Important Android change for IntelliJ IDEA 10.5 users

The ever-productive guys over at JetBrains have released the new 10.5 version of IDEA, their flagship Java IDE.  IDEA has been my weapon of choice for over a decade now, and I still just love it over the competition - of course I know there are cases to be made for other environments too, and certainly to each their own.  IDEA just feels right for me.

Check out this blog entry if you use IDEA as an Android development environment and upgrade to 10.5.  They've changed the way Android SDKs are modeled, so the Android SDK is the project SDK in the new world, as opposed to having the Android SDK "bolted on" to a module.  This ends up being much nicer, but I found that the supposed "transparent / automatic" upgrade did not work for my projects.  Luckily, the process of setting up the SDK takes about 20 seconds - you just need to stop looking for the setting in the old location. :)

Hope everyone (in the US anyway) had a terrific holiday weekend!

Handy Android Debugging Tip!

Well, completely ignoring the 2+ year hiatus since I last wrote on this blog (hi all you folks who are still subscribed!), wanted to note down a quick tip for Android developers.  I've been working on a new project lately which has me working in Rails and Android, and I'm having a blast with both.

When building your awesome Android app, you'll often use the logcat output to debug stuff.  Example:

log.d(Constants.REMOVE, "Last updated date is " + lastUpdated.toString());

So, here's the cheesy-simple tip.  Sometimes you want to get the context of exactly how you got to the method in question when logging something like this.  In the case above, this is in the midst of deserializing some JSON and we could get to this code down a variety of paths.  So to get a stacktrace in your log output, just use the other form of the Log call (such as you might normally do within a catch block) with a freshly-minted Exception that you don't throw:

log.d(Constants.REMOVE, "Last updated date is " + lastUpdated.toString(), new Exception());

And voilà!  (by the way, I use the Constants.REMOVE tag for transient debug logging, so that I can do an easy sweep of my code to remove them before checkins)

Debugging Multi-hop SOA Interactions Simply?

Hi y'all! Back to blogging for now, it seems. :)

A brief Glen-update before we proceed to the subject of this post - I've been having a pretty good year so far, and have been doing a lot of thinking about social technologies and how to make them work better together. I've been doing a fair bit of tweeting, and enjoying the progress on foaf+ssl. I'm consulting right now, helping out a university with an ESB RFP, which is fun in that I'm enjoying being on the client side of one of these things for once. :) I've got my eyes open looking for the Next Step, which might be continued consulting or might involve taking a Real Job. Will keep you posted.

OK. So I've been thinking about debugging complex SOA interactions which might involve multiple layers of intermediaries - proxies on the client side, ESBs, etc. What I want is either the ability to collect log information in a message as it flows through nodes along a message path, or the ability to have each node log some information to a remote logging service, correlated in some way so it's clear all the logs relating to a given message flow (process/composition) are together. There are certainly some SOA Management products out there on the market (AmberPoint, Actional, etc) which can handle this kind of thing, but I'd like a simple, ideally Open Source solution.

Along these lines, are there any common SOAP extensions that function similarly to either traceroute or syslog? What I want is something like either this:

<soap:header>
<dbg:tracepad role="next" relay="true">
  <step nodeid="identifier of this node">
    Each node along the way has the opportunity/responsibility to
    add a "step" containing whatever information it feels like injecting.
    It then ensures that this header is inserted into the outgoing
    message(s) heading further down the message path.
  </step>
</dbg:tracepad>
</soap:header>

...where debugging info can collect in the message, or like this:

<soap:header>
 <dbg:log role="next" relay="true">
  <id>correlator-for-this-process</id>
  <logger>http://example.com/logService</logger>
 </dbg:log>
</soap:header> 

...where each node gets a pointer to a logging service (could even literally be syslog, or Hyperic, or Nagios) and some configuration including in particular a correlation ID. Then clearly it's up to the logging service to show you nicely structured output with everything lined up.

Of course both of these ideas require plugins (Axis2 Modules, JAX-WS Handlers, etc) that support the desired functionality for all the platforms you want it to work with.

Is this a niche waiting to be filled, or does this exist already in some non-proprietary form?

UPDATE : look at that, Mark Little was clearly thinking along the same lines recently - check out his InfoQ article asking about SOA testing tools...

Farewell 2008, don't let the door hit you in the ass on the way out :)

2008 has been a tumultuous year. It's been busier than most of the years in recent memory, both socially and work-wise. It's been filled with intense events - both positive and negative.

There has been way too much sickness this year. I've been sick a couple of times (coinciding with my birthday and Christmas, bleh), but that's nothing compared to the folks in my world that had serious medical issues. My friend Dave had a stroke this summer (he's 40) - thankfully it was caught right away and after some rehab he's doing *really* well now, slightly over six months later. My friend Adam (35) was suddenly struck with Gullain-Barre Syndrome and is currently in the hospital where he's been for over a month now - he's just regaining some small ability to move his hands and legs, but still can't talk (he's breathing through a tracheostomy) or move much. This is one of the healthiest people I know - WTF??? We know his road to recovery will be long but he'll get there. Still other friends lost relatives or dealt with their own illness, and the number of folks who caught the flu this fall/winter was outrageous.

Those of you who know me well know how much my cats Kaju and Kasha have meant to me over the last 8.5 years. When Kaju was diagnosed with lymphoma in March, I was devastated. She had almost 8 more months with us thanks to chemotherapy, but it wasn't nearly enough. We had to put her down the day of my 40th birthday party - oh my that was an odd day.

My tenure as WSO2's Director of Java Platforms is over (see Sanjiva's note). I'll still hopefully be doing some consulting work for WSO2, and I believe strongly in their mission. But for now, I'm sort of lazily looking around for my next gig - if you have any ideas or things I should consider, drop me a line! I'm focusing on consulting for now but would consider the right full-time opportunity if something awesome came up. In the meanwhile I'm hoping to stretch my brain a bit learning some new stuff (FaceBook and Android development).

And then there was the economy. 'Nuff said.

So, that's some of the unfortunate stuff. On the bright side - well, there's the obvious. :) Perhaps the most exciting political moment for the US in my lifetime, and I got to watch it happen while sitting with fabulous people in New Orleans at ApacheCon. Although things were intensely busy, so much of it was wonderful - four weddings in close succession over the summer, the birth of my fantastic nephew Jason, discovering Twitter and FaceBook, doing some great work with WSO2, and spending time with friends new and old. I threw April a fantastic 40th birthday party, and then she threw me one. :) Our relationship has been a focus this year as well, and we've both been growing with and around each other in some wonderful ways. I feel truly blessed to be a part of the community of brilliant, creative, and caring people that surround me.

2009 has the potential to be a pivotal, and very healing, year for us as individuals, as an overlapping set of communities, and as a nation. I hope we fulfill that promise, and I'm ready to do what I can to make it happen.

With an open and spacious hope for the future, I wish you all a very very happy new year. As Savas says, "Be happy, love, and smile!"

Give it a REST...

Sanjiva lets fly with a rebuttal to Tim Bray's comments on REST and its relationship to SOAP, Java, and the multi-language divide.

Although I'm getting a little tired of saying it these days, I think it's clear that both SOAP and REST are here to stay.  There are some situations where you could use either (or both), but there are also a bunch where there is a clear winner - just like there are some cases where TCP is the right protocol, and others where UDP is better.  Use the right technology for the right situation.  Don't break the web.  And you'll be fine.

SOAP isn't "an embarrassing failure".  REST isn't "insufficient for the enterprise". Can we get on with the good stuff now? :)

WSO2's Semantic Web Initiative... wait, what?

We had a nice chat with Rich Seeley from SearchSOA a little while ago, all about the new 1.1 release of the WSO2 Registry.  Rich wrote up the conversation in this article, but he seems to have focused a bit too narrowly on the "triples" aspect. :)

It looks like Rich conflated our discussion of the extension points in the Registry with the talk about associations.  Not a truly egregious error, to be sure, but one that does mask some of what we're doing.

The extension points in the Registry are designed to enable serious customization in two ways - first, Filters/Handlers let you install interceptors that control the existing Registry behavior.  For example, you can set it up so that whenever a put() matching certain conditions (let's say where the target URL matches "/pictures/*") occurs, a Handler can check that the size of the new resource is under a certain threshold before the put() is allowed to complete.  Handlers are great for inserting custom governance rules, or for performing automated tasks triggered by normal Registry actions.  We use these for our WSDL validation and auto-importing XSD Schemas that are imported from WSDLs or Schemas.

The second extension point is called Aspects, and using Aspects allows you to add new behavior beyond the standard put/get/delete and our various built-in community features.  The out-of-the-box example we have for this is Lifecycles, where we let you configure a chain of states and, optionally, conditions which control the transition from state to state.  The Lifecyle aspect adds the "promote" and "demote" actions to any resource which has a Lifecycle associated with it.  But Aspects can be used to make any arbitrary behavior occur, so for instance spell-checking, triggering an external build process, sending email to someone, etc...

So, we also do of course now support arbitrarily typed associations, so you can say stuff like "document D1 references service S1" (this might be documentation for a Web service) or "picture foo.jpg is-a-photo-of http://glendaniels.blogspot.com".  These are the actual triples, and they do represent what are essentially subject-verb-object relationships.  The subjects are always Registry resources in our world, the relationship types are arbitrary strings (which may, and probably should, be URLs), and the objects (or "targets") are either relative URLs from the Registry root, in which case they are other resources in the Registry, or absolute URLs in which case they point to Web resources.

The important takeaway here is that our extension model isn't entirely built on the triple system.  Triples are just one way you can use the Registry to build out a network of behaviors and relationships that best reflects your particular set of data.

Trying out Windows Live Writer

Yep, it's time for an offline blogging client.  I've heard good things about Windows Live Writer, so trying it out right now.  It's got a feature where it analyzes the look (i.e. theme) of your weblog at install-time so it can give you an accurate preview of what your posts will look like.  It at least got the sizes and fonts right!

Definitely seems cool so far, so we'll give it a run and see how it goes.  Stay tuned for actual content next post.