Monday, August 29, 2011

The Linux Programming Interface: a beautifully written technical book

I have been reading, "The Linux Programming Interface" recently. It covers everything about the Linux programming environment: the layout of process space in memory, threads, signals, sockets. Nearly everything you can think of while programming Linux is covered here. Go get it. Now.

It is a beautifully written book. The author, Michael Kerrisk, combines technical knowledge about Linux internals with a clear, precise writing style. This book is fun to read. I have used Linux for many years now, and I found the chapters both illuminating and delightful. At first, I picked it up to learn about memory layout in Linux. I found the writing style so good that I read on, finishing not just that chapter, but many others. I have been reading a chapter at a time at random since. Each chapter deals with a single topic (e.g. Threads) and consists of roughly 25 pages. This is an excellent organisation: it lets you completely understand one area at a time in manageable chunks. Its 64 chapters are spread across 1500 pages, giving it unprecedented breadth and depth.

Technical books are difficult to write. The subject matter can be dry and the terminology makes sentences verbose and difficult to parse. In addition, there is a problem of target audience. You can assume the reader knows too much, making the book inaccessible. Or you could assume too little, and require the reader to go through trivial material that they already know. In addition, technical books are often read with a purpose in mind. They need to answer the question, "How do I do X in Linux" in minimum time. Remarkably, this book does well along all these dimensions. It is a case study in pleasant, lucid writing.

If you do anything with Linux, and have ever programmed in Linux, get a copy now. Keep it on your shelf, and leaf through it when you are bored. You will enjoy the book, and learn more about Linux while doing so.

Sunday, August 28, 2011

Be more productive at work

I have learned a few things about enhancing my productivity over the past few years, by observing my own productivity at work. These rules should work for anyone whose work requires concentration, creativity and thought.

Here goes:
  1. Get a quiet room. If your job requires thinking of any kind, it needs to happen in a quiet place. In case you cannot get a quiet room, invest in a pair of good earplugs. I recommend the Howard Leight Laser Light earplugs. At $20 for 200 pairs, it is a steal. If you do get a box, hand them out to your co-workers to improve the entire team's productivity. Even if you think that a noisy room works for you, try out a pair of earplugs first. Chances are that you, like most of humanity, will prefer a quiet room. If you work in an enclosed office: you are lucky! Consider submitting my resume to your recruiters.
  2. No distractions. This is essential to keep you in flow. What works for me is to wear my earplugs and display a sheet of paper that says, "Do not disturb". Yes, you look like a douche-bag and you feel anti-social, but the feeling quickly passes. Additionally, you can indicate that if people drop you an email, you will go by their desk when they are free. This reduces the chances of people mistaking you for a self-important jerk. Apologise in advance, and mention what you are working on. I use an IM status like this "Do not Disturb. Need to finish Project Wallaby. Please email. Apologies :(" I also block off time on my calendar to focus on a single activity. This reduces the chance of someone scheduling you for a meeting when you're in the middle of a task.
  3. Respect people's time. Meeting with people is essential. I choose to meet people in their office at a scheduled time. When I do meet someone, I avoid checking email, and I avoid looking at my phone. If someone is spending time with you, respect their time in addition to yours. Ditto for meetings. If you are checking mail in a meeting: you should consider avoiding the meeting entirely.
  4. Stop when done. I usually set a goal and try to finish the activity as soon as possible. When I am done, I stop and take a break. This is essential to getting a feeling of accomplishment. Plodding through the day is much easier if you get regular shots of satisfaction. Break up work into 2-3 hour chunks, and try to finish a task before allowing yourself to be distracted. Over time, you'll find that your productivity improves, so adjust your expectations. Once you are done, go for a short walk, or look outside. Give yourself some time to relax before tackling the next objective.
  5. Beat inertia with a trivial task. I find it much easier to get back into work if I have something trivial that I can hammer out early. This could be a simple bug or a trivial feature. This allows you to get in the mode of work with minimal hassle and beats inertia. 
  6. Hardest job first. Once you have beaten inertia, go for the hardest task of the day. Concentration, focus, and decision-making are their best in the morning after a full night of rest. Once you've done the hardest task, you have the added benefit of knowing that the remaining day is easy.
  7. Full night's sleep. Research suggests that a full night's sleep is critical to improving your concentration. If you are constantly tired at work, napping might help. Many managers frown upon napping, so exercise caution if you need to go down this route.
  8. Love your work. It is easy to work hard at something when work is fun. It might be too late to change jobs, but try to find interesting projects and interesting people to work with. My productivity is high when I work with peers whom I respect and from whom I can learn.
This wisdom is from personal experience, good books like "Peopleware" and "The Mythical Man Month", Randy Pausch's talk, and many online resources.

Many activities at home require concentration and focus, and work is no different. At home, I love reading a book or playing with computers. I think of the atmosphere that allows me to enjoy my home activities and I try to recreate the same atmosphere at work. You might consider trying something similar. Find an activity you love, and identify what atmosphere allows you to enjoy that activity completely. A similar atomsphere at work might help improve your productivity.

Friday, August 19, 2011

Why software patents lead to poor usability

I'm a big fan of usability. I think that usability is the next goal, not features. Products are being distinguished based on how usable they are, rather than how many features they have.

In the physical world, usability is improved by
  1. Making the underlying process visible. An example is a small light that glows when a device is turned on. Glowing lights indicate that electricity is flowing through the device, which suggests that now the device is on.
  2. Improving the mapping between the action and the object that causes the action. Switches have only two positions: on and off, corresponding to the two states of a lamp. Volume controls are dials that you rotate indicating a range of possibilities. Doors have handles that indicate which direction they can be pulled.

Good interfaces in the physical world rely on making the system clear to the user. When interfaces don't follow any logic, they have been standardised: all cars have driving controls in very similar locations.

Computer usability is somewhat arbitrary, though. There is no real-world analogue for a menu-bar, or a right click, or a context menu. There is no real-world analogue for task-switching. The pioneers in computer design could adapt some real-world objects as metaphors for computing actions. Thus the pervasive 'desktop' metaphor for objects on the computer, even though it now has nothing to do with a real desktop. But metaphors are rare and much of the interface was incidental and arbitrary. Like the use of the QWERTY keyboard for all English-language computers, and the arbitrary position of the menu bar (top of the window) and the status bar (bottom of the window).

When usability cannot follow any logic, the easiest solution is to standardise. In his book, "The Design of Everyday Things", Donald Norman shows how the design of a wall clock is arbitrary and illogical. But around the world, every wall clock looks identical, which allows you to read a clock. The placement of the accelerator and brake pedals, and the control sticks on the car is similarly illogical. There is no good reason for the wiper control to lie to the right, and the light control to lie to the left of the steering wheel. But every car seems to follow this. The result is a breathtaking advance in usability. You can rent a Toyota Sienna or step into a Ford Focus and drive it without any instruction. Once you know one car, you can drive nearly every car.

Computers aren't like that, here are the trash bins from Windows and Mac OS:

They both look pretty similar, but not exactly. A user who has been seeing a clear glass recycle bin will look for something similar on OS X. It takes some time to identify these similar features and their related mappings: 'Recycle bin' versus 'Trash can'. Trash cans are just the start of it. Computer systems differ along all these characteristics: the placement and position of the menu, the types of icons, the keyboard behaviours. Even turning off a computer has no agreement. Some computers have a physical off button on the keyboard, some have an icon on the top right, some have menu items. Software to perform the same action looks very different on different systems.

Where computers have standardised, it has been a success. Computers all use the same keyboard and mouse, thankfully. And some keystrokes (Ctrl-C, Ctrl-V) are common across platforms and programs.

The reason why software cannot look identical across products is due to software look-and-feel patents. Look-and-feel patents allow the patent holder to maintain exclusive right to how a user interface looks. A good example is the recent patent litigation on a phone's look and feel. These patents have been around for a while now. So has the resulting litigation. Patents of this nature disallow someone from providing a similar look-and-feel of an established product, which makes it impossible to standardise on an interface.

As a result, consumers have to deal with the explosion of interfaces. Using a new phone is much harder than using a new car!

I don't want to highlight just one company: many companies are involved in this. Such litigation has existed for quite some time now. One of the early lawsuits between Apple and Microsoft about the look-and-feel of the Windows system was filed in 1988. As a result, Windows could not look similar to Mac OS. Windows developed its features in isolation, which Mac users had to painfully adapt to when they switched to Windows. Many years later, Apple developed the popular OS X operating system and many users switched from Windows to Mac OS, they had to painfully learn the new interface.

Innovation is key to generating new products, though radical innovation in the interface is harmful rather than helpful. Cars have had the same control mechanism for many years now. Yet they have had some innovation within the confines of the interface. Cars are more comfortable, safer, and consume less fuel than those in 1960. Yet, you could probably step into a car from 1960 and drive it.

While computers have become faster and more capable, they have not made much advance in standardising interfaces. New systems have their own bewildering interface that require learning. People dislike upgrading because they will have to learn the new interface to perform the same actions that they used to perform earlier.

It is our responsibility as users to demand consistent interfaces. We can buy a new car and can safely transfer all our driving knowledge to it. We should be able to buy a new computer and be productive with it right away.

Tuesday, August 16, 2011

1 Watt webserver

I recently bought a Zipit 2 from an online store. It is a tiny device with an ARM CPU (XScale-PXA270) with 32MB of RAM, an SD card slot, and 802.11 networking. The device cost me $30 including shipping, which is a cheap price for the computing potential. My goal was to run Linux on it, and learn the ARM instruction set. There are many Linux distributions for the Z2, and I found Debian on the Z2 to be perfect. The device is small, light and fits in the pocket of my jeans. Its battery lasts four hours when the screen is on.

Installing Linux on it was trivial: you flash a custom bootloader using FlashStock. This loads a new kernel on the small flash partition on the device, and it gives you the ability to boot from an SD card. Then, you download a Linux distribution for the z2 (I chose z2sid), copy the image to the SD card (using a raw copy tool like dd) and boot from it. I have an 8GB SD card in the Zipit. This Z2 is better than my first Pentium computer along every single dimension except screen size.

Once Debian is installed on the Zipit, you have access to the 'apt-get' package management tool. After installing vim, gcc, make, it turned into a fully functioning ARM development system. I did not want to type using the tiny keyboard, which is uncomfortable and lacks important keys. So I installed an ssh server called dropbear. Now I can remotely log in to the device, copy files back and forth, and use it for development.

Once it was set up, I wondered if I can serve web pages from it. After installing a webserver called nginx, the zipit holds up very well. I'm serving three virtual hosts externally from it, and two hosts internally. For a small amount of traffic, this is the perfect device.

Power consumption

With the screen turned on, the Zipit consumes less than 2 watts of power. When the lid is shut, the screen turns off and power consumption drops to 1 watt. By comparison, a typical laptop consumes 30 Watts and a typical desktop consumes 100 watts. The device is dead silent and cold to the touch. Due to the low power consumption, it generates no perceptible heat. You can leave it in the corner of a cramped closet, and it will chug away. Silently.

There is a lot of potential in these low-power devices called plug computers. Plug computers and mobile devices have caused a resurgence of ARM processors due to their low power consumption. With improvements in processor technology, an entry-level ARM CPU can handle tasks reserved for a "real" computer. Web serving, file serving and ssh-login don't require a beefy processor.  Rather than maintain a full computer, you can purchase a small, silent, and low-footprint computer to handle these tasks for you. Once it is set up, you can store it in a closet somewhere, completely out of sight. Low power consumption allows the device to run exclusively on solar power.

You could use it as an entry point to a home network. Once the SD card is copied to a desktop, you can recover from a malicious attack by copying a known-good image back onto the card.

Low-power computing holds a lot of promise. In the developed world, it can be used instead of power-hungry computers for routine tasks. In the developing world, it can be the first computer for a family.

Wednesday, August 10, 2011

The importance of staying mentally agile

I am a software engineer, and I get paid to write software and design software systems. In my spare time I write other code: Arduino and microcontroller code and Android code for my phone. Over the past few days, I have been modifying my site's CSS and HTML to ensure it looks just right. Forget just right, I wanted it to look darn near perfect, even if it meant knowing everything about CSS layout.

After a few days of not writing software or constructing anything, I get itchy. At the very least, I find reading technical documentation and learning about the innards of systems very liberating.

I didn't understand why this is so until I was discussing mental agility with a friend. He mentioned that, in his job, he felt his skills were wasting away. He felt that he was getting slower. He thought he was taking longer to learn new systems. After this discussion, I realised that I am scared of losing mental agility. A lot of my home-hacking is done for fun: I love playing with an Arduino and electronics. But I suspect that deep down, I am also motivated by a fear of slowing down. I don't want to reach a point when I cannot learn something new, because my livelihood depends on learning new things quickly and in sufficient detail.

Intelligence is more than just mental agility. Intelligence includes quick learning, and also requires good communication and abstract thought.  But the ability to quickly learn a new area is critical.  Even if I wasn't an engineer, I would be working in a profession that required quick mental thinking.  Learning an arcane instruction set won't make me smarter (more intelligent). However, I will get the mental rush of learning something new. And I'll know that I have the mental agility to learn something new to sufficient depth. In the future when I'm required to learn something completely new, I will be prepared for it.

In the case of my friend, his fears are unfounded. The guy is a talented engineer and a quick learner. He is certainly faster than I am at learning new things.

Ironically, the people who are worried about slowing down are the ones that never slow down. They drive harder, keep picking up new skills and keep sharpening their powers of learning.

The people slowing down are the ones that aren't worried about slowing down. If you're worried about slowing down: you're probably doing fine.

Sunday, August 07, 2011

Beautiful, professional resumes with LaTeX

I love LaTeX, but when it comes to resume writing, my skills at LaTeX fall short. This means that I have to load up OpenOffice, and spend hours tuning every single spacing and pagination problem.

Enter Moderncv, a class file for professional looking resumes. If you use LaTeX, it is the perfect document class for writing a resume.

This is what my resume looks like:

You can download the resume in PDF. This resume was generated from this LaTeX source file.

The moderncv class is straightforward: you fill in the details and it generates a beautiful, professional resume for you. Once you fill in the critical details, the page layout is handled for you. So if one section is too big it is automatically shifted to the next page. You fill in the contents, LaTeX handles the rest.

Itching to give it a try? To get started, download the moderncv class from CTAN. Either use my resume as an example, or look through the examples directory for a file called 'template.tex'. On Ubuntu, you need the texlive and texlive-latex-extra packages.

On Ubuntu or Debian machines, you can download all the packages with:
$ sudo apt-get install texlive texlive-latex-extra 

Lego NXT Mindstorm with Linux

There is a lot of documentation on the NXT and Linux on the Internet. A lot of it is very good, like this page showing Linux setup with NXT. Unfortunately it is scattered all over the place, making it difficult for a complete newbie to make headway with the Lego Mindstorms on Linux. This page links to the major steps and will enable you to set up Linux-Mindstorms communication and the programming environment.

Why Linux?

Linux is better suited for Lego programming. It is essential if you have a Linux machine, and don't want to install Windows (or MacOS) just for using the Mindstorm. But the advantages of Linux go beyond that. Linux is a great programming environment, and interfacing it with Mindstorms allows you to connect it to other devices. Linux machines have a good programming interface for Bluetooth, GPS, networking through the Internet, sound, display, and large-scale processing.  Connecting the NXT to a Linux device opens up a lot of possibilities.

Also, many netbook computers are ideal robot building blocks: they are small, light and lack fragile spinning disks. Linux is space efficient, and runs well on these devices.


These are the steps you need to be completely up and running with Linux and the NXT. These pages are listed in order, and each page builds upon the previous work.
  1. Setting up the Linux-NXT Bluetooth connection
  2. Setting up the Linux-NXT NXC programming environment
  3. Writing a program that demonstrates NXT Robot-Linux communication over Bluetooth 
With a little bit of setup, you can combine the flexibility and design of the Mindstorms with the power of Linux.

Saturday, August 06, 2011

Alternate ways of viewing this site

This site is hosted on Blogger, which allows alternate views on the same content. Here are some views you can try:

  1. Sidebar view: the content takes the entire screen. The list of posts is in a left bar which is good for small laptop screens. This is my favorite alternate view.
  2. Flipcard view: all posts appear as two-sided cards. Clicking on the card takes you to the post. The top navigation allows different sorting methods.
  3. Snapshot view: all posts appear as instant-camera snapshots.
  4. Timeslide view: for seeing the entire site arranged by time with recent posts on the top.
These views allow you to explore the blog in a more flexible way than traditional page views.

Friday, August 05, 2011

What to look for in a manager

After having worked with a few people, I have narrowed down the skills needed by a technical manager down to two qualities. While these are observations from software engineering and business analysis, the lessons hold for other technical professions. Here are the two qualities.
  1. Provide creative space. This is essential for technical areas like software development where creativity and risk-taking are essential. After confirming a general direction, the manager should be willing to let the employee explore and learn from mistakes. An excessive amount of top-down direction is frustrating and demeaning to a capable employee. This requires technical skill in the manager, so he can set general direction and realize the amount of work involved.  Providing creative space also means ensuring that the employee has a distraction-free atmosphere, and meetings are kept to a minimum. 

    Without the freedom to make mistakes, a technical employee feels bored, demotivated, and does all his creative work elsewhere (at home, or with friends).

  2. Reward technical achievement. Many projects look deceptively simple from the outside, but require significant work to be successful. A person who ensures that technical work gets rewarded makes an excellent manager. This is critical when the employee's achievement might not yield immediate benefit: large-scale re-factoring of code leads to immense long-term gains and short-term discomfort. Therefore, strong managers understand the benefit of code hygiene and reward engineers for improving the quality of the system.

    Without recognition for hard work, employees settle for low-risk high-visibility projects. Over time, challenging technical work dries up, since nobody is willing to solve real problems. Once this happens, the team loses the ability to hire fresh talent, because they have no interesting projects. Also, a manager who either cannot recognize technical achievement or does not spend time rewarding achievement is seen as spineless. Such a manager quickly loses respect among skilled engineers.

In the best teams, recognition flows downward and blame flows upward. A good manager shields a well-functioning team from missed deadlines and temporary failure. And when things work, he highlights individual engineers for their contributions and ensures recognition for them. Sounds too good to be true? Managers like this do exist.

Truly exceptional managers inspire confidence and motivate their employees. Work is fun because employees are interested in the problems they are solving.

You can judge a team's technical manager approximately by assessing two things.

  1. Quality of technical work: quality of code, and challenge in existing projects. Excellent technical work speaks for itself. It shows that the team values technical achievement and rewards it.
  2. Amount of time employees spend dealing with fluff: number of hours spent in non-technical meetings is a great estimate. Any manager who frees his employees' time values their time and their contribution.