API or not API, that is the question…

API _ Application programming interface

Sous ce titre un peu… provocateur (la chaleur de ce mois d’août y est peut-être pour quelque chose 🙂 ), j’ai décidé de vous partager différentes ressources en ce qui concerne les APIs et Librairies que j’utilise ou suis susceptible d’utiliser pour mes développement d’applications mobiles.

Cet article est bien sûr destiné à être mis à jour régulièrement, donc n’hésitez pas à (re)venir y jeter un oeil de temps en temps !

Lire la suite

La Cathédrale et le Bazar

cathedral_bazaar

Je profite du relâchement (relatif) du mois d’août pour me remettre un peu à la lecture… de livres ayant trait à l’informatique vous vous doutez bien 😉

Premier de la liste : La Cathédrale et le Bazar, d’E.Raymond.

C’est impressionnant comme un essai paru en 1999 peut être par beaucoup de cotés à la fois précurseur et d’actualité !

Voici le résumé tiré du site verbiage.fr :

 »

Eric Steven Raymond est un informaticien américain oeuvrant dans le monde du logiciel libre à qui l’on attribue la création du terme « open source ». En 1999, il diffuse un essai devenu depuis une référence dans le monde du logiciel libre « The Cathedral and the Bazaar » (La cathédrale et le bazar).

Eric Raymond y oppose les modèles de développement des logiciels libres à ceux appliqués aux logiciels propriétaires.

Rédigé par un informaticien, évoquant le développement d’outils informatique, il n’est que peu souvent cité comme ouvrage de référence de Management. Pourtant, Eric Raymond développe sans prétention une analyse mettant en évidence la supériorité d’un modèle d’organisation basé sur la transparence et la collaboration.

C’est ici qu’apparaît, à mon sens, le principal point commun avec l’ouvrage de Vineet Nayar. Ils posent tous les deux les principes d’une organisation déstructurée favorisant l’initiative, l’efficacité et la créativité.

Par opposition aux organisations managériales traditionnelles dits de « type cathédrale » marquées par une hiérarchie, une structure forte, Eric Raymond présente le modèle du logiciel libre basé sur le collaboratif, le volontariat, la transparence. Tout est ouvert, tout est accessible, tout est transparent, une organisation à la fois horizontale et verticale : un bazar. Ici le responsable se fait davantage coordonnateur.

Contrairement aux apparences le modèle bazar n’est pas l’anarchie. Il est au contraire structuré par ses propres règles de fonctionnement, basées sur la souplesse, la rapidité et les échanges permanents entre contributeurs.

Au delà de l’éloge d’un type de management différent, que l’on pourrait juger plus où moins adapté à tel ou tel type d’entreprise, sont évoqués ici les thèmes essentiels dans la gestion de projet et dans la gestion des hommes que sont la motivation et la créativité.

L’organisation doit permettre de ne pas perdre de vue l’objectif visé, de mettre en cohérence les travaux de chacun, sans être un carcan limitant l’initiative et la créativité.

Les axe essentiels sont la motivation « tout bon logiciel commence par gratter un développeur là où ça le démange », la compétence (ici des développeurs), la transparence, mais aussi enfin et surtout une relation permanente avec les utilisateurs « traiter vos utilisateurs en tant que co-développeurs est le chemin le moins semé d’embûches vers une amélioration rapide … ».

Une démarche itérative de correction des bugs orientée client qui, en définitive, donne au bazar la charpente nécessaire à sa réussite, son but ultime : satisfaire l’utilisateur final.

Les succès de Linux, Wikipedia, la fondation Mozilla et son célèbre navigateur Firefox, l’émergence de start up devenues depuis des multinationales (Google…), sont les signes qu’un management différent est en train de s’imposer. De plus en plus d’entreprises « cathédrales » se laissent en effet peu à peu tenter par l’esprit « bazar ».

 »

A lire ou à relire, sur la plage ou ailleurs…

Ayant eu quelques difficultés à trouver la version epub pour ma liseuse, je vous mets en téléchargement les fichiers pdf et epub :

cathedrale-bazar.pdf

cathedrale-bazar.epub

Bonne lecture à tous, et si vous avez des suggestions pour le blog, n’hésitez pas à les mettre en commentaires !

Programmation Swift : le mot-clé guard

GuardOrIf

Je ne sais pas pour vous, mais il m’a fallu un moment pour comprendre à quel moment il était préférable d’utiliser le mot clé « guard » à la place du couple « if / else » en programmation Swift.

En fait, c’est comme tout, lorsque l’on à compris… c’est hyper simple ! Mais avant 😦

Donc, la différence entre « if » et « guard » est un peu subtile, mais la voici : « guard » doit être utilisé lorsque une donnée doit être présente pour la bonne exécution de la fonction.

Bon, dit comme cela, c’est encore un peu flou, alors voici un petit exemple :

guard.png

Ici, il est nécessaire que les champs « name », « address » et « phone » soient remplis pour pouvoir exécuter la fonction « sendToServer ». Sinon, on affiche un message et on sort de la fonction (return). On aurait bien sûr pu faire la même chose avec des « if/else », mais avouez que cela aurait certainement eu un impact négatif sur la taille et la lisibilité du code !

En fait, on s’aperçoit vite qu’une grande partie des « if / else » peuvent êtres avantageusement remplacés par des « guard » ! Cela nécessite un peu d’entrainement au début (il faut réfléchir « à l’envers »), mais cela améliore nettement la lisibilité du code !

Donc, maintenant, plus de prétexte pour planter (dans vos codes…) des forêts d’Ifs !

 

 

A propos de… moi !

IMG_5270Carre

Vincent Barousse, développeur d’applications Apple iOS / swift (entre autres…)

J’aime les ordinateurs sous toutes leurs formes, j’aime le code et j’aime la nouveauté. Cette passion m’a poussé à m’orienter vers le développement iOS et watchOS en 2015.

Je mets maintenant mon expertise dans ce domaine au service de mes clients.

Cette page est là pour résumer mes différentes réalisations.

Lire la suite

Mémo : utilisation de NSLocalizedString en Swift

Cet article n’est pas un tutoriel en temps que tel, mais plutôt un mémo sur l’utilisation de fichiers « string » pour gérer les traductions dans une application iOS.

Pour cet exemple, nous allons créer une application très simple : 1 vue, 1 champ de texte : voir les captures d’écran ci dessus.

Le champ texte sera localisé, c’est à dire qu’il sera automatiquement traduit en fonction de la langue du device.

Donc, pour réaliser ce « miracle », il faut commencer par créer un fichier « Localizable.strings » (cliquez sur les images pour agrandir) :

On crée donc simplement un nouveau fichier de type « Strings File ».

On rajoute les langues désirées dans les paramètres de l’appli :

AddLocalization

Et on ajoute également les langues pour le fichier Localizable.strings :

AddLocalization2

2 fichiers sont alors créés : Localizable.strings(French) et Localizable.strings(English).

Ces fichiers contiendront les traductions sous forme de « Clé » = « Valeur ».

Voici donc le contenu des fichiers English et French (cliquez pour agrandir) :

Enfin, pour utiliser nos traductions, il suffit de les appeler sous la forme NSLocalizedString(key : «  », comment : «  ») ex :

let myString = NSLocalizedString(key : « Hello », comment : «  »)

Appliqué à notre view controller, cela donne :

carbon(4)

Tout simplement…

Maintenant, plus de prétexte pour ne pas gérer correctement ses traductions !

Des commentaires, des questions ? Commentez !