Affichage des articles dont le libellé est liens. Afficher tous les articles
Affichage des articles dont le libellé est liens. Afficher tous les articles

samedi 7 novembre 2009

Octobre 2009

Retour sur le mois passé...

Rett.iuwt

Asmanur a eu la formidable idée de créer une plateforme Status.net en parallèle du chan #sdz (et #zds - sur epic.net) et de Buzzerl : ça s'appelle "Rett.iuwt" ou "Twuitter", et c'est ici.
Etant maintenant bien habitué à Twitter, j'avoue que j'apprécie bien ce mode de communication, en particulier comparé à IRC (où, il faut bien le dire, je ne fous jamais les pieds), aux forum et aux réseaux sociaux plus "riches" :

  • Par rapport aux messageries instantanées donc, c'est beaucoup moins invasif, on gère plus facilement le bruit, et ça a également l'énorme avantage de la persistance (les logs IRC, c'est pénible à lire).
  • Je trouve les forum souvent trop "statiques". De plus, ils sont généralement axés vers un "thème" en particulier, et se prêtent mal au partage d'items (liens, news, photos, etc...) : ils ne sont pas vraiment faits pour ça.
  • Les "gros" réseaux sociaux, au sens "grosse appli", sont... lourds. Facebook par exemple, même s'il reste un outil très utile pour garder le contact avec ses potes, n'est pas du tout adapté pour une utilisation en mode "communauté" : trop d'applications (plus useless et mal codées les unes que les autres), trop de bruit et des outils (et interface) trop lourds. Sans parler des problèmes d'accès aux informations privées...
Peut-être Google Wave (NON, je n'ai pas d'invitation, je n'y suis pas !) proposera-t-il quelque chose de nouveau dans ce domaine...

Dans la foulée, je cherchais un client multi-plateforme pour Twitter et Status.net, et je suis tombé sur qTwitter, qui est tout à fait sympathique. Certes, ce n'est pas le plus joli esthétiquement, mais il fait bien le job et a pas mal de fonctionnalités utiles (réglage mises-à-jour, support de Twitter, Identi.ca et autres Status.net, options d'auto-#tag et de raccourcissement d'URL...).

Il reste plus qu'à trouver un moyen propre de faire le pont entre deux comptes/API Twitter et Status.net, et ce sera  nickel...


SupInfo

On a beaucoup entendu parler de SupInfo ce mois-ci, dans des termes peu avantageux (euphémisme).
D'abord la sombre histoire d'un étudiant à qui SupInfo refusait de remettre son diplôme qui a fait un peu de buzz. Ensuite, un article assassin d'un enseignant chercheur sur la formation prodiguée par cette école... qui a déclenché pas mal de réactions, notamment celle d'un compte Twitter (@olivier_comes) supposé appartenir à un responsable de cette école (je vous laisse juger au vu des tweets, mais je ne peux que penser qu'il s'agit d'une usurpation d'identité...).
Je ne commente pas l'affaire de l'étudiant, elle me parait louche. Pour ce qui est de l'article, s'il avait été écrit par un membre de la CTI, j'y porterais plus de crédit, même si je pense que l'auteur est de bonne foi.

Je ne connais personnellement aucune personne étudiant ou ayant étudié dans cet (ces) établissement(s). Je ne connais pas non plus particulièrement bien la formation prodiguée.
Pour autant, les problèmes mentionnés (même s'ils sont exagérés, là n'est pas la question) sont pour moi "logiques" pour une formation privée, d'une part, et non sanctionnée par la CTI d'autre part.
J'ai toujours été favorable à l'enseignement (supérieur) public, qu'il se fasse en classes préparatoires, universités, écoles d'ingénieurs ou autre. Ce n'est pas tant une question de gratuité (les écoles de commerce publiques sont payantes par exemple), mais une certaine garantie (imparfaite bien sûr) du mérite de l'intégration : concours après les CPGE, intégration sur titre depuis la fac, etc... L'argent n'est pas supposé intervenir dans cette phase là.
Ensuite, qu'on le veuille ou non, la commission des titres d'ingénieur impose des conditions parfois très strictes aux établissements pour que ceux-ci délivrent le diplôme d'ingénieur. Ce n'est pas pour rien : d'une part, cela assure un semblant de standardisation entre les formations sur les sujets transverses (gestion de projet, management, communication, langues, formation théorique, etc...) quelque soit le niveau supposé de la dite formation. D'autre part, c'est une sorte de "label qualité" applicable à tous ses diplômés. Bien sûr, ensuite, certains étudiants seront plus compétents que d'autres dans un contexte professionnel : c'est pourquoi il est évident qu'avoir un diplôme SupInfo n'est pas un point négatif en soi. Cependant, je comprendrais un recruteur (surprenant, non ?) qui à profil équivalent préfèrerais un candidat avec un diplôme d'ingénieur.

Jeux

Deux très bons jeux ce mois-ci :

  • Plants VS Zombies : un excellent jeu de stratégie sur PC (Windows, Mac et Web) dans le genre "tower-defense en lignes". Design marrant, bonne durée de vie, musiques géniales... vraiment très sympa.
  • Professeur Layton et la boîte de Pandore : sur Nintendo DS, dans la lignée du premier épisode. Je craignais un peu que le principe de jeu s'essouffle à cause d'une répétition des énigmes, mais je me trompais : on se régale tout pareil.


Musique et BD

D'abord, l'annonce du nouvel album des Puppetmastaz pour le 9 Novembre (déjà) : "The Breakup". Si vous aimez le Hip Hop un peu décalé, technique et à tendance électro, foncez. Un minimix de preview, absolument génial, est disponible gratuitement ici.

Dans le style vieux Blues et Boogie, je vous conseille Sonny Boy Williamson I, un grand harmoniciste ayant enregistré dans les années 30 et 40. Beaucoup de perles dans sa discographie.

J'ai enfin récupéré la bande originale du film Conan le Barbare, par Basil Poledouris. Hormis le fait que c'est excellent (surtout pour un geek comme moi, ou pour un fan de Naheulbeuk), je pense que c'est à conseiller à toute personne souhaitant découvrir doucement la musique classique : les morceaux sont plutôt courts, les mélodies assez simples et redondantes, mais la composition générale et l'interprétation en font quelque chose de très intéressant.

En BD, le dernier Jiro Taniguchi, "Un zoo en hiver", est très bon : dans la lignée de ses titres "Un ciel radieux", "Quartier lointain" ou "Le journal de mon père", celui-ci apporte une touche auto-biographique supplémentaire (jeunesse dans l'industrie du dessin et du manga dans les années 60), et une ambiance vraiment particulière. Très touchant.

samedi 17 octobre 2009

Io Language Libraries and Tools

Because of its too short name, it's quite hard to find resources for Io language. Besides, I never found some kind of "libraries central" for it (as it exists in other languages like Perl or Ruby for example). Io official website also lacks of links, or some are obsolete...

So, this post is an attempt to simply list existing libs and tools for Io language and provide links to them, with minimalist descriptions.

You are really encouraged to notify me (via the comments for example) missing libs or tools, or to use  this raw list for a possible centralization of Io resources (This is what CC licences are for).


  • IoFE - An alternative command line interface to the IoVM interpreter [old ?]
  • IoWiki - A simple wiki written in Io (sources)
  • Backpacking - An Io web framework [old ?]
  • Ike - Rake (Make in Ruby) in Io [several repos]
  • Jim - An IRC bot in Io
  • Muun - A multi-user unified network
  • Iota - A tiny web app framework in Io [old ?]
  • Yown - A little web framework for Io (initially developed by _why) [several repos/forks]
  • Io-snippets - Snippets for Io
  • Icis - An Io continuous integration server
  • couchDB-io-viewserver - A couchDB viewserver in Io [old ? - Ok ?]
  • Io-SCGI - An SCGI implementation for Io
  • Chordal - An Io library to generate chords [???]
  • Io-Pack - A pack/unpack implementation for Io
  • Iospec2 - An RSpec-like tool (behavior driven development) for Io [several repos]
  • Io-Stuff - Little utilities for Io [Ok ?]
  • Io-JSON - A simple json pack/unpack for Io
  • Beanstalk-client-io - A beanstalk client library
  • IoSVN - Subversion Io language add-on
  • iorm - A minimalistic ORM [Ok ?]
  • IoPackage - Io code package manager based on Git repositories
  • Generys - Web framework in Io [Ok ?]
  • Netz - A simple webserver abstraction layer for Io [Ok ? New]
  • couchDB-Io - Io library for CouchDB [New]
  • IoGraphViz - Binding for GraphViz [New]


Not found:

  • IoGTK
  • ModIo
  • IoL4
  • It (by Pixar studios)


Last update: 17th October 2009

dimanche 8 février 2009

Atlas du monde réel

Il y a de nombreuses façons de représenter le monde qui nous entoure. Traditionnellement, un carte représente le monde en tant qu'espace "physique" (ou plus exactement, une de ses projections) le plus fidèlement possible en termes de surfaces et distances.
Un cartogramme tente lui de représenter le monde en fonction d'une variable donnée : PIB d'un pays, densité de la population, taux d'accès à une ressource, etc. Pour ce faire, il déforme les surfaces et les distances réelles proportionnellement à la variable qu'il exprime. Cette technique est relativement récente : inventée durant le XIXème siècle, elle n'est fréquemment utilisée que depuis la seconde moitié du XXème. Par exemple, ci-dessous, la répartition des destinations touristiques dans le monde (où l'on peut voir que la France, l'Espagne et l'Italie apparaissent bien plus volumineuses que sur une carte classique de par leur forte attraction touristique). De nombreux cartogrammes sont consultables en ligne sur le site WorldMapper.



L'Atlas du monde réel (chez l'éditeur) propose avec 366 cartogrammes une représentation originale et souvent très efficace du monde, sur des problématiques très diverses (économiques, politiques, ressources, sociologiques, médicales, culturelles, etc...).

L'une des très grandes qualités de cet ouvrage (hormis sa présentation très claire et agréable) se cache derrière la méthode employée pour la génération de ses cartes. En effet, il s'agit d'une méthode numérique récente (2004) développée par Michael Gastner et Mark Newman (coauteur de l'ouvrage et chercheur numéricien à l'université du Michigan).
Cette méthode se base sur le phénomène physique de la diffusion (mécanique des fluides/thermique) : les territoires représentés se déforment comme s'il s'agissait de ballons contenant du gaz (la variable étudiée) avec des zones de pression (les zones de fortes densités de population, le plus souvent). Article de référence : Diffusion-based method for producing density equalizing maps, Michael T. Gastner and M. E. J. Newman (PDF).
D'un point de vue purement numérique, l'équation de la diffusion est résolue par une transformée de Fourrier rapide (FFT) et intégrée par une méthode de Runge-Kutta d'ordre 4. Selon les auteurs, une précision à 1.0E-4 (cela peut paraître décevant, mais une précision plus grande n'est quasiment pas observable humainement) est obtenue en peu d'itérations (ordre de temps de calcul : quelques minutes sur un ordinateur de bureau).

Ce qui m'a paru intéressant dans cette méthode, c'est l'application d'un problème de physique (la diffusion/mécanique des fluides) à un contexte tout à fait décalé (cartographie/représentation des données). Dans l'article cité plus haut, sont listées les précédentes méthodes de génération de cartogrammes, dont une autre consiste en une analogie physique avec l'élasticité des matériaux (mécanique solide déformable).
Dans d'autres domaines, pour ce type d'analogie, on peut citer l'utilisation de méthodes de CFD (calcul en mécanique des fluides) dans des calculs de trafic (routier ou autre) ou en finance ("flux" monétaires...).


Références :



Autres liens en vrac à propos des cartes :



Note : le cartogramme présenté ci-dessus est tiré de l'"Atlas du monde réel" et appartient à ses auteurs.

dimanche 14 décembre 2008

3 petits Reddits

Petit post publicitaire pour présenter à ceux qui ne connaissent pas Reddit, et 3 petits sub-reddits sympathiques.



Reddit est un site de "social news" ou de "social bookmarking", assez proche de Digg (l'aspect réseau social en moins), ou Scoopeo en Français (moins orienté "news" cependant) : son contenu consiste en une liste de liens proposés par la communauté des internautes, mise à jour en permanence. Afin de trier les liens par sujet, il existe de nombreux "sub-reddits", spécialisé dans un genre ou un thème donné. Parmi les plus connus de ces sub-reddits, on retrouve Pics, Politics, Technology, Science, Programming, Ruby, WTF (What The Fuck ? : C'est quoi ce bordel ?) ou encore NSFW (Not Safe For Work : pour du pOr|\|0 et autre...). Depuis plusieurs mois, il est possible de créer gratuitement ses propres sub-reddits, publics ou privés, sur des sujets de son choix, et ce, assez facilement.

Au niveau de l'utilisation, le principe est très simple. Vous pouvez proposer un lien qui vous a plu (ou pas d'ailleurs...) à l'un des sub-reddits. Ensuite, ce lien apparaitra dans la liste des nouveaux liens soumis. A partir de ce moment, les autres redditeurs pourront voter pour ou contre ce lien, le commenter et éventuellement le reporter en cas d'abus (par exemple si vous postez un lien prOn dans le reddit des trucs mimi). Si votre lien obtient un accueil favorable, il pourra éventuellement passer en première page.
Pour encourager les redditeurs, il existe un système de points appelés "points de karma". Ils sont supposés représenter le respect que vous doit la communauté en fonction de votre attitude : liens soumis appréciés, bons commentaires, etc... Sans être un but en soi, ils donnent un aperçu de l'activité de chacun sur le site.

Parenthèse pour les hackeurs, le code de Reddit est libre et donc disponible pour chacun. Au départ codé en LISP, il est désormais principalement implémenté en Python (sources).

Cependant, comme beaucoup de sites "web 2.0" reposant majoritairement sur l'activité de sa communauté, il est soumis à divers problèmes. Notamment, il est très difficile pour un sub-reddit de survivre si sa communauté n'est suffisament active, ou, tout simplement, nombreuse (ce qui est souvent le cas pour des sujets très spécifiques). De même, étant un site international, c'est l'Anglais qui domine très largement les autres langues (même s'il existe quelques reddits spécifiquement dans d'autres langues...). Il est d'ailleurs amusant de constater une certaine "animosité" à l'égard de liens dans certaines langues (dont le Français) ou l'absence totale dans certaines autres (dont l'Arabe)...

Je me permets donc de vous proposer ici 3 "petits" reddits qui me paraissent intéressants :

Pixel Art :

Ce très modeste sub-reddit se focalise sur le pixel art, bien sûr, mais également sur toute autre tentaive artistique liée à 'lunivers informatique.

Blues Music :

Autre sub-reddit sympathique, mais malheureusement très peu actif, Blues Music parle bien évidemment... de Blues. N'hésitez pas à proposer vos liens !


XFCE :

Enfin, l'un des plus "spé", le reddit de l'environnement graphique XFCE. Pour info, j'ai découvert cet environnement récemment via les nouveaux netbooks sous Linux, et je dois doit dire que dans ce type de matériel, il est particulièrement efficace et agréable.

vendredi 31 octobre 2008

Pourquoi utiliser Ruby ?

Note préliminaire :

Il y a quelques temps, j'avais rédigé cette présentation à la demande de gars du Site du Zéro, dans le but de faire un topic de comparaison objective (Mama mia !) du Ruby et du Python. Ne connaissant que très peu le Python, je me suis chargé de la partie Ruby. Initialement rédigée en zCode, la première version de celle-ci est disponible à l'adresse suivante (à toute fin utile) : version zCode. (Merci par avance de me prévenir si vous détectez un problème dans cet article : lien mort, texte "bizarre" ou autre).

-~=.=~-

Pourquoi Ruby ?

Ruby

Ruby est un langage de programmation libre, interprété, à typage dynamique fort et orienté objet. L'écriture de ce langage d'origine japonaise a débuté en 1993 et est dirigée par différents principes :
En Ruby, toute donnée est un objet, et toute fonction est une méthode (une méthode étant elle même un objet...) : il n'existe pas de type primitif comme dans certains autres langages.

irb(main):001:0> 1.class
=> Fixnum
irb(main):002:0> Fixnum.class
=> Class
irb(main):003:0> Class.class
=> Class


Ruby est dynamique et flexible : possibilité de modifier le code à l'exécution, et/ou de redéfinir son implémentation de base.

# Exemple de modification du code natif # en cours d'execution

a = 1

puts a.class
#=>Fixnum

# to_s : methode native de conversion en String
puts a.to_s
#=>"1"

# Modification de to_s
class Fixnum
def to_s
"Huhuhu !"
end
end

puts a.to_s
#=>"Huhuhu !"


Le principe de moindre surprise veut que le développeur (expérimenté, ou venant d'un autre langage) soit le moins surpris/dépaysé/perturbé possible par la syntaxe ou les mots clés de Ruby.

"Convention plutôt que configuration." Ruby favorise ce concept, très repris dans certaines applications du langage, dont Rails.

Ruby est à comparer à d'autres langages dynamiques interprétés, dont : Python, Groovy, PHP, Io, Perl et Scheme, entre autres.

Pourquoi Ruby ?

Quelques avantages :



  • Entièrement objet, mais autorise le procédural, et dans une certaine mesure inspiré du fonctionnel. Le développeur est donc libre. De même il y a "Plusieurs façons de faire la même chose". Cela ne veut pas dire pour autant que toutes se vaillent.

  • Le core et l'API standard fournissent tout le nécessaire pour débuter (et continuer !) : threads, benchmark, gestion d'exceptions, parseurs...

  • Grandes possibilités de métaprogrammation.

  • Différentes implémentations du langage sont disponibles : MRI pour la principale en C, mais aussi JRuby (en Java, pour la JVM), IronRuby (pour la plate-forme .Net), Rubinius (en Ruby) et dernièrement MagLev, et quelques autres.

  • La prise en main est généralement rapide pour quelqu'un ayant déjà de premières bases en programmation et en POO.

  • Contrairement à ce qu'on peut souvent entendre, la documentation du coeur et des librairies standards est bonne et claire. Les ouvrages traitant du langage sont également assez nombreux, et parfois de très bonne qualité. Notamment : Why's (Poignant) Guide to Ruby, le Pickaxe, Ruby par l'Exemple, Design Patterns in Ruby...

  • Outils associés : TextMate (pour MacOS), Aptana RadRails (pour Eclipse ?), RDoc (génération automatique de documentation), RubyGems (gestionnaire de packages, appelés "gem" en Ruby), etc...

  • Communauté importante et active : RubyForge.

  • De nombreuses gems, portages et librairies de qualité pour le web (Rails, Merb, Ramaze, Camping...), pour la GUI (GTK, WxWidgets, FOX, Shoes, tk...), pour les sciences (BioRuby, LaPack...)...




  • Et quelques (malheureux) défauts :



    • D'abord, les performances en terme de vitesse d'exécution sont assez mauvaises pour un langage de ce type. A relativiser cependant : les performances sont rarement critiques pour un langage de ce type d'une part, et d'autre part, les améliorations sont régulières sur chacune des implémentations du langage (avec une certaine compétition qui favorise les progrès).

    • Manque de sécurité sur certains points : peu de warnings, constantes pas constantes... Ceci est principalement dû à la grande liberté du codeur.

    • Métaprogrammation riche, mais incomplète (à comparer à Io pour l'introspection/réflexion notamment).
    • Communauté très (trop ?) orientée Rails et web. Très anglophone également.

    • Gestion perfectible des blocks.

    • Certaines parties des librairies standards contestables (Math et Matrix entre autres).

    • Langage "non-pur" : à comparer à Io, Smalltalk ou Scheme (encore que le Scheme ne soit peut-être pas "purement" fonctionnel...). Ici encore, c'est surtout une conséquence de la liberté du programmeur. Et en conséquence, la relative facilité pour commencer à coder en Ruby peut donner de mauvaises habitudes aux débutants (ou l'impression d'avoir rapidement fait le tour...) ; on le constate régulièrement dans des codes pour Rails ou RPG Maker XP.



    • Ah ! Et dernier avantage du langage : son créateur est aussi un grand comique ^^




mardi 23 septembre 2008

Une tortue avec Processing

J'ai découvert récemment Processing (parfois écrit Proce55ing), un langage de programmation/environnement pensé pour des réalisations "artistiques" : images, animations, sons et 'interactions'.

Basé sur le Java, la syntaxe semble assez proche du Javascript, assez concise et simple. Le typage est statique en revanche. Dans l'ensemble, c'est plutôt bien fait : la prise en main se fait en quelques petits essais... Par exemple :

Exemple (Le code)

Pour information, cet environnement est disponible sous toute plateforme, et en diverses implémentation (Javascript, Ruby...). Pour avoir un peu joué avec Shoes, je retrouve là une bonne partie de ce qui a inspiré _Why pour sa conception... L'un des côtés intéressant, outre l'environnement vraiment simplissime, c'est l'assez grand nombre de bibliothèques (3D, traitement du son et du signal, XML, Vidéo, PDF...) même si elles sont parfois un peu "orientée Mac" (QuickTime entre autre...). Notamment, Arduino et Wiring dans l'interfaçage physique, me paraissent particulièrement intéressants : avec un matos de base relativement abordable (à partir de 20€ pour les cartes), les possibilités sont très grandes... (Je vous laisse chercher.)

Allez, un petit code rigolo pour illustrer :

Turtle :

J'ai essayé de faire une petite version, assez simplifiée, du langage Logo (langage de programmation où l'on dessine avec une tortue).

Le "coeur" est implémenté dans un premier fichier "turtle_lib.pde".
La méthode setup(), comme son nom l'indique, est une méthode d'initialisation qui est systématiquement appelée (si existante) par Processing avant la méthode principale. Elle ne peut être rappelée par la suite. La fonction noLoop() indique à l'interpréteur que les instructions qui seront données par la suite n'auront pas à être répétées (par défaut, le contenu de la méthode draw() est exécuté de manière cyclique, notamment pour les animations et les captions diverses : souris, clic, etc... Ici, ceci est inutile et gênant).
Les méthodes suivantes sont les méthodes de base du Logo : move pour avancer le crayon d'un nombre donné de pixels, turn pour changer sa direction, changeColor pour changer sa couleur et son opacité, raisePen et putPen pour le lever le crayon (celui-ci n'écrit donc plus lorsqu'on le déplace) et le (re)poser, respectivement.

Voici un petit exemple d'utilisation : les instructions se trouvent dans la méthode draw() qui constitue la méthode "principale" de tout programme Processing.


Exemple de la tortue (turtle_ex.pde)

Non, ce n'est pas très joli... mais c'est de la faute à la tortue !

Références :

Dans le même genre...

Amusez-vous bien !

mercredi 13 août 2008

Tumblelog

En général, j'essaie d'éviter de "metablogger" (blogger au sujet de mon blog, ou du fait même de blogger). Mais une fois n'est pas coutume...

Les quelques courageux qui suivent ce blog régulièrement auront sans doute constaté que malgré mes efforts, ma fréquence de publication a pour le moins "baissé" depuis quelques mois. Plus de travail, moins de temps libre, etc... Donc, moins de temps pour écrire des articles "corrects".
Cependant, il y a une solution pour partager rapidement des liens, articles et infos intéressantes : un tumblelog.

Sur le principe, un tumblelog est comparable à un blog, mais avec des billets très courts : de simples notes ou liens, en général sans commentaires. Entre la page de partage et le flux de liens, avec un contenu souvent plus divers qu'un blog classique. Il semblerait que le terme ait été introduit par Why The Lucky Stiff, hacker ruby populaire. Attention à ne pas confondre avec le Microblogging qui consiste à partager sous forme de courts tickets les instants passionnants de sa vie (cf. Twitter et autres sites buggés...).

Et il se trouve que j'utilise la page de partage de Google Reader comme Tumblelog à cette adresse, les derniers articles apparaissant dans la colonne de droite de cette page. Par rapport à ce blog, la fréquence de post est bien supérieure et les sujets plus variés (programmation bien sûr, mais aussi design, art, BD, jeux...).

Pour le principe, j'ajoute ici une liste de tumbles et pages de partage que je suis, en vrac :

Au passage, j'en profite : j'ai "nettoyé" ma colonne de droite : plus de pub, moins de liens useless. J'ai également ajouté un bouton reddit en bas d'article pour ceux qui utilisent cet outil (on en reparlera...). Bonne lecture.

mercredi 9 juillet 2008

Omniscientificoclasme : 1 - Les langages de programmation

Je hais les omniscientifiques. Ceux qui croient tout savoir avec un aplomb digne de Chuck Norris : "Peu importe tes arguments, ma foi en mon propre savoir leur est supérieure.". Ceux qui gaspillent leur énergie à étaler leurs connaissances incomplètes. Ceux qui promeuvent leur culture et leur expériences seules, snobbant tout ce qui ne fait pas partie du cercle de leur "sélection" d'items de valeur. Ceux qui sont constamment blasés de tout (puisqu'ils l'ont déjà vu, lu ou fait, ou qu'ils connaissaient il y a déjà des lustres).


Les omniscientifiques ne sont pas omniscients : ils croient l'être.

Les omniscientifiques ne sont pas scientifiques : ils veulent l'être.


Il est temps de détruire cette engeance malfaisante. Et pour cela, il existe un moyen simple : détruire leur foi en leur savoir faussement complet. Comment ? En mettant en évidence les "trous", les "hiatus" et autres "manques" à leur connaissance, pour enfin faire renaître l'objectivité, l'humilité et la curiosité dans leur esprit biaisé.

Vous aussi, soutenez l'Omniscientificoclasme !


Allez, après la jolie intro, en avant Guingamp !

VOUS NE CONNAISSEZ PAS
TOUS LES LANGAGES DE PROGRAMMATION :


Vous ne connaissez pas GOTO++

GOTO++ est un langage exotique complètement loufoque. Son paradigme est "orienté goto" (vous avez bien lu !). Le GOTO++ doit son nom à l'instruction GOTOGOTO qui va à une étiquette "au pif" dans une liste donnée... Ses types de variables privilégiés sont les étiquettes, les chances, les pingouins, les troupeaux de pingouins, les bergers et les machines à pingouins. A noter qu'il y a aussi une tortue pour faire du dessin à la Logo.

Vous ne connaissez pas Scratch

Scratch est un langage de programmation développé par le MIT, spécifiquement pour les enfants. Basé sur Squeak (une implémentation dérivée de Smalltalk), il a principalement un but éducatif et est très visuel. Un point intéressant est que le langage est dans la langue maternelle de l'enfant (une vingtaine de langues européennes disponibles selon Wikipedia). Il est aussi assez orienté "multimédia" pour encourager le tout jeune hacker. Une guideline à noter (et approfondir peut-être) également est le principe du "Imagine-Programme-Partage" que l'on retrouve notamment dans Hackety Hack (dont on reparlera sans faute !).

Vous ne connaissez pas Factor

Factor est un langage dynamique basé sur la pile (dans la ligné de Forth donc). Il supporte également l'orientation objet, les macros à la LISP et les continuations. Mais ce n'est pas pour autant un langage exotique : toute plate-forme (sauf Solaris apparemment ?), bindings pour OpenGL, Cocoa, X11 ou Win32, client et serveur web, parser XML et autres, support de plusieurs BDD... Un "vrai" langage donc, encore moins connu que Io... avec un logo classe.

Dans notre lutte objective contre les omniscientifiques, ce n'est qu'une première bataille.
D'autres suivront !


NOTA : les images de cet articles appartiennent à leurs auteurs respectifs (Danil Kryvoruchko pour la première et probablement un propagandiste nord-coréen sans droit d'auteur pour la seconde).

dimanche 22 juin 2008

Le Logiciel Libre expliqué à ma Maman (et à toute personne non portée sur l'informatique...)

Le logiciel libre est une notion importante en informatique actuelle. Mais si n'importe quel geek, informaticien ou programmeur maîtrise ce concept, ce n'est pas le cas du grand public et particulièrement des personnes pour qui l'informatique n'est qu'un outil nécessaire, mais souvent un peu compliqué.

Le but de cet article est donc de tenter d'expliquer à ma maman, et par extension à toute personne peu portée sur l'informatique ce qu'est un logiciel libre.
Dans ce cadre, il est très probable que je fasse des raccourcis, analogies ou approximations sur certaines notions ou concepts liés ; à l'attention des personnes pointilleuses sur ces points qui font parfois débat (ou troll), n'hésitez pas à utiliser les commentaires afin de mettre les choses au point, point (poin poin !).
Par ailleurs, seuls les geeks semblent maîtriser le web et avoir le temps de lire les pages présentées dans les liens (et d'autres choses, comme la navigation par onglets sous Firefox ^^) : donc, la plupart des liens pointent vers une simple image (Une image vaut mille mots.).

Qu'est-ce qu'un logiciel ?

Commençons par le commencement ! Word, Excel, Firefox, Outlook Express et iTunes sont des logiciels. C'est probablement ceux qu'utilisent le plus ma maman. Mais ce ne sont que quelques exemples. Window$, MacOS X et Linux sont également des logiciels : ce sont des systèmes d'exploitation (c'est à dire le logiciel qui gère l'interaction avec le matériel, écran, clavier, etc ainsi que la base pour les autres logiciels cités en premier.).
Mais il y a également des logiciels plus "discrets" pour l'utilisateur de base : les "drivers" (ou pilotes) qui font fonctionner du matériel (imprimante, webcam, etc...) sur un PC, les systèmes assurant les transmissions bancaires, les applications web (comme Gmail, ou ce blog), le manager de vol d'un avion, un code calcul scientifique, le système d'un téléphone portable, un guichet de retrait de monnaie ou encore la synchronisation des feux dans les grandes agglomérations.

Pour résumer, sur un ordinateur (au sens large), un logiciel est toute la partie non-matérielle. En anglais, on parle de "Harware" pour le matériel (partie "dure") et de "software" pour les logiciels (partie "légère" ou immatérielle).

Comment construit-on un logiciel ?

Sans trop rentrer dans la technique, quelques notions sont utiles pour la suite.
Tout logiciel est construit à partir d'un "code source" qu'écrit le programmeur, développeur ou codeur (ou ingénieur logiciel, mais celui-ci, il se la pète un peu je trouve ^^). De quoi s'agit-il ? Il s'agit d'un texte, écrit dans un langage spécialement conçu pour "communiquer avec l'ordinateur". Il existe de nombreux langages permettant d'écrire du code.
Le code source peut être défini comme un ensemble d'ordre et de définitions d'ordres que le codeur donne à la machine. Du coup, le code source d'un logiciel peut être comparé à une recette de cuisine à laquelle on ajoute une définition des gestes techniques (abricoter, brider, delayer, etc...).
Par exemple, ci-dessous voici à quoi pourrait ressembler le code permettant d'ouvrir une fenêtre contenant une horloge à l'heure :

Programme Fenetre-Horloge :
ouvrir fenetre
fenetre contient horloge(heure_actuelle)
toutes les 1 secondes : mettre l'heure à jour dans horloge
fin programme


Bien sûr il s'agit de pseudo-code : c'est à dire un langage de programmation que la machine ne comprendrait pas. Mais dans l'esprit, on n'est pas très loin de ce à quoi pourrait ressembler un vrai code source. La preuve, voici un vrai programme faisant ce que je viens de décrire, en Ruby (Ruby est donc un "vrai" langage de programmation) :

stack do
background black
para @time.strftime("%a"),
span(@time.strftime(" %b %d, %Y "), :stroke => "#ccc"),

strong(@time.strftime("%I:%M"), :stroke => white),
@time.strftime(".%S"), :align => "center", :stroke => "
#666"
end

(source : hackety.org par Why's the Lucky Stiff)

C'est déjà moins compréhensible, mais ça marche ^^ !

Qu'est-ce qu'un logiciel libre ?

Un logiciel libre est un logiciel dont la licence dite libre donne à chacun le droit d'utiliser, d'étudier, de modifier, de dupliquer, de donner et de vendre ledit logiciel.
Cette citation Wikipedia est selon moi une bonne définition de ce qu'est un logiciel libre.
Mini-Tux, une mascotte de Linux (libre !)

Contrairement à ce qu'on pourrait facilement penser, un logiciel libre n'est pas forcément un logiciel gratuit. C'est sa licence qui est libre, c'est à dire le texte "juridique" définissant les droits de l'utilisateur sur le logiciel. Même si la majorité des logiciels libres sont gratuits, il en existe quelques un payants, ou en version payante (on y reviendra).

En l'occurrence, l'utilisateur, quel qu'il soit, à le droit d'utiliser le logiciel comme bon lui semble.

Contrairement à la plupart des logiciels propriétaires (non-libres donc), l'utilisateur a également le droit de copier, donner, vendre ce logiciel dans certaines conditions. Il n'y a donc quasiment pas de piratage dans le monde du logiciel libre puisqu'on est libre de dupliquer et de distribuer ces logiciels. Je dis quasiment car les conditions ne sont parfois pas respectées : par exemple une condi tion de redistribution peut être de continuer à montrer le code source (ce que ne font pas toujours les entreprises).

Le droit de vente peut paraître surprenant : pourquoi vendre un logiciel qui peut ensuite être redistribué gratuitement ? En pratique, peu de logiciels libres sont payants. La plupart du temps, le code source du logiciel est gratuit, mais c'est le support associé qui est rémunéré. Par exemple, le logiciel de développement que j'utilise actuellement est libre, mais mon entreprise paye la société qui le distribue pour corriger rapidement les bugs que nous rencontrons, ou ajouter de petites fonctionnalités. Je peux par contre utiliser la version amateur, sans support, gratuitement, à la maison.

L'utilisateur a également le droit d'"étudier" le logiciel : en pratique, cela signifie qu'il a le droit d'accéder au code source du logiciel pour comprendre (ou essayer de comprendre) comment celui-ci fonctionne. On parle alors de logiciel "Open-source" puisque ses sources sont accessibles à tous ; "ouvertes". Bien entendu, ce droit est surtout destiné aux développeurs : ceux qui sont capables de lire le code source.
Hormis le côté éducatif, ce droit a un avantage direct pour un logiciel libre : les bugs et autres erreurs dans le code source sont visibles par tous et donc, le plus souvent, rapide ment détectés. Cela explique également pourquoi les logiciels libres les plus utilisés proposent des mises à jours régulières : les erreurs sont fréquemment corrigées et on en fait profiter les utilisateurs le plus rapidement possible.
Enfin, dans le domaine scientifique, il y a un autre intérêt direct : la vérification. Dans un code de calcul notamment, il devient possible de vérifier les formules et algorithmes qui ont été employés. En cela, le logiciel libre garde l'esprit scientifique (particulièrement mathématique / pas de brevets en maths) qui veut que le savoir soit accessible à tous.

Le logiciel libre en pratique

Beaucoup de logiciels libres sont soutenus par une "communauté". Ce terme, qui fait un peu penser à "secte", "hippy" ou "communisme", désigne simplement un groupe de personnes soutenant un logiciel libre. Il s'agit bien sur de programmeurs qui le développent, mais aussi de simples utilisateurs qui l'utilisent bien sûr, mais aussi qui le testent (et donc préviennent de certains bugs), le diffusent, écrivent de la documentation (aide, wiki, manuels, etc...), font sa publicité, aident les débutants ou même le soutiennent financièrement.

Ce côté communautaire fait souvent croire que le logiciel libre est uniquement l'affaire de quelques passionnés, et que les entreprises ne les emploient jamais. Cela est faux.

Pour le simple utilisateur, un logiciel libre a plusieurs avantages. Comme on l'a vu précédemment, il est souvent gratuit, facilement trouvable puisque librement distribuable et mis à jour régulièrement.
Ensuite, du fait de l'ouverture du code, les logiciels libres sont souvent personnalisables puisque n'importe qui peut proposer un module complémentaire (comme un aspect graphique ou un add-on sous Firefox).
Enfin, de par la compétition (pour ne pas dire guerre) entre les logiciels libres et les logiciels propriétaires, les communautés attachent beaucoup d'importance à aider les nouveaux arrivants, notamment sur les forums d'aide (en principe du moins...).

Un aspect important du libre en informatique réside dans les standards des formats, ce point étant vital pour les utilisateurs de base et probablement encore plus pour les entreprises. Un format, c'est les dernières lettres d'un fichier : par exemple .jpeg ou .gif pour une image, .mp3 ou .ogg pour une chanson, .doc ou .rtf pour un document texte ou encore .xls pour un classeur Excel.
Plus que trois lettres après un point, ces formats désignent la façon dont la machine écrie et lit ces documents : c'est une représentation de la donnée de départ en langage machine ; en règle générale, un être humain ne peut pas lire ces formats.
Le problème est qu'il existe des formats propriétaires. Une entreprise peut donc décider de déposer une licence propriétaire, ou un brevet sur un format qu'elle aurait "inventé". C'est le cas pour Microsoft avec le .doc et le .xls ou le .aac par Sony (entre autres). Alors, elle peut décider de "libérer" son utilisation ou non.
Dans tous les cas, ces formats posent problèment car d'une part, une entreprise peut décider d'abandonner un format (si Microsoft abandonne le .doc, comment ouvrir ses documents dans 10 ans ?) ou d'autre part de restreindre sa diffusion en faisant payer les producteurs d'autres logiciels l'employant. Ou encore de se réserver entièrement les droits sur un format : par exemple pour de l'audio pour écouter un tel format créé par Toshiba, vous devez acheter un lecteur Toshiba (simple exemple).

En général, les logiciels libres préfèrent créer ou/et employer des formats libres et standards assurant ainsi la compatibilité entre les différentes applications (par exemple un format de tableau pourrait être lisible par différents logiciels tableurs -comme Excel-) ainsi que la pérennité des documents.

Quelques exemples de logiciels libres (propriétaires) :

  • Firefox ; navigateur web (InternetExplorer, Safari, Opera...)
  • Thunderbird ; outil de messagerie (Outlook Express...)
  • Azureus, EMule ; peer-to-peer (?)
  • OpenOffice.org ; suite bureautique (Microsoft Office...)
  • Linux ; système d'exploitation (Windows, MacOS)
  • The Gimp ; dessin et traitement d'image (Paint, Photoshop...)
  • SciLab ; outil scientifique (MatLab, Maple...)
Références :


Alors Maman, tu as compris ?

Les commentaires sont ouverts !

jeudi 12 juin 2008

Firefox 3 - D-Day !

Je ne vais pas vous faire étalage des avantages de Firefox sur la concurrence dans le monde merveilleux des navigateurs web. Non. Mais je vous encourage vivement à participer au Download Day de Firefox 3.

Il s'agit d'essayer d'établir le record du plus grand nombre de téléchargements pour un logiciel en 24H. Amusant non ? Outre le fait que c'est un évènement marketing sympa, c'est l'occasion de découvrir, ou mettre à jour l'un des meilleurs navigateurs disponibles sous toute plate-forme.

Vous pouvez déjà effectuer une promesse de téléchargement sur la carte du monde (la France n'est d'ailleurs pas si mal placée ^^) ou patienter gentiment jusqu'à... Mardi 17 Juin (selon Silicon.fr, qui a réalisé il y quelques jours une interview de Tristan Nitot, Prez' de Mozilla Europe, sur la sortie du dernier panda rouge).

Bon téléchargement !

vendredi 30 mai 2008

Google Reader pour Lefty

Les flux RSS sont vraiment un moyen très puissant de se tenir au courant à moindre coût : c'est une application "assez" récente d'Internet, qui à mon avis est encore mal maîtrisée par l'internaute moyen (ce qui n'est pas le cas de Lefty, puisque celui-ci a un blog - waow ! -).


Présentation :

L'intérêt des flux RSS réside dans un principe très simple :

"Chercher une information qui vous intéresse sur le web est en soi une perte de temps : c'est l'information qui vous intéresse qui doit arriver à vous."

D'où ces flux qui vous tiennent au courant des dernières entrées du blog de votre pote qui joue de la gratte, des dernières nouvelles concernant les JO ou d'une réponse à votre message sur un forum de discussion.
La question est comment ? Comment profiter de ces outils le plus simplement et naturellement possible ?

Il existe grosso-modo 3 méthodes :

  • Via son navigateur web
  • Via un agrégateur de flux offline et/ou son logiciel de messagerie
  • Via un agrégateur de flux online
La plupart des navigateurs web modernes intègrent des outils de lecture de flux RSS/ATOM. Mais dans l'ensemble je les trouve reltivement peu pratiques. Le modèle de Safari est assez peu intuitif, avec un rendu assez médiocre. Opera est un peu mieux sur ce point, mais j'accroche pas. Firefox (v2, j'attends la suite...) par contre, propose les marque-pages dynamiques qui peuvent être intéressants : ceux-ci se présentent comme des favoris classiques qui se déroulent pour révéler les dernières entrées du flux. C'est surtout pratique pour les flux souvent mis à jour (tumblelog, blogger hyperactif ou site d'informations), mais là encore, il faut faire l'effort de cliquer dessus pour être tenu au courant (monde de feignants...).


Les agrégateurs de flux, eux, se présentent davantage comme des logiciels de messagerie, recevant les entrées comme des messages. D'ailleurs, différents logiciels de messagerie proposent cette fonctionnalité, Mozilla ThunderBird notamment.

Mais il existe une méthode qui paraît plus "logique" : les agrégateurs de flux online comme Google Reader, NetVibes (qui est en fait un peu plus qu'un simple agrégateur : plus proche d'iGoogle peut-être...) ou BlogLines (et bien d'autres...).

Google Reader :

Je vais m'intéresser maintenant plus particulièrement à Google Reader. (Non, je n'ai pas d'action chez Google : je ne leur fais pas de pub... juste de la propagande. On en reparlera...)

L'intérêt, à mon sens, de Google Reader, c'est qu'il se présente quasiment comme Gmail : si on utilise cette messagerie, on ne sera pas dépaysé.
Pour ajouter des abonnements, rien de plus simple : on peut entrer l'URL du flux désiré (via "ajouter un abonnement"), ou importer une liste de flux (fichier au format OPML) dans "Gestion des abonnement/Importer" ou encore lancer une recherche et attendre les propositions du moteur. Si en plus on possède un navigateur profondément bon (comme, je sais pas moi... Firefox ?), celui-ci vous propose de l'y ajouter lorsque vous cliquez l'icône d'abonnement sur un site.

En dehors des fonctionnalités de base, comme tagger ses articles, assurer un suivi, ajout à iGoogle et quelques stats, Google Reader permet également de "partager" des items. C'est à dire que suite à la lecture d'un très bon article sur l'un de vos flux, vous pouvez cliquer sur "Partager" pour l'ajouter à votre page de partage. Cette page web est "publique" et est donc accessible à quiconque en connait l'adresse : à fournir à vos amis par exemple.


Mais allons un peu plus loin. Il existe évidemment un widget pour ajouter vos derniers coups de cœur à votre site ou à votre blog (painless, surtout chez Blogger). Du coup, on obtient quasiment un "Tumblelog" (blog avec messages très courts, le plus souvent un simple lien vers une page intéressante).
Attention, maintenant grosse manip' bien technique : dans "Paramètres", passer la langue en Anglais et là "KABOOM"* : vous pouvez à présent ajouter des notes qui seront partagées par défaut (décocher la case "Share" sinon) et la possibilité de changer l'apparence de votre page de partage (d'où les petits ninjas sur la mienne**). Du coup, on a effectivement un Tumblelog à pas cher...

Je suis sûr que ça va intéresser Lefty...



* : Si vous ne parvenez pas à effectuer cette manipulation, merci de contacter notre équipe d'assistance au 080808, 44€55/s...
** : Dans la colonne de droite, juste en dessous de la pub sur laquelle vous ne cliquez jamais bande de rats !
*** : Les images de cet article appartiennent à leurs propriétaires respectifs. Pas à moi donc...

mercredi 21 mai 2008

Typage statique pour Ruby

Via cet article sur Segment7, voici le lien vers une publication sur le développement de DRuby (DiamondBack Ruby) [:en, :pdf] : un outil (codé en OCaml) visant à autoriser le typage statique en Ruby. Le code source de cette application devrait être publié dans les mois à venir.

J'ai un avis assez mitigé sur ce genre de projet : d'un côté, j'apprécie la possibilité de choisir (cf. article précédent sur le typage en Groovy), et je reconnais tout à fait beaucoup des avantages du typage statique. Parmi eux, une certaine fiabilité et la détection précoce d'erreurs de développement.
Mais en Ruby (Perl, Python, etc...) ? L'un des avantages de ces langages dynamiques n'est-il pas d'"éluder" au maximum les contraintes de type pour un développement plus rapide et libre ? En Ruby en tout cas, la "philosophie" veut que l'on s'intéresse davantage au comportement d'un objet (no primitive type here !) qu'à sa classe (principe du "Duck Typing"). On croise donc plus souvent des foo.respond_to? :a_method que des foo.is_a? A_Class.

Il est cependant intéressant de se poser la question suivante (et pas seulement en Ruby !) :

Comment et/ou avec quelles techniques, assurer la fiabilité d'un programme dans un langage dynamique ?

Je vais essayer de bientôt placer quelques petits exemples de code sur ce sujet.

jeudi 13 mars 2008

Un générateur de MIDI en Ruby

Giles Bowkett est un étonnant programmeur Californien qui a développé un générateur de MIDI, en Ruby : Archaeopterix. Pour rappel, le MIDI est une interface audio électronique. Manifestement, il utilise pour cela le logiciel Reason, bien connu dans ce domaine...


Des liens en vrac sur le sujet :


Voilà, c'est fait, j'ai parlé musique... Et au passage, c'est une application originale et relativement inattendue pour un langage de programmation, et le Ruby en particulier.

Relativement, car Ada Lovelace, scientifique du XIXème ayant donné son nom au langage Ada avait avancé, aux alentours de 1840, que, je cite : "La machine [- son anticipation de l'ordinateur, de fait -] pourrait composer de manière scientifique et élaborée des morceaux de musique de n'importe quels longueur ou degré de complexité.". Etonnant, non ? Qu'on ne vienne plus me parler de SF après ça... et pour ceux qui veulent un de vrai musique, c'est par là, chez un escroc notoire.

mardi 11 mars 2008

Débutons en Ada

En Ada 95 plus précisément... Deux docs et un livre :


Les deux premiers docs sont idéaux (et non pas "idéals"...) pour attaquer Ada en ayant déjà des connaissances en programmation, mais ne creusent pas nécessairement certains aspects très particuliers ou avancés du langage... Le livre de Barnes est en revanche très complet, et part du (tout) début : plutôt clair en général.
Une bonne base pour attaquer.

dimanche 9 mars 2008

Work World Whores


Big Billou soit loué ! Jason Calcanis, fondateur de Mahalo (un moteur de recherche moyen mais pas trop...), vient de publier sur son blog une liste d'astuces pour économiser de l'argent pour une start-up (trouvé via techcrunch / techcrunch en français). Alors bon, c'est un peu en décalage par rapport aux sujets habituels de ce blog, mais je vais me permettre de commenter un peu ses "astuces". D'abord parce qu'elles ne sont pas toutes immondes. Ensuite parce qu'elles ne se limitent absolument pas au monde psychédélique des start-up.

How to save money running a start-up, by J. Calcanis.

Passons en revue ces 18 points :

  1. Achetez des Macs. Tu es sur la bonne voix pitchoune : une licence MacOS X.5 coûte effectivement moins cher qu'une Vista et est meilleure. Mais pourquoi s'arrêter en si bon chemin ? Même avec des macs, il me paraît illusoire de croire que l'on peu complètement s'affranchir des frais d'une équipe d'assistance ou réseau. A ce compte là, autant passer sur un OS libre, gratuit et efficace. Bien sûr, je pense à Linux. OpenSolaris aussi. Dans certains domaines, comme les sciences et/ou avec une dose importante de développement informatique, je ne comprends pas qu'on investisse dans autre chose...
  2. Achetez un second écran pour chaque employé. Oh god damn' yes ! Je prends. Win-win.
  3. "Pas de réunion" : faites vos réunions pendant les repas. Oui et non. Il faut aussi couper la journée. Tojo ! Pourquoi pas des entretiens aux toilettes ?
  4. Achetez des tables "cheap" et de très bonnes chaises. Tout à fait d'accord, mais pas pour les mêmes raisons. Qui se soucie de bosser sur un bureau à 3000 quand il a le postérieur éclaté sur une chaise pourrave ? Idem : de bons écrans/claviers/souris sont plus importants qu'une unité centrale esthétique.
  5. Pas de système de téléphones : utilisez IRC ou autre. Pourquoi pas, mais : si les PC / le réseau plante(nt), comment tu préviens l'assistance ? A voir.
  6. Louez vos bureaux en trop. Bof bof...
  7. Outsource et RH... No comment.
  8. N'achetez que quelques licences Microsoft Office et utilisez Google Docs. Nan. Achetez UNE licence MS Office complète (avec PDF converter) et n'utilisez QUE Open Office. Bannissez le .doc. C'est mal.
  9. Ne payez pas pour un serveur d'échange, utilisez GMail. Oui, mais il manque quand même des fonctionnalités.
  10. Payez des PC à ceux qui bossent le plus pour qu'ils continuent à la maison. On te pendra avec tes tripes.
  11. Virez ceux qui ne sont pas des workaholics ("fous de travail"). Augmente tes salaires tojo ! (On te pendra quand même, et en plus on va te châtier. Grave.)
  12. Achetez de la bouffe et une très bonne machine à café pour garder les employés au bureau. C'est vicelard, mais il faut reconnaître que c'est pas forcément désagréable. D'autant que payer à la machine à café, au taf (payer - au taf), c'est très désagréable. Win-win.
  13. Pareil avec des sodas. Idem donc.
  14. Autoriser les gens à faire les horaires qu'ils souhaitent (arrivée et départ, hein !). Oui : win-win. Non, quand celui qui se pointe à 11H fait rester celui qui est là depuis 8H le soir à 20H pour une release naze.
  15. Négocier des prix de gros. Incroyable ! Innovant ! Personne n'y avait pensé !!!
  16. Ne perdez pas d'argent avec des recruteurs, utilisez FaceBook. Hahahaha !!! Quel cou1llon ! Tu vas engager qui ? Celui qui a le plus de potes ? Celui qui lance le plus de moutons ? Ou celui qui a reçu comme "gift" un caleçon à cœur ? Cela dit, il existe des méthodes alternatives efficaces, comme la cooptation.
  17. Prendre un consultant plutôt qu'un contrat avec une PR firm. A voir... différences entre les USA et la France à ce niveau ?
  18. Outsource to Middle America. Comme nous en Inde ? Touss touss...

Bref, vous l'aurez compris : un employé prend en moyenne 15 minutes par jour pour déféquer : 15 min * 218 jours par an donnent environ 37 H, soit près d'une semaine de travail perdu dans les toilettes.

EMPLOYES ! PRENEZ SUR VOUS ! NE CH1EZ PLUS !


vendredi 22 février 2008

Galerie Cod'Art

Une très bonne initiative : des membres du Site du Zéro ont réalisé une galerie des "oeuvres" de l'Atelier Cod'Art, qui avait eu lieu l'été dernier sur ce site. Le but était de découvrir la programmation graphique, c'est à dire générer des images (ou animations) uniquement via du code et de les présenter avec leur source. Il y a eu beaucoup de fractales bien sûr, mais beaucoup de choses originales aussi. L'aspect visuel de certaines réalisations est vraiment superbe et plusieurs font de bons fonds d'écran.

Pour ma part, j'avais fait un peu original en présentant une petite version du jeu de la vie de Conway (gif ci-dessus) avec des couleurs plus ou moins aléatoires (! - c'est pas génial visuellement, mais c'était une des rares animations), en Ruby avec la gem RMagick (binding vers ImageMagick, lib de graphisme très utilisée et disponible pour de nombreux langages). A noter que mon code tournait (à l'époque du moins) sur la version Linux de RMagick, pas celle de Windows (dû à des différences d'avancement de RMagick).

Liens :

mardi 19 février 2008

Et maintenant, quel langage ?

Les habitués de forums de programmation pour débutants (SDZ ?) devraient avoir souri en lisant ce titre... (En effet, ce type de forum voit apparaître avec une fréquence de 2 à 10 par semaine des sujet portant un titre approché de ça : "Quel language choisire svp URGENT ?" le plus souvent).

Blague à part, la question n'est pas idiote. Loin de là.
Quel langage apprendre ?

Des langages !
Beaucoup !

Il y a beaucoup de langages. De plus en plus même (note : je vais parler ici des "vrais langages" de programmation, c'est à dire, à mon sens, ceux qui sont Turing-complet ; pas du HTML, LaTeX, XML ou autres...).

Lesquels sont généralistes ? La plupart.
Lesquels sont spécialisés ou orientés vers une utilisation précise ? La plupart aussi !
Je m'explique : Fortran permet de tout faire (à condition d'être courageux) mais n'a que peu d'intérêt en dehors du domaine scientifique. Ruby est généraliste, mais est surtout employé pour des applications web (Rails...). Python permet de faire de "vrais" programmes mais sera surtout utilisé (dans le monde pro) pour du scripting d'appoint. On cherche encore Ada ailleurs que dans de l'embarqué et le Javascript ailleurs que dans des applis web côté client... Et pourtant, dans l'absolu, tous permettent de faire la même chose.

Les généralistes et les familles

Cela dit, il existe quelques langages qui sont utilisés (utilisables ?) pour à peu près tout : le C++ et le Java. Pas de chance pour eux (ou pour moi !), je ne les apprécie pas outre mesure. Sans être allergique au C++ que j'ai déjà utilisé en milieu professionnel, je trouve qu'ils sont assez proches et assez lourds (j'ai déjà le Fortran à la maison, merci !) : je reconnais sans problème leurs qualités respectives, mais ils ne conviennent pas, à mon sens, pour un usage domestique/éducatif/récréatif. De plus il ne recèlent pas ou peu de concepts nouveaux pour moi (même si ça ne me ferait pas de mal de revoir la gestion des pointeurs et références en C++ et deux, trois petites choses...).

Dans le même ordre d'idée, je pourrais me mettre au Python. Mais comme il est très proche de Ruby, à quoi bon ? Me taper les différences de syntaxe et de convention pour faire les mêmes choses qu'en Ruby mais en Python ? Pas assez rentable à mon goût ! Je pense, ou plutôt espère, que connaître un langage dans une "catégorie" facilite et accélère l'apprentissage des langages proches, en cas de nécessité. Par exemple pour Ruby : Python, Perl, Groovy, Smalltalk...

Coder, pourquoi ?
Coder plus pour gagner plus...

Car si je code, ce n'est pas que pour le plaisir.

C'est vrai qu'après des débuts difficiles, je me suis mis à apprécier de plus en plus la programmation, pour pas mal de raisons. D'abord pour l'aspect mathématique assez fort que j'y retrouve. Ensuite pour le côté "Lego" : il y a un aspect "architectural" dans la construction d'un programme, des contraintes mais aussi une grande liberté devant son éditeur de texte (un peu comme face aux briques), et une fois terminé on peut "jouer avec" son programme. Enfin, c'est un monde riche en "concepts" liés à l'image que l'on (l'homme et/ou la machine) se fait d'un problème et de sa résolution.

Mais la programmation, c'est aussi une partie importante de mon métier (ingénieur modélisation - bon, ok, pas en ce moment, mais je vais trouver ^^). Et dans ce contexte, à mon niveau, il n'est pas question de choix. On travaille avec le(s) langage(s) qu'on nous donne. Et c'est là que ça se gatte... Dans le domaine de la simulation et analyse numérique, sont surtout utilisés le Fortran et le C++, que je maîtrise "relativement" bien. Les informations glanées sur le web, au cours d'entretiens, etc... ont mis en lumière d'autres "technologies" possibles : Matlab, VisualBasic, C et Ada principalement.
  • Je pourrais me mettre au Matlab mais c'est pas gratuit, même s'il existe SciLab dans le genre...
  • L'environnement VisualBasic, malgré tout le mal que j'en pense, a été installé sur ma bécane... moins d'une heure. Déjà, les IDE m'insupportent, alors quand on ajoute un helper autiste et des tutos qui commencent par "Comment insérer un copyright dans votre programme" (véridique : cherchez sur le web !) et enchaîne sur "Créer un menu dans une fenêtre", ça fait beaucoup. Sans rire, ce genre de truc est extrêmement dangereux pour le PC d'un gars comme moi... Dix minutes de plus et je transperçais l'écran à coup de tête. Dangereux je vous dis !
  • C après C++, connaissant le Fortran ? Mouais...
  • Ada serait sans doute le plus intéressant, mais il y a peu de chance qu'il me serve en milieu professionnel, vu qu'il est le plus souvent dédié au systèmes embarqués (domaine intéressant, mais un peu loin de ma branche).

L'utilisation éventuelle d'un langage en entreprise m'aide donc peu.

Concept ?
Aqui lo paradigme !

Il reste les "concepts".
Cela fait déjà un bon moment que le monde de la programmation fonctionnelle me fascine : attraction/répulsion.
Attraction car c'est une grande famille de langages, de LISP à Haskell en passant par Scheme et OCaml avec des méthodes intéressantes.
Répulsion car jusqu'ici, j'ai toujours été incapable de "décrypter" le moindre bout de code fonctionnel aperçu ici ou là : crispant.
Il y a aussi d'autres "concepts" (paradigmes en l'occurrence ici) : logique (PROLOG), concurrent (Ada, encore !), par contrainte...

Finalement...
Tout ça pour ça...

Finalement, c'est par hasard que je me suis mis... au Scheme.
Un article, chez RubyInside, décrivait un interpréteur pour Scheme, codé en Ruby, dans le bus. J'ai voulu tester. Du coup, il m'a fallu taper un peu de Scheme ; du coup, j'ai lu du Scheme ; du coup je me suis mis à comprendre un peu le Scheme ; du coup, j'apprends le Scheme.
Pour être tout à fait franc, ce langage faisait déjà parti de ceux qui me tentaient fortement, avec le LISP, l'OCaml, Io et Cobol (non, pour le Cobol, j'd3conne !).
Io a perdu car je voulais voir autre chose que de l'OO. Quite à se lancer dans le fonctionnel, autant prendre un langage "simple" : l'OCaml me semblait "trop riche" car multi-paradigme. Enfin, le LISP a eu un petit désavantage : cette citation de G. Chaitin sur la "pureté" d'un langage.
Scheme donc, avec l'interpréteur MzScheme (Bus-Scheme, celui en Ruby étant... peu utilisable ?).

Effectivement, Scheme est austère. Mais il semble reconnu pour son côté pédagogique et est (hormis pour les parenthèses) assez bref dans sa syntaxe : il y a une certaine élégance proche des maths je trouve. Il est vieux, mais a un certain charme... et j'avoue que je l'apprends avec un certain plaisir. Et pour ma bonne conscience professionnelle, Scheme est utilisé dans certains codes de calculs industriel, en appoint (bientôt un article sur "Quel(s) langage(s) dans tel programme ?").Que demander de plus ?

Références et Docs :

D'abord, deux textes pleins de sagesse (si si, il y a un rapport avec le reste...) :
L'article sur Bus-Scheme, l'implémentation en Ruby :
Commençons gentiment en Scheme (avec un interpréteur qui marche !) :
Pour tout le reste vu dans cet article, Wikipédia saura répondre... sinon demandez toujours !