J'utilise Maven au boulot, et je le vois surtout comme une surcouche à Ant.
Et pourtant, Maven n'est pas une surcouche à Ant, mais bien un outil à part entière. Maven est à une couche d'abstraction de plus haut niveau que celle de Ant et autres outils similaires dans la construction logicielle.
on reste toujours avec des fichiers XML qui ne sont pas fait pour écrire du code.
Oui, seulement Maven n'est pas pour écrire du code ;-)
Sinon, effectivement, l'usage du XML pour écrire le POM peut être pour certain considéré comme rébarbatif. Je ne suis moi même pas sûr que ce choix soit pertinent ; seulement, à l'heure du tout XML, bien que critiquable, je comprends le choix de celui-ci par les concepteurs de Maven.
Le fait de télécharger les dépendances à partir d'internet est aussi relativement gênant lorsque l'on travaille en local,
Ce qui est téléchargé de l'extérieur ce sont seulement les plugins ou dépendances qui ne sont pas présents dans le cache local (dépôt local). Une fois, téléchargés, seuls ceux présents dans le cache local sont pris en compte. Donc, au début, c'est lourd, mais après ça va très vite. De plus, l'usage de Maven dans de l'intégration continue m'est apparu plus facile qu'avec d'autres solutions.
la structure imposée n'est pas forcément la plus logique bien qu'elle convienne pour un certain nombre d'applications de gestion en J2EE
Là je ne suis pas d'accord. Que la structure plaise ou non est une chose. Elle a sa propre logique et, que l'on aime ou pas, elle est cohérente pour bcp types de projets, et pas essentiellement pour du J2EE/JEE. Elle a l'avantage de proposer une structure commune aux projets, ce qui fait que les développeurs n'ont pas à réapprendre de comment celui-ci est structuré, de comment sont gérées les dépendances, etc. (Oui, effectivement, il doit connaitre celui de Maven, mais cet acquis est capitalisable.)
Waf et les autotools possèdent cependant un concept similaire dans l'écriture du code: la configuration, la compilation, l'installation, la vérification (make distcheck), la distribution (make dist).
Oui, mais ça reste toujours des définitions de tâches qui sont pré-écrites dans les Makefile ou autres fichiers de build. L'enchaînement des tâches y doivent aussi être décrites. Dans Maven, l'accent est mis non plus sur les tâches, mais sur les phases d'écriture de code, Maven gérant le flot qui parcours les phases.
Pour ce qui est de la lourdeur du modèle de tâches et de dépendances, je pense qu'il s'agit surtout d'un problème de granularité, par exemple pour des projets en C on se retrouve avec des fichiers objets individuels (.o) alors qu'en java des répertoires entiers sont transformés en même temps, le compilateur java de sun faisant un optimisation globale (avec des fichiers inner class impossibles à prédire avant de compiler les fichiers).
Oui, d'accord. Mais je ne pense pas que ça empêche la création d'outil pour C/C++ similaires à Maven ; il faut prendre en compte je pense les particularités de cet environnement.
La diversité des outils et des compilateurs, c'est aussi ce qui fait la richesse des environnements de type Unix, et sur cet aspect
Oui, une certaine richesse. Et c'est justement la pauvreté d'outils de type Maven, cad d'outils de construction logicielle de plus haut niveau, que je trouve dommage. Probablement que c'est encore tôt.
Ok, au vue des exemples que j'ai pu voir, on reste encore à des choses du type Ant pour Java qui a été une solution très intéressante de remplacement des Makefile dans le dév Java.
Or, depuis quelques année est apparue sur la plate-forme Java un remplacement à ce genre de système de construction de logiciels : maven. http://maven.apache.org/
Pour ceux qui ne connaissent pas, maven est un système de construction de logiciel de plus haut niveau au sens où d'une part il impose une structure du projet et d'autre par il parcours différentes phases dans l'écriture de code : validate, compile, test, package, integration-test, install, deploy pour ne citer que quelques uns.
(Voir http://www.oqube.com/formations/maven/lifecycle.html pour une vision plus complète des phases.)
Il n'y pas plus la définition de tâches mais des plugins avec différentes cibles d'exécutions : un pour la compilation de code, un autre pour dérouler des tests, un pour archiver, etc. Chacun va s'exécuter dans une ou plusieurs phases selon son objectif.
Un autre avantage, et un gros, de Maven, est la gestion des dépendances : les dépendances en bibliothèques sont automatiquement téléchargées de dépôts maven sur le Web et intégrées dans les phases de compilation, de tests, etc. Les dépendances transitives sont aussi prises en compte. Ce qui est aussi intéressant, c'est que seul les plugins définis dans le POM (Project Object Model, le descripteur du projet), sont chargés (et récupérés du Web s'ils ne sont pas présents dans le cache local (un dépôt local)).
Malgré les défauts de Maven, après avoir travaillé avec aussi bien sur des petits que des plus gros projets, je ne reviendrais pas en arrière sur des systèmes de construction logicielle à la Ant ou Makefile ou Cons (dont SCons est un clone pour Python) ... Le principe de définition de tâches dans de tels systèmes peut devenir trop lourd avec de gros projets et de plus il faut soit même s'embêter à gérer les dépendances.
Il est dommage qu'il n'y ait pas encore de projet du style Maven pour gérer la construction logicielle pour la plate-forme C/C++ ou Python.
Des logiciels complexes comme le noyau Linux ont été écrits sans la moindre méthodologie officielle (*), que ce soit Scrum, cycles-en-V, etc. Un programme, ça ne s'« ingénie » pas, ça ne s'usine pas : ça s'écrit.
D'abord, le noyau Linux a été développé selon une méthode même si celle-ci est propre aux développeurs du noyau et surtout propre à l'approche personnelle de Linus. Méthode qui d'ailleurs s'est raffinée au fur et à mesure des développements. C'est exactement l'approche des méthodes agiles ; la méthode utilisée est une méthode agile.
Ensuite, un programme s'écrit, certes, mais selon des techniques dites d'ingénierie, de la même façon que le projet dans lequel l'élaboration du programme se fait. Ainsi, par exemple, Scrum va t'aider en donnant des techniques dans la gestion de ton projet tandis que des approches comme XP ou TDD va te fournir des méthodes d'écriture de code te permettant d'atteindre une certaine qualité tout en maintenant une cohésion et une discipline d'équipe. De plus, afin de maintenir un code de qualité tout en maintenant une vélocité d'élaboration du programme, des outils comme l'intégration continue, les tests unitaires et d'intégration automatiques, des outils de contrôle de versions, le source control, etc. sont plus ou moins nécessaires et font partie ce que l'on appelle l'ingénierie logicielle.
La seule vertu de telles méthodologies, c'est de créer une discipline (notamment en entreprise, où le chef voit son autorité légitimée par l'autorité extérieure de la méthodologie). Mais à ce compte elles se valent probablement toutes, et les querelles de clocher ou de génération sont sans importance.
D'abord, le propre des méthodes agiles est l'auto-discipline et l'auto-organisation. Ce qui tranche en général des méthodes comme CMMi par exemple qui est malheureusement utilisée le plus souvent de la façon dont tu dis.
Ensuite, s'il existe une multitude de méthodes dites agiles, et qui émergent en partie du monde du logiciel libre, certaines sont plus connues sous des noms bien précis comme Scrum, Crystal Clear, etc. Or ces dénominations sont importants parce qu'ils permettent de mieux diffuser la connaissance (ce qui ce cache derrière ce nom) et ils permettent aussi de pouvoir les "vendre" à tes manageurs dans une entreprise ... et ça c'est important ; d'où d'ailleurs le buzz autour.
Derrière les méthodes agiles, je dirais que c'est une sorte de retour du contrôle des développeurs dans la façon dont s'écrivent les programmes, face à un raz bol de toujours payer les pots cassés du fait des décideurs ou manageurs qui n'ont de connaissance du développement logiciel que leur prétention d'y connaitre.
J'ai lu le billet dans le blog (pas la traduction) avec une reprise du mail en question.
J'ai ensuite parcouru la traduction.
Malheureusement, contrairement à ce que semble croire le traducteur, en France aussi ça arrive mais on en entend pas parler (à part sur Framablog).
Et ce n'est pas qu'avec des enseignants, mais aussi avec des parents des associations parentales. Par exemple, l'année dernière, un père a été offusqué que des enfants de maternelle (oui de maternelle) aient eu un apprentissage de l'outil informatique (clavier / souris) avec des PC sous GNU/Linux ; son argument a été que dans la vie professionnelle, les ordinateurs sont équipés que de Windows et que donc il fallait que nos charmants bambins commencent à se familiariser avec cet environnement (sinon, vous vous rendez compte ma bonne dame, ils seront être exclus de la société avec de telles approches déviants !)
Je sais que c'est différent mais le concept y ressemble de très près.
Seaside est un framework de développement d'applications Web basé sur Smalltalk (et plus particulièrement sur Squeak).
Sa faculté est de pouvoir aussi développer et déboguer son appli via son navigateur web, le tout à chaud.
Ainsi, en installant simplement seaside sur un serveur distant et en codant rapidement un cadre de créations d'appli web avec, tu offres en peu de temps et surtout sans plomberie la possibilité à des personnes de créer leurs applis Web. L'intérêt est que tout est déjà quasiment prêt avec seaside et que les utilisateurs n'ont pas à connaitre des technos différentes que sont le JS, l'Ajax, le HTML, etc... ; il suffit de connaitre smalltalk et l'environnement de dév publié dans le navigateur.
Je constate que depuis quelques années, les langages fonctionnelles refont surface :
- les vieux langages reprennent du poil de la bête (Haskell, Erlang, ...)
- les langages impératifs introduisent des concepts fonctionnels,
- de nv langages fonctionnels apparaissent (Scala par exemple).
Et je pense que ceci est en grande partie dû à deux aspects :
- ce sont des langages d'assez haut niveaux qui permettent de répondre à des problématiques bcp plus complexes et de façon plus élégante que ne le peuvent actuellement les langages dîts impératifs,
- les architectures multi-corps et la progression de la programmation parallèle sur le marché ont mis en lumière les limites des outils actuels utilisés et basé sur une structure impérative et les facultés des langages fonctionnels dans le domaine.
Le tout évidemment combiné avec la monté en puissance des machines qui permettent de palier aux pb de perfs inhérents aux programmes fonctionnels (quoique lorsque l'on regarde un programme en Caml ...)
Ce qui est intéressant dans Haskell, c'est l'innovation que gravite autour. Il supporte ainsi non seulement le fonctionnel de second ordre, mais aussi, en quelque part, le typage du second ordre avec ses classes de type (un clin d'œil à la théorie F-Bound de Cook).
A côté de ceci, pour ceux qui veulent s'y exercer, il existe xmonad, un gestionnaire de fenêtres X en Haskell ; vous pouvez y lire un peu son code, jouer avec. Au début, je recommande de jouer d'abord avec la conf qui est écrite en Haskell et qui est compilée à la volé dès le démarrage ou le redémarrage du gestionnaire.
Sinon, je me suis acheté le bouquin sur Erlang de Joe Armstrong (Programming Erlang: Software for a Concurrent World) afin de m'amuser un peu plus avec ce langage (enfin, qd j'ai le temps, ce qui est de plus en plus rare ces temps-ci)
C'est une application web de gestion de travaux collaboratifs. A ce titre, il permet la gestion des tâches, des documents relatifs à ceux-ci, etc.
La gestion des tâches de l'outil répond à ton besoin puisque l'application calcule le temps pris par chaque individu dans une tâche (en calculant le temps passé sur celle-ci ; l'utilisateur indiquant le début et la fin de ses participations dans ladite tâche)
Window Maker a été longtemps mon wm de tous les jours. Le seul bémol était le gestionnaire de fichier au look&feel de wmaker (wmfile je crois) et qui était bogué jusqu'à la moelle ; j'ai fini par me rabattre sur rox-filer.
Il était facilement configurable avec wmprefs (que j'ai toujours préféré à wmakerconf), et son ergonomie et son graphisme était alléchant ! J'ai eu même l'occasion de jeter un coup d'oeuil sur son code et celui-ci était vraiment bien conçu et agréable à lire, malgré que ce soit du C.
Mais le temps a passé, et aujourd'hui j'utilise Fvwm (avec Fvwm-Crystal) à la maison et XMonad au boulot. (Note : je suis un peu bizarre parce que j'utilise Fvwm sur un portable tandis que XMonad tourne sur une ... station de bureau ! L'inverse aurait été plus logique, mais bon ...)
J'ai découvert Erlang il y a peu de temps, et les personnes s'occupant de l'association disait que la VM multi-cpu allait sortir bientôt (c'était il y a 2 ou 3 ans maximum). La VM Erlang savait gérer plein de threads mais sur un seul processus physique.
Ok, la VM multi-proc d'Erlang (donc non OTP) existe apparemment depuis 2 à 3 ans. Néanmoins, OTP existe lui depuis 1996 et j'ai toujours entendu qu'OTP gérait les archi multi-procs ; mais peut-être que c'était de l'intox (je n'ai pas vérifié de moi même ceci).
Quant aux perfs, ce qui est testé sont relatifs à des algo, c'est ce que j'appelle des perfs locales. Or, ce qui est intéressant dans une appli sont les perfs globales. Ainsi, on a souvent des surprises d'appli, pourtant écrites en C, qui se révèlent plus lourdes /à l'usage/ que les même mais écrites dans des langages de plus haut niveau (le design influe, mais pas seulement, sur les perfs globales).
Performant ne signifie pas uniquement 'rapidité d'exécution atomique de code'.
La performance signifie aussi 'temps d'exécution /globale/ du code' dans une appli et le débit de traitement des requêtes (et le design joue bcp ici). Et à ce niveau, Erlang n'a pas à rougir. (Bien sûr, il existe des plate-formes plus performantes qu'Erlang.)
Quand à la gestion multiprocesseur, elle existe au plus depuis OTP, donc depuis 1996. Il est probable qu'elle existait déjà dans le langage avant, mais je n'ai pas d'info là dessus.
Si on veut jouer les troubles fêtes, en ne s'appuyant que sur la définition de la POO telle qu'énoncé par son concepteur, Alan Kay, et dans laquelle l'envoi de messages entre objets est un concept clé de la POO, alors on peut dire que les langages actuels tel que C++, Java, C#, etc. ne sont pas des langages orientés-objet. (On pourrait plus les qualifier de langages orientés composants, une mixture de modulaire et d'objet.)
et sa phrase :
"OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them"
En fait, l'approche orienté agent est issue de celle OO. Elles ne s'excluent pas, au contraire, puisqu'en OO un agent peut-être tout simplement un objet ! En fait, c'est l'implémentation actuelle de la POO dans langages qui est relativement limitée et qui pose problème.
Il faut voir à ce sujet SCOOP (Simple Concurrent Object-Oriented Programming). Dans cette approche, à chaque objet est associé un thread dans lequel est exécuté chaque appel de méthodes. Si la méthode est de type requête (retour de valeur) alors la méthode est synchrone, sinon elle est asynchrone. De plus, comme dans Ada, des conditions d'entrée peuvent être définies au niveau des méthodes ; si la condition n'est pas respectée, l'appel de la méthode est mise en attente jusqu'à ce qu'elle soit remplie. Ainsi, comme les changements d'états sont en rétention dans l'objet, il n'y a pas d'effet de bord ou de changement d'état entre threads !
Effectivement, Erlang est né du secteur des Telecom (chez Ericsson). Ce qui fait que les choix sur la conception du langage ont été issues des préoccupation de ce domaine : performance, monté en charges, rechargement à chaud, etc. L'usage de ce langage, comme tout langage fonctionnel, est resté marginal ou niché dans certaines activités (autre que les télécoms) parce que la lingua-franca auprès de la masse des développeurs et des entreprises reste le C-like (au sens syntaxique et impérative).
Or, les architectures de nos PC ont basculé il y a 1 à 2 ans vers les multi-coeurs et cette tendance va en s'accélérant. Le problème est alors posé aux langages de programmation actuels : on passe d'une approche séquentielle vers une approche parallèle. Et voilà où actuellement le bas blesse : les langages impératives actuels ne sont pas adaptés à cette approche. Il en résulte alors deux tendances :
- récupérer des techniques et des concepts issues des langages fonctionnelles pour les introduire dans les langages impératives existants,
- sortir de nouvelles API sur les aspects du parallélisme
C'est ce que l'on observe avec C# (premier point) et Java (second point) par exemple.
En attendant, des langages comme Erlang répondent déjà à ce genre de problématique et ont fait leur preuve. C'est pourquoi celui-ci reprend du poil de la bête.
Par exemple, sur la plate-forme Java est apparue le langage fonctionnel scala qui prend lui aussi de l'ampleur.
Alors, que sera le 21e siècle : encore impérative avec tout un tas de hacks pour faciliter tant bien que mal la programmation parallèle ou finalement fonctionnelle dont l'approche permet de répondre élégamment à ce type de programmation ?
Quelques éclaircissement : la méthode HTTP PUT permet de remplacer une ressource existante ou la créer avec celle embarquée dans le corps de la requête HTTP. Ce n'est pas vraiment de l'édition au sens ou tu peux ajouter ou enlever de l'information directement avec la ressource pointée par l'URI. (On peut par contre plus parler d'édition avec le navigateur, se dernier se chargeant alors de remplacer tout simplement le contenu existant avec le nouveau avec la méthode PUT ; enfin s'il supporte cette fonction.)
Ensuite, il me semble que le premier navigateur Web, celui utilisé par Tim Berners-Lee (le créateur du Web), et qui tournait sur NextStep, permettait de mettre à jour une ressource Web : la représentation de la ressource Web (en HTML) dans le navigateur était directement éditable. Par besoin donc de formulaire pour ce faire.
Après, il reste le problème de l'autorisation de modification de ressources Web ...
Je ne connais pas la façon dont les sciences sont enseignées actuellement dans les collèges et lycées.
Par contre, par mon expérience, j'ai pu constater que l'accroche de l'élève à la science enseignée dépendait de beaucoup du professeur. A côté de ceci, et pour donner raison à certains ici, j'ai pu constater aussi un enseignement parfois débile non à cause du prof mais surtout du fait du programme limite farfelue ; en mémoire me vient les transistors en Terminal C alors que finalement on n'avait eu aucune préparation nécessaire pour justement appréhender ce programme. Mais voilà, c'était demandé par le programme ! Du grand n'importe quoi.
Toutefois, une chose est sûr, même si l'enseignement des sciences est loin d'être parfaite, (de toute façon l'enseignement en lui même n'est pas une science exacte et relève à mon avis plus de l'expérimentale), il est nécessaire parce qu'il nous donne les armes qui nous permettrons de mieux appréhender notre monde ; et ceci d'autant plus à notre époque qui s'inscrit dans une ère technologique. De plus, sans enseignement des sciences, comment les élèves vont pouvoir savoir que ça les intéresse ou que c'est peut-être leur voie ?
Dans ton exemple, tu ne fais que déplacer la fenêtre dans le workspace au doux nom "mail".
Je le fais aussi. Ce que j'aimerai, c'est de pouvoir aussi taguer la fenêtre (extension XMonad.Actions.TagWindows).
Sinon, pour déplacer la fenêtre, au lieu de doF (W.shift "2:mail")
tu peux écrire aussi : doShift "mail"
Actuellement, à mon travail, j'utilise XMonad que j'apprécie bcp.
Ce que j'aime bien de cet environnement est sa légèreté, sa facilité de conf (même si on ne connaît pas trop Haskell), et le tiling. Ha et aussi qu'il est écrit en Haskell, un langage de de haut niveau et de qualité, ce qui permet des évolutions et des corrections de bogues rapides et d'écrire soit même rapidement des choses (la contre partie est la courbe d'apprentissage de haskell).
Sinon, il m'a fait découvrir le syst. de tags et je trouve ça vachement sympa ; dommage que je n'ai pas encore trouvé comme attribuer un tag à une fenêtre applicative précise au démarrage de celle-ci.
J'ai remarqué que le système de tag semble plus intégré et abouti dans awesome. Faudra que je l'essai un jour. Dommage qu'il soit écrit tout en C (mais comme il propose un framework de dév, il propose probablement des fonctions de haut niveau pour s'abstraire de détails trop techniques (comme la gestion de la mémoire par exemple)).
XCB est en fait plus bas niveau que la Xlib puisqu'elle est au niveau protocolaire (protocole X). Ce qui fait donc qu'elle remonte à la surface la caractéristique asynchrone de X11 qui avait été trop longtemps cachée par la Xlib.
C'est pour cette raison qu'il faut écrire plus d'instructions pour faire la même chose avec une ou deux fonctions de la Xlib.
Par contre, je pense que XCB n'est pas à utiliser comme tel par un développeur d'IHM. C'est aux toolkits (Gtk+, Qt, ...) d'encapsuler XCB, ce qui fait que le développeur n'aura alors pas à modifier son code existant et qu'il pourra toujours se concentrer sur son IHM et pas sur des détails techniques de bas niveau.
La version de 2.0 de dotclear est une refonte de ce dernier et il y a des incompatibilités entre la version 2.0 avec celle 1.2. Apparemment, les feeds n'ont pas les même URI entre les deux versions, ce qui explique que ces derniers soient cassés lors de la migration.
On parle beaucoup de SCons comme l'alternative aux autotools ou autre CMake.
Je voudrais ici rendre à César ce qui appartient à César.
SCons est une implémentation en Python de ce qu'est Cons, lui écrit en Perl.
Cons est celui qui a proposé ce mécanisme de build. SCons n'a fait que reprendre son approche mais en Python (probablement en l'enrichissant aussi).
Voilà, c'est tout.
Le site web de Cons : http://www.dsmit.com/cons/
Bonne journée ...
Au contraire, les sociétés de service actuelles sont multi-compétentes et bien plus orientées vers la production finale que vers la maintenance et la vente de licence associées a des bibliothèques (pour le monde du libre en tout cas).
Tu as déjà travaillé dans une société de service ?
Parce que désolé mais la majorité des société de services en informatique actuellement ne sont que de *vulgaires* marchands de compétences, sans capitalisation sur ces dernières ; elles vendraient des canapés qu'elles ne s'en prendraient pas autrement. Elles ne valent pas mieux que les boites d'intérim. Il est commun de trouver un jeune sortie tout frais de l'école, qui coûte pas cher et qui, s'il a pratiqué un peu de J2EE (JEE) à l'école, est balancé chez le client comme expert J2EE ; les managers (si on peut appeler ça des managers) s'appuient sur sa conscience professionnelle pour qu'il assure tout seul et qu'il ferme sa gueule.
Le monde change ...
Oui, d'une société économique de production vers une société économique de service ou le paraître revêt encore plus d'importance, où le faux s'habille en vrai et où le vrai y paraît faux. (Il suffit juste d'observer ce que l'on appelle les consultants (à ne pas confondre avec les simples prestataires), les enfants perdus de ce type de société économique, pour y cerner la nature cachée de cette société.)
Note : bien sûr tout n'est pas si noir que ça. Mais jusqu'à présent, ces sociétés de production, mal adaptées selon toi à satisfaire le besoin du client final, étaient de celles qui encore capitalisaient sur les compétences des personnes. De plus, contrairement à ce que tu crois, les sociétés de services ne sont pas plus aptes à satisfaire le besoin du client final parce que justement elles ne savent pas capitaliser sur les compétences ni technique, ni métier (coûte trop cher). Peut être que ça changera, mais je suis sceptique.
[^] # 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é à -1.
J'utilise Maven au boulot, et je le vois surtout comme une surcouche à Ant.
Et pourtant, Maven n'est pas une surcouche à Ant, mais bien un outil à part entière. Maven est à une couche d'abstraction de plus haut niveau que celle de Ant et autres outils similaires dans la construction logicielle.
on reste toujours avec des fichiers XML qui ne sont pas fait pour écrire du code.
Oui, seulement Maven n'est pas pour écrire du code ;-)
Sinon, effectivement, l'usage du XML pour écrire le POM peut être pour certain considéré comme rébarbatif. Je ne suis moi même pas sûr que ce choix soit pertinent ; seulement, à l'heure du tout XML, bien que critiquable, je comprends le choix de celui-ci par les concepteurs de Maven.
Le fait de télécharger les dépendances à partir d'internet est aussi relativement gênant lorsque l'on travaille en local,
Ce qui est téléchargé de l'extérieur ce sont seulement les plugins ou dépendances qui ne sont pas présents dans le cache local (dépôt local). Une fois, téléchargés, seuls ceux présents dans le cache local sont pris en compte. Donc, au début, c'est lourd, mais après ça va très vite. De plus, l'usage de Maven dans de l'intégration continue m'est apparu plus facile qu'avec d'autres solutions.
la structure imposée n'est pas forcément la plus logique bien qu'elle convienne pour un certain nombre d'applications de gestion en J2EE
Là je ne suis pas d'accord. Que la structure plaise ou non est une chose. Elle a sa propre logique et, que l'on aime ou pas, elle est cohérente pour bcp types de projets, et pas essentiellement pour du J2EE/JEE. Elle a l'avantage de proposer une structure commune aux projets, ce qui fait que les développeurs n'ont pas à réapprendre de comment celui-ci est structuré, de comment sont gérées les dépendances, etc. (Oui, effectivement, il doit connaitre celui de Maven, mais cet acquis est capitalisable.)
Waf et les autotools possèdent cependant un concept similaire dans l'écriture du code: la configuration, la compilation, l'installation, la vérification (make distcheck), la distribution (make dist).
Oui, mais ça reste toujours des définitions de tâches qui sont pré-écrites dans les Makefile ou autres fichiers de build. L'enchaînement des tâches y doivent aussi être décrites. Dans Maven, l'accent est mis non plus sur les tâches, mais sur les phases d'écriture de code, Maven gérant le flot qui parcours les phases.
Pour ce qui est de la lourdeur du modèle de tâches et de dépendances, je pense qu'il s'agit surtout d'un problème de granularité, par exemple pour des projets en C on se retrouve avec des fichiers objets individuels (.o) alors qu'en java des répertoires entiers sont transformés en même temps, le compilateur java de sun faisant un optimisation globale (avec des fichiers inner class impossibles à prédire avant de compiler les fichiers).
Oui, d'accord. Mais je ne pense pas que ça empêche la création d'outil pour C/C++ similaires à Maven ; il faut prendre en compte je pense les particularités de cet environnement.
La diversité des outils et des compilateurs, c'est aussi ce qui fait la richesse des environnements de type Unix, et sur cet aspect
Oui, une certaine richesse. Et c'est justement la pauvreté d'outils de type Maven, cad d'outils de construction logicielle de plus haut niveau, que je trouve dommage. Probablement que c'est encore tôt.
Maven est un peu calqué sur le modèle Windows.
Hooo ! Et en quoi ?
# 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é à 1.
Or, depuis quelques année est apparue sur la plate-forme Java un remplacement à ce genre de système de construction de logiciels : maven.
http://maven.apache.org/
Pour ceux qui ne connaissent pas, maven est un système de construction de logiciel de plus haut niveau au sens où d'une part il impose une structure du projet et d'autre par il parcours différentes phases dans l'écriture de code : validate, compile, test, package, integration-test, install, deploy pour ne citer que quelques uns.
(Voir http://www.oqube.com/formations/maven/lifecycle.html pour une vision plus complète des phases.)
Il n'y pas plus la définition de tâches mais des plugins avec différentes cibles d'exécutions : un pour la compilation de code, un autre pour dérouler des tests, un pour archiver, etc. Chacun va s'exécuter dans une ou plusieurs phases selon son objectif.
Un autre avantage, et un gros, de Maven, est la gestion des dépendances : les dépendances en bibliothèques sont automatiquement téléchargées de dépôts maven sur le Web et intégrées dans les phases de compilation, de tests, etc. Les dépendances transitives sont aussi prises en compte. Ce qui est aussi intéressant, c'est que seul les plugins définis dans le POM (Project Object Model, le descripteur du projet), sont chargés (et récupérés du Web s'ils ne sont pas présents dans le cache local (un dépôt local)).
Malgré les défauts de Maven, après avoir travaillé avec aussi bien sur des petits que des plus gros projets, je ne reviendrais pas en arrière sur des systèmes de construction logicielle à la Ant ou Makefile ou Cons (dont SCons est un clone pour Python) ... Le principe de définition de tâches dans de tels systèmes peut devenir trop lourd avec de gros projets et de plus il faut soit même s'embêter à gérer les dépendances.
Il est dommage qu'il n'y ait pas encore de projet du style Maven pour gérer la construction logicielle pour la plate-forme C/C++ ou Python.
Sinon, il existe un concurrent à Maven : Raven, http://raven.rubyforge.org/
[^] # Re: Existent-il un projet OpenSource qui a été érit selon la méthode
Posté par Miguel Moquillon (site web personnel) . En réponse à la dépêche Coding Dojo à Grenoble. Évalué à 2.
Des logiciels complexes comme le noyau Linux ont été écrits sans la moindre méthodologie officielle (*), que ce soit Scrum, cycles-en-V, etc. Un programme, ça ne s'« ingénie » pas, ça ne s'usine pas : ça s'écrit.
D'abord, le noyau Linux a été développé selon une méthode même si celle-ci est propre aux développeurs du noyau et surtout propre à l'approche personnelle de Linus. Méthode qui d'ailleurs s'est raffinée au fur et à mesure des développements. C'est exactement l'approche des méthodes agiles ; la méthode utilisée est une méthode agile.
Ensuite, un programme s'écrit, certes, mais selon des techniques dites d'ingénierie, de la même façon que le projet dans lequel l'élaboration du programme se fait. Ainsi, par exemple, Scrum va t'aider en donnant des techniques dans la gestion de ton projet tandis que des approches comme XP ou TDD va te fournir des méthodes d'écriture de code te permettant d'atteindre une certaine qualité tout en maintenant une cohésion et une discipline d'équipe. De plus, afin de maintenir un code de qualité tout en maintenant une vélocité d'élaboration du programme, des outils comme l'intégration continue, les tests unitaires et d'intégration automatiques, des outils de contrôle de versions, le source control, etc. sont plus ou moins nécessaires et font partie ce que l'on appelle l'ingénierie logicielle.
La seule vertu de telles méthodologies, c'est de créer une discipline (notamment en entreprise, où le chef voit son autorité légitimée par l'autorité extérieure de la méthodologie). Mais à ce compte elles se valent probablement toutes, et les querelles de clocher ou de génération sont sans importance.
D'abord, le propre des méthodes agiles est l'auto-discipline et l'auto-organisation. Ce qui tranche en général des méthodes comme CMMi par exemple qui est malheureusement utilisée le plus souvent de la façon dont tu dis.
Ensuite, s'il existe une multitude de méthodes dites agiles, et qui émergent en partie du monde du logiciel libre, certaines sont plus connues sous des noms bien précis comme Scrum, Crystal Clear, etc. Or ces dénominations sont importants parce qu'ils permettent de mieux diffuser la connaissance (ce qui ce cache derrière ce nom) et ils permettent aussi de pouvoir les "vendre" à tes manageurs dans une entreprise ... et ça c'est important ; d'où d'ailleurs le buzz autour.
Derrière les méthodes agiles, je dirais que c'est une sorte de retour du contrôle des développeurs dans la façon dont s'écrivent les programmes, face à un raz bol de toujours payer les pots cassés du fait des décideurs ou manageurs qui n'ont de connaissance du développement logiciel que leur prétention d'y connaitre.
# Et ça se passe aussi en France, dans les coulisses
Posté par Miguel Moquillon (site web personnel) . En réponse au journal Selon une enseignante américaine, Linux ferait régresser nos enfants. Évalué à 10.
J'ai ensuite parcouru la traduction.
Malheureusement, contrairement à ce que semble croire le traducteur, en France aussi ça arrive mais on en entend pas parler (à part sur Framablog).
Et ce n'est pas qu'avec des enseignants, mais aussi avec des parents des associations parentales. Par exemple, l'année dernière, un père a été offusqué que des enfants de maternelle (oui de maternelle) aient eu un apprentissage de l'outil informatique (clavier / souris) avec des PC sous GNU/Linux ; son argument a été que dans la vie professionnelle, les ordinateurs sont équipés que de Windows et que donc il fallait que nos charmants bambins commencent à se familiariser avec cet environnement (sinon, vous vous rendez compte ma bonne dame, ils seront être exclus de la société avec de telles approches déviants !)
# Ressemble à ce que l'on peut faire avec seaside
Posté par Miguel Moquillon (site web personnel) . En réponse au journal AppJet : je suis sidéré. Évalué à 4.
Seaside est un framework de développement d'applications Web basé sur Smalltalk (et plus particulièrement sur Squeak).
Sa faculté est de pouvoir aussi développer et déboguer son appli via son navigateur web, le tout à chaud.
Ainsi, en installant simplement seaside sur un serveur distant et en codant rapidement un cadre de créations d'appli web avec, tu offres en peu de temps et surtout sans plomberie la possibilité à des personnes de créer leurs applis Web. L'intérêt est que tout est déjà quasiment prêt avec seaside et que les utilisateurs n'ont pas à connaitre des technos différentes que sont le JS, l'Ajax, le HTML, etc... ; il suffit de connaitre smalltalk et l'environnement de dév publié dans le navigateur.
# Il était une fois les langages fonctionnels ...
Posté par Miguel Moquillon (site web personnel) . En réponse au journal Sortie du livre Real World Haskell. Évalué à 4.
- les vieux langages reprennent du poil de la bête (Haskell, Erlang, ...)
- les langages impératifs introduisent des concepts fonctionnels,
- de nv langages fonctionnels apparaissent (Scala par exemple).
Et je pense que ceci est en grande partie dû à deux aspects :
- ce sont des langages d'assez haut niveaux qui permettent de répondre à des problématiques bcp plus complexes et de façon plus élégante que ne le peuvent actuellement les langages dîts impératifs,
- les architectures multi-corps et la progression de la programmation parallèle sur le marché ont mis en lumière les limites des outils actuels utilisés et basé sur une structure impérative et les facultés des langages fonctionnels dans le domaine.
Le tout évidemment combiné avec la monté en puissance des machines qui permettent de palier aux pb de perfs inhérents aux programmes fonctionnels (quoique lorsque l'on regarde un programme en Caml ...)
Ce qui est intéressant dans Haskell, c'est l'innovation que gravite autour. Il supporte ainsi non seulement le fonctionnel de second ordre, mais aussi, en quelque part, le typage du second ordre avec ses classes de type (un clin d'œil à la théorie F-Bound de Cook).
A côté de ceci, pour ceux qui veulent s'y exercer, il existe xmonad, un gestionnaire de fenêtres X en Haskell ; vous pouvez y lire un peu son code, jouer avec. Au début, je recommande de jouer d'abord avec la conf qui est écrite en Haskell et qui est compilée à la volé dès le démarrage ou le redémarrage du gestionnaire.
Sinon, je me suis acheté le bouquin sur Erlang de Joe Armstrong (Programming Erlang: Software for a Concurrent World) afin de m'amuser un peu plus avec ce langage (enfin, qd j'ai le temps, ce qui est de plus en plus rare ces temps-ci)
# OpenGoo peut être ton ami
Posté par Miguel Moquillon (site web personnel) . En réponse au journal Time tracker. Évalué à 1.
http://opengoo.org/
C'est une application web de gestion de travaux collaboratifs. A ce titre, il permet la gestion des tâches, des documents relatifs à ceux-ci, etc.
La gestion des tâches de l'outil répond à ton besoin puisque l'application calcule le temps pris par chaque individu dans une tâche (en calculant le temps passé sur celle-ci ; l'utilisateur indiquant le début et la fin de ses participations dans ladite tâche)
# ha souvenir souvenir
Posté par Miguel Moquillon (site web personnel) . En réponse à la dépêche Window Maker : projet relancé. Évalué à 3.
Il était facilement configurable avec wmprefs (que j'ai toujours préféré à wmakerconf), et son ergonomie et son graphisme était alléchant ! J'ai eu même l'occasion de jeter un coup d'oeuil sur son code et celui-ci était vraiment bien conçu et agréable à lire, malgré que ce soit du C.
Mais le temps a passé, et aujourd'hui j'utilise Fvwm (avec Fvwm-Crystal) à la maison et XMonad au boulot. (Note : je suis un peu bizarre parce que j'utilise Fvwm sur un portable tandis que XMonad tourne sur une ... station de bureau ! L'inverse aurait été plus logique, mais bon ...)
[^] # Re: Pourquoi ce langage?
Posté par Miguel Moquillon (site web personnel) . En réponse au journal Erlang Planet. Évalué à 1.
http://www.erlang.se/euc/05/1710OTPupdate.ppt
Comme quoi, faut toujours faire attention à ce que l'on nous dit ou aux interprétations que l'on pourrait avoir aux propos d'autrui.
[^] # Re: Pourquoi ce langage?
Posté par Miguel Moquillon (site web personnel) . En réponse au journal Erlang Planet. Évalué à 1.
J'ai découvert Erlang il y a peu de temps, et les personnes s'occupant de l'association disait que la VM multi-cpu allait sortir bientôt (c'était il y a 2 ou 3 ans maximum). La VM Erlang savait gérer plein de threads mais sur un seul processus physique.
Ok, la VM multi-proc d'Erlang (donc non OTP) existe apparemment depuis 2 à 3 ans. Néanmoins, OTP existe lui depuis 1996 et j'ai toujours entendu qu'OTP gérait les archi multi-procs ; mais peut-être que c'était de l'intox (je n'ai pas vérifié de moi même ceci).
Ici on a une idée des perfs :
http://shootout.alioth.debian.org/u32/benchmark.php?test=all(...)
C'est souvent 3 ou 4 fois plus lent que Java.
Quant aux perfs, ce qui est testé sont relatifs à des algo, c'est ce que j'appelle des perfs locales. Or, ce qui est intéressant dans une appli sont les perfs globales. Ainsi, on a souvent des surprises d'appli, pourtant écrites en C, qui se révèlent plus lourdes /à l'usage/ que les même mais écrites dans des langages de plus haut niveau (le design influe, mais pas seulement, sur les perfs globales).
[^] # Re: Pourquoi ce langage?
Posté par Miguel Moquillon (site web personnel) . En réponse au journal Erlang Planet. Évalué à 1.
La performance signifie aussi 'temps d'exécution /globale/ du code' dans une appli et le débit de traitement des requêtes (et le design joue bcp ici). Et à ce niveau, Erlang n'a pas à rougir. (Bien sûr, il existe des plate-formes plus performantes qu'Erlang.)
Quand à la gestion multiprocesseur, elle existe au plus depuis OTP, donc depuis 1996. Il est probable qu'elle existait déjà dans le langage avant, mais je n'ai pas d'info là dessus.
Il y a un peu d'info ici : http://www.ericsson.com/technology/opensource/erlang/
[^] # Re: Agrégateur Erlang
Posté par Miguel Moquillon (site web personnel) . En réponse au journal Erlang Planet. Évalué à 2.
Voir à ce sujet l'échange de mails avec Alan Kay au sujet de la POO :
http://discuss.joelonsoftware.com/default.asp?design.4.48554(...)
ou
http://www.purl.org/stefan_ram/pub/doc_kay_oop_en
(je ne comprend pas, l'accès direct à cet URL me donne une erreur 403 alors qu'en passant par Google, je n'ai pas de problème : http://www.google.fr/search?hl=fr&client=firefox-a&r(...)
et sa phrase :
"OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them"
[^] # Re: Agrégateur Erlang
Posté par Miguel Moquillon (site web personnel) . En réponse au journal Erlang Planet. Évalué à 1.
Il faut voir à ce sujet SCOOP (Simple Concurrent Object-Oriented Programming). Dans cette approche, à chaque objet est associé un thread dans lequel est exécuté chaque appel de méthodes. Si la méthode est de type requête (retour de valeur) alors la méthode est synchrone, sinon elle est asynchrone. De plus, comme dans Ada, des conditions d'entrée peuvent être définies au niveau des méthodes ; si la condition n'est pas respectée, l'appel de la méthode est mise en attente jusqu'à ce qu'elle soit remplie. Ainsi, comme les changements d'états sont en rétention dans l'objet, il n'y a pas d'effet de bord ou de changement d'état entre threads !
[^] # Re: Pourquoi ce langage?
Posté par Miguel Moquillon (site web personnel) . En réponse au journal Erlang Planet. Évalué à 6.
Or, les architectures de nos PC ont basculé il y a 1 à 2 ans vers les multi-coeurs et cette tendance va en s'accélérant. Le problème est alors posé aux langages de programmation actuels : on passe d'une approche séquentielle vers une approche parallèle. Et voilà où actuellement le bas blesse : les langages impératives actuels ne sont pas adaptés à cette approche. Il en résulte alors deux tendances :
- récupérer des techniques et des concepts issues des langages fonctionnelles pour les introduire dans les langages impératives existants,
- sortir de nouvelles API sur les aspects du parallélisme
C'est ce que l'on observe avec C# (premier point) et Java (second point) par exemple.
En attendant, des langages comme Erlang répondent déjà à ce genre de problématique et ont fait leur preuve. C'est pourquoi celui-ci reprend du poil de la bête.
Par exemple, sur la plate-forme Java est apparue le langage fonctionnel scala qui prend lui aussi de l'ampleur.
Alors, que sera le 21e siècle : encore impérative avec tout un tas de hacks pour faciliter tant bien que mal la programmation parallèle ou finalement fonctionnelle dont l'approche permet de répondre élégamment à ce type de programmation ?
# PUT -> remplacement ou création d'une ressource
Posté par Miguel Moquillon (site web personnel) . En réponse au journal Éditer une ressource HTTP. Évalué à 2.
Ensuite, il me semble que le premier navigateur Web, celui utilisé par Tim Berners-Lee (le créateur du Web), et qui tournait sur NextStep, permettait de mettre à jour une ressource Web : la représentation de la ressource Web (en HTML) dans le navigateur était directement éditable. Par besoin donc de formulaire pour ce faire.
Après, il reste le problème de l'autorisation de modification de ressources Web ...
# Le lycée et les sciences
Posté par Miguel Moquillon (site web personnel) . En réponse au journal Les sciences, la France et le nouveau lycée. Évalué à 2.
Par contre, par mon expérience, j'ai pu constater que l'accroche de l'élève à la science enseignée dépendait de beaucoup du professeur. A côté de ceci, et pour donner raison à certains ici, j'ai pu constater aussi un enseignement parfois débile non à cause du prof mais surtout du fait du programme limite farfelue ; en mémoire me vient les transistors en Terminal C alors que finalement on n'avait eu aucune préparation nécessaire pour justement appréhender ce programme. Mais voilà, c'était demandé par le programme ! Du grand n'importe quoi.
Toutefois, une chose est sûr, même si l'enseignement des sciences est loin d'être parfaite, (de toute façon l'enseignement en lui même n'est pas une science exacte et relève à mon avis plus de l'expérimentale), il est nécessaire parce qu'il nous donne les armes qui nous permettrons de mieux appréhender notre monde ; et ceci d'autant plus à notre époque qui s'inscrit dans une ère technologique. De plus, sans enseignement des sciences, comment les élèves vont pouvoir savoir que ça les intéresse ou que c'est peut-être leur voie ?
[^] # Re: Xmonad et awesome.
Posté par Miguel Moquillon (site web personnel) . En réponse à la dépêche awesome 3 : premier gestionnaire de fenêtres basé sur XCB. Évalué à 1.
Je le fais aussi. Ce que j'aimerai, c'est de pouvoir aussi taguer la fenêtre (extension XMonad.Actions.TagWindows).
Sinon, pour déplacer la fenêtre, au lieu de
doF (W.shift "2:mail")tu peux écrire aussi :
doShift "mail"# Xmonad et awesome.
Posté par Miguel Moquillon (site web personnel) . En réponse à la dépêche awesome 3 : premier gestionnaire de fenêtres basé sur XCB. Évalué à 1.
Ce que j'aime bien de cet environnement est sa légèreté, sa facilité de conf (même si on ne connaît pas trop Haskell), et le tiling. Ha et aussi qu'il est écrit en Haskell, un langage de de haut niveau et de qualité, ce qui permet des évolutions et des corrections de bogues rapides et d'écrire soit même rapidement des choses (la contre partie est la courbe d'apprentissage de haskell).
Sinon, il m'a fait découvrir le syst. de tags et je trouve ça vachement sympa ; dommage que je n'ai pas encore trouvé comme attribuer un tag à une fenêtre applicative précise au démarrage de celle-ci.
J'ai remarqué que le système de tag semble plus intégré et abouti dans awesome. Faudra que je l'essai un jour. Dommage qu'il soit écrit tout en C (mais comme il propose un framework de dév, il propose probablement des fonctions de haut niveau pour s'abstraire de détails trop techniques (comme la gestion de la mémoire par exemple)).
[^] # Re: XCB
Posté par Miguel Moquillon (site web personnel) . En réponse à la dépêche awesome 3 : premier gestionnaire de fenêtres basé sur XCB. Évalué à 3.
C'est pour cette raison qu'il faut écrire plus d'instructions pour faire la même chose avec une ou deux fonctions de la Xlib.
Par contre, je pense que XCB n'est pas à utiliser comme tel par un développeur d'IHM. C'est aux toolkits (Gtk+, Qt, ...) d'encapsuler XCB, ce qui fait que le développeur n'aura alors pas à modifier son code existant et qu'il pourra toujours se concentrer sur son IHM et pas sur des détails techniques de bas niveau.
[^] # Re: C'est pas ma faute à moi
Posté par Miguel Moquillon (site web personnel) . En réponse au journal Mise à jour de mon p'tit blog. Évalué à -1.
Mais si tu veux le faire pour moi, je suis receveur :-D
[^] # Re: À l'encontre ?
Posté par Miguel Moquillon (site web personnel) . En réponse au journal Mise à jour de mon p'tit blog. Évalué à 0.
[^] # Re: Je ne peux pas m'abonner...
Posté par Miguel Moquillon (site web personnel) . En réponse au journal Mise à jour de mon p'tit blog. Évalué à -1.
Mea culpa.
Le voici : http://myblog.moquillon.free.fr
(Sinon, en fait, sur le site web perso, il suffit d'aller sur mes pages perso puis de cliquer sur 'Mon blog' dans le menu.)
[^] # Re: C'est pas ma faute à moi
Posté par Miguel Moquillon (site web personnel) . En réponse au journal Mise à jour de mon p'tit blog. Évalué à 0.
# Cons
Posté par Miguel Moquillon (site web personnel) . En réponse à la dépêche SCons 1.0. Évalué à 9.
Je voudrais ici rendre à César ce qui appartient à César.
SCons est une implémentation en Python de ce qu'est Cons, lui écrit en Perl.
Cons est celui qui a proposé ce mécanisme de build. SCons n'a fait que reprendre son approche mais en Python (probablement en l'enrichissant aussi).
Voilà, c'est tout.
Le site web de Cons : http://www.dsmit.com/cons/
Bonne journée ...
[^] # Re: et si c'etait bon signe
Posté par Miguel Moquillon (site web personnel) . En réponse au journal Après Business Objects, Ilog se fait racheter.. Évalué à 10.
Au contraire, les sociétés de service actuelles sont multi-compétentes et bien plus orientées vers la production finale que vers la maintenance et la vente de licence associées a des bibliothèques (pour le monde du libre en tout cas).
Tu as déjà travaillé dans une société de service ?
Parce que désolé mais la majorité des société de services en informatique actuellement ne sont que de *vulgaires* marchands de compétences, sans capitalisation sur ces dernières ; elles vendraient des canapés qu'elles ne s'en prendraient pas autrement. Elles ne valent pas mieux que les boites d'intérim. Il est commun de trouver un jeune sortie tout frais de l'école, qui coûte pas cher et qui, s'il a pratiqué un peu de J2EE (JEE) à l'école, est balancé chez le client comme expert J2EE ; les managers (si on peut appeler ça des managers) s'appuient sur sa conscience professionnelle pour qu'il assure tout seul et qu'il ferme sa gueule.
Le monde change ...
Oui, d'une société économique de production vers une société économique de service ou le paraître revêt encore plus d'importance, où le faux s'habille en vrai et où le vrai y paraît faux. (Il suffit juste d'observer ce que l'on appelle les consultants (à ne pas confondre avec les simples prestataires), les enfants perdus de ce type de société économique, pour y cerner la nature cachée de cette société.)
Note : bien sûr tout n'est pas si noir que ça. Mais jusqu'à présent, ces sociétés de production, mal adaptées selon toi à satisfaire le besoin du client final, étaient de celles qui encore capitalisaient sur les compétences des personnes. De plus, contrairement à ce que tu crois, les sociétés de services ne sont pas plus aptes à satisfaire le besoin du client final parce que justement elles ne savent pas capitaliser sur les compétences ni technique, ni métier (coûte trop cher). Peut être que ça changera, mais je suis sceptique.