Entre deux équipes qui sont bien constituées, celle qui met en place (en plus) des méthodes de travail sera probablement meilleure.
Sans doute. Encore que. Je pense que les méthodes qui marchent vont dépendre de ton équipe. Et du client.
Le coeur du truc, ce sont les gens et on l'oublie trop souvent. Il y a eu une époque où les clients choisissaient forcément la société qui disait le plus qu'elle appliquait la méthode agile. Résultat, un paquet de projets sont allés dans le mur. Et les clients en sont revenus. Sur la fin, on avait même des clients qui vérifiaient bien qu'on ne faisait pas de l'agile.
On avait notre méthode à nous qui correspondait à l'équipe, à comment on voulait faire nos projets et aux clients qu'on essayait d'avoir. Elle n'avait pas de nom mais elle nous correspondait. Et on l'adaptait aussi en fonction du client.
Globalement, ça me gêne qu'on théorise trop parce que ça généralise quelque chose qui ne l'est pas vraiment car avant tout bâti sur l'humain.
Je ne sais pas ce que tu entends par "faire des sites web"
Je voulais juste différencier application métier vs pur site de présentation mais tu as compris donc c'était assez clair comme ça ;).
Bref, tout ça pour dire qu'on fait bien des applications métier et qu'on est très content de le faire - pour les même raisons que toi :)
Ouais, ça peut vraiment être très intéressant, contrairement à ce que beaucoup de gens pensent. Mais j'ai changé de vie maintenant.
Le truc, c'est que tu te fais plaisir différemment. Par ailleurs, tu as un peu tronqué ce que je disais : il faut intégrer des nouvelles technos mais pas juste parce que c'est le dernier truc à la mode mais parce qu'elles apportent fondamentalement quelque chose - notamment se simplifier la vie et ne pas réinventer la roue.
Le fait de ne pas démarrer sans arrêt sur une nouvelle techno, c'est aussi ne pas refaire sans arrêt les mêmes choses : tu capitalises de projet en projet et du coup, tu fais des choses nouvelles et pas la même chose dans un nième langage différent parce qu'il est plus kikoo lol à l'instant t (et deviendra gavant à l'instant t+1).
Tu intègres des nouvelles technos quand elles ont un intérêt, pas juste pour dire de tester une nouvelle techno. C'est frustrant pour une catégorie de gens mais pas pour tous - comprendre pas pour ceux que j'embauchais :). Il y a des gens qui prennent plaisir à construire de belles choses sur des fondations solides. A optimiser les choses pour que le démarrage du prochain projet soit encore plus rapide, le projet encore plus efficace et moins répétitif. Evidemment, il faut que les fondations solides soient chouettes pour que ce soit plaisant. Sinon, ça ne marche pas bien.
Le fait d'avoir un socle préexistant, ça réduit le risque global, ça permet aussi de prendre plus de risques contrôlés sur des nouveaux enjeux. Du coup, on peut aussi tenter plus de choses.
Et tu trouves aussi ton plaisir sur les nouveaux défis qui sont amenés par les nouveaux projets (bien les choisir est important). Qu'il soit plus gros, plus technique, dans un domaine complètement différent, ça apporte de toute manière plein de choses.
Finalement, je pense que toute l'astuce est de faire en sorte que les gens trouvent un sens à ce qu'ils font. Ca marche en général bien mieux comme ça.
Ah et j'oubliais un point important également lié aux gens : la réussite d'un projet, ça dépend aussi en grande partie du client. Tu peux mettre une équipe de rêve qui donne tout pour que ce soit une réussite, avec le mauvais client, ça donnera un mauvais projet. L'envie de faire des belles choses et la confiance doivent être partagées, ça permet aussi de gagner un temps fou.
Le meilleur moyen de gagner du temps est d'avoir des "développeurs" qui sont capables de s'imprégner du métier des utilisateurs. Perso, je trouve le terme "développeur" un peu réducteur car le boulot ne se limite justement pas à développer.
Comprendre leurs enjeux, le pourquoi des tâches, ça change complètement la donne. Et ça évite énormément d'échanges et d'itérations inutiles.
Quelqu'un parlait d'ergonomie mais je pense que ça va même un peu plus loin que ça. Comprendre le métier de l'utilisateur, ça permet également de prendre du recul par rapport à ses souhaits pour lui proposer une meilleure solution qu'il n'avait pas imaginée. Ou alors, quelque chose d'assez classique, qu'il n'avait pas osé proposer car il pensait que ça prendrait trop de temps.
Si je devais résumer ce qui nous permettait d'aller vite et d'avoir des clients contents dans mon job précédent :
un socle technique réutilisé sur tous les projets
n'intégrer des nouvelles technos que si elles ont un apport manifeste
la capacité à générer le template du projet en une commande
une archi standard enrichie d'éléments spécifiques si nécessaire
des technos qui vont plutôt à l'opposé de la mode actuelle : plus c'est compilé, mieux c'est (tout en évitant la lourdeur)
des bonnes discussions avec le client pour comprendre le métier, les enjeux, le pourquoi du comment… Comme introduction, assez souvent, définir les grandes lignes du modèle de données avec eux aide bien à déblayer le terrain et à lever des loups, c'est un bon outil de discussion. Et creuser, toujours creuser pour mieux appréhender.
une équipe de gens intelligents qui prennent en compte ces enjeux, prennent du recul par rapport à ce qu'ils font et savent se placer dans la peau d'un utilisateur
une équipe qui bosse pour rendre les clients contents et pas que pour se faire plaisir techniquement
Et si on n'a pas les gens qui vont bien, on peut mettre en place toutes les méthodes qu'on veut, le résultat ne sera jamais terrible et ça prendra toujours plus longtemps que nécessaire. La clé, c'est de recruter les bonnes personnes pour construire une équipe efficace et qui se complète bien. Le reste, ça va plutôt tout seul.
Personnellement, un des trucs qui m'a toujours le plus plu dans ce métier (note : on bossait sur des applications métier, pas des sites web), c'est la capacité à découvrir des métiers totalement différents et de s'en imprégner, c'est vraiment super enrichissant et motivant. Et je pense qu'on devrait mettre cela plus en avant.
on passe d'une étape à la suivante (ou précédente) en roulant la molette de la souris
Pour être honnête, je ne trouve pas ça pratique du tout. Pour passer au slide suivant, un simple click serait appréciable. Jouer avec la molette est le meilleur moyen de ne jamais tomber sur le bon slide. C'est pas mal pour parcourir rapidement et revenir à un autre slide mais pour simplement faire avancer sa présentation, ce n'est pas terrible.
Par contre, je ne sais pas s'il est possible d'attraper le clic gauche seulement s'il ne porte pas sur un lien défini.
Ben si justement, cf le premier commentaire du thread :).
Enfin, je parlais d'AsciiDoctor mais je pense que c'est ce qu'il faut utiliser maintenant plutôt pour manipuler de l'Asciidoc. Et comme je le disais, la sortie PDF est maintenant très acceptable et on n'a plus besoin d'autre chose.
J'ai également posté des liens vers les sorties HTML et PDF de la doc d'Hibernate Validator faite avec AsciiDoctor dans un autre commentaire.
avec rolename étant ce que tu souhaites. On a utilisé classname et methodname fut un temps. Mais c'était assez verbeux et ça avait assez peu d'intérêt donc on a abandonné.
Pour le HTML, en dehors du logo, c'est la sortie par défaut. Pour le PDF, on a configuré un peu les polices car la police de code par défaut était un peu étrange.
Docbook a été très connu en fait. Il était énormément utilisé fut un temps. Je me rappelle même avoir fait quelques XSL simplifiées vers 2003 (ah ce petit plaisir coupable d'écrire du XSL…).
Il est relativement passé de mode maintenant, notamment à cause de son aspect verbeux qui le rend un peu pénible à écrire et assez pénible aussi à relire. Le temps de génération est aussi assez lourd comparé à l'outil dont je vais parler juste après.
Pour la documentation Hibernate, on est passé à AsciiDoctor (http://asciidoctor.org/) depuis quelques années pour la rédaction des documentations. On convertissait toujours la documentation en Docbook après pour avoir la sortie PDF, AsciiDoctor ne la proposant pas à l'époque. J'ai revisité le sujet récemment et AsciiDoctor a maintenant une chouette version PDF.
Pour les prochaines versions, on s'oriente donc maintenant vers une pure sortie AsciiDoctor (je vais pousser une nouvelle version d'Hibernate Validator dans l'aprèm avec le nouveau format de doc, je posterai des liens avant après).
La capacité à inclure facilement des bouts de code est vraiment chouette aussi. Il est également possible de relativement facilement ajouter des balisages complémentaires.
C'est en Ruby mais AsciiDoctor propose également un plugin Maven qui fonctionne par dessus JRuby. C'est ce dernier que nous utilisons.
Dans les moins par rapport à ce dont tu parlais, la sortie epub est encore assez perfectible pour des documentations du calibre de ce qu'on a. On a décidé de ne pas la publier pour l'instant.
Parce que l'idée est que les enregistrements DNS soient au maximum mis en cache pour accélérer la résolution. Si tu mets 5 mn, les caches des FAI vont respecter cela et réinterroger toutes les 5 minutes.
De plus, tu peux vite avoir des soucis avec des TTL aussi bas. Je me rappelle qu'on avait fini sur une liste de spam pour avoir un TTL trop bas sur un domaine (oubli de le remettre d'aplomb après une migration).
Bref, une fois ta phase de test/migration terminée, je le remettrai à une journée.
Perso, j'ai fait MPSI/MP avec option SI - quasi pas d'info avant d'arriver en école d'ingé et ce qui a fait que je me suis orienté vers l'info, ce sont les activités associatives en école d'ingé.
Ce qui m'a franchement le plus servi, ce sont justement toutes ces années de maths, pas les connaissances en elle-même, mais la manière de réfléchir, la logique, la capacité à comprendre une démonstration, à se l'approprier, la capacité à se concentrer pour comprendre des problèmes complexes, la créativité que certains exercices induisent aussi.
Partir du principe que l'étude d'une matière est inutile car elle ne servira pas concrètement n'est pas la bonne démarche.
L'Histoire non plus ça ne sert à rien. Et pourtant, savoir un peu ce qu'a été la guerre - au delà des films qui mettent en exergue l'héroïsme et les gentils - que c'est crade, horrible, ben, c'est con, mais ça donne moyen envie de reproduire la chose. Se rappeler combien l'Europe était instable avant la construction de l'Union Européenne, c'est aussi utile pour apprécier la stabilité que l'UE a apporté, comment ça a donné l'impression de faire partie d'un tout (et la monnaie européenne a pas mal aidé), au delà des critiques et des remises en cause.
Bref, profite de tes études et construis toi, ce ne sera pas inutile.
Que 16 - je suis passé juste avant que ce soit 32 par défaut. Je dois avouer qu'avec 4-5 Eclipse ouverts + 2 navigateurs + les builds Maven, 32 ne seraient pas de trop (enfin 24 seraient suffisants).
Pour l'autonomie, je dois avouer que je suis principalement sédentaire. C'était tout pourri au début jusqu'à ce que le noyau supporte les Skylake. Maintenant, je dirai genre 4h en utilisation dév un peu intensive (avec la batterie qui dépasse un peu mais je ne sais pas si c'est la 46 ou la 72). A vue de nez parce que ce n'est pas mon utilisation courante.
Perso, pour bosser, je suis adepte du 14 pouces depuis bien 10 ans, je trouve que c'est le bon compromis.
Bon, par contre, côté écran, j'ai le 1920, ça ne vaut clairement pas un retina côté finesse mais ça tient la route quand même.
C'est clairement un modèle moins hype/tape à l'oeil que les XPS mais j'en suis vraiment très content au quotidien. Et, même esthétiquement, son côté tout noir mat tout simple me plaît bien. Un petit sticker Red Hat dans le coin et il est le plus beau pour aller coder.
Le seul truc sur lequel je n'ai pas d'avis, c'est le touchpad/trackpoint. Je ne m'en sers jamais parce que je déteste ça. Visiblement avec quelques réglages de vitesse/sensibilité, des gens les trouvent utilisables :).
Bon courage pour ton choix, ce n'est jamais évident de choisir sans pouvoir passer quelques semaines avec !
Je ne saurai pas trop dire : une certaine fermeté dans le retour qui est super agréable. A l'usage, j'ai vraiment du mal avec les autres claviers maintenant.
Ah et les touches qui sont en face des doigts (comprendre une disposition très classique).
Pour le support dans les Fedora, ce sont les modèles qu'on a par défaut chez Red Hat pour les ingénieurs maintenant. J'ai juste entendu parler de quelques soucis avec le dock qui méritait une mise à jour de bios (le bios du dock), qui malheureusement nécessiterait un Windows… Perso, je n'utilise pas le dock donc je n'ai pas d'expérience à partager sur le sujet.
+1 même si c'est un 14 pouces par contre (j'ai la version avec i7+nvidia avec optimus, pas eu spécialement de souci). Il est très fin avec juste une petite ex croissance pour le modèle de batterie que j'ai mais c'est plutôt pas mal parce que ça l'incline légèrement et je trouve ça plus agréable à la longue.
C'est vraiment super agréable de bosser dessus, le clavier est vraiment très très chouette.
PS : la lettre p a son importance dans le modèle, le T460s n'est pas le même.
Pour le salaire, je ne donnerai que le brut annuel. C'est toujours comme cela que j'ai parlé salaire avec mes employeurs et avec les candidats que j'ai pu voir.
Et ça t'éviterait une formule comme "le salaire est estimé autour de" qui ne donne pas trop confiance.
Dans les infos à préparer pour la suite, il y a le sujet de la mutuelle. C'est un sujet qui peut jouer, en particulier pour les gens qui ont une famille. Me semble qu'elle est obligatoire même pour les petites boîtes maintenant ? Ou ça a été retardé ?
Pour la situation, donne aussi la ville un peu grande la plus proche. Je ne sais pas si Pierrelatte est connu dans ton coin (si ça l'est, choisis ca) mais Orange, ça l'est. Quelque chose comme à 35 minutes d'Orange et 1h de …
Mouais. Perso, je sais lire, merci, mais je trouve ce qui est en train de devenir une habitude sur le site particulièrement désagréable à lire. Ca casse le rythme et ça demande une gymnastique complètement inutile. A peu près aussi désagréable que l'absence d'accent ou les fautes d'orthographe/grammaire. Et personnellement, ça me rend plutôt irritable que tolérant.
Encore une fois, ce n'est pas une affaire de domination mais de grammaire. Ca me fait bien rire ton "on "milite" pour l'universalisme masculin". Je pense franchement que "féminiser" (mais quelle idée d'appliquer cela à un texte…) un texte a tout à fait l'effet contraire de ce que vous recherchez.
On va devoir écrire un-e person-ne ? Ben ouais une personne est féminin et désigne aussi bien un homme qu'une femme, quel problème ça peut bien poser ?
Je suppose que dans quelques années, on aura la version masculin/féminin/ne sait pas (le "questioning" anglais).
Je trouve ça beaucoup plus dérangeant et discriminant de tout sexuer. Et j'ai envie de dire que la plus grande marque d'égalité est justement de ne pas se poser la question et de ne pas y faire attention. Qu'un utilisateur soit un homme, une femme, un transgenre, whatever, quelle importance ?
Que vous militiez pour quelque chose, c'est votre droit, que vous l'imposiez à tous, c'est déjà plus discutable, que les gens n'aient pas le droit de dire que c'est extrêmement désagréable sous peine d'avoir droit à un discours sentencieux et moralisateur, c'est un peu fort de café.
PGDP date de 2000, je me rappelle avoir participé en 2001-2002.
Ca date même d'avant Wikipedia, et donc bien avant Wikisource.
Ca ne règle pas le problème de la dispersion des forces mais on ne peut pas vraiment leur reprocher d'avoir réinventé la roue vu que c'était largement le premier projet de grande ampleur de ce type.
Bon, c'est vraiment un détail, mais sur le dernier écran de configuration qu'on voit sur la capture, il faudrait vraiment faire un :
s/une location/un emplacement/
A moins qu'il faille louer un appartement pour y mettre ses fichiers :).
un don déductible permet de donner plus à tarif équivalent
Pas vraiment. Tu décides juste que cette association mérite plus cet argent que l'Etat et sa mission globale.
C'est quand même important dans la réflexion plutôt que simplement te dire que ton don te coûte moins cher et que tu peux donner plus.
Ce raisonnement de "tu donnes 75 euros, ça ne te coûte que 25 euros" est clairement véhiculé par beaucoup d'associations. L'équation n'est quand même pas exactement celle-là : si tu veux donner 25 euros et qu'en fait tu donnes 75 et que tu déduis le reste de tes impôts, ton budget à toi est constant mais le budget de l'Etat, non.
Ca pourrait sans doute se faire. Pour l'instant, nous n'avons pas implémenté les API Rest de Nexus ou d'Artifactory comme sources de données. On risque vite d'avoir le souci de plusieurs artifacts non cohérents entre des repositories distincts et ça va vite compliquer l'interface, notre objectif étant vraiment au départ de faire un truc simple qui juste marche et qui permette en quelques clics d'avoir géré le plus gros.
Par ailleurs, pour le besoin des grosses boutiques, je pense qu'il faudrait sans doute l'installer en interne car je vois mal une grosse boutique accorder la vision sur son repository interne à un outil externe.
La feature "regrouper les artifacts sous des projets" ce serait vraiment cool aussi pour retrouver les pom à mettre à jour
Maven ne le fait pas déjà de base ?
Yep, Maven le fait de base mais c'est vrai qu'on pense rarement à le faire. D'où le fait qu'un petit push a du bon. En particulier quand on attend une correction de bug avec beaucoup d'impatience.
Le fait de savoir qu'un artifact est utilisé par tel projet peut finalement aussi nous servir à faire le ménage.
Mais bon d'une manière générale tu connais tes dépendences, comment chacun gère ses releases
Ouais, je dois avouer que je fais quand même un tour sur les changelogs en général pour voir si ça vaut le coup de prendre le risque en fonction du moment et du temps qu'on a.
Après, notre usage est sans doute un peu particulier vu qu'on maintient un socle avec plein de projets en dessous.
[^] # Re: Les gens.
Posté par Guillaume Smet (site web personnel) . En réponse au journal Réduire les temps de développement sans sacrifier la qualité. Évalué à 2.
Sans doute. Encore que. Je pense que les méthodes qui marchent vont dépendre de ton équipe. Et du client.
Le coeur du truc, ce sont les gens et on l'oublie trop souvent. Il y a eu une époque où les clients choisissaient forcément la société qui disait le plus qu'elle appliquait la méthode agile. Résultat, un paquet de projets sont allés dans le mur. Et les clients en sont revenus. Sur la fin, on avait même des clients qui vérifiaient bien qu'on ne faisait pas de l'agile.
On avait notre méthode à nous qui correspondait à l'équipe, à comment on voulait faire nos projets et aux clients qu'on essayait d'avoir. Elle n'avait pas de nom mais elle nous correspondait. Et on l'adaptait aussi en fonction du client.
Globalement, ça me gêne qu'on théorise trop parce que ça généralise quelque chose qui ne l'est pas vraiment car avant tout bâti sur l'humain.
Je voulais juste différencier application métier vs pur site de présentation mais tu as compris donc c'était assez clair comme ça ;).
Ouais, ça peut vraiment être très intéressant, contrairement à ce que beaucoup de gens pensent. Mais j'ai changé de vie maintenant.
Bonne continuation en tout cas.
[^] # Re: Les gens.
Posté par Guillaume Smet (site web personnel) . En réponse au journal Réduire les temps de développement sans sacrifier la qualité. Évalué à 1. Dernière modification le 22 février 2017 à 13:07.
Le truc, c'est que tu te fais plaisir différemment. Par ailleurs, tu as un peu tronqué ce que je disais : il faut intégrer des nouvelles technos mais pas juste parce que c'est le dernier truc à la mode mais parce qu'elles apportent fondamentalement quelque chose - notamment se simplifier la vie et ne pas réinventer la roue.
Le fait de ne pas démarrer sans arrêt sur une nouvelle techno, c'est aussi ne pas refaire sans arrêt les mêmes choses : tu capitalises de projet en projet et du coup, tu fais des choses nouvelles et pas la même chose dans un nième langage différent parce qu'il est plus kikoo lol à l'instant t (et deviendra gavant à l'instant t+1).
Tu intègres des nouvelles technos quand elles ont un intérêt, pas juste pour dire de tester une nouvelle techno. C'est frustrant pour une catégorie de gens mais pas pour tous - comprendre pas pour ceux que j'embauchais :). Il y a des gens qui prennent plaisir à construire de belles choses sur des fondations solides. A optimiser les choses pour que le démarrage du prochain projet soit encore plus rapide, le projet encore plus efficace et moins répétitif. Evidemment, il faut que les fondations solides soient chouettes pour que ce soit plaisant. Sinon, ça ne marche pas bien.
Le fait d'avoir un socle préexistant, ça réduit le risque global, ça permet aussi de prendre plus de risques contrôlés sur des nouveaux enjeux. Du coup, on peut aussi tenter plus de choses.
Et tu trouves aussi ton plaisir sur les nouveaux défis qui sont amenés par les nouveaux projets (bien les choisir est important). Qu'il soit plus gros, plus technique, dans un domaine complètement différent, ça apporte de toute manière plein de choses.
Finalement, je pense que toute l'astuce est de faire en sorte que les gens trouvent un sens à ce qu'ils font. Ca marche en général bien mieux comme ça.
Ah et j'oubliais un point important également lié aux gens : la réussite d'un projet, ça dépend aussi en grande partie du client. Tu peux mettre une équipe de rêve qui donne tout pour que ce soit une réussite, avec le mauvais client, ça donnera un mauvais projet. L'envie de faire des belles choses et la confiance doivent être partagées, ça permet aussi de gagner un temps fou.
# Les gens.
Posté par Guillaume Smet (site web personnel) . En réponse au journal Réduire les temps de développement sans sacrifier la qualité. Évalué à 6.
Le meilleur moyen de gagner du temps est d'avoir des "développeurs" qui sont capables de s'imprégner du métier des utilisateurs. Perso, je trouve le terme "développeur" un peu réducteur car le boulot ne se limite justement pas à développer.
Comprendre leurs enjeux, le pourquoi des tâches, ça change complètement la donne. Et ça évite énormément d'échanges et d'itérations inutiles.
Quelqu'un parlait d'ergonomie mais je pense que ça va même un peu plus loin que ça. Comprendre le métier de l'utilisateur, ça permet également de prendre du recul par rapport à ses souhaits pour lui proposer une meilleure solution qu'il n'avait pas imaginée. Ou alors, quelque chose d'assez classique, qu'il n'avait pas osé proposer car il pensait que ça prendrait trop de temps.
Si je devais résumer ce qui nous permettait d'aller vite et d'avoir des clients contents dans mon job précédent :
Et si on n'a pas les gens qui vont bien, on peut mettre en place toutes les méthodes qu'on veut, le résultat ne sera jamais terrible et ça prendra toujours plus longtemps que nécessaire. La clé, c'est de recruter les bonnes personnes pour construire une équipe efficace et qui se complète bien. Le reste, ça va plutôt tout seul.
Personnellement, un des trucs qui m'a toujours le plus plu dans ce métier (note : on bossait sur des applications métier, pas des sites web), c'est la capacité à découvrir des métiers totalement différents et de s'en imprégner, c'est vraiment super enrichissant et motivant. Et je pense qu'on devrait mettre cela plus en avant.
# Liquibase, Flyway...
Posté par Guillaume Smet (site web personnel) . En réponse au message Demande d'informations sur Gestion versionning Data base . Évalué à 2.
Salut,
Le mieux est sans doute de regarder du côté des gens qui ont déjà résolu ce souci :
Ce n'est pas un sujet si simple.
--
Guillaume
[^] # Re: Navigation par liens ?
Posté par Guillaume Smet (site web personnel) . En réponse à la dépêche PAMPI — Présentations avec Markdown, Pandoc, Impress. Évalué à 4.
Bonjour,
Pour être honnête, je ne trouve pas ça pratique du tout. Pour passer au slide suivant, un simple click serait appréciable. Jouer avec la molette est le meilleur moyen de ne jamais tomber sur le bon slide. C'est pas mal pour parcourir rapidement et revenir à un autre slide mais pour simplement faire avancer sa présentation, ce n'est pas terrible.
Par contre, je ne sais pas s'il est possible d'attraper le clic gauche seulement s'il ne porte pas sur un lien défini.
[^] # Re: Aaaah Docbook...
Posté par Guillaume Smet (site web personnel) . En réponse au journal DocBook ou l'art d'écrire de la documentation. Évalué à 3.
Ben si justement, cf le premier commentaire du thread :).
Enfin, je parlais d'AsciiDoctor mais je pense que c'est ce qu'il faut utiliser maintenant plutôt pour manipuler de l'Asciidoc. Et comme je le disais, la sortie PDF est maintenant très acceptable et on n'a plus besoin d'autre chose.
J'ai également posté des liens vers les sorties HTML et PDF de la doc d'Hibernate Validator faite avec AsciiDoctor dans un autre commentaire.
[^] # Re: Aaaah Docbook...
Posté par Guillaume Smet (site web personnel) . En réponse au journal DocBook ou l'art d'écrire de la documentation. Évalué à 3.
Tu peux utiliser
[rolename]`monospace text`
avec rolename étant ce que tu souhaites. On a utilisé classname et methodname fut un temps. Mais c'était assez verbeux et ça avait assez peu d'intérêt donc on a abandonné.
Chercher "Role-playing for text enclosed in backticks" dans http://asciidoctor.org/docs/user-manual/ .
Je dois avouer que j'étais plutôt de ton avis fut un temps mais à l'usage on y gagne en lisibilité et en légèreté.
[^] # Re: Aaaah Docbook...
Posté par Guillaume Smet (site web personnel) . En réponse au journal DocBook ou l'art d'écrire de la documentation. Évalué à 6.
Du coup, le résultat est là :
- HTML : https://docs.jboss.org/hibernate/stable/validator/reference/en-US/html_single/
- PDF : https://docs.jboss.org/hibernate/stable/validator/reference/en-US/pdf/hibernate_validator_reference.pdf
Pour le HTML, en dehors du logo, c'est la sortie par défaut. Pour le PDF, on a configuré un peu les polices car la police de code par défaut était un peu étrange.
# Aaaah Docbook...
Posté par Guillaume Smet (site web personnel) . En réponse au journal DocBook ou l'art d'écrire de la documentation. Évalué à 8.
Docbook a été très connu en fait. Il était énormément utilisé fut un temps. Je me rappelle même avoir fait quelques XSL simplifiées vers 2003 (ah ce petit plaisir coupable d'écrire du XSL…).
Il est relativement passé de mode maintenant, notamment à cause de son aspect verbeux qui le rend un peu pénible à écrire et assez pénible aussi à relire. Le temps de génération est aussi assez lourd comparé à l'outil dont je vais parler juste après.
Pour la documentation Hibernate, on est passé à AsciiDoctor (http://asciidoctor.org/) depuis quelques années pour la rédaction des documentations. On convertissait toujours la documentation en Docbook après pour avoir la sortie PDF, AsciiDoctor ne la proposant pas à l'époque. J'ai revisité le sujet récemment et AsciiDoctor a maintenant une chouette version PDF.
Pour les prochaines versions, on s'oriente donc maintenant vers une pure sortie AsciiDoctor (je vais pousser une nouvelle version d'Hibernate Validator dans l'aprèm avec le nouveau format de doc, je posterai des liens avant après).
Un exemple de bout de doc :
- version rendue par GitHub (c'est aussi un des avantages) : https://github.com/hibernate/hibernate-validator/blob/master/documentation/src/main/asciidoc/ch02.asciidoc
- version code : https://raw.githubusercontent.com/hibernate/hibernate-validator/master/documentation/src/main/asciidoc/ch02.asciidoc
La capacité à inclure facilement des bouts de code est vraiment chouette aussi. Il est également possible de relativement facilement ajouter des balisages complémentaires.
C'est en Ruby mais AsciiDoctor propose également un plugin Maven qui fonctionne par dessus JRuby. C'est ce dernier que nous utilisons.
Dans les moins par rapport à ce dont tu parlais, la sortie epub est encore assez perfectible pour des documentations du calibre de ce qu'on a. On a décidé de ne pas la publier pour l'instant.
Je conseille chaudement.
# Eléments de réponse
Posté par Guillaume Smet (site web personnel) . En réponse au message Bonne valeur pour TTL sur nom de domaine. Évalué à 2.
Parce que l'idée est que les enregistrements DNS soient au maximum mis en cache pour accélérer la résolution. Si tu mets 5 mn, les caches des FAI vont respecter cela et réinterroger toutes les 5 minutes.
De plus, tu peux vite avoir des soucis avec des TTL aussi bas. Je me rappelle qu'on avait fini sur une liste de spam pour avoir un TTL trop bas sur un domaine (oubli de le remettre d'aplomb après une migration).
Bref, une fois ta phase de test/migration terminée, je le remettrai à une journée.
# Typo sur le site kymeria.fr
Posté par Guillaume Smet (site web personnel) . En réponse au message Stage Python/Linux Lyon (5-6 mois). Évalué à 3.
Hello,
Pas grand rapport avec l'annonce, désolé, mais sur la page http://kymeria.fr/technologies/, il y a une petite typo :
Le "façons" semble de trop.
[^] # Re: Rester en prépa :)
Posté par Guillaume Smet (site web personnel) . En réponse au message Encore une question d'orientation... Rester en prépa ou partir en fac ?. Évalué à 2.
Perso, j'ai fait MPSI/MP avec option SI - quasi pas d'info avant d'arriver en école d'ingé et ce qui a fait que je me suis orienté vers l'info, ce sont les activités associatives en école d'ingé.
Ce qui m'a franchement le plus servi, ce sont justement toutes ces années de maths, pas les connaissances en elle-même, mais la manière de réfléchir, la logique, la capacité à comprendre une démonstration, à se l'approprier, la capacité à se concentrer pour comprendre des problèmes complexes, la créativité que certains exercices induisent aussi.
Partir du principe que l'étude d'une matière est inutile car elle ne servira pas concrètement n'est pas la bonne démarche.
L'Histoire non plus ça ne sert à rien. Et pourtant, savoir un peu ce qu'a été la guerre - au delà des films qui mettent en exergue l'héroïsme et les gentils - que c'est crade, horrible, ben, c'est con, mais ça donne moyen envie de reproduire la chose. Se rappeler combien l'Europe était instable avant la construction de l'Union Européenne, c'est aussi utile pour apprécier la stabilité que l'UE a apporté, comment ça a donné l'impression de faire partie d'un tout (et la monnaie européenne a pas mal aidé), au delà des critiques et des remises en cause.
Bref, profite de tes études et construis toi, ce ne sera pas inutile.
[^] # Re: Lenovo T460p
Posté par Guillaume Smet (site web personnel) . En réponse au message Support Dell XPS 13 ?. Évalué à 1.
Que 16 - je suis passé juste avant que ce soit 32 par défaut. Je dois avouer qu'avec 4-5 Eclipse ouverts + 2 navigateurs + les builds Maven, 32 ne seraient pas de trop (enfin 24 seraient suffisants).
Pour l'autonomie, je dois avouer que je suis principalement sédentaire. C'était tout pourri au début jusqu'à ce que le noyau supporte les Skylake. Maintenant, je dirai genre 4h en utilisation dév un peu intensive (avec la batterie qui dépasse un peu mais je ne sais pas si c'est la 46 ou la 72). A vue de nez parce que ce n'est pas mon utilisation courante.
Perso, pour bosser, je suis adepte du 14 pouces depuis bien 10 ans, je trouve que c'est le bon compromis.
Bon, par contre, côté écran, j'ai le 1920, ça ne vaut clairement pas un retina côté finesse mais ça tient la route quand même.
C'est clairement un modèle moins hype/tape à l'oeil que les XPS mais j'en suis vraiment très content au quotidien. Et, même esthétiquement, son côté tout noir mat tout simple me plaît bien. Un petit sticker Red Hat dans le coin et il est le plus beau pour aller coder.
Le seul truc sur lequel je n'ai pas d'avis, c'est le touchpad/trackpoint. Je ne m'en sers jamais parce que je déteste ça. Visiblement avec quelques réglages de vitesse/sensibilité, des gens les trouvent utilisables :).
Bon courage pour ton choix, ce n'est jamais évident de choisir sans pouvoir passer quelques semaines avec !
[^] # Re: Lenovo T460p
Posté par Guillaume Smet (site web personnel) . En réponse au message Support Dell XPS 13 ?. Évalué à 1.
Je ne saurai pas trop dire : une certaine fermeté dans le retour qui est super agréable. A l'usage, j'ai vraiment du mal avec les autres claviers maintenant.
Ah et les touches qui sont en face des doigts (comprendre une disposition très classique).
Pour le support dans les Fedora, ce sont les modèles qu'on a par défaut chez Red Hat pour les ingénieurs maintenant. J'ai juste entendu parler de quelques soucis avec le dock qui méritait une mise à jour de bios (le bios du dock), qui malheureusement nécessiterait un Windows… Perso, je n'utilise pas le dock donc je n'ai pas d'expérience à partager sur le sujet.
[^] # Re: Lenovo T460p
Posté par Guillaume Smet (site web personnel) . En réponse au message Support Dell XPS 13 ?. Évalué à 1.
+1 même si c'est un 14 pouces par contre (j'ai la version avec i7+nvidia avec optimus, pas eu spécialement de souci). Il est très fin avec juste une petite ex croissance pour le modèle de batterie que j'ai mais c'est plutôt pas mal parce que ça l'incline légèrement et je trouve ça plus agréable à la longue.
C'est vraiment super agréable de bosser dessus, le clavier est vraiment très très chouette.
PS : la lettre p a son importance dans le modèle, le T460s n'est pas le même.
[^] # Re: Nouvelle annonce
Posté par Guillaume Smet (site web personnel) . En réponse au journal Trouver un développeur. Évalué à 4.
Pour le salaire, je ne donnerai que le brut annuel. C'est toujours comme cela que j'ai parlé salaire avec mes employeurs et avec les candidats que j'ai pu voir.
Et ça t'éviterait une formule comme "le salaire est estimé autour de" qui ne donne pas trop confiance.
Dans les infos à préparer pour la suite, il y a le sujet de la mutuelle. C'est un sujet qui peut jouer, en particulier pour les gens qui ont une famille. Me semble qu'elle est obligatoire même pour les petites boîtes maintenant ? Ou ça a été retardé ?
Pour la situation, donne aussi la ville un peu grande la plus proche. Je ne sais pas si Pierrelatte est connu dans ton coin (si ça l'est, choisis ca) mais Orange, ça l'est. Quelque chose comme à 35 minutes d'Orange et 1h de …
[^] # Re: Rubrique à brac
Posté par Guillaume Smet (site web personnel) . En réponse au journal Une charade. Évalué à 10.
Ben, il aurait dit un person si c'était un homme et un-e person-ne si on ne savait pas.
[^] # Re: Les fotes restantes
Posté par Guillaume Smet (site web personnel) . En réponse à la dépêche Unixcorn, trois mois plus tard : évolutions, remises en questions et stabilisation. Évalué à 10.
Mouais. Perso, je sais lire, merci, mais je trouve ce qui est en train de devenir une habitude sur le site particulièrement désagréable à lire. Ca casse le rythme et ça demande une gymnastique complètement inutile. A peu près aussi désagréable que l'absence d'accent ou les fautes d'orthographe/grammaire. Et personnellement, ça me rend plutôt irritable que tolérant.
Encore une fois, ce n'est pas une affaire de domination mais de grammaire. Ca me fait bien rire ton "on "milite" pour l'universalisme masculin". Je pense franchement que "féminiser" (mais quelle idée d'appliquer cela à un texte…) un texte a tout à fait l'effet contraire de ce que vous recherchez.
On va devoir écrire un-e person-ne ? Ben ouais une personne est féminin et désigne aussi bien un homme qu'une femme, quel problème ça peut bien poser ?
Je suppose que dans quelques années, on aura la version masculin/féminin/ne sait pas (le "questioning" anglais).
Je trouve ça beaucoup plus dérangeant et discriminant de tout sexuer. Et j'ai envie de dire que la plus grande marque d'égalité est justement de ne pas se poser la question et de ne pas y faire attention. Qu'un utilisateur soit un homme, une femme, un transgenre, whatever, quelle importance ?
Que vous militiez pour quelque chose, c'est votre droit, que vous l'imposiez à tous, c'est déjà plus discutable, que les gens n'aient pas le droit de dire que c'est extrêmement désagréable sous peine d'avoir droit à un discours sentencieux et moralisateur, c'est un peu fort de café.
[^] # Re: Wikisource
Posté par Guillaume Smet (site web personnel) . En réponse au journal pgdp.net: Contribuer à des projets libres quand on a pas le temps. Évalué à 4.
PGDP date de 2000, je me rappelle avoir participé en 2001-2002.
Ca date même d'avant Wikipedia, et donc bien avant Wikisource.
Ca ne règle pas le problème de la dispersion des forces mais on ne peut pas vraiment leur reprocher d'avoir réinventé la roue vu que c'était largement le premier projet de grande ampleur de ce type.
# Petit détail
Posté par Guillaume Smet (site web personnel) . En réponse à la dépêche Synchronisez vos fichiers avec cozy-desktop. Évalué à 2.
Bon, c'est vraiment un détail, mais sur le dernier écran de configuration qu'on voit sur la capture, il faudrait vraiment faire un :
s/une location/un emplacement/
A moins qu'il faille louer un appartement pour y mettre ses fichiers :).
# Et...
Posté par Guillaume Smet (site web personnel) . En réponse à la dépêche Publication de la version 2.0 du moteur de jeu libre Godot Engine. Évalué à 6.
Et du coup, on attend encore quelqu'un ou on peut y aller ?
# ...
Posté par Guillaume Smet (site web personnel) . En réponse à la dépêche Appel à contribution pour l’écriture d’un manuel GodotEngine. Évalué à 4.
On a bien fait d'attendre !
[^] # Re: Defiscalisation ?
Posté par Guillaume Smet (site web personnel) . En réponse à la dépêche La Quadrature du Net a besoin de soutien pour boucler son budget 2013. Évalué à 10.
Pas vraiment. Tu décides juste que cette association mérite plus cet argent que l'Etat et sa mission globale.
C'est quand même important dans la réflexion plutôt que simplement te dire que ton don te coûte moins cher et que tu peux donner plus.
Ce raisonnement de "tu donnes 75 euros, ça ne te coûte que 25 euros" est clairement véhiculé par beaucoup d'associations. L'équation n'est quand même pas exactement celle-là : si tu veux donner 25 euros et qu'en fait tu donnes 75 et que tu déduis le reste de tes impôts, ton budget à toi est constant mais le budget de l'Etat, non.
[^] # Re: proxy type nexus
Posté par Guillaume Smet (site web personnel) . En réponse au journal Artifact Listener - Service de notification pour Maven Central - Java inside. Évalué à 1.
Hello,
Ca pourrait sans doute se faire. Pour l'instant, nous n'avons pas implémenté les API Rest de Nexus ou d'Artifactory comme sources de données. On risque vite d'avoir le souci de plusieurs artifacts non cohérents entre des repositories distincts et ça va vite compliquer l'interface, notre objectif étant vraiment au départ de faire un truc simple qui juste marche et qui permette en quelques clics d'avoir géré le plus gros.
Par ailleurs, pour le besoin des grosses boutiques, je pense qu'il faudrait sans doute l'installer en interne car je vois mal une grosse boutique accorder la vision sur son repository interne à un outil externe.
Guillaume
[^] # Re: Ça a l'air sympa
Posté par Guillaume Smet (site web personnel) . En réponse au journal Artifact Listener - Service de notification pour Maven Central - Java inside. Évalué à 1.
Yep, Maven le fait de base mais c'est vrai qu'on pense rarement à le faire. D'où le fait qu'un petit push a du bon. En particulier quand on attend une correction de bug avec beaucoup d'impatience.
Le fait de savoir qu'un artifact est utilisé par tel projet peut finalement aussi nous servir à faire le ménage.
Ouais, je dois avouer que je fais quand même un tour sur les changelogs en général pour voir si ça vaut le coup de prendre le risque en fonction du moment et du temps qu'on a.
Après, notre usage est sans doute un peu particulier vu qu'on maintient un socle avec plein de projets en dessous.