The concept of lens as bidirectional programs for transforming data.
From: Ron Jeffries <ronjeffries@XProgramming.com> Subject: Re: [XP] Incremental design material (was YAGNI Football Analogy) To: extremeprogramming@yahoogroups.com Date: Sun, 11 May 2008 11:44:04 -0400 X-Spam-Status: No, score=2.6 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_WHOIS,HTML_MESSAGE,HTML_TINY_FONT autolearn=no version=3.1.7-deb X-Mailer: The Bat! (v4.0.24) Home X-Sent: 2 days, 13 hours, 23 minutes, 17 seconds ago Reply-To: extremeprogramming@yahoogroups.com 1. (*) text/plain ( ) text/html Hello, Kim. On Sunday, May 11, 2008, at 9:56:23 AM, you wrote: > I guess I'm looking for practical advice on how to design for > evolution. I suppose /Refactoring/ has enough tips in it that it might > fit the bill... I'll read it again and see how it feels. I'd suggest two things: First, going back to the classic issues of good design, high cohesion and low coupling. Good design means changeable design, and these characteristics, cohesion and coupling, delineate and measure design quality, albeit subjectively. Second, follow Beck's description of simple design. In priority order, a design is simple to the extent that 1. It runs all the tests, 2. Contains no duplication, 3. Expresses all the design ideas that are in there, 4. Minimizes the number of entities such as classes and methods. The Beck description is simple, but deep. As we follow these rules more and better, the design becomes better. As the design becomes better it becomes better able to evolve. Ron Jeffries www.XProgramming.com Do I contradict myself? Very well then I contradict myself. (I am large, I contain multitudes.) --Walt Whitman
Création d'un disque encrypté sur le disque USB WD:
cryptsetup luksOpen /dev/sdc1 data echo "/dev/mapper/data /home/nono ext3 defaults,user 0 1" >> /etc/fstab mount /home/nono
Ce disque contient:
/home/nono personnelles /home/nono/soft/home/nono/projetsProblème
Itération 1:
There is considerable excitement about Haskell, functional programming and even category theory in SPA2008. This prompted me to revive an old project of mine, which is the implementation of an Haskell compiler in Java. I just got the code back and put it in somewhat good shape again: it compiles and most test passes with meaningful results.
I was thinking seriously about following the HaXE trail: developing a language and systemn based on functional paradigm, that would be compiled to mixed bunch of java/javascript/html files to produce applications.
Function/features of a software are its turnover: the value that is generated by the software. The net earning (ie. bénéfice) is the turnover minus all expenses that limit the functionality delivered by the software:
Function delivery is materialized by stories (along with story points) and accounted for in the burndown chart for the sprint and the backlog.
Code produced during the iteration goes to different accounts:
To balance assets one needs liabilities:
What about tests and tested code ?
Another interesting measure, churn, changes made to the software:
Subject: [XP] SLOC and Churn as measures of technical debt To: extremeprogramming@yahoogroups.com Date: Tue, 11 Mar 2008 17:42:59 +1300 (NZDT) X-Spam-Status: No, score=3.8 required=5.0 tests=AWL,BAYES_50, DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_WHOIS,HTML_MESSAGE,HTML_TINY_FONT autolearn=no version=3.1.7-deb X-Mailer: Pidgeon Post X-Sent: 2 hours, 56 minutes, 2 seconds ago Reply-To: extremeprogramming@yahoogroups.com 1. (*) text/plain ( ) text/html On Fri, 7 Mar 2008, Jim Shore wrote: > Last night, as I was busily not sleeping here in Iceland, I had an > epiphany: > > --> What if the best measure of technical debt is SLOC? > I've already posted the following to the refactoring list and I wasn't going to crosspost it here, but it's too appropriate to what you are saying... --Subject: Churn Metric----------------------------------------------- Here's a simple one. Say "cvs -q rlog -N MODULE_NAME/path/FileName | grep 'total revisions'" And it tells you how many changes has been committed to that file. Now do that for _every_ file in your system and sort by number of revisions. Ooh. Looky. Churn is _extremely_ unevenly distributed. (In the case I discovered this on, the file was being changed once every 1.4 days for the life of the project.) In fact... If you could wave a Magic Wand and stop all churn on say the top 4 most churned files... you would get a very significant boost in productivity across the team. In some cases, refactoring can be that Magic Wand. ---------------------------------------------------------------------- Why do I say it's appropriate to your post? Well, in the case above I mention... the most churned file was indeed deeply "In Debt", _and_ also too long. (4500 raw lines / 2600 sloc (non-comment non-blank) John Carter Phone : (64)(3) 358 6639 Tait Electronics Fax : (64)(3) 359 4632 PO Box 1645 Christchurch Email : john.carter@tait.co.nz New Zealand
http://peter.michaux.ca/article/3556
To be able to infer any part of a (linear) arithmetic equation: http://okmij.org/ftp/Prolog/Arithm/DefinitionTree.hs
Comparing classical object-oriented patterns with functional patterns as found in scala or in Okasaki's book.
The question of typing is important, lot of tricks in Haskell (and Scala) rely on features provided by the type system.
http://en.wikipedia.org/wiki/Duck_typing
Seems like one important language is missing from the list: Javascript !
Having a hard time teaching maven today. There are a lot of hurdles for beginners:
There is a pattern emerging - or being noticed by me - on functional testing: annotating human-readable documents for automated consumption and creation of executable specifications. This pattern is embedded in various tools like:
2008.02.22 17:49:06
I started playing with web annotations which seems a good candidate for implementing easily that kind of stuff. Installed ShiftSpace which is a GreaseMonkey extension that allows one to share actions on web pages:
Fleck is another tool for annotating pages. Works as FFox extension, displays a toolbar on a page and annotations are positionned as little markers hovering on the page.
http://www.markbernstein.org/NeoVictorian.html
Still more fundamentally, the mass of guilt that weighs upon the field deadens our conferences. That guilt arises from the divergence of what we like from what we think we should like. We enjoy exciting new systems that do what nothing else could do; we think we should like systematic demonstrations that this widget lets students do a task 5% faster than that one. We enjoy daring prototypes and agile development; we think we should be planning our work and proving correctness. We enjoy astonishing code; we think we should write code so clear that our most mediocre students (and the management team) will grasp it without effort.
I finally found the error that prevente proper parsing of muse files by maven site plugin: this was caused by an incorrect declaration of plexus.component in the site module class. The question is: How could such a silly error be prevented ? What kind of testing/verification could be done that would prevent creeping such bugs, depending on some framework and off-code declarations that are not detected at compile time. And not reported at run-time by the DI engine...
This is once more a tribute to static typing.
List(Nil),<+>>>>, function g(List(R)) gives compatible head and tail in the request list From: "John A. De Goes" <john@n-brain.net> Subject: Re: [XP] What about QA? To: extremeprogramming@yahoogroups.com Date: Thu, 31 Jan 2008 13:38:48 -0700 X-Spam-Status: No, score=3.8 required=5.0 tests=AWL,BAYES_50, DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_WHOIS,HTML_MESSAGE,HTML_TINY_FONT autolearn=no version=3.1.7-deb X-Mailer: Apple Mail (2.915) X-Sent: 4 days, 14 hours, 25 minutes, 14 seconds ago Reply-To: extremeprogramming@yahoogroups.com 1. (*) text/plain ( ) text/html Seconded. Developers need to come to see QA as measuring the effectiveness of their development process, not as catching all the bugs they're 'too busy' or too lazy to find themselves. When QA finds a bug, developers need to understand this means their development process is broken and they need to improve it. For their part, QA personnel should come to understand that their job is NOT to find bugs. Their job is to help improve the development process, by providing developers with rapid, accurate, and comprehensive feedback on just how efficiently that development process is performing. This means QA should become obsessed with (1) working with developers to produce a means of automating all tests, (2) making tests run in real-time on all supported platforms, (3) continuously expanding the coverage of automated tests, (4) increasing the robustness of tests to requirements changes, (5) increasing the speed with which tests can be changed to accommodate changing requirements, (6) increasing the specificity of tests, so that when a test fails, it's immediately obvious where to look for the problem, (7) constantly making sure developers understand that QA should not be finding any bugs, and doing whatever it takes to make that happen, including working with developers to improve their TDD skills or other skills relevant to the production of defect-free code. I think in the ideal world, all QA personnel are developers and regularly rotate with the other developers (the reason this is not done, I suspect, is that it seems to cost more; why hire a developer at 90k when you can hire QA guy for 2/3rds of that). Regards, John A. De Goes N-BRAIN, Inc. http://www.n-brain.net
Intitulé: Javascript for anal retentive people
Résumé: Présenter le Javascript sous un jour différent, montrer comment on peut mettre en oeuvre les pratiques XP - TDD, remaniement, intégration continue - avec Javascript et comment tirer partie de la nature fonctionnelle du langage.
Détail: Javascript est avant tout considéré comme un langage de seconde zone, un langage de script, tout juste bon à bidouiller des pages web, encombré d'une sémantique extraordinairement floue et d'un nombre incalculable de versions et de plate-formes toutes incompatibles entre elles.
Mais Javascript, c'est aussi le coeur d'un projet aussi important par sa taille et son retentissement - que Mozilla, le premier langage de script officiel de Java 1.6, un nombre de plus en plus important de canevas - Script.aculo.us, ExtJS, Dojo, Rico - ayant permis l'essor du web 2.0... Il est donc probable que de plus en plus de développements, d'une manière ou d'une autre, se fasse en utilisant ce langage.
Parce qu'il n'y a aucune raison profonde pour que du code Javascript soit illisible et non testé, et qu'il est urgent de prévenir l'inflation de code non maîtrisé, cette session propose d'explorer Javascript en mettant l'accent:
La session se déroulera sous la forme d'un kata de développement sur un problème métier, accompagné des explications techniques et du détail de la mise en oeuvre d'un environnement de développement et de build adéquat.
Technique: les développements seront illustrés avec du code Javascript v1.8 sur plate-forme Mozilla, intégrés dans l'outil de build Maven et testés avec le canevas de tests unitaires JSunit et Selenium. Aucune connaissance préliminaire du langage n'est nécessaire, non plus que de la programmation fonctionnelle.
Intitulé: Mon langage est plus gros que le tien
Résumé: Comparer la mise en oeuvre des principes de codage d'XP, sur un problème métier relativement complexe, entre le paradigme fonctionnel et le paradigme objet. Plus particulièrement, évaluer la pertinence du paradigme fonctionnel par rapport:
Détail: Le paradigme de la programmation fonctionnel - tout est fonction - est historiquement le plus ancien modèle de programmation. Il a connu son heure de gloire dans les années 60-70 avec la famille de langages Lisp et Scheme et les promesses de l'intelligence artificielle, au point que certains ont envisagé de construire des machines Lisp.
Après une longue éclipse, pendant laquelle ces langages, devenus les jouets favoris des universitaires et théoriciens, ont éclos en une multitude de dialectes, une nouvelle génération connaît un renouveau limité certes, mais perceptible - de popularité. Haskell, OCaml, Scala, Erlang: ces noms sont désormais connus au-delà des symposiums académiques.
Depuis longtemps fasciné par l'expressivité de ces langages, nous cherchons à comprendre comment articuler les pratiques XP TDD, Binômage, remaniement du code, itérations - et le paradigme fonctionnel; à identifier les points faibles et forts de ces langages par rapport au paradigme dominant - l'objet - dans le cadre de processus de développement agiles; à convaincre le plus grand nombre, enfin, de la pertinence de modifier nos modes de pensée dans le sens où ces langages nous y invitent.
Cette session pratique met en parallèle les deux paradigmes au travers du développement - dirigé par les tests - de deux solutions, fonctionnellement identiques (ie. répondant aux mêmes tests de recette). Nous proposons de dérouler la séance sous la forme de deux itérations successives, conclues par des rétrospectives et d'une synthèse globale. Le plan prévu - mais pas nécessairement imposé - est le suivant:
L'accent sera mis sur l'identification de motifs de conception fonctionnels: fonctions d'ordre supérieur, types abstraits de données, pliage/dépliage de structures, monades...
Technique: l'utilisation d'un portable et la réalisation en parallèle des dévelopements est conseillée. Le langage fonctionnel choisi sera Haskell, et le langage objet Java.
Voir la solution de Christophe Thibaut utilisant les graphes au Dojo Paris. On transforme la liste de demandes en un DAG et on parcourt le DAG afin de trouver le chemin de prix maximum. On aimerait que le graphe soit implicite dans le flot de contrôle des appels de méthodes:
Pour avancer un peu, quelques idées ou pistes pour développer un session XP Day.
XP et les langages fonctionnels (fortement typés ?):
Le problème d'expression (Expression problem en anglais, cf. Philip Wadler): comment permettre, dans un langage (ou plus généralement un système informatique), de faire évoluer la structure des données traitées indépendamment des traitements sur ces données.
Un système doit être extensible tout en respectant les propriétés suivantes:
D'autres propriétés intéressantes sont:
Qu'est ce que cela a à voir avec XP ? Tout, parce qu'un système/langage possédant ces propriétés supporte plus facilement une conception et une réalisation incrémentale, des cycles courts, un minimum de refactoring: on peut faire évoluer indépendamment différents parties du système sans risque de (trop) casser les dépendances, les tests continuent à passer (et sont eux-mêmes extensibles).
Qu'est-ce-que cela a à voir avec la programmation fonctionnelle ? Il n'existe pas actuellement de solution parfaite à ce problème, quel que soit le langage:
Il pourrait être intéressant de comparer ce que les langages fonctionnels, objets et dynamiques ont a à dire sur la question, sur une étude de cas concrète.
L'exemple de Composing Contracts pourrait servir de base: construire un système (simple) d'évaluation d'actifs financiers dans différents langages, et l'étendre en plusieurs étapes.
Not being convinced by the KataChop Dojo of december, I tried my own KataChop, based on Scala programming language. The objective is to be able to prove`` that we are indeed searching in log(n). In the original KataChop, the approach is to derive a loop invariant through TDD: using small programming steps, we install the loop invariant that state we are searching a half-sized list each iteration.
In this variation, I tried to state the property holds without resorting to assertions within the code. The idea of this exercise is to state explicitly the expected property such that we can be convinced that it holds without inspecting the code, ie. through blackbox testing only. To be able to do that, I did the following:
val prop = Prop.forAll(sortedIntList)((l : List[Int]) => property((tgt : Int) => fixpoint(Dicho(l), tgt).length <= (log2(l.length) + 1)))
Dicho object, that defines a <code>search: Int > Dicho</code>. The fixpoint= function then lookup the fix point of this methods invocation and returns the stream of Dicho objects used Some conclusions I can draw are:
Dicho class should store the index from the original array to be somewhat useful. More generally, the code is woefully inefficient: the underlying collection could be shared between all dicho objects and only indices passed around