Sunday, September 30, 2007

short-sighted

I recently finished Jan Crawford Greenburg's latest book, Supreme Conflict: The Inside Story of the Struggle for Control of the United States Supreme Court, and I have to say, it was remarkably even-handed given its topic. Details from the personal notes and memos of nine current and former Supreme Court justices provide some insight into how the Court runs; a revealing interview with Justice O'Connor adds some extra drama, explaining her early retirement and how we came to have two SCOTUS vacancies at the same time. It was all very personal, and not terribly political. I would recommend it to anyone who finds the judicial branch somewhat mysterious and wants to understand how it affects the lives of average people.

There were two things that came up repeatedly in Supreme Conflict, and neither was particularly encouraging. The first item was how small the political network is in and around Washington. The book covers SCOTUS appointments from the Reagan Administration through Samuel Alito, but during those thirty years, no more than a dozen or so candidates are considered by other side of the American political spectrum. It is clear that if you were not able to land an appointment to the 4th circuit federal appeals court (which requires knowing and having worked with one or more of the president's advisors), the cards are stacked against you and your dreams of serving in the Court. Judges from other appellate courts in other parts of the country are occasionally considered (like the aforementioned Alito), but the vast majority were nominated because top advisors wanted to push their favorites, and said favorites had the opportunity to participate in the Washington, D.C. social network. Geography-based judicial nominations seem incredibly... injudicious... even for politicians.

The second item was how abortion became the primary issue - if not the only issue - that influenced a candidate's support from legislators and the public. No other issue even comes close. In reading the notes and transcripts provided by multiple instances of the executive branch, it is hard to find more than a token concern paid to other issues that the Court might face. Homosexuality, education, property rights, medical marijuana, the Pledge of Allegiance, government surveillance - these things were mentioned, but none was ever a deal breaker. Abortion is the ultimate deal breaker.

I think it's fair to say that putting so much weight on one issue is bound to negatively affect decisions made on other issues. In every case that does not involve abortion, a justice is forced to spend lots of time and mental energy weighing how his opinion in the case may affect current or future abortion-related cases; he may be pressured to make a sub-optimal decision because he is afraid the optimal one may eventually lead to politically unpopular action on the abortion front.

Justices may not face elections or popularity polls, but they certainly face pressure from politicians, friends of the Court, and talking heads who can demonize them as the face of the enemy. Even notoriously independent and aloof justices like Stevens and Thomas must be affected the pressure. No one wants to go into the history books because of a decision that was really a side effect. That's a lot of stress to put on a person who already has pages and pages of case history and legal arguments to absorb.

Finally, I know that if I were appealing a decision that had a major impact on my life and revolved around, say, privacy, I wouldn't want to be short-changed because Justice Bob was worried about the implications to the pro-X crowd. Despite its prominence in the national discussion over Court rulings, abortion-related cases don't make their way onto the docket very often, and yet these potential cases have a significant affect on topics as disparate as gay rights and terrorism. I'm sure this is a fun twist for the lawyers arguing before the Court.

Despite these common themes of cronyism and questionable priorities, the book was great and I enjoyed the opportunity to blog about one of my favorite subjects: consitutional law. Did you like how I mixed in issues that were "critical" to both liberals and conservatives and used variables in order to hide my own opinions? Aren't corporate blogs fun?

Update: I shouldn't have tried to write this post in such a short period of time. I've cleaned up some of the minor problems, but I still wish I had let it simmer a while longer.

Labels: , ,

Friday, September 21, 2007

voracious

When I first moved to North Carolina, I was fortunate enough to live in apartment complexes that were surrounded by forests and swamp land. During the spring and summer months, I would sleep with bedroom windows open and listen to the crickets and the bullfrogs talk to each other. The only downside of doing this was that I couldn't sleep in on the weekends, because by 10:00 a.m. my apartment would be roasting in the Carolina heat; few things in life are perfect.

Anyway, it was always very serene, and it upset me greatly when the twenty acres of undeveloped land across from my last apartment was torn apart and turned into a Harris Teeter. Not only did it add an obnoxious amount of shopping center light to the night time sky, but it also eliminated most of the wildlife habitat and made it so the only sounds I heard at night were cars. I closed my windows after that.

Only now am I learning that my innocent bed time habits could have cost me my life. According to this article, bullfrogs are unstoppable predators that can threaten an entire ecosystem; people in Utah are terrified that the immigration of bullfrogs will cause a plague of Biblical proportions. I had no idea. I guess I'm just happy that I was on the third floor, and none of them ever made it up the wall before sunrise.

Labels: ,

baptism

Let's make one thing clear: I know very little about security-related programming.

Now, don't misunderstand: I know the best practices related to creating secure web applications, and I've picked up many other general security principles in the last couple of years, but those do not require me to write security-related code - just secure code. Making sure that your web application is safe from SQL injection helps to make your code secure, but it doesn't require that you understand the fundamentals behind security features. You're just an end user who has managed to perform his job correctly.

I think of security-related code as those parts of a platform that are responsible for authentication, authorization, encryption, and the complex protocols that the industry has created to simplify them. That's the stuff that I am not familiar with and, to be quite frank, has never really interested me. I'm not sure if the lack of interest was driven by perceived difficulty or the overwhelming focus on encryption that I encountered while in academia[1], but either way, I've always avoided security-related projects.

Until now.

The code base for Zero Core isn't that big, so while its event-driven architecture makes it harder for a new person to read through the code and understand the flow, it really doesn't take that long to figure out how things work. For the past few weeks, I've been trying to help out with some bugs and enhancements to Zero Core, mainly to learn more about the code and fill in my mental gaps; one of the enhancements that I was particularly interested in was related to authorization, but because there are more work items than there are Core team programmers, I was told that the enhancement would have to wait until our third milestone, meaning December-ish. The only way the code would get into the next milestone (October-ish) would be if I agreed to write it. So I did.

Let's make a second thing clear: bug 972 was not very hard. It's not a big feature, and you don't have to be a computer scientist to understand how it works. Had someone from our security team been available, I'm sure they could have written the code and the unit tests before lunch[2]. Still, I'm happy to report that I was able to read through all of the zero.core.security.* code and understand it, and I didn't break the build once during development. I feel a bit more confident in my ability to tackle security-related projects now, even if I've only scratched the surface of understanding. Baby steps.

Special thanks go to Zero security lead Todd Kaplinger, who made sure that I started off on the right foot and who didn't even make a face when I told him that I don't know much about security.

[1] Encryption is discouraging because I am certain that it is difficult, and that I do not possess the mathematical mind required to conquer it.

[2] It took me a day in a half, when you add up all of the hours.

Labels: , ,

Tuesday, September 11, 2007

fresh

I've published six or seven articles on IBM's developerWorks site since joining Project Zero in April, but none of them contained Zero-related content; each article had been written during my pre-Zero days and revolved around Apache Muse and WS-*. The truth is, the articles had their publication dates set long before I joined the Zero team, but I think my management was starting to wonder if I was ever going to let go of the past and start working for them.

Today we dispel those worries: my latest article is very Zero-oriented, and it's accompanied by an interview I did for the site's podcast. Enjoy.

Labels: ,

Friday, September 7, 2007

underachievers

I have been sending and receiving email for a decade, and during that time I've deleted a lot of spam. I've never been particularly annoyed by spam - before I signed up for Gmail (which is unmatched when it comes to intercepting spam before I see it) I would just delete the messages and move on with my life. I didn't receive that much to begin with, so I was never able to sympathize with people who claimed to have thousands upon thousands of spam messages clouding their inboxes.

Still, I was not completely apathetic about spam; while I may not be as inconvenienced as some by their mere presence, I have always been disappointed in the quality of spam messages. In the early-to-mid nineties, I shrugged off the obvious subject lines, the poor English, and the ridiculous formatting because I figured that the people creating the messages were amateurs who were experimenting and didn't have any experience to tell them what would work and what wouldn't. They were true spammers: throwing millions of messages into the wind in the hopes of making profits in volume.

What's disappointing is that today, ten years later, most of the spam that I see in my Gmail spam folder is no different. I don't understand how such a lucrative business could still depend on such amateur content. I realize that the messages will always be a little zany because of the never-ending battle between spammers and spam blockers, but I don't think that should preclude the spammers from sending advertisements with proper English sentences and appropriate color schemes.

Every time I read a news article about the arrest or trial of a spam kingpin[1], they always mention how large the spam market is and the potential for huge profits; I find it hard to believe that the successful people in this business are not interested in creating higher-quality, more professional advertisements. I'm not saying they need to create corporate-level advertisements, but they should be willing to spend thirty minutes or so on a message to make sure it's legible and credible. Thirty minutes seems like a small price to pay for a significant increase in one's click-through rate.

The only really creative spam I've ever seen arrived around the spring of 2006. All of a sudden I started seeing emails from senders such as Felix Q. Marvelous and Burger F. Luscious, with subjects that, while not valid English, were at least entertaining[2]. Sadly, the message content was the same old boring stuff... but I shared a lot of laughs with my friends by exchanging great spam names. If the authors of this genre of spam had just applied the same creativity to the actual content, they might have convinced someone to take their emails seriously, but instead, they never evolved beyond an amusing self-parody. As of today, the spammers are back to their Plain Jane, WE ARE READY TO ACCEPT YOUR LOAN REQUEST ways.

Only one group of people disappoints me more than spammers, and that's scam artists. People who are trying to scam other people into giving up their bank account number or other important data have the opportunity to make more in one hit than spammers do in a year. And yet, it wasn't until late 2005 or early 2006 that they thought to replace their poorly-formatted messages with HTML and images copied from real bank web sites. Hello? The media is always going on and on about how clever these online scams are, but I see them as incredibly inept. Yes, they stole one old lady's life savings and her home is in foreclosure, but how many people did they lose because they misspelled Citibank? Twice? That's beyond lazy.

Sometimes I feel like I should have gone into the spam business. The amount of wasted potential I've seen over the last decade tells me that someone with my ambition could really clean up. With a few college classes on psychology, advertising, and information technology, the will to work for more than five minutes on an advertisement, and the email automation software that has existed for years, I bet I could double the average click-through rate and make a killing.

Sigh. I could have been a kingpin.

[1] Always kingpin. Not executive. Not owner. Kingpin. Like he's gunning people down and sneaking cocaine through customs instead of clicking a few buttons from a non-descript apartment in Poughkeepsie.

[2] A little too entertaining to reproduce here.

Labels: ,

Thursday, September 6, 2007

maintenance

I want to update by blog template to include a new link. This sounds simple, but if my past experience with Blogger is any indication, this change will not only modify the old post files, it will also re-publish the posts as if they are new. If you're subscribed to my Atom feed and you end up with a mountain of new entries in your feed reader tonight, just delete them all. Sorry for any inconvenience.

Labels:

augur

There is a very active thread on muse-dev right now about how to fix or workaround the lack of thread safety in Apache Xerces, which is the XML parser used by Muse. In XmlUtils.

Yes, that XmlUtils.

Ruh-roh, Shaggy.

All of the concerns raised over this issue are valid, and the people who are working to understand and solve the problem are all users who have deployed Muse in real world projects. I trust them to get it right, it's just a bit nerve-racking to watch people consider an API change that will touch the code in over six dozen places. Muse 2.1 has already shipped as part of a WebSphere product, and I can only imagine the number of conference calls that will ensue if their Muse-based applications break when they upgrade to 2.3.

That said, I'm really stoked to see such disparate parties working together to solve the problem - this is why we wanted to have a community in the first place! I wish I could invest the same amount of time towards resolving this issue, but I can't do two jobs at once.

Definitely nerve-racking.

Labels: ,

overlooked

The Apache Muse code base includes a collection of DOM-based convenience methods that help us parse and construct XML fragments without a lot of DOM API boilerplate. These methods are included in an incredibly large class named XmlUtils and represent the collective knowledge, mistakes, and advice of a half dozen developers who have worked on WS-* technology for over three years. Changing any of the methods in XmlUtils could leave the Muse build totally broken; despite the fact that it's been extracted from the core engine into a small library, XmlUtils is very much a core piece of code because of how heavily dependent on it the rest of the project is.

Any piece of code that is so central to a project is bound to have one or two (or ten) ugly hacks to handle edge cases, bugs in dependencies, and backwards compatibilty. XmlUtils is fairly hack-free, but it does have some code that I consider... unsavory. In my opinion, the most cringe-worthy code snippets are the ones that need to accept an XML element and iterate over its child elements. The only way to get all of the direct children of an element is to call Node.getChildNodes() and save those Node objects that are actually Elements; such code involves one or more if blocks that check the concrete type of the Node objects and ignore the undesired ones:
if (nextNode.getNodeType() != Node.ELEMENT_NODE)
continue;
Today these checks are common, but when I first wrote the code I allowed myself to make a number of assumptions because it was only used for traversing schema-validated SOAP messages. Then, one day, we added a configuration file[1], and all of a sudden the input was much less predictable. One of the first bugs I had to fix was the one caused by comments in the configuration file; XML comments become their own DOM nodes - different from Element or Text - and my code failed when comments were added in places where I expected a child element. My final fix eliminated comments from the DOM tree all together, but I kept the conditionals mentioned above on the off chance that we encountered XML pre-processor nodes or CDATA nodes. I would not be fooled again!
DocumentBuilderFactory factory = 
DocumentBuilderFactory.newInstance();

//
// we don't need comment nodes - they'll only
// slow us down
//
factory.setIgnoringComments(true);
This bug, and others like it, were part of my education into the more pedantic corners of XML Land. Over the course of three years I learned many things about XML, and while many of them were logged in my brain and never used again, all of them helped to drive home the message that XML-related issues were never as simple as they first seemed. When reading or writing XML documents or schemas, great care must be taken to ensure that edge cases and ambiguity are not hiding in the bushes. And as much as I malign the DOM API, it does a pretty good job of alerting you to the fact that XML processing in a real world system is never as easy as more user-friendly APIs would have you believe.

Now, despite four excruciating paragraphs on the internals of Muse, this post is actually about frustration I've had with some of my Zero-related work. I had to create some custom Dojo widgets this week, and after a few hours of searching the Internet for proper instructions[2], I started to make some progress: I had a widget "class", a widget template, and an HTML page that was loading the widget class and calling its initialization routines. The only problem was that nothing was showing up in the page - I had picked off all of the initialization errors, and yet there was no Dojo-inspired HTML to be seen.

Just as I was about to break down and open a DOM inspector to try and read through the eighty-seven levels of HTML to find the answer, it dawned on me: comments! My widget template is encapsulated in a single <div/> tag, but the HTML file that contains that <div/> has two comment tags: one for the IBM copyright notice and one with my comments explaining the content of the file. I had a hunch that Dojo was assuming the template file had only one node (an element) and wasn't checking for other, irrelevant nodes.

I was right.

I took the copyright notice and comments out of my template file and everything worked beautifully. It's good to know that my WS-* skill set isn't completely wasted here in RESTtopia.

[1] The beginning of the end for any project.

[2] The Dojo team isn't big on documentation, so I had to piece things together using half-baked suggestions from mailing lists and forums, some of which were no longer operating. I love reading documentation through Google cache!

Labels: , ,