Changes in my open source life

February 15th, 2015 Comments off


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.


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.


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.


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.

Categories: Development, News Tags: , , , ,

Testing rubys initialize

October 6th, 2014 7 comments

In /ruby you have a lot of flexibility in writing code, this includes possibility to not initialize an object.
I use this for testing my initializers, here are some examples how to do it.

Lets start with ruby class:

class TestMe
  attr_reader :value
  def initialize(value = nil)
    @value = value

It’s a simple example where only initialize can set a value, usually you use more advanced code, but this is just a minimal example.

Now lets test it:

describe TestMe do
  subject do

  it "has default value" do
    subject.send :initialize
    subject.value.must_equal nil

  it "sets value" do
    subject.send :initialize, 3
    subject.value.must_equal 3


For more real live examples of allocate check

RVM 2.0 Fundraiser halfway

October 30th, 2013 Comments off

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!


Categories: Development, News Tags: , ,

please hack my rails

October 17th, 2013 1 comment

Security is hard, it requires knowing your system is vulnerable, you should assume it is, but many Ruby on Rails developers seem to forget about it.

I’m writing this because a security vulnerability is promoted and it has to be stopped. The problem is adding bin, ./bin or $pwd/bin to $PATH. This is extended version of the problem with . in $PATH described here

When bin or it’s variation is in $PATH, attacker can place there executable that will be executed instead of system files and gives attacker possibility to run code on your system easily. This is described better here (for the . case):

So why would anyone advice us to jeopardize our system? The answer is bundle exec, it is so long to write and is required to run proper versions of gems placed in Gemfile. To avoid calling it the bundler gem introduces binstubs, many developers advised adding the bin variation to $PATH to simplify calling bin/binary to just binary.

I guess you are thinking now “how is it relevant, I do review my code before running any commands”, the question is “are you?”. There is a lot of tools and extensions to shell that run commands for you, the simplest would be using PS1 to display git status, something like \u@\h:\w $(git branch) > it will execute a git command when displaying the prompt. So when someone writes bin/git into the repository – it will be executed before you can review code after git pull. The prompt and pre command hooks are very popular now and give a lot of options for attackers when bin is in $PATH.

“What should I do then?”

First, you can stop being lazy and type bin/rake or bundle exec rake this way Bundler will be loaded without the possibility to add extra code to your $PATH.

Another solution that helps to fix this problem – I wrote a gem rubygems-bundler which automates calling bundle exec, it does check if the executed binary is part of Gemfile and automatically calls Bundler.setup when needed, this eliminates the need to use binstubs wrappers.

Day from opensource project maintainer: git commit –author

October 2nd, 2013 1 comment

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.


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

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 – 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 <>"

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 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.


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.

Categories: Development, Linux Tags: , ,