tabbyjabby

Hmm. The author's recommendation to use Redis' 'KEYS' command to pattern match keys for invalidation is a dangerous one. 'KEYS' runs in O(n) time. If you're using Redis in a serious production environment, you do not want want to be using an O(n) command each time you need to invalidate a group of keys. It's better to group related items in a Redis hash table, and that way they are all stored under one common key.

Honestly, I think this article is a more impoverished version of antirez's post on the same topic [1]. antirez, being one of the principal authors of Redis, is a much more authoritative source, and he actually describes all the patterns that this author described in greater detail.

[1] http://antirez.com/post/take-advantage-of-redis-adding-it-to...

Also, your client doesn't support pipelining, which is a nice feature for any Redis client.

Sorry, but why not just use phpredis? We heavily use Redis + PHP, and phpredis already seems to be a fairly minimalist interpretation, in the sense that it doesn't attempt to implement commands that Redis doesn't support. It's also written as a C extension, which makes it, to my knowledge, the faster PHP Redis client out there.

Also, using magic methods tends to be about 3x slower than a normal function call, AFAIK.

Your startup failed because teachers hate technology? Your startup failed because you couldn't make teachers love the technology you were providing. Or you didn't go to the right people. Maybe you should've gone straight to the schools.

Very dodgy methodology...

We're working on integrating Redis into our stack, but we use it mostly as a caching layer. As with any NoSQL datastore, your data will have to be structured far differently than if you were using a relational database. The nice thing about Redis is that it's a lot more effective than a simple key-value store for representing the data structures that exist in your application. If you're willing to put the time into learning this paradigm of data persistence the logical interaction with your data won't be a problem.

Redis does have a number of shortcomings. Firstly, it doesn't provide a very sophisticated transactions system. You get multi blocks, and the ability to watch keys (which is like a check and set), but you don't get true transactions. For example, there's no rollback mechanism, and commands will still be executed in a multi block if one of them fails.

Secondly, Redis by default does not provide strong guarantees of durability. It writes a snapshot to disk of your data periodically, so if something happens to the server that causes the program to shut down unexpectedly, you'll lose a lot of data. Redis can be configured to provide stronger guarantees of durability, but at the expense of speed.

Thirdly, there is currently no sharding mechanism built into Redis. They're working on Redis Cluster, which will allow your data to be spread across multiple servers, but it won't come out for sometime. You can build your own distribution system into your application however. You can read up on consistent hashing algorithms to help you with ideas for that.

Fourthly, everything is in memory at all times. That's pretty expensive, though Redis is quite efficient with memory usage.

Redis is really fast, which is awesome, but we still use MySQL as our primary datastore. We have a write-through/read-through caching layer, and if the transaction ever fails in part, we just rollback the MySQL transaction and invalidate the key in Redis, because we can trust that MySQL's records are more authoritative.

a) Apple is rumoured to be working on a low-cost iPhone for developing markets. Greenspun provides absolutely no evidence to support his claim that Apple cannot, except to say that emerging markets are becoming more important. If we use China as an example, desire for Apple products is absolutely booming there (see the profusion of fake Apple stores that Chinese consumers flock to.) I'd adopt a wait-and-see approach here, but Greenspun has said absolutely nothing.

b) Do you think their core profit centre is the iTunes Store? Because it's not. They make their money on iPhones, iPads, iPods, and Macs. This point is really dumb because even if it were true it has absolutely no bearing on the company's bottom line.

c) ...

This article is so astoundingly empty of any real logic that I am truly shocked that it's currently on the front page.

He claims that Apple's rise was fuelled by early adopters who forked over large sums of cash for the privilege of being able to posses the newest shiny bauble from Apple, but that their gadget lust has now been sated, thus spelling a near certain end to Apple's incredible growth. Does he realize that the very same people who paid to have the original iPhone have also probably put down money to have later iterations of the phone? The truth is that more and more people are now seeing the benefits of smartphones and are willing to invest more money in a mobile phone with more capabilities. This argument is completely bullocks!

It's really unattractive. Your text boxes look like buttons, probably due to the dropping of a hard border, the centred label, and the use of the unconventional yellow colour. This is a situation that's only made worse by the fact that the actual "Sleep On It" button looks identical to the text boxes, except for its background colour. Why would you make two widgets with entirely different uses look the same?

The entire site feels cramped. The layout of the actual entry form is frankly bizarre. Why would you wedge a check box in between two text boxes?

There's more, but I'm too lazy to keep going... take this back to the lab.