comments edit

Patrick Cauldwell points out that the challenge of coding a business app isn’t in writing the code, that’s easy. The challenge is in understanding business requirements, and not because developers and architects can’t understand plain English.

In my experience, I find that often, “business people” (for the lack of a better word) do not apply the same rigor to developing a business model for an application as developers do towards requirements gathering, specifications, and coding for the application.

I understand that agile methodologies are designed to help manage change, but even they can’t keep up when the business owner doesn’t even know what the requirements should be, but is spouting them out anyways. What do you do when the business owner has been involved in every step of the project, played with every prototype and interim release, but at the end says, well that’s not what I want.

For ~95% of business software, the actual code needed to implement them ends up being, if not trivial, then at least not technically challenging.  Business software projects go over budget/schedule etc. because the business rules aren’t known (to anyone) or because no one in the organization really knows what they want.  …snip…

So when people complain that projects are going way over budget/schedule/what have you, it’s almost always (in my experience) due to the fact that engineers spend 6 hours a day poring over vague and conflicting sets of documents, and 2 hours writing code.

[Via Patrick Cauldwell’s Blog]

As a developer friend of mine used to say,

This job would be great if we didn’t have clients.

Of course I prefer the paycheck.

comments edit

I’m happily married, but if you’re not, and you live in L.A., I recommend you take your dog for a walk at the Barrington Dog Park, on the east side of Barrington just south of Sunset. We were playing a game of soccer, but we couldn’t help noticing that all the talent was in the dog park area adjacent to us. Looked like a bonafide LA pickup joint.

comments edit

If you’re a lazy mofo like me, there’s one thing you’re not lazy about, getting out of having to do a lot of work. An important skill that should be on every lazy developer’s utility belt is the ability to understand requirements.

However, there’s a subtle technique to this. When I say, “understand requirements”, I don’t necessarily mean understanding what the client tells you the requirement is, but taking a moment to dig deeper and get to the real purpose of the requirement. Let me tell you a story based on a true story.

WeLikeCustomers.com has a two email systems for communicating to its clients. One system sends news letters and “Please come back” emails to clients who have opted in. The other system sends emails welcoming newly registered users as well as password reminders etc… The second system is designed to send only the most important emails so as not to get blacklisted.

Millard in Marketing decides that the second system should route emails through an email delivery service that guarantees delivery. He tells Damien the developer that only emails in a certain category should be sent through the new delivery service, and all others should be sent in the current manner.

Well Damien thinks about it and tells Millard it will take a day or so to add this routing within the second system. Currently the system only supports sending emails to one configured SMTP server. Now he has to add the ability to send some emails to another SMTP server based on certain criteria. He dives right into designing a general purpose email routing system. After a bit of time, he has the sudden thought,

“Now why the hell are they routing only a portion of emails to this new service anyways?”

So he asks Millard, who replies,

“To make it easier for you of course.”

After some discussion, Damien finds out that Millard would prefer to send all emails to the delivery service. So he changes one setting in his config file pointing to the service’s SMTP address, closes his office door, and takes a nap. Meanwhile, Millard is sending out emails complimenting Damien for going above and beyond the call of duty.

Be like Damien.

personal comments edit

UPDATE: I cannot help you move to Alaska. This post was written in 2004. If you want to move to Alaska, please don’t contact me. Try looking for information at the official Alaska homepage. Thanks!

Alaska’s Flag As a relocated Alaskan, I read Rory’s post about moving Canada to the right a bit so that Alaska could join the “lower 48” with amusement. I don’t think that idea would go over too well with Alaskans, as we…er…they take great pride in their independence, not only in spirit, but in location. Not only that, it could affect the fishing season, and you don’t mess with the fishing season in Alaska, the biggest state in the Union. That’s right Texas, the stars at night are even bigger and brighter in Alaska. Get over it, we rule you.

Alaska Map However, Alaska is not paradise on Earth (except in the summer when the sun stays out quite late drinking and carousing). Did you know they pay residents to live there? It’s a little thing called the “Permanent Fund Dividend”. The Permanent Fund is a huge investment of oil revenues in a variety of stocks and bonds. Around October of every year, the interest earned from the fund pays each resident anywhere between 1 to 2 grand a year, depending on how well the market does. Just in time for some good Christmas shopping.

Not only that, there’s no sales tax and no income tax in Alaska. Yeah. Starting to sound like a good place to live, no? Well, before you rush off to go panning for gold, keep in mind that winter lasts around 8 to 9 months of the year, so I hope you like winter sports.

comments edit

There ought to be a law that requires employers to give their charges the day off due to great weather. Back in Alaska, we’d have the day off when it dropped to -60 F with snow up to your nostrils. They call it a “snow day”. Well there ought to be a “good weather day”.

Not that I needed it, I’m on vacation fool! No, I ask for this for all you suckers trudging to work while I was kayaking away on Lake Union in Seattle. We paddled our way through a channel to Lake Washington and had fun limboing underneath the freeway. Yes, underneath. There’s a portion of the freeway directly over the lake, and portions of it are only three feet above the water. My wife and I nearly scraped our noses trying to glide underneath laying on our backs against the kayak.

Earlier today we cashed in my REI dividend buying my wife some nice sandals. Seattle has the nicest REI store I’ve ever seen, complete with a huge climbing wall. It made me nostalgic for the wilderness of Alaska. I had the sudden urge to climb mountains, wrestle bears and sleep in caves. Then again, L.A. has its own version of wilderness that’s pretty wild too.

comments edit

twilight samuraiWe saw a fantastic movie at the Landmark last night called Twilight Samurai. It stars Hiroyuki Sanada who played the bad ass in The Last Samurai who beats the crap out of Tom Cruise and was the Samurai leader’s second in command.

What sets this movie apart from most Japanese Samurai movies is how vulnerable the hero is. He’s trying to lead a simple life and struggles to make ends meet. He is sensitive to his daughters and senile mother (his wife died of consumption) encouraging the daughters to study the classics (quite atypical) along with their needlework. He isn’t a typical bushido super-hero with perfect valor, but a petty Samurai who wants nothing more than to watch his daughters blossom into young women. As you might expect, it isn’t always that easy to maintain a simple life for a Samurai with duties.

This isn’t the movie for you if you’re looking for one gratuitious battle after another. The fighting is scarce, but significant to the story, well done, and have a realistic look to them. There are no crouching tigers nor hidden dragons here.

comments edit

My friend Julie showed me and Akumi around the campus today. She works for the Finance department in Building 4. When I say “campus”, Microsoft really has a collegiate feel to it. We even saw a group sitting in a circle in a plot of grass having what appeared to be a discussion group. We had lunch at the cafeteria there and the food reminded me of my college dining hall, not terrible, but nothing to write blog about.

Seems like everyone we know in Seattle is trying to pimp it to us. Grace, whom we’re staying with, is constantly pointing out how wonderful it is while Julie is selling both Seattle and Microsoft. She certainly knows how to sell Microsoft to a person like me (not that I need any selling). After lunch, she immediately took us by the soccer field where two lunchtime games were going on a perfect turf field. Need I see more?

After walking around a bit, we headed over to the Microsoft Store and Museum. The store didn’t impress me too much, but the museum was neat, and not just because of the X-Box consoles. The old pictures of Bill and crew inspire a laugh and it was interesting to see the box for “Microsoft Adventure”, one of their first games.

After our impromptu tour was over, we sat in the lobby of building 4 when I noticed a group of people on the other side of the glass walk by. I noticed a guy in an orange XML Web Services shirt and told my wife that the huge book in my backpack that adds all the bulk to my luggage was written by him. I would’ve liked to have introduced myself to Chris, but we were already on the outside of the glass.

comments edit

I’m here in Seattle hooking an unsuspecting Dan Kalish on the drug I call RSS Bandit. He just finished the Washington Bar (after having passed the Connecticut bar only a couple of years ago. Sucks to be a lawyer and move.) and is enjoying a quiet repose. This is my first attempt to a non geek on RSS.

comments edit

We fly off tomorrow to Seattle and don’t let me catch you even thinking about trying to snake my stuff. I live in a very bad neighborhood, you wouldn’t want to be there after dark or in the nude. We have vicious blind dogs in the yard that have been raised on human meat and will bite anything that breathes or walks funny. And robots in the house with lasers and duct tape and … and Barry Manilow CDs!

And…um.. we have cameras all over the place, and a direct upload to America’s Funniest Home Videos so everyone can laugh at you when you’re attacked by blind dogs, including the girl in HR who never looks in your direction you pathetic slob.

Besides, my stereo is out-dated and sounds crappy. But I hear the neighbors just bought a huge flat panel HDTV with a Bang & Olufsen stereo. You should steal their shit instead.

comments edit

I have a bad habit of writing specs in the future tense. Since the system I’m spec’ing doesn’t yet exist, it’s so easy for me to fall in the habit of saying things like:

  • This page will look like this:
  • At this point the system will do this.
  • The system will display that control here.

instead of:

  • This page looks like this:
  • At this point the system does this.
  • The system displays that control here.

So what’s the big deal? Well there’s two big deals. Number one is a question of written aesthetics and the other is a more practical consideration. Ok, so they’re not all that BIG a deal. But let me continue.

Aesthetically speaking, using the present tense sounds more active and interesting. Remember all those lessons about active voice and passive voice in high school English? I think it’s made me paranoid.

Secondly, and more importantly, is that after you build the system and someone comes along and refers to you spec as a piece of documentation, it sounds kinda funny to say the system “will look like this” when it already “does look like this”. You can argue that the system doesn’t respond till the user interacts with it so that saying “When the user clicks here, the system will navigate there” isn’t so off the mark. See my first point in response to that point. I thank you for your time.

comments edit

I’m no professional musician, but I thought the acoustics at the Hollywood bowl was fantastic. They’ve been touting the improved sound with the new shell and improvements. The sound was sharp and clear.

The opening act played an Eastern influenced set with guitar, bongos, and even some Drum & Bass mixed in there. They were accompanied by Indian dancers on one side and break-dancers on the other. East meets west. I don’t believe for a second that the break dancers are from this world. I think they are former Gumby rejects in the way they contorted and flipped. Of course, I’ve seen just as impressive dancers on 3rd Street Promenade.

Sidestepper soothed us with “In Beats We Trust”, a very reggae-ish funky tune. Nortec Collective picked up the intensity a notch with some thumping music. The Crystal Method then brought it home with a nice selection of a few new tracks and several classics, ending with “Busy Child.”

comments edit

Google originally wanted to raise $2,718,281,828, but based on this article, I predict they’ll be closer to $3,141,592,653. In any case, that’s a big piece of pi. (sorry. really. don’t shoot me.)

LOS ANGELES (Reuters) - Google Inc., the world’s No. 1 Web search provider, said on Monday its highly anticipated initial public offer could be worth as much as $3.3 billion as it prices its stock in a range that could value the company at more than $36 billion.

[Via Reuters: Top News]

comments edit

Soccer ball My team, Nothend United, tied the Westsiders 2 to 2. Our goalie was phenomenal in staving off their aggresive attack, but sadly the opponents scored twice by capitalizing on deflections of our defense that took our goalie out of position. I scored one off of a penalty kick. For the record, I didn’t dive. I never do.

comments edit

I have to hand it to Microsoft, they really do listen to their customers. And I don’t mean in that head nodding “I hear you but I don’t know what you’re saying” kind of way so common with people who really want you to think they’re listening, but have no time for you. I posted my question about device support on Don Box’s Wiki and here’s his response:

There are several small XML parsers (expat being the most well-known) that should make it exceedingly straightforward to implement basic SOAP functionality on your device (you will have to write some code, as the tool support is zip when using this approach). The challenge going forward is getting XML DSIG and Encryption, both of which require a real investment if your platform doesn’t include support for them. How long it takes Sun to bring these technologies to J2ME is out of our control. If it’s any consolation, we don’t have them on .NET Compact Framework yet either. For the near-to-mid-term future, if you want reach, transport-level security is your best option for getting messages out of the device.

Now, I know this may be out of Don’s control, but I think its pertinent and I might as well ask. The way I see it, a huge source of consumers for SOA will be mobile devices running on other platforms connecting to these services. Although J2ME (and BREW etc…) is out of Microsoft’s control, now that Sun and Microsoft are good buddies, can we expect to see some more collaboration and perhaps even a bit of friendly pressure on Sun to provide toolkit support for WSE 2.0 now and Indigo near the time Indigo is released? At the very least Microsoft should be (and I imagine are) concurrently building Indigo support into the .NET Compact Framework. Out of curiosity, is that the case? Microsoft says they’ve run out of things to buy, but perhaps they should buy or start some spinoff companies to build toolkits for platforms that do not have decent support for Web Services. What better way to complete the chicken-egg problem than to make both?

code comments edit

SoapIn this post, Tim Ewald talks about using Doc/Literal/Bare for your web service. There are several benefits he ticks off, but one seems to be the aesthetic effect of cleaning up the format of the XML within your SOAP message. In SOAP, the XML sent back and forth is just the wire format. As a typical developer, why should you care what the wire format is? In general, you shouldn’t. If you have the tools to generate WSDL and generate a proxy off of a WSDL to call a web service, you’re all set.

Unfortunately for me, it’s not that easy. My job right now is to expose my company’s platform to clients running cell-phones, set-top boxes, etc… These platforms are running J2ME, BREW, C, etc… Potential future clients are interested in SOAP, but our first client is dead set against it because they say it’s too verbose for their tiny devices and there is scant tool support for them.

So I went and took some sand-paper to our SOAP services and shaved off every bit I could, smoothing out the edges, shortening the namespaces I have control over, making everything so “Doc/Literal/Bare” you’d blush just looking at it. Still, no go. They weren’t having it. They have their own proprietary XML format they want to send to us over HTTP with a roll-our-own authentication scheme. I was hoping to take advantage of all the plumbing VS.NET and the .NET Web Services provide.

I recently watched a video in which Don Box and Doug Purdy discuss Indigo and SOA. They hope that most developers will not have to become plumbers and understand how it all works under the hood. You just use Indigo and it automagically takes care of it for you. You just focus on your business rules.

The problem I see arising is that as Microsoft takes web services and SOA to the next level, not everybody is keeping up. How will I get these people on mobile devices to interoperate with my service if they are lacking the tools to even generate simple SOAP messages? These guys didn’t want to use XML until I showed them their format required very little change to make it XML compliant. As much as I don’t want to know what’s going on under the hood, I’m afraid I am forced to hike my pants down a bit and expose some butt crack to become a plumber.

In my next post, I’ll talk about my solution to this problem and a problem I ran into.

comments edit

Dare asks the question whether or not we should change the browser used by RSS Bandit. He was greeted by over 30 comments, mostly in favor of the switch. This is purely anecdotal, but I get the sense alot of people are upset by recent vulnerabilities in IE. I also get the sense that a lot of people feel that upstart browsers are toeing the line of innovation while IE has sat on its fat ass and done nothing lately.

Whether that’s true or not, as Dare points out, integrating another browser into RSS Bandit is a bit of work and could open a whole can of worms. I’d like to point out that there’s something you can do now with RSS Bandit as a stop-gap. It may not appease the die-hard Firefox or Gecko users, but hopefully it will help you feel more secure using RSS Bandit.

A little while ago I wrote up some documentation called Changing The Web Browser Security Settings which can be found on the RSS Bandit documentation site. There are two important features the document discusses. One is that you can have HTML links within RSS Bandit opened by an executable of your choice. This may not integrate with the nice Tabs within RSS Bandit, but at least you’re using the browser of your choice.

If you decide to stick with IE, I suggest configuring the Security, Restrictions options. You can deactivate ActiveX controls (the source of most vulnerabilities) and browse in relative safety. The documentation describes the risk of checking each option.

The Reading Pane (or “Item Detail Pane”) is not affected by these settings. It never allows any script or ActiveX controls. While we debate removing IE, you can read your feeds with more security. Happy RSS Reading.

comments edit

Soap In my last post I discussed a client who requires that we build a web service using a proprietary XML format (lets call it MyXML) so his mobile devices can interact with our platform.

Naturally, I didn’t want to limit ourselves to one client, but looked at the big picture and decided I should build a standard Web Service using SOAP, but provide some sort of facade that would translate his MyXML requests to SOAP and translate the SOAP responses back to MyXML.

My first attempt was to write a Soap Extension. I was planning to do something like this (some code ommitted):

using System;
using System.IO;
using System.Web;
using System.Web.Services.Protocols;

/// <summary>
/// Soap Extension that transforms incoming MyXml to 
/// SOAP and outgoing SOAP to MyXml.
/// 
public class MyXmlToSoapExtension : SoapExtension
{
    Stream _soapStream;
    Stream _tempStream;

    /// <summary>
    /// Transforms incoming MyXml to SOAP and outgoing SOAP to 
    /// MyXml
    /// 
    /// <param name="message">
    public override void ProcessMessage(SoapMessage message)
    {
        switch (message.Stage)
        {
            case SoapMessageStage.BeforeDeserialize:
            {
                // Code to transform incoming _soapStream
                // into the chained _tempStream via XSLT.
            }
            break;

            case SoapMessageStage.AfterSerialize:
            {
                // Code to transform chained 
                // _tempStream and write result to 
                // the outgoing _soapStream via XSLT
            }
            break;
        }
    }

    /// <summary>
    /// When overridden in a derived class, allows a 
    /// SOAP extension access to the memory buffer 
    /// containing the SOAP request or response.
    /// 
    /// <param name="stream">
    /// <returns>
    public override Stream ChainStream(Stream stream)
    {
        // by overriding ChainStream we can
        // cause the ASP.NET system to use
        // our stream for buffering SOAP messages
        // rather than the default stream.
        // we will store off the original stream
        // so we can pass the data back down to the 
        // ASP.NET system in original stream that 
        // it created.
        _soapStream = stream;
        _tempStream = new MemoryStream();
        return _tempStream;
    }
}

And man, it was working like a charm in my unit tests. I was converting straight up garbage into SOAP. The beauty of this scheme was that SOAP requests and MyXML requests were happily going to the exact same URL. Everybody was getting along. All I had to do was examine the request. If it was a SOAP request, I didn’t change anything. If it was a MyXML request, I ran my transformations. For a moment, I was daydreaming about the articles I would write about how brilliant a solution I had created (not realizing there were other problems as well such as maintaining the transformations between MyXML and SOAP) until I noticed that my unit test was cheating a bit. When making the HTTP request, the test did the following sneaky thing:

HttpWebRequest request 
    = (HttpWebRequest)HttpWebRequest.Create("http://localhost/Svc.asmx");
//...Code Omitted...
request.Headers.Add("SOAPAction", "http://mynamespace/MethodName"); 

You see, a SOAP request is more than just the contents of the SOAP envelope (especially when using doc/literal/bare), there’s also crucial information in the HTTP headers. So I removed that line in my test, and tried to add that line within my Soap Extension like so:

HttpRequest request = HttpContext.Current.Request;
request.Headers.Add("SOAPAction", "http://mynamespace/MethodName"); 

Not going to happen, my tests failed. By the time the HTTP headers reach my web server, they are READ ONLY. They won’t let me get my grubby hands in there and change them. I might be able to convince my client to add this header to his clients for kicks, but I don’t think he’d go for it. Why would he? He doesn’t want anything to do with SOAP.

Now, unless someone comes along and shows me how to modify incoming HTTP headers from an ASP.NET service, I am going to resort to plan B. I will write an HttpHandler that takes in the MyXML, does the authentication etc…, figures out which method to call, and then call the appropriate Web Service method. I’ve put the code that implements my web service in another assembly like so:

<%@ WebService Language="c#" Class="Svc,MyAssembly" %>

That way my HttpHandler doesn’t have to make a second HTTP request to the Web Service, but just use the underlying logic (assuming my methods don’t access such things as the SoapContext etc…). I was hoping to avoid this type of duplication of efforts, but oh well.

UPDATE: As my friend Ben points out, I can modify the HTTP headers with an ISAPI filter, but that’s a lot more work and I prefer to work within the ASP.NET model and not have to deal with ISAPI.

comments edit

First Kyle, then Micah. I’ve bugged him, cajoled him, annoyed him, till finally he caved and installed RSS Bandit. Took about five minutes before he became a full fledged addict. I have a feeling he’ll be up really late tonight. Next step is to get him set up with a .TEXT blog. I’m so eeeeevil.

comments edit

VacationI’m taking all of next week off of work. Wohoo! Well actually, I’m only on vacation from my day job. Monday and Tuesday I’ll be working on some contracts I’ve got going on the side. Then on Wednesday, the little lady and I are heading out to Seattle to visit her best friend. Hopefully I’ll have some time to work on RSS Bandit too.

Tonight I’ll be going out for a few drinks with my buddy Micah. He quit his job and went independent. He’s poised to take over the world soon, while I’m jockeying to position myself to ride his coattails. ;) He’s got a lot of great ideas on how to make IT a value proposition and not a cost.

Saturday night, I have a big soccer game. Sunday I have an acupuncture appointment and we’re going to the Hollywood Bowl concert. Whew! We’re pretty busy this weekend.