Sidebar: JShell

So i'm coding away and getting increasingly frustrated with having to open multiple cmd windows (yeah, yeah i use windows) . My main crib is that I have to remember which one of the cmd's to open up for the task at hand - db server, db client, app svr or compile/jar/run :(. Papa not like!

So I think: would'nt it be nice if i had the same sort of tabbed console that those lucky linux guys have and play around with? Even better, wouldnt it be nice if ran off of the app anywhere platform - ie written in Java?

So I go looking for a java command shell - and find one in good ole sourceforge - jcmd. It has pretty much everything I want:

• tabbed consoles
• command history
• restarts each console with command history on restart ( had to fix it so it did it even when you alt-f4'd the app)

But..

• The backspace didnt work - something that I eventually found was a JDK bug in TextArea.replaceRange(). jcmd has not been updated since 2002
• it really didnt have variable substitution. It supported env var sets, but not exactly along the lines of ${java.home}\bin\javac

So....
I'm making my own java shell - called JShell.

It uses a lot of concepts from JCmd, but is a build-from-ground-up-while-looking-at-a-good-example effort.

Right now, I have what I call the DOGFOOD release - I can use JShell to compile, jar and run itself. However, its by no means even close to working as:

• The GUI code is just adequate - needs refactoring.
• It has very basic keyboad handling - only enter is handled now.
• However, it does improve on jcmd by having a grammar for the commands and I use JavaCC to generate a grammar.
• It has very poor execution capabilities - right now it just spawns a process to exec normal OS commands, waits for the process to complete and then prints out the result

more later..

The tiny dev tools

Awrite, time to write some code. So I next went shopping for tools. Of course I could just go barebones - edit with notepad and compile with javac like the good ole days, but I thought I could do better than that. Why not have a dev toolchain that also sits in the pen drive? Maybe I could have one pen drive to hold the deployed app, and another to hold the dev environment.

So here's the shopping list I came up with:

• Editor
• should have project feature
• should allow build to deploy directory (this eliminated need for ant and suchlikes)
• Version Control Tool - for obvious reasons
• should have ability to cull out deltas (this is because I expect to work on the code in a disconnected mode, and would like to snyc up just the deltas)
• Of course, both had to be written in java to leverage the base java platform.
  

So, Back to google.

Searching for java editor and java ide turns up a plethora of choices. The obvious ones - eclipse, netbeans et al were disqualified on footprint and general too-busy-interfaces excuses. So I went looking for the not too mainstream, sufficiently enough feature-laden IDEs and finally settled on jedit. It was written in java, seemed pretty stable, and could be extended with plugins to support the project feature. So jedit the editor was.

Note to self: At some later date, I should come back and post on the specific editors I looked and and nay-said just as a comparison.

Setting jedit up was not as straightforward. While the base install worked like a charm, it took some figurin out to get the settings to save under my app root and NOT in user.home, which on windows defaults to My Documents. Also, I couldnt get the plugins to download at all, and had to manually download the plugins, find their dependent plugins and download those, and then manually set up jedit so that it recognized them. After all these, the project plugin just barely worked, and the Compiler didnt at all, so I had to resort to command line compiles from the console. Which was the two step forward routine, as you'll agree :(.

Fast-forward to keep on the same thread: I perservered for a while until I broke away from the project for longer than usual, and when I came back, found that the settings didnt work right, and I'd forgotten how I'd manually compiled. So back I went to the search for the next IDE. I finally settled on drjava - a tool used more to help students learn java, but seems to fit my needs just fine. So thats what I'm using right now.

Finding a version control system written in java turned out to be a little more diffcult. There are scores of java cvs and svn clients, but few servers. And even less have a GUI - except superversion. The 2.7 M package has pretty much everthing I need except being able to extract deltas. Oh well :)

Next: The early days of code generation, or realizing how less I still knew!

The tiny app platform

small..tiny..those were the keywords with which I went shopping for a database and an app server. The client of course, was to be the browser, so I didnt bother too much about that one - the idea being that the one external piece of software the "app anywhere" platform would depend on would be the browser. How naive I was in those early days!

Back to the db and App Server in the meanwhile.

I'd used hsqldb before, so that was an obvious choice for a free, opensource java db. So that was that as far as the backend was concerned.

As for the app server - any EJB server was out of the question because a) anything that verbose didnt come without flab and more importantly b) because i just dont like EJB :). Hey its my app, i make the rules!

I'd been a big fan of vqServer a while ago and went looking for it, but seems to have not been updated lately, so I looked at the other good thing I knew about - jetty. The latest docs seemed to show much promise, and at 20-some-odd MB, a real good fit for my purpose.

Time to get a little organized. So I started with the primordial directory structure:

(Not shown: hsqldb.jar in the jetty/ext dir)






And then I came upon this superb writeup on creating exactly what I wanted. The author intended it to be a "run-from-cd" app, but cd to pen drive is a short sneeze away. And the util servlets absolutely were the topping!

A lean n mean java machine

So I look at the jdk 1.5 bundle - its way over 100M. Not good. So its gotta lose some weight. Obviously the docs can go. So can src.zip and most of the i18n stuff - I aint planning on international support, and even if I am - maybe we can just stick in just the files we need when we need them ;).

I then go through the readme that comes with the jdk (does anybody do this at all - guess people like me do!) and find some more fat to take out.

End result: Jdk at 77.5 M, ladies and gentlemen!

Next up: the dev platform.

Account Management Software

As a middle level manager in one of the top outsoucing companies, the pains of executing a app dev/maintenance service keep hitting me on a daily basis. Having worked on both sides of the onsite-offshore model - the business development and delivery sides, that is - I'm surprised that the tool of choice still remains the extremely, yet infuriatingly versatile excel sheet. Every manager worth his salt has his own collection of xl sheets that contain the dark secrets with which he plies his middle-mgmt trade. And while most organizations provide a plethora of internal tools and portals, the middle manager still sticks to his xl sheets. Why this is so is a rant, so I'll concentrate on what could be done about it.

An onsite manager's primary goal is Business Development. Top line and bottom line mostly. An offshore manager's primary role is Delivery - plans and people. And yet both need to store and user the same underlying data - people, projects, start and end dates and so forth. The former needs a system to be able to predict how much business he is seeing down the pipe, and the latter needs a system to be able to predict how many resources he is seeing down the same pipe. The former however has a greater need for portability - he is most proably a seasoned road warrior - used to connecting from the reticent hotel wifi connection just to see that last mail he missed out on during the flight. The latter has some need for portability as well - he might take calls from home late in the night and (unless his company has provided him with one) might not have a laptop handy to check all his xl sheets with.

Enough whys and wherefores. Such thoughts led me to think of an account management software that can be used by an onsite or offshore manager to handle the various pieces of data in an easily accessible form - the anywhere app.

The idea itself is not new at all - Have an app that runs from a pen drive. Portable Apps has tons of such software. But bein a Java geek wannabe, I had to go for gold and come up with a tech spec like below:

• Completely Java based - still believing the WORA concept
• Should fit into a pretty small pen drive code+data - targetting the 128 M one that I have
• Should work from a standard browser.
• Should provide all the functionality that a normal app would - ie RIA
  

And for some functional requirements:

• Should allow for temporal data storage. Ie, it should be able to handle facts such as "I added Resource X to my team effective Jun 2006 till Sep 2006, but I entered the fact into the database on July 2nd".
• Should allow for temopral queries, obviously. Something along the lines of:
• Who were in my team as on Jun 3?
• What has been the history of Resource Y in my team?
• For the offshore manager it should allow the management of:
• People
• Teams
• Resource Forecasting
  
• Projects
• For the onsite manager it should allow the management of:
• Projects
• Prospective Projects
• Pipeline & Forecasting
  
• Client Management

Next post: The tiny java deploy environment