Framework PHP

Este blog se traslada a http://codice.aletia8.com/, si te gusta lo que aquí se habla podemos seguir la conversación allí.

Estamos acostumbrados a pensar por comparación y a aprender con parábolas. Esto a menudo es de gran ayuda, pero a la larga nos impide dar el salto cualitativo del aprendiz al maestro. En informática esta advertencia tiene un profundo significado. Tendemos a comparar los ordenadores con personas o con máquinas, luego aplicamos estas comparaciones para intentar comprender lo que es un ordenador, pero un ordenador no es ni una cosa ni otra y no podremos entenderlo (y por tanto dominarlo) hasta que no dejemos de lado esas comparaciones, esas muletas que nos ayudan a aprender.

Quien escribe esto se haya muy al principio de ese camino de aprendizaje, a veces he tenido un vislumbre de la magia de un algoritmo o de la potencia de un paradigma informático, en esos momentos se queda uno asombrado ante la elegancia y la simplicidad que subyacen en un simple fragmento de código. Pero pronto me ofusco de nuevo y tengo que volver a las comparaciones y las parábolas para seguir avanzando. En estas páginas uso muchas comparaciones, pero no quedaros con ellas, no penséis que todo puede ser aprendido así, tampoco penséis que vosotros no podréis aprenderlo, si nos lo proponemos en firme y actuamos en consecuencia algún día daremos ese salto. Entonces dominaremos el arte de programar.

Algunos consejos rápidos

• Aprende bien el lenguaje: no te quedes con las cuatro estructuras que conoces y las veinte funciones que manejas, hay mucho más hay dentro, cada estructura tiene su lugar, de cada función puedes aprender algo. Intenta aprender algo nuevo cada día.
• Lee mucho código. ¿Te imaginas un novelista que nunca leyera libros? Lee código, mejor si es bueno, pero hasta del malo se aprende. Intenta entenderlo, pregúntate porqué está hecho así. Una buena fuente de código son los frameworks abiertos.
• No dejes de practicar: entre proyecto y proyecto practica con piezas pequeñas, crea pequeños algoritmos o programas que hagan esto o aquello. Un buena idea es ir creando tus propias herramientas. Primero algo modesto, que resuelva pequeñas tareas tediosas, pero no tienes porqué quedarte ahí, puedes crearte tu propio editor, o, quien sabe, algún día tu propio lenguaje, al fin y al cabo así suelen empezar la mayoría de los proyectos de código abierto.
• Aprende y aplica nuevos conceptos: no hagas siempre lo mismo, te quedarás atrás y te aburrirás.
• Conoce y utiliza nuevas herramientas: no digo que cambies de editor cada día, pero, ¿sabes lo que es un gestor de versiones?¿te suenan de algo los tests unitarios?¿usas alguna herramienta para validar html o css?
• Aprende más de un lenguaje: esto es algo más a largo plazo, pero no lo pierdas de vista. Sólo manejando varios lenguajes llegarás algún día al fondo de la cuestión.

Enlaces recomendados

• Sobre la crueldad de verdaderamente enseñar ciencias de la computación- Edsger W Dijkstra
• Code Reading: The Open Source Perspective – Un libro sobre como leer código ajeno.

No soy un experto en PHP, ni por asomo, pero cada vez estoy más convencido de que la mejor forma de aprender es enseñando. Llevaba un tiempo dando vueltas a la idea de escribir una página sobre programación en PHP, pero no acababa de encontrar la motivación.

Un problema con el que me he encontrado cada vez que hacía una nueva aplicación web era el de tener que reinventar la rueda, partiendo siempre desde cero, incorporando todo lo que había aprendido desde la última vez e intentando rehusar el código que ya había logrado hacer funcionar correctamente.

Otro problema es que no puedo con la programación procedimental, cuando un proyecto pasa de cinco o seis ficheros ya no sabes donde meter cada cosa, que página tiene que llamar a cual, etc. Al final todo el mundo acaba con un código spaguetti. Así que me decanté por la programación orientada a objetos, que va más con mi forma de ser y de pensar. Pero la programación orientada a objetos también me plantea mil dudas: que va en un objeto y que en otro, donde meto todas esas funciones que no parecen tener cabida en ningún objeto, que objetos generarán html y cuales no y así hasta el infinito. Esto me dejaba bloqueado.

Entonces descubrí Ruby un Rails y me dije: “¡Esto es lo mio!”. Me encantá Rails, me encanta su forma de hacer las cosas, he aprendido mucho con Rails, a pesar de no haber llegado a desarrollar ningún proyecto. Pero no se nada de Ruby, no me acabo de enterar como funciona Rails y eso da mucho miedo.

Así que me puse a buscar algo parecido a Rails, pero para PHP. En principio intenté hacerlo yo, pero era una tarea que me venía demasiado grande, entonces me topé con CakePHP. ¡Que maravilla!, un entorno como Rails en un lenguaje que si conocía. Me lance de cabeza con Cake, me empapé toda la documentación, algo de la API, los tutoriales que encontré e incluso me puse a traducir el manual oficial al español. Comencé a desarrollar un proyecto a la vez que aprendía por aquello de predicar con el ejemplo. Pero tampoco me acaba de enterar como funcionaba Cake por dentro, cuando algo falla y no sabes porqué, eso me asustaba terriblemente.

Entonces encontré en el sitio de Onlamp una serie de artículos para hacerte tu propio framework y ahí comencé a ver la luz. Empecé a comprender como funcionaba por dentro un framework basado en el patrón MVC y me entendí que para trabajar con soltura y seguridad en cualquier framework hay que haber hecho uno. No tiene que ser muy sofisticado, no tiene que incorporar las últimas tecnologías 2.0. Sólo algo que funcione por lo menos con pequeños proyectos, de momento claro, y esto a su vez te permite acceder a frameworks más complejos y a dejar de tener miedo.