Monday, May 19, 2008 - Posts

• The Ogden Marathon

  Well, like I mentioned back in January , one of my major personal goals for this year has been to complete my first marathon. I started training back in December and followed Hal Hidgon's novice training program . I only missed a few runs here and there but was able to stay pretty consistent throughout the 18 week program. Sometimes it got a little tricky while traveling but thanks to the GMaps Pedometer , LogYourRun.com , and my Garmin Forerunner 305 , I was able to figure out decent routes on the fly. I trained for the Ogden Marathon , which was held this past Saturday. We had to get up at 3:45am to drive into downtown Ogden to catch the buses at 5:00am that shuttled us up the canyon and into the mountains. We arrived at the start line around 6:00am where we found some bon fires and about 50 green porta-potties lined up in a row. There were about 2000 runners, which is max-capacity for this marathon. My wife and I found our friends we'd been training with and joked around until the start of the race, trying to reduce the nerves as much as possible, hitting the porta-potties occassionally, while trying to stay warm. It was very cold up in the starting area -- cold enough to see our breath. But we also heard we we're going to have record-breaking heat later in the day, somewhere in the 80-90 F range. After a short motivational speach by Jeff Galloway , the race started promptly at 7:00am and there was no turning back. The first 8 miles of the race was mostly downhill, running down a small canyon into the valley of Pineview Reservoire . The next 10 miles required us to run around the reservoire. There were several long stretches that never seemed to end and only one hill worth mentioning. The route took us to the top of Ogden Canyon, where we began our decent into downtown Ogden. This final canyon decent was about 6 miles long (from miles 17-23), at which point we got on the Ogden River Parkway running path for the next few miles until we emerged onto Grant Street and could see the finish line a mile down the road. So the course was mostly downhill -- and is generally considered easy -- but it didn't turn out that way for me. There was a great deal of excitement, energy, and adrenaline in the air when the race began. So like an inexperienced first-time-marathoner I started out way too fast. My normal long run pace is a little under 9:00/mile and I ran the first 3-4 miles at a 7:30/mile pace. I knew I was probably running a little too fast for my own good so Read More... Posted Monday, May 19, 2008 6:50 AM from Service Station, by Aaron Skonnard | 0 Comments

• Smells like a domain-specific language for using WCF

  No, not these kinds of domain-specific languages (DSL)... I must admit, the following code has a not too small degree of sexiness. The DSL-iness is not just for WCF but for a number of mainly dependency-injection-related scenarios, but obviously I tend to care more about WCF :) Service side: var windsorContainer = new WindsorContainer() .AddFacility<WcfFacility>() .Register( Component.For<LoggingInterceptor>(), Component.For<IMyContract>().ImplementedBy<MyService>() .ActAs(new DefaultServiceModel().AddEndpoints( WcfEndpoint .BoundTo(new NetTcpBinding()) .At("net.tcp://localhost/MyService/internal") ) ) ); Consumer side: var windsorContainer = new WindsorContainer() .AddFacility<WcfFacility>() .Register(WcfClient.ForChannels( new DefaultClientModel() { Endpoint = WcfEndpoint.ForContract<IMyContract>() .BoundTo(new NetTcpBinding()) .At("net.tcp://localhost/MyService/internal") }) ) ); I am currently investigating a bit into Windsor Castle and its WCF facility. What I see until now I like, but I am just at the beginning. There is a lot more in Windsor's WCF support which is worth digging into - all in all these features are aimed to make using WCF a bit more natural and a bit more straight-forward. Some feature points from the latest release: *Client Side: Automatic generation of WCF client channels when a component has been configured for WCF Client capabilities. Any Endpoint or Operation behaviors registered in the kernel will be attached to the channels. Automatic cleanup of channel proxy when component is released (channel.Close() vs channel.Abort), i.e. no need to cast proxy to IChannel and call Dispose. Automatic detection of unhanded channel faults and re-acquisition of new channel proxy. You can continue to use client proxy even after an exception occurs (by default WCF makes all faulted channels unavailable). Ability to use the client channel configuration from app.config/web.config Custom registration provider to simplify batch registration of channels Client extensibility interface IClientChannelBuilder. Supports plugging in other ways to create channels (e.g. REST-ful services) *Service Side: Automatic management of ServiceHost when a component is configured for WCF Service capabilities. Any Service, Endpoint or Operation behaviors registered in the kernel will be attached to the channels. Ability to use the service channel configuration from app.config/web.config Service extensibility interface IServiceHostBuilder. Read More... Posted Monday, May 19, 2008 5:10 AM from Christian Weyer: Smells like service spirit | 0 Comments

• Guide you, the Force should

  Steve Yegge posted the transcript from a talk on dynamic languages that he gave at Stanford. Cedric Beust posted a response to Steve's talk, espousing statically-typed languages. Numerous comments and flamewars erupted, not to mention a Star Wars analogy (which always makes things more fun). This is my feeble attempt to play galactic peacemaker. Or at least galactic color commentary and play-by-play. I have no doubts about its efficacy, and that it will only fan the flames, for that's how these things work. Still, I feel a certain perverse pleasure in pretending, so.... Enjoy the carnage that results. First of all, let me be very honest: I like Steve's talk. I think he does a pretty good job of representing the negatives and positives of dynamic languages, though there are obviously places where I'm going to disagree: "Because we all know that C++ has some very serious problems, that organizations, you know, put hundreds of staff years into fixing. Portability across compiler upgrades, across platforms, I mean the list goes on and on and on. C++ is like an evolutionary sort of dead-end. But, you know, it's fast, right?" Funny, I doubt Bjarne Stroustrup or Herb Sutter would agree with the "evolutionary dead-end" statement, but they're biased, so let's put that aside for a moment. Have organizations put hundreds of staff years into fixing the problems of C++? Possibly--it would be good to know what Steve considers the "very serious problems" of C++, because that list he does give (compiler/platform/language upgrades and portability across platforms) seems problematic regardless of the langauge or platform you choose--Lord knows we saw that with Java, and Lord knows we see it with ECMAScript in the browser, too. The larger question should be, can, and does, the language evolve? Clearly, based on the work in the Boost libraries and the C++0X standards work, the answer is yes, every bit as much as Java or C#/.NET is, and arguably much more so than what we're seeing in some of the dynamic languages. C++ is getting a standardized memory model, which will make a portable threading package possible, as well as lambda expressions, which is a far cry from the language that I grew up with. That seems evolutionary to me. What's more, Bjarne has said, point-blank, that he prefers taking a slow approach to adopting new features or ideas, so that it can be "done right", and I think that's every bit a fair position to take, regardless of whether I agree with it or not. (I'd Read More... Posted Monday, May 19, 2008 12:34 AM from Interoperability Happens | 0 Comments Filed under: .NET, Java/J2EE, Ruby, XML Services, C++, Windows, Languages, Mac OS, Parrot, LLVM, F#, Visual Basic