add resume and git-subtrac
This commit is contained in:
parent
4c2582760d
commit
e77a0674fe
|
@ -0,0 +1,99 @@
|
||||||
|
---
|
||||||
|
title: "git-subtrac met andrewrk"
|
||||||
|
date: 2022-04-23T05:37:51+03:00
|
||||||
|
draft: true
|
||||||
|
---
|
||||||
|
|
||||||
|
TLDR: I wish `git clone` with default parameters would clone the submodules if
|
||||||
|
they are in the same repository.
|
||||||
|
|
||||||
|
git submodules meet andrewrk
|
||||||
|
----------------------------
|
||||||
|
|
||||||
|
I use [`git-subtrac`][git-subtrac] for some of my projects, and was not very
|
||||||
|
enthusiastic about Zig getting it's own package manager (can we all use
|
||||||
|
git-subtrac and be done with it?). A few weeks ago in a park in Milan my
|
||||||
|
conversation with [Andrew Kelley](https://andrewkelley.me/) was something like:
|
||||||
|
|
||||||
|
- me: "yadda yadda git submodules vendoring dependencies yadda yadda".
|
||||||
|
- Andrew: "if I clone a repository that uses git-subtrac with no extra
|
||||||
|
parameters, will it work as expected?"
|
||||||
|
- me: "no, you have to pass `--recursive`, so git will checkout submodules...
|
||||||
|
even if they are already available locally."
|
||||||
|
- Andrew: "then it's a piece-of-shit-approach."
|
||||||
|
|
||||||
|
Uh, I agree. People have not grown muscle memory to add `git clone --recursive
|
||||||
|
<repo>` and never will, so it's impossible to adopt git-subtrac beyond
|
||||||
|
well-controlled silos. Which is why we will have a
|
||||||
|
yet-another-programming-language-specific-package-manager, this time for zig.
|
||||||
|
Or at least my argument for using git-subtrac stops right there.
|
||||||
|
|
||||||
|
About git-subtrac
|
||||||
|
-----------------
|
||||||
|
|
||||||
|
[`git-subtrac`][git-subtrac] manages dependencies of some of my projects. It is
|
||||||
|
like git submodules, but all refs of the dependencies stay in the same
|
||||||
|
repository. Wait, stop here. Repeat after me: _it is like git submodules, but
|
||||||
|
all refs stay in the same repository_. I call it "good vendoring". Since all
|
||||||
|
the deps are in our repo, no external force can make our dependency
|
||||||
|
unavailable.
|
||||||
|
|
||||||
|
It is, howerver, harder to *add* a dependency than with, say, `go get
|
||||||
|
<dependency>`. Let's talk about auditing dependencies.
|
||||||
|
|
||||||
|
Auditing dependencies
|
||||||
|
---------------------
|
||||||
|
|
||||||
|
In "modern" programming languages with their package managers dependencies are
|
||||||
|
easy to add, hard to remove, and the maintenance burden grows with their
|
||||||
|
amount. Package managers claim to take care of transitive dependencies. Which
|
||||||
|
is convenient to the developer, but, as Corbet says, frees (or denies,
|
||||||
|
depending how one looks at it) developers from their basic right (or
|
||||||
|
obligation?) to understand them. "We can't understand why Kids These Days
|
||||||
|
just don't want to live that way" -- [Jonathan Corbet, 2022 April][linux-rust].
|
||||||
|
|
||||||
|
Here is my dependency checklist:
|
||||||
|
|
||||||
|
- Obvious: does it work at all?
|
||||||
|
- How easy is it to build, run and run it's tests?
|
||||||
|
- Is it well written? API surface, documentation, tests, error handling, error
|
||||||
|
signaling, logging, metrics (if applicable), etc.
|
||||||
|
- It's system dependencies.
|
||||||
|
- It's transitive dependencies.
|
||||||
|
|
||||||
|
Zooming into the last part: C projects tend to do it well. For Go and Python
|
||||||
|
projects a small number of dependencies is often a sign of care and quality on
|
||||||
|
other areas, too. [mattn/go-sqlite3](https://github.com/mattn/go-sqlite3),
|
||||||
|
[google/brotli](https://github.com/google/brotli),
|
||||||
|
[apenwarr/redo](https://github.com/apenwarr/redo),
|
||||||
|
[cmph](http://cmph.sourceforge.net/) are good examples.
|
||||||
|
|
||||||
|
If a dependency is well written, but has more transitive dependencies than I
|
||||||
|
need and there is no good alternative, I will fork it and remove unnecessary
|
||||||
|
code and dependencies. My recent example is
|
||||||
|
[sql-migrate](https://github.com/motiejus/sql-migrate).
|
||||||
|
|
||||||
|
If I may combine Corbet's views with mine: if we understand and audit our
|
||||||
|
dependencies (and transitive ones), we will have less dependencies and a more
|
||||||
|
maintainable system. Win-win.
|
||||||
|
|
||||||
|
Which brings us to...
|
||||||
|
|
||||||
|
Transitive dependencies and git-subtrac
|
||||||
|
---------------------------------------
|
||||||
|
|
||||||
|
[`git-subtrac`][git-subtrac] does not deal with transitive dependencies. At
|
||||||
|
least not directly. Or I am not aware of it. Ok, I haven't tried.
|
||||||
|
|
||||||
|
If we audit and thus understand our dependencies, we will be able to add
|
||||||
|
transitive ones to our project even without support of git-subtrac. So perhaps
|
||||||
|
git-subtrac shouldn't care?
|
||||||
|
|
||||||
|
Conclusion
|
||||||
|
----------
|
||||||
|
|
||||||
|
Can git checkout local submodules when they are in the same repository, so we
|
||||||
|
can reconsider (of not having) a package manager for zig?
|
||||||
|
|
||||||
|
[git-subtrac]: https://github.com/apenwarr/git-subtrac/
|
||||||
|
[linux-rust]: https://lwn.net/SubscriberLink/889924/a733d6630e3b5115/
|
|
@ -0,0 +1,48 @@
|
||||||
|
---
|
||||||
|
title: "Resume"
|
||||||
|
---
|
||||||
|
|
||||||
|
In reverse-chronological order.
|
||||||
|
|
||||||
|
## Uber: 2016-now
|
||||||
|
|
||||||
|
Core Infrastructure. Areas:
|
||||||
|
|
||||||
|
- Solving problems of Core Infra via various initiatives.
|
||||||
|
- Writing tools that manage our fleet.
|
||||||
|
- Trained an Incident Response team in EU.
|
||||||
|
|
||||||
|
Tech: Go and Linux.
|
||||||
|
|
||||||
|
## Amazon: 2014-2016
|
||||||
|
|
||||||
|
- Worked on Amazon WorkMail.
|
||||||
|
- Intersection between the business application and the system (and networks)
|
||||||
|
that are running it.
|
||||||
|
|
||||||
|
Tech: Java, Linux and AWS public offerings.
|
||||||
|
|
||||||
|
## Spil Games: 2012-2014
|
||||||
|
|
||||||
|
- Backend application developer.
|
||||||
|
- Networking and Linux investigator.
|
||||||
|
|
||||||
|
Tech: Erlang, C and Linux.
|
||||||
|
|
||||||
|
## Glasgow University: 2011-2012
|
||||||
|
|
||||||
|
Linux systems and hardware administrator.
|
||||||
|
|
||||||
|
## Mano Numeris: 2010-2011
|
||||||
|
|
||||||
|
Business line application developer in Erlang.
|
||||||
|
|
||||||
|
# Education
|
||||||
|
|
||||||
|
## Vilnius University: 2019-2021
|
||||||
|
|
||||||
|
MSc in Cartography.
|
||||||
|
|
||||||
|
## University of Glasgow: 2010-2013
|
||||||
|
|
||||||
|
BSc in Computing Science.
|
Loading…
Reference in New Issue