La falta de recursos es un gran inspirador

Hoy me envio mi padre un forward muy interesante que me gustaría compartirlo, en este mail cuenta tres historias de tres problemas, una con una solución avanzada y otra con una solución sencilla. Aquí las historias.

 

Problema 01

 

Cuando la NASA comenzó con el lanzamiento de astronautas al espacio, descubrieron que los bolígrafos no funcionarían sin gravedad (o con gravedad cero), pues la tinta no bajaría hasta la superficie en que se deseara escribir.

Solución A) Resolver este problema, les llevó 6 años y 12 millones de dólares. Desarrollaron un bolígrafo que funcionaba: bajo gravedad cero, al revés, debajo del agua, prácticamente en cualquier superficie incluyendo cristal y en un rango de temperaturas que iban desde abajo del punto de congelación hasta superar los 300 grados centígrados.

Solución B) ¿Y qué hicieron los rusos? ¡Los rusos utilizaron un lápiz!

Problema 02

Uno de los más memorables casos de estudio de la gestión japonesa fue el caso de la caja de jabón vacía, que ocurrió en una de las más grandes empresas de cosmética de Japón. La compañía recibió la queja de un consumidor que compró una caja de jabón y estaba vacía. Inmediatamente las autoridades aislaron el problema a la cadena de montaje, que transportaba todas las cajas empaquetadas de jabón al departamento de reparto. Por alguna razón, una caja de jabón pasó vacía por la cadena de montaje. Los altos cargos pidieron a sus ingenieros que encontraran una buena y rápida solución del problema.

Solución A) De inmediato, los ingenieros se lanzaron a su labor para idear una máquina de rayos X con monitores de alta resolución manejados por dos personas y así vigilar todas las cajas de jabón que pasaran por la línea para asegurarse de que no fueran vacías. Sin duda, trabajaron duro y rápido.

Solución B) Cuando a un empleado común en una empresa pequeña se le planteó el mismo problema, no entró en complicaciones de rayos X, robots, equipos informáticos o complicados; en lugar de eso planteó otra solución: Compró un potente ventilador industrial y lo apuntó hacia la cadena de montaje. Encendió el ventilador, y mientras cada caja pasaba por el ventilador, las que estaban vacías simplemente salían volando de la línea de producción.

Problema 03

Un magnate hotelero viajo a una ciudad Hindú por segunda vez a un año de distancia de su primer viaje, al llegar al mostrador de un hotel inferior en estrellas a los de su cadena, el empleado le sonríe y lo saluda diciéndole: Bienvenido nuevamente señor, que bueno verlo de vuelta en nuestro hotel; sorprendido en gran manera ya que a pesar de ser una persona tan importante, le gusta el anonimato y difícilmente el empleado tendría tan buena memoria para saber que estuvo allí un año antes, quiso imponer el mismo sistema en su cadena de hoteles ya que ese simple gesto lo hizo sentir muy bien. A su regreso inmediatamente puso a trabajar en este asunto a sus empleados para encontrar una solución a su petición.

Solución A) La solución fue buscar el mejor software con reconocimiento de rostros, base de datos, cámaras especiales, tiempo de respuesta en micro segundos, capacitación a empleados, etc. Etc. Con un costo aproximado de 2.5 millones de dólares.

Solución B) El magnate prefirió viajar nuevamente y sobornar al empleado de aquel hotel para que revelara la tecnología que aplican. El empleado no acepto soborno alguno, sino que humildemente comento al magnate como lo hacían, el dijo: “Mire señor, tenemos un arreglo con los taxistas que lo trajeron hasta acá, ellos le preguntan si ya se ha hospedado en el hotel al cual lo está trayendo, y si es afirmativo, entonces cuando el deja su equipaje aquí en el mostrador, nos hace una señal, y así se gana un dólar”.

Mi conclusión

Podemos sacar miles de conclusiones y moralejas respecto a esto, pero lo primero que se me viene a la mente es la capacidad de la gente que implemento los planes B para hacer algo muy copado, sacrificando a lo mejor algunas features, con muy pocos recursos y llegando prácticamente al mismo objetivo.

Muchas veces nos quejamos de que no contamos con los recursos para poder hacer tal o cual idea y es claro que cuando se quiere se puede, solamente hay que seguir pensando el problema, podar un poco las expectativas y apuntar a un objetivo puntual para lograrlo. No debemos delirar e irnos por las ramas con cosas que verdaderamente no aportan valor a lo que pretendemos solucionar, y lo peor de todos es que estas cosas nos cuestan dinero y tiempo.

Da para pensar dos veces la próxima vez que tengamos un problema en nuestras manos.

Share

Xdebug, Var_dump con Esteroides


Todavía recuerdo la época cuando PHP no tenía Xdebug, cuando andabamos con print_r y echo para poder debugear algo en esos miles y miles de scripts que estaban llenos de includes y requires, haaaa que tiempos, menos mal que ya paso. No voy a contar que es Xdebug por que asumo que ya tenes idea que es, tampoco voy a contarles como instalarlo por que la internet esta llena de artículos sobre ello.

Este articulo va a ir al grano, a como usar cosas mas copadas que solo ver colorcitos en el var_dump y conectarlo con la IDE para hacer un debug paso a paso, vamos a ver algunos puntos que nos pueden ayudar en esos momentos de desesperación en que no podemos encontrar el problema.

Var_dump

Ok, si, lo primero a ver es var_dump, si lo usamos por defecto var dump va mostrar la información de una variable de manera recursiva, el problema es que por defecto PHP trae los errores HTML desactivados, lo primero que deberíamos hacer después de instalar xdebug es setear html_errors en el php.ini en On

html_errors = On

Tambien siendo que esta es una configuración de desarrollo deberíamos habilitar la salida de error.

display_errors = On

Ya que estamos en el php.ini vamos a ver tres parámetros que afectan a Xdebug, estos parámetros afectan la forma que Xdebug presenta la información en el var_dump y en los mensajes de error.

xdebug.var_display_max_depth : Default 3, Cuan profundo se va a buscar atributos. Vean en este ejemplo, un caso esta con profundidad 1 por ende la información aparece muy resumida, el otro esta en 3, podemos ver mas datos. Util para cuando tenemos varios niveles de anidamiento.

Screen Shot 2013-02-20 at 9.14.49 PM

xdebug.var_display_max_children : Default 128, Cuantos atributos del objeto se van mostrar, observen el primer caso, solo muestra un atributo por elemento, en el siguiente caso muestra hasta 128. Util para casos donde el objeto sea muuuy grande.

Screen Shot 2013-02-20 at 9.17.20 PM

xdebug.var_display_max_data : Default 512, cuantos caracteres del string en una variable se van a mostrar. Util para estirar la cadena de caracteres a mostrar cuando necesitamos analizar los textos del las variables.

Screen Shot 2013-02-20 at 9.18.14 PM

xdebug.collect_params=4 : Este parametro permite recolectar datos de las variables y los valores que toma cada invocación a una función, cuando salte un error o hagamos un trace podremos ver estos valores reflejados en el stack trace. Por defecto esta en 0 (no colecta nada), a mi personalmente me gusta 4.

Bien, ahora sabemos como customizar nuestro var_dump para casos extremos donde no estamos viendo lo que necesitamos.

Otras Funciones

Si queremos ver un poco mas de información, por ejemplo cuando trabajamos con variables por referencia, podemos usar la funcion xdebug_debug_zval, esta recibe como parámetro el nombre de la variable a mostrar y ademas de la información que nos provee var_dumpo nos muestra información de refcount (cuantas variables apuntan a este valor) y si es una referencia. Este es un ejemplo de una salida de xdebug_debug_zval.

Screen Shot 2013-02-20 at 9.27.49 PM

Otra función muy útil es xdebug_dump_superglobals, esta nos dumpea el valor de las variables super globales, pero para hacerla funcionar correctamente necesita una configuración para indicar que variables queremos ver exactamente, esta configuracion se puede hacer en el php.ini, .htaccess o via ini_set, este es un ejemplo bastante práctico.

   xdebug.dump.GET=*
   xdebug.dump.POST=*
   xdebug.dump.COOKIE=*
   xdebug.dump.SERVER=SCRIPT_FILENAME,REMOTE_ADDR

Es es un ejemplo de la salida

Screen Shot 2013-02-20 at 9.27.40 PM

Configuraciones Útiles

Lo interesante es tener esta información de las super globales y de los parámetros que se pasaron a las funciones del stack trace cuando surja un mensaje de error. Si usamos esta configuracion, o similar,

 xdebug.show_local_vars=On ;Muestra las variables locales del ultimo scope
 xdebug.dump.SERVER=HTTP_HOST, SERVER_NAME ;Configuracion para dump_super global
 xdebug.dump_globals=On
 xdebug.collect_params=4

podremos tener una salida de error como la de la imagen

var_dump_full

La teoría dice que las variables superglobales, salvo la de SESSION, no debería cambiar durante la ejecución, por ende Xdebug por defecto muestra estas globales solo en el primer error para no ser tan verboso, si quieren que siempre se muestren pueden cambiar poner en off dump_once.

xdebug.dump_once=Off

Algo que suele ser interesante tambien es poder ver el stack trace cuando surge una excepcion, el problema es que las exceciones en PHP no son manejadas de la misma forma que los errores, ahora, si queremos que Xdebug no alerte en cada excepcion que suceda, capturada o no, podemos usar esta variable de configuracion.

xdebug.show_exception_trace=On

Conclusión

Estas son algunas de las cosas avanzadas que pude ver para obtener mejores mensajes de error y tener un poco mas de información en el var_dump, pero en realidad lo que me llevo a ver esto es que me puse a ver como hacer un poco mas completo los traces para poder ser mas efectivo debugeando, nunca fuí fan del Paso a Paso para debugear, asi que el próximo articulo estará relacionado a como hacer traces efectivos en PHP con Xdebug para un mejor debugging.

Para los curiosos, aca esta la doc oficial

http://xdebug.org/docs/

Share

Sitios para compartir archivos sin registracion

Van un par de links para sitios que permiten subir un archivo por X tiempo y sharearlo con otras personas, el bonus es que no necesita registración.

- Wikisend: Permite subir hasta 100MB, el archivo estará disponible por 7 días, permite añadir password al archivo.

- StreamFile: Permite archivos de 150MB, estará disponible por 24.

- GE.TT: Permite subir archivos de 250MB, estará diponible 30 días.

- LargeFilesASAP: Soporta archivos de 2GB, solo permite una descarga, el archivo estará disponible por 72hs.

Buenos servicios si queremos pasar algo rápido a otra persona que esta lejos y nuestro proxy corporativo bloquea DropBox :)

Share

Escucharon hablar PSR ?

ooxml-isoHace unos años atras me uni a un grupo de google llamado php-fig, este grupo pretendía definir estándares de desarrollo para la comunidad PHP con el ánimo de unificar el ecosistema de frameworks, librerías, componentes y aplicaciones desarrolladas en PHP.

Hoy leí este articulo que me parece muy bueno y decidí escribir sobre lo mismo para transmitir esta información y ademas añadirle un poco de mis condimentos.

Este grupo esta formado por los referentes mas influentes de la comunidad PHP al momento y estos no pretenden imponer la forma de trabajar pero proponen buenas prácticas y lineamientos a seguir en pos de lograr una estandarización, reutilización de componentes y quien dice, hasta dejar de inventar la rueda todas las veces; es por eso que PSR es la sigla de PHP Standards Recommendation, y el grupo se llama PHP Fig donde Fig viene de la sigla Framework Interoperability Group.

Ellos básicamente discuten temas de importancia en un la lista de correo, aceptan opiniones de gente externa a los miembros votantes, y luego los miembros votantes deciden votando la mejor alternativa.

El primer tópico a discutir fue como implementar un autoloader estándar que pueda levantar cualquier clase de cualquier librería sin muchas complicaciones y evitando tener un autoloader por cada librería que incorporemos a nuestro desarrollo (los que trabajaron con __autoload y spl_autoload_register saben el calvario que es esto). Con este topico implementaron el PSR-0, el cual fue adoptado en principio por Symfony 2 y hoy en día es el corazón de composer.

Después liberaron dos estándares mas, el PSR-1 y el PSR-2 los cuales están referidos a coding standars, si vos formas parte de una empresa de desarrollo que trabaja en PHP deberían comenzar a implementarlo.

Hace muy poco sacaron a la luz el estándar para una interfaz de logeo, PSR-3, esta va a ser la base (de hecho esta muy inspirada) para Monolog.

Ahora están discutiendo como implementar un manejo estándar para el paquete HTTP y como implementar una interfaz estándar para manejo de Caches.

Personalmente me agrada muchísimo este tipo de actividades, lo bueno es que existe algo para los que aman la interoperabilidad entre componentes aceptado en consenso por gente que la tiene muy clara y que lo hace solo por el mero interes de hacer las cosas bien, no por un interes comercial o bajo alguna presión monetaria. Por el otro lado, si bien podes estar o no de acuerdo con las propuestas podes simplemente ignorarlas y hacer lo que te parece, lamentablemente el mercado si adopta las proposals te va a exigir a que vos tambien las implementes, pero eso es al margen.

Mi recomendación es que visiten el grupo, lean las conversaciones, traten de implementar las recomendaciones en sus implementaciones y si pueden hasta deberían participar opinando (a conciencia obviamente).

Les dejo un par de links interesantes para que se metan un poco mas en el tema.

https://groups.google.com/forum/#!forum/php-fig

https://github.com/php-fig/fig-standards

https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-0.md

https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-1-basic-coding-standard.md

https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-2-coding-style-guide.md

https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-3-logger-interface.md

http://net.tutsplus.com/tutorials/php/psr-huh/

Share

Haciendo valer el Budget de un proyecto

Al señor este, Casey Neistat, Nike le entrego un proyecto para hacer una propaganda de un producto y el flaco se mando 10 días con un amigo a recorrer el mundo con el budget del proyecto, con las filmaciones del viaje produjo este video.

Desde mi punto de vista lo único que tengo para decir, sos groso sabelo, la propaganda esta genial y el flaco la paso bomba, a eso llamo hacer valer la guita.

Share

Meetings, usese con precaución, mantengase alejado de los niños

Últimamente vengo leyendo en varios lados críticas muy fuertes hacias las meetings señalandolas como grandes agujeros negros que se consumen toda la productividad, obviamente estoy de acuerdo con dichos artículos dado que cotidianamente sufro perdidas de tiempo importantes en meetings sin sentido que apoyan poco y nada a la productividad de los participantes.

Si uno piensa detenidamente el ideal de las meetings no es malo, debería ser un intervalo de tiempo donde todos los involucrados sincronizan y discuten una idea (o varias) para ponerse de acuerdo y continuar con sus trabajos. Hasta aquí fantástico, es algo muy óptimo y mucho mas rápido que estar escribiendo miles de líneas en un chat o respondiendo cadenas interminables de emails.

Entonces, cual es el problema con las mismas ?, de mi experiencia diaria y de leer varias experiencias ajenas, puedo identificar varios factores que afectan al beneficio que uno pretende obtener de una meeting.

El primero de ellos es que los managers (principales generadores de meetings) son Meetings Dependientes, ante cualquier duda pretenden crear meetings dado que la mayoría de ellos estan incapacitados para tomar desiciones por si mismos, necesitan la colaboración de las personas con las que trabaja para tomar sus desiciones. El problema es que abusan de las reuniones para obtener la información que necesita. Estas personas deberían utilizar algunos caminos alternativos para evitar realizar meetings, algunos de ellos serían

- Ponerse en contacto individualmente con los miembros del equipo para evacuar sus dudas (Via mail, chat, teléfono).

- Evitar la reincidencia, no preguntar varias veces lo mismo, una vez resuelto un tema recordar la solución y no volver a preguntarlo.

- Llevar notas de lo hablado, asi cuando surja una duda sobre algo ya hablado se puede volver a los logs anteriores.

- En caso de tener que preguntar, formar bien la pregunta, ser breve, ir al grano, aceptar las respuestas como son y no ser inquisitivo para escuchar lo tiene ganas de escuchar.

Otro de los focos generadores de meetings es la necesidad de saber donde estamos parados, la necesidad de tener visibilidad. Para solventar esta cuestion el manager debe contar con herramientas de gestion para poder determinar en cualquier momento, en cualquier lugar, sin necesidad de preguntar a nadie, donde estamos parados. Un manager que incansantemente pregunta donde estamos es un mal manager, no sabe realizar un trabajo de seguimiento. Para saber esto el manager debe definirse un proceso para obtener esta información (llamese usar Jira, Trac, Mantis, Actualizar una planilla, realizar envios diarios de mail con el avance, o lo que sea) sin necesidad de caer en meetings interminables.

El tercer generador de meetings es el cliente, este tiene incertidumbre, quiere saber donde esta el proyecto en todo momento, siempre tiene dudas, nuevas ideas, miedos, cosas que identifica sobre la marcha y desea revisar, y lo mas importante, todo es urgente, por ende todo termina en una meeting. Para esto debemos aplicar gestion sobre nuestro cliente y acostumbrarlo que NO todo es importante, a que utilice mails para enviar consultas y sepa esperar respuestas, debemos ser proactivos y tratar de identificar las necesidad del cliente antes que lo pida y sobre todo, ser claros con las comunicaciones que enviamos al mismo, tener un dialogo e interlocutores unificados para evitar doble discurso y confusiones.

El último factor que identifico son nuestros pares del equipo, ellos necesitan saber que estamos haciendo, como lo estamos haciendo, que vamos a hacer después, suelen necesitar ayuda, suelen necesitar orientación, etc. El primero paso aquí creo que es tratar de alentar al equipo a ser independiente, que sepa leer código, que sepa googlear las soluciones, que sepa pensar por si solo. El seguno paso es tratar de documentar los trabajos, pero sin generar documentos muertos, docuemntar solo lo importante, de manera breve, corta, consisa y si se puede con un gráfico que acompañe. Por último, es comunicarse casi casi de modo offline, para esto lo mejor que vi hasta ahora es usar alguna herramienta de chat compartido tipo los grupos de Skype, esto ayuda bastante a agilizar la comunicación sin necesidad de una respuesta inmediata.

A que quiero llegar con esto, a que debemos orientarnos a no ser dependientes de las meetings, a tratar de buscar alternativas de comunicación, usar herramientas de soporte, a tomar la información cuando esta disponible y depender de una meeting para adquirirla, a ser autonomos sin dejar de formar parte del team, a poder ser objetivos y determinar claramente cuando algo es urgente y cuando no, ser objetivo para determinar quien puede darnos la información que requerimos sin necesidad de molestar a todo el team.

Bien, ahora como bien sabemos nunca vamos a poder escapar 100% de las meetings, podemos llegar a trabajar con un equipo excelente, un manager clarividente que ve mas alla de lo evidente, clientes super piolas que confian en nosotros, etc, igualmente tarde o temprano vamos a tener meetings. Por ende, es bueno tener estos tips que rejunte de varios posts para tener meetings efectivas, y quien dice, capaz que no nos afecta tanto si los aplicamos bien.

- Agendar meetings por la tarde, la mañana suele ser el momento con mas capacidad para trabajar, no lo desperdicie en meetings

- Preguntar siempre

por que esta meeting ?
por que debo estar yo en esta meeting ?

si no hay una respuesta clara dejar claro que no es necesario que usteded participe.

- No invite a todo el mundo por que sí, sea conciente de a quien invita, señale quienes son obligatorios y quienes pueden ser opcionales.

- No plane meetings semanales, considere realizarlas cada tres semanas o cada dos de ser muy necesario. Reconsiderelo varias veces si realmente necesita ser semanal, no tome la desición de hacerlo semanalmente a la ligera. Si mas tarde se dio cuenta de que no necesita ser semanal, cambielo, su desición no se grabado en piedra.

- Limitar la meeting a 30min, si es posible solo 15min. No exceda ese tiempo. Siempre pregunte por el tiempo a asignar.

- Tener una agenda clara de los tópicos a tratar, forzar la agenda en la meeting.

- Prepare la meeting, no improvise en la reunion, incluso si usted es un participante familiaricese con los temas a tratar preguntandole primero al organizador cualquier duda previa.

- Llegue siempre a tiempo a la reunion.

- No espere a gente que llega tarde, comience la reunion a la hora que estaba planeada.

- No haga resúmenes de lo hablado para la gente que llega tarde. Que vean la minuta después de la reunion.

- Si usted llego tarde, no interrumpa saludando, espere a un momento de silencio para saludar si es necesario. Si es por telefono y puede, avise al organizador por chat o mail que entro al conference room.

- Evitar temas externos a los de la agenda.

- Sea rápido y consiso al saludar, a nadie le interesa lo que hizo el fin de semana o que lleva puesto, si cuando llego a la reunion esta no empezo no comienze a hablar de cosas externas a la agenda. Si quiere hablar cosas personales con alguien que esta en la reunion vealo mas tarde.

- Si va a usar proyector o cualquier dispositivo tecnológico, pruebe todo 15min antes.

- Si la meeting usará una session WebEx, GoToMeeting o JoinMe, como participante ingrese 5min antes, como organizador comienze todo 15min antes.

- Caye a los participantes que se van de tema, que dan vuelta sobre el mismo tema, o que se van por las ramas, no deje que hagan perder el tiempo de los demas.

- El que organizo la meeting debe ser el responsable, no deje que otra persona tome el control de la reunion.

- No use las reuniones como un Juicios en búsqueda de culpables, trate estos temas individualmente.

- Si algo no funciona como lo esperado, no pretenda hacer fixes en la meeting, salte el tema y prometa enviar soluciones luego.

- Sea consiente de que probablemente no todo se resuelva en la meeting, por ende cuando un tema toma demasiado tiempo en resolverse ponga como punto final analizar el tema en cuestion y buscar una respuesta tomando en cuenta los puntos conversados en la meeting. Esto es obligación del dueño de la meeting.

- Hacer una minuta de la reunion y dejarla en algun lugar accesible para todo el mundo.

Tenga en claro que nadie, nadie, quiere estar en la meeting, por ende no pierda el objetivo de la misma y ayude a que termine pronto, usted como cliente se vera beneficiado por que podrán trabajar en completar su solución, lo mismo como manager sumado el plus de que su equipo estará agradecido con usted. Incluso como compañero de team, entre mas rápido se discutan los temas mas armonía de equipo existirá.

En resumen

- Evite todo tipo de meetings usando la creatividad para ello, pero si las necesita hagalo.

- No haga meetings programadas, nadie las entiende, nadie las preparas y suelen no tener topicos claros.

- Si va a relizar una meetng aplique los tips comentados

Si ustedes es una de esas personas que tiene que estar todo el día en meetings y piensa que ese es su trabajo y por ello se cree importante, probablemente tiene un monton de inoperantes a su cargo que lo necesitan todo el tiempo para tomar desiciones por que ellos son incapaces de tomar alguna o usted es un inoperantes que no puede hacer nada por si solo por ende molesta a todo el mundo, o en el peor de los casos usted es las dos cosas. Cualquiera sea su razón, puede evitarlo.

Si me inspiro el próximo va relacionado a las threads de emails con copia a todo el mundo que son interminables. Aca van unos links

http://www.vancouversun.com/business/productiveconversations/meetings+kill+productivity/6690596/story.html

 

http://www.fastcompany.com/1837301/5-ways-process-killing-your-productivity

 

http://www.entrepreneur.com/blog/222759

 

http://www.lifehack.org/articles/productivity/kill-meetings-to-get-more-done.html

 

http://facilethings.com/blog/en/others-productivity-killers

 

http://www.psychologytoday.com/blog/wired-success/201204/why-meetings-kill-productivity?goback=%2Egde_1956828_member_153805186

 

http://www.effectiveday.com/10bigmistakes/

 

http://killthemeeting.com/

 

Share

Se fué el 2012

A pocas horas de cerrar el año puedo decir contento que no deje nada pendiente, puedo empezar el año nuevo con la mente fresca, haciendo borron y cuenta nueva.

Entre las cosas lindas que hice lo primero que recuerdo fue el viaje fugaz a Salta que hicimos con Caro a principio de año, un lugar fantástico.

427490_3189887198700_1485636655_n

Después ví a una de las bandas que mas me gustan en River Plate, Foo Fighters, un recital increible, pasado por agua pero el recital fantástico.

Seguidito a eso la empresa donde trabajo, después de mucho pelearla, me manda a NY, una de las ciudades que tenía que conocer antes de morirme, por 3 meses para trabajar ni mas ni menos que para el NYSE (New York Stock Exchange), el viaje en NY fue fantástico y ademas tuve la suerte de estar acompañado por Marcos y Caro quienes estuvieron visitandome, no podía haber imaginado un viaje mejor.

Uno de los fines de semana fuimos a Washington y fue el día mas caluroso en 30 años, el calor chaqueño nos sigue, igualmente nos recorrimos todos los museos y caminamos por el national memorial.

555464_3903665042700_502610752_n

Otra de las cosas copadas que pude hacer allá fue ir a ver un recital del maestro Victor Wooten, impresionante, lo tenia a 5 mts haciendo su magia con el bajo, ace les dejo un video de Steve Bailey, quien lo acompañanba en el show.

Desde el punto de vista de trabajo personal realicé dos proyectos, uno fue PHRequests

https://github.com/casivaagustin/PHRequests

Este es un wrapper para Curl el cual pretende hacer la vida mas fácil a la hora de usar curl, ya lo he usado en 3 proyectos y es una maravilla, probalo.

Tambien empezé a trabajar en un módulo para usar PHPUnit dentro de Drupal, originalmente creado para Drupal 6 y recientemente portado en un branch para Drupal 7.

http://drupal.org/sandbox/casivaagustin/1678226

Lo estoy usando en dos proyectos pero no logro cerrarlo todavía, igualmente es funcional si queres probarlo, tambien se aceptan ayudas dado que el proyecto es open source.

Para cerrar el año fuí a una Hackathon en Paraguay la cual estuvo fantástica, esperamos para volver en Marzo a la próxima. En esta hackathon tuve la suerte de conocerlo al gran Cesar Rodas con el cual siempre intercambiabamos twits pero al final nunca nos conocimos en persona, un verdadero genio.

Como lado negativo tengo que decir que no estoy muy satisfecho con mi desempeño este año, creo que tuve el culo muy pesado y no llegue a hacer cumplir ningún hito significativo para con mi vida este año, creo que podría haber hecho mas cosas de las que hice.

El año que viene quiero hacer mas cosas y quiero pegarle un giro a mi vida, así que estoy empezando a ver ideas e oportunidades para ver que se puede hacer. Lamentablemente esta imagen me hizo ver la realidad, voy a hacer lo posible para que no me suceda lo de la imagen.

536149_4699358915250_111866633_n

Feliz Año para Todos !

Share

cat HackathonPy 2012

Este fin de semana fuimos hasta el país vecino, Paraguay, a un Hackathon que organizaba el amigo Cesar Rodas junto la colaboración de Microsoft y Puntopy.

Se prendieron al viaje Marcos, Jonathan, Ariel y Rata, todos trabajamos en Globant y justo el viernes a la noche teníamos la despedida de fin de año, igualmente esto no evito que reventáramos en la fiesta (me termine acostando tipo 6am). A eso de las 9am pasa Marcos por casa listo para salir a la ruta, hermosa resaca de por medio, meto la laptop al bolso y salimos a rodar. Después de hacer una parada en Clorinda para comprar refrescos y conseguir guaranies seguimos para Asunción.

En la aduana del lado paraguayo nos recibe un amable señor que nos guia paso a paso para hacer el trámite aduanero, después de hacer nuestros papeles teníamos que hacer la verificación del automobil y allí un agente de la policía nacional no reclama que los parabrisas no solo deberían tener grabado el número de chasis sino que tambien necesitábamos el de motor, (WTF!), como segunda objeción nos dice que nos faltaba un certificado del seguro donde decía que el mismo estaba habilitado para circular por el mercosur (doble WTF!), después de mucho hablar terminamos siendo víctimas de la corrupción típica de latino america y nos emperno, y al amable señor que nos guió en el paso a paso había que pagarle tambien (Fuck!). Moraleja, ojo para la próxima, segundo no pidan ayuda el tramite es muy sencillo (pasar por migración argentina, pasar por Afip, pasar por migraciones paraguayas y pasar por la policia nacional, listo), tercero verifiquen los papeles para salir del pais con gente que salga seguido y/o con oficiales de policia federal o gendarmería.

Después de pasar el control aduanero y putearnos un rato llegamos a puntopy donde se realizaba el evento. Esta era una casona vieja reformada para ser oficinas, un lugar hermoso. La hackathon ya había empezado cuando llegamos pero igual nos dieron una cálida bienvenida.

Largamos decidiendo el proyecto a realizar, después de mucho rompernos la cabeza con Marcos decidimos encarar un proyecto para presentar en un mapa las fotos de mi viaje realizado a NY, para eso íbamos a utilizar la información que mi cámara pone en le header del JGP con datos geográficos. Sabíamos que no era nada loco, pero queriamos usar Gmaps, Symfony 2 y teníamos que hacerlo correr en Azure, todo en 24hs, así que decidimos no engordar el scope y terminarlo. A todo esto, se suma Ariel quien decide incorporar test automation al proyecto con un framework que viene creando el sobre TestNG y Selenium, el moñito que nos faltaba.

Nos largamos a codear, Marcos hizo de sysadmin levantando el Git, Azure y setupeando todo. Jonathan preparo el entorno de Symfony2, Ariel se largo a preparar los test y yo me puse a pelear con el frontend. Entre comidas, puchos, muchas gaseosas, cervezas y muchas charlas con los amigos del paraguay, después de 24hs llegamos al final. Hicimos las presentaciones de los proyectos, uno mas bueno que el otro, nos quedamos sorprendido por el nivel de los proyectos realizados por los muchachos del paraguay. Al final gano una aplicación que permitia a un usuario hacer un dibujo y a otro ver el dibujo que este realizando (en otra maquina), en tiempo real (mediante websockets se mandaba el update de una maquina a otra) y el otro usuario debía adivinar lo que dibujo, simplemente fantástico.

Aca pueden ver nuestra app corriendo http://triplot.mibanez.com.ar/ y aquí esta nuestro Github https://github.com/mgi1982/triplot.

Una graciosa, como estábamos muertos por el viaje y tanto codear, tuvimos que tirarnos a dormir, Marcos se tiro a dormir y justo comenzó una charla de Windows 8 dada por Guillermo, durante la charla Marcos ronco todo el tiempo y fue muy gracioso, como lo defino Cesar

Aca va una foto

Photo on 12-16-12 at 9.58 AM

El día domingo se nos acerco Cesar y nos dio un regalo, va que regalo, un regalón !, nos dio a todo el team de Chaco un Raspberri con la condición de hacer algo innovador, nos quedamos sin palabras, impresionante, nadie nunca nos dio algo tan copado y tan groso, no se como vamos a devolverle este regalo.

Photo on 12-16-12 at 12.04 PM

Después de la entrega de premios, donde nosotros no ganamos nada :( , después de muchos abrazos y saludos, emprendimos la vuelta, esta vez sin problemas y sin paradas llegando a eso de las 19:30 a Resistencia. Así como llegue me bañe y me fui a dormir, estaba muerto.

Se esta organizando para Marzo del 2013 otra hackaton, mas grande, con mas premios, mas comida y mas gente, si alguien esta interesado en ir no dude en avisar así vamos armando equipos y generando ideas.

Gracias a Cesar, Guillermo, Mauro y todos los muchachos de paraguay por la excelente atención, la pasamos de diez.

Mas fotos del evento.

Share