Je suis en train de voir pour héberger le Slidy sur sourceforge, mais de mémoire c'est une vrai plaie pour accèder a l'upload (ajout de la clef ssh, etc.).
Sinon j'ai d'autre serveur dispo mais pas de nom de domaine potable (on devrait en acheter un quand AWiki sera fini) pour mettre la démo dessu :P
Pas testé encore, mais je doute que ca fonctionne pour le moment.
On est très orienté page web, et j'ai a peine commencé a me documenter sur comment faire en sorte que ca marche dans les extension samedi aux JDLL (sur le stand de mozilla).
Si t'as des tuto pr les script grease monkey, par contre, ca m'interesse :)
Sinon pour ce qui est d'une vrai démo hébergée, c'est en cour avec la développement de AWiki. On pourrait d'ores et déjà mettre Slidy, mais j'aimerai, pour en faire la démo, lui faire un back avec un BDD et gérer des effets sur les slides avec scriptaculous....
En ce moment je n'ai pas le net chez moi (déménagement) et seul Swiip peu avancer en dehors du mardi (journée pendant laquelle notre boite nous paye à développer Archetype :D)
- Slidy un présentation type "Powerpoint" dans le navigateur faite avec Archetype (on a repris un application disponible sur le site du W3C, d'ou les non hack css pour les navigateur ne supportant pas tout bien à ce niveau là, je corrigerai ça d'ici la 0.1.1 ou la 0.2) qui propose de faire soi même sa première application avec Archetype :)
Suivant votre heure d'arrivée, et habitant à proximité de la gare de la Part Dieu, si vous utilisez le train, je peux servir de taxi jusqu'à CPE ou se déroulent les JDLL (surtout samedi, vendredi je bosse normalement, meme si je vais negocier pour aller voir la conf sur RoR le matin)
Je suis contactable sur 1e5ozk8lulrgvhf@jetable.net (adresse valable une semaine) pour plus d'informations.
Le plugin JSEclipse rend le même genre de services. Si on mélangeait les 2, on aurait quasiment le plugin idéal pr éditer du javascript.
J'aime beaucoup Aptana, mais des trucs simples comme l'indication de l'utilisation d'une variable ailleurs dans la page (les petits carré jaune vers la barre de défilement qu'on voit qd on est sur une fonction ou une variable, dans JSeclipse, ou dans l'editeur Java) manque par exemple.
Au début, j'utilisais peu ce genre d'information mais ca évite souvent une recherche dans le code et c'est donc bien pratique sur un code long. JSEclipse possède ce petit plus (qu'on a ususellement dans du coe java d'ailleurs).
Là ou Aptana est fort, c'est sur le "scope" de fichiers pour l'autocomplétion: qd on ouvre un fichier html, il regarde les include javascript et rajoute tout seul dans un "scope" les fichiers pr faire la complétion surles variables contenues. On peut aussi le faire en manuel ce qui est vraiment très pratique.
Là ou dans sa grande force il a une faiblesse, c'est qu'il ne comprend pas "tout". Ainsi, si je ne dis pas de bêtise, il ne fait pas la complétion sur les objets qui ne sont pas créés de manière "naturelle".
Je m'explique : un objetMachin.prototype.methode(param1,param2) permettra d'avoir l'autocomplétion aussi bien sur param1, que param2, ou sur methode. Par contre un objetMachin= Class.create(mapDecrivantLePrototypeContenantLaMethode_methode) ne fonctionnera pas.
Or le 2e cas, avec l'évolution des framework javascript risque d'affluer en grand nombre. Dans notre Framework, Archetyp (cf signature) on a redéfini Class.create pr fonctionner comme dans le 2e cas décrit. On a de la même manière un Component.create (1) et la complétion n'est pas prise en compte (tout comme la Jsdoc du prototype, en tout cas avec JSDoc Toolkit et les options de bases + "-a").
La modification de Class.create dans ce sens est identique dans Prototype 1.6.0rc0 (Archétype est basé sur Prototype 1.5.1, mais l'évolution de Prototype rattrape certaines idées que l'on a implémentées dan Archétype), sachant que c'est le framework javascript le plus utilisé, ca va faire rapidement beaucoup de problèmes.
En même temps c'est normal, comment sait-il que Class.create/Component.create contient une définition d'objet ? 3 solutions: interprêter le code, ou permettre la création de fichier de description de certaines fonctions comme le propose JSEclipse (2), ou encore l'interprêtation de certaines données de la JSDoc de la fonction, cumulé a des conventions (3), ce qui serait ss doute le plus simple !
J'ai parlé JSDoc, je trouve Aptana aussi assez fort dans le domaine, puisque qu'un raccourci permet de construire automatiquement le commenatire JSDoc au dessus de la fonction dans laquelle se trouve le curseur, prérempli des paramètres qu'elle possède.
JSEclipse, lui, se contente de supporter la complétion sur les attributs de la JSDoc, et n'est même pas très à jour dans le domaine d'ailleurs.
Bref tandis que je me résignai à utiliser JSEclipse et abandonner Aptana (4), j'ai trouvé de bon côté a JSEclipse, mais l'éditeur Javascript parfait n'est pas encore là, même si avec Aptana et JSEclipse mélangé, on aurait sans doute un truc vraiment bien pour bosser!
Une chose est sure pour moi, les outils arrivent, on va arrêter de coder du javascript caché dans du code serveur, et on va réèllement codé en javascript pour la vue, le controlleur, et passer par des passerelles de RPC comme DWR pour la communication avec le code métier, pour ne pas avoir a s'en soucier ni à la coder pour chaque appli.
Les éditeurs poussés, comme Aptana ou JSEclipse devraient le permettre sans difficulté pour le programmeur, les navigateurs sont en pleine tendance d'accélération matérielle du graphisme et de patater le javascript, les frameworks permettront de se dégager des soucis de compatibilité (ce qui est déjà fait en grande partie), et faciliteront beaucoup le développement JS, aussi on devrait voir se multiplier dans les prochains mois des appli lourde "web 2.0" dont une bonne partie du développement aura été fait côté javascript, et non caché dans du code coté serveur qui en fait est du javascript (5).
Bon bon bon, amusez-vous bien , et essayez Archetype(6), vous verrez ce que c'est de programmer sympathiquement en JS ;o)
(1) : Les "component" sont des classes améliorées, permettant d'avoir des services ajoutés transversaux(comme l'enregistrement automatique de fonction "onMachin" aux évènements "Machin"), notamment le chargement des dépendances --transitives-- requises à son fonctionnement avant son chargement et permettent de manière aisée de créer des sortes de widgets graphique, séparant vue controleur et model, au lieu de tout mélanger comme des porcs dans du code javascriptohtmlocssoïque, ou pire, "DOMcentrique")
(2) : Je sais que c'est des XML, mais j'ai jamais trouvé ceux de Prototype et j'ai jamais vraiment fouillé, du coup la complétion est assez moyenne dans JSEclipse je trouve, des qu'on utilise des lib de ce type, car il ne connais jamais le scope de ce qui nous intéresse.
(3) : Une annotation "@createObjectByMap param1" par exemple, pour indiquer qu'on va créer un objet a partir de la map "param1" qui se trouve en paramètre
(4) : "sapusaipulibre" c'était pire que pas être libre d'origine ! EN même temps j'avoue ne pas avoir lu la nouvelle license, mais son changement me chigrinait tout de même surtout pour aller vers quelquechose de non redistribuable ou presque ...
(5) : RoR, JSF, Struts, Tapestry5, j'en passe cachent le JS qu'ils utilisent... C'est gentil mais ça ne fait jamais tout ce dont on a besoin, et au final on s'embête plus avec que sans, en utilisant un simple DWR pour communiquer...
(6) : On a un problème de compatibilité avec IE7 pour le moment, depuis qu'on a revu un des fonctionnement du coeur de l'appli, pr le rendre plus astucieux et plus léger(on a supprimé des "eval" et des new Function("") qui nous plaisaient pas du tout par du objet["methode"] simple léger et efficace), c'est pour ça qu'on fait pas encore notre première release (la 0.0.9, on prévoit la 0.1 mi octobre, agrémentée de doc et de petits exemple!) ... Néanmoins le code est Checkoutable sur notre SVN pour faire joujou, n'hésitez pas !
En attendant que je retourne au boulot pour avoir un moyen de débogguer pour IE7, on commence le développement de Awiki, un wiki Wysiwyg fait avec Archetype/TinyMCE/DWR/Spring/Hibernate, basé sur des idées façon tiddlywiki ou xookie, mais avec une BDD derrière, et une vrai gestion de version.
Je trouve le blog en image bien, mais l'idée que je souhaite exprimer est plus video que statique.
Je vais l'exprimer ici sous forme de texte, en attendant d'avoir le courage de fabriquer 2 ou 3 images caractéristiques à partir de rien (j'arrive même pas a trouver les icône de la barre d'outils sans aller chercher les sources, ça me gonfle...) puisque je ne connais pas d'interface comme ça :)
Les principes de mon interface, sont :
- D'abord que les ordinateurs taillé pour faire du traitement d'image ne sont jamais des bouses, et on peut donc faire une interface très mobile (beryl / e17 like) car il y a toujours une accélération graphique suffisante
- Toujours maximiser l'espace de travail pour travailler sur les images
- Avoir une vue scalaire des informations, aka le principe du "FishEye" : l'idee de base c'est genre une barre MacOSX pour chaque "dock" (même concept de dock que l'actuel): quand la souris est loin et ne travaille pas (aka click enclenché), on ne voit que l'icone/titre du dock, puis on se rapproche, un minidock apparait, avec les informations importantes du dock (mode sélectionné, etc.) puis on a plus d'informations, jusqu'a l'ensemble des options, ce qui revient quasiment à une fenêtre, qui pourrait être "épinglable" (pour rester verrouillée dans cet état si besoin).
Je détail le dock des outils par exemple: les outils sont en ligne verticalement façon barre OSX, et minimisé ils ne dépassent pas sur le/les buffer image. Plus on rapproche la souris d'un outil, plus on a d'informations dessus: une icone qui déborde sur l'image pour bien l'identifier, le nom de l'outil qui apparait puis eventuellement une petit aide, ou un truc/astuce sur l'outil,(desactivable) et quand on passe la souris sur l'icone, aparaissent les options de l'outil, on peut alors facilement cliquer sur l'outil pour le selectionner et règler ses options. Pour voir l'état des options et les changer, un simple coup de souris dans la direction du dock montrera rapidement l'information nécéssaire.
Si on pense avoir à rechanger les options regulièrement pendant le travail avec l'outil, on "épingle" les informations de l'outil (sous forme de dock contextuel/ fenetre MDI ou multifenêtre suivant les options utilisateur, par exemple, pour moi ca dépendrai si j'etais sous Linux ou Win :D )
- Avoir une gestion d'action sur les images (filtre, script, propriétés de l'image/du canevas, inversion de la sélection, changement de couleur ) avec favoris/ liste de MRU, par exemple sur un dock (toujours type FishEye) en bas au centre de l'application (dans la conf par défaut)
- Avoir des vues, de la même façon qu'on peut avoir des vues dans Eclipse (et d'autre éditeurs) permettant un autre agencement des barres/ dock/etc.
- Avoir eventuellement des workspaces permettant de switcher d'images ouvertes entre les workspaces (façon calques de blender, une image peut etre sur plusieurs workspaces, seules ou avec d'autres images).
On pourrait même garder la dernière vue utilisée dans le workspace afin de swicher facilement beaucoup de chose.
Par exemple, un workspace permettant de picorer des bouts d'image par-ci par-là sur d'autres image que l'image de travail, avec une vue organisée pour cela(on pourrait imaginer de voir dans cette vue le gestionnaire de calque avec l'ensemble des calques de toutes les images ouvertes dans le workspace), et un workspace ou on a que l'image de travail (on switcherai dessus en changeant d'onglet par exemple, façon FF), avec que les outils de peinture avec les brosses facilement accessibles et listé dans un dock FishEye(avec une recherche sur les tag dans le dock, suivi des brosses triés par nombre de fois ou elles ont été utilisées, vu qu'ils vont utiliser des tags pour catégoriser, d'apres la video que j'ai vu, pour les brosses/tiles/gradient/etc.).
Bon, si vous voyez comment faire 2 images permettant d'expliquer tout ça, je prend (d'autant plus si elle est déjà faite ^_^) !!
Je suis sur que c'est une configuration permettant d'exploiter les écran pas énormes facilement, tout autant que les dual screens (on peut imaginer des colonnes de docke FishEye, ça me parait pas déconnant à mettre sur le 2e écran), que ça permettra au débutant d'apprécier avec une vue simple qu'il peut personnaliser, et à l'expert d'augmenter sa productivité avec un environnement conditionné comme il l'entend à tout moment grâce aux workspaces/vues/favoris/MRU.
Le seul inconvénient c'est que ça nécéssite un minimum d'accélération graphique (2D) pour que ça ne rame pas(ou alors être basé sur les EFL pour l'interface ! ), mais ce prérequis ne sera pas un problème d'ici peu (les drivers graphique semblent s'ouvrir ces temps-ci :D ) quelque soit la plateforme, et même sur les périphériques portable car eux aussi se font accélérer le graphisme maintenant :P
Pour ce qui est du lieu, on le doit à certains geek qui sont profs/admin à l'école (notamment feu Oscar Figuereido, mort dans un accident il y a un an, et à qui la session 2006 était dédiée, et qui n'est sans doute pas étrangé au site actuel des JDLL, puisque celui-ci tourne sous Plone).
On compte notamment parmis les profs, un des core developer du Gimp ( je lui avais moi même poussé 1-2 patchs ), David Odin, sachant qu'un autre, Dave Neary, habite aussi sur Lyon, et qu'il fait régulièrement des conférences aux JDLL.
Bref CPE met le logiciel libre dans la culture de l'ingénieur et beaucoup de Cpéen souhaiteraient aider un logiciel libre d'une manière ou d'une autre. Pour ma part j'ai entamé un gros projet libre avec un ami, un vrai framework javascript pour montrer qu'on peut réellement développer en javascript ses RIA et qu'avec de bon outils ce n'est pas plus dure que du web1. Nous sommes même soutenu par notre boite qui nous paye 1 jour par semaine a travailler sur notre projet, et somme en phase de freeze pour une 0.1, qui apporte déjà son lot de petites révolutions dans le domaine :) J'espere que nous pourrons présenter ce framework l'année prochaine aux JDLL !
PS pour toi benoit: En comptant les chimistes et les electroniciens, vu qu'on est généraliste, dans les faits, on doit produire environs 120 informaticiens par an (1/3 des chimistes, 2/3 des electroniciens directement, et le reste des electroniciens font de l'info + de l'elec en gros).
Je ne pense pas que l'INSA Lyon produise 1000 informaticiens par an, aux vues des proportions, comparables, dans ma boite (entre 10 et 15% chacun), entre les 2 ecole lyonnaise (il y a un peu plus d'INSA, mais tous ne sont pas de l'INSA Lyon).
Ton école, c'est aussi la mienne(même si j'y suis plus :P), et les JDLL là bas, on le doit notamment à plusieurs profs d'info (peut-être surtout à feu Oscar Figuereido, paix à son âme, mais aussi David Odin, développeur de The Gimp, ou encore Pollux admin unix des meilleurs qu'il soit ;) ) très compétents!
Oscar était vraiment impliqué pour faire marcher l'école avec le libre, qu'elle le soutienne et accueil des journées telles que celles ci (on notera que l'utilisation de Zope sur le site des JDLL n'est sans doute pas étrangé au passage d'Oscar sur cette terre).
On a manqué accueillir un rassemblement mondial des développeur de The Gimp mais le dossier n'est pas passé (on était 2 avec l'angleterre a rester, si j'ai bon souvenir, mais ils ont pris l'angleterre) :'(
A noter qu'il y a un autre développeur du Gimp sur Lyon, Dave Neary, qui fait souvent des conférences lors des JDLL, peut-être cette année aussi.
Bref c'est loin d'être déplacé de faire les JDLL là bas, c'est des passionés qui l'ont permis (fallait convaincre l'école déjà!) :)
PS: Arrête de dire qu'on est pas une école d'info, soit réaliste, 1/3 des chimistes sont dans l'info, et 2/3 des electroniciens font purement de l'info (le dernier 1/3 fait de l'élec + de l'info !) et la plupart se spécialisent fortement en info en 2e & 3e année. On est généraliste, oui, mais on créé pas mal d'informaticiens... à vue de nez 120/an.
Sur Lyon, dans ma boite (d'informatique), CPE Lyon représente environs 10% des effectifs (l'INSA Lyon représente entre 10 et 20% je pense, l'INSA Lyon ne produit pas que des informaticiens, et je doute que les promos d'info+elec représente 1000 informaticiens par an). On est même un peu plus en % sur le projet Geoportail je pense (15-20% pareil que l'INSA "toute provenance"). Nous sommes tous des pro libres convaincu je pense, vu qu'on en utilise toute la journée, et qu'on commence même à en produire (cf. ma signature) :D
Bref, l'INSA a aussi ses conférences sur le libre (je me rappel d'une sur OOo par exemple) et il ne me parait pas déplacé que ces conférences aient lieu a CPE
Je mettrai des reserves, mais ya de ça (sauf que win me, pour le voir, fallait deja arriver à passer les écrans bleu). Ce n'est pas la stabilité qui est pourrie, c'est tous les petits détails, la finition. Ils auraient du faire Longhorn comme ils l'avaient prévu, en coupant la compatibilité et
avec 2-3 trucs un peu innovant (même si on retrouvait le gros des trucs "innovants" déjà ailleurs...).
Néanmoins la gestion de seulement 2Go de ram pour XP me rend rébarbatif le fait de revenir dessus (perdre 1 Go de RAM ... mouarf :/)
Bon sinon je cherche un expert OGLSL pour faire tourner VG suffisament vite sur mon ordi sous wine :D
"nouveau ?" le nom me dit que ça a en effet à voir avec NVidia et qu'il me parait lointainement connu, mais je ne saurai en dire plus.
Sinon perso après 2 ans de Linux (pas de windows du tout sur le pc) je suis repassé a Windows Vista ( vous inquiétez pas j'ai gardé ma Ubuntu à côté, et c'est toujours elle qui a droit a 80% de mon disque dur ^_^) ... et je m'en mords les doigts de plus en plus...
La raison de ce retour à Windows, c'est mon passage de WoW (tournant parfaitement sous Linux avec wine, même s'il est plus gourmand côté processeur) à Vanguard SoH qui tourne entre 0.5 et 2 fps sous Linux avec wine en le tunant à mort (j'envisage de m'acheter un PC de grosse brute pour repasser sous Linux tout de même).
La raison est un problème d'implémentation d'un bout d'openGLSL qui est fait côté CPU pour Linux lors de l'utilisation de VG, ce qui ne permet pas de bonnes performances (bien qu'ayant tenté de regarder, je manque sérieusement de compétence pour faire le patch qu'il faut ... )
J'explique pourquoi je regrette vraiment Linux (même si j'ai un public converti devant moi ! ). Sous Vista:
- Mon PC passe largement 30% de sont temps à gratter sur le DD (je suppose que ça a à avoir avec l'indexation pr les recherches rapides).
- J'ai du désactiver l'UAC alors que je suis pour (c'est un vrai pas dans le bon sens pour une séparation root / user)!
Ses passages par une popup modale qui noirci le reste de mon bureau en passant par une coupure de l'écran puis un réaffichage me gonfle.
Surtout que ça rame (en fait je me demande si Aero sert a quelquechose là dedans car je vois pas en quoi faire un truxc noir transparent en fond d'écran doit faire ramer le reste de mes appli ... ?)
Si je lance ventrilo en mode user, l'application ne reçoit ce qui vient de mon micro que lorsqu'elle à le focus ! je dois donc la lancer en administrateur (c'est clairement pas le but de ventrilo d'être la fenêtre avec le focus)
Résultat 80% des appli il faut les lancer en administrateur (et ici c'est bien la faute des développeur des applis, pas de Microsoft). Un exemple parmis d'autre, Firefox (en fait je tourne sur Minefield), pour qu'il puisse se mettre à jour(ya des MaJ tous les jours)!
- Les gadget Vista sont NUL !
La barre d'Aero ne se souvient jamais de rien : affichage de la place restant sur les disques dur: OK, sauf que 2 gadget, un pour C, un pour D, je configure le 2E pour D: a chaque démarrage car il est pas foutu de se rappeler qu'il faut regarder D: (il me remet C: sur le 2e tout le temps)
Résultat je vire la barre Aéro. Coupure d'electricite, hop elle revient par magie , j'ai rien demandé ...
- Je lance un media player (VLC, SMPlayer par exemple, j'ai gardé mes logiciels préférés ;P) hop hop ni une ni deux, aéro se désactive. C'est vrai, c'est tellement normal, le media player pourrait mettre la carte graphique a genou avec son film à diffuser, faut vite enlever les effets graphique jolis pour pas que ça rame... Après je redémmare sous Linuwx, et je fait tourner le cube de compiz fusion, ses engrenage GLX gear au coeur du cube et j'ouvre 10 videos et je fais tourner le cube pr m'amuser, et du coup j'ai du mal a comprendre pourquoi Windows désactive Aéro...)
- Aero ne sert à rien (juste à la transparence des barres de titre des fenêtres, c'est tout)! Je me demande même s'ils ont pensé a l'utiliser de temps à autre, le switcher de fenêtre 3D sert à rien(c'est même pas lui qd on fait alt-tab), la réduction/ouverture des appli qui peuvent ramer, bah ça rame (alors que sous Linux, une de mes grandes joies c'est que les applis n'ont pas a se rafraichir de A à Z pour se réafficher avec beryl/compiz/compiz-fusion c'est donc instantané).
- Il bouffe de la RAM au pti'dej' (mes 3 Go sont suffisant, certe, mais
vu comme il gratte sur mes DD tout le tps, c'est certainement pas avec du cache disque qu'il rempli ma RAM, du coup je me demande avec quoi!)
Alors si. je le préfère tout de même Vista à XP pour le principe de l'UAC et pour l'autre grande avancée technologique: la recherche bien foutue du menu démarrer (ça vaudrait presque une console avec auto complétion ;) ) qui gère notamment les pertinences sur les fréquences d'utilisation (c'est bien bien bien mieu que launchy). Mais bon, pour Linux est vraiment en avance à présent côté réactivité et agrément du desktop.
Conclusion: si quelqu'un veut me faire don de 1100 ¤, ou est assez fort pour corriger mon probleme de performances dans wine, je reviens sous Linux, je n'attend que ça !
PS: tandis que je ne notai aucune différence entre mode fenêtré et full screen sous linux pour WoW(et j'avais en gros le même fps que sous win), j'ai pu constater que sous VG j'ai une différence de 5-10 fps entre fenêtré et fulls creen (et j'ai droit à un swap de 10s pour faire un alt-tab qd je suis en full screen... vive le fait que aero soit débranché ...) une idée du pourquoi ?
En un sens, et vu la nouvelle évolution des processeurs ( multiplication des cores ) il va falloir changer notre façon de programmer, et le langage qui me parait le plus indiqué pour le faire est l'Erlang puisqu'il est fait pour permettre de passer de 1 à N core avec quasiment un facteur N d'amélioration de performances (les cores peuvent partager la memoire ou non aussi, ce n'est pas un problème à gérer côté développeur... Alors qu'avec les autre langages, proposant des threads dans une memoire partagee... ça pose plus de problèmes).
J'avoue ne pas avoir encore beaucoup pratiqué, mais du coup après avoir vu tout ça je trouve dommage que tu n'ai pas mis l'Erlang/Yaws/ErlyWeb parmis les alternatives :)
Sinon bon courage pour le de votre ORM, mon experience d'hibernate me fait dire que ça m'est devenu indispensable ;)
Le documentaire est sympa, même si je ne l'ai vu qu'en anglais non sous-titré, car parfois faut s'accrocher pour comprendre (le bon côté c'est que pour l'avoir regardé plusieurs fois, ça m'a donné un accent pas trop crade en anglais :P).
Mon moment préféré demeure l'intro, je la connais presque par coeur... "I'm your worst Nightmare!"
Globalement pour quelqu'un qui a besoin d'acceder a de multiple serveur, TuTTY est bien mieu ( http://putty.dwalin.ru/ ) car il permet de "ranger" proprement ses serveurs (c'est aussi très pratique pour faire des consoles qui lancent directement des scripts sur les machines distantes) et donner un nom cohérent à la fenêtre (et en changer l'icône), le tout avec aussi un tray (un session manager a coller dans le menu Démarrer)
Si vous voulez de la transparence comme PuTTY Tray, il suffit d'utiliser Vitrite avec ( http://www.framasoft.net/article2320.html ). Par contre ca rend toute la fenetre transprente, alors qu'il serait mieu que ce ne soit que le fond (avec les raccourci je "transparente" en live lorsque j'ai besoin de voir a travers, mais on ne voit plus rien a ce qu'on ecrit souvent dans ce cas, c'est chiant...
J'avais trouvé aussi un outil permettant de modifier des paramètres avec toutes les (ou un partie des) sessions enregistrées de putty (trèèèès pratique), ca marche bien, mais pas quand les sessions sont dans des "sous repertoires". Malheureusement j'ai perdu le nom...
J'ai pensé a faire mon propre putty tout patché avec ce que je voulais, mais il faut à priori VC que je n'ai pas (j'ai vaguement regardé comment faire sans, et ça m'a vite gonflé :P ).
J'ai testé pleins de dérivé de putty, et franchement tutty est le mieu foutu, mais les outils pour putty même ne fonctionnet pas tous (genre celui qui permet d'envoyer le texte que tu tapes dans plusieurs fenetre en même temps)
Il y a quelques années, dans l'esprit de participer à ce formidable esprit de partage de connaissance qu'est la coupe, j'avais créé feu http://wikibot.ma.cx (certains participant comprendons a quoi correspond le logo !) -- qui n'a plus vocation à être actif, d'où sa lenteur incomparable --.
J'avais vu, avec plusieurs équipe(dont la mienne!), pour intégrer leurs documentations sur ce site afin de faire profiter à la communauté de doc mises à jours, toujours dans cet esprit de partage qu'il y a à la coupe.
Je fût contacté quelques mois plus tard par le président de la section robotique de planète science, afin de faire un site officiel wikibot sur planète sciences. Malheureusement je n'ai pas pu les aider (principalement par manque de temps, et d'autres priorités a gérer à ce moment là), mais dans une grande motivation, ils ont refait le site, officiellement cette fois http://www.planete-sciences.org/robot/wikibot/ .
Je conseil à tous les participant de la coupe d'aller y faire un tour ce peut être une vrai mine d'information(et si possible complètez le avec vos connaissances !).
Si vous êtes un peu motivé aussi, aidez le site en transférant ce qui n'a pas été pourri par les bot anti wiki sur mon ancien wikibot (qui fut ma premiere source de démotivation) dans les sections qui vont bien. Le nouveau wikibot en a bien besoin car la première sensation est qu'il est un peu vide (si on ne fouille pas trop).
Ce projet à toujours été un petit rêve pour moi, mais un jour il fût trop gros pour moi seul ( je remercie d'ailleurs tous les participants au site, qui à l'époque partageait ma vision des choses et se sont donné pour fournir de bons articles a la communauté)
[^] # Re: Intégration avec Greasemonkey
Posté par Temsa (site web personnel) . En réponse à la dépêche Archetype Javascript Framework 0.1. Évalué à 1.
[^] # Re: Démo ? Pas encore ...
Posté par Temsa (site web personnel) . En réponse à la dépêche Archetype Javascript Framework 0.1. Évalué à 2.
http://sd-10490.dedibox.fr/Archetype-0.1.0/WebContent/Slidy.(...)
[^] # Re: Surcouche de surcouche
Posté par Temsa (site web personnel) . En réponse à la dépêche Archetype Javascript Framework 0.1. Évalué à 1.
Genre Hibernate, c'est une horrible surcouche a JDBC lui meme une surcouche au lib d'accès aux BDD ... Mouarf :x
[^] # Re: Démo ? Pas encore ...
Posté par Temsa (site web personnel) . En réponse à la dépêche Archetype Javascript Framework 0.1. Évalué à 1.
Sinon j'ai d'autre serveur dispo mais pas de nom de domaine potable (on devrait en acheter un quand AWiki sera fini) pour mettre la démo dessu :P
[^] # Re: Intégration avec Greasemonkey
Posté par Temsa (site web personnel) . En réponse à la dépêche Archetype Javascript Framework 0.1. Évalué à 1.
On est très orienté page web, et j'ai a peine commencé a me documenter sur comment faire en sorte que ca marche dans les extension samedi aux JDLL (sur le stand de mozilla).
Si t'as des tuto pr les script grease monkey, par contre, ca m'interesse :)
[^] # Re: Démo ? Pas encore ...
Posté par Temsa (site web personnel) . En réponse à la dépêche Archetype Javascript Framework 0.1. Évalué à 1.
En ce moment je n'ai pas le net chez moi (déménagement) et seul Swiip peu avancer en dehors du mardi (journée pendant laquelle notre boite nous paye à développer Archetype :D)
[^] # Re: Démo ? Pas encore ...
Posté par Temsa (site web personnel) . En réponse à la dépêche Archetype Javascript Framework 0.1. Évalué à 1.
Il ya a 2 petites démo :
- "Hello world" qu'on ouvre avec Start.html
- Slidy un présentation type "Powerpoint" dans le navigateur faite avec Archetype (on a repris un application disponible sur le site du W3C, d'ou les non hack css pour les navigateur ne supportant pas tout bien à ce niveau là, je corrigerai ça d'ici la 0.1.1 ou la 0.2) qui propose de faire soi même sa première application avec Archetype :)
Amusez-vous bien :)
# En cas d'utilisation du train
Posté par Temsa (site web personnel) . En réponse au journal Transport pour les JDLL. Évalué à 2.
Je suis contactable sur 1e5ozk8lulrgvhf@jetable.net (adresse valable une semaine) pour plus d'informations.
[^] # Re: ...
Posté par Temsa (site web personnel) . En réponse au journal Aptana passe en double licences APL+GPL. Évalué à 2.
Perso même si j'ai un vi configuré au pti oignons, un Eclipse aussi bien configuré est loin d'être si mauvais qu'on le prétend !
# A noter
Posté par Temsa (site web personnel) . En réponse à la dépêche Aptana : finalement ce sera de la double licence.. Évalué à 3.
J'aime beaucoup Aptana, mais des trucs simples comme l'indication de l'utilisation d'une variable ailleurs dans la page (les petits carré jaune vers la barre de défilement qu'on voit qd on est sur une fonction ou une variable, dans JSeclipse, ou dans l'editeur Java) manque par exemple.
Au début, j'utilisais peu ce genre d'information mais ca évite souvent une recherche dans le code et c'est donc bien pratique sur un code long. JSEclipse possède ce petit plus (qu'on a ususellement dans du coe java d'ailleurs).
Là ou Aptana est fort, c'est sur le "scope" de fichiers pour l'autocomplétion: qd on ouvre un fichier html, il regarde les include javascript et rajoute tout seul dans un "scope" les fichiers pr faire la complétion surles variables contenues. On peut aussi le faire en manuel ce qui est vraiment très pratique.
Là ou dans sa grande force il a une faiblesse, c'est qu'il ne comprend pas "tout". Ainsi, si je ne dis pas de bêtise, il ne fait pas la complétion sur les objets qui ne sont pas créés de manière "naturelle".
Je m'explique : un objetMachin.prototype.methode(param1,param2) permettra d'avoir l'autocomplétion aussi bien sur param1, que param2, ou sur methode. Par contre un objetMachin= Class.create(mapDecrivantLePrototypeContenantLaMethode_methode) ne fonctionnera pas.
Or le 2e cas, avec l'évolution des framework javascript risque d'affluer en grand nombre. Dans notre Framework, Archetyp (cf signature) on a redéfini Class.create pr fonctionner comme dans le 2e cas décrit. On a de la même manière un Component.create (1) et la complétion n'est pas prise en compte (tout comme la Jsdoc du prototype, en tout cas avec JSDoc Toolkit et les options de bases + "-a").
La modification de Class.create dans ce sens est identique dans Prototype 1.6.0rc0 (Archétype est basé sur Prototype 1.5.1, mais l'évolution de Prototype rattrape certaines idées que l'on a implémentées dan Archétype), sachant que c'est le framework javascript le plus utilisé, ca va faire rapidement beaucoup de problèmes.
En même temps c'est normal, comment sait-il que Class.create/Component.create contient une définition d'objet ? 3 solutions: interprêter le code, ou permettre la création de fichier de description de certaines fonctions comme le propose JSEclipse (2), ou encore l'interprêtation de certaines données de la JSDoc de la fonction, cumulé a des conventions (3), ce qui serait ss doute le plus simple !
J'ai parlé JSDoc, je trouve Aptana aussi assez fort dans le domaine, puisque qu'un raccourci permet de construire automatiquement le commenatire JSDoc au dessus de la fonction dans laquelle se trouve le curseur, prérempli des paramètres qu'elle possède.
JSEclipse, lui, se contente de supporter la complétion sur les attributs de la JSDoc, et n'est même pas très à jour dans le domaine d'ailleurs.
Bref tandis que je me résignai à utiliser JSEclipse et abandonner Aptana (4), j'ai trouvé de bon côté a JSEclipse, mais l'éditeur Javascript parfait n'est pas encore là, même si avec Aptana et JSEclipse mélangé, on aurait sans doute un truc vraiment bien pour bosser!
Une chose est sure pour moi, les outils arrivent, on va arrêter de coder du javascript caché dans du code serveur, et on va réèllement codé en javascript pour la vue, le controlleur, et passer par des passerelles de RPC comme DWR pour la communication avec le code métier, pour ne pas avoir a s'en soucier ni à la coder pour chaque appli.
Les éditeurs poussés, comme Aptana ou JSEclipse devraient le permettre sans difficulté pour le programmeur, les navigateurs sont en pleine tendance d'accélération matérielle du graphisme et de patater le javascript, les frameworks permettront de se dégager des soucis de compatibilité (ce qui est déjà fait en grande partie), et faciliteront beaucoup le développement JS, aussi on devrait voir se multiplier dans les prochains mois des appli lourde "web 2.0" dont une bonne partie du développement aura été fait côté javascript, et non caché dans du code coté serveur qui en fait est du javascript (5).
Bon bon bon, amusez-vous bien , et essayez Archetype(6), vous verrez ce que c'est de programmer sympathiquement en JS ;o)
(1) : Les "component" sont des classes améliorées, permettant d'avoir des services ajoutés transversaux(comme l'enregistrement automatique de fonction "onMachin" aux évènements "Machin"), notamment le chargement des dépendances --transitives-- requises à son fonctionnement avant son chargement et permettent de manière aisée de créer des sortes de widgets graphique, séparant vue controleur et model, au lieu de tout mélanger comme des porcs dans du code javascriptohtmlocssoïque, ou pire, "DOMcentrique")
(2) : Je sais que c'est des XML, mais j'ai jamais trouvé ceux de Prototype et j'ai jamais vraiment fouillé, du coup la complétion est assez moyenne dans JSEclipse je trouve, des qu'on utilise des lib de ce type, car il ne connais jamais le scope de ce qui nous intéresse.
(3) : Une annotation "@createObjectByMap param1" par exemple, pour indiquer qu'on va créer un objet a partir de la map "param1" qui se trouve en paramètre
(4) : "sapusaipulibre" c'était pire que pas être libre d'origine ! EN même temps j'avoue ne pas avoir lu la nouvelle license, mais son changement me chigrinait tout de même surtout pour aller vers quelquechose de non redistribuable ou presque ...
(5) : RoR, JSF, Struts, Tapestry5, j'en passe cachent le JS qu'ils utilisent... C'est gentil mais ça ne fait jamais tout ce dont on a besoin, et au final on s'embête plus avec que sans, en utilisant un simple DWR pour communiquer...
(6) : On a un problème de compatibilité avec IE7 pour le moment, depuis qu'on a revu un des fonctionnement du coeur de l'appli, pr le rendre plus astucieux et plus léger(on a supprimé des "eval" et des new Function("") qui nous plaisaient pas du tout par du objet["methode"] simple léger et efficace), c'est pour ça qu'on fait pas encore notre première release (la 0.0.9, on prévoit la 0.1 mi octobre, agrémentée de doc et de petits exemple!) ... Néanmoins le code est Checkoutable sur notre SVN pour faire joujou, n'hésitez pas !
En attendant que je retourne au boulot pour avoir un moyen de débogguer pour IE7, on commence le développement de Awiki, un wiki Wysiwyg fait avec Archetype/TinyMCE/DWR/Spring/Hibernate, basé sur des idées façon tiddlywiki ou xookie, mais avec une BDD derrière, et une vrai gestion de version.
# Le blog en image, bien mais limité !
Posté par Temsa (site web personnel) . En réponse au journal Redesign de l'interface de gimp. Évalué à 3.
Je vais l'exprimer ici sous forme de texte, en attendant d'avoir le courage de fabriquer 2 ou 3 images caractéristiques à partir de rien (j'arrive même pas a trouver les icône de la barre d'outils sans aller chercher les sources, ça me gonfle...) puisque je ne connais pas d'interface comme ça :)
Les principes de mon interface, sont :
- D'abord que les ordinateurs taillé pour faire du traitement d'image ne sont jamais des bouses, et on peut donc faire une interface très mobile (beryl / e17 like) car il y a toujours une accélération graphique suffisante
- Toujours maximiser l'espace de travail pour travailler sur les images
- Avoir une vue scalaire des informations, aka le principe du "FishEye" : l'idee de base c'est genre une barre MacOSX pour chaque "dock" (même concept de dock que l'actuel): quand la souris est loin et ne travaille pas (aka click enclenché), on ne voit que l'icone/titre du dock, puis on se rapproche, un minidock apparait, avec les informations importantes du dock (mode sélectionné, etc.) puis on a plus d'informations, jusqu'a l'ensemble des options, ce qui revient quasiment à une fenêtre, qui pourrait être "épinglable" (pour rester verrouillée dans cet état si besoin).
Je détail le dock des outils par exemple: les outils sont en ligne verticalement façon barre OSX, et minimisé ils ne dépassent pas sur le/les buffer image. Plus on rapproche la souris d'un outil, plus on a d'informations dessus: une icone qui déborde sur l'image pour bien l'identifier, le nom de l'outil qui apparait puis eventuellement une petit aide, ou un truc/astuce sur l'outil,(desactivable) et quand on passe la souris sur l'icone, aparaissent les options de l'outil, on peut alors facilement cliquer sur l'outil pour le selectionner et règler ses options. Pour voir l'état des options et les changer, un simple coup de souris dans la direction du dock montrera rapidement l'information nécéssaire.
Si on pense avoir à rechanger les options regulièrement pendant le travail avec l'outil, on "épingle" les informations de l'outil (sous forme de dock contextuel/ fenetre MDI ou multifenêtre suivant les options utilisateur, par exemple, pour moi ca dépendrai si j'etais sous Linux ou Win :D )
- Avoir une gestion d'action sur les images (filtre, script, propriétés de l'image/du canevas, inversion de la sélection, changement de couleur ) avec favoris/ liste de MRU, par exemple sur un dock (toujours type FishEye) en bas au centre de l'application (dans la conf par défaut)
- Avoir des vues, de la même façon qu'on peut avoir des vues dans Eclipse (et d'autre éditeurs) permettant un autre agencement des barres/ dock/etc.
- Avoir eventuellement des workspaces permettant de switcher d'images ouvertes entre les workspaces (façon calques de blender, une image peut etre sur plusieurs workspaces, seules ou avec d'autres images).
On pourrait même garder la dernière vue utilisée dans le workspace afin de swicher facilement beaucoup de chose.
Par exemple, un workspace permettant de picorer des bouts d'image par-ci par-là sur d'autres image que l'image de travail, avec une vue organisée pour cela(on pourrait imaginer de voir dans cette vue le gestionnaire de calque avec l'ensemble des calques de toutes les images ouvertes dans le workspace), et un workspace ou on a que l'image de travail (on switcherai dessus en changeant d'onglet par exemple, façon FF), avec que les outils de peinture avec les brosses facilement accessibles et listé dans un dock FishEye(avec une recherche sur les tag dans le dock, suivi des brosses triés par nombre de fois ou elles ont été utilisées, vu qu'ils vont utiliser des tags pour catégoriser, d'apres la video que j'ai vu, pour les brosses/tiles/gradient/etc.).
Bon, si vous voyez comment faire 2 images permettant d'expliquer tout ça, je prend (d'autant plus si elle est déjà faite ^_^) !!
Je suis sur que c'est une configuration permettant d'exploiter les écran pas énormes facilement, tout autant que les dual screens (on peut imaginer des colonnes de docke FishEye, ça me parait pas déconnant à mettre sur le 2e écran), que ça permettra au débutant d'apprécier avec une vue simple qu'il peut personnaliser, et à l'expert d'augmenter sa productivité avec un environnement conditionné comme il l'entend à tout moment grâce aux workspaces/vues/favoris/MRU.
Le seul inconvénient c'est que ça nécéssite un minimum d'accélération graphique (2D) pour que ça ne rame pas(ou alors être basé sur les EFL pour l'interface ! ), mais ce prérequis ne sera pas un problème d'ici peu (les drivers graphique semblent s'ouvrir ces temps-ci :D ) quelque soit la plateforme, et même sur les périphériques portable car eux aussi se font accélérer le graphisme maintenant :P
[^] # Re: CPE
Posté par Temsa (site web personnel) . En réponse à la dépêche Les JDLL 2007, c'est bientôt. Évalué à 1.
[^] # Re: CPE
Posté par Temsa (site web personnel) . En réponse à la dépêche Les JDLL 2007, c'est bientôt. Évalué à 0.
On compte notamment parmis les profs, un des core developer du Gimp ( je lui avais moi même poussé 1-2 patchs ), David Odin, sachant qu'un autre, Dave Neary, habite aussi sur Lyon, et qu'il fait régulièrement des conférences aux JDLL.
Bref CPE met le logiciel libre dans la culture de l'ingénieur et beaucoup de Cpéen souhaiteraient aider un logiciel libre d'une manière ou d'une autre. Pour ma part j'ai entamé un gros projet libre avec un ami, un vrai framework javascript pour montrer qu'on peut réellement développer en javascript ses RIA et qu'avec de bon outils ce n'est pas plus dure que du web1. Nous sommes même soutenu par notre boite qui nous paye 1 jour par semaine a travailler sur notre projet, et somme en phase de freeze pour une 0.1, qui apporte déjà son lot de petites révolutions dans le domaine :) J'espere que nous pourrons présenter ce framework l'année prochaine aux JDLL !
PS pour toi benoit: En comptant les chimistes et les electroniciens, vu qu'on est généraliste, dans les faits, on doit produire environs 120 informaticiens par an (1/3 des chimistes, 2/3 des electroniciens directement, et le reste des electroniciens font de l'info + de l'elec en gros).
Je ne pense pas que l'INSA Lyon produise 1000 informaticiens par an, aux vues des proportions, comparables, dans ma boite (entre 10 et 15% chacun), entre les 2 ecole lyonnaise (il y a un peu plus d'INSA, mais tous ne sont pas de l'INSA Lyon).
[^] # Re: CPE
Posté par Temsa (site web personnel) . En réponse à la dépêche Les JDLL 2007, c'est bientôt. Évalué à 1.
Oscar était vraiment impliqué pour faire marcher l'école avec le libre, qu'elle le soutienne et accueil des journées telles que celles ci (on notera que l'utilisation de Zope sur le site des JDLL n'est sans doute pas étrangé au passage d'Oscar sur cette terre).
On a manqué accueillir un rassemblement mondial des développeur de The Gimp mais le dossier n'est pas passé (on était 2 avec l'angleterre a rester, si j'ai bon souvenir, mais ils ont pris l'angleterre) :'(
A noter qu'il y a un autre développeur du Gimp sur Lyon, Dave Neary, qui fait souvent des conférences lors des JDLL, peut-être cette année aussi.
Bref c'est loin d'être déplacé de faire les JDLL là bas, c'est des passionés qui l'ont permis (fallait convaincre l'école déjà!) :)
PS: Arrête de dire qu'on est pas une école d'info, soit réaliste, 1/3 des chimistes sont dans l'info, et 2/3 des electroniciens font purement de l'info (le dernier 1/3 fait de l'élec + de l'info !) et la plupart se spécialisent fortement en info en 2e & 3e année. On est généraliste, oui, mais on créé pas mal d'informaticiens... à vue de nez 120/an.
Sur Lyon, dans ma boite (d'informatique), CPE Lyon représente environs 10% des effectifs (l'INSA Lyon représente entre 10 et 20% je pense, l'INSA Lyon ne produit pas que des informaticiens, et je doute que les promos d'info+elec représente 1000 informaticiens par an). On est même un peu plus en % sur le projet Geoportail je pense (15-20% pareil que l'INSA "toute provenance"). Nous sommes tous des pro libres convaincu je pense, vu qu'on en utilise toute la journée, et qu'on commence même à en produire (cf. ma signature) :D
Bref, l'INSA a aussi ses conférences sur le libre (je me rappel d'une sur OOo par exemple) et il ne me parait pas déplacé que ces conférences aient lieu a CPE
[^] # Re: Analyse juste ?
Posté par Temsa (site web personnel) . En réponse au journal L'ex directeur marketing de Microsoft France analyse Vista. Évalué à 1.
avec 2-3 trucs un peu innovant (même si on retrouvait le gros des trucs "innovants" déjà ailleurs...).
Néanmoins la gestion de seulement 2Go de ram pour XP me rend rébarbatif le fait de revenir dessus (perdre 1 Go de RAM ... mouarf :/)
Bon sinon je cherche un expert OGLSL pour faire tourner VG suffisament vite sur mon ordi sous wine :D
[^] # Re: les drivers nvidia posent problème pour vista aussi ?
Posté par Temsa (site web personnel) . En réponse au journal L'ex directeur marketing de Microsoft France analyse Vista. Évalué à 4.
Sinon perso après 2 ans de Linux (pas de windows du tout sur le pc) je suis repassé a Windows Vista ( vous inquiétez pas j'ai gardé ma Ubuntu à côté, et c'est toujours elle qui a droit a 80% de mon disque dur ^_^) ... et je m'en mords les doigts de plus en plus...
La raison de ce retour à Windows, c'est mon passage de WoW (tournant parfaitement sous Linux avec wine, même s'il est plus gourmand côté processeur) à Vanguard SoH qui tourne entre 0.5 et 2 fps sous Linux avec wine en le tunant à mort (j'envisage de m'acheter un PC de grosse brute pour repasser sous Linux tout de même).
La raison est un problème d'implémentation d'un bout d'openGLSL qui est fait côté CPU pour Linux lors de l'utilisation de VG, ce qui ne permet pas de bonnes performances (bien qu'ayant tenté de regarder, je manque sérieusement de compétence pour faire le patch qu'il faut ... )
J'explique pourquoi je regrette vraiment Linux (même si j'ai un public converti devant moi ! ). Sous Vista:
- Mon PC passe largement 30% de sont temps à gratter sur le DD (je suppose que ça a à avoir avec l'indexation pr les recherches rapides).
- J'ai du désactiver l'UAC alors que je suis pour (c'est un vrai pas dans le bon sens pour une séparation root / user)!
Ses passages par une popup modale qui noirci le reste de mon bureau en passant par une coupure de l'écran puis un réaffichage me gonfle.
Surtout que ça rame (en fait je me demande si Aero sert a quelquechose là dedans car je vois pas en quoi faire un truxc noir transparent en fond d'écran doit faire ramer le reste de mes appli ... ?)
Si je lance ventrilo en mode user, l'application ne reçoit ce qui vient de mon micro que lorsqu'elle à le focus ! je dois donc la lancer en administrateur (c'est clairement pas le but de ventrilo d'être la fenêtre avec le focus)
Résultat 80% des appli il faut les lancer en administrateur (et ici c'est bien la faute des développeur des applis, pas de Microsoft). Un exemple parmis d'autre, Firefox (en fait je tourne sur Minefield), pour qu'il puisse se mettre à jour(ya des MaJ tous les jours)!
- Les gadget Vista sont NUL !
La barre d'Aero ne se souvient jamais de rien : affichage de la place restant sur les disques dur: OK, sauf que 2 gadget, un pour C, un pour D, je configure le 2E pour D: a chaque démarrage car il est pas foutu de se rappeler qu'il faut regarder D: (il me remet C: sur le 2e tout le temps)
Résultat je vire la barre Aéro. Coupure d'electricite, hop elle revient par magie , j'ai rien demandé ...
- Je lance un media player (VLC, SMPlayer par exemple, j'ai gardé mes logiciels préférés ;P) hop hop ni une ni deux, aéro se désactive. C'est vrai, c'est tellement normal, le media player pourrait mettre la carte graphique a genou avec son film à diffuser, faut vite enlever les effets graphique jolis pour pas que ça rame... Après je redémmare sous Linuwx, et je fait tourner le cube de compiz fusion, ses engrenage GLX gear au coeur du cube et j'ouvre 10 videos et je fais tourner le cube pr m'amuser, et du coup j'ai du mal a comprendre pourquoi Windows désactive Aéro...)
- Aero ne sert à rien (juste à la transparence des barres de titre des fenêtres, c'est tout)! Je me demande même s'ils ont pensé a l'utiliser de temps à autre, le switcher de fenêtre 3D sert à rien(c'est même pas lui qd on fait alt-tab), la réduction/ouverture des appli qui peuvent ramer, bah ça rame (alors que sous Linux, une de mes grandes joies c'est que les applis n'ont pas a se rafraichir de A à Z pour se réafficher avec beryl/compiz/compiz-fusion c'est donc instantané).
- Il bouffe de la RAM au pti'dej' (mes 3 Go sont suffisant, certe, mais
vu comme il gratte sur mes DD tout le tps, c'est certainement pas avec du cache disque qu'il rempli ma RAM, du coup je me demande avec quoi!)
Alors si. je le préfère tout de même Vista à XP pour le principe de l'UAC et pour l'autre grande avancée technologique: la recherche bien foutue du menu démarrer (ça vaudrait presque une console avec auto complétion ;) ) qui gère notamment les pertinences sur les fréquences d'utilisation (c'est bien bien bien mieu que launchy). Mais bon, pour Linux est vraiment en avance à présent côté réactivité et agrément du desktop.
Conclusion: si quelqu'un veut me faire don de 1100 ¤, ou est assez fort pour corriger mon probleme de performances dans wine, je reviens sous Linux, je n'attend que ça !
PS: tandis que je ne notai aucune différence entre mode fenêtré et full screen sous linux pour WoW(et j'avais en gros le même fps que sous win), j'ai pu constater que sous VG j'ai une différence de 5-10 fps entre fenêtré et fulls creen (et j'ai droit à un swap de 10s pour faire un alt-tab qd je suis en full screen... vive le fait que aero soit débranché ...) une idée du pourquoi ?
# ORM pour Erlang
Posté par Temsa (site web personnel) . En réponse à la dépêche PhpMyObject 0.06 vient de sortir. Évalué à 2.
Etant developpeur utilisant Java/Spring/Hibernate/DWR/Tapestry5/Struts côté serveur, j'ai trouvé Yaws ( http://yaws.hyber.org/ ) en serveur web/d'application (utilisable comme un apache haute disponibilité), Erlyweb ( http://erlyweb.org/ , http://erlyweb.org/doc/ ) en framework fournissant notamment ErlyDB ( http://erlyweb.org/doc/erlydb.html ) pour l'ORM.
En un sens, et vu la nouvelle évolution des processeurs ( multiplication des cores ) il va falloir changer notre façon de programmer, et le langage qui me parait le plus indiqué pour le faire est l'Erlang puisqu'il est fait pour permettre de passer de 1 à N core avec quasiment un facteur N d'amélioration de performances (les cores peuvent partager la memoire ou non aussi, ce n'est pas un problème à gérer côté développeur... Alors qu'avec les autre langages, proposant des threads dans une memoire partagee... ça pose plus de problèmes).
J'avoue ne pas avoir encore beaucoup pratiqué, mais du coup après avoir vu tout ça je trouve dommage que tu n'ai pas mis l'Erlang/Yaws/ErlyWeb parmis les alternatives :)
Sinon bon courage pour le de votre ORM, mon experience d'hibernate me fait dire que ça m'est devenu indispensable ;)
# Ouinnnn
Posté par Temsa (site web personnel) . En réponse au journal Youpi !!!. Évalué à 10.
[^] # Re: La perle rare existe (?)
Posté par Temsa (site web personnel) . En réponse au journal Topachat ca devient n'importe quoi. Évalué à 3.
Ils repondent par mail aussi, très vite, et de façon compétente :)
Et en cas de petit problème, ça se passe très bien aussi :)
Mon magasin préféré quand je veux être sur de ne pas avoir de problème, après... Parfois je préfère prendre des risques vu les différences de tarif
[^] # Re: Moi je vais pas tarder...
Posté par Temsa (site web personnel) . En réponse au journal Les bureaux de votes sont ouverts.... Évalué à 3.
[^] # Re: Moi je vais pas tarder...
Posté par Temsa (site web personnel) . En réponse au journal Les bureaux de votes sont ouverts.... Évalué à 1.
le spiegel et le zeit (mais faut comprendre un minimum l'allemand, c'est pas mon fort) en parlent
Sur les journeaus anglais que j'ai pas de resultat pour le moment
[^] # Re: Moi je vais pas tarder...
Posté par Temsa (site web personnel) . En réponse au journal Les bureaux de votes sont ouverts.... Évalué à 1.
Une chose m'a frappé, au fûr et à mesure de la journée, les textes changent peu, par contre ... les photos beaucoup !
En 2h, 3 photos de segolène ont été remplacées: 2 par celle de bayrou, et un par des bulletins de vote ... ! ???
Sont-ce des infos avant l'heure ?
# L'intro
Posté par Temsa (site web personnel) . En réponse à la dépêche "Revolution OS" à l'Utopia Tournefeuille (31) le 27/11/2006. Évalué à 0.
Mon moment préféré demeure l'intro, je la connais presque par coeur... "I'm your worst Nightmare!"
[^] # Re: OpenSSH roxorz
Posté par Temsa (site web personnel) . En réponse à la dépêche OpenSSH version 4.4 fait dans la finesse. Évalué à 8.
Si vous voulez de la transparence comme PuTTY Tray, il suffit d'utiliser Vitrite avec ( http://www.framasoft.net/article2320.html ). Par contre ca rend toute la fenetre transprente, alors qu'il serait mieu que ce ne soit que le fond (avec les raccourci je "transparente" en live lorsque j'ai besoin de voir a travers, mais on ne voit plus rien a ce qu'on ecrit souvent dans ce cas, c'est chiant...
J'avais trouvé aussi un outil permettant de modifier des paramètres avec toutes les (ou un partie des) sessions enregistrées de putty (trèèèès pratique), ca marche bien, mais pas quand les sessions sont dans des "sous repertoires". Malheureusement j'ai perdu le nom...
J'ai pensé a faire mon propre putty tout patché avec ce que je voulais, mais il faut à priori VC que je n'ai pas (j'ai vaguement regardé comment faire sans, et ça m'a vite gonflé :P ).
J'ai testé pleins de dérivé de putty, et franchement tutty est le mieu foutu, mais les outils pour putty même ne fonctionnet pas tous (genre celui qui permet d'envoyer le texte que tu tapes dans plusieurs fenetre en même temps)
# Il manque un lien important
Posté par Temsa (site web personnel) . En réponse à la dépêche Coupe de France et d'Europe de Robotique 2007. Évalué à 2.
J'avais vu, avec plusieurs équipe(dont la mienne!), pour intégrer leurs documentations sur ce site afin de faire profiter à la communauté de doc mises à jours, toujours dans cet esprit de partage qu'il y a à la coupe.
Je fût contacté quelques mois plus tard par le président de la section robotique de planète science, afin de faire un site officiel wikibot sur planète sciences. Malheureusement je n'ai pas pu les aider (principalement par manque de temps, et d'autres priorités a gérer à ce moment là), mais dans une grande motivation, ils ont refait le site, officiellement cette fois http://www.planete-sciences.org/robot/wikibot/ .
Je conseil à tous les participant de la coupe d'aller y faire un tour ce peut être une vrai mine d'information(et si possible complètez le avec vos connaissances !).
Si vous êtes un peu motivé aussi, aidez le site en transférant ce qui n'a pas été pourri par les bot anti wiki sur mon ancien wikibot (qui fut ma premiere source de démotivation) dans les sections qui vont bien. Le nouveau wikibot en a bien besoin car la première sensation est qu'il est un peu vide (si on ne fouille pas trop).
Ce projet à toujours été un petit rêve pour moi, mais un jour il fût trop gros pour moi seul ( je remercie d'ailleurs tous les participants au site, qui à l'époque partageait ma vision des choses et se sont donné pour fournir de bons articles a la communauté)
http://www.planete-sciences.org/robot/wikibot/index.php/Accueil