TarDisk Review

My dev machine is a “Late 2013” 13 inch Macbook Pro. The machine has more or less been serving me well, despite the occasional kernel panic — these crashes tend to happen when I need to have Android Studio and an Xcode project with a substantial storyboard open at the same time. If you’re interested in more detailed specs, take a look below:

My one major problem since about three months after I got the Macbook has been the insuficient amount of storage that I speced it with at the time purchase. After finding out that Apple will no longer perform a harddisk upgrade as a service at the Genius bar and I didn’t feel particularly confident in opening up my machine myself, so I started looking for alternate solution. After hearing about TarDisk on Twitter, I decided to order one of their 128GB kits and give upgrading my Mac a shot.

Right off the bat, I got a less than great feeling about the product. It came in pretty cheap looking packaging and the instructions looked like they were printed out on a home class inkjet printer. The device itself is a non-descript silver wedge, meant to go in the SD slot of the computer. To be honest, after unpacking the device I sat at my desk with it and the packing out for a few minutes and considered just sending it back. After my few minutes of doubt, I decided to go for it.

After following the instructions that basically amount to closing all applications nad restarting my Mac, I attempted to inster the device into my Macbook — it got stuck. I had to power down and get a thumbtack to wedge the device out. Again, I considered just bailing out on this process but ultimately decided to give it another go, because I’m crazy apparently. After finally getting the TarDisk into the mac and waiting about forty-five seconds and again remove it, since the device was not recognized by MacOS which is what the instructions state should happen automatically on insertion.

Inserting it a second time got MacOS to recognize the TarDisk and I was able to run the tool as described in the instructions. After a few minutes, the process was complete:

As you can see, I do indeed have the additional hard disk storage. Despite the rough installation, the TarDisk does seem to work as advertised and, though it will take some months to tell for sure, seems to not have had any adverse effect on the general stability of the system.

While I won’t go as far as to recommend TarDisk just yet, I can say that it’s an affordable option worth taking a look at if you don’t mind taking a bit of risk. Obviously, there’s plenty of room for the team at TarDisk to improve the installation process and it might be interesting to see a revised version of this product with some of the rough edges smooted out a bit.

Update: For those concerned about benchmarks, there’s been no noticeable degredation in performance on regular use but my needs are not particulary high-end. However, if you’re doing video encoding or something like this, you probably want a different solution. Take a look at this review from Digital Trends where they benchmark it but again if you care at all about disk IO performance beyond your system drive, I’d still contend you’re better off just doing the full SSD upgrade.

AppCode Review

As is well documented on Twitter, I’ve had my share of frustrating system locking beachball of death experiences with Xcode, so it should come as no surprise that I’ve been keeping a keen eye on JetBrains’ AppCode IDE for iOS and MacOS development.

Being a user of two of JetBrains’ other IDEs, Android Studio and RubyMine, I found the on-boarding experience for AppCode to be pretty familar and was able to get up and running in just a few minutes. Overall, the keyboard shortcuts are very similar to their other IDEs and there’s a lot of value in having a similar setup on multiple IDEs.

AppCode also includes many of the refactoring tools that you’ll be familar with if you use any of JetBrains’ other IDEs and has impressilvely just about been able to keep up with Swift 2.0. However, it’s pretty clear that the AppCode team’s fighting an uphill battle to keep up with the development of Swift and is still refining how the refactoring tools deal with the langauge — the AppCode team will likely have to devote continued effort to keeping up with Swift for the forseable future.

Unfortunately, keeping up with Apple’s development of Swift seems ot have come at a cost, the integrated UI designer. As explained here, the Designer has been made a plugin that can be added after you install the main AppCode package. It’s also worth noting that the plugin doesn’t work on all interface file types and was not useable at all for three out of the four test iOS projects that I used to evaluate the Designer. On the one project that it did work with, it was pretty disappointing and not at all an acceptable replacement for the tooling provided in Xcode for user interface design.

What I and I imagine the vast majority of iOS and MacOS developers want out of AppCode is for it to be what it originally was planned to be — a full Xcode replacement, but there’s a lot of ground to cover before it can qualify there. If JetBrains is serious about AppCode, then they’re going to need to improve the user interface designer to the point where 100% of an iOS or MacOS development project can be done in AppCode. Let me know what you think on Twitter.

A Farewell to Apps?

Ars Technica recently posted an article by Larry Seltzer that discusses the possibility of native mobile apps being marginalized by web-based solutions thanks to the increasing advancement of web standards on mobile. Normally, I’d ignore something like this — in most cases when you see the tech press post a headline that’s something akin to for will A kill B, you can rest assured that the content will be fairly overstated and that you’ve been taken by a click-bait title. For the most part, Seltzer does a good job of understanding some of the challenges faced when using web-based technologies to develop but overstates the desirability of having mobile websites replace apps while simultaneously overlooking obvious shortfall of a pure mobile-web only strategy: performance.

JavaScript interpreters have been getting better and better every year and most JITs (just in time compilers) are on track to annually provide “free” performance increases on most browsers for most common use cases. However, they’re not keeping up in terms of raw speed with optimized native code on specialized hardware — for instance, Swift code on Apple’s A8 processor in the iPhone 6S. Another thing to consider is that all of the code on a mobile website must be run through the browser’s JavaScript interpreter.

The idea that native apps aren’t necessarily right for all business needs is pretty obvious and I agree with the author up to that point, but most of the technical issues that he mentions have been addressed by hybrid apps. Hybrid apps using Cordova-based tool-kits such as Ionic address the most common performance issues seen with mobile sites and the lack of web-based APIs for some many hardware features by actually having native level tie-ins. Basically, they implement native API’s a layer below where the developer writes his app logic and expose a JavaScript version of the APIs for the developer to use. From a technical perspective, developers can write any hybrid plugin for any functionality released in a future version of Android or iOS, then access that functionality via JavaScript.

Mobile websites do have one advantage of packaged apps and that’s that they do not have to be distributed via the AppStore. This, however, is not a technical problem, but rather a policy one. Apple still opts to manually approve every single app submission and app update for their iOS store and that creates an artificial delay between developers completing a release and users being able to install it; in cases where the developer is fixing a major security issue, this can be devastating and needlessly exposes users to risk. Still, the advantages of being able to tie directly into device functionality and the performance increases gained make publishing apps via the AppStore mechanism or some enterprise deployment scheme the right choice for the vast majority of apps whether you are developing using native or HTML5 technologies.

2015 Year in Review: Apple

Now that we are just dabbing our toes into 2016, it’s given me some time and cause to look back at the year that was. A lot of things were happening in 2015 but they broadly break down into who was involved: Apple, Google, Microsoft, VC Startups. Today, we start with Apple.

Swift: Arguably, the largest and most positive impact Apple has had on the take space this year was in releasing and open-sourcing their new programming language Swift. Swift is on track to take the development world by storm and benefits greatly from the success of the iOS development platform with the general development community.

IBM Partnership: Apple is not historically the easiest company to partner with but this year they’ve unveiled a partnership with IBM to bring the iOS platform deeper into the enterprise space. This might have some impact but my bet is that most enterprises who are interested in mobile are going to focus on Cordova or other HTML5 based solutions for their line of business development needs. Even in the worst case, the deal with IBM gives Apple some well needed good press.

Sub Apple-Par Products: The Apple Watch was well hyped, enthusiastically covered, and basically a disappointment. Apple Music is… well… not exactly what anyone had hoped and let’s not even talk about the battery case. Their product launches this year have run counter to the usual level of quality we’ve come to expect in terms of fucntional design and user interface design. Also, they still have some serious issues when it comes to cloud services.

Successful as they may be, Apple seems to be have been stumbling in 2015 in terms of product launches while making significant strides with Swift. The Watch felt rushed and I’m hopeful that version two will be a lot more stylish and functional. All in all, Apple might want to revert back to their previous focus and take just a little more care in polishing products before launching them in 2016.

iOS Needs to Go Pro

Apple did it! They launched another amazing, category defining product! Of course, I am referring to the iPad Pro. Coder Radio listeners will know that I have a fabulous gold model that I’m enthralled with. I truly believe that the Pro has the potential to become the primary computing device for the vast majority of business and home users. There’s just one tiny little problem with the device and my vision of iPad world domination: Apple.

Despite its name, the iPad Pro is more Pro and less iPad. Given the complexity of apps that need to be written to take full advantage of the Pro, the lumping it in with regular iPads puts an undue burden of backward compatibility on developers. In all likeliness Pro users are not going to be primarily the same types of users or at least using the device in the same way that regular iPad users user their tablets — the idea here is production on consumption. Apple should consider allowing developers to submit and publish iPad Pro specific apps that are not required to be backward compatibile to regular iPads.

Advanced productivity functionality is great but it would be even better if iOS didn’t limit what developers could do. Though iOS 9 has made some strides in terms of inter-app communications, there is still plenty of work to be done. I won’t go into a laundry list right now of API additions and changes, I’d like to see for the Pro but to start it involves greater inter-app communications and greater filesystem access.

iPad Pro apps are going to be expensive and time-consuming to develop. That means that developers are going to be under even more pressure to monetize their apps. Up to this point, the story of App Store pricing has been depressing to say the least. Apple’s been unwilling to work with developers on things that are very common in productivity oriented software such as upgrade pricing and trials. The reality is that many developers will not be able to afford to take full advantage of the Pro unless they can find an effective and predictible way to gain repeated revenue from their customers.

All in all, the iPad Pro is the best device so far to finally achieve the goal of widespread tablet computing in the productivity market, but there are some policy and API limitations that Apple will need to consider in order for the device to reach its full potential. Let me know what you think on Twitter.

The King’s Mores

The recent tragedy in South Carolina has brought questions of the Confederate flag being used on government buildings and other placaes that it might be offensive. Personally, I agree with the critics that it was wildly inappropriate for the US flag to be flown at half mast out of respect for the lives lost while the Confederate one was not lowered. In response to the tragedy, a number of retailers have decide to stop selling memorobilia with the flag on it and the flags themseleves. One unlikely follower in this trend was Apple with their App Store.

Apple has decided to begin enforcing rule 19.1: “Apps containing references or commentary about a religious, cultural or ethnic group that are defamatory, offensive, mean-spirited or likely to expose the targeted group to harm or violence will be rejected”. Basically, they are asserting that the Confederate flag is inherently damaging. The issue is that many of the apps in question are games that focus on the historical aspects of the Civil War. I persnally find this to be a gross over-application of that rule but even if you agree with teh decision, there is a wider issue at play that shoud be of concerned to every developer working on Apple’s platfoms.

Apple is no longer shy about using its absolute power over the App Store to enforce what might be considered its own preferences / world view. This is well beyond just protecting users from poorly coded apps or security flaws in third-party software. Apple is now enforcing their tastes and mores on every iOS user and (more frightenly) every iOS developer.

It’s been a long time coming but I think this is the last straw for me in terms of control from Apple. I just can’t justify having so much of my life and livelyhood be based on a platform whose owner has no issue with enforces their mores on its users and developer community.

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!