Loïc d'Anterroches a écrit 194 commentaires

  • [^] # Re: Django ?

    Posté par (page perso) . En réponse à la dépêche InDefero, Wiki et support de Mercurial dans la version 0.4.0. Évalué à 4.

    Merci Cørtø, je viens de faire l'ajout, je n'y avais pas pensé du tout.
  • [^] # Re: Django ?

    Posté par (page perso) . En réponse à la dépêche InDefero, Wiki et support de Mercurial dans la version 0.4.0. Évalué à 2.

    En effet, le problème des sous-tâches existe, une solution est de simplement discuter sur un ticket et le renommer au fur et à mesure, comme ici :
    http://projects.ceondo.com/p/indefero/issues/55/ (regarde les commentaires 6 et 7)

    Par contre, si c'est un travail plus important, le plus simple et le plus élégant est de créer une étiquette "Tâche:Fonctionnalité-Truc" et d'associer cette étiquette au tickets correspondants. C'est à mon avis la méthode la plus simple et surtout, cela permet de garder l'interface d'ajout d'un ticket la plus simple possible. La devise d'InDefero est "beautiful simplicity" soit "belle simplicité".
  • [^] # Re: Django ?

    Posté par (page perso) . En réponse à la dépêche InDefero, Wiki et support de Mercurial dans la version 0.4.0. Évalué à 10.

    Bonjour Bozo,

    Deux raisons m'ont poussées à coder cela en PHP :

    - La première et la plus importante, la disponibilité de PHP pour presque tout le monde, partout, facilement. Je souhaite donner la possibilité à tous d'utiliser InDefero facilement sur la majorité des hébergements. PHP est pour cela merveilleux. (ok, il manque un petit script d'installation automatique pour InDefero, mais cela va venir). Un logiciel libre a besoin d'une communauté d'utilisateur, j'ai donc choisi la technologie qui offre accès à la plus grande communauté/base d'utilisateurs.

    - Le seconde, bien égoïste, étant développeur de Pluf, c'était l'occasion de montrer qu'on peut facilement faire du code propre et efficace, le tout rapidement, avec ce framework. Rien de tel pour faire la pub d'un framework qu'une "killer app" que tout le monde veut installer.

    - La troisième, pas vraiment bonne donc à ne pas vraiment compter, les limitations du système de gabarit de Django avec l'impossibilité de mettre des if/then/else un peu compliqués dedans (on peut changer ça, mais ce n'est plus standard pour les templates venant d'autres applications).

    Par rapport à ta remarque sur les limitations de PHP, je dirais qu'aujourd'hui on peut tout faire correctement et facilement avec n'importe quel langage orienté web ou ayant un framework de qualité. Pour ce type d'application, PHP, Ruby, Erlang ou Python c'est grosso-modo la même chose, plus une question de goût et surtout d'efficacité et de connaissance des outils par les développeurs.

    En espérant avoir répondu à tes questions.
    loïc
  • [^] # Re: Très bon ça, le support Mercurial :)

    Posté par (page perso) . En réponse à la dépêche InDefero, Wiki et support de Mercurial dans la version 0.4.0. Évalué à 3.

    Peux-tu m'éclairer un peu et m'expliquer rapidement ce que sont les outils pull/clone de bitbucket ? Histoire que je garde ces idées au coin du crâne pour les prochains développements.

    Merci !
  • [^] # Re: Moi aussi j'ai des questions

    Posté par (page perso) . En réponse au journal InDefero, Wiki et support de Mercurial dans la version 0.4.0. Évalué à 1.

    Tu as raison, il faut juste que je regarde le "comment" faire. C'est souvent un problème de droits etc.
  • [^] # Re: Quelques remarques...

    Posté par (page perso) . En réponse au journal InDefero, Wiki et support de Mercurial dans la version 0.4.0. Évalué à 2.

    Voici quelques réponses à tes questions :

    - Pour le wiki, il est où ? C'est les pages de documentation ? Peut -t-on, où pourra t-on faire les pages en multilingue (avec un switch entre les langues un peut à la façon wikipédia ?)

    - Le wiki est la documentation, le mot wiki est inconnu de la majorité des gens. Documentation "parle" tout de suite, "Wiki" non.
    - Les pages en plusieurs langues, on pourrait faire une étiquette associant une langue à une page, puis ensuite on liste via cette étiquette.

    - Pour les pages de documentation, un truc qui pourrait être intéressant, c'est l'extraction directe en PDF. Genre, pour ma boite, on écrit les documentations dans le wiki dans plusieurs langues (ce qui permet aussi de gérer aussi les versions facilement), et un simple clique permet de sortir le document en PDF. Ça permettrait d'éviter les éternels soucis de mise en page avec les gens qui traduisent.

    - l'export pdf doit bien être possible avec une classe genre tcpdf. Pour les soucis de mise en page, les pages sont écrites en Markdown, donc cela résout le problème directement.

    - Y'a t-il, où, y aura-t-il un mini forum dédié à chaque projet ? Parce que je vois là, que tu redirige vers le forum de GoogleCode.

    C'est prévu, mais ma priorité est la revue de code avant d'ajouter le forum.

    - Pour les projets « privés », peut-t-on quand même rendre le système de tickets et documentations publiques ?

    - oui et non, tu peux avoir un projet publique dont certaines tabs ont des droits particuliers pour donner accès au code uniquement aux membres du groupe. Un projet privé cache même le projet dans la liste des projets pour les personnes non autorisées (tu as encore des sous-droits pour les personnes autorisées).

    Sinon, projet intéressant, je le garde sous la main. Mais il manque encore des choses pour être vraiment utilisable :)

    Pour toi, pour moi il est parfaitement utilisable ;)
  • [^] # Re: Essayez le

    Posté par (page perso) . En réponse au journal InDefero, Wiki et support de Mercurial dans la version 0.4.0. Évalué à 5.

    Je dirais - comme je suis le développeur mon avis est biaisé - mais cela vient de ma connaissance du code derrière.

    Stade production : Tickets, visualisation du code.
    Stade production mais pas "user friendly" : Installation.
    Stade beta : Wiki.

    Sinon, cette nuit, j'ai trouvé comment implémenter la revue de code en pré commit et aussi en post commit. Cela va être mon petit joujou de début décembre.
  • [^] # Re: bzr ?

    Posté par (page perso) . En réponse au journal InDefero, bug tracker et navigateur git/subversion en version 0.2.0. Évalué à 2.

    Effectivement on travaille de concert car les devs de Jelix codent un équivalent d'InDefero. On va pouvoir éviter de dupliquer le travail. Par ailleurs, le support de Mercurial vient d'être ajouté.
  • [^] # Re: J'ai codé Activity Monitor pour ça

    Posté par (page perso) . En réponse au message Time tracking. Évalué à 2.

    C'est vrai que c'est un script pour quelqu'un qui connait Python et en fait, je pense être l'unique utilisateur. Je vais améliorer l'installation, ce n'est pas trop un problème.

    Merci !
  • # J'ai codé Activity Monitor pour ça

    Posté par (page perso) . En réponse au message Time tracking. Évalué à 2.

    J'ai fait un petit script pour ça : http://projects.ceondo.com/p/activitymonitor/

    les captures d'écrans sont anciennes, maintenant on peut faire plus de rapports. Il n'y a que 2 niveaux de tache/sous tache. Comme je suis l'unique utilisateur (je l'utilise pour faire mes rapports de temps pour facturer ensuite mes clients), je ne sais pas si cela s'installe facilement, mais en même temps, c'est un bête script python avec 2 fichiers png pour les icones.
  • [^] # Re: Hum

    Posté par (page perso) . En réponse au journal InDefero, bug tracker et navigateur git/subversion en version 0.2.0. Évalué à 2.

    J'ai mis à jour la doc avec tes remarques:

    http://projects.ceondo.com/p/indefero/source/commit/a5acd5d6(...)

    Pour le "script qui fait tout", cela va venir, c'est effectivement important pour éviter aux gens de mettre les mains dedans inutilement.
  • [^] # Re: Hum

    Posté par (page perso) . En réponse au journal InDefero, bug tracker et navigateur git/subversion en version 0.2.0. Évalué à 1.

    Merci pour ce retour ! C'est le genre d'expérience dont j'ai besoin pour pouvoir mettre à jour la doc. Cela sera fait aujourd'hui. Lance :

    $ php src/migrate.php --conf=src/IDF/conf/idf.php -a -i -d

    pour créer les tables, le "-u" c'est le "dry-run".

    Pour la taille, je parle effectivement de la taille de l'archive et non de la taille totale, c'est juste pour comparer avec les applications où il faut souvent se faire un téléchargement de 5Mo pour faire quelque chose.

    Encore merci !
  • [^] # Re: Installation et mise à jour automatique

    Posté par (page perso) . En réponse à la dépêche DotClear 2.1, le blog qui monte, qui monte.... Évalué à 1.

    Il me semble que SPIP offrait cela. Mais sinon, je ne préfère pas avoir ce genre de choses, je préfère nettement avoir une liste claire des dossiers où un script PHP peut venir écrire (fichiers temporaires, uploads). C'est une question simple de sécurité, si tu as une installation automatique/mise à jour automatique et un trou de sécurité dans ton application, et bien, le crackeur va pouvoir installer ce qu'il veut sur ton système (et tu n'auras même pas un log quelque part qui te permettra de comprendre pourquoi tu t'es fait avoir).

    Un simple coup de sftp + chmod sur les 2 répertoires à ouvrir en écriture c'est à mon avis la base de la sécurité, pour les personnes qui veulent tout en "1 click", qu'ils prennent un hébergeur offrant l'option "1 click" pour certaines applications.

    Je ne donne pas un couteau à désosser à mon gamin de 1 an.
  • # NorhTec ou système maison

    Posté par (page perso) . En réponse au message Serveur perso silencieux. Évalué à 2.

    J'ai un petit DFC de chez NorhTec, la qualité est vraiment superbe, il est vieux (3 ans) et tourne sans broncher, on entend que les disques (3.5").
    http://www.norhtec.com/

    Le "fanless" n'est pas forcément nécessaire, l'important c'est d'avoir un ventilateur qui tourne à basse vitesse, monté sur de la gomme pour limiter les vibrations et une caisse bien remplie (en dehors des circuits d'air) pour éviter de la raisonnance. Avec cela, on arrive à créer des systèmes inaudibles à 1m.
    http://www.silentpcreview.com

    Se faire sa boite en bois à partir de composants genre microATX permet de ne pas payer le surcoût miniITX. La boite que je me suis faite la semaine dernière :
    http://www.silentpcreview.com/forums/viewtopic.php?p=433651
  • # Séparation entre interface d'administration et d'utilisation très bien

    Posté par (page perso) . En réponse à la dépêche Lundi Matin Business, un nouveau logiciel de gestion commerciale OpenSource. Évalué à 7.

    Je suis allé faire un petit tour sur la démo. Vraiment sympa l'idée de faire une séparation entre l'interface d'utilisation et celle de configuration, le tout avec un design différent. Cela permet de bien faire la séparation et donne une interface légère dans l'utilisation courante.

    Une idée à garder sous le coude pour certains développements.

    Sinon, le design est bien agréable et l'interface bien réactive.
  • [^] # Re: ORM

    Posté par (page perso) . En réponse à la dépêche Sortie de la version 1.0 de Django. Évalué à 5.

    Si les migrations t'intéresse, c'est effectivement le sujet du moment pour la communauté Django. Simon Willison propose sa méthode et fait des liens vers les différentes solutions ici :

    http://simonwillison.net/2008/Sep/3/dmigrations/

    Le fait est qu'il n'existe pas de méthode standard/officielle pour le moment. Maintenant, il y a un désir de la part des développeurs d'arriver à ajouter cela par défaut, donc cela arrivera bien vite.
  • [^] # Re: Titre et contenu de la dépêche pas trop en rapport...

    Posté par (page perso) . En réponse à la dépêche InDefero, clone Google Code en version 0.1.0. Évalué à 2.

    L'intérêt d'un framework qui va vite sur un hello world est que si on se retrouve à devoir optimiser un petit bout du site utilisant le framework, on peut prendre les quelques vues en question et revenir presque à du PHP pur (requêtes SQL directes sans ORM, pas de système de templates, etc...) sans pour autant être obligé de faire du vrai PHP pur, ce qui voudrait dire avoir une partie du site avec un système et une autre avec un autre, ce qui est galère au niveau maintenance.
  • [^] # Re: Titre et contenu de la dépêche pas trop en rapport...

    Posté par (page perso) . En réponse à la dépêche InDefero, clone Google Code en version 0.1.0. Évalué à 2.

    Guillaume, c'était un journal au départ, et je suis donc totalement d'accord avec ta remarque. Désolé. La version 1.0 d'InDefero va bientôt venir et là une présentation complète d'InDefero sera faite.

    Merci pour votre patience et désolé pour le dérangement.
  • # Journal transformé en dépêche

    Posté par (page perso) . En réponse à la dépêche InDefero, clone Google Code en version 0.1.0. Évalué à 3.

    Salut, c'est juste pour dire que c'est un journal qui s'est fait transformé en dépêche dans mon dos. Je ne suis pas mécontent, mais comme la version 1.0 va venir bientôt, cela risque de faire doublon. Désolé...
  • [^] # Re: Mais ...

    Posté par (page perso) . En réponse au journal InDefero, clone GoogleCode en version 0.1.0. Évalué à 3.

    Merci Antoine.

    Le wiki est effectivement prévu, c'est ce que j'appelle le système de documentation. J'ai constaté que le mot wiki, quoique banal pour nous développeurs, reste un mot bizarre pour la majorité des gens.

    Pour les flux, j'ajouterai cela, ce n'est pas compliqué du tout à faire. Le plus compliqué sera de trouver où mettre l'icône pour que cela reste élégant.
  • [^] # Re: Mais ...

    Posté par (page perso) . En réponse au journal InDefero, clone GoogleCode en version 0.1.0. Évalué à 2.

    Merci ! Mais je préfère faire des journaux de seconde page en attendant la sortie de la 1.0.

    J'ai des vacances la semaine prochaine, cela correspondra parfaitement pour l'ajout d'une timeline et d'un petit système de documentation. C'est ce qu'il me manque pour la 1.0, mais les remarques pour des ajouts sont les bienvenues, du moment que j'arrive à garder l'interface la plus sobre possible...
  • [^] # Re: Mais ...

    Posté par (page perso) . En réponse au journal InDefero, clone GoogleCode en version 0.1.0. Évalué à 3.

    Le support de Subversion avait été demandé par les personnes ici-même, donc c'est pour cela que je l'annonce ici.

    Pour ne pas trop déranger quand même, je poste toujours en "journal de seconde page", il me semble que cela donne un score de base plus faible au journal et donc une descente plus rapide.
  • # Oups

    Posté par (page perso) . En réponse au journal InDefero, clone GoogleCode en version 0.1.0. Évalué à 2.

    les remarques constructives reçues
  • [^] # Re: stratégie de Novell

    Posté par (page perso) . En réponse au journal Petites nouvelles.... Évalué à 4.

    C'est pour des raisons historiques, car Microsoft n'a pas cassé la compatibilité avec toutes les DLLs. On a des routines de calcul scientifique codées en Fortran le tout dans une DLL, on peut facilement l'utiliser depuis C# et le bon vieux Fortran 77, cela se compile bien aussi sous Linux :)

    En gros, on peut doucement migrer une application MFC vers C# sans perdre les années de travail sur une partie du cœur.

    Je suppose que c'est possible de faire des accès à des DLLs avec Java (on le fait bien avec Python) mais bon, on fait la transition doucement, on a des contrôles activex dans la partie GUI...

    C'est donc un choix complètement orthogonal à la licence, Microsoft, etc. Quand je peux choisir, je prends plaisir avec d'autres langages que C#, mais il faut reconnaître, Microsoft a fait du joli travail avec ce langage et la VM qui va avec.
  • [^] # Re: stratégie de Novell

    Posté par (page perso) . En réponse au journal Petites nouvelles.... Évalué à 3.

    Moi, je dis mille fois merci à Novell pour Mono. Cela me donne une boite à outils supplémentaire pour facilement faire des applications qui tournent sous Linux et Windows.

    Dans mon cas bien concret, j'ai une application métier qui tourne sous Windows (pas un seul client n'utilise Linux et même si on propose une version Linux on n'a pas encore reçu la moindre demande réelle) et une version web de cette même application qui tourne sous Linux. Le cœur est le même, merci Mono.