Forem: Luís Costa

go-timetracker | Part II - Initial Struggles

Luís Costa — Wed, 10 Jun 2020 17:54:23 +0000

Hello and welcome back to this series of posts where I document my journey into building a simple time tracker in Golang. In this blog post, we'll take a look into what I've worked on in the past couple of months for the project, what I struggled with, and what I learned.

Struggle #1: Installing Dep on Windows

The first struggle I faced was installing dep on windows. For those who don't know, dep is a dependency management tool for Go, just like npm and bundler.

As documented in the README of the repository, to install dep on windows, you should download a tarball from a specific link, but that link is broken, responding with a 404. There is currently an issue opened about this, which I bumped but sadly no one has yet had the time to take a look into it.

The README also says that for any other platforms you can use a simple install script:

curl https://raw.githubusercontent.com/golang/dep/master/install.sh | sh

When I initially run this command on my machine, I kept getting the error:

Installation requires your GOBIN directory C/bin to exist

So, I needed to set up a bin folder for my go environment. I ended up creating a bin bolder in my GOPATH folder, like:

mkdir $GOPATH\\bin

Now the script above runs just fine! Now, to run dep I needed to run:

$ $GOPATH\\bin\\dep init
$ $GOPATH\\bin\\dep ensure

The init command is similar to npm init, creating an empty Gopkg.toml file in the current directory. The dependencies of the project can be specified in that file (refer to the documentation page to understand how it works).

Voila. I can now start coding/designing!

Struggle #2: Building the CLI skeleton

For the initial version of the tool, I decided a simple CLI application would be good enough. Before trying any solution/library from other people, I tried to build my own, and it wasn't that difficult to understand the basics. Golang's documentation helped me here.

All you need is the flag standard library. You can build powerful CLI apps just with this library, which is awesome. Initially, I built a simple CLI app with several subcommands, using as templates the commands I described in the previous blog post, where they didn't do anything useful, it was meant purely to test out the flag lib.

Then, figuring I'd want to build something more robust (with helper messages, command descriptions, etc) and deciding that I didn't want to re-invent the wheel, I started looking online for Golang open-source CLI app builders. I stumbled upon two: Cobra and Urfave/cli. I ended up using Cobra for no particular reason: it was just the first one I used, and I stuck with it.

I built the skeleton of the app quite quickly, which was nice because it meant I could just focus on the core logic of my application right away.

Now, I realize I wrote in the previous post that I wanted to use as little dependencies as possible. I do not intend to add any other dependency, at the time of this writing, besides Cobra (unless, of course, I want to extend the app and use other persistence mechanisms, like a database).

After writing the skeleton of the CLI, here's what it looks like when I type go run main.go help (I didn't have to write the help command since that is provided by default by Cobra):

$ go run main.go help

With go-tt, you can easily track the time you spend on different activities throughout your day.
go-tt provides several reports outlining the time you have spent in all your registered activities.
The goal of this small app is to help you fight procrastination, 
by making you aware of where you chose to spend your time.

Usage:
  tt [command]

Available Commands:
  add         Adds a new activity
  del         Deletes an activity
  help        Help about any command
  list        Lists all activities
  start       Starts an activity

Flags:
  -h, --help   help for tt

Use "tt [command] --help" for more information about a command.

(Not all commands are implemented at this time of writing). It's starting to look like a real CLI app!

Struggle #3: Designing the Persistence Module

Before diving into writing any code, I needed to think about how was I going to structure the persistence module of the app. The persistence module is the module that handles the logic of storing/reading activity data from some internal persistence mechanism. The details of that implementation should be hidden from the outside. I didn't want to lock myself to a particular implementation so the module interface should only deal with, if possible, core domain models (such as Activity). I decided to go with a simple solution: create an interface to expose the API of the persistence module. I called it ActivityRepository. Here's how the first version of that interface looks like:

type ActivityRepository interface {
    Initialize() error
    Update(core.Activity) error
    List() []core.Activity
    Delete(core.Activity) error
    Start(core.Activity) error
    Find(string) (*core.Activity, error)
}

The Initialize method should handle the logic to initialize the whole repository. For a file-based implementation, it could be something like setting up the necessary files/folders in the user's file system, dealing with permissions on those files, etc. For a database based implementation, it could be setting the needed connections.

The remaining methods should be self-explanatory.

Struggle #4: Implementing a JSON repository

As I wrote in the previous post, the initial implementation for the persistence module would be based on a simple JSON data storage.

The first step was choosing a folder in the user's file systems to store the data. I set up the app so that on the first use, the folder .gott would be created in the user's home folder (for that I used the method HomeDir from the current OS user, which is fetched from the method Current of the Golang's standard library os/user).

I had to write a lot of utility methods to create/read/delete files from the filesystem, which turned out okay because I learned a lot about IO in Golang.

Struggle #5: Indexing activities with aliases

The next difficulty was finding a way to quickly fetch an activity given an alias. As I wrote in the previous post, an activity can have a name and an alias. This is so that the activity name can act more as a description, and the alias more as the identifier (perhaps I should rename these fields, uh). This way, the user doesn't have to remember exactly the activity name to start it, and can quickly reference it via its alias. The aliases are shown with the List command, for example:

$ go run main.go add Activity1 -a=a1
$ go run main.go add Activity2 -a=act2
$ go run main.go add Activity3 -a=3

$ go run main.go list
activity1 (a1)
activity2 (act2)
activity3 (3)

How do we make sure that fetching the associated activity JSON file given an alias is as fast as possible (given our initial implementation using a JSON based repository)? The naive way would be to open each and every activity file in the data folder, read its contents into memory, fetching the Alias key (for now, an activity JSON file contains: name and alias) and seeing if it matches the alias given as input. Of course, this is terribly slow.

Another option would be to give a specific file name structure to each file. Something like ActivityName_Alias.json, and we could quickly identify the files by doing some regexp shenanigans, but this didn't quite felt right.

Another solution I thought about was using an in-memory database, like Redis, to store mappings between aliases and file names. But this would require an additional service to be running on the user's machine, which I think doesn't make sense for such a small CLI app.

So I ended up with creating a simple version of an index: a file called index.json which contains the following structure:

{
    "alias1": "/path/to/activityfile.json",
    "alias2": "/path/to/activityfile.json"
}

Simple to use and implement. Of course, as always, this has the disadvantage of having to load the entire index file in memory and also the need to add/remove entries every time a new activity is created or deleted but, for now, it will suffice.

That'll be all for now! Thanks for reading! Remember you can take a look at the repository. If you have any suggestions on how I can improve the code, please open a ticket or better yet fork it and open a PR. Remember: I'm a noob at Golang, so I may have a lot of bad/inefficient code. But bare with me, I'm learning!

Golang DNS Resolving

Luís Costa — Thu, 23 Apr 2020 10:04:33 +0000

Lately, I have been writing Golang (more commonly known as just Go, which is what I’ll be using from here on out) at work, and so far I have been enjoying it a lot! This is a small TIL (Today I Learned) about making Go correctly communicate with services in the local machine like, for instance, Redis, Postgres, or Kafka.

In my particular situation, the project I am working on is running on my machine, however, some of the needed services (Redis, Kafka) are running inside a Docker container. For instance, Redis is accessible via the hostname redis, and likewise for Kafka. Initially, I thought that simply adding the following entries to my etc/hosts files would be enough for the name resolution to work properly:

127.0.0.1 redis kafka

However, the code was still throwing errors because it could not connect to redis or Kafka. Turns out that Go has two ways to perform address name resolution, depending on the operating system it is running on. On OS X (which is my case), Golang uses a different name resolution library called cgo, which is a bit different than the default name resolver. You can see which name resolver your Go program is using by setting the flag GODEBUG with the value netdns=2. Here’s a sample output for my program:

GODEBUG=netdns=1 go run main.go
> go package net: hostLookupOrder(redis) = cgo
...

On OSX, applications are not allowed to make direct DNS requests. So, let’s try running the program with the pure Go name resolver:

GODEBUG=netdns=go+2 go run main.go
> go package net: GODEBUG setting forcing use of Go’s resolver go 
> package net: hostLookupOrder(redis) = files,dns

(The + sign is used to tell Go to force a specific name resolver and to show debugging information).

And it works! Since the pure Go name resolver is used, Go accesses local files in the machine to perform name resolutions such as /etc/resolv.conf and /etc/hosts

Nowadays I work at Runtime Revolution as a full-stack software developer. Working here has been, and continues to be, a great learning experience. I’ve matured professionally as a developer, as well as a human being.

go-timetracker | Part I - Why and What

Luís Costa — Sun, 19 Apr 2020 18:18:03 +0000

Lately, I've been enjoying programming in go. I don't know what it is, but I feel good writing go code. Maybe it's because I have a background in dynamically typed languages (such as ruby and javascript) and so returning now to a statically typed and compiled language just seems like its a new, shiny thing and I like shiny new things. And what better way to learn a new programming language than to actually build something with it?

This post will be part of a series of posts, where I will describe my process of building a command-line application in go. In this first post, I'll go over what the project is, why I'm building it, and how I intend to build it!

Why

I've always heard that tracking your time is a good thing. It allows you to review where you're spending your time and it gives you a better view on whether you're using your time effectively or not. It can also tell you how much time you spend working and procrastinating. There are tons of tools that can do this for you, but I wanted something that could be used via simple commands from my terminal, and which doesn't get in the way of doing what I set out to do (i.e, I don't want to spent too much time learning a productivity tool, because that would be... unproductive).

What

The tool I will be writing (go-tt) will allow me to say something like I'm now working on unit tests and, a few minutes later, I can say I'm now writing documentation for feature X. If I want to consciously take a break, like reading an article, I can quickly say I'm now reading an article. I should then be able to see at a glance the tasks I've been working on in the last day, week, month, year or in any other random period in time.

Requirements

It should be accessible via the command line and be easily installable via popular package management systems (like homebrew, apt, etc). However, installing it from source should be easy too.
It should work on all major operating systems.
It should be fast, with a few set of commands, which must be easy to use (which implies a low number of arguments for each command) and good documentation.
It should be free for modification and distribution, i.e, open-sourced.
The code should be extensible:
- Even though it will be primarily a CLI application, adding a GUI in the future should not be much of a trouble.
It should report the data in various formats: CSV, JSON, etc (more on this later).
It should contain as few dependencies as possible.
It should be well covered with tests.

Specification

Let's get into the nitty-gritty parts. In this section I will outline the major commands in the program, what they should do and how they should work. Note that things can (and most probably will) change during the development of the project.

Modules

UI: This module takes care of everything about displaying and receiving data from/to the user. Here we can have one submodule per UI layer: CLI, GUI, etc.
Persistence: This module takes care of writing/reading hard data. I will talk a bit more about the data we're going to need later.
Core: This module will contain most of the business logic. It will combine all the other modules to achieve the goals of the program.
Reporter: This module will handle the logic of taking the data and presenting it to the user (for instance, in CSV files). More on this later.

Operations

Do not confuse this with command-line commands, even though the syntax I will use may suggest that. This is an high level overview of the operations the program should accept.

add new activity

This operation creates a new activity in the system. For instance, one could create an activity named writing tests or attending meeting. An activity is identified by a unique identifier and can additionally have a description and a list of aliases. If the activity already exists, a helpful error message should be returned to the user.

start activity X | alias

Once this operation is executed, the program starts tracking the time that the user is taking to do the activity X. If activity X is not yet created, then it should automatically create it and start tracking it. Tracking here simply means recording a timestamp with the current system time. Only one activity can be tracked at the same time, i.e, the user cannot start two activities one after the other, unless the previous one is stopped (this is an explicit decision on my part: I don't want to encourage multi-tasking). An alias can be used instead to reference the activity.

stop activity X | alias

Once this operation is executed, the program records the current system time and calculates the total time spent on this activity by using the start time recorded early. If the activity X does not exist, or if it does exist but its not the current one being tracked, or if none activity at all is being tracked, an error message should be returned. An alias can be used instead to reference the activity.

delete activity X | alias

This operation deletes the activity X from the system. If the activity does not exist, an error is returned. This action is not reversible: deleting an activity will also delete all data associated with it. An alias can be used instead to reference the activity.

get report

This operation returns the tracked data of all activities or for a given specified list of activities in a given period. The user can decide which format he wishes the report to be in. More on this later.

list activities

This operation lists all activities currently registered in the system.

backup

This operation creates a compressed file (.zip or .tar, for instance) with all the data recorded for your activities since the beginning of time.

purge

This operation wipes out all the data in the system.

Data

As I've mentioned, in the first version, we're going to rely on the filesystem to persist data. The data we'll need is:

A list of tracked activities. (Activity metadata files)
A daily log where each activity start and end time is recorded (Activity Log files)

I can easily implement this using the file system with JSON files. (the choice here is arbitrary, we could easily just use plain .txt files, but I find working with JSON pleasant).

Activity Metadata

Each activity will have its own meta data file. The name of the file will be the identifier of the activity. For instance, for the activity activity-1:

{
  "identifier": "activity-1",
  "description": "Some description...",
  "aliases": ["alias1", "alias2"]
}

Activity Log

Each individual activity log has the following structure:

{
  "activity-1": [
    {
      "start": 1587231890,
      "end": 1587231901,
      "duration": "..."
    },
    {
      "start": 1587231920,
      "end": 1587231931,
      "duration": "..."
    }
  ]
}

I have yet to decide the data format for the duration key. The name of the activity log file will have the structure YYYY/MM/DD.json, for instance: 2020/10/01.json.

Each entry in the array for activity-1 corresponds to a cycle of starting and stopping the tracking.

For instance:

> go-tt start a1 # t0
# ...
> go-tt stop a1 # t1
> go-tt start a2 # t2
# ...
> go-tt stop a2 # t3
> go-tt start a1 # t4
# ...
> go-tt stop a1 # t5
> go-tt start a2 # t6
# ...
> go-tt stop a2 # t7

This would produce the following log file:

{
  "a1": [
    {
      "start": "t0",
      "end": "t1",
      "duration": "..."
    },
    {
      "start": "t4",
      "end": "t5",
      "duration": "..."
    },
  ],
  "a2": [
    {
      "start": "t2",
      "end": "t3",
      "duration": "..."
    },
    {
      "start": "t6",
      "end": "t7",
      "duration": "..."
    }
  ]
}

Combining every thing together, here's a possible folder hierarchy for the data describe above:

meta/
  activity-1.json
  activity-2.json
  ...
log/
  2020/
    01/
      1.json
      2.json
    02/
      10.json
  2021/
    03/
      1.json
  ... etc

This is madness!

Yes, I know! This solution has SO many disadvantages, including:

What if the files get corrupted?
What if the user manually changes the files?
What if the files disappear?
I have to load metadata and log files in memory to read/update activities and to create the reports! This is going to cause memory problems soon enough!
What about automatic/regular backups?
You're trying to be smarter than the guys that spent many years writing and optimizing databases for this kind of thing! Who do you think you are?

I know.

Since I'm new to the language, I think that learning how to do I\O is important, and this initial version will be the perfect playground to do it. Plus, if I write the code in a modular fashion, I can then plugin a DBMS like Postgres, SQLite or even Mongo easily. That will certainly come later on.

This is the kind of solution I would be ashamed to show publicly, and only work on it privately. But I want to share the process with you. I am aware this is not a good solution, but I must remind myself: this tool is built to be used by me first and foremost, and to learn go. On future iterations, I will certainly add a more robust layer of data persistence.

Reports

In this initial version, the reporting system is straightforward. It should accept three arguments: the format of the report (in this first version, I will write three report systems: JSON, CSV and directly in the stdout), the initial date and end dates (like: 2020-01-02 to 2020-01-04). The report (independently of the format) should present:

A list of activities tracked in that period.
For each activity, the total time spent on it.

For fun, we could show other aggregations like:

The average time spent in each activity per day/week/month.
The time of day where each activity is most performed.
The median of each activity.
The days of the week where each activity is most performed.
A graph (only possible in UI solutions) showing the evolution of the time spent in each activity in the period.
... any other ideas? Let me know!

Some of these can certainly come later on.

Notes

Aren't you worried that people might steal your idea? Absolutely not! Please, feel free to go ahead and implement it on your own as well! It would be fun to compare implementations later on!
Are you going to host the project on Github? Yes.
What will be the schedule of the posts? I will not set an explicit hard schedule to write posts for this series. After I have finished a major milestone in the project, I will then write a post about it.

Thanks for reading! If you find any clear and alarming problem in this first naive implementation, or if you have any other ideas you'd like to see, please let me know!

How do you find the time to participate on dev communities? (Such as dev.to)

Luís Costa — Mon, 23 Jul 2018 15:28:34 +0000

I'm just a bit curious to know how do you guys usually find time to participate in an online dev community such as dev.to (when I mean participate, I mean reading articles but also commenting and writing posts).

Do you do it at home, after work, before work, or at work during dead hours? I know it's a bit too specific, but I just would like to know how my fellow developers do it!

Redis - An Introduction

Luís Costa — Fri, 01 Jun 2018 08:41:26 +0000

What is Redis?

Redis is an in-memory key-value data store that you can integrate with your application to store volatile data. It’s volatile because once you quit Redis, all the data you’ve stored is lost.

It works by storing some value in a key. You can later on request “Give me the value for key ‘some_key’”.

It supports a wide range of data types such as strings, hashes, lists, sets, bitmaps, etc…

Do I need it?

Redis is typically used as a caching mechanism. For instance, let’s say your application has an endpoint that performs a computational-heavy task and returns a large json to the user. If you repeat this work over and over for every request, you are most likely introducing a bottleneck in your client-server communication. A popular solution for this is to perform the work once and then store the result in Redis. The next time the user makes the same request, your application simply checks if the result is cached and returns it.

Of course this pattern requires that you follow a set of rules:

Each result stored should be uniquely namespaced. In the example below, the result should cached per user id (for example) and any other additional parameters that can identify two requests as being the same.

You should enforce a TTL (time to live) in each result that you store in Redis.
A TTL of 15 minutes means that after 15 minutes, the result is wiped from Redis. In the example below, this means that 15 minutes after the initial request, a new user request would trigger the heavy computation on the server again. This depends on your application and user needs, so take some time to think about this.

Don’t overuse Redis. This is important. Redis is useful for some tasks, not all tasks. Use a proper database when appropriate. For instance, you should not store user credentials and preferences in Redis.

If you’re working with huge datasets, be very careful when doing queries on Redis. If your application performs several reads and/or writes to Redis per minute, one wrong query to Redis (for instance, listing all the keys currently existent) may introduce downtime, possibly breaking your entire application. This, of course, depends on the overall infrastructure of your application.

For the remainder of this blog post, I’m going to talk about the major data types that Redis supports and the basic commands for each. I will be using the Ruby implementation of Redis (which you can find here) and show you, as an example, how to set up Redis in your Rails application. There are ports of Redis for almost any programming language, and the public API should be pretty similar among them, so setting it up for your preferred development environment should be a simple matter of reading the README file in the official repository.

Setting up Redis in your Rails app

Simply append the redis to your local Gemfile

gem 'redis'

And then create a new initialiser class in your config/initializer folder called redis.rb with:

Redis.current = Redis.new(host: 'localhost', port: 6379)

You can also pass additional options depending on how you have configured redis such as a password, a path to a specific unix socket, a driver and a specific database name. Check the README file over at the official ruby gem for more information on how to configure redis.

General commands

These are commands that are not specific to a data type, rather to any redis key itself

Deleting a key
Redis.current.del('some key')
Checking if a key exists
Redis.current.exists('some key')
Get all keys in the database
Redis.current.keys

!! WARNING !! : Please avoid at all costs running the command above in your production redis server, because this operation has a O(N) complexity, where N is number of keys you currently have in Redis.

Setting a TTL in a key Redis.current.expire('some key', 5000)

The second argument is the expire time, in milliseconds. This means that the key 'some key+ will expire in 5 seconds.

Renaming a key Redis.current.rename('some key', 'new key')

If you don’t know or don’t remember which data structure is currently held by a key, you can ask redis to inform you:

Redis.current.type('key') => 'String', 'Set', 'Hash', ...

If you really want to perform a scan over all your keys in Redis (for instance, to check if a key with a particular pattern in its name exist), the correct way to do it is with the scan command.

For instance, let’s say our current Redis database holds 1 billion keys and you want to know if there’s any key with name pattern some:cache:key. You do not, I repeat, you do NOT execute the command Redis.current.keys and iterate over the returned collection to find it. Not only will you probably kill your application memory, but you will also probably kill redis.

You’ll use scan for this. This command allows you to iteratively look for keys in the database using a cursor. You provide it with an initial cursor, redis will scan the next N keys (configurable), and then return you the next cursor (and the keys scanned) that you should use in the next call.

For a correct use of this command, you should stop scanning whenever redis returns 0 as the next cursor. This means that there’s no more keys to scan. In our example above, to find a key that contains the pattern some:cache:key we would use scan in the following way:

Redis.current.scan(0, match: '*some:cache:key*')

The asterics before and after the pattern means ‘I don’t care whatever is before or after this particular pattern, so the key random:some:cache:key:random would match.

The first call would return, for example, the iterator 1000 and whataver keys match the pattern. Given that the iterator is not 0, we can continue:

Redis.current.scan(1000, match: '*some:cache:key*')

This call would return the iterator 10, so we continue:

Redis.current.scan(10, match: '*some:cache:key*')

This call would return the iterator 0, so we know that there are no more keys that match this pattern. It goes without saying that you should keep a list of the keys that have matched, from the result of each scan command.

Strings / Integers

In this section we’l learn the basic operations around storing and retrieving string and integer values from redis.

Storing a new string value in a key
Redis.current.set('mykey', 'myvalue')
Retrieving the value of the key mykey
Redis.current.get('mykey') => 'myvalue'
Setting a new string value in a key, unless it already exists
Redis.current.setnx('mykey', 10) => false (because the key 'mykey' already exists)

Redis.current.setnx('another key', 10) => 'OK'

Hashes

A hash in Redis is a data structure that can hold several key — value pairs (just like a hash in Ruby)

Creating a new key/value pair in a hash:
Redis.current.hset('myhash', 'my hash field', 10)
Retrieving the value of the field my hash field in the hash myhash :
Redis.current.hget('myhash', 'my hash field')

There’s also a way to create a hash with multiple fields in a single command:

Redis.current.hmset('myhash', 'field 1', 'value field 1', 'field 2', 'value field 2', 'field 3', 'value field 3')

Here I’m showing examples with strings, but of course you can also store integers, and even json dumps, for instance:

Redis.current.hmset('myhash', 'field 3', '{\" key \": \" value \"}')

Likewise, you can also retrieve the values from multiple fields in a single command

Redis.current.hmget('myhash', 'field 2', 'field 3') => {'field 2' => 'value field 2', 'field 3' => 'value field 3'}

Deleting one or more fields from a hash Redis.current.hdel('myhash', 'field 2', 'field 3')

Retrieving the full hash stored in a key
Redis.current.hgetall('myhash') => {'field 1' => 'value field 1', 'field 2' => 'value field 2', 'field 3' => 'value field 3'}

Lists

Prepend a new element to a list (add to the beginning of the list):
Redis.current.lpush("mylist", 10)
Append a new element to a list (add to the end of the list):
Redis.current.rpush("mylist", JSON.dump({ some_hash_key: 2}))
Removing elements from a list
Redis.current.lrem("mylist", 1, 10)

The method lrem accepts three arguments. The first argument is the name of the key holding the list, the third argument is an element that we want to delete from the list, and the second argument is an integer that:

When 0, it will remove all elements in the list equal to the element we want to remove. For example, if we had several elements in the list with the value 10 calling Redis.current.lrem("mylist", 0, 10) would remove all elements in the list with the value 10
When positive, will remove the first element matching the element that we want to remove, starting from the head of the list to the tail
When negative, will remove the first element matching the element that we want to remove, starting from the tail of the list to the head
These last two options are useful if, for example, you’d like to remove the first or the last occurrences of a given element in a list
Getting the elements of a list
Redis.current.lrange("mylist", 0, -1)

The second and third argument of this method specifies the range of elements that we want. When using 0 and -1, it means that we want all elements starting from the beginning until the end. If we’d like only the first two elements we’d have to write Redis.current.lrange("mylist", 0, 1) , and so on.

If you don’t know the current size of your list:
Redis.current.llen("mylist")

Sets

Sets are useful if want to keep a data structure with unique elements.

Adding new elements to a set Redis.current.sadd("myset", "myelement")

Note that if the element “myelement” already exists in the set “myset”, it is ignored and thus not added

Removing elements from a set
Redis.current.srem("myset", "myelement")
Getting all current members of a set
Redis.current.smembers("myset")
Checking if an element is already in a set
Redis.current.sismember("myset", "myelement")

Final thoughts

The list of commands presented here is just a quick “cheasheet” that you can use to quickly look up the most common use cases of Redis. For a list of complete commands, check the official redis documentation.

Finally, please be aware of how you’re using redis. If redis is on a different machine than the one running your application, consider that each redis call is a network request. Also, be very careful with commands that return everything from a list, like smembers , lrange , hgetall , etc. If your application is very big, you may not only flood your application memory, but also possibly block redis for a while. Always, always, use iteration based search, such as scan .

Thanks for reading!

How/When do you make time for side projects?

Luís Costa — Mon, 09 Apr 2018 12:44:43 +0000

Before work? After work? During the day? At your job? How do set up your routines and days to allow time for side projects?