Scikit-learn organise son deuxième sprint international à Paris ! Rejoignez les développeurs pour une bière bien fraîche dans le quartier de la Butte aux cailles.
Le jeudi 25 Juillet, à partir de 19h30.
Au Sputnik, 14-16, rue de la butte aux cailles. Pour s’y rendre:
- en métro : ligne 5 (place d’italie) ou 6 (corvisart)
- en bus : ligne 57, 67 arrêt Verlaine,
- en Vélib’ : Station Vélib’ Avenue Casanova
Scikit-learn organise son deuxième sprint international à Paris ! Rejoignez les développeurs pour une bière bien fraîche dans le quartier de la Butte aux cailles.
Le jeudi 25 Juillet, à partir de 19h30.
Au Sputnik, 14-16, rue de la butte aux cailles. Pour s’y rendre:
- en métro : ligne 5 (place d’italie) ou 6 (corvisart)
- en bus : ligne 57, 67 arrêt Verlaine,
- en Vélib’ : Station Vélib’ Avenue Casanova
The side affect of owning your owning content and controlling what you do with it, is that it become much more shareable. You don’t have to have a Facebook or Google+ account to read this post. It is freely shared and anyone can read it. I can archive it and access it 20 years from now, because it is a portable format (at least it will be when I am done).
Declaration of Content Independence, James King
J'ai récemment arrêté de tweeter pendant 3 semaines, après avoir identifié Twitter comme étant le service en ligne dont j'étais le plus dépendant (et archivé mon historique). Rien de mieux pour découvrir à quel point cette addiction s'était développée au cours des années.
L'objectif initial était de ne publier aucun tweet et de ne lire ma timeline qu'une à deux fois par jour, ce à quoi je me suis à peu près tenu, j'ai juste signalé après une semaine que je testais Vole pour ceux qui voulaient tenter une expérience décentralisée à base de Bittorrent Sync. Quelques personnes ont suivi et on a réussi à avoir quelques échanges mais rapidement le soufflé s'est dégonflé et on s'est retrouvés en dialogue avec Nico ce qui limite un peu l'intérêt d'un réseau socia^W^soucieux.
La première journée a été très difficile : mon navigateur était plein de liens à échanger, ma timeline pleine de tweets auxquels réagir. J'ai envoyé quelques mails à certains pour répondre via un autre canal. La frustration était bien réelle, l'addiction aussi. Puis est arrivée la première conférence et j'avais vraiment envie de partager mon bonheur d'avoir réuni des personnes intéressantes dans un lieu paradisiaque. Puis sont arrivés les premières questions directement sur Twitter auxquelles je me suis empêché de répondre, après tout mon mail est suffisamment public pour pouvoir être joignable différemment (ce qui n'a pas été le cas).
Je n'avais jamais vraiment envisagé Twitter comme étant un mégaphone à mon égo. Et pourtant… je me suis rendu compte qu'il s'agissait avant tout de communiquer sur du positif et de l'auto-flatterie. Dur bilan. Mais c'était peut-être aussi l'objectif de cette prise de recul : observer ce qui avait vraiment de la valeur dans ce que je partageais et ce que je consultait. Fort de ce constat, je me suis remis à suivre moins de 100 personnes et je me limite dorénavant à 3 tweets par jour (excepté les discussions). Un besoin d'augmenter le rapport signal/bruit, en commençant par l'appliquer à mes propres publications.
Beaucoup de questions relatives à mon exil de Twitter par conviction — suite aux révélations sur PRISM etc — c'était surtout l'occasion de voir si d'autres solutions pouvaient être envisagées et la réponse est négative pour l'instant, que ce soit Vole, App.net ou Pump.io, aucun des réseaux n'atteint la masse critique permettant d'avoir la qualité des échanges que j'ai actuellement sur Twitter. Il y aurait bien la solution POSSE mais ça ne résout pas la distribution des discussions, leur agrégation et leur pérennité.
Le bilan de cette expérience est cruellement insatisfaisant. Si Twitter venait à disparaitre, tout un graphe de relations serait perdu (ou plutôt revendu au plus offrant) sans qu'il y ait d'alternative réelle, peut-être que je devrais davantage m'intéresser à la sauvegarde de ces relations plutôt qu'aux contenus sur ma page dédiée car c'est ce qui fait la réelle valeur de ce réseau social. Mais les identifiants étant définis au niveau de la plateforme et non du web, ceux-ci disparaitraient malheureusement aussi. Il est peut-être temps de jouer avec le champ URL de la bio Twitter :-).
tldr; I built a Ghetto blaster with a suit case. Click on the image below to see me dancing with it.
After my Raspberry Juke box project was done, I wanted to take it to the next level and build a standalone amplified speaker I could drive from the home wifi instead of putting $300 in a Bose Soundlink or a Jawbone JAMBOX and get limited features compared with what I can build with a Raspberry.
So I built a Ghetto blaster with a suit case.
Ghetto blasters are one of the coolest thing ever. It's the perfect device to enjoy music outside - and it's so 80s.. :)
I found an old suit case in my basement that used to contain tools. This kind of suit case is made with cardboard and covered with aluminum. Once emptied, it's perfect as a speaker. The cardboard and aluminum vibrate and produce excellent basses. This suitcase costs around 10 euros.
I also found 2 old car speakers in my basement, that are pretty good. 25W & 3 channels each. I suspect these would cost arount 20 euros these days.
Once the holes were made and the speakers screwed on the suitcase panel, I bought a small 25W amplifier on Amazon for 27 euros. This thing is really amazing. It's small enough to fit in the suitcase and has a small equalizer that is really handy. I unscrewed the front panel and placed it outside on the suitcase, and screwed back through the suitcase to hold the amplifier inside.
I started to play with my suitcase and got amazed by the sound, it really kicks and has very good basses.
The next steps were to plug a Raspberry-Pi with an USB sound card and a wifi dongle and run Mopidy on it. That allowed me to stream music from my Spotify account.
When the Raspberry starts, it starts Mopidy, connects to the home Wifi and speaks out using espeak:
"I am ready to play music, my IP address is 192.168.0.16"
From there I can start a MPD client like MPDroid and connect to that IP and queue some music.
Of course the big challenge was to power up the amplifier & the Raspberry so I could actually walk around freely. I did not want to use lead acid, so I bought this 12v lipo battery for $20. It comes pre-charged and has a small on/off button.
Now this battery delivers 12v but I still need 5v for my Raspberry. You can use a voltage regulator for this, like the LM1117.
I built a small board you can see in the video. It takes the 12v from the battery and outputs 5v for the Raspberry. It has the LM1117 with a sink, and a few capacitors for stability.
It's exactly the same design as this one https://www.youtube.com/watch?v=CKS6zHo5T9k except they use a L7805 in there - which has a different wiring.
That's it - my 12v LiPO powers up the amplifier & the Raspberry. It's been playing for hours and the battery still has some juice.
The wifi dongle loses the signal if I close the suitcase and I am too far from the wifi router. I need to set up an external antenna.
I am also going to add a battery level indicator, using this schematic
One issue I have yet to solve is the ability to reconfigure the network setup in case I use the Ghetto blaster in someone else's house. Right now I have to plug a screen and a keyboard or to plug a network cable and ssh on the Raspberry to change the network config.
Maybe one way to solve this would be to have a second wifi dongle set as an access point, and a small web interface to configure the network.
Raspberry-Pis are so fun.
Circus is a process & socket manager. It can be used to monitor and control processes and sockets.
At Novapost, we usually launch processes on different (virtual) machines, so we wanted Circus to manage processes launched on different servers.
Today we are using circus in production and one nice feature is to be able to monitor all processes and sockets dispatched around our servers from one interface.
Circus is an Open Source project started by Tarek Ziadé and Alexis Metaireau from the Mozilla Services team.
It appears that after one year of development, Mozilla is now looking forward to use Circus internally to manage their service infrastructure.
As a matter of fact we, at Novapost, are also planning to replace our supervisord based infrastructure with circus.
Novapost is organizing a Sprint on Circus for two days in Paris.
From July the 8th to July the 9th 2013.
Pizza and Drinks will be provided.
You are welcome to help us, please register here : http://www.doodle.com/s856fqh4mht32nw6
Je travaille pour Mozilla depuis une semaine — sur la partie paiement du Marketplace — pour le compte de scopyleft. Il s'agit d'intégrer une équipe qui bosse sur le projet depuis plusieurs années, l'occasion de découvrir de nouveaux outils, de nouvelles pratiques, de nouvelles conventions et de nouvelles personnes. Quelques conseil mis en pratique pour débuter :
Quelques regrets quand même :
Bon et sinon c'est cool de bosser sur un projet utile !
Un Afpyro aura lieu le mercredi 31 juin à partir de 20h au Tooley’s - 7 quai Fulchiron - Lyon 5éme (probablement sur la terrasse côté rue Monseigneur Lavarenne).
Aucune présentation n’est prévue, mais nous pourrons nous désaltérer (sic!) en maudissant la chaleur et les alertes pollutions.
C'est évident comme un grain de sable: plus que la ville ou le pays, c'est moi qui ai changé. Mes goûts, mes envies, mon rythme et mes petites misères.
Mais l'affection est sincère, sans cette maladresse des sentiments digne de réunions d'anciens élèves. Oui, ceux qui n'ont rien d'autre à se dire, rien en commun que quelques blagues surannées et des souvenirs en conserve.
Cette histoire s'écrit au présent.
Je reviendrai.
Tokyo, Juin 2013: Voyage Sentimental, Olivier Thereaux
Je suis revenu du Japon il y a maintenant un an. Et je sens bien que le petit bout de Japon qui était revenu avec moi, en moi, s'amenuise irrémédiablement, se transforme, perd de son authenticité. Les souvenirs s'idéalisent, les relations s'estompent et les sensations vécues ont du mal à être rejouées — même avec des photos. Il manque les sons, les odeurs, les interactions, les non-interactions aussi. Il manque la fraîcheur, la naïveté, les rires et la bienveillance. Il manque Tokyo.
Au loin l'appel d'un quotidien perdu. D'un exotisme non-touristique. D'une vie différente.
Je repartirai.
Last Friday, we hosted the French event for the international Great Salt Sprint. Here is a report on what was done and discussed on this occasion.
We started off by discussing various points that were of interest to the participants :
We then split up into pairs to tackle issues in small groups, with some general discussions from time to time.
6 people participated, 5 from Logilab, 1 from nbs-system. We were expecting more participants but some couldn't make it at the last minute, or though the sprint was taking place at some other time.
Unfortunately we had a major electricity black out all afternoon, some of us switched to battery and 3G tethering to carry on, but that couldn't last all afternoon. We ended up talking about design and use cases. ERDF (French electricity distribution company) ended up bringing generator trucks for the neighborhood !
Some unfinished draft code for supervision backends was written and pushed on github. We explored how a common "interface" could be done in salt (using a combination of states and __virtual___). The official documentation was often very useful, reading code was also always a good resource (and the code is really readable).
While we were fixing stuff because of the power black out, Benoit submitted a bug fix.
The idea is to couple the SLS description and the current state of the salt master to generate documentation about one's infrastructure using Sphinx. This was transmitted to the mailing-list.
Design was done around which information should be extracted and display and how to configure access control to the salt-master, taking a further look to external_auth and salt-api will probably be the way forward.
We had general discussions around concepts of access control to a salt master, on how to define this access. One of the things we believe to be missing (but haven't checked thoroughly) is the ability to separate the "read-only" operations to the "read-write" operations in states and modules, if this was done (through decorators?) we could easily tell salt-api to only give access to data collection. Complex scenarios of access were discussed. Having a configuration or external_auth based on ssh public keys (similar to mercurial-server would be nice, and would provide a "limited" shell to a mercurial server.
The power black out didn't help us get things done, but nevertheless, some sharing was done around our uses cases around SaltStack and features that we'd want to get out of it (or from third party applications). We hope to convert all the discussions into bug reports or further discussion on the mailing-lists and (obviously) into code and pull-requests. Check out the scoreboard for an overview of how the other cities contributed.
to comment this post you need to login or create an account
The 14th Debian developers conference (DebConf13) will take place between August 11th and August 18th in Vaumarcus, Switzerland.
Logilab is a DebConf13 sponsor, and I'll attend the conference. There are quite a lot of cloud-related events on the schedule this year, plus the usual impromptu discussions and hallway track. Looking forward to meeting the usual suspects there!
We're currently focusing on Loads with Alexis and I have just released the first version at PyPI.
It's a distributed load testing tool.
It's still at a very early stage but I think it's worth releasing it to share it with people that might be interested in doing heavy distributed load testing.
From a user's perspective, the key concepts of Loads are:
If you want to give it a shot, install it , then follow the guide here: http://loads.readthedocs.org/en/latest/guide and let us know what you think.
Beware that it's an early prototype, probably still full of bugs.
From a design point of view, this is how Loads is organized when you run a load test across several servers:
Loads uses a ZeroMQ Broker that drives several Agents to run tests. Tests results are sent in real time into a publisher.
In detail:
Right now, we've deployed Loads on AWS on several boxes, and started to use it to load test a few of our applications we're currently building at Mozilla Services.
The long term goal is to offer a load testing service to our team, so anyone can send huge loads on a staging or dev application with a simple command line call.
I hope that we will have something that works well by the end of the summer and be useful to more people than our own team.
If you're interested, please join the fun at https://github.com/mozilla-services/loads
