* Graph flow: a lot of interesting problems can be solved efficiently by converting them to graph flow problems.
* Basic microeconomics: the world looks different once you understand it, and it's not that hard to learn. A cheap enlightenment boost!
* Monoid-cached trees. Guy Steele explains better than I could. Video and slides:
Any others? I'm sure I haven't done more than scratch the surface.
But what do I know, just giving friendly advice...
If you change the title of the wikipedia article you can read it as a description of Redis strings almost verbatim ;)
It's not wrong. I think when you say String people think of:
String name = "Leto Atreides";
byte anything = ....
generally understood as a data type...using some character encoding
It isn't a big deal, but I think you'd find that it can be a little confusing to us some.
I think that if calling what are strings, "strings", can generate confusion, go figure how much confusion can be created by calling them with another term...
Is an image a string?
Is a video on YouTube a giant string?
They happen to be equivalent at a data storage level, but they're not semantically equivalent. I think the article explains the difference quite well to be honest.
This is true, but at least with Ruby it's widely regarded as an embarrassing design mistake. (Not that it's a mistake in Redis; a database has different goals from a language.)
#2 I and a lot of other programmers tend to think of a string (for me, going back decades) as "a byte sequence which just happens to represent text, in some encoding". It's not merely a byte array. A byte array could be say an encoded image (PNG, GIF, etc.) or some other serialized object. That said, this distinction/confusion in terminology is not important. It pales in comparison to how awesome Redis is. :)
I do appreciate the particular names in the example text, however so I'm willing to overlook this.
If it's all going in memory, why not run the client on that machine and use native data structures?
1) Redis is much more memory efficient than your average programming language.
2) Redis handles persistence and replication for you. Not a joke.
3) Accessing data with atomic operations on complex data types from your application using multiple threads can create more problems.
4) Your application is free of doing other stuff if you use a non blocking client, if you are asking Redis to do computationally intensive tasks.
5) There is no easy way to model Redis sorted sets, in many very high level languages, at the same speed, without writing a C extension.
As for why not use native structures? You need to build persistence, transaction support, pub/sub api, thread awarness. Also, if you happen to use a generic data structure, like Java's HashSet, you probably won't get even close to the same level of performance.
So I'd love to see the paragraph that begins "There are various ways to install Redis" expanded. In particular, what's the workflow between a) I just downloaded something called Redis, and b) I am issuing commands to learn along with these examples.
Otherwise very clear and concise. Well done.
No need to install it just to play with it..
Compiles in no time at all =)
Not my choice, at home OSX/Linux, but even then also a machine with Windows XP.
I simply don't think a remotely complex web application can do without it these days.