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.

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.

Coder Radio 100% Employment

Help Wanted!Every week Chris Fisher and I hear from energetic developers and the like who are looking to break into the field but are just having a hard time getting that first gig. Well, Coder Radio’s sponsor Digital Ocean is hiring as is my own company Fingertip Tech, INC.

Both companies are great (OK I’m a little bias on the second one…) and would be a great fit for any of the Jupiter Broadcasting listener-base.

At Digital Ocean, you’d be working at one of the hottest Linux based companies. As a very happy Digital Ocean customer, I can tell you that it is one of the hottest forms in its space and would be a great resume-builder for a Jr Developer or IT worker.

Fingertip Tech, INC is equally awesome! At Fingertip, you’d get to work in a fast-paced environment with the latest in mobile and web technologies with a tight-knit group of folks who not only work technology but live and breathe it. I should warn you, however, if you are a Linux user, then you’ll need to be ready to defend your distro and window manager choice not only on your interview but on your first day; XP users need not apply. Currently, we are only interested in candidates that can travel to our Eatontown NJ offices, however, full and part-time opportunities are available.

I hope this helps someone and let’s get that Coder Radio community employment number up to 100%! Digital Ocean and Fingertip Tech, INC can both be found on Twitter.

If you have enjoyed this post, please consider following me and my company on Twitter and on Facebook.

Programming Pitfalls: Circular Imports in Objective-C

PitfallI spend a lot of time in XCode working in Objective-C for iOS and Mac OS X projects. In many ways, Objective-C has become my “native language” in terms of programming languages. Still, that doesn’t mean that I can’t make really silly mistakes when working in that language. In fact, through the magic of GitHub you can see the mistake in real-time in my open-source Cocoa / Cocoa Touch networking library, MDNetworking.

The mistake is, like the best dumb mistakes, small and simple but can take more time than I’d like to admit to notice and resolve. Take a look at this pseudo-code sample for what went wrong:

#import "Foo.h"
#import "Bar.h"

@implementation Foo
 // CODE
@end

 

#import "Bar.h"
#import "Foo.h"

@implementation Bar
// CODE
@end

That’s it. That’s all you need to do to reproduce this programming pitfall. As always, I hope this has been illuminating and entertaining for you and please do follow me on Twitter.

Customer Service and Tech

Our industry is a little odd to say the least No I am mot going to dribble on about haw tech, or perhaps more accurately the software industry, has made the world a much better place. What really means me proud to be in this field Is the amount of personal accountability our C level executives take. Even Google the most anti-people company in tech, has brought on customer service reps for their enterprise and hardware products.

For instance, Apple’s Tim Cook wrote an open letter in which he took the hit for issues that Apple users had with Apple is mapping solution. He even took things a step further by getting rid of Scott Forestall the executive who refused to take responsibility for the issue.

Microsoft took things a step further by making long-time CEO and figurehead of the company resign due to the much overblown Windows 8 situation; more on this at another time. If this isn’t personal accountability then nothing is.

Time and again I’ve had to deal with companies outside of our industry and been sorely disappointing. My two favorite recent examples are 1-800 Flowers and UPS. Both these firm take pains to avoid any sort of customer service responsibly. For instance, the flower company has an automated message is your call them on a high volume day that simply hangs up on callers. UPS is a bit better -they will take your call but claim that their distribution Centers do not have phones. That statement is, if true, an obvious safety issue for their employees. The reality is that they “don’t have phones” really mean “we don’t want you calling us”.

The time has Come for these businesses to start being a little more customer focused.

Testing TDD: First Look

TDD (Test Driven Development) seems to be gearing up to the new “best practice” for 2014 and you know there is nothing I like more than being told that there is a new (though TDD’s newness is debatable) shininess that will solve all of my problems and make me poop rainbows. To be clear, I don’t think that TDD is a bad idea. In fact, we are actively discussing how we might implement TDD where it makes sense at Fingertip Tech, INC – they key phrase there is “where it makes sense.” To be brutally honest, one of the reasons I’m writing these posts is to try to counter the “up and coming” TDD consultant trend. Oh yes, the process consultants are moving on from Agile and are trying to make TDD a fertile ground for their inflated consulting fees. It is my hope that sharing some knowledge at this point with you my dear reader will help you to not get suckered in by a smooth talking process consultant; as far as I’ve seen these people are nothing but charlatans, preying on organizations that have failed to keep their staff engaged.

Proponents of TDD claim that it will reduce time spent on QA / bug fixing and generally increase the quality of our code across the board. Unfortunately, they’ve so far failed to provide any conclusive evidence that supports those claims across the board – to be fair, there are plenty of folks offering guestimated anecdotes but those are as dubious as they sound. What I want is something like the average project has X hours of bug fixing under normal circumstances, we spent Y hours doing TDD, spent Z hours bug fixing anyway, Z + Y is either greater than or less than X. From a practical point of view, I see no reason to bother with TDD unless Y + Z constantly come out to be less than X. It is for this reason, that I am currently tracking this simple formula in our TDD projects.

I’m also tracking a few other factors: platform, client-side, server-side, testing library, and the nature of the bugs that we still end up having to manually test. Though I’ve been doing this personally for a few months, I am still not prepared to release my full results.

I will, however, say that TDD (at least in my experience) is looking to be like Agile in that a little bit of a good thing is good but a lot can be terrible. I’ll also share a few more points. The first being that TDD for me has so far been a sunk cost in terms of time on the client-side – it is near impossible to really “test” visual elements without manually testing them. The server-side, however, has been a different story and far more positive. This makes sense, since the TDD folks tend to focus on its effectiveness for server-side platforms such as ASP.Net or Rails.

If you want to follow this series, please follow me on Twitter and add this site your RSS reader of choice.