Standalone Web Applications: Have it All

Ajax and the fancy “Web 2.0″ trend are causing all sorts of web applications to pop up. The most familiar examples are the many services that google is making available, and gmail especially. Gmail is, for many people, a desktop mail client replacement. And why not? It contains the functionality that one would expect in a desktop application – viewing mail, composing new messages, and creating filters to sort incoming articles of text. It is a nicely packaged application with a decent interface. It does however have one major flaw: it doesn’t control the application used to view it.

We aren’t talking cross-browser compatibility problems or the folks using text-only browsers such as lynx. The issue that spans all browsers is that they contain navigation buttons. Back, forward, and refresh, these are all elements that can make the execution of a web application occur in an order unintended by the developer. From a software engineering perspective, this presents new problems previously not encountered when designing and developing software. From a programmer’s perspective, this introduces new complexities in the code because the state of execution can change at any time. Additionally, the code monkeys have to handle sessions that may not terminate properly, half-open connections, and navigation issues that will creep up from the user jumping around your application.

A solution to this problem that hasn’t been completely explored is to combine the benefits of desktop applications with the advantages of web applications. Desktop applications are self contained, meaning the interface to that application is completely controlled by the developer. The state of execution again becomes reliable, hooks into the process’ termination can execute cleanup code, and even cross-browser issues may be ignored. Web applications need only a web browser to load them. By embedding the rendering engine of your web browser of choice (as far as I know, Mozilla’s, Internet Explorer’s, and Safari’s rendering engines can be embedded) in an application, the only thing the user see is exactly what you want them to.

The only complication that arises from this situation is the initial distribution of your application. But because the desktop ‘launcher’ application is going to be nothing more than a frame with some logic to handle any initializing or cleanup you wish to do, it is going to be a very small download. And if you are a company that produces a lot of applications, your launcher can be modified easily to support all of them from a single application. Attractive, isn’t it? This also allows for targeting an older demographic that has been slow to catch on to web trends by deploying to them something familiar: an icon on the desktop to be click clicked.

Now for the business stuff. If you already have a solid web application that conquers the navigation and other issues that plague them, you are one step away from redeploying your application to a new market. And while speaking of markets (and thus money), if your application is driven by advertisements, controlling the platform means that the user won’t be able to block your ads. Physical distribution also becomes possible at this point. Your launcher could be bundled with an installer and distributed by CD to be sold on the shelves in brick and mortar establishments. Now your application will be reaching all corners of the current software markets, bridging gaps of technical understanding, and all without your users blocking the media you want them to see. If you are just starting development with this paradigm in mind, you are going to save development time which can be refocused on implementing features for your users. The result is a better web application that is available to everyone.

The benefits gained don’t take a lot of convincing to sell. Simplified development, a cleaner application, and reaching broader markets all from changing the means of distribution?

Money. 

Making .ico Icons With Paint.NET

Giving your application an icon can be that finishing touch that says “application, I love you.” Unfortunately, the icon designer in Visual Studio 2005 isn’t a very friendly tool for creating nice looking icons. Wanting to make a cow icon for a quick 12/24 hour converter I wrote for my girlfriend, I went running to my favorite image editing program – Paint.NET.

Paint.NET it turns out doesn’t support saving images in the windows-standard .ico format! Luckily, someone was as unhappy with this as I was and created a filetype plugin for Paint.NET that grants the ability to work with and save images as icons. The download link is here. The plugin is awesome, it supports editing and saving images to be used as cursors also. And both formats, icons and cursors, can be saved with multiple image sizes in one file to support multiple icon and cursor sizes. While it is overkill for my application, this feature will save time in the future by allowing  icons and cursors to be designed once (as a larger image) before being automatically scaled to each of the smaller sizes. The same feature addresses large icon and cursor sizes for users that require higher accessibility (another extremely important aspect of software development that is far too often ignored) making this plugin an all-in-one hit.

So while my girlfriend will never appreciate the depth and accessibility her little cow icon provides, it makes me smile knowing that in a pinch it could be blown up to all its 256×256 32bit glory :)

The Greatest Programming Tip Ever

We’ll start this one off with a link. Don’t worry, it is just an image (safe for work, too).

The Greatest Programming Tip Ever.

I laughed when I saw that initially, then the title hit me. That really is the Greatest Programming Tip ever. Or at least it should be on the list of top 10 Great Programming Tips, if there were such a thing. Regardless of whether you are working on an assignment for a class, a personal project, or a product for your employer, it is almost certain that someone is going to look at your code. Writing readable and easily maintained code is important for this reason, but for different reasons.

If you are going to be writing code for a class, you had better put some time in making sure your code adheres to your department’s style guidelines. For the computer science department at RIT, this was actually factored into our grades on labs and projects. Even if it weren’t, your professor is going to be more frustrated than impressed with a piece of code that lacks comments and is filled with ternary operators. Comment your code to explain things that aren’t immediately obvious to a first year CS student, name your variables to be descriptive of their function, and make sure your program flows well (no spaghetti code). This will make your professor happy, thus boosting your grades.

For personal projects, it is just as important to follow the guidelines above. While there may be no one grading your work, consider that friends, future employers, and future-you may look at the code later. Embarrassingly, I can’t even count the number of times I’ve rewritten those run-once-every-three-months kind of scripts because I didn’t take the time to comment them. And if I had put those scripts on a public source repository (which I fully plan to set up soon), employers would eventually see it. I want the code I present to the world to reflect that I am a proficient, clean coder. You should want that for yourself.

Now here is the big one, your employers. If you are working for someone, that almost definitely means you are working on a team. In this case it isn’t just a matter of writing readable code so you can remember what you’ve done when you later have to fix a bug in the code. No – things have become amplified to a factor determined by the number of people on your team and the number of those team members that have to maintain your code. I know from experience the pain and delays that can be caused by terrible code, and I won’t lie: it happened way more often than I’ve blogged here. It dragged down the morale of our project team, caused huge delays in our production (on the magnitude of weeks of developer time over the past six months), and made the codebase impossible to maintain cleanly. You do not want to be the guy that is responsible for that. Best case is you lose your job, worst case is management turns a blind eye to the project team hiding organic material in the corners of your office (give it a couple of weeks, you won’t enjoy it).

Go out and do some reading on writing readable and maintainable code. Aside of learning the basics of a language, it is the single greatest thing you can do to improve your abilities as a programmer.

Geek Adventures: Project Management – Implementation

Last time, I talked about the requirements and initial division of an attendance database project for Computer Science House. If you recall, we left off with the project having been split into parts that will eventually be coupled into a complete system – these parts being an iButton interface, iButton back end, user interface, and client back end.

Mark, having been on the last team’s attempt to create this database, was tasked with getting our preliminary idea of what the database should look like up and running. Additionally, since he’ll be working directly with the database, I’ve assigned him the task of creating a PHP interface for interacting with the database. This interface will be called from the user interface as a means of centralizing the database calls for easier updates and maintenance.

Dave offered his help with whatever module needed developing, so he is primarily responsible with developing the user interface. He’ll be using PHP, JavaScript, and CSS as his development tools, utilizing Ajax-ian techniques for creating an interactive interface. This is going to be the most time consuming part of the project, so while Dave is responsible for the primary design and page layout, both Mark and I will be jumping on board to implement specific features when our parts are complete.

As for myself, being the only one with the iButton hardware for now, I am implementing the iButton interface and back end. The technologies I am using are Java, JavaScript, and LiveConnect. Java allows for the development of both the iButton communication application (the iButton interface) and the applet (iButton back end), the first of which was necessary to use the iButton Java SDK, and the second of which allows us to use LiveConnect to make the iButton IDs available to our web user interface invisibly.

The division of the project into smaller parts allows each member of our team to develop in parallel. With an emphasis placed on clean, self-explanatory interfaces existing at the points in which the modules come together, core development should proceed smoothly. As a bonus, each member is granted the freedom to develop in their own style at their own speed, with the only required communication occurring when it is time for members to link up their pieces.

For now, we code. See you when it comes time to integrate!

Geek Adventures: Project Management – Requirements

In my short career as a software developer, I’ve gained experience in multiple programming languages, development styles, and team roles. One role I have yet to play however is project manager. Transforming an idea into an end product using several stages of development with multiple people using many necessarily distinct technologies has always intrigued me (and here is my first public announcement-) an ideal job. Since there is no room for me to gain experience in this arena at my current job, I’ve decided to take on a small project and recruit two others to help me mature the concept and realization of a meeting attendance database for Computer Science House (CSH).

The basic idea of the attendance database falls in CSH’s need to record when members attend committe and general house meetings so we may conduct evaluations of our members. It is a simple idea until the requirements are analyzed. They are as listed:

1. The system must be able to store and retrieve which members were present at a specific meeting.
2. The database will be on a central server, but the client must be multi-platform and portable.
3. The system must be able to able to verify on some level that a member was physically present at a meeting.
4. Corrections to the database shall only be made by the executive board member presiding over the meeting.

And once these basic requirements are met, features will include:

1. The system must be accessible in the absence of an Internet connection.
2. The system will make the job of the executive board members easier by not requiring their involvement in recording a member’s presence at the meeting.
3. The system will include functionality for the evaluations director and chairman to generate reports of meeting attendance for all members to aid in quarterly evaluations.

Once equipped with the requirements and feature requests, I set out to find a couple of intelligent members that could aid in designing and development of the project. They are David Brenner (chairman, spring quarter ‘07) and Mark Schillaci (evaluations director, ‘07-’08). Dave learns as naturally and relentlessly as his heart beats and is capable of grasping abstract concepts easily. This makes him great for picking something up and applying it quickly. Mark is less experienced than Dave or I, but is also sharp. The reason I asked him to be a part of this project has two factors. First, he was on the last attempt to create the attendance database, and second, because he isn’t afraid to dream. This second factor paired with his lack of fear of being wrong yields great ideas that, when grounded and refined, become solid and actionable contributions.

With a team assembled, analysis of the requirements and how to move them into implementable items began. The first step was a separation of the system into components: the database and the client. Following this, an analysis of the components was made in order to fit the requirements. The database being hosted centrally is a given, so it really doesn’t need further discussion. The client requirements state that it must be portable and multi-platform, and obviously must be able to communicate with a database remotely. Additionally, it should be able to verify the physical presence of a member. This one is more interesting.

When developing for multiple platforms, the most efficient way to proceed is to create something that has a single interface for all platforms and a codebase that requires little or no modification to make available to other platforms. This results in creating a single user experience regardless of their operating system, and most importantly as a developer, an easy to maintain system. These objectives are most easily achieved with a web application, where any user with access to a graphical web browser that supports javascript will be able to use our application.

 The issue of verification on the client required more thought, and came to me while I was working on another project. The first method proposed by the developers of a previous attempt at creating the attendance database was to have the executive board member or house secretary log in, then manually type in or check off the names of people who were present. This system is flawed – it relies on the individual entering the information to see each member, which in a crowded room with members sitting behind couches can be unreliable. It also leaves the members not knowing if the person taking attendance noticed them, resulting in their asking “did you get me?” Immediate feedback to the member is necessary to prevent this. My solution to this problem is to use iButtons.

iButtons are a technology that in their most simple form are capable of carrying a guaranteed unique 64 bit ID. We already use them on CSH in our Drink projects Big Drink and Little Drink, as well as in prototype implementations of our iButton doorlocks, so the technology is not foreign to our members as an identifying token. In our case, a USB iButton reader would be connected to the laptop from which the attendance database client was running, and members upon entering the meeting place would click their iButton into the reader which would then record their attendance at the meeting. This solves the requirement of ensuring a member is physically present at the meeting and easily addresses the feature requesting that little involvement from the executive board member be had in recording attendance.

 The final subdivison of the client ends up looking like this with the above taken into consideration: the user interface (graphical interface), client backend (database communications,) iButton interface (physical reader and accompanying software), and iButton backend (local communications with client). In the next part of this series, we’ll discuss the technologies involved, the solutions decided upon, and the initial roadmap of development.

Java GUI Development

I’ve inherited a decently complex graphical interface to add functionality to, all written in Java. The previous developer who originally designed the interface (and who is also no longer with the company) used NetBeans to accelerate the process. While not bad in itself, the results are horrifying.

I now have a couple hundred lines of variables named along the lines of “jPanel18″ and “jTextField3.” There are three separate layouts being used across the many panels. Not a comment is to be seen, except for what was provided by NetBeans’ auto-generated comments, which have nothing to do with the code and everything to do with “this is auto generated, don’t edit.” To make things worse, the form file that accompanies the source for NetBeans is almost two years out of date, and a lot of functionality and structure changes have occurred since then leaving me to do all the editing by hand.

Tips I suggest for those thrown into situations like this:

• Put a TitledBorder around each panel with the panel’s name. Now that you know which panel goes where, write it down.
• Seriously, draw a picture. When working with generically named components, you’ll appreciate having a ‘map’ of where everything is going.
• Refactor. If you can rename the components without breaking things, give them useful names (Eclipse makes this easy). If nothing else, move the components into groups of functionality or physical geometry in your initialization method.
• Read up on the layouts being used. If you know how to work with the layouts within a panel, you’ll spend more time coding and less time making a single modification, rebuilding, and running your application to see how the change affected things.
• Learn from this painful experience, and don’t do this in code you write in the future.

May you be blessed with patience. You’ll need it.

Build Hell

At my place of work, we have a project that compiles for multiple platforms. Unfortunately, multiple platforms means g++ for linux, and a crazy perl script that generates a Visual Studio project out of the files instead of using g++ running under cygwin to generate executables directly. (So you have to run a bat file which runs a perl script which generates MSVS .sln and .vcproj files which you then open in MSVS and then build within the IDE.) To make this mess even further convoluted, the perl script depends on an in-house method of including dependent libraries for the generated files. Some of them use environment variables to set the path to these libs, while others assume that all portions of the project (in-house and third party) were put in the same root directory. Glorious amounts of relative path traversal occur in the form of repeated instances of “../”. This is hard to read and debug, and since dependency providing includes are at multiple levels of the filesystem hierarchy, it takes a lot of searching to find where things are defined initially.

Ideally, this system wouldn’t be so complicated and shitty.

First of all, there is no reason to be going through MSVS. It can be assumed the build system already has cygwin on it because that is how our perl script runs, so using g++ isn’t an issue. Heck, even Microsoft has a command line compiler if they wanted to use it over g++ – bottom line, there is no reason to use the GUI IDE, especially since it is only used to build the binaries.

Second, the paths in the dependency files are ridiculous. If the current system is to be kept, then the root makefile should contain the paths to each of the libs that will be used, and those variables will be passed down to the other project specific makefiles. No relative paths should be used except for when branching from that main lib environment variable.

Third, things should all be done from makefiles. In our case, it is safe to assume the build machine has cygwin on it. There is little reason to intermingle bat files and make scripts for ‘platform independence’ when we already use cygwin for perl.

I can’t believe what professional software engineers get away with.