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.
News posted by antirez
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
These are the real victims of flamewars: "After the recent affair with @antirez's blogpost, I'm seriously considering forgoing further usage of #Redis in all my projects." (@nathell) Obvious considerations: 1) Somebody will be happy about this as there was definitely a force trying to resonate as much as possible what was happening in the worst way. 2) The guy should read my blog post seriously. But this is how it goes, you write a blog post that is a point of view about how to handle sexism (focusing on its effects, not the cause that anyway at the most subtle level, for instance a wrong promotion, can simply be denied by the author of the sexism), and the net result thanks to a number of people in part evil, in part simply bigot as hell, is that I'm sexist.