Archivo de la categoría: Programación

La importancia de la web multilingüe

Debemos admitirlo: no estamos solos. En una época en la que viajes, noticias, economía y las culturas de todo el mundo están tan interrelacionadas, no podemos ignorar el hecho de que Internet también es un medio global, intercultural y sí, multilingüe.

Dicho brevemente: ni España es el centro del mundo, ni el español es el único idioma hablado. Por eso, a estas alturas de la globalización, se hace indispensable contar con páginas web que “hablen” a los usuarios en su propio idioma. Pero, ¿por qué se hace tan necesario? Veamos algunas razones:

  • Imagen: una web disponible en varios idiomas es un “guiño” al usuario; demuestra interés y concienciación por las necesidades de nuestros usuarios. Esto se hace, si cabe, más importante en páginas de comercio electrónico.
  • Mayor difusión y alcance de la información: una web en español puede llegar a, aproximadamente, 500 millones de personas (precisamente esta difusión del español hace que seamos “perezosos” a la hora de pensar en otros idiomas). Si además añadimos el inglés a nuestra web, abarcamos a otros 600 millones más (nos referimos a personas que tienen estos idiomas como primera o segunda lengua). Finalmente, con idiomas como el francés y el portugués podríamos llegar hasta los 700 millones de hablantes. En resumen:  4 idiomas en nuestra web permiten el acceso a 1.800 millones de habitantes, ¡y esto son 1.800 millones de posibles clientes!
  • Amortización de la inversión: el incremento de precio de una web multilingüe es pequeño, y a efectos reales es como tener varias páginas totalmente diferentes.
  • Posicionamiento en buscadores: más idiomas significa más contenidos, y por tanto los buscadores asignarán mejores puntuaciones a nuestra web.

Bien, supongamos que ya estamos decididos a hacer una web multilingüe. ¿Qué debemos tener en cuenta?

  • La web presenta diversos idiomas, no países. Salvo contadas excepciones, no se recomienda poner banderas indicando los idiomas disponibles (el español no sólo se habla en España, ni el inglés en el Reino Unido). Entre las excepciones están:  idiomas minoritarios que se hablen en un solo país, localizaciones específicas por países (Venezuela, Argentina, México, Perú, España…).
  • Los idiomas representan culturas. Esto implica que deben cuidarse ciertas expresiones que no tienen traducción, distribución de los contenidos… por poner un ejemplo extremo para entenderlo: los países de cultura árabe tienen mentalidades muy distintas a la nuestra, y debe cuidarse.
  • Distintos idiomas, generalmente, presentan distintas monedas. Si nuestra web es de comercio electrónico, haremos bien en facilitar la conversión a la moneda local del usuario (habitualmente, con euros y dólares americanos abarcaremos el mayor número de usuarios).

Como en todo, es importante el equilibrio: no merece la pena incluir una traducción al Xhosa a menos que las perspectivas de usuarios de este grupo lingüístico sean importantes.

En resumen, la próxima vez que debas hacer una web, pregúntate: ¿debo considerar la posibilidad de incluir, al menos, un par de idiomas más? Seguramente la respuesta sea afirmativa en la mayoría de los casos.

Nueva versión de jQuery User Interface

Admito que desde que descubrí jQuery veo programar con JavaScript con otros ojos. ¿Y qué es jQuery? De forma resumida: es un conjunto de librerías diseñadas para facilitar la programación con JavaScript.

Presenta muchas ventajas, entre ellas:

  • Cross-Browser: facilita la creación de código compatible con todos los navegadores.
  • Ligero: apenas ocupa 19kb, y ofrece un gran número de funciones muy útiles en el día a día del programador (AJAX, animaciones, ocultar y mostrar elementos, validación, efectos gráficos)…
  • Sencillo y bien documentado: es increiblemente fácil de aprender, y tan sencillo de manejar que tras 15 minutos de usarlo ya te sientes cómodo con él.
  • Extensible: mediante plugins, encuentras de todo (galerías de imágenes, efectos, transiciones, etc.).

Pero recientemente se ha lanzado una “extensión” de jQuery: se llama jQuer User Interface y, como su nombre en inglés indica, permite crear de forma sencilla componentes gráficos de interacción con el usuario.

Por ejemplo:

  • Pestañas
  • Acordeón
  • Selección de fecha con calendario
  • Ventanas de diálogo (incluidas modales). Este punto me gusta especialmente: ¡por fin una solución decente a una necesidad tan básica! Se acabaron los alert y confirm.
  • Barras de progreso.
  • Y un sinfín de posibilidades.

Te animo a que le dés un vistazo. Merece la pena. De momento, ya planeamos usarlo de forma extensa (pero con cabeza, no merece la pena recargar la web con estos efectos) para nuestro próximo gran proyecto: la Tienda Virtual 3.0 de SGM Sistemas.

Descarga (gratuita), documentación y ejemplos: página oficial de jQuery y jQuery UI.

Flash vs. HTML

Es posible que, al leer el título, muchos esperen una respuesta definitiva y categórica, similar a: “X” es mejor. Lamento decepcionarte si esperabas esto…

¿Por qué? Bueno, de forma resumida, en términos generales ninguna tecnología es mejor que otra. Ambas tienen sus puntos fuertes y sus puntos débiles. Veamos.

HTML es un lenguaje de marcado de etiquetas. Es decir, el texto se formatea mediante marcas especiales que lo distinguen. Por ejemplo:

<strong>Esto es un párrafo en negrita</strong>

Presentaría el texto más grueso, en negrita. Nótense las etiquetas <strong> y </strong> que engloban el texto.

Flash, por el contrario, es un conjunto de herramientas y tecnologías que trabajan usando fotogramas, similar a una película de cine.

Siendo realistas, no es justa la comparación Flash vs. HTML. ¿Por qué? Básicamente, HTML es un lenguaje antiguo y muy limitado; tanto que hoy en día no existe ninguna página realizada exclusivamente en HTML.

Pero, ¿no es cierto que todo lo que vemos en Internet es HTML?

En cierto modo, sí y no. Veamos: cualquier página web moderna usa un conjunto de lenguajes complementarios al HTML, por ejemplo CSS, JavaScript y, opcionalmente, un lenguaje de servidor como PHP (o ASP), incluso enlazado a una base de datos.

Por eso decimos que la comparación Flash vs. HTML no es justa, ya que hoy en día es imposible concebir HTML sin todos sus “anexos”.

Por tanto, la pregunta se convierte en: ¿qué es mejor? ¿Flash, o HTML + CSS + JavaScript? La respuesta, en mi opinión, es: nunca hagas un sitio web completo en Flash.

Hay gente que opina de forma distinta (afortunadamente) y consigue realizar sitios web asombrosos en Flash (véase este ejemplo). Son animaciones gigantescas, muy elaboradas gráficamente y muy costosas.

Pero, ¿qué sucederá si necesitas hacer tu web en varios idiomas? Generalmente, en Flash hay que duplicar todos los archivos y modificarlos en el nuevo idioma… una labor colosal.

Pongamos ahora este otro ejemplo: la nueva web de L’Antic Colonial (desarrollo en el que he participado recientemente, en la empresa de Diseño Web SGM Sistemas). Destacamos lo más importante: categorías y colecciones (menú lateral) administrables. Productos y ambientes administrables. Noticias, descargas, novedades, área de usuarios… y un larguísimo etcétera. ¿Imaginas hacer todo esto en Flash? Podría hacerse, obviamente, pero sería mucho más caro y difícil.

Si te fijas, en la portada hay una animación en Flash, con varias imágenes alternando. Para eso se concibió Flash, para hacer animaciones. Y un sitio web completo no es, al menos no debería ser, una animación.

En resumen:

Lo bueno de Flash:

  • Posibilidad de crear animaciones espectaculares.
  • Gran integración con otras herramientas de Adobe (como Photoshop).

Lo malo de Flash:

  • Carente de accesibilidad (aunque están mejorando en ello): historial, favoritos, navegación por voz…
  • Te vincula a una herramienta cerrada, y cara: Adobe Flash.
  • Dificultades para vincular con bases de datos (generalmente se usa un lenguaje intermedio, XML, para poder leer los datos).
  • Más pesado = más tiempo de carga.
  • Más costoso (en tiempo y dinero).

Lo bueno del HTML:

  • Ligero y rápido.
  • Lenguajes auxiliares muy completos: CSS, JavaScript, PHP/ASP/JSP, conexión a bases de datos…
  • Estándar, accesible, abierto, gratuito.
  • Funciona en multitud de plataformas, sistemas operativos, navegadores, dispositivos móviles…
  • Versatilidad: puedes hacer lo que quieras.

Lo malo del HTML:

  • Necesita de otras tecnologías (ya mencionadas) para que sea medianamente decente.

Para mí, la mejor combinación para realizar una aplicación web de calidad es:

HTML para mostrar en el navegador.
CSS para el estilo de la web.
PHP para añadir programación del servidor (usando el fabuloso framework CodeIgniter).
JavaScript para la programación del cliente (con la magnífica librería jQuery para simplificar la tarea).

Dominando estas tecnologías, puedes olvidarte por completo de Flash.

Usando CodeIgniter en un proyecto real

Recientemente en la empresa para la que trabajo (Sistemas Globales Multimeda, también conocida como SGM Sistemas) se nos planteó un presupuesto, cuanto menos, atractivo e interesante. Tras muchas deliberaciones en torno a qué lenguaje utilizar (ASP o PHP), finalmente nos inclinamos por éste último por varias razones:

  • Mayor cantidad de herramientas disponibles (Eclipse frente a Dreamweaver; MySQL frente a SQL Server; MySQL Workbench para el diseño de la base de datos, PHPMyAdmin y un servidor con Plesk).
  • Más componentes disponibles y a un precio más asequibles (cuando no gratuitos).
  • Mejor separación entre el código y el diseño.

Nuestro equipo de trabajo había tenido de forma reciente buenas experiencias con PHP, logrando reducir los tiempos de desarrollo y aumentando sensiblemente la calidad y reusabilidad de las aplicaciones realizadas.

El proyecto constaba de las siguientes áreas:

  • Extranet con posibilidad de intercambio de documentos.
  • Notificación de disponibilidad de documentos, y de lectura de los mismos vía e-mail.
  • Gestor de contenidos basado en plantillas predefinidas.
  • Gestión de descargas, noticias y galerías.

No es uno de los mayores proyectos a los que nos hemos enfrentado; no obstante, dada la importancia del cliente (una institución pública) el resultado debía ser óptimo, bien probado y en un marco de seguridad importante.

Tras barajar las posibilidades disponibles (utilizar un framework o programar con PHP puro), nos decantamos por el uso de CodeIgniter, por las siguientes razones:

Razones para el uso de un marco de trabajo (framework) frente a desarrollar la aplicación desde cero con PHP:

  1. La seguridad debía ser un factor clave: datos introducidos por el usuario debidamente validados y filtrados para evitar ataques XSS.
  2. Comunicación con Base de Datos (MySQL) automatizada, validando todas las consultas y filtrando los datos variables para evitar inyección SQL.
  3. Disponer de componentes plenamente probados, con el objetivo de mejorar la productividad.

Razones para el uso de CodeIgniter frente a otros marcos de trabajo:

  1. Amplia documentación disponible.
  2. Ligero, y sin instalación (para comenzar a desarrollar una aplicación basta con copiar los archivos, y ponerse a trabajar).
  3. Compatibilidad con una amplia variedad de servidores y configuraciones (la aplicación se concebiría para ejecutarse en un hosting compartido con otros clientes, y con relativamente poca posibilidad de configuración).
  4. Flexibilidad, ya que no obliga a tener una determinada estructura de tablas, nombres de campos, ni adherirse a una forma de programar concreta.

Entre las desventajas y dificultades con las que nos encontramos durante el desarrollo del proyecto están:

  • Curva de aprendizaje: necesidad de aprender nuevas funciones, estructuras y métodos de programación.
  • Dificultad para adaptar el código escrito en PHP tradicional (nuestra empresa contaba con una administración escrita en PHP puro, con listados, formularios, subida de archivos, etc.). No disponíamos de tiempo para comenzar de cero, por lo que se optó por adaptar el existente a la nueva filosofía. Esto no debería representar mucha dificultad para un programador avanzado, con experiencia en desarrollo de proyectos de complejidad media.

A medida que avanza el desarrollo de la aplicación (aún está en fase de desarrollo) hemos solventado todas estas dificultades, resultando un proyecto muy interesante, de gran calidad y fácilmente reutilizable. La adaptación de los componentes ya desarrollados no conllevó serios problemas (eso sí, manual de CodeIgniter en mano) y el resultado está siendo más que satisfactorio.

No obstante, al ser este el primer proyecto serio en el que empleamos CodeIgniter no podemos hacer una valoración de la facilidad o dificultad de las futuras modificaciones. No obstante, por la forma de estructurar la aplicación y los archivos suponemos no entrañará mayor dificultad.

Proyecto con CodeIgniter

Proyecto con CodeIgniter

Comunidad CodeIgniter en español

Ya está en marcha el blog de la comunidad CodeIgniter en español. Un lugar donde se recogen las experiencias y colaboración de todos los desarrolladores que usan CodeIgniter en sus proyectos.

La dirección es: http://comunidadcodeigniter.wordpress.com

¡Todo el que lo desee puede participar con sus comentarios!

Modelo Vista Controlador

Es inevitable comenzar una discusión entre programadores cuando se habla de lenguajes de programación. Ya no sólo que cada uno tiene sus preferencias personales, costumbres e ideas; finalmente se termina discutiendo acerca de Programación Web y Programación de Escritorio.

Como es lógico, cada uno tiene sus ventajas e inconvenientes. No obstante, la programación de escritorio siempre ha sido más “tradicional”. Programación por un lado, diseño de interfaz por otro…

Al analizar los lenguajes de programación web nos damos cuenta que, desde el mismo comienzo, las cosas son distintas. ¿Por qué?

De forma sencilla: el resultado tiene que ser HTML (hablando de forma general). Sin embargo, HTML no es un lenguaje de programación propiamente dicho, y los servidores no entienden HTML.

Debido a lo mencionado anteriormente, se hace necesario utilizar un lenguaje que sí entienda el servidor (léase ASP, JSP, PHP, Perl, Ruby, y un larguísimo etcétera). Esto conlleva una serie de inconvenientes, como la necesidad de aprender varios lenguajes de programación para conseguir un resultado (HTML + Lenguaje de servidor + JavaScript, habitualmente) o la imposibilidad de depurar de forma eficiente la aplicación, salvo probando el resultado (o la salida) de la misma.

Sin embargo, posiblemente el peor de todos esos inconvenientes es la excesiva tendencia a mezclar HTML con lenguaje de servidor.

Es decir, con muchísima frecuencia se ve esto (ejemplo en ASP):
<% while not rs.Eof %>
<tr>
<td>Nombre:</td>
<td><%= rs("Nombre") %></td>

</tr>
<% wend %>

Y es un serio problema… especialmente cuando quieres cambiar el diseño (en aplicaciones que deben ser reutilizadas frecuentemente), o cuando el diseñador/maquetador no conoce el lenguaje de programación utilizado.

¿Cómo solucionar, o al menos evitar en parte, este problema?

Bueno, cabe decir que es completamente imposible aislar por completo la presentación de la programación, por el simple hecho de que la presentación debe generarse desde el servidor.

Aunque hay soluciones como usar plantillas (la lógica no se crea mediante un lenguaje de programación, sino un “pseudolenguaje” de plantillas, lo que a fin de cuentas viene a ser lo mismo), actualmente se tiende a utilizar un sistema que aisla en diferentes capas la programación y el diseño: el Model Vista Controlador.

¿En qué consiste esta filosofía, denominada comúnmente MVC?

Pues bien, básicamente hay tres capas en la aplicación:

  • Modelo: capa que realiza todas las tareas de comunicación con la base de datos, como ejecución de consultas, generación de recordsets y tablas, etc.
  • Controlador: recibe las peticiones y decide qué se mostrará y cuándo. Si tenemos un área de “Productos” y otra de “Servicios”, cada una de ellas tendrá su controlador. Puede existir que un controlador rija todas las operaciones (por ejemplo “productos/ver”, “productos/listado”, “productos/borrar”).
  • Vista: al recibir la petición del controlador decide cómo se mostrará la información suministrada por el controlador. Es decir: la presentación del contenido.

¿Qué ventajas presenta este modelo?

Pues bien, al separar la presentación de la programación (o lógica de negocio), la aplicación es más fácil de modificar en el futuro (si intentas vender esto a tus superiores deberás decir que “la aplicación es más escalable” y “puede mantenerse mejor”); el resultado es más claro, y el reparto de tareas dentro del equipo de trabajo es más fácil; la depuración de la aplicación es más sencilla y, finalmente, puede utilizarse un marco de trabajo (o framework) bien testeado.

¿Presenta inconvenientes, o es todo tan bonito como dices?

Si decides utilizar un framework, evalúalo muy bien antes de comenzar, ya que su complejidad puede afectar (positiva o negativamente) al tiempo de desarrollo del proyecto.

Es necesario invertir tiempo en crear un modelo (si decides programarlo tú mismo) o leer la documentación y comprender lo que ya está hecho (si decides utilizar un framework ya creado).

No obstante, el mayor inconveniente puede ser el cambio de mentalidad de los distintos componentes del equipo, ya que se abandona la técnica tradicional de programación “pagina A -> pagina B -> pagina C”; muchos serán reacios a cambiar su forma de trabajar y posiblemente tendrán de su lado a los directivos, que no suelen querer “arriesgar” o “innovar” (salvo algunas afortunadas excepciones).

En resumen:

  • El Modelo Vista Controlador (MVC) separa la lógica de la aplicación y la presentación en varias capas.
  • Facilita la labor de todo el equipo: diseñadores gráficos, programadores, diseñadores de base de datos y.
  • Existen marcos de trabajo ya programados (según en lenguaje de programación hay más o menos posibilidades) que facilitarán el trabajo de los miembros del equipo de trabajo.

Aplicaciones basadas en CodeIgniter

A continuación presentamos una lista de aplicaciones desarrolladas con CodeIgniter. Está en permanente actualización, así que sentíos libres de hacer vuestras contribuciones y sugerencias.

Bamboo Invoice

Sistema de facturación on-line, libre y multiidioma.

http://bambooinvoice.org/

68kb

Sistema para crear “bases de conocimiento”, dedicados a reunir documentación sobre un tema específico. Es ideal para colectivos de profesionales que necesitan estar al día con las novedades en su profesión.

http://68kb.com/

Open Blog

Sencillo y completo blog hecho íntegramente con CodeIgniter. Tiene soporte multiidioma, varias plantillas predefinidas (con la posibilidad de crear nuevas) y todo lo que se puede esperar de un blog decente.

http://www.open-blog.info

CodeIgniter: simplificando la programación en PHP

A la hora de desarrollar proyectos web de complejidad media nos enfrentamos a diversos problemas que pueden hacer que un proyecto que parecía interesante pase a ser un infierno de código.

Frecuentemente los escasos plazos, presupuestos ajustados y presiones por parte de los superiores (a menudo muy desconectados de la programación) hacen que los proyectos no tengan la calidad que deberían, y terminan siendo más un problema que un trabajo decente.

¿Cómo evitar los problemas de trabajar en un proyecto web de programación?

Algunos de los consejos son más que obvios: mantén una programación clara, investiga antes de comenzar, plantea una buena estructura de datos…

Sin embargo, aun cuando se es un programador pulcro y ordenado, finalmente deberás enfrentarte a la realidad: cuantas más líneas escribas, más errores cometerás.

¿Se pueden realizar trabajos de más calidad, programando menos? La respuesta es: Sí, utilizando un marco de trabajo adecuado (framework). Estos marcos son bibliotecas de código bien probadas, generalmente utilizando el Modelo Vista Controlador (puedes leer más acerca del Modelo Vista Controlador en Wikipedia o en este post de nuestro blog sobre MVC). Se utilizan para hacer de forma más rápida las tareas más repetitivas: creación de formularios, conexión a base de datos, paginación, etc.

Al estar ya todo hecho, simplemente hay que usarlo, se evitan los errores típicos de la programación tradicional que nos han sacado los colores en más de una ocasión (cualquiera que haya presentado un proyecto ante uno o varios clientes sabrá a lo que me refiero: un enlace erróneo, un error no manejado…)

Para quienes trabajan con PHP, encontrarán que hay una gran cantidad de estos frameworks que pretenden hacer la vida más fácil a los programadores. Pero ¡cuidado!, algunos harán que el proyecto se complique más. No tiene mucho sentido utilizar un framework para una web de cuatro páginas, a menos que sea como experimento…

Veamos a continuación un marco de trabajo en PHP que cumple unos requisitos muy definidos:

  • Mantiene un equilibrio correcto entre lo que ya está hecho y lo que debes programar. Un framework con muchas funciones es más fácil de usar, pero más lento y pesado.
  • Debe estar bien documentado. Te vendrá muy bien cuando estés empezando.
  • Debe ser ligero, configurable y sencillo.
Logo CodeIgniter

Logo de CodeIgniter

Un marco de trabajo que me ha sorprendido es CodeIgniter. Rápido, funcional y bien documentado. Creo que es ideal para comenzar a trabajar en proyectos de cierta complejidad.

Obviamente no es el único: ZendFramework, CakePHP, Kohana hacen seria competencia a CodeIgniter.

¿Por qué, entonces, nos decantamos por CodeIgniter?

Principalmente porque es el más rápido y el que más documentación tiene. Además te permite mantener una forma de programación más “clásica”, al no tener tantos módulos o librerías como otros que, en muchos casos no se utilizan.

De forma que podemos asegurar que CodeIgniter es muy adecuado para empezar a trabajar en un Modelo Vista Controlador. Tus proyectos de programación web ganarán en calidad, y serán más rentables.

Instalar extensiones de Firefox como aplicaciones de escritorio

¿Alguna vez has querido usar una extensión de Firefox sin tener que usar el navegador? Pues si te planteas si realmente es posible, la respuesta es sí, es posible utilizar extensiones de Firefox de forma independiente al navegador.

Lee el resto de esta entrada