Eso me pasó siempre cada vez que alguien me pregunta qué framework PHP debería utilizar. Siendo que nunca me gustaron demasiado los frameworks por el simple hecho que estos te limitan el campo de acción debo reconocer que trabajar sin uno hoy en día es casi suicida.

Habiendo pasado por varios frameworks he visto cómo se suele desvirtuar el objetivo y la utilidad de un framework en nombre de la sencillez, la estabilidad, facilidad de uso y dios sabe que otra aberrada justificación.

Ejemplos como:

• Utilizar sesiones propias engorrosas y pesadísimas en pos de la seguridad (WTF) en vez de utilizar sesiones nativas del lenguaje.
• Tener que aprender a utilizar  funciones para cerrar un simple tag html como podría ser form_close() que lo único que hace es imprimir un “</form>”
• Obligar al desarrollador a usar GET o POST dependiendo sea el caso o el módulo a utilizar.

Todas estos ejemplos hicieron que no haya tenido buena experiencia en general con los frameworks PHP o los CMS mal llamado frameworks.

Es por esto que  con Pixelatom continuamos una idea que tuvo Javier y que plasmó en su LinxPHP, un framework que ofrece la estructura básica para trabajar en cualquier tipo de proyecto.

LinxPHP no ofrece, como otros, codificar menos o menos tiempo de desarrollo. Lo mejor de linx es que ofrece una estructura sólida para que un desarrollador con experiencia de programación orientada a objetos pueda demostrar lo que sabe sin tener que preocuparse por la estructura genral del sistema.

Las principales ventajas y las vertebras de LinxPHP son las siguientes:

• Un enrutador que permite trabajar con URL amigables directamente con los controladores.
• Modelos que mapean la base de datos y que crean todas los objetos necesarios para trabajar con la base de datos
• Un MVC  básico para no tener que aprender nada nuevo.

En Pixelatom venimos laburando hace más de un año con este framework y hemos realizado más de 30 sistemas y sitios webs con un éxito rotundo. Por lo que ahora, después de varias vuelta de tuercas, lanzamos el framework con licencia Open Source para que pueda seguir creciendo y alimentándose de los desarrolladores que están podridos de tener que limitarse con las funcionalidades de los frameworks monstruosos.

Es por eso que, hoy en día, si me preguntan que framework PHP utilizar, puedo decir sin preámbulos y tranquilo que LinxPHP se la banca un paquetazo.

Esto se debe a que PHP tiene 2 formas de comparar datos, una compara el valor y otra también el tipo de dato. Es así entonces como
0 == false
pero
0 !== false

A continuación, listo una serie de casos para entender mejor cómo funciona la comparación de PHP con los datos booleanos. Probablemente se sorprendan con varios de estos

Las siguientes comparaciones dan verdadero (true) en todos los casos

• false == ”
• false !== ”
• false == null
• false !== null
• null == ”
• null !== ”
• 0 == null
• 0 !== null
• null !== ”
• null == ”

Otra curiosidad de yapa: count(”) devuelve 1

¿Alguno de estos casos te llamó la atención y no lo habías considerado?

Values in VARCHAR columns are variable-length strings. The length can be specified as a value from 0 to 255 before MySQL 5.0.3, and 0 to 65,535 in 5.0.3 and later versions.

Resulta que a partir de la versión 5.0.3 de MySql, se permiten varchar de hasta 65.000 caracteres.

¿Es bueno cambiar la estructura de datos de un lenguaje tan radicalmente? ¿Para qué hacen tanto hincapié, entonces, las facultades para enseñarte (casi de memoria) los tipos de datos?

En fin… si se quedan cortos ya saben, usen varchar(2000) que está todo bien.

Estaría mejor decir que son los sitios quienes tienen problema con Opera 10. ¿Por qué? por la simple razón que capturan mal la versión de los navegadores y en vez de leer 10, leen 1.

Y no estamos hablando de cualquier sitio, sino de sitios como Microsoft, el Bank of América y el banco South Australia entre muchos otros.

Estas son las respuestas HTTP con el opera 9.62

GET /InternetBanking/ HTTP/1.1
User-Agent: Opera/9.62 (Windows NT 5.1; U; en) Presto/2.1.1
Host: ibanking.banksa.com.au

HTTP/1.1 200 OK
Set-Cookie: JSESSIONID=000019WTazsWAk-lB38OrmKD3kR:13l3ifhnq;Path=/
Set-Cookie: bhCookieSess=1;Path=/
Set-Cookie: bhCookiePerm=1;Expires=Sat, 20-Dec-2008 23:35:40 GMT;Path=/

Esta con el 10

GET /InternetBanking/ HTTP/1.1
User-Agent: Opera/10.00 (Windows NT 5.1; U; en) Presto/2.2.0
Host: ibanking.banksa.com.au

HTTP/1.1 200 OK
Content-Type: text/html;charset=ISO-8859-1
Content-Language: en-AU
Date: Thu, 18 Dec 2008 23:34:37 GMT
Connection: close

No entiendo como se les puede pasar semejante error a los programadores de los sitios webs.

Lo vi en un blog de Opera

La lista de ejemplos y tests es prometedora. Imagínense poder jugar al Quake desde el browser.

La tecnología es Open Source (BSD) y ya puede encontrar todo lo necesario para correrlo en diferentes plataformas (Windows, Linux, Mac).

Fabuloso.

Los administradores de proyectos web, debieran exigir más documentación tanto al cliente como al desarrollador.

Muchos desarrolladores amigos quizá no estén de acuerdo y seguramente cada cual tendrá una opinión válida que me gustaría leer en los comentarios. La necesidad de expresar esto me surge luego de leer este artículo bastante bien fundamentado pero del cual no estoy de acuerdo. Uno de los pasajes dice:

They also showed me two big books (sorry, specification docs) with around 300 pages in total. And the project was quite simple – it was basic CRU (Create, Read, Update) with one type of objects to be stored and queried. Believe me – the system was simple.

Wow! That’s a lot of, for a simple system, to read – imagine how much time you need to read this. And it’s nothing comparing to how much time and effort it cost to produce it – and you still have no single line of code working.

Sinceramente, nunca me tocó un proyecto que esté sobre documentado pero en caso de que me toque, bienvenido sea. Prefiero gastar esfuerzo y tiempo en leer documentación que en pelear con el cliente sobre sus vagos requerimientos.

Más de una vez, por no decir siempre, el proyecto se subestima. El cliente dice que necesita ciertos requerimientos, esos requerimientos se estudian y se propone una solución en un determinado período de tiempo con una cierta cantidad de esfuerzo.

Sin embargo, en la mayoría de los casos, esos requerimientos terminan duplicándose debido a que los requerimientos originales ocultaban suposiciones que el cliente omitió.

El administrador de proyecto, en este caso, debiera exigirle al cliente, toda la documentación necesaria sobre los requerimientos. Y cuando digo necesaria me refiero a que el PM tiene que detectar estas suposiciones ocultas y aclararlas antes de que se comience el proyecto.

Por otro lado, en el afán de vender el servicio, se omiten los tiempos de documentación y de las especificaciones técnicas del desarrollo. Y este, es un punto en donde la mayoría de los PM y desarrolladores hacen agua.

El PM necesita y debe asignar esfuerzo y tiempo a la documentación técnica del proyecto, incluso si el cliente no lo desea. Esto debe ser integrado a la propuesta y el estimado.

Si no, lo que va a ocurrir tarde o temprano, es que la modificación o mantenimiento de ese sistema se vuelve más caro que el desarrollo de uno nuevo.

¿Te interesa el tema? Comentá lo tuyo.

Muchas funciones son simples manejos de array, otra más complejas tiene el algoritmo de encriptación MD5 e incluso está disponible la clásica base64_decode(). Hay otras otras más simples pero muy útiles como la función date().

Me parece un proyecto fantástico e invito a todos los profesores de programación para que inciten a sus alumnos a participar en este proyecto como alternativa a los clásicos ejercicios que suelen dar a sus alumnos.

El proyecto está muy bien organizado y tiene la documentación necesaria tanto para participar como para utilizar la librería.

Gracias Javier