Au boulot, mon PC portable est équipé, par mes soins, d'un SSD depuis le 16 août 2010.
Je ne suis pas le seul, un collègue a équipé aussi son PC portable avec un SSD depuis au à peu près 2 ans.
Le retour : terrible ! Le PC démarre au quart de tour et les accès au système de fichiers rendent le système véloce comme je n'en ai jamais connu ; c'est là que l'on se rend compte de l'usage fréquent que l'on fait avec le système de fichier. Les desktops lourds comme KDE 4 ou GNOME paraissent bien légers ! (Bon d'accord, j'avoue, j'utilise XMonad comme window manager avec ces desktops). Mon usage est essentiellement du développement logiciel + bureautique.
Le SSD qui équipe mon PC portable est un SSD Intel. Celui du collègue est un Vertex. Pour l'instant, pas de problèmes constatés.
Oui, tu fais bien d'être pinailleur parce que tu as raison. J'ai été effectivement un peu rapide en généralisant les arbres rouge et noir d'arbre équilibrés.
Oui, pour avoir travaillé dessus il y a quelques années, je suis sûr. Pour les propos de Valérie Aurora, il est commun d'appeler les arbres B+-Tree tout simplement B-Tree puisqu'ils sont sont aussi des B-Tree (une famille particulière des B-Tree très en vogue dans les systèmes de fichiers). Par contre, les propos de Rodeh me laissent perplexe; il s'est peut-être mélangé les pinceaux dans son écrit.
J'adore tes dépêches patrick_g. Elles sont d'une qualité exemplaire.
Je voudrais ici juste corriger un détail. Les arbres B sont, en français, les arbres équilibrés (le B signifiant balanced); il en existe plusieurs types dont les plus connus sont les arbres rouges et noirs, et les arbres binaires. Dans les arbres équilibrés (B Tree), les feuilles ne sont pas reliées entre elles. Ce sont avec les B+ Tree que les feuilles sont reliées entre elles ; c'est ce qu'utilise par exemple ReiserFS. Il existe aussi les B* Tree qui sont des arbres qui optimisent la densité des nœuds internes (il fortifie l'équilibre de ces derniers).
Ok, le portable est proposé avec un GNU/Linux dessus. Mais avec une résolution de 1366×768 pixels sur un 15,6", ça ne le fait pas.
Franchement, ce qui est important sur un portable est sa résolution et secondairement le processeur ou la carte graphique (même pour les gamers où, en dehors de la carte graphique, la résolution joue beaucoup aussi dans la qualité vidéo des jeux).
Alors, je préfère un portable avec un code 2 duo pourvu qu'il soit pourvu d'une dalle 15,6" d'au moins WSXGA+ (1680×1050 pixels).
Ce que je trouve dommage, justement, c'est la très peu diversité des résolutions des ordinateurs portables ; les 1366×768 pixels sur des 15,6" sont trop communs (et c'est l'horreur à travailler dessus sous GNU/Linux). Tout ça pour baisser les prix et proposer des portables (jetables) à environ 400-500€ !
Merci pour tes explications, je ne connaissais pas ces aspects techniques.
Je préfère ce genre d'explication à un simple moinssage d'un commentaire qui a eu le malheur de dire, et au conditionnel, ce qui est souvent pensé sur la conséquence de l'IPv6. Une explication est beaucoup plus constructif qu'un simple moinssage qui lui, à défaut de rebuter, n'apporte rien (si ce n'est un défouloir au moinsseur).
Il semblerait qu'avec l'IPv6, chacun pourra avoir une adresse IP concrète et non virtuelle comme avec le NAT. Donc, comme une adresse IPv6 pourra être associée à chaque PC ou, du moins, à chaque domicile (d'où pourquoi le NAT disparaitra pas de toute façon), alors il est plus facile de savoir d'où provient concrètement les paquets réseaux ... d'où le bonheur par exemple de l'HADOPI.
Je te souhaite une bonne migration et que celle-ci se déroule sur les rails ;-)
Combien de temps as tu estimé pour cette migration et avec quelle marge d'erreur ?
Sinon je serai très intéressé par ton retour d'expérience sur cette migration une fois celle-ci finie. J'attends donc avec impatience un journal là-dessus ;-)
Les premières conférences ont eu lieu à l'ENSIMAG. Or après les conférences, l'AlpesJUG aime bien rassembler les participants et le ou les speakers autour d'une collation pour partager, discuter et apprendre à se connaître. C'est un moment jugé important. Ceci n'était pas possible à l'ENSIMAG.
Je n'ai pas suivi l'affaire de près, mais il semblerait que suite à cela, après avoir fait le tour de plusieurs écoles ou universités, seule SUPINFO a marqué son intérêt pour prêter à l'AlpesJUG des salles pour les conférences et un lieu, d'ailleurs fort sympathique et approprié, pour organiser la collation.
Il est vrai que l'émergence des applications Web pour des tâches à l'origine dévolues à des applications natives coïncide avec le tout-connecté. Le tout-connecté afin de pouvoir accéder où que l'on soit à nos données personnelles ou partagées.
C'est ainsi que l'on a des applications Web dédiées à la retouche photo et qui, pour certaines, n'ont rien à envier à un photoshop dans ce domaine. Et il semble qu'elles sont de plus en plus utilisées, ceci malgré leur lenteur effective. Le cloud-computing est un pas en avant là dessus puisqu'il facilite l'externalisation des applications Web et donc aussi, indirectement, des données. Un jour viendra où le desktop et le navigateur Web ne fera plus qu'un.
Et ceci me gène : les données sont crées, voir gérées par nous, mais qui les contrôlent, qui les possèdent réellement ? A mon avis, plus du tout nous. Et lorsque ces données concernent des événements de notre vie (texte, photos, vidéos, autres), j'ai comme l'impression qu'on les laisser filer, se perdre ... Comme si elles ne nous appartenaient plus.
Je ne sais pas si les monades dans Haskell comme les IO sont de gros hacks. Ce que je suis sûr c'est qu'ils me permettent de programmer de façon plus propre en évitant de répartir le code à effet de bord un peu partout. J'ai trouvé que c'était plus facile à déboguer. Au regard de ceci, je trouve que tu exagères avec ton «La pureté en question, c'est pour se donner bonne conscience » ; c'est leur solution pour identifier et isoler les effets de bords afin de mieux les maîtriser et par conséquent garder un code a minima pur. On peut aimer ou non la soupe : dans ce cas, vaut mieux dire «je n'aime pas» que« c'est pas bon».
Pour l'implémentation en C, c'est plus que tester la validité d'un paramètre. C'est une implémentation du monad Maybe d'Haskell qui permet de simuler sans en avoir les problèmes d'effet de bord du null pointer. Le concept du null ou nil a été introduit par Hoare qui, par la suite, l'a regretté car celui-ci introduit des effets de bords indésirables, ce qui conduit au programmeur d'être sur la défensive. Dans Haskell, une variable peut être de type Maybe a, c'est à dire c'est soit une valeur de type a, soit il est rien (il n'est pas initialisé) ; on dit que c'est une variable ou valeur monadique. La monad Maybe permet de représenter et d'informer de la possibilité qu'une donnée peut être nulle. Ceci permet alors d'utiliser des fonctions sur ces types de données sans se faire avoir par surprise par un effet de bord indésirable (de toute façon le compilateur nous rappelle à l'ordre).
Pour l'implémentation en Perl, elle est longue et je ne l'ai que rapidement lu. Son objectif semble de modéliser en Perl les monads (structure qui implémente la notion de changement d'état et qui implique donc aussi une séquence nécessaire des opérations). Ici l'objectif est de prendre une valeur monadique (autrement dit une variable) et d'appliquer sur celle-ci des fonctions pour en ressortir une autre valeur monadique. (De cette valeur monadique, on peut en sortir une valeur pure qui peut donc ne plus être modifiée.) Avec bind, on peut appliquer une fonction pure sur des valeurs monadiques. En singularisant les effets de bords, on peut plus facilement les contrôler. Après, selon le langage, ça peut rendre le code lourd.
Ou encore l'écriture sur un écran ;-)
Les monads sont des structures qui enferment la notion d'effet de bord et pour lesquels un ensemble d'opérations est défini. On y trouve par exemple IO pour les entrées/sorties, X pour l'affichage graphique (dans XMonad), State pour la gestion des états, etc. Les monads obéissent en général à un certain nombre d'axiomes. Ceci permet de singulariser et d'identifier les effets de bords dans le but d'éviter de les repartir dans tout le code.
J'ai trouvé un lien que je pense intéressant pour un peu saisir le concept de monad : http://www.haskell.org/haskellwiki/Monad
Comme l'a répondu kaouete, le concept de monads d'Haskell permet d'y répondre. Voir par exemple le window manager XMonad pour ça.
Toutefois, ta réponse est pertinente au sens où un des principes des langages fonctionnels est d'être libre d'effets de bords, principe qui a dérivé d'ailleurs vers plutôt la maîtrise des effets de bords (parce qu'il est impossible d'être sans effets de bords ; notre univers n'est il pas entropique ?). Au regard de ceci, on peut douter effectivement de la pertinence de l'usage d'un langage fonctionnel dans la programmation système. A côté de ça, sa maîtrise des effets de bord fait que la programmation fonctionnelle semble, à l'heure actuelle, plus propre et efficace à répondre aux problèmes du parallélisme. (Et le langage Go semble avoir été écrit aussi pour répondre aux défis que posent maintenant les architectures multi-cœurs.)
En fait, lorsque je posais cette question, j'avais plus en tête son modèle déclaratif qui apporte une approche intéressante dans la résolution des problèmes ; j'ai l'impression de plus en plus que les solutions à nos problèmes informatiques se traduisent plus facilement dans une approche fonctionnelle qu'impérative.
Ken Thomson n'est pas seulement un des auteurs d'Unix, il est le père fondateur d'Unix. De même, il est aussi un des auteurs de Plan9 et un des pères fondateurs de celui-ci. En effet, avec Plan9 il a voulu remettre à plat Unix en prenant en compte l'expérience et le recul sur la conception de ce système (son objectif était de pousser le "tout est fichier" à son point extrême). C'est dans ce contexte que certaines parties de Plan9 ont d'abord été prototypées en Pike avant d'être réécrit en C.
Maintenant, Rob Pike, le concepteur du langage du même nom, avec, apparemment, l'aide de Ken Thomson, envisage de remettre à plat le C au travers du langage Go. Espérons qu'il ait plus de succès qu'avec Plan9 qui méritait tout de même de réussir.
Toutefois, je me pose une question : est ce que de nos jours un langage de programmation système doit être impératif pour réussir ou être efficace ? Un langage fonctionnel ne pourrait il pas aussi être pertinent dans la programmation système ?
Juste en passant : pour les problèmes de retour en arrière (bouton back des navigateurs par exemple), cf. continuation. Un des premiers (voir le premier à ma connaissance) serveur d'appli web à supporter la continuation fut Seaside. Maintenant la plupart des frameworks le supporte avec plus ou moins de succès. (Celui de Seaside reste à mes yeux le plus aboutit.)
Sinon, dans nos projets, nous utilisons entre autre Grails et des projets Web java classiques avec Spring lorsque l'IHM doit être réalisé avec des techno comme Flex ou GWT.
J'apprécie bcp Grails pour la rapidité qu'il nous offre dans le dév d'applis et ceci grâce à l'intégration des différentes briques logicielles utilisées comme Spring, Hibernate, etc. mais aussi grâce en grande partie au langage Groovy lui-même.
Toutefois, j'ai vue le screencast de Play! et ce que j'ai vue me plait bcp. Dommage que l'on doit se taper du Java (j'aurais préféré du Groovy quant à faire) mais apparemment Play! rajoute plein de petites choses qui permet de faciliter l'utilisation des objets métier en Java. Dommage qu'il n'y ait pas (encore ?) d'intégration avec maven (la tendance est à ce que les projets dans l'entreprise soient gérés et mis à dispo via maven). En tout cas à suivre.
Le problème est plus simple que ça en fait.
La GC est là pour nettoyer la mémoire qui n'est plus référencée et ceci selon des algorithmes qui permettent de le faire de façon optimale. Et le terme plus référencée a une grande importance : le développeur doit toujours se préoccuper de la mémoire allouée ; autrement dit déférencer les objets inutilisés. Ce qui est très important dès que l'on manipule des collections/conteneurs.
Les problèmes de mémoires que l'on observe souvent avec les applis sur VM proviennent d'oublis de déférencement de la part du développeur.
Le groupe n'est pourtant pas Gallilé, Newton ou Einstein.
Un grand homme de science peut être un mauvais citoyen. Qu'est ce que ça prouve ?
De plus, il ne faut pas se leurrer, ils n'étaient pas seuls et ce n'est pas seuls qu'ils ont apporté leur pierre à la connaissance ; là aussi le groupe a son importance, celui auxquels ils appartenaient.
Enfin bon, le monde est tel qu'il est. Le groupe n'a tout simplement pas les connaissance ni la morale requise pour gouverner. Tout ce qu'il réclame, c'est du confort, des avantage sociaux, bref, rien qui concerne la politique au sens noble du terme (faire en sorte que nous soyons encore là dans 100 ans).
Et cette phrase résume toute la différence sur notre point de vue.
Tu estimes que le groupe est tel qu'il t'apparaît aujourd'hui.
J'estime de mon côté que le groupe, constitué d'individus, est, à l'image de ces derniers, capable du mauvais comme du bon. C'est pourquoi aujourd'hui il est tel que l'on voudrait qu'il soit : du pain et des jeux mon bon monsieur, voilà ce qui est nécessaire pour maintenir le groupe à un état souvent qualifié de populace et ceci est d'autant plus facile que le pouvoir est maintenu par un cercle restreint d'individus et que ces derniers n'ont aucun intérêt, même inconscient, de laisser ce pouvoir au groupe. Mais le groupe est capable de plus que ça ; et la démocratie est justement de permettre à ce groupe d'assumer le pouvoir ... et pas de le laisser aux mains de cercles restreints.
Cf le XXéme siècle... pour voir ce que ça donne de laisser le pouvoir à des cercles restreints. (Je pourrais même dire Cf. les siècles précédents aussi et sûrement postérieurs au notre).
De toute façon, je pense que pour qu'un groupe puisse assumer une quelconque forme de pouvoir, il faudrait d'abord lui laisser les moyens pour ça, et ensuite lui lasser acquérir de l'expérience car à mon avis s'assumer, c'est quelque chose qui s'apprend et comme toute chose qui s'apprend, ça se fait dans le temps.
En préface à L'écume des Jours, Boris Vian écrivait: "Il ressort de tout cela que les masses ont toujours tort et les individus toujours raison".
C'est amusant, j'ai appris l'inverse dans des cours de communications : le groupe tombe soit sur la bonne réponse, soit s'en approche le plus comparé aux individus seuls.
Le seul bémol à ceci est que le groupe se trompe autant qu'un individu seul dès qu'une grande gueule qui croit savoir est présent dans le groupe que le reste dudit groupe se laisse manier.
En tout cas, j'ai appris une chose : personne a raison ; personne a la bonne solution, a la bonne réponse pour la simple raison que d'un nous ne sommes pas parfait, et de deux il n'y a pas une solution, une réponse, une vérité.
A partir de ce constat, je considère que personne n'a de réelles prérogatives à gérer, à diriger les choses pour le compte des autres (d'ailleurs, pour les avoir, tous ont en commun de maintenir les autres dans une certaine ignorance des choses). Et donc, pour ce fait, dans une démocratie, nous devons laisser aux gens d'être citoyens et de décider par eux même. Et si des choix mauvais sont faits, ils seront fait par le choix qui a émergé de l'ensemble et pas uniquement d'un seul ou d'un groupe restreint d'individus ; la conséquence est partagée par tout le monde et est le reflet du groupe et pas d'un cercle restreint.
Ben en fait, spring fait partie du truc de base J2EE.
Hum, je pense que tu veux signifier ici que Spring est très pertinent dans les applications Web Java (dont la spécification est une partie de J2EE, JEE maintenant), même s'il ne fait pas partie de J2EE.
Ce que je veux dire par la, c'est que tous les frameworks ne se contentent pas de deplacer un probleme, comme tu le dit.
Oui, ils ne se contentent pas de déplacer le problème, mais c'est un point à ne pas négliger ; leur objectif est tout de même d'amener le problème sur un autre terrain qui soit plus facile à appréhender. Par exemple, les outils déplacent en général la connaissance et le savoir-faire dans l'outil même. Et pour reprendre ton exemple d'Hibernate, point de salut si tu ne comprends pas comment il marche et plus particulièrement ses histoires de cache de premier niveau et de second niveau.
concernant spring, je suis pas trop d'accord.
C'est un framework fabuleux, admirablement bien ecrit, qui permet tout simplement de ne pas perdre de temps sur des betises techniques.
Heu, c'est où que j'ai écris que Spring n'est pas bien. Il ne me semble pas l'avoir écrit. J'ai juste écrit que j'en abusais, autrement dit que j'ai tendance à l'utiliser même dans des applications simples qui ne nécessitent pas nécessairement celui-ci.
Je ne sais pas si ça a un rapport avec la suite de ce que tu as écris, mais gérer la base de donnée n'est pas du ressort de Spring ; il n'offre que des accès à des frameworks tiers comme JPA par exemple (c'est d'ailleurs une de ses grandes forces ; ne pas être intrusif) mais ce n'est pas lui que va gérer ça.
Pour être en écho avec les autres commentaires, je dirais qu'un framework est utile dans deux contextes particuliers :
* tu ne connais pas bien le langage ou les techniques à utiliser et tu ne souhaites pas y investir du temps dedans ; et il existe un framework qui t'abstrait tout ça.
* tu connais bien le langage, la technique, la plate-forme sur laquelle tu développes et tu ne souhaites pas réécrire/copier à chaque fois la même chose ou passer ton temps à maintenir ton propre framework.
Dans les deux cas, j'ai constaté une chose : on s'accoutume à l'usage de frameworks et si on s'améliore dans la mise en œuvre et l'intégration de frameworks, on perd peu à peu la faculté (et la volonté) de faire par nous même. De plus, avec l'accoutumance, on perd aussi le recul suffisant pour apprécier l'intérêt d'utiliser ou non un framework ou même tel ou tel autre framework.
Pour prendre exemple de mon cas :
* je ne souhaite pas m'investir en JS et j'adopte facilement des outils comme scriptulous, puis maintenant de frameworks qui me génère le JS.
* sur plate-forme Java, j'ai tendance à abuser du framework Spring pour gérer le cycle de vie des objets de mes applis et assurer le découplage entre les interfaces et leurs implémentations ou entre les briques métiers et les briques techniques. Tout ceci pour éviter de gérer moi même à nouveau tout ça.
Toutefois, il ne faut pas se leurrer. Le temps passé à maîtriser ton code est transféré sur celui des mécanismes sous-jacent au framework. Bref, un framework n'évite pas d'apprendre ou de savoir-faire quelque chose, il ne fait, AMHA, que transférer l'apprentissage et le problème ailleurs.
Java, l'art de faire compliqué/complexe quand on peut faire simple.
Je pense au contraire que la tendance de faire compliqué ce qui est simple vient en général de ce qui est entre la chaise et le clavier et pas nécessairement de Java ; parce que la plate-forme Java connait un nombre croissant de développeurs, et donc que l'on trouve aussi bien du moins bon que du bon, il est normal que l'on perçoit plus facilement ce genre d'attitude. En tout cas, on trouve bcp de parasites avec une insufférable suffisance.
En tout cas, ta phrase m'a fait penser à ce que j'ai lu un jour : 'Java est un langage pour débutant'.
Cela dit, une interface Eclipse, c'est relativement beau et fonctionnel, faut pas être hypocrite.
Oui ... et avec bcp (trop) de bogues. Quand je peux éviter Eclipse, je le fais.
Et Maven est au dessus de ceci, à une couche d'abstraction supérieure ...
Tu n'as pas compris ce que j'ai écris sur l'approche de Maven ; je n'ai pas dû être très clair. Le plus simple, je pense, est de l'essayer, ça vaut mieux que de grands discours.
# Mon retour
Posté par Miguel Moquillon (site web personnel) . En réponse au journal Les SSD. Évalué à 5.
Au boulot, mon PC portable est équipé, par mes soins, d'un SSD depuis le 16 août 2010.
Je ne suis pas le seul, un collègue a équipé aussi son PC portable avec un SSD depuis au à peu près 2 ans.
Le retour : terrible ! Le PC démarre au quart de tour et les accès au système de fichiers rendent le système véloce comme je n'en ai jamais connu ; c'est là que l'on se rend compte de l'usage fréquent que l'on fait avec le système de fichier. Les desktops lourds comme KDE 4 ou GNOME paraissent bien légers ! (Bon d'accord, j'avoue, j'utilise XMonad comme window manager avec ces desktops). Mon usage est essentiellement du développement logiciel + bureautique.
Le SSD qui équipe mon PC portable est un SSD Intel. Celui du collègue est un Vertex. Pour l'instant, pas de problèmes constatés.
[^] # Re: Arbre B et B+
Posté par Miguel Moquillon (site web personnel) . En réponse à la dépêche Le noyau Linux est disponible en version 3.0. Évalué à 2.
Intéressant. J'ignorais que CouchDB se basait sur un COW B-Tree.
C'est bizarre qu'ils n'en parlent pas ici http://guide.couchdb.org/draft/btree.html
[^] # Re: Arbre B et B+
Posté par Miguel Moquillon (site web personnel) . En réponse à la dépêche Le noyau Linux est disponible en version 3.0. Évalué à 6.
Oui, tu fais bien d'être pinailleur parce que tu as raison. J'ai été effectivement un peu rapide en généralisant les arbres rouge et noir d'arbre équilibrés.
[^] # Re: Arbre B et B+
Posté par Miguel Moquillon (site web personnel) . En réponse à la dépêche Le noyau Linux est disponible en version 3.0. Évalué à 10.
Oui, pour avoir travaillé dessus il y a quelques années, je suis sûr. Pour les propos de Valérie Aurora, il est commun d'appeler les arbres B+-Tree tout simplement B-Tree puisqu'ils sont sont aussi des B-Tree (une famille particulière des B-Tree très en vogue dans les systèmes de fichiers). Par contre, les propos de Rodeh me laissent perplexe; il s'est peut-être mélangé les pinceaux dans son écrit.
Il suffit aussi de vérifier sur wikipédia :
http://en.wikipedia.org/wiki/B-tree
http://en.wikipedia.org/wiki/B%2B_tree
Il y a aussi suffisamment d'articles sur le sujet sur le Web (deux articles en première page de Google):
http://www.bluerwhite.org/btree/
http://www.mec.ac.in/resources/notes/notes/ds/bplus.htm
# Arbre B et B+
Posté par Miguel Moquillon (site web personnel) . En réponse à la dépêche Le noyau Linux est disponible en version 3.0. Évalué à 10.
J'adore tes dépêches patrick_g. Elles sont d'une qualité exemplaire.
Je voudrais ici juste corriger un détail. Les arbres B sont, en français, les arbres équilibrés (le B signifiant balanced); il en existe plusieurs types dont les plus connus sont les arbres rouges et noirs, et les arbres binaires. Dans les arbres équilibrés (B Tree), les feuilles ne sont pas reliées entre elles. Ce sont avec les B+ Tree que les feuilles sont reliées entre elles ; c'est ce qu'utilise par exemple ReiserFS. Il existe aussi les B* Tree qui sont des arbres qui optimisent la densité des nœuds internes (il fortifie l'équilibre de ces derniers).
Voilà c'est tout.
# Oui mais non
Posté par Miguel Moquillon (site web personnel) . En réponse au journal Un portable 15.6" sous GNU/Linux à prix plancher !. Évalué à 5.
Franchement, ce qui est important sur un portable est sa résolution et secondairement le processeur ou la carte graphique (même pour les gamers où, en dehors de la carte graphique, la résolution joue beaucoup aussi dans la qualité vidéo des jeux).
Alors, je préfère un portable avec un code 2 duo pourvu qu'il soit pourvu d'une dalle 15,6" d'au moins WSXGA+ (1680×1050 pixels).
Ce que je trouve dommage, justement, c'est la très peu diversité des résolutions des ordinateurs portables ; les 1366×768 pixels sur des 15,6" sont trop communs (et c'est l'horreur à travailler dessus sous GNU/Linux). Tout ça pour baisser les prix et proposer des portables (jetables) à environ 400-500€ !
# Merci
Posté par Miguel Moquillon (site web personnel) . En réponse à la dépêche IPv6 et conséquences sur l'anonymat. Évalué à 5.
Je préfère ce genre d'explication à un simple moinssage d'un commentaire qui a eu le malheur de dire, et au conditionnel, ce qui est souvent pensé sur la conséquence de l'IPv6. Une explication est beaucoup plus constructif qu'un simple moinssage qui lui, à défaut de rebuter, n'apporte rien (si ce n'est un défouloir au moinsseur).
[^] # Re: Pardon mais
Posté par Miguel Moquillon (site web personnel) . En réponse au journal Le tour de force de l'IPv6. Évalué à -1.
# Retour d'expérience bienvenu
Posté par Miguel Moquillon (site web personnel) . En réponse au journal Pourquoi réécrire LinuxFr.org ?. Évalué à 5.
Combien de temps as tu estimé pour cette migration et avec quelle marge d'erreur ?
Sinon je serai très intéressé par ton retour d'expérience sur cette migration une fois celle-ci finie. J'attends donc avec impatience un journal là-dessus ;-)
[^] # Re: Supinfo ?
Posté par Miguel Moquillon (site web personnel) . En réponse à la dépêche Conférence sur Git à Grenoble (38). Évalué à 2.
Je n'ai pas suivi l'affaire de près, mais il semblerait que suite à cela, après avoir fait le tour de plusieurs écoles ou universités, seule SUPINFO a marqué son intérêt pour prêter à l'AlpesJUG des salles pour les conférences et un lieu, d'ailleurs fort sympathique et approprié, pour organiser la collation.
# Le tout connecté
Posté par Miguel Moquillon (site web personnel) . En réponse au journal Vous êtes plutôt applications web ou applications desktop/native ?. Évalué à 10.
C'est ainsi que l'on a des applications Web dédiées à la retouche photo et qui, pour certaines, n'ont rien à envier à un photoshop dans ce domaine. Et il semble qu'elles sont de plus en plus utilisées, ceci malgré leur lenteur effective. Le cloud-computing est un pas en avant là dessus puisqu'il facilite l'externalisation des applications Web et donc aussi, indirectement, des données. Un jour viendra où le desktop et le navigateur Web ne fera plus qu'un.
Et ceci me gène : les données sont crées, voir gérées par nous, mais qui les contrôlent, qui les possèdent réellement ? A mon avis, plus du tout nous. Et lorsque ces données concernent des événements de notre vie (texte, photos, vidéos, autres), j'ai comme l'impression qu'on les laisser filer, se perdre ... Comme si elles ne nous appartenaient plus.
[^] # Re: Quelques petites rectifications et une question
Posté par Miguel Moquillon (site web personnel) . En réponse au journal Go : Un nouveau langage chez Google. Évalué à 1.
[^] # Re: Quelques petites rectifications et une question
Posté par Miguel Moquillon (site web personnel) . En réponse au journal Go : Un nouveau langage chez Google. Évalué à 1.
Pour l'implémentation en Perl, elle est longue et je ne l'ai que rapidement lu. Son objectif semble de modéliser en Perl les monads (structure qui implémente la notion de changement d'état et qui implique donc aussi une séquence nécessaire des opérations). Ici l'objectif est de prendre une valeur monadique (autrement dit une variable) et d'appliquer sur celle-ci des fonctions pour en ressortir une autre valeur monadique. (De cette valeur monadique, on peut en sortir une valeur pure qui peut donc ne plus être modifiée.) Avec bind, on peut appliquer une fonction pure sur des valeurs monadiques. En singularisant les effets de bords, on peut plus facilement les contrôler. Après, selon le langage, ça peut rendre le code lourd.
[^] # Re: Quelques petites rectifications et une question
Posté par Miguel Moquillon (site web personnel) . En réponse au journal Go : Un nouveau langage chez Google. Évalué à 2.
Les monads sont des structures qui enferment la notion d'effet de bord et pour lesquels un ensemble d'opérations est défini. On y trouve par exemple IO pour les entrées/sorties, X pour l'affichage graphique (dans XMonad), State pour la gestion des états, etc. Les monads obéissent en général à un certain nombre d'axiomes. Ceci permet de singulariser et d'identifier les effets de bords dans le but d'éviter de les repartir dans tout le code.
J'ai trouvé un lien que je pense intéressant pour un peu saisir le concept de monad :
http://www.haskell.org/haskellwiki/Monad
[^] # Re: Quelques petites rectifications et une question
Posté par Miguel Moquillon (site web personnel) . En réponse au journal Go : Un nouveau langage chez Google. Évalué à 2.
Toutefois, ta réponse est pertinente au sens où un des principes des langages fonctionnels est d'être libre d'effets de bords, principe qui a dérivé d'ailleurs vers plutôt la maîtrise des effets de bords (parce qu'il est impossible d'être sans effets de bords ; notre univers n'est il pas entropique ?). Au regard de ceci, on peut douter effectivement de la pertinence de l'usage d'un langage fonctionnel dans la programmation système. A côté de ça, sa maîtrise des effets de bord fait que la programmation fonctionnelle semble, à l'heure actuelle, plus propre et efficace à répondre aux problèmes du parallélisme. (Et le langage Go semble avoir été écrit aussi pour répondre aux défis que posent maintenant les architectures multi-cœurs.)
En fait, lorsque je posais cette question, j'avais plus en tête son modèle déclaratif qui apporte une approche intéressante dans la résolution des problèmes ; j'ai l'impression de plus en plus que les solutions à nos problèmes informatiques se traduisent plus facilement dans une approche fonctionnelle qu'impérative.
# Quelques petites rectifications et une question
Posté par Miguel Moquillon (site web personnel) . En réponse au journal Go : Un nouveau langage chez Google. Évalué à 1.
Maintenant, Rob Pike, le concepteur du langage du même nom, avec, apparemment, l'aide de Ken Thomson, envisage de remettre à plat le C au travers du langage Go. Espérons qu'il ait plus de succès qu'avec Plan9 qui méritait tout de même de réussir.
Toutefois, je me pose une question : est ce que de nos jours un langage de programmation système doit être impératif pour réussir ou être efficace ? Un langage fonctionnel ne pourrait il pas aussi être pertinent dans la programmation système ?
[^] # Re: Mon expérience
Posté par Miguel Moquillon (site web personnel) . En réponse à la dépêche Play! 1.0 est sorti. Évalué à 2.
Sinon, dans nos projets, nous utilisons entre autre Grails et des projets Web java classiques avec Spring lorsque l'IHM doit être réalisé avec des techno comme Flex ou GWT.
J'apprécie bcp Grails pour la rapidité qu'il nous offre dans le dév d'applis et ceci grâce à l'intégration des différentes briques logicielles utilisées comme Spring, Hibernate, etc. mais aussi grâce en grande partie au langage Groovy lui-même.
Toutefois, j'ai vue le screencast de Play! et ce que j'ai vue me plait bcp. Dommage que l'on doit se taper du Java (j'aurais préféré du Groovy quant à faire) mais apparemment Play! rajoute plein de petites choses qui permet de faciliter l'utilisation des objets métier en Java. Dommage qu'il n'y ait pas (encore ?) d'intégration avec maven (la tendance est à ce que les projets dans l'entreprise soient gérés et mis à dispo via maven). En tout cas à suivre.
# GC et déférencement
Posté par Miguel Moquillon (site web personnel) . En réponse au journal Encore une histoire de récupérateur de mémoire. Évalué à 3.
La GC est là pour nettoyer la mémoire qui n'est plus référencée et ceci selon des algorithmes qui permettent de le faire de façon optimale. Et le terme plus référencée a une grande importance : le développeur doit toujours se préoccuper de la mémoire allouée ; autrement dit déférencer les objets inutilisés. Ce qui est très important dès que l'on manipule des collections/conteneurs.
Les problèmes de mémoires que l'on observe souvent avec les applis sur VM proviennent d'oublis de déférencement de la part du développeur.
[^] # Re: signe des temps
Posté par Miguel Moquillon (site web personnel) . En réponse au journal Marrons-nous 2 minutes avec HADOPI 2. Évalué à 2.
Le groupe n'est pourtant pas Gallilé, Newton ou Einstein.
Un grand homme de science peut être un mauvais citoyen. Qu'est ce que ça prouve ?
De plus, il ne faut pas se leurrer, ils n'étaient pas seuls et ce n'est pas seuls qu'ils ont apporté leur pierre à la connaissance ; là aussi le groupe a son importance, celui auxquels ils appartenaient.
Enfin bon, le monde est tel qu'il est. Le groupe n'a tout simplement pas les connaissance ni la morale requise pour gouverner. Tout ce qu'il réclame, c'est du confort, des avantage sociaux, bref, rien qui concerne la politique au sens noble du terme (faire en sorte que nous soyons encore là dans 100 ans).
Et cette phrase résume toute la différence sur notre point de vue.
Tu estimes que le groupe est tel qu'il t'apparaît aujourd'hui.
J'estime de mon côté que le groupe, constitué d'individus, est, à l'image de ces derniers, capable du mauvais comme du bon. C'est pourquoi aujourd'hui il est tel que l'on voudrait qu'il soit : du pain et des jeux mon bon monsieur, voilà ce qui est nécessaire pour maintenir le groupe à un état souvent qualifié de populace et ceci est d'autant plus facile que le pouvoir est maintenu par un cercle restreint d'individus et que ces derniers n'ont aucun intérêt, même inconscient, de laisser ce pouvoir au groupe. Mais le groupe est capable de plus que ça ; et la démocratie est justement de permettre à ce groupe d'assumer le pouvoir ... et pas de le laisser aux mains de cercles restreints.
Cf le XXéme siècle... pour voir ce que ça donne de laisser le pouvoir à des cercles restreints. (Je pourrais même dire Cf. les siècles précédents aussi et sûrement postérieurs au notre).
De toute façon, je pense que pour qu'un groupe puisse assumer une quelconque forme de pouvoir, il faudrait d'abord lui laisser les moyens pour ça, et ensuite lui lasser acquérir de l'expérience car à mon avis s'assumer, c'est quelque chose qui s'apprend et comme toute chose qui s'apprend, ça se fait dans le temps.
[^] # Re: signe des temps
Posté par Miguel Moquillon (site web personnel) . En réponse au journal Marrons-nous 2 minutes avec HADOPI 2. Évalué à 1.
En préface à L'écume des Jours, Boris Vian écrivait: "Il ressort de tout cela que les masses ont toujours tort et les individus toujours raison".
C'est amusant, j'ai appris l'inverse dans des cours de communications : le groupe tombe soit sur la bonne réponse, soit s'en approche le plus comparé aux individus seuls.
Le seul bémol à ceci est que le groupe se trompe autant qu'un individu seul dès qu'une grande gueule qui croit savoir est présent dans le groupe que le reste dudit groupe se laisse manier.
En tout cas, j'ai appris une chose : personne a raison ; personne a la bonne solution, a la bonne réponse pour la simple raison que d'un nous ne sommes pas parfait, et de deux il n'y a pas une solution, une réponse, une vérité.
A partir de ce constat, je considère que personne n'a de réelles prérogatives à gérer, à diriger les choses pour le compte des autres (d'ailleurs, pour les avoir, tous ont en commun de maintenir les autres dans une certaine ignorance des choses). Et donc, pour ce fait, dans une démocratie, nous devons laisser aux gens d'être citoyens et de décider par eux même. Et si des choix mauvais sont faits, ils seront fait par le choix qui a émergé de l'ensemble et pas uniquement d'un seul ou d'un groupe restreint d'individus ; la conséquence est partagée par tout le monde et est le reflet du groupe et pas d'un cercle restreint.
[^] # Re: L'usage des frameworks: un transfert du savoir-faire
Posté par Miguel Moquillon (site web personnel) . En réponse au journal framework ou farmer ?. Évalué à 1.
Hum, je pense que tu veux signifier ici que Spring est très pertinent dans les applications Web Java (dont la spécification est une partie de J2EE, JEE maintenant), même s'il ne fait pas partie de J2EE.
Ce que je veux dire par la, c'est que tous les frameworks ne se contentent pas de deplacer un probleme, comme tu le dit.
Oui, ils ne se contentent pas de déplacer le problème, mais c'est un point à ne pas négliger ; leur objectif est tout de même d'amener le problème sur un autre terrain qui soit plus facile à appréhender. Par exemple, les outils déplacent en général la connaissance et le savoir-faire dans l'outil même. Et pour reprendre ton exemple d'Hibernate, point de salut si tu ne comprends pas comment il marche et plus particulièrement ses histoires de cache de premier niveau et de second niveau.
[^] # Re: L'usage des frameworks: un transfert du savoir-faire
Posté par Miguel Moquillon (site web personnel) . En réponse au journal framework ou farmer ?. Évalué à 1.
concernant spring, je suis pas trop d'accord.
C'est un framework fabuleux, admirablement bien ecrit, qui permet tout simplement de ne pas perdre de temps sur des betises techniques.
Heu, c'est où que j'ai écris que Spring n'est pas bien. Il ne me semble pas l'avoir écrit. J'ai juste écrit que j'en abusais, autrement dit que j'ai tendance à l'utiliser même dans des applications simples qui ne nécessitent pas nécessairement celui-ci.
Je ne sais pas si ça a un rapport avec la suite de ce que tu as écris, mais gérer la base de donnée n'est pas du ressort de Spring ; il n'offre que des accès à des frameworks tiers comme JPA par exemple (c'est d'ailleurs une de ses grandes forces ; ne pas être intrusif) mais ce n'est pas lui que va gérer ça.
# L'usage des frameworks: un transfert du savoir-faire
Posté par Miguel Moquillon (site web personnel) . En réponse au journal framework ou farmer ?. Évalué à 3.
* tu ne connais pas bien le langage ou les techniques à utiliser et tu ne souhaites pas y investir du temps dedans ; et il existe un framework qui t'abstrait tout ça.
* tu connais bien le langage, la technique, la plate-forme sur laquelle tu développes et tu ne souhaites pas réécrire/copier à chaque fois la même chose ou passer ton temps à maintenir ton propre framework.
Dans les deux cas, j'ai constaté une chose : on s'accoutume à l'usage de frameworks et si on s'améliore dans la mise en œuvre et l'intégration de frameworks, on perd peu à peu la faculté (et la volonté) de faire par nous même. De plus, avec l'accoutumance, on perd aussi le recul suffisant pour apprécier l'intérêt d'utiliser ou non un framework ou même tel ou tel autre framework.
Pour prendre exemple de mon cas :
* je ne souhaite pas m'investir en JS et j'adopte facilement des outils comme scriptulous, puis maintenant de frameworks qui me génère le JS.
* sur plate-forme Java, j'ai tendance à abuser du framework Spring pour gérer le cycle de vie des objets de mes applis et assurer le découplage entre les interfaces et leurs implémentations ou entre les briques métiers et les briques techniques. Tout ceci pour éviter de gérer moi même à nouveau tout ça.
Toutefois, il ne faut pas se leurrer. Le temps passé à maîtriser ton code est transféré sur celui des mécanismes sous-jacent au framework. Bref, un framework n'évite pas d'apprendre ou de savoir-faire quelque chose, il ne fait, AMHA, que transférer l'apprentissage et le problème ailleurs.
[^] # Re: Grandiose
Posté par Miguel Moquillon (site web personnel) . En réponse au journal Linuxfr en J2EE. Évalué à 9.
Java, l'art de faire compliqué/complexe quand on peut faire simple.
Je pense au contraire que la tendance de faire compliqué ce qui est simple vient en général de ce qui est entre la chaise et le clavier et pas nécessairement de Java ; parce que la plate-forme Java connait un nombre croissant de développeurs, et donc que l'on trouve aussi bien du moins bon que du bon, il est normal que l'on perçoit plus facilement ce genre d'attitude. En tout cas, on trouve bcp de parasites avec une insufférable suffisance.
En tout cas, ta phrase m'a fait penser à ce que j'ai lu un jour : 'Java est un langage pour débutant'.
Cela dit, une interface Eclipse, c'est relativement beau et fonctionnel, faut pas être hypocrite.
Oui ... et avec bcp (trop) de bogues. Quand je peux éviter Eclipse, je le fais.
[^] # Re: Ant like. A quand un maven like ?
Posté par Miguel Moquillon (site web personnel) . En réponse à la dépêche Waf - un système de construction de logiciels. Évalué à 0.
Tu n'as pas compris ce que j'ai écris sur l'approche de Maven ; je n'ai pas dû être très clair. Le plus simple, je pense, est de l'essayer, ça vaut mieux que de grands discours.