Can't believe the only examples and use cases are at the very bottom of the page in the testimonials.

Putting performance optimization hints in my presentation code feels wrong. I think I'd use a separate css file for will-change.

By what I'm reading you shouldn't have the property in a style sheet at all. The author implies that every usage of the property requires resources that are never released as long as the property is still active. The property in a style sheet will mean that the resources are never released.

Thus, the suggestion to use the property through javascript so that it can be applied and then removed. That just seems totally weird to me.

The project on github credits chessboardjs for the board editor. Quite related ;)

ChessBoard was built because the author of lichess.org contacted me about re-using some code from another project of mine.

I had always wanted to build the board as a separate component.

$('.pickme').click()

is there a way I could have disabled that?

Of course. Give the numbers a randomly generated id, and check for the winning value server side. You'd also want display the numbers in a way where it's tougher to compare them than checking the text values--the target value is $('#left h1').text().trim(). So that means using images (not named 1.jpg!) or canvas or something like that.

Also, your app is vulnerable to replay. I can keep POSTing the same request over and over and my score increases.

As it is now, you don't even need to match the numbers. Just find the form and submit it. $("#right form").submit()

Looks like a Markov chain text generator.

Most web sites can grow significantly without having to do data partitioning. Simple replication should be considered as a first option, especially if your read/write ratio is high. Also, you don't have to implement a lot of extra logic in your application; just write to your master and read from the slaves.

Damn straight. And cache appropriately (and dumbly).

First off, congrats! I was in charge of the website when Oprah featured The Secret a few times on her show. Here's a few pointers from my experience.

1. Remember the show airs in Chicago in the morning, then more than once across time zones, so this will be an all day treat. We had a lot of buzz (Oprah's own forums went down under load for our show), and our URL was displayed on the screen. Regardless, you can expect a lot of traffic, mostly during the show and a few days afterward.

2. Your db will likely be your bottleneck. Make sure you don't have any unoptimized queries, or better yet, cache as much as you can so you're only hitting the db on writes for all the orders you'll be getting.

3. If possible, offload static content to a cdn. Akamai saved us here, because the site was not optimized size-wise.

4. What ultimately caused us issues was slow clients. I would definitely try to have a caching proxy up front. The snowball effect would cause us to tap out our 100Mb connection at times. Since you're using cloud hosting hopefully that's not a hard limitation for you.

5. It's really fun watching your bandwidth. I used a console tool called bmon. You'll be able to tell when commercials happen during the show.

6. +1 for a backup plan. Have a static page ready that you can switch over to. I'd highly suggest having an alternate payment processor, even if you have to go with Paypal. Since you're SAAS, you can't rely on retail or Amazon, so you may not get visitors to come back if your site fails. Make sure you can capture those customers the first time.

7. If you don't plan on having a free account, offer something so you can build your customer list and capture contact info. A whitepaper, newsletter, etc.

Have fun!

Thanks a lot for the answers!

1. Can you tell me approximately how many unique visitors you had during the shows? I'm kind of curious...

3. We're using cloudfront... So you'd advise on using Akamai instead? or would cloudfront be ok?

6. For payments, we're using Authorize.net (with the CIM feature to capture credit card information)... Hadn't thought that they could be a bottle neck but I'll definitely at least check up with them...

7. Makes sense, I'll suggest that...

It'll be a fun few months preparing... I've been meaning to play around with Varnish, now's my chance :-)

1. Can't give you any real numbers, but dude, it's Oprah.

3. Any cdn should be ok. You just want to offload those files to somebody else. Remember that browsers will only download a few resources from a single domain concurrently, so even if you have a subdomain for statics you'll get a faster page load. Hint: use yslow for more frontend optimization tips.

6. Authorize.net can handle it--we used them. But if your shopping cart can't, it's always nice to have a Paypal 'buy it now' button ready to go. Not real elegant, but it's a backup plan.

Thanks!

3. I'm a big fan of yslow too... It's really great for that :-)

Array dereferencing in is the trunk and will be available in 5.4.

And will be available for use on BigNameCorp's RHEL servers in about eight years.

If then. Look how many BigNameCorps are still using ASP classic.

The first answer that comes to mind is tooling. At one extreme you have SOAP, where your IDE can make complete proxy objects from a WSDL file. At the other end is REST, where normally you're in luck if there's a nice client library to translate request/response into objects, but otherwise you're left with API documentation. (Is anyone really using WADL?) Somewhere in between is XML-RPC, where you're more than likely to find some kind of reflection method to call such as client.get_methods or something similar.

I'm going to take this opportunity to shamelessly plug an open source project I've started for easily turning requests/responses into .NET objects: http://restsharp.org

There is a de-facto standard for that: system.listMethods to list supported methods, system.methodSignature to get the parameter and return types for a method, and system.methodHelp to get its documentation. It's not an ideal solution, since method signatures are shallow and not every server implements these methods the same way (or at all), but they are enough to do basic code generation for statically-typed languages. Here's an example of that for OCaml: http://code.google.com/p/xmlrpc-light/source/browse/trunk/ex...

I think it's inexcusable to cancel a contest, even if you only get a single entry. API providers can require registration to the contest, then monitor the usage metrics based on API keys. This would give an indication of how much development is happening before the contest deadline. If it's not much, extend the deadline, but don't cancel it. As far as quality of the submissions, it's not reasonable to expect polished, production quality work. The goal should be creative or novel prototypes that demonstrate a use case of the API. To me, a good entry would be one that clearly shows how the API is being utilized. Finally, if you've got good prizes(check), an iteresting API to play with(check), and a site to support the API(check), and you can't attract developers, you're doing something very wrong or not trying very hard.

I'd agree. They definitely screwed up here, but I can imagine exactly what happened is all. They should just bite the bullet- or at least reopen and extend.