• THINGM
• SPARKFUN
• LEXTRONIC
• HACKABLE DEVICES
• E44
• SELECTRONIC
• RADIOSPARES
• DEAL EXTREME
• GOTRONIC
• ROUND SOLUTIONS
• ALDAFUNK
• MODERN DEVICES
• DORJI
• PYMCU

Editez :

/etc/kismet/kismet.conf

Cherchez la ligne qui concerne la source.

• Carte Alfa

  source = rt8180, wlan0, ALFA

• Carte Ralink

  source = rt73, rausb0, Ralink

• Carte Realtek

  source = rt8180, wlan0, RTL8187

• Carte Atheros

  source = madwifi_g, wifi0, Atheros

• Carte Zydas

  source = zd1211, eth0, ZyDAS

Cette décontraction du sentiment d'interdit se repère aussi à la manière dont les filles se hiérarchisent dans la société. Alors que les petits garçons, très tôt, inventent des jeux de compétition, les filles inventent des jeux de coopération. Les garçons grimpent dans la hiérarchie ou s'en excluent, constituant ainsi la majorité aux grandes écoles, parmi les clochards et les délinquants. Ce n'est pas le cas des filles, qui intègrent moins les grandes écoles et deviennent rarement clochardes ou délinquantes car cette manière de se socialiser par le triomphe ou l'exclusion n'a pas de valeur sociale pour elles, alors qu'elle peut éventuellement en avoir une sexuelle.

[…]

Il semble donc que les femmes se socialisent par leurs manières d'aimer tandis que les hommes se socialisent par leurs manières d'agir. D'ailleurs, les sexes ne s'y trompent pas, puisque les femmes sont plutôt séduites par les indices sociaux que les hommes manifestent comme des promesses d'existence ; alors que les hommes sont plutôt séduits par les indices physiques et affectifs que les femmes portent sur elles comme des promesses d'amour.

Les Nourritures affectives, Boris Cyrulnik

J'ai découvert, avec l'alpinisme, un milieu où la proportion d'hommes est encore plus importante que l'informatique (en moins jeune). Et ça m'interroge forcément sur mon attirance involontaire pour ces disciplines. Qu'est-ce que j'y cherche ?

Je ne pense pas y chercher (ni y trouver d'ailleurs) une quelconque reconnaissance sociale. Il y a une sorte de momentum en ce moment autour du geek qui est un simple contrecoup du cliché d'informaticien boutonneux de ces dernières décennies mais cela va se stabiliser assez vite. C'est ce qu'il s'est également produit avec l'alpinisme qui tend à se banaliser (et à se consommer mais ce sera l'objet d'un futur billet).

Je ne pense pas non plus y chercher un père « spirituel » suite à mon défaut de père biologique. La lecture de Boris Cyrulnik m'aide à comprendre certains mécanismes complexes à ce niveau et me conforte — ou au moins clarifie — cette prise de position. Si ce n'est pas la testostérone qui est en jeu, il va falloir creuser un peu plus.

J'ai l'impression d'être davantage attiré par la capacité d'adaptation que l'on retrouve dans l'informatique et l'alpinisme : prendre connaissance de l'environnement, choisir sa voie, échanger ses connaissances et ses expériences (résilience), faire des choses en petites équipes (pluridisciplinarité). Toutes ces actions reviennent pour moi à définir l'intelligence et c'est peut-être ce que je cherche à travers tout ça : faire travailler mes cellules.

Merci pour la psychanalyse mes petits canards numériques :-).

Jour 1 : Réveil à 7h pour aller prendre le tramway du Mont-Blanc au col de Voza après une courte nuit sous la tente. On aperçoit déjà le refuge du Goûter qui brille tout là-haut, à 3835 mètres d'altitude. L'objectif de la journée est de le rejoindre sans trop forcer — ce qui va s'avérer plus difficile que prévu. Premier stress : essayer de faire rentrer tout l'équipement nécessaire dans mon sac de 22 litres, ça déborde un peu mais je sais que je ne vais pas tenir longtemps en t-shirt. À la descente du tramway au Nid d'aigle (2372 mètres), une longue file ininterrompue se forme pour rejoindre le refuge de Tête Rousse (3167 mètres) que l'on rejoint en mode randonnée classique. Quelques pas sur des névés et on arrive à la difficulté de la journée : le couloir du Goûter — rebaptisé « couloir de la mort » en raison du nombre d'accidents lors de sa traversée. En effet, des pierres dévalent en continu les 500 mètres de couloir qu'il faut traverser. Casques et rapidité sont de rigueur sur un sol qui ne permet pas non plus de courir en raison des chutes de neige de ces derniers jours. Quelques esquives plus tard, il faut maintenant monter jusqu'au refuge en escalade facile (si la roche n'était pas aussi friable). Il me faut quelques minutes pour être à l'aise avec les crampons dans les rochers et faire confiance au matériel. Arrivée au nouveau refuge du Goûter qui se veut être le fleuron de ce que l'on peut faire en matière d'écologie et de technologie. On se retrouve avec une pièce commune qui semble être designée par Ikea, à se demander si l'avenir est à la montagne aseptisée et déshumanisée, au moins ont-ils réussi à insonoriser les lieux ce qui est appréciable lorsque 120 personnes se mettent à table. Grosse sensation de fatigue accumulée sur ces derniers jours, exacerbée par la dernière montée qui a laissée des traces, pas terrible pour partir en confiance le lendemain… heureusement aucune trace de mal aigu des montagnes, il faut croire que la journée d'acclimatation à l'aiguille du Midi a porté ses fruits.

Jour 2 : Réveil à 3h pour un petit déjeuner express, l'ambiance est à l'économie de paroles, de gestes, de souffle. C'est une peu la cohue dans la salle où tout le monde chausse et s'encorde mais ça reste raisonnable. Crampons ajustés, bâtons vissés, corde avalée, c'est parti pour le dôme du Goûter (4304 mètres) à la suite de quelques cordées qui donnent un rythme irrégulier, cassant. Le dôme que l'on apercevait du refuge semble maintenant si loin, et le vent commence à souffler faisant tomber la température aux alentours des -15°C. Difficile entrée en matière, on décide de faire une pause au sommet pour boire un peu et prendre une barre après 1h30 d'effort. Le temps de se refroidir et de constater que la pipette à eau est en train de geler… Petite descente avant d'attaquer la montée vers l'abri Vallot (4362 mètres), les extrémités commencent à geler ce qui m'oblige à faire bouger mes doigts en permanence, l'inclinaison de la pente est telle qu'il faut parfois avancer avec la pointe des crampons en biais mais le soleil réconfortant commence à éclairer l'horizon de manière spectaculaire. On distingue les sommets environnants qui semblent tout petits malgré leurs 4000 mètres. Un coup d'œil vers le haut me permet d'apercevoir l'arrête sommitale, je me retourne vers mon oncle avec un grand sourire : « on va le faire ! ». C'est le moment où la fatigue commence à arriver après 3 heures d'effort dans le froid et l'oxygène se fait de plus en plus rare (45% en moins au sommet du Mont-Blanc). On dépasse quand même quelques cordées ce qui me rassure sur mon niveau de forme. On aperçoit enfin le sommet (4810 mètres), j'avale les quelques mètres de corde qui me séparent de mon compagnon de cordée pour que l'on finisse ensemble et on laisse éclater notre joie avant de se couvrir rapidement car il y a un peu de vent. On savoure ce moment unique en passant une petite heure au sommet, ce qui nous permet de récupérer aussi après 3h30 de montée !

La descente jusqu'au refuge est très agréable, surtout après l'euphorie sommitale, on y fait une pause pour se rassasier un peu et surtout se réhydrater vu que ma poche à eau avait gelée à la montée. Un peu de désescalade pour arriver jusqu'au couloir où l'on profite d'une accalmie dans les chutes de pierres pour passer sans trop de stress. Il est temps de regarder les horaires du tramway pour redescendre, il n'y en a qu'un toutes les 1h40 ! Et le prochain est dans 1 heure, on tente le coup malgré les 800 mètres de dénivelés à se faire. Dur pour les genoux mais on arrive à temps, ouf ! Avec le recul ça aura été le plus fatigant de la journée :p

Vouloir atteindre le sommet du Mont-Blanc est un premier pas dans l'alpinisme. Cela demande une bonne condition physique, une bonne acclimatation, une bonne météo et un peu de chance pour passer le couloir du Goûter sans se prendre un caillou mal placé. Rien d'inaccessible ni de technique et relativement peu de dangers (surtout vu l'affluence) si l'on est correctement équipé et entraîné. Je ne souhaite pas minimiser le risque pour autant d'une telle course et je vous invite à vous faire accompagner d'un guide, d'autant plus si vous souhaitez emprunter une autre voie.

J'ai publié quelques photos de cette ascension.

Editez :

/etc/kismet/kismet.conf

Cherchez la ligne qui concerne la source.

• Carte Alfa

  source = rt8180, wlan0, ALFA

• Carte Ralink

  source = rt73, rausb0, Ralink

• Carte Realtek

  source = rt8180, wlan0, RTL8187

• Carte Atheros

  source = madwifi_g, wifi0, Atheros

• Carte Zydas

  source = zd1211, eth0, ZyDAS

• THINGM
• SPARKFUN
• LEXTRONIC
• HACKABLE DEVICES
• E44
• SELECTRONIC
• RADIOSPARES
• DEAL EXTREME
• GOTRONIC
• ROUND SOLUTIONS
• ALDAFUNK
• MODERN DEVICES
• DORJI
• PYMCU

Now that we have enough details about how the NSA eavesdrops on the internet, including today's disclosures of the NSA's deliberate weakening of cryptographic systems, we can finally start to figure out how to protect ourselves.

NSA surveillance: A guide to staying secure, Bruce Schneier

Bruce donne quelques conseils dédiés aux citoyens mais je m'interroge sur ma responsabilité en tant que développeur : comment faire en sorte qu'une rencontre avec les services secrets soit la moins problématique ? Comment préserver l'intimité de l'ensemble de mes utilisateurs ?

Une première action à entreprendre pourrait être de séparer les données des utilisateurs par pays/juridiction afin de n'en révéler qu'une partie. On pourrait même aller plus loin dans le découpage afin de pouvoir fournir uniquement les données propres à un utilisateur ou aux amis de ses amis.

Une seconde action qui irait probablement aux limites de la législation en vigueur dans les états concernés serait de mettre en place une commande de suppression des relations (attention, pas des données) et de délivrer les données à plat sans pouvoir suivre les liens entre les personnes/media/discussion/etc.

Une autre option est de ne stocker que des données chiffrées côté client, c'est ce que fait le service ZeroBin par exemple (il y a même une version en Python). Même avec un très gros datacenter ça prend quelques temps à déchiffrer si chaque clé unique est générée par chaque utilisateur.

Enfin il y a énormément de choses à inventer en matière de pair-à-pair et, même si des connexions asymétriques rendent les échanges de données moins performantes, la démocratisation du haut-débit est suffisante pour échanger au moins du texte de manière privée et sécurisée.

Je suis surpris qu'il y ait si peu d'initiatives de résistance de la part des geeks pour mettre en place les solutions techniques qui sont à notre disposition afin de réacquérir une intimité à nos échanges sur le web.

The EuroScipy2013 conference was held in Bruxelles at the Université libre de Bruxelles.

As usual the first two days were dedicated to tutorials while the last two ones were dedicated to scientific presentations and general python related talks. The meeting was extended by one more day for sprint sessions during which enthusiasts were able to help free software projects, namely sage, vispy and scipy.

Jérôme and I had the great opportunity to represent Logilab during the scientific tracks and the sprint day. We enjoyed many talks about scientific applications using python. We're not going to describe the whole conference. Visit the conference website if you want the complete list of talks. In this article we will try to focus on the ones we found the most interesting.

First of all the keynote by Cameron Neylon about Network ready research was very interesting. He presented some graphs about the impact of a group job on resolving complex problems. They revealed that there is a critical network size for which the effectiveness for solving a problem drastically increase. He pointed that the source code accessibility "friction" limits the "getting help" variable. Open sourcing software could be the best way to reduce this "friction" while unit testing and ongoing integration are facilitators. And, in general, process reproducibility is very important, not only in computing research. Retrieving experimental settings, metadata, and process environment is vital. We agree with this as we are experimenting it everyday in our work. That is why we encourage open source licenses and develop a collaborative platform that provides the distributed simulation traceability and reproducibility platform Simulagora (in french).

Ian Ozsvald's talk dealt with key points and tips from his own experience to grow a business based on open source and python, as well as mistakes to avoid (e.g. not checking beforehand there are paying customers interested by what you want to develop). His talk was comprehensive and mentioned a wide panel of situations.

We got a very nice presentation of a young but interesting visualization tools: Vispy. It is 6 months old and the first public release was early August. It is the result of the merge of 4 separated libraries, oriented toward interactive visualisation (vs. static figure generation for Matplotlib) and using OpenGL on GPUs to avoid CPU overload. A demonstration with large datasets showed vispy displaying millions of points in real time at 40 frames per second. During the talk we got interesting information about OpenGL features like anti-grain compared to Matplotlib Agg using CPU.

We also got to learn about cartopy which is an open source Python library originally written for weather and climate science. It provides useful and simple API to manipulate cartographic mapping.

Distributed computing systems was a hot topic and many talks were related to this theme.

Gael Varoquaux reminded us what are the keys problems with "biggish data" and the key points to successfully process them. I think that some of his recommendations are generally useful like "choose simple solutions", "fail gracefully", "make it easy to debug". For big data processing when I/O limit is the constraint, first try to split the problem into random fractions of the data, then run algorithms and aggregate the results to circumvent this limit. He also presented mini-batch that takes a bunch of observations (trade-off memory usage/vectorization) and joblib.parallel that makes I/O faster using compression (CPUs are faster than disk access).

Benoit Da Mota talked about shared memory in parallel computing and Antonio Messina gave us a quick overview on how to build a computing cluster with Elasticluster, using OpenStack/Slurm/ansible. He demonstrated starting and stopping a cluster on OpenStack: once all VMs are started, ansible configures them as hosts to the cluster and new VMs can be created and added to the cluster on the fly thanks to a command line interface.

We also got a keynote by Peter Wang (from Continuum Analytics) about the future of data analysis with Python. As a PhD in physics I loved his metaphor of giving mass to data. He tried to explain the pain that scientists have when using databases.

After the conference we participated to the numpy/scipy sprint. It was organized by Ralph Gommers and Pauli Virtanen. There were 18 people trying to close issues from different difficulty levels and had a quick tutorial on how easy it is to contribute: the easiest is to fork from the github project page on your own github account (you can create one for free), so that later your patch submission will be a simple "Pull Request" (PR). Clone locally your scipy fork repository, and make a new branch (git checkout -b <newbranch>) to tackle one specific issue. Once your patch is ready, commit it locally, push it on your github repository and from the github interface choose "Push request". You will be able to add something to your commit message before your PR is sent and looked at by the project lead developers. For example using "gh-XXXX" in your commit message will automatically add a link to the issue no. XXXX. Here is the list of open issues for scipy; you can filter them, e.g. displaying only the ones considered easy to fix :D

For more information: Contributing to SciPy.

I had the pleasure to be invited to lead a tutorial at JDEV2013 titled Learning TDD and Python in Dojo mode.

I quickly introduced the keywords with a single slide to keep it simple:

http://Python.org
+ Test Driven Development (Test, Code, Refactor)
+ Dojo (house of training: Kata / Randori)
= Calculators
  - Reverse Polish Notation
  - Formulas with Roman Numbers
  - Formulas with Numbers in letters

As you can see, I had three types of calculators, hence at least three Kata to practice, but as usual with beginners, it took us the whole tutorial to get done with the first one.

The room was a class room that we set up as our coding dojo with the coder and his copilot working on a laptop, facing the rest of the participants, with the large screen at their back. The pair-programmers could freely discuss with the people facing them, who were following the typing on the large screen.

We switched every ten minutes: the copilot became coder, the coder went back to his seat in the class and someone else stood up to became the copilot.

The session was allocated 3 hours split over two slots of 1h30. It took me less than 10 minutes to open the session with the above slide, 10 minutes as first coder and 10 minutes to close it. Over a time span of 3 hours, that left 150 minutes for coding, hence 15 people. Luckily, the whole group was about that size and almost everyone got a chance to type.

I completely skipped explaining Python, its syntax and the unittest framework and we jumped right into writing our first tests with if and print statements. Since they knew about other programming languages, they picked up the Python langage on the way.

After more than an hour of slowly discovering Python and TDD, someone in the room realized they had been focusing more on handling exception cases and failures than implementing the parsing and computation of the formulas because the specifications where not clearly understood. He then asked me the right question by trying to define Reverse Polish Notation in one sentence and checking that he got it right.

Different algorithms to parse and compute RPN formulas where devised at the blackboard over the pause while part of the group went for a coffee break.

The implementation took about another hour to get right, with me making sure they would not wander too far from the actual goal. Once the stack-based solution was found and implemented, I asked them to delete the files, switch coder and start again. They had forgotten about the Kata definition and were surprised, but quickly enjoyed it when they realized that progress was much faster on the second attempt.

Since it is always better to show that you can walk the talk, I closed the session by praticing the RPN calculator kata myself in a bit less than 10 minutes. The order in which to write the tests is the tricky part, because it can easily appear far-fetched for such a small problem when you already know an algorithm that solves it.

Here it is:

import operator

OPERATORS = {'+': operator.add,
             '*': operator.mul,
             '/': operator.div,
             '-': operator.sub,
             }

def compute(args):
    items = args.split()
    stack = []
    for item in items:
        if item in OPERATORS:
            b,a = stack.pop(), stack.pop()
            stack.append(OPERATORS[item](a,b))
        else:
            stack.append(int(item))
    return stack[0]

with the accompanying tests:

import unittest
from npi import compute

class TestTC(unittest.TestCase):

    def test_unit(self):
        self.assertEqual(compute('1'), 1)

    def test_dual(self):
        self.assertEqual(compute('1 2 +'), 3)

    def test_tri(self):
        self.assertEqual(compute('1 2 3 + +'), 6)
        self.assertEqual(compute('1 2 + 3 +'), 6)

    def test_precedence(self):
        self.assertEqual(compute('1 2 + 3 *'), 9)
        self.assertEqual(compute('1 2 * 3 +'), 5)

    def test_zerodiv(self):
        self.assertRaises(ZeroDivisionError, compute, '10 0 /')

unittest.main()

Apparently, it did not go too bad, for I had positive comments at the end from people that enjoyed discovering in a single session Python, Test Driven Development and the Dojo mode of learning.

I had fun doing this tutorial and thank the organizators for this conference!

At OBHM 2013, the 19th Annual Meeting of the Organization for Human Brain Mapping, Logilab presented a poster which explains the work done using CubicWeb on brain imaging and genetics data in collaboration with INRIA, INSERM and the CEA during the Brainomics project co-financed by Agence nationale de la Rercherche.

You can download this poster and try the demo online.