Molti sviluppatori software si trovano a lavorare da remoto in queste settimane per via dell’emergenza COVID-19. Molte aziende hanno preso la decisione, spontanea o forzata, di chiudere gli uffici e far lavorare da casa tutto o parte del personale, praticamente adottando lo “Smart Working” (come si preferisce chiamarlo in Italia) a tempo pieno.

Un sogno che si avvera per alcuni software engineers, una situazione non necessariamente facile da gestire per altri. In questo breve post voglio condividere alcuni suggerimenti pratici per affrontare al meglio questo periodo di lavoro nel vostro team.

Innanzitutto, non bisogna pensare che la situazione che stiamo vivendo in questo momento sia la normalità del lavoro da remoto. La pandemia del coronavirus è chiaramente un evento straordinario che coglie tutti ugualmente impreparati, sia in Italia e all’estero. Persino aziende in cui normalmente il 100% dello staff lavora da remoto, pur avendo una certa sensibilità culturale di base sull’argomento, hanno messo in pratica processi e meccanismi aggiuntivi per affrontare l’emergenza.

Siamo passati bruscamente dalla quotidianità del lavoro in ufficio, o magari da una situazione di “lavoro flessibile” (in cui il lavoro da remoto è opzionale e volontario, pur essendo incentivato) ad un periodo di lavoro in isolamento forzato a tempo indeterminato.

In questo scenario un po’ surreale, non possiamo aspettarci che la produttività di un team di sviluppo rimanga invariata.

Tutti noi abbiamo personalità e reazioni potenzialmente differenti in queste circostanze. Ci sono tante buone ragioni per cui un team efficiente possa attraversare un periodo di scarsa energia e produttività.

C’è chi magari ha figli a cui badare durante la giornata o persone di cui prendersi cura. Certi individui possono soffrire particolarmente una situazione di isolamento in casa. Oppure ancora, il bombardamento mediatico costante sull’emergenza coronavirus può provocare negatività, stress o ansia.

Cosa fare per lavorare meglio insieme? Ecco un principio semplice e basilare:

Concentrarsi sulle persone come priorità assoluta, e poi sui processi del team.

Alcune idee per gestire le relazioni interpersonali lavorando da remoto:

• 👋 Favorite le interazioni dirette fra due persone (1:1) rispetto ai meeting che coinvolgono tutto il team. Almeno una volta al giorno, parlate con tutte le persone del team anche solo per qualche minuto. L’ideale è una videochiamata veloce, altrimenti va bene anche usare la chat. Interessatevi sia di come procede il lavoro che dello stato mentale e della situazione personale.

• 🗓 Se il team si riunisce a cadenza regolare, continuate a farlo! Sprint planning, daily stand-up, retrospettiva? Cercate di partecipare tutti, per quanto possibile. Un buon modo per far scorrere via un lungo meeting di un’ora è accorciarlo a 50 minuti, riservando 5 minuti all’inizio e alla fine della call per chiacchierare informalmente del più e del meno.

• 😌 Incoraggiate trasparenza e “vulnerabilità”. E’ ok sentirsi giù di tono, è ok fare una pausa lunga per ricaricarsi, è ok cercare un collega per un consiglio o una chiacchierata. Parlare della propria situazione personale o del proprio stato mentale non è un tabù. In un team sano non c’è alcuna vergogna nel dire cose tipo “oggi non sono qui con la testa” o “sono molto distratto, possiamo rimandare questa conversazione a domani?”.

• 👻 Pianificate momenti di svago comune. Una o due volte a settimana organizzate una pausa caffè virtuale a tema libero. Decidete in anticipo argomento e regole: possono partecipare i figli? E gli animali domestici? In alternativa, aggiungete un po’ di imbarazzo e di risate ai meeting troppo lunghi: tutti davanti alla webcam in abito elegante!

In secondo luogo, ecco dei suggerimenti per migliorare i processi del team:

• 🗣 Over-comunicate, ovvero comunicate più di quanto avreste fatto prima (ma fatelo bene!). In situazioni di stress alcune persone possono involontariamente iniziare ad ignorare molto di ciò che succede intorno, come forma di protezione da un sovraccarico di informazioni. Valutate bene l’importanza e l’impatto di quello che volete comunicare: se è necessario che tutti siano allineati con una certa decisione allora è bene comunicarlo a voce e magari ripetetelo anche per iscritto, accertandosi che tutti siano in condizioni di poter prestare attenzione.

• 💻 Non aspettatevi che l’altra persona sia sempre davanti alla tastiera. La comunicazione remota è asincrona per definizione. Se sono stati pianificati dei meeting è opportuno rispettare presenze ed orari. Per tutto il resto, tenete in conto che la persona a cui avete appena inviato un messaggio potrebbe essere in pausa oppure impegnata in qualcosa da cui preferisce non essere distratta. Una accortezza semplice: iniziate una conversazione in chat indicando la priorità del messaggio, ad esempio “Hai 10 minuti per aiutarmi con questo task? Anche a pomeriggio andrebbe bene”.

• 🕐 Rendete note le vostre esigenze, e cercate di rispettare quelle degli altri. Spesso gli orari di lavoro non coincidono esattamente nel team: ad esempio, chi ha figli magari preferisce iniziare a lavorare molto presto e poi spendere il pomeriggio con la famiglia. Mettetevi d’accordo in base alle necessità quotidiane di ognuno, comunicate e rispettate rigorosamente gli orari di inizio e fine giornata lavorativa. Sia i vostri che quelli degli altri. Non va bene disconnettersi salutando tutti alle 6 del pomeriggio per poi riaprire il laptop a tarda sera e rispondere alle email: voi rischiate di esaurire presto le energie (burnout), e chi vi legge potrebbe sentirsi obbligato a seguire gli stessi ritmi. Quando si stacca si stacca.

• ✍️ Fate in modo che le decisioni possano essere prese in autonomia. Solo le decisioni irreversibili, che non possono essere rivalutate in seguito, dovrebbero richiedere l’attenzione e l’approvazione di tutto il team o di un responsabile. Ogni altra decisione reversibile (tecnica o meno) , deve poter essere delegabile ad un qualsiasi sottogruppo di individui. L’idea è evitare colli di bottiglia dovuti alla comunicazione asincrona o a ritmi di lavoro differenti. Attenzione però, perché questo meccanismo funzioni in modo sano tutte le decisioni e le modifiche devono essere peer-reviewed, registrate permanentemente ed accessibili a tutti.

• 📊 Discutete obiettivi a breve termine e comunicate correttamente le aspettative al di fuori del team. Evitate di definire obiettivi troppo ambiziosi circa il carico di lavoro sostenibile. Questa è una considerazione che dovrebbe valere sempre, ma è particolarmente importante nella situazione di imprevedibilità attuale. Fissate obiettivi fattibili e riesaminateli di frequente, eventualmente ricalibrandoli in base alle necessità e le peculiarità di ogni individuo nel team. Fate in modo che i vostri obiettivi e il loro stato di avanzamento siano facilmente visibili all’esterno del team, comunicate con trasparenza e regolarità agli stakeholder cosicché le aspettative non vengano fraintese o disattese.

Lavorare in team da remoto in questa situazione di emergenza ed isolamento non è per nulla banale: richiede di ricalibrare le proprie interazioni e di adattare i ritmi di lavoro di tutto il team. Non esiste una soluzione unica applicabile in ogni contesto. Fiducia, rispetto e trasparenza sono i capisaldi di sane e produttive relazioni tra gli individui, tanto in generale quanto soprattutto in un team. Lasciatevi guidare da questi valori e siate flessibili nell’adattarvi alle situazioni.

Definitions, first!

A script is an executable file that begins with a line (starting with the #! characters) specifying a path to a script interpreter.

#! /path/to/interpreter [ args ]

On most Unix implementations, the space after the #! is optional.

How the kernel executes a script

What happens when you execute a Python script like this one?

#!/usr/bin/python

print "Hello World"

If you strace the script to intercept syscalls, this is what you should see:

$ strace -e trace=open,execve,write ./hello.py
execve("./hello.py", ["./hello.py"], [/* 59 vars */]) = 0
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libutil.so.1", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libz.so.1", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libm.so.6", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/python2.7/site.x86_64-linux-gnu.so", O_RDONLY) = -1 ENOENT (No such file or directory)
...
open("./hello.py", O_RDONLY)             = 3
write(1, "Hello World\n", 12Hello World
)           = 12
+++ exited with 0 +++

There is exactly one execve() call, with the script filename as first argument: no Python interpreter is being executed here!

Well, what happens under the hood is the kernel recognizing such executable file as an interpreter script, given it starts with the sha-bang magic numbers (0x23 0x21). The whole first line of the file is then split into an interpreter path and (optional) args. The interpreter is located on the filesystem and invoked with the script path as first argument.

In the example above, any syscall after the execve() is actually issued by the Python interpreter binary, although you can’t directly see it being executed.

Interpreter and script’s arguments

The first line of a script file specifies the interpreter path and optional arguments for the interpreter itself. Any other command line argument is appended after the script path. Let’s explain this with an example:

$ cat script.sh
#!/home/cristian/myecho interp_arg1 interp_arg2

The myecho interpreter is a little C program that outputs argv:

#include <stdio.h>

int main(int argc, char* argv[]) {
  for (int i = 0; i < argc; i++) {
    printf("%d -> %s\n", i, argv[i]);
  }
}

When executing script.sh with additional command line arguments, output is:

$ ./script.sh cli_arg1 cli_arg2
0 -> /home/cristian/myecho
1 -> interp_arg1 interp_arg2
2 -> ./script.sh
3 -> cli_arg1
4 -> cli_arg2

Here you see that inside execve() the arguments are re-arranged in this manner:

interpreter-path interpreter-args script-path script-args

On Linux, the interpreter args are parsed as a single line (this explains why interp_arg1 interp_arg2 are printed as a single argv entry), and this may be the source of portability issues. You should also be aware that, on Linux, the total length of the first line of a script (i.e. sha-bang + interpreter-path + interpreter-args) cannot be longer than 128 characters (including newline).

The problem with PATH

The interpreter path is usually an absolute path (although a relative path can still be used). In fact, the $PATH mechanism of your shell is meaningless in kernel space (remember everything we’re discussing here happens inside an execve() syscall). The interpreter path must be the exact location of an executable file.

For the sake of portability, the env(1) utility is often used as a workaround. Assuming that env is commonly installed under the standard /usr/bin/env path, this small executable is then used as a trampoline to start the real interpreter, which then needs to be located somewhere in the user’s PATH.

#!/usr/bin/env python

print "Hello World"

In other words, #!/usr/bin/env python executes env as an interpreter, passing python as an interpreter-arg. env itself is usually implemented with an execvp(3) call - a C library call - that searches for the given executable in PATH.

Nesting the interpreter

Some UNIX implementations permit the interpreter of a script to itself be a script. On Linux, this kind of “executable search” is recursive up to an hardcoded limit of four recursions.

$ cat nested.sh
#!./nested.sh

$ ./nested.sh
bash: ./nested.sh: /nested.sh: bad interpreter: Too many levels of symbolic links

The setuid bit is ignored

On Linux, and in other Unix implementations, the setuid bit on scripts in ignored for security reasons.

We can prepare a small test program:

#include <unistd.h>
#include <stdio.h>

int main() {
  printf("real=%d effective=%d\n", getuid(), geteuid());
}

The setuid permission on the binary executable works as expected:

$ ./test-setuid
real=1000 effective=1000

$ sudo chown root test-setuid && sudo chmod +s test-setuid

$ ./test-setuid
real=1000 effective=0

If we do the same job on a script, the setuid bit is ignored instead:

$ cat test-setuid.sh
#!/bin/bash

id -u

$ ./test-setuid.sh
1000

$ sudo chown root test-setuid.sh && sudo chmod +s test-setuid.sh

$ ./test-setuid.sh
1000

Further reading

In the description above, I’ve mentioned a few times that some details are very Linux-specific. This is because, unfortunately, the #! mechanism is not officially part of any Unix specification. Here are described more in-depth details about the differences between existing Unix flavours and how they evolved over time.

Since release 3.0.0, Redis is able to operate in Cluster mode, providing automatic data sharding across multiple nodes with a high degree of fault tolerance.

Well known techniques have been around for quite some time now to partition the data set and scale Redis to many instances, the most simple and effective one being client side partitioning implemented with consistent hashing. Redis Cluster goes a step forward in the direction of high scalability: it has been designed from the beginning with focus on high performance and with the aim to provide a set of consistency and availability guarantees that are suitable for different kinds of applications.

There is an increasing amount of documentation around Redis Cluster, including official resources like the quick-start tutorial for end users and detailed tech specifications for developers. In this post we’ll focus on the cluster networking internals, to give you an overview of the role and the importance of inter-node communications.

Redis Cluster topology

A set of isolated Redis instances, with proper configuration and guidance, can be joined to form a Redis Cluster. The minimal working cluster is composed of three master nodes, but Redis Cluster is designed and tested to scale efficiently up to 1000 nodes. In our examples, for the sake of simplicity, we’ll consider only sets of masters without attached slaves.

Nodes in a Redis Cluster talk to each other using the Cluster Bus. Every node is connected to every other node through a dedicated tcp connection, thus forming a fully connected network. This node-to-node communication channel is used exclusively for cluster operations (e.g. configuration update, failure detection, failover authorization) and its links are kept separate from normal client connections.

Nodes exchange data over the bus using a binary protocol, which is deliberately undocumented because it is not intended to be used by clients. Of course, code speaks and Redis source code is always worth studying.

Cluster heartbeat: PING / PONG packets

Under normal conditions, nodes of the cluster continuously exchange PING and PONG packets over the bus (remember we’re talking about raw binary packets here, not to be confused with the PING client command).

This packet flow constitutes the heartbeat mechanism of the cluster, a means of information propagation fundamental to some key features such as, for example, node auto-discovery and failure detection. In fact, each ping/pong packet carries important pieces of information about the state of the cluster from the point of view of the sender node, like hash slots distribution, configuration information and additional data about other trusted nodes.

This animation¹ shows the heartbeat packet flow in a cluster of 5 master nodes under normal operation. While it is extremely slowed down, you can see that every PING packet triggers a PONG reply from the receiver node:

In order to avoid exchanging too many packets on the network, usually a node will ping only a few (not all) randomly chosen nodes every second. However, the cluster-node-timeout configuration parameter controls (among other things) the volume of heartbeat packets exchanged between nodes: each node in the cluster will always try to ping every other node that didn’t send a PING or received a PONG for longer than half this timeout value.

In other words, information about other nodes is refreshed after -at most- half cluster-node-timeout milliseconds, so this value significantly affects the hearthbeat traffic. Although packets are usually small in size, a lower timeout will cause a sensibly higher network traffic in a very large cluster. This setting is also involved in failure detection: if a node seems to be unreachable, before complete timeout expiration the sender will try to renew the underlying tcp connection and ping it again.

Cluster bootstrap: MEET packets

Fundamental to the bootstrap process of a Redis Cluster and, in general, to the addition of new nodes, is the MEET packet. Its binary structure is similar to the PING / PONG packets, but a node receiving a MEET message will accept the sender as a new trusted node of the cluster.

In fact, being part of a Redis Cluster is a matter of being trusted by your neighbors. While any node in a cluster will blindly reply to incoming PINGs on the cluster bus port, it won’t process any other sensible packet nor will consider another Redis instance as part of the cluster until such untrusted source introduces itself with a MEET packet.

To stimulate a new node to join an existing Redis Cluster we need to use the CLUSTER MEET command. The syntax

CLUSTER MEET ip port

will force Redis, when configured in cluster mode, to send a MEET packet to the specified node. Note that port here is the bus port, and any node of the cluster can be used as target, as we’re going to explain.

The creation of a Redis Cluster is usually handled with the redis-trib tool, a Ruby utility that simplifies cluster operations for sysadms. What this script actually does in order to bootstrap a cluster of N nodes, is a kind of brute force approach:

1. the first Redis instance passed on the command line is selected as a trusted node,
2. then a CLUSTER MEET command is sent to every other node to meet with this first one.

This means that initially the trust relationship between cluster nodes is effectively forced by the sysadm.

In this animation you can see the bootstrap phase of a Redis Cluster with 5 masters:

Here node 9000 is the first trusted node, so every other node meets with it and receives a PONG reply. After some time that node 9000 knows about every other node in the cluster, you can see other nodes spontaneously getting in touch with each other through additional MEET messages, thus forming the fully connected network of an operational Redis Cluster. How did this information propagate across all nodes?

Gossip: rumors worth listening to

Redis Cluster uses a simple Gossip protocol in order to quickly spread information through any connected node. Heartbeat packets carry information on their own, but they also contain a special header for gossip data.

This section contains information about a few random nodes among the set of nodes known to the sender. The number of entries included in the gossip header is proportional to the size of the cluster (usually 1/10 of the nodes, but may be empty as well in some cases). The trick is: almost any heartbeat packet contains data about some (a few) nodes of the cluster from the point of view of the sender. This is how information propagates quickly at large scale without requiring an exponential number of messages exchanged.

Through gossip, all nodes eventually converge to a common shared view of the state of the cluster. This continuous information exchange is crucial in various point in life of the cluster like, for example, at bootstrap time and during node or network failures. In particular, when connecting a new node to an existing cluster, the redis-trib script just issues a single CLUSTER MEET command, then gossip makes the magic of auto-discover.

This last animation shows in details what happens when a new node is connected to a cluster of 50 nodes:

The video only shows MEET messages and PING / PONG packets that carry the information of the new node (so a lot of other heartbeat traffic is not represented). Nodes are initially in gray as they don’t know about the newly connected Redis instance, nor it knows about them. What can happen here is either:

1. the new node gets to know about a cluster node first (which is then highlighted in blue), or
2. a cluster node is informed about the new node first (in this case is highlighted in red).

This second event happens either by directly receiving a MEET or through a gossip info from a peer. In the example above, node 9050 meets with 9049 and receives gossip info by the PONG reply, then the information quickly flows and the nodes eventually form a fully connected graph again.

It is worth noting that is much easier for the new node to discover existing nodes (i.e. case 1 is the majority), because every MEET/PONG exchange carries data about potentially unknown nodes. If you’re wondering how fast it is, the 50 nodes above were configured with a cluster-node-timeout of 500 ms and the auto-discovery phase converged in about 400 ms.

The Geo API consists of a set of new commands that add support for storing and querying pairs of longitude/latitude coordinates into Redis keys. GeoSet is the name of the data structure holding a set of (x,y) coordinates. Actually, there isn’t any new data structure under the hood: a GeoSet is simply a Redis SortedSet.

Let’s have a quick look at the syntax of the new GEO* commands:

• GEOADD key long lat name [long2 lat2 name2 ... longN latN nameN]

Add a member with the specified long/lat coordinates to a GeoSet.

• GEORADIUS key long lat radius unit [WITHDIST] [WITHHASH] [WITHCOORD] [ASC|DESC] [COUNT count]

Search a GeoSet for members within ‘radius’ distance from given coordinates. Valid units for radius are m, km, ft, mi.

• GEORADIUSBYMEMBER key member radius unit [WITHDIST] [WITHHASH] [WITHCOORD] [ASC|DESC] [COUNT count]

The same as GEORADIUS, but the search is centered on the coordinates of a member of the GeoSet.

• GEOPOS key elem1 elem2 ... elemN

Return the long/lat coordinates of each specified element in a GeoSet.

• GEODIST key elem1 elem2 [unit]

Return the distance in unit (meters by default) between elem1 and elem2 in a GeoSet.

• GEOHASH key elem1 elem2 ... elemN

Return the GeoHash string representation (an array of 11 characters) of the coordinates of the specified elements.

• GEOENCODE long lat [radius unit]

Translate the given coordinates to the GeoHash integer value with highest accuracy.

• GEODECODE hash

Translate a GeoHash integer value back to a pair of coordinates.

I think at this point you’re wondering what a GeoHash is … before digging into details let’s have a visual example.

Building an Hotel Reservation system with map search

A picture is worth a thousand words, so let’s build a real-world example.

I downloaded (thanks to Overpass turbo a small dataset with the coordinates of a set of hotels in Rome (a very small set indeed) and imported it into Redis. This is the GeoJSON dataset and an example script to load it. It is as easy as adding coordinates with symbolic names in a GeoSet and then populating a key for each hotel data (using such names in order to later retrieve it).

geoadd hotels 12.4844774 41.9184129 h:259299923 12.4920147 41.9175913 h:261733735 ...
set h:259299923 '{"geometry": {"type": "Point", "coordinates": [12.4844774, 41.9184129]} ...'
set h:261733735 '{"geometry": {"type": "Point", "coordinates": [12.4920147, 41.9175913]} ...'
...

All the hotels visualized on a map:

Now let’s suppose you’re searching for an accommodation near Stazione Termini (not really the best place to stay in Rome). How do you retrieve the hotels within 1km from your point of interest?

GEORADIUS hotels 12.499705 41.902372 1 km
 1) "h:530719587"
 2) "h:3412957318"
 3) "h:3554601725"
 4) "h:1743613641"
 5) "h:3292538681"
...

Fine, but a friend of mine suggested me a cheap accommodation near Termini, let’s say property known as h:2309332158. Ouch, no availability for my dates… let’s search for the accommodations at shortest distance:

GEORADIUSBYMEMBER hotels h:2309332158 1 km withdist asc
 1) 1) "h:2309332158"
    2) "0.0000"
 2) 1) "h:3403814918"
    2) "0.0627"
 3) 1) "h:3403814919"
    2) "0.0657"
 4) 1) "h:3403817806"
    2) "0.0688"
 5) 1) "h:2397317566"
    2) "0.0928"
...

This is how the result could be presented to the user:

Let’s retrieve the position on the map of two of the hotels in this list:

GEOPOS hotels h:3403814919 h:3403817806
1) 1) "12.497514188289642"
   2) "41.899867204456598"
2) 1) "12.497755587100983"
   2) "41.900039565495433”

Quite close to each other? Yeah, say less than 30 meters:

GEODIST hotels h:3403814919 h:3403817806
"27.693296515757325"

Under the hood: GeoHashing

We said before that a GeoSet in Redis is implemented as a SortedSet (actually the GEOADD command translates your input to a proper ZADD command). All members in a SortedSet have a score value associated used for sorting (indeed) and range indexing. But how is it possible to translate a pair of coordinates to a score?

GeoHashing is a technique to encode a pair of longitude/latitude coordinates into a single ASCII string (usually encoded base32). It all started with the geohash.org service as a way to represent locations with short and easily shareable urls.

The GeoHash encoding algorithm offers arbitrary precision. The accuracy of the representation depends on the number of bits used. Also, the raw binary form can be interpreted as an integer instead of a base32 string. This is the intuition behind the usage of GeoHash as a score for a SortedSet.

The integer GeoHash implementation in Redis derives from Ardb, but has been completely reimplemented by Matt Stancliff and is based on a 52bit integer representation (which gives an accuracy of less than 1 meter). Why 52bit? Because SortedSet uses double values for members scores, and a double can safely hold a 52bit integer without loss of accuracy.

The GeoHash score of a GeoSet member can be exposed with a ZRANGE command (GeoSets are SortedSets, right?):

ZRANGE hotels 0 -1 withscores
  1) "h:2138691946"
  2) "3480341633710855"
  3) "h:2302346446"
  4) "3480341645075993"
  5) "h:2985974223"
  6) "3480341646134189"
...

The corresponding base32 string representation can be obtained in this way:

GEOHASH hotels h:530719587
1) "sr2ykhnegy0"

See how it translates back to coordinates at http://geohash.org/sr2ykhnegy0.

So, the integer GeoHash encoding is a Redis-specific implementation detail, and Geo API provides two specific commands to deal with it:

GEOENCODE 12.498113 41.8994816
1) (integer) 3480343095387795
2) 1) "12.498112320899963"
   2) "41.899480659479806"
3) 1) "12.498117685317993"
   2) "41.899483194200954"
4) 1) "12.498115003108978"
   2) "41.89948192684038"
5) 1) "3480343095387795"
   2) "3480343095387796"

GEODECODE 3480343095387795
1) 1) "12.498112320899963"
   2) "41.899480659479806"
2) 1) "12.498117685317993"
   2) "41.899483194200954"
3) 1) "12.498115003108978"
   2) "41.89948192684038"

The output may look scary at first, but keep in mind that a GeoHash represents actually an area rather than a single point (in fact, you can add a radius to GEOENCODE). So the first pair of coordinates in this multi-bulk reply is the minimum corner (i.e. the south-west point) of the bounding box, then the maximum corner (north-est point) and an averaged center of the area.

The GEOENCODE command also outputs two scores to be used as range query parameters. A fundamental property of GeoHashing is that a range search between a lower and a higher range (excluded) will contain all members with corresponding coordinates in this range.

Given a pair of coordinates, we use GEOENCODE to determine the GeoHash that represents its 1km bounding box with highest accuracy:

GEOENCODE 12.498113 41.8994816 1000 m
1) (integer) 3480343080337408
2) 1) "12.48046875"
   2) "41.892249100012208"
3) 1) "12.50244140625"
   2) "41.902631317880861"
4) 1) "12.491455078125"
   2) "41.897440208946534"
5) 1) "3480343080337408"
   2) "3480343097114624"

Then, a range search using the returned low-high GeoHashes produces:

ZRANGEBYSCORE hotels 3480343080337408 3480343097114624
 1) "h:3192164485"
 2) "h:1649776328"
 3) "h:985232400"
...

A visual representation of the bounding box: note that the initial (highlighted) value is not the center of the box, but just falls within it.

I’ve been reading this new book Redis Applied Design Patterns by Arun Chinnachamy. It is meant to be a very practical and small (100 pages) guide for developers to using Redis effectively by taking advantage of the uniqueness of its features.

The first pages of the book briefly introduce the reader to the NoSql way of thinking, with some examples showing data denormalization in a key-value storage and explaining the need to carefully design your data structures based on how you want to access your data. Then the author provides a good collection of real-life use cases for Redis: cache management is a must for a book on this topic, but the real focus is on the kind of things that are too slow or impossible to achieve with a relational database (features like autosuggest, leaderboards, notifications, real time analysis) and also more complex examples about using Redis as primary in-memory data store (for a commenting systems, an advertising network or your new shiny social network).

Each chapter, as the book itself, keeps short and focused on the discussed use case. It provides a brief context to the reader and describes a step-by-step solution. After relevant explanation and code examples, the author usually comments on the flexibility of a Redis-based solution and/or suggests how the system could be further improved to handle more complex requirements.

The book is short enough that could be read in a day, but such a collection of documented design pattern is good to keep at hand everyday for quick review. Each use case is self-contained, showing commands and explaining data structures with descriptions and links to documentation. The code examples are straightforward to read and understand.

What I didn’t like is that while the book seems to be written for an intermediate user (one who is already familiar with the basics of Redis and is able to use a client library), some of the patterns described here are probably obvious to this kind of reader. The author just provides very basic examples to start with, covering only the surface of the problems without in-depth discussion: when things start to get more interesting and not so obvious, you’re at the end of chapter and it feels like you didn’t have the opportunity to understand how more complex scenarios can be solved in real production applications.

This (first?) edition of the book suffers from several problems. For example, in some cases there are inconsistencies between the examples and the text, and the code uses different variable naming conventions. Clearly nothing that harms the understanding of the concepts but, in general, seems like the book has been written in a hurry and/or at different times: different chapters try to explain the same thing without self-reference (e.g. the ZREVRANGEBYSCORE command is explained twice in ch. 8 and in ch. 10). Some examples are outdated: the chapter on autocomplete could at least mention the ZRANGEBYLEX command, while Redis Sentinel is nowadays a stable solution for high-availability (no more “under development”). A book about Redis use cases is not complete without discussing the Lua Scripting feature and how many problems it solves.

Redis Applied Design Patterns is a short and maybe worth reading book for any non-advanced Redis user. It is a collection of the established, well-known practices: you may find it useful for a quick overview of the kind of problems Redis helps to solve, but this book doesn’t really add anything new to the amount of documentation and resources already available by the community.