Bueno, recibí por fin un nuevo auricular con micrófono (no es nada del otro mundo, pero hasta que consiga otro de mejor calidad, salimos del paso) y estoy probando distintos programas "legales" (me resisto a usar software a través de "cracks").
Para mi primer screencasts estaba usando uno gratuito de Microsoft (Windows Media Encoder) pero no encuentro la versión vieja que usaba y la nueva consume demasiados recursos para mi gusto. Y por el momento estoy usando Windows XP para unos proyectos, así que más adelante volveré a GNU/Linux.
Buscando me encontré el proyecto Jing, así que lo estoy probando. Genera directamente archivos en formato flash (.swf) e inocentemente pensé que podía subirlo a Youtube directamente, algo que no es cierto ya que debo antes convertirlo a ".flv".
Por el momento subí el archivo .swf a mi servidor y lo incrusté en Blogger. Aparentemente funciona bien, pero me gustaría simplificar la operación y seguir subiendo los futuros screencasts a Youtube para que estén a disposición de todos.
¿Sugerencias? ¿Software para hacer screencasts que recomienden?
Soluciono estos detalles y esta semana empiezan a salir los screencasts como "por un tubo" ;-)
PD: También muchos usuarios me han sugerido en su momento la opción para bajarlos, pero creo que a través de youtube se puede llegar a más gente usando una infraestructura existente. Sé que el tamaño es reducido (tengo que jugar dentro de los 425x355 de Youtube para no distorsionar la imagen), tal vez se podría hacer otros de mayor tamaño, pero tendría que ver el ancho de banda y cómo quedaría posteriormente.
Screencasts sobre Zend Framework
Como muchos sabrán a través de este blog, hace un tiempo que estoy dedicándome a estudiar el Zend Framework (producto desarrollado por "la empresa de PHP"). La idea fundamental, motivado por grandes modas como Ruby On Rails, es generar un marco de trabajo de más alto nivel, así evitar la habitual programación artesanal de "una sola capa" (php con html embebido y programando sin uso de objetos).
Lo vivo en carne propia, no es sencillo aprenderlo ya que hay que entender antes muchos conceptos para luego lentamente ir comprendiendo el marco de trabajo para empezar a sacarle el provecho justo.
Actualmente me estoy apoyando en varios screencasts, que aunque están en inglés, son muy entendibles y te muestran paso a paso cómo empezar a construir la estructura de tu proyecto para poder usar el framework y aplicar el patrón MVC.
El primero es de Mitchell Hashimoto y la sección se llama Zend Framework Tutoriales donde este estudiante nos cuenta paso a paso y a través de código cómo instalar Zend partiendo de una estructura en cero (el nos invita luego a hacerle una donación a través de Paypal para apoyar sus estudios). El otro tutorial es sobre Zend_Registry, que nos permite entender cómo funciona la registración de variables para luego poder ser utilizada en distintas partes de nuestro sistema (funcionalidad similar a contar con variables globales pero sin los perjuicios de estas).
Los otros screencasts que estoy viendo, directamente como si estuviera en un curso ;-), son de la misma empresa Zend y están en la sección Webinar, y también tienen uno que inicia de cero, pero primero por los conceptos, explicando la estructura del framework (hay que registrarse primero en el sitio para poder verlo).
Próximamente voy a compartirles dos ayudas más:
- A pesar que existe el proyecto abierto surforce-cms que puede servir a cualquier desarrollador para empezar a conocer cómo funciona Zend Framework, voy a armar otro proyecto con el nombre "surforce-base" que contará con lo mínimo indispensable para empezar un proyecto de cero: Zend instalado, configuración básica, un ejemplo con conexión a la base de datos y comentados todos los pasos. Tengo pensado agregarle un detalle interesante: dejar configurado por defecto Smarty para poder aprovecharlo en esta estructura (ya que conozco muchas empresas que sus diseñadores usan templates para luego fácilmente pasarles el trabajo a los desarrolladores).
- Armar un screencasts basado en los anteriores que están en inglés, pero en nuestro idioma y profundizando un poco más los conceptos básicos de cómo trabajar con Zend, la parte de persistencia y usando Eclipse para la demostración.
Dentro de poco novedades ;-)
Crear templates para consultas SQL
Los "templates" o "plantillas" nos sirven para disponer de una estructura base y agregarle solo la información que cambia o varía, evitando tener que volver a copiar código una y otra vez.
En el caso de HTML podríamos usar Smarty, lo que nos permite contar con archivos de extensión .tpl y separar el código de presentación del código que se encargaría de armar o recibir información de la lógica de nuestro sistema.
Me ha sucedido que en muchos proyectos relacionados con web y con PHP se tienen que trabajar intensamente con consultas sql, más allá del tema de usar o no una capa de abstracción para conectarse a la base de datos. En estas situaciones existe mucho trabajo del lado del rol de DBA para incorporar mucha lógica en el motor de base de datos, como ser restricciones de integridad, disparadores, vistas, etc. De la misma forma, muchas reglas del negocio se resuelven a través de complejas consultas SQL que escapan del entendimiento de muchos de los programadores tradicionales (cabe aclarar que un programador nace con un cerebro distinto al de un DBA; muchas veces odiamos a las bases de datos y todo lo relacionado con la teoría de conjuntos ;-)).
En estos casos conviene que las consultas vengan preparadas por el DBA y que el desarrollador solo tenga que ejecutarlas, en otros, directamente trabajar con vistas que nos oculten toda la complejidad del diseño de la estructura de datos. También se pueden aprovechar "procedimientos almacenados" para ejecutar consultas con solo entregar algunos parámetros.
Me ha sucedido en situaciones intermedias y menos complejas que me es útil manejar el concepto de templates pero aplicados a consultas SQL donde simplemente tengo almacenadas las consultas y les paso los parámetros que requieren para ejecutarse.
Un ejemplo sencillo sería:
SELECT * FROM usuarios WHERE id = 1
Donde si tuviera un código PHP tendría que hacer cosas como:
O alguna versión más POO como:
Ahora bien, ¿qué pasa si para todas mis tablas uso constantemente esta misma lógica, donde solo necesito cambiar el nombre de la tabla y mantengo siempre un campo id, y luego solo le paso distintos valores por parámetro?
Yo puedo procesar esta consulta como un template, armando el marco para la sentencia y luego sustituyendo las "marcas" por valores, simplemente así:
Lo que sucede es que ahora tomará la sentencia sql y en cada %s ("s" por "String") sustituirá en orden por los valores que agregue a continuación, causando el resultado esperado:
Y ahí podemos aumentar enormemente la complejidad de las consultas y podremos reutilizarlas todas las veces que queramos, más, si las tenemos almacenadas en un archivo aparte y que todo nuestro sistema las use. Llegado el caso, si hubiera que optimizarlas habría que modificar un solo archivo.
Otra cosa que se me ocurre es algo más parecido al patrón de diseño ActiveRecord, que nos solucionaría un poco la vida con la operación de nuestras clases de persistencia de objetos.
Por ejemplo, podría crearme una clase Persistente que fuera así (usaré PHP4 para demostrar que no hace falta gran uso del lenguaje para implementar la idea):
¿Bien, y cómo se usaría? Me creo mi clase concreta de persistencia de objetos, por ejemplo Usuario, y simplemente defino la información particular de la misma:
Y listo, no debo decirle nada más. Ahora solo me basta usarla de esta forma:
Si quiero traerme a todos los usuarios
Y si quiero traerme solo a un usuario particular, basta con que la base de datos del usuario tenga los campos id, nombre y apellido para hacer dinámicamente lo siguiente:
Y lo más interesante es que en situaciones donde lo genérico puede quitarnos libertad de acción, simplemente con sobreescribir los valores de los atributos definidos en la clase Persistente pero del lado de la clase Usuario resolvemos algunas limitaciones:
Mmm... creo que hoy me fui muy lejos divagando... más adelante les comparto un ejemplo completo que incluye persistencia en todos sus casos (update, delete, etc).
Más información
- Manual oficial, comando sprintf
En el caso de HTML podríamos usar Smarty, lo que nos permite contar con archivos de extensión .tpl y separar el código de presentación del código que se encargaría de armar o recibir información de la lógica de nuestro sistema.
Me ha sucedido que en muchos proyectos relacionados con web y con PHP se tienen que trabajar intensamente con consultas sql, más allá del tema de usar o no una capa de abstracción para conectarse a la base de datos. En estas situaciones existe mucho trabajo del lado del rol de DBA para incorporar mucha lógica en el motor de base de datos, como ser restricciones de integridad, disparadores, vistas, etc. De la misma forma, muchas reglas del negocio se resuelven a través de complejas consultas SQL que escapan del entendimiento de muchos de los programadores tradicionales (cabe aclarar que un programador nace con un cerebro distinto al de un DBA; muchas veces odiamos a las bases de datos y todo lo relacionado con la teoría de conjuntos ;-)).
En estos casos conviene que las consultas vengan preparadas por el DBA y que el desarrollador solo tenga que ejecutarlas, en otros, directamente trabajar con vistas que nos oculten toda la complejidad del diseño de la estructura de datos. También se pueden aprovechar "procedimientos almacenados" para ejecutar consultas con solo entregar algunos parámetros.
Me ha sucedido en situaciones intermedias y menos complejas que me es útil manejar el concepto de templates pero aplicados a consultas SQL donde simplemente tengo almacenadas las consultas y les paso los parámetros que requieren para ejecutarse.
Un ejemplo sencillo sería:
SELECT * FROM usuarios WHERE id = 1
Donde si tuviera un código PHP tendría que hacer cosas como:
1
<?php
2
3 function traerUsuario( $id ){
4 $sql = "SELECT * FROM usuarios WHERE id = $id";
5
6 // ejecutar_sql( $sql );
7 // etc.
8
9 }
10
11 ?>
O alguna versión más POO como:
1
<?php
2
3 class Usuario{
4 function getId( $id ){
5 $sql = "SELECT * FROM usuarios WHERE id = $id";
6 // procesar consulta
7 }
8 }
9
10 ?>
Ahora bien, ¿qué pasa si para todas mis tablas uso constantemente esta misma lógica, donde solo necesito cambiar el nombre de la tabla y mantengo siempre un campo id, y luego solo le paso distintos valores por parámetro?
Yo puedo procesar esta consulta como un template, armando el marco para la sentencia y luego sustituyendo las "marcas" por valores, simplemente así:
1
<?php
2
3 $sql_one = "SELECT * FROM %s WHERE id = %s ";
4 $sql = sprintf( $sql_one, "usuarios", 1 );
5
6 ?>
Lo que sucede es que ahora tomará la sentencia sql y en cada %s ("s" por "String") sustituirá en orden por los valores que agregue a continuación, causando el resultado esperado:
$sql = "SELECT * FROM usuarios WHERE id = 1"; Y ahí podemos aumentar enormemente la complejidad de las consultas y podremos reutilizarlas todas las veces que queramos, más, si las tenemos almacenadas en un archivo aparte y que todo nuestro sistema las use. Llegado el caso, si hubiera que optimizarlas habría que modificar un solo archivo.
Otra cosa que se me ocurre es algo más parecido al patrón de diseño ActiveRecord, que nos solucionaría un poco la vida con la operación de nuestras clases de persistencia de objetos.
Por ejemplo, podría crearme una clase Persistente que fuera así (usaré PHP4 para demostrar que no hace falta gran uso del lenguaje para implementar la idea):
1
<?php
2
3 require_once( 'BaseDeDatos.class.php' )
4
5 class Persistente {
6 var $id;
7 var $tabla;
8 var $orden;
9
10 var $sql_one = "SELECT * FROM %s WHERE id = %s ";
11 var $sql_all = "SELECT * FROM %s ORDER BY %s ASC";
12
13 function getId( $id ){
14 $sql = sprintf( $this->sql_one, $this->tabla, $id );
15
16 $bd = new BaseDeDatos();
17 $datos = $bd->traerTodo( $sql );
18 $this->cargarDatos( $datos );
19 }
20 function cargarDatos( $datos ){
21 foreach( $datos as $key => $it ){
22 $this->$key = $it;
23 }
24 }
25 function getAll(){
26 $sql = sprintf( $this->sql_all, $this->tabla, $this->orden );
27
28 $bd = new BaseDeDatos();
29 $datos = $bd->traerTodo( $sql );
30 return $datos
31 }
32 }
33
34 ?>
¿Bien, y cómo se usaría? Me creo mi clase concreta de persistencia de objetos, por ejemplo Usuario, y simplemente defino la información particular de la misma:
1
<?php
2
3 require_once( 'Persistente.class.php' );
4
5 class Usuario extends Persistente {
6
7 function Usuario() {
8 $this->tabla = "usuarios";
9 $this->orden = "id";
10 }
11 }
12
13 ?>
Y listo, no debo decirle nada más. Ahora solo me basta usarla de esta forma:
Si quiero traerme a todos los usuarios
$usuario = new Usuario();
$datos = $usuario->getAll(); Y si quiero traerme solo a un usuario particular, basta con que la base de datos del usuario tenga los campos id, nombre y apellido para hacer dinámicamente lo siguiente:
$usuario = new Usuario();
$usuario->getId(1);
echo "Mi nombre es {$usuario->nombre} y mi apellido
es {$usuario->apellido}"; Y lo más interesante es que en situaciones donde lo genérico puede quitarnos libertad de acción, simplemente con sobreescribir los valores de los atributos definidos en la clase Persistente pero del lado de la clase Usuario resolvemos algunas limitaciones:
1
<?php
2
3 require_once( 'Persistente.class.php' );
4
5 class Usuario extends Persistente {
6
7 function Usuario() {
8 $this->tabla = "usuarios";
9 $this->orden = "id";
10
11 // Agregamos un JOINs con otra tabla
12 $this->sql_all = "SELECT * FROM %s as u,
telefonos as t WHERE u.id = t.idUsuario ORDER BY u.%s, t.id ASC";
13 }
14 }
15
16 ?>
Mmm... creo que hoy me fui muy lejos divagando... más adelante les comparto un ejemplo completo que incluye persistencia en todos sus casos (update, delete, etc).
Más información
- Manual oficial, comando sprintf
Presentación: "Construyendo Entornos de Desarrollo Escalables"
Buscando presentaciones sobre "gestión ágil", metodologías y en concreto sobre Scrum, me encontré con esta de casualidad. Muy interesante, se las comparto:
"Surforce CMS": nueva lista de tareas pendientes
Estoy en estos momentos ingresando en una planilla de Google Docs la lista de tareas pendientes a realizar sobre el CMS que estamos desarrollando de forma colaborativa, con el simple objetivo de aprender entre nosotros a usar Zend Framework.
Si quieres participar -necesitamos revitalizar el equipo de trabajo- esta es tú oportunidad; deberás simplemente y por cuenta propia (hay mucha información en este blog de cómo hacerlo):
Demuestra que puedes lograrlo y estás dentro. ¡Suerte!
Si quieres participar -necesitamos revitalizar el equipo de trabajo- esta es tú oportunidad; deberás simplemente y por cuenta propia (hay mucha información en este blog de cómo hacerlo):
- Reconstruir localmente el CMS
- Elegir alguna de las tareas pendientes
- Implementarla
- Enviarme por mail el código nuevo (un "diff" mostrando lo que se hizo)
Demuestra que puedes lograrlo y estás dentro. ¡Suerte!
Herencia de clases y el "Principio de Liskov" (actualizado 15/10/2007)
En realidad se llama "Principio de sustitución de Liskov" y el nombre completo es Bárbara H. Liskov (sí, hay mujeres en la informática y han hecho grandes aportes ;-)).
A grandes rasgos dice que el famoso "es un" (is_a) que generalmente usan los docentes para enseñarnos "herencia de clases" no es suficiente.
No basta con "ser" hay que "comportarse como tal".
Generalmente hago el mismo chiste cuando trato el tema en un curso: "un docente es una persona, pero no basta, debe comportarse como tal".
Un ejemplo más real: Sistema de liquidación de sueldos
Si tienes un sistema que liquida sueldos, una clase base Empleado (con atributos como "sueldo" que se usa para calcular su pago) y subclases Gerente, Desarrollador, Administrativa y Becario (asumamos que el último no recibe ninguna remuneración).
Usas polimorfismo y en tu clase Administracion tienes un método liquidarSueldo donde recibirás objetos de tipo Empleado. Bien, cuando en un momento recibes de tu lista de empleados un becario... ¿qué debe hacer el sistema? (ya que haces el cálculo en base al valor que viene en el atributo sueldo y este es heredado por todos desde la clase Empleado).
- ¿Emitir un comprobante impreso pero con valor 0?
- ¿Agregar un "if" preguntando si es becario, y no hacer nada?
- etc
Supongamos que el 1) no es aceptable por el gasto de papel y te piden que no se impriman (no tiene sentido), pasamos al punto 2), agregamos un "if".
¿No estamos "codificando a fuego" nuestro sistema para un comportamiento particular?
Estamos rompiendo el polimorfismo, justamente, el patrón estratégico más importante que tiene la POO. Cada vez que tenemos que cambiar nuestro código generamos nuevos costos y nuevos posibles errores.
Por eso cada vez nos cuesta más desarrollar un sistema, hasta que tenemos que tirarlo y desarrollar otro de cero... y empezamos otra vez con los problemas del mal diseño (code smell).
La base teórica
Los principios de diseño te dicen que "desarrolla cerrado al cambio y abierto a la extensión" (Principio Open/Closed, "Abierto / Cerrado").
Por ejemplo, tu código debe ser reutilizable (¿no es la idea esencial de la OO?) y con solo agregar código -sin tocar el existente- lograrás adecuarte a los cambios, a los nuevos requerimientos. No te olvides que nuestro código lo usan muchos otros objetos, si este cambiara, generaría un efecto en cadena, posiblemente, dejando de funcionar lo ya existente y tener que modificar más objetos.
Esta forma de "extensión" es agregar más clases a la herencia y el método liquidarSueldo no se modifica, pero si tu no haces correctas herencias, no puedes hacer lo primero, por lo tanto tu sistema se degradará en cascada.
Esta simple tontería el autor demuestra con muchos ejemplos que hacer "herencia por herencia", "por reutilizar código", no es suficiente y genera grandes problemas en los diseños.
Es una de las razones que me ven de mal humor cuando veo que implementan herencia a los golpes, prueba y error, con el argumento solo de "reutilizar código"
La conclusión final es...
El problema es que la herencia está mal formulada y que el Becario no se comporta como un Empleado, por lo tanto no puede ir en esa estructura jerárquica, de lo contrario nos va a obligar a desarmar nuestro sistema para tratar de ajustarlo a un comportamiento no adecuado (agregando condiciones explícitas para el mismo, hardcode) y este empezará a dejar de ser reusable.
No se puede hacer herencia por herencia, para reusar código. No se puede hacer herencia simplemente por que un "Becario es un Empleado", hay que estar seguro que además de "ser" se comporte como tal.
Nuestro becario, ya que no cobra una remuneración, no pude pasar por el sistema de liquidación de sueldos. La solución no es ajustar el sistema de sueldos para que lo permita.
Anexo otro artículo relacionado: Herencia Múltiple en PHP5
Nota: este post está basado en una discusión presentada en Foros del Web
Parece que pasamos a las ligas mayores: ¡Namespaces en PHP 5.3!
Me comenta mi colega Julio Viana que se enteró a través del blog de Inwe una muy buena noticia: la disponibilidad en la rama 5.3 de desarrollo de los tan necesitados namespaces. Fue toda una sorpresa, ya que se discutía si estaría recién en la próxima versión 6, pero veo que se han dado cuenta que era una vergüenza no contar con tan básica funcionalidad (los que conocemos lenguajes que se usan en arquitecturas como Java o .Net sabemos que sin esto no se puede vivir).
Si quieres saber de qué te hablo, puedes leer los siguientes post:
Si quieres saber de qué te hablo, puedes leer los siguientes post:
Próximo martes, curso en Universidad ORT
Bajar folleto
Recuerda: a partir del año que viene PHP4 dejará de tener soporte y se generará una importante demanda de desarrolladores con conocimientos de PHP5, no solo para migrar, sino, para rehacer sistemas y convertirlos a Programación Orientada a Objetos (sí, bien tarde, cuando todo el mundo ya habla "objetos").
Lo más importante de PHP5 no es el lenguaje en sí ni las miles de funciones que incorpora, es que podrás trabajar por fin "Orientado a Objetos" como con los "lenguajes mayores", al estilo de Java.
Puedes estar en la cresta de la ola o dejarla pasar.
PD: no digas que no te avisé.
"Surforce CMS": primer prototipo cerrado
Les comparto el siguiente correo que envié a la lista donde participamos todos los "teamleaders" del equipo de desarrollo del taller -piloto- on-line:
"Primer prototipo terminado
Bueno, se hicieron muchos cambios (están todos registrados en los comentarios del log de svn).Revisión 76Recomendación a todos:
Hacer un update del repositorio y volver a reconstruir la base de datos de cero a partir del archivo 6_TODO.sql (tiene la base de datos completa y ahora con soporte UTF8). También hay que configurar el proyecto en Eclipse para que soporte el mismo formato.
Felicitaciones a todos por su trabajo y dedicación, en especial a Julio Viana (mi mano derecha ;-)) que se quedó conmigo hasta las 3am para hacer los últimos arreglos y "cableados a fuego" para cumplir en tiempo y forma con las fechas de entrega.
El prototipo fue entregado al cliente para su evaluación. En base a las correcciones que sugieran seguimos con la segunda etapa que culmina con un segundo prototipo para el 31 de agosto.
Lo que hay que hacer mientras tanto es un fuerte refactoring para corregir todos los errores que cometimos y poder continuar limpiamente.
Nuevamente, felicitaciones a todos y adelante! ;-)"
Como había comentado en su momento este desarrollo es "real", para un cliente real, con exigencias reales. El proyecto lo estamos trabajando principalmente con mi colega Julio Viana, pero vamos asignando tareas para intentar compartir entre quienes quieran participar (solo hace falta ganas de aprender y dedicación) de la experiencia y así entre todos poder más fácilmente aprender herramientas nuevas, como en este caso, Zend Framework.
El sitio donde se encuentran los fuentes es en Google Code (alojado como un proyecto libre y de licencia GPL) y el sitio de pruebas está en Surforce.
Desde ya agradezco a todos los que se han mantenido activos hasta el momento, pues con la retroalimentación todos aprendemos.
Los teamleader's
De los cuatro grupos de desarrollo que participan hasta el momento (con desarrolladores a su cargo):
Y quiero hacer menciones especiales a:
El "Robin" que todo "Batman" necesita, el mano derecha que se encarga de encontrar soluciones mágicas para tratar de cumplir con las fechas propuestas ;-)A los colaboradores que han levantado el guante y participaron enviando código con funcionalidades que necesitábamos: Rodrigo Muñoz (que de ahora en más va a participar con nosotros) más todos los aportes de gurús latinoamericanos como Pablo Rigazzi (Ar) y Christopher Valderrama (Mx) que siempre nos aportan una luz cuando el camino de nuestro aprendizaje se hace más oscuro y no sabemos hacia donde ir.
Nuevamente, gracias a todos (espero no olvidar a nadie) y seguimos adelante, quedan aún dos meses para concluir con el taller ;-)
Si quieres participar, ya sabes qué debes hacer.
PD: me queda pendiente saludar y agradecer a cada uno de los desarrolladores de cada uno de los cuatro grupos de desarrollo, a no desesperar, quiero armar un post aparte sobre el tema ;-)
Faltan 24 días - Curso "Desarrollo de Sistemas Web con PHP 5" (duración: 4 meses)
Existe abundante información en este blog de lo que trata el curso, los temas que abordaremos , la forma de darlo, mi filosofía con respecto al desarrollo de sistemas y en particular sobre el mundo "PHP Profesional". Todo lo que recorreremos durante 4 meses se puede desprender perfectamente desde el primero al último de los artículos que publico regularmente aquí.
¿Entonces, qué puedo decir de nuevo? ;-)
Bien, desde ya que no hay un curso igual, no solo porque siempre trato de adecuarme al público que tengo en frente y tratar de canalizar todas sus expectativas, sino porque yo también aprendo durante el proceso de cada dictado, obteniendo más experiencia, conocimientos, variando las herramientas... el mundo cambia rápidamente y nosotros no podemos estar ajenos a ello.
En la primera versión del curso de este año, que ya casi termina (20 de agosto entrega de obligatorios y defensas), la propuesta fue desarrollar un sistema similar a Twitter (aquí el mío), buscando con ello que no solo "programen"... que entiendan lo que involucra "desarrollar sistemas", conocer el mercado y casos de éxito, entender qué es "Web 2.0" y qué no, plantear un negocio, definir una estrategia, ser rentables, los riesgos que involucra, cómo dividir los problemas en pequeñas partes, o cómo trabajar en equipo apoyados con herramientas especializadas para ello, trabajo a distancia, conceptos de Ingeniería de Software, y un largo etcétera.
Para la segunda versión del curso -Setiembre 2007- estoy manejando varias actualizaciones, entre ellas agregar una introducción a Zend Framework que incluye abordar en la práctica el patrón MVC (para que se vayan con lo último que se está trabajando en el mercado mundial), y como obligatorio ya estoy evaluando solicitar la implementación de un sistema de "contactos personales" (del estilo Match.com o Yahoo.com) que involucra muchos puntos interesantes y desafiantes (además de los clásicos, mayor incorporación de Ajax para las interfaces, el desarrollo de chats entre usuarios, mayor trabajo en equipo tratando de emular un proyecto real con varios desarrolladores en paralelo, etc).
En los próximos días más novedades... pero ve reservando ya tu lugar en Universidad ORT ;-)
Suscribirse a:
Entradas (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...
