I was working on a logger that writes metrics every time a warning or an error is logged. I tried to provide additional metric tags depending on the log annotations. And it didn't work. I was adding an annotation and I could see its value somewhere deep in the stack trace but the annotations value was empty.
Turned out that ZIO has two log annotation mechanisms that work in parallel.
At the time of writing this, urmaul.com is a static blog with privacy-friendly dynamic elements. Everything runs self-hosted on a single virtual server with an automatically updated Linux.
This is a description of every layer with some reasoning and configuration details.
This post is a confession about multiple overlapping mistakes we made when trying to measure API request times. These errors went unnoticed for months because wrong statistics still look realistic. Hopefully, this post will help you avoid such fails.
There's one programming puzzle I solved many years ago but I still remember it because of the unusual solution.
Problem: You have a text encrypted with a simple monoalphabetic substitution cipher. You don't have the key but you have a dictionary. Every word in a text can be found in this dictionary. Find the original text.
It can be solved by dynamically generating regular expressions.
Problem: Imagine a sequence 1504170715041707*n mod 4503599627370517 where n is an integer increasing from 1. Find the subsequence of this sequence where every next element is smaller than the previous one.
All the solutions I've read about include brute force calculations. I found a better one, and I can't stop myself from posting it.
TL;DR: You can create a Yeoman generator for your CI/CD pipelines. It's good, I tried.
Once you start multiplying services, you hit a problem of increased effort spent on non-business logic. With every new application you need to setup all the boilerplate: initial project, dependencies, running tests, building and deploying everything. Most of this things are very similar from project to project but they differ in details so you can copypaste a lot but you need to do it carefully so you don't break a lot of stuff by forgetting to update one line in a copypasted file. This needs a better solution.
TL;DR:I've created a typescript library fp-ts-type-check. You can use it to validate the structure of data you get from outside of your application.
Here's the situation: your typescript application needs to retrieve some object via some API. You make an API request and you get a successful response with some json. Probably it's the data you expect but you can't say for sure. Your actions?
Once upon a time, I wanted to get a rubber duck. One rubber duck. I spent a lot of time looking for a perfect yellow rubber duck not representing any character and finally, I have found and bought it.
Later I accidentally found a much better rubber duck. I bought it also. That's one more rubber duck than I but I wasn't cruel enough to throw first one away. A big mistake.
This is the last part of my learnings during writing a sudoku solver. It's about several iterations of a property-based test refactoring in an attempt to find the best way to generate input data.
I keep writing about my learnings during writing a sudoku solver. This time we touch solver's logic and I have something to share about making the big functions out of the small ones.
Sometimes you're trying to solve a puzzle so hard so you have to write a program to solve it. That happened to me with one specific sudoku so I wrote a sudoku solver.
I did some learning during this and I want to share them here. This part is about injecting validation into the type system.
As a PHP developer, I should probably rejoice when someone's saying "we do microservices in PHP". I don't. I'm fine with PHP and I like microservices but the combination is just bad. PHP is a tool for solving a narrow range of tasks (i.e. making websites) and if you're trying to do something out of this range (i.e. making microservices) — you're gonna have a bad time.
In this post, I tried to collect all microservice-related PHP problems I saw over the years.
I'm currently learning functional programming with scala and as a practice I've implemented FizzBuzz. To be honest, I made three different implementations of FizzBuzz but only the third one is good.
Stream.from(1) # Create infinite lazy stream from 1
.map { (_, "") } # convert it to (number, word) tuple
.map { x => if (x._1 % 3 == 0) (x._1, x._2 + "Fizz") else x } # Add "Fizz" to each 3rd word
.map { x => if (x._1 % 5 == 0) (x._1, x._2 + "Buzz") else x } # Add "Buzz" to each 5th word
.map { x => if (x._2 != "") x._2 else x._1.toString } # Take word or number
.take(30) # Limit stream length
.foreach(println) # Run everything and print results
It's even much better than usual imperative implementation and here's why.
React Styleguidist uses external Markdown files to store usage examples. We wanted to use TypeScript for examples because reasons and we managed to do this with horrible solution. It includes custom webpack loader that parses TypeScript file with regular expressions and converts it to markdown. You could find parts of our code below.
Imagine you have two groups of date ranges and you want to determine whether they overlap.
Nah, let's make it harder. Imagine you have two groups of include date ranges and two groups of exclude date ranges. Your task is to determine, whether there's a date that is present in both include groups and not present in exclude groups. How to do that?
Imagine a wooden ship. It's a quite famous ship - Theseus himself used it to return to Athens from Crete. After that Athenians tried to preserve it by replacing decayed planks with new ones. Many years passed and now we can say for sure that every part of the ship was replaced at least once. Is it still the same ship?
I had to fix performance issues of one API endpoint. A pretty Symfony endpoint that gathers some data from database, assembling it to some structure and returns it as json.
Performance started being an issue when major part of that "some data" started to be 60000 entities. In worst case response time was almost 20 seconds. "Ok", I thought, "60k is a big enough number to make it slow". But trace showed that retrieving data from DB isn't a slowest part. There were things taking almost 1/3 of request time each. And these things were easy to fix.
Imagine you want to rename form parameter but you also want it to accept old parameter name in requests to preserve backwards compatibility. Here's how you do it.
Junior dev's life is hard an full of dangers. You come to technical interview and think "at least I'll learn something new from guys that know it better than me". Well, not really. Threre are some things that are ok in interviews and are totally wrong in real life. Here are some examples.
I've heard about composer long before I started using it. I couldn't understand why it's so much cooler than downloading dependencies manually. I couldn't understand why it's worth running composer install after every code fetch.
This article is for guys like me in the past. If you're already using composer you can stop reading.