Strash a écrit 981 commentaires

Très bonne idée le projecteur halogène !

Je viens d'acheter une maison et j'avais l'idée de faire une installation similaire pour enregistrer les évolutions du jardin.

Merci pour toute ces infos !

Désolé, je n'ai pas de réponse à ta question mais je suis hyper intéressé pour connaître comment est ton installation pour obtenir de telles photos.

Est-ce en pleine nature ? Comment est-ce alimenté ? Quelle est la caméra utilisée ?

Merci !

200 annonces avec autant de variables, je suis pas sûr qu'une quelconque analyse donne quelque chose.

Surtout que rien n'empêche les autres acteurs de récupérer les données, de les compléter, etc… On voit ça très bien avec OpenStreetMap où on utilise largement des opendata pour compléter la carte (le Cadastre par exemple), puis les données sont enrichies et publiées.

De nombreuses boîtes impriment des PCB à la demande, pour quelques euros. Le prix est dégressif avec la quantité.

Bon, la plupart sont en chine et il faut pas être pressé, mais c'est bien plus pratique que de faire la gravure soi-même, et tu peux même faire des PCB multi-couches.

Exemple (parmi la myriade que tu peux trouver avec une recherche rapide) : https://www.pcbway.com/

pyinstaller ne compile pas le code python, il crée un exécutable qui contiens lui même l'interpréteur python.

Je pense qu'il faut que vous arrêtiez d'essayer de faire de la physique et de l’ingénierie de comptoir.

Un échangeur de chaleur, surtout un échangeur air-eau, ça ne fonctionne pas bien si le delta-T n'est pas assez grand. Utiliser des matériaux très cher à produire (écologiquement comme de façon pécuniaire), comme du cuivre (car pour transférer 10W à de l'eau par un échangeur air-eau, il va falloir avoir un sacré radiateur bien performant), le tout bien isolé pour pas que le radiateur fasse l'effet inverse. J'imagine pas le coût écologique d'un tel échangeur, tout ça pour transférer 10W ?

Le bilan carbone de l'opération doit terrible.

Tout ça me rappelle la fabuleuse aventure de l'arbre à vent. Ou comment ne pas comprendre que le facteur d'échelle est important en physique.

Pour de l'eau chaude il faut un sacré serveur quand même… un tout petit ballon d'eau chaude (75l) a quand même une épingle électrique de 1200 W !

C'est bête, maintenant tu as fait 100 fois la faute au nom de famille !

je trouvais cela fastidieux de repasser par la phase d'importation à chaque ouverture

Je ne comprends pas vraiment de quoi tu parles quand tu dis "phase d'importation". Si ton tableur est bien configuré, il devrait pouvoir ouvrir et manipuler les csv sans avoir à l'importer.

Imprimer les photos, acheter des post-it en forme de bulle de BD, quelques feuilles A3 et un bâton de colle.

Du coup si c'est impossible de faire des merge et des diff, quel est l'intérêt que tu as trouvé à imposer Markdown à ton équipe à la place de Word ? (au cas où tu penses que cette question est du troll, c'est l'inverse, je suis vraiment intéressé par le gain d'un Markdown sur du WYSIWYG)

Je ne partage pas en totalité ton analyse. Dans mes différentes boîtes j'ai souvent vu des transitions d'outils qui se sont certes plus ou moins bien passées, mais qui au final ont été adoptées et utilisées. Que ce soit par exemple l'adoption de Sharepoint pour le partage des documents, OneNote pour les comptes rendus de réunion jusqu'au changement d'ERP, etc… Cela montre que lorsqu'on fourni un outil adapté, les utilisateurs ne sont pas totalement réfractaires et franchissent le pas.

Mon constat est juste que de nombreuses personnes crachent sur Word, mais personne n'est capable de fournir une alternative viable en face. XML, LateX ou Markdown sont juste trop en deçà au niveau fonctionnalité et facilité de prise en main, et nécessitent un effort trop important pour l'utilisateur sans bénéfice réel à leurs yeux.

Cependant je ne cherche pas à remplacer Word totalement mais seulement pour l'application spécifique de la gestion de documentation technique, et je constate (grâce aux nombreuses réponses à ce post) que de nombreuses industries se tournent vers d'autres solutions (DITA, etc…). Je pense donc que c'est du domaine du possible d'appliquer la même chose chez moi.

Reste à trouver l'outil le mieux adapté à mon besoin.

Bah quand même… N'as-tu pas remarqué que c'est toujours le point bloquant ?

Étant ingénieur en mécanique, j'ai une approche pragmatique des outils. Si les utilisateurs à qui on destine l'outil n'arrivent pas à l'utiliser, c'est que l'outil n'est pas adapté.

Je ne parles pas ici d'un utilisateur en particulier, mais d'un profil d'utilisateur. Mes utilisateurs ici ne sont pas des informaticiens, ils sont avant tout concepteurs en mécanique, hydraulique, électrotechnique, etc… Et c'est ces compétences là que l'on va rechercher lorsqu'on va les recruter.

L'outil doit s'adapter à eux, et non pas l'inverse.

Cette solution me semble intéressante selon certains aspects.

Quelques questions :

Où vivent les documents ? Dans des bases de données ? Si non, sont-ils des documents directement utilisables en temps que tel ? Y a-t-il une arborescence conservée dans des dossiers ?

le fait de mettre des tags "nommés" sur des versions de document (le versionning de tracim est suffisant techniquement, mais il ne permettra pas d'avoir des tags explicites, juste des numéros de version)

Une version est créée à chaque modification du document ?

On crache beaucoup sur Word et le WYSIWYG, mais c'est tout de même ce qui se fait de plus proche à l'utilisation d'un stylo et d'une feuille de papier. Il faut arrêter de vouloir tout ramener à que l'utilisateur a été déformé par le méchant Microsoft. Un traitement de texte WYSIWYG est quand même beaucoup plus abordable et intuitif qu'un langage à balise.

Heu, comment veux-tu la même « facilité » que Word avec un langage textuel ?

Je n'ai pas vraiment dit que je souhaitais un langage textuel. Je souhaite un système qui me permette de gérer la documentation des machines, à partir de master, d'options, avec une gestion des versions des documents à chaque validation.
Le côté langage textuel est uniquement un aspect pour la technique qui est pour moi plus un obstacle qu'une aide.

Sans passer par un Webdav, nous avons aujourd'hui déjà simplement des dossiers sur un serveur sur le réseau dans lesquels chaque projet vit. Chaque personne édite les documents directement dessus, et personne ne conserve de copie locale ou ne les envoie par email. Ça s'ouvre directement dans Word et se sauvegarde directement dessus.

Je ne comprends pas bien l'intérêt d'un Webdav par rapport à la solution actuelle.

Je suis par contre d'accord avec toi que le problème est de l'ordre des connaissances des utilisateurs. Par contre je ne suis pas d'accord avec toi qu'un bon outil ne pourrait résoudre le problème.
Word est un très bon outil, fiable, efficace et facile à utiliser. Les utilisateurs seraient sans aucun souci capable de s'adapter à un autre outil si il fournissait la même facilité d'utilisation. Mais Markdown ou autres langages à balise ne sont juste pas au niveau de ce côté là.

C'est exactement ce que je recherchais comme retour à mon journal : des retours concrets de boîtes qui ont le même besoin. Je me doutais que l'on était pas la seule entreprise à écrire de la documentation.

Je vais regarder ce DITA de plus près et voir si ça correspond à ce que je recherche.

Merci !

C'est exactement ce qui me fait peur avec tout les langages à balise.

S'il est agréable d'avoir des documents clean et au comportement prévisible, je pense qu'il est préférable d'avoir une approche "sale" à la Word qui autorise quelqu'un a faire de la mise en page dégelasse à base d'espace et de tabulations. Au moins la personne est autonome. Ça autorise aussi facilement d'accepter une nouvelle personne dans l'équipe (intérim, remplacement maladie, etc…).

J'imagine que mon seul souci est de vouloir le meilleur des deux mondes.

Je viens de regarder Etherpad, je vois en quoi il réponds aux besoin de suivi des changements et gestion des versions, je ne vois pas comment il peut résoudre le coté document master, branching et fusion.

Je vais regarder un peu plus du côté des Wiki, mais ça me semble quelque chose de très lourd à gérer, j'aurais préféré une solution où l'on reste sur des documents qui vivent dans des fichiers séparés et éditable directement, le fait que les documents vivent dans une base de donnée quelque part ne m'attire pas du tout.

Justement je ne les vois pas ouvrir une console et lancer du git. C'est bien pour cela que je cherche des outils.

Quand à suivre la procédure ISO, bien entendu je fais ça tout les jours, mais il faudra bien d'abord trouver un concept qui tiens la route.

Un jeu de société peut t'aider à trouver des thèmes pour une histoire, peut-être à jouer avant de lancer le processus de création de ton roman photo ?

https://boardgamegeek.com/boardgameversion/140627/french-edition

Encore une fois vous ne savez vraiment pas de quoi vous parlez. 2-3€ ? C'est énorme ! Les discussions avec les fournisseurs au département achat se jouent sur chaque pièces et les négociations reviennent à quelques centimes par pièces. Et comment les développeurs pouvaient savoir que c'est cette résistance qui allait être le maillon faible ? Et si ils avaient pris une meilleure qualité, est-ce que la résistance d'à coté n'allait pas péter aussi ? On rajoute aussi 2-3€ sur tout les composants pour être sûr ?

Je ne connais pas le monde de l'électronique grand public, mais dans mes domaines le service SAV est présent dès le début de la conception et ils valident la plupart des décisions qui les impactent. Encore une fois vous semblez ne rien connaître de la réalité industrielle.

Le monde du jetable est imposé par la frénésie d'achat créée par le marketing et la course à la dernière innovation au plus bas coût de la part du public. Au niveau conception on ne fait que s'adapter à la demande de la part des chefs de produits, ou la prochaine génération de matériel doit faire mieux, plus beau et moins cher, au risque de perdre des clients. Encore une fois on ne nous demande jamais de faire moins maintenable ni réparable.

Pourrait-on faire mieux au même prix ? Oui, peut-être, on est humain et on ne prends pas toujours la meilleure décision à tout les moments de la conception. Par contre nous mettez pas sur le dos cette obsolescence programmée que j'entends m'être reprochée dès que je croise une nouvelle personne et que je lui parles de mon métier. On a juste pas le temps et le budget à calculer pour que la pièce fasse exprès de mourir à la fin de la garantie.

L'obsolescence du matériel est une conséquence de notre mode de consommation, toujours moins cher et plus neuf. Pas l'inverse.

Sauf que mon raisonnement est que la plupart de ces modifications ne sont pas faites explicitement pour réduire la maintenabilité, mais réduire les coûts ou pour la miniaturisation.

Je pense que tu ne te rends pas compte du gain de coût entre des clips et des vis.

Sauf que bon, quelqu'un qui n'a jamais bossé dans le domaine de la fabrication mécanique va forcément regarder le truc et dire qu'il aurait fait mieux que les professionnels.

J'aimerais savoir ce que tu trouves de fallacieux dans mon argumentaire. En temps qu'industriel et ingénieur j'ai ma part de responsabilité quant à la réparabilité et impact écologique des produits que je conçois. Mais j'ai aussi une réalité économique.

Lorsque je le peux je met en place des solutions qui permettent une meilleure ergonomie, on ne perds pas du temps à concevoir explicitement quelque chose de non démontable ou réparable. Certains industriels le font cependant, je ne suis pas au pays des bisounours (j'ai voulu démonter ma cafetière pour changer un joint et je me suis rendu compte que les vis ont une tête inconnue au bataillon, même dans mon bestiaire de tournevis étranges). Mais personnellement je n'ai jamais, en 10 ans de carrière, reçu la moindre instruction de qui que ce soit de faire exprès d'entraver la réparabilité ou la démontabilité. Ce serait plutôt même l'inverse.

Par contre la pression du coût est elle bien réelle. Avec la réalité de la compétition internationale, produire un produit grand public est avant tout contraint par le coût. Et le temps de développement et de validation a un réel impact sur le prix final du produit, ainsi que le coût des matériaux et du montage. Si tu produit un produit au dessus du prix du marché, tu ne vas tout simplement pas vendre.