I’m leaving Zalando with fond memories after 4 years. Here I’m writing down my experience. It’s never comprehensive, but I hope some people find it interesting!

Beginning

I had lived mostly in Japan for 34 years until 2016. I wanted to travel more, but I was lazy. I decided to work abroad so that I could travel while earning money.

A job-matching website called Honeypot introduced me to Zalando. I had 5 interviews and got an offer for Senior Software Engineer (Frontend). I accepted the offer without looking into any other companies because I liked the interviewers and the company’s OSS projects looked interesting. (Honeypot was very happy about it. They put me on their top page and an interview blog post.)

I moved from Tokyo to Berlin and joined Zalando in October 2016. With 200 other newbies in a month! Zalando is a fashion e-commerce company that sells shoes, clothes, etc. on its website. I had no clue why they needed so many people at the beginning. Isn’t it a website in the end? I later learned that the visible part of the website was the tip of the iceberg. There were many more areas like wholesale, brand relationship, pricing, warehouse management, shipping, payment, and so on.

Team(s)

In 2016, Zalando was hiring software engineers with pool hiring. We were hired without specific teams to join. After a month of onboarding, each newbie was offered two departments to choose from. I chose the Catalog and Navigation team in the Fashion Store, the e-commerce website of Zalando.

For the first few months, I thought that the company was providing free beer to employees because fridges were always full of beer bottles even if we drank them a couple of times a week. I later learned that the beer was provided by the delivery lead and the product owner of the team. I joined the right team.

Aside from the beer, I liked the team. We worked together and played together. It was multi-cultural and magically bonded. It was an old team, but several members including me joined the team in late 2016. We learned the German language and explored the city of Berlin. We had BBQs in a park and drank vodka playing games in the office. It felt like a youth again. Some of the teammates were actually young. After two years or so, we stopped drinking as much as we did. We all became grown-ups...? Maybe.

Through re-organizations, the shape of the team has changed. It was split into multiple teams. Some people left and new people joined. But I stayed in the same area more or less.

Frontend engineer...?

At Zalando, frontend engineers were more like JavaScript fullstack engineers.

In 2016, Zalando had a slogan, Radical Agility. It promoted team autonomy and Microservices to support it. Each engineering team was supposed to operate what they built on top of the STUPS infrastructure. Frontend was not an exception. Mosaic (frontend-microservices architecture) allowed each product team to own their Node.js servers for data aggregation and React server-side rendering in addition to frontend components.

The team’s responsibilities were broad. Building new features and UI improvements with A/B testing, contributing to shared UI components, web performance optimization, Node.js server operations, 24x7 on-call, writing post mortems, and so on.

In the new architecture that the Fashion Store is moving to, product teams don’t need to maintain Node.js servers. I would miss the burden, but I think it’s a good thing.

Operation and reliability

I had a good opportunity to work on Node.js servers with serious traffic and business impact. Before joining Zalando, I had worked only on products that didn’t take off or were just taking off. I didn’t have much experience in scaling, monitoring, etc. But writing post mortems became one of my favorite activities after 4 years.

When my team migrated one of Zalando’s most frequently visited pages to the microservice architecture, our journey in this area started. Even among frontend engineers in the team, some of them were frontendy—good at UI—and some of them were backendy. I was a backendy one and started looking into the topic. I found it interesting. It was a nice way to contribute to the team and the business.

I glimpsed SRE initiatives and Cyber Week preparation being set up and evolving. How Zalando prepares for Cyber Week is a great overview of the evolution. I had a good chance to take part in it as a member of a product team. The people who formed the SRE team taught us monitoring, alerting, and reliability patterns (retry, circuit breaker, fallback, etc.). Incident response and post mortems were standardized. Then distributed tracing and adaptive paging were introduced.

Some of my contributions were reliability improvements of Node.js services. I researched timeout mechanisms of Node.js HTTP client and added a timeout feature to an HTTP client library. Built a mitigation strategy for DNS timeouts, improved histogram metrics aggregation, performed profiling and found interesting findings—I had a chance to talk about it in front of a big audience including TC39 folks... I was nervous!

I was late to the Kubernetes train. The migration from STUPS to Kubernetes didn’t get enough priority in my team. On the other hand, Zalando was an early adapter of Kubernetes and has been a strong contributor to the ecosystem. I missed a good learning opportunity to dive into it and learn from the in-house experts.

Web performance

Another topic that I enjoyed was web performance optimization. It was especially rewarding because it directly contributes to customer experience and the e-commerce business. After my team worked on it, I had an opportunity to write a part of a blog post about the improvements.

This topic keeps evolving. New metrics like Web Vitals and more measurement/optimization techniques came out. It is one of the topics that I would want to pursue if I remained at Zalando.

Cross-team collaboration

I had a chance to work with many other teams in the Fashion Store and other departments. I met and worked with literally hundreds of colleagues. I had never worked with so many people before joining Zalando.

That meant more meetings and alignments. I learned decision making with writing. I still don’t say that I’m good at it, but Google Docs became my favorite editor next to Vim.

I learned that it can be fun to work with many teams. Sometimes it was frustrating because of the time consumed. But it was rewarding to meet with many colleagues and work together.

Career

I saw good examples of career paths. Before joining Zalando, I imagined only two paths for software engineers. Staying as a senior engineer (or a lead engineer) or becoming a manager. It was great to see another path, being a senior individual contributor who takes technical leadership. At Zalando, it’s called Principal Engineer. In addition to technically leading projects, they shape the tech landscape of the company beyond the scope of a team.

I was fortunate enough to be promoted to a principal engineer this year. A new role gave me new tasks and a new point of view. It’s one of my regrets to leave this role prematurely.

Fun

I had a lot of fun.

Lunch tours to Schlesisches Tor. Countless drinks at the office. After-drink burgers at Burgermeister. A team event on canoes. Summer BBQs in a park. Company parties with thousands of people and getting lost. Mett —German traditional breakfast of minced raw pork—with some beer in the office at 11 am. Ordering Maß at lunch and learning what it meant when 1L of beer arrived...

Next

It’s been a fun journey. I’m grateful for all the opportunities and learnings. If I went back to 2016, I would do it again.

I’m going to start a new job tomorrow. I hope it will be fun as well!

I like fountain pens and good notebooks. They spark joy when I write on paper. Computer terminals are like stationery. A good terminal setup makes it fun to work with computers. Here is how I improved colors on my terminal and made it easy to switch them depending on the time and the mood.

Using official color schemes

I have been using Dracula color scheme on Vim and Alacritty for a while. I liked the colors, but I had a small problem with it on Vim. The pop-up of coc.nvim had the same color as the background color, and it was hard to distinguish a pop-up and the background.

I was using Dracula from vim-colorschemes, which hadn’t been updated for three years. I tried the official Dracula color scheme for Vim. It had a different background color for pop-ups! Yes, it’s subtle, but now I can distinguish pop-ups from the background.

vim-colorschemes is a great way to try out different color schemes. You can get a random color scheme by :colorscheme random. But once you pick a few favorite ones, it’s worth checking if they have official color schemes that are likely to be more maintained.

The same goes for Alacritty. I was using the Dracula color scheme that I converted with my tool from iTerm2-Color-Schemes for Alacritty. Dracula has its official Alacritty theme, and it looks better!

termguicolors

I started trying other color schemes and found Vim’s termguicolors option in ayu-vim’s README. It enables true colors (24-bit colors) instead of 256 colors (8-bit).

if has('termguicolors')
  set termguicolors
endif

I turned it on, and the colors looked gorgeous! Before learning about termguicolors, I had tried light color schemes like Ayu Light and given up because of too low contrast (left in the following image). With termguicolors, light color schemes became finally usable!

Switching color schemes

After trying dozens of color schemes, I picked the following:

• Ayu Light: Good in the morning or at a place with natural light.
• Pink Moon
• Nord: Low-contrast theme. Good in the night.

I started switching color schemes depending on the time and the mood and bumped into a couple of issues. It was tedious to update the color schemes of Vim and Alacritty together. Also, I manage my .alacritty.yml and .vimrc in a git repository. It was annoying that the repository had unstaged changes every time I switched color schemes.

Solution

Alacritty

I decided to remove .alacritty.yml from the git repository and generate it out of a base template and color scheme files. Once I prepared a YAML file for each color scheme, it was quite easy with a one-liner.

cat alacritty/base.yml alacritty/${color}.yml > .alacritty.yml

Vim

I could have generated .vimrc, but it felt weird because VimScript is a programming language. Instead of generating the whole .vimrc, I decided to generate a color scheme file .vim/color.vim, which is in .gitignore

echo 'let ayucolor="light"\ncolorscheme ayu' > ~/.vim/color.vim

and load it from .vimrc.

let color_path = expand('~/.vim/color.vim')
if filereadable(color_path)
  exec 'source' color_path
else
  " Default color scheme
  colorscheme pink-moon
endif

Putting them together

Then, I created a shell script named colorscheme to switch color schemes of Vim and Alacritty together.

#!/bin/sh

color=$1
dotfiles=~/dotfiles
alacritty=${dotfiles}/alacritty

configure_alacritty() {
  cat ${alacritty}/base.yml ${alacritty}/${color}.yml > ${dotfiles}/.alacritty.yml
}

configure_vim() {
  echo $1 > ${dotfiles}/.vim/color.vim
}

case $color in
  dracula)
    configure_alacritty
    configure_vim 'colorscheme dracula'
    ;;
  nord)
    configure_alacritty
    configure_vim 'colorscheme nord'
    ;;
  pink-moon)
    configure_alacritty
    configure_vim 'colorscheme pink-moon'
    ;;
  ayu-light)
    configure_alacritty
    configure_vim 'let ayucolor="light"\ncolorscheme ayu'
    ;;
  *)
    echo "Supported colorschemes: dracula, nord, pink-moon, ayu-light"
    exit 1
    ;;
esac

Now I can switch color schemes with only one command! (I still need to restart/reload open Vim sessions, but I can live with it.)

colorscheme ayu-light
colorscheme nord

If you are curious about the full setup, check out my dotfiles repo.

Summary

• Official color schemes may have more features than color scheme bundles
• Enable termguicolors on Vim
• Switch color schemes with a command!

Textile is a markup language that is similar to Markdown. This blog had had posts written in Textile for more than a decade—I feel old now! I removed the Textile files last weekend. This post is a memoir on the markup language.

I started using Textile on a blog engine called Textpattern. I don’t remember exactly when, but probably around 2004 or 2005. I was a university student. Movable Type was the most popular blog engine at the time, but it changed its license towards a more commercial one. Textpattern was a new open-source software. I fell in love with its minimalism. There were not many Textpattern users in Japan. Information in Japanese was very little if not none. I read documentation and forums in English and translated some into Japanese with a few fellows whom I had never met in person.

After a few years, Wordpress became a thing, or I realized it did. Even after I moved to Wordpress, I kept writing in Textile. I liked editing Textile more than editing rich text on WYSIWYG editor. I am not sure whether I had heard of Markdown at the time. But it was not as popular or dominant as it is now.

I started this blog with Textile on Wordpress in 2008 when I started my first job. And I migrated it to Octopress in 2012. I started writing in Markdown with Octopress because it was the lingua franca of GitHub where all the cool things were happening. I had a bit more than a hundred posts in Textile. I kept them in Textile because Octopress supported Textile as well. In 2014, I rebuilt this blog with a handmade static site generator using Gulp. I carried the old Textile files over. I even wrote gulp-textile plugin, which was just a thin wrapper of textile-js. It was my first npm package.

Since then, I implemented a few Markdown-only features like syntax highlighting and responsive table in this blog. The outputs of Markdown and Textile diverged. Last weekend, I wanted to implement responsive images. One more Markdown-only feature. Then I thought it was time to convert the Textile files to Markdown.

Converting Textile to Markdown

I didn’t want to convert a hundred posts by hand. I had tried tomd a few years ago, but I was not satisfied with the result. The old Textile files had raw HTML tags and some classes for styling. Also, I was afraid of missing some details that I don’t remember anymore. So I decided to write a conversion script.

I used textile-js to parse Textile. It turned out that textile-js output HTML string or JsonML. JsonML was new to me. It is basically HTML in JSON format. Each text node is represented as a string. Each element node is represented as an array whose first item is the tag name, an optional second item is an object of attributes and the rest are child nodes.

<a href="https://foo.com"><img src="foo.png" alt="Foo" /> Yay</a>

[
  "a",
  { "href": "https://foo.com" },
  ["img", { "src": "foo.png", "alt": "Foo" }],
  " Yay"
]

I wrote a switch statement to handle tags and added tag handlers one by one.

switch (tag) {
  case "img":
    return /* render <img> */;
  case "a":
    return /* render <a> */;
  default:
    throw new Error(`Unknown tag: ${tag}`);
}

I also added console.log for unknown attributes. In this way, I was able to make sure that all tags and attributes were handled. The script worked well to convert more than one hundred posts. The full script is on Gist.