My winter vacation
11/25/2005
I will be out of town for the next week as I will be attending my best friend's wedding in Auckland, New Zealand. Even though my 21-hour flight itinerary is a bit hectic, Los Angeles to Auckland via Seoul (South Korea), the experience is going to be worth it. Planes aside, I am sincerely happy to be visiting one of the most beautiful places on Earth and celebrating with wonderful people. Cheers and happy holidays to all.
Artist Collaboration Makes for Good Times
11/23/2005
This following photo just made my day:
The Foo Fighters and Weezer recently wrapped up their 2005 tour. I was fortunate enough to attend the Long Beach concert (first night). Of all the extensive photo galleries that I've seen, this particular snapshot is my favorite (via Wikipedia). An acoustic Dave Grohl and electric Rivers Cuomo battling each other on stage looks great, doesn't it? I hope the audience was enjoying the spectacle: two incredibly humble artists doing what they do best. I wonder what song they were jamming out to. My guess? A Foo Fighters cover of "Big Me" (something that happened more than once during the tour).
iTunes, Meet Variable Pricing
11/23/2005
Here's an excerpt from this rumor about Apple increasing iTMS prices:
There is a common understanding that we will have to come to a variable pricing structure. The issue is when. There is a case for superstars to have a higher price.Let us suppose that [insert popular emo artist here] is releasing a new 12-track album next week. I'm using 12 because heard somewhere that 12 was the average number of tracks for pop artists. Typically, their album goes for $16.00 at a physical retailer, roughly $1.33 a track. Under iTunes' current pricing scheme each track roughly costs $1.00. That means I'd incur an estimated savings of $4.00 by legally downloading the album. Hooray!
But wouldn't this hurt the artist? Well, it depends if they can move more units through the iTMS. It's commonly known that "tweeners" typically download singles whereas hardcore fans go for the album, the bonus disc, and then some. As an example, the recent Weezer album entitled "Make Believe" sold less than a million copies physically yet the album's first single "Beverly Hills" sold more than half a million copies through the iTMS. I guess there are a lot of tweeners or "light fans" out there.
If Apple wants to increase the price per track of this new album to match the $16.00 store value, they'd have to do so by 33%. Holy cow Batman! While it's relatively small in the scheme of things, it is a hike that might deter consumers. Apple probably knows this and will still try to undercut retail chains by at least a couple bucks. If there's an increase, the new price per track will most likely fall between $1.00 to $1.15, which would price this particlar CD at roughly $14.00. I'd still save $2.00 through downloading the album. Light applause.
I suppose this variable pricing will help artists like Weezer and one-hit-wonder artists that are never heard from again. At the other end of the spectrum, it will keep indie albums at a more "pragmatic" value. From a business point of view, the band that I'm in should not be demanding $1.00 a track, but really $0.20 a track (is there a way to calculate an indie band's net worth?). However, as a musician I can always argue that you can't price art. I can see this issue being debated both ways.
Hopefully this is just a rumor and nothing to start panicking about. Perhaps we'll hear about this at some upcoming Apple conference or press event. I just wonder how they'll convince swarms of music lovers that it's "cool" and "hip" to increase prices.
Web services and the piggybacked economy
11/16/2005
We rely on other web services, but what would happen if the del.icio.us API would go kaput? Generally, what if the API for [insert popular web site here] experienced downtime or even permanent loss of service? If you take advantage of these development tools, you have got to plan for the worst operationally and programatically.
I'll use my friend Justin as an example. Recently, Justin has established a business (OpenYard) that utilizes the Amazon API. His revenue model is completely dependent on the API's functionality, including retrieved data. Well Justin is not a pioneer in this segment. Since plenty of people (I know I can think of at least three others) are using the Amazon API to make a couple bucks here and there, I've started to identify this group as its own piggybacked economy. Interestingly, there is an unspoken and implicit risk that Amazon could pull the plug or reduce the functionality of the API. While it's not likely to happen, you still have to plan for failure.
As a developer who's worked with many APIs in the past, I like to put out two simple points to remember every time you think about using a web service:
- While you may influence the content, you have no control over the gateway. Flickr fits this case quite nicely (note, the Flickr API has been stellar thus far). You upload photos, add your descriptions, and compile photo albums. That data is yours. However, since you are storing it remotely, you are at the mercy of Flickr's service being active or inactive (up or down), returned data that's well-formed or full of badness (strange character entities, poorly formed XML, etc.).
- If the provider stops, am I screwed? Remember Justin's case (using Amazon API to build a business) from above? Well, if Justin can't use the API for whatever reason, his business stops. Good thing he's got a full-time job! As they teach you in business school, try to overcome any dependency if possible.
PHP has its moments
11/13/2005
I've never really enjoyed PHP that much until this past week. I love the Smarty templating system, the PEAR libraries, and the GD bundle. However, the coolest thing about PHP is the ability to extend the language by programming and compiling C++ source code. Why would you want to do this? Well, C++ is faster.
I've been programming a homegrown collaborative filtering model, which you'll start to hear more about over the next few months. I started in ColdFusion and was disappointed. Things like 'while' loops (only in cfscript) and awkward array support (thinking that array[1] is the same as array[0] is lame) made programming a CFC difficult. Notwithstanding, the functions that I did end up testing responded quite slow. I knew it wasn't the hardware so I decided to whip the same set of functions up in Python. Sure enough Python was able to parse this large data-set of mine, roughly 10,000 nodes, exceptionally fast. Even though I could configure mod_python and wrestle with Apache configurations, I decided to give PHP5 a try.
I ported my functions and libraries from Python to PHP in a couple of hours. I was surprised by the results. PHP held its own against Python, being roughly 7% less efficient (time measured in seconds). This problem will be reduced as more application servers are added. Two cheap computers could sufficiently keep this PHP process running strong. However, I started thinking about Cal Henderson's (the Flickr development lead) talk about planning project scale from inception. While the PHP process runs fine, it could perform better. This is where C++ comes into play. Through a few Google queries, I learned about extending PHP. Note, this isn't something for the faint of heart or those not comfortable playing and deploying source. If you're on a shared host, you probably won't be able to get your provider to use your custom PHP - but this won't be an issue for your local development area.
Anyways, I fired up Visual Studio and have started the process of porting my library into C++. The last time I touched C++ was at least 4 years ago, so I'm going to be rusty. I've already found some great free e-books to help the re-learning process. Hopefully I will have some statistics that compare the PHP class and the C++ extension.
