Ylan Segal

The REPL: Issue 50 - September 2018

How to teach yourself hard things

Julia Evans writes a great article on how to learn… to learn. In her traditional straight-forward fashion, she describes the method she has used to learn things that are difficult. She breaks the process down into approachable skills that anyone can learn (e.g ask questions, have confidence in your knowledge). I also recommend following her on twitter. She posts comics often about unix tools: I always learn something knew from them.

Distributed Agreement on Random Order – Fun with Lamport Timestamps

If you’ve ever done some digging into distributed computing, you will have heard of Lamport Clocks. In this post, Quentin Duval, details step by step on how to construct an application that uses Lamport’s algorithm for reaching agreement on the order of events across a distributed system.

Upgrading GitHub from Rails 3.2 to 5.2

Working as a Rails developer, I’ve found myself a few times in the same situation GitHub was: Relying on an old version of a framework that has now become a liability, and upgrading is anything but straight forward. In this post, Eileen Uchitelle describes the strategy that GitHub used to upgrade. I especially like the section about lessons learned: It’s one of my favorite things about the software community. The willingness to share with others allows us to learn from each other. Thanks Eileen!

The REPL: Issue 49 - August 2018

Cost of a Join

Brian Davis writes a detailed post of how expensive it is to do join queries in postgres. The details are very interesting, as is the conclusion: Join operations are usually cheap.

Elixir: a few things about GenStage I wish I knew some time ago

I’ve recently started working on an Elixir project that seems perfectly suited to use GenStage. In this article Andrei Chernykh complements the GenStage documentation and explains how to use it in an approachable manner.

What they don’t tell you about event sourcing

Hugo Rocha writes about the pitfalls of using event sourcing. Like most engineering techniques, it is not a perfect fit for every situation. In fact, I believe event sourcing is a sufficiently different paradigm to traditional CRUD applications that it makes it difficult to approach in a iterative manner that other techniques can be incorporated into existing systems.

Why JWTs Suck as Session Tokens

Randall Degges writes a good primer on what JWT tokens are, what security guarantees they give, and what problem they are a good solution for. Namely, using them in distributed systems to reduce inter-service calls to verify authentication (or other claims). As the title not-so-subtly suggests, they are not great as session tokens. Most web frameworks already have this problem solved. There is no need to re-invent wheels that are rolling just fine.

On Taking Notes

For over a year now, I’ve started taking methodical notes as I go about my daily work as a Software Engineer. I find the process worthwhile.


As I work on my daily tasks, I keep a note with my current plan and findings along the way. The very act of writing things down forces my thoughts to be more concrete. Putting my thoughts into words makes my assumptions explicit, often resulting in illuminating any gaps in reasoning. I find this is very similar to “rubber ducking”.


Taking good notes makes it easier to find the at a later time and use as reference. I find that there is no need need for specific tagging and organizing. Simple text search (grep) is enough to find previous content quickly. I find that I now regularly rely on being able to go back to my previous notes.


When learning new tools, writing down specific instructions, CLI commands, etc helps cement the new knowledge. My preferred style of learning usually a mix of learn-by-doing enhanced by documenting the steps I took.

How I Take Notes

  • Markdown: I prefer a plan text format. I favor markdown because of it’s simplicity and support for code blocks with syntax highlighting and checklists. It’s also becoming ubiquitous in many tools I use.
  • Atom: My current editor of choice. A few plugins make it particularly useful: pipe for executing against external commands, wikilink for lightweight linking between notes.
  • Synching: My notes are regular files, so they can be synched with any service (eg. Dropbox, iCloud, etc). I usually don’t need my notes on my phone, but those services makes them available when I do.
  • Daily Note: I usually start a fresh notes each day. It’s like a dashboard of all the things I have going on. It’s pre-populated with the items from the previous workday that were not completed (in Franklin Covey style). It serves as a scratchpad too. I link to notes that are more in depth for specific projects or tickets.
  • Weekly Note: At the end of each work week I conduct a personal retrospective and write down my thoughts. It helps with keeping a big picture of what I am working on and my effectiveness at work.

I’ve found that t first taking lots of notes felt tedious. Now, I feel that it’s very helpful to my daily tasks. I recommend it!

The REPL: Issue 48 - July 2018

Web Architecture 101

The world-wide web is built on top of many abstractions. That is what makes it powerful. As a user, we are typically just concerned with a browser and a “site”. When I first started programming for the web, I learned about HTTP, request and responses. Sometimes, one needs to dig deeper into common architecture patterns. In this article, Jonathan Fulton covers some of that architecture: DNS, load balancers, web and application servers, databases, caching. I found it to be a very useful reference. Note: As is always the case with computers, there are more levels of abstraction to learn: TCP, IP, UDP, TLS, etc.

Scaling the GitLab database

Yorick Peterse discusses some of the scaling issues that GitLab went through and how they resolved them. I find these type of articles very enlightening. Both for the solution they chose and for those that they discarded: Your particular scaling problem might look different, making one of those solutions more attractive.

Queries on Rails - Showcasing Active Record and Arel

Pedro Rolo discusses how to go beyond basic queries with ActiveRecord and Arel. I personally use techniques similar to the ones outlined in the article often. Caution: Arel is considered private API by Rails maintainers. If you decide to use it, there might be some work needed to ensure your code works when upgrading Rails. I’ve never had a significant problem with that, provided that I have good tests around complex queries. I much prefer Arel to using long and complicated sql fragments as strings. I believe those are even more brittle.

On Remote Work

A few months ago I changed jobs. My previous job was at a large software company, with offices worldwide. My day-to-day activities routinely included conference calls with people in the Americas, Europe and Asia. For the most part, these were coordinations meetings. My most meaningful collaborations were with the people sitting around me: The members of my team.

My situation now is quite different. I work for a much smaller company, in number of total employees. My team all works at headquarters, but I come in most days to a company office located in a different city. In practice, this makes me a remote worker. I’ve had time to make some observations about that type of work. My experience relates specifically to software engineering, but I imagine that it could also apply to other similar type of work.

Embrace Asynchronous Communication

When working in the same office, it’s relatively easy to tell when it’s appropriate to interrupt someone: They are preparing coffee, returning from a break, or are in between meetings. When working remotely, I am more careful about other’s time, since I don’t want to break their concentration. This is especially true if I need some input, but don’t need it right now.

Asynchronous, written communication helps. I can send someone an email or ask a question in a PR. While they respond, I can continue with other tasks. At first, this switching between tasks was difficult. With practice and a good organization system, this has become much easier. Now, I generally work on my tasks until I need input, request it asynchronously and switch to something else in the meantime.

Work At The Same Time

While asynchronous communication makes it easier to work remotely, there is such a thing as too much of a good thing. If members of a team work in widely different timezones, effectively collaboration can be very slow. I’ve experience this before, when I was assigned to lead and teach a team based in India – 11.5 hours away. It was challenging, because all the communication was in written form and, for all intents and purposes, delayed for a full work day. No matter how small the question was, it was never answered until the next day.

Working at the same times as your co-wokers – at least for a portion of the work day – allows for faster feedback cycles and the possibility of jumping on a call when written communication just doesn’t cut it.

Video Calls

The next best thing to in-person communication is video calls. There is a certain awkwardness inherent in them. In particular it bothers me greatly that because of where the camera is positioned, participant never seem to look each other in the eyes. That nitpick notwithstanding, video chat is much richer than just audio: Seeing other’s facial expressions conveys a lot of meaning. Using your computer as a communication device has some issues. I always have many windows open. When on video calls, it’s easy to allow myself to get distracted and peak into another window: Email, chat, the code I was working on. Pretty soon, I’ve stoped paying attention to the conversation. To avoid that, I’ve started combating the temptation by minimizing all windows except for the video call, having the video window in my laptop’s screen while sitting directly in front of it– to simulate as much as possible looking at the other people in the eyes. This has made me much more engaged in conversations. If I still need to fidget with something, I doodle on paper or turn to my current favorite fidget: A Rubik’s cube.

For video calls to be effective, they need to be high quality. A reliable internet connection is needed, but not enough. There is no shortage of video call providers. I’ve tried many. Their quality is much different, and it makes a big difference. Poor audio quality, or “lossy” connections make it hard to have good conversations. In my experience, Zoom quality is much better than others, including Slack and Skype. Google Hangouts seems to have good quality, too, but I’ve only used it a handful of times.

In the same vein, as a software engineer, I find myself talking about code a lot. Sharing my screen, or seeing some else’s screen, has been essential to good communication. A picture is worth a thousand words.

Everyone Needs To Be Onboard

Collaborating remotely only works if others are willing to collaborate with you in that way. On teams were this is effective I’ve observed that: - All meetings are by default remote, even if most participants are sitting in their desks in the same building. - Any agreement reached or significant exchange of information exchanged in person needs a follow up for the benefit of remote workers. Posting about in Slack, email, or commenting on the next standup is usually enough. As a bonus, this minimizes misunderstandings for the original participants.

Occasional In-Person Collaboration

In-person communication is still the highest-bandwidth form of communication. I travel roughly every two-months to spend a few days with the team. Eating lunch or dinner, and having the occasional beer with teammates helps for closer relationships. I consider some travel to be a necessary evil of remote working.


So far, I’ve been really happy working remotely. Most challenges I’ve faced, have been solved easily, not in the least because I am lucky to have a very supporting team and manager.

If you are thinking of working remotely, I recommend you prepare yourself for it. I recommend reading Remote, by Jason Fried and David Heinemeier-Hanson.