Supprimer les notes, c’est assurément une façon de se recentrer sur l’apprentissage ; c’est arrêter de chiffrer quelque chose qui n’est pas chiffrable. Mais, arrêter la note ne veut pas dire arrêter d’évaluer, car, bien évidemment, l’étudiant a besoin de repères, de savoir où il en est. Quand il n’y arrive pas, il le sait : il n’a pas besoin de recevoir une mauvaise note. Il faut trouver comment stimuler son envie de continuer à apprendre, alors que la mauvaise note, en général, lui donne envie de ne plus essayer. La note, pour les bons élèves, sert de carotte : elle est intéressante en terme d’émulation. Mais il faut trouver une autre façon de stimuler l’apprentissage : en disant à la personne que ce qu’elle fait est bien, qu’elle peut être fière d’elle. Si l’enthousiasme est réveillé, elle aura envie de continuer à apprendre.
Je suis contre le système de notation actuel. Mais il faut pourtant que j’attribue une note à chaque élève. Alors je vais essayer de transformer cela en auto-évaluation. À partir d’un exercice imposé sur une heure, seuls (mais connectés) face à la page blanche, essayer de produire quelque chose à partir des concepts que j’ai essayé de leur transmettre. Au final l’évaluation sera davantage intéressante pour moi. Qu’ont-ils retenu de ces 24 heures passées ensemble ? Un peu, beaucoup, rien du tout ?
Le débriefing/correction sera l’occasion de faire un bilan de ce que l’on a abordé ensemble. D’analyser ce qu’il manque à ce cours pour être plus pertinent et plus engageant. De vérifier qu’il a répondu à leurs craintes initiales. Mon bilan personnel est assez mitigé :
Malgré ces retenues, le bilan est globalement positif et j’espère pouvoir participer par la suite plus en amont pour orienter le programme afin qu’il réponde un peu mieux aux enjeux et pratiques du métier.
C’est en observant nos deux apprentis tantôt réussir, tantôt échouer, que je fus soudain prise d’empathie. J’ai repensé à mes propres débuts.
J’ai alors eu envie de les aider. Au quotidien, j’essaie de les aider du mieux que je peux, bien que cette aide ne soit pas toujours facile à caser dans un rythme de production soutenu.
C’est pourquoi je publie ici les 24 conseils que j’aurais voulu qu’on me donne aussi quand j’ai débuté, afin que cela puisse servir à d’autres débutants… quitte à prendre moi-même un petit coup de vieux !
24 conseils que j’aurais voulu que l’on me donne quand j’ai débuté
Quelques conseils que j’aimerais leur donner pour la suite :
Un Afpyro aura lieu le mardi 16 décembre à partir de 20h à l’Antre Autre - 11 rue Terme - 69001 Lyon.
Une présentation sur Sentry sera donnée. Sentry est un logiciel permettant de suivre les erreurs pouvant se produire dans vos applications.
L’Antre Autre est un lieu où nous pouvons discuter autour d’un verre, et, pour ceux qui le souhaitent, prendre un repas.
Pour se rendre à l’Antre Autre :
Autre exemple : observez Lean startup, une approche extrêmement puissante pour construire rapidement un produit/service en itérant directement avec ses utilisateurs. Si vous deviez construire un quartier en mode Lean, vous commenceriez par construire rapidement des logements répondant aux besoins minimum exprimés par les utilisateurs : un sol, des murs, un toit et une porte pour assurer le clos et le couvert du logement. La condition minimum de l’habitat est respectée. Par contre si vous produisez ça à l’échelle du quartier vous avez construit une favela.
En voulant répondre rapidement au besoin minimum de l’utilisateur vous avez livré un produit qui générera rapidement des problèmes de salubrité, de promiscuité, et de violence. Finalement vous avez bien suivi la méthode mais la qualité de vie (ou l’expérience utilisateur) n’est pas satisfaisante.
Dans cet exemple la production s’est attachée à répondre aux besoins conscients de l’utilisateur. Les besoins futurs, non-conscients et non-exprimés, comme une bonne qualité de vie, la sécurité ou la salubrité, n’ont pas été pris en considération. Ils conditionnent pourtant largement la qualité de l’expérience utilisateur.
En Lean comme ailleurs l’expert est aussi là pour, si j’ose dire, préserver l’utilisateur de lui-même. Si l’utilisateur est conscient de ses besoins présents, est-il conscient des conséquences futures de ces choix ? On peut en douter…
Non, la conception centrée utilisateur doit être encadrée par des ressources responsables de la vision du projet. Il faut des visionnaires, il faut des innovateurs, des planificateurs. Il faut des garants de la qualité du produit/service pas seulement pour l’usage présent, mais aussi pour les usages futurs.
Il y a 2 choses qui me gênent dans cet extrait :
Si je reprends l’exemple de l’habitat, la première itération débouchera en effet peut-être sur une cabane. Puis la seconde, une fois que des personnes y auront vécu, débouchera sur un groupe de cabanes avec une pièce commune et des sanitaires externes. Puis la troisième pourrait être à l’origine d’un renforcement des murs existants et la construction d’une école. Enfin lors de la quatrième on démolirait la pièce commune pour faire une salle des fêtes en béton. Ou tout autre chose en fonction des besoins des personnes qui sont concernées au quotidien. Lean n’est pas fait pour développer un prototype et passer à l’échelle à partir de celui-ci mais bien pour itérer sur ce prototype de manière à ce qu’il acquiert le maximum de valeur avant de passer à l’échelle. Si personne ne souhaite vivre dans une favela, un projet Lean ne devrait jamais aboutir à une favela (au passage comparer une n-ième fois le développement logiciel à du BTP est délirant).
Passons à l’encadrement des utilisateurs trop stupides pour pouvoir avoir une vision de leur produit. Dans un système complexe, l’expert et l’utilisateur sont sur un pied d’égalité vis-à-vis de la prédiction qu’ils peuvent faire sur un produit innovant : c’est entre la voyance et le bullshit. Personne ne peut anticiper dans un tel système. La chance de notre domaine c’est la flexibilité que l’on a pour pouvoir s’adapter au changement. L’agilité propose des outils pour que les compétences de l’expert (estimation relative de la complexité et qualité interne) et l’utilisateur (priorité et budget) puissent travailler ensemble afin de maximiser la valeur de chaque itération. Inutile d’anticiper (faussement) sur les usages futurs si l’on est suffisamment réactif dans les développements présents. L’enjeu est de rester suffisamment réactif tout au long du processus, à la fois techniquement mais aussi en terme de retours utilisateurs.
Je fais rarement de la pub par ici mais la formation qu’expérimente Stéphane dans le domaine est vraiment éclairante.
Logilab était présent à EuroSciPy2014 à Cambridge la semaine dernière, à la fois pour suivre les travaux de la communauté scientifique, et pour y présenter deux posters.
Il y a encore beaucoup été question de performances, au travers de tutoriels et de conférences de grande qualité :
D'autres sujets que je vous laisse découvrir plus en détails sur le site d'EuroSciPy2014 prouvent que la communauté européenne du Python scientifique est dynamique. Parmi eux :
Logilab a eu l'opportunité de prendre part au projet de recherche PAFI (Plateforme d'Aide à la Facture Instrumentale), en développant une application WEB innovante, basée sur CubicWeb, visant à la fois à faciliter le prototypage virtuel d'instruments (à vent pour le moment) et à permettre des échanges de données entre les acteurs de la recherche et les facteurs d'instrument, voire les musées qui possèdent des instruments anciens ou exceptionnels. La plateforme met ainsi en œuvre la Web Audio API et un modèle de collaboration élaboré.
Licence : Creative Commons BY-SA
L'autre poster présenté par Logilab concerne Simulagora, un service en ligne de simulation numérique collaborative, qui permet de lancer des calculs dans les nuages (donc sans investissement dans du matériel ou d'administration système), qui met l'accent sur la traçabilité et la reproductibilité des calculs, ainsi que sur le travail collaboratif (partage de logiciel, de données et d'études numériques complètes).
Licence : Creative Commons BY-SA
Un grand merci à l'équipe d'organisation de l'événement, qui a encore remporté un joli succès cette année.
La communauté Salt s'est a nouveau réunie pour son meetup bi-mestriel autour de trois présentations. Voici un compte rendu (très court) pour vous renvoyer vers les références.
Aurélien Minet de l'ENS Cachan nous a présenté son utilisation de salt dans la gestion de postes utilisateurs OS X et Windows.
OS X:
Windows:
- salt.modules.win_*
- salt.modules.chocolatey
- salt.modules.reg
- pour chocolatey, possibilité d'héberger un repo sous linux avec Simple Nuget
- Mise en commun d'installeurs windows sous forme de states sur salt-winrepo
Support de présentation à venir.
Arthur Lutz de Logilab nous a présenté un développement pour évaluer la distance entre l'état souhaité de son infrastructure salt et l'état réel.
Merci à tinyclues d'avoir acceuilli et apporté à boire, ainsi qu'à Logilab pour les pizzas.
Pour le prochain meetup (en janvier), votez pour une date sur framadate et n'hésitez pas à inscrire une proposition de présentation ou de lieu sur le pad d'organisation.
J'ai récemment écrit un petit guide sur le tracking de bulles dans une mousse. A défaut de temps, voici donc un billet court plutôt que rien afin de référencer cette contribution. J'ai utilisé la bibliothèque Trackpy écrite en Python afin de tracker les bulles. Cependant, une étape supplémentaire d'identification a été nécessaire (car en dehors des clous des particules plus classiques) et j'ai utilisé scikit-image.
Le tuto a ainsi pour ambition de montrer la versatilité de trackpy pour des objets moins conventionnels. Il est disponible ici.
As presented at the November french meetup of saltstack users, we've published code to generate some statistics about a salstack infrastructure. We're using it, for the moment, to identify which parts of our infrastructure need attention. One of the tools we're using to monitor this distance is munin.
You can grab the code at bitbucket salt-highstate-stats, fork it, post issues, discuss it on the mailing lists.
If you're french speaking, you can also read the slides of the above presentation (mirrored on slideshare).
Hope you find it useful.
Un meetup tardif, dû à la PyConFr, centré sur deux présentations opposées en termes de technicité : une présentation d’un outil (presque) clés-en-mains, et un survol des possibilités de iPython dans la dataviz cartographique, ainsi que quelques bibliothèques utiles.
Intervenant : Damien Nicolas, Gordon
Pelican est un générateur de site statique écrit en Python initialement par Alexis Métaireau.
Le site est réalisé via un langage de template ensuite traduit en HTML. Le contenu généré peut ensuite être déployé sur un serveur sans configuration supplémentaire. Il n’y a donc pas d’applicatif sur le serveur.
Les avantages d’un tel système sont nombreux. D’abord la simplicité. Un simple éditeur de texte suffit pour écrire le contenu. Étant purement textuel, le contenu est facilement versionnable et recevoir/fournir un patch peut se résumer à un envoi de mail. L'absence d’applicatif côté serveur rend la configuration serveur aisée et la sécurité proche de la perfection : pas d’applicatif = pas de faille.
Bon évidemment, il y a quelques inconvénients. En terme de fonctionnalité d’abord, l’absence native de recherche ou de commentaire. Mais heureusement, il est possible via des extensions de remédier à ces problèmes. En revanche, la barrière à l’entrée est immuable. Pour faire du Pelican, il faut pouvoir écrire du RestructuredText ou du Markdown. Pour profiter pleinement de tout ça, il est bon de savoir invoquer une commande “make” ou “git push”. Plus que rébarbatif pour un néophyte.
L’installation se fait comme n’importe quelle bibliothèque Python. On crée un environnement virtuel (e.g. via pyvenv en Python 3). On l’active et via pip on peut installer Pelican. A noter que par défaut, Pelican supporte uniquement le RestructuredText pour les articles, pour markdown, il faudra installer le paquet markdown en plus. On peut ensuite préparer le site via l'installer de Pelican, qui de façon interactive pose quelques questions qui facilitent grandement la configuration. A cette étape, on paramètre notamment les différents moyens utiliser pour déployer le site web sur le serveur.
Une fois configuré, on peut écrire des articles. Ces derniers pourront être placés dans un dossier articles dans le dossier content (tout ceci est paramétrable). Pour générer le site, le plus simple est d'utiliser la commande make :
make html
Et on déploie :
make upload
Et la magie opère. Le site est redéployé !
Il est assez facile de tester localement, Pelican permet d’utiliser un simple serveur HTTP en local pour vérifier ses modifications avant de publier des erreurs ;).
On l’a écrit, nativement, il n’existe pas de gestion des commentaires ni de fonction de recherche. Rien d’insurmontable cependant.
Pour les commentaires, une solution simple est d’intégrer Disqus. Disqus est un service permettant de stoquer des commentaires sur un autre serveur que celui de l’application. L’extension disqus_static permet d’utiliser l’API de ce service pour gérer les commentaires dans Pelican. Il y a d’autres alternatives, comme par exemple gérer des commentaires statiquement dans des fichiers sur le serveur hébergeant Pelican. Cette dernière solution permet d’éviter les dépendances à un service tiers.
Ici, on pourra fait appel à tipue_search, qui permet d’intégrer une fonctionnalité de recherche côté client. Sur le serveur, un fichier JSON est généré. Celui-ci est ensuite utilisé côté client pour de la recherche via JQuery. Le thème elegant intègre cette fonctionnalité nativement.
Très extensible, il est possible de faire tout un tas de choses avec Pelican. C’est d’ailleurs le moteur utilisé pour le blog que vous lisez en ce moment. Pour vous faire une idée des possibilités, c’est par là : <https://github.com/Python-Nairobi/pelican-plugins>`_.
Les slides de la présentation sont disponibles ici : Pelican
Intervenant : Thomas Gratier
IPython est un shell Python interactif offrant autocomplétion et historique des commandes. Il peut également s’utiliser sous forme de notebook dans un navigateur. De nombreuses bibliothèques sont disponibles et peuvent être chargées dynamiquement. Ainsi, il est très aisé de préparer des présentations dynamiques avec démonstration Python en temps réel et image générée directement dans un navigateur. IPython permet aussi de déployer les notebooks sur un site web. C’est donc un outil très puissant à la fois pour expérimenter avec Python mais aussi pour préparer des présentations interactives.
Pas plus de mots, lors du meetup, nous avons pu voir des résultats assez chouettes que vous invités à expérimenter par vous-même ici : Dataviz avec iPython.
Merci à tous pour votre présence et à très bientôt :) !
Ce mardi 23 décembre, nous proposons au pythonistas de Nantes de se retrouver pour prendre un verre.
Le rendez-vous est à 19h au Delirium Tremens, 19 allée Baco à Nantes.
Certains seront absents, le système de distribution du Père Noël semble-t'il repose sur Python (ce qui explique peut-être qu'il dépasse celui d'Amazon écrit en Perl !).
Joyeuses fêtes !
The Logilab team holds a roadmap meeting every two months to plan its CubicWeb development effort. The previous roadmap meeting was in July 2014.
Here is the report about the September 4th, 2014 meeting. Christophe de Vienne (Unlish) and Dimitri Papadopoulos (CEA) joined us to express their concerns and discuss the future of CubicWeb.
This version is stable but old and maintainance will continue only as long as some customers will be willing to pay for it (current is 3.17.16 with 3.17.17 in development).
This version is stable and maintained (current is 3.18.5 with 3.18.6 in development).
This version is stable and maintained (current is 3.19.3 with 3.19.4 in development).
This version is under development. It will try to reduce as much as possible the stock of patches in the state "reviewed", "awaiting review" and "in progress". If you have had something in the works that has not been accepted yet, please ready it for 3.20 and get it merged.
It should still include the work done for CWEP-002 (computed attributes and relations).
For details read list of tickets for CubicWeb 3.20.0.
Removal of the dbapi, merging of Connection and ClientConnection, CWEP-003 (adding a FROM clause to RQL).
When the work done for Pyramid will have been tested, it will become the default runner and a lot of things will be dropped: twisted, dead code, ui and core code that would be better cast into cubes, etc.
This version could happen early in 2015.
Here is the status of open CubicWeb Evolution Proposals:
CWEP-0002 full-featured implementation, to be merged in 3.20
CWEP-0003 patches sent to the review. . Champion will be adim.
Christophe will try to present at PyConFR the work he did on getting CubicWeb to work with Pyramid.
Logilab and Christophe will try to make CubicWeb more pip/virtualenv-friendly. This may involve changing the source layout to include a sub-directory, but the impact on existing devs is expected to be too much and could be delayed to CubicWeb 4.0.
Christophe has made good progress on getting CubicWeb to work with Pyramid and he intends to put it into production real soon now. There is a Pyramid extension named pyramid_cubicweb and a CubicWeb cube named cubicweb-pyramid. Both work with CubicWeb 3.19. Christophe demonstrated using the debug toolbar, authenticating users with Authomatic and starting multiple workers with uWSGI.
Early adopters are now invited to jump in and help harden the code!
Logilab's next roadmap meeting will be held at the beginning of november 2014 and Christophe and Dimitri were invited.
Question sobriété heureuse, nous sommes bien loin du minimalisme. Le Père Noël, tel que je le vois présenté à la télé ou dans les magazines ne met pas l’accent sur les cadeaux expérience. Il ne prône que le matérialisme. Nous nous efforçons d’expliquer et de montrer à Petit Lutin que les biens matériels ne sont pas ce qui rend heureux. Nous cherchons à partager du temps de qualité avec lui. Désolée Père Noël, mais tu es actuellement incompatible avec ma vision de la sobriété heureuse !
Moi, Petit Lutin, 3 ans et demi, je n’ai jamais cru au Père Noël
Il y a énormément de raisons pour ne pas avoir envie de faire croire au Père Noël à son enfant : mercatique, religieuse, culpabilité, mensonge, hypocrisie, société de consommation, etc. Celle qui me tient à cœur est plus positive, je trouve dommage que l’on mystifie un moment de convivialité et de partage. Pourquoi vouloir cacher le fait que des personnes proches nous aiment au point de nous faire des cadeaux et de passer un bon moment avec nous ? Elle est là la magie de noël, se retrouver ensemble. Faire don de son temps, de son enthousiasme et parfois d’une petite attention personnelle en plus.
Note
Most running applications out there are good enough for casual runners. This blog post is my tentative to describe what I would like to see in a running app for more serious practice.
I used a few running applications to track all my runs. Mostly the Nike+ app since this what naturally came with my Nike+ watch before I switched to a Garmin Forerunner 310XT.
From Nike+ to Garmin...
The app was a bit frustrating for many reasons and I thought that was because it's made for beginners, and that I was not the typical user anymore. I was not really interested in the provided metrics and was looking for better things.
When I switched to my new watch I though the app would be as good as the hardware. But no. What came as a surprise is that all the applications I have tried or looked at are not really better than Nike+. It looks like they are all aiming at casual runners.
But when you buy a expensive watch and do 5 trainings per week, you have some expectations.
I still wonder how come we don't have something better in a domain where anyone can understand the basics of what a good training session should be, by reading 2 or 3 running magazines. Unless you are doing crazy elite training with a whole staff, it's not rocket science.
And in my running club, even the very experienced runners use one of these apps and get frustrated. But it seems that no one expects these apps to be better than they are right now. The general consensus around me is: you can analyze your runs manually, the watch and its software will just help you get the raw data.
This is not good enough for me. I am very frustrated. I want to see if I am making any progress by using months of data - and this is not easy to do by hand.
SmashRun looks like a promising app but still misses a lot of what I am looking for. Since it's built by runners who seem passionate about building the right stuff, I got a pro account to encourage them. They have a voting system for new features, people that have a pro account can use.
However, I would like to write down in this blog post what I am exactly looking for and what I despise in a running app.
Of course this is what I want - but I am pretty sure that most seasoned runners would want something similar. Maybe it exists ? You should let me know.
I think this is the worst feature all running apps have: they will tell you your average pace and your "progression". Some of them try to take a coach-like tone and tell you stuff like:
You're getting slow!
Jeez. Of course I am getting slow. I ran an interval run yesterday with a specific pace of 3'40/km and today I am doing a long run at a very slow pace because this is how you train !
Yeah the pace varies during the week. Nothing I can do with this chart here.
Global metrics that use all your recorded runs have no sense
You can't do this. That does not mean anything. Knowing that my yearly average pace is 4'45 does not mean anything.
You can't either really know what will be my estimate finish on a 5k using one of my long runs.
My estimated 5k finish time based on one long run. Of course it's completely wrong.
Also, the volume of trainings and kilometers you do really depends on what you're aiming at. Someone that is getting ready for a marathon will do at least 60km/week, and will take it easy the last week.
That would be a non-sense if you are getting ready for a 5k - But in most apps, the runner that prepares for the marathon will appear like a killer compared to the 5k runner. Tell this to the runners that are doing 16' on a 5k...
I will soon lose my Gold medal since my 5 weeks training plan is over.
Anyways. My point is that the software should be smarter there. Every run needs to be classified in very specific groups to have any useful metrics on it. The most important ones are:
A long run is basically running at a lower pace for a longer time than usual. If you are getting ready for a 10k, you usually have one or two long runs per week, that will last for 1h to 1h30 tops.
The goal of those runs is to try to keep the same steady heart rate, and usually if the place where you are running is flat enough, the same pace.
A long run look like this:
The red zone is the HR drift.
There are several interesting things in this chart: you don't usually warmup when you do long runs. So the first portion of the run is a slow raise of your pace and heart rate until you've reached the targeted zone.
The quality of a long run is your ability to stick with the same heart rate for the whole session. Unless you are very careful and slow down a bit over time, there will be a slow, natural increase of your heart reate over time.
The most interesting metric in the case of a long run is to determine how flat your HR is, excluding the warmup section at the beginning.
A possible variation is to add a few strikes in the middle of your long runs. It makes it less boring. For example 2x2mn at 10k speed. It's important that these two strikes don't confuse the software that measures how flat your HR is.
Comparing long runs can be done by looking at;
If I do a short interval run, this is how things will go:
The red line is the linear regression of the fast strikes.
We can ditch the warmup. It does not bring any interesting data besides the volume of training. The only interesting thing to do there is to make sure it was long enough. That varies between runners, but for short intervals, it's usually roughly as long as the intervals themselves.
Now for the intervals, a quality metrics is to check if they are all done at the same speed. It's quite common to start the series very fast and to finish slowly, completely burnt by the first strikes. This is not good! A good interval run is done at the same speed for all strikes (both fast and slow segments). A great interval run is done with a slightly faster speed for the last intervals.
A good metrics in this case is the linear regression of the pace for the fast segments then the slow segments. It should be flat or slightly increasing.
The ten last minutes are also very intesting: how fast your heart rate decreases over the ten minutes ? The faster the better.
Comparing interval runs between them can be done by checking how these metrics progress over time.
Long interval runs are like the short ones. The only difference is that you can take into account your HR variation between strikes to see how good you are at decreasing your HR between each strike. A linear regression can be added there.
A Race is a very specific run, and has its specific metrics. Usually, we tend to start too fast with the danger of getting in the red zone in the first kilometers.
This is the perfect 10k run:
A 10K run with a perfect negative split.
The first 5-6k are down 3-5 seconds slower than your target pace, and the end of the run 3-5 seconds faster. This is called a negative split. The last 500m should be as fast as you can.
So for races, what I want to find out is if I was able to do a negative split, if I did not start too fast and if I was able to sprint to the finish line.
This is also a set of metrics that can be compared from race to race over time.
I have a friend at the racing club that trained hard for 8 weeks for a marathon. He was aiming at 3h15mn and practiced accordingly. The day the race was there, we had a very unusual heat wave in France - 37ºC which is a lot for my area. He finished the marathon in 3h40 and was happy about his performance!
The bottom line is that the heat or the cold directly impact how we perform - and this varies a lot between individuals. In my dream running app, I want to correlate my results with the temperature.
I want all my predictions to have a ponderation (not sure that's how you say it in english ;)) with the temperature.
How long did you rest since the last run ? How did it impact your performances ?
With this information and how fast your heart slows down after your training, we can detect overtraining and undertraining.
I know Polar has a bit of this in its latest software. It tells you how long you should rest before your next run. I wonder how they calculate this.
Last year I ran in San Franscisco near the bay bridge with my Nike+ watch and when I uploaded my run I was delighted to see that I did a 1 mile segment many people did.
Unfortunately, the only thing the app was able to tell me is that I was 365th in terms of pace and another ridiculous rank in terms of how many runs I did there.
This is so stupid. Where am I getting with this ? Becoming the Running Mayor of the Pier? :)
There's one thing that could be interesting in running apps when comparing your data with other people: group users by ages and by records.
I am 37 and my 10k record is around 38' - I don't really care to know how I perform on a weekly basis compared to an elite runner who does 31', or a more casual runner who does 50'.
What could be interesting though is to compare with people that are at my level or age and that are getting ready for the same race maybe ? or a race that's similar enough and close enough.
This blog post is just a brain dump - some ideas are pretty vague and I have not really talked about the UX of the Running Software.
But the bottom line is that if you don't just jog, and want to use a running application for serious training, what I have described is what I think is needed.
I hope Smashrun will go into that direction!
The Logilab team holds a roadmap meeting every two months to plan its CubicWeb development effort. The previous roadmap meeting was in July 2014.
Here is the report about the September 4th, 2014 meeting. Christophe de Vienne (Unlish) and Dimitri Papadopoulos (CEA) joined us to express their concerns and discuss the future of CubicWeb.
This version is stable but old and maintainance will continue only as long as some customers will be willing to pay for it (current is 3.17.16 with 3.17.17 in development).
This version is stable and maintained (current is 3.18.5 with 3.18.6 in development).
This version is stable and maintained (current is 3.19.3 with 3.19.4 in development).
This version is under development. It will try to reduce as much as possible the stock of patches in the state "reviewed", "awaiting review" and "in progress". If you have had something in the works that has not been accepted yet, please ready it for 3.20 and get it merged.
It should still include the work done for CWEP-002 (computed attributes and relations).
For details read list of tickets for CubicWeb 3.20.0.
Removal of the dbapi, merging of Connection and ClientConnection, CWEP-003 (adding a FROM clause to RQL).
When the work done for Pyramid will have been tested, it will become the default runner and a lot of things will be dropped: twisted, dead code, ui and core code that would be better cast into cubes, etc.
This version could happen early in 2015.
Here is the status of open CubicWeb Evolution Proposals:
CWEP-0002 full-featured implementation, to be merged in 3.20
CWEP-0003 patches sent to the review. . Champion will be adim.
Christophe will try to present at PyConFR the work he did on getting CubicWeb to work with Pyramid.
Logilab and Christophe will try to make CubicWeb more pip/virtualenv-friendly. This may involve changing the source layout to include a sub-directory, but the impact on existing devs is expected to be too much and could be delayed to CubicWeb 4.0.
Christophe has made good progress on getting CubicWeb to work with Pyramid and he intends to put it into production real soon now. There is a Pyramid extension named pyramid_cubicweb and a CubicWeb cube named cubicweb-pyramid. Both work with CubicWeb 3.19. Christophe demonstrated using the debug toolbar, authenticating users with Authomatic and starting multiple workers with uWSGI.
Early adopters are now invited to jump in and help harden the code!
Logilab's next roadmap meeting will be held at the beginning of november 2014 and Christophe and Dimitri were invited.
But really the details of this are not that important. What I believe is really, really important is the ability to critically examine your job and projects and examine their worth.
What normally happens is that you get a group of people and tell them to work on project X. They will iterate through features and complete features. And repeat and keep going. And if you don’t stop at some point and critically examine what is going on, it will keep repeating. People will find new features, new enhancements, new areas to add to the project. Just as they have been trained to do so. And the project will keep growing.
That’s a perfectly normal thing for a team to do. It’s harder to call a project done, the features complete and realize that there might be an end.
Au final c’était vraiment une très bonne expérience car cela m’a permis de réaliser à quel point je n’étais pas fait pour travailler dans une entreprise de cette taille. J’ai pu expérimenter de nouvelles technologies et de nouvelles façons de collaborer. J’ai pu confirmer certains points sur la relation qu’ont les geeks au travail qui feront peut-être l’objet de futurs billets.
PS : je redeviens disponible pour de nouvelles aventures via scopyleft si vous voulez que l’on travaille ensemble, je suis toujours motivé par des projets utiles et citoyens ainsi que la transmission de mes savoirs.
The Logilab team holds a roadmap meeting every two months to plan its CubicWeb development effort. The previous roadmap meeting was in July 2014.
Here is the report about the September 4th, 2014 meeting. Christophe de Vienne (Unlish) and Dimitri Papadopoulos (CEA) joined us to express their concerns and discuss the future of CubicWeb.
This version is stable but old and maintainance will continue only as long as some customers will be willing to pay for it (current is 3.17.16 with 3.17.17 in development).
This version is stable and maintained (current is 3.18.5 with 3.18.6 in development).
This version is stable and maintained (current is 3.19.3 with 3.19.4 in development).
This version is under development. It will try to reduce as much as possible the stock of patches in the state "reviewed", "awaiting review" and "in progress". If you have had something in the works that has not been accepted yet, please ready it for 3.20 and get it merged.
It should still include the work done for CWEP-002 (computed attributes and relations).
For details read list of tickets for CubicWeb 3.20.0.
Removal of the dbapi, merging of Connection and ClientConnection, CWEP-003 (adding a FROM clause to RQL).
When the work done for Pyramid will have been tested, it will become the default runner and a lot of things will be dropped: twisted, dead code, ui and core code that would be better cast into cubes, etc.
This version could happen early in 2015.
Here is the status of open CubicWeb Evolution Proposals:
CWEP-0002 full-featured implementation, to be merged in 3.20
CWEP-0003 patches sent to the review. . Champion will be adim.
Christophe will try to present at PyConFR the work he did on getting CubicWeb to work with Pyramid.
Logilab and Christophe will try to make CubicWeb more pip/virtualenv-friendly. This may involve changing the source layout to include a sub-directory, but the impact on existing devs is expected to be too much and could be delayed to CubicWeb 4.0.
Christophe has made good progress on getting CubicWeb to work with Pyramid and he intends to put it into production real soon now. There is a Pyramid extension named pyramid_cubicweb and a CubicWeb cube named cubicweb-pyramid. Both work with CubicWeb 3.19. Christophe demonstrated using the debug toolbar, authenticating users with Authomatic and starting multiple workers with uWSGI.
Early adopters are now invited to jump in and help harden the code!
Logilab's next roadmap meeting will be held at the beginning of november 2014 and Christophe and Dimitri were invited.
J’inaugure une nouvelle forme de publication courte qui est destinée à remplacer mon usage de Twitter. L’idée est de continuer à partager des liens et des idées sans pour autant abreuver une machine publicitaire. Le format restera court et un seul article devrait être publié par jour. C’est expérimental.
