Saturday, February 27, 2010

Why Piracy is Sometimes Good For the Software Industry

This morning at the gym I started thinking about how nice it would be to be a Photoshop guru.

The ability to just have an idea of an image of design in your head, open up Photoshop and come out with a snazzy-looking result after a few minutes of hard work. It would be frickin' awesome. Unfortunately all the tools I really have at my disposal for design work are HTML + CSS. Bummer.

And then there's the cost.

A copy of Photoshop CS4 (the latest version in Adobe's suite) goes for $699 if you're buying it fresh off the presses. The extended version will burn a grand in your pocket.

That's way too expensive. Especially if you just want to play around (like I do). Which leads to why so many people download Photoshop off of Bittorrent. Free is free. Honestly, how many Photoshop gurus actually bought the damn thing when they were first curious about it? I doubt very many.

I don't know why this is what first came to me, but I thought for a second that maybe Adobe wants its software to be pirated. Look at it this way: maybe Adobe charging such an exorbitant amount for its software is just a form of price discrimination.

They know that businesses will fork over the price as long as its not ridiculous. Hell, if you're a design firm you need Photoshop. You bite your lip, buy the software, hire a great designer (who probably learned Photoshop off of a pirated version), and move on. It sucks, but no company wants to be using pirated software. It's just not a good idea.

If you don't have the money, you'll just download it.

Here's a little example to illustrate why Adobe wants people to pirate their software. Fixed costs for software production is very, very high (programmers are expensive ;) ). On the other hand, variable costs are basically nil (you're basically paying for the cost of bandwidth if its download only, and the cost of shipping otherwise). A software company can charge nearly nothing for software given that people will continue to buy it forever into the future.

Other products, like jet engines, have a high variable cost, so it would be pretty stupid to charge a penny for one. You'd go out of business in the blink of an eye.

Now let's imagine that Adobe charged $9.99 for Photoshop CS4. I would buy it without a second thought. So would maybe other people who wanted to get their feet wet in design. Flipside: Adobe now needs to ship 70 times more copies.

This is a bad business decision if more than 1 of 70 Photoshop installations are legal. I'm actually inclined to say that the number is higher. In the end, it's better business sense to keep the price at an astronomically high value and let the rest of us download the thing on Bittorrent. It's a small price to pay, but Adobe makes more money in the end.

What do you think?

Tuesday, February 9, 2010

Is the iPad a mistake?

The iPad was announced about a week and a half ago to great fanfare amongst both the tech community and the world at large. It has been hailed as the computer for people who don't know how to use computers.


What a thought.


I really applaud Apple for this achievement. They've really gotten close to pushing something out to market what I would like to call the "sexagenarian-proof computer". This will be the computer that will not longer be called a computer by those who use it. That's probably a good thing, because mostly everything about the iPad is antithetical to everything that computers have been up until today.


If you're around my age and ever had any interest in the Internet, you probably remember when you made your first website. You opened up your text editor, searched Altavista or Yahoo for "how to make a website", and were up on Geocities within the week.


I did this when I was younger, and one of the reasons I did do it was because the barrier to entry was so incredibly low. There was nothing stopping me. If I was a kid with an iPad, the barrier to actual development would be so high that I'd most likely not consider it.


If the iPad is a harbinger of things to come, I'll be very uncomfortable, mostly because the kid in me probably wouldn't have made that first website. From that first website came my first interest in programming, and then my interest in Java, etc, etc. Each step of the way requires that your computer be incrementally more capable. And tinkerable. Hell, I'd be a frustrated kid if I couldn't figure out how to write a program on my iPad. I'd be even more frustrated since it would cost $99 for my parents to fork over just so I could "play around" (that is the actual cost of the SDK for those who are interested in whether I'm simply pulling numbers out of my head).


I believe that computers are meant to be democratic devices -- machines that anyone can use and do anything with. If it ever gets to the point when our computers are owning us rather than the other way around, the iPad will have won. Let's hope it doesn't.

Monday, January 25, 2010

Querying For N Random Entities using the Appengine Datastore

First, this post is 100% programming related. So if you don't care about programming, just walk away.


Chances are that if you're a Python or Java developer, you've run into Google Appengine at one point or another. A perennial issue with the datastore is that there's no officially documentation on how to pull random entities from your database. Well friends, I'd like to let you in on a little secret for how you can do this.


It's quite simple, actually. Let's say you have a simple model, called Users. E.g.



Make another model called UserCount (this model will only have one entity, and the count will be equivalent to the number of Users that have been inserted into the database). Instantiate a UserCount entity with an initial count of 0 before you do anything.



Simple so far. Do something similar to this when you insert a User into the database.



To get random data, use Python's random module, and call the User's by their key names. Caching is recommended. You may want to do something similar to the below.



And that is how to get random entities from the Google Appengine datastore. =)

Sunday, January 24, 2010

When to buy airline tickets

This weekend I've been mulling over how annoying it was that there isn't really freely available data on prices for airline tickets. Farecast, the one site that I was aware of that did *something* like this, was purchased by Microsoft and is now a part of Bing Travel.


So what separates the market for airline tickets and others is that ticket prices are extremely sporadic from day-to-day and even by the hour. This makes getting a really good deal on airline tickets very difficult for the average consumer. There's only one participant in the transaction that gets a good deal, and that is the airline. Their pricing schemes are actually quite ingenious when you begin to think about it.


Typically, an airline will have multiple pricing ranges for seats on the same flights. That is, 10% of seats will be $50-100, 40% will be $100-$150, and 50% will be >$150.


The gist of price discrimination is that there are usually people who are willing to pay than you are for the same product or service. Instead of charging everyone a flat rate, a company will vary the price based on the customer. Simply put, movie theaters don't have senior and student discounts because they're particularly nice, they do it because they make more money this way =). See Wikipedia for more information.


Alright, back to the meat and potatoes. 


After some thought, I decided Mechanical Turk would be the best way to gather this info. So I got down and wrote a Python script that randomly generated 500 origin cities, destination cities, and dates within the next 329 days (it seems most airlines don't give price information past this amount of time). The cities were only the ones I was interesting in (Miami, LA, NYC, and San Francisco).


I set up the job, uploaded the batch of data, and salivated throughout the night. When I woke up today, I got down to analyzing the data.


Some interesting patterns emerged.


First of all, Wednesday is (on average), the most expensive day to travel, unless you're flying from LA, where a Thursday ticket will cost you on average $500 to Miami, NYC, or SF. Miami was the worst city to fly from, with the most expensive day costing a traveler about 564 buckeroos.





Here are average weekly ticket prices between the four cities over this year.



Prices appear to be highest for the next week, then hit a yearly low in late February, when the average ticket price hits $109.13. Cheap. Prices are a little unpredictable over the summer, hit highs in early July and late September, and plateau over the holiday season. We'll see how much of this is due to the day that this data was gathered.


How about cheapest airlines? Well, you may be surprised about this as well.
  1. Delta Air Lines, 100 tickets
  2. United Airlines, 62 tickets
  3. AirTran Airways, 54 tickets
  4. US Airways, 36 tickets
  5. Alaska Airlines, 27 tickets
  6. Virgin America, 20 tickets
  7. Continental Airlines, 10 tickets
  8. Frontier Airlines, 7 tickets
  9. JetBlue Airways, 7 tickets
  10. Spirit Airlines, 3 tickets
  11. Midwest Airlines, 1 tickets
  12. Other, 1 ticket
Southwest didn't make it *once*! Now that was a surprise.

This is only the tip of the iceberg. Over the next week, I'll keep listing HITs on Mechanical Turk, and should have some more robust data on *when* the best times to buy tickets are. Stay tuned...

Saturday, January 9, 2010

My Social News Escape: Day Four

Four days has gone by and I haven't visited Reddit, Digg, or HN.


When I originally started this experiment, I thought that by this time I would be struggling to make it through the day without a burning desire to start typing "redd" into my address bar. Strangely enough, this hasn't yet happened to me. In fact, I have basically forgotten about social news altogether and am have shifted over primarily to Twitter and Google Reader.


I've noticed that if you follow reliable people and subscribe to good blogs, your sources of information will usually be well-vetted and there isn't much of a need to "filter" the useless junk. I think that by the time this experiment ends, I may end up sticking to it.

    Wednesday, January 6, 2010

    My Social News Escape: Day Two

    I vowed on Monday not to visit either Hacker News or Reddit.com for a week starting from yesterday. And my god has it been painful.


    I can hardly believe it's already been almost 48 hours. What's most unbelievable to me is how much more "stuff" I have gotten done without the constant urge to check out what's going on in the social-news-o-sphere. In many ways I feel like I'm a little disconnected, but in other ways I feel completely free. 


    The Internet is addicting. Social news is addicting. The reason is simple. People want to be entertained and spoon-fed. We have become very dependent on having other people give us information...ANY information, even if it's completely irrelevant to our daily life.


    Some may argue (with good reason, might I add) that almost everything is relevant in some sense. We always have room to learn about the people around us and the events that are occurring. Unfortunately, though, the difference between news and entertainment has begun to blur beyond recognition.


    This is one of the problems with social news. Posts such as "What is something really embarrassing you have done, but never" are put right alongside posts like "IRAN: Video shows gunman opening fire on demonstrators, who fight". Who is there to separate the crap from the good stuff? That's right, YOU! BTW, I am not allowing myself to click those links. I found them through Google.


    Reading these submissions is time consuming, and so what usually happens is that even if you don't particularly care about an IAmA about a zookeeper, you'll probably find yourself clicking on the link just to see what all the fuss is about. It's so easy, right?


    Right, but there's a cost. There is an almost constant distraction and urge to just "click".


    Stop the clicking and start the doing. I guess that's the lesson for today.

    Sunday, January 3, 2010

    OpenID, Clickpass, web.py, and Python

    I just spent a few hours working on implementing Clickpass with my new project built on web.py, so I figured I could save everyone else some time by giving some tips on how to fast forward to the actual development of what it is you want to make instead of tweaking configuration files.


    OpenID is nearly ubiquitous at this point. If you don't think you have an OpenID login, you probably do and just don't know it. Google, Yahoo, Facebook, and others have already implemented the protocol into their backends.


    What does that mean?


    Well, for one, as someone who's starting a new website or a web application, you don't need to worry about storing passwords or causing potential users a small annoyance by having to fill in yet another registration form.


    This is how login works in an OpenID world: a user goes to a website and clicks a "Login with OpenID" button. They are then redirected to a choice of providers (e.g. Google, Yahoo) that run all of their user accounts as OpenID accounts as well. You click your provider (let's say Google) and are then asked one more time whether it's OK to login with Google. You click sure, and you're brought back to the website and, "ta da", you're now logged in.


    This all seems really dandy from the user's perspective. Unfortunately there's a ton of developer mumbo-jumbo on the backend side that will make most developers puke. You can read the specs if you'd like, but I recommend that you don't. Chances are that you won't be able to finish.


    As a consumer (website owner), you will need a way to authenticate users with OpenID. I chose Clickpass. They offer a nice interface with a couple of choices for providers. With Clickpass, you will need to make (at minimum) two URLs to facilitate the logins. One will begin the authentication process, and another will complete it.


    Now for the fun part: implementation. I can't give an example use in every language (that would just be a waste of time), but I can show you how this entire process is done in Pythonweb.py, and the python-openid library. If you want me to walk you through the entire installation process, let me know in the comments and I'll write a follow up post.


    Without further adieu, here is the working code. Be sure that you sign up with Clickpass and receive a site key. Replace all the variables with the appropriate values.