1. Story: Humans like stories and Moleskine story is motivating. I’m saying the story because the real history could be a little different. Well, it’s another feeling and I compare it like using Mac (Molesking) vs a PC (simple notebook).
2. Paper format: There are plain, ruled, square, pentagram, etc., etc. paper formats so you can have a notebook that fits your needs. I use plain paper format because I want to have all the freedom for writing notes, ideas, mindmaps, etc.
3. Cover: You can can choose hard or soft cover so you can feel comfortable carrrying it and writing.
4. Page marker and inner pocket: A page marker is always useful and inner pocket helps you to keep papers, post-its, etc. and is so useful.
5. Size: Pocket, Large and Extra-Large notebooks are available. I always carry a pocket size notebook and I use a large size for mindmaps about conferences & books I read.

In conclusion, I use Molesking because it has a lot of features that motivate me for writing notes, ideas, etc. which is a great technique  I read from Pragmatic Thinking & Learning by Andy Hunt.

Configuring Debian GNU/LiNUX to use a public NTP Server is simple, just do this:

$ sudo aptitude install ntpdate

The ntpdate package includes the file /etc/if-up.d/ntpdate that runs /usr/bin/ntpdate-debian after an interface (eth0, eth1, etc.) is up so you won’t have to worry about configuring this synchronizing process to run automatically. Let’s run it manually so we apply the time from the NTP Server right now:

$ sudo ntpdate-debian
14 Mar 21:41:50 ntpdate[10808]: step time server 146.164.48.5 offset -0.589987 sec

That’s it! This is the simple way but if you want to try a more advance config just read /usr/share/doc/ntpdate/README.Debian and /etc/default/ntpdate files in your server.

I’ve got that information by taking notes for three months. The solution could be just trying to sleep eight hours but sometimes it’s inevitable because of the crunch time at work or personal project, going to a social event, etc. etc. I want to avoid any dependence of pharmacological drugs so what can I do? I tried different ways (founded in internet) to solve this problem: going to the gym, eating an ice cream after the aura, etc, etc. and nothing works for me.

In 2008, when I was thinking about my migraine problem I read Pragmatic Thinking & Learning by Andy Hunt. It’s a really good book and I like the way Andy explains how our mind works using computer metaphors. So I got an idea,… I’ve been involved in software development since I was ten years old so maybe if I thinking about the migraine as a software problem (bug) could help me to find a solution.

I spent a whole week thinking about the migraine as a bug. I used the trial and error method to verify my ideas for some months until I got this:

The migraine starts with 15 to 30 minutes with an aura, the problem is the amount of wrong information between the systems involved (brain and eyes) because I see something (aura) that doesn’t exist and my brain knows that so maybe it requests again and again information to the eyes. That could explain why after the aura disappears the headache is worse just behind the eyes because both systems were overloaded.

I can’t upgrade those systems (sadly) so I tried to find a way to filter the wrong information: closing my eyes, going to lightly room, etc, etc,… and one day I had a headache attack while I was reading a book and what I used to do is stop reading because reading with a little vertigo is quite complicated but this time I decided to continue and tried to concentrate in the reading and not paying attention to the aura. When the aura disappears I don’t have a headache!!!!

I was surprised about this event so I took my notes and write about it. Then every time I had an aura, I started to read anything and after the aura disappear most of the time I didn’t have a headache. My conclusion was:

To filter the wrong information I have to force my brain to pay attention to other thing (reading a book) instead of the aura.

The next month I tried to find other ways beside reading a book for avoiding the headache so with practice now when I have an aura I can pay attention to other things like the street, the computer, colors, etc. and don’t have headache. I have 15-30 minutes with the aura but I don’t have headaches for 6-24 hours and that’s improved dramatically my quality of living.

I hope to have time to write other post about this technique in detail. If you have the same type of migraine you could tried what I write here, maybe it could work maybe not but it could help you to find a solution for your case.

I don’t know why we won the game with a blind goalkeeper but that’s another story. When the game finished, I was feeling better because I can see normally but a terrible headache started. I felt like dying because it was so painful and lasted until the next day. I had two more migraines after that day with the same symptoms but I didn’t go to see a doctor because that was a headache and nothing more. My mother told me that she had something similar several years ago and she thoughts it was migraine.

When that happened, I was 15 years old and over the next years I had that terrible headaches only once a year so I forgot to think about it and try to find a solution. Sadly when I was 25 years old and I was working in a software development company when the headaches started again but this time they occur once a day during a week so I thought that something terrible is going to happen to me. I went to see a doctor and he ordered a lot of exams to find if something unusual was happening in my brain but he can’t find anything wrong so he told me: “You have migraine and you have to find what is the trigger“.

The doctor told me that pharmacological drugs can help me to avoid the terrible headaches but they are addictive so my body will need more and more to avoid the pain. I didn’t like that so I decided to find the trigger, I read a lot of information in internet and I started to take notes of what I ate, drank, weather, stress level, etc. After that terrible week, I have migraines more frequently from one to six times a month so after a few months I had enough data to see that my migraine trigger was little sleep or too much sleep and also the stress is an important factor.

I can try to sleep enough but work, my personal projects and also social events from time to time won’t let me sleep eight hours so what can I do? The migraine affects not only my productive time, it also affects my personal life so I decided to find a solution and in the next post I will share how I find a solution for my migraines.

Es una técnica que busca potenciar la forma de trabajo que tiene nuestro cerebro, a través del uso de palabras o imágenes relacionadas entre si con lineas. Estos diagramas son más fáciles de recordar que lineas de texto, es más puede incluso estimular nuestro cerebro a encontrar otros conceptos y relacionarlos con los que ya se tienen.

Los mapas mentales son diagramas que se usan para organizar, generar ideas y capturar información; podemos usarlos para estudiar, resolver problemas, tomar decisiones, escribir artículos y mucho más.

¿Cómo es un mapa mental?

Es simple, primero comenzamos con una idea central:

Luego vamos agregando agregando palabras/conceptos relacionados. Es importante el uso de colores.

Una imagen vale mas que mil palabras así que podemos agregar imágenes que ayuden.

Pueden ayudar otras relaciones entre los conceptos que ya tenemos e incluso podemos trazar líneas en blanco para motivar nuestro cerebro a buscar más conceptos.

¿En que podemos usar mapa mentales?

Prácticamente en todo, por ejemplo :

• Para tomar notas: En clases o en una reunión es importante capturar de manera rápida los conceptos claves.
• Lluvia de ideas: En grupo o de manera individual es importante capturar todas las ideas que vengan y motivar que nuestro cerebro busque la mayor cantidad de conceptos relacionados con el tema central.
• Toma de decisiones: Primero hacer una lluvia de ideas y luego organizarlas para que podamos tomar una decisión.
• Presentaciones: Una manera simple y rápida de armar una presentación que sea fácil de captar por el público.
• Productividad: Capturar tareas, organizarlas, priorizarlas, etc. Por ejemplo es un buen complemento para la técnica de Getting Things Done.

En próximos artículos tocaré con mayor detalle de cada una de las aplicaciones de los mapas mentales.

¿Qué necesitamos?

No necesitamos mas que lapiz/lapicero y papel para comenzar con los mapas mentales, aquí algunas ideas:

• Una hoja en blanco (sin lineas) y lápices de colores: Es lo ideal usar colores pero cuando es necesario incluso podemos usar una servilleta y un lápiz negro.
• Moleskine: Podemos usar este legendario cuaderno y lápices o lapiceros de colores.

En el mundo virtual tenemos muchos programas disponibles, entre ellos les recomiendo:

• Freemind: Simple, ligero y multi-plataforma.

• Xmind: Es un producto completo y que uso para casi todo en mi día a día.

Es fácil de aprender

Todo el tiempo que llevo usando esta técnica he encontrado que solo es necesario explicar los conceptos básicos de mapas mentales, luego cada uno por si solo puede usarlo y encontrar el potencial de esta técnica, descubrir nuevos usos, etc. Ejemplo de esto es como se difundió el uso de mapas mentales en las comunidades de Agile Perú y Spring Perú así como en mi centro de trabajo.

Los animo usar esta técnica que es simple pero muy potente, en estos enlaces pueden encontrar otros ejemplos de mapas mentales:

• Xmind Share
• Modlost’s Xmind Share Page

• Instalando Debian GNU/LiNUX 5.0 (Lenny)
• Completando la instalación Debian GNU/LiNUX 5.0 (Lenny)

Nota: En este artículo asumo conocimiento previo de LiNUX y LDAP.

Instalación

Una vez más utilizaremos aptitude para instalar los paquetes que necesitemos. Ejecutamos el siguiente comando:

modlost@ironhide:~$ sudo aptitude install ldap-server phpldapadmin

Tendremos que ingresar la contraseña del administrador del servidor LDAP durante la configuración del paquete ldap-server.

Confirmamos la contraseña:

Tomar en cuenta que durante la instalación se creará una base de datos LDAP en base al nombre de dominio que asignamos al servidor de pruebas.

Administración

Existen varias formas de administrar el servidor LDAP, por ejemplo: por línea de comandos, aplicaciones web y aplicaciones de escritorio. En nuestro caso usaremos una aplicación hecha en PHP llamada phpLDAPadmin que ya esta configurada y lista para usar ingresando a la siguiente ruta:

http://virtualmachineip/phpldapadmin/

Deben reemplazar virtualmachineip por el IP que tiene asignada la máquina virtual. En el artículo Completando la instalación Debian GNU/LiNUX 5.0 (Lenny) encontrarás los pasos para obtener la IP.

Haciendo click en el enlace “Login…” veremos que el “Login DN” ya se encuentra completado con el distinguish name del administrador del servidor LDAP. Ingresamos la contraseña que definimos en la instalación.

Ahora podemos ver claramente la estructura que se creo en la instalación del servidor LDAP. Esta aplicación web nos permitirá administrar nuestro servidor LDAP: consultar, crear, eliminar, actualizar, exportar, importar datos en la base de datos.

Datos de prueba

Preparando los datos de prueba para los siguientes artículos importaremos un grupo y un par de usuarios.

Seleccionando la opción “import”, podemos subir un archivo LDIFF o pegarlo directamente para importarlo. Ya que nuestros datos de prueba son pequeños solo pegaremos el siguiente LDIFF

version: 1

dn: ou=groups,dc=modlost,dc=net
ou: groups
objectClass: top
objectClass: organizationalUnit
description: Groups

dn: cn=developers,ou=groups,dc=modlost,dc=net
objectClass: posixGroup
objectClass: top
cn: Developers
gidNumber: 2000
memberUid: modlost
memberUid: ssilva

dn: ou=people,dc=modlost,dc=net
ou: people
objectClass: top
objectClass: organizationalUnit
description: People

dn: uid=modlost,ou=people,dc=modlost,dc=net
cn: Abner Ballardo
objectClass: posixAccount
objectClass: inetOrgPerson
sn: Ballardo
uid: modlost
uidNumber: 2000
gidNumber: 2000
homeDirectory: /home/modlost

dn: uid=ssilva,ou=people,dc=modlost,dc=net
cn: Stephanie Silva
objectClass: posixAccount
objectClass: inetOrgPerson
sn: Silva
uid: ssilva
uidNumber: 2001
gidNumber: 2000
homeDirectory: /home/ssilva

Haciendo click en el botón “Proceed >>” procedemos con importar la data.

Si todo ha sido satisfactorio obtendremos el siguiente reporte:

Excelente! Vamos a practicar un poco el uso de phpLDAPadmin signando una contraseña al usuario modlost, para ello hacemos click en “uid=modlost”

Hacemos click en “Add new attribute”.

Seleccionamos “userPassword”, ingresamos la contraseña y finalizamos haciendo click en el botón “Add”.

Probamos esta configuración, terminando la sesión actual para luego ingresar con el usuario modlost y la contraseña que acabamos de asignar:

Si logran ingresar habrán configurado satisfactoriamente la contraseña. Ahora tenemos un servidor LDAP con el cual jugar!!!!!!

Nota: Asumo un conocimiento previo de Linux, VIM y BASH

Luego de finalizar la instalación de nuestro servidor de pruebas, podemos ingresar con el usuario administrador (root)

Usando el editor de texto vi o nano podemos editar el archivo /etc/apt/sources.list y eliminamos todas las líneas que contengan “deb-src” y “deb cdrom”. En mi caso el archivo queda así:

deb http://ftp2.de.debian.org/debian/ lenny main
deb http://security.debian.org/ lenny/updates main
deb http://volatile.debian.org/debian-volatile main

Antes de comenzar a instalar debemos actualizar la lista de paquetes disponibles:

ironhide:~# aptitude update

Usaremos el programa sudo para delegar accesos al usuario sin privilegios de administración, el que creamos durante la instalación de Debian Lenny. Para mayor información puede visitar el website de sudo:

ironhide:~# aptitude install sudo

Para configurar sudo ejecutamos:

ironhide:~# vi sudo

Se levantará un editor de textos (vi o nano) y modificamos la ultima línea:

# /etc/sudoers
#
# This file MUST be edited with the 'visudo' command as root.
#
# See the man page for details on how to write a sudoers file.
#

Defaults        env_reset

# Host alias specification

# User alias specification

# Cmnd alias specification

# User privilege specification
root    ALL=(ALL) ALL

# Uncomment to allow members of group sudo to not need a password
# (Note that later entries override this, so you might need to move
# it further down)
%sudo ALL=NOPASSWD: ALL

Guardamos los cambios. Agregamos el usuario sin privilegios de administración al grupo sudo:

ironhide:~# adduser modlost sudo

Luego, instalaremos el servidor SSH ya que es más flexible (en mi opinión) usar un cliente SSH del sistema operativo host para administrar nuestro servidor de prueba que usar la consola en la maquina virtual.

ironhide:~# aptitude install ssh

Necesitamos obtener el IP del servidor de pruebas, para ello ejecutamos este comando:

ironhide:~# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:0c:29:91:79:90
          inet addr:172.16.234.128  Bcast:172.16.234.255  Mask:255.255.255.0
          inet6 addr: fe80::20c:29ff:fe91:7990/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:11037 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6299 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:13688669 (13.0 MiB)  TX bytes:519837 (507.6 KiB)
          Interrupt:18 Base address:0x2000 

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:8 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:560 (560.0 B)  TX bytes:560 (560.0 B)

Cerramos la sesión con el usuario root y usando el cliente SSH que prefieran (PuTTY en Windows o el comando ssh en GNU/LiNUX o Mac) nos conectamos al servidor de pruebas.

Finalmente, instalaremos los siguientes programas:

• Vi IMproved – enhanced vi editor: Esta variedad de VI tiene más funcionalidades que la versión instalada por defecto.
• Apache HTTP Server – traditional non-threaded model: El popular servidor web.
• PHP5: El popular lenguaje script.
• MySQL Database Server: El popular servidor de base de datos.

Con los comandos:

modlost@ironhide:~$ sudo aptitude install vim apache2-mpm-prefork php5
modlost@ironhide:~$ sudo aptitude install mysql-server php5-mysql

Durante la instalación de MySQL se solicitará ingresar la contraseña de usuario administrador (root) de la base de datos:

Confirmamos la contraseña

Todo esta instalado y solo falta configurar VIM un poco para que sobresalte con colores y que tome en cuenta que uso una consola con fondo negro. Estas y otras mejoras las obtenemos modificando el archivo de configuración:

modlost@ironhide:~$ sudo vi /etc/vim/vimrc

Quitamos los comentarios de las siguientes lineas resaltadas (en vimrc los comentarios comienzan con comillas dobles)

" All system-wide defaults are set in $VIMRUNTIME/debian.vim (usually just
" /usr/share/vim/vimcurrent/debian.vim) and sourced by the call to :runtime
" you can find below.  If you wish to change any of those settings, you should
" do it in this file (/etc/vim/vimrc), since debian.vim will be overwritten
" everytime an upgrade of the vim packages is performed.  It is recommended to
" make changes after sourcing debian.vim since it alters the value of the
" ‘compatible‘ option.

" This line should not be removed as it ensures that various options are
" properly set to work with the Vim-related packages available in Debian.
runtime! debian.vim

" Uncomment the next line to make Vim more Vi-compatible
" NOTE: debian.vim sets ‘nocompatible‘.  Setting ‘compatible‘ changes numerous
" options, so any other options should be set AFTER setting ‘compatible‘.
"set compatible

" Vim5 and later versions support syntax highlighting. Uncommenting the next
" line enables syntax highlighting by default.
syntax on

" If using a dark background within the editing area and syntax highlighting
" turn on this option as well
set background=dark

" Uncomment the following to have Vim jump to the last position when
" reopening a file
if has("autocmd")
  au BufReadPost * if line("‘\"") > 0 && line("‘\"") <= line("$")
    \| exe "normal! g‘\"" | endif
endif

" Uncomment the following to have Vim load indentation rules and plugins
" according to the detected filetype.
if has("autocmd")
  filetype plugin indent on
endif

" The following are commented out as they cause vim to behave a lot
" differently from regular Vi. They are highly recommended though.
set showcmd            " Show (partial) command in status line.
set showmatch          " Show matching brackets.
set ignorecase         " Do case insensitive matching
set smartcase          " Do smart case matching
set incsearch          " Incremental search
"set autowrite          " Automatically save before commands like :next and :make
"set hidden             " Hide buffers when they are abandoned
"set mouse=a            " Enable mouse usage (all modes) in terminals

" Source a global configuration file if available
" XXX Deprecated, please move your changes here in /etc/vim/vimrc
if filereadable("/etc/vim/vimrc.local")
  source /etc/vim/vimrc.local
endif

Guardamos los cambios y podemos continuar jugando con nuestro servidor de pruebas con Debian GNU/LiNUX 5.0 – Lenny

Con este nuevo instalador ahora tenemos disponible un practico botón para guardar screenshots, así que aprovechando esta característica me decidí a escribir un mini artículo de instalación. No busco detallar los pasos para instalar un servidor de producción, sino mi intensión es brindar una guía para instalar un servidor de pruebas en una máquina virtual. Con servidor de pruebas quiero decir un servidor donde podamos jugar con base de datos, ldap servers, web servers, etc.

Nota: En este artículo asumo un conocimiento previo de linux.

Comenzando la instalación

Descargamos la imagen del CD del network install (netinst) desde aqui:

http://www.debian.org/CD/netinst/

Esta imagen solo contiene el instalador y el sistema base, por eso pesa menos que el CD #1 de la distribución completa. Para este servidor de pruebas solo quiero descargar los paquetes que instalaré y netinst es una buena opción para lo que quiero hacer.

Podemos quemar esta imagen o usarla directamente como CD dentro de una maquina virtual. Debes asegurarte que el BIOS busque arrancar desde la lectora de CD’s antes que otros dispositivos.

Seleccionamos “Graphical Install” para iniciar la instalación.

Idioma y Teclado

Prefiero usar el idioma ingles ya que algunas veces las traducciones pueden ser confusas con los términos castellanizados.

Para seleccionar nuestra ubicación geográfica, escogemos la opción “otros”.

Buscamos Sudamérica.

Y luego podremos encontrar a Perú.

Seleccionamos el tipo de teclado, recuerden que para teclados en español tenemos dos opciones Spanish o Latin America.

Configuración de Red

Indicamos el nombre del servidor de pruebas. Por ser un fanático de los Transformers todas mis PC’s y VM’s tienen nombre de Autobots o Decepticons. ¿Qué nombre escogerás?

Ingresamos el dominio al que va a pertenecer nuestro servidor de pruebas. No tiene que ser uno existente solo usen su imaginación.

Particionamiento

Ya que es un servidor de pruebas vamos a utilizar la opción de instalación más simple: “Usar el disco entero”, es decir, la instalación usará todo el espacio disponible en el disco y sobreescribirá cualquier información anterior.

Seleccionamos el disco a particionar.

Usaremos la opción más simple de patrones de particionamiento: “Todo en una sola partición”.

El instalador realizará el particionamiento por nosotros, así que solo tenemos que continuar.

Antes de aplicar los cambios se muestra un resumen de lo que se hará. Confirmamos los cambios y continuamos.

Instalación del Sistema Base

Luego de terminado el particionamiento, se instalará el sistema base.

Usuarios

Ingresamos el password del usuario administrador (root) de nuestro servidor de pruebas.

Las buenas prácticas recomiendan usar un usuario sin privilegios de administración para realizar tareas cotidianas y solo usar el usuario root para las administrativas. Ingresamos el nombre de este usuario.

También ingresamos el nombre de la cuenta de dicho usuario.

Confirmamos la contraseña.

Mirrors

Seleccionamos el país desde donde bajaremos los paquetes a instalar.

Seleccionamos el servidor espejo dentro de ese país.

Si en tu red tienes un servidor proxy, este es el momento de ingresar sus datos. De no tener un proxy lo dejamos en blanco.

Instalando paquetes

Puedes apoyar a Debian brindando información de que paquetes instalas para así organizar mejor los paquetes dentro de los CD’s de la distribución. Como estamos instalando un servidor de pruebas no aceptamos la encuesta.

En mi opinión no es necesario instalar el entorno gráfico un servidor de pruebas por eso solo dejo seleccionado la opción de sistema estándar. Si se sienten mas cómodos con un entorno gráfico pueden seleccionar “Desktop environment” pero como consecuencia tendrán que bajar más paquetes.

Gestor de arranque

Para arrancar Debian instalaremos Grub en el Master Boot Record.

¡Terminó a instalación!

Finalmente el instalador nos indica que terminamos la instalación, el siguiente paso reinicia el servidor.

Ya tenemos instalado Debian GNU/LiNUX 5.0 (Lenny). Seleccionamos la primera opción para que nuestro servidor de pruebas arranque.

Ahora tenemos nuestro servidor de pruebas listo para comenzar a jugar.

Pero que sucede si nos encontramos con el siguiente problema:

Estamos usando Spring MVC en una aplicación web pero nos vemos obligados a implementar un Servlet. Dentro de este Servlet tenemos que invocar a un Service que ya esta siendo administrado por el contexto de Spring.

El consejo del bug killer puede llevarnos por dos caminos en este escenario:

• No buscar en internet a profundidad, ni preguntar y usar la solución más rápida que se te venga a la mente.
• Seguir el buen diseño y obtener una referencia al Service administrado por Spring.

En el primer caso tendríamos un Servlet implementado de la siguiente manera:

public class DummyServlet extends HttpServlet {
 private static final long serialVersionUID = 1L;

 public DummyServlet() {
   super();
 }

 @Override
 protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
   DummyService service = new DummyServiceImpl();
   resp.getWriter().print(bean.getMessage());
 }
}

¡Esta instanciando la implementación del Service directamente!,… esto puede traer serios problemas si se tiene que cambiar el DummyServiceImpl por otro en un futuro próximo o lejano. Lo más probable es que no se actualice el Servlet y se presente un comportamiento no esperado del sistema.

En el segundo caso, usaríamos las mismas clases de Spring para obtener una referencia al Service:

public class DummyServlet extends HttpServlet {
 private static final long serialVersionUID = 1L;

 public DummyServlet() {
   super();
 }

 @Override
 protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
   WebApplicationContext applicationContext = ContextLoader.getCurrentWebApplicationContext();
   DummyService service = (DummyService) applicationContext.getBean("DummyService");
   resp.getWriter().print(bean.getMessage());
 }
}

Manteniendo de esa manera el diseño y el patrón de inyección de dependiencias.

Happy Hacking!

UPDATE: Para simplificar el ejemplo de este articulo solo se instancia el Service en el Servlet pero debemos tener en cuenta que el Service puede depender de clases DAO o puede necesitar AOP. Esto agravaría más los problemas de instanciar una clase que ya esta siendo manejada por el contenedor IoC.

Ya no sería necesario llamar a los Bug Killers (*), ¿quienes son?, son aquellos miembros del equipo de desarrollo de software que:

• Por saber un poco más.
• Por saber buscar con criterio en google.
• Por saber preguntar (en listas, foros, etc).
• Por tener un poco más de sentido común (algo que es poco común).
• Por haber aprendido de sus experiencias pasadas. Por recordar sus malas y buenas experiencias.
• Por tener paciencia, perseverancia aunque a veces creo que es terquedad y orgullo.

Tienen el encargo de encontrar solución a toda clase de enigmáticos problemas que se presentan en el día a día y más aún en el pico más alto del crunch time. Algunos de ellos reciben el título de arquitecto de software pero no implica que todos los arquitectos de software sean bug killers!

No es una tarea fácil la que tienen que realizar porque la consigna es solucionar el problema si o si!. Es en este punto donde podemos encontrar dos tipos de bug killers:

• Los que prefieren mantener un diseño o solución elegante porque entienden que el desarrollo de software es un arte y buscan mantener la belleza.
• Los que buscan soluciones rápidas y no les interesa mantener la elegancia o el diseño. Son los que prefieren aplicar hacks malogrados, chiches (**), hardcodes o como quieran llamarlo.

Obviamente los resultados de las decisiones de los bug killers pueden causar el sufrimiento, desdicha de los programadores del proyecto o de los futuros programadores cuando se modifique o actualice el software. Por ello, es importante saber antes de aceptar una solución saber con que tipo de bug killer estas tratando, es más, debería ser considerada una tarea de alto riesgo en el proyecto identificar al bug killer idóneo.

¿Qué tipo de bug killer eres?

(*) Algunos también los llaman bomberos porque apagan incendios, no estoy tan de acuerdo con ello porque algunas veces el bug killer solo encuentra una solución (la manera de matar el bicho) y otros la implementan así que no se acerca al fuego del desarrollo de software.

(**) Debo aclarar que no todos los Chichos hacen chiches o por lo menos eso quiero creer.

So, why do I decide to take a PMI© Certification course?,.. well, I wanted to know more about PMI©, learn from it, modify it, adapt it to agile practices and write about everything I disagree/agree with. I just want challenge myself!

The course was divided in sections, one for each PMBOK© chapter. So I can read each chapter before class and prepare questions or topics for discussion in class. Yeah, that will be fun!

Well, as part of the Certification course my group has to develop all the documentation for a software development project reusing some templates that we received in the first day of class. This week, we had the first preliminary presentation of Project Charter and Preliminary Project Scope Statement documents. While I was looking the Preliminary Project Scope Statement template, I had a doubt about project phases because the template assumes sequential project phases and my partners defined them as: analisys, desing, implementatión, testing. OMG that’s waterfall!!!

I asked about how can I show clearly that I’m following an iterative process in the Preliminary Project Scope Statement but I didn’t receive a clear answer. Someone told me that PMBOK© assumes that project phases are sequential. Argggg!,… waterfall!!!

At night, taking a closer look in Chapter 2 – Section 2.1.2 – 3rd Paragraph, I found that PMBOK© uses as example an information technology project with iterative project life cycle!. In conclusion, PMBOK© assumes that most of the projects have sequential phases but there are exceptions like information technology projects using an iterative life cycle.

So it could be interesting to develop a template for Preliminary Project Scope Statements that assumes parallel and sequential phases and a mix of them.

¿Por qué llegan la mayoría de proyectos al Crunch Time? Hay diferentes razones y entre ellas podría mencionar:

• Mala definición del alcance del proyecto: Si al definir el alcance del proyecto solo intervienen los vendedores, el cliente y el jefe de proyecto entonces todo saldrá mal. Los vendedores solo quieren vender y tienen de bajar tiempos, recursos con el fin de vender aun así sepan lo que pasará. Los clientes muchas veces no saben lo que quieren o quieren algo que es imposible realizar con el tiempo y dinero que pueden invertir. Los jefes de proyecto por lo normal tampoco saben de tecnologías y no piden un juicio experto (consultan al arquitecto de software)
• Mala estimación de tiempos: Tiene que ver mucho con lo anterior. El cliente quiere que todo sea rápido. El vendedor promete un tiempo para convencer al cliente sin consultar si es viable. El jefe de proyecto trata de cumplir con lo imposible porque ya todo esta bajo contrato, etc.
• Mala estimación de cantidad de recursos: A menos recursos más ganancia (vendedor), menos costo (cliente). El jefe de proyecto tendrá que exigir más y más al equipo.
• Over-engineering: Hacer más de lo que necesita el cliente, un ejemplo clásico es tratar de hacer un sistema extremadamente flexible. Al final el cliente nunca necesitará aprovechar esa extrema flexibilidad y peor aún esa flexibilidad no funciona correctamente.

¿Que resultado obtendremos con esto?

• Un equipo desmotivado y por ende un mal producto
• Un cliente enojado debido a que el tiempo, costo y calidad del producto no es el esperado
• Los miembros del equipo van renunciando, esto lleva a que en el siguiente proyecto se cometan los mismos errores

Y al parecer nadie aprende de estos errores, nadie trata de cambiar:

• Enseñar a los vendedores sobre tecnologías y que siempre consulten al arquitecto de software
• El arquitecto de software debe lo suficientemente fuerte para poder decir las cosas como son y no callar
• Presentar al cliente opciones factibles/reales para solucionar sus necesidades. Si quiere menos costo o tiempo disminuir las funcionalidades para mantener la calidad del producto. De que le sirve al cliente un producto que se entrego a tiempo y con los costos exactos y no es de buena calidad. Tarde o temprano el producto será más y más costoso para el cliente.
• El jefe de proyecto debe negociar y no tratar de cumplir por cumplir
• Documentar las experiencias adquiridas sean buenas o malas para tomarlas en cuenta en los siguientes proyectos

Y mi recomendación final: Digan NO al Crunch Time!!!! o cobren mucho mucho mucho mas!!!!

Dedicado a mis amigos que en estos
momentos están en Cruch Time.

Estas seguro que el Perú esta preparado para saber lo que realmente tiene que hacer un arquitecto de software

Wow!, nunca lo había planteado en esos términos pero si estoy convencido que hay mucho por mejorar y replantear respecto al rol del arquitecto de software en el Perú. No hay un consenso generalizado sobre este tema, en ningún lado y menos espero lo que lo haya en el Perú.

Este tema va a ser muy interesante para un podcast y mucho mejor si los participantes no comparten las mismas ideas. Pero lo primero lo primero, dentro de unas horas voy a publicar el tercer episodio de modlost.net radio, luego me concentraré en el podcast de arquitectura y haré un post preliminar para calentar la discusión.

Hay diferentes formas de ver la programación:

• Como algo que no te gusta pero tienes que hacerlo porque esta en tu curricula.
• Como algo que no te gusta pero tienes que hacerlo para luego poder comenzar como programador pero dejarlo lo mas pronto posible para poder luego postular por un puesto de analista programador, analista, jefe de proyecto, etc.
• Como algo que no te apasiona pero que tampoco te parece terrible hacerlo.
• Como algo que te apasiona y te interesa aprender más y más.
• Como un arte.

Este artículo va orientado para todos los apasionados por la programación y mas aun para los que ven la programación como un arte.

Las buenas practicas en programación han ido cambiando o adecuándose a través de los años con el nacimiento de nuevas tecnologías, nuevas técnicas y las nuevas necesidades. Lamentablemente muchos de los malos hábitos perduran y complican innecesariamente el desarrollo de software en la actualidad. En este artículo enumerare solo algunos de ellos y propondré que buenas practicas o técnicas se deberían seguir.

1. Nunca borres código! Solo tienes que comentarlo porque no sabes cuando lo necesitaras.

En este caso el programador cree ser clarividente, pitoniso, chaman o brujo. Luego de una serie de visiones tiene claro que va a necesitar mantener algún rastro del estado actual del código y no ha encontrado mejor solución que comentar el código que modificara (ya se de el o de otro). Continuará lineas mas abajo su trabajo, contento y feliz que su futuro sera mas tranquilo.

El programador tiene temor de modificar el código ya sea por que es novato o por malas experiencias anteriores. Por ello, trata de dejar un rastro del código anterior sin saber que este mal hábito iniciará o continuará el desorden y hará el código más y más difícil de entender.

Para dejar este mal hábito es necesario mejorar el autoestima del programador, tienen que confiar en si mismos!. Como apoyo, el histórico de los cambios al código debe ser gestionado por un controlador de versiones y se puede complementar con el uso de test cases para probar automáticamente el código y estar seguro de que los cambios que se hagan no afecten al sistema.

Dejar este mal hábito es difícil.

2. Imprime logs, más logs, más logs hasta que encuentres el problema.

En este caso el programador esta tan paranoico (debido al stress, sobre tiempo, etc, etc) que comienza a dudar de todo cuando no funciona algo en lo que esta trabajando. A veces dudan del IDE o del compilador o creen que por alguna razón mágica el string que contiene el password del usuario cambia y no por eso lo imprimen a cada rato. También hay casos donde los programadores liberan sus tensiones, frustraciones, odios a la empresa donde trabaja a través de mensajes sórdidos o sarcásticos en los logs. En casos muy extremos se encuentran tantas lineas de código de negocio que lineas de código para imprimir logs.

El programador esta utilizando una de las técnicas más antiguas de debugging: imprimir mensajes a stdout, stderr o a un archivo. El problema radica en que no eliminan esos logs luego de usarlos ya sea por flojera o porque creen necesitarlo en el futuro. Este mal hábito puede afectar la performance de la aplicación, complicar la administración y detención de problemas en producción, sin mencionar que se ve poco serio un sistema que tenga logs con bromas, insultos, etc.

Para dejar este mal hábito es necesario forzar al programador que borre sus comentarios luego de usarlos. Usar un framework para el manejo de logs es una muy buena opción pero también se debe explicar claramente su uso (por ejemplo: que son los niveles de log, etc.) La raíz de este problema es la necesidad de realizar debug, para ello recomendaría aplicar la técnica “make a test case instead of debugging”.

Dejar este mal hábito es difícil.

3. Funciones, procedimientos ¿para qué?. Todo en un sola función!

En este caso el programador puede tener una afición desmesurada por lo gigantesco, grande o tal vez tiene temor a crear nuevos métodos, clases o peor aún le da flojera crearlos. Muchas veces detrás de este mal hábito esta el deseo del programador de ser el único que sepa como modificar el código o quiere que sufra el siguiente programador que verá su código.

El programador al no aplicar la recomendación de divide y vencerás tendrá que convivir con la complejidad de su código. En el caso de lenguajes orientados a objetos perderá la potencia que le brinda la herencia, polimorfismo, etc. Este mal habito disminuye la calidad del código, dificulta el cambio o mejora del código y hace que el traspaso del conocimiento (de un programador a otro) sea una tarea imposible de realizar de manera satisfactoria.

Para dejar este mal hábito se debe iniciar al programador en Refactoring, Pre-factoring y de ser necesario por intravenosa! Al aprender sobre Refactoring es imposible no aprender también de patrones, asi que es necesario también conocer de patrones, refactorings to patterns, etc. Como técnica avanzadas en este campo tenemos aspect oriented refactorings, database refactorings, html refactorings, etc.

Dejar este mal hábito es difícil.

4. Copy & Paste es tu mejor aliado, úsalo siempre!

En este caso el programador cree que la mejor técnica de re-utilización de código es el famoso “copy & paste” (algunos lo pronuncian como “copy & page”). Esta es la manera mas fácil de complicar el desarrollo no solo para el que lo implementa sino también para los que verán el código fuente durante toda su vida útil. Ya que al copiar código ademas de tener más lugares donde dar mantenimiento también corren el peligro de copiar bugs. Un síntoma común es que si modifican alguna parte del código otro componente se cae!

El programador debe evitar usar “copy & paste” en la mayoría de casos! La re-utilización de código implica también tener un solo lugar donde realizar mejoras y cambios de tal manera que múltiples partes del sistema se puedan beneficiar de dichos cambios. Este mal hábito genera código inmanejable y facilita que surjan bugs, bugs y más bugs!.

Para dejar este mal hábito es necesario que el programador tenga una dieta de “copy & paste” y que aprenda sobre Refactoring y Pre-factoring.

Dejar este mal hábito es muy muy difícil.

I’ve never needed to do that kind of search so I’ve recommended to read find command man page and use regular expressions. At home, I’ve found an nice way to do this task:

modlost@optimus:~/tmp$ mkdir -p testdir/1/2/3
modlost@optimus:~/tmp$ touch testdir/1/withoutdots
modlost@optimus:~/tmp$ touch testdir/1/2/with.dot
modlost@optimus:~/tmp$ touch testdir/1/2/3/withoutdots
modlost@optimus:~/tmp$ find testdir -type f -regex '[^.]*'
testdir/1/2/3/withoutdots
testdir/1/withoutdots