2009-09-14T13:37:44+02:00 30 2009-11-25T09:00:00+01:00 HAML is a DRYer way of writing your views. We'll explain how to get started with HAML and SASS, and convert an example app. Later we'll explain some conventions and the best way to use helpers, translations and CSS files to keep your views as clean as possible. Taller 9 120 haml-and-sass image/png haml.png 27969 2009-11-08T01:56:54+01:00 3 Confirmed 2009-11-13T13:10:37+01:00 2009-10-22T17:00:16+02:00 125 2009-11-25T11:30:00+01:00 Chef es un framework de integración de sistemas escrito en Ruby, nos permite aplicar los principios de la gestión de la configuración a nuestra infraestructura. Programa: - Qué es Chef. - Y para que sirve. - La primera pregunta. - ¿Porqué no Puppet? - ¿Porqué Chef? - Instalación de Chef. - Instalación del servidor. - Instalación de los clientes. - Configurando el servidor y los clientes. - Validando los clientes en el servidor. - Configurando el interfaz web de Chef. - Sintaxis y configuración de servidores con Chef. - Creando un repositorio de Chef. - Creación de libros de cocina. ¿Que hay dentro de un libro de cocina? - Añadiendo recetas al libro. - Caso práctico: Desplegando toda la potencia de Chef - Instalación de un stack rails con Chef. - Caso práctico: Administrando grupos de máquinas en Chef. - Administrando un cluster de Apache desde Chef. - Ruegos y preguntas. Por lo que será necesario traer un ordenador al taller. El taller se dará en español o inglés in función del los asistentes. Taller 53 120 taller-de-chef-administra-sistemas-como-ferran-adria-cocina image/jpeg ist1_11021441-chef-being-showered-with-flour.jpg 11849 2009-11-08T02:12:17+01:00 3 Confirmed 2009-11-08T02:12:17+01:00 2009-09-29T08:56:15+02:00 48 2009-11-25T15:00:00+01:00 Actualización: Si queréis hacer algo en concreto con Capistrano podéis dejar en los comentarios vuestras inquietudes. Gracias! --- (teoria) * ¿Qué es capistrano?     - Breve descripción por si hay algún despistado en la sala. * Pasado, presente y futuro.     - Pasado:         Aquí un pequeño salto en el tiempo mostrando lo que podía producir un deploy antiguamente sin Capistrano.         El cambio que supuso el desarrollo de Jamis Buck y la verdad de porque dejó de desarrollarlo(mea culpa).     - Presente:         ¿Quién corta el bacalao ahora?         Que se ha hecho hasta ahora.             - Bugs relevantes corregidos             - Nuevas features     - Futuro:         Lo dejamos para el final. * Estructura de Capistrano     - Gemas que usa y que nos aportan (práctica) ** Primera Parte - Básico     - Instalación.     - Ejecución de tareas.     - Ejecución de tareas encadenadas.     - Listados de tareas.         Mostrar los diferentes listados: breve, descripción extendida de tareas, listado de tareas "ocultas".     - Definir nuevas tareas.         Cómo definir y documentar nuevas tareas.     - Tareas globales y namespacing.         Definir tareas globales.         Usar namespaces.     - Roles y tareas en paralelo.         Definir roles.         Ejecución de tareas en paralelo por rol.         Uso del except y only.     - La terminal es nuestra amiga y como comunicarnos con ella.         Aprenderemos a manejar los diferentes streams(standard input, output y error)         Prompts         Las funciones run, capture, stream.         Subir y descargar ficheros del servidor     - Callbacks         Uso del before y after (teoria) ** Segunda Parte - Deployando que es gerundio      - El camino del deploy         Aquí explicaré las tareas y callbacks que son ejecutadas al hacer un deploy con un gráfico muy chulo(igual no tanto) :-)     - Entendiendo lo que nos dice el log         Repasaremos una salida del log de capistrano con la salida coloreada para verlo mas claro. (práctica)     - Despliegue de una aplicación Rails paso a paso.         "Capistranizarla" con capify.         Configurar config/deploy.rb: ajustar las variables, sobreescribir las tareas de start/stop/restart         cap deploy:setup , explicar la estructura de directorios que se genera         cap deploy , hacer un despliegue     - Mejorar la receta anterior para que nos enlace ficheros compartidos (configuraciones, ficheros de subidos por usuarios,...)     - Generar ficheros de configuración con plantillas     - Convertir esa configuración específica en una genérica y ampliable para poder usarla en otros proyectos.     - Algunos trucos avanzados (diferentes estrategias de multistage, sacar datos estadísticos de tu aplicación, el uso de rollbacks, crear una nueva estrategia de despligue, ...)          (teoria) ** Tercera Parte     - Hablar del futuro de capistrano.      - Despedida y cierre Nota: Los títulos de las partes no son definitivos pero la idea de lo que se quiere explicar es esa. Taller 26 120 taller-de-capistrano image/png header-graphic-box.png 52657 2009-09-29T09:07:55+02:00 3 Confirmed 2009-11-05T16:12:05+01:00 2009-09-29T11:07:52+02:00 51 2009-11-25T17:30:00+01:00 Se trata un taller de Cucumber utilizando el plugin MundoPepino con el fin de que los asistentes acaben con una máquina en la que estarán instaladas todas las gemas y plugins necesarios para ejecutar sus funcionalidades en castellano cuando vuelvan al trabajo. El taller consistirá en crear una aplicación graciosa y útil definiendo las funcionalidades utilizando Cucumber y MundoPepino. La idea es profundizar en los steps reusables que ya están definidos en el plugin, desde los tests relacionados a las vistas, hasta los de la base de datos, pasando por los que involucran los emails y xml generado y parseado por el sistema y mucho más. Empezaremos con una demostración del proceso, definiendo la funcionalidad, viendo fallar los tests e implementando el código necesario para que pasen, colgaremos un tutorial online para que lo vayáis siguiendo y mientras tanto nos daremos vueltas echando una mano donde haga falta. Os animamos a programar en pareja al igual que haremos nosotros. Uno de los objetivos más importantes de cucumber es mejorar la comunicación entre hombres de negocio, diseñadores y desarrolladores, por lo que todo el mundo esta invitado a pasarse sin conocimientos previos sobre las herramientas. Si queréis realizar el tutorial del taller los requisitos son un portátil con ruby on rails, mysql y linux/mac como sistema operativo. Taller 33 120 testing-sin-escribir-tests-con-cucumber-y-mundopepino-el-taller image/jpeg cukes.jpg 9926 2009-11-10T00:04:04+01:00 3 Confirmed 2009-11-10T00:04:06+01:00 2009-09-26T20:20:58+02:00 3 2009-11-26T10:45:00+01:00 Esta charla será una reflexión sobre el mundo del desarrollo web,y de la importancia relativa de la herramienta que se usa para trabajar. Argumentaré por qué creo que es mucho más importante la figura del desarrollador que el hecho de que desarrolle en Ruby on Rails o no. Además, hablaré sobre por qué un framework como Ruby On Rails resulta apetecible para uno de estos desarrolladores, y por qué en el sistema actual no es fácil encontrar empresas que apliquen estas prácticas. En la charla expondré algunas de las características que considero que un "desarrollador definitivo" debería tener, y lo enlazaré con algunos conceptos de clásicos de la literatura geek como The Mythical Man Month, The Cluetrain Manifesto, Microserfs o The Soul of a New Machine. La idea es doble: por un lado iniciar un debate sobre la necesidad de cambiar las estructuras actuales de la mayoría de empresas de desarrollo,y hacia qué modelo deberíamos movernos; por otro lado, que podamos ver cosas que nos diferencian de otro tipo de desarrolladores y que podamos identificarnos con unos valores comunes. Charla 17 45 la-herramienta-de-desarrollo-definitiva image/png raww.png 128663 2009-11-17T00:06:31+01:00 1 Confirmed 2009-11-17T00:06:32+01:00 2009-09-21T10:36:06+02:00 31 2009-11-26T12:00:00+01:00 En 37signals utilizamos RabbitMQ, un servidor que habla AMQP, para gestionar servicios, monitorizar servicios y excepciones de las aplicaciones entre otras cosas. Esta charla pretende de explicar cómo funciona AMQP y cómo se hace útil para cualquier infrastructura, desde una cola de trabajo distribuido para aplicaciones hasta un gestor de logs. Hablaré unos 20 minutos (con demo) de cómo utilizamos RabbitMQ hoy en dia en nuestros servidores, y con qué clientes de Ruby se debe trabajar (Bunny, Nanite, amqp gem, etc). Se harán dos demos: Una, un gestor de excepciones de aplicaciones utilizando couchdb y RabbitMQ. La otra, un monitor de mensajes de syslog distribuido que funciona como el UNIX 'tail' pero mucho más flexible a la hora de elegir qué partes de los mensajes quieres ver y de dónde. Veremos tambien un cluster de Rails recibiendo peticiones a traves de RabbitMQ. Durante otro 20 minutos hablaré de otros usos interesantes de esa tecnología como streaming de video, comunicaciones seguras entre servidores con Nanite (un cliente Ruby de AMQP), y aplicaciones de código abierto que actualmente se aprovechan de RabbitMQ (como Chef). Charla 10 45 amqp-ruby-en-tiempo-real image/png topic-exchange.png 51260 2009-09-21T10:44:06+02:00 1 Confirmed 2009-11-25T01:59:36+01:00 2009-09-29T01:08:26+02:00 43 2009-11-26T12:00:00+01:00 Llevamos prácticamente cinco años con rails entre nosotros, por lo que hay mucho código ahí fuera con mucho valor que necesita muchísimo amor para seguir siendo querido por sus propietarios. Todos escribimos código legacy, por lo que debemos intentar que el impacto y el coste de su mantenimiento sea el mínimo, ya sea por nosotros o por cualquier otro desarrollador que llegue detrás. Mantener nuestro código fresco y saludable no es siempre una tarea sencilla, cogiendo unos pequeños hábitos puede hacerse mucho más llevadero. ¿Qué vamos a tratar?: * Prácticas y consecuencias que pueden complicar la vida de un desarrollo. * Qué es la deuda técnica y cómo saldarla. * Cómo evitar la gran refactorización, pero si es necesaria por donde empezar. * Rojo, Verde, Refactor! Testing y refactorización como modo de vida (TAFT & RAFT) * Usa rails de manera estándar y sigue sus convenciones: hooks en modelos, AR Observers, AC Filters. * Construye tu propio framework con convenciones encima de rails y compártelo con tu equipo de desarrollo. * Algunos plugins y prácticas, que te ayudarán y mejoraran la mantenibilidad. Charla 25 45 mejor-prevenir-que-curar-lidiando-con-codigo-legacy-en-rails image/jpeg 3886492586_6f29183994_o.jpg 83656 2009-10-25T21:30:13+01:00 2 Confirmed 2009-11-10T00:45:28+01:00 2009-09-28T20:57:41+02:00 10 2009-11-26T12:45:00+01:00 ¿Qué tienen en común RubyVM, JRuby, Rubinius, IronRuby y MacRuby? Todas son implementaciones de un mismo lenguaje pero solo una de ellas es la referencia, el resto persigue ser lo más compatible posible. Rubyspec es el proyecto que marca las pautas y define como se deben comportar todas las implementaciones de Ruby ante un mismo código. En esta charla se pretende repasar las principales funcionalidades que Ruby 1.9 incorpora, como Rubyspec define estas funcionalidades y como otras implementaciones se están adaptando a ellas. Desde el interior de cada una de ellas veremos los problemas que a los que se enfrentan sus desarrolladores para hacer una implementación lo más compatible posible con la especificación y como los resuelven. Charla 22 45 rubyspec-y-el-largo-camino-hacia-ruby-1-9 image/jpeg ruby2.jpeg 49219 2009-11-10T00:22:34+01:00 1 Confirmed 2009-11-10T00:23:11+01:00 2009-09-30T00:21:50+02:00 64 2009-11-26T13:30:00+01:00 Hace dos años, en RubyConf, vimos un LED parpadeando... el año pasado, bebimos cócteles preparados por el "Barduino"... En 2009, veréis a Ruby volar! Utilizando "Ruby Arduino Development", y una coleción de hardware variado y software libre, demostraramos "Rogue 3", un Vehículo Aéreo Autónomo (UAV) que es más ligero que el aire. También compartiremos algunos metodos y recursos que necesitaríais para empezar con los UAVs hechos en casa. Charla 48 45 la-ascencion-de-la-real-world-web image/jpeg Photo2.jpg 72781 2009-09-30T00:22:31+02:00 1 Confirmed 2009-11-16T09:20:44+01:00 2009-09-29T14:38:01+02:00 60 2009-11-26T16:00:00+01:00 Esta charla tiene como objetivo que la audiencia consiga una idea clara de la situación actual en el campo de los key-value stores, haciendo especial hicapié, en las caracteristicas individuales que las hacen idóneas para su incoporación en aplicaciones Ruby on Rails, ya sea como la capa de persistencia de una aplicación web o como complemento a un sistema gestor de bases de datos relacional. Abordaremos con énfasis las siguientes key-value stores: Cassandra, CouchDB, y Redis. Los principales aspectos a tratar en esta propuesta son los siguientes: 1.- Comparativa de uso, aspectos prácticos relevantes de cada key-value store analizada: tipos de problemas donde su utilización supone una ventaja frente a una base de datos relacional, consejos de diseño para trasladar un modelo relacional normalizado al modelo de datos desnormalizado usado en cada key-value store, problemas y errores comunes en el uso de este tipo de capa de persistencia, etc. 2.-Bibliotecas existentes para el uso de key-value stores desde aplicaciones Ruby y Ruby on Rails. 3.-Características de las principales key-value stores analizadas: tipo, tolerancia a fallos, capacidad de persistencia, tecnología usada en su implementación, etc. 4.-Comparativa de desempeño de las key-value stores mencionadas, para una aplicación y conjunto de datos de prueba. Charla 43 45 key-value-stores-conviertete-en-un-jedi-master image/jpeg obi-wan-kenobi-squared.jpg 25448 2009-09-29T14:44:19+02:00 1 Confirmed 2009-11-24T23:54:58+01:00 2009-10-07T16:34:18+02:00 35 2009-11-26T16:00:00+01:00 This talk will introduce into programming with evolutionary algorithms. We'll build and/or discover a small framework for creating genetic algorithms. Programming evolutionary algorithms is like writing very large applications. You have a feeling about how the outcome should look like without knowing how to actually build it in detail. You start with a rough idea and iteratively shape the problem solution. Genetic algorithms are good to solve certain kind of algorithmic problems. The talk will also give a rough picture about situations where evolutionary programming might be the right solution. Especially np hard problems like the traveling sales man problem (TSP) or the rucksack problem are well known combinatoric problems (such as distributing vservers across a number of vserver-hosts). The theory of evolutionary programming will be explained while solving the traveling salesman problem by creating a heuristic using genetic algorithms. TSP: A salesman needs to travel to n cities using a optimal route going through all n cities and returning to his origin. http://en.wikipedia.org/wiki/Travelling_salesman_problem * Individuals First you need to create a representation of your individuals. TSP: Individual = path through the cities * Fitness ** Basic idea: survival of the fittest but which one is it? ** Determine the fitness of a individual using a fitness-function. * Genetic operations ** Mutate *** Beginning from the first individual mutate it to get a second. *** Mutation needs to create VALID individuals (valid salesman roundtrips). ** Recombine *** Like in sexual reproduction we assume that combination of two individuals might combine their best characteristics (or the worst - but these we are gonna throw away. I shouldn't say that as a german I know - but hey it's about computing :-) ** Select *** After a generation (set of n individuals) has been filled we open up the next generation and takeover the best X individuals * Evolution ** Using random operations (mutate, recombine) we fill the generation ** Then we take the best X individuals and put them into the next generation ** Because of the selection there is a continuous improvement of the fittest individual in each generation. ** Repeat this until your solution matches your exit criteria and you are done! Charla 50 45 genetic-algorithms-with-ruby image/jpeg dna.jpg 26632 2009-11-10T00:55:16+01:00 2 Confirmed 2009-11-10T00:55:16+01:00 2009-09-28T23:43:33+02:00 26 2009-11-26T16:45:00+01:00 JRuby es una implementación de Ruby *100%* Java. Muchos conocemos sus bondades más pregonadas: + Hilos auténticos. + Interoperabilidad con Java (lo que da acceso a todas las librerías existentes en Java). + Uno de los mejores GC. También se conoce su peor defecto: No puede cargar extensiones escritas en C. Para compensarlo, existen varios rodeos, siendo los más conocidos FFI y la interoperabilidad con Java. Sin embargo, existe una menos conocida que es la de escribir las extensiones en Java, como si una de C para MRI se tratase. La charla contendrá todo el contenido que me hubiese gustado tener a mano cuando empecé a desarrollar Nokogiri4J, como: + BasicLibraryService + Relación entre la posición del Service y el require que lo llama. + Cómo definir módulos y clases. + Las anotaciones más útiles (especialmente @JRubyMethod). + ThreadContext y Runtime, cómo utilizarlos y cómo obtenerlos. + El (no tan) misterioso mundo de las signaturas de los métodos. + La pesadilla de las extensiones (LoadError y sus [para nada] descriptivos errores). Todo ello a través de código real (la extensión en Java de Nokogiri4J) de forma que puedas orientarte en la creación de tus propias extensiones. Charla 23 45 extendiendo-jruby image/jpeg jruby.jpg 8564 2009-11-10T01:06:27+01:00 2 Confirmed 2009-11-10T01:06:27+01:00 2009-08-19T20:52:33+02:00 23 2009-11-27T12:00:00+01:00 This 45 minute talk will cover what Git is and how it differs from Subversion or Perforce. We will go over why it's so powerful and how it turns source control from a necessary annoyance into a powerful development tool. We will cover the technical underpinnings of the system, common tips and best practices for getting the most out of Git and ways to use Git that you may not have thought of before - as a pure content-addressable filesystem. Attendees will leave with a better understanding of Git and hopefully a new way of thinking about how to work. The talk will be mostly in English with some Spanish when possible. -- Esta presentación de 45 minutos sobre Git es y cómo es diferente de Subversion. Voy a hablar de cómo es una poderosa herramienta para programadores. Voy a hablar de cómo funciona, consejos común y las mejores prácticas para sacar el máximo provecho de Git e interesantes formas de usar Git. El público saldrá con una mejor comprensión de Git y una nueva manera de pensar acerca de cómo trabajar. La charla será en su mayoría en Inglés con un poco de español cuando sea posible. Charla 6 45 la-diferencia-git image/png 4124024_thumbnail.png 21890 2009-08-19T21:20:37+02:00 1 Confirmed 2009-10-24T13:24:12+02:00 2009-09-29T19:42:22+02:00 49 2009-11-27T12:00:00+01:00 En esta charla compartiré como caso práctico mi experiencia como desarrollador de negocio en una empresa de soluciones y aplicaciones Rails. Recorreré las diferencias que me he encontrado al pasar de una multinacional como es France Telecom, con un departamento de sistemas rígido y burócrata, a un equipo pequeño y ágil de desarrolladores de Ruby on Rails. Me apoyaré en el manifiesto “Boot strappers Bible” de Seth Gothin, para ilustrar con ejemplos prácticos como la Tribu Rails puede contribuir a la competitividad en las pequeñas y mediadas empresas frente a las grandes multinacionales. Durante la presentación recorreré el concepto emergente de Tribu, intentando establecer las características de la tribu railera de una forma participativa con los asistentes. Todo desde la perspectiva de alguien que pertenece al lado oscuro: el Marketing Charla 44 45 caso-practico-tribu-on-rails image/jpeg tribes.jpg 28326 2009-11-10T00:15:04+01:00 2 Confirmed 2009-11-10T00:15:04+01:00 2009-09-24T14:30:12+02:00 38 2009-11-27T12:45:00+01:00 Most hardcore developers cringe at the idea of putting down their coding tools and becoming a pointy-haired boss. The journey from Rails coder to manager is fraught with peril - from dealing with difficult clients, to keeping your team motivated, to making sure you don't lose your technical edge. Here is the story of one man who survived the journey and lived to tell the tale. This talk is geared towards Rails developers in the midst of a transition from coder to manager, those who would like to someday make the transition, or anyone who like to learn more about communicating with clients and coworkers. This will be a wide-ranging talk, but will cover topics such as: * Learning a different set of jargon * Handling completely different types of work * Knowing when to delegate and when to get your hands dirty * Keeping your skills sharp * Keeping your team motivated * Communication with employees * Finding balance * How to position yourself for a transition Charla 12 45 surviving-the-journey-from-rails-coder-to-manager image/jpeg n671216028_1219406_1596.jpg 15876 2009-09-24T14:30:55+02:00 2 Confirmed 2009-10-24T13:26:53+02:00 2009-09-29T23:34:13+02:00 63 2009-11-27T12:45:00+01:00 Rails es ideal para desarrollar la mayoría de los proyectos web que se nos plantean, pero en ocasiones necesitamos desarrollar servicios o aplicaciones muy sencillos para los que Rails puede resultar demasiado pesado. En la charla se presentarán varias alternativas más ligeras que Rails comentando los pros y contras de cada una de ellas. Charla 47 45 charla-o-taller-alternativas-a-rails-para-sitios-y-servicios-web-ultraligeros image/jpeg rack.jpeg 14441 2009-11-10T00:28:00+01:00 1 Confirmed 2009-11-10T00:28:00+01:00 2009-09-25T13:34:38+02:00 13 2009-11-27T13:30:00+01:00 Rails es un framework web, esto no es un juicio sino que Rails se autodefine de ese modo. Rails ha nacido en y para la web que es un mundo de pantallas. Sin embargo los humanos vivimos inmersos en una cultura no-web, en una cultura con más de 500 años de tradición en el uso del papel. Nuestra vida esta rodeada de objetos hechos de papel o relacionados con él y es muy difícil dejarlo atrás de golpe: * Los libros, * Los títulos de propiedad, * Los contratos, * El periódico, * La lista de la compra... ¡Incluso la ilustración de “Aplicación” en wikipedia es una metáfora de una hoja de papel! [http://es.wikipedia.org/wiki/Aplicación_informática] No es un problema exclusivo de Rails (PHP, ASP …) cualquier lenguaje de programación o tecnología de los últimos años se ha enfrentado a esta circunstancia. La principal dificultad viene de las diferencias entre medios de las cosas que son respectivamente características de los medios impresos y los, llamemosles, "proyectados": Algunos ejemplos de estas diferencias: PAPEL-IMPRESO / PANTALLA Tamaño/formato predecible / Tamaño variado Alta resolución ~300ppp / Baja resolución ~72ppp Márgenes imprescindibles / Márgenes opinables Predominantemente vertical / Vista horizontal Nosotros, como muchos otros, nos hemos tenido que enfrentar a éste problema. Lo que queremos plantear aquí es un resumen de nuestra experiencia en el proceso para ayudar a otros, para que este camino de ensayo y error lo puedan recorrer un poco más informados y tomar sus decisiones menos a ciegas de lo que las tuvimos que tomar nosotros en su día. No existe una receta mágica para la solución, ya que depende mucho de las necesidades de vada aplicación. Un ejemplo de ello es la disyuntiva entre el rendimiento y el control que surge al valorar la posibilidad de emitir informes en PDF cuyo aspecto puede controlarse de manera bastante precisa pero cuyo proceso siempre acarrea un coste mayor en recursos. Entrando en detalle, haremos un recorrido por las tecnologías a las que nosotros nos hemos enfrentado personalmente, y de las que contaremos nuestras experiencias: * Pdf_writter (los primeros pasos) * RTex1 (plugin para usar plantillas en LaTeX con Ruby embebido) * RTex2 * HTMLDoc (basado en el añejo ejecutable de los sistemas *nix) * Jasper Reports (el Crystal Reports de los pobres) * Act as flying saucer (y entonces llegó java) * Prawnto (la historia del mendicant) * Render_as_PDF (presentacion del plugin de Lleir) * XHTML1strict + CSS2.1 (presentacion de la solución de Fernando) Para iluminar este (tortuoso) camino valoraremos en cada tecnología una serie de criterios que a nosotros nos han ayudado a elegir y juzgar entre las diferentes soluciones: * Rapidez/facilidad de desarrollo (~subjetiva) * Facilidad de modificar/Mantenibilidad (basada en nuestra experiencia) * Rendimiento en máquina * Precisión de la salida (respecto a esperado/modelo) * Soporte de Parciales * Soporte de Imágenes * Control de rupturas (Saltos de Página) * Soporte/control de tipografías * Posibilidad de validación * Compatibilidad con versiones Rails * Compatibilidad con navegadores Una vez evaluada cada una de las alternativas nos gustaría presentar una comparativa de tecnologías de reporting en Rails a modo de resumen o de 'chuleta' si se quiere para ayudar a los asistente a tomar sus propias decisiones informadas Finalmente animaremos a cada uno a evaluar sus propias necesidades y prioridades basándonos en nuestro propio ejemplo (ya que cada uno de nosotros hemos adoptado diferentes soluciones) y a que experimenten, eso sí, sabiendo a que se atienen al enfrentarse a los temibles _árboles muertos_. Charla 14 45 el-ferrocarril-contra-los-arboles-muertos image/png charla.png 130211 2009-09-25T14:39:23+02:00 2 Confirmed 2009-11-08T12:28:38+01:00 2009-09-25T21:28:53+02:00 41 2009-11-27T13:30:00+01:00 Rails includes a standard way to handle internationalization in your applications, but is it sufficient? On a recent project that had to be available in English and Spanish, I found it was not. While Rails implements simple text substitution well, it does not handle inflecting multiple languages. Pluralizing the model name EmergencyContact into Spanish will result in "contacto de emergencias" instead of "contactos de emergencia," for example. This makes using form builders problematic, as well as other automated pluralizations and singularizations. I re-wrote ActiveSupport's inflector and core extensions to respect multiple inflectors per language. In this talk, we'll examine the changes I made and learn about the core of Rails' internationalization support. Along the way, we'll see how to make your application's translation easier with modern key-value stores like Redis, how to name your models and tables in your native language, and how the changes in Rails 3 will affect internationalization. You can read a blog post about some of the work I did at http://www.viget.com/extend/rails-internationalization-and-tu/. Charla 15 45 deep-internationalization-in-rails image/jpeg clinton2-sm.jpg 284269 2009-09-25T21:31:06+02:00 1 Confirmed 2009-12-29T15:02:30+01:00 2009-09-29T14:30:19+02:00 60 2009-11-27T13:30:00+01:00 Cassandra es una iniciativa de key/value store estructurada altamente escalable, distribuida, con consistencia eventual. Reúne a las tecnologías de sistemas distribuidos de Dynamo y el modelo de datos de BigTable de Google. Al igual que Dynamo, Cassandra tiene consistencia eventual. Al igual que BigTable, Cassandra proporciona un modelo de datos basados en ColumnFamily más rica que la típica de sistemas de key/values. Cassandra se liberó a código abierto por Facebook en 2008, donde fue diseñado por uno de los autores de Dynamo de Amazon. Está en producción en Facebook, recientemente Digg la ha incorporado y Twitter está destinando recursos a su desarrollo. Motivación: - Los problemas con la escalabilidad de bases de datos relacionales. Introduccion a key/value store estructurado: - Conceptos básicos. Replicación, Hashing Consistente, Modelos de Concistencia, Teorema de CAP. Algoritmo de Gossip. Características generales de Cassandra: - Replicación, Elasticidad, Modelo de consistencia "eventual", Modelo de datos, Modelo key/value estructurados, Consultas de Rango, Escritura distribuida, Keyspace, Column family, Key, Column and Super-column. Interface con ruby (/rails) a travez de Thrift: - Cassandra gem, Modelando con ColumFamily y Range Queries - Aplicación ejemplo: Utilizando Cassandra y Ruby on Rails Charla 42 45 cassandra-db-que-tienen-facebook-twitter-y-digg-en-comun image/jpeg cassandra_logo.jpg 19339 2009-11-12T10:52:15+01:00 2 Confirmed 2009-11-12T10:52:16+01:00 2009-09-29T12:19:25+02:00 8 2009-11-27T16:00:00+01:00 El Desarrollador Total asume la responsabilidad (y se apoya en ella) El Desarrollador Total abraza el cambio (en vez de quejarse) El Desarrollador Total colabora compitiendo (y compite colaborando) El Desarrollador Total usa la especialización para ser excelente (y no para buscar excusas) El Desarrollador Total es brillante en algunas parcelas (y muy bueno en las demás) El Desarrollador Total escribe código para comunicar (no para demostrar lo listo que es) El Desarrollador Total sabe por qué escribe código (y escribe código que merece ser escrito) El Desarrollador Total no tiene miedo (pero nunca es imprudente) El Desarrollador Total hace ganar dinero (y quiere su parte) Todos podemos ser el Desarrollador Total (porque intentarlo es serlo) Charla 37 45 el-desarrollador-total image/png total-dev.png 55880 2009-11-10T01:01:57+01:00 1 Confirmed 2009-11-10T01:01:57+01:00 2009-08-12T00:16:18+02:00 9 2009-11-27T16:45:00+01:00 Desde pro bono publico intentamos atraer a desarrolladores para que usen conocimiento para crear servicios público por y para la ciudadanía. Si tenemos médicos y maestros que dedican su tiempo libre a temas tan vitales como la sanidad y la educación... ¿qué estamos haciendo los hackers con algo no menos importante como el derecho a la información? Podemos y tenemos que hackear las estructuras sociales y políticas de la misma manera que hacemos con la propia tecnología: esta vez de hecho nuestro trabajo quizás sirva a mucha más gente de todo tipo. Para que todo esto sea posible necesitamos la materia prima: los datos. Mi charlará tratara de presentar en que punto estamos con la apertura de datos públicos y que posibilidades tenemos para colaborar y trabajar en ese espacio. Una estructura inicial de la misma: * Motivación, objetivos y estado actual * Principios básicos * Datasources y datasets * Formatos * Acceso * Peligros y confusiones frequentes El objetivo de la misma es claro: conseguir despertar el interés en la comunidad rails sobre proyecto civiles y públicos en los que pueden participar. Charla 5 45 hack-politics image/jpeg 2731067095_73f8f62020_b.jpg 387770 2009-08-12T00:22:49+02:00 1 Confirmed 2009-10-24T13:21:03+02:00 2009-09-29T20:21:34+02:00 53 2009-11-27T16:45:00+01:00 Gran parte de las nuevas Startups que se crean en Internet confían en Ruby on Rails como framework de desarrollo. Emprender haciendo realidad tu idea o proyecto puede darte mucha satisfacción personal (y por supuesto dinero). Si puedes desarrollar en Ruby on Rails, ¿por qué no crear tu propio proyecto? Si alguna vez has tenido una gran idea, has pensado en hacerla realidad pero no lo has hecho, esta es tu charla. Explicaré desde mi experiencia por donde empezar y que es importante que tengas en cuenta (esfuerzo, riesgo, socios, conseguir dinero, business plan ...) todo ello enfocado a desarrolladores y perfiles técnicos. Charla 45 45 emprender-on-rails image/jpeg emprendedor.jpg 20822 2009-11-10T01:13:33+01:00 2 Confirmed 2009-11-10T01:13:34+01:00 2009-11-11T14:11:52+01:00 198 2009-11-27T18:45:00+01:00 "Those who don't understand UNIX are condemned to reinvent it, poorly." We in the Ruby Community seem to have a habit of re-inventing things. Sometimes this is for good reason, but in some cases we don't know we're even doing it! We're wasting valuable time that could be spent learning Erlang! UNIX-like operating systems have been around for decades and lots of problems have come and gone in that time. I'm going to talk about some of the tools available that can be used to solve common Ruby and Rails deployment and development problems. Charla 58 45 unix-rediscovering-the-wheel image/jpeg john-11082008-192x192.jpg 48806 2009-11-11T14:13:26+01:00 1 Acepted 2009-11-11T15:52:11+01:00