Category Archives: Uncategorized - Page 2

Making theater-style popcorn

Something different than my usual computer-related posts…

For a lot of people, one of the best parts about going to the theater is the popcorn. A while back, some of us at work figured out how to make similar-tasting popcorn, and I’ve since bought a similar kit for my parents – they love the stuff and won’t go back to microwave popcorn.

Making this popcorn is fairly easy, and not terribly expensive – although the machine itself involves a small upfront investment. Here is what you need:

1. Popcorn Machine

Technically, you can do this with a pot on the oven, but the machine is much easier and more fun! They cost $150 – $200.

2. Kernels

Nothing special here.

3. Coconut Oil

This gives the popcorn the rich flavor. Costs about $24 per gallon, which should give you hundreds of batches of popcorn.

4. Flavacol

This gives the popcorn the salty taste. $6 or so for a carton that should last for a hundred or so batches, depending on how much you use.

5. Butter-flavored topping

You can add this on after popping the popcorn.

How to make it

1. Mix the following in the kettle:

1/2 cup of kernels
1.5 – 2 tablespoons of Coconut oil
1 teaspoon of Flavacol

You can alter the amounts of Flavacol and Coconut Oil to suit your taste. Some people like it a bit saltier (more flavacol), others like it more moist and richer (more coconut oil). TurnĀ stirrer and heating element on, then turn off the heating element when you start hearing kernels popping only every second or so. Let it stir around for another minute or so, then dump the kettle.

Then add the butter-flavored topping (don’t use real butter) on if you want – it tastes fine without it, though, so it isn’t necessary unless you like the extra buttery taste.

You can get most of these at your local specialty food store, or via Amazon at the links below:

1. Popcorn machine

2. Kernels

3. Coconut Oil

4. Flavacol

5. Butter-flavored topping

 



Ad supported vs $.99 – My experience

I love football, and I can’t tell you how excited I am that it is back on this week. I love playing fantasy football even more, and have even made an iPhone app for fantasy football drafts the past few years.

This isn’t my day job, and I know I’ll never get rich doing it. My main goals are to get some more experience developing for iOS, earn back my expenses, and help pay for NFL Sunday Ticket.

Last year, my app was sold for $.99, and I made a small, but reasonable amount of money (something between $400-$500). This year, I decided to see what the results would be like if I offered it for free, but monetized it using advertising. At the last minute, I decided to make another version that cost $.99, but was identical except for the fact that it lacked ads – ads are sometimes kind of annoying, and as a user I’ll often opt to pay $.99 rather than deal with them.

Now that the fantasy football draft season is over, I thought it would be kind of interesting to take a look at the results. The limited shelf-life of this app (drafting season is at most 2 months long, and the average user won’t use it more than a few hours per year) makes a less than ideal case study for ad-supported vs paid, but I think there is some interesting data anyway. So, here is some stuff I learned from this:

1) Free apps get downloaded way, way more than even $.99 apps

This is obvious, of course, but the magnitude of the difference is worth pointing out. The free version of my app was downloaded 11,450 times, whereas the $.99 version was downloaded only 239 times.

My takeaway from this is, if you’re going to try to sell an app that is going to have free competitors, you’re really going to have to work hard to differentiate yourself from the free versions. Free apps are simply going to eat up the lion’s share of the market.

2) But they don’t make nearly as much, per-user

Those 11,450 downloads translated into several hundred thousand ad views, resulting in total revenue of $111.25 for me. This is very slightly less than $.01 per download. The paid version brought in $167.34 from its 239 downloads – despite having roughly 1/50th of the downloads, it actually out-earned the ad-supported version by ~$55.

I almost certainly made a lot less money this year by offering a free version supported by ads – if even 2% of the users who downloaded my free version would have shelled out $.99 for the paid version had it been the only option, I would have come out ahead.

Had this app been something people would use year-round, it might have worked out a little better.

Lessons for next time

Despite this not being the ideal outcome, I learned a few lessons from this. Your app has to be immensely popular to make any sort of worthwhile revenue from advertising. I don’t think niche apps or apps with limited lifespans are good candidates for ad-supported versions. Also, I think there are probably better ways to utilize a free app than just throwing ads on it.

Probably the best use of an ad-supported app is to use it to promote additional, paid functionality. You could do this through In-App Purchase or by selling a different version of the app altogehter. The important thing is to differentiate the two beyond just advertising – the paid version should also offer more features. I would have done something like this, but I given the short life-span of these apps and my late decision to offer both versions, I didn’t have time.

Going this route gives you a chance to use your likely more popular free download as an opportunity to promote the paid functionality. Just be careful to offer enough functionality in the free version to make it worth downloading – free apps that are utterly useless platforms to promote paid functionality get (rightly) harsh reviews in the app store.

Graphical HTTP Client 1.0.3 submitted to the App Store

Graphical HTTP Client has been in the app store for roughly 2 months now and has had a few updates, but I haven’t quite added as much as I’d original hoped to. I’ve been able to devote more time to it recently and have just submitted 1.0.3 to the App Store. If history is any indication, it should be available in roughly a week. I plan to submit 1.0.4 in the next few weeks and generally update the app more frequently over the next few months.

On a side note – I spent some time playing around with NoSQL technologies (Riak and MongoDB, specifically) over the weekend. One interesting thing about the current crop of NoSQL solutions is that many of them offer an HTTP interface. I found this tool to be quite handy when interacting with Riak and Mongo, and I’m now brainstorming ideas for making it even more useful for working with NoSQL solutions – I am kind of excited by some of the possibilities! If this interests you at all, please let me know what ideas you have.

New Features in 1.0.3

1. Improved header entry

Probably the worst thing about Graphical HTTP Client in its current state is the way you enter and update request headers. It works, but it is kind of clunky and some unexpected things can happen if you aren’t careful. It turns out, a table view isn’t the easiest thing to work with for this kind of data. In 1.0.3, I’ve modified it so that there is a new sheet for adding and updating headers. Clicking on the + button will bring up this sheet, which lets you pick from a list of header names. You can also enter your own if it is a non-standard header. To edit a header, just double-click on its entry in the table. It won’t let you save over another header, which was a problem with the old table (actually, it would sometimes lock up if you even tried).

I think this is a much better interaction, and in future releases I’m going to make it even better. Here are some plans for this functionality for the next release:

– Documentation for standard headers, including example values.
– Some form of auto-complete for values (for example, if you select ‘Accept’ or ‘Content-Type’, we can give you a list of standard content types to choose from).

Also, double-clicking on a response header row will pop up a read-only sheet that shows the full header name and header value – this can be helpful if you are dealing with longer header values.

2. New Options

Above the ‘Request Headers’ box, there is a new ‘Options’ button. This will grow over time, but for now it has 4 options:

– Validate Certificates. True by default. This allows you to tell it to NOT validate SSL certificates, which can be handy if you are using self-signed or internal certificates for your sites/services.
– Follow Redirects. True by default. Unchecking this will cause the tool to stop when it encounters a redirect.
– Compress Request Body. False by default. If checked, this will compress the request body.
– Allow Compressed Responses. False by default. If checked, this will allow the server to send GZIPped responses.

All of these options are scoped to the request and will be saved along with the request, so if you load it back up later, it will remember your options.

3. Redirect Count

This is a fairly trivial feature that shows you the number of times your request was redirected. In the future, I plan to record information (url and headers) about each redirect and provide a way for you to view that data, which could be helpful for diagnosing redirect issues.

4. If the response is an image, it will show up instead of the text box

If we can see that the response is an image (by looking at the content-type header), we’ll try to show it instead of the blank text view. Not a huge feature, but if you are ever loading images via the tool, it will save you from having to save the image and go to another program to view it.

Bug Fixes

1. Fixed an issue where the ‘Copy to Clipboard’ functionality wouldn’t work properly in certain cases.
2. Fixed an issue where sometimes old data hung around when you loaded a request from a file.

What’s coming in 1.0.4

1. The ability to upload binary data. This is something I badly wanted to get into this release, but it will for sure make it into the next one.
2. More improvements to the header functionality, as mentioned above.
3. Also as mentioned above, more information about redirects.
4. The ability to set preferences for certain things.
5. It will save your last X number of URLs, so you can re-use them easily.

1.1 and beyond

1. The #1 feature folks have requested is the ability to use OAuth integration. This is useful for working with services like Twitter.
2. Better formatting for non-JSON responses.
3. Color-coding for response bodies (ie, JSON and XML).
4. The ability to paste in a CURL command and have it be parsed into the tool. This was suggested by someone on the suggestion forum, and once I went through the Riak tutorial, I realized how handy it could be.

Thanks to everyone who uses this tool, has provided feedback, and left ratings/reviews on the app store. If you have feedback on how this tool could improve, don’t hesitate to let me know.

Software Patent Insanity – When will it end?

I’ve been sick today, and so I’ve been laying in bed watching TV and using my iPad for most of the day. As I sat there, I couldn’t help thinking “I’m so grateful for the brilliant insight and tireless effort of Dan Abelow, who has made it possible for me to take my railroad baron skills in Ticket to Ride to the European theater, by way of In App Purchase.”

Actually, though, I did read Fred Wilson’s blog post on how the current patent system, abused more and more by lowly patent trolls, is a threat to innovation.

This isn’t a new problem – I’ve had discussions about the problems with software (and business process) patents over a decade ago, and even then it probably wasn’t new. What is changing, however, is the willingness of patent trolls to go after smaller and smaller businesses, and the fact that technology is so much more a part of every day life for everyone today.

Before, patent suits were largely behind-the-scenes affairs between big companies that resulted in boring settlements or cross-licensing agreements. Or, as I’ve seen firsthand, the threat of patent lawsuits prevented small startups from receiving financing. Unfair and a huge impediment to innovation? Yes. Exciting and interesting to the average American citizen? Not really.

But as actions like the Lodsys suit against mobile apps that utilize in app purchasing become more common, the effects of a horribly-implemented patent system, abused by unscrupulous patent trolls like Lodsys, has the potential to affect the every-day lives of your average person – and perhaps shed some more light on the problem.

The scope of the Problem

The scope of the problem with software patents isn’t obvious at first, but it is an important part of realizing why they are such a threat to innovation and economic growth. Let’s go through a short little exercise –

Grab your smartphone or tablet if you have one. Scroll through the pages and pages of apps you’ve downloaded. Pop open your browser and look through the bookmarks and history items that contain all of your favorite websites. Look through the list of applications listed on your computer.

What do all of these have in common? The vast majority (if not all) of them violate one or more patents. Indeed, any marginally non-trivial app, service, or website probably violates dozens of patents.

Who are these people who have been providing you with applications or services chock-full of patent violations? Are they hardened criminals, numb to the harm they cause others? Or, are they shameless copycats who copy whatever they can find? Or, perhaps, they are hackers who’ve used their computer skills to steal secret designs from competitors?

None of the above. Most patents (especially the ones used by patent trolls) don’t exist as an implemented product, a documented library one can buy, or anything of that nature. They exist solely as one of millions of software patents filed with the PTO, written in legalese so heavy you or I would have a hard time knowing what they are describing.

Figuring out which patents your technology violates is so expensive and time consuming that it is effectively impossible for any small or medium business.

Think about that for a minute. Every small business that creates a technology product or service is sitting on dozens of bombs, any one of which can kill it. How is that fair? How is that good policy for promoting innovation and economic growth?

The worst kind of tax

When it comes to talking about economic growth (or lack thereof), it is hard to get very far without talking about the economic impact of taxes. Patents are a form of a tax, but they are the very worst kind of tax – a tax that is unpublished, seemingly random, and can wipe out your business.

The worst part is that for many of the small victims of these patent trolls, there is very little that can be done to fight this government-enforced monopoly – the very act of defending themselves will at worst case leave them bankrupt, and at best case cost countless hours and tens of thousands (at the very least) of dollars merely to continue to be able to exist.

It isn’t a bad business model – document some basic and broad idea, wait for others to come up with and implement the same idea, then sue them for a percentage of the profits.

Arguments for the patent system

There are lots of arguments for some form of a patent system. The main one is that if I think someone is going to steal my idea (which presumably took a lot of work to come up with), then I won’t bother coming up with new stuff because it will be hard for me to make money off of my work.

As a society that very highly values competition, we are willing to effectively kill competition by granting a monopoly on an idea in exchange for the value of someone coming up with it. This requires 2 things to be true – 1) Your ‘idea’ must be genuinely novel and take a lot of investment to come up with, and 2) The only way you were willing to invest in coming up with the idea was if you were granted a temporary monopoly on it.

A government-enforced monopoly is a pretty drastic – and potentially harmful – thing, so if we are going to buy into that concept we’d better be getting a lot out of it. As I’ll try to explain in the next few sections, I don’t think we are getting even close to enough out of the deal (at least with regards to software patents) to make it worth the cost.

Necessity, the mother of invention

Software development, as a profession, is largely about coming up with solutions to problems. For a given problem, there are generally only a handful of reasonable ways to solve it, and developers independently working on a similar problem will likely come up with generally similar solutions.

If you were to get 100 developers who were ignorant of the Lodsys patents (which, until Lodsys began firing off lawsuits, could have been pretty much any developer) and tell them you need to be able to sell expansions of your game to your users, and give them each an afternoon to come up with a rough solution, you’d likely get back ideas that could be grouped into half a dozen or so similar distinct ideas. Of those half-dozen distinct approaches, at least a few of them would probably violate the Lodsys patents.

The fact is that most of us solve similarly-difficult problems on a consistent basis – it is part of our job, and it is part of the reasons software developers are compensated somewhat more than average. The business side of the organization comes to us and says “We need to be able to do X.” So, we sit in front of a whiteboard for an hour or whatever, and then start implementing it.

Most of us don’t think “Hey, that’s a good idea! I should write my name on it and send it to the PTO so nobody else can do that without my blessing.” If we’re nice enough (and/or our egos are big enough), we’ll even write about it so others can use our idea.

Some people, however, feel like every idea they come up with is special and that nobody else should be able to do something like it unless they first pay for a license. Those people are assholes.

The cost of an idea

When I look at patents involved in some of these lawsuits, one thing almost always jumps out at me – once you get past all the lawyer-speak and understand what the patent is describing, it becomes clear that there wasn’t a lot of work involved in coming up with the idea. In fact, I wouldn’t be shocked to find that the effort to file the patent significantly outweighed the effort in coming up with the original idea.

If your patent is for a medication that your company spent years of effort and billions of dollars to research and produce, I can get behind patenting it. If your software patent describes something I wrote in High School using Perl, I’m going to have a hard time accepting your idea as a patentable one.

Counterpoint: Open Source Software

Open sourcing your software is pretty much the opposite of patenting it – rather than claim a monopoly on my idea, I’m going to go to great lengths to give it away to others so they can use it. It is a powerful counterpoint to the argument that patents foster innovation.

Go back to the original exercise I had you do earlier. Now consider this – all of those apps, services, and websites most likely rely heavily on open-source software (yes, even iOS uses plenty of open-source components). This simple blog relies heavily on open-source: The software used is WordPress – an open-source blogging platform, which is written in PHP – an open-source programming language. The content is stored in mySQL – an open-source database. All of it is running on Linux – an open-source operating system. To write this post, I’m using Chrome – an open-source web browser, which is running on Mac OS X – an operating system that relies heavily on open-source components.

Even you – one of my 3 or 4 readers – are almost certainly utilizing a wide array of open-source software to view this post.

The fact that open-source software plays such a pivotal role in everything we do is clear, convincing evidence to me that we can have invention and innovation on a breathtakingly large scale without the need to patent every idea we come up with.

The ‘small inventor’ myth

The final defense patent supporters like to throw out is a hypothetical one – patents are needed to help the small inventor who has his ideas ripped off by a big, evil corporation. I have to ask – how many times has a small inventor ‘invented’ some software and successfully used a patent to keep a big corporation from stealing it? We have a long history of patent trolls abusing software patents, but have we ever seen someone legitimately use one in this way? I haven’t.

Conclusion

So, to summarize – most software patents encapsulate something that an average developer could reasonably come up with on their own, are overly broad, and don’t typically represent a large amount of investment. The people at the PTO should hate themselves for approving them. Even worse – patents don’t even seem to be required to get people to innovate and invent new software. So why are we continuing to allow them?

A lot of people talk about half-measures that could be used to improve the patent system, while still allowing software patents – and a lot of the ideas are decent, but come with their own set of drawbacks.

The real thing that scares me, though, is the fact that much of the damage has already been done. Millions of incredibly simple, overly broad software patents already litter the landscape – much like how cluster bombs and land mines make an area unsafe even long after the conflict has been resolved. Even if we were to stop issuing software patents immediately, the ones already issued are broad enough to hinder innovation for the next decade.

How will we get out of this mess we’ve allowed to happen? I don’t know. But like Fred Wilson said, enough is enough. At some point, this madness has to end.

New Mac OS X app released – Graphical Http Client

I’m a huge fan of the app store model that has sprung up over the past few years, and I Apple’s introduction of the iPhone App Store may have been more influential than the iPhone itself. Part of the reason I like it so much is that I think it is a good business model, but it also brings back memories of my Dad and I making applications and sharing them via CompuServe and AOL message boards when I was in Jr High. It is pretty cool to build something that entertains or helps thousands of people across the world (and make a few bucks to fuel your computer habit in the process!)

Nostalgia aside – I’ve released a new Mac (desktop) app to the Mac App Store called ‘Graphical Http Client’. This is a developer tool aimed at helping developers test and interact with REST-based services. Typically, when experimenting with or testing these services, you’ll use a command-line tool (like curl), access it with your browser (if it is a really simple GET request), or write tests to work with these services. My software aims to make this interaction somewhat easier. Some features include:

– Perform any HTTP method (GET, POST, PUT, DELETE, etc..)
– Ability to set request headers
– Ability to set authentication (Basic or Digest)
– When you perform the request, you’ll see the HTTP status code, how long the request took, the response headers, and the response body
– Nice formatting for requests that return JSON
– Ability to view HTML responses in a web view
– You can save the response body as a file (useful for when it returns binary data like an image)
– You can also save your requests and open them up later to save time
– Plus a bunch of other stuff

You can view it on my website here, or directly on the Mac App Store.

If you do download it, please leave feedback in the App Store and/or at my User Voice site.