Archivo de la categoría: Productividad

Org-Mode I

Estados custom

Agregar al principio del archivo esta línea:

#+TODO: TODO(t) WORKING(w) | DONE(d) CANCELED(c)

Shortcuts

C-c C-c Toggle checkbox
C-c C-x C-b Org Toggle checkbox
C-c C-x C-a Archive subtree (org-archive-subtree)

Estadísticas

Agregar [/] en la entrada padre y apretar C-c (al final de la línea) o apretar C-c en alguno de los checkboxes (o marcarlo como “completed” / “done”, etc.) para actualizar la estadística.

Reportes y timers

C-c C-x C-i para iniciar un timer
C-c C-x C-o para detener un timer
Marcar una tarea como DONE para detener un timer
C-c C-x C-r para actualizar el reporte

Reporte semanal (suma de horas)


#+BEGIN: clocktable :maxlevel 2 :scope file :block thisweek

#+END:

Reporte diario detallado


#+BEGIN: clocktable :maxlevel 2 :scope file :block today

#+END:

Reporte semanal detallado


#+BEGIN: clocktable :maxlevel 2 :scope file :block thisweek :step day :stepskip0

#+END:

Anuncios

Política de To-Read

Estoy reduciendo la carga de los “A leer” o To-Read. La idea es que al final del día no me quede ningún to-read a menos que realmente valga la pena. Al mismo tiempo, quiero estar relativamente informado de las tendencias y nuevas tecnologías, por lo que necesito tener al menos una subscripción RSS que englobe mas o menos todas las tendencias tecnológicas (DZone).

Para esto, tengo:

1) RSS con Thunderbird, configurado para borrar los feeds que no lea en el día (y también los leídos) excepto aquellos que marque como “destacados”.

2) Un archivo “leyendo” con las páginas que estoy leyendo (en general tutoriales relativamente largos). La idea es que este archivo sea pequeño, nunca pase de los 5 items.

3) Un archivo de links categorizados donde agregue los artículos que después de leerlos me interese tener como referencia. Esto lo hago con Emacs / Org-Mode y lo publico en mi sito personal. Podría implementarse también con Delicious.

En general ahora elijo sólo aquellos to-reads que realmente me interesen y, sobre todo, dejar de acumular una infinita lista de to-reads.

Objetivos Próximos

Siguiendo la pauta que leí en alguna parte, lo mejor para hacer algo es decir que lo vas a hacer. Así que pienso investigar estos temas en algún momento, haciendo algún que otro post con mis pequeñas investigaciones:

SmallTalk | POO “en serio”

Me dieron ganas de aprender lo básico de SmallTalk cuando en una charla en una empresa del centro sobre Node.js (no recuerdo cuál) un hombre que había trabajado en IBM bastante tiempo me comentó que lo que implementan la mayoría de los lenguajes de programación hoy en día no es POO sino algo “parecido”. Que en realidad POO son objetos “vivos” en memoria y modificables en tiempo real. Es decir, que sólo SmallTalk provee un entorno de objetos.

ExtJS | La web para programadores

Vengo trabajando hace algún tiempo con ExtJS pero todavía no hice un proyecto desde “cero” con esta tecnología y por eso me gustaría conocer las bases. Es excelente porque le saca el carácter “documental” a la web: permite hacer verdaderas aplicaciones web donde no tocás un ápice de HTML ni CSS: Javascript puro y duro como nos gusta a los programadores.

Three.js | Juegos en 3d y Javascript

No hay que ser un genio para darse cuenta por qué puedo estar interesado en esto. O sea, ¡3d!

Aunque mi interés por los juegos decayó bastante, me queda algún interés por renderizar gráficos 3D.

Proyectos personales

Si uno quiere concretar algunas cosas, tiene que expresarlo. Tirar semillas al viento. Alguna quizás crezca. Lo importante es comunicar los deseos o ideas de uno. Si, esto quizás tiene el lado negativo de que alguien puede robar tu idea. Pero, el tiempo que vengo intentando proyectos personales por mi cuenta en solitario no ha dado muchos resultados, así que no está demás probar.

Blog en ingles

Posiblemente sería bueno, tanto para mejorar mi ingles como para mostrar mi trabajo afuera, hacer un blog en inglés.

Otras cosas que me gustaría investigar en algún momento:

– Lenguaje de programación R

– IA

– Lisp

– Programación declarativa

Efectividad de los task managers

Generalmente se usan las listas de tareas para organizar las tareas futuras. Hay numerosos programas para tal fin. Uno bastante copado para Linux es Nitro, aunque hay numerosas alternativas, tanto online como offline. El tema de mantener todo en “La Nube”, con la facilidad de poder acceder desde cualquier dispositivo poco a poco se va comiendo todo y también estoy pensando en migrar de Nitro a alguna aplicación web como Redmine (un project manager bastante pulenta hecho en Rails). Igualmente, la realidad es que importa bastante poco qué task manager uses. Un task manager no va a hacer que seas mas productivo, de hecho, ¡incluso puede reducir tu productividad! Ya que uno puede acostumbrarse a cargar tareas en el task manager en vez de… hacerlas.

Este es el futuro de la computación.

A mi particularmente creo que me resultan productivos siempre y cuando le dedique muy poca atención al task manager en si mismo y especifique bien los pasos a realizar en la tarea. Anotar tareas poco descriptivas, nebulosas, no sirve de mucho, si no estamos seguros de qué vamos a hacer, mejor no lo anotemos. Tampoco sirve llenar el task manager de tareas si después no vamos a hacer ninguna.

A ustedes, ¿qué tan útiles les resultan los task managers? ¿cómo los usan?

Por qué no administrar tus propios sitios

Invirtamos la pregunta. ¿Por qué alguien administraría sus sitios en un servidor totalmente bajo tu control como Amazon EC2 o algún otro VPS? Hasta ahora, se me ocurren cuatro respuestas:

  1. Porque está desarrollando algo loco y usa tecnologías raras que requieren tener un servidor propio configurado a piacere. Ruby on Rails, cronjobs, cualquier cosa que implique una aplicación web compleja y/o con una cofiguración no estándar (PHP-MySQL) y para el cual no haya aparecido algo que lo resuelva gratuitamente como, en el caso de RoR, Heroku.
  2. Porque necesita personalizar a fondo el server para obtener la máxima performance.
  3. Porque lo necesita para otras tareas y ya que está lo usa para hosting.
  4. Por hobbie.

No se me ocurren mas razones por las cuales no derivar el hosting de tus sitios en servidores externos, que te ahorran el problema de la configuración y administración de los mismos, habiendo tantas alternativas gratuitas. Bueno, en realidad sí se me ocurre una opción mas: para entender cómo funcionan estas tecnologías por abajo.

Es bastante lo que aprendés cuando tenés que levantar sitios usando como única herramienta la consola de comandos. Pero claro, una vez que mas o menos entendés el funcionamiento lo mejor es derivar el trabajo pesado en sistemas que ya están funcionando sin tu intervención para ocuparte de lo realmente importante en un sitio: el contenido.