jeudi, mars 17 2016

Jeu de la vie 1.1

J'ai publié une nouvelle version de mon jeu de la vie sur Android.
Cette version permet de dessiner des cellules ou d'en supprimer avec le doigt. On peut désormais partir d'un écran vide. La taille de la gomme peut être modifiée dans les préférences.
Du coup c'est assez amusant de chercher des combinaisons qui durent. J'aime particulièrement les figures symétriques. J'en ai trouvé par hasard une qui boucle sur plusieurs cycles.
Je pense qu'une amélioration future sera de pouvoir sauvegarder l'état courant dans un fichier ou une base de données et de pouvoir les recharger et les exporter.
Une autre amélioration sera de pouvoir zoomer car avec beaucoup de cellules l'édition n'est pas précise.
Afficher une grille permettrait de faciliter le placement des cellules.
Enfin, un undo ne serait pas de trop car cela éviterait de prendre la gomme quand on a placé une cellule au mauvais endroit. Screenshot_2016-03-16-20-53-41.png

samedi, octobre 17 2015

Applet

Quand je lis ce document 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.
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.
Par ailleurs ce qu'ils appellent Same-Origin Policy 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.
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.
En fait on peut considérer que la plupart des sites ont des failles dues à une méconnaissance des problèmes de sécurité.
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.
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.
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.
Quand je vois JavaFX 2, je me dis que si il était sorti en 2000 les choses auraient pu être différentes.
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.
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) ?
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é.
De la part de Google c'est quand même un peu bizarre étant donné qu'il a volé 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.
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 liste des langages de programmation 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.
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.
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.
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 upload et POUF le programme s'exécute ! Magique. Quand on voit le bordel que c'est actuellement j'ai de la peine à l'imaginer.
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.

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é ?

samedi, mai 30 2015

FS1R (4)

J'ai mis à disposition une première version de l'éditeur pour le FS1R. Vous pouvez le télécharger à cette adresse : FS1REditorFx

dimanche, avril 26 2015

FS1R (3)

J'ai commencé à traiter les FSEQ mais c'est vraiment compliqué. Voici un avant-goût : FS1R FSEQ J'utilise l'API Chart de javafx mais ce n'est pas certain que ce soit la meilleure solution. J'essaye de contrôler la hauteur de chaque point avec la souris.

Sinon j'ai bien avancé sur l'édition des voices : FS1R voice Je pense qu'il faudrait que j'ajoute un bandeau avec des contrôles de volume ou des "mute" pour tous les opérateurs, que ce soit accessible tout le temps.

samedi, février 7 2015

FS1R (2)

J'ai avancé sur l'éditeur et l'édition des performances est quasi fonctionnelle à part l'édition des effets qui est encore très sommaire. L'ergonomie n'est pas encore terrible, j'ai plein de refactoring à réaliser pour que ce soit vraiment pratique mais il faut que je puisse l'utiliser pour juger de ce qui est bien et de ce que je dois changer.
Avant de faire l'édition des voices, j'aimerais regarder les FSEQ et voir ce que je peux faire là-dessus histoire de faire autre chose que d'aligner des potards.

FS1R common

FS1R Effects

FS1R part

lundi, janvier 26 2015

FS1R (1)

J'ai commencé un éditeur pour le Yamaha FS1R. Il est encore un peu limité !

FS1R

dimanche, décembre 7 2014

Et si je passais sur Linux ?

Je suis passé de Mac à Windows sans perdre beaucoup de logiciels. Parmi les logiciels que j'ai acheté, je crois que j'ai perdu uniquement Poser. Est-ce que ce serait le cas si je passais sur Linux ? Voici la liste des logiciels que j'utilise couramment :
Pour Internet :

  • Thunderbird : OK
  • Firefox OK
  • Filezilla OK
  • Putty ssh OK
  • Pidgin OK

Pour la musique :

  • Ableton Live 8 KO
  • Propellerheads Reason 7.1 KO
  • Audacity OK
  • iTunes KO
  • ObieEditorFx (mon éditeur Matrix-1000 écrit en Java 8) OK

Pour l'image 2D :

  • Gimp OK
  • ArtRage, semble fonctionner avec WINE, ?
  • Mischief : KO
  • SketchBook Express KO
  • driver Wacom pour la Bamboo ?

Pour l'image 3D :

  • Shade KO
  • Hexagon KO
  • Blender OK
  • Wings 3D OK
  • DAZ 3D KO (WINE ?)
  • Vue 6 KO
  • Bryce 7 KO

Pour la video :

  • VLC OK

Pour le développement :

  • Java OK
  • Netbeans OK
  • IDEA OK

Pour les ebooks :

  • Calibre OK

Pour les photos :

  • Galerie de photo Windows KO
  • Rawtherapee OK
  • driver RAW pour mon Pentax ?

Pour le système :

  • FreeFileSync OK

Les jeux :

  • XPlane OK
  • driver pour mon joystick Cyborg machin ?

Finalement les domaines les plus touchés sont la musique et la 3D. Pour la 3D ce n'est pas bloquant car j'en fait assez peu. Par contre pour la musique c'est vraiment bloquant. Une solution serait de passer sur BitWig mais je perdrais énormément de plugins VST dont certains payants (Zebra, Kuassa, Sampletank). En fait je ne sais pas si les plugins VST Windows fonctionnent sur Linux. Cela suppose aussi de faire une croix sur l'investissement que représente Live et Reason, ce qui n'est pas réjouissant.
Il faudrait aussi trouver un remplaçant pour itunes mais ça doit exister à condition que je convertisse les morceaux achetés en MP3 ou autre. Heureusement je n'en ai pas beaucoup.

Conclusion :
Je ne pense pas que Linux attirera beaucoup les gens tant que les logiciels commerciaux ne fonctionneront que sur Mac/Windows. Cela suppose que les éditeurs fassent l'effort de choisir des plateformes de développement qui le permettent. A ce titre Bitwig est intéressant car il est écrit en Java pour ce qui est de la GUI et en C pour l'audio. C'est vraiment remarquable et cela montre que Java est une plateforme sérieuse pas uniquement réservée aux serveurs.

dimanche, novembre 2 2014

ObieEditorFx Matrix-1000

J'ai terminé une première version de l'éditeur Java 8 pour le Matrix-1000. J'ai réussi à caser tous les paramètres sur une page ce qui était une condition sine qua non. En tout cas je le trouve beaucoup plus beau et plus ergonomique que celui de JSynthLib, sans me vanter. Bon c'est vrai j'ai honteusement copié le look des potentiomètres d'Ableton Live, j'avoue, comme ça je ne suis pas dépaysé ;)
Vous pouvez le télécharger ici. En voici un aperçu : ObieEditorFx

dimanche, octobre 26 2014

Preferences

Je me demandais comment gérer les préférences en Java de manière transparente par rapport au système, et bien en fait c'est déjà dans le JDK en ce depuis la version 1.4 !
C'est la classe java.util.prefs.Preferences qui gère cela.
Voila ce que c'est que d'avoir fait des logiciels serveurs pendant des années, il y a des classes dont je n'ai aucune connaissance.

Optional

Je viens de m'apercevoir que le JDK 8 contient la classe Optional qui sert à contenir une valeur potentiellement absente.
Habituellement on retourne null pour signifier l'absence de valeur. Néanmoins cela peut provoquer des NPE plus tard dans le code.
Je n'étais pas hyper convaincu de l'intérêt de Optional, mais je pense que c'est quand même mieux de l'utiliser pour plusieurs raisons :

  1. le fait que la méthode peut ne pas fournir de valeur est indiqué dans sa signature
  2. l'interface est claire : isPresent et get
  3. le get lève NoSuchElementException


Le type de retour indique la possibilité de ne pas avoir de valeur alors qu'avec une méthode qui retourne null il faut consulter la javadoc. Ainsi si on prend l'habitude de tester isPresent avant de l'utiliser, pas de problème. Mais même si on appelle get sur un Optional vide on à l'exception. En fait il est préférable d'utiliser la méthode ifPresent comme indiqué sur la page Oracle.
Évidemment cela suppose de ne pas transmettre un Optional en paramètre car là il me semble qu'on retombe dans les inconvénients de transmettre une valeur null. Je pense qu'il faut appeler isPresent et get immédiatement après le retour de méthode, ainsi si il y a un problème il est localisé au plus près de la source.

Voir aussi