Crossing The Finish Line With IMSA

This slideshow requires JavaScript.


As Tim called out the other day, we recently went live with a brand new mobile experience for IMSA, and I had the privilege of leading the engineering team on the project here at IK. The scope and timeframe of the project were both ambitious: we delivered a brand-new, content-driven mobile app with live streaming audio and video, realtime in-race scoring results, custom push notifications and more, across all major platforms (iOS, Android, and Windows), with custom interfaces for both phone and tablet form factors – all in a development cycle of about twelve weeks. It goes without saying that the fantastic team of engineers here at IK are all rockstars, but without some cutting-edge development tools and great partnerships, this would have been impossible to get across the finish line on time:

  • Xamarin allowed our team to utilize a shared codebase in a single language (C#, which we happen to love) across all of our target platforms, enabling massive code reuse and rapid development of (effectively) six different apps all at once.
  • Working closely with the team at Xamarin enabled us to leverage Xamarin.Forms to unlock even further code-sharing than would have been otherwise possible, building whole sections of the presentation layer in a single, cross-platform XAML-based UI framework.
  • On the server side, our partners at Microsoft’s continued world-class work on Azure made utilizing Mobile App Service (née Azure Mobile Services) a no-brainer. The ability to scale smoothly with live race-day traffic, the persistent uptime in the face of tens of thousands of concurrent users making millions of calls per day, and the ease of implementation across all three platforms, all combined to save us countless hours of development time versus a conventional DIY approach to the server layer.
  • Last but not least, being able to leverage Visual Studio’s best-of-breed suite of developer tools was essential to the truly heroic amounts of productivity and output of our engineering team at crunch time. And Visual Studio Online enabled the Project Management team and myself to organize features and tasks, track bugs, and keep tabs on our progress throughout the hectic pace of a fast development cycle.

The final result of this marriage between cutting-edge cross-platform technology and an awesome team of developers is a brand new app experience that’s available on every major platform, phone or tablet, and this is just the beginning – we have lots of great new features in store for IMSA fans worldwide. I’ll be following up with a couple more technical posts about particular challenges we faced and how we overcame them, and be sure to check out the next IMSA event in Detroit the weekend of May 29-30; I know I’ll be streaming the live coverage from my phone!

Observations on Xamarin Evolve 2014

Last week I had the privilege of attending Xamarin’s annual Evolve conference in Atlanta. There were great talks, great toys, and great food, and I had a blast. A few random high-level thoughts and observations on the state of the platform, the community, and Miguel’s pronunciation of popular acronyms:

  • Previously, I would have characterized Xamarin’s pitch as “You’re a C# / .NET developer? Leverage your existing knowledge to write iOS and Android apps.” Now, I’m convinced they’d like to present it more along the lines of “You want to do cross-platform mobile development? Learn C# / .NET and use our platform, because it’s the best.” The ambition and the roadmap are aggressive and impressive.
  • The new announcements were all pretty great. Sketches are like Swift’s Playgrounds for C#, Insights gives you robust cross-platform analytics for very little code overhead, and the new Android simulator is so much faster than Google’s it’s embarrassing. Add in the recently-announced Test Cloud that lets you run automated tests on actual devices over the network, and the amount this team has added to their product in the last twelve months or so is downright impressive.
  • The culture of the company and the community around it occupies a unique position at the intersection of all the different platforms and communities it supports. More corporate- and enterprise-friendly than Apple, more hip and independent than Microsoft, and less nerdy and creepy than Google. There was a pretty even split of iOS and Android phones on attendees, and almost all of the presenters used Macs (though many of those Macs were running Windows.) Eclectic, independent, high-energy, and unique.
  • The production value and logistics of the conference were phenomenal, almost on the level of WWDC/io/Build. The keynote was slick and very well-produced, and the after-hours social events throughout downtown Atlanta were a blast. And did I mention how good the food was?
  • The pace with which the engineering team has to run is intense. I was told by multiple Xamarin engineers that the road to getting full coverage of the hundreds of new APIs in iOS 8 on launch day involved many new hires and many sleepless nights. When you step back and look at the effort they’re undertaking, it’s both super-brilliant and more than a little insane. I would argue this reflects the personalities of its founders, but what do I know?
  • PCL and NuGet are properly pronounced “Pickle” and “Noojay”, respectively. Miguel said so.

Fantastic conference, great people, and I’m already busy hacking away on a project using some of the new stuff here at IK. If you’re interested in cross-platform mobile development, and especially if you have any background in Microsoft developer technologies, you owe it to yourself to check out Xamarin. And if you’re an engineer who’s ready to build awesome stuff with the latest tools like these, we’re always looking for new InterKnowlogists.

This Is Why You Don’t Hire Good Developers ->

Laurie Voss, CTO of npm, nailing it over on Quartz: technical interviews are seriously hard, for both sides of the table. Here at IK we’ve put a lot of time and thought into how we screen engineering candidates, and our process is constantly evolving, but a few highlights that match up with Laurie’s thoughts:

    No algorithm quizzes. Ability to memorize trivia answers, while possibly indicative of intellectual passion and capacity, just doesn’t convey enough information about useful engineering skills – and quizzes like this can make an otherwise-fantastic candidate nervous and uncomfortable.
    No on-the-spot white boarding or over-the-shoulder code sessions. Again, stress and time constraints that are artificial and don’t give you an actual picture of engineer productivity. Especially short-sighted are exercises that intentionally limit access to Google or Stack Overflow: how productive would you be on a daily basis without access to both?
    Hiring for fit: Laurie does a great job of calling out what this doesn’t mean, which is hiring for friendship. Cultural fit is hugely important and difficult to define, but it’s easy to fall into the trap of hiring people that “look like they belong”, instead of finding people who bring something new to the table – while still fitting around it.

I’ve worked on a number of engineering teams throughout my career, and happen to have been involved with interviewing on every single one of them. (It’s pure coincidence that this has frequently involved a free lunch with the candidates, I swear.) Growing your team is one of the most important – and most difficult – tasks you face as a company, as it literally reshapes who you are and how you get things done. We’re constantly working at improving our own process, but I’m proud to be a part of such an awesome team of talented folks – something that’s only possible because of how much work we put in to our engineering interview process.

Want to see for yourself just how awesome our technical interviews are? We’re always looking for smart people who get things done.

P.S. Laurie’s piece is seriously great. You should read the whole thing. -> http://qz.com/258066/this-is-why-you-dont-hire-good-developers/

PDFX: First Thoughts

Quick poll: raise your hand if you

A) are a developer, and

B) have ever had to write an application with a complex graph of property dependencies.

Keep your hand up if your solution to that complex graph involved some combination of complicated property update methods, a fragile web of events and handlers wired up between properties, wailing and gnashing of teeth, or all of the above.

Brothers and sisters, put down your hands and download your deliverance: fellow InterKnowlogist Kevin Stumpf recently posted a blog series on his new Property Dependency Framework for .NET applications, PDFx. I’ve spent the last week or so implementing it for (my) first time on a project here at InterKnowlogy, and wanted to whip up a quick post on my first impressions. Since a code snippet is worth a thousand words, let’s lead with a quick example:

//Depends on value of Properties B1 and B2, and returns their summation.
public int A1
{
     get
     {
          Property(() => A1)
                  .Depends(p => p.On(() => B1)
                  .AndOn(() => B2));
          //"Property A1 depends on B1 and on B2". How cool is that?
		
          return B1 + B2;
     }
}

Yep, it’s really that simple. Fluent interface, stupid-simple declaration, and all that’s required is to inherit your model objects from a Bindable base class provided by the framework. And the best part? It all just… works, like magic. In our example above, any time B1 or B2 change, A1 is automatically reevaluated, as are any other properties dependent upon its value. There’s all sorts of great documentation on Kevin’s blog, including great info on advanced features like external property dependencies, collection dependencies (very nifty), and caching. Bottom line: if you develop .NET applications in any capacity of even moderate complexity, take five minutes to grab the code from CodePlex and check out the documentation, and if you’re not completely satisfied, I’ll send you a case of Kölsch as a way of saying entschuldigung.*

*German for “sorry”, in honor of Herr Stumpf’s forefathers.
*Not an actual offer.