Publicidad:
Terra
La Coctelera

Mis Tags > desarrollo

Hay 5 artículos con el tag desarrollo.

Otros artículos en La Coctelera
clasificados con desarrollo

Maquetar para desarrollo

Desde hace meses he ido incorporando de manera bastante natural a mi rutina de maquetación pequeños detalles que ayudan a que el engranaje entre la maqueta y la implementación en un proyecto web sea un poquito más sencillo. La mayoría son obviedades, sentido común fácil de incorporar a nuestro día a día.

Muchos de estos "vicios" los heredé de Álvaro y María y otros los he ido incorporando a base de trabajo y de integrar html en desarrollo, pero sobre todo a base de equivocarme mucho, que también es necesario.

Esto es lo que a mi me funciona, es más que probable que no descubras nada nuevo:

Comentar y tabular:

Un código bien tabulado siempre es más legible independientemente del lenguaje que estemos escribiendo. Si la maquetación se hace en equipo siempre está bien llegar a un acuerdo sobre el tipo de tabulación que se va a usar. Yo me encuentro cómodo con 4 espacios, pero es cuestión de gustos.

Es muy útil marcar con un comentario el final de los divs principales para siempre tener localizado dónde se cierra.

 
     <div id="content">
 
         ...
 
     </div><!-- #content -->
 

Tampoco está de más marcar con un comentario el comienzo y fin de bloques específicos, por ejemplo: <!-- ultimos comentarios --> o <!-- listado de profesores -->

Es la manera más fácil de no volvernos locos al abrir nuestro trabajo cuando ya no lo tengamos fresco.

Primero el marcado, después el estilo:

No hablo de escribirte todo el html de la página que vayas a maquetar, pero es muy fácil identificar los bloques que van a funcionar como unidad.

Pon el esfuerzo en escribir un html limpio y semántico en lugar de ir saltando entre la hoja de estilo y el html desde el principio. A mi esto me da muy buen resultado, pero hay quien prefiere ver una evolución más gradual mientras trabaja.

Mantén limpio tu html y hereda:

Todos hemos pasado una fase de 'classitis' :) Un uso correcto de la herencia nos evita este problema. Al integrar el html la mayoría de los desarrolladores son cuidadosos, pero un código limpio les facilita bastante las cosas, reduce el margen de error y es más sostenible.

Un ejemplo podría ser este:

 
 	<ul id="menu">
 	   <li><a href="#">01</a></li>
 	   <li class="active"><a href="#">02</a></li>
 	   <li><a href="#">03</a></li>
 	   <li><a href="#">04</a></li>
 	   <li><a href="#">05</a></li>
 	</ul>
 

Marcando la clase en el li en lugar de en el enlace podemos actuar sobre dos elementos para componer nuestro estilo 'active'.

Menos no siempre es más:

Se que mucha gente está a favor de poner únicamente el html necesario, ni más ni menos. Yo estoy totalmente de acuerdo siempre y cuando sepamos a ciencia cierta que un cambio en una estructura del html dentro de unos meses no va a generarnos más dolores de cabeza de los necesarios.

Con toda la cautela del mundo, a veces un div de más rodeando un bloque de contenido nos da el juego suficiente para cosas tan básicas como ajustar detalles entre distintos navegadores. Siempre es más fácil añadir un poquito más de CSS que destripar una aplicación en producción.

Aclaro que no hablo más que de un poquito, un elemento para ajustar padding, para dar un sobrefondo en un momento determinado, etc, no estoy justificando un chorro de sobre-html que se pega con la filosofía de mantener el código lo más limpio posible.

Establece algún criterio de calidad:

En todas las fases de un proyecto deberían de haber reglas de control que nos ayudasen a asegurar que nuestro trabajo sea lo suficientemente bueno. El criterio de calidad más usual en el caso de la maquetación es el de validar tanto html como CSS.

Que un código valide no significa que esté bien, pero sí que no se nos ha olvidado cerrar ninguna etiqueta.

Esto nos lleva a otro criterio más, que es probar nuestro trabajo en los navegadores que exija la ruta del proyecto, que por lo general suelen ser 4 - 5.

Yo además, siempre que es posible paso trozos complicados de código a compañeros de trabajo o de fatigas para tener siempre una segunda opinion, que normalmente no es objetiva, pero que nos aporta un punto crítico.

Usa convenciones:

Usar patrones en esquemas básicos que se repiten a lo largo de todo un site nos facilita el trabajo a nosotros y a los integradores.

El ejemplo más fácil de explicar sería el de marcar el elemento activo en un menú. Normalmente tenemos una navegación principal y una secundaria al menos. Pues podríamos convenir que los menús siempre son listas, y que el elemento activo se va a marcar en el li con una clase 'active'.

Minimiza el impacto de los cambios:

Quiérete a ti y a los que te rodean y utiliza todos los medios que tienes a tu alcance para no perder ni tu código ni tu tiempo.

Mete todo tu código en un control de versiones. Da igual el que sea, el que más fácil te resulte o el que menos infraestructura vaya a requerir. Los más famositos son subversion, csv y últimamente está muy e moda git. Dedicale un ratito a aprender los 4 comandos básicos y nunca vuelvas a perder un solo archivo.

Utiliza herramientas que te ayuden a hacer el trabajo mecánico. Todos hemos recibido un cambio en la cabecera en un proyecto en el que ya hay 50 maquetas ya hechas :) Si hacemos un reemplazo masivo corremos el riesgo de cambiar lo que no debemos. Si hacemos el cambio en una sola maqueta y avisamos de dónde está el cambio vía mail / viva voz / paloma mensajera corremos el riesgo totalmente innecesario de que el que finalmente va a trabajar con las maquetas no reciba el recado.

Cualquier método que nos permita trabajar con el concepto de 'include' nos puede valer, pero los más útiles son los que generan html estático. Una buena solución si no le tienes miedo a programar un poquito sería nanoc, que además está bastante documentado.

Intercambia conocimientos:

Habla con la gente que trabaja contigo, intercambia opiniones, trata de conocer sus problemas a la hora de afrontar lo que tú les vas a enviar porque es la mejor manera de que todo salga bien.

Discute con otra gente tus métodos. Hace unos días tuvimos una pequeña reunión varios compañeros para poner en común formas de trabajar y surgieron temas interesantísimos que no salen de ninguna otra manera.

Todos los puntos anteriores son matizables, incluso algunos totalmente prescindibles, pero son un buen comienzo :)

Taller sobre la API de 11870.com

Seguro que ya todos conocéis 11870 y que tienen una API fantástica y llena de posibilidades. La documentación lo pone todo MUY sencillito, pero seguro que te falta un empujón para ponerte a jugar.

La oportunidad de quitarte la pereza de encima viene en forma de taller en sus oficinas (Virgen de los Peligros 3, 3º izquierda). Será mañana jueves 24 de abril a las 19:30.

Tienes que confimarles asistencia :) Nos vemos allí!

La nueva coctelera

Pues sí, ya queda mucho menos para tener la nueva coctelera funcionando. Hemos estado muy ocupados con trabajos de chapa y pintura, y los mecánicos trabajando mucho más a fondo para que los motores de esta nuestra comunidad suenen como los de un rolls roice.

Se que la limpieza de piezas y optimización de engranajes son trabajos muy desagradecidos, porque para conseguir mejoras, a veces pequeñas, en los rendimientos se trabaja mucho y muy duro. Y además siempre hay un tornillo puñetero que se afloja un poquito y que hay que volver a ajustar. Pero seguro que todo el esfuerzo está mereciendo la pena.

En esta próxima entrega encontrareis nuevas funcionalidades interesantísimas, como las portadas temáticas o una página de perfil y amigos mucho más visual y útil. Esto te da la posibilidad de navegar entre personas y descubrir contenidos a los que no habrías llegado de ninguna otra manera.

Una de las novedades que más me ha sorprendido es la página general de últimos comentarios. Un concepto tan simple como ver los últimos comentarios hechos en TODA la plataforma es tremendamente adictivo.

Y muchas cositas más, que son más fáciles de probar que de contar :D

¿Quieres probar la nueva coctelera? Pues es muy fácil, mira aquí, y cuando tengas tus impresiones compártelas con nosotros.

A todo esto, estoy esperando el comentario de uno que yo me se. Te lo pongo a huevo…

DashCode al rescate

He aquí un fan absoluto de picar código, con sus ventajas e inconvenientes. Carlos a esto le llama hacer el pollo, todo el día picando. A ratos muertos estoy desarrollando un widget muy sencillito para el dashboard de OS X.
Me habían recomendado widget factor, pero no acababa de pillarle el punto y al final acabé enganchado a mi adorado textmate haciendo el oso.

Dashboard no es ni más ni menos que un servidor web un poquito especial, y los widgets son pequeñísimas aplicaciones que pueden interactuar con el sistema, con la red, con internet o con otras aplicaciones.

No hace falta dedicarle demasiado tiempo a aprender a desarrollar un widget, no es muy novedoso si estás familiarizado con el desarrollo web. Los archivos con extensión wdgt son carpetas que el sistema operativo tiene identificadas. Si en el menú contextual del wdgt eliges 'Mostrar contenido del paquete' puedes explorar todos los archivos que componen el componente.

Blat me envió un enlace a un post que hablaba de Dashcode, una beta que ha lanzado Apple para desarrollar widgets para su dashboard, disponible en Developer Connection. La herramienta es muy visual, pero permite moldear todo el código generado a manita. Tiene una librería de componentes usuales que está bastante bien y se pueden usar arrastrando encima de tu diseño, y un inspector de elementos bastante sencillo para incorporar comportamientos asociados a eventos.

Hasta aquí nada nuevo bajo el sol.

Hasta ahora todo el test del widget se hacía sobre un navegador, por lo que hasta que no tenías bastante adelantado el desarrollo no podías ver qué tal se comportaba en su entorno final. Muchas funciones relacionadas con efectos, cambios de tamaño, o accesos a sistema hacen que javascript se vuelva un poquito loco, que falle y que todo sea un engorro. Por otra parte, en dashboard no tenemos la posibilidad de ver errores de javascript, así que si algo falla podemos tardar un tiempecito.

Dascode provee de una interfaz de depuración muy práctica. De esta manera conforme vamos avanzando en el desarrollo del código podemos probar el widget en un entorno de desarrollo. Un log nos va informando de todos los pasos que va dando la aplicación y de los errores y alertas. También nos permite insertar breakpoints en el código.

Si es la primera vez que vas a ponerte en harina esta herramienta te vendrá de perlas. Te permite combinar la potencia de escribir tu propio código con un editor visual y un entorno de test. Además si no sabes por dónde empezar en el lateral tienes unos 'workflow steps' que varían en función del tipo de aplicación que vayas a crear.

Seguro que tiene aspectos malos, además es una beta y tendrá fallitos que todavía no he detectado. Pero las primeras impresiones son bastante buenas.

Hoy la cosa va de cursos. El próximo miércoles 25 de octubre, en el aula de la gran corporación, Luis Villa dará un curso sobre microformatos en compañía de Manuel Gonzalez Noriega.

Si quieres venir con las pilas puestas sobre qué son y para qué sirven los microformatos es más que recomendable que leas este post más que didáctico de Luis.

(Esto es un bonito ejemplo de cómo hacer un post con una densidad infernal de enlaces)