Code Away

A peek at creating the Django Admin interface for any model has floored me completely. I did make a feeble attempt to create something similar for this in Java way back in 2005, but it is quite a daunting task.

The integration offered by Django and RoR really makes one feel that not using these frameworks is just the thing why software developers are in demand today. Hire fifteen to do a job in php which two could do using Django.

Some may say these facilities are just keystroke-savers. Agreed. The important question is why do you not want to save those keystrokes . A common application development (without the right kind of framework) spends a significant amount of time (I’d hazard a guess of more than 25%) doing plumbing work. Lets take a Java example for an “edit” screen, which shows the user already stored data, and allows him to make changes:

• Take data from repository, probably as a generic List
  • Oh yeah, connect to the DB first, and run a DB Statement in a try-catch block, right within your business logic
• Populate a data bean with all the data. All manually. If the DB cursor contains 25 columns, have a object with 25 attributes, 25 getters, 25 setters and populate all attributes one by one.
• Send the data bean to the view
• In the view, have hard-coded UI components for each attribute of the data bean to be displayed. For any related queries to be executed, hard code page links which will fetch those.
• On event of user clicking OK, program a set of validations to ensure user has not entered bad values. Most of these are not business validations, but checks to ensure no bad characters are present in the input.
• Populate user entered values obtained through form into a data bean
• Code a SQL Update script which will take each value from the data bean and update the backend
• commit (don’t forget that!)
• Rinse-and-repeat for all related queries

Any framework support (struts, spring, hibernate) is a keystroke saver in addition to being responsible for formalizing (a subset of) the programming for the application. Django and RoR simply take the integration between MVC to the next level. I had mailed a friend a few months ago about what Rails has:

1. Integration with AJAX: You see whether the type of request from the client (browser) is ajax or plain HTTP. You use those conditions to provide a specific response. In case it is an ajax request, you can play directly with elements rendered in the browser (e.g. Put text “Saved Successfully” in the information bar and blink it once). This integration, and resulting 5 lines of code is far faster than anything we would do by ourselves. (client side use ajax-specific library functions to send request, then check XML returned and perform activities in browser using javascript again). This integration is thanks to use of inbuilt prototype and scriptaculous libraries

2. Test Integration: I know that if a nice high-level test framework didn’t exist already, we would never get serious about writing real automated tests. It would always be like “lets develop this cool feature now that we have time… we’ll check out tests later”. Fortunately, tests are easy to write, and we can start small. (full page tests and all can be written later). We can also write Model level tests for ensuring relationships etc. N e a t.

3. MVC Integration: Neat MVC code, easy to write. Controllers and views nicely integrated. All variables declared in controller are directly available to views. Which should have always been the case, but in other barebones J2EE/php, you need to pass a data object explicitly, because MVC is not mandated.

4. Fixtures: Stuff to fill your “Test” database with data. Easy to write YAML (byebye XML). This will auto-run when you run tests, so your test database is ready with required data. If you don’t know yet, Rails will auto-create dev, test, prod databases for easy demarcation. Rails will also auto-clone the dev database schema to test database prior to loading fixtures.

The learning curve is a bit high, and I am spending a lot more time understanding the components in comparison to J2EE. Yet, given the benefits, I think it is well worth the effort.

Since I wrote about my stint with Lego Mindstorms and blocked Java I/O calls in my last post, I thought I might as well go ahead and note some more of the gotchas I encountered while working with Mindstorms kit.

Although the Mindstorms RCX has pretty good capability, the programming interface bundled alongwith it is for kids. For any program spanning more than two cases of flow control, we need a real programming language.

The two languages I used were NQC (having almost C syntax, and named Not Quite C) and LeJOS (Le Java OS), based on Java 1.2.

NQC has inbuilt support for functions as well as multithreaded modules, but quite frankly the threading was not upto the mark. With two threads competing with each other for execution time, sometimes there would be several seconds where one of the threads waited for execution. LeJOS, on the other hand, worked beautifully with multithreading.

NQC also has a rather limited memory available for processing in comparison to LeJOS, which is quite surprising considering Java VM of LeJOS occupied around half of the memory. Yet, I was able to form large data structures in LeJOS while arrays of as small as 30 integers started giving trouble in NQC.

LeJOS has its set of troubles as well. The VM installation is actually a one time thing, but with the amount of testing you perform on the bot, batteries get changed, RCX units change and thus you find yourself running LeJOS installation a dozen times, which is quite a miserable thing to waste one’s time on. In addition to that, we have the great blocked I/O problem for Infrared Sensor which we discussed in our last post.

Limited memory and processing capacity puts stringent limits on nested methods, garbage collection and size of data structures. As I discussed earlier, a workaround to blocked I/O calls involved creating two separate threads. In my case, I had to keep both threads running infinitely. Having the child thread exit after receiving the data and having the parent thread spawn a new child when necessary worked for a while, but then the program would hang, presumably because there were too many threads getting created and the garbage collection may not have been able to cope up.

All in all, its fun working on the RCX, as long as the program is tuned to minimum resource usage, which goes for any micro platform. If you have experienced any more glitches or gotchas, please feel free to post comments!

Some time ago, I happened to work with Lego Mindstorms. Rather than learn yet another programming notation for Mindstorms, I preferred to use LeJOS.

However, LeJOS was based on Java 1.2, which had blocked I/O calls. This means that an I/O write was not completed until a corresponding I/O read was executed at the receiver. Similarly, an I/O read was not executed till someone wrote to the buffer.

How is this different from unblocked I/O? In the latter scenario, we poll the buffer status like this:

while(true) {
  sbuf = inputStream.read(byteArr);
  if (sbuf != null) {
    //code to process byteArr
  }
  //other processing to be done
}

In case of blocked I/O, the program waits for inputStream.read to get executed, till a point that the input buffer actually contains some data. Of course, this makes the check sbuf != null worthless, but more important is the fact that the “Other processing” we’d like to do never gets done until the input buffer is populated. Why is this important? Because in most cases we want to process a lot more than a single data stream. For example, in my LeJOS program, I was handling inputs from touch sensors, a light sensor and an Infrared sensor.

(A bit about my LeJOS program: I was trying a basic car driving program which could understand walls with touch sensors, car driving in front using light sensor and vehicle coming head-on using infrared sensor.  Although my Infrared sensor could be accessed using the usual I/O calls, it meant blocking up all the processing till someone actually sent me a signal.)

The easy way out of blocked I/O is multi-threading. The parent class polls the buffer data held in the child class (where both classes are threads and run independently). If there is valid data, we read and respawn the child class. Else we continue (in an infinite loop) with other processing and return later to check data. The child class is the one which stays blocked, but that thread is dedicated to receiving data only. Our program execution continues safely.

For those interested, LeJOS code for basic car driving (with inputs from sensors) with Lego Mindstorms RCX kit is available here.