Podcasts!

Recently I have been assigned to a project at a company about 50 minutes from where I live. I therefore find myself spending a lot of time in traffic. It is less than ideal.

I can remember a friend telling me how he used to use his traveling time to think and make notes etc, possibly on some kind of voice recorder or something. He was making the most of the time spent commuting - it was even more than the time I currently spend commuting.

I felt that I needed to leverage the time spent commuting. In this regard I discovered podcasts. Now I would concede that in more "advanced" societies, i.e. the First World, there is more familiarity with these kinds of concepts, and better access so I am a little behind the times. Nevertheless they have enriched my commuting experience substantially.

I can now spend the time that I otherwise wasted keeping abreast of the latest developments in the tech world - the podcasts are all tech podcasts.

And for those people that think podcasts are much the same as reading the content - they are not, they are far more entertaining and interesting as you can have dialogue between for instance, a protagonist and an antagonist. Besides, I can't read and drive simultaneously.

The regular podcast I listen to:

• zdnet's podcasts podcast.zdnet.com and specifically the "Dan and David Show". http://blogs.zdnet.com/BTL/wp-rss2.php?cat=12 - this is the one I listen to regularly. It is a very entertaining and informative podcast for keeping up with the latest trends in the tech world.
  

I tried the "Mike Tech Show" but it was far too simple.

If you have any podcasts which I should try, then pass them on.

Google Chat - how do they do that?

Okay, so we know how to submit from the client asynchronously...

The question is, how does google chat do it? For those people that haven't used google chat, it is a web based chat client which behaves just like a normal one.

In other words, if I'm in a chat session with someone I get messages like "Bob is typing", and when Bob finishes typing, then bobs messages comes through. It appears as if the server is initiating communication with the browser! How do they do that?

The exercise started off by wanting to look at how AJAX apps built with google web toolkit submit data to the server - for this I installed a very funky plugin called "firebug". I was looking for something that would enable me to view the xml http requests submitted by the browser and this is exactly what firebug offers, along with a whole bunch of other stuff.

I used firebug on one of my simple gwt apps, and it showed me what I was looking for, then I thought I'd try it on google mail. It wasn't long before I realised how google's chat works.

Very simple to be honest. Nothing profound at all! When you initiate a chat with someone and click enter, it sends that chat message, but also submits another one. This one does not return immediately, but only returns when the user you're chatting with writes something! If it times out, as far as I know, timeout is 90 seconds, then it will receive a "nothing happened" message and then submit another "if you have anything to say put in this bucket" message. In fact, multiple buckets can be submitted in order that there is always one available.

It shouldn't surprise you that this mechanism has also been given a name and it is called "Comet".

Google Web Toolkit - some experience now...

It was with relish that I embarked on putting the google web toolkit through it's paces. In fact, for the first time in long time, I coded for fun on the weekend. The recent addition of a laptop helped in this regard however...

For a long time I have wanted to build a simple database app to help out a local church. It's a simple app to manage a list of people, their particulars and other properties. Now I thought that would be an ideal test bed for the new google web toolkit - how cool would it be to make it a AJAX rich client app that runs in a browser. A familiar "link" would be all that is required. Because it will run in an intranet environment speed was not a consideration.

All in all, I was able to reach a fairly advanced stage, quite quickly. The API is very simple and easy to use. The "hosted" mode helps a lot. There were a couple of anomalies in the compilation of the javascript - you can't go wild with anonymous inner classes, the parser doesn't handle those very well, and there seems to be some conditions on your package names.

All in all, however, for an application of this nature, the google web toolkit is ideal.

I will have to do some work on the back end to get the data to persist, probably going to use flat files and an xml based serialization mechanism. It's very easy however to use stubs for those back end calls - funny how they're termed back end calls, whereas in actual fact they're simple request to an http server. With AJAX and DHTML the client is no longer dumb!

I had something else that I wanted to throw google web toolkit at (I call it "goowit" for short)...

Recently I built a Sudoku puzzle solver in java - complete with funky swing user interface and all - you enter the numbers, click go and it solves it. I was very keen to see if this would port to java script via gwt so that it can be deployed easily on the net. It took me a while to remove all the non gwt supported stuff - there were a lot of dependencies on java API classes not supported by gwt. I thought at one stage that it in fact would not work. In the end, it did, and I was very impressed.

So it was with great excitement that I finally got rid of all the "cannot import" messages on the hosted mode console - be aware that if an import fails it means that that the class has not been successfully translated, probably because it contains unsupported content. Once this was done, I entered my numbers and clicked go. In an instant it solved the puzzle.

Now for the final test, compile to javascript and see how it runs on the browser. This was where my heart sank, it was unacceptably slow. In fact, it probably would have taken about a day to solve one puzzle! The browser's "A script is taking too long" came up even before the first cell was picked!

Something which ran fine in hosted mode (java compiled mode) was far too slow in javascript mode. Now I'm not 100% sure exactly why - is it because the generated code is inefficient or just because job is too big for an interpreted language. I can't say. I think the rule of thumb here and it sounds obvious is to avoid doing heavy duty, complicated and long running processing with javascript. Not only because it may be slow but also because javascript is a single threaded environment and you need that one thread for keeping the gui snappy. Whilst a javascript process is running, the browser is totally non-responsive.

More exciting discoveries await...

Google Web Toolkit… a first look

When I was first exposed to the AJAX technology and how it works at the Sun Tech Days, I thought to myself, why then can't you code in java and get a tool which allows you to "press button for thick client", or "press button for thin client". It would have to be some kind of a cut down version of java because you wouldn't be able to do everything on a thin client than you can do on a thick client.

In a nutshell, this is what Google has done with their google toolkit. It is, like a friend first said to me, "a way to write AJAX applications with standard java code".

They have solved a lot of the problems and what they've come up with is something far more amazing than I was thinking at the Sun Tech Days. especially since, having seen google's solution, the number of issues that I was just plain not aware of are vast.

Let me mention however, that they have not solved the "deploy to thick client" - though in a sense their "hosted" mode is exactly that. I think because that need is in fact not required in any case. There are already API's available for building thick client gui's and besides, practically speaking thick and thin clients are so different that you would not be able to seemlessly deploy to whichever you choose.

Google's Web Toolkit - Summary of usage…

• They have built their own set of gui controls - the functionality of which can be realised in html. If you start using them, and you are familiar with html you will soon see this. They are "wrappers" onto the features of the html controls. They also have some of the familiar layout managers - DockLayout (BorderLayout), FlowLayout, TableLayout and others.
• They "translate" java code into javascript code. This, to be honest, is probably the biggest achievement of the google web toolkit. It is not therefore an AJAX toolkit as such. It is far more than an AJAX toolkit. This feature by itself is amazing. I have a sudoku puzzle solver that I built with a swing gui. I am very keen to see if it will translate into javascript so I can run it on the client (no AJAX). There are some limitations to what can be done, since java is not javascript. They also have a little bit more work to do on the parsing side - if you find that your code is not translating properly then you need to adjust the source code a little (it parses the java source code). The prospect of porting my sudoku solver to javascript by hand is not something I would dream of doing, this way I can see it in javascript, painlessly.
• Handle AJAX calls with standard RPC infrastructure but with additions to make it asynchronous. For someone who's done RPC in any context, a lot of the concepts involved will be familiar.
1. Build the remote interface, build the remote implementation of the interface
2. Build the Asynchronous remote interface - contains every method in the synchronous interface but with call back reference added to each call.
3. The process of calling is…
1. Instantiate the remote interface (on the client).
2. Specify the location of the "server" - in this case it is a servlet which you call.
3. Make the call - when making the call provide an implementation of the AsyncCallBack interface. AJAX familiar people will recognise this concept.

It didn't take me long to write a simple web application in google web toolkit which takes two numbers as input and multiplies them or adds them according to the button that is pushed. When I get a site I can place this kind of content on (zip files) I will put it there so that people can acquire it. For now, if you're interested, email me and I'll pass it on.

I'm using eclipse and created two run configurations for GWT compile and GWT run. When they mean compile however, what is interesting is that they're converting the java code into javascript code. Going from one language to another! Believe me, making sense of the compiled stuff is impossible - they've obfuscated it quite a lot and rightly so.

The payload can be fairly big - a fairly simple app I'm busy with comes to 82K. It might sound like a lot, but when you consider that there is absolutely no library code on the platform on which it is running it puts it into perspective. There is no big JVM required, the client only needs a browser.

All in all, it is an amazing tool. I'm not sure if it is ready to write business applications on - but I do think that day will come.

Google and AJAX - Wow!

A friend pointed out to me that google has recently released a toolkit for ajax, and how you can simply code in java and the toolkit will do the work of web enabling it. That looks absolutely amazing! I can't wait to try it out.

Thanks Trevor.

Build Ajax apps in the java language

Eclipse and Netbeans... which is it going to be?

Having attended the Sun tech days last week I was exposed for the first time to netbeans. Now it is my bad that I haven't investigated the merits of this very impressive IDE before, for from what I saw there, it is very impressive.

In fact, I would say that it is so good, that it is insane to give it away for free. Some of the industrial strength you-typically-only-get-them-if-you-pay-for-them features that it has are an awesome profiler as well as a collaboration suite that is just amazing. That suite along with some VOIP installation and you never have to get up and go to the other developers PC! In fact, you can probably do remote pair programming.

But what are the differences between Eclipse and Netbeans and why so much bad love between the two camps.

I think the initial bad love started when IBM decided to eschew swing and build their own gui API. Swing was slow and just not "nice". IBM's perspective was that having a GUI look and feel that resembled the OS's native gui API was preferable, and I can see there point of view. Swing, with all it's progress that has most definitely made, does not look as "nice" as the native gui API's (windows and GTK).

So I set about giving netbeans run with gusto. It wasn't long however, before my initial enthusiasm was repressed. Having been used to eclipse's rich set of refactoring and code productivity tools I frequently found myself frustrated that a samilar level of functionality is not available in nebeans. For instance, Netbeans does not have the following quick fixes: "create class" and "create interface".

Another one of Sun's gripes on Eclipse is that they use a non standard compiler. Sun wants them to use "javac" which they don't. I now understand why. The java builder (eclipse speak) is a much more powerful tool as it is far more "on the fly" than the java one. This is because it holds dependency graphs so that whenever a change is made all the files which depend on that change are also recompiled. In netbeans the appearance of an error is not immediate. The javac uses very basic "is the source file newer than the class file" to ascertain the need for a recompile.

I could continue... the debugger, is also not half as fully functional as the netbeans debugger.

In conclusion - I would agree that netbeans is a worthy competitor, the profiler, gui builder and collaborative tools are world class. However, developers spend far more time actually doing the work of editing and compiling, and this is where netbeans runs a distant second to eclipse.

Sun Tech Days...

I had the privilege, last week, of attending the Sun Tech Days. It was the first time tech days were held in South Africa, and it was worth the wait. It was two days jam packed with great ideas, great collaboration, lots of learning, lots of sharing, lots of excitement, lots of great food (The food was particularly good) and lots of free stuff (managed to score 2 t-shirts, a bouncy ball, a java mascot as well as a sun tog bag and id tag in addition to the netbeans book I won for answering a question!).

Over the next few days I shall be blogging on some of the details on the conference. For now I'll provide short synopsis.

The first day opened with a keynote from James Gosling. I must admit, it was great to see the so called "Father of Java" in the flesh! Nice to know these people are actually flesh and blood like you and me. His opening key note was not amazing but did provide a number of pointers as to Sun's thinking on java.

The day continued with tech sessions on various technologies and infrastructures, some of the key technologies touted at the convention were AJAX, BPEL (business process execution language), Netbeans - a world class IDE and EJB3.

Sun has a lot of experience running these days and I must admit, it showed. The days were well organised and ran smoothly, the speakers were interesting and for the most part excited about what they were talking about. There were exceptions to this, though these speakers were without exception, non sun people.

The sessions were generally, very tech oriented - one techie talking to another techie - (no marketing blurb) and though they were at times a little basic, necessarily so, they had enough content to keep the familiar parties, such as myself, happy. I'm sure if I was totally unfamiliar with the technology I would have found the basics to be very interesting.

Johannesburg is an amazing place - Sandton must have the largest concentration of head offices anywhere in the country.

All in all, the conference was a success. I'm very glad that I was able to go, thanks to my company for sponsoring the trip. Though the value they gained out of it was far more than the money they put in.

Too many classes?

This is a post which was originally posted last year, under my other blog thoughts for life. I'm reposting it here because this is where it actually belongs.

I can remember, when I was in under grad, my brother said to me that when you're stuck on a programming problem then just add another class (the word class in this article is used to refer to interfaces and abstract classes as well as concrete classes).

At the time I don't think he or I understood how profound that statement is. How often does one come to code and found just two classes that do too many things, and then scratch ones head trying to figure out what's going on.

That statement is borne out of the notion that having lots of classes is a good thing.

Let's take an example from real life...

Analogy from the Real World
Imagine your motor car's engine was made up of 5 parts. When the starter motor breaks you have to remove the water pump as well because they're both from the same part. So you introduce potential for problems. Maybe the mechanic does not re-install the water pump properly, and so a problem that was just the starter motor now takes longer, with more risk because you cannot just remove the starter motor.

Transferring the analogy into the software design arena and you soon realise that the problems are far worse. A class which does many things which requires one change, there is an even larger risk factor than the engine analogy, because of the potential complexity software component.

Example
To give you an example, a certain component of an application was particularly inefficient and for want of a better word, was just plain bad. I was tasked with upgrading (rewriting) it. When I was finished, the number of classes was about 4 - 5 times higher then in the previous version.

Why
Here are some advantages of having many classes...

1. Isolation of Bugs: In a system with many small classes, you have many relatively independent sub-systems all working together. If there is a problem, or a bug, chances are the bug will be isolated to one class, and only that class will have to change.
2. Flexible to Change: I can remember times when I've had to make changes to an already built system and I spend a good part of the time figuring out how the current system works because the current system is comprised of very few classes. If the system were comprised of many small classes, then I would only have to understand many simple, small pieces of code. I may even find that the piece of functionality where the change applies is wrapped in one class already, and that class may even be named appropriately.
3. Ease of Comprehension: Having many classes means you need less documentation. If you have one method which is rather large and you break it down into maybe two/three methods, and you name the methods appropriately then the method names describe what they do and the play the role that code comments would play in the larger method. The same is true when you break a system down into many classes.
4. Potential for Good Design. I have found that when a system consists of many classes, chances are, the design is good. The number of classes would however, have to be relevant to the complexity involved, and this relationship is often an exponential one. As the complexity increases, so the number of classes increases even more. It is only by experience that one gets a feel for how many classes are appropriate to perform a particular job, but by and large, if the complexity is high and the number of classes is low, then the design is poor. If the number of classes is high this does not necessarily mean the design is good, but it is one of the indications.

I've heard rumours that in the past people were reluctant to have many classes with many methods because of the overheads of method calls and class intanstiation. The rationale for this consideration has been removed by efficiencies in modern compilers, virtual machines and the speed of hardware. Yes, you do incur an overhead when calling a method and instantiating a class, but, in general practice, I have found this to be negligible. Time and time again, design well, and then optimise rings true.

Real World Example
Why does this work? Well, it won't work if you just divide your large class into smaller classes in a naive way. If you were to divide a class into smaller pieces but still achieve the same degree of coupling between the classes as was previously the case, then you haven't achieved much. It is far more valuable if when dividing the class into smaller ones, the coupling level between the created classes is fairly low. In other words, the various classes do have a semblance of meaning outside of their context.

Take for example the problem that says

1. Read in a file
2. Count the number of words in the file

A naive approach would put all the functionality into one class which will read the file in and then count the words by counting the number of spaces. This would require one class.

A far more funky approach would be to separate the reading of the file from the counting, and if this is done with a low degree of coupling (via an interface) then changing the source location from a file to a string would be a simple process. If the counting is also done in its own class, then you could also change that algorithm to count say the letter 'a' without affecting the way it sources the file.

The classes that would be requried would be

• Interface to communicate with the data source
• Interface/abstract class to communiate with the counter
• Concrete implementation of the file sourcer to retrieve it from a file
• Concrete implementation of the counter to count spaces/white space
• Controller to hook the two up

We've gone from 1 class to 5 classes in a very short space of time.

Conclusion
So when you code, do not be afraid to make many classes.

And when you're stuck, just add another class.

Get Perpendicular!

This is most hilarious...

Slashdot reports that "Hitachi has recently announced perpendicular recording with their harddrives".

That is good news because it means hard drives can get even smaller.

That is not the funny bit however, they've also developed a "music video" to go with it....

Absolutely hilarious!

For more information on perpendicular recording see the wikipedia article on it.

EJB JDO, what's going on

I've read with interest the discussion on the go between the JDO camp and EJB camp.

If you're not familiar with it, I'll give you a brief background.

EJB, more specifically "entity beans" is a persistence framework. JDO (java data objects) is also a persistence framework. The Entity beans framework is part of the broader EJB spec, currently in version 3.0. JDO is a "stand alone" specification in a similar vein to EJB in that Sun publishes the specification and a vendor then implements that specification and sells it on the market. JDO can be used in a desktop app, a web app or in an application server. Entity beans requires an application server to work and comes with significant overhead because of this.

I have used JDO extensively and have recently started looking at EJB in its version 2 guise. To be honest, the learning curve for Entity Beans is huge! It would take a developer twice if not three times as long to be useful under Entity beans than under JDO. I know because I was new to JDO at one stage and can remember how long it took me to learn. The developer would need to learn a lot of not specificaly persistence related stuff like session beans and local/remote interfaces.

There have been a number of discussions on the pros and cons of JDO against EJB. What makes the discussion even more interesting is that the latest EJB 3.0 spec, from what I've read, is unashamedly Hibernate! There are a number of conspiracy theories floating around as to why the EJB expert group went that way. The plot thickens when you consider that the JDO 2.0 specification is still in the process of being ratified - it has been rejected once already.

One of the loudest shouts in the community has been "We don't want two persistence frameworks!". My response to that is "why not?". It gives the user choice, it increases quality via increasing competition, it promotes flexibility. I say bring on alternatives.

This is the rationale behind the push on EJB 3.0. It seems that somehow this specification has won the day and that JDO has been abandoned. The primary reason for this I think is that because of the fact that Entity beans require an application server to work, the large vendors, Oracle, BEA, IBM, JBoss (who own hibernate btw), have supported the EJB specification because that way they protect their market.

To utilise JDO you do not need a heavyweight, complex and expensive application server.

The other apparent reason for the support of hibernate via EJB 3.0 entity beans is that hibernate uses standard sql as its query language. This not only locks the user into the underlying database but apparently affords the developer a seamless cross-over. I do not see how this can be seamless when the developer has to learn about all the overhead that comes with running on an application server.

I had to learn the JDO QL (JDO Query Language), and the syntax is a lot cleaner than SQL. JDOQL is far closer to object space than SQL is. It is just a more obvious and better fit when it comes to the object space. The key here is that it is far easier for an OO programmer to learn JDOQL than it is for an OO programmer to learn SQL. Which is why I do not buy the "they'll have to learn a new query language" rhetoric.

Furthermore, there is no reason why you can't use JDO with an application server. Again, surprise surprise, you have choice.

Reading various articles on the subject might indicate that JDO is dead, well, I was pleasantly surprised to note that the final round of voting on the JDO 2 spec is imminent. See jcp 243.
I'm holding thumbs for its adoption.

It probably won't be ratified however; based on the voting up till now a betting man would not put money on it.

Ultimately, I think that Apache opinion is correct and the most democratic and "broad based". They have always maintained "Let The Market Decide!". The specification is good enough, the implementations are of sufficient quality that the computing industry will use it. Proof of this is that a number of companies have already implemented the JDO 2.0 specification without it's ratification! JDO fulfills important requirements quite efficiently. In my work place we have used it for two web applications so far, and have seen no reason to go the Application server route.

Let's hear it one more time, Let the Market Decide!

btw, if you have an opinion, then tell me what you think...

Java on the up...

Recently, anecdotal evidence has suggested to me that java's influence has been on the wane... Especially given the view in Cape Town, South Africa - South Africa has traditionally been a microsoft land, while in other countries (mostly first world), microsoft is not so strong.

However, according to Tiobe Programming Commity Index, java is the most popular programming language on the internet, not only that, but java also won the TIOBE Programming Language of 2005 award. Go Java!

Based on more anecdotal evidence is done seem as if microsoft is stronger in the developing world than in the non developing world. I do not think that the battle is between microsoft and java but between closed source proprietary and open source public domain. Open source thrives in environments where you have a high number of educated people as well as a high number of people who have the time to devote to developing open source applications. It stands to reason that if you have a high number of people developing open source applications in their spare time, those same people are going to push the adoption of open source in their day jobs, thereby increasing the popularity of open source, and thus java. It might also be true that open source requires a sufficiently large programming population in order to develop, another reason why java is probably more popular in first world countries.

You may be asking why open source does not fit with VB and C# - the answer is simple. You can't run an open source operating system and code in C#/VB. Okay, before you argue that there are IDE's where this is possible, they are not in the main stream developer market.

Eclipse RCP - have got to see this...

Before I point you to the merits of the Eclipse RCP I'll just digress for a moment and say Happy New Year to all those who deem the new year to be on first of January. I hope 2006 brings many epiphanies for you.

But like I was saying, the RCP is a stunning platform to develop on top of. Every piece of your application is packaged as a plugin so modularising your app is simple. On top of that, you get advanced update and management capability out of the box.

If you need a quick demonstration of its power, then take a look at EclipseZone - Why You Should Use Eclipse RCP (In 10 Minutes).

It'll prove to you the merits of developing on the eclipse RCP platform better than any words could.

btw, the link embeds a short movie clip to walk you through the process of creating a RCP app with eclipse. Unfortunately, it does not work in firefox. However, there is a plugin which with one click allows you to open a site in IE. It changes the current tab to an IE tab. Seemless IE integration! A very useful ie plugin.

What is an object supposed to know?

I must apologies for the long deley between posts, unfortunately, I have just battled to come up with anything interesting to write. Hopefully this post will change this.

I have recently started investigating Enterprise Java Beans. It has been both interesting and frustrating. Entity beans I find to be hugely complex, all the local/remote/home/bean concepts are to my mind, having used JDO extensively, rather complex and difficult to grasp. Let's hope EJB 3.0 is all I'm hoping it will be...

Anyway, back to the matter in hand.

I was reminded of the relationship between what an object does and what an object knows. These two concepts are inextricably linked and should be carefully considered. To take an example from the real world - there are often times when knowledge is specific to the role of that person/entity. The classic - need to know basis. As an employee of a company I am given enough information to perform my set tasks, and no more. There is certain pieces of information which I should not be provided with, because they involve knowledge that is outside of the ambit of my responsibility.

The other scenario where knowledge is important is when I need to find out something. I should immediately be able to deduce the person or entity which possesses that knowledge. The knowledge required should be congruent with the person or entity who possesses that knowledge. It would be inappropriate for the cleaning staff to know the bank account details of the company for instance.

Now let's bring out thoughts into the object space. Like I was saying, I've recently started looking at J2ee and Enterprise Java beans. I'm using the Eclipse Web tools project to do the development. When you request an enterprise bean you have to do a JNDI lookup in order to locate that bean - you provide it with a name, and it returns a bean. When eclipse sets up a bean for you it creates a Util class which knows how to lookup the bean (one util class per bean). Thus this util class not only has the behaviour to lookup the bean but also the knowledge.

Personally, I do not believe a class that uses a bean should be required to know the location of the bean. The reason for this is that a class that uses a bean has a functional job. Imagine you create a class to lookup employee details. This class calls an EJB to achieve this end. The directory information require to locate the bean has little to do with the job which the class is assigned. Thus that knowledge of where the bean is should not be stored in the bean. The class kinda thinks, all I want is a hook onto this bean, I don't want to know where it is, why do I care?

The thing to remember is that a class is defined by its behaviour as well as its knowledge. In other words, looking at the data which a class contains, be it static or dynamic, is a valid and important mechanism for determining what the class does. If a class contains the database connection url, then it clearly must be responsible for connecting to the database. Thus it could easily have two responsibilities (bad idea), some other responsibility which requires a database connection.

One of the advantages of providing classes with data on a strictly need to know basis is that duplication is reduced. If I have a class whose sole responsibility is to acquire a handle onto an EJB, if I wish to change the lookup information for that bean I only have to change it in one place. This is because only one class "knows" that information. The other classes are not privy to that information, why should they be?

In light of this there should probably be more objects in our code, with potentially more static methods as well. On the one project I worked on I implement a help system. I created a class with a number of static methods which contained the code for hooking and displaying the help. I effectively created a help "service". The class was full of static methods - changing the help system was as easy as changing this class.

Google and advertising...

When google made their first steps into advertising they took the view hitherto not taken too seriously. While the rest of the industry was using flash based animated adds, popups and even rather intrusive "pop-backs" (popups which appear when you close your browser windows), they eschewed those and went for POTA's (plain old text adds).

Their text based entry into advertising is discussed at How Google tamed ads on the wild, wild Web.

The article makes the point that while they were entering the market and sticking to text adds, some of the other advertisers were convinced that they would have to move to animated, flash based adverts eventually.

However, I would like to suggest that by going the text based route, restricting the text to a specific length, and make the adds context sensitive, google has succeeded in taking web advertising from a necessary evil, something you put up with, to a valuable and relevant part of an everyday web experience.

It is not suprise therefore that google is the only company which is making a lot of money from web based advertising. They saw the good in amongst the bad, they knew there was money to be made in web advertising, only if it's done right.

I find myself going to a web site now and getting severely irritated by "flash" (excuse the pun). A collection of horrible animated adverts that just plain make me mad. Those are the ones I want to turn off, they are the ones that distract me and make my browsing experience particularly unpleasant.

I much prefer going to a page which does not have animated or even picture based adverts.

Personally, I feel that google has been so successful at making text based ads fashionable that the consumer will start demanding that they are the only kind of ads that they see.

Geek and Beautiful do go together...

I stumbled on this site via slash dot I think, and I thought it was just too cool.

Check out The Geek Gorgeous Calendar featuring Women in Technology

"The calendar showcases young ladies who are not only beautiful and stylish, but can also fix your computer, normalize your databases, discuss the advantages of polymorphism, and beat you at Doom."

I think it's a great idea. Besides, who says you can't have both?

Best of What's new 2005

Check out popular science's Best of what's new 2005

Those pesky Gui Designers...

My first introduction to a heavy weight java IDE was JBuilder. I have to admit, I do not remember those days with an fondness.

The application was in a nutshell, a data maintenance gui. I can remember rolling up my sleeves and fighting with the clumsy and just plain irritating gui designer.

Nowadays I have an intense disliking for the concept of automated gui design. I feel that coding it manually is a far more efficient and liberating approach to gui design. As an aside, I did experiment a little with gui design on the SWT API and saw an awful lot of potential there for a gui designer that I might be persuaded to use.

I think my eschewing of gui designers is both because of the lack of control and because I disliked the code that gui designers produced. Which is why a salute Charles Petzold and his article Does Visual Studio Rot the Mind?

He fully endorse everything he says on the subject and highly recommend that you read his words on automated gui design.

I'm also sure all the java programmers out there, will have a quite chuckle to themselves when they read about Microsoft plans with Avalon about how they're going to introduce layout managers (sic).

Object Oriented Design?

When Object oriented design first came on the scene there was a great deal of excitement. One of the early mantra's was that with the OO programming paradigm you can create complex data types which not only contains data but also the behaviour associated with that data.

The most obvious example of this is in the case of the Vector data structure. The standard vector consists of three scalars, x, y and z, and as my ever persistent matric science teacher was at pains to point out, "has magnitude and direction".

With OO you can create a data structure which contains the 3 scalars and a collection of methods in the same context as the scalars to allow the vector interact with other vectors. Addition, multiplication and dot product etc.

However, I'm not so sure if this is the key to the success of OO, nor that this paradigm should be ubiquitously applied.

It's probably fair to say that the majority of data types that are built in modern programming do not have such a tight coupling between their behaviour and their data and therefore this encapsulation should, in most circumstances, not take place.

In the case of the vector, it is in fact defined by its behaviour; the vector is an entity which has this set of data and behaves in this way. The same cannot be said about a Person object for instance.

Let's change tack for a second and look at what would happen if we do enapsulate the behaviour of an object with its data.

Consider a person object, it contains the name, surname, birthday etc of a Person. If we place behaviour for the person object into the person object it becomes prohibitively difficult to reuse that behaviour, for a different person object for instance. If we wish to use that behaviour we have go via the Person object itself. It also means that we cannot change the behaviour without affecting the data.

It is therefore better to create a data object which only contains the data associated with the Person and then another object which contains the behaviour associated with the person.

So then you might be asking, doesn't that make the data object little more than a struct, a concept which was part of the procedural programming paradigm? You would be right, but then that begs the question, why is the OO paradigm better?

The key to the OO paradigm is not that data can be associated with it's behaviour but that behaviour can be treated as a variable. The strength of a variable is that it is exactly that, it can change, it can be assigned and it can therefore be moved around. Now with the OO model we can pass behaviour around like a variable is passed around. With the introduction of objects, which have behaviour (methods), we can now treat behaviour like we would treat a string for example. We can pass it in as a parameter for a method, we can change the behaviour as easily as changing a variables value.

How is this achieved? It is achieved by something that was formally introduced in Java, the "interface". C++ fully supported interfaces in their "abstract classes with no implemented methods" guise, java however, created a new class type. Interfaces are exactly that, abstract classes with no implemented methods. In java, though it does not have multiple inheritance, there is no limit on the number of interfaces a class can implement.

If you write an object which contains functionality associated with a Person object then you would create an interface with which this behaviour would know how to talk. Your person object would then implement that interface, and by so doing, would be able to be acted upon by the functionality you have created.

Whether to separate behaviour from data is a decision that should always be looked at. Conjoining behaviour with data should only be done when the behaviour and data are tightly coupled. Making behaviour mobile is arguably the key advantage of the OO approach, and one that should be leveraged as much as possible.

Only do it once...

When it comes to programming, one of my most recent mantras is to "only do it once".

Whenever I solve a problem, whatever that problem might be, I must only solve the problem once and then re-use that solution in future. By doing this you programs become many mini programs.

I can remember one of the first things I learnt, even when I still at school, about computer programs is that it's input, process, output. By employing this approach you are configuring alreaday written components, supplying them with input data and then firing them off.

A naive example would be, you have a square root to solve, you write a square route method, make it statically available (it is a stateless algorithm) and you never have to solve the square route problem again.

It has input - the input parameter you want to find the square root, it has processing, calculate the square root and it has result, the calculated square root.

Now on my current project, we receive data from a back end stored in a Map. We have to move that data into a data object. The populate mechanism for doing this would be to write something like...

vo.setStartDate((String)map.get("START_DATE"));
vo.setAmount((String)map.get("AMOUNT"));
vo.setDuration((String)map.get("DURATION"));
vo.setElecTransID((String)map.get("ELEC_TRANS_ID"));
vo.setInitialSequence((String)map.get("INITIAL_SUB_SEQ"));
vo.setNodeName((String)map.get("NODE_NAME"));
vo.setProviderID((String)map.get("PROVIDER_ID"));
vo.setRechargeMethod((String)map.get("RECHARGE_METHOD"));
vo.setTransactionID((String)map.get("TRANSACTION_ID"));
vo.setValueAddedInformation((String)map.get("VALUE_ADD_INFO"));
vo.setVoucherBatchNumber((String)map.get("VOUCHER_BATCH_NO"));
vo.setVoucherEndDate((String)map.get("VOUNCHER_END_DATE"));
vo.setVoucherNumber((String)map.get("VOUCHER_NO"));
vo.setVoucherPin((String)map.get("VOUCHER_PIN"));

Now, as you can see, for every different data object I receive from the back end, I have to do something similar to this.

However, that means I have to solve the same problem many times. If I apply the "only do it once, input process output" paradigm then I write a re-usable utility that will do the work for me. I supply it input parameters and configuration parameters, and it does the work of copying the data from the map to the data object.

In this case the input parameter is the map. The configuration parameter (this is a kind of input parameter) is the mapping between the key names in the map and the property names in the data object. The other input parameter would be the data object.

funkyMechanism(map, <ObjecToMapMapper> , dataObject)

So map to data object would contain...
START_DATE = startDate
AMOUNT = amount
etc...

In order to solve this problem in this way, reflection was used. There are ways to solve it using a similar input processing output paradigm, they're just not as elegant.

When programming try your best to only ever solve a problem once, and then re-use that solution. Think of instances where you can encapsulate a solution into input - processing - output. You'll find you code a lot less, your programs will be more robust and will have more of a Wow factor!

Swing and the client...

For the last week and a half I have been on a java gui project... I had to wipe away the cob webs entangled in my swing knowledge.

I read somewhere months ago about how Java's uptake ont he client was not as much as could be expected. I cannot remember the answer to this question. Having spent the last week and half building java guis, I'm pretty sure I know why.

Fundamental to building a gui is the laying out of gui components. Java eschews the absolute positioning and sizing of a gui in favour of the concept of a layout manager. This is a laudable goal, and I understand why they went this route. I agree with it to be honest. In a multi platform environment you do not know how an absolute size location on one platform will appear on another. What about when the user wishes to resize? What happens then when using the abolute system. What if you want to let the user resize? Proof of this is evident in that there is no XYLayout provided in java!

However, laying out components with the managers provided is a black art. To get the gui to look exactly the way you want it takes a lot of hair pulling. Just to get a component to move to the left by 5 points can sometimes take up to 2 hours. Just to get a gui to resize in the way you desire could take half a day.

I start building a simple gui, using one of the simpler layout managers. Eventually, the gui just won't work, and I have to use GridBagLayout. As far as I'm concerned, this is overkill, but I don't have any choice. I'd rather _not_ use it, but what can you do?

It does not have to be this way.

I have used the SWT Formlayout and find it GREAT! I wish that someone would be so kind as to port the SWT Formlayout to Swing. I have taken a short look at the java FormLayout (jGoodies). I will consider that manager and the Table Layout manager. Maybe they will work better.