Chrome-like Tab behavior in Vim on Mac OS X

Google Chrome has trained my brain that Ctrl+T, and ⌘+⌥+[arrows] will move me to the next and previous tabs. I wanted vim to work the same way. In .vimrc:

""""" TAB BEHAVIOR
" Ctrl+t to open new tab
" Note: this overwrites a shortcut for the tag stack, if you use tags
nnoremap <C-t> :tabnew

" Chrome-like shortcuts for prevtab and nexttab
" (Meaning ⌘+⌥+[arrows])
nnoremap <ESC>[1;9D gT
nnoremap <ESC>[1;9C gt

YMMV on the exact mappings to use, see below on how to figure it out for yourself. I found a lot of solutions that didn’t work for me, including pressing the key combo in vim under Visual Line mode, so it would show me vim’s notation for what keys it’s getting. But the problem was three things failing in some combination:

— The terminal was mangling the input before it got to vim

— Vim wasn’t showing me the starting “^[” (escape key)

— Vim wasn’t displaying the [1; section of the input either. Just “:9C” or “:9D”

After a lot of searching, I finally found this simple solution to figure out what the terminal is actually sending, and translate to vim speak, all in one. Using the terminal on my Macbook Pro, it’s surprisingly simple:

> sed -n l
[Press whatever key combination you want]

The output it showed me was “^[[1;9D”, so my key signature to map was “<ESC>[1;9D”

You can see my entire .vimrc file on Github. Hat tip to Adam Morse for the warning on Ctrl+T and the tag stack.

Today I learned that creating getters & setters in PHP more than doubles execution time.

From reddit, I found this command-line snippet: http://pastie.org/638732. It reminded me that in general I want to do more of these kinds of tests. It’s bound to lead to interesting discoveries.

Any ideas what I should test myself?

 

> php -d implicit_flush=off -r  '\
  class dog {\
    public $name = "";\
    public function setName($name) { $this->name = $name; }\
    public function getName() {return $this->name; }\
  }\
  $rover = new dog();\
  for ($x=0; $x<10; $x++) {\ 
    $t = microtime(true);\
    for ($i=0; $i<1000000; $i++) { \
      $rover->setName("rover");\
      $n = $rover->getName();\
    }\
  echo microtime(true) - $t;\
  echo "\n";}'
1.48462200165
1.49136686325
1.48365998268
1.47310495377
1.46616101265
1.44583415985
1.42663908005
1.43124985695
1.42830300331
1.42891597748

> php -d implicit_flush=off -r  '\
  class dog { \
    public $name = "";\
  }\
  $rover = new dog();\
  for ($x=0; $x<10; $x++) {\
    $t = microtime(true); \
    for ($i=0; $i<1000000; $i++) { \
      $rover->name = "rover"; \
      $n = $rover->name;\
    }\
  echo microtime(true) - $t;\
  echo "\n";\
}'
0.700392007828
0.686674118042
0.687913894653
0.693347930908
0.697072982788
0.708423852921
0.709672927856
0.704964876175
0.704661130905
0.708118915558

30 Days of Programming Interviews

I’m starting a new 30 days experiment! This time with my good friend from University of Maryland, Koffi Kpetigo. Each week we’re picking one chapter from this book on programming interview questions: Cracking the Coding Interview: 150 Programming Questions and Solutions

Each chapter is themed (Arrays & Strings, Object Oriented Design, etc) so each week will be a focus on one of our top four topics. If it goes great after 30 days, then we’ll keep going until every chapter is done. Each morning, I’m waking up at the same time as before (8:30am) and doing a one-hour interview as if someone were asking me questions from that chapter. Then I’ll attempt to document that effort here, for posterity. Then, once a week, we’ll call each other up and do phone screens on questions from the “Medium” and “Hard” chapters (which are miscellaneous unthemed chapters that seem to represent the kinds of questions I’ve actually been asked in interviews.) The weeks are going to be this ordering, with today being Day 1 of the first week:

Week 1 – Chap 7: OO Design
Week 2 – Chap 3: Stacks & Queues
Week 3 – Chap 4: Trees & Graphs
Week 4 – Chap 9: Sorting and Searching

I expect I’ll get two things out of it, with hopefully a few surprise leanings thrown in as we go:

  1. More confidence in a variety of interview questions. Right now I typically go in to an interview with the belief that I’ll be able to figure out most problems, and a solid (though not perfect) understanding of common data structures. But I’ve never studied interview questions themselves, so I always feel like there’s something I’m missing. I’m definitely not one of those people who remembers their sorting algorithms, and I don’t feel like I’m at the point where I can say something like “Ok, this question falls into <question grouping>, which usually depends on <data structure here>, and they’re really looking to see if I can <thought process here>.” Even though I’ve been on the other side of interviewing for years, I still don’t feel like I’ve “pulled back the curtain” 100%. This should change that, or at least start.
  2. A couple new interview questions to use myself. I’ve been using the same one or two interview questions for a couple years now, and I’d like to switch it up. I like my current favorite a lot: it starts with basic algorithms, expands requirements in the middle, and ends up in a larger systems design conversation. But two problems I have with it are: (1) if you’ve heard a similar question for the algorithm part before, you’ll get further, and it’s close enough to a more common interview question that that’s happened a few times. I can correct for this, but I’d like to not have to. (2) I’d like to ask a harder initial question in general, so I can make a more granular evaluation of the top candidates.

Here we go!