Categories
remote work slack

Slack journal is my office blog

I use slack at work, which is not a surprise as many teams do. Our team is also remote, not fully remote but everyday some part of the team is not in the office. This changes how we work together, and it in my opinion affects communication most. To tackle problems with remote teams it is best to look for advice from companies that are remote as they most probably solved it already. While looking for such advice I found a great guide to remote teams. It has 4 chapters on: hiring, communication, management, and culture. I highly recommend reading the whole guide.

What I have focused on is communication, as this was issue that in my opinion caused most problems. Too little exchange will cause misunderstandings, and may give false impression that no one is working and little is going on. Decisions made without notifying all team members may cause misunderstandings as well. Such decisions are sometimes made in a channel, or in a private talk, or during a meeting.

To improve visibility in what I’m working on I have started keeping a journal on Slack, as described in chapter on communication. I’m documenting what I do, what I read, and my thoughts and opinions on different tasks or projects, for more than a year now.

My slack journal

Journal allows my colleagues to chime in on my channel as well. Numerous times someone had jumped in with a great advice regarding some problem I had been struggling with, or simply with some tool that would solve it, or with a new library I should be looking at. I find it really helpful, as I can track my work during the week so when filling time sheets I can review what I’ve been doing. I’m really bad at keeping track so this solves one of my issues. While writing my journal I have received a lot of new information back, hopefully helped someone, and what is most important provided a visibility in what I do when you can’t see me.

Other thing we are trying is documenting every important decision for others to read. Not everyone can attend a meeting, video call or a small face to face discussion and it is vital to pass this information to other members of the team. So there is no urgency to attend everything, and there is no FOMO as all will be documented.

Categories
elixir patterns

Actor model

Motivation

One of my resolutions this year is to review my notes from each conference I visit and read/learn/build something. Quite recently I have been for the second time to Lambda Days in Kraków, where I got interested in Elixir. It is functional, what is dear to me but more importantly it is built for concurrent computation. This is achieved by shared nothing architecure and actor model. It means that each actor, or process in Elixir land, is independent and share no memory or disk storage. Communication between processes is achieved by sending messages. This allows building systems that are concurrent with less effort. Since it is so helpful I’ll try to understand what actor is and hopefully explain it here.

This is not a full explanation by any means but rather a primer before I implement my latest project using this computation model. It is possible that my knowledge will be revised along with a new post.

What is the Actor Model

Actor is a model of concurrent computation. It has the following properties or axioms. (I have shuffled them a bit to emphasise messaging as IMHO important part of this model).

  • Can designate how to handle next received message
  • Can create actors
  • Can send messages to actors

Let’s unpack those properties to make it more clear. "Can designate how to handle next received message", so actors communicate with messages. Each actor has an address as well, where messages can be send. And it is up to an actor how will it respond if at all.

"Can create actors" is pretty simple, each actor can spawn other actors if required by performed task.

"Can send messages to actors" as mentioned while describing first axiom communication is done via messages. Actors send messages to each other.

One actor is not really an actor model, as mentioned in one of the articles, actor come in systems.

This is short and simple, it is the jist of it with focus on most important parts of actor model. What I find valuable is the fact that this model brings software failures to the front and forces solution designer to appreciate and expect them.

I find it similar to OOP created by Alan Key and described here

OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I’m not aware of them.

When to use it?

If you are having a task that can be split into stages, may be linked or independent. In such case I find actors more palatable than locks and threading. This is kind of thing that Broadway library for Elixir is trying to solve. Actor model may also be used when thinking about OOP, it might not be possible to implement actors in such way that they are independent at the level this model expects, but thinking in such terms may improve resilience of the project.

Resources

I know I have skimmed this topic and if you are interested please have a look at resources I used to grasp the idea of actor model.

Categories
python

Redis cache

I enjoy listening to podcasts, as they sometimes give me inspiration to create something. In one of the episodes of Python Bytes podcast guys mentioned https://github.com/bwasti/cache.py tool. cache.py allows to cache function calls across runs by using cache file. Simple and really useful.

This inspired me to write a similar thing but for distributed apps, based on redis as a cache storage. I called it rcache and you can find it on PyPI.

In order to use it simply decorate a function like this:

import rcache

@rcache.rcache()
def expensive_func(arg, kwarg=None):
  # Expensive stuff here
  return arg

Default redis address is http://localhost:6379, but you can change it by passing an url into the decorator @rcache.cache(url="http://your_redis:6379").

I hope you find it useful and if you wish to comment or report something please go to https://gitlab.com/the_speedball/redis.cache.py/issues.

Have fun