Rockford Lhotka's Blog

Home | Lhotka.net | CSLA .NET

 Saturday, July 26, 2014

I am sitting here listening to Stone Sour on Xbox Music (yes, I’m a hard rock/metal fan – always have been).

Stone Sour - what an excellent band. Not only because their music rocks, but because their stage performance is amazing. If you ever have the chance I suggest you see them in concert. Don’t bother to go out of your way to see Rob Zombie. His music might be good, but he is flakey and might skip out on a live show in the middle.

I say this because I was just at Rock Fest in Cadott, WI and that’s what happened. Stone Sour, despite the Corey Taylor having a rough throat put on an amazing performance – Corey gave everything he had left to put on a great show. Yes, it was sub-standard in terms of his voice, but it was perhaps the most amazing show I’ve ever seen.

Rob Zombie, having a rough throat, did just enough to get paid and then walked off the stage, unwilling to match Stone Sour’s ability to put everything into the performance. Rob Zombie said, in so many words, that he was willing to walk off stage rather than give a sub-standard performance, missing the opportunity to match Taylor’s dedication to his audience.

There’s a parallel to software development that crystallized for me with these two contrasting performances. It is something I think my friend Billy Hollis has been trying to tell me (and the rest of the industry) for the past few years.

When we’re younger we’re so ready to prove ourselves that we’ll do pretty much whatever it takes to get the job done – to build software that meets the user’s needs. It seems that many of us change as we get older, being more willing to abandon the user’s needs in our pursuit of “doing the right thing”. We focus on TDD and Agile and all sorts of other esoteric concepts at the expense of actually getting things done for the users who need our software to improve their lives.

Don’t get me wrong, I’m not saying we should write crappy software. But  there’s a mantra in Microsoft that applies here: “shipping is a feature”. In other words, if you delay getting sh*t done because you’ll only release if your code is perfect then you are missing the whole point of writing software. We aren’t creating art, we’re improving people’s lives – which can only be done by putting our software in the hands of actual users.

There’s a balance to be struck between “doing everything right” and “getting sht*t done”. For most of my career I’ve leaned toward the latter, but it is true that as I’ve gotten older I’ve put a higher value on the former.

Thinking about this, I think it is the same misguided ego that caused Rob Zombie to piss off a couple thousand fans by walking off stage. Exactly the opposite of Corey Taylor who got sh*t done even if it wasn’t perfect – and thus won the love of a couple thousand of the same fans.

I’ll go out of my way to see Stone Sour again, but I if I see Rob Zombie it will be because he came to me – I’ll never bother to pay to watch him walk off stage again.

I suspect the same is true with the users of our software. If we actually release something – even if if isn’t perfect – our users will be happier than if we get halfway through a project and fail because we were so focused on making it perfect that it couldn’t be accomplished with reasonable effort.

In summary, things like Agile and TDD are great, as long as they don’t get in the way of getting sh*t done.

Saturday, July 26, 2014 1:03:38 AM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [1]  | 
 Monday, July 14, 2014

From around 1995 until 2010 there was really only one operating system for client computing: Windows.

Prior to 1995 there were a lot of options, though most not recognizable to users today: 3270 terminals, VT terminals, OS/2, Windows, DOS, CPM, and a bunch of others. Now most of these weren’t “client computing”, they were relatively dumb terminal technologies that provided access to a server (back then called a mainframe or minicomputer). Very much like today’s web browser (sans JavaScript).

Today we’ve returned to a chaotic landscape of client computing: browsers, Windows, iOS, OS X, Android, Linux (for the daring), and of course it isn’t like the pre-1995 technologies went away, they are just mostly emulated in Windows. What is interesting though, is that most of today’s client computing technologies do actually enable smart client software development. This includes the browser which can be used as a smart client technology via JavaScript development, even though the majority of browser “apps” are actually just colorful versions of 1990-era terminal-based computing where the processing is all on a server/mainframe/minicomputer/whatever-you-want-to-call-it.

What is interesting about this return to client-side chaos is that it has reopened the door for third party developer tools as a niche market.

In the early 1990’s there were quite a number of companies selling developer tools for other company’s platforms. Borland with C++, Delphi and TurboPascal, Gupta with SqlWindows, Powerbuilder, and a lot more.

When Windows became the dominant client computing platform most of these dev tools fell by the wayside (not that they went away, they just stopped being mainstream). This was because they couldn’t compete with Microsoft’s dev tools, which were always in sync with the platform in a way that was probably too expensive for third parties to match.

I think it is notable that our return to client computing chaos (or pluralism?) today has already led to numerous third party dev tool vendors that sell dev tools for other company’s platforms. Xamarin, PhoneGap, Telerik’s tools, and a lot more.

What is different to me is that in the early 1990’s I thought it was pretty obvious that Windows would become a dominant platform, and I tended to argue against using third party dev tools because I thought they’d have a rough go of it. As cool as Delphi was, I always recommended VB.

Today I’m not so sure. I don’t see any of today’s platforms becoming dominant in the foreseeable future. It is hard to imagine Windows returning to its monopoly status, but I can’t imagine iOS or Android or OS X displacing Windows as the primary corporate desktop computing environment either.

As a result we business developers need some way to build software independently of any particular platform or OS vendor, because we must assume all our business software will need to run on multiple platforms and OSes.

So today I find myself in the inverse of my early 1990’s stance, in that I’m reasonably convinced that building smart client software (at least for business) means using third party dev tools from vendors that aren’t tied to any one platform.

Of course I’ve spent the last 14 years in the .NET world, so naturally I gravitate toward a combination of Xamarin and Microsoft .NET as a way to use my C# and .NET knowledge across all platforms. I get to develop in Visual Studio on Windows where I’m most comfortable, and my resulting software runs on Android and iOS as well as on Windows Desktop, Phone, and WinRT.

As far into the future as I can see there’s no obvious platform/OS “winner”, so as a developer the question isn’t which platform to target, it is which third party dev tool reaches all platforms with a solid strategy that will stand out and thrive over the next many years.

Monday, July 14, 2014 1:00:31 PM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [0]  | 
 Tuesday, July 01, 2014

There’s been a lot of exciting change in cross-platform development for C# developers over the past few months. Microsoft introduced the Universal Apps concept for WinRT (Windows 8 and Windows Phone 8.1), and Xamarin introduced Xamarin.Forms (Windows Phone 8, Android, and iOS).

Beneath the Universal App support in Visual Studio 2013 is a broader concept called a Shared Project. With the Shared Project Reference Manager add-in for VS13 you can reference these shared projects from any project, not just Universal App projects.

As a result, you can build a solution like this one:

SharedCodeSolution

This solution includes a Xamarin.Forms MobileApp, a Microsoft Universal App (based on the Hub control), a Windows Forms app, and a WPF app. All of these apps use non-UI code from the NonUICode.Shared project.

In fact, the Android, iOS, WinPhone, Windows, and WindowsPhone UI projects have basically no code at all. In the MobileApp all the UI code is in the MobileApp1.Shared project. In the WinRTApp all the UI code is in the HubApp1.Shared project.

The Windows Forms and WPF apps each have their own UI code. Windows Forms is its own thing, and although WPF uses XAML, it is an older dialect that doesn’t share enough in common with WinRT or Xamarin.Forms for sharing.

None of the UI projects contain any business logic or logic to call services. All that code is in the NonUICode.Shared project so it can be maintained just one time. The service calls use HttpClient, which is reasonably common across all the UI platforms, and for the few differences I’m using #if statements to accommodate the per-platform code. For example, here’s a bit of code from a shared viewmodel class: 

    public async Task SaveData()
    {
      if (this.IsDataLoaded)
      {
        var webClient = new HttpClient();
        var data = JsonConvert.SerializeObject(this.Speaker);
#if ANDROID || __ANDROID__ || __IOS__
        var content = new StringContent(data, System.Text.Encoding.UTF8, "application/json");
#else
        var content = new HttpStringContent(data);
#endif
        var urlString = apiSpeakerUrl + @"/" + this.Speaker.Id.ToString();
        var response = await webClient.PutAsync(new Uri(urlString), content);
        if (!response.IsSuccessStatusCode)
          throw new Exception("SaveData failed");
      }
    }

The overall result is that with reasonable effort you can create an app that spans every type of smart client technology available today; from Windows Forms up to iOS. These apps can share all your business and service client code, and can often share a lot of UI code.

(fwiw, if you build your business logic with CSLA .NET it is a lot easier to create and maintain the shared business and service client code than if you try to build that code by hand)

CSLA .NET | WinRT | WP8 | Xamarin
Tuesday, July 01, 2014 3:32:53 PM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [3]  | 
On this page....
Search
Archives
Feed your aggregator (RSS 2.0)
July, 2014 (3)
June, 2014 (4)
May, 2014 (2)
April, 2014 (6)
March, 2014 (4)
February, 2014 (4)
January, 2014 (2)
December, 2013 (3)
October, 2013 (3)
August, 2013 (5)
July, 2013 (2)
May, 2013 (3)
April, 2013 (2)
March, 2013 (3)
February, 2013 (7)
January, 2013 (4)
December, 2012 (3)
November, 2012 (3)
October, 2012 (7)
September, 2012 (1)
August, 2012 (4)
July, 2012 (3)
June, 2012 (5)
May, 2012 (4)
April, 2012 (6)
March, 2012 (10)
February, 2012 (2)
January, 2012 (2)
December, 2011 (4)
November, 2011 (6)
October, 2011 (14)
September, 2011 (5)
August, 2011 (3)
June, 2011 (2)
May, 2011 (1)
April, 2011 (3)
March, 2011 (6)
February, 2011 (3)
January, 2011 (6)
December, 2010 (3)
November, 2010 (8)
October, 2010 (6)
September, 2010 (6)
August, 2010 (7)
July, 2010 (8)
June, 2010 (6)
May, 2010 (8)
April, 2010 (13)
March, 2010 (7)
February, 2010 (5)
January, 2010 (9)
December, 2009 (6)
November, 2009 (8)
October, 2009 (11)
September, 2009 (5)
August, 2009 (5)
July, 2009 (10)
June, 2009 (5)
May, 2009 (7)
April, 2009 (7)
March, 2009 (11)
February, 2009 (6)
January, 2009 (9)
December, 2008 (5)
November, 2008 (4)
October, 2008 (7)
September, 2008 (8)
August, 2008 (11)
July, 2008 (11)
June, 2008 (10)
May, 2008 (6)
April, 2008 (8)
March, 2008 (9)
February, 2008 (6)
January, 2008 (6)
December, 2007 (6)
November, 2007 (9)
October, 2007 (7)
September, 2007 (5)
August, 2007 (8)
July, 2007 (6)
June, 2007 (8)
May, 2007 (7)
April, 2007 (9)
March, 2007 (8)
February, 2007 (5)
January, 2007 (9)
December, 2006 (4)
November, 2006 (3)
October, 2006 (4)
September, 2006 (9)
August, 2006 (4)
July, 2006 (9)
June, 2006 (4)
May, 2006 (10)
April, 2006 (4)
March, 2006 (11)
February, 2006 (3)
January, 2006 (13)
December, 2005 (6)
November, 2005 (7)
October, 2005 (4)
September, 2005 (9)
August, 2005 (6)
July, 2005 (7)
June, 2005 (5)
May, 2005 (4)
April, 2005 (7)
March, 2005 (16)
February, 2005 (17)
January, 2005 (17)
December, 2004 (13)
November, 2004 (7)
October, 2004 (14)
September, 2004 (11)
August, 2004 (7)
July, 2004 (3)
June, 2004 (6)
May, 2004 (3)
April, 2004 (2)
March, 2004 (1)
February, 2004 (5)
Categories
About

Powered by: newtelligence dasBlog 2.0.7226.0

Disclaimer
The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.

© Copyright 2014, Marimer LLC

Send mail to the author(s) E-mail



Sign In