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 :)

Teniendo en cuenta que hay gente apuntada al curso que tiene que ya ha hecho cositas con estas y otras APIs creo que lo más enriquecedor sería abrir un debate entre todos los asistentes sobre modelos de interacción entre móvil y aplicaciones (web o no), patrones, qué es útil y qué no.

Y justo después... fiesta unvlog!!

Todavía estás a tiempo de apuntarte.

La idea partió de María, y ella os explica mejor que yo de dónde ha surgido la idea y cómo nos hemos metido en este lío. Es el primer desarrollo grande fuera de the cocktail que hago con ella y ha sido tremendamente enriquecedor.

En la parte de desarrollo el que ha partido la pana ha sido Blat. Cualquier cosa que diga sobre él se queda corta.

En estos proyectos personales donde se barajan ilusiones pero no dinero es imprescindible poder ser totalmente transparente con tus compañeros para que puedan saltar de 'servilletas en los bares' a realidades más o menos ambiciosas.

Lo que sabemos: El proyecto se nos ha ido haciendo muy grande durante el proceso de creación. De hecho ha sido largo y con miles de pequeñas batallas sobre cómo hacer esto o aquello.

Finalmente, sabiendo que no está todo hilado y que tenemos casi tanto camino por recorrer como el que ya hemos recorrido, hemos sacado una beta. Somos conscientes de que tiene miles de carencias a todos los niveles, pero es la única manera de empezar en este tipo de proyectos. Además las críticas del entorno, de la gente que escribe sobre el proyecto y de la que escribe en el proyecto son muy útiles unas veces para descubrir dónde te has equivocado y otras para confirmar lo que ya sabías.

Esto significa que durante los próximos meses iwanna se irá transformando y mejorando para hacer la experiencia de uso mucho más agradable.

Lo que nos gustaría: Puestos a mirar alto nos gustaría llegar a ser una guía de viajes completa, muy completa.

El componente social se convierte en algo importante, pero tal vez no apto para los colonizadores de amigos en redes sociales. En iwanna no tiene sentido entrar, añadir y esperar. Para que la aplicación empiece a ser útil y se puedan crear rutas interesantes un buen puñado de usuarios tiene que haber contribuido con información.

Postear no es fácil si se busca aquella información que te hubiese gustado encontrarte en una guía, con toda la carga subjetiva que eso supone.

Sólo tras unos meses de rodaje y mucho trabajo sabremos si funciona o sólo ha sido una bonita experiencia.

A título totalmente personal. Sé que tenemos muchos puntos tangentes con otros proyectos y que las comparaciones son inevitables. Hemos querido construir por encima de todo una guía de viajes colaborativa, no un directorio de empresas, no un lugar donde la gente cuente sus viajes como una experiencia global. Nuestra primera tarea es resaltar nuestras diferencias y eso nos va a ayudar a evolucionar como servicio.

Esperamos veros por nuestra iwanna :)

No sólo se han currado el organizar la fiesta, sino que además han hecho videoconvocatorias. Por aquí la de isabl + xurde:

Y por aquí el gran gorriti.

Así que nos vemos el 3 de julio en Sideral Club, en Madrid!

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í!

Hoy es un día de esos en los que sueltas al mundo algo en lo que has puesto mucha ilusión, y la verdad estoy muy contento :)

Hace un puñao de meses alberto puso este twitt. En un par de días blat, alberto y yo estábamos en un bar (donde se forjan los proyectos de verdad) hablando de esto. Alberto tenía una idea, y nosotros podíamos construirla.

Y así al final cada uno hemos puesto nuestro pequeño granito de arena, pasando por épocas buenas, malas e incluso un agosto hemos ido haciendo unvlog. A todo este esfuerzo se han unido las ilustraciones de dos señores estupendos como son dani (arriba) y puño (abajo). He de decir que todo el mundo flipa con las ilustraciones (tweet) y no es para menos.

Hace muy poquito empezamos con las cuentas para amiguitos, y fue cuando empezamos a notar que todo el cariño que se había puesto en el proyecto venía de vuelta cuando gente que te importa y a la que respetas habla maravillas (me dejo tweets, lo se).

Como colofón a tanta felicidad el viernes presentamos a la criatura en sociedad. Esperemos que nos acojan con el mismo cariño que todos los que ya habitan vuestro unvlog.

Ahora a divertirme. Jugando con la api de youtube vemos que podemos conseguir lo básico para poder tirar de su información con nuestra aplicación. Tenemos una gema que nos hace la vida más fácil.

Lo único que no nos devuelve la api de youtube directamente es la url del flv que va a cargar su player. No es que nos valga para muchas cosas, pero en casos concretos nos puede interesar (nah, nada de detalles).

Pongamos el caso de la url este video. La anatomía de la url (http://www.youtube.com/watch?v=0xaX7ZfX054) nos da la id del video, y incluso sin tirar de la gema sabremos que la url del player es http://www.youtube.com/v/0xaX7ZfX054.

La url directa al flv no es tan intuitiva de construir.

http://www.youtube.com/get_video.php?video_id=la sabemos&t=token de youtube a averiguar

Así que con un poquito de ruby (y definiendo un método string.to_hash):

require 'open-uri'
 
 class String
    def to_hash(seperation='&', assignment='=')
      hash = Hash.new
      self.split(seperation).each do |elemement|
        pieces = elemement.split(assignment)
        hash[pieces[0]] = pieces[1]
      end
      hash.delete_if { |key, value| value.nil? }
    end
 end
 
 
 def get_flv(url)
   getparams = nil
   open(url) {|f|
       getparams = f.base_uri.request_uri.split("?")[1]
   }
   unless getparams.nil?
     parameters = getparams.to_hash()
     url = "http://www.youtube.com/get_video.php?video_id=#{parameters['video_id']}&t=#{parameters['t']}"
   end  
   return url
 end

Así con una simple llamada a get_flv('http://www.youtube.com/v/0xaX7ZfX054') nos devolverá la url al flv.

A disfrutar!

Echadle un vistazo a nuestra página de empleo y si tu perfil encaja (más o menos) con lo que pedimos ya estáis enviándonos el curriculum!! Y si no encaja envíalo igual, siempre estamos abiertos a conocer a personas interesantes.

El proyecto se basa (basaba más bien) en la creación de un interfaz para el blogueo de mapas tomando como base google maps y como público aquellos que nunca tocarán una línea de su api. He perdido muchas horas definiendo la interacción, y una cantidad vergonzosa de tiempo desarrollando adelante y atrás, empollando apis e incorporando ideas.

Y el perfeccionismo mató a la idea.

Ahora existe la opción de 'mis mapas', que lejos de quedarse en un pequeño servicio, va creciendo en funcionalidad a pasos agigantados, así que la posibilidad de bloguear un mapa desde el propio google es cuestión de tiempo, y es totalmente imbatible.

Duele un poquito decidir que quieres dejar de hacer una cosa a la que le has dedicado tantísimo tiempo y de la que has hablado a la gente que te importa, pero es necesario cerrar los viejos proyectos antes de afrontar los nuevos.

Esta decisión se me hace un poquito más dramática porque la he tomado mientras terminaba de crear una cuentas de prueba para los sospechosos habituales (esos que me importan) y que iban a ser convenientemente enviadas esta semana.

Acaba de subir la revisión 779 al repositorio, y ahí quedará para recordarme que la próxima vez debo de ser más rápido.

De todo esto queda una bonita experiencia, un camino de aprendizaje que no siempre ha sido fácil y un plugin para rails :)

Esta release (totalmente beta) la podeis instalar en vuestro mephisto:

Si quereis curiosear código pasaos por este svn (si dreamhost os deja).

Creo que no hace falta decirlo, pero cualquier feedbak será bienvenido.

He hecho un plugin para el sistema de blogs mephisto. El plugin funciona poniendo en relación artículos por medio de sus tags. Esta funcionalidad (tontísima) es bastante útil si eres más o menos disciplinado con los tags de tu blog.

Por defecto saca los últimos 5 artículos que tengan 2 (o más) tags coincidentes, pero estos parámetros se pueden configurar.

En próximos días lo pondré en un repositorio de plugins (o al menos público), pero para eso hacen falta pulir dos cositas:

• Hacer los tests de rigor (para lo que necesito engañar a blat)
• Solucionar el caso en el que no hayan artículos relacionados.

Mientras tanto lo podéis ver en acción en madeonvinyl.

A pesar de todo, si alguien con mephisto lo quiere probar que me de un silbidito que se lo paso.

Se parece bastante a lo que pretendía ser el always procrastinated smupf (hijos, ahora volveré a tratar de centrarme y reconducirlo).

Que google permita hacer mapas con la pedazo de api que tiene por detrás, y con las posibilidades que nos permite aplicando un poquito de imaginación, no sorprende (pronto saldrá el experimentos que hicimos para el taller de apis, vease imagen).

Lo que me sorprende es que usen 'tu' en cursiva :)

Posteado desde MarsEdit.

El jueves en Madrid, en pleno centro, los cocteleros celebramos la salida de la nueva coctelera, y no queremos que se lo pierda nadie, así que apúntate, que vamos a ir todos.

Antonio Martinez le dijo a unos amigos que se apuntasen con él a la fiesta, que los cocteleros somos mu buena gente, y al día siguiente quedó encerrado con una sueca en el ascensor de su edificio, que desde entonces se ha convertido en la mujer de su vida.

Leonardo García pasó de la fiesta de la coctelera y al día siguiente pisó una caquita de perro, le rayaron el coche y cuando fue a almorzar como cada día NO QUEDABA TORTILLA DE PATATAS!!!

Tú mismo ¿no te apuntas?

Si te interesa el tema de las APIS, no puedes faltar. El taller hablaremos:

• Carlos, de nvivo.es, que nos hablara de las apis de MusicBrainz, Last.fm/Audiscrobbler y MyStrands/OpenStrands.
• María, mi gran compañera de mesa y maquetas, de limalimon.com.es y the-cocktail.com, que trabajará sobre la api de Flickr
• Y yo mismo, the-cocktail.com proud member, que contaré cosas de la de GoogleMaps

El taller es abierto (aunque el aforo limitado, apuntate!!).

Más información e inscripciones por aquí .

La librería que liquid incorpora por defecto nos permite hacerlo de esta forma tan sencilla. Dentro del bucle de comentarios se pone:

 {{ comment | gravatar:40,'avatarpordefecto.png' }}
 

Es una tontuna, pero es mucho más fácil que hacerlo desde cero (que es lo que me había planteado :) )

En este caso vamos a jugar con la opción que tiene para 'arreglar' inputs de html que vengan un poco escacharraillos ¿quién no se ha dejado un div sin cerrar? Pues esta gema nos va a ayudar a dejar el código limpito de verdad.

No descubro nada que no esté en la documentación, pero es que me ha parecido genial.

Cojamos el código a parsear, bien desde un archivo:

doc = Hpricot(open("tudocumento.html"))
 

Bien desde una variable:

doc = Hpricot(param[:mivariable])
 

Tenemos dos opciones. No toques mi código, sólo cierra lo que esté abierto:

doc = Hpricot(mivariable_o_documento) { |f| Hpricot f, :fixup_tags => true }
 

O bien cierra todo lo que esté abierto, y además convierte mi código en xhtml estricto:

doc = Hpricot(mivariable_o_documento) { |f| Hpricot f, :xhtml_strict => true }
 

Problemas, los hay. Cuando te enfrentas a un código (pegado desde word, por ejemplo) con 300 niveles de anidación no es capaz de decir más que 'too much stack levels'. Evidentemente no es el ejemplo más común, para código normal hecho por gente normal y con unos niveles de errores incluso algo bestia funciona.

Me queda comprobar cuánto consume realmente. Es mucho más ligero que otros parsers de html para rails, pero cuando da el 'stack levels' se come tu máquina y la del vecino. Imagino que se podrá controlar pero todavía no se como.

Ahora, para trabajos sencillo es ideal.

Ni Britney Spears rapada, ni youtube, ni myspace ni narices.

De verdad que me alegro mucho de que el proyecto esté funcionando
tan bien hasta ahora en estos poquitos días que lleva en funcionamiento.

Enhorabuena!!

El caso es que una larga historia ha hecho que salga sin diseño y sin otras muchas cosas. Pero como lo importante es poder escribir, iremos posteando y arreglando lo demás al mismo tiempo.

Nos vemos en madeonvinyl.com para estas cosas. Pero antes... no me resisto a postear mi última imagen de vinilos aquí.

Esta mañana he recogido el dunny que ha hecho ejecutado obey, y que no puedo dejar en la oficina porque maggie tendría pesadillas.

Y vamos, creo que ya está todo dicho menos que los errores 500 han desaparecido prácticamente por completo.

Ahora, mi todolist para este blog:

• Volver a postear con normalidad
• Añadir a mi listita de cocteleros a mr lupión, que lo tengo abandonado
• Arreglar la css de una vez :D

Disfruten usándola tanto como nosotros haciéndola.