Optimisez vos développements de services web grâce à Swift
Consultant en développement iOS, Florent Morin partage dans cet article des conseils tirés de ses expériences dans des grands groupes.
Concevoir une app iOS qui s'appuie sur un écosystème logiciel ancien peut rapidement devenir une entreprise terriblement complexe et chronophage, source de perte de temps et donc d’argent. Faire communiquer une app mobile moderne avec une architecture remontant à plusieurs (dizaines) d'années ne coule pas de source en effet. Heureusement, l’écosystème Apple s’est organisé en conséquence. Découvrons ensemble comment un handicap peut se transformer en opportunité au sein d’une équipe mobile.
Comprendre le problème
Prenons l'exemple d'une banque, d'une assurance ou de n’importe quel grand groupe qui a pignon sur rue depuis des décennies. Cet exemple est le plus extrême, mais la problématique peut aussi rapidement s’appliquer aux start-ups malgré leur agilité naturelle.
Cette entreprise s’est probablement développée grâce à l’informatique des années 1960, avec les fameuses cartes perforées et le langage COBOL. Mais les systèmes COBOL, comme leurs développeurs, vieillissent irrémédiablement avec le temps : au sein de cette entreprise, on migre donc les systèmes vers le langage Java grâce à toutes sortes de ponts temporaires.
Je ne suis pas développeur, cet article était quasiment entièrement compréhensible malgré mon absence de connaissances dans le domaine.
Bravo! Super intéressant 😁
@Eratic
Merci 😊
Sympa des petits articles de vulgarisation d’enjeux dev d’un peu haut niveau 👍
Là nous sommes sur des enjeux sans doute absolument étrangers à beaucoup de lecteurs, cela devrait ouvrir l’esprit
@YetOneOtherGit
Merci. 😊
C’est en effet l’idée. Rentre compréhensible ce qui est parfois difficile à expliquer à des développeurs juniors, des développeurs non spécialisés ou même des non-développeurs.
S’il y a des sujets que vous souhaiteriez voir vulgarisés, il ne faut pas hésiter. On traitera en priorité les sujets les plus demandés. On l’a fait avec l’accessibilité. Et on a plein de sujets dans les tuyaux.
@FloMo
Il faudrait avoir des retours du lectorat non initié pour savoir ce qui passe et qu’elles sont les envies.
Le successeur de la carte perforée (+imprimante) n’est pas COBOL, c’est le terminal clavier+écran.
Pour rentrer un programme COBOL (ou Fortran, ou assembleur, ou un fichier client, ou une lettre à mémé), on utilisait un paquet de cartes.
Rien n’interdirait — sauf le bon sens — d’utiliser des cartes perforées pour un programme Java ou Swift.
Je trouve que le petit schéma cartes->Cobol->Java mélange les torchons et les serviettes. C’est comme si on faisait le Swift le successeur de la VT100.
En revanche, dans l’historique de ce qui a suivi COBOL, on pourrait citer les L4G (Natural, Pacbase...), j’ai vu des clients chez qui ça tourne encore. Et la pléthore de solutions techniques qui se greffent autour de ça (BO et consorts), chacune avec ses APIs et ses formats, et les jobs qui transfèrent constamment des données de l’un à l’autre.
@DahuLArthropode
Je dois avouer que je ne suis pas un expert COBOL. 😅
Je comprend les problématiques mais je n’ai pas une connaissance approfondie. Merci de la précision.
@FloMo
“Je dois avouer que je ne suis pas un expert COBOL. 😅”
Comme te le disais les cartes perforées et COBOL ne sont pas liées conceptuellement.
La photo que tu as choisie est un système de perforation, les cates perforées ne sont qu’un système physique de codage de l’information c’est totalement indépendant d’un langage de programmation et COBOl n’est en rien lié à elles.
Ils se trouvent juste qu’à l’apparition de COBOL est FORTRAN c’était la manière standard de coder l’information pour la;faire digérer par la machine rien de plus.
COBOL et FORTRAN sont encore en usages mais bien évidemment avec les même modalité d’usage que les autres langages depuis bien longtemps, la carte perforées totalement appartient au passé pas ces langage qui constitues encore une part conséquente de la base de code héritée et exploité de part le monde.
Pour l’anecdote une part conséquente des échanges financiers reposent toujours sur des solutions COBOL.
@YetOneOtherGit
"Pour l’anecdote une part conséquente des échanges financiers reposent toujours sur des solutions COBOL."
Je crois qu'il y a pénurie de talent pour ce langage (en cause la retraite et pas de remplaçant)
Ça a l’air intéressant mais étant complètement incompétant en développement, je dois avouer être bien largué à la lecture de cet article. Pour moi, les framework et API ne sont que des noms abstraits à un concept que j’ai du mal à appréhender...
Avec un tout petit plus de maîtrise de ces sujets, je comprendrais bien mieux le fonctionnement de toutes ces structures.
J’ai bien un sujet qui m’a toujours passionné, mais que je n’ai pas creusé: la synchronisation.
Il y a 20 ans j’avais créé une base de données généalogique sur les chiens terre-neuve avec 4D. A l’époque, on avait pas encore les services web. J’avais donc créé un site miroir sur internet en php/mysql qui permettait de donner accès aux internautes aux données disponibles. La première était une base sans redondance, la deuxième était un infocentre avec une seule table et des récurrences.
Mais je ne suis pas allé jusqu’à récupérer des données fournies par les internautes. Pas eu le temps...
Depuis, je ne développe plus, mais j’ai vu utiliser un logiciel de comptabilité partagé par 3 cabinets vétérinaires associés. Moi même, j’ai mes comptes sur mon imac, et j’ai un acces miroir sur mon ipad. J’ai aussi un logiciel de généalogie sur mon imac et mon ipad... or l’imac n’est pas toujours allumé, la bande passante de l’ipad est parfois capricieuse... comment gérer des informations saisies sur plusieurs terminaux chacun avec leur base de données miroir, parfois sur la même fiche et finir par obtenir une synchronisation avec éventuellement un fichier des incohérences....
Bon c’est vrai qu’aujourd’hui, on n’a plus l’inquiétude de la place que ça va prendre en mémoire et en disque dur 😝
@Sica
C’est un vrai sujet qui pose toujours autant de problèmes.
Personnellement, au niveau des technologies Apple, j’utilise Core Data pour stocker en local et CloudKit pour gérer la synchronisation. Ça automatise pas mal de choses.
Le summum si on a un projet « basique », c’est NSPersistentCloudKitContainer.
En gros, ça synchronise automatiquement les données Core Data dans CloudKit.
Il y a certaines limites, notamment par rapport au partage. Mais c’est vraiment puissant.
Et s’il y a des contraintes de performances réseau, Protocol Buffer peut faire des petites merveilles.
Belle vulgarisation, merci !
@ric_anto
😊