Mémo : The Clean Coder Robert C. Martin

En résumé, ce livre va essayer de définir la notion de développeur "professionnel".

Voici en quelques lignes les notions qui m'ont le plus marquées et avec lesquelles je suis d'accord (en théorie ou en pratique).

- prendre ses responsabilités: quand on s'engage, il faut respecter sa promesse

- savoir dire non

- savoir ce que cela représente de dire oui (ou je vais essayer ...), c'est un engagement. Plutôt donner une fourchette (x jours plus ou moins y avec des probabilités de succés)

- savoir dit que l'on va être en retard, et ce, dès que l'on s'en aperçoit. Ce n'est pas professionnel de dissimuler une vérité pour se protéger

- respecter les horaires de l'équipe

- ne pas faire des heures insoutenables, travailler beaucoup ne signifie pas bien travailler

- quand on développe, l'objectif doit toujours être : les testeurs ne trouveront pas de bug, un bug, c'est un échec. Trouver les moyens de ne pas reproduire le problème

- 100 % de code testé: non négociable -> question de confiance dans ce que l'on livre

- ne pas changer ses habitudes de bonnes pratiques sous pression, si on a de bonnes pratiques quand ca va bien, c'est parce que c'est la meilleure façon de résoudre les problèmes

- mentorer les plus jeunes, un des seuls métiers où l'on met des nouveaux sur des projets importants en autonomie, penser au pair programming

- faire faire des projets à des équipes plutôt que monter des équipes pour un projet

- savoir travailler en équipe : développeur moyen : solitaire, aime être dans sa bulle. Ce n'est pas parce que tu travailles mieux comme ça que l'équipe travaille mieux en adoptant ce mode de travail

- savoir demander de l'aide

- savoir faire du pair, surtout quand on est fatigué / pas motivé

- dormir suiffisament et ne pas travailler fatigué (code à jeter)

- savoir prendre des pauses (pomodoro ...)

- savoir garder sa concentration : refuser poliment les questions quand on a besoin de rester concentré et revenir à la prochaine pause

- TDD works (http://blog.cleancoder.com/uncle-bob/2014/12/17/TheCyclesOfTDD.html)

Ce livre devrait être lu pendant nos études. Il y a des mises en situation, des retours d'expérience qui appuie bien le message de l'auteur.

Voici le seul chapitre du livre avec lequel je suis partiellement en désaccord :

-----------------------------------------------------------------------------------

Chapter I, Profesionalism : WORK ETHIC

Your career is your responsability. It is not your employer's responsability to make sur you are marketable.

It is not your employer's responsability to train you, or to send you to conferences, or to buy you books.

These things are your responsability. Woe to the software developer who entrusts his career to his employers.

Some employers are willing to buy you books and send you to training classes and conferences. That's fine, they are doing you a favor.

But never fall into the trap of thinking that this is your employer's responsability. If your employer doesn't do these things for you, you should find a way to do them yourself.

It is also not your employer's responsability to give you the time you need to learn. Some employers may provide that time. Some employers may even demand that you take the time.

But again, they are doing you a favor, and you should be appropriately appreciative. Such favor are not something you should expect.

You owe your employer a certain amount of time and effort.

For the sake of argument, let's use the U.S. standard of 40 hours per week. these 40 hours should be spent on your employer's problems, not on your problems.

You should plan on working 60 hours per week. The first 40 are four your employer. The remaining 20 are for you.

During the remaining 20 hours you should be reading, practicing, learning, and otherwise enhancing your career.

I can hear you thinking: "But what about my family? What about my life? Am I supposed to sacrifice them to my employer?"

I'm not talking about all your free time here. I'm talking about 20 extra hours per week. that's roughly three hours per day.If you use your lunch hour to read, listen to podcasts on your computer, and spend 90 minutes per day learning a new language , you'll have at ill covered.

Do the math. In a week there are 168 hours. Give your employer 40, and your career another 20. That leaves 108. Another 56 for sleep leaver 52 for everthing else.

Perhaps you don't want to make that kind of commitment. that's fine, but you should not then think yourself as a professional. Professionals spend time caring for their profession.

Perhaps you think that work should stay at work and that you shouldn't bring it home. I agree! You should not be working for your employer during those 20 hours. Instead, you should be working on your career.

Sometimes these two are aligned with each other. Sometimes te work you do for your employer is greatly beneficial to your career. In that case, spending some of that 20 hours on it is reasonable.

But remember , those 20 hours are for you. They are to be used to make yourseff more valuable as a professional.

Perhaps you think this is a recipe for burnout. On the contrary, it is a recipe to avoid burnout.

Presumably you became a software developer because you are passionate about software and your desire to be a professional is motivated by that passion.

During that 20 hours you should be doing those things that reinforce that passion. Those 20 hours should be fun!

--------------------------------------------------------------------------------------

La phrase qui me dérange le plus est la suivante : "Perhaps you don't want to make that kind of commitment. that's fine, but you should not then think yourself as a professional"

Il est évident que l'évolution de notre carrière est de notre responsabilité.

Mais le développement n'est pas une passion pour tout le monde. Pour certain, c'est un travail qui s'effectue pendant le temps allouer à celui-ci.

Je considère donc que ma formation doit être une fraction de cette période.

J'ai déjà entendu plusieurs fois des discussions ressemblant à ceci :

"Les collègues sur ma mission c'est des boulets. j'en ai entendu un dire :

'Moi je suis la c'est pour le salaire sinon je viendrai pas'.

C'est inadmissible, heuresement que dans notre société, on ne recrute pas des gens comme ca."

Quand je réponds que je travaille pour le salaire, c'est parfois suivit d'un silence génant.

Mais lorsque l'on demande à ce même collègue : 'si t'étais millionaire, est-ce que tu continuerai de travailler ?'

La réponse est souvent négative.

Et bizarrement, ce n'est pas mon cas. Je pense que je travaillerai à mi-temps.

Log time on JIRA with REST API

If you get the chance to work with people that want you to log everything you do on jira, this little script can help:

#!/bin/bash

user="user"
password="password"

# $1 : jira number
# $2 : log to echo
# $3 : time
# $4 : jira log comment
logTime () {
  echo "#######################################"
  echo "Logging $2"
  echo "#######################################"
  
  curl -k --request POST \
    --url "https://jira.toto.fr/rest/api/2/issue/$1/worklog" \
    --user "$user:$password" \
    --header 'Accept: application/json' \
    --header 'Content-Type: application/json' \
    --data '{
      "comment": "'"$4"'",
      "timeSpent": "'"$3"'"
    }'
}

logTime "Jira-number" "log jira" "time (format : 15m, 4h 3d ...)" "jira comment"
logTime ...
logTime ...

Daily 2.0 : one browser extension that keep you up to date

I was searching for ways to find information on development. I was first told of Medium which is a nice way to get that.

There is a also nice browser extension called Daily 2.0 that basically does the same thing. You just need to add it to your favorite browser, enter your preferences by tags and then read a lot :)

You can find the chrome extension here

What should I say when the customer asks for direct data access ?

On my project, we were asked to open our database to the customer. At first I knew it was bad but I didn't have the argument to answer. I finally came to this mail.
They are currently asking customers what they really need to see. I see improvment :)

-----------------------

Hello @all,

In the backlog, we have this user story : As a user, I can request my data on a database copy.

I will need to know what are the reasons for this request. What information do users need?
In general, a request like this one comes from a lack of functionality in the application.
To rephrase, the question would be: What would these users need to have in the application to avoid having direct access to the database (replicated or not)?

If the answer is: "they already have access on their current application", it is not a good answer. :D

I have several problems with this:
- Security on the exposed data
- Performance risk (anyone can make risky SQL queries, even read-only ones)
- Data and performance control is no longer the responsibility of the informatic service alone
- It requires training these users on our data model
- It requires support when they can't do what they want
- It requires to change the data exposed when the model evolves
- Risk of having to justify ourself to the business on the data structure
- No guarantee that they use the extracted information correctly
- No tests on the exposed data

Topics that talk about the subject:

https://security.stackexchange.com/questions/175344/what-are-the-risks-of-allowing-business-users-direct-production-database-access
https://stackoverflow.com/questions/1559892/why-shouldnt-i-give-outsiders-access-to-my-database

Seen from below, it looks like a reporting / export / API exposure demand that has evolved because we don't know what we want to do.

Did the informatic service already authorized this type of demand before? If so, it's amazing.

Thank you for your answers.

Clean you mailbox with Cleanfox

If you want to make your world a better place (Miss u MJ) and/or if you just want to get rid of all those newsletters you keep receiving, you can try Cleanfox.

It will automatically detect newsletters / spam and will let you choose what you want to remove. It can also unsubscribe you from those newsletters.

It can be use on all main mailboxes an is easy to use.

Trust this nice french company. ;)

|| operator, a coalesce like in Javascript

When I first encounter coalesce in SQL, I was amazed by the simplicity and the usefullness of the function. So I searched for it in other languages.

The closest I get in Javascript was to use the || operator. Using it on multiple operand will result in taking the first non null, non undefined, non false variable. See done below:

const a = null;
const b = false;
const c = 8;

a || b || c;
8

const d = true;

a || d || c;
true

const e = undefined;

a || e || c;
8

Remove leading and trailing spaces on Strings across your spring application with Jackson

If you are using Jackson to convert http messages, you can add a custom String Deserializer to removes heading and trailing spaces across you application in a few lines.

import com.fasterxml.jackson.core.JsonParser;
import com.fasterxml.jackson.databind.DeserializationContext;
import com.fasterxml.jackson.databind.deser.std.StdDeserializer;
import org.apache.commons.lang3.StringUtils;

import java.io.IOException;

public class StringDeserializer extends StdDeserializer<string> {

  private static final long serialVersionUID = 1623333240815834335L;

  public StringDeserializer() {
    this(null);
  }

  private StringDeserializer(Class vc) {
    super(vc);
  }

  @Override
  public String deserialize(JsonParser jp, DeserializationContext ctxt) throws IOException {
    String valueAsString = jp.getValueAsString();
    if (StringUtils.isEmpty(valueAsString)) {
      return null;
    }

    return valueAsString.trim();
  }
}

To activate it, add this bean to your WebConfig file.

@Configuration
@EnableWebMvc
public class WebConfig implements WebMvcConfigurer {

  @Bean
  public MappingJackson2HttpMessageConverter mappingJackson2HttpMessageConverter() {
    MappingJackson2HttpMessageConverter jsonConverter = new MappingJackson2HttpMessageConverter();
    ObjectMapper objectMapper = new ObjectMapper();
    objectMapper.configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, false);
    objectMapper.configure(SerializationFeature.FAIL_ON_EMPTY_BEANS, false);
    objectMapper.setVisibility(PropertyAccessor.FIELD, Visibility.ANY);
    jsonConverter.setObjectMapper(objectMapper);

    SimpleModule module = new SimpleModule();

    module.addDeserializer(String.class, new StringDeserializer());
    objectMapper.registerModule(module);

    return jsonConverter;
  }
}