Announcing the SeedKit library and SeedKit Viewer 0.1 release.

The SeedKit project is happy to announce the simultaneous releases of both the SeedKit library and viewer.

It is the first ever release of the SeedKit project.

SeedKit view's consumers, documentation writer, hybrid applications developers and contributors are welcome to test/modify/contribute. Any help gladly appreciated !

Notes

• This is unstable development release. While it has had a bit of testing, there are certainly plenty of bugs remaining to be found. This release should not be used in production.
• No API compatibility guarantee is provided. The interfaces are susceptible to change until the 1.0 release.
• to pre-release testers : the project was split recently and changed its license terms, please update your copy of the original repository and clone the viewer one (see bellow).

What does it ?

With SeedKit, a developer can choose to define the user interface of a native application in pure web standard technologies (HTML/CSS/Javascript).

Alternatively a developer of an existing GTK+ application can embed a SeedKit view within the current interface.

What is it ?

The SeedKit project currently consists of two modules:

• SeedKit library: HTML view Gtk+ widget with access to lower-level libraries and systems within its Javascript environment. It is build around the Gtk+ port of WebKit and Seed [1]. Licensed under the LGPL 3+ terms.
• SeedKit viewer: a simple command-line viewer/launcher for applications whose views are defined in pure web standard technologies, while accessing lower-level libraries and systems (hybrid applications). Licensed under the GPL 3+ terms.

Examples of hybrid applications are provided in the examples/ directory of the seedkit-viewer package.

Download

SeedKit release packages are currently hosted on a personal public dropbox folder until a proper solution is found.

SeedKit library 0.1: http://dl.dropbox.com/u/5746554/seedkit-releases/seedkit-0.1.tar.gz

SeedKit viewer 0.1: http://dl.dropbox.com/u/5746554/seedkit-releases/seedkit-viewer-0.1.tar.gz

To follow the SeedKit development, you should clone the following repositories on Gitorious:

git://gitorious.org/seedkit/seedkit.git

git://gitorious.org/~scaroo/seedkit/seedkit-viewer.git

Building and installing

The SeedKit library compilation depends on the presence of :

* gtk-3.0 >= 2.90

* webkit-3.0 >= 1.3.3

* seed >= 2.31.5

The viewer only depends on the SeedKit library's presence.

Both can be compiled and install using the classic "./configure && make && sudo make install" sequence.

Contact

Concidering its low maturity, expect to experience bugs and misbehavior. Please report any issue, expectation or remark to the SeedKit mailing-list at seedkit-list@gnome.org until a proper bug-tracker is be set or used (hello sysadmin team ;)

Of course, drop a mail on the list if you want to participate in the SeedKit development too.

Happy coding !

HJGMPB 1 : Profils de deploiement (Updated)

Commençons la série des HJGMPB (How JEE 6 Gave My Productivity Back) avec la présentation de la gestion et définition de profils standards de déploiement introduite par EE 6.

L'une des critiques récurrente à l'encontre de la plate forme EE est sa lourdeur et sa fâcheuse tendance à accumuler les APIs peu maintenues, utilisées et élégantes par souci de rétro-compatibilité et de complétude.

Cela implique l'obligation pour les fournisseurs de serveurs d'application de proposer une implémentation pour chacune de celles-ci, qui seront ensuite déployées sur toutes les instances. Qu'elles soient utilisées ou non.

La spécification de la gestion des profils apporte la possibilité de configurer des types de déploiement standards ciblant des besoins précis. Ils définissent notamment les systèmes et APIs déployés et mis au service des applications. Ainsi, un bus d'entreprise ne nécessite certainement pas les technologies de vue comme les servlets ou JSF.

Le premier de ces profils à voir le jour est le "Web Profile" destiné à l'hébergement d'applications Web légères. Il se passe donc des APIs "entreprise" superflues telles que EJB2, JDO ou encore JMS.

Ne restent principalement que JPA, EJB3, JSF2, CDI et Beans Validation, tous utiles dans le cadre du développement web.

Cela permet à des serveurs d'application légers, comme Tomcat ou Caucho de se déclarer compatibles avec ce profil, bien que n'implémentant pas l'ensemble des spécifications EE6.

De ce fait, une application ciblant ce profil est d'autant plus portable et résistante aux changements futurs.

En outre, le temps de lancement et l'occupation en ressources du serveur d'application s'en trouvent réduits. Un avantage non-négligeable dans sa gestion des coûts et de la disponibilité.

Les développeurs ne sont pas en reste, le (re)lancement du serveur d'application étant récurrent dans le cadre de l'implémentation d'une application Web en Java. Le swap à chaud n'est malheureusement pas toujours applicable.

Le gain peut se révéler de l'ordre de la demi-heure par jour, ce qui est loin d'être négligeable.

Si par ailleurs, le projet est régulièrement déployé sur un serveur d'intégration continue, le temps gagné peut permettre un rythme plus soutenu de test sans engendrer de coûts supplémentaires. Et ainsi mettre en évidence plus rapidement la moindre régression détectée.

Il intéressant de noter que la majorité des fournisseurs de serveurs d'application reposent leur gestion des profils sur OSGi.

Utilisant un même standard de plugins, les fournisseurs partagent facilement leur travail.

"Web Profile" sera bientôt rejoint par de profils destinés à bien d'autres usages qui bénéficieront alors de tous les avantages suscités en terme de flexibilité et de performance.

Comment JavaEE 6 m'a rendu ma productivité.

Disponible depuis la fin de l'année dernière notamment au sein de l'implementation de référence Glassfish 3 de Sun (désormais Oracle) et JBoss AS6, Java EE 6 apporte son lot de nouveautés et dépoussière heureusement une plate-forme trop souvent perçue comme vieillissante.

Java EE souffre notamment d'une image d'usine à gaz dont les anciennes APIs sont intrusives, inélégantes et compliquées (JDO, EJB2...). En outre, elles demandaient aux développeurs un effort de configuration (XM Hell) certain, du fait de leur (trop?) grande abstraction et flexibilité.

EE 5 a grandement amélioré la situation avec l'introduction d'API modernes basées sur le principe de "convention over configuration". On peut citer notamment JPA et EJB 3.

EE6 poursuit cette simplification sur tous les fronts avec la mise à jour des nouveautés introduites par la 5eme version, l'ajout d'un système d'injection de dépendances et de gestion de contextes stateful et la mise à jour de JSF introduisant la gestion d'Ajax.

Le déploiement n'est pas oublié puisque les spécifications définissent des profiles serveurs type, notamment le "Web Profile" qui se passe des API trop "corporate" comme les ESB ou EJB2.

Ces avancées ont transforme JEE en une plate forme concurrentielle pour le développement de site de petite à moyenne taille, là où elle se destinait jusqu'alors aux grands comptes.

Comparé en terme de productivité à Rails, Django ou CakePHP, JSF2+Weld+JPA semble largement à la hauteur avec son écosystème d'outils de conception, ses performances inégalables et sa maturité.

Pour les geeks : c'est tres peu verbeux, je vous l'assure.

Une série de posts sera consacrée aux détails des changements et à leur intérêt en terme de productivité.

News and noteworthy in the SeedKit land

Due to my current professional engagements, SeedKit development slowed down the last few week on my side.

This did not stop others to take the flame with contributions from Javier Jardón and Elliot Smith related to the build system (autotools).

Also a first third-party application is currently being developed by Alan Forbes. This log viewer is a great showcase for SeedKit. Thumbs up.

Announcing SeedKit project.

Those last few days, I had the oportunity to spend some time on my pet projects. Being far enough for now and waiting gladly for some external help, I am ready to announce one of them : SeedKit.

SeedKit is a runtime environment for hybrid Web-ui/GObject applications.

Taking advantage of Seed bug #612590, SeedKit provides a Webview whose Javascript context is filled with Seed-provided GObject symbols.

It makes possible the creation of a ui using standard Web technologies, such as JS, CSS3 and HTML5 bound to lower level events and behaviours of GObject based libs and DBus services (WIP).

All it requires is the path to an html file (defaulting to ui.html in CWD). This file can include js files calling into GIR-provided symbols.

You can pass --inspector to be able to inspect dom elements dynamically and --script=file.js for a custom initialization javascript file.
Some samples (Notifications, GIO, DBus...)are provided in the examples dir.

The project is still in its infacy and suffers from serious issues. Notably the DBus binding is not in a working state, seems like the js context is cleared after first-level imports or something.

TODO (as of now) :
- define a system-wide css file for common theming.
- add a developer mode, with reloading button

- create a bug tracker, an agile management tool, a website, ML
- fix DBus binding (exposes a customly created dbus connection within native code ?)
- add samples of web-services integration ( Evolution Contacts on a google map ?)
- a runtime for widgets ?
- see what s come next :)

The sources can be grabbed at http://gitorious.org/seedkit and you can mail me at scaroo@gmail.com, in the wait of a proper ML.

Any code, help or idea appreciated. Contributions welcomed :)

Cloud computing : vers une industrie de la transformation de ressources ?

A la lecture de cet article et dans le cadre d'un projet personnel, je me suis fais la réflexion suivante : proposer un service hébergé sur une plate-forme cloud n'est-il pas comparable à l'industrie de transformation de matières premières ?

Avant d'essayer d'y répondre, faisons un point sur ce qu'est le cloud, ou du moins la façon dont je l'envisage.

La tête dans les nuages

L'hébergement d'une application sur le cloud implique un paiement à la demande : seules les ressources réellement consommées sont facturées.

Les cycles CPU, le stockage et les transferts réseau sont souvent les ressources quantifiables, unités de la facturation.

Cette approche est à comparer avec celle, plus classique, consistant à payer un forfait mensuel, voire annuel, quelque soit la charge effectivement utilisée.

En outre, l'approche cloud apporte de l'élasticité, de la scalabilite puisque des ressources supplémentaires peuvent être allouées de manière (quasi-)transparente en cas d'un besoin ponctuel supérieur.

Enfin, une bonne partie des tâches d'administration et de garantie de disponibilité sont déléguées au fournisseur.

Ce modèle économique permet notamment de supprimer les frais initiaux (pas d'achat de serveur), de lisser et réduire les frais et de se concentrer sur le coeur de son métier, sans ce soucier des problématiques orthogonales que sont l'hébergement et la garantie de service.

Cloud Factory

Imaginons maintenant le cas d'un service web hébergé sur ce type de plate-forme. Imaginons aussi, dans un premier temps, que son fournisseur s'oriente vers une facturation forfaitaire de ses clients. Il parie donc sur le fait que le forfait mensuel payé par chaque client couvrira les coûts en ressources induits par son utilisation du service.
Il y a donc un risque que l'activité ne se révèle pas rentable, voire déficitaire. Le fournisseur peut minorer ce risque en misant sur la mutualisation et en imposant des règles d'utilisation limitant ce dépassement éventuel.

Il reste malgré tout une zone d'incertitude.

A contrario, l'éditeur peut opter pour une facturation à la demande, au même titre que ses propres frais d'hébergement. Ainsi, l'utilisateur ne paierait que la quantité de service auquel il a fait appel. Par exemple, un service de conversion de devises ou l'utilisateur serait facturé pour chaque conversion effectuée. Cette somme doit bien entendu être définie en fonction du coût engendré par une telle requête.

Avec un peu de recul, on peut dire que le fournisseur effectue la transformation, la combinaison et la valorisation de ressources brutes (CPU, réseau, mémoire, stockage) en produit transformé (conversion) consommable par l'utilisateur. Le tout en flux tendu. Ces produits sont alors vendu sous forme packagée, de manière unitaire et sans le moindre stockage.
Cela vous rappelle quelque chose ? Et oui, l'application hébergée sur le cloud est foncièrement devenue une usine de transformation comparable à celles du secteur de l'industrie ou de l'agronomie.

Du coup, il serait judicieux de s'appuyer sur les nombreux enseignements, modèles et outils du domaine industriel pour optimiser son activité de prestation de service sur le cloud. Non ?

EDIT : rephrasage, correction de fautes.