Comments on: iTunes Music Store contest http://www.chrisdolan.net/talk/2005/07/07/itunes-music-store-contest/ Ideas and tools to improve programming throughput. Wed, 20 Aug 2008 18:09:52 +0000 http://wordpress.org/?v=1.5.2 Comment on iTunes Music Store contest by: MattH http://www.chrisdolan.net/talk/2005/07/07/itunes-music-store-contest/#comment-17 Fri, 08 Jul 2005 20:43:35 +0000 http://www.chrisdolan.net/talk/2005/07/07/itunes-music-store-contest/#comment-17 "This assumes that no one else will try to do the same thing..." Like this? :) http://www.versiontracker.com/dyn/moreinfo/macosx/27314 “This assumes that no one else will try to do the same thing…”

Like this? :)

http://www.versiontracker.com/dyn/moreinfo/macosx/27314

]]> Comment on iTunes Music Store contest by: klang http://www.chrisdolan.net/talk/2005/07/07/itunes-music-store-contest/#comment-16 Fri, 08 Jul 2005 15:42:33 +0000 http://www.chrisdolan.net/talk/2005/07/07/itunes-music-store-contest/#comment-16 ..noting the "speed (up) of purchase" around each 100,000th mark would make predictions better, but I don't think there is a foolproof way of making sure that you will win ;-) ..noting the “speed (up) of purchase” around each 100,000th mark would make predictions better, but I don’t think there is a foolproof way of making sure that you will win ;-)

]]> Comment on iTunes Music Store contest by: Peter Erwin http://www.chrisdolan.net/talk/2005/07/07/itunes-music-store-contest/#comment-15 Fri, 08 Jul 2005 14:05:35 +0000 http://www.chrisdolan.net/talk/2005/07/07/itunes-music-store-contest/#comment-15 This assumes that no one else will try to do the same thing, which will tend to make predicting the right moment a bit harder: the purchase rate would shoot up right around the predicted time, thus shifting the actual time to something slightly earlier... Good thing this is nothing <i>I</i> have to worry about ;-) -- Peter This assumes that no one else will try to do the same thing, which will tend to make predicting the right moment a bit harder: the purchase rate would shoot up right around the predicted time, thus shifting the actual time to something slightly earlier…

Good thing this is nothing I have to worry about ;-)

– Peter

]]> Comment on iTunes Music Store contest by: Drew http://www.chrisdolan.net/talk/2005/07/07/itunes-music-store-contest/#comment-14 Fri, 08 Jul 2005 13:43:06 +0000 http://www.chrisdolan.net/talk/2005/07/07/itunes-music-store-contest/#comment-14 The real problem is that there is no way to have a program that purchases the songs; that has to be done through iTunes, for which there is no API, necessitating the use of a human to purchase the music. Furthermore, the rate that you show there is 23 songs/sec, so even if there were a manner in which the program could purchase music automatically, you have to think about it's accuracy and purchasing latency. Your purchase latency is at the very least the latency between your machine and the iTunes servers (50-250ms) but also any processing delays. To be safe, it's probably best to shoot to begin buying songs a couple of seconds before the predicted time, and to continue buying until you receive notification that the 100,000th song has been purchased (say, another few seconds). This leaves you with a window of 6 seconds (2 before, the predicted second, 3 until confirmation; just conjecture) during which you will want to buy at least 23 songs each second in order to have a 50% chance of winning if the 100,00th song occurs during that second. 138 songs is $136.62. Is that good enough for a 50% chance? If you are buying 138 songs that you'll enjoy, and you think that your program is good, sure, might be. The real problem is that there is no way to have a program that purchases the songs; that has to be done through iTunes, for which there is no API, necessitating the use of a human to purchase the music. Furthermore, the rate that you show there is 23 songs/sec, so even if there were a manner in which the program could purchase music automatically, you have to think about it’s accuracy and purchasing latency.

Your purchase latency is at the very least the latency between your machine and the iTunes servers (50-250ms) but also any processing delays. To be safe, it’s probably best to shoot to begin buying songs a couple of seconds before the predicted time, and to continue buying until you receive notification that the 100,000th song has been purchased (say, another few seconds). This leaves you with a window of 6 seconds (2 before, the predicted second, 3 until confirmation; just conjecture) during which you will want to buy at least 23 songs each second in order to have a 50% chance of winning if the 100,00th song occurs during that second. 138 songs is $136.62.

Is that good enough for a 50% chance? If you are buying 138 songs that you’ll enjoy, and you think that your program is good, sure, might be.

]]> Comment on iTunes Music Store contest by: klang http://www.chrisdolan.net/talk/2005/07/07/itunes-music-store-contest/#comment-13 Fri, 08 Jul 2005 05:55:00 +0000 http://www.chrisdolan.net/talk/2005/07/07/itunes-music-store-contest/#comment-13 It should be possible to make the program slurp up data and extrapolate at the same time, ajusting the winning moment at each cycle.... It seems I have something to do at work today ;-) It should be possible to make the program slurp up data and extrapolate at the same time, ajusting the winning moment at each cycle…. It seems I have something to do at work today ;-)

]]>