Like many people in technology, I have enjoyed my fair share of time playing video games. My particular poison was an MMO, World of Warcraft. My brother played, and my best friend played too – and they both started telling me how great it was. Pretty soon, we were all in my brother’s guild having a great time.
The guild part was key. We had hundreds of people in the guild, and there was always 10-50 of them online, no matter if it was 3PM or 3AM. The guild really defined my enjoyment of the game. Every time I logged in, I might see people online that I liked. They might be people that I could talk about my day with, or talk about music with. Most of the time, it was just talk about the game we were playing. We might work on some game content together, maybe a quest or a dungeon. We had a shared passion. We scheduled times when we would all get together to try to do something in larger groups. We were a casual family guild, so we played every Tuesday and Thursday night usually starting around 9PM. It was a great time – group dynamics, good friends, making jokes on our headsets, taking a video game way too seriously. No, it wasn’t a great time. It was an amazing time.
Of course, as I got married, and my career progressed, I found I naturally had less time for WoW. And, unfortunately, once I couldn’t play enough to “keep up” with the guild, it wasn’t worth it to me anymore, and I stopped altogether. C’est La Vie. I didn’t miss the video game, and I still talk to my WoW buddies on Facebook – but I really missed the camaraderie.
Over the last few years, with some of the free time left over after WoW, I’ve started to spend time in the amazing tech community in Toronto. It started with XP Toronto, a really great group that a co-worker introduced me to. Then I started going to Metro Toronto DNUG. These are large, established tech groups – at first I was thinking of them purely as a recruitment tool to find talented developers and see some great content too. Gradually, however, I began to find the camaraderie I had been missing. I began to seek out more groups. Then I found MeetUp.
MeetUp is this website absolutely filled with little groups. Ruby developer in Toronto? Try Toronto Ruby Brigade. Aspiring Electronic music composer in Edmonton? Electronic Music Producers has a meetup scheduled for March 11th. Crazy about dice games in the suburbs of Kansas City? The Rolling Dots meets soon.
I started drinking from the fire hose, first HTML5 Toronto, then Toronto MongoDB User Group, and even starting one called Toronto Code Retreat with the help of a fellow MongoDB enthusiast and tech entrepreneur. So now, a few times a month, sometimes a few times a week, I meet up in the evening with all sorts of like-minded folks who are passionate about a subject that I am also passionate about. Sometimes in groups of 25-40 with pizza and t-shirts and professional speakers, sometimes its just 5 people, a couch and some folding chairs. And its always worth it. The content is great, the people are amazing. And the camaraderie? Never been better.
- PhoneGap Build is currently touring the podcast circuit, on Hanselminutes, the Tablet Show, and DotNetRocks. It’s not surprising, Adobe’s recent acquisition of Nitobi (which built PhoneGap) is quite newsworthy. But really, it’s not just that – PhoneGap Build is awesome. So what is it? From my research, it basically helps HTML5 / JavaScript developers to build “native” mobile apps. I have native in quotes, as it won’t be the same as developing apps in the main supported environments like Android’s Java SDK or Objective C for iPhone. My understanding of it is that PhoneGap basically uses a native browser component, removes the chrome like the back button and address bar, and loads up your HTML5 site from a file:// URL. Sure, you wouldn’t want to build Angry Birds this way, but then again you also don’t have to start out by learning an entirely new paradigm. All you have to do is upload your HTML5/javascript/css to build.phonegap.com and they produce binaries for iOS, Android, Blackberry, webOS, and Symbian. They even integrate with Github! Tres cool.
- jQuery Mobile – this user interface library is a really great way to get started with developing mobile apps. After fooling around with it this weekend for a couple of hours, I quickly had put together a simple product listing application – you can check it out at www.lcbobuddy.com. You can think of jQuery mobile as some great starter CSS (that works with jQuery theme roller of course!) and a great programming paradigm for developing mobile apps. For instance, there’s a really great single page app concept in it too, complete with some basic routing. The idea goes your html file contains multiple <div> elements with a like this:
<div data-role="page" id="product_listings" >
<div data-role="header"> <h1>Heading</h1>
</div><!-- /header -->
<div data-role="content">
<ul data-role="listview" data-inset="true" data-filter="true" id="listings_listview"></ul>
</div><!-- /content-->
<div data-role="footer"> <h4>Footer</h4>
</div><!-- /footer-->
</div> <!-- /page -->
<div data-role="page" id="product_details" >
<div data-role="header"> <h1>Heading</h1>
</div><!-- /header -->
<div data-role="content">
</div><!-- /content-->
<div data-role="footer"> <h4>Footer</h4>
</div><!-- /footer-->
</div> <!-- /page -->
With this structure in place, you can make links to “#product_details=1234″, and with a simple JavaScript hook you can catch calls to product_details, parse out the specific product ID and pre-load the product data you need to service the request.
- Kendo UI Mobile - Telerik has been hard at work on their KendoUI, an open source JavaScript framework. It’s in beta now, but the mobile stuff looks really promising. I haven’t done any projects with it yet, but Telerik is known for delivering top quality tools.
- Adobe has been investing in HTML5 mobile. Not only did they recently buy Nitobi, but apparently Dreamweaver and Illustrator support mobile development somehow.
I love the phone in many ways. The build quality is very high, the device looks good, the screen is gorgeous, the controls work well, processor feels snappy. All in all, the device has a place in my heart, but I’m just plain missing my iPhone right about now. Here’s the low down!
I’ll start with the good:
- The screen looks beautiful!
- Facebook, MSN and Gmail integration are stunning! Really well done. Contacts, Calendar, email, all synchronize without any weird setup steps.
- The email app, while missing some functions that I’ve come to rely on like thread view, is very very good. The search actually seems to work, the messages are easy to read and navigate.
- The device has horsepower to spare; the processing speed on the majority of tasks is superb.
- The tile updates work really well (when they are working). The commercials are right, I couldn’t live without this now.
- The Zune desktop app is a really fantastic piece of software. It’s made me realize just how bad iTunes is! Zune looks good, is easy to use, and performs very well on my hardware.
- Call quality is great.
- Battery life is astronomical compared to my iPhone 3GS.
As promised, on to the 10 things that bother me the most:
- The device is too big! Sure, it fits in my pocket easily; but I find myself at least a few times a day needing to switch to two hands because I’m finding it hard to type with only one thumb. Keep in mind, at 6’6, I have really big hands and long fingers that can cover a lot of space very quickly – as a developer, I type for a living. This never happened on my iPhone – not in landscape mode or in portrait mode.
- WP7 feels like a time warp sometimes. If the Office app, the People app, the WordPress app make me feel like I’m a character in the Jetsons, the Instant Messenger app, the Facebook app, the Twitter client all feel like I’m in the Flintstones! No Remote Desktop! No Mint! No Skype! No Meebo!
- Mioyoma Messenger crashes half the time I use it at least, and the other half of the time its slow.
- Often I’m finding that the mic stops working and I have to reboot to fix this. Weird.
- The search button is in the way. I keep hitting it when I’m trying to type, especially one handed. See #1.
- No cut and paste! Dying for this.
- The browser is a bit clunky. Going in to landscape mode you no longer have the address bar available to you, sites that are great on iPhone are unusable on WP7 IE8 …
- I don’t like the way selecting text works. You put your thumb down on the screen, and given a moment a selection cursor appears above your thumb.
- The Zune player in the phone doesn’t feel quite right with Podcasts – I find I’m starting them over from the beginning, perhaps on accident, if I don’t use the application just right.
- Not sure I am in love with the way the volume thing works. Is it controlling ringer volume? Phone call volume? MP3 volume? I don’t know!
- You want to keep more of your money
- You “get” that a higher bandwidth line and a lower cap just means you’re going to give it away sooner
- You understand that whether you’re pulling it down at 5 Mb/s or 25, that it’s going to finish before you wake up
- You aren’t foolish enough to confuse latency with speed
- You are sure that they think we’re all pretty dumb with that whole UBB thing
- Telling your friends you have switched to some company they’ve never heard of will make you a hit at parties (OK, only LAN parties)
- Because you have a choice
- Now that you’re uncapped, you can use Netflix and Hulu and probably cut your cable too (we did! ask me how…)
- Because caps are for baseball
- Don’t worry, if you still need to feel fleeced, you’re probably still have cell phone service!
One thing you might notice as you go through the agile process… you can do standup, you can move cards around on a corkboard, you can estimate, do time boxed iterations, milestones… but the User Story is the key to it all.
If you don’t break your software project up in to digestible, well formed pieces, all of the other things are just window dressing.
- When requests pile in to us at various stages of specification, and none of them looks anything like a user story, it takes your BA team and developers a long time to re-distill the requests in to user stories. If you make sure that more and more requests are starting out life as user stories, there is less re-writing. This has a huge impact.
- There is a really great Kanban “cork board” plugin for FogBugz. If you use FogBugz, I think you’ll really like it. Stefan Rusek’s Kanban Board plugin really takes FogBugz to the next level.

More links on Agile and Kanban:
If you’ve reviewed the API’s of different payment processors, you’ve seen that they’re fairly standard, but with lots of little differences. All in all, they’re well formed, easy enough to work with – but some of them are a little dated in their approach. Sometimes, you have to deal with one web service for processing USD, and a completely different one for CAD. Now, they’re not actually all that different in the way they work, they’re nearly identical. Here’s an example… to register a card on an American merchant account you would do this:
USApi.USDataObject data = new USApi.USDataObject();
avs.SetStreetNumber(streetNumber);
avs.SetStreetName(streetName);
avs.SetPostalCode(postalCode);
Whereas if it’s a Canadian merchant account you should do this:
Api.DataObject data = new Api.DataObject();
avs.SetStreetNumber(streetNumber);
avs.SetStreetName(streetName);
avs.SetPostalCode(postalCode);
It’s annoying; you have to write double the code. At first, you might think “dynamic objects”, as they’re perfectly suited to this kind of thing where type safety is kind of getting in the way… but that only works in .NET 4.0. I once proposed a similar problem to Michael, and he suggested the Accessor pattern. We create a new accessor for each data object. The accessors hide the ugly away. A typical accessor for this scenario might look like this:
public class CompletionAccessor
{
private object Obj;
private CompletionAccessor(object capture)
{ }
public static CompletionAccessor GetCompletionInstance(PreAuthAccessor preauth, ProcessorCredentials credentials)
{
object completion = new object();
if ( preauth is USApi.USPreAuth )
{
completion = getUsCompletion( (USApi.USPreAuth)preauth, credentials);
}
else if ( preauth is Api.PreAuth )
{
completion = getCaCompletion( (Api.PreAuth)preauth, credentials);
}
return new CompletionAccessor( completion );
}
private static getUsCompletion(USApi.UsPreAuth preauth, credentials)
{
// set up the US completion request based on the US pre-auth
}
private static getCaCompletion(Api.PreAuth preauth, credentials)
{
// set up the Canadian completion request based on the Canadian pre-auth
}
}
Michael would say “we’re building a facade”. Sounds good to me! The net result is that the business logic code that does things like check the AVS response, check the authorization, save the processor reference, all the little things we have to do to process a payment properly don’t have to be written twice, even if the code that deals with the partner’s API directly does.
The next step might be to make sure that its testable – you might want to access the actual object inside of the accessor, to run methods on them without a lot of casting and if statements. To do this, you could make a generic accessor that could be re-used with a method on it that would allow you to run any method on the internal object by name without casting. This idea is borrowed from Jon Skeet (of multiple fames) – if you were trying to figure out how to use dynamic objects in .NET 3.5, you could read his post on the matter.If you borrowed liberally from Mr. Skeet’s post you might end up with this:
public abstract class GenericAccessor
{
internal object Obj { get; set; }
protected GenericAccessor(object obj)
{
Obj = obj;
}
private GenericAccessor()
{ }
public T GetMethodResult(string methodName)
{
Type type = Obj.GetType();
MethodInfo method;
T retval;
try
{
method = type.GetMethod(methodName);
retval = (T)method.Invoke(Obj, null);
return retval;
}
catch (Exception ex)
{
Logger.LogException(ex);
return default(T);
}
}
}
So now, you can run GetMethodResult to access the processor’s API methods directly even through your accessor without having to write a bunch of wrapper methods. It’s kind of like dynamic programming! Though, I prefer the real thing!
I don’ t want to get in to the big picture “Adobe vs. HTML5 vs. Silverlight” discussion, I think its been done well elsewhere.
However, if Mary Jo is right in her recent article about Microsoft’s intentions, I’m a little worried:
“Silverlight is our development platform for Windows Phone,” he said. Silverlight also has some “sweet spots” in media and line-of-business applications, he said.
But when it comes to touting Silverlight as Microsoft’s vehicle for delivering a cross-platform runtime, “our strategy has shifted,” Muglia told me.
and later:
Muglia didn’t share any kind of timetable as to when Silverlight 5 might make its debut. He did note that the delivery pace of Silverlight is slowing. “As with anything as it matures, the (delivery) cadence changes,” he said.
That last bit sends chills down my spine. The trouble is, I’ve been observing Silverlight’s growth trajectory, and watching it mature as an excellent potential platform for line of business apps. As a SaaS ISV delivering, among other things, accounting applications for large organizations, Silverlight’s mix of easy deployment, rapid application development, and inherent cross platform nature make my life easy. We recently undertook a project to replace an aging ASP.NET WebForms app containing some 1,500 lines of pre-JQuery JavaScript with a Silverlight app, and we’re thrilled. Better developer productivity, a very clean UI… I realize that Silverlight might not be considered “the web”; but it is in my mind an Internet platform for rapid application development that delivers apps on all major operating systems elegantly.
I don’t want the world to ignore HTML5, and I’m really excited about the “new JavaScript” world – node.js, CouchDB and others are all doing things in JavaScript that are really interesting. Projects that we deliver to end consumers in their homes, of course we want HTML5 there. I don’t want to be beholden to a plugin when I’m targeting end consumers. But when we’re delivering line of business software to a large organization that can help us make sure that Silverlight is on all of the machines we are licensing, Silverlight is a real winner.
So, if Microsoft is “embracing HTML5″ why am I worried?
A decade of Microsoft’s ASP.NET WebForms world leaves me a little dubious of Microsoft’s commitment to well formed, cross browser HTML. When I watch a Silverlight developer add a button control in XAML or even drag it on to a Silverlight form, I’m not worried about the mess being made. I can’t say the same thing about WebForms. Micosoft’s historical tooling support for HTML CSS and JavaScript is just not all that good; and what’s to say they won’t try to use HTML5 in an embrace and extend campaign to win IE9 marketshare back?
Of course, there’s ASP.NET/MVC, and of course we love it for consumer facing web apps – but it makes assumptions that the developer can deliver good markup, which will need to be tested on IE7, IE8, IE9, FF2, FF3, FF3.5, Chrome, Safari… need I go on? Of course JQuery makes that easier than it was, no doubt – but I think what I liked about Silverlight is that I could put a good developer who knows XAML and C# well, sit him down in a chair with a good set of tools, and out would come easily managed well formed code. To do a good job in ASP.NET/MVC the developer needs to be expert in a much longer list of technologies.
If I had my way, Microsoft’s IE9 would do a good job supporting HTML5 – but Microsoft would continue to invest in developing Silverlight, and not just for the phone. I guess I’m just afraid of how far they’re going to turn the ship…
UPDATE:
A recent Microsoft publication addresses some of the concerns above and makes for good reading on the future of Silverlight.
Having launched programs on all sorts of payment networks, including Canada’s home grown Interac “PIN debit” system, Visa, MasterCard, Discover, and even Maestro in Europe, I can relate to both sides. It’s true, right now as EMV is not common place in the US yet, the cards are a bit more expensive, as are the payment terminals. That being said, however, the added security is tremendous. Its easy to get up in arms about increased cost, especially if we don’t remember to look at what we’re getting for this increased cost.
A typical “mag stripe” card relies purely on data that has been embedded in the magnetic stripe. Anyone can buy an inexpensive card reader and record the data in the mag stripe, and with an easily obtainable machine they can then create a duplicate of the card. There are ways to make this more secure; but most of the rely on adding even more data to the mag stripe that’s just as easy to clone, unless you go so far as to require a PIN – and it’s not hard to simply video tape people entering the PIN to get around that.
There are questions from smart people about the EMV standard – it may not, in its current incarnation, be smart enough yet, even though it changes the game significantly. Many believe that it is enough to reduce the scope of the problem – but is it good enough?
So what are your thoughts? Wal-Mart says that EMV is the future – and that we should just get going with it already. I can relate – its frustrating watching the glacial change of pace with EMV. Is it time?
Over on LinkedIn, I’m doing a quick poll of who uses what Browser. Right now, with 12 responses, its evenly split between two browsers. However, you might not guess which two!
Check it out, and put your own vote in.
I checked out the Windows Phone 7 tools tonight, and I’m very happy with the current release. Visual Studio Express is one fantastic product, and Silverlight 4 is very nice. In about an hour (or two) I had a basic app going. Hit F5, and up it comes in an emulator.
I’m toying around with whipping up a little app, and I imagine us putting it in the Microsoft App Store thing. Pretty cool! Go, check it out.
I did a Channel 9 video on Silverlight 4 the other day, which was good preparation for working in the WP7 Silverlight environment. If you’re a Silverlight Whiz already, you can probably skip it.
Here’s some great starter links:
