(NOTA: La imagen anterior no muestra ni la mitad del total de las condiciones)

Verdaderamente me causo un gran asombro en mi expresión y ante tal ingenio, magnitud y poder de la condición IF, decidí nombrar a este tipo de patrón de múltiples condicionantes como “Hyper-IF”. En verdad se nota que la persona que realizó la implementación invirtió una gran cantidad de su tiempo ideando, calculando y esforzandose por cubrir todas las posibles combinaciones o variantes, incluso llegue a pensar que erá una especie de ASCII Art y trate de mover la cabeza en varias direcciones con la finalidad de encontrar la figura escondida (ó era una acaso un mensaje cifrado?).

Al parecer los autores intentaban analizar cada uno de los carácteres de una cadena con la finalidad de determinar si son correctos. Al final de mi revisión les mande una serie de recomendaciones y entre ellas les suplicaba que aprendieran el uso de “Expresiones Regulares”.

Finalmente la solución se resolvió en una sola linea de código empleado una expresión regular para verificar carácteres alfanuméricos y final feliz!.

Por favor recuerda que si requieres hacer uso de análisis de cadenas y antes de caer en la implementación de un “Hyper-IF” considera el uso de patrones de expresiones regulares,  te pueden ayudar a simplificar bastante tu código.

Algunas referencias interesantes:

http://www.regular-expressions.info/

http://regexlib.com

Es debido a este andar por varios proyectos que tome la decision de crear mi propio compendio de bloques de códigos “peculiares” (ya sea horrores, antipatrones, etc.) que debido a su estructura y contenido me han causado asombro, lagrimas y con frecuencia risas.

Como elemento de inicio he seleccionado el siguiente patrón de código que he denominado “Double Play Try/Catch”, y para tratar de explicarlo una breve introducción:

Imagina a un desarrollador al que se le asigna agregar el manejo de excepciones a un bloque de código y con base a su gran “iniciativa” ha decidido hacer una implementación tratando de aplicar las “Best Practices” que leyó en alguna revista. Una vez puestas las manos en marcha realiza la implementación logrando con ello algo muy parecido a lo siguiente:

MyFunction(…)
Try
something()
Catch Exception ex
Throw ex

Al final sin querer el desarrollador termina aplicando un antipatrón que en mi caso he nombrado el “Double Play Try /Catch”. El nombre lo he tomado de una famosa jugada del Béisbol conocida como el DOUBLE PLAY, en donde dos jugadores de ofensiva son puestos OUT al momento de una jugada continua (aunque en nuestro ejemplo parece ser que el out es así mismo).

Para el caso del bloque de código anterior, en el manejo de excepciones implementado se “atrapa” una excepción en la primer sentencia Catch (Primer OUT) y se decide volver a lanzar nuevamente la misma excepción, esperando que en algún punto más adelante se logre atrapar nuevamente a dicha excepción (Segundo OUT) y DOUBLE PLAY!.

Con lo anterior, es por demás decir que se trata de un manejo totalmente INCORRECTO de las excepciones y debido a su estructura y logica? simplemente no tuvo ningún caso el bloque Try/Catch.

La generación de una excepción tiene un costo ALTO en el procesamiento y performance de las aplicaciones; por tanto es muy importante tener mucho cuidado al momento de aplicar un manejo adecuado y tomar en cuenta las siguientes consideraciones:

a) Agregar un manejo de excepciones no es una cuestión de performance, solo de buenas costumbres al momento de prevenir flujos excepcionales, pero como todo en EXCESO puedo ser contraproducente.

b) El manejo de excepciones debe de proporcionar información detallada sobre los síntomas que provocan el flujo Excepcional, con la intención de ofrecer alternativas sobre como intentar reaccionar a ellas, el simple hecho de colocar un bloque Try/Catch no soluciona nada.

c) Las excepciones tienen un impacto en el performance y por tanto no es conveniente tratarlas como un mecanismo de decisión en la lógica de procesamiento!, en cuanto te sea posible mejor evitarlas.

Finalmente algunos recursos que permiten explicar el costo de las excepciones y algunas buenas recomendaciones sobre su manejo:

- Design Guidelines: Exception Throwing por Krzysztof Cwalina

- Error Handling

- When you can´t throw an exception

En fin, conforme vaya recordando vivencias o encontrando en mi recorrido algunos bloques de código “interesantes” por supuesto que los intentare clasificar y anexar a este compendio.

 

“Addison-Wesley has published a new book. It’s by Robert Daigneau and it’s called Service Design Patterns. It’s a topic that’s already had too many books on it, but I added this one to the series because I think Robert has done a particularly good job of collecting together the best advice on the topic and organizing it into a useful handbook. This is the book that I think ought to become the standard book on the topic.”

 

(Via Martin Fowler’s Bliki)

El soporte de NTFS no se encuentra habilitado por default y para activarlo hay que realizar los siguientes pasos:

1. Abrir una instancia de “Terminal” y escribir el comando diskutil info /Volumnes/<VOLUME-EXTERNO>, en donde VOLUME-EXTERNO es el nombre de la partición NTFS.

2. Con la información resultante copiar los datos de la sección Volume UUID

3. Escribir el comando sudo nano /etc/fstab

4. Una vez dentro del editor, escribir UUID = y en seguida copiar la información de Volume UUID del paso 2, agregar un espacio en blanco y escribir none ntfs rw. El resultado final deberá ser muy parecido a: UUID=9999-9999-999 none ntfs rw.

5. Guardar los cambios en el archivo y quitar nano (Control-X, Y, ENTER).

6. Reiniciar el equipo.

Una vez realizado los pasos anteriores se podrá tener acceso de lectura y escritura a particiones o unidades externas con formato NTFS.

Dentro de los dispositivos que soportan esta comunicación se encuentra Apple TV, pero para los que aun no somos afortunados en tener uno, existe una forma de emplear nuestra Mac como una pantalla de “AppleTV”, como se logra esto?..muy fácil mediante “AirPlayer“, esta aplicación para MacOSX  permite crear un servicio que emula un “Apple TV” en nuestra Mac de forma que cualquier iDevice (dispositivo basado en iOS) pueda transmitir información directamente hacia la Mac.

La aplicación esta disponible de forma libre en esta ruta, además de ser un excelente “Hack”!.

Así que los pasos son los siguientes:
1. Instalar Hotspot Shield (existen versiones para PC y Mac). una vez instalado se mostrará un icono en la barra de menús de MacOS.

2. Presionar la opción “Connect” de Hotspot Shield y aparecerá una página con la confirmación de la conexión.

3. Entrar a Boxee y en “TV Shows” ingresar a la librería de canales, seleccionar una serie que se muestre en un servicio de EU (casi todas) y ver el contenido.

4. Listo funciona a la perfección.

Espero sea de utilidad, creo que el mismo procedimiento también funciona para PC/Windows.

“.objc_class_name_PTHotKey”, referenced from: literal-pointer@__OBJC@__cls_refs@PTHotKey in PomodoroController.o

“.objc_class_name_PTHotKeyCenter”, referenced from: literal-pointer@__OBJC@__cls_refs@PTHotKeyCenter in PomodoroController.o

ld: symbol(s) not found collect2: ld returned 1 exit status

simplemente WTF! parece una grosería del compilador!!

Después de pasar un muy buen rato investigando sobre este tipo de errores, que por equivocación se los atribuía al compilador, encontré en la ayuda de Apple y foros de que este error es ocasionado por el Linker al momento de ensamblar la aplicación y se debe a que en el código fuente se hace referencia a clases que no se encuentran incluidas en XCode, por ejemplo mediante #import, pero que probablemente físicamente existan en la ruta del proyecto pero no en XCode, por lo que no se encuentran los símbolos que requiere el Linker en el armado de la aplicación.

Por tanto la solución para esta situación es:

1. Agregar los archivos faltantes a XCode en la sección “Classes”.
2. En los “Targets” del proyecto agregar en “Compile Sources” los archivos faltantes agregado en el paso 1.
3. Aplicar un “Clean” / “Clean All Targets”.
4. Compilar la aplicación y listo!

Espero que este Tip sirva, ya que es poca la información que existe al respecto!

Las experiencias que durante este tiempo considero las más importantes las puedo listar a continuación:

1. Estabilidad emocional, muy importante para haber superado los inconvenientes que se presentaron en todo el año y que fueron bastantes y complicados. Mi familia cada vez más unida.

2. Haber participado en proyectos profesionales que han sido por demás interesantes y con grandes retos, me siento cada vez más confiado de mis conocimientos!.

3. A pesar de ser un año de crisis económicas y sociales alrededor del mundo y muy marcadas en mi país, México, puedo decir que he podido pasarlo sin ningún apuro y gracias a Dios sin ninguna situación critica.

4. Durante este año he perdido a 5 familiares de los cuales 2 me han dejado muy marcado debido al aprecio que les tenía.

5. Haber completado la certificación MCPD Enterprise para Framework 3.5 en menos de 4 meses todo un reto el estudio!

Con respecto a mis propósitos de este año, creo que ninguno pude cumplir, más sin embargo se presentaron otros que ni siquiera tenia contemplado, así que llego a la conclusión de que no sirve hacer listas de cosas que esperamos algún día cumplir, las metas a muy corto plazo con más seguras de completar!.

Al parecer el año siguiente nos presenta una nueva serie de retos, más impuestos,más inseguridad, etc. pero la verdad me siento confiado de que a pesar del panorama será un muy buen año!, así que a mis lectores, amigos, conocidos o cualquiera que lea este post, le pido que sea feliz este nuevo año 2010, que lo afronte con la esperanza de hacer de este mundo un lugar mejor, que sea mejor vecino, mejor amigo, mejor ser humano y que se cumplan sus metas (personales y profesionales), y recuerden que los deseos uno es el que trabajo para cumplirlos con el dia a dia!.

God Bles you! and Happy New Year 2010!

Durante este lapso pude darme cuenta de diferentes aspectos, al menos en mi caso me llamaron bastante mi atención:

a) Crear una comunidad requieren de convocar a personas con interes en común.
b) Es difícil encontrar personas dispuestas a invertir tiempo en la organización o que quieran participar.
c) Muchos se aburren rápidamente o pierden el interes sin proponer nada.
d) La más importantes: No sabemos participar o integrarnos a comunidades!.

Tomo el último punto para detallar mi perspectiva con respecto a las comunidades en nuestra cultura, una vez que me toco vivir lo que significa el crear una comunidad pude comprender muchas de las dificultades a las cuales toca enfrentarse y creo que muchas de las complicaciones son más de cultural que lo vuelve algo complicado y de mucha dedicación.

Primero en ocasiones (por no mencionar muy generalmente) se tiende a mal entender el propósito de las comunidades (cualquiera que sea el tema, en mi caso se refiero a las comunidades de desarrollo de software), muchas veces los asistentes solo logran sentirse atraídos solo si escuchan que por presentarse van a recibir regalos a cambio (comida, revistas, DVD, libros, etc), cuando el simple hecho de compartir conocimientos ya significa regalar algo!.

En otras ocasiones muchos van por “echar la fiesta” ó pasar un momento con los cuates, sin importar los temas a tratar y finalmente después de ir una o dos veces se olvidan o se aburren de la comunidad!.

Ante lo anterior me pregunto entonces: En verdad sabemos integrarnos a comunidades?

Si reviso la descripción de Comunidad en Wikipedia encuentro:

“Una comunidad es un grupo o conjunto de individuos, seres humanos, o de animales que comparten elementos en común, tales como un idioma, costumbres, valores, tareas, visión del mundo, edad, ubicación geográfica (un barrio por ejemplo), estatus social, roles. Por lo general en una comunidad se crea una identidad común, mediante la diferenciación de otros grupos…..”

Desde esa perspectiva, ¿Resulta importante reservarse el derecho sobre quienes deberían de integrar una comunidad? a fin de que los integrantes compartan los mismo intereses en común y preservar su identidad?.

Incluso si revisamos a nivel internacional, cuando alguien se muda a vivir a otro país se tiende a buscar comunidades de la misma nacionalidad en busca de apoyo, compañía y ayuda, entonces porque nosotros no sabemos integrarnos así?

Tratar de encontrar las razones llevaría a intentar analizar un sin fin de motivos (ideologías, cultura, personalidad, etc, etc, etc….), más a pesar de lo anterior no me desanimo en conformar una, yo creo que aunque se cuente únicamente con 3 personas, significa un avance siempre y cuando sea uno constante, no tanto un compromiso pero si disposición y creo que un mucho de vocación por enseñar!, así que si alguien pretende pertenecer a una comunidad de desarrollo le recomiendo lo siguiente:

1. Disposición a participar.
2. Invertir tiempo personal en aprender (muy importante!).
3. Proponer y cuestionar, proporcionar retroalimentación.
4. No esperar regalos a cambio!.

Creo que es importante procurar ser participativos, buscar compartir el saber y no ser celosos de nuestros conocimientos, siempre va a existir alguien que le interese lo que sabemos o que le sirva para solucionar algún problema.

Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 2355240 bytes) in /home/mysite/public_html/wp-includes/http.php on line 133X.

El problema se debe principalmente a que algunos plug-in instalados no sean completamente soportados por WP o requieren de configuración adicional, para continuar unicamente se deben de desactivar todos los plug-in y ejecutar nuevamente la actualización automática, una vez finalizado el proceso se deben de activar los plug-in que se requieren.

Espero que este tip sea de utilidad, en mi caso me salvo del clásico WP Upgrade.

Volviendo al inicio (“bottom line”), en una reciente plática con un equipo de trabajo, se estaba discutiendo el tema de las pruebas unitarias y el cómo se van a emplear en el proyecto, algunos mencionaron que nunca las habían empleado, otros habían solo leído o escuchado sobre de ellas y otros decían que tenían amplia experiencia y que incluso habían aplicado TDD (Test-Driven Development)…interesante punto!

Cuando les pedía a los que “habían” empleado TDD comentarán sobre sus experiencias y utilidad, surgieron los siguientes puntos:

-          Comentaban que su tiempo de implementación alargaba en tiempo de desarrollo del proyecto.

-          Que se hacía complicado cumplir con las coberturas de código.

-          Al final terminaban haciendo muchas pruebas unitarias.

-          Que el IDE ya generaba automáticamente las pruebas y aplicaba el TDD…..?

Después de escuchar los comentarios no pude evitar comentar: hacer pruebas unitarias NO es aplicar TDD!, decirle a un Wizard que tome nuestros componente y automáticamente genere las pruebas unitarias NO es TDD!. Muchas veces no se logran comprender los verdaderos beneficios (o desventajas) de aplicar tal o cual práctica ó nos mal acostumbramos al flujo de trabajo que sigue cierta herramienta y creemos que así es como esta se aplica (todo gracias a la mercadotecnia!).

TDD es una práctica que se encuentra enfocada en aplicar dos principios básicos: Escribir primero las pruebas unitarias  y Refactoring de código. Para la definición de las pruebas unitarias se requiere tener claramente definidos los requerimientos (punto importante!), y una vez que se tengan claros aplicar los siguientes puntos:

a)      Tomar un requerimiento (con su respectivo caso de uso) que sea factible de iniciar su implementación o que sea más representativo.

b)      Definir la prueba unitaria con un nombre que describe el requerimiento.

Ejemplo:  IniciarSesiónConTokenDeSeguridadTest().

c)       Verificar que la prueba falla, se supone que en un principio esta se encuentra vacía y no tiene código.

d)      Implementar la prueba unitaria, es decir empezar a codificar a fin de realizar la implementación que cumpla con el propósito de la prueba unitaria.

e)      Ejecutar la prueba unitaria y verificar que funcione.

f)       Aplicar refactoring del código a fin de eliminar redundancias y reducir la implementación.

g)      Opcionalmente detectar posibles comportamientos que no se encontraban claramente especificados en el requerimiento implementado.

Revisando los puntos anteriores, el uso de este tipo de prácticas permite reducir la cantidad de errores y principalmente, permite al desarrollador confiar en su código al momento de la implementación de las pruebas unitarias, además de que las pruebas permiten mostrar el avance del trabajo y poder  demostrar escenarios de comportamiento que nuestros usuarios puedan revisar de forma simple.

Como toda práctica tiene sus ventajas y desventajas, por lo que su uso debe de estar condicionado a la experiencia de quienes lo van a implementar y se encuentren a gusto con trabajar de este modo. En mi caso lo he aplicado y me ha funcionado bastante bien, pero como siempre en gustos (y prácticas) se rompen géneros!

Lo anterior son una serie de preguntas que en la mayoría de los casos, toman relevancia en los momentos finales del proyecto,  en la entrega del resultado o más aun cuando nuestro cliente dice: “Esto que están entregando no es lo que esperábamos”, clásico pero muy cierto y recurrente.  

Casi siempre se tienda a caer en ambigüedades como querer emplear tecnologías “tan innovadoras” y “tan de moda” llenas de términos “rimbombantes” con tal de impresionar al cliente, es decir un típico escenario de proyecto  “buzzword compliance”: “Si implementamos SOA 2.0 vamos a apuntalar a los equipos de trabajo y capitalizaremos en valor de la empresa”, “Deberíamos subir nuestros servicios a la nube para así migrar todas las aplicaciones para que sean RIA al 100% y sean compatibles con Web 2.0“.

Otro escenario común es cuando en un proyecto nos asignan una pieza “compleja” un: “Generador  de notificaciones asíncronas mediante scheduler para ambiente mutithreading”, el cual debe de finalizarse el 2500 horas, donde dicha pieza fue definida en la etapa de arquitectura del proyecto por el “master architect” de soporte a pre-venta. Después de leer la especificación uno le indica al “manager”: Oye pero el requerimiento indica que el programa solo debe de mandar un correo al administrador cuando llegue un nuevo registro en la base de datos, que no basta con definir un job y ahorrarnos ese tiempo?….les parece familiar? o como decimos por acá, “para que tanto brinco estando el suelo tan parejo”.

Existen aspectos “primordiales”, antes de diseñar o codificar una pieza de software que es importante reflexionar:

a)      ¿Cuál es la finalidad del funcionamiento de esta pieza y quienes la van a utilizar?

b)      ¿Es necesario esta pieza dentro del “todo” del proyecto?

c)       ¿Están definidos y son claros los contratos de los componentes?

d)      ¿Es necesaria TODA la funcionalidad que estoy pensando implementar?

De tal forma que cuando se entregue nuestra pieza esta permita ser medida en función de los requerimientos e integración con los demás componentes, así como la funcionalidad comprendida sea única y estrictamente necesaria, recordar el YAGNI,  y de paso ahorrar tiempo de corregir nuestros errores, perdón mejor dicho “refactoring del código para mejorar performance” suena mejor.

En resumen es importante siempre entregar un resultado que al final genere un “valor” y que cumpla con las expectativas de nuestros usuarios o clientes finales, que los haga sentirse conformes con su inversión y lo consideren como algo “valioso” y “útil” o simplemente “vale la pena su costo”, es importante tener en cuenta que en términos de software es difícil cuantificar su valor.