CSS - Por qué usar pre-procesadores: Less / Sass (conceptos básicos)

viernes, 26 de septiembre de 2014

CSS (Cascading Style Sheets) es el lenguaje utilizado para detallar los estilos y formatos de webpages basadas en contenidos creados en documentos HTML.

CSS es muy simplista, accesible y esencial para quienes hacen diseños web pero también es bastante limitado.

El problema con CSS es que cuando el proyecto empieza a hacerse más complejo es cuando saltan a la luz las limitaciones que este lenguaje presenta respecto de las necesidades de desarrollo cada vez más sofisticadas - para las cuales no fue pensado -. Si bien se fueron haciendo cambios en los features de CSS con nuevas versiones y propiedades, todavía le falta mucho para poder satisfacer los requerimientos actuales del diseño web. Esto lleva a que las hojas de estilo se hagan cada vez más repetitivas y difíciles de mantener.

Para cubrir estas necesidades aparecieron los pre-procesadores de CSS que posibilitan el desarrollo de código más ordenado, optimizado y de fácil mantenimiento.

Estos pre-procesadores no ocupan el lugar de CSS sino que ayudan en el ahorro de tiempo de desarrollo, en la creación de documentos más prolijos y en facilitar el uso de características avanzadas de estilos.

Dos de los pre-procesadores más conocidos y utilizados son LESS (Less CSS) y SASS (Syntactically Awesome Stylesheets), cuyas características comunes son:

  • permiten una mejor organización del código
  • ofrecen el uso de variables
  • implementan el uso de mixins
  • permiten reutilizar código
  • tienen funciones nativas para llevar a cabo funciones de uso común
  • dan la posibilidad de ocultar comentarios
  • permiten incluir archivos
  • habilitan el uso de namespaces

Algunas de las virtudes que resaltan quienes prefieren Less

Extensiones

Si bien Sass cuenta con una librería (Compass) conteniendo muchísimas extensiones, Less también puede usar diversas extensiones que, a diferencia de Compass que agrupa todas en un único repositorio, están dispersas y construídas por distintos desarrolladores.
Algunas extensiones disponibles para Less:

Por su simplicidad Less es ideal para quienes ya saben de CSS pero necesitan ponerse rápidamente prácticos en el uso de un pre-procesador que les ayude en sus tareas. La curva de aprendizaje puede ser un poco menos pronunciada con Less que con Sass, aunque en este punto están muy parejos.

Para algunos el sitio oficial de Less es más fácil de usar y es más vistoso que el de Sass, aunque este último ha mejorado mucho la estética y usabilidad de su sitio.

Puntos que resaltan quienes prefieren Sass

Anidamiento

Tanto Less como Sass permiten anidamiento, lo que es útil para evitar escribir selectores repetidamente. Pero Sass va un poco más allá permitiendo también el anidamiento de propiedades individuales.

Mixins y herencia de selectores

Ambos pre-procesadores ofrecen el uso de "mixins" y sólo difieren en la manera de definirlos (en Less con la directiva "@" y en Sass con class selector).

Los mixins en ambos casos se usan para incluir propiedades de un conjunto de reglas en otro. Pero Sass agrega la capacidad de herencia de selectores.

La herencia permite a los selectores heredar las propiedades de otros selectores, Sass soporta esta capacidad naturalmente mientras Less no puede hacerlo.

Documentación

En el sitio de Sass la documentación es mucha, muy comprensible y extensa. La presentación de información es muy sencilla, al estilo Wikipedia.

Por otro lado Less también ofrece buena documentación pero puede parecer más simple y directa, con mucho uso de ejemplos. En cuanto a la documentación puede parecer un poco más atractiva en cuanto a su presentación.


Consideraciones en general

Mas allá de que estas tecnologías nos ofrecen ciertas ventajas a la hora de desarrollar, por otro lado, la organización de nuestros estilos es tan o más importante que las ventajas en sí. Al final del día, que nuestro css logre ser mantenido y comprendido por todos los integrantes de nuestro equipo también es un objetivo a cumplir. Particularmente, nos estamos sumergiendo en la implementación de una guía de estilos

El hecho de que Less haya sido elegido por Bootstrap hizo que muchos se inclinaran por este pre-procesador, pensando en el "aval" que esto le daba. Sin duda le ha dado más y mejor prensa.

Por su lado Sass tiene el soporte de Google que por supuesto representa también un respaldo importante.

Sobre Sass hay varios pre-conceptos que suponen cosas como que es necesario tener un manejo avanzado de Ruby o usar líneas de comando "truculentas"  o cambiar radicalmente la forma de escribir las hojas de estilo. Nada de eso es cierto.

En general al recorrer la web se encuentra más coincidencia en que Sass es más robusto y cubre más necesidades que Less (o al menos de mejor forma).

Particularmente creo que el uso de uno u otro depende de las necesidades de cada desarrollo y las circunstancias en que tengamos que usarlo o la urgencia por empezar a aplicar un pre-procesador como estos.
Algunos de los puntos que es importante tener en cuenta a la hora de elegir:
  • Evaluar el rendimiento de cada uno para servir a los distintos tipos de necesidades del proyecto
  • Tener clara la guía de estilos y las necesidades del front end
  • Evaluar la curva de aprendizaje
  • Tener conocimientos previos de CSS
  • Recurrir a la documentación ofrecida por ambos

Links donde encontrar más información


Sobre comparaciones ambos pre-procesadores estos dos links me parecieron muy interesantes:


Para quienes quieran empezar a ver Less:  

Sobre Sass y Compass: Introducción a Saas y Compass  (en español)














Leer más...

Entendiendo la Deuda técnica

lunes, 22 de septiembre de 2014

Más de una vez nos ha pasado de estar en la encrucijada de tener que decidir si resolvemos una funcionalidad de la forma más rápida pero no tan ordenada o elegante - aún sabiendo que en algún momento habrá que modificarlo , o hacerlo más ordenado y prolijo pero sabiendo que llevará más tiempo en terminarse.

Cualquiera de las dos opciones tiene sus consecuencias pero podríamos decir que en muchas oportunidades la urgencia del cliente tiene mucho peso y terminamos decidiendo por el camino más corto.

Ese tipo de soluciones - que trasladan al futuro cambios que pueden ser más costosos que haberlos implementado en el momento -  pueden considerarse deudas técnicas y las mismas pueden resultar en altas tasas de defectos, baja velocidad de respuesta, baja calidad del producto, baja productividad, problemas de mantenimiento, entre otros. Y no debemos olvidar los costos en el presupuesto.

Las deudas técnicas pueden estar relacionadas con distintos aspectos del desarrollo: algunas pueden ser debido al código (código repetido, complejo, difícil de entender y mantener, etc.), al entorno de desarrollo, la plataforma usada, el diseño, testing automatizado y demás.

Ward Cunningham utilizó una metáfora comparando este tipo de problemas del desarrollo de software con una deuda financiera. Es decir, queremos pagar la deuda con sus intereses en el futuro o pagamos el costo completo en el presente?

Esta metáfora también "justifica" que en determinadas circunstancias la elección de la solución rápida puede ser la adecuada cuando, por ejemplo, se quiere aprovechar una oportunidad de mercado, lo que en el desarrollo de software podríamos traducir como llegar a una fecha límite.

Creo que el mayor dilema en estos casos es saber cómo administrar las deudas técnicas y tratar de determinar a qué tipo de deuda nos estamos enfrentando para tener idea de la gravedad de la misma.

Algo que puede ser útil para esto es el Cuadrante de la deuda técnia creado por Martin Fowler.

Este cuadrante podría usarse para decir qué tipos de deudas son aceptables o no y usar esta información para establecer tácticas que nos permitan prevenir conductas o patrones inaceptables.

Fowler dice que, en realidad, la gran elección no es si tener o no deudas ténicas, sino que la decisión está en tomar Deudas Prudentes o Deudas Imprudentes. Además de determinar si son Deliberadas o Inadvertidas.

Una deuda Prudente y Deliberada se da cuando el equipo sabe que está incurriendo en esa deuda y supone una evaluación del costo futuro vs. el costo actual. Este tipo de deuda se considera "positiva" y su administración se hace más simple.

Las deudas Prudentes pero Inadvertidas suelen darse en casi todos los proyectos, dado que a medida que se va desarrollando los miembros del equipo van haciendo un aprendizaje que les permite darse cuenta que hay cosas que podrían haberse hecho mejor. Mucho más se da este fenómeno si el equipo cuenta con miembros menos experimentados. En estos casos lo importante es "pesar" si vale la pena corregir lo ya hecho o qué cosas puntuales sí deberían modificarse, según el impacto que puedan acarrear.
Para Fowler este tipo de deudas son inevitables y desde el inicio del proyecto todos deberían estar advertidos de su posible aparición.

Las deudas imprudentes suelen ser tomadas por equipos que desconocen las prácticas de diseño dado que no tienen la capacidad de evaluar cuál será el costo futuro.

Una deuda imprudente y advertida puede ser un caso muy peligroso. Se da cuando el equipo, aún teniendo conocimientos de buenas prácticas, decide que escribiendo un código más limpio no puede cumplir con los tiempos requeridos. Son muchos los factores que pueden llevar a tomar esta decisión:

      • mala gestión, 
      • presiones innecesarias, 
      • problemas en el equipo interno, etc..

Acumular este tipo de deudas implica que la calidad del producto va a ser muy baja.

Por otro lado, el creer que escribir un código desprolijo es más rápido que hacer un código limpio es un error.
La aplicación de las buenas prácticas tienden justamente a que el desarrollo sea, a la larga, más rápido y el código mucho más confiable.

Las deudas imprudentes no deberían ser, además, inadvertidas porque la acumulación de las mismas llevaría al fracaso del proyecto. En general este tipo de deudas salen a la luz por inexperiencia o falta de conocimientos del equipo o de los responsables.
Ocurre en general cuando los desarrolladores no tienen noción de las implicancias de cambiar una parte del código. Este tipo de deudas deben ser administradas con mucho cuidado.

Srinath Ramakrishnan en su artículo Managing Technical Debt sugiere la utilización de herramientas como pair programming, code reviews, integración continua, testing automatizado, etc.:

"La clave para administrar deudas técnicas es estar constantemente vigilante, evitar usar atajos en el código, usar diseños de aplicaciones lo más simple posible, hacer refactoring frecuente. "


Artículos de interés:

Managing Technical Debt
When code is considered Technical Debt
Technical Debt
Deuda Técnica
Uso de técnicas agile para pagar la deuda técnica
La mala calidad del software al final se paga










Leer más...

Desarrollos Sitecore® en Latinoamérica

viernes, 19 de septiembre de 2014

Tal como contamos en nuestro sitio, una de las áreas de negocio a la que venimos abocándonos desde algunos años es el desarrollo de aplicaciones sobre la plataforma Sitecore®, lo que nos convirtió en uno de los pocos equipos de desarrollo en Sudamérica en dedicarse a la misma.

Dado que Sitecore® es, en su concepción más básica, una herramienta pensada para la construcción de sitios web corporativos e intranets, nuestro trabajo como desarrolladores consiste en la implementación de la plataforma, configuración de la arquitectura necesaria, integración de la misma con servicios externos y soporte sobre actualizaciones, entre otras tareas, de forma que los equipos del cliente puedan encargarse de la administración de los contenidos y estrategias de marketing.

Qué es Sitecore® 

Si bien Sitecore® nació como un software de gestión de contenidos, al día de hoy su punto más fuerte radica en las ventajas que ofrece al área de marketing, y se ha constituido como una de las más sólidas herramientas empresariales para la construcción de aplicaciones web, intranets y software de Automatización de Marketing. Por lo cual, y según su propia definición, Sitecore® es "una plataforma de gestión de la experiencia de usuarios".

Con más de 10 años de posicionamiento en el mercado (su primera versión apareció por 2001), la empresa multinacional danesa que lo creó cuenta hoy con oficinas en lugares como Australia, Suecia, Canadá, Alemania, , Reino Unido, y Estados Unidos entre otros.

Los usos de Sitecore® son variados pero siempre enfocados a la administración de la experiencia de usuarios y funcionalidades de marketing. Con el paso de los años ha ido unificando la actividad de múltiples canales abarcando desde el armado de campañas, seguimiento de la actividad de los usuarios (con la incorporación de los web performance for marketers, por ejemplo) hasta mediciones de performance.

Novedades de la plataforma

En la reciente presentación de los features de la próxima versión "Sitecore® 8 - #SYMNA" en Las Vegas (Sitecore® Symposium 2014) se destacó que el objetivo principal de los cambios incorporados en la herramienta está puesto en el "customer engagement".

En dicho simposio se mostró a Sitecore® 8 como una plataforma con la capacidad de implementar analíticas como base de una "máquina de marketing" personalizada, integrada con múltiples canales. Se agrega la posibilidad de trabajar con segmentación dinámica de audiencias y con testing automatizado que permite optimizar las estrategias de captación de clientes.

Además de una interfaz de usuario más simplificada, la nueva versión avanza sobre una tecnología de marketing altamente focalizada en el target de los clientes a los que apunte cada compañía que la implemente.

En cuanto a la "parte de atrás" de la herramienta, podemos decir que está desarrollada en .NET y permite integración con una infinidad de servicios y plataformas de diverso tipo.

Dada esta característica, otro de los anuncios importantes es que están trabajando en forma conjunta con Microsoft® con la finalidad de dotar a la plataforma de algoritmos de "machine learning" que agregan un valor importantísimo a uno de los objetivos de la herramienta que es el de lograr "enviar el aviso específico a la persona adecuada en el momento justo", es decir, captar nuevos clientes y lograr retenerlos fieles al producto que cada empresa ofrece.

Artículos de interés:

Sitecore Documentation
Sitecore, gestor de contenidos
Sitecore simplifies marketing with newest upgrade, Sitecore 8
Sitecore simplifica el marketing con su última versión, Sitecore 8
Sitecore Experience Platform


Leer más...