octubre 2012

Cambiar los saltos de linea rn de Windows a n de Linux, Unix, Mac OSX

Quienes tenemos que trabajar con código fuente entre varios sistemas operativos, a veces nos encontramos con un mas que desagradable problema, y es que los saltos de linea se desvirtuan. Al trabajar desde un sistema operativo nix, como pueden ser: Linux, Unix, Mac OSX (si ya se que es un Unix pero es por dejarlo claro) y mover esos ficheros a un Windows, salvo que editemos los ficheros con el avanzadísimo sistema del notepad, no tendremos mayores complicaciones. Realmente, si editamos a la inversa, es decir, llevando el archivo desde Windows a Mac OSX o a Linux, no tendremos tampoco muchos problemas, ya que los sistemas están preparados para soportar los saltos de linea. El problema real radica en los sistemas de control de versiones.

Pongo en situación para quien no lo conozca. En los sistemas operativos hay un caracter especial que determina el salto de linea, lo que ocurre cuando pulsamos la tecla intro en un editor de texto, como si de una maquina de escribir, baja un nivel, hasta la siguiente linea. El caracter de salto de linea se representa con n. Ahora vayamos a Windows y su similitud con las máquinas de escribir. En Windows no basta con hacer un salto de linea n, sino que ademas hay que hacer un retorno de carro. Probablemente muchos no sepan que significa un retorno de carro representado con r pero viene de cuando en las máquinas de escribir antiguas llegabas al final de la linea, con una palanca que había en el extremo, el carro (donde se posiciona para escribir en el papel) se desplazaba hasta el principio de la linea. Por tanto en Windows, el salto de linea se representa con rn es decir, retorno de carro (volver el cursor al principio de la linea) y un salto de linea.

Es por esto, que cuando tenemos un sistema de control de versiones como puede ser GIT o SVN y archivos de diferentes sistemas nos podemos encontrar con el problema de que nos dice que el 100% del archivo ha cambiado, solo porque ha cambiado el salto de linea y entiende que es una linea nueva. Esto por ejemplo pasa con el cliente de consola de GIT por poner un caso, pero ocurre en mas lugares. La solución es muy fácil, solo tenemos que ejecutar un script que nos corrija los molestos saltos de linea de Windows de la siguiente manera:

perl -i -pne "s/rn/n/g" archivo-a-corregir.html

Donde le decimos a perl que recorra cada linea del archivo en modo sed y que nos sustituya los rn de Windows por los n de Linux/Mac OSX. También podemos utilizar el comando sed tal que:

sed -i "s/rn/n/g" archivo-a-corregir.html

Cual utiliceis es a gusto de cada uno. Quizas el sed sea mejor, puesto que al ser un comando del sistema operativo y no perl directamente a alguno le gusta mas.

Desactivar el scroll vertical en apps de phonegap

Al hacer una app con phonegap, nos encontramos con que el scroll horizontal se desactiva fácilmente, ya que phonegap, al tener un webview, este se adapta a nuestro html y si ademas eliminamos la opción de zoom con los scale

<meta name="viewport" content="initial-scale=1, maximum-scale=1, minimun-scale=1, user-scale=no" />

Resultará curioso como al probar nuestra aplicación, horizontalmente es estática, pero cuando deslizamos el dedo de arriba hacia abaja, vemos un efecto cuanto menos curioso y es que se desliza como si fuera una página web normal y corriente, es decir, nos aplica un scroll vertical como el navegador. Os pongo una imagen para que veáis lo que digo:

Esto es muy fácil de arreglar. Tan solo tenemos que irnos a nuestro proyecto de phonegap, concretamente al archivo Cordova.plist, que lo podemos encontrar de 2 formas:

  • Xcode: raíz del proyecto > Resources > Cordova.plist
  • Finder: raíz del proyecto > [Nombre del proyecto] > Cordova.plist

Ahora, dependiendo de si lo editamos desde Xcode o con otro editor veremos algo como lo siguiente:

Tan solo deberemos poner el valor del UIWebViewBounce a NO en Xcode o a false en el xml del plist y asunto arreglado, al intentar hacer scroll vertical, ya no se deslizará fuera de la pantalla.

El porque del estilo Metro y Windows 8, cuando debemos de actualizar nuestro navegador

De casualidad y haciendo unas pruebas para una web, di con la clave del por que del diseño que se utiliza en Windows Mobile y en las futuras versiones a partir de Windows 8 en escritorio. Los diseñadores de Redmon, se les ocurrió la idea de copiar un framework de fronted como puede ser bootstrap de twitter, tras pensarlo deliveradamente, decidieron entrar en la web de bootstrap con la versión en ese momento de Internet Explorer.

Aunque en el momento ya estaba Internet Explorer 9, como iba a ser utilizado para Windows 8, decidieron entrar con la versión de Internet Explorer 8 (por eso de hacer el honor al 8) y se encontraron una agradable sorpresa y es que el diseño les encanto. Pero ojo, no penséis si vais corriendo a la web de bootstrap vais a ver lo mismo que ellos vieron, nada mas lejos de la realidad. Lo que verían estos diseñadores eran cajas cuadradas, de colores claros, elegantes y lisos. Nada de degradados, brillos y efectos. Os dejo una captura de como se ve la web en Internet Explorer 8 y os animo a entrar con vuestro navegador favorito, ya sea Chrome, Firefox, Safari, etc.

Ni que decir tiene que es una chorrada de las típicas que se le ocurren a uno cuando lleva demasiadas horas trabajadas y que la interfaz Metro, Windows 8 o ModernUI como la llaman (ya que con Metro tienen un pleito de marcas registradas), es una interfaz que aunque para mi gusto tengo otras preferencias con mas curvas, no es desagradable a la vista (aunque si algo extraña). Por supuesto todo tiene su por que y esta interfaz no es menos.

Espero que por lo hemos os haya sacado una sonrisa.

Video sobre el jQueryIO acerca de buenas practicas con jQuery

El otro día tuve la suerte de estar en el jQueryIO junto a Miguel Angel Alvarez de desarrolloweb.com y Quique Fernández. Hicimos una pequeña charla hablando un poco sobre buenas practicas a la hora de trabajar con jQuery y como mejorar el rendimiento de nuestras aplicaciones web.

Una parte de lo que se habló, esta publicada en la web en algunos artículos como: Guía de buenas prácticas para aumentar el rendimiento de jQuery o Selectores dobles con JQuery, aumentando el rendimiento de JQuery

Os dejo el video de la charla para quien quiera echarle un vistazo y deje sus opiniones:

Introducción a RaphaelJS

RaphaelJS es una librería de javascript para desarrollar gráficos y animaciones vectoriales en SVG y VML. ¿Qué es SVG? ¿Por qué vamos a utilizar gráficos vectoriales? ¿Para qué utilizar una librería para trabajar con SVG? Todas estas preguntas son las que debemos comprender antes de empezar a trabajar.

Gráficos Vectoriales Escalables o abreviado del ingles SVG (Scalable Vector Graphics) es un estandar propuesto en el año 2001 por el W3C para estandarizar los gráficos vectoriales. Allá por el año 1998, se presentaron 2 propuestas de gráficos vectoriales, por un lado se presento PGML por parte de Adobe, IBM, Netscape (Mozilla y Firefox) y Sun (Java, ahora parte de Oracle). Por otra parte se presento VML que tuvo más éxito por parte de Autodesk (creadores de Autocad), Macromedia (creadores de flash y posteriormente comprado por Adobe) y Microsoft. Normalmente cuando se hacen varias propuestas de este estilo al W3C, se acaba decantando por una en particular, pero en este caso, se optó por el camino del medio y el W3C propuso SVG que no es mas que la mezcla de VML + PGML.

Con SVG se crea un documento XML que puede ser utilizado tanto en un archivo independiente con extension *.SVG como embebido dentro de una página web al ser un XML y puede ser manipulado con javascriptSVG tiene su propio árbol DOM similar al HTML por lo que fácilmente desde javascript podremos capturar eventos, cambiar sus caracteristicas, así como dar estilos desde CSS.

Una vez tenemos la base, podemos entender mejor el papel de RaphaelJS en todo esto. RaphaelJS es una librería que nos promueve de una gran cantidad de objetos y métodos para encapsular los documentos SVG. Esta necesidad vino dada en su dia por los navegadores antiguos que interpretaban VML y los mas modernos que fueron interpretando SVGRaphaelJS genera los documentos dinámicamente en uno u otro lenguaje, dependiendo de lo que soporte el navegador, siempre dando prioridad al estandar SVG.

Si todos los navegadores actuales soportan SVG ¿Por qué utilizar una librería como RaphaelJS y no SVG nativo? Muy sencillo y es que cuando queremos generar unos gráficos en SVG dinámicamente, con animaciones y demás, necesitamos de un respaldo de utilidades que nos faciliten en todo lo posible el trabajo, ya que el objetivo es ser productivos. Por ejemplo, para quienes conozcan jQuery, todo el mundo sabe hacer un document.getElementById, pero siempre acabamos haciendo $(«#id») porque es más cómodo, ademas de ofrecernos herramientas muy útiles. Con RaphaelJS pasa lo mismo, si queremos generar una animación en SVG, nos ofrece funciones con calbacks para generar animaciones dinámicamente con varias funciones easing o podemos guardar los objetos de SVG según los vayamos creando para reutilizarlos mas adelante, ademas de ser un poco mas sencillo de utilizar que SVG a pelo.

Este contenido y mas ira apareciendo en el curso de Raphael JS – Gráficos vectoriales con javascript y mas en concreto en el primer capítuo: Introducción a RaphaelJS.

Scroll al inicio