groumpf ... - Mot-clé - internetVous pouvez me faire des retours sur twitter denmakesmusic.2023-08-19T08:21:26+02:00urn:md5:5f4edc3aa25c2fe8c2dcc41ed6bc48aeDotclearL'informatique et les formulairesurn:md5:cfc4924407a030f46760b78356c95d6e2022-07-09T08:44:00+02:002022-07-09T08:44:00+02:00groumpfInternetinformatiqueinternetprogrammation <p>La semaine dernière j'ai suivi une formation sur Angular, le <q>framework</q> de développement d'applications WEB.<br /></p>
<p>A un moment donné est venu le sujet des formulaires. Vous savez les formulaires sont des écrans avec des champs de saisie et un bouton <q>Valider</q>. Cela peut servir à valider une commande par exemple, après avoir entré son nom, son numéro de carte bleue, son adresse etc. Ce sont tout simplement des abstractions informatiques des formulaires papiers.</p>
<p>Et donc les participants de s'extasier (j'exagère un peu) devant les facilités qu'offre Angular pour réaliser les formulaires.</p>
<p>Là je me suis souvenu que dans les années 90 (avant internet oui), j'avais des collègues qui passaient leurs journées à faire des formulaires sur un système qui s'appelait (de mémoire) SQL Forms et qui était proposé par Oracle pour fonctionner directement avec la base de données.
Je relève donc cette anecdote amusante à la formation en soulignant que fonctionnellement on n'avait pas beaucoup progressé puisque le même type de formulaire existait il y a 30 ans. Simplement le système de développement était différent, et je n'étais pas certain qu'il était beaucoup plus difficile comparé à Angular (qui me parait quand même assez complexe).
Que n'avais-je pas dit là !
Ils m'ont assuré que c'était beaucoup mieux maintenant étant donné que le formulaire n'accédait pas directement à la base de données. En gros l'architecture logicielle était mieux, il y avait des interfaces pour séparer les différentes <q>couches</q> etc. Je leur ai fait remarquer que tout cela étaient des considérations d'informaticien et que cela ne concernait pas l'utilisateur mais ils avaient un peu de mal à comprendre.
Ils étaient dans leur monde de développement logiciel, incapable de voir qu'un formulaire des années 90 remplissaient les mêmes fonctions qu'un formulaire des années 2020.</p>
<p>Tout cela pour dire quoi ?</p>
<p>Et bien je pense que l'informatique WEB est dans un égarement profond. Les informaticiens passent leur temps à refaire la roue et c'est particulièrement le cas dans le monde WEB. Ils ont presque oublié que le but de l'informatique est de rendre des services et sont obnubilés par des questions d'architecture, de compétition entre les <q>frameworks</q> (il en existe des dizaines qui font à peu près tous la même chose), d'élégance du code, oui les informaticiens sont des esthètes. Les <q>frameworks</q> deviennent assez vite obsolètes ou subissent une mode qui en fait parfois disparaître certains bien qu'ayant des qualités.</p>
<p>Le fait qu'il faille encore des jours de développement, à se prendre la tête avec des syntaxes compliquées, pour faire des formulaires, choses qui n'est pas si compliqué en soit, est assez symptomatique qu'en 30 ans on n'a pas beaucoup avancé. Et savoir le faire dans un système apporte peu d'aide quand on doit passer à un autre car il faut réapprendre. Il est difficile de capitaliser une expérience donc la durée de développement s'en ressent.</p>
<p>De nos jours, l'apparence de l'informatique donnée aux utilisateurs est beaucoup plus complexe que par exemple le Minitel que tout le monde était à peu près capable d'utiliser. Mais maintenant, les sites WEB sont très complexes et ont tendance à rebuter les utilisateurs qui ne les utilisent qu'occasionnellement.
Cela me fait aussi penser au système 3270 (de mémoire) utilisé dans les banques, entièrement en mode <q>texte</q>, et qui semblait d'un maniement très rapide et efficace, du moins pour les opérateurs de banques mais qui n'étaient pas forcément des informaticiens.</p>
<p>Évidemment, c'est une idée générale, tout cela peut être nuancé.</p>Appleturn:md5:38721a16242c38d7bda0dcbb5c3d4deb2015-10-17T19:31:00+02:002015-12-03T14:41:03+01:00groumpfInternetinformatiqueinternetjavaprogrammation <p>Quand je lis ce <a href="http://www.gwtproject.org/doc/latest/DevGuideSecurity.html" hreflang="en">document</a> de Google sur les problèmes de sécurité avec les applications Web, je me dis que les Applets ont été écartées pour de mauvaises raisons.<br />
Certes je ne suis pas un spécialiste en sécurité mais Google lui-même indique que l'utilisation massive d'AJAX a créé des failles de sécurité qui n'existaient pas avant avec des sites plus classiques. Et Google est un des plus actifs promoteurs des applications AJAX.<br />
Par ailleurs ce qu'ils appellent <q>Same-Origin Policy</q> a été copié de ce qui avait été introduit par les Applets (en quelle année ? 1998 ?). De même le problème d'injection de code par des entrées utilisateurs n'est pas possible en Applets puisque l'application n'est pas faite en HTML/JS/JSON. C'est du Java. On peut difficilement imaginer saisir dans un formulaire du code Java en espérant qu'à l'affichage il va s'exécuter.<br />
Je ne dis pas qu'il n'y a pas de failles dans les Applets mais je pense que ce ne sont pas des failles introduites par un mauvais codage alors qu'en HTML/AJAX/JS c'est le cœur du problème.<br />
En fait on peut considérer que la plupart des sites ont des failles dues à une méconnaissance des problèmes de sécurité.<br />
Bref tout cela me fait dire qu'avec HTML/AJAX/JS on a fait un bon en arrière incroyable en promouvant des technologies qui n'étaient pas adaptées pour faire des applications solides. D'ailleurs le nombre de frameworks qui existent dans ce domaine indique que ces technologies en sont au stade du prototype et que chacun cherche désespérément à combler les lacunes d'un système de développement bancal.<br />
En fait - parenthèse - tout ce temps perdu me donne à penser que la concurrence exacerbée est vraiment un mauvais système. Au contraire une coopération entre les différents acteurs aurait abouti beaucoup plus rapidement (en théorie) à produire les fonctions manquantes sur les systèmes existant, en l’occurrence Java puisque c'est le sujet. L'idéologie des USA nous a entrainé dans des errements dont on n'est pas encore sorti.<br />
Parallèlement Java est depuis longtemps une technologie aboutie et il aurait juste fallu corriger les quelques choses qui n'allaient pas (UI/Swing, le problème du déploiement par exemple) mais des guerres de pouvoir ont sabordé cela.<br />
Quand je vois JavaFX 2, je me dis que si il était sorti en 2000 les choses auraient pu être différentes.<br />
Alors on va me dire qu'avec Java il faut installer une JVM, c'est chiant. C'est vrai mais comment croyez-vous que JavaScript s'exécute ? Avec une VM embarquée comme l'était la JVM dans les premiers navigateurs.<br />
De plus je pense que Java pourrait évoluer pour être modulaire et n'installer dans le navigateur que le strict nécessaire au fur et à mesure des besoins. De même, ne pourrait-on pas imaginer de livrer une application Java entièrement autonome (en fait c'est déjà possible en utilisant des outils payants) ?<br />
Le problème principal étant que les acteurs qui font les navigateurs sont engagés dans une mise à l'écart de Java dans le Web et dans les systèmes car ils veulent tous que le développeur utilise leur framework de développement à l'exclusion de tout autre (Google, Apple, Microsoft). Java étant multi-plateforme il doit être tué.<br />
De la part de Google c'est quand même un peu bizarre étant donné qu'il a <del>volé</del> choisi Java pour en faire le système de développement sur Android. D'ailleurs il n'a pas choisi JavaScript mais Java (tout le monde sait que JavaScript est un très mauvais langage...). De fait on peut considérer qu'il y a désormais deux Java différents qui évoluent de manière indépendante. Cela fractionne encore plus les énergies. <br />
C'est une spécialité de l'informatique de refaire 100 fois les mêmes outils. Il suffit pour s'en convaincre de consulter la <a href="https://fr.wikipedia.org/wiki/Liste_des_langages_de_programmation">liste des langages de programmation</a> sur Wikipedia. Il faut imaginer tout le temps et l'argent dépensé pour créer tous ces langages dont peut-être 10% sont couramment utilisés et encore moins dans l'industrie. Et encore ce ne sont que les langages de programmation. Il y a plein d'autres langages pour tout un tas d'usages tous plus ou moins différents parfois de manière très subtile.<br />
Franchement les différences (je considère uniquement le langage) entre C++, Java, Ruby, Groovy, Python, Scala, C#, JavaScript, Go, Dart, Eiffel etc. justifient-elles de créer un nouveau langage et un nouveau environnement de compilation, d'exécution et de débug ? Ne pourrait-on pas juste améliorer l'existant ? C'est par exemple ce que fait Java 8 en intégrant des nouveautés présentes dans d'autres langages. Mais comme le processus est long, les autres langages ont le temps de prendre une place significative.<br />
Ceci dit, c'est plaisant de découvrir un nouveau langage mais le problème se pose de pouvoir le maitriser pour le mettre en œuvre de manière efficace, sachant que si l'on fait cela on se disperse immanquablement et je ne peux m’empêcher de penser que cela nuit à l'efficacité globale. Une autre façon de voir est de s'inspirer de ce que l'on voit dans d'autres langages pour l'appliquer dans son langage courant. C'est parfois possible mais pas toujours du fait de manques rédhibitoires.<br />
D'ailleurs - une parenthèse - cela me fait penser aux films SF dans lesquels les informaticiens arrivent à télécharger des programmes dans des systèmes dont ils ne savent rien. On imagine donc que le futur n'utilisera qu'un seul système, avec un seul type de langage, un seul type de binaire, un seul type de connexion etc. On branche, ça <q>upload</q> et POUF le programme s'exécute ! Magique. Quand on voit le bordel que c'est actuellement j'ai de la peine à l'imaginer.<br />
Il y a quand même un domaine où Java est très populaire, c'est le domaine des applications serveur, et on peut considérer qu'il ne survit que pour cela. C'est dommage car Java est l'évolution de Smalltalk qui était aussi une plateforme entière de développement aboutie aussi bien client que serveur.<br />
<br />
MAJ: j'étais à l'instant sur un forum de développement Mac et ça parlait de Swift. C'est vrai que j'avais oublié de le citer dans ma liste non exhaustive de langages. Je ne connais pas bien Swift mais il semble qu'il soit plus statique que Objective-C qui est dynamique par nature. En effet la méthode exécutée n'est découverte qu'à l'exécution et non à la compilation. Visiblement Swift corrige cela. Mais alors on peut se demander pourquoi ne pas avoir choisi Java qui est fortement typé ?</p>Critique d'un nom de partiurn:md5:2c08e6c537fc8a9140ba9cdf9570012c2013-06-07T09:01:00+02:002013-06-07T09:01:00+02:00groumpfGeneralinternetpolitique <p>Je voudrais critiquer le choix du nom de parti : UPR.<br />
Une première critique est que quand on le prononce on à l'impression d'un mélange entre UMP et RPR, donc connoté à droite, ce qui est le comble pour un parti qui se revendique en dehors du clivage gauche-droite.<br />
Cette critique à sûrement déjà été faite.<br />
Je pense aussi à un autre problème : celui de la recherche sur le web. Étant donné que ce parti s'est créé sur internet il semble normal de s'intéresser aux moyens de se faire connaitre, donc aux moteurs de recherche.<br />
Un petit tour des moteurs fait apparaitre plusieurs homonymes : l'Union Patronale Régionale PACA, l'Université Populaire et Républicaine, Union Portuaire de Rouen, Universidad de Puerto Rico etc.<br />
On voit que ce choix n'est pas génial car c'est le problème des acronymes : ils sont tous déjà utilisés !<br />
Cela aurait été plus judicieux d'inventer un nom quelconque sans signification car il aurait été inexistant sur internet. Il faut en tout cas éviter les acronymes. Je m'étais posé cette question quand j'ai choisi les mots "den makes music" pour mon nom d'artiste (hem...). Ce n'est peut-être pas génial comme nom mais l'avantage c'est qu'il n'y a pas de mauvais résultats de recherche.</p>