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 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 !

Achats :

SwiftyStoreKit : pour les achats in apps : https://github.com/bizz84/SwiftyStoreKit

 

Interface :

ActiveLabel : remplacement de UILabel qui supporte les hashtags, les mentions, les urls : https://github.com/optonaut/ActiveLabel.swift

IQKeyboardManager : pour le problème de recouvrement des textes par le clavier : https://github.com/hackiftekhar/IQKeyboardManager

MarqueeLabel : remplacement de UILabel, ajoute un scroll automatique lorsque le texte dépasse le label : https://github.com/cbpowell/MarqueeLabel

NotificationBanner : des bannières de notification : https://github.com/Daltron/NotificationBanner

PKHUD : pour l’affichage de logo de chargement, sons… https://github.com/pkluz/PKHUD

PureLayout : extension pour UIView, NSView, NSArray et NSLayoutConstrain : https://github.com/PureLayout/PureLayout

RMessage : de jolis messages d’alerte / d’informations : https://github.com/donileo/RMessage

SCAlertView : de jolies popup d’alerte : https://github.com/vikmeup/SCLAlertView-Swift

SideMenu : un simple SideMenu en Swift : https://github.com/jonkykong/SideMenu

SlideMenuController : pour un menu « Hamburger » : https://github.com/dekatotoro/SlideMenuControllerSwift

Snapkit : pour l’autolayout : http://snapkit.io/

 

Debug :

https://api.randomuser.me/ : API pour test : génère des données d’utilisateurs (JSON…)

Crashlytics : analyse de crash : https://try.crashlytics.com/

https://jsonplaceholder.typicode.com/https://github.com/typicode/jsonplaceholder : REST API gratuite pour tests, supporte les requêtes standartd GET, POST…

 

Divers :

https://api.gouv.fr/apis : les api du gouvernement Français : niveaux d’eau…

https://api.nasa.gov/ : la Nasa…

Bolts-Swift : framework de bas niveau développé par Facebook : https://github.com/BoltsFramework/Bolts-Swift

https://cloudconvert.com/ : pour convertir un fichier d’un format vers un autre

LevelDB : système de stockage key-value par Google permettant un meilleur tri : https://github.com/google/leveldb

https://market.mashape.com/ : tout un tas d’api’s, gratuites ou non

https://www.programmableweb.com/category/all/apis?data_format=21173 : beaucoup d’api’s également

http://restcountries.eu/ : permet d’avoir des infos sur les pays : capitale, monnaie, population

 

Films :

http://www.themoviedb.org/ : api concernant les films

 

Images :

DMSwipeCards : pour créer un effet « incliné » sur des « cartes » (images), par exemple lorsque l’on veut effacer une image : https://github.com/D-32/DMSwipeCards

HexColors : extension pour UIColor et NSColor qui permet de créer des couleurs depuis leur code hexadecimal : https://github.com/mRs-/HexColors

IGRPhotoTweaks : pour autoriser l’utilisateur à recouper, faire tourner… des photos : https://github.com/IGRSoft/IGRPhotoTweaks

https://imagga.com/ : reconnaissance d’images

Nuke : pour la mise en cache d’images : https://github.com/kean/Nuke

 

Maps :

Cluster : pour faciliter les annotations sur les maps : https://github.com/efremidze/Cluster

 

Météo :

https://darksky.net/dev : api météo

https://openweathermap.org/api : api météo

https://openweathermap.org/api : API pour une appli météo

Réseau :

Alamofire, Moya et swiftyJSON : parsing d’url et gestion du json (REST) :

https://github.com/Alamofire/Alamofire

https://github.com/SwiftyJSON/SwiftyJSON

https://github.com/Moya/Moya

GoogleToolboxForMac : différents projets Google : https://github.com/google/google-toolbox-for-mac

Gtm-session-fetcher : GoogleToolboxForMac – pour les opérations http : https://github.com/google/gtm-session-fetcher

NanoPb : système de protocol buffer : https://github.com/nanopb/nanopb

Protobuf : Google, envoi de données : https://github.com/google/protobuf

ObjectMapper : conversion JSON : https://github.com/Hearst-DD/ObjectMapper

Reachability : ré-écriture de Apple Reachabilyty pour connaître l’état du réseau Attention : possibilité de rejet par Apple : voir le site : https://github.com/ashleymills/Reachability.swift

 

Sons :

JSQSystemSoundPlayer : pour ajouter des sons : https://github.com/jessesquires/JSQSystemSoundPlayer

 

 

 

 

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 !

React Native : je continue mes essais !

Ma première application mobile React Native

Comme je l’avais évoqué ici, je m’intéresse au développement cross platform, et plus particulièrement à la prometteuse technologie React Native.

Et, grâce au super cours d’Open Classroms, (un giga merci à eux), j’ai pu, après beaucoup de transpiré du cerveau, avoir la joie de faire fonctionner ma première application React Native !

Bon, ce n’est pas grand chose, un petit pas dans Javascript, mais un grand pas pour moi !

Lorsque Microsoft à proposé gratuitement Visual Studio et Xamarin, j’avais déjà tenté la programmation cross platform… et n’avais pas été très enthousiasmé : courbe d’apprentissage rude à mon goût, passage en langage natif tôt ou tard incontournable, temps de compilation ++ …

Mais là, j’ai été bluffé ! J’ai eu un coup de foudre technologique 🙂

La technologie est encore jeune, c’est clair, et je ne suis pas prêt de l’utiliser de manière professionnelle, mais c’est vraiment prometteur !

Le plus bluffant est l’absence de la phase de compilation (merci Javascript) : le résultat d’un changement du code est visible immédiatement sur le device ou la MV (merci Expo). Impressionnant.

Pour le debug, pour le moment, je ne suis pas vraiment à l’aise… Comme « IDE », j’utilise « Atom« , et je n’en ai pas encore exploré toutes les possibilités.

Niveau apprentissage, c’est clair que j’ai du boulot ! Je suis pas près d’être aussi performant qu’en Swift ! Mais ce n’est pas le but pour le moment. De toutes façons, je n’ai pas trouvé comment faire d’appli pour l’Apple Watch alors…

Pour les curieux, voici le code source sur FramaGit (soyez tolérants, c’est mon premier programme en JS :

https://framagit.org/VinceBar/MoviesAndMe.git

Et comme d’habitude, si vous avez des questions, suggestions… commentez !

Quant à moi, je sens que je vais passer quelques we à faire du React Native !

 

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 !