Christophe B. a écrit 1665 commentaires

Pour les sparklines voici le lien d'une image avec les 3 types possibles

Plus d'infos sur le blog de Tomaz

Mais il manque LE "killer truc" (IMHO) qui m'aurait permis de rendre visible dans une cellule le taux de remplissage d'un disque, d'un espace de travail BDD etc …

Comme ici par exemple : Colonne Usage la mise en graphique d'un pourcentage

C'est super comme ajout, mais cela aurais été le "truc de la mort qui tue" avec plus d'options de type de graphique, après il est fort probable que tout ne soit pas possible pour des questions de lisibilité

Merci beaucoup

Même si en lisant cette dépêche,je me suis aperçu que j'avais déjà effectué la mise a jour.

La modification concernant la cosmétique des Polices au niveau des Styles ne m'a pas choqué plus que cela

Par contre les sparklines ça c'est super bien et très pratique, j'utilise beaucoup plus Writer que Calc mais cela va certainement rendre plus parlant certaines données

Et je vais faire un tour dans les extensions …

Tant que le prix ne change pas : le client se contrefout de savoir ce que c'est : Mo Go … tout pareil

Et encore il râle pour 28 Mb
Les devs que je côtoie il ne veulent jouer si si ya plusieurs dizaines ou centaines de Go sinon c'est pas drôle

Vivement que l'on utilise AWS … avec la facturation au Go on va rire ;)

Oui je connais les problèmes du statique mais parfois cela rend des services
Exemple :
avec le langage go j'avais pu ré écrire un utilitaire d'envoi de mail (l'éditeur n'avait pas le temps …)
Avantage : presque le même code pour Windows et Linux
Autre avantage : installation par copie du binaire compilé en statique (sur les 2 OS)

Mais tu as raison cela a ses limites et cet exemple est plus du bricolage que du vrai développement

On leur dira jamais assez … Fréquence et volume

Le ministère du numérique ne réponds toujours pas a ma proposition de faire tatouer sur les bras des devs ces 2 mots (même en petit) pour qu'il n'oublie pas

Pour être honnête … c'est du bluff

mais bon avec un avatar bisounours tu perds pas mal en crédibilité :)

OK Désolé :)

enfin plutôt ouf …

Je te prie d'accepter mes plus humbles excuses, la condescendance n'était pas voulue

Je voulais juste dire que l'échange de données peut être régler de manière plus simple que par des Web Services + oauth + …

tout dépend du contexte.

C'est comme si l'on appliquait le code de la route qu'hors des villes.

Le code de la route est utile à l'extérieur pour rouler avec les autres

Quand je roule dans ma propriété je n'ai pas besoin du code de la route

Ma vision de la sécurité est la suivante :

Bâtir un château fort avec pont levis, parapet tour de garde etc …

mais dans le château fort pas besoin de serrure, ou alors sauf pour des données très sensibles comme les paies

Alors c'est vrai les failles il y en a : les postes utilisateurs qui vont chez les clients et/ou voyagent (wifi public etc … ) par exemple

Pendant longtemps je ne voulais même pas de wifi, tant que je n'avais pas trouvé un parefeu capable de gérer correctement Wifi interne et "Invité"

Mais bon quand tes collègues font n'importe quoi et donne les codes wifi internes aux clients … comment veux tu gérer correctement de la sécurité

La sécurité c'est d'abord du bon sens puis de la formation

Oui cela dépend de l'échelle du projet

Mais quand je vois des préconisations ou des installations avec du SSL de partout, alors que les composants sont sur une seule machine.

cela me fait penser au type qui pose des digicodes sur toutes les portes de sa maison (y compris les toilettes) avec rotation à la semaine des codes :)

Il serait pas plus simple de sécuriser les accès extérieurs et de laisser l'intérieur tranquille non ?

Et d'ailleurs toute la page vaut son pesant de cahuetes

12 Images pour comprendre

Pour résumer … en image :)

Tu as tout a fait raison, ce qui est dommage c'est que la plupart des informaticiens (je tapes large volontairement) n'ont plus le temps (ou le budget) de réfléchir et de choisir le bon outil pour le bon usage.

Quand tu as trouvé un bon marteau, tout tes problèmes ressemble a des clous

Et a force d'universaliser on se retrouve avec des couches et surcouches qui vont, comme les trous noirs, s'écrouler sous leur propre masse.

Pour les échanges interbancaires, c'est un domaine que je connais bien, et j'ai jamais entendu parler de PeSit. Une recherche sur internet semble faire un lien avec Axway CFT, qui est très utilisé en effet, mais est hautement merdique (je connais plusieurs centaines de personnes prêtes à tuer pour s'en affranchir).

Ah ah … cela me m'étonne pas
Je le pratique depuis longtemps et j'ai eu la chance de travailler avec des personnes qui ne faisait que "ça" … et m'ont montré comment bien faire, pour donner un ordre de grandeur nous échangions avec une douzaine de "partenaires" au plus fort de l'utilisation … eux en géraient à peu près 300.

CFT à l'origine (avant que cela devienne Axway CFT …) est un produit simple robuste et sécure.
Les échanges bien qu'effectués à travers TRANSPAC pouvaient déjà être crypté et certains l'étaient : double sécurité donc
A cela tu rajoutes la reconnaissance des "partenaires" et cela pouvait se faire de plusieurs manières y compris via un protocole d'échanges de mot de passe, et ce a plusieurs niveaux.

Puis transpac a disparu … (encore un bel outil jeté à la poubelle …) et fallait passer par INTERNET et la on a vu la différence des partenaires :

• ceux avec CONSULTANT en SECURITE
• ceux avec (CON)SULTAN en SECURITE

Dans le cas numéro 1 : il a suffit de déclarer les adresses IP de n'autoriser que celle qui nous intéressent de se mettre d'accord sur un port de communication et cela roule.
Les produits comme CFT ont des dizaines d'années d'historique sur de multiples OS et configuration et vu l'importance des contenus ont toujours été tres suivi d'un point de vue sécuritaire … en gros rien à craindre même en passant via le net
les échanges de mot de passe et autres se faisait par téléphone généralement.

Dans le cas numéro 2 :
La on rigole … il a fallu rajouter des VPNS, des certificats (des vrais … payants !), des doubles authentifications et autres surcouches … à une couche déjà TRES sécurisé.

En gros ils n'ont rien compris et n'ont fait qu'appliquer les recettes utilisées ailleurs sans même se poser de questions.

Si la dessus tu rajoutes, le turn over habituel des grosses structures avec, bien entendu, AUCUN passage d'informations … tu te marres de les voir s'agiter dans leur fange … enfin presque parce qu'au début c'est OBLIGATOIREMENT de ta faute, toi le petit fournisseur externe

Donc oui je penses que certains doivent détester Axway CFT … parce qu'il ne le connaissent pas

Et désolé de vous parler comme un vieux con, mais cela va pas en s'arrangeant
Bon avant c'était pas mieux mais pas pour des raisons ubuesque comme celles ci

HTML n'était pas fait pour faire de la sécurité, ni pour gérer des sessions , Windows et le DOS n'aurait jamais du être aussi répandu sur les postes de travail, CFT et certains logiciels se passeraient bien de surcouche "sécuritaire" et de certificats décernés par par des "AUTORITE DE CONFIANCE" à obsolescence programmée etc …

C'est tout sauf de la logique , j'appellerai plutôt cela marcher sur la tête … vivement que le bon sens revienne et reste à définir (je n'ai pas la solution juste le gout de la critique … c'est plus facile :) )

Et je comprends pourquoi les extra terrestres ne nous contactent pas :) doivent se marrer quand même

Comme tu le dis cela reste de l'artillerie lourde … pour un problème relativement simple : échanger des données

de SOAP WSDL - XML à REST - JSON cela évolue dans le bon sens, et il faut bien le reconnaitre cela fonctionne ( oauth2 est quand même un peu usine à gaz … )

Mais je ne peu pas m’empêcher de regarder des protocoles anté diluviens comme PeSit (90% des échanges interbancaires je crois) et de voir la simplicité et l'élégance de la chose.
pour résoudre le même problème.

La différence : les ressources humaines et financières misent en face du problème à l'époque

trop souvent on préférè acquérir un produit cela évite de réfléchir
Après on se retrouve devant des usines à gaz que plus personnes ne veut ou ne peut administrer

D'ailleurs ce que tu dis c'est triste :

on n'est plus dans un monde de bisounours où on peut faire confiance à une machine juste parce qu'elle est dans le même réseau, ou à un même process juste parce qu'il est sur la même machine.

Bonjour à tous,

Attention je vais provoquer grave, vous pouvez moinssez : même pas peur

Les tubes nommés ou fichiers fifos existent depuis très longtemps, peut être même depuis les débuts d'unix (si quelqu'un à le courage de rechercher …)

Au siècle dernier cela servait a beaucoup de choses, comme par exemple le multiplexage de connexion série, la compression d'export oracle en shell ( que même chez oracle ils y avaient pas pensé …) , pour temporiser l'envoi de SMS via modem (je sais c'est plus tard …)

Puis est venu internet et le HTML, depuis tout le monde s'est mis à faire du Markup Langage
vu le succés du HTML difficile de le critiquer et pourtant …

Et on a oublié de refléchir tout devait passer par un langage de MARKUP

Quand on regarde comment cela fonctionne sous le capot, bien souvent il y a plus de contenant que de contenu ( les balises sont plus importantes que les données en volume …)

Les Web services n'échappent pas a cette régle et même si cela permet d'échanger des flux de données et de publier des fonctions, je n'ai jamais trouvé cette solution élégante
Surtout que très souvent un échange de fichier format CSV suffirait :)

J'ai vu trop souvent des canons de 105mm destiné à tuer des mouches dans les webs services (dans l'informatique de gestion celle que je connais) et des ressources informatiques inutilement dilapidées. Et beaucoup trop de dev ne jamais se poser de questions, surtout a ce sujet qui apparait comme une boite noire magique pour certains

Les tubes nommées et autres fifo par contre j'ai toujours trouvé cela élégant, ne consomme pas beaucoup de ressources pris en charge par le noyau et bien souvent très efficace
Content que cela refasse surface :)
C'est simple efficace élégant

Merci pour la commande socat je ne la connaissais pas.

Bonjour

Réactivation du sujet car je suis dans la même problématique : sortir de confluence
- trop cher pour une petite équipe
- difficile de stocker des informations "sensibles" sur le cloud

Après quelques recherches Xwiki peut effectivement remplacer Confluence et même aller plus loin

Confluence est un bon produit, d'ailleurs atlassian s'en est aperçu et a augmenté le tarif en conséquence … ou comment flinguer un bon produit commercialement

XWiki est un bon produit aussi, pour être honnête je ne le connaissais pas ou peu il y a quelques jours, et il m'a agréablement surpris
Il demande cependant un peu d'investissement (confluence aussi) pour le maitriser mais pour l'instant je ne suis pas déçu.

J'ai pu effectuer des tests et il rempli quasiment toutes les cases que je cherchais pour mes humbles besoins :

• une recherche efficace (y compris dans les PJ testé sur PDF ODT DOCX)
• Des documents modèles (template) pratique quand on a pas de mémoire …
• Gestion simple de l'arborescence ( des pages "répertoires" )
• Gestion des droits par utilisateur (en gros rédacteur / lecteur )

Mais aussi

• La possibilité de copier coller des images directement
• La gestion des mots clés (tags)
• Un export PDF propre

Et j'ai tout trouvé dans XWIKI parfois mieux que dans confluence (exemple sur la presonnalisation de l'export PDF) et même si il y a des différences cela ne justifie pas la différence de cout avec confluence

Son installation est simple et bien documentée

Et le seul reproche que je puisse faire est de ne pas avoir trouvé de tuto "from scratch" ou de "xwiki pour les nuls"

Par exemple on partant d'un xwiki vide … vous ne pouvez rien faire … même pas l'administrer

Il faut passer par les extensions (et il y en a beaucoup) pour un béotien c'est pas évident et c'est difficile à deviner

Idem pour le coté programmation et dev de XWiki, on doit pouvoir fair beaucoup de choses, la ou confluence apparait comme "fermé"

Bref Xwiki c'est vraiment bien, en 2 jours il m'apparaît comme une solution viable et économique et je vais certainement étudier le coté 'payant' pour du support et certaines extensions pour voir si elles le méritent .

XWiki est le genre produit qui mérite de l'investissement car il offre beaucoup, et même trop de choses (ce qui est bien aussi … ) mais cela perturbe au début

Après il faut trouver le temps …

Oui j'ai toujours pensé qu'il y avait un gaspillage énorme avec ces mails
de temps et de ressources informatiques.

Et ce avant même de prendre en considération les spams et autres péniches qu'il faut élargir …

Sans parler du fait que la plupart des "utilisateurs" (en restant polis) utilise leur boite mail comme une base de données

Certains on compris la différence en POP et IMAP le jour ou le disque dur de leur ordi portable a rendu l’âme … sans sauvegarde bien sur, c'est pour les lâches

Bref si le mail ne servait qu'a véhiculer de l'information et qu'il y a avait un outil pour stocker correctement l'info de manière pertinente et efficace on n'en serait pas la …

C'est vrai un peu comme un forum …

Je m'en doutais et c'est pour cela que je te remerciais pour cette dépêche.
Même si la partie tibétaine a faillit me faire décrocher …

Mais d'un autre coté, cela fait réfléchir : si une écriture particulière ne peut pas se transformer en fontes utilisables informatiquement … elle va disparaître et dans quelques années sera stockée dans un musée dans le meilleur des cas.

D'ailleurs c'est pas le golang qui a remis au gout du jour la compilation en statique ?
( corrigez moi si je me trompe )

l’exécutable est un peu plus gros mais comprend toutes les dépendances de librairie liées statiquement

Au moins l'installation se fait en copiant le binaire … c'est tout

OK cela ne correspond pas forcément à tout les cas de figures, mais a mon humble avis ce n'est pas si bête …

Merci beaucoup pour ce journal sur la typographie

Jamais je n'aurais pensé qu"il soit si difficile de faire une fonte.
On imagine la somme de travail que représente Dafonts et autres sources …

Encore merci

Merci pour le lien … trop fort … respect

J'ai plussé pour la belle autodérision de Zenitram :)