Monday, October 10, 2005
Driving in downtown Amsterdam is like that TV show on cable called Most Extreme Elimination Challenge where contestants are forced to navigate swaying bridges, booby-trapped streams, and other insane obstacle courses while having rubber balls shot at them out of cannons. The only difference is that instead of rubber balls, it is pedestrians, cyclists, mopeds, and cars that are being shot at you out of cannons. I learned quickly that the key is to just keep creeping forward -- feather the clutch -- until you hear someone honk or yell. If the honking/yelling is coming from behind you, then you let the clutch out all the way and gun it. The people here are spry and they know how to get out of your way. Sometimes, however, they challenge you, like one couple I came across who tried to assert their right-of-way by forcing their baby's carriage in front of my car. I pretended not to see them and I didn't hear any screaming, so I guess it worked out.
But seriously, there are people walking and riding bikes the wrong way in the middle of the street, two-way streets only wide enough to fit a single car, scooters driving in the bike line, and even motorcycles on the sidewalk, and all of this taking place while city trams are rushing back and forth all around you (you just have to listen for the “ding,” and get the hell out of the way). It's a miracle we got our car into and out of this labyrinth. Driving here is by far the most insane thing I have ever done in a car.
As you may or may not know, Marijuana and prostitution are legal in the Netherlands. Marijuana and hash are sold at places called “coffee shops” for anywhere between 10 and 20 dollars a gram. Patrons are required to smoke their purchase in the shop or within their own private quarters. Once in a while, however, one can catch a glimpse of a person huddled in an inconspicuous doorway lighting up. The city is also home to many other drugs, such as cocaine, ecstasy, and heroin, but these are all illegal, and many clubs and coffee shops have signs prohibiting these so-called “hard drugs”.
Prostitutes can be found in the “red light district.” This is a neighborhood spanning approximately 2 square miles where the streets are bathed in the red light emanating from the glass doorways of hookers. This section of town is not run down. It is not “on the wrong side of the track.” This is Amsterdam, and one can find a scantily clad woman beckoning in a doorway right next to a trendy bar or a souvenir shop. There is even a church that is completely encircled with red rooms. Many tourists traverse these streets just to catch a glimpse of the spectacle -- it truly is a sight to behold.
While we're on the subject of women, if any single guys are looking for a mate, buy a one-way ticket to Amsterdam. You can pretty much throw a dart in a crowd and hit a tall, well-proportioned, beautiful woman. I fell in love at least 10 times.
The hotel that we stayed at advertised itself as “gay friendly.” It is located in the gay section of town, but you can't really tell, apart from the pictures on the walls.
Click here for more random pictures from Amsterdam.
On our last day in the Netherlands, we traveled to a nearby city called Den Haag (“The Hague”). Here there is a special park called “Madurodam.” This park is basically a scale model of all of the Netherlands. It is like the Cliff Notes of Holland. Everything from bridges, to the airport, to downtown Amsterdam is represented here. It is largely designed to entertain children and their incredibly attractive mothers, but these three single guys had a very good time as well. I like the trains and boats and planes that all really move. Anyway, here's the pics of those...
Anyway, thanks for reading, and stay tuned in the future for more fascinating stories from around the world!
Saturday, October 08, 2005
Hello everyone. Sorry for the lateness of this post. We've been in Amsterdam for the last 3 days, so I'm forcing myself to take some time to tell you all about Oktoberfest back in Germany before I lose all my memory here.
We left for Munich (called “München” here in Germany) from Dan's house in Landstuhl Saturday morning (the 1st) -- well, afternoon, really. We had reserved a room via Priceline at a pretty good rate: about $100/night, plus taxes. We rented a car and did our best to plot a course.
The autobahns here are pretty cool, but not the awesome raceways I was picturing before I came. Still, it is refreshing to drive here (when there's not a lot of traffic). It is illegal to pass on the right, and it is illegal to drive in the left lane unless you're passing someone. Sounds awesome, doesn't it? It is.
Our arrival at the hotel was uneventful. We settled in to relax after a long drive, and I realized that the cold I caught a few days earlier was not going away. That's right -- we're all the way in Munich already and I'm going to be too sick for Oktoberfest? You're out of your mind! So, I took some DayQuil and we hit the road. (None of those ingredients interact with alcohol, right?)
So, to everyone who's been wondering what the hell Oktoberfest is actually like, your wait is at long last over. Oktoberfest is basically like the State Fair with tons of beer and no animals (except the cats and dogs that are falling out of the sky the entire time). Yes, there's rides and BBQ and bratwursten, etc. And there's a SHITLOAD of people to go along with all that.
We got inside, and we made a beeline for the nearest tent. However, what we didn't account for was the fact that every college student and beer-swilling European within a 12 light-year radius knows about Oktoberfest and therefore getting inside any of the beer tents is kind of a “big deal”. We tried about 10 different big name tents (Paulaner, Hof Brau, Spaten, etc.) and kept running into really long lines. All we could do was gaze longingly into the warm, colorful room through the cold and rainy window panes.
Luckily we found a place that had a “biergarten” where we could order beers outside in the rain instead of waiting to get inside. Lucky us. So we got some beers and took them over to the Hof Brau building and sat in their (covered) patio section, hiding the brand logos on our beer mugs.
We drank and chatted and drank some more and then ate and finished it up with some drinking, and then when we were all stumbling drunk at about 9pm, they suddenly opened the doors to let everyone inside. I ran in and jostled around with the crowd. Sorry the picture looks so blurry, but that's how it really was.
At some point during the evening, on some bathroom run or another, we were waylaid by a group of drunken ruffians who kept grabbing us and jumping up and down hollering. They were pretty funny and pretty friendly, though. When we left, one of them said, “You are cools. Peace nigga.”
Well, there you have it! That's what Oktoberfest is like. Now back to the vacation at hand...
Thursday, September 29, 2005
The last 48 hours have been pretty intense, to say the least. Here is the “Cliff Notes” version of what happened.
After we got settled into our seats on the plane, I began to notice a commotion. I turned and saw a scrawny, weird looking man with glasses and a shifty demeanor arguing in German with one of the flight attendants. The attendant seemed to be explaining something in a way that said, “Sorry, I can't help you,” and the man was getting progressively more upset at this. Finally, the crew leader was called into the fray, and she continued to deny the man whatever it was that he so desparately wanted. They ordered the man to go back to his seat, and he did, very disgruntled.
After take off, I noticed the commotion starting up again. I looked behind me, and there was the same man, arguing with the flight attendant. Except this time, the flight attendant was pushing the man forward through the aisle, until they reached our location. Here there was a platoon of flight attendants, all gathered around this guy. Now I'm thinking, Great, they're going to have to take this guy into custody and do an emergency landing at some podunk airport and my carry-on luggage that they forced me to check is going to get lost. Just about when I was sure they were going to tackle him and tie his hands together with hair ties, the crew leader came on the intercom and explained that the man was refusing to take his window seat and that they were requesting someone to trade with him. Somebody did, and our flight proceeded as normal.
As an aside, let me just take this moment to explain something about sitting next to the bathroom on an airplane. First of all, people do not wait to go. They all get up at the same time and then stand in a huge group of 15 or more next to the bathroom. And then they all act totally surprised when a flight attendant comes down the aisle or when another passenger needs to leave the bathroom, at which time they proceed to jostle around and step on all your shit, laughing loudly in whatever annoying dialect they speak, as if hanging out by the bathroom is the cool thing to do.
Anyway, finally the sun came up and we landed a couple hours after that.
After we landed in Frankfurt, we wandered around through the asphixiating haze of cigarette smoke (yes, smoking is legal and even encouraged in German airports), until we found a payphone. This turned out not to be very far, since the German Air Transport Board is apparently partially owned by T-Mobile. We tried calling Dan, our connection in Germany, but after several attempts (and a beer at the “Irish Pub” downstairs), we were unable to get a hold of him. So we left messages and decided to hang out in Frankfurt all day.
We took the subway into downtown and saw some interesting stuff. The subway entrance reminded me a lot of Ghirardelli Square in San Francisco. There are a few shops and vendors around, and stairs lead up to the street level where citygoers are bustling back and forth.
The city is a nice one. There are no bums, no gangs or other ruffians. Everything is pretty much clean and nice looking. There are quite a few American companies present, including Subway (which had a line out the door while the locally owned Mexican cantina next door was empty).
We wandered around and found a nice park that had a fountain and other nice scenery.
After exploring for a little while, we hit the phone again and finally got in touch with Dan. It turns out that he got our message, but he thought we were already in Landstuhl, the town by where he lives. He said he had been waiting there for 2 hours. We decided that we would leave Frankfurt ASAP and then call him again when we got to Landstuhl.
Our first challenge against the German rail system began when we descended back under downtown to return to the airport. After staring at the map and times tables for about 15 minutes, and looking around confusedly (keep in mind, neither of us speaks or reads German), we found a nice man that explained to us we were looking at entirely the wrong board. He helped us find the right train, and soon we were back at the airport buying tickets to Landstuhl.
Here is an example of a German rail itinerary:
You might be wondering why I'm showing you this, as it makes absolutely no sense. And that is precisely my point. The German train system makes no sense. In order to know which train you're supposed to get on, you have to know the final stop of the line that goes to your destination. All of this confusion led to us getting on the wrong train at some point, and going 45 minutes in the wrong direction. Finally the sick feeling of forsakenness passed, and I just accepted our fate, not too long before our train arrived at our newly “scheduled” stop.
We deboarded at Mainz and spoke with an attendant there. She printed up a secondary itinerary to take us to Landstuhl from our current location. So, we called Dan to let him know what happened, and we happily waited for the train. Once on board and on our way, we rested easy, knowing that we only had another hour and a half with two more connections to go. But as our scheduled transfer time drew close, and the transfer station was nowhere in sight, I began to grow uneasy again. Our uneasiness faded into resigned frustration when the scheduled arrival time came and went. We deboarded the train 10 minutes late to find the other side of the platform completely empty.
After examining the board (I'm becoming an expert by this time, like an archaeologist reading hieroglyphs), I determine that the next train will not be by until an hour from now. So we just accepted the reality of the situation and hunkered down for the rest of the hour.
Notice the time in the picture on the right. We started at 4 and it's already after 7. Not to mention the 11 hour plane ride. And we still have an hour and a half to go... But at least the Germans have a good policy about breakdancing.
The remainder of the day presented no more surprises and no more detours, and now we are happily settling in at Dan's house.
Copyright (c) 2005 Steven Padfield. Any images or other content in this publication can only be used with the express written consent of the author.
Thursday, September 22, 2005
Thanks for visiting. You're here because you want to find out about my trip to Germany for Oktoberfest from 9/27 to 10/11.
For those of you who don't know (which is most of you), I'm going to Germany with my good friend Scott, and we're visiting our good friend Dan who's stationed at Ramstein Air Force Base in Kaiserslautern. The three of us have been friends since high school, so it's sure to be a raucous two weeks. We plan to go to Munich for Oktoberfest celebrations, then to Amsterdam for ... celebrations, then wherever else strikes our fancy.
Keep checking back here for updates throughout the next several weeks!
Click here for the RSS feed.
For those of you who don't know what Oktoberfest is, it is basically a big beer-party.
Here are some random Internet pictures...
Wednesday, July 27, 2005
In K. Scott Allen's recent post, The Problem with Test Driven Development, he cited what he calls a "fundamental problem" with the TDD approach: the use of the word "failure". Although I appreciate the tongue-in-cheek irony of what he's saying, I wonder if the essential point of TDD's first step escapes most developers.
What is TDD?
The TDD approach can be outlined in three basic steps:
- Write a test that fails
- Make changes to the model code until the test succeeds
- Refactor
Mr. Allen's issue with step number one, whether offered jokingly or not, is the use of the word "fail". Indeed, why would a developer wish to write code to ensure failure, only to fix it in the next step? The answer is intuitively simple: to ensure that the newly added test is actually doing something. To expand on this idea, let's examine the basis of test driven development and what functions it serves in the development process.
First of all, what is the point of writing tests in the first place? Obviously, we wish to have some amount of confidence that the code we've written does what it's supposed to do. Also, we want to know that if we make a change to the code, say to fix a bug, that the change will not cause a defect in some other part of the application. In this regard, tests also help ensure that we don't break existing functionality while maintaining an application.
So that's great, we're all on board with automated unit testing. But why must we write a failing test before writing the code to be tested? Why not write the code, write the test to verify it, and then move on?
There are two reasons this is a bad approach:
- You cannot be sure that your test is working.
- The test will verify the code does what it does rather than what it's supposed to do.
Let's look at these one at a time.
Is the test working?
By adding a test before writing code, one is attempting to ensure that the addition of new code satisfies a requirement that was not previously satisfied. If you write a test after the code is already in place and you get a green bar, how do you know you wrote the test correctly? What if the test is testing the wrong function? Now you've introduced new code that is not covered by a test, and no one will know about it until a customer discovers the bug.
When you follow the first step of TDD, "write a test that fails," you are ensuring that the test you just added is testing something new. If your new test succeeds on the first run, you know you either implemented the test incorrectly, or you are attempting to add functionality that already exists in the application. In this context, the red bar is a sign of success: that we've just written a working test that tests functionality not yet implemented! With this feedback, we can be confident that when we achieve a green bar after adding model code that it will mean something - that it won't be a false positive.
Am I testing what the code is supposed to do?
Another side-effect of writing a test after writing code is that there is more of a tendency to write the test to verify the code, rather than writing the test to verify that the code meets the specification. By writing the test first, you do not have a "cheat-sheet" of what you want to test. You must think about the input and output of the method/class you are testing. You must think about the functionality that you want. You must think about interfaces and contracts. Writing the test first forces you really to be certain about what you want the code to do.
Failure equals feedback.
According to Mr. Allen, "The problem is no ambitious person will wake up in the morning, walk into the shower, and plan ahead for a day of failure." While this is true, the first step of TDD does not represent a day of failure. It represents a recognition of what has yet to be done. What person will wake up in the morning, walk into the shower, and go to work without first realizing that these things have not yet been done?
In terms of political correctness, the word "failure" may seem kind of harsh. But test driven development is about solid and robust code, which makes us feel better than all the sugar-coated language in the world could. I guess I'm a fan of simple language.
References
Test Driven Development: By Example, Kent Beck
Thursday, November 11, 2004
Name
Declarative Registration
Other names
Implicit Registration, Passive Registration
Description
Provides a way to declaratively register classes in a central registry without requiring explicit registration method calls.
Context
Microsoft .NET applications.
Forces
Sometimes a registry is required in order to manage a collection of classes. For example, if there is a collection of Command classes that each correspond to a specific command in an application, it could be useful to have a registry whereby Commands can be created based on name. Normally, a registration function would be required to explicitly register all the applicable classes in the application.
The problem is that the registration function is then coupled with the classes it is responsible for registering. There are two aspects to this coupling: one, the registrar needs to explicitly know the name of the classes being registered as well as any other required registration attributes. Two, whenever a new class is defined and needs to be registered or when a class is removed, a corresponding change must be made to the registrar function.
To compound the problem of coupling, there is a lack of locality in that registration properties are really attributes of the class, yet they do not appear on the class and there is no indication on the class that those properties are specified anywhere. Thus it is not obvious from looking at the class whether it is actually being registered, what registration attributes apply to it, or where the registration is being done.
The Declarative Registration pattern is a method of class registration that solves both the problem of coupling and the problem of locality by storing the registration attributes with the class itself.
Implementation
- Define a custom class attribute to act as a registration declaration. Include as public properties any parameters you wish to have included in the registration declaration.
- Apply the attribute to classes that need registering, parameterizing as needed.
- Define a method that uses reflection to find all the classes marked with this registration attribute, processes the properties of the attribute (if there are any), and instantiates the class.
Example
(assumes an ICommand interface is defined)
[AttributeUsage(AttributeTargets.Class)]
public class CommandAttribute : Attribute
{
public CommandAttribute(string name) { this.Name = name; }
public string Name;
}
[Command("Foo")]
public class FooCommand : ICommand
{
public void Execute() { /* ... */ }
}
[Command("Bar")]
public class BarCommand : ICommand
{
public void Execute() { /* ... */ }
}
public class App
{
public void ExecuteCommand(string commandName)
{
// iterate through all the types in this assembly
Type[] types = Assembly.GetExecutingAssembly().GetTypes();
foreach (Type type in types)
{
// see if the type has a CommandAttribute
CommandAttribute[] attr =
type.GetCustomAttributes(typeof(CommandAttribute), false)
as CommandAttribute[];
if (attr.Length != 0)
{
// see if the CommandAttribute name matches the given
// command name
if (attr[0].Name == commandName)
{
// instantiate the command object and call Execute()
ICommand command = Activator.CreateInstance(type) as ICommand;
command.Execute();
}
}
}
}
}
Participants
RegistrationAttribute (CommandAttribute)
- Custom class attribute.
- Declaratively marks a TargetClass for registration.
Registrar (App)
- Responsible for building a registry of TargetClasses that are marked with RegistrationAttribute.
TargetClass (FooCommand, BarCommand)
- Class being registered.
- Has a RegistrationAttribute declared on it.
Consequences
The registration declaration for a particular class or object resides with the class, rather than in a separate registration function. This makes it trivial to add a newly created TargetClass to the registry or to change properties of the registration for a specific TargetClass (for example, to change the declarative “name” of a Command class). The relationship of the TargetClass to the registry is obvious, because the registration declaration appears with the TargetClass declaration.
The process of building the registration table still happens at run-time, but can execute in a lazy fashion. In the example above, it would be a good idea to extract the registration algorithm into another method which is called only once, the first time ExecuteCommand() is called.
Multiple Assemblies
Extra work needs to be done to handle registration across different assemblies. The example given above only examines types that are part of the executing assembly. It would be relatively simple to have the registrar search for and load other assemblies from disk and examine their types in a similar fashion, or to have it simply search within assemblies already loaded in the current AppDomain. However, it is important to be aware of whether each assembly will have its own version of the RegistrationAttribute or whether they all share the same type reference.
If one and only one assembly declares the RegistrationAttribute and all the satellite assemblies import a reference to that assembly, then there is only one version of the RegistrationAttribute that is valid across all assemblies. In some situations, importing a reference may create a circular dependency or be otherwise undesirable, and therefore each assembly must declare its own RegistrationAttribute. In this case, the registrar needs to obtain a type reference for the specific RegistrationAttribute class that resides within the assembly being searched.
If the registrar is searching through all currently loaded assemblies, then it must re-conduct its search every time it is called (i.e. it cannot reuse a registry after building it once), because the list of loaded assemblies in the AppDomain can change between calls.
Subclassing Instead of Attributing
It is possible to apply this pattern without using the RegistrationAttribute. Subclassing is also an effective way of indicating that a TargetClass needs to be registered. However, this method of declarative registration is frankly less declarative, and it does not allow for any registration parameters. It is also misusing the mechanism of inheritance, which is a mechanism to inherit behavior, not a mechanism for classification.
Methods of Instantiating TargetClass
In the above example, the registrar instantiates the TargetClass by calling Activator.CreateInstance(). This requires the TargetClass to have a default constructor. In situations where instantiation of the TargetClass must be parameterized (for example, to pass in some sort of application state), reflection must be used to obtain and invoke the appropriate constructor with the parameter(s) at hand.
Here is what the code would look like if you needed to pass an instance of the Registrar (App) to the constructor of the TargetClass:
ICommand command = type.GetConstructor(this.GetType()).Invoke(this) as ICommand;
Of course, a more robust solution would include a check for null and throw an appropriate exception if the TargetClass did not have the right constructor.
A Note About Performance
Obviously the performance of an application that uses declarative registration will be slower than one that uses explicit registration. However, keep in mind that Microsoft's implementation of reflection in .NET is very fast, and the difference in performance we are talking about is in the 10s of milliseconds. Thus you do not want a scenario in which a registry is built from reflection frequently (many times a second), but I can't imagine that such a scenario is common. In any case, it stands to be noted that this pattern only applies to scenarios involving minimal call frequencies. When possible, the registry should be cached in memory rather than rebuilt, which will limit the performance hit to the first call. Yet again, however, we have a trade-off, as this approach does not eliminate the performance cost, it just defers it from call-time to working-set.
Wednesday, September 15, 2004
If anything can be demonstrated by the loss of “friend” when moving from C++ to C#, it's that good design is hard to do.
Invariably you will run into a situation where the good programmer inside you lapses into a self-destructive hack addict with an overpowering urge to score a quick fix. The quickest fix of all is to dissolve encapsulation. And now that our better judgment is faltering after hours of frustrated caffeineation, this would seem to be a good solution. Yet there is a cost: that the erosion you initiate cannot be stopped. Bad code multiplies like a virus, and holes in abstractions are like open-mouth kissing between classes.
Why is the friend declaration so bad? Because simply, it defeats the purpose of encapsulation: to hide data and protect the implementations of types from other classes so that they are decoupled from their environment. But what's more sinister is that on top of just being bad, the friend keyword encourages its own use. Its very existence is not only a temptation, but an endorsement of a bad design decision. If a programmer finds himself in a situation where he “needs” to compromise encapsulation, the correct course of action is not to poke holes in the walls that protect implementation. The correct course of action is to rethink the design and root out the flaw that is underlying the conflict.
In recent years, we have come to understand from a rational perspective that our urges, though motivated by a desire to do good, can only bring evil into our lives. Yet we still find ourselves prone to temptation during those frantic hours long and late spent coaxing storms of panic back into the base of our brains long enough to get a green bar.
So how does Microsoft respond to this persistent social disease? They simply remove the friend keyword altogether. Now all of us shuddering addicts have no choice but to become better programmers.
Does this represent a loss of flexibility in the language? Yes, of course. But there is a delicate balance between flexibility and robustness, and in this case, a friend can be your worst enemy.
Monday, September 13, 2004
Hello all.
This time I went on my favorite drive through the Castro Valley, east of Oakland. I started up into the hills on Wildcat Canyon Rd, which leads into Grizzly Peak Rd. I took that over to Skyline Blvd, and onto my favorite road, Pinehurst Rd. After a nice, long, weaving drive through patches of shade beneath the overarching canopy of trees that line this beautiful road, I finished up on Redwood Rd.
Check out the gallery here.
Saturday, September 11, 2004
It's been a while since I've gone for a nice drive, so I decided to give it a shot. Since Sacramento is pretty much dead-smack in the middle of nowhere in terms of good roads to drive on, all the locations I had to choose amongst are at least an hour away. This time, I thought I'd go check out Highway 49 running down through the El Dorado Hills and Pool Station Road. Although the weather was pretty hot and the scenery was very dry and brown, there were some good turns and straights on this drive, especially on the less traveled parts.
You can check out the gallery here.
Tuesday, August 31, 2004
My name is Steven Padfield, and I'm a software engineer at a small company in Sacramento, CA where I work primarily with ASP.NET.
I hold a profound fascination with Genetic Programming, and it is my intention to develop a generic, pluggable framework for running studies on various GP problem domains. Of course, the holy grail is to develop a winning strategy for the game of craps, at which point I will siphon a small fortune from Las Vegas and then live off the royalties from licensing this technology to the rest of the world. At that point, I may have the option to invest in time travel technologies or cybernetics, but that's still up in the air for now. I'm definitely going to have bionic eyes at some point in my life, that's for sure.
In my spare time, I race my Subaru WRX in SCCA RallyCross, which is basically “entry-level” rally racing with no rocks, trees, cliffs, water, jumps, burms, or any other obstacle. But nevertheless it's fun, and it sounds cool to say that I race my car.
