Últimas horas para inscribirse al Grupo 5 del Taller POO/PHP5

Al momento ya hay 13 personas activas en el Grupo 5 del taller, por lo tanto quedan 7 lugares disponibles (como tope para que el grupo no se desborde) y lo recomendable es que si alguien más quiere inscribirse lo haga entre hoy y el fin de semana, ya que se encuentran disponibles todos los materiales de la semana y la letra para la nueva tarea que tiene como plazo de entrega el martes 4/10 a las 23:55.

Si quieres inscribirte el lunes ya te diría que estarás sobre la fecha y tendrás riesgo de atrasarte con la semana siguiente.

Último llamadooooo..... ;-)

¡Se abrió el Grupo 5 del Taller POO / PHP5!

A pedido de varios usuarios que habían quedado fuera de los anteriores grupos doy por inaugurada la apertura de este nuevo grupo para el taller de POO / PHP5.

Todos los interesados deberán estar registrados en el sistema y enviarme un correo solicitando la información de pago del taller. Una vez confirmado el pago, doy de alta el usuario e inicias accediendo a todos los materiales de estudio de la Semana 1.

Nota importante: solo aceptaré pagos durante esta primer semana, posteriormente y para evitar atrasos en el grupo, ya no habilitaré ningún alumno más en el Grupo 5.

El cupo máximo es de 20 personas, y a pesar que me han comunicado su interés de iniciar esta semana por lo menos 15 personas, sin importar el número final, aún sean 5, el dictado inicia sin inconvenientes.

Bueno, no desaproveches, tú última oportunidad, este taller cuenta con 4 grupos activos con un total de 90 alumnos y el último grupo está concluyendo esta semana con la entrega de la tarea final.

Puedes consultar la lista de inscriptos de todos los talleres en el sistema de registración.

¿Evolucionamos hacia la Programación Orientada a Objetos bajo PHP5 o nos seguimos quedando con el código estructurado embebido en HTML?

Invierte en conocimientos, logra diferenciarte laboralmente, da un paso más hacia el camino de un "PHP Senior" ;-)

Taller POO / PHP5: El lunes 27/10 sería la última fecha teórica posible...

... para iniciar un taller de POO para PHP. Hace días que me vienen consultando de la posibilidad de hacer otro grupo para este año y lo mismo me han preguntado algunas empresas para hacer un "taller privado" para capacitar a sus equipos de desarrollo.

Por lo pronto, si se desea iniciar un grupo más con una duración de 2 meses, como última fecha, se podría iniciar el lunes próximo para que que termine el 19/12, antes de fin de año (luego se vienen las fiestas, etc, etc).

Si hay interés, podemos evaluarlo rápidamente, ya que tendríamos que cerrar un grupo de 20 personas esta semana.

Ahora les estoy enviando un email a la base de registrados para saber si hay verdadero interés.

Espero sus comentarios para ver qué hacemos o el taller sigue cerrado hasta el año que viene ;-)

Martin Fowler: "Código como documentación"

Releyendo algunos artículos de Martin Fowler (gurú/pensador relacionado con Análisis & Diseño en POO) caigo en este artículo que, fuera de no ser tan técnico, considero un tema base a tratar en los equipos de desarrollo como así también sobre cómo se podría aumentar la calidad del código de un desarrollador que se considere "profesional".

En lo personal prefiero ser siempre "simple", clarificar lo suficiente el código como para que hasta un novato pueda entenderlo y esto no me hace menos "experto" por hacer código "entendible".

Lo que hay que evitar es la "sobre-ingeniería", es decir, ser complejos por el simple hecho que nuestra mente sea -tal vez- un poco más rápida que el resto, o simplemente, porque llegamos a tal grado de "optimización temprana" que creemos que nuestra calidad es elevada cuando "resumimos" 50 líneas en unas pocas 5.

Nota al margen: tanto "sobre-ingeniería" como "optimización temprana" son dos males detectados en la ingeniería de software y deben evitarse.

Algunos ejemplos de lo histérico que puedo llegar a ser ;-). Tengo la costumbre inconsciente de:
  1. Separar las sentencias relacionadas entre sí como si fueran párrafos de un artículo: veo a muchos desarrolladores que toman un método de una clase y en todo su contenido no hay una sola línea de separación, todo junto, todo "pegado". Lo primero que hago es empezar a separar como párrafos de un artículo: cuando las líneas de código están relacionadas, van juntas ("punto y seguido"), pero cuando las líneas tratan otro tema agrego una línea en blanco ("punto y aparte"). A mi me costaría leer un libro o un artículo que tiene contenido sin separar, ¿por qué no me pasaría eso con el código de un sistema?
  2. Evitar los "elseif" porque anidar condiciones genera un código difícil de seguir, ya que tenemos que estar evaluando cada condición y todos sus caminos alternos. Si no quedara otra simplificación, trato de cambiar el elseif por un simple else y coloco dentro un "if" aparte y agregarles lineas de separación. En parte está relacionado con el punto anterior (no mejora la lógica pero sí su lectura y entendimiento).
  3. Inmediatamente eliminar cualquier "número mágico", técnica de refactoring que dice algo así como "sustituir todos los códigos numéricos que hay por todo nuestro sistema y cambiarlo por una constante que lo describa", lo cual ya evita que tengamos que hacer un comentario antes del "número mágico".
  4. Cambiar los nombres de variables y hacerlas más descriptivas, sin importar lo largas que me queden: si el caso es muy obvio, no tengo problemas de agregar una variables del tipo "ret" o "retorno", pero en el caso donde lo obvio es peligroso, o donde no es tan obvio, trato que las variables sean tan descriptivas que no haga falta agregar un comentario para explicar para qué sirven, y el lugar más indicado es con los parámetros de un método.
  5. Abrir el código en varias líneas hasta que sea entendible: no tengo pudor en ampliar una línea de código en varias hasta que quede claro, aún sabiendo que puedo yo mismo entenderla con una sola línea. Lo importante, otra vez, no es si solo yo lo entiendo, es si el que viene detrás puede hacerlo, y esto es fundamental para trabajar en equipo y que todos seamos productivos.
Tan malo es hacer código que nosotros mismos nos cueste entender dentro de unos meses, como ser los únicos que lo puedan entender. Un código de alta calidad es el código que todos pueden entender, y hay que comprender que en algún momento u otro, vamos a trabajar en equipo con otra persona, y el código, además de ser entendible para nosotros poder trabajar de forma productiva, debe poder ser entendido por los demás.

Experto es quién hace código entendible, y experto es quién entiende la diferencia entre "código de calidad" y el que no lo es.

Y ahí entra la disciplina "refactoring" que busca, sin cambiar de funcionalidad, que el código mejore su calidad.

¿Y tú, haces código entendible para los demás, para ti, o para nadie? ;-)

Presentaciones de la ZendCon 08 (PHP)

Visitando el sitio de Crónicas de un Mundo Gris me encuentro con el link a las Presentaciones de la ZendCon 08 (PHP) que sabía se iba a hacer, pero no estaba al tanto de la disponibilidad del material de las presentaciones.

Todas tienen muy buena pinta, pero me quedo con la primera que usaron de apertura del evento: muy buenos ejemplos, frases y argumentos que cuentan el crecimiento y adopción que está teniendo hoy día PHP en el ámbito empresarial.



La verdad que viendo de afuera, la empresa Zend ha hecho mucho por estar donde está, y que el framework oficial haya crecido tan prolijo y rápido, a logrado que este último se haya vuelto un gran apoyo a la valoración del Desarrollador PHP en un mundo que dominan las "plataformas complejas".

Entradas populares