Things any programmer should know #4

  • A good bug report must express three things:
    • how to reproduce the bug
    • what should have happened, in your opinion
    • what actually happened, with as much information as you can record
  • You can improve code by removing it. You Aren’t Gonna Need It.
  • Remove all you warnings or deal right away with a warning when it appears. You need to get rid of the noise.
  • Know your IDE but try working with command-line build tools, they can help look under the hood and understand what is going on.

 

Things any programmer should know #3

  • Understand as much as you can the project you work on
  • A common web-based development architecture:
    • local development and unit testing on the developer’s machine
    • development server where manual or automated integration testing is done
    • staging server where the QA team and the users do acceptance tests
    • production server
  • If something is broken, it should not be fixed on production.
  • There is no guru. There should be an expert willing to develop other experts.

Things any programmer should know #2

  • Don’t ignore an error!It will raise problems in the future.
  • Write comments only when the code doesn’t or can’t say something.
  • Technical exceptions will be handled by the application framework while the business domain exceptions by the client code.
  • Deploy often.
  • Challenge yourself by doing what you are not good at (deliberate practice).

Things any programmer should know #1

  1. Create shared library only when you know the context. Sometimes, while decreasing the number of line of code in the system the number of dependencies is increased.
  2. Care for the team’s code. Make it a little bit better than when you checked it out.
  3. Debug your own code before rushing to blame others.
  4. Choose the right mix of tools:
    1. avoid architectural mistmatch (some tools are good only in some specific contexts)
    2. avoid using too many
    3. should be easy to configure
    4. licensing terms matter
    5. start by using only the tools that are absolutely necessary

Une journée à Avignon

Je suis parti de Paris à Avignon  à 7h dans le matin en TGV. Le voyage a duré 2h:40. C’était la premiere fois que j’ai voyagé vers le Sud. Quand je suis arrivé à Avignon je suis allé visiter le Palais des Papes. Cette grande construction gothique du Moyen Age a été la residence pour 9 papes. J’ai pris trois heure pour visiter ce lieu plein d’histoire.

Personne ne dansait sur Le Pont d’Avignon, le fameux pont sur le Rhone. J’ai passé une heure lá.

J’ai visité le Musée du Petit Palais et je me suis promené dans le centre-ville jusqu’a la fin de la journée.

MVC Architecture

Model – the application data and behaviour in terms of its problem domain. It is independent of the UI. (Domain Model – POCO).

View – the HTML markup we want to display to the user.

Controller – it is responsible for handling a HTTP request. It does some things.

Router – selects the right controller. Based on some rules the router knows that a request should be handled by a method of a class (called an action) with the same name as the request. So, an action in a controller is responsable for handling a request.

ASP.NET Core Authorization

Authentication – when you ask someone who they are and you get its identity.

Authorization – decide what identity is able to do.

You can authenticate but you don’t have to authorize.

You can authorize without having any authentication.

Two main HTTP codes in web security:

401 – Unauthorized – You are not authenticated

403 – Forbidden – You are authenticated but you don’t have access

ASP.NET Authorization workshop