Vim Tricks – Googling with keywordprg

Most vim users are familiar with the man page lookup; K under the cursor or on visual selection. For anyone who needs a quick refrersher lets take a look at the help docs (help :K)

              *K*
K     Run a program to lookup the keyword under the
      cursor.  The name of the program is given with the
      'keywordprg' (kp) option (default is "man").  The
      keyword is formed of letters, numbers and the
      characters in 'iskeyword'.  The keyword under or
      right of the cursor is used.  The same can be done
      with the command
        :!{program} {keyword}

So we can see that the default program (keywordprg / kp) is defaulted to “man” and the keyword is determined by what is right under the cursor when it is used. The other important thing to not is the fact we could invoke man or whatever program we want using :!program_name but that’s not as fun as reconfiguring the default behavior to do what we want.

Let’s imagine that for some reason we find ourselves copying sections of text and searching google for the results. Rather than doing this over and over why not just change the keywordprg to a custom bash script to do what we want. First thing’s first lets write a simple bash script to open up the browser (I assume every OS has some way to open a browers with a given URL; This is written on an Ubuntu machine but if I were on a Mac I’d use open and test / google to make sure the syntax works as expected)

#!/bin/bash
firefox "https://www.google.com/serach?q=$1"

Give it a handy name like googleShit, move it into your PATH and and pop open that ~/.vimrc to change your default keywordprg

set keywordprg=googleShit

And now when you use K inside a new vim session you will be googling contents rather than looking up the man pages! If you find yourself repeating a task under the cursor or in visual mode pretty handy trick to have in the utility belt. Use a little imagination and you can come up with something to improve your daily workflow.

Different browsers are the worst

While working on a personal project I ran into an issue with a bootstrap navbar collapse. In my local testing everything went fine and I decided to push and hoped everything would behave properly.. I grab my iPhone 5 and take a look only to see that the dropdown is not working at all.

After doing some googling I came across a SO post that accurately described the shitty situation I found myself in (the dropdown working in all browsers (including IE) and failing on all iOS devices)

The guy was apparently using a <a> tag without the href attribute which would fail to trigger the collapseable menu. That’s all fine and good but I’m trying to use a span and am too lazy to wrap my one line in a tag so I hunt for a better solution..

My original (almost functional code) trigger looks like this

<span class="glyphicon glyphicon-menu-hamburger navbar-toggle" "style"="color:white;", "data-toggle"= "collapse", "data-target"=".navbar-collapse" />

Can you spot what’s missing with this simple data-toggle? It turns out you need to add cursor: pointer to the style of whatever the element might be..

If the majority of people are usin links and buttons to trigger collapsable content then everything will work as expected and no problems will be had. For people who do what they want there’s shit like this to deal with.

And that’s the web for you. Use some CSS/JS library like Bootstrap in hopes of saving yourself time and then tackle random shit like this. For the novice I’d imagine this would be an aggravating roadblock that would make hault all progress for a few solid hours until they give up and use a button or link to accomplish the same thing as adding the cursor: pointer styling.

If you want to do work with web applications enjoy things like this because this is what we deal with on the daily.

Into the Abyss with Turbolinks

Previous attempts to adopt turbolinks during upgrades or new projects led me to the conclusion that I have a burning hatred for everything the project stands for (rage hatred is the worst kind..). From conversations with other Rails folks + former CTOs it seemed like turbolinks was something I could avoid without batting an eyelash (see comparisons to Windows 8 decision making or just ask a local Rails expert what their experience with turbolinks has been like)

As someone who previously ignored the efforts being made by DHH and the core team I would just start a new project with --skip-turbolinks to ensure my own sanity and continue with the hammering.

Since I’m a bit late to this conversation it’s nice to read posts like Yahuda Katz’ problem with turbolinks and 3 reasons why I shouldn’t use Turbolinks to get my hopes and dreams crushed.. Here is just the beginning of the headache that one can look forward to if they are to continue down through the thorns

Duplicate Bound Events

Because JavaScript is not reloaded, events are not unbound when the body is replaced. So, if you’re using generic selectors to bind events, and you’re binding those events on every Turbolinks page load. [This] often leads to undesirable behavior.

Alright so to be honest this isn’t that bad. People can bitch about global state all they want but as someone who enjoys thinking in a “game loop” I don’t mind this and feel like I can easily write my own code to these standards

Audit Third-Party code

You audit all third-party code that you use to make sure that they do not rely on DOM Ready events, or if they do, that they DOM Ready events are idempotent.

And this is where it starts to get fun.. I just stumbled upon a bug that reared its head beacuse of these two issues and I wanted to post a solution that I may find myself using more moving forward..

Imagine we are using typeahead.js we want to go ahead and initialize our typeahead input on a given page. Here’s what the JS might look like

  $('#searchBar .typeahead').typeahead({
    hint: true,
    highlight: true,
    minLength: 2
  },
  {
    name: 'estados',
    source: matcher(items)
  });

A pretty harmless call that you are probably going to copy paste in to try the first time you mess with typeahead.js. It works and you move on.. But be careful because turbolinks will give you some intereseting behaviour if we navigate between the page that has this piece of JS and another page. .

Turbolinks will invoke this each time the page is “loaded”. Because of this we will spawn a new instance of the typeahead input and the associated hint div.. For some reason (one I don’t care to look into) typeahead.js will spawn a new instance and hide the others rather than truly cleaning up. No matter what we are left to fend for ourselves in the wilds of turbolinks so we search for a solution.

I figure we can just handle global state a little better than your typical inline JS would. To do this we simply wrap the initializer in a conditional to verify the number of typeahead divs that are present on the screen. With proper naming we should be able to expand this approach to multiple typeahead instances.

  if($('.typeahead.tt-input').size() < 1) {
    $('#searchBar .typeahead').typeahead({
      ...
    }
  }

With that extra check we are able to handle the global state that turbolinks will create when natrually navigating and attempting to speed up our page.

A recent webcast featuring DHH got me thinking about how simple the problem of a web application really is. The server demands are not a problem whatsoever (30ms response times are all you need to be perfect anything lower is not truly noticable or necessary). We have an issue when it comes to how the rest of the “page-load” occurs for the user.

We all know the “hard refresh” links, the ones that clearly jump you to a new page with new content. Loading a new page is the same old same old that we’ve been doing since we could serve shit up. Of course the new way is the “one page app” that allows the user to navigate without ever having to disengage from the page they were on. IMO the trend is getting a bit insane (always felt the JS community was a bit heavy handed with trying new things..) and trying to keep up with the latest quarrels and trends is tiring. Where is the solution to the seamless application?

It’s clear that some will say Ember or React are the way forward to building beautiful apps that will take over the world but I’m not sure I believe a JS Framework is what will carry an application. So why learn all that unecessary complexity when HTML5 is here?

If Turbolinks lives up to the into of the README I will be a happy Rails camper.

Turbolinks makes navigating your web application faster. Get the performance benefits of a single-page application without the added complexity of a client-side JavaScript framework. Use HTML to render your views on the server side and link to pages as usual. When you follow a link, Turbolinks automatically fetches the page, swaps in its , and merges its , all without incurring the cost of a full page load.

C’mon Turbolinks don’t let me down again..

Development Turntable

And the turntable keeps on turnin’ and turnin’
Nothing can fuck with the way it goes around
– Slug

Human nature tells us that there is a natural desire to make sense of the uncertain and create some semblance of control in our lives. This fundamental desire to create order where chaos thrives is the entire struggle of every growing company and the realization that always occurs when a company begins to grow past its infancy/adolescence. You know a company is in this phase when the Operations side wants to throw X engineers at the problem in hopes that it will increase effiency and get us to that cash cow ASAP (a different can of worms for another time)

When I was introduced to SCRUM in the real world I was blown away with the organization that seemed to be instilled throughout a company of ~20 engineers (the largets team I had worked with at the time) and >100 in all departments. Communication seemed to be streamlined and the pace of development seemed like it was pushing limits and allowing the team to move at the maximum velocity.. As a disclaimer I still am a believer in some system like SCRUM (loose-SCRUM) to keep visibility in a minimal way but I’d like to rethink the “optimal development cycle”

Whenever I think about business I am a bit cynical after seeing a company be sold with very little transparency to the <10 employees in the ranks. Because of past experiences with companies and individuals who have reneged on contracts and payments I like to assume the worst case when thinking in the hypothetical.

Let’s imagine a company that has just gone through a big round of funding and is now ready to make the push from 150 employees to 300+ w/ multiple offices around the United States to house all the talent that they have. This company is going places and they are in control of their destiny. Development team is churning out features left and right and the folks in Operations and Sales are able to keep customers happy and sign new customers with ease. In our ficticious company we have happy employees in every aspect of the business.

Now what happens when a Sales manager gets word that the company can sign the biggest contract ever by orders of magnatiude that make

To be continued..