TL;DR

I’m struggling with burnout, to fix it I decided to change my life, got part time job at Try Catch, decided to stop spending all my time on supporting RVM 1 and instead in freed time finish developing RVM 2. RVM 1 maintainers needed.

Open source

Before open source I was a bit unhappy, spending big part of my week in work. I was not depressed, just still not where I wanted to be. This unhappiness was pushing me to find things that made me happy – and open source was it. I was spending a lot of my after work time to be happy – helping people was the solution. So when I got chance to ditch work and do full time open source I was very happy. This continued for long time, I was solving problems, making people happy by helping them. I have noticed larger problems and thought of solving them, this is when I planned RVM 2 a rewrite that was supposed to fix many problems developers struggled in the setup phase of projects and development/production environments. I got money from community and started working, the feature looked bright.

Burnout

But then I was caught by trap of my own creation, I still wanted RVM 1 to work great, to be useful before RVM 2 is finished. Every time I started working on the second version I was distracted by problems of first version. With time this broke me and in the end I was unable to focus on version two. As the only developer on multiple projects I was continuing to help to solve existing problems. I even thought on changing projects I’m involved, I got into working with veewee. This helped for short time and I was able to help both veewee and to work on RVM 2, but soon the disruption wear off and I wasn’t unable to do anything else but support RVM 1. Part of the problem was I was to good in support, new people were not coming to help me, I was doing it all alone. Doing everything alone took a toll on me, I was struggling with burnout. Some weeks were good, some less. I was considering different paths I can take and how to get back in the game of development.

Solutions

In the end I have decided to cut down my support time, really cut it down to a few hours a week. Assuming the projects I’m involved are worth for others someone will pick it up and help with them. There are also alternatives to most of the code I am maintaining, people can migrate to the other projects, now it’s up to the community to step up and help me – help them self to manage the projects. I also decided to get back to working with people by getting a part time job. It happened I got contacted by an amazing startup – Try Catch – which is aligned with my personality, they want to help people. I see it as a great opportunity to get back into the development game. For start I’m working in 80% capacity – so I still can have time to focus on open source. Especially I want to focus in the remaining time on finishing RVM 2, I still have almost half of the money from the fundraiser. There is already a lot of code and putting it all together is only question of spending some quality time with it.

Excitement

I’m very excited to work with Try Catch. As I was looking to get a Ruby job it was very hard to find something really interesting and company I would like to work with. I was getting contacted by multiple headhunters, they were trying to fit me into the job openings they had, but they treated me only as meat, they did not consider searching opening for me. When I got contacted by Try Catch I was very skeptical, my thoughts were “another headhunter agency”, but after few minutes I realized they reverse the process, they search for proper position for developer, not try to push him to current openings. I have spent last week working with Try Catch and it only cemented my good feelings about the company and our future. I’m also very excited to get back into developing RVM 2, I have still the same strong feelings about solving problems with RVM 2.

The feature looks bright again!

For information on helping with open source projects I’m involved with check RVM 1 maintainers needed.

Hello Ruby Lovers,

First off, I want to thank everyone who has donated to the RVM 2.0 fundraiser so far. Every contribution counts and I appreciate them all, no matter how small! I would also like to thank EngineYard for their sponsorship of RVM over the last two years, which has allowed me to add:

• tests,
• stable releases,
• ruby binaries, and
• automatic dependency installation (autolibs)

…among many others.

Working solely on RVM 1.x for the last few years has given me a unique view into the Ruby community. I discovered some of the most common issues users run into and tried to address them in RVM by automating installation and configuration to improve everyone’s experience with Ruby (both newcomers and experienced developers).

It was also during this time that I realized that maintaining a huge project in shell (20,000 lines) isn’t possible — it’s hard to separate modules, it’s hard to test, and advanced algorithms either slow down or need to be simplified to shell coding limitations. All of these lead to the idea of rewriting RVM in Ruby.

Initially, I resisted the idea of rewriting RVM in Ruby since there were some ideas touching static ZSH. However, thanks to DRUG, I was convinced. It seemed all the elements were in place, most importantly, binary rubies which are required for easy bootstrapping. As such, I came up with the RVM 2.0 slogan: “with RVM 2.0, you get one Ruby for free”.

I believe in Ruby. I believe it can be used for more than just web applications. We have a vast ecosystem of gems and Ruby implementations and we are constantly discovering new ways to use Ruby, like Rubinius X, JRuby 9k and Shoes 4. I want RVM 2.0 to become one of those projects that shapes the future of Ruby, and with your help, it can.

If you use RVM personally, please show your support. If you use RVM at work, please encourage your employer to show their support. Everything counts!

https://www.bountysource.com/fundraisers/489-rvm-2-0

Cheers,
Michal

Working as opensource project maintainer is a big task. I have been doing it for some time for the RVM project thanks to Engine Yard.

Problem

A big part of the maintenance is accepting others code for the project; it is very important to handle it well so the code author wants to get back to us and help again. As much as Ruby community is opensource oriented there are few things that can be improved. It happened a few times to me and other developers that the code was merged into projects without preserving authorship. This is a basic error made by maintainers, so I want to share some thoughts on how I try to avoid that problem when maintaining RVM. This problem mostly happens when the we want to change the commits, but is not limited to it and happens also without changes.

Easy way

When you do not care about number of commits you can merge the commit from Github or using hub and then add new commit on top updating it to proper state mentioning the ticket number in commit:

git commit -m "Formatting ..., update #2195"

For example see https://github.com/wayneeseguin/rvm/pull/2195

Limit number of commits

The most basic method when you want to limit the number of commits is to apply changes from the committer and then commit it using the --author flag. I used this for https://github.com/wayneeseguin/rvm/pull/2238 – getting the proper result with involving author would require too much work as for small commit, so I did the required changes to the code (just changing order of paragraphs) and committed it using:

git commit -m "..., closes #2238" --author "Name <author@email.com>"

It is important that the author matches exactly the original author name and email (from their commits) so it does not confuse others or tools used (like git annotate). Also make sure to mention the pull request (close #2238) so it is automatically closed and your commit is linked with it.

Work with the author

The slowest way is to actually talk to the author and explain to him/her what changes are required to make his/her commit accepted. For example, this happened in https://github.com/wayneeseguin/rvm/pull/2187 where most of the discussions happened on IRC or Skype sometimes in comments. This way the person contributing gets best experience and getting back to coding on your project is much easier for him/her.

MINASWAN

Matz Is Nice And So We Are Nice

Most important for maintaining your project is treating other developers with respect, they are human beings, being impolite just builds a wall and ensures they will not get back to you or your project.

Other ways?

Obviously there have to be other ways to handle this, please comment below if you use another flow.

It’s a bit over a year as I work as RVM maintainer with over one and half year (19 months) of contributing to the project.

As I work on the project it was always improved, we spent a lot of time responding to user requests. At first I was helping Wayne E. Seguin the original author and later I took over as maintainer. We have been working hard in our free time to improve the first ruby environment switcher. We also had a lot of ideas how to make things better, but because it was our free time we were not always able to make all the ideas happen even implementing them would be as simple as just few lines change.

Today I want to share history of one of that ideas, automatic environment switching using a shell hook PROMPT_COMMAND => http://www.tldp.org/HOWTO/Bash-Prompt-HOWTO/x264.html, it is very easy idea allowing to execute piece of code every time user prompt is to be displayed. It was supposed to solve some limitations of overwriting builtin change directory command – cd, especially not rereading project file when it’s updated.

Before we were able to implement it a new project come to life – rbenv, it was also intended to do the environment switching but a lot simpler. Among of a lot of promotional keywords rbenv was accusing rvm of overwriting cd, which is considered harmful by rbenv author. To not feed the propaganda of a new tool rvm team has dropped all ideas related to accusations from rbenv. Among other interesting ideas rvm dropped also the idea of using PROMPT_COMMAND.

As time passes a lot of new tools was created to do the same thing – switching ruby environments. One of the tools is chruby, one of the most minimalistic implementations. I was helping from time to time the author with shell code, with understanding the problem of switching environment or just discussing various aspects of the tools we work on.

Of course there was also a need for automated switching of environment in chruby, the author started with cd function implementation as this is one of the easiest ways to archive this functionality. But then I have remembered of PROMPT_COMMAND and proposed use of it, which after quick test appeared to be better solution.

Seeing the idea working I have decided to implement it also for rvm, as initially expected this is a lot simpler code and solves some of the issues. We could have this code available for rvm users one year ago, possibly we could have a lot more of good solutions if the problems were discussed instead of throwing accusations as it was done by rbenv author.

So I wanted to sum the situation here, I wanted to disapprove the method of promoting opensource in cost of other opensource software without bringing discussion, without opening not a single ticket for the project. This are practices that you use fighting “corporate” world, as opensource authors we can choose to work together put aside all the politics, and do our work together for common benefit.

On the end I would thank postmodern the author of chruby for bringing up the discussion and working towards standardizing our software.

There is so much confusion around deploying applications using RVM, I went down and verified. The process was quite straight forward, but I found few points that could be improved.

So all my experiments were done using fresh rails app with one model, you can find sources here: https://github.com/mpapis/ad

My goal was to be able to install rails app on server without complicated recipes and doing much on server.

So the boring part first, setup server:

1. I’m assuming your domain (DNS) is configured and points to the server
2. I’m assuming you have nginx up and running, most distributions have own instructions for it, but the process should be rather easy like apt-get install nginx
3. To keep good security levels we assume one user is created per application, I used this command useradd --comment "AD - Example Rails App" -s /bin/bash -m -U ad but you might need other command depending on the system, do not forget to generate and exchange SSH keys
4. Then I had to create nginx configuration for my site /etc/nginx/sites-available/ad.niczsoft.com`` the code bellow
5. And finally link the configuration ln -s /etc/nginx/sites-available/ad.niczsoft.com /etc/nginx/sites-enabled/ad.niczsoft.com, do not forget to restart nginx

server {
  listen 80;
  server_name ad.niczsoft.com;
  access_log /var/log/nginx/ad.niczsoft.com.access.log;
  error_log /var/log/nginx/ad.niczsoft.com.error.log;
  location / {
    proxy_pass http://unix:/home/ad/app/shared/pids/unicorn.socket;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header Host $http_host;  # this is required for HTTPS (another server section):  # proxy_set_header X-Forwarded-Proto https;  }
}

Server is at this point ready and trying to proxy incoming connections to our application. As mentioned above I have minimal rails application, so locally I have installed capistrano and generated basic setup with capify . and replaced config/deploy.rb with this https://github.com/mpapis/ad/blob/master/config/deploy.rb

We need also few gems to be added to Gemfile and then bundle installed:

group :development do
  gem 'capistrano'
  gem 'capistrano-unicorn'
  gem 'capistrano-file_db'
end

but feel free to check the whole file: https://github.com/mpapis/ad/blob/master/Gemfile

On the list is one new gem I have created to simplify deployments capistrano-file_db. It’s minimalistic gem to support deployment of file based databases (defaults to sqlite3).

I have reused also existing gem capistrano-unicorn – this one was not so straight and needed minimal hacking, but I was able to get it running in few minutes, I will be fixing the problems I found shortly, hopefully my changes get merged to master soon.

Lets go through the config/deploy.rb, the first section is pretty standard and reflects most of the configuration we did for server:

set :application, "ad"

set :deploy_to, "/home/#{application}/app"
set :user, "#{application}"
set :use_sudo, false
set :scm, :git
set :repository, "git://github.com/mpapis/ad.git"

The fun starts later, first we set ruby version to our current local selected ruby.

set :rvm_ruby_string, ENV['GEM_HOME'].gsub(/.*\//,"")

Next we tell rvm to check for remote installation in user home – as by default it checks system installation.

set :rvm_type, :user

Here we instruct rvm to install head version remotely, this line can get removed after 1.11.0 gets out, it will be defaulting back to stable.

set :rvm_install_type, :head # before rvm 1.11.0 gets released

We tell bundler to omit development dependencies, which of course are our capistrano libraries.

set :bundle_without, [:development]

And finally we instruct unicorn plugin about the proper pid path, unfortunately it was not the only place we needed to setup it, check https://github.com/mpapis/ad/blob/master/config/unicorn/production.rb for more details:

set :unicorn_pid, "#{shared_path}/pids/unicorn.pid"

That’s almost it, now lets tell capistrano where the deploy, and to always do migrations:

server "niczsoft.com", :app, :web, :db, :primary => true

before 'deploy:restart', 'deploy:migrate'

This two steps are important, they tell capistrano to install rvm and ruby on server, it will also create application gemset if used, it will use rvm_ruby_string, so make sure to set it to something useful like `rvm current`:

before 'deploy:setup', 'rvm:install_rvm'
before 'deploy:setup', 'rvm:install_ruby'

And on the end all the capistrano plugins we want to use:

require "rvm/capistrano"
require "bundler/capistrano"
require "capistrano-unicorn"
require "capistrano-file_db"
load 'deploy/assets'

For the deploy/assets to work we have gem 'therubyracer' in Gemfile.

That’s all, let deploy our application, first prepare server

cap deploy:setup

cap deploy:cold

this will take some time so grab a tee/coffee.

After server is prepared we can deploy application after every commit to repository:

cap deploy

And it’s the end of the journey, it takes a lot longer to write this tutorial then to just do the deployment, doing it second time try to fit in 10 minutes !

You can get more details on RVM / Capistrano integration in the freshly updated documentation page: http://beginrescueend.com/integration/capistrano/ also worth reading is the new project files not requiring trusting: http://beginrescueend.com/workflow/projects/#ruby-versions