rvm has a great feature: gemsets. If you don’t know what it is, please, go read about it.
Anyway, what I really like about rvm’s gemsets is the isolation level they provide. It super easy to try something for a while and then wipe it out in a second.
I can create a gemset just by executing the following command. Note that a gemset is only a .gs folder in the current directory.
1
~/code/bh/cuba master 0 $ gs init
To use the gemset, just run gs with no parameters
12
~/code/bh/cuba master 0 $ gs
cuba ~/code/bh/cuba master 0 $
Notice how my prompt changed? This is not provided by gs, but this gist does the trick (it alters your PS1 variable). The name of the gemset is the folder’s name. Simple, no complex stuff here.
Ok, let’s install some dependencies. In this case I’m using dep (topic for another post), bundler’s simple alternative for dependencies tracking.
Ok, a lot of gems, right? If I want to leave the gemset, I just need to exit (either by typing exit or with Ctrl-d). And now we have only the original gems installed.
1234567
cuba ~/code/bh/cuba master 0 $ exit
~/code/bh/cuba master 0 $ gem list
bigdecimal (1.1.0)
clap (0.0.2)
dep (1.0.1)
gs (0.1.0)
rake (0.9.2.2)
Do you want to remove the gemset? Just remove the .gs folder.
1
~/code/bh/cuba master 0 $ rm -fr .gs
So how does this thing work? I leave that as an exercise, ‘cause I think you’ll be amazed. Check the code base.
To me, this is a great example of how to build simple and useful stuff, without doing more than what is needed. We need more of this and less complected stuff.
Lately it seems like setting up rails on Mac OS X is a complicated task, something only the hackers of the world can achieve. Since I’m no hacker, and I do it constantly, I decided to write a quick outline of what I do every time I have a new clean Mac, to achieve this “impossible” task.
In my experience, you don’t need much to get started. I am not even using rvm, ry or rbenv. There’s always time to learn more about them, and you can wait until you need different ruby versions to start complicating your life.
Let’s face it: we, the hardcore ruby devs (?) always recommend this or that tool, but in the beginning you need to learn the basics. You don’t care about which one is the best database, or if imagemagick is crap. You can learn about all the details later, when the problem is in your face.
Homebrew is my package manager of choice. The recipes or formulas are written in ruby, so it’s as good as it gets. You have one of this on most *nix like operating systems.
After executing that, provided that you didn’t mess up, you’ll be able to install most software you’ll ever need.
Homebrew will install by default on /usr/local, and your new friend is the brew command.
Install Ruby
Watch out for this, because it’s very complicated stuff.
1234567
brew install ruby
# Put the pava on the fire for the mate.
#.... Downloading, compiling...
# Remove the pava from the fire.
ruby -v
# ruby 1.9.3p125 (2012-02-16 revision 34643) [x86_64-darwin11.3.0]
I know, I know… You feel the pain.
Install Rails
1
gem install rails # I know, it's amazing...
Note
At this point in my life I feel that there are many other ways to do web development with Ruby. Of course, Rails is the preferred one since forever, but be aware of other lighter, more flexible solutions. I’ll write some more about this later.
Install the database
This is completely optional, alright? Rails works out of the box with sqlite3, so without doing this you are still set, ready to go.
1
brew install mysql # for example, but it can be also postgresql, redis, etc.
Next Steps
At some point, you are gonna start adding gems, and some of them are going to require other libraries in order to work. Nokogiri requires libxml2, paperclip requires imagemagick, and so on. Just brew the dependency named at the library’s Readme file. It’s not that complicated, is it?
Done
You’re done, man. Start learning and blow our minds away.
Themes For Rails, version 0.5.0.pre, has been released. It includes a couple of bug fixes, and many improvements. The most important one is the support for the Rails Assets Pipeline. In reality, this is a consequence of an important enhancement.
The problem
In the beginning, a Theme was a collection of static files (images, css and js files), and dynamic views (haml, erb, or whatever rails supported). Each theme was one single package, normally organized on the themes folder at the Rails application’s root.
The folder containing each themes should look like this:
dark # <--- Theme name
stylesheets
javascripts
images
views
layouts
After some time, I realized things doesn’t always are used the way I thought they would be. So some people asked me about how to change this layouts of files (I also saw forks on github existing only to change this).
The solution
To make this story a little but shorter, now you can change where the assets are stored, and how.
Let’s see an example.
Hey, I don’t want all the static files right there, on the root of theme.
Ok, you can change it like this.
# config/initializers/tfr.rb
ThemesForRails.config do |config|
config.assets_dir = ":root/themes/:name/assets"
end
So your static assets will be on themes/pink/assets/stylesheets, themes/pink/assets/javascripts and themes/pink/assets/images, but your views will still need to be stored on themes/pink/views in order to be found.
What about Assets Pipeline support?
ThemesForRails.config do |config|
# themes_dir is used to allow ThemesForRails to list available themes.
# It is not used to resolve any paths or routes.
config.themes_dir = ":root/app/assets/themes"
# assets_dir is the path to your theme assets.
config.assets_dir = ":root/app/assets/themes/:name"
# views_dir is the path to your theme views
config.views_dir = ":root/app/views/themes/:name"
# themes_routes_dir is the asset pipeline route base.
# Because of the way the asset pipeline resolves paths, you do
# not need to include the 'themes' folder in your route dir.
#
# for example, to get application.css for the default theme,
# your URL route should be : /assets/default/stylesheets/application.css
config.themes_routes_dir = "assets"
end
So this is not the final release. We need some testing so if you are using this gem, please, update to the pre version and submit all the bug you can find. I’ll do my best to fix them.
Ok, a new release of ThemesForRails has been released. It took me a while, and may be because I am not use to deal with a open source project and my regular job (clearly, I need to take some classes from @soveran or @luislavena (Tucuman’s Ruby OSS Bot). Today, I’ve decided to do something about it.
Any way, this release is mostly bugfixes and compatibility with rails 3.1. In the following days (or hours) I will release the new version for rails 3.2 (removing all the de deprecation warnings).
Algunos sabían, otros no, pero este año tuve el agrado de participar
activamente en la organización de la primera RubyConf Argentina [1]. Si no
recuerdo mal, a principio de mayo nos juntamos por primera vez en Urban Station
(nuestro lugar de reuniones mensuales) y decidimos (entre los que estábamos)
encarar la aventura de realizar este ambicioso proyecto.
Pasaron los meses y fuimos avanzando. Creamos el website, conseguimos los
primeros sponsors (github e inaka networks), y anunciamos los primero speakers (Aaron Patterson y Luis Lavena, si la memoria no me falla).
Qué alegrón fue saber que podíamos hacer el evento en el Konex! La Casa
Cultural Konexi es un lugar que
tiene onda y no es acartonado como los habituales lugares donde se
hacen conferencias. Graffitties, minimalismo y luces de neón, entre otras
cosas.
Lanzamos la inscripción, intentando ver si lo que habíamos pensado era
posible y la gente respondió positivamente. Se siguieron sumando los sponsors,
y luego más oradores.
Detrás de la organización de cualquier evento masivo hay muchos inconvenientes
que van surgiendo que ninguno había imaginado inicialmente. Uno de esos fue el
tema de cómo facturar cada acreditación. Luego de varias ideas fallidas
decidimos encarar lo más complicado: Crear una sociedad sin fines de lucro que
nos permitiera hacer cualquier cosa referida a Ruby. Según los cálculos los
trámites no se deberían haber demorado tanto, pero la realidad demostró que las
cosas son más laxas, y al día de la fecha aun no ha salido la aprobación de la
IGJ (aquí estamos esperando).
Con esos quilombos y mil cosas más, logramos salir adelante igualmente.
Brindamos un día para rubyistas de varios niveles que querían hacer algo el
domingo previo (Ruby Fun Day), comimos un asado en Brandsen con los oradores y
laburamos como locos durante dos días para que 300 programadores/as tuvieran un
evento a la altura de sus expectativas (eso espero!).
Tampoco se puede olvidar las noches de la RubyConf. Pudimos disfrutar de dos
drinkups invitados por Github y Business Vision.
De mi lado, y ya que este es mi blog personal, me gustaría agradecer a todos
los sponsors, speakers y proveedores que nos dieron una mano desde donde
pudieron, y por supuesto, a cada uno de los asistentes. Sin ellos, esto no
hubiera tenido ningún sentido, y obviamente no hubiera sido posible.
Pero más que nada al equipo que formamos con todos los rubyistas voluntarios de
Ruby Argentina. Llegamos, muchachos… :D
Destacado personal: En la foto de abajo le explica a Scott Chacon lo que
su apellido, en capicua, quería decir en Argentina. Fue mundial… y no me
olvido más :)
Nos vemos el año que viene, en la RubyConf Argentina 2012.
[1] Vale la pena aclarar que en el 2009 se realizó la conferencia Locos X
Rails, pero ésta es la primera vez que se hace en el mismo marco que las demás
RubyConfs mundiales.
Move by one letters at a time:
ctrl+f (ctrl+b to go backwards)
Move by word
alt+f (alt+b to go backwards)
Delete words:
alt+d (remember that you need to be in the beginning of the word)
Update (thanks to @etagwerker)
Shell History Reverse Search:
ctrl+r Start typing a previous command and it will look it up for you, so you just
press enter without having to write the whole (long ass) command again.
Como algunos sabrán, estuve compitiendo el otro fin de semana en un rally de programación. La intensión del mismo era construir una aplicación en solo 48 horas (o sea que lo que se ve tomó ese tiempo únicamente para ser construido, así que fallas tiene seguro… y muchas). El equipo estuvo confirmado por Nicolás Sztabzyb (@n1cus), Juan Manuel Barreneche (@jbarreneche) y yo (@lucasefe). Nos matamos durante todo el fin de semana, durmiendo una cantidad mínima de horas… pero creemos que valió la pena. Si, lo haríamos de vuelta.
En fin, se acaban de abrir las votaciones públicas, así que les agradeceré vuestro honesto voto (honesto o lleno de fanatismo enfermo sirve igual :) )
La aplicación a votar se encuentra en http://awedition.com.ar. Es un buscador de músicos y grupos. La información que tiene hoy en día es de prueba, pero la intención es armar una buena comunidad, útil, de músicos de todo el mundo. Podés buscar bandas si sos músico, o la pieza que te falta si tenés un proyecto musical. También podés crear tu perfil musical (Musiculum Vitae) y esperar a que el proyecto perfecto te encuentre.
Iniciar sesión con Twitter. El link se encuentra arriba de la página. No usen el link que los lleva a github, porque lo más probable es que no tengan un cuenta ahí. Al hacer click los va a llevara twitter y luego, cuando autoricen, los va a devolver a la página del Rally, pero a la home.
Hace un par de semanas, a partir de mi acostumbrada curiosidad, inicié la tercera Encuesta Ruby Sur. La idea era saber un poco más sobre nuestra comunidad, y tratar de entender un poco qué queremos, de dónde venimos y hacia donde vamos.
Algo positivo que noté es que el año pasado la convocatoria fue mucho menor, ya que solo completaron la encuesta 71 personas. Este año casi se duplicó ese número. 134 personas quisieron aportar su granito de arena. Creo que por suerte se dieron cuenta de que detrás de esto no ningún interés particular.
Se pueden sacar muchas conclusiones de los resultados, pero prefiero dejar que los número hablen por si solos, más que nada porque no me siento el más capaz para hacer ese análisis (invito a cualquier a que lo haga y me pase su opinión para ser publicada).
Salud, y ojalá que sirva para que podamos seguir construyendo una mejor comunidad, con más oportunidades y mayores espacios para compartir este lenguaje que a tantos nos copa.
No recuerdo muy bien, pero el año pasado y el anterior realicé dos encuestas referidas a Ruby en Argentina.
Los resultados de las mismas fueron publicados aquí y aquí.
Este año decidí realizarla nuevamente, pero pensando un poco más en Latino América, tratando de entender dónde estamos y hacia dónde vamos, así que le agregué un par de preguntas más.
El formulario de la versión 2011 se encuentra publicado acá y permanecerá disponible hasta el Viernes 12 de Agosto de 2011. Luego de eso publicaré los resultados libremente y para todo el mundo, igual que las veces anteriores.
Estaría buenísimo que participen mucho, así que se aprecia mucho la difusión.
