Bonjour journal !
je t'écris cette (première) missive afin de te montrer mon premier script à moi que j'ai fait pour télécharger mes opérations de compte LCL au format CSV sans
1) devoir cliquer ou taper mon mdp car je suis fainéant,
2) devoir payer pour l'option téléchargement car je suis radin.
Ce script est donc mon premier script Perl à moi que j'ai fait, il est très crade car :
1) je ne comprends pas tout à Perl mais ça m'a l'air affreusement crade à la base comme langage (des liens vers de la bonne doc avec de beaux exemples ?),
2) je parse du HTML d'une façon dégueulasse mais c'est parce que ça marche
J'avais fait ce mm script en PHP avant car je maîtrise un peu plus et ça marche aussi bien mais je me suis dit que tout le monde a pas PHP installé et que Perl doit être plus courant. si ça intéresse du monde, j'ai un script PHP qui récupère la synthèse des comptes de la Caisse d'épargne (et même un qui télécharge le csv d'un compte mais alors celui-là j'ose à peine en parler tellement il est sale, j'en ai encore mal aux yeux).
Journal Script LCL
2
août
2006
# putin le lien !!
Posté par teddyber . Évalué à 7.
désolé. moinssez moi, faites vous plaisir...
[^] # Re: putin le lien !!
Posté par Mouns (site web personnel) . Évalué à 2.
il y a deja , La Poste, Societe Generale , BNP , credit mutuel
[^] # Re: putin le lien !!
Posté par teddyber . Évalué à 3.
par exemple, comment trouver ces scripts pour la poste, la sogé, etc. ?
ça m'aurait bien aidé...
[^] # Re: putin le lien !!
Posté par teddyber . Évalué à 2.
bon ben je vais adapter le script pour avoir de belles fonctions comme eux...
[^] # Re: putin le lien !!
Posté par moramarth . Évalué à 5.
Je t'ai trouvé pertinent, donc je t'ai moinssé…
…Euh, attends…
# salut
Posté par plagiats . Évalué à 5.
1) tu as oublié de poster le lien
2) ca peut être sympa à lire
# Konqueror
Posté par plic . Évalué à 2.
Or dans le module sécurité je vois bien la case SSL 128 cochée. Est-ce dû à un mauvais réglage serveur ou à ma config ?
KDE 3.5
La faculté de citer est un substitut commode à l'intelligence -- Somerset Maugham
[^] # Re: Konqueror
Posté par med . Évalué à 1.
[^] # Re: Konqueror
Posté par Sufflope (site web personnel) . Évalué à 2.
[^] # Re: Konqueror
Posté par jijin . Évalué à 2.
[^] # Re: Konqueror
Posté par Frédéric COIFFIER . Évalué à 1.
[^] # Re: Konqueror
Posté par Frédéric COIFFIER . Évalué à 1.
DHE-RSA-AES256-SHA
[^] # Re: Konqueror
Posté par thom_ra . Évalué à 1.
Bon, sinon, moi je m'étais fait descendre dans un cours de sécurité logique, parce que le chiffrage, c'est quand tu fais un devis par exemple... ;-)
Enfin, pour moi ce qui compte, c'est de ne pas dire cryptage ! ;-)
Bon, si personne répond, dès que j'ai un moment, je vais intérroger mon moteur de recherche favori pour voir ça de plus près...
[^] # Re: Konqueror
Posté par Frédéric COIFFIER . Évalué à 1.
# 1er conseil
Posté par Fabien Engels . Évalué à 4.
use strict;
Perl t'obligerat à etre plus rigoureux sur les declarations de variables et compagnie.
[^] # 2ème conseil
Posté par Fnor . Évalué à 5.
http://articles.mongueurs.net/magazines/
L'article "Introduction à la programmation en Perl" de Sylvain Lhullier te donnera de bonne bases. Ensuite, les articles "Construire des robots pour le web" de Philippe Bruhat sont incontournables. C'est ce qui m'a décidé à me mettre au Perl. J'en profite pour remercier Philippe pour ses articles.
# LCL et linux...
Posté par mouskouyouss . Évalué à 2.
Mais récemment, ils semblent avoir modifier leur site pour intégrer entre autre un activeX anti keylogger (qui est optionnel, c'est bien).
Mais le résultat semble être que je n'arrive plus à me connecter directement...
Faisant partie de l'agence en ligne e.LCL je me connecte via l'adresse http://e.lcl.fr et si je veux consulter mes compte je suis rediriger vers https://e.secure.lcl.fr
Et c'est cette page que ne se charge plus correctement (le navigateur n'affiche rien est charge la page indéfiniment)
Le truc étrange c'est que si je regarde le source, j'ai tout le code présent, et si je l'enregistre en local et le réouvre, j'obtiens le formulaire de connection (sans les images et feuille de style).
le truc bizarre, c'est qu'en validant le formulaire, j'arrive à me connecter !!
Sauf qu'au lieu d'avoir l'interface complète (virement externe, historique, téléchargement), j'ai l'interface sans abonnement (enfin je crois)
Encore plus intéressant, c'est qu'en trafiquant le referer pour simuler une connection provenant de e.lcl.fr, je me connecte cette fois ci sur l'interface complète !
Pour ceux qui n'ont pas d'abonnement, cela vaut le coup d'essayer !
Par contre, je ne comprend pas pourquoi le formulaire de connection ne s'affiche pas sous Linux/Firefox alors que cela fonctionne sous Windows/Firefox.
J'ai essayé les autres navigateurs que j'avais sous la main, mais sans succès.
Si quelqu'un à une explication je suis preneur...
[^] # Re: LCL et linux...
Posté par Yusei (Mastodon) . Évalué à 3.
[^] # Re: LCL et linux...
Posté par Sufflope (site web personnel) . Évalué à 6.
[^] # Re: LCL et linux...
Posté par Nicolas Bernard (site web personnel) . Évalué à 2.
[^] # Re: LCL et linux...
Posté par mouskouyouss . Évalué à 1.
Ok, je vais chercher un peu plus alors...
Je suis sous FC 5.
# Alternative au perl
Posté par Tristram . Évalué à 2.
Pour ce genre de taches, la mode serait vers Python ou Ruby. C'est toujours un troll infernal.
Ce sont tous les deux des langages modernes, répandus, avec des bibliothèques conséquentes etc. et permettent un codage assez propre.
Bon, très personnellement j'ai un très fort faible pour Ruby qui s'inspire vaguement de Perl (pour les regexp dans le langage par exemple), mais aussi du Smalltalk (tout objet).
Bref, je pense que globalement, se plonger dans le perl de nos jours n'est pas le pertinent/interessant. Evidemment on peut toujours suivre les trace de ses ainés du temps où il n'y avait pas mieux ;)
[^] # Re: Alternative au perl
Posté par Fabien Engels . Évalué à 3.
Que ça plaises ou pas, ça reste le langage script le plus utilisé dans l'administraton système, donc si ce monsieur veut devenir admin, Perl est pertinent et interressant ...
Ruby ne brilles pas par sa documentation (du à la barrière du japonais ...) donc je pense pas que ça soit le plus simple à prendre en main. Python me semblerait plus pertinent.
[^] # Re: Alternative au perl
Posté par Yusei (Mastodon) . Évalué à 5.
Il y a la première version du rubybook, qui est libre et intégrée dans debian, qui est très bien pour apprendre. Pour le reste, il y a la deuxième version du rubybook en livre (traduit en français il me semble), des API sur le net, des tutoriaux un peu partout...
La barrière du japonais, c'était vrai il y a 4-5 ans, plus maintenant.
[^] # Re: Alternative au perl
Posté par Fabien Engels . Évalué à 1.
[^] # Re: Alternative au perl
Posté par Gniarf . Évalué à 1.
merci du cadeau.
[^] # Re: Alternative au perl
Posté par Yusei (Mastodon) . Évalué à 2.
Une comparaison injuste: je suis en train de "jouer" avec les modules Perl pour manipuler Cyrus, et c'est extrêmement peu documenté. Ok, c'est pas la faute de Perl, c'est la faute de Cyrus, mais bon... :) Après, je ne sais pas si c'est parce que j'ai perdu l'habitude de Perl, mais je trouve beaucoup plus difficile de "trouver comment ça marche" en Perl qu'en Ruby, où tu peux faire un obj.methods pour avoir la liste des méthodes de obj (par exemple).
[^] # Re: Alternative au perl
Posté par Sylvain Sauvage . Évalué à 2.
[^] # Re: Alternative au perl
Posté par Pierrick Le Gall (site web personnel) . Évalué à 3.
Un autre avantage de Perl est sa communauté. On y trouve de nombreux experts d'une grande qualité technique. Cela est certainement dû à l'ancienneté du langage et à l'attrait de ce langage qui se veut facile à prendre en main, et capable de faire des choses complexes.
L'argument de la propreté du langage est tout relatif à la personne derrière le clavier. Perl n'empêche pas de code proprement, il permet juste de code vite et jetable et pas propre, mais ce n'est pas obligé.
[^] # Re: Alternative au perl
Posté par teddyber . Évalué à 3.
Dans d'autres langages (je pense particulièrement à ADA), coder vite = coder propre et il faut vraiment le vouloir pour coder salement.
[^] # Re: Alternative au perl
Posté par sobek . Évalué à 4.
Je corrigerais bien par coder vite sans un minimum de méthode = coder sale
Par avec un peu d'expérience, on peut programmer vite tout en restant propre...
Maintenant c'est sûr que sans les "use strict" et "use warning", on peut faire des choses très sales mais qui tombent en marche...
[^] # Re: Alternative au perl
Posté par sobek . Évalué à 3.
Python est à la mode en effet. Maintenant, faut-il suivre la mode ou rester sur des langages qui répondent aux besoins et ont fait leurs preuves ?
Quand à Ruby... J'ai beau fouiller sur nos serveurs, la seule chose qui en dépend ici c'est portupgrade, ce qui est très peu comparer à tous els outils dépendant de Perl. De là à parler de langage à la mode... Et c'est pénible de devoir maintenir un langage en plus pour un seul outil.
Autant je comprends l'intérêt du tout objet dans certains cas particulier, autant je ne comprends pas la volonté de certains d'en mettre partout.
C'est ton avis, permet moi de ne pas le partager.
Je n'en ferais clairement pas un premier langage pour de l'initiation à la programmation, mais c'est un langage qui merite qu'on s'y intéresse.
Ben j'avoue que je cherche encore un langage qui fasse mieux que Perl en terme de souplesse, sans rendre la programmation plus pénible.
J'avoue que l'indentation obligatoire de python me sort par les trous de nez : si cela éclairci le code, l'impossibilité de définir un code autrement rend la réutilisation de code pénible. Et vu comment mon voisin de bureau s'est arraché les cheveux à cause de la façon dont python gère certains signaux...
Quand à Ruby, à part le tout objet (qui a aussi ses inconvénients amha), je ne vois pas trop l'intéret par rapport à perl pour l'utilisation que j'en ai...
[^] # Re: Alternative au perl
Posté par Dring . Évalué à 2.
Peux-tu préciser ta pensée ?
[^] # Re: Alternative au perl
Posté par JoeBar . Évalué à 2.
Ca empêche aussi un formatage automatique avec réindentation, comme j'utilise de façon extensive avec Java et Eclispe. J'aime avoir du code lisible, mais j'aime quand c'est la machine qui se charge de gérer les espaces et l'indentation. Pourtant j'aime python... mais je ne comprends guère ce choix de l'indentation signifiante.
[^] # Re: Alternative au perl
Posté par Jean-Philippe (site web personnel) . Évalué à 0.
Pour le coup de l'indentation je trouve dommage que l'on rale sur un langage juste parce qu'on ne peut pas faire un copier/coller directement...
[^] # Re: Alternative au perl
Posté par sobek . Évalué à 0.
Sauf que justement, je préfère les {,} à une indentation signifiante, c'est plus rapidement lisible et en toutes circonstances, je trouve (sans même parler des problèmes de réindentation sur un copier-coller).
C'est loin d'être la seule chose que je reproche à Python, mais c'est la plus peinible au jour le jour...
[^] # Re: Alternative au perl
Posté par iznogoud . Évalué à 1.
[^] # Re: Alternative au perl
Posté par Yusei (Mastodon) . Évalué à 5.
Avantages:
- c'est un langage fonctionnel, en plus d'être objet, et ça permet certaines constructions élégantes, par exemple récupérer la valeur de retour d'un "case" (équivalent du switch de C, en mieux).
- les itérateurs, c'est vachement mieux que toutes les variantes de foreach. Je suppose qu'on doit pouvoir en ajouter à Perl, mais c'est bien quand tous les objets énumérables les ont d'office.
- tu peux rajouter ou redéfinir des méthodes d'objets existants quand tu veux, là où en Perl tu devrais définir une fonction d'enrobage. Je prend un exemple à la con: si tu décides que tu veux logger toutes les connexions effectuées via http, il te suffit de redéfinir la méthode de connexion de la classe Net::HTTP (ou quelque chose du style) au début de ton script, et tu n'as rien à faire d'autre.
- tu n'as pas besoin de mémoriser si ta variable est un array, un hash, un ensemble, un graphe, un arbre... pour savoir comment prendre un élément dedans, tu fais juste variable[identifiant].
- tu peux redéfinir les opérateurs, c'est pratique, surtout pour l'opérateur de comparaison qui sert à faire des tris.
- le controle d'accès des méthodes, ça a du bon pour les gros projets. (La philosophie de perl c'est: on n'exécute pas une fonction privée, pas parce que c'est impossible mais parce que ce n'est pas poli. En ruby c'est pas possible.)
Inconvénients.
- Ruby on Rails, ça déchire des ours, et ça aurait été vraiment difficile à coder en Perl.
Inconvénients:
- C'est plus lent que perl, donc si ton usage principal est d'analyser des logs, par exemple, ça risque de ne pas être rentable.
- Il y a un peu moins de libs, même si j'ai presque toujours trouvé ce dont j'avais besoin tout prêt dans debian. Par contre, c'est vraiment simple de faire des extensions Ruby à partir d'une lib en C.
- Pas de "use strict" pour t'obliger à être rigoureux, même si on doit pouvoir bidouiller un truc similaire.
[^] # Re: Alternative au perl
Posté par Yusei (Mastodon) . Évalué à 2.
J'ajouterais, quand même, que j'ai fait pas mal de Perl avant de faire du Ruby, et que Ruby en est fortement inspiré, ce qui est agréable. Ruby rend simple tout ce que Perl rendait simple, et ne rend rien plus difficile. Généralement, les modes de pensée perliens se traduisent assez bien en Ruby. Boucler sur un fichier, appliquer des regexps sur chaque ligne, utiliser des backticks pour exécuter une commande, balancer le résultat dans un hash et sortir des statistiques à la fin, bref l'utilisation standard de Perl, se traduit presque directement.
[^] # Re: Alternative au perl
Posté par iznogoud . Évalué à 1.
C'est vrai, le switch case en perl n'existe pas en tant que tel. On peut aussi dire qu'on se debrouille tres bien sans :D
- les itérateurs, c'est vachement mieux que toutes les variantes de foreach. Je suppose qu'on doit pouvoir en ajouter à Perl, mais c'est bien quand tous les objets énumérables les ont d'office.
Moi, j'ai jamais aime les iterateurs, ca m'embrouille l'esprit, je n'arrive pas a "visualiser" ce qui se passe derriere. J'ai l'impression qu'on veut me masquer l'aspect "boucle" de la chose. Alors qu'un bon vieux foreach, ca te prend 2 lignes de plus que ton iterateur, je ne vois pas le probleme. Mais bon, ca c'est purement subjectif
- tu peux rajouter ou redéfinir des méthodes d'objets existants quand tu veux, là où en Perl tu devrais définir une fonction d'enrobage. Je prend un exemple à la con: si tu décides que tu veux logger toutes les connexions effectuées via http, il te suffit de redéfinir la méthode de connexion de la classe Net::HTTP (ou quelque chose du style) au début de ton script, et tu n'as rien à faire d'autre.
Inconvenient : ton Net::HTTP peut se retrouver dissemine dans tout ton code, apres, vazyleon pour retrouver la methode que tu veux. J'ai bon ? :D
- tu n'as pas besoin de mémoriser si ta variable est un array, un hash, un ensemble, un graphe, un arbre... pour savoir comment prendre un élément dedans, tu fais juste variable[identifiant].
Chacun son truc, moi j'aime les langages qui sont un minimum typés, ca m'interdit de faire des conneries genre vouloir acceder a la valeur d'un element d'une hash table alors que je suis dans un contexte de string. Ca me parait une contrainte importante. Encore une fois, c'est subjectif.
- tu peux redéfinir les opérateurs, c'est pratique, surtout pour l'opérateur de comparaison qui sert à faire des tris.
Je crois que perl6 devrait ajouter ce genre de fonctionnalites.
Pour ton exemple cela dit :
- le controle d'accès des méthodes, ça a du bon pour les gros projets. (La philosophie de perl c'est: on n'exécute pas une fonction privée, pas parce que c'est impossible mais parce que ce n'est pas poli. En ruby c'est pas possible.)
Vrai. Y'a des moyens d'interdire reellement l'execution d'une fonction donnee, mais ca reste plus ou moins de la bidouille. C'est bien un element dommageable pour perl :)
- Ruby on Rails, ça déchire des ours, et ça aurait été vraiment difficile à coder en Perl.
C'est pas dit hein :D
Cela dit, justifier de la pertinence d'un langage par une application en particulier, je trouve ca mediocre comme argument :) Si je veux developper un module qui fait, disons, des acces a un annuaire LDAP, je m'en fiche royalement que RoR dechire des ours. Je veux que le langage que je vais utiliser me permette de faire mon script de maniere efficace, rapide, et qui reponde a mes attentes. RoR a beau etre un framework de dev web vachement classe, hype, a la mode et tout, il n'empeche que c'est pas ca qui va me faire developper un truc en Ruby. A la rigueur un truc pour le web, si je veux utiliser un framework et que le langage me plait. Mais c'est tout :)
[^] # Re: Alternative au perl
Posté par Yusei (Mastodon) . Évalué à 2.
"use Switch", non ? :)
Je faisais plutot référence à la possibilité de récupérer la valeur de n'importe quelle expression, par exemple (salement):
toto = if (a == 2) then 3
elsif (a== 5) then 6
else 42
end
Sauf qu'un itérateur peut faire autre chose qu'itérer sur les éléments d'une collection dans l'ordre. Tu as each, bien sûr, mais tu peux avoir reverse_each qui itère à l'envers. Pour faire ça avec un foreach, tu dois d'abord inverser ta collection. Tu as aussi str.each(délimiteurs) qui fait quelque chose comme foreach my $s (split(délimiteurs, $str)).
Et si tu fais une matrice, tu peux faire des itérateurs each_row, each_cell, etc.
Oui, mais on peut coder salement dans n'importe quel langage :) Ceci dit, il suffit de faire un grep pour retrouver toutes les définitions d'une classe.
Et en ruby, articles = files.sort { |a,b| b <=> a }, comme quoi ça se ressemble. Mais la magie de la redéfinition des opérateurs, c'est que tu peux définir une bonne fois pour toutes comment "<=>" compare tes objets. C'est pratique quand tu as des données structurées, et une fois que tu as redéfini <=>, tu peux faire if a < b ... et ça marche.
Je ne sais pas si tu as essayé Rails, mais justement, ça roxor des ours grace à Ruby. C'est une bonne démonstration de la flexibilité que permet Ruby, et certaines choses seraient vraiment très difficiles à faire avec un langage plus "rigide". Rails n'est pas vraiment "une application", c'est plutôt un ensemble de code Ruby qui t'aide à construire une application Ruby.
Pour prendre un exemple qui parlera peut-être aux sysadmins habitués aux scripts d'analyse de logs, il ne doit pas être très difficile en Perl d'obtenir la date de dans dix jours, mais j'ai cherché deux minutes sans trouver de méthode standard qui gère les mois de 28, 29, 30 et 31 jours. En Ruby, on fait Date.today+10, et en Rails on peut aussi écrire 10.days_from_now (je pense). Ce sont des détails, mais des détails qui rendent le développement rapide et agréable.
[^] # Re: Alternative au perl
Posté par iznogoud . Évalué à 1.
toto = if (a == 2) then 3
elsif (a== 5) then 6
else 42
end
equivalent perl :
$toto = ($i == 2) ? 3 : ($i == 5) ? 6 : 42
Comme quoi, on peut faire ca aussi.
Pour le use switch, j'ai tendance a dire : j'aime pas devoir faire appel a un module pour quelque chose qui pour moi releve plus du langage. Or le switch manque effectivement.
Et si tu fais une matrice, tu peux faire des itérateurs each_row, each_cell, etc.
La, ca devient interessant (non parce que les reverse et tout, ma foi, un foreach regle le probleme, alors qu'une manipulation de matrice oblige a faire deux foreach, c'est pas toujours top top)
Oui, mais on peut coder salement dans n'importe quel langage :) Ceci dit, il suffit de faire un grep pour retrouver toutes les définitions d'une classe.
Je disais plus ca en argument au fait qu'on critique toujours perl parce que c'est un langage qui permet de coder salement. On *peut* le faire. Dans tous les langages. Mais y'a aucun interet a le faire, quelque soit le langage.
Mais la magie de la redéfinition des opérateurs, c'est que tu peux définir une bonne fois pour toutes comment "<=>" compare tes objets.
C'est ce que je pensais, en disant : normalement, perl6 devrait corriger ce manque :
http://dev.perl.org/perl6/doc/design/apo/A03.html
Je ne sais pas si tu as essayé Rails, mais justement, ça roxor des ours grace à Ruby.
j'ai testouille, oui. Convaincu, non.
(pour le probleme de dates, la solution est dans perldoc.perl.org, une petite recherche te dit de faire un :
use DateTime;
(on en apprend tous les jours))
J'ai le meme avis que beaucoup d'autres ici. Perl a de la bouteille, est moins hype que python ou ruby. Mais il reste un excellent langage, il me permet d'etre efficace. ruby, j'ai teste avec RoR, j'ai patauge. Je ne suis pas fait pour, apparemment. Et python, j'aime pas ses regexp, NA ! :D
[^] # Re: Alternative au perl
Posté par Yusei (Mastodon) . Évalué à 2.
Oui, bien sûr, en Ruby aussi l'opérateur "?" existe, mais ce n'était qu'un exemple du fait que chaque expression a une valeur de retour, puisque c'est fonctionnel. Faut bien avouer que l'opérateur ternaire, c'est sale :)
Note que je n'ai rien contre Perl, à part certains détails de syntaxe qui m'énervent, j'aime beaucoup. Personnellement, je n'ai jamais rien compris aux objets en Perl, alors je me suis d'abord servi de Ruby comme d'un Perl avec un modèle objet bien fait.
[^] # Re: Alternative au perl
Posté par lolop (site web personnel) . Évalué à 2.
Heu, Python a fait ses preuves depuis déjà quelques années.
Après, le choix d'un langage, c'est quand même très personnel et une question... d'habitudes et de goûts (bon, pour un soft dans une boite c'est généralement imposé, et de temps en temps on tombe sur des problèmatique pour lesquelles il y a des langages dédiés).
M'enfin, troller sur Truc c'est mieux que Machin... l'important c'est que ce script LCL soit disponible, et mieux en libre pour pouvoir le corriger, l'améliorer et le rediffuser.
Si certains préfèreraient avoir le script dans un autre langage, "y'a qu'a" regarder comment il marche et l'adapter.
Sinon (continuation de troll):
Et moi c'est un des critères qui me fait apprécier Python (c'est donc bien en partie une question de goûts), à l'utilisation je ne trouve pas ça du tout pénible (comme tu dis, ça éclairci le code, ça le rend lisible... et ça c'est très très appréciable).
Ca, pour moi c'est pas un critère. Dans tous les développements tu trouveras un moment où tu galèreras sur un point, à cause du langage ou à cause d'une librairie. Vaut mieux regarder les possibilités d'expression du langage, de structuration, de ré-utilisation du code, les librairies disponibles pour ne pas avoir à tout recoder, etc...
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.