Squeak tips #1

Hoy encontré un mensaje de control de bloques extremadamente útil: el mensaje #ensure:

¿Que hace? Bueno, para los usuarios de Java se puede explicar fácilmente: hace lo mismo que un finally, asegura que el contenido del bloque "asegurado" se ejecute no importa cual sea el resultado de la ejecución del bloque original. 

Al igual que la estructura de control en java, este mensaje tiene pocas ocasiones donde es verdaderamente útil, pero en esas ocasiones es realmente útil. 

Un ejemplo que se me ocurre (de hecho el problema que estaba resolviendo y que me llevó a "descubrir" el mensaje) es el manejo de FileStreams: tengo que asegurar que el archivo quede cerrado, no importa qué ocurra. Bien, en squeak queda así: 

[ ^stream contents ] ensure: [ stream close ]


Lindo, ¿no?

Loving TDD

Soy un desconfiado de las metodologías. Como todo programador, me gusta la parte en la que vamos a codear. Por supuesto, no soy un negado, muchos años de programación en proyectos de distinto tamaño me han hecho valorar algunas de las herramientas que proveen las diversas metodologías que probé, aunque tiendo a considerarlas a todas un poco hinchadas.
En estos momentos estamos probando con Scrum para gestión y TDD como normativa de programación -y otras cosas sacadas de XP-, al estilo que cuenta Henrik Kniberg en “Scrum and XP from the Trenches” (excelente lectura, la recomiendo ampliamente) y estoy teniendo mucho mejor resultado de lo que esperaba.
En particular, hoy mismo tuve que resolver dos problemas en el que usar TDD me solucionó realmente mucho más de lo que esperaba, y me permitió ser realmente ágil:
Tenia que resolver un simple proceso de login, que es un componente de prácticamente todas las aplicaciones en las que trabajamos, por lo que está bastante generalizado, en un package llamado “SmallLogin”, que en teoría debe ser reutilizado en todas las aplicaciones.
Bien, el proceso entonces sería: a) Instalar el package, b) extender las clases necesarias para efectivamente realizar el login.
-¡Hey! ¡Esto es TDD, ¿Dónde están los tests?!
Tuve que refrenar mi impulso de ir al código directamente y hacer los tests, aunque sea un simple proceso de login, así que maldiciendo por lo bajo (no me gusta “perder tiempo”), me puse a armar un test case para el login y registración de un usuario del sistema, cosa que logré luego de unos minutos (la tarea fue simplemente crear una clase con un par métodos de test).
Ahora, la tendencia natural luego de completar esta tarea sería ir browser y codear, ahora si, las clases y métodos que necesito, ¿no?
¡Error!
Esto es lo que haría si estuviera utilizando lenguajes tradicionales, pero yo estoy trabajando con smalltalk, tengo un ambiente entero a mi disposición. No hay que abrir el browser, hay que abrir el test runner y correr los tests... y programar con el debugger, que te va guiando por lo que falta para conseguir que esos tests vayan a verde.
Es el principio de “correr hacia el verde”... conseguir una versión andando lo antes posible. Hacer esto fuera de un ambiente requiere un montón de ciclos de codificación-compilación-ejecución (amén de que un programa sin un esqueleto previo simplemente no compila), pero en un ambiente se transforma en algo bastante trivial.

Momento en el que descubrí que el debugger 

es el mejor amigo del programador

El segundo “caso”, ocurrió justo después.
El sistema que tengo que hacer requiere el uso de otro de nuestros frameworks, el “Whiteboard”, que sirve para mantener un grafo de objetos compartidos entre diferentes usuarios, así que lo bajé y me puse a integrarlo con mis usuarios, y corrí los tests, que por supuesto fallaron. Siguiendo el mismo procedimiento, llegué al lugar donde estaba el error, noté que había que hacer una refactorización en el Whiteboard (no en el sistema actual), la apliqué y en menos de diez minutos tenia mis tests en verde de nuevo.
Mi gran pregunta es ¿Hubiera resuelto esto tan rápido si no hubiera hecho los tests? ¿Cuál sería la calidad del producto sin ellos? ¿Cuanto el tiempo perdido en re-works y re-tests?

En conclusión, ¡los invito a todos a disfrutar de la experiencia de hacer Test Driven Development en un ambiente vivo! (Cuidado, puede ser altamente adictivo)

Luchando contra la depresión de estar fuera del mainstream.

Una de las cosas que pensamos al momento de comenzar esta aventura de smallworks, era que nos iba a costar mucho entrar al mercado. Y les tengo que confirmar es así. Hay cosas que el mercado exige y que no están el core de negocio.
Una empresa puede tener los mejores recursos, manejar la ultima tecnología, pero si no tiene un sitio con la home en flash, ya empieza la carrera 2 cuadras atras...y hay que correr mucho para alcanzar al pelotón...
Este tipo de cosas me sumieron en un fuerte depresión esta semana. Actualmente, aparte de buscar genera la plataforma para este sueño llamado smallworks, tengo un trabajo regular, que día a día se me hace mas difícil hacer. Es tan utópica la empresa que pensamos, que cada día la veo mas lejos. por eso el titulo de este post y por eso las ganas de largar todo y dedicarme al Smalltalk.
Otra cosa con la que me choque esta semana y me tiraron medio abajo, fue que en las primeras escáramusas comerciales, puede detectar que el mercado se encuentra a unos 5 años atrás comparado con de la visión que tenemos los que formamos parte de smallworks. Preguntas como..."yo que gano en usar smalltalk en lugar de .net o java. fueron recurrentes en mis reuniones". Lamentablemente es muy poca la gente que decide que entiende las ventajas del tipado dinámico. Aunque pude transmitir un poco el concepto de las ventajas que tenemos ante una opción tradicional, estamos muy lejos...aun...
Los mounstros comerciales que mantienen las tecnologías mainstream tiene el circo tan bien armado, que aunque a las personas le muestre hechos concretos, todavía siguen eligiendo las opciones tradicionales, sin siquiera dar lugar a la duda.
Podemos definir esta posición en una frase: "Coma Caca, un millón de moscas no pueden equivocarse."
No puedo negar que existen empresas que quieren hace las cosas bien y la gente que las conduce esta mas interesada en obtener un producto de calidad y no hablar en el DEV Day de IBM o en algunos de los coloquio de IDEA. InfOil o MerCap son claros ejemplos, pero son las menos.
Lamentablemente nos encontramos en un estado del arte tal que es mas importante un presupuesto abultado, que una buena solución. Es mas importante salir en tapa de la Information Technologies, que brindar una buena plataforma de negocio para su empresa, que la posicione mejor ante sus competidores. Hablan de SOA y App Servers cuando lo único que vieron en su vida sobre el tema es alguna ppt armada por un consultor que solo le interesaba vender un proyecto con varios 0(ceros)(quien solamente leyó algún papper para armar la ppt).
Nosotros en Smallworks no somos así. Pero esta postura en lugar de ayudarnos nos juega en contra. Pareciera que la gente que toma decisiones en las empresa les gusta las cosas como están y cualquier cambio esta mal.
Esta cosas me sumieron en una fuerte depresión.
Para agravar la cosa también llegamos a la conclusión que el TDD casi se transforman en un must en las tecnologías dynamic typed. Esto deja en el mismo costo y tiempo un proyecto en Seaside desarrollado con TDD y uno en .net desarrollado con Agil UP o cualquier otra metodología. La calidad del resultado entre las dos opciones son como el día y la noche. no hay punto de comparación en las cualidades se debería buscar en software, (escalabilidad, mantenibilidad, extensibilidad.. y todas las bilidad que se les ocurran) los desarrollos en Smalltalk son infinitamente superiores, pero nuevamente aparece el pensamiento mainstream. "Para que me voy a arriesgar a desarrollar en Seaside, si gasto lo mismo que en -NET y si lo hago en .Net algo voy a ligar de rebote","Coma Caca, un millón de moscas no pueden equivocarse.".
Pero vuelvo a afirmar, nosotros en Smallworks no somos así, como el mercado espera de una consultora tradicional. Nosotros vamos a luchar día a día, momento tras momento para alcanzar niveles de excelencia que el mercado argentino nunca vio. Y voy a morir con las botas puestas.
Aunque sea mas caro vamos a seguir usando TDD,, que se que al final de la historia nuestros productos terminen siendo menos rentables.

Bueno este es el antimarketing, no hacemos lo que el mercado nos pide, hacemos las cosas bien, hacemos las cosas con excelencia...se que hay gente que puede estar leyendo este post y diciendo "a este loco no le compro ni un alfiler.", pero no importa nosotros tenemos la visión bien clara.
Si se sintió identificado con alguno de los perfiles que figuran arriba y quiere cambiar contactenos, estamos para acompañarlo en esta aventura.
Si se siente identificada y no esta de acuerdo, sus comentarios serán bien recibidos.
Y si por ultimo usted quiere hacer las cosas bien. contactenos...seguro que se enamorará de smallwork. llamenos y compruebelo..

En busca de la identidad "Sin que suene a verso."

Una de las cosas que estamos buscando es construir una identidad de empresa.
No buscamos una lista atributos comerciales que nos diferencien, solo con el fin de vender, sino que buscamos diferenciarnos con el solo fin de "ser diferentes".
Cuando empezamos a plantear nuestra visión, misión y valores, resultaron tan utópicos que terminaron sonando alejados de la realidad y poco creíbles a la hora de vender.

Mas o mes esto son:

Visión:
Hacemos lo que nos gusta, de la manera que nos gusta y con la gente que nos gusta (Traducción: trabajamos en desarrollo de software, buscando la excelencia, sin sucumbir a las presiones del medio, y sin caer en las malas practicas, que las consultoras en que hemos trabajado hasta ahora, caen a la hora de cerrar un negocio o proyecto. Cuando decimos "con la gente que nos gusta", es porque vamos a buscar la excelencia en el capital humano de nuestra empresa, sobre todo lo demás. Porque creemos que el buen software, esta desarrollado por buenas personas. Si una persona carece de aptitudes blandas, no puede relacionarse con los demas; si no puede relacionarse, no puede entender las necesidades del cliente, que lo llevan a desarrollar una solución, por eso, no pueden desarrollar software que colme 100% las espectivas del cliente en calidad, tiempo y forma. Además es horrible trabajar con gente antipática o con falta de humildad).

Misión:
Brindar un macro de desarrollo tanto personal, como profesional para todos aquellos que compartan nuestra visión y nuestros valores. Tanto para nuestros empleados como para nuestros clientes. (Esto lo promoten muchos, pero nosotros lo vamos a cumplir, por que?.... porque nos gusta y punto.)

Valores:
Aunque no expresemos nuestros valores como los encontrarían en un libro acá les pongo algunas frases que nos identifica.

• Nuestros valores están sobre todo, porque nos definen como personas y empresa, aun sobre la rentabilidad. La vida es mas que plata...Smallwork va poner en practica su misión y alcanzar su visión, sin claudicar en sus valores, sin que esto signifique la sangre de nadie.
• No tememos al cambio..El es la fuente de nuestro diferencial y donde nos sentimos comodos.
• No creemos en dogmas, palabras ni frases de moda.
• La realidad cambia y nosotros fluimos con ella, pero nosotros cambiamos con la realidad no con las modas.
• A veces es bueno cambiarse de rompa y en muchas otras es bueno quedarse con lo puesto.
• Todo lo que hacemos, lo hacemos con pasión y compromiso.
• El desarrollo de software, es una arte ( una actividad creativa), no una actividad repetitiva. Las estructuras, las metodología y otras cosas que usamos hoy en día, fueron creadas para asegurar que los proyectos informáticos sean concretados en tiempo y en presupuesto. Lo hacen, se aseguran del resultado.....mediocre. Toda actividad que limite la creatividad del profesional de sistemas atenta contra el resultado final de su trabajo...el software. Estamos convencidos que el valor de negocio que podemos agregar supera ampliamente el costo de gestionar el riesgo de los desvíos como se hace actualmente en el mercado.
• El conocimiento no tiene propietario. Toda actividad de investigación y desarrollo que realizamos en Smallworks esta disponible para la comunidad en su todo. Somos parte de la comunidad y cualquier mejora a la misma, es mejorarnos a nosotros mismos. El mayor activo que tenemos es nuestro medio, no lo que podamos conocer y atesorar en un momento dado.
  
• Capitalismo Responsable. Todos el revenue que obtenga Smallwork como empresa, mas allá de las inversiones (que tiene un porcentaje limite definido desde el momento cero. ) para el crecimiento natural de la empresa, será distribuido en todos los miembros de Smallworks según su participación en las actividades de la compañía. Siempre nos quejamos de la sociedad...nosotros queremos hacer las cosas diferentes, porque creemos en que una sociedad diferente es posible. También cabe aclarar que también estará definido un % de revenue para invertir actividades de bien publico. Dios quiera que nos convirtamos en el Ben & Jerry's del ambiente informático.
• Somos parte de una sociedad y queremos darle valor a ella. Toda las cosas las vamos a hacer en un ámbito de inclusión, dando la posibilidad a todos de expresar sus ideas y permitiendo el desarrollo de las misma. Vamos a apoyar en los medios que nos sea posible los emprendimientos que mejoren nuestro entorno, así como vamos devincularnos (ni por toda la plata del mundo le vamos a vender) de toda empresa o entidad que atente contra nuestro medio ambiente (en todas sus facesta, ambientalmente, socialmente, educativamente, etc.)
• Respetamos a la gente que trabaja con nosotros...porque en algún momento de nuestras vidas estuvimos en su lugar. Trabajadores, Clientes, Proveedores, todos los que se relacionan con smallworks son tratados en forma justa y respetuosa de su condición de persona y entidad (estamos hablando desde sueldos justos, pasando por las sillas y los escritorio donde trabajamos, hasta cuanto le cobramos por el trabajo). Esto nos impide entrar en el jueguito que muchos conocemos de la negociación de precio y tiempo de los proyectos....sobre nuestras espaldas y la de nuestra gente.
  

Todo esto tiene un montón de consecuencia que no las voy a detallar en este post pero lo que si les digo que es muy difícil transmitir a una persona estos valores, sin que esta los catalogue de verso.
Hay mucho que empezaron así prometiendo capacitación, sueldo, vacaciones...... y después .......bueno mejor no hablar de ciertas cosas. Todos sabemos lo que nos prometen para vendernos un producto o cuando nos contratan.

Agradeceremos ideas y comentarios.