Receipt QR codes

I've always found QR codes to be quite interesting. The idea of tagging physical things in a reliable easy for computers to read way has many interesting possibilities. Today I was spending some time thinking of a project to work on. I want to learn more about using Amazon's Web Services and wanted a project that would be suitably challenging but not too difficult. Well actually I got a bit sidetracked, but maybe we'll get back to AWS if you follow this blog for awhile.

Like many engineers I like to think of myself as organized. I dutifully enter financial data into quicken for instance. And that's what really got me thinking. I like services like Mint, its great in fact, but its not very accurate in tracking how I spend my money. For instance anything spent at a gas station shows up as Gas and Fuel but I can assure you its just as likely to be chips and soda. So I prefer Quicken, it helps me budget more accurately and save by knowing what I really spend my money on. Wouldn't it be great if printed on the receipt was something I could scan with my smart phone and have it do more accurate data entry?

So I started to think about this in more detail. First a "standard" QR code, the kind you most typically see has a capacity of only 174 characters at its highest error correction level. There are higher density QR codes but I have doubts that they are printable on the standard thermal paper based receipt printers in most cash registers. So one thing to consider is go to a different format, there are lots of ways to print machine readable data on a cash register receipt. But it's hard to resist the QR code approach, as its popularity makes it instantly recognizable.

With 174 characters there's enough space for a date/time stamp, a company name, a transaction type (debit/cash/etc) and enough left over for at least 10 rows of category information. The total should probably be implicit as the sum of the categories. Let's use a simple pipe delimited format for an example (XML is too bulky for QR codes)

12311214:31|Joes's gas station|Debit|Fuel|45.00USD|Cash|Food|4.75USD

I made this a little more human readable then it needs to be, especially we could use a coding system for the categories, that would save a lot of space. The above is 66 characters long, more than 100 left. I would love to be able to scan something like this in.

I think most stores cash register software could accomodate this if there was a standard format. Many companies already break out a receipt like this to some extent in the human readable portion. Grocery stores even go into details like dairy vs. produce. Why should they do this? Well it's a convenience to their customers, it's a feature they can offer over competition, and if you added a secure hash of some kind you could tie a paper receipt to all sorts of online reward programs and opportunities.

I suppose some people might object on privacy concerns. A couple of thoughts, first make sure the bar code is not encrypted (except the hash :). So anyone can see what the data actually says. Keep any personally identifying data out of it. If you do that it doesn't really contain anything sensitive anyway, nothing more sensitive than the original receipt. I suppose if the general population really objected to it you could tie it into the various reward cards programs that are quite common. I don't foresee this would be a big issue.

Next time I'm going to write about some alternate ideas to accomplish the same goal. What do you think?

Tools Sharp - The Economist

Sirs,

Keeping the tools sharp is a repeated theme of this blog. It's important to remember that this means more than keeping your software skills up to date. It means knowing enough about the world around you to take advantages of unexpected opportunities and also keeping a close eye out for warning signs that might affect your business or your lifestyle.

For many many years I subscribed to US News and World Report. This was the preeminent news magazine of its day. It didn't have the largest subscriber base but it had the broadest and deepest coverage of any American news weekly. Sadly I watched its rapid decline in the early 2000s focusing more and more on sensationalist and celebrity stories while its pages on news international and othewise was cut back.

Clearly this was a victim of the internet age and it is true that many publications experienced similar sharp declines. I could spend weeks on what happend to beloved cable chanels as the reality television format took over like ivy climbing on a wall.

Neverthless some periodicials made a choice to move to quality instead of the lowest common demoninator. Surprisingly Rupert Murdoch has done well with the Wall Street Journal, no doubt because its audidence is razor focused on financial information.

As for the American news weekly, we all saw the decline of Time, Newsweek and US News. All using differing combinations of celebrity and shocking news stories to sell issues while slowly minimizing their day to day hard news information that helps you understand how the world works.

Obviously as a person who makes my living off the internet I should probably just move to many free web sites. Many of these places do good analaysis but they don't do a good job putting together an objective picture. CNN used to the be the best of this lot and yet they seem affected by the same trend of trivia and celebrity that so many other news sites have fallen on.

Despite the internet I keep several print subscriptions and The Economist is the most important. This magazine (or newspaper as it likes to call itself) presents the broadest and deepest news coverage of any weekly on the planet. It's not cheap, about $100 a year (or $0.36 cents a day). But it covers every part of the world with a seriousness and purposefulness yet also with a smart sense of humor that makes it a must read the moment it hits my mailbox or my ipad. They do a technology review every quarter that is literally filled with good ideas for start up companies.

I have no financial interest in The Economist (at economist.com) but they are the last publication I would stop if forced to cut off my feed of information from my mailbox.

[Note I edited this slightly to reduce any political references which only add argument and reduce value ad fixed a couple of spelling mistakes at the same time.]

Job Search Tools

Last time I briefly discussed what I have learned about the job situation for software engineers as of the end of 2012. I want to also spend some time talking about the tools that I've found to be most effective so far.

First, and really deserving of its own article, is LinkedIn. Any professional should be familiar with LinkedIn and have an up to date profile. Your job search should begin by looking through your contacts and see who's where. Reach out to the people in companies you are interested in working for and especially reach out to those people who know you well who might be in a position to hire you directly. You should always keep your LinkedIn contacts up to date as you work with people. Personally I keep my LinkedIn contacts limited to people I know fairly well... primarily because I personally don't find the friend-of-a-friend connections to be very useful. Your mileage may vary and certain jobs such as sales might encourage different tactics. But for engineering, its all about knowing someone is capable of doing a quality job or knowing someone is good at estimating, or some other aspect of the job that just doesn't communicate very well to secondary and tertiary tiers of relationships.

Next up are the inevitable job search boards. Here in the Midwest careerlink.com is well known and popular. I have also personally found dice.com a good place to go, I use the feature they provide to email you the newest jobs matching certain search criteria. You can have up to five different such searches in their free tier. There are also the meta-job boards, boards that attempt to collate content from other job boards: simplyhired.com and indeed.com are the best known examples. Be certain to check the careers sections of larger companies you might be interested in. You should know the big players in your industry and check them directly.

If you are conducting a more open ended search or really hoping to move up the food chain I also recommend glassdoor.com. A website that provides inside reviews of companies somewhat like how amazon products are reviewed. The same caveats must be applied, always throw out the best and worst reviews but companies with a significant number of reviews should converge to an average. The main point of this site is to sort out great places to work from average or worse places to work.

Finally, remember to research prospective employers before an interview. Find out what's new, what their current products are, how they are doing in the market, etc. All of this information will allow you to ask thoughtful questions during the interview which is a somewhat neglected part of the process. Also, depending on your circumstances of course, you should try to keep some perspective that you are interviewing them just as much as they are interviewing you.

The Midwest Job Market

Living in Lincoln Nebraska my job search has focused on the midwest. Primarily cities within a reasonable day's drive. This includes Denver (and the entire front range), Minneapolis, Kansas City, Chicago (barely), Des Moines, and of course Omaha where I have worked for most of my life.

I decided on an extended job search that looked at locations outside of commuting distance because I wanted to make sure I found the right job. Exactly what that is will of course vary by each individual's situation. For me, I have a child in college and one not far behind so I was definitely looking for a salary that matched my previous job. I also want a company where technology is important, a profit center, not an expense or after thought. So with those parameters in mind I have been looking in a circle roughly defined as a 500 mile radius centered on Lincoln.

I have found that there are a reasonable number of jobs in any given metropolitan area. And those jobs form a nice spectrum from entry level to very experienced. Very roughly I see about 50% Microsoft technology and 50% Unix. Microsoft shops tend to want VB, .Net, or maybe C# and Unix shops are looking for Java, scripting and some C/C++. I am honestly quite surprised by the high penetration of Java given its history but it certainly is a nice language to work with and I think its popularity derives from a great library and ease of use.

Recruiters are generally willing to talk to you and give you that chance to get the foot in the door. However it appears that competition is pretty intense. Interviews are tougher now than I can ever recall previously and closing the deal is harder than before. The good news is salaries don't seem to have suffered too much. People more knowledgeable than me in the field seem to indicate Salaries are holding up well.

Lessons learned: Study, do your homework, practice your skills while you have some time, maybe write a blog. Do things that get you noticed like contribute to open source or work on an iOS or Android application. I would also recommend targeting your prospects carefully so you don't waste a lot of time on marginal opportunities. Look for jobs that are a good match for your skills.

Good luck and persevere.

Keeping the Tools Sharp

Any software engineer that isn't right out of school knows how important it is to keep up with the latest technology. I'm a Unix guy so if you are going to follow this blog you are going to hear about Unix and its related technology stack and Java to the extent it is platform agnostic. Nothing against the Microsoft tools, there are just only so many pencils you can keep sharp at once.

Let me clarify what I mean by keeping your tools sharp. It not only means keeping up with new versions of software you use (Java EE 6 for instance, huge changes over earlier versions). It also means diving into your tools that you use every day and really understanding them. Especially fundamental tools like your IDE or your source control system. Knowing these tools inside and out means you will get a reputation helping others fix problems and you yourself will be more productive.

But it also means taking the time to revisit things you haven't thought of in awhile. Let's say you are an expert C++ programmer. When was the last time you flipped through Stroustrup's book The C++ Programming Language for those not familiar. Well worth it even if you write C++ code in your sleep. There is always something new to learn.

I would also highly advise taking advantage of any tuition reimbursement program your company offers and taking some classes at a local University. I recently took an operating systems class from a local public university. I'll be honest I wasn't expecting much, I don't write operating systems. But it was actually a great experience. It reminded me about some concepts I don't have to think about very often in my day to day job like signal handling or interprocess communication. But those are things I should be familiar with, they are tools, they solve problems. Being reminded how operating systems schedule processes or how a real-time system's I/O architecture differs from Unix can be critically important and be the difference between looking like an idiot and being the star of your next project. Go to school occasionally, it is well worth it.

Keep those tools sharp.

Remember the Algorithms and Data Structures

It's no secret to anyone who knows me that I've been looking for a job for the last few weeks. I wanted to share a terrific resource that every single software engineer should know about as they get ready for technical interviews.

Companies, of course, have a range of strategies for interviews but typically the best ones (for us Software Engineers) are going to ask tough technical questions. Many companies make it a point to focus on fundamentals, figuring that engineers who know the fundamentals will be better at learning new things. It doesn't matter what language, what operating system, what environment you are interviewing for, if you know your algorithms and data structures you are going to be more impressive in any interview.

I've been out of school awhile, I hadn't even thought much about different kinds of sort algorithms or how to create a balanced binary tree in a long time. Most of us know that our languages typically have libraries that implement these things and that's good enough. But a recruiter for one company happened to mention that their engineers recommended that candidates study The Algorithm Design Manual by Steven S. Skiena. This was one of those companies known for asking fundamental computer science questions as part of the interview process. I figured what the heck, its good practice for any interview and so I ordered a copy from Amazon.

Wow did I quickly learn how much I had known from school but hadn't thought about in ages. This book covers many things that any good engineer will use in their career to develop high quality solutions. You may remember graphs are a great data structure, but do you remember how to calculate the shortest path through one, how about a minimum spanning tree? Do you remember what this is? You should. We all know about NP complete problems and how we have to use heuristics to solve them as best as possible... how many nodes does your graph have to have before you have to give up on an exact solution? 10, 50, 100? (It's a lot closer to 10 than you might remember).

We all probably also remember that a few really good sort algorithms are really fast and the rest are crap. But there are differences between those best algorithms and certain ones are better for certain circumstances.

Every chapter is well written, with real world examples, sample code, and practical advice. Even better, the chapters are filled with exercises to give you a chance to practice and make sure you understand the material.

I also discovered Professor Skiena has his lectures available online. A good option for those who don't want to purchase what is admittedly a somewhat expensive book. And a great way to either supplement the material or learn the material for those who prefer an oral presentation. Here's the link: http://www.cs.sunysb.edu/~algorith/video-lectures/.

Here's a link to the book on Amazon (note this is NOT an affiliate link, I am not making any money off this): http://www.amazon.com/Algorithm-Design-Manual-Steven-Skiena/dp/1849967202/