Publiczne prywatne notatki Andrzeja

Kompendium świeżoupieczonego rodzica

2026-05-31T19:07:00.000Z

Lista formalności, o których warto wiedzieć, szykując się na przyjście dziecka. Możliwe, że niektóre z poniższych sekcji będą kiedyś rozwinięte jako osobne notatki.

tl;dr:

wizyty położnej
zgłoszenie do USC
zgłoszenie do ZUS/NFZ
wybór POZ
zasiłki
urlopy
wyprawka

Lista

Wizyty położnej środowiskowej

Położna ma za zadanie opiekować się kobietą w ciąży, a po porodzie sprawdzić stan zdrowia noworodka, jak i samej kobiety w połogu. Żeby dowiedzieć się więcej u źródła, polecam sprawdzić stronę rządową: Jakie są kompetencje położnej POZ.

Sprawdzenie stanu faktycznego

Każda osoba zarejestrowana w NFZ powinna być przypisana do konkretnego lekarza/lekarki oraz pielęgniarza/pielęgniarki, a kobiety dodatkowo przypisane do konkretnej położnej ^[1]. Mówię "powinna", ponieważ np. cudzoziemcy, którzy nigdy nie wypełnili żadnej deklaracji, nie mają nikogo przypisanego z automatu. Najlepiej sprawdzić stan faktyczny w IKP, ponieważ może się równie dobrze okazać, że jesteście przypisani do lekarza z lat dziecięcych w rodzinnym mieście.

Wybierzcie przychodnię POZ niedaleko Was, i najlepiej udajcie się do niej osobiście w celu spisania deklaracji. Można to zrobić przez IKP, natomiast istnieją placówki, które nie są zsynchronizowane z systemem, bądź osoby, do których się przypiszecie mogą odrzucić Wasze deklaracje (nic nie stoi na przeszkodzie, żeby Gdańszczanin zapisał się w systemie do pielęgniarki z Rzeszowa -- stąd możliwość odrzucenia deklaracji pacjenta).

Kontakt z położną

Najlepiej nawiązać kontakt we wczesnej fazie ciąży, ponieważ kobiecie w ciąży przysługuje opieka położnej, m.in. edukacja o ciąży, porodzie, połogu, rodzicielstwie, np. w formie spotkań w przychodni.

Po porodzie, w pierwszych 8 tygodniach życia dziecka powinny odbyć się od 4 do 6 wizyt patronażowych.

Co prawda szpital sam zgłasza informację o narodzinach do położnej, ale w ekstremalnych przypadkach może to trwać nawet i kilkanaście dni, dlatego najlepiej skontaktować się bezpośrednio z położną bądź z POZ, w którym pracuje. Po zgłoszeniu narodzin wizyta powinna się odbyć w ciągu 2 dni roboczych.

Trochę prywaty: każde województwo inaczej weryfikuje prawdziwość papierów w systemie i bywa i tak, że wizyty patronażowe w ogóle się nie odbywają. Ba, pary w ogóle nie wiedzą o istnieniu położnych środowiskowych. Dlatego jeśli Wam zależy, to ubiegajcie się o te wizyty. Ale jednocześnie pamiętajcie, że położna nie pojawi się magicznie pod Waszym adresem, jeśli się z nią wcześniej nie umówicie -- to w Waszym interesie jest sprawdzić kto jest położną środowiskową i skontaktować się z nią.

Twoja położna środowiskowa (położna Twojej partnerki) najpewniej nie jest związana ze szpitalem, w którym odbywał się poród. Ale to już tłumaczyłem w sekcji wcześniej.

Zarejestruj dziecko w Urzędzie Stanu Cywilnego

Strona rządowa: Zgłoś urodzenie dziecka.

Strona warszawska: Zgłoszenie urodzenia dziecka

Można to zrobić online bądź w urzędzie. Polecam zgłosić urodzenie online natomiast odebrać dokumenty osobiście w urzędzie.

Na zgłoszenie masz 21 dni od wystawienia karty urodzenia (karta urodzenia to dokument wystawiany po porodzie przez położną bądź lekarza). Jeśli nie zgłosisz sam dziecka do USC w ciągu 21 dni, urzędnik zgłosi dziecko za Ciebie i wybierze mu imię. 😳

Uwaga: jeśli jesteś cudzoziemcem i Twoje akty stanu cywilnego nie są wpisane w polskim USC, musisz przynieść do wglądu oryginały zagranicznych dokumentów stanu cywilnego, które potwierdzają stan cywilny matki dziecka. Dokumenty te muszą być przetłumaczone przez tłumacza przysięgłego na język polski.

Uwaga: jeśli nie macie ślubu, proponuję zadbać o "uznanie ojcostwa" przed narodzinami dziecka (również w USC). W przeciwnym razie po narodzinach musielibyście udać się razem do USC, inaczej ojciec będzie "nieznany".

Co dostaniesz w zamian

jeden bezpłatny odpis skrócony aktu urodzenia,
powiadomienie o nadaniu numeru PESEL (jeśli dziecko otrzymało numer PESEL),
zaświadczenie o zameldowaniu dziecka (jeśli dziecko zostało zameldowane)

Załatwienie ubezpieczenia zdrowotnego dla dziecka (rejestracja w ZUS)

Podpięcie dziecka do ZUS

Zgłaszasz pracodawcy w ciągu 7 dni od nadaniu PESEL-u, bądź jeśli masz swoje JDG sam wypełniasz i wysyłasz formularz "ZUS ZCNA". Jeśli któreś z Was ma JDG, polecam samemu podpiąć dziecko w ramach własnego ubezpieczenia zdrowotnego. Łatwiej coś "odkręcić" bądź dosłać brakujący dokument samemu, niż polegać na pracodawcy ^[2].

Wybór POZ dla dziecka

Procedura taka sama jak wspominałem wcześniej, w sekcji o położnych. Dla ułatwienia wszystkich procedur wybierzcie tych samych specjalistów co Wasi (bądź matka).

Instrukcja ze strony rządowej: Wybierz dziecku lekarza rodzinnego.

800+ i inne zasiłki

Rządowa strona z listą wszystkich świadczeń rodzinnych: Wsparcie dla rodzin z dziećmi

800+ (dawniej "500+")

Dostępne na każde dziecko. Można zgłosić na wiele sposobów. Najprościej zrobić to przez własny bank. Serio. Jeśli ktoś chce spróbować swoich sił, może to zrobić bezpośrednio przez stronę ZUS-u. Ale po co? Link do strony rządowej
Becikowe, Kosiniakowe
- Becikowe przysługuje przy niskich dochodach
- Kosiniakowe przysługuje przy braku możliwości wzięcia zasiłku macierzńskiego (bezrobotni, studenci, pracujący na umowę o dzieło)
Aktywny Rodzic

Obowiązuje dopiero od 12 miesiąca życia dziecka. Występuje w 3 smakach: Aktywnie w żłobku, Aktywni rodzice w pracy, Aktywnie w domu. Link.

Urlopy

Witamy w Europie.

Lista ze strony rządowej: Uprawnienia związane z rodzicielstwem

Macierzyński: 20 tygodni^[3].

Rozpoczyna się w dniu porodu. Matka musi wziąć co najmniej 14 tygodni. Ojciec może wziąć resztę, nazywane jest to potocznie "tacierzyńskim".
Rodzicielski: 41 tygodni^[4]

Można dzielić między matkę a partnera. Ale uwaga: każdy rodzic ma zagwarantowane nieprzenoszalne 9 tygodni urlopu, co oznacza, że jeśli matka weźmie 41 tygodni, to wtedy ojciec dostaje "on top" 9 tygodni. W sumie 50 tygodni dla dwojga partnerów. Te 9 tygodni można również dzielić na kawałki, nie trzeba brać na raz.
Ojcowski: 2 tygodnie

Do wykorzystania do 12. miesiąca życia dziecka. Wyłącznie dla ojca.
Wychowawczy: 36 miesięcy (3 lata)

Udzielany do końca roku kalendarzowego, w którym dziecko kończy 6 lat. Jeden miesiąc jest zagwarantowany dla każdego z rodziców, więc jeden rodzic może wziąć maksymalnie 35 miesięcy (inaczej niż w przypadku rodzicielskiego, gdzie obowiązkowe 9 tygodni dla ojca drugiego z rodziców magicznie pojawia się po wymaksowaniu urlopu przez matkę pierwszego). Dzieli się na maksymalnie 5 części (liczone są wnioski urlopowe).

Miejska wyprawka dla dziecka

Różne miasta mają programy dla swoich nowych mieszczan. Każde miasto ma swoje zasady i formę wyprawki.

Warszawa: Wyprawka dla Warszawskiego Malucha
Kraków: Krakowska wyprawka
Poznań: Wyprawka dla gzubka
Wrocław: Wyprawka wrocławska
...i inne

I tyle

Na pewno to, co wymieniłem powyżej, nie wyczerpuje tematu i są jeszcze jakieś inne tematy. Wrzuciłem to, co chodziło mi po głowie od dłuższego czasu. Będę starał się rozwijać tę listę, bądź rozszerzać temat sekcji (najprawdopodobniej w oddzielnych wpisach).

W 2018 położni (mężczyźni) stanowili 0,2% wszystkich położnych. ↩︎
Zwłaszcza jeśli pracodawcą jest placówka oświatowa, a za wysyłanie dokumentów odpowiada "pani Basia" z sekretariatu, która wysyła dokumenty po terminie bądź gubi je bezpowrotnie, a także potrafi wysłać mailem skan dowodu osobistego (trzymanego na pulpicie) do złego adresata. ↩︎
31, 33, 35, 37 przy kolejno 2, 3, 4, 5+ dzieciach (przy jednym porodzie) ↩︎
43 w przypadku ciąży mnogiej ↩︎

I finally understood Nx usefulness

2023-12-23T23:44:29.000Z

I was planning on releasing a longer post about Nx, but I got lost in my line of reasoning. So here goes a shorter note, just to share some thoughts.

TypeScript project references

Before I get to the Nx part, I wanted to talk about a useful TypeScript's feature: project references.

It allows you to divide your project into separate sub-projects that are understood by TypeScript, as long as you reference the root directories of used projects (or their tsconfig.json files) inside the "using" project's tsconfig.json#references. What's neat about this is that whenever you want to build the app that relies on libA and libB, and you run tsc --build, the TypeScript compiler will first run type-checking and transpilation for those dependencies, before builing the app itself. If everything is configured properly with the .tsbuildinfo files, then the sub-build will be skipped (because cached).

Enter Nx

So what's the deal with Nx? One of it's core features is the fact that it manages the dependencies between the tasks, including "build" tasks. Why would it matter to me, since TS handles that out of the box?

Well, I just realized that when you change the transpiler (to, for example, swc), it turns out you have to transpile all the projects one by one yourself.

So this is where Nx is showing its colors -- if the sub-projects are properly defined as dependencies in the package's manifest (=package.json), and the Nx is set up to run "build" target (="command") for project's dependencies whenever the project's "build" target is run, then you're all set. You run "build" for the app, and all the dependencies (libA, libB) are "built" first, regardless of the used transpiler, because Nx knows what to run in what order.

The benefit? Your CI YAMLs/bash scripts/Dockefiles do not need to contain:

yarn run $YOUR_TRANSPILER packages/libA
yarn run $YOUR_TRANSPILER packages/libB
yarn run $YOUR_TRANSPILER packages/app

which would otherwise increase the complexity of the projet and would mean that the YAML/bash/Dockerfile would need to be in sync whenever you decide to add/remove/modify internal dependency of the app.

With Nx, you just need to make sure that Nx is available in the runner context, and then run:

nx app:build

All the relationships between the packages is already defined in the source code and/or the manifests. No need to duplicate the responsiblity.

And when you are using the cache properly (the easiest scenario is the local one -- practically no setup required), then the projects that were already built once and were not modified are not built again.

But that's the benefit I understood only when I decided to migrate to swc, since tsc took way to long to build the project. If not the build times, I'd still orchestrate the builds with tsc.

Envs and Twelve Factor App

2023-12-15T11:14:21.000Z

Intro

In the Twelve Factor App manifesto there is a section III. dedicated to config management. In short, it advises that the configuration of the app should come "from outside", not from inside.

Then there is this paragraph about "grouping":

Another aspect of config management is grouping. Sometimes apps batch config into named groups (often called “environments”) named after specific deploys, such as the development, test, and production environments in Rails. This method does not scale cleanly: as more deploys of the app are created, new environment names are necessary, such as staging or qa. As the project grows further, developers may add their own special environments like joes-staging, resulting in a combinatorial explosion of config which makes managing deploys of the app very brittle.

In a twelve-factor app, env vars are granular controls, each fully orthogonal to other env vars. They are never grouped together as “environments”, but instead are independently managed for each deploy. This is a model that scales up smoothly as the app naturally expands into more deploys over its lifetime.

I did not understand this at first. I mean, how can you not group the environment variables? At the end of the day you have to have the list of values written down somewhere, so that you can create a release for a particular environment (prod/dev/etc). It's turtles all the way down, right?

I started imagining some software that would serve as a manager of the env variables, so that you can modify their values per release or something, but it couldn't be what the author of the manifesto had in mind, because you can achieve the same thing while modifying the files that define the values for a release. No need for additional technology -- if anything, this should be against the manifesto. And even if it was about the software, you will for sure group the variables, the whole idea of having particular values for a release is grouping.

And then it hit me -- it's not about storing the variables in groups, it's about using groups in code.

A good idea

Let's imagine you have some service that is expected to use a local filesystem when run locally and a 3rd party HTTP API when used on actual servers. We could write it this way:

class SomeService {
  public run() {
    if (process.env['APP_ENV'] === 'LOCAL') {
       this.runUsingLocalFs();
    } else {
       this.runUsingHttpApi();
    }
  }
}

Seems fine at first. You got the service behaviour designed exactly how you wanted.

The APP_ENV variable needs to be defined properly in all environment definitions: local environment, dev environment, prod environment, you name it. So you add these APP_ENV=PROD or APP_ENV=LOCAL to some YAMLs or other .env files to make it work correctly.

With time you create more services that need to rely on some fallback behaviour, for example a logger service, that pretty-prints when it's useful, otherwise it creates standardized JSON logs.

class Logger {
  private print(message: string) {
    if (process.env['APP_ENV'] === 'LOCAL') {
       this.prettyPrint(message);
    } else {
       this.jsonPrint(message);
    }
  }
}

It gets messier...

Then a couple more services that behave in a similar way. Maybe there are some that behave the same way on more than one environment

if (['LOCAL', 'DEV'].includes(process.env['APP_ENV'])) {
  ...
} else {
  ...
}

You decide to create some utils, maybe ~~an enum~~ const^[1] not to make a typo in the environment name:

export const APP_ENV = {
  LOCAL = 'LOCAL',
  DEV = 'DEV',
  PROD = 'PROD',
} as const;

or maybe some functions to make it more consise:

export function isLocalOrDevEnv() {
  return [APP_ENV.LOCAL, APP_ENV.DEV].includes(process.env['APP_ENV']);
}
export function isLocalEnv() {
  return [APP_ENV.LOCAL].includes(process.env['APP_ENV']);
}

Adding a new environment? Ok, sure, just extend the APP_ENV. And the utils. And make sure that all the services are running correctly when they APP_ENV contains a value that was not decided on previously.

...and messier

What if you want to run some integration tests that call SomeService? You either have to define APP_ENV as LOCAL or something else, to choose the implementation you want.

Choosing the APP_ENV also changes the behaviour of other N services, that now have to behave as if they were on some particular environment. Trying to get the desired behaviour of one service that relies on APP_ENV is now a game of whack-a-mole, or a minesweeper -- you change one setting and then you see multiple things changed.

I believe this is the grouping of which the manifesto tried to warn us.

Solution

If the services were implemented with separate config flags, like this:

class SomeService {
  public run() {
    if (process.env['SOME_SERVICE_LOCAL_FS']) {
       this.runUsingLocalFs();
    } else {
       this.runUsingHttpApi();
    }
  }
}

class Logger {
  private print(message: string) {
    if(process.env['LOGGER_PRETTY_PRINT']) {
       this.prettyPrint(message);
    } else {
       this.jsonPrint(message);
    }
  }
}

then you avoid the issues mentioned above.

You still need to decide what is the default behaviour (should it be some particular implementation or throwing errors when the configuration is undefined) -- I guess there are some best practices as well. But at least you are not grouping unrelated features with an environment name.

no enums please ↩︎

Class fields, again

2023-10-31T08:52:38.000Z

Two weeks ago I wrote about class fields, TC39 and TypeScript. This time I want to go into the details of transpilation output related to class fields.

Intro

You see, I have this class in my TypeScript codebase:

class Foobar {
    public foo = 31;

    constructor(public x: string){
    }
    
    public bar = this.x.toUpperCase();
}

Obviously, this is some real production-grade code.

Now, to set the scene: my tsconfig.json has the target set to ES2021 and I am not using the useDefineForClassFields flag yet.

So the JavaScript result of running tsc looks like this:

class Foobar {
    constructor(x) {
        this.x = x;
        this.foo = 12;
        this.bar = this.x.toUpperCase();
    }
}

Idea 1: the flag

I want to start using useDefineForClassFields: true in my repo, to move my TypeScript source code closer to JavaScript.

So I turn this on in the tsconfig.json, and with the same ES2021 target, what I get from tsc now is this:

class Foobar {
    constructor(x) {
        Object.defineProperty(this, "x", {
            enumerable: true,
            configurable: true,
            writable: true,
            value: x
        });
        Object.defineProperty(this, "foo", {
            enumerable: true,
            configurable: true,
            writable: true,
            value: 12
        });
        Object.defineProperty(this, "bar", {
            enumerable: true,
            configurable: true,
            writable: true,
            value: this.x.toUpperCase()
        });
    }
}

This is definitely more verbose, but not surprising, knowing why the flag was introduced in the first place.

So far, all's fine. What's interesting is that you might already see that there is a specific order in which the properties are defined. The first defined property is always the class field defined via parameter properties.

Idea 2(022): electric boogaloo

Since I'm already using the flag, and it is now year 2023 (so ES2022 is already released), why won't I set the target to ES2022?

And that's what I do, with the useDefineForClassFields flag turned on.

But tsc is not happy:

class Foobar {
    public foo = 31;

    constructor(public x: string){
    }

    public bar = this.x.toUpperCase();
    //                ^ Property 'x' is used before its initialization.(2729)
}

Weird.

I remove the bar property from the class, and this is the transpilation output:

class Foobar {
    x;
    foo = 31;
    constructor(x) {
        this.x = x;
    }
}

x;? No Object.defineProperty calls anymore? And why was suddenly bar illegal?

Looking for patterns

First thing that gets my attention is the fact that there are no Object.defineProperty calls anymore. I believe this is because ES2022 now has the class fields as part of the language, so the field being initialized like foo = 31; has to be realized as if there was the Object.defineProperty call in the code. That is why the useDefineForClassFields flag's behaviour was to add these calls in the first place. Now with ES2022 being a thing, this is not necessary -- the language imposes these [[Define]] semantics on the runtime.

Second thing is the lone x; expression. This does not look like it would be a requirement of the ECMAScript specification. I searched for some clues in the TypeScript repository, but I couldn't find any proof for the hypothesis that it is by TypeScript's design to define^Wassign^[1] the fields in this specific order: parameter properties, then class fields.

Because this is what it looks like:

Wild theories below

With TypeScript's original decision to use the [[Set]] semantics for class field initialization, it was also decided that the parameter properies were always assigned first. An arbitrary decision, but it allows assignments like the one for baz, where the value is taken from a constructor argument. And also, you have to have some order, so placing the parameter properties first looks elegant as opposed to doing it in the order of appearance in the class (mixing class scope with constructor-parameter scope, yuck!). I wonder why weren't parameter properties placed last, but it's probably because placing them first gives you the baz assigment for free and placing them last gives you nothing.

Then, when it turned out that ECMAScript is going to go for [[Define]] semantics, TypeScript was forced to use Object.defineProperty. The order was kept, since the parameter properties are not a JavaScript feature^[2] and the designers wanted to keep the same behaviour. Notice that the bar initialization was legal with the ES2021 target. What's more (that is not highlighted in my example) is that with the [[Define]] semantics TypeScript needs to emit statements for uninitialized fields, that were previously removed from the output (since their purpose was only type-checking).

Finally, when ES2022 arrived, the parameter properties needed to be "mentioned" at the top of the class definition, to keep the already established TS behaviour. But what's the most interesting here is that with ES2022 target there is now a separation between definition and assignment -- previously, it was happening in a single expression with the value sitting in the third argument of Object.defineProperty call.

What's also interesting is that the output for a pre-ES2022 target with useDefineForClassFields does not separate the definition from assignment as the ES2022 output, while it is totally possible to do technically. My wild guess is that the difference was not made on purpose as a "migration stage", but the final behaviour of ES2022 was decided after the flag was implemented in TS 3.7. But again, I have no proof to support this.

tsc, why

Consider this snippet:

class Asdf {
    public bar = this.foo;
    //                ^^^ Property 'foo' is used before its initialization.(2729)
    public foo = 31;
}

class Qwerty {
    public foo = 31;
    public bar = this.foo; // all's good
}

The order of field initializers is important to TypeScript. And because parameter properties are emitted first, that's why it has been always legal to set bar like this:

class BarX {
    public bar = this.x;
    constructor(public x: string) {
    }
}

It looks like you're trying to use x before it is initialized, but we already know that this is not the case for pre-ES2022 output.

But trying to transpile the BarX class above into ES2022, we will first get a type-checking error from tsc. TS Playground shows you what would the output be for this code:

class BarX {
    x;
    bar = this.x;
    constructor(x) {
        this.x = x;
    }
}

So here's the problem. The parameter property was defined with ES2022 syntax at the top, but assigned in the constructor body, whereas the bar class field assigment was not moved to the constructor. It does make sense why TS reports an error (bar will be initialized with undefined), but it does not make sense to me why isn't the output like the snippet below in the first place:

class BarX {
    x;
    bar;
    constructor(x) {
        this.x = x;
        this.bar = this.x;
    }
}

I assume this is due to "TypeScript not wanting to transform the source code" and "being as close to ECMAScript as possible". Well, unfortunately you cannot have your cake and eat it too, because not only the sole existence of parameter properties forces you to transform the code in some way, it's also the fact that useDefineForClassFields behaviour for pre-ES2022 was supposed to bring the forward compatibility with ES2022, but it turned out to have a different behaviour than ES2022. By chance it was the exact behaviour that we wanted, and now, we don't have it.

swc, hi

And here's the same snippet ran through swc with ES2022 and useDefineForClassFields set to true (by default):

class BarX {
    x;
    bar;
    constructor(x){
        this.x = x;
        this.bar = this.x;
    }
}

Yes, the default ES2022 behaviour is to emit the equivalent of tsc's pre-ES2022 + useDefineForClassFields output.

Too bad we cannot just use it, since tsc is going to report compiler errors on the source code anyway.

What will I do, a.k.a "Closing words"

I'll probably change my original Foobar class from this:

class Foobar {
    public foo = 31;

    constructor(public x: string){
    }
    
    public bar = this.x.toUpperCase();
}

to this:

class Foobar {
    public foo = 31;

    constructor(public x: string){
        bar = this.x.toUpperCase();
    }
    
    public bar: string;
}

because this is all it takes to get the old behaviour (for the bar field assignment) back in ES2022.

But I'll be cautiously keeping an eye at all the syntax sugar that is provided by TS from now on.

Post scriptum

In C# a field initializer cannot refer to other instance fields. You can only do the assignment in the constructor body.

Had this rule been in TS from the start, we wouldn't have ended up with some code that is now only valid for old compilation targets.

the whole thing is actually about the assumption it was supposed to be an "assignment", not a "definition" ↩︎
yet ↩︎

Yarn being Yarn

2023-10-25T14:44:07.000Z

When fighting with some tools working not as expected, it is always good to read an insightful commit message.

Especially if it's your own commit message, from 8 months ago.

chore: set some-package resolution to 2.0.0

I used the following command:
   yarn set resolution some-package@npm:^1.0.4 2.0.0
This caused the lock file to be modified. There is no additional entry inside top-level package.json.

What's more, yarn documentation mentions -s option that should "Persist the resolution inside the top-level manifest"^[1], but it is not implemented according to an answer from 2020^[2].

What's more, resolutions in package.json and yarn set resolution are totally different features...

And then the next message afterwards:

chore: decided to use package.json resolutions

Putting a new entry inside package.json is more developer-friendly -- the approach with yarn set resolution leaves no info other than the lockfile itself, which if regenerated, loses the information about the forced resolution.

The only downside is that it's now harder to parse the lockfile on its own, cause the lockfile mentions version 2.0.0 which is not requested by any package (contrary to yarn set resolution which kept declarated range as "^1.0.4" and only modified the actual resolution version).

I checked the issue and the --saved flag is still mentioned in the docs, and still not implemented. The save = Option.Boolean(`-s,--save`) variable just sits here, patiently waiting to be deleted.

https://yarnpkg.com/cli/set/resolution ↩︎
https://github.com/yarnpkg/berry/issues/2202#issuecomment-737788770 ↩︎

Class fields, TC39 and TypeScript

2023-10-20T15:07:00.000Z

It's June 2022 and a new version of ECMAScript has just been released. One of the novelties that this version has brought us are the class fields.

You see, Object-Oriented languages usually have this feature, where you can declare a field on a class in the top-most scope of the class like this:

class Foobar {
  private someNumberField = 10;
  public  aFieldWithNoValue; 
}

Well, aside from the obvious lack of access keywords, this was still impossible in JavaScript. Until ES2022 you usually set those in the constructor (or never mentioned them at all):

class Foobar {
  constructor() {
    this.someNumberField = 10;
  }
}

But because of the proposal^[1] that has been marinating since 2017, this feature has been brought to life in ES2022, and since then, JS is now like any other OO language.

Hehe.

Well, it has been decided around 2018/2019 that the declaration of class fields will be done in JS using [[Define]] semantics and not [[Set]] semantics.

This means that whenever a class Foobar defines a property (for example, initialized like: someNumberField = 10), JS is

not doing this.someNumberField = 10 when creating an instance of the class

but

running Object.defineProperty(Foobar, "someProp", 10) somewhere around the class declaration

Why does it matter? Oh boy, it matters a lot. See the heated discussion here.

Most importantly to the TS users, the class fields that were in TypeScript long before ES2022, were originally implemented with [[Set]] semantics. That's what the TypeScript creators assumed at that time, and I have to admit, [[Set]] semantics make total sense to me.

Sooo, since TS 3.7 there's this useDefineForClassFields flag that when turned on, flips the implementation to an ECMAScript-compilant one. ^[2]

But the new ECMAScript-compliant behaviour breaks some existing code related to class inheritance and property setters. If you have a derived class that narrows a type of some property (a totally valid thing to do in TS) that is set in the base class with a super() call, it will be set to undefined after the constructor of the derived class returns!

There are a couple of fixes:

quick and dirty: set useDefineForClassFields to false if you have it set to true. Unless your target is ES2022 or higher, then you're left with the other option:
fix the code by marking the property in the derived class with the declare keyword. Even if originally you overrode it.
or use a transpiler that does provides non-compliant transformation options: https://swc.rs/docs/configuration/compilation#jsctransformusedefineforclassfields

https://github.com/tc39/proposal-class-fields ↩︎
https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-7.html#the-usedefineforclassfields-flag-and-the-declare-property-modifier ↩︎

Https Stuff

2022-08-04T21:34:19.000Z

A couple of things I learned yesterday when browsing Hacker News.

Upgrade-Insecure-Requests

Content-Security-Policy: upgrade-insecure-requests;

This means that if for any reason a non-navigational content on your website contains http instead of https (by mistake), then the browser will try to access it via https

This won't change navigation <a> links to 3rd party websites.

HTTP Strict-Transport-Security (HSTS)

Strict-Transport-Security: max-age=<expire-time>

This header instructs the browser that this website needs to be accessed only via https for as long as the header is not expired. Even if you click on a link with http or write the URL by hand using http, the browser will automatically treat this as https.

But this works only after you initially visited the website via HTTPS.

HSTS Preload

If you visit the website http://example.com for the first time, there's a possibility that you'll be a victim of a man-in-the-middle attack. The attacker hijacks your HTTP request, calls the original website themselves via HTTPS and then returns the response to you via HTTP, without the Strict-Transport-Security header.

In order to make sure that your website is always accessed via HTTPS, you need to add it to the pre-loaded list of websites, curated by browser vendors. This is the only way the browser will know it has to use HTTPS for the first time, without getting the headers beforehand.

Problems Not Solutions

2022-04-07T08:24:55.000Z

Today an interesting read by a Columbia professor: The examples you see in the textbooks are not representative of the sorts of problems you see in the real world

I see it too. But what is even more important to me regarding Maths or Physics is that very often the real problems you encounter can only be solved/described/modelled using a mix of various approaches. It is sometimes obviously easy when you’re learning a particular topic that the posed problems can be automatically solved by applying this thing you just learned about. You simply need to use the method or apply the same formula, maybe this time with a slight twist. For me personally it’s hard to apply the knowledge in the real world, if I’ve been using it only in an artificial and very precise problem space.

How to make it better then? One way could be to mix the problems in such a way that you need to apply different methods, not only the latest thing you’ve just learned. Science handbooks do that usually at the ends of chapters as a form of summary. Most of them fail anyway, because those problems are usually listed in the very same order as the topics in the chapter — you don’t need an Einstein to figure out that when you use the tools in roughly the same order you learned them several pages ago, you’ll be fine. Why not randomise the order of the problems in the summary sections? Is this idea really that bold?

Another way would be not to structure the course around the methods, but around the problems. Let’s step back and ask ourselves — why do we want to teach others anything? I guess the most useful reason would be to help them understand the world around them. So why not guide people through their questions and problems they have, or might have in the future, and not stuffing them with some knowledge that you (or the curriculum) find important. Let people try working with the problems themselves and only then teach them various methods and equations that fill in the missing gaps.

Teach problems, not solutions. Solutions are only interesting when you had the opportunity to familiarise with the problems first. People might be not only more interested in the course, but the skills they learn are actually more useful from the day one. This approach is definitely harder for the tutor, because it requires more creative work and it requires them to understand the topics very well — I would argue it’s possible to teach people from a book and not understanding truly what you’re teaching — but I truly believe that if you care about the students, this is the way to go.

I wonder if there’s ever going to be such a shift in education.

Simple PR Stats

2022-03-31T07:28:23.000Z

So my Rails project failed before it even started. I am not surprised, I know myself quite well. I think I don't have enough frontend experience and that's what blocks me from going forward.

I'd like to say I took a breather and stopped thinking about side-project ideas, until one suddenly appeared to me, but obviously I still had that thing at the back of my head that tried to generate new ideas amd another thing that validated if those are within my reach.

Well, there was an idea that suddenly popped into my mind yesterday. I was looking for some tool that would automatically generate a small statistics report on GitHub PRs in a repository of my choice. Most of these were paid products, some of them were too comllex and every tool I found required either registration or external intrastructure on which you run the tool. Then I found a GitHub Action that did almost what I wanted, but the stats were calculated per contributor, not per whole repo.

So I dug into GitHub Actions docs and wrote an action myself. The most important part (for me) is that I have already published it publicly!

This is the thing: simple-pr-stats

It's very simple and needs lots of love, but let's see if the fact that the project is live and publicly available will help me get unstuck.

After Hours

2022-02-16T20:37:32.000Z

I have noticed that it takes me about 30 to 60 minutes to clear my mind after work. Until then, my mind is foggy and I'm living life on auto-pilot for a while. Sometimes I even feel I'm not completely back for the rest of the day. It sounds a little bit scary, and I the more I think about it, the more I realise it should make me scared, for my own good.

I don't have any sophisticated takes on this matter, but I think it is quite obvioue that putting yourself into a mental state like this one cannot be healthy. Especially if it happens 5 out of 7 days in the week, each week.

It's hard to plan things, it's hard to get out of the rut. It's even hard to read books at times. What's easy is mindless scrolling of news websites and feeds on social media. But it does not help clearing the fog at all.

What I realised is that the more I focus on being here and now, the faster I get control over my thoughts, and the more present I am after hours. I don't meditate or do any mindfullness stuff, but sometimes I force myself to simply close my eyes and get my shit together. Tink about past weeks, current date and upcoming days, any chores that I forgot about -- it's so simple and silly when I describe it in words, but I know that it's often just too hard to do properly.

I read today that acute aerobic exercise sessions can help you recover quicker from cognitive fatigue than leisure time. The study even used "watching a popular sitcom" as the "leisure" approach. I guess this means I should do a trial myself. Let's say instead of another episode of The Office I should probably do a 20-minute run around the block. And then compare the results with my notmindfullness sessions.

Not sure when I'll start with this research of my own though -- still waiting for funding.

Ruby on Rails Questions, part 1

2022-02-13T21:13:07.000Z

I decided to give RoR a try. I don't quite feel it yet, mostly because I've never learned any Ruby. Maybe it's not the smartest move to learn the framework without learning its mother language, but at least it's a move.

I opened the official Getting Started guide on my 2.5 hour long train ride and finished the basic "blog" app by ~copy-past~ following the instructions step by step.

On my way back (another 2.5h ride) I decided to start with my own app.

Below are the questions I asked myself during this experiment, sometimes with some answers I managed to find on SO:

Q: How on earth do you know the attributes of the model, if the model class does not contain definitions of possible fields/columns?

A: You inspect the items in the console with .columns or .attributes, or you write block comments with the database schema in the model class (or use a plugin for that^[1]).

Sounds... not ideal, to say the least. Most of the fields are going to be mentioned in the class anyway, because of some validation rules, but this is just coincidental. I've found attr_accessor that could've been used, but it seems that it's not a conventional thing to do.
Q: Is it common to have models that are not derived from ActiveRecord, so that they do not represent database entities?

Maybe I do not know MVC well enough.
Q: How to structure Rails app where calendar date is the main view?

Remember to include it in the :development group ↩︎

Ruby or Not Ruby

2022-02-05T13:58:12.000Z

Hacker news is an interesting place.

Today I saw an article about the superiority of Ruby over Javascript ecosystem when it comes to tooling simplicity. The points made by the author make sense to me. They are almost too familiar — I spent my latest creative hour on comparisons of several javascript... storage approaches? (like a database wasn’t good enough). On the other hand Ruby with Rails framework in the centre, has only one particular tool for each job, so you won’t waste time on preoptimizing your tech stack even before you wrote a single line of code. I was sold and decided to put (Ruby on) Rails onto my backlog.

Half a day later I saw another article about Ruby. This time the main theme was that Rails is to Ruby what a Cracow dialect is to Polish language. Interesting, huh? I learned that Ruby on Rails community loves monkey-patching and it’s a source of serious problems for the authors of Ruby libraries. Apparently Rails is powered mainly by the ActiveSupport library which extends every builtin type. Because it gets the special treatment as the “unofficial stdlib” it’s hard to write other libraries. You either add more patches and hope that there will be no clashes between the libraries or you propose a different paradigm, which is then rejected by the community so used to the Rails conventions. Well, it does not sound like the ecosystem is easily extendable and when you try to do something more complex (like Shopify it gets much harder.

Even though these two articles at first seem like arguments for and against Ruby, they actually agree on the single premise, that you should do the things in a very particular way. All the way. Hard for me to say whether it’s appealing to me or not. Maybe I’ll give it a try one day.

Sent From iPhone

2022-01-31T20:33:36.000Z

The title says it all. I wanted to be able to write and edit posts from my phone. And I made it!

I installed a Termius app on my iPhone. It allowed me to generate an ECDSA keypair in a secure enclave -- allegedly even the app does not know the key.

I then exported the public key from Termius via Signal (it was the easiest way to sync the content from my iPhone to my Windows PC) and pasted it into the terminal, where I was logged onto the VPS running the blog.

Originally I thought about having a separate app for preparing Markdown files and then uploading them onto the VPS. But file uploading might be not possible (or just very incovenient) using the free version of Termius, so I am currently typing these words in vim... on a smartphone touchscreen keyboard 🤪

Why did I do that? Well firstly, because I was curious whether it's possible. Secondly, since I'm using my phone way more often than my private laptop, and I consume digital content almost exclusively on a phone, I figured it wpuld be much harder for me to now find an excuse not to write.

But I alteady see I need to find out how to turn on autocorrect.

Cheers! :wq

Interesting things #1

2022-01-30T00:00:00.000Z

James Hoffman's 3-part series about moka pot brewing
NEVER TOO SMALL channel which shows small, but highly functional apartments
Homo Deus by Yuval Noah Harari -- very interesting read about the human history and potential future. Lots of author's personal views on various subjects, so stay cautious and don't treat it as a scientific book.
Moving Out on PS4
Trivial Pursuit: Friends -- I had no idea my knowledge about the series is that bad. Somebody should make a 'Trivial Pursuit: The Office' 😁
Wordle and its Polish version literalnie.fun -- a linguistic version of Mastermind
Blog post on how to deploy a Hugo blog with NGINX
Titane, but I definitely don't recommend it to everyone
The Woman in the House Across the Street from the Girl in the Window, just released by Netflix. Watched only 3 episodes and I don't think it's very funny, but I appreciate the idea to spoof all the thriller pulp produced in the last decade.

How not to use merge --squash

2019-06-24T00:00:00.000Z

Merging branches using "--squash" has its advocates. The main (and also - the only) reason for squashing is to keep the history clean, but one can of course argue whether a commit containing a whole feature is easier to understand than a "dirty" history of incremental commits.

Leaving the argument aside, there is one thing that you certainly shouldn't do and that is squashing commits between long-lived branches. What's that? Suppose you have 2 main-ish parallel branches -- those can be 2 maintenance release branches, current and vNext development branches, you name it. Or maybe let me name it: alpha and beta. And assume (without loss of generality) that beta is a younger, newer branch - all the changes that happen on alpha need to be merged into beta (but not necessarily the other way round).

Now, let me paint you a picture.

Prolog

Your team has never squashed before so every merge on the repository has only been performed via pull requests with --no-ff option. Today as usual you are told to fix a bug that was discovered on branch alpha. You make a fix, create a pull request and after a successful review ^[1] you merge it into alpha. A commit 0a has been created. Because the bug also exists in the newer version of the system, you create a PR that merges alpha (with the fix) into beta. A PR is merged using --no-ff into beta the same day. A commit 0b has been created.

The next day

On a daily scrum your team decides that from now on you should merge every PR using only the squash method. You all seem to be happy with the proposal, because you've always thought that linear git history is the best git history ^[2]. Your today's task -- to create a new feature for the alpha version. You push several commits and create a pull request. You then squash the content of the PR into alpha. A commit 1a is created.

Then, you are told to merge the new stuff into the beta branch. So you create a pull request from alpha to beta. And then you perform the first squash merge into the beta branch. That's how you've created commit 1b.

At the same time your favourite colleague Andrew has been working on his alpha-feature. He created a PR as well and squashed his feature branch into alpha (creating commit 2a) after you had squashed yours. And now he wants to squash 2a into beta. He tries to do that, but hey, there's a conflict! Hmm, you and him have been working on different features, different parts of the system even, so how come the merge is not automatic? "I must have done something wrong" -- he thinks. Or more probably -- "Damn you git, what is your problem today?". So Andrew with a frown on his face abandons the PR, creates an intermediate branch, resolves the conflict by hand locally, pushes the changes on the new branch, makes the PR and then squashes the PR into beta, which results in commit 2b.

A day after

You want to correct another nasty bug on the alpha branch. You fetch all the branches from remote and repeat the necessary steps to create a squash into alpha. All good for now -- commit 3a. Then you try squashing alpha into beta. Conflicts. And to your surprise, some of them are in Andrew's files? But how? You have only added new files, not modified anything! And even more, 2a is a direct parent of 3a and commit 2b has exactly the same diff as 2a!

And that's how we get to the point -- 2a is an ancestor of 3a, but 2b isn't. 2a and 2b are two different commits, they just happen to share the exact same content. The same with commits 1a and 1b that caused Andrew some trouble a day earlier. Git merges commits based on their ancestor tree, not their content. Git does not care ^[3] that 1a contains the same changes to your foo.txt file as 1b. It cares that the last common ancestor of alpha and beta at that time was commit 0a.

When Andrew tries to merge 2a into beta he wants to merge 2 branches that diverged at 0a and both have the content of foo.txt changed. That’s where the conflict comes from. And then when you try to merge 3a into beta you want to merge 2 branches that… also diverged at 0a but have changes in the foo.txt and bar.txt! The latest common ancestor hasn’t changed and will never do, unless someone finally merges (without squashing!) all the commits that do not exist in beta history. This will finally create a link between the branches that will release your team from neverending merge conflicts. Otherwise, every time you squash a PR from alpha into beta you create one more link in the conflict chain! Try to imagine what would happen if the team merged alpha into beta twice a month and were to discover the problem only after 3 months...

For the brevity of the article we skipped several phases. ↩︎
Unbeknownst to you, the horrors are yet to come. ↩︎
citation needed ↩︎