aaronblohowiak · October 23, 2012 00:02
diff --git a/gistfile1.txt b/gistfile1.txt
 Notes from my talk are here:
 	https://gist.github.com/3935383

 "Doing crazy stuff in redis" - Fitzy @fritzy from &Yet
 	* Everything on the internet is feeds in feeds, your follower list, your status updates..
 	* XMPP pubsub interface, called ZUMP, was XEP60.. it "kinda sucked" and "was really slow"
 	* I wanted something that fans out messages and was fast and if only there was something that already did that -- well they did, and it was redis.
 	* Implemented XEP60 in redis, and it was fast and awesome. "And then I had an epiphany"
 	* "I didn't need XMPP, this could be useful for ANY API..." events, and publishing messages could be useful for all the apis. "I know some of you JavaScripters think there's just HTTP, but there is a whole world of Protocols and APIs that could benefit."
 	* "What if we had CRUD events that came out of custom objects that weren't just feeds?"
 	* "[In node] there are events, and they can interrupt your watch/multi/exec... and life is too short to just crush bugs..."
 	* "Lua was there so we could implement our own commands.. and we had taken it there.. but we can take it farther[SIC]" .. Henrik asked: "What about ACL or object validation?" .. Yea! .. And then Henrik started driving!  But we were doing something crazy, so I was into it...
 	* The scripts started getting very long... found a crazy hack to call scripts from other scripts.. then started playing with making macros... 
 	* Boss: "Is this a good idea?"  Fritzy: "No! But it is AWESOME!"
 	* Started doing tests, an 800 line lua script can run thousands of times a second on a modest PC.
 	* It's no longer a database, it is an application service.  "It is crazy shit, don't do it!"

 Michel Martens - Author of redis.rb and longtime redis contributor
 	* soveren, cyz, djanowski
 	* made redis-cli -i, brpoplpush, redis.io, redis-doc, redis-rb
 	* "Ruby is a community that has a tendency to create loaded tools...at some point, I realized that everyone thinks that what they do is simple.. nobody goes around saying 'I write unneccessarily complex code'..."
 	* Discussing "Worse is Better", we can focus on completeness or simplicity of implementation even if we leave out some features.
 	* "I identify with the second group...for people of the other group, simplicity is solving more problems with the same tool"
 	* (Discussion of 'Shield' vs 'Devise' ruby libraries...) Shield is 100 LOC + 100 LOC for dependencies, Devise is 60,0000 LOC if you include deps (railties, which pulls in 1/2 of rails. Tilt, which has lots of deps as well..)
 	* LOC is a controversial measure because it favors people who prefer simple implementations.
 	* "Complex tools are hard to maintain"
 	* He wants to "use a tool that knows how to handle dependencies, implicit and explicit"
 	* "The thing with Bundler is that it has to be complex itself...7,000 LOC...very fragile tool... at any time, 300 reported bugs"
 	* Mote, cuba, shield, ost, ohm.
 	* Three instances of how Salvatore confronts complexity and deals with it.
 	* 1. Started small: Existing tools for analytics were too big or too slow
 	* 2. redis-cli made it interactive when txns added because the client/server had to maintain state.  In beginning, it didnt have editing or history.  Salvatore hated that readline had more LOC than redis at the time, so he wrote LineNoise
 	* 3. virtual memory: "in the early days, i was a heavy proponant of vm".."i wanted to use redis for everything.. [when I and others started using it, we realized it was not good and too complex]. So what happened to my dream of using redis for everything?"
 	* You can either change which tool you're using, or redefine the problem.
 	* Adding things in redis is easy, removing them is tricky. Created Ohm to wrap common patterns.
 	* Simple tools let you know not only what is happening, but make it easier to understand things when they go wrong.

 Antirez (via video)
 	* 2.6 is live Now! 1383 commits.
 	* Lua scripting, bitops, better expired keys
 	* Fewer latency spikes, better slow client handling
 	* Now we are ready for 2.8, which will be incremental release on 2.6
	Notes from my talk are here:
	https://gist.github.com/3935383

	"Doing crazy stuff in redis" - Fitzy @fritzy from &Yet
	* Everything on the internet is feeds in feeds, your follower list, your status updates..
	* XMPP pubsub interface, called ZUMP, was XEP60.. it "kinda sucked" and "was really slow"
	* I wanted something that fans out messages and was fast and if only there was something that already did that -- well they did, and it was redis.
	* Implemented XEP60 in redis, and it was fast and awesome. "And then I had an epiphany"
	* "I didn't need XMPP, this could be useful for ANY API..." events, and publishing messages could be useful for all the apis. "I know some of you JavaScripters think there's just HTTP, but there is a whole world of Protocols and APIs that could benefit."
	* "What if we had CRUD events that came out of custom objects that weren't just feeds?"
	* "[In node] there are events, and they can interrupt your watch/multi/exec... and life is too short to just crush bugs..."
	* "Lua was there so we could implement our own commands.. and we had taken it there.. but we can take it farther[SIC]" .. Henrik asked: "What about ACL or object validation?" .. Yea! .. And then Henrik started driving! But we were doing something crazy, so I was into it...
	* The scripts started getting very long... found a crazy hack to call scripts from other scripts.. then started playing with making macros...
	* Boss: "Is this a good idea?" Fritzy: "No! But it is AWESOME!"
	* Started doing tests, an 800 line lua script can run thousands of times a second on a modest PC.
	* It's no longer a database, it is an application service. "It is crazy shit, don't do it!"

	Michel Martens - Author of redis.rb and longtime redis contributor
	* soveren, cyz, djanowski
	* made redis-cli -i, brpoplpush, redis.io, redis-doc, redis-rb
	* "Ruby is a community that has a tendency to create loaded tools...at some point, I realized that everyone thinks that what they do is simple.. nobody goes around saying 'I write unneccessarily complex code'..."
	* Discussing "Worse is Better", we can focus on completeness or simplicity of implementation even if we leave out some features.
	* "I identify with the second group...for people of the other group, simplicity is solving more problems with the same tool"
	* (Discussion of 'Shield' vs 'Devise' ruby libraries...) Shield is 100 LOC + 100 LOC for dependencies, Devise is 60,0000 LOC if you include deps (railties, which pulls in 1/2 of rails. Tilt, which has lots of deps as well..)
	* LOC is a controversial measure because it favors people who prefer simple implementations.
	* "Complex tools are hard to maintain"
	* He wants to "use a tool that knows how to handle dependencies, implicit and explicit"
	* "The thing with Bundler is that it has to be complex itself...7,000 LOC...very fragile tool... at any time, 300 reported bugs"
	* Mote, cuba, shield, ost, ohm.
	* Three instances of how Salvatore confronts complexity and deals with it.
	* 1. Started small: Existing tools for analytics were too big or too slow
	* 2. redis-cli made it interactive when txns added because the client/server had to maintain state. In beginning, it didnt have editing or history. Salvatore hated that readline had more LOC than redis at the time, so he wrote LineNoise
	* 3. virtual memory: "in the early days, i was a heavy proponant of vm".."i wanted to use redis for everything.. [when I and others started using it, we realized it was not good and too complex]. So what happened to my dream of using redis for everything?"
	* You can either change which tool you're using, or redefine the problem.
	* Adding things in redis is easy, removing them is tricky. Created Ohm to wrap common patterns.
	* Simple tools let you know not only what is happening, but make it easier to understand things when they go wrong.

	Antirez (via video)
	* 2.6 is live Now! 1383 commits.
	* Lua scripting, bitops, better expired keys
	* Fewer latency spikes, better slow client handling
	* Now we are ready for 2.8, which will be incremental release on 2.6