Redis: Zero to Master in 30 minutes
openmymind.net
openmymind.net
* 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:
http://labs.oracle.com/projects/plrg/Publications/ICFPAugust...
Any others? I'm sure I haven't done more than scratch the surface.
But what do I know, just giving friendly advice...
http://en.wikipedia.org/wiki/String_(computer_science)
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";
In Redis (and I guess as a Computer Science term) it means: byte[] anything = ....
Although, the Wiki page does say: generally understood as a data type...using some character encoding
With the redis implementation not having any 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.
#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. :)
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.)
Some of the explanations are a bit confusing though. I'm not sure I know what a List is - though I suspect, knowing JavaScript, Python, and PHP pretty well, I know what a List is. Descriptions like "If a hash is like a string with an extra field layer" are just plain confusing. Why not put it in terms of commonly understood programming languages? The examples are in Ruby, why not let us know which Ruby structures these most closely correspond to, for instance?
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.