Technical Dev Blog

A tale of tmux, a bell and the perpetuity of time

Fri, 31 Jan 2014 14:03:00 +0000

I've been using tmux for a while and love it. I had heard of tmux on various podcasts and through Twitter, but I was finally convinced to try it in early 2012 after listening to the tmux episode on the Changelog (excellent podcast by-the-way). tmux: Productive Mouse-Free Development, which was the topic of the podcast, is an excellent book for getting started with tmux. In the books short 88 pages it takes you from basics to advanced features to kick start your tmux development.

After some experimentation, I got into a good workflow with tmux. I particularly like using tmux with tmuxinator to set up projects and easily launch a full tmux environment with all my panes and windows running the applications I configured in the tmuxinator YAML file.

As much as I loved tmux, one thing really bugged me. If I had several tmux sessions open, which I was prone to do as I'd have several things on the go, the terminal bell kept going off. It would go off regardless of whether something was happening in that tmux session or not. I use iTerm and Growl, so bell events manifest themselves through Growl. This is actually surprisingly useful because when I have a long running task in a tab I'm not looking at, when the task completes and the shell becomes idle, I get a nice Growl alert. Unfortunately, this feature is not so useful when it happens all the time and nothing actually happens in the tab.

I searched around extensively trying to figure out the issue thinking it might be a tmux bug, or an iTerm bug. I came up with nothing, so I forgot about it and just ignored the Growl notifications. Then, all the sudden, one day I noticed that all the tabs ring their bell at the same time. Strange... what could it be? And then I looked at the corner of my tmux window and there was the answer.

The corner of the tmux window holds the tmux status bar. As it turns out, the default tmux configuration holds the date and time, in minutes. Every minute, each tab that's running tmux updates to display the current time. Time is ever perpetual, always marching forward, and always setting off bells in tmux sessions.

The solution was easy enough, change the default status bar to only show the day and month.

set -g status-right "#T %d %b"

Voila! Now my bells and Growl notifications are useful again.

Being Productive on OS X

Mon, 12 Sep 2011 00:00:00 +0000

I’ve been a Mac OS X user for about 3 years now, and a Linux user before that. I was originally attracted to the Mac not for the hardware (although it’s nice), but for the software. My first taste came from a home made Hackintosh, but I fell in love and wanted the real thing.

Recently, a coworker bought her first Mac (with perhaps a bit of evangelizing by me) and asked if I had any suggestions for good applications. I decided to compile the entire list of apps that I use on a more or less regular basis, and, admittedly, was shocked at the number.

But then again, I guess it comes as no surprise. All these little tools here and there are the reason why more and more developers are flocking to OS X. It’s evident in any conference or in any picture of a start up. Developers just seem to be more productive on a Mac.

After I finished compiling the list of applications, I thought it made sense to share the list with everyone. I hope that you will find something useful for yourself in the list. There’s a ton of applications out there that I didn’t list here, so share your favourites in the comments. Oh, and don’t forget to follow me on Twitter, @arthurkalm.

Developer Tools

This being a developer blog, I’ll start with developer specific apps and tools.

Programming

Eclipse – Java IDE. free/OSS
MacVim – native Vim UI for the Mac. free/OSS
TextWrangler – simple text editor. free
Github for Mac – Git and Github UI for the Mac. free
XCode – native Mac development, also needed for GCC (when installing brew, but you might get away with this: https://github.com/kennethreitz/osx-gcc-installer), Mac App Store. free
Sequel Pro – a SQL client for MySQL (others coming). free/OSS
snippet – code snippet manager. paid

Command Line

iTerm2 – terminal application that has more features than Terminal.app. free/OSS
brew – the missing package manager for OS X, use to install just about anything. free/OSS
oh-my-zsh – great default configuration for zsh, the best shell :). free/OSS
janus – spruce up your Vim with great default configurations. free/OSS
solarized – amazing color scheme for your terminal, vim, IDEs, etc. free/OSS
autojump – a cd command that learns. free/OSS

Design

Skitch – a free screenshot taking app, really kicks butt. free
Balsamiq Mockups – great tool for creating wireframes. paid
ColorSnapper – is the missing color picker for OS X. What I like is it picks colors in HEX, rgb, hsl, etc. paid
phone finger – giant finger for touch screen images. free

Everything Else

Aside from all the developer tools, I use a number of productivity tools that help through my workflow. I also do some amateur photography, so there are some applications for that. The rest are the rest of the apps I use.

Productivity

Growl – notification system, has plugins for tons of apps. free
Alfred – use it to quickly launch apps. free + pro
Launchy – Simplifies OS X’s launchctl tool for daemons on OS X. Great for starting and stopping services set up by Homebrew. free/OSS
Caffeine – keeps your monitor from sleeping or decreasing brightness. free
SizeUp – quickly resize and move windows around your desktop. paid
BetterTouchTool – custom touch gestures for your trackpad and magic mouse. free
Jumpcut – an awesome clipboard buffer, great for copying/pasting stuff. free/OSS
Evernote – note taking application, works across a whole bunch of platforms. free + pro

Chat

Adium – universal chat client, use for MSN, etc. free/OSS
Colloquy – IRC client. free/OSS

Configuration

Gmask – Editing host files in OS X, profiles and everything like that. free/OSS
App Zapper – removes extra cruft when deleting an application (uninstall). free + pro
BootChamp – lets you easily reboot into your Boot Camp Windows partition. free

Benchmarking

Xbench – standard benchmarking tool. free
rember – RAM benchmarking tool. free
AJA System Test – hard drive benchmarker. free

Other

Keynote – Apple’s presentation software, best out there, Mac App Store. paid
Twitter – the official twitter app, Mac App Store. freeThe Unarchiver – Unzip tool. free
Transmission – bit torrent client. free/OSS
ClamXav – anti-virus for OS X. I use it sparingly for downloaded file. free/OSS

Photo/Video

Lightroom – Adobe photo editor. paid
Picasa – Google’s photo organizer. free
Gimp – open source Photoshop competitor. free/OSS
Hugin – photo stitching for panoramas. free/OSS
Hydra – I’m starting to get into HDR photography, and this has been the best app I’ve found so far. paid
Audacity – sound recording application. free/OSS
Handbrake – video transcoder for ripping DVDs, etc. free/OSS
iSquint – convert videos for ipods, iphones, etc. free
Miro – aggregates music and video from the web. free/OSS
VLC – video player. free/OSS

Getting into Node

Wed, 27 Apr 2011 00:00:00 +0000

Updated 2011-04-27: forgot to add Backbone.js

Most of the net is abuzz about Node, so it’s hard to miss it. I’ve been sitting on the sidelines for several months now, but after attending a TechTalksTO talk on Node given by James Duncan of Joyent, I’m convinced I should dive in.

tl;dr version

Like C, Javascript is here to stay.
Asynchronous (everywhere) is the future.
Node is an exciting platform you have to check out.

What is Node?

Node is a server side Javascript implementation. As James put it, Node is the Google Chrome V8 Javascript engine and libev glued together. V8 provides the super fast Javascript virtual machine while libev contributes the event loop. Of course, it’s more complicated than that, but those are the basics.

To make full use of this fast underpinning, Node follows a non-blocking, fully asynchronous programming mode, and encourages libraries to follow its example.

Why Node and Not Another Server Side Javascript?

The best known server side Javascript implementation is Rhino. However, as Dhanji Prasanna asked on Twitter,

Are there any fast alternatives to Rhino on JVM?

Most of the server side Javascript implementations didn’t grasp the importance of non-blocking, asynchronous I/O.

Why Asynchronous?

Asynchronous programming is usually associated with GUI development where everything is event driven and asynchronous. Why would you bring this to the server? Well, for one, blocking sucks. James made this point very potent by showing the amount of CPU cycles spent accessing each layer in a computer. Starting from L1 cache, L2 cache, RAM, disk and finally the network, each layer adds many orders of magnitude to the amount of time the CPU sits blocked, waiting for the call to return.

That’s why you want non-blocking I/O. As the Mashable article (above) said about the history of Node, Ryan Dhal tried the Node approach on a number of languages, in all cases failing, because of the culture of synchronous, blocking programming. But Javascript, being a front end language, has always been event driven and asynchronous.

How Much Does This Buy You? (Easy C10K)

What does this approach really buy you? As James pointed out, it buys you easy C10K. What’s that you ask? 10 thousand concurrent connections. In fact, Node seems to be able to handle 100K concurrent connections on a single, mildly beefy server. In benchmarks, Node competes at the level of Nginx, a C based web framework built around the same principles. This is a testament to the power of V8.

Asynchronous programming has been around for a long time, but has started to gain popularity recently. The benefits are evident, take the recent search speed increase at Twitter after they adopted Netty and an asynchronous model.

Alright, I’m sold. Now what?

Getting started with Node is easy, if you’re on a Mac, I highly recommend installing it through Homebrew.

brew install node

Now try out Node’s obligatory “Hello, World!”. Create server.js,

var http = require('http');

http.createServer(function (req, res) {
  res.writeHead(200, {'Content-Type': 'text/plain'});
  res.end('Hello World\n');
}).listen(8080, "127.0.0.1");

console.log('Server running at http://127.0.0.1:8080/');

Then run

node server.js

And voilà! Your first node app.

Great… Anything Else?

Tons. One of Node’s biggest strengths is the huge community that’s sprouted around it. As RedMonk discussed in their recent Programming Language Framework Traction on Hacker News, “What’s interesting is that the much younger Node.js is beginning to approach Django both in growth rate and visibility.” This is evident by the number of new libraries and the speed at which they are being developed.

The best way to install plugins is to use npm. Some of the more popular plugins are,

express – a Sinatra inspired framework.
socket.io – server push support.
backbone.js – a popular MVC framework for Javascript, works with Node as well.
jsdom – web scraping 2.0, powered by Node.
node.io – another scraping library, this looks even better then jsdom.
Mustache – template engine, used by Twitter (the JS version).
Jade – another template engine, inspired by HAML.
stylus – a SCSS or LESS inspired CSS engine.
mongoose – MongoDB ORM layer.

A Look at Express

The Node ecosystem is growing by leaps and bounds, but I wanted to highlight one of the more popular libraries. Making web application development in Node easier, Express has become a trademark in most Node web apps. Let’s see how easy it is to use.

var app = express.createServer();

app.get('/', function(req, res){
    res.send('Hello World');
});

app.listen(8080);

Hosting

You’re all excited to get started on Node, but you’re wondering where to host your new Node application. There is a great stackoverflow question that has a lot of options. Another recent contender in hosting Node applications is VMware with Cloud Foundry. I’ve tried both Joyent’s http://no.de and Cloud Foundry.

Node is an exciting platform that’s experiencing explosive growth. If you’ve been sitting on the fence, now is a great time to jump in.

More Resources

Node Github project, web page and Ryan Dahl’s intro video.
How To Node – lots of great how-to articles
6 free ebooks on Node
InfoQ covers Node ecosystem
Javascript the Good Parts – a great resource for learning the intricacies of Javascript

Proposals for Google I/O 2012

Wed, 09 Feb 2011 00:00:00 +0000

I’ll preempt this post by saying I wasn’t able to register for Google I/O. Like many other people, I was caught up in the server crashes that happened the minute the tickets were announced. I have a feeling our corporate firewall had to do something with my inability to reach the website, and when I tried it on my Nexus One, I got the message that it was sold out (I’ve looked for that PK session token, but I didn’t get one because I wasn’t able to get far enough in the registration). I’ve been trying to go to Google I/O for 3 years now, and this year was the year I had everything in order for registration. I was very disappointed.

The Stampede

From @googleioRT @VicGundotra – Google I/O ‘09 sold out in 90 days, '10 in 50 days… #io2011: 59 minutes. Holy moly.

That’s a drastic change from the previous years. Even Apple’s WWDC sold out in 8 days last year. This might not come as a surprise, @googleio has 50K+ followers. At least 10% of those followers must be interested in coming to the conference. When the tweet went out that registration was open, the stampede of developers crushed the server. That might sounds strange, how can Google’s servers not handle the load? Turns out that Google used a third party service called WB Events Global for their registration. The service was built using Cold Fusion on top of an IIS server. Not surprisingly, the server instantly crashed under the load.

The Reasons

Like most things in life, I don’t think there is any one reason why Google I/O sold out so quickly.

Freebies help

In previous years Google has given out free phones during and before the conference. Like many people, I believe this is one of the main reasons behind many’s choice. If the conference is paid for by one’s employer, a free phone/tablet is even more attractive. However, if that’s the case, it’s kind of sad. Tech conferences are about learning and meeting people, not about parties and freebies.

Price is attractive

It’s true that for those not living in the Bay Area, the flight and hotel expenses usually outweigh the conference price. But at $450, Google I/O is a bargain. Most tech conferences are $1-1.5K.

Android rising

Finally, I’m starting to believe that Android’s exponential is a big draw. Many developers no doubt want to get a head start developing the next great Android app, or help their employer navigate the mobile world.

The Proposals

Have a separate Android event

I think it might make sense to have a separate Android event instead of rolling everything up into one giant conference. Maybe have one everything Android conference and one everything else conference (GWT, AppEngine, OpenSocial, etc). I guess depending on how full the Android sessions will be would drive this.

Rent all of Moscone

You could have Google I/O in all the Moscone buildings like JavaOne used to be. But I’ve read good reasons why a 15K developer conference just isn’t the same. Having large auditoriums for 300+ people doesn’t give you the intimacy you normally get from a conference.

Dealing with Freebies

To discourage those that register for the conference just to get a freebie, I love Justin’s idea of not giving out a freebie and letting everyone who wants a refund get one. Google I/O brings more then enough to the table, a free phone shouldn’t be your main deciding factor.

Why is my LayoutPanel invisible?!

Fri, 21 Jan 2011 00:00:00 +0000

This is just a quick post in the hope that I can help others avoid hours debugging an “issue” I recently had. I was working through a new application that I’m building using the new MVP framework in GWT 2.1, and for the life in me couldn’t understand why the LayoutPanel I was adding to the page was not invisible. The code could be as simple as this.

I could clearly see it was added to the DOM when I poked around with Web Inspector, but it just wasn’t visible. I made sure my HTML doctype was set to standards mode. Dumbfounded, I went to the GWT documentation on Panels, and sure enough, found the RootLayoutPanel. *LayoutPanels need to be added to the RootLayoutPanel, not the RootPanel.

Works perfectly.

I found this hidden/invisible issue comes up with most *LayoutPanel panels added to RootPanel. The same effect is experienced when you stick these panels into an HTMLPanel, as is customary when writing UiBinder code.

Of course, the previously mentioned GWT documentation clearly states at the end.

When should I not use layout panels?

The panels described above are best used for defining your application’s outer structure — that is, the parts that are the least “document-like”. You should continue to use basic widgets and HTML structure for those parts for which the HTML/CSS layout algorithm works well. In particular, consider using UiBinder templates to directly use HTML wherever that makes sense.

The documentation points out the misuse of *LayoutPanel. However, I was thinking a good usability feature would be to display a warning that the *LayoutPanel is being abused. This warning should probably be in Development Mode. If you’d like to see something along those lines, please star the issue I created

GWT Data Bindings Part 1 - First Look

Mon, 08 Nov 2010 00:00:00 +0000

With the release of GWT 2.1, I’m going to try to put together a blog post about each of the new features. We’ll start off with my favourite addition, the data binding framework. If you are interested in GWT 2.1 coverage, make sure to check out Thomas Broyer’s blog, which covers Places extensively and Activities with nesting. Last, but certainly not least, the excellent GWT documentation has been updated to include 2.1 features.

One of the killer features in GWT 2.1 is data bindings. The GWT blog put it best.

Data bound views – An app that doesn’t allow end users to view or edit data isn’t terribly useful, now, is it? With GWT 2.1’s Data Editors, developers can create views that are generated from their app’s data model. These views are completely customizable, and handle all of the nasty work of syncing change sets between the client and server.

While data bindings are not new by any means, you usually find them in more traditional web frameworks like Seam, Spring Web Flow, etc. Now, this powerful paradigm has found it’s way into the best (IMHO) RIA framework.

Single Binding

Let’s cover the simplest case, data binding a single Java bean. For example, a simple Email POJO.

The Serializable implementation is only required for GWT-RPC calls, not the Editors framework. Also note that these objects do need getters and setters, you can’t modify immutable objects. Immutable objects can only be used for display.

Now you need a GWT widget to represent the Email object.

EmailEditor is a standard GWT widget, the only new piece is the Editor<Email> bit. This is the cue telling GWT that it is indeed a data bindable widget. If the field in the widget is named the same as the corresponding POJO field, the binding is automagic. Otherwise, you can use the @Path("") annotation to indicate the name of the field (or reach into nested values).

The final piece in the data binding story is the interface that will be GWT generated with the GWT.create() call. This does the required code generation to do automatic data binding.

This code could either go in some new class, or could be stuffed into the Presenter component if you follow the MVP pattern. Regardless, that’s all you need to bind to a single object.

Of course, in most cases, you have an entire object graph, so lets move on to binding a whole object graph.

Nested Binding

It turns out that data binding an object graph is as easy as binding to a single object. Take the Customer object.

Again, a regular POJO like we’ve seen before, but this time it has an nested Email and Address. Let’s take a look at what the Editor looks like.

As you would expect, editing the nested objects only requires including the editors for those nested objects. Finally, instead of having a Driver for each Editor, you create one Driver for the top-level Editor. In this case we define the driver in the entry point.

That’s about it. All your existing boilerplate that does data binding evaporates with some GWT generator magic.

We’re done for now. Part 2 will dive deeper into Editors and explain using interfaces, integration with GIN and using Editors with the new MVP framework.

More Information

Some additional documentation to check out for now.

Mocking your GWT widgets, without GWTTestCase

Tue, 19 Oct 2010 00:00:00 +0000

When unit testing, mocking out your dependencies is standard practice. GWT is no exception. However, as you will discover, mocking your UI in GWT doesn’t work as you might expect.

Before we start with a sample, I just wanted to mention some best practices around GWT. It’s generally considered a best practice to use the Model-View-Presenter pattern (Part I, Part II, GWT 2.1 method). When you use this pattern, you avoid writing tests for your Views because they don’t contain any logic.

However, if you’re not following this pattern for whatever reason (existing code base, legacy, etc), you’ll want to unit test your UI logic. Furthermore, if you read the GWT 2.1 way of implementing MVP using Activities, you’ll find that some logic, like event handling, may creep into your Views for convenience sake. Therefore, I hope you find this useful in general.

Let’s build a simple example view.

With the class in place, we’d like to unit test the validUsernameAndPassword method. Using my favourite unit testing framework TestNG and mocking framework Mockito, we’d come up with something like the following.

Seems simple enough. But if you try to run this test, you’ll be greeted with the following error.

java.lang.ExceptionInInitializerError
    at sun.reflect.GeneratedSerializationConstructorAccessor1.newInstance(Unknown Source)
    at java.lang.reflect.Constructor.newInstance(Constructor.java:513)

...

Caused by: java.lang.UnsupportedOperationException: ERROR: GWT.create() is only usable in client code!  It cannot be called, for example, from server code.  If you are running a unit test, check that your test case extends GWTTestCase and that GWT.create() is not called from within an initializer or constructor.
    at com.google.gwt.core.client.GWT.create(GWT.java:92)
    at com.google.gwt.user.client.ui.UIObject.(UIObject.java:179)
    ... 42 more

What this is telling you is that you have to run these tests in a GWTTestCase, not a standard TestNG test. If you’ve had experience with GWTTestCase, you know it’s very slow to initialize and not something you want to use for unit tests. To get around this, we have to use a secret class that’s not even documented in the Java doc, GWTMockUtilities. The test class now looks like this.

Viola! Your tests pass as you expect them to. Hope that helps anyone doing UI unit testing in GWT.

GWT: Defacto for Creating Rich Web Applications?

Mon, 27 Sep 2010 00:00:00 +0000

Last year there was some fervent discussion on the GWT contributor mailing list on supporting Scala as a language alternative for writing GWT applications. The discussion was interesting, but I hadn't heard anything since and had assumed nothing happened. Turns out, I was wrong. While I can't claim to know much about Scala, the idea of writing GWT based applications in another language sounded really interesting. Reading on, I found an even more exciting idea, in Jribble. As put on the GWT Scala site.

Java source code does not want to be a target language. It has restrictions against logically sound constructs that would be bad Java practice to write by hand. Lex Spoon proposed a plan for an intermediate step, "Loose Java," which we have christened Jribble (pronounced "Dribble").

Jribble is essentially Java with the interfering restrictions removed. Lex: "It's like a puddle of Java. It's also like drivel, which is appropriate enough for a language no one writes and no one reads. Computers can entertain themselves with it well enough."

And what it could eventually lead to.

The Jribble concept is interesting as a target language, because it's likely to be an effective target for other JVM languages, not only Scala. Any language that easily produces valid JVM bytecodes, but struggles to produce valid Java, might take advantage of Jribble as a bridge to GWT Javascript compilation.

Other JVM languages? Groovy, JRuby, Clojure anyone?

GWT is becoming the platform of choice for Java developers*. More so with the Instantiation purchase and collaboration with VMware/SpringSource. But the future could be even brighter. GWT could be the default compiler for writing rich web applications in any language of your choice. I'll be very excited to see how this evolves.

* I'm just guessing here based on the 23000+ mailing list subscriptions and 2000+ tags on Stackoverflow (when compared with other frameworks).

Obligatory Introduction

Thu, 17 Jun 2010 00:00:00 +0000

On Java

As the name suggests, I’m mainly a Java developer. I like Java. I know, it’s falling out of fashion with today’s web hipsters, but there’s a lot to like about the language and its environment. For one, I find the static typing bit to be very helpful in a larger team environment, especially when you’re trying to piece together how someone else’s application works. But I think Java really wins out in the ecosystem. The sheer amount of active, high quality, tools and libraries available, is often overwhelming. One could argue that this can be a disadvantage, but I believe that the more choice a developer has, the better.

On the Web

I’m also passionate about everything happening on the web. I believe that web vs desktop is analogous to Steve Job’s truck vs sedan analogy. You’ll always need desktop applications (trucks), but for the majority of users, the web (already?) provides everything they need (sedans). But when it comes to developing rich web applications, I think the best tool out there is Google Web Toolkit. More on that later.

On Google

As mentioned, I love GWT. After my initial taste of GWT, I wanted more of that excellent Google stuff. So I found Guice, Google App Engine, Page Speed, Speed Tracer, Sitebricks, the plethora of Google APIs and much more. While I always liked Google services in general, I had no idea (until a few years ago), how awesome they are to developers.

On not just Java

The JVM might be great at running Java, but many new languages have started calling the JVM home. Aside from existing languages like JRuby, Clojure (Lisp), Jython, and others, cool new languages like Groovy and Scala have found their way to the JVM. More on those as I get to them.

On what’s the point already?

Ah, the point… right. The point is, I’m really into the tech world. I love programming. I love gadgets. So what you’ll find on this blog is a lot about the web, Google Web Toolkit and other Google technologies, Spring and Hibernate, new languages that I explore, perhaps some gadget reviews and who knows what else. It’s definitely an exciting time to be on the JVM. Stay tuned!