Postmortem Part 1: The Curtin Rises

If you’re anything like me, you started your business knowing that one day you might lose it but at a certain point you figured that you lasted long enough that you were pretty safe. Of course, you’ve gotten a few dings and dents along the way but you figure that you’ll never face something worse that what you’ve already faced. Well, you might be wrong. I was. This series is going to be the story of how the frst company that I founded almost six years ago grew until it imploded. My goal is to be both frank but also objective, honest but also sensitive to those involved.

In the beginning, there was a silly boy with a Medieval Literature degree, or rather on his way to earning one, doing little Word Press sites and other projects for local business. He was one measure happy to every four measures of naivety but still did well. In time, he learned, grew, and expanded his little freelancing gig pipeline into a business with staff and even a brand book. That boy was of course me and of course he, like Bruce Willis in The Sixth Sense was already dead and all the signs were there…. if you knew what to look for.

Business was seemingly booming. After having let go of an underperforming sales rep, a new rep had been hired and was going gangbusters. Leads were converting to proposals and then to deals faster than I ever could have thought possible. Volume was increadible! What could go wrong!

We had to keep up with the influx of work, so off to job faires and Indeed.com I went. Within a span of just over a quarter we went from a team of two and half to around ten and things seemed to be cranking away! Hell, things got so crazy, we ended having a Customer Service team to deal with client inquiries.

We were already dead and just didn’t know it. All the signs were there. I should have known and more expereince managers would have known that a company of ten having to dedicate more than one fullt-ime staffer to customer service probably has a problem. More on that next time.

Ahoy Mateys!

I am happy to announce the official public launch of my new company Buccaneer Tech, INC. Buccaneer is something new from what I’ve done before, as it has more of a focus on bringing the best of open-source technologies to the enterprise market via innovative mobile and software as a service products.

Enough of the buzzword bingo! What does this all mean? Well, it means we are going to be launching some products based on open-source and of course we will also be limitedly available for consulting projects.

I’m not ready to make any product announcements just yet but if you follow @BuccaneerTech on Twitter to be one of the first to know!

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

Slack

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.