[Index Software] Coin des développeurs :]

[Tugdual]

C++ vs Rust :

• une comparaison pratique de la vitesse de compilation et de test...

[Bubu]

ok Bon. Je trouve qu'il y a beaucoup trop de sériosité dans cette page.
Attention, car si ça continue ça va ruer dans les pancartes. Je ne le dirais pas deux fois. C'est moi que je vous le dis !
Si ca vous fait peur, un molassique de 10 grammes veut vous la faire qu'a la peu jusqu'à réveiller l'embryon qui sommeille en vous .
Le problème est le toggleable button. Il est enclenché ou déclenché. Il peut rester appuyé quand on relâche le doigt.


Pour le désactiver, il faut appuyer à nouveau dessus.

[lucius]

C++ vs Rust :

• une comparaison pratique de la vitesse de compilation et de test...

Cela fait bien longtemps que l'on parle d'un successeur au C++. Il y a eu java, le langage D, Carbon...

Mais tant que 2 conditions ne seront pas remplies, cela restera C++ qui dominera:
-Une évolution complète des architectures (exemple passer de bit à qubit comme dans les ordinateurs quantiques)
-La faiblesse du nombre d'API et de libs incontournables (linux, unix, windows) dans un autre langage comme Rusy. Rust ne peut utiliser de libs c++ directement sans utiliser un binding (de langage) à ma connaissance (lorsque je m'y suis intéressé à l'époque).

Rust a des avantages face au C++ mais des projets en cours vieux de 10-15 ans et des gens formés à C++ pousseront les gens à rester vers le C++ au lieu de prendre des risques. Porter du code C++ vers Rust coûte horriblement cher (en temps, outils, procédures, validation, tests unitaires, tests NR...). La crainte de l'absence d'une totale portabilité peut décourager.

[Tugdual]

Il y a une pression de grand acteurs pour l'adoption de Rust : Amazon, Google, Microsoft, Linux...

Il semble également que ces acteurs n'envisagent pas un remplacement rapide, mais une transition progressive.

[lucius]

Je sais mais actuellement Rust part dans un écosystéme favorable au C++ et même Java.

Il faut surtout trouver un financement et du temps pour convertir pas mal de libs en Rust afin d'encourager certains à faire la transition.

[Bubu]

Je travaille sous Android Studio, qui utilise JVM (Java Virtual Machine), et depuis la dernière MAJ, Android Studio ne trouve pas la machine virtuelle Java.
J'ai réinstallé AndroidStudio, le JDK (Java Développement Kit), et rien à faire, j'ai une erreur dès le lancement d'Android Studio.

Il me dit qu'il ne trouve pas la MV Java et qu'il faille que je modifie les variables d'environnement JAVA dans le système.


je suis sous Windows, et je recherche jvm.dll. Donc je bidouille, j'ai l'intention de copier le fichier dans l'arborescence mentionée.

[Tugdual]

Capital One supprime :

• tous les profils Agile de ses effectifs...

Extrait :

Après de nombreuses années d'investissement dans les méthodes Agile pour amorcer "convenablement" sa transformation numérique, Capital One pense désormais à réorganiser ses équipes et se sépare des professionnels en méthodes Agile. Une personne au courant de l'affaire a déclaré à Bloomberg que plus de 1 100 employés ont été touchés par cette décision. Ces travailleurs ont été invités à postuler pour d'autres postes au sein de la banque, des centaines de postes étant ouverts dans toute l'entreprise.

[...]

À la place, les ingénieurs et les chefs de produit devront utiliser naturellement les routines Agile. « Le rôle Agile dans notre organisation technique était essentiel pour nos premières phases de transformation, mais à mesure que notre organisation mûrissait, la prochaine étape naturelle était d'intégrer les processus de livraison Agile directement dans nos pratiques d'ingénierie de base », a déclaré Capital One.

[...]

Erik Meijer, un développeur de l’écosystème .NET disait il y a quelques années : « la méthodologie Agile est un cancer que nous devons éliminer de l’industrie ». Ron Jeffries, expert de l'industrie et signataire du Manifeste Agile, est de cet avis.

Jeffries estime qu’il est temps de passer à autre chose. Il conseille aux développeurs d’abandonner les méthodes Agile. Selon lui, ce n'est pas les méthodes qui sont en cause, mais plutôt la manière dont elles sont appliquées. Dans le même ordre d'idée, Andy Hunt, un autre signataire du Manifeste Agile en 2021, n'a pas non plus caché sa déception. Pour lui, Agile n'a pas atteint les objectifs escomptés au départ.

[...]

Certains développeurs voient également dans la méthodologie Agile un "problème qui pourrait conduire les entreprises technologiques vers une dette technique plus importante".

[...]

« La dette technique n'est évidemment pas limitée aux équipes qui s'appuient sur la méthodologie Agile, et il y a de fortes chances que ces points s'appliquent à de nombreuses équipes qui se basent sur l'approche Waterfall, bien que dans une mesure différente. Quoi qu'il en soit, toutes les équipes sont aujourd'hui tenues d'aller plus vite. Qu'elles s'efforcent de devenir agiles ou qu'elles se battent pour demeurer dans l'approche Waterfall, lorsque vous allez plus vite, la dette technique s'accumule », a conclu Don Clos.

[lucius]

Les méthodes agiles ont été survendus au point que cela est devenu une plaie pour beaucoup. On en met partout alors que pour beaucoup de projets, il vaudrait mieux rester en waterfall (ou en cycle en v) si on avait une véritable analyse en amont (durée du projet, exigences très définies du client et du projet). Trop de gens sont devenus des adeptes de Scrum, XP, voir kanban.

Sans compter l'utilisation de BDD ou de TDD
Et le plus drôle c'est les conflits entre eux. Certains disent que Scrum n'est pas une méthode, d'autres disent que Kanban ne l'est pas et que c'est une approche visuelle.

Cela apporte plus de conflits.

[lucius]

Avec un proche qui est Scrummaster, il dit sans cesse faire du Scrum.
Mais en général, la plupart des projets font du Scrum-like.

[lucius]

Connaissez-vous le software craftsmanship?

Explications:



Mais attention aux dérives:

[Tugdual]

Je ne connaissais pas.

Après avoir regardé la première vidéo, je dirais que ça ressemble à ce que j'ai connu.

Je vais regarder la seconde...

[lucius]

être craftman, être en projet agile (même si on n'en a pas besoin), utiliser la dernière techno, faire du DevOps... On pousse les codeurs à faire n'importe quoi pour donner l'illusion de rester dans la course de l'innovation et de la compétitivité.
Par contre, des trucs de base sont zappés faute de temps car on se lance dans des trucs que l'on ne maitrise pas.

Par exemple, on ne prend pas assez en compte les tests alors que indispensables à anticiper et créer en phases de conception. On manque d'intégrer à des équipes un responsable des tests surtout dans les phases de conception par contre il faut absolument avoir dans une équipe un Scrum Master et un devops Lorsque l'on pense à créer les différents types de tests, c'est avec un temps de retard.
Même le TDD est plus spécifique par un cycle plus court (grosso modo écriture test-écriture code- vérification) que dans un cycle en V mais certains préfèrent passer au BDD. On zappe trop souvent le TDR

[Lilas]

Honnêtement, je ne comprends rien à tout ces sigles et ne sais absolument pas de quoi on parle.

Pour moi, la recette n'a pas changé depuis 20 ans :
- analyse fonctionnelle
- analyse technique
- développement
- tests
- validation
- mise en production
- service après-vente

Pas de méthode particulière et pas de responsable de ci ou de ça : à part la validation, c'est moi qui fait tout.
Et tout le monde en est satisfait, moi la première.

[Bubu]

C'est pour gueuler, mais vu qu'il s'agit de programmation, je poste ici.
Je suis aux prémices du développement d'un jeu de Sudoku pour Android, mais leur dernière version est inutilisable.
J'ai réinstallé AndroidStudio, j'ai rajouter des clés JAVA_HOME et cela ne change rien.

Je crois que je vais patienter avec sagesse leur prochaine version.

En attendant, je ne peux plus développer.

Le truc vraiment aberrant, c'est qu'il me dit (dans un dossier) que le fichier jvm.dll n'existe pas. Alors que si! La dll est bien là!

[lucius]

Honnêtement, je ne comprends rien à tout ces sigles et ne sais absolument pas de quoi on parle.

Pour moi, la recette n'a pas changé depuis 20 ans :
- analyse fonctionnelle
- analyse technique
- développement
- tests
- validation
- mise en production
- service après-vente

Pas de méthode particulière et pas de responsable de ci ou de ça : à part la validation, c'est moi qui fait tout.
Et tout le monde en est satisfait, moi la première.

Je comprends. Il y a des années, j'avais cherché un livre complet pour un proche qui explique le SDLC (cycle de développement) mais je n'ai pas trouvé de bon livre.
il y a quelques mois, j'ai rejeté un coup par curiosité. toujours rien.
Entre le client (MOA), le prestataire (MOE) et le chef de projet beaucoup ne savent pas qui doivent faire quoi. Sans compter que je n'ai jamais réellement vu de livre qui explique de manière compréhensible par des exemples la partie documents à remplir. Beaucoup de livres parlant de tests logiciels sont incapables d'exprimer les tests de manière compréhensibles . Je suis tombé sur un bouquin sur le génie logiciel qui ne parlait que d’algorithmes, codes structures de données, langages... mais rien sur le génie logiciel.
En même temps les bouquins sur leur équivalent en électronique pour la conception d'un composant sont inexistants.