Just in case it saves someone else the tedious typing... Capitalisation of messages duplicates the inconsistencies in RFC2616. Don't ask me...
public enum HttpResponse {
HTTP_100( 100, "HTTP/1.0 100 Continue\r\n\r\n" ),
HTTP_101( 101, "HTTP/1.0 101 Switching Protocols\r\n\r\n" ),
HTTP_200( 200, "HTTP/1.0 200 OK\r\n\r\n" ),
HTTP_201( 201, "HTTP/1.0 201 Created\r\n\r\n" ),
HTTP_202( 202, "HTTP/1.0 202 Accepted\r\n\r\n" ),
HTTP_203( 203, "HTTP/1.0 203 Non-Authoritative Information\r\n\r\n" ),
HTTP_204( 204, "HTTP/1.0 204 No Content\r\n\r\n" ),
HTTP_205( 205, "HTTP/1.0 205 Reset Content\r\n\r\n" ),
HTTP_206( 206, "HTTP/1.0 206 Partial Content\r\n\r\n" ),
HTTP_300( 300, "HTTP/1.0 300 Multiple Choices\r\n\r\n" ),
HTTP_301( 301, "HTTP/1.0 301 Moved Permanently\r\n\r\n" ),
HTTP_302( 302, "HTTP/1.0 302 Found\r\n\r\n" ),
HTTP_303( 303, "HTTP/1.0 303 See Other\r\n\r\n" ),
HTTP_304( 304, "HTTP/1.0 304 Not Modified\r\n\r\n" ),
HTTP_305( 305, "HTTP/1.0 305 Use Proxy\r\n\r\n" ),
HTTP_307( 307, "HTTP/1.0 307 Temporary Redirect\r\n\r\n" ),
HTTP_400( 400, "HTTP/1.0 400 Bad Request\r\n\r\n" ),
HTTP_401( 401, "HTTP/1.0 401 Unauthorized\r\n\r\n" ),
HTTP_402( 402, "HTTP/1.0 402 Payment Required\r\n\r\n" ),
HTTP_403( 403, "HTTP/1.0 403 Forbidden\r\n\r\n" ),
HTTP_404( 404, "HTTP/1.0 404 Not Found\r\n\r\n" ),
HTTP_405( 405, "HTTP/1.0 405 Method Not Allowed\r\n\r\n" ),
HTTP_406( 406, "HTTP/1.0 406 Not Acceptable\r\n\r\n" ),
HTTP_407( 407, "HTTP/1.0 407 Proxy Authentication Required\r\n\r\n" ),
HTTP_408( 408, "HTTP/1.0 408 Request Time-out\r\n\r\n" ),
HTTP_409( 409, "HTTP/1.0 409 Conflict\r\n\r\n" ),
HTTP_410( 410, "HTTP/1.0 410 Gone\r\n\r\n" ),
HTTP_411( 411, "HTTP/1.0 411 Length Required\r\n\r\n" ),
HTTP_412( 412, "HTTP/1.0 412 Precondition Failed\r\n\r\n" ),
HTTP_413( 413, "HTTP/1.0 413 Request Entity Too Large\r\n\r\n" ),
HTTP_414( 414, "HTTP/1.0 414 Request-URI Too Large\r\n\r\n" ),
HTTP_415( 415, "HTTP/1.0 415 Unsupported Media Type\r\n\r\n" ),
HTTP_416( 416, "HTTP/1.0 416 Requested range not satisfiable\r\n\r\n" ),
HTTP_417( 417, "HTTP/1.0 417 Expectation Failed\r\n\r\n" ),
HTTP_500( 500, "HTTP/1.0 500 Internal Server Error\r\n\r\n" ),
HTTP_501( 501, "HTTP/1.0 501 Not Implemented\r\n\r\n" ),
HTTP_502( 502, "HTTP/1.0 502 Bad Gateway\r\n\r\n" ),
HTTP_503( 503, "HTTP/1.0 503 Service Unavailable\r\n\r\n" ),
HTTP_504( 504, "HTTP/1.0 504 Gateway Time-out\r\n\r\n" ),
HTTP_505( 505, "HTTP/1.0 505 HTTP Version not supported\r\n\r\n" );
private final int intValue;
private final String msg;
private HttpResponse( int intValue, final String msg ){
this.intValue = intValue;
this.msg = msg;
}
public int intValue(){
return intValue;
}
public String responseString(){
return msg;
}
public static HttpResponse forResponseCode( int responseCode ){
for( HttpResponse v : values() ){
if( responseCode == v.intValue() ) return v;
}
throw new IllegalArgumentException();
}
}
Showing posts with label java. Show all posts
Showing posts with label java. Show all posts
18 October 2010
13 October 2010
A Lesson from Vegetable Gardening for Hiring (and Keeping) Better Software Developers
Right now I'm in the midst of Busy Season in the Veggie Garden: Spring Planting Time. Even busier than harvest time. You see, you can almost always delay a harvest by a few days or a week without serious consequences. But you can't delay sowing seed without reaping serious consequences 4 to 6 months down the line. Veggie gardening is all about strategy.
Just the other day I heard about a successful and growing Cape Town company planning a hiring spree for Java developers. They'll be looking for quite a number of Java developers at all skill and experience levels.
But they face two key problems:
This is great news for Java devs: Salaries are pretty competitive, even if not quite up to Jo'burg levels just yet.
Hell for employers, though.
Strategy is about Time
My main problem this Planting Season is that I don't have any compost for the garden. The key to making great compost is adding plenty of water, and the key to great veggie crops is building the soil by adding compost, year after year after year. But we're (still) in a drought, so no water. Successful crops are going to be a serious challenge this Summer...
CEOs, CTOs and Development Managers who get it know that investing in their developers' skills, knowledge and experience is investing in their own success and the success of their business. And the secret is that it can't be done overnight. It takes long-term commitment to helping their developers build their skills. And intelligent developers reward real, honest commitment to skills- and career-development with loyalty.
And developers talk to each other. In their mailing lists and user-group meetings, on Facebook and Twitter, word-of-mouth ensures that developers have a pretty good idea of who is doing the interesting software, who is providing a stimulating development environment. In short, who the good employers are. (Especially in Cape Town! The software world in CT really is a very small village.)
Compost making and soil-building is a strategic practise for farmers and gardeners everywhere, whether they are organic growers (like me) or not, soil-building is of vital strategic importance. Without healthy soil we have nothing.
Likewise, CEOs, CTOs and Dev Managers of companies for whom software development is a strategic business activity have a vital interest in developing their developers.
Planning to Hire Developers Any Time Soon?
If you are planning to attempt to hire developers (particularly Java developers; particularly in or around Cape Town) within the next 6 months, ask yourself the following 3 questions:
If you'd like help creating fertile ground for interesting minds who can help drive your software development to greater successes, call me.
Just the other day I heard about a successful and growing Cape Town company planning a hiring spree for Java developers. They'll be looking for quite a number of Java developers at all skill and experience levels.
But they face two key problems:
- There is an extreme scarcity of Java developers at any and all levels in Cape Town and surrounds.
- They'll be competing against a very large number of other employers looking for large numbers of Java developers. I have, over the past couple of months, heard of numerous companies searching for 10, 12 and more "skilled Java developers".
This is great news for Java devs: Salaries are pretty competitive, even if not quite up to Jo'burg levels just yet.
Hell for employers, though.
Strategy is about Time
My main problem this Planting Season is that I don't have any compost for the garden. The key to making great compost is adding plenty of water, and the key to great veggie crops is building the soil by adding compost, year after year after year. But we're (still) in a drought, so no water. Successful crops are going to be a serious challenge this Summer...
CEOs, CTOs and Development Managers who get it know that investing in their developers' skills, knowledge and experience is investing in their own success and the success of their business. And the secret is that it can't be done overnight. It takes long-term commitment to helping their developers build their skills. And intelligent developers reward real, honest commitment to skills- and career-development with loyalty.
And developers talk to each other. In their mailing lists and user-group meetings, on Facebook and Twitter, word-of-mouth ensures that developers have a pretty good idea of who is doing the interesting software, who is providing a stimulating development environment. In short, who the good employers are. (Especially in Cape Town! The software world in CT really is a very small village.)
Compost making and soil-building is a strategic practise for farmers and gardeners everywhere, whether they are organic growers (like me) or not, soil-building is of vital strategic importance. Without healthy soil we have nothing.
Likewise, CEOs, CTOs and Dev Managers of companies for whom software development is a strategic business activity have a vital interest in developing their developers.
Planning to Hire Developers Any Time Soon?
If you are planning to attempt to hire developers (particularly Java developers; particularly in or around Cape Town) within the next 6 months, ask yourself the following 3 questions:
- How are you going to source the best and brightest devs when they're almost unreachable at any price?
- How are you going to make your company more attractive to those devs than all the competition you face?
- How are you going to keep developers from job-hopping when they get that email from a competing employer or headhunter offering them a huge raise?
If you'd like help creating fertile ground for interesting minds who can help drive your software development to greater successes, call me.
29 July 2010
Refresher Training is Good, Too!
Some while ago I was teaching a course -- Java Web Application Programming, as it happens -- to a group of quite-experienced web developers working in a large corporate environment. Needless to say, we all thought that this was yet another case of the Training Department getting their act together waaaay too late...
We soon discovered, however, that some of the core concepts and technologies of Java Web Application development were, at best, only poorly understood, even by the most experienced developers in the group. Many of the details of the HTTP protocol were unknown to them, as was the development of custom Tag Libraries -- a key component for developing clean, maintainable Java Web applications without in-page scripting. They had not thought much about the consequences of placing large (multi-megabyte) objects in the application Session... (this is in a clustered web-container environment!)
This is not a criticism of those developers! They had, for years, been delivering absolutely critical business functionality. This is merely an observation that technologies move on; sometimes developers need a little help to catch up, since their management usually neglects to allow time for self-study catch-up on new evolutions in the technology.
More important, it is an observation that Development Managers, Team Leaders and Project Managers shouldn't assume that their developers are completely up-to-date on the technologies they're using for day-to-day development.
Replicated from http://coco.co.za/wiki/KeyTechnologyTrainingStory
We soon discovered, however, that some of the core concepts and technologies of Java Web Application development were, at best, only poorly understood, even by the most experienced developers in the group. Many of the details of the HTTP protocol were unknown to them, as was the development of custom Tag Libraries -- a key component for developing clean, maintainable Java Web applications without in-page scripting. They had not thought much about the consequences of placing large (multi-megabyte) objects in the application Session... (this is in a clustered web-container environment!)
This is not a criticism of those developers! They had, for years, been delivering absolutely critical business functionality. This is merely an observation that technologies move on; sometimes developers need a little help to catch up, since their management usually neglects to allow time for self-study catch-up on new evolutions in the technology.
More important, it is an observation that Development Managers, Team Leaders and Project Managers shouldn't assume that their developers are completely up-to-date on the technologies they're using for day-to-day development.
Replicated from http://coco.co.za/wiki/KeyTechnologyTrainingStory
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?
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?
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.
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.
30 December 2008
Teaching Servlets and JSP
It's the end of a week teaching Sun's SL-314 course -- "Web Component Development with Servlets and JSP" in Cape Town. It's been challenging and demanding, but, above all, fun! I had a great bunch of participants on the course, a couple of whom were old friends from an "Intro to Java" course (Sun's SL-275 course) some months ago.
The course materials are pretty good, although with a couple of misfeatures -- in my ever-so-humble opinion, as always -- and one glaring omission! (Never mind the details; I won't bite the hand that feeds me. This time. Rest assured that I've passed my thoughts on to the good people at Sun Education.) However, the whole sequencing and structure of the course has set me thinking, "How would I go about structuring such a course? What examples and challenges would I use for lab work?"
I take this teaching stuff pretty seriously1. So I'm always looking for ways to add value above and beyond what is offered by the course materials. Of course, the most valuable thing a trainer can bring into these sorts of skills-oriented technical courses is one's own experience actually using the technology on real-world projects. But beyond that, a lot of value can be added (or subtracted) by the sequence, timing and manner in which the material is presented. In a 5-day course time is terribly limited, so practical examples and labwork are necessarily very constrained, so it is very hard to work-up really good examples.
Setting examples and lab-work for courses is actually a very hard problem. You don't want to restrict the work to toy problems -- students pick up on that very quickly, and, even more quickly, lose interest in the course material, and, more importantly and with longer-term consequences for the remainder of the course, they lose respect for the course (and sometimes for the instructor, too.) On the other hand, time is very limited -- perhaps a couple of hours for any given issue, so extensive examples take too long to implement.
Then, too, one is in the position of trying to illustrate and/or reinforce key points in the course material, and developing actual code always involves a measure of extraneous detail -- housekeeping code. It adds nothing to the teaching purpose of the exercise, but it certainly chews into the time available!
And -- not to be neglected -- I think it is important that examples be at least a little bit entertaining. After all, we can do order-entry at work anytime... But there's a borderline across which "entertaining" becomes "irrelevant". (Much the same can be said of micro-benchmarks.)
Relevance? You wanted relevance from a blog post? As opposed to rambling?
OK.
I'm starting to put together my own material for a number of courses, centring around the gaps in the corporate professional training space (OO and Java technical matters, of course.) that I've been seeing over the past decade.
(Of course, now is a brilliant time to be putting my own course-material together. In times of economic downturn, the very first thing to get the axe is training! How short-sighted is that?)
[1] As with most things, the more you put into it, the more you get out of it!
The course materials are pretty good, although with a couple of misfeatures -- in my ever-so-humble opinion, as always -- and one glaring omission! (Never mind the details; I won't bite the hand that feeds me. This time. Rest assured that I've passed my thoughts on to the good people at Sun Education.) However, the whole sequencing and structure of the course has set me thinking, "How would I go about structuring such a course? What examples and challenges would I use for lab work?"
I take this teaching stuff pretty seriously1. So I'm always looking for ways to add value above and beyond what is offered by the course materials. Of course, the most valuable thing a trainer can bring into these sorts of skills-oriented technical courses is one's own experience actually using the technology on real-world projects. But beyond that, a lot of value can be added (or subtracted) by the sequence, timing and manner in which the material is presented. In a 5-day course time is terribly limited, so practical examples and labwork are necessarily very constrained, so it is very hard to work-up really good examples.
Setting examples and lab-work for courses is actually a very hard problem. You don't want to restrict the work to toy problems -- students pick up on that very quickly, and, even more quickly, lose interest in the course material, and, more importantly and with longer-term consequences for the remainder of the course, they lose respect for the course (and sometimes for the instructor, too.) On the other hand, time is very limited -- perhaps a couple of hours for any given issue, so extensive examples take too long to implement.
Then, too, one is in the position of trying to illustrate and/or reinforce key points in the course material, and developing actual code always involves a measure of extraneous detail -- housekeeping code. It adds nothing to the teaching purpose of the exercise, but it certainly chews into the time available!
And -- not to be neglected -- I think it is important that examples be at least a little bit entertaining. After all, we can do order-entry at work anytime... But there's a borderline across which "entertaining" becomes "irrelevant". (Much the same can be said of micro-benchmarks.)
Relevance? You wanted relevance from a blog post? As opposed to rambling?
OK.
I'm starting to put together my own material for a number of courses, centring around the gaps in the corporate professional training space (OO and Java technical matters, of course.) that I've been seeing over the past decade.
(Of course, now is a brilliant time to be putting my own course-material together. In times of economic downturn, the very first thing to get the axe is training! How short-sighted is that?)
[1] As with most things, the more you put into it, the more you get out of it!
25 September 2008
Back in the Saddle: Java 101
Interesting to be back in the Training Game. It is a Java 101 (Introduction to Java Programming for Programmers) course. With some differences.
Its all for one corporate client. My God, its been a long time since I had to deal with Corporate IT Thinking. There's some of it that exists for good reason. And then there's a whole lot of crap. Stuff that's more to do with politics, staking out of turf, ass-covering... The real downside for a Java 101 course is not so huge, but still... everybody is from the same organisation, though they might well be from different planets, considering the departments they're drawn from... But, there's still not a lot of cross-pollination of ideas. The whiff of groupthink.
I've taken the format of the "usual" 5-day course and adapted it somewhat to a 6-day format split over two 3-day sessions a couple of weeks apart, so there's a lot more breathing room, but, for any "Intro to X" course there is a certain body of knowledge that has to be covered, and there's a certain Logic to the order in which material has to be presented, so there's no escaping... There's just a bunch of stuff that has to get taught before people can realistically handle a tutorial (a.k.a. "homework".) All resulting in a pretty heavy First Three Days. I've just finished Day 3 ("Subscriber Trunk Dialing".) I'm exhausted.
Differences: In the usual "5-day" format I'd have to be really winding up my energy to stay the pace for Day 4. This time around I get a week-long break, and get to start fresh. Mmmmm... Gooooood!
Happily I have a fairly bright bunch. Quite a mix of backgrounds, all the way from a university graduates to "just-a-programmer-can-I-google-a-solution-and-cut-n-paste-the-code". The usual chirpy heckler who borders, at times, on irritating, but helps keep things alive. The usual "deeply tech" who catches all my mistakes and omissions, and keeps me on my toes.
I'll confess that I'm having a ball!
Its all for one corporate client. My God, its been a long time since I had to deal with Corporate IT Thinking. There's some of it that exists for good reason. And then there's a whole lot of crap. Stuff that's more to do with politics, staking out of turf, ass-covering... The real downside for a Java 101 course is not so huge, but still... everybody is from the same organisation, though they might well be from different planets, considering the departments they're drawn from... But, there's still not a lot of cross-pollination of ideas. The whiff of groupthink.
I've taken the format of the "usual" 5-day course and adapted it somewhat to a 6-day format split over two 3-day sessions a couple of weeks apart, so there's a lot more breathing room, but, for any "Intro to X" course there is a certain body of knowledge that has to be covered, and there's a certain Logic to the order in which material has to be presented, so there's no escaping... There's just a bunch of stuff that has to get taught before people can realistically handle a tutorial (a.k.a. "homework".) All resulting in a pretty heavy First Three Days. I've just finished Day 3 ("Subscriber Trunk Dialing".) I'm exhausted.
Differences: In the usual "5-day" format I'd have to be really winding up my energy to stay the pace for Day 4. This time around I get a week-long break, and get to start fresh. Mmmmm... Gooooood!
Happily I have a fairly bright bunch. Quite a mix of backgrounds, all the way from a university graduates to "just-a-programmer-can-I-google-a-solution-and-cut-n-paste-the-code". The usual chirpy heckler who borders, at times, on irritating, but helps keep things alive. The usual "deeply tech" who catches all my mistakes and omissions, and keeps me on my toes.
I'll confess that I'm having a ball!
19 November 2007
Object-Relational Event
At long last EoD SQL 1.0 is out! Congrats to Lemnik on this achievement. But what is lurgy?
EoDSQL is an Object-Relational bridge -- an small library for getting (Java) objects in and out of relational databases. It is not an OR Mapper; that task is left to the developer. You get to specify how (Java) data elements correspond to which database columns handraulically, using annotations[1]. Not only that, but, as developer, you get to write all the SQL, too! Good! For me this is one of the best features of EoDSQL. EoDSQL will never mess with your highly tuned SQL, will never get between you and your database. I confess to finding myself far more comfortable with this sort of lightweight approach to the much-lamented "OR impedance mismatch" problem than other approaches I've seen to date.
The upshot of all this lightweight deliciousness is that it is screamingly fast! Way faster than any of the heavyweight OR tools I've seen. And Lemnik is talking about implementing a compile-time tool to make it faster yet.
I have to confess to some bias, though: I was so impressed with the thing that I ended-up writing the tutorial for EoDSQL, so I'd welcome feedback on it, either here, or on the project's mailing list.
EoDSQL is an Object-Relational bridge -- an small library for getting (Java) objects in and out of relational databases. It is not an OR Mapper; that task is left to the developer. You get to specify how (Java) data elements correspond to which database columns handraulically, using annotations[1]. Not only that, but, as developer, you get to write all the SQL, too! Good! For me this is one of the best features of EoDSQL. EoDSQL will never mess with your highly tuned SQL, will never get between you and your database. I confess to finding myself far more comfortable with this sort of lightweight approach to the much-lamented "OR impedance mismatch" problem than other approaches I've seen to date.
The upshot of all this lightweight deliciousness is that it is screamingly fast! Way faster than any of the heavyweight OR tools I've seen. And Lemnik is talking about implementing a compile-time tool to make it faster yet.
I have to confess to some bias, though: I was so impressed with the thing that I ended-up writing the tutorial for EoDSQL, so I'd welcome feedback on it, either here, or on the project's mailing list.
[1] So, yes, it is Java >=1.5 only. Anybody who is not already running 1.5 or better (production environments included!) has lost the plot (or has serious, perhaps fatal, legacy issues!)
10 July 2006
JSPWiki
I think JSPWiki is one of the greatest pieces of open source software out there anywhere. It might not be well suited to everytone running a small website on a shared host because it requires a Java servlet container for hosting, so demands a slightly higher level of expertise than the PHP junk that's out there.
That said, it drops into place and "just works" for a fast tryout or evaluation. At the same time most of the flexibility needed for large-scale, sysadmin-run deployments is easily available, and its not an "all in one big step" thing either: you can gradually add the finer-grained controls as you need them. Any Java-capable sysadmin will have no difficulty.
Furthermore, there is an active, healthy and, above all, friendly developer community.
I am using JSPWiki to run the "static" content side of this website, with only myself allowed to create, delete and edit pages. (Indeed, only I am allowed to log in!) Its perfect for the task. All I have to do now is hack the templates into something nicer to look at. :-)
That said, it drops into place and "just works" for a fast tryout or evaluation. At the same time most of the flexibility needed for large-scale, sysadmin-run deployments is easily available, and its not an "all in one big step" thing either: you can gradually add the finer-grained controls as you need them. Any Java-capable sysadmin will have no difficulty.
Furthermore, there is an active, healthy and, above all, friendly developer community.
I am using JSPWiki to run the "static" content side of this website, with only myself allowed to create, delete and edit pages. (Indeed, only I am allowed to log in!) Its perfect for the task. All I have to do now is hack the templates into something nicer to look at. :-)
Subscribe to:
Posts (Atom)
