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.

Code Journal 1.4.0 Update

Code Journal LogoI am Happy to announce that Code Journal 1.4 has just been released on the Mac App Store. We took special care to respond to your feedback both in terms of performance and of course new features.

I am particulary fond of the new less wordy way we are naming and dealing with repositires in the title bar and also we’ve added the match requested manual refresh button. For a more complete list of changes, please see the release notes on the App Store.

Going Mobile: Byword

This is the first entry into Going Mobile my series of reviews on mobile productivity software – I am defining productivity software as any software I use to get work done. For this first entry we have Byword for iPad, a great markdown editor for iPad (and actually iPhone too). It’s fitting that the first pick be a markdown editor, since the majority of this website has been written in markdown for some time; in fact, this post post has been drafted in the app on my iPad Mini.

Byword doesn’t strain itself to be the best looking iOS app on the market; in fact, it focuses more on function than form, however, it is still a pretty good looking app and leans very heavily toward the iOS 7 design paradigm.

What puts Byword ahead of the pack of mobile markdown editors is its integrated posting to Word Press and a number of other blogging platforms. This might seems like an unnecessary convenience but the fact is that effective blogging from a mobile device requires that the process be as frictionless as possible. A close second for my favorite feature in the app, is dark mode. Given iOS 7’s relative hostility toward nighttime use around a sleeping partner or spouse, it is refreshing to see third party developers taking the time to add dark modes and other quality of life features.

The app costs $4.99 currently and to unlock some of the advanced publishing capabilities, you have to purchase a $4.99 “premium” in app purchase. This is my only issue with the app – the app feels pretty incomplete without the in app purchase. That’s not to suggest that the app isn’t well worth it’s true cost of $10, but rather that this pricing scheme feels a little deceptive and in my mind brings down the (for lack of a better term) “class” of what is otherwise a very high-end experience. I’d gladly pay $10 for the app outright but understand that I’m in a fast shrinking minority; the reality is that thine pricing scheme probably was decided upon due to the unfortunate economics of the app economy.

If you’re in the market for a mobile markdown editor and are an iOS user, then I strongly recommend that you check Byword out. If you have any comments or app suggestions, please share them with me on Twitter.

Time to Go Mobile

If you read my 2014 Predictions, then you know that I don’t believe that we are going to see a lot of huge leaps in mobile hardware or OS technology in the next year. Software from third party developers however will be a different story. Indeed, it is my belief that 2014 is the year that large numbers of normal users are going to begin using their mobile devices as the power personal computers they really are – in many ways, a mobile device is a far more personal computer than an actual PC at this point.

I’m going to be one of these brave few and will therefore start featuring and reviewing applications that I use on a variety of devices. However, I am not going to artificially promise to review an app per week. Nor am I going to worry about making sure all platforms get the same amount of coverage. My goal is to honestly review and recommend apps that I use regularly on whatever platform.

Since these are apps that I actually use, there will be no negative reviews – in fact, there’ll be no scoring at all, as I find the star or X out ten scoring systems to be arbitrary at best. Think of these apps as my picks and treat them that way. If you like what I like and you find something that you start to use often from these posts, then please let me know on Twitter or Google+.

2014 Predictions

I hope that you have all had an awesome New Year’s Eve! I’ve decided that I’ll start off 2014 by making a fool of myself by trying to make some predictions for the tech industry for the new year. This is not a what you will see list, but nor is it a what you won’t see one; in reality, I am trying to focus more on trends than anything else. Overall, 2014 is looking to be a transition year rather than a real game-changer. This is in no way a bad thing and makes sense for where we are in what is usually a twenty year tech cycle; it is important to remember that the mobile revolution is not even half way done and there are still a lot of incremental advancements that need to be made in that area before it can be considered complete. Still, this article will not focus on mobile exclusively but will rather jump around with no other aim than what I find interesting.

Docker: Docker is the darling of the developer community right now and for good reason — it solves a problem that (outside of the BSD community) hasn’t really been properly addressed. There is however a risk of certain segments of the community drinking a little too much of the Koop-Aide and using Docker in ways that it wasn’t intended to be used; just think about what we saw with Rails a few years ago and the hype surrounding that and you will have a good idea of what I am concerned with. Still, at the end of the day Dockery is going to be a major tool in a lot developers’ (including this one’s) toolboxes for 2014 and probably beyond.

Windows 8: In the consumer market, Windows 8′s RT offering is in a lot of trouble — that is undeniable at this point. Windows Phone suffers much the same fate as Windows RT, though Windows Phone does enjoy a good holding in South America and some other parts of the world. Microsoft has already hinted strongly that they plan to merge WinRT and Windows Phone into one mobile operating system alla iOS. This is a great Idea but is several years too late. It also undermines the “one Windows” pitch that Microsoft has been making for Windows 8 over the last few years. In 2014, Microsoft will still be dealing with the fallout of their bumbling launch and marketing of Windows 8.

Azure: Azure has grown far beyond Windows in the cloud and at the close of 2013 is a rival to Amazon Web Services and pretty much every other cloud offering. I’ve used Azure several times myself over the year and am pretty impressed on the whole; there were some bumps in the beginning and middle of the year, but these have largely been addressed and it looks like Microsoft has some ambitious plans for Azure in 2014. Over the last month or so something called Midori has been leaking out of Microsoft and, though the pundits seem to think it is something to do with Windows on the client-side, my bet is that this is some sort of evolution of Microsoft’s cloud offerings. Either way, 2014 is going to be a good year for Microsoft in the cloud and for Azure.

Mac OS X: Twelve months ago it looked like OS X was veering dangerously toward an iOSification that would have proven intolerable for professional users. With Mavericks however Apple has found a good balance between their desire for control and the reality that the pro-market has been driven to OS X due to its being a UNIX system that has a late vendor for support and an attractive user interface. Despite the apparent back peddling, it is important to note that Apple has gotten one major change in the OS and managed to implement it in a way that is both useful to the average consumer and acceptable to the pro users — this feature is called Gatekeeper. In Mavericks, Gatekeeper does not allowed unsigned applications (to sign an application one needs to be an approved Apple developer) to be installed on the system by default. The key is that this is a default that any sophisticated user can change. However, I must admit that I have kept this default. Going forward, Apple’s belief in signed applications (or perhaps some slightly watered-down version of it) makes a lot for sense for the future of computing and I actively support refusing to install unsigned applications from untrusted sources. If the current path holds, Apple will be balancing making OS X simpler for average users and new users who came over due to the halo effect of iOS while balancing the needs of the professional user market.

Ubuntu / Linux: Canonical has done an amazing job of sullying the Ubuntu name over the 2013 and has done little more than make a fool of themselves with their naïve attempt at breaking into the mobile space. Ubuntu will still be a very popular desktop Linux operating system among new Linux users and will continue to be a major player on the server-side. Canonical the company however will fail to monetize their offerings in any significant way. The only ray of hope would be some sort of re-focusing of the company to be an enterprise focused organization much like Red Hat. Even in that case, Canonical will not be able to be a true challenger to Red Hat in 2014 and it is unlikely that they will even decide to try. The continued flailing of Canonical will contribute to a “brain drain” of passionate and talented Linux enthusiasts out of the Ubuntu community and into other Linux communities. Another side of effect this is that desktop Linux will continue to be the proverbial tempest in a teapot that it has always been. This internal discord will guarantee that 2014 will not be the year of the Linux desktop in any significant way.

That’s it! Those are my foolish predictions for 2014 — foolish as they may be, I am pretty confident that most of them will be, if not correct, then on the right track. I know they are not earth shattering and basically boil down to 2014 will more or less maintain the status quo. In a way, that’s a good thing. If we are constantly reinventing new technologies and never refining the technologies we are already have, then we will always be using unstable and half baked first generation technology. Have a happy new year and feel free to comment on Twitter.

MDNetworking: My Little Networking Lib

Disclaimer: This is in no way a 1.0 codebase and I strongly recommend against you using this in production.

Summary: MDNetworking is a small Apache 2.0 licensed Cocoa / Cocoa Touch library. It is intended to be suitable for use on iOS7+ and Mac OS X 10.8+ but it may in fact be possible to get it working on older version of iOS and OS X. My intention in creating this library is not to make yet another heavy Cocoa networking framework that is going to solve the meaning of life and the world’s problems. I merely want to present a relatively simple and easy to use facade of NSURLConnection and the like.

Contributing: I’m open and welcome contributions from the community, however, any contributions that don’t adhere to the present code-style will be rejected.

Review: Dell Venue 7

tablet-venue-7-mag-965-mixed-set-video-comOver the last few weeks, I’ve had the opportunity to try out the Dell Venue 7 and use it as a test device but also a day to day media tablet.

The Good: The tablet ships with a fairly recent version of Android: 4.2.2. Additionally, the UX is pretty much stock Android — in fact, I’m at a strain to find anywhere that Dell has significantly modified the OS. At $150, it is nothing if not affordable. This low price point is made all the more impressive by the beautiful screen that holds up fairly well to its higher-end competitors.

The Bad: Unlike most popular Android tablets, the Venue is based on an Intel chipset. Taken by itself, that’s not necessarily a bad thing, but there is a trend of developers (especially mobile game developers) tweaking their software to optimize for Tegra and SnapDragon processors — or more broadly put, developers of high-end Android software, have been optimizing for ARM systems. In fact, on a few higher end games, I’ve seen a bit of sputtering on the Venue that I don’t see on the Nexus 7.

The Ugly: Dell’s decision to go with Intel also seems to have affected the industrial design of the tablet. It is noticeably thicker than the Nexus 7 and feels like it is a year or two behind the likes of the Nexus and Nokia’s Sirius tablet in terms of its industrial design aesthetic.

Conclusion: Dell’s’ Venue 7 is not a bad tablet by any means and will probably excel in certain arenas where price matters more than performance: ie corporate deployments. However, if you can spring for the Nexus 7, then you’ll probably be a bit happier with Google’s tablet.

Programming Pitfalls: Windows 8 & VS 13

PitfallIt will come as no surprise to anyone who has been following this site for a while that I’ve been doing a bit of Windows 8 development. Like many developers moving over from another platform, I have some concerns about XAML and the development philosophy that it seems to promote, but that’s not the pitfall I hit this time. No, the trap I fell into is far more sinister….

You see I had opened Visual Studio 12 and got a notification that there was a new version of Visual Studio coming out and if I wanted to take advantage of all of the new goodness in Windows 8.1, I’d need to download it via MSDN. Like a good little code monkey, I did just that and made a fussy coffee while I waited for download and install to finish.

Once the install had finished I opened Visual Studio 13 and created a C# / XAML metro app. So far so good. No errors or warnings of any kind where displayed. On the whole, I am pretty happy with the workflow in 13 and got the app done in just about a week — it was just a proof of concept.

Now comes the tricky part: deployment. After going through the ridiculous proces of explaining to a non-tech person that they have to run a PowerShell script to run the archive Visual Studio produces, all seemed to go well — the first stakeholder was happy and passed it on to someone else. Then came the issues. For some reason the app would run on some devices and not others.

After a few frantic hours of search-fu, Stack Overflow browsing, and digging through the chaos that is the MSDN developer forums, I had a theory. Was it possible that all the devices that the app ran on had been updated to 8.1 and the ones it didn’t work on were still on 8? If so, there surely would be a menu or XML attribute in the App Manifest that I could change the minimum version to 8.

I was right on the first point and kind of right on the second. It turns out that the app could not be run on 8.0 devices as built and there is an option in the manifest to change the version. Unfortunately, in VS 13, you can’t change the version number. My suspicion was confirmed — Visual Studio 13 did not support building for Windows 8.0. Well, that’s not exactly right either. It turns out that Visual Studio 13 will build a Windows 8.0 app but will not create one — that means that you’d need to create the project in VS 12 but could move over to VS 13 later. I ended up having to create a new project in VS 12 and copying the code over into that new project. The bottom line is that this feels like a ham-fisted attempt on Microsoft’s part to force adoption of the 8.1 APIs and left me with a bad taste in my mouth. At this point, I am sticking with VS 12 until all of my projects no longer require 8.0 support but, frankly, this problem just shouldn’t exist.

Questions? Comments? Find me on Twitter.