Skip to content

Lesson One: REST from the Beginning

Lesson One is finally up (and, yes, this is about the pace you can expect). It’s a brief discussion on the Lean and pragmatic approach that Pasithea will be taking in developing Xprest and how the development team got REST into the system from the get go.

Next up: A roadmap for Xprest and Lesson Two: Authentication (most likely).

Tagged

Lesson Zero

Lesson 0 of the Xprest project is up.

http://code.google.com/p/xprest/wiki/DevelopmentEnvironment

It’s mostly just installation and configuration information, nothing terribly REST-oriented.  But you might want to give it a read through if you’re planning on following along.  There’s also a nugget or two in there and a question for you, dear reader.

Tagged

Introducing the Xprest Project

The good people at Pasithea Corp have assembled a core team of IT, HR, and Accounting people to specify and build the new expense report management system, code named Xprest.

There’s not much there yet and what’s there is pretty dull, but here are the initial documents to start driving the project forward.

As you can see, I’ll be using Google Code to host this project.  And that includes not just the code, but the stories, epics, themes, and defects that will drive its creation.  As well as the textual explanation of how to build such a system RESTfully.

That last bit is problematic.  The good points are it allows people to track the project incrementally (assuming you’re completely without a life), maintains a persistent record of changes, and, should we get this far, allows me to open the project to other contributors.  The down side is that the Google Code wiki is pretty anemic and the resulting HTML will not be so easily transformed into something more suitable for printing.  We’ll see how it goes.

Stay tuned for our first few stories.

Tagged ,

I picked a bad week to start blogging again

There will be a slight delay in getting the RESTful design project off the ground.  We are experiencing some run-up to 1.0 madness.  Real blogging to commence shortly.  I promise.  Honest.

New Year, New Post

My last post was twelve months ago today. And since then I have never worked harder nor have had more fun doing so than I have in helping to create TriSano. Today is also auspicious in that we will cut 1.0 RC2 in a few hours. All in all, it seems like a good time to start blogging again.

This time, however, I have a plan.

Yes, I’m still a proponent of REST. More so than ever, in fact. But my proselytizing days are over. For the next bit of time I plan to take a more pragmatic approach to assisting others to design and build scalable, resilient, Web APIs by showing step by step and line by line how to build a RESTful application and why.

But we won’t build yet another blogging application or social networking, Web 4.0 thingy. What’s needed here is an example of a typical, erm, enterprise application. Problem is, many enterprise applications are industry specific. Such things as trading applications, life insurance applications, loan management applications. What’s more, these kinds of applications are way too complicated to be used for example purposes. But there’s one application I can think of, one I used when explaining REST as a Burton Group consultant, that exemplifies most typical enterprise use cases and is universally understood: expense report management system. It’s got it all: it’s reasonably straightforward, it’s got typical database-oriented functionality, there are stateful resources (an expense report can be open, submitted, approved, etc.), authentication and authorization requirements, and, if we get this far, integration.

I have not already designed or built this application. Instead, we’ll be nice and lean and refine things as we go along. I’ll be using Rails for this, which some might find un-enterprisey, but one fight at a time. If you’re not using Rails or something similar for enterprise Web applications, well, get over it. There’s no more excuses. Besides Rails is something I’m currently familiar with, it’s got REST baked right in, and, honestly, it works. That and we have all these exciting things happening these days with Rack and Metal and Merb and so on.

So, for the next few months, I hope you follow along and contribute as together we build a RESTful enterprise expense reporting system. I will most likely host the code over on Google Code, and will keep the text distinct from this blog. Comments, of course, are extremely welcome. Those related to REST and Rails especially so. Just bear in mind that this project will be starting small and building. So if you see, for instance, that I’ve not used ETags where I should have, then that’s likely because I haven’t gotten there yet. That said, if it looks like I’ve covered a topic, and it’s wrong or could be better, then, by all means, correct me. All content will be licensed under the most liberal of Creative Commons licenses, the Attribution license.

Good to be back. Talk soon

New Year. New Gig.

So, I took Mike up on his offer. Starting this coming Monday, January 7th, 2008, I will be a full time employee of Collaborative Software Initiative. This was not a terribly easy decision to make because at virtually the same time that I was talking to Mike, Burton Group, my current employer, asked me to step up to an analyst position and help make 2008 the year of REST. Had the timing been just a little bit different, I would have happily went that route. But as it is, after nearly three and a half years of fighting the good fight privately and publicly, and just as the message is starting to resonate, I’m moving on.

Why? Short answer: it’s time to shut up and code. Even though I was a consultant at Burton Group, my deliverables were reports. “Here’s 30 pages on how you might want to re-architect your software. Here’s 40 pages on why ESBs suck. Here’s 25 pages stating that yes, you can run PeopleSoft on Linux. ” Don’t get me wrong, these were mostly fun projects, but, man, sometimes you just gotta code. I can’t feel good about my work for customers or even my opinions here on this blog, if it’s been 3, 5, 10 years since I moved an app into production. And an analyst position, while prestigious and to some degree influential, doesn’t change that.

Of course, if it was just coding I was after, I could have taken a development job at BigBank or BigPharma, but the CSI gig is more than that. CSI has a unique and appealing (especially to this freetard) business model. The short of it is as follows: You, BigBank or BigPhara or BigManufacturer, require the use of a lot of domain specific software that affords you no competitive advantage; say to satisfy regulatory requirements. Now you could develop this in house, and that would cost you a $1,000,000. Or you could outsource it to Elbonia, but that’s still $500,000 and you never really know about quality. And in both cases you’re stuck with hosting and maintaining that codebase for a very long time. Or you could collaborate with others in your industry (remember this software has no competitive advantage), chip in some smaller number of dollars, and CSI will do it for you—professionally—and with you very much part of the project team. Not only that, we’ll be using open source tools the whole way. Indeed, the final product will be open source (that’s the cool bit, BTW), so that as development continues by CSI, yourselves, or your competitors—whether they payed to play or not—you benefit. Sure, someone could make changes locally and not give them back, but really we’re talking about compliance issues and other boring, non-competitive things, so why bother?

Back to the analyst thing for a moment. Research and Analysis (R&A) firms can provide a very valuable service, especially if you are largely unfamiliar with the wherefores and whatnots of a particular technology domain. For instance, Burton Group has a relatively new Data Center Strategies service whose content is, to me, someone who knows next to nothing about SANs and virtualization and ITIL, deeply informative. Burton Group also differs greatly from the big name R&A firms in that, by and large, our content is extremely technical and aimed at a technical audience. Nor do we attempt to cover every aspect of the technology industry, such as microprocessors, consumer technologies, or ERP systems. And we do not write reports for a fee. Furthermore, our analysts are, to a person, ridiculously smart. Thus, our customers get the focused and well-reasoned guidance they pay for. Plus the convenience of not having to go looking for it themselves.

That said, our analysts are human. They have biases, imperfect knowledge, and limited viewpoints just as we all do. These human foibles may not be significant when it comes to networking or telecoms or managing the data center (maybe they are, don’t know), but when it comes to the somewhat more subjective world of software development, application design, and enterprise architecture, the ramifications can be significant. Furthermore, R&A firms suffer from the very real problem of being a largely one-way medium: we write it, you read it, with limited feedback, little fine-tuning, and little exposure to alternative thinking. In addition, and for obvious reasons, most R&A content lives behind a pay wall, which to me at least seems like a pretty limiting means of promoting knowledge and effecting change in the enterprise, among vendors, and in the world at large. I would go so far as to say that Sam Ruby’s blog, for instance, has done more to change the world than the millions of pages minted by R&A firms that only a select few get to read.

However, the path from Sam’s blog to the enterprise is circuitous. In an ideal world enterprise technologists, from senior management on down, would be subscribed to that section of the blogosphere that is related to their trade; they can buy the same books, read the same papers, and attend the same conferences. But by and large they still don’t hear you. Instead, as Sam wrangles with Unicode issues in Ruby 1.9, Ruby improves and awareness is raised that Unicode is indeed tractable. And soon it becomes the norm that English/Western biases are no longer acceptable. Also, because Ruby improves, Rails improves. As Rails (or Merb or whatever) grows in popularity, so too does iterative development, a focus on testing, a recognition that dynamic languages are not toys. Then the vendors start adding DRY principles to their products, adding support for Ruby and Python, recognizing that REST really makes sense. And then, finally, these notions begin to trickle into the enterprise such that it starts to look like the rest of the world did ten years prior.

In short, the R&A industry can and does provide valuable information, all nicely consolidated. And the content produced is formulated perfectly for the chosen consumer. But, at least as it pertains to software development, if you’re looking for timely, informed, and practical information from the people who are actually doing it, nothing beats the continuous feedback loop of the Web. Your job is to find the signal in the noise and make your own informed decisions.

Now it’s time to install Ubuntu onto my new Thinkpad.

By the way, you may be wondering how I got this job. Here’s how.

Michael Nygard, where have you been all my life?

I know my previous post was on how great a book Release It! is, but have you subscribed to Michael’s blog, Wide Awake Developers? In particular, did you see Budgetecture and its ugly cousins? Beautiful. There’s lots of fun quotes in this short post, but here’s the one I like best.

Of course, if databases didn’t cost so much, nobody would care how many of them there are. Which is why MySQL, Postgres, SQLite, and the others are really so useful. It’s not an issue to create twenty or thirty instances of a free database. There’s no need to collect them up into a grand “enterprise data architecture”. In fact, exactly the opposite is true. You can finally let independent business units evolve independently. Independent services can own their own data stores, and never let other applications stick their fingers into its guts.

Oh, boy! This is good stuff.

Release It!

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!

I want to know everything, so where do I start?

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.

Google Code for Educators

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

Via: Ian Davis.