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

viernes, 26 de setiembre 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 setiembre 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 setiembre 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...

Trabajo en equipos distribuidos

miércoles, 23 de julio de 2014

Nuestra experiencia en trabajar en equipos distribuidos en distintos lugares físicos fue dándose gradualmente:

  1. pasamos de trabajar en dos oficinas separadas - por una cuestión de calidad de vida de algunas de las personas que tenían mucho tiempo de viaje -,
  2. a trabajar para clientes en el exterior - lo que implicó cambiar nuevamente algunos hábitos laborales -,
  3. hasta ser parte de un grupo de equipos de desarrollo ubicados en puntos distantes del planeta.

En este camino que llevamos recorrido hemos tenido que aprender a adaptarnos y compartir experiencias para poder llevar adelante los proyectos manteniendo el uso de metodologías ágiles.

Siguiendo consejos de quienes ya habían pasado por estos menesteres y aportando nuestro propio conocimiento y sentido común, resumimos en este artículo algunos de los puntos que nos parecen más importantes para considerar en estos casos.

Algunos puntos relevantes

Si bien en las metodologías ágiles la comunicación tiene un rol fundamental, encontramos por allí quienes aconsejan también darle tanta o más importancia a la estructuración del proyecto y la gente que va a formar parte de los distintos equipos. Ese trabajo previo debe llevar a que cada miembro tenga claro el contexto, los objetivos y los roles. En nuestra experiencia esto resultó fundamental.

Considerar algunas características culturales y tratar de unificar criterios de colaboración no sólo entre equipos sino también dentro de cada uno de ellos. Algunos de esos criterios son:
  • Definir metas estándar de distinto tipo (por ejemplo, respecto de la calidad del software, armado de prototipos, criterios de aceptación o del significado de "done", etc.)
  • Definir la frecuencia de control para cada meta, para evitar desvíos o minimizarlos
  • Definir cuándo y cómo se van a realizar las Stand up meetings, quiénes van a estar presentes y cómo se van a cargar las horas insumidas por cada equipo 
  • Definir qué herramientas se van a usar, cómo y en qué casos. Es importante entender que no existe una única herramienta que sirva para todos los fines. Si bien es necesario tratar de minimizar la cantidad de éstas para evitar duplicación de trabajo, tampoco tenemos que forzar que una sola h pueda cubrir todas las necesidades. En este punto puede servir detenerse a pensar:
    • qué necesitamos
    • qué herramientas ya tenemos (o usan los distintos equipos para cubrir esas necesidades)
    • qué herramientas nuevas necesitamos incorporar, qué uso se le va a dar y verificar que no entre en conflicto con alguna de las pre-existentes
  • Invertir en el entrenamiento de todos los equipos para el uso de herramientas, estándares en la codificación, metodologías, etc. permitirá ahorrar tiempo y errores a lo largo del proceso. Y puede ser un buen terreno de intercambio de conocimientos entre los equipos

Otros aspectos a tener en cuenta

Para lograr los objetivos cuando los equipos se encuentran físicamente distribuidos y deben ensamblarse es necesario contar con un rol de alguien que sirva como guía, gerente, scrum master, coordinador o la etiqueta que quiera ponérsele para que se encargue de aunar los criterios de trabajo, la relación con el cliente y la comunicación entre teams. Y por sobre todas las cosas debe asegurarse que los equipos puedan reaccionar rápidamente a los cambios que se presenten.

En otro aspecto, en metodologías ágiles son bienvenidas las habilidades diversas dentro del equipo. Al trabajar con equipos de diferentes culturas y niveles de conocimiento hay que ser muy cuidadosos y optimizar el uso de las distintas capacidades dentro de cada uno de  los equipos y entre los equipos dado que muchas veces pueden darse colisiones. El rol del "administrador" en estos casos es fundamental.


Por supuesto, uno de los aspectos importantes en esta forma de trabajo está referido a la creación y mantenimiento de canales de comunicación que permitan suplantar de la mejor manera los beneficios de la comunicación "presencial" o cara a cara. Pero además es necesario equilibrar la comunicación escrita con la oral para evitar el uso exagerado de una sola de las dos.

En el mismo sentido anterior, el uso de las Historias de Usuario puede tener un apartado especial. Cuando los equipos son tan diversos es posible que la adminstración de las historias requiera un detalle más exhaustivo de lo que un equipo independiente está acostumbrado a usar.
En nuestra experiencia hemos necesitado que las historias o estén complementadas con otra forma de documentación o que sea necesario el uso de una herramienta un poco diferente a la tradicional pizarra para poder llevarlas adelante. Sobre todo, porque hay que tener en cuenta que dados los distintos husos horarios y la integración con tareas hechas por otros equipos, las historias deben considerarse como lugar de conversación y de tracking de necesidades o consultas con otros miembros.
En este sentido una herramienta que nos ha sido muy útil es Assembla.

Respecto de la integración de código, Github es altamente recomendable (How Github works)
Y por supuesto Skype, GoogleDocs y Join.me son también de gran ayuda.

Más artículos de interés:

Distributed Agile: 8 ways to get more from your distributed teams
3 Surprising Reasons Distributed Teams Work Better
Fully Distributed Teams: are they viable?
The Secret Ingredients of a Successful Distributed Team

De nuestro blog:

Trabajo distribuido
Herramientas para trabajo distribuido
Reuniones diarias


(Fuentes de las imágenes:
http://2.bp.blogspot.com/-jUVasDg67s8/Ui6s1sF-MeI/AAAAAAAABho/S7Kv8NZ_yuY/s200/distributed-teams.jpg
http://qablog.practitest.com/wp-content/uploads/2012/07/ID-10064353.jpg) 


        







Leer más...

Documentación ágil

miércoles, 7 de mayo de 2014

En cuántos proyectos nos ha pasado que no encontramos la forma ideal de crear y mantener una documentación que resulte realmente útil?

Cuántas veces tuvimos que recurrir a una documentación para ver "cómo se había definido algo" o "cómo se había resuelto" y no lo encontramos o lo encontramos desactualizado?

(fuente www.freevector.com)
Particularmente me siento muy frustrada cuando pasan estas cosas porque me doy cuenta de lo difícil que nos resulta determinar en qué medida documentar y cómo sostener esto en el tiempo.

En este artículo de Jens Schauber encontré algunos comentarios y tips que me parecen muy útiles para ordenar la idea de la práctica de la documentación durante los proyectos.

Comparto un resumen de lo que dice el autor:

El concepto que me pareció más interesante es la visión que nos da sobre la documentación y que expresa al final de su artículo:
La documentación no debe ser un objetivo por sí misma. Es una herramienta para el entendimiento común y sólo debería ser creada cuando realmente aporta valor a nuestro trabajo. No debemos confundir la herramienta con el propósito que debe tener.
  • Cuando creamos documentación es necesario clarificar el propósito, debemos preguntarnos qué problema esperamos resolver con eso, qué problema trata de resolver esa documentación y resolver ese problema en la misma documentación.
  • Y no sólo eso, cuando se crea una documentación hay que pensar y tener claro desde el principio cómo hacer para mantenerla actualizada. Algo que sugiere Schauber es incluir esa tarea como parte de la definición de "Done! o agendar tiempo a intervalos regulares para dedicar a la misma. 
  • Debemos elegir formas de documentar que sean fáciles de matener: una wiki puede ser una buena idea, documentar en el código puede ser aún mejor.
  • Y algo para tener en claro según el autor: 
"lo que decididamente no sirve es tener largos procesos de aprobación de la documentación, que hará que nadie quiera actualizarlos a menos que sea obligado a hacerlo ...."

Territorios y mapas

Creo que a partir de lo anterior podemos entender mejor algunos de los tips que nos da, haciendo una analogía entre la documentación y los mapas.

Según el autor, una de las utilidades de la documentación es la de servir como guía a los nuevos. Para quienes llevan tiempo trabajando en un proyecto es fácil identificar cuáles son los puntos más importantes, riesgosos o complejos. Alguien nuevo seguramente se encuentre perdido en un territorio desconocido. Tener un "mapa" de ese terreno ayudará a que el nuevo integrante pueda ubicarse y detectar sin mucho esfuerzo los puntos estratégicos, aún cuando ese mapa no esté del todo actualizado.

Por otro lado, aún cuando se conozca bien el territorio, no siempre es fácil determinar la mejor forma de moverse entre dos puntos. Un mapa puede ayudar a darnos una visión más clara y rápida de ese problema.

A veces podemos encontrar en ese territorio "features" que no se sabe muy bien para qué estan.  Poner anotaciones en el mapa ayuda a detectar fácilmente si esos features deben quedar (y por qué) o simplemente son basura que espera ser removida.

Por último, Schauber nos dice que la documentación debe ser usada,
la documentación que no se usa es inútil

Usar la documentación sirve para notar los problemas y, a partir de eso, abordarlos.

Además, la documentación debe ser fácilmente accesible y comunicada al resto: desde imprimir y pegar en las paredes de la oficina las actualizaciones o definiciones más importantes, hasta poner un link en algún lugar al que los involucrados tengan acceso (servers, intranets, etc.)  o enviar mail, usar RSS feeds, etc., debemos buscar la forma de hacer llegar a todos las notificaciones de cambio si queremos que realmente tenga sentido el tiempo que utilizamos en mantener una documentación medianamente actualizada.


Artículo de Jens Schauber (en inglés): The purpose of documentation



        










Leer más...

Cuando la solución es el problema (cómo prevenir la sobre-ingeniería)

lunes, 5 de mayo de 2014

Hace pocos días leí un artículo que me pareció muy útil y cierto sobre algo que podemos reconocer fácilmente como "pecado cometido" en nuestros propios proyectos: lo difícil que resulta determinar cuándo llegamos a un punto en que estamos haciendo sobre-ingeniería o agregando features que no siempre son imprescindibles.

La visión que tiene el autor - Aneesh Karven - y los consejos que da para reconocer y afrontar este problema son muy directos y pueden ser de gran ayuda para empezar a observarnos internamente.
Les comparto aquí un resumen en español del artículo (original en inglés):

Un primer punto a destacar de la nota es que el autor entiende que el problema de muchos profesionales del software es que tienen un "exceso de confianza en la herramienta que usan y les es familiar" (por eso lo relaciona con la Ley del Martillo) lo que hace que piensen que aquello que puede ser la "solución al problema" en realidad resulta ser una exacerbación del problema. Esto hace que se generen features y fixes que dañan más que lo tienen que curar debido a las consecuencias inesperedas que suelen provocarse.

Otra de las cosas que me pareció interesante es lo que Karven sugiere como solución a estos casos de sobre-ingeniería en los que se suele caer. Como punto de partida nos dice que es fundamental un cambio de mentalidad.


Y a partir de este cambio sugiere implementar estos 2 consejos prácticos:

Preguntarse 3 cosas

Cuestionarse varias cosas antes de escribir una sola línea de código. El autor recomienda tener en cuenta estas 3 preguntas de Baumer and Silverman (en su libro When the implication is not to Design)

  1. Podría la tecnología ser reemplazada por un enfoque igualmente viable pero no tecnológico?
  2. Una intervención tecnológica puede resultar en más problemas o daños que los que podría provocar la situación actual ?
  3. Es la tecnología (en este caso) un sustituto "menor" de la solución real a aplicar?

Cambiar la cultura de la compañía 

Según Karven los siguientes valores culturales pueden ser útiles para prevenir la expansión descontrolada de features:

  • Valorar el "no hacer algunas cosas" (o "no hacer cosas"):  aquí sugiere instalar conversaciones dentro de la compañía sobre "MENOS ES MÁS". Considerar qué features se pueden eliminar para mejorar el producto Esta frase que Karven cita en su artículo me pareció muy apropiada: "La perfección es finalmente alcanzada no cuando ya no hay más para agregar sino cuando ya no hay más para sacar." (Antoine de Saint Exupéry)
  • Documentar los caminos NO explorados: para superar la mencionada Ley del Martillo nos sugiere documentar lo que NO SE ESTÁ HACIENDO y por qué no lo hacemos, o sea, tener bien visibles las soluciones NO TOMADAS.


Continuar creciendo

A lo que se refiere en este caso es a lograr un cambio de perspectiva. Practicar esto es "practicar la humildad y precisión". El software, la gente que lo usa y las situaciones que crea pueden ser más complejas de lo que podemos imaginar. Debemos esperar sorpresas y resultados no lineales de cada intervención."
Esta otra frase dentro del artículo expresa muy bien lo que nos quiere decir "mirar en todos los rincones antes de empezar a intervenir.".

Personalmente encontré en este artículo muchos puntos clave con los que podemos identificarnos quienes trabajamos en este ámbito desde hace tiempo y creo que la mayor dificultad está en poder entender claramente que un cambio de rumbo en estas prácticas (a veces no vistas como un problema) pueden mejorar muchísimo el resultado de nuestro trabajo. Es muy común pensar que cuanto más agreguemos y tengamos contemplado dentro de nuestro código, mejor va a ser para el cliente. Pero me pareció muy clara la visión totalmente opuesta que Karven expone sobre esta creencia.

Como dice mi maestro de pintura: "una obra no se termina, simplemente se abandona", lo difícil es tener claro cuál el punto justo para hacerlo.


Este es el artículo original en inglés When the solution is the problem - How to prevent over-engineering & useless features

En el mismo sentido de este artículo, este otro artículo del autor puede ser de utiilidad How to cut features and enjoy it


        


Leer más...

Responsive y Adaptive Design

jueves, 27 de febrero de 2014

Cuando se habla de Responsive y Adaptive web design suelen tomarse como lo mismo.

Pero buceando en la web podemos encontrar 3 visiones diferentes sobre estos términos: los que piensan que son dos cosas muy distintas que no tienen puntos en común ("tengo que elegir entre uno u otro"), los que sostienen que el Responsive Web Design (RWD) es un subconjunto del Adaptive Web Design (AWD) y otros (tal vez los menos?) que consideran que en realidad son dos conceptos que se complementan.

En una definición general podemos encontrar que se habla de Responsive Design cuando se piensa un sitio donde el contenido pueda ser reacomodado según el dispositivo donde se visualiza (desktop, tablet, celular, etc.) enviando siempre la misma información.

Muy genéricamente también encontramos que el diseño Adaptive se define como el diseño pensado en base a los dispositivos donde se visualizará una aplicación, diseñando una versión para cada uno de ellos, haciendo que sea el servidor el que detecte qué dispositivo lo está invocando y enviando el diseño adecuado para el mismo.

Tal como mencionamos, algunas visiones consideran al RWD como parte del AWD, como un subconjunto del mismo. Muchas puntualizan que el Resposive design tiene como objetivo el layout únicamente.

Si bien los dos conceptos tienen en común que se focalizan en permitir que los sitios puedan ser vistos en dispositivos de distintos tamaños o resoluciones buscando dar una mejor experiencia a los usuarios, Adaptive design es algo más amplio e íntimamente relacionado con la mejora progresiva, cosa de la que el RWD tampoco está ajeno. Es por ello que hay quienes consideran que ambos conceptos se complementan. Personalmente me inclino más por esta visión.

El AWD es un concepto más abarcativo y, según la definición de su creador Aaron Gustafson, utiliza mucho de los componentes de la mejora progresiva (PE - Progressive Enhancement) que se focaliza en el uso de los métodos de diseño necesarios que apunten al usuario y no a los browsers, donde el RWD debería ser una parte, pero siempre teniendo en cuenta  que el AWD es un "acercamiento más holístico del diseño web".

Desde el punto de vista de los usuarios de los sitios que desarrollamos, poco sabrán ellos sobre qué métodos fueron usados para crearlos. Sólo buscarán poder navegarlos de la forma más simple, rápida y clara desde cualquier "aparato" que se los permita y si no, simplemente los abandonarán. Es por eso que las herramientas y métodos que usemos en su creación deben llevarnos siempre a satisfacer de la mejor forma posible las necesidades de dichos usuarios.

Tomar lo mejor que cada uno nos brinda para lograr este objetivo puede ser una buena idea ...

    


Leer más...

Uso de texto en lugar de imágenes (icon fonts)

lunes, 24 de febrero de 2014

Desde hace ya un par de años una de las prácticas instaladas en desarrollos web es el uso de fuentes tipográficas en lugar de íconos o pequeñas imágenes o incluso sprites css. O sea, se manejan los íconos como textos lo que permite cambiar sus propiedades usando CSS.




El uso de estos “icon fonts” (icon web fonts) presenta muchas ventajas respecto de otras técnicas de inserción de imágenes dado que disminuyen la carga del servidor y las peticiones HTTP, no son tan complejos de implementar como los sprites, son adaptables a distintos dispositivos (los íconos pueden verse pixelados al cambiar de tamaño), se puede cambiar fácilmente sus propiedades, entre otras.

Varios son los sitios donde podemos encontrar conjuntos de font-icons – gratuitos y pagos - y abarcan una enorme variedad de temas. Algunas de estas colecciones hemos aplicado en nuestro web site.

Recomendamos aquí muy buenos artículos donde pueden leer más detalles sobre su implementación y sitios desde donde descargar colecciones:

CSS Tricks

(imagen: htttp://commons.wikimedia.org/wiki/File:Early_writing_tablet_recording_the_allocation_of_beer.jpg)

    
Leer más...