start your journey with a Lean coach that also happens to know intimately what software development is all aboutThough it seems to come as a shock to some that such coaches actually want paying! ;-)
20 May 2010
Healthy Software Projects
Love this little gem on eXtreme Programming: eXtreme Pill: Increase the odds of a lasting, healthy software project
18 May 2010
The Way You (Probably) Use Subversion is Just Wrong
Trying to learn Hg (Take 2) I learned something about Subversion: it seems that many people are using it all wrong!
Prompted by a conversation last week with Brian which touched on Subversion and Git, I decided to have another go at grokking distributed version control. I confess that I'm probably hopelessly brain-damaged on this score; I can't help it: I started out with version control systems in the days of SCCS, graduated to RCS, was forced to deal with the abomination that was PVCS, migrated to CVS, and have largely been reasonably OK (though not ecstatically happy) with Subversion for the past several years and a half. So I can't really be blamed for my difficulties getting to grips with distributed version control, can I? I learned all I know about the subject back in the Dark Ages.
But, hey! I'm a distributed worker kind of guy. I'm sure I can figure this out, even at my advanced age.
Rather than tackle the Swiss Army Chainsaw that is Git, I thought I'd give Mercurial a second go. I lucked into Spolsky's HgInit tutorial which seems a lot more approachable than other tutorials I've seen to date, and a lot shorter than The Mercurial Book. Almost immediately I ran into a passage that stopped me short with the thought, "If this is how people are using Subversion, no wonder they want to move onto something better!"
Joel on Subversion
Wrong. All wrong!
As luck would have it I was discussing repository-management strategies just last week with a client's (new) development team, and suggesting that they use a much more aggressive strategy than they've ever seen before: Multiple checkins per day by every developer. Maybe go so far as to tie the "File-Save" key to "checkin". Anytime a developer does not make a checkin for 2 days in a row there's almost certainly a problem!
How do we achieve this without the tears and craziness described by Spolsky? Simple! Have every developer working in their own private branch. Or even flipping between a variety of private branches as they switch between tasks. (Yes, I know its not the most productive way to work, but sometimes we have to respond to demands from the outside world, so we do have to take the hit of task-switching.)
I suggested a structure where each developer simply gets a private piece of the repository to work in. Anything that's broken in there is your own problem, but doesn't affect anybody else on the team. When you're satisfied that your branch won't break the world you're ready to merge back to the main development line and integrate your work with your colleagues'. And yes, then you might have some merge conflicts, but I don't really see how any version control system can avoid this; you fix the conflicts and 'Lo! the build is intact. This does imply, though, that you want to merge quite frequently. At least every day or two. Or every time your private branch builds and tests clean. Or maybe just builds clean. All depends on your team - team size, maturity, process-maturity, personal temperaments,... One must study this very hard.
I suppose that the hangups about branching and merging come from the days of CVS, where branching was really, really expensive, and merging really, really difficult. Admittedly, too, earlier versions of Subversion were also not too hot on the merge side of things. (Though I guess it is still work-in-progress and we may yet see some improvements there.)
In recent times I have been using Subversion branches very aggressively. Frequently I'll find myself flipping between as many as 6 or 8 branches on related modules, merging them, abandoning them,... and this is on a one-man project! It means that I have to use branch-names that are pretty long and descriptive, otherwise I would soon lose myself in the forest of twisty little names.
But really, I don't see the dilemma Joel talks about in the quote above. I'll readily agree that Subversion's merging still needs some work: It can be quite counterintuitive and error prone until you get the habits right. But this Big Hairy Deal about breaking the build? Doesn't exist if you just use Subversion right!
Go forth and branch!
Maybe I'm making a mountain out of a molehill when it comes to Hg... Maybe I'll fall in love with it yet, if it makes this style of working easier for me. There's hope for the old fart, yet.
Prompted by a conversation last week with Brian which touched on Subversion and Git, I decided to have another go at grokking distributed version control. I confess that I'm probably hopelessly brain-damaged on this score; I can't help it: I started out with version control systems in the days of SCCS, graduated to RCS, was forced to deal with the abomination that was PVCS, migrated to CVS, and have largely been reasonably OK (though not ecstatically happy) with Subversion for the past several years and a half. So I can't really be blamed for my difficulties getting to grips with distributed version control, can I? I learned all I know about the subject back in the Dark Ages.
But, hey! I'm a distributed worker kind of guy. I'm sure I can figure this out, even at my advanced age.
Rather than tackle the Swiss Army Chainsaw that is Git, I thought I'd give Mercurial a second go. I lucked into Spolsky's HgInit tutorial which seems a lot more approachable than other tutorials I've seen to date, and a lot shorter than The Mercurial Book. Almost immediately I ran into a passage that stopped me short with the thought, "If this is how people are using Subversion, no wonder they want to move onto something better!"
Joel on Subversion
Now, here’s how Subversion works:No, that's not me he's talking about; that's some other Mike.
* When you check new code in, everybody else gets it.
Since all new code that you write has bugs, you have a choice.
* You can check in buggy code and drive everyone else crazy, or
* You can avoid checking it in until it’s fully debugged.
Subversion always gives you this horrible dilemma. Either the repository is full of bugs because it includes new code that was just written, or new code that was just written is not in the repository.
As Subversion users, we are so used to this dilemma that it’s hard to imagine it not existing.
Subversion team members often go days or weeks without checking anything in. In Subversion teams, newbies are terrified of checking any code in, for fear of breaking the build, or pissing off Mike, the senior developer, or whatever.
Wrong. All wrong!
As luck would have it I was discussing repository-management strategies just last week with a client's (new) development team, and suggesting that they use a much more aggressive strategy than they've ever seen before: Multiple checkins per day by every developer. Maybe go so far as to tie the "File-Save" key to "checkin". Anytime a developer does not make a checkin for 2 days in a row there's almost certainly a problem!
How do we achieve this without the tears and craziness described by Spolsky? Simple! Have every developer working in their own private branch. Or even flipping between a variety of private branches as they switch between tasks. (Yes, I know its not the most productive way to work, but sometimes we have to respond to demands from the outside world, so we do have to take the hit of task-switching.)
I suggested a structure where each developer simply gets a private piece of the repository to work in. Anything that's broken in there is your own problem, but doesn't affect anybody else on the team. When you're satisfied that your branch won't break the world you're ready to merge back to the main development line and integrate your work with your colleagues'. And yes, then you might have some merge conflicts, but I don't really see how any version control system can avoid this; you fix the conflicts and 'Lo! the build is intact. This does imply, though, that you want to merge quite frequently. At least every day or two. Or every time your private branch builds and tests clean. Or maybe just builds clean. All depends on your team - team size, maturity, process-maturity, personal temperaments,... One must study this very hard.
I suppose that the hangups about branching and merging come from the days of CVS, where branching was really, really expensive, and merging really, really difficult. Admittedly, too, earlier versions of Subversion were also not too hot on the merge side of things. (Though I guess it is still work-in-progress and we may yet see some improvements there.)
In recent times I have been using Subversion branches very aggressively. Frequently I'll find myself flipping between as many as 6 or 8 branches on related modules, merging them, abandoning them,... and this is on a one-man project! It means that I have to use branch-names that are pretty long and descriptive, otherwise I would soon lose myself in the forest of twisty little names.
But really, I don't see the dilemma Joel talks about in the quote above. I'll readily agree that Subversion's merging still needs some work: It can be quite counterintuitive and error prone until you get the habits right. But this Big Hairy Deal about breaking the build? Doesn't exist if you just use Subversion right!
Go forth and branch!
Maybe I'm making a mountain out of a molehill when it comes to Hg... Maybe I'll fall in love with it yet, if it makes this style of working easier for me. There's hope for the old fart, yet.
12 April 2010
Cogito Ergo Wiki
For your entertainment and delectation, I offer up a small write-up in which I muse about complexity and simplicity in the tools we choose to inflict upon our project partners.
A short excerpt:
A short excerpt:
I think that WikiMedia is a relatively terrible thing to inflict upon unsuspecting project partners who are already stressed out by the weird idea that they should contribute documentation to your project, that they might actually be asked to actually write somethingWiki Wondering: Share and enjoy.
04 March 2010
Those Damn JavaStations Just Won't Go Away
Actually, this thing - going by the dubious name of 'zero client' - looks to be something more like a SunRay than a JavaStation NC.
I have what is probably one of the only production JavaStations left in the world sitting downstairs - by the front door - waiting to get dumped for recycling. It is not one of those original concept JavaStations - youknow, the one that looked like the Heart Of Gold starship with Infinite Improbability Drive. Rather it was one that actually worked, looking more like a conventional PC, but with an odd (smart-card) slot in the front. It was part of a special production-run that Sun did for a client about 10 years ago which deal fell into disarray when the Left Hand of Marketing failed to talk to the Right Hand of Management at Sun, and they canned the entire JavaStation concept. As a result a couple of thousand of these JavaStations got dumped and the customer got the contract fulfilled by other means.
Actually, it would make a nice X terminal when running Linux. You'd just have to reflash the BIOS.
It occurs to me that there must be some JavaStation nostalgia buff out there that might want it. Any offers?
I have what is probably one of the only production JavaStations left in the world sitting downstairs - by the front door - waiting to get dumped for recycling. It is not one of those original concept JavaStations - youknow, the one that looked like the Heart Of Gold starship with Infinite Improbability Drive. Rather it was one that actually worked, looking more like a conventional PC, but with an odd (smart-card) slot in the front. It was part of a special production-run that Sun did for a client about 10 years ago which deal fell into disarray when the Left Hand of Marketing failed to talk to the Right Hand of Management at Sun, and they canned the entire JavaStation concept. As a result a couple of thousand of these JavaStations got dumped and the customer got the contract fulfilled by other means.
Actually, it would make a nice X terminal when running Linux. You'd just have to reflash the BIOS.
It occurs to me that there must be some JavaStation nostalgia buff out there that might want it. Any offers?
24 February 2010
Invalid Field Feedback Failure
Random musing on UI misdesign
A particular egregious error (seen in websites too numerous to list) is to validate a form, rejecting some field's value as invalid input, and then not telling the user the correct or acceptable values/formats. In other words, leaving the poor user in the dark over what they did wrong.
Only the most motivated and perseverant user will try more than once or twice before simply giving up and going away. And you will fail to capture some information/data the presumably would have been of some value. (Otherwise why would you have constructed a form in the first place?)
Example: Dzone user-profile editing rejects phone numbers entered in a format identical with the example displayed below the phone-number input field, and never provides and explanation of why. Just "Invalid input" over and over again. Result: users do not (cannot) provide valid registration information.
Somehow this failure is even worse when your form absolutely refuses to accept an entry that is perfectly valid in the user's world, but, through your own ignorance or provincialism, you reject as invalid in your own part of the world. A classic example of this crops up on websites requiring a postal-code (zip-code) as part of their input, but insist that postal codes contain exactly 5 or 9 digits. This might be a requirement for valid postal-codes in some parts of the world, but it is patently false for the vast majority of global users. Admittedly this problem has abated some over the past 10 years, but not enough, yet.
So: When you reject a user's input, please tell them how to provide something you will accept. Even better, use input mechanisms that only produce valid values in the first place, and both you and your users will be happier. e.g. Clicking on a map to indicate a position is inherently easier and more error-proof than typing in a latitude and longitude into a textbox.
[Repost from http://mikro2nd.net/bits/Wiki.jsp?page=UIDesign]
A particular egregious error (seen in websites too numerous to list) is to validate a form, rejecting some field's value as invalid input, and then not telling the user the correct or acceptable values/formats. In other words, leaving the poor user in the dark over what they did wrong.
Only the most motivated and perseverant user will try more than once or twice before simply giving up and going away. And you will fail to capture some information/data the presumably would have been of some value. (Otherwise why would you have constructed a form in the first place?)
Example: Dzone user-profile editing rejects phone numbers entered in a format identical with the example displayed below the phone-number input field, and never provides and explanation of why. Just "Invalid input" over and over again. Result: users do not (cannot) provide valid registration information.
Somehow this failure is even worse when your form absolutely refuses to accept an entry that is perfectly valid in the user's world, but, through your own ignorance or provincialism, you reject as invalid in your own part of the world. A classic example of this crops up on websites requiring a postal-code (zip-code) as part of their input, but insist that postal codes contain exactly 5 or 9 digits. This might be a requirement for valid postal-codes in some parts of the world, but it is patently false for the vast majority of global users. Admittedly this problem has abated some over the past 10 years, but not enough, yet.
So: When you reject a user's input, please tell them how to provide something you will accept. Even better, use input mechanisms that only produce valid values in the first place, and both you and your users will be happier. e.g. Clicking on a map to indicate a position is inherently easier and more error-proof than typing in a latitude and longitude into a textbox.
[Repost from http://mikro2nd.net/bits/Wiki.jsp?page=UIDesign]
18 February 2010
MIA: Google News Upgrades
When is Google going to upgrade Google News?
I don't mean anything too radical... I really, really don't want people clicking news articles straight through to Buzz on the assumption that this somehow substitutes for real communication. I have enough noise in my life already!
But I would like to see a way to promote/demote articles that the News software decides to feed me. I'm sick to death of seeing articles for the latest car models released. Let's leave aside the fact that the articles are hideously misclassified... Helloooo, Google! It's over 100 years since cars were bleeding edge Sci/Tech! At least a promote/demote system would allow their software to learn over time that I'm never going to read articles about cars or cricket... that "How Green is Your Valentine", apart from being a bit dated at this point in time, is definitely not climate-change news...
Then, too, it would be so nice to have a way to say to Google News, "Please never show me news from source X ever again." Certain news sites are so tediously flashy that they're not worth the bother of clicking through. I'd rather just make them vanish - at least from my view of the world.
Does this mean I would only get biased, half-arsed, partial news? Of course. But that's what any of us are seeing anyway!
Ah well, its pretty unlikely that Google are paying any attention to this anyway. ;-) My real point is about software adapting to the way I work, play, communicate and view the world. I'll elaborate in another post.
I don't mean anything too radical... I really, really don't want people clicking news articles straight through to Buzz on the assumption that this somehow substitutes for real communication. I have enough noise in my life already!
But I would like to see a way to promote/demote articles that the News software decides to feed me. I'm sick to death of seeing articles for the latest car models released. Let's leave aside the fact that the articles are hideously misclassified... Helloooo, Google! It's over 100 years since cars were bleeding edge Sci/Tech! At least a promote/demote system would allow their software to learn over time that I'm never going to read articles about cars or cricket... that "How Green is Your Valentine", apart from being a bit dated at this point in time, is definitely not climate-change news...
Then, too, it would be so nice to have a way to say to Google News, "Please never show me news from source X ever again." Certain news sites are so tediously flashy that they're not worth the bother of clicking through. I'd rather just make them vanish - at least from my view of the world.
Does this mean I would only get biased, half-arsed, partial news? Of course. But that's what any of us are seeing anyway!
Ah well, its pretty unlikely that Google are paying any attention to this anyway. ;-) My real point is about software adapting to the way I work, play, communicate and view the world. I'll elaborate in another post.
11 February 2010
User Interface Redesigns
I love this quote by E. A. Vander Veer in "Why Does Facebook Keep Redesigning?"
This is more true than I care to think about! Case in point: the SA Weather Service's abomination of a website. They went from a site that, while it had its faults, was uncluttered, easy to navigate, and pretty useful to an astonishingly broad range of audiences whose weather-and-climate-information needs are wildly different: from farmers to firefighters, airline pilots to town-planners. The new site provoked such a backlash when it was first released that the Weather Service website developers were forced to put in links back to the old site in order to provide the vast swathes of information that was missing from the new one.1
Rather than ragging any further on the shitty Weather Service website, allow me to point out one fundamental driver of user-interface redesigns that E A Vander Veer seems to have missed... a reason that goes, in fact, far further than UI redesigns, but is all too often a well concealed motivation for many, many software rewrites and redesigns: We redesign and rewrite because the developers want to play around with a bunch of flavour-of-the-day, oooh-shiny-new-toy technologies.
Not knocking E A's basic insight, though... The motivation seldom comes from the users (or their legitimate representatives) themselves, but almost always from the technical insiders who want change for change's sake.
Like those who thought that adding autoboxing and varargs to the Java language was a value-add...
[1] At the same time the SAWS web designers tried to do the whole "Social Weather 2.0" thing. Sadly they missed the point completely. Any negative comments on the forums regarding the new site were silently deleted. Way to build trust, guys!
typically users aren't considered at all when it comes to software redesigns. I wouldn't have believed this if I hadn't seen it in action on countless projects in several different companies! The attitude is, "We're the experts, we know what you want and need, our redesign is making it better, and it won't take more than a few minutes for you to get up to speed."
This is more true than I care to think about! Case in point: the SA Weather Service's abomination of a website. They went from a site that, while it had its faults, was uncluttered, easy to navigate, and pretty useful to an astonishingly broad range of audiences whose weather-and-climate-information needs are wildly different: from farmers to firefighters, airline pilots to town-planners. The new site provoked such a backlash when it was first released that the Weather Service website developers were forced to put in links back to the old site in order to provide the vast swathes of information that was missing from the new one.1
Rather than ragging any further on the shitty Weather Service website, allow me to point out one fundamental driver of user-interface redesigns that E A Vander Veer seems to have missed... a reason that goes, in fact, far further than UI redesigns, but is all too often a well concealed motivation for many, many software rewrites and redesigns: We redesign and rewrite because the developers want to play around with a bunch of flavour-of-the-day, oooh-shiny-new-toy technologies.
Not knocking E A's basic insight, though... The motivation seldom comes from the users (or their legitimate representatives) themselves, but almost always from the technical insiders who want change for change's sake.
Like those who thought that adding autoboxing and varargs to the Java language was a value-add...
[1] At the same time the SAWS web designers tried to do the whole "Social Weather 2.0" thing. Sadly they missed the point completely. Any negative comments on the forums regarding the new site were silently deleted. Way to build trust, guys!
04 February 2010
Software Design
"System Design, is one that as a profession we talk about less than I believe we should. It is, in many ways, the most important and most difficult thing that we engineers attempt to do. I believe that we avoid talking about it because it is hard, and seems somehow “unscientific.” There are clearly some designs that are good and others that are not. But the judgment of how good a design is often seems subjective or based on aesthetic principles rather than on the cold hard facts that we are engineers who pride ourselves on forming the basis for all that we do. I hope that this essay convinces some readers that the dichotomy between science and art or engineering and aesthetics is not clear, required, or even desirable. What we do must be grounded in fact, but it also needs to be grounded in taste. We should revel in that rather than trying to cover it up. It makes what we do more difficult, but also much more interesting."-- Jim Waldo
I've been thinking a lot again, lately, about software design and how to teach it... and about how little there is out there to guide the design of good software architecture...
All part of my Quest After The Heart Of Design for the last 15 years. And maybe (just maybe!) I think I have a useful angle on it that might illuminate a path forward.
I'll say more as I develop the concept.
(And, BTW, Jim Waldo is, in my humble opinion, one of the preeminent thinkers on design alive, and one of the most interesting people I've had the privilege to meet.)
03 February 2010
Death
So Jason and I were discussing death, as we sometimes do. In particular, what to have engraved1 on our tombstones (assuming we get so lucky!)
"I told you I was ill" -- Spike Milligan
This quickly degenerated to the OO software-designer specific:
"I've been finalized..."
"I've been Garbage Collected."
"Finally, I've been taken up to the PermGen space!"
...all depends on your spiritual views, I suppose...
[1] I it just a coincidence that tombstones get engraved? Probably not.
"I told you I was ill" -- Spike Milligan
This quickly degenerated to the OO software-designer specific:
"I've been finalized..."
"I've been Garbage Collected."
"Finally, I've been taken up to the PermGen space!"
...all depends on your spiritual views, I suppose...
[1] I it just a coincidence that tombstones get engraved? Probably not.
23 January 2010
Boolean Illogic
Why do Java programmers hate the boolean XOR operator?
Is it that they are just generally ignorant about the full-eval boolean operators in general? You know, the operators that look like &, | and ^. Perhaps its that most Java developers are under the impression that they only operate on bits, an are ignorant of the fact that they operate on booleans (and Booleans with that fucking horrible autoboxing/unboxing nonsense.)
I know that 99 time out of 100 we prefer the early-out operators && and || for their efficiency, but a simple ^ can save a hell of a lot of unreadable and less-understandable if-then-else logic. For example, I've just refactored (somebody else's code)
Is it that they are just generally ignorant about the full-eval boolean operators in general? You know, the operators that look like &, | and ^. Perhaps its that most Java developers are under the impression that they only operate on bits, an are ignorant of the fact that they operate on booleans (and Booleans with that fucking horrible autoboxing/unboxing nonsense.)
I know that 99 time out of 100 we prefer the early-out operators && and || for their efficiency, but a simple ^ can save a hell of a lot of unreadable and less-understandable if-then-else logic. For example, I've just refactored (somebody else's code)
if( check ){which I find nasty as hell to be sure is doing what it's supposed to, into
if( !user.isAnonymousUser() ) doStuff();
}else{
if( user.isAnonymousUser() ) doStuff();
}
if( check ^ user.isAnonymouseUser() ) doStuff();Much easier to understand, no?
10 January 2010
How Do Development Managers Screw Up?
Here's a question, much on my mind:
What is the single most important thing that Development Managers do, or fail to do, or pay insufficient attention to, that create a friction in the delivery of working software?
Answers in comments (or email if you don't want to publicly reveal details) please!
By "Development Manager" I don't just mean those people who have those words in their job title, but I mean any person who is responsible for tasking development teams - large or small - and ensuring the delivery of software systems by their developers. Sometimes they are called Project Managers, sometimes - in small entrepreneurial startups - they are the Boss Of The Whole Gig. The point is that they are the interface between the business stakeholders and the technical people who do the development and implementation work.
What is the single most important thing that Development Managers do, or fail to do, or pay insufficient attention to, that create a friction in the delivery of working software?
Answers in comments (or email if you don't want to publicly reveal details) please!
By "Development Manager" I don't just mean those people who have those words in their job title, but I mean any person who is responsible for tasking development teams - large or small - and ensuring the delivery of software systems by their developers. Sometimes they are called Project Managers, sometimes - in small entrepreneurial startups - they are the Boss Of The Whole Gig. The point is that they are the interface between the business stakeholders and the technical people who do the development and implementation work.
06 January 2010
New Courses Scheduled
Courses newly scheduled:
Please contact me directly if you're interested. Places are limited, especially for the Design Patterns course.
More to come soon... if you're interested, I suggest that you keep track of my course schedule page feed (the feed-link is near the top-right), or course-schedule calendar in your feed-reader.
- Patterns of OO Design, 17-19 Feb in Cape Town
- OO Technology Overview for Managers, 22 Feb, Cape Town.
Please contact me directly if you're interested. Places are limited, especially for the Design Patterns course.
More to come soon... if you're interested, I suggest that you keep track of my course schedule page feed (the feed-link is near the top-right), or course-schedule calendar in your feed-reader.
27 December 2009
Flightwish Reboot
Restarted working on Flightwish today. A lot of background stuff... seeing that the DNS is correctly set up for all the FW domains... getting Subversion properly configured on the dev server... restoring the old FW software trove... all the dirty little details of permissions, software configuration and setup that don't usually get mentioned in software development plans, but eat into your time in such a big way.
I've installed the Pebble blog engine on the server, and I have to say it looks pretty nice. Far more impressive than the Blojsom engine that I'm still using for my personal blogs. Simpler to use and customise, and performance feels somehow snappier. The only real snag I hit is that Pebble is supposedly able to interpret WikiCreole - not my wiki syntax of choice, but better than no wiki syntax at all! - only it doesn't seem to work. At least I couldn't make it work. Well, it was pretty late in the day, so maybe my brain has simply had enough for the day.
My idea is to first just get a Flightwish blog up and running so that I can get some content up on the site, and update it reasonably regularly so as to improve its pagerank. I was a bit surprised to see, though, that despite having only reactivated the flightwish.com site a few days ago, its pagerank is 3. Not bad for a dead site! I guess it must be because it has been a real site in the past, and also due to its age (several years.)
After that my next priority will be to get a forum system up and running and looking reasonable so that people can start to sign up and chat. Yes, it would seem to be Yet Another Social Networking Website. Hopefully we'll have enough of a real focus to make it a bit different. The idea is (as it always has been) to do something in the travel space, with a strongly social slant.
As soon as the forum is set up I'll focus on writing a bunch of content - to be released at several-day intervals - telling the stories that drive/drove the initial concept of Flightwish. Those stories (you'll have to subscribe to the Flightwish Blog and wait a few days if you're interested - there's no content there yet) will explain the shape of the Heart of Flightwish as it exists in my head. I'll probably also reminisce about some of the experiences we've had with this thing in years past... the long, long road we've travelled to get here.
Lots of work for a one-man-band! But I think we can do something really interesting, different and meaningful in the travel space. Certainly I'd love to visit Bolivia, Peru, Guatemala, Mexico, Belgium (for the beer) and loads of other places, but I don't think I can do it without a bunch of help!
I've installed the Pebble blog engine on the server, and I have to say it looks pretty nice. Far more impressive than the Blojsom engine that I'm still using for my personal blogs. Simpler to use and customise, and performance feels somehow snappier. The only real snag I hit is that Pebble is supposedly able to interpret WikiCreole - not my wiki syntax of choice, but better than no wiki syntax at all! - only it doesn't seem to work. At least I couldn't make it work. Well, it was pretty late in the day, so maybe my brain has simply had enough for the day.
My idea is to first just get a Flightwish blog up and running so that I can get some content up on the site, and update it reasonably regularly so as to improve its pagerank. I was a bit surprised to see, though, that despite having only reactivated the flightwish.com site a few days ago, its pagerank is 3. Not bad for a dead site! I guess it must be because it has been a real site in the past, and also due to its age (several years.)
After that my next priority will be to get a forum system up and running and looking reasonable so that people can start to sign up and chat. Yes, it would seem to be Yet Another Social Networking Website. Hopefully we'll have enough of a real focus to make it a bit different. The idea is (as it always has been) to do something in the travel space, with a strongly social slant.
As soon as the forum is set up I'll focus on writing a bunch of content - to be released at several-day intervals - telling the stories that drive/drove the initial concept of Flightwish. Those stories (you'll have to subscribe to the Flightwish Blog and wait a few days if you're interested - there's no content there yet) will explain the shape of the Heart of Flightwish as it exists in my head. I'll probably also reminisce about some of the experiences we've had with this thing in years past... the long, long road we've travelled to get here.
Lots of work for a one-man-band! But I think we can do something really interesting, different and meaningful in the travel space. Certainly I'd love to visit Bolivia, Peru, Guatemala, Mexico, Belgium (for the beer) and loads of other places, but I don't think I can do it without a bunch of help!
17 December 2009
Well done, Jason!
Congratulations to Jason on becoming the first family-member to get published:
Implement Automatic Discovery in Your Java Code with Annotations — Developer.com
10 September 2009
Network Disasters Happen in Threes Fours
Only 9 more sleeps to go...
Strike 1: Last week, disaster struck in the form of a 2-day DSL outage. Telkom -- my current DSL provider -- blithely went and cleared the fault ticket after 24hours -- without any consultation with me -- because their test centre said that my router was getting a connection to the local exchange. The ticket comment was, "Fault closed at customer request." Liars!
Much wailing and gnashing of teeth later, they discovered that a whole lot of people in the area were experiencing the same problems: very sporadic connectivity with almost no traffic getting through. Turned out to be a fault on the exchange itself.
Strike 2: On the same day that this problem started, my London-housed server went down for Reasons Unknown. Of course I was blissfully unaware of it until Friday. 2 days of server outage. Then my service provider there was terribly slow to rectify the problem (which -- as the universe will insist upon -- involved a fractal nesting of sub-problems with their own sub-sub-problems ad mandelbrot.) As I write, the server is still only partially up. Apache service -- the one my paying customers rely on -- is up and working fine on one IP address, but Tomcat, hosting my personal and "corporate" sites, blogs and wikis still cannot talk through the other IP address. The service I get from VAServ is pretty kak, but not so kak as to be noteworthy -- they really are giving me a very low-cost package, and, as always, You Gets What You Pays For.
Strike 3: At the same time an FTP backup service I use for offsite backups refused to authenticate me, using the same credentials I've been using for years, with the result that I could not even ensure the safety of all the data! Be Still, My Twitching Ulcer.
You're Out: Welcome to this morning, where we present -- for your entertainment and edification -- a reprise of last week's DSL outage. Telkom, predictably, and once again, are in complete denial that there is actually a problem. Their tests show a solid connection between my router and their exchange. No shit, Sherlock! Pity the bits can't squeeze through the tiny opening.
I've always been very happy with the ISP service I've received from WebAfrica, and have, over the years, put many friends and colleagues onto them, not one of whom has had anything less than Sterling service. I've asked WA to take over my DSL service1, too, in light of recent events. The only bit of business Telkom will be getting from me for the foreseeable future will be POTS.
Only 9 more sleeps to go...2
I think this sorry whining actually has a point; it tends to back up my long-held belief that telcos are constitutionally incapable of competently running IP services. The cultures and philosophies that make end-to-end controlled networks are unable to comprehend -- in some weirdly deep, DNA-level way -- how to cope with IP networks which have almost no intelligence in the middle, but live, instead, with all the intelligence at the edges.
People who run IP networks, on the other hand, are able to provide perfectly adequate voice services over IP, which is why they're going to eat the telcos' lunch over the long term.
[1] There's no transfer/installation fee. Their monthly rates are at present the same as Telkom's, and as they roll out their own infrastructure, they anticipate reducing the charges. Their support desk is outstanding, staffed by people who actually know stuff, don't mind admitting mistakes and problems, treat customers like Real Humans instead of problem-id's, and follow through on promises and commitments and ensuring that things get fixed. I can't see any downside, can you?
[2] Of course, it occurs to me a little late, that I'll only be able to actually post this when I get the server working properly again. Which will only happen when I get some reasonable connectivity back. Which might happen slightly after Lucifer goes skiing from his front doorstep.
Strike 1: Last week, disaster struck in the form of a 2-day DSL outage. Telkom -- my current DSL provider -- blithely went and cleared the fault ticket after 24hours -- without any consultation with me -- because their test centre said that my router was getting a connection to the local exchange. The ticket comment was, "Fault closed at customer request." Liars!
Much wailing and gnashing of teeth later, they discovered that a whole lot of people in the area were experiencing the same problems: very sporadic connectivity with almost no traffic getting through. Turned out to be a fault on the exchange itself.
Strike 2: On the same day that this problem started, my London-housed server went down for Reasons Unknown. Of course I was blissfully unaware of it until Friday. 2 days of server outage. Then my service provider there was terribly slow to rectify the problem (which -- as the universe will insist upon -- involved a fractal nesting of sub-problems with their own sub-sub-problems ad mandelbrot.) As I write, the server is still only partially up. Apache service -- the one my paying customers rely on -- is up and working fine on one IP address, but Tomcat, hosting my personal and "corporate" sites, blogs and wikis still cannot talk through the other IP address. The service I get from VAServ is pretty kak, but not so kak as to be noteworthy -- they really are giving me a very low-cost package, and, as always, You Gets What You Pays For.
Strike 3: At the same time an FTP backup service I use for offsite backups refused to authenticate me, using the same credentials I've been using for years, with the result that I could not even ensure the safety of all the data! Be Still, My Twitching Ulcer.
You're Out: Welcome to this morning, where we present -- for your entertainment and edification -- a reprise of last week's DSL outage. Telkom, predictably, and once again, are in complete denial that there is actually a problem. Their tests show a solid connection between my router and their exchange. No shit, Sherlock! Pity the bits can't squeeze through the tiny opening.
I've always been very happy with the ISP service I've received from WebAfrica, and have, over the years, put many friends and colleagues onto them, not one of whom has had anything less than Sterling service. I've asked WA to take over my DSL service1, too, in light of recent events. The only bit of business Telkom will be getting from me for the foreseeable future will be POTS.
Only 9 more sleeps to go...2
I think this sorry whining actually has a point; it tends to back up my long-held belief that telcos are constitutionally incapable of competently running IP services. The cultures and philosophies that make end-to-end controlled networks are unable to comprehend -- in some weirdly deep, DNA-level way -- how to cope with IP networks which have almost no intelligence in the middle, but live, instead, with all the intelligence at the edges.
People who run IP networks, on the other hand, are able to provide perfectly adequate voice services over IP, which is why they're going to eat the telcos' lunch over the long term.
[1] There's no transfer/installation fee. Their monthly rates are at present the same as Telkom's, and as they roll out their own infrastructure, they anticipate reducing the charges. Their support desk is outstanding, staffed by people who actually know stuff, don't mind admitting mistakes and problems, treat customers like Real Humans instead of problem-id's, and follow through on promises and commitments and ensuring that things get fixed. I can't see any downside, can you?
[2] Of course, it occurs to me a little late, that I'll only be able to actually post this when I get the server working properly again. Which will only happen when I get some reasonable connectivity back. Which might happen slightly after Lucifer goes skiing from his front doorstep.
27 May 2009
Word processors
If Word Processors are to Words as Food Processors are to Food.... no wonder they're so bloody awful to use!
15 May 2009
Backups
Nice story on /. this morning about a faulty backup strategy gone wrong and its consequences. I'll bet a lot of smalltime operators are checking their backups this morning.
I know I am ;-)
I know I am ;-)
14 May 2009
MikroBlog Brainstorm, Part One
Part one of a wiki-essay on "Thinking about a new/different way of doing blogging... and about what blogging is all about...
"
Original at: http://mikro2nd.net/bits/Wiki.jsp?page=MikroBlog
Comments/constructive criticism welcome; be aware, though, that Part One is just painting background for a brainstorm, and not intended as a comprehensive, or even accurate, Recent History Of Blogging. Still very much a Work In Progress!
Past
Blogging in the conventional manner -- having a blog at BlogSpot or LiveJournal or WordPress or even at your own domain using some custom blog platform -- it all seems a bit passè, now, after the hype and frenzy of a couple of years ago.
The format is very much that of a newspaper article, isn't it? Headline, dateline, reporter, article. Even TV reporters follow the format. Oh, except for the commenting, of course! And ratings. That's what was so exciting; a new form of conversation. Two different kinds of conversation, really.
The first is the __News Mode__ conversation. It's a ''broadcast'' mode, primarily; News from me and my world to y'all out there who might be interested in following my drivel. Great for venting. Later that morphed into podcasts -- where did that all go to? -- and photoblogs, but it's all much the same thing. Think of Life Magazine in the 50's and 60's. That's why the mainstream news-media has managed, though it took them long enough, to successfully incorporate blogs and the blog style of things into their websites and mainstream content: it's not so very different from what they were doing before blogs came along. Though let's note in passing that many of them are still extremely uncomfortable with the free-and-easy, short-and-to-the-point, frequently vituperative style that commenters use. There's still a whole lot of this style of blogging going on, and I don't think it is going to disappear.
[{Image src='http://www.adfreeblog.org/adfreebutton.jpg' width='150' height='56' align='right' style='' class='image' }] It can be demanding, though, for the C-list bloggers like Yours Truly. Bloggers with, perhaps, a couple of dozen regular readers who share some niche common interests, read and comment regularly on each others' blogs, and, over time, become friends-at-a-distance. These are the bloggers who are not in it for the money. On their sites you'll see "Proudly Ad-Free" badges. They tried AdSense, and made the grand sum of 32 cents from it. The pressure from all those "How to be a Successful Blogger" websites... the feelings of having let people down should you fail to blog three times a week on a regular schedule... keeping that blogroll up to date... acknowledging all the comments... keeping the comment-spam under control... It all becomes too much after a time, and we see many of these C-listers give up their blogs after a couple of years. Sad, really, because many of them bring a fresh, interesting, if slightly myopic, story to the world.
The idea that bloggers were going to replace conventional journalism with news-from-the-streets... where did that go? Sadly not too many bloggers are keen to follow the Courts beat, nor to drag about after boring political hacks looking for the stuff the mainstream media masticates into news.
But! The conversation is peculiarly stilted. You leave a comment on someone's blog. Perhaps they reply via another comment. Perhaps somebody else comments on your comment. You probably never get to see that. Did you bookmark that conversation? Unlikely! And even if you did, will you remember to go back and visit the bookmark? You might comment on half-a-dozen blogs on any given day. It's a hell of a lot of work keeping up with all those conversations!
There have been various technical fixes to the problem -- email notifications on comment follow-ups, websites that follow the conversation for you and attempt to centralise it -- but none of these have been particularly successful. So as a means of actual conversation, conventional blogging comes up deficient.
But it did get us started, didn't it? We're all writing and conversing much more than we were a decade ago when we were still mainly a television audience -- mere passive consumers of the torrent of crap deemed by the Media Powers to be in our best interests -- and their way of ramming crappy advertorial down our collective gullets.
Original at: http://mikro2nd.net/bits/Wiki.jsp?page=MikroBlog
Comments/constructive criticism welcome; be aware, though, that Part One is just painting background for a brainstorm, and not intended as a comprehensive, or even accurate, Recent History Of Blogging. Still very much a Work In Progress!
Past
Blogging in the conventional manner -- having a blog at BlogSpot or LiveJournal or WordPress or even at your own domain using some custom blog platform -- it all seems a bit passè, now, after the hype and frenzy of a couple of years ago.
The format is very much that of a newspaper article, isn't it? Headline, dateline, reporter, article. Even TV reporters follow the format. Oh, except for the commenting, of course! And ratings. That's what was so exciting; a new form of conversation. Two different kinds of conversation, really.
The first is the __News Mode__ conversation. It's a ''broadcast'' mode, primarily; News from me and my world to y'all out there who might be interested in following my drivel. Great for venting. Later that morphed into podcasts -- where did that all go to? -- and photoblogs, but it's all much the same thing. Think of Life Magazine in the 50's and 60's. That's why the mainstream news-media has managed, though it took them long enough, to successfully incorporate blogs and the blog style of things into their websites and mainstream content: it's not so very different from what they were doing before blogs came along. Though let's note in passing that many of them are still extremely uncomfortable with the free-and-easy, short-and-to-the-point, frequently vituperative style that commenters use. There's still a whole lot of this style of blogging going on, and I don't think it is going to disappear.
[{Image src='http://www.adfreeblog.org/adfreebutton.jpg' width='150' height='56' align='right' style='' class='image' }] It can be demanding, though, for the C-list bloggers like Yours Truly. Bloggers with, perhaps, a couple of dozen regular readers who share some niche common interests, read and comment regularly on each others' blogs, and, over time, become friends-at-a-distance. These are the bloggers who are not in it for the money. On their sites you'll see "Proudly Ad-Free" badges. They tried AdSense, and made the grand sum of 32 cents from it. The pressure from all those "How to be a Successful Blogger" websites... the feelings of having let people down should you fail to blog three times a week on a regular schedule... keeping that blogroll up to date... acknowledging all the comments... keeping the comment-spam under control... It all becomes too much after a time, and we see many of these C-listers give up their blogs after a couple of years. Sad, really, because many of them bring a fresh, interesting, if slightly myopic, story to the world.
The idea that bloggers were going to replace conventional journalism with news-from-the-streets... where did that go? Sadly not too many bloggers are keen to follow the Courts beat, nor to drag about after boring political hacks looking for the stuff the mainstream media masticates into news.
But! The conversation is peculiarly stilted. You leave a comment on someone's blog. Perhaps they reply via another comment. Perhaps somebody else comments on your comment. You probably never get to see that. Did you bookmark that conversation? Unlikely! And even if you did, will you remember to go back and visit the bookmark? You might comment on half-a-dozen blogs on any given day. It's a hell of a lot of work keeping up with all those conversations!
There have been various technical fixes to the problem -- email notifications on comment follow-ups, websites that follow the conversation for you and attempt to centralise it -- but none of these have been particularly successful. So as a means of actual conversation, conventional blogging comes up deficient.
But it did get us started, didn't it? We're all writing and conversing much more than we were a decade ago when we were still mainly a television audience -- mere passive consumers of the torrent of crap deemed by the Media Powers to be in our best interests -- and their way of ramming crappy advertorial down our collective gullets.
28 April 2009
Code as Exploration of Unknown Territory
I have come to view coding as the act of exploring and charting unknown territory -- the wilderness of our cognitive space.
If we let it, as we go along, our code illuminates the crevices and crags of our understanding, and shapes as it goes, our ideas of where to go next.
Version-control is the key mapping tool.
I've just reached a point in the development of the mikroblogging tool where I (finally!) believe I understand what's needed; what might work as something new-ish and interesting-ish in the conversations we have over this Internet thingie...
It's not a conventional website like Twitter or Blogger. It's not a standalone desktop/PC-installed system doing some sort of smart p2p stuff. It's not a conversation follower nor a search tool nor a Bayesian-interest-detector. More something hybrid from all of these.
Let's see where the code will take me next...
If we let it, as we go along, our code illuminates the crevices and crags of our understanding, and shapes as it goes, our ideas of where to go next.
Version-control is the key mapping tool.
I've just reached a point in the development of the mikroblogging tool where I (finally!) believe I understand what's needed; what might work as something new-ish and interesting-ish in the conversations we have over this Internet thingie...
It's not a conventional website like Twitter or Blogger. It's not a standalone desktop/PC-installed system doing some sort of smart p2p stuff. It's not a conversation follower nor a search tool nor a Bayesian-interest-detector. More something hybrid from all of these.
Let's see where the code will take me next...
21 April 2009
Sun and Oracle
TL;DR: A fucking disaster for everybody except Oracle and Sun's execs and (maybe) shareholders. i.e. The Kakistocracy wins and the rest of us get shafted. (As usual.)
I think Oracle are getting an absolute bargain. $7.4 billion is chump-change for the IP they're acquiring. The question is, Which pieces are they going to keep, and which are toast? Some of this is blatantly obvious, other bits are pure crystal-ball-gazing on my part.
Java: the no-brainer. Oracle are heavily invested in Java for the Enterprise stack. Bad news for open-source Java? Maybe! Or maybe not... it all depends on whether Oracle were backing Apache simply as a tactic against Sun in the JCP. I've heard a number comments along the lines of "it's GPL -- the boat has sailed". They're forgetting that the owner of the IP can do as they please, including closing the source completely in the next release. (Not that I think it very likely; just a possibility.) Yes, an open-source community might be able to follow, but I'm betting that there would be compatibility problems.
MySQL: Toast. (Personally I never bought the logic behind Sun acquiring MySQL, and then they went and mishandled the whole thing badly.)
Glassfish: More toast. What will this be... Oracles fourth appserver? I lose count.
Netbeans: A cold shaft of ice pierces my gut. I love Netbeans. I just don't much like its competitor (just a personal preference; don't read too much into it!) But I fear that this might be the end of the road for NB... OTOH it can -- unlike so many of Sun's other open-source projects -- probably survive, nay flourish, as a standalone open-source IDE. After all, that where it came from in the first place.
OpenOffice.org: Makes perfect sense for Oracle. I bet on them keeping this one going. In fact, this might be the Secret Weapon Acquisition... the knife with which Oracle goes seriously for Microsoft's jugular in the Enterprise space, together with Solaris and the Sun hardware.
Solaris: I'm betting it stays. Oracle's strategy has been (to the limited extent I bother to keep track) to lock up the mission-critical, "hard-to-do" stuff in the Enterprise space. And there's still a whole lot of stuff that Solaris does way better than Linux.
VirtualBox: also plays well into the Enterprise/datacentre "integrated offering" strategy.
JavaFX: not one I'm capable of guessing about... any offers?
And the Sun hardware: makes pretty good sense for Oracle, in my limited understanding.
On a more personal note, much closer to home: How likely is it that Oracle will retain Sun's training programs for Java? Methinks it unlikely, since they already have their own training programs. What does that mean for the first Sun-authorised Java trainer in Africa?
Not good news at all, I'll bet!
All-in-all I think the acquisition is terrible news for Sun people, and probably not good news for their customers, either. I am finding it hard to see it in a good light for Java, either, and, having (literally) bet the farm on Java for the past 13 years, find the prospects quite discouraging. And for open-source in general it's a disaster. Despite the Slashdot whiners, Sun has sunk an incredible amount of money and effort into open-source projects, and I simply don't believe that Oracle has the same largeness of vision.
Oh well. Shit happens. I suppose its still a step better than Sun going under completely... Best I get a move-on with further developing my own training material and courseware.
I think Oracle are getting an absolute bargain. $7.4 billion is chump-change for the IP they're acquiring. The question is, Which pieces are they going to keep, and which are toast? Some of this is blatantly obvious, other bits are pure crystal-ball-gazing on my part.
Java: the no-brainer. Oracle are heavily invested in Java for the Enterprise stack. Bad news for open-source Java? Maybe! Or maybe not... it all depends on whether Oracle were backing Apache simply as a tactic against Sun in the JCP. I've heard a number comments along the lines of "it's GPL -- the boat has sailed". They're forgetting that the owner of the IP can do as they please, including closing the source completely in the next release. (Not that I think it very likely; just a possibility.) Yes, an open-source community might be able to follow, but I'm betting that there would be compatibility problems.
MySQL: Toast. (Personally I never bought the logic behind Sun acquiring MySQL, and then they went and mishandled the whole thing badly.)
Glassfish: More toast. What will this be... Oracles fourth appserver? I lose count.
Netbeans: A cold shaft of ice pierces my gut. I love Netbeans. I just don't much like its competitor (just a personal preference; don't read too much into it!) But I fear that this might be the end of the road for NB... OTOH it can -- unlike so many of Sun's other open-source projects -- probably survive, nay flourish, as a standalone open-source IDE. After all, that where it came from in the first place.
OpenOffice.org: Makes perfect sense for Oracle. I bet on them keeping this one going. In fact, this might be the Secret Weapon Acquisition... the knife with which Oracle goes seriously for Microsoft's jugular in the Enterprise space, together with Solaris and the Sun hardware.
Solaris: I'm betting it stays. Oracle's strategy has been (to the limited extent I bother to keep track) to lock up the mission-critical, "hard-to-do" stuff in the Enterprise space. And there's still a whole lot of stuff that Solaris does way better than Linux.
VirtualBox: also plays well into the Enterprise/datacentre "integrated offering" strategy.
JavaFX: not one I'm capable of guessing about... any offers?
And the Sun hardware: makes pretty good sense for Oracle, in my limited understanding.
On a more personal note, much closer to home: How likely is it that Oracle will retain Sun's training programs for Java? Methinks it unlikely, since they already have their own training programs. What does that mean for the first Sun-authorised Java trainer in Africa?
Not good news at all, I'll bet!
All-in-all I think the acquisition is terrible news for Sun people, and probably not good news for their customers, either. I am finding it hard to see it in a good light for Java, either, and, having (literally) bet the farm on Java for the past 13 years, find the prospects quite discouraging. And for open-source in general it's a disaster. Despite the Slashdot whiners, Sun has sunk an incredible amount of money and effort into open-source projects, and I simply don't believe that Oracle has the same largeness of vision.
Oh well. Shit happens. I suppose its still a step better than Sun going under completely... Best I get a move-on with further developing my own training material and courseware.
13 April 2009
Twitter looks vaguely interesting. Not too much. Not enough for me to bother with it. I think it's very Flavour Of The Day.
But it does suit one thing I've had in mind for a while... the idea of a "stream of consciousness" blog sort of thing. Essentially a blog where I can just post a line or two or three, without all the formality and palaver of Subject lines, Categories, Tags, etc. In a nutshell, Twitter,but without the 140 character limit, and hosted on my own server as part of my own infrastructure.
Maybe I'll just write it....
<i>I need another development project like I need more holes in my head. Only two major development projects on the go at the moment, and a couple of minor ones.</i>
But it does suit one thing I've had in mind for a while... the idea of a "stream of consciousness" blog sort of thing. Essentially a blog where I can just post a line or two or three, without all the formality and palaver of Subject lines, Categories, Tags, etc. In a nutshell, Twitter,but without the 140 character limit, and hosted on my own server as part of my own infrastructure.
Maybe I'll just write it....
<i>I need another development project like I need more holes in my head. Only two major development projects on the go at the moment, and a couple of minor ones.</i>
26 March 2009
SL-275 and Java Programmer Certification
Midweek; past the halfway mark (in time, anyway) of teaching Sun's SL-275 "Java Programming Language" course. I wonder how many times I've taught this course over the past 12 years... I still love it! Even though its just the basics, there's something just plain fun about introducing Java to new minds.
This one is interesting; 5 of the students have flown from Stockholm, Sweden all the way to Cape Town, especially to attend this course! Wow! (Of course they might pick up some sunshine in the middle of the Northern Winter. I guess that may help. ;-)
The trouble is that Java has grown so large over the years that there's a hard choice: cover (mostly) everything in a shallow way? or leave a lot out to get more depth?
Add to that, Sun punt the course as "the" prerequisite for writing the Java Programmer Certification Exam. Frankly, I shudder at the thought! Programmers would need a lot more than just this course to be in a position to tackle the exam. And programmers who are in a good position to tackle the exam don't really need this course!
As it currently stands, the course is inadequate for students attending it in order to prepare for the Certification Exam. There's very little I can teach them and still remain reasonably close to the course materials. The course is pretty good as an intro to Java for experienced developers, but pressure from more experienced developers in the class -- especially when they are in a significant majority -- could, if I'm not careful and strong in controlling it, leave the less-well-versed-in-Java students stranded. (I assure you that I don't let this happen.)
The solution is to split the course in two. One would be a truly introductory course aimed at otherwise-experienced developers. And the second would avoid all basic material -- syntax of if statements, declaring classes and interfaces -- in favour of homing-in on the deeper, less well known details of Java execution that the Certification Exam aims to test.
I sure wish Sun would do it soon! It would make life so much easier for us trainers, and would deliver a much better focussed value to customers.
This one is interesting; 5 of the students have flown from Stockholm, Sweden all the way to Cape Town, especially to attend this course! Wow! (Of course they might pick up some sunshine in the middle of the Northern Winter. I guess that may help. ;-)
The trouble is that Java has grown so large over the years that there's a hard choice: cover (mostly) everything in a shallow way? or leave a lot out to get more depth?
Add to that, Sun punt the course as "the" prerequisite for writing the Java Programmer Certification Exam. Frankly, I shudder at the thought! Programmers would need a lot more than just this course to be in a position to tackle the exam. And programmers who are in a good position to tackle the exam don't really need this course!
As it currently stands, the course is inadequate for students attending it in order to prepare for the Certification Exam. There's very little I can teach them and still remain reasonably close to the course materials. The course is pretty good as an intro to Java for experienced developers, but pressure from more experienced developers in the class -- especially when they are in a significant majority -- could, if I'm not careful and strong in controlling it, leave the less-well-versed-in-Java students stranded. (I assure you that I don't let this happen.)
The solution is to split the course in two. One would be a truly introductory course aimed at otherwise-experienced developers. And the second would avoid all basic material -- syntax of if statements, declaring classes and interfaces -- in favour of homing-in on the deeper, less well known details of Java execution that the Certification Exam aims to test.
I sure wish Sun would do it soon! It would make life so much easier for us trainers, and would deliver a much better focussed value to customers.
18 January 2009
Open Course Development
It strikes me that, whilst I am deep into the design of a number of programming-related courses, I am making a terrible mistake. The mistake of not talking about what I'm up to. The mistake of assuming the entire burden of course development.
Instead I ought to be employing Open Source development principles. At least some of them. Seems to me that (at least) the Thousand Eyeballs principle applies quite well, at least to the course structure, content and sequencing.
Right now I'm in the thick of codesigning three courses that I (with good reason!) believe are served very poorly by the corporate training world, and I think I can design courses that deliver much, much better value for money. The three I'm busy with right now are "Elements of Object Oriented Programming", "OO Analysis and Design" and "Patterns of Software Design".
"Elements" is intended as an introductory foundation course for programmers coming from a non-OO background who want/need to learn the OO concepts quite quickly. Nobody in their right minds would believe that a 3-day "Elements"-style course is going to turn any Natural programmer into an OO expert... we all know that the process of learning to Think Objects takes 9 months. But I do believe that it is possible to teach the foundation concepts really well.
"OO A&D" seeks to demystify the analysis and design process -- to the degree that it is possible to demystify an essentially creative process.
And, finally, the "Design Patterns" course aims to teach something useful about... well... design patterns. I've taught variations on this one numerous times over the years, but never really been satisfied with the value I was able to deliver, so I've completely rethought the approach from the ground up, and -- I think -- come up with something Just a Bit Different. A whole lot of the Design Patterns courses I've seen offered seem to add up to nothing more than a whole lot of droning through the GoF patterns catalogue. I think there's a whole bunch more to the topic than that, and I plan to use the course to explore that.
I've also outlined a whole bunch of other courses that I want to develop over the next year or so, but developing even these three is a daunting enough task for now.
I'm openly stealing some of the concepts -- the approach to teaching -- exemplified by the Head First books, and I'm really interested to see that O'Reilly are themselves developing a bunch of courses -- I gather they'll be web-based courses -- under the Head First brand. Good for them! It's about time we saw a better approach to teaching technical stuff.
So I'm aiming to make the courses colourful, interactive and fun. I'm trying to build in lots of of pictures, music, video, games, practical exercises, movement. (Trying to figure out how to include flavours and smells... ;-)
I've also been breaking away -- especially for the "Elements" course -- from linearity in the course sequencing. Essentially I'm developing using a Spiral Model. First introduce a concept, then go on to related concepts, etc., in time spiralling round to repeat the discussion of the topic in greater depth, and so on. I've long known that it is too easy to give too much detail all at once, so for my own course material, I'm explicitly shying away from that. I think it equates -- somewhat -- to the concept of Progressive Disclosure in user-interface design. As luck would have it, after several weeks working on this stuff, I tripped across this article just today, and went "Aha! Somebody else who Gets It!"
Right now I am stuck. Struggling to come up with good great practical ways of exploring the topic of "Encapsulation" in a way that doesn't stray too far from the way it's meant in OO programming, whilst remaining vaguely interesting.
As soon as I get the relevant bits of machinery up and running, I'll post the course outlines. (Will take a while: I am unexpectedly and suddenly off to London for a week for a spot of consulting work.)
Instead I ought to be employing Open Source development principles. At least some of them. Seems to me that (at least) the Thousand Eyeballs principle applies quite well, at least to the course structure, content and sequencing.
Right now I'm in the thick of codesigning three courses that I (with good reason!) believe are served very poorly by the corporate training world, and I think I can design courses that deliver much, much better value for money. The three I'm busy with right now are "Elements of Object Oriented Programming", "OO Analysis and Design" and "Patterns of Software Design".
"Elements" is intended as an introductory foundation course for programmers coming from a non-OO background who want/need to learn the OO concepts quite quickly. Nobody in their right minds would believe that a 3-day "Elements"-style course is going to turn any Natural programmer into an OO expert... we all know that the process of learning to Think Objects takes 9 months. But I do believe that it is possible to teach the foundation concepts really well.
"OO A&D" seeks to demystify the analysis and design process -- to the degree that it is possible to demystify an essentially creative process.
And, finally, the "Design Patterns" course aims to teach something useful about... well... design patterns. I've taught variations on this one numerous times over the years, but never really been satisfied with the value I was able to deliver, so I've completely rethought the approach from the ground up, and -- I think -- come up with something Just a Bit Different. A whole lot of the Design Patterns courses I've seen offered seem to add up to nothing more than a whole lot of droning through the GoF patterns catalogue. I think there's a whole bunch more to the topic than that, and I plan to use the course to explore that.
I've also outlined a whole bunch of other courses that I want to develop over the next year or so, but developing even these three is a daunting enough task for now.
I'm openly stealing some of the concepts -- the approach to teaching -- exemplified by the Head First books, and I'm really interested to see that O'Reilly are themselves developing a bunch of courses -- I gather they'll be web-based courses -- under the Head First brand. Good for them! It's about time we saw a better approach to teaching technical stuff.
So I'm aiming to make the courses colourful, interactive and fun. I'm trying to build in lots of of pictures, music, video, games, practical exercises, movement. (Trying to figure out how to include flavours and smells... ;-)
I've also been breaking away -- especially for the "Elements" course -- from linearity in the course sequencing. Essentially I'm developing using a Spiral Model. First introduce a concept, then go on to related concepts, etc., in time spiralling round to repeat the discussion of the topic in greater depth, and so on. I've long known that it is too easy to give too much detail all at once, so for my own course material, I'm explicitly shying away from that. I think it equates -- somewhat -- to the concept of Progressive Disclosure in user-interface design. As luck would have it, after several weeks working on this stuff, I tripped across this article just today, and went "Aha! Somebody else who Gets It!"
Right now I am stuck. Struggling to come up with good great practical ways of exploring the topic of "Encapsulation" in a way that doesn't stray too far from the way it's meant in OO programming, whilst remaining vaguely interesting.
As soon as I get the relevant bits of machinery up and running, I'll post the course outlines. (Will take a while: I am unexpectedly and suddenly off to London for a week for a spot of consulting work.)
Subscribe to:
Posts (Atom)
