LOB in 2015

Line of business software development is one of the least discussed and least sexy areas of software development. Ironically, it is by almost any metric the largest. There are more HR applications that are succussfully running inside their organizations than there are indie apps that are successful business.  Why don’t we care about LOB software? Why isn’t there an LOB blog or podcasts about being LOB developers (or even “dark matter developers”), the tools they use, and the struggles they face? Well, LOB development has been boring at least up until now. 

2015 is going to be the year that all of those older LOB applications get brought into the modern world. This will be brought upong by a mixture of pressure to go mobile and the natural purchasing cycles of medium to large enterprises.  On this week’s Coder RadioChris Fisher and I, had a lively discussion about Xamarin.Forms and my less than stellar expereince with it. 

Purists will of course say that for the best expereince on a platform you have have to develop natively on the officially supported tools for that platform. I agree with that, but here’s the thing — not everyone wants or needs “the best”. We make compromises of this sort al the time. For instance, I can’t afford the best car, so I drive a car that’s good enough for me; if you must know, I drive an 08 Toyotal Corolla. You see, I made a cost / benefit analysis when purchasing my car all those years back and that’s the exact sort of calculus that business types make routinely when it comes to commissioning line of bussines applications; that might explain all the IE 6 and VB code that’s running around for sure….

Here’s where I get controversial — I think they are right and correct in their decision, at least in principle. The issue becomes one of balance. How do you balance quality and cost-savings? That’s the question (at least in the mobile space) that Xamarin and the various vendors of mobile web-based app development solutions will have to answer. I still hope that Xamarin gets their act together with Forms, since C# is a much more pleasant language to work in thatn Javascript, but only time will tell. 

Xamarin.Forms Review

A few months back in August I did a brief review of Xamarin in which I was pretty happy with the tool-kit and how it was helping the team at Fingertip Tech, INC
efficiently handle developing mobile apps for both iOS and Android. Now that we are about six months on and I’ve built a lot more expereince with the tooling I’d like to take a deeper look at Xamarin’s “write once run anywhere” offering Xamarin.Forms. 

I’ll be blunt — Forms is as immature as it is seductive. Don’t get me wrong, the things that Forms does support are great and work really well cross platform but the reality is that you can’t get very far without Xamarin.Forms Labs, an impressive open-source project that sadly suffers immaturity and having to keep up with Xamarin which has to keep up with iOS and Android. Additionally, if you really care about the user experience of your apps, then you will likely end up having to purchase some controls from Telerik or the like. To ble clear, I’m not just talking about complex charts or anything like that. To date, Forms doesn’t have an ImageButton class — you’ll need Labs for that.  

The work around for all this is writing custom renderers for each platform. The problem there is that basically defeats the purpose of using Forms, since you might as well use “classic” Xamarin at that point; the assumption being that you are using Forms to cut down on platform specific work. 

Having said all that, I was able (along with the awesome team at FTT) to ship projects using Forms but we ended up underwater financially on almost all of them, since we had to write “customer renders” for any non-trivial UIs. 

Forms is a great idea. Sadly, it’s the same great idea that Sun had for Java on the desktop in 1990’s. Xamarin could make Forms a great offering but would be wise to take the lessons of desktop Java and RealBasic to heart. 

Follow me on Twitter or Google+. Interested in getting your app project off the ground? Then, contact Fingertip Tech, INC and forget to follow us onTwitter!

Pallet Town: Xamarin.Forms Basic IOC

enter image description hereWelcome to Pallet Town! Pallet town is going to be an ongoing bi-weekly look at various development technologies and techniques from the perspective of someone new to that technology. For those who might know or (God forbid) are too young to get the reference, Pallet Town is the first town in the original Pokemon games for the Nintendo Gameboy.

Xamarin.Forms is a cross platform tool that allow code re-use for iOS and Android. It works by interpreting your C# code and layout it out using what are usually reasonable conventions for the specific platform’s UX paradigms. For example, a Forms Tabbar lays out on the bottom of the screen in iOS but the top on Android devices, thus following the conventions for both platforms correctly.

Forms makes good use of the common .Net inversion of control development technique. If you haven’t worked in the .Net space, then IOC may seem a bit strange – indeed, it has taken me some time to actually figure out how it works but it’s actually pretty simple to get started with and is extremely powerful in terms of code re-use and modular design. Forms.Labs, an open-source collection of classes designed to jump start your Forms development, uses IOC to great effect to help you easily access device specific functionality from your shared Forms code, rather than having to write platform specific code.

Let’s take a simple case of wanting to import an photo from your device and wanting to keep it as much as possible on the Forms level, rather than dropping to platform specific code. Here’s the shared code that would likely be on a Page in your app:

IMediaPicker picker = DependencyService.Get<IMediaPicker> ();  
MediaFile img = await picker.SelectPhotoAsync (new   CameraMediaStorageOptions {
                MaxPixelDimension = 100 // arbitrary size

OK, so you’ve picked an image. Now let’s take things a step further and say that you want to save it to disk for some other use, such as uploading it to S3 or maybe just to have for later:

var fileAccess = Resolver.Resolve<IFileAccess> ();
string imageName = "somename" + "jpeg"; // assuming jpeg
fileAccess.WriteStream (imageName, img.Source);

What we are doing is uses a shared / abstract interface to call onto both the phones image gallery in the first snippet and the filesystem in the second. So far so simple and I’m happy to say it really never gets much more complex. We just have to do a little platform specific code. First, let’s take a look at our AppDelegate for iOS:

var resolverContainer = new SimpleContainer ();
    resolverContainer.Register<IDevice> (t =>   AppleDevice.CurrentDevice)
            .Register<IDependencyContainer> (t => resolverContainer)    
            .Register<IFileAccess> (t =>; new FileAccess ());
Resolver.SetResolver (resolverContainer.GetResolver ());

You’ll either want to add this code to your ‘FinishedLaunching’ method or create a separate method and call that method from ‘FinishedLaunching’. Now, let’s take a look at Android where we will be working in our MainActivity:

var resolverContainer = new SimpleContainer ();
        resolverContainer.Register<IDevice> (t => AndroidDevice.CurrentDevice)
            .Register<IDependencyContainer> (t => resolverContainer)    
            .Register<IFileAccess> (t => new FileAccess ());
Resolver.SetResolver (resolverContainer.GetResolver ());

Notice that the code is just about identical with the obvious ‘AppleDevice’ versus ‘AndroidDevice’ difference. Basically, what we are doing is setting the correct platform specific objects upfront on application launch, so that when we call the first snippets in our shared code, we don’t have to care which platform the code is actually running on.

Developers experienced with IOC will note that this is a pretty simple example of IOC and it is capable of much more than just abstracting away the device platform. If you’re just getting started on your development journey and are having a hard time wrapping your head around the snippets here, don’t worry about it and come back to it later. This is just mean to be an introduction to IOC on Xamarin.

Hope this post helps you on your journey to become a Pokemon… err coding master! Please feel free to send any feedback to me on Twitter or Google+. Also, be sure to check out my company Fingertip Tech, INC on Twitter.

Playing Hockey in MS Stadium

Hockey now plays in Microsoft's rink!Before Apple acquired Testflight last year, we were heavy users of the service for both iOS and Android deployments. This fit well with our strategy at the time of providing affordable prototyping for entrepreneurs that could be tested on both major mobile platforms. Apple decided that they’d cut off support for Android once they completed the Testflight acquisition and this left us (and many other developers) in a lurch; the hassle of getting non-technical people (i.e. our average customer) to switch over to another beta / app deployment service was pretty steep and for a bout a month our customer service costs nearly doubled. To make matters worse, we didn’t immediately jump to Hockey. Instead, we tried a few other alternatives that made large promises but on the average failed to deliver. It was a good day when we finally made the Hockey switch and we haven’t looked back.

Now, things are once again in question. Whenever a small / medium company whose services you rely on gets acquired by a giant, there is a huge opportunity for disruption – again, see how Apple handled the Testflight acquisition.

However, it is unlikely that Microsoft will take any similar action, as they are in a very different situation – Apple had a dominant (at least in terms of developer mind-share) platform but lackluster developer tools, where Microsoft is quickly becoming a tools powerhouse but it would be had to say that Windows RT is anything but a total failure and Windows Phone just isn’t making any real impact in the markets that FTT focuses on. This difference in market position seems to have lead to Microsoft focusing on developers as their customers (at least in the narrow space of mobile), rather than end users. This is an interesting strategy and one that Microsoft alone is uniquely positioned to succeed with.

In the last few months, I’ve found myself increasingly working in Microsoft tools, such as Visual Studio and various Azure offerings. This hasn’t been the effect of some conscience “let’s go Microsoft” campaign but rather a natural outcome of looking for tools that more appropriately fit my current needs at the right price. Your mileage may vary, but so far my experience has been pretty positive; the largest issue I had was some confusion with company MSDN account and our installs of Windows and Visual Studio; the latter issue has pretty much been eliminated by Visual Studio Community Edition.

Does this mean the we should all drop our current tool-chains in favor of the Microsoft equivelants? Of course not. In fact, that’s not what we’ve done at FTT – almost all of our back-ends are still based on Ruby on Rails, not ASP.NET MVC. As always, you have to pick the right tool for the right job and the right team but it is good to see that Microsoft is getting into the mobile game and is taking mobile developers and our needs seriously.

Questions? Comments? Boiling Linux-powered hatred? Get in touch on Twitter and please follow FTT on Twitter.

Going Mobile: Oyster

Reading is one of the few constant pleasures I’ve had my entire life. As a young boy, I used to accompany my mother to the local Barnes and Nobel once a week, not to purchase but to read books — my mother was kind enough to purchase me a book once every other month or so, but that’s a story for another day.

Overtime, my reading habit started to get a little too costly and I quickly had to turn to some desperate sources, such as the Dunellen Public School library who, despite doing the best they could, had little more than a shallow offering on a relatively narrow range of subjects.

One day everything changed. One day Amazon released the Kindle. The Kindle was a revolution for me and significantly lowered the cost of my drug of choice. Unfortunately, it turned out to the heroin to my cocaine and my habit became an increasingly frequent one.

Oyster aims to act as a methadone of sorts for my reading habit. Basically, Oyster is a subscription service for ebooks. It works in a very similar way that Netflix or Spotify do but you can tell based on the selection that this is an area that the publishing industry is not exactly jumping into lightly; indeed, it can be a challenge for me to find titles that are of interest to me and that I haven’t read. Still, for the price (just under $10 per month), you can’t go wrong if you can manage to read at least two books per month.

Happy reading! Please follow me Twitter and remember that this post is brought to you by Fingertip Tech, INC (@FingertipTech) who would love to help you with your app project!

Xamarin Review

http://xamarin.comRecently, we at Fingertip Tech, INC have been doing a lot of work in Xamarin and Xamarin.Forms. All in all, things have been going fairly well and the tooling seems to get better everyday! Still, nothing is perfect and at the end of the day working with the Xamarin toolchain is a decsion that has to made on a per project basis and will greatly depend on the overall budget for the project and its maintenance. We are still evaluating Xamarin.Forms but the following are my findings and observations of working with Xamarin classic.

The Good: C# is an absolutely amazing language and every .Net developer ought to apologize to every Java for not spreading the word on just how phenominal the langauge really is. I know that will be a controlversial statment and the Java VS C# debate is a post for another day, but if you haven’t ever done any work in a modern version of C#, then I urge you to give it a shot and try to have an open mind.

Xamarin Studio is a pretty good IDE on Mac OS X and XCode developers will be familar with the IDE’s layout and overall setup – additionally, if you have ever used a modern version of MonoDevelop, you’ll be in pretty good shape. Additionally, the setup process on Mac OS X was pretty straightforward and I was impressed the Xamarin was able to tie into my iOS development tool-chain, pulling up my simulators and my code-signing credentials. On the iOS side, Xamarin does a great job of supporting storyboard and nib files for user-interface design and is no too shabby on the Android side also; however, Android UIs are still best done in the XML layout files directly.

Despite being in C# rather than Objective-C or Java, Xamarin is a faithful port of just about all of the native iOS and Android APIs. In fact, if you know how to do something with say UITableView in Objective-C, then you pretty much are good to go in Xamarin.

The Bad: Working in Xamarin Studio is great! Well, that’s as long as you are working on Mac OS X. The Windows version of Xamarin Studio is nowhere near as polished or as reliable as its Mac sister. For example, on my Windows 8.1 machine, there is an issue in Xamarin Studio that incorrectly highlights correct code as erroneous. Additionally, the intellisense and related features just aren’t as reliable on Windows. AlthoughIt is likely that a good number of developers using Xamarin on Windows would prefer to work in Visual Studio, there is little excuse for the way Xamarin Studio runs on that platform and frankly it makes it seem like Windows users who have not paid for access to the Visual Studio integration are not as much of a priority as those using Visual Studio or Mac.

The Ugly: Once upon a time, developers the world over were used to paying for by the seat licences for software development tools and even progreamming languages. Xamarin is trying pretty hard to bring that back but I’m not sure it works. Something about the per seat pricing model rubs me the wrong way. Additionally, up until just the other week, no form of mothly subscription billing was available and even to date there is no monthly pricing for anything beyond the ‘Indie’ plan. As the owner of a small but still bigger than five person software development company, I find their drawing the line between ‘Indie’ and ‘Business’ at the seemingly arbitrary number of five just a bit too well… arbitrary for my tastes. Additionally, there are plenty of companies like mine that would probably prefer to not be billed seperately for iOS and Android. All of this creates a sort of complexity that just doesn’t jive with what is otherwise a clean and very customer friendly offering.

Overall, I am pretty happy with how well Xamarin is working out for us and plant to continue working in it. Follow me on Twitter or Google+. Interested in getting your app project off the ground? Then, contact Fingertip Tech, INC and forget to follow us on Twitter!

Going Mobile: Overcast

icon_340This is the second entry into Going Mobile, my series of reviews on mobile software. Frequent readers of this blog will notice that this series used to only focus on productivity software but is now expanding to the wider app ecosystem. I’m still taking a special focus on apps that actually allow you to “get things done” or provide a certain level of productive value.

This week I’m really excited to be taking a quick look at a brand new app by the nerd-famous Marco ArmentOvercast. Overcast is basically a high-end iOS only podcast client. As a podcaster myself, please check out Coder Radio if you are into development, I get really excited when a top-tier developer like Arment puts something out in the space.

The Good: Overcast is fast. I mean lightening fast. I’ve been using it since day one and have yet to find any noticeable lag or stuttering with any of the animations in the app. To be fair, some of this is due to the app’s arguably spartan design; in fact, other than the app’s logo, it uses all standard iOS controls, something that works surprisingly well and is refreshing when compared to some of the overly “designed” apps we’ve seen over the past few years.

Though I am not a huge fan of playing podcasts at higher than 1X speed, it’s good that Overcast offers the ability to finely control how fast you are playing back the audio. Like all of the app’s features, this is elegantly tucked away and is in now way intrusive.

The Bad: Overcast is free to download and use to a point and Arment has been pretty generous in what features he allows you to access before paying the $4.99 upgrade price; in fact, you can use some of the premium features for free with limits without paying – it is a little shocking that Apple allowed this, given their relatively hard position on trials of any kind. However, Arment’s generosity doesn’t make up for the fact that “smart speed”, the apps signature feature, is just not very impressive and I’ve found to not work pretty very well for the majority of podcasts in my somewhat extensive library.

The Ugly: It is a little disheartening that someone like Arment who has a following and could release even the simplest of apps and still get some immediate and great press felt that even he had to go with a freemium model to make a decent profit on the app. Arment’s done freemium in the “cleanest” way I’ve seen so yet but it still feels a bit unfortunate that it had to be done.

Conclusion: If you subscribe to more than three podcasts and use an iPhone, then you should give Overcast a shot.

Slacking Off


At Fingertip Tech, INC HQ collaboration is key, so we’ve been searching for tools to help us better work together as a team. We’ve worked with a few tools over the years but none has fit our work model as well as Slack.

Slack is very similar to HipChat, the tool it is replacing at the Fingertip HQ. The main advantage that makes Slack the winner for me is its better user experience and greater focus on design than HipChat and pretty much the rest of its competition.

We’ve found it easy to integrate Slack with all of our most important services – especially our self-hosted (on Digital Ocean) GitLab source control system.

Of course with any tool, there are downsides. For instance Slack doesn’t have an app on any desktop platform other than Mac OS X. Additionally, Slack’s Mac app does not feel very native; in fact it seems to be a wrapped HTML5 app – this is something that rubs me the wrong way but in practical terms rarely becomes an issue.

Being grounded in web technologies does make its Chrome app one of the most impressive Chrome apps I’ve used in some time.

A Swift Softening

enter image description here Listeners to last week’s Coder Radio know that during the live feed WWDC coverage, I was less than enthused with the announcement of Swift, Apple’s new programming language for iOS and OS X. My initial reaction was based on the somewhat unclear way they announced Swift; it was not very clear what they wanted us developers to use Swift for and that led me to the wrong conclusion that Swift is designed to be a near to medium term 100% replacement for Objective-C – this simply is not the case. So far, I’ve read through the Swift book on iBooks and the documentation publicly available twice and found something very surprising – Swift reminds of QML in QT.

This might sound a bit odd, given that in a lot of significant ways Swift and QML are very different languages, but they actually share a kindred spirit and will likely take the same place in my tool-chain – layouts. Yes, both Swift and QML are technically capable of so much more than layouts but really they are both well suited for that task in particular. Why do you think the WWDC demo was so UI / visuals heavy?

So the bottom line is no I don’t hate Swift and no I don’t think it will be the end of Apple development as we know it. And yes, I will be using it but, at least for the next year or so, in the same capacity as QML and its relationship with Objective-C will be same as QML’s with C++ in my QT code-bases.

Questions? Comments? Find me on Twitter.

WWDC 2014 Predictions

WWDC 2014

Well, it is that time of year again – when the tech space goes crazy with Apple fever and starts to have dancing iTVs and iWatches in their heads. From the Apple developer perspective, this is (like the WWDC of 2012) being preceded by increasing frustrations from the community regarding Apple’s tools but more their practices – these complaints have been grumbling under the surface and indeed I’ve been at the forefront of sounding the alarm, but some fights have already been lost and if history is any indicator the prominent Apple devs will be placated by pretty much whatever they get on Monday. Still, to be fair, if Apple could address a few core areas of developer pain, then there would be legitimate cause to celebrate.

Contracts / Intents: Windows Phone and Android both have viable solutions to interapp communication that work very well for the developer communities on those platforms, the platform vendors, and of course the end user. iOS, however, has no real solution to this problem; I don’t consider and a reasonable person would probably agree that the current URL schemes tricks are all just really sloppy hacks that should never be shipped and no sane developer would use them by choice if there were a better alternative. There is no technical reason that this can’t be done and at this point Apple’s stubbornness is doing a huge disservice to the developer community and the end user.

App Test Distribution: One of the most annoying aspects of being an Apple developer is that whenever a customer or even a teammate gets a new iOS device, we have to go through the whole rigmarole of getting the devices UUID, adding the UUID to our developer portal, regenerating a provisioning profile, and making making a whole new binary just to get that one new device into the testing pool. This is absurd. Apple for good reasons wants to limit how apps are distributed outside of the App Store but at this point, there system is too much of an inconvenience to developers (a group I strongly feel is important to their long-term success) to be tolerated one day longer. There is some hope – a few months ago Apple purchased Testflight and that suggests that they intend to streamline the test distribution system.

Mac Mini Refresh: I’ve been careful not to put oo many consumer / new product requests in these sort of posts but I am willing to make an exception for the Mac Mini. Though the mini is probably the least sexy device that Apple sells, it is extremely important for the developer community at large, as a ton of little shops are almost 100% Mac Mini shops. At this point, it is pretty hard to justify the purchase of a Mini given how old the tech in the device is and the somewhat poor value proposition – at least compared with the iMac or an equivalent Windows PC.

That’s it. I don’t think these items are too crazy but am not so sure that we are going see anything of significance in any of these areas. My guess is that we will see nothing the way of interapp communication, a half step toward an easier test distribution, and little more than a spec bump or price drop on the Mini.

If you want to troll me when I inevitably proven wrong on Monday, then please follow me on Twitter.