Archives de catégorie : DevOps

Développeur Frontend derrière un proxy

torx-272866_1920

Je viens du monde Java et ce qui me manque le plus lorsque je fais du développement frontend, c’est bien la maturité de l’écosystème. Et je le ressens beaucoup quand j’essaie de travailler derrière un proxy et que je me rends compte que chaque outil qui participe au buid de mon application utilise un paramétrage différent.

C’est en tentant de reprendre le squelette d’application Aurelia en Typescript que j’ai cherché tous les paramétrages ci-dessous.

Unix

Tout d’abord, il faut configurer le proxy système. Sous Linux, il suffit de déclarer les variables ci-dessous :

export http_proxy=http://proxy.host:8080/
export https_proxy=http://proxy.host:8080/

NPM

Pour la commande NPM, il suffit de créer un fichier « .npmrc » à la racine du répertoire utilisateur :

proxy=http://proxy.host:8080/

Typings

Il suffit de créer un fichier « .typingsrc » à la racine du répertoire utilisateur :

proxy=http://proxy.host:8080/

JSPM

Pour JSPM, si vous avez bien suivi le paramétrage Unix ci-dessus, ça devrait fonctionner (sachant que le piège se trouve dans au niveau du proxy HTTPS qui doit utiliser le protocole « http » simple).

Maven et la Javadoc

blog_header_javadoc
Voici une commande Maven qui dépanne bien pour compléter la Javadoc intégré à mon IDE préféré (en l’occurrence Netbeans).

Souvent, sur un projet Maven, on ajoute des dépendances sur tout un tas de librairies et, à chaque fois, on implore les dieux pour que la Javadoc vienne avec la librairie et soit directement intégré à l’IDE. Ça nous éviterait de bookmarker toutes les Javadoc en ligne :

blog_completion2

Bon, ça va pas venir automatiquement mais il suffit de lancer la commande Maven ci-dessous pour télécharger toutes ces Javadoc :

mvn dependency:resolve -Dclassifier=javadoc

A noter, qu’il est possible de télécharger les sources également (si vous aimez passer au débugger tout ce qui vous passe sous la main) avec la commande :

mvn dependency:resolve -Dclassifier=sources

Toutes les archives téléchargées se trouvent alors dans le repository local de Maven.

BeanMill ou une autre vision des logs

blog_header_beanmill
Ah les fichiers de logs, les rotations de fichiers, les commandes tail sous Windows. Un fichier de log, c’est bien sur un serveur mais sur le poste du développeur, c’est tout bonnement impraticable. Et c’est en rouvrant mon Netbeans préféré que j’ai découvert le plugin BeanMill.

Je n’ai pas compris du premier coup mais c’est en fait très simple. Lorsque le plugin est installé, l’IDE se comporte alors comme un serveur de log. Finalement, il n’y a plus qu’à modifier la configuration des logs sur l’application que nous sommes en train de façonner. Par exemple, si il s’agit d’une configuration log4j, ajouter l’appender suivant au rootLogger pour voir la magie opérer :

# Log Event appender
log4j.appender.sockets=org.apache.log4j.net.SocketAppender
log4j.appender.sockets.remoteHost=localhost
log4j.appender.sockets.port=4445
log4j.appender.sockets.locationInfo=true

log4j.rootLogger=INFO, sockets

Dorénavant, l’onglet BeanMill présentera les évènements de log et nous pouvons les filtrer en fonction du contenu de chaque message, nous pouvons affecter des niveaux de trace différents en fonction des packages et le tout dans un rendu coloré qui saute aux yeux.

beanmill

Je vous préviens, l’utilisation de ce plugin est fortement addictif mais sans effet secondaire sur la santé.

Simple Git

Capture du 2013-02-02 17:49:22
Git est connu pour apporter une nouvelle façon de penser le travail collaboratif. Lui et et sa bande de copains que sont les gestionnaires de sources décentralisés ont définis de nouvelles organisations comme le « Integration-Manager Workflow » ou « Dictator and Lieutenant Workflow ». Ces workflows définissent des responsables pour les étapes de merge libérant ainsi le développeur de cette tache.

Oui mais (parce qu’il en faut toujours un) lorsqu’on passe d’un outil centralisé comme Subversion à Git, on ne change pas toute l’organisation. La création des branches conservent le même rythme et chaque développeur n’aura pas son dépôt publique de si tôt. C’est une habitude purement centralisée avec des branches par version qui sont souvent conservé. Cet article se veut être le guide de survie du Git centralisé en résumant les commandes élémentaires et nécessaire de connaître.

  • git clone

C’est la première étape qui va vous permettre de cloner le dépôt à partir duquel vous souhaitez travailler.

git clone ssh://host:/mondepot
  • git checkout

Cette commande va vous permettre de sélectionner la branche dans laquelle travailler. En effet, c’est l’ensemble du dépôt que vous avez cloné et pas uniquement une branche.

git checkout branch-new-feature
  • git add

Vous venez de créer et modifier des fichiers dans votre espace de travail. La commande « add » va faire passer ces modifications dans l’espace de « staging ».

Il faut bien concevoir que lorsqu’on travail en local avec Git, on dispose de 3 espaces : l’espace de travail qui sont les répertoires et fichiers que nous manipulons directement, le dépôt qui est une copie du dépôt distant et qui enregistre les commits et il y a le « staging » (ou « index ») qui est une zone intermédiaire qui traque les fichiers qui vont faire parti du prochain commit

vi README
git add README
  • git commit

La commande ressemble à celle des autres gestionnaires de sources. Et elle fait la même chose, elle enregistre les modifications associés à un message dans le dépôt mais uniquement dans votre copie locale du dépôt.

git commit

Pour que le commit prenne en compte les fichiers modifiés dans votre espace de travail mais non transité dans l’index, vous pouvez utiliser l’option « -a » (attention, ça ne prend pas en compte les nouveaux fichiers uniquement les modifiés).

  • git push

Votre dépôt local a enregistré une série de commit et vous êtes satisfait de vos développements, il ne vous reste plus qu’à les envoyer sur le dépôt officiel avec cette simple commande :

git push

Git reprend la source de la commande c »clone » pour savoir où envoyer les commits enregistrés dans votre dépôt. Si d’autres commit ont été « pushés » avant vous sur le dépôt distant (à partir du moment où vous l’avez cloné), il faudra alors mettre votre dépôt à jour avant de pouvoir envoyer quoique ce soit.

  • git pull

C’est la commande qui permet de mettre à jour le dépôt local à partir du dépôt distant. Dans le cas le plus simple (vous n’avez pas de modification sur votre dépôt local), la commande rapatrie toutes les modifications du dépôt. Si des modifications locales il existe, deux modes de fonctionnement il existe :

  1. En invoquant la commande sans option, nous faisons alors un « pull » en mode « merge ». Lorsque les commits distants sont rapatriés sur votre dépôt local, un commit supplémentaire contenant le résultat du merge automatique est créé.
  2. En invoquant la commande avec l’option « –rebase », nous faisons alors un « pull » en mode « rebase ». Lorsque les commits distants sont rapatriés sur votre dépôt local, vos commits locaux sont déplacés au sommets des commits et comprennent le résultat du merge automatique

Dans les deux cas, si le merge automatique ne fonctionne pas, la commande « pull » signalera les fichiers en conflit. Comme avec Subversion les fichiers en question seront marqués avec des extraits de la version local et distante et ce sera à vous de résoudre le conflit. Une fois un fichier résolu, il suffit de l’ajouter dans l’index avec la commande « add ».

Une fois tous les conflits résolus, s’il s’agissait d’un « pull » en mode « merge » et il ne reste plus qu’à commiter le merge avec la commande « commit ». Sinon, c’était un « pull » en mode « rebase » et il faut terminer le rebase :

git rebase --continue

Dans le cas d’une utilisation en mode centralisé, je pense qu’il est préférable d’utiliser des « pull » en mode « rebase ». En effet, sinon le dépôt laisse apparaitre des commits de merge qui n’ont pas vraiment de sens puisqu’aucune branche n’a réellement été mergé (même si dans les faits votre dépôt local est considéré comme une branche par Git).

Besoin de quelques références sur Git :
http://git-scm.com/book
http://blog.octo.com/git-dans-la-pratique-22/

Velocity, si c’est pas null


Si au vu du titre, vous vous attendiez à trouver un jugement sur le langage de template Velocity, passez votre chemin. Il s’agit juste d’un petit rappel pour moi même pour avoir le test absolu pour vérifier si une variable est null (non définie) ou vide (chaîne de caractère vide) :

#if($car && $car == "")

Source : http://www.mail-archive.com/velocity-user@jakarta.apache.org/msg13790.html

CSS : tous en bloque et en ligne

Voici le petit hack dont il faut se souvenir avoir une propriété « display: inline-block; » qui fonctionne sous Internet Explorer. Il faut l’ajouter les propriétés suivante :

    *display:inline; 
    zoom:1; /* "inline-block" for IE6/7 */

Et pendant que j’y suis, la valeur « auto » sur la propriété « margin » ne fonctionne sous IE que si le parent a une propriété « text-align: center » de positionné.

Sources :

http://robertnyman.com/2010/02/24/css-display-inline-block-why-it-rocks-and-why-it-sucks/

http://forum.alsacreations.com/topic-4-40741-1-Probleme-IE8—margin–0-auto-.html

Postgres et ses séquences


C’est un petit truc à savoir mais ça peut rendre chèvre si on ne le sait pas.

Lorsque vous faites un dump d’une base PostgreSQL avce par exemple PHPPGAdmin, les dernières lignes du fichier généré sont là pour mettre à jour les séquences de la base de données.

Oui mais voilà, de temps en temps, ces lignes sont de la forme :

SELECT pg_catalog.setval('seq_role', 100, true);

Et les autres fois, ça sera de la forme :

SELECT pg_catalog.setval('seq_role', 100, false);

Si vous modifiez le script à la main après l’avoir dumpé, faites attention, ce flag qui prend la valeur « true » ou « false » définit si la valeur passée en paramètre est la suivante qui sera fournie par la séuqence ou si c’est la précédente valeur.

-- le prochain appel retournera 101
SELECT pg_catalog.setval('seq_role', 100, true); 

-- le prochain appel retournera 100
SELECT pg_catalog.setval('seq_role', 100, false);

Pensez-y quand vous aurez vos prochaines violations de contraintes.

Netbeans ne passera pas à côté d’Unity

Si parmis les IDE gratuits, comme moi, votre préférence se porte sur Netbeans (déjà je vous aimes bien car, d’une part, je n’en rencontre pas si souvent, et d’autre part, comme tout être humain, j’aime ceux qui me ressemble 😉 ). Et si comme moi, vous avez abandonné le système aux « fenêtres » pour quelque chose d’un peu plus underground comme Ubuntu, alors cet article va vous intéresser.

Vous n’êtes pas sans savoir que le bureau officiel d’Ubuntu est maintenant, et depuis quelques versions, Unity. Et vous avez sûrement remarqué que les menus des applications sont intégrés à la barre principale de l’OS (qui fait maintenant office de barre de titre des fenêtres, menu de la fenêtre, barre de notification et menu du système). Si vous avez bien poussé la porte de la 12.04, vous devriez pas avoir loupé le nouveau système de recherche indexée HUD qui permet de rechercher dans les menus des applications sans avoir à les retenir par cœur. Bref, c’est génial mais, ça ne fonctionne pas pour les applications Java comme Netbeans.

N’étant pas le premier Java Geek, d’autres sont passé avant moi pour intégrer la barre de menu de Netbeans à HUD. Et c’est Dan Jared qui, après avoir indiqué sur son blog comment installer son plugin Java Ayatana pour Netbeans (http://danjared.wordpress.com/netbeans/), semble avoir finalement distribuer ce plugin dans l’update center d’Oracle (http://plugins.netbeans.org/plugin/41822/java-ayatana).

Pour rappel, Ayatana est le nom donné par la communauté Ubuntu pour unifier tous les efforts faits autour l’intégration d’Unity. Ca va du menu global dont on vient de parler dans le cas de Netbeans jusqu’au notifications (https://wiki.ubuntu.com/Ayatana). Notre ami maintient la librairie qui va vous permettre d’intégrer les menu Swing dans le menu global d’Unity : http://code.google.com/p/java-swing-ayatana/

 

 

Git : Le commit qui fait mal

Imaginez-vous, un soir, vous êtes mal luné et vous remonté un fichier personnel qui vous a servi à faire vos tests dans votre gestionnaire de source. Les développements avancent. D’itération en itération, votre fichier personnel est trimbalé jusqu’au jour où arrive la livraison et que votre fichier personnel se retrouve dans le livrable de votre client.

Bon, c’est vrai, je pousse la caricature un peu loin. Si votre est arrivé jusque là, c’est qu’il n’avais pas tant d’importance que ça ce fichier. Ou alors, vous vouliez parfaitement illustrer mon propos à vos collègues. Dans ce cas, je ne peux que vous en remercier.

Toujours est-il que la trace de votre fichier sera toujours visible dans ce satané commit. Et les futurs développeurs de votre projet (dont vous serez peut-être le chef dans 5-10 ans) sera toujours accessible. Heureusement, je viens de tomber sur la commande magique de Git :

git filter-branch --tree-filter 'rm -f my_file' HEAD

Le fichier my_file aura alors disparu de tous vos commits. Et la prochaine fois, vous éviterez de mélanger le boulot avec votre vie personnelle.

 

Redmine, Rails, Warbler, JBoss : la magie de JRuby

J’ai toujours regreté de ne pas trouver un outil de bug tracking Open Source et sympa dans l’écosystème Java. Certes, il y a bien Jira qui offre une licence au projet Open Source (je trouve que c’est d’ailleurs une très bonne démarche de leur part qui permet de conserver leur business model tout en soutenant la communauté). Mais c’est bien loin de mon business model personnel composé à 80% de vaporware.

De plus, j’ai toujours été attiré, intrigué, piqué au vif par Redmine. Les quelques heures de prise en main que j’ai pu en faire m’ont fait très bonne impression. Il n’a pas l’air aussi personnalisable que Jira mais l’interface respire la simplicité et l’évidence, je ne me suis jamais posé de question sur ce que je faisais.

Je désespérais donc de trouver un outil équivalent à déployer sous mon JBoss ou mon Tomcat et j’en venais à la conclusion, mainte fois partagé, que finalement on est jamais mieux servi que par soi-même. Et là, je suis tombé sur cet article et ma vie a changée :

http://www.javacodegeeks.com/2012/02/redmine-installation-getting-started.html

Et toute cette magie repose sur Warbler un gem à installer qui permet d’encapsuler les applications Rails dans un package war. Le tout utilisant JRuby pour l’exécution. Et je garantie que les explications données dans l’article ci-dessus fonctionne à merveille pour un Redmine 1.3.1 déployé sur un JBoss 7.1.0. Et pour avoir un peu plus de détail sur le fonctionnement de Warbler :

http://jrubyist.wordpress.com/2009/10/15/using-jruby-warbler-rake-to-deploy-rails-apps-to-jboss/