SeViR Notes

Después de unos cuantos años como usuario de MacOSX y desengañado en el último año tengo una opinión bastante forjada de las bondades y quebraderos de cabeza que pueda dar un MacOSX.

Los sistemas operativos de Apple siempre se han caracterizado por un buen rendimiento y optimizados para tareas gráficas y vídeo. Uno de los grandes avances y una apuesta de futuro fue la de apostar por un núcleo UNIX pero manteniendo una estupenda capa gráfica y una interfaz de usuario fácil de utilizar, así nació la serie MacOSX.

No os puedo mentir, el uso diario de un MacOSX como usuario o como programador supone toda una experiencia. El sistema operativo está concebido para una extrema facilidad de uso que podemos ver en cuanto intentamos instalar un programa, simplemente arrastrando y soltando a la carpeta de Aplicaciones, viene con una buena cantidad de aplicaciones útiles (un cliente de correo soberbio, visor de mapas, notas, visor de imágenes, etc...) y elementos que crees que nunca vas a poder separarte de ellos como Spotlight, la Vista Rápida (ver cualquier documento con la tecla espaciadora) o el Dock o barra de aplicaciones, mucho más vistosa pero a la vez extraordinariamente ligera y fácil de usar.

Desgraciadamente (no se si tendrá algo que ver) desde la muerte de Steve Jobs, mientras Microsoft hacía cada vez más ligero y rápido su Windows, MacOSX se ha vuelto más lento y con más retardos en tareas tan simples como ver el correo, abrir aplicaciones o el manejo día a día, requiriendo equipos más potentes. Y no porque tuviésemos equipos poco potentes.

He estado trabajando con MacOSX, programando y emulando Windows con aplicaciones sin ningún problema, pero de una versión a otra (de un día para otro) parecía que mi portátil hubiese envejecido varios años y su rendimiento cada vez peor. Mavericks, Yosemite, han añadido pocas mejoras, solo unas pequeñas aplicaciones y algunas ideas de iPhone pero además mayores requerimientos que de forma extraña nunca resultan suficientes...

Cuando empezaron las actualizaciones a Mavericks se encontraban por la red quejas de usuarios con equipos de Apple con 32GB de RAM y potentes procesadores que funcionaban apreciablemente lento una vez actualizados.

Parece que todo haya funcionado bien hasta las versiones 10.8.x, y a partir de aquí cometiendo los errores que en el pasado se atribuían a Microsoft.

Aún así, MacOSX tiene muchos puntos a favor, el corazón UNIX permite qe podamos programar web como si fuese Linux, existen muchas aplicaciones equivalentes y las rutas de los ficheros son similares aunque la parte UNIX suele estar oculta para el usuario, mostrando únicamente las carpetas que le interesa. Las aplicaciones de MacOSX suelen acompañar en intefaz gráfica y facilidad de manejo, los programadores de aplicaciones para MacOSX suelen hacer muy buenas aplicaciones y de las que los usuarios de Windows y Linux suelen ver con envidia.

A menudo mantenemos la relación (incluso en el mundillo de la informática) de Software Libre igual a GRATIS, oigo multitud de clientes que me comentan "Usa software libre que es gratis y así abaratamos".

Por lo general la forma de discutir esto siempre comienza por Libre es distinto de GRATIS, y que viene de una mala traducción de la palabra FREE en Free Software, la denominación en inglés. Pero aún así, cuando pensamos en Software Libre, pensamos en gratis.

Ahora bien, este planteamiento, no es del todo inválido, pues efectivamente, el Software Libre por lo general no implica un deselvolso de dinero inicial o pago por uso (digo por lo general, lo que no es en todos los casos). Pero esto no quita que, primero, no haya costado tiempo y esfuerzo de alguien el producirlo (y por lo tanto dinero), y segundo, que si en algún momento detectamos un problema y como programadores decidimos resolverlo pues lo usamos en algún proyecto propio, es responsabilidad nuestra también comunicar estos cambios a los creadores originales para que puedan añadir nuestras mejoras.

A menudo en DIGIO hemos mejorado multitud de herramientas de Software Libre y en muchas ocasiones por falta de tiempo, no caemos en la cuenta que comunicar y pasar las mejoras al proyecto original es una responsabilidad, sino que además repercute en mejoras futuras que pueden hacer otros sobre nuestros cambios que de otra manera, no obtendríamos, por lo que es una apuesta por ahorrarnos esfuerzo y trabajo en el futuro.

El coste de comunicar estos cambios a los proyectos de Software Libre suele ser siempre mucho menor que el coste de las mejoras futuras que obtendremos. Y en caso contrario aunque solo sea porque nuestro esfuerzo y dedicación no desaparezca con nuestro proyecto, sino que otros puedan aprovechar nuestro trabajo para mejorarlo y continuarlo.

Todo el que me conoce sabe que no soy un completo fanático del Software Libre, lo uso y he colaborado y aportado muchos cambios en muchos proyectos, pero eso no quita que no pueda ver puntos flacos en el planteamiento como excesiva fragmentación en proyectos derivados, mayor carga de correos (no os podéis imaginar la cantidad de correos que pueden llegar de Github, en cuanto uno hace grandes colaboraciones en proyectos de Software Libre, pero creo que es importante que el trabajo que hacemos tenga más vida fuera de lo poco que podamos desarrollar de forma interna y es el precio que debemos de pagar por desarrollar con Software Libre.

Aunque hace bastante tiempo de esto, aún tiene mucha utilidad. Se ha convertido en una costumbre que las aplicaciones webs estén pobladas de consultas o peticiones AJAX, cargando inicialmente una plantilla, y actualizando los contenidos mediante consultas o peticiones asíncronas.

Cuando queremos subir ficheros en segundo plano sin realizar la carga, en cambio no podemos usar AJAX, teniendo que remitirnos al File API de HTML5 o bien buscar una técnica alternativa que permita enviar un formulario con un formulario en multipart en segundo plano. Esto se puede conseguir mediante iframes, la técnica se basa en crear un iframe no visible (que no oculto, si está display:hidden no funcionará), de un tamaño de 0 pixeles y sin bordes conseguiremos un iframe funcional pero que no es visible por el usuario. Si indicamos como target de un formulario multipart este iframe, podremos subir un fichero sin recargar la página.

El problema será entonces conocer el momento en que el archivo se ha terminado de subir, para esto la respuesta cargada en el iframe debe ejecutar una llamada JavaScript definida en la ventana padre, que como si fuese una función de Callback se ejecutará cuando tengamos subido el fichero.

Poder obtener datos en JavaScript entre diferentes dominios permitirá crear fácilmente servicios web en formato JSON, a esta técnica se le denomina JSONP, consiste en devolver no un objeto JavaScript sino la llamada a una función con el nombre que escojamos (función callback) pasando como parámetro este objeto. Cuando cargamos una url con la llamada al servicio lanzaremos la ejecución de la función de callback con los datos que esperamos de respuesta. Esto ya lo hace jQuery por detrás cuando ejecutamos el método $.getScript generando una función con un nombre aleatorio.

Para todo esto tenemos una librería que nos ayudará para generar respuestas en formato JSON, JSONP, XML y respuestas a través de iframes, si usamos CodeIgniter 2 o superior, mediante Spark/ajax disponemos de una serie de funciones helpers y métodos útiles para generar respuestas válidas en JSONP, envío de respuestas dentro de un iframe o respuestas en XML.

Con un método $this->ajax->response() podremos generar respuestas para enviar como JSON, JSONP, extender un objeto JS con jQuery, asignar datos generados a una variable, o generar respuestas en XML a partir de un objeto PHP.

Por ejemplo queremos cargar las cadenas de traducción de un array PHP a una variable JavaScript, podríamos añadir una carga de script en HTML

<code>< script type="text/javascript" src="http://url/controller/method">
</code>

y que este método PHP devuelva los datos en una variable:

<code>$this->ajax->response($array_traduccion, null, TRUE, "varjs");
</code>

Esto cargará los datos en varjs para poder usarlo en JavaScript. Esto funcionaría también en cualquier dominio, por lo que sería cross-domain.