miércoles, 4 de junio de 2008

¡Mudanza!

Bueno, nos mudamos... finalmente decidimos no esperar más a mejorar en diseño la página (la verdad es que le falta mucho) y nos mudamos a nuestro sitio propio: Smallworks, a su vez, decidimos que cada uno tenga un blog personal (hablamos de cosas muy distintas, todos), los blogs pueden encontrarlos directamente aquí.
El único problema que encuentro es que estoy escribiendo la serie "caminando con pier" (algo colgada ahora, pero no abandonada, el trabajo me impidió terminarla). Bueno, esa serie terminará allá, en mi blog, "El Octavo Clan".

Esperamos que nos sigan acompañando, en esta nueva casa nuestra y de todos :)

lunes, 5 de mayo de 2008

Caminando con Pier #6 - Crear un componente de "Novedades"

En este post voy a empezar a hablar de cosas más específicas, aunque creo que están casi siempre presentes en las páginas.
Por ejemplo, un componente que muestre las novedades suele ser necesario, y pier tiene una solución muy simple para eso: ¡un blog!
Los blogs son medios ideales para comunicar las novedades, pero claro, eso obliga a los interesados a entrar en el blog, y en realidad lo más cómodo (y “publicitariamente correcto”) es tenerlo en la página inicial, de entrada (si vemos el diseño del sitio que estamos armando como ejemplo, hay una sección de novedades incluidas)

Para construir un componente de novedades hay que seguir los siguientes pasos:

Crear una página embebida de novedades
Se crea una página embebida común, de la forma que vimos en los posts anteriores, haciendo click sobre “news”.

El template que yo quiero para mi página de novedades es el que sigue:

!Novedades

+newsBlog+

*Más novedades>/Blogs*

Como se vé en esta imágen:

Ingresando el "template" de novedades

Eso logrará que la página tenga un header (Novedades) y un footer (Más novedades), que apunta directamente al blog que creamos con anterioridad.

Esta página tiene también un componente embebido, +newsBlog+, que debemos definir.

Creando el enlace a las novedades
Para mostrar las novedades (que se encuentran en el blog), selecciono +newsBlog+, y lo defino como un componente.

Agregando un componente

De la lista de componentes disponibles, selecciono “Post Ticker” (este es el componente que hace el trabajo que necesito)

Un componente tipo "Post Ticker"

Después, solo me queda configurarlo, lo cual consigo seleccionando “Settings”.

Configurando el Post Ticker

Hay que ingresar el link que será tomado como fuente y si queremos, podemos modificar la cantidad de posts y la longitud máxima a mostrar.

¡Listo!

Para probarlo alcanza con poner un post en el blog y verlo como novedad en la página principal.

¡Hasta luego!

martes, 22 de abril de 2008

Caminando con Pier #5 - Creando una págína con estructura

En el post anterior habíamos visto como agregar páginas y blogs a nuestro sitio. Sin embargo, algo falta para que pueda se considerado "operativo" (además de un estilo propio, claro): en general, todas las páginas de entrada a un sitio tienen una estructura particular, en donde presentan distintos datos: bienvenida, novedades, etc. 
En mi caso, para este ejercicio, quiero que mi punto de entrada quede así: 


Sin tomar en cuenta el estilo, que es un poco exagerado -a propósito-, necesito darle cierta estructura a la página.

Por suerte, para este ejemplo, el header, logo y menú ya lo tengo por defecto, con la configuración estándar de Pier.
Entonces, lo que se necesita es crear la estructura interna: los tres paneles (animation, news y others).

Crear esta estructura, con ciertas limitaciones, es bastante simple:

Selecciono el “Home”.

Del sidebar, selecciono “Edit”.

Cambio el título por: “¡Bienvenido!”
En los contents, ingreso la estructura XHTML con la que desee ver la página:



Después, es tan simple como agregar las páginas o componentes internos seleccionando los componentes, para lograr una estructura de la forma que queramos.

Detalle: Embeber componentes en Pier.
Esta es una de las características (features) únicas en Pier: embeber componentes. Esto es tan simple como poner entre “+” el nombre del componente a embeber, por ejemplo: +welcome+, +news+. Luego, será tan fácil como hacer click sobre los links generados y seguir el wizard de adicion de componentes, para obtener un componente embebido.
Además, es posible agregar componentes ya existentes (indicando el path, por ejemplo: ++).
Es importante destacar que esta es la forma en la que uno insertaría imágenes o links a documentos descargables: se embeben como cualquier componente, y luego se selecciona “File” como tipo de componente.

Problema: Según el diseño de las páginas de Pier, todas llevan un título. Para armar estructuras a veces es deseable no poner un título (veamos por ejemplo el diseño con el que estoy trabajando), pero no hemos encontrado una forma elegante de ocultarlo o eliminarlo. Hay, sin embargo, algunos workarounds:
Lo más fácil es simplemente cambiar el CSS para el título (H1), y ponerle “display: none” o alguna de las otras formas.
Es posible modificar la estructura desde Squeak, para sacarle el título.

Para completar la estructura, hago click sobre cada componente y ingreso el contenido:
  • banner, tiene una imagen (animada, idealmente, pero por ahora no tengo). Despues del click, selecciono tipo File y subo la imagen que quiero usar. 
  • news, es una página embebida, con un listado de novedades (cubriremos esto en el proximo post), por ahora simplemente la agrego como una página: luego del click, selecciono tipo Page y salvo. 
  • welcome, es, al igual que news, una página embebida, pero con contenido (debo poner un mensaje de bienvenida, ¿no?). Para obtener esto repito lo hecho para las novedades, pero agrego como contenido el texto que quiero. 
Con eso, la página queda así. De más esta decir que, con un diseño (y un diseñador adecuado), quedaría muy pero muy bien, pero eso queda para un post mas adelante.


En la próxima entrega (con un poco de suerte mañana mismo ;)), mostraré como construir la página de novedades. 

¡Hasta luego! 

jueves, 17 de abril de 2008

La gente de Smallworks

Hace ya un par de meses que venimos en esto de armar una empresa, y todavía no presentamos al equipo, cosa que fue recordada a gritos por algún miembro de este “hermoso grupo” que forma Smallworks.
Este post es para presentar a todos los que participan en mayor o menor medida de este sueño.
El proyecto lo comenzamos tres amigos en muchas charlas after-office en el lugar en que trabajábamos con anterioridad. Ahí, café, cerveza, vino o fernet de por medio (variando las circunstancias dependiendo del día, la hora, el clima, etc.) empezamos a trazar los principios y objetivos fundamentales que le dan forma a Smallworks.Juanjo, Diógenes y yo (Esteban) somos ese grupo de amigos que puso en marcha esto.
Por supuesto, tuvimos que incorporar rápidamente a otros participantes del proyecto (y, lamentablente, tuvimos que decirle “esperá un poco, a que arranquemos” a otros). Así, sumamos al equipo a gente que completa muy bien el equipo: Nic, en diseño gráfico y “arte”, es el responsable del logo de la empresa y será el responsable del diseño y mantenimiento de la página, así como del diseño gráfico de las herramientas que implementemos; Martín, responsable de ventas, en quien descansan nuestras esperanzas de hacernos ricos ;) Y además, tenemos una legión extranjera, que darán los pasos necesarios para hacernos conocidos -y populares- en España primero, y cualquier lugar de la UE después: German y Laura.
Y ya está, con este equipo podemos lograr nuestros objetivos de convertirnos en un lugar viable y sobre todo, divertido.

martes, 15 de abril de 2008

Caminando con Pier #4 - Agregar páginas y blogs

Nuestra página web tiene una estructura más o menos compleja: una página principal, con un formato específico y después una serie de páginas “Quienes somos”, “Nuestra historia”, etc. Necesito entonces poder agregar páginas, blogs y también necesito poder darle un formato específico a la primer página (para mostrar novedades, etc.).
En esta entrega mostraré como hice para agregar las páginas y blog de la empresa. 

Agregando páginas
Agregar una página es facilísimo:

Seleccione el “home” del sitio.

Importante: Asegurarse de seleccionar la página de la cual queremos “colgar” nuestras páginas. Las páginas se crearan como hijos la que se encuentre seleccionadas.

Seleccione “Add” del sidebar y complete el formulario para una página:

Diálogo de agregado de componentes

Y complete los datos en el siguiente diálogo.

Diálogo de edición de páginas

Los campos obligatorios son “Title” y “Contents” (en realidad, “contents” no es obligatorio, pero es lo que le da sentido a agregar una página, ¿no?).

Importante: Para obtener los botones que ayudan a la edición de texto tengo que instalar un package particular, Pier-EditorEnh-lr.12.mcz, que se puede encontrar en el repositorio http://source.lukas-renggli.ch/pieraddons.

Importante: El formato de los contenidos es una wiki, que utiliza el mismo formato que la swiki tradicional, sintaxis que se puede encontrar aquí. La única diferencia (al menos la única que vi) es la sintaxis para embeber componentes (que es una característica exclusiva de pier), el nombre del componente embebido se pone entre “+”, por ejemplo: +news+.

Agregando blogs
Agregar blogs es tan sencillo como agregar una página cualquiera. En este ejemplo, yo necesito crear más de un blog, que estarán concentrados en una página “Blogs”, por lo cual en lugar de seleccionar el Home, selecciono Blogs como padre, pero el procedimiento es similar:

Seleccione “Add” del sidebar y complete el formulario para un blog:

Diálogo de agregado de componentes, seleccionando "Blog"

La única diferencia con respecto a crear una página común es que hay que cambiar el tipo de componente, por “Blog”.

Y complete los datos en el siguiente diálogo.

Diálogo de edición de propiedades de blog

Hay varios campos obligatorios, pero en la mayoría puedo dejarle los defaults.

Detalle: Agregar un post a un blog, es tan simple como todo lo demás: simplemente seleccione “Add” del sidebar e ingrese el post. El formato del post es el mismo que el de una página wiki (misma sintaxis y misma forma de agregar imágenes, etc.)

Luego de unos minutos de trabajo, su sitio se verá más o menos así:

Nuestra página, en este momento

Problema: El menú “children”, que muestra las páginas de smallworks, está ordenado alfabéticamente, y probablemente ese no sea el orden en el que las querramos.
Existen dos soluciones posibles:
1) Reemplazar el componente de tipo children por un de tipo menú, que nos permite editar el mismo manualmente (pero se pierde el agregado dinámico de páginas).
2) Una solución medio “hacker” (hay que tocar la página desde squeak), pero es bastante sencilla: si tiene una versión de pier anterior a la 215, hay que actualizar a esta (Pier-Model-lr-215) o mayor y ejecutar en un workspace:
(PRKernel instanceNamed: 'Smallworks') propertyAt: #childrenSortBlock put: nil.
Lamentablemente, todavía no hay interfaz gráfica para setear esto.

Hasta aquí, la página de Smallworks ya tiene páginas hijas y un blog. En la próxima entrega mostraré como creo que se hace para darle un formato específico a una página (la principal).

¡Hasta luego! 

miércoles, 9 de abril de 2008

Valor...no es Mc Donalds

En mi ultimo post escribí sobre el liderazgo y lo que significa. En este post había una palabra que se repetía constantemente "Valor". Valor es una palabra que usamos con muchos significados, y las variantes etimológicas del termino son infinitas. Según el contexto el valor es aplicable al coraje o a la concepción monetaria de un bien dado. Aunque en el post anterior esta muy claro que estamos hablando de coraje, me vi animado a escribir el presente, para llevar a la realidad el concepto de valor, dado que el Valor, como valor en si, solo es un concepto dialéctico cuya aplicación puede cambiar con el tiempo.
Antes de seguir quería decirles que este puede ser el ultimo post que escriba en blogger. Como escribo antes Esteban, breve vamos a tener listo nuestro sitio, el sitio de este sueño que dimos en llamar Smallworks [S|W]. Allí vamos a dividir en forma mas clara nuestros post, cada uno (estaban, juanjo, yo y cada uno de los que trabajamos en [S|W]) tendrá su propio blog para contar experiencia personales y habrá un blog general donde postearemos mayormente sobre tecnología y las experiencias de esta aventura con forma de empresa empresa.
De esta manera encontrarán mejor clasificados los tipos de posts. (Supongo que ya se habran dado cuenta del perfil de cada uno).
Ahora continuando con el tema de este post vamos de detallar las principales forma mostrar valor en nuestro contexto actual, siempre según mi humilde punto de vista.

Manifestaciones del Valor

"Comenzar algo solo y con las manos vacías asusta al mejor de los hombres. También dice muchísimo de cuán seguros están de que Dios está con ellos." [Un relato de los tres reyes]

Antes que nadie salte por la palabra "Dios" en el texto, e independientemente de mi fé, quise poner este extracto para mostrar la primera manisfestación del valor, "Las Convicciones".
Se puede decir que una persona es valiente cuando sus convicciones están sobre la realidad que sus sentidos le indican y lo que la razón aplicable en ese momento. Son estos tipos de personas que van mas allá de la media y son los verdaderos agentes de cambio. Son aquellos que gustosamente abandonan su zona de comodidad y se lanza a la exploración de nuevos terrenos por la promesa de cambio.
En la biblia define en forma muy sintética este tipo de comportamiento, "La certeza de los que no se conoce, la convicción de los que se espera", en Otra palabras "Fe", una persona que tiene fe en sus convicciones es una persona Valerosa.

"La oportunidad no es obligación". [Mile Nappa]

En esta frase, aunque muy oculta, esta la segunda manifestación del valor. "Decir que no"
Una de las primeras pruebas que tenemos que pasar cuando queremos ser diferentes y demostrar nuestro valor es "Decir que no". Tom Peter en su libro "La empresa de Servicios Profesiones " dice: "A cuantos clientes le a dicho que no en este tiempo?, Cuantos negocios ha dejado pasar? esta es una muy buena medida de su madurez". Decir que no es una
de las poderosas manifestaciones de valor. Esto demuestra 2 cosas, que tiene su visión clara y que tiene la madures para seguirla. Usted puede equivocarse en una decisión o en juicio de valor sobre algo, pero si pierde su visión y su personalidad, ya no es nadie. Se convertirá en uno mas de la masa. Ahora basta de retorica, decir que no, a que? Es muy simple, a lo vea en contra de su visión y mision en la vida, por ejemplo nosotros en Smallworks respetamos el ser humano como tal y conocemos lo que pasa(sufre) un profesional cuando es enviado a un cliente en el modelo de "Man Power". Es por eso que nosotros no hacemos "Man power", no importa el dinero que haya atrás. Smallworks no hace "Man power" y se los digo por experiencia, hay que ser muy valiente para decirle que no a un cheque "Gordo" cuando no tenes para el colectivo (autobus). Pero si lo aceptaramos no seríamos SmallWorks, seríamos algo que no queremos ser.

"Es una perdida de tiempo diseñar e implementar una estrategia de cambio hasta que no se descubre y acepta la realidad presente. Si no sabe donde está, es imposible llegar a donde tiene que estar. Lo que no sabe lo puede matar"[Andy Stanley]

Otra manisfestación del valor es reconocer la realidad de los que estamos viviendo, hay muchisima gente que se encierra en un mundo irreal para no enfrentar sus miedos y comenzar un cambio real de sus vidas, trabajo, pareja, en fin de todo su entorno. Sobre este punto puedo escribir horas pero lo voy a resumir en 7 "No" para asegurarnos que vivimos lo que "Es" y tenemos los pies bien plantados la tierra, porque esto también es valor:

  1. No fingir lo que no es

  2. No hace la vista gorda

  3. No Exagerar

  4. No Matar al mensajero(cuando trae malas noticias)

  5. No Esconderse detrás de las estadísticas y numero(perdiste a un empleado, no al 2,5% de tu Staff)

  6. No Obviar la critca (constructiva o no, muchas veces en la maldad de otros, verdades ocultas hay)

  7. No aislarse


  8. Vea la realidad y si algo no le gusta "Cambielo"
.

"Las cosas se crean 2 veces, una en tu mente y las segunda en la realidad".

No tengas pequeños sueños, porque no apasionan los corazones de los hombres

En estas dos frases tenemos la ultima manifestación de valor que voy a sitar. Se por experiencia propia que es imposible el cambio sin sueños, que es imposible alcanzar ese estado que llamamos valor sin tener una meta en mente, sin tener enfrente un horizonte que justifique el esfuerzo de luchar contra el status quo. Las sociedades que se quedan con lo actual, están perferctamente preparadas para una realidad que ya no existe. Si quiere ser una persona valoroza atrevase a soñar en algo mejor, planifique y actue en consecuencia.

martes, 8 de abril de 2008

Caminando con Pier #3 - Configuración de acceso

Dado que vamos a hacer una página institucional (o personal, da igual) y no una wiki, necesitamos establecer un diferencias entre lo que cualquier usuario puede ver y lo que yo, que soy el administrador, veo. En principio, necesitamos ocultar para el visitante todas las opciones que aparecen en el sidebar, con la única excepción del login.
Este proceso es muy simple, pero bastante complejo de explicar (y requiere varios pasos), así que si no se entiende, agradecería sus comentarios... así puedo arreglarlo. 
Importante: Las páginas iniciales (aquellas que fueron creadas en el proceso de instalación) no tienen asignado un dueño específico y por lo tanto son de acceso público visibles en todo momento. Como regala general, siempre que una página carezca de dueño, por defecto será editable por todos los que puedan verla.

A. Login de usuario administrador
Esto es lo primero que debemos hacer, para poder cambiar todos los derechos de acceso.

Seleccionar “Login”, del sidebar.
La configuración inicial tiene como usuario administrador a “admin” con password “pier”.
El login de Pier. Por defecto el nombre es "admin" y la contraseña "pier"

B. Cambio de dueño y grupo de las páginas
Una vez ingresados, debemos cambiar el dueño de la página principal.

Seleccione “Change Owner”
Marcar “recursive” y seleccionar “admin” como el nuevo “Owner”. Eso hará que todas las páginas hijas de la página principal pasen a pertenecer al usuario “admin”.

Permisos del dueño. Permite cambiar el dueño y la visibilidad del componente para un usuario determinado.
 
Y repito la operación para el grupo:
Permisos del grupo. Permite cambiar el grupo dueño y la visibilidad del componente para ese grupo.

Con esto logramos ser los dueños de la página principal y de todos los hijos.

Importante: No hay que cometer el error de hacer logout ahora, pues no hemos asignado derechos de lectura a usuarios generales ¡Si lo hacemos, no podremos ver absolutamente nada y habrá que repetir el proceso, o resolverlo desde el Pier-OmniBrowser! (que no cubrimos aquí)

C. Agregar propiedades de solo lectura para otros usuarios
Ahora, solo queda agregar derecho de lectura para cualquier usuario que no sea administrador.
Eso tiene dos pasos: 1) Habilitar derecho de lectura general y 2) deshabilitar otros derechos.

1. Habilitar derecho de lectura general.
De las opciones del sidebar, seleccionar “Change Other”, marcar “recursive” y seleccionar “View” de la lista de permisos.

Permisos de "otros". Permite cambiar la visibilidad del componente para usuarios no logueados (Por ejemplo, visitantes comunes de la página).

Con esto asignamos derecho de lectura a todas las páginas a un visitante cualquiera de la página.

2. Deshabilitar derecho de lectura en páginas específicas.
Con el paso anterior habilitamos a un visitante a ver todas las páginas, pero hay aún algunas páginas que no deberían verse: Los que permiten visualizar la página (logs, historia, etc.) y los links del header, “Environment” e “Information”.

2.1 Ocultando visualización de la página
Seleccionar el link “Environment” y luego “Sidebar>Views”.

Del sidebar, seleccionar “Change Other”, marcar “recursive”, seleccionar “remove” como Operator y seleccionar “View” de la lista de permisos.
Eliminación de permisos de "otros"

2.2 Ocultando páginas del menú
Ahora vamos a ocultar los links “Information” y “Environment”.
Seleccionar el link “Information”
Del sidebar, seleccionar “Settings” y marcar “Hide from menus”.

Configuración general de una página. Edición de título y visibilidad. 

Repetir la misma operación para “Environment”

Importante: El componente “Environment” es el componente principal de la aplicación, porque define la estructura general de la misma (header, footer, contents, sidebar, todo absolutamente), aunque es “hijo” de la pagina principal, también la define a ella.

Con esto hemos completado la configuración de la página. Si hacemos logout, podemos ver que hemos ocultado todo lo que debía ser ocultado, dejando habilitado una opción de login para poder realizar la administración de la página.

Así queda la aplicación luego de configurar los derechos de acceso y "desloguearse"

Ahora estamos listos para lo que realmente importa, que es armar la página de nuestra empresa... pero para eso habrá que esperar hasta mañana.

¡Hasta luego!

lunes, 7 de abril de 2008

Caminando con Pier #2 - Instalación

Como había prometido, aquí esta la primer entrega de la mini-guía de pier. Me colgué un poco y tardé en empezar, pero a partir de hoy, me comprometo a poner una parte por día (y no son tantas partes, por ahora cuento 4).
En esta primer entrega, haré la parte mas simple: la instalación. Aunque sea un paso un poco trivial,  espero que les sea de alguna utilidad. Además, el primer paso para empezar a usar un programa es tenerlo instalado :)

Instalar Pier desde una imágen 3.10 es bastante simple, requiere seguir estos pasos:
  1. Bajarse una imágen 3.10: Squeak3.10-7159-basic.zip
  2. En la imágen seleccionar el “Package Universe Browser”.
  3. Actualizar los packages, seleccionando "Update list from network"
  4. Seleccionar e instalar “Pier version current” (esta en la sección "Web Development")
  5. La instalación pregunta por un usuario y password de administración, para este ejemplo yo puse admin/admin. 
  6. La instalación pregunta si quiero crear una aplicación de Seaside para Pier, le digo que sí.
  7. Nombre del kernel: “Smallworks”
  8. Entry Point: “smallworks”
  9. Puerto: 8080
¡Listo!

La instalación estándar de pier me deja una aplicación corriendo, en este caso en http://localhost:8080/seaside/smallworks

Así se ve una instalación default de Pier

Alternativa: Instalando desde monticello
El metapackage “Pier version current” instala un montón de cosas, aunque a veces no las más nuevas. Esto es particularmente crítico porque tanto Seaside como Pier se actualizan muy frecuentemente, y a veces nos conviene -o simplemente queremos- tener versiones más nuevas.
El siguiente es un script que hace lo mismo que el metapackage que instalamos, pero con las últimas versiones (a la fecha):

"******************************"
"Level Playing Field (LPF)"
"Esta línea se baja de internet la última version del LPF, es necesario para poder instalar los últimos packages."
"******************************"
(HTTPSocket httpGet: 'installer.pbwiki.com/f/LPF.st') readStream fileIn.

"******************************"
"Comanche"
"Comanche es el servidor web default de Seaside.
Lo instalo de Universe, porque es bastante estable y no ha cambiado en los últimos tiempos"
"******************************"
Installer universe
addPackage: 'KomHttpServer(7.0.30)';
addPackage: 'KomServices(1.12)';
install.

"******************************"
"Seaside con Scriptaculous"
"Instalo la última versión estable de Seaside 2.8 y de Scriptaculous.
Las últimas versiones son distintas de las del universo, así que instalo las que estan en
el SqueakSource"
"Este paso pedirá el nombre y contraseña para el usuario administrador de Seaside"
"******************************"
"Seaside + Scriptaculous"
Installer ss project: 'Seaside';
install: 'Seaside2.8a1-tbn.539.mcz';
install: 'Scriptaculous-mb.239.mcz'.

"******************************"
"Magritte"
"Pier utiliza Magritte para describir los componentes, las versiones se encuentran en el
repositorio de lukas renggli (creador de magritte, además de pier)
"******************************"
Installer lukas project: 'magritte';
install: 'Magritte-All-lr.261.mcz'.

"******************************"
"Pier"
"Pier también esta en el repositorio de lukas
Como curiosidad: Pier-All no instala el componente de blog, ni el de persistencia,
así que los instalamos explicitamente"
"Este paso preguntará si se desea publicar una apliación pier, y los datos correspondientes"
"******************************"
Installer lukas project: 'pier';
install: 'Pier-All-lr.282.mcz';
install: 'Pier-Blog-lr.72.mcz';
install: 'Pier-Squeak-Persistency-lr.1.mcz'.

"******************************"
"Limpieza"
"Esto limpia los cachés de monticello, que engordan bastante la imágen, y luego de
la instalación son inútiles"
"******************************"
MCFileBasedRepository flushAllCaches.
Smalltalk garbageCollect.
Este proceso deja algunas cosas sin instalar que el paquete del Universe instala: el Pier-OmniBrowser y sus dependencias, pero como en esta guía no lo voy a usar, los dejé a fuera.

Eso es todo por ahora, el paso de mañana es "Configuración de usuarios y derechos de acceso"

¡Hasta luego!
 

 

jueves, 3 de abril de 2008

Grupo

Hace menos de un mes comencé mi tercer año de Psicología Social. Cuanto más aprendo, más me convenzo de lo útil que puede resultar esta disciplina aplicada a nuestros equipos de desarrollo. Metodologías agiles como Scrum hacen especial enfasis en la autogestión de los grupos. El Dr Enrique Pichon Riviere define al grupo como un "Conjunto restringido de personas que ligadas por constante de tiempo y espacio y articuladas por su mutua representación interna, se propone en forma explícita o implícitamente una tarea que constituye una finalidad, interactuando a través de mecanismos de asunción y adjudicación de roles.". Muy loco, resulta ser que nuestros equipos de trabajo, al menos para Pichón Riviere, son grupos!

Lo de las personas ligadas por constante de tiempo y espacio queda más o menos claro, todos llegamos entre las 9 y las 11, y nos vamos a las 18 clavado :)

La tarea que constituye una finalidad, también está claro, somos un equipo de trabajo con algún objetivo claro. Puede ser un proyecto, mantenimiento, soporte o lo que fuera, pero sabemos para qué estamos trabajando.

Articuladas por la mutua representación interna está un poco menos obvio. Esto se basa en el concepto de comunicación que dice que la comunicación entre dos personas siempre es triangular, o sea, hay un emisor que emite un mensaje hacia un receptor, una persona que habla y emite sonidos que fisicamente son escuchados por el receptor, pero además de estas dos personas físicas, el emisor en realidad simboliza su mensaje hacia un receptor que está dentro de su cabeza y que es una imagen del receptor físico que tiene delante. Esto genera un cierto grado de distorsión en la comunicación ya que esa imagen internalizada está distorsionada por cantidad de información previa suministrada por el subconsciente (historias previas con el sujeto, prejuicios, estereotipos o transferencias) En el grupo esto funciona plenamente. En primer lugar genera cohesión en el grupo ya que uno tiene internalizado a todos los integrantes, esto hace que a veces cuando falte alguien, igual esté presente porque los demás lo hacen participar en sus imaginaciones "Si estuviera fulano te hubiera dicho que eso está mal". Por otro lado esta representación interna también articula los mecanismos de funcionamiento del grupo, ya que hay una transferencia de lo conocido a esas imágenes internalizadas de mis compañeros de grupo. Por ejemplo es muy probable que algún fulano me resuene parecido a mi hermano, entonces mis reacciones hacia fulano van a ser bastante resonantes con las que tengo con mi hermano. Eso a su vez hace que fulano me incorpore de una determinada manera y tenga reacciones que reacomodarán mi representación de fulano.

Todas estas interacciones que van formando y reacomodando la mutua representación interna configuran los mecanismos de asunción y adjudicación de roles. Estos mecanismos son únicos para cada grupo y además en un mismo grupo también van evolucionando en el tiempo. Estos roles no están asociados al cargo asignado formalmente en el equipo de trabajo, sino a los roles que dinámicamente se van adjudicando y asumiendo en el devenir del trabajo del grupo.

Bien, muy lindo todo, y qué aporta esto al desarrollo de sistemas. Nada y mucho a la vez. Los equipos de desarrollo son grupos de trabajo, y querramos aceptarlo o no, se van a mover mediante las reglas descriptas. Pretender definir procesos que encierren a los integrantes del grupo en un molde donde cada perfil tiene que responder de una manera premoldeada, es negar nuestra naturaleza humana. Se pueden delinear roles y responsabilidades, pero no se puede esconder nuestra naturaleza creativa.

Bueno, otro día sigo

Whiteboard, creo que terminé

Bien, en whiteboard manejamos posts. Cada usuario tiene una colección de posts, cada post tiene n usuarios asociados y el mismo post existe en cada una de las colecciones de los usuarios a los que pertenece.

Esto nos da una herramienta para organizar la información y compartirla a la vez.

Y vuelvo con un ejemplo.

Supongamos que tengo:

Un post con titulo smallworks y sin tags

Un post con título whiteboard y tags smallworks

Un post con título officious y tags whiteboard proyecto


Un post con titulo tracker y sin tags

Un post con título bug y tags tracker

Un post con título requirement y tags tracker


Si cargo un post con los tags bug officious, automáticamente este post va a recibir los tags whiteboard proyecto smallworks y tracker, esto nos va a permitir filtrar, por ejemplo, por tracker+officious para ver todos las entradas del tracker generadas para officious o también podría filtrar por bug para ver todos los bugs cargados para todos los proyectos


Ahora bien, qué se hace con eso? Para poder adaptarlo a cada situación hay un mecanismo de plugins. Cada plugin sabe qué tipo de post crear y cómo mostrarse en el menú.

De esta manera crear una aplicación que administre contenidos consiste en crear los tipos de posts necesarios y el plugin que sepa crearlos, de hecho, el plugin también es opcional. Es así como basandonos en whiteboard logramos construir officious que es una aplicación análoga a un foro, un sistema de subastas y estamos trabajando en un sitio de administración de activos. Para todo esto solo hizo falta crear nuevos plugins. 


Todavía le falta mucho, es cierto, pero la verdad es que así como está ya nos dio muchas satisfacciones.

Whiteboard, te queremos!

viernes, 28 de marzo de 2008

Caminando con Pier - Introducción

Esta semana estuve ocupado armando el nuevo sitio de Smallworks (si, próximamente nos mudaremos a un sitio completo de esta “empresita”, en la cual habrá blogs propios).
Como parte de este trabajo (en realidad, como única parte realmente ardua de él), tuve que aprender Pier.

¿Que es Pier?
Es un Content Management System (CMS) hecho sobre Seaside, que corre en Squeak (hay ports para VisualWorks y GemStone, también). Pier tiene todos los elementos que requiere un CMS (facilidad de extensión y estilización y customización); tiene además algunos agregados que muchos otros no tienen: la orientación a componentes extensibles y una buena cantidad de componentes ya disponibles; finalmente, tiene algunas características con las que no cuenta ningún otro CMS: la posibilidad de “embeber” componentes en una página e inclusive incluir como componentes otras aplicaciones Seaside completas, transformándose así en una suerte de portal.
Toda esta maravillosa potencialidad viene con su costo: Si bien es increíblemente sencillo de usar, esto es así sólo después de dar un paso, hacer un pequeño “click” y entender el funcionamiento... al menos, eso me pasó a mí, quizás porque nunca antes había lidiado con un CMS... y como muchas de las cosas del mundo Squeak, Pier esta bastante pobremente documentado, lo cual es un problema, porque es realmente una herramienta muy poderosa.
En fin, como parte del trabajo de hacer andar nuestro sitio, escribí un pequeño “paso a paso” con todo lo que yo necesité hacer para tener la página andando bien. Sólo que es un poco largo para poner como un solo post... así que lo voy a partir en distintos posts, que insertaré en estos días.

Por cierto, en estos momentos hay una linda competencia en el mundo squeak para ver cual de los dos principales CMSs -Seaside/Pier o Aida/Scribo- utilizar para la página web. Por supuesto yo voto por Pier, pero sé que hay quienes leen este blog y prefieren Aida. De cualquier manera, eso esta aún lejos de ser definido... y no creo que a nadie le importe mucho mi opinión a la hora de decidirlo ;)

viernes, 21 de marzo de 2008

Whiteboard, parte 2

Continúo con la historia de whiteboard .
En el último post conté cómo llegamos a la decisión de compartir los posts utilizando los mismos tags para esto.
Bien, Otra cosa que queríamos tener era la posibilidad de crear grupos de usuarios para compartir los posts destinados siempre al mismo grupo. Para esto lo que definimos fue que al taguear un post con un label que coincida con el título de otro post, este heredaría los permisos de aquel post. De esta manera armar un grupo sería tan sencillo como crear un nuevo post, ponerle un título representativo y agregarle los usuarios al mismo. Luego, cualquier posts que hiciera referencia a este sería visto por todos los usuarios referenciados.
Suena un tanto confuso. Mejor lo explico con un ejemplo.
Quiero generar una serie de posts que van a servir para discutir temas relacionados a whiteboard, así que creo un post titulado "Grupo whiteboard", a ese post lo tagueo con los siguientes tags: estebanlm@smallworks.com.ar diogenes.moreira@smallworks.com.ar juanjoe@smallworks.com.ar
Este nuevo post es agregado en las respectivas vistas de cada uno de estos tres usuarios y cualquiera de ellos podría modificarlo e inclusive borrar su nombre de la lista de tags, con lo que automáticamente dejaría de ver el post.
Ahora agrego un nuevo post con algún comentario referente a whiteboar y quiero que mis compañeros lo vean. Esto lo logro agregando el tag "grupo whiteboard"

Dado que el usuario no es más que un tag, también puedo agrupar tags de la misma manera. Esto nos da una posibilidad de agrupar los posts en carpetas, solo que cada post pertenece a n carpetas y cada carpeta tiene n parents, con lo que las posibilidades de organización son muy grandes.

Bueno, espero que se haya entendido, otro día sigo

jueves, 20 de marzo de 2008

¿El año de Smalltalk?

Este es un "meta-post", un post que habla de otro post: leí este artículo publicado por Randal Schwartz en el que afirma que "este tiene que ser el año de Smalltalk" y menciona algunos puntos que creo que son interesantes: 
"If there is any year for Smalltalk to regain a commercial visibility, this will be it. I mean, look at all the things coming together:
  • the OLPC XO is putting Smalltalk into the hands of thousands of young kids
  • Cincom and Gemstone are stepping up to support Seaside in a big way
  • Gemstone is offering the single-instance free commercial license and GLASS quickstart appliance
  • Squeak's license is finally getting cleaned up
  • Seaside is reaching a nice level of maturity
  • Seaside running on GNU Smalltalk for those that want a command-line environment
  • Croquet is maturing, even being adopted as a commercial "virtual meeting" space
  • Ruby on Rails has reestablished dynamic languages as useful for the web"

miércoles, 19 de marzo de 2008

Como saber si te estas conviertiendo en un lider?, simple, lee este post


Si un psicólogo lee este post seguramente va a decir que estoy buscando justificar la "Locura" o "Utopía" que puede parecer Smallworks. Y tiene razón, pero quería compartir con todos los que nos leen algunas de las cosas que "Nos" diferencian a los lideres.

Se que si estas leyendo este post seguramente hay mucho de estas cualidades en forma de potencial dentro tuyo, solo tienes que dar ese paso que hace la diferencia.

Cualidades de un Líder

Un líder es motivado por la mejora, el cambio. No hay nada mas deprimente para un líder estar en ambiente en el que no exista la posibilidad de cambio. Esto lo mata. Si estas en esta situación y te sentís que se te va la vida.... ya tienes la primera cualidad de un líder.

Un líder esta motivado, tiene miedo al cambio como cualquier, pero tiene el valor de enfrentarlo... la necesidad del cambio es mayor que el miedo y las estructuras en las que vive. Esta necesidad lo lleva a ir mas allá de lo que nunca llego. Un líder digno de seguir es aquel que te guía a lugares donde nunca llegaste... y el tampoco. Un líder no espera a controlar su miedo, viaja con él

Un líder no es una persona que tiene una capacidad especial para ver las oportunidad o la inteligencia para pensar mejor las cosas, es una persona que tiene las mismas cualidades intelectuales y cognitivas que vos, solo que tiene el valor de arriesgar lo necesario en pos de la promesa de un cambio.

Un líder es precavido, y ahora me voy a para un poco, porque es común encontrar muchas malas interpretaciones sobre este punto. El líder se preocupa por las personas que lo siguen y los efectos de sus acciones, pero no deja que esto lo frene. Hay muchos que esconden el miedo en la "precaución". Por eso algunas diferencias entre precaución y miedo. (según Andy Stanley).
  • La precaución es cerebral, el miedo es emocional.
  • La precaución tiene origen en la información, el miedo tiene origen en la imaginación.
  • El precavido calcula riesgos, el temeroso evita los riesgos.
  • La precaución tiene como objetivo el éxito, el temor tiene como objetivo no fracasar.
  • La precaución esta enfocada en el progreso, el temor estar enfocado en la protección de lo actual.
Si un líder no es precavido, esta muy cerca de recibirse de idiota y deja de ser líder.

Como lideres nunca sabemos los reales efectos de nuestras acciones, dado que nuestras acciones y sus resultados empujan a muchos otros a seguir el mismo camino, destrozando las antiguas estructuras y preconceptos.

Por ejemplo en Smallworks creemos fervientemente en un nuevo modelo de negocio del software, además que la calidad y la pasión de las cosas que nos gustan pueden coexistir. Realmente no sabemos si nuestros aportes a la comunidad en materia de administración y/o desarrollo de software (espacialmente en la comunidad squeak) van a generar algún cambio, pero en estos humildes comienzos, nuestra experiencia esta motivando a nuestros amigos (algunos informáticos y otros no.) a seguir sus sueños.

No se si a Amazon se le ocurrió vender libros por internet... pero ellos fuero los que tuvieron el valor de comenzar algo nuevo.

Google no invento los buscadores, pero ellos fueron los que tuvieron el valor de convertir su buscador en el mejor y a raíz de esto el mercado informático ya no es el mismo.

Y por ultimo, una de las señales que te van asegurar que sos un líder en lo que estas haciendo, es que muchas, pero muchas personas te van a decir que lo que queres cambiar no esta bien, no es rentable, no es posible y los no que se te ocurran.
No lo hacen de mala onda, sino que son gente que tiene el ingrediente fundamental de un líder, el "Valor de enfrentar sus miedos".

También como líder te va a rodear gente "rara", fuera de lo común. Ustedes se imaginan como lo catalogaron a Alan Kay cuando definio la DynaBook, seguramente lo habran catalogado de "raro". No te asustes porque es generalmente esta gente la que tiene la capacidad de ver el cambio.

Claro hay que diferenciar a los "locos", que hay muchos por ahí sin ver la realidad, pero no te asusten los "raros", seguramente alguien dice de vos los mismo por tus espaldas.

En resumen un líder es aquel que termina siendo un factor de cambio para su medio.

Si queres un mundo mejor, empezá a crearlo.
Si queres un trabajo mejor, empezá a crearlo.
Si queres crear algo nuevo, no evites el miedo y las ansiedades.... Enfrentalos.

Es posible que el seguir tu visión te lleve a lugares que aun no están iluminados...pero no temas, acordate cuando eras chicos y tenias miedo a la oscuridad...con el tiempo el miedo se va. Con el cambio , la innovación y el liderazgo es lo mismo.

jueves, 13 de marzo de 2008

IMS..una de nuestras aplicaciones


Al principio no pensábamos publicar aquí los proyectos que ejecutamos, pero por un pedido de la gente que nos lee vamos a hacerlo.

IMS es una aplicación que desarrollamos para un correo privado, una empresa de servicios postales. Esta aplicación fue construida sobre Squeak, con Seaside y Glorp como ORM. La base de datos es un PostgreSQL. Antes de continuar quería aclarar que estamos usando base de datos a pedido del cliente, además esta base después alimenta otros sistemas y un cubo OLAP.

Es por lo antes dicho que elegimos hacer la persistencia sobre una base de datos, y no sobre la misma imagen o sobre un magma. (La verdad que se nos paso por la cabeza GEMSTONE, pero la billetera aprieta y el cliente no nos miro con buena cara cuando hablamos de esa inversión. )
Esta aplicación es una aplicación de gestión como cualquier ERP, pero enfocada al negocio del correo postal.
Aparte de la aplicación web desarrollamos un panel de control en Morphic, para que un administrador pueda ver el estado de la aplicación y pueda realizar algunas operaciones basicas. El know how que hay en el cliente es casí nulo, así que debimos dejarle todo cocinado y al alcance la mano, "APB" como se dice en Argentina.
Usamos Scriptaculous para facilitar la interacción con el usuarios. (drap & drop, ligthboxes, etc.), además de hacer el entorno mas agradable al usuarios.(por los efectos...)
Aunque en muchos casos tuvimos que hacer mix, entre Javascript y Smalltalk, el resultados es satisfactorio.
De estas necesidades de mix uno de nuestro socios, nuestro TVP, se le ocurrió que sería bueno desarrollar una librería de componente WEB con SWT y ST2JS, cosa que ya propuso a la comunidad de Seaside. Aunque la versión actual no tiene estos componentes, esta nueva idea abrirá muchas posibilidades y por eso no quería dejar e mensionarla. Sobre este tema seguramente mi socio escribirá un post en la medida de lo posible.
IMS maneja un volumen mensual de aproximado de quinientas mil (500.000) piezas y es utilizado por casi todo el personal de nuestro cliente, que son 600 personas.
Nuestro cliente tiene 5 sucursales, las cuales operan vía VPN sobre un único servidor que se encuentra hosteado en sus oficinas centrales. Este servidor es un windows 2003 (personalmente hubiera puesto otra cosa, pero es lo que hay.), El hardware es un Dell chiquito, (PowerEdgeTM 840) que cuesta al rededor de U$S 1000.
Esto muchos no lo dicen pero, el hecho que squeak y seaside utilicen muchisimos menos recursos que su competencia del mainstream, termina redundando en que hay que hace una menor inversión en hardware.
La aplicación mantendrá un historia del 5 años para todas las operaciones sobre las piezas que se entreguen.
La verdad que hasta el momento, estamos muy contentos con la respuesta que esta teniendo el sistema.
El cliente, que al principio, no con mucha confianza, nos acepto que hiciéramos el sistema en esta tecnología, a pesar todos los mitos que hay dando vuelta al redodor de Smalltalk, esta mas que satisfecho.
Por ultimo y para terminar quería remarcar que gracias a que esta aplicación este construida en smalltalk, ya con 2 meses en producción, termino siendo una diferencial de negocio importante, porque pudimos adaptar su aplicación a nuevas funcionalidades , en tiempo record.

miércoles, 12 de marzo de 2008

Whiteboard, historia

Bueno, yo no voy a pegar pantallas, ni fotos. Mi intención es contar en tres o cuatro posts de qué se trata whiteboard (http://www.squeaksource.com/Officious.html).
Primero que nada un poco de historia.
Hace poco más de un año, cuando la idea de lanzarnos en un emprendimiento basado en Squeak iba tomando forma, decidimos crear un producto que nos permita entrar en el mercado por un lado, e ir probando la tecnología y definiendo formas de trabajo, por otro. Fue así como surge Officious.
Officious es una herramienta colaborativa, pensada para aquellos que trabajan en oficinas, con acceso a computadoras e internet. El objetivo central de la herramienta es generar un espacio donde se puedan compartir comentarios, tareas, concursos, organización de almuerzos, salidas, etc.
La premisa más importante fue la de la simplicidad de uso orientada a usuarios sin conocimientos técnicos.
Bien. Luego de unas cuantas idas y vueltas la cosa quedó así. 
La aplicación va a contar con una especie de tablón de anuncios al que se le pueden agregar distintos tipos de entradas ya prearmadas, como un sticky, un almuerzo, una nota comentable, etc. A cada una de estas entradas las denominamos "post"
La organización de este tablón de anuncios (whiteboard) se va a realizar mediante tags. La navegación la pensamos similar a delicious (hasta el nombre le choreamos) donde haciendo click en un tag se muestran solo los posts marcados con ese tag.
Cada usuario, verá su propio whiteboard, con posts suyos y posts de otros usuarios que le hayan compartido. Cada post podrá ser compartido a distintos usuarios.
El otro tema a resolver fue el compartir los posts. No queríamos toda una funcionalidad aparte donde el usuario tenga que pasar por la traumática tarea de entrar en una pantalla especial para compartir su post (que esas cosas solo las hacen los administradores de redes, vamos).
La decisión que tomamos fue la de utilizar los mismos tags para eso. O sea, si el usuario juan crea un post y le pone el tag "jose". El usuario jose automáticamente va a ver aparecer el post en su whiteboard, y además lo puede modificar.
Con esto ya teníamos una linda idea (y potente) para comenzar a trabajar.
La sigo en la próxima...

martes, 11 de marzo de 2008

Tips #2: La performance se encuentra buscando la raiz de las cosas


Hoy estaba desarrollando y me encontré con una verdad que termina siendo un tip.
Algo que amo de Smalltalk y especialmente de Squeak es que se puede acceder directamente hasta el core de las cosas.
En la búsqueda que nace de nuestra curiosidad natural de seres humanos, se llega al conocimiento de la implementación de cada cosa.
De esta manera pude mejora la performace de mi desarrollo.

tenía en mi código algo parecido a:

|temp|
temp:=aCollection collect[:aObject | aObject doSomeThing ]
^temp size

resulta que la implementación de size, es un contador que suma 1 por cada elemento de la colección.

|tally|
tally := 0.
self do: [:each | tally := tally + 1].
^tally

En una aplicación que no maneja muchos registros, esto sería una cosa trivial, pero en mi aplicación que maneja cientos de miles de registros (una aplicación de servicio postal) cambiar el código anterior por el siguiente, significo una diferencia como la que existe entre el día y la noche , porque recorro una sola vez la colección.

^aCollection
inject: 0 into: [:cuenta :aObject |
aObject doSomeThing.
cuenta:= cuenta + 1 ]

Esto solo fue posible, por lo menos para mi, por tener la posibilidad de ver la implementación de cada uno los elementos (Collection en este caso particular.)que componen la plataforma. Cosas que otros ambiente del mainstream no pasa y estas atado a "prueba y error" o búsquedas interminables (googlear todo el día).

Aunque suene redundante, Amo este ambiente y cada día entiendo menos porque no es adoptado como tecnología principal por mas gente.


PD: Aquellos que tiene miedo a la performance de Squeak, les cuento que esta aplicación comenzó desarrollándose en dot.net con nhibernate y postgreSql como DB. Después de pasado un mes de desarrollo decidí tirar todo y desarrollarla en Squeak , con Seaside y Glorp como ORM. Esto me dio la oportunidad de comparar la performance en una aplicación real y no benchmarks de laboratorio (dado que ya tenía desarrollado un modulo en .net ) con el mismo modelo y el mismo soporte de persistencia (la DB), comparativamente hay una mejora de performance del 30% a favor de Squeak. Se pueden sacar muchas conclusiones y buscar la raíz de esta mejora en distintas partes de la plataforma, pero lo concluyente y la principal diferencia que termina afectando la perfomance es la cultura de la gente que esta detrás de cada entorno. Ya sea por su gente o por las prueba empíricas, puedo afirmar que Squeak esta listo para competir de par a par con cualquier plataforma comercial del mainstream y salir victorioso con mejora sustanciales. Por lo cual no tema y tirense a la pileta que hay agua.

jueves, 6 de marzo de 2008

Un sueño

No me puedo quejar. Hace años ya que laburo cómodo. Hago lo que me gusta, tengo mis libertades de movimiento, y no me va mal. Pero algo falta, siempre falta algo. Ya estoy llegando a la quinta década, y siento que tengo que hacer algo más. Es aquí donde entra Smallworks. Este proyecto no es independizarse y montar mi propia empresa. Eso podría haberlo hecho hace rato ya. Smallworks es un sueño, es querer armar algo nuevo, algo propio. Este sueño compartido con Diogenes y Esteban es lo que nos moviliza a seguir adelante, a ir contra gigantes, aunque a veces sintamos que son solo molinos y estamos perdiendo el tiempo.
Nuestro trabajo es creativo, vivimos de llegar a lugares donde solo hay una expresión de deseo e irnos dejando el deseo concretado en una aplicación. Lo hacemos, coordinamos grupos de trabajo, sufrimos las dificultades del desarrollo, las ansiedades de los tiempos tiranos y ambientes hostiles. Pero lo disfrutamos, lo nuestro es crear y esta quizá sea NUESTRA creación, desde cero, desde la nada y hacia un objetivo que parece un molino, pero que en realidad es un gigante. 

miércoles, 5 de marzo de 2008

Procesos

Bueno, yo no soy escritor como mis amigos/socios, pero voy con mi granito de arena.
Allá por el 2000 cuando paloteabamos java, pasamos varias veces por el dilema de la persistencia, CMP, BMP, ORM, o lo que anduviera dando vueltas en ese momento. Casi siempre terminamos en alguna solución ad-hoc. Lo que nunca faltó es el requerimiento de que la persistencia tenía que ser independiente del motor de bases de datos. No se quién nos metió eso en la cabeza, porque jamás escuché a ningún cliente pidiendo eso, pero de repente pegarse a Oracle, IBM o lo que fuera se había transformado en tabú.
Y así fue como comenzamos a nivelar para abajo, haciendo cosas espantosas con DAOs insoportablemente pesados y que oscurecían toda posibilidad de aprovechar las ventajas del motor de base de datos subyacente, y a veces hasta de las propias características del SQL. Por suerte el amigo Gavin nos sacó bastantes de esos problemas de encima.
Hoy estaba pensando en nuestros queridos procesos, y de repente me cayó la ficha que estamos haciendo lo mismo. Queremos un proceso que nos solucione todo, que sea independiente de las personas que lo ejecuten, que sea pa'todos igual. Tiene sus ventajas, claro, y bastantes más que la persistencia, cierto también. Pero de vuelta vamos nivelando para abajo, perdemos las características propias de cada uno de los participantes, y a veces hasta las propias características de las personas en general.
Los procesos sirven, y mucho, pero no deberían intentar jamás tratar de anular las diferencias que nos hacen personas.

Una alegría para el alma


Hoy empecé el día con una buena noticia, seleccionaron mi tesis (la generación "Y" y su impacto en el mercado informático), como una de las mejores del 2007 y el poster de la misma en este momento esta expuesto en el salón central de la facultad (UADE).
El cuerpo de la tesis estará disponible aquí y la nota que fue publicada en la revista .Code sobre el tema puede verse aqui .

Bueno Solo quería compartir mi alegría con todo ustedes y agradecerles a todos los que me apoyaron durante este duro tiempo de investigación.

lunes, 3 de marzo de 2008

Smalltalk vs. la ignorancia


Cuando era niño jugaba una versión del Trivia (juego de mesa estilo parchís, pero con preguntas y respuestas) que tenía una particularidad: si nadie sabía la respuesta, avanzaba en el tablero una ficha, normalmente negra, apodada “la ignorancia”. Yo odiaba que esa ficha llegara antes que nosotros, me sentía un tonto que no sabía nada.
Bueno, hace un par de semanas ocurrió un episodio que me hizo recordar esa etapa de mi vida, quisiera compartirlas con ustedes:

En una de sus charlas de negocio, uno de mis socios quedó consternado por una de las preguntas que le hizo uno de los socios de la empresa con la que se habría la posibilidad de asociarnos.
La charla fue más o menos como se había planificado, hasta ese momento: se presentó de una forma más bien poco profunda (así estaba pensada) nuestra forma de trabajar y nuestras tecnologías preferidas, así como las ventajas que veíamos, al menos para empresas medianas (pues creemos que las empresas grandes tienen compromisos -no fundados en razones tecnológicas, la mayoría de las veces-, que les impiden moverse en diferentes direcciones a las establecidas por lo que llamamos “el mainstream”, la corriente principal, la moda.
Volviendo al tema, la charla iba mas o menos bien, hasta que uno de los presentes interrumpió a mi socio y sin más soltó la pregunta: “¿Además de las ventajas de productividad, por qué deberíamos ofrecerle al Banco Galicia una solución en Smalltalk y Seaside, en lugar de hacerlo en .Net?”. Mi socio se quedó con la boca abierta. Después de todo, la charla había empezado aclarando que veíamos nuestra solución más bien para empresas medianas, y el Banco Galicia claramente no entra en esa escala.
En consecuencia, mi socio no tuvo una respuesta satisfactoria (ni ninguna respuesta, bah).
Y no es que no tengamos una, simplemente no queríamos darla: nos propusimos desde el primer día no defender una tecnología haciendo comparaciones con otras, sino a través de la ponderación de sus propias cualidades. Creemos que con eso alcanza para convencer a aquellos que busquen realmente una solución viable para su negocio.
Bien, pese a eso, yo me quedé con una espina clavada... creo que hay muy buenas razones para que un banco (El Galicia o cualquiera) pueda escoger una solución basada en Smalltalk para su negocio, voy a exponer las primeras tres que se me vienen a la mente:

  1. El principal propósito de Smalltalk es la simulación del mundo real. Es un ambiente donde el modelado de sistemas sumamente complejos se hace mucho más fácil que en cualquier otro. No es que en otros lenguajes u otras formas de ver el desarrollo de software no lo permita, es simplemente que en Smalltalk es mas sencillo, mas “natural”.
  2. Programar en Smalltalk es altamente productivo. Puedo demostrarlo en cualquier momento, pero detenerme en este detalle sería perder el foco del post (una búsqueda en google de “smalltalk productivity” arrojará literalmente miles de resultados. Cualquier negocio (bancario o de cualquier tipo) puede beneficiarse de esto. 
  3. Smalltalk se adapta con facilidad a los cambios constantes. Los sistemas bancarios son particularmente dinámicos y requieren adaptaciones frecuentemente, debido a cambios en la legislación (en nuestro país esto es cosa de todos los días), pero también a la adaptación a un mercado altamente competitivo. 

Sin embargo, y pese a la cantidad de cualidades y casos de éxito que hay, siempre existen los que se niegan a considerar siquiera la posibilidad de utilizar Smalltalk o cualquier otro lenguaje dinámico, siempre con las mismas excusas:

Soporte
Es un clásico de las empresas grandes, siempre dicen “vamos a ir con la tecnología tal, porque con ella tengo soporte y con la que ustedes proponen no”.
Bien, sobre esto... me genera bastante mal humor, siempre que lo dicen.
Una plataforma que cambia cada dos o tres años, y te fuerza a migrar cada vez a su nueva “solución”, no es soporte de calidad.
Una plataforma que crea algo totalmente distinto cada dos o tres años, y te fuerza a cambiar tu arquitectura para adaptarse a la nueva cosa, no es soporte de calidad.
Una plataforma donde los que te atienden son empleados de un callcenter que tienen un manual de instrucciones y no los creadores de la misma, no es soporte de calidad. Si encima tiene el soporte tercerizado en el tercer mundo (donde vivimos) y el soporte “de calidad” esta en el primero, es aún peor.
Productividad
Se sostiene una y otra vez que soluciones pre-hechas (tipo ensamblaje de componentes, etc.) permite alcanzar mejor productividad en los proyectos.
Psé... ni siquiera vale la pena detenerse aquí. Ya se sabe lo que pasa con las soluciones pre-hechas: no están realmente pensadas para el negocio que las requiere, sino para casos generales. Los componentes son caros y además tienen el código cerrado, por lo que entran en el ciclo de soporte lamentable mencionado en el punto 1.
Además, sostener que Smalltalk no es productivo es simplemente no tener idea de lo que se habla.
Falta de desarrolladores
Se sostiene que “todos programan Java o .Net, no hay programadores en el mercado para realizar un desarrollo que no se haga con una de estas plataformas”.
Este es un punto altamente cuestionable, sobre todo en Argentina, donde todas las carreras serias tienen formación en programación orientada a objetos y en Smalltalk.

¿Quien utiliza Smalltalk?
Por supuesto, los “casos de éxito” son importantes: nadie quiere arriesgarse a utilizar una herramienta sin que sea plenamente probada, y si bien es cuestionable en determinados ámbitos, es cierto que no se puede pedir a ningún negocio que tome un riesgo si no tiene una buena razón para hacerlo. Afortunadamente, hay empresas de primer linea mundial (y nacional) que utilizan Smalltalk para sus soluciones... y lo que es más importante, muchas de ellas lo hacen desde hace muchos años. Las siguientes empresas las encontré haciendo una investigación de 5’ con google, no son las únicas ni mucho menos, pero bastan como ejemplo: JPMorgan, Telecom, Repsol-YPF, Texas Instruments, Mercap SRL, Merrill Lynch, Swiss National Bank, y muchos más....


De cualquier forma, me quedó picando el tema y en futuros posts pienso hablar de cómo lograr calidad en el software usando Smalltalk (Squeak, en particular)

sábado, 1 de marzo de 2008

Diseñando (con CSS) aplicaciones web

Estoy haciendo un sistema muy pequeño de subastas inversas. Para el mismo estoy usando una arquitectura Squeak, Seaside y Magma (ah, las cosas divertidas de la vida). Uno de los requerimientos originales era que el sistema fuera fácilmente modificable por un diseñador gráfico, en un momento no determinado del desarrollo (es decir, no lo tenia disponible de entrada).
Por supuesto, se supone que siempre debería ser así, que los programadores no deberían tener nada que ver con el diseño, que los diseñadores no deberían meterse con el código, que blablabla... pero todos los que tenemos alguna experiencia en el desarrollo de aplicaciones web sabemos que no es así nunca, que el diseño de las pantallas tiene repercusiones en el diseño de la aplicación y viceversa.
Bueno, esta tarea, con Seaside se hace bastante trivial (en realidad, con cualquier framework orientado a componentes debería ser posible, pero en particular con Seaside, por algunas características como la capacidad de agregar decorators dinámicamente).
Para probar esto, trabajé durante dos semanas sin consideraciones “artísticas”, pero con algunas decisiones importantes en el armado de los componentes.
Para que se vea cuan cierto es que no me fijé, pueden ver como se veía la aplicación hasta ayer a la tarde:

Poca onda con los diseños

Y miren ahora los resultados de la aplicación con un rato de trabajo (y de robarme asquerosamente estilos de otros sitios), y, sobre todo, sin tocar absolutamente nada del código escrito. Todo a través de CSS:

Así esta mejor

Le falta mucho, pero a pesar de lo poderosos que son los componentes de Seaside y el CSS2, yo sigo siendo un humilde programador, con un talento para hacer el look&feel de las aplicaciones tendiente a cero. Imagínense lo que un verdadero diseñador puede hacer.

Para que esto funcione, hay que desarrollar los componentes siguiendo un par de pautas:

En primer lugar, todos los componentes plausibles de ser tocados por CSS deberían estar englobados en un div. Resolví esto creando un decorator, que se le puede agregar a cada componente que lo requiera.
En segundo lugar, internamente, los componentes también deben estar divididos en secciones, demarcadas por otros tantos divs.
Por ejemplo, un componente tendrá esta forma:

initialize
super initialize.
self addDecoration: SWCustomizableDecoration new.

renderContentOn: html
html heading level1; with: 'Edición de subasta'.
html heading level2; with: 'Datos generales'.
html form: [
html div class: #data; with: [ self renderBasicOn: html ].
html div class: #sheets; with: pliegos.
html div class: #buttons; with: [ self renderButtonsOn: html ] ]


jueves, 28 de febrero de 2008

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?

sábado, 16 de febrero de 2008

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)

viernes, 15 de febrero de 2008

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..