Sergio Gago

Hoy navegando, he llegado por casualidad a la Web de una empresa de diseño Web, inicialmente muy parecida a las otras miles que hay por España. Pero cuando ha empezado a salir una sonrisa de mi boca ha sido cuando he llegado a su política de precios:

• 5 Pantallas destinadas a las diferentes necesidades de tu actividad o negocio, por ejemplo: Quienes Somos, Nuestros Servicios, Dónde Estamos, Solicita tu Presupuesto, etc.
  Con 5 basta, ni una más ni una menos.
• 1 Pantalla con un Formulario para que puedas recibir datos en tu E-mail (pedidos, información…).
  A sabe cómo está hecho el formulario… probablemente un “mailto:” en el action.
• 1 Pantalla para confirmación de envío del Formulario (siempre que tu servidor lo permita).
  Guau.. .tecnología punta
• 12 Fotografías que puedes distribuir en las 5 pantallas principales (facilitadas por ti).
  Ni una más ni una menos, no sea que tengamos que retocar más de lo debido en photoshop.
• Logotipo de tu empresa en cada pantalla (facilitado por ti).
  Por supuesto!
• 1 Diseño de pantalla estándar que puedes elegir entre los diferentes modelos que tenemos actualmente disponibles.

Y cuando dicen página estándar, dicen una colección de plantillazos sacados de variantes de template monster y derivados que aplican a varios clientes. Es más, peores derivados de template monster, porque ni siquiera cumplen estándares.

Precio: 250€, sin Iva, ni registro de dominio ni hosting.

Analizando un poco las webs generadas (estas cosas me fastidian más de lo debido, y le suelo dedicar algo de tiempo), vemos que:

• Están desarrolladas íntegramente con dreamweaver (vale, esto no es tan malo).
• El < ! DOCTYPE > brilla por su ausencia, así como el tipo de codificación utilizada.
• La mayoría de las etiquetas están en mayúsculas.
• Maquetan absolutamente todo con tablas (volvámos a los 90!)
• Por supuesto, no valida, se usan parámetros de estilo en el html no siempre válidos, y los alt de las imágenes no existen (y mira que el dreamweaver te lo pide!).

Eso si, puedes pedirles un presupuesto personalizado:

• Cada pantalla HTML con texto (tamaño a4): 35€
• Cada imágen: 2€
• Formulario: 38€
• Inserción de logotipo: 2€
• Pantalla HTML emergente (toma ya!): 10€
• 3 Banners rotativos: 6€
• Imágen de fondo por pantalla: 2€
• Midis por pantalla: 2€
• Contador de visitas: 9€
• Tablón de anuncios con CGI: 60€
• Lista de correo: 60€
• Diseño de interface con elementos de navegación: 60€
• Barra de navegación personalizada: 180€
• Mantenimiento y modificaciones. 9€
• Alta en 150 buscadores: 80€
• Ser un Webmaster de finales de los 90 en pleno fenómeno “2.0″ no tiene precio.

Y lo más divertido viene cuando en su página principal, “denuncian” a otras Webs por plagiar su plantilla… me pregunto qué pensarán sus clientes cuando vean que su web es exactamente igual que otra…

No se cuánto facturarán (ni me importa demasiado), pero al final tendrán fecha de caducidad…

Nota: No he puesto su Web a propósito, pero si alguien la quiere, me la puede pedir personalmente.

Desde que conocí la metodología de programación extrema hace unos años, me di cuenta de que estaba hecha para la Web. Aunque inicialmente estuviera pensada para cualquier tipo de desarrollo (sobre todo Java), realmente encaja a la perfección con un proceso de desarrollo Web normal.

La XP es uno de los muchos procesos ágiles que hay ahora mismo disponibles, y que se basa fundamentalmente en olvidarse de que no podemos adelantarnos a los cambios de requisitos, y a que los clientes siempre serán aleatorios y caóticos. De modo que nos propone varias pautas a seguir a la hora de gestionar nuestro proyecto. Copio los epígrafes del artículo en la wikipedia, adaptándolos a un desarrollo web medio – grande.

• Desarrollo iterativo e incremental: El desarrollo en espiral evolucionado. No podemos presentar directamente la imágen a un cliente, o a unos usuarios. Aquí entra la labor de bocetado, prototipado, pruebas de usabilidad, etc. Poco a poco vamos aumentando fidelidad a los prototipos hasta que desarrollamos la lógica de negocio completamente (donde el cliente ya pinta poco). Y como decía hace unos días: Da igual que tu algoritmo sea el mejor y más eficiente… si es feo, al cliente no le va a gustar!
  Y respecto a incremental, el hecho de ir añadiendo módulos, o funcinoalidades hace que el desarrollo sea menos caótico, algo nada nuevo dentro del desarrollo Web.

• Pruebas unitarias continuas. Hoy en día con Firebug, esto es más fácil que nunca. A la hora de desarrollar la GUI, trabajar con los efectos JS y el CSS (sobre todo con librerías), cada vez que vamos al navegador y pulsamos F5 para comprobar los efectos del último hack incluido no estamos haciendo más que pruerbas unitarias. Esto inicialmente estaba pensado para JUnit, y para la preparación de los casos de prueba de las clases antes de la programación de las mismas. Esto también lo podemos hacer en la lógica de negocio de nuestras clases. De hecho una técnica para fidelizar al 100% los prototipos es desarrollar toda la lógica de presentación apuntando a clases de prueba, que en lugar de sacar los datos de una capa de acceso a datos, tiene un contenido dummy (arrays escritos a pelo en una clase PHP). De esta forma, la interfaz da la impresión de estar terminada, pero realmente no hay nada por debajo.

• Programación por parejas: Esta es la parte que más me gusta, y que aunque parezca mentira realmente funciona. Mientras uno codifica, el otro va diseñando y realizando pruebas, preparando la codificación y comprobando lo que va haciendo el otro. Cuando hay un error que se nos atasca no hay nada mejor que pedir a alguein que lo eche un vistazo, y la programación por parejas va un poco por ahi. En el mundo del desarrollo Web es común hacer esto en parejas de diseñador gráfico – maquetador, o programador – analista, pero la idea es que haya cuatro ojos mirando el mismo monitor.

• Frecuente interacción del equipo de programación con el cliente. De hecho, el método propone que haya un miembro de la empresa cliente en el equipo de desarrollo. Esto es bastante inviable en el 99% de los casos, pero lo que si se puede hacer es un constante trabajo de pruebas y mejoras continuas. De nuevo, volvemos al prototipado y las pruebas con el cliente. Desde diagramas de casos de uso que sean entendibles, hasta documentación (no técnica), pasando, claro, por reuniones de seguimiento y de pruebas, documentadas y en acta.

• Corrección de todos los errores. Lo ideal es que cada “entrega” o “hito” no dure más de una semana. Cuanto más cortos mucho mejor, pues se genera menos ruido o caos en el código general. Y una filosofía que pocos apliacan. No se añaden funcionalidades hasta que se han solventado todos los errores de las existentes. En Web esto es muy importante. No nos sirve de nada implementar un mashup de google maps en nuestra aplicación, si la página no se ve bien en firefox!

• Refactorización del código. Aunque depende mucho del sistema que usemos (Java con struts y JSP, PHP, Ruby on Rails….), es importante refactorizar el código para aumentar la escalabilidad y el mantenimiento. En prácticamente todos los desarrollos informáticos acabas utilizando más librerías o implementando más funciones de las que necesitas. Muchas veces haces código duplicado, y otras podrías haber usado algún patrón de diseño para mejorar el código y hacerlo más claro. Lo idea es que cada iteración de la aplicación sufra una refactorización total, por supuesto sin modificar las funcionalidades. ¿Qué implica esto en el D. Web? Separar los CSS por tipo de presentación y módulo, juntar los JS de funciones similares, o separar los que no tengan nada que ver, buscar herencias y polimorfismos en el código e implementarlos, etc… Aquí la diferencia se nos dará en clarificación de código, y tiempo de carga (pasar de cargar código javascript de 80kb a cargar 30kb).

• Propiedad del código compartida: Todo el código es de todos y cualqueira puede modificar cualquier parte. Aquí estoy de acuerdo sólo si usas un buen control de versiones. Pero en los desarrollos Web es más común que un pequeño cambio afecte a toda la aplicación, de forma que se hace necesario que todos los desarrolladores conozcan todo el código y estén capacitados para modificarlo.

• Simplicidad en el código. Esto está claro, pero ampliarlo a simplicidad en la interfaz, en el diseño (no solo gráfico, sino de la aplicación), y por supuesto, cumplir con estándares y validaciones.

En general es útil cuando los equipos no son muy grandes (no más de 8 personas), y cuando son ágiles. La consultora tradicional tendrá muchos problemas para adaptarse. Sin embargo el equipo de jóvenes desarrolladores de una start-up, lo tendrán como el modelo ideal. Ergo concluyo: La programación extrema puede ser el mejor paradigma de programación para la creación de start-ups.

Más info en la web de difusión del extreme programming.

Pero no el posicionamiento en google, sino el de negocio, un posicionamiento que en muchos casos, se olvida.

Todo esto viene a través del artículo ¿Cuánto vale una web profesional? en Tecnotertulia, que me ha parecido muy interesante y me ha recordado a las charlas que tenía con mis socios hace tiempo (aunque no he podido dejar un comentario).

Y hoy publican “La Respuesta“, que en parte, contesta a lo que escribo en este artículo.

Divide los presupuestos de Webs en Gratuitos – De 500 a 2000€ – de 2000 a 9000€ – de 9000 a 22.000€ y de 22000 a 500000€. Clasificación que me parece bien, pero que yo diviría en función del personal y tiempo involucrado en el proyecto. De modo que respondan a estas preguntas:

• ¿El proyecto tiena la suficiente extensión para requerir un jefe de proyecto dedicado a planificación y seguimiento?
• El proyecto lo va a llevar a cabo una sola persona o harán falta distintos roles? Diseñador gráfico, analista, maquetador, programador, experto SEO, DBA…
• ¿Las herramientas de desarrollo requieren licencias? ¿Será de creación propia o se usarán módulos de otras aplicaciones (código libre)?
• ¿El proyecto requiere mantenimiento? ¿Se garantiza posicionamiento? ¿Hay que preparar documentación? ¿Formación? ¿Presentar memoria?
• etc…

Al final todo esto “cala” mucho en la empresa que desarrolla (y aquí quería llegar). Información sobre “cuánto cobrar” por un desarrollo hay mucha y muy variada, y cada uno te dirá una cosa, pero al final lo que importa es que cada uno encuentre su nicho de mercado (que no siempre tiene que ser el de los precios más bajos).

Si tus clientes son grandes empresas con grandes expectativas, no aceptarán presupuestos de 1000€, y si vas a vender una web a una pescadería que no va a entender la diferencia entre usar estándares o plantar su texto en una plantilla, probablemente 300€ será mucho. Cuando nosotros vendiamos webs por 600€, nuestro trabajo era medio, con bajones de vez en cuando, pero cuando cambiamos la filosofía a “desarrolladora cara” incluso para pymes no bajando de 2000 o 3000€ por proyecto, de repente empezaron a llover trabajos, encontramos nuestro nicho. Y si alguien decía que eramos muy caros, le decíamos que eso era porque lo hacíamos mejor.

AlphaWork services es una especie de google labs de IBM, donde desarrollar aplicaciones (sobre todo) Web punteras, e intentan innovar en la forma de mostrar la información que tenemos actualmente.

Uno de los últimos trabajos que he visto es el Many Eyes, una aplicación social para la visualización y preparación de información colaborativa. Es decir, que grupos de usuarios puedan representar de forma social la información que deseen usando varios tipos de gráficos, entre ellos evoluciones de tag clouds.

Recomiendo echar un vistazo al tour de la aplicación, donde podemos ver el potencial que tiene la herramienta.

Cosas similares se hicieron con Quintura, por ejemplo. También recomiendo la lectura del artículo de Yusef Hassan-Montero y Victor Herrero-Solana: Improving tag clouds as visual information retrieval interfaces, que ya se puso en un comentario de este blog.

¿Hasta donde pueden llegar las nubes de tags para las categorías? ¿Cuál es la utilidad real a nivel de usabilidad?

He leido en Sentido Web esta entrada que habla de PHP Maker , una herramienta que no conocía, y que me de haberlo hecho me habría ahorrado unas cuantas horas de trabajo.

A la hora de desarrollar aplicaciones web, en la parte de acceso a datos suelo implementar dos modelos diferentes, uno basado en consultas, y otro basado en “maestros”. Aunque no es nada nuevo, trataré de explicarlo un poco.

• Servicio de consultas:
  Sería una parte de la capa de acceso a datos que gestiona todas las consultas necesarias para ofrecer información a la lógica de negocio. Búsquedas concretas, ordenaciones, extracción de información de tablas diferentes en función de variables determinadas, etc… Id est: “Quiero ver los últimos 10 posts del usuario X en la categoría K”. Esa consulta implica varias tablas, y parámetros que nos ha pedido el usuario de antemano.
• Servicio de maestros:
  En ocasiones es necesario obtener toda la tupla de información de un registro, para cualquiera de las modificaciones básicas (CRUD – Create, Retrieve, Update, Delete, es decir: Crear, Obtener, Actualizar, Modificar registros). En esas ocasiones con un identificador nos puede valer para obtener toda esa tupla.
  Pues bien, este servicio hace unas labores tan concretas y tan optimizables, que tiene sentido separarlas en un servicio aparte, y que sea la lógica de negocio y el acceso a datos el que decida qué usar en cada momento.

Entonces, este PHP Maker, nos sirve para generar automaticamente scripts de acceso a datos a partir de una base de datos, y por lo tanto nos ahorra mucho trabajo.
Para ser sinceros, no lo he probado en mis propias carnes, pero tiene muy buena pinta. Y en la misma página ofrecen XMLMaker, o ASPMaker, que prometen soluciones del estilo. Merece la pena probarlo!

Me he reido un rato con este artículo de gentegeek.com, y se me ha ocurrido ampliarlo pobremente…

• Separarás contenido de maquetación y de comportamiento, hornado al padre Javascript, a la madre CSS y al abuelo XHTML.
• No usarás editores WYSIWYG, y de tener que hacerlo, comprobarás el código resultante a mano.
• Te sentirás emocionado por la Web semántica y tratarás de emplear microformatos.
• No pondrás reflejos ni estrellas “2.0″ porque sí.
• Buscarás la forma de meter la inteligencia social en todo proyecto web que realices.
• Tratarás la accesibilidad como un requisito obligatorio y no “si me queda algo de tiempo”, y validarás con WAI.
• No intentarás hacer engaños burdos para salir mejor en google y te centrarás en crear mejor contenido.

etc… XD

Y los originales:

• 1. Amarás a
  sobre todas las demás etiquetas
• 2. No usarás
  en vano
• 3. Validarás siempre tu código con w3c
• 4. Honrarás al XHTML y CSS
• 5. No usarás tablas en la maquetación principal
• 6. No utilizarás la etiqueta dentro del código
• 7. No harás Copy&Paste de otras páginas
• 8. No programarás sólo para Internet Explorer
• 9. No descargarás por el emule plantillas de templatemonster
• 10. No codiciarás la Web 2.0

Veo en Denken Über una referencia al artículo original de Google Watch, sobre el experimento de estos últimos, cambiando la homepage de google al estilo yahoo.

Es cierto que en la homepage de google ya tiene todas esas funcionalidades, pero la GUI de yahoo me gusta mucho más. Creo que es mucho mas usable, y si tuviera las pestañas que si implementa ya sería excelente.

Me retracto de lo dicho en ejemplos de newsletters ayer, al ver esta noticia en Sentido Web: Lo que outlook 2007 no permitirá hacer con los mailings.

Parece ser que ahora usará el motor de Word para renderizar mensajes (si, ese mismo que te permitía hacer unas páginas Web estupendas).

• Se carga los background-image, tanto en html como en CSS.
• Adós a todo posicionamiento no “static”. Sin floats, nos quedamos sin columnas. ¿Será la vuelta al mundo de las tablas?
• Elementos de bloque mal especificados, los paddings y margenes ya no son lo que eran.
• Sin flash. (bueno, esto no es tan malo)
• No se pueden imágenes como viñetas de las listas no númeradas (tampoco es tan malo).
• No permite Gif animados (nunca los usé en mailings).

Interesante ver el mismo mail en Outlook 2000 y en Outlook 2007
Supuestamente, todo esto son motivos de seguridad, pero luego podremos embeber código activeX, o JS para hacer cualquier cosa… a saber. ¿Alternativas? Eudora, Thunderbird… y sino… Gmail con tu nombre de dominio.

El artículo original en SitePoint.

A la hora de desarrollar una Web, es cierto que usar frameworks es una ayuda muy interesante. Anieto, ya escribió hace unos meses sobre los más usados.
Quizá el problema puede estar en que unos te dan unas facilidades que no te dan otros, y por supuesto, mezclarlos es una muy mala idea. Además, la actual, si se puede llamar “guerra de frameworks”, provoca que cada vez tengan más funcionalidades, y por lo tanto más peso. De forma que si lo quieres solo para una cosa concreta, o te buscas un snippet de código concreto, o rebajas manualmente la librería.

En coder battery, dan una lista de razones muy adecuada sobre porqué usar frameworks, que intentaré resumir.

• Te permite programar más rápidamente.
• Te ahorra trabajo
• Da consistencia a tu código.
• Te ayuda a escribir mejor código y más ordenado.
• Te permite usar lo último en herramientas técnicas
• Te da soporte gratuito
• Te permite tener un ejército de programadores para ti.
• Te permite separar presentación de negocio.
• Puedes tener la documentación lista.
• Es más multiplataforma
• Mejor acceso a la capa de datos del que podrías hacer tu.
• Mejora la seguridad de tu aplicación

Bien, estas afirmaciones, lo cierto es que tienen muchas caras. Empezando porque hay que sopesar el tiempo de aprendizaje que requiere una librería, o la elección de la más apropiada (usaré prototype o jQuery?), por no hablar de efectos espectaculares que nos dejan asombrados, pero que requieren cantidades inmensas de código.

Aumenta el peso de nuestra aplicación, y, cuidado, como tengamos errores o incompatibilidades con el resto de nuestro código, prepárense para analizar el código línea a línea a ver dónde carajo está el fallo (gracias! firebug!).

Y depende que frameworks, tendrás mejor o peor soporte, las herramientas serán mejores o peores, o tienen una documentación maso menos útil.

“In the other hand” , tenemos este artículo en inglés de Andy Smith: Why frameworks suck, muy interesante de leer, aunque un poco denso.

Me quedo con una frase:

If building an application with libraries is playing football with your buddies, building an application on a large framework is playing football in the NFL. You may get money, attention and busty cheerleaders, but what was a game about throwing a ball and doing your damndest to make your best friend eat mud becomes a game about offsides, holding and television breaks; it’s just not fun anymore.

Si desarrollar una aplicación con librerías es como jugar al futbol (americano) con tus colegas, desarrollar una aplicaión con un gran framework es como jugar en la NFL (liga de futbol americano). Puedes conseguir dinero, atención y animadoras “pechugonas”, pero lo que fué un juego de tirar una pelota y hacer todo lo posible para que tu mejor amigo caiga sobre el barro, se ha convertido en algo lateral, de participación y televisión; ya no es divertido… (traducción libre y muy mejorable).
Y la conclusión, al final de su artículo:

Frameworks suck because they are an avatar of enterprise, frameworks suck because they take away your freedom, frameworks suck because they build walls between coders, frameworks suck because they make you fit your project to the toolset rather than the toolset to the project, and frameworks suck because they take the fun out of programming, long live the library.

Los frameworks apestan porque son la representación empresarial, porque te quitan libertad, porque levantan muros entre programadores, porque hacen que tengas que cambiar tu proyecto a la herramienta en lugar de la herramienta al proyecto, y porque le quitan la diversión a la programación, larga vida a las librerías!.

Sin duda, la clave está en el término medio. Ni son la panacea para cualquier proyecto, ni debemos dejarlos de lado. En parte estoy de acuerdo en que en ocasiones adaptamos nuestro proyecto a una herramienta, cuando debería ser al revés, de modo que ahi entra la inteligencia y experiencia del analista, que sopesa los riesgos y las ventajas de usar un framework y los acepta y asume.

Vosotros, ¿que framework utilizáis? ¿Qué dificultades os habéis encontrado a la hora de implementar alguno?

En esta entrega de las herramientas de trabajo para desarrolladores Web, vamos a entrar, no con un software, sino con una extensión sin la que ya no podría vivir.

Webdeveloper toolbar + DOM inspector (no os preocupéis, el firebug lo tengo para una entrega posterior).

Con el Web developer toolbar, tendremos una herramienta de testeo de nuestras páginas casi completo, a tiro de barra de herramientas. Muy fácil de usar y de aprender, y que probablemente nos sacará de más de un apuro a la hora de hacer la parte gráfica de nuestras Webs.

Haremos un repaso rápido a las opciones que tien:

• Disable: Desde aquí podremos deshabilitar las opciones más comunes, para ver el comportamiento de nuestra página en ausencia de estos sistemas, por ejemplo, Java, o javascript, colores o referers. Así, podremos comprobar si alguien sin javascript puede al menos acceder a nuestra información (navegadores de solo texto, lectores de páginas, motores de búsqueda, etc).
• Cookies: Cuando desarrollamos aplicaciones Web, es común que recurramos a las típicas “galletitas” para saber cosas del usuario. Desde este menú podremos, o bien deshabilitarlas, o bien añadirlas, eliminarlas, ver su código, etc.
• CSS: Para mi uno de los menús con más utilidad. Como de costumbre podemos deshabilitar los estilos y ver la página “desnuda”, podemos ver el código de las hojas CSS y sobre todo, centrarnos en algún elemento determinado. Pero lo más importante de todo es que nos permite editar el estilo de cualquier elemento “en caliente”, incluso de páginas que están online y no son nuestras!
• Forms: Desde aquí tenemos varias opciones típicas de formularios, comprobaciones de métodos de envío, prepopulado y modificación de algunos valores desde cliente.
• Images: El trabajo básico de las imágenes se reduce a: especificar bien los atributos “alt”, comprobar que el peso no es excesivo, y ver si hay superposiciones (entre otras). Desde aquí nos permite ir activando y desactivando opciones para comprobar los resultados en nuestra página (o en otras).
• Information: Este menú suele ser más útil para ver otras páginas que las nuestras (si lo hemos desarrollado nosotros, no nos dirá nada nuevo), o bien para depurar CSS, en esos momentos en los que te estás tirando de los pelos. Nos permite mostrar las anclas, claves de acceso (accesibilidad), tamaño en pixels de elemtos de bloque, orden de los DIVs y parentesco, información de los elementos (este último el que más me gusta, ya que saca un tooltip que cambia por donde tienes el ratón), y en general, toda la información relacionada con estilos y código Javascript.
• Miscellaneous: Aquí tenemos las clásicas opciones que no entrar en ningún sitio. Desde ver unas líneas guía muy útiles para maquetar, hasta limpiar todos los datos privados (caché, historial…) nuestros.
• Outline: A nivel visual, hay muchas ocasiones en las que es dificil ver realmente hasta donde llega una celda, o una capa determinada. Con outline podremos dibujar un borde bien grueso y rojo que nos marque los bordes de todos estos elementos, y así ver, por qué narices no conseguimos maquetar bien la página.
• Resize: Podemos modificar el tamaño de nuestro navegador a resoluciones determinadas para comprobar como navegarían, por ejemplo, los pobres de 640×480. También hay una opción de zoom.
• Tools: Desde aqui tenemos acceso directo a los validadores de la W3C, enlaces, y WAI (accesibilidad), además de poder abrir el DOM Inpector.
• View Source: Ver código fuente, pero con facilidades para ver el código de la página de un frame facilmente.
• Options: Opciones de configuración de la extensión.

Por otra parte, tenemos el DOM Inspector, imprescindible cuando nuestro amigo javascript lo manipula dinámicamente con appendChilds, innerHtMLs y compañía. Podemos ver el árbol jerárquico actualizado de la página que se muestra, con información de cada nodo, atributos, etiquetas, etc… y por supuesto, buscar dentro de todos los elementos, ver quienes son los padres y los hijos, etc… No se como hace tiempo pudimos desarrollar sin él. Nota: Al instalar Firefox, hay que especificar que quieres también el DOM inspector.

La Web developer, se puede descargar aquí.