GIT, y ahora que hago?

Hace ya un tiempo que empezamos a trabajar con GIT y como suele pasar despues de todo cambio positivo, cuesta entender por qué no haciamos esto antes.

Claro, todo esto suena muy lindo, pero no fue tan fácil desde el principio. "Veamos de qué se trata" dijimos y nos encontramos con: repository, local repository, init, clone, stage, commit, pull, push, fetch, merge, rebase, squash, branch, check out, tag, cherry pick… Si, "ya estamos mareados" pensamos, y sólo conocíamos los nombres de estas, que son algunas de las acciones que se pueden hacer con GIT y efectivamente se usan casi todas en lo cotidiano de un equipo de trabajo.

Una vez tomada la decisión, no quedaba otra opción que aprender lo más rápido posible. Buscar información clara y sobre todo en castellano no fue sencillo. Toda la documentación estaba en inglés y por si fuera poco, parecía dedicada a un experto más que a alguien que intentaba aprender cosas básicas como nosotros. Si bien hoy se puede encontrar documentación bastante más clara, decidimos aportar nuestro granito de arena, redactando un breve comentario con las características más usadas.

Repositorio remoto y otro local

Un repositorio de git se puede pensar como una carpeta que contiene información de las modificaciones que se fueron haciendo en el contenido del mismo organizada en comits y ramas, generalmente este repositorio se genera en alguna plataforma online, para poder compartirla facilmente como GitHub, Bitbucket, etc. De ahora en más nos referiremos al mismo como repositorio origen.

Un repositorio local de git no es más que una carpeta en nuestra computadora donde almacenamos nuestro código y una carpeta .git que guarda toda la información del repositorio principal además de una referencia al repositorio origen. Tambien podemos generar un "repositorio origen" dentro de una carpeta en forma local y trabajar con el mismo. La configuración mas común es generar un repositorio en forma online como ya mencionamos y varias copias, distribuidas en los equipos que colaborarán con nuestro proyecto.

Init

Esta acción se utiliza para generar un nuevo repositorio. No es el comando más usado, ya que sólo la usaríamos en dos situaciones.

1. Vamos a crear en repositorio origen en nuestro equipo. 
2. Vamos a generar un repositorio local y luego agregar manualmente la referencia al repositorio origen.

El primer punto puede realizarse ejecutando 'git init --bare' aunque ya discutimos por qué no es lo más común. Mientras que el segundo que cuenta con dos pasos puede resumirse usando el comando que veremos a continuación.

Clone

Lo más común es que varias personas trabajen en un mismo proyecto, por lo que generalmente se crea un repositorio público, al que todos tengan acceso y un repositorio local en cada puesto de desarrollo. El primero se genera usando ‘git init --bare’ o en plataformas online como vimos en el punto 1 del bloque anterior. En el punto 2 hicimos referencia a este comando que copia el repositorio origen a los puestos que van a colaborar en el proyecto ‘git clone’. Este comando genera un repositorio local con una copia exacta del repositorio origen en una ubicación especificada.

El comando generico para esto es ‘git clone origen destino’, donde origen es el path o url del repositorio origen a referenciar y destino el path donde queremos almacenar nuestra copia.

Fetch y Pull

Ambos comandos son utilizados para actualizar nuestro repositorio local con los datos del repositorio origen. El primero Fetch ‘git fetch –all’ actualiza sólo la carpeta .git, con lo cual podemos saber qué cambios hubo sobre el repositorio origen, pero no podemos interactuar con ellos ya que nuestro entorno de trabajo no fue modificado. Es como tener una foto del estado actual. Mientras que con el segundo ‘git pull’ se actualiza todo el repositorio, tanto la carpeta .git como nuestro directorio de trabajo y todos los archivos contenidos por el mismo. Después de ejecutar este comando, no sólo conocemos el estado del repositorio remoto, sino que somos capaces de interactuar con todos los cambios realizados por cualquier colaborador en el repositorio principal.

Hasta este momento sabemos cómo generar un repositorio, mantenerlo actualizado y sincronizado con un repositorio origen o remoto. Supongamos ahora que hicimos una modificación al proyecto y queremos que los demás lo puedan ver. Para esto tenemos que seguir una serie de pasos que se comentan a continuación.

Stage y Commit

Lo primero es generar un paquete con nuestras modificaciones y agregar una descripción del trabajo realizado, todo esto se conoce como 'commit'.
Después de modificar uno o más archivos, los mismos se encuentran en un estado ‘Dirty’ o sucio y para que formen parte de un commit, tienen que pasar por una etapa de stage, cuando hacemos esto estamos generando una imagen de estos archivos y esta información se almacena en la carpeta .git. Supongamos que agregamos un archivo test.txt a nuestro directorio de trabajo, antes de generar un comit ejecutamos 'git add test.txt' con lo cual agregamos este archivo al area de stagging.

Todavía la historia de nuestro repositorio no se modificó, para esto debemos confirmar los cambios que fuimos sumando al area de stagging y agregar un mensaje. Esto se conoce como 'commit' y ejecutando 'git commit -m "mensage"' lo generamos.

Ahora si, después de confirmar los cambios y agregar el mensaje, podemos ver como la historia de nuestro repositorio, se modifica y aparece el nuevo commit.

Push

Lo que nos falta hacer es compartir nuestro trabajo con el resto de los participantes del proyecto y para esto nuestros commits deben publicarse al repositorio origen. Para lograrlo es que usamos el comando ‘push’. Esta es la única acción de las realizadas hasta el momento que modifica el contenido del repositorio remoto.
Simplemente ejecutando ’git commit origin master’ logramos que nuestros commits viajen hasta el repositorio origen, modificando la historia del proyecto que todos ven. Una vez hecho esto, el ciclo vuelve a comenzar.

Este es un acercamiento básico a GIT que esperemos ayude a clarificar algunas dudas, Si bien comentamos las acciones basicas que funcionarían bien en un proyecto con un solo desarrollador, el proceso puede complicarse al agregar participantes

Otras entradas de nuestro blog sobre este tema:

Git submodulos anidados


Puente entre TFS y Git

Obtener version de Git tag desde CCNET

Empezando en Git ...

Git, paquetes Nuget y caracteres de fin de linea

Twittear Seguir a @3p_ar

Leer más...

Javascript: Escribiendo buen código

Ya sea porque recién comenzamos o porque necesitamos garantizar la efectividad de nuestros javascript, es necesario conocer que herramientas tenemos al alcance de la mano que nos ayuden a escribir buen código: quizás hayan leído o escuchado acerca de JsLint y JsHint, hoy vamos a hablar de ellos

Sin entrar en mucho detalle, ambas son herramientas que nos van a permitir validar nuestro javascript y asegurarnos que cumpla con determinadas reglas. En el caso de JsLint es un poco restrictivo acerca de su configuración y JsHint es un fork del anterior muchisimo más pulido, flexible y hecho por y para desarrolladores.

Con respecto a las reglas, podemos decirle a los validadores que tengan en cuenta aspectos como los siguientes y nos alerte al respecto:

• Si tenemos variables que declaramos y no usamos
• Si no usamos algún parámetro en una función
• Comentarios del estilo TODO
• Existencia de sentencias de debugging (console.log)
• Comparaciones con == o != (No estríctas)
• Cuando no usamos { } para separar bloques if (Por más que tengan una sola línea)
• Si usamos funciones dentro de ciclos
• Etcétera

En el sitio de JsHint, hay un apartado partícular que nos enseña como incluirlo para que sean de utilidad en nuestros proyectos. Hay muchas implementaciones y se encuentra en los entornos de desarrollo más utilizados

Casos que analizamos

• Constructores

 var cat = new Object();
    cat.name = "Nacho";
    console.log(cat.name);

En este caso, las herramientas nos recomiendan que la notación literal de objetos es más adecuada

 var dog = {
        name: "Benji",
        getName: function () {
         return this.name;
  }
   };
    
    console.log(dog.getName());

Ventajas: Menos código, más claro a simple vista, menos repetitivo si debemos agregar propiedades y funcionalidad

• Comparaciones

var a = 1, b = 2;

if (a = b) { 
  console.log(1);
} 
else { 
  console.log(2);
}

Javascript no espera que ocurran asignaciones dentro de bloques condicionales. Es más probable que la verdadera interpretación deseada sea if (a == b) o if (a === b)

Ambas herramientas alertarán al respecto y es configurable bajo la característica: "About assignments inside if/for/..."

• Comparaciones de tipo al usar == y !=

  var gato = {edad:2};
   var perro = {edad:2};

   if(gato.edad == perro.edad){
    console.log("iguales");
   }
   else{
    console.log("diferentes");
   }

   // Muestra iguales

   perro.edad = "2"; // Convertimos el valor 2 en un string que tiene un 2

   if(gato.edad == perro.edad){
    console.log("iguales");
   }
   else{
    console.log("diferentes");
   }

   // Muestra "iguales". Porque Javascript internamente está haciendo una conversión de tipos              
   // para que ambos valores sean comparables. Entonces 2 será igual que "2"

   if(gato.edad === perro.edad){     // Comparamos estrictamente: Valor y tipo
    console.log("iguales");
   }
   else{
    console.log("diferentes");
   }

   // Muestra diferentes

   perro.edad = 2.0; // Asigno un valor con decimales

   if(gato.edad === perro.edad){
    console.log("iguales");
   }
   else{
    console.log("diferentes");
   }
   // Muestra iguales. Por qué? Porque Javascript no reconoce "subtipos", ambos son  
   // numéricos y por ende iguales
 

Ambas herramientas permiten configurar si nos alerta o no en caso de no usar comparaciones estrictas

• Cuidado con la coma

    var json = {
       hola: "hola",
       como: "como",
       estas: "estas",
       numero: 1,          // La última coma no es necesaria, pero generalmente no muestra error
   };

La coma ubicada en algunos lugares de nuestro código sin ningún propósito puede generar errores en algunos navegadores. JsLint alerta siempre en este caso

• ++ y --

JsLint posee la capacidad de no permitir dichos operadores argumentando que es una práctica que alienta astucia innecesaria y hace trabajar de más al compilador

   var num = 2;
   console.log(++num);     //3
   console.log(num++);     //3

El código anterior no valida, en JsHint si lo hace

Donde realmente creo que tenemos un problema es en los ciclos, por ejemplo, el siguiente código no es válido

   for (var i = 0; i < 10; i++) {
           console.log(i);
   }

Primero, porque especifica que las variables deben estar antes de bloques de código, quedando así

     var i;

   for (i = 0; i < 10; i++) {
       console.log(i);
   }

Y segundo por el ++ del incremento final. Esta regla no es muy útil creo, JsHint la conoce y no genera error.

• Salto de linea

¿Cual es la diferencia entre las siguientes funciones?

function sayHello(){
 return {
  a:'hola'
 }; 
}

function sayHelloAgain(){
 return
 {a:'hola'}; 
}

A simple vista parecería que son iguales, la diferencia reside simplemente en el salto de linea del return ¿Pero acaso esto podría ocasionar algún problema? Si recordamos que en javascript el salto de linea es interpretado como el fin de una sentencia podemos inferir que la función no va a retornar lo que esperamos. En otras palabras return va a ser interpretado como una sola sentencia y el resultado de hacer sayHelloAgain() va a ser undefined ¿Que macana no? Afortunadamente tanto JsLint como JsHint nos pueden ayudar a evitar este tipo de errores. En este caso en particular lanzando una advertencia por el salto de linea o también de ausencia del punto y coma (dependiendo que reglas hayamos elegido).

En resumen, dada las ambigüedades de javascript contar con una herramienta amiga que nos ayude a no caer en ciertos errores es de gran utilidad (sobre todo por los dolores de cabeza que nos ahorramos). Si desean probar algunas de las validaciones sin instalar nada pueden hacerlo desde las respectivas paginas oficiales  de JsLint y JsHint.

Ir a JsLint
Ir a JsHint


Twittear Seguir a @3p_ar

Leer más...

¿Se aplica "testing ágil" con metodologías ágiles?

Todos sabemos de qué estamos hablando cuando decimos “proyectos ágiles”. Ahora, ¿Cuándo hablamos de testing, decimos también “testing ágil” ?

Es sabido que ya sea que apliquemos metodologías de trabajo tradicionales o ágiles, los procesos de desarrollo de aplicaciones requieren tareas básicas, a grandes rasgos: análisis, construcción, pruebas, corrección de bugs, implementación. Pero uno de los puntos distintivos en las metodologías ágiles es la velocidad de respuesta frente a los cambios, característica no menor.

Las metodologías ágiles se caracterizan por la obtención de resultados hacia el cliente en el menor tiempo posible. Esto implica un cambio permanente en el software, y esto transforma el testing en ágil, lo que a su vez implica un cambio en la estrategia de testing y la vuelve fundamental ya que aporta uno de los valores primordiales en un proyecto de software ágil.

Más allá de las herramientas que se puedan aplicar para las tareas de testing y de gestión de los defectos, lo que quiero puntualizar en este artículo es la importancia que debe tomar el tester dentro de un equipo. 

Si bien es fundamental elegir las herramientas de apoyo a las tareas de testing desde el inicio del proyecto, tiendo a pensar que la mejor herramienta para un equipo ágil es el conocimiento, la confianza y el valor que tiene el aporte de cada uno. Lograr el fortalecimiento y la fluidez de las relaciones entre los integrantes del equipo, principalmente entre los desarrolladores y testers, es una de las claves para alcanzar con éxito los resultados esperados.

Tomo para ello algunos consejos que leí en este artículo . Cuando los desarrolladores y testers colisionan que me parecieron básicos pero muy interesantes, y que transcribo aquí porque pueden ser de utilidad:

• Dilucidar juntos los requisitos de los clientes
• Construir historias y pruebas unitarias juntos 
• Consensuar cuándo una tarea está lista para pasar a testing para evitar “desencuentros” entre desarrollo y prueba
• Definir entre todos claramente cuándo una tarea se considera como “Done”

Si bien puede sonar algo difícil de poner en práctica, en Tercer Planeta podemos dar fe que este tipo de acuerdos dentro del equipo hacen más fluida la forma de trabajo y con el tiempo se incorporan a un ritmo natural que favorece la relación entre los miembros.
 
Desde mi punto de vista, el "Testeo Ágil", está enteramente relacionado con el conocimiento y aprendizaje de la aplicación por todo el grupo, y fundamentalmente de la confianza que todos los integrantes del mismo le tengan al tester. Además de ser fundamental definir desde el comienzo y entre todos cuál va a ser la estrategia de testing a aplicar y elegir las herramientas que mejor se adapten a cada tipo de proyecto.

El test es una pata MUY importante en el desarrollo de software, vale la pena estar atentos a la evolución del mismo.

Otro artículo recomendado: ¿Como testear un proyecto ágil?

Twittear Seguir a @3p_ar

Leer más...

Team Development for Sitecore (TDS)

En la mayoría de los proyectos de IT estamos acostumbrados a trabajar en distintos ambientes, a pesar de tener infinidad de beneficios, esta forma de trabajo nos obliga a ocuparnos de un desarrollo sincronizado.
Hay dos cosas que necesitan ser sincronizadas en todos los entornos: código y datos. En el caso del código, lo solucionamos utilizando alguna herramienta de "Source Control "(GIT, TFS, etc).

La otra parte del problema es la sincronización de datos, en el caso de Sitecore no sólo nos referimos al contenido del sitio, sino que muchas de las cosas del código (.ASPX, .ASCX, .XSLT) están relacionadas como datos dentro del CMS (Layouts, Sublayouts, Renderings), una práctica común para estos proyectos, es crear paquetes Sitecore, seleccionando todos los items y luego generar un .ZIP.

A partir del Sitecore 6 se incluyo la Serializacion de Items (datos de Sitecore), esto nos permite exportar los datos a un archivo de texto y viceversa. Una vez que tenemos los items de Sitecore en el disco, nos da la posibilidad de incluirlos a un sistema de control de código fuente.
Ahi es donde aparece TDS (Team Development for Sitecore), plug-in para Visual Studio que permite serializar y deserializar items Sitecore para su proyecto directamente dentro de Visual Studio e interactuar con algún "Source Control", pudiendo aprovechar los beneficios que nos brinda: control de versiones, cambios realizados, etc.

Ademas, ahora cada desarrollador puede trabajar con una base de datos local conociendo sus cambios sobre una única base de datos en común, sin necesidad de invertir una increíble cantidad de tiempo en la generación de un paquete para compartir en el resto de los ambientes y poder tener una sincronizacion entre ellos. Esto servirá para centrarse en el código y no en las dependencias.

También nos facilita la comparación entre diferentes versiones de código y si algo que se ha hecho resulta ser un error, simplemente se puede volver a una versión anterior.

Es por eso que destacamos esta herramienta como fundamental y de gran ayuda para este tipo de proyectos, la cual nos ha facilitado mucho el trabajo desde comenzamos a implementarla.

Twittear Seguir a @3p_ar

Leer más...

Las redes sociales dentro de la empresa

Desde hace algunos años el boom de las redes sociales está llevando a las empresas a una nueva forma de comunicación con sus clientes. Esto obliga a, por un lado diseñar estrategias y planes que acompañen y apoyen las campañas de marketing establecidas, y por otro lado a re-pensar la estrategia de comunicación.

Pero qué impacto tienen estos canales en la comunicación interna de la empresa? El uso tradicional de mails, reuniones presenciales o a distancia, intranets, chat, etc. va cediendo terreno frente a los nuevos retos que presenta la necesidad de una comunicación más fluída y "horizontal".  La presencia del microblogging y la red social corporativa en general llega, en mi opinión, para complementar las carencias de los canales tradicionales y adaptarlos a una nueva realidad comunicacional.

Ahora bien, cuáles son las ventajas del uso de redes sociales internas ?

1. Su uso en la vida diaria es ampliamente conocido y difundido, no sólo por las nuevas generaciones. 
2. Son sencillas de usar. 
3. Permiten la comunicación instantánea entre los usuarios en cualquier momento y desde cualquier lugar. 
4. Mejoran la imagen interna de la compañía, fomentando la escucha activa entre todos los niveles jerárquicos.

El valor que los empleados le dan a esta forma de comunicación se basa principalmente en la credibilidad que estos canales despiertan dado que se perciben como más abiertos y francos que cualquiera de los tradicionales.

A mi entender la clave del éxito en la implementación de esta forma de comunicación reside no sólo en el alcance que se le quiera dar a la comunicación interna sino también en la plataforma que se decida utilizar. Este último punto es crucial para no sobre-saturar a los usuarios con demasiadas aplicaciones pudiendo crear confusión sobre cuál usar en cada caso.

Plataformas

Respecto de las herramientas para implementar redes sociales corporativas, algunas empresas optan por desarrollar sus propias redes (basadas fundamentalmente en los conceptos de twitter y facebook), otras se inclinan por herramientas de colaboración ofrecidas en el mercado. En cualquiera de los casos hay que considerar que no siempre es necesario reemplazar las herramientas existentes (como intranets, por ejemplo) sino que la mayoría de las veces lo más conveniente es incorporar los nuevos canales a los que ya estén en uso, precisamente para tomar las ventajas de cada plataforma.

Entre las herramientas más conocidas está Yammer, adquirida por Microsoft en 2012. Pero existen otras como SocialCast, SocialText o CominCorp también bastante difundidas.

Dentro del mundo del OpenSource han aparecido distintas soluciones pero no todas han sobrevivido, muchas de ellas ya no tienen continuidad. Algunas de las que al día de hoy permanecen activas son:

• Status-Net
• Gelato Tumblelog
• JaikuEngine
• ShareTronix
• P2Theme  (no es exactamente una herramienta de microblogging sino un theme de WordPress que transforma la versión standard de WordPress en un sitio de microblogging.
• EcoWaves
• Blurtit

Engagement

Más allá de esto, lo que vale rescatar es que, sin dudas, cualquier mejora en el modelo comunicacional acompañada por la implementación de redes sociales corporativas dará la oportunidad de aumentar la motivación, el compromiso y la productividad, reforzando así la cultura organizacional y la participación de una gran parte de los empleados.


Algunos artículos que nos parecen de interés en este tema:

Microblogging privado en la empresa

La mitad de las empresas usarán las redes sociales ...  

Twittear Seguir a @3p_ar

Leer más...

AngularJS – Experiencia de usuario asegurada

La mejora en la experiencia de usuario en los sitios web, es un camino sin retorno.

Se busca constantemente darle dinamismo a los sitios, además de hacerlos visualmente más atractivos, se intenta que el usuario pueda bucear en la información, sin refrescos de la página ni aparentes demoras.

Esto es algo que se ha buscado desde siempre y de hecho hace mucho que se puede llevar a cabo, las nuevas tecnologías que fueron surgiendo lograron traer simplicidad, y re-utilización del código, ya no tenemos que preocuparnos en hacer llamadas asincrónicas complejas a través  de APIs nativas.

Hoy por hoy existen muchos Frameworks de FrontEnd que permiten simplificar las cosa.

Desde hace unos años en Tercer Planeta nos decidimos por AngularJS y este post es simplemente una invitación que les hacemos a meterse en el tema.

AngularJS es un Framework de FrontEnd / OpenSource desarrollado con JavaScript. Cada vez más popular en la comunidad, no por moda ni nada que se le parezca, el motivo del éxito es su fácil comprensión, desarrollo y por supuesto una notable mejora en la experiencia del usuario.

AngularJS

Ponemos la herramienta sobre la mesa, y les compartimos algunos links de interés para quien quiera empezar adentrarse en el tema:

http://angularjs.org/ - Descargas / Tutoriales y más.

http://www.youtube.com/user/angularjs - Videos y más información.

http://www.lostiemposcambian.com/blog/javascript/angularjs-framework-javascript-para-webapps/ - Un poco de información en español.

Batarang

Por último, queremos destacar además esta poderosa herramienta Batarang.
Un plugin para Chrome, que permite debugear AngularJS:
http://blog.angularjs.org/2012/07/introducing-angularjs-batarang.html

Hoy por hoy una herramienta obligada si se desea utilizar AngularJS.

Twittear Seguir a @3p_ar

Leer más...

Video en HTML5

Hablar de video en HTML5 es hablar de una intensa lucha que se da entre pesos pesados de internet y de la singular batalla por la estandarización de un códec. En años pasados (2004/2005) la manera que tenian los administradores web de compartir videos en sus web era mediante el recordado Quicktime, Windows media player o los archivos .swf que popularizó Adobe.

Hoy en día, apelamos a Youtube o Vimeo para compartir videos y Steve Jobs para sus dispositivos jamás quiso flash así que se reabrió el debate por tener un estándar para manipular video desde los navegadores.

Pensemos en video como las imágenes. Pueden ser .jpg, .png, .gif, pero no dejan de ser una imágen y el navegador es el encargado de implementarlas a todas. Con el video pasa lo mismo.

Cómo se usa?

Para incluir un video con HTML5 usas el siguiente formato:

Además del ancho y el alto y tal como ocurre con la etiqueta <audio>, tenemos atributos adicionales:

• Preload: Carga el video junto con la página. Opción recomendada solo si el video es contenido muy importante en nuestra página

Por el contrario, si es un información secundaria, ¿para que penalizar al usuario con espera si quizás no vea el video?. En este caso usaremos algo como esto:

donde le especificamos al navegador que no descargue información del video a menos que el usuario de Play.

• Autoplay: Esta opción dará play al video automáticamente al terminar de descargarse la página. Lo implementamos de la siguiente manera:

• Controls: Manipula la visibilidad de los controles para el video (Play, Pause, Seek bar y volúmen).

Compatibilidad

Como ocurre con el tag <audio>, necesitamos especificar varios sources para garantizar la reproducción del video en la mayor cantidad de navegadores. Podemos escribir un código similar a este:

De esta manera, con el primer <source> nos aseguramos que el video funcione en el mundo Apple y con la otra apoyamos una versión más liberal empujada por Google.

Con respecto a IE en sus versiones viejas está de más aclarar que no soporta el tag video, pero podemos contar con flash para solucionar nuestro problema: Incluyendo el código embed justo debajo del último <source>, encerrado también dentro del tag <video>

La documentación oficial del tag video está aquí



Existe un proyecto interesante para utilizar y cuanto menos mirar que es VideoJS. Si te vas a tomar en serio la cuestión de alojar los videos en tu sitio y no depender de terceros, este es tu proyecto. Es un proyecto libre y tiene skins para imitar los principales sitios de video de la web.

Twittear Seguir a @3p_ar

Leer más...

Iniciandonos en CSS3

En un principio, las páginas de internet sólo transmitían texto e imágenes y eran en blanco y negro o a lo sumo con muy pocos colores. Hoy no es de esta manera, la web evolucionó y el diseño gráfico no es la excepción. Vamos a profundizar un poquito en este tema: vamos a hablar de CSS


CSS es el lenguaje que se emplea para aplicar diseño visual a los elementos de nuestro documento .html. No es un lenguaje que presente una curva elevada de aprendizaje y posee una sintaxis sencilla. Las letras CSS hacen referencia a Cascade Style Sheets porque los estilos se van aplicando por orden de escritura desde el principio al final. Hoy día continúa en desarrollo pero podría decir que casi no existen limitaciones para diseñar y estilizar un sitio web

CSS: Solución a un gran problema

El .html nunca debe contener estilos. Para eso existen las hojas de estilo: la forma más adecuada de aplicar estilos es mediante ellas. Recordemos que el .html sólo debe contener la estructura semántica de nuestros documentos. Por lo tanto, aislar la presentación del mismo es ideal: permite paralelizar la semántica del diseño y que dos personas o más puedan trabajar cómodamente (Este caso no aplica para los correos electrónicos, pero es un caso aparte)

Por otro lado, al tener asilada la presentación de la semántica, permite que, teniendo una sola hoja de estilos, apliquemos estilos idénticos en diferentes páginas y en todo nuestro sitio muy fácilmente  Pensemos que aplicar un estilo antes era modificar cada hoja que lo usara: hoy modificamos un archivo externo y la solución es inmediata

¿Como empezamos a usar CSS?

• Estilo en línea: aplicamos bajo el atributo style el estilo para ese elemento. No es una manera recomendada, estructurada y óptima de dar formato a nuestros sitios, pero sí sencilla y rápida. No se recomienda usar esta metodología. Como mencionabamos antes, esta regla no aplica para los correos electrónicos, por lo que si queremos aplicarles estilos debemos hacerlos mediante estilos en línea
• Hoja de estilo interna: está incrustada dentro del <head>, marcada por la etiqueta <style>. De esta manera se separa la información de los estilos. Esta técnica tiene el mismo problema que los estilos en línea, deberiamos replicarlo en cada página
• Hoja de estilo externa: es un archivo de extensión .css diferente al archivo donde se almacena el código HTML. Esta es la forma más recomendada porque permite separar el estilo de la estructura

¿Cómo escribimos código .CSS?

La sintaxis de CSS puede resumirse de la siguiente manera:

• Selector
• Propiedad y valor

El selector (en este caso: todas las etiquetas p) hace referencia a los elementos del DOM a los que se le aplicarán los estilos (color de fondo rojo). Estos elementos pueden ser seleccionados en función de su tipo, id, clase y posición, entre otros. CSS en su version actual incluye pseudo clases y pseudo elementos. Pseudo clases son :hover, :active, :visited, etc. Y pseudo elementos son :before, :after, -first-letter, first-line, etc

Propiedad y valor se refiere a que atributo de esos elementos será modificado y que valor se le establecerá. La lista de atributos CSS que pueden utilizarse puede encontrarse aquí

El mismo CSS funciona igual en todos los navegadores?

Hay muchas funcionalidades de CSS que no están disponibles en todos los navegadores y menos en todas sus versiones. Es ahí donde entran en juego los prefijos propietarios (-webkit-, -moz-, -o-, etc). Por suerte existen herramientas que nos permiten hacer compatibles nuestros códigos con todos los navegadores más usados

Para ser más específico hablemos de un caso en particular: múltiples columnas (column-count). Esta propiedad permite dividir y estilizar un texto en columnas

Vamos a can i use y buscamos la propiedad para ver su integración: link acá

La fila que nos interesa es: Current

Como vemos en el gráfico, todos los navegadores modernos y más usados ofrecen soporte para esta funcionalidad, pero algunos no de forma nativa, necesitan de un prefijo propietario (Señalado con una pequeña etiqueta de color amarillo). Este prefijo indica que es una propiedad en desarrollo o que quizás no forme parte del estándar y sea un experimento. Para usar esta propiedad y que funcione en todos los navegadores deberíamos usar un estilo similar a este:

Con -moz- le indicamos al motor de render Gecko que use la funcionalidad, y con -webkit- hacemos lo mismo pero para Webkit. En los demás navegadores, como IE desde su versión 10, la funcionalidad funciona sin ningún prefijo. Si seguimos mirando más arriba en esa misma columna, notamos que para las versiones 8 y 9 de internet explorer la propiedad no está presente. Si nuestro sitio debe ser compatible con estas versiones tendremos que lograr la funcionalidad de otra manera

Lo sé, es incómodo todo esto pero existen herramientas como prefix-free que nos facilitan este trabajo. Prefix free es un script que debemos importar ANTES de nuestros estilos y se encargará de agregar automáticamente los prefijos propietarios. Siguiendo el ejemplo anterior, bastaría con escribir algo como esto:

Y como si fuera poco, existe CSS3 PIE que logra que los features de CSS3 estén disponibles en IE6, 7, 8 Y 9! (Magia negra?)

Espero que esto sirva como un buen comienzo

Twittear Seguir a @3p_ar

Leer más...