You might remember my rant/advice on keeping your seed.rb file up-to-date.
Well, I’ve found something a very cool gem that might just do the trick when just giving the newbie a dump of the database isn’t possible for any reason: Seed Dump gem by rroblak
This gem will add a rake task that will generate a seed.rb file containing as much actual data from your development database (which is supposed to be consistent with your data model) as you want.
Simpy wonderful!
Esta pasada semana tuve la oportunidad de participar junto con la gente de Salumedia en una muy buena sesión de formación sobre la gestión de equipos y proyectos desde el punto de vista del Scrum Master, impartida por José Ignacio Ortiz de Galisteo.
Fue una sesión muy abierta y dinámica, en la que los que ya habíamos trabajado con Scrum alguna vez pudimos hablar de nuestra experiencia y hacer ver mejor a los “no iniciados” cómo se hacen algunas cosas, mientras que estos últimos pudieron preguntar todas sus dudas (e insistir en algunas de ellas) sin límite. Incluso se consiguió no lanzar la “alerta de trauma” ni una sola vez :)
Durante la sesión, y posteriormente, reflexionando y recordando el ciclo “Lunes ágiles” sobre agilismo que David JGurú, Javier Baena y yo dimos en la Universidad de Sevilla a finales de mayo, y en el que precisamente yo cubrí el rol de Scrum Master, me he dado cuenta de que al introducir Scrum a un equipo nuevo siempre acaban apareciendo los mismos lugares comunes.
Pese a parece algo liosa en principio (¿planning poker? ¿sucesión de Fibonacci?), es bien recibida. La gente está muy cansada de estimaciones irreales que llegan desde arriba, hechas por gente que generalmente ha oído campanas sobre el desarrollo, pero realmente no sabe dónde. Por tanto, es normal que esta forma de “empoderar” al equipo de desarrollo ilusione tanto. Pese a todo, este tipo de estimaciones tienen riesgos y dificultades, a saber
- La sobreestimación y la subestimación. Mientras que la primera puede ser fruto de la inexperiencia (o de un realismo extremo) y las sucesivas iteraciones deberían ir eliminando esta práctica, lo segundo creo que suele venir por influencias externas (“no se puede tardar tanto en tener esto”) y puede ser altamente tóxica para el equipo. Es algo a evitar SIEMPRE. Una estimación bajo presión que acabe con mucha “subestimación” acabará pasando factura anímica (porque el trabajo es el que es y se tarde lo que se tiene que tardar), por no hablar de que malvender las horas de trabajo es nocivo para el negocio de por sí.
- Compromiso versus contrato. El equipo se tomará las estimaciones como el compromiso que asumen: “en tanto tiempo tendremos tantas cosas”. El problema llega cuando desde el PO/cliente se entiende que una estimación es algo absoluto y escrito en piedra, y que jamás se va a tardar más de lo que se dice porque nunca va a haber imprevistos. Ahi es cuando entra el dolor. Se ha de comprender que hay cosas que hasta que no se está hasta las rodillas en la faena, no aparecen.
- La obsesión con las horas. Esto suele darse entre la gente de las capas “de gestión” que llegan de nuevas. El concepto de puntos de esfuerzo les parece demasiado abstracto, no hacen más que preguntar por la equivalencia en horas. Lo importante es aprender qué implican y significan (y no “cuanto”) para tu equipo tres, cinco, ocho puntos de esfuerzo, y la conversión a horas vendrá sola, gracias al proceso subyacente de auto-conocimiento del equipo que conlleva el adoptar scrum.
Esto es más de cara a un PO/comercial que un SM. Por esto es recomendable enlazar aquí la parte que dió David al respecto en el ciclo de agilismo.
Suele ser habitual el “¿como le vendo al cliente esto si no le puedo decir que van a ser 2 meses, tres semanas y cuatro dias JUSTOS de desarrollo?”, “¿como les hablo de sprints? ¿de que en dos semanas van a tener algo que se va a ir transformando en lo que quieren?”, “¿como hago para que cada sprint suponga aumentar el valor del producto, en lugar de pivotar completamente porque el cliente no tiene claro lo que quiere?”.
Todo esto es bastante complicado, concedido, porque requiere en mayor o menor medida reeducar al cliente. Esto es más labor de un PO/comercial si este pertenece a tu organización, en lugar de a la del cliente. Tendréis que aprender a vender proyectos de otra forma (juntos, el PO es parte del equipo, más que un comercial al que solo se le ve de higos a brevas por la ofi y con una bolsa cargadita de marrones). Aprovechad el factor iterativo y el de “más resultados, más pronto”, e involucrad al cliente más en el proceso. Abandonad la mentalidad de “desarrollos caja negra”, y trabajad más codo con codo con el cliente a base de implicarle.
Si toda vuestra organización va a ser ágil, pero vuestros clientes no van a cambiar con vosotros, aquí sólo va a haber DOLOR. Llegará ese momento en el que habrá que decir “no somos los desarrolladores que buscas”. Y sí, perder un cliente es doloroso, pero más doloroso es tener a un equipo encabronado en un ambiente tóxico, un cliente encabronado, y estar tú en medio.
Y si el PO que tenéis es del lado del cliente, y no entiende esto, entonces necesitáis quitaros a esa persona de encima, porque no ha entendido nada de nada.
En definitiva, adoptar Scrum no es cosa de un día. Requiere un aprendizaje, un sacrificio y tiempo de adaptación para todos los roles implicados. Son necesarios paciencia, comprensión y apertura mental.
Pero merece la pena. Porque implica una cultura organizacional diferente. Porque da poder al equipo de desarrollo, y porque nos reeduca a todos, poniéndonos en el sagrado camino de ser felices mientras trabajamos (que al final es lo más importante).
Y porque bueno, cuando lo echas a andar, Scrum funciona y todo.
De vez en cuando, alguien aparece con la misma pregunta:
¿Qué necesito para poder programar en Rails? ¿Qué recursos me recomendáis?
Como ya he respondido lo mismo más de una vez, y se que volverán las oscuras golondrinas, he decidido hacer un pequeño post explicando por donde empezar, qué libros mirar, etcétera. Todo opinionado, como Rails: todo basado en mi gusto y experiencia personal.
##El ecosistema Rails, cosas que interesa saber:
Esto es fácil: OS X o GNU/Linux. Nunca me he aventurado a desarrollar Rails en Windows, y por lo que he leído, es algo que no quiero hacer salvo que me ofrezcan MUCHA pasta por ello. Tanto para desarrollo como para despliegue.
NOTA: por preguntas que me han hecho, añado un par de links que pueden ser interesantes: Developing Rails in Windows, seriously, y Deploying Rails to Windows Server.
Son gestores del entorno para Ruby/Rails y sus gemas (librerías). Cada uno funciona de una forma y sirven para controlar que version de Ruby hay instalada, que librerías y en qué versión están visibles para tal o cual proyecto, etc.
Para despliegues en producción, me gusta Rbenv, no lo conocía hasta hace poco y mola bastante. Para mi máquina local, trabajo con RVM por que fue el primero que conocí y ya es costumbre. Este post (en inglés) viene muy bien para enterarse de como funciona RVM.
Llegar a comprender como funcionan y sacarle partido es comprender como se organiza el ecosistema, como interactúan y son dependientes entre sí Rails, Ruby y las gemas que se usen.
El lenguaje en sí. Ruby es a Rails lo que Python a Django o PHP a Laravel. Hay dos formas de enfocar esto: aprender Ruby conforme aprendes Rails, o aprender primero Ruby.
Yo hice lo primero por necesidad, y bueno, se tira para adelante, pero cuando sepas más Ruby, volverás a ver código antiguo y te avergonazarás al ver los pifostios que montabas para resolver cosas que con una sola buena línea de Ruby haces ahora más elegante y rápidamente. Es normal.
A mi me gusta mucho el Why’s (Poignant) guide to Ruby, que por cierto recomienda otros libros que son muy buenos también.
El framework. El esqueleto de tu aplicación. El conjunto de herramientas, comandos, estructuras y funcionalidades que te ayudarán a crear sitios web molones en dos patadas (bueno, quizá algo más). Una lista de recursos:
Rails Tutorial
Este lo hemos hecho casi todos, es básicamente el “Hola mundo” del Rails
Las guías Rails
Con esto hemos empezado todos a pegarnos con Rails. Explicaciones, soluciones y consejos básicos y rapidos para empezar a andar, algo así como “The Rails Way in a nutshell”. Imprescindibles!
The Rails Way
La BIBLIA de Rails. Aqui te explican como funciona todo y porqué (cosa bastante importante, no todo va a ser “magia”).
Ojo, que existen varias versiones: el original para Rails 2, el que salió para Rails 3, y el que ha salido hace poco para Rails 4. El problema de este libro es que algunas partes se te pueden quedar algo obsoletas por ejemplo si estás trabajando en Rails 3.2, ya que el libro cubre Rails 3.0, pero en términos generales, está todo ahí.
Es un sistema de control de versiones, que es muy popular y casi está considerado ahora mismo como el estándar de facto. Aquí está la manteca:
Adicionalmente, en Github podrás guardar tus proyectos (o en Bitbucket si necesitas que sean privados) y estar en contacto con la comunidad de desarrolladores, creando gemas, ayudando a mejorarlas, y averiguando como funcionan. Colaborar y aprender, los pilares del FLOSS.
Ojo, esta parte es algo fundamental en el desarrollo y aprendizaje (contínuo) de Rails. Cuando estés más pendiente de lo que pasa Github que de lo que pasa en Facebook, estarás en el buen camino :P (de ser un m4m3r70 pr0, pero hey tiene su aquél, ¡en serio!)
Hay algunos IDES para Rails funcionando que no he probado. Por lo que sé, la forma más habitual de trabajar es consola de comando, un editor de textos potente (TextMate2, SublimeText2, Vim, Gedit o Emacs) y varios navegadores en los que probar.
Todo lo demás que puedas conseguir con GUI para ayudarte si tienes miedo a la consola no te vendrá mal: clientes gráficos de Git, el JewelryBox para la RVM, SequelPro o PgAdmin para tus bases de datos, etc. Usa lo que necesites, con lo que te sientas más cómodo, y lo que tu máquina pueda correr (algunos de los softwares citados solo existen para OS X).
Personalmente, tiro de TextMate2, 4-5 terminales abiertos por proyecto (servidor Rails, IRB, SassWatch, RSpec y una “libre”). Uso la app de Postgres de Heroku para gestionar el servicio de PostgreSQL, PgAdmin o SequelPro para GUI de la BD. Raras veces uso JewelryBox y SourceTree, ya que suelo tirar casi siempre de consola para operaciones de Git y RVM.
¿PostgreSQL? ¿MySQL? ¿SQLite? Para el día a día, es complicado que tengas que llegar a pegarte con tu base de datos cara a cara, consulta a consulta, picando SQL ‘a pelo’, salvo que estés trabajando en algo MUY GORDO (¿qué haces leyendo esto, entonces?). Rails ofrece ActiveRecord, una interfaz de consultasa base de datos bastante potente que te facilitará el trabajo (y es legible por humanos!).
Aun así, conocer SQL no te vendrá NUNCA NADA mal (perogrullada). No, en serio, es una de esas cosas básicas que hay que conocer en esto del desarrollo web. Aunque también es cierto que la gran parte de las veces solo te tendrás que pegar con tu SGBD para importar o hacer dumps de la base de datos o crear usuarios :P
Rails viene con TestUnit (creo recordar) para tests unitarios. Yo por mi experiencia recomiendo RSpec, Capybara y Cucumber para cubrir TODOS los ámbitos de testing, desde unitarios hasta aceptacion y features (hablando ya también de BDD y no sólo TDD). En Rails Tutorial lo explican bastante bien de qué va todo, al menos lo básico.
CoffeeScript A grandes rasgos es una versión de la sintaxis de Javascript que hace que se parezca un poco a Ruby, para tener código más legible y claro. Una forma más bonita de escribir Javascript, vaya. Pero tiene más, yo sigo aún descubriéndolo :D
De Javascript y jQuery pues, qué decir a estas alturas. Llevan funcionando tanto tiempo que resulta manido hablar de ellos :) Si estás leyendo esto ahora, seguro que sabes de qué van, o incluso te manejas con ellos.
Capistrano Es un sistema de despliegue automatizado para Rails. Facilita la vida porque si te montas bien los scripts en tu máquina de desarrollo, con cuatro comandos de tu consola LOCAL (él solo se conecta por SSH y hace todo) pones la aplicación a funcionar desde cero, teniendo solo el servidor recién contratado.
Instalar las bases de datos, librerias, ruby, rails, gemas, el código, todo con cuatro comandos. El arte está en hacer bien los scripts, claro, y saber como funciona el SO sobre el que vas a desplegar. Por ejemplo no es igual el tratamiento de servicios de sistema en Debian que en Ubuntu, de ahi que tengas que tener nociones de administración de sistemas.
En mi opinión, es una herramienta FUN-DA-MEN-TAL. También he de decir que yo soy más ducho en el camino oscuro del sistemero, pero bueno. Cierto es que permite a gente sin mucha noción de sistemas configurar un servidor de forma rápida y sencilla para tareas básicas, gracias a que hay quien cuelga sus recetas (scripts) en Github. Solo necesitas saber leer y entender qué hacen, para ver si te interesa usarlas.
Otros Tutoriales En Udemy tienen un tutorial bastante completo. Aqui
Cursos online Son muy interesantes y amenos de hacer los de CodeSchool. Prueba los gratuitos, y si te molan ya vas a los de pago. Como complemento, los de jQuery, Coffeescript y Sass ayudan también.
Yo no los he hecho todos (alguno de pago he pillado cuando les da por ponerlos un día gratis). No te van a enseñar nada que no puedas averiguar con los recursos gratuitos y escritos que hay por la red, pero están muy bien presentados y son muy entretenidos de seguir.
Railscast
Videos cortos en los que Ryan Bates explica de forma corta, amena y con la consola por delante como hacer cosas con Rails y el uso de gemas (librerías) populares. Esto no es para verlo desde el 1 al ultimo, al menos no después de los básicos. Estos son de consumir conforme necesites info: buscar cuál habla sobre lo que te interesas y te miras el que necesites.
¿Me dejo algo? ¿Crees que este post es mejorable? ¿Quieres rebatirme o aconsejarme? ¿Contratarme? ¡Comenta!
Hace poco tuve el placer de impartir junto a mis amigos y “camaradas del metal” David “JGurú” Rodríguez y Javier “Javo” Baena, con los que formo el tridente denominado “Bonobo Squad” unas charlas sobre agilismo y Scrum en la Escuela de Ingeniería Informática de Sevilla.
Dividimos la charla en tres partes:
La presentación completa está disponible en speakerdeck.
Disfrutadla.
While trying to build and install PHP 5.4 in a OS X 10.7.5 in order to test Laravel, I found myself updating several things with Homebrew. It seems that one of the things updated was my brew installation of MySQL.
The thing is that later, I tried to boot the Rails console for a project and it puked this fearsome line:
~/.rvm/gems/<gemset>/gems/activesupport-2.3.17/lib/active_support/dependencies.rb:466:in
`load_missing_constant':NameError: uninitialized constant MysqlCompat::MysqlRes
As delicate as installing MySQL in Mac OS X and getting it to work is, I knew this was a bad omen. Yes. I couldn’t make any query using the rails console.
So, after checking the Internet, the first probable cause is that after changing the MySQL installation you would need to rebuild the mysql gem. So, after checking ‘which MySQL’ was in use, I reinstalled the gem with some options:
env ARCHFLAGS="-arch x86_64" \
gem install mysql -v=2.8.1 --with-mysql-config=/usr/local/mysql/bin/mysql_config
Everything went smoothly, but I had the same error when firing up the console. Damn. The next thing I found about it was about the libmysqlclient not being installed or found. But locate libmysqlclient gave me three different paths… so it had to be about the library not being visible. After researching, the library is usually looked for in the $DYLD_LIBRARY_PATH. Set the proper path in your .bash_profile (something along /user/local/mysql/lib) and you’ll get going.