Rainy days and Java always get me down

I've Moved My Blog

It's currently located at http://www.urlinone.com/blog

I should say "I'm moving my blog." It's a pretty painful process.

Pebble has blown up on me, and it's been many months since I've been able to blog reliably. I've lost posts. And now I've got to figure out how to migrate my past blog posts from Pebble to my new destination without all the URLs changing, lest external links become 404 Not Founds.

Why does everything in the 21st century have to be a three-day project???

I suspect that a large part of what makes Ruby on Rails so captivating has to do with its promise of rapid web site development driven by entrepreneurial pursuits. (I know that's true for me.) Certainly, that's what motivated the 37signals guys, and look at what they did with it (backpack, basecamp, etc.). Most big and medium-sized companies are deeply entrenched in Java, and their idea of rapid (as in RAD) is far from what the midnight engineer or solo entrepreneur needs. There's a chasm between the needs of a major eCommerce site and that of a small business with a niche product or service to sell. You've only got so many hours of productive coding in you after long hours at your day job. You need genuinely rapid application development.

Code generation has always held great promise, and Rails is a great framework, but there is still a long row to hoe in creating a fully functional site that includes sales, memberships, affiliate links, not to mention all the magic known only to marketing gurus that make a site successful. I've been working for months on an idea that ought to be so easy, but there's so many little details to work out. Every time I think I'm approaching product launch, I turn a corner and spot three more weekend-long things that have to be done. Frankly, I'm exhausted.

It's frustrating when you can visualize the finished product, but it just never seems to get any closer. So, I just found this product that generates turn-key, marketing-savvy, ready-to-launch web sites with a ton of features -- the same features I've been coding for months! They're in PHP, not Rails or Java, but I don't care. I've come to realize that I've got to not be so pedantic (read anal ;) about that. I'm trying to make money, not defend a technology. With this, I can focus on what makes my application unique without spending time reinventing the wheel just because I know how to.

I have found that my success in business has actually been impeded by the fact that I am a software engineer. Because I know how to code this stuff, it doesn't mean that I have to. And yet, I am compelled to do so, rather than download it, buy it, or even outsource it. I'm not sure if it's ego, uncertainty about the process, or just wanting to have things just so, but I'm through with that modus operandi. What about you? Has your ability to write code ever prevented you from working smart, rather than hard?

I'm telling you, I've done some cool stuff over the years. Okay, I've never actually told you before, but I'm telling you now: I've done some cool stuff over the years. Would someone who hasn't done cool stuff over the years have a blog category named Cool Stuff I've Done? I don't think so.

Not terribly impressive, but more of a "Huh." kind of a thing was Sanity Saver, something I wrote and "marketed" (in the loosest and least lucrative sense of the word) about fifteen or twenty years ago. I had forgotten about it until I saw this.

My tag line for SanitySaver was:

You use a screen saver to prevent monitor burn-in.

Use Sanity Saver to prevent user burn-out.

Do you see what I did there? Did you catch that twist? Pretty damn catchy, eh? It's a gift. I am merely the instrument.

The thing is, I think I can rightfully claim to have pioneered and established the entire software-that-reminds-you-that-you-are-a-living-organism-that-has-a- physical-body-with-biological-needs market segment, although I don't believe I am recognized as such in the industry.

Of course, it made me quite wealthy, and I retired to raise and race ferrets on the median-sized island off the coast of Microamnesia. I only came out of retirement because I missed the exquisite torture of software development.

I don't remember whether it was Sanity Saver or SanitySaver, so I've alternated use of each to cover all my bases. (All of which are belong to us, BTW.)

Quick Tip

If you can plainly see your SVG text in Inkscape, but you can't see it in your browser, try this:

  1. Select the text in Inkscape
  2. In the Text menu, select Convert to Text
  3. Save the document again
  4. Refresh your browser

I'm not sure what the point is of having the default text be of a type that doesn't show up in Adobe's latest SVG plug-in, but I would imagine this is a bug.

I hope that helps someone, because it drove me nuts!

Having dubbed this blog "JCranky," I can certainly sympathize with Andrew's rant. However, as a drinker and provider of SOA-flavored Kool-Aid™ for one of the top ESB vendors, I feel compelled to defend my wares and the substantial technology behind them. Here are a few things to keep in mind that may be less than obvious to the casual observer.

  1. Don't confuse SOA with Web Services. They are absolutely not the same thing. You can write horrible, tightly-coupled spaghetti code using Web Services. Conversely, you can create a beautiful, loosely-coupled SOA implementation without ever calling or exposing a single web service. The key to SOA is the architecture, not the use of web services. Service Oriented Architecture and Web Services are related in the same way that Java and JavaScript are. Just because you can do a substring() and find a word in common, that doesn't make the two equivalent.
  2. SOA doesn't have to be expensive or painful. The big challenge is that it requires a change in thinking on the part of your architects and engineers. The principles of SOA seem obvious and intuitive, but once you start working in that mode, you find yourself trying to map the new ways to the old ways and getting a little lost in between. (I'm old enough to have made the transition from procedural coding to OOP. I remember feeling lost for about a year, as I struggled to rewire my brain to think in the new paradigm. For me, SOA demanded a comparable transition. Interestingly, OOP and SOA require a similar initial investment and offer a similar downstream ROI. You might even say that SOA is the next quantum level of OOP... Then again, you might not.)
  3. SOA is about loose coupling and abstraction of coarse-grained services, so RPC is quite far from a panacea. In fact, it's more like the same old thing. To create truly reusable services, you need to think more along the lines of document-oriented messaging. In the SOAP world, you'll find more agility and tolerance for change when web services are doc/literal rather than rpc/literal. RPC is not much more than running the same old functions on another machine. This does not constitute SOA. Do not confuse calling a publicly-exposed function with creating a service-oriented architecture.
  4. I have no issue with Andrew's comments about IBM Global Services. ;-)

I'm not picking on Andrew. In this sea of TLAs and daily "Next Big Things," I certainly feel his pain. But there are legitimate advantages here, and, like it or not, we're all going to be forced to deal with SOA in the near future. We might as well have a better understanding of what it is -- and maybe even a little appreciation. It's a pretty elegant, robust architecture with tangible benefits. So says the guy high on the Kool-Aid™.

My opinions do not necessarily reflect those of my employer, my colleagues, or my superiors (of which there are many). Nothing in this blog is sanctioned, approved, or reviewed by anyone. Not even me.