revois la génération de fichier et les titres

2020-03-08 01:08:16 +01:00
parent 4be4778b7b
commit c0ed9245cd
316 changed files with 996 additions and 845 deletions
@@ -21,7 +21,8 @@
    <link rel="alternate" type="application/rss" href="/feed.xml" title="elsif.fr/feed" />
  </head>
  <body>
-    <main>
+    <article>
+      <h1>Marre du liste fiche de l’informatique de gestion</h1>
      <p><em>Il y a quelque chose qui commence à être lourd dans les développements logiciel auquel je participe: l’ergonomie idiote. Je me demande comment enrayer cela. Voici une image du problème que je rencontre si souvent</em>.</p>
      <p>En général, on écrit un logiciel pour faciliter la vie d’utilisateurs. Dans mon cas, c’est souvent des utilisateurs interne (je travail en <em>informatique de gestion</em>). Il y a déjà là une petite piste de reflexion: <strong>pourquoi je traite des utilisateurs interne différement du grand public (ou utilisateur externe) ?</strong></p>
      <p>Peut-être parce qu’on ne peut pas <em>imposer</em> une manière de travailler à monsieur tout-le-monde. Mais finalement, quand on y pense un peu, les divers services que l’on utilise nous impose un peu leur vision des choses, et quand c’est bien fait, c’est un service qui marche, parce que la façon dont sont proposé les fonctionnalitées nous convient. Sinon, le produit disparait.</p>
@@ -48,7 +49,7 @@
      </ul>
      <p>Peut-être un peu plus confidentiel (surtout auprès des développeur français que je connais ?) mais j’ai l’impression que ça pourrais nous faire revenir à l’essentiel: la fonction d’un logiciel. Et non la structure des données (qui semble être le point le plus important aujourd’hui, malheureusement). Mais c’est un sujet un peu trop neuf pour moi pour l’instant. Si vous voulez en savoir plus, je ne peut que vous conseiller l’<a href="http://en.wikipedia.org/wiki/Domain-driven_design">article wikipedia sur le Domain Driven Design</a>pour commencer (la version française manque d’ailleurs de richesse :p): puis le <a href="http://domaindrivendesign.org/">site de la communauté ddd</a>.</p>
      <p>Je ne sais pas trop a quoi ressemblerons nos appli de demain, mais j’espère que celles que l’on voit dans les entreprises seront plus sympa à utiliser !</p>
-    </main>
+    </article>
    <footer>
      <ul>
            </ul>
@@ -21,7 +21,8 @@
    <link rel="alternate" type="application/rss" href="/feed.xml" title="elsif.fr/feed" />
  </head>
  <body>
-    <main>
+    <article>
+      <h1>OKAMI design: expo peinture</h1>
      <p>Rien à voir avec les pieds dans le code directement: je me permet un peu de pub pour Cyrou, un ami de longue date et Monique, une artiste/designeuse.</p>
      <p>Si vous aimez les japonaiserie je vous conseil d’aller faire un tour sur <a href="http://okami.fr/">Okami</a>.</p>
      <figure>
@@ -31,7 +32,7 @@
      <img src="http://elsif.fr/files/dessin_cyrou_tigre.jpg" alt="Un tigre de Cyrou- Okami design" /><figcaption>Un tigre de Cyrou- Okami design</figcaption>
      </figure>
      <p><a href="http://okami.fr/blog/fr/expo-de-peintures/">Monique expose jusqu’à fin mars quelques peintures chez Yin</a>, un restaurant que Cyril nous recommande.</p>
-    </main>
+    </article>
    <footer>
      <ul>
            </ul>
@@ -21,7 +21,8 @@
    <link rel="alternate" type="application/rss" href="/feed.xml" title="elsif.fr/feed" />
  </head>
  <body>
-    <main>
+    <article>
+      <h1>Git ou Mercurial lequel choisir ? Les deux mon général !</h1>
      <figure>
      <img src="http://elsif.fr/files/git-logo.png" alt="Git Logo" /><figcaption>Git Logo</figcaption>
      </figure>
@@ -35,7 +36,7 @@
      <figure>
      <img src="http://elsif.fr/files/mercurial-logo1.png" alt="Mercurial Logo" /><figcaption>Mercurial Logo</figcaption>
      </figure>
-    </main>
+    </article>
    <footer>
      <ul>
            </ul>
@@ -21,7 +21,8 @@
    <link rel="alternate" type="application/rss" href="/feed.xml" title="elsif.fr/feed" />
  </head>
  <body>
-    <main>
+    <article>
+      <h1>Appel de WebServices Soap en Ruby</h1>
      <figure>
      <img src="http://elsif.fr/files/soap.jpg" alt="Ruby Soap" /><figcaption>Ruby Soap</figcaption>
      </figure>
@@ -146,7 +147,7 @@
      </pre>
      <p>Au final, ça fonctionne plutôt bien et c’est en peut de temps que l’on a pu mettre en place cet appel. Soap est un protocole de communication verbeux, mais il a l’avantage d’être très bien intégré dans les divers langages et framework, et, dans notre cas, nous avons plusieurs technologie qui utilise ce service. On préfèrerais bien sur voir ici l’utilisation d’un service <a href="http://fr.wikipedia.org/wiki/Representational_State_Transfer">rest</a> mais il faudrais dans ce cas que les autres technologie soit capable de l’utiliser, et pour certaine techno un peu vieillissante, c’est pas facile (de plus reprendre le code existant a un coût).</p>
      <p>Je n’aime pas non plus le code généré pour plusieurs raison dont le manque de test. On sent aussi qu’avec les capacités dynamique de <a href="http://www.ruby-lang.org/">Ruby</a> on pourrais ne pas générer du code, mais construire <em>à la volé</em> les appels au service soap.</p>
-    </main>
+    </article>
    <footer>
      <ul>
            </ul>
@@ -21,7 +21,8 @@
    <link rel="alternate" type="application/rss" href="/feed.xml" title="elsif.fr/feed" />
  </head>
  <body>
-    <main>
+    <article>
+      <h1>Rework, sans rien changer…</h1>
      <p>Après avoir refermé ce nouveau bouquin de chez <a href="http://37signals.com/">37Signals</a>, je suis un peu déçu. <a href="http://37signals.com/rework/">Rework</a> n’est, de mon point de vue, qu’une version amélioré de <a href="http://gettingreal.37signals.com/">Getting Real</a>. C’était peut-être le but, mais du coup, je n’ai rien appris de nouveau.</p>
      <figure>
      <img src="/files/front-cover.png" alt="Rework" /><figcaption>Rework</figcaption>
@@ -29,7 +30,7 @@
      <p>Beaucoup de chose relève du bon sens et sont courament faite dans quelques sociétés. D’autres sont moins évidente, et on voit peu d’entreprise les mettre en place. Je pense notamment au fait de rester <em>petit</em>. Je vois trop de personnes pour qui la taille d’une boite indique une certaine puissance, notoriété ou encore tranquillité…</p>
      <p>Il y a par contre quelque choses avec lequel je ne suis pas d’accord: le fait de travailler à domicile, avec une équipe réparti. Je pense: pour pouvoir recruter les meilleurs des meilleurs il faut accepter de recruter à travers la planête. Pour moi, le fait de travailler en équipe, dans une même pièce est beaucoup plus efficace et important que de travailler avec la crème de la crème mondiale. Mon coté vert me dit que c’est pourtant bien de proner le travail à domicile… mais je préfère pouvoir discuter tout de suite avec quelqu’un quand j’ai besoin de le faire, et surtout voir quand son visage ce tord de douleur sur un bout de code, pour pouvoir lui venir en aide. Et j’aime à penser que les défaut de chaque membre de l’équipe servent a rendre l’équipe plus forte.</p>
      <p>En gros, lisez Rework plutôt que Getting Real si vous devez en choisir un. Et surtout (c’est d’ailleur dit dans un des premiers chapitres) restez vous même !</p>
-    </main>
+    </article>
    <footer>
      <ul>
            </ul>