Showing posts with label courses. Show all posts
Showing posts with label courses. Show all posts

08 February 2011

Fusion Cuisine: Slicing and Dicing Courses to Suit Different Palates

Ever been faced with setting up training for some of your developers, but the courses offered by the usual suspects fail to cover the technologies your team uses? Or cover technologies that you don't use? Or lack the depth you're looking for in particular areas? Or too much depth...?

I was recently faced with a request from a client who want to put some of their junior developers through an Intro to Java course. The developers in question come from various other programming backgrounds, and already understand OO concepts and normal development disciplines. The "obvious" choice is the Sun/Oracle SL-275 mainstay course which I have been teaching (on and off) for something like 15 years, now.

But! A good part of SL-275 – and of my own Intro to Java course – delves into developing applications using the Swing GUI toolkit, used to construct desktop applications. This particular client is a company that only does web-applications, so learning a bunch of Swing concepts does them little good. I was happily able to propose that, instead of using Swing for that portion of the course, we could substitute some Servlet and JSP concepts and development. This arrangement serves them much better, as it also equips their developers with knowledge they will be able to immediately put to productive use. Fortunately I have lately put in a lot of work on a Servlet/JSP course, so I'm able to cycle some of that material into the Java Intro course.

It's not as simple as it sounds, though!

The Swing portion of "Intro to Java" also serves some other pedagogic purposes. It reinforces some of the OO groundwork covered earlier in the course by driving home the differences between inheritance, containment and usage. (At least it does the way I teach it!) Swing also provides a good platform for introducing listeners (Observer Pattern in the GoF book), Java's anonymous-inner class mechanism, and the exception-handling framework, along with a bunch of other bits-and-pieces that are useful for new-to-Java developers to learn, like converting between Strings and numbers.

So the challenge, now, is to make sure that I can adequately cover the same territory, and serve the same purposes, using servlets and JSPs. Not too hard, really, but it should make for a fun course where we can do a lot more hands-on, practical development work than the stock SL-275 allows.

The other tricky bit to watch is making sure that the level of detail doesn't overwhelm new-to-Java developers with too many web-application specifics. It is important to keep the focus on "Introduction to Java", and not lose sight of the real objective in a welter of webapp configuration and deployment.

Just a single, simple example of where and when customised courses can much better match the client's needs than any standardised, templatised training provided by a 4-week-per-month manual-pusher.
Contact me for a course customised to your organisation's needs!

18 January 2011

2011 Course Planning

Whew! Looks like March is going to be a busy month. I've planned no less than 3 courses back to back, so hard work ahead...

I'll be kicking off with the 5-day "Intro to Java" course on 7-11 March. It seems like Cape Town's demand for Java developers is insatiable. I've had requests from a couple of clients for this course simply because they just can't find good Java devs for their expanding teams, and they're going to be hiring developers with good OO experience from other (non-Java) environments and training them up for Java development as an alternative. Now, I know that any good developers loves learning new stuff, so I think these clients are doing a Good Thing by offering skills-development as part of their hiring process. My job is to give them the best possible Java Platform course, and I have great plans for delivering just that!

Next up will be the newly developed 5-day "Web Application Development with Servlets and JSP". If you've last looked at JSP technology a few years ago, possibly run away in terror at the sight of all the horrible in-page logic that made scriptlet-based JSPs such a nightmare for maintenance, then you really owe it to yourself to get up to speed with scriptlet-free, tag-based JSP development. The course includes topics on the new, new Servlet-3.0/JSP-2.2 enhancements that use annotation-based configuration.

And last, but not least, will be my much-acclaimed 4-day "OO Analysis and Design" course – thus fitting neatly into the 4 working days that remain after the Human Rights Day public-holiday.

I'm planning to run all the courses in Cape Town. (still looking for a great venue, so please drop me a line of you know of something extraordinary.)

Drop me a line if you're interested in any of these. Miss this opportunity at your own risk – I will probably not be scheduling courses in Cape Town again before August!

I'm offering an Early Bird discount of 20% to anybody who confirms a reservation before the end of January!

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

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. 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.

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?


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!

22 August 2008

Courseware: The Next Step

Just received my Instructor's Manual (only a week late!) for Sun's SL-425 "Architecting and Designing J2EE Applications"1 and I'm very happy to see that it is basically the same course as the old "Architecture and Design" course I taught several times lo' those many years ago when I was so frequently on my feet as "Herr Instructor".

This is easily the best2 course I ever "taught"! It is aimed a senior, experienced designers and developers3, and confronts head-on the sticky few-good-answers stuff, the ill-defined and the fuzzy grey areas. I have always run the course in a round-table "workshop" format. When you get 8 or 10 senior developers into a room, each with a decade or two of experience, you're not going to be their Teacher. And you sure as hell better not have a tender ego. "I don't know" is a frequent answer. The job is much more one of facilitation: Keeping discussion on-track, drawing quieter participants into the discussion, acknowledging expertise and encouraging people to share their (often vast!) experience. I found it hugely enjoyable to engage with seriously expert people, and to facilitate drawing out their expertise. And I learned a lot!

It has been a very long time that I have wanted to run this course again, so I'm looking forward to it hugely!

So: I have a couple of weeks to catch-up on the changes since last it taught facilitated this course. Mainly the technology has caught up with the tech: Where there was only CORBA or RMI a decade ago, there are now a host of J2EE technologies, and the course now includes them. Where a decade ago the whole idea of enterprise-architecture patterns was pretty new and unheard-of, now there's the J2EE Blueprints Catalogue (even if those yanks can't spell "Catalogue"!)

Of course I'll probably be unable to resist the temptation fo slipping in a few sly teasers about Jini and Javaspaces -- but Hey! Sun seem to encourage instructors to go beyond the boundaries of the course material, and encourage us to bring our own experience into the classroom. Or workshop in this case.

I am still thinking about floating my own version of this course, perhaps a little less attached to Java tech, so that more people might engage. The absolutely best runs of the course were when we had many people from different organisations and backgrounds. Cross-pollination really works. Ask plants!
[1] Is there such a word as "Architecting"? My spelling-chequer doesn't seam to think sew.

[2] "Best" from my point of view, anyway. Though, I can honestly report that every participant I've ever had on this course reported exactly the same sentiment!

[3] I don't believe the term/job-title "Architect" had any currency back then. Whilst it had certainly been invented4 it was certainly not popular. In fact there still was no such Job Title as "Software Designer" back then. My boss had to invent it for me!

[4] I believe that I was one of the (probably many) inventors of "Software Architect"a s a job title. Certainly not unique in that, though! Back in 1989 a technical career-path looked much like "Junior Programmer - Programmer - SeniorProgramer - Junior Systems Analyst - Systems Analyst - Senior Systems Analyst - Business Analyst..." I rejected the whole deal5 stating "Analysis is The Art of Taking Things Apart. I don't want to do that. I want to put things together, and that's called Design (and, at the high-end, Architecture)."

[5] ... in a bi-annual merit-assessment that became (in)famous as the one where I told my Manager, "If you want loyalty, get a dog! This is a business relationship; didn't you understand that?" Needless to say I got no increase that year. ;-)

13 June 2008

Otherwise Occupied

Spending my time preparing for a course -- "Introduction to Java Programming" -- for a Major Corp in CT next week. It's a course I must have presented dozens of time. Perhaps hundreds. But its been about 5 or 6 years. Actually, I did teach it once a year or two ago... I'm sure the company I did the work for were satisfied. I'm pretty sure my students were mostly happy. I wasn't. The break from teaching had left me rusty. God knows how many tiny but important details I left out by mistake. Did I talk about volatile variables?

In a 5-day "intro" course, there's not much time to fuck about. There's a certain set of Java's features that you simply have to talk about, at least in a simplified and superficial way, simply because your students are guaranteed to trip across them almost immediately they walk out of the classroom.

On the other hand -- let's be honest -- there's a limit to what the human brain can absorb in 5 days!

This time around its a little different. I'm teaching for a single company. The Program Manager's focus seems to be quite squarely on getting her people up-to-speed, and not on any other corporate ass-covering or thinly-veiled-reward-holiday-for-week sort of bullshit. Believe me, I've seen that crap all too often!

I was able to stretch the course schedule to 6 days instead of 5 -- a huge relief and I can take things at a slightly less frantic pace. I frankly don't quite know how I would fit the basics into a 5-day course anymore, given that one has to cover (at least at a shallow level) enums, annotations and generics. I guess that maybe the modules on threading and concurrency would have to fall away, but how the hell do you justify doing that when you absolutely know that your students are -- willingly or un- -- going to confronted with those as soon as you can say "Boo"?

Well, I've been working hard at getting my teach up to scratch, updating the (Day 2) OO module to include enums, and the (Day 4) module on the Collections API to teach generics, etc., etc. Of course my (development) contract customer is a little miffed that I'm not putting in 18 hour days for them... Tough Tittie -- their time is worth about 1/4 what I'll earn from teaching, and they've hardly made any effort to improve the disgusting working conditions!

I think it will be a killer course. I'm certainly aiming to make it so!

Along the way, Jason and I have been having some very entertaining discussion about the deeper, occult details of Java concurrency and system design. Something clicked last night; we both reached the conclusion that it would be fun (and probably educational for all concerned) to get more people in on that conversation, so we've revived my idea-of-many-years-standing -- a workshop/seminar format gathering, aimed at top-level, ten-years-plus-experience OO designers, architects and senior developers: A general framework to guide and channel discussion, aiming for an honest sharing experiences and learning. No fluff!

I facilitated (I would hardly dare claim "taught") one such many years ago, and, in my own humble opinion, it was the best course I ever led! I think that quite a few of the participants would agree with me. Certainly a majority of them kept in touch with me for an otherwise inexcusable number of years afterwards! After all this time, there still exists a huge gap in the professional-education space... beyond a certain level, expert practitioners (and I think it is true of any field, not just software design) have nobody to talk to -- nobody around them who is at a level where they can meaningfully push back on ideas -- nobody to brainstorm with. Or at least, far too few. The Advanced Practitioner Workshops would aim to try and (partially) fill that vacuum.

So maybe its back to teaching again for a while! It could be fun to focus on actually delivering actual deep learning for a change instead of just aiming to be Brilliant Clown For A Week!
Related Posts Plugin for WordPress, Blogger...