Sirupsen

Quotes

2011-07-31T00:00:00-07:00

Quotes are beautiful, because beauty is raising curiosity.

This is my evolving growing list of favorite quotes. Originally I planned to add why I like them, but I’ve left them beautiful.

“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” – Antoine de Saint-Exupery

“Make things as simple as possible but no simpler.” – Albert Einstein

“Less is more.”

“Those who are crazy enough to think they can change the world usually do.” – Steve Jobs

“Don’t compare yourself to others. Compare yourself to the progress you’ve made.”

“The potential of greater good goes right along with the potential for greater evil.” – Larry Wall

“Humans are allergic to change. They love to say, ‘We’ve always done it this way.’ I try to fight that. That’s why I have a clock on my wall that runs counter-clockwise.” – Grace Hooper

“Great minds discuss ideas. Average minds discuss events. Small minds discuss people.” – Eleanor Roosevelt

“Everything goes with bacon!” – Grant Achatz, Alinea

“In theory there is no difference between theory and practice. But, in practice, there is.” – Jan van de Snepscheut

“Experience is what you get when you didn’t get what you wanted.” – Randy Pausch

“When you don’t create things, you become defined by your tastes rather than ability. So create.” – why

“If you live each day as it was your last, someday you’ll most certainly be right.” – Steve Jobs

“You can’t connect the dots looking forward; you can only connect them looking backwards.” – Steve Jobs

“Stay hungry, stay foolish.” – Whole Earth Catalog

“Make every detail perfect. Limit the number of details.” – Jack Dorsey

“If I had asked people what they wanted, they would have said faster horses.” – Henry Ford

“Pressure makes diamonds"
– General George S. Patton

“Change only takes place through action.” – Dalai Lama

“Bad ideas are just waiting to become bad ass.”

“Shut the hell up and do it.”

“The greatest advantage usually’s also the biggest disadvantage.”

“Experience comes from bad judgement.”

Paperless with Evernote

2011-07-26T00:00:00-07:00

As a student, I get tons of paper everyday. The greatest issue with paper is finding the right one once it’s needed, without going through every single paper you have. Organizing paper is tedious.

This is where computers shine. You don’t even have to invent fancy directory structures; Spotlight in OS X, or Search in Windows can match you up with the right file with just a few keystrokes.

That said, paper has great advantages attached, too — it’s brilliant for e.g. sketching and brainstorming. I wouldn’t ever leave paper completely behind, I use my Moleskin frequently for these kinds of tasks, but that’s about the only paper I use. A hybrid-solution is Livescribe, I have one, and used it for some time, but eventually ditched it: the pros of writing notes directly on the computer outweighed the pros of using Livescribe, simply because I can type faster on my computer.

By being paperless you’ll use less time searching through your paper stacks, you’ll become much more organized, and you’ll always have your paper at hand.

Nowadays I scan everything with my Doxie, you can use any scanner, of course, if you don’t already have one though, get the Doxie. It’s compact, portable, scans in good quality and has hearts on it.

All the scanned documents go to Evernote for four reasons: first being that it’s all in the cloud, that means I can access my documents anywhere, which brings me to the second reason: great mobile apps. Third, the search functionality is excellent and that becomes even better due the final reason, OCR — Optical Character Recognizition — all my scanned document PDFs are scanned for text, and Evernote’s search will search through this text as well.

That means all your papers' text are searchable by Evernote. It even recognizes handwriting. OCR happens in Evernote’s cloud and the metadata is synced along with your notes so it’ll work everywhere Evernote works.

Every sunday I scan new paper acquired during the previous week, the Doxie software puts the scanned papers directly into Evernote, I give it a descriptive title, throw out the paper, and I’m done. That’s it.

I don’t use tags, special notebooks, or any of Evernote’s other fancy organization features. There’s simply no need with Evernote’s fantastic searching capabilities. I only follow a simple syntax for my notes' titles:

    <area> <title>

Examples:

receipt doxie scanner
sirupsen.com paperless post
recipe dad’s lasagna
physics potential energy

If I want to browse all my receipts, I search for “receipt”, if I want all notes containing “Doxie” I search for Doxie, and Evernote would return “receipt doxie scanner” and “sirupsen.com paperless post” to me. You should definitely get Evernote premium if you start using it for your scanned documents for prioritized OCR on their servers, more storage and to support an excellent service.

For quick scans on the go, mostly receipts, I use JotNot Pro iPhone — it works great and can throw the pictures directly to the Evernote app.

In classes I take notes directly in Evernote for several reasons. Typing on the computer is simply heaps faster than writing on paper, the only thing I miss from paper is the ability to make quick, rough illustrations.

As physics and mathematics are part of my school work I frequently have to put equations into my notes. Evernote has no built-in functionality that lets you do this, but LaTeXiT that comes with the MacTex bundle comes with a service that lets you transform LaTeX math to pretty pictures:

Gives you:

I’m no pro in Automator, if you happen to know how to create this functionality indepent of LaTeXiT (because LaTeXiT is slow), please contact me and I’ll include it here.

How I get shit done

2011-05-28T00:00:00-07:00

Today I decided to ditch my to do list.

The important tasks will constantly nag me, thus the most important tasks will always be fresh in my head. I never forget the main tasks.

I do, however, forget the minor, less important tasks. The actually used part of my to do list ended up being a shopping list, and I don’t need a full-blown GTD-application to keep track of my errands. The other minor tasks I’d forget were 2-minute tasks. Resolved easily by doing the task immediately after thinking of it instead of deferring it.

The real problem I was trying to solve with my to do list was procrastinating. Every Sunday I now make a list of what I need to do in the coming week, writing down tasks for each day, scattering the major tasks throughout the week. Now when I’m done with the day’s tasks I can relax feeling confident I’m on track for the week. That’s real relaxation.

Stop relying on your ORM and learn SQL

2011-03-02T00:00:00-08:00

In modern development, and in particular with web frameworks such as Rails that offer and encourage extensive use of database ORM libraries, some developers skip learning SQL in favour of using ORMs. It is as if developers think they no longer need to know SQL when they’ve got an ORM. The truth is that we are not this fortunate. You should only use an ORM if you know exactly what it is generated by the ORM and you are sure that the generated SQL is as well performing as what you could have written by hand.

Let me go through the most common pitfall I see.

You have a blog listing a bunch of posts: title, content, author, date and the number of associated comments.

Typically one would do it like this in Rails:

<% for post in @posts %>
  <h1><%= post.title %></h1>
  <p><%= post.content %></p>
  <p>
    <%= post.author %> posted on <%= post.created_at %>
    <%= post.comments.count %> comments
  </p>
<% end %>

This looks simple enough, and it is — the issue here is the query for retrieving the number of comments associated (post.comments.count) is run for each blog post, although it could easily be included in the main SQL query fetching the posts with a join:

SELECT posts.*, count(comments.id) as comments_count FROM "users" INNER JOIN "comments" ON comments.post_id = posts.id GROUP BY posts.id

Or in Rails' ORM:

Post.all(:joins => :comments, :select => "posts.*, count(comments.id) as comments_count", :group => "posts.id")

For a typical blog an extra 20 count queries are not critical, but once your database reaches a certain size a noticeable, avoidable, delay will occur on that page. Something that could have been avoided with a basic understanding of SQL.

ORMs are indeed very useful to developers, however you should not neglect learning SQL because you have it.

Every time you use your ORM you should stop for a moment and think to yourself: “Can I be sure the ORM is generating the optimum query possible here?”

Improving the Open Source user experience

2011-02-25T00:00:00-08:00

Draft

I absolutely love open source, I contribute myself and I use tons of open source software every day. I am attached to the idea that what I use is completely open, I can change everything about it if I want, I can figure out how it works, learn from it, contribute to it. Open source is many things: browsers, databases, operating systems and what not.

However, there’s one thing I always thought could be drastically improved in many open source projects: The User Experience. When I ask a not-so-techinal friend why they don’t use some open source project instead of commercial one many say that “it’s because ugly”. What they mean by ugly is that it’s hard to find what you are looking for in the interface, and yeah, it’s usually not eye candy either.

Most open source projects have no designers attached. However, some do, for instance Ubuntu, most people, again non-techinal people, I know like Ubuntu because it’s pretty and easy to use:

For every % in sales invested in product design, a company’s sales and profits rise 3-4% on average. From A Whole New Mind, p. 78

This is relevant for open source too; good product design attract users.

People tend to design for themselves, and generally it just doesn’t work when developers create software for non-developers. Even so, developers are taking care of designing and implementing the user interface in the majority of open source projects. Leaving us with an unconsistent, probably not well thought through, interface that is very much hacked together and is something the developers just want to get over with. Most importantly: An interface which may confuse users. Designing interfaces usually is not what developers enjoy doing the most, very much reflected in the finished interface.

This is where the designers come in; we need designers to help the developers to create amazing frontends for the open source applications.

There are a couple of problems dragging designers into open source projects, and we can start addressing the reason why it hasn’t happened a lot in the past. To put it briefly: Designers are scared of developers. Developers speak a foreign language, they are like aliens. Developers don’t package their source code in .zip files, instead we use some scary thing called version control. The frontends typically presuposes a pretty extensive knowledge of the backend, a knowledge the designers simply don’t have and will have a pretty tough time getting. Designers don’t know how to modify a QT GUI, although they may have a daunting idea on how the interface could be so much better.

How do we solve this? Communication. Developers need to get in touch with the designers and talk with them about how they can get the designers started contributing. For a web application, a skilled web designer might have an easier time than with a GUI, but communication is still required to understand the interface’s needs as well as implementation details in terms of communicating with the back end.

The designers I have talked to would love to get involved, the motivation is there they get to put this on their portfolio and they enjoy designing — the crucial thing is communication and getting started. Designers want to have easy access to developers of the project they can ask all kinds of questions, developers that might also help the designer implement the interface change itself. IRC is probably not the designer’s favorite communication channel, but it’s the only one developers know and it’s a great way to perform a group chat, involving the entire community around the project.

Setting up Unicorn with Nginx

2010-10-22T00:00:00-07:00

Unicorn is a cool new Ruby HTTP server, and we like it because it’s Unix.

Unicorn is an HTTP server for Rack applications designed to only serve fast clients on low-latency, high-bandwidth connections and take advantage of features in Unix/Unix-like kernels.

I’m going to talk about Unicorn’s design, and then I’ll walk you through setting it up on your server.

Design

Its design is Unix:

Do one thing and do it right.

For instance, load balancing in Unicorn is done by the OS kernel and you manage the processes by sending signals.

Unicorn has a whole document dedicated to address its design. Here are some of the things:

Load balancing

Load balancing between worker processes is done by the OS kernel. All workers share a common set of listener sockets and does non-blocking accept() on them. The kernel will decide which worker process to give a socket to and workers will sleep if there is nothing to accept().

This is really, really cool. Normally load balancers reverse proxy to the worker that is most likely to be ready, usually based on when the last request was sent to that worker. But there are a few problems to that method:

Some requests take longer to complete (e.g. heavy I/O)
Software fails (and it always does, at 2am if you are a software engineer)

Unicorn uses a shared Unix socket (although it can also use TCP, but Unix domain sockets are faster). When a worker is not currently serving a request, it listens on the Unix socket and fights with the other workers to accept() connections. This is called push balancing. It’s great because it solves the problems from above.

Slow clients

Some clients are slow. And those clients can slow down everything. Twitter has put this issue nicely in their blog post on why they moved to Unicorn:

Every server has a fixed number of workers that handle incoming requests. During peak hours, we may get more simultaneous requests than available workers. We respond by putting those requests in a queue.

Welcome to the (retro)world of evented I/O; here’s the catch:

This is unnoticeable to users when the queue is short and we handle requests quickly, but large systems have outliers. Every so often a request will take unusually long, and everyone waiting behind that request suffers. Worse, if an individual worker’s line gets too long, we have to drop requests. You may be presented with an adorable whale just because you landed in the wrong queue at the wrong time.

And then they continue to talk about supermarket queues, read the whole thing.

Unicorn disfavors slow clients. Instead of stacking people up in long queues behind some guy who’s connection fails miserably; Unicorn lets that one guy fail. The Unicorn master process knows exactly how long each of its workers has been processing a request, and if it takes longer than timeout (configured; usually 30s) to finish the request, it kills the worker and immediately forks a new one ready to serve requests. Affected clients are given a 502 error page.

Deploying

With Unicorn one can deploy with zero downtime. This is rad stuff:

You can upgrade Unicorn, your entire application, libraries and even your Ruby interpreter without dropping clients.

The Unicorn master and worker processes respond to SIGNALS. Here’s what Github does:

First we send the existing Unicorn master a USR2 SIGNAL. This tells it to begin starting a new master process, reloading all our app code. When the new master is fully loaded it forks all the workers it needs. The first worker forked notices there is still an old master and sends it a QUIT signal.

When the old master receives the QUIT, it starts gracefully shutting down its workers. Once all the workers have finished serving requests, it dies. We now have a fresh version of our app, fully loaded and ready to receive requests, without any downtime: the old and new workers all share the Unix Domain Socket so nginx doesn’t have to even care about the transition.

We can also use this process to upgrade Unicorn itself.

This behaviour requires a bit of Unicorn-config-fu to achieve, but Github has shared their config with us. There’s a handy bash script taking advantage of the SIGNAL Unicorn API baked in with Unicorn.

Unicorn makes 100% uptime possible.

Rails on Unicorns

Ready power your app by rainbows?

We’re going to set up Nginx in front of Unicorn.

Nginx

Start by installing Nginx via your favorite package manager. Afterwards we need to configure it for Unicorn, we’re gonna grab the nginx.conf example configuration shipped with Unicorn, the Nginx configuration file is usually located at /etc/nginx/nginx.conf, so place it there, and tweak it to your likings, read the comments—they’re quite good.

In nginx.conf you may have stumbled upon this line:

user nobody nogroup; # for systems with a "nogroup"

While this works, it’s generally adviced to run as a seperate user for security reasons and increased control. Let’s create an Nginx user, and a web group:

$ sudo useradd -s /sbin/nologin -r nginx
$ sudo usermod -a -G web nginx

Configure your static path in nginx.conf to /var/www, and give permissions to that folder to the web group:

$ sudo mkdir /var/www
$ sudo chgrp -R web /var/www # set /var/www owner group to "web"
$ sudo chmod -R 775 /var/www # group write permission

Then add yourself to the web group so you can modify the contents of /var/www:

$ sudo usermod -a -G web USERNAME

Unicorn

Time for flying rainbow horses. Start by installing the Unicorn gem:

$ gem install unicorn

You should now have Unicorn installed: unicorn (for non-Rails rack applications) and unicorn_rails (for Rails applications version >= 1.2) should be in your path.

Time to take it for a spin! (You may wish to re-login with su - USERNAME if you haven’t already, this ensures your permission tokens are set, otherwise you will not have write permission to /var/www)

$ cd /var/www
$ rails new unicorn

There we go, we now have our Unicorn Rails test app in /var/www! Let’s fetch some Unicorn config and start the madness. We’re going for the unicorn.conf example that comes with the Unicorn source:

$ curl -o config/unicorn.rb https://raw.github.com/defunkt/unicorn/master/examples/unicorn.conf.rb

You might want to tweak a few things:

APP_PATH = "/var/www/unicorn"
working_directory APP_PATH

stderr_path APP_PATH + "/log/unicorn.stderr.log"
stdout_path APP_PATH + "/log/unicorn.stderr.log"

pid APP_PATH + "/tmp/pid/unicorn.pid"

Our Unicorn is ready!

Rainbow magic

Start the Nginx deamon, how this is done depends on your OS. And then start Unicorn:

$ unicorn_rails -c /var/www/unicorn/config/unicorn.rb -D

-D deamonizes it. -c should be pretty obvious; it specifies the configuration. In production you will probably want to pass -E production as well to run the app in the production environment.

That’s it! Visiting localhost should take you to the Rails default page.

A Rubyist's development environment

2010-09-19T00:00:00-07:00

I consider myself as a Rubyist and a minimalist. I want my tools to be few, and sharp. That means I only want few tools, but I want to master these tools. Now it’s been about a year since I started programming, this post is supposed to give you a look into my toolbox. I hope it can be of inspiration to you.

I’ve open sourced all my dotfiles on Github.

Operating System: Linux and Mac

My primary development platform is my desktop running Arch Linux. It’s a dual screen setup, which I learned to love. I also own a Macbook, primarily used for schoolwork and field coding.

As for my desktop setup of noteworthy tools besides my editor, I use bleeding-edge Chromium as my browser. I might switch to Uzbl someday. I use Openbox as my window manager. Sakura as my terminal, simply because it’s lightweight, simple to setup and it does its job.

I have Openbox configured to act like Vim, and for Chromium I use Vimium to achieve the same Vim behavior. In theory I never have to touch my mouse.

Shell

As for my shell I just use bash. I know the cool kids use zsh, but I simply haven’t bothered to set it up, and I’m really quite happy with bash.

My bash configuration is pretty simple. It just defines some default values, source a few things, and add to my $PATH. It also sets my PS1 which consists of only the current directory. I figured that I already know my username, and hostname. Furthermore I really don’t need to know the entire absolute path of the current directory.

Editor: Vim

I’ve been through many editors. Many. Believe me. A little less than a year ago, a friend recommended me Vim. And I started digging into it. In the beginning, it was hard. But he promised me it’d be worth it. So I sticked to it. In the start, I felt less productive in Vim, because it was somewhat hard to learn. After a few days in it however, I began taking advantage of the endless sets of commands, this all resulted in a more productive me. I now love Vim, and nowadays I almost do all of my text-processing in it: I take notes in Vim, I’m writing this very blog post in Vim, and I make kickass code in Vim.

My Vim setup really is nothing special. I use a few plugins, and I have a small configuration file which is just parts stolen and compiled from others. I can’t remember who I stole what from, though. So they are not credited. I use Monaco as my Vim (and terminal) font, I simply like this font a lot. Screenshot.

Syncing: Dropbox

As I have multiple computers, I sync everything with Dropbox. This also has the benefit of being (additional, I have everything under git, too) backup. My Dropbox holds mostly configuration files and code. The rest is in the cloud. With everything in my Dropbox, I make symbolic links from the Dropbox.

Configuration between multiple computers

As I have multiple computers, I want my configuration files (dotfiles) to change on other computers as soon as I have changed it somewhere else. In the beginning I had an ugly Rake task to do all this symbolic linking, but later I discovered Homesick.

Homesick is sorta like rip, but for dotfiles. It uses git to clone a repository containing dotfiles, and saves them in ~/.homesick. It then allows you to symlink all the dotfiles into place with a single command.

When you clone a castle, as they are called in Homesick, it puts the castle in ~/.homesick/repos/<repo>, for instance:

$ homesick clone Sirupsen/dotfiles # goes to ~/homesick/repos/Sirupsen/dotfiles

Instead of updating the dotfiles with Git via pulling, however, I wanted it to go through Dropbox, so changes are reflected on my other computers instantly. Later, I can commit these changes:

$ ln -s Dropbox/dotfiles ~/.homesick/repos/

Now I can symlink everything easily:

$ homesick symlink dotfiles

Using dual screen for coding

When I work, I usually work on two monitors. A 19", and a 24".

On my 19" I have Pidgin running. This makes me able to talk to colleagues, or friends while working on my other monitor. I might also shring my windows here, and have another terminal open with tests.

On my 24" I have my browser running in the right side, taking up about 50% of horizontal space. When i am coding, this is great for documentation and general googling, githubing and ticket managing while coding. I have experimented with fullscreen Vim, however I just don’t need more than these 80 columns horizontally, so this setup works great. More vertical space is always nice, I’ve heard great things about having a screen that can be turned around to a portrait view for coding. I usually have my terminal running beneath my Vim window, it’s super easy to switch between them with my Openbox Vim configuration.

Get started right with RVM

2010-09-07T00:00:00-07:00

I’ve always run Ruby, and I’ve always used RVM. But it’s not until recently when I attended Aarhusrb and @chopmo gave a talk on RVM, that I realized how wrong I was using RVM. Basically, I’m somewhat always using system Ruby, installing all gems with sudo. However, digging into RVM I found useful features, such as gemsets, installing gems on a user basis, .. Thus I realized I ideally should run my entire Ruby environment through RVM, instead of only using RVM for anything not supported by my system install.

Here are my new discoveries, compiled down to a blog post. Most of this can be found in the great RVM documentation.

Installing RVM

If you don’t already have RVM installed, you should do it now. It’s fairly simple to install:

$ bash < <( curl http://rvm.beginrescueend.com/releases/rvm-install-head )

If there are > 1 users on your system wishing to use RVM, you may want to look into a system-wide installation

And then add what it says to .bashrc, .bash_profile or whatever you use.

$ echo '[[ -s "$HOME/.rvm/scripts/rvm" ]] && source "$HOME/.rvm/scripts/rvm"' >> .bashrc

What I hate about installing gems is that it’s slow due to ri and rdoc. I never use this local documentation anyway, and it’s faily easy to disable the generation of it; speeding up your gem installs a great deal. Just put this in your ~/.gemrc:

gem: --no-ri --no-rdoc

Verify whether the rvm command works, and use the chance to also check your system notes:

$ rvm notes

Uninstalling all gems in system Ruby (Optional)

Now this is not required, I just did it to clean my system. Therefore you can safely skip this step.

Now that you have RVM installed, you can simply empty the gemset (this’ll all make more sense later):

$ rvm gemset empty

Before running this you can take a backup of all your currently installed gems:

$ rvm gemset export backup.gems

This leaves you with a file, desribing all your system’s gems. (Quite a file, in my case). If you at some point need to install all these gems again, it’s simply a matter of running:

$ rvm gemset import backup.gems

We’ll talk a bit more about rvm gemset {import,export} later; why it’s as nifty as it is.

Installing Rubies

Rubies are essentially Ruby versions, let’s go ahead and get Ruby 1.9.2 first, and set that as our default interpreter. Afterwards, we’ll install Ruby 1.8.6. And then we’ll try to switch between the two environments.

Installing 1.9.2 is very easy, it’s simply a matter of issuing:

$ rvm install 1.9.2

It can take a while to install, since it compiles from source.
Let’s switch to it; verify it all works!

$ rvm 1.9.2
$ ruby -v
ruby 1.9.2p0 (2010-08-18 revision 29036) [i686-linux]

Great!
We want 1.9.2 to be our default interpreter:

$ rvm --default 1.9.2

Restart your shell, and run ruby -v to verify it’s all working as expcted. Let’s install 1.8.6 along with 1.9.2:

$ rvm install 1.8.6

And then we can switch to it, like we switched to 1.9.2 before:

$ rvm 1.8.6

(Which is a shortcut for rvm use 1.8.6). You are now up and running with two Ruby environments, congratulations!

Gemsets

What?

The shortest explanation, is found within the name. Gem-sets.
RVM’s documentation puts it like this:

RVM gives you compartmentalized independent ruby setups. This means that ruby, gems and irb are all separate and self-contained from system and from each other.
You may even have separate named gemsets.
Let’s say, for example, that you are testing two versions of a gem with ruby 1.9.2-head. You can install one to the default 1.9.2-head and create a named gemset for the other version and switch between them easily.

Ideally you have a Gemset for each project that you are working on. This keeps your system clean, and eliminates “Gem clutter”. Also running bundle install will use the project defined gemset to also store the gems.

Creating and using a gemset

So let’s go ahead and create a gemset:

$ rvm gemset create foo # Create gemset 'foo'
'foo' gemset created (/home/sirup/.rvm/gems/ruby-1.9.2-p0@foo).

$ rvm 1.9.2@foo # Switch to Ruby 1.9.2 with gemset 'foo'
$ gem list # Lists installed gems
*** LOCAL GEMS ***

Let’s try to install a few gems in our new gemset, note again, we do shouldn’t use sudo to install gems, as that would install it outside of your gemset:

$ gem install rails
$ gem list
gem list
*** LOCAL GEMS ***

abstract (1.0.0)
actionmailer (3.0.0)
actionpack (3.0.0)
activemodel (3.0.0)
[..]

Great! Let’s switch back to our global gemset (this is the default gemset, you can also switch to it more explicitly with rvm 1.9.2@global):

$ rvm 1.9.2

And gem list here returns an empty list, as expected since no gems are installed in the global gemset.

Dumping and loading gemsets

Let’s try that export feature, that I previously explained as a backup solution, again:

$ rvm 1.9.2@foo
$ rvm gemset export rails.gems
$ cat rails.gems
abstract -v1.0.0
actionmailer -v3.0.0
actionpack -v3.0.0
activemodel -v3.0.0
[..]

You are then free to send rails.gems to someone else, and that person would simply import the gemset like so:

$ rvm use 1.9.2@rails --create # Shortcut to create, then switch to it
$ rvm gemset import rails.gems

Which would install all the gems from rails.gems, and the exact same versions. This is great when you work in teams, because we all tried messing up the versions..

The global and default gemset

Two interesting gemsets are the global (~/.rvm/gemsets/global.gems) and default (~/.rvm/gemsets/default.gems) gemsets.
Gems in the global gemset, will be added to the global gemset in every new Ruby you install. rake and rdoc are good examples of handy global gems.
The default gemset is the gems included in every new gemset.

rvmrc

Now there are different kinds of rvmrc files:

System /etc/rvmrc
- System wide configuration
User ~/.rvmrc
- User wide configuration
Project .rvmrc
- Project wide configuration

The most interesting one is the project .rvmrc. Every time you cd, RVM looks for a file called .rvmrc. If it finds it, it executes it.
Ouput from bash says more than a thousand words:

$ echo "rvm 1.8.6@project" > ~/projects/ruby-1.8.6-project/.rvmrc

I recieved a tip from @wayneeseguin, that we can be even more sneaky about this:

$ rvm --create --rvmrc 1.8.6@project

This will create the gemset, and the .rvmrc file!

~/projects $ ruby -v
ruby 1.9.2p0 (2010-08-18 revision 29036) [i686-linux]
~/projects $ cd ruby-1.8.6-project/
~/projects/ruby-1.8.6-project $ ruby -v
ruby 1.8.6 (2010-02-05 patchlevel 399) [i686-linux]
~/projects/ruby-1.8.6-project $ rvm gemset name
project

My favorite configuration option is rvm_gemset_create_on_use_flag=1, having this line in /etc/rvmrc or ~/.rvmrc, gemsets will be automatically created when used:

$ rvm gemset list
gemsets for ruby-1.9.2-p0 (found in /home/sirup/.rvm/gems/ruby-1.9.2-p0)

foo
global
$ rvm gemset use foobar
Now using gemset 'foobar'

@wayneeseguin sent in another tip about bash and zsh completion.

You can read more about rvmrc in RVM’s documentation.

Conclusion

This is all briefly describing what can be found in RVM’s (fantastic) documentation. For basic use, this article should cover the main topics, however, RVM can still do a whole lot more than I adressed here. The goal of this post was simply to get you started well, and right, with RVM.

Discuss this on Hacker News

The switch to Github Pages

2010-07-23T00:00:00-07:00

Until recently I’ve never had my own server; always hosted at friends, for free. Usually limiting me in terms of mobility regarding technologies. One of the first thing which made me stay away from Ruby — my host would only support PHP. That’s really an advantage for PHP, in terms of community growth.

A few months back, I decided to finally buy myself a server. I had been into Ruby for a while, and I wanted to deploy a cool personal site, handling some dynamic features as well like: pulling my Github repositories, and listing them directly at /projects.

I looked around for a low end box, since I didn’t need much power. While not being very server-wise, I still needed some. I had at this point already written What I wish a Ruby programmer had told me one year ago which became quite popular, with something like 20.000 hits the first day. A social media attack like that, requires some server power. Luckily, the server I had my blog hosted on at that point, could easily manage such a load. However, when I wanted to move my blog to a less powerful server, my own, I’d still need some power in order to handle these attacks. But the major problem here, is that I don’t want to pay for server power I’ll rarely take full advantage of, so I had to find balance between pricing a student could afford, and power.
I wanted to make the move because I didn’t want to be limited to Wordpress, or PHP-based stuff. I was set to develop my own little solution, for the fun and learning process of it.

I ended up buying a Fivebean (they are now called bluemile) node with 256 mb. of ram, and 512 mb. burst. This should do good, and would only be $16/month, which seemed fair. The first month, I used it a lot — I had never had a server before, so I learned a great deal on this node. I set it up with Arch Linux — following the philosophy:

For a personal Linux server, use the distro you feel the most comfortable with.¹

As I’ve had previous experience with Arch Linux, I decided to go for it on the server-side too, even though Arch tends to be bleeding edge — it worked out just fine. I set the web server up with Nginx which I had heard great things about, mostly it was to try something else than Apache. I also set up Passenger for Ruby/Rack deployment. I even documented this process on the Arch Linux wiki.

This was all a great experience. I ended up having some issues with Fivebean, in terms of my node being DDOSSed, resulting in poor performance and occasional downtime; about 5 minutes per hour in average. I contacted the support, and they told me they’d move me — great! However, issues kept happening so I interpreted it as a sign: try this Linode thing everyone is buzzing about!

And I did. Linode is great, and appears fast — SSH worked much faster than what I had been used to with my Fivebean node. So I kept with Linode, and at their birthday, they even boosted the ram of all slices — for free!

At some point I realised something though: I just hosted static stuff on my site, I barely used it for anything dynamic anymore. I reminded myself Github had a service for just this: Github Pages:

The GitHub Pages feature allows you to publish content to the web by simply pushing content to one of your GitHub hosted repositories. There are two different kinds of Pages that you can create: User Pages and Project Pages.²

I had one issue with Pages though: I wanted my host my blog there. Quickly I found that Github already, of course – had internally developed a RubyGem called Jekyll:

Jekyll is a blog-aware, static site generator in Ruby³

By formatting your blog posts in either Markdown, Textile or HTML, you could use Liquid to format your pages. Resulting in the perfect environment for any hackers website. I’m using this right now, to write this post. Having a Textile file, editing it with Vim. Whenever I want to deploy a new post, or change something — I just push it to my site repository.

The best thing about Github Pages is, that it has allowed me to cancel my Linode, and I can also redirect my domain here. Furthermore, my blog should be able to handle Social Media attacks just fine now. And all this is for free.
If you can see yourself in some of this, I advice you to try out Github Pages — it’s been a great experience for me this far.

If you want to run a blog, and are already using another blog system, like Wordpress, Jekyll has some built in code for converting your blog posts for Jekyll!

My entire site is open source, hosted at Github — of course. Perhaps it could help you get started!

¹ Own wisdom

² http://pages.github.com

³ http://github.com/mojombo/jekyll

A simple Imgur Bash screenshot utility

2010-05-10T00:00:00-07:00

I use screenshots a lot, every day. Mostly when I do instant messaging, they can usually help explain something much quicker than anything else. It’s rare that I edit the screenshot, and in these rare occasions, it doesn’t bother me all that much having to fire up Pinta or Gimp—to make these small changes.

Installation

shoot’s dependencies are:

curl
grep
scrot
xclip
libnotify (optional)

You probably have those already, if not, install them via your package manager.

curl http://sirupsen.com/static/misc/shoot > ~/bin/shoot && chmod 755 ~/bin/shoot

Assuming ~/bin is in your $PATH, you’re ready to shoot:

$ shoot
$ xclip -selection c -o
http://imgur.com/Z8prG.jpg

I recommend that you bind the script to a key, so you can easily activate it.

Coming up with the script

The functionality needed, came down to this:

Select region and take screenshot of this region
Upload screenshot to Imgur
Put direct link to screenshot into the clipboard

Taking a screenshot of a specified region is quite easy with scrot:

scrot -s

Then using curl to upload the picture, via the Imgur API:

curl -s -F "image=@$1" -F "key=api-key" \
http://imgur.com/api/upload.xml

This returns some XML containing, among other things, the direct URL to the uploaded screenshot, which we extract from the returned XML with a simple regex:

grep -E -o "<original_image>(.)*</original_image>" | \
grep -E -o "http://i.imgur.com/[^<]*"

Now we have the direct link, and then it’s simply a matter of putting this all into the clipboard with xclip:

xclip -selection c

Now this is optional, but quite handy. It uses libnotify to notify you when the image is uploaded, and ready to be pasted:

notify-send "Clipboard ready!"

The script

And I compiled all this into this simple script (I’m aware that this can be a one-liner and everything but this just seems more readable and works. If you have a better solution, be sure to contact me!):

function uploadImage {
  curl -s -F "image=@$1" -F "key=486690f872c678126a2c09a9e196ce1b" http://imgur.com/api/upload.xml | grep -E -o "<original_image>(.)*</original_image>" | grep -E -o "http://i.imgur.com/[^<]*"
}

scrot -s "shot.png" 
uploadImage "shot.png" | xclip -selection c
rm "shot.png"
notify-send "Done"

That’s it. Hopefully you’ll enjoy it as much as I do.

What I wish a Ruby programmer had told me one year ago

2010-04-28T00:00:00-07:00

Warning: Biased content follows.

Scroll down if you just want to skip to my wise words.

One year ago, I started coding for real again. I dumped wasting times on stupid games and so on. I like building websites, so I started by going back to the roots. HTML & CSS which I had coded when I was about 10, and it didn't take me long before I had moved from tables to div tags and all. I learned myself to hand-code it, and not rely on software like Dreamweaver. Resulting in better, more compact and valid HTML. I had played around with PHP when I was about 11, so I decided to build some stuff in it again.

I should never have done that, I have realized. I used about 4 months in PHP, picking up bad habits. At some point, I found myself reaching points where I saw PHP solutions plain stupid. I didn't have experience with any other languages, but I knew there had to be better ways. So I decided to dive into Python, and later look at the Django web framework. So I did.

After a few days playing around with Python, I felt okay with it. I didn't love Python, but it was fairly simple, and from the simple Django examples I felt confident I was ready to proceed and expand my literacy in Python via Django. After following the basic tutorials, I felt Django was already superior to PHP.

I had heard about this evil language called Ruby and some framework called Rails, I had not considered it though because of three (stupid) reasons:

Highest ratio of smug fanboys
End-statements
Ruby had become popular due to Rails, not the other way around as it is with Django

So a Saturday night, I turned off the light, locked the door and sealed the windows. It was time to check out this Japanese creation. The fanboys all over the web seemed to recommend this fabulous book called Why's (poignant) guide to Ruby. I installed Ruby, and dove into the book.

A few hours later, I had forgotten everything about Python. Stupid language. Ruby was where it was at, and I instantly started recommending it to all my code-buddies. It's such an awesome language, why not spread the joy? They said I was a fanboy, and told me to gtfo. And I quickly realized what had happened.

Ruby is evil

Ruby is indeed evil. So evil. Extremely evil. But why so evil? Because it's so beautiful. The syntax is so elegant, everything are objects. Everything makes sense. The Ruby-way of doing things is so sexy.

I quickly headed over to #ruby and asked them what I should do to practise my all-so-awesome Ruby skills, and some guy recommended me coding a todo-app. It seemed it was the new semi-advanced-but-no-so-advanced hello world. So I did, and here's the extremely awesome output (be prepared, it's extremely bad code and you should NEVER do something like this in Ruby):

class Todo
  def initialize(*argv)
    @argv = argv

    begin
      send(@argv[0])
    rescue TypeError
      list
    rescue NoMethodError
      puts "Command #{@argv[0]} not found.\n\n"
      help
    end
  end

  # Lists help information
  def help
    puts <<-help
Commands for Todo.rb:
   add [task name] - Add a new task
   list - Lists all tasks
   done [task id] - Complete a task
   help - Prints out this information
    help
  end

  # Add task
  def add
    unless @argv[1]
      puts "Lacking argument [name]"
      exit
    end

    # Append task to file
    contents = File.read('todo.td')

    File.open('todo.td', 'w') do |f|
      todo = contents + @argv[1] + "\n"
      f.write(todo)
    end
  end

  # List all tasks
  def list
    # Read content
    contents = File.read('todo.td')
    puts "No tasks" unless contents

    # Show it with ids
    i = 0
    contents.each_line do |todo|
      i += 1
      puts "##{i} - #{todo}"
    end
  end

  # Finished a task
  def done
    unless @argv[1]
      puts "Lacking argument [id]"
      exit
    end

    # Put tasks into an array
    todos = File.read('todo.td').split("\n")

    unless todos
      puts "No tasks"
      exit
    end

    puts "Completed task: " + todos[@argv[1].to_i - 1]

    # Delete task from array and make string
    todos.delete_at(@argv[1].to_i - 1)
    content = todos.join("\n")

    # Update file
    File.open('todo.td', 'w') do |f|
      f.write(content)
    end
  end
end

todo = Todo.new(*ARGV)

Proudly I showed it to the guy who recommended me to create a Todo-app. "Look at this! Ruby is so narwhal!" It took him a while to reply. It would've taken me a while to reply too if somebody showed me such code. It looks like some Bash code, in an object oriented language. Woah. So this guy, he was very helpful and told me he'd make a skeleton for the app. and make me fill in the holes/methods, it was something like this:

class TodoList
  def self.load(file)
      # read the file, create a list, create items, add them
  end

  def initialize
  end

  def add(item)
  end

  def write(file)
    # write the file, only write the undone items
  end

  def [](id)
    @list[id]
  end
end

class TodoItem
# provide reader and setter for name and state

  def initialize(name)
    # store name
    # set state to undone
  end
end

# ---
# the library will be used like this:
# list = TodoList.load("todo.td")
# list[0].done = true
# list.add TodoItem.new("another cool item")
# list.write("todo.td")
#

So I did. It took a while to adapt from the bad PHP-style, to the Ruby-style. I ended up with this. And then I added an interface. And then meta-programming. And then I was in love.

So the title of this post is "What I wish a Ruby programmer had told me one year ago..", and that's quite an intro. Since what I wish a Ruby programmer had told me is not much, but could've saved me 4 months in company with PHP.

Here's what I'll tell anyone asking me how they should get into programming:

"First, learn Ruby (buy a book). Play around, create a Todo-app. Create simple programs to handle system tasks for you. But always remember to use classes, and separate the interface from the functionality. In the end this will be pain, you'll always think about making it appear Rubyish, but at some point - it becomes natural. And when it has become natural, you go create a Gem. If you create a big Gem, with much functionality - split it into more Gems, and make it require those. Or use other peoples Gems. If you want to move on with developing web applications, start out simple. Check out a lightweight framework like Sinatra, it's cool and very fun to work with. Move on to Rails if you want, it takes longer to learn, but it is much faster to develop in."

And perhaps point them towards Linux, if they are up for it:

"I do not believe Windows is the best development platform in the world for Ruby. I recommend you to try out Linux (or OS X, if you've got the money for it). Start with a simple distribution, like Ubuntu. And then I recommend something like Arch Linux whenever you feel like you are ready for something more advanced, assuming you want to learn more about how Linux works!"

Note: I'm biased. And I know it. Ruby is not a language for everyone, and PHP is not a bad language - it's just not for me. Neither is Python a bad language - it's just not for me. Windows is not a bad operating system - It's just not for me. I advise you to try different languages/operating systems, and eventually find the one you feel at home in.

Create your first Ruby Gem and release it to Gemcutter

2010-04-20T00:00:00-07:00

A few days ago I was set off to create my first RubyGem. There are many resources on how to do this, but it took me a good while to gather all the information I figured I’d need for my application, so I’ve decided to gather my bit of knowledge in this article.

This article’s goal is kick start the creation of your first Gem. To make this experience more enjoyable, I’ve chosen to use a gem called Jeweler.

Note: I am by no means a “ruby-pro”. I have only created a single Gem, but I thought this article could be helpful to a lot of people, and thus I wrote it. If you have any corrections, questions, or suggestions please either email me at sirup@sirupsen.dk or comment below.

Preparing

.. for world domination!

I assume you already know a bit of Ruby, that you know what RubyGems is, and you have already downloaded a few gems, and used some of them in your work. Now your are simply seeking to create your own Gems. You are indeed in for a fun time, coding gems is lots of fun!

Before we can begin, install the Jeweler gem via RubyGems:

$ gem install jeweler

Jeweler is a tool to create the basic skeleton for your Gem, as well as managing the gem.

Creating your gem

.. with your mighty companion Jeweler

Once Jeweler is installed, you want to create your Gem skeleton. I'm going to create a simple Hello World gem for the sake of example, and later on explain a bit about how you could manage your own Gem (at the very least my 2 cents about how a gem should be done).

$ jeweler helloworld # Should be all small letters

   create  .gitignore
    create  Rakefile
    create  LICENSE
    create  README.rdoc
    create  .document
    create  lib
    create  lib/helloworld.rb
    create  test
    create  test/helper.rb
    create  test/test_helloworld.rb
Jeweler has prepared your gem in helloworld

Now your gem skeleton is ready! Let's get in there and check it out.

$ cd helloworld
$ ls
lib/  LICENSE  Rakefile  README.rdoc  test/

This structure might look familiar to you. (Assuming you are like me and have already stalked a few Gems' sources over at Github) Now I'll attempt to explain what these files and folders are.

lib/

This is where your application lives, this is where you'll probably spend the most of your time working on your gem. It is common to have a folder inside this folder called whatever your gem is called (in this example, that would be helloworld), in which your app. is split into a few files, for organizations sake. And then have lib/<gem name>.rb require these files (as /lib/<gem name>.rb is what is required by Ruby whenever somebody requires your gem in their own project).

My 2 cents on organizing stuff in here (skippable)

As said, I am in no way an expert. But this is how I would do it.

My first gem is a gem for a file storage service (Anyhub) which should do two things:

Create a library for easy Ruby interaction with Anyhub
Contain a small CLI for Anyhub based on it's own library

So I figured I would have a module, containing a few classes:

Upload (for uploading files to Anyhub)
Account (to manage ones Anyhub account)
Runner (to manage the CLI)

The Upload class would simply be able to use the account class, to check if an account was configured in a config file (f.e. account_config.yaml). If a config file was present, it would upload the file(s) specified in arguments to the script. Otherwise, it would return an error. Runner (the CLI) would respond to this error, allowing the user to type in his details so they could be used for the ongoing upload, as well as any following uploads (by saving the details to account_config.yaml via the Account class).

Now, I had made a perfectly good module. The only thing it needed was arguments send to Runner, which would activate it all. By doing a little research I figured if I created the directory bin/ and threw in a file here, this file would automatically be inserted into the installers own bin (f.e. /usr/bin on Linux if installed for all users). So I created the bin/ directory, and a file in here called anyhub with a Ruby shebang at the top. This file simply instanced the Runner class with ARGV.

Now this is just my little not-so-fancy gem theory. It's not exactly done this way (yet) because Anyhub didn't have an API at first - so I created the first version without the Account class, so it might not be exactly like this at the Github repo. just yet.

Anyhub gem @ Github.

LICENSE

Simply a file which contains the license for your project. By default MIT with Jeweler.

Rakefile

Rake configuration for your project. It is here you can define rake tasks, and configure your project (in terms of the name of it, dependencies, description and similar).

Readme.rdoc

The Readme file for your project. If you create a Github repo. it'll show up there. It is also "the index" for your Gems' documentation.

test/

It is here you create your tests.

Configuring your Gem

Remember a few lines ago, I told you how you could configure your Gem via Rakefile? As you might have already guessed, we're going to open that very file now, to configure our example Gem.

After rubygems and rake has been required by Rakefile we see some fancy code, and then something which looks like some configuration. This is indeed where we configure our example Gem. You mostly only need to configure the summary and description the first time, I did it like this:

begin
  require 'jeweler'
  Jeweler::Tasks.new do |gem|
    gem.name = "helloworld"
    gem.summary = %Q{I'm a helloworld gem! I like to hello the world.}
    gem.description = %Q{This is a fancy little test gem.}
    gem.email = "sirup@sirupsen.dk"
    gem.homepage = "http://github.com/Sirupsen/helloworld"
    gem.authors = ["Sirupsen"]
    gem.add_development_dependency "thoughtbot-shoulda", ">= 0"
    # gem is a Gem::Specification... see http://www.rubygems.org/read/chapter/  20 for additional settings
  end
  Jeweler::GemcutterTasks.new
rescue LoadError
  puts "Jeweler (or a dependency) not available. Install it with: gem install   jeweler"
end

A little something more on configuring

.. which can be skipped.

If your gem has any dependencies, you can add them here. Dependencies in this context mean "gems which my gem depends on". You should add them, because if you do they are automatically installed along with your Gem whenever somebody tries to install your Gem. If you don't, they'll just get a good ton of errors when they try using your gem.

Do add dependencies, simply add this to your Rakefile:

gem.add_dependency "gem", "version"

For example, in my gem I used the Curb Gem, and therefore I added this to my Rakefile:

gem.add_dependency "curb", ">= 0"

(>= 0 just means "I don't care about which version of the Gem it is, as long as it's there", mostly because I couldn't find much version-specific documentation Curb, otherwise I would have done this properly.)

Let's add some sample code

Now it's time to add some code to our helloworld Gem. I simply open /lib/helloworld.rb, and add these few lines of code:

module HelloWorld
  def self.do
    "Hello World from the all mighty helloworld Gem!"
  end
end

So HelloWorld.do would return the string "Hello World from the all mighty helloworld Gem!". Great, so far, so good.

Version

In order to finish our Gem, we need a version file. Now because Jeweler is so awesome, we don't even need to use our editor to do this, simply execute the following command:

$ rake version:write

And the VERSION file is created. It's not that fancy though.

$ cat VERSION
0.0.0

But that seems correct. This is our first Gem build, so of course, the version is 0.0.0 as of now!

Install it!

Now you can install the Gem. It's very easy:

$ rake install
Password:
(in /home/sirup/Code/Ruby/helloworld)
Generated: helloworld.gemspec
helloworld.gemspec is valid.
WARNING:  no rubyforge_project specified
  Successfully built RubyGem
  Name: helloworld
  Version: 0.0.0
  File: helloworld-0.0.0.gem
Executing "gem install ./pkg/helloworld-0.0.0.gem":
gem install ./pkg/helloworld-0.0.0.gem
Successfully installed helloworld-0.0.0
1 gem installed
Installing ri documentation for helloworld-0.0.0...
Updating class cache with 1983 classes...
Installing RDoc documentation for helloworld-0.0.0...

Moment of truth

irb --simple-prompt
>> require 'helloworld'
=> true
>> HelloWorld.do
=> "Hello World from the all mighty helloworld Gem!"

(Note: If you are not using Ruby 1.9, you might need to require 'rubygems' before requiring helloworld)

Awesome, it works. I hope this has helped you towards creating your first gem. You are welcome to leave a comment, or contact me if you run into any trouble.

Further information

You'll find it all if you visit Jeweler at Github. Below is for quick reference.

Github

I advice you to commit all your code, and push it to Github. Makes it easy for other people to view the source, post issues, and participate in your project.

Github because it's sort of the standard for Ruby open source projects.

Releasing Gem at Gemcutter

If you feel like sharing your Gem to the world (and you probably do). Register an account at Gemcutter.

And now you are ready to release your Gem. Simply run:

$  rake gemcutter:release

To release your gem. (You can also release it at RubyForge instead if you wish so, see the Jeweler readme) You might be asked to sign in to your account, simply do so whenever prompted.

Workflow

.. taken directly from the Jeweler Wiki.

gem install jeweler
Create a new project and customize it, or configure an existing project
Write good code, and commit it
Bump the version with one of the rake tasks:
- rake version:bump:patch 1.5.3 → 1.5.4
- rake version:bump:minor 1.5.3 → 1.6.0
- rake version:bump:major 1.5.3 → 2.0.0
- rake version:write MAJOR=2 MINOR=3 PATCH=6 1.5.3 → 2.3.6
Release it
- rake release
- Optionally release it to Rubyforge: rake rubyforge:release
- Optionally release it to Gemcutter: rake gemcutter:release
Go to #2

One terminal, just one

2010-04-06T00:00:00-07:00

Until not-so-long ago, I always had a million terminals open at the same time. I have this neat keyboard-shortcut (Alt-T) which opens a new terminal. That’s nice and all, but the problem is, that I can’t be arsed to alt-tab to my old terminals, leaving a million terminals open, making alt-tabbing between other applications a pain. And I rely quite a bit on Alt-tab, I don’t have any task bar, since I’d rather just alt-tab between stuff than clicking on a task bar (which also takes up precious screen space).

So yes, one day I realised I really had this problem. So I scaled it down, my goal was to: On launch it looks for terminals.

If any terminal is found, this terminal should appear in front of all other windows, instead of launching a new terminal. If, however, no terminals are present, a new one should be launched.

That’s when I realised: “How-the-bob am I going to do this?”- Google to the rescue, and I eventually scaled down each problem in the application, and found a neat little application called wmctrl which (apparently) handles Windows. And by looking a bit at this application, I came up with this script, which handles the problem nicely:

#! /bin/bash
WINTITLE="sakura" # Name of the window (or part of it)
PROGRAMNAME="sakura" # Name of the program, so it can be opened if there's no window currently

# Lists all windows, if there's one containing $WINTITLE it'll return 1, and bring the current instance of the program to the front.
if [ `wmctrl -l | grep -c "$WINTITLE"` != 0 ]
  then
    wmctrl -a "$WINTITLE"
# Else, it'll launch a new instance
else
  $PROGRAMNAME &
fi

# We're good!
exit 0

Just change the variables to reflect your environment, it should be rather obvious what to change. So yeah, you just c/p this script to a whatever.sh file, and put it in your bin and launch your terminal via this script from now on. It’s also in my Kittybin, I might cover some of the other scripts from there in further blog posts. :)

And there we go. Problem solved.

My experience with Arch Linux

2010-04-06T00:00:00-07:00

After about 8 months with Ubuntu, I decided it was time for change. I had for a while wanted to switch to some other distribution, not because I did not like Ubuntu, more because I wanted to learn more about Linux, and try something new. And I felt Ubuntu limited me in this direction. Furthermore, I wanted to have a system which I did not feel I had to reinstall whenever new major updates came out, I wanted a system I could improve over time. I wanted a system where I could switch desktop environment/window manager quickly, and without googling myself on how to then remove all the old, now useless, packages. And rolling-release seems to be the solution, to that problem.

I quickly found a distro. which seemed to fit my requirements, Arch Linux. Arch Linux is lightweight, and simple. I found a quote on the Wiki, which describes it quite well:

“Linux, with a nice package manager.”

And my edition:

“Linux, with an nice package manager, and a kick-ass Wiki.”

That Wiki seriously provides the best information on everything you’ll ever need to know – I have yet to run into a problem which is not described here.

With Arch, you basically start with bare-bones Linux, which can boot into a CLI, has the basic stuff like Vi, grep, and these kind of basic Unix tools, that you’d have to install anyway, as well as a tool with which you can install packages. From there, you simply start building your system with the Arch Linux beginner’s guide (which is extremely well written). You install Vim, Xorg, Drivers, and so on. As it was my first (and hopefully only on this computer) install, I took good time to do each step, to understand what I was installing, and why I was installing it. Once I had Xorg up (I already felt like I had learned a lot more about how Linux works at a lower level. I was already starting to really like Arch Linux.

At some point when Xorg was set up, I wanted a Window Manager. And it’s really a dungeon there. There are hundreds of different Window Managers, tiling, not-tiling, and these big desktop environments (Gnome, KDE). I had already decided I didn’t want to go for a desktop environment, since then I’d have loads of gui-configuring-tools, and not learn exactly where configuration files are located (oh how I search the knowledge). I quickly figured out that Openbox was very popular on the Arch Linux forums. So I decided to install it, and found the neat Arkid theme, somebody had posted it in a screenshot thread on the Arch Linux forums. I’ve found Openbox to be great, and fit my needs.

From there, it was just a matter of setting up all the stuff I usually set up when I install Ubuntu: Vim, Chrome, Pidgin, a music player, Dropbox, and so on. And Pacman (the Arch Linux package manager) made this a pleasing experience. I ran into a few packages which I could not install with Pacman however. But, I quickly figured there was something called AUR (the Arch User Repository), in which I have yet to not find a package, this helps me get minimum headaches, since the AUR packages usually compile OTB, running the right ./configure etc. And of course, my fellow Arch Linux users have also provided me with tools which allows easy installation from AUR. I found a tool called Clyde, which works great. Basically a layer on Pacman with AUR support.

I’ve been running this system for a few weeks (as of this update, months), and I feel at home. I love it really. If you are looking to try something new, and already got some Linux experience, then you should defiantly go and try Arch Linux! Should you run into issues you have trouble addressing the people at #archlinux on chat.freenode.net are helpful.

Here’s a screenshot of my Archbox, because everyone loves screenshots.

Slow internet under Ubuntu or Linux

2009-10-31T00:00:00-07:00

Fix one: DNS issue

Ever since I started using Linux, I’ve run into issues regarding internet performance; it was unstable – it would take it several seconds, sometimes 10-20, to look up the host for most sites. Overall, it was very unstable – and rather unusable for a heavy surfer like me.

Download speed, and basically everything but the browser worked fine. Thus, I concluded that it could have something to do with the DNS – and I was right. I switched to OpenDNS, and it was running normally – here’s [the guide from OpenDNS on configuring OpenDNS on Ubuntu, should you be using another Linux distro., simply Google something like linux-distro opendns.

I also stumbled upon Namebench in the process, which is a little Python application that attempts to find the fastest DNS for you – which you can use to optimize performance further.

Fix two: IPV6

Currently, the standard for IPs is IPV4 – the thing is, that there’s always a limit towards to maximum number of IP-adresses available. We’re nearing this limit rapidly with IPV4, and therefore IPV6 is set to replace the old IPV4. ¹ However, some providers doesn’t support IPV6 yet, and Linux might attempt to use IPV6, conclude it fails, and then use IPV4 – each time it connects. This can be result in bad performance. Luckily, you can disable the IPV6 kernel module, which fixes this.

Fixing on Debian-based systems

I don’t know for sure, if this is the routine on anything non-debian based. I know this is not the way to go on e.g. Arch Linux. Debian-based systems include Linux Mint and Ubuntu.

You should be able to disable IPv6 by adding ipv6.disable=1 to kernel boot parameters (editing Grub config in /boot/grub/menu.lstand running sudo update-grub as instructed for example here). ²

Other distros

Again, use Google and you’ll probably be geared towards a Wiki, or forum thread for your specific distro.

¹ http://en.wikipedia.org/wiki/IPv6

² http://superuser.com/questions/67921/slow-website-loading-on-ubuntu-karmic

Become a Dropbox ninja!

2009-10-31T00:00:00-07:00

I’ve known Dropbox for very long. I’ve already found it to be an extremely cool service, however – I like to have things automated, the little programmer inside all of us. I didn’t want to “Drop” my files manually into the Dropbox folder all the time. That was time consuming, and I would forget to do it – sort of eliminating the purpose.

I wanted Dropbox to sync everything automatically across all my machine, I wanted to still have my files where they would originally be on my Desktop. On my Laptop, that didn’t matter – since I only use it for browsing the web, sometimes I program a bit on it, though. On my Desktop, I have all my Photos, configuration files, and code. I wanted to have these files available everywhere, anytime.

The solution to this was simple, very simple because of symbolic links, under Linux (my desktop, and main computer) I’d just download Dropbox, and place the special folder in my ~, then start throwing symbolic links in. First of, my photos.

$ ln -s Photos Dropbox/Photos

Then all my local code:

$ ln -s /var/www Dropbox/Programming

Then my Dumper which is basically anything else than videos, photos, music and programming:

$ ln -s Dumper Dropbox/Dumper

In my dumper I even did symbolic links to some of the configuration directories (e.g. Vim configuration, .bashrc etc.)

It started syncing, and now the magic of Dropbox is a lot more tempting to me. I now have everything, and the most recent version of it, available everywhere (iPhone, Laptop, Web), and it’s securely backed up.

If Dropbox seems tempting to you (now?), be sure to sign up at Dropbox.com If you’d like to help me, and yourself, you can signup via my referral link and you’ll get (and give) 250 mb extra to the 2gb default free limit!

Furthermore, Dropbox has a great wiki with various addons and tips & and tricks . They even have a CLI to Dropbox, which I use nowadays on Arch Linux when I’m without Nautilus.

Starting with Git!

2009-09-12T00:00:00-07:00

The purpose of this guide or tutorial is to give a brief overview of how to work with Git, even for people who've never had any experience with version controlling. This guide anticipates that you:

Have a bit experience with working in the terminal
Common sense

I will teach you how to:

Set up a Github repository
Upload content to your Github repository
Work with Git
Simple collaboration

A lot of people still believe SVN is much better than Git. However, this is not the case. SVN's way of handling repositories is bad, it means everyone pushes to the same master "repository". In Git everyone has their own, which is a lot smarter. I'm not going to go in depth about the difference, since a lot of people, with much more knowledge about Git and SVN than me, already did that. So you can Google your way to that.

With that in shape, let's get started!

Installing Git

Before starting this guide, you should have Git installed locally. You can download Git here. If you run Linux, there's a good chance that you can install it via your favorite package manager. For Ubuntu's package manager (Aptitude) the terminal command is:

sudo aptitude install git-core

You should most likely be able to type: "git" in the terminal, and it would give you the instructions on how to install it. This guide is not to cover the installation, but to teach the usage of Git. If you have troubles with installing, try to Google your way around!

Github

It has a lot of features, including graphs for your project, issue tracker and a wiki for your project.

Before you start on the next step, please register at Github.

Creating your first Repository

Our goal is to make a new repository, and upload a few files to it. Before we can do this though, we need to set up Git, so that Github knows who you are when you push things to their server.

Configuring Git

Configuring Git is very important, I used the first couple of hours with Git having headaches about Github not recognizing me, when I pulled stuff from my repositories at Github. However, it's pretty straight forward to configure.

We need to do two things:

Create an SSH-key
Provide this SSH-key to Git
Introduce ourselves to Git!

There is no reason for me to reinvent the wheel, Github has already done this. First, read their guide about Providing your SSH Key, then go ahead and Tell git your user name and email address.

Creating the Repository

Creating our own repository is pretty straight forward. Go to Github, login and you'll be at your dashboard. At the right you should see (create a new one). Click it, and it'll take you to the page where you can create your project.

Fill out the fields as you like, I'll call my project "Test". Hit submit. Now you've created your online Git repository!

You'll be taken to your new project, and you'll notice Github provides you a small guide on how to upload the first files to your project! Again, let's just follow Github's guide once again.

The first step is the Global setup step, we don't need to do this though, but because you followed the guides before, this is already done! I find it weird though, it doesn't tell you to provide your SSH key. Ignore this step.

However, we can follow the next steps:

Fire up a terminal, and type (replace Test with the name of the name of the repository you created on Github):

 mkdir Test

Afterwards, navigate into this new directory by typing:

 cd Test

Instance Git inside this directory by typing:

 git init

Create a new file by typing:

 touch README

Add this file to the repository by typing:

 git add README

Now, let's make a change to this file, by writing something to it:

 echo "Hello, is this on Github?!" > README

Now, we need to commit. Committing is a small message of what you just did (we'll cover more about that later):

 git commit -m 'Initial upload'

Next, we need to add the online Github repository (the origin), this is done by adding a remote origin (notice that you'll need to change "Sirupsen" and "Test" to reflect your own user, and repository):

 git remote add origin git@github.com:Sirupsen/Test.git

And finally, let's push it to Github.

 git push origin master

(This means we push the commits to the origin (master repository), at the master branch)

Now, go to your Github repository and you should notice a file named "README", if you open it you should see whatever you echoed into that file.

Now you've added your first file to Github! Continue to learn more about how to work with Git.

Working with Git

Now you know how to do the most basic stuff with Git, and Github:

Creating a local folder to represent your Git repository
Committing changes to a file
Update this on the server

With this, you can do the most basic stuff with Git. Now I will introduce you to some of the more exciting features of Git.

Pulling changes from the origin

But, what if I change something online. And would like to apply these updates on my local copy of the repository? That's what we're going to do now. First, let's go to our Github repository. Click on the file you'd like to edit (you'll probably only have your README file currently). When your viewing the file, you can chose edit to edit it.

Now you can edit your file. Make a few changes - create a small commit message, then hit commit.

Now, when you've added some stuff to your README file, it's time to pull the changes to your local repository. Open up the terminal where you arranged yourself into the Test directory, and pull from the origin:

 git pull origin master

Try to open the README file again, and you should see the changes you made on Github! Another way to check the output is by writing:

 cat -A README

Which will output the contents of the file directly in the terminal.

Cloning a repository

Instead of making a directory, adding the origin, and pulling, each time youneed a copy of your repository. You can simply use the clone command, which clones the repository to your machine. Let's try it. First, delete your local copy of the repository.

Next, go to your Github repository, and on the top locate your private clone URL (see picture to the right). Copy it, and go to your terminal and type (replace my URL, with your own private clone URL):

 git clone git@github.com:Sirupsen/Test.git

And then you should have a fresh copy of your repository!

Deleting files from your repository

Sometimes you may need to delete files permanently from your Git repository. The command for this is almost the same as the basic delete command ("rm"), we just need to have git in front of it. This command will both remove the file form your harddrive, as well as remove it from the git repository.

For instance, I've added a file called "INSTALL". But I ended up just adding this text to the README file. I already added the content of the INSTALL file to the README file, and committed these changes - but now I want to delete the INSTALL file, as it serves no purpose anymore.

To delete the file, we type:

 git rm INSTALL

And then we need to commit the changes:

 git commit -m 'Removed INSTALL file, due to content having been appended to the README file'

Finally, push it to Github:

 git push origin master

Simple, right?

The Difference

At some point you might have just cleaned up a few files, and totally forgot about commiting. Its ok if you don't even remember which files you edited. To find the difference from the Github repository, and your local copy simply type:

 git diff

And it'll show what is different. As it might be a bit pain to add each individual file like this:

 git add file1 file2 file3 file4

And then give them a shared commit, there's an easier way:

 git commit -a -m 'Cleaned up files'

This takes all the files which are different from the main repository (Github), and gives them the commit entered after -m. This is also good when you are editing a single file, because instead of:

 git add file

 git commit -m 'Added function to calculate average'

You can do:

 git commit -a -m 'Added function to calculate average'

It automatically picks up the changed file(s), and then commits them. Cool, right?

Workflow

Now you know all the basic commands of git, and you know how to work with Github. Let's take a quick look at an example of how our workflow could be like now:

I create a file, and call it index.php, I've already added some stuff to it. Now, I want to push it to Github:

 git add index.php

 git commit -m 'Added index file'

You might ask now, why don't we use:

 git commit -a -m 'Added index file'

-a will not add new files to the repository, you'll have to do that with add the first time. Alright, now I've added the file. I make some more changes to the file, and I commit it:

 git commit -a -m 'Added a menu'

Now I think it's good enough, to be pushed to Github:

 git push origin master

These 3 commands are by far the ones which you are going to use the most.

Commit
Add
Push

As I said before, it's very important that you commit every time you can rinse up what you've done in one sentence. Commit messages must be short, and precise. You should maybe use some time on your first commits, but over time you should learn creating small informative and useful commits. That's all for now, we might come around collaboration in Git in a later post. The best way to learn is always trying out, and if you don't know how to do something, use Google!

For further reading go to Git's official website, and read the documentation. Github also has several amazing articles on Git!

Dual booting Windows and Linux

2009-09-12T00:00:00-07:00

When I for the first time wanted to try out Linux, I couldn't at first glance find a simple guide on how to dual-boot Windows and Linux. So I decided to write a quick simple guide for you, to give an overview of how to create your own dual boot system. You should have the following stuff solved before you try this out:

Windows CD
- Be sure you have a valid serial for it, and so on
Linux CD
- Ubuntu, Fedora, Mint or whatever you might prefer
- Check out distrowatch if you have yet to decide
Backup of all your important files
- Also configuration files are handy to have
- .. and plugins!

When this is solved, you should be ready to get started.

What you do when you want two operation systems, is basically you have a partition for each. Linux requires an additional swap partition, Windows requires only one partition for the entire system. You can even share a partition between both operation systems. However, if you want Windows to be able to read it, you'll need it to be FAT32 (both Windows and Linux handles this filesystem fine!), and you need to create the shared partition, when you install Windows. (I.e. if you have Windows installed now, and would like to have an extra shared drive with Linux, you can't create it when you install Linux, since then Windows won't find it).

You might not know what a partition is, but it's quite simple. Imagine you have your harddisk, and you split it into smaller chunks, and store stuff here. As humans remember, and learn better by illustrations, I made one (bear with me, I'm bad at drawing):

Imagine partition 1 being Windows, partition 2 Linux and partition 3 the shared drive. (I didn't include the swap one here, as it would be pretty small on the scale, but it is a partition like the other ones)

Now, you should decide how your partition scheme should be like. There's tons of options, for this example (to keep it simple) we'll go with this, please check the comments for other ways to do it:

Windows partition (partition we install Windows on) [NTFS]
Linux Partition (partition we install Linux on) [EXT4]
- Swap partition (partition we install swap for linux on) [swap]
Shared Partition (partition we want Linux and Windows to share) [FAT]

Alright, let's get to it. For this "guide" I assume we are working on a 500 gb harddrive (plan how you partition your own harddrive). And we want a shared partition between the two systems. This should give a basic knowledge of what you need to do.

Boot from Windows CD
- If you happen to not being able to boot from it, go into your BIOS and set CD as first for boot priority
  - Should you have trouble doing this, google your way around for it. There's plenty of articles on that subject
Create two partitions in Windows partition manager
- Partition to install Windows on [100 GB]
- Partition we share between Linux and Windows, which we format to Fat32 later [300 GB]
Install Windows on the first partition
- Format it with NTFS (not quick, since quick doesn't examine for bad stuff)
Now wait a while for Windows to install
- Enter your valid serial when prompted
When your done it should boot
Install your drivers
- You'll probably have to restart a few times
Go to "My Computer", and open the D:/ drive (the shared partition)
- It'll ask you to format
- Do so, and pick FAT32 as the filesystem
Boot up in Windows, and take out the Windows CD
- Then put in the Linux CD (Ubuntu, Fedora or whatever distroration you picked)
Restart your computer
Now, there's two kind of installation cd's:
- LiveCD: (Fedora has this), it'll boot into the Fedora system. On the desktop there will be a shortcut named something like "Install on your system", click this and you'll get into the installation
- Normal: (Ubuntu has this), you'll be greeted by a screen where you can pick install, check disc etc. Pick install.
Now you should be taken through some installation stuff, time, location, etc.
At some point, you'll be at a partition manager.
- Ubuntu (Maybe Mint, and other ubuntu based systems too, not sure): You have an option to install the system side by side with the Windows system, do this. Does all the partitioning stuff for you! This will take the rest of the space, ~ 100 GB.
- Fedora (And probably any other system): Create a new partition named: "/" (this is the Linux system) [93 GB]. And a "/boot" partition [200 mb] (This is probably for Fedora only, never tried any other system than Ubuntu and Fedora, check your systems installation guide). And then you need the swap one, just pick swap from the dropdown of filesystems. To figure your size, follow this guideline [6 GB for me, as I have 4 GB ram]:
- M = Amount of RAM in GB, and S = Amount of swap in GB:
- ```
If M < 2
	S = M *2
Else
	S = M + 2
```
Follow the last configuration
Now, your system restarts and you should see a list of different systems to choose from (remember to take our your CD, so you don't boot the installation CD again), when you boot (i.e. Windows and Linux distroration):
- Try to boot Windows
  - Test shared drive
- Restart
- Boot Linux
  - Test shared drive
And everything should be working great! You should be able to access the shared drive on both systems!

I can not take any responsibility for any damage you may cause to your system, while following this guide. It's written only to give a overview of what you need to do, in order to create a dual boot system.