DEV Community: amabe_dev

How to Make Pull Requests Easier

amabe_dev — Mon, 09 Jan 2023 19:24:36 +0000

Pull Requests are a powerful tool for code review and knowledge sharing.

And, as developers, reviewing Pull Requests represent a big amount of time every week.

We will talk about "Pull Requests" in this article. But you can read it as "Merge Request" or whatever term you are used to. These ideas are not directly linked to any tooling.

But we might not want to do Pull Request

Some really knowledgeable people advise against doing Pull Requests inside a team. So, here are some reasons why we might not want to do Pull Requests:

They introduce a blocking step in the dev process. And this step might take time.
We do not often catch problems during these reviews.
And when we find something to say, the feedback comes really late, and it might be too late to make changes.

We can do pair or mob programming to keep the benefits of Pull Requests without their drawbacks. Pair or mob programming put the discussion and feedback during the development of a feature instead of when it is already done. This makes for a better design and implementation on the first time.

By doing so, there should be nothing to say once the feature is done. And the team can go to another feature directly because there is no longer the need for this blocking Pull Request step in the process.

But leaving Pull Requests or doing pair programming might not be an option. So we better know how to do effective Pull Requests. And here are thoughts to try to make them easier.

Pull Requests as a team

Pull requests do not have much sense outside a team because nobody would be able to review our changes. So it starts by asking ourselves why we use this tool inside our team.

Define what you expect from Pull Request

It is not enough to create a branch, doing multiple things on it, create a Pull Request and wait while spamming our teammates from time to time so they don't forget to review it.

Well. In fact, it can be enough. And it is sometimes what is done in teams. But it is definitively not the best experience for anyone.

Instead, everybody on the team should be aligned on how to handle the Pull Requests. This means answering questions like:

When should Pull Requests be used? Are they required for any new development? Or are they only for new features? What about documentation, styles or build changes?
Are they used for everyone or only for contributions from people outside the team?
What are their goal? Is it to share knowledge between team members? Is it just a tool for code review? Is it okay to suggest big changes or start discussions on a Pull Request?
Are Pull Request a way to transfer the ownership from the author to the whole team? Meaning that, once merged, every member of the team is as responsible for the code as the original author.
When are they reviewed? Each day? Each Friday? Each March 2nd?
Who can validate a Pull Request? Can every developer give his approval or only senior developers?
And how the reviewers know that they should review the Pull Request? Are they mentioned on it? Do they watch for a given label? Does the Pull Request link need to be sent in a channel in team's chat?
When can we consider a Pull Request approved? Does it need to be approved by only one person? Or do multiple developers need to approve it before merging.
And how to know that someone approved the Pull Request? Does the person approve it by using an "Approve" feature of the tool? By adding an emoji? (If so, which emoji?) Or by leaving a comment that says "all good for me"?
Who resolve the comments on the Pull Request? Is it the author of the Pull Request or the author of the comment? Or is it the author of the comment if he has not yet approved it and the author of the Pull Request otherwise?

Making sure that everybody in the team is aligned with why we do Pull Requests is important. Otherwise, it could be the cause of conflicts between team members that have different expectations.

Automate everything you can

A review by a peer takes time and is often quite exhausting for the reviewer.

To make it easier on the reviewers, everything that can be automated should be automated.

This includes, if possible:

Running the tests automatically, so the reviewers don't have to do it manually.
Running code formatters to have consistent formatting everywhere and not letting the formatting be a distraction.
Running linters and code quality tools for common problems and team conventions to avoid manual checking.

Automating everything that can be lets the reviewers focus on what is important. They are free from checking every whitespace and variable declaration and can focus on the big picture.

Another benefit is that the automation gives feedback earlier. The earlier the feedback, the better. Ideally we should even be able to run these automated checks locally to have the feedback during the development.

And when automated, there are way less comments to handle. The fewer comments there are, the easier it is for everyone. The author doesn't have to handle them. And the reviewers don't have to come and check later to see if they are resolved.

Find what works for you

There is no single solution that work for every team. Pull Requests are easier when everyone is aligned on why we do Pull Requests and there is automated feedback. But we still need to review the Pull Requests.

To make the review process easier, the team may choose to use its own conventions. Here are some ideas:

Everybody can add an emoji while reviewing to communicate that he's still doing the review. This can help avoid getting comments after the Pull Request is merged. And it helps to avoid spamming someone for a review if he is already reviewing the Pull Request.
A tool that can be useful is the use of conventional comments. This helps to give context about the comment, its intent and what is expected. It can make it easier for everyone to know what is needed. (More on that later.)

Let's now move on into the life of a Pull Request. And its starts by the author creating the Pull Request for review.

As the author

As the author of the Pull Request, we are proposing changes to our team. It is often expected that we will make the changes necessary until the Pull Request is merged.

Remember that it is the code that is reviewed

Comments on the Pull Request are comments about the code we produced and the solution we thought of. It is easy to take them personally.

But we shouldn't. One of the most important thing we can do is to remember that the comments are about the code and not about ourselves. We should put our ego aside to discuss the choices we made and search for the best solution.

It's possible that we made bad choices. There are a lot of good reasons to be wrong, including not being aware of some information, or just making mistakes. Or our solution can be a good solution but not the best possible. We should try our best to stay open to find better solutions instead of defending what we did first.

This does not mean that the reviewers are always right. Sometimes we already thought about or tried what is suggested and rejected the solution. We should explain why we chose the solution if it's relevant. We just shouldn't hold to a bad solution just because of our ego.

Break changes down

Big Pull Requests are exhausting both for us and for the reviewers. And the reviewers will not be able to do a good review if the Pull Request is too long.

To make Pull Requests easier, we should try to make them as small as possible. This means splitting big tasks in smaller tasks and doing one Pull Request for each.

If the task is big and multiple Pull Requests are necessary, it may take time to continue. To address this problem, we can stack Pull Requests. (The first points to the branch we want to merge on. The second point on the branch of the first. And we will merge the first before merging the second.)

Smaller Pull Requests make it possible for the reviewers to focus on what changed, leading to better feedback. And since they are faster to review and result in less comments, they are usually merged faster. And, since smaller Pull Requests are less of a chore, this can help team members to review them more frequently.

Explain what the change is intended to do

To make it easier for reviewers, we should explain what the changes are intended to do. It can be as easy as giving the context that made the change necessary.

Since we try to make small Pull Request, the changes should only focus on one behavior change. That makes them easier to explain.

The reviewers were most likely working on other subjects. Giving them the context of the change is a gift we give to them. This information makes the switch of context easier for them.

If the change is linked to an issue, it is interesting to put a link to that issue in the description. It gives an easy way for reviewers to get more context if they need. (For what it's worth, you might also want to put it in the commit. It can help a lot to find why something was done when debugging in the future.)

And we can add comments on our Pull Request if there are some changes where we think more context is needed. (In this case it makes sense to ask ourselves if the best place is a comment on the Pull Request or a comment in the code.)

Be your first reviewer

Reviewing our Pull Request ourselves can help catch errors, forgotten TODOs or bad structure. And finding these ourselves saves times for everyone by avoiding back and forth comments.

Reviewing our code is easier that reviewing a Pull Request from someone else because we already have the context and the big picture view of what is done. There is no good reason not to do it. (Except that we might have already done it before typing "git commit" two minutes ago.)

And it is an opportunity to add comments to explain a choice we made for the reviewers. Or even to ask for thoughts about a piece of code we are unsure of.

Then we just have to wait for the reviewers to review our newly created Pull Request and answer them or apply their suggestions.

As a reviewer

This is the hardest role in the Pull Request process. It requires us to switch context and understand what someone else did. But it is the whole point of the Pull Requests. They would serve no purpose without reviewers.

Remember that it is the code that is reviewed

The authors should remember that it is their code that is reviewed and that the comments are not about themselves. But for that to work, we have to ensure that the comments are about the code and not the authors when writing them.

We should always be discussing solutions and how to make the code better. And there should never have comments on the author. If we find ourselves using "you" in a comment, we should take time to think again if this is really what we are wanting to write. Pull Requests are usually not fun. Let's try to not make them harder than necessary for anyone.

If you see something that seem strange, it is better to ask for details about the choice. And more often than not we should not suggest that something is wrong without all the context necessary. There are chances that the authors thought about it and made a decision based on information we do not have. So prefer asking for details instead of pointing something as wrong.

Share your thoughts

Pull Requests are a communication tool. This is not an evaluation of the code someone else produced. We can do more than just saying what could be better.

It can be asking questions to better understand a choice or why the change was necessary. After all, once the Pull Request is merged, we will likely have to maintain this code. It is a good moment to go get information to understand it.

It can also be thoughts of potential issues we think of when reviewing the code. Maybe the changes may have impacts that the authors did not think about that would be interesting to check. If so, tell them. It will be easier to check it and make changes when the Pull Request is still being reviewed.

And it can even be unrelated thoughts. For example, sharing a pattern that we think might be appropriate but do not make the code a lot better. It can help to gather opinions or start a discussion to finish elsewhere later.

Be clear about what you expect

We put comments on Pull Requests for different reasons. We should be clear about the intent behind every comment so the author and other reviewers know what we are expecting.

The context of a comment includes: if it is blocking the Pull Request, whether it is a question, a thought or an issue, etc.

Conventional comments are a great tool for this. It consists of prefixing the comment with context. For example:

prefixing with "question:" if we are asking for more details
prefixing with "thought:" if we are sharing a thought and not making a suggestion
prefixing with "suggestion:" if we are suggesting changes
prefixing with "nitpick:" if what is done works, but we found something to nitpick about
adding "(blocking)" or "(non-blocking)" to add context about if it has to be taken into account if the author wants our approval

See the Conventional Comments' website for more details. And, even if they thought of a lot of cases, we can add our own keywords if we need to. Or even take inspiration from it and do it our way with different keywords. Or with emojis.

Let the author know of what is done well

Last, it is nice to the authors know if we find something that is well done.

It can be hard to receive only feedback on what to change. Getting feedback on what is good can help the authors feel better about the review and his skills. Especially if the author is new in the team, a junior or lacks confidence.

The review is not a punishment, we should try to make it easier for everyone.

Conclusion

There are tips that I think can help make Pull Requests easier for everyone in a team.

These are my current opinions about Pull Requests. It may change in the future, it surely did since I started doing them. And I will try to keep this article updated if I change my mind.

I hope it can help you to make better Pull Requests. And, if you think of things that are missing, please reach out. I would be grateful for the feedback and would love to try new ideas.

Interesting resources

amabe_dev — Sat, 19 Nov 2022 15:50:31 +0000

This post is intended as an entry point to resources I find interesting.

These were in my Twitter bookmarks. But it does not seem the best place to keep these resources anymore.

General
Architecture
Testing
Tooling
Design
Management
Misc

General

Clean Code rules summary with JavaScript examples:
https://github.com/ryanmcdermott/clean-code-javascript
Programming principles summary: https://github.com/webpro/programming-principles

Architecture

Using an hexagonal architecture to limit coupling of the business logic with the framework: https://dev.to/drouianm/hexagonal-architecture-as-a-solution-to-the-obsolescence-of-ui-frameworks-ej2
Guide for JavaScript library build: https://github.com/frehner/modern-guide-to-packaging-js-library
Thoughts about microservices vs monolith: https://dev.to/semaphore/when-microservices-are-a-bad-idea-2p7h %}

Testing

Testing best practices (for JavaScript app): https://github.com/goldbergyoni/javascript-testing-best-practices

Tooling

A great articles about using the devtools: https://dev.to/lissy93/awesome-dev-tool-tips-32oo

Design

Checklist for interface design: https://www.smashingmagazine.com/2022/09/ux-checklists-for-interface-designers/

Management

A framework for evaluation: https://github.com/jorgef/engineeringladders

Misc

Privacy and security focused softwares: https://github.com/lissy93/awesome-privacy
Personal security best practices: https://security-list.js.org/#/
Article about knowledge sharing in teams: https://leaddev.com/communication-relationships/want-promote-knowledge-sharing-your-teams-standardize-way-you-take
Tips to promote knowledge sharing: https://dev.to/codingchili/tips-for-boosting-knowledge-sharing-1f93

How do you promote knowledge sharing?

amabe_dev — Thu, 06 Oct 2022 17:28:51 +0000

Knowledge sharing seem to be a hard challenge.

So, here is the question: How do you promote knowledge sharing inside your team and/or organization?

Please share your awesome tips and resources to go deeper on the subject!

Unit testing AngularJS components with ng-model

amabe_dev — Wed, 31 Aug 2022 18:10:22 +0000

I wanted to test a component using the UI elements to avoid testing to much implementation details.

When doing that, I faced was faced with an input and did not find easily how to trigger its change events to trigger the ng-model change and the ng-change event.

Here is how I did it. (This come late given that AngularJS is deprecated. But I guess I will not be the only one lucky enough to still work with it sometime.)

The test base

For these tests, we will use the angular-mocks library.

We will use le $compile to instanciate the component. And then interact with the component by using the compiled elements.

We will compile the input directly to make the tests easier. We could compile a component that have inputs and retrieve them by calling the JQuery .find(<selector>) on the compiled element.

We will use the Jest syntax for the test declaration and assertions.

require('angular');
require('angular-mocks');

describe('test', () => {
  let $rootScope;
  let $compile;
  let $timeout;

  beforeEach(inject((_$rootScope_, _$compile_, _$timeout_) => {
    $rootScope = _$rootScope_;
    $compile = _$compile_;
    $timeout = _$timeout_;
  }));

  // ...
});

Simple ng-model test

In this test, we will use a simple input without ng-model-options.

To update the ng-model update and ng-change update we will use the following JQuery operations:
- .val(<value>) to update the value
- .triggerHandler('change') to send the change event of the input

it('Should trigger change ng-model value and trigger ng-change', () => {
  const scope = $rootScope.$new();
  scope.value = '';
  scope.onChange = jest.fn();

  const element = $compile('<input ng-model="value" ng-change="onChange()">')(scope);
  scope.$digest();

  element.val('test').triggerHandler('change');

  expect(scope.value).toBe('test');
  expect(scope.onChange).toHaveBeenCalled();
});

ng-model with update on blur

In this test, we will use a simple input with ng-model-options to update only when the input blur event is triggered.

The blur event is triggered when the field looses focus.

This may be used to avoid updating every time the value changes if we know that we will only use the value when the input will be filled.

it('Should trigger change ng-model value and trigger ng-change (update on blur)', () => {
  const scope = $rootScope.$new();
  scope.value = '';
  scope.onChange = jest.fn();

  const element = $compile('<input ng-model="value" ng-model-options="{ updateOn: \'blur\' }" ng-change="onChange()">')(scope);
  scope.$digest();

  element.val('test').triggerHandler('change').triggerHandler('blur');

  expect(scope.value).toBe('test');
  expect(scope.onChange).toHaveBeenCalled();
});

ng-model with debounce

In this test, we will use a simple input without ng-model-options.

The debounce option can be used to update the value only when the if it does not change for a given time.

This make it possible to keep up to date even if the input does not loose focus while avoiding getting too much events.

It can be useful for elements like search inputs where we want to show suggestions while the user types. But we do not want to do the computation on every change because it can be quite heavy.

Then we will use $timeout.flush() for the code to act like if the debounce time has passed.

it('Should trigger change ng-model value and trigger ng-change (debounce)', () => {
  const scope = $rootScope.$new();
  scope.value = '';
  scope.onChange = jest.fn();

  const element = $compile('<input ng-model="value" ng-model-options="{ debounce: 200 }" ng-change="onChange()">')(scope);
  scope.$digest();

  element.val('test').triggerHandler('change');
  $timeout.flush();

  expect(scope.value).toBe('test');
  expect(scope.onChange).toHaveBeenCalled();
});

Interesting Things in Tech lately (2022 week 33)

amabe_dev — Mon, 22 Aug 2022 16:28:00 +0000

It takes quite a lot of time to keep updated on what is happening in the tech world. So I thought it would be interesting to share what we found interesting.

Here is what I found interesting last week. If you have found interesting things that I didn't put here, please add them in the comments, it will help to share the efforts.

Big changes for Deno

Deno will make it easier to work with NPM packages. It will be possible to import them like this: import express from "npm:express@5";.

And they have the goal to make it the fastest of JavaScript runtimes.

Big Changes Ahead for Deno

Learnings from our recent survey and feedback from across our community. We'll discuss how we're addressing this feedback and the features to expect from Deno in the coming months.

deno.com

The job interview process for senior roles

A very complete article on the interview process for senior engineer roles.

How to get the best job offer for senior+ software engineer roles

Erry Kostala ・ Aug 15 '22

#interview #programming #career #jobs

Thoughts about the tech lead role

An interesting thread to read on the teach lead role.

(TL;DR: Be there to improve the team as a whole, not just have badass skills.)

// Detect dark theme var iframe = document.getElementById('tweet-1559213234992947202-528'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1559213234992947202&theme=dark" }

Tips for giving feedback

Very nice thoughts about giving feedback.

Remember to also include feedback on what we like and not only negative feedback.

And remember that the person might also receive feedback from others.

Giving Good Feedback: Consider the Ratio – charity.wtf

Consider the ratio. You work with someone great. If someone asked, you’d say they are brilliant, inspired and dedicated. They care deeply about their work, they are timely and reliable (for the mos…

charity.wtf

Thoughts about taking notes as a team

Nice thoughts about taking notes as a team to share knowledge.

Taking (good) notes as a person is a very powerful tool. Taking them as a team may be even more powerful. (If people in the team are interested in taking notes this way.)

Want to promote knowledge-sharing in your teams? Standardize the way you take notes. | LeadDev

How to manage and document the collective knowledge across your teams

leaddev.com

Good (quick) Resources to Become a Better Developer

amabe_dev — Mon, 15 Aug 2022 15:18:00 +0000

In this article I will share some resources that I find great to become a better developer.

There will be no books or other time consuming resources in this article. I will only include resources that are relatively quick to consume.

If you can think of other good resources that are not included here, feel free to share them in the comments. I am always looking for good resources and would love to see them.

Clean Code

clean-code-javascript by Ryan McDermott

clean-code-javascript, by Ryan McDermott, is a GitHub repository. It shows examples of the Clean Code principles of Uncle Bob written in JavaScript.

It is a sort of overview of what is in the book. It is a really good read for people that are not familiar with the book or who want a refresher.

Programming Principles

Programming Principles by Lars Kappert

Programming Principles, by Lars Kappert, is a GitHub repository. It lists programming principles with a brief description and links to dig deeper.

It is a good introduction to programming principles. Or a good refresher for those who already know about them.

patterns.dev website

patterns.dev website lists design patterns for the web. It is both a free book and a set pages by design pattern on the website.

It also includes links to other resources, like the clean-code-javascript above.

It is a good place filled with interesting resources.

Testing Best Practices

JavaScript Testing Best Practices by Yoni Goldberg

JavaScript Testing Best Practices, by Yoni Goldberg is a GitHub repository. It gives good practices about testing.

I would recommend it for everyone because it is really complete. There are good chances that everyone will either learn or remember some good practices while reading it.

Interesting Things in Tech (2022w32)

amabe_dev — Mon, 15 Aug 2022 12:25:40 +0000

It takes quite a lot of time to keep updated on what is happening in the tech world. So I thought it would be interesting to share what we found interesting.

Here is what I found interesting last week. If you have found interesting things that I didn't put here, please add them in the comments, it will help to share the efforts.

A reflection on SOLID principle

Martin Fowler said it all in this tweet. It is an interesting read with openings to other principles.

// Detect dark theme var iframe = document.getElementById('tweet-1558085694127489025-414'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1558085694127489025&theme=dark" }

Checklists for accessibility

These checklists are quite simple but have a lot of value to make sure that we looked at everything.

// Detect dark theme var iframe = document.getElementById('tweet-1557704990822731779-589'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1557704990822731779&theme=dark" }

Using native modals

A nice article from @dailydevtips1 about using native modals. There seems that we have no need for modal plugins anymore. It even takes care about the accessibility issues with focus.

Trying out native dialog modals

Chris Bongers ・ Aug 8 '22

#html #webdev

The changes on GitLab free plan

Last week they announced that inactive projects will be archived. They will still be accessible but it will take longer to access.

They will also apply a storage limit on free namespaces: https://docs.gitlab.com/ee/user/usage_quotas.html#namespace-storage-limit-enforcement-schedule

And here are thoughts about these changes and the reaction we see. The complaints come from the user perspective to whom we remove things they could use for free before. This gives a wider perspective:

// Detect dark theme var iframe = document.getElementById('tweet-1558172218751963136-729'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1558172218751963136&theme=dark" }

NPM and security

A big problem with NPM is that we have to download the packages to see their code. There is often a link to a GitHub repository but we cannot be sure that it is the same code.

NPM has opened a RFC to address this problem.

// Detect dark theme var iframe = document.getElementById('tweet-1556706813944504320-766'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1556706813944504320&theme=dark" }

The impact of translations on the design

Interesting thoughts about the impact of translations on the design.

// Detect dark theme var iframe = document.getElementById('tweet-1556531974604455937-973'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1556531974604455937&theme=dark" }

Teasing on Preact performance

Jason Miller continues teasing about his latests achievements while trying to make Preact more performant.

It will be a new library to replace hooks with a similar interface. More details in these threads:

// Detect dark theme var iframe = document.getElementById('tweet-1549001036802625536-221'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1549001036802625536&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1557163907340443648-280'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1557163907340443648&theme=dark" }

Astro 1.0

Astro has reached the 1.0. It is a framework for optimization worth checking out.

// Detect dark theme var iframe = document.getElementById('tweet-1557049466401632256-50'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1557049466401632256&theme=dark" }

What you learn when hacking your car

An interesting article about the steps it takes to hack a car and the findings he did: https://programmingwithstyle.com/posts/howihackedmycar/

// Detect dark theme var iframe = document.getElementById('tweet-1558309810801631233-996'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1558309810801631233&theme=dark" }

A benchmark on Bun

Another interesting benchmark on Bun by @tomfern.

TL;DR: It is not yet fully compatible with Node.js API but it is faster on the things tested.

I am still curious to see if it faster than Node.js on more complex programs. v8 has a lot of optimizations that JavaScriptCore (base of WebKit) might not have.

A First Look at Bun: Will It Take Node’s Crown?

Tomas Fernandez for Semaphore ・ Aug 12 '22

#javascript #node #deno #typescript

Experienced developers struggle as well

An article by @jkettmann that I found interesting, reminding that everyone struggles at times. I think the conclusion has good advice for new developers.

It makes a good point on pair-programming for onboarding new developers. It makes them see experienced developers struggle and it may help to ease the impostor syndrome. (On top of all other advantages of pair-programming.)

Experienced Programmers Struggle As Well: Ease Your Imposter Syndrome As A Junior Developer

Johannes Kettmann for Profy.dev ・ Aug 12 '22

#react #javascript #frontend #webdev

Interesting Things in Tech (2022w31)

amabe_dev — Mon, 08 Aug 2022 09:48:00 +0000

It takes quite a lot of time to watch what is happening in the tech sphere. So I thought it would be interesting to share what we found interesting.

Here is what I found interesting last week. If you have found interesting things that I didn't put here, please add them in the comments.

1. Funny

Think about this next time you do infinite scrolling:

// Detect dark theme var iframe = document.getElementById('tweet-1554130332420476929-574'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1554130332420476929&theme=dark" }

2. Articles

2.1. Tips for creating buttons

// Detect dark theme var iframe = document.getElementById('tweet-1554443986974253057-370'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1554443986974253057&theme=dark" }

2.2. Thoughts on microservices and monoliths

An interesting read about why starting directly with microservices may not be a good idea.

When Microservices Are a Bad Idea

Tomas Fernandez for Semaphore ・ Aug 1 '22

#microservices #devops #opinion #programming

3. Security

3.1. A reminder to take care about our credentials when coding

// Detect dark theme var iframe = document.getElementById('tweet-1554108071492079616-598'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1554108071492079616&theme=dark" }

4. Dev tooling

4.1. GitLab will archive inactive repositories

GitLab will archive inactive making them slower to access. It made a lot of noise earlier when they announced they would be deleted.

// Detect dark theme var iframe = document.getElementById('tweet-1555325376687226883-620'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1555325376687226883&theme=dark" }

And a discussion thread here:

(The title has not been update yet to reflect the change that projects will not be deleted but archived.)

GitLab will be deleting dormant projects

Ben Halpern ・ Aug 4 '22

#news #discuss #gitlab #cloud

4.2. A new version of VSCode is here

// Detect dark theme var iframe = document.getElementById('tweet-1555252452722675712-807'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1555252452722675712&theme=dark" }

And it has a new interesting experimental feature:

(The title has not been updated to reflect the change yet.)

// Detect dark theme var iframe = document.getElementById('tweet-1555466217774882818-898'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1555466217774882818&theme=dark" }

4.3. StackBlitz announced collections

// Detect dark theme var iframe = document.getElementById('tweet-1555238114574082048-735'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1555238114574082048&theme=dark" }

It may become a good place to find tips, like with this collection.

5. Misc

5.1. A framework for engineering managers

An interesting read even for people who are not managers.

I found it interesting to see where I think I am on this graph and what I can do to do better. And there is example graphs for different roles.

// Detect dark theme var iframe = document.getElementById('tweet-1553019018298138625-89'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1553019018298138625&theme=dark" }

5.2. A survey about CSS nesting

// Detect dark theme var iframe = document.getElementById('tweet-1552034604550279168-717'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1552034604550279168&theme=dark" }

How to run GUI apps in LXD containers

amabe_dev — Thu, 04 Aug 2022 13:42:43 +0000

I recently tried to run GUI apps in LXD containers and had a hard time doing it. Here is the solution I found and the problems I encountered.

We will assume a basic knowledge of LXD. It is possible to follow this article with a very limited knowledge of it. But we will not start from scratch by explaining what it is and how to use it.

I will explain how I did it on a Ubuntu host, by using the host Xorg socket in containers that use the ubuntu:22.04 image.

Why use GUI apps in a LXD container

Before doing anything, we should probably discuss why we may want to do that. Here is why I did it:

Running apps in a container is more secure. They still have access to other windows because we use the host Xorg socket. But they run in a separated filesystem and have only access to what we give them.
It is easier to make backup by using the snapshots and backups features provided by LXD.
We can use them for temporary tests without polluting the host machine. And then delete them as if they had never been there.

My main goal was testing applications I don't fully trust while staying the most secure I can. And I then found that it is really nice to have the ability to make snapshots and clone containers, especially for dev environments.

A way to run GUI apps in a LXD container

Here begins the journey!

1. Creating a profile and forwarding the Xorg socket

First we need to forward the host Xorg socket. It will allow the container to display GUI without having to install its own window system.

To make it easier, we can create a profile. We will then be able to start multiple containers without having to write everything again.

To create a profile, run:

lxc profile create <profile name>

And edit it to add the following config:

config:
  environment.DISPLAY: :0
description: ""
devices:
  X0:
    bind: container
    connect: unix:/tmp/.X11-unix/X1
    listen: unix:/mnt/X0
    security.gid: "1000"
    security.uid: "1000"
    type: proxy
name: <profile name>

What it does is:

set the DISPLAY environment variable with the value :0 (used to know which socket to use)
proxy the host Xorg socket located at /tmp/.X11-unix/X1 to the container at /mnt/X0 (you might need to replace the X1 by something else)

Warning: We do not want to proxy the socket to /tmp/.X11-unix/X0 in the container. Otherwise it will be deleted on reboot because it is located on the /tmp folder. See below how to do it.

2. Starting a container

Now that we have our profile, we are able to create new containers with it.

To start a new container, run:

lxc launch --profile default --profile <profile name> <image> <container name>

Here we are using the official ubuntu:22.04 image, so run:

lxc launch --profile default --profile <profile name> ubuntu:22.04 <container name>

And we can then enter the container by running:

lxc exec <container name> -- bash

And here is our dear terminal where we can do almost anything!

3. Creating a symlink for the Xorg socket

We created a proxy for the host Xorg socket. But it is located at /mnt/X0. Not in /tmp/.X11-unix/X0 were it needs to be.

We did that to avoid the socket being deleted when the system starts. Because the /tmp would be emptied on boot.

To make it work, we are going to create a symlink from /mnt/X0 to /tmp/.X11-unix/X0 by running the following command:

ln -s /mnt/X0 /tmp/.X11-unix/X0

Now we can use GUI apps inside our container. But it is not really user friendly.

4. Make the symlink automatic on startup

Until now, we are able to use GUI apps in out container. But we have to create the symlink manually everytime we start the container. We will make it automatic to avoid this pain.

To do that we can use multiple solutions. Here, we will use CRON jobs.

Run:

crontab -e

And add this in the editor:

@reboot ln -s /mnt/X0 /tmp/.X11-unix/X0

If we want to be able to run GUI apps from other users, we can also change the socket permissions by adding this CRON job:

@reboot chmod a+wx /tmp/.X11-unix/X0

And now we can restart our container as much as we cant without having anything manual to do anymore!

5. Install GUI apps and run them

This step is just the fun part!

Just install any GUI app in your container and start it. Everything should work as a charm. (If you are as lucky as me.)

Conclusion

Running GUI apps in LXD containers is not that simple. And some guides that we can find on the Internet even make it harder by guiding us in the wrong direction.

The main challenges I found were not documented enough were:

The need to proxy the Xorg socket to anywhere else than the /tmp folder. Otherwise it would work. But only before we restart the container.
Setting the permissions on the socket to allow other users to run GUI apps. Because even in containers we may not want to use them as root. And Electron apps do not like to be run as root.

I hope this article helped. (And "Hi!" to my future self 😁️)

Feedback and tips are more than welcome, don't hesitate to reach out!

Why we use layered architectures

amabe_dev — Mon, 25 Jul 2022 16:45:00 +0000

I recently looked for articles that I could forward to explain why we use often choose a layered architecture when creating a new service.

And I found none. The articles I found either did not try to explain the why or, in my opinion, missed the point by just stating that "this is easy". So, here is my attempt to explain the why of the layered architecture.

Disclaimer: I am not an architect. This is only my understanding as a software developer. If you see anything wrong or missing, please reach out, I will happily update the article (and my knowledge).

What is a layered architecture

A layered architecture is a way to design a service by dividing its logic in layers. Each layer is only allowed to call the layer directly below.

We usually use these 3 layers:

The API/UI layer: exposes the API or the UI and is responsible for authentication and requests handling.
The business logic layer: everything that is business logic, data validation and processing.
The data access layer: responsible for the interactions with the database.

It is usually represented like this:

Why we are using a layered architecture

There are many reasons why we may want to use a layered architecture. Even the reason "because I was told to" is valid.

The following reasons are the reasons that I think have the most valuable impact.

It tends to remove surprises

The layers separation forces us to separate the logic in a given way. One of the consequences is that it make it easier to find what we are looking for. Everything is where it should be.

If we are looking for an API route, we know that it will be in the API layer. The same is true if we are looking for a specific request to the database, it will be in the data access layer.

It also make it easier to navigate in the code. We know that a request is starting at the API layer and we can drill down the layers if we want to know the implementation details.

It helps reuse the logic

One of the direct results of the separation of the API logic, the business logic and the data access logic is that it is way easier to reuse the logic without duplicating it.

It is easier to reuse the business logic in multiple API routes because it is not mixed with a specific route logic. It is also easier to reuse the data access logic because it is not mixed with a specific business logic part.

For example, instead of duplicating the query to retrieve an entity everywhere, it can - and probably should - be a single function in the data access layer.

(Yes. It could and should be the case even without using the layered architecture. But we see things we can never unsee in this world.)

It makes it easier to change

The consequence of separating the logic is that is it way easier to change any part of it.

For example, if we have a single function to retrieve an entity, we have only one place to change when the filter has to change.

We can also go a step further. It is way easier to replace a whole layer if we need it. (Even if we probably would never want to replace the business logic layer. It makes more sense for the other layers.)

For example, we can replace the data access layer with limited to no impact on the other layers. It may happen if we want to switch the database engine that we use.

To make this even easier, the layers should know each other only by interface and avoid exposing their implementation details. Dependency injection can help for that.

Throwing big principles names

Since we love to name things, I thought I would try to throw big principle names that apply there:

Because it gives a structure and define where things are expected to be, it contributes to the principle of least surprise.
Because each layer has a well defined role, it contributes to the separation of concerns principle.
Because it helps to avoid duplication of the logic, it contributes to the "don't repeat yourself" principle.
To make it easier to change, we can use the inversion of control principle with dependency injection.

Conclusion

We use the layered architecture because it is quite simple to implement and helps a lot to maintain a project.

It is of course possible to make a mess while implementing it. But the structure it gives guide us in the right direction.

If you see something wrong or something that I might have missed, please reach out. I would love to learn more. And I would like this article to be as complete as possible to be able to share it next time.

Hope it helped!

How to have multiple Git configs for the same user

amabe_dev — Thu, 14 Jul 2022 17:56:00 +0000

How to have multiple Git configs for the same user?

In this article, we will see how to have different Git configs depending on the folder in which is the project we are working on.

It is quite easy to change the config for a single project. But it means we have to do it for every project on which we want the change to be made. And we need to keep it in mind to do it on every new project that we clone.

The goal here is to set it up once and be able to forget it. We will then be able to clone any new project and it will use our custom config without us doing anything.

Why have multiple Git configs?

There are multiple reasons why we may want to have multiple Git configs. For example:

To have a different commit name and email on different projects. For example, for work projects and for personal projects.
To have different aliases depending on projects. For example, if some aliases are tied to a context shared by only some projects.
To have different behavior on different projects. For example, having git pull perform a merge on some project and a rebase on others.

I can go on and on. But I might end up reciting everything that can be configured in Git. So, I won't.

What we will do

To have different configs depending on projects, we will use a Git option to include config files conditionally.

For the example, we are going to use a different name depending if we are on a work project or a personal project.

We will assume that we have a workspace structure like this:

~/
    work/
        project1/
        project2/
    perso/
        project3/
        project4/

Diving into Git configs

First, we need to create config files with the config that we want to override. For example ~/work/gitconfig and ~/perso/gitconfig and add the custom config in each.

For example, in ~/work/gitconfig:

[user]
    name = The name I use at work
    email = <myworkemail@example.com>

Then we can conditionally include the config from the folder depending on the project on which we are working on. To do this, we will add a new option in out Git config (~/.gitconfig):

[includeIf "gitdir:~/work/**"]
    path = ~/work/gitconfig

Now, each time we run a Git command in a directory inside ~/work/ folder, the custom config from ~/work/gitconfig will override our default config. And, if we run a command anywhere else, it will not.

Only the config that is present in the included file will be overridden. Anything else from the ~/.gitconfig will stay unchanged.

This is helpful to have a common config for everything. With only small differences for some projects.

(We can ever have aliases in the main config file and add new aliases in an included file.)

Using different SSH keys

When using different identities, we might want to also use different SSH keys. For example, to use different accounts on the same Git repo hosting platform (GitHub, GitLab, etc).

To do this, we will use both the SSH config file and an option from Git to change the URL used on actions.

To be able to use different SSH keys, we will update the SSH config (~/.ssh/config) like this:

Host github
    User git
    HostName github.com
    IdentityFile ~/.ssh/id_rsa # change the path to the key here
    IdentitiesOnly true

This will use the SSH key at the given path when using github as a remote (here ~/.ssh/id_rsa).

Then we need to replace the used remote from git@github.com to github to use our new SSH alias. We can either update the remote on each repository or add this in our Git config (~/.gitconfig):

[url "github"]
    insteadOf = git@github.com

Conclusion

By using this configs, we are able to have a flexible Git config. Some is common between projects because we want to use Git in the same way everywhere. And yet we are able to override some configs depending on the projects we are working on.

I found it really helpful (and quite hard to find) when I needed to use a different commit email on some projects.

If you have any feedback, please reach out either in the comments or in private. This is my first attempt at learning in public and writing about technical things. I will be grateful for any opportunity to improve.

Hope it helped! And have a good config session :)