diff --git a/.gitignore b/.gitignore index 2c1edb8..341caa6 100644 --- a/.gitignore +++ b/.gitignore @@ -1,2 +1,3 @@ /report.pdf /result +/.pre-commit-config.yaml diff --git a/.markdownlint.yaml b/.markdownlint.yaml new file mode 100644 index 0000000..3de5073 --- /dev/null +++ b/.markdownlint.yaml @@ -0,0 +1,4 @@ +default: true + +# I use top-level titles for each section +MD025: false diff --git a/flake.lock b/flake.lock index b84cf74..efff0aa 100644 --- a/flake.lock +++ b/flake.lock @@ -2,38 +2,65 @@ "nodes": { "futils": { "locked": { - "lastModified": 1618868421, - "narHash": "sha256-vyoJhLV6cJ8/tWz+l9HZLIkb9Rd9esE7p+0RL6zDR6Y=", + "lastModified": 1623875721, + "narHash": "sha256-A8BU7bjS5GirpAUv4QA+QnJ4CceLHkcXdRp4xITDB0s=", "owner": "numtide", "repo": "flake-utils", - "rev": "eed214942bcfb3a8cc09eb3b28ca7d7221e44a94", + "rev": "f7e004a55b120c02ecb6219596820fcd32ca8772", "type": "github" }, "original": { "owner": "numtide", + "ref": "master", "repo": "flake-utils", "type": "github" } }, "nixpkgs": { "locked": { - "lastModified": 1619180214, - "narHash": "sha256-wt1uDD9RAxc3wdWOQp8zM3+ZyLb2rbnGIeaIuXGzw80=", + "lastModified": 1626764163, + "narHash": "sha256-TB+mtRpwn6pnoUXjBvJPIgHKkwLtjzFji4tkANlZWJQ=", "owner": "NixOS", "repo": "nixpkgs", - "rev": "112a3b08e9bcffa58e0f79af0072fc8273933b87", + "rev": "1441fa74d213d7cc120d9d7d49e540c1fc59bc58", "type": "github" }, "original": { "owner": "NixOS", + "ref": "nixpkgs-unstable", "repo": "nixpkgs", "type": "github" } }, + "pre-commit-hooks": { + "inputs": { + "flake-utils": [ + "futils" + ], + "nixpkgs": [ + "nixpkgs" + ] + }, + "locked": { + "lastModified": 1624971177, + "narHash": "sha256-Amf/nBj1E77RmbSSmV+hg6YOpR+rddCbbVgo5C7BS0I=", + "owner": "cachix", + "repo": "pre-commit-hooks.nix", + "rev": "397f0713d007250a2c7a745e555fa16c5dc8cadb", + "type": "github" + }, + "original": { + "owner": "cachix", + "ref": "master", + "repo": "pre-commit-hooks.nix", + "type": "github" + } + }, "root": { "inputs": { "futils": "futils", - "nixpkgs": "nixpkgs" + "nixpkgs": "nixpkgs", + "pre-commit-hooks": "pre-commit-hooks" } } }, diff --git a/flake.nix b/flake.nix index 1bdafcf..10916bd 100644 --- a/flake.nix +++ b/flake.nix @@ -2,12 +2,34 @@ description = "Ambroisie's CV"; inputs = { - nixpkgs.url = "github:NixOS/nixpkgs"; - futils.url = "github:numtide/flake-utils"; + futils = { + type = "github"; + owner = "numtide"; + repo = "flake-utils"; + ref = "master"; + }; + + nixpkgs = { + type = "github"; + owner = "NixOS"; + repo = "nixpkgs"; + ref = "nixpkgs-unstable"; + }; + + pre-commit-hooks = { + type = "github"; + owner = "cachix"; + repo = "pre-commit-hooks.nix"; + ref = "master"; + inputs = { + flake-utils.follows = "futils"; + nixpkgs.follows = "nixpkgs"; + }; + }; }; - outputs = { self, nixpkgs, futils } @ inputs: - futils.lib.eachSystem futils.lib.allSystems (system: + outputs = { self, futils, nixpkgs, pre-commit-hooks } @ inputs: + futils.lib.eachDefaultSystem (system: let inherit (nixpkgs) lib; pkgs = nixpkgs.legacyPackages.${system}; @@ -16,19 +38,46 @@ pandoc (texlive.combine { inherit (texlive) - scheme-small - # Extra packages needed - changepage - enumitem - placeins - ; + scheme-small + # Extra packages needed + changepage + enumitem + placeins + ; }) ]; in { + checks = { + pre-commit = pre-commit-hooks.lib.${system}.run { + src = ./.; + + hooks = { + nixpkgs-fmt = { + enable = true; + }; + + markdown-lint = { + enable = true; + + name = "Lint each post's markdown"; + + entry = + let + pkg = pkgs.nodePackages.markdownlint-cli; + in + "${pkg}/bin/markdownlint"; + + types = [ "markdown" ]; + }; + }; + }; + }; + devShell = pkgs.mkShell { name = "report"; inherit buildInputs; + inherit (self.checks.${system}.pre-commit) shellHook; }; defaultPackage = pkgs.stdenvNoCC.mkDerivation { diff --git a/report.md b/report.md index 6fa3e74..dc2f958 100644 --- a/report.md +++ b/report.md @@ -327,6 +327,87 @@ Problematic: development of a benchmark framework # Illustrated analysis of acquired skills +## Working in a team and project management + +Delivering a product is the goal of working in a business. However the process +to get from zero to final product is unique to every company. + +During our project management classes, we were taught various ways of planning +a product from before the first line of code to its final delivery. The +prevailing culture in our industry in the last decade has been to adopt an agile +work environment: evolve the product and its product backlog alongside each +other, adapting to changing requirements. This is in sharp contrast to the +traditional way of planning projects, called *Waterfall*, where a specification +of behaviour is drawn upfront, and worked on for a long period of time with +little to no modification done to that project charter. + +We can say that IMC has embraced a more Agile way of delivering new features: +the products are continuously being worked on and improved, the work being +organized into a backlog of issues, partitioned into epics. And similarly, +the company culture embraces a few of the processes associated with Agile +programming. The one has most affected me is the daily stand up, a meeting +organized in the morning to interact with the rest of the team, summarising the +work that has been accomplished the day before, and what one wishes to work on +during the day. + +During the times of remote-work because of COVID, interactions with the team at +large feel more limited than they otherwise would be when working alongside one +another at the office. I have learned to communicate better with my colleagues: +explain what I am working on, reaching out to ask questions, and discussing +issues with them. + +## Working in a large code base + +IMC has a large body of code written to fulfil their business needs. It is rare +to work on a pre-existing code-base during the school curriculum. The few +projects that do provide you with a basis of code to complete them are at scales +that have nothing to do with what I had to get acclimated to at IMC. + +This has multiple ramifications, all linked to the amount of knowledge embedded +in the code. It is simply impossible to understand everything in depth, one +cannot hold the entirety of the logic that has been written in their head. + +Due to that difference, my way of writing software and squashing bugs had to +evolve, from an approach that worked on small programs to one that is more +scalable: I could not just dive into a problem head-first, trying to understand +everything that happens down to every detail, before being able to fix the +problem. The amount of minutia is too large, it would not be productive to try +to derive an understanding of the whole application before starting to work on +it. + +Instead I had to revise my approach, getting surface level understanding of the +broad strokes, thinking more carefully about the implications of an introduced +change, coming up with a theory and confirming it. + +This is only possible because of my prior experience on the large number of +projects I had to work on at EPITA, exposing me to a various subjects and +sharpening my inductive skills, building my intuition for picking out the +important pieces of a puzzle. + +## Debugging distributed systems + +My work specifically centers around running, interacting with, instrumenting, +and observing production binaries for use in testing or benchmarking. + +Due to this, and because nobody writes perfect code the first time, I have had +to inspect and debug various issues between my code and the software I was +running under it. That kind of scenario is difficult to inspect, make sense of, +and debug. The behaviour is distributed over multiple separate processes, each +of which carries its own state. + +In a way that is similar to our Distribute Algorithms final project, to tackle +those issues I had to think about the states of my processes carefully. I had to +reflect on the problem I encountered, trying to reverse-engineer what must have +gone wrong to get to that situation, and make further observations to further my +understanding of the issue. + +This iterative process of chipping away at the problem until the issue becomes +self-evident is inherent with working on such systems. One cannot just inspect +all the processes at once, and immediately derive what must have happened to +them. It feels more akin to detective work, with the usual suspect not being Mrs +Pink in the living room with the chandelier, but instead my own self having +forgotten to account for an edge case. + # Benefits of the internship ## Contributions to the company @@ -457,6 +538,25 @@ expect few places to be as well-rounded as IMC. # Appendix +## Vocabulary + +Bid and ask + +: Respectively the price for buying and selling a stock or other financial +instrument. The closer the spread of the two prices is, the more liquidity there +is in the market for that product. + +Continuous Integration + +: The practice of automating the integration of code from multiple contributors +into a single software project. + +Market-making + +: A market-maker provides liquidity to the market by continuously quoting both +sell and trade prices on the market, hoping to make a profit on the *bid-ask +spread*. + ## About IMC International Marketmakers Combinations (IMC) was founded in 1989 in Amsterdam,