laurent laffont a écrit 67 commentaires

Je n'ai rien compris …

Pour moi un logiciel devient meilleur lorsqu'une entité (un-e développeur-se, une équipe, une entreprise, …) arrive à écouter des besoins que des utilisateurs-rices ont réussi à formaliser. Si l'utilisateur-rice développe le logiciel pour lui/elle-même, cela facilite vraisemblablement les choses. Il se peut que le logiciel (en libre) intéresse d'autres personnes, encore faut-il (et cela constitue un énorme obstacle) que ces autres personnes aient connaissance de ce logiciel et qu'elles savent que ça peut les aider (ce qui implique la description, la diffusion et la communication autour du logiciel).

La gratuité facilite la diffusion (libre ou pas).

Comment un logiciel peut s'améliorer dans le temps ? Plus de besoins exprimés (ce qui n'est pas forcément synonyme de plus d'utilisateurs-rices) et plus de besoins implémentés (ce qui n'est pas forcément synonyme de plus développeur-ses).

De là, est-ce qu'on peut dire qu'un logiciel libre devient forcément meilleur qu'un logiciel propriétaire ? Cela dépend surtout des gens qui travaillent derrière, des gens qui l'utilisent, … La seule chose viable me semble qu'un logiciel libre se perd plus difficilement qu'un logiciel propriétaire.

Actuellement il n'y a pas d'option pour choisir l'agencement du formulaire. Ceci dit la prochaine version majeure (dans 6 mois) devrait contenir un développement permettant aux administrateurs de composer des formulaires d'articles selon les besoins des rédacteurs. Cela permettra d'avoir des formulaires de rédaction taillés sur mesure selon le type d'article rédigé.

J'ai l'impression qu'il y a amalgame entre Bokeh et les prestations d'hébergement.

Bokeh est un logiciel logiciel "ouvert" dont le code source est publié et sous licence AGPL3. Tu peux l'installer sur ton serveur, modifier le code PHP, HTML, JS, forker, etc …. donc à ce niveau là pas de soucis je suppose. Par exemple la Médiathèque de Montrouge (qui contribue au développement de Bokeh) utilise ses propres serveurs pour justement avoir la main sur tout le code (et ce n'est pas la seule).

Une autre solution est de passer par un prestataire pour l'hébergement, comme AFI, Waterbear ou bien Bibliossimo. Ce prestataire peut autoriser plus ou moins d'accès à la modification du code source qu'il héberge selon les besoins du client, les coûts de service et de maintenance.

Ceci dit côté AFI, tu peux créer ton skin où tu pourra surcharger n'importe quelle vue, l'héberger sur le gitlab dédié et le synchroniser sur l'hébergement mutualisé. Certes c'est un usage avancé mais possible.

Pour le site de démonstration nous avons corrigé le lien (merci du signalement), voici le lien correct.

Bokeh est à la fois un OPAC et un CMS. Le public principal visé sont les médiathèques et leurs abonnés. Certes il peut y avoir du streaming de vidéo, mais on est bien loin de BitChute …

Il y'a le catalogue de la BNF http://catalogue.bnf.fr/index.do

Pour les rédacteurs, on suggère généralement d'écrire les articles directement côté front sans passer par le backend.

Pour tenter de clarifier:

Historiquement Bokeh constituait un OPAC qui a intégré au fur et à mesure des fonctionnalités CMS, et non le contraire. Alors oui pour un webmaster qui a l'habitude de travailler avec Drupal / Joomla / … pour publier des articles, on fait un bon en arrière. L'agrégation de contenu, catalogues et indexation restent les fonctions centrales de Bokeh, avec des fonctionnalités de CMS, mise en page, communication, … qui évoluent au fur et à mesure des besoins des projets.

L'histoire des URLs doublées dépend de l'hébergement en production, les sites sont migrés au fur et à mesure. Bokeh permet en partie de générer des URLs propres. Ex: http://mediatheques.valenceromans.fr/agenda

Biblibre n'est pas propriétaire d'AFI. Ceci dit les deux entreprises travaillent sur des projets communs. Et Bokeh est un logiciel libre (donc non propriétaire).

Bokeh 7.5.x est une branche de développement, chacun de nos clients à la possibilité d'utiliser la branche stable (ici 7.4.x) ou de développement (ici 7.5.x). Pour le responsive, cela nécessite aussi d'adapter la charte graphique si elle n'a pas été conçue dans ce sens à la mise en place du site.

L'interface admin est en cours de refonte, une première version devrait arriver dans les prochaines semaines. Tout retour et coup de main sont acceptés :)

Moose permet l'exploration et l'analyse de données. Quelques liens:
- analyse de données depuis une base PostGreSQL: https://www.youtube.com/watch?v=BtfgK7Wcx5o&list=PL4actYd6bfnyq0hwxV9XB_BVDAlzO-6Oq
- exploitation de données OpenStreetMap: https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/OpenStreetMap/0306-OpenStreetMap.html
- analyse de code: http://www.themoosebook.org/book/externals/visualizations/system-complexity

Pour moi le gros avantage d'Emacs est qu'on peut le spécialiser facilement pour le projet sur lequel on travaille et ainsi gagner énormément de temps. C'est un environnement "plastique" et à part les environnements Smalltalk je n'ai pas trouvé d'IDE aussi malléable.

Pharo est multi-plateforme, Morphic tourne partout, avec de jolis modèles de description comme Magritte ( https://vimeo.com/68166920 ) qui permettent de générer la même interface en desktop et HTML5. Il y'a même des bindings GTK / Cocoa ( http://www.youtube.com/watch?v=IRdBHfq1oNk ) et surtout un super environnement de dev.

Tous les debugger ne sont pas lourd. Certains sont même au coeur du système et le rapport change. Je pense notamment à Smalltalk qui inscrit le debugger dans le processus de développement (ex: http://www.pharocasts.com/2010/08/see-how-to-get-data-from-url-parse-xml.html ), même en TDD (ex: http://www.pharocasts.com/2010/07/live-testing-with-autotest.html ).

Du coup le debugger améliore la productivité et ne s'utilise pas seulement lorsque quelque chose va mal.

Malheureusement la très grande majorité des environnements de développement ont un debugger lourd, limité parce que le langage rend difficile leur implémentation.

Smalltalk signifie "bavardage", en un seul mot.

Parce que Lisp était là avant Unix. Parce que dans cette vision le système d'exploitation multi-processus-multi-langages n'existait pas vraiment. Il y avait les machines Lisp et les machines Smalltalk, qui sont des mondes à eux seuls. Je vois Emacs/Lisp comme le pendant texte de Pharo/Smalltalk avec leurs debuggers, leurs packages, extensibles dynamiquement, …

je tenterai le journal dans quelques jours

Plus de détails ici sur Pharocasts. Signé: la moule ;)

Concernant le gestionnaire de version il s'agit de Monticello. Il est décentralisé et supporte plusieurs types de dépôts (système de fichier, FTP, HTTP,…). Il est particulier dans le sens que Pharo Smalltalk ne travaille pas directement avec des fichiers, seulement des objets. A l'utilisation, cela ne fait pas beaucoup de différence, les outils graphiques aidant.

Historiquement les projets sont partagés via SqueakSource. Il est maintenant préférable d'utiliser SqueakSource3. SmalltalkHub, un nouveau gestionnaire de projets, moderne, est en cours de finition.

Un backend git / github est aussi en cours de réalisation via le projet Cypress.

Kent Beck a écrit son premier framework de tests unitaires type xUnit en Smalltalk (SUnit), donc on peut dire qu'il y a de l'expérience dans le monde Smalltalk :) L'avantage de Pharo est que lorsqu'on exécute un test sur des objets / méthodes inexistantes, le debugger nous assiste (création des classes et méthodes à la volée), ce qui permet d'aller vite. Voir cette vidéo sur SUnit, une autre avec Autotest

Si quelqu'un connait une Tomate sous Linux qui permet de scripter les messageries instantanées comme ceci http://magaloma.blogspot.com/2011/04/pomodoro-scripts.html , je prends.

Je préfère restreindre.

C'est ce que fait Smalltalk, la syntaxe tiens sur une carte postale et c'est extrêmement puissant.

Même pas de if, tout est objet, je reste impressionné par l'élégance et la simplicité des designs qu'on peut trouver.

:)

Diffusable non.

Mais si tu clones le repository il y a un PBE1.pdf compilé.

Je ne sais pas vraiment mais les sources sont ici: https://github.com/SquareBracketAssociates/PharoByExample-french

Le partage des sources peut se faire soit - via une plateforme comme SqueakSource http://squeaksource.com/ et bientot SmalltalkHub http://nicolas-petton.fr/2011/04/06/smalltalkhub-beta-in-a-week.html - soit via un serveur FTP / Webdav ou de fichiers, Monticello lui-même assurant la gestion du versionning

Pour monter son Hudson/Jenkins pour Pharo: https://github.com/renggli/builder

Pharo intègre un système de package (Monticello) ainsi que la gestion de dépendances entre packages (Metacello) avec versions symboliques (#stable, #development, ...). Ce qui permet de contrôler la mise à jour d'une image en production.

Une excellente source d'informations est la mailing-list pharo-dev :)

La migration vers Jenkins est prévue.

Au passage PharoCore 1.2 intègre une preview de SimpleMorphic en vue de baser l'UI sur ce framework. SimpleMorphic viens de Cuis http://www.jvuletich.org/Cuis/Index.html

D'ailleurs dans la dernière release note http://www.jvuletich.org/Cuis/CuisReleaseNotes.html:

Super fast Morphic world display.

About ten times faster when many windows are open.
Makes the whole UI feel much more responsive.
Simpler code