Le Front-end dans la vie public. Règles de conception pour les styles (CSS)

 

Règles de conception

Balises principales :

• On n'écrit pas de CSS;
• On utilise des composants qui existent dans les librairies des développeurs;
• On veut quand même arriver avec un visuel qui semble au système de design du gouvernement.

Pour y arriver, pendent la conception des maquettes, on se serve concrètement des composants Bootstrap et Kendo UI (dans cet ordre) sauf si le composant de Quebec.ca n'est pas trop lois de ces composants.

On attente le moment où on peut juger l'utilisation de certains composants certain et stable, pour affiner le thème, si ces composants ne semblent pas assez au système de design.

Technologie UI générale

• Framework : Kendo UI for MVC (pas de SPA); On crée un thème pour Kendo UI/Bootstrap, et on crée qu'un minimum de CSS.
• Hyperliens pour une section du formulaire ou une question, et pour la page de connexion
• Navigation historique entre vues marche (bouton retour plutôt que reset)
• La session est suffisamment longue (20h idéalement; 1h min.)
• HTML 5 (CSS 4, 5), l’interaction peut être différent dépendent des capacités du navigateur (progressive enhancement)
• Enregistrement des sections sans remplir tout le champs obligatoires et sans soumettre la demande
• Confirmation de navigation s'il y a des changements non-enregistrés
• HTTPS partout
• Validation des formats des champs et obligatoires au moins par JavaScript, sur blur (inline)
• Soumission implicite sur touche Entrée dans les champs
• Les formats d'affichage doivent toujours être accepté comme format d'entrée, particulièrement sans et avec espaces, pour permettre copier-coller
• Limites des charactères généreux ou sans limite pour permettre des espaces ou des cas extrêmes (Consultation)
• Performance comparable à AJAX (Turbolinks/SPA) souhaitable
• Aperçu des fichiers souhaitable, avant le téléversement encore mieux

a11y

• HTML sémantique
• Tests avec clavier
• Tests avec un lecteur d'écran
• SGQRI 008 2.0 

Textes

• Si un article de la loi est mentionné, mettre un lien vers l'article chez legisquebec.ca
• Les abréviations sont expliqués (premier occurrence avec parenthèses)
• Pas des formulations négatives
• Les signes de ponctuation, si nécessaire, sont séparé par un espace fine, ou au moins avec un espace insécable

Déjà utile

• Kendo UI (Telerik for APS.NET MVC) 
• Stratégie de transformation numérique gouvernementale 2019-2023 
• Dix principes de conception 
• Sondage 5 minutes pour contribuer à la transformation numérique gouvernementale 
• Implementing a citizen-centric approach to delivering government services 
• WCAG Quick reference 
• SGQRI 008 2.0 
• PIV  gouvernement:gouv@piv
• Systeme de design Quebec.ca 
  • Accordéons 
  • Retour en haut de page 
  • Notes  et exemple mobile 
  • À consulter aussi 
  • Champs texte 
  • Champs obligatoires 
  • Fil d’Ariane 
  • Images 
  • Tuiles  (en développement)
  • Menu déroulant  (en développement)
  • Infobulles  (en développement)

Regardé

• Lion Web Components 
• 9 Web Components UI Libraries You Should Know in 2020 
• Stimulus JS 
• Bootstrap 

backup post - QC MTL job salaries 2020.

Some pics of job salaries for IT positions.

Also some wafers for those coffee brakes.

Goodhart’s Law on Software Development

Goodhart's law is an adage named after British economist Charles Goodhart, who advanced the idea in a 1975 article on monetary policy in the United Kingdom, Problems of Monetary Management: the U.K. Experience (wiki 2020) 

There are numerous concepts related to this idea, at least one of which predates Goodhart's statement of 1975

Clean Code et bonne pratiques en général

 

Règles générales concernant la longueur des classes et méthodes

1. Les méthodes devraient avoir au plus 20 lignes

2. Les classes devraient avoir au plus 200 lignes

3. Une classe devrait contenir au plus 10 méthodes

4. Plus les méthodes et les classes sont grandes, moins elles sont réutilisables   

   Principe de proximité

   • Regrouper ensemble une méthode publique avec ses méthodes privées

     • Permet de lire le fichier comme un journal : Grand titre = méthode publique, sous-titres = méthodes privées, etc.

     • Éviter les régions

     • Moyen artificiel d'organiser les fichiers
     • Dissimulent la véritable longueur d'un fichier et sa complexité
     • Ne valent pas mieux que les commentaires si on les compare au code auto-documenté

Créer une branche de feature dans Visual Studio et Azure DevOps

Sur Visual Studio

1. Basculer sur la branche master.

   • S'il y a des modifications dans la branche courante, il faudra les valider (commit) ou les annuler (undo) avant de basculer sur master.

2. Tirer la dernière version de la branche master.
   
   

3. Créer une nouvelle branche à partir de la branche master locale et la nommer selon la règle de nomenclature.
   
   

Sur Azure DevOps

1. Sélectionner New Branch à partir de la branche master.
   
   

2. Nommer la branche selon la règle de nomenclature.
   
   

3. Tirer la nouvelle branche sur Visual Studio

   • S'il y a des modifications dans la branche courante, il faudra les valider (commit) ou les annuler (undo) avant de tirer la nouvelle branche.

   • Récupérer la liste de branches distantes à partir du serveur (fetch).
     
     

   • Basculer vers la nouvelle branche en faisant un double clique sur son nom. La branche sera automatiquement tirée.
     
     

Check your C# in Visual Studio

Steps to check your version of C# in your Visual Studio projet.

1. Right click on the project name and select Properties from context menu
2. Select Build tab from left
3. Scroll down and click Advanced button to open advanced build settings
4. From Language version dropdown select C# version you are interested in

39

Here I am 39, one more cucke and more year and one year less. SHOULD always make it count wether is enjoying nature, working on a project or simply by spending time with good friends a d family that appreciate you, is the way enjoy the ride of life which could end in any moment. Stay in the moment.

Old classic casting in C#

The classic difference between int.Parse(), Convert.ToInt32() and int.TryParse().

int.Parse(string s)

Simply, int.Parse (string s) method converts the string to integer. If string s is null, then it will throw ArgumentNullException. If string s is other than integer value, then it will throw FormatException. If string s represents out of integer ranges, then it will throw OverflowException

 

Convert.ToInt32(string s)

 Simply, Convert.ToInt32(string s) method converts the string to integer. If string s is null, then it will return 0 rather than throw ArgumentNullException. 

 If string s is other than integer value, then it will throw FormatException. If string s represents out of integer ranges, then it will throw OverflowException.

 

Int.TryParse(string s,Out)

Simply int.TryParse(string s,out int) method converts the string to integer out variable and returns true if successfully parsed, otherwise false. If string s is null, then the out variable has 0 rather than throw ArgumentNullException. If string s is other than integer value, then the out variable will have 0 rather than FormatException. If string s represents out of integer ranges, then the out variable will have 0 rather than throw OverflowException.