dominickm.com | Meditations on coding and software.

Google and I: It’s Complicated

Larry Page’s Google IO keynote speech was more than a little touching. it gave the company m more more human face and reminded me of why Google and its story is so inspiring. Unlike most other major tech companies, Google is actually “doing stuff”; in fact, Google is not afraid to take on projects that have the odor of science fiction: self-driving cars and Glass come to mind. In a lot of ways, Google is actually the sort of company that I think many developers dreamed of being apart of as children, so why then do I have this weird issue with them. A lot of Coder Radio listeners seem to think that I “hate” Google — an accusation that is more silly than true. My real issue is what Google does with our data (what they craftily refer to as “signals”) behind the scenes — the truth is the we (the public) don’t really know to what extent and in what ways Google is monetizing our data and it is that secrecy that leaves me with cause for (albeit mild) alarm. The question becomes — do the benefits and amazing technologies that Google brings us justify the potential privacy implications?

Again, I want to reiterate that I really do like a lot of what Google does. In fact when forming my company (Fingertip Tech, INC), Google was one of the main role models I had in mind — at the time Google was one of the few non-Linux focused companies that was making a real effort to bring open-source software and values to a more mainstream market; that is a tact I’ve taken and tried to expand on by open-sourcing as much of the software that I right as is feasible. Google’s dedication to pushing the web and mobile forward is nothing short of expiring.

The problem is that I can’t really know what I am paying for the amazing software that Google offers, since I am not paying with currency that I can track but rather my personal information. In a perfect world, I’d be able to purchase Google services ala carte and opt out of all of the “signal generation” aspect of Google. This, however, is not likely, since the data is probably more valuable than any fee that they could effectively extract from any meaningful percentage of the population. I’ve been beating the “pay for software — don’t be the product” drum for some time now, but it seems that the market would just rather not pay for certain percentage of software. Is it time to stop fighting the tide?

Questions? Comments? Dogmatic rage? Find me on Twitter and Google+. This post was brought to you by Code Journal and Fingertip Tech, INC.

Play Means War

May 20, 2013 Android, Apple, Apps No comments

Google IO fever is in full swing and, though there are a lot of interesting things coming out of this year’s IO, but there is only one real threat to Apple’s leading position in mobile Monetization. This is Play Games. Play Games functions a lot like Game Center with a bit more and (naturally) a focus on Google+. Play Games allows many of the features that Game Center does but has one killer feature: it is cross platform, supporting Android and iOS. You might wonder why this matters, but the truth is (according to the Apple App Store top grossing and top paid charts) the developers that are making the most money are the game developers. It has been argued that one of the big advantages that iOS has is that it is the prefered platform for mobile game developers — meaning that they release on iOS only or iOS first.

Play Games looks really impressive, but the most attractive aspect of it is that it is a backed Game Center like service that is not run by Apple. Let’s be honest, Apple makes great devices and some pretty good client-side software, but their backend services leave a lot to be desired. Game Center in particular was crippled when Letterpress — one of the first games to actually take advantage some of Game Center’s more advanced functionality — was released and became an overnight success. The reality is that Apple left this door open by not focussing on backend-technologies and now Google is going to be able walk through it.

If Android is able to generate roughly the same revenue as iOS for developers, Apple will have to act quickly to preempt an exodus of developers. This might sound a little overboard, but there is a frustration in the iOS community in all but the most hardcore Apple fans that Apple’s policies are increasingly hostile toward independant developers, but as long as the business case is strongly in Apple’s favor, Apple can do whatever it wants. If Google was able to change the business story, they’d be changing the entire landscape.

Why Not Platform X?

May 12, 2013 Apps, Platforms, Programming No comments

Recently, I launched my latest app Tomato Soup – simple iOS pomodoro timer and have been fielding a lot of questions from Coder Radio listeners regarding my platform choice; for those who don’t know Code Journal (iOS and OS X) and Tomato Soup (iOS) are both only available on Apple platforms. Many of these listeners seem to think that my selection of a particular platform over another is some sort of indictment of lack of confidence in the alternative platforms, however, that’s not always always true and there perfectly legitimate reasons to go single platform for any particular project.

One of the most obvious ones is familiarity with the platform, development environment, and language. In my particular case, Cocoa and Objective-C are by far my favorite platform / language combination. That doesn’t mean that there is anything wrong or I think badly of C# / .Net or Java — in fact, I often find myself defending Java against folks who spend far too much time reading alarmist Reddit posts. All it means is that I am most efficient in Objective-C. As they say: “Time is money” and sometimes shipping fast is important and the time it would take.

Increasingly, platform vendors are adding features to their platforms that can (generally speaking) only be accessed via the native API — an example of this on OS X is Notification Center. Sure, it is possible to write a wrapper around the Cocoa API for Notification Center, but that’s usually harder than you would hope and adds maintenance to your project that (in most cases) would not be put on the individual developer.

Some projects just market better on specific platforms. A lot has been discussed about the marketability of apps on Linux in particular, but I really don’t think that the conversation needs to center around Linux but should rather be about the tastes and norms of users of each respective platform. For instance, it is usually tough to sell an OS X app to a Mac user that doesn’t “feel native” but that problem doesn’t generally exist for Windows or Linux users.

Developing software for multiple platforms presents its own issues and often takes more financial resources than honing in on a specific platform. The sad fact is that if ISVs (independent software vendors) regularly poured more resources into cross platform development, we would eventually have fewer unique applications released.

I hope this provides a bit of clarification and rest assured that I, like most developers, do not hate your chosen platform and sincerely wish I could easily have my software on as many platforms as possible.

UILocalNotification 100

May 8, 2013 iOS, Objective-C, Programming No comments

There are a lot of cases where you will want to notify your user of some event of reminder without actually setting a formal alarm in their Alarm app. The standard solution most developers seem to take in these situations is to setup something like Urban Airship and fire off a push notification – this costly and shares the user’s data for no reason. Using
iOS’s UILocalNotification, you can pop a push-like notification without worrying about the hassle and potential cost of a push service and without sending any user data over the air. Checkout how easy it is to fire off a simple notification from this simple from my newly released Pomodoro timer Tomato Soup:

- (void)createNotificationForPomo:(TSPomodoro *)pomo
{
	UILocalNotification* notification = [[UILocalNotification alloc] init];
	notification.fireDate = pomo.fireDate;
	notification.alertBody = [NSString stringWithFormat:@"Nice work! Pomodoro: %@ is complete!", pomo.title];
	[[UIApplication sharedApplication] scheduleLocalNotification:notification];
}

// Now let's remove all notifications
- (void)removeNotifications
{
	[[UIApplication sharedApplication] cancelAllLocalNotifications];
}

Notifications like the one created above will still fire if the app is in the background, however, if you don’t want them to fire if the app is active, you will have to deactivate them on willResumeActive.I hope this helps you and that you reconsider how often you send user data over the air and use UILocalNotification as a simple alternative to push when appropriate.

Comments? Questions? Drop me a line on App.net, Google+, or Twitter. Also, pickup Code Journal.

Code Journal 1.3.3 Released

May 4, 2013 Apps, Mac OS X, Tools No comments

I’m happy to share that Code Journal for Mac version 1.3.3 is now available on the Mac App Store. This build includes a few small tweaks including splitting off from the iOS Github tokens and now has a friendly message for users who have no incoming activity in the Github feed.

Hope you like it!

Taking the Firefox Challenge pt1

April 29, 2013 Tools No comments

There was a point in my life when I was something of an aggressive advocate for open-source and free software. I am still a huge fan of them and do open-source as much code as I can and even contribute to some free software projects, but I’ve also gone back to a number proprietary tools for my day to day tool chain; for instance, this post was at least (partially) drafted in Microsoft Word or Google Docs rather than Libre or Open Office. Probably the most commonly used tool in my belt (and probably everyone else’s) is the web browser and up until today, I pretty much only used Google’s Chrome. An awesome Coder Radio listener named Nicholas replied to an episode from early April suggesting that if I think Google’s forking Webkit to create Blink was a I problem, I should simply vote with usage and move to Firefox, since Mozilla is a bit more dedicated to standards than just about any browser vendor out there. Over the next month, I am going to recount my experiences as a switcher here and see if Chrome really does have such an advantage over the competition. Stay tuned for all the gory details.

This post was brought to you by Code Journal – available now on the Mac App Store. Questions? Comments? Find me on Twitter or Google+.

No, The Market is not Fine

April 20, 2013 Apple, Apps, iOS No comments

There has been a lot of discussion recently in the iOS community regarding the so called “health” of the paid application market. My feelings on whether it is better to pay for the software you use to ensure that you are the developer’s main customer are well documented both on this site and Coder Radio, but, for new readers, I am an advocate of paying (and charging) for software. The most recent developer to throw his hat into this debate has been Marco Arment – the famous developer of Instapaper and The Magazine. Marco is a great developer and someone whose work I respect. His post is well thought out and reasonable – up until the last line where he states: “The bar is higher, but the market is fine”. Before diving into how someone as euredite as Arment could be so mistaken, let’s first define what it means when we say the bar is higher – apps now require a “better user experience” and a good deal of marketing to even be noticed by a reasonable number of users.

Yes, I know Apple has changed the world! Users now demand simple and elegant experiences. Isn’t that great? Well, no if you’re a developer, that’s terrible. That’s terrible, because, as a developer, you likely do not possess the design skills or experience to properly design an app of design caliber that a professional designer would. Like developers, designers do not work for free and a gifted designer who has been working in the field for any length of time command and handsome hourly rate. That means that to hit the required level of design, developers need to invest a good deal of capital in it.

Let’s say that you’ve got your design down and you’ve come to terms with your newly shrunken bank account – my condolences on that by the way. What now? Do you just passively wait for users to download your app? Perhaps you pray for users? Do a rain dance? Sadly, there is no evidence to suggest that any of the preceding will actually help your app become successful. Like any product (and yes your app is a product, not some work of self-expression), your app needs to be marketed. There are a lot of ways of to market it an app, though few of them are effective, but none of them is free unless you are a known quantity (like Arment) or able to convince one to push your app. That means you will need even more capital to get advertising for your app.

Like Arment, I agree that the bar is higher for apps than it was just a few years ago, but I contend that the bar being higher is a problem for the average independent developer. Many of these developers simply do not have the capital required to hire a decent designer and effectively market an app. So, if Arment seems to agree that the bar is higher, then how could he be so blind to the issues that poses for small independent developers? The answer is surprisingly simple: Arment is something of a celebrity in the Apple developer world. That means he doesn’t need to spend the capitol that others would to market his apps; In fact, his name and connections do that for him. In short, the bar is higher for all of us, but it is only half as high for Arment.

“There are Always Men like You”

April 20, 2013 Programming No comments

At the time of this draft I am lying in bed watching The Avengers and I’ve just gotten through the scene where Loki makes the German civilians kneel and one elderly man stands up and refuses – he states that there are “always men like you” to Loki. What’s my point other than proving I am a huge nerd? Well I feel like that old man in the tech space today. More and more it seems there is always another threat around the corner. Whether it be a patent troll looking to extort us, a large platform vendor making us scramble according to their whims or “taste”, or worse our users demanding ever more of our time and energy for pennies an hour if any money at all.

Still, I am not deterred from the field and hope you will join me in toughing it out. There is still a lot to be happy about in the industry even if some of it (app store distribution) comes with some serious strings attached. It’s a bit funny in fact – as I lie here thinking of all the things wrong with our industry I am also planning out what coding projects I want to work on over the weekend.

I hope this post has brought some value to you despite it being basically a stream of consciousness – if you do like it and have comments, please leave them on Google+ or Twitter.

My Win8 Dev Tools

April 19, 2013 Tools, Windows No comments

Coder Radio listeners will know that I recently purchased a Dell XPS 8500 from my local Microsoft Store. Unlike a lot of Cocoa developer, I am not just buying a PC as a glorified Xbox; in fact, I have an Xbox and am very happy with it. This PC is, like my MacBook Air, a working machine. Its mission in life is to develop software or rather be a tool to help me develop software. To that point, a lot of listeners from CR have been interested in what my tool chain on Mac was and I have already received some emails from Windows users asking what I use on the Windows side of life. Before we jump into specific tools, let’s lay some ground work: cross platform support is important to me for most utilities I use; I am very committed to continuing to use Git as my scm of choice; it sounds silly but I like tools that are simple to use and native to the platform; I have no interest in running Cygwin on my Windows machine. Also, I am not going to bother listing the tools that don’t directly influence my dev work or are not Windows specific – for instance I will not be listing Dropbox or Evernote even though I do use them daily.

SourceTree: Though I generally use the command line on Mac for Git, on Windows I prefer to user a GUI and there really isn’t one out there that performs better or is as simple to use as SourceTree. To put it simply, it is the best looking Git client on Windows and is totally free of cost like its Mac counterpart.

Visual Studio: I’ve said it before and I’ll say it again: Visual Studio is a great IDE. Currently, one of my projects is focused on Windows Azure, so Visual Studio was the way to go. So far it rocks.

PowerShell: I have to admit that before Windows PowerShell hit the scene, I always felt that Windows was just a little too GUI focused. After all, on my Mac I can write a little Ruby script or Bash script to solve whatever lame problem I am problem I am having – these problems usually have something to do with improperly named assets from clients (as an aside, please follow the naming conventions I prescribe) that I have loop over and mass rename. Admittedly, I am a PowerShell novice, but so far it rocks I can do just about everything I used to do with a Bash script with roughly the same amount of lines in PowerShell.

That’s it so far. Obviously, I could use a few more tools on the Windows side and if you have any suggestions, please send them my way. Questions? Comments? Dogmatic rage? Please feel free to contact me on Google+ or Twitter. This post was brought to you by Code Journal for Mac.

Wither Webkit?

April 17, 2013 Apple, Google, Web No comments

As you are probably aware Google has forked Webkit and will be calling their fork Blink. Google does not intend to re-merge with the main project at any point in the future and is signaling that they will be adding new features to their rendering engine. As a developer who often has to work on the web or mobile web this is very interesting but also a little concerning.

Currently, Blink and Webkit are just about identical, so we can still feel secure in our Webkit “monoculture”, but the situation will likely change in a year or less. Even if Google makes an effort, as some have suggested that they might, to not break standards or chooses not to push Blink specific features, web developers are still going to have to deal with yet another rendering engine. Sure we’ve already been dealing with a number of them and have gotten used to having to append our CSS with “–webkit” or “–moz”, but Google is not adding a “–blink”. Instead, developers will have to dig into a settings screen to enable or disable functionality. Bottom line there is that there will be Blink specific functionality that some developers will likely want to user; for example currently NACL only works on Chrome and Dart VM works best on Chrome – in other browsers code written in Dart has to translated into traditional JavaScript. There are also a number of rumors floating around that Blink may focus on optimizing HTML5 graphics performance on ARM devices.

The question really becomes not what Google is going to do with Blink but rather what are the rest of the Webkit team going to do without them? Google and Apple have been the driving forces around the project and more and more Google has been taking point on a lot of the more cutting edge issues; for example, Google has been pushing performance more than any other contributor to the project but, for the most part, Apple and others have been able to benefit from Google’s efforts thanks to the free software nature of the project’s license. Given Apple’s less than enthusiastic embrace of developers using web technologies to develop for their platforms, it seems unlikely that they would be inclined to match Google’s pace. In a lot of ways, give that Apple’s business model is to sell expensive hardware, a good browser is just another feature on an Apple device, however, for Google, the browser is the primary platform.

Progress is a good thing for web and I am confident that Google’s decisions will yield web developers some pretty cool tech to work with, but there is also the risk that web developers will start relying on those tools too much and we will end up back in an IE 6 / ActiveX situation. Questions? Comments? Dogmatic rage? Please feel free to contact me on Google+ or Twitter. This post was brought to you by Code Journal for Mac.

« Older Entries