Curso en Universidad ORT: "Desarrollo de Sistemas Web con PHP 5" (4 meses)

Les comento que el día 16 de abril de 2007 (mes próximo) está iniciando mi curso (presencial ;-)) de "Desarrollo de Sistemas Orientados a Objetos con PHP5" en la Universidad ORT. Este curso se enmarca dentro del programa "Cursos de Actualización Profesional" dirigido a profesionales en el área de sistemas que deseen especializarse en el desarrollo de aplicaciones para Internet, a través de un enfoque más cercado a la Ingeniería de Software que al simple scripting y desarrollo estructurado que estamos acostumbrados a ver en PHP (bueno, ya creo que está casi de más decirlo si lees este blog ;-)).


Bajar el folleto (pdf)


Los horarios: Martes y Jueves de 19:30 a 22:30

Buscando en este blog por la etiqueta "ORT" podrán encontrar toda la información que desde el año pasado vengo compartiendo sobre el dictado del curso. Se desprende claramente de todo lo que he escrito sobre el tema:

[No es un curso tradicional de PHP]

Por lo pronto solo es para residentes en Uruguay, pero se escuchan ofertas para dar charlas especializadas sobre este tema, o dictados más extensos fuera de fronteras. ;-)

PD: curiosidad aparte, la semana que viene también estaré dictando la materia "Programación Web" (horario matutino) para las carreras Analista Programador y Analista en Tecnologías de la Información. En este caso más que Desarrollo de Sistemas y Orientación a Objetos vamos a concentrarnos en la Capa de Presentación y en RIA (Ajax, JSON, prototype y probablemente scriptaculous).

Solución Semana 3: "Cuestionario" (III/III)

Bueno, llegamos al final al cuestionario, donde debíamos responder algunas preguntas "macabras" (¿tan difícil es razonar? sí, lo es, porque hay que aplicar lo que se aprendió).

Cuestionario

Pregunta: ¿Cómo se representa en código PHP la existencia de una dependencia entre estos elementos?

Respuesta: Con cualquier sentencia de inclusión de fuentes: include, include_once, requiere, require_once. Es eso, nada más que eso, eso es lo que representan los diagramas UML. Cómo un fuente depende de otro, y si depende, es que lo usa de alguna forma, y en PHP es usando alguna de las funciones de inclusión (en los demás lenguajes es igual, solo cambiará la sintaxis. UML se aplica a cualquier lenguaje orientado a objetos).

Pregunta: ¿Analizando estas dependencias en sentido inverso, cómo se representa en código PHP?

Respuesta: Entendiendo el concepto, la pregunta *claramente* no tienen sentido. Si existe dependencia entre:

Presentación->Dominio->Persistencia

Significa claramente que Presentación ve solo a Dominio, Dominio ve solo a Persistencia, pero al revés ninguno puede verse, pues así queda representado en el diagrama. Los include/requiere van de arriba a abajo de los paquetes, en el sentido de las flechas. Si hubiera visibilidad en ambos sentidos habría que agregar un include/require de Persistencia->Dominio->Presentación (invertido) lo cual estaría mal, pues se puede deducir que:

  • Del diagrama correcto: los cambios de persistencia solo afectan a dominio y tal vez a presentación si dominio se ve obligado a cambiar (el otro significado de las flechas, ver cómo el paquete que apunta a otro es dependiente de sus cambios).
  • Del diagrama de "todos se ven a todos": cualquier cambio afecta a todos en cascada y en ciclos, lo que significa "sistema inestable y peligroso ante cualquier cambio".

Pregunta: ¿Cómo se verifica que existan cambios (y cuales fueron) en el repositorio SVN?

Respuesta: sobre el proyecto, menú contextual (botón derecho), Team->show history

Y mostrará el siguiente mensaje:

7/03/07 00:27 - enriqueplace
- cambia estética (css, templates)
- se agrega un campo nuevo "descripción"

¿No era tan difícil, o sí? ;-)

Solución Semana 3: "Consultas de Usuarios incompleta" (II/III)

Como decía anteriormente, "hacer un sistema es un tema de orden", entonces hagamos un "mapa" para saber donde estamos parados y hacia donde vamos.

Para hacer el formulario

ConsultarUsuario -> PresentaciónFachada

Una vez que ejecutamos el módulo correspondiente el formulario de consultas queda generado a partir del template contenido_consultar_usuario.tpl.html, esperando luego a que se ingrese información y presione el botón "consultar".

Ejecutar el formulario

Estando en el formulario, luego de ejecutar el botón "consultar", se invocarían a partir del template contenido_consultar_usuario.tpl.html:

MostrarUsuario -> PresentacionFachada -> DominioFachada -> PersistenciaFachada

Bien, el tema es el siguiente: ahora tenemos más de un parámetro que recibimos por $_REQUEST (que engloba a GET y POST), lo cual podemos usar varias estrategias:
  • Agregar los parámetros que necesitamos en la firma del método ejecutar y en todos los métodos que lo necesiten, capa por capa (vamos a tener además del id y nombre, la descripción).
  • Colocar un genérico $_REQUEST sin parámetros, que resultará en el array completo con lo que recibamos desde el formulario. También funcionaría $_GET o $_POST. (Nota: hay que tener en cuenta la seguridad de un sistema al recibir desde el "exterior" cualquier tipo de información).

Usemos esta última opción:
  • DominioFachada::traerObjetoUsuario( $request )
  • PersistenciaFachada::traerUsuario( $request );
Diagrama de Secuencia

Aprovechemos para conocer como trabaja un diagrama de secuencia y para qué nos puede servir. Lo ideal es que sea parte del diseño a "bajo nivel" antes de empezar codificar, como un plan para saber exactamente como trabajará nuestro sistema y como será implementado... todos los métodos estarán definidos de antemano con sus objetos y solo deberemos posteriormente programar su contenido. En este caso, lo usaremos al revés, definir un mapa a partir de lo que existe y validar que el diseño sea correcto (por ejemplo, respetar el correcto acceso a las 3 capas).


Este diagrama está dividido en dos etapas: cuando se ejecuta por primera vez y armar el formulario de consultas, y cuando se presiona le botón de "consultar" para generar todo el proceso de búsqueda de información en la base de datos.

En la primer etapa solo podemos documentar en este caso como se invoca el template, puesto que ahí quedamos a la espera de la acción del usuario. Cabe aclarar que no necesariamente deberíamos documentar el trabajo con el sistema de templates porque se puede dar por convenido que su funcionamiento se conoce y solo se necesita explicitar el resto de la lógica.

En la segunda etapa se parte del accionar del botón de búsqueda que genera la invocación en cascada de cada método de cada clase de cada paquete, hasta obtener el resultado buscado.

Varias salvedades para tener en cuenta:
  • Las flechas que aparecen en el diagrama representan las llamadas a los métodos perteneciente a cada Clase, es decir, muestran claramente el concepto de que la interfaz de los objetos son sus métodos públicos y los clientes de esos servicios son los que los invocan.
  • El nivel de profundidad en la documentación dependerá de nuestro contexto, y cada comentario (en UML es el dibujo que representa una "nota" con la punta doblada) puede aclarar la parte que se toma como obvia y que no aparece en el diagrama.
  • Muchos autores sugieren que no es necesario mostrar una flecha de retorno de datos (de derecha a izquierda), y menos todas las veces que sucede esta acción, puesto que lo importante es marcar el camino para generar la comunicación entre los objetos. Perfectamente podría ir al final del segundo diagrama una flecha de retorno que volviera a cada capa documentando que retorna un array con el objeto Usuario encontrado, pero podría considerarse redundante porque se supone que esto sucede.
  • De la misma forma que en la parte 1 -que no es necesario documentar el Template- en la parte 2 no es necesario documentar SentenciaSQL (framework).
Finalmente, ya lo hemos dicho con los Casos de Uso, los diagramas son "interpretativos" y están sujetos a un contexto y a la documentación que debe acompañar siempre. Nosotros documentamos lo que queremos y esto está sujeto a un contexto y a nuestro "público objetivo".

Dudas, preguntas, en los comentarios ;-)

Solución Semana 3: "Diseño en 3 capas" (I/III)

Bueno, voy a dar una solución al primer requerimiento del desafío de la "Semana 3" que no necesariamente ustedes debieron acercarse a la versión que voy a presentarles (trato de dar un paso más adelante).

Conceptualmente hablando

Desde nuestros "módulos" (index.php, listado_usuarios.php, consultar_usuario.php y mostrar_usuario.php), ubicados en la raíz del proyecto, debemos asegurarnos que la "dependencia" (flecha punteada) sea solo con el "paquete de presentación" y no con el resto de los paquetes (como se ve en el primer diagrama). Si nuestro sistema está organizado en 3 capas (siguiendo el segundo diagrama corregido, presentado a continuación) la forma de trabajo debería ser siempre:


"módulo" -> "presentación" -> "dominio" -> "persistencia"
  • "presentación": resuelve la interfaz, arma las pantallas, pero si necesita datos pasa a solicitarlos al dominio.
  • "dominio": donde se encuentran todos los objetos que representan la lógica de nuestro universo, de nuestro problema, de nuestro negocio (por eso también se le dice "capa de lógica de negocio"). Por ejemplo, si queremos mostrar un usuario este estará representado como un objeto de tipo Usuario la información para crearlo está en esta capa.
  • "persistencia": si necesitamos "persistir" la información para poder volver a recuperarla en un futuro, es decir, todas las operaciones conocidas: recuperar sus datos, grabar datos o modificar los existentes, eso representa acceder a la capa de "persistencia", quien se encarga de comunicarse con la herramienta de turno (una base de datos, un archivo plano, xml, webservices, etc).
Capas = Responsabilidades

Cada capa tienen su responsabilidad única, concreta, bien definida. De esta forma tenemos a nuestro sistema bien diseñado, dividiendo los problemas en partes diferenciadas. Si hay que modificar o agregar funcionalidades, hay que ir a una capa concreta y no tocar todos los fuentes de nuestro sistema. De la misma forma, si una capa hay que cambiarla por otra, se puede hacer intercambiándolas, o hasta usándolas ambas hasta que una sustituya a la otra, de forma casi transparente.

Si queremos cambiar la estética, solo se modifica la capa de presentación. Si queremos cambiar la lógica del funcionamiento del sistema, la capa de dominio, y si queremos hacer cambios en la forma de almacenar la información, la capa de persistencia.

Nota: no siempre es tan literal, puesto que si agregamos un "caso de uso" a nuestro sistema, deberemos crear la interfaz, reutilizar o crear parte de la lógica del dominio existente, y si no existe, agregar la funcionalidad para persistir el nuevo objeto.

Hay dos frases que entran en juego aquí:
  • "Divide y conquistarás" (frase histórica)
  • "Desarrollar un sistema es, fundamentalmente, un problema de orden" (mía ;-))
Dividir nuestro sistema en 3 o más capas, y cada una resuelva un problema, es justamente eso, trabajar de forma ordenada teniendo el control de lo que sucede.

Cambios a realizar

Claramente se detecta en el diagrama las clases que se está rompiendo el diseño de 3 capas y accediendo a cualquier capa sin ningún tipo de orden. Los fuentes involucrados son: listado_usuarios, consultar_usuario y mostrar_usuario.


Repasando: deberían entrar por la capa de presentación y luego esta capa -y solo esta- acceder a las demás capas.

index.php

  • Siguiendo el diagrama, este módulo se convierte en una clase (así tratamos de transformar nuestro desarrollo híbrido en un sistema 100% Orientado a Objetos, objetos que se comunican con objetos), por lo que habría que encapsular todo en una clase (se obtiene la estructura interpretando el diagrama).
  • La dependencia es correcta puesto que apuntaba únicamente al paquete de presentación.
  • No cambiamos de nombre el fuente a Index.class.php porque romperíamos el estándar y nuestro servidor no encontraría el index.php, pero internamente sí la convertiremos en una clase (Nota: esto es una convención que se me ocurrió crear, no necesariamente encontrarán esta forma de trabajo explicada en ningún libro).

listado_usuarios.php

  • Este es el primer fuente que muestra claramente la dependencia contra dos paquetes (presentación y dominio) cuando debería ser solo con el primero, y luego pasar de presentación a dominio. Esto se lee en PHP simplemente viendo la sentencia require, require_once, include o include_once (aquí ya estoy respondiendo la pregunta del cuestionario).
  • Dijimos que todo iban a ser clases, entonces, creamos una clase ListadoUsuarios
  • Mantenemos el mismo nombre, rompiendo la nomenclatura porque así lo necesitamos ahora para poder acceder desde http://localhost/surforce-proyectobase/listado_usuarios.php (no usamos ListadoUsuarios.class.php por la misma razón que no decidimos hacerlo con index.php).
  • Debemos modificar PresentacionFachada::listarUsuarios del paquete presentación para que resuelva internamente las invocaciones a la capa de dominio. Simplemente evitamos tener que hacerlo en el módulo y estas se esconden dentro del paquete que corresponde.

presentación/PresentacionFachada.class.php

  • El método listarUsuario deja de recibir por parámetros los usuarios y ahora internamente llama al dominio para solicitarlos. El módulo ni se entera (no debe) pues es una responsabilidad de la presentación obtener los datos del dominio, el módulo solo debe ejecutar la acción de la capa de presentación, el resto, un problema interno que no me corresponde enterarme. Es importantísimo entender esto para que nuestro sistema esté "desacoplado" y pueda ser "reutilizable".

mostrar_usuario.php

  • Similar al caso anterior, creo una clase, saco el código del dominio del módulo y lo muevo a la capa de presentación, y me quedo solo con llamadas a la capa de presentación.
  • En presentación modifico para que invoque ahora al dominio (como decía anteriormente, simplemente es pasar la lógica del módulo al paquete presentación).
Hasta aquí solucionamos el problema de "las 3 capas rotas", ahora, terminemos de corregir para que cada módulo sea una clase:

consultar_usuario.php

  • Similar a los casos anteriores, encapsulo todo en una clase y luego invocamos el método que inicia la acción (método ejecutar).
Fin de la parte 1 del desafío "Semana 3"

Pronto, un poco más, un poco menos, es lo que se esperaba de la "parte 1".

Dudas y consultas, en los comentarios de esta entrada. ;-)

Desafío Semana 4: "Modularizar el sistema" (actualizado 23/3/2007)

Nuevamente el Gerente de Proyectos, receptivo a los trabajos entregados y a todos los comentarios de sus subordinados, comprende que aún le falta hacer cambios en el diseño del sistema base entregado, por lo tanto decide solicitar un informe explicando las siguientes mejoras:
  • Sistema modular: centralizar las invocaciones que puedan venir únicamente a través del index.php y no del resto del sistema. Solo se ingresa por index.php y luego a los módulos correspondientes. Evitar el acceso por cualquier ruta distinta a index (concepto "web modular").
  • Eliminar los módulos por invocaciones a clases: eliminar los archivos que hoy día representan a los módulos de nuestro sistema (por ej. listado_usuarios.php) y desde el punto de entrada único (index.php) hacer invocaciones a las clases correspondientes que ofrecen esos servicios (por ej. ListadoUsuarios). Las clases no pueden estar definidas dentro de index.php y deberán crearse archivos para cada clase respetando la nomenclatura aprendida hasta el momento. Se solicita actualizar el diagrama de paquetes que represente todos estos cambios.
  • Clases Abstractas: hacer una lista de todas las clases que no son necesarias instanciarlas en el sistema y que deban ser "abstractas". Explicar la implementación, justificar la selección y la razón de esta decisión.
  • Mejorar la búsqueda: corregir la búsqueda por nombre y descripción para que pueda obtener más de una coincidencia (actualmente solo trae una).
  • Seguridad: el sistema actual confía de los datos que recibe, lo cual puede convertirse en un problema de seguridad a través de un ataque del tipo "sql injection". Proponer una solución a este problema.
Versión del Sistema Base

Deberán esperar a que se actualice la última versión del sistema, que estará disponible en las próximas horas y tendrá todos los cambios realizados para la entrega "Semana 3".

Forma y límite de la entrega

  • Seguiremos manejando un período de 1 semana, la entrega se hará el lunes 26/3/07.
  • Documento "compartido" (que permita modificarlo) con el siguiente nombre "semana4-[idDeUsuario]".
  • Quién no cumpla con los requerimientos es automáticamente pasado al estado "deshabilitado" dentro del taller, lo cual queda fuera de las evaluaciones de los trabajos y de una futura asignación a un equipo de desarrollo en SurForce.
  • Se penalizarán todos los errores: cualquier detalle mencionado en esta entrada, más las faltas de ortografía, no uso de las herramientas oficiales, faltantes en las entregas, etc.
PD: dudas sobre los requerimientos, en los comentarios de esta entrada.

Actualizaciones
  • 23/03/2007 - se corrige redacción punto 2.

Inicio corrección de la "Semana 3" del taller

Algunos usuarios me han enviado correos preguntando si estaba vivo o si me había desmotivado, pero ya les confirmo que estoy bastante lejos de claudicar ;-)

Tirado en el piso, cansado. Mi hija mayor (3 años) me insiste en sacarme una foto con el celular (hasta que lo logra)

Como anuncié desde el principio de la creación de este "taller piloto", mi objetivo es , además de tratar de transmitirles conocimientos que permitan subir el nivel de nuestros desarrollos en PHP, que aprendamos todos de la experiencia general, así poder sacar nuestras propias conclusiones y contar a futuro con mejores herramientas para aplicarlas en proyectos que involucren todas estas disciplinas (educación a distancia, gestión, diseño, desarrollo, teletrabajo, screencasts, blogging, etc).

Una de las tantas cosas que estoy aprendiendo (gracias por todos sus comentarios respondiendo mis preguntas) es que un desafío por semana puede ser muy exigente tanto para quién lo crea como para quién debe cumplirlo. Además de recibir todos vuestros trabajos, debo corregirlos, y a su vez, quiero basarme en sus errores para ajustar el desafío siguiente (es la esencia de la didáctica que estoy usando).

Aunque parece una foto montada, es real. Mi hija preguntando "¿qué es esto?", lo cual le respondo "la representación del 'paquete de dominio', la 'lógica de negocio', ¿se entiende?" (espero que ustedes ahora también ;-))

Por lo tanto me tomé unos días para que ustedes y yo descansemos, y recién hoy estoy empezando a corregir sus trabajos (Semana3). Asumo que me llevará todo el día y en base a las conclusiones que saque a última hora les estaré publicando el desafío de la "Semana 4" (estimo que en la madrugada del domingo lo publicaré, acorde al ritmo de vida de todo vampiro ;-)).
Empezamos con 100 inscriptos, en la semana 2 entregaron trabajos 37 y en esta semana 19. Veremos con cuantos terminamos ;-)

Aquí está la planilla donde me pueden ver trabajar, durante el correr de todo el día verán cambios (la hoja de cálculo permite configurar para que cada 5 minutos se actualice su vista pública), por consiguiente, pueden quedarse junto a mi para conocer los trabajos de sus colegas y ver cuando yo les evalúe. ;-)

Si ven que la nota sube y baja, no se preocupen, hasta que no ponga la fecha de cierre la nota es provisoria ;-)

Dentro de horas más novedades.

Cerrada la Semana 2 del taller

Bueno, esta es otra de las cosas que se aprende cuando se hacen en la práctica y no solo en la teoría. Intenté hacer una segunda revisión de los trabajos pero se me hizo interminable, por lo que tuve que dejar por la mitad la escritura de comentarios individualizados (son 37 trabajos completos, con diagramas y respuestas a las encuestas).

Así que doy por cerrada esta evaluación aunque pudiera cometer alguna injusticia con algún punto sobre los trabajos, por lo cual les pedido a todos los que tengan dudas o lleguen a comparar con otros trabajos y vean diferencias en criterios, me avisan y con gusto trato individualmente de volver a evaluar ese punto.

No se olviden que los puntos, más que para valorizarlos a ustedes, son para evaluar donde ocurren los errores más frecuentes y armarme una guía de materiales a desarrollar para presentarles y solucionar sus dudas.

Resumen de mis explicaciones para cada punto de la Semana2
  1. Desafío Semana 2 - Ingeniería Inversa
  2. Comentarios sobre la evaluación
  3. Solución - Diagrama de Casos de Uso (I/IV)
  4. Solución - Diagrama de Paquetes (II/IV)
  5. Solución - Diagramas de Clases (III/IV)
  6. Solución - Cuestionarios (IV/IV)
Desde ya siguen abiertos los comentarios en cada una de esas entradas, así poder seguir profundizando los conceptos y solucionando las dudas.

Bueno, y mañana empiezo con la evaluación de la Semana3 ;-)

PD: algunos alumnos se me están perdiendo por el camino, la Semana 2 se concluyó con 37 trabajos entregados y esta Semana 3 van hasta ahora 15...

Pregunta: ¿los estoy exigiendo mucho?

Si tienen comentarios o críticas, fundamentalmente las personas que no están llegando a esta entrega, me gustaría conocerlas.

Están llegando los primeros trabajos correspondientes a la "Semana3"


Bien, esto me pone muy contento ;-). Desde el día 11 estoy recibiendo los trabajos correspondientes al desafío de la "Semana 3 ", que justamente finaliza hoy.

Siguiendo con los experimentos (creo que debo ser el resultado de uno, no lo sé) dejé disponible una planilla que actualizo regularmente para que sirva de confirmación que recibí vuestros trabajos.

Recomendaciones

  • No voy a corregir ningún trabajo hasta mañana, cuando oficialmente cierre la fecha de entrega. Luego, copio la versión original, y trabajaré sobre un nuevo documento donde yo seré el único editor. Resumiendo, todavía pueden hacer correcciones de último momento. Nota: si alguien se le ocurre un servicio para recomendar del estilo "hora centralizada en Internet", me avise (sé que existen proyectos para sincronizar reuniones con personas distribuidas geográficamente, pero no he encontrado ninguno que parezca confiable).

  • El nombre del documento debe ser "semana3-[idUsuario]", lo que se debe traducir como "semana3-23". Si se equivocaron pueden cambiar de nombre sin problemas, pues inteligentemente Google usa un link único y este no cambia una vez creado el contenido. También pueden poner sus datos personales dentro del documento, en el cabezal del mismo (nombre, usuario de gmail, país, etc), como se estila en documentos formales.

  • No comentan errores de ortografía, ni de redacción, sean concisos. De ahora en más voy a penalizar esas equivocaciones. Para las respuestas sean breves, pues sucedió en las entregas de la Semana 2 que la primer frase era correcta pero luego se iban por las nubes y se equivocaban en tonterías, tal vez, por simple distracción.
Con respecto a la revisión y cierre de la Semana 2, por un tema de tiempos y compromisos (sí, tengo vida fuera de Internet ;-)) estoy un poco demorado, pero debería concluir hoy.

Próxima apertura de los grupos de trabajo

Como novedad les confirmo, el mes próximo empezamos a abrir los grupos de desarrollo para seguir con los trabajos de forma real y práctica. Sus desafíos personales se volverán desafíos grupales, donde deberán aportar cumpliendo sus tareas. En este momento solo participarán los que han entregado los trabajos de la Semana 2 y Semana 3, y los restantes desafíos que seguiré publicando durante el mes de marzo. Posteriormente, se volverá a abrir el registro de usuarios y cambiaremos la forma de integrarlos a los equipos de trabajo existentes. Muy probablemente se les solicitará una tarea puntual que resumirá todo el proceso de desafíos y si la aprueban quedarán clasificados para participar como desarrolladores o líderes.

Dentro de poco más novedades ;-)

Explicación de la Semana 2 - "Cuestionario"

Seguimos, la última parte: explicar las respuestas que se esperaban del cuestionario propuesto como parte del desafío de la Semana 2.

Letra del cuestionario

Contestar el siguiente cuestionario (en caso afirmativo indicar claramente en que parte del fuente, en caso negativo, justificarlo de forma detallada)
  1. ¿En qué parte del sistema se realiza "herencia"?
  2. ¿En alguna parte del sistema se usa "polimorfismo"?
  3. ¿Si tuviera que agregar otro tipo de usuario, como un Administrador, qué haría?
  4. Obtenga un ejemplo de "encapsulamiento" y explíquelo detalladamente.
Respuestas esperadas
  1. La idea era forzarlos a leer todo el sistema de arriba a abajo. Si contestaban algo genérico no estaba mal pero lo consideraba incompleto, y si nombraban un solo caso, también ;-). La respuesta esperada era en dos clases concretas, en TemplateSmarty y en Usuario.
  2. Esto también les obligaba a recorrer todo el sistema, otra vez. Aquí es donde hubieron mayores fallos, lo que identifica claramente que hay un problema de conceptos y no se entendió que significa "polimorfimo" (ya armaré material extra sobre el tema). La respuesta era "no".
  3. Hubo de todo aquí, pero repasemos el contexto: estamos buscando afirmar conceptos de POO, por lo tanto aunque hay muchas opciones válidas y aplicables en muchos contextos, aquí lo esperado era usar OO entonces la herramienta a utilizar era la herencia. Por lo tanto, para crear el Administrador podría heredar de la clase base Persona, o si la nueva clase es una especialización de Usuario, lo más probable que la herencia sea sobre esta última.
  4. Aquí era meramente una pregunta conceptual y muy general. Existen de sobra ejemplos sobre el tema en el código. La respuesta esperada es "el encapsulamiento es utilizado para esconder detalles de la implementación que no necesitan conocer los objetos que son clientes de la clase que brinda sus servicios". Esto se hace a través del uso de atributos/métodos "públicos y privados" y el encapsulamiento se consigue a menudo mediante la ocultación de la información. Todo esto sirve para reducir la dependencia externa con la implementación interna de la clase. Cuanto menos se sepa de su interior, más reutilizable es porque solo dependemos de lo que hace y no cómo se hace.
Bien, terminadas todas las explicaciones... si hay alguna que duden o discrepen, bienvenidos sus aportes en los comentarios de esta entrada.

PD: tal vez por el cansancio extremo puedo haber cometido un error sin darme cuenta, así que los que saben del tema no tengan reparos en corregirme ;-)

Explicación de la Semana 2 - "Clases" (III/IV)

Bien, seguimos con la parte de los diagramas de clases correspondiente al desafío de la Semana 2.

Empecemos con algunas puntualizaciones:
  • Igual que con los casos de uso, según quién sea el usuario objetivo de la documentación UML esta tendrá más o menos detalle.
  • Los "get / set" no son necesarios documentar, lo mismo con toString y el constructor (aunque este último puede documentarse si representa alguna información importante como en el caso del patrón de diseño Singleton)
Tratando de mantener un perfil "pragmático" ("simple y sencillo") los diagramas de clases los presento por paquete y no todos juntos (a los efectos es lo mismo, pero aporta un poco más de claridad).

Para el paquete "Presentación"

Básicamente es eso lo que hay en la capa presentación, una clase Fachada que se encarga de recibir todas las peticiones del exterior y derivarla luego a la clase correspondiente (esta estrategia se aplica en todas las capas), así se evita acceder desde fuera del paquete a cada clase que lo compone (un tema de orden y simplificación, de lo contrario sería una enredadera con invocaciones de todos lados).

Nota: como en java, el "void" representa que ese método no devuelve valor alguno.

Para el paquete "Dominio"

El DominioFachada tiene una flecha punteada que representa la dependencia ("relación de uso") con la clase Usuario, lo cual significa que en algún momento o recibe la clase por parámetro o la crea dentro de algún método (en este caso es la última opción).

Nota: aparece una nueva representación de UML, una "nota" (el dibujo representa una hoja con la punta superior derecha doblada), donde se puede agregar comentarios con respecto al diagrama o a partes del mismo (se suele agregar una flecha que va desde la nota al elemento del diagrama que se está comentando). Conviene usarlo para clarificar el diagrama o hasta para poner pequeños trozos de código a modo de ejemplo para guiar la futura implementación.

Para el paquete "Persistencia"

Se ven dos métodos, uno que no tiene parámetros pero como resultado retorna un Array (o "vector") con datos y el segundo recibe un parámetro de tipo Array y retorna un Array de datos.

En este caso se usa la "nota" para evitar tener que representar la clase del framework en este diagrama y dejar esta representación para otro diagrama exclusivo. Hacer lo contrario tampoco quiere decir que está mal, es un criterio adoptado.

Respuesta esperada: lo más parecido a las clases representadas aquí, no teniendo en cuenta si se mostraban las mínimas necesarias o todas las que hay en el sistema, se evaluó fundamentalmente la construcción de las clases y sus relaciones.

Dudas sobre este tema, en los comentarios en esta entrada ;-)

Explicación de la Semana 2 - "Paquetes" (IV/IV)

Luego de comentar sobre el tema Casos de Uso y la respuesta que se esperaba para el desafío de la Semana 2, prosigo con la explicación sobre el tema de la representación de "paquetes" en UML.

Antes de empezar cabe aclarar que cada paquete a su vez representa una "capa" o nivel de nuestro sistema. Se dice entonces que nuestro sistema "está dividido en 3 capas", cada una con una responsabilidad bien definida.

Aquí podemos apreciar 3 posibles diagramas de paquetes. La figura 1 representa el diagrama clásico cuando se quiere representar un sistema dividido en 3 capas:

  • Capa de Presentación: sección donde tiene la responsabilidad de recibir datos y presentarlos o de armar interfaces para interactuar con el usuario. No importa en qué esté hecho, si en PHP o en un sistema de Templates como Smarty, lo que importa es que cumpla con una sola responsabilidad, representar los datos (nada de ir hacia la base de datos ni resolver problemas del sistema; recibe datos y los muestra).
  • Capa de Dominio: al existir una línea punteada entre la capa de presentación y la de dominio estamos definiendo por diseño que una capa "usa/necesita/se comunica" con la capa de más abajo. La capa de dominio es la también llamada "lógica de negocio", donde verdaderamente se resuelven los problemas de nuestro sistema. Esta es la capa más importante, pues en un futuro podemos cambiar el sistema de representación de los datos y sacaremos el paquete actual de presentación y lo cambiaremos por otro, pero el dominio seguirá existiendo como hasta ahora, pues ahí se resuelve el verdadero funcionamiento de nuestro sistema.
  • Capa de Persistencia: cuando la capa de dominio necesita los datos de un usuario, a pesar que cuente con la definición de la clase Usuario, necesita pedirle a una nueva capa que se conecte con el dispositivo de turno y retorne los datos para luego armar el objeto. Esta capa es la especializada en esa tarea, de la misma forma que la de presentación, puede ser una capa muy volátil y pasible de ser sustituida por otra (un paquete que soporta solo mysql es cambiado por otro que soporta postgres o un conjunto mayor de bases de datos).
Comentario al margen: a pesar que este es el diagrama tradicional para representar las 3 capas (los sistemas pueden tener perfectamente n-capas, no solo 3) la capa de persistencia debería apuntar a dominio y no al revés. Aquí se va evidenciando claramente la importancia del significado del sentido de las flechas. Como está ahora el diagrama, cualquier cambio que se haga en el paquete de persistencia afectará al paquete de dominio, como ya dijimos, el más importante del sistema (grueso error).

Acercándonos más a nuestro entorno

En la figura 2 represento el archivo index.php (como ya dijimos, estándar y necesario que exista) como ejemplo de por donde debería iniciarse la invocación de nuestro sistema. Nuestra clase inicial recibe la invocación del usuario y pasa su petición a la capa de presentación para solicitarle que arme la interfaz correspondiente, luego, si esta capa necesita representar una lista de usuarios deberá solicitarle a la capa de dominio esta información, y finalmente, la capa de dominio le deberá pedir a la capa de persistencia los datos almacenados en el sistema correspondiente. Luego de hacer este "pasamano" entre capas, todos retornarán "mensajes" hacia la capa superior, generando finalmente una respuesta desde el archivo "index.php".

Nota: como en PHP no todo son objetos, no podemos usar la nomenclatura para los nombres de archivos de objetos: Index.class.php, debemos seguir usando index.php o el servidor no encontrará la página inicial. De todas formas podemos seguir la convención de que internamente y a pesar de no respetar el nombre, existe una clase Index (evitando código estructurado).

Algunas puntualizaciones conceptuales
  • Un paquete es un elemento para agrupar otros elementos: una clase, una interfaz, otros paquetes.
  • Un paquete = un directorio: En lenguajes como PHP y Java la traducción de "paquete uml" se representa como un subdirectorio, la esencia es la misma: "contenedor de otros elementos", permitiendo un almacenamiento recursivo (un paquete puede contener otros paquetes dentro).
  • El nombre del paquete: El nombre siempre va en minúsculas y las flechas de relación siempre son de "uso" (punteadas).
  • La flecha punteada: representa que hay una relación de uso (en un solo sentido) entre los paquetes (paquete "presentación" usa al paquete "dominio", etc).
Definir una convención para nuestro contexto
  • Como en Java todo es un objeto, es natural ver a diestra y siniestra representación de clases en un diagrama UML. PHP no es un lenguaje 100% OO, pero podemos intentar hacerlo y convenir que absolutamente "todo son clases" y no permitir que exista ninguna línea fuera de una clase, pero:
    • El index.php siempre debe existir: Si fuera Index.class.php nuestro servidor no encontraría esta página por defecto.
    • Se puede agregar al diagrama todos los "módulos" como clases: pues internamente estarán implementados de ahora en más como una clase pero usando el nombre habitual de los archivos PHP: nombre_nombre.php. En nuestro sistema de ejemplo podemos ver listado_usuarios.php, consultar_usuario.php, mostrar_usuario.php, etc.
Solución esperada: la figura 1 sin la flecha entre presentación y dominio, o algo similar a la figura 3. En el sistema entregado (surforce-proyectobase) no existe -intencionalmente- la comunicación entre capa de presentación y la capa de dominio.

Todas las dudas serán respondidas en los comentarios de esta entrada ;-)

Más información

Explicación de la Semana 2 - "Casos de Uso" (I/IV)

Esta es la explicación complementaria para la parte "casos de uso" del desafío de la Semana 2. Quiero aclarar que no me voy a limitar a decir solo lo que se esperaba como respuesta del desafío, buscaré ahora reforzar algunos conceptos sobre el tema.



En el gráfico dos opciones posibles. Una más descriptiva que la otra, pero ninguna comete el error de entrar a descomponer las funcionalidades del sistema como si estuviéramos ya desarrollando.

¿Cual de las dos opciones es correcta? Ambas lo son, pues describen la realidad pero toda documentación se deben ajustar a un contexto: ¿quién es el público objetivo de la documentación?. Si son los clientes del proyecto se podría usar la versión 1, pero si son desarrolladores (con más razón si cuentan con poca experiencia) tal vez se podría usar la versión 2 que explica con un poco más de detalle la funcionalidad que tendrá el sistema.

Algunas puntualizaciones sobre el tema de los diagramas de casos de uso:
  • Para qué se usan: Los Casos de Uso son empleados para descubrir y capturar requerimientos de los clientes en una forma que sea accesible para todos los participantes del proyecto, tanto desarrolladores como clientes.
  • Qué deben comunicar: Un Caso de Uso describe QUÉ hace el sistema sin decir CÓMO lo hace.
  • Qué representan: una o varias funcionalidades de nuestro sistema que ofrecen valor al usuario del mismo. Si lo que estamos documentando ("el globo") no devuelve ningún valor al usuario, no debe considerarse un caso de uso.
  • Flecha"include": es cuando un caso de uso incluye otro caso de uso. El caso base incorpora explícitamente el comportamiento del otro. En ambos casos el sistema lista ("listar usuarios") o consulta ("consultar usuario") para llegar a mostrar finalmente toda la información del usuario como si fuera una ficha ("mostrar usuario") que en nuestro caso se hace dos veces (se llega por dos caminos distintos a la ficha del usuario).
  • Los nombres de los casos de uso: preferiblemente que sean descriptivos de la acción o el valor que generan al actor del sistema. En vez de usar términos como "Listado de Usuarios" se usa una expresión más genérica que describa la acción o uso en el contexto del sistema: "listar usuarios".
Esto es lo básico de los Casos de Uso, pero hay algunos detalles más. Por ejemplo, la documentación que debe acompañar a cada caso es tan importante como el propio diagrama. Debe describir con palabras el comportamiento del caso de uso, su curso básico y sus cursos alternativos.

Por ejemplo, para el caso de uso "consultar usuario":

Curso Básico
  1. El usuario ingresa el id o el nombre del usuario
  2. El sistema lo encuentra y muestra la ficha del usuario
Cursos alternativos
  1. Si el usuario no ingresa ni id ni el nombre el sistema envía un mensaje de error
  2. Si el sistema no encuentra el usuario envía un mensaje de ayuda y posibilita volver a intentar la consulta.
Todo esto es parte de la documentación de una "Especificación de Requerimientos" o "ESRE" que se origina luego de una entrevista con nuestro cliente y este nos cuenta qué desea que haga el sistema (existen muchos templates para usarlos como ejemplos).

Relación entre Casos de Uso y los "módulos" de nuestro sistema

Podemos hacer un paralelismo en nuestro contexto: cada caso de uso puede convertirse literalmente en un "módulo" de nuestra aplicación:
  • Caso de Uso "Listar Usuarios" -> listado_usuarios.php
  • Caso de Uso "Consultar Usuario" -> consultar_usuario.php
  • Caso de Uso "Mostrar Usuario" -> mostrar_usuario.php
Detalle final

En muchos casos pude ver trabajos que incluían el "index" como un caso de uso. A pesar de que nuestro sistema siempre tendrá uno, no necesariamente hay que representarlo (cuanto más minimalista el diagrama, mejor). Lo más realista sería que si nuestro "index" ofrece algo más que información estática (como sucede en el "proyecto base") se podría considerar que ofrece "valor" al usuario. Por ejemplo, si la página principal fuera un sistema de noticias, ordenadas cronológicamente, con posibilidad de comentarios, etc, sí lo agregaría como un caso de uso y lo nombraría "mostrar noticias" (no necesariamente "index", estoy contando la funcionalidad, no cómo la voy a implementar ni en donde).

Espero haber aportado un poco más sobre el tema y haber despejado algunas dudas. Cualquier otra consulta está disponible la sección de comentarios de esta entrada ;-)

Dos frases que ultimamente están guiando mis pasos...

De casualidad, durante el proceso del taller, me fueron brotando dos sentimientos. El primero, dirigirme hacia donde siento naturalmente que debo ir sin importar si me equivoco o no, sin tener miedo a experimentar. El segundo, cómo hacer para organizar algo tan grande, casi en solitario. Siempre llegaba a la conclusión que la única forma es dividir el problema en muchos problemas pequeños, y luego, delegar pequeños conjuntos de problemas a otras personas.

Por suerte hay tantas frases dichas en la historia que existe una para cada situación, así que encontré las que necesitaba para "auto-justificarme" ;-)

Cuando alguno de mis colegas, a los cuales estoy eternamente agradecido por sus profesionales consejos, me sugieren "caminos probados", ejemplos de libros reconocidos, recuerdo:


"Nunca vayas por el camino trazado, porque conduce hacia donde otros han ido ya"

Alexandre Graham Bell

Y cuando me bloqueo pensando cómo gestionar y manejar tanta cantidad de información:

"El secreto para progresar es empezar. El secreto para empezar es dividir las tareas complejas y abrumadoras en pequeñas tareas y empezar por la primera"

Visto en
Microsiervos

Hasta el momento me vienen funcionando ;-)

Taller PHP5: Borrador con los resultados de la Semana 2


Porque soy histérico y detallista, y por un tema de respeto hacia ustedes, estos resultados deben considerarse un "borrador" de la nota final. Recuerden que la idea no era "hacer todo bien", la primer exigencia era el "compromiso" y entregar el trabajo con lo poco o mucho que pudieran haber entendido de los materiales que leyeron.

Posteriormente, en los próximos días, revisaré nuevamente los trabajos y les haré comentarios sobre cada uno de -en mi opinión- los errores que cometieron en base a lo que se esperaba.


Agregué una columna que se llama "Cerrado" (en rojo) donde al colocar una fecha estaré confirmando que fue nuevamente verificado el trabajo, los puntajes corregidos (si corresponde) y que ahora el enlace al documento tiene los comentarios pertinentes (así pueden aprender de los errores y entender qué les estoy tratando de enseñar).


Todos los documentos son copia del original que me han compartido, así tenemos una versión "congelada" y nadie pueda modificar lo ya entregado (intencional o por accidente, no importa). También he dejado público los trabajos para seguir compartiendo información con los demás interesados que no necesariamente quieran o puedan seguir el taller, o para que ustedes mismos vean lo que sus colegas hicieron. El otro tema aquí es acostumbrarnos a compartir información y a recibir críticas logrando canalizarlas a nuestro favor.


Me imagino que muchos podrán discrepar con algunos criterios que he usado para evaluarlos, pero la idea de esta tarea es que me sirva como guía para saber qué temas debemos trabajar más y crear material extra para solucionar las dudas (constructivismo). Por ejemplo, viendo rápidamente los resultados globales podemos casi aceptar que el tema "herencia" es algo que todos entendieron no así el polimorfismo. Sobre UML vamos a tener que trabajarlo un poco más y darles ejemplos específicos de como los aplico en desarrollos que involucren Web y PHP.

Estos puntos no representan vuestro nivel o escala jerárquica dentro del taller, solo es para guiar mi camino.


Bueno, para los "impacientes de siempre", aquí está el borrador de la planilla con los resultados y los trabajos recibidos.

Desde ya felicitaciones por el esfuerzo y el compromiso ;-)

Comentario al margen:
mi evaluación ya estaba pronta el mismo lunes, pero tuve que esperar a casi 10 usuarios que en vez de "compartirme" el documento como "editor", solo estaba como "lector" del mismo, impidiéndome hacer una copia del trabajo. En esta entrega fui bastante flexible (aunque muchos no lo crean así), y comprendí que las herramientas son en general nuevas para ustedes... algo que no va a pasar en las próximas entregas (tengo que irles soltando la mano progresivamente para que aprendan a caminar solos).

Taller PHP5: "Semana 3 - correcciones en el diseño de 3 capas" (actualizado 7/3/2007)

El Gerente de Proyectos luego de haber leído cada uno de los informes de sus postulantes se percató que el sistema no está correctamente implementado y que existen varios errores, por consiguiente (luego de despedir a dos líderes y un especialista en testing) decide volver a asignar un desafío:

Pre-requisitos

El equipo de desarrolladores siguió trabajando en el sistema durante el correr de la Semana 2, por lo tanto en el repositorio SVN existen cambios que deberán ser actualizados con respecto a la versión local de cada postulante.

Nota: no se puede cumplir con la Semana 3 si el sistema no corresponde con la última versión disponible.

Diseño en 3 capas

Luego de ver la gran variedad de diseños propuestos por los postulantes nos percatamos que nuestro diseño tiene fallas, las cuales queremos ahora que solucionen y que nos entreguen un informe explicando detalladamente todos los cambios que deberían hacerse.

Diseño actual, con errores

Diseño corregido, lo que se solicita implementar

Consultas de Usuarios incompleta

De la misma forma, se ha verificado que el sistema presenta faltantes en la programación de las funcionalidades. El formulario de búsqueda no permite encontrar usuarios por nombre, por consiguiente, se solicita que documenten toda la implementación y que esta esté acompañada de un "Diagrama de Secuencia" (UML) para verificar que la lógica del diseño sea la correcta. A su vez, se agrega un nuevo campo "descripción" que se solicita agregar al sistema de consultas.


Cuestionario

Según el diagrama correcto la clase Index depende del paquete Presentación, el paquete Presentación depende del paquete de Dominio, y el paquete de Dominio del paquete de Persistencia.
  • ¿Cómo se representa en código PHP la existencia de una dependencia entre estos elementos?
  • ¿Analizando estas dependencias en sentido inverso, cómo se representa en código PHP?
  • ¿Cómo se verifica que existan cambios (y cuales fueron) en el repositorio SVN?
Forma y límite de la entrega

  • Seguiremos manejando un período de 1 semana, como este lunes fue un día muy complejo para procesar todos los trabajos, lo haremos de miércoles a miércoles: vence el 14 de marzo
  • Documento "compartido" (que permita modificarlo) con el siguiente nombre "semana3-[idDeUsuario]".
  • Quién no cumpla con los requerimientos es automáticamente pasado al estado "deshabilitado" dentro del taller, lo cual queda fuera de las evaluaciones de los trabajos y de una futura asignación a un equipo de desarrollo en SurForce.
  • Se penalizarán todos los errores: cualquier detalle mencionado en esta entrada, más las faltas de ortografía, no uso de las herramientas oficiales, faltantes en las entregas, etc.
PD: dudas sobre los requerimientos, en los comentarios de esta entrada.

Actualizaciones

7/3/2007
  • #2 - bueno, sigo con los errores pero involuntarios, el diagrama que representa el diseño incorrecto tenía de más la flecha que va de Presentación a Dominio. Si vuelven a observar el "sistema base" verán llamadas a ambas capas únicamente desde los módulos (index.php, listado_usuario.php, etc).
  • #1 - cometí un error en describir el contexto de las preguntas del cuestionario. Describí con palabras index->presentación->persistencia y debería ser index->presentación->dominio->persistencia (exactamente lo que dice el diagrama)

Espero que el taller les pueda dejar alguna conclusión sobre "teletrabajo"...


Comento en mi blog personal que hoy recibí un correo y un posterior "chat" ofreciéndome ser "freelance" o mejor dicho, "trabajador a distancia". Esto es lo que ocurre habitualmente en Internet, lo he visto tanto en empresas "juniors" como "seniors", donde lo que buscan fundamentalmente es aprovecharse "a distancia" de los trabajadores.

Hay varios puntos que hay que tener en cuenta:
  • El chat no sirve para trabajar, menos para gestionar un proyecto
  • El correo bien escrito no se diferencia de ningún documento formal impreso que puede existir en las grandes organizaciones para documentar sus procedimientos.
  • El trabajo a distancia debe medirse por "obras" o "tareas específicas", es imposible que no existan problemas si se intenta hacerlo "por horas" o cumpliendo un "horario a distancia". ¿Cómo se manejarían situaciones de husos horarios distintos? (entre otras cosas).
Nosotros estamos indirectamente probando cómo definir alguna metodología formal y documentarla sobre cómo debería ser una empresa que trabaje seriamente a distancia, tanto con sus clientes como con sus empleados.

No he visto ejemplos reales ni documentados, por esa razón, juntando muchas ideas se arma un proyecto como este Taller "piloto" a Distancia, que involucra programación, diseño, gestión de proyectos, recursos humanos, teletrabajo, e-learning, etc.

Veremos en qué y cómo terminamos, y si sobrevivimos a la experiencia.

PD: a veces me siento como David Blane dentro de la pecera tratando de probar quién sabe qué a través de una proeza completamente arriesgada y estúpida ;-)

Final de la semana 2: ¡37 trabajos entregados!

Interesante. Según mi estimación pensé que de 100 personas registradas iban a entregar trabajos en el entorno del 50%, y hasta hubieron colegas que me decían que iba a superar largamente esa cifra. Concretamente ahora tengo 37 trabajos recibidos (ya se cerró la recepción) y ya evaluados (fui corrigiendo cada vez que llegaba uno). En un rato les publico el documento con el primer resumen y el resultado de cada parte del trabajo solicitado (creo que merecería hacer una segunda revisión de mi evaluación, pero no sé si dará el tiempo).

Hay que tener en cuenta que debe haber un mecanismo de evaluación de los trabajos y cada puntuación fue dada de acuerdo a mi personal punto de vista. No soy un gurú consumado ni busco ser una eminencia en el tema, pero en sí los puntos me dicen donde debo trabajar más y tratar de aclarar las dudas y/o definirles un criterio de ahora en más para solucionar determinados problemas de diseño bajo el particular contexto de la web y PHP5.

Por consiguiente, a pesar que hay muchas variaciones en los puntos, el margen entre los extremos es bastante pequeño y calculo que la mayoría cometió errores menores, tanto de observación, descuidos o interpretación de la letra (en la próxima evaluación voy a restar puntos por faltas de ortografía).

En unas horas les presento la primer versión del resumen con los resultados.

Semana 2: Hasta el momento 16 trabajos recibidos...

... y todavía faltan 24 horas. Son las 2am y ya tengo corregidos todos los trabajos que recibí. Voy a esperar a que culmine el plazo para analizar donde radican las debilidades y reforzar esas dudas -muy probablemente- con screencasts.

Comentaba hoy a otro usuario que mi estimación era que solo iban a responder el 50% de los inscriptos (100) , pero esto viene realmente lento... veamos que pasa en el correr del día (parecen elecciones presidenciales). Teniendo en cuenta mi experiencia en la universidad es muy posible que se reciban muchas más sobre la hora de finalización (5/3 - 23:59) ;-)

La idea es confirmar sus conocimientos, qué adquirieron, donde fallan, y ver de remediarlo definitivamente con apoyo extra. También sirve de filtro para evaluar vuestro compromiso con el proyecto, algo que será crítico una vez que se empiecen a abrir los grupos de desarrollos de sistemas y tengan que interactuar con un líder de grupo y con otros desarrolladores en sus mismas condiciones.

No se dejen estar, pueden enviar todos los trabajos quienes:
  • Estén inscriptos y hayan recibido confirmación
  • Estén inscriptos y no hayan recibido confirmación (la confirmación se hará posteriormente)
  • No estén inscriptos pero tienen los requerimientos prontos (veré de darles de alta internamente)
Pasado el plazo de este lunes, el mecanismo para auto-capacitación y evaluación cambiará conceptualmente, como así también la forma de asignación a los grupos de trabajo.

¡Buena suerte a todos los que enviaron su parte, ya comunicaré los resultados! ;-)

Semana 2 - "Todos deben cumplir con la entrega"

Me han consultado esta duda y paso a comunicar la respuesta a todos: sí, todos los postulantes, tanto líderes como desarrolladores deben cumplir con las entregas semanales.

Es una forma de:
  • Acostumbrarlos a trabajar con las herramientas
  • Repasar conceptos
  • Evaluar a cada uno de ustedes, tanto a los novatos como a los que tienen más experiencia.
Lunes, sin prórroga, deben compartir el documento con el Gerente de Proyectos (no me envíen documentos adjuntos).

PD: ya empecé a recibir los primeros informes de los usuarios ;-)

Semana 2: respondo consultas y hago algunas aclaraciones

Vayamos por partes. Creo que muchos están entendiendo mal el sentido del taller (desde siempre dije "no es un curso"), mi misión y vuestra misión. La "empresa" les dio esos requerimientos como forma de evaluarlos y a su vez de entrenarlos. Recalqué más de una vez que no se abrirían foros para hacer consultas concretas sobre las tareas, para eso tienen foros generales como ForosDelWeb. Los foros los usaremos para la comunicación "inter-proyecto", pero no para resolver sus responsabilidades.

Cada uno debe poner su esfuerzo para superar los "desafíos" (de lo contrario no lo serían) y estar preparados para cuando pasen a trabajar en equipo (se busca que aporten y no que sobrecarguen al resto de los integrantes).

Otro error grave que he visto es preguntar sobre información que se desprende entendiendo lo que se lee. Lo peor que puede suceder es que fracasemos en la "comprensión lectora", porque dificulta en demasía la comunicación, lo cual es considerado como uno de los factores a cuidar dentro de una organización de trabajado a distancia.

Respondo algunas dudas que se vieron en los comentarios:
  • Lean con cuidado cada requerimiento: si alguna duda es algo que se desprende de la letra o de la información que se asignó que estudiaran en las semanas anteriores, no se responderá.
  • Sobre los grupos de trabajo: los desarrolladores participarán primero de un mes (tal vez un poco más) de "auto-capacitación" a través de las los desafíos semanales. Una vez prontos, y con los que vayan calificando, se los irá paulatinamente agregando a un grupo con un líder asignado (asignación que se hará durante el mes de marzo).
  • ¿Se abrirán otros cursos?: no sé como vamos a terminar ni en cuantos sub-proyectos nos iremos abriendo y si esto termina en tres meses o será un proceso permanente de trabajo en equipo para desarrollar proyectos libres mientras nos autocapacitamos.
  • Sobre la forma de corrección: aprendan a "leer entre líneas". Vuestro "gerente" nunca dijo que "serán descartados" por los errores que se puedan cometer. Sí serán descartados por no cumplir en la fecha asignada o porque existan faltantes en los requerimientos. Es una forma de que permanezcan los que se han esforzado e ir depurando. No se olviden que esto es crítico para mi, o de lo contrario no podrán trabajar en equipo de forma productiva.
  • ¿El taller es muy exigente?: Estoy dejando en claro, constantemente, que lo importante es equivocarse y aprender de los errores, pero obviamente que se castigará la falta de compromiso con el proyecto. Repito: si se aceptaran participantes que no tengan voluntad para cumplir con las asignaciones, repercutiría negativamente en el grupo que se le asignará en el futuro y en el proyecto en general.
  • ¿Eres líder/desarrollador y todavía no te han asignado a un grupo?: Estoy haciendo pruebas con algunos líderes para ver como organizarnos y empezar a definir nuevos grupos. Los desarrolladores aún no están trabajando en nada que no sea las semanas de autocapacitación. De a poco voy llamando a otros líderes según vaya acumulando experiencia (no puedo probarlos a todos juntos y equivocarme con todos a la vez).
  • ¿Donde hago las consultas sobre dudas?: Si te refieres a algún desafío semanal, deberías poder resolverlo por tus medios. No te olvides que la "empresa" te está evaluando y es fundamental aprender a ser "autosuficientes". Busca, lee, prueba, investiga. Aprender a aprender.
  • Sobre los problemas con las "herramientas no oficiales" (WAMP, Enterprise Architect, Appserv, etc): La empresa es "medio necia" en ese sentido y su estrategia es usar fundamentalmente herramientas web y a su vez, que permitan la colaboración de personas de forma remota. Pero hay un punto muy claro: se seleccionaron las herramientas para que queden "uniformes" y que los problemas sean similares. Hubieron muchos que se debieron a configuraciones particulares y estas herramientas no son las sugeridas (Semana 0).
  • Cambios en el código del proyecto base: no se autorizó, por lo pronto no pueden modificarlo ustedes. Si hubiera algún cambio en el proyecto y ustedes tuvieran que actualizarlo desde el repositorio svn, sobreescribiría todos sus cambios.
  • ¿Para la entrega de la "Semana 2" hay que hacer un documento formal?: sí, usa el sentido común (sí, ese, el menos común) te estás postulando para trabajar en un proyecto y vas a tratar con el Gerente de Proyectos de forma directa. Sobre "compartir documentos"... es tan simple con Google Docs que me da pereza explicarlo (vamos, no se me queden por el camino).
  • Los desafíos son personales: comento esto porque en cada comentario de las entradas semanales hay pedidos de ayuda y soluciones a las mismas, convirtiéndose en casi un foro de consultas. Nadie les va a impedir que se ayuden, pero, deben sacrificarse y lograr aportar su "granito de arena personal". Esto quedará muy fácilmente evidenciado cuando trabajen en grupo y por consiguiente serán eliminados del taller cuando fallen reiteradas veces. Aprendan desde ya a ser "auto-suficientes" y "auto-capacitarse" (esa es la idea detrás de cada desafío semanal y del taller en si).
  • No respondo correos personales con dudas sobre el taller: ahora que soy "famoso" (broma)... no, digo, es imposible que conteste tanta cantidad de correos de forma individualizada, además, tampoco es la idea. Ese es su trabajo, y estar intercambiando correos indiscriminadamente puede hacer que colapse el proyecto por excesos en la comunicación. Así que mantengamos los canales oficiales hasta el momento (blog) y que en los próximos días iremos mejorando (wiki, foros).
  • Sobre si duermo: no, no duermo, tengo un sarcófago al lado del pc ;-)
Por ahora es todo, dentro de unas horas les hago un informe general de como va el proyecto "internamente", cuantos líderes hay trabajando, cuantos grupos, qué estamos haciendo, cómo vamos a seguir (estoy por llamar a otro grupo de líderes, así que alerta), y tal vez alguna pista más de lo que sucederá el lunes próximo.

(¡uff... no pensé que me iba a dar tanto trabajo! ;-) )

Entradas populares