Author: sellarafaeli

On the Perils of Failing Silently

Last week we discovered a bug in production where a certain user flow would crash. Naturally, since this was a high-profile flow, the bug was discovered on Thursday evening (the end of the work week in Israel). And naturally, we could quickly reproduce the error in our live site, but it would not reproduce in any non-production environment. Par for the course.

Diving into the issue, we saw that under this set of circumstances, the client was receiving a(n inappropriate) 403, with no further information. Since the flow did not require authentication, this was particularly suspect. We started iterating through the various usual suspects – could our nginx be at fault? Is our load-balancer denying this particular flow? A broken SSL certificate perhaps? Or was something in the code broken, or just deep-six’ing the request with no further info?

Our usual log systems did not show any errors, and upon further inspection we realized that the breaking flow did not result in any applicative logging at all, which was especially odd since we make heavy use of logs and error-log anything that breaks. The lack of applicative logs along with the silent 403 led to the expected back-and-forth between the application code developers and the dev-ops infra people, where each side assumed it’s the other’s fault. Hours spent, dollars lost.

Eventually we traced it down to a particular legacy before_filter (we ride on Rails) which was affected by recent site configuration changes. This before_filter denied the request, but did so extremely silently:

render :nothing => true, :status => 403 and return

Once found, we could quickly verify this was indeed the issue and fix the before_filter to match the configuration changes, making everything go back to normal. However, it had taken us precious time to debug this error – hours with the flow broken, affecting users.

This could have been solved much, much quicker if the before_filter would not be so silent. The act of denial could be appropriately logged, but that’s not so straightforward – we wouldn’t want to log it as an error (since a truthful denial/403 is not an error), and any non-error logging would not be immediately obvious (what we would be looking for, anyway?).

A good way to solve this would be to simply return a non-empty error message to the client. Say:

render :text => "Action denied, Sorry-O.", :status => 403 and return

With a non-empty error message as above, a simple grep would quickly locate the root problem, enabling near-immmediate response.

$ grep "Action denied, Sorry-O." -ir .

Don’t give out compromising information, but *say something*, so your error is identifiable. Rendering ‘nothing’ is the equivalent of saying “Why? Because Fuck You, that’s why.”

Moral of the story: Never fail silently. Just like kids are taught: if you see something wrong, SAY SOMETHING.

Git for Smart Noobs

One of the problems with technical topics is that the oftentimes experts have a very hard time explaining the complicated details to others with less of an expertise. The explanations, aiming for exactness and truthfulness, go over the student’s head and are lost.

In my personal (slow, arduous) journey to learn the basics of OS code development and Git, whenever I manage to reach a more-than-basic understanding of a more-than-basic topic I try to write a post to explain that topic. This (hopefully) results in:

  1. Others (other noobs) benefitting from a down-to-earth explanation in terms they can understand, and
  2. My better understanding of the topic, for the best way to understand something is to explain it.

I’ve been writing using ‘Medium’, a new blogging software, which is aesthetically very pretty and does a good job at it’s main claimed purpose, “getting out of the way” and allowing you to spill your ideas easily.

So far I’ve written on how to use git rebase and git reset. Check it out.

Optimal Notes Strategy For Productivity Freaks

I’ve got lots of stuff to remember so I use notes and I needed a system that was better than any existing tool that I knew of, so I spent a some time thinking about it and now I have a system and it is BOSS.

Use-cases are:

  1. Find a note by name (like ‘git’ or ‘deploy_process’ or ‘electricity bill’)
  2. Find a note by content
  3. Edit, save, sync note to cloud
  4. Access anywhere, anytime, any device
  5. Port all my notes somewhere else in 2 years

The requirements (must be…):

  1. Super-fast to find a note by searching for name.
  2. Super-fast to find a note content.
  3. Super-fast and easy to edit a note and sync to cloud, all without using mouse.
  4. Available online via web, all platforms
  5. Easily exportable (No lock-in)
  6. Complete revision history

Failed attempts: Evernote and GoogleDocs. Both are too heavy, cumbersome, and slow. GoogleDocs is bottlenecked by the network and is in-browser, which is crowded enough. Evernote has a lock-in, no revision history, and is basically 眉ber cumbersome. They might work for you if you’re infinitely patient but I am kind of the opposite.

Best solution:

  1. Open a folder in your Dropbox folder. Call it ‘notes’.
  2. Use your favorite text editor (which should be Sublime Text) to find, add, and edit simple text notes.

Shazam, you’re done. Let’s examine how this answers the requirements and use-cases.

  1. Find a note by name: ST’s fuzzy-search for file names is famously boss.
  2. Find a note by content: Ditto, ST’s search-function is famously sweet.
  3. Editing notes: By definition, it’s already your favorite text editor. Saving syncs it automatically to the cloud (dropbox).
  4. Access anywhere, anyhow:, and you’re golden.
  5. Exportable: it’s just a folder of text files! Evernote, Dropbox, and Google[Docs] may come and go (not to mention other app solutions like SimpleNote, etc.), but text files will be here for a long time. Whenever you want you can copy the whole folder off to your folder, or your SugarSync magic briefcase, and edit the files with vim instead of Sublime. No lock-in, ever.
  6. Dropbox saves all your revision history.

As you can see, these cover the requirements perfectly. To me, this clearly outclasses using GoogleDocs or Evernote for any personal use. I’ve been riding this for about 4 months at time of writing, and it’s been a dream. Anything I need to remember can easily be jotted down to the relevant note and retrieved at the speed of light (well, at the speed of Sublime Text, but it’s pretty damn close). Zero upkeep. Totally free. And I know that when I grow tired of Sublime (and/or switch computer, OS, polar meltdown, etc.) my notes will be there for me. This very post’s draft was written in my ‘blog’ note, where I keep a list of topics and first drafts of posts.

Basically this is has just been riding on the awesomeness of Sublime Text and Dropbox. You lose tiny things like clickable links and rich-text formatting, but those are for girls anyway.

Extra points for using ST+Dropbox for notes::

  • Use a specific Sublime theme for your ‘notes’ folder, so you can easily tell the ‘notes’ Sublime instance from code instances. I use Solarized (Light) because I like the light/dark contrast with code’s Monokai.
  • Set a syntax highlighting that complements free-text notes. I use AppleScript for no reason at all.
  • Organize your files into folders, if you feel like it, but with Sublime’s great search capabilities – it doesn’t really matter. I’ve got 150+ notes by now on everything from Apple to ZenDesk and don’t need the folders.

So: never remember anything again. You’ve got your computer to remember, now that you’ve got your llama-whooping notes mechanism set to retrieve and update notes at whiplash speed.

Now, go forth and multiply. Or at least use efficient notes.

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.