At OmbuLabs we are always trying to find or create tools to help our processes and workdays run as smoothly and efficiently as possible. For the past few months we have been developing just such a tool, and recently we made it open source. Dash is a dashboard application written in Ruby on Rails that integrates open pull requests and issues from GitHub with Pivotal Tracker stories.Read more »
Articles about Open Source
This is our first quarter report for open source projects, we will be releasing this report on each quarter of the year with the purpose of motivate us to contribute more and release more open source projects.Read more »
At Ombu Labs we are firm believers of open source. We use open source but also like to contribute back to the community and we have open sourced a few projects.
We know that contributing to open source can be a difficult task so we have been looking for easier ways help to onboard new and past contributors. Here is a list of tips and tools that we believe that can help you make your open source project a more friendly space.Read more »
Contributing to open source might be scary, you might think that your pull request (PR) is not good enough; that people will judge you by your code; or that fixing that little typo is not worth it.
I had all these questions in my head before I submitted my first contribution to an open source project and it stopped me many times.Read more »
Today I'm happy to introduce Pecas, time tracking leaderboards for Freckle! Pecas is an open source tool that integrates with your account and generates beautiful leaderboards per project and per teammate.
Here is a sample dashboard for all your projects:
On top of that, it will send you an email alert if you haven't tracked any hours during a work day. If it's a holiday, it won't bother you. :)Read more »
We decided to build a simple tool that would allow anyone with a Twitter account to report a parking violation. All you need to do is submit a geolocated tweet and a couple of photos (as evidence!)
Here is an example:
You can check out this tool over here: http://www.infractoresba.com.arRead more »
If you are working with open source or if you are going to open source a repository, you should ensure that none of your sensitive data (API Keys, Credentials, Passwords) can be accessed by anyone.
One thing that a lot of people forget, is that this information stay forever in your repository history, if you do not rewrite the history of your repository.
For instance, what usually happens is that you commit a file with sensitive information. In this Example I added accidentally my
ssh-key to the repo:
$ git commit -am 'init git repo' [master (root-commit) 917a1e1] init git repo 2 files changed, 52 insertions(+) create mode 100644 id_rsa create mode 100644 id_rsa.pub
After doing a couple of additions, working and editing, I realise that I should never have commited the
Alright, then I just do a simple
git rm --cached id_rsa and everything is back to normal. I also add this file to a .gitignore, so that this cannot happen in the future anymore.
(master) $ git rm --cached id_rsa rm 'id_rsa' (master) $ git status A .gitignore D id_rsa (master) $ git commit -am 'remove id_rsa' [master c69deb9] remove id_rsa 2 files changed, 1 insertion(+), 51 deletions(-) create mode 100644 .gitignore delete mode 100644 id_rsa
So if we now have a look in our commit list, we can still see our first commit where I added my ssh-key. If I checkout this commit, I still have the contents of my
(master) $ git log 917a1e1 - init git repo (24 minutes ago) <Sirko Sittig> (master) $ git checkout 917a1e1 ((detached from 917a1e1)) $ cat id_rsa -----BEGIN RSA PRIVATE KEY----- MIIJKQIBAAKCAgEAoequrqsM42na3OpvBFYOpqvzJumr3/kxJTuluXbPyJzVjMXf d/uhFUJgSqq4AJGOFLLPpQ+9jwfA+WraIxZ9R7p8LgpNdUwKsmGnUvofeD/9Rs1y YZO8EAjl1URLJ379nN+L5KKPS/48Q4iGp57iwuGzrXLHccLyW5+Z0iMuHlKBQzPx ...
To ensure that ALL of this data gets properly removed, I need to remove this file from all the commits in the repository with git filter-branch. The command
git rm --cached git rm docs is not sufficient in this case.
(master) $ git filter-branch --tree-filter 'rm -f id_rsa' HEAD Rewrite c69deb9779a30e6335ab1a8ac1a0825cfc9302e4 (6/6) Ref 'refs/heads/master' was rewritten
So far so good, but what about my other branches that have been created?
(master) $ git checkout new-feature
(new-feature) $ ls
drwxrwxr-x 3 sirko sirko 4096 Dec 31 13:20 ./
drwx------ 56 sirko sirko 12288 Dec 31 12:37 ../
drwxrwxr-x 8 sirko sirko 4096 Dec 31 13:20 .git/
-rw-rw-r-- 1 sirko sirko 3243 Dec 31 13:20 id_rsa
-rw-r--r-- 1 sirko sirko 748 Dec 31 12:41 id_rsa.pub
-rw-rw-r-- 1 sirko sirko 64 Dec 31 13:20 my_document.txt
git filter-branch is applying this changes only to the current branch, which is actually not what I want. To make this work, it seems that I have to run
git filter-branch in every existing branch, which makes it pretty annoying. After reading more in the (git docs)[https://git-scm.com/docs/git-filter-branch], I found that I need to apply the
(master) $ git filter-branch --tree-filter 'rm -f id_rsa' HEAD --all Rewrite c69deb9779a30e6335ab1a8ac1a0825cfc9302e4 (7/7) Ref 'refs/heads/master' was rewritten WARNING: Ref 'refs/heads/master' is unchanged Ref 'refs/remotes/origin/master' was rewritten WARNING: Ref 'refs/remotes/origin/master' is unchanged Ref 'refs/remotes/origin/new-feature' was rewritten (master) $ git checkout new-feature (new-feature) $ ll total 44 drwxrwxr-x 3 sirko sirko 4096 Dec 31 13:41 ./ drwx------ 57 sirko sirko 12288 Dec 31 13:41 ../ drwxrwxr-x 8 sirko sirko 4096 Dec 31 13:41 .git/ -rw-rw-r-- 1 sirko sirko 748 Dec 31 13:41 id_rsa.pub -rw-rw-r-- 1 sirko sirko 64 Dec 31 13:41 my_document.txt
That seems to be exactly what I want and in the end I just need to
git push --all --force my changes. After doing this, all collaborators should dump their local versions and clone a fresh version from the origin.
Another alternative to working with
git filter-branch is BFG which has some more nifty features.
This tool provides some commands to completely remove big files as well as passwords from your Git history. Sadly I could not get it properly working, big files are still persistent as a git object and passwords can not be deleted because they are
protected by 'HEAD'. I could not really find a solution for these problems. Maybe you are more lucky!
The easiest and much simpler solution is to initialize a new git repository, after making sure to have all sensitive information removed. The downside is obviously the loss of the project's Git history.Read more »
The simplest way to contribute to an open source project is to file an issue. Here are a few steps for you to file issues that are useful for the project maintainers.
1. Make sure it hasn't been reported yet
A quick Google search should return one or more results about the issue. If it's user error, just change the way you are using the code and move on.
If that doesn't work, find the project (it's probably on Github) and search through open and closed issues. If it's filed and open, try to add more information to make it easier to solve. (Please please please don't just add another +1 to a series of +1s)
If you couldn't find any issues, submit an issue (Beware: some projects will encourage you to post to their mailing list before filing an issue)
2. Submit a useful issue report
Don't just post the title of the error and what you were doing when it happened.
Please be as specific as possible!
Post information about:
- The environment (a snapshot of Gemfile.lock could help)
- The error message (a good candidate for the issue's title)
- The backtrace should always be included in the description
- If there is some configuration involved, add it to the description
3. Bonus points
Try a couple of alternatives and see what results you get. Save all the output, which might be useful for the issue's resolution. I know that most of us try different solutions before filing an issue.
If you want to show the maintainer an example of the problem, you could create a sample application that generates the problem, using the same configuration and the same dependencies you have in your application.
If you found the problematic line in the library, you could enhance the tests to cover the scenario that you are seeing. The best libraries have near 100% code coverage, so adding another scenario could be easier than you think. You don't need to find the solution, but seeing a failing spec will definitely make it easier to find a solution.
4. Share your monkeypatch
Most of us will monkeypatch our application and move on. This sucks!
You should file the issue, so that other programmers will benefit from your "wasted" effort.
If you monkeypatched it in a horrible way, add it to the issue as well. The project maintainer or other programmers might find that it isn't such a horrible patch after all.
To sum things up
I've explained a couple of ways that you can make a contribution to an open source project. I started with the simpler steps and then I moved on to the more advanced contributions.
Ideally, detailed issue reports will become pull requests in the future. You (or someone else) might send the pull request, but it all begins with a detailed description of the problem you are seeing.
Don't just say "It doesn't work!", don't be that person! Next time file an issue so that we can all benefit from your pain.Read more »
I thought it was a good idea, because the current version of DatabaseCleaner requires you to have Postgres, MySQL, Redis, and Mongo up and running before you run
Here are the steps:
Download the Docker Toolbox, a 176+ MB package.
Install the package, which will expand to 400+ MB in your filesystem.
In the terminal:
docker-machine start default
Then within your project:
docker-compose up(before this I had to run
eval "$(docker-machine env default)"because of this issue). Get ready to wait for a few minutes while it sets up your virtual machine.
docker-compose run --rm gem
Last Wednesday I gave a lightning talk about open source at the Buenos Aires Ruby Meetup. I proposed a challenge to all attendees: Contribute to one (or many) open source projects for 7 days straight.
The rules are simple:
- You have to do it for 7 days straight
- If you can't do it one day, that breaks your streak
- When you break your streak, you have to start over from day 1