Construye tu propia fuente [si te atreves...] FontStruct te lo pone un poco más fácil. Después puedes compartirla con la comunidad.
Si no tienes suficiente paciencia, puedes bajarte algunas de las que ha diseñado la gente. Las hay realmente buenas.
Y para terminar, un ejemplo curioso: cómo dibujar con fuentes
Estamos muy contentos. Enhorabuena a beruby.com
BeRuby Wants to Put Cash Back in Your Pocket via the Web - HispanicBusiness.com
En mayo Ruby ha escalado un puesto en la lista de los lenguajes de programación más populares elaborada por TIOBE, y ocupa ya el puesto 9. Por delante se sitúan Java, C, Visual Basic, PHP, C++, Perl, Python y C#. Por detrás, el resto (que son casi todos, claro). Este índice, elaborado por la comunidad de programación TIOBE, se actualiza de forma mensual y no mide cuál es el mejor lenguaje, ni en cuál se tiran más líneas de código. Lo que mide es la popularidad, y para hacerlo se basa en los resultados de los motores de búsqueda más populares: Google, MSN, Yahoo y YouTube.
El índice TIOBE puede ser útil para adoptar decisiones estratégicas, como elegir el lenguaje de programación más adecuado a la hora de construir un nuevo sistema o aplicación. Puedes ver la lista completa aquí. Más información sobre el índice aquí.
El mercado de soluciones dedicadas a gestionar el rendimiento de aplicaciones Ruby on Rails sigue creciendo y ya cuenta con un nuevo competidor. New Relic ha conseguido nada menos que 3,5 millones de dólares en una primera ronda de financiación, y tratará de hacerse hueco en un escenario hasta ahora dominado por FiveRuns (que, dicho sea de paso, acaba de publicar una entrevista a nuestro compañero Xavier Noria).
El producto de New Relic se llama RPM y, al menos en teoría, proporciona información que los desarrolladores pueden utilizar para detectar, diagnosticar y arreglar con rapidez los problemas de rendimiento de la aplicación. Por el momento, parece que el RM-Manage de FiveRuns incorpora bastantes más funcionalidades (seguimiento de bases de datos, Web daemon, etc.) pero habrá que esperar a las tarifas de New Relic para ver qué es lo que le interesa a cada empresa.
Como siempre, hay quien opina que no es necesario un servicio propietario para realizar estas funciones, y que hay recursos gratuitos suficientes, tipo Query Reviewer. En cualquier caso, el lanzamiento es interesante, no sólo por la inversión realizada (comparable con la de FiveRuns y Engine Yard ), sino porque demuestra que tanto los medios como los inversores están empezando a tener muy en cuenta los movimientos en el escenario Ruby on Rails. De hecho, la todopoderosa Teccrunch se hizo eco de la noticia.
Vía Ruby Inside.
FiveRuns ha publicado la entrevista que me han hecho para la serie Rails TakeFive.
Kelly Waters nos da algunas claves para no perder de vista la visión de conjunto (the big picture) durante el desarrollo de un proyecto ágil. Aquí os dejo una traducción libre:
“Cuando utilizamos un enfoque basado en el desarrollo ágil, no hay grandes especificaciones ni diseños inamovibles. El alcance del proyecto varía. Algunos requisitos evolucionan, y otros nuevos van emergiendo. Las funcionalidades crecen, cambian y desaparecen a lo largo de todo el ciclo de vida del proyecto. En este entorno variable, la cuestión es: ¿qué podemos hacer para no perder de vista la visión de conjunto?
Aunque el desarrollo ágil consiste, en gran parte, en trocear los objetos hasta conseguir pedazos pequeños y manejables -para obtener, por ejemplo, el product backlog y el sprint backlog- es muy importante no perder de vista el contexto global, para que nos sirva como guía y referencia a lo largo de todo el proceso.
Este contexto se nos presenta en 3 formas principales:
Contexto de negocio
ALGUNAS PREGUNTAS ÚTILES: ¿Cuál es la visión de negocio? ¿Cuáles son los retos y las oportunidades desde el punto de vista del negocio? ¿Cuáles son los objetivos de negocio a corto, medio y largo plazo? ¿Quiénes son los clientes? ¿Por qué compran y para que utlizan las solución que vamos a desarrollar? ¿Qué les gusta y qué no les gusta del proyecto? ¿Quién es la competencia y cómo son sus soluciones?
Sin esta información global de contexto, cualquier equipo de desarrollo está trabajando con una gran desventaja. La gente de desarrollo puede ser muy innovadora y si los equipos de desarrollo cuentan con una visión interna real del contexto de negocio, pueden ser mucho más proactivos. Con esta información, es mucho mas probable que las soluciones innovadoras emerjan a la superficie.
Contexto del proyecto
Muchos de los elementos definidos en la fase de inicio de un proyecto tradicional siguen siendo importantes en un entorno de desarrollo ágil.
ALGUNAS PREGUNTAS ÚTILES: ¿Cuáles son los problemas específicos o las oportunidades que el proyecto intenta abordar? ¿Cuál es la visión para el proyecto? ¿Cuáles son los objetivos del proyecto? ¿Cuál es el enfoque? ¿Cuál es el coste previsto y el plazo de entrega? ¿Cuáles son los beneficios y cómo se van a conseguir? ¿Quién trabajará en el proyecto y cuál será su estructura?
Las respuestas a éstas y otras preguntas constituyen una guía de referencia importante para el equipo. Esta guía se hace más necesaria si cabe en un desarrollo ágil, en el que hay libertad para cambiar las cosas durante todo el proceso. Con esta información, el equipo dispone de algunos parámetros con los que trabajar, y tiene claro cuáles son los resultados esperados.
Contexto de la solución
He escrito varios posts sobre cómo escribir buenas historias de usuario. Me gusta que sean tan pequeñas, autoexplicativas y manejables. Hacen que las cosas resulten sencillas. Pero, ¿qué deberíamos hacer antes de llegar al detalle de las historias de usuario? Es importante enmarcarlas dentro del contexto global de la solución. Las siguientes herramientas pueden ayudarnos:
Resumen: Un equipo de desarrollo ágil necesita trocear las cosas en pequeños fragmentos y hacer las entregas de manera incremental. Para hacerlo, resulta especialmente importante tener en mente el contexto general. Mi consejo es que utilices herramientas-guía de alto nivel, ligeras y muy visuales (objetivos del proyecto, mapa de producto, arquitectura de la solución), y las mantengas pegadas en la pared junto con las historias de usuarios y las tareas diarias.
Podéis leer el post original aquí.
Richard Stallman, gurú de la informática y genuino impulsor del software libre, pasó por Madrid hace unos días y dio una conferencia en la que habló sobre la libertad y el usuario. Aquí os dejo un resumen libre, basado sobre todo en la primera parte de la conferencia. Es un poco largo, pero creo que merece la pena. Esta es la controvertida visión de Stallman:
Sobre Richard Stallman. “En el año 83 lancé el movimiento de software libre. El objetivo era, primeramente, desarrollar un sistema operativo libre para que fuese posible usar una computadora en libertad. Este sistema se llamó GNU. Comencé su desarrollo en enero del 84. En el año 92 faltaba un componente importante, el kernel. Otro programador [Linus Torvalds] liberó un kernel que se llamaba Linux. La combinación del sistema completo GNU y el kernel Linux era un sistema completo y libre. Desde entonces es posible (más o menos) comprar un PC y usarlo en libertad, siempre que uses una versión netamente libre GNU Linux, y no instales otros programas privativos.”
Premisa. El software libre es aquel que respeta la libertad del usuario, en contraposición al software privativo, que sume a los usuarios en una situación de inhibición e impotencia. Inhibición porque los usuarios tienen prohibido compartirlo con los demás, e impotencia porque no poseen el código fuente y, por tanto, no pueden cambiar el programa ni saber qué es lo que el programa verdaderamente está haciendo.
Según Stallman, un programa de software es libre si proporciona al usuario las 4 libertades esenciales:
LIBERTAD 0. La libertad de ejecutar el programa como quieras.
LIBERTAD 1. La libertad de estudiar el código fuente del programa y cambiarlo para que haga lo que tú quieres que haga.
LIBERTAD 2. La libertad de ayudar a tu prójimo: es decir, la libertad de distribuir copias del programa a los demás cuando quieras.
LIBERTAD 3. La libertad de contribuir a tu comunidad, es decir: la libertad de distribuir copias de tus versiones cambiadas cuando quieras.
Con estas 4 libertades, el programa es software libre. Sus usuarios son libres y el sistema social de su distribución y uso es un sistema ético que respeta la libertad del usuario y la solidaridad social de la comunidad. Si una de estas libertades falta o es insuficiente, el programa se convierte en software privativo, porque el sistema social de su distribución y su uso no es ético. Un programa privativo no es una contribución a la humanidad, sino un ataque. Es un trampa que intenta atraer a la gente para que ceda su libertad.
Facilitar recomendaciones comerciales a través del correo electrónico es ilegal según la Agencia Española de Protección de Datos. No es posible enviar ningún mail con contenidos publicitario o promocional salvo que exista un consentimiento previo e informado del destinatario, algo que casi nunca sucede en los típicos “Recomendar a un amigo” de los sitios web.
Así aparece reflejado en una Resolución de la Agencia, del 20 de febrero de 2008, en la que se multa a una página web por ofrecer a los internautas la facilidad de remitir a la dirección de correo electrónico de un familiar o de un amigo un mensaje informativo invitando al destinatario a registrarse. La infracción ha sido considerada leve, pero muchos piensan que puede constituir un importante golpe para el marketing viral.
El envío de este tipo de correos electrónicos, aunque lo llevan a cabo los propios internautas, se realiza desde la dirección IP de la empresa sancionada, por lo que la Agencia estima que la página web es responsable.
Leer el artículo en El Economista.
En el blog de Alberto estaba esta presentación con datos mas que interesantes.En tres palabras, más videos, mas participación y menos televisión.
Hoy hemos celebrado la reunión mensual de raileros en Barcelona, en las oficinas de Linqia.
Fuimos siete, Christian presentó algunos aspectos de escalabilidad de Linqia. Hablamos también del stack EC2/S3/SQS, y de git, entre otras cosas.
Hoy fui a la reunión con el Segway y una vez terminada improvisamos unas prácticas en Gran de Gràcia.
