Blogounage

Mon avis sur le livre "Apache Maven" de Nicolas De Loof et Arnaud Héritier

batmat — Wed, 17 Mar 2010 19:30:00 +0100

J'ai lu le livre Apache Maven, édité chez Pearson. Pour un premier livre en français sur Maven, on peut dire que l'expérience est globalement très réussie.

Mon expérience de maven

Disons-le tout de suite, je ne suis pas néophyte sur Maven. J'ai été utilisateur de maven 1 un tout petit peu (preuve ici :-)), avant de me plonger dans maven 2 depuis maintenant plusieurs années. Bon, ça c'est fait. J'espère que vous comprendrez que là, je veux pas me la péter hein. Je veux juste dire que nombre de concepts du livre m'étaient déjà connus. Et que, donc, mon analyse ne sera forcément pas celle d'un nouvel arrivant sur Maven.

Le style du livre

J'avoue que j'ai trouvé la lecture très agréable. C'est volontaire de la part des auteurs, et c'est réussi. Ils ont réussi à apporter beaucoup de concepts dans un style facile à lire. Ils ne sont pas tombés dans le piège de la documentation de référence, parfois un peu dure à lire, voire carrément chiante, qu'on n'ouvrirait que pour y faire un grep sur ce qu'on cherche (et ce n'est à mon sens pas le but pour un livre papier).

Le livre se lit un peu comme un roman : un petit projet débute, et rencontre les problèmes classiques du packaging qui devient une usine à gaz, et que seul celui qui l'a développé (et encore) peut lancer. Au fil de l'eau, on explique donc comment fonctionne maven (et pourquoi il a été créé), comment packager simplement, etc. Ensuite, on se rend compte que l'écriture et le lancement de tests est fastidieuse, alors on explique comment ajouter des tests, et ainsi de suite en décrivant la mise en œuvre de choses de plus en plus complexes.

La structure et le contenu du livre

"Premiers pas avec Maven"

La première partie introduit maven, d'où il arrive, qui l'a créé et pourquoi. Exemple : un projet, quel qu'il soit (et dans quelque langage que ce soit), rencontre presque toujours les trois besoins suivants lors de sa construction : préparer la construction (initialisation), compilation, puis assemblage.

Tout y est, "convention-over-configuration", la notion de dépendance, la transitivité, les scopes, les classifiers, etc... Et tout passe comme une lettre à la poste. Vraiment, je le redis : l'exploit de Nicolas et Arnaud réside dans la capacité à nous permettre de lire le livre sans avoir l'impression de lire une documentation technique.

Comme je le disais sur twitter, je pense que ce livre est un outil formidable sur lequel s'appuyer pour préparer des sensibilisations à Maven dans vos boîtes. Mais surtout, CITEZ VOS SOURCES !!!

Dans la première partie, on la jouait petit. En tant qu'utilisateur expérimenté de maven, ça m'a surtout donné envie de voir comment on pourrait déployer Selenium et FitNesse en IC chez nous.

"Maven en entreprise"

Là, on commence à ouvrir les vannes. Le projet est devenu complexe : comment gérer les dépendances proprement avec un repo manager, centraliser les informations dans un pom parent, utiliser Maven dans l'IDE.., et on arrive enfin à "mais diantre, comment on release un projet avec Maven ? On pourrait pas gérer automatiquement ces actions répétitives, rébarbatives qu'on se tape à chaque livraison, et sur lesquelles on se trompe une fois sur deux ?".

"Encore plus loin avec Maven"

On lâche les chevaux : écriture de plugin maison, comment le tester, intégrer de l'assurance qualité (analyse de code, couverture de code), la génération des rapports et enfin on parle de Sonar, la rolls de l'analyse qualité d'un projet.

Une fois la partie "technique" terminée, Arnaud et Nicolas se livrent même à l'exercice périlleux de prédiction : Maven 3 et consorts (Encore bon pour le moment : Maven 3 à attendre plutôt pour fin 2010, d'après le livre imprimé en novembre 2009. On en est à l'alpha-7 à ce jour.).

Les reproches

Il en faut, sinon, vous allez penser que je ne suis pas objectif :-).

Tests d'intégration : les mettre dans le projet, ou dans un projet externe ? Le livre dit que les deux approches sont valides, mais sans creuser. J'aurais aimé davantage de retours sur le sujet. Au moins essayer de donner des pistes ou des exemples sur quelle stratégie plutôt adopter qu'une autre dans une situation en particulier. Ou même simplement l'avis d'Arnaud et de Nicolas (je suis sûr que vous en avez un :)) si aucun consensus n'existe effectivement.
Problèmes d'impression en N&B : je suppose que quelques captures ou diagrammes (exemple : p.206, un des écrans de sonar) ont dû être envoyés à l'éditeur en couleur. Le passage au noir&blanc les rend peu lisibles (essayez de différencier du bleu et du vert une fois dans des nuances de gris...). Je pense qu'il aurait fallu soit vérifier la conversion au noir&blanc, soit voir avec l'éditeur pour imprimer en couleur au moins ceux-là (je suppose que ça permet de baisser le prix de revient du livre).
Évolution de Maven 3 : pouvoir référencer un pom parent sans version. Le problème de la poule et de l'œuf de Maven. Cette évolution me paraît à la fois intéressante, et en même temps pose question. En effet, l'une des forces de Maven est qu'il est actuellement possible de checkouter un seul module (et non tous) et de travailler dessus. Un peu comme SVN, on peut checkouter n'importe quel niveau, et Maven s'y retrouve très bien. Je suppose que si la version parent n'est plus spécifiée, il devient impossible de checkouter de cette façon. Je pense que ce sera comme ça, mais j'aurais aimé quelques détails sur le sujet.

Mon impression générale

Dans la description de ce petit projet devenu gros, j'ai retrouvé une très grande partie des choses que nous avons faites chez nous. Je pense que certains choix n'ont pas toujours été faits immédiatement, et la lecture d'un tel livre nous aurait économisé pas mal de temps et de recherches (le release-plugin marche très bien, une fois qu'il marche. Mais il peut être difficile d'initialiser les premières releases, où il y a toujours un truc qui plante au milieu).

Petit bonus en prime : le style adopté, et la partie à la fin du livre vous donnent l'impression de connaître tout le monde, de faire un peu partie de la famille :). Maintenant on connait l'âge de tous les développeurs francophones de Maven, même celui de Vincent qui a tenté un chiffrement en héxa :-).

Globalement, donc, je recommande chaudement ce livre à toute personne qui utilise maven et qui souhaite maîtriser l'outil. Le livre offre un accès facile à toutes les facettes du projet, des plus simples au plus avancées, sans omettre le côté humain qui est si important dans les projets opensource.

Comment connaître la provenance d'une classe programmatiquement en Java

batmat — Wed, 13 Jan 2010 18:07:00 +0100

Il est possible par programmation de savoir d'où vient une classe : un jar ? un répertoire ? autre ?

Use case classique : vous pensez (et devez) ne plus avoir les commons-logging nulle part dans votre classpath, parce que vous êtes (intelligemment :-)) passés à SLF4J. Malgré cela, il semble que cette fichue classe soit toujours trouvée, mais vous n'arrivez pas à savoir dans quel jar (ou quel répertoire si vous travaillez directement avec les .class). Résultat, ça vous fout un bazar monstre dans la configuration de vos logs. Certains continuent à apparaitre alors que vous avez demandé à ce qu'ils ne soient pas affichés...

Le code est un peu sioux, alors je le mets ici au cas où ça vous servirait :

System.out.println(MaClasse.class.getProtectionDomain().getCodeSource().getLocation());

MAJ du 15/03/2010

Suite à l'incompréhension ci-dessous, voici quelques exemples pour illustrer ce que fait ce code :

Le code :

System.out.println(org.springframework.mail.MailSender.class.getProtectionDomain().getCodeSource().getLocation());

System.out.println(MyJunitTest.class.getProtectionDomain().getCodeSource().getLocation());

Affiche sous Windows :

file:/C:/m2repository/org/springframework/spring-context-support/2.5.6/spring-context-support-2.5.6.jar
file:/C:/tests/myproject-core/target/test-classes/

J'espère que l'utilité est un peu plus claire à présent.

Bonne année 2010 à tous

batmat — Sat, 02 Jan 2010 11:48:00 +0100

Souhaitons que cette nouvelle année soit le début d'un retour aux manettes de ceux qui font à la place de ceux qui comptent. Mais j'avoue que j'y crois très peu :-).

Vu aucune différence de performances entre firefox 3.5 et les versions précédentes : vous utiliseriez pas Firebug ?

batmat — Wed, 23 Dec 2009 14:01:00 +0100

Par le plus grand hasard, pendant la lecture d'un billet de Pascal sur les performances de firefox au fil des âges, je viens de m'apercevoir que je ne profitais en fait pas de TraceMonkey, le compilateur JIT intégré à Firefox depuis la 3.5 !

C'est vrai que je n'avais pas fait très attention, mais que je n'avais pas non plus remarqué d'amélioration notable sur mon navigateur favori. En fait, c'était à cause du fait que j'avais, comme tout bon développeur qui se respecte :-), installé firebug depuis déjà un bon moment.

Sur le blog de Pascal, la phrase suivante m'a donc fait tilter :

Un petit rappel si vous utilisez Firebug, votre moteur de compilation JIT de javascript est désactivé et vous aurez donc des perfs équivalentes à celles de Firefox 3.0, même si vous êtes en 3.5. La version 1.5beta7 de Firebug sortie hier devrait résoudre ce bug.

Aussitôt dit, aussitôt fait. J'ai installé la version 1.5X.0b8 de firebug et j'ai tout de suite vu effectivement une différence. Gmail, Google Reader, Hudson, tout s'affiche plus vite.

Comme j'avais fait le test SunSpider avant la mise à jour, en gros, je peux vous dire que je suis passé de 3500 à 1500 !

Bref, installez-vite cette mise à jour !

Si vous maigrissez trop vite, prenez vos patch un jour sur deux

batmat — Mon, 21 Dec 2009 13:47:00 +0100

Je viens d'éclater de rire en voyant une publicité passer dans Gmail :

Le plus extraordinaire, c'est que le site en question semble pourtant se vouloir très sérieux :-).

Encoding par défaut avec XML : UTF-8

batmat — Thu, 19 Nov 2009 10:51:00 +0100

Nous gérons en ce moment un petit problème d'intégration avec des WebServices d'une entreprise qui ne s'attend qu'à du iso-8859-1. XML a pourtant été conçu pour gérer plus simplement les problèmes de jeux de caractères et d'encodage utilisé, mais ce qui a été fait ne respecte tout simplement pas la spécification.

En effet, notre code envoie une requête SOAP dans un tube HTTP annonçant de l'UTF-8. Comme ça ne marchait pas, nous avons carrément ajouté l'attribut encoding au prologue XML et retesté avec Soapui, mais ça n'a rien donné.

Alors, comme il faut que quelqu'un corrige son code, j'ai vérifié la spécification^[1], voici ce qui est indiqué :

Dans le cas où un encoding est précisé en externe, et que le prologue ne spécifie rien, c'est cet encoding qui est utilisé
Si rien n'est spécifié dans les premiers octets du XML, alors on parse de l'UTF-8 par défaut.
On trouve aussi cette phrase : All XML processors MUST accept the UTF-8 and UTF-16 encodings of Unicode.

Bref, attendre de l'iso-8859-1 lorsque rien n'est indiqué est au minimum une bizarrerie, et au pire une erreur par rapport à ce que dit la spécification.

Notes

[1] Non-Normative

Apache Subversion

batmat — Wed, 18 Nov 2009 15:58:00 +0100

Tiens, j'avais raté cette news (300 billets en attente dans mon google reader :-/, que je n'arrive à dépiler que 10 par 10. Ça ne suffit pas :-)) : Subversion a intégré l'incubateur d'Apache.

En français, ça veut dire que bientôt, Subversion sera un projet faisant partie entièrement de la fondation Apache. Subversion n'arrête pas son ascension, et c'est logique vu la qualité de l'outil.

[Hudson] How to set a private maven repository by job and easily be able to delete them

batmat — Fri, 09 Oct 2009 10:17:00 +0200

When building maven projects with hudson, there's some common best practices about maven repositories handling :

isolate maven repositories between jobs
regularly purge repositories

The problem

The basic way to do it is to activate the hudson per-job option : "Use private Maven repository". But the thing is you have to do it for EVERY new job you add. There is no way inside hudson to activate it globally.

Documented solution

If you look at hudson help for this option, you'll see a link to a simple solution that specify the repository directly in the maven settings.xml file. The tip is to redefine the localRepository tag inside settings with this special value :

<localRepository>${env.WORKSPACE}/m2_repo</localRepository>

This way, you're done with the first best practice : isolate maven repositories. But not yet with the regularly purge repositories one. Actually, using this option will put the m2_repo inside each hudson job workspace. So, finding and deleting them could become a bit cumbersome. You'd have to cron something like find . -name m2_repo -exec rm -rf "{}" \;.

Even better

As you might have understood, I was not thoroughly satisfied with this solution. I wanted to be able to really easily delete the repositories. So I just changed the option above to have them all inside the same root directory under ~/.m2/repositories, one per job.

Quite simple in fact, instead, just use :

<localRepository>/some/path/.m2/repositories/${env.JOB_NAME}/repository</localRepository>

This way, the only thing you have to put in the cron job is rm -rf /some/path/.m2/repositories/. A bit more straightforward, isn't it?

Hope this helps.

Encodages/jeux de caractères : Vincent et Hadrien, un grand merci !

batmat — Thu, 10 Sep 2009 16:07:00 +0200

Non, ce billet n'est pas une nouvelle tentative d'explication de ce que sont encodages et jeux de caractères. Je garde toujours dans un coin de ma tête de chercher un jour à écrire moi aussi un billet sur le sujet. Qu'est-ce j'aimerais pouvoir faire comprendre ce sujet à la fois simple et complexe à tous en quelques mots...

Non, ce billet est là pour remercier Vincent et Hadrien pour leurs pages récapitulant les jeux de caractères les plus courants en France. Je viens de m'en servir à l'instant pour expliquer une nouvelle fois le sujet.

Un autre site bien pratique, qui permet notamment d'avoir la valeur hexadécimale du stockage d'un point de code Unicode en UTF-8 : FileFormat.Info. Par exemple, le î (''LATIN SMALL LETTER I WITH CIRCUMFLEX'').

Et encore un rappel d'articles en français que je vous conseille sur le sujet :

JSR 330 : Dependency Injection for Java

batmat — Fri, 29 May 2009 09:57:00 +0200

Récemment, SpringSource (Rod Johnson, créateur de Spring) et Google (Bob Lee, coauteur de Guice) lançaient une proposition de JSR visant à standardiser un jeu d'annotations pour gérer l'injection de dépendances.

Cette proposition, « Dependency Injection for Java », est devenue une véritable JSR depuis 3 jours.

Personnellement, j'ai hâte de voir ce qui va ressortir de ce travail. Notamment, je regarderai attentivement en quoi cela complètera ou s'intégrera avec les annotations de common annotations (JSR 250, dont sont notamment issues @PostConstruct, @PreDestroy, @Resource) et éventuellement les annotations de la spécification des EJB3 (@TransactionAttribute, notamment).

Comme la spécification sera développée avec un scm et une liste de diffusion accessibles publiquement, j'essaierai de vous en dire plus à ce sujet dès que possible.

À suivre.

Citation du jour : Clémenceau

batmat — Thu, 28 May 2009 08:23:00 +0200

En lisant un bouquin, j'ai découvert l'histoire de la mort de Félix Faure, et le commentaire fait par Clémenceau après son décès. Félix Faure, président français de la fin du 19e siècle, est en effet mort en pleins ébats avec sa maîtresse.

Et Clémenceau, publiquement de dire :

Il a voulu vivre César et il est mort Pompée.

Superbe, Georges !

Java User Group Toulouse : première conférence

batmat — Mon, 11 May 2009 08:44:00 +0200

Pour ceux qui n'auraient pas encore vu passer l'information, demain soir a lieu la première session du JUG toulousain. Vous êtes évidemment les bienvenus !

Au programme, GWT et Java ME.

À demain !

L'église catholique à côté de la plaque

batmat — Fri, 27 Mar 2009 10:16:00 +0100

Après la récente intervention controversée du pape^[1], on a par contre maintenant affaire à un véritable débile en la personne d'André Fort.

Je viens en effet de l'entendre nous expliquer à la radio que (de mémoire) : les scientifiques savent très bien que le virus du SIDA est trop petit et traverse la paroi du préservatif (!).

Inutile de préciser que toute la communité scientifique est dite indignée par de tels propos... Et rappelons que si ! N'en déplaise à ce ramolli du bulbe d'André Fort, l'usage du préservatif est très sûr.

Il est inadmissible de chercher à appuyer ses propos de la sorte en se référant à des soi-disants "scientifiques". Ça me rappelle les créationnistes !

Cela risque d'avoir simplement un impact sur la frange peut-être la plus fragile de la population qui pourrait croire ce discours, et à exaspérer encore davantage les catholiques... Je suis personnellement d'éducation catholique et non pratiquant (je n'ose pas dire simplement "catholique non pratiquant") et les propos de ce genre de décérébré me rendent dingue.

Heureusement que je connais d'autres prêtres plus intelligents, plus pragmatiques, plus ancrés dans la vie de tous les jours, pour ne pas me mettre simplement à penser comme certains doivent certainement le faire (et on peut les comprendre...) : "décidément, ces catholiques, qu'est-ce qu'ils peuvent être cons !".

À bon entendeur.

Notes

[1] attention à bien toutefois se renseigner quant aux propos exacts du pape avant de critiquer, cf. la note de Maître Eolas par exemple. On a toujours l'air très con à critiquer des propos qui ne sont pas ceux que l'on pense précisément.

Abattre des cloisons non porteuses en briques

batmat — Sun, 15 Mar 2009 09:53:00 +0100

Dans les travaux de notre maison actuellement, je me suis enfin décidé à expliquer comment nous avons procédé pour l'abattage de cloisons. Plusieurs personnes ont semble-t-il été étonnées que je n'en parlasse point avant :-).

Abattre des cloisons en brique

Nous avions environ 30 à 40 mètres linéaires à abattre, sur des hauteurs de 2m50 ou 2m80. L'objectif était d'abattre absolument toutes les cloisons, parce que nous n'avions pas de mur porteur (seuls les murs extérieurs sont porteurs sur cette maison). Ces cloisons étaient en brique de 7cm d'épaisseur.

Première étape : se faire une idée de la difficulté des opérations

J'ai commencé par créer un passage entre les pièces pour faciliter la circulation. Ce premier perçage avait aussi pour objectif d'avoir une idée de la vitesse à laquelle nous pourrions abattre le reste.

J'y suis allé franco : à grands coups de masse. (J'avais acheté cette "masse trancheuse" chez Casto. Le côté "tranchant" est effectivement bien pratique.).

Note à ce propos : faites très attention à ce qu'il n'y ait rien qui craigne les projections de gravats de l'autre côté de la cloison sur laquelle vous vous acharnez. En effet, taper à coup de masses dedans a dans mon cas projeté des gravats largement jusqu'au mur suivant (situé à environ 4 mètres). Réfléchissez donc aux fenêtres qui peuvent se trouver derrière, ou simplement aux personnes qui travaillent avec vous. Dans ce dernier cas, hurlez simplement tiiimbeeeer avant de taper, ça fonctionne généralement plutôt bien :-).

Deuxième étape : industrialiser le processus

La technique du "c'est moi que vlà avec ma masse", c'est bien. Mais si vous cassez progressivement et simplement autour du point initial, ça va vous faire des tonnes de gravats à transporter par petits morceaux. Je vous la déconseille donc.

Je vous recommande en effet plutôt une technique que j'ai adoptée ensuite : casser le mur en faisant des grosses saignées pour réaliser des carrés de briques transportables. C'est plus simple à transporter dans la voiture que tout casser en petits bouts...

Pour vous, j'ai testé plusieurs techniques :

À la meuleuse d'angle et disque diamant (on l'appelle aussi souvent "disqueuse") : bof. Je vous la déconseille plutôt, sauf si vous avez besoin d'une découpe au millimètre. Mais ATTENTION : si vous partez sur cette technique, préparez vous à faire de la poussière. Mais quand je dis poussière, je ne plaisante pas. La pièce sera remplie de poussière après 5 minutes de meulage...
à la masse petit bout par petit bout : vous faites un trou, puis vous l'élargissez progressivement. Cette technique a le gros inconvénient de vous imposer un long et fastidieux ramassage de gravats après coup. Je vous la déconseille aussi. Vous devrez aussi investir à mon avis dans un nombre très important de "sacs de gravats" (j'y reviens plus bas) ;
à la masse, avec des saignées pour essayer d'obtenir des plaques de par exemple environ 1m² plus facilement transportables ;
à la masse et au marteau, par pan de cloison entier... On part toujours sur le principe des saignées, sauf qu'on part du sol, on va jusqu'au plafond. On fait la saignée au ras du plafond avec escabeau et marteau, puis on redescend jusqu'au sol au bout de quelques mètres. Vous l'aurez compris. Cette technique est de loin la plus rapide. Un conseil toutefois : soyez plusieurs et au moment où vous faites descendre la cloison, retenez la le plus longtemps possible. Par exemple, à trois, nous retenions sans aucun souci une cloison de 2m50 par environ 3m. Pensez aussi à mettre au sol des tapis ou toute chose de ce genre pour amortir le choc de la chute lorsque vous ne pouvez pas retenir jusqu'au bout. Nous avons utilisé cette technique pour les derniers 90% des cloisons sans soucis. Son gros avantage est qu'on peut ensuite simplement récupérer des morceaux de taille assez importante au sol sans trop de petits morceaux.

À propos des petits morceaux, les nombreux "bouts" de gravats que ce genre de travaux va vous produire, un conseil important : achetez des "sacs à gravats" (comme ceux-là). Ce sont des sacs en plastique extrêmement épais qui sont très utiles lorsqu'il faut balayer puis convoyer jusqu'à la déchetterie les bouts de briques cassées sur le sol. Attention, ne les jetez pas avec les gravats... Videz les simplement et réutilisez les jusqu'à ce qu'ils rendent l'âme (jusqu'ici, je dirais que nous avons utilisé chaque sac environ 5 à 10 fois, nous en avions acheté 24...)

Si vous avez des questions, n'hésitez pas.

Dans le prochain épisode, si vous êtes sage : abattre un plafond en plafonnette ou en lattis (oui, j'ai les deux).

Eclipse Killer Feature (un de plus) : formatage automatique du code modifié

batmat — Wed, 25 Feb 2009 17:28:00 +0100

Voilà pourquoi j'utilise Eclipse, pour ce genre d'apports qui peut paraître mineur au premier abord, mais qui en fait nous change la vie.

Lorsqu'on développe dans une équipe, on souhaite généralement appliquer entre autre des normes communes de formatage. Dans Eclipse, le Ctrl-Shift-F permet d'exécuter le formatage sur le fichier (ou sur toute une arborescence) selon le modèle qu'on aura défini et chargé au préalable.

Le Ctrl-Shift-F a cependant un défaut : sans sélection préalable, il va formater le fichier complet. La fois suivante que vous envoyez vos modifications aux gestionnaires de version (commit avec svn, par exemple), les développeurs qui récupèrent votre modification peuvent se demander pourquoi vous êtes allé modifier tout le fichier pour une simple faute de frappe...

Autre cas encore plus problématique : vous faites du développement MDA. Une partie plus ou moins importante de votre code est donc générée. Vous ne devez donc a priori surtout pas toucher au code en dehors de ce qu'on appelle généralement le code utilisateur (on retrouve ce principe avec acceleo il me semble). Du genre

// Ici, le code modifié manuellement sera écrasé par le générateur.

  // [DEBUT:METHODES]

// Là, le code ne sera pas écrasé à la régénération suivante.

  // [FIN:METHODES]

Depuis la 3.3 d'Eclipse, dans la partie Java/Editor/Save Actions de Window/Preferences, on peut demander à ce que le code qu'on vient de modifier soit automatiquement formaté... C'est pas formidable, ça ? À chaque Ctrl-S, le code modifié et uniquement celui-ci va subir le formatage adéquat... Via cette fonctionnalité, vous pouvez automatiser tout plein d'autres choses au moment de la sauvegarde, je vous laisse jouer avec :-).

Java User Group Toulouse

batmat — Fri, 30 Jan 2009 10:10:00 +0100

Via Sami, j'apprends ce matin que ça y est, le JUG Toulouse est né. Je me suis d'ores et déjà inscrit à liste de diffusion.

J'espère que je trouverai le temps de participer à ce groupe malgré les importants travaux à faire dans la maison que nous venons d'acheter.

PS : Sami, merci encore pour la bétonnière :-).

Drop sequences for Oracle

batmat — Mon, 22 Dec 2008 09:41:00 +0100

Adam already showed how to generate all the drop table statements (impossible to trackback):

SELECT 'drop table '||table_name||' CASCADE CONSTRAINTS;' FROM USER_TABLES

As I just needed to drop sequences, based on Adam's query, here's the necessary:

SELECT 'drop sequence '||sequence_name||';' FROM USER_SEQUENCES;

Quite straightforward indeed.

Hope this helps.

À quelle vitesse vous tapez ?

batmat — Fri, 28 Nov 2008 20:22:00 +0100

41 mots

Speed test

L'image du jour

batmat — Fri, 17 Oct 2008 21:14:00 +0200

Reçu ça il y a quelques jours, ça m'a beaucoup fait rire :

Leçon de politique politicienne à l'américaine

batmat — Tue, 30 Sep 2008 13:51:00 +0200

Je viens de lire cet article du monde à propos du rejet du plan Paulson. Très fort, ce Douglas Holtz-Eakin...

Si M. McCain a évité de s'en prendre trop frontalement à Obama, son conseiller économique, Douglas Holtz-Eakin, n'a pas pris de pincettes.

Si l'adoption du plan de relance a échoué, explique-t-il, c'est "à cause de Barack Obama et des démocrates, qui mettent la politique avant le pays". [...] Sur les 433 élus de la Chambre basse, 228 ont voté contre, dont 133 républicains et 95 démocrates.

Refaisons le compte, d'après wikipedia, la chambre des représentants des États-Unis, aussi appelée chambre basse, est composée de 435 membres, répartis comme suit :

Républicains : 202 sièges
Démocrates : 233 sièges

Et on nous dit donc qu'ont voté contre le plan Paulson :

133 républicains
92 démocrates

Comptons les votes pour :

Républicains : 69 votes, soit 34% des républicains
Démocrates : 141 votes, soit 60% des démocrates

En résumé, Douglas Holtz-Eakin, républicain, accuse les démocrates qui ont voté massivement pour (autant en nombre qu'en pourcentage) d'avoir fait échouer le plan Paulson... C'est pas un rien malhonnête, ça, mon petit monsieur ?