Faraday is an high-level HTTP client library with middleware support, and support for multiple low-level HTTP client libraries. It can be used just by adding it to the Gemfile and running
bundle install, just like RestClient can. Or, a different library can be added to the Gemfile and then used through one of its adapters.
The faraday_middleware library, which was started by Wynn Netherland and has been maintained by Erik Michaels-Ober, contains a bunch of middlewares for authentication, response parsing, and convenient hash objects.
Faraday Stack is a pretty generic yet convenient API client. It encodes JSON, parses XML and JSON, follows redirects, and raises errors. In short, it works like many expect custom API clients to work, yet it can be used anywhere, just by specifying the domain. It doesn’t include authentication, which ships with many API clients, but that can be added easily by looking at the source for the stack and adding authentication from another library into it. It’s better than many custom API clients, so if an API client is the slightest bit frustrating, it may be a good idea to use faraday_stack instead.
I really like Faraday, because it lets me choose which HTTP library I’m going to use, which is different between Ruby and JRuby. I often use Faraday by itself even when a custom API client is available. I also will use it in irb (next time, pry) instead of curl at times.
I added a new feature to grem: if you’re somewhere in your ~/github directory, you can simply type “grem” and the program will use launchy to open an appropriate page on GitHub in the default browser.
This is handy, because often I’m in someone’s repo and I wonder what else they worked on. All I have to do now is go up a directory or a few, and run “grem” with no arguments, and I’m there!
I chose to make it go to a repo, rather than a directory in the tree, when I’m in a subdirectory of a repo, for simplicity’s sake. This way, I don’t have to worry about when a directory has been added to a local copy of a repo but not the github repo.
What do you think? Is this command-line tool useful? Do you think my directory structure makes sense? Are there any other ways you can think of that I can take advantage of having a system for organizing my copies of repositories?
Meet grem. Short for gremlin, grem is a tool for managing local copies of github repos. Grem is also my first gem. It was remarkably easy to create a gem with newgem and push it to gemcutter.
Right now, all grem does is clone a repository to a default directory. To try it out, run
sudo gem install grem
grem benatkin grem
…and grem will clone my grem repo to ~/github/benatkin/grem, creating directories as needed.
I got this idea from a comment on my earlier post, Organizing github repos, by KevBurnsJr, where he suggested making a bash script for cloning repos into my directory structure. I decided to take it a step further by making a gem, and adding more features later.
By the way, standardizing on ~/github/username/reponame has worked wonders for me. It’s lowered the friction for downloading repos, looking at them, and coming back to them later. This script should lower the friction even more.
Speaking of lowering friction, with Heroku‘s help, I deployed a mini-app. Check it out at http://last7.heroku.com/ (github).
There are only two hard things in Computer Science: cache invalidation and naming things.
— Phil Carlton
I find that I spend an awful lot of time naming things. More than that, it’s a distraction. I also spend a lot of time organizing directories, and a lot of time trying to recall where I’ve put things.
GitHub has made it a lot easier for me to find code online. In fact, it’s so easy that sometimes I just download another copy of a repository rather than search my home directory for one.
As of yesterday, though, the madness is over, because I decided to replicate github’s organization on my own computer. Here are the first two levels of my new, and currently modest, ~/github directory:
As I get more repos downloaded, I think my new organization style will only make more sense. And if I also need a github repo somewhere else, I can symlink it. Also, ~/src is symlinked to ~/github/benatkin.
The idea came when I realized I didn’t have all of my GitHub repos in one place. As you can tell by the tree, I still don’t. Also, I’m putting stuff in my GitHub directory that I may add to GitHub later. If something stays there longer than a week and I don’t put it on GitHub, though, I’ll move it to the archive.
This new directory structure also has the nice side effect that I won’t need to delete repositories just because I need stuff to be easier to find. It shouldn’t take long for the number at the end of the tree output to go over 100, and in a while, the number could be in the thousands. I’ll think of it as a partial mirror.