Big Code ?

Je crois que j’en ai eu assez d’entendre des politiques et autres commentateurs dire que le code du travail trop gros et que sa modification est urgente. Au delà des arguments politiques, j’aimerais mettre quelques chiffres ici, suite à mon expérience sur ces données (http://codes.droit.org) et bientôt une application iOS et des web-services.

Si je regarde le poids des PDFs que je génère pour chaque codes (droit positif + articles liés), je constate que les plus lourds sont :

  • sante_publique.pdf (35412646)
  • rural_peche_maritime.pdf (30630860)
  • securite_sociale.pdf (30238979)
  • travail.pdf (28924689)
  • impots.pdf (23586049)

En nombre d’articles, c’est différent:

  • sante_publique (11845)
  • travail (1123)
  • rural_peche_maritime (9413)
  • securite_sociale (7538)
  • commerce (6679)

Enfin, si on se contente d’observer le nombre de liens, on obtient:

  • sante_publique 19001
  • securite_sociale 17364
  • rural_peche_maritime 14501
  • travail 13442
  • monetaire_financier 11899

Bref, le code du travail n’est ni le plus lourd, ni le plus long.

Je vous épargne mes commentaires politiques.

Waveform

Il n’échappera à personne que je fais par ailleurs de la musique et que je la publie sur un de mes sites (http://habett.net). Pour avoir par ailleurs mis de la musique sur soundcloud j’observe que les formes d’ondes sont bien utiles pour comprendre et apprécier la structure du morceau. Reste que les waveforms de soundcloud sont extrêmement peu parlantes. J’ignore leur algorithme mais il est vraiment lénifiant et donne un résultat tellement peu expressif que je me suis très rapidement dit que je pouvais faire beaucoup mieux.

L’outil pour y procédé vas être un script bash avec quelques dépendances : sox, gnuplot et imagemagick. Le paramètre est le nom du fichier .wav à traiter sans son extension. Vous pouvez observer que je fais en fait deux waveforms que je combine à la fin dans  un composite, pour obtenir un représentation différentielles des fréquences utilisées par la musique en question, waveform plus sombre pour les basses et claire pour les aigus dominants.

#!/bin/sh

WAV=${1%.wav}
sox "$WAV" /tmp/test.wav lowpass 500

sox /tmp/test.wav --rate 1k /tmp/test.dat

rm /tmp/test.wav

grep -v '^;' /tmp/test.dat >/tmp/test.clean

perl -pe 's/.*/0 1 1\n0.0001 -1 -1/ if $. == 1' /tmp/test.clean > /tmp/test.norm

rm /tmp/test.dat

rm /tmp/test.clean

CMD="set terminal png transparent size 6400,1600; set noxtics;set tmarg 0;set bmarg 0;set lmarg 0;set rmarg 0;set noytics; set noborder;set nogrid;set nokey;set output '/tmp/test.png';plot '/tmp/test.norm' with impulses notitle lt -1"

 echo $CMD | gnuplot

rm /tmp/test.norm

convert /tmp/test.png -scale 1600x400 "$1.low.png"

rm /tmp/test.png

sox "$WAV" /tmp/test.wav highpass 300

sox /tmp/test.wav --rate 1k /tmp/test.dat

rm /tmp/test.wav

grep -v '^;' /tmp/test.dat >/tmp/test.clean

perl -pe 's/.*/0 1 1\n0.0001 -1 -1/ if $. == 1' /tmp/test.clean > /tmp/test.norm

rm /tmp/test.dat

rm /tmp/test.clean

echo $CMD | gnuplot

rm /tmp/test.norm

convert /tmp/test.png -negate -scale 1600x400 "$1.high.png"

rm /tmp/test.png

composite -compose difference "$1.low.png" "$1.high.png" "$1.png"

rm "$1.low.png"

rm "$1.high.png"

 

Open Game

J’étais à une conférence où il était question entre autre d’Open Access et Démocratie.

J’ai été marqué par plusieurs choses. Par exemple dans l’opposition vis à vis des éditeurs privés (concentrations, prix abusif, opacité, …) plusieurs personnes semblaient rêver d’interventions de l’Etat afin de garantir un accès démocratique. Plusieurs fois l’intervention du secteur public semble vécue comme la panacée. Sur le fond je trouve aussi que sur de telles questions l’intervention de l’Etat est plus que légitime et pourrait aller encore plus loin de par ses prérogatives. Reste que vu l’évolution du paysage politique, je ne pense malheureusement pas que l’intervention de l’Etat soit l’ultime remède car certains prétendants au pouvoir (et pas les plus mal placés (( entretiennent apparemment de gros fantasmes de privatisations.

Le rempart cela semble être la publication de code open source permettant de traiter les données. Si tel service est privatisé ou absorbé par un méchant éditeur du secteur privé, au moins on sauve l’infrastructure logicielle de traitement. Ce raisonnement doit être modéré par les interrogations sur l’Open Source au sens logiciel. Pour ma part je relis très très rarement le code d’autres personnes. Peut-être suis-je une loup des steppes/circuits mais je vois rarement mes confrères proches évoquer ce  type d’activité non productrice à court terme.

Vu de l’extérieur code is code, il sera relu et tout ira bien.

Mon point principal, en tant que programmeur en perl, javascript, xml et/ou swift, c’est que le langage dans lequel sont développés ces projets est un enjeu majeur. Il suffit de peu d’observations pour se rendre compte que le public qui s’exprime en assembleur, C++, python ou dotnet sont très différents. Il y a une part d’idéologie sous-jacent, un constat générationnel et sociologique. C’est pourtant bien occulté au grand public. Pour un certain nombre de personnes plus proches du milieu vas vous tenir le raisonnement que pour tel type de job il n’y a pas à tergiverser quand au choix de l’outil qui doit s’imposer par lui même. Je n’y crois pas. Comme on dit souvent entre perlistes, « there’s more than one way to do it ».

J’y crois d’autant moins que j’ai connu professionnellement des cas où la décision du choix du langage incombe à la hiérarchie non technique. Je suis pour le pluralisme, je pratique certains langages mais j’en ignore bien d’autres. Je n’ai pas envie d’imposer mes choix, au mieux convaincre, et encore. J’aurai pu apprendre php il y a quelques années mais cela me révulse, j’aurai pu me mettre au python mais je trouve le code inélégant, et je suis trop jeune pour avoir un background en assembleur. Paysage d’autant plus compliqué avec l’explosion du nombre de librairies et fameworks, il y en a pour tous les goûts.

Code is not code. Ce n’est pas un tour de babel mais une ville avec ses quartiers et ses ghettos, sa politique et sa sociologie.

Google: license to forget ?

Je publie de la musique sous licence creative commons sur un de mes sites (http://habett.net). L’ayant refait il y a quelques mois, je me suis posé des questions quant à l’exposition et la cohérence du balisage des mes métadonnées et j’ai fini par m’orienter essentiellement vers la technologie json-ld.

Je mets en place mes données et métas et après quelques tâtonnements je finis par obtenir la validation par l’outil google de test des données structurées (https://search.google.com/structured-data/testing-tool/u/0/). Je suis content. Je retourne il y a quelques jours pour vérifier un truc et je constate que mon json-ld est maintenant marqué comme contenant des erreurs. Je ne suis plus content. Je vérifie avec schema.org que j’utilise pour mes définitions et je constate que mes structures semblent encore correctes. Voici un exemple minimal:

{
 "@context" : "http://schema.org",
 "@type" : "CreativeWork",
 "name" : "DJ Habett",
 "alternateName" : "Free music for unfree people",
 "url" : "http://habett.net",
 "license": "http://creativecommons.org/licenses/by-sa/3.0/fr/"
 }

C’est très simple à priori, un travail créatif auquel on rattache une licence désignée par son URL. (https://schema.org/CreativeWork) et (https://schema.org/license). L’outil google répond (alors qu’il n’y trouvait rien à redire il y a quelques semaines):

« Nous ne reconnaissons pas la propriété http://www.w3.org/1999/xhtml/vocab#license pour un objet de type CreativeWork. »

Selon moi la propriété « license » est connue (cf schema.org) mais par google « plus reconnue » et non pas « pas reconnue » car cela fonctionnait encore récemment.

Que dire ? Je ne vais pas être le seul (http://stackoverflow.com/questions/35844485/mixing-json-ld-and-microdata-schema-org) (impact entre 1000 et 10000 domaines selon schema.org).

Nihilisme ou révisionnisme ?

(https://productforums.google.com/forum/?utm_medium=email&utm_source=footer#!msg/webmasters/yPcF6rteIqo/ZlhapEEVBQAJ)

PS: J’ai signalé l’erreur en utilisant l’outil google dédié mais pas de réponse pour le moment.

PS: Réparé par google début juillet.

Assembly types

Je crois qu’une dans grandes erreurs de la programmation moderne est que beaucoup pensent coder dans un langage proche de l’assembleur où il existe une forme de compréhension du poids de chaque instruction. Les langages modernes sont de si haut niveau que l’on peut avoir l’impression qu’un code compact est plus efficient.
Récemment je code un peu en Swift pour divers projets, mon casual load restant perl. C’est le grand écart. Le typage dans perl est tellement faible et la syntaxe libérée que swift semble bien coercitif. Je comprends que cette modernité est liée à des considérations d’optimisations qui sont réelles. J’avais fait des essais en objective-c et j’avais détesté car je trouvais la syntaxe vraiment trop inélégante.
Swift donc, les fonctions. Par convention le premier paramètre n’est pas nommé mais les paramètres suivants sont déclarés avec des préfixes nommés qui permettent, en plus du type qui est très fort, de savoir que passer. Reste que contrairement au premier, les suivants doivent être préfixés et en plus l’ordre est important: Que faire de la police ? La discipline m’est ici presque insupportable.

Reste qu’il y a des aspects plaisants, le code est propre et élégant selon mes standards, les curlies sont scopants, les ; optionnels, la surchage est classes est très bien faite, les parenthèses optionnelles sur les conditions. Par contre les strings qui nécessitent toujours des doubles quotes sont un grand malheur pour moi.

Comme le dit Larry Wall, programmer c’est trop compliqué, let’s go scripting !

Solar 5, premières notes

Je note ici mes premières impressions et difficultés avec le nouveau SolR 5. J’aime beaucoup l’idée principale qui est de se passer d’un container, rien contre. standalone me vas bien.

Auto-discovery des cores, je ne comprend toujours pas pourquoi il faut créer un core.properties dans le répertoire de chaque core, quitte à ce qu’il soit vide, ou alors un collection.properties.

Quelques types de données ont disparu, pint, sint, etc… pas bien grave, c’est même mieux.

Comme souvent le clustering est un peu chiant à mettre en place car il n’est pas dans la config par défaut donc il faut ajouter à son solr start -a ‘-Dsolr.clustering.enabled=true’ copier les jar du contrib/clustering vers $solrhome/lib/clustering avec le <lib> qui vas bien dans le solrconfig.xml

Quelques handlers devenus incompatible à enlever de la configuration.

J’ai supprimé les sections <indexDefaults> et <mainIndex> de mon solrconfig.xml.

Dans mon schema j’ai eu des problèmes avec enablePositionIncrements= »true » dans les stopFilterFactory.

J’ai eu un coup de flip car il ne retrouvait plus mes datas car le dataDir est relatif au solrhome et non au home du core comme je le croyais.

Enfin certain de mes vieux scripts avaient des curl que j’ai du adapter:

curl $sol5url/update?commit=true
curl -H ‘Content-type: text/xml’ -X POST -d ‘<optimize />’ $sol5url/update

MTWrong

j’ai donc quitté MT pour WP. pas grand chose à en dire si ce n’est que c’est un peu le même type d’intérêt pour les technos qui gèrent leurs propres migrations qui m’avait poussé à revenir sous Ubuntu après un passage sous Mint, ce type de confort et le fait que MT a fini par me planter sec avec aucune possibilité autre que de déplacer mes datas de l’un à l’autre à la main.

Time will tell.

A l’occasion ce blog Resistance is Futile devient Bug or Feature ?

Adobe 0 – ExifTool 1 – Habett II

Pas mal de prises de tête au final pour injecter des méta-données dans des PDFs.

Surtout sur le champ du milieu.

Sujet.

Après avoir hésité sur la méthodologie je me suis rendu à l’évidence que le meilleur outil pour faire cela programmatiquement (par script) est bel et bien ExifTool. Le grand ExifTool, ce puissant et capricieux outil multi-platteforme. Mais à vrai dire, est-ce son caprice ou bien celui qui s’introduit malignement dans mon esprit à trop me demander pourquoi les turpides d’affichage de ces même méta-données dans Adobe Reader et Acrobat sont si perturbantes. Ou bien les méandres de l’histoire sont liées à l’age de cette technologie et à l’évolution des techniques disponibles.
Reste qu’Adobe nous fout un bon gros bordel en place. Je pourrais cracher mon venin sur ces bureaucrates et l’informatique et les maudire longtemps encore, et parfois même aller jusqu’à douter de la qualité du travail d’ExifTool mais non, voici donc ma solution en ligne de commande.

Je commence par faire le vide dans les métadonnées car l’empilement des différentes couches devient vite problématique. Je fais donc simplement:
exiftool -overwrite_original -all= monfichier.pdf

Ensuite j’injecte un fichier XMP que j’aurai rempli avec mes métadonnées selon la distribution suivante (je remplis le XML en DOM Javascript ou un LibXML Perl).

<?xpacket begin=’?’ id=’W5M0MpCehiHzreSzNTczkc9d’?>
<x:xmpmeta xmlns:x= »adobe:ns:meta/ »>
<rdf:RDF xmlns:rdf= »http://www.w3.org/1999/02/22-rdf-syntax-ns# »>
<rdf:Description rdf:about= » » xmlns:dc= »http://purl.org/dc/elements/1.1/ »>
<dc:creator>
<rdf:Seq>
<rdf:li>None</rdf:li>
</rdf:Seq>
</dc:creator>
<dc:description>
<rdf:Alt>
<rdf:li xml:lang= »x-default »>références</rdf:li>
</rdf:Alt>
</dc:description>
<dc:format>application/pdf</dc:format>
<dc:subject>
<rdf:Bag><rdf:li>baratin</rdf:li></rdf:Bag>
</dc:subject>
<dc:title>
<rdf:Alt>
<rdf:li xml:lang= »x-default »>circonscription électorale des Etats-Unis d’Amérique</rdf:li>
</rdf:Alt>
</dc:title>
</rdf:Description>
<rdf:Description rdf:about= » » xmlns:pdf= »http://ns.adobe.com/pdf/1.3/ »>
<pdf:Author>None</pdf:Author>
<pdf:Keywords>baratin</pdf:Keywords>
<pdf:PDFVersion>1.4</pdf:PDFVersion>
</rdf:Description>
<rdf:Description rdf:about= » » xmlns:xmp= »http://ns.adobe.com/xap/1.0/ »>
<xmp:CreateDate>Wed Jan 21 2015 16:43:41 GMT+0100</xmp:CreateDate>
<xmp:MetadataDate>Wed Jan 21 2015 16:43:41 GMT+0100</xmp:MetadataDate>
<xmp:ModifyDate>Wed Jan 21 2015 16:43:41 GMT+0100</xmp:ModifyDate>
</rdf:Description>
<rdf:Description rdf:about= » » xmlns:xmpRights= »http://ns.adobe.com/xap/1.0/rights/ »>
<xmpRights:WebStatement>http://www.legicrack.org</xmpRights:WebStatement>
</rdf:Description>
</rdf:RDF>
</x:xmpmeta>
<?xpacket end=’w’?>

Plusieurs notes à ce propos. Bien respecter les format de date et UUID, bien diviser la valeur du champ Mots-Clés selon les virgules et les points-vigules afin d’en répéter le contenu depuis <pdf:Keywords> pour sa totalité littérale vers <dc:subject>/<rdf:Bag> et autant de <rdf:li> que la division vous donnera. Cela semble nécessaire même si le paradoxe viendra plus loin.

Pour injecter cela, on utilisera la commande suivante:

exiftool -overwrite_orginal -tags_from_file monxmp.xmp monpdf.pdf

Reste le champ Subject ou Description ou Sujet, comme vous voulez, à force je l’appelle le champ du milieu. Comme vous le voyez dans le XML précédent il y a différents namespace dans les métadonnées donc il faut pas se rater.

Ma solution est la suivante, avec l’option -L en plus si vous êtes sous Windows et que vous voulez mettre une valeur avec accents:

exiftool -overwrite_orginal -pdf:subject= »Mon champ du milieu » -xmp:subject= » » monpdf.pdf

Ils ont le même nodename mais dans des espaces de noms différents et pourtant il faut les injecter avec des valeurs radicalement différentes.

Après ces trois étapes, j’arrive à mes fins, et mon résultat dans les produits Adobe est conforme, avec juste le petit itch qui est que la valeur des mots-clés est encadrée de quotes, ce qui peut arriver même quand on saisit à la main, à moins qu’un lecteur ou moi ne finisse par trouver une solution programmatique.