Excellent : une application d'exemple de l'équipe qui a travaillé sur Ionic 4. Bon à prendre pour checker les bonnes pratiques en dev Ionic.

Petit rappel : avant d'implémenter un Dark Mode, pensez bien aux contraintes.
Un exemple : au taf on développe une application de transports en commun (calcul d'itinéraires, horaires de départ, tout ça).
Mais là, le client veut un skin sombre.
Sauf que :

• On parle d'une application de transports, que les gens vont utiliser le plus souvent... en extérieur.
• Les gens vont l'utiliser ponctuellement, 1 à 3 fois par jour.
  Il n'y a donc aucun intérêt à faire un mode sombre.
  1) Un mode sombre serait moins lisible en journée, donc plus difficile de voir ce qui est à l'écran s'il y a du soleil ou une forte luminosité.
  2) Les gens ne passeront pas des heures devant leur écran à regarder l'application. Donc ça n'apportera pas vraiment de "repos des yeux".
  3) L'économie de batterie est intéressante, mais elle se ferait donc au détriment de l'utilisabilité de l'application (voir point 1).
  Mettre un skin sombre à l'application serait contreproductif.

"Les développeur(euse)s détestent PHP car c’est cool de détester PHP"
via <A href="https://sebsauvage.net/links/?ex3i3g" rel="nofollow">https://sebsauvage.net/links/?ex3i3g</A>

TL;DR : à date de sortie égale, un bon smartphone Android sera 3x plus lent à exécuter du JavaScript qu'un iPhone.
Ce qui explique la sensation de réactivité / fluidité des iphones vs les Android.
(A noter aussi que les iPhones sont désormais plus rapides à exécuter du JS que les macbook pros)
<<The iPhone 11 performs as advertised on the Speedometer 2.0 JavaScript test with a score of 150. That’s exactly 20% more than the XS. Matching the iPad Pro. And almost THREE times faster than the latest Snapdragon 855. (Thanks @LaurenGoode for testing ❤️).
It’s also more than 20% faster than my 10-core iMac Pro! And ditto for the MacBook Pro. The Apple chip team is once again simply trouncing everyone else in the industry. The best Android chip continues to be about 3 years behind Apple on this test. Astounding.
Also interesting: This doesn’t seem to be about which JavaScript engine you run. Chrome and Safari hit exactly the same 125 on my iMac Pro running latest release of both and OSX. This really is all down to Apple’s insane chip power.
Which brings us to another point: Apple phones are now faster at dealing with the web than any desktop or laptop computer that Apple sells. Think about that! You have to remember to take care of slow computers (and Androids!), not apple phones, when designing for the web 🤯
And it doesn’t seem like Apple is close to hitting any walls. Next year they’re rumored to go to 5nm chips. So a few more years of 20-30% y/y improvements doesn’t seem out of the question. And every jump just makes Intel (and Android chip makers) look ever more silly.
Finally, look at how slowly Qualcomm is improving. The Snapdragon 845 in the S9 scored a 56 against the latest 855 in the One Plus 7 Pro with 64. That’s a 14% y/y improvement. If that’s the constant rate of improvement, it’ll be 2025 before they have a chip to match the A13 😂
Actually, given how poorly flagship Snapdragon chips perform for the web, I’m actually really curious what mid-tier or low-end Android phones are like? Anyone has some Motorola mid tier $300-400 phones they could test with? browserbench.org/Speedometer2.0/>>

J'aime bien le raisonnement et le process à privilégier :

• Commencez par la problématique métier : quel est le besoin, la problématique à résoudre
• Brainstormez et challengez les différentes idées et solutions
• Sketchez votre approche, fignolez la en groupe
• Rédigez une documentation avec des diagrammes simples
• Envisagez des sacrifices et des alternatives en fonction de vos priorités (ex. monolithe > microservices car compétences dispos et gain de temps)
• Faites circuler le design auprès de tous ceux qui sont intéressés, histoire d'avoir leurs feedbacks (ex. le collègue qui rappelle que certains utilisateurs sont malvoyants et ne pourront pas utiliser l'appli à cause de X)
  Le fait de partir du besoin métier, pour ensuite essayer de résoudre la problématique, c'est pour moi la façon la plus saine d'arriver à une bonne solution.
  Partir de l'idée de quelqu'un (je veux du mobile, je veux une appli qui fait exactement ça, je veux une liste déroulante, je veux cette interface) c'est le meilleur moyen de se planter et de coder de la merde.

Une petite checklist qu'on utilise dans mon équipe pour les merge requests, que je voulais partager.

var names = Input.GetJoystickNames();
       foreach (KeyCode kcode in Enum.GetValues(typeof(KeyCode)))
       {
           if (Input.GetKeyDown(kcode))
               Debug.Log("KeyCode down: " + kcode);
       }

La BIBLE. J'ai pas d'autres mots. Vous devez faire une application mobile ? Lisez cet article. Et appliquez ce qui est dit. Y'a RIEN de faux. Tout y est.

Un gros article : accumulation de plein d'astuces / méthodos / règles pour bien développer en mobile (avec Ionic ou autres frameworks)

Un truc que j'ai appris à mon dernier taf : si des membres de l'équipe posent un gros problème à l'équipe, c'est que leur place n'est probablement pas dans cette équipe, peu importe qu'ils soient ultra bons techniquement.
Je pense surtout :

• Aux gens toxiques, sans empathie, cassants, méchants dans leurs commentaires de merge et limite méchants en général, considérant qu'un développeur moins bon qu'eux est nul. (La méchanceté gratuite n'est jamais productive)
• Aux gens qui se plaignent quotidiennement, qui sont ultra négatifs et pessimistes, et qui démotivent tout le monde, sans jamais chercher à agir pour améliorer les choses (2 solutions : Soit tu peux améliorer les choses, donc tu agis. Soit tu ne peux pas, donc à quoi bon te plaindre tous les jours des mêmes choses, autant l'accepter ou chercher du travail ailleurs.)
• Aux gens qui se rendent volontairement indispensables et incontournables (ne documente rien, a ses propres outils et process, travaille énormément et prend peu de congés, refuse de déléguer ou d'expliquer ce qu'il fait et comment il le fait, répète souvent "non mais t'en fais pas, je m'en occupe"...)
• Aux gens qui refusent catégoriquement (de façon assumée ou en esquivant volontairement à chaque fois) de faire leur part de tâches "moins intéressantes" (documentation, tests, correction de bugs, maintient de la CI, ...)
• Aux gens qui prennent plein d'initiatives sans jamais consulter personne, qui bossent dans leur coin sur des trucs pas importants ou prioritaires, sans jamais se synchroniser avec le reste de l'équipe. (=ceux qui veulent juste s'amuser techniquement)
  Peu importe que ces gens là soient bons techniquement ou pas. Si après avoir parlé avec eux de ces problématiques, ils refusent de changer, ou n'y arrivent pas, il faut leur chercher une place ailleurs. En solo sur des petits projets, en correction de bugs, avec des managers qui sont du genre à tout contrôler, etc.
  Voire même juste... les remercier.
  Ces gens là sont des développeurs qui peuvent détruire une équipe à eux seuls. Un seul de ces développeur dans une bonne équipe peut ruiner le moral de tout le monde et faire partir des gens cools et compétents. Tout ça pour garder un mec toxique mais compétent ? Non merci.
  Si je devais monter une équipe, je prendrais plutôt des gens moyennement bon techniquement mais au top humainement, que des gens ultra bons techniquement mais bof humainement.
  Car on sera toujours plus heureux à travailler avec des gens cools sur un projet inintéressant, que de travailler sur un projet intéressant avec des gens toxiques.

Lien 1 : <A href="https://material.io/resources/color/" rel="nofollow">https://material.io/resources/color/</A>
Le color tool de material design qui permet de prévisualiser et de trouver les couleurs qui vous plaisent.<A href="https://www.sessions.edu/color-calculator/" rel="nofollow">https://www.sessions.edu/color-calculator/</A>
Une color wheel qui permet de trouver les bonnes couleurs complémentaires en fonction du thème que vous souhaitez faire.<A href="https://ionicframework.com/docs/theming/color-generator" rel="nofollow">https://ionicframework.com/docs/theming/color-generator</A>
Le générateur de thèmes d'Ionic (pour la V4) qui permet à partir des codes Hexa de générer tout le SCSS nécessaire.<A href="https://ionicframework.com/docs/v3/ionicons/" rel="nofollow">https://ionicframework.com/docs/v3/ionicons/</A>
Les icones d'ionic.<A href="https://coolors.co/browser/latest/1" rel="nofollow">https://coolors.co/browser/latest/1</A>
Un site pas mal où on peut créer un thème en quelques clics (ou s'inspirer de thèmes existants)

Quand vous utilisez flex pour des trucs assez précis en CSS, avec des min-width ou max-width, genre :

• élément 1 : flex-grow: 0; flex-shrink: 1; flex-basis: 50%;
• élément 2 : flex-grow: 1; flex-shrink: 0; flex-basis: 50%; min-width: 300px;
  Pensez à mettre un flex-wrap: nowrap; sur le parent. Sinon au lieu de shrink votre premier élément poussera l'autre à la ligne, et vous perdrez 2h pour rien ! :D

Le meilleur site pour quand on bosse avec RxJS <3

"We don't talk about failure much in tech. So many rockstar ninja geniuses, and so much success. It's time for a change.
I'll start:
It took me two months longer than most people to graduate from code school because coding was really challenging for me at first (and still is)."
Parce qu'il n'y a pas que des "ninja". On a tous nos points faibles et nos galères.
Personnellement :

• Je fais 2/3 recherches stackoverflow par jour sur des trucs bidons que je devrais vraiment connaître
• Même après 6 mois à faire de l'angular, je dois toujours copier/coller la structure de base des composants (je suis incapable de retenir la syntaxe)
• J'ai énormément de mal à comprendre et assimiler rxjs et les enchainements d'observables