Ergodox is a split ergonomic keyboard that you have to build yourself. Anyone can look into how an Ergodox can be built through their website. I used to think that I could never build one for myself because I don’t have formal training in electronics, I don’t know how to solder, and since I live in the Philippines, it would be quite challenging for me to acquire the tools and materials that I need to build one. That mentality went on for quite some time until I was introduced to Massdrop. I took the plunge and bought a kit.

For the rest of this article, I will detail how I acquired the materials and tools that one will need to build an Ergodox. Also, all details will focus on how to obtain stuff in my home country, the Philippines. For the succeeding articles of this series, I will write about why you shouldn’t be afraid to build your own Ergodox, how to build one even without soldering skills, and how to configure it to suit your needs. Stay tuned!

Getting a kit

The Ergodox website has a detailed list of the parts you need to build an Ergodox. However, it would cost you more if you buy each part selectively, especially since not all parts can be bought in one store. Which means, more shipping costs for you. Massdrop is a place where you can do group buys of different items. The advantage of doing so is reduced cost. This is because large quantities of items bought directly from the manufacturer usually receive discounts. Aside from that, you get a full Ergodox kit in one shot, which means reduced shipping costs.

Paying for your kit

You can pay using the usual methods: PayPal, or credit card. If you don’t have both, don’t be disheartened. You can also use Bitcon to pay for your Massdrop purchases. coins.ph is a good place to buy Bitcoins in the Philippines, along with buybitcoin.ph and coinxchange.ph.

DISCLAIMER: I work at coins.ph ;)

Shipping your kit

Massdrop ships internationally for $24.99. You can either use the Massdrop option, or you can have your item shipped through Johnny Air. I prefer having my items shipped through Johnny Air using their New York address. As of time of writing, I already had ~6 shipments through Johnny Air, and I never had a problem with their service.

Getting the tools you need

Massdrop has a great guide on how to build an Ergodox, with pictures of the tools you need. Another great resource for general soldering advice is this video series from Dave Jones of EEVBlog. I highly recommend watching that series before jumping in to your first soldering project.

If you’re like me, you don’t have any of the tools shown in Dave Jones’ video. What follows are tips on how to acquire these tools in the Philippines.

Soldering lead, tweezers, etc.

You need a roll of soldering lead with a diameter of 0.4mm. Anything larger than that will make it harder for you to solder the tiny smd components. It’s ok to use 1mm for soldering the switches, but you don’t have to get two separate rolls of soldering lead. Just get 0.4mm and you can use that for every component that you have to solder. I used a rosin-cored 63/37 variant, but a common 60/40 will also do the job. Don’t get a lead-free soldering wire since they sometimes have corrosive properties.

It’s important to use tweezers that are both stainless-steel and anti-static because most of the components you’ll be working on are sensitive to ESD. A pair of straight-point tweezers will do the job, but for some situations, you might want to use a curved sharp-point jeweler’s tweezers instead. Actually, it’s a matter of preference. I used the curved tweezers most of the time. They’re pretty cheap so I suggest you get both.

You’ll also be using a wire cutter for the most part. Get a flush cutter, the one with a beveled side and a flat side. Cut the wires with the flat side down. Because even the pros commit mistakes, buy a reasonable length of desoldering wick. Around 2m are more than enough. Get this along with a desoldering pump. In the next articles of this series, I will write about how these two tools helped save my Ergodox. A lamp might also be useful, especially when soldering smaller components.

Soldering iron

I don’t have prior experience to soldering and I’m afraid that I might burn some of the components using the usual soldering iron that plugs directly to a wall socket. They are cheap and you might be tempted to get those instead of the temperature controlled variants, but I suggest you do get a quality soldering iron. It’s more expensive to have burnt components, buy replacements, and ship them back to the Philippines.

I highly recommend the Hakko FX888D. This one is from Amazon and it comes with a wire cutter. It comes with a 1.6mm chisel tip, but it’s still a good idea to buy an extra tip. You can pay for this using the usual methods, and you can have it shipped internationally or through Johnny Air. If you have a friend from the US who will be visiting the Philippines soon, you can also have this shipped through them :p

You can also get a Hakko imitation from e-gizmo. They are out of stock when I was about to buy though, which is why I opted for the real deal. Hakko imitations are also pretty good as far as I’ve heard, but I haven’t tried them personally so I won’t recommend them. YMMV.

Power tool

ETA and parting words

Getting a kit from Massdrop takes the most amount of time, usually because of keyswitch availability. A non-common keyswitch usually takes a longer amount of time to be delivered. I bought my kit around November 2013 and it arrived in the Philippines around February 2014. The long waiting time in my case seems to be affected by the Christmas rush. A mistake I made is waiting for the kit to arrive before gathering the tools that I need. I suggest you buy the other tools while waiting for your kit to arrive, esp. if these tools have to be shipped internationally. Actually, the same is true for tools that are available locally because sometimes stores run out of stock. Better get a reservation, or even better, borrow from a friend who already has these tools. Another good use for your time is to watch videos on how to build the Ergodox. I got everything I need around April, but I had to wait for another two weeks and I was able to finish the keyboard around May because I damaged the teensy with ESD, which will be the topic of the next part of this series.I’ll write about my experience on soldering the keyboard, pitfalls, and how to avoid them. Stay tuned for the next article!

I recently tried to update all of my npm installed packages by running npm -g update and I got this error:

1

Error: Refusing to delete: /usr/local/bin/npm

Wat. This error shows up when npm tries to update itself.

After a moment of googling for answers, I found this github issue. Yep, I have installed node via brew, and it comes with npm. As it turns out, there’s a problem with npm when it is installed via brew. The official fix is to uninstall the homebrew installed node, download node from the official website, and install that instead. But I love homebrew, so I scrolled down the issue and found an acceptable workaround:

1
2

$ npm update -gf
$ brew unlink node && brew link --overwrite node

Adding -f to npm -g update makes it a forced update. With that flag, npm will no longer refuse to delete /usr/local/bin/npm. Well, at least that’s how I understand it. Be careful though, as it’s not a safe thing to do. But I like to live dangerously, so yeah. In case you want to play safe, don’t add the -f flag on npm -g update. Instead, only forcefully update those packages that won’t update without the -f flag. In my case, that’s npm.

The second line is to fix the broken homebrew links. And voila! I now have shiny new things in my global node_modules, without resorting to removing the homebrew installed node.

Firebase is an awesome backend API that allows developers to build apps without managing servers. Among the killer features of Firebase is its push ala socket.io, but really, there is more than that. So far, these are some Firebase features that I have personally used:

• Push data from an Angular.js client
• Store data in a Firebase data structure
• Receive data on an Android app

Yep, data was sent from an Angular.js client to an Android app because Firebase supports multiple client platforms. As far as I know, they have client libraries for:

• Angular.js
• Android
• Java
• Objective C
• Javascript

How to Get Started

A Development Firebase is free. You can get started right away by signing up, and then creating a Firebase backend.

How to Use

As much as I’d like to simply point you to their developer documentation, I think I’m still obliged to write a simple code example because c’mon, a tech blog without code samples? But really, the Firebase team did a great job in their docs.

Here’s how you push data from a JS client:

Simple wasn’t it? And here’s how you receive data on an Android client:

While the usage itself is simple, there are some caveats to keep in mind. In Android, DataSnapshot::getValue() will either return an ArrayList or a Map, depending on the kind of data that was stored in Firebase. If it is a collection, it will be an ArrayList of Maps, otherwise, it will simply be a Map. In addition to this, you can’t use generic types for those collections because Firebase doesn’t restrict the data types that it can store.

Yep, it’s that few lines of code.

What is it good for?

In Android/iOS, you can totally eliminate the “Pull to Refresh” UI pattern commonly being used in mobile devices. With Firebase, there’s no need for this since the data will get pushed to the device as it becomes available. In my experience at least, a Firebase listener is far easier to implement than pull to refresh. In theory, you can also replace GCM/APNS with Firebase, as long as you put your listener in a long running service. Well, in Android at least. I don’t know about iOS since I don’t have experience developing native apps in that platform.

Since Firebase is a full backend, you can get away with not implementing your own backend as long as you’ll only be sending/retrieving objects. If you need to manipulate the data server-side, then you’ll have to supplement Firebase with your own backend. This makes Firebase an ideal choice for hackathons, and for quickly prototyping frontend stuff.

When not to use it?

If you have a rather large app and you’re on a budget, or if you want to do a lot of data manipulation/computation on your backend which might require advanced database features like triggers. Aside from that, I can’t think of anything else because I haven’t explored enough of Firebase to know its quirks.

Overall

Firebase is awesome. It’s now my default choice for “Pull to Refresh” (not really, because push) UI patterns, and for hackathons. I haven’t tested my GCM theory, but I’m also keen on replacing GCM with Firebase. I’ll do experiment on that as time allows. Overall, Firebase is a worthy tool in my toolbox.

This month, I helped Philippine Tech Hackers organize a hacker meetup in Makati City. Me and my co-organizer had decided to make it a keyboard party, so that we could go around and talk to our fellow group members while doing something geeky at the same time. Thanks to our friends at Aestrea for welcoming us to their office. You guys are awesome!

We started the night with some beer and pizza. Since it’s my first time to meet most of the members, the beer helped me talk in front of them :)

Some brought their favorite mechanical keyboards with them, which in turn brought joy to those who were curious about the feel of other mechanical keyboards.

A lot of the members were actively participating in the discussion. Aside from mechanical keyboards, we also talked about alternative keyboard layouts (ie. dvorak), typing tricks, and development tools.

Unfortunately, some members weren’t able to attend because of the bad weather. In our area, bad weather == bad traffic. Yep. I’m sorry for that. Hopefully we’ll have better weather next time. See you around!

I’ve been doing Android development for three years now, and I’ve only used Robotium and JUnit for testing my apps. Recently, a friend of mine introduced me to Calabash, an acceptance testing framework for mobile apps. Calabash is based from Cucumber, a ruby BDD framework.

I’ve played around with Ruby before, but I haven’t really used it for a real project because I’m primarily a Java and Python guy. This weekend, I decided to try Calabash to get some Ruby chops. I rolled up my sleeves and read about the differences of ruby from python. I nodded along the way, but I needed something more to help me understand ruby. This talk did the job. Now onto Calabash!

I have some BDD experience with AngularJS, but Cucumber’s way of doing things looks like magic to me. How is it possible to describe tests in a human readable language? Calabash docs assume familiarity with Cucumber, so I started with that first. Thankfully, Cucumber has a nice documentation about the Gherkin syntax, the language being used to define Cucumber tests, or features in Cucumber speak. An example of a feature looks like this:

1
2
3
4
5
6
7

Feature: Ads                              # This is the name of the feature.

  Scenario: As a user I can click on ads  # And this is the scenario we want to test
    Given that I am at the some screen    # A precondition step. Cucumber starts test execution from here
    And I can see an ad at the screen     # Another step which is a continuation of the previous step
    When I press the ad                   # A step which performs the first user interaction
    Then I should be taken to the browser # Verification step. I think about this as Robotium's assert()

A feature file is parsed by Cucumber, which in turn executes each steps. The final step asserts whether the test passes or fails. At this point, it still looks like magic to me, until I learned that I have to define each step from the feature file in a separate Ruby file. While Calabash has a good set of canned steps, you’ll soon find that you’ll have to define some of the steps on your own if you decide to do anything serious with it. I’m not yet good at Ruby, and I don’t have someone with me to help me out. Luckily, there’s the Calabash shell which allows me to try out the Ruby API interactively.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

$ calabash-android console path/to/your/android.apk

irb(main):001:0> start_test_server_in_background
irb(main):002:0> query("webview")
[
    [0] {
        "contentDescription" => nil,
               "description" => "android.webkit.WebView{a7240998 VFEDHVCL ......ID 0,1012-1080,1822 #7f050010 app:id/wv_ads}",
                        "id" => "wv_ads",
                     "class" => "android.webkit.WebView",
                   "enabled" => true,
                      "rect" => {
               "width" => 1080,
            "center_x" => 540.0,
            "center_y" => 1492.0,
              "height" => 810,
                   "x" => 0,
                   "y" => 1087
        }
    }
]

Now, let’s get back to defining the steps for our feature. As an example, let’s define the step “an ad is at the bottom of the screen”:

1
2
3
4
5
6
7

# This tells Calabash to wait for 5 seconds before asserting that an ad exists
Given(/^an ad is at the bottom of the screen$/) do
  ads_container = "webview css:'#ads_container'"
  fail_msg = "No WebView for ads"

  wait_for_elements_exist([ads_container], :timeout => 5) or fail(msg=fail_msg)
end

After fleshing out the rest of the steps, execute calabash-android run path/to/your/android.apk and watch the magic begin!

As a newcomer to Ruby, Cucumber, and Calabash, I’m quite surprised at how easy it is to get started at using the whole suite. Granted, there’s a lot of reading involved, but overall it was a smooth process. It took me less than a day to get stuff running. Another thing that I like about Calabash is its interactive nature. Since it is written in Ruby, I can test the steps I’m planning to write in irb prior to fleshing it out and see immediate results. Compare this to Robotium, where you’ll have to recompile each time you make a change to your tests. Generally, I’m a fan of interpreted languages because of the smoother workflow compared to, say, Java. As an Android developer, Calabash is my gateway drug to the Ruby world.

Most of the time, people switch to a different keyboard layout for the reportedly better ergonomics. Two years ago, I switched to Dvorak not because of ergonomics, but because I want to improve my typing speed. At that time, I can type up to around 70 wpm in Qwerty, and I can’t get any further. Because Dvorak’s design is more efficient (relative to English), I concluded that I can type faster once I get comfortable with the layout. Indeed, after a month of use, my typing speed increased from 70 to 80 wpm. After a year, my typing speed went up to 100 wpm.

While Dvorak helped me increase my typing speed, strangely enough it had an adverse effect on me in terms of ergonomics. Instead of a more comfortable typing experience, I experienced pain in my right hand instead, which becomes apparent after prolonged periods of typing. This is probably because I’m a lefty, and my right hand is not used to doing much work. Most probably, my right hand just needs time to train.

However, at that time, I was handling my team’s servers at work. Actually, the rest of the team is expected to have at least an acceptable skill in systems administration so that each of us can jump-in in case of emergencies. Guess what, all of us share the root account :) Because of this use case, it’s not practical for me to set the default keyboard layout to Dvorak, esp. since changing keyboard layouts in the command line is non-trivial. The rest of the team will hate me for doing so. Eventually, this made me switch back to Qwerty.

I haven’t really had the chance to see whether the pain in my right hand will go away after spending some more time in Dvorak, but what I’ve learned from the experience are:

• Dvorak is designed for right handed persons (so is the keyboard in general).
• Environmental factors will limit the advantages of using alternative keyboard layouts.
• Most program hotkeys are designed with Qwerty in mind, and are noticeably more comfortable to use in Qwerty.
• Dvorak may increase your typing speed.

Overall, my experience in using Dvorak is definitely worth it. I’ve been using Qwerty for more than a year now, and my typing speed caught up with my Dvorak typing speed. Right now though, I have no desire in switching back to Dvorak because I’m not willing to spend time retraining my muscle memory esp. for the keyboard shortcuts I usually use.

From what I’ve noticed so far, it seems that almost every popular Linux DE is imitating OSX in some ways. For instance, Ubuntu’s move to unity borrows OSX’s one instance per app, which pained a lot of users because it will affect their workflow. Gnome 3 borrows the same model too. A lot of linux desktop users voiced out their complaints, and honestly, I share the same sentiment. Ubuntu’s classic Gnome 2 is the simplest, most user friendly, and beautiful DE I’ve used in Linux. I can even combine Gnome 2 and XMonad to get the best of both worlds. Here’s my rather dated XMonad config for those who are interested.

Impetus

I’m a happy Linux user, but the major changes in the leading desktop environments made me curious about OSX. Aside from that, some of my coworkers and friends swear by it. Like Linux, OSX is a unix-like operating system, which means I can replicate my emacs and terminal workflows in an OSX environment. Other things I’m looking for, in no particular order, are:

• Remappable keys. Either through a GUI or through an xmodmap-like config is fine.
• An easy way to arrange and adjust windows, if not a tiling window manager.
• A package manager.
• A nice community.
• Easy way to launch apps. Something like Kupfer

The Machine

I got myself a 2011 Macbook Air 13”. It’s awesome. Best piece of hardware I’ve owned so far. I’ll stop there before I’m accused of being an Apple fanboy :)

Configuration Über Alles

OSX just works, but I like to tinker. I’m willing and prefer to spend some of my time to adapt an environment to my style rather than me adapting to an environment. Thankfully, OSX is configurable enough even if it’s not an open source system. The first thing I did is to…

Swap Caps Lock and Control

Which is pretty much mandatory for emacs, or even vim users. And then I…

Swapped ⌘ and ⌥

Because I’m a Linux refugee and emacs user, I make heavy use of the Meta key. ⌥ is Meta in OSX and ⌘ is Super. In my case, it makes sense to swap these two. Besides, in Linux, I’m used to using the Super key for WM operations. OSX already has some emacs CTRL keybindings, but it doesn’t have the Meta keybindings by default. Swapping ⌘ and ⌥ allows me to define the Meta keybindings without rebinding a lot default ⌘ mappings. Now that I’ve adapted OSX to my muscle memory, it’s time to move on to…

Homebrew

The missing package manager for OSX indeed. With this, we can now get…

Emacs

Via brew install emacs --cocoa. And then I want to launch it with…

Quicksilver

Kupfer is actually based from Quicksilver. Most OSX users prefer Alfred nowadays, but I still prefer open source alternatives over paid software. Unlike the reports I’ve seen about Quicksilver, I actually find it fast and stable. Aside from using the catalog for launching apps, I have defined the following triggers for fast app switching:

• ⌥ + SPACE to activate Quicksilver
• ⌥ + E to launch Emacs
• ⌥ + R to launch Chrome
• ⌥ + T to launch Terminal

And then that’s it

Configuring OSX to match the workflow I’m used to is ezmode compared to doing it in Linux. So far, the only thing that’s lacking from my previous setup is a way to tile windows. Unlike Linux, I can’t replace the OSX WM with a tiling one, but I guess there’s an app that can do the same. Right now though, I’m happy with Quicksilver triggers.

So far, these are the things I like about OSX:

• It looks nice.
• Ezmode compared to Linux.
• *nix like.
• Friendly user community.
• I can port my old dotfiles easily because of point three.

Overall, the transition is a pretty easy one. Actually, I find it easier to switch from Linux to OSX than to switch from Slackware to Gentoo to Fedora to Ubuntu. But that’s probably because I’ve done enough playing around with various Linux distros to know my way around another *nix.

Tiling window managers just make sense for a keyboard oriented workflow. Switching between apps becomes faster, and arranging windows are easier.

Recently though, I’ve explored Eclipse to try out the new functionalities of the ADT plugin. I use the Emacs+ plugin, but you really can’t get away with Eclipse’s mouse oriented workflow. Some functionalities like switching perspectives have keyboard shortcuts which makes transitioning from text editing to viewing DDMS output a lot smoother, but navigating through most of the panes and tabs are painful without using the mouse. For instance, Eclipse will spawn floating window dialogs for some events, and a mouse is more efficient for these kinds of things. My WM of choice doesn’t have the standard window gui controls for closing a window, which makes closing floating windows a pain. I’ll have to do one mouse roundtrip to move the focus to the window I’d like to close, and then back to the keyboard to do the actual kill-window command. Because of this, I have decided to give Gnome 3 a try. The first thing I did is to rebind the workspace and window control commands to something like what I’m used to.

This led me to the realization that I’m not really using the tiling feature of tiling WMs to their full potential. Most of the time, I configure the tiling WM to put certain apps to their own workspace because I prefer to jump to a particular workspace number rather than navigating a stack of unrelated window tiles. In fact, ever since I used emacs, I rarely even tile windows because emacs itself can do split buffers, and most of the apps that I use are inside emacs. The good thing is, emacs doesn’t force me to use the mouse.

For a couple of years now, I’ve tried to maintain a keyboard oriented workflow. Firefox, another app that I heavily use, usually breaks this workflow until I have discovered the Vimperator plugin. Eclipse seems to break this workflow more often though. It’s not like I regularly use Eclipse, but I’m considering the fact that some app might take away take away the fun out of my tiling WM. Oh well, C’est la vie.

Are ten fingers really enough to become a productive coder? I don’t think so. Are there ways to compensate for our lack of fingers? Lots! TAB key, at yer service!

As programmers, we generally like to lessen the amount of typing that we do. This is why most text environments offer TAB completion. You can use TAB completion in your shell, your text editor, or your IDE. While I don’t use the TAB character for my code, I do use the TAB key alot for completion. This makes the TAB key is my next favorite key after CTRL.

At first, I was daunted by the number of Icicles stuff that I have to put on my .emacs. This helped me decide to opt for Ido for my buffer/file completion tool instead. As my usage of emacs grew heavier and heavier, I opted for WinRing as my emacs “window manager”. This led me to the discovery that Ido does not support (or perhaps I just don't know how to do it) completion when switching between window configurations. This discovery helped me gain the courage to try out Icicles.

Icicles is well documented in the emacs wiki. Even though I haven’t personally interacted with its developers, they do seem to be a smart and friendly bunch who do care about their users. Take a peek at Icicles’ newbie friendly introduction and see for yourself.

Icicles supports all kinds of minibuffer completion. It can even complete commands and file/directory names in shell mode! For instance you have a file called foo_foo_bar_foo_foo.baz in your pwd and you want to perform some operation on it. You can type, for instance, mv bar[SHIFT+TAB] and it will expand to foo_foo_bar_foo_foo.baz if the string bar is unique within your current directory. If not, you will then be presented with a list of possible completions. You can cycle through this list, or type some more to narrow the list of possible completions. In Icicles terminology this kind of completion is called apropos completion. If you know regex, apropos is something like “.?string.“. If you know SQL, apropos is something like LIKE %string%. You get the idea.

As a previous Ido user, I came to like fuzzy completion a lot. Icicles provides this through scatter completion. You can change the mode of completion by pressing M-(. Yes, Icicles supports multiple modes of completion, but the two modes previously mentioned are usually enough for me.

Of course, Icicles is not yet the perfect (well, almost) minibuffer completion mechanism for emacs. I do use shell mode a lot and I have several shell scripts which contains several function definitions. In a regular terminal, I can just type some part of the source function name and then press TAB to complete. Icicles’ list of possible completions doesn’t know about functions from a sourced script. Perhaps I just don’t know how to configure Icicles to include sourced functions, or perhaps I should take a closer look at bash completions. One easy way to get around this is to open the script in an emacs buffer. This way, I can use the omnipresent M-/ hippie-expand for completion, which is another addicting emacs feature.

It’s been a month of using emacs, and I’m enjoying it so far. However, I’m still using the vim + eclim combo at work. The day I use emacs at work is coming near though. So far, I have several observations that I would like to share.

Vim got me real close to my shell. The shell is my IDE of sorts, and GNU screen is an integral part of this IDE. Familiarization with common unix tools is mandatory. Most of the time, I cook up small scripts to automate tedious tasks that vim does not do for me. For example, I have scripts that build and deploy my project, invoke rest calls and generate logs of which calls passed/failed, clunky refactoring through sed, etc.

Emacs is the other way around. I run a shell inside of it, instead of running it in a shell. This allows me to leverage emacs keybindings to execute commands in the shell and copy output from it, which is my favorite feature so far. I can also do that in a vim + screen setup via “copy mode”, but it involves GNU screen keybindings which are very much unlike vim keybindings. For example, you can’t do y/foo in screen’s copy mode (EDIT: In tmux you can). In emacs, since the shell is just a buffer, you can do something like C-<space> C-s foo <RET> M-w to copy something off the shell.