Pete Lacey’s Weblog

Based on Steve’s glowing review, I ordered a copy of “Release It!” And, wow! What Steve said. This is an extremely readable and informative book that every enterprise developer should read. But rather than heap more praise on Mr. Nygard, I thought I’d present here a few choice quote that resonated well with my RESTian world view.

Cynical software expects bad things to happen and is never surprised when they do.

The more tightly coupled the architecture, the greater the chance that [a] coding error can propagate. Conversely, the less coupled architectures act as shock absorbers, diminishing the effects of [an] error instead of amplifying them.

Your best bet is to keep as little in the session as possible. [Nothing, really. Ed.]

Hope is not a design method. [Sounds familiar. Ed.]

[This next one I’ll quote at length. Ideally, we should have all learned this a long time ago, but sadly that’s not the case. Ed.]

Integration point latency can be a serious performance problem. The problem becomes acute when the integration point uses some flavor of remote object protocol. The “location transparency” philosophy for remote objects claims that a caller should be unaware of the difference between a local call and a remote call. This philosophy has been widely discredited for two major reasons. First, remote calls exhibit different failure modes than local calls. They are vulnerable to network failures, failure in the remote process, and version mismatch between the caller and server, to name a few. Second, location transparency leads developers to design remote object interfaces the same way they would design local objects, resulting in a chatty interface. Such designs use multiple method calls for a single interaction. Each method call incurs its own latency penalty. The cumulative effect is a very slow response time.

A system that cannot adapt to its environment is stillborn

If this group [of enterprisey, ivory tower architects] has power, they will put projects on hold until the enterprise architecture is defined. If they do not have power, they will gnaw on their own livers as project after nonconforming project rolls into production without the benefit of their architecture.

Nothing hobbles a system’s ability to adapt quite like having other systems poking into its guts.

Clearly, there is value in avoiding this [tight] coupling [between systems]. It has undesirable effects on the time to market, deployment cost, and system availability. We must design protocols so that either endpoint can change independently of the other. [Or properly use one we already have. Ed.]

Of course, not every sentence rings as true as these. Here are two that fell a little flat.

When that invisible machinery [application servers magically dealing with cookies and sessions] involves layers of kludges meant to make HTTP look like a real application protocol, it can really tip over badly.

It’s understood that what Mike really meant to say was “… make HTTP look like a more familiar application protocol.”

The sad truth is that HTTP doesn’t handshake well. HTTP-based protocols, such as XML-RPC or WS-I Basic, have few options available for handshaking.

Again, to put words in Mike’s mouth, what he meant to say is that “Protocols that tunnel over HTTP, such as XML-RPC or WS-I Basic, have few options available for handshaking.”

BTW, what Mike means by handshaking in this regard is the ability for a server to protect itself by “throttling its own workload” in cooperation with a client. HTTP actually has a sizable number of mechanisms for limiting resource consumption including:

• Caching and conditional GETs
• Using HEAD and OPTIONS to query a server’s capabilities before attempting to use them
• Politely putting off processing till later (202 Accepted)
• Sending the work elsewhere (303 See Other, 305 Use Proxy, 307 Temporary Redirect)
• Simply refusing the work (503 Service Unavailable)
• Using “look-before-you-leap-requests” (Expect: 100 Continue)

Admittedly, some clients and servers are better than others at properly implementing support for these features, but that’s not to say they’re not there.

But none of this last bit is to say that “Release It!” is flawed. These are just two (and the only two) picayune things I could find. In every respect “Release It!” is just fantastic and is a must read for anyone developing enterprise apps. Not only does it have lots of fun, pithy quotes and entertaining war stories, it has real practical advice on how to create production ready software. Buy it!

Like most other Americans living remotely from the family nexus, I traveled home for Thanksgiving. While talking to my brother, he mentioned that “Joe (not his real name) said to say thanks for the advice. He followed it and now he’s doing very well.” It took a moment to jog my memory, but the “advice” was an email I sent to a colleague of my brother’s on how to position himself for a job in the technology sector. I dug up the email I sent nearly three years ago and found that it’s still largely applicable, so I’m posting it here. What advice would you give to the query that follows?

The Query (The subject of this post is the same as the email. My brother is retired from the Army, but still in the reserves as a Lt. Colonel.)

You told me to shoot you an email that you could forward to your brother, here it is. I still plan to give you a resume, but I don’t have that ready yet. This is more of a question about what knowledge to start building, and hopefully in what order. I don’t have a perfectly clear plan of where I want to go with this career-wise, either (which makes part A harder) but I do know that I’m really enjoying learning/doing this stuff. So, let me start with that; what I have learned/done and which parts I enjoyed most. The question for your brother, I guess, is where to build my strengths, where formal training is better vs. self-taught stuff, and which certifications might be essential/nice to have/a waste of time to go with the strength-building part.

So, a bit about my coming of age with computers. My formal training prior to this mobilization was just in database design, with a little bit of project management/software life cycle (that sort of thing) thrown in. I taught myself Access, Excel, a bit of SQL, and Visual Basic for Apps in the intervening years between my degree and this mobilization, and I completed a few small DB projects during that time as well (the most complex one to date you saw, the one I did for the unit. For your brother’s edification, it was a secured Access db designed to be shared by 12 users over a network drive. Most of its forms were linked to the user logged in (i.e. who you are determined what you saw as well as what you could do at the DB level)). It’s not an enormous project (equivalent to, say, something a small business owner would use to track inventory and sales data, if he had multiple employees providing the inputs), but I learned a lot about VBA and security implementation while doing it, as there was sensitive info (privacy act stuff, mostly).

Most recently, I’ve been trained by the Army on basic network design (OSI model, components, programming Cisco devices, subnetting, etc. Something that’s probably about the 75% solution toward getting a CCNA, if I go that route). I’m also doing online and hands-on training w/ Win Server 2k3, Exchange Server 2k3 and SQL Server 2k3, all of which are used by the Army in support of its tactical systems.

I’ve enjoyed pretty much everything I’ve learned so far, though I’m just at the start of the power curve on the Server stuff. The stuff that grabs me the most, I think, is still database design, and some of the programming, though I’m finding myself curious about web-app development, though I have yet to pursue that with any vigor since it doesn’t relate to my current job.

I’m considering doing some freelance work via eLance, Guru.com, or the like, to gain some experience, but I’m not sure how far I’ll be able to take that in terms of making it a career. Likewise, I don’t know what I don’t know in terms of learning/training. For example, I thought an ‘easy’ way to expand on my current knowledge might be to pick up Visual Studio to be able to create runtime apps based on Office components. That, in turn, led me to think that learning C# or Java might be a good step toward the future, but I’m not sure. It seems that there are a lot of projects available online for guys who know mySQL, perl, and php. So that makes me think that might be the right direction to go.

Hence, my call for advice. Thanks in advance for your time/consideration.

The Response (gently edited for grammar)

Joe,

Disclaimer; I’m biased and not all knowing. This is a long, un-proofed email, skip to the end for a shot at a concrete suggestion.

A question for you; are you planning on leaving the military, and getting a civilian IT job? Is that where these questions stem from? If not, learn what the Army wants you to know, and enjoy a fairly secure job. If so, then…

There’s no one answer to your questions. A lot depend on your goals and affinities. Lets break probable career goals into three (non-military) categories:

1. Stability
2. Money
3. Job satisfaction

They’re not mutually exclusive, but any one of them may be more or less difficult to attain given your age and knowledge level.

Stability: Nothing is stable. Some things, however, are more stable than others. Government jobs tend to be more stable, but for less money and old technology. Jobs in finance offer the most money, have all the good toys, but require a lot of expertise and are not stable during economic downturns. Mom and pops get by with a few Windows machines, Excel, and a VB app. Etc. Answering these questions first can help with the rest. None of what follows consider Mom and Pops as there needs are simplistic. It assumes firms of several hundred to tens of thousands of employees. It also doesn’t consider actually working for technology companies (Microsoft, IBM, etc.), though consulting companies are valid.

Like me and many others, you get a charge out of all aspects of technology. And while its good (required) to know a little bit about everything, you will need to specialize. So lets break the IT world into two pieces:

1. Hardware
2. Software

Hardware, in this case, means the guys that are racking and stacking servers, routers, disk arrays and such. They care about networks, and security, and uptime. Software means writing code, testing, and deploying applications. It means administrating software servers; i.e. databases, application servers, directory servers, etc.

Pick one of these now. If you choose hardware, then it’s especially hard to learn on your own. You can read all you want, and that’s good, but ultimately you won’t be able to afford any of this stuff, so you’ll have to learn on the company dime. That means an entry level position while they get you training or just throw you into the deep end of the pool. My thinking is that at your age you probably can’t financially afford to do this. A CCNE is an especially valuable accreditation, but it’s expensive and difficult.

If you choose software, well, that’s infinitely malleable, and there’s lots of specialties. But we’ll continue narrowing things down. What follows might seem brazen, but it is really where the world is now.

1. Microsoft
2. Everyone else

You have already started down the Microsoft path, and that’s fine. For that reason you may consider staying there. If so, let’s break that down a little further:

a. Client
b. Server

So far, you seem to have most of your experience on the client side. You’ll want to know this as a matter of course, but you do not want to specialize in it. No growth, no money, and not what larger firms care about. Knowing Visual Basic, Access, Excel, Office components, etc. doesn’t hurt, but that’s either Mom and Pop technology or fully baked at larger firms. Deploying and securing Windows to the desktop is a different story, but I find that tortuous and uninteresting, you can decide on your own.

The server aspect of MS technology is much more interesting and financially rewarding, simply because its much more difficult and MS is in the process of reinventing their offering. In this case, it’s all about .NET. If you’re not familiar with it, it may be hard for you to really discern what .NET is; here’s how most people currently define it. The C# and Visual Basic programming languages, the Common Language Runtime (CLR, a virtual machine), the .NET libraries, and a boat-load of best practices and design principles; chiefly web services (aka SOAP). Now, just like any technology, you can write simplistic applications with this technology. But your real goal should be understanding enterprise application development. The problem is that there’s a very steep learning curve here as there’s lots of technology in play, plus 30 years of aggregated design practices. Also, a lot of what’s entailed will be pretty heady stuff for a self-starter with a non-programming background. However, that’s also true for the non-Microsoft camp.

If being a .NET developer is not of interest to you, then there are always MS platforms that need managing. You’ve got some experience here, and it may be the place you want to start. Specifically Exchange, SharePoint, and SQL Server. Of these, SQL Server is the closest to business application development, and employers might want more experience than you currently have. If this is of interest, though, let the army train you, and if that training is not sufficient, explore on your own. Also remember, that resumes can be very creative. If you want to get ahead of the curve SQL Server 2005 (Yukon, in beta) has support for a technology called XQuery. XQuery will be a very big thing, and very few people know about it. You might want to look closely at that, so that when the XQuery jobs come, you’ll be ahead of the game.

Finally, there’s managing an MS infrastructure. This is an IT function half-way between all hardware and all software. It means making all those back-end systems work together. Specially it means MS Active Directory, Win2K and 2003, file and print services, and so on. Note, though, that very few companies are 100% MS in the server room.

If I had to wager on a fight between MS and Everyone Else, I’d pick Everyone Else (Note, I have anti-Microsoft tendencies). Remember Everyone Else includes IBM, Oracle, Sun, HP, SAP, the open source community, and nearly all non-US governments. So how do we factor out the Everyone Else technology? Not surprisingly, since Microsoft’s offering “emulates” Everyone Else’s offering, they look very similar. Just do a little name substitution:

Windows -> Unix (Solaris, AIX, HP/UX, Linux (especially Linux)).
C# -> Java
CLR -> JVM
.NET -> Java/J2EE
Active Directory -> LDAP
SQL Server -> Oracle, DB/2, PostgreSQL/MySQL
ASP -> JSP/PHP
Exchange -> Sendmail/Postfix/etc.

Of course, it’s not really that simple. But I would highly suggest that you look closely at these technologies. It’s cheap (free), there’s a TON of information available online, and it’s going to make larger and larger inroads. In my opinion, MS has lost a lot of it’s ability to influence corporate decisions. Firms now recognize that an inexpensive Linux solution provides as much or more functionality than a corresponding MS solution for a LOT less money. This means that they’ll be a migration away from MS towards Linux (open source); a wave you can still catch. From your point of view, Linux costs you nothing, databases cost you nothing, application servers, IDE’s, compilers, web servers, mail servers, and so on ad nauseum cost you nothing. The barrier to entry is not high.

So, if you’ve chosen the non-MS side where do you go? Well the same dichotomies exist: programmer, administrator, etc. If you choose to program, then the choices are:

1. Java
2. Non-Java
3. Both

I highly recommend Both, but that’s a lot to bite off. Java developers are in high demand, especially J2EE developers (similar to .NET developers), that is those guys that write complex enterprise systems. J2EE is a lot to get your head around, but fortunately for you there’s a recent upswell of resentment to the complexity of J2EE, which is being addressed by simpler, equally effective, platforms. Since this is new and likely to be sustained, this is another rewarding wave to catch. So, if you’re intrigued, go take a look at the open source Spring Framework. If you want to stick with J2EE, go download the open source JBoss.

In the non-Java camp there’s basically:

1. C
2. C++
3. Scripting languages

You will not find too many entry level C/C++ positions, but from a personal growth perspective you should become familiar with C. You do not understand computers until you’ve done your own memory management. Avoid C++ at all cost. You really should become familiar with the scripting languages. None of them will make you much money in corporate America, but all sorts of interesting things are going on there, and Perl at least is a prerequisite for using Unix. You should glance at Perl, Python, PHP, and Ruby. You do not need to know all of them — I don’t — but you should be aware of them. At this point, I don’t think there’s a lot of money in PHP/MySQL development. The jobs you’re finding are project jobs, and, as yet, steady corporate work specifically around these technologies is not there. I could be wrong on that, though.

Okay, now the databases. Being a DBA is a unique position, again straddling the line between programmer, administrator, and Nazi. A highly skilled Oracle DBA is very valuable. Less skilled ones will find employment. If you just want to learn more about databases in general, check out PostgreSQL. Ignore MySQL as a learning resource, it’s popular, but it ain’t a “real” database. Go ahead and learn it though, as a lot of apps are built on top of it — not business apps, though.

The list goes on and on (like this email), so I’ll stop enumerating everything.

There is, of course, a lot of technology that crosses boundaries. I’m intrigued that you have software development management experience. A good manager is a valuable find. Fundamentally, good project management skills are mostly what you need. Technology wise, you should be familiar with the current thinking about the “Software Development Life Cycle.” In particular, “Agile” development. That means Unit Testing, continuous integration, iterative design, and more. You might want to learn UML & RUP, but I’m loathe to recommend that.

Also, learn the Web and Web app development, be it PHP, ASP, JSP or whatever, but really understand it.

Security is a job unto itself. In fact, it’s several. Implementations are technology dependent, but the concepts are generic. However, you really have to _earn_ your security wings.

Learn XML. Learn XML. Learn XML. In particular focus on the core XML spec, XML Schema, and XPath. Indulge in a little XQuery too. Also look at XML parsers and processors; Saxon, Xerces, Xalan, and so on.

Practice fundamental coding techniques, that is data structures and algorithms. In the language of your choice, implement a hash function, a quick sort, a linked list, etc. It provides a positive grounding, just like learning C does. In fact, do this in C and you will have really learned something.

As for certifications, I’ve never had any. Word on the street is that outside of Cisco’s they’re all worthless. Yes, you’ll learn something if you go in there cold or even warm, but they won’t prepare you for the real world. Certifications won’t hurt the resume, but probably won’t buy you much either.

That’s it for now. I know I rambled, but it’s not a question you can answer definitively, especially since I don’t know you. To summarize: Choose hardware or software. I can’t provide much guidance if you choose hardware. If software, choose Microsoft or the rest of the world. If MS, then learn .NET. If the rest of the world, learn Java and J2EE or Spring. Unless you want to be a DBA or IT administrator

If you want a more concrete recommendation, I would recommend that you choose a role of Software Development Manager. These are important, financially rewarding roles that very few people do well. Typically this post is offered to ex-programmers who have exactly the wrong temperament for the job. As I understand it, the army helps build good project management skills. In your case, you even have some experience in the SDLC. I would bolster that with a study of Agile development techniques and a glance at RUP. This is not a tech-lite position. You have to understand the technologies that the software is being built on (e.g., Java, Oracle, Linux), and you have to understand the tools the software is being built with (e.g., Eclipse, JUnit, Ant, Subversion). It’s a high-paying job and I think satisfying for people who can really manage process and people (I can’t).

If you want to talk, let me know. We can do it for free with Skype. My Skype ID is xxxxxx.

Good Luck,
Pete

After Thoughts

If I were giving the same advice today, I don’t think I’d change too much. In retrospect, I may have made too much of XQuery, but I was playing with it at the time. This was pre-Rails and the dynamic language revolution, so I’d alter my advice slightly regarding Python and Ruby. I wasn’t a full-blown RESTian then, either, but I don’t think that would have changed my advice too much. I certainly would not recommend today spending a lot of time with XSD.

Now, this is interesting: Google Code for Educators. Lectures, labs, and teaching materials on current technology trends, e.g. map/reduce.

Via: Ian Davis.

Is REST over-hyped?  Is WS-* viable?  Is SOA evil?  Stefan steps up to the plate with RESTafarian SOA Killers.

Update:  My slides are here.  However, they’re not as effective without the demo.

What’s left to say? It seems everyone who participated in the SOA track, as a speaker or attendee, has already posted their thoughts. And others who could not attend have run with Stefan’s notes (go backwards from that link to see them all).

From my POV, it was a fantastic two days. All of the RESTians on the SOA track had excellent (if somewhat overlapping) presentations. The lone non-dyed-in-the-wool REST proponent, Sanjeeva, had a—uhm, err, shall I say—provocative presentation. So lets talk about some of the other sessions I was able to attend. On the Ruby track Obie Fernandez gave a presentation on “Designing RESTful Rails Applications.” I knew most of what Obie had to say already, but still learned a thing or two, and also learned that there’s more to learn. Must peak into the routing code. It was a good talk nonetheless, especially if you were Rails proficient, but new to RESTful application design. James Cox also gave an informative talk (with examples!) of what’s new in Rails 2.0. And Jay Fields gave a wonderfully intriguing talk on using Ruby to build “Business Natural Languages.” That is, highly specialized, English-like DSLs that can be used by subject matter experts to implement business rules. This talk was not a “gee, wouldn’t it be nice” kinda thing either. He’s really built them. With great success.

Brian Zimmer, lead architect at Orbitz, gave a talk on the Architecture Track about growing Orbitz both from an infrastructure and design viewpoint as well as from a U.S.-centric to a globally-capable system. Brian was a good speaker, but I can’t say I learned much. Rule #1 seems to be, don’t code yourself into a corner with U.S.-centric assumptions. Rule #2 seems to be don’t architect yourself into a corner with bad design choices. Both true. Both hard. But what really moved this talk from “green” to “yellow” for me, was his discussion on caching. In order for Orbitz to not beat the crap out of their partner’s systems, they cache results for a period of time (presumably based on SLAs, since there’s no cache control info on the wire), but their original, home-grown, caching solution didn’t scale. Brian described this system via the metaphor of a block of mailboxes that you might see in a post office or apartment building that could only hold so much information and only for a specific partner. And my thought was, well, who the heck designed that? They resolved the problem by purchasing a commercial caching solution, but he wouldn’t say which one.

James Noble presented Thursday’s keynote “The Lego Hypothesis.” With a somewhat over-the-top presentation style, James said the right thing: Google is our software repository, and developers reuse code snippets and libraries just as people have been saying we should — albeit, without being weighed down by issues like “correctness.”

I arrived late on Wednesday and so could only take in two sessions. The first had Chet Haase, Erik Meijer (LINQ), Charlie Nutter (JRuby), Joshua Bloch (large pieces of Java), and Rod Johnson (Spring) debating the future of Java. Everyone was (obviously) knowledgeable and pragmatic. They did not, however, all agree. I felt myself leaning towards Charlie’s answers which can be summed up as “it’s up to you, now.” I also managed to attend Wednesday’s closing presentation, “50 in 50,” delivered by the eminent Dr. Richard Gabriel; a bizarre, delightful, entertaining multimedia romp through the history of programming languages. My favorite? HQ9+.

That’s it. A wonderful conference made better by being able to meet many people face to face for the first time, including not only my fellow track speakers but Stu Charlton, Mike Herrick, Patrick Logan, and many others.

This is a long-delayed post.

Next week is QCon San Francisco. Stefan generously offered me a slot in the “Connecting SOA and the Web: How much REST do we need” track, alongside Steve Vinoski, Sanjiva Weerawarana, Dan Diephouse, and other luminaries. Woot.

For my part, I’ll be demonstrating the “ilities” of REST. Yes, rather than just explain things and have the audience take my word for it, I’ll be showing running code of a real (albeit simple) RESTful application. Thus, for the last two weeks, I’ve been busily learning Rails and enjoying its support for REST. It’s a simple app, and if I knew when I started what I know now, it could have been done in a day or two. No loss, I’ll be able to leverage this time for the REST Workshops I deliver as part of my Burton Group gig.

Of course the intent of the demo is not to show off Rails (I don’t plan too) or to prove how leet I am (I’m not), but to put an emphasis on the fact that something as mundane as a Web application, when properly designed, leads to accessible information and evolvable systems. I’d love to demonstrate scalability and performance too, but, hey, I’ll only have one laptop with me. (Oh, and VMWare rocks.)

Hope to see you there.