Kyle Baley - The Coding Hillbilly

January 2008 - Posts

• Career Opportunities in the Bahamas: Don't get your hopes up yet

  In response to numerous enquiries, I present: the reality of working the Bahamas. The part on living here will come maybe tomorrow but more likely next week. Before I start though, some background that will almost certainly break the mystique I've somehow built up of a software developer working in the tropics who calls himself Hillbilly. I didn't come here to escape the hustle and bustle and spiteful climate of urban Canada. My wife works for a fellow whose clientele is approximately 5% Canadian and he's on site in whatever country he's working in about ten to eleven months out of the year. He decided to move to the Bahamas because it didn't make sense for him to pay tax in Canada when he didn't live or work there for the most part. We came along for the ride not really knowing how I'd manage my career. So there you have it. I'm trying to figure things out as I go, just like you are. Apologies if I've shattered any images you have of me. I don't do "role model" very well. So now, with confidence and expectations reset, let's carry on... I won't sugar coat this. There are few if any career opportunities for software developers here, especially in an intermediate or senior capacity. I worked for two months for one development shop and eight months at another. Both on commercial software and both for about half my going rate outside the country. And both were very small places where you are responsible for not only development, but maintaining the company network and providing technical support. To my knowledge, these two places account for two thirds of the places that actively hire software developers as part of their core business (and I can't confirm that one of them is even still in business). The third is a fellow who, I've heard, has a team of people building databases and applications specifically to manage and increase his wealth. The overwhelmingly main industry is tourism. The biggest hotel is Atlantis which is actually based here and does hire software developers. In fact, I notice that they've got a recent opening for a systems analyst if you're willing to work 45 hours a week which doesn't mesh with my plan to take Fridays off. The rest of the tourism industry consists mostly of: a) chains where IT solutions are mandated from above, or b) small hotels/family run activities where technology generally runs counter to the image they're trying to portray. The next big industry is banking. Again, much of the banks have their head office elsewhere. Two of the more popular consumer banks are, in fact, Royal Bank of Canada and ScotiaBank - both based in Canada. I know for a fact that the online banking software the Royal Bank uses is at least ten years old compared to what they use in Canada. There is also a big insurance contingent which is somewhat more promising. I interviewed with a company that was going to hire me for a position created specifically for my skillset as a software developer with an actuarial background. Starting salary: $37k/year. (Side note: Don't let anyone try to justify salaries here by saying, "But it's tax-free". Nothing, and I do mean *nothing*, is tax free.) My experience is that in most cases, there simply isn't the base level knowledge of what IT solutions can provide or even that the current process can be improved. When there is recognition of problems, the mentality is to hire a couple of junior developers out of college to patch something together rather than plan it out as a project. This is why I find contracts working remotely. Not because I've got it all figured out. But because historically, I've have to if we want to continue living here. Which is a decision that changed daily in the beginning but nowadays fluctuates less frequently, changing more with the seasons. And this is why I'm turning my focus on developing the industry here. Both in terms of generating demand locally for quality software as well as creating the infrastructure, network, and processes that will enable remote workers to live here and work elsewhere. After almost five years, I finally have a decent enough handle on things here that now is a good time to start helping the country realize its potential. Admittedly, the main impetus for this was born out of my own frustrations and I have some not-so-altruistic reasons for it. But by the same token, there are benefits to be had by all. Myself, the country, other developers, companies willing to step outside the typical mindset. Now there is a caveat here. At one point, someone did have a go at building a software consulting company here. Not long ago in fact. His experience was that the demand existed but that he couldn't get people to do the work. He ended up having to hire a consulting company in the U.S. to finish the project he started, took a bit of a bath (fixed bid...brrrrr....), and got back to the business he had before which was, and is, still going strong. This doesn't jive with my own experience but it is encouraging. My fear is that by "get people to do the work", he meant that he couldn't get high-quality people to do the work for a pittance. In any case, I've spoken with him a couple of times and am overdue to do so again shortly. So for those of you already packing their shorts and thongs in response to my penultimate post, hang tight unless you have an alternate source of income. And even then, you'll want to wait until my next post on non-work life down here. As a primer for that, I'll remind you that this *is* a third world country... Kyle the Developer Posted Jan 31 2008, 03:48 PM by Kyle Baley with 9 comment(s) Filed under: Career

• CruiseControl, VS2008 and ASP.NET MVC

  Everyone who e-mailed me asking about the realities of working down here, I will respond on this blog in the coming days. I need to take a break first and write on a technical topic since those seem to inspire far fewer e-mails for me to respond to. Before I do, quick reminder that the South Florida Code Camp is this weekend in Miramar, which is somewhere 'twixt Miami and Fort Lauderdale, I hope. Come check it out. There are twelve, count 'em, TWELVE tracks, including a Spanish one. I will be there in full hillbilly regalia chattin' on MVC, TDD, and Brownfield development. Some awesome looking sessions too. I may duck out of my own MVC talk to see the one on For Love or More Money (which is co-presented by the uncannily-named David Silverlight). Anyway, back to our own little vaudeville here... I'm setting up a brand new ASP.NET MVC project and I've created for it a shiny new NAnt build file that performs the following steps, in order: Compiles the application I want to do this in baby steps, you see. My goal is to get everything into CruiseControl as quickly as possible and for the time being, all I need is to compile the app. After that's done, I'll start adding test projects, test targets, deployment packages, real code, and so on and so forth. But first, CI. Harder than one might think, don't you know, and the rest of this post will consist of various error messages and the minor tweaks involved in getting around them. Getting the build file to compile the app on my local machine was relatively straightforward thanks, once again, to Jeff Palermo's CodeCampServer sample project. There was one minor hiccup in that the version of NAnt I had didn't like the 3.5 framework but Jeff already had that covered. So I copy and paste my way through setting up the project on my build server and lo! BUILD FAILED Failed to initialize the 'Microsoft .NET Framework 2.0' (net-2.0) target framework. Property evaluation failed. Expression: ${path::combine(sdkInstallRoot, 'bin')} Google helps me determine that this has been fixed in the latest nightly build for NAnt. So bada-build-bing, I switch to the uber-latest version of NAnt, check it works locally, check in to Subversion and wait for the build to complete: ./Trilogy.Gunton.sln(2): Solution file error MSB5014: File format version is not recognized. MSBuild can only read solution files between versions 7.0 and 9.0, inclusive. External Program Failed: C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\msbuild.exe (return code was 1) Fix for this was to read Jeff Palermo's previous post *all* the way through and set the nant.settings.currentframework property to net-3.5 in my build file. Which leads to the next error: C:\data\ccnet\Trilogy.Gunton\src\app\Trilogy.Gunton.Web\Trilogy.Gunton.Web.csproj(89,11): error MSB4019: The imported project "C:\Program Files\MSBuild\Microsoft\VisualStudio\v9.0\WebApplications\Microsoft. WebApplication.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk. External Program Failed: C:\WINDOWS\Microsoft.NET\Framework\v3.5\msbuild.exe (return code was 1) This was an interesting one in that I found a solution right away but didn't much like it. It says to copy the Microsoft.WebApplications.targets file to your solution directory, then modify your .csproj file directly so that it uses the copied file rather than the one it's expecting in Program Files. What I don't like about the solution is that it involves copying a file that might change. Plus, it's seems more than a little subversive. Having said that, the only other solution I found was to install a version of Visual Studio on the build server and blimey, I'm surprised how many people think that's okay. I'll have to pick someone's brain on that because it feels really, really wrong. But I've gotten used to worse. Anyway, in the end, I went with copying the targets file to my solution directory. Note: in order to pass the SolutionDir variable to MSBuild from NAnt, as the link suggests, you pass it in through the /p switch. Example: <exec program="${framework::get-framework-directory(framework::get-target-framework())}\msbuild.exe" commandline="${solution.file} /t:Rebuild /p:Configuration=Debug;SolutionDir=${current.dir} /v:q" workingdir="." /> After that, it worked! OK, that's a lie. The next error was thus: Controllers\HomeController.cs(3,18): error CS0234: The type or namespace name 'Mvc' does not exist in the namespace 'System.Web' (are you missing an assembly reference?) This was a fairly easy one. I could either install the ASP.NET Web Extensions CTP on the build server or reference all the relevant assemblies locally. I chose the former because the eventual production server will need to have it installed anyway. So here's hoping this string of errors helps a soul as lost as mine. Kyle the Cruised Posted Jan 30 2008, 11:55 AM by Kyle Baley with 7 comment(s) Filed under: ASP.NET MVC, Continuous Integration

• Wanted: IT Professionals to Create an Industry

  There's no getting around it. I live in the Bahamas and it's about time I start accepting that fact. And one of the items that's been on my to do list for a while now, nestled between "Lose ten pounds" and "Fix the hole in the drywall" is "Drag this country into the 21st century." There is no software development industry in the Bahamas. And there should be one. It's criminal the opportunity the country is wasting by not trying to create one. Not only do they have reliable high speed internet (I've heard tell they have a direct line to some main Internet thing-y in Miami via a big cable along the ocean floor), but there are at least three US cities that are less than an hour and a half from here by plane (although admittedly, they're all in Florida). And there are other regular direct flights to New York, Atlanta, Dallas, Washington, Calgary, Toronto, and London, which are the cities I know off the top of my head. These are only the advantages for companies that might be interested in investing in remote workers based in the Bahamas. For the worker himself/herself, I don't think I need to dwell too much on why you should consider it. For the government, it means an influx of young professionals with lots of disposable income who won't be stealing jobs from locals but will be spending money locally. So, after getting a bit of a kick-start from someone who will remain nameless because the power cut out during our conversation before I asked permission to name-drop him, the wheels are in motion. The goal: work with the government to encourage IT professionals to move to the Bahamas to work remotely and to encourage companies to invest in said IT professionals. What that entails, I'm not quite sure. I didn't do that well in the "IT industry planning for third-world countries" course in university. Perhaps it means first upgrading the government's systems (or, in some cases, installing them since a lot of them are still paper-based). Maybe it means streamlining the process for getting residency permits. Or setting up a network to help people get accustomed to a place where Starbucks closes at eight. Or creating a registry of qualified tradespeople that haven't screwed people over in the past. Don't rightly know, just thinking out loud. Now to be sure, there are many reasons why the fantasy of living and working in the Bahamas is different than the reality. But given what I've seen of the weather in western Canada in the last two days, I have a feeling any arguments I make against working here will fall on deaf and/or frozen ears. If, after reading this post, you want to help me on my quest, contact me directly and I'll give you an honest run-down. In any case, a prospecting e-mail has been sent to the deputy prime minister who I'm fully expecting will ignore it. It's more of a courtesy because I have a back-up plan that is more direct and more likely to get results. (Hint: The adage "it's not what you know, it's who you know" is practically baked into the constitution here.) In the meantime, my task for each of you is to give a long, hard look at where you are living and working. Take your time... Kyle the Patient Posted Jan 29 2008, 10:32 AM by Kyle Baley with 17 comment(s) Filed under: Career

• Interview question: Tell me about your mother

  The Hillbilly turns 36 today and for my birthday, each and every one of you is going to give me a present by listenin' to a little story of when I was but a wee developer fresh out of codin' skool. (Unless you're on the ASP.NET MVC team, in which case you could offer me a job since one of the criteria for working on the team seems to be having Garnet as your birthstone). Eight years ago, I was hired for what was essentially my first full-time development job. I had dabbled with Visual Basic on and off for a year or so and  Y2K tested Delphi for a company that didn't trust Borland's public statements (no, seriously) but that's it. This was a job with a small company that sold an ASP-based learning management system with a twenty-year-old C component and some Word VBA templates. And when I say small, I mean that when I came on board, I doubled the size of the development team. At that point, I had never laid eyes on a single line of ASP code. Now, before the interview, I had actually lost the ad (it was posted in the newspaper) so I had no idea what it was about or even what the company was named (it was run out of an office in a local technical college). Note the foreshadowing... Interviewer: Did you look up anything about the company? Coding Hillbilly: Oh yes, of course Interviewer (pleasantly surprised): Really? What did you find? Coding Hillbilly: That you're...ummm...based out of...<school name>...and you build...stuff? ... Interviewer: So I don't see any ASP in your resume. Do you know much about it? CH: Oh yeah, I've been studying it in my free time Interviewer: What can you tell me about it? CH: ...err....that it stands for Active....Server....Programming? And you can...build....stuff? ... Interviewer: There was another website in the job ad. Did you get a chance to take a look at it? CH: For sure, dude! Interviewer (clearly skeptical by this point): What colours are in the logo? CH: .... fuchsia and mauve? Interviewer: Lucky guess. What do they do? CH: They...build...stuff? ... Interviewer: It's very clear to me that you have not done any research on this company or this position. Can you tell me why I should bother to take this any further and consider you? At this point, I came clean, admitted I lost the advertisement, had no idea who they were or what they did, and that I had no practical coding experience. I politely grovelled at his feet and promised to kick my own ass out of the building. The offer came a couple of days later. No, seriously. They called me back and offered me the position. And that's not even the point of this story. But give me a minute, I do have a point. By that time, I had decided to stay where I was. The missus was pregnant with what we later determined was my child and moving from a big oil company with banked holidays to a near-startup that could go under at anytime didn't seem prudent. So after a prolonged stunned silence at even being offered, I politely declined. Two days later, he calls back. What will it take for me to join them? At that point, I had had feelings of regret at turning it down and my wife and I agreed that I would have taken it if they upped the offer by another $5k a year plus a week of holidays. I told him that and he says "Done". (Later, I learned that the only reason my wife agreed to those terms was because she thought there was no hope in purgatory that they would have called back.) By this time, curiosity gets the better of me and I ask the burning question: "Dude! I totally blew chunks at the interview. Why you trippin' to get me?" My eventual boss for whom I gained a tremendous respect replied: To be honest, you weren't the strongest technical candidate by a long shot. But out of all the people we interviewed, you have the best attitude and would fit in with our team. And I've been an educator for many years and have a hunch you're a quick one. Back to the present wherein you probably see where this is going. This fellow took a tremendous risk on me. At the time, I didn't recognize how big a chance it was. The chance was that I had the team skills and the personality fit for the company and that the technical skills would come. Bless him for being able to recognize that and for placing such a high priority on them but my experience is that he's the exception rather than the rule. There have been a number of discussions on interview questions of late in blogs and discussion groups. I'll single out Jeff Atwood's list because...I dunno... it was probably the last blog I read on the topic. I don't have a lot of pride so I don't mind admitting I'd probably flunk his test. And I write code for a living. Worst-case insertion performance of a hashtable? No idea. How do you test if the high-order bit is set? My answer would probably be eleventeen. Even the one on reading integers from a text file I'd probably falter on if I didn't have an IDE with IntelliSense. On a side note, this is probably a dangerous line of thinking coming on the heels of Ray Lewallen questioning the money being spent on mediocrity. But in Ray's post, Dave Laribee comments that the winning attitude and the winning skillz should be rewarded. I.E. Not just the talent and not just the attitude. And even then, what's the definition of "talent"? The ability to recite from a computer science manual? Or someone who knows how to transform business requirements into reasonably designed software and who can figure out the technical problems as they arise. Ideally, you'd want someone that lies somewhere along that spectrum that makes sense to your organization. (Not to imply the two are mutually exclusive, either.) For a research position, business requirements may not be so ambiguous and you need someone who is acutely aware of how to unroll a for loop into assembly. For your average business application, maybe someone nearer the other end. Now, let's not get all crazy and start assumin' I don't care if you are capable of finding all the prime numbers between 1 and 4. You do need to have some base level of knowledge in whatever technology is required. Nor am I suggesting you break out a Rorschach test during the interview. But there needs to be at least some emphasis on the candidate's personality. And maybe I'm overly optimistic/naive, but I have a feeling that if you gear your interview toward determining those less objective traits, you'll be able to determine their level of expertise anyway. By the way, if you're looking for closure on the story, I stayed with them for a year, learned ASP, XSL, DHTML, and VB, then bolted to a consulting company. It sounds rather mercenary and when I think back on it, it was, even if I didn't mean it to be. It was a good move for me career-wise but has always left a bad taste in my mouth. Damn conscience... Kyle the Aged Posted Jan 28 2008, 10:47 AM by Kyle Baley with 11 comment(s) Filed under: Career, Featured

• West Palm Beach and the Fluent URLs

  Ah, it's good to be back on the circuit. The Hillbilly made his first speaking engagement since May '06 earlier this week, thanks to the brave and trusting souls behind the South Florida .NET user groups. They have themselves a nice group out West Palm Beach way and I hope I can come back either there or one of the other places they're in charge of. I can only hope this last meeting was as fateful as my last presentation. The official topic was ASP.NET MVC but we ventured into TDD, DDD, productivity tools, and AJAX if memory serves. Definitely played out differently than I expected but that's why speaking is so fun. Lots left uncovered but that just makes my presentation at South Florida Code Camp next week that much more interesting. The code can be found here (3.8 Mb). It's a music catalog type application that lets you search for music in your library and play it, although only a song at a time. Check the ReadMe.txt for instructions on building. The short version, in theory, is: modify local-properties.xml and run clicktobuild.bat and you're good to go, assuming you have some version of SQL Server installed. It will create an IIS virtual directory pointing to your music folder to allow you to play the songs you select. Before I start rambling on one of the more interesting aspects of the presentation, some acknowledgements. These are the main links I used in preparing both the code and the presentation: Scott Guthrie's Intro Series (Link is to part 4, which contains links to the other three parts) Phil Haack on testing controller actions Rob Conery talks on the MVCToolkit Special thanks to Jeff Palermo's CodeCampServer from which I borrowed very heavily. I didn't go as deeply as he did in the architecture (unit tests? Pffft) and I switched out StructureMap for Windsor because it's what I know. Having said that, I've seen enough sample code for StructureMap that it's near the top of my list of things to check out in the near future. The rest of this post discusses something I showed, albeit briefly, during the talk. It's the idea of "Fluent URLs". It started when I created a search controller based on Scott Guthrie's sample search router. In this version, I'm searching a database of songs. Here is the route: RouteTable.Routes.Add(new Route { Url = "Search/[query]", Defaults = new { controller="Search", action = "Results" }, RouteHandler = typeof(MvcRouteHandler) }); Here are some sample URLs that use this route: localhost/Suvius.Flamingo/Search/Brubeck localhost/Suvius.Flamingo/Search/Folk localhost/Suvius.Flamingo/Search/Muppet Movie Soundtrack And so on and so forth. The idea is that you pass in a [query] and it will find any song containing that text in the title, artist, album, whatever. After that, I got to thinkin'. What if we wanted a more specific query that search based on, say, artist only. So I added the route: RouteTable.Routes.Add(new Route { Url = "Search/FindSongsSungBy/[artist]", Defaults = new { controller="Search", action = "FindSongsSungBy" }, RouteHandler = typeof(MvcRouteHandler) }); And some sample URLs: localhost/Suvius.Flamingo/Search/FindSongsSungBy/Dean Martin localhost/Suvius.Flamingo/Search/FindSongsSungBy/Sarah Mclachlan localhost/Suvius.Flamingo/Search/FindSongsSungBy/Mary Poppins That route didn't last long due to the obvious duplication in the action. It's practically begging you to refactor into something more generic like: RouteTable.Routes.Add(new Route { Url = "Search/[searchCriteria]/[queryText]", Defaults = new { controller="Search" }, RouteHandler = typeof(MvcRouteHandler) }); In this case, searchCriteria can be one of: Title, Artist, Album, Genre, or whatever criteria you wish to search by. I didn't even implement this one because that's where the idea of a fluent URL came in. The new route: RouteTable.Routes.Add(new Route { Url = "FindSongsWhere/[searchCriteria]/Is/[artist]", Defaults = new { controller="Search" }, RouteHandler = typeof(MvcRouteHandler) }); And some sample URLs: localhost/Suvius.Flamingo/FindSongsWhere/Artist/Is/Neil Young  localhost/Suvius.Flamingo/FindSongsWhere/Title/Is/Come Away With Me localhost/Suvius.Flamingo/FindSongsWhere/Genre/Is/Disco Funk localhost/Suvius.Flamingo/FindSongsWhere/Album/Is/William Shatner Sings The Hits I didn't take it any further than that (by, say, parameterizing the /Is/ into options such as /Contains/ or /IsSimilarTo/). I will leave it to someone more practical than I to determine the usefulness of something like this but coming up with it did make me feel ever so giddy that such a thing was even possible. Not that I'd advocate this being the sole interface to your search engine but at the very least, it does lend itself to quick launch tools like Launchy and SlickRun where you can set up parameterized URLs in a more intuitive way. On the downside, it's nigh impossible to use things like Url.Action when you insert random, hard-coded words (like "Is") into the Url for the route. A final important note on the code. It uses Castle Windsor to create the controllers and inject services into them and it uses NHibernate for the data access layer. I remember my first exposure to both of these fairly vividly and if you are not familiar with them, they can be ever so slightly unintuitive. As it is, I'm no NHibernate expert which is why this code took three days to prepare for release. If there is anything about these aspects (or any others) that you need clarification on, please contact me and I'll do my best to edify and elucidate. Kyle the Routed Posted Jan 25 2008, 12:43 PM by Kyle Baley with 4 comment(s) Filed under: ASP.NET MVC, Featured, Presenting

• Link: Top 10 Estimation Best Practices

  Mike Griffiths is a project manager based in Calgary and has an awesome blog on agile project management. I admit I don't always follow the hard-core estimation planning techniques but yesterday's post on the Top 10 Estimation Best Practices is Gold with a capital Guh. 3. Agree on what “It” and “Done” means – make sure everyone is estimating in the same units (e.g. ideal days), have the same assumptions, and are based on standard developer ability/effort. When asking for estimates spell out what you are asking them to estimate. What does “Done” include? Coded, unit tested? How about integrated and system tested? What about refactoring contingencies? User meeting time? 10. Review, Revisit, Remove head from sand, Repeat – Our first estimates will likely be our worst. Don’t leave it there; review the project velocities to see how fast we are really going. Revisit the estimates armed with the real velocities to determine likely end dates. Embrace the reality you see, “The map is not the territory”, reprioritize and repeat the estimation process often to adapt and iterate to the most accurate estimates It was originally titled the Top 10 Agile Estimation Best Practices but someone correctly pointed out that they applied to any estimation planning. He has it available in handy PDF format and he's too polite to say it so I'll voice the implication: Put it up on the wall over top of the picture of your kids and read it every day! Y'know, if you want to. Kyle the Best Practiced Posted Jan 18 2008, 09:39 AM by Kyle Baley with 3 comment(s) Filed under: Estimating

• Arial vs. Helvetica: The Smackdown

  This is a bit of a departure but what is a blog if not a dumping ground for random thoughts? This isn't really the point of this post but I've never liked Arial. It's too "squished" for my tastes. I prefer the wider letters of Verdana or Tahoma. But my current favorite font is Century Gothic with it's big round letters that harken back to when I first learned how to print. I was reading over Jeff Atwoods latest post which discusses, in part, the Helvetica font. I following the links to its relationship with Arial and finally, How to Spot Arial. I've never considered the difference 'twixt Helvetica and Arial before so I did a little experiment in Microsoft Word 2003 and Windows XP. The results are in the image below (click for larger version): Here's your quiz. Comparing with the notes in How to Spot Arial, which block of text above is Arial and which is Helvetica? And once you answer that question, here's a follow-up: What gives? Kyle the Rhetorical Posted Jan 17 2008, 09:46 AM by Kyle Baley with 15 comment(s) Filed under: Sundry

• NHibernate and ASP.NET MVC

  Am playing with ASP.NET MVC these days in preparation for a couple o' presentations on it. Jeffrey Palermo's CodeCampServer sample app has proven invaluable in this regard even if I have become overly cognizant that I'm ripping off his ideas. In my own version, I'm also referencing NHibernate in my data access layer and whenever I do that, I always forget which assemblies it requires to tag along with it. In my sample, I brought over NHibernate.dll, Iesi.Collections.dll, and log4net.dll into my lib folder and added the reference to NHibernate.dll from the project. Wired up all my repositories, hooked in the IoC container (in this case, Windsor) and loaded the page: Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information. Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code. Exception Details: System.Reflection.ReflectionTypeLoadException: Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information. Not overly helpful and although my lead-up to this has made it painfully obvious, let me tell you when you've also added the IoC container and three other layers 'twixt the UI and the DataAccess layer, 'tweren't altogether clear just what was causing this problem. In fact, even when I reverted all the code in the control back to use the simplest possible controller action, I still got this error. The reason being: I still had the reference to the DataAccess project as well as the references to its classes in the Windsor container. Which means it was still trying to load NHibernate. And NHibernate (or at least the version of it I have) requires, along with the other assemblies mentioned above, a reference to Castle.DynamicProxy.dll. So I dropped the assembly into the lib folder and it came along for the ride the next time I compiled. Problem solved. Reminder stored. Kyle the Proxied Posted Jan 16 2008, 07:07 PM by Kyle Baley with 4 comment(s) Filed under: ASP.NET MVC, NHibernate

• Upcoming speaking engagements

  Floridians beware! The Hillbilly descends on your fair state in the next few weeks: FlaDotNet - West Palm Beach, January 22, 2008   6:30pm Introducing MVC in .NET OnLoad, OnPreRender, OnRender, OnInit. Traditional web forms development makes it sound like you're some crazed Santa Claus born from the imagination of Tim Burton. But it doesn't have to be that way. In this session, Kyle will free you from the shackles of the ASP.NET event model and show you a shiny, happy world. A world where web developers write application code, not plumbing. A world where "ViewState" is the eighth word you can't say on television. Such a world does exist. And Kyle can take you there with the help of Microsoft's shiny, new implementation of Model-View-Controller. And you will see a place where the air is clean, easily maintained, and testable.   South Florida Code Camp - Miramar, February 2, 2008    7:30am - 5:45pm Not one, not two, but THREE doses of the Hillbilly: Introduction to TDD, Mocking, and Dependency Injection I know, I know, why would we need TDD? It’s not like requirements ever change, right? Users are always crystal clear when describing them and once they’re written down, everyone *knows* they’re set in stone. So this session will be more of an academic exercise for those purely hypothetical situations where, say, your client claims he “forgot” about a key feature one week before delivery and that it “absolutely has to” be in the application and, wouldn’t you know it, it’s going to touch every single layer of the application. Crazy talk, maybe. But indulge a budding theorist and join me for a demonstration of TDD in action and how it allows you to wholesale replace entire sections of your application with confidence. Along the way, we’ll discuss how you can test components entirely in isolation from each other through the power of mocking and dependency injection. ASP.NET MVC and AJAX No abstract for this one because I was originally going to re-hash my Introducing MVC in .NET presentation before David Hayden decided he wanted me to work for my money. But unlike Justice Gray, I'm folding like a new shirt and tweaking my presentation. Brownfield Software Development: Inheriting Code What a mess this code is! If only the mucky-mucks would let me rewrite it from scratch. (I’d *never* make the same mistakes the previous team did.) But alas, I’m stuck adding features and making bug fixes to this convoluted codebase that has no unit tests, has no CI process, and is not even completely in the source code repository. And I’m scared to make changes because the first time I tried, some users couldn’t log in, the app crashed for others, and for one unfortunate person, a big gaping hole opened up under his desk when he tried to enter an order. In this session, we’ll take an existing application and move it to a state where we can make changes with confidence. We’ll implement a continuous integration process and start you on the addictive road to refactoring. And once you get your first hit, you’ll never start a greenfield application from scratch again.   I'm rather excited about the last one even if it seems the least sexy of the topics. I think it has the most potential to help people in the NOW instead of some hypothetical future. Kyle the Re-presented Posted Jan 15 2008, 01:02 PM by Kyle Baley with 3 comment(s) Filed under: TDD, ASP.NET MVC, Brownfield, Mocking, Presenting

• Why not remote developers?

  In my previous post whereby I lament the lack of companies willing to offer remote work, I wanted to touch on some of the arguments against using remote workers (and remote developers in particular) but felt it deserved a post on its own. And as luck would have it, half the post has been written already in the comments to the last one. Jimmy Bogard has one that I couldn't have planted any better if I tried: "Remote team members that aren't in the same time zone +/- 1 hour, are very difficult to work with. [...] Even with remote team members in a close time zone, we noticed that 1) they missed out on important human conversations that led to 2) them not really being part of the team.  We kinda strive for the XP-style Whole Team, which can be very difficult to make work with remotely." You may not believe me but these were the exact same three points I was planning to bring up anyway in this post, even without Jimmy's fine segue. His sentiments are echoed by other comments, many of which point out correctly that agile requires a lot of face time. Yes, there are some obvious and no so obvious challenges on both sides when dealing with a remote worker. From experience, I can tell you that you can manage reasonably well with a time zone difference of +/- two hours but the fact remains, time zones must be taken into account. If you're on the east coast of North America an d have a regular 8:00am stand-up, your Vancouver-based developer had best be an early riser. Several people brought up what I find is one of the biggest disadvantages to not being onsite: the hallway conversation. I know I've said this before somewhere but you would be amazed at how many major decisions are made at the coffee machine. Design, architecture, new features, it doesn't matter. Never forget: Humans have far more experience with the verbal word than the written one. As was also pointed out, this is more pronounced in agile environments, where face-to-face communication is built-in to the process. Daily stand-ups around a scrum wall filled with post-it notes does not lend itself to remote developers. And no matter what technology solution you use to mimic it, there will always be a disconnect. Unfortunately for me and remote workers in general, what these add up to is that it's  probably not practical in an agile environment to have more than one or two remote developers. There is simply too much focus on direct communication among the team that no amount of IM, e-mail, or internet telephony can overcome. But I would absolutely *lust* after whomever is able to prove me wrong. None of these even take into account the most important factor: the skillz and personality of the actual developer under consideration. Interestingly, only Dave Woods mentioned this in his comment, almost as a footnote. Not everyone is capable of working remotely so this is something employers need to determine as part of the interview process, as if it wasn't difficult enough. Not to mention the fact that you are likely interviewing the person over the phone. In the end, these are concerns that, like any other, need to be weighed against potential benefits. It's likely that these issues are so esoteric that most managers simply don't want to deal with them. They can deal with a shortage of good local help by commiserating with other managers who are in the same boat. It's a well-understood and widely-accepted problem and when you complain about it, people nod knowingly and say, "Yeah, tell me about it." But if someone were to say, "I can't believe I have to schedule our meetings before 3:00 because of this guy we have working from the Bahamas", you had *better* be productive. Kyle the Lamented Posted Jan 14 2008, 09:28 AM by Kyle Baley with 9 comment(s) Filed under: Working Remotely

• Fighting the remote mindset

  I've had not one, but two people say something along these lines to me in the last twenty-four hours: The promise of the 90s of all work being done remotely didn't really come to pass. One of those people, Casey Charlton, explains further in an e-mail: "the reality is I would probably get none [remote contracts] - even for clients I have worked for a few times and implicitly trust me and need my skill level" And the following frustratingly contradictory remark later on: "In the UK where petrol is extortionately expensive, cars are massively overpriced, and public transport is a very expensive joke, there isn't any perceptible move towards [remote contracts]. [...] Most of the time they would rather have someone with half the skill who would be in the office." I've come across the same mindset in North America and as someone who prides himself in delivering efficiency in software, it's maddening knowing that efficiencies can be gained just in the logistics. Casey mentions some benefits for the people who work remotely but there are measurable benefits for the employers as well. No need for office space is an obvious one. Most of the time, they don't need to provide a phone or a computer (except when you have to VPN in, connect to Citrix, then Terminal Service into a box in the office). Plus, I would happily compare my productivity both locally and remotely when you factor in interruptions (for example, I don't hold fire drills at home nearly as often as the average office building) and the fact that, since I don't work in the downtown core, I'm generally more efficient about scheduling time to run errands (i.e. I don't). And yet, still this stigma exists that people who work remotely aren't as productive as their local counterparts. I would love to see some empirical evidence to study this because I can't imagine my personal experience is that different than the norm. To me, the rationale behind the practice is the same as the one that leads to WebSense (sidenote: the Hillbilly's old home was deemed inappropriate at my last POB) and companies monitoring employees' IM and internet usage. And as I lamented in a previous post on that subject, it gives the impression that companies simply do not trust their hiring process. It's an easy trap to fall into, particularly in my case because not only do I live in the caribbean but I have a nasty habit of assuming people have a sense of humour when I say things like, "I can't check in just yet, I got sand all over my keyboard." People don't like to feel like they're being taken advantage of. But the thing is: I have tasks to complete just like anyone else. My work is available for scrutiny at any time. I'm held to the exact same schedule as the rest of the team. If I'm not pulling my weight, I expect to be canned plain and simple. And absolutely none of that is any different whether you work in the office, at your home in the suburbs, or across two time zones. I have been lucky enough to work at three contracts where I performed all, or at least the bulk of the work from home. In every case, my performance was the same or better than it was when I worked onsite. And as far as I know, the clients were happy with the quality of my work and two of them have expressed an interest in working with me again. In fact, in early talks with a someone to follow-up on one of them on another project, I asked if it would be okay for me to visit my family in Canada on occasion and do my work from there. His response: "You can do the work from Mars for all I care. You know what needs to be done." Another part of the mentality is that there's a general sense that it would be difficult to manage remote workers logistically. It's a problem people just don't want to have to deal with. "Oh, this guy wants to work remotely? Well, we're not set up for that, let's just find someone locally" and they don't even bother taking a look. There is a bit of truth to that but in this day and age, any such difficulties are easily overcome. Especially if you are dealing with someone who has done it before. Still, there is a bit of truth to that argument. It's just one more thing that might go wrong so it's best just to go with someone where you have more control over their internet connection during work hours. But the fact remains, there are concrete cost savings to be had with the practise. It baffles me why people aren't willing to at least consider it on a larger scale than they have. Kyle the Lackadaisical Posted Jan 12 2008, 11:05 AM by Kyle Baley with 13 comment(s) Filed under: Working Remotely

• AutoMockingContainer and ASP.NET MVC: Round 1

  I resolved to pace myself a little better in '08 on this blog. But then, I also resolved not to keep any of my resolutions. Mostly because I like the circular reference. I'm delving a little more deeply into the ASP.NET MVC framework these days in preparation for a couple of upcoming presentations. And I've really liked using Jacob Llewallen's AutoMockingContainer in other projects so naturally, I wanted to take that into MVC and use it to create my controllers: controller = container.Create<SongControllerTester>( mocks ); (NOTE: I'm using the Test Specific Subclasses espoused in Phil Haack's post on the subject but it doesn't matter if you use the subclasses or the actual base controllers.) This fails with the error: MissingMethodException: Can't find a constructor with matching arguments. Luckily, the AutoMockingContainer's source is available. Even more luckily, so is Windsor's. So after some digging, here is what appears to be happening: When the AutoMockingContainer attempts to create SongControllerTester class, it adds the class's type to its own internal Windsor container. It then attempts to resolve that type, thus retrieving an instance of the object from the container. During that retrieval process, Windsor loops through the object's properties and tries to resolve the ones that it can (for the properties that are objects). Typically, they can't be resolved unless they've also been added to the container. But the cool thing about the AutoMockingContainer is that it wires itself into this process and will create dynamic mocks for the objects that represent these properties. However, these objects must have a default constructor. The MVC Controller object has a ControllerContext property and the ControllerContext object does not have a default constructor. Hence, no dynamic mock for it. And unfortunately, I haven't found a way around this yet. Marking ControllerContext as non-dynamic, stubbed, or non-mocked won't work, nor am I able to get the AutoMockingContainer to create an instance of ControllerContext (there is no setter on its Controller property). So in lieu of the amount of time I've already spent looking into this, I'll have to switch to more traditional methods of creating my controllers and mocking their dependencies. Kyle the Mockable Posted Jan 10 2008, 08:53 AM by Kyle Baley with 6 comment(s) Filed under: ASP.NET MVC, Mocking

• BDD-style specification reporting in CC.Net

  Shortly before I was given the free time I so dearly craved in such a Twilight Zone-esque manner, we had implemented Ryan LaNeve's fancy XSL technique for reporting BDD-style specifications from CC.NET. It gives some neat little feedback for your tests and even works reasonably well for more traditionally-named tests. And the XSL itself is very neatly laid out and easy to follow. A couple of notes on it that may not be obvious from the post: The XSL stylesheet adds a "success" or "failure" class to the test names. So if you load it up and don't immediately see green test names, add CSS rules for those two class names. And try to be more creative than: color:red; font-weight: bold. As a general rule, you can never use too much cyan. By default, the XSL will strip out spaces from the test as well as any leading .BaseSetUp. and trailing .TearDown text from the test names. This works if your setup and teardown methods are so named. If not, you'll need to make appropriate changes. A note about the second point: XSL is case-sensitive. So if you tell the stylesheet to strip TearDown, that's all it will strip. Any teardown methods named Teardown or teardown will still appear. And while XSL 2.0 does offer the ability to do case-insensitive search and replace, to the best of my knowledge, neither Firefox nor IE support it. So you are stuck either with funky templates using translate, or, and this probably more practical, adding checks for all variations of TearDown and SetUp used in your codebase. Or you could just be consistent with your naming standards. Kyle the Optional Posted Jan 09 2008, 04:20 PM by Kyle Baley with 1 comment(s) Filed under: BDD, Continuous Integration

• Goodwill and Career Security

  Suppose I should have waited before pimping myself out yesterday because there actually is a decent post in this. And one that wouldn't have required me to walk that awkward line 'twixt soliciting the readers and trying not to appear desperate. Sometimes self-awareness isn't all it's cracked up to be. As it turns out, the Hillbilly was part of a healthy purge at the IS department of his most recent Past Experience entry. They are ten-less strong today than they were yesterday. That includes someone who was going to be leaving in three days anyway which makes me wonder how much value the company places on goodwill. And goodwill will be one of the topics of the day. A good chunk of yesterday's biopsy were employees. And did you know that in Alberta, employees that have worked 'twixt three and twenty-four months are entitled to a grand total of one weeks' notice. Or pay in lieu of. Here's where the goodwill comes in. One of the victims told me that little tidbit. And as a general rule, when your recently laid-off employees are looking up labour laws right afterward, you probably haven't handled things in the best possible way. As a contractor, I got nothing and I'm fine with that. It's in my contract so there's hardly anyone I can blame. I was hoping my VPN access would have lasted long enough after the "can we chat" conversation to at least check in the test I was working on but that's the nature of most companies. Granting access requires three signatures and just as many weeks. Revoking it requires a phone call and it's done before you hear the dial tone. Justice has a good post on job security vs. career security (which is not the same as employee vs. contractor). Yesterday was a textbook proof of his theory that job security is a myth. There are some interesting comments in the post (and then there are the ones talking about the Mad Mexican rolling over for Sam Gentile). I particularly like Bil's comment that, whether employee or contractor, you have to be prepared for just the scenario described here. As I mentioned yesterday, I'm cautiously optimistic about my own future. Such is my nature in general but in this instance, it's backed up a little by confidence but mostly with past experience when looking for jobs. (Man, I wish I was that subtle yesterday.) That's because I'm secure in my career, not in my job. Yes, it may not play out the way I want it to but my worst-case scenario, which I will leave to your fertile imaginations, is still pretty good. And there are worse fates than being unemployed in the Bahamas. Kyle the Silver-Lined Posted Jan 08 2008, 09:22 AM by Kyle Baley with no comments Filed under: Career

• A Hillbilly on the Prowl

  In another lifetime/blog, I did a little mini-series on working remotely. It started with some tips on landing remote contracts and it's time to practice what I preach after being unceremoniously thrown to the wolves today. Something about budgets or not wearing pants during videoconferences or some dang thing. I half-considered not going quietly but it's hard to appear menacing when you can be silenced by a dial tone. Let it not be said there are no downsides to working remotely. So not the ideal place to be three weeks before one's birthday but hillbillies are optimistic by nature and I'm not cancelling my plans to go to DevTeach just yet. And to make this post not *too* obvious that I'm soliciting my readership, I'll toss out some generic advice on the benefits of optimism, patience, and integrity in the face of opposing forces who smell badly and probably still wet their beds. Here goes... Optimism, patience, and integrity are good. I'll end now because frankly, I'm kind of forcing it at this point. But still: tell your friends. Kyle the Blatant Posted Jan 07 2008, 09:29 PM by Kyle Baley with 2 comment(s) Filed under: Working Remotely