What To Do When A Vim Keymap Doesn't Work

I just started learning Vim, and I’m maybe a bit too enamored with the level of customization I can do. I installed a great Mercurial plugin called Lawrencium (which is excellent, by the way). I loved everything about it… except that I couldn’t get Ctrl-S to commit when viewing the repo status.

Vim Lawrencium

The key is plainly mapped in the plugin. After I hunted down the mapping and figured out the command it should be running, I found I could run the command manually, but I wasn’t sure where to go next to find out why it didn’t work. This led me to StackOverflow where I asked how to debug a faulty keymap. Here’s what I learned.

Make Sure the Key Is Mapped to the Proper Command

Using :map will show you your current key mappings. Add the key you want to check to see only that mapping. In my case, the command was :map <C-S> which produced this output:

v         *@:Hgstatuscommit
n         *@:Hgstatuscommit

The v and n tell me that the key is mapped in visual and normal modes respectively. The last bit is the actual command. I’m not entirely clear what the *@ means, but the rest is the :Hgstatuscommit command followed by a carriage return.

If the mapping happened to be to something I didn’t expect, I could have gone a step further and used :verbose to have Vim tell me where the keys were mapped. That command looks like this: :verbose map <C-S>

Its output shows me it was mapped in the Lawrencium plugin.

v         *@:Hgstatuscommit
        Last set from ~/.spf13-vim-3/.vim/bundle/vim-lawrencium/plugin/lawrencium.vim
n         *@:Hgstatuscommit
        Last set from ~/.spf13-vim-3/.vim/bundle/vim-lawrencium/plugin/lawrencium.vim

Try to Run the Command Manually

If you can’t run the command in the Vim command line (summoned with :), then the command itself is likely the problem rather than the keymap (although, if you’re really unlikely, you might be having both problems at once). If that’s the case, find where it’s declared inside the plugin and use the same sorts of techniques you would use to debug any code you write: put in a few echos to see how far into the command you’re getting and to be sure you’re getting the values you expect.

Assume the Shortcut Isn’t Getting to Vim

This was the final outcome in my case. The shortcut key Control-S was being intercepted by my terminal and was never getting through to Vim. The Vim Wikia had a helpful solution that fixed the problem. As soon as I added the fix to my .zshrc, the command began working like a charm.

Mercurial For Git Users

Git is the only version control system I’ve ever used. By the time I was ready to dive in to version control, it had already won the hearts and minds of developers, so I jumped on board.

Recently, I found myself working on a project under Mercurial version control. I’m always a bit fearful of version control because mistakes, especially when pushed to a remote, can be difficult to undo. It was somewhat harrowing to start committing to someone else’s repo even when you are familiar with the VCS in use; when you aren’t, it’s downright frightening! Fortunately, the differences between Git and Mercurial — at least to perform the basic tasks — are minimal.

Install Mercurial by downloading the installer from the Mercurial site or using Homebrew. The commands you’ll use to get started with your repo are basically the same as their Git counterparts (in terms of usage; what’s happening behind the scenes could be dramatically different).

Start a new repo in the current directory
hg init
Clone a remote repo
hg clone <URL>

In Git, we’re accustomed to making some changes, staging those changes, and committing. Mercurial (along with other VCSs apparently) does not require staging of files. Once a file has been added to the repo, it can then be committed. The one problem this caused for me is that I was unable to selectively commit files until I learned you could list the files along with the commit command in order to commit a subset of the changes.

I also use Git’s interactive staging to make my commits more atomic. An analog to this is available to Mercurial users through the record extension.

Add a file to the repo
hg add <file(s)>
Commit changes
hg commit [file(s)] [-m "Commit message"]
Commit file deletions
hg remove --after
Undo last commit keeping changes
hg rollback

The final piece of the puzzle necessary for collaboration is branching. In most collaborative scenarios, you’ll be creating branches and ultimately merging those into the default (Mercurial’s analog to master) branch.

Creating a branch
hg branch <name>
hg commit -m "New branch commit message"
Switch branches
hg update <name>
Push a new branch
hg push --new-branch
Merge branches
hg merge <name>

One notable difference about branches is that they cannot be deleted after merging. My understanding is that Mercurial will do a sort of trash collection and remove disused branch names from the branch list, but deleting a branch actually deletes the commits associated with it which could be problematic for other branches based on the deleted branch. Picture Michael J. Fox in Back to the Future disappearing from the photo as his parents relationship almost never happened. A fate such as this likely awaits your code if you start deleting Mercurial branches.

On a very surface level, those are the facts you need to know about Mercurial in order to start collaborating on a project. This post no doubt ignores almost all of the nuance and brilliance of Mercurial, but, if your only goal was to get up to speed quickly, you should now be ready to start writing and committing some code!

Where Are Opera Mini Users?

I love icon fonts. You can imagine how I may have felt over the past couple of weeks as stories began hitting the web about the fact that wide swaths of the Internet would not even see my icon fonts. Much of this is due to the fact that Opera Mini, a browser which apparently ditches several beloved modern web standards has a massive userbase — 261 million according to Opera themselves.

This is difficult to believe for most web developers. Have you ever run into anyone who uses Opera Mini? I haven’t. This is entirely anecdotal, of course, but statistics like this tend to manifest as at least one person I might come across in my daily life using the popular thing. That’s not the case here. Here’s why.

The magic of Opera Mini — and the reason it has such a large userbase — is that it uses compression to help squeeze more browsing into restrictive data plans. Opera claims the browser can reduce the size of pages by up to 80%. In this context, it doesn’t make sense to download fonts. These are typically only for aesthetics and don’t really have a place in Opera’s plan to deliver the most web possible with the smallest footprint.

This all breaks when it comes to icon fonts. Since these use non-standard characters, the content of the page changes when they are not loaded. If we end up looking at some text displayed in a system font other than Gotham, we’ll still be able to read and understand it. If we look at glyphs from an icon font that never loaded, this is not the case. Instead, we see some character which the browser displays to mean, “I don’t know what this thing is.” That’s helpful to no one.

Let’s get back to why every third person you meet on the street doesn’t have Opera Mini on their mobile device despite its userbase. It’s because this technique is most useful in countries where mobile data is prohibitively expensive. Opera Mini has incredible marketshare in many African countries, for instance, where they offer data plans as low as 10MB per month. Larger data plans are available, but most users are likely unable to afford these plans.

As of last year, a 1GB mobile data plan from Vodacom, the largest cellular service provider in Africa, was the equivalent of $28 US per month. In Sudan, where Opera Mini has one of its largest footholds at 56% of the mobile market, the minimum wage is 425 Sudanese Pounds per month or about $75 per month. Likely, these workers are not the ones who will purchase any sort of data plan, but this information can calibrate our expectations of even the relatively well-off in Sudan. A $28 data plan is a luxury few can afford.

In this context, the browser makes sense despite its faults. It has strong marketshare in Africa, the Middle East, Eastern Europe, India, and Russia, among others. For these users, Opera Mini allows them to experience web sites with varying degrees of their intended functionality through their mobile devices where they otherwise wouldn’t be able to do so.

My first reaction when these issues and their workarounds began to circulate online was, “Why are so many people using this crippled browser?” Now, it makes sense, but it also brought to light another consideration: Are the users of this browser in my site’s audience? 261 million is a massive number — enough to give any developer pause — but what if it’s simply the case we don’t need to talk to those users?

The point is not to encourage you to hang on to your favorite development techniques even if it means ignoring reality, but, instead, I advocate that we avoid reflexively changing out workflows simply because an extremely large number is being thrown around. How many sites need to be able to reach every individual in the world with any sort of Internet access? I’d venture a guess very few.

Introducing The Thinkful Flaskcast!

I started Thinkful’s online Python bootcamp a while back in an effort to beef up my back-end development skills. As the course was wrapping up, I realized I wasn’t going to be able to get my final project to where I wanted it to be before the end of the course. As I thought about how to fix this problem, I also heard they were looking for ways to tell prospective students what their live mentoring sessions are like. I pitched the idea that I could continue in the course and record my sessions so that they could show exactly how mentoring works.

From this, the Flaskcast was born. The app I’m building is a control interface for my local maker space, the Knox Makers. This will control a remote monitoring system they’re setting up in their hackerspace. I’m embedding the first three episodes of the Flaskcast here for your enjoyment. Many more episodes are still to come.

For more information about the contents of the videos, click through to their Vimeo pages where you’ll find clickable timestamps with the various discussion topics.

Woo Clients By Showing Instead Of Telling

If people already know you and like you, it’s easy for them to decide to pay you to perform a service they need. If that prior relationship doesn’t exist, they need something else that feels substantial. Many pitches to clients begin and end with telling the client what you can do. Some go a small step further and say how you will do it.

The problem with this from the client’s perspective is that anyone can tell them anything. If they don’t have trust already established in you, why would your claims be any more credible than those of the others who are pitching them? The best you’ll get from the client by telling is the benefit of the doubt. This is where showing over telling can provide a powerful advantage. If you show what you can do, you leave no room for doubt.

I’ll give the example of my recent client. Showing them what could be done was the biggest factor that contributed to me beating out the other freelancers pitching their services. I found this client on reddit. He is from New York. He had never met me or heard of me before I pitched him. After his single project posting, he was pitched by about 20 members of reddit, myself included.

He already had mock-ups of the pages he wanted built. He needed the mock-ups converted to an HTML template he could use for his live site. The first item I showed him was the result of a similar mock-up I had taken to HTML. This made it easy for him to see I could do the same for him.

The next bit was a little trickier. He wanted to know that I could implement a specific technology in his templates (jQuery Mobile, in case you’re wondering). I had no experience with this technology in particular, but I was confident I could do it because I have used many similar technologies. I asked him which elements of this, in particular, he was interested in, and he sent me a list.

For my final round of show-instead-of-tell, I decided to quickly build up a page and implement one of these elements just to prove to him I could do it. This took 5-10 minutes, but this set me apart from most of the other freelancers. I had been up-front with him in saying I had no experience with the tech, but, unlike others who may have been very experienced with it, he now had an example of an actual working implementation.

Here’s the exact screenshot example I sent over:

You have every right to be underwhelmed. It is practically nothing. It’s a jQuery Mobile header on a blank web page that took, as I mentioned before, about five minutes to implement. Despite all that, it’s still more concrete, more tangible than any big talk, claims, or promises I could have given. I show you here not to wow you with complexity but to wow you with the simplicity of how little it may take to show your client that you are the right person for their project.

If you think about this from the client’s perspective, a live working example of what you want to build is far more powerful even than claims of years of experience. Those years of experience may still have produced garbage in the end, but it’s hard to deny the value of a working example.

I can’t prove that this practically empty screenshot is what got me the job. All I can say is that, after seeing this mostly gray image, my client wrote back saying he wanted to get me under NDA for the project and asking for details about my contract. At that point, we were about two more messages away from a signed contract. It seemed that, by showing the client my skills, I was able to overcome many disadvantages I had. It only took a few minutes to instill the confidence needed to convert my prospective client into a real one.