Deanne Barker points out that USA Today, like many other sites will soon be asking readers to answer a survey before getting access to articles.
I know these sites are just trying to make a buck, but I find the surveys annoying and intrusive, especially after I've answered the questions twice already that day.
As a defence to my sanity, I've developed a standard set of answers:
How many classes do you come across named 'SomethingManager'? Any decent sized commercial system seems to have plenty - SessionManager, ConnectionManager, PolicyManager, QueueManager, UrlManager, ConfigurationManager, or even, sadly, EJBManager.
A quick look at the dictionary entry for "manager" and "manage" gives at least ten different meanings - from "to make and keep compliant" through to "to achieve one's purpose". I remember one day when the receptionist briefly retitled herself as Switchboard Manager. The common semantic to all these definitions seem to be a vague "looks after stuff".
This imprecision makes Manager a bad word to use in naming classes. For instance, take a class named "UrlManager" - you cannot tell whether it pool URLs, manipulates URLs or audits the use of them. All the name tells you is that this is not a URL, but it does somehow work with them. On the other hand, the name "UrlBuilder" gives a much better picture of what the class does.
In the Java world, it seems that the "Manager" suffix is thrown around a lot. Almost anywhere you have a class that is responsible in any way for other objects, it automatically gets the Manager label.
"Manager" has come to be a danger signal to me - warning of lack of thought on behalf of the application's designer. It either means (a) that the designer couldn't be bothered thinking of a truly descriptive name, and begs the question, "What else couldn't the designer be bothered with?", or (b) that the designer hadn't carefully thought through the role and responsiblities of this class.[1]
"Manager" can therefore be placed on the list of Words Never To Be Used When Naming Classes. That list in full now reads:
Since I've just banned "Manager", it behooves me to suggest some better alternatives:
Herder
A "Herder" looks after things that are too stupid to look after themselves. Taking the insurance domain as an example, let's say you have a whole bunch of Policy domain objects which your application constructs from multiple datasources. You might have a PolicyHerder to find, store and delete policies across various data sources, to ensure that each Policy is only accessed by one agent at a time and to audit all changes to Policies.
"Shepherd" or "Wrangler" could be used if you'd like to avoid the association with cows.
Bucket
A Bucket is a place to stick stuff when you don't need to hold it.
A situation where you need a bucket is for pooling connections to some external resource. When you want a connection, you take one out of the ConnectionBucket, and when you are finished, you put it back.
"Pool" has a more computer-sciency feel to it, but means the same thing.
Supervisor
A "Supervisor" implies allocating work or checking its progress.
In a sytem handling workflow for users, an object responsible for balancing units of work amongst user queues could properly be called a QueueSupervisor.
And More!
There are plenty of other words to use to describe objects that interact with, coordinate are are responsible for others: Auditor, Gatekeeper, Coordinator, Planner, Home, Utility, Builder all come to mind. The trick is to be succinct and accurate.
So, next time you feel tempted to name a class "XyzManager", pause for a few moments, grab the thesaurus and find exactly the right words for a helpfully descriptive name. You will be making the world a kinder, gentler, more understandable place.
[1]I don't count myself innocent of this particular coding sin.
[2]This is a good list. It suggests that the "TheBloodyManagerObject" is a bad name for a class, and it is right.
Charles makes some interesting points about interviewing programmers. Don't forget to check out the comments - Blake Winton has an interviewer's perspective.
I have had cause to interview programmers over the years. It is both interesting and difficult work.
My favourite set of questions for interviewees starts by asking them to describe a large system that they've worked on before - I pick an appropriate one off their resume - and getting them to draw the system on a white board.
The interviewee gets to decide from which point of view to describe the system. If they ask, I tell them to pick whatever they are most comfortable with. They might describe the system from a business point of view (data flows between user departments, reports, and letters to customers) as a technical architect (hardware, IP networks, J2EE), or as a programmer (class and interaction diagrams), or as something else altogether. This is a good time to see how they answer questions from what may not be their natural perspective (What was the business case for this system? How many classes were there altogether? Who wrote the coding standards?)
After a little bit of probing, and getting about 10 boxes on the whiteboard, I then ask what they thought worked well in that design and what worked poorly. I also ask them what they would do if it were up to them to redesign the system from scratch. The intent of the question is to evaluate their design skills, and whether they think critically about what they are doing.
From this, I start making up my mind about whether they are a thinker, a leader, a starter or a finisher, experienced or new or just along for the ride.
Anyone falsely presenting themselves as being a senior member of the team that worked on that project tends to show their hand by speaking in generalities and not having a strong opinions on specific issues.
Not quite the same as a coding test, but valuable.
I once worked with Stephane, a Frenchman who speaks English better than most natives, because he devotes real effort to learning the language. For instance, he can tell you if you should say "He speaks English better than I" or "He speaks English better than me".
Once though, there was a few weeks when Stephane spoke of the "cows everywhere up the other end of the floor". I thought it was a particularly apt metaphor for kind of problems that typically plague software projects. I could easily imagine the mayhem that would be caused by four or five cows wandering through the cube farm, disturbing developers, surprising guests, eating the pot plants and tripping over power cords.
Eventually, Stephane and I realised a mutual misunderstanding. What I heard as "cows" was Stephane saying "chaos" with an outrageous French accent, thereby rendering his factual statements in accurately poetic manner.
The more I think about it, the more relevant and useful the Cow Metaphor seems. Here is some of the lingo:
And then there are Fridays. Fridays are good because the team traditionally has a symbolic lunch of dead, minced, Burger King cow. Mmmmmm c0w.
Thanks, Stephane.
Moo.
I installed Gentoo Linux over the weekend. Actually, I started on Thursday evening and finished Sunday evening. Installing Gentoo takes a long time.
Gentoo is a source based distribution. This means that you compile everything you run. I started by booting a 40Mb CD image, and following the installation guide set up networking and proceeded to down load and compile everything - kernel, libraries, compiler, logging daemon, X, gnome, alsa, evolution, galeon, open office, eclipse everything.
Did I mention that this takes a long time? Many steps take several hours, the longest was OpenOffice, which kept my computer busy for the afternoon - 4 hours at least. Plan on watching a lot of telly, doing housework, surfing the net using Lynx, even (if you are desperate) go outside into the sunshine.
The result is impressive. Galeon starts up in 6 seconds the first time. After it has been loaded once, I can shut it down and have it up in less than a second. w00t indeed.
A few niggles:
So far, I give Gentoo 8 out of 10, on the provisio that Eclipse can be made to work. If all goes well, I'll be uninstalling Redhat in a week or two.
Being in the middle of installing Gentoo Linux and with not much to do, I turned to the Web for amusement. All I have at this stage of the installation is a bunch of 80x25 consoles, so I fired up the text based browser Lynx.
I'm genuinely impressed at what a good job it does of rendering on a VGA text screen with 16 colours.
The Lynx documentation pointed me at the HTML 3.0 specification. Never heard of HTML 3.0! 2.0, yes. 3.2, yes. But not 3.0. It looks like 3.0 was the draft that the IETF were working on when they handed over responsibility for HTML to the W3C.
My only gripe with Lynx is the user interface for filling out forms. A single wrong key pressed will lose the form for you.
So, while Charles gets into Javascript in a big way, I'm quite enjoying the other end of the technology spectrum.
I wonder what my client's architect would say if I suggested throwing out Javascript and going with a Lynx combatable interface?
One advantage to travelling on the train is that I have lots of good reading time. I've been reading a few different things, including 1 & 2 Samuel.
Quick Summary
1 & 2 Samuel were originally one book. The book is set 1200BC-ish - Samuel is a priest and the last of the judges that God appointed to look after his people, the Israelites. The books of Samuel document the life and times of Israel's first two kings, Saul and David.
Like Genesis and Judges, the book of Samuel is non-stop action. It is so fast that I had to put some effort into maintaining a mental timeline as the book spans about a hundred years of history. The author tends to deal with one plot at a time, although there are several themes that the author returns to time and time again: Gods' holiness, his judgement, his patience and the way he keeps promises.
Noteworthy Bits
There are plenty of good commentaries available on the books of Samuel, so I'll spare you further detail. However, there are lots of memorable things. Here is my list from 1Samuel.
2Samuel is about David's tumultuous reign. David alternately excels and stumbles. The stories of David's taking of Bathsheba and Amnon's rape of his sister Tamar are particularly poignant.
All in all, Samuel is definitely worth a read. Lots to learn about how God dealt with his people in Old Testament times, and lots to ponder about what it means to us in New Testament times.
My darling wife was telling me how much fun she had yesterday at work trying to make words out of the letters of "serendipitous". The group she was running managed 100. I agreed that sounded like fun and immediately set to writing an instant program to find more than her group.
Step 1. Google up a word list and download it:
[alang@homer words]$ wc -l ShortList.txt 36720 ShortList.txt [alang@homer words]$
Step 2. Write program:
# Make words from xreadlines import xreadlines def contains(needle, haystack): t = [] t.extend(haystack) for c in needle: if c in t: t.remove(c) else: return 0 return 1 f = file('ShortList.txt') for word in xreadlines(f): word = word.strip() if len(word) > 4 and \ contains(word, "serendipitous"): print word
Not very pretty, but quick to write.
Step 3. Run it:
[alang@homer words]$ time python words.py | wc -l
521
real 0m0.549s
user 0m0.545s
sys 0m0.004s
[alang@homer words]$
Step 4. Gloat:
I got more than you! 521! And I took less than one second to do it!
If only I would use Python for good rather than evil.
Life sure can be interesting. Here are three samples from the last few days.
One: Almost Getting Killed.
On Thursday morning I was almost killed on the way to work. I was stopped at a set of traffic lights. When the lights went green, I had a little trouble getting my car into first gear and it was an extra second or two before I started the car moving. A split second later something flashed in the corner of my eye and I slammed on the brakes with a screech. The thing that had flashed in the corner of my eye turned out to be a little white Mercedes zooming through the red light on the cross-street.
Now, if I had got the car into gear right away, the little white Mercedes and I would have arrived at the centre of the intersection at the same time. The geometry of the situation was such that I probably wouldn't have seen the other car out of the corner of my eye, too. Would the driver of the Mercedes have seen me? Maybe. But the evidence is that they weren't paying attention.
Two: Meeting Robbie
On Friday evening I met a guy on the train. His name was Robbie. He often travels to spend weekends with his mates. We talked about current affairs (Iraq, cloning) and more generally about relating to coworkers and friends. Robbie likes technology but is a little unsure if it is the right way for the human race to be going. He loves talking to people but is happy for others having fun without him.
Robbie wore sandals, board shorts, a t-shirt and cool sunglasses. He had a neat short haircut and closely-trimmed mutton-chop sideburns. All in all, he looked like a typical, relaxed, young country bloke. Keep that picture in your mind while I tell you how Robbie earns a living.
Robbie's is a funeral director. And I can see that he would be good at it because he combines gentleness and other-person centeredness in a really rare way. This guy knows how to listen. Wish I was like that naturally.
Go Robbie!
Three: A Food Fight at School
My son Connor started school on Tuesday. He is thoroughly enjoying it. Yesterday evening I what was the best thing about school that day.
Connor:The food fight.
Me: When was that?
Connor:At lunchtime.
Me: Were there any teachers around?
Connor:Yes. It was in the classroom.
Me: What did the teacher say?
Connor: She said that we could throw our food at each other instead of eating it, if we wanted to.
I then kissed him goodnight without seeking comment or clarification. Why spoil such a good story?
Static vs Dynamic typing is a great source of controversy. Like many of the other great debates (e.g. where to put the curly braces) there is not a lot of factual support for either side. One notable exception is Lutz Prechelts paper "An empirical comparison of C, C++, Java, Perl, Python, Rexx, and Tcl".
The abstract reads:
Anyway, here is my opinion in a nutshell. Dynamically typed languages do lead to shorter programs. For example, where a Java programmer would typically write something like:
ExpandedChoicePolicyOption expandedChoicePolicyOption
= new ExpandedChoicePolicyOption();
a Python programmer would accomplish the same thing with:
policyOption = ExpandedChoicePolicyOption()
assuming, of course, that they could be persuaded to write insurance applications. (The variable name in Python snippet is shorter on purpose - that's one noticeable differences between typical Java programs and typical Python programs.)
This leads me to the following logic:
Dont ask me to back this up with fact. All I have is personal anecdote and conjecture. On the other hand, Lutz Prechelt does have some solid fact to contribute.
Chris Winters links to Dave Thomas' article on How To Keep Your Job.
It's aimed at programmers, but all technical professionals could learn something from it. Ask me how I'm going with my Pragmatic Investment Plan next month.
Some links for Dawn. Enjoy.
PS: These links are for Dawn only. Everyone else...
Learned musings on possible enhancements to Java took a silly turn today when Charles Miller made several interesting and unique suggestions in the area of programmability. He goes on to give these suggestions the working title of JSR-666.
I was intrigued. A few moments more thought provided plenty of additional fodder for the proposed specification request, and it was dawned on me that this was an Idea Whose Time Has Come.
Here, I collect Charles' initial ruminations together with a few of my own ideas. I will be scouring the web for further, similar notions and certainly welcome reader contributions.
Top Three Components of JSR-666:
import *;
Previously this might have meant import-on-demand from the default package, but I don't think anybody ever wrote it. I boldly assert that no code that anybody wants to keep will be affected by this change. No JVM changes will be required.
throws Clause. Keeping track of exceptions can be another huge pain in the Java programmer's neck. We propose modifying the default behaviour of the Java compiler in the event that the throws clause is not specified on a method declaration.
JSR-666 proposes that an omitted throws clause be treated as though throws Exception had been specified. That is, if no checked exceptions are specified, then the superclass of all checked exceptions is implicitly specified.
This change will have no effect on existing code. No modifications to the JVM are required.
NullPointerException Exceptions. A bugbear of novice Java programmers, NullPointerExceptions will be elimated by JSR-666.
The proposed approach is to remove null from the Java language and to specify that all variables hold a reference to a valid object, of the correct type, at all times.
Several restrictions concerning the creation of arrays will also need to be tightened. For instance, it would no longer be possible to allocate an array of an abstract class, or an array of class without a no-args constructor.
Unrecoverable errors may also occour if variables are accessed before initialisation, as may happen at instance creation and class initialization time.
Some existing Java source code may require minor modification before compilation with a JSR-666 compliant compiler. Most existing Java source code will require major modification in order to function correctly after compilation with a JSR-666 compliant compiler.
TO DO: put together notes on dynamic typing in Java, research making semi-colons optional and explore the possible use of 'begin' and 'end' as synonyms for curly braces.
Ever wonder why God, supposedly in control of the universe, lets it run in such an arbitrary and unfair manner? Ever wonder how a loving God could let this planet get so far out of control? I certainly do.
And I think I have a small part of the answer.
As a parent, I often do things that seem arbitrary and unfair to my children. Sometimes my actions even come across to them as confusing, harsh and hurtful. Here are some examples:
Its easy to see what's happening here. On the one hand, from the boys' of view, my wife and I did horrible things to them. On the other hand, my wife and I did these things because we love our children, and we did these things even though we didn't enjoy doing them.
But our children, with age-limited intelligence and experience, have no way to understand the specific circumstances around each piece of pain that we apparently put their way. Our children must trust that their parents love them and want the best for them, and (by and large) they do.
For me the parallels are this. God likens his relationship to us as a Father to a child. God's ways are mysterious to us. As children, we don't have the intelligence or experience to understand what God does or why he does it. He just asks that we trust that he is doing the best thing, even when it all seems to be out of contol, arbitrary and unfair.
And so I guess it comes down to faith. When I was little, I had faith in my parents. Now it's time to exercise the same faith in my heavenly Father.
Last weekend, I went to see Star Wars: The Magic of Myth tour, which arrived locally after touring the U.S for some time. There is 80 crates worth of really cool stuff on display.
We saw Darth Vader's original costume from episodes IV through VI. When you stand in front of the costume you realise just how tall Darth Vader must have been. (I looked it up later - the actor inside the costume was 6 foot 5in).
Later on in the exhibit I came across Anakin Skywalker's costume from episode II. I found myself thinking:
Gee, Anakin's costume is tall. I wonder if he was as tall as Darth Vader?
Duh.
