update

proprog.md

@@ -15,37 +15,43 @@ NOTE: We're interested in the 'HOW' and the 'WHY/WHY NOT' in the report.
 ### 1.1 Strengths and weaknesses of Rust
 
 #### 1.1.1 Strengths
-- Catches errors at compile-time:
+- **Catches errors at compile-time**:
 		* Type errors
 		* Memory leak errors
 		* Index out-of bounds errors
 		* Null pointer errors
-		* Which is good because catching errors as early as possible saves development time, and increases iteration speed. A bug found at run-time is considered 10x more costly to fix, than a bug at compile-time.
-- Fast - Fast because Rust enables low-level programming. Does not have a JIT. Is compiled instead of interpreted. 
-- Modern language - Language made to run on modern hardware, with modern language features. A new generation of programmers expects modern features from a language. Rust makes it easier to convince young programmers to get started with low-level programming.
-- Young community -  A new generation of programmers are developing Rust. Also good innovation, and longevity.
-- Endorsed by industry - Linux, Mozilla, Microsoft. This is a strength because it ensures that Rust will be supported with money, resources, people for the forseeable future. 
-- Strong documentation - I am thinking about you Rust Book - https://doc.rust-lang.org/book/
+		* Which is good because catching errors as early as possible saves development time, and increases iteration speed. A bug found at run-time is considered 10x more costly to fix, than a bug at compile-time. (@TODO Add reference)
+- **Fast** - Fast because Rust enables low-level programming. Does not have a JIT. Is compiled instead of interpreted. 
+- **Modern language** - Language made to run on modern hardware, with modern language features. A new generation of programmers expects modern features from a language. Rust makes it easier to convince young programmers to get started with low-level programming.
+- **Young community** -  A new generation of programmers are developing Rust. Also good innovation, and longevity.
+- **Endorsed by industry**:
+	-  Linux has been talking lately about allowing contributions to the Linux kernel in Rust. This is a huge breakthrough for Rust, since the Linux kernel has been quite conservative in regards to supporting languages, and only supported C up until this point. (@TODO Add reference)
+	-  Mozilla - In 2017 made a bold decision to rewrite it's entire browser-engine in Rust. The engine was previously written in C++, but Firefox thought it was worth scrapping it's C++ codebase in favor of Rust due to some reasons: (@TODO add reasons) (@TODO add reference)
+- **Strong documentation** - If you are learning Rust, just reading the entire Rust Book helped me a lot. See: https://doc.rust-lang.org/book/
 
 
 #### 1.1.2 Weaknesses
-- Slow compilation time. 3-4 seconds for debug-build, on a 1000 LOC project. This is a weakness because it slows down iteration-speed.
-- Verbose syntax - If a developer is used to a higher-level interpreted language the Rust syntax may be annyoingly verbose. This may scare developers away from Rust.
-
+- **Slow compilation time**. 3-4 seconds for debug-build, on a 1000 LOC project. This is a weakness because it slows down iteration-speed.
+- **Verbose syntax** - If a developer is used to a higher-level interpreted language the Rust syntax may be annyoingly verbose. This may scare developers away from Rust. (@TODO Add example of verbose syntax to do simple thing)
+- **Steep learning curve** - At least from my own experience, getting into Rust was like getting hit by a brick wall. The amount of new concepts that was thrown against me, not seen before in any other language I had ventured into, was freightening at first. Borrowing, explicit mutability, etc. Nonetheless I soldiered on, knowing that most of these new concepts actually was a strength of Rust, and not some idiosyncratic bullshit withouth any benefit, some languages make you learn.
 
 ### 1.2 How we controlled process and communication systems during development
  
- - Discord
- - Google hangouts
- - MSTeams
- - Issues
- - Email
+ - **Discord** - Most live discussion was conducted in Decentralized Identity Norden (DIN) Discord server. 
+ - **Slack** - DIN also had a Slack-server, but this was never utiliized throughout the project period. DIF on the other hand, did most of their discussions through their Slack server.
+ - **Google hangouts** - The weekly domain-experts video-meeting was conducted using Google Hangouts.
+ - **MSTeams** - The weekly academic supervisor meeting was conducted in an MSTeams group.
+ - **Github Issues** - When discussions gets complicated and/or lasts for an extended  period of time, there was a need to create a dedicated Github issue, to keep track of everything. Creating a dedicated issue for every type discussion, would be the ideal situation, but tend to not be practical. There is an overhead of creating and maintaining an issue. The end results is that most issues are resolved directly through verbal conversation or through Discord, or any other kind of live chat/meeting.
+ - **Email** - Before getting into DIFs Slack-channel, there was a need to get in touch with some of the DIF-guys to ask questions about which direction the project should go in. We wanted to avoid doing uninteresting things. Snorre, which was the projects product manager, had some contact information to reach these key-industry-experts via email. The conversation always started with Snorre sending an email to one of these experts, with me (Jonas) as a CC-recipient, introducing me.
+ 
 
 ### 1.3 Use of version control systems, ticket tracking, branching, tagging/versioning
 
-- Git version control
-- Github Issue tracking and Project Board
-- Github Branching
+- **Git version control** - Git has become the de-factor choice for version-control. Not much more to say about that.
+- **Github Issue tracking and Project Board** - The project Board was the centerpiece of the issue-tracking. Creating low-overhead tickets was done for most tasks. These tickets do not have an actual Github-issue attached to them. Tasks that required a bit more discussion and involvement from more people got it's own Github issues. (@TODO Add screenshot of Github Board)
+- **Github Branching** - As only one developer was working on this project, throughout the entire period, most issues were resolved directly on the main branch. The few times a separate branch was created, was when bigger milestones were implemented - Example: When DID CLI was first conceived, it was being worked on on a separate branch for quite a while. Also there were alot of `playground/<miniproject>` branches in the beginning, for experimentation with different SSI-technologies. It was good to keep the experimentation in a separate branch. Because this made it easy to kill experiments, if they turned out to be a dead end.
+
+
 
 ### 1.4 Programming style guide including how to comment code
 
@@ -58,18 +64,19 @@ NOTE: We're interested in the 'HOW' and the 'WHY/WHY NOT' in the report.
  One of the goals of the project, was to re-use as much as possible of existing code. This was the main reason Rust was chosen in the first place. The SSI community are already heavily invested into Rust, for many of the same reasons mentioned in section 1.1.1.
  
  
- ### 1.6 Professionalism in your approach to software development
- 
- - Lean development - Work on as few tickets at the same time as possible.
- - Remove dead code - Clean up code that is no longer use. Do not write code that is not in use from day 1.
-
-### 1.7 Use of code review
+### 1.6 Use of code review
 
 - Pull Requests in Github is at the center of the code review process. Ideally there should be one pull request attached to every branch. 
 - When the pull request has received a code review, it could either be approved or receive a change-request.
 - Once code review is approved, the pull request is merged, closed, the branch gets deleted, and the attached issue-ticket gets a status change from "In-review" to "Done" 
 
 
+
+ ### 1.7 Professionalism in your approach to software development
+ 
+- Lean development - Work on as few tickets at the same time as possible.
+- Limit scope - Doing less than planned is better (cheaper) than doing more (expensiver) than what you planned. This is not limited to software development as this principle can be applied to engineering in general.
+
 ## 2 Individual discussion
  
 ### 2.1 A link to, and discussion of, code you consider good
@@ -81,3 +88,6 @@ NOTE: We're interested in the 'HOW' and the 'WHY/WHY NOT' in the report.
 This will include a discussion of why the code was refactored
  
 ### 2.4 Personal reflection about professionalism in programming
+
+ - Remove dead code - Clean up code that is no longer use. Do not write code that is not in use from day 1
+ - Write requirements -> Then write tests -> Then write code