Taverne d'Arma

Gradle, un bel outil

Armaklan — Fri, 13 Apr 2012 10:16:00 +0200

Au travail, j'ai le « bonheur » d'utilisé Ant et son scripting fait de façon manuel et donc assez coûteux. J'ai déjà pu avoir une approche de Maven dont l'idée globale m'avais séduit (gestion de dépendance, projet archetype, …). L'implémentation et la lourdeur m'avais par contre un peu rebuté.

J'ai donc décidé d'approcher Gradle pour voir ce qu'il avait dans les tripes.

Kesako ?

Gradle est un outil de gestion de livraison. Son objectif est donc de récupérer les différentes sources, de les compiler, et de packager tout ça en jar, ear, … Bien sur, Gradle ne s'arrête pas là, il vous offre également une gestion de dépendance => Vous indiquez de quelles librairies vous avez besoin, et Gradle vous la récupère ainsi que toutes ses dépendances !

Gradle se veut presque aussi puissant qu'un maven, tout en restant très flexible (presque autant que Ant!)

Utiliser la bête

Attention, je ne compte pas effectuer ici un tutorial complet mais juste vous donnez un aperçu de la bête.

Installation

L'installation de Gradle sur Windows est assez simple : il suffit de télécharger l'archive, de la dezipper, et de rajouter le dossier nouvellement crée dans le Path. Une nouvelle commande sera ainsi à disposition : gradle. Cette commande peut prendre différent paramètre, le plus important d'entre eux correspond à la tache à exécuter :

gradle build effectuera la compilation, le packaging et les tests
gradle test se contentera de compiler et de lancer les tests
gradle assemble fera le package sans tester

Il y a bien sur beaucoup d'autre tache, mais il sera plus rare de les appeler.

Paramétrer un packaging

Bien, mais pour l'instant votre build ne va pas fonctionner. Pourquoi ? Il faut tout simplement donner quelques informations de base en crée un fichier build.gradle.

Il faut tout d'abord associer ce qu'on appelle un plugin. Ce plugin va importer avec lui un ensemble de tâche et de paramétrage. Dans un projet Java, il faut importer le plugin du langage en rajoutant dans le build :

apply plugin: 'java'

Une fois cette simple tâche utilisé, gradle va rechercher vos sources et essayer de les compiler. Par défaut, gradle utilise les dossiers suivants :

src/main/java
src/main/resources
src/test/java
src/test/resources

Gradle s’attend donc à avoir deux dossiers de sources (test et main) et les fichiers ressources associés. Le modèle est ici le même que celui de Maven. Il est toutefois très facile de modifier l'emplacement des dossiers de cette manière :

    sourceSets {
        main {
            java {
                srcDir 'src/'
            }
	resources {
                srcDir 'resources/'
            }
        }
        test {
            java {
                srcDir 'test/'
            }
        }
    }

Donc ici, Gradle va rechercher les sources et les compiler. Mais qu'en est-il des dépendances ? Il faut également lui préciser. Vous pouvez le faire de cette manière :

	compile 'com.sun.faces:jsf-impl:2.0.9',
                'com.sun.faces:jsf-api:2.0.9'
	runtime 'jstl:jstl:1.2'
	testRuntime 'org.apache.geronimo.specs:geronimo-activation_1.1_spec:1.1'
	testCompile "junit:junit:4+"

Dans cet exemple, j'ai introduit les 4 niveaux de dépendance standard :

compile quand vous en avez besoin à la compilation runtime quand vous en avez besoin à l'exécution. Inutile ici de remettre ce que vous avez mis en compilation. Les mêmes précéder de test pour tout ce qui concerne vos tests unitaires (junit ou testng)

Simple non ?

À noter que dans mon cas, j'ai choisis d'utiliser les repositories maven. J'ai donc rajouter ceci :

    repositories {
        mavenCentral()
    }

Gradle et mes sueurs froides

Histoire de faire simple, je me suis alors lancer dans un build multi-projet J2EE (avec EJB, Web, et Shared) qui avait été construit jusqu'alors par eclipse sans outils de gestion de dépendances. Commencer par ceci pour un premier exercice était sûrement un peu masochiste, mais c'était le meilleur cas pratique que j'avais pour prouver l'utilité de l'outil à mon travail:)

Malheureusement, Gradle est encore jeune et il est difficile de trouver des exemples pour des applications J2EE... Autant dire que paramétrer ce build a été loin d'être simple. Il m'a fallut à peine une soirée pour avoir un projet qui compilait, par contre il m'a fallu plus longtemps pour arriver à le packager correctement.

Après plusieurs heures de recherche, je suis tombé toutefois sur la commande magique :

deploy project(path: ':LissageWEB', configuration: 'archives')

Ce qui est important dans cette ligne est « configuration : 'archives' » qui indique à Gradle que je veux packager le war, et non uniquement un jar qui contient les sources. Malheureusement cette ligne n'est pas dans la documentation (ou en tout cas, je ne l'ai pas trouvé) et il a fallu que je traine sur des forums pour trouver l'origine de mon problème.

Fichier gradle final par ici

Interfacer avec des IDEs ?

Ce point fera l'objet d'un article à part ou j'expliquerai, avec mon cas tordu, comment interface avec les IDEs eclipse et netbeans. Suite donc dans les prochains jours.

Synthèse

La documentation du site plutôt bien foutu
La lisibilité du fichier de build
La simplicité d'utilisation
Flexibilité

La jeunesse de l'outil
Flexibilité (risque d'avoir des builds tordus et non maintenable)

Et si Java pouvais être simple, finalement ?

Armaklan — Mon, 02 Apr 2012 16:37:00 +0200

Dans mon avant-dernier post, j'ai relâché tout le mal que j'avais vis-à-vis de Java. Maintenant que c'est fait, je vais m'attacher tout seul à me montrer que j'ai tort ! Comment ? Je vais refaire un peu de Java en perturbant intégralement l'eco-système que j'utilise au boulot.

Exit donc Spring, Hibernate, Eclipse, Ant, … Et bonjour de nouveau logiciel qui me semble plus simple et user friendly. Chaque nouveau logiciel fera l'objet d'un petit article par ici.

Voilà pour l'instant les points que je pense aborder :

Packager en douceur avec Gradle
Faire du Web simplement avec Play
Coder avec légèreté avec Jedit
Versionner sans se prendre la tête avec Bazar

Mes titres ne sont pas forcément réaliste hein, c'est juste l'expression de mes rêves;)

Si jamais vous avez des idées de logiciels/framework à inclure dans cette liste, ou si vous voulez contestez mon choix, n’hésitez pas ! Les commentaires sont là pour ça :)

J'ai déjà commencé à jouez avec Gradle, l'article devrait donc suivre demain ou après-demain.

Pluxml, un CMS lite

Armaklan — Sun, 19 Feb 2012 01:07:00 +0100

Bienvenue à Pluxml comme CMS permettant la génération du blog. Exit l'usine à gaz Wordpress que j'avais avant pour plus de légereté et de flexibilité. Quelques mots sur un CMS qui gagne à être connu !

Si vous êtes déjà passé sur ce blog avant ce jour, vous n’aurez aucune difficulté à cerner un changement majeur : le blog à migrer de wordpress vers pluxml.

Pluxml est un CMS orienté blog qui possède les avantages suivants :

Pas de base de données : Pluxml utilise un stockage sous forme de fichier XML. Facile à sauvegarder et à restaurer !
Bonne réactivité du site généré : Ici, pas de requête ou de fonctionnalité inutilisé, on se concentre sur le principal pour obtenir une fluidité sans égal.
Blog lite facile à utiliser : Le temps de prise en main du blog est vraiment réduit ! Au bout de quelques heures on se surprend déjà à refaire le thème sans aucune appréhension.

Biensur, ces avantages viennent avec leur pendant négatif : pour toutes les fonctionnalités avancés il faut mettre les mains dans le cambouis. Mais c’est justement ça qui fait sa force ! Tout à été pensé pour que les rouages de ce CMS soit facilement abordable et modifiable.

Vous êtes un utilisateur n’ayant aucune notion d’informatique et voulant un blog avec des tas de widget et pas mal de personnalisation sans modifier de code ? Passer votre chemin, Pluxml ne vous conviendra pas.

Vous voulez un site léger ? Vous n’avez pas peur de modifier un peu de code ? Vous avez envie de personnaliser votre blog à 100% ? Alors Pluxml est fait pour vous !

Plus d’info sur Pluxml par ici : http://www.pluxml.org/

Sur ces quelques mots, je vous souhaite une bonne navigation. N’hésitez pas à me faire des retours sur le nouveau design du blog :)

Pourquoi je n’aime pas Java

Armaklan — Thu, 16 Feb 2012 10:58:00 +0100

Je n’aime pas Java. Pourtant il s’agit du langage où mon expertise est le plus pointu ! j’ai en effet commencé le Java il y a 5 ans. Depuis maintenant 3 ans j’en fais un usage intensif dans le cadre professionnel.

Quand je dit ici que je n’aime pas le java, je parle de l’eco-système Java, pas du langage. A vrai dire mon impression s’arrête plutôt du coté Java EE, vu que je l’ai toujours utilisé dans ce cadre.

Cette article explique ce que je n'aime pas dans Java, dans l'espoir qu'on viennent me contredire vu que je vais encore bosser avec ce langage ! :)

Java, le monde de la branlette intellectuelle

Pour moi, Java, c’est ça ! Un monde où on passe plus de temps à penser de belles architectures, des architectures robustes, modulaire, soit disant maintenable, en oubliant son vrai besoin et le confort du développeur.

Durant mes années de travail, j’ai pu voir des applications en 5-6 couches avec des objets de données (réduit à leur plus simple expression, c’est à dire juste porteur de donnée) sont transformé par adapter en des DTO pour le passage à la couche suivante. Normal me direz vous si on est dans un cadre « service» ou la réutilisabilité des couches est essentiel. Sauf que non, nous étions dans une application « block » ou les couches étaient vraiment réservé et spécifique à notre application.

J’ai pu également me heurter aux applications EAR avec leur étrange structure/séparation EAR, Web, Module, … Cette étrange séparation qui rend parfois la gestion des dépendances complexe. Ce matin encore je me suis prit la tête avec une annotation qui ne s’appliquait pas à l’ensemble des éléments.

La raison ? L’annotation était dans un JAR et, même si elle était bien dans tous les build path, je ne l’avais pas packagé au bon endroit dans l’EAR pour qu’elle soit appliqué à toutes les classes. En l’occurrence c’était mes classes du projet EJB qui était oublié.

L’exemple ci-dessus n’est qu’un exemple parmi d’autre. Mais dans le monde Java, il y a des tas de préconisation et de norme d’architecture que l’on ne s’imposerait pas dans d’autre technologie…

Oh, un dernier point… A quoi ça sert de découper en des dizaines de petits jars qui sont, au final, tellement lié entre eux que l’insertion d’un jar entraîne automatiquement l’insertion du second ? Essayez d’introduire Spring dans votre projet et vous comprendrez. Pas de tricherie, faites le sans un gestionnaire de dépendance tel que Maven ! Au final vous verrez que, en plus du spring « core», vous aurez embarquez 5-6 autres jar de spring (je ne compte pas les dépendances externes que je comprend parfaitement).

Java, le monde du framework faussement simple

Autre chose que je déteste dans Java ? Les frameworks !

Ne vous trompez pas, je ne suis pas pro from-scratch. J’aime les frameworks qui me facilite le travail. Malheureusement, j’ai du mal à rentrer les frameworks Java dans cette catégorie. Pourquoi ?

Voilà comment se sont déroulées toutes mes expériences d’intégration de framework :

J’intègre le framework. Je me rends alors compte qu’il faut faire un fichier XML de paramétrage obligatoire d’environ 10 km de long. Je prends des tutoriels, j’essaye de comprendre, je reproduis. Go, ça a l’air de marcher !
Je commence donc à travailler tranquillos ! Maintenant que j’en ai ***** pour le paramétrage, le framework me fait gagner du temps, c’est cool.
Et là, pof ! c’est le drame ! J’ai un comportement étrange :/ La recherche sur internet me faire dire que j’ai configuré de façon incomplète ou mal mon Framework.
Et hop c’est parti pour une seconde vague de configuration qui va me couter un bras pour faire marcher le tout. Ok, sur une grosse appli j’aurai peut être gagné du temps. Mais quand vous travaillez sur un tas de petites applications, là, ce n’est plus du tout sûr.

Ce dernier constat est celui qui me fait le plus bizarre : les frameworks java sont un gain de temps sur une grosse appli et une perte sur une petite application. Je vais voir coté Python, langage que j’apprécie, et c’est tout l’inverse ! On préconisera un framework pour les petites appli ! A vrai dire, rien d’étonnant ! C’est dans les petits appli que l’on n’a pas le temps d’investir !

Ok, dans mon exemple le réel problème se situe dans mes compétences : j’ai beau être un développeur expérimenté je n’ai encore que peu de recul sur le paramétrage de Framework. En même temps je n’ai pas besoin d’avoir ce recul dans les autres langages…

Mon ressenti concernant les framework Java, c’est qu’ils ont la philosophie inverse du KISS unix que j’apprécie temps => 1 programme = 1 fonction. Les frameworks java veulent faire le code du développeur, le café, et le massage de pieds… Manque de post, moi le massage, ils me les cassent !

La java et son héritage de lourdeur

Dernier point, je pense que l’héritage Java (qui assure une rétro compatibilité quasi totale) est nuisible sur le long terme. On se trimbale beaucoup de difficulté « historique » qui alourdisse inutilement le langage.

Un exemple ? Essayer de manipuler des Buffers par exemple !

Ce n’est pas la seule fonctionnalité qui est difficile à manipuler et entraîne la création de nombreux objets pour « pas grand chose ».

Je sais que ce post est un peu « troll », mais depuis le temps que je me casse les dents sur ces problèmes, il fallait que ça sorte ! Après je me ferai un plaisir de lire vos commentaire qui, peut être, viendront me faire comprendre que mon impression découle uniquement de mon cadre projet.

Frugalware, une distribution qui mériterai d'être plus connu

Armaklan — Mon, 24 Oct 2011 10:53:00 +0200

Et voilà, après une courte période sur ArchLinux me voilà reparti sur une autre distribution.

Laissez moi vous présenter ici la "petite" distribution Frugalware. Proche d'ArchLinux dans sa philisophie, Frugalware se trouve a mi-chemin entre une distribution grand public et une distribution from Scratch.

Personnellement, cette distribution m'a conquis, et sa communauté encore plus !

Et voilà, après une courte période sur ArchLinux me voilà reparti sur une autre distribution.

Pourquoi donc ?

ArchLinux est une très bonne distribution qui possède de nombreux avantages :

Très grande fluidité
Diversité de paquet très impressionnant (grâce à AUR)

Mais pour moi qui ne suis encore qu’un néophyte en linux (bon ok, un néophytes ++ :p ), l’absence de pré-configuration ou d’interface d’admin est assez rédhibitoire. Certes je n’ai pas besoin d’un environnement aussi complet que celui livré par un Ubuntu ou une Fedora, mais tout de même, tout faire à la main me pose parfois soucis.

Bon, malgré tout ArchLinux reste pour moi le must dans les différentes distributions que j’ai testé. C’est donc tout naturellement que je me suis routé vers sa petite cousine, j’ai nommé Frugalware.

Etape 1 – Installation

L’installation de la Frugalware se fait intégralement en mode texte (interface mode texte, pas en ligne de commande tout de même). Les différentes questions qui sont posés sont basiques et similaires à ce que l’on retrouve pour d’autre distribution. Aucun soucis donc.

Après l’installation le système redémarre en mode console. Aie… Pour moi qui crains toujours l’install en console, je suis servi. Je lance tout de même la commande de synchronisation pacman (pacman –Su) et, ho, miracle, le système se met à jour sans soucis ! Vous vous demandez surement pourquoi j’ai autant d’appréhension face au monde console ? La réponse est simple, mon pc dispose uniquement du Wifi et configurer le wifi en console, c’est un calvaire pour moi. Dans le cas de la Frugalware toutefois, la config Wifi a été faite durant l’installation et marche à merveille.

Une fois ceci fait j’ai suivi le guide de post-installation :

http://wiki.frugalware.org/index.php/Post-Installation_(Fran%C3%A7ais)

Au final le guide indique quels sont les paquets à installés. Aucune config particulière à faire, tout marche parfaitement y comprit X qui m’avait pourtant posé de nombreux soucis avec ArchLinux. Ici il m’a suffit d’installer les paquets du serveur X, les paquets de gnome également, un petit reboot et, oh, miracle, gnome-shell s’affiche directement.

Car oui, vous l’aurez comprit j’ai décidé de me remettre un peu à Gnome 3. Pour la plupart des environnements, les dépôts de FW mettent à dispo un paquet virtuel préinstallant un système complet. Avec un seul paquet nommé gnome, je me suis donc retrouvé avec gnome, les interfaces d’administrations, les principales extensions, et quelques applis. Un vrai bonheur J

A noter que je retrouve suite à ce premier boot une réactivité et une fluidité digne d’ArchLinux. Un boot complet en moins de 15 sec, franchement j’aime ! Première utilisation, tout marche : graphique, son, wifi, …

Ah si, j’ai eu un seul souci : j’ai eu la malencontreuse idée d’installer le driver catalyst pour ma carte ATI. En 64bit se driver plante ! Le souci ne vient pas de la FW, j’ai eu exactement le même sur la ArchLinux. Bref, je suis resté sur le driver libre qui fonctionne très bien.

Etape 2 : Migration vers current

En tant que bon geek, j’ai décidé ensuite de passer vers la version current de la distribution. La version current est un peu l’équivalent de la testing debian : elle permet d’avoir les derniers paquets à jours au prix de quelques bugs. La current est également une version en rolling release (contrairement à la FW stable).

Pour la migration, j’ai encore une fois suivi le guide :

http://frugalware.org/docs/upgrade.html

Quelques petites manip donc :

Modifier le dépôt cible
Mettre à jour
Mettre des configs d’appli à jour (sur mon système neuf, je n’ai rien eu à faire)
Modifier légèrement grub (cause : un changement de techno pour la construction du noyau).

Je reboot, pas de problème et… Misère ! Mon wifi marche plus (problème n°1) et gnome se met à plantouiller (problème n°2).

Concernant le prb n°1, il s’agissait d’un soucis entre le network manager de gnome et ma carte wifi (mon wpa plus exactement). La désactivation du manager et l’utilisation d’une autre application (gnetconfig) a suffit à résoudre le souci.

Le prb n°2 vient uniquement d’extension qui n’est pas totalement compatible avec gnome mis à jour. Je les ai désactivé et plus aucun soucis depuis.

Vous noterez que les deux soucis ne sont pas directement liés à Frugalware mais plutôt à Gnome…

Etape 3 : Utilisations

Depuis maintenant une bonne semaine j’utilise donc la FW couplé à Gnome 3. Pour Gnome 3 je confirme mes premières impressions : l’environnement est bon mais manque encore un petit peu de maturité.

Concernant Frugalware, je suis agréablement surpris. Frugalware se trouve à mi-chemin entre une distribution expert (ou « fait tout toi-même ») et une distribution grand public. Il y a un peu de préconfig (ou de configuration pré-livré plus exactement) et quelques assistants (dont gfpm qui sert de frontend à pacman).

Frugalware n’a pas de support d’AUR et donc ne bénéficie pas d’autant de paquet qu’ArchLinux. C’est finalement le point qui me fait regretter un peu cette dernière. Toutefois les dev annoncent prendre en compte les besoins d’appli particulière dans les packagings, à voir ;)

Etape 4 : la communauté

Frugalware est une distribution agréable. Il y a toutefois un point que je veux souligner, un aspect qui actuellement me fait dire que je vais peut être enfin m’arrêter sur une distribution : la communauté.

Frugalware bénéficie d’une petite communauté française très sympathique. Celle-ci se réunit sur le forum du site http://frugalware.fr ou via le chan irc #frugalware.fr (freenode). Lors de mes différents problèmes (wifi et gnome), j’y ai trouvé des personnes pour me conseiller et tenter de m’aider. Avant l’installation j’avais déjà pu y poser quelques questions. En plus ce chan est hanté par plusieurs dev.

Bref, si il y a une raison pour laquelle je conseillerai vraiment la Frugalware, c’est pour son coté humain et convivial.

Txt2Tags - Le traitement de texte du futur !

Armaklan — Tue, 20 Sep 2011 10:49:00 +0200

Le titre de ce traitement de texte est quelques peu trompeur : je ne vais pas vous présenter le futur concurrent de Word ou de Libre Office. A vrai dire je ne vais pas vous parler d’un éditeur WYSIWYG mais d’un projet que j’aimerai voir se développer davantage : Txt2tags

Bon du coup, txt2tags kesako ?

Txt2tags est un petit programme permettant d’interprété des fichiers rédigés avec une syntaxe type wiki, et de générer ensuite des fichiers rtf, html, dokbook, bbcode, ou pdf (en passant par latex). Vous pouvez donc formater votre texte et le structuré très facilement sans avoir à toucher votre souris. La syntaxe s’apprend aisément et est très facile d’utilisation.

Les avantages ?

Moins de perte de temps : qui n’a jamais perdu de temps à cause d’un comportement étrange de word ?
Plusieurs types de fichier générable sans soucis.

A noter que txt2tags offrent aussi des mécanismes plus avancées pour gérer la mise en forme dans chaque format, ou l’ajout de nouvelles balises.

Plus d’info ici http://txt2tags.org/

Edit du 24 Septembre en réponse aux commentaires

Personnellement je m'en sert principalement pour deux types de choses :

Petit document

Première utilisation, généré de petit document que je souhaite avoir soit en pdf, soit en html. Ce sont en général des documents principalements texte qui vont être sur 3-4 pages, actuellement des documents perso mais je pense bientôt en faire une utilisation au boulot.

Par exemple, pour nos amis les rolistes, le document de présentation de mon univers de jeu de rôle, Mousquetaire de Sang, est généré via txt2tags. Visualisable ici : http://fusina-jdr.org/2011/09/presentation-de-mds/

Article de blog

Je prépare également les articles de blog tranquillement sur mon post. Ensuite je génère la version html et je copie celle-ci dans le champs de saisies du blog.

Pour les futur

J'envisage actuellement de migrer de très gros documents que j'ai en latex, vers txt2tags. Cela dit dans le Latex j'ai plusieurs balises maisons, ça va donc me demander pas mal de boulot de formatage de ses balises sur txt2tags. Donc ce n'est pas encore fait, mais j'y pense sérieusement ! :) -

Faire du Tilling sous Windows

Armaklan — Tue, 30 Aug 2011 10:47:00 +0200

J’ai eu l’occasion de gouter il y a peu à du Tilling sous Linux grâce à pytylling. Ce programme permet de positionner les fenetres “automatiquements” de façon à partager de manière optimum l’espace présent sur l’écran. Ce procédé est extrêmement pratique lorsque l’on a besoin de travailler avec plusieurs fenetres de “petit taille” tels que les fenetres de chats, les terminaux, les explorateurs des fichiers, …

Malheureusement, au travail on m’impose de travailler dans un environnement Windows où ce genre d’outils n’est pas disponible. En cherchant un peu, j’ai toutefois trouvé un logiciel permettant de faire quelques chose s’en approchant : WinSplit.

WinSplit permet en effet d’envoyer des fenetres sur des positions et des dimensions pré-parametré. Par exemple vous avez une zone “coin haut droit” avec deux dimensionnements possible : 20% de largeur, 50% de hauteur, ou, 40% de largeur, 50% de hauteur. Vous pouvez ensuite, grâce à un simple raccourci clavier, envoyer la fenetre active dans ce fameux coin. La fenetre prendra alors automatiquement le premier dimensionnement. Le même raccourci clavier vous permettra de switcher sur le second positionnement.

WinSplit est au final un utilitaire léger mais très agréable et très pratique.

Plus d’info sur le site du logiciel

Mon environnement de travail

Armaklan — Tue, 16 Aug 2011 10:44:00 +0200

Un bon environnement de travail est très important pour utiliser efficacement son ordinateur. C'est pour cette raison que je test fréquemment des outils ou utilitaire. Récemment, je viens de passer plusieurs journée à éplucher un peu les sites et blogs à la recherche de nouveaux outils et je viens de découvrir (rédécouvrir) pas mal de chose. Grâce à eux mon environnement c'est bien améliorer, à mon tour maintenant de partager !

Quel distribution ? CTKArch !

Point très important : le choix de la distribution ! Oui, j'utilise le terme de distribution car j'utilise Linux. Au travail on m'impose d'utiliser un Windows XP, mais au final je me retrouve régulièrement à bosser sur une VM Linux ? Pourquoi ? L'environnement Linux offre un grand nombre de possibilités difficile à mettre en place sur Windows : multi-bureau, tilling, package manager, ...

Pour installer mon poste de travail, j'utilise comme base la distribution "CTKArch". En réalité il ne s'agit pas d'une distribution. CTKArch est un live-cd de ArchLinux.

Pourquoi CTKArch et non pas directement ArchLinux ?

ArchLinux, par défaut, est un environnement "nu", sans couche graphique. C'est à l'utilisateur de faire son installation tels qu'il l'entend. L'utilisateur doit installer X et un gestionnaire de fenetre avant d'avoir accès à un environnement graphique. J'ai essayé mais je me heurte à plusieurs difficultés dont la première est un problème réseau : je dispose uniquement d'une connection Wifi, et configurer le wifi en mode console, c'est un peu difficile...

CTKArch me fourni donc un environnement pré-installé, prennant en charge mon matériel, et disposant par défaut d'un environnement graphique (OpenBox, mais là je vais y revenir). Grâce à CTKArch j'ai enfin pu tester ArchLinux, une distribution dont on me vantait les mérites depuis longtemps, et je ne suis pas deçus du voyage !

Pourquoi ArchLinux ?

ArchLinux est une distribution Linux dont le slogan est "Keep it simple and stupid". L'objectif de cette distribution est de donner à l'utilisateur un environnement simple, sans superflus. C'est l'utilisateur qui devra l'installer en fonction de ces besoins.

ArchLinux présente certains avantages :

Un temps de boot imbattable (- de 30 sec ! )
Rolling-Release (pas de "version" mais des mises à jours en continu).
Des paquets réèllements à jour. Le gestionnaire de paquet donne accès aux binaires, mais aussi au paquet à "compiler" (la compilation est géré par le gestionnaire).

Le principale (et seul en faite) défaut d'ArchLinux est qu'il faut tout configurer soit même. Pas de pré-configuration à l'installation. Ce choix peut donc causer quelques soucis aux utilisateurs néophytes (tels que moi). Le problème tourne principalement autour de certains services tels que l'impression, ou l'accéllération 3d.

Quel gestionnaire de fenêtre ? Openbox !

A l'origine j'utilisais l'environnement de bureau Gnome 2, et XFCE comme environnement pour vielle machine (ou VM). Récemment j'ai testé Gnome 3. J'apprécie beaucoup ce nouvel environnement et les possibilités qu'ils offrent. Toutefois Gnome 3 présente deux défauts qui me gène réèllement : l'obligation d'avoir une accéllération 3d, et la difficulté de personnalisation et de configuration de l'environnement.

Avec CTKArch, j'ai découvert un nouvel environnement : OpenBox. OpenBox est un gestionnaire de fenêtre léger et plutôt joli. Sa grande force : la facilité de personnalisation de l'environnement. Menu, Panel, Menu contextuel, Raccourci clavier, ... Tous les élements sont personnalisable à souhait. Enfin un gestionnaire où on peut crée NOTRE bureau ! En plus, CTKArch avait pré-installer plusieurs outils très utile (FBPanel par exemple).

L'outillage ?

L'outillage de bureau

Pour le bureau en lui-même, j'utilise l'outillage suivant :

Tint2 pour la barre des tâches
FBPanel pour la barre de Panel
Conky avec le thème orange lunatico pour le monitoring
Wicd pour le wifi
PcmanFm pour le navigateur de fichier.

Outillage internet

Chromium en navigateur
Pidgin pour la messagerie instantannée
Hotot pour le micro-blogging (Twitter)

Outillage bureautique

LibreOffice pour la rédaction de document en wysiwyg
Txt2tags pour la rédaction de documents qui seront portées sous différents formats
FreeMind pour les mindmaps
Mirage pour visualiser les images
RapidSVN pour la gestion de SVN

Txt2tags

Quelques mots rapide sur cet outils qui est très intéressant. Txt2tags est en fait un immense parser permettant de générer différents type de documents (rtf, latex, bbcode, html, ...) à partir d'une seule syntaxe de type "wiki".

Sans être allergique au éditeur Wysiwyg, je me rend compte que je suis bien plus concentré sur ce que j'écrit dans des éditeurs plus lite. La syntaxe Wysiwyg permet de prévoir la mise en forme, sans être toutefois trop invasif.