Thursday, November 27, 2003

PATTERNS: knit one, pearl one

In books like the racy The Struts Framework, you will often come across stuff like:

"The ActionServlet represents the Controller in the MVC design pattern. Additionally, the ActionServlet implements both the Front Controller and the Singleton pattern"

If you havn't a clue what this man is talking about, then you need to get into design patterns. Gamma et al describe them as:

"A design pattern systematically names, motivates, and explains a general design that addresses a recurring design problem in object-oriented systems. It describes the problem, the solution, when to apply the solution, and its consequences. It also gives implementation hints and examples. The solution is a general arrangement of objects and classes that solve the problem. The solution is customized and implemented to solve the problem in a particular context."

For a brilliant and very readable introduction to patterns i'd reccomend, Java Design Patterns - A Tutorial. Equally brilliant from a J2EE perspective are: Core J2EE patterns and Patterns of Enterprise Application Architecture.

If your feeling keen, you could attempt the seminal work: Design Patterns by the Gang of Four. This is a bit more hard work (all the examples are in C++) but rewarding in a slightly pervy computer-science-tanktop kind of way.

Finally, if you arrived here by mistake and are thinking "who this pompous git showing off about his dull computer books" perhaps you'd be better of with Brenda's crayon scribble pullover.

Wednesday, November 26, 2003

Double Computing

Just checked my timetable and it appears we have double computing again this afternoon. The really sad thing is that we are going to have it again tomorrow morning!

Sat at the back with Pants. He reckons if I let him see my Lotusscript then he'll let me have one of his refreshers.


Fold to live, live to fold

My folding bicycle "Lucille" has returned from dry dock. Thing is, you either have style or you don't.

WSAD: Of debugging and other daring do.

WSAD, or as I heard a Blue Meanie pronounce it "Wussad", is a giant champion sumo wrestler as software goes. It needs a minimum of 512mb RAM to run, but probably a hell of a lot more. Needless to say, it is far too big and hairy for my effeminate laptop.

Still, that aside, here is a small note on its debugging capabilities, which I have been playing with recently (a cry for help?). Rather than dribble on in any great detail, I shall just point out groovy bits that you don't get with Domino Designer.

  • Run to Line: You can simply stick your cursor in the source, right click and execute "Run to line". This, as you would imagine just jumps to that line. I realise you could just add more breakpoints but a nice touch.

  • Viewing variables: when the debugger is running you can hover over a variable name in the code and a popup window will appear showing the value. This works for simple variables and it even shows the javadoc if there is any. For objects, there is a variable window where you can expand and view all member variables etc.

  • Display View: In the debugger you can open the display view which enables you to evaluate java expressions. For instance you could type in a variable name (name) and add something to it (name + " hello"), highlight and right click and the result is displayed "Spuggy hello". Furthermore, you can change the value of variables by executing assignment expressions in the display view (name = "Blue Meanie"). These values will be used through the rest of the executing code.

  • Hit Count Breakpoints: Add a breakpint and edit its properties. The hit point allows you to state how many times you want the breakpoint to be passed before suspend execution.

  • Logic condition Breakpoints: Similar to the hit count but suspends when a particular expression is reached(name.equals("spuggy")

  • Exception Breakpoints: Exception breakpoint are like being able to say "jump into the degugger when Object not set happens". This feature allows you to select an exception from a list and add it to your breakpoints view. Anytime this exception is thrown the debugger will susspend

  • The Scapbook: Not officially part of the debugger but a feature that allows you to quickly type in code to experiment with, rather than entering straight into the source and waiting for big compiles.

  • Hot code replace: This feature enables you to fix the buggy code there and then, rather than closing the debugger down.

I thank you.

Monday, November 24, 2003

APACHE: Enabling Server Side Includes

One down side of using blogger, is that you are denied the near orgasmic pleasure of producing your blog in bloody Lotus Domino. I realise I have the opportunity of using one of the many fabulous free Domino blog templates, but ... well I just can't be arsed. I wanted to have fun, sort of.

Anyhow, to have a link section on the left hand side (and other stuff) I decided to use server side includes. This involved:

1. Creating a .htaccess file and shoving it on my web server:

# J2ME Stuff

AddType text/ jad
AddType application/java-archive jar

# Server side includes

AddType text/html .htm
AddHandler server-parsed .htm

2. Adding the includes to my blogger template and associated files like this:
<!--#include virtual="/links.htm" -->

Bit of fannying about in places but largely painless.

P.S I briefly entertained using XML and XSLT but became nervous of the browser support. Cowardy Custard.

Sunday, November 23, 2003

J2EE: Of packages and script libraries

Packages are away of organising you code in java, just the same as script libraries in Domino. The rather dinky Elements of java style states:

"Place types that are commonly used changed, and released together; or mutually dependent on each other; into the same package."

Examples being:

Calendars Dates and Times
Points and polygons etc etc

They go on to give even more advice on using packages to isolate volatile classes; making sure you are careful about dependencies between packages; and using packages as the effective unit of release (rather than individual classes).

Its all rip roaring stuff (really?). Thing is how do they look in real life? It's all very well to bang on about polygons and circles, but I can't remember the last bit of code I wrote that needed any. That's a lie actually, I did write a program in basic in 1983 called the "Purple poo eater" that needed a circle, but that's another story.

Anyhow, whats a real world example of packages? In the extraordinarily absorbing Enterprise Programming with websphere they give a good example of packaging in J2EE application.

The packages are based on the architectural layer so the names could be:

  • domain: business logic stuff

  • mediator:mediator classes

  • panel: panels in presentation layer classes.

  • system: system classes used to provide services to all layers

  • testscripts: testscripts used to drive the domain logic

  • mapping: mapping layer classes, that is mapping between objects and a relational back end database

  • controller: controller layer

  • applet: applets stupid

  • frame: frames defined for standalone applications

  • util: utility classes independent of any layer

Following this convention, the packages for a simple J2EE app could be:
  • com.spuggy.domain

  • com.spuggy.servlet

  • com.spuggy.mediator

  • com.spuggy.system

  • com.spuggy.util

  • com.spuggy.testscript

Finally it's worth mentioning that Elements of java style is co-authored by the fantastically named Greg Bumgardner. I tried to search google to find a link to him, and by accident stumbled on the legendary Rusty Bumgardner. Go Rusty.

This page is powered by Blogger. Isn't yours?