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! ;-) )

Taller PHP5: "Semana 2 - Ingeniería Inversa"

Esta es la letra de la Semana2 del Taller sobre PHP5:

La "empresa" SurForce, entendiendo que el postulante ha estudiado cabalmente el material que se le sugirió como base, solicita que se apliquen los conceptos aprendidos y resuelva los siguientes requerimientos:

Preparar el entorno de trabajo

1. Bajar el "proyecto base" desde el repositorio SVN: usando las herramientas instaladas obtener los fuentes del proyecto que se encuentra actualmente alojado en el servicio Google Code.
   
2. Reconstruir la base de datos que necesita el sistema (subdirectorio "sql").
3. Probar todas las opciones del sistema

Documentar el sistema

Se necesita hacer "ingeniería inversa", es decir, usted recibe un sistema que desconoce y que no cuenta con documentación. Se le solicita que analice el sistema y presente una documentación que contenga los siguientes diagramas UML.

1. Diagrama de "Casos de Uso"
2. Diagrama de "Paquetes" (presentación, dominio y persistencia)
   
3. Diagrama de "Clases" de cada paquete.
   

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.
   

Forma y límite de la entrega

Tienen una semana para investigar, experimentar, y aplicar los conocimientos. El plazo de entrega es el próximo lunes sin prórroga.

Para la documentación deberá usar las siguientes herramientas:

• Google Docs - deberá realizar un documento "formal" con toda la información que se le solicita. Luego de finalizado, deberá compartir el documento con el Gerente de Proyectos. El documento deberá llamarse "semana2-nombredeusuario".
  
• Gliffy - se usará para hacer todos los diagramas UML, que luego deberá grabarlos en un archivo gráfico y agregarlos al documento base (punto anterior).

IMPORTANTE: El desarrollador que exceda de esta fecha límite (lunes 5 de marzo) o que en la documentación falte alguno de los requerimientos, será descartado del taller.

PD: todas las dudas sobre los requerimientos podrán hacerse en los comentarios de esta entrada.

Semana 1 - contesto las dudas de los usuarios

Voy a tomar algunas dudas de participantes del taller para contestarles a todos en general (los ">" representan los textos de mi interlocutor):

Estimado Edu T:

> Voy a dar alguna opinión personal
> por si tienes a bien tenerla en
> cuenta.

Todas las opiniones, sugerencias o críticas se usan para tener otros puntos de vista y contrastarlos con los nuestros, así que bienvenidas!.

> 1º Me he apuntado al curso hace
> ya mucho y aparezco en el
> "mapita", nunca me quedó muy
> claro si eso era el sistema de
> registro de alumnos o sólo un
> modo de darse a conocer,
> finalmente he visto que "eso" era
> el sistema de apuntarse.

Bien, es uno de los temas de estudio en este taller, el gran problema de todos los proyectos y particularmente, de los seres humanos: "la comunicación".

Si recorres las entradas por la etiqueta "taller" encontrarás ordenado cronológicamente los pasos que fuimos dando (el más reciente primero):

• "Tallerphp5: registrate en el mapa" con la explicación que momentáneamente nos registraremos en el mapa para conocernos (poder saludar y decir "¡Aquí estoy!") y de alguna forma cuantificar cuantos interesados había y de donde eran.
  

• Luego, con la entrada "Semana 1" se aclara el tema de los grupos/foros de discusión que se van a armar para nuclear la comunicación entre los participantes y el tema de crear un Wiki para centralizar la información que se genere (procedimientos, metodología, documentación, screencasts, FAQ, lista de proyectos, etc).

Pero como esto es un "experimento" y vamos aprendiendo sobre la marcha, todo lleva su tiempo de organización hasta pulir la forma de trabajo.

Es como tú bien dices, tenemos que pasar a un modelo centralizado de documentación o nos perderemos en la comunicación desperdigada y generará muchos malos entendidos.

Se ha progresado, lentamente, pero de forma calculada (iré aumentando la velocidad con las semanas). Lo que trato de evitar es hacer pruebas con todos juntos, a la vez. Pruebo con un grupo, cometo errores, cambio la óptica del problema, lo pulo, y luego voy agregando más integrantes al proyecto.

Hasta el momento hay:

• 2 muy buenos asesores en desarrollo PHP5 (GatorV y WebStudio)
  
• 2 excelentes asesores que son docentes en gestión de proyectos y educación a distancia (Mauro y Rafael).
  
• un primer grupo de desarrollo (Sistema "Gestión Taller") al cual se le han asignado los primeros desarrolladores a su "líder de equipo". En horas se les está asignado la tarea de solucionar el problema de seguridad y aumentar la calidad del código para evitar posibles nuevos errores (refactoring).
• Posteriormente, se habilitará nuevamente el sistema de registro, el cual no tendrá ningún límite máximo de usuarios ni de tiempo. Se usará de ahora en más como una "bolsa de trabajo virtual" y paulatinamente se los irá contactando para ser asignados a un grupo de desarrollo.
  
• Está definida una forma de evaluar a todos los que se han postulado como líderes (gracias a los asesores en gestión) y en las próximas horas se les comunicará por correo a cada uno.
• Hay 5 foros prontos para trabajar sobre 5 sistemas concretos. Una vez definidos los líderes de grupo se asignarán los desarrolladores para cada grupo (por esa razón podemos seguir demorando unos días más).
• El lunes próximo inicia la Semana 2 y está todo pronto: buscaré que apliquen los conocimientos conceptuales que debieron haber acumulado en la Semana 1 (por eso no habilito aún los foros, quiero que se den "la cabeza contra la pared" así aprenden).
  

> 2º He hecho mis tareas de la "Semana 1"
> y se me ocurrió ver si alguien te había
> hecho alguna consulta o preguntado
> alguna duda sobre sus estudios.

Te aclaro, mucho del trabajo semanal es de "autocapacitación", se busca que sea en solitario. De todas formas iré apoyándolos a través de screencasts, pero que nunca serán un resumen o sustituto de vuestro propio estudio.

La idea de estas semanas es que las tomen dentro del siguiente contexto:

"La empresa SurForce les ofreció integrar su equipo de teletrabajadores y usará un primer mes para evaluarlos y ver como se desempeñan. Les darán pautas para estar prontos para trabajar en equipo. Si ustedes no logran seguir estos requerimientos la empresa dudará de sus capacidades de adaptación y si ustedes pueden ser desarrolladores independientes."

La etapa de trabajo en equipo se aplicará en el segundo mes del taller (aproximadamente).

> Mi primer "problema" fue encontrar dónde
> la gente te plantea sus dudas

Atención: este "piloto" está pensado para ser un taller, no un curso, y buscará ser sumamente práctico. Por eso recreamos este contexto virtual de "empresa". No se van a crear exclusivamente foros para solucionar dudas sobre tareas que deberían resolver ustedes (para eso existen foros especializados para esos menesteres). Se usarán sólo para comunicarse dentro del equipo de desarrollo, y no para descansar en el esfuerzo de otro desarrollador. Un equipo depende del trabajo de todos sus integrantes, del aporte de cada uno de ellos por una causa común.

Si no se logra esa "sinergia", el líder debería detectarlo y resolverlo con el "gerente de proyectos" (tal vez moviendo de grupo, o sacándolo de la "empresa"). El que no cumple, no se esfuerza, no rinde, perjudica al que sí lo hace (no estoy inventando nada nuevo, así es la realidad).

> ¿en los comentarios de "Semana 1"? ¿En siguientes posts sobre el sabotaje?

En las entradas está la información oficial. En los comentarios de esa entrada se discute el tema puntal, o algunas dudas. En la entrada sobre "sabotaje" solo sobre ese tema. Cuando se suman muchos comentarios y algunos aportes comunican detalles importantes, hago una nueva entrada en la página principal resumiendo todo (para que nadie se pierda si no lee todos los comentarios).

> La respuesta ha sido: en todos ellos;
> lo cual resulta "engorroso", como opinión

Bien dicho, por eso se creará un Wiki pero lleva tiempo. Si hay algún participante que quiera colaborar con esta tarea, que me avise.

> 3º Las definiciones de la wikipedia son
> bastante técnicas y en algunos casos
> yo diría que poco claras. ¿Se podrían
> añadir "otros enlaces relacionados"?
> De este modo podríamos disponer de
> más información con distinta "narrativa".

Exactamente, me has leído la mente ;-)

Varios puntos:

• La idea es buscar comprender los conceptos (obviamente eso generará dudas). Pero los apuntes que se dieron son puntos de partida, luego, ustedes deben seguir su propio camino de investigación.
  

• La "empresa" te dio ese material, y tu quieres el trabajo y sabes que no puedes estar preguntando a cada rato para que te auxilien... que harías entonces?

> Son sólo unas ideas...lo principal es
> que el esfuerzo/ que estáis haciendo
> vale la pena para muchos, entre
> los que me encuentro.

Una de las tácticas que me gusta hacer en los cursos "presenciales" es la de "Karate Kid" (mis ex-alumnos lo saben muy bien):

• les doy una serie de caminos a recorrer y no les digo hasta que llegan al final cual era la intención. Lo opuesto a ver una película sabiendo de antemano el final. Lo que enriquece es el proceso de investigación y descubrimiento que ofrece la ruta intencionalmente marcada, no necesariamente saber la conclusión final.
• La otra táctica es "contextualizar siempre": justamente hoy lo comentaba otra vez, yo aprendí verdaderamente a "aprender" en mi edad adulta, pues considero que mis años de enseñanza "mecánica" de la primaria y el liceo no me aportaron mucho, pues carecían de toda practicidad. Casi nada de lo que aprendimos supimos para qué nos iba a servir en la vida real.
  

Esa experiencia es la que trato de transmitir. Todo sumamente ligado con su aplicación, tratando de aprender sobre la práctica, la experimentación, con el apoyo de los conceptos y la teoría.

Increíblemente luego de investigar el proyecto OLPC, me di cuenta que el mecanismo pedagógico que usan se llama "Constructivismo", que es el mismo que muchos habremos llegado a usar sin saber que tenía un nombre:

"... una corriente que afirma que el conocimiento de todas las cosas es un proceso mental del individuo, que se desarrolla de manera interna conforme el individuo obtiene información e interactúa con su entorno"

> Edu T (Burgos/España)

Estimado Edu, gracias por tus preguntas. Me dieron un buen punto de partida para comentar varios temas que pueden aclarar dudas a otros.

Sabotaje 1: resumen y comentarios

Respondo todas las consultas recibidas sobre la situación luego del "intento de sabotaje" contra el "mini sistema de altas" para registrarse en el "taller piloto":

• No hubieron pérdidas de datos: el sistema de altas fue desarrollado con la misma intención que los futuros sistemas que intentaremos desarrollar, "aprender conceptos". No estamos usando ninguna herramienta extra para auxiliar el trabajo ni la seguridad del sistema. La idea es bien clara desde el principio: "aprender de nuestros errores".
  
• Seguridad & SQL Injection: Se discutió exactamente esta situación y llegamos a la conclusión de que además de reforzar todas las entradas contra posibles ataques de este tipo, se hiciera un buen respaldo de datos. La base de datos se respalda muy regularmente, pero además, como respaldo alternativo el sistema nos enviaba un correo ni bien el usuario terminaba su registro, con sus datos personales y su correo. Por consiguiente, solo se perdieron tres registros de los 100 de la base de datos, pero disponemos de los datos suficientes para enviarles un correo y pedirles nuevo ingreso.
• Límite de inscripción al taller: originalmente no teníamos planificado ningún límite (recordar: esto es una experiencia piloto para experimentar sobre muchos temas), puesto que es natural pensar que la cifra de inscriptos sería razonable, pero luego de superar los 50 hace recapacitar a cualquier persona. Si sumamos además de las naturales preocupaciones de cómo gestionar tanto volumen de personas, de forma distribuida, un intento (completamente esperado) de "sabotaje", decidimos momentáneamente suspender el registro en los 100 inscriptos. Como la idea siempre fue aprender, estoy evaluando cambiar este límite "circunstancial" y volver a habilitarlo de forma indefinida, pero agregando nuevos criterios de selección y metodología de trabajo.
• Luego del registro, se procesó la aceptación del postulante: había llegado a aceptar hasta la mitad de los registrados y estaba empezando a definir con mis "asesores en gestión" el mecanismo de evaluación de los conocimientos de los "líderes de grupos" (cabe recordar que en el registro se les hacía una encuesta sobre sus conocimientos y a que puesto se postulaba). El proceso se suspendió momentáneamente luego del incidente de hoy, pero pienso retomarlo en el correr de los días (ahora cambiamos las prioridades).
• Cambio de Prioridades, asegurar el sistema de registros: por obvias razones ;-). Como se anunció desde el principio, la idea no es que yo desarrolle los sistemas, es darles pautas para formar pequeños equipos de desarrollo y puedan autogestionarse. Lo que empezaron a trabajar en estos primeros sistemas sabían de antemano que el terreno iba a ser "duro", pero que no me importaba que destruyeran el sitio mientras eso sirviera para complementar la "experiencia" (¡talibanes, gracias nuevamente por colaborar con el taller!). La forma de los respaldos fueron un seguro para no perder la base de usuarios y poder continuar con el taller. Nota curiosa: justamente pocas horas antes pensaba que era extraño que no nos hubieran intentado vulnerar de alguna forma, y volvimos a tratar el tema de las medidas de contingencia.
• Sobre los contenidos del taller: procederé de la misma forma que he venido trabajando en este blog, compartiendo todas las experiencias del proceso del taller, tanto relacionadas con PHP5 como sobre la gestión a distancia, herramientas, dudas, conclusiones, etc. La idea es generar "contenido", compartirlo, y construir un feedback que nos retroalimente. No me considero "experto gurú consumado" en ninguna área, tampoco en PHP5 ni en gestión de proyectos (nunca terminas de aprender), pero siempre estoy tratando de conocer mis límites y forzarme a superarlos como obviamente es este taller, sobre algo que me supera completamente pero que voy a disfrutar tratando de concretarlo de la forma más creativa posible.
  
• Voy a cambiar de rumbo, constantemente: por todo lo anteriormente expuesto. Creé una situación que me supera y que no domino, pero por consiguiente estoy tratando de generar la "sinergia" con los arriesgados "conejillos de indias" (ustedes) y con amigos y colegas que invité o que se ofrecieron a acompañarme en algo por lo que no han dejado de decirme que estoy loco. Así que paciencia, la idea es aprender juntos y sacar todos provecho del proyecto "piloto". Cuando sea la hora de que ustedes empiecen a trabajar en sus grupos de desarrollo solo espero la misma pasión y entrega que yo mismo estoy ofreciendo.
  
• Sobre el incidente concreto: sí, voy a ir comentando lo que vayamos haciendo al respecto y cualquier otra información que aporte conocimientos a otros desarrolladores. He invitado a dos colegas expertos en PHP5 que jugarán como nuestros "asesores técnicos": Christopher Valderrama (México, alias GatorV, colaborador de www.forosdelweb.com) y a Pablo Rigazzi (Argentina, alias Webstudio, autor de www.zonaphp.com y moderador en www.forosdelweb.com ).
  

En resumen: todo esto es parte de la idea original, y cada nuevo problema que se presente es un mundo para explorar. Uno de los mayores problemas (que muchos se preguntarán) es "¡¿cómo lo gestiono?!" ;-)

En las próximas horas iré agregando más novedades y contactando a cada uno de ustedes, por orden de ingreso, y asignándoles un grupo de trabajo con tareas.

Tampoco se olviden, la "Semana 1" de autocapacitación está corriendo y el lunes próximo comienza la "Semana 2" con tareas "muy relacionadas" con los temas que supuestamente ya han estudiado ;-)

Seguimos en contacto.