barmic a écrit 10455 commentaires

Mais j'essaie surtout de ne plus jamais avoir de listes car :

• ça ne sert à rien
• le spectateur ne se concentre jamais
• griser n'est qu'un paliatif
• ça ne permet quasiment jamais de passer un message

Je ne suis pas d'accord. Ça permet d'avoir une énumération claire et sobre. Par exemple si je veux décrire les axes d'évolutions. Tu as le choix entre :

• les incorporer dans le texte et c'est extrêmement chiant pour le lecteur (tu dois écrire des phrases, il faut tout relire pour se repérer, etc) ;
• les mettre sous forme de liste (pas trop longues) ;
• inclure ça dans un schémas stylisé super classe qui va déconcentrer le lecteur, risquer de mal passer selon la qualité du projecteur, etc
• ne pas les mettre et là tu as intérêt à parler vraiment doucement tout en captivant ton auditoire parce que s'ils ont décroché (et ils décrochent faut pas se croire à une keynote Apple) ton message ne passe pas.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Si je les ai vu mais ils sont nettement moins pratiques (ils se déconnectent facilement et se reconnectent difficilement, ensuite je crois que la connexion n'est pas enregistrée dans le fichier XML (mais peut être que j'enregistrai en SVG standard et pas en SVG inkscape)) que ceux de dia à tel point que c'est toujours la dernière étape de mes graphes quand j'utilise inkscape.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Ne parlons pas d'alternatives si tu veux jouer sur les mots, disons que dans biens des usages c'est une option à envisager.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

J'ai zappé le paragraphe bureautique désolé.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Je suis surpris de ne pas voir inkscape. Qui est vraiment une alternative à dia.

dia est vraiment fait pour faire des diagrammes, il a des bibliothèques de dessins complètes et permet de réellement lier les objets entre eux, mais son ergonomie n'est pas génial et les PDF qu'il génère ne sont pas toujours géniaux. Inkscape est nettement plus agréable à utiliser mais il ne permet pas de lier les objet du dessin entre eux.

En plus inkscape permet de faire des présentations très sympa avec sozi ou jessyink.

D'ailleurs tu ne nous a pas parlé de ce que tu utilisait comme traitement de texte ? Moi c'était LaTeX ou txt2tags quand je devais collaborer avec d'autres.

Enfin pour des traitement statistique et/ou probabiliste j'utilisais R.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Ou que l'on en pervertisse le sens, en le plaçant dans un groupement de textes de trolleurs sociopathes.

Aucune licence CC n'empêche ça.

Du coup je présume que ce que tu souhaite c'est garder ton pleins droit d'auteur et attribuer des autorisations sur demandes ou alors trouver/écrire une licence plus en accord avec tes besoins, mais elle ne seras pas libre (la dsfg indique par exemple qu'une licence libre ne doit faire « Aucune discrimination de champ d'application » (point n°6)).

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Soit heureux et fier d'avoir accès aux protocole IMAP et SMTP quand tu en a besoin.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Je ne sais pas ce que tu entends exactement par « cycler », mais avec awesome j'ai un équivalent de alt-tab si c'est ce que tu cherche.

Sinon en principe les tillings sont extrêmement efficace quand tu as des habitudes de travail assez établies et que tu prend le temps de les configurer. Pour par exemple avec un tag « web » avec les fenêtres (clients si je ne me trompe pas) de ton navigateur (parce que bien sûr les onglets c'est fait pour ceux qui n'ont pas de bon gestionnaire de fenêtres), un tag « coding » avec ton terminal et ton éditeur de texte positionner au millimètre, etc... et tu peux toujours garder un tag flottant pour les moments où tu en a besoin.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Dire que j'ai toujours cru que c'était la cousine de Ouioui...

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Kaum là gramèr é lautografe ?

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Ta description m'a intéressée et j'ai voulu essayé. Je l'ai installé via apt-get sans problème puis j'ai parcouru très vite fait cette doc (j'ai surtout vite fait regardé les exemples) : http://www.adacore.com/wp-content/files/auto_update/gprbuild-docs/html/gprbuild_ug.html

J'ai donc tenté avec un petit programme d'exemple de 3 fichiers, j'ai écris un build.gpr ainsi :

project Build is
  for Languages use ("C");
  for Source_Dirs use ("src");
  for Object_Dir use "build";
  for Exec_Dir use ".";
  for Main use ("hello");
end Build;

un petit gprbuild et pouf j'ai l'éxécutable !

J'ai du y passé 10 à 20 minutes grand max. Cet outil est vraiment pas mal ! Pas très flexible, mais ce qu'il fait, il le fait bien. Je le garde dans ma besace :D

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

ah, tiens, pour MVC, je l'aurais dit plus simplement :

Je galère à présenter simplement les choses (par exemple je parlais de modèle 3-tière au dessus... :-)

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Je vois que tu ne connaissais ni patsubst ni include (avec -include et l'quivalent GNU sinclude), ni gcc -MM... Bref, tu ne connaissais pas make ! Ce n'est pas un critique mais une constatation.

include si mais pour faire de l'inclusion bête et méchant. gcc -MM j'en avais entendu parlé mais comme je n'avais pas trouvé de vrais moyens de s'en servir, j'ai rapidement oublié. Pour ce qui est de patsubst, j'utilisais ${SRC:.c=.o}.

Le problème des dépendances est un problème de compilateur car il faut savoir lire le langage pour le faire correctement. Tout compilateur devrait savoir écrire les règles de dépendances (comme gcc -MM).

Je suis d'accord avec toi. J'adapterais cette solution pour convenir à LaTeX à grand coup de sed.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Bon bon bon, ça devient de l'attaque un peu gratuite. Je me fais moinser sur mes messages et tu te fais plusser sur les tiens, donc j'ai tendance à croire que quoi je dise, je vais passer soit pour un méchant, soit pour un imbécile, soit pour un incapable :-/

Faut s'en foutre des cliques ça fait juste parti du folklore local.

Selon mon expérience, plus tu rajoutes d'intermédiaires, de fonctions qui appellent des classes, elles mêmes dérivées de plusieurs classes, etc.... plus ça devient compliqué à maintenir. Maintenir = corriger un bug. Maintenir != faire évoluer.

En fait c'est plus de la structuration de code. Si tu sais que pour tout ce qui touche à la base de données il faut aller toucher à l'objet DAO c'est nettement plus simple que d'aller voir avec grep toutes les utilisations de l'API SQL. Si en plus on a un moteur de template qui ne s'occupe que de la présentation des données et qui ne s'intéresse pas de savoir ce qu'elles représentent ni comment elles doivent être modifiées, alors tu as une application 3 tiers. C'est pas ajouter des milliards d'indiréctions, c'est juste avoir structuré son application de manière cohérente. Le sur-coût existe (on a plus de classes/objets, on appel des fonctions), mais à coté de ça l'application est nettement plus maintenable. Ça simplifie le travail collaboratif car chaque contributeur travailleras sur un sous ensemble du code qui s'utilisent entre elles avec le principe des boites noires.

J'ai travaillé avec des développeurs qui se prenaient la tête à prévoir que peut-être un jour on voudra faire ceci ou cela avec le code et donc il fallait le prévoir dans l'architecture. Moi je dis stop. Soit on en a besoin tout de suite, soit on ne le prévoit pas et on reste simple dans son architecture. Code simple = code facile à maintenir. C'est d'autant plus important dans un projet libre et ouvert comme Piwigo que le développeur d'une fonctionnalité ne va pas forcément être celui qui va y corriger un bug 3 ans plus tard.

Tu as raison l'un des grands principes de scrum est de ne pas hésiter à réécrire pendant chaque sprint. Cela n'empêche pas d'avoir une structuration de son code pour simplifier son développement (et simplifier les tests lorsque l'on fait des tests unitaires).

Quant à la capacité d'étendre Piwigo, je parle des thèmes et des plugins. Il y a plus de 200 plugins et plus de 100 thèmes. Pour un CMS "spécifique", c'est plutôt pas mal.

C'est même très bien. Prévoir la possibilité de créer des thèmes et celle d'avoir des plugins est un travail très complexes.

"Changer de SGBD" n'est en aucun cas un besoin récurrent. Et la problématique n'est pas de changer, mais d'être compatible multi-SGBD, ce qui n'est pas du tout la même chose. Si un jour on passe en MariaDB, ce sera bien plus simple que d'être compatible PostgreSQL/SQLite/Firebird/FuturSGBDopensourceAlamode.

Une méthode consiste à utiliser un paterne DAO. Pour chaque moteur, on hérite du DAO_MySQL et on réécris les méthodes qui en ont besoin. Ça ne me semble pas très couteux.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Très intéressant. C'est exactement le genre de découvertes que j'espérais faire avec cette dépêche :)

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

[…] même si c'est libre, comme on est pas maître de ses données (export/import possible facilement), on reste enfermé.

Ouai mais bon quand on parle de DCVS, on a de toute manière toutes les sources et leur versions sous le coude (je sais dans une forge il n'y a pas que ça).

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Piwigo est très performant, plutôt facile à maintenir et à étendre.

Quand changer de SGBDR, prend un temps pas possible et arrive à faire casser certains thème, j'ai un doute sur ce dernier point.

Sinon vous avez eu temps de problème de performance pour que ça soit si primordiale ? Tu nous en parle depuis le début et à toutes les sauces, c'est une contraintes qui a était si forte que ça ? et dure à tenir ? Il ne faut pas voir un troll dans mes questions, c'est juste que ce n'est (il me semble) pas mis en avant par le projet et que je ne m'en doutais pas.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Je comprends ! C'est intéressant, mais j'aurais alors une question en plus.

Si je comprends bien la Makefile au dessus va créer des fichiers *.deps qui sont au formats Makefile et qui sont inclus dans le Makefile par la directive -include $(DEP). Mais cette dernière prends en compte dynamiquement les fichiers en question ?

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

maven, il te faut Java (pour un projet Java on va dire que c'est le minimum de toute manière) et maven qui s'installe en décompressant un zip.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Dans le cas de Piwigo, on ne partait pas de rien, mais d'un existant dans lequel les requêtes SQL étaient au milieu du code PHP (certains trouvent ça horrible, moi pas du tout, bien au contraire). Pour éviter de réécrire 98% du code on a choisi la méthode 2, qui minimisait l'impact sur le code.

Une architecture multi-tière ou MVC, c'est pas juste du buzzword qui ne sert à rien. Ça permet de regrouper au même endroit des choses qui ont la même utilité.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Pour le coté POSIX, la souplesse et le fait que c'est un langage nous sommes d'accord.

Je ne connaissais pas patsubst, mais le problème c'est que normalement il faut que cette recherche soit récursive.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

C'est un problème connu de maven, dès qu'on sort des clous c'est très compliqué. Peut être que tu devrais regarder du coté de gradle ?

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Pourquoi ? parce qu'être compatible avec PostgreSQL apporte des contraintes pénibles de développement, empêche d'optimiser les requêtes efficacement

Tiens je serais curieux de connaître ces optimisations.

Les utilisateurs testeurs sur PostgreSQL ne peuvent pas utiliser les plugins voire même certains thèmes et c'est très frustrant.

Je me demande ce qui peut entraîner une tel incompatibilité.

C'est dommage, mais nous allons nous reconcentrer sur MySQL, qui présente de nombreux avantages : disponibilité, libre, gratuit, performant.

Disponibilité je comprends, mais libre, gratuit et performant il est loin d'être le seul.

(le jour où MySQL ne présentera plus ces avantages, il sera temps de changer)

Et ça sera une galère monstre vu comme il semble difficile de gérer postgre actuellement (on parle quand même d'un SGBD qui a était racheté par Oracle et qui a connu au moins un fork plus quelques alternatives l'an dernier juste à cause de ça).

Vouloir être compatible avec plusieurs SGBD, c'est bien en théorie mais en pratique, c'est une charge de travail supplémentaire et au final, il faut être réaliste : les utilisateurs s'en moquent complètement. Les utilisateurs, ils veulent que ça marche, pas que les contraintes d'intégrité référentiel soient gérées de telle ou telle façon. Désolé si c'est trop pragmatique mais c'est mon expérience.

Tu trouveras rarement un logiciel Java qui limite à une base de données (le seul que je connais c'est Oracle SQL Developer), c'est tout l'avantage de JDBC, Perl a DBI, python a SQLAlchemy, PHP a ses équivalents. Quand ils sont utilisé le coût de l'abstraction est nul. Les administrateurs (ceux qui installent ces solutions) sont sensibles à ça (et même free.fr propose Postgre).

Enfin ce que je voulais dire, c'est que je n'ai pas trouvé l'info du SGBD qu'ils utilisaient pour MediaGoblin. Enfin si, avec un peu plus de recherche, j'ai trouvé qu'ils utilisaient MongoDB, qui n'est pas un SGBD. Donc tu ne pourras pas utiliser PostgreSQL, mais à mon sens cela n'a rigoureusement aucune importance.

MongoDB est un SGBD, c'est juste pas un SGBDR. Oui du coup il n'y a pas de choix possible, mais en même temps ça n'existe pas encore d'abstraction autour des bases de données orientés document.

Encore une fois, je constate de manière empirique sur des exemples concrets (probablement pas assez nombreux pour en tirer une conclusion générale), mais lorsque j'ai fait tourner du Ruby On Rails ou du Python, le serveur avait vraiment du mal à suivre et la conséquence était une dégradation rapide de la qualité de service pour les visiteurs du site. Les applications équivalentes en PHP n'avaient quasiment pas d'incidence sur la consommation CPU/RAM du serveur.

Comme déjà dis tu es ici sur un site en Ruby on Rail qui est un peu plus léger que sa précédente version en PHP qui utilisait un moteur de template réputé très optimisé.

OK, alors effectivement ça change tout, ils visent une niche vraiment petite (pour le moment, dans 5 ans, ce sera peut-être la majorité)

Petite par rapport à quoi ? Ils cherchent à répondre à un besoin.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Côté auteur, il faut un shell, m4 et Perl en effet, mais il semble évident que, pour utiliser un système de construction, il faut l'avoir installé, ou du moins ce qui le constitue, non ?

Oui mais face à OMake ou ninja qui ont un nombre de dépendance extrêmement faible même coté développeur surtout qu'un bourne shell et m4 sous Windows c'est pas ce qu'il y a de plus simple.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Je suis aussi très satisfait de maven pour du java (même si j'ai encore peu d'expérience et que je n'ai pas encore touché à des archétypes).
J'aimerais bien avoir l'occasion de toucher à gradle ou buildr qui ont l'air intéressants et qui évite de faire du XML. Je sais que maven 3 permet d'avoir une configuration XML compact. Avec ça :

<dependencies>
  <dependency groupId="org.apache.maven" artifactId="maven-artifact" version="${mavenVersion}" />
  <dependency groupId="org.apache.maven" artifactId="maven-project" version="${mavenVersion}" />
</dependencies>

À la place de :

<dependencies>
  <dependency>
    <groupId>org.apache.maven</groupId>
    <artifactId>maven-artifact</artifactId>
    <version>${mavenVersion}</version>
  </dependency>
  <dependency>
    <groupId>org.apache.maven</groupId>
    <artifactId>maven-project</artifactId>
    <version>${mavenVersion}</version>
  </dependency>
</dependencies>

Mais ce n'est pas très mis en valeur et je n'ai pas eu l'occasion d'essayer.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)