NTC

6 Años

3 Comentarios

y basta...de todo!

+ basta de la mentira...de enseñar que los objetos tienen metodos si en la vida real no se hace asi.
+ basta de la mentira...de enseñarle a los chicos Herencia, si "Estudiante" TIENE UNA Persona....y no hereda de Persona.
+ basta de la mentira...de la que la Clave Primaria debe ser natural y compuesta en el DER...si siempre se usa un ID.
+ basta de la mentira...de que NO hace falta saber programar para ser bueno en esta profesion.
+ basta de la mentira...de Iterativo e Incremental, si siempre es en Cascada.
+ basta de la mentira...de que si estudio ingenieria en sistemas, sé arreglar computadoras, sé de celulares, sé usar el Corel y el Photoshop y sé hackear cuentas de mail.

Si alguien sabe más...avise y vamos agregando!

6 Años

1 Comentarios

Érase una vez...

Hoy les dejo una adaptacion de un cuentito para que se vayan a dormir intranquilos...

"Érase una vez en un lejano país donde vivían dos cerditos, Chucho y Checho que, además, eran hermanos. Ambos eran los cerditos más listos de la granja y, por eso, el gallo Tucho (el gerente de la misma) organizo una reunión en el establo, donde les encargo desarrollar un software para controlar el almacén de granos.

Les explico que quería saber en todo momento: cuantos sacos de grano había y quien metía y sacaba sacos de grano del almacén. Para ello solo tenían un mes pero les advirtió que, en una semana, quería ya ver algo funcionando. Al final de esa primera semana, eliminaría a uno de los dos.

Chucho, que era el más joven e impulsivo, inmediatamente se puso manos a la obra. “¡No hay tiempo que perder!”, decía. Y empezó rápidamente a escribir líneas y líneas de código. Algunas eran de un reciente programa que había ayudado a escribir para la guardería de la vaca Paca. Chucho pensó que no eran muy diferentes un almacén de grano y una guardería. En el primero se guardan sacos y en el segundo, pequeños animalitos. De acuerdo, tenía que retocar algunas cositas para que aquello le sirviera pero bueno, esto del software sirve para reutilizar lo que ya funciona, ¿no?

Checho, sin embargo, antes de escribir una sola línea de código comenzó acordando con Tucho dos cosas: que era exactamente lo que podría ver dentro de una semana y como sabría que, efectivamente, estaba terminada cada cosa.

Tucho quería conocer, tan rápido como fuera posible, cuantos sacos de grano había en cada parte del almacén porque sospechaba que, en algunas partes del mismo, se estaban acumulando sacos sin control y se estaban estropeando. Como los sacos entraban y salían constantemente, no podía saber cuántos había y donde estaban en cada instante, así que acordaron ir contabilizándolos por zonas y apuntando a que parte iba o de que parte venia, cada vez que entrara o saliera un saco. Así, en poco tiempo podrían tener una idea clara del uso que se estaba dando a las distintas zonas del almacén.

Mientras Chucho adelantaba a Checho escribiendo muchas líneas de código, Checho escribía primero las pruebas automatizadas. A Chucho eso le parecía una pérdida de tiempo. ¡Solo tenían una semana para convencer a Tucho!

Al final de la primera semana, la demo de Chucho fue espectacular, tenía un control de usuarios muy completo, hizo la demostración desde un celular y enseño, además, las posibilidades de un generador de reportes muy potente que había desarrollado para otra granja anteriormente. Durante la demostración hubo dos o tres problemitas y tuvo que arrancar de nuevo el programa pero, salvo eso, todo fue genial.

La demostración de Checho fue mucho más modesta, pero cumplió con las expectativas de Tucho y el programa no fallo en ningún momento. Claro, todo lo que enseño lo había probado muchísimas veces antes, gracias a que había automatizado las pruebas. Checho hacia TDD, es decir, nunca escribía una línea de código sin antes tener una prueba que le indicara un error. Chucho no podía creer que Checho hubiera gastado más de la mitad de su tiempo en aquellas pruebas que no hacían más que retrasarle a la hora de escribir las funcionalidades que había pedido Tucho.

El programa de Chucho tenía muchos botones y muchísimas opciones, probablemente muchas más de las que jamás serian necesarias para lo que había pedido Tucho, pero tenía un aspecto “muy profesional”.

Tucho no supo qué hacer. La propuesta de Checho era muy robusta y hacia justo lo que habían acordado. La propuesta de Chucho tenía cositas que pulir, pero era muy prometedora. ¡Había hecho la demostración desde un celular! Así que les propuso el siguiente trato: “Les pagare un 50% más de lo que inicialmente habíamos presupuestado, pero solo al que me haga el mejor proyecto. Al otro no le daré nada”.

Era una oferta complicada porque, por un lado, el que ganaba se llevaba mucho más de lo previsto. Muy tentador. Pero, por el otro lado, corrían el riesgo de trabajar durante un mes completamente gratis.

Chucho, tan impulsivo y arrogante como siempre, no dudo ni un instante. “¡Trato hecho!”, dijo. Checho explico que aceptaría solo si Tucho se comprometía a colaborar como lo había hecho durante la primera semana. A Tucho le pareció razonable y los convoco a ambos para que le enseñaran el resultado final en tres semanas.

Chucho se marcho silbando y llamo a su primo Sixto, que sabía mucho y le aseguraría la victoria, aunque tuviera que darle parte de las ganancias. Ambos se pusieron rápidamente manos a la obra. Mientras Chucho arreglaba los defectos encontrados durante la demo, Sixto se encargo de diseñar una arquitectura que permitiera enviar mensajes desde el celular hasta un webservice que permitía encolar cualquier operación para ser procesada en paralelo por varios servidores y así garantizar que el sistema estaría en disposición de dar servicio 24 horas al día, los 7 días de la semana.

Mientras tanto, Checho se reunió con Tucho y Mencho (el encargado del almacén) para ver cuales deberían ser las siguientes funcionalidades a desarrollar. Les pidió que le explicaran, para cada petición, que beneficio obtenía la granja con cada nueva funcionalidad. Y así, poco a poco, fueron elaborando una lista de funcionalidades priorizadas y resumidas en una serie de tarjetas.

A continuación, Checho fue, tarjeta a tarjeta, discutiendo con Tucho y Mencho cuanto tiempo podría tardar en terminarlas. De paso, aprovecho para anotar algunos criterios que luego servirían para considerar que esa funcionalidad estaría completamente terminada y eliminar alguna ambigüedad que fuera surgiendo. Cuando Checho pensó que, por su experiencia, no podría hacer mas trabajo que el que ya habían discutido, dio por concluida la reunión y se dispuso a trabajar.

Antes que nada, resolvió un par de defectos que habían surgido durante la demostración y le pidió a Tucho que lo validara. A continuación, se marcho a casa a descansar. Al día siguiente, tomo la primera de las tarjetas y, como ya había hecho durante la semana anterior, comenzó a automatizar los criterios de aceptación acordados con Tucho y Mencho. Y luego, fue escribiendo la parte del programa que hacía que se cumplieran esos criterios de aceptación.

Checho le había pedido ayuda a su amigo Gaturro, un gato vegetariano que había venido desde Santa Cruz a pasar el invierno. Gaturro no sabía programar, pero era muy rápido haciendo cosas sencillas. Checho le encargo que comprobara constantemente los criterios de aceptación que él había automatizado. Así, cada vez que Checho hacia algún cambio en su programa, avisaba a Gaturro y este hacia, una tras otra, todas las pruebas de aceptación que Checho iba escribiendo. Y cada vez había mas. ¡Este Gaturro era realmente veloz e incansable!

A medida que iba pasando el tiempo, Chucho y Sixto tenían cada vez más problemas. Terminaron culpando a todo el mundo. A Tucho, porque no les había explicado detalles importantísimos para el éxito del proyecto. A la vaca Paca, porque había incluido una serie de cambios en el programa de la guardería que hacía que no pudieran reutilizar casi nada. A los inventores de los SMS y los webservices, porque no tenían ni idea de cómo funciona una granja.

Eran tantos los frentes que tenían abiertos que tuvieron que prescindir del envió de SMS y buscaron un generador de páginas web que les permitiera dibujar el flujo de navegación en un grafico y, a partir de ahí, generar el esqueleto de la aplicación. ¡Eso seguro que les ahorraría mucho tiempo! Al poco tiempo, Sixto, harto de ver que Chucho no valoraba sus aportes y que ya no se iban a usar sus ideas para enviar y recibir los SMS, decidió que se marchaba, aun renunciando a su parte de los beneficios. Total, el ya no creía que fueran a ser capaces de ganar la competición.

Mientras tanto, Checho le pidió un par de veces a Tucho y a Mencho que le validaran si lo que llevaba hecho hasta aquel momento era de su agrado y les hizo un par de demostraciones durante aquellas 3 semanas, lo que sirvió para corregir algunos defectos y cambiar algunas prioridades. Tucho y Mencho estaban francamente contentos con el trabajo de Checho. Sin embargo, entre ellos comentaron más de una vez: “¿Que estará haciendo Chucho? ¿Cómo lo llevaría?”.

Cuando se acercaba la fecha final para entregar el programa, Chucho se quedo sin dormir un par de noches para así poder entregar su programa. Pero eran tantos los defectos que había ido acumulando que, cada vez que arreglaba una cosa, le fallaba otra. De hecho, cuando llego la hora de la demostración, Chucho solo pudo enseñar el programa instalado en su notebook (el único lugar donde, a duras penas, funcionaba) y fue todo un desastre, mensajes de error por todos sitios, comportamientos inesperados... y lo peor de todo: el programa no hacia lo que habían acordado con Tucho.

Checho, sin embargo, no tuvo ningún problema en enseñar lo que llevaba funcionando desde hacía mucho tiempo y que tantas veces había probado. Por si acaso, dos días antes de la entrega, Checho había dejado de introducir nuevas características al programa porque quería centrarse en dar un buen manual de usuario, que Tucho había olvidado mencionar en las primeras reuniones porque daba por sentado que se lo entregarían. Claro, Chucho no había tenido tiempo para nada de eso.

Moraleja:

Además de toda una serie de buenas prácticas y un proceso de desarrollo ágil, Checho hizo algo que Chucho desprecio, acordó con Tucho (el cliente) y con Mencho (el usuario) los criterios mediante los cuales se comprobaría que cada una de las funcionalidades estaría bien acabada.

A eso que solemos llamar “criterios de aceptación”, Checho le añadió la posibilidad de automatizar su ejecución e incorporarlos en un proceso de integración continua (que es lo que representa su amigo Gaturro en este cuento).

De esta manera, Checho estaba siempre tranquilo de que no estaba estropeando nada viejo con cada nueva modificación. Al evitar volver a trabajar sobre asuntos ya acabados, Checho era más eficiente. En el corto plazo, las diferencias entre ambos enfoques no parecen significativas, pero en el medio y largo plazo, es evidente que escribir las pruebas antes de desarrollar la solución es mucho más eficaz y eficiente."

*(del libro "Diseño Agil con TDD" que se pueden bajar desde aqui)

6 Años

4 Comentarios

Cuando solo tenes un martillo...todos son clavos

Asi como nos quejamos de los que modelan y decimos "los que saben RUP aplican RUP a todo"...y los que desarrollan? No se escucha decir que "los que saben OO aplican OO a todo".

Cito un comentario que me llamo la atencion:

[ "con un diseño orientado a objetos que cumpla..."

Parece que damos por sentado que hay que utilizar un diseño orientado a objetos.

Los "novatos" tenéis que saber que también se puede utilizar una buena programación estructurada y procedural, y no utilizar un diseño orientado a objetos. Incluso aunque utilices un lenguaje orientado a objetos (Java, C++, etc.), no es necesario que utilices un diseño orientado a objetos, puedes utilizar un diseño estructurado y procedural.

"no utilizan herencia ni interfaces"

¿Acaso es obligatorio utilizar interfaces? Esta moda de ahora de utilizar interfaces, por ejemplo "por si cambiamos la base de datos por otra cosa" es típica de alguien que se ha leído muchos documentos "modernos" de los que circulan por Internet pero tiene poca experiencia en una empresa real.

Enterémonos: NADIE cambia la base de datos por otra cosa, y, si se cambia, te aseguro que el menor de los problemas será el haber usado o no interfaces. Es realmente absurda la costumbre de hacer siempre dos fuentes: uno con el interface y otro con la implementación.

Los interfaces están bien cuando necesitas herencia múltiple (que no existe en Java), pero es absurdo usarlos "por si nos cambian la base de datos por otra cosa y tenemos que modificar la implementación". ]

7 Años

0 Comentarios

Herramientas de soporte para gestion, contenido y afines para pymes

Esto mas que un post es un block de notas :D . Despues volver y sere millones...por ahora solo este post triste.

Herramientas sugeridas por el Centro de Excelencia de Software Libre de Castilla, España.
http://ticos.ceslcam.com/aplicaciones_pymes/index. htm [ceslcam.com]

ERP (Gestión integrada)
* Abanq
* Oasis
* OpenBravo

CRM (Seguimiento clientes)
* SugarCRM
* vTiger

Comercio Electrónico
* OsCommerce
* Magento

Gestor de tareas
* OpenProj
* Planner

Herramientas Colaborativas

* Zimbra
* Egroupware

Gestión de proyectos
* Redmine
* DotProject

Gestor de contenidos
* Joomla
* Typo3

Gestor documental
* Alfresco
* Nuxeo

Espero que los disfruten.Saludos.

7 Años

3 Comentarios

No serás tan 'ayail'

El dia sabado fuimos con el Ing. Frias a las "Sesiones Agile Open Córdoba 2010" en el FAMAF. La verdad que fueron unas sesiones muy buenas, desde como organizaron el caos acreditacional hasta el sorteo final donde Frias gano un vino gracias al "principio de atraccion", pasando por el catering y cafe correspondiente.

Fue mucha gente, la mayoria de testing, seguido por desarrollo y casi nadie de analisis, gente del PMI y un PM de Globant entre los mas sobresalientes. Como era de esperarse la forma de las sesiones fue agil, al mejor estilo "AA" (Alcoholicos Anonimos):
- Hola mi nombre es Gabriel, soy desarrollador y hace 3 años que consumo metodologias tradicionales...
- ¡¡¡Hola Gabriel!!!

Esa manera de "debatir" temas, hacía que las 8 hrs. que duró el evento fueran muy llevaderas. De la variedad de temas que se propusieron nosotros fuimos a los siguiente:

-"Metodologias Agiles": Se hablo sobre XP, TDD, DDD y LEAN...no mucho por que la mayoria deberia haber ido a la otra charla sobre "Introduccion a las Metodologias Agiles", ya que se perdia el foco de la charla debido a que varios no habian leido mucho acerca de "agile".

-"La psicologia en los metodos agiles": Hizo referencia al factor humano dentro de la "pseudo-industria" del software, algo que rescata y hace incapie esta "nueva movida". Algo muy interesante que surgio aca fue la "Teoría X y Teoría Y" sobre estilos de administración.

-"XP: sujeto y objeto": En esta, los que estabamos no sabiamos los fundamentos de XP, asi que gracias a la internec fuimos leyendo las caracteristicas y debatiendo esos puntos y viendo en que nos ayudan y por que no se implementa. Fue la charla mas graciosa ya que como era de esperarse, todos programadores, surgieron muchas puteadas y ejemplos pichis que cada uno padece en su ambito laboral. En resumen, lo mejor, programacion en parejas es lo que mas rinde, tomados de las manos, uno teclea y el otro clickea.

-"Casos de exito y fracaso en Cordoba con metodologias agiles": Aqui si no fuera por un PM de Globant nos ibamos a mirar las caras, ya que nadie tenia experiencia. El PM nos conto que en Globant siempre trabajaron con metodologias agiles, hace 6 años ya, y que se puede hacer $$$ y tener grandes proyectos con estas cuestiones, que hay un mapeo entre el PM y el Scum Master, y que estas metodologias son una evolucion de las tradicionales, que vienen a responder a estos nuevos modelos de negocio, a estas nuevas formas de las empresas, que tienen que ver con este mundo globalizado, dinamico y virtual.

-"Gestion de proyectos con SCRUM": Se hablo de como implementar metricas para estimaciones, medir la velocidad del "team" es un buen indicador. Como sirve SCRUM para cualquier proyecto, independientemente de la profesion (se esta enseñando SCRUM en la Facultad de Comunicacion Social).

-"RUP y la Iglesia Catolica: respuestas viejas a problemas nuevos": Esta ultima la iba a proponer yo pero no me anime.

Una cosa que me llamo la atencion, fue que todos hablaban de "waterfall" antes de pasarse a "agile". Es por que nadie hace RUP o porque siempre terminan RUPiando en cascada?

Conclusiones:

-Las metodologias agiles son la evolucion de las metodologias tradicionales.

-Ponen el "team" por encima del proceso, el trabajo en grupo es lo mas importante.

-No le tienen miedo al "error" y lo ven como una oportunidad de aprender y corregir rapido el rumbo.

-Desarrollan un sistema con el cliente y no para el cliente.

-Tambien se documenta, solo que no en volumenes que hacen desaparecer al amazonas.

-La calidad no es negociable. El alcance, la estimacion y la importancia, si.

Todo se resume a una frase del Negro Dolina..."prefiero el desengaño temprano, que una mina me diga que no me quiere ahora y no despues de sacar un credito para comprar una casita".

7 Años

0 Comentarios

Delivery de código

El otro día en el trabajo escuche un pedido de cambio de requerimientos vía telefónica, tal cual como hace uno cuando quiere comer pizza un viernes a la noche y no tiene ganas de cocinar. El pobre cadete que tiene que cumplimentar ese pedido, después de despacharse a putiadas, me hizo pensar que la burocracia también puede ser tu amiga.

Si vos tenés un cliente que cuando se le ocurre modificar algo de los requerimientos cerrados, levanta el teléfono y lo hace, estas ante un inmenso problema. Acá entra la burocracia de la que uno tanto reniega. Si le pones al tipo un documento que tenga que llenar para poder atender el cambio que pide, no digo 50 hojas, sino algo que le lleve 15 min de redacción, por pequeño que sea, vas a estar un poco más relajado.

De esto también surge otra cuestión, que si vos dejas que EL redacte el requerimiento, lo más probable es que lo haga de una forma muy pobre y vas a terminar vos refactorizando lo que el quiso decir. Ante esa situación, después de atender el llamado, enviarle un documento con lo que vos entendiste que tenias que hacer para que él lo valide, esto también implica que él se siente a leer, pensar y redactar los cambios. Después de un par de cambios que pida, y vea que no es tan fácil como pedir una pizza, quizás ahí puedas ponerte a ver youtube tranquilamente.

"Hacer un requerimiento debe implicar un mínimo costo para el solicitante.
Si es totalmente gratuito nos inundaremos de proyectos que no son más que “expresiones de deseo”."
(1)

(1) Recomiendo leer esta nota que habla más y mejor sobre esto.

7 Años

2 Comentarios

Diferencias entre programadores Junior, Semi Senior y Senior

¿Cuáles son las principales diferencias entre un programador junior, un semi senior y un senior?

Me contaron que un ingeniero amigo de un ingeniero amigo consiguio trabajo en una respetable empresa de desarollo de software a nivel internacional como semi senior en Java. Entonces me llamo la atencion como estratifican estas cuestiones de mortal, semi dios y dios, y mas o menos asi:

Experiencia laboral

Cantidad de años de experiencia laboral en informática.
No cuentan los trabajos prácticos realizados durante sus estudios. Tampoco suma si la persona trabajó 2 años atendiendo una agencia de viajes.

Junior: Menos de 2 años de experiencia.
Semi Senior: De 2 a 6 años de experiencia.
Senior: Más de 6 años de experiencia.

Conocimientos técnicos

Principalmente referido a las herramientas, tecnologías, lenguajes de programación, paradigmas de programación, base de datos, arquitecturas, etc. que deba utilizar para cumplir sus labores.

Junior: Para desempeñarse suele requerir acompañamiento. El código que genera puede presentar mayor cantidad de bugs de lo esperado. Probablemente no maneja todas las herramientas que se necesitan para la tarea.
Semi Senior: Técnicamente autosuficiente. Puede desarrollar funcionalidades más complejas y ejecutar proyectos de mayor envergadura. Pero no es un crack y todavía comete errores “evitables”.
Senior: Es referente técnico dentro del equipo. Su conocimiento le permite colaborar en definiciones arquitectónicas y desarrollar los proyectos más desafiantes. Su código funciona, es bueno y fácil de mantener.

Conocimientos funcionales

Relacionado a los procesos, metodologías, estándares, circuitos requeridos para cumplir sus labores.

Junior: Para desempeñarse suele requerir cierto nivel de acompañamiento. No conoce todos los procesos, ni los estándares. No es experto en los temas propios del negocio.
Semi Senior: Maneja los circuitos lo suficiente como para desempeñarse. Respeta los estándares y metodologías. Conoce buena parte de los procesos del negocio.
Senior: Ayuda a definir procesos, metodologías, estándares y circuitos. Por supuesto cumple los existentes.

Proactividad

Indicando si la persona espera a que le asignen sus tarea o si por el contrario toma una actitud de mayor iniciativa.

Junior: Necesita que frecuentemente le definan su trabajo. Está a la espera del siguiente pedido. Cuando tiene tiempo libre no sabe con qué seguir. Depende de otros para avanzar con sus tareas.
Semi Senior: Se preocupa por aprovechar mejor su tiempo. Pide nuevas asignaciones cuando tiene tiempo disponible y es autosuficiente para llevar adelante una gran parte de sus tareas.
Senior: No solamente recibe requerimientos, sino que los busca y genera. En muchas oportunidades es él quien le genera asignaciones nuevas a su superior.

Seguimiento requerido

Atención que requiere de su superior inmediato.

Junior: Requiere seguimiento diario a nivel detallado.
Semi Senior: Requiere seguimiento semanal y a nivel general.
Senior: Proactivamente reporta el estado y avance de sus tareas.

Indicadores de productividad

Indicadores varios relacionados con el trabajo que realiza

Junior: Calidad: Baja/Media  -  Productividad: Baja/Media  -  Innovación: Poca o Nula
Semi Senior: Calidad: Media  -  Productividad: Media  -  Innovación: Poca
Senior: Calidad: Alta  -  Productividad: Alta  -  Innovación: Alta

Cumplimiento de fechas

Cumplimiento de las fechas de entrega pautadas. Se aplica a las tareas de análisis, desarrollos, documentación, reporting, etc.

Junior: La mayoría de las veces no cumple con sus estimaciones.
Semi Senior: A veces cumple, a veces no.
Senior: Siempre cumple. Cuando surge un desvío (inevitablemente) lo informa adecuadamente y con anticipación.

Respuesta bajo presión

Referido a situaciones extremas… no a la corrida semanal para cumplir con la fecha de entrega del siguiente release en producción.

Junior: Le pueden pasar alguna de las siguientes cosas:
- Se bloquea
- Se angustia
- Se confunde
- Se estresa
El resultado de su trabajo en una situación de presión no es bueno.

Semi Senior: Le pueden pasar alguna de las siguientes cosas:
- Se enoja
- Se defiende
- Se distancia (se borra)
- Se resigna
El resultado de su trabajo en una situación de presión a pesar de todo, es bueno.

Senior: Le pueden pasar alguna de las siguientes cosas:
- Se entusiasma
- Se compromete
- Se hace cargo
- Se inspira
El resultado de su trabajo en una situación de presión puede llegar a ser asombroso.

Relación interpersonal

(Gracias a Javier Scavino por mencionar este aspecto).

Más allá de los conocimientos y capacidades de una persona, la habilidad de comunicarse con su entorno es fundamental para su desarrollo profesional.

Junior: Puede tener dificultades para transmitir sus ideas con claridad. No logra arribar a conclusiones concretables. No siempre sabe interactuar con otras personas de forma colaborativa y profesional.
Semi Senior: Se hace entender pero no logra ganarse la simpatía ni despierta la vocación de sus colaboradores para acompañarlo en sus sugerencias. Se permite escuchar otros puntos de vista pero sigue intentando que sean sus ideas (buenas y malas) las que prevalecen.
Senior: Es bueno comunicando, pero principalmente escuchando. Puede participar en desiciones de alto nivel y colaborar si es necesario en actividades más operativas privilegiando el resultado y la calidad de las relaciones por sobre su autoría en las ideas.


Dicho todo esto, les presento a un flamante desarrollador SEMI SENIOR: