I’m in the early stages of writing a web app with a friend who has been somewhat on the periphery of ASP.NET MVC. As in, when someone says “let’s build a web app”, he doesn’t automatically reach for the MVC project template as I typically do. Bear in mind, he’s also not a web forms fan either.

Instead, he has a very specific architecture in mind that has taken me some time to come around to. A simplified version of it is thus: there is one web application for the various HTML files (and yes, they will be HTML only) and another for the “services”. The services one will serve up primarily JSON to the client which will interact with it with a very healthy dose of JavaScript. This is one reason we’ve decided on OpenRasta for the services layer.

I’ve deferred to my friend on some of this because I feel like I have too much emotional investment in MVC these days (as you can tell by my tendency to erroneously drop the ASP.NET part of the name). Suffice it to say he’s led development on some major league websites that have more traffic in an hour than I have cycles in my family tree. So I feel confident in his evaluation skillz. He has a more rounded view of the world, partially because of his experience with these websites and partially because he hasn’t been drinking the kool-aid as much as I have for some of this stuff.

One of those areas where he isn’t tightly coupled is with JavaScript libraries. Me, I’m a jQuery guy. Not because I like it better than the other libraries but because it’s the only library I’ve ever used and it hasn’t caused me any pain. He has only a passing knowledge of a few of them and attacked the problem of which one to choose more objectively.

To that end, we’ve settled on MooTools, at least for the time being. The main technical reason for this is because jQuery is getting too popular and we don’t want to be perceived as jumping on the bandwagon. We feel that if it’s good enough for Microsoft to throw its support behind, then we need to look at something else.

I jest, of course. In fact, our research shows it to be faster than jQuery and I have it on pretty good authority it is well-suited if you plan to have a somewhat complicated object model on the client. During my spike, I did find it to be more verbose than jQuery but not prohibitively so.

Another JavaScript library we’re playing with is Embedded JavaScript, which is a view engine for JavaScript. With it, you can define views like so:

<h2><%= petNameForRack %></h2>
<ul>
<% for( var i = 0; i < guns.length; i++ ) { %>
    <li><%= guns[i] %></li>
<% } %>
</ul>

This would be stored in an external file and you render it with some JavaScript like so:

function renderListOfLovers( )
{
    var jsonRequest = new Request.JSON( {
        url: "http://localhost/Services.Web/Lovers",
        method: "get",
        onSuccess: function( gunRackList ) {
            gunRackList.Racks.each( buildItem );
        } ).send( );
}

function buildItem( item )
{
    target = $("destinationDiv"); 
    var div = new Element( "div" );
    var view = "views/MyListOLovers.ejs";  // Contains the view shown above
    new EJS( {url: view} ).update(div, item);
    div.inject(target);
}

That's mostly from memory so don’t be cuttin’ and pastin’ none. In the first function, we call out to our OpenRasta service which is configured to return a list of gun racks as JSON by default. When that call succeeds, it creates a new DIV, renders the view in it, then injects it into into a target container.

All in all, it’s an interesting way of doing things. It’s nice that JSON has become kind of the de facto standard for passing stuff around with the various frameworks because it would be a pain to have to retrieve the list from OpenRasta in one format, convert it to another to work with MooTools, then another to work with EJS.

All of this pretty much worked out of the box, too. The spike involved very little actual troubleshooting. It was mostly getting used to the syntax (e.g. I would have thought the MooTools inject function would act on the target rather than the item being injected).

I also discovered you can throw an instance of a custom MooTools class into a view as well with no further changes required. Maybe that’s obvious if you are intimately aware of how JavaScript handles classes but my own experience has been limited to: new ActiveXObject(“MSXML2.XMLHttp”);

On the EJS side of things, it also comes with a bunch of view helpers which are analogous to the dumping ground that is HTML extension methods with ASP.NET MVC.

One roadblock I’ve hit is that while you have the power of a full-fledged library at your disposal with MooTools, in the EJS views, you are limited to only what it supports between the angle brackets. But as a wise man said: in the end, it’s just JavaScript so you can make it do what you want anyway.

How this will end up playing out when things get hairy is still anyone’s guess. But the pain-free spike has been pretty encouraging so far.

Kyle the Scriptified

There is some discussion on a group about countries and states and cascading and such. Essentially centring around the ideas that: a) not every country has states/provinces/islands/territories, and b) some countries *are* states (e.g. Singapore, which also apparently does triple-duty as a city, who knew?).

As an addendum to that, I would also like to point out that not every country has zip/postal codes either. SO STOP MAKING THE &*%$ THINGS MANDATORY!

In short, if you’re going to list a country as an option, be mindful of its idiosyncrasies.

Kyle the Optional

I don’t own a cell phone but I love me my iTouch (which, in fact, is the missus’ cast-off from when she got an iPhone). Given the amount of time I spend waiting for things to happen, being able to whip the thing out to play with at any ti---actually, I’m gonna stop this analogy and move on…

One of the apps I bought on it was Solebon, which is a list of approximately 6,899 solitaire games by my last count. I had downloaded the free version which had about six games. I liked a couple and had a blast with it. So I figured that would scale if I bought the full version. But these days, I never play the thing.

The reason for that is exactly the reason I bought it: more choices. I thought if I like two games out of six with the free version, then surely I’d like at least ten or so games in the paid version. But whenever I open it up for a “quick” game of something, I’m faced with a screen of thirty odd games to choose from, most of them with cryptic names like “Ambrose” or “Blind Alleys” or “Eight Out”.

There are simply too many to keep track of for me to figure out which ones I might like on a regular basis. And the “random game” feature is only marginally better because I always need to re-read the rules to whatever game I’m playing. In the end, I usually just skip over Solebon and go straight for the stand-alone Cribbage app I also got. Sure it doesn’t show the time at the time and it doesn’t always count points properly. But I don’t have to put any thought into it before I start the game.

This ties back to a project I’m working on, one in which the developers have free reign to decide on which features to include. And as a developer, my naturally tendency is “the more the better”. But as a user, it’s “don’t make me think”. Even during software installations, ninety percent of the time, I select Custom and proceed to accept all the defaults anyway.

Because of this, my teammate and I have been fairly ruthless in deciding on features. Unless it is something that 80% of users can absolutely not do without, it’s on our fictitious “future release” board.

One of the things that has seriously helped us in this regard is Balsamiq. Admittedly, I got a free license for it, but my partner didn’t and he has extolled its virtues on numerous occasions. I suspect we have saved ourselves many thousands of dollars but not working on features that may have seemed like no-brainers until we actually saw them in the context of a screen mock-up. Even something simple like an admin CRUD screen hasn’t gone unscathed. “Do we really need four columns? Will users actually care if they are able to upload a headshot?” BAM! Three days work, gone!

Obviously, this has the advantage of making the product easier to develop (at least in the short-term). But there’s another benefit. No user likes to have features taken away. Even if they are so obscure that only 3% of people use them, those 3% can be pretty vocal when they want to be.

Kyle the Optional

Last week, Derick Bailey announced the FluentNHibernate Contrib project. I have not looked at it but read the post with interest and tucked it away for future reference.

Then, against my better judgment, I looked through the comments. The first one didn’t “disappoint”:

And you're not using Linq To Nh ... why ?

Admittedly, I’m a hopeless optimist. I like the way the world looks through my rose-tinted glasses mostly because it’s been nice to me when I look at it this way.

So I don’t understand the tendency some people have where they seem to relish in knocking someone down a peg or three. All Derick is doing is announcing a project that could potentially help developers. Sir Occo reads this and thinks, “this guy’s wasting his time. And I’m going to tell him about it in the universal language of sarcasm.”

I have no idea if FNH.Contrib is similar to another project. I’m told on Twitter that it is different than Linq to NH. Which is where the danger lies. In all that “holier-than-thou”, there’s a chance that they *aren’t* all that similar. That there are fundamental differences. And more importantly, that Derick has indeed tried Linq to NH and has very good reasons for not using Linq to NH.

But even if he hasn’t, even if the two projects are identical in scope and Derick had no idea of the existence of Linq to NH, what is he supposed to say now? “Thank you for exposing my ignorance, sirocco, and in such a productive fashion, too.” Of course not, the natural reaction is to dig in your heels and start looking for minute differences

To contrast, let’s review comment number three on the same post:

Check out this nhlambdaextensions.googlecode.com/.../NhLambdaExtensions.html

Does something quite similar

Better yet is Neal Blomfield’s comment later on:

Looks a lot like the NH lambda extensions stuff.  Might be worthwhile looking up code.google.com/.../nhlambdaextensions and checkign out broloco.blogspot.com/.../using-lambda-expressions-with.html to see if these guys have some useful things to contribute.

Here, the content is essentially the same (this is similar to another project) but the intent is much different. The Harrisonmeister and Neal bring up alternate projects not to knock the wind out of Derick’s sails, but to see if the two projects can collaborate. Y’know, to make the development community better.

Now, I’ve been known to enjoy the occasional jibe or two and there’s a slight chance some of them may have been in what may be construed by some as a somewhat ironic tone. In more immediate communication methods, like IM or phone or…what’s the other one called, again…oh, yeah!…face-to-face, there are times when I go into a mode as depicted by Dave Foley above. But I try to do so only with a known audience. People that will take it for what it is, good-natured ribbing. Where the :) is implied. But on a blog post for someone I’ve never met in any form, whenever I feel the urge to be snarky, there’s always a voice in the back of my head that tells me to assume the person knows what he or she is doing. So I prefer to choose my comments carefully.

At least for the first one. After that, if you prove my assumption wrong, well, sorry, buddy, you’re fair game.

Kyle the Predatory

Got a question today from someone asking how I managed to achieve the lifestyle I did and asking for tips on having to do the same. In order to impart this wisdom, I am deeming it necessary to brag a little.

As many of you probably know, I live in the Bahamas and work from home. I’ll throw tact out the window and add that my condo is about 100 feet from a private beach and also has a pool and tennis courts. At night, my wife and I sit on the balcony reading to the sound of the ocean. Thanks to a side burner, we barbecue almost everything year-round, even pancakes. When I can get away with it (which is more often you might think, you’d be surprised what you can get away with by asking), I like to work only 3 days a week. Last weekend, my daughter and I jumped into the canal off the ocean with some neighbours’ kids for a while and when that got boring, we played baseball on the beach.

It’s probably a coincidence that I’ve just started reading The 4-Hour Workweek because this kind of sounds like something from the opening chapter. But the difference is: Tim Ferriss put some thought in achieving his lifestyle. As much as I would like to translate my own experience into a multi-million dollar empire, I came by my good fortune mostly by accident.

How it happened

Before moving here, my family and I lived in Calgary and I worked as an employee for a consulting company. My wife works for an international consultant and he decided to move to the Bahamas for whatever reason. We basically came along because he asked us if we wanted to. The decision was harder than you might imagine primarily because our daughter was three at the time and moving her away from family to a country where we knew little about the education system was a big unknown. I was also worried about the work situation.

But we did it and I, of course, had to quit my job. For the next two or three years, my career was very much in flux. I found contracts in the US but they required me to be onsite (i.e. away from my family). A couple of them paid room and board but for the ones that didn't, I had to rent a place on my own and live a college life, except that I couldn't date anyone. For the first two years alone, I was away from home for 13-14 months. I also tried a couple of permanent positions locally but that didn't take very well. I'll leave it at that and just say it'll be a long, long time before I accept a permanent position locally.

Really, it's only been in the last two or three years that I've been able to get some stability in my career to the point where I don't automatically panic when a contract ends. But having said that, it's a *LOT* of work trying to find a contract where they will let you work remotely. Chances are, I'll have to travel for work again in the future. In the meantime, the main reason I started blogging and speaking at user groups and attending conferences was self-serving. I need my name out there so people have at least some idea who they're talking to on the phone in the Bahamas. And even then, they're still leery. I feel like I have to be twice as productive just to prove myself. Which isn't too hard given that at most places, they're half as productive as they could be anyway.

So that was my master plan for living such a life: I said yes. And I don’t mind admitting that those first two or three years were tough and involved a lot of soul searching, to the point where we actually went house-hunting back in Calgary. Maybe it would have been different if we consciously decided to move here and follow our dream. But instead, the opportunity arose and we took it. So anytime something inconvenient happened, it was easy for us to say, “We didn’t have to deal with this back home.” And the fact that we still considered Calgary home at the time did not go unnoticed.

But gradually, we worked out the kinks. We learned the ins and outs of our new home and, most importantly, took stock of what was important. Only after doing that did we really start to realize that we were wasting a whole lot of time and energy on the wrong things. Since then, we’ve re-prioritized to take advantage of what we gained from our move (more sporting climate, proximity to beaches and other islands, more relaxed lifestyle) rather than focusing on what we lost (regular access to Multi-Grain Cheerios).

Planning it out

But that doesn’t mean I don’t have anything useful to say on the subject. I can help to avoid the same pitfalls I ran into. While the first couple of years had their challenges, I suspect people might be underestimating how easy it is to accomplish it. You’d be surprised at what you can accomplish through trial by fire. And if you put more thought and planning into it than we did, it’ll go that much smoother. Besides, it’s not like moving to another country is an irreversible decision (unless you’re dream is to visit the front lines in Iraq).

One of the most important things you will need is a safety net. You don’t want to have to worry about money so as much as you can secure a regular source of it, do it. Make sure you have a good list of contacts for people who could potentially hire you or help you find a job. Like I said, that’s what I went into blogging and community work. And it should be noted that I do love doing it. If you don’t, find another way to get your name out there because you won’t help anyone by faking interest in community work.

Also, start planting the seeds of working remotely now. Work from home a day or two a week if you can and try to increase it. If you can keep your current job when you move, that's gold. We were kind of okay because my wife had a pretty good job but it was a bit of a struggle with me being away all the time while she had to learn the ropes of a new country. Even if you do find a job working remotely, expect to have to leave home for work on occasion. Hopefully, you won't have to but it helps to prepare just in case.

When you do move, scope the place out first. Find expats who can give you the lay of the land for things like finding decent tradespeople. Splurge a little on the place where you’re living. It may be easy to say you’ll just start out in a small apartment next to the main road but you’ll be robbing yourself. What you want is some place where you can kick back at night with a malt-based beverage and say, “Now, THIS is more like it.”

Finally, realize that while your career is important and it's easy to get caught up in it, don't forget the reasons why you move. Even now, I still suffer from “just one more test, honey!” syndrome. Yes, by all means, be dedicated and good at your job and work on OSS projects and that side project that will get you on the cover of Time. But make sure you treat them for what they are: hobbies. You didn’t move to make yourself rich, you moved so you wouldn’t have to make yourself rich.

In short, if you’re already living your dream, don’t waste your time and effort pursuing it.

Kyle the Coached

I struggle with a lot of things. No, no, it’s true. I’m not the infallible coder of the earth that my online persona may have you believe. There are things in this world that I have trouble with. Saran Wrap, for example. It is one of my life goals to be able to tear off a sheet of it without having it stick to itself, forcing me to fiddle with the edges until it’s a mangled ball of cellophane and I have to summon my nine-year-old daughter to tear off another sheet for me. I just don’t have the required food storage skillz. But I’m learning.

Another point of potential improvement is meeting preparation. In my current assignment, we’re test-driving scrum. I’ve worked in a scrum environment before but I came in partway through and the existing team was already long practiced at it and I was able to merge in pretty quickly. In this one, we’re all kind of getting a feel for it.

Part of the process involves meetings. The daily stand-up, of course, but also code reviews, retrospectives, demos, and planning sessions. And I don’t feel like I’m as productive as I should be in them.

The reason for this is that I’m used to meetings being interruptions in my work. The two-hour eye-wateringly detailed recap of the project plan. For these meetings, I’d work until the last possible moment before another conscriptee passed my desk and said, “you coming to the meeting?” at which point I’d lock my computer and saunter into the meeting, usually a few minutes late. And I wouldn’t be the last one in. These are mindless meetings. Ones where you don’t need to put in any thought before, during, or after. You’re there to grease the project manager’s wheels.

But the scrum meetings seem to demand more discipline from their attendees. They don't work as well if everyone walks in with a “switch-on” mentality. That is, they turn their attention to the meeting task as soon as they walk in the door.

Consider a retrospective meeting, where you discuss the good, the bad, and the physically unattractive of the most recent sprint. Very often, the question will come to me, “what was good/bad about the last sprint” and I’ll have to sit and think for a few minutes before coming up with some lame contribution just because I didn’t want to look like an idiot. (“Well, I really liked the colour palette we chose.”) Wouldn’t it have been easier if I did that thinking beforehand so I didn’t waste anyone’s time?

This is even more critical for code reviews and planning sessions. Almost anyone that has attended a code review has had everyone walk in, sit down, and the leader says, “So what do we want to look at today?” Ideas are thrown out, some code is plastered on the page, and everyone looks at it for a few seconds before tossing out ideas off the top of their head.

Ditto for planning sessions. “I’m thinking we should handle the admin screen to add customers?” “Hmmm…that might be a good idea…actually, no wait, we should do the invoice screen first, then we’ll have an idea of what data we need to capture.” “But if we do the invoice screen first, we’ll have to wire in the calculation engine.” And so on and so forth.

This is the type of discussion I think is worth *starting* over e-mail. I.e. An e-mail that says, “The planning session is on Monday, the features under consideration are: 1) admin screen for customers, 2) invoice screen, 3) easter egg page showing the after effects of the company Christmas party. Let me know your thoughts before the meeting.” Then, come Monday, everyone has (presumably) contributed to the discussion, some issues have been brought forth and we’ve got a head start.

For code reviews, it’s the same thing. A generic review where the class-at-hand is decided on the spot leads to developers wondering if they’ll have to end up spending the meeting defending their code. But if the code being reviewed was decided beforehand, he could take a look at it and maybe get a sense of the issues that maybe be brought up. And presumably, the issues that *are* brought up are more substantial than “shouldn’t you have an underscore at the beginning of your variable names, Sparky?”

I’m already doing this in some respect for the daily stand-up. It’s not very mentally demanding because you generally have a good idea what you did the day before and what you plan to do today, but I still go through the mental exercise before the meeting. But that’s because the expectation has been set that everyone should know what to say and get to the point. The same expectation usually isn’t held at the more involved meetings.

The latent English professor in me says that this is an awkward place to end the post but for the life of me, I can’t think of anything else to say. So…ummm…start the discussion before the meeting, I guess is the overall takeaway here.

Kyle the Prepared