Sunday, March 17, 2013

Sharing data

These days I split my computing time between a desktop computer at work, a desktop computer at home, a tablet device, and a smartphone.  Frequently I find myself wanting to save data in the form of a bookmark, a link to a web pace, or a note on one of these devices to access later on others.  Fortunately, there are a number of applications which make this easy.  Here are the applications I've picked to do the job.

Dropbox - Installing this application on computers and mobile devices allows effortless sharing of all types of files between devices.  Dropbox gets used by a number of other applications like PlainTest (listed below) to make life easier.

PlainText - Allows easy viewing and/or editing of text files stored on your Dropbox account from your mobile devices.  Only available on iOS devices like iPhone and iPad but you can find similar applications for Android devices.

Xmarks - Makes keeping bookmarks synchronized between browsers on desktop and laptop computers dead simple.

Instapaper - Ideal for those URLs you stumble upon on an application on one device that you want to save for later viewing.  A number of mobile device applications such as Twitter feature integration with Instapaper to simplify the task of saving interesting web pages.

Saturday, February 9, 2013

Windows development tools

It's no secret that given my own choice, I'd abandon the use of Windows PCs altogether.  However it's a sad fact of life that many of development tools I need to use at work are commercial Windows based tools.  In order to make using a Windows PC on a daily basis more bearable, I add the following tools.  An unmodified Windows PC is almost unusable to me these days.  I've no idea how anyone can get anything done on an unmodified Windows PC.

All of the following tools are free except VMware.

  • 7zip - The best archive utility I've found for Windows.  It handles all the archive formats I need to use like ZIP, RAR, and TGZ.
  • Ack - A handy little Perl script similar but superior to Grep which searches only source files.
  • ctags - Creates tags files which many editors, including Vim, can use to make source code navigation dramatically easier.
  • cygwin - Well worth it for the Unix style shell alone but you can add Windows ports of most Unix tools using this.
  • DropBox - Makes sharing files between multiple systems possible.  I take it one step further and have added it to my phone as well so my files are now easily portable.
  • FeedReader - I'm faced with periodic downtime at work where I have to wait for software builds, downloads, and tests to complete.  This RSS reader allows me to stay up-to-date on development tools and techniques during these intervals.
  • Sumatra PDF reader - Using a less popular PDF reader lowers the chances that you'll fall prey to malware using PDF files as a delivery mechanism.
  • Irfanview - Handy for cropping screenshots and other light image file manipulation.
  • Pidgin - Our office uses IM to stay in touch.  This is a nice little IM program with support for multiple IM protocols.
  • putty - I periodically need to connect to remote systems using telnet or ssh protocols.  This program makes that easy.
  • source navigator - Useful for familiarizing yourself with large bodies of source code.
  • sysinternals - These utilities proved so handy that Microsoft purchased the company which developed them.
  • TeraTerm - A decent terminal emulator.  Handles both telnet and serial port connections but I only use it for its serial capabilities.
  • Thunderbird - I use this to monitor my home email account.
  • TortoiseSvn - Integrates the Subversion source code control system with Windows Explorer.
  • TrueCrypt - A useful program for encrypting files, directories, and disk images.  I use it for some of the files I store on DropBox.
  • VMware - I need to run Linux software occasionally.  VMware is the fastest and easiest method I've found of doing this without using a separate PC. 
  • Winmerge - This is the best visual tool I know of for displaying differences between files and for merging changes from one file to another.
  • winscp - Handy for transferring files between systems using ftp, sftp, or scp protocols.
  • Wireshark - The best Ethernet packet sniffer.  It understands lots of protocols and can be extended to understand new ones if necessary.
  • Vim - My favorite editor.  It's a Vi clone with modern features like color syntax highlighting and column editing.
  • Xvi32 - My favorite hex editor.

Sunday, January 27, 2013

Using grep in vim

One of the things I like about Vim (and vi) is the ability to invoke Unix utilities to manipulate text in ways that might be hard or impossible with just the regular editor commands.  It's definitely written with the Unix Philosophy in mind.

One thing I do frequently while debugging problems is to add log messages with a distinct pattern so I can find them easily in the log file.  For purposes of this example, let's assume the pattern I use is XYZ.  If I open the log file in Vim, I can issue the following command to isolate just the lines in the log file which contain XYZ.

^[ggVG!grep XYZ^M

That looks like a pretty complicated command, doesn't it?  But if we examine it piece by piece, it's not really that bad.

At the beginning of the command we've got ^[ which is the escape key.  Look at this ASCII chart if you're not familiar with the caret followed by a letter shorthand for control characters.  I issue the escape key to make sure Vim is in command mode.  While we're talking about control characters, the ^M at the end of the command is shorthand for the carriage return (AKA the Enter key).  That causes the command to be executed.

The ggVG in the command serves to do a visual selection of all the text in the file.  The gg causes the cursor to be placed at the first line of the file.  The V invokes visual marking of text.  And finally, the G causes the cursor to be placed on the final line of the file.  That causes the marked area to contain all the lines of the file.

The real meat of the command is the next part - !grep XYZ.  The exclamation mark pipes the marked text to the external Unix utility which follows which is the grep command.  This particular command line searches for lines which match a pattern of XYZ.

Issuing this command will cause Vim's current data buffer (the full contents of the log file) to be replaced with the output of the external Unix utility which will be just the lines within the log file which contain the pattern XYZ.

That makes it really simple to isolate just the log commands I've added.  Once I'm done, I can either exit Vim without saving or just issue the u command (undo last text manipulation) to leave the log file untouched.

Sunday, January 20, 2013

Unix tool: xargs

One of the reasons I like Unix style operating systems so much is the Unix Philosophy.  One of the principles is it's better to include a bunch of small, fast tools which can be combined together to accomplish a variety of tasks than it is to build large special purpose tools which are complicated to use.  One of my favorite of these Unix tools is xargs.  What xargs is good at is taking a bunch of separate lines of input and changing those into arguments for another command.

Perhaps an example will serve to illustrate better than a dry explanation.

Let's imagine we want to find all the source files from the current directory (recursively) which contain the string "stdio.h" and to edit each of those files using vi.  The following line will accomplish that.  Of course in Unix, there are numerous ways to accomplish the same task.  This happens to be my favorite way to perform the task and serves to illustrate the use of xargs nicely.

find . -name "*.c" -print | xargs grep -l "stdio.h" | xargs vi

The first part of the command (that before the first pipe character) is a simple find command.  The only thing worthy of explanation is the quotes around the file pattern.  Unix shells will substitute matches for a wildcard such as this before the find command gets invoked.  If we invoke this long command in a directory containing files which match the pattern *.c, the matches would be substituted on the command line instead of the actual *.c pattern.

The second part of the command is a simple grep command but combined with the xargs command.  This passes the file names output by the find command to be used as arguments to the grep command.  The grep command is looking for files which contain the string "stdio.h", a common c library header file.

The third part of the command simply takes the matching files found by grep and passes them to vi.

This example should work on either Linux or Mac OS X.  It will also work on Windows provided you've installed a Unix environment such as Cygwin.  Cygwin is one of the first things I install on any Windows machine I have to use on more than a casual basis.

Play around with the xargs command to get a feel for what it can do.  It's a handy part of any Unix tech's grab bag of tricks.

Tuesday, January 15, 2013

Portable tools

Having written software on a variety of development systems including Sun workstations, Windows PCs, Linux PCs, and Macs, I've never regretted the decision to choose easily portable tools for use in my daily work.  By doing so, I learn a tool once and am able to use it regardless of what type of development system I am given at a new company.  I also have a preference for free software.  In the past it's been difficult if not impossible to get companies to pay for software tools.  Having a ready arsenal of free tools for any system I use is a huge bonus.

My editor of choice these days is one of the GUI versions of Vim (MacVim at home and GVim on the Windows PCs at work).  Besides the obvious enhancements which either version of Vim adds to the standard vi commands, the developer who started the project, Bram Moolenaar, runs the project as charity-ware with donations going to help children in Uganda.  I've got no problems donating to such a worthy cause.

I continue to use vi clones because vi was available on most of the systems I've used over the past 20+ years.  Using PCs in the early days, I chose vi over emacs because early ports of emacs were extremely resource intensive.  While vi would fit easily in a 40 KB .COM file which could be executed from a floppy disk on base PCs, the emacs .EXE file (necessary because it required more than 64 KB of code space) typically required a PC with an expensive EMS board.  

Were I to be starting out these days, I believe I'd probably choose to learn UltraEdit or SlickEdit since both have Linux, Windows, and Mac versions.  Both editors also have a much less daunting learning curve.  At best, vi commands are perplexing to new users.  You really need to understand the history of vi to grasp why the commands are designed the way they are.  In a nutshell, software in the early days of Unix had to support a variety of dumb terminals.  Commands had to be formed from the common subset of keys available on all terminals.

If you combine Vim with Exuberant CTAGS, you have a very powerful programming editor which makes it easy to learn and to navigate unfamiliar source code.

I've also chosen the Bash shell as my daily command line interface.  It's available on Linux and Mac.  It can also easily be added to Windows systems as part of Cygwin.  Bash is much more powerful than the standard Windows command shell.  I've heard good things about PowerShell but since it's only available on Windows, it's not really an attractive option for me.

Aside from the tools above, I'm fond of AWK and SED.  Used either separately or combined with their Unix based brothers like xargs, find, and grep, they give an nearless endless variety of ways to manipulate text files.

I've got one last recommendation.  There's a great grep replacement for software developers called ack.  It makes it easy to restrict the files searched to just source files.  You can do the same thing with grep but the command line gets very complicated.

Sunday, January 13, 2013

Loss of a friend

Last week, our dog passed away while we were at work.  Talking to people about it on more than a superficial level is hard because it's difficult to talk about without getting emotional.  I was resigned to leaving my feelings bottled up until a friend sent me a link to a blog post by one of my favorite authors, Neil Gaiman.  Neil lost his dog recently as well.  His eloquent words resonated so strongly with me that I decided to try to take a stab at giving a voice to my feelings.

Jinann sandy cute

We got Sandy almost 12 years ago.  My stepdaughter was in her freshman year of college which left my wife with a bad case of empty nest syndrome.  That was bad enough but our old dog, a friendly little Cockapoo named Biscuit, died making the house seem even emptier.  To make matters still worse, I was working for a startup company which was keeping me away from home 60-70 hours per week.

So my wife called my stepdaughter home from college to help pick out a new dog.  They went to an adoption event given by the Rappahannock Animal Welfare League.  At the event, they discovered a 7 month old Siberian Husky - German Shepherd mix.  Apparently most people want to adopt puppies so the League had almost given up on getting Sandy adopted out because she was very close to full grown by that time.  My wife insists Sandy chose them as family.  She jumped up on her back legs and put her front legs on my wife's shoulders, something she was easily capable of as such a long bodied dog.  Once they met her, Sandy ignored the rest of her surroundings including an open bag of dog food ending any doubt that she was the perfect dog for us.

DSC00092 2

Sandy came home with them and while it would be nice to say I loved her immediately, the truth is the long hours were making me kind of cranky.  So Sandy whining at night in her new surroundings while I was trying to sleep didn't instantly ingratiate her to me.  However within a few days, Sandy's friendly enthusiasm and loving nature started winning me over.

From the first my wife was without a doubt the alpha member of Sandy's pack.  Whenever we returned home, Sandy made a beeline to greet my wife.  Only after she'd paid homage to the alpha would she seek me out.  Lest you think I'm bemoaning my beta status, life as Sandy's second fiddle was still pretty great.  Her energy and enthusiasm was infectious and she'd easily lure us into a game of keep away with her favorite stuffed hedgehog.  Thinking about her running up and down the stairs while squeaking her "Hedge" still brings a smile to my face.

My favorite times with Sandy were walking in the snow.  She loved bounding through deep snow drifts.  She also was determined to investigate any small indentation in the snow's surface, as if convinced there were some small animal burrowed in the snow.  I had to stifle laughter while watching her, something exceptionally hard to do when she'd look up at me with her muzzle covered with snow.

Sandy had several nicknames.  Since our parents had always included our middle names calling us when we were in trouble, I decided Sandy needed a middle and last name.  So her full name became Sandra Day O'Connor.  To tell you the truth, even on the rare occasion when she'd done something to warrant the use of her full name, a sad face from her usually turned our thoughts from scolding to laughing and playing.

Since she was a herding breed, she instinctually nudged us with her nose to get us to do things.  It's quite hard to type on a computer when your arm gets suddenly flung up into the air by a dog nose.  That habit got her christened "The Beak".  The sound of her toenails when she ran on hard floors invited the name "Trotsky".  That one was a bit unfair as I don't believe she had a revolutionary bone in her body.

It's been almost a week since she's been gone and I still find myself looking down at the floor next to the bed before I get up in the morning so I don't step on her.  She'd usually go to sleep on my wife's side of the bed but would move to my side at some point during the night.  She had very distinct ideas on who to stay next to when my wife and I were both at home.  If one of us were sick, she'd stay next to the sick one.  She also guarded whoever was the last person to get up each morning (usually me). 

Seeing her toys laying around the house still brings a pang of sadness followed by memories of her playing without abandon.  I hope she could sense how much we loved her.  She certainly made our lives much richer with her presence.

Sunday, April 15, 2012

Long hours

For years I've been subscribing to Jack Ganssle's excellent newsletter, The Embedded Muse. It's a must read for anyone working with embedded systems. It's also very good as a general resource for engineers who work with any type of hardware or software. If you're a software or hardware engineer, I urge you to take a look at a few back issues and then sign up for the free newsletter.

 The issue which arrived today contains an interesting discussion about the number of hours engineers are asked to work. I fall heavily into the camp which questions the wisdom of working more than 40 hours. Lest you think I'm a slacker, consider that I worked for 8 straight years at startup companies, and I probably averaged 55-60 hours per week during most of that period. I can speak from personal experience that the weeks with extremely long hours were not nearly as productive as those where I worked 40-45 hours.

Of particular significance are the stories where upper management gets upset when they find no one in the lab after hours. Whenever you find upper management in the lab after hours, that's also a result of poor management. Good managers will be able to communicate with line managers without checking up on them. Good upper managers will also be sufficiently removed from day to day operations that they realize they may not have the entire picture. Employees connected to lab equipment from home are awfully hard for anyone to detect. If you think that you can only achieve results by having a negative impact on the engineer's personal life, I can safely say I don't want to work for you and I suspect most experienced engineers would say the same.

 I would suggest that any project where management asks for a long term commitment of long hours is a direct result of inexperienced or poor management. Any manager with a reasonable amount of time in the industry knows that while you may get a delivery out with a short burst of concentrated effort but if you ask for it over a period of months (or more), you're going to get a product which requires more and quicker maintenance releases thanks to the mistakes even the best engineers make when they're overtired. You're also asking for a large turnaround in your engineering team unless you're able to offer some form of extreme compensation (large bonuses and/or stock options).

For young engineers, I would advise that you consider what you're getting out of any company which is asking for extreme time commitments. If you're getting some form of financial compensation or some form of experience which will prove extremely valuable in the future, I'd say go for it although I'd get it in writing if at all possible. Otherwise, I would suggest that you update your resume and start looking around for a company whose management might not be so out of touch with reality.