Me mudo a chusete.es

Ya me han activado el dominio que adquirí con el plan Jóvenes en la Red, por lo que desde hoy este blog estará alojado en mi nuevo dominio: http://chusete.es

A los cuatro gatos que me seguís, actualizad vuestros feeds

¡Nos vemos!

Presupuestos y análisis web

Presupuestar un proyecto de desarrollo software es una tarea muy compleja, en la mayoría de los casos diría que se trata de magia¹. Tal y como dicen en Extreme Programming for Web Projects,

¡La estimación es alquimia! No podemos calcular el número de documentos y funcionalidades y simplemente multiplicarlos por algún factor que nos dé una respuesta mágica.

Y no podría estar más de acuerdo. Hay demasiadas variables en juego como para poder hacer una estimación más o menos precisa. Interoperabilidad, accesibilidad, SEO, diseño gráfico, diseño de interfaces, programación en el servidor, programación de interfaces, optimización del código, calidad, seguridad, documentación, gestión del proyecto, etc. Además, distintas personas/equipos pueden trabajar puntualmente juntos en determinadas secciones, como el diseñador gráfico junto con expertos en márketing y usabilidad.

Si bien es cierto que en páginas corporativas sencillas todo el trabajo puede condensarse en pocas horas y es fácil calcular el plazo de entrega, cuando el desarrollo es complejo y requiere de un equipo de personas trabajando en paralelo, el número de horas puede dispararse de forma dramática, arruinando un proyecto, incumpliendo plazos y perdiendo clientes.

¿Entonces cómo se suelen estimar los proyectos? Existen numerosos métodos. Sin embargo, la mayoría de ellos se basan en fórmulas que utilizan como premisa prever el número de líneas de código que tendrá el proyecto, lo cual en mi opinión nos puede llevar a una situación incluso peor. No es lo mismo una línea de código en Perl que en un framework como Ruby on Rails, ni todos los programadores codifican igual. Además, hay muchos factores implicados en la creación de software aparte de la programación.

En mi opinión lo que mejor funciona es conocer de forma precisa todos los hitos semanales del proyecto, y basándonos en un histórico, podremos hacer una estimación bastante más precisa. Pero surge el gran problema: Necesitaríamos un análisis detallado de la aplicación, y cuando hacemos presupuestos tenemos que ser ágiles, no debemos hacer esperar al cliente.

Para explicar el problema utilizaré la clásica analogía de la construcción de edificios. Supongamos que un cliente desea una vivienda, acude al equipo de albañiles y les dice “Quiero algo muy sencillo. Una vivienda con 3 dormitorios, salón y cocina. ¿Por cuánto me saldría?”. Lógicamente le exigirán muchos más detalles. ¿Sobre qué tipo de suelo se trabaja? ¿Qué tipo de construcción quiere? ¿Cuál será la disposición final de las habitaciones? ¿Cuántos baños tendrá? ¿Dónde irán estarán los interruptores? ¿Hace falta conexión telefónica en los dormitorios? ¿Querrán garaje? En definitiva, es necesario que un arquitecto haya definido previamente y de forma precisa todos los detalles de la vivienda.

En el desarrollo web esto prácticamente nunca sucede. Bajo unas sencillas premisas se presupuesta algo tan versatil como una página. Pongamos un ejemplo sencillo: El cliente quiere añadir a su actual página un módulo para añadir noticias que se puedan comentar. Para ello desea que los usuarios se autentiquen. Existen muchas formas de realizar esto. Podríamos crear un usuario maestro que se autenticara mediante HTTP. Otra opción sería tener varios usuarios preestablecidos creados en una base de datos o en un fichero, que ingresaran mediante un formulario HTML y se usara una cookie para manejar sesiones. O bien podría tambien permitirse que cualquier persona se registrara para así poder firmar comentarios con su usuario, y que desde un panel de control el administrador pueda actualizar sus permisos para permitirles poder publicar noticias. Además, se podría añadir confirmación por correo electrónico, códigos de seguridad captcha tras un determinado número de intentos de acceso fallidos, recuperación de contraseña, o numerosos campos que poder rellenar, como localidad, usuario de mensajería instantánea, fecha de último acceso o firma en sus comentarios.

Partiendo de una premisa sencilla hemos llegado a soluciones muy distintas. Es posible definir brevemente estos detalles en el presupuesto, pero en proyectos medianos/grandes nunca llegará a ser suficientemente preciso como para asegurarnos un error en la estimación asumible. Necesitaríamos de un riguroso análisis y diseño previo, para posteriormente realizará la codificación, pruebas e implantación.

De este modo, la creación de proyectos software disfrutarían de una notable mejora en la gestión si se dividiera al menos en dos etapas:

1. Análisis y diseño
2. Codificación, pruebas e implantación.

No sólo sería sano para el sector de desarrollo, sino que nos obligaríamos a seguir un orden, unas pautas de trabajo, que repercutirían notablemente en la calidad del producto, con lo que el cliente estaría mucho más satisfecho.

Cuando una persona quiere construir una vivienda, proporciona a los constructores los planos y detalles de ésta. Cuando el Estado saca a concurso la construcción de un nuevo tramo de autovía, facilita toda la información necesaria de su recorrido y de la calzada de forma precisa. La ingeniería del software es una disciplina aun adolescente. Quizás deba aprender de sus mayores.

---

¹ Aun tengo muy poca experiencia en gestión de desarrollos software. Habré realizado unos 20 presupuestos, y desarrollado unas 12 páginas, la mayoría de ellas poco complejas. Estáis invitados a ponerme a caldo si suelto barbaridades

Circulación chunga

Este post no es sobre nada de la web. Anoche a las tantas de la mañana en un bar cualquiera discutíamos sobre situaciones al volante de dificil solución. ¡Vamos a ello!

Situación 1

Carretera convencional. El coche negro, en vista de que en sentido contrario no viene nadie, decide adelantar. Mientras, el coche amarillo decide salir hacia su izquierda, pues le da tiempo a incorporarse, por su derecha no viene nadie y no ha visto al coche negro adelantando. Se chocan ¿Quién tiene la culpa? ¿Cómo se debería evitar?

Situación 2

Carretera convencional. El coche negro decide adelantar. Justo cuando empieza, el coche amarillo comienza a torcer para incorporarse al camino a su izquierda. Todos los vehículos se ven obligados a reducir drásticamente la velocidad, incluido el negro. Al salir de la calzada el amarillo, el negro descubre al vehículo azul justo frente a él y chocan. ¿Quién tiene la culpa? ¿Cómo se debería evitar?

Situación 3

Carretera convencional. Un ciclista circula por el arcén cuando cruza un carril deceleración. A su izquierda, un vehículo quiere salir de la calzada. ¿Quién debe ceder el paso a quién?

Situación 4

Autovía de 3 carriles. El coche negro acaba de adelantar al rojo y, en vista de que no ve ningún vehículo más, decide incorporarse al carril central. A la vez, el coche amarillo decide adelantar al verde. El negro y el amarillo chocan. ¿Quién tiene la culpa? ¿Cómo se debería evitar?

Si alguien está seguro de conocer la respuesta, mis amigos y yo os lo agradecermos

SVG y la web

Los mapas de bits no escalan (Y nunca mejor dicho), por lo que en numerosas situaciones es preferible utilizar imágenes vectoriales. Por ejemplo, los escritorios de Linux ya están permitiendo emplear iconos vectoriales, de modo que se vean siempre bien definidos independientemente de su tamaño o de la resolución de la pantalla. Existen muchos formatos propietarios, pero, como siempre, para garantizar la interoperabilidad es preferible utilizar estándares, y ese es el formato SVG, que es un lenguaje para describir imágenes y aplicaciones gráficas en XML.

En el mundo web es igualmente interesante poder empotrar imágenes dinámicas generadas mediante SVG. Por ejemplo, hace un tiempo quise hacer unos mapas de densidades de población por municipios generados de forma automática para la Wikipedia. En realidad es muy sencillo. En ese caso podemos partir de una imagen con un objeto por cada término municipal, y mediante un editor de SVG (Por ejemplo, Inkscape) editar las propiedades del objeto y establecer como ID el código postal del municipio. De ese modo, podremos acceder mediante DOM al objeto que representa cada término municipal para posteriormente establecer el color de fondo dependiendo de su densidad (Expresiones regulares al rescate).

Y es que a veces nos complicamos mucho la vida, como por ejemplo dibujando a pelo polígonos sobre la API de Google Maps, cuando incluso podemos empotrar directamente imágenes SVG en un mapa de Google.

A día de hoy, la mayoría de los navegadores permiten visualizar directamente imágenes vectoriales SVG dentro de un documento XHTML, pero como a menudo sucede, Internet Explorer no renderiza de forma nativa SVG. ¿Qué podemos hacer en esos casos? Muy sencillo. Convertir dinámicamente a un mapa de bits. En el caso de PHP no he encontrado ninguna biblioteca o clase que permita la conversión de forma eficaz, sin embargo existen utilidades en la línea de comandos a las que podemos llamar para que realicen conviertan al formato deseado (Como el propio Inkscape o la utilidad convert de ImageMagick).

Porqué me gusta tanto el desarrollo web

Recuerdo que en mis primeros años de universidad una gracia bastante recurrente entre mis compañeros era decir que si no te querías complicar la vida con el PFC hicieras una página web. Éramos unos polluelos, y no podíamos estar más equivocados. El hecho de que existan formas de crear una página sin necesidad de programar (Ya sea utilizando un CMS o bien HTML con un editor WYSIWYG) no significa que todas las páginas deban ser sencillas. No es que me guste complicarme la vida, de hecho creo que un vicio bastante frecuente entre los desarrolladores es que somos muy perezosos (Gracias a ello encapsulamos funcionalidades en unidades más o menos reutilizables), lo que ocurre es que disfruto conjugando numerosas disciplinas de la informática. Y esa es precisamente la razón por la que adoro la web: Es un entorno totalmente heterogéneo donde [casi] toda la informática tiene cabida.

Los comienzos

Muchos hemos hecho nuestras primeras páginas web con aplicaciones para editar HTML. Es ahí cuando empiezas a descubrir lo útiles que son todos los controles de usuario como botones, cajas de texto, tablas, etiquetas o menús. Suele ser una lección precipitada de Interfáces Gráficas de Usuario. Sin embargo pronto necesitas tener más control sobre tu página, por lo que decides indagar en HTML y descubres las maravillas de los Lenguajes de Marcado, una forma muy sencilla de intercambiar información entre máquinas. A la vez, compruebas que no es una buena idea repetir tantas definiciones sobre cómo mostrar la web en cada uno de los ficheros, por lo que aprendes CSS, y lo que es más importante, comprendes la necesidad de separar en capas la información en sí, y el cómo se muestra. Pero no todo funciona como esperabas, ya que tu web no se comporta igual en todos los navegadores, y ahí es cuando descubres lo importante que es que exista un organismo regulador que establezca los estándares, el W3C.

Pero ahora no sólo quieres que tu página esté bien estructurada y que sea compatible con todos los navegadores, sino que además quieres que luzca bonita (Diseño Gráfico), que sea intuitiva (Usabilidad) y accesible a cualquier usuario (Accesibilidad).

Pasos intermedios

Pronto tu página empieza a crecer, y necesitas ahorrarte trabajo a ti y al usuario. Es cuando de verdad entra en juego la programación. Pero resulta que hay dos lugares en los que programar, en el servidor y en el cliente (Aprendes sobre la estructura cliente-servidor). En el lado del cliente utilizas JavaScript, que es un lenguaje de programación estructurado, y en el lado del servidor PHP, ASP, JSP, Ruby, Python o cualquier otro, la mayoría de ellos lenguajes orientados a objetos.

Y pronto surge la necesidad de almacenar información de una forma robusta, sencilla y escalable, y es cuando aprendes a Diseñar Bases de Datos y a generar consultas mediante SQL. ¡Ahora tus páginas sí empiezan a ser de verdad escalables! Independientemente de si eres el administrador o no del servidor de bases de datos, has aprendido numerosas nociones de qué es un Sistema Gestor de Bases de Datos Relacionales. Ahora estás utilizando una estructura de 3 capas: Cliente – Servidor de aplicaciones – Servidor BBDD.

Pronto necesitarás gestionar las sesiones de usuario, por lo que casi con total seguridad deberás aprender sobre las cookies, y querrás poder gestionar redirecciones, si tus páginas se deben almacenar en una memoria caché o mostrar errores de página no encontrada. En consecuencia, debes aprender sobre HTTP, que no es más que un Protocolo de Nivel de Aplicación. Además has aprendido cómo dotar de estado a un protocolo que no almacena estado.

Con el tiempo la lógica de las aplicaciones web que desarrollas empieza a ser más compleja, pero siempre hay patrones que se repiten, por lo que decides aprender más acerca de Patrones de Diseño, e incluso utilizas algún Framework de desarrollo. Puede que incluso decidas conocer alguna metodología de desarrollo como Programación eXtrema.

La cosa se complica

Un día tu página empieza a tener mucho tráfico, y tu alojamiento compartido se te queda pequeño. Entonces decides utilizar un servidor dedicado. Ahora no sólo tienes que gestionar tu página, sino que debes preocuparte por la seguridad de la red con un firewall y una buena política de permisos. Gestionarás el servidor de bases de datos, de correo electrónico, de páginas web, de ficheros, etc. Es decir, aprendes a gestionar servicios críticos, por lo que ya tienes nociones de administración de sistemas.

Además quieres poder interactuar con otras páginas, bien sea integrando su información, o facilitando la que tiene la tuya. En el segundo caso necesitas generar una API para que los demás puedan acceder a tu información, y a ser posible exportando en lenguaje como XML o JSON.

Luego deseas optimizar tu página para que sea más veloz, y entonces empiezas a utilizar servidores de caché.

Aquí ya hablo desde la inexperiencia total, pero imagino que llega un momento en que tu página debe estar alojada en un cluster (Computación Distribuída) para poder delegar todo el tráfico a distintos servidores y obtener tolerancia a fallos.

Resumiendo

En el desarrollo web tienes la posibilidad de aprender y conjugar:

• Interfáces Gráficas de Usuario
• Lenguajes de Marcado
• Separar en capas
• Estándares Web
• Diseño Gráfico
• Usabilidad
• Accesibilidad
• Estructura cliente-servidor
• Lenguajes de Programación Estructurados
• Lenguajes orientados a objetos
• Diseño de Bases de Datos
• SQL
• Sistema Gestor de Bases de Datos Relacionales
• Protocolos de Nivel de Aplicación
• Aplicaciones web
• Patrones de Diseño
• Frameworks de desarrollo
• Seguridad de la red
• Administración de sistemas
• APIs
• XML o JSON
• servidores de caché
• Computación Distribuída
• Tolerancia a fallos
• Y un largo etcétera

¿Y quién dijo que hacer páginas web era una cosa sencilla?

Ancho de banda de un camión

Este ejemplo es un clásico. Si la memoria no me falla, hace un par de años mi profesor de redes de la universidad nos decía que nunca despreciáramos el ancho de banda de un camión. El pasado fin de semana bromeaba sobre esto con un amigo, y nos pusimos a echar cuentas. ¿Cuál es el ancho de banda de un camión? E igualmente interesante, ¿es más caro que una conexión ADSL convencional?

ADSL convencional

• Precio – 40,90€/mes
• Ancho de banda de descarga – 3Mbps
• Precio por Mbps – 40,90 / 3 = 13,63€

Trailer

Un disco duro cualquiera:

• Capacidad – 750GB
• Peso – 0,63Kg

Un trailer cualquiera:

• MMA – 24.000Kg
• Precio kilómetro – 3,35€

Por tanto un trailer puede transportar 38095 discos duros, o lo que es lo mismo, alrededor de 27.000GB

Supongamos un viaje de 600Km. A una media de 80Km/h, al trailer le llevaría 7,5 horas. Luego el ancho de banda del camión es: 27.000 / 7,5*60*60 = 1GBps. ¡Pero espera! Estamos hablando de bytes, no de bits. Para compararlo con nuestra conexión ADSL tendremos que multiplicar por 8, con lo que el ancho de banda del camión queda en 8Gbps. No está nada mal, ¿verdad?

Aun queda lo mejor. ¿A cuánto sale el Mbps si utilizamos un trailer?

• Precio del trayecto – 600 * 3,35 = 2010€.
• Precio del Mbps – 2010 / 8000 = 0,25€

Así pues, nunca subestimes el ancho de banda del camión.

Relacionado: El precio de los mensajes de texto es muy superior a transmitir datos desde el Hubble.