Redundant is never Redundant enough.


Common Housecat
Blogabond went down for about 20 minutes on Friday. Our Five Nines of uptime were dashed to the ground by the uncommon treachery of the common housecat. We really need to get into a Colocation facility.

It's amazing how industrious our servers are at removing themselves from the internet. We have redundant backups for everything, uninterruptible power to everything, tons of bandwidth and beefy boxes. Still, we keep getting nailed by silly things. Our RAID drives find a way to die at the precise second that we finish wiping the backup. Our old router knew to take itself offline as soon as it was sure the entire team was out of town. Everything from faulty house wiring to funky drive controllers have taken us offline at some point.

But Friday took the cake. We suddenly found ourselves unable to reach the outside world. Somehow the router had gone down. But how??? It's on an Uninterruptible Power Supply! And we hadn't had a power outage in months! Ah, but on top of that UPS is a big red power button.


Cat Spikes (artist's rendition)
And on that button sits the cat. Sure, it's not as warm as it was about 20 minutes ago, but it's still warmer than the rest of the house.

Somebody needs to design a UPS that is not flat and comfortable, does not warm up nicely on a cold day, and does not have a hair-trigger OFF switch right on top of it. Either that or they need to ship it with cat spikes.




Sprinting

I didn't get anything done last week. Nothing at all. Most of my days were spent reading random stuff on the internet, making minor tweaks to Blogabond, and obsessing over traffic stats for Twiddla (why did 5000 people suddenly show up from StumbleUpon in one day???)

This week, on the other hand, I've been on fire. In the last 4 days, here's what I've accomplished:

  • Built a Reddit clone from the ground up for Rootdown's soon-to-be-live Clinical Pearls section.
  • Built a Google-Maps powered acupuncture chart, cut up 3000 tiles for it, incorporated effective Lat/Lon coordinates into Rootdown's database, and built a little Ajax data entry tool to drag & drop acupuncture points and meridians onto the chart.
  • Reworked the Photo uploading and Photo management pieces of Blogabond.
  • Tore out and streamlined the installation process for Regressor.NET
  • Wrote this lame article
Trust me, that's a lot of stuff.

I've noticed this same pattern happening over and over again. I think of it as Sprinting, and I think I'm getting better at harnessing it. There are a few factors that play into it, but I think the key is knowing that I have an entire day to Sprint on whatever it is that I want to do. Knowing Absolutely that the door to my office won't open, the phone won't ring, and no little IM popups will bother me for the Next Twelve Hours. Knowing that I'm free to get as deep into what I'm doing as I need to get whatever I'm doing Done and Done for good. Those are the days that I get the most accomplished.


Sprinting for a different reason:
Team Expat, Running with the Bulls in 1998
Another thing that seems to help, at least for me, is to have more than one ball in the air at a time. When I've only got one project, I seem more content to move slowly, check my email, read the occasional blog, and essentially stuff my productivity. But when I've got 3 things the Need to Get Done, and there just aren't enough hours in the day to do it all, I find that I work a lot faster.

Better still is to have something ELSE that I should really be doing. You should SEE the days I spend blowing off paid work to Sprint on a side project.

But it more than just blowing off one project for another. The real advantage of having more than one project going at a time is that if I get blocked for any reason, I can switch over to another project and continue Sprinting at the same pace. If I'm motivated to move fast, it doesn't really matter all that much what I'm moving on, provided I'm moving. If I can ignore the little bottlenecks and keep Sprinting until the inspiration fades, I can get a lot more done overall. If I only had a single thing to work on, any minor distraction, such as missing graphics from a screen designer, could derail me and send me off to check Reddit (and thus get stuck there for six hours.)

I don't think that any of this is new. It's common knowledge that developers tend to work in bursts. I guess the difference for me is that I'm starting to work on ways to facilitate those bursts. To keep them going once they get started. To finally look up and find it's dark out, and I haven't eaten for 16 hours and wow, did I really get all that done in a single day??? That's where I want to be. That's Sprinting.




Free Online Flash Card Software

I've been taking Spanish lessons these last couple weeks. I'm getting to the point where I can usually communicate my thoughts, but my vocabulary is seriously lacking. No sweat, I thought, I'll just hop online and find a little Flash Card site. There's got to be half a dozen websites where you can make flash cards and test yourself with them, right?

Uh... Hang on. They all suck! And they're trying to sell me something. This is lame.

Fortunately for me, I write software for a living. Cut to six hours later, and we now have flash-card.org, a site where you can actually make some flash cards and test yourself with them. It will even pay attention to your answers, and stop showing you cards that you always get right after a while.

Flash Card Software from www.flash-card.org

I'm going to keep taking more classes, so I bet the site will get some more attention soon, as I become frustrated by things it can't do. And, since I can never leave things alone, it will probably get a few more useless bells and whistles tacked on. Check it out if you're a student or otherwise need to memorize stuff. Let me know what you think!

www.flash-card.org - Online Flash Cards




Getting Your Priorities Straight. Scalability and Performance are the Least of your Worries.

Back in my Contractor days, I would occasionally take a job bringing a bunch of C++ guys up to speed in C# and ASP.NET. Invariably, I would have to break them of old habits that they had picked up back in the days when memory and hard drive space were expensive, and applications had to run in real time. Most of these little battles were quickly won, so flat files were replaced by relational databases, bit masks gave way to association tables, and data access code was pulled out into its own layer.

But one thing never went over well. Performance. Speed is largely irrelevant for a web application. Sure, it's important that your thing run fast, but there are a half dozen other things that are more important for a big web application. This is difficult to hear if your major skill is writing inline assembly for critical routines, but it's still the truth. Readability, Debugability, Maintainability and Development Pace are much more important than raw speed.

To deal with this rift, I would ask the developers to list out the most important qualities of a piece of software, and to rank those qualities in order. I've hinted at my answer above, but I'll take a few minutes to list them out below. Everything you see in the list is important, but the things toward the top are relatively more important than the ones towards the bottom. For what it's worth, we're talking about Web Applications here, so clearly this list does not apply to Game Development or even Windows Apps. Here goes:

Readability

In my mind, this is the single most important quality of a piece of software. Assuming your thing is going to be around for a while, you're always going to need to return to a given piece of code from time to time and make modifications. The faster you can read and understand what's going on, the sooner you will be able to start making modifications and adding new functionality. Better still, if you can quickly figure out what the code is doing and why, you'll be less likely to break anything in the process.

Debugability

Your code is going to break. Often. That's how it goes, so you'd better structure things so that it's easy to step through and figure out what's going on. That means declaring variables instead of stringing together 17 object methods on a single line. That means using real IF/THEN/ELSE blocks with squiggly brackets instead of inlined immediate if's. And it means thinking twice before committing to some automagically generated database framework that sniffs out all your column names, writes its own SQL, and keeps your data in ArrayLists of ArrayLists.

Keep your design simple enough that any exception will drop you into the debugger looking at a single line of code that does a single thing. Even if it turns out it's doing that single thing wrong, at least you'll be able to find and fix it.

Maintainability

Over time, new features are going to get added and old features are going to get dropped. Some of those new features will be stupid ones, with dorky business logic that rubs the fur the wrong way in your elegantly designed class structure. You want to be able to make those changes quickly, without breaking anything else. This means you need unit testing. You'll also want to refactor large sections of your backend to work in ways you had never anticipated, and you'll need to propagate those changes all the way out to the client code. For that, you'll need even more unit tests (and some good tools), but also you'll need an architecture that doesn't fall apart when you rip chunks out of it.

Development Pace

Modern applications are big and complicated. It doesn't matter how nicely written your thing is or how many simultaneous users it can support if you never manage to get it out the door. If you want to get your application shipped, you're going to need to put out a ton of code in a hurry. That means you're going to need the best tools available, and the most productive environment that you can find.

Side Note: PHP might seem fast if you've never seen the alternatives, but let's see how many Ex-Ruby-on-Rails and Ex-ASP.NET guys you can find doing PHP development by choice.
Keeping the above points in mind, you're going to want a development framework of some description. Here at Expat, we've rolled our own specifically to keep us fast without sacrificing Readability, Debugability, or Maintainability. I'd recommend doing the same, but there are any number of 3rd party frameworks out there that might fit the bill. Just make sure you keep those three qualities in mind when you are evaluating any new framework.

Scalability

At some point, your thing is going to get popular. Actually, chances are it won't, but you shouldn't architect your thing to preclude the possibility that people might start using it in the Millions. So how do you pull that off without undoing all those Important Things further up this list? Simple. Just be aware that one day you might need the ability to add more database and web servers to the mix. Add a few little abstractions such as a Database Connection Factory, and a Session wrapper that you can replace someday with something BEEFY. For now, they don't have to do anything fancier than wrapping the existing stuff in whatever framework you're using. But if you're diligent in using these wherever you would normally use the framework components, you might end up saving yourself a lot of headache down the road.

For the most part though, don't worry too much about scalability. Having a million people that want to use your thing on a single day is a good thing. If you've done a little homework, you'll work things out when the time comes.

Performance

Computers are fast. Seriously, computers are faster than you think. If you try to imagine which piece of your application is slow, you're probably wrong. I once worked with a developer who spent the better part of 6 months hand optimizing an algorithm to do fast fuzzy string comparisons. It turned out that the server doing the text processing was only spending about 10% of its time actually processing text (even with a simplified, non-optimized algorithm), and 90% of its time battling database locks to get the results put away. He could have figured this out in one day with a profiler, and then spent a few hours tweaking database indices and optimizing queries. Instead, he spent half a year solving the wrong problem.

So yeah, keep a profiler handy, and if you see something that is obviously taking a lot of extra time, go ahead and fix it. But don't spend too much time sweating performance issues. At least, wait until they present themselves as issues before you start sweating them!

Life imitates Rant...

As I write this, Blogabond (one of my diversions from real work) is starting to show its first signs of scaling pain. Every once in a while, a misbehaved crawler will swing by and hit it 500 times in a second, causing SQL Server to time out on a specific long-running query. This is a good thing in my mind, as it gives me a chance to tackle a potential bottleneck before it starts affecting real users.

Still, Blogabond has been up and running for almost two years now, and it is only now that I'm having to think about performance at all. Those other qualities though: Readability, Debugability, Maintainability, Development Pace. I'm seeing benefits from them every day.




How to rent an Apartment in Spain (if you're a clueless American and don't speak Spanish!)

So the Expat Software offices have officially moved to Spain. It's sunny here every day. The buildings are made of stone. You can walk places. Name me one city in America where they have all that and maybe I'll move back. Oh, and you'll also need to find me a huge 3 bedroom apartment overlooking the town square of that city for less than a crappy studio would cost in the bad part of Seattle.

Getting this place was hard. At least, it was hard for me and my girlfriend because neither of us speaks Spanish. I mean sure, we can order beers and ask about hotel rooms and that sort of thing. But we were in no way prepared to deal with the hassle of buying real estate in a foreign land. Hopefully, if I spell out some of the things we didn't know, it might help somebody else!

Stupid simple things:

Spanish people like their families, so Spanish houses are HUGE. In the countryside, you'll have trouble finding anything with less than 6 bedrooms. Seriously. Renting a house is going to be hard. In cities and towns, homes are often the entire floor of a building. You can find smaller apartments, but they are still called a "Piso" (floor). So if you're looking to rent one, you're looking for a Piso en Alquilar.

It's nearly impossible to find rental property in Spain on the Internet. There are tens of thousands of websites devoted to finding holiday flats for Brits traveling to Costa Blanca, so any search for apartment rentals in Spain is futile. Here are a few sites we found locally that actually rent property to Spaniards:

http://www.inmof3.com/
http://www.inmobiliaria.com/
http://www.enalquiler.com/

You can wander around your target town, looking for "en Alquilar" signs in windows and try making phone calls in a foreign tongue (hard), or you can go to the various "Immobilaria" (real estate) offices scattered around and ask them. It will still be a struggle, as nobody ever speaks English, but at least you can use hand gestures and point to things in dictionaries and so forth.

Spanish leases are One Year Minimum, so you're basically hosed if you want to find a place for 6 months. We spent an entire day walking around Pamplona trying to get around this fact, with no luck at all. If you're gonna go, go big. Nobody will rent to you for less than a year.

Painful details

You'll need a Spanish bank account. All the utilities and rent payments will need to be set up as direct debits from a Spanish bank. Overseas banks won't cut it. Even if you have a Barclays account at home, and there's a Barclays branch next door to the real estate agent, you're still screwed. International banking is not yet up to speed that way. You'll need to open an account locally, which is hard because…

You'll need a Spanish address to open a bank account. This seems more of a showstopper than it actually is. If you have a sympathetic real estate agent on your side, you'll hopefully be able to sit everybody down in the bank and work things out. In this case, it definitely helps to have an account with an overseas branch of the same bank. At least then it's sort of in the bank's best interest to help you out.

You'll need permission to reside in Spain to open a bank account. This one is tough for Americans, because it's hard to get a resident visa without a residence. And you need to get that visa before you leave home. We got lucky here because my girlfriend is English, and she was able to handwave around the issue with a bunch of broken Spanish about the UK technically being part of the EU and reciprocity and a bunch of other confusing stuff that exasperated the banker until he just signed the papers. I think I would have been screwed here had I been on my own. Likely I would have had to go from Bank to Bank until I found one that forgot to ask about my Resident status.

You'll need permission to reside in Spain to stay there a whole year. Uhh… Ask me about this in a couple months. The Spanish Embassy website is down right now, so I haven't quite gotten around to looking into this. Yeah… It's easier to ask forgiveness than permission, right?

Getting set up once you're here

Assuming you're a small software development house staffed with Expat Americans, your first concern when you get here will be getting ADSL into your new apartment. For the task, this little page is Gold (use Google's language tools to translate it to English):

http://www.redaragon.com/informatica/adsl/

That will give you a bunch of info you'll need to know about various DSL suppliers in Spain. If your place already has a land line, you should be able to limp through the online signup process for one of those providers. If, like me, you don't want any more hassle at this point, you can do it all in English through the phone company (though for a bit more money):

http://www.telefonicainenglish.com/

You'll need a mobile phone too. That's easy though. Walk in to any phone shop on the street and try to look helpless. These people have one task in life: to supply mobile phones to those who don't yet have them. Things will work themselves out. (We're on HappyMovil, which seems to be really cheap compared to the others, with $.05 calls to the United States!)

There are a bunch of other things to set up too, but if you're lucky the real estate people will get them switched over for you. Here is some good info on utilities and stuff :

http://costablanca.angloinfo.com/countries/spain/services.asp

Anyway, I can't imagine that this has made for enjoyable reading, but hopefully it will be helpful to anybody else trying to get set up in Spain. If you're planning to come out and have more questions, don't hesitate to drop me an email. It is all good here!




Twiddla - 1000 Signups on Day One!

Twiddla has been getting enough attention this last week that I moved it out to its own blog. Check out this recap of day one at Twiddla.com.

Putting stuff up on Reddit seems to be a good plan. Twiddla got another 1000 signups this morning. Most of it was traffic flowing through that article. Damn. I wish I'd spent some time getting it ready to show off!




Zero to Dogfood in one day

If you've been around software for any length of time, you've probably heard the term "Eating your own Dogfood." Other people have given better definitions of this than I can, but basically it means using your own application in house.

So if your company is developing a little web-based word processor that it hopes will get bought out by Google, you would be well served to force your management and marketing teams to use that little word processor in lieu of Microsoft Word. The idea being that you'll quickly discover about 100 new top-priority bugs in your thing that are stopping the CEO from being able to write a simple letter to his lawyer.

Now once you start thinking about your new thing in terms of Dogfood, you are immediately given a new goal for development: "We've got to get this thing to Dogfood." Meaning, our stupid new mail client has been in development for 3 years now, so why are we still using Outlook internally?!??

The Idea

Working with a distributed team is hard. I hate to say that, since it's sort of our thing here at Expat Software, but it is true to an extent. We have a design team up in Portland doing mockups for the new Rootdown look and feel. Down in LA, we would look at the designs that came in, mark them up and send them back to Portland, sometimes calling the designers on the phone, sometimes getting in touch via chat. It was taking forever. Just explaining the concept of "This button isn't necessary, and could you move the logo down to here" would take a couple days to get across.

Over dinner one night, we were griping about this process, and somebody suggested WebEx as a solution. "Yeah, but WebEx sucks." "And it's expensive." "And it sucks." And yeah, all the real-time collaboration software out there really does suck. It's all got too many hoops to jump through to get up and working, and it's all too bloated with stuff you don't really need. All we want to do is draw lines on a web page. Why should that be hard?

And that got us thinking. Why should it be hard? What would you need to do something like that in a Browser? Not much, really. All the technology is there. Hell, we've done most of what you'd need before. Like, back in 1998! It's got to be easy to reproduce that today.

Thus, the seed was planted.

The Provocation

A few weeks back I wrote an article that touched on some of the effort we've put into our backend framework here at Expat. It got a lot of feedback, some of which asked how we could possibly be productive with such an expansive backend to maintain. This really took me by surprise, because our experience has shown that we're a lot faster now than we used to be before we had that infrastructure in place. In my mind, that framework is the reason that I was able to put up a site like Blogabond in a few months of my free time, while it has taken other companies in the same space over a year to put up a similar site with a dozen developers and a million dollars in venture capital.

So hey, if we're so fast and all that, and this little collaborative marker-upper is so easy, why can't we just build it? Like fast, even?

Yeah. How about we set aside a day to do a little proof of concept and see how far we get.

The Day

10am
Technical proof of concept
First off, there are a few fundamental questions that need answering. What do we absolutely need? Can we layer a DIV over an IFrame? In every browser? Can we put a transparent-backround Canvas in that DIV and draw on it? Even using the IECanvas hack? Can we hook mouse events to it? Cool. We're in business.

12pm
Silly Drawing App
Next up, we needed a quick and dirty little drawing application for marking up photos and web pages. One day we'll want to put some more effort into this piece, but for now all we needed to do was draw little scribbly lines on the canvas.

2pm
The Proxy
We needed a simple proxy of some sort to show web pages on that IFrame, to avoid annoying Cross-Site-Scripting issues. It would need to mess with the HTML somehow to ensure that any clicks on those pages got redirected back to the proxy.

For the time being, we just grabbed an open source ASP.NET proxy tool and plugged it in. (This got swapped out about 2 days later for a home built version that worked a lot better for what we were doing.)

3pm
First Cut at the Backend
This was still a proof of concept, so we just mocked up a few basic objects and stored them in static memory on the server. Throw in a few little web services that the client can call to talk to the backend, and we're off to the races. (This piece was blown away and rebuilt the next morning to use a real data layer, but it kept us on task and out of the mire until we had the rest of the thing working.)

5pm
Testing
First multi-user twiddle session. Basically, 3 guys in one room drawing words and pictures over Google's home page. I'm really glad we don't have screen captures of most of the things we were drawing.

6pm
Chat
Somebody asked for Chat, so we threw in a little ghetto chat window. Nothing fancy, but at least you could see what people were saying (but not who was saying it!)

6:30pm
Refactoring
Much polishing and refinement of the original concept. And we added a few more features like being able to choose what color you were drawing with.

7pm
Outside users
At this point, things were looking basically usable, so we invited a few friends from the outside to try it out. Lots of childish graffiti was drawn, and a few more major issues were uncovered.

8pm
Dogfood
Finally, with the last showstopper issues out of the way, it was time to get the design team in Portland on to the site. Somebody pulled up Rootdown.us in the main window and we all started drawing lines on it and suggesting things to nudge around.

Holy wow. We were using this thing to do real work!

The Analysis

So how did we pull it off? Simple. We cheated.

The nice thing about Dogfood is that it doesn't have to be a finished product. It just needs to be useful for the task you're trying to accomplish. Sure, it needs to be stable enough to get stuff done, and it can't go losing critical data. But mostly, it just has to limp along well enough that you can start using it to do real work.

Since we weren't trying to build the whole product all at once, we were able to cut a few corners to get that Dogfood version up as quickly as possible. You'll notice that we had to go back the next day and tape on a new back end, and that we had to throw out the crappy third party proxy we were using. Better still, in the version we used that night, you couldn't even log in or create new WhiteBoard sessions. We had a single session, and a hard-limit of 3 users. There was still loads of work to be done before we could let the general public see the thing.

Another thing we had going for us was a really clear vision of what we were trying to accomplish. That vision was small enough to fit inside a single brain, and compact to the point that we could throw a single programmer at it for a day to get it implemented. You get a huge speed advantage with a team size of one. I doubt we would have finished in a day had we had three guys working on it.

One Week Later

So here we are, a week later, with a big pile of bugs and feature requests in the hopper. All found through simply trying to use the application to get work done. We're on the thing every day reviewing designs with the guys in Portland, and every day I'll spend another couple hours tweaking the thing to be less annoying and more useful.

With all the positive feedback we've gotten from friends and family, we're starting to think about opening Twiddla up as a public Alpha. Maybe even turning it into a real product at some point.

Lucky for us, we have this little blog with its little readership of early-adopter types. I'd encourage anybody reading this to go to www.twiddla.com and put our little whiteboard app through the paces. Naturally, we'll want to hear honest feedback about what you like and dislike about the thing. And hey, it's only been alive for a week now, so you're not going to hurt our feelings by telling us that it sucks.

We know it sucks, and we have a good idea as to why. That's the power of eating your own dogfood. With luck, maybe you'll have ideas to make it suck less!




The West Coast Mobile Office


Writing software is a lot like writing anything else. I think that's why so many computer programmers are unhappy working at companies that expect to see them typing away furiously for 8 hours a day, 40 hours a week. With any creative endeavor, inspiration tends to happen in bursts. In programming, these bursts tend to take the form of the 18 hour caffeine-fuelled marathon sessions that come to mind when you think of Internet startups. One of the (very few) things that those companies got right in the late 90s was to recognize this work pattern and find ways to accommodate it. (Unfortunately, most companies accommodated it by setting up pinball machines right in the middle of the dev space, thus wiping away any potential productivity gains in a sea of noise).


Anyway, back to the point at hand, the key to keeping up productivity as a developer is to find ways to foster these inspired bursts of creativity. With this in mind, we packed up the truck and left rainy, dismal Portland behind for a while. 20 hours south, we set up shop in Bishop, one of the most inspiring spots that the US has to offer. High alpine wilderness, tons of amazing rock climbing and Bouldering, pleasant secluded camping, and, amazingly, good EVDO coverage. Everything a climber/geek could want!


Free from the distractions of the city, we'd pull out the laptops in the morning, sipping espresso and knocking out new functionality until well after lunch. Thus creatively spent, we'd pull out the rock boots and head up the hill in search of Boulder problems on the amazing granite that Bishop is famous for.

What a week. What a place. we'll be back.




exampleCode != productionCode

Take a look at this little piece of code. It looks pretty innocuous, like it was taken straight from "Teach Yourself ASP.NET in 21 Days". Pull a list of Trips out of the database for a given user, and bind it to a select list. Nothing fancy. Teaches you a little bit about ADO.NET and databinding all in one place.

Figure 1., Book Sample

public class ExampleCode : System.Web.UI.Page
{
    protected HtmlSelect selTripID;

    private void Page_Load(object sender, System.EventArgs e)
    {
        if (!IsPostBack)
        {
            DataSet ds = new DataSet();
            SqlConnection connection = new SqlConnection(
                "server=OurProductionServer;database=Payroll;
                UID=jimmy;PWD=j1mmy;");
            SqlDataAdapter adapter = new SqlDataAdapter(
                "select * from Trip where UserID=" 
                + Request["UserID"], connection);
            adapter.Fill(ds);

            selTripID.DataSource = ds;
            selTripID.DataTextField = "TripName";
            selTripID.DataValueField = "TripID";
            selTripID.DataBind();
        }
    }
}
Imagine my surprise, however, when I walked in to a small software shop recently and found a whole project written with code like the above. What were these guys thinking? Are they seriously relying on this fragile, unmaintainable mess in a real software product?

And then it dawned on me. Maybe nobody had ever told them that the little examples in the book are just that: Little Examples. For teaching purposes. Never intended for use in the real world. Come to think of it, it doesn't even tell you that in the book. It aught to be in block capitals across the cover of the book:

WARNING: DO NOT PASTE THE SAMPLES FROM THIS BOOK DIRECTLY INTO PRODUCTION SOFTWARE!!!

Somehow, it seems that this message never got through to a substantial portion of the software industry. Every time I see a "Senior Developer" writing ad-hoc SQL or referencing a hashtable with a string I just want to cry.

So what do we do about it? I guess we try to get the message out. Here is some code I copied out of the Blogabond source that is functionally equivalent to the above:

Figure 2., Production Sample

public class ProductionCode : System.Web.UI.Page
{
    protected HtmlSelect selTripID;
    private int _userID;

    private void Page_Load(object sender, System.EventArgs e)
    {
        if (!IsPostBack)
        {
            _userID = StringConvert.ToInt32(
                Request[User.Columns.UserID], 0);
            if (_userID != 0)
            {
                PopulateTripList();
            }
            else
            {
                // bail gracefully...
            }
        }
    }

    private void PopulateTripList()
    {
        selTripID.DataSource = Trip.GetByUserID(_userID);
        selTripID.DataTextField = Trip.Columns.TripName;
        selTripID.DataValueField = Trip.Columns.TripID;
        selTripID.DataBind();
    }
}
Short and to the point. And obviously only the tip of the iceberg. This bit of code goes deep, but we can learn a few things just by looking at it:
  1. We're using a Data Layer of some sort. Somewhere in the back end lives a class that is wrapping a stored procedure for me. There's a ConnectionFactory back there someplace that knows to hand me a connection to the Production database because of a server setting.

    The code that's handing me the DataSet I'm binding to can be reused by any page in the project, so I know that little select statement is only living in a single place. In fact, everything that touches that table is sitting in a single class back there. So if something changes in the schema I won't have to go hunting through the client code to fix it.

    Best of all, because we've separated the database code out into its own place, we can drop all the boilerplate CRUD into CodeSmith templates and let it auto-generate itself from the database schema. In the case of Blogabond, I can flip a switch and watch as 50k lines of boilerplate C# and SQL in our backend gets blown away and recreated in about 30 seconds. And since it's also generating all the boilerplate Unit Tests for all that code, we can be sure that the datalayer and the database line up correctly. So if junior dev Jimmy comes by and unchecks a not-null constraint in Enterprise manager, we'll see the continuous build fail on an integrity check a few minutes later.

  2. We're using Enums instead of inline strings to reference our column names. This may not sound like a big deal, but it buys us a couple things. First, we've abstracted out the concept of the Typo. There is simply no way we can misspell "TripID", because the compiler will catch it for us. It will sit there underlined in red if we even try. We don't even have to remember what columns we have available, since Intellisense will tell us when we hit ctrl+space.

    Second, and bigger, is that we buy the freedom to monkey with our tables and never worry that we're causing runtime errors someplace. I can rename the column "TripName" to "BlogName" if I want, re-generate the database wrappers, and watch as the project fails to compile until I fix the references. That is some powerful stuff. And what happens if I forget to re-generate the wrappers for that table? The continuous build will fail in about 5 minutes, since the unit tests that check to make sure the wrappers match the schema will fail.

Where do we go from here?

Copy and paste code reuse is bad. Everybody knows that. Ad-hoc SQL is bad. Everybody knows that. Inline strings are bad. Everybody knows that.

At least that's what I thought. But you know what? They don’t. And they should. And it's our job to tell them.




New stuff at Blogabond

Just pushed a few new features to Blogabond today. Most visible is the ability to embed your maps into external web sites, blogs, and wherever else you might want to stick a map of your travels:

Groovy, eh? You can try it out on your own blog by running through the Trip Builder, and copying out the code it gives you when you're done. Along the way you'll need to sign up for an account and name your trip, but it's still pretty quick to get a map up and running on your own site.

For the curious, here is the code you'd need to drop onto your page to display the map above:

<script src="http://www.blogabond.com/BlogMap.aspx?tripID=34&width=500&height=300"></script>

Enjoy!



Viewing 41 - 50 of 55 Entries
first | previous | next | last

Jason Kester
@jasonkester

I run a little company called Expat Software. Right now, the most interesting things we're doing are related to Cloud Storage Analytics, Online Classrooms, and Customer Lifecycle Metrics for SaaS Businesses. I'll leave it to you to figure out how those things tie together.


Subscribe in a reader


Copyright © 2017 Expat Software