git-ify your command line!

In a nutshell:

Run bash /dev/null | tail -n1) != “nothing to commit (working directory clean)” ]] && echo “*” }
function parse_git_branch { git branch —no-color 2> /dev/null | sed -e ‘/^[^*]/d’ -e “s/* \(.*\)/[\1$(parse_git_dirty)]/” } export PS1=’\u@\h \[\033[1;33m\]\w\[\033[0m\]$(parse_git_branch)$ ‘

I’m totally addicted to this wicked CLI upgrade, can’t work without it nowadays.  Thanks to Henrik Nyh.  I’ve seen lots of other variations on the web for this, but I like his’ the best.

Update: You can also use the following snippet to also get a little plus sign (/path/to/git/repo[master+]$) when the local repo is ahead of the remote repo, i.e. you have unpushed commits. Thanks to Paul!

function parse_git_dirty { if [[ $(git status 2> /dev/null | tail -n1) != “nothing to commit (working directory clean)” ]]; then
echo “*”
elif (( $(git status 2> /dev/null | grep ‘Your branch is ahead of’ | wc -l) != 0 )); then
echo “+”
fi
}

2. Common shortcuts (git aliases)

I use the following shortcuts (some were inspired by previous workings with SVN):

/path/to/git/repo[master]$ git st # == git status
/path/to/git/repo[master]$ git br # == git branch
/path/to/git/repo[master]$ git co someBranch # == git checkout someBranch
/path/to/git/repo[master]$ git ci -m”message” # == git commit -m”message”
/path/to/git/repo[master]$ git df # == git diff

To get these aliases up and running just run the following lines in your command line:

git config –-global alias.st status
git config —global alias.br branch
git config —global alias.co checkout
git config —global alias.ci checkin
git config —global alias.df diff

3. Avoiding fast-forward merges

This is just another alias, though I think it’s worth mentioning in detail.  In git, when you create a new branch and start working on it, once you decide to merge back to the originating branch, if that originating branch hasn’t diverged yet (i.e. received more commits), git doesn’t really perform a merge.  What it actually does is change the original branch’s pointer to point to the last commit on the new branch, resulting in both the original branch and the new branch pointing to the same last commit.  The trouble with this feature is that if you want to trace back where you’re branch originated from, the history graph won’t show the intersecting commit where you branched out.  So if for some reason you need to revert the work done on this branch you’ll have to manually sift through git log’s historical commit messages and try to remember where you started your branch - a serious headache?  Instead, I regularly commit with:

/path/to/git/repo[master]$ git nffmerge someBranch

which is just an alias to git’s regular commit command but with fast-foward flagged off:

git config —add alias.nffmerge ‘merge —no-ff’

An excellent resource to understand this better is Vincent Driessen’s git branching model

4. History graphs (git log)

git log just doesn’t cut it for me.  There’s too much clutter on the screen that you can’t really read.  I suggest using this simple alias:

git config —global alias.logk “log —graph —pretty=oneline —abbrev-commit —decorate”
# Now use it: /path/to/git/repo[master]$ git logk

Then git logk will generate a nice flat looking log which is easier to read:



But the real bomb (wait for it…), is the colorful history graph that shows relative commit time and commiter names.  Don’t just stand there, you have to try this one out:

git config —global alias.log-color “log —graph —full-history —all —color —pretty=format:’%x1b[31m%h%x09%x1b[32m %C(white)- %d%x1b[0m%x20%s %Cgreen(%cr) %C(bold blue)%Creset’ —date=relative”
# Now use it: /path/to/git/repo[master]$ git log-color

And here’s how it looks:



Thanks to Bart’s blog and some random dudes on stackoverflow.com.

5. Whole project diff (git diffall)

Sometimes I’d like to see a diffs of all changed files in my project in a tree view of the folder structure (like Winmerge, Tortoise and other Windows tools).  The solution is to combine git-diffall with a GUI diff tool (meld in my case):



To do this, you need to install git-diffall and configure git to use it:

git clone https://github.com/thenigan/git-diffall.git ~/tools/git-diffall sudo ln -s ~/tools/git-diffall/git-diffall /usr/bin/git-diffall git config —global diff.tool “meld” git config —global diff.external “meld”
# Now use it: /path/to/git/repo[master*]$ git diffall

You can also you git-meld which is very similar and also a good tool.

Conclusion

Git is awesome compared to some older source control systems I’ve worked with (CVS, SVN, Clearcase to name a few).  The fact that branching and merging is so easy and fast really transforms your work flow.  With just a bit of command line hacking, you can make your life a lot easier.

If anyone out there has more git command line productivity tips, do share!

First 3 months of a startup: 20 things I’ve learned

I finally did it 3 months ago.  I quit my day job and jumped into the deep water with two partners.  Together we co-founded the SOOMLA project.  We’re a store creation platform for mobile games, the first of it’s kind.  Instead of diving into the technical \ business details, I’d like to share the facts and insights I’ve learned over the course of our first 3 months as a startup.  This post is heavily inspired by a post by Fab’s CEO, Jason Goldberg.  Here it goes, counting 20:

  1. Don’t expect to raise money because you’re not going to.  This doesn’t mean your product isn’t great or your team isn’t strong enough.  It just that means that most investors are risk-averse.  Even if you have a team of rockstars and a killer product in a huge market, at an early stage most of them prefer to hang around till you show some traction or until some other investor jumps in first.
  2. Build a thorough fund raising strategy.  Don’t just go “yeah I’m looking for money”.  You need to create a plan that’s aligned with the pace of your product development and customer acquisition.  Think about how much cash you actually need, who you want to raise from, how many rounds you want to open and what the investment terms are.  Share your plan with experienced entrepreneurs as a sanity check.  This was a game changer for us and made us completely rethink our strategy.
  3. Quit fucking around. This one’s my favorite.  Shut down your email and Facebook, don’t go to any meetups, delete stupid movies people send you, and restrict your Techcrunch time to 15 minutes a day.  If you’re a technical co-founder like myself, avoid business meetings and trust your biz-oriented co-founder to nail them and update you later.  Your coding time is sacred and the opportunity cost is just too big to waste it slacking off online.  The only exception is helping people out, which is good Karma and will get back to you in the long run.  @Stammy of Picplum has written about it in Techcrunch.  I think this was the last time I extensively read Techcrunch :-)
  4. Work hard but keep a sustainable pace.  Don’t do all-nighters.  Your exhaustion will eventually kick you in the butt and those few extra hours you worked up till 4AM will cost you most of the following day.
  5. Always be asking for feedback, from anyone, about anything.  You’ll talk to hundreds of people with worthless comments until you hit that one person who’s feedback is a golden nugget.
  6. Don’t take easy money. In the early months, you will get financing offers from all kinds of investors looking for exceptional terms and equity.  This will practically buy your ass and paralyze your future rounds.  Don’t get tempted.
  7. It’s better to pay in equity than in cash.  This isn’t just dictated by how much money you can afford to pay.  It’s a philosophy we’ve embraced which asserts that stakeholders in your venture will be much more engaged and interested to help when they have ownership in the company instead of being contractors or paycheck collectors.
  8. Administration is a hassle, get it out of your way as quick as possible.  I’m talking about incorporation, a founders’ agreement, lawyers, bookkeeping, bank accounts etc.  All of’em are important, but none of’em will actually advance your product so don’t stall on each one too much.
  9. Think in terms of risk reduction.  This was hard for me to do at first, being a tech-minded person.  Keep asking yourself what activity would most mitigate your risks as a company and engage in that activity.
  10. Participating in a conference is great for PR, but kills focus and consumes too much time.  Say no to most conferences and competitions unless you get called upon without applying or unless you see a real value booster.
  11. Do one thing, and do it better than anyone else.  Focus is key to moving fast and building something great that nobody else can build.  Say no to more features and more ideas.  Instead, focus on a lean and beautiful product that solves one problem all the way.  There are several services in our realm (mobile gaming) that have 5 different offerings for game developers, but none of them do one thing exceptionally well. 
  12. Be humble.  This is also my personal credo talking.  Don’t brag about your achievements. Nobody likes people that bitch around about how much they raised or how awesome they are.  Remember that your chances to build the next Facebook aren’t in your favor, but….
  13. Be a believer.  Always have faith in your product.  Leave aside the sales pitch, this has an enormous impact on the dynamics between you and your co-founders.  If one partner has a shitty day and starts thinking bad thoughts (which is perfectly normal in a pre-investment, pre-traction stage), the others should employ their vision and faith to bring him \ her back on track.
  14. Don’t outsource your core technology, ever! (I knew that before these 3 months but I still think it’s worth mentioning).
  15. UI + UX shouldn’t be taken for granted in terms of difficulty and dev time.  In the early stages of a startup, since the UI is the only thing that’s customer facing, it will be the bottleneck of development.  Prioritize efforts on the parts of the product that users actually see with their own eyes, you can always optimize the backend parts later.
  16. Your performance is measured by your co-founders.  You think you can “fire at will” because you still don’t have any employees to parent after, but the truth is you’ve got your co-founders behind your shoulder examining the quality of your work and the speed of your delivery.  You should examine them too.  Given the risk you’ve taken, it’s only rational to validate yourself and your choice of partners by following their work closely.  I’ve been blessed with two co-founders who I trust with my eyes closed, and I’m confident they feel the same about me, but it took us a while to build this level of trust.  
  17. Use your friends for leveraging your social footprint, and making new intros.  Don’t be afraid to ask, they’d do the same if they were in your position.
  18. Tel Aviv is a kick-ass city for startups.  Great weather, lots of events, a huge tech community and plenty of bars for drowning your sorrow in a glass of whiskey at the end of hard coding day.  I know it’s a tough sell for Silicon Valley diehards, but I recommend reading a post by the guys at Buffer who were very content with the time they spent here.
  19. Exercise a lot.  Heck, you’re finally out of that corp, you make your own schedule now.  Try to jog \ bike \ whatever at least 2-3 times a week.  It will ease your mind and foster your creativity.
  20. Prepare for the ride of your life.  You will enjoy it no matter what and you’ll never feel more fulfilled.

That’s it.  You’re welcome to drop by our website and sign up for the early beta, or have a look at our open source projects on Github.  Please, do share your thoughts and learning experiences in the comments.

The trouble with software engineer CVs

Note: This post is based solely on my personal opinion, and experience from the Israeli tech scene. It might be a completely different ballgame in Silicon valley or other parts of the world.
Resume cartoon
In my current workplace, as in my previous job, I’ve been lucky to have the opportunity to interview a lot of candidates.  Leave aside the context switch it creates and the disruption to your coding time, you can really enjoy the process of getting to talk to other developers.  There is however one black spot to recruiting which I’ve noticed and it’s the poor job candidates do in writing their résumés.  I don’t know where this originates from, but I can take a few educated guesses:
  • You can’t write a good CV because you’ve never been taught how to.
  • You’re a geek with poor soft skills and you’re incompetent of writing a comprehensible, attractive CV.
  • You haven’t seen other CVs yourself, so you can’t judge between poor, mediocre and excellent CVs.
  • You can write a nice CV but you can’t write a damn good one, because you’re just not a damn good engineer.
  • You don’t understand the purpose of CV.
Let’s focus on the last point for a minute: the ultimate and most important purpose of your CV is to get an employer to call you \ schedule an interview with you.
That’s it, plain and simple.  All the rest doesn’t matter that much, because once you’ll come in for an interview you’ll get a chance to shine.  This principle should resonate through your head when writing your CV, because a CV is in many cases the first encounter a potential employer will have with you. This isn’t even a face-to-face encounter, so donning your best suit and tie won’t help you much, it’s all about words.  You’ll have to bridge the “in-person meeting” gap by superbly expressing yourself with the sole use of written words.  After reading quite a lot of résumés lately, it strikes me again and again how people just don’t get it right.  So, in the interest of assisting my fellow coders out there looking for a job, here’s a pile of tips, a crash course if you may, on how to get your CV right:

DOs

  • Add a cover letter \ mission statement
    It could be 1-2 paragraphs where you describe yourself, or even just 2-3 sentences inside the CV.  What matters here is to tell about yourself in short and show the employer that you know what kind of position you’re looking for.  I find this shows character.
  • Describe what you did in previous jobs COHERENTLY
    I can’t stress how important this is. Explain exactly what you did in your previous job.  Mention what product(s) you worked on, how big the team was, what was your role in the team, what technology stack you used, what challenges you faced, what impact your work had on the team, which interfaces you worked within the organization, etc. Clarity here is key.  Avoid including vague descriptions and titles and make sure the reader can understand your actual experience. Refrain from any hand waving.  Hand waving can only get you so far but it won’t last through the interview.
    Bad example: Developed a large scale project as part of a client-server platform while incorporating high load database interaction.  Participated in the lifecycle of the product from inception to launch.
    Good example: Worked on the company’s advertising portal as a web application engineer in a team of 4.  Built several web-apps from scratch using a Ruby-on-Rails + MySQL + Redis + EC2 stack, while scaling one of them to 50MM users.
  • Prove that you can code
    Provide your github account.  Add a link to some pet project or school assignment you’ve done.  List any open source projects you’ve contributed to.  If you have nothing to show, think about ways to contribute or publish code that you’ve written in the past.  This will likely skyrocket the credit you get before even getting the job interview.
  • Show your online footprint
    Gear up your CV with your Linkedin and Twitter accounts.  Mention your blog.  Tell us about any communities or sites you’re active in (e.g. stackoverflow).  If you’re scratching your head on this one, have no doubt, any decent employer will most likely Google your name and fish for more details about you.  Providing these assets makes the employer’s life easier and creates an enormous impression that you’re a part of an online tech community.
  • List your hobbies
    OK, this is just me, but I like to see that a candidate has some out-of-office activities. If you’re a member of the local hockey team, or an avid biker, a wine lover, a basketball fan, or anything else cool, I want to know about it. On the other hand, if you’re just an uber-geek-lab-rat with zero social skills and no interests whatsoever besides programming then I don’t want you to work with me.  Call it discrimination if you will, but I want to work with vibrant people who can pull off a joke and enjoy a game of pool just as much as they can program.
  • Have a look at other CVs
    You’ll be surprised how much this helps. Try searching “software engineer résumés”.
  • Have a friend read your CV before sending it
    For some reason, lots of us don’t think this is necessary: “I don’t need someone to look at my CV, I know how to write one”.  Wrong. Even if you’re sure you know how to write a CV, always question yourself by passing it through another pair of eyes.  It’s worth it even if all your friend finds out is a small spelling mistake that you missed.  You’ll be surprised how much people will be inclined to read your CV and give you notes.

DON’T DOs

  • Don’t write a national bestseller novel
    Try to squeeze your CV into one page. I think most people would respect this. Spare the employer the torture of reading  the 3-page pile of boredom you just wrote.  Be concise and accurate.  Mention only the most important things relevant to the position you’re seeking.  If you were temping as a waiter while you were an undergrad, and that extra line is causing a page break, throw it out.  Go over your CV over and over until you weed out all those mundane details nobody cares about.  If you worked in a shitty place for a short time, consider not even mentioning it.
  • Don’t tell us about 4th grade
    Some people like to write their CVs from the dawn of man.  Don’t start writing about your experience from the 90s.Write the positions you’ve had in reverse chronological order and not the opposite.  I care much more about what you did in your last job than what you did back in ‘98.  This goes also for education, accomplishments and other activities you took part in.
  • Don’t use fancy Word-Art or tables
    This just looks so freakin’ amateur.  Keep your CV clean and simple.  No need for fancy artwork and photoshop.  By all means don’t use a bordered table with rows per each work place.  The flip-side of this tip is to maintain proper alignment to bullets and sections in your CV in order to ease the reader’s eyes.  When hiring, employers sometimes go through so many CVs everyday that they start scanning through them instead of actually reading every word.  You want to put those eyes at comfort.  The recipient of your CV isn’t always cognitively aware of this, but I can definitely testify that when I get a nicely laid out CV, I give that candidate some extra points without even noticing.  Earn those extra points!
  • Don’t mention JSON and XML as skills (!!)
    Sorry fellas, but this is pathetic.  Everyone nowadays works with these formats.  There’s nothing special to know about them, and they sure as hell don’t qualify as skills.  The next CV I read with this bullshit will be pinned to the wall of shame (we don’t really have one of those in the office…) .

All in all, I have to say that there is a substantial correlation between candidates who write a good CV and candidates who do well in the interview.  Screening candidates just by their CVs is a form of art.  Discerning the ones who are actually qualified and deserve an interview is even a finer art.  Make your potential employer’s life easier by getting your CV done right.  On that note, Capriza is hiring, so go prepare your CV and send it on over!

One last tip: if you make it to the job interview, make sure you stick up for what you write in your CV.  An employer is more likely to ask you questions of what you claim to know rather than just random disciplines in computer science.  If you claim you’re a Java developer, don’t dare coming into an interview without mastering object oriented programing.  If you say you know databases well, but can’t write a simple SELECT command, you’ll be caught pretty fast.  And for cryin’ out loud, know your data structures before you interview.  The next candidate I see who can’t reverse a linked list or traverse a binary tree will be hanged on the wall of shame…

Domo.rb & Domo.js: Canonize domain names easily

In a nutshell:

>> Domo.canonize("motors.ebay.co.uk")
=> "ebay.co.uk"

Ruby: https://github.com/gurdotan/domo-rb

Javascript: https://github.com/gurdotan/domo.js

In detail:

About a year ago, while I was still working at Kontera, my team leader asked me to write a small utility that could extract the canonical domain from a domain string.  A canonical domain name is the domain authority with all the TLD (top level domain) suffixes following it.  So for example, the domains  www.ebay.com and motors.ebay.com share the same canonical domain: ebay.com.  That’s an easy example, but what happens when you take into consideration all the possible TLD suffixes (.com, .info, .org, .edu, .mobi …) and also all the country code suffixes (.us, .ca, .mx, .jp, .de, .il ….)?  To thicken the plot even more, some countries use co for commercial domains (i.e. UK:  www.ebay.co.uk) and others use com (i.e. Australia:  www.qantas.com.au).

The reason we needed to canonize domains was for reporting purposes.  We were counting our system’s page views and we wanted to divide them into per-domain buckets.  The task was high priority, and I couldn’t find any existing Ruby code that did the job, so I managed to come up with a solution within an hour’s work.  Extracting a domain’s canonical form can actually be achieved by applying a simple algorithm I devised (I’m sure I’m not the first one to think of this):

1. Strip the domain string from protocols, ports and paths.

"http://motors.ebay.co.uk:8082/search/buy_now.html"  	# Regular
"motors.ebay.co.uk"					# Stripped

2. Split the domain by dots and reverse the array.

["uk", "co", "ebay", "motors"]

3. Iterate the array until you reach a slice that isn’t a standard TLD, and dispose of the rest of the array.

["uk", "co", "ebay"]	# "motors" dropped

4. Reverse the array back and join it.  TADA - the canonical domain string:

"ebay.co.uk"

This method works fairly well but it does have its pitfalls.  It won’t manage to find the canonical form of domains who’s authority is also a TLD.  So assume an imaginary company named “Mobi”, the domain news.mobi.com will be erroneously canonized to news.mobi.com instead of mobi.com, because mobi is a standard TLD.  If anyone has a clue on how to identify those trickier domains’ canonical form, please do share.

Come November 2011, I was asked by Oren, my manager at Capriza, to add a canonical domain to each record in the database.  DOHHH!!! Why didn’t I open source that piece of code from a year ago?  So this time around, even though I was doing it in Javascript instead of Ruby, I decided to publish it all on Github for the future’s sake.  Maybe my grandchildren will one day ask me how we canonized domains back in the days - I’ll just send them to my Github account and go back to watching TV :-)

Ruby: https://github.com/gurdotan/domo-rb

Javascript: https://github.com/gurdotan/domo.js

Reference

Wikipedia has a full list of all top level domains, which I used as reference for matching TLDs in the code.

Activerecord Plurals - A shot at the rails source code

In a nutshell:

gem install activerecord_plurals

Usage: https://github.com/gurdotan/activerecord_plurals

In detail:

I find myself many times in need of fetching all IDs or all names of an ActiveRecord query result.  To generalize, I’d like to get all [attribute]s of a certain ActiveRecord model.  Instead of this:

>> Beer.select(:id).map{&id}
=> [1, 2, 3, 4, 5]

I’d like to do something more semantic:

>> Beer.ids
=> [1, 2, 3, 4, 5]

>> Beer.names
=> ["Miller", "Coors", "Heineken", "Tuborg", "Guinness"]

There comes a time in every Rails programmer’s life when he \ she have to open the Rails source code and start digging in the mud. Since I found myself repeating the same pattern of ActiveRecord queries followed by map() calls over and over again, I figured this was my queue. ActiveRecord uses a lot of meta-programming techniques.  Time to code!


# activerecord_plurals.rb
#
class << ActiveRecord::Base

  alias_method :singular_method_missing, :method_missing

  def method_missing(method_id, *args, &block)
    singular_method_id = method_id.to_s.singularize.to_sym
    if method_id == singular_method_id
      singular_method_missing(method_id, *args, &block)
    else
      self.select(singular_method_id).map(&singular_method_id)
    end
  end

end

What’s going on here?  First, we’re reopening the ActiveRecord::Base meta-class (also called an eigenclass by some books) with the class << syntax.  Then we provide a new implementation for method_missing along with an around alias.  This is necessary since ActiveRecord::Base already implements method_missing and we want to wrap the original implementation.  The new implementation’s logic just checks if the invoked method is in singular or plural form.  In case of a singular form, we delegate the method call to the singular_method_missing which is a reference to ActiveRecord’s original implementation.  Otherwise we assume a plural method invocation - we select the requested field and map the query result into an array. 

This is not enough though.  method_missing should always be implemented with respond_to?.  If you can call it, you should be able to recognize it! Add the following to the above class:


  alias_method :singular_respond_to?, :respond_to?

  def respond_to?(*args)
    return true if singular_respond_to?(*args)
    singular_method_id = args[0].to_s.singularize.to_sym
    instance_methods.include?(singular_method_id)
  end

All of the meta-programming techniques demonstrated in this post - Ghost methods (method_missing), method aliases(alias_method), and meta classes - are also heavily used in ActiveRecord’s source code, so I highly recommend you to have a look. If you’re completely new to Ruby meta-programming concepts you can read more here.

The full source code is available on Github.  Or, you can just install it as a gem

gem install activerecord_plurals

or as a rails plugin

rails plugin install git://github.com/gurdotan/activerecord_plurals.git

This is my first gem so any feedback, good or bad, is very welcome :-)