It seems that all Rails branches (2.3, 3.0, 3.1 and 3.2) have been updated to fix two severe security issues (first and second). Please refer to the Rails Weblog post for more information and take action ASAP to keep your rails apps secure!

Insight on the bug causing this ‘emergency’: http://www.insinuator.net/2013/01/rails-yaml/

Things to have into account when updating:

Rails 3.0.x apps over Ruby 1.8.x:

Of course, always do this in your dev environment prior to updating your servers to make sure you’re not breaking anything.

• Update rubygems to 1.8  (if needed) using gem update --system
• Modify your Gemfile to specify the rails 3.0.19 version. Note: you might have to delete your local Gemfile.lock before to update it.
• Run bundle.
• You may need to update or specify the versions of some gems. For example I found that I had the ``factory_girl_rails`` gem on my Gemfile, but its current version doesn't work with Ruby 1.8 anymore, so I had to specify the 1.7.0 version for this gem in order to keep everything working.
• You might want to use the gem clean command in order to remove the old rails (and other gems) versions once you've ensured that the app works after doing the previous steps. Beware, this might will break dependencies, run bundler afterwards to attempt to fix broken dependencies. Take extra care with your passenger gem, as you won't come across any problem with it until your actually working on your servers.

Rails 2.x apps:

If you don’t have bundler, install rails gem version 2.3.15, and after that, update your app/config/environment.rb file to use rails 2.3.15.

With this version of Rails I’ve come across this warning message when running Webrick or the Rails Console:

NOTE: Gem.source_index is deprecated, use Specification.
It will be removed on or after 2011-11-01.Gem.source_index called from
/Users/meh/.rvm/gems/ruby-1.8.7-p370@project/gems/rails-2.3.15/lib/rails/gem_dependency.rb:78.

It seems that you may solve this by updating your bundler gem (gem update bundler) to the latest version but I found that I had to downgrade the rubygems version in that gemset to version 1.6.2  (gem update --system 1.6.2) to get rid of the message.

When debugging and testing Rails 3 apps locally, you might eventually need to boot Webrick (or whatever server you use) in “production mode”

rails server -u -e production

Then when you get to -usually- localhost:3000, you might find that no images, stylesheets or javascripts are being served, and you’re getting lots of routing errors on the server output.

Don’t panic! This happens because Rails in production mode assumes that your web server (Apache, nginx, etc) will manage serving the assets.

This can be fixed by changing the 32nd line in your config/environments/production.rb file:

  config.serve_static_assets = false

From false to true.

And that’s it.

DISCLAIMER: being a post about a local event, I’ve decided to write it in Spanish. This should help me to finish it fast and publish it while the impressions from the event are still fresh in our heads. If you still want an English version, help yourself with the Google Translation apps.

Este fin de semana acudí a mi primer sarao profesional, el #OpenSpaceSevilla. Lo primero, como debe ser siempre, es agradecer el esfuerzo, dedicación y atención a los organizadores. No faltó de nada, y gracias a ellos y a los asistentes hubo muy buen ambiente en todo momento :)

Web Security por Pedro Laguna

Pese a lo improvisado, es un tema que nunca falla. Siempre hay anéctodas, prácticas y discusiones que salen a la palestra, en especial sobre la valoración que hace el cliente sobre ésto. ¿Debe la seguridad ser un valor añadido, o una core feature del software/servicio que ofrecemos? Personalmente soy más partidario de la segunda opción: la seguridad debe estar ahí, la pida el cliente o no. Esto puede requerirnos más esfuerzo como desarrolladores, o jugárnosla al ser más caros, pero creo que usando buenas metodologías y frameworks de desarrollo el impacto no debería ser tan dramático.

Hablando de frameworks, se hizo hincapié en una cuestión interesante: ¿confiamos demasiado en los frameworks que usamos? ¿los auditamos? ¿o es mejor encargarnos de todo nosotros mismos? Creo que para sustentar mi opinión en el apartado anterior, es obvio que soy partidario de delegar en los frameworks que usamos. La comunidad de usuarios y/o desarrolladores se encargará de mantener seguro el framework, simplemente es cuestión de estar al día de versiones y parches (esto ultimo es muy importante, y no siempre se sigue).

Aplicaciones tipo revista para iOS y Android por Javier Alonso

Bastante interesante por la relativa facilidad para crear este tipo de aplicaciones, me ha dado una idea para algún proyecto personal :) En cuanto a lo negativo: lo de Android era más un “reclamo publicitario” que otra cosa :P

También me gustaría comentar que se preguntó sobre como subir aplicaciones al Market de Apple desde un “Hackintosh”, y la verdad, me parece un absurdo. Si quieres jugar a ser dev de iOS porque mola Apple, sigues las reglas de Apple, pasas por el aro, pagas y te quitas de tonterías. Ah, ¿que es caro? Pues desarrolla para Android. Analogía: si quieres ser guay y moderno y fardar de zapatillas Converse, te compras unas puñeteras Converse originales. Si no te quieres gastar la pasta, te compras la Beppi de imitación cutres de la tienda de tu barrio, PERO NO LES VAYAS A PEGAR EL ICONO DE LAS CONVERSE, MIARMA, NO ME SEAS UN CUTRE.

Garajes en Andalucía, propuesta por José Manuel Beas

Esta charla comenzó muy muy bien, con muy buenas ideas y una muy buena dirección, hasta que fué acaparada por uno de los asistentes y desviada de la dirección original hacia un lamento continuo, un lloro y un solo ver lo negativo. No se consiguieron abordar ideas como la madurez del mercado en la región (se impuso la idea de que hay que irse a buscar el cliente en otro sitio, aun estando situados aquí), ni, -porque no-, la propia madurez de los profesionales del sector que empiezan su carrera profesional en Andalucía.

O lo que es lo mismo: la gente que va a dedicarse a esto, ¿sale imbuida del “espiritu garajero a.k.a. emprendedor” de donde quiera que ha sido instruido? La respuesta, en mi opinión, viene a ser que no, y creo que es algo que viene directamente de los métodos de formación y evaluación, desde mi experiencia, en la universidad. Luego ya está lo de que cada uno debe ser consciente de sí mismo y su entorno, pero es otra faceta más del mismo problema, creo yo.

Al final se atisbó algo de luz, al hablar de la dificultad de hacer comunidad, en concreto en Sevilla. La dificultad de montar eventos y charlas (que nos lo digan a los Wombytes) y que acuda el personal. De nuevo me remito a lo anterior. Me hubiera gustado que se ahondara más en ciertas recomendaciones que iban surgiendo para dar visibilidad a eventos y hacer algo de piña y masa, pero el tiempo no lo permitió.

Yo te la mido (la campaña), por David JGurú y Rubén Teijeiro

Me gustó mucho el planteamiento temático (en torno al surf) de la presentación, la idea, la motivación, toda la explicación del por qué y el como, el equipo, y el insistir y volver a insistir en opensource y el “lo damos gratis y libre”, una auténtica rara avis en éste evento.

Si debo decir que la parte en la que se muestra código me pareció algo floja, perdiendo la atención de muchos asistentes. Creo que es simplemente cuestión de seguir desarrollando la demo y poder mostrar más chicha en acción.

JS’s varios para hacer de todo, propuesta por Javier Alonso

Dada mi inexperiencia con las tecnologías tratadas (no me he pegado de verdad con node.js aún), éste fue el coloquio en el que estuve más perdido, aunque creo que sí que fue el más “open” de todos. Cada uno fué contando su experiencia y sus ideas respecto a los diferentes “js” tratados, consejos, mitos desmontados, referencias, documentaciones, un auténtico ejercicio de compartir conocimientos.

Historias de usuario, por José Manuel Beas

Sin lugar a dudas, la mejor ponencia de las que asistí. Hace poco que sigo a Beas en Twitter, y he leído algo de su blog, y la verdad es que sus intervenciones en el resto de charlas me gustaron mucho, pero me resultó impresionante verle “en acción” llevando realmente la batuta en una ponencia, y hablando de lo que más sabe. En cuanto a las historias de usuario, es algo con lo que tengo contacto en mi trabajo (llevo cuatro meses trabajando en un equipo ágil), y cada vez creo más firmemente que el agilismo es el camino para hacer las cosas bien, y hacerlas a gusto.

Obviamente las inquietudes sobre el mapeo de requisitos no funcionales, el catálogo de requisitos y demás parafernalia proveniente de la metodología tradicional es algo que a todos nos preocupa/ha preocupado en algún momento, pero creo que en muchos casos son cosas que por experiencia van saliendo solas. Me gustó mucho el hincapié que se hizo en el tablón físico, en el “yo soy el que mueve la tarjeta”, el “veo el tablón y de un vistazo tengo una impresión de como va la cosa”, me sentí muy identificado, me gusta tener las cosas apuntadas en papel, y por ejemplo, tachar una tarea realizada en un papel resulta infinitamente más gratificante que marcar un check en una aplicación móvil. Creo que trasladar a lo físico ciertos aspectos de nuestro trabajo, por muy IT que seamos, es esencial, a muchísimos niveles.

Y hasta aquí en cuanto al contenido de las charlas (me salté la última y la retro, soy mala persona).

En cuanto a la experiencia, tremendamente positiva. Al ser la primera vez, considero en global todo, y repetiría sin pensármelo. Quizá en cuanto a contenidos y charlas, podría mejorarse tal o cual cosa (contenido más técnico, o no; más control sobre determinadas actitudes), pero creo que simplemente es cuestión de estar ahí en la próxima ocasión, y aportar/proponer yo mismo algo, callar menos y participar más (aunque soy de natural observador, qué voy a hacer), y adaptar así el evento más a mis gustos y preferencias. Es así de simple y así de bonito. Lo mismo si fuera la cuarta o quinta vez que acudo a un sarao de estos no quizá estaría tan contento, pero la verdad es que me siento muy satisfecho.

Y la verdad, por 12€ un día y medio de conocer a personas, profesionales y absorber tanto conocimiento, los amortizas y amortizarás más y mejor que cualquier Máster de tres al cuarto de esos que hay por ahí.

At my job, we decided that twice a month, a member of the team should host a talk in which he would speak about something he could teach to the others. When we spoke about this, I had just succesfully deployed my first Rails application and I kinda liked it (bear with me, I was a C++ systems dev kid for 2+ years, it was a brave new world for me), so I suggested the possibility of giving a talk on Capistrano, the Rails default-ish option for deploying automation.

I prepared a neat presentation available here (Spanish only). Its most important part is based in a live demo, so I’m sorry if you find that it doesn’t cover essential aspects like tasks syntax and such, because they were covered in the hands-on. In exchange, I offer you some simple recipes I made as examples, or by demand of a fellow dev at Wombytes. They aren’t intended as showcase of my prowess at reciping, but only as simple examples of what namespaces and tasks are about. In fact, they’re the composition of fragments and ideas picked from all around the internets.

This one allows you to see the production log as it grows, without the fuss of having to open a new terminal get into the machine via ssh and navigate to the log folder. Just an elegant cap production log:tail and there you go! In this github repo there’s a similar one, that executes tail on every log present (pre, production, whatever) instead of just one. The addition of the INT signal treatment was shamelessly taken from this post from the almighty Stackoverflow.

  namespace :log do
    desc "Tail production log file"
    task :tail, :roles => :app do
      run "tail -f #{shared_path}/log/production.log" do |channel, stream, data|
        # this catches the INT signal and avoids the ugly capistrano error on CTRL+C

        trap("INT") { puts 'Interupted'; exit 0; }
        # this is to have a cleaner output

        puts "#{channel[:domain]}: #{data}"
        break if stream == :err
      end
    end
  end

The next set of recipes make use of your regular recipe to make dumps (namely ‘backup’) of the production database, and need a couple of extra things. Basically what they do is put some order in your dumps folder, and download new dumps you create easily via scp. I don’t like the fact that they have too much folder information hardcoded on them, but it’s just a matter of refinement and good variable usage.

  #put this with your variable declarations

  #the LOCAL folder where you want to store database dumps

  set :projects_folder, 'projects'

  #put this with the rest of your hooks

  before "db:getnewdump", "db:tidydumps"

  # THESE TASKS GO INTO YOUR namespace :db

  desc "Moves old backups to old folder"
  task :tidydumps do
    puts 'Moving old backups to the old folder'
    run "mkdir -p #{shared_path}/db/backups/old"
    run "mv #{shared_path}/db/backups/*.gzip #{shared_path}/db/backups/old"
  end

  desc "Downloads the las db dump"
  task :getlastdump do
    puts "Downloading latest dump to $HOME/#{projects_folder}/database_dumps/#{application}/"
    system "mkdir -p $HOME/#{projects_folder}/database_dumps/#{application}/"
    system "scp -P #{port} #{user}@#{domain}:/#{shared_path}/db/backups/*.gzip
            $HOME/#{projects_folder}/database_dumps/#{application}/"
  end

  desc "Creates a dump and downloads it"
  task :getnewdump do
    db.backup
    db.getlastdump
  end

  desc "Downloads ALL THE DUMPS!!"
  task :getalldumps do
    puts "Downloading dumps to $HOME/#{projects_folder}/database_dumps/#{application}/"
    system "mkdir -p $HOME/#{projects_folder}/database_dumps/#{application}/"
    system "scp -r -P #{port} #{user}@#{domain}:/#{shared_path}/db/backups/*
            $HOME/#{projects_folder}/database_dumps/#{application}/"
  end

Anyway, the talk went well, as only the devs were present[1] and I felt more comfortable. Some team members learnt something they didn’t know about Capistrano (yay for me!), and some others with more experience explained some things I didn’t have understood too well to me (yay for me again!).  There’s a chance that I will be giving this talk sometime again in the future, so those lucky enought to see me then will get a much better and expanded experience.

This talk gave me the chance to have a conversation with Juanje Ojeda, who kindly pointed me in the direction of some nifty Chef (which is mentioned at the end of the presentation) resources, so I can delve deeper into the devops lore. I guess you’ll be reading about my findings here in the short future. Thanks, mate :)

That’s the best of it: get the satisfaction of teaching a little bit and learn a lot in the process.

[1] Having talks on thursdays at 18:30 in a god forsaken place faraway from downtown doesn’t precisely attract many peeps, no matter how interesting the talk seems to be.