The price if you order over the phone (and I think the price in stores as of now) is actually $5.50, which is still a lot less than what it costs through the site.
Here is a list of other charges/fees that you'll get if you order over the phone:
Handling: $5
Shipping: $4.xx for <4, $9.xx >5+
Basically if you order over the phone it costs you $15 or so, plus the inconvenience of having to wait on the phone, and verbally submit your credit card information and shipping address.
In the end, it really costs my customers $5 for the convenience of ordering online, through PayPal. Economies of scale let me process each order for less than what it would cost to order 1 at a time, so I can cover the final shipping cost on my end because of the savings.
I haven't had any complaints about price, but I did see a comment on Jackcheng.com comparing me to GM or Ford because of the price.
edit Here's the actual comment if you don't want to go hunting for it: "That's awesome that you take a $4.95 product and mark it up to $19.99. Do you work for Ford or GM or something?"
I've been in Buenos Aires for about 2 months now, and it's still hard for me to believe how ridiculous this situation is. Two examples from my daily life:
1) I take the bus every day, which only accepts coins. So, everyday I have to figure out how to get more coins. One strategy I tried was to forgo the convenient subway card and actually stand on line to pay for a single fare card every time I happened to take the subway. A huge pain, but in exchange for a 2 peso bill, I would get a subway ticket and a precious $1.10 in coins.
Only the ticket clerk at the subway stop I most often frequent stopped selling me single tickets. I would show my 2 peso bill and ask for 1 ticket, and he would say "No monedas" and wave me through the gate for free. Every day, the same thing would happen. Same clerk. Same 2 peso bill. No coins, and he would wave me through for free. This went on for 2 weeks.
You would think that I'd be pretty happy about this, but actually, it infuriated me. I really want the coins instead! Sure, I get a free ride, but now I've got to go buy a bottle of water and tangle with a kiosk owner to try and get change.
2) Paying cash at the supermarket can be glacial. They keep very few coins in the cash registers, so every time they run out of coins, the checkout clerk has to call for a manager, who has to go to the safe to get more coins, who then exchanges 2 pesos worth of coins for a 2 peso bill. Yes, that's right...they restock the coins in the register the equivalent of 60 US cents at a time!
What's really interesting about these coin shortages is that they are exactly what we should expect as governments have created monopolies over the manufacture of coinage. Central planning always leads to the systematic misallocation of resources, causing these nasty supply surprises which the government then proceeds to blame on other actors.
An unappreciated miracle of our world is how rare shortages are among truly free-market goods.
"The Big Problem of Small Change" offers the first credible and analytically sound explanation of how a problem that dogged monetary authorities for hundreds of years was finally solved. Two leading economists, Thomas Sargent and François Velde, examine the evolution of Western European economies through the lens of one of the classic problems of monetary history--the recurring scarcity and depreciation of small change. Through penetrating and clearly worded analysis, they tell the story of how monetary technologies, doctrines, and practices evolved from 1300 to 1850; of how the "standard formula" was devised to address an age-old dilemma without causing inflation.
One big problem had long plagued commodity money (that is, money literally worth its weight in gold): governments were hard-pressed to provide a steady supply of small change because of its high costs of production. The ensuing shortages hampered trade and, paradoxically, resulted in inflation and depreciation of small change. After centuries of technological progress that limited counterfeiting, in the nineteenth century governments replaced the small change in use until then with fiat money (money not literally equal to the value claimed for it)--ensuring a secure flow of small change. But this was not all. By solving this problem, suggest Sargent and Velde, modern European states laid the intellectual and practical basis for the diverse forms of money that make the world go round today.
Alas, I couldn't follow their math. (Maybe I should try again, taking more time.) But their historical examples were quite extensive.
I lived in Buenos Aires for four months at the beginning of the year and developed the exact same strategies. And the same thing often happened to me at the subway stations. I often resorted to buying some cheap piece of candy at a corner store to get coins.
It's amazing how you find yourself thinking, "okay this is $2.50 so if I pay with a five I'll get a 2 peso bill back and .50 in coins but if I pay with two 2 peso bills I'll get 1.50 back in coins."
P.S. check out 'Juana M.' definitely the best steak I had in the city. (Plus a real salad)
Greg Linden used to work at Amazon. From an older blog post of his:
"In A/B tests, we tried delaying the page in increments of 100 milliseconds and found that even very small delays would result in substantial and costly drops in revenue."
I find it immaterial considering the easier thing to speed up is the number of HTTP requests on the site, and that has clearly gotten worse over the years, not better. I pushed heavily to get HTML cleaned up and valid (showing an easy 10-20% reduction with HTML alone), reduce the amount of javascript, etc. It simply wasn't a priority. To be fair, at the time I was there the priority was to grow as fast as possible and deal with profits later.
What I thought was most interesting about the linked article was the charge that Apple has been misleading it's developers, not whether Apple's iPhone strategy is right or wrong from a business or technical perspective. At what point does putting the best possible spin on things cross over into outright lying?
Is it fair to characterize Apple's guidance to developers as misleading?
If so, will Apple's behavior eventually drive away developers, or can they always count on developers sticking around, so long as they continue to produce hot products like the iPhone?
One minor correction to your very helpful post: the scalability book you are referring to is "Building Scalable Web Sites" by Cal Henderson (not Clay Shirky).
There hasn't yet been a "first generation cloud computing automation framework", so it's kind of impossible to be building the "next generation". That first generation is pretty much what everybody in the field is working on (including my company).
But Vertebra sounds like an interesting approach for the applications where it fits. And repurposing an existing protocol for RPC is always interesting, they've chosen the surprising, and novel, XMPP (we use a light-weight RPC mechanism that runs over HTTPS that was already part of Webmin, with a fallback to SSH on instances that don't have Webmin or Virtualmin). And they're addressing a niche that no one else is addressing, which is Ruby on Rails in a cloud environment...it could be done with Amazon using SQS to detect rising "pressure" and ramping up new instances as the pressure rises and shutting them down as the pressure decreases. But, Vertebra being focused on RoR probably means that if you're building a RoR app, you'll need to spend a couple of days less time developing that aspect of your deployment. You still have to solve the database scaling issue, and the data sharing and state problems, just like any other large scale deployment...but one less thing to worry about is one less thing to worry about. (And nobody is going to solve all of those other problems automatically.)
Actually Vertebra is not tied to Ruby on Rails at all. Since the main communication is all XMPP based, any language that can speak XMPP that implements our protocol can become part of the XMPP cloud. Our first implementation of the agent framework is written in Ruby but I expect many more languages to be supported.We will be releasing at least python and erlang based agents along with our ruby agents. We will be releasing the whole thing open source once we have locked down the protocol and made it a XEP standard, so keep an eye on my blog if you are interested.
Also Vertebra is not just for server automation, it is a framework for distributed computation of many kinds as well as a real time application platform.
The discovery mechanism and Resource based dispatch will allow for applications to get a request, discover via a Vertebra call which backend is least loaded and offers the request processing you need and then dispatching said request to the proper backend. Also allowing for map/reduce and scatter/gather style programming.
I have many ideas of where to take this thing and I cannot wait to get it out in the open so I can see what other folks do with it.
"Actually Vertebra is not tied to Ruby on Rails at all."
Interesting. I just assumed because of the connection to Engine Yard, and you know what happens when one assumes.
"We will be releasing the whole thing open source once we have locked down the protocol and made it a XEP standard, so keep an eye on my blog if you are interested."
Will do. While we have our own implementation for solving quite a few of the common cloud infrastructure problems, we're also agnostic and configure dozens of other tools without feeling the least bit guilty about having multiple ways to do things (must be our Perlmonger background), and it sounds like you're addressing things that aren't in our current scope. (For example, we support Xen, VServers, Zones, and EC2, and S3 and ZFS...we're loco like that. We don't even care.)
If you use the Caps Lock key as CTRL, then it feels pretty awkward for me to type some key combinations (like ctrl-x or ctrl-c) and still keep my fingers on the "home row".
Do you just get used to this? Do you type ctrl-x with your pinky and ring finger? Or, do you shift your hand away from the home row and type ctrl-x with your pinky and middle finger?
Ran across this long after the fact, and I'm not even sure if you'll be aware I posted this, but...
I've been wondering the same thing, as C-x is used all the time and seems really uncomfortable. I've found one mention of it, so I thought I'd pass along Steve Yegge's opinion:
"Incidentally, if you want to fine-tune this tip to extraordinary levels, then you probably don't want to use your ring-finger for typing the x-key when you hit Ctrl-x. I use my left index finger, since I'm used to it that way, but you're probably better off using your left middle finger. The reason is that your hand isn't technically on home row when your left pinkie is jammed down on the Caps-Lock key that you've turned into Ctrl. The point is to use whatever requires the least amount of stretching, followed by the least amount of finger motion. You should experiment until you find what's most comfortable for you."
"Google App Engine's ability to scale depends on how much server resources Google is willing to dedicate to the task of running these applications. Google is not going to risk slowing down their primary services for a Google App Engine application. So their ability to scale could very well be less than other companies, we just don't know."
No doubt a $6/mo. account at Dreamhost will scale better than Google.
He is not saying that it will or will not scale better. He is only saying that we simply dont have data to prove that Google will scale better. People are invoking the Google brandname but a brandname shows almost nothing.
Normally, I would have agreed but in Google's case, there is so much evidence to believe they will do a better job. Scaling is their biggest technological achievement to date. The reason they are running away with products with such great performance is because of their success in getting things to scale very well.
This is just magical thinking. Google's services scale amazingly well because their hardware and software were optimized, for specific applications, by great programmers commanding large budgets. Google does not have a magic bullet that can make any app in the world "scale", they are not going to rent Steve Yegge to me for $14 per hour to help me design scalable apps, nor are they going to lend me an entire datacenter's worth of computers to ensure that my naive attempt to bubble-sort 1e6 database rows per pageview will "scale" out to 10 million hits per day.
Your Google Apps site is going to have limitations, it is going to have to pay to exceed those limitations, and it is going to have to be carefully architected in order to scale. The original poster notes, correctly, that half of Google Apps' limitations are restrictive compared to those of a $7-per-month web host, and the other half -- the ones that will make or break the value proposition -- haven't been stated yet.
Not really -- this is "it's less effort for them to deploy everything on their existing, robust tools" thinking. I personally don't second-guess it, because once a tool proves itself worthy at the GOOG, it tends to stick around for a long, long time. Some of my cave-man Python code is probably still kicking around in ops/SRE. (It's hard to write really bad Python, although there have been valiant efforts over the years, and we're sure to see many more)
Your skepticism is warranted, but I just think it's misplaced. The one thing that Google has proven they can do as well as, perhaps better than, anyone else is get tasks to run transparently across a whole shitload of computers and datacenters. Maybe everyone there is turning evil nowadays, I don't know, I can't know -- what I do know is that it would be more effort to turn around and fuck up the existing building blocks than to simply open them up (with appropriate restrictions) via GAE. That's all.
Normally I find your commentary extremely perceptive, but this time I think that you're off the mark. JMHO
nor are they going to lend me an entire datacenter's worth of computers to ensure that my naive attempt to bubble-sort 1e6 database rows per pageview will "scale" out to 10 million hits per day.
If the price is right, I'd bet you they would rent it... That's really what AWS is all about. Although it will be a while before the GOOG has entire excess datacenters' worth of capacity -- somehow, Google always managed to soak up all the deployed capacity and then some, at all times. As someone coming from a supercomputing background, I thought that was really fucking cool, because when you're deploying racks an 18-wheeler at a time, you might expect some lag between powering up and going to 1mW steady. Nope.
I've never seen a company that could scale infrastructure like Google, and I worked at IBM Microelectronics a couple years before GOOG, along with another one of the biggest websites on the planet, and deployed my own multihomed network in the interim (as mentioned elsewhere, one of my bigger triumps as an 'architect' was beating Microsoft at their own game with a staff of 4 people during that time). No one I have ever seen comes close to Google in terms of operational efficiency, and I've seen a lot over the years.
Your Google Apps site is going to have limitations
No shit, that's why it's free. I honestly cannot see how those limitations will include a lack of fault tolerance, the provision of which is their biggest selling point (IMHO). Everything else (again IMHO) pales in comparison.
The original poster notes, correctly, that half of Google Apps' limitations are restrictive compared to those of a $7-per-month web host
For certain conditions -- you can't be a Pythonista or the comparison goes out the window. Moreover, if you create several GAE accounts (do it! do it! Just because I worked there doesn't mean I don't support taking advantage of them), you now have a framework for freely deploying a bunch of pilot projects for $0 down and $0/month.
Just don't marry yourself to the Google toolset (Users, ObjectStore) too tightly and you get a LOT of good shit for free. AWS is more open and more loosely coupled, so for many (most?) non-larval startups it's probably the better choice at this point in time.
But if you're a cubicle dweller plotting your escape? FUCKING GO FOR IT, MAN! The price is right (free) and Django is an awesome framework for pilot projects. If you strike it big... well, burn that bridge when you come to it.
Oddly enough, I'm going to have to invoke DHH's "build first, scale later" maxim here -- "build first, limit lockin, migrate later" for many people. Not all, maybe not even most, but for individual developers with a little self-discipline, this is a HUGE step.
And (this is killer) nobody says you can't farm our your long-running jobs to AWS/EC2 and call them via REST from your GAE app. Just like the ticket for urllib2 support is mostly about RESTful auth and data transfer. A LOT of us want to decouple GAE from those bits -- instead of complaining, some of us are working on it, and it seems like Guido and others at Google are supporting the effort.
Never attribute to malice that which can be adequately explained by the GOOG's internal disorganization and 'organic' (to be generous) growth pattern. ;-)
Normally I find your commentary extremely perceptive, but this time I think that you're off the mark. JMHO
Why, thank you! In this case, my writing may be completely off base, but it has achieved its victory condition: It has drawn you out to provide a very intelligent level of argument. ;)
And I am operating at a severe disadvantage... all I know about Google (and about Python and Django, for that matter) is what I read in the papers. You really can't learn much about what's going on inside Google from the papers.
That's a big part of the problem here: with Google Apps the company seems to be gearing up to make a transition toward more transparency, but they're not quite there yet. I am fully willing to admit that Google's infrastructure kicks the butt of a $7 web host... once I know what I'm getting, what the charge is, and what the service level will be. I certainly agree that the various limitations we can see now -- Python only, limited static files, limits on peak bandwidth, no SSL for now, blah blah blah -- will all be forgivable, even trivial, once we have confidence that Google will deliver cheap scalability and rock-solid operational performance -- and once there are well-understood approaches and tools for deploying Google Apps without "marrying oneself to the Google toolset". But for much of their history Google's reputation has been kind of like Batman's reputation: They're known to be superheroes, they have many wonderful toys, they use them mostly for good and we're very grateful... but they operate in the shadows, and folks often complain that it's hard to get them on the phone to explain exactly why your pagerank just dropped by fifty spots overnight, or exactly how they control your ad revenue for false clicks.
I don't attribute any of that to malice, though. And it's early in the history of the beta of Google Apps (a real beta, not one of those legendary eternal "betas"), so we must be patient. Certainly your words are cause for optimism.
Have you gotten any pushback on your $19.95 price?