Recursos en inglés para programar en PHP

Obtenido de WikiBooks: PHP Programming

Haz un comentario

Lynx. El regreso de un veterano.

Estábamos en el año 92, teníamos HTML, pero no teníamos browser, así que dos estudiantes se propusieron  crear el primer browser compatible con HTML. Por entonces, aún usábamos terminales en la universidad, y veíamos las páginas web así:

Cuando ya me había olvidado totalmente de él, me encuentro que Google está aconsejando a los desarrolladores que utilicen Lynx para probar como “ve” el indexador la página web.

Así que me he decido a bajarme una versión para Mac, y probar algunas páginas web.

Es curioso ver, como páginas como Apple, Google, Wordpress funcionan, pero páginas como Microsoft, MSN, o la mayoría de los bancos no funcionan.

Pero lo que más destaca es la necesidad de agregar ALT y TITLE a todas las imágenes, que contienen alguna información, como cabeceras, anuncios, etc.

Más información en google:

http://www.google.com/support/webmasters/bin/answer.py?hl=en&answer=40349

Haz un comentario

CMS Made Simple

Hasta la fecha he vivido en carne propia tres frameworks para desarrollar aplicaciones web: Ruby on Rails, CakePHP y CMS Made Simple, este último, que ni siquiera es un framework como tal, ha sido el único que ha resultado productivo casi desde el primer día.
CMS Made Simple es un gestor de contenidos que puede pasar por un framework, no está tan orientado al usuario final del sitio como Joomla u otros CMS, ni tampoco es un framework como Cake o Symphony. Pero quizás ese hallarse a medio camino es lo que lo hace tan asequible para alguien que esté acostumbrado a programar en PHP.

Portal de cmsmadesimple.org

Los ingredientes de CMS Made Simple son:

  • PHP con objetos o sin ellos para la lógica de la aplicación,
  • CSS y HTML para la presentación
  • Smarty para hacer plantillas
  • Ado DB para poder acceder a cualquier base de datos.

Las dos cosas que destacan de él desde el primer momento son: la modularidad y claridad con que trata el tema de las plantillas y hojas de estilo y la capacidad de incorporar código en cualquier parte del contenido de forma limpia y elegante usando los llamados “Tags personalizados”. Además tiene estos otros puntos fuertes:

  • Una web lista para usar desde el primer momento, con gran facilidad en la gestión de plantillas.
  • Gran facilidad para programar extensiones desde dentro del entorno.
  • Traducido al español.
  • Una buena colección de módulos para agregar funcionalidades.
  • Fácil de entender y programar al poco tiempo de empezar a trabajar con él.
  • Facilidad de acceso a distintas bases de datos.

No obstante todo tiene su lado oscuro y debes conocer los puntos débiles de este entorno antes de decidirte por él:

  • Una documentación algo escasa, aunque esto parece ir mejorando.
  • Gestión de usuarios bastante mejorable.
  • No es un framework, es un CMS.

¿Cómo saber entonces si necesitas un CMS o un framework? te daré un criterio: si toda la web es la aplicación necesitas un framework, si la web utiliza varias pequeñas aplicaciones necesitas un gestor de contenidos.

Para seguir profundizando en este entorno te recomiendo:

1 Comentario

¿Preparados para ir de “Safari”?

Recuerdo aquellos tiempos por el año 92, cuando al desarrollar una web, sólo tenías que preocuparte de que se mostrara bien en Netscape. Años más tarde, Microsoft compra Mosaic y lo llama Internet Explorer y en poco tiempo obtiene una cuota de mercado del 95%, de forma que los desarrolladores, pasaron a preocuparse sólo por el IE.

El mercado actual es totalmente diferente, Firefox ha recuperado la cuota perdida por Netscape, y entran en juego más exploradores como el Opera. Los desarrolladores se ven forzados a hacer sus páginas más compatibles, al menos para Firefox e Internet Explorer.

Icono de SafariCuando todos creíamos que Apple se había rendido a Firefox y Camino (también basado en el mismo motor de Firefox), nos encontramos con una sorpresa, una apuesta muy fuerte de Apple por extender Safari, siguiendo un plan perfectamente trazado:

  1. Lo primero ha sido, quitarse la etiqueta de incompatible, actualmente Safari 3.1 es el navegador más compatible que existe con los estándares actuales.
  2. Han convertido a Safari en multiplataforma, con versiones para Windows, OSX, iPhone y con su motor webkit, compatible con Linux.
  3. Han creado una política de distribución perfecta: todos los iPhone y todos los iPod, tienen instalados Safari (y muy pronto Apple TV). Todos los usuarios en Windows con iTunes o QuickTime, se han encontrado al actualizar la ultima versión con un icono de Safari 3.1.
  4. ¿Cómo destacar con respecto al resto de navegadores? En lugar de desarrollar navegadores cada vez más grandes, con más características (que nadie utiliza), Apple se ha dedicado a mejorar la velocidad, teniendo un rendimiento muy superior a sus competidores.
  5. Apoyo a los desarrolladores. Por un lado, Safari está basado en el navegador Konqueror de Linux, el motor sigue siendo Open Source. Por otro lado, encontramos en la versión 3.1 un menú “Desarrollo”, creado para ayudar a los desarrolladores.

¿Es hora de ir de “Safari”?

Pues la verdad es que aún es pronto, que Safari sea el navegador más compatible del mercado, no significa que funcionen todas las páginas web. Hay que tener en cuenta, que el HTML es un lenguaje que permite errores, trucos, uso de características propietarias del navegador, etc.

No obstante, como desarrolladores, debemos ir empezando a probar nuestras páginas con Safari.

¿Por qué utilizar Safari?

En los próximos años, el panorama de los navegadores cambiará radicalmente:

  • Cada vez hay más dispositivos con acceso a Internet; móviles, PDA, Nintendo Wii, Playstation 3, Nintendo DS.
  • Linux y Apple le van ganando terreno a Microsoft.
  • Google apuesta por contenido estándar, penalizando a las web que utilizan contenido no compatible.
  • La única solución para hacer páginas compatibles es seguir un estándar, de esta forma nuestro contenido se verá en todos los medios.

Utilizando Safari desde ahora, conseguiremos que nuestro contenido sea accesible en cualquier navegador.

Más información

1 Comentario

Web 2.0: El diseño importa (a veces)

A menudo aparecen publicaciones sobre las maravillas de Web 2:0; interfaz de usuario mejorado, animaciones, interactividad, etc…

Muchos me dicen que mejore mi página web, que agregue animación, noticias, que cambie los tipos de letra.

Llevo muchos años en esto, y el diseño importa, claro que importa, pero tambien hay algo mucho más importante que muchos olvidan: El objetivo de la web (vender, comunicar, etc..)

Muchas páginas web 2.0, son expectaculares, pero no cumplen su objetivo.

Pongamos un ejemplo en el mundo real con una inmobiliaria:

Inmobiliaria 1.0

- Fácil acceso

- Limpia y amplia, todo el espacio bien organizado.

- Dispone de sala de espera comoda.

- Nos recibe una secretaría amable, traje formal, educada.

- Se nos proporciona información clara y concisa.

- El entorno, la información, la docoración, la atención inspirta confianza.

Inmobiliaria 2.0

- Local de diseño, desde el exterior no parece que es una inmobiliaria, parece una galería de arte.

- Al entrar te encuentras con un monitor con videos musicales, otro monitor con anuncio de la inmobiliaria, otro monitor con información técnica de las promociones, y en otro monitor puedes chatear con tus amigos.

- Después de un rato, que no sabes donde mirar, te sientas en una silla, que tiene masaje para los pies, y de pronto, aparece un cantante de rap, cantando las características de los pisos que vende.

Desde luego, volveras a este local más veces, aunque ni siquiera te has enterado lo que venden, ni el precio, pero no te importa.

Esto, que parece una exageración, es la pura realidad, mientras las tiendas y portales, siguen apostando por un diseño clásico como google o amazon, algunos quedan encantados por las maravillas de web 2.0, haciendo portales de internet, totalmente inutiles, como la página de ww.nike.com, que despues de una hor navegando, aún no he encontrado como comprar un zapatilla.

¿Como tiene que ser una página web?

1. Debe cumplir el objetivo para la que fué diseñada.

Si es una web para vender, en 5 clicks debes poder hacer un pedido.

Si es para informar, debe presentar información clara y concisa. Es muy común en las páginas web de pequeñas empresas, que no aparezca ni su teléfono, ni su dirección.

2. Tiene que inspirar confianza, incoporando información sobre la empresa, forma de contacto, etc..

3. Tiene que estar bien organizada, la información e contacto en “Contacto”, los productos en “Productos”, etc..

4. Y los más importante, tiene que funcionar!!!!! es desesperante en algunas páginas de bancos y seguros, que por la incorporación de AJAX, la página de errores y no funcione en todos los navegadores.

En conclusión: Sólo teneis que echar un vistazo a www.google.es www.amazon.com www.apple.com

2 Comentarios

Código samurai: como programar mejor

Este artículo es un resumen de los consejos ofrecidos en el artículo Free Programming Tips are Worth Every Penny (Consejos gratuitos para programadores que valen su peso en oro) por Will Shipley.Dibujo de samurai. Autor: Eugene Collache

Sigue el Código Samurai

Los antiguos samurais, cuando luchaban, se pasaban horas observándose mutuamente hasta que repentinamente uno de ellos lanzaba un sólo golpe y derrotaba al contrincante.

Cuando vayas a programar, antes de nada, piensa, luego piensa un poco más, hasta que tengas una idea de conjunto de todo el proyecto. Luego piensa en un problema concreto con el que vayas a comenzar a programar, piensa de nuevo en el conjunto y en como encaja esta pieza en él. Entonces comienza a escribir código. No escribas una sola línea de código hasta que no tengas claro que es lo que vas a hacer.

Si eres de los que necesitan escribir para pensar: escribe en una carpeta aparte, crea tantas nuevas carpetas como bocetos necesites y cuando ya tengas el dibujo completo entonces escribe en la carpeta o proyecto definitivo; reutilizando los fragmentos de código que son de calidad y reescribiendo de nuevo lo que haya salido emborronado.

Escribe todo el código “en limpio” la primera vez que lo escribas. No hagas una chapuza pensando que lo arreglarás más tarde, de hecho nunca lo arreglarás. Utiliza clases para todos. Usa tipos enumerados.

Escribe código robusto y “a prueba de balas” desde el principio. Piensa en todo lo que podría causar un fallo y toma medidas preventivas como si el fallo ya hubiera ocurrido.

Cada vez que retoques tu código para añadir funcionalidades o corregir un fallo aprovecha para hacer limpieza. Haz limpieza todo el rato. Pasa el paño cada vez que veas una mota de polvo afeando tu código.

Menos código casi siempre es mejor. Mejor para depurar, mejor para que lo entiendan otro programadores o tu mismo en el futuro, menos código son menos fallos. No añadas funciones adicionales a una clase pensando que las necesitarás en el futuro. Escribe sólo lo que necesites ahora. Cuando necesites contemplar nuevos casos escribe una función más genérica, que admita parámetros, pero no lo hagas hasta que no estés usando esa función en dos o más lugares de tu aplicación.

No te obsesiones con la velocidad y la eficiencia de tu código al principio. Tu tiempo de programador es caro, el hardware es rápido y barato. Cuando tu código funcione y esté depurado podrás hacer test de rendimiento y encontrar los cuellos de botella que merece la pena optimizar.

Haz un comentario

Las ventajas de programar con un framework

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.

Haz un comentario

El arte de programar

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.

Central Solar Solucar

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

Haz un comentario