J’avais besoin de renouveler mon vieux portable Dell Inspiron 8500 par quelque chose de plus récent et plus puissant.
Etant un peu saturé de Windows XP et le passage à Vista ou Windows 7 ne me tentant pas trop, j’ai tenté le passage à un Mac. Le fait que plusieurs amis aient un mac et en soient content m’a aussi aidé à la décision.
L’utilisation d’un système Linux/Fedora à mi temps au boulot m’a aussi donner envie d’aller voir ailleurs et d’avoir aussi un vrai shell.

Et puis il faut dire que le look des Mac tant au niveau des machines que de l’interface graphique est vraiment attirant .

Les bons points:

La machine est vraiment silencieuse, le clavier agréable (l’éclairage du clavier en jette aussi).
Le trackpad est réellement magique: très doux au toucher, très sensible au contraire de beaucoup d’autres trackpad de (Dell, Asus). Le multitouch avec deux/trois doigts est vraiment top.
De par sa grande taille le trackpad permet de parcourir tout l’écran sans s’y reprendre à deux fois.
C’est tellement agréable que je n’ai pas encore branché de souris. D’ailleurs je verrais un trackpad externe à brancher sur les ordinateurs de bureau.
Bon point pour la carte wifi qui permet bien le mode bridge avec VirtualBox.
Le prix est conséquent mais on apprécie la qualité de finition de l’ensemble (du magsafe, au niveau de batterie consultable sans allumer l’ordi, en passant par la coque tout alu très classe.
Pas de souci pour le moment côté application: Google Chrome venait juste de sortir pour Mac et Netbeans et Eclipse fonctionnent sans souci.

Les points difficiles:

Pour quelqu’un venant de Windows et même de Linux, il est difficile de se faire au menu unique pour toutes les applications. Surtout pour la fermeture d’une application.

L’installation et la désinstallation des applications n’est pas aussi simple qu’il n’y paraît car il y a plusieurs possibilités. Le plus compliqué est quand les applications ont un “désinstalleur” car il faut garder le fichier d’origine si j’ai bien compris.
Même si la lecture est supportée, je trouve incompréhensible que Mac OS ne gère pas l’écriture de volume NTFS, cela simplifierait le passage au Mac. En attendant j’ai acheté NTFS for Mac de Paragon.
Le finder, l’explorateur de fichier Mac est aussi un peu particulier, comme par exemple afficher les fichiers cachés.
Petit retour sur le clavier, agréable oui mais tous les symboles ne sont pas inscrits, on cherche un peu pour trouver le pipe par exemple.
Exposé et Space sont vraiment fluide et agréable à utiliser.
Petit point sur Space: pourquoi n’y-a-t-il pas un menu système dans chaque applications ouvertes permettant de la déplacer sur un autre space ?
Autre point particulier à mon utilisation, le add-on S3Fox sur Firefox permettant d’accèder à son compte Amazon S3 n’affiche pas tout les fichiers et répertoires ! Pas compris pourquoi.

Conclusion

Pour l’instant, très content de mon achat ! Ce n’est pas un vrai switch comme on dit car je continuerai à travailler sur Windows mais cela fait toujours du bien de connaître d’autres systèmes.

Cette application “FlickrML” permet d’afficher dynamiquement dans Google Earth les photos géotagguées de Flickr via un fichier KML à ouvrir dans Google Earth.

Ne pas oublier de cocher le dossier “FlickrML” puis baladez-vous dans des endroits susceptibles d’avoir beaucoup de photos comme Paris.

Ce fichier KML contient un Network Link qui pointe sur une servlet hébergée sur Google App Engine.

1s après un arrêt de mouvement, Google Earth va appeler la servlet en lui passant en paramètre les coordonnées de longitudes et de latitudes de l’endroit que vous observez (paramètres BBOX). La servlet utilise ces coordonnées pour récupérer auprès de Flickr toutes les photos correspondantes sous format XML.

Télécharger le fichier KML sur Application FlickrML

Une petite démonstration ci-dessous:

Annoncé lors du Google Campfire (littéralement feu de camp) du 7 avril dernier, le support du langage Java dans Google App Engine (GAE) est une grande nouvelle pour ceux qui développent dans ce langage.

Flashback

Un petit flashback s’impose en effet: GAE est un service qui permet de déployer des applications web sur l’infrastructure Google sorti il y a un an mais avec comme seul langage de développement Python.

Depuis la sortie de GAE, le support de Java comme langage figurait comme la première demande (même devant PHP). Demande exaucée donc depuis le 7 avril par Google.

GAE c’est quoi ?

Google App Engine est une une plateforme permettant de déployer des applications web Python et maintenant Java de type servlet/JSP en profitant gratuitement jusqu’à une certaine limite (quota) de l’infrastructure de Google.

C’est presque une révolution car dans le monde de l’hébergement, l’hébergement d’application web java n’est pas très répandu. Il y a bien quelques hébergeurs spécialisés dans ce domaine mais au vu des prix et des contraintes la solution la plus simple reste souvent de louer un serveur et d’installer soit même son JDK/Tomcat. On est très loin du niveau de support de PHP que presque tous les fournisseurs d’accès à internet offrent à leurs clients.

C’est là que Google App Engine Java change la donne.

On peut enfin déployer facilement une application web java comme on le ferait sur un serveur d’application en local mais surtout profiter de l’infrastructure de Google pour tenir une charge importante en répartissant la charge sur plusieurs serveurs si nécessaire.

C’est un des points fort de GAE par rapport à un serveur dédié: on déploit son application et c’est Google qui s’occupe de gérer la montée en charge de l’application selon les besoins.

Contraintes et persistence de données

Pour pouvoir assurer cela, GAE impose certaines contraintes à bien prendre en compte:

• il n’est pas possible d’écrire dans un fichier
• pas de possibilités de créer des threads
• pas de connexion de type socket directe à des serveurs externes (les requêtes HTTP sont par contre autorisées)
• une limite d’exécution de 30s par requête (depuis)
• support des apis java limité à une whitelist : http://code.google.com/appengine/docs/java/jrewhitelist.html
• pas d’accès à des bases de données relationnelles type MySQL (par contre JDO et JPA sont disponibles)

Il faut bien comprendre que ces limites permettent à Google d’assurer une montée en charge en déployant une même application sur plusieurs serveurs.

Dans ce cas on comprend pourquoi l’écriture de fichier est interdite : elle n’a aucun sens  quand l’application est distribuée. Un fichier généré par une instance d’une application ne peut pas être utilisé par une autre instance de l’application sur un autre serveur tel quel.

Avant de vous révolter sur ces contraintes, relisez les restrictions à respecter dans le développement des EJB (http://java.sun.com/blueprints/qanda/ejb_tier/restrictions.html), on y retrouve presque les mêmes contraintes.

L’aspect absence de base de données est plus délicat: mettre à disposition une base de données relationnelles de type MySQL à l’ensemble des applications distribuées sur plusieurs serveurs est un problème qui n’est pas simple. Les Facebook, Google, LinkedIn, Flickr, Amazon et autres gros consommateurs de ressources n’ont apparemment pas trouver de solution simple et s’appuient sur des systèmes alternatifs plus simples en plus de bases de données relationnelles traditionnelles: Cassandra pour Facebook, BigTable pour Google, Dynamo pour Amazon, …

La persistence des données dans GAE s’appuit donc sur un système “Datastore” plus simple et plus “scalable” comme on dit, ce système dispose d’APIs mais pour nous faciliter la vie, les standards Java de persistence de données JDO et JPA sont disponibles via une implémentation basée sur le Datastore.

La gestion des sessions web est elle-même gérée via ce Datastore ce qui permet d’avoir des sessions distribuées sur plusieurs serveurs (besoin classique quand il s’agit de distribuer une application gérant des sessions utilisateurs sur plusieurs serveurs, la méthode la plus simple étant l’affinité de serveur, un client est “fixé” sur un serveur donné et toutes ses requêtes ultérieures sont dirigés sur ce même serveur).

Console d’Administration

GAE met à votre disposition une interface d’administration dont on aimerait bien avoir plus souvent l’équivalent dans le monde professionnel: statistiques de requêtes à la secondes, de temps par requêtes, de consommation CPU, nombre d’octets envoyés/reçus, …

Petite remarque: c’est une vue consolidée des différents serveurs sur lesquels peuvent tourner votre application (à prendre en compte avant de dire que le serveur d’application X ou Y fournit la même chose…).

Versioning

GAE gère les versions de vos applications: à chaque fois que vous déployer vous pouvez préciser la version de l’application que vous déployez, les différentes versions sont ainsi conservées sur GAE et même accessibles simultanément individuellement via une URL spécifique. Une fois déployée, vous pouvez choisir quelle version doit être celle par défaut. Point intéressant pour pouvoir tester une nouvelle version en réel sans l’activer pour tout le monde (hors problème de gestion de version de la structure des données …).

Développement/Déploiement & GWT:

En plus de l’App Engine SKD, un plugin pour Eclipse est disponible pour développer/tester votre application en local puis la déployer sur GAE. Le JDK utilisé est 1.6. Le plugin intégre aussi en option le plugin Google Web Toolkit (GWT)  permettant de développer en java des applications Ajax.

Coûts ?

Et oui, GAE est gratuit jusqu’à un certain niveau (nb de requêtes, octets, …), mais au delà l’application est bloquée par un message d’erreur. Ces quotas sont extensibles en payant.

Voici ci-dessous une partie des quotas sur les ressources:

La liste complète: http://code.google.com/appengine/docs/quotas.html

Ouverture de GAE à d’autres langages

Le support de Java par Java permet à des langages qui ont été porté sur la JVM comme par exemple Ruby avec JRuby de pouvoir être exécuté sur GAE:

• Dynamic languages on google App Engine

Groovy qui s’appuie directement sur la JVM est lui aussi disponible:

• Write Groovy applications on Google App Engine!
• Groovy Web console

Cron , Secure Data connector

GAE dispose aussi d’un ordonnanceur (cron) permettant d’appeler une URL de votre application, bien utile pour mettre à jour des statistiques, remplir des caches, …

Secure Data Connector est un service permettant de pouvoir accèder depuis GAE à des données au sein de l’entreprise.

Conclusion : Révolution ?

Je ne sais pas encore si GAE Java est une révolution mais c’est clairement un gros changement dans le paysage Java car GAE abaisse fortement la barrière de déploiement d’application web Java sur Internet. Plus besoins de serveurs dédiés, plus de gestion de montée en charge sur différents serveurs.

On se demande (enfin surtout moi ), pourquoi ce n’est pas Sun, père de Java qui a eu cette initiative ?

Pourquoi Sun n’a pas populariser davantage Java chez les hébergeurs webs ou en offrant lui-même un hébergement de ce type ?

Quel dilemme pour un pro Java d’être obligé d’utiliser PHP pour son blog perso car c’est le langage le plus répandu chez les hébergeurs mutualisés gratuits et payants. Quelle frustration de ne pas pouvoir déployer ses applications web java aussi facilement que d’autres lancent leur blog ou leur applis PHP !

C’est pourquoi GAE est à mon avis, une avancée importante pour le développement de Java dans le web.

Sources:

• Google App Engine
• Liste des propriétés systèmes et moteur de servlet utilisé (Jetty)
• What you cannot do using Java in Google App Engine :
• Standards-based Persistence For Java™ Apps On Google App Engine
• L’annonce sur le blog Google Code
• Import des données dans GAE
• Secure Data connector (permet d’accèder à des données de l’entrepris depuis GAE)
• Google App Engine Will Change Java Web Development
• Overview of Java support in Google App Engine (avec un schéma d’ensemble)
• Google Brings App Engine’s Pros and Cons to Java (InfoQ)

Et bien Google met à disposition depuis quelque temps des apis qui permettent d’agir sur ces documents : les Google Data APIs.

Ces apis sont basées sur des échanges XML via HTTP et pour faciliter la vie des développeurs des bibliothèques encapsulant ces appels sont disponibles dans différents langages : Java, .NET, PHP, Python, Javascript et même Objective-C.

La nouveauté c’est que ces apis ont été mis à jour sur la partie Documents en ajoutant le téléchargement des documents [1].

Afin de mieux voir de quoi il retourne, j’ai développé une petite application “GDocsUI” en Java/Swing pour mettre en oeuvre ces apis.

Voici ci-dessous une copie d’écran de l’application:

Vous pouvez lancer cette application via Java Web Start via ce bouton :

Cette application a été développé avec l’IDE Netbeans et le Swing Application Framework plus riche que les apis Swing de base (gestion des Actions centralisées, gestion des traitements en tâche de fond toujours problèmatique en client lourd, …).

Mais pour moi, la killer feature, c’est le “Touring” ou pour parler français la visite guidée: Google Earth 5 permet en effet d’enregistrer tous les mouvements que vous faîtes et même d’enregistrer votre voix en même temps pour ajouter vos commentaires audios.

La démonstration en images:

Et voici un petit exemple fait maison :  

• Visite Annecy avec Google Earth.

Si vous voulez une visite plus en musique voici un tour du concert du chanteur Jimmy Buffet à Hawaii :  

• Jimmy Buffet (attention 8 Mo le fichier).

Toutes les visites sont en fait enregistrées dans le format XML de Google Earth : le KML .
Les fichiers avec une extension en .kmz sont en fait des fichiers kml compressés au format zip (la même technique que les fichiers d’OpenOffice).

Ce format permet donc de créer soit même ces visites et certains ont déjà créé des visites en générant automatiquement le fichier KML, voici par exemple une belle visite de San Francisco par Brian Flood de Arc2Earth  :

•  San Francisco Tour (19Ko).

Donc à vos souris pour enregistrer et envoyer à vos amis les visites de vos coins préférés !

Si vous voulez en faire de manière professionnelle avec une naviguation  fluide, il vous faut absolumnet le SpaceNavigator :

Source:

Les avantages : aucune installation à faire et un accès à toutes vos données depuis n’importe quel accès internet.

En appliquant ce principe au développement, on a le concept d’un environnement de développement intégré tout en ligne. Développer sur n’importe quel ordinateur avec votre configuration personnelle, vos projets, le tout sans rien réinstaller, le rêve, non ?

Bespin est un nouveau projet des labs Mozilla qui va dans ce sens : un éditeur de code réalisé en javascript permettant d’intéragir avec un serveur pour par exemple enregistrer le texte édité dans une structure de projet grâce à des apis REST à implémenter côté serveur (des exemples en Python et Servlet Java sont fournis [1]).

L’éditeur est assez évolué et dispose d’une ligne de commande avec aide en ligne.

Allez à 2:13 pour voir l’éditeur en action: 

Introducing Bespin from Dion Almaer on Vimeo.

Mais ce n’est pas fini! Quelques jours après cette annonce Boris Bokowski, commiter sur Eclipse et son camarade Simon Kaegi ont implémenté ces apis [2] avec un Eclipse “headless” sans interface graphique [3].

L’intérêt ? Un des avantages du tout en ligne c’est la puissance de calcul qui peut être mis en oeuvre par une application web par rapport à votre ordinateur personnel si puissant soit-il.

Par exemple, utilisateur régulier de service de calcul d’itinéraire comme Google Maps, j’ai acheté il y a quelques temps un GPS portable et au premier test d’itinéraire ce qui m’a frappé c’est le temps de calcul de l’itinéraire : plusieurs secondes alors que sur internet c’est quasiment instantané…

Et oui, sur une application web, on ne sait pas combien d’ordinateurs sont utilisé pour vous fournir le service. Si l’application en question utilise des services distribués cela peut être un nombre important.  C’est ainsi que l’on a appris récemment qu’une simple recherche sur google utiliserait par exemple près de 1000 serveurs [4].

Appliquons maintenant ce principe de puissance à la demande à un éditeur de code : compilation instanée, exécution des tests en simultané, etc… Le tout à partir de votre ordinateur qui peut être beaucoup plus léger en puissance car son seul but est de faire tourner le navigateur Web: pas besoin d’avoir des tonnes de RAM ou des processeurs à 300 coeurs. On reporte cela sur le ou les serveurs.

C’est un peu un retour au principe des terminaux X mais avec une ouverture beaucoup large : votre éditeur pourrait utiliser un serveur pour la compilation, d’autres services web pour des analyses de code, etc…

Vous pouvez essayer Bespin sur le site suivant : https://bespin.mozilla.com/

Références:

Source: Hacker News

• les Certificate Authorities CA (les entités qui délivrent des certificats) : des revues sont réalisées
• des comparatifs de tarifs pour les certificats SSL (et oui il n’y a pas que Verisign)
• des news dans le domaine SSL
• une FAQ sur SSL qui couvre l’ensemble des problèmes : génération, installation, …
• mais surtout des outils en ligne bien pratiques :
  • un vérificateur de certificat SSL (permet d’afficher sur la même page toute la chaîne)
  • des décodeurs de CSR et de certificat
  • un contrôleur clé privée / certificat, csr / certficat (attention avant de donner votre clé privée…)
  • des convertisseurs de format PEM/DER/PKCS#7/PKCS#12

Gros plus pour chaque outil en ligne, les commandes équivalentes openssl (pas toujours évidentes) sont fournies.

Un site que je vous recommande donc !

J’ai justement reçu le Speedo Aquabeat en cadeau d’anniversaire :

Le lecteur est suffisament petit et léger pour s’accrocher à l’arrière de votre tête sur la lanière de vos lunettes. Les écouteurs et le cable ne sont pas gênants, même si en crawl il faut faire un peu attention. La capacité de 1 Go et l’autonomie de 9 heures annoncées sont largement suffisantes pour mes séances aquatiques.

Je n’ai pas d’actions chez Speedo, ni chez des revendeurs mais je vous fait partager ma bonne expérience.

Ah j’oubliais le prix aux alentours de 90 EUR.

PS.: un grand merci à ma soeur pour ce cadeau