JuliaLang, dont la page principale montre quelques tests récents (avec V8 et C; C++ comme référence)
Au final V8 est en moyenne peut-être cinq fois plus lent que C++ pour une consommation mémoire relativement importante (mais en deçà de Java). À ma connaissance, dans les langages dynamiquement typés, seul LuaJIT est capable de battre cette prouesse. Dommage que Pypy ne fasse plus partie du shootout.
Il existe une procédure de mise à jour. J'ai entendu que ça se passait en général bien. Cela dit, je ne l'ai pas expérimenté personnellement (j'ai la réinstallite aigüe, mais je me soigne).
Posté par Yakulu .
En réponse à la dépêche OpenSUSE 12.3.
Évalué à 3.
Dernière modification le 15 mars 2013 à 12:03.
Je ne connais pas vraiment la politique de Novell sur les distributions à support payant. En revanche, pour le projet openSUSE :
la politique par défaut est de supporter deux versions + 2 mois, donc en théorie 18 mois de support après la sortie.
il existe un projet communautaire, Evergreen, qui étend ce support. Les versions 11.2 et 11.4 sont actuellement maintenues. Le support court sur environ deux années supplémentaires. Par exemple la 11.4, sortie en mars 2011, bénéficiera du support Evergreen jusqu'à en juillet 2014. J'imagine que la 12.3, dernière de la série 12, finira par être supportée par Evergreen.
Pour ceux que ça intéresse, il existe aussi le projet Tumbleweed, qui permet d'avoir une openSUSE en publication continue ( rolling-release ).
En dehors du fait que votre plateforme soit libre, vous n'en dîtes pas beaucoup :
gauche d'auteur : aucune, standard, forte (il est sans doute possible de ne pas trop influencer la licence des logiciels utilisés via une exception FOSS)
clause prenant en compte les brevets logiciels
considération que l'exécution à travers le réseau est une distribution
Peut-être Elveos ?
Malheureusement, l'équipe a du se désengager en début d'année.
Quant à l'idée, elle me parait plutôt bonne, moyennant le plus difficile point AMHA : atteindre une masse critique de projets l'employant. Et tu touches un point important : beaucoup de projets souhaitent avoir leur liste de tâches sur leur système de gestion de projet. Travailler sur une intégration forte avec pas mal de solutions existantes me parait dans ce cas très important.
En fait, toute la difficulté vient de la notion de travail dérivé. Pour la FSF, il semble que ce type d'emploi (une bibliothèque dynamiquement liée ?) soit admis comme formant un travail dérivé. Dans ce cas, l'AGPL considérant l'exécution à travers le réseau comme une distribution, l'ensemble de l'application devrait bel et bien être fournie aux utilisateurs sous la même licence.
pkgin, qui a commencé à faire parler de lui en 2009, est utilisé sous NetBSD, DragonFly.
Sous FreeBSD, plus récemment, la suite pkg(ng) dont la v1 est arrivée il y a un peu plus d'un mois. Peut-être encore un peu jeune mais très prometteur.
Il ne s'agirait pas plutôt d'un backport ?
Il semble que ce soit pour Ubuntu LTS ou pour Debian stable, il y ait aujourd'hui les noyaux 3.4 disponibles.
C'est sans doute une erreur de ma part. Il semble en effet que Clover Trail soit prévu pour les tablettes, alors qu'il s'agit de Clover Trail+ pour les smartphones, comme le disait reno dans son commentaire plus haut.
Et bien c'est plutôt une bonne nouvelle si un logiciel libre existant répond aux contraintes citées plus haut ainsi qu'à une bonne partie du cahier des charges. Y a-t-il un lieu avec des informations sur l'outil ?
Je contacte avec l'association dans la foulée, merci.
Merci pour les encouragements et déjà pour les questions, qui m'ont permis d'expliquer plus en détails le projet.
La seule chose qui me fasse tiquer (mais bon, il y a un ORM, et c'est sans doute lié à l'objectif de portabilité ultime), c'est sqlite.
Alors en effet, Peewee permet d'utiliser SQLite, MySQL et Postgre. En dehors de l'avantage sur la portabilité et le peu de configuration nécessaire, je trouve que SQLite est un très bon moteur dans de nombreux cas. Je l'ai déjà utilisé en prod avec succès. On lui reproch(ait) souvent trois choses :
son défaut de certaines fonctionnalités importantes, comme les contraintes référentielles
son verrou sur toute la base de données en écriture
en Python, le pilote inclus n'est pas par défaut thread-safe
Je vais peut-être dire des bêtises - dans ce cas, surtout arrêtez-moi - mais :
concernant le premier point, SQLite le supporte depuis la 3.6.19.
pour le second, le verrou ne devient important que si le volume de requêtes est élevé, ce qui ne devrait pas être le cas ici (même sur une grosse structure, nous n'atteindrons pas plusieurs centaines d'écritures par seconde). Plusieurs contournements existent cependant, bien que je n'ai pas eu à les tester : utiliser plusieurs bases et les lier lors des requêtes qui en ont besoin, utiliser le module asynchrone…
Peewee, entre autres, répond au problème via threadlocals.
Cela dit, ce sont des fonctionnalités avancées de la base qui seront à jauger le moment venu. La montée en charge devrait par défaut se faire en migrant vers un moteur plus adapté.
PPS: dès que vous avez un github/bitbucket/repo autre, faites-le savoir !
A priori, il y aura un Trac avec les sources comme premier lieu de la gestion du projet, un accès HTTP au dépôt (Mercurial), plus un miroir Github (via HG-GIT).
PS: (au passage, il y a un lyonnais dans mon enseigne (majerti) - j'ose faire ma pub)
HS : le monde est petit, je suis allé visiter votre site ce matin, depuis celui de la PyCon Fr.
Quelle forme économique et technique prendra le développement du logiciel ? Qui est-ce qui développera, pour quel prix, et avec quelles techniques ? Comment l'hébergement sera-t-il proposé ?
Je suis la personne qui va développer la solution. Je suis lyonnais et fais partie d'une coopérative d'activités et d'emploi.
En réalité, si l'annonce n'est pas précise concernant les objectifs fonctionnels - ce n'est pas le but -, il s'agit de davantage qu'un outil de gestion d'adhérents.
Sans rentrer dans les détails, l'outil veut également donner la possibilité aux structures de gérer :
leurs contacts (penser aux responsables d'ateliers, à la presse, aux élus etc)
les activités qu'elles proposent (évènements réguliers ou temporaires, inscriptions, tarifs…)
le partage de documents, la notion de pièces jointes
l'envoi de messages à tous, aux membres d'une activité, aux responsables, à l'équipe..
la sortie d'états pré-définis et la possibilité d'en créer
Le cahier des charges n'est pas finalisé et ne le sera que lorsque plusieurs structures y auront participé.
Ce projet est une spécialisation d'un projet plus large sur lequel je travaille, destiné aux associations de petite à moyenne taille : un outil souhaité participatif, c'est à dire non seulement pour le bureau mais aussi pour tous les adhérents voire les sympathisants. Il y est prévu de pouvoir s'organiser en groupe, de gérer ses rencontres et réunions, de communiquer directement sur l'outil, de pouvoir faire part de ses compétences et disponibilités…
L'application sera en mode Web, point que je pourrais débattre ici. Je ne suis pas de ceux qui prônent l'emploi du Web partout et je trouve que les applications clientes dites lourdes conservent bien des avantages. Néanmoins, lorsque l'on s'adresse à un large public de non techniciens, le mode Web est parfois, à mon avis, incontournable.
Les contraintes auto-imposées de l'application sont les suivantes :
l'accessibilité : l'outil devra pouvoir fonctionner pour le plus large public possible
la simplicité : le logiciel sera destiné à un public de non informaticiens; il écoutera donc ses utilisateurs à propos de son ergonomie. Si le spectre de fonctionnalités visé peut paraître large, le but est de proposer des choses simples. On ne fera clairement pas le café (il ne s'agit pas de réécrire un groupware d'entreprise)
le déploiement en quelques clics : l'outil devra pouvoir être déployé via un simple [pip install](http://www.pip-installer.org) sous UNIX, via un installateur à assez court terme sous Windows. Il devra fonctionner y compris sur une machine d'il y a une dizaine d'années. L'objectif est de permettre à des associations sans compétences avancées en informatique et dotée de peu de moyens de l'installer et de l'utiliser.
Le financement octroyé par le conseil régional représentera en ce qui me concerne entre un tiers et la moitié du coût de développement (base SMIC, et je ne compte pas la veille et la R&D).
Le modèle économique est encore à définir; mais il devrait être assez classique pour un éditeur de logiciel libre :
proposer une offre sur Internet pour ceux qui ne souhaitent pas l'outil en local
proposer l'installation, la configuration sur place
assurer la maintenance (mise à jour de l'outil etc), le support, notamment téléphonique
formation sur l'outil
développement sur mesure de fonctionnalités non prévues
enfin, si l'effort est important, le coût de la migration des données dont dispose la structure
Je rappelle qu'en tant que projet libre, une structure pourra choisir de gérer elle-même tous ces aspects, et pourra bien entendu faire appel à un autre prestataire.
La plateforme sélectionnée côté serveur est la suivante : Python2, le framework Flask et l'ORM Peewee.
Voilà les raisons de ce choix :
Python est le meilleur compromis pour remplir les contraintes citées ci-dessus. Il dispose d'un serveur Web inclus tout à fait capable (CherryPy est sinon un serveur pur Python, portable doué pour de la mise en production). Il inclut le moteur de base de données SQLite. Quant au langage lui-même, avec le framework et l'ORM sélectionnés, l'objectif de performances (déploiement sur une vieille machine) devrait être rempli. Enfin, plusieurs outils existent pour empaqueter une application Python dans un exécutable (objectif de déploiement facile).
Python est un langage qui continue sa lente ascension. Il s'agit d'un des
langages les plus populaires si j'en crois les statistiques glanées ça et là. Il jouit d'une solide réputation et de beaucoup d'utilisateurs dans la communauté du libre, ce qui est un bon point (à terme contribution, audit de code).
L'écosystème permet d'anticiper un certain nombre de choses à court terme telle que la production de fichier au format OpenDocument comme à moyen terme (optimisation via Cython, intégration dans des environnements hétérogènes et j'en passe).
On me reprochera sans doute de ne pas choisir PHP, notamment du fait de son ultra-présence sur les hébergements mutualisés. Voilà pourquoi :
il ne me semble pas simple de proposer un outil sous forme de paquet avec du code PHP qui sera utilisable avec très peu de configuration sous les différents systèmes d'exploitation
sur l'avantage supposé : il existe des hébergements mutualisés supportant Python; bien que je concède qu'ils soient clairement moins nombreux et que la mise en place y est peut-être moins aisée. Toute documentation à ce sujet sera bien entendu bienvenue. Je trouve qu'à partir du moment où tout est fait pour faciliter l'installation sans compétences particulières et où des alternatives pour l'hébergement existent, cela est suffisant.
cet argument est subjectif mais en ce qui me concerne, je trouve qu'à qualité proche, du code Python est plus lisible et plus concis.
et puis il ne faut pas oublier mes compétences personnelles, ma connaissance de l'écosystème, aujourd'hui plus avancées en Python que sur d'autres plateformes.
J'imagine que la fédération des MJC de Bourgogne + Champagne a contacté toutes celles de la région ? (sinon, je peux transmettre à celle de Sens).
Cette annonce a été envoyée à une centaine de destinataires en Bourgogne. J'imagine que la MJC de Sens a été prévenue mais sur ce point, c'est Laurent qui saura mieux répondre que moi.
Je trouve intéressant le choix de l'AGPL… mais je me demande si ça ne signifie pas qu'on a choisi de faire un développement de zéro sans vérifier si une solution déjà existante pourrait servir de base aux développement des fonctionnalités attendues.
Vous avez raison, le projet sera construit "from scratch".
Les objectifs de l'outil m'ont amené vers ce choix : je n'ai pas connaissance de solution libre dans un domaine proche qui soit orientée participatif et qui remplisse les contraintes citées plus haut.
Concernant la licence, le choix se porte vers l'AGPLv3 car c'est celle qui répond le mieux à notre vision pour ce type d'outil.
Je serai peut-être amené à développer des bibliothèques dans le cadre de ce projet. Ces dernières seront publiées sous une licence plus permissive (selon leur nature, BSD ou MPL).
Je tiens également à rassurer concernant la nature du projet, même si je ne peux ici avancer que ma bonne foi : la totalité du code et de la documentation seront libérés. L'investissement non couvert par la subvention est réalisé sur mes fonds propres (une garantie pour moi d'indépendance).
Et pour compléter (trop tard pour éditer désolé) mes dires, il semble que ce soit Phoronix qui est à l'origine de cette transmission de réponse. Une version plus épurée de l'article de Phoronix est disponible via ViewText.
Le message semble assez diplomatique et dit en substance qu'Optimus a été conçu pour Windows 7 Premium et supérieur (et pas pour les distributions Linux ni pour les autres Windows). Quant aux pilotes Linux, Nvidia se défend en disant préférer utiliser son propre code que de s'intégrer à l'infrastructure commune, afin d'offrir, je cite, une meilleure expérience.
Je suis d'accord pour le framework, ça aide à mutualiser le code.
Maintenant l'approche semble être légère (SQLite, Fossil …) et si Jelix n'est pas trop lourd, il n'en est pas de même - je crois - pour Symfony. Mes connaissances en PHP sont datées mais il existe des micro-frameworks il me semble, dont l'un des plus anciens et connus est CodeIgniter.
Quant à SQLite3, s'il est vrai qu'une interface commune, permettant aux utilisateurs de choisir, pourrait être bienvenue, je ne trouve pas que ce soit un mauvais choix, surtout au niveau de la fiabilité. SQLite est un base matûre, fortement testée. Le seul reproche qu'on peut lui faire dans le cadre d'une application Web est le verrou exclusif sur toute la base de données lors d'une écriture. Mais comme dit plus haut, ce type de projet n'a pas pour but d'atteindre des centaines de simultanés par instance. Et dans ce cas, SQLite semble largement suffisant. Cela change des projets qui imposent MySQL.
Il y en a effet un risque, surtout au niveau du moteur JavaScript, pour les sites-applications et autres précurseurs usant de dizaines de milliers de lignes de code JS (mais là est de pouvoir utiliser conjointement webkit).
En revanche, concernant les normes HTML5 et CSS3, si les navigateurs jouent à celui qui implémentera un maximum de choses le plus vite, il ne faut pas oublier que le tout n'est grosso modo encore qu'une somme de brouillons soumis à changements. Il peut se passer encore des années avant que ces normes soient finalisées, peut-être assez pour que KHTML reste dans la course, même avec une équipe réduite ?
Je partage le même point de vue. J'aurais tendance à préférer la forme suivante, bien que demandant une ligne supplémentaire :
val, present := map[key]
if present {
...
}
Quant au fait de pouvoir lire ce bout code sans connaître Go, il est surtout lié au nom donné à la variable de vérification de présence (et à la connaissance du langage, mais c'est vrai pour tous).
Est-il possible de ne récupérer qu'une partie des variables retournées
Oui, en utilisant la variable spéciale _ . Par exemple, lorsque tu itères un dictionnaire (map) et que tu ne veux utiliser que les valeurs :
for _, value := range array {
...
}
Existe-t'il un IDE pour Go (ou un projet d'IDE) ?
Oui, il y en a des spécialisés, comme GolangIDE. Il y a également une extension Eclipse, IntelliJ… et des plugins Vim / Emacs (gocode pour l'autocomplétion)… La liste des efforts est concentrée sur Cat-V.
Problème selon moi : si la clé ne correspond à aucune valeur, la valeur nulle est renvoyée. De fait dans mon programme j'utilise une map pour faire la correspondance entre les labels et leur adresse réelle. Si je demande l'adresse d'un label inexistant, la map va me renvoyer la valeur 0 puisque c'est l'équivalent de la valeur nulle pour un int…
Comme tu le dis, Go est capable de renvoyer plusieurs valeurs en retour de fonction.
Pour savoir si la clé existe, il faut utiliser le paradigme, fréquent en Go, dit comma ok :
if res, ok := map[key]; ok {
return res
}
Pour les slices, il manque peut-être un peu de sucre syntaxique oui, mais il est simple de créer une fonction remove(i) qui agira comme souhaité.
En tout cas sympathique retour et projet, je vais moi aussi utiliser Go pour mes développements à venir.
Je ne l'ai pratiqué que superficiellement mais, à mon avis; il dispose de solides atouts :
Langage libre, avec de nombreux contributeurs hors Google (qui y emploie une dizaine de personnes à temps plein aujourd'hui).
Relativement efficace (CPU, mémoire vive)
Doté d'une syntaxe familière.
Des concepts simples, plutôt réfléchis et suffisants (on peut comprendre et pratiquer l'ensemble de ceux-ci en quelques semaines, ce que peu de langages permettent réellement). C'est à mon sens l'un de ses plus gros atouts.
À la base prévue pour de la programmation système et réseau, son usage réel l'amène aujourd'hui à devenir un langage généraliste.
La production d'un binaire (avec cross-compilation) qui facilite le déploiement et la distribution.
La commande go, qui prend en charge la compilation, la gestion de dépendances, le style du code, la documentation, les tests….
Une compilation rapide.
Batteries incluses : une librairie standard que je trouve assez complète et bien pensée.
Un langage assez "moderne" : prise en charge native d'Unicode, concurrence aisée via les goroutines et les channels…
Déjà utilisé en production et parfois sur des applications critiques par des entreprises de renom (surtout des startups) : Google lui-même, mais aussi Heroku, Atlassian, Camlistore…
Cela dit, le langage a ses propres défauts :
Il est encore jeune : initié courant 2007, une révélation publique fin 2009, la version "stable" est arrivée il y a seulement quelques semaines.
Conséquence du premier point, le nombre de projets actifs en Go est limité (1, 2) (CGo permet cependant d'utiliser du code existant C). La communauté est dynamique mais cela peut être dû à l'effet de Buzz de la 1.0.
Dans le même ordre, peu de gens connaissent Go, même s'il est relativement simple à apprendre. C'est donc un risque au niveau de certains décideurs, qui de toute façon n'imaginent rien en dehors de Java, C#, PHP voire C(++).
Il s'agit d'un langage compilé statiquement typé. Certains avantages des langages interprétés ne sont logiquement pas présents.
Go est un peu verbeux (beaucoup moins que Java à mon sens mais davantage que des langages comme Ruby, ooc, …).
Il est moyennement portable : Windows, GNU/Linux, OSX, FreeBSD (OpenBSD est quasi officiel je crois) mais trois architectures (x86, 64, ARM). GCCGo vise davantage de plateformes mais n'est pas encore complet.
Certains défauts existent au niveau du ramasse-miettes, notamment en 32bits. Le journal cité au dessus en parle; et un nouveau GC est en cours de développement parait-il.
Certains reprocheront le fait que ce soit une entreprise, Google, qui décide en dernier ressort (et non une fondation et/ou une communauté démocratique).
Cela ne veut en aucun cas dire que c'est du lourd ou qu'il aura un brillant avenir; la qualité technique ou même conceptuelle n'influençant pas toujours sur le succès d'un langage.
Mais personnellement, je trouve qu'il remplit très bien son espace et parierai sur sa pérennité, même si je doute qu'il entre dans le TOP10 de popularité avant longtemps.
Pour ceux que cela intéresse, Michael Meeks, employé par Novell, a publié le 26 avril dernier une comparaison entre les trois suites de la famille : Apache OpenOffice 3.4 (encore en développement à ce moment), LibreOffice 3.5.3 et enfin Oracle OOo.
On y voit que LibreOffice semble avoir une nette avance fonctionnelle, le seul domaine où Apache aurait apporté de nouvelles choses étant celui du dessin.
Concernant l'hébergement Python, tu as aussi une liste sur le wiki officiel.
Personnellement, et sans pouvoir juger de leur qualité / fiabilité, j'avais noté pour les VPS hébergés dans le coin, par ordre décroissant de prix (12 à 5€ HT) : Gandi, PHPNet et FirstHeberg. Il semblerait aussi que Toile Libre propose des VPS à prix libre, si on en fait la demande.
[^] # Re: Dans Firefox
Posté par Yakulu . En réponse au journal DRM et Web ouvert : le drame shakespearien du W3C.. Évalué à 3.
Ça reste du micro benchmark mais :
Au final V8 est en moyenne peut-être cinq fois plus lent que C++ pour une consommation mémoire relativement importante (mais en deçà de Java). À ma connaissance, dans les langages dynamiquement typés, seul LuaJIT est capable de battre cette prouesse. Dommage que Pypy ne fasse plus partie du shootout.
[^] # Re: LTS?
Posté par Yakulu . En réponse à la dépêche OpenSUSE 12.3. Évalué à 1.
Il existe une procédure de mise à jour. J'ai entendu que ça se passait en général bien. Cela dit, je ne l'ai pas expérimenté personnellement (j'ai la réinstallite aigüe, mais je me soigne).
[^] # Re: LTS?
Posté par Yakulu . En réponse à la dépêche OpenSUSE 12.3. Évalué à 3. Dernière modification le 15 mars 2013 à 12:03.
Je ne connais pas vraiment la politique de Novell sur les distributions à support payant. En revanche, pour le projet openSUSE :
Pour ceux que ça intéresse, il existe aussi le projet Tumbleweed, qui permet d'avoir une openSUSE en publication continue ( rolling-release ).
[^] # Re: Il est déjà prêt
Posté par Yakulu . En réponse au sondage Selon vous, pourquoi Linux n'est-il pas prêt pour le bureau ?. Évalué à 4.
Quelques pistes (sans pouvoir réellement conseiller la ou lesquelles) :
# Quelles caractéristiques souhaitées ?
Posté par Yakulu . En réponse au journal Quelle licence pour une application libre avec possibilité d'hébergement payant ?. Évalué à 2.
En dehors du fait que votre plateforme soit libre, vous n'en dîtes pas beaucoup :
[^] # Re: Les performances ?
Posté par Yakulu . En réponse à la dépêche JRuby 1.7.0. Évalué à 2.
Le shootout est passé à JRuby 1.7
Ça permet des comparaisons (et en 32), sur pas mal de micro-benchmarks entre cette version et l'officielle.
Sur ces tests, qui ne reflètent évidemment pas la réalité pour un programme donné :
[^] # Re: L'esprit du libre disparait...
Posté par Yakulu . En réponse au journal Deux ans de projet libre : bilan. Évalué à 1.
Peut-être Elveos ?
Malheureusement, l'équipe a du se désengager en début d'année.
Quant à l'idée, elle me parait plutôt bonne, moyennant le plus difficile point AMHA : atteindre une masse critique de projets l'employant. Et tu touches un point important : beaucoup de projets souhaitent avoir leur liste de tâches sur leur système de gestion de projet. Travailler sur une intégration forte avec pas mal de solutions existantes me parait dans ce cas très important.
[^] # Re: À priori non
Posté par Yakulu . En réponse au message java, jar, application web, agpl et itext. Évalué à 3.
En fait, toute la difficulté vient de la notion de travail dérivé. Pour la FSF, il semble que ce type d'emploi (une bibliothèque dynamiquement liée ?) soit admis comme formant un travail dérivé. Dans ce cas, l'AGPL considérant l'exécution à travers le réseau comme une distribution, l'ensemble de l'application devrait bel et bien être fournie aux utilisateurs sous la même licence.
Cependant, certains remettent en cause cette notion. Et franchement, il est difficile de savoir qui a raison…
[^] # Re: Et tu remplaces Arch Linux par quoi ?
Posté par Yakulu . En réponse au journal Archlinux est morte…. Évalué à 3.
pkgin, qui a commencé à faire parler de lui en 2009, est utilisé sous NetBSD, DragonFly.
Sous FreeBSD, plus récemment, la suite pkg(ng) dont la v1 est arrivée il y a un peu plus d'un mois. Peut-être encore un peu jeune mais très prometteur.
[^] # Re: mise à jour
Posté par Yakulu . En réponse au message linux et usb3. Évalué à 3.
Il ne s'agirait pas plutôt d'un backport ?
Il semble que ce soit pour Ubuntu LTS ou pour Debian stable, il y ait aujourd'hui les noyaux 3.4 disponibles.
# Quelques lieux pour les jeux sous Linux
Posté par Yakulu . En réponse au message Où comuniquer sur son projet open source ?. Évalué à 2.
Outre DLFP, dans le domaine des jeux libres ou des jeux sous Linux, une liste non exhaustive de lieux où en parler :
[^] # Re: Plus d'Android ?
Posté par Yakulu . En réponse au journal Intel ne supportera pas Linux pour ses Clover Trail. Évalué à 1.
C'est sans doute une erreur de ma part. Il semble en effet que Clover Trail soit prévu pour les tablettes, alors qu'il s'agit de Clover Trail+ pour les smartphones, comme le disait reno dans son commentaire plus haut.
[^] # Re: Qui, comment ?
Posté par Yakulu . En réponse à la dépêche Le Conseil Régional de Bourgogne soutient le développement d'un logiciel libre. Évalué à 2.
Et bien c'est plutôt une bonne nouvelle si un logiciel libre existant répond aux contraintes citées plus haut ainsi qu'à une bonne partie du cahier des charges. Y a-t-il un lieu avec des informations sur l'outil ?
Je contacte avec l'association dans la foulée, merci.
[^] # Re: Qui, comment ?
Posté par Yakulu . En réponse à la dépêche Le Conseil Régional de Bourgogne soutient le développement d'un logiciel libre. Évalué à 2. Dernière modification le 03 mars 2024 à 20:45.
Merci pour les encouragements et déjà pour les questions, qui m'ont permis d'expliquer plus en détails le projet.
Alors en effet, Peewee permet d'utiliser SQLite, MySQL et Postgre. En dehors de l'avantage sur la portabilité et le peu de configuration nécessaire, je trouve que SQLite est un très bon moteur dans de nombreux cas. Je l'ai déjà utilisé en prod avec succès. On lui reproch(ait) souvent trois choses :
Je vais peut-être dire des bêtises - dans ce cas, surtout arrêtez-moi - mais :
Cela dit, ce sont des fonctionnalités avancées de la base qui seront à jauger le moment venu. La montée en charge devrait par défaut se faire en migrant vers un moteur plus adapté.
A priori, il y aura un Trac avec les sources comme premier lieu de la gestion du projet, un accès HTTP au dépôt (Mercurial), plus un miroir Github (via HG-GIT).
HS : le monde est petit, je suis allé visiter votre site ce matin, depuis celui de la PyCon Fr.
[^] # Re: Qui, comment ?
Posté par Yakulu . En réponse à la dépêche Le Conseil Régional de Bourgogne soutient le développement d'un logiciel libre. Évalué à 9.
Je suis la personne qui va développer la solution. Je suis lyonnais et fais partie d'une coopérative d'activités et d'emploi.
En réalité, si l'annonce n'est pas précise concernant les objectifs fonctionnels - ce n'est pas le but -, il s'agit de davantage qu'un outil de gestion d'adhérents.
Sans rentrer dans les détails, l'outil veut également donner la possibilité aux structures de gérer :
Le cahier des charges n'est pas finalisé et ne le sera que lorsque plusieurs structures y auront participé.
Ce projet est une spécialisation d'un projet plus large sur lequel je travaille, destiné aux associations de petite à moyenne taille : un outil souhaité participatif, c'est à dire non seulement pour le bureau mais aussi pour tous les adhérents voire les sympathisants. Il y est prévu de pouvoir s'organiser en groupe, de gérer ses rencontres et réunions, de communiquer directement sur l'outil, de pouvoir faire part de ses compétences et disponibilités…
L'application sera en mode Web, point que je pourrais débattre ici. Je ne suis pas de ceux qui prônent l'emploi du Web partout et je trouve que les applications clientes dites lourdes conservent bien des avantages. Néanmoins, lorsque l'on s'adresse à un large public de non techniciens, le mode Web est parfois, à mon avis, incontournable.
Les contraintes auto-imposées de l'application sont les suivantes :
[pip install](http://www.pip-installer.org)sous UNIX, via un installateur à assez court terme sous Windows. Il devra fonctionner y compris sur une machine d'il y a une dizaine d'années. L'objectif est de permettre à des associations sans compétences avancées en informatique et dotée de peu de moyens de l'installer et de l'utiliser.Le financement octroyé par le conseil régional représentera en ce qui me concerne entre un tiers et la moitié du coût de développement (base SMIC, et je ne compte pas la veille et la R&D).
Le modèle économique est encore à définir; mais il devrait être assez classique pour un éditeur de logiciel libre :
Je rappelle qu'en tant que projet libre, une structure pourra choisir de gérer elle-même tous ces aspects, et pourra bien entendu faire appel à un autre prestataire.
La plateforme sélectionnée côté serveur est la suivante : Python2, le framework Flask et l'ORM Peewee.
Voilà les raisons de ce choix :
On me reprochera sans doute de ne pas choisir PHP, notamment du fait de son ultra-présence sur les hébergements mutualisés. Voilà pourquoi :
Cette annonce a été envoyée à une centaine de destinataires en Bourgogne. J'imagine que la MJC de Sens a été prévenue mais sur ce point, c'est Laurent qui saura mieux répondre que moi.
Vous avez raison, le projet sera construit "from scratch".
Les objectifs de l'outil m'ont amené vers ce choix : je n'ai pas connaissance de solution libre dans un domaine proche qui soit orientée participatif et qui remplisse les contraintes citées plus haut.
Concernant la licence, le choix se porte vers l'AGPLv3 car c'est celle qui répond le mieux à notre vision pour ce type d'outil.
Je serai peut-être amené à développer des bibliothèques dans le cadre de ce projet. Ces dernières seront publiées sous une licence plus permissive (selon leur nature, BSD ou MPL).
Je tiens également à rassurer concernant la nature du projet, même si je ne peux ici avancer que ma bonne foi : la totalité du code et de la documentation seront libérés. L'investissement non couvert par la subvention est réalisé sur mes fonds propres (une garantie pour moi d'indépendance).
[^] # Re: Réponse de Nvidia à PCINpact
Posté par Yakulu . En réponse au journal Quand Linus énervé, Linus faire ça !. Évalué à 2.
Et pour compléter (trop tard pour éditer désolé) mes dires, il semble que ce soit Phoronix qui est à l'origine de cette transmission de réponse. Une version plus épurée de l'article de Phoronix est disponible via ViewText.
# Réponse de Nvidia à PCINpact
Posté par Yakulu . En réponse au journal Quand Linus énervé, Linus faire ça !. Évalué à 2.
Nvidia aurait transmis une réponse à PCI.
Le message semble assez diplomatique et dit en substance qu'Optimus a été conçu pour Windows 7 Premium et supérieur (et pas pour les distributions Linux ni pour les autres Windows). Quant aux pilotes Linux, Nvidia se défend en disant préférer utiliser son propre code que de s'intégrer à l'infrastructure commune, afin d'offrir, je cite, une meilleure expérience.
[^] # Re: Pas de framework?
Posté par Yakulu . En réponse au journal Garradin : gestionnaire d'association léger, complet et libre. Évalué à 3.
Je suis d'accord pour le framework, ça aide à mutualiser le code.
Maintenant l'approche semble être légère (SQLite, Fossil …) et si Jelix n'est pas trop lourd, il n'en est pas de même - je crois - pour Symfony. Mes connaissances en PHP sont datées mais il existe des micro-frameworks il me semble, dont l'un des plus anciens et connus est CodeIgniter.
Quant à SQLite3, s'il est vrai qu'une interface commune, permettant aux utilisateurs de choisir, pourrait être bienvenue, je ne trouve pas que ce soit un mauvais choix, surtout au niveau de la fiabilité. SQLite est un base matûre, fortement testée. Le seul reproche qu'on peut lui faire dans le cadre d'une application Web est le verrou exclusif sur toute la base de données lors d'une écriture. Mais comme dit plus haut, ce type de projet n'a pas pour but d'atteindre des centaines de simultanés par instance. Et dans ce cas, SQLite semble largement suffisant. Cela change des projets qui imposent MySQL.
[^] # Re: Évolutions de KHTML et Webkit
Posté par Yakulu . En réponse au journal avenir de konqueror et khtml dans KDE ?. Évalué à 2.
Il y en a effet un risque, surtout au niveau du moteur JavaScript, pour les sites-applications et autres précurseurs usant de dizaines de milliers de lignes de code JS (mais là est de pouvoir utiliser conjointement webkit).
En revanche, concernant les normes HTML5 et CSS3, si les navigateurs jouent à celui qui implémentera un maximum de choses le plus vite, il ne faut pas oublier que le tout n'est grosso modo encore qu'une somme de brouillons soumis à changements. Il peut se passer encore des années avant que ces normes soient finalisées, peut-être assez pour que KHTML reste dans la course, même avec une équipe réduite ?
[^] # Re: Maps et slices
Posté par Yakulu . En réponse au journal Retour d'expérience sur Go. Évalué à 2.
Je partage le même point de vue. J'aurais tendance à préférer la forme suivante, bien que demandant une ligne supplémentaire :
Quant au fait de pouvoir lire ce bout code sans connaître Go, il est surtout lié au nom donné à la variable de vérification de présence (et à la connaissance du langage, mais c'est vrai pour tous).
[^] # Re: Petites questions
Posté par Yakulu . En réponse au journal Retour d'expérience sur Go. Évalué à 2.
Oui, en utilisant la variable spéciale _ . Par exemple, lorsque tu itères un dictionnaire (map) et que tu ne veux utiliser que les valeurs :
Oui, il y en a des spécialisés, comme GolangIDE. Il y a également une extension Eclipse, IntelliJ… et des plugins Vim / Emacs (gocode pour l'autocomplétion)… La liste des efforts est concentrée sur Cat-V.
# Maps et slices
Posté par Yakulu . En réponse au journal Retour d'expérience sur Go. Évalué à 5.
Comme tu le dis, Go est capable de renvoyer plusieurs valeurs en retour de fonction.
Pour savoir si la clé existe, il faut utiliser le paradigme, fréquent en Go, dit comma ok :
Pour les slices, il manque peut-être un peu de sucre syntaxique oui, mais il est simple de créer une fonction remove(i) qui agira comme souhaité.
En tout cas sympathique retour et projet, je vais moi aussi utiliser Go pour mes développements à venir.
# AMHA
Posté par Yakulu . En réponse au message Et alors ? Go de google, c'est bien ?. Évalué à 7.
Je ne l'ai pratiqué que superficiellement mais, à mon avis; il dispose de solides atouts :
Cela dit, le langage a ses propres défauts :
Cela ne veut en aucun cas dire que c'est du lourd ou qu'il aura un brillant avenir; la qualité technique ou même conceptuelle n'influençant pas toujours sur le succès d'un langage.
Mais personnellement, je trouve qu'il remplit très bien son espace et parierai sur sa pérennité, même si je doute qu'il entre dans le TOP10 de popularité avant longtemps.
# Comparaison LibreOffice Apache OO
Posté par Yakulu . En réponse au journal OpenOffice n'est pas mort !. Évalué à 6.
Pour ceux que cela intéresse, Michael Meeks, employé par Novell, a publié le 26 avril dernier une comparaison entre les trois suites de la famille : Apache OpenOffice 3.4 (encore en développement à ce moment), LibreOffice 3.5.3 et enfin Oracle OOo.
On y voit que LibreOffice semble avoir une nette avance fonctionnelle, le seul domaine où Apache aurait apporté de nouvelles choses étant celui du dessin.
[^] # Re: Contrainte techniques
Posté par Yakulu . En réponse au journal Garder contact librement. Évalué à 1.
Concernant l'hébergement Python, tu as aussi une liste sur le wiki officiel.
Personnellement, et sans pouvoir juger de leur qualité / fiabilité, j'avais noté pour les VPS hébergés dans le coin, par ordre décroissant de prix (12 à 5€ HT) : Gandi, PHPNet et FirstHeberg. Il semblerait aussi que Toile Libre propose des VPS à prix libre, si on en fait la demande.