Cada vez que uno recomienda algo, está dando una aprobación con un cierto grado de responsabilidad. Sin embargo, aveces nos encontramos recomendando cosas que no conocemos demasiado por el simple hecho de ayudar a quien solicita una opinión.

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.

 

Seguramente a casi todos los programadores PHP le ha sucedido tener que comparar datos booleanos y más de uno se habrá rascado la cabeza cuando el 0 era interpretado como nulo.

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?

Desde toda la vida, el varchar estuvo diseñado para contener 255 caracteres; cosa que lo hacía ideal para urls, emails, nombres, y demás textos limitados. Pero esto ya no es más así:

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.

Un poco de humor geek para variar…

En realidad no se trata de un problema de Opera, le hubiera pasado a cualquier navegador que hubiera llegado a los dos dígitos y como Opera es el primero, cae en la volteada.

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

Google sigue desarrollando nuevas tecnologías y Native Client se perfila como punta de lanza para llevar el software de escritorio a la web. Se trata de una tecnología que permite ejecutar código x86 (cualquier código de aplicación de escritorio) en un browser. De esta forma, no importa si está programado para Windows, este será servido a través de aplicaciones web, evitando así toda incompatibilidad de plataforma.

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.

Sin entrar en el neutralismo de “todo depende del proyecto” creo que este planteo tiene una base sólida: más de 4 años en el desarrollo web, tres de ellos en una empresa de desarrollo de software.

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.

PHP.js es un ambicioso proyecto colaborativo que trata de programar tantas funciones de php en java script como sea posible para lograr una mayor compatibilidad entre ambos lenguajes. Por el momento ya tienen una lista de 190 funciones escritas y pueden encontrarlas en esta librería JS.

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

Esta solución al Ajax Cross Domain representa, para mí, uno de los mejores descubrimientos en materia de programación Javascript de los últimos tiempos y es, al mismo tiempo, una de las peores vulnerabilidades encontradas a TODOS los navegadores del momento.

Por cuestiones de seguridad, no se puede hacer CrossDomain utilizando ajax, sin embargo, con esta librería ahora es posible. Simplemente usa un llamado @import url() CSS con la URL que necesita, la librería se encarga de encodearlo de manera tal que el navegador interprete que es una inofensiva URL de un CSS el que se está solicitando en otro dominio. Pero lo que hace en verdad es solicitar una URl cualquiera, obteniendo su información.

Como esto es totalmente válido, me refiero a incluir, en nuestro sitio, un CSS que está hosteado en otro dominio, el navegador no se da ni por enterado que en realidad estamos haciendo CrossDomain.

Utilizar la librería es realmente MUY fácil, simplemente incluimos la librería y después solo resta llamar el método con la función callback que necesitemos:

CSSHttpRequest.get(
“http://www.nb.io/hacks/csshttprequest/hello-world/”,
function(response) { alert(response); }
);

Hasta el momento no había ninguna opción independiente de alguna ejecución en el sevidor, como lo es Ajax Cross Domain. Ahora todo depende de una sola librería JS open source.

Estos tipos son unos genios. Me pregunto si esto servirá para que los navegadores validen de forma más estricta lo que se está pasando por el @import o si abrirán una puerta legal al CrossDomain.

Magnífico.

Esta incógnita surgió ayer en la oficina y suscitó varias fervientes discusiones. Para muchos, la maquetación debiera ser realizada por el diseñador y, para otros, por el programador. Y si bien esto se viene discutiendo desde hace mucho, me pareció interesante hacer un breve planteo en este blog sobre lo que opino al respecto.

Para mí, el maquetador no debe ser tomado como una persona sino como un rol. Y este rol no debe ser polarizado ni en el diseño ni en la programación. Debe estar justo en el medio, es decir, lograr una interacción con el rol del programador y el rol del diseñador.

Algunos diseños requieren más esfuerzo de maquetación de otros y es ampliamante recomendable que, aunque el diseñador no maquete, conozca las bases de la maquetación para evitar trabajo extra del maquetador.

Por otro lado, el maquetador, necesita también considerar algunos conceptos básicos de la programación. Más de una vez me he visto formularios quilométricos en donde el maquetador copió y pegó cajas de texto incluso donde iba otro controlador como menús desplegables o campos de opción. Dejándoles, al mismo tiempo, el mismo nombre a todos y cada uno de los campos, lo que conllevó un doble trabajo en la programación.

La maquetación jamás debe polarizarse sino seguro habrá guerra y discusiones entre el programador y el diseñador.

Es por eso que, de acuerdo con mi experiencia, el maquetador debe encontrarse en el medio de los extremos entra la programacion y el diseño y debe conocer lo que implican ambas actividades.

La mejor práctica de todas es que el maquetador tenga interacción con el diseñador, en caso que sea un programador y con el programador en caso que sea el diseñador. La sinergia es invencible.