One of Many Worlds: Another go at Go … failed!

Remember folks, choose the right tool for the job…

You can’t read about programming languages these days without Google’s Go programming language being discussed with much praise.  I agree that Go is good,  but I recently ran across a post addressing some short comings titled Another go at Go…failed!  The criticism is constructive and a good read.  Bottom line:

  • If your problem domain involves patterns that benefit from type parameterization or[2] polymorphism that is easily achievable through inheritance, Go is a poor choice.
  • If you find your Go code evolving into having few interfaces but many higher-order functions (or methods) that resort to frequent type assertions, Go is a poor choice.
  • Go runtime can learn a trick or two from JRE 7 as regards performance.

I thought it was going to be more bashing by a naive developer but it’s far from the case.   It goes to show the point that not all tools are the right tool for the job and not a single programming language is right in all cases.  

Developers tend to use a tool, programming language or framework, and try to fit the problem’s solution to the tool.  It doesn’t always work that way.

What He Said – Tim Bray · Software in 2014

Tim Bray has a great post discussing the state of software development in 2014.  I found myself nodding in agreement virtually all the way through this one, mainly about client-side development for mobile and the web.

The client-side mess · Things are bad. You have to build everything three times: Web, iOS, Android. We’re talent-starved, this is egregious waste, and it’s really hurting us.

A bit about mobile:

Mobile sucks · I’m going to skip the differences between Android and iOS here because they’re just not that significant in engineering terms. Anyhow, here’s the suckage.

  • First of all, you have to do your mobile development twice.
  • The update cycles are slow. Days in the case of iOS, hours for Android (compared to seconds for browser-based apps). What’s worse is that you can’t even count on people accepting the mobile-app updates you send them. Got a critical data-losing account-compromising privacy-infringing bug? Sucks to be you.
  • The devices are memory-starved, CPU-starved, and battery-starved.
  • There are loads of form factors and it’s getting worse.
  • You don’t get a choice of languages; if you hate both Java and ObjC, get another job.

Bottom line, client-side development is a difficult place to live but server-side is more stable.  I have felt this way for a long time, client-side makes me cuss and server-side makes me smile.  

It’s a good read.

Errors Installing the pg Gem When Using Heroku Postgres.app

I’ve been using the PostgreSQL Mac OS X app from Mattt Thompson and Heroku for quite some time now.  If you don’t know what it is, it’s a drop in app bundle for the PostgreSQL database.  There are many ways that work, this just happens to be really simple.

I use PostgreSQL with my Ruby on Rails projects and combine that with the pg ruby gem.  

I ran into a situation where the pg gem would not install because it could not find pg_config in a known location on my Mac.  The error occurred on Rails 3.2 but 4.0 may show the same behavior.  

The Error

The error can come up when running a bundle install or just a straight gem install pg from the command line. The resulting error may look something like this:

Installing pg (0.17.0) with native extensions 
Gem::Installer::ExtensionBuildError: ERROR: Failed to build gem native extension
.
.
.
.
An error occurred while installing pg (0.17.0), and Bundler cannot continue.
Make sure that `gem install pg -v ‘0.17.0'` succeeds before bundling.

The Solution

I already mentioned the problem is the gem install not finding pg_config during installation.  So let’s find it.

1. First, find where pg_config is located.  Run this command from a terminal window:
which pg_config

Should display something like this:

/Applications/Postgres.app/Contents/MacOS/bin/pg_config

2. You can tell RubyGems where your pg_config file is located:

gem install pg -- --with-pg-config='PATH_TO_YOUR_PG_CONFIG'

For example, pg_config is here on my system:

/Applications/Postgres.app/Contents/MacOS/bin/pg_config

So I would install the gem this way:

gem install pg -- --with-pg-config='/Applications/Postgres.app/Contents/MacOS/bin/pg_config'

The pg gem should now install. I hope this helps.

UPDATE: Scott Watermasysk points out another good solution:

SimpleMailr Coming Soon to Make Email Newsletters a Pleasure

SimpleMailr med

I’ve been working on a SaaS application for the past number of months named SimpleMailr. It has gone through several iterations as I try to convey my intentions for the service.  In a one-liner, SimpleMailr is intended to “Get your newsletter in the hands of your readers easier.”

I’ve tried and used several services such as MailChimp, Constant Contact, Campaign Monitor and others but there is a certain amount of barrier to entry.  I want something simple to setup, simple to get that first newsletter to readers and simple to do over and over.  The end goal is getting content to readers and make it easy.

Using SimpleMailr you will be able to:

1. Easily add an existing list of email addresses.  If you know how to type an email address, copy and paste a list of address or upload an Excel file with email address in it, you will be able to get your list into SimpleMailr.  If you don’t feel comfortable with any means available..simply contact [email protected] and we will do it for you. 

2. Easily add newsletter content to get your first issue out the door.  The content of your newsletter is the heart of what you have to share, even if you are familiar with HTML you can add your text and not worry about the details.

3. Send it.  There’s really nothing more involved once you have something to say.  Once your ready, just press the send button and we will do the rest.

4. If you care about stats, stats you will have.  Know how many subscribers you have, how many were sent your content, how many received it and bounce details.  If you want it, we will have it.

I would really like to get feedback on how you use newsletter marketing today as well as how you would like to use it in the future.  What could be better?  What’s missing with your current solution?  Tell me about your ideal solution.  Feel free to send an email to [email protected] and start the conversation.  No obligation and I promise not to send any sales pitches your way.  You will be helping me build the best and most useful solution I can.

If you’re interested in following along to launch, you can sign-up to be notified right here:

 

Ratings or No Ratings, It Could be Time for A Change to Apple App Store Rating System

The latest episode of the The Talk Show, Gruber discusses his distaste for apps that ask for a rating. I found the view a bit disappointing. He has a lot of influence and is both a user and an app developer.

I can’t understand this adversity. A developer works hard and wants to know what a user thinks of their work. Is our time too much in demand to leave a bit of feedback? Ratings are supposed to have an effect how apps appear in the store, their rank and eventually their placement. An app without ratings is an app that may never be found, a possible lost soul.

I have responded in every way to the rating dialogs. If I don’t have time or have not had enough time with the app I will request to be asked later. If I just don’t want to rate it, I will respond with a “No thanks” but I do rate the apps I use and like.

This is but one problem with the App Store and users. Giving an application a rating or a review is not easy.  A user has to go to iTunes and the App Store, find the app and rate it.  It’s too much work.

David Smith has a thoughtful piece on his hopes for the future of the app store. I wish I had the same positive view of the future:

I want to believe that the App Store is a special place. I want for it to be the singularly best venue for customers to come and find innovative, well designed, quality software. Software that pushes the boundaries of what is possible and continually amazes and delights its customers. I want for there to be an aspirational pull upwards on my own development. I want to feel like I need to work extra hard to make sure my apps meet the high standards my customers have been trained to expect.

Gruber had a follow-up to David’s post agreeing the App Store and iOS should feel special.

It’s not just the App Store that we want to feel like a special place — it’s iOS itself. Using iOS, on both the iPhone and iPad, dozens of times every day, for stretches long and short, should feel like a platform in pursuit of perfection. Having a de facto standard practice where apps badger you at seemingly random moments with pop-up ads prompting you to rate them is in contradiction to this ideal.

I could be missing something but shouldn’t a user rating an application be helping filter out the bad apps? If a developer can’t ask for a rating, and we know users hardly go out of their way to rate an app, how can ensure we are getting the good apps? Maybe we should remove ratings altogether? Or it could be a time for a change to the way apps are rated; instead of a 1 to 5, a “Like” system such as on Facebook. You can’t dislike something on Facebook, only like it. A viable option?

I don’t think chastising a developer because they are trying to ask the user what they think is fair.  Accept this or don’t, kill off ratings completely or change the procedure.  I think what is there not doesn’t work and is too hard for users to take part.

Yep, paid apps are dead « Tapity

Jeremy over at Tapity had a great post yesterday talking about the very same topic I blogged about; paid apps. Tapity makes much of its living on paid applications like Languages, Grades and Hours and they face the reality.

Yep, paid apps are dead « Tapity.

By piecing together a few anecdotes I have heard, the top ten best-selling apps are selling roughly 25% as many copies as they did a year ago. If a #5 app sold 16,000 copies a day a year ago, #5 might only sell 4000 copies a day today. Now, that may still sound like a lot but apps are lucky to be #5 for a few days before dropping back into the abyss of obscurity. I’m not saying those statistics are by any means exact or even accurate but this is the kind of scale we are talking about. It is pretty drastic.

The volume just isn’t there anymore for paid apps. Premium apps that can sell for $5-$20 can probably continue to do well but the days of hit-based $0.99 apps are very much over.

His possible solution:

My thinking has changed quite a bit over the past few months and here is what I have come up with: we need to stop making apps and start making businesses.

Turning an app into a business? He explains it exactly as I have been telling those that will listen:

Hours is a perfect example. The old thinking goes like this: sell Hours for a few bucks, try to have a big launch. Rinse and repeat for updates. Since we’ve learned some things about launching great apps, we can probably do fairly well with this model and make, say, $100k.

That would be considered a successful app. But $100k isn’t enough to support a business like Tapity. It’s not nearly enough.

But what if we think bigger? Yes, release the app and sell a lot of copies but don’t stop there. Use that to prove to big companies that Hours is the absolute best time-tracker out there, hook into the back-ends that those companies use, and sell it to them at the corporate level for big bucks. Build some web and Mac integration. Maybe even hire a small salesforce. Make it a company.

Yes, yes and yes again…thinking out of the app box that has become warm and comfortable to making our apps into a real business with the actual app just being an integral part of it.

Jeremy, how about a nice SaaS app to collect all those entries from Hours for companies to use?  You can charge monthly, nice recurring revenue instead of that terrible one-time app charge.  And just think, you’re adding a ton of value.

Digging the Gold from the Apple App Store

It’s really hard to make a living in the Apple App Store. It’s not impossible but neither is winning the lottery. People who aren’t developers don’t understand how hard software is to create and because of the Apple-influenced ecosystem, they expect software will be cheap or free.

I have been thinking about how to be profitable in the App Store or better to avoid it altogether. I’ve discussed this with developer friends and it seems to be a challenge we all face today. Times are changing and in order to thrive we need to adapt.

Oh the Choices We Have

Today we have mainly 3 ways to make money in the app store:

  1. Conventional purchase, typically starting at $0.99 and ranging up to $4.99. Users seem to hate to spend even $0.99 when there is an acceptable, free, alternative.
  2. Advertising – display ads in your software and get paid when a user clicks on the ad. If your sales are small, there aren’t many people to look at these ads and less to click.
  3. In-App Purchase (IAP) – this seems to be a valid alternative to asking users for upgrades. IAP allows developers to bundle features and offer users these features for a fee.

IAP is an approach I am considering for my current apps and future ones. The idea would be to give the basic software away and charge for “Pro” features.  These pro features need to be real value to the user, no just take a crippled lite version of the app and enabling features users expect.

I have experimented pricing for my apps. My main app is Palette Pro, started out for $1.99 and did fine at release. I later changed the price to free for a short period of time to test the results, which were astonishing. Downloads for the free app was 1000x that of paid. This is pretty powerful and says a lot. Just like most developers, I can’t work for free.

Joel Spolsky from Hacker News:

The only business models I want to work on any more have some mass-market component that is absolutely free, and a niche companion product that makes money off of the exhaust fumes of the mass-market component.

The last two businesses I started are Stack Overflow, which is free, where the careers business on the side makes money on the small fraction of Stack Overflow users who are looking to get better jobs, and Trello, which is free, but the business of providing administrative tools to large organizations using Trello can sustain the whole business.

This is more than just “freemium” or “advertising-supported.” Freemium and Ad-supported business models are special cases of this general model. The real insight is that the free product has a chance to reach an enormous audience which provides distribution/advertising/marketing making it trivial to go to market with your paid product.

What Marco is reporting here is that the old-fashioned “make something and get people to pay for it” business is much harder to pull off and likely to always be left in the dust by someone making the same thing for free, getting 100x the user base, and getting 1% of them to pay for some value added feature.

Upgrades

Apple has so far refused to listen to the developer community for app upgrades. Today, when a developer releases a new version of their app they are not compensated. Small updates are fine and expected, but full an upgrade that takes developers weeks or months are hard to justify spending the precious development time and see no immediate return. If a user purchases an app, they receive free-for-life upgrades. 

The only way today to get paid for upgrades is to create an entirely new app in the app store. People have to pay the full-price for the mew features. This is great for developers but not appreciated by users. Realmac Software, developers of the Clear to-do app for iOS and the Mac, attempted this recently and it was not well-accepted. So, Realmac back peddled on their decision.

David Smith has a great episode of Developing Perspective where he talks with a Clear user (his wife) about her thoughts on the Clear upgrade attempt. If her thoughts represent how most users view software on their mobile device; upgrades are not worth pursuing.

Personally, I think this is a great way to get paid for upgrades. Users don’t have to buy, if their current version does what they need then just keep using what you have. This is how software has been sold over the years; you have version, here’s an upgrade, don’t buy it if you don’t want it. Users don’t favor this approach.

Marco Arment recently discussed his new podcasting app, Overcast, on his blog and thoughts on pricing. He’s right:

I’ve gone back and forth on what Overcast’s business model should be. I’m definitely charging customers directly (rather than venture-capital or ads), but I’m still debating where, how, and for what.

I’m sure of one thing, though: the market for paid-up-front apps appealing to mass consumers is gone. If you have paid apps in the store, you’ve probably seen the writing on the wall for a while.

That model made sense when there were fewer apps available, but now that there are plenty of free and good-enough versions of almost anything, it’s a different game. Apps targeting niche markets can still find enough paying customers to stay alive if they’re much better than any free alternatives, but the number of apps in that situation is always shrinking.

I don’t think we will see an upgrading pricing structure any time soon from Apple.  The company wants apps to be free and let developers figure out how to run the business side of things.

The Gold at the End of the App Rainbow

The art of pricing combined with making a living with mobile apps has been on my mind for a long time.  Recently my thoughts have become a bit more tangible. The reality is, most apps will be free.  Most people with make money giving their applications away, while getting the most attention,  then offer premium services with In-App Purchase.  

One aspect I haven’t mentioned but believe is probably the best way to realize the value of mobile applications is to offer applications for free but consume a paid backend.  A Software-as-a-Service (SaaS) backend is offered for some monthly fee and the mobile application is simply a client of the SaaS app, just like a web browser.  The beauty and simplicity of this approach is that it works for apps in the Apple app store but also on Google Play and the Windows Store.

It’s interesting where this is going but things are pretty clear; developers need to change their approach to how they earn their living in mobile.

JOBS

Jobs

I don’t usually post about movies, mainly because most movies these days really suck and aren’t worth the time to even say I saw one.  I did take in the new JOBS film with Ashton Kutcher.  I really enjoy the movie.  It brought back a lot of memories of how the industry was back in the day and how it has evolved since then.  It was truly an exciting time and I hate to admit, a far more exciting and exhilarating time than today.  

I’ve heard a lot of criticism leading up to the movie, both about the content and Kutcher’s portrayal of Steve so going into the movie my expectations were not very high.  I have followed the creation of Apple, and many tech companies for that matter, since I got my first computer in the early 80’s..so I’m very familiar with the storyline. 

I was pleasantly surprised by the movie.  It was just over 2 hours and I found myself entranced by the film.  I thought Kutcher did a great job of becoming Steve Jobs, from his facial mannerisms, the looks, personality (maybe a bit nicer) to his walk.

Watching the feedback this weekend I have heard much about how the story wasn’t told accurately and various aspect exaggerated.  The fact that it was meant to honor Steve and Apple as well as entertain, should be obvious it is not a documentary.

Apple fans should enjoy the movie and avoid the criticism.  My daughter and I thoroughly enjoy the story and would/will see it again.  It was a trip back in time when technology seem magical and revolutionary.

Vesper Quickly Becoming a Valuable Case Study

When I first heard about Vesper, a note-taking application for $4.99 that only runs on the iPhone, I was a bit skeptical.  Vesper comes from Q Branch, LLC and consists of some fairly high-profile people including: John Gruber, Brent Simmons and Dave Wiskus.  My gut told me these guys are leveraging their Internet fame to sell a lot of Vesper.  I believe my gut was very wrong.

The trio appeared on an episode of the Debug podcast and John discussed this very aspect of marketing Vesper.  He pointed out their fame would only take them so far and fame alone will not make this a successful product.  In order to build a successful business from Vesper, they would need much more. This was the turning point in my thinking and John was exactly right, they need to create a great product people will want and only then will they gain the momentum they want.

Since the release of Vesper, I’ve seen consistent discussion about the design and some of the decisions which went into its features.  We can all speculate on it, but fortunately the Q Branch team has been taking it further with a level of transparency we don’t usually see in a high-profile iOS application.

Vesper is an application we can all learn from, starting with design to the thought process of feature implementation.  The team is doing a great job of helping us see their process from detailed design discussions to open sourcing code they use.  I hope they continue the level of transparency with the dialogs they have, I know I personally address they questions myself and often times don’t have an echo chamber to help me out.  I often look at a good application and wonder how or why something was done.

Here are a few of the nuggets of information we don’t usually see, but are so valuable:

How to Make a Vesper: Design – a great view into the history of Vesper design discussing all the different aspects of what goes into design.  Each aspect of the application design is discussed, what made it in and what did not. 

Vesper is opinionated software. Every interaction, pixel, and line of code was carefully considered, and no work was too precious to throw away. I’d like to share some history of how Vesper came to look and feel the way it does. 

You can learn a ton about design, especially if you are not a designer and may not be aware of all the things needing consideration when building a beautiful application.

Open Source: DB5 – at times it becomes difficult to effectively work with non-developers on a project and collaborate in a positive way.  DB5 is a simple idea solving a common problem in an elegant way.  The Vesper team releases their tool to everyone who may face a similar problem.  It’s open source so anyone can make it even better.

Brent Simmons Gists – a nice collection of code from the Vesper developer, someone who is a very experienced Objective-C developer. 

Technical Notes on Vesper’s Full-Screen Animations – a detailed look on animations, comparing the standard way most developers do it to how they did it with the logic behind the decision making.  This is how a regular application can be outstanding, paying attention to these kinds of details reveals the difference between an artist and a laborer.

How should you handle beta testers for you application?  Lots of ways to do it but this is how Vesper does it as explained by Brent Simmons.  Being very open about the tools that worked for a particular style and project is always very nice to know.

No developer is proud of a bug in their creation and most of us go to great lengths to hide the fact that they exist.  It’s only human nature to not want others to know we have failed in some way.  Not surprising, the Vesper team is open about this aspect too

Here’s a bug in Vesper. You can reproduce this easily.

  1. Start dragging a note from right-to-left to archive it.
  2. Before you let go, take another finger and tap the hamburgrabber button in the top left to open the sidebar.

Note that the sidebar opens and the note is still in a partially-dragged state. That shouldn’t be, but I didn’t think of it when I was writing the code.

You can figure out why the bug exists. When I’m writing a feature, I don’t necessarily think of all the interactions with all the other features. I try to, but it’s easy to get overly-focused.

I bought Vesper *because* of the openness of the team and I want to witness the evolution of this application.  It’s refreshing and rare to be told a story you can witness about the crafting of a product.  The Vesper story is just that, the story of crafting a great application.  We are often pushed or expected to be producers, our parents and grandparents were the crafters of our time, proud of the things they created.  It is time we show that we are crafters too.

The openness and transparent style of the Q Branch team seems like a winning approach.  It will at the very least continue and grow the discussion of their application.  If people are talking, they are probably buying…like I did. 

Let’s hope for more thoughts and reasoning from these guys in the future.

Feed Wrangler is My Go To RSS Reader Platform

Colorbanner 2x

July 1 is fast approaching and Google Reader is shutting down.  Many people in the world use this service to read and sync their RSS feeds.  When I heard it was shutting down I was a bit annoyed but not surprised, but today I am anxious for it to shut down so people will stop talking about it.  Google Reader, it’s been nice but not real nice.  Goodbye!

I have found a paid service I am happy to pay for and support, Feed Wrangler by David Smith.  Feed Wrangler costs $19 per year and it developed by someone I believe will do his best to be around tomorrow.   I have officially dumped Google Reader about a month ago and been using Feed Wrangler ever since, and I could not be more happy.

The Apps

Out of the gate Feed Wrangler has a web site that can be used to read posts, mark them read/unread and add to Instapaper.  It works very similar to Google Reader but with *much* cleaner interface.  I never used Google Reader this way, I always used some third-party apps in my Mac, iPhone or iPad.

I have used a handful of client applications for Google Reader over the years and settled on a couple that worked really well on my Mac and iPad.  When I heard about Google Reader shutting down my first concern was what I would use for applications.

Feed Wrangler has free applications for the iPhone and the iPad that work really well.  I found a few little UI bugs or inconsistencies that I needed to get used to, but nothing I was unable to live with.

Thanks to the great API, third-party apps are starting to pop-up with Feed Wrangler support.  Mr. Reeder for the iPad, and most important to me is ReadKit for the Mac.  Both of these applications are fantastic and I am using them now.

The Syncing

The main part of what I consider the syncing platform is the backend web site and API which helps keeps the applications knowing what’s read and what has yet to be read.  This is transparent and should be, I don’t need to know the details nor do I care.  I just want to be able to go from device to device and not have to miss an article or mark something read more than once.

So far, it just works.

The API

One beautiful part of this platform is the open API for developers so they can create any number of client applications.  Did I mention this is a supported and nicely documented API?  Unlike what Google Reader had offered, this will be a pleasure to write application for.

As someone who consumes API’s for a living, the style of the documentation and examples is a lesson other developers should follow.

Finally

You have more choice popping up now that Google Reader is shutting down but David Smith has done some really nice work so far and I can only suspect he will new features all the time.

I am very happy and think Feed Wrangler is worth checking out.