Steno & PL

Kodowanie w Rust modułów w stylu ML

Sat, 17 Jun 2023 00:00:00 +0000

Docelowi odbiorcy	Programiści OCaml/SML uczący się języka Rust. Programiści funkcjonalni, którzy wcześniej nie mieli styczności z języków takimi jak OCaml czy Haskell, ale mogą być zainteresowani pewną techniką abstrakcji. Należy zauważyć, że termin “moduł w stylu ML” odnosi się do rodziny języków programowania ML, a nie do uczenia maszynowego.
Pochodzenie	Doświadczenie w OCaml i Rust. Doświadczenie w teorii typów.
Nastrój	Pomocny
Język	Obcy. Moim pierwszym język jest angielki. Jeśli zobaczysz błąd, niezależnie od tego, czy chodzi o pisownię, gramatykę czy dobór słow, skomentuj to!

Spis treści:

Stwierdzenie problemu
Cachowanie funkcji
Kodowanie modułów
Powiązane posty
Komentarze

Stwierdzenie problemu

Problem: chcesz dodać do istniejącego typu implementującego pewnego trait nową działalność, która będzie wymagała używania wewnętrznego stanu.

Problem: chcesz wziąć istniejący typ spełniający jakąś cechę i rozszerzyć go o nową funkcjonalność — w tym nowy stan wewnętrzny.

Jeśli nie chcesz dodać wewnętrznego stanu, istnieje kilka możliwych rozwiązań:

Używać domyślnych implementacji metod trait.
Używać “extension traits”.
Używać impl dyn (uwaga techniczna: będzie to wymagać dynamicznego wywoływania na czasie wykonywania).
Używać wolnych (globalnych) funkcji, które są generyczne i akceptują dowolny typ implementujący trait.

Na przykład: implementowanie warstwa cachowania [ang. “caching”] tylko raz, które mogło wtedy zastosować się do dowolnej implementacji jakiegoś trait Backend.

Moduły w stylu ML są naturalnym rozwiązaniem dla tego rodzaju problemów. Bardziej wydajne są one niż tradycyjne “moduły”, jak uważa się w popularnych językach programowania. Zarówno moduły w stylu ML, jak i tradycyjne moduły obsługują:

Rozdzielanie kodu na logiczne przestrzenie nazw [ang. “namespaces”].
Definiowanie interfejsów.
Abstrahowanie typów danych i ukrywanie szczegółów implementacji.

Ponadto moduły w stylu ML mogą być parametryzowane na typach (podobnie szablonom [ang. “templates”] lub typom generycznym w innych językach programowania), a także _innych modułach _(omówione w tym artykule).

Pomimo, że Rust pochodzi z OCaml, nie dziedziczy systemu modułów w stylu ML. Zamiast, system “trait” w Rust przypomina typeclasses z Haskell. Jednak, korzystający dodatkowych funkcji, możemy symulować w Rust moduły w stylu ML.

(Uwaga pedagogiczna: przykładem kanonicznym modułów w stylu ML nad typeclasses chyba jest utworzenie nowego typu “tree-set”, który akceptuje inne kolejności, a nie ogranicza się do jednej kolejności na typ. Sądzę, że ten przykład się nudzi, bo nie rozwiązuje Prawdziwych Problemów Inżynierii, i bo rozwiązanie typeclasses — utworzenie “typ opakowania” [ang. “wrapper type”] z nową kolejnością — wymaga mniej więcej tyle samo pracy dla programisty, co używanie modułów.)

Cachowanie funkcji

Załóżmy, że mamy kosztowne obliczenia, które chcemy cachować (być może wysyłania zapytania do bazy danych lub wykonują dużo pracy związanej z procesorem [ang. “CPU-bound”]). Dla przykładu użyjemy funkcji, która oblicza długość łańcucha:

fn str_len(s: &str) -> usize {
    println!("Called expensive function str_len");
    s.len()
}

Cachowanie indywidualnej funkcji

Jak napisać funkcję która działa jak str_len, ale cachuje wyniki w pamięci podręcznej w taki sposób, że nigdy nie obliczy dwukrotnie tej samej pary klucz-wartość? Jednym ze sposobów jest wygenerowanie funkcji opakowania z zmiennym wewnętrznym pamięcią podręczną i wywołanie podstawowe funkcji str_len kiedy klucza nie ma w pamięci podręcznej:

// Declare that we return an `FnMut` rather than an `Fn`
// because the returned closure may modify mutable state
// (and thus isn't safe to call in parallel -- not relevant
// in this example).
fn make_cached_str_len() -> impl (FnMut(&str) -> usize) {
    let mut cache = HashMap::new();
    // Use the `move` keyword to move the mutable `cache`
    // into the returned closure object. Unlike a variable defined
    // in the closure body itself, this cache will be shared across
    // *all* invocations of the new function.
    move |s: &str| -> usize {
        // For simplicity, we clone the `&str` as the cache key
        // rather than worry about the lifetime annotations here.
        // If we didn't do this, it's possible that our internal `cache`
        // would hold a reference to a `str` even after that `str` was freed.
        let key: String = s.to_owned();
        // Look up the entry in our cache,
        // or create a new one if none exists.
        let result: usize = *cache.entry(key).or_insert_with_key(|key| str_len(key));
        result
    }
}

fn main() {
    let mut cached_str_len = make_cached_str_len();
    let key = "foo";

    // Prints:
    // Called expensive function str_len
    // Cached str len 1/2: 3
    println!("Cached str len 1/2: {}", cached_str_len(key));

    // Cached str len 2/2: 3
    println!("Cached str len 2/2: {}", cached_str_len(key));
}

Oczywiście, możliwe jest również utworzenie struct, która cachuje wewnętrzną pamięcię podręczną i po prostu wymaganie wywołującemu wywołania opakowaną funkcję za pomocą metody .call (uwaga techniczna: Rust obecnie nie obsługuje przeciążania operatora wywołania funkcji).

Cachowanie funkcji generyczne

A teraz abstrahujemy o jeden poziom: a jak chcemy napisać funkcję generyczną do cachowania, która może cachować wyniki dowolnej funkcji, a nie tylko konkretnie str_len? (Uwaga techniczna: aby uprościć sytuację, ograniczymy się do cachowania wyników tylko tych funkcji, które akceptują dokładnie jeden parametr, ponieważ Rust obecnie nie obsługuje “variadic generics”.) Możemy to osiągnąć za pomocą funkcji generycznej:

// Create a function which is generic over the key and value types,
// and accepts a "base" function which takes a key and returns a value.
//
// In order to store the key in the cache, we had to add the additional
// bounds `Eq + Hash` to `K`. To simplify the lifetimes, we added
// the lifetime bound `'static` to `K` and the bound `Clone` to `V`
// (and cloned the value before returning it).
fn cache_f<K: Eq + Hash + 'static, V: Clone>(f: impl Fn(&K) -> V) -> impl (FnMut(K) -> V) {
    let mut cache = HashMap::new();
    move |key: K| -> V {
        let result: &V = cache.entry(key).or_insert_with_key(|key| f(key));
        result.clone()
    }
}

A potem nieznacznie dostosowujemy podany parametr, żeby działały typy w tym przykładzie:

fn main() {
    // To make some types work, add an additional `&`
    // to the parameter type.
    let mut cached_str_len = cache_f(|s: &&str| str_len(s));
    let key = "foo";

    // Prints:
    // Called expensive function str_len
    // Cached str len 1/2: 3
    println!("Cached str len 1/2: {}", cached_str_len(key));

    // Cached str len 2/2: 3
    println!("Cached str len 2/2: {}", cached_str_len(key));
}

Uważanie funkcji jako wartość

Oczywiście z powodu, że zadaliśmy sobie tyle trudu, aby stworzyć tą pamięcię podrzęczną, pewnie chcemy podać ją przekazywać i używać. Idealnie moglibyśmy pisać to tak:

// `impl T` does not compile (yet).
type CachedF<K: Eq + Hash + 'static, V: Clone> = impl FnMut(K) -> V;
type CachedStrLenF = CachedF<&'static str, usize>;

fn accepts_cached_str_len(cached_str_len: CachedStrLenF) {
    let key = "foo";
    println!("Cached str len 1/2: {}", cached_str_len(key));
    println!("Cached str len 2/2: {}", cached_str_len(key));
}

fn main() {
    let mut cached_str_len = cache_f(|s: &&str| str_len(s));
    accepts_cached_str_len(cached_str_len);
}

Niestety, produkuje ten błąd:

error[E0658]: `impl Trait` in type aliases is unstable
  --> src/bin/main3-pass-function.rs:24:50
   |
24 | type CachedF<K: Eq + Hash + 'static, V: Clone> = impl FnMut(K) -> V;
   |                                                  ^^^^^^^^^^^^^^^^^^
   |
   = note: see issue #63063 <https://github.com/rust-lang/rust/issues/63063> for more information

error: non-defining opaque type use in defining scope
  --> src/bin/main3-pass-function.rs:35:5
   |
35 |     accepts_cached_str_len(cached_str_len);
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
note: used non-generic type `&'static str` for generic parameter
  --> src/bin/main3-pass-function.rs:24:14
   |
24 | type CachedF<K: Eq + Hash + 'static, V: Clone> = impl FnMut(K) -> V;
   |              ^

Nie możemy używać impl Fn w “type alias”, więc musimy to wypisać:

fn accepts_cached_str_len(mut cached_str_len: impl FnMut(&'static str) -> usize) {
    let key = "foo";
    println!("Cached str len 1/2: {}", cached_str_len(key));
    println!("Cached str len 2/2: {}", cached_str_len(key));
}

fn main() {
    let cached_str_len = cache_f(|s: &&str| str_len(s));
    accepts_cached_str_len(cached_str_len);
}

Czyli każde użycie naszej typu funkcji musi zawierać również parametry generycznych typów. To “zaraźliwe” zachowanie szybko staje się nieporęczne w praktyce dla programów nawet o średniej wielkości.

Kodowanie modułów

Moduły w OCaml

Moduły w stylu ML mogą ukrywać typy generyczne w sposób, w jaki same funkcje generyczne nie mogą osiągać (uwaga techniczna: używają pewnej formę typów “existential”). Aby wyrazić podobny przykład za pomocą modułów w stylu ML, możesz przejrzeć (i chyba nie zrozumieć) następujący kod OCaml:

module type Backend = sig
    type t
    type key
    type value
    val compute : t -> key -> value
end

module StrLenBackend = struct
    type t = unit
    type key = string
    type value = int
  let make () = ()
    let compute () key =
    Printf.printf "Computing length of string %s\n" key;
    String.length key
end

module CachedBackend(B: Backend) : sig
    type t
    type key = B.key
    type value = B.value
  val make : B.t -> t
    val compute_cached : t -> key -> value
end = struct
  type key = B.key
  type value = B.value
    type t = {
        backend: B.t;
        cache: (key, value) Hashtbl.t;
    }
  let make backend = {
    backend;
    cache = Hashtbl.create 0;
  }
    let compute_cached t key = match Hashtbl.find_opt t.cache key with
    | Some value -> value
    | None ->
      let value = B.compute t.backend key in
      let () = Hashtbl.add t.cache key value in
      value
end

Ostatecznie chodzi o to, że możesz napisać funkcję taką jak accepts_cached_str_len, za pomocą typu niegenerycznego, takiego jak CachedStrLenBackend.t:

let accepts_cached_str_len (cached_str_len : CachedStrLenBackend.t) =
  let key = "foo" in
  Printf.printf "Cached len 1/2: %d\n" (CachedStrLenBackend.compute_cached cached_str_len key);
  Printf.printf "Cached len 2/2: %d\n" (CachedStrLenBackend.compute_cached cached_str_len key);
  ()
  
let () =
    let backend = StrLenBackend.make () in
  let cached_str_len: CachedStrLenBackend.t = CachedStrLenBackend.make backend in
  accepts_cached_str_len cached_str_len;
 ()

“Associated” typy

Aby osiągnąć coś podobnego do modułów w stylu ML, możemy używać Rust typy “associated” [ang. “associated types”]. Najpierw, zmieniamy nasze typy funkcji w traits (uwaga techniczna: ostatecznie, to jest pewną formą “defunctionalization”).

trait Backend {
    // We declare "associated types" for this trait. For any type 
    // which implements `Backend`, it must declare corresponding `Key`
    // and `Value` types, and include an implementation of `compute`
    // adhering to those types.
    type Key;
    type Value;
    fn compute(&self, key: &Self::Key) -> Self::Value;
}

A teraz stworzymy naszą funkcję str_len jako nowy typ i implementację trait Backend:

// This type doesn't need state, but you could imagine
// embedding e.g. a database connection in this struct.
//
// Normally, types without any data aren't very useful, but
// this is one of the key ideas of the "encoding of ML-style
// modules". Instead of state (or in addition to state), the
// type instead has associated types and functions,
// declared below.
//
// This type corresponds to the "closed-over" variables
// of a closure object.
struct StrLenBackend;

impl Backend for StrLenBackend {
    type Key = &'static str;
    type Value = usize;
    fn compute(&self, key: &Self::Key) -> Self::Value {
        println!("Computing length of key {key:?}");
        key.len()
    }
}

Jak definiujemy generyczną wersję cachowanego backend, który działa dla dowolnego rodzaju Backend? Prosta wersja funkcji generycznej tak jak compute_cached<B: Backend> nie działa, bo chcemy, żeby przechowywał stan. Zamiast tego deklarujemy inny typ, który jest sparametryzowany na typie Backend:

struct CachedBackend<B: Backend> {
    backend: B,
    cache: HashMap<B::Key, B::Value>,
}

impl<B: Backend> CachedBackend<B>
where
    // We require that the wrapped backend adheres to these bounds
    // in order to call any of the functions in this `impl`
    // (including `new`, which is how you would get a new value
    // of this type).
    //
    // Previously, we had to add the appropriate bounds to 
    // each generic type in each place that it appeared.
    // Using a `trait`, we can instead declare the bounds
    // just once on the `impl`.
    B::Key: Eq + Hash,
{
    fn new(backend: B) -> Self {
        Self {
            backend,
            cache: Default::default(),
        }
    }

    fn compute_cached(&mut self, key: B::Key) -> &B::Value {
        self.cache
            .entry(key)
            .or_insert_with_key(|key| self.backend.compute(key.clone()))
    }
}

Następnie skonstruujemy wartości tych typów i przekazujemy je dalej. Inaczej niż wcześniej, możemy nawet stwarzać “type aliases” dla cachowanego typu funkcji — bez konieczności ponownego określenia parametrów typów generycznych w każdym miejscu.

type CachedStrLenBackend = CachedBackend<StrLenBackend>;

fn accepts_cached_str_len(mut cached_str_len: CachedStrLenBackend) {
    let key = "foo";

    // Prints:
    // Computing length of key "foo"
    // Cached len 1/2: 3
    println!("Cached len 1/2: {}", cached_str_len.compute_cached(key));

    // Cached len 2/2: 3
    println!("Cached len 2/2: {}", cached_str_len.compute_cached(key));
}

fn main() {
    let backend = StrLenBackend;
    let cached_str_len = CachedBackend::new(backend);
    accepts_cached_str_len(cached_str_len);
}

Parametryzowanie tylko nad typami

Przekazywanie dalej wartości, które ucieleśniają moduły jest właściwie najpotężniejszą formą tej techniki, odpowiadające “modułom pierwszej-klasy” [ang. “first-class modules”], ale jest to prawdopodobnie najbardziej naturalna forma wyrażania w Rust, ponieważ większość programistów zajmuje się raczej wartościami niż typami. Idealnie byłoby, gdyby optimizer wyeliminował narzut związany z przekazywaniem wartości, która nie zawiera danych.

Rzadko trzeba to robić, ale można wywoływać tylko na podstawie typu i zakazywać nawet budować wartości. Jest to również interesujące z pedagogicznego punktu widzenia jako przykład “kierowanego-przez-typ” [ang. “type-directed”] generowania kodu w Rust. Aby przepisać powyższy przykład bez tworzenia Backend, usuniemy wszędzie parametr &self:

trait Backend {
    type Key;
    type Value;

    // We no longer take a value of type `&self`.
    fn compute(key: &Self::Key) -> Self::Value;
}

// In Rust, it's not possible to make a value of the type
// of an empty enum.
enum StrLenBackend {}

impl Backend for StrLenBackend {
    type Key = &'static str;
    type Value = usize;
    fn compute(key: &Self::Key) -> Self::Value {
        println!("Computing length of key {key:?}");
        key.len()
    }
}

Następnie dostosujemy nasz CachedBackend, żeby bezpośrednio użył B, zamiast wywołać metody na wartości typu B, tak jak wywołanie B::compute:

// Note that we no longer have a member of type `B`.
struct CachedBackend<B: Backend> {
    cache: HashMap<B::Key, B::Value>,
}

impl<B: Backend> CachedBackend<B>
where
    B::Key: Eq + Hash,
{
    fn new() -> Self {
        Self {
            cache: Default::default(),
        }
    }

    fn compute_cached(&mut self, key: B::Key) -> &B::Value {
        self.cache
            .entry(key)
            .or_insert_with_key(|key| B::compute(key.clone()))
    }
}

type CachedStrLenBackend = CachedBackend<StrLenBackend>;

fn accepts_cached_str_len(mut cached_str_len: CachedStrLenBackend) {
    let key = "foo";

    // Prints:
    // Computing length of key "foo"
    // Cached len 1/2: 3
    println!("Cached len 1/2: {}", cached_str_len.compute_cached(key));

    // Cached len 2/2: 3
    println!("Cached len 2/2: {}", cached_str_len.compute_cached(key));
}

fn main() {
    // This weird syntax is equivalent to `CachedBackend<StrLenBackend>::new()`
    // in some other languages. It's written with an extra `::` due to
    // technical restrictions on the syntax.
    //
    // Note that, unlike before, we never pass a *value* into
    // the `CachedBackend`, only a type.
    let cached_str_len = CachedBackend::<StrLenBackend>::new();

    // We could also write the type annotation on the left side and let
    // type inference figure it out:
    let _also_works: CachedBackend<StrLenBackend> = CachedBackend::new();

    // Or we could use our previously-defined type alias:
    let _also_works = CachedStrLenBackend::new();

    accepts_cached_str_len(cached_str_len);
}

Inne kodowania

Moduły w stylu ML obejmują inne funkcje niż powyższe. Oto krótka dyskusja o kodowaniu tamtych funkcji:

include:
- Można używać poprzednio dyskutowane sposoby, tak jak “extension traits”.
- Albo możesz używać makr — widziałem to w systemach produkcyjnych. (Istnieją dobrze udokumentowane problemy z makrami, których tutaj nie omówię.)
Aktualizowanie modułów, czyli tworzenie nowej definicji istniejącego modułu z przedefiniowanym jednym z typów “associated”.
- Poza makrami, nie widziałem kodowania na to.
Typowanie strukturalne [ang. “structural typing”]
- Rust po prostu nie pozwala strukturalnego typowania obiektów podobnych do modułów. Możesz spróbować zmienić swoje implicytne strukturalne typy na eksplicytne hierarchię traits.
- Albo możesz używać makr.
“Applicative” vs “generative” funktory
- Zobacz https://stackoverflow.com/questions/52161048/applicative-vs-generative-functors
- Zależy od konkretnego kodowania modułu. Abstrakcje typów są wprowadzone ręcznie typami “associated” i zawsze są nierówne, podczas gdy typy przekazywane przez parametr typu generycznego mogą być uważane równe. Więc jeśli chcesz funktor generatywnego, możesz bezpośrednio wprowadzić nowy typ abstrakcyjny poprzez kolejną warstwę trait z typem “associated”.

Zobacz też The AST typing problem, abe znaleźć powiązane pytania dotyczące praktycznego kodowania modułów.

Powiązane posty

Poniżej znajduje się kilka ręcznie wybranych postów, które mogą Cię zainteresować.

Date		Title
17 Jun 2023	(this post)	Kodowanie w Rust modułów w stylu ML

Chcesz zobaczyć więcej moich postów? Obserwuj mnie na Twitterze albo subskrybuj za pomocą RSS.

Komentarze

Szybkie formatowanie stosu zatwierdzeń

Tue, 11 Apr 2023 00:00:00 +0000

Docelowi odbiorcy	Inżynierowie oprogramowanie pracujący z Git, którzy używają "patch stacks"/"stacked diffs", na przykład w jaki sposób Git jest używany w projektach Git i Linux, a także w wielu firmach wprowadzających "trunk-based development". Nie użytkownicy Git, który uważają, że graf zatwierdzeń Git powinien odzwierciedlać rzeczywisty proces rozwijania.
Pochodzenie	Moja praca nad git-branchless.
Nastrój	Prawdopodobnie niezważany.
Język	Obcy. Moim pierwszym język jest angielki. Jeśli zobaczysz błąd, niezależnie od tego, czy chodzi o pisownię, gramatykę czy dobór słow, skomentuj to!

Spis treści:

Powiązane posty
Komentarze

Pewna kategoria programistów używa Git z przypływem pracy “patch stack”, na którym zbierają ciąg małych, indywidualnie przeglądanych zatwierdzeń, które razem realizują znaczną zmianę. W takich przykładach, często przydatne jest uruchamianie linters lub formatters na każdym zatwierdzeniu w stosie i zastosowanie wyników. Może to być jednak żmudne, a naiwne podejście może powodować niepotrzebne konflikty scalania. (Jednym z obejść jest zastosowanie formatter na każdym zatwierdzeniu w stosie wstecz.)

Komenda git test z git-branchless przedstawia rozwiązanie do szybkiego uruchamiania formatters, itd., na całym stosie zatwierdzeń bez produkowania konfliktów scalania. Dodatkowo, może to zostać wykonywany równoległe, i zapisuje wyniki, żeby ponowne formatowania tego samego zatwierdzenia zostawił pominięte. Możesz zobaczyć post z ogłoszeniem lub dokumentację git test.

Oto demonstracja formatowania zatwierdzeń w stosie (przewiń do 0:35, aby zobaczyć tylko demonstrację git test fix):

Ja zwykle ustawiam git fmt na alias na coś takiego

git test run --exec 'cargo fmt --all' --strategy worktree --jobs 8

Powiązane posty

Poniżej znajduje się kilka ręcznie wybranych postów, które mogą Cię zainteresować.

Date		Title
11 Apr 2023	(this post)	Szybkie formatowanie stosu zatwierdzeń

Chcesz zobaczyć więcej moich postów? Obserwuj mnie na Twitterze albo subskrybuj za pomocą RSS.

Komentarze

e69de29bb2d1d6434b8b29ae775ad8c2e48c5391

Tue, 14 Mar 2023 00:00:00 +0000

Docelowi odbiorcy	Inżynierowie oprogramowania pracujący z Git, którzy natrafili na tą wartośc i chcą potwierdzić, że ma ona szczególne znaczenie.
Pochodzenie	Ogólne doświadczenie w Git.
Nastrój	Pomocny.
Język	Obcy. Moim pierwszym język jest angielki. Jeśli zobaczysz błąd, niezależnie od tego, czy chodzi o pisownię, gramatykę czy dobór słow, skomentuj to!

Spis treści:

Powiązane posty
Komentarze

Git stosuje hash e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 dla oznaczenia pustego blob (pusty plik).

W ramach potwierdzenia, możemy ręcznie zbudować zawartość takiego obiektu Git i obliczyć jego hash. Format zawartości obiektu to <typ> <rozmiar>\0<zawartość> (przy czym \0 oznacza znak null). W tym przypadku, typ to blob rozmiar wynosi 0 i nie ma zawartości. Można obliczyć hash za pomocą jednej z poniższych komend:

$ printf 'blob 0\0' | shasum
e69de29bb2d1d6434b8b29ae775ad8c2e48c5391  -

$ printf 'blob 0\0' | openssl dgst -sha1  
e69de29bb2d1d6434b8b29ae775ad8c2e48c5391

Zobacz też Why does Git hash only the Contents of A File? na powiązaną dyskusję.

Powiązane posty

Poniżej znajduje się kilka ręcznie wybranych postów, które mogą Cię zainteresować.

Date		Title
14 Mar 2023	(this post)	e69de29bb2d1d6434b8b29ae775ad8c2e48c5391

Chcesz zobaczyć więcej moich postów? Obserwuj mnie na Twitterze albo subskrybuj za pomocą RSS.

Komentarze

Moja historia płacy

Wed, 08 Mar 2023 00:00:00 +0000

Docelowi odbiorcy	Obecny inżynierzy oprogramowania szukający informacji dla swojego poszukiwania pracy lub negocjacja Osoby ciekawe o kompensacji w branży inżyniera oprogramowania w US (“poziom 3”).
Pochodzenie	Moja historia pracy.
Nastrój	Wstępnie pomocny, ale ostrożny.
Język	Obcy. Moim pierwszym język jest angielki. Jeśli zobaczysz błąd, niezależnie od tego, czy chodzi o pisownię, gramatykę czy dobór słow, skomentuj to!

Spis treści:

Historia płacy
Powiązane posty
Komentarze

Historia płacy

Inni udostępniali swoją płacę w rynku inżyniera oprogramowania. Z tych samych powodów, udostępniam własną płacę na tym połączeniu Google Sheets. Uważam tą informację trochę sensytywną, więc musisz poprosić o pozwolenie aby zobaczyć.

W ramach trójmodalnego modelu płacy, ponieważ pracowałem w US dla “big tech” i finansów, plasuję się dobrze w “poziomu 3”. Zatem, ta informacją jest głównie przydatna dla kogoś negocjującego z firmą poziomu 3.

W przypadku big tech, kompensacja zwykle jest dostana w postaci pensji, akcji (RSU), i rocznej premii opartej na wynikach.
W przypadku finansy, kompensacja zwykle jest dostana w postaci pensji i rocznej premii opartej na wynikach.

Jeśli masz pytania dotyczące kompensacji lub negocjacji jako inżynier oprogramowania w US, moje dane kontaktowe znajdziesz tutaj.

Powiązane posty

Poniżej znajduje się kilka ręcznie wybranych postów, które mogą Cię zainteresować.

Date		Title
08 Mar 2023	(this post)	Moja historia płacy

Chcesz zobaczyć więcej moich postów? Obserwuj mnie na Twitterze albo subskrybuj za pomocą RSS.

Komentarze

Ulepszenie przyrostowe czasy testowania Rust

Tue, 07 Feb 2023 00:00:00 +0000

Docelowi odbiorcy	Potencjalni i średnio-zaawansowani deweloperzy Rust, którzy martwią się wolnymi czasami kompilacji, ich skalą i praktykami zapobiegawczymi. Zaawansowani deweloperzy Rust, którzy pomogą mi poprawić czas kompilacji.
Pochodzenie	Moje doświadczenie w Rust.
Nastrój	Trochę udany; trochę rozczarowany.
Język	Obcy. Moim pierwszym język jest angielki. Jeśli zobaczysz błąd, niezależnie od tego, czy chodzi o pisownię, gramatykę czy dobór słow, skomentuj to!

Rust jest znany z wolnego czasu kompilacji. Spędziłem dużo czasu próbując poprawić przyrostowe czasy kompilacji testowania dla mojego projektu git-branchless w https://github.com/arxanas/git-branchless/pull/650. Oto dyskusja wyników.

Spis treści:

Streszczenie wykonawcze
Szczegóły projektu
Podzielenie się na więcej crates
Czas bez operacji
Koniec profilowania?
Koniec kolejnych pomysłów?
Powiązane posty
Komentarze

Streszczenie wykonawcze

“Przyrostowe testowania” odnosi się tylko do zmiany kodu testu integracyjnego i przebudowanie. Kod źródłowy pozostaje niezmienony.
Ostatecznie udało mi się skrócić przyrostowy czas testowania z ~6.9sek do ~1.7sek (~4x). Inne sposoby na skrócenie czasu kompilacji przyniosły niewielką lub żadną poprawę.

W celach informacyjnych, oto najlepsze artykuły dotyczące konceptualnego zrozumienia modelu kompilacji Rust i poprawy czasu kompilacji:

Fast Rust Builds (matklad.github.io, 2021)
How to Test (matklad.github.io, 2021)
Why is my Rust build so slow? (fasterthanli.me, 2021)
Tips for Faster Rust Builds (endler.dev, 2020-2022)
- W rzeczywistości, wówczas nie czytałem tego artykułu, ale przeczytałem kiedy napisałem ten artykuł.

Szczegóły projektu

Oto jak duży był mój projekt git-branchless przed pull request:

git-branchless/src: 12060 linii.
git-branchless/tests: 12897 linii.
- Zauważ, że w dużej mierze opiera się na “snapshot testing”, więc większość tych linii kodu to “multiline string literals”.
git-branchless-lib/src: 12406 linii.

Dopuszczalne są długie czasy kompilacji i konsolidacja, ale aby zoptymalizować sprzężenie zwrotnego programowania, potrzebuję krótkich czasów testowania. W szczególności chcę iterować nad pracowaniem pewnego testu. (IntelliJ ma fajną funkcję automatycznego ponownego uruchamiania danego testu, gdy występuje zmiana w kodu źródła ale trwanie zbyt długo ponownej kompilacji zmniejsza jej przydatność.)

Na początek zbudowanie binary test_amend (który testuje subcommand amend) po dodaniu pojedynczego komentarza do jego pliku testu (bez zmian w library!) wymaga ~6.9sek:

$ hyperfine --warmup 3 --prepare 'echo "// @nocommit test" >>git-branchless/tests/command/test_amend.rs' 'cargo test --test mod --no-run'   
Benchmark 1: cargo test --test mod --no-run
  Time (mean ± σ):      6.927 s ±  0.123 s    [User: 7.652 s, System: 1.738 s]
  Range (min … max):    6.754 s …  7.161 s    10 runs

Tragedia! To nie duży projekt, a zmieniamy tylko testy, więc nie powinno to wymagać tak długiego czasu iteracji.

Podzielenie się na więcej crates

W pull request wyodrębniłem do dodatkowych dziewięciu crates, co daje przyrostowy czas kompilacji testu wynoszący ~1.7sek (~4x poprawa).

$ hyperfine --warmup 3 --prepare 'echo "// @nocommit test" >>git-branchless/tests/test_amend.rs' 'cargo test --test test_amend --no-run'   
Benchmark 1: cargo test --test test_amend --no-run
  Time (mean ± σ):  	1.771 s ±  0.012 s	[User: 1.471 s, System: 0.330 s]
  Range (min … max):	1.750 s …  1.793 s	10 runs

Jeśli chodzi o poprawę względną, to znaczna, ale jeśli chodzi o poprawę bezwzględną, sądzę, że jest raczej słaba. Bym oczekiwał 100-200ms na parsing, macro expansion, typechecking, i code generation (bez optimacji) dla pliku tego rozmiaru (~1k linii, głownie długi wartości łańcuchowe).

Dodatkowe, dzielenie na wiele crates utrudnia rozpowszechnianie projektu za pośrednictwem crates.io:

Każdy crate wymaga indywidualnego publikowania na crates.io (nie można opublikować crate z zależnościami Git w crates.io).
- Dlatego muszę zarządzać wersjami i licencji każdego crate.
Według mojej ankiety wśród użytkowników, większość moich użytkowników instaluje program za pomocą cargo. Na pytanie “Jak zainstalowałeś git-branchless?”, odpowiedzi są następujące (stan na ):
- 7/18 (38.9%): przez cargo install git-branchless.
- 4/18 (22.2%): za pośrednictwem tradycyjnego systemowego menedżera pakietów.
- 4/18 (22.2%): przez Nix lub NixOS
- 2/18 (11.1%): klonując repozytorium i ręcznie budując i instalując.
- 1/18 (5.6%): przez artefakt kompilacji z GitHub Actions

Niestety, muszę publicznie udostępniać wewnętrzne moduły na crates.io tylko po to, aby uzyskać rozsądne czasy kompilacji.

Czas bez operacji

Wtedy, mierzę czas bez operacji [ang. “no-op”] na ~350ms dla mniejszej testowe crate z niewieloma zależnościami:

$ hyperfine --warmup 3 'cargo test -p git-branchless-test --no-run' 		 
Benchmark 1: cargo test -p git-branchless-test --no-run
  Time (mean ± σ):     344.2 ms ±   3.5 ms    [User: 246.2 ms, System: 91.9 ms]
  Range (min … max):   340.4 ms … 351.0 ms    10 runs

To jest nieoczekiwane. Spodziewałbym się, że czas na kompilację bez operacji będzie podobny do git status, może 15ms:

$ hyperfine --warmup 3 'git status'
Benchmark 1: git status
  Time (mean ± σ): 	 13.5 ms ±   2.5 ms    [User: 4.9 ms, System: 6.1 ms]
  Range (min … max):    11.1 ms …  24.7 ms    197 runs

Tu może być jakiś głębszy problem. Dokumentacja cargo nextest ostrzega, że niektóre systemy przeciw malware mogą wprowadzać sztuczne opóźnienie uruchamiania podczas sprawdzania plików wykonywalnych:

A typical sign of this happening is even the simplest of tests in cargo nextest run taking more than 0.2 seconds.

Zgodnie z dokumentacją, oznaczyłem moje oprogramowanie terminala jako “Developer Tools” w systemie macOS, ale nie udało mi się skrócić czasu kompilacji bez operacji.

Koniec profilowania?

Spróbowalem z subcommand crate, który niedawno stworzyłem bez wielu zaleźności:

$ hyperfine --warmup 3 --prepare 'echo "// @nocommit test" >>git-branchless-test/tests/test_test.rs' 'cargo test -p git-branchless-test --no-run'
Benchmark 1: cargo test -p git-branchless-test --no-run
  Time (mean ± σ):  	1.855 s ±  0.034 s	[User: 1.476 s, System: 0.335 s]
  Range (min … max):	1.831 s …  1.939 s	10 runs

Wykres czasu kompilacji według cargo build nie pomaga. Tylko pokazuje to, że budowany test wymaga 100% czasu:

The timing graph for building the git-branchless-test crate.

Koniec kolejnych pomysłów?

Oto niektóre pomysły, które nie zadziałały:

Połączenie testów integracyjnych w jeden binary. (W każdym razie chętnie uruchamiam indywidualne binaries, jeśli to konieczne.)
Zmniejszenie głównych monomorfozacji (wywołania AsRef itp. Pojawiły się w cargo llvm-lines, ale ich zmniejszenie nie zdawało się poprawiać czasu kompilacji).
Używanie sccache.
Używanie cargo nextest.
Używanie zld/mold/sold.
Ustawienie profile.dev.split-debuginfo = “unpacked” (dla systemu macOS).
Ustawienie profile.dev.build-override.opt-level = 3.
- Niestety, jest dużo makr proceduralnych, zwłaszcza #[instrument] z crate tracing.
Ustawienie profile.dev.debug = 0. W rzeczywistości skraca czas kompilacji o 20ms, ale samo w sobie nie wystarczy.

Więc teraz utknąłem. To najwięcej, jak mogę skrócić przyrostowe czasy testowania Rust. Daj znać, jeśli masz jakieś inne pomysły.

Powiązane posty

Poniżej znajduje się kilka ręcznie wybranych postów, które mogą Cię zainteresować.

Date		Title
07 Feb 2023	(this post)	Ulepszenie przyrostowe czasy testowania Rust

Chcesz zobaczyć więcej moich postów? Obserwuj mnie na Twitterze albo subskrybuj za pomocą RSS.

Komentarze

System kontroli wersja Yandex Arc

Fri, 27 Jan 2023 00:00:00 +0000

Docelowi odbiorcy	Deweloperzy systemów kontroli źródła, tak jak Git i Mercurial.
Pochodzenie	Moje notatki w Discordzie. Moje doświadczenie w programowaniu dla systemów kontroli źródła. Oficjalny blog Yandex.
Nastrój	Lekko zainteresowany.
Język	Obcy. Moim pierwszym język jest angielki. Jeśli zobaczysz błąd, niezależnie od tego, czy chodzi o pisownię, gramatykę czy dobór słow, skomentuj to!

Spis treści:

Powiązane posty
Komentarze

Ostatnio był przeciek koda z Yandex. Ja nie spradzałem plików, ale temat właśnie przypomina nam, że Yandex utrzymuje swoje duże monorepo, a nawet zbudował własny system kontroli źródła [ang. “source control system”], żeby sobie z tym radzić, o nazwie “Arc”.

Oryginalny artykuł z Yandex (2020): https://habr.com/ru/company/yandex/blog/482926/

Krótkie notatki (pierwotnie opublikowane na Discordzie):

Wydaje się, że jest oparty nad SVN na back-end.
Prowadzają trunk-based development.
6 mln zatwierdzeń, 2 mln plików, 2TB rozmiar repo.
Wypróbowali Mercurial, ale nie rozwiązał problemów wydajności.
Używają numery generacji [ang. “generation numbers”] do obliczania “merge-bases”.
- Jest to teraz dostępne w Gitu poprzez mechanizm commit-graph.
Prawdopodobnie oparty nad Gitem do front-end UI, ale narzekają, że UI Gita jest zły, więc go ulepszają.
Używany wewnętrznie przez 20% deweloperzy w momencie napisania.
Ciężko używa wirtualnego system plików [ang. “virtual filesystem”, “VFS”].
- Używają FUSE na macOS, chociaż wsparcie VFS’ów na macOS jest niestabilne w tym czasie; może zmienili od tamtego czasu?
Używa Yandex Database (YDB) jako bazę danych na back-end, z jakimś narzędziem przekładania z SVN’a.
W ramach systemu code review, zatwierdzenie Arc’a będzie przedkładane w zatwierdzenie SVN’a, w tym dodatkowe metadane z Arc’a.
Niezauważalnie używa zatwierdzenia dla “working copy” aby przeprowadzać niektóre algorytmy, który zawierać “untracked” pliki, ponieważ zaopatrzywa VFS.
- Wspomniałem o tym w kontekście Jujutsu VCS.

W sumie, nie wydaje mi się, że ma wiele do awansowania systemów kontroli wersji w porównaniu z dużymi firmami tech, takimi jak Google i Meta.

Powiązane posty

Poniżej znajduje się kilka ręcznie wybranych postów, które mogą Cię zainteresować.

Date		Title
27 Jan 2023	(this post)	System kontroli wersja Yandex Arc

Chcesz zobaczyć więcej moich postów? Obserwuj mnie na Twitterze albo subskrybuj za pomocą RSS.

Komentarze

Używanie `tracing` w aplikacji Rust CLI

Wed, 25 Jan 2023 00:00:00 +0000

Docelowi odbiorcy	Użytkownicy Rust.
Pochodzenie	Mój post na GitHub. Moje doświadczenie w Rust.
Nastrój	Informujący.
Język	Obcy. Moim pierwszym język jest angielki. Jeśli zobaczysz błąd, niezależnie od tego, czy chodzi o pisownię, gramatykę czy dobór słow, skomentuj to!

@epage w https://github.com/arxanas/git-branchless/discussions/732 zapytał:

Widzę, że mówią o tracing, ale głównie z perspektywy “web” i jestem ciekawy, jak to doświadczenie przekłada się na CLI. Zamierzam zastosować go w niektórych mniejszych CLI, żeby zdobyć trochę doświadczenia, aby zrozumieć, w jaki sposób może pomóc cargo.

Ponownie publikuję moją odpowiedź tutaj, w formie wypunktowanej.

Spis treści:

Dla Cargo
Pełne notatki
Powiązane posty
Komentarze

Dla Cargo

W przypadku Cargo chciałbym podkreślić następujące punkty:

Zachęca do robienia właściwych rzeczy za pomocą makr do ustrukturyzowanego logowania [ang. “structured logging”]. Dodatkowe obliczenia nie są przeprowadzane, jeśli nie zostaną używane przez subskrybenta, co w przeciwnym razie mogłoby spowodować regres wydajności.
Śledzenie “spantraces” w celu profilowania jest niewygodne, ponieważ trzeba ręcznie dodawać adnotacje do każdej funkcji, która ma być śledzona. Nie wiem, czy można to poprawić za pomocą “stack traces”.
Można łatwo wysyłać dane do wielu różnych subskrybentów, w tym do niestandardowych (…jeśli wiadomo, jakie funkcje wywołać). Na przykład, tracing_subscriber::fmt_layer::Layer::with_writer pozwala zbudować warstwę, która zużywa sformatowane informacje logowania i zapisuje je w dowolnym miejscu.
- Można używać gotowych komponentów, takich jak subskrybent śledzenia Chrome [ang. “Chrome tracing”, jakaś].
Ktoś może to skonfigurować raz, a inni nie muszą się tym zbytnio przejmować.
Dla mnie, profilowanie okazało się bardzo skuteczne.

Pełne notatki

Przez używanie eyre/color_eyre można dołączyć parametry funkcji do “spantraces”. Jest to dość cenne podczas debugowania, ponieważ widzę m.in. OID zatwierdzenia [ang. “commit OID”] w “spantrace” dla zatwierdzenia, które powoduje problemy, bez konieczności ręcznego wyodrębniania go przez dodanie większej liczby logów.
Konfigurowanie tracing po raz pierwszy jest uciążliwe, ale po tym w dużej mierze nie musisz go dotykać.
- Oto moja funkcja, która to robi: https://github.com/arxanas/git-branchless/blob/4b76af669258e80a6f6eb4ddf45bbb358da80248/git-branchless/src/commands/mod.rs#L437
- Z powodzeniem skonfigurowałem instrukcje logowania do drukowania za pomocą mojego własnego typu (Effects), zamiast drukowania bezpośrednio na stdout/stderr, ponieważ może to blokować liczniki postępu [ang. “progress meters”] lub inne interaktywnie dane wyjście.
- Skonfigurowałem go tak, że podprocesy nie zostaną zawarte w śledzeniu nadrzędnym; otrzymują własne pliki wyjściowe. Szczerze mówiąc, nie sądzę, żebym musiał badać śledzenie podprocesów.
- Kiedyś było to mniej ergonomiczne, ale ostatnio ulepszyli coś związanego z kompozycją warstw, na przykład filtrowanie jednej warstwy na podstawie innej warstwy; zobacz https://github.com/arxanas/git-branchless/commit/5428f1b9dbed356accf854774cad053c22d19b1f
- Niektóre komunikaty o błędach dotyczące kompozycji warstw mogą być nieczytelne z powodu domyślnego użycia polimorfizmu statycznego. Na przykład trudno jest warunkowo skonstruować warstwę do włączenia. Typy stają się bardzo długimi łańcuchami zagnieżdżonych parametrów typu ogólnego [ang. “generic type parameters”].
  - Na szczęście Option<Layer> jest również warstwą, więc możesz przekazać Some(layer) lub None w zależności od stosownego warunku, zamiast próbować bezpośrednio wywoływać metody rejestru.
Makro #[instrument] to jedyny realistyczny sposób dołączania funkcji do “spantraces” dla eyre/color_eyre.
- Niszczy to autopoprawki [ang. “autofixes”, tak jak w IDE] (prawdopodobnie należy to uznać za błąd w rust-analyzer).
- Może to wymazać lokalizację błędów, ponieważ czasami błąd jest przypisywany do funkcji jako całości, a nie do konkretnej linii.
- Może to wydłużyć czas kompilacji, ponieważ jest to makro proceduralne [ang. “procedural macro”, pojęcia z Rusta]. Jak być może wiesz, procedury makr proceduralnych, takie jak syn [ang. Rust crate zwany “syn”, nie ma czegoś wspólnego z słowem “syn”], zwykle znajdują się na ścieżce krytycznej [ang. “critical path”] kompilacji, ale jeśli zobowiążesz się w ogóle nie używać makr proceduralnych, możesz je pominąć.
Profilowanie poprzez zrzut do warstwy śledzenia Chrome jest skuteczne.
- Spójrz na https://github.com/arxanas/git-branchless/wiki/Runbook#profiling, aby uzyskać szczegółowe informacje na temat procedur profilowania.
- Wielokrotnie korzystałem z tego systemu do debugowania problemów/regresji w związku wydajnością. Istniejące wizualizatory śledzenia Chrome są całkiem przydatne do analizy podziału spędzonego czasu.
- Zawarcie parametrów funkcji było wyjątkowo przydatne, ponieważ mogłem bezpośrednio zobaczyć wycinek danych wyjściowych profilowania, który trwał zbyt długo, i sprawdzić odpowiedni OID zatwierdzenia, dzięki czemu mogłem zbadać i przetestować to konkretne zatwierdzenie.
Spróbowałem użyć śledzenia jako danych wejściowych do mojego własnego systemu raportowania postępów (tak, aby wywołania funkcji były bezpośrednio powiązane z paskami postępu, które pojawiają się na ekranie). Było to możliwe, ale ostatecznie zrezygnowałem z tego podejścia, ponieważ operacje logiczne nie odpowiadały dokładnie jeden do jednego wywołaniom funkcji, a zbyt łatwo było zapomnieć o poprawnym opatrzeniu metodą adnotacją.
W ogóle nie próbowałem śledzenia z async/.await.
W ogóle nie próbowałem https://github.com/tokio-rs/console, ale chciałbym wiedzieć, czy jest to dla Was przydatne.
Ustrukturyzowane logowanie jest świetne.
- Samo użycie makr ustrukturyzowanego logowania z reprezentacjami debugowania (np. warn(?var, "Message")) jest znacznie bardziej ergonomiczne niż ręczne interpolowanie wartości do stringów.
- Obsługuje również takie rzeczy, jak renderowanie znaków niedrukowalnych, gdzie wcześniej musiałbym uważać, aby uwzględnić wartości stringów w cudzysłowach itp.
- Zasadniczo można zobaczyć te zdarzenia i ich wartości w wynikach profilowania, chociaż nie musiałem profilować na podstawie pojedynczych zdarzeń, tylko na podstawie całego zakresu.
- Jest to bardziej wydajne, ponieważ nie będziemy budować sznurów, jeśli wartości nie zostaną zużyte przez żadnego subskrybenta w czasie wykonywania.
Istnieje dziwna niezgodność między wersją tracing_subscriber używaną przez mój kod i color_eyre, co oznacza, że zablokowałem ją w znanej dobrej wersji tutaj: https://github.com/arxanas/git-branchless/pull/533/ zatwierdzenia/e97954a9a9fab4039ad269d6b8982bb8bd95b133.
- Myślę, że color_eyre musi po prostu zaktualizować swoją wersję śledzenia-subskrybenta, ale od tamtej pory się tym nie zajmowałem.

Powiązane posty

Poniżej znajduje się kilka ręcznie wybranych postów, które mogą Cię zainteresować.

Date		Title
25 Jan 2023	(this post)	Używanie `tracing` w aplikacji Rust CLI

Chcesz zobaczyć więcej moich postów? Obserwuj mnie na Twitterze albo subskrybuj za pomocą RSS.

Komentarze

Interaktywne blogi

Wed, 11 Jan 2023 00:00:00 +0000

Spis treści:

Niech żyje ten blog
Powiązane posty
Komentarze

Dla mnie, najlepszym platformą na blogging jest Google Docs, bo obsługuje poniższe:

Współpracować na żywo.
Pozostawiać komentarze bezpośrednio w tekście, a nie w ograniczonym obszarze.
Sugerować zmiany bezpośrednio w tekście. Cóż miły sposób na poprawianie tekstu!
- Z tego powodu również wolę Wikis od Git’a, jeśli chodzi o pisanie dokumentacji, bo bariera wejścia jest znacznie mniejsza.

Niestety, Google Docs nie jest zwłaszcza dostępny:

Wydaje się, że nie będzie indeksowany przez wyszukiwarki?
Wymaga Javascript.
Wymaga Google, czemu niektórzy ludzie sprzeciwiają się ze względu na prywatność.

Dlatego nie wydaję w ten sposób postów na blogu.

Ale w dobie hipermediów te funkcje powinny być standardem! Powinniśmy dyskutować, a nie wyrzucać artykuły w próżnię!

Medium wyświetlało komentarze w tekście, ale już tego nie robi (nie żebym chciał wydawać posty na Medium). Nie widziałem wielu innych blogów, które zapraszają do dyskusji za pomocą interaktywnych funkcji.

Kiedyś czytałem Real World OCaml, kiedy jego drugie wydanie było w wersji roboczej. Po każdym zdaniu znajdował się link na pozostawianie komentarza. To jest naprawdę fajny sposób na pisanie książki! Dlaczego akurat książka jest bardziej interaktywna niż nasze blogi?

Niech żyje ten blog

Od niedawna można pozostawiać komentarze na akapitach mojego blogu, najeżdżając/dotykając i klikając link “Skomentuj”, który się pojawi.

Inne rozwiązania:
- https://utteranc.es
- Disqus
  - Używany już do komentarzy na tym blogu, chociaż jest trochę podejrzany, jeśli chodzi o korzystanie plików cookie.
- Każda z tych opcji wymaga tworzenie własnego wątku komentarza dla każdego akapitu, na którym można skomentować.
  - Ich UIs nie zostały zaprojektowane tak, aby były zwarte, więc nie pasują dobrze między akapitami na blogu. Byłoby ogromny formularz po każdym akapitu.
  - Spowodowałoby to niepotrzebne obciążenie serwerów komentarzy, trochę niegrzecznie dla nich.
  - Spowodowałoby to wolniejsze ładowanie strony podczas zapytania do kilku wątków komentarzy.
- Możesz czerpać inspirację z projektu takiego jak SideComments.js.
- Moja implementacja niestety opiera się na GitHub jako dostawcy uwierzytelniania i bazie danych. Jestem pewien, że wielu czytelników nie będzie miało kont GitHub’a.
  - To był dla mnie najłatwiejszy sposób na zaimplementowanie.
  - GitHub API jest wystarczająco wyrazisty, aby wysłać zapytanie o wszystkie komentarze dla pewnego dokumentu w jednym żądaniu.
  - GitHub API nie wymaga uwierzytelniania ani klucza API do wysyłania żądań!
    - Przypuszczalnie będziesz ograniczany bardziej agresywnie niż w przypadku uwierzytelnienia.
  - Otwarcie nowej strony GitHub Issues’a w celu pozostawiania komentarza jest niewygodnie.
  - Patrząc wstecz, być może powinienem był użyć GitHub Discussions’a zamiast GitHub Issues’a jako bazy daty, ponieważ są to… dyskusje.
- Akapity są identyfikowane za pomocą permalinku/”slug” i poprzez pobranie kilku pierwszych znormalizowanych bajtów danych w akapicie i zakodowanie jako base64.
  - Teoretycznie identyfikatory akapitów nie są zatem stabilne, jeśli treść zmienia się później, ale wydaje się, że jest to niewielki problem.
- Oto implementacja w momencie pisania tego tekstu (137 linii kodu): github-comment-links.js.
  - Nowoczesne API przeglądarki sprawiają, że zapytanie do API GitHub’a jest dość proste.

Powiązane posty

Poniżej znajduje się kilka ręcznie wybranych postów, które mogą Cię zainteresować.

Date		Title
11 Jan 2023	(this post)	Interaktywne blogi

Chcesz zobaczyć więcej moich postów? Obserwuj mnie na Twitterze albo subskrybuj za pomocą RSS.

Komentarze

Gdzie są moje funkcji Git’a z przyszłości?

Thu, 05 Jan 2023 00:00:00 +0000

Git jest do bani

System kontroli wersji “Git” od 15+ lat przynosi nam nieszczęście. Od momentu powstania, tysiące osób próbowało stworzyć nowe klienty Git’a aby poprawić jego użyteczność.

Jednak, prawie każda z nich skupiła się budować ładną fasadę nad Git’em, żeby robić te same operacji, które właśnie robi Git, jakby interfejs linii komend Git’a był szczytem użyteczności.

Nikt nie raczy się zastanowić: jakie są przepływy pracy, które osoby właśnie chcą wykonywać? Jakie są funkcji, ułatwiające takie przepływy pracy? Zamiast, dostajemy klienty, które uważają, że git rebase -i to najlepszy sposób, aby zmienić komunikat zatwierdzenia, aby edytować zatwierdzenie, aby rozdzielić zatwierdzenie — albo, że warto nawet pokazać w UI tę funkcję.

Spis treści:

Git jest do bani
Rubryka
Klienty
Wyróżnienia
Powiązane posty
Komentarze

Rubryka

Rozmyślałem o przepływach pracy, które często wykonuję, i sprawdziłem kilka klientów Git’a (niektóre z nich są GUIs, i niektóre TUIs), żebym zrozumiał, jak dobrze je obsługują.

Wielu z moich czytelników nie dba o tych przepływach pracy, ale to nie tylko sprawa samych przepływach pracy; chodzi o decyzję, by nie używać wadliwych prymitywnych oferowanych przez Git.

Przepływy pracy:

reword: Trzeba być możliwe aktualizować komunikat zatwierdzenia, który nie jest wypożyczany.
- Aktualizowanie komunikatu zatwierdzenia nie spowoduje konfliktu scalania, zatem nie jest potrzebny wymagać, że zatwierdzenie jest wypożyczany.
- Też powinno być możliwe aktualizować komunikat zatwierdzenia, który jest przodkiem wielu gałęzi, bez porzucania niektórych z tych gałęzi, ale nie róbmy sobie nadziei…
sync: Trzeba być możliwe synchronizować wszystkie moje gałęzi (albo dowolny podzbiór) przez scalanie lub zmianę bazy [ang. “rebase”], w jednej operacji!
- Robię to cały czas! Praktycznie pierwsza rzecz każdego ranka przychodząc do pracy.
split: Trzeba być szczególne polecenie, aby dzielić zatwierdzenie na dwa lub więcej zatwierdzeń, w tym zatwierdzenia, które nie są aktualnie wypożyczane.
- Dzielenie zatwierdzenia nie spowoduje konfliktu scalania, zatem nie jest potrzebny wymagać, że zatwierdzenie jest wypożyczany.
- Nie akceptuję rozwiązań za pomocą git rebase -i, ponieważ sprawdzanie stanu repozytorium podczas zmiany bazy jest bardzo mylące.
preview: Przed wykonaniem scalania albo zmianą bazy, trzeba być możliwy podgląd wyniku, w tym ewentualne konflikty.
- W ten sposób, nie muszę rozpoczynać scalania/zmiany bazy, żeby zobaczyć, czy się powiedzie, albo czy będzie trudno mi rozwiązać konflikty.
- Konfliktami scalania może są najokropniejsza rzecz w używaniu Git’a, dlatego powinno być bardzo łatwiej zajmować się nimi (albo unikać zajmowania się nimi!).
undo: Trzeba być możliwe cofnąć się z dowolnej operacji, najlepiej obejmujące śledzone-ale-niezatwierdzone zmiany.
- To nie to samo, co cofnięcie [ang. “revert”] zatwierdzenia. Cofnięcie zatwierdzenia tworzy całkowicie nowe zatwierdzenie z odwrotnych zmian, ale cofnięcie operacji powinno przywrócić repozytorium do stanu, w jakim znajdowało się przed wykonaniem operacji, więc nie byłoby pierwotnego zatwierdzenia do przywrócenia.
large-load: UI powinien szybko ładować duże repozytorium.
- UI nie powinien zawieszać się w żadnym momencie i powinien pokazywać przydatne informacje zaraz po załadowaniu. Nie powinieneś czekać na załadowanie całego repozytorium, zanim będziesz mógł sprawdzić zatwierdzenia i gałęzi.
- Program może działać wolno przy pierwszym wywołaniu w celu zbudowania niezbędnych pamięci podręcznych, ale musi reagować szybko na kolejne wywołania.
large-ops: UI powinien reagować szybko podczas wykonywania różnych operacji, takich jak sprawdzanie zatwierdzeń i gałęzi, lub scalanie i zmianę bazy.

Dodatkowe punkty:

Przyznam honorowe punkty ujemne każdemu klientowi, który ośmieli się potraktować git rebase -i tak, jakby był fundamentalnym prymitywem.
Przyznam honorowe punkty bonusowe każdemu klientowi, który wydaje się szanować empiryczne badania użyteczności dla Git (lub innych VCS).
- Gitless: https://gitless.com/
- IASGE: https://investigating-archiving-git.gitlab.io/

Z powodu, że nie zapisałem nic z tego, te kryteria są tylko po to, aby każdy sprzedawca tych klientów mógł wiedzieć, czy jestem pod wrażeniem, czy rozczarowany.

Klienty

Wybrałem arbitralnie kilku klientów z tej listy klientów. Z pewnością mylę się co do niektórych z tych punktów (lub zmieniły się od ostatniego razu), więc skomentuj.

Aktualizacja 2022-01-09: Dodałem IntelliJ.
Aktualizacja 2022-01-10: Dodałem Tower.
Aktualizacja 2023-05-28: Podniosłem ocenę reword dla Magit.

Załączyłem mój własny projekt git-branchless, ale się nie liczy jako przykład innowacji w branży. Tylko jest tu, aby pokazać, że wiele z tych przepływów pracy jest naprawdę możliwych.

	Git CLI	GitKraken	Fork	Sourcetree	Sublime Merge	SmartGit	Tower	GitUp	IntelliJ	Magit	Lazygit	Gitui	git-branchless	Jujutsu
`reword`	❌ ¹	❌	❌	❌	⚠️ ²	❌	⚠️ ²	✅	⚠️ ²	❌	❌	❌	✅	✅
`sync`	❌	❌	❌	❌	❌	❌	❌	❌	❌	❌	❌	❌	✅	❌
`split`	❌ ¹	❌	❌	❌	❌	❌	❌	✅	❌	❌	❌	❌	❌	✅
`preview`	❌	❌	⚠️ ³	❌	⚠️ ³	❌	⚠️ ³	❌	❌	✅ ⁴	❌	❌	⚠️ ⁵	✅ ⁶
`undo`	❌	✅	❓	✅	✅	❌	✅	✅	❌	❌	⚠️ ⁷	❌	✅	✅
`large-load`	✅ ⁸	❌	❌	❌	✅	❌	❌	❌	✅	✅ ⁹	✅	✅	✅	❌
`large-ops`	✅ ⁸	❌	❌	✅	✅	❌	❌	✅	✅	✅ ⁹	✅	✅	✅	❌

Uwagi:

¹ Można to zrobić za pomocą git rebase -i lub odpowiednika, ale nie jest to ergonomiczne i działa tylko w przypadku zatwierdzeń osiągalnych z HEAD, a nie z innych gałęzi.
² Zmiana komunikatu zatwierdzenia można wykonać bez wypożyczaniu zatwierdzenia, ale tylko na zatwierdzeń osiągalnych z HEAD. Może istnieją dodatkowe ograniczenia.
³ Częściowe wsparcie. Może pokazać, czy można przewijać scalanie do przodu, ale bez dodatkowych szczegołów.
⁴ Można to robić za pomocą magit-merge-preview.
⁵ Częściowe wsparcie. Jeśli operacja spowoduje konflikt scalania, i opcja --merge nie została przekazana, zamiast tego zostanie przerwana i pokaże liczbę plików w stanu konfliktu.
⁶ Jujutsu nie pozwala na podgląd konfliktów scalania, ale scalanie i rebase zawsze się udają, a konflikty są przechowywane w zatwierdzeniu, a potem możesz cofnąć operację, jeśli nie chcesz zajmować się konfliktami scalania. W razie potrzeby możesz nawet przywrócić starą wersję zatwierdzenia po przeprowadzeniu scalania/zmiany bazy. Pozwala to uniknąć przerywania przepływu pracy, co jest ostatecznym celem tej funkcji, dlatego oceniam, że wystarczy dla tej kategorii.
⁷ Obsługa cofania jest eksperymentalna i zależy na reflogu, który nie może cofnąć wszystkich rodzajów operacji.
⁸ Git ma problemy z niektórymi operacjami na dużych repozytoriach i można je ulepszyć, ale uznamy to za podstawową wydajność dla dużych repozytoriów.
⁹ Chyba Magit ma taką samą wydajność jak Git, ale nie sprawdziłem, bo nie używam Emacs’a.

Wyróżnienia

Pochwały:

GitUp: najbardziej innowacyjny GUI dla Git’a spośród powyższych.
GitKraken: wprowadza innowację w niektórych obszarach, takie jak ulepszona obsługa scentralizowanych przepływów pracy przez ostrzeganie o współbieżnie edytowanych plikach. Te obszary nie są napisane powyżej; Po prostu zauważyłem je przy innych okazjach.
Sublime Merge: niesamowicie responsywny, jak można się spodziewać po ludziach odpowiedzialnych za Sublime Text.
Tower: za przyjemną implementację cofania.

Wady:

Fork: za utrudnienie wyszukiwania dokumentacji (bo “git fork undo” zazwyczaj produkuje wyniki cofania rozwidlenia w ogóle, a nie dla klienta Fork).
SmartGit: z braki we wszystkich testowanych kategoriach.

Powiązane posty

Poniżej znajduje się kilka ręcznie wybranych postów, które mogą Cię zainteresować.

Date		Title
05 Jan 2023	(this post)	Gdzie są moje funkcji Git’a z przyszłości?

Chcesz zobaczyć więcej moich postów? Obserwuj mnie na Twitterze albo subskrybuj za pomocą RSS.