kside.net

Previous note: this post isn’t of very much use for sysadmins, I’m a software developer

I always wanted to have a fresh new terminal prompt but never got to stop everything to actually research about it, because I didn’t really knew much about it besides the basic export PS1="> ".

Finally I did this and was kind of frustrated by not finding many sources. I found many that were useful, like the Bash how-to at TLDP, but, you know, I was initially after a “bash prompt gallery” to take a look at and grab one of my choice. There aren’t none of that, except this good blog post from MakeTechEasier, from which I didn’t really find what I was looking for.

I wanted a simple, minimal, coloured and also “beautiful” prompt, but besides all, it had to be useful. To accomplish this, I went then to gather the information I should display on the screen.

The first urge of many people (and I infer that from the many examples I found) is to put many cool things, like CPU load, bash command history number, last command return value, time, current directory, username, hostname, a “floating” clock on the right up corner of the terminal… ah, come on. You have to remember that these things will show up every time you hit enter. If you want to play pacman on your prompt, that’s fine, but I realised that you have to focus on what you’re doing, nothing else. Again, when you are woke for, say, 20-24 hours, or working in the middle of the night, you don’t want things blinking, buzzing or stealing your attention. You don’t want a Crazy POWERFUL bash prompt when you actually want to write commands and hopefully go to sleep.

So I went for the radical minimalistic, almost hidden, prompt. To get there, I started a list of the most essential things I will not live without, to then remove the useless ones. I started like:

1. Current directory

… then I suddenly stopped and tried to think of anything else. And simply there aren’t other essential things. By reading it in cold like that, you may disagree, but if you take the time to do the mental exercise of actually thinking of it, even things that at first seem to be critical like the time and date, aren’t really necessary to be shown at every single command (if you are after seeing how long a command takes, there are tools out there to do it). Take username or hostname too, how often do you think those things change when you’re at your personal notebook?

So that’s that, now I have to show only one information in a nice way.

After trying some colors and layouts, I was uncertain about a two-line prompt. At first, it seemed to be a lot like one of these bloated prompts, but after some testing, I finally decided to go for it, mainly because I often encounter large directory names like in my music collection.

From, here, the prompt was basically set. I looked at it and saw it could have it show more information, but in a implicit way: changing the color of the arrow on the prompt to reflect the last command status, it is, if it was successful, it should be green, if failure, red.

Now this is completely personal

Since I’m a software developer that uses git for everything, I decided to put the current checked out branch after the current directory. But if CWD is not a git repository, show nothing, as expected.

The final result was this:

The code you can grab here: http://gist.github.com/450459

To use it just add those lines to your ~/.bash_profile, taking care of replacing possible old ones.

Here is a very simple shell in Python to test regular expressions with sed.

The shell works by matching the input as a sed command against a given data.
Each input line is evaluated as a Python expression (and it must evaluate to a [base]string) and then sent to sed as a command to be matched against this given data.
So every input is the same as:

echo <data> | sed -r -e <input>

<data> is set by using the d() function:

>> d("My data")
>> r's#^My#Our#'
Our data

To see what <data> contains, simply use the d() function without arguments:

>> d()
My data

(<data> defaults to the alphabet string "abc...z")

To exit, use Ctrl-C (KeyboardInterrupt) or send an EOF to it (Windows: Ctrl-Z+Enter, Linux: Ctrl-D) or yet use the exit() function.

I had a draft of this article on a paper since my first contribution to Rails Core was accepted approximately a week ago and I was postponing to write it because 1) I didn’t have enough experience, 2) the article would sound a lot like shameless self-promotion and 3) write in English is still a pain in the ass.

However, I got really impressed of what I read tonight on this agressive article Want It? Give. by Ryan Bigg (I could really listen to DHH talking on a conference on that tone.. am I that crazy?), so I decided to write the article anyway (which doesn’t mean that I overcame all of my 3 points above, they can still be true).

Although I’m not a big fan of tirades, they can be very effective and make us motivated to do something, and on this case hopefully it’s a healthy thing! If you aren’t convinced to start contributing to Rails right now, go read this article too Pledge 3 Percent for Rails 3 by Dan Pickett.

Now that Bigg and Pickett got you motived to contribute to Rails , it’s time to learn on how to do it, there’s plenty of instructions around on how to send a patch to Rails, I’m not going to reproduce it here, so I recommend you to read/watch the following first:

• #113 Contributing to Rails with GIT from Railscasts
• Contributing to Rails from Rails Lighthouse

Enough on motivational talk, those articles can fullfil “Why I should contribute to Rails”, so I will go through some questions that I asked myself when trying to contribute to rails and I wanted to share.

How I find something to fix or add on Rails?

I got used to think that all problems on Rails were solved by Rails Rockstars and there wasn’t bugs left to fix neither features that I could add. If you think like this, I have to tell that you are wrong, as I was. I’m not a great developer and definitely not that smart, and still I was able to do my part.

If you didn’t find a bug or something that you think ‘should be nice have X on Rails’ you probably aren’t playing with Rails that much, but still you can find a lot of patches to test and bugs to fix on Rails Lighthouse.

Where should I start?

You start from the obvious beginning when talking about Test Driven Development: writing failing tests. Rails has a rock solid test suite and you have to embrace it, love it, cultivate it, treat it like your own son! When you are dealing with a bugfix, write the missing test case or when adding a new feature modify the existing tests (if necessary) and add more tests designing your feature.

Where I should insert method X? What’s the best design for feature Y?

Read the manual and play around. You have a new toy, you don’t know how to play with it, what you should do is read the damn manual and start playing with it. So, read the Rails API and start doing ugly things, it’s your own copy of Rails and you want to know how things works, if you are not sure what all that modules and classes are all about start doing copy/paste (build your own Rails frankenstein!) and see what happens. It’s even valid do PDD – Puts Driven Development (as would say Rafael, I friend of mine).

Feature or Bugfix?

I would strongly recommend you to start with bugfixes, they are all over the place and will not stop growing anytime soon. However, if you are thinking of adding a new feature on Rails, first discuss it on Rails Core mailing list.

As you may know, Rails has some quite strong opinions about a lot of things, and most of the time when talking about new features what sounds good to you is far away of what the Rails Core Team thinks, so be careful when trying to sell your shiny new feature that you think will be awesome-freaking-good on Rails.

How should I post my ticket?

Be straight to the point, no one will read a very long text neither guess what your one line bug description means. You should follow this simple script:

• Describe it shortly
• Post a step by step how to reproduce the bug
• Post OS, database, rails version or whatever you think should be relevant

In case of a patch you can add:

• Describe where was the problem and..
• Why you took that approach to fix the problem?

What makes my contribution good enough?

• If I had just a few words to say, it would be: “a lot of tests”. That’s it, you have to write tests for every single case, doing a one line patch on Rails could easily mean writing 30 lines of tests. The commiter who will evaluate your patch will look essentially your tests and if they cover all cases, so don’t hesitate on writing a lot of them, tests are always welcome.
• Write good documentation in case of features.
• Be polite and collaborative, no one will look at your bug report if you are an asshole or test your patch if you are arrogant.
• I can’t think of anything else to add here. Any suggestion?

Conclusion

Although the goal is clear enough: make a better software and contribute for a greater cause. I think that the most useful thing that I could get from this enjoyable experience is the whole process, because I learned a lot. This motive should be enough for anyone seeking on improving his programming skills and can’t handle doing nothing useful on Sundays. :)

And this article is only a personal experience and opinion from a greedy Rails Core contributor. I can be very wrong on some subjects, feel free to enlighten me and join the discussion.

Happy Rails Hacking.

I play some games, often those of the kind: easy to learn, hard to master (and I've played serious sometimes, but not nowadays). Recently I've been playing the great Race Driver: GRID. (Which is really hard to master with only a keyboard, probably impossible.)

In this game you can race the prestigious 24 Hours of Le Mans, a endurance race of 24 hours that has 4 classes, many teams per class, each class has 3 drivers (yes, of course, they switch drivers to reach the 24h mark).

All right, what a Python code snippet has to do with all this? Nothing much, actually (I just got very excited about the whole Le Mans thing), but the thing is that I went searching for videos on YouTube about Le Mans and found some real nice videos in a specific playlist. I wanted to extract all the links from that playlist, for further use later, and then ended writing the simple script below.

It will grab the links from the Google Data API, using the playlist id. The details are inside the script comments.

Besides the code, which is really simple and short, the whole post's point is that I love this excitement feeling when you get interested in something then goes and writes some code, hopefully useful. This gives me the stamina to write even more (plus commenting it), stop to write down a blog post (and actually searching for images, editing, etc), so all this even could result in a little project. Not this subject, the playlist reader, but could be anything.

If you, like me, are not an expert in web design, you probably do as I do when trying to implement a layout or fix one: put a line in the CSS file, refresh the page, see what happened, then edit the CSS file again, see what happened, then comment out the changes before, hit refresh again, and so on (much of this will likely be caused by trying to debug a page using that something-that-is-not-a-browser called Internet Explorer).

But CSS comments are so annoying with that C-like syntax (the '/*' opening and '*/' to close):

#navbar {
  width: 500px;
  height: 50px;
  font-family: "Comic Sans";
  /*border: 1px solid black;*/
}

Did you see that "border" property? Yep, it's me print debugging a div box to see where the heck it went (specially when toying with the "float" property) or seeing why its content is being shown outside of it (using too much "padding", for example).

I do comment and un-comment 1-lines like that for testing so many times that I got angry and wrote this small vim helper to aid in this cumbersome task!

Here it is:

You can put that in your .vimrc and call it like this:

:call ToggleCssComment()

One would wonder that typing all this is probably more than typing 4 chars, but hey, it's vim. You can call it by hitting TAB to auto-complete the command:

:call Tog<tab>

Or you can even bind it to a shortcut key (using FileType [:help FileType] is way more fun, since you can bind the key only when a CSS file is being edited)!

I was using scribbish theme for this blog, but didn’t like the small fonts and colors, so I started playing around hacking the theme a bit and at the end I discovered that it was a complete different theme from the original scribbish (not on structure, only on style).

I decided then launch it as a separated theme named simple-blue, here’s the description from README:

simple-blue is a simple typo theme heavily based on scribbish, but with larger fonts, grey background and lot of blue/orange.

To install just clone this repository inside your typo theme folder:

cd typo/themes

git clone git@github.com:krsmurata/simple-blue.git

I hope you find this theme useful somehow.

I wrote this very simple, yet very handy, Google Chrome extension for searching brazilian zip codes in Brazil''s government postal service site, Correios.com.br.

Here''s a screenshot of it in action:

BuscaCEP

Screenshots and install at the Google Chrome extension page

Source code on the repository at GitHub