Recursos para el profesional independiente (freelancer)

En los últimos años me ha tentado en más de una ocasión ejercer mi profesión de manera independiente, pero por diversos motivos nunca me decidí a hacerlo. Más allá de eso quiero compartir algunos recursos que revisé en esas ocaciones y que me parecieron muy útiles particularmente para profesionales independientes.

Empiezo por el libro de Miles Burke: The Principles Of Successful Freelancing. Esta obra toca una gran diversidad de temas que van desde las consideraciones para decidirse a trabajar independiente, hasta work-life balance, pasando por consejos financieros, calidad de servicio y configuración de la oficina hogareña. Un recurso muy útil y entretenido para leer.

Otro recurso valiosísimo es la técnica del Pomodoro. Sin entrar en mayor detalle les digo que esta técnica ayuda administrar mejor el tiempo e incrementar la productuvidad.

Una lectura que también me parece apropiada y no solo para independientes es el best seller: Los 7 hábitos de la gente altamente efectiva.

Por último creo que Linkedin es una herramienta clave para promocionarse y hacer contactos, dos puntos a mi entender importantísimos para todo freelancer.

Bien, esto es todo lo que tenia por decir a pesar de nuncar abler trabajado independiente, pero bue, es lo que hay.

Se aceptan sugerencias.

GitHub quickstart

Hace un tiempo que estoy colaborando en un proyecto open source que recientemente fue migrado de SVN a GIT, particularmente a GitHub y dado que algunos miembros del equipo del proyecto no estan familiarizados con esta herramienta he decidido escribir es post orientativo. GIT a diferencia de SVN es un sistema de control de versiones NO centralizado (SVN es centralizado), este es un detalle interesante, pero en este momento no voy a profundizar al respecto, sino que voy a pasar directamente a los pasos para comenzar a trabajar con esta herramienta.

Aclaración: si bien hay más de una forma de trabajar con Github, yo voy a enfocarme en la que considero más simple.

En primer lugar vamos a github para crear

image

Dado que en este caso vamos a trabajar en un proyecto open source bastará con seleccionar la opción de cuenta gratuita. Una vez que tengamos nuestra cuenta, nos comunicaremos con el administrador del proyecto en que deseamos colaborar y pedirle que nos otorgue acceso de escritura.

image

Bien, ahora vamos a tener que instalarnos un cliente de git para poder conectarnos y trabajar. Aqui hay una lista de clientes para todos los gustos, personalmente les recomiendo un cliente de consola, a mi me ha dado más exito que los clientes de ventanas. Una vez instalado el cliente vamos a necesitar generar una clave RSA que es lo que Git utiliza para autenticar a los usuarios. Esto es muy simple (al menos con el cliente de consola, ja!) en está página de github van  encontrar las instrucción para generar su clave, pero siendo más directo, hagan esto: abren la consola Git, se posicionan en la carperta c:\users\{tuusuario}\.ssh (si no existe la crean) y tipean:

ssh-keygen -t rsa –C “{tu cuenta de mail que usaste para registrarte en github}”

Cuando les pida nombre de archivo, presionen enter y se utilizarán los nombres default. Si gustan pueden poner un passphrase, pero es opcional. Esto va a generar dos archivos: uno con la clave pública para subir a github (id_rsa.pub) y otro con la clave privada que NUNCA deberán compartir (id_rsa).

image

El siguiente paso es configurar nuestro client local indicando nuestro nombre y direccion de correo. Para ello debemos ejercutar las siguientes dos lineas:

git config —global user.name “{tu nombre de usuario}”

git config –global user.email {tu correo}

Ahora que ya tenemos nuestro par de claves, volvemos a github y subimos nuestra clave pública. Vamos a SSH Public Keys\ Add another public key y pegamos el contenido del archivo id_rsa.pub (mucho cuidado de no agregar ningún caracter adicional).

image

image

Con esto ya estamos en condiciones de dirigimos al repositorio del proyecto en que queremos trabajar. Claro, antes de esto deberiamos asegurarnos que el administrador del proyecto nos haya otorgado permiso de escritura en el repositorio. Si es asi, entonces veremos en la página del repositorio la URL de read+write.

image

Copiamos la url de read+write y vamos a la consola git. Nos dirigimos al directorio local donde crearemos nuestro repositorio local y ejecutamos la sentencia para crearlo:

git clone {url que copiamos de github}

image

Si todo salió bien, ya tenemos nuestro repositorio local y podemos empezar a trabajar. Un detalle interesante a tener en cuenta cuando trabajamos con git es que es una herramienta no centralizada de control de versiones. Esto significa que cada miembro cuenta con una copia local completa de todo el repositorio. Para trabajar sincronizadamente, uno de estos repositorios es designado como master. El master, en cierto modo puede ver como el repositorio central de un SVN, a lo interente de git es que si el master se cae, facilmente podemos designar otro y seguir trabajando.

Dicho esto, en general nuestro flujo de trabajo será:

  1. Actualizar nuestro repositorio local y nuestra copia de trabajo obteniendo la última versión desde el repositorio master. En términos concretos de git esto es ejecutar un git pull.
  2. Realizar nuestro trabajo sobre el contenido y comitearlo. En términos de git es ejecutar dos comando: git add <arcihvo modificado/agregado>  y git commit. El primero de estos comando “agrega” el archivo indicado a la lista de archivos del próximo commit. El segundo es el commit que  “copia” nuestras modificaciones desde nuestra copia de trabajo a nuestro repositorio local.
  3. Mezclar nuestros cambios con el repositorio master, esto es: ejecutar un git pull para obtener la última version desde el repositorio master. Si el pull es exitoso, entonces nuestro repositorio contendrá la última versión (lo que estaba en el repositorio master + nuestros cambios)
  4. Actualizar el repositorio master con nuestro contenido, lo cual se hace ejecutando un git push.

Creo que no olvido nada, si bien hay muchas cosas más por decir esto deberia ser suficiente para las necesidades de mi equipo de proyecto.

Le doy las gracias al groso de  Dario Seminara, evangelizador de GIT, por revisar este post y les recomiendo que si gustan aprender más de Git, no duden en visitar el blog de Dario.

Espero les resulte útil.

Proyecto Seed (segunda parte)

Habiendo seteado algo de contexto en la primera parte ahora voy a hablar en concreto de lo que estamos haciendo en Seed. Arrancaré como bien dicen las practicas de proyectos por definir nuestra visión y misión.

Visión: Pharo cuenta con un kernel mínimo, límpio y extensible.

Misión: experimentar con distintas estrategias para crear un paquete que nos permita crear imagenes mínimas y customizables de Pharo.

Si bien esto parece bastante claro a estas alturas, las primeras 3 semanas de proyecto por momentos me sentí como turco en la neblina, pues había algunas cosas que no me cerraban. Al mismo tiempo, al comienzo nos dedicamos hacer algunas pruebas de concepto experimentado con los enfoques utilizados en otro proyectos y por momento era darse la cabeza contra la pared demasiado seguido. Por suerte, ya durante la cuarta semana de trabajo y luego de varias sesiones de peloteo con Stef y Marcus pusimos norte a nuestro barco definiendo el roadmap de trabajo.

Existen distintas posibilidades para atacar esta problemática, algunas de las cuales ya hemos descartado de entrada. Por ejemplo, hemos decidido manejar el mismo formato de imagen que Pharo, o sea, queremos seguir utilizando la misma máquina virtual (aunque no se decarta que en futuras versiones del proyecto se propongan cambios en la máquina virtual para así optimazar el funcionamiento del sistema).

Si pensamos en nuestro problema como “obtener una imagen tan chica como sea posible”, básicamente existen 2 alternativas:

  1. Partir de una imagen existente y recortarla todo lo posible
  2. Partir de una imagen vacia y agregar lo mínimo necesario

Como se podrán imaginar, nosotros no somos lo primeros en atacar esta problemática, ya ha habido proyectos anteriores entre los que me parece importante destacar:

  • Chácharas: sin entrar en detalles, lo que hace es crear una imagen “vacia” y la va llenando en runtime y on the fly. O sea si cuando envia un mensaje a la clase X se intercepta la llamada, se chequea la validez del mensaje y si el mismo no se puede resolver se comunica con otro imagen e importa las clases que resulten necesarias para poder resolver la llamada. El detalle es que requiere de una máquina virtual modificada.
  • Gwen Bootstrap: este desarrollo lo hizo Gweneal Cassasio quien es también parte del equipo RMoD. Básicamente Gwen trabajó sobre Gnu-Smalltalk, modificó la máquina virtual y definió su propia imagen desde cero.
  • PharoKernel: este es un desarrollo de Pavel Krivanek quien a muy grandes rasgos tomó una imagen de Pharo y la entró a recortar y mediante prueba y error se aseguro que el subconjunto final era suficiente para cargar el sistema.

A diferencia de estos enfoques nosotros hemos decidido comenzar de una imagen vacia e ir agregando lo mínimo indispensable y al mismo tiempo de ir identificando “cosas sospechosas” para modificar en el proceso de creación de nuestra imagen.

Ahora: ¿qué es lo mínimo? Ja! ¡Que buena pregunta Mario! La respuesta queda para la próxima entrega porque no es trivial y va a requerir unas cuantas líneas.

Continuará…

Recomendaciones para dictar workshop

Después de haber dictado algunos workshop y haber participado en tantos otros, hay algunas recomendaciones que quiero compartir.

En general los workshops tienen una estructura bastante estándar:

  1. Introducción: que puede contener algo de teoría y la explicación de la consigna. En caso de ser necesaria una introducción teórica se suele utilizar un slide deck para facilitar la explicación.
  2. Actividad: donde generalmente los asistentes son divididos en grupos y trabajan sobre la consigna. Puede que haya una o varias actividades.
  3. Cierre: donde se hace una puesta en común de realizado por los asistentes, se reflexiona sobre lo aprendido / ejercitado y se extraen conclusiones.

Un punto muy importante para el éxito es setear las expectativas al comienzo del workshop, por ello yo suelo poner en la segunda diapositiva (en la primera está el título del workshop) el objetivo del workshop y luego en la tercer diapositiva, la agenda del workshop listando las actividades que se realizarán con los tiempos estimativos de cada una.

image

Por otro lado muy importante manejar correctamente los tiempos, pues de lo imagecontrario puede que no se lleguen a completar las actividades. Para esto, ultimamente he utilizado un software de reloj en cuenta regresiva mostrando el tiempo restante para completar la actividad. Este reloj muestra a todos los participantes el tiempo restante mientras trabajan.

Para esto he utilizado una herramienta gratuita llamada XNote Timer.

Por último, es importante obtener feedback al final del workshop de feedbackcara a poder mejorarlo. Para esto suelo utilizar la técnica del post-it, a cada participante le pido que al finalizar dibuje una carita ( :-), :-|, 😦 ) en un post-it y si gusta escriba al dorso cualquier sugetencia que pueda tener.

Espero esto les resulte útil.

eSTImation MAnager (stima)

Last Monday, my classmate Maria Florencia Perez  finished her studies when she presented her proffesional work: Stima. It is a software that allow users to perform estimations of duration and effort for software development project. It is based on use case points method and it provides some useful features like metrics, estimation history and comparison.

The application is available under Apache License and can be downloaded from Google code rigth at this location.

WordPress through Live Writer

Believe it or not, I am writing this post using Live Writer. Yes Microsoft built a software that is capable to work/interact with services that directly compete with his own product (Live Spaces).

After moving my blog to WordPress, I was looking for a tool that allow me to write posts being offline. After reviewing several tools I read an article that mentioned that it was possible to use Live Writer to post on WordPress. I didn’t beleive it at once, so I had to check it myself. And you see, that article was rigth!.