Programación

Publicaciones que no se centran en ningún lenguaje de programación en concreto

Digan lo que digan, GIT es el mejor

Para los que se hayan dedicado desde hace mucho al desarrollo, conocerán, casi que seguro algún sistema de control de código fuente (Source Code Version System) y seguramente habrán preferencias al respecto, sin embargo desde hace cosa de un par de añitos vemos que poco a poco GIT se va imponiendo entre el tipo de repositorios de código fuente más habituales. Páginas como GitHub o Bitbucket hacen casi uso exclusivo de este tipo de repositorios para distribuir código fuente, amén de los fuentes de Linux que también lo usan, pero ¿por qué?…

Echemos una ojeada a la historia de GIT. Git fue creado por nada menos que el mismísimo Linus Torvalds, papaito del sistema operativo Linux. Al parecer, Linus estaba bastante harto de cómo funcionaban los repositorios que tenía que utilizar, por ejemplo SVN (proyecto libre de Apache Foundation) y decidió hacer uno por su cuenta, pero con ligeros detalles que lo harían diferente del resto.

  • Los repositorios sin distribuídos. Esto significa que en teoría no hace falta tener un servidor centralizado para distribuir los repositorios, aunque se puede, de hecho uno mismo puede crearse uno en su ordenador y no tener que distribuirlo, pero que de cualquier manera, se puede usar para controlar las versiones de un proyecto.
  • Acepta muchos tipos de conexión para distribuir las versiones, como SSH, HTTP, etc. por lo tanto es muy adaptable.
  • Está pensado en ser muy rápido por lo que es ideal para trabajar con muchos ficheros (doy fe!!!).
  • Si alguien necesita trabajar con SVN pero quiere seguir usando GIT puede usar git-svn para ello.

Y todo esto muy bien pero, ¿por qué está siendo muy popular? Entre otras cosas la culpa lo tiene el fuerte apoyo de la comunidad de usuarios Linux. Al adoptar este tipo de repositorio ha incrementado la popularidad de git y el interés general sobre él. La facilidad de uso, fácil integración en cualquier entorno y la cantidad de clientes para añadir una interfaz de usuario usando ventanas (GUI) hacen que se adapte a cualquier entorno o sistema operativo, aunque siempre quedarán los puristas, como un servidor, que adoran el uso de la línea de comandos.

En resumen, si sois desarrolladores, tenéis acceso al servidor donde almacenáis los repositorios y estáis un poco hartos de SVN o similares, echad una ojeada a GIT. No os defraudará.

 

Ya hago hasta apps para móviles

Pues si faltaban cosas por hacer en mi vida ahora tengo otra nueva diversión, hacer aplicaciones para móviles.

Toda esta historia empezó cuando en mis primeros meses de trabajo en Hogarth Worldwide descubrí casi por accidente el entorno de desarrollo para apps móviles Phonegap. PhoneGap aseguraba que mediante únicamente código HTML, CSS y JavaScript era posible crear una app móvil que era capaz de funcionar en cualquier teléfono del mercado, ya fuera iOS, Android, Blackberry, etc; es decir, no hacía falta aprender Objective-C para iOS o Java para Android. Le estuve echando una ojeada con el fin de que en un futuro, medianamente próximo pudiera hacer algo en concreto ya que por aquel entonces tenía tiempo de sobra y no iba demasiado estresado en el trabajo. Pobre de mí, pensaba que ese nivel de “poco estrés” iba a durar poco y por motivos de falta de tiempo olvidé Phonegap por unos meses.

Unos cuantos meses más tarde tuvimos que hacer una especie de webapp para una empresa de reconocido prestigio (lo siento, esto es un blog, no puedo dar nombres) y a alguien se le ocurrió la genial idea de decir: “¡sería la caña que pudiéramos convertir esto en una app para móviles con su icono y que no se viera el navegador!” y en seguida recordé aquello que había visto hace unos meses… PhoneGap!! Dicho y hecho procedí a intentar descargar la última versión y…¿qué ha pasado? me encuentro que el proyecto PhoneGap es ahora de Adobe. Que en teoria funciona todo igual, pero hay que pasar por el aro de Adobe para algunas cosas. Yo, como chico amante del software libre, recordaba que el primer phonegap que vi era totalmente libre y opensource. Cual fue mi sorpresa enorme cuando descubro que al margen de PhoneGap existe “Cordova”. Cordova… ¿con V? Pues sí, a mi me pareció de lo más insólito, aunque investigando he descubierto que hay un lugar llamado así en Filipinas, a saber si le han puesto el nombre en honor a dicho lugar. Volviendo a Cordova; es lo mismo que phonegap, pero, desarrollado de manera OpenSource por Apache Foundation. A partir de Cordova se realiza Phonegap por parte de Adobe, lo cual no deja claro si PhoneGap es un fork comercial de Cordova o es simplemente una versión que pagando se puede obtener soporte. En fin, que a fin de cuentas ambos son completamente compatibles, por lo que queda a gusto del consumidor elegir cuál es la más apropiada. Yo como ya he dicho antes, me he decantado por Cordova para evitar tener que pasar por el aro de cualquier empresa.

Mis primeros pinitos con Cordova no estuvieron mal. Conseguí compilar la webapp que habíamos hecho en la oficina e instalarla en un iPad. ¡¡Impresionante!! Teníamos un bonito icono y una webapp hecha a partir de código HTML y JavaScript. Pero… ¿esto es lícito? ¿Cómo es posible que funcione? Pues sí, sí que funcionaba. Pero PhoneGap/Cordova no solo se limita a hackear de alguna manera el teléfono para hacer una app desde una página web, te permite, mediante un API propio acceder a cosas internas del teléfono como la cámara, contactos, gps, etc, y es ahí donde entra la potencia de utilizar este framework. Con esta API se podría llamar a Google Maps y posicionarnos en una App de búsqueda, por ejemplo de restaurantes, donde el código es puro HTML+JavaScript, portarla a 3 sistemas y andando. Brutal, ¿verdad?

Con todo este nivel de emoción en mi cuerpo no dudé que tenía que desarrollar algo, pero, ¿el qué? Tenía que ser algo que fuera útil y que me permitiera aprender mucho en poco tiempo y mi querido ex compañero de trabajo James Miller (@jimhunty) me dio la idea. Estaba desarrollando apps móviles para equipos de divisiones inferiores de la liga inglesa de fútbol. Les eché una ojeada pero no me terminaban de convencer para la liga española así que me dije a mi mismo: “Voy a hacer una app para la UD Almería pero a mi manera”, y así empezó el proyecto. El problema de todo esto ha sido que se ha demorado por más de 9 meses, ¡¡¡ni que hubiera sido un embarazo!!! ya que tenía muy poco tiempo libre para dedicarle a la app.

En navidad aproximadamente tenía una beta medio funcionando tras 3 o 4 versiones completamente diferentes, en las que había cambiado prácticamente todo. Desde la forma de mostrar y recibir noticias a la apariencia visual. Recordemos que yo en el fondo soy sysadmin y de diseño sé bien poco, pero bueno, poco a poco y sin prisa.

Con todo esto llegamos hasta abril, semana de Easter (Semana Santa en España) y me encuentro que tengo tiempo más que suficiente para acabar la app y dicho y hecho. Tras dos días prácticamente enteros volcados en la App consigo acabarla, y tras probarla intensivamente en dos teléfonos y una tableta que tengo en casa decido que debe ver la luz. Pago religiosamente las cuotas de Google y Apple y me propongo subirlas a las tiendas de apps de las dos respectivas marcas, eso sí, sin saber el quebradero de cabeza que ello conlleva. Lo primero de todo es soltar pasta para algo que teóricamente iba a ser gratis. Google te pide $25, lo cual no está mal porque lo pagas una vez y ya está. Para mí eso son £16, lo cual es poca cosa, pero el problema es de los señores de Apple. £60 ($99) de golpe y encima anual, por no hablar de lo complicadisimo que es mandar una App a la AppleStore. Hay que pasar por mil cosas, rellenar formularios, pasar hasta por un proceso similar al fiscal, poco más que diciéndote que si haces algo ilegal vas derecho a la cárcel, en fin, una paranoya que no ocurrió para nada a la hora de subir la app a PlayStore de Google. En PlayStore solo tuve que darme de alta, pagar, preparar la App, firmarla digitalmente y subirla. Me costó un poco, pero vamos, en cuestión de dos horas la app estaba subida. En el caso de Apple, paga, pero paga hasta para probar la App en un teléfono; si no, es imposible, por no hablar del lío de certificados que hay que instalar, mandar, volver a descargar, etc y que hace falta un Mac sí o sí para desarrollar para iOS. En resumen, después de 4 horas (¡¡¡Si si!! 4 horas) de dar vueltas consigo mandar la App y primer problema, me sueltan que no tengo suficientes “screenshots” y que por favor suba las de un iPad. ¡¡¡Pero si no tengo un iPad!!! pero sin embargo, bendito emulador del Xcode que permite hacer screenshots.

En fin, que tras la odisea tengo las apps mandadas. La de Android está desde ayer publicada y se puede descargar sin problemas. La de iOS estoy esperando que Apple la apruebe, proceso que según he leído puede durar hasta 15 días, así que tengo los dedos cruzados para que todo vaya bien. Solo faltaba que después de pagar me dijeran que no la publican.

Si queréis más información podéis ver PhoneGap en este link o Cordova en éste.

Para descargar la App de la UD Almería que he realizado lo podéis hacer en los siguientes links. Recordad que la de iOS aún no está publicada, por lo que el enlace es provisional y entiendo que funcionará en un futuro no muy lejano.

Android: https://play.google.com/store/apps/details?id=es.khaos.udalmeria

iOS: https://itunes.apple.com/us/app/ud-almeria/id866761824?ls=1&mt=8

PHP rapido, sencillo y pontente: CodeIgniter

Justo nada más empezar a trabajar en el Reino Unido me llamó la atención un framework (entorno de desarrollo) que muchos compañeros de mi trabajo solían utilizar a menudo cuando llegaban proyectos que requerían el uso intensivo de patrones, templates o como queramos llamarlos. Dicho entorno tiene el nombre de CodeIgniter y sí, para mi gusto es lo mejor que me he encontrado en muchísimo tiempo cuando quieres aprender a usar un entorno basado en MVC (Modelo Vista Controlador https://es.wikipedia.org/wiki/Modelo_Vista_Controlador) pero no se tiene demasiado tiempo libre para aprender a usarlo.

Muchos puristas y frikis de la materia me podrán decir: “Ya tenemos Symfony”, a lo que yo respondería: “por desgracia tenemos Symfony”. Symfony es grande, demasiado grande para mi gusto la verdad. Quizás su mayor baza sea que es genial para proyectos enormes que requieran de un sistema tremendamente dinámico que cree formularios en un abrir y cerrar de ojos con un sistema muy orientado a las tablas, pero en mi caso esto no ocurre. Dicho esto, vayamos al kit de la cuestión.

CodeIgniter es genial por varias cosas, pero destacaría las siguientes:

  • Es muy sencillo de aprender; sí, más que Symfony, por mucho que les pese a más de uno
  • Aunque permite el uso de templates no es necesario usarlos si uno no lo desea, es muy poco restrictivo
  • Requiere configuración cero para empezar a utilizarlo, es decir, lo descargas, descomprimes y a trabajar.
  • No necesita de lineas de comandos para configurar nada, todo lo contrario que Symfony
  • Y sobretodo… es raaaaaapidoooooo. A penas tiene impacto sobre un código en PHP puro.

De todas formas, lo que realmente hace interesante a este Framework es que, al igual que Symfony, permite el uso de algo tan de moda como es la programación en modelo Vista-Controlador. Para el que aún no tenga ni idea de qué va el asunto les resumiré que es algo así como tener dos partes en el código fuente. Por un lado tendríamos la parte visual, es decir, archivos semiestáticos en html o php y otra parte, más orientada al backend, en el que viene toda la lógica interna de la página web: Llamadas a la base de datos, rutinas internas a nivel de servidor, control de variables, etc. De esta manera conseguimos algo realmente interesante en un equipo de desarrollo: Podemos poner a un desarrollador especializado en html+css a hacer la parte visual y otro desarrollador únicamente entretenido en la parte interna. El resultado se fusiona, manteniendo unas reglas obvias para no machacarse uno con otro y ¡¡listo!!

Si os sigue picando la curiosidad: https://ellislab.com/codeigniter

 

Eclipse y Ubuntu [Mal matrimonio]

Desde hace ya bastante tiempo uso Ubuntu en casa como sistema operativo principal, de hecho a Windows solo le veo en el portátil de la empresa y porque pos desgracia no me queda más remedio. A pesar de mi devoción por Ubuntu ha habido una cosa que siempre me ha tocado literalmente las narices y es Eclipse. Hace tiempo me costó lo suyo hacerlo andar en Ubuntu (corría entonces la versión 9.04) y desde entonces he andando con ese “paquetito” hecho a medida que iba viajando conmigo en cada actualización.

Hace pocos días me dio por instalarme la última versión en el ordenador del trabajo y .. ¡¡ooohhh!! ¡cuánta cosa bonita! Pues en cuanto llegue el fin de semana me lo instalo, me dije para mí mismo. Lo primero que hice fue aparcar la “carpetita” en cuestión e intentar instalar Eclipse desde el repositorio que tiene Ubuntu, sin acordarme que en su día eso fue lo que me volvió completamente loco e hizo plantearme el bajar y configurar a mi manera todo.

Aunque al principio todo fue como la seda no tardaron demasiado tiempo en aparecer los primeros problemas. Yo evidentemente uso Eclipse, como mucha otra gente, para programar en Java, pero no es en lo único que programo. Ni corto ni perezoso intenté descargar los paquetes que hacen que Eclipse hable Java y… PEEEKKK! Error.. ¿Cómo? ¿Esto que eeessss? Bueno, pues vamos a intentar ponerlo en “Cristiano” (por defecto sale en inglés) con el paquete Babel del repositorio para Eclipse Indigo.. PEEEKKK!!! Su put……e!!!

Finalmente mi memoria hizo lo que tenía que hacer, recordar que usar el paquete hecho para Ubuntu no iba a servir así queeee.. como hace  3 años.

Pasos a seguir:

  • Descargar el paquete para tu versión de Linux (Es un TGZ) de la página Oficial de Eclipse. Hay muchos paquetes, con descargar el Eclipse Classic será suficiente: 179Mb.
  • Descomprimimos el archivo y ejecutamos Eclipse.
  • Ahora sí, si nos vamos al menú Help->Install New Software ya podemos instalar cosas. Lo primero de todo es dentro del repositorio de Indigo buscar dentro de Programming Languages a PHP y tooooodo lo que nos haga falta e instalarlo.
  • Lo siguiente es añadir al repositorio la dirección https://download.eclipse.org/technology/babel/update-site/R0.9.1/indigo
  • Al hacer esto último podremos instalar los paquetes de idiomas del “Proyecto Babel”. Buscamos el correspondiente a Spanish y lo instalamos, con lo que en el siguiente reinicio del programa nuestro Eclipse aparecerá en un lenguaje que seguramente entenderemos mejor

Poco más. ¡A disfrutar de Eclipse en Ubuntu!

 

 

La vida es más sencilla con TinyMCE

Como muchos de vosotros sabréis trabajo como Administrador de Sistemas en una empresa que tiene entre otra cosas un periódico. Hace unos meses me dijeron algo así: “¿Por qué no podemos poner en los artículos de la web cursiva, negrita y colores?”. En aquel entonces sabía que existían algunas librerías y plugins que permitían hacer eso, pero para colmo de males en aquel entonces no tenía el más mínimo tiempo libre para estar haciendo experimentos… hasta hoy.

Después de investigar un rato y haber encontrado varios editores tipo “lo_que_ves_es_lo_que_obtienes” para poner dentro de una cajita en un script HTML o PHP seguía sin haber nada que me hiciera exclamar bien alto ¡GUAUUU!.. hasta que encontré TinyMCE. Vaya si grité ¡¡GUAUUU!! pero no porque la librería fuera enorme o impresionante; ¡es que es minúscula! Como su propio nombre dice, Tiny significa pequeñajo en inglés, y es lo que os vais a encontrar: una librería pequeña pero tremendamente eficiente que os permitirá convertir las cajas tipo TextArea de una página HTML en auténticos procesadores de texto que guardarán el texto insertado en código HTML listo para ser usado, con sus colores, negritas, etc etc… ¿Y qué se necesita? Poca cosa, tener activado JavaScript.

Lo primero que hay que hacer para tener esta maravilla funcionando es descargársela de www.tinymce.com. Veréis que hay varias versiones, una incluso para ser usada desde JQuery, pero no es nuestro caso, así que diréctamente coged la versión más nueva que haya y que no diga cosas raras. Lo siguiente es descomprimir el archivo (puede venir en zip o tgz) y subir el directorio tinymce que encontraréis a vuestro espacio web. Tras eso cread un documento en HTML como el siguiente y subidlo..

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "https://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> <html xmlns="https://www.w3.org/1999/xhtml" dir="ltr"> <head> <title>TinyMCE Test</title> <meta http-equiv="content-type" content="text/html; charset=utf-8"/>  <script type="text/javascript" src="tiny_mce/tiny_mce.js"> </script>  <script type="text/javascript">  tinyMCE.init({  mode : "textareas" });  </script> </head> <body>  <textarea name="content" cols="50" rows="15">Esta sera la cajita editora</textarea&gt </body>  </html> 

Abrid el navegador y apuntar a la dirección donde habeis subido el archivo y vereis una fantástica cajita con botones para editar texto como por ejemplo poner en negrita, itálica, etc… Y lo mejor de todo es que el texto que genera es completamente html, con sus código de color CSS incluídos. Una maravilla…

Life is easier with TinyMCE

As you all probably know I work as a System Administrator on a company that has a newspaper. Several months ago somebody asked something like: “When will we have on the web a system to put bold, italic and colours inside the articles?” I knew there were libraries and plugins to do that, but until today  I din’t have the time to make such experiments… However, the day has arrived..

After “webing” a little I found a couple of “wysiwyg html editor” to put inside an HTML/PHP document, but nothing that made me say “WOWWW!!” until I found TinyMCE… yes, I said “WOOW!” but not because it’s great but because it’s tiny!!! Yes, as its own name says this little, tiny, ridiculous library permits yourself to convert an HTML TextArea on a fully wordprocessor… What do you need? JavaScript!! Nothing more.. so let’s activate some “boxes” with editors inside…

First of all, go to www.tinymce.com and download the package. As you can see there are several versions, even one which works fine using JQuery over it, but this is not the case. Upack the archive and upload the content of the tinymce directory inside your web folder. After that create an html document and put this inside it…

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "https://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> <html xmlns="https://www.w3.org/1999/xhtml" dir="ltr"> <head> <title>TinyMCE Test</title> <meta http-equiv="content-type" content="text/html; charset=utf-8"/>  <script type="text/javascript" src="tiny_mce/tiny_mce.js"> </script>  <script type="text/javascript">  tinyMCE.init({         mode : "textareas" });  </script> </head> <body>     <textarea name="content" cols="50" rows="15">This will be inside your box.</textarea&gt </body>  </html> 

Go to your browser and point where your document is saved and… yes! you’ll see a wonderfull “textarea box” where you can put your text in bold style and many things more…

Downloading from FTP servers in Java

Some months ago I needed a program which did the following:

– Connectsto an FTP host

– Check everything inside the remote folder

– Download all the files

– Delete all the files

– Wait a minute until the next connection

I found a very tiny program which did it ok but it has a problem, it’s always hanging and the information I had to receive was not properly updated, so I took the decision to make myself a program to do the same. The decision of using Java as the programming language was easy, but my Java skills were not as good as a year ago.

Luckily I found a great class called JvFTP (Yes! You have guessed: Java FTP) that works. After some tries this was the result:

import cz.dhl.io.*;
import cz.dhl.ftp.*;

import java.io.FileOutputStream;
import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public class FTPClass {
    public static final int    BUFFER_SIZE = 10240;
    
    public static void ftpdownload(String host, String user, String pass) {
        /*
         * Creates the connection to the FTP Server using the given parameters
         */
        FtpConnect cn = FtpConnect.newConnect(“ftp://” + host);
        cn.setUserName(user);
        cn.setPassWord(pass);
        Ftp cl = new Ftp();

        try {
            /*
             * Connects to the host
             */
            cl.connect(cn);

            /*
             * Gets current path
             */
            CoFile dir = new FtpFile(cl.pwd(), cl);

            /*
             * Gets the list of files inside the directory
             */
            CoFile fls[] = dir.listCoFiles();
            if (fls != null)
                for (int n = 0; n < fls.length; n++) {
                    /*
                     * Prints the name of the file. If it’s a directory it’ll be discarded
                     */
                    System.out.println(
                        fls[n].getName() + (fls[n].isDirectory() ? “/” : “”));
                    String pathFile = fls[n].getName() + (fls[n].isDirectory() ? “/” : “”);
                    /*
                     * Creates the InputStream from the FTP connection
                     */
                    FtpFile file = new FtpFile(pathFile, cl);              
                    InputStream in = file.getInputStream();
                    /*
                     * Creates the OutputStream to the file in the local disk
                     */
                    OutputStream out= new FileOutputStream(fls[n].getName());
                    byte[] buffer= new byte[BUFFER_SIZE];
                    /*
                     * Reads and writes…
                     */
                    while (true) {
                      int k= in.read(buffer);
                      if (k < 0)
                        break;
                      out.write(buffer, 0, k);
                    }
                    in.close();
                    out.close();
                }
            
        } catch (IOException e) {
            System.out.println(e);
        } finally { /* disconnect from server
              * this must be always run */
            cl.disconnect();
        }
    }
    public static void main(String args[]) {
        ftpdownload(“myhost”, “myuser”, “mypass”);
    }
}

Webs compatibles con SmartPhones

Los smartphones, sí esos cacharritos que aunque han credido en tamaño siguen siendo móviles, están cada día más presentes en nuestras vidas. El parque de este tipo de terminales ha crecido como la espuma después de que Apple con su famoso iPhone y RIM con Blackberry empezaran a acaparar el mercado gracias a terminales cada vez más asequibles y que “nos hacen la vida más fácil”. Atrás quedó la hegemonía de marcas como Nokia a la que nadie parecía poder toserle en la cara y el desplome absoluto de otras marcas que ya parecían estar casi moribundas como Motorola.

El nuevo concepto de teléfono móvil del siglo XXI no se parece en nada a los de principios de siglo. Recordad que solo han pasado 12 años desde que en el año 2000 solo la mitad de la población española tenía un terminal móvil y que los que lo tenían alucinaban con terminales que hacen “pipipipipopo” como tomo de llamadas con pantallas minúsculas monocromáticas. Marcas como Alcatel, Nokia y Ericsson (antes de ser Sony-Ericsson) eran las que mandaban. ¿Y tanto ha cambiado la cosa en 12 años? Y tanto… los terminales empezaron a empequeñecerse. La moda era que cuanto más pequeño era el teléfono, más “portátil” era y por lo tanto “más chic”, hasta que RIM sacó su primera Blackberry y poco tiempo después Apple le puso las cosas duras con el primer iPhone.

De “navegar”, y lo pongo entre comillas porque aquello más que navegar era una broma, usando la tecnología WAP en los primeros móviles con GPRS, amén de los sablazos que metían las compañías en aquel entonces por usar transmisión de datos por la red GSM, hasta los primeros navegadores que traían las blackberrys, que se parecían más al Lynx de Unix/Linux que otra cosa hemos llegado a terminales como los de hoy en día, que poco tienen que envidiar a los de sus hermanos mayores en los ordenadores de sobremesa. En los terminales con Android podemos instalar Firefox. Apple diréctamente hizo una versión de Safari para su terminal (El navegador que llevan por defecto los Macs y que también está para Windows). Sin embargo todavía hoy en día existe un “pequeño problema”. La pantalla.. No podemos comparar una pantalla de un móvil que por lo normal suele trabajar a 320 o 480 pixels de ancho con una de un ordenador que empieza a moverse medio bien a 1024 y más teniendo en cuenta que la resolución más estándar en nuestros días es tener 1280 pixels de ancho en casi todas las resoluciones de monitor, ya sean en 4:3 o en 16:9.

Para poder hacer una aplicación que sea 100% compatible con un smartphone móvil tenemos varias opciones:

  • Primera: Pasar ligeramente de todo y hacer una web que se muestre bien pero que haya que estar haciendo zoom (típico gesto de los usuarios de iPhone con los deditos para ampliar o alejar la pantalla)
  • Segunda: Hacer una rutina en JavaScript o PHP/ASP/Ruby/… que detecte qué tipo de terminal tenemos y nos redirija a una versión para móviles de la web en cuestión. Esto es bastante típico hoy en día en periódicos online.
  • Tercero: Hacer una versión híbrida que detecte el móvil y “adapte” la web, normalmente mediante JavaScript, para que salga corréctamente con la resolución de un smartphone. Esto puede ser por ejemplo quitar div’s laterales tipo menús, o información que se pueda colocar en otro lado de la pantalla y que de esta forma el texto no se desplac

Sea cual sea la versión que escojamos está claro que lo suyo es la segunda o tercera opción. Muchos usuarios lo agradecerán. Por mi parte las primeras pruebas las estoy haciendo con la segunda, más que nada porque me permite aprender de una forma más ordenada y cuando ya esté todo avanzado quizás una tercera versión nos ahorrará reescribir código innecesario. Sin embargo, como lo primero es aprender allá vamos.

Primeramente habrá que detectar que estamos usando un móvil, ¿cómo? He aquí las diferentes variantes:

JavaScript:

Se podría mejorar, pero por lo normal nos interesará saber, mediante la propiedad navigator.userAgent el tipo de navegador que está usando. En dicha propiedad con buscar iphone, android, o lo que nos interese sería suficiente para detectar al smartphone. El siguiente código es una buena prueba de ello:

<script type=”text/javascript”>
var navegador = navigator.userAgent.toLowerCase();
if( navegador.search(/iphone|ipod|android/) > -1 ){
document.location = ‘https://miversionparamoviles.com’;
}
</script>

Evidentemente la búsqueda en userAgent podemos extenderla más usando palabras como blackberry,palm, etc…

PHP:

if (eregi( ‘ipod|iphone|android|opera mini|blackberry|palm os|windows ce’, $_SERVER[‘HTTP_USER_AGENT’] )) {

código aquí….

}

Ya sabemos cómo detectar que usamos un móvil, ahora prepararemos nuestra web:

Las webs para SmartPhones suelen estar preparadas según XHTML, sin embargo por lo normal suelen trabajar bien en cualquier tipo de código que sea estándard a W3C. Sin embargo para evitar problemas de compatibilidad prepararemos nuestro DOCTYPE según dicho acuerdo. Para comenzar nuestra cabecera se debe de preparar de la siguiente manera:

<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “https://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”>
<html xmlns=”https://www.w3.org/1999/xhtml” id=”v1.06″ xml:lang=”es” lang=”es”>

Esto evitará más de un susto a más de uno. Ahora viene lo realmente interesante. Queremos que sea 100% compatible con smartphones. Lo primero de todo es evitar que se pueda hacer zoom y cosas raras que los usuarios suelen hacer cuando no se ve bien una web porque o salen las letras muy pequeñas o todo lo contrario. ¡Por supuesto contamos con que haremos las pruebas en un smartphone a medida que vayamos haciendo nuestro proyecto! Toda esta magia la hace el llamado ViewPort. ViewPort es una propiedad que pasaremos a través de un METATAG al navegador y al mismo tiempo también define la visión que va a tener el smartphone. Llamamos viewport a la parte visual que tiene la pantalla del smartphone. De momento para mis pruebas he utilizado el siguiente:

<meta name=”viewport” content=”width=device-width, initial-scale=1, maximum-scale=1″ />

Esta línea modifica el viewport del smartphone y le indica que se ajuste en forma vertical a la resolución de nuestro smartphone y al msimo tiempo que la escala de visualización sea 1. Esto es importante porque imaginaos que haceis una aplicación web y que en un iPhone se ve de maravilla pero que en una Blackberry se viera realmente pequeña. Con “tocar” estos valores, poniendo el valor initial-scale a otro mayor ampliaríamos la visión del viewport, por poner un ejemplo, aunque se puede hacer de muchas otras maneras.

Sigamos…

<meta content=”text/html; charset=UTF-8″ http-equiv=”content-type” />
<meta http-equiv=”cache-control” content=”no-cache” />
<meta http-equiv=”cache-control” content=”no-store” />
<meta http-equiv=”cache-control” content=”max-age=0″ />
<meta http-equiv=”cache-control” content=”must-revalidate” />

Estos meta son realmente interesantes. El que no hay que olvidar nunca poner es que indica el content-type. Los navegadores para SmartPhones trabajan en codificación UTF-8. Algunos son compatibles con el estándar ISO-8859-1 que usamos en España, pero es mejor no arriesgar. Los siguientes indican que no se utilice caché, de esta forma evitaremos problemas a la hora de recargar la página ya que a fin de cuentas un smartphone NO ES UN ORDENADOR.

y finalmente ya podemos empezar con nuestro código..

<body> Blabvlablablablbll </body>

Hay que tener cuidado en no usar cosas especialmente raras, por ejemplo, las tablas de las que se ha abusado tanto en el pasado para maquetar corréctamente las webs tienen poco sentido gracias a los bloques (divs) de los que se disponen de hoy en día.

Se pueden usar CSS sin ningún tipo de problema, al menos los que yo he probado, pero hay que intentar no usar propiedades demasiado nuevas o “extrañas” que sean útiles en navegadores modernos para hacer algún truco poco documentado.

La recompensa de hacer las cosas bien

En anteriores posts he dejado patente mi gran agrado en el uso de la orientación a objetos y el que debido a las locuras que ocurren cuando uno trabaja bajo un enorme stress se llegan a hacer auténticos disparates para llegar a tiempo.

Por suerte para mí por fin he conseguido entregar un proyecto que está realizado 100% en OOP y que utiliza mi queridísimo lenguaje PHP5. Las mejoras no se han hecho esperar. Tras presentar esta mañana el proyecto en cuestión se me han pedido hacer una serie de cambios/mejoras a nivel de funcionamiento (filtros en los informes, algún que otro botón adicional, etc..). Por suerte para mí el haber realizado todo en base a objetos me ha permitido que para hacer estos cambios solo hubiera que abrir la clase en cuestión de la que depende el formulario, y “toquetear” el código del que depende.

Está claro en que de aquí en adelante el futuro va en esta línea. A veces vale la pena perder un poco de tiempo en definir corréctamente las clases, métodos y variables privadas, y sobretodo el definir bien los métodos de acceso con nomenclatura adecuada. Ahorraremos muchísimo código, reutilizaremos nuestras rutinas un disparate, pero sobretodo es importantísimo, y más que nunca, el análisis previo al desarrollo para poder crear todo de una forma coherente.

Clases y objetos en PHP5. Flexibilidad para el programador

Desde prácticamente mis tiempos universitarios he sido un fiel seguidor de las tendencias en lo que a programación orientada a objetos se refiere, sin embargo, debido a mis labores como currante perdí el hilo durante unos años y cuando de nuevo me tuve que poner a programar después de todos estos años dedicándome únicamente a a la administración de sistemas me encontré con que mi cabeza estaba oxidada en cuanto a los buen haceres de una programación bien estructurada, por no hablar de la correcta utilización de los patrones de la programación orientada a objetos. El resultado podía haber sido peor de lo que yo me hubiera imaginado. Mis scripts en PHP realmente funcionaban bien (utilizaba el estándard PHP4 aunque ya corría PHP5 en mis servidores) pero la estructura interna de los mismos era de ese tipo que cuando un programador medianamente experimentado los ve se hubeira caído de espaldas del susto.

En fin, para los siguientes proyectos intenté organizarme mejor y la verdad es que todo empezó de maravilla hasta que lo de siempre, la fecha objetivo se acercaba y el sprint final hace que tengas que tomar una decisión salomónica, sacrificar la estructura y buen hacer en detrimento de acabar el proyecto “como sea”. Sin embargo por fin las cosas han cambiado, y he conseguido empezar a hacer un proyecto desde el principio utilizando clases y objetos en PHP para la casi totalidad de mis scripts y sinceramente ¡¡qué gozada!! Tras ver cómo van evolucionando mis clases y objetos, y sobretodo que interrelacionan entre sí en un código limpio y de fácil comprensión me pregunto, ¿pero cómo es posible que te pase siempre lo mismo?

Bromas a parte, a continuación os muestro un par de ejemplos de cómo crear objetos y clases en PHP5, que PHP5 incluso permite crear clases estáticas y llamarlas desde cualquier parte del programa. En fin… que después de ver esto me pregunto ¿realmente hace falta Java/JSP para crear webs dinámicas existiendo PHP5? ¿¿¿Cómo es posible que haya aún gente que se interese por ASP/ASPX???

Ejemplo de una clase en PHP:

class miClase {
private $miVariable;
function __construct($param) { /* el constructor en PHP5 se define como __construct */
$this->setVariable($param);
}
function setVariable($param) {
$miVariable = $param;
}
function getVariable() {
return $miVariable;
}
}

Ya tenemos creada una fantástica clase donde guardaremos, y de forma privada, un atributo (variable) que será accedido mediante los métodos que sí que serán públicos. Con esto conseguimos cumplir una de las premisas de la programación orientada a objetos, la encapsulación.

¿Y se puede hacer herencia? Y tanto…

class miOtraClase extends miClase {
function otraFuncion() {
print “Esto se imprime desde otra funcion”;
}
}

¿¿Y cómo creamos objetos?? Tan sencillo como esto…

$miObjeto = new miClase(“Pepito”);
echo $miObjeto->getVariable();
$miObjeto->setVariable(“Joselito”);
echo $miObjeto->getVariable();
$miOtroObjeto = new miOtraClase(“Pepote”);
echo $miOtroObjeto->getVariable();
$miOtroObjeto->otraFuncion();

Y el resultado sería…

Pepito
Joselito
Pepote
Esto se imprime desde otra funcion

Evidentemente este es un ejemplo sencillísimo, pero en cuatro líneas como se suele decir se puede ver que a este lenguaje no le hace falta ¡¡de nada!!