c'est surtout la mise en place du management chez github (qui avait auparavant une structure hiérarchique très plate) qui a permis ça.
Ça m'intéresse ça, tu aurais des liens ?
En fait je me demande en quoi rajouter du management fait que des features sortes ? C'est hyper intéressant comme question (d'autant plus que je suis dans une boite ultra plate ;-) ).
Un peu comme la dépêche qui dit "Notons que GitHub a vite réagi et propose maintenant une fonctionnalité ressemblante", j'aimerais bien une source qui indique c'est en réaction. Certes côté timing c'est quasi en même temps, presque trop pour que ce soit une réaction justement.
Maintenant ces remarques n'enlèvent pas le fait que c'est une bonne chose qu'il y ait de la concurrence, ça force toujours à aller un peu plus loin. Et gitlab garde une avance avec leur CI pour le moment.
Le Branching by Abstraction je ne crois pas que ce soit autre chose qu'une vue de l'esprit. Je n'ai jamais vu des gens en faire pour de vrai. Je pense que c'est trop complexe pour véritablement être mis en place.
Je suis tristesse de l'avoir mis en place plusieurs fois avec succès alors :-(
Pour donner un peu une idée : le soft était une app mobile, multiplateforme, de pilotage de drones. On a du, plusieurs fois, réaliser de gros chantiers dans l'app tout en continuant à ajouter des features. Et quand je dis gros chantiers c'est aussi chantiers critiques, genre refonte totale de tous les checks fait avant le décollage, refonte de tout le mécanisme de détection de problème en vol. Un poil sensible.
Et le problème c'était surtout que chacun de ses taffs dépassaient une itération de boulot. Hors on avait besoin d'avoir des versions utilisables à chaque itération.
La solution classique c'est de faire une branche, qui va durer le temps qu'il faut, et qui sera mergée un jour. C'est hyper fatiguant. Encore plus quand, durant les refactorings un autre dev doit ajouter des features utilisant la partie refactoré (par exemple ajout d'un nouveau check avant décollage). Et il n'est pas question de le faire attendre plusieurs semaines.
Donc tout s'est passé suivant du Branching by Abstraction. J'ai pu introduire une couche de compatibilité très rapidement, puis développer une nouvelle archi en parallèle (dans master pour simplifier un poil). Pendant un temps d'ailleurs les deux archi ont coexisté, puis tout l'existant a été converti sur la nouvelle archi, l'ancienne n'étant alors qu'une coquille vide elle a disparu. Tout c'est fait avec des branches de courtes durée (pour avoir de la review) et mergé dans master. Ainsi, alors que le boulot n'était pas fini et simplement désactivé par un ifdef, des versions utilisables était toujours présentes.
L'un des gros avantages (qui est commun aux features branches et qui contredit _ il n'y a pas de différence notable entre un mec qui développe dans son workspace sans soumettre son code et sans mettre à jour sa base de code et le feature branche_) est que le code de la nouvelle feature, bien que partiellement désactivé en prod, était dans la CI, les tests se jouaient dessus en permanence, tout le monde utilisait la nouvelle abstraction. Ce qui fait d'ailleurs que la transition old->new fut simple et avec beaucoup moins de risques que si on avait fait une branche qui avait existé pendant 3-4 semaines.
Si je me trompe pas, je crois même que je peux légalement copier la partie serveur du projet, faire des modifications et en faire un site/application close source.
Non.
Ce que tu peux faire c'est prendre le code, le modifier, le mettre en ligne (l'exécuter) sur un serveur et personne ne peut exiger d'avoir accès à tes modifications. Au contraire un programme que tu compilerais et que l'utilisateur exécuterait sur sa machine, ici ça s'exécuterait sur le serveur et l'utilisateur ne fait que consommer le résultat, d'où le fait qu'il n'ait pas de droits dessus.
Et donc justement dans ce cas, GPL ou BSD/MIT ça ne change pas grand chose.
Rien que pour npm ou la gestion de l'asynchrone js (callback ou promises — quelle implémentation d'ailleurs ?) est aujourd'hui assez affreux.
Quand j'ai besoin de faire du js côté serveur je le fais maintenant au maximum en clojurescript…
Mais oui, techniquement, la GPL oblige à fournir les sources lors de toute diffusion des binaires.
Absolument pas.
La GPL permet à un utilisateur du logiciel (du binaire par exemple) de demander les sources. Et l'éditeur du logiciel doit les fournir, il a même le droit de faire payer l'utilisateur pour ça.
Qu'est ce qui n'est pas user friendly sur un android ? Tu as une notification, ça te dis qu'il vaut mieux faire ça sur du wifi et avoir de la batterie et ça reboot. Quelle est vraiment la différence ?
Une banque ou GDF va demander à ta grand-mère d'installer un raspberry pi chez elle ou de souscrire un abonnement sur cozycloud.com pour pouvoir échanger des données ?
J'irais même plus loin : si le CTO ne s'intéresse pas au business, c'est un mauvais CTO. Le truc c'est que y'a pas mal de dév/ingés qui croient que monter une startup c'est juste "faire le même métier, en travaillant un peu plus et devenir millionnaire".
En fait ça devrait même être la préoccupation de tout le monde dans la boite, non ? Ça ne veut pas forcément dire avec la même énergie dessus (ni forcément le même pouvoir), mais tout le monde devrait s'y intéresser.
lorsqu'on monte une boîte, on est une équipe soudée pour un objectif donné : que la boîte marche. Les autres objectifs (richesse, liberté, qualité de vie, satisfaction du travail fourni, de changer le monde, etc) sont des objectifs individuels, que chacun atteindra comme il l'entend, avec les moyens qui lui correspondent.
Ces autres objectifs ne peuvent-t-ils pas entrer aussi dans la définition de la boite ? Changer le monde, satisfaction du travail fourni, qualité de vie sont au moins des objectifs qui peuvent être portés par la boite, voir même portés comme des moyens permettant d'arriver à l'objectif de faire marcher la boite.
Ben s'il l'a co-fondé et qu'il est DG-CTO un peu quand même.
je sais qu'il y a d'autres raisons dans le vie de virer qqu'un que de vouloir mettre le beau-frère de la voisine qui est un gros branleur mais à quoi on n'a pas pu trouver de place au ministère
Ok, compris le prob. En fait la seule qu'on a introduite c'est Go. On est sur une app web, finalement Java et Python auraient été encore plus loin, alors que js on l'utilise déjà (ok non, coffee).
Parce que la notion de microservice c'est un nom à la mode pour parler de quelque chose qui se faisait déjà avant en plus poussé
Toutafé.
D'ailleurs, là j'explique le résultat, dans les étapes c'est pas ça.
Pour l'histoire, au début une bonne partie de nos traitements (miniatures par ex) était dans notre app Rails (monolithique on peut dire). Puis quand ça a fait mal, plutôt que de chercher à scaler une app juste pour une portion très identifiable, on a sorti cette portion et on s'en est occupé à côté : changer de langage (ruby -> js) et de plateforme d'exécution (rails -> AWS Lambda).
C'est ainsi que ça devrait toujours être fait, il ne faut juste pas avoir peur de sortit des briques. Mais c'est différent que de vouloir absolument tout sortir et de ne plus être capable de gérer la communication. C'est un peu la même histoire que linux vs minix d'ailleurs :-D
Sincèrement tu semble être entrain de nous dérouler la planche publicitaire des microservices sans le moindre recul.
-_-'
Sérieux, soit j'ai vraiment écris de la merde soit tu as tout lu de travers.
A aucun moment je n'ai introduit la notion de microservices (c'est toi ici avec Se la jouer « on fait du microservice donc on peut faire ce qu'on veut » je te le laisse volontiers.) et l'app dont je parle n'est pas en microservices. Certaines briques sont extraites dans des services dédiés et ça, ça fait des années et des années que ça se fait. Ce n'est pas pour autant une archi à base de microservice. Mais extraire les parties qui posent problème c'est la base d'une archi web. C'est d'ailleurs ce que tu fais quand tu stock tes datas dans une base de donnée. Là c'est la même chose mais pour des unités de calcul, rien de magique là dedans, rien de microservicebullshit non plus.
Et franchement (oui je sais tu vas encore mal le prendre) faire un service Go de quelques centaines de lignes alors que tu sais écrire du Java/Ruby/PHP c'est vraiment dans le domaine du normal. C'est un peu le principe du développement. Personne ne demande à être hyper calé, ni à connaître sur le bout des doigts ce langage, cette plateforme. Par contre introduire des changements — genre langage — isolés, à la marge est une vrai méthode pour tester en condition réelle de nouvelles façon de faire, nouveaux langages, etc. Si ça ne marche pas il se passe quoi ? On passe une ou deux journées à réécrire en ruby et on aura appris déjà pas mal de choses. Et si ça marche on pourra augmenter la connaissance et l'utiliser plus la prochaine fois.
Le truc c'est que tu caricature à mort un discours qui était, je le rappel, de dire que c'est pas Java qui fait que ton appli va scaler mais ton design et qu'avec un bon design tu t'affranchis grandement des problématiques de langages, framework, plateforme ou autre.
Ça pousse juste à faire n'importe quoi par excès de confiance (« non mais quelques centaines de go je sais faire », « mais il n'y a que les nuls qui tombent dans les pièges des langages », « apprendre un nouveau langage ? 1/2 journée maximum »,…).
Nan mais t'es sérieux ?
Oui je pense qu'un dev doit être en capacité d'apprendre d'autres langages, ne serait-ce que pour être meilleur dans son langage de prédilection. Ça ne veut pas dire que ça prend 1/2 journée, ni ne parle de nuls ou autre.
Je n'ai fais que reprendre ce que tu as dis hein ?
Pas vraiment non, tu extrais bien juste ce que tu veux mais pas de prob, c'est le jeux ma pauv' Lucette ;-)
Se la jouer « on fait du microservice donc on peut faire ce qu'on veut » je te le laisse volontiers
Clairement non, je ne dis pas que je peux faire ce que je veux je dis que l'isolation fournie par des services me permet de ne pas avoir des contraintes de plateforme/langage. Et donc je peux intégrer d'autres dimensions dans mes choix, ce que tu ne peux pas faire si tu reste monolithique. Et prendre une brique pour tester en prod un langage qui n'était pas dans la stack (Go, fun, toussa) est clairement un choix intéressant.
Mais ces choix sont plus compliqué que ça. Ce n'est pas une question de geek, dans le choix, la pérennité de la techno et la gestion de vos compétences sont vraiment à prendre en compte.
Bien sur que c'est plus compliqué, sauf que dans un cas tu n'as simplement pas de choix.
Gestion des compétences de quoi ? Pour écrire un service Go de quelques centaines de lignes ? Soyons sérieux, n'importe quel développeur devrait être en capacité de le faire. Pérennité de quoi ? Go et Javascript ? Je pense que c'est pas trop mal à ce niveau.
A l'inverse, je n'ai pas vu une seule personne dire ce projet critique, il faut le faire en Go ou Rust.
Pourtant pas mal de monde parie (utilise aujourd'hui je ne sais pas) sur Rust pour écrire du code un peu plus sûr.
Et des projets critiques (bon après on peut définir critique aussi) en Go j'ai l'impression qu'il y en a pas mal, surtout pas mal de services backend, d'outils, cli, etc.
il n'est pas fun, car omniprésent en entreprise
Ce n'est pas parce qu'il est omniprésent en entreprise qu'il n'est pas fun, c'est parce que c'est un langage pauvre, pas très intéressant, assez verbeux. La JVM est pas mal par contre, ça marche bien, les perfs sont intéressantes.
Kotlin c'est sympa, mais ça montre juste ce que devrait être java en fait. Un peu comme quand Google sortait guava, guice, etc et que ça a fait un peu bouger l'ecosystème basé sur les libs apaches.
Le revers de la médaille pour kotlin (de mon point de vue) c'est que c'est juste java en mieux, mais pas assez pour me donner envie. Sauf dans le cas d'Android où je le testerais bien.
Qu'est ce qui n'est pas mature ? Faire du REST en Go par exemple ? Ça veut dire quoi mature ?
Pour la gestion des dépendances, je ne dirais pas que c'est pas mature. C'est sur que c'est loin de maven, mais c'est plutôt une bonne chose :-D
Franchement il suffit juste d'essayer. Genre durant les 6 mois qui viennent apprenez Go, les 6 mois suivant Clojure, ensuite Rust, puis …
C'est le meilleur moyen de voir ce qui est mature ou non, productif ou non, rapide ou non, et d'ensuite pouvoir faire des choix qui dépassent la techno qu'on maitrise et les dires des autres.
[^] # Re: Réaction de Github
Posté par CrEv (site web personnel) . En réponse à la dépêche GitLab 8.11 : vue kanban et bien plus . Évalué à 2.
Ça m'intéresse ça, tu aurais des liens ?
En fait je me demande en quoi rajouter du management fait que des features sortes ? C'est hyper intéressant comme question (d'autant plus que je suis dans une boite ultra plate ;-) ).
[^] # Re: Réaction de Github
Posté par CrEv (site web personnel) . En réponse à la dépêche GitLab 8.11 : vue kanban et bien plus . Évalué à 3.
C'est pas plutôt en réaction à https://github.com/dear-github/dear-github ?
Un peu comme la dépêche qui dit "Notons que GitHub a vite réagi et propose maintenant une fonctionnalité ressemblante", j'aimerais bien une source qui indique c'est en réaction. Certes côté timing c'est quasi en même temps, presque trop pour que ce soit une réaction justement.
Maintenant ces remarques n'enlèvent pas le fait que c'est une bonne chose qu'il y ait de la concurrence, ça force toujours à aller un peu plus loin. Et gitlab garde une avance avec leur CI pour le moment.
[^] # Re: Config recommandée
Posté par CrEv (site web personnel) . En réponse à la dépêche GitLab 8.11 : vue kanban et bien plus . Évalué à 2.
C'est un peu plus que ca, non ?
Et d'ailleurs, avec ou sans mattermost ?
[^] # Re: Kanboard ou kanban?
Posté par CrEv (site web personnel) . En réponse à la dépêche GitLab 8.11 : vue kanban et bien plus . Évalué à 4.
Oui, c'est un board kanban si on veut, mais kanboard est un logiciel. D'ailleurs ils appellent ça "issue board" dans les release notes de gitlab.
[^] # Re: Workflow git
Posté par CrEv (site web personnel) . En réponse au journal Git Rev News: la newsletter de Git, et sondage pour utilisateurs de Git. Évalué à 3.
Je suis tristesse de l'avoir mis en place plusieurs fois avec succès alors :-(
Pour donner un peu une idée : le soft était une app mobile, multiplateforme, de pilotage de drones. On a du, plusieurs fois, réaliser de gros chantiers dans l'app tout en continuant à ajouter des features. Et quand je dis gros chantiers c'est aussi chantiers critiques, genre refonte totale de tous les checks fait avant le décollage, refonte de tout le mécanisme de détection de problème en vol. Un poil sensible.
Et le problème c'était surtout que chacun de ses taffs dépassaient une itération de boulot. Hors on avait besoin d'avoir des versions utilisables à chaque itération.
La solution classique c'est de faire une branche, qui va durer le temps qu'il faut, et qui sera mergée un jour. C'est hyper fatiguant. Encore plus quand, durant les refactorings un autre dev doit ajouter des features utilisant la partie refactoré (par exemple ajout d'un nouveau check avant décollage). Et il n'est pas question de le faire attendre plusieurs semaines.
Donc tout s'est passé suivant du Branching by Abstraction. J'ai pu introduire une couche de compatibilité très rapidement, puis développer une nouvelle archi en parallèle (dans master pour simplifier un poil). Pendant un temps d'ailleurs les deux archi ont coexisté, puis tout l'existant a été converti sur la nouvelle archi, l'ancienne n'étant alors qu'une coquille vide elle a disparu. Tout c'est fait avec des branches de courtes durée (pour avoir de la review) et mergé dans master. Ainsi, alors que le boulot n'était pas fini et simplement désactivé par un ifdef, des versions utilisables était toujours présentes.
L'un des gros avantages (qui est commun aux features branches et qui contredit _ il n'y a pas de différence notable entre un mec qui développe dans son workspace sans soumettre son code et sans mettre à jour sa base de code et le feature branche_) est que le code de la nouvelle feature, bien que partiellement désactivé en prod, était dans la CI, les tests se jouaient dessus en permanence, tout le monde utilisait la nouvelle abstraction. Ce qui fait d'ailleurs que la transition old->new fut simple et avec beaucoup moins de risques que si on avait fait une branche qui avait existé pendant 3-4 semaines.
[^] # Re: Licence GPL ?
Posté par CrEv (site web personnel) . En réponse à la dépêche L'Air du Bois devient Open Source !. Évalué à 2.
Non.
Ce que tu peux faire c'est prendre le code, le modifier, le mettre en ligne (l'exécuter) sur un serveur et personne ne peut exiger d'avoir accès à tes modifications. Au contraire un programme que tu compilerais et que l'utilisateur exécuterait sur sa machine, ici ça s'exécuterait sur le serveur et l'utilisateur ne fait que consommer le résultat, d'où le fait qu'il n'ait pas de droits dessus.
Et donc justement dans ce cas, GPL ou BSD/MIT ça ne change pas grand chose.
[^] # Re: On en a vraiment besoin ?
Posté par CrEv (site web personnel) . En réponse au journal Tout simplement E P I Q U E. Évalué à 2.
Tu veux dire les conférences avec des développeurs, devops et autre ?
[^] # Re: Stop avec le RapberryPI
Posté par CrEv (site web personnel) . En réponse à la dépêche Donnez votre avis sur la nouvelle architecture de Cozy. Évalué à 1.
Je suis certains que l'équipe de Cozy se fera un plaisir d'étudier voir d'intégrer tes contributions ;-)
[^] # Re: Go!
Posté par CrEv (site web personnel) . En réponse à la dépêche Donnez votre avis sur la nouvelle architecture de Cozy. Évalué à 10.
Rien que pour npm ou la gestion de l'asynchrone js (callback ou promises — quelle implémentation d'ailleurs ?) est aujourd'hui assez affreux.
Quand j'ai besoin de faire du js côté serveur je le fais maintenant au maximum en clojurescript…
Dernière tranche de lol sur npm :
# Go!
Posté par CrEv (site web personnel) . En réponse à la dépêche Donnez votre avis sur la nouvelle architecture de Cozy. Évalué à 9.
Je note le passage à Go et je trouve ça vraiment cool!
En tout cas personnellement ça me donne beaucoup plus envie que de développer du backend en js.
Et l'idée de passer en multi-utilisateur me plait bien :-)
[^] # Re: Mauvaise licence, changer licence
Posté par CrEv (site web personnel) . En réponse au journal Faut-il défendre la GPL devant les tribunaux ?. Évalué à 6.
Absolument pas.
La GPL permet à un utilisateur du logiciel (du binaire par exemple) de demander les sources. Et l'éditeur du logiciel doit les fournir, il a même le droit de faire payer l'utilisateur pour ça.
[^] # Re: Espoir..
Posté par CrEv (site web personnel) . En réponse à la dépêche Appel de wallabag aux fabricants de liseuse. Évalué à 2.
Il doit bien encore y avoir des gens qui lisent linuxfr chez tea, non ?
[^] # Re: Java ou JS ?
Posté par CrEv (site web personnel) . En réponse à la dépêche Les coulisses du standard C++. Évalué à 8.
A priori c'est bien javascript : http://tsdr.uspto.gov/#caseNumber=75026640&caseType=SERIAL_NO&searchType=statusSearch
[^] # Re: Amical pour l'utilisateur ?
Posté par CrEv (site web personnel) . En réponse au journal 1 an sous Ubuntu Phone. Évalué à 5.
Qu'est ce qui n'est pas user friendly sur un android ? Tu as une notification, ça te dis qu'il vaut mieux faire ça sur du wifi et avoir de la batterie et ça reboot. Quelle est vraiment la différence ?
[^] # Re: Vision stratégique
Posté par CrEv (site web personnel) . En réponse au journal Cozy cloud, maif et licenciement du CTO???. Évalué à 10.
EDF installe bien un linky chez les particuliers…
[^] # Re: Tweet déjà trompeur
Posté par CrEv (site web personnel) . En réponse au journal Cozy cloud, maif et licenciement du CTO???. Évalué à 1.
En fait ça devrait même être la préoccupation de tout le monde dans la boite, non ? Ça ne veut pas forcément dire avec la même énergie dessus (ni forcément le même pouvoir), mais tout le monde devrait s'y intéresser.
Ces autres objectifs ne peuvent-t-ils pas entrer aussi dans la définition de la boite ? Changer le monde, satisfaction du travail fourni, qualité de vie sont au moins des objectifs qui peuvent être portés par la boite, voir même portés comme des moyens permettant d'arriver à l'objectif de faire marcher la boite.
[^] # Re: La cour des grands
Posté par CrEv (site web personnel) . En réponse au journal Cozy cloud, maif et licenciement du CTO???. Évalué à -9.
Ha mais en fait on était d'accord ? Pfiou l'espace d'un instant j'ai cru que ça n'était pas le cas ! ;-)
La phrase était à prendre dans son ensemble, pas besoin de faire autant de mal à ces pauvres petits insectes…
[^] # Re: La cour des grands
Posté par CrEv (site web personnel) . En réponse au journal Cozy cloud, maif et licenciement du CTO???. Évalué à 1.
Ben s'il l'a co-fondé et qu'il est DG-CTO un peu quand même.
Quelqu'un a parlé de ça ?
[^] # Re: migre
Posté par CrEv (site web personnel) . En réponse au journal Java (EE) Sapu cépalibre.. Évalué à 3.
Cool :-)
Ok, compris le prob. En fait la seule qu'on a introduite c'est Go. On est sur une app web, finalement Java et Python auraient été encore plus loin, alors que js on l'utilise déjà (ok non, coffee).
Toutafé.
D'ailleurs, là j'explique le résultat, dans les étapes c'est pas ça.
Pour l'histoire, au début une bonne partie de nos traitements (miniatures par ex) était dans notre app Rails (monolithique on peut dire). Puis quand ça a fait mal, plutôt que de chercher à scaler une app juste pour une portion très identifiable, on a sorti cette portion et on s'en est occupé à côté : changer de langage (ruby -> js) et de plateforme d'exécution (rails -> AWS Lambda).
C'est ainsi que ça devrait toujours être fait, il ne faut juste pas avoir peur de sortit des briques. Mais c'est différent que de vouloir absolument tout sortir et de ne plus être capable de gérer la communication. C'est un peu la même histoire que linux vs minix d'ailleurs :-D
[^] # Re: migre
Posté par CrEv (site web personnel) . En réponse au journal Java (EE) Sapu cépalibre.. Évalué à 2.
C'est vrai, c'est aussi un de leur problème mais je le comprend.
Javascript est pas mal sur ce point, non ?
[^] # Re: migre
Posté par CrEv (site web personnel) . En réponse au journal Java (EE) Sapu cépalibre.. Évalué à 3.
Ça va mieux ? Ça fait du bien ?
-_-'
Sérieux, soit j'ai vraiment écris de la merde soit tu as tout lu de travers.
A aucun moment je n'ai introduit la notion de microservices (c'est toi ici avec Se la jouer « on fait du microservice donc on peut faire ce qu'on veut » je te le laisse volontiers.) et l'app dont je parle n'est pas en microservices. Certaines briques sont extraites dans des services dédiés et ça, ça fait des années et des années que ça se fait. Ce n'est pas pour autant une archi à base de microservice. Mais extraire les parties qui posent problème c'est la base d'une archi web. C'est d'ailleurs ce que tu fais quand tu stock tes datas dans une base de donnée. Là c'est la même chose mais pour des unités de calcul, rien de magique là dedans, rien de microservicebullshit non plus.
Et franchement (oui je sais tu vas encore mal le prendre) faire un service Go de quelques centaines de lignes alors que tu sais écrire du Java/Ruby/PHP c'est vraiment dans le domaine du normal. C'est un peu le principe du développement. Personne ne demande à être hyper calé, ni à connaître sur le bout des doigts ce langage, cette plateforme. Par contre introduire des changements — genre langage — isolés, à la marge est une vrai méthode pour tester en condition réelle de nouvelles façon de faire, nouveaux langages, etc. Si ça ne marche pas il se passe quoi ? On passe une ou deux journées à réécrire en ruby et on aura appris déjà pas mal de choses. Et si ça marche on pourra augmenter la connaissance et l'utiliser plus la prochaine fois.
Le truc c'est que tu caricature à mort un discours qui était, je le rappel, de dire que c'est pas Java qui fait que ton appli va scaler mais ton design et qu'avec un bon design tu t'affranchis grandement des problématiques de langages, framework, plateforme ou autre.
Nan mais t'es sérieux ?
Oui je pense qu'un dev doit être en capacité d'apprendre d'autres langages, ne serait-ce que pour être meilleur dans son langage de prédilection. Ça ne veut pas dire que ça prend 1/2 journée, ni ne parle de nuls ou autre.
[^] # Re: migre
Posté par CrEv (site web personnel) . En réponse au journal Java (EE) Sapu cépalibre.. Évalué à 2.
Compatibilité avec quoi ?
[^] # Re: migre
Posté par CrEv (site web personnel) . En réponse au journal Java (EE) Sapu cépalibre.. Évalué à 1.
Pas vraiment non, tu extrais bien juste ce que tu veux mais pas de prob, c'est le jeux ma pauv' Lucette ;-)
Clairement non, je ne dis pas que je peux faire ce que je veux je dis que l'isolation fournie par des services me permet de ne pas avoir des contraintes de plateforme/langage. Et donc je peux intégrer d'autres dimensions dans mes choix, ce que tu ne peux pas faire si tu reste monolithique. Et prendre une brique pour tester en prod un langage qui n'était pas dans la stack (Go, fun, toussa) est clairement un choix intéressant.
Bien sur que c'est plus compliqué, sauf que dans un cas tu n'as simplement pas de choix.
Gestion des compétences de quoi ? Pour écrire un service Go de quelques centaines de lignes ? Soyons sérieux, n'importe quel développeur devrait être en capacité de le faire. Pérennité de quoi ? Go et Javascript ? Je pense que c'est pas trop mal à ce niveau.
[^] # Re: sondage
Posté par CrEv (site web personnel) . En réponse au journal Java (EE) Sapu cépalibre.. Évalué à 3.
Pourtant pas mal de monde parie (utilise aujourd'hui je ne sais pas) sur Rust pour écrire du code un peu plus sûr.
Et des projets critiques (bon après on peut définir critique aussi) en Go j'ai l'impression qu'il y en a pas mal, surtout pas mal de services backend, d'outils, cli, etc.
Ce n'est pas parce qu'il est omniprésent en entreprise qu'il n'est pas fun, c'est parce que c'est un langage pauvre, pas très intéressant, assez verbeux. La JVM est pas mal par contre, ça marche bien, les perfs sont intéressantes.
Kotlin c'est sympa, mais ça montre juste ce que devrait être java en fait. Un peu comme quand Google sortait guava, guice, etc et que ça a fait un peu bouger l'ecosystème basé sur les libs apaches.
Le revers de la médaille pour kotlin (de mon point de vue) c'est que c'est juste java en mieux, mais pas assez pour me donner envie. Sauf dans le cas d'Android où je le testerais bien.
[^] # Re: Go ?
Posté par CrEv (site web personnel) . En réponse au journal Java (EE) Sapu cépalibre.. Évalué à 4.
Qu'est ce qui n'est pas mature ? Faire du REST en Go par exemple ? Ça veut dire quoi mature ?
Pour la gestion des dépendances, je ne dirais pas que c'est pas mature. C'est sur que c'est loin de maven, mais c'est plutôt une bonne chose :-D
Franchement il suffit juste d'essayer. Genre durant les 6 mois qui viennent apprenez Go, les 6 mois suivant Clojure, ensuite Rust, puis …
C'est le meilleur moyen de voir ce qui est mature ou non, productif ou non, rapide ou non, et d'ensuite pouvoir faire des choix qui dépassent la techno qu'on maitrise et les dires des autres.