fabernovel loader

16 févr. 2017 | 6 min de lecture

Tech

DotSwift, nous étions là

Pierre Felgines

Developer Senior


APPLIDIUM
Le vendredi 27 janvier avait lieu la dotSwift à Paris, une série de conférences pour les développeurs Swift. Chez Applidium nous avons envoyé trois de nos ingénieurs et voici leurs retours.

L’événement

La dotSwift se tenait au Théâtre des Variétés, en plein coeur de Paris. Il est rare que de tels événements soient organisés à Paris, c’est pourquoi nous étions ravis de pouvoir y assister, d’autant plus dans un lieu si singulier.

Durant l’après-midi il y a eu trois sessions d’une heure, suivies de pauses d’une demi-heure utiles pour engager la discussion avec les autres participants ou profiter du buffet.

La seconde session était constituée de lightning talks, des interventions très courtes de cinq à dix minutes. Cela a permis à un grand nombre d’intervenants de se succéder sur scène. Les lightning talks sont une bonne opportunité pour les développeurs de présenter un sujet qui ne couvrirait pas une présentation entière.

Les intervenants venaient de différents horizons. Certains étaient ingénieurs dans des entreprises renommées telles que Realm, IBM ou Microsoft, d’autres étaient des développeurs indépendants et nous avons même pu voir des gens impliqués dans le projet Swift open source. Daniel Steinberg, maître de cérémonie, introduisait les différentes conférences puis posait des questions aux intervenants à l’issue de leurs présentations.

Le contenu

Les présentations n’étaient pas toutes du même niveau. Certaines étaient à destination des plus novices, d’autres pour les développeurs plus expérimentés. C’est important que tout le monde puisse en retenir quelque chose.

Les vidéos des conférences ne seront pas disponibles avant quelques semaines, c’est pourquoi nous n’entrerons pas dans le détail de chacune mais nous allons plutôt faire un rapide résumé des différents sujets abordés.

La plupart des interventions portaient sur le langage Swift en lui-même et sur la façon d’utiliser ses fonctionnalités dans différents cas pratiques. Par exemple, comment se servir de la puissance des structs, comment faire un bon usage du Protocol Oriented Programming, etc.

Quelques présentations s’intéressaient à la compatibilité entre Swift et Objective-C. Comment éviter la propagation de NSObject ou comment se passer des méthodes du runtime Objective-C.

Une conférence détaillait l’utilisation de RxSwift. C’est un framework à la mode et Marin Todorov nous a fait un récapitulatif des fonctionnalités.

Enfin, deux interventions étaient dédiées à l’utilisation de Swift côté serveur. Ian Partridge, ingénieur IBM, était notamment présent pour en parler. Swift peut être exécuté sur Linux, mais il y a des limitations, comme par exemple le fait que certaines fonctionnalités de Foundation ne sont pas encore implémentées.

Ce que nous en avons pensé

En participant à la dotSwift nous avons remarqué que les sujets simples et classiques sur Swift se font rares. À la place ce sont davantage des situations concrètes qui sont présentées (design d’API, communication Bluetooth, etc.), ou de nouveaux usages et frameworks (RxSwift, Swift côté serveur).

Nous pensons que cela témoigne à la fois d’une maturité du langage mais aussi de la communauté.

Depuis que Swift est devenu open source, le langage n’a cessé de prendre de l’ampleur et la communauté est très investie. Chacun peut choisir de participer à son élaboration et c’est pourquoi nous pensons que c’est une garantie que le projet avance dans la bonne direction.

Ce qui est encore plus prometteur, c’est la volonté d’Apple, et de la communauté en général, de porter Swift côté serveur. Les frameworks pour l’usage du langage sur les serveurs sont désormais nombreux. Nous pouvons citer Vapor (Logan Wright, le co-créateur était un des intervenants), Kitura (propulsé par IBM, le représentant Ian Partridge était présent pour en parler), Zewo, Perfect, etc.

Chez Applidium nous attendons avec impatience de voir comment vont évoluer ces technologies. Ian Partridge a émis l’idée que dans le meilleur des mondes nous pourrions développer deux backends : un en Swift qui communiquerait avec les applications iOS, et un en JavaScript qui communiquerait avec une application web frontend. D’après lui, cela influencerait la manière dont les équipes de développeurs travaillent, car les mêmes ressources pourraient être disponibles sur les deux plateformes (iOS et serveur), voire pourraient complètement partager du code source.

Nous sommes un peu sceptiques face à ces arguments, car nous voyons quelques limitations. Répliquer exactement les mêmes fonctionnalités entre deux langages différents (Swift et JS) par deux développeurs différents a de grandes chances d’aboutir à du code dupliqué et aux autres problèmes qui vont avec : introduction de bugs, différences subtiles entre les deux plateformes, mauvaise utilisation des ressources… De plus, même si l’équipe Swift travaille à la fois sur le frontend et sur le backend, partager du code peut être plus compliqué qu’il n’y paraît car les architectures et les modèles de données sont différents.

Pour le moment nous pensons qu’il est trop tôt pour utiliser Swift sur nos serveurs en production, mais nous gardons tout de même un oeil sur l’évolution de la technologie.

Les “solutions miracles”

Cette partie est une mention spéciale pour l’intervention de Roy Marmelstein qui nous a particulièrement marquée.

L’idée principale était que chaque fois qu’un nouveau sujet technique devient à la mode, nous nous empressons de l’essayer et nous avons tendance à vouloir l’utiliser un peu partout dans notre code. Nous pensons qu’il va agir comme une solution miracle et résoudre tous nos problèmes. Mais cela peut finir par engendrer d’autres difficultés, et il est parfois nécessaire de prendre un peu de recul pour se rendre compte que ce n’était pas une si bonne idée et qu’il faudrait faire marche arrière.

Il mentionnait spécifiquement trois “solutions miracles” :

  • Protocol Oriented Programming
  • RxSwift
  • Swift lui-même

En essence, le Protocol Oriented Programming est un outil très puissant et Apple l’utilise un peu partout dans sa librairie standard. Il y a même eu une conférence dédiée à la WWDC 2015. Mais de temps en temps il peut être sur-utilisé, ou utilisé dans des situations où cela n’a pas vraiment de sens.

RxSwift est attractif et simplifie grandement le flot de données. Mais la courbe d’apprentissage est plutôt raide et il faut un bon moment avant qu’une équipe de développeurs inexpérimentée puisse l’utiliser de manière efficace.

Le langage Swift en lui-même peut être vu comme une solution miracle mais il est encore en phase de développement et souffre de problèmes de compatibilité ABI ou de temps de compilation longs. Il y a des cas où le bon choix est d’utiliser Objective-C.

Ce que nous pouvons retenir de cette présentation, et de la dotSwift en général, c’est que tous ces nouveaux outils qui nous ont été présentés sont très puissants et peuvent vraiment nous aider à améliorer notre code. Mais chaque outil est utile dans un contexte particulier qu’il est important de connaître avant de l’utiliser.

Conclusion

Nous avons apprécié participer à la dotSwift car les conférences étaient intéressantes. A Applidium nous utilisons Swift tous les jours dans nos applications donc nous n’avons pas appris grand chose mais c’est toujours agréable de revenir le lundi matin au travail pour tester de nouvelles idées et de nouveaux patterns.

De plus c’est assez stimulant de rencontrer les intervenants en personne quand nous sommes habitués à les lires sur leurs blogs.

Nous serons à la dotSwift l’an prochain et nous espérons vous y voir également. Si vous voulez faire partie de l’écosystème Swift nous avons des opportunités à vous proposer et nous serions ravis de vous les présenter.

Nous sommes toujours à la recherche de personnes compétentes.

Rejoignez-nous!
logo business unit

APPLIDIUM

Nous développons des services mobiles innovants. Applidium est une agence à fortes composantes design et technologique, spécialisée dans la mise en place de produits mobiles innovants et industriels.

à lire