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.
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 …
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 :)
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.
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.
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, …
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.
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 :)
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
[^] # Re: Un logiciel reste un produit
Posté par laurent laffont (site web personnel) . En réponse au journal Un logiciel libre devient-il meilleur qu'un logiciel propriétaire dans la durée ?. Évalué à -7.
Je n'ai rien compris …
# Un logiciel reste un produit
Posté par laurent laffont (site web personnel) . En réponse au journal Un logiciel libre devient-il meilleur qu'un logiciel propriétaire dans la durée ?. Évalué à -10.
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.
[^] # Re: Changement
Posté par laurent laffont (site web personnel) . En réponse à la dépêche Sortie de Bokeh 7.10. Évalué à 1.
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é.
[^] # Re: mouais
Posté par laurent laffont (site web personnel) . En réponse à la dépêche Sortie de Bokeh 7.8. Évalué à 3.
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.
[^] # Re: merci pour la dépêche
Posté par laurent laffont (site web personnel) . En réponse à la dépêche Sortie de Bokeh 7.8. Évalué à 3.
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 …
[^] # Re: Excellent!
Posté par laurent laffont (site web personnel) . En réponse à la dépêche Nouveau logiciel libre de gestion d'une bibliothèque: Alessandria. Évalué à 2.
Il y'a le catalogue de la BNF http://catalogue.bnf.fr/index.do
[^] # Re: Retour d'expérience webmaster
Posté par laurent laffont (site web personnel) . En réponse à la dépêche Sortie de la version 7.4 de Bokeh. Évalué à 2.
Pour les rédacteurs, on suggère généralement d'écrire les articles directement côté front sans passer par le backend.
[^] # Re: Retour d'expérience webmaster
Posté par laurent laffont (site web personnel) . En réponse à la dépêche Sortie de la version 7.4 de Bokeh. Évalué à 4.
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 :)
[^] # Re: Data mining
Posté par laurent laffont (site web personnel) . En réponse à la dépêche Sortie de Pharo et de son environnement de développement en version 4.0. Évalué à 2.
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
[^] # Re: Emacs
Posté par laurent laffont (site web personnel) . En réponse au journal {éditeurs de texte, IDE} × {généralistes, spécialisés}. Évalué à 3.
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
Posté par laurent laffont (site web personnel) . En réponse au journal [Trolldi] Le langage plus approprié pour écrire des applications graphiques multiplateformes. Évalué à 1.
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.
# Développement piloté par le debugger
Posté par laurent laffont (site web personnel) . En réponse au journal Un debugger est-il indispensable ?. Évalué à 4.
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 => Smalltalk
Posté par laurent laffont (site web personnel) . En réponse à la dépêche Congrès FOSDEM 2013. Évalué à 1.
Smalltalk signifie "bavardage", en un seul mot.
[^] # Re: Serveur web
Posté par laurent laffont (site web personnel) . En réponse au journal emacs - l'innovation qui marche au poil. Évalué à 5.
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, …
[^] # Re: Super idée
Posté par laurent laffont (site web personnel) . En réponse au message NML Code Retreat, Haute-Savoie, 26-28 mai, Haskell, Smalltalk, Clojure. Évalué à 1.
je tenterai le journal dans quelques jours
[^] # Re: Une autre vidéo
Posté par laurent laffont (site web personnel) . En réponse à la dépêche Pharo 1.4 — nouvelle version d'un Smalltalk libre. Évalué à 1.
Plus de détails ici sur Pharocasts. Signé: la moule ;)
[^] # Re: Merci
Posté par laurent laffont (site web personnel) . En réponse à la dépêche Pharo 1.4 — nouvelle version d'un Smalltalk libre. Évalué à 5. Dernière modification le 21 avril 2012 à 10:43.
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
# Scripting
Posté par laurent laffont (site web personnel) . En réponse à la dépêche Tomate : une petite applet de productivité pour Linux. Évalué à 2.
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.
[^] # Re: Savoir choisir, plutôt que se restreindre
Posté par laurent laffont (site web personnel) . En réponse au journal Programmation : la complexité c'est le mal. Évalué à 1.
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.
[^] # Re: Et Pharo par l'exemple ?
Posté par laurent laffont (site web personnel) . En réponse à la dépêche Pharo 1.2. Évalué à 1.
:)
[^] # Re: Et Pharo par l'exemple ?
Posté par laurent laffont (site web personnel) . En réponse à la dépêche Pharo 1.2. Évalué à 1.
Diffusable non.
Mais si tu clones le repository il y a un PBE1.pdf compilé.
[^] # Re: Et Pharo par l'exemple ?
Posté par laurent laffont (site web personnel) . En réponse à la dépêche Pharo 1.2. Évalué à 1.
Je ne sais pas vraiment mais les sources sont ici: https://github.com/SquareBracketAssociates/PharoByExample-french
[^] # Re: Processus de développement
Posté par laurent laffont (site web personnel) . En réponse à la dépêche Pharo 1.2. Évalué à 3.
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 :)
[^] # Re: Vendredi?
Posté par laurent laffont (site web personnel) . En réponse à la dépêche Pharo 1.2. Évalué à 2.
La migration vers Jenkins est prévue.
[^] # Re: difference avec Squeak ?
Posté par laurent laffont (site web personnel) . En réponse à la dépêche Pharo 1.2. Évalué à 3.
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.