The Code is Poetry » Blog

Áreas de TI vs Administración

Ronald Guillen — Wed, 02 May 2012 05:04:18 +0000

Desde que se introdujeron las tecnologías de información al interior de las organizaciones se generó un problema que aun sigue vigente. Las áreas encargadas de tecnología hablan un “idioma” que la parte administrativa simplemente no entiende y viceversa.

Para resolver este problema se crearon una serie de mecanismos para representar gráficamente los elementos de un sistema sin necesidad de profundizar en lo ténico, creando incluso un nuevo tipo de profesional, el analista de sistemas.

La funcion de este personaje es normalmente el de traducir los procesos de negocio y requerimientos de las diversas áreas de sistemas a un lenguaje comprensible por ambas partes. En muchos casos se usa UML, sin embargo existen muchas formas de representar un sistema.

Estos diagramas deben de cambiarse y actualizarse conforme avance el proyecto, y dependiendo del proceso elegido para el desarrollo de software, se necesitarán muchas reuniones para realizar un cambio. cof.. PMI cof.. RUP

Si el proyecto dura 5 años y tienes el presupuesto suficiente como para no morir en el intento, no existe ningun problema, pero si tu proyecto tiene que entregarse para ayer, no me imagino el desastre. Pero seré objetivo, en muchos casos funciona muy bien.

Si tu empresa demora 30 días en realizar un pequeño cambio a un formulario, y la competencia lo hace en 30 min estarás en un gran problema. Esto aplica por ejemplo a SEO y CRO, debido a que la variacíon del ranking en google es casi de minuto a minuto.

¿Existen otras alternativas? Afortunadamente si existen, por ejemplo las metodologías ágiles tratan de eliminar mucha de la redudancia de UML mediante mecanismos muy ingeniosos que trasladan los requerimientos directamente al área de tecnología, de esta forma se ejecutan de forma mucho más eficiente.

El código puede ser autodocumentado, sin embargo esto requiere de mucha disciplina, pero al final termina siendo mucho más eficiente que las 300 páginas en papel que se generaban con otras metodologías. Seamos sinceros, quien lee los manuales.

Aquí es necesario aclarar que existen documentos que si son vitales, entre ellos:

Diagrama de base de datos
Diccionario de datos
Descripción de componentes
Diagramas funcionales

Finalmente es necesario ceder en ambas partes, las capas intermedias de administración tiene que esforzarse en comprender un poco más sobre las tecnologías de información, y por otra parte las áreas de tecnología de información deben de expresarse en un lenguaje menos técnico.

Algo de usabilidad para E-Commerce

Ronald Guillen — Sun, 29 Apr 2012 03:59:58 +0000

Es increible lo que un comic nos puede enseñar, sin embargo el secreto esta en olvidarte por un momento que tienes que entregar esa tienda electronica para el Lunes. Olvidate de los procesos, olvidate de los sistemas de pago. Lo unico importante aqui es resolver la vida de los usuarios. Los procesos funcionan bien con la gerencia, pero al final del dia a los usuarios solo les importa que la experiencia sea la mejor de todas.

The Oatmeal nos enseña un caso tipico de como un usuario puede llegar a la frustracion total, cuando lo unico que deseaba era comprar un producto en tu tienda.

How to make you shopping cart suck less.

Mil llamadas perdidas

Ronald Guillen — Mon, 16 Jan 2012 03:02:24 +0000

Desde hace algunos meses he notado que ya no me importa cargar la batería de mi teléfono, y en muchos casos lo dejo ahi tirado en cualquier lugar. El resultado de esto termina siendo una larga lista de llamadas perdidas y de personas quejandose por que no contesto sus llamadas. No es que sea a proposito, es simplemente que he desplazado la función de comunicación hacia el correo electrónico.

Debido a mi trabajo siempre estoy conectado a la mensajería instantánea y al correo electrónico, con esas 2 herramientas es suficiente en muchos casos para coordinar todo lo que sea necesario durante el día, esto funciona incluso con los clientes… bueno no con todos.

En casa puedo estar en la iMac trabajando en algun proyecto, o estoy con la notebook viendo alguna película, sin embargo en ambos casos tengo una pestaña con el correo electrónico, es por ello que escribirme un correo electrónico resulta la mejor opción de comunicación para mi.

Ahora entiendo el comercial de Apple cuando salío el iPhone 3G. Al final terminaba con la siguiente frase “… y tambien es un teléfono.”

No quiero un Framework que lo haga todo

Ronald Guillen — Sun, 15 Jan 2012 23:27:00 +0000

Hace ya varios meses que no escribo en el blog, lamentablemente sigo algo desordenado con el tiempo. Por otra parte durante las últimas semanas estaba buscando un Framework para desarrollar una pequeña aplicación. Luego de revisar los principales frameworks en PHP y las diversas funcionalidades que ofrecen, tuve que llegar a la conclusión de que ninguno se acerca al concepto de framework que esperaba.

Personalmente considero que un Framework debe de resolver solo 3 aspectos de la programación en PHP.

Routing
Templating
ORM

Todos lo demás me parece que es simplemente innecesario, debido a que cada aplicación tiene diversos requerimientos, y es muy probable que no termines usando todas esas maravillosas características que tiene un Framework en particular. Por otra parte un Framework no debe de forzar la convención de nombres para los archivos, debido a que es probable que ya tengas una convención definida para la codificación.

En el caso de Python, me parece que los desarrolladores de Django han hecho un gran trabajo, y resalto algunas cosas muy simples que me gustan de este Framework y que tranquilamente pueden copiarse a los que ya existen para PHP:

Las direcciones URL se pueden mapear a lo que yo desee, no tengo que se seguir la plantilla de siempre: controller/action/variable
Puedo organizar mis archivos de la forma que desee, sin que afecte el funcionamiento del Framework.
Las clases y métodos pueden tener cualquier nombre, no estan limitados a: DefaultController, indexAction, etc.

Error 303: Icon is missing from the package

Ronald Guillen — Sun, 15 Jan 2012 23:26:19 +0000

Si obtienes este mensaje de error al compilar tu aplicación Adobe Air mediante la terminal, simplemente agrega el nombre de los archivos de los íconos al comando, por ejemplo de la siguiente forma:

sudo adt -package -target apk -storetype pkcs12 -keystore ronald.p12 Grillo.apk Grillo-app.xml Grillo.swf icon_128x128.png icon_48x48.png icon_32x32.png

No más nubes esponjosas por aqui

Ronald Guillen — Sun, 15 Jan 2012 23:25:16 +0000

Un momento, pero yo odio el sol!!. En realidad me referia a la recurrente frase de “la nube” en referencia al “Cloud Computing”. Estos últimos días del año estuve buscando una plataforma enla nube para alojar una aplicación que estoy desarrollando. Luego de revisar Google App Engine y Windows Azure termine escogiendo un modelo intermedio en Rackspace.

¿Por qué elegí una plataforma semi-cloud?

Es posible que aun no me acostumbre a la nube para el desarrollo de aplicaciones, ó que simplemente estas plataformas no cumplen algunos de mis requerimentos. A continuación un resumen de mi evaluación de ambas plataformas:

Google App Engine:

Esta fue mi primera opción debido a que te permite hasta 1 millón de visitas al mes de forma gratuita, soporta Python =) e incluye Django, no podia pedir más salvo que no incluye una base de datos relacional, y eso de conectarse a una base de datos en otro datacenter degrada el performance de las aplicaciones. Google App Engine incluye su propio motor de datos propietario, por lo cual tendría que escribir la aplicación conectada desde la base con el motor de datos de Google, limitando mi capacidad de migrar hacia otra plataforma.

Google promete que muy pronto estará disponible un motor de datos relacional, pero solo para su versión Enterprise, lo que de alguna forma le quita el atractivo que tenia para mi. Es posible escribir una capa de abstracción de datos, pero eso agregaría trabajo adicional al proyecto y adicionalmente requiero de un daemon propio que ejecute algunas tareas para la aplicación.

Windows Azure:

Recorde que tenia una cuenta de Windows Azure y que soy partner de Microsoft(No se como sucedio…), por lo cual me decidi revisar un poco mejor esta plataforma. En princio el gran atractivo para mi fue que soporta C#(Lo siento Java..). Por otra parte posee soporte para ASP.NET MVC, con lo cual el desarrollo sería mucho más sencillo. Posee soporte para SQL Server que si es una base de datos relacional. Posee 2 roles llamados Web Role y Worker Role, el primero es basicamente una aplicación que se ejecuta sobre IIS 7.0, y el segundo es un tipo especial de aplicación que se ejecuta como un servicio en constante ejecución.

El soporte de Microsoft, siempre muy amables me guiaron en la configuración y los aspectos necesarios para cargar mi primera aplicación de prueba. Pero no todo es perfecto, y nuevamente me encontre encerrado en esta plataforma con respecto al Worker Role, debido a que no cuenta con una contraparte fuera de la plataforma de Windows Azure, por lo cual una migración requeriría de la creación de un servicio que actue de forma similar.

¿Por qué es tan importante la capacidad de migración?

Es cierto, si escojes alguna de estas plataformas para tu apliación, es muy probable que no llegues a migrarla debido a que es mucho más cómodo ejecutarla en ese ambiente. Sin embargo si en algún momento requieres de un mayor control, ó servicios adicionales que no están soportados no tendras otra opción que adecuarte a las limitaciones. Adicionalmente es necesario considerar que el personal capacitado para crear aplicaciones para estas plataformas es limitado.

¿Qué opciones quedan?

Algunas empresas están creando servicios para cubrir este problema, y lo llaman “Private Cloud”, que consiste en proporcionarte una plataforma flexible con gran capacidad de crecimiento que te permiten crear tu propia red de servidores en minutos y usar la tecnologías que creas conveniente con todos los privilegios necesarios. Entre ellas podemos destacar a Rackspace Cloud y Amazon EC2.

Cuatro meses con un Androide

Ronald Guillen — Sun, 15 Jan 2012 23:23:55 +0000

Bueno, no es que haya vivido con un androide de esos que salen en las películas, en realidad me refiero a mis impresiones respecto al Nexus One. En resumen he llegado a las siguientes conclusiones respecto al equipo y el sistema operativo.

Lo bueno de Android:

El sistema operativo es simplemente increíble e intuitivo, con una interfaz gráfica que no tiene que envidiarle nada a iOS.
Multitasking real, y resalto la palabra real debido a que en iOS el “multitasking” debe de ser implementado a nivel de aplicación, haciendo uso de servicios que se ejecutan en background.
Wifi Hostpot, esta es simplemente una funcionalidad que debería de venir de serie con todos los smartphones.

Lo impresentable de Android:

En mi caso solo se resume en una cosa. La no existencia de aplicaciones pagadas en Perú.

Respecto al equipo, no tengo ninguna objeción salvo resaltar que la pantalla OLED es simplemente expectacular, superando a mi parecer al “Retina Display” del iPhone 4.

UML no es sinónimo de buen software

Ronald Guillen — Sun, 15 Jan 2012 23:22:56 +0000

Como la mayor parte de los desarrolladores de software, pienso que la documentación es la parte más aburrida del ciclo de desarrollo. Pero es un mal necesario, a pesar de que estadísticamente casi nunca se acude a la documentación de un programa.

Ahora el problema viene cuando te encuentras con clientes que exigen un modelado completo incluso para proyectos con procesos predefinidos e invariables, solo con la excusa de que se obtendrá un “mejor desarrollo”.

En este punto queda por aclarar, que después de todo los diagramas son una representación de las funciones que implementará el software, pero al final la codificación será lo que hará todo el trabajo. En algunos casos podemos terminar con un excelente modelado, pero con una codificación pobre llena de errores.

En otros casos podemos terminar con todo lo contrario, una documentación mínima y una codificación buena y extensible. Y siguiendo la misma lógica, mi combinación favorita de “Juntemos todo a ver que pasa”, la cual no tiene justificación alguna.

Recordando un poco lo que mencionaron en algunos eventos, me viene a la mente lo que indicaba un desarrollador de Google, el cual respondió a una pregunta del auditorio con lo siguiente, en referencia a RUP: “No se para que enseñan esas cosas realmente, en Google no tenemos necesidad de esas cosas, debido a que trabajamos en grupos pequeños y nos reunimos todo el tiempo.”

JSON feeds en WordPress

Ronald Guillen — Sun, 15 Jan 2012 23:22:28 +0000

Existen múltiples plugins que realizan esta tarea actualmente, por lo cual este post es para aquellas personas que deseen crear su propio feed JSON ó son fanáticos de “Hagalo Usted Mismo”.

¿Para que crear un feed JSON? Es posible que desees incluir un listado de los posts de tu blog en otro sitio web, para lo que normalmente se usa RSS ó ATOM, pero hacer un parser para estos formatos suele ser complicado y se transporta una gran cantidad de datos. En contraparte JSON es un formato muy ligero y que podemos manipular fácilmente con Java Script.

Ahora manos a la obra!

En primer lugar creamos un archivo de nombre wp-json.php en la raiz de nuestro blog(en donde se encuentra wp-config.php). Este archivo debe de contener lo siguiente:

/wp-json.php

if (empty($wp)) {
require_once('./wp-load.php');
wp('feed=json');
}
require (ABSPATH . WPINC . '/feed-json.php');
?>

A continuación creamos un archivo de nombre feed-json.php en la capeta wp-includes de nuestro blog. Este archivo debe de contener lo siguiente

/wp-includes/feed-json.php

header('Content-Type: application/json; charset=' . get_option('blog_charset'), true);
$more = 1;
$items = array();
query_posts("");
while (have_posts()) :
the_post();
$item = array(
"title" => get_the_title_rss(),
"link" => apply_filters('the_permalink_rss', get_permalink()),
"description" => apply_filters('the_excerpt_rss', get_the_excerpt()));
$items[] = $item;
endwhile;
$arr = array(
'title' => get_bloginfo_rss('name'),
'link' => get_bloginfo_rss('url'),
'description' => get_bloginfo_rss('description'),
'language' => get_option('rss_language'),
'item' => $items);
echo "".$HTTP_GET_VARS["callback"]."(".json_encode($arr).");";
?>

Finalmente para probar nuestro feed nos dirigimos a http://miblog.com/wp-json.php y veremos nuestro nuevo feed en JSON. Puedes encontrar más atributos para usar en WordPress.

Drupal no es un CMS

Ronald Guillen — Sun, 15 Jan 2012 23:19:07 +0000

Antes de que intenten quemarme por decir semejante blasfemia, sugiero seguir leyendo este post.

Para empezar que es lo que creen que se viene a la mente a un desarrollador web cuando escucha las siglas CMS?. Normalmente y de acuerdo a la información que puedan haber escuchado, imaginan un backend en el que pueden modificar fácilmente el contenido de su sitio web mediante un editor WYSIWYG, y con capacidad de poder insertar y gestionar contenido multimedia muy fácilmente.

Aquí viene el problema, que es lo que obtienen al instalar y jugar con Drupal por primera vez?. Frustración total, ya que por los comentarios y noticias del medio piensan que Drupal es un WordPress en esteroides, pero al final aparentemente se encuentran con algo que está entre un framework y WordPress.

Y donde esta el super CMS?, no hay editor WYSIWYG?, como cargo las imágenes?, quizás algunas de las preguntas recurrentes al iniciar el desarrollo con Drupal. En realidad todo esto es posible mediante módulos desarrollados por terceros.

Ahora, si es posible suplir estas “falencias” mediante módulos por qué el título de este post dice que no es un CMS? En realidad mi intención es capturar la atención de las personas que aún no han usado Drupal, de esta forma sabrán con anticipación a que se están enfrentando.

El problema de Drupal no es el software, el problema es que la comunidad no se ha tomado el tiempo de explicar claramente que Drupal es un framework para construir tu propio CMS, y no un WordPress en esteroides.

Una duda que puede quedar flotando es: ¿por que usar Drupal si puedo hacer lo mismo con un framework PHP?, pero eso lo dejaré para otro post.