Last week's finds #17
Cet article est libre d'accès pour tous grâce à ceux qui soutiennent notre blog indépendant.
Dans cette série, nous allons faire un peu de veille ensemble. Le principe est simple, je vous parle de ce qui m'a intéressé dans les 7 jours de veille précédents et je vous mets un lien pour que vous puissiez en profiter aussi.
La lecture, c'est ici
Insisting on Core Development Principles
Cet article ne traite pas de technique, il n'explique pas comment mettre en oeuvre une bonne pratique ou un design pattern dans un projet. Cet article explique pourquoi il est important (non optionnel) de mettre en oeuvre les standards et bonnes pratiques de développement par défaut dans tous nos projets.
Il aborde d'ailleurs le coté éthique de la chose : pourquoi nous "arnaquons" notre client si nous ne mettons pas en place les standard et bonnes pratiques dans son projet.
alistapart.com (en)
Better Routing for IOS Applications with Router in Swift
Utiliser Alamofire pour gérer les requêtes HTTP d'un projet est très bien mais peu vite devenir compliqué si les appels aux API sont nombreux.
Il est possible de simplifier le code et de le rendre plus lisible en écrivant un routeur. Beaucoup de choses sont répétitives dans ce genre de traitement et il est possible d'automatiser certaines choses en encapsulant une partie d'Alamofire dans des classes comme un routeur.
medium.com (en)
Every developer should write a personal automation API
Matthew Watkins explique pourquoi, selon lui, tous les développeurs devraient écrire leur propre API d'automatisation.
Entre gain de temps et amélioration/ajout de fonctionnalités non existantes sur les plateformes telles que IFTTT ou Flow, il donne des idées, explique ce qu'il a fait, comment il l'a fait (en gros).
Développeurs, vous avez le pouvoir d'améliorer vos vies, faites le.
dev.to (en)
Handling Internet Connection Using Reachability With ReachabilityManager in Swift
Tous ceux qui ont essayé de rendre leur application stable dans des environnements ou le réseau n'est pas stable du tout se sont frotté aux API réseaux d'iOS.
Une API sympa mais relativement compliquée à utiliser à cause des multiples situations (3G, 4G, Wifi, non connecté, Bluetooth, itinérance des datas, etc) possible de l'utilisateur. Etre connecté ne veut pas forcément dire que l'utilisateur a accès à internet.
medium.com (en)
Rejoins 250+ développeurs de notre liste de diffusion et sois reçois les articles directement dans ta boite mail.
Aucun spam. Désabonnes-toi en un seul clic à tout moment.
Si vous avez des questions ou des remarques/conseils, n'hésitez pas à laisser un commentaire plus bas ! Je serais ravis de vous lire. Et si vous aimez l'article, n'oubliez pas de le partager avec vos amis.