Month: January 2014

2014 Resolutions Status: January

January has passed. That’s almost 10% of 2014, gone for good. How am I doing with my 2014 resolutions? Each resolution and its status for January:

  • Happy: 5/10. Better than before, but could still use some improvement.
  • Healthy. 7/10. Worked out 16 times. Starting biking to work.
  • Save time. 6/10. Do not recall many instances of staying in pointless endeavours, waiting for them to end.
  • Travel. 1/10. Visited Ofek’s base in the Negev and drove to Jerusalem and Haifa. Nothing to brag about.
  • Family. 6/10. 3 birthday parties with Agam,
  • Write. 8/10. 2.5 chapters rough draft for SA book, 8 blog posts.
  • Experience. 2/10. Few adventures this month.

Altogether: 35 points, with room left for improvement.

Shabbat Shalom! 馃檪

Git Rebase for Dummies

In the following post I will go over how and why to use git rebase instead of聽git merge, even if you don’t completely understand how and what rebasing does.

We will try to explain in layman’s terms (e.g., without relying on the term ‘HEAD’) what’s happening, and most importantly, why you should drop your fear of rebase and learn to love it. If your Git-fu is strong and you’re a Git-ninja, cherry-picking all over the place, you won’t need this. However, if you’re a smart developer but learning Git has been a trip down the rabbit hole, read on.

Specifically we will cover the most common use-case, where you are working (alone) on a feature branch and have finished your feature, and you wish to now push your code to master. Perhaps you might ‘merge’ from master (as many naive guides suggest), but you’ve heard people say you should be rebasing. How? What? Why?

We will cover the following:

  1. Base workflow when rebasing in git
  2. In-depth explanation of what rebase does, in easy terms
  3. Conflicts – and why you shouldn’t fear them
  4. Summary

1. Git rebase workflow cheatsheet:

  • git checkout master
  • git pull
  • git checkout branch
  • git rebase master (if you have conflicts, see below.)
  • git log (see your branch commits on top)
  • git diff master
  • git push –force (unless someone else has pulled this branch. This will mess them up.)

(if ready to deploy:)

  • git checkout master
  • git merge branch
  • git push

2. git rebase, step by step:

  • git checkout master
  • git pull

As you may have heard before, *pull* is actually *fetch+merge*. Anyway, in our case master is now up-to-date.

  • git checkout branch
  • git rebase master

The crucial step, of course. What rebase does is it puts the branch commits on top of master’s commits., instead of merging them together.

Let’s explore the differences between merge and rebase. Suppose master has commits A-B-C-D, and your branch includes your additions, commits E-F. After merging, we will have all the commits together. Hooray? No, wait – the order in which the commits appear will depend on at which point we branched off. Our commit log might look something like A-B-E-F-C-D, despite the last commits de-facto being E-F. The end result (the code) will be the same, but the commit log is deceiving. (In fact, in the case of merging there will also be a redundant ‘merge commit’, but let’s ignore that for now.)

When merging, if we had branched off from A, the end result after merging would be A-E-F-B-C-D. If we had branched off of B, if would be A-B-E-F-C-D. If we had branched off of C, it would be A-B-C-E-F-D. If we had branched off of D, it would be A-B-C-D-E-F. And this is what we want, of course — after ‘adding’ our branch to master (and pushing), we would want the commit log to reflect our changes as being added ‘on top’ of everything else, since logically that’s what happened for master.

Enter rebase. What rebase does is ignore the point at which you branched off. It grabs the current ‘last commit’ of master, and puts all of your commits on top of it. So in effect, it simulates as if you had just now branched off master, done all of your commits, and then merged back. In the above scenario, it will ensure our commit log will be A-B-C-D-E-F. Awesomeness!

Bottom line is聽if you merge, the post-merge commit log would be something like A-B-E-F-C-D, where B is the commit where you branched off, E-F are your commits, and C-D are any commits pushed to master between the time you branched off and the time you merged.

But if you rebase, the post-merge commit log will *in any case* be A-B-C-D-E-F, where *your commits* E-F are *on top*. Why is this important? For you as a developer, it usually isn’t. I did my commits, merged & deployed, thank the Lord. But think of your coworker: He sees you’ve pushed code to master and goes to your github repo to view the commit log to see what’s changed. Bah humbug! If you’ve ‘merged’ the top commits he sees are C-D, which aren’t the new commits – they were already there. How can he even know what’s changed? It’s very difficult, up to impossible. However, if you rebase, a quick look at the git log will show the newest commits on top. Excellent and shiny.

Now we can know exactly what’s changed, revert if necessary, etc. This is also relevant in the case of Pull Requests, and any other situation in which you inspect the commit log. To review, you should now be able to understand the excellent documentation and visualization at and

  • git log Yes! Our commits are on top. We can easily see exactly what we’ve changed, by commits. To stress the point, when you ‘merge’, the top commits in the commit log will be the last commits pushed to master by *anyone*, not necessarily yours – very confusing.
  • git push –force (unless someone else has pulled this branch. This will mess them up.)

If we rebase over master and then push to our branch, we might have to override a previous push to the branch, since we’ve rewritten history (moving our commits to the ‘top’). The easiest way to overcome this is by –force’ing our code into the repo. Obviously this might create issues for anyone sharing our branch, which is why this method is advocated only if you are not sharing this branch with others.

3) Conflicts

You might have conflicts during the rebase. If this happens, stay calm and follow git’s instructions. Git is here to help you (and if we freak out and lose our marbles, we can always git rebase –abort聽and go back to square 1.)

As always, Git is a little (too?) verbose. But it helpfully CAPSLOCKS the important part:聽And at the end, it will (vaguely) what you need to do: OK, what’s going on? The issue to understand is that when ‘rebasing’, Git first ‘grabs’ the master branch (or whatever branch you’re rebasing on) and then ‘applies’ all of your commits, one-by-one, *on top* of those commits. (As we said, this is main difference from ‘merging’, which integrates (well, merges) your commits in-between the commits on master.). Unfortunately, sometimes we have conflicts, but we can solve them.

Git has already told us, but to be sure a git status聽will show us the files being changed in *this* commit, including the conflicted ones. (Recall, we are rebasing all of the commits in our branch, one-by-one. Each commit might entail several files.)

You might conflicts in one or more files. Go into those files and fix the conflict[s], the standard way . Now back in the shell, we can proceed, recalling git’s instructions: git rebase –continue.

Note, you might have more than one conflicting commit – we are ‘rebasing’ all of your commits, so each one might contain a conflict you might have to solve.

4) Summary

Hopefully by now you have both understood what rebase does (specifically, differently form merging) and why it is important. Hopefully you have also lost your fear of rebase conflicts.

Remember that even if you don’t need it for yourself, the team as a whole can much better observe each other’s work if everybody rebases.

Be a team player – rebase.

OS X: Maximize windows the right way with RightZoom

OS X’s behavior regarding maximizing聽window size can be quite unpredictable and aggravating for those used to Window’s default maximize-to-screen. Shift/Command-clicking the maximize button doesn’t seem to get the job done consistently, either.

What you can use is RightZoom, a tiny utility to allow you to maximize your windows to fit the screen, and using the keyboard to boot!


1. Go to聽

2. Download RightZoom.

3. Open it by going to downloads folder, open folder, right-click on RightZoom, open, open.

4. Configure it to maximize your screen when pressing, say, Ctrl-Shift-M (I recommend using ‘Ctrl’, since it seems that with you can also toggle back to previous size).

5. Profit!聽Maximize screens to your heart’s delight.

Vim Basics: .vimrc, Ruby Coloring and Syntax

I only use Vim when I have to. But sometimes, you have to – as in when working on a remote server. You might as well know what the hell is going on. So get comfortable with it. Here’s how to at least enable some sanity in your vim view.

1. Go to your root dir. Create/find a “.vimrc” file. (The ‘rc’ stands for ‘Run Commands‘, by the way) Just like bashrc, this file will run every time you run vim, so you can put some setup instructions here.

2. Go to (or create) ~/.vim/syntax. This folder holds the various syntax-highlighting rules files.

3. Execute聽wget, for a file with Ruby syntax rules (Google around if you need a different language).

4. Back to ~/.vimrc, add the following:

:colorscheme delek
:syntax on
:set nu

The first command sets a nifty colorscheme, the second one turns on the syntax highlighting for ruby files, and the third one turns on line numbers.

5. Now vim your favorite ruby files, like a boss.

讗讬谉 讻诪讜 讛驻住讬讻讜诪讟专讬

讻诪讚讬 注转 诇注转, 注讜诇讬诐 拽讜诇讜转 驻讜驻讜诇讬住讟讬诐 讜诪讚讘专讬诐 注诇 诇讘讟诇 讗转 讛驻住讬讻讜诪讟专讬. 讻讬 讛讜讗 诇讗 砖讬讜讜讬讜谞讬, 讻讬 讛讜讗 诇讗 诪砖拽祝, 讻讬 讛讜讗 诇讗… 诇讗 诪住驻讬拽 讟讜讘. 诪讛 讞讘诇, 砖讻诇 讛谞转讜谞讬诐 诪专讗讬诐 砖讛讘讞讬谞讛 讛驻住讬讻讜诪讟专讬转 讛讬讗 讘讚讬讜拽 讛讻诇讬 讛讻讬 讟讜讘 诇转驻拽讬讚 砖诇讛. 讗讝 讘讜讗讜 谞讚讘专 注诇 讝讛.

1. 讛驻住讬讻讜诪讟专讬 诇讗 诪砖拽祝 讗讬谞讟讬诇讬讙谞爪讬讛.聽讝讜 讗讜诇讬 讛谞拽讜讚讛 讛讞砖讜讘讛 讜讛专讙讬砖讛 讘讬讜转专. 讛诪拽讟专讙讬诐 讟讜注谞讬诐 砖’讗讬谉 讻诇 拽砖专 讘讬谉 讘讬爪讜注 讘驻住讬讻讜诪讟专讬 诇讘讬谉 讗讬谞讟讬诇讬讙谞爪讬讛’. 讬讬转讻谉 诪讗讜讚 砖讻讱 讛讚讘专, 讗讘诇 讝讛 讘讻诇诇 诇讗 诪砖谞讛: 转驻拽讬讚 讛驻住讬讻讜诪讟专讬 讗讬谞谞讜 诇讘讚讜拽 讗讬谞讟讬诇讬讙谞爪讬讛. 诪讬讜转专 诇爪讬讬谉 砖讛诪讜谞讞 ‘讗讬谞讟讬诇讬讙谞爪讬讛’ 讞诪拽诪拽 诇诪讚讬, 讗讘诇 讙诐 讗诐 讗讬谉 拽砖专 讘讬谉 讛诪讘讞谉 诇诪谞转 诪砖讻诇 讗讜 诇讻诇 拽专讬讟专讬讜谉 讗讞专 诇诪讚讬讚转 讬讻讜诇讜转 拽讜讙谞讬讟讬讘讬讜转 讝讛 讗讬谞谞讜 驻讙诐 讘诪讘讞谉, 砖诪讟专转讜, 讻讗诪讜专, 讗讬谞讛 诇讘讚讜拽 讗讬谞讟讬诇讬讙谞爪讬讛. 讗讝: 讛驻住讬讻讜诪讟专讬 诇讗 讘讛讻专讞 诪砖拽祝 讗讬谞讟讬诇讬讙谞爪讬讛. 讜讝讛 讘住讚专.

2. 讛驻住讬讻讜诪讟专讬 诪砖拽祝 诪爪讜讬谉 住讬讻讜讬讬 讛爪诇讞讛 讘转讜讗专 专讗砖讜谉.

拽讬讬诐 讙讜祝 爪讬讘讜专讬 砖谞拽专讗 ‘讛诪专讻讝 讛讗专爪讬 诇讘讞讬谞讜转 讜讛注专讻讛’. 讛讜讗 讬讜砖讘 讘讬-诐. 讛讜讗 讛讜拽诐 注”讬 讜注讚 讛讗讜谞讬讘专住讬讟讗讜转 讘讬砖专讗诇, 讜驻讜注诇 讘驻讬拽讜讞诐. 注讜讘讚讬诐 讘讜 讛专讘讛 讗谞砖讬诐 讞讻诪讬诐 (讙讬诇讜讬 谞讗讜转 诪砖转诪注: 讗谞讬 诇讗 注讜讘讚 砖诐). 转驻拽讬讚讜 (讘讬谉 讛砖讗专 讜讘注讬拽专) 诇讬爪讜专, 诇驻拽讞 讜诇谞讛诇 讗转 诪讘讞谞讬 讛讻谞讬住讛 诇讗讜谞讬讘专住讬讟讛, 讜讘讻诇诇 讝讛 讛驻住讬讻讜诪讟专讬. 拽专讬, 讛讙讜祝 讛讝讛, 讛诪专讻讝 讛讗专爪讬 诇讘讞讬谞讜转 讜讛注专讻讛, 注讜讘讚 拽砖讛聽注讘讜专 讛讗讜谞讬讘专住讬讟讗讜转, 诇讬爪讜专 诪讘讞谉聽注讘讜专谉, 讻讝讛 砖讬砖拽祝 讘爪讜专讛 讛讟讜讘讛 讘讬讜转专 讗转 住讬讻讜讬讬 讛讛爪诇讞讛 讘转讜讗专 专讗砖讜谉. 讝讗转 讻讬 讛讛谞讞讛 砖诇 讛讗讜谞讬讘专住讬讟讗讜转 讛讬讗 砖讛诐 专讜爪讬诐 诇拽讘诇 讗转 讛转诇诪讬讚讬诐 讘注诇讬 讛住讬讻讜讬 讛讟讜讘 讘讬讜转专 诇讛爪诇讬讞 讘转讜讗专 专讗砖讜谉. 注诇 讛谞讞讛 讝讜 谞讬转谉 诇讞诇讜拽 诇讙讘讬 讛爪讚拽 诪讗讞讜专讬讛, 讗讘诇 讛讬讗 讛拽讬讬诪转.

讗讝 讛讙讜祝 讛讝讛, 转驻拽讬讚讜 诇讬爪讜专 诪讘讞谉 砖讬讬转谉 讗转 讛转讜拽祝 讛住讟讟讬住讟讬 讛讟讜讘 讘讬讜转专 诇讙讘讬 讛爪诇讞讛 讘讗讜谞讬讘专住讬讟讛. 诇诪讘讞谉 讛讝讛 讬砖 砖诐 – 讛驻住讬讻讜诪讟专讬. 讻驻讬 砖谞讬转谉 诇爪驻讜转 诪讙讜祝 专爪讬谞讬, 讛讜讗 讗祝 诪讘爪注 讞讬转讜讻讬诐 住讟讟讬住讟讬诐 诇讗讞讜专, 注诇-诪谞转 诇讘讚讜拽 讗转 诪讬讚转 讛讛爪诇讞讛 砖诇 讛诪讘讞谞讬诐 砖驻讬转讞 (讜注诇-诪谞转 诇砖驻专 讗讜转诐). 讜讗讻谉, 诪住转讘专 (讻诪讛 诪驻转讬注) 砖讛驻住讬讻讜诪讟专讬 诪谞讘讗 诪爪讜讬谉 讗转 诪讬讚转 讛讛爪诇讞讛 讘转讜讗专 专讗砖讜谉. 讝讗转 讙诐 讘讞转讻讬诐 讘转讜讱 讞讜讙 诇讬诪讜讚 诪住讜讬诐.聽讘诪讬诇讬诐 讗讞专讜转, 讝讜 讗讬谞谞讛 讚注讛, 讗诇讗 谞转讜谉 住讟讟讬住讟讬 讚讬 驻砖讜讟: 讛拽讜专诇爪讬讛 讘讬谉 爪讬讜谉 讛驻住讬讻讜诪讟专讬 诇诪讬讚转 讛讛爪诇讞讛 讘转讜讗专 专讗砖讜谉 讙讘讜讛讛 诇诪讚讬.聽

3. 讛驻住讬讻讜诪讟专讬 (+讘讙专讜讬讜转) 讛讜讗 讛讻诇讬 讛住讟讟讬住讟讬 讛讟讜讘 讘讬讜转专 诇诪讟专讛 讝讜.

讻讗诪讜专 讜讻诪讜讘谉, 诇讗讜谞讬讘专住讬讟讗讜转 讬砖 讗讬谞讟专住 诇拽讘诇 讗转 讛住讟讜讚谞讟讬诐 讛诪转讗讬诪讬诐 讘讬讜转专. 讛拽专讬讟专讬讜谉 讛拽讬讬诐 讻讬讜诐, 讛讜讗 诪讬讚转 讛住讘讬专讜转 诇住讬讬诐 讗转 讛转讜讗专 讛专讗砖讜谉 注诐 爪讬讜谉 讙讘讜讛. 讘讛转讗诐, 讛讜拽诐 讙讜祝 砖转驻拽讬讚讜 诇讬爪讜专 诪讘讞谉 砖讬谞讘讗 讗转 讛住讘讬专讜转 讛讝讜. 诇诪讘讞谉 拽讜专讗讬诐 ‘讛驻住讬讻讜诪讟专讬’, 讜讘讚讬拽讜转 住讟讟讬住讟讬讜转 驻砖讜讟讜转 讬讞住讬转 诪专讗讜转 砖讗讻谉, 讛讜讗 讘注诇 讻讜砖专 谞讬讘讜讬 (讘讚讬注讘讚) 讙讘讜讛 讘讬讜转专 砖诇 诪讬讚转 讛讛爪诇讞讛 讘转讜讗专. 讬讞讚 注诐 爪讬讜谞讬 讛讘讙专讜讬讜转 (‘住讻诐’), 讛砖讬诇讜讘 谞讜转谉 讗转 讬讻讜诇转 讛谞讬讘讜讬 讛讟讜讘讛 讘讬讜转专 诇诪讬讚转 讛讛爪诇讞讛 讘转讜讗专. 讝讛 诇讗 诪驻转讬注, 讻讬 讛砖讬诇讜讘 讛讝讛 诇讗 谞讜诇讚 讜诇讗 谞砖讗专 讘诪拽专讛; 讛讜讗 讛砖讬诇讜讘 讘讜 诪砖转诪砖讬诐, 讻讬 诪住转讘专 砖讛讜讗 讛砖讬诇讜讘 砖诪谞讘讗 讘爪讜专讛 讛讟讜讘讛 讘讬讜转专. 谞讬住讜 诪讚讚讬诐 讗讞专讬诐, 讜诇讗 诪爪讗讜 诪砖讛讜 讟讜讘 讬讜转专.

讗讛, 专讙注 – 讘注爪诐, 讻谉 诪爪讗讜 拽专讬讟专讬讜谉 讗讞讚 讟讜讘 讬讜转专 诇谞讘讗 诪讬讚转 讛爪诇讞讛 讘转讜讗专 专讗砖讜谉 –聽诪讬讚转 讛讛砖转讻专讜转 砖诇 讛讗讘. 讻谉, 讛谞转讜谉 讗砖专 诪谞讘讗 (住讟讟讬住讟讬转) 讘爪讜专讛 讛讟讜讘讛 讘讬讜转专 讗转 诪讬讚转 讛讛爪诇讞讛 砖诇讱 讘转讜讗专 专讗砖讜谉, 讛讜讗 讻诪讛 讻住祝 讗讘讗 砖诇讱 诪专讜讜讬讞. 诪驻转讬注? 诇讗 讘诪讬讜讞讚. 讗讜讻诇讜住讬讜转 讗诪讬讚讜转 讛谉 讞讝拽讜转 讬讜转专 讜讟讜讘讜转 讬讜转专 讘诇讬诪讜讚讬诐 (讜讗讜诇讬 住转诐 讬砖 诇讛诐 讬讜转专 驻谞讗讬 讻讬 讛诐 诇讗 爪专讬讻讬诐 诇注讘讜讚 讘讝诪谉 讛诇讬诪讜讚讬诐). 讘讻诇 讗讜驻谉, 讘专讜专 砖讝讛 诇讗 拽专讬讟专讬讜谉 ‘驻讬讬专’ 讜讟讜讘 砖诇讗 诪砖转诪砖讬诐 讘讜. 讛驻住讬讻讜诪讟专讬 讛专讘讛 讬讜转专 ‘驻讬讬专’, 讙诐 讗诐 诪讻讜谞讬 讛讻谞讛 讙讜讘讬诐 住讻讜诪讬诐 砖注专讜专讬讬转讬讬诐.

讗诐 讻谉, 讛驻住讬讻讜诪讟专讬 诪谞讘讗 讟讜讘 讬讞住讬转 讗转 诪讬讚转 讛讛爪诇讞讛 讘转讜讗专 专讗砖讜谉. 讬讞讚 注诐 谞转讜谞讬 讛讘讙专讜讬讜转, 讛爪讬讜谉 讛诪砖讜诇讘 讛讜讗 讛讻诇讬 讛住讟讟讬住讟讬 讛诪谞讘讗 讛讟讜讘 讘讬讜转专 砖谞诪爪讗 讘讬谞转讬讬诐. (讞讜抓 诪诪讬讚转 讛讛砖转讻专讜转 砖诇 讛讗讘, 诪诪谞讛 讟讜讘 砖诪转注诇诪讬诐.) 讜讝讛 诇讗 讘诪拽专讛; 讛诪诪爪讗讬诐 讛讗诇讜 讛讬谞诐聽讛住讬讘讛 诇砖讬诪讜砖 讘驻住讬讻讜诪讟专讬 讜讘讘讙专讜讬讜转 讻拽专讬讟专讬讜谉 拽讘诇讛. 讻诇 讘讬拽讜专转 注诇 讛诪讘讞谉 讻讻诇讬 诪谞讘讗, 专讗讜讬 砖转注讜诪转 注诐 讛讗转讙专: 讛讗诐 讗谞讞谞讜 讬讻讜诇讬诐 诇讛爪讬讙 讻诇讬 讟讜讘 讬讜转专? 讻诇讬 砖注讘讜专聽讻诇诇 讛讗讜讻诇讜住讬讛 讬砖诪砖 讻诇诇 讗爪讘注 讘注诇 讻讜砖专 谞讬讘讜讬 讙讘讜讛 讬讜转专? 讗谞讬 讗讬谞谞讬 诪讻讬专 拽专讬讟专讬讜谉 讛讜诇诐 砖讻讝讛, 讜讗祝 诪注讜诇诐 诇讗 砖诪注转讬 讛爪注讛 住讘讬专讛 讘讻讬讜讜谉.

诇讘讬谞转讬讬诐, 讗谞讞谞讜 谞讗诇爪讬诐 诇讛讬砖讗专 注诐 讛诪住拽谞讜转 讛住讟讟讬住讟讬讜转 讛讘诇转讬-谞注讬诪讜转: 讛讗讜谞讬讘专住讬讟讗讜转 爪专讬讻讜转 讚专讱 诇谞讘讗 诪讘讬谉 讻诇诇 讛诪讜注诪讚讬诐 诇诇讬诪讜讚 讘讗讜谞讬讘专住讬讟讗讜转, 诪讬 讛诐 讛拽讘讜爪讛 讘注诇转 讛住讬讻讜讬 讛讟讜讘 讘讬讜转专 诇讛爪诇讬讞 讘转讜讗专 专讗砖讜谉. 讛住讟讟讬住讟讬拽讛 诪专讗讛 砖讛砖讬诇讜讘 砖诇 讛驻住讬讻讜诪讟专讬 讜谞转讜谞讬 讛讘讙专讜讬讜转 讛诐 讛诪谞讘讗 讛讟讜讘 讘讬讜转专. 讬砖 讬讜爪讗讬诐 诪谉 讛讻诇诇 (讜讻诪讜讘谉 砖讗转诐 诪讬讜讞讚讬诐 诪讗讜讚), 讗讘诇 讗讬谉 讻讬讜诐 讻诇诇 讟讜讘 讬讜转专.

注专讬讻讛: 讻专讙讬诇, 诪住转讘专 砖注砖讜 讗转 拽讜讚诐, 诇驻谞讬, 讜讟讜讘 讬讜转专. 讛诪专讻讝 讛讗专爪讬 注专讱 (讜驻专住诐) 谞讬转讜讞 讚讜诪讛 注诇 讛驻住讬讻讜诪讟专讬, 诪诪谞讜 注讜诇讛 讘讬谉 讛砖讗专 讻讬 讛诪转讗诐 讛住讟讟讬住讟讬 (驻讬专住讜谉, r) 讘讬谉 讛驻住讬讻讜诪讟专讬+讘讙专讜讬讜转 诇讘讬谉 住讬讜诐 讛转讜讗专 讛讜讗 0.55 (诪讻讜讘讚 讘讬讜转专). 讻诪讜 讻谉 讘谞讬转讜讞 讬砖 讛转讬讬讞住讜转 诇转诇讜谞讜转 注诇 讛讘注讬讬转讬讜转 讛讞讘专转讬转 砖诇 诪讘讞谉 讛驻住讬讻讜诪讟专讬, 讜讻谉 诇讗驻砖专讜转 讛诪讬讜谉 注诇-住诪讱 爪讬讜谞讬 砖谞讛 专讗砖讜谞讛 讘讗讜谞讬讘专住讬讟讛. 拽专讬讗讛 诪爪讜讬谞转 讘谞讜砖讗:聽

Chrome-Fu: Custom URLs via ‘Search Engine’ hacking

(Technical post.)

Chrome’s omnibar is very good at helping me speed quickly to my desired (and oft-used) websites. 脺ber-speed is important at everyday tasks, since there are no small delays. In some cases the omnibar does not manage well enough; in those cases I would like to define a custom route, s.t. hitting ‘foo’ in the omnibar will redirect me to

So here’s the relevant thread, and to my view the best solution:

1. Open chrome’s settings via the omnibar,聽chrome://settings/searchEngines

2. Add a new fake ‘search engine’, namely entering a聽name,聽keyword, and聽URL. In our case these would be “My Custom Route”,聽foo, and聽聽

3. ‘Done’, and we are: now Cmd+L,聽f-o-o, ‘enter’ will take us to our custom site.

Kind of a hack (too bad Chrome doesn’t offer this as built-in functionality), but useful for sites we visit a lot that don’t have an easy-to-find URL.

There Are No Small Delays

Software development is (arguably) one of the most complicated, mentally demanding disciplines, built on increasingly complex layers of abstraction, comprised only by the substrate of thought. One is always juggling multiple complex data and procedural flows in one’s mind.

To quote Dijkstra (a prominent pioneer in Computer Science) on the subject:

From a bit to a few hundred megabytes, from a microsecond to a half an hour of computing confronts us with completely baffling ratio of 109! The programmer is in the unique position that his is the only discipline and profession in which such a gigantic ratio, which totally baffles our imagination, has to be bridged by a single technology. He has to be able to think in terms of conceptual hierarchies that are much deeper than a single mind ever needed to face before. […]聽For [many], an automatic computer is something like the familiar cash register, only somewhat bigger, faster, and more flexible. But the analogy is ridiculously shallow: it is orders of magnitude worse than comparing, as a means of transportation, the supersonic jet plane with a crawling baby, for that speed ratio is only a thousand.

(The source, while lengthy, is a worthwhile read.)

One consequence is that thought interruptions are costly. Now, a single interruption is always costly, as aptly described in the sort-of-famous comic, “This is why you shouldn’t interrupt a programmer”:

This is why you shouldn’t interrupt a programmer


So a聽single interruption is quite costly.聽A delay lasting for one second may cost orders of magnitude more in productive time lost.

Multiple interruptions (even seemingly minor ones) not only add up incrementally, but their total result is even worse than their mere sum, as momentum and concentration needs to be picked up time and again. This includes indiscernible amounts: the same way that a bad shoe or an un-warmed-up muscle might hinder a runner (physical hinderances), if a programmer has to stop to think about anything but the task at hand, it breaks his/her flow. The issue at hand is not (only) the inevitable gradual accumulations of seconds and minutes wasted, but the loss in overall momentum.

Bottom line: There Are No Small Delays. Every delay, sidetrack, interruption – by its very nature – costs many times its size in missed mental productivity.

This why keyboard shortcuts matter. Why short URLs matter. Why dealing with timesheets, bills, and emails is destructive; why you shouldn’t have to ‘just remember this small thing’ like having to turn the light on in the staircase at your office, or one of many passwords; why I never answer the phone.

A moment’s distraction could mean a productive hour lost.

There Are No Small Delays.

Pimp Your RubyMine

(The following is a very technical post, aimed at Ruby software developers.)

0. Introduction

I spend most of my day coding in Ruby. I alternate between two main code editors:

1. Sublime Text, “The Editor You’ll Fall in Love With“, which is truly beautiful and fun to work with. Sublime is sweet.
2. RubyMine, a [big-ass] IDE, Ruby’s equivalent of ‘Eclipse’, which has a lot of shortcomings. While I personally abhor the bloatware and, IMHO, mostly redundant functionalities IDEs offer, three main issues keep me using RubyMine as my dominant code editor (though I alternate):

a. Click-Through to definition
b. Superior breakpoints (set without typing code as ‘debugger/binding.pry’)
c. Superior code inspection and evaluation during debugging runtime

Though I would honestly love to use Sublime exclusively (and in fact, am using it to write this very post), points a-c are deal-breakers for me. Appropriate packages for Sublime Text seem to exist for these, but I have found them to be sadly inadequate/subpar. The end result is I find myself doing most of my day-to-day work in RubyMine. I am (obviously) not the only one, and come to think of it, I believe my team has a slight majority in RubyMine users over Sublime users. Huh.

So, if you too find yourself using RubyMine (and by all means, try Sublime ‘cuz it is awesome), you should spend the due diligence into pimping it up into the best (read: fastest, most lightweight) editor it can be. (This post will focus on usability, not technical performance.) Using RubyMine 6 – whose performance is not bad at all – the following creates an end result which gives Sublime a run for its money.

1. Setup:
– go to preferences: cmd+,
– find the keymap: preferences + search for ‘keymap’
– search for ‘find action’ and change[/add] its keyboard shortcut to shift+cmd+P, as in Sublime.
– Now access keymap via find-action+’keymap’ (Change current keymap)

Boom, now we are on fire. We can search for any action, and assign it a custom keyboard shortcut via find-action+keymap+search (cmd+shift+P, ‘keymap’, ‘Change current keymap’)

The following are some pimped keyboard shortcuts RubyMine offers (along with a few suggestions for changing some keys)

2. Your minimal set of ninja swiss-knife Code Editing/Debugging keyboard shortcuts:

(These are all awesome. You should seriously be using at least the following set聽all the time.)
find action: shift+cmd+P (see above)
go to聽file: cmd+shift+O (change this to cmd+P, as in Sublime, via keymap. Consistency [with yourself and with others] is good.).
toggle breakpoint: cmd+F8 聽(sweet! change this to cmd+B[reakpoint..], and remove the conflicts. )
click-through, go to declaration:聽cmd+B (sweet!) change this to cmd+D[eclaration..], and remove the conflicts).
go back/fwd: cmd+alt+left/right {recommend switching to cmd+'[‘/’]’}
step over:聽F8
step into:聽F7
open code evaluation window:聽alt+F8
edit keyboard shortcut for anything (as above) – cmd+shift+P, ‘keymap’, ‘change current keymap’, find action name (you can use the default keymap as a reference for action names).

3. Prettiness (it counts):
– set theme (cmd+, search for ‘fonts’) as ‘monokai’ (same as sublime); increase font size to 14. (and save as your own theme name.)
– edit menus appearance to your liking by going to Preferences (cmd+,), the ‘appearance’.
– hide all menus by menu->view->uncheck all toolbars ()
– disable code analysis on right-hand side (next to vertical scrollbar) by right-clicking it, ‘customize highlighting level’, ‘none’. (It actually has some pretty good tips, but syntax tips are notoriously problematic, especially unless the entire team is using the same one.)

Awesomeness.聽If you have further tips, hit me up. No go forth and remember – real men don’t use the mouse.