martin-white.blogspot.com

I truly believe that in most instances, less is more - Minimalistic design in architecture, car design and computer code (Assuming that shortcuts aren't taken and things are done properly). With code, less code = fewer potential bugs. Following the simple mantra reuse, reuse and reuse, we try... but often come up short. This all sounds pretty simple and is preached everywhere but can actually be very difficult to attain. In developing my web application framework for my applications, I've decided to strip away all the unnessesary stuff and simplify the number of classes. In doing so, I've still tried to keep everything scalable, flexible, consistant and easy to maintain - alot easier said than done.

I turn my attention to JSP tag libraries. In my previous job, I did everything - analysis, design, development and implementation. This is not the idea situation because the responsibility lines get blurred. In the ideal situation, a Web developer who has knowledge of HTML, scripting languages, tag libraries, style sheets etc. but no knowledge of Java, maintains the front end and a back end Java developer develops the business objects. Honestly, I don't know how often this actually happens but the benefits are often preached. Coming back to my former position, I had no problem with reading JSP pages interspersed with Java code but a HTML web developer may have great difficulties in understanding the relevance of much of it. A lot of the complexity can be hidden by using JSP tag libraries which use simple HTML like tags to map to Java classes which output simple tags or more complex structures like tables of data.

Tag Libraries aren't a new thing but like many things, in depth studying of library development has been put off for a long time. But now that I've started delving to into it, I've realised the importance of them. Firstly as mentioned, they remove most (if not all) of the need for Java code to be placed in a JSP page allowing expert web developers to develop the look and feel. Secondly, with no java code in a JSP, it reduces the amount of code and as mentioned before, bugs. I had relativly recently started using ASP.net and was suprrised at the ease of being able to double click on a HTML design component e.g. a button and it suddenly produced a .aspx file with the button handler. I have no idea how the application server handles the flow between the HTML page and the server side handler but that's the point - I don't have to. All I need to know is that it happens. This is essentially what I'm trying to achieve.

It was all going well... I had the SMS gateway installed and running on my laptop and it could send and retrieve SMS's. So the next step was to transfer the .war file to the remote server, install all the other components and test. Easier said than done...

Firstly, I tried deploying straight to Tomcat, but that left me with the problem of not being able to see certain error messages. I know, I should be logging error messages properly but hey, this is still a test. So I then started up Eclipse and tried to run it there only to find out that I was having problems writing to the COM ports. With all the messing about I think I may have screwed up the firmware on my phone. Whenever I plug in my phone via the USB cable now, it just gives a "Unrecognised usb device" message. This suddenly happened on both my computers. I tried to use my other Samsung instead, but couldn't get it to show up as a COM port in the device manager. So it's off to my service provider to see what they can do. The joys of being a programmer...

Continuing from the previous research and work, I've decided to build a complete gateway using the smsLib as a base. So far, I've already built part of it and completed the basic design. The system has a web interface which enables user management, gateway creation etc. The gateway management allows adding either a "local" GSM device or a third party gateway such as bulksms or clickatel. Within the smsLib API, load balancing and cost routing can be set. This allows multiple phones to be connected to the system to increase throughput - very handy. The API also enables specifying sms "handlers" which process incoming SMS's. This may allow some interesting options in managing a server via SMS? Once I'm finished, I'm considering releasing it as open source - It may be useful to someone.