When is a Service also a Resource
Posted by Jim Jagielski on Monday, November 27. 2006 in Programming
Ignoring for the moment the potential "issues" of various competing projects, Sanjiva's post describing his view on, basically, how to expose a service as a resource is interesting.
More...
Performance tuning
Posted by Jim Jagielski on Monday, November 20. 2006 in Programming
While checking out a suggested patch for Telaen, I noticed a lot of places where the code does a regex check instead of a more simple string comparison. This is done when checking for the response back from the POP3 server and is looking for a response that starts with '+OK'. Using 'ereg' (Telaen is written in PHP) seemed overkill to me, plus I made the assumption that doing a simple 'substr' and comparison would be faster as well. But would it?
Since this check is only done after sending the POP3 server a command, it's done pretty rarely, most of the time spent is in disk and network I/O. I did some profiling and, in typical cases, the difference was pretty much in-the-noise, but in cases with lots of small Email messages, there really was a small but noticable difference.
Of course, even so, if the "faster" code wasn't any clearer, then I doubt I would even have made the change... but, IMO, this change did make the code more easily read, but mostly due to that nasty little '+' in there, which could trip people up in the regex. Kernighan and Pike are right.
More...
So Simple It's Scary
Posted by Jim Jagielski on Friday, November 17. 2006 in Programming
This would be even funnier if it wasn't so true.
More...
SOA != ESB
Posted by Jim Jagielski on Monday, November 13. 2006 in Programming
IMO, SOA runs the very real danger of being so overhyped that it dies a horrible and untimely death. Not so much because it's a "technology" that doesn't meet the hype, but rather it's a definition defined several different ways, and a horrible, but widely held, interpretation of the term, can easily be the killing stroke.
Of course, one danger is that people think of SOA as a technology, but it's not; it's a mindset, an ideology. Unfortunately, either SOA advocates don't make that clear (which confuses people) or else try to actively avoid saying it (which makes people think they are being sneaky). I've found that most places that do a better job at defining what SOA is, and isn't, are those that are promoting REST... if you want to know SOA, google REST.
Another problem is that too many places associate the theology of SOA with a bus-centric implementation (ESB) (or some other specific implementation), so if the implementation sucks, then so does SOA itself. This is, of course, unfair to SOA and to the many ESB and non-ESB implementations that do do it right.
And finally, SOA itself doesn't require, IMO, a "centric" approach at all... at least not when you consider what is core to SOA. But again, sometimes that isn't made clear, and people are afraid that an environment that is SOA "compliant" cannot at the same time be lightweight. People want simple. But of course, that is starting to sound more like REST (real REST, not just HTTP+POX) than SOA at all, so I'll stop there.
More...
Active and reactive code review
Posted by Jim Jagielski on Friday, November 10. 2006 in Programming
For any software project, continual code review is crucial. In general, there are 2 methods, at least regarding how I do it.
The first is what I call active review. That's when I take time out and pick out a code segment at (semi) random and just read it. I follow any function or method calls and track how the code works. Is it logical? Is it robust? What improvements can be made? I usually find at least some way to make it better.
The second is reactive and it generally occurs either when tracking down a bug, or when evaluating a patch. I follow the same procedure as with active, but the starting point is obviously different. The cool thing is that most of the time, in addition to fixing the bug (or validating the patch), I almost always discover something which can be improved or fixed. A good example of this just happened: we're looking at possibly doing a release of Apache HTTPD 2.2.4 in the very near future, and one potential backport was being discussed. This got me looking not only at the backport code itself, but the other functions that the code uses. This lead me to our implementation of
More...
apr_socket_recvfrom() in APR. Unlike the "real" recvfrom(), ours requires a from argument. In fact, if you look at some of the various test scripts, they have to go out of their way to create bogus from info to test the function. Why? Certainly it makes sense that one should allow a NULL from, and have apr_socket_recvfrom() do the right thing... posting this to the APR dev list indicated that other APR developers thought so as well, so I'm going to spend some time implementing that.
Sometimes it's the unexpected byproducts of reviews that are the most beneficial.
Page 1 of 1, totaling 5 entries
Syndicate This Blog
