Cuando empezamos este "taller piloto" claramente no sabía cómo iba resultar ni todos los problemas que iban a surgir... aunque siempre supe por donde debía transitar y que sería evidente que cambiaría constantemente para ir ajustándome a los acontecimientos.
Esta segunda etapa estuvo concentrada en el trabajo en equipo, con teamleaders a cargo de pequeños grupos de desarrolladores y con un especial aditamento: la falta de experiencia en gestión de los líderes como a su vez en desarrollo POO de los dirigidos, y para peor, todos "a distancia".
El proceso fue lento y existieron muchos problemas que tuvimos que ir solucionando, pero finalmente llegamos al cometido: afirmar conocimientos a los novatos sobre los temas de programación orientada a objetos usando PHP5.
Todos sacamos -directa o indirectamente- conclusiones y adquirimos experiencia en muchos temas: trabajo a distancia, educación a distancia, gestión a distancia, colaboración, versionado, comunicación, herramientas colaborativas, etc.
Como "producto" de ese proceso tenemos un proyecto libre llamado "Clases Bases", que obviamente están invitados a probarlo, estudiarlo, preguntar, criticar y hasta continuar desarrollando.
Próximamente comentaré la tercer y última etapa del taller (serán los últimos 3 meses del mismo): desarrollar un proyecto libre todos los equipos juntos y usando Zend Framework.
¡Felicitaciones a todos! ¡Excelente trabajo!
A estar atentos de las novedades ;-)
Como convertirse en un "Desarrollador PHP Senior" y no morir en el intento... escrito por Enrique Place
Taller: concluida la segunda etapa - Proyecto "Clases Bases"
Suscribirse a:
Comentarios de la entrada (Atom)
Entradas populares
-
He visto mucha documentación que habla sobre el tema de los métodos "getter / setter", o traducido al castellano los métodos "...
-
Esto es lo que pasa cuando tienes entornos que no son homogéneos y cada aplicación se encuentra ubicada en distintas márgenes de un "rí...
-
Uno de los problemas que me he encontrado con la versión 5 de PHP es la falta de la representación de los "paquetes" desde el prop...
-
Este es un resumen de conclusiones que se vertieron en una discusión sobre el tema en Foros de Web , donde se plantea la duda de si PHP5 ...
-
Este es un ejemplo publicado a partir de la duda de un usuario , y como son preguntas que se hacen reiteradamente, les dejo el ejemplo aquí ...
-
Esta reflexión se la escribo a todos los "Programadores PHP": Al día de hoy la mayoría de los institutos o universidades de muchos...
-
El Patrón " Singleton " sirve para cuando buscamos restringir la creación de instancias de un objeto, obligando que solo se pueda ...
-
Hace un tiempo que vengo recomendando esta presentación como punto de partida para definir un estándar de desarrollo en una empresa. En ambi...
-
Bueno, luego de revisarlo una y otra vez (y otra vez) ya se encuentra terminada la primer versión del libro que junta toda la experiencia ac...
-
Estoy viendo muy seguido en foros que frecuento regularmente a muchos programadores que quieren dar " el gran salto " y evolucion...
4 comentarios:
Me cuesta algo de trabajo entender porque alguien querría usar clases tan complejas para hacer cosas tan sencillas, el punto es que se hagan las cosas de manera robusta, pero no complicarlas innecesariamente.
Claro, no estoy en los cursos, y a lo mejor estuvieron viendo un esenario en el que en verdad es necesario, pero no creo que sea la mejor manera de hacerlo, debe haber algo mas sencillo y general.
a mi me parece interesante esto y creo que para PHP6 deberia haber como clases base estas entre muchas otras clases para entonces si programar totalmente OO..
bueno mi critica constructiva.. en las clases .
# Boolean.class.php
# Float.class.php
# Integer.class.php
# Number.class.php
con excepcion de la de String las excepciones se tratan como segun yo entiendo se deben de tratar generando como una pila de llamadas y lanzando una excepcion desde abajo para que alguien en algun momento la pueda cachar (catch)
pero noto con extranieza que en la clase String se hace un catch en el mismo metodo dejando un poco de lado la posibilidad de un catch en algun otro lado y matando la aplicacion en ese mismo instante..
creo que eso podria ser un tanto inutil e incorrecto...
# String.class.php..
try{
if (!(is_string($suffix)) || (strlen($suffix) < 1)){
throw new Exception("El parámetro no es una cadena");
} else {
if (substr($this->value,-(strlen($suffix)),strlen($suffix)) == $suffix){
return new Boolean(true) ;
}else{
return new Boolean(false);
}
}
}catch (Exception $e) {
die("Exception: " . $e->getMessage() . "\n");
}
Por otro lado los felicito, creo que es un esfuerzo y trabajo excelente para los que se iniciaron con esto...
Saludos cordiales
ATTE
Sergio Lopez
Estimado Garaged:
No me queda claro por qué lo dices, concretamente por las "clases bases" o por el uso de Zend Framework?
No sé cual es tu propuesta, si va por el lado de sí usar POO pero con clases más sencillas, o directamente por el lado de no usar POO y que con programación estructurada es suficiente.
Si me explicas un poco más te respondo más al detalle ;-)
Estimado Sergio:
Exactamente, comparto plenamente la visión de que son necesarias las "clases base" en todos los lenguajes POO, y que tal vez en algún momento (PHP7?) pasemos a tener -por ejemplo- la clase String y todos sus métodos serán las funciones estructuradas que hoy día existen en el lenguaje.
Tal vez hagan lo mismo que hicimos para este taller, una clase "wrapper" que internamente tenga las llamadas a las funciones del lenguaje.
Sobre tus comentarios y correcciones, invaluables, ya se las pasé al foro de los teamleaders del proyecto para que lo discutan ;-)
Gracias
Publicar un comentario