Laurent J a écrit 2938 commentaires

tout est expliqué sur le site.

pas mieux

On sourira à la musique héroïque finale très "américaine", cette petite pincée de patriotisme est encore acceptable au vu de ce que nous sort Hollywood ces dernières années.

C'est surtout acceptable vu l'époque pendant laquelle il a été tournée : la guerre froide.

Tout à fait d'accord, casio et ti, c'est peut-être bien, mais faut reconnaitre, que quand on est geek, une HP48 (et suivante), c'est le pied ! C'est LA calculatrice du geek.

viva el hp48 !

surtout avec un bon Jytris ;-)

Tenez d'ailleurs, il y a une 49g+ ou je sais plus trop quoi qui vient de sortir. elle est toute belle :-D

moi, ancien geek^Wnerd sur hp48, vais-je céder à la tentation ? Faudrait peut-être qu'un jour je finisse J-Asm... :-D

tu as mal lu, il a un accés haut-débit par satellite.
C'est autrement plus cher que 15 euros par mois..

http://ljouanneau.com/blog/(...)

et tous les sites utilisant dotclear. (http://www.dotclear.net(...))

Self et Lissac, ne sont PAS les seuls langages objets basés prototypes.

Il y a aussi EcmaScript, plus connu sous le nom de Javascript ;-)

http://devedge.netscape.com/library/manuals/2000/javascript/1.5/gui(...)

1) relis la len : les hebergeurs ne sont PAS OBLIGES d'avoir un système de verification. Donc ils sont pas obligés d'avoir des frais...

2) les micros hebergeurs ( <50 sites on va dire), en principe, ils connaissent leurs hébergés et n'autorise pas n'importe qui sur leurs serveurs (ce serait mon cas si j'etais micro-hebergeur benevole, qu'il y ait la len ou pas). Bref, à priori, ils auront pas tant de contrôles que ça... Donc ils ne vont pas disparaitre. Je dirais même que ce sera le contraire... Et une verification visuelle de temps à autre ne prendra pas si peu de temps que ça.

3) pour les hebergeurs moyens, c'est plus délicat effectivement.

4) pour les gros, ils ont assez de sous pour investir dans des outils de détection.

Solution : developper des outils libre de detection que les moyens et petits hebergeurs pourront utiliser sans trop de frais (mais c'est pas gagner, technologiquement, je reconnais que c'est chaud)

ouarf... c'est pas bête ça :-D

---
Laurent tête en l'air

non, "à vos fork" ça veut rien dire. ça serait plutôt

à vos claviers, pret, forkez !

:-)

félicitation :-)

tiens d'ailleurs, vais p'tete un de ces 4 faire un p'tit coucou à ces djeuns qui n'en veulent du LL. Ils ont eu une bonne idée de monter ça tout prés de chez moi :-)

Et les SSI mon cher, tu connais ? (Serveur Side Include) pas besoin d'avoir fait bac +5 dans une école d'ingenieur pour savoir le faire :

<!--#include file="monmenu.html" -->

au lieu de .html, tu enregistre en .shtml
Faut bien sur que l'hebergeur le propose. mais normalement, c'est un truc de base qui existe depuis des années...

chez moi, c'est de la même taille

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031021

C'est clair ! :-D

(oui oui -1)

Ta CPU n'a pas trop souffert parce qu'une bonne partie de l'energie dégagée a été absorbé par ton ventilo et son plastic (d'où la fonte...).

Au fait, moi aussi, j'ai un AMD qui arrive à fonctionner sans ventilateur. C'est costaud AMD...

Hein ? ah oui, c'est un 386DX40...

---> je retourne à mon postgres

<mode type="windowsien barbare">
Et le bouton reset, il sert à quoi, hein ?
</mode>

ok ok -->sais pas où

pendant qu'on y est, voici inv en php

#!/usr/bin/php
<?php echo strrev($argv[1]),"\n"; ?>


./inv "php ça roxor"

tu veux parler de comment adapter un jeu de balises wiki differents de celui par défaut ? La doc est en cours...

En gros, 2 solutions au choix, selon ton envie :

1 ) tu te fais un nouveau fichier sur le même modèle que le fichier wikirenderer.conf.php, tu y modifie ce que tu veux, en renommant la classe de configuration (TrucConf par exemple)
et aprés tu fais $wr = new WikiRenderer(new TrucConf());

2) tu modifie directement wikirenderer.conf.php

Apres, la façon de modifier le fichier de conf, la doc est en cours. Tu as quelques elements là http://ljouanneau.com/softs/wikirenderer/documentation.php(...) ...

je m'étonne que ça donne l'impression que chacun des ministères travaille dans son coin, à sa vitesse, mais surtout, en réinventant à chaque fois la roue : chaque ministère semble faire exactement la même étude de faisabilité/rentabilité/etc. sur la question,...

Euh, j'ai l'impression que tu n'as jamais fait d'audits ou d'études de faisabilités. Si chaque ministère travaille chacun dans son coin, c'est surtout parce qu'ils n'ont pas les même besoins, ni les mêmes équipements etc. C'est bien beau de penser "OOo c'est bien !", mais correspond-il aux besoins de tel ou tel service ? Qui sont les utilisateurs ? Des techos ou des newbies en informatique ? Qu'est ce qu'ils doivent produire ? quels types de données ? Est ce que le passif peut être utilisé dans ce contexte-ci ou ce contexte-là avec ce nouvel outil vers lequel on projete de migrer ? etc..

Bref, le résultat d'une étude d'une migration d'un produit à un autre, qu'ils soient propriétaires ou libres, va dépendre de plein de facteurs qui sont tous différents d'un environnement à un autre, donc d'un ministère à un autre, parce qu'il y a à chaque fois des besoins différents, une population différente, des données différentes à traiter et un passé informatique différent.

C'est ridicule d'avoir plusieurs versions comme cela alors qu'Il suffit d'avoir une page HTML bien formée, avec une bonne utilisation des balises en respectant leur semantique (des balises titres pour les titres, des p pour les paragraphes etc...) pour que la page soit accessible A TOUT LE MONDE... Le CSS s'occupant du design...
Bref, que des choses trés simples à mettre en place plutôt que de se faire chier à developper différentes versions des pages...

Et c'est d'autant plus ridicule par le fait que peu de site mettent ce lien /oo, donc inaccessible pour les handicapés...

Aller, un peu d'accéssibilité ne fait pas de mal :
http://openweb.eu.org/accessiblite/(...)
http://www.la-grange.net/accessibilite/(...)

Les langages du futur ? Pas facile...

Par contre ce qui est sur, du coté du développement des interfaces d'applications, c'est que celles-ci ne reposeront plus sur une API classique, mais sur des fichiers XML comme XUL dans Mozilla.

Il n'y a qu'à voir les dizaines de bibliothèques déjà disponibles en Java, en C/C++ etc, qui offrent une surcouche à GTK, swing ou AWT etc... (y a même un moteur pour PHP/GTK). Voir une liste exhaustive sur http://xul.sourceforge.net(...) . D'ailleurs MS l'a compris avec d'Avalon, le système graphique du futur windows, qui reposera entièrement sur XAML, un concurrent de XUL, mais aussi Macromedia, avec sa techno Flex, 100% pompé sur XUL.

L'avantage de ces interfaces à base de fichier XML, c'est que c'est utilisable pour une application web. Et XUL/Mozilla offrent déjà une belle plateforme pour faire ce genre d'appli. Cela permettra enfin de faire des trucs utilisables et ergnomiques (HTML est plutôt limité pour faire des interfaces digne de ce nom, de toute façon, il est pas fait pour ça).

Et puis, grâce à ce système de fichier XML, on pourra voir apparaitre des outils générateur d'interface graphique qui soient "universel" (à la limite, un coup de XSL pour transformer du XUL en XAML par exemple, ou l'inverse..).

Seul hic : il faudrait un standard, une normalisation de XUL ou equivalent afin ne pas avoir à réapprendre la roue à chaque passage d'une techno à une autre.

juste comme ça, dans ta doc : on dit pas désavantage, mais inconvénient ;-)

sinon l'idée est pas mal. Vive XHTML :-)

ouai du coup, c'est encore plus lourd qu'avant...
Bref, il n'apporte pas grand chose ton plugin...

à la limite, cela aurait été mieux de mettre ce qu'il y a dans le sous menu frame, dans le menu principal directement, sans enlever le view source, view info disponible pour la page principale

et si on veut recharger la page mère ?
et si on veut voir le code source du frameset ?
on peut ?

non, y'en a pas hélas...

http://www.xulfr.org/wiki/RessourcesLogiciels(...)