You are there in the morning with your coffee in front of you, scanning pull requests and bug reports, then you see a conversation around a commit among a few guys that modified the code to make it better, than there is another one suggesting to improve it in another way. You click in the account names and you see this people with their transparent eyes and your trust in humanity is restored.
Takeaways: 1) Making videos is in some way harder than doing a talk live. 2) Screen Flow is awesome, but could be improved with more video editing capabilities, apparently you can't "cut" the video. 3) The problem is to upload files when they are big and you have normal ADSL connection :-) But it feels good to be able to send the video talks a few days in advance, so the conf organizers will be able to perform editing, filter audio if needed, whatever.
of the final recording of the videos I'll send to the Redis Conf. That was hard! The timing of the conf was not excellent for my attending, but producing the video was also less trivial than I thought, but finally I've the slides, an idea about what to say, and the ScreenFlow skills ;) Maybe after this experience I'll produce some video tutorial of Redis new features as I introduce it, in order to accelerate the adoption of new things in our community. Now back to work...
Good article by Josiah Carlson on Redis memory usage estimation, including copy-on-write worst case during BGSAVE: https://groups.google.com/d/msg/redis-db/02oq_DNZA3s/l_uEwDT3d4sJ
On twitter I read a few concerns about inability to read what I think about tech non-redis topics. First of all, thanks to everybody interested in my thoughts :) Second, this blog is exactly the place where I'll post everything like that. So: @redisfeed -> Redis news, mostly low traffic, high signal. @antirez -> Will be converted into my personal account, mostly italian language, non work related. @zeritna -> Will be simply dismissed. This blog -> Everything about day by day Redis development, personal opinion about sexism, sky driving, shit eating and japanese food.
I'm going to be a bit away from Redis code and this blog as I need to freaking focus on finishing the video talks for the Redis Conference that is very near at this point... I'm also tuning and testing the final bits into 2.6 to make sure to release it ASAP :-) See you in a couple of days. p.s. also my wife feels contraction since a few hours, so maybe Greta is going to birth in a few... (!!!)
The commit message says it all:
Fix MULTI / EXEC rendering in MONITOR output.
Before of this commit it used to be like this:
MULTI
EXEC
... actual commands of the transaction ...
Because after all that is the natural order of things. Transaction
commands are queued and executed *only after* EXEC is called.
However this makes debugging with MONITOR a mess, so the code was
modified to provide a coherent output.
What happens is that MULTI is rendered in the MONITOR output as far as