jeudi 26 mai 2016

Java vs .Net C#

C'est un débat sans fin mais comme je développe sur les deux environnements je me dois d'y participer un peu, d'apporter mon caillou au tas de gravats.

Je vais balayer d'un revers de main l'aspect performance : c'est pareil ou presque. Bon quand même on va dire que les Winform sous Windows ont un rendu certainement plus rapide et réactif que du Java swing ou autre. Pour le reste cela dépend beaucoup du développeur et on peut voir une programmation d'un algo en Java battre le même en C à cause de la mise en oeuvre : un mauvais développeur C/C++ fera pire qu'une mauvais développeur Java/C#.
Et on peut jouer avec cela : http://benchmarksgame.alioth.debian.org/
Donc grosso c'est pareil.

Attaquons d'un point de vue langage et syntaxe. Ce sont des syntaxes très proches, C# est fortement inspirées de Java et C et Java est elle-même inspirée de C. Mais plus en détail question langage, le C# est clairement meilleur, plus flexible et plus juste. Son secret, le C# n'est pas rétrocompatible ce qui lui a permis de briser certaines barrières et d'évoluer plus vite.
Ainsi les generics sont vraiment gérés au runtime ce qui n'est pas le cas de Java et dès qu'on s'attaque à faire de la réflexion on réalise que cela a de l'importance.
En suite le gros apport de C# c'est linq qui permet de réaliser des requêtes dans les structures de données les plus divers (SQL, XML, objets...).
Le foreach multi threads et quelques raccourcis pour faire un code utilisant plusieurs threads mais je crois que maintenant il y a un équivalent en Java.
De plus il y a une certaine flexibilité dans la gestion des fichiers de code source : une classe peut-être implémentée dans plusieurs fichiers, pratique pour le code généré, et la structure namespace-classe ne doit pas comme en Java être identique à celle répertoire-fichier (mais cela n'a pas que du bon). 
Enfin à chaque nouvelles versions ils progressent et l'écart se réduit ou change de géométrie.

Ensuite l'environnement de développement, Visual Studio contre Eclipse, Intelij, Netbean... bon aujourd'hui ils sont tous très aboutis, mais le développement d'une application reste complexe, et il fini par y avoir pléthores de menus et sous menu et modules... bref c'est ainsi. Visual Studio intègre nativement plus de chose ce qu'il fait qu'il est plus simple d'approche. Il faut aussi noté qu'il y a dans l'ASP.NET et autre finalement pas mal de code généré par Visual Studio qui est masqué à l'utilisateur. Après pour avoir la couverture de code par les test dans Visual Studio faut s'attaquer à une licence qui vaut quelques milliers d'€...

En en arrive a la réalisation d'un projet Web par exemple, c'est quand même mieux intégré dans Visual Studio, on est tenu par la main. En Java il faut déjà faire beaucoup de choix, Java EE, Spring, JPA, JSF, JSP, GWT... tout ça décliné en version, cela demande un certain savoir faire sans compter que cela change régulièrement aujourd'hui on partirait plus sur Java EE REST, JPA + Angular (ce qui simplifie la donne ou déplace le problème vers le développement javascript). En ASP.NET y a moyen de chercher du Nhibernate, Castle, EntLib, Unity et autres mais étrangement c'est assez peu couru de méditer sur la stack ASP.NET.

Ce que fait la grande différence lors de la réalisation c'est la gestion des librairies tiers, d'un côté Maven (ou Gradle) pour Java et Nuget pour .net. Mais il faut dire que Maven a des années d'avance et une pratique assez généralisée aussi bien dans les projets tiers qu'au sein même de l'entreprise. Nuget commence a entrer dans les mœurs.

Un autre aspect qui fait la différence est l'écosystème, en Java il y a de grandes organisations qui gèrent de l'opensource (Apache, Redhat, Spring...) de gros éditeurs (Oracle, IBM...). Du coup c'est très riche on peut vite s'y perdre, mais il y a aussi Java EE pour normaliser et cadrer un peu tout cela. A contrario le monde .Net est plus fermé, il a quelques éditeurs spécialisés dans les composant d'interfaces et autres outils : Telerik, ComponentArt, ComponentOne. Les projets opensource en c# dans http://www.codeproject.com/ et http://codeplex.com ont rarement un gouvernance clair, les bonnes idées finissent absorbées par Microsoft sous une forme ou une autre, alors souvent le plus simple est de ne surtout rien faire et attendre la prochaine version du framework. Et inversement Microsoft y déverse les éléments qu'il ne souhaite plus maintenir (ex : Entlib, Unity).

Finalement la grande différence c'est le développeur. Le développeur .Net et le développeur Java sont très différents dans leurs approches et leurs travers. Mais cela mérite son propre post.

lundi 18 janvier 2016

On continue l'aventure GAE Endpoint et SEO

Voila depuis quelques temps que mon application de compteur en ligne est en production en version Alpha. Bien entendu personne ne l'utilise, même par mégarde. Du coup je me dit qu'un petit effort de SEO, optimisation pour les moteurs de recherche, s'impose.
Pour cela 2 axes possibles :
  • Plus de contenus
  • Une URL plus parlante

Pour le 1er axe, c'est possible en réalisant des pages de documentation pour l'utilisation de l'application, c'est prévu mais il faut du temps. Par contre modifier l'URL du site pour que cela soit plus efficace semble assez rapide. L'URL compte beaucoup pour les moteurs d'indexation, car c'est un champ limité en taille, obligatoire et potentiellement compliqué à modifier, très engageant : achat de domaine, mise à jour DNS, redirection du site...

Pour mon cas je ne vais pas investir dans un domaine, mais j'en ai déjà un capverszero.fr, du coup je vais faire un sous domaine bien parlant : https://onlinetallycounter.capverszero.fr

Alors avec Google Cloud Endpoint c'est le parcours du combattant...
Première étape enregistrer le nouveau domaine, au travers de la console Google AppEngine, montrer patte blanche et prouver que vous êtes bien propriétaire du domaine. J'ai opté pour la validation au travers de l'ajout d'une directive DNS. Une fois ceci passé Google donne la directive DNS à ajouter pour redirigé le sous domaine vers l'application GAE. 
Il faut bien noter que chaque mise à jour du DNS prend un certain temps... plusieurs heures... donc faut pas être pressé.
Et là stupeur les Cloud Endpoints ne supportent pas les custom domain... oui c'était une petite note dans la documentation... Heureusement la page HTML est bien accessible sur le nouveau domaine mais les services ne sont pas disponibles sur ce domaine. Argh !!! 

Donc il faut se lancer dans la modification du code de l'application pour utiliser CORS (Cross-Origin Resource Sharing). Ça marche dans les nouveaux navigateurs, ça signifie tout simplement qu'il faut appeler les services REST de Google Cloud Endpoints sur l'adresse contingit.appspot.com, en dur, et ça marche ouf.

Et maintenant il faut mettre à jour le référencement de mon site dans les outils Google (Webmaster Tools et Analytics), et là il demande qu'une redirection HTTP 301 soit mise en place pour valider que c'est bien une migration de site. Et là impossible de réaliser cette redirection côté serveur : je n'ai qu'une page statique... Je me lance sur une redirection par balise meta... c'est pas classe mais il parait que ça peu marcher. Mais la blague c'est que je n'ai qu'une page et c'est physiquement la même au 2 adresses donc tout cela semble compromis je risque d'être redirigé indéfiniment. J'ai bien fait le test en mettant une seconde page mais cela ne m'a pas permis de valider la migration du site dans l'outil google... du coup c'est comme s'il y avait 2 sites...


Enfin je m'arrête ici et j'attends de voir si je monte un peu dans le ranking google, à suivre...

dimanche 13 décembre 2015

Le voyage du Kimsufi en Docker (Etape 5) subsonic

Voila on attaque la dockerisation de Subsonic, on trouve déjà des images et des Dockerfile, donc ce n'est pas trop compliquer de s'en inspirer voir on pourrait les reprendre directement. Mais pour divers raisons je recompile Subsonic à partir des sources et puis je voulais compiler ffmpeg dans le container histoire de voir si le tout est plus performant. Mon mini Kimsufi souffre un peu avec l'encodage à la volée côté puissance c'est un peu léger.

Bien entendu c'est la dernière version de Subsonic, j'avais espéré la brancher à la base de donnée MariaDB (mysql) mais ce n'est pas encore pour cette fois... peut-être faire un fork du projet pour le migrer de JDBC à JPA et mettre à jour le lecteur en HTML5... mais ça c'est vraiment si je trouve du temps... à voir si y a pas déjà un énervé qui a lancé un projet sur GitHub.
Vu que Subsonic est un conteneur autonome, il y a juste un partage de volume pour récupérer la musique et patienter un peu pour que la base de données se remplisse.

Je n'ai vu de différence notable, mais l'avantage de passer par un container rend la migration plus sécurisée, en effet sur le serveur l'ancienne version de Subsonic est utilisable et n'a pas été écrasée. Si je n'avais pas utilisé Docker j'aurais du écraser ma précédente installation.
Voila un lien vers l'images dans docker hub : https://hub.docker.com/r/niclange/subsonic/

Sinon le fait d'utiliser une version compilée à partir des sources pour ffmpeg ça donne cela :
Version compilée :
real 10m53.476s
user 38m21.924s
sys 0m30.456s

Version installée avec subsonic :
real 14m23.775s
user 45m1.728s
sys 0m31.908s