Catégorie : Non classé

curl cert apache2 2.2

Grand fan de l’initiative letsencrypt (https://letsencrypt.org/) dont parle souvent l’EFF (https://www.eff.org/) (je suis membre), j’ai eu des problèmes avec la vérification des certificats générés par ce service sur un serveur avec une installation un peu ancienne. curl et LWP me refusaient en raison de problèmes de certificats.
https://community.letsencrypt.org/t/certificate-verification-errors-when-using-curl/105335 a attiré mon attention sur le fait qu’il me manquait la ligne, à priori propre à apache 2,2 suivante, à adapter au bon domaine, dans ma config apache:
SSLCertificateChainFile /etc/letsencrypt/live/privatestash.org/chain.pem


Une fois en place, plus besoin de bypass de la vérification des certificats dans LWP (use IO::Socket::SSL; $ua->ssl_opts( SSL_verify_mode => IO::Socket::SSL::SSL_VERIFY_NONE, verify_hostname =>0);) et plus besoin des mêmes options dans curl (-k), ce qui est bien plus satisfaisant.

Le truc bizarre est que les browsers ne pâtissaient pas de ce point.


curl cert apache2 2.2

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.

Big Code ?

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.

Google: license to forget ?

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 !

Assembly types

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

Solar 5, premières notes

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 ?

MTWrong