CodeBetter.Com
CodeBetter.Com
RSS 2.0 via Feedburner
           Do you Twitter? Follow us @CodeBetter

Kyle Baley - The Coding Hillbilly

"We are stuck with technology when what we really want is just stuff that works" -- Douglas Adams

February 2008 - Posts

  • Getting ASP.NET MVC to do the dirty work

    Hey, whaddaya know! I have some actual feedback to give on something in the form of "boy, I wish the product could do X". Who knew I had evaluation skillz?

    The product is ASP.NET MVC and I'm implementing some pretty standard functionality: Get the data from the user and save it in the database. For this post, we'll call the object being saved a Critter.

    One of the properties on a Critter is Species and its value is selected from a dropdown list. This is not such a far cry from Scott Guthrie's equally descriptive Product/Category example which is an okay example if you're looking only for education and not entertainment.

    Like Scott's version, I'm passing what amounts to a DTO as the ViewData. The DTO includes a list of Species to select from as well as the actual Critter object. You fill in the name of the critter, select your species, and click Save and watch the magic happen in the form of saving the Critter to the database.

    Now, according to the tutorial, there are two ways to create your Critter object in the Create action. The first way is to specify a method parameter for each property. For example:

    [ControllerAction]
    public void Create( string CritterName, int SpeciesID )
    {
        Critter critter = new Critter( );
        critter.Name = CritterName;
        critter.SpeciesID = SpeciesID;
        // Do "stuff" with the critter
    }

    The second way is shorter and possibly cleaner:

    [ControllerAction]
    public void Create( )
    {
        Critter critter = new Critter( );
        critter.UpdateFrom( Request.Form );
        // Do "stuff" with the critter
    }

    This one is kinda cool if a little too magic. Updating from a NameValueCollection sounds like it might be fragile but they seem to have a good collective head on their shoulders so that might not be a concern.

    Here's where my wish list comes in. Neither of these methods are how I would code the thing if I were doing it in, say, a Windows app. Ideally, I'd like to be able to do this:

    [ControllerAction]
    public void Create( ICritter critter )
    {
        // Do "stuff" with the critter
    }

    That is, I'd like the framework to create my critter for me. It can do this for primitive types but not so much with objects. Admittedly, this is probably a tall order without getting back into a ViewState state of being but a hillbilly can dream, can't he?

    Kyle the Utopian

  • The Bahamas .NET User Group

    OK, I've already given away the ending so I'll skip the build-up. But to set the stage for the official announcement, I'll direct your attention to the pictures adorningThank goodness for neighbours with no sense of wireless security this post. They represent two of the workspaces I frequent, both in my condo complex. All pictures are clickable for larger, more enviable versions. I could try to justify why I'm putting them up with some sort of ergonomic crap but really, I'm just gloating.

    The formal announcement: The Bahamas .NET User Group is up and, quite possibly, running. With little more than a half-baked plan and a dream (but still no location for the first meeting). The inaugural meeting is April 30 and the topic is Software Development in the Bahamas. It will be a round-table discussion, very likely done in fishbowl style because I predict a lot of opinions on the subject.

    Many thanks to all who listened to me babble on it to date and those who showed enough enthusiasm to convince me that this might actually work. And to those who critiqued the various incarnations of the websites. These include: Donald Belcham (head of www.edmug.net), Derik Whittaker, Josh Schwartzberg, Dave Noderer (of www.fladotnet.com fame), and Morgan Baker of INETA.

    Because the version you see before you is actually version 3.0. Version 1.0 was a DotNetNuke site that didn't last long after I received some advice from someone who has had to deal with it on a regular basis. I'd reprint it but I don't want to offend my younger readers. Besides, I'm not sure I could spell some of the profanity he used.

    Version 2.0 was SharePoint-based. Specifically, it was the Community Kit for SharePoint: User Group Edition template (more commonly known as CKS:UGE, which, and I'm sure this is a coincidence, is oThey really need to invent a screen that works in natural lightne letter away from containing all letters from the word "suckage").

    This version actually lasted over a week. I even upgraded my server's RAM at GoDaddy to accommodate the slight increase in requirements that SharePoint needs in order to run. (Actually, to be fair to SharePoint, it ran fine on the box. It was every other web application that went on strike in a show of solidarity against the invading new kid.)

    So I configured SharePoint (on the advice of my psychiatrist, I shan't elaborate) and figured out how to install the CKS:UGE template. It doesn't quite work out of the box but there are pretty detailed instructions on what to do to remedy that. Kudos where they're due, they have done a good job in helping user group leaders get a demo site going from which you can steal ideas.

    But there were a fair share of minor annoyances with the templaWish the wireless worked out herete. You can follow along with my discussion of them with their demo site. Firstly is the usability of the design. There is way too much wasted space at the top which means users need to scroll down to see what is likely going to be the most commonly consumed piece of information: the next meeting. On my display resolution of 1440x900, the main content of the page starts just shy of halfway down the page. Everything above that is noise to me.

    Also on my display resolution, the Events Calendar section has only enough space to display the title of the event in the bottom right corner (depending on the size of the announcements). In my opinion, this should be the most prominent thing on the site, along with the Welcome message. It shouldn't be relegated to the galleys right above the sponsors that nobody clicks on. Yes, users can subscribe to events with RSS but for those that don't and just want to whip the site up for a quick check (possibly in a mobile device), don't make 'em look for what they need.

    Next issue: The left sidebar. The links here are mostly redundant so I wanted to ditch the thing and reclaim that space. No such luck. I don't think anyway. I can hide it but then it still takes up space. At least it did when I was logged in as an admin because it displayed the Recycle Bin. Looking at the demo, it doesn't display a Recycle Bin so perhaps it actually does go away when you are logged in anonymously.

    Final problem is how users sign up. They do it by completing a survey. Which means that for me to see the membership, I need to sign in and navigate to the results of that survey and click on each one individually so see the details. Or export it to Excel. Neither option makes it easy for me to grab a quick list of current membership.

    These little nitpicks, coupled with the fact that I needWatch out for sand-kicking bullies! only three of the forty features it offers, led me down the custom app route. The three features I wanted for the initial launch:

    • Ability to sign up
    • Ability to display the next event
    • Ability to display list of sponsors

    That about covers it. Don't need discussion lists, wiki pages, photos, or even a past events page. In fact, for the amount I'll be updating this site, I have serious doubts as to whether I even need to make the events list dynamic at all. I am a software developer after all. How hard is it to cut and paste HTML?

    Elapsed time to implement the current incarnation of the site: 1 day (thanks in part to the fine folks at www.oswd.org for their free web templatSucks I can't share this experience with anyone...es). This includes a sign up process that writes to a .CSV file and sends an e-mail to me when new members join. Which is about as dynamic as it gets down here.

    So if you're in the Bahamas and have nothing else to do on April 30, consider joining us at a yet-to-be-determined location. I'm trying to decide between holding it at the local college or commandeering someone's yacht.

    Now to work on my plan for a CodeCamp every week from November through the end of April.

    Kyle the Ambitious

  • If it feels good, do it

    When my daughter was born, and even during the nine months leading up to it, my wife and I read a *LOT* of books. On pregnancy, on child rearing, on labour, on how to cryogenically freeze the blood from the umbilical cord.

    But when it came down to the really hard questions, I did what almost every new parent does: I called an expert I trusted. I.E. My mother. See, books can take imageyou only so far when you're learning. Yes, they're important to get a general sense of things but nothing beats a proven expert's opinion and, even better, good old-fashioned experience.

    I remember a conversation I had with said expert. At the time, I was asking about some stupid little thing that new parents worry about. After she calmed my worries, I asked my mother: How do you deal with all the conflicting advice you get from people and books and magazines?

    She said: Do what you think is right, then find a book that says you did the right thing if it'll make you feel better.

    Now, eight years after the birth, I'm a little more seasoned as a parent. I've gained some experience and can handle most anything she throws at me (though she still surprises me). There are more than a few cases when I'll consult with peers on things like study habits, social skills, symptoms for illnesses, but for the most part, I leave it up to an intuition that has been honed over the years.

    It's about time to bring this back to software development and hopefully, you'll see the parallels. If not, well, they can't all be gold.

    I'm not suggesting you call your (or my) mother the next time you need to figure out how to resolve a dependency. But chances are, you have a network of peers and experts (sometimes the same people, sometimes not) that you turn to when you have questions or just want to discuss software in general.

    That, coupled with the aforementioned old-fashioned experience, is how I become a better software developer/parent. Books and articles and blogs and even discussion groups are good for giving you a sense of what's good and bad. But if you're faced with a situation you've never seen before, or if you've done the "right thing" and are feeling something's off, it's time to break out the free will, baby.

    This is important for people who are just starting out in software development or even in an area of it they haven't much experience in. It can be overwhelming trying to figure out what the "right thing" is. Or worse, you get into a situation where the "right thing" doesn't actually apply to your scenario specifically and you start fretting about whether you should deviate.

    I've been putting "right thing" in quotes because, well, you can't see me making quote-y motions with my hands a la Dr. Evil. But rest assured, I'm making them. And the reason is that the "right thing" differs from one situation to the next and, more importantly, from one person to the next. All it takes is one look through the altdotnet discussion list to find an example. Even given the exact same conditions, one person's preference may not match another's. And both may be equally valid.

    So if you'll feel better having a second aggregate root in your domain, by all means do it. But make sure it isn't simply a quick fix so you can go home. Maybe a single aggregate, lazy loading, and a unit of work will solve your problem. But then again, maybe it won't.

    In the end, a little confidence goes a long way. You're smart people. Like the title says, if it feels good, do it. But make sure you are always questioning what feels good.

    Kyle the Enlightened

    Posted Feb 19 2008, 04:41 PM by Kyle Baley with 1 comment(s)
    Filed under:
  • Solution folders

    So what's your collective take on solution folders with Visual Studio?

    For the longest time, I didn't pay them no never mind. Then there was a brief period when I had an intense love affair with them. Everything went into my solution. Third-party libraries, testing tools, documentation, damning evidence that other members of the team were plotting to beat me up and steal my lunch money. At my last contract, even the projects were organized within solution folders and when I first saw that, I nodded approvingly to myself.

    The rationale was that if it was in the solution, I didn't need to leave Visual Studio to deal with source control. It was safe in Visual Studio. It gave me comfort. Even joy. Windows Explorer was a scary place and this TortoiseSVN/Explorer integration wackiness was just plain FREAKY FRIDAY! Better to stay in my happy place.

    Then I noticed cracks in the veneer. I couldn't add a physical folder to a solution folder and have it magically add all the files within it to my solution. I felt a slight twinge of annoyance at having to navigate an extra layer to get to the project I wanted. And at the risk of being called a "slave to my tools" (which is a funny accusation at the best of times, unless the accusers writes code in Notepad and compiles from the command line with csc), I do enjoy the Collapse All Projects feature of Gaston Milano's CoolCommands, which didn't work as nicely with that extra layer.

    So now I find myself back to having all my projects at the top level and using solution folders sparingly for things like batch files, build files, and readme files. I ventured out of my comfort zone in Visual Studio and learned to deal with third party library folders and tool folders externally. And really, it only took one time re-creating the full NAnt folder structure in solution folder format to make me drop the practice.

    How about you? What do you store in solution folders? Do you maintain a project hierarchy in them? Use them for any non-code-type files? Love them long time or hate them with a Charles Bronson-like vengeance?

    Kyle the Solvable

  • AutoMockingContainer and ASP.NET MVC: Round 2

    Many thanks to honorary hillbilly, Aaron Jensen for both nudging me into helping out when I lamented on the AutoMockingContainer/ASP.NET MVC combination and for helping me through my first official patch submission to an open source project. He was very gracious with my lapse in matching formatting and spacing standards.

    The end result is that you (and, more importantly, I) can now use the AutoMockingContainer to create controllers in ASP.NET MVC. Whether or not you think that's a good thing, I'm feeling mighty proud of myself either way.

    The issue previously was that when the container tried to create the controller, the default behaviour was to create dynamic mocks for any properties it could. Controllers have two properties, ControllerContext and TempData, that can't be mocked without help, primarily because they don't have default constructors.

    The fix was trivial in the way that Ayende would say something was trivial. That is, it wasn't trivial for me at all but it sure looks like it was in the finished code.

    By default, Windsor will try to instantiate an object using the DefaultComponentActivator. One of the methods it calls is SetupProperties which, as one might expect, loops through the object's properties and resolves any that it can. And the AutoMockingContainer assumes that it can resolve any and all comers without any outside help.

    The fix was to create a custom component activator that derives from DefaultComponentActivator but that overrides SetupProperties so that it does nothing:

    public class AutoMockingComponentActivator : DefaultComponentActivator
    {
    	public AutoMockingComponentActivator(ComponentModel model, IKernel kernel, ComponentInstanceDelegate onCreation,
    			  ComponentInstanceDelegate onDestruction)
    		: base(model, kernel, onCreation, onDestruction)
    	{
    	}
    
    	protected override void SetUpProperties(object instance, CreationContext context)
    	{
    	}
    }

    Then, thanks to Castle's extensibility, that activator can be wired into the Kernel in the AutoMockingContainer (bolded code is new):

    public void Initialize()
    {
    	Kernel.AddSubSystem(SubSystemConstants.NamingKey,new AutoMockingNamingSubSystem(this));
    	Kernel.AddFacility("AutoMockingFacility", new AutoMockingFacility(this));
    	Kernel.ComponentModelCreated += Kernel_ComponentModelCreated;
    }
    
    void Kernel_ComponentModelCreated(Castle.Core.ComponentModel model)
    {
    	model.CustomComponentActivator = typeof(AutoMockingComponentActivator);
    }

    Retrofit some tests (oops! I mean I wrote those first) and boom-bada-billy-bing, I'm off to the races. At the expense of about four billable hours.

    Kyle the Activated

  • You broke the build!

    Stumbled across this today in my search for build images. Perhaps not as subtle as Bil Simser's broken build handout but I believe people will get the message:

    image

    Don't forget to check out Agnes's friends at www.buildsonmymachine.com and www.wheresthebuild.com.

  • How do you build your application?

    The Hillbilly asks: How do you compile your application in your NAnt script for releases?

    There are many options, you see, even though the <solution> task is no longer one of them. You could use the <msbuild> task to build the solution as it is built in VS (I think; the documentation is a little sketchy on this task if you don't know the inner workings of msbuild). Or you could use the <csc> or <vbc> tasks to compile a group of code files into an assembly (similar to a .csproj or .vbproj file). Or, for the ultimate control, you could use the <exec> task to call out to msbuild.exe, csc.exe, or vbc.exe directly though I couldn't tell you personally what that offers you that the imagecorresponding tasks don't. Future-proofing maybe.

    Usually, for testing purposes at least, this entails using <csc> (or <exec> with csc.exe) to compile all the application code into a single assembly that I can run tests against. It's a practice I learned from JP Boodhoo and I've been happy with the results in the absence of anything better.

    But I don't care much about the unit tests. I'm more interested in your releases. Assuming you've automated them in a NAnt script, how do you build the application in preparation for them?

    Historically, I've usually used the <msbuild>/msbuild.exe scenario mostly because I couldn't wrap my head around writing a bunch of <csc> tasks to compile the code into the same structure I see in Visual Studio. For example, if your solution has a Domain project, a DataAccess project, and a UI project, I would need three <csc> tasks to create the individual assemblies. Or one <msbuild> task running against the solution. My reasoning was that it was the easiest way to build the application the same way I did in Visual Studio, which I assumed was how I wanted to deploy it.

    Then I talked to Donald Belcham.

    Conversations with Donald Belcham are always eye-opening (and I won't expand on that comment this time; happy belated birthday, dude). And during our chat, he admitted to using <csc> to create his releases. I expressed my surprise: "But Iggy, what if your solution has a dozen projects in it? I don't want to deal with the pain of a dozen <csc> tasks in the right order". To which he replied: "Dude, you don't need to deploy the same way you build. The Visual Studio solution is a file management mechanism, not a deployment mechanism." And my mind awakened like it did during my last visit to Brian Head.

    The basic idea Donald described was thus: Just because you build your application one way in Visual Studio during development, doesn't mean you need to build your releases the same way. Especially if you are using NAnt to create your releases because then you can do it however you like.

    And as if my mind wasn't expanded enough, he typically shoots for one assembly per physical location. Not one assembly for the domain, one for the data layer, one for the common utilities, and so on and so forth. One. Total. If I were building a WinForms application with no other physical layers, I'd have one file: MyApp.exe. If it were a WinForms app calling a web service, there would be two assemblies. One for the client and one for the web service (plus corresponding .asmx files).image

    This is the extreme position of course and there are caveats. If the application depends on third-party libraries, naturally we won't bundle those up into the assembly. And if you're using an internal client library that is common to more than one project, you'd treat that as you would any other third-party library and keep them separate. But if your application-specific domain code and data access code sits on the same server, that all gets munged into one assembly regardless of how it is organized in the .sln file. NAnt gives us that flexibility.

    I'm kind of putting Donald out there for potential ridicule so I'll expose myself ever so slightly and admit that I really like this idea. Why *do* we feel we have to ship a dozen assemblies for our application? If something changes in our domain, what difference does it make if we re-deploy MyCompany.MyApp.Domain.dll or MyCompand.MyApp.exe? And in speaking with Donald, he points out that even though we have the flexibility to deploy only parts of an application, rarely do we exercise it. In a typical scenario, new versions and hot fixes are deployed as an "all or nothing" in each physical layer anyway. This matches my experience. Even if nothing changed in certain assemblies, I typically re-deploy everything during an upgrade just to be safe.

    Now, we still need to be practical about it. If the resulting executable is 300Mb, then ISDN line or not, you'll want to break that into something more manageable. But for the average application, one assembly should function just as easily as five, yesno?

    Looking forward to hearing the counter-arguments because I haven't quite thought this through too much except from a maintenance point of view. In particular, are there performance differences with loading several smaller assemblies vs. one "larger" (but still manageable) one? What about issues with unloading an assembly from an application pool in IIS?

    Enquiring minds want to know!

    Kyle the Inquisitive

  • Splitter bars: Not for the farsighted

    I think there are a few "standard" controls that are in serious need of revisiting/refactoring. One of them is the splitter control. Below is an image from Word 2003 with a document on the left and the thesaurus on the right. This is probably more obvious on standard monitors but on my laptop, the space between the dark grey bar and the side window appears almost as a single colour. I've placed red lines around the actual "clickable" area for the splitter.

    image

    Here's another example with a horizontal splitter in Word 2003.

    image

    And yet another, this time in Visual Studio 2008. Note that there is also a darker grey bar outside the red lines but just to add to the confusion, this is not, in fact, clickable.

    image

    I'm still primarily in Windows XP/Office 2003 so maybe this has been addressed in Vista/Office 2007. If not, it needs to be. I've seen other complaints over the years about having to hunt for pixels in order to control the splitter so I don't understand why it is still an issue in 2008. Even the Apple guidelines state that a 1-pixel splitter is the most common. Or maybe it's just my eyesight and motor skills deteriorating.

    The Hillbilly is gettin' too old for this #*%$.

    Kyle the Myopic

    Posted Feb 09 2008, 04:12 PM by Kyle Baley with 2 comment(s)
    Filed under:
  • Presentation tips

    Fresh from my experience at South Florida Code Camp and based entirely on the evaluations I got, we present "Tips for Better Presentations"

    1. Pick up the pace. You only have an hour
    The overwhelming criticism aimed at me was to pick up the pace. Which was an eye-opener as I purposefully kept things slow to avoid what I thought was a common complaint at code camps: he went too fast. In retrospect, I think I underestimated the technical prowess of the crowd. Too fast is probably better than too slow but ideally, you want to move things along without losing the audience. Plus one of the presentations was a shortened version of the two-hour talk I did a week earlier and it was obvious I didn't take the new format into consideration. Point taken. And to answer the comment pleading with organizers to give me a Red Bull before the next presentation: I'll stock up on Earl Grey tea but that's as caffeinated as I get.

    2. Book a warm-up act
    Preferably someone like Sarah Silverman but Veronica Belmont has some good geek cred, too. Barring either of those, there's always the Mad Mexican.

    3. Speak up
    This one surprised me too because I made a conscious effort to be louder as it's always been a failing of mine during presentations, dating as far back as the Slop Tart commercial I did for my elementary school Christmas pageant. Still need some work in this regard apparently.

    4. Strobe lights
    It's not a presentation unless it comes with a seizure warning.

    5. Answer questions when you can but move things along
    Mark Miller did a good job of this in his Science of UI presentation. Give a few seconds for questions at appropriate intervals. But more importantly, recognize when to offline conversations if they break up the talk.

    6. Learn the Macarena
    You'll be glad you did. My laptop crashed twice during the day. And now I'm kicking myself for not having any material to fill that awkward silence while it booted up.

    7. Don't lie in the abstract
    For example, if your presentation is called "Introduction to TDD, Mocking, and Dependency Injection",  don't open with "I'm not sure we'll have time for mocking and dependency injection." You *will* be called out on it. Yes, you may have had grandiose plans when you submitted the abstract but come code camp, you'd better be ready to talk on what you said you would.

    8. Give yourself a soundtrack
    Anyone can tell you to write your tests first. But it won't truly sink in unless you do it to the strains of Neil Diamond singing "Good times NEVER seemed so good". And seriously, the combination of Dean Martin and MVC will have you beating the ladies off with a stick. But be very cautious. It takes a seasoned practitioner to use some songs effectively.

    9. Be entertaining but be natural
    Jeff Atwood's already covered this but it's always relevant. I'm still kinda working on this one. I don't script a lot of jokes into my presentation because I usually can't pull them off and instead, I rely on off-the-cuff remarks that are generally very dry, and very Canadian. The danger is that some people can't tell if you're kidding or boring. Or if you just don't get your own jokes. Plus there's the risk that you actually *are* boring. In which case, you may want to consider substituting your soundtrack with a laugh track.

    10. When in doubt: tearaway pants 
    This was my advice to Justice Gray before his DevTeach talk. Luckily, he already had a pair so there was no out-of-pocket cost for him. The tip works best when combined with tips 4 and 6.

    I've focused on the negative comments here because they're generally the ones that give you ideas on how to improve. Overall though, my results were positive enough to be encouraging but not so positive that I'll do things the same way next time. Thanks to all who responded.

    Kyle the Ameliorated

  • Dust off the credit card

    During my presentations at South Florida Code Camp, some people asked on the tools I was using. I went off on a bit of a tangent on tools in general and cut myself off when it occurred to me, "this is bloggable".

    The theme of that tangent was thus: Don't be afraid of commercial tools. The analogy I made was that carpenters, plumbers, electricians, even hookers all buy there own tools to...ummm....reduce friction. The good ones buy tools that fit their needs, regardless of whether it's top of the line or a fourth generation hand-me-down with a crank on the side.

    At the time I talked about this, I was demonstrating VisualSVN. Which is $50. Translated, that comes out to anywhere between twenty minutes to two hours of billable time, depending on your negotiation skillz. It paid for itself probably around month two. And even if you don't buy that logic, I've bought far less useful stuff for $50 which I will leave to your imagination.

    You knew of course that I'd bring up ReSharper. I won't beat you over the head with the amount of time it's saved me but suffice it to say, it's another favorable purchase on the cost/benefit scale. I didn't get a chance to see Mark Miller's presentation on Code Rush and I haven't tried the product myself but my opinion is, try 'em both and pick one that works for you. Or maybe you try each, put them through their paces, and find that neither adds to your productivity. But try them. And buy them if they are useful.

    In short, don't avoid something just because it costs money. Yes, you can put up two files in Notepad side by side and compare them visually. But isn't your time worth the thirty dollars to get it done that much quicker with BeyondCompare?

    This post brought to you by the creators of SmartFTP and UltraMon.

    Kyle the Pimp

  • Life in the Bahamas

    The topic of this post is pretty much the polar opposite of what I was hoping to achieve when I came to CodeBetter since it is about as technical as your average Teletubby but it's here by popular demand. So if you aren't interested, this will be the last I say on the subject for a bit unless Microsoft decides to open a branch office down the street tomorrow. And it's a long one because I already feel self-conscious about writing one post on the subject so I don't want to break it up into two.

    I'll start off focusing on the negative aspects of the island life because those are what have always kept us on the brink of moving back. And they will do so for you, too, for at least the first year you live here. Especially if you start out with high hopes. But I'll segue into the positives just like I started to do after giving the place a chance.

    First and foremost, safety is a factor. Especially for me growing up in rural Manitoba in a town where the only rule of hide 'n seek was "You can't hide outside the town limits". In the second month we lived here, the babysitters that watched our daughter were robbed at gunpoint in the house they were housesitting while they were watching our daughter. This was in a gated community in the middle of the afternoon with 24-hour security at the gates and security cameras. If you ask me today why we didn't pack up and go home after that, I can make up an answer for you but the fact remains, you have to be conscious of it. Of course, these things happen in any city but it seems more prominent here because it's not a very high population.

    There are multiple ways you can give yourself the illusion of safety, most of which are common sense. This will keep the punks at bay but not anyone who is more determined. Again, just like any other place. Luckily, the punks are usually more common and the more determined people aren't typically that high on the evolutionary chain. But it still factors into your decision-making.

    The next topic is tradespersons. There are very few direct repercussions for plumbers, carpenters, and the like if they come to your house and say, cut through your main water line. There are codes in place but they are not enforced. (By the way, the same goes for drinking and driving laws which I'll leave for you to decide if that's a positive or a negative.)

    So you don't phone someone up in the yellow pages and expect a minimum level of service. Instead, you need to network. Talk with other people about who is good and who isn't. Namedrop those people that recommended the company when you call. Offer the tradesperson a drink when they come. Tip them when they leave (assuming you plan to call them back). Like a good CI process, it's all in the name of reducing future friction.

    Another bee in my bonnet used to be the lack of variety in food and regularly-purchased goods. It's not quite as bad as it was five years ago mostly because the supermarkets have finally started stocking Multi-Grain Cheerios. But I've had to solicit visiting family and friends for things like Ichiban noodles and toilet levers for side-mounted toilets over the years. In short, there ain't no Home Depot or Wal-Mart to "pop out" to.

    Related to that is the cost of living. It's high but in my opinion, not prohibitively so. The reason things cost so much more here is because there are import duties on anything that's imported. And as I've probably mentioned before, EVERYTHING is imported. The import duties are high because it's the main source of income for the government. Because there's no income tax and no sales tax.

    So yes, things cost 30% - 40% more here on average. But by the same token, you don't have to pay 30% - 40% of your wages to the government every month. It doesn't quite balance out because salaries here are lower than their counterparts in North America but that's why you'll want to look for a job working remotely. All in all, whether you consider the cost of living high depends on where you come from.

    Side bar

    I've heard tell that in the eyes of the IRS, once an American, always an American. I.E. You're pretty much taxed for life no matter where you live. Someone will have to verify that for me but if it's true, well, I feel for ya, man.

    Last major sticking point is one where your mileage may vary. That's a lack of easily-accessible activities. If you're in the mood to do something different, you're flying or boating to it. There are times when you just get sick of walking around Atlantis pretending to be a tourist. On the other hand, if you're a beach person, this won't affect you too much. In my experience, though, everyone gets island fever eventually. We get away a few times a year just to get a regular dose of civilization.

    So with all that cathartic negativity out of the way, let's get to the good stuff. And we'll start with the elephant in the room.

    It really is awesome to go rollerblading at six in the morning in the middle of January. That sounds bad for those of you stuck in snow but there's no getting around it. Rounding a corner to be met with the sun coming up over the ocean does not get old. Ever. Ditto for sitting out on the balcony listening to the waves and drinking tea. It took me a long time to realize it, but I will forgive a country a lot of things to be able to do that. That said, I have a tremendous respect for all you people sticking it out in the -40 weather up in western Canada. Brave, brave coders, the lot o' ya.

    Next stop is healthcare. I have absolutely no complaints about it and compared with my experience in Calgary, would recommend it to anyone. I can call my doctor at 8:00 in the morning for an appointment and he'll apologize if he can't see me before 2:00 that afternoon. When my daughter fainted unexpectedly one day while out with my wife, by the time I got to the hospital twenty minutes later, she was already in a room and had had a blood sample taken. Before we left two hours later, she had seen two doctors, had another sample taken, and had an ultrasound. Before the week was done, she had seen her regular doctor, who gave her a thorough exam including some other ultra-sound-ish test, and had received an EEG.

    I have had similar experiences myself, most notably with my hernia operation last year (maybe I should have put a disclaimer at the beginning of this post), which occurred a mere three weeks after diagnosis, and only because the missus was away and I wanted to wait for her to return before I had it for maximum dotage. I've heard horror stories from others but I haven't seen any evidence of it from my end.

    There is a caveat to all this. We pay approximately $600/month for health coverage for a family of three. And when we left the hospital after my daughter's fainting spell, I was extolling the virtues of the healthcare system and my wife just said ominously, "yeah, well money talks". Sounds vaguely capitalistic but hey, we're talking my daughter's health here! Besides which, that's also a nice little example of, shall we say, reducing friction, which is a very effective technique for a variety of purposes over here. But I shan't elaborate.

    Earlier I mentioned a lack of quality tradespeople. The other side of that argument is that when you do find someone you like, you get pretty quick service. Same day most of the time and rarely longer than two or three, unless you're dealing with government-run utilities, in which case the universal "three to six weeks" applies.

    I could go on in both categories but I think that about covers the high points. Plus I have some other topics in the wings that will hopefully bring me more in line with the "Code Better" moniker. The underlying message here is that moving to the Bahamas is not like moving from one city to another in North America where there's always a Starbucks within shouting distance (although there are five on the island). Expect a good dose of culture shock and pack a lot of patience with your sarong.

    But again, don't pack yet. I'm still working on the industry.

    Kyle the Indusrial

  • South Florida CodeCamp Wrap-up

    The company that invents a PDA that mimics the mind of Dave Noderer will have a license to print money based on what I witnessed this past Saturday. The man clearly thinks in terms of some DSL based on tasks and bulleted lists in order to pull together the South Florida Code Camp. Over 600 attendees, twelve tracks, at least three dozen speakers. All executed with the efficiency of a good UI, in that you don't even notice it until you stop to think about it.

    Since I presented for half the allotted time, I didn't get a chance to see too many other presentations. Saw Mark Miller present on the science of good UI, a topic that probably deserves a separate post but I make no promises just yet. In any case, it was entertaining and thought-provoking. Also watched Larry Port talk on CruiseControl and NAnt and got some good tips from him.

    For my part, I'm reasonably happy with how my sessions went though some need more work than others. Had a technical glitch during two of them in the form of a laptop crash that I won't speculate on just yet until I've had a chance to investigate further. Suffice it to say, my plan to screencast my presentations will not come to pass.

    Other than that, if anyone attended any of the sessions, all feedback is welcome. But keep in mind that my psyche is very fragile and that any negative comments will be met with either, "I know you are but what am I?" or "Sticks and stones will break *your* bones..."

    Also inspiring was the reaction I got from the user group community when I spoke of my plan to start a user group in the Bahamas. Hard to say whether it was the humanitarian spirit or the pleas of "For the love of all that is Hillbilly, schedule your code camp in winter!" from attendees visiting from northern parts of the country. I came away encouraged nonetheless.

    Kyle the Camper

More Posts