Shortly after I posted the Busybox post I received an email from the vendor whose device I was working with, offering assistance. Nice! I really haven’t leveraged it (yet) because the toughest nut I had to crack was the roundtrip to the clock on the update and retrieval of data (which IS done). THAT would still be much, much easier if I could access the clock using JDBC but there have been a few advantages I have uncovered in working with just the http server and shell scripting. My next challenge is to get the whole thing as secure as possible, but security isn’t critical here: The data doesn’t carry any personally identifiable information and although someone who intercepted the data could manipulate it (I guess), there is a verification step that takes place that makes erroneously paying someone doubtful.
Adding to the mix is the need for checking to see if the clocks are online, updating the data en-mass and clearing data that has been retrieved without losing anything. Still working through that as well. The UI is pretty much done but I am not 100% happy with it. The difficulty is viewing the time clock “punches” in a way that is easy to view. If someone punches in and out 8 times in one day, how do you present that? As a horizontal row or as a set of vertical transactions? Best way to handle it is with agile, iterative steps I think. See how it works and then improve it.
Lots of chatter about Flex over on the midrange.com list today. I have seen some demos and sooner or later I’ll take the plunge. But right now, jQuery and Web 2.0 techniques are my bread and butter for now. I need to get the application done, and sell a few dozen, before I even think about moving to a new development platform. All of the data I/O is using Ajax at the moment. Seems like the most flexible way to go.
I have about a week or two left with this project and then I need to return to ASAAP for some additional polishing work and then jump into the IVR replacement. Nice to have work, but it would be better to have some income (still working on that!).
If you have worked with embedded systems you have probably bumped into Busybox. If you are a long time Linux geek, you probably know Busybox. My first encounter with Busybox started last weekend and has been almost non-stop since. Here is the scoop:
You know that I have a Java based Absence Management System called ASAAP . I have recently been contracted to develop an automated time clock system and make it work seamlessly with a payroll package. I naively figured it would be a snap. This being the 21st Century, I figured I’d just find a electronic time clock that had a JDBC compliant interface and within a couple of weeks hook it up to ASAAP which already has payroll posting capabilities. After poking around the Internet, attempting to contact sales people and gather information, I settled on a clock that had a “polling” package to collect the data on a scheduled basis and also push the employee information up to the clock.
After receiving the clock and having a chance to try it out, I was less than enamored with the user interface and my attempts to interface with the DB were frustrated by the fact the DB was an MS Access DB and the JDBC-ODBC bridge is slow and unreliable. What I wanted was something that allowed secure access to the data over a network. So, back to square one.
The company I had purchased the timeclock from had a “barebones” configuration that basically had nothing but a scripting api that accessed clock functions in a embedded Linux distro called Busybox. So, I went with the “start from scratch” approach and have been learning (and re-learning) Linux commands and their particular implementation in Busybox.
This tiny footprint Linux distro is pretty cool and the folks on the Busybox mailing list have been very tolerant of this noob as I have bumbled my way through the learning curve. At this point I have a functioning application that will take input from the keypad or the Proximity badge scan (RFID), look up the employee in the database, display the employee name, prompt them for a punch in or out and store that information in the database.
Next step is to work on data import/export. Unfortunately the Busybox distro I am working with has a relatively old version of Sqlite3 which doesn’t support JDBC, so my plan is to use the HTTP server and CGI to post data to and retrieve data from the DB. THAT should be fun!
So I’ll keep you posted on the progress (or lack thereof). All in all, Busybox provides enough to work with to build this application, I just need the smarts to make it work.
I engaged in a round of discussions on open source on the Midrange-L list regarding the use and merits of open source software in the enterprise. I wasn’t really surprised all that much by the content of the discussion, there seems to be some folks who naturally share code and those who don’t, and there isn’t really any way to convince either side to switch. But that discussion did surface some licensing discussion that opened my eyes a bit to the issues of using open source. Some of that information may influence my projects so it was worth participating.
I play in both camps. I have some “proprietary” solutions that use open source code and I have some projects that I share freely. The one “proprietary” solution I sell may eventually become open source when fully completed and if there are enough customers to sustain a “support only” business model. I estimate that I would need about 50 individual school districts to be licensee’s in order to have a critical mass to move to a purely open source model. But that is a guess. The first step is to get 50 customers! The ASAAP product is basically done after two years of solo work and although I have a long list of things I want to add and much code I want to rewrite, it is “ready to market”. Just in time (barely) to be considered in this (bleak) budget year.
If you need a new attendance solution for your school district that will handle absence recording, substitute dispatch and time card management, drop me a line.