Software Development: Old School or New School?

Since I started writing software when I was 5, I’ve been doing it a long time.  I’ve seen a lot of changes in the technology – from the BASIC language all the way to assembly, desktop to server, fat client to thin client, you name it.  But the trend I’ve seen over the last 10-15 years is troubling.

There is absolutely no question that the Internet has changed things radically.  Much of that change is good.  There is, however, an aspect of the Internet and the way that software is written that is disturbing.  Many of the time-tested, well-thought-out, efficient ways of coding are disappearing and are being replaced by junky, ill-conceived, incredibly inefficient substitutes.  People that are learning to code now are mostly coding for the web, and it is very upsetting how little they understand of the actual science behind computing, mostly because the software development tools in use today don’t even support the best, time-tested concepts.

As part of my job I do software development in both Delphi (a modern-day variant of Pascal, very similar to Microsoft’s C#) and PHP.  Delphi is extremely efficient, and has adopted most of the best ideas that have ever come along in computing.  PHP is at the opposite end of the spectrum – extremely inefficient, lacking support for many of the most basic tools that real high level languages offer.  If you start to talk about JavaScript (the programming language that powers web browsers) the situation is even more dire – it is far more basic than even PHP.  Yet nearly all of the hype you hear in development is around HTML 5, JavaScript, Java, and PHP.  All of which are, frankly, very immature, and are evolving at glacial pace.

One of the technologies that is falling by the wayside is object-oriented programming.  It allows developers to create virtual objects that you can copy, manipulate, and act upon extremely easily and efficiently.  Java is object oriented, but it has other problems of its own (efficiency and security being the main two) that are causing it to fall out of favor quite rapidly.  PHP has some support for objects, but frankly it’s pretty terrible.  HTML and JavaScript don’t even attempt to support it at all.  People that are learning to program now don’t seem to have any kind of understanding of how much easier their lives would be if they had access to object-oriented development tools.  And the situation is actually getting worse, not better.

Another concept that is lost on the web is code compilation.  Pretty much ever since the dawn of computing, developers take code and run it through a compiler to produce the set of instructions that are native to their computer so that they don’t have to be translated at the time the software is run.  Consider how much more efficient you are at speaking your own language than you would be at trying to converse in Korean by using a dictionary, having never heard or seen a word of Korean before.  Compiling does the translation ahead of time (just once) so that software runs as quickly as possible.  Yet again, web technologies don’t do compilation – they do the “translation” at the time that code is executed, making things incredibly slow in comparison.  In addition to that, since the translation is done at run-time, that means you have to distribute the actual source code (the original code you’ve written) to your software in order to run it… so anybody who wants to could take your code and modify and redistribute it… or in cases where you’ve got content you want to protect, like music, or a movie, everybody can see exactly how it is protected so that protection can be removed.  Java has the ability to do a sort of rudimentary compilation just before code is executed, but it is still far from true native code, and it still slows you down considerably.

It’s almost like about 15 years ago people said, “We don’t care about all of the research and learning that has occurred over the last 50 years.  We’re going to come up with a new way of doing things, no matter how good some of your ideas may be.”

As someone who works in both worlds it is incredibly frustrating.  Especially when I have to interact with people who have only ever spent time in the newer web technologies, because they don’t even have a remote concept of what they are missing out on.

There are a ton of other great technologies that seem to be falling by the wayside.  True code debugging (the ability to see what is happening internally inside of software as it is running, making testing much, much easier) is extremely rare.  RAD (Rapid Application Development), once considered the epitome of efficient design and coding, is almost unheard of today.  True integration with databases is pretty much gone too, and in its place are incredibly difficult-to-program, very bloated communication methods that making coding difficult, especially if it is to be done securely.  Forgive me if fname.value=’Frank’ is easier (and conceptually much more sound) than “UPDATE users SET fname=’Frank’ WHERE userid=56”, but this is exactly the sort of difference I’m talking about.  For the most part web developers aren’t even remotely aware that the tools we had for doing things were much better than the best of what they have access to today.  It’s really quite sad.

I’m not saying for a minute that these newer tools don’t have a place.  They do.  But very little, if anything, is being done to improve the tools and incorporate the lessons that 70 years of computing science have taught us.  There’s almost a wall there where anyone who works in the newer tools will automatically dismiss ideas from the old school just because they are old school, not because there is any real reason to do so.

So I have to admit that I don’t really having to work with HTML and JavaScript and PHP.  They all seem incredibly antiquated to me.  Almost like I’m stepping back in time 30 years.  In many cases it is much harder to do things in the “modern” tools than it was in the contemporary tools of the early 1980s.  Things that I’ve taken for granted in what I would call a “real” development environment just don’t even exist when working with their “modern” counterparts. 

Would you enjoy having your Ferrari swapped out for a Model T?  And somehow I’m expected to like it.

The result of all of the backwards ways of doing things with “modern” tools is that it takes forever to get anything done.  I can easily write “equivalent” code in Delphi five times faster than it can be done in PHP even though at this point I probably know PHP as well as anyone could.  And, on average, it takes about half of the lines of code in Delphi to accomplish something as it does to do the same thing in PHP.  And yet the Delphi code literally executes more than a hundred times faster, and provides a better user experience.  Yet somehow people are critical of my decision to continue to use such a tool.  Only because they don’t understand it, and in most cases refuse to even try.

Much of the stagnation in web technologies is due to the bickering and in-fighting that happens between companies that build tools for the web.  HTML 5 is, in reality, very poorly suited for what we are asking it to do today.  And everybody involved wants their own ideas for improving it to become the standard, but nobody else is willing to adopt those ideas because they aren’t their own and they can’t profit from it.  In the 1990s and early 2000s, for example, Microsoft tried to extend HTML 5 with new features in Internet Explorer and they got shot down by everyone else, because they weren’t “following the standard.”  Well, yeah, they didn’t… because there wasn’t a way of doing the things they wanted to in the standard.  Yet when people do actually get together to try to improve the standard, nobody can agree on anything so nothing gets done.  We’ve been talking about HTML 5 for nearly ten years, and it is still so poorly supported across different browsers that you almost can’t use it.

Trying to creating interactive web pages is a an absolute disaster – programmers have to take care of every low-level event (click button, move mouse, release), and those events differ from browser to browser.  Want to play music or show video on a web page?  Nobody can even agree on how to do that so you have to produce three separate versions of every file, then figure out which version to use when you view the page.  HTML wasn’t ever even designed to handle any multimedia other than graphics, either, which is why so many web pages use Adobe Flash, despite the fact that everybody hates it.  Want to do things like drag-and-drop?  Good luck.  It’s really hard to do, and usually has to be coded multiple different ways to work in all popular browsers.  But in my ‘old school’ Delphi drag and drop doesn’t even require writing a single line of code.  Just set an object property saying ‘yes, you can be dragged’ and ‘you can accept dragged objects.’

Adding database interactivity to a web page is an exercise in patience and frustration.  There still isn’t an official way for a web page to pull data from (or insert data into) a database.  It’s still a very tedious and time consuming thing to do.  Don’t even get me started on how nobody does it securely because that’s even harder to do.  But we’ve had databases for 50 years so basic interactions like this should be a cakewalk.  In Delphi, all I have to do to retrieve record 56 from the users table of the database is users.FindKey([56]).  The same thing in PHP is at a minimum of 4 lines of code – much more if you do proper error checking.  And in JavaScript?  Well, don’t plan on working on anything else that afternoon.

It goes on and on.  Want a web page to interact with a Joystick on the web?  Not happening.  Or generating output for a printer with full control over how it looks?  Again, not really possible.  How about photo editing?  Not very plausible in HTML.  How about a page that uploads a picture to your cell phone over USB?  Nope, HTML doesn’t allow it.  And it will likely be at least a decade before such things are actually possible and usable.

All of the above problems had already been pretty much solved by traditional development tools long ago. 

And somehow many of the companies that have produced the strongest tools and environments for software development in the past are abandoning the more mature technologies.  Microsoft is trying to force everybody to the write Windows 8 apps, despite the fact that this environment, too, is missing some of the best things from their traditional desktop environment.  Apple invests very little in desktop technologies.  And Linux stagnated years ago.

It’s really pretty sad.  If people were smart they’d take the best ideas from wherever they come from instead of trying to reinvent the wheel over and over.  And as it stands today, the technologies that power the web – HTML, JavaScript, etc. – are more of a wooden, square wheel than most developers realize.  The traditional ways of doing things don’t have to be left behind – they could easily handle the same tasks that the newer technologies are doing, and in most cases do a far better job of it.  Or, some of the concepts from traditional development could be added to the newer tools.  But, for some reason, never the twain shall meet.  It’s frustrating having to choose between high functionality, quick development, and high performance, and working on the Internet.  It would be really nice to be able to do both.

The Web, HTML5… It’s a Mess!!!

I sometimes get hassled for preferring to develop software to run on the computer desktop instead of as web sites.  Truth is, I don’t care if I get hassled about it.  I know how to develop for the web… part of my job involves creating web sites in PHP, and I think I do fairly well at it, but it doesn’t mean I like it.  And honestly I ought to be criticizing more people for putting so much emphasis on the web… not because it isn’t going to be the future, but mostly because they aren’t being more critical of the way things work on the Internet.

If you take a step back and think about the way that the web works, it’s really pretty silly.  We download a page with information.  We type information into a form on that page, then click a button to allow a computer somewhere else to process that information, and wait for an entirely new web page to be sent back to us.  It’s slow.  It requires that the same information be sent over and over again (everything on a page that hasn’t changed or doesn’t change).  It makes true interactivity slow and frustrating.  It’s silly.  We have these high powered devices we’re using to display static pages that have been created somewhere else. 

Imagine having a web page to do a simple addition operation: you enter 2+2.  You enter the data, click the calculate button, your browser sends that data off to some computer somewhere in a remote data center, it performs the calculation, and sends you an entirely new web page giving you not just the answer, but your original data, and every piece of the entire web page… You’ve just transferred a ton of data, wasted a ton of computing power, just to figure out the answer to a very simple problem.  Total silliness.  But it’s what we deal with every day, because that is the way that the web works.

Add to that the difficulty that web developers go through to make sure their web sites work on different browsers.  We create a page and it works perfectly in our browser of choice, then we try it in another browser only to find it doesn’t look (or work) right at all.  It’s very frustrating.  Again, it’s silly.  And it’s a very slow process.

Compare this with developing programs that run on the desktop (not in a browser).  They can be developed very quickly.  They run very quickly.  The development tools are mature and work very well.  They’re guaranteed to work the same on every computer they run on.  It’s SO much easier to make something work on the desktop than it is on the web.  We have access to advanced technologies that don’t work on the web.  Interactivity is amazing, performance is amazing, with things responding immediately when clicked. 

I know this makes me sound like a stick-in-the-mud to people who think that the web is the future of apps.  I’m not going to argue that things are moving in that direction, and that there are a lot of advantages to it.  My argument is that the way we’re doing things now is just… dumb, and that we’re making very little progress at fixing the problems.

HTML and the web in general were not designed to do the things that we’re doing with them.  HTML was written with the idea of serving informational pages… You view a page, you see a link to another page with more information on a particular topic, click it, and view the new page.  It was never designed with any kind of interactivity beyond that, and every attempt to make it work that way has been a hack.  Even things like logging into web sites and shopping carts are a total hack.  And despite the fact that we’re nearly two decades into using HTML, things haven’t really gotten that much better.  We’re still primarily serving new pages every time we change any data on a page instead of changing just the parts of the display that are affected by our data changes, waiting on a remote computer to do things that our own computers are perfectly capable of doing themselves. 

Not only that, but there just aren’t any great ways to define the structure of data entry, or how it interacts with the page or the web server that is saving and formatting it for us.  It has taken until HTML5, which still isn’t really implemented (and even then very poorly on virtually every browser) and it still isn’t done well.  Even if web developers choose to use HTML5 for their web sites, even the newest browsers still aren’t implementing most of it.  It’s ridiculous!  But more about that in a minute.

The development tools for creating web sites are still really bad too.  I have tried the “best of the best” of them and have given up on every one.  I have resorted to creating web sites in Notepad, because the supposedly “advanced” editors just get in the way more than they help.  I don’t understand why we keep putting up with this and aren’t pushing for something better.  A lot of it has to do with HTML not being designed for the way we use it, but even more-so is the fact that HTML has been very slow to evolve, and browser makers have done very poorly at implementing the changes that actually have been made.

Some web sites do make an attempt to improve the interactivity by only updating only small portions of a page when something changes through a technology known as AJAX.  You’ve seen it before on sites like facebook and Amazon.com where you click something and just one part of a page will change, but honestly few sites take this step because it’s difficult to implement properly.  And unless your browser settings are just right, it doesn’t work at all.

There are other problems too… like security.  You may have recently heard about Firesheep, a program that captures authentication information from other computers on a network and allows a hacker to visit popular web sites using your account without having your login information.  And most web developers don’t understand how to properly secure their sites to prevent outside access to their data.  Because it’s difficult.  These technologies are being asked to do things that they were never meant to do, and very few software developers understand the right way to do things, or even the importance of doing so.  Or they don’t care.

Most of these problems go away when you start developing software that runs directly on the desktop.  Most of the security issues go away.  The slow interactivity goes away.  The difficulty of updating the screen when data is entered goes away. 

Yes, I know that developing applications that run on the desktop does have its own set of drawbacks.  You have to write versions for each type of computer that might use the software.  The software has to be installed.  You have to install updates.  But in my mind the advantages far outweigh the drawbacks for many, many applications that are currently being developed for the web.  And these problems are being addressed anyway.

Eventually many the advantages of running software on the desktop will probably go away.  But we aren’t moving in that direction fast enough.  Developing for the web isn’t really any easier than it was 10 years ago.  Development tools have improved, but not much.  The technologies that power the web have gotten better, but not much.  And yet we as web developers continue to accept it, and some even criticize those that don’t condescend to using these bad technologies.

HTML5

Last week I finally sat down to see what’s so great about this new HTML5 thing that’s getting a lot of press.  Frankly, I was sorely disappointed.

HTML5 doesn’t really add a lot of new capabilities to web sites.  It does add a few, some are kind of cool… graphics rendering and interactivity is one area where things are supposed to get a lot better.  There is the promise of a standard way to display video and audio (finally!!!! it has only taken nearly 20 years).  There are new ways to handle and validate data in forms.  But the changes basically stop there.  And honestly, most of these things aren’t even usable.

Each of the new features is either not implemented in a major browser, or isn’t implemented properly.  A few examples…

• The new graphics features are only supported by IE9, Firefox 4, and Chrome.  Safari (which is what the iPhone, iPad, and Macs use) doesn’t.  And Chrome is the only one with a “current” version that even attempts it.
• The new methods for displaying video are a mess.  Apple and Microsoft have elected to use one format for video, while Mozilla (FireFox) and Opera have elected to use something else entirely incompatible.  Google is taking a more neutral position with Chrome, supporting both.  But there isn’t a single video format supported by all of the browsers.  So you have to create two versions of every video, and provide two versions of every page that contains video to allow users to view it.
• Audio is the same way.  The different browsers support different types of audio files.  No one format is supported by all browsers.
• There is still no way to watch live video.  Only pre-recorded video and audio sources are supported.
• The new features to format and validate form data are only supported by Opera and Chrome.  And Chrome’s implementation is horrible.  The other browsers don’t even try, even in their unreleased beta versions.  These features, which would be very useful and make web programming easier, are completely unusable to the 99+% of people not running Opera as their browser, and therefore are useless to developers.

You may have heard a lot of hype around HTML5 being a cure-all for some of the problems we deal with on the Internet (like Adobe Flash).  But based on what I have seen, it isn’t going to help anything because those creating browsers aren’t doing their job in implementing HTML5 properly.  It’s also very ironic that the most vocal of all of the HTML5 supporters, Steve Jobs, also has by far the worst HTML5 implementation of anyone.  Apple’s Safari browser is, without question, the least HTML5-compliant browser in use today.  It doesn’t even attempt to support the vast majority of the new features being added to HTML5, even in its latest version.  Not that the other browser creators are doing much better.

Ideally…

Ideally someday we’ll have a sort of hybrid of the two ways things are done now.  Store the software and data on remote computers, but download the necessary pieces to our local computer on demand, where things like interactivity and calculations can be handled locally.  If designed properly, most of the things we do now that require entirely new web pages be downloaded would be done entirely locally on our own computers, with only data changes being sent out remotely.  (Some might say this sounds like Java… but… ick, no.  What a terrible language.)  We would standardize on the tools for creating application user interfaces, and the way that the applications respond to user interaction.  We have sort of started on that path with technologies like DOM and AJAX, but they are too limited, too difficult to use, too inconsistent, and too slow to be able to develop meaningful applications that run primarily locally.  We’re still far too reliant on remote computers to do extremely basic tasks that have no place being run remotely.  I believe someday we’ll get there, but at the pace we’re moving now I’m not holding my breath… we’ll be lucky to see anything like that before 2020.

The Truth

The truth of it all is that even though I get criticized for preferring to develop desktop software most web developers deep down know that they’re using inferior technologies.  They know the pain of making stuff work across multiple browsers.  They know the pain of hand coding HTML and CSS to make sites look and work the way they should.  They also know that native applications work better than web sites too.  All one has to do is cite the iPhone as an example.  The first version of the iPhone couldn’t run native apps, and had to rely on the web to do anything other than what the included software could do.  Almost nobody took the time to create sites to run on the iPhone.  It wasn’t until the second version of the iPhone, with the ability to run Apps, came out that it started to really take off.  And everyone with an iPhone knows that running an App instead of going to a web site in Safari is a much better way to do things.  It’s much faster, cleaner, and easier.

It’s really a shame that web developers will criticize me for still preferring to work on native applications rather than the Internet.  Or is it more of a shame that most of them continue to believe that they’re working with state-of-the-art tools with state-of-the-art technologies, and not put more effort into trying to make things better on their end?  It’s also a shame that so many pieces of software that really should live on the desktop are being written (and being written poorly) for the web.  Each has a place, but because the internet is “cooler” than running programs on your computer, too many things that should be on the desktop are being pushed to the Internet, and are being done improperly.

In many ways things I was doing more than 20 years ago worked better on the computers I used then than things do today on the Internet.  Internet technologies have improved, but they are moving at a glacial pace.  And it both makes me laugh, and cry a little on the inside.

Full Circle

My life as a professional programmer has officially come full circle.

The first contract programming job I ever did was when I was 12… some 24 years ago (ugh… was it really that long ago?). It was a project for a law firm in Omaha, NE (where my family was living at the time) that downloaded data from a piece of equipment that logged all phone calls in and out of their office to a computer, and present that information in a usable and meaningful way. The firm had approached my dad about writing this software for them and he decided to pass the software portion of it on to me, while he took care of connecting the hardware. It wasn’t a big project; we didn’t work on it long, and it didn’t pay a lot, but it was significant in that it was the first time that I was being paid for doing some programming.

Today I’m part owner of a company that creates, sells, and supports restaurant management software. We currently have 7 people working at the company, 3 of which are dedicated to taking telephone support calls. I am responsible for putting together the software that they use for supporting customers, and within the last couple of days one of the features I added was the ability to log data about incoming and outgoing phone calls. A box in the office records the caller ID information coming in, sends it out to the network where my software receives it and logs it in a database along with the duration of the call as well as which employee took the call.

This new feature of the software is very similar to the first project I worked on professionally. They both record phone call information into a database.

Many other aspects of my current employment mirror programming experiences I had when I was younger as well. Knowing what to do with phone call data was a natural fit, because I had done it before.

The money that my dad and I were paid for that project went toward purchasing a printer for the computer we had at home. That printer was an Epson dot matrix printer (those really loud, slow ones). Today we are using Epson dot matrix printers for printing customer receipts as part of the cash register portion of our software. Many of the commands to control the receipt printers today are the same as the commands I learned to control that first printer we got nearly a quarter century ago. Learning to talk to the printers today was easy because I learned how to do it 25 years ago.

With the Point-of-Sale system we also talk to various pieces of equipment using serial ports on the register computers. In 1987 I wrote a telecommunication program whose primary focus was talking to other computers over serial ports. In 1989 I worked on a project where a computer would record data coming off of an induction pipe bending machine over a serial port. The project for the law firm also used the computer’s serial port.

There are other ways that I have seen things cycle back on themselves with our current project. It’s kind of weird to see things happen like that, especially considering the rapid pace of technological development. But at the same time the things I was doing 25 years ago (or more) were in a lot of ways preparing me in a unique way for the things I am doing today.

Now if only I can find a good multimedia programming project to work on so I can relive the stuff I made in the early 1990s.

Lots of code

The Point-of-Sale software I’ve been working on for the last 18 months (StreamPOS) is getting pretty big.  I just published a new version of it, and the source code is currently 165,559 lines long.  It has 79 different screens it can display, not counting the standard “Open File” or “Print” type dialog boxes that most software uses.

In more familiar terms, if those 165,559 lines of code were to be printed on standard letter-sized paper, it would take approximately 3680 pages to print it out.  The stack of paper would be more than a foot and a half tall.   It would consume nearly 7.5 reams of paper, and take 5 hours to print at 12 pages per minute. 

That’s an average of 7 new pages per day, every day, 7 days per week, for the last 18 months.  (What does your brain say when you think, “write a 7 page paper every day for 18 months?”)

If it were published in a paperback book, that book would be 6600 pages long (not including the foreword, index, etc. :) ).  This book would be almost three feet thick.  Reading it would take 110 hours at one page per minute, if you could make it past the first page awake.

This makes it the largest program I have written in my life.  My backup software, FileBack PC, is currently hovering around 140,000 lines.  It took 12 years for FBPC to get to the point where it is now.  StreamPOS is bigger and was started just 18 months ago. 

Ironically, StreamPOS is probably the most bug-free piece of software I’ve ever written too.

The first “long” program I wrote was one I created during the summer after I graduated from high school, my first freshman year of college, and the following summer (16 months in total), weighing in at 27,000 lines.  I did print the source code for that one, and it took a little over a ream of paper.

One metric used to determine the length of time it will take to develop a piece of software says it takes about one person-year to create 3750 lines of code.  If that were really true, StreamPOS would take 44 years to develop.  Of course, that same metric says that a line of source code is worth about $33, and if that were true StreamPOS would cost $5,463,447 if we were to hire someone to write it.  So I’m not sure I buy those metrics.  And I certainly wouldn’t hire the guy that writes 3750 lines per year; I’m writing three times that many every month, which is 35 times faster.

In all fairness, though, a portion (I’d guess about 7-8%) of StreamPOS is library code which has been purchased or licensed elsewhere.  But the remaining 92% has all been entered with my own two hands.  It’s a wonder I don’t have Carpal Tunnel.

But if 165,559 lines seems big, Windows Vista is estimated to be about 50 million lines of code.  Even though I have developed StreamPOS at an incredibly fast rate by industry standards, it would take 453 years to write Windows Vista by myself if I were able to continue working at that rate the whole time.  Ugh.

Doug’s Typical Day

Times vary widely, but the activities are fairly typical of any given day, Monday through Saturday.

11:00 am – Wake up, process any incoming software orders, grab some toast, a yogurt, banana, or bowl of cereal from the kitchen, head back to the computer to eat while continuing the day.

11:05 am – Look over the 50-60 emails received overnight, begin responding to the most critical, easiest to answer, and the ones that have been sitting in my inbox too long.

11:45 am – Check the technology news sites for anything new and exciting in the last 24 hours. 

12:00 pm – Take a look over the databases and logs from the different stores running our Point-of-Sale software.  Perform any needed grooming and fix any issues with any servers or registers that have obvious problems. 

12:30 pm – Begin working on one of the various programming projects I’m involved with… these days that is usually the Point-of-Sale system, in preparation for Pizza Expo in early March.

4:00 pm – Time for a break.  That usually involves showering, getting dressed, checking the mail, processing any email from the last few hours, and making a quick lunch/snack.

4:30 pm – If I have any shopping or other errands to do, do that for the next little while.  Back to the computer to do (you guessed it) more coding.

6:00 pm – I’m on shift now for technical support calls for the Point-of-Sale system, though I often get some rollover from the prior shift starting around mid-afternoon.  Still coding when I’m not taking care of POS issues.

7:45 pm – Time for another break.  Quick second lunch or snack.  This is usually when the TV gets turned on to catch any evening shows I follow, but only in the background (I’m not mentally able to just sit and watch TV without doing something else). 

8:00 pm - Back to coding, unless it’s Friday, in which case it’s time to start cleaning up the living room and kitchen areas for Movie Night guests.

10:00 pm – Phone calls and emails have subsided by now, so I can really concentrate on getting some good programming done.  (Phone calls during the day, even quick ones, throw me off by as much as 30-45 minutes each, so my post-10 pm ‘no interruptions’ time is special.)

12:00 am – Snack break.  Check tech and news sites and my email again and catch up on any friends’ blogs that have been updated.  Back to coding.

3:30 am – Start to look for a good place to wind down programming for the day. 

4:00 am – Really start to look for a good place to wind down programming for the day.  Start thinking about going to bed.  On a night when I’m at a good stopping place, this is about where I can start wrapping things up.  Otherwise…

Between 4:15 am and 5:00 am – Finally getting to a point where I can really wrap up coding for the day.  Climb into bed.

Between 5:00 am and 5:30 am – Scripture study if it’s a day where I can still keep my eyes open.  Flip on a TV show or two or three I’ve seen a million times so I can …

Between 5:15 am and 6:00 am – Finally fall asleep.

What is your typical day like?   Post on your blog, then paste a link in the comments section below.

Fun with a GPS

At least fun for me... for others, maybe not so much. But anyway, back to the techie posts...

Last month I got a Dash Express GPS for navigation in my truck and whenever I'm traveling. One of its cool features is its always-on Internet connection, providing up-to-the-minute traffic information, gas prices, and movie listings, but also making searches for just about anything possible since it can pull information from online; it isn't limited to just the database it has internally like other GPS devices.

Another of its cool features is the ability to add custom written applications to the device. This week I found several cool applications, including a White Pages search, so I can just type in someone's name and it will find their address and route me to them, and several local information apps, like population, community, and cultural information. I even found and installed a Twitter app.

Being a programmer myself, and always wanting my toys to do more stuff, I looked into what it takes to create my own apps for it, and it turns out that it's pretty easy. So I wrote three of my own on Friday.

The first is a reverse phone number search. So I can just type in someone's home phone number, and it will retrieve the name and address associated with that number, and map and route to them. Since it was my first app it took me a couple hours to get working. I'm still undecided as to whether I'm going to make it totally public; but for right now I've got about 25 other people that have signed up to use it.

The second one I created is a calculator. (With my two hours of experience with the first app, this one took me all of 10 minutes to put together.) Sometimes I want to calculate my gas mileage and I'm too lazy to pull my phone out of my pocket, so now I can do mathematical calculations on the GPS. It even knows trigonometry, not that I would expect anyone would use it. I made this one fully public so anyone can add it. About 20 people have installed it so far.

The third one, and one that I most definitely will not be making public, is one that will look up the names, addresses, and phone numbers of anyone who lives near my current location. I can either enter a house number (it already knows what street I'm on) or request the information for everybody on that block. I don't see myself using it much, but I will definitely not be sharing it with anyone because of the 'creepiness' factor; would you like someone following you home, pressing a couple buttons on their GPS, and find out your name and phone number? I wouldn't. So that one stays safely under wraps. It was mostly a test to see just how much information I could get for free off of the Internet knowing only a lat/lon coordinate. And it's almost scary how easy it was.

Ultimately I hope to be including some of the functionality of this device into the point-of-sale system, specifically for routing drivers to their delivery destinations, and allowing store managers to keep track of drivers while they are out. I'm working with the guys who created the Dash to see if they can add some additional functionality to make those things easier to accomplish, and so far it looks promising.

It's been fun. How often do you get to buy a consumer electronics device (besides a computer) and create new functionality for it? Not too often I don't think.