voui, c'est ce qui me fait loucher vers mercurial
A priori c'est quand même du niveau de git (du même niveau quoi) mais avec de meilleurs outils pour windows / eclipse (important pour moi)
Du moment que les fonctionnalités sont là ;)
(sous linux uniquement j'utiliserais git)
A priori par contre il existe plusieurs interfaces à svn, contrairement à git
en fait, tu avais raison... j'étais pas encore assez loin dans la vidéo
Au début il tape sur cvs mais ensuite, au delà du fait que pour lui cvs et svn est quasi identique, il tape aussi sur la gestion (ou non gestion) du merge dans subversion
> que quelques merges sur des projets utilisés via SVN
Ceci explique cela...
Fais-en un peu plus et tu comprendras ;)
Tiré d'un journal précédent, mais vécu de trop nombreuses fois : Je veux fusionner depuis une branche, mais les fichiers ont été déplacés/renommés dans le trunk. TortoiseSVN me répond systématiquement "skip missing target"...
(on peut remplacer tortoise par n'importe quel client svn hein...
(journal : https://linuxfr.org/~NoNo/26146.html )
hum ... jsuis pas vraiment d'accord, surtout avec le dernier paragraphe (ou plutôt je ne réagis pas du tout pareil)
Moi ce qui m'intéresse aujourd'hui dans un truc comme git (s'il y a autre chose de mieux ça me gène pas hein ;)) c'est justement pas l'aspect décentralisé (même si c'est pratique) mais l'aspect branches.
Aujourd'hui, je dois me préparer à maintenir un trunk, 2 à 3 branches de maintenance, 1, 2 ou plus ça dépend branches de dev expérimental / choses ne rentrant pas dans le trunk par projet. (c'est du grossier)
avec un truc comme ça et un système comme svn c'est galère.
Alors oui c'est technique, mais ça pue.
Dans certains cas il est interdit à certaines personnes de commiter sur des branches de maintenance. Problème : certaines personnes vont tout de même créer des correctifs mais ne pourront jamais les versionner -> c'est le bordel, les commits ne ressemblent plus à rien, c'est chiant à faire, et s'ils sont pas intégrés rapidement c'est horrible.
Avec un système de branche ... c'est plus facile.
Le côté décentralisé ... ben heu ... c'est pas ce que je recherche, mais ça peu avoir des côtés intéressant, surtout lorsque l'un des développeurs veut se lancer dans une expérimentation sans polluer la branche principale, ni créer de branche distante sur le répo principal.
De puis, pour mon cas, ça reste une utilisation assez professionnelle et dans ce cas c'est pas l'outil qui pose des problèmes de communication, loin de là.
D'ailleurs un tel outil permet dans certains cas de mieux communiquer :
plutôt que de se retrouver un jour avec des commits apparaissant n'importe comment sans avertir les développeurs en charge, on va au contraire apprendre qu'untel a fait des modifs dans sa branche / nous a envoyé des patch et on va les intégrer.
Alors oui, gestion des droits, toussa, mais ça ne répond pas toujours aux règles fines qu'on souhaite.
(je sais pas si je me fais bien comprendre là...)
Un VCS décentralisé ne favorise pas plus le travail individuel, mais il garanti à chacun de pouvoir versionner son taff (très important, surtout quand on voit que certains ne comprenent toujours pas l'intéret...) à chacun de pouvoir améliorer le taff de l'autre, et aux responsables de pouvoir améliorer l'ensemble en prenant facilement les idées de tous.
Ca fait un peu fouilli dit comme ça mais c'est au contraire poser un cadre, des outils pour le réguler facilement.
> Moi, je préfère le travail collectif et donc, je n'utiliserai jamais git à moins d'y être forcé. J'aime bien SVN, il fait ce que je veux, point. Les features qui manquent, elles arriveront un jour, je ne me fait pas de souci.
C'est une erreur je pense, git est simplement un meilleur outil que svn. Il manque beaucoup trop de feature, et le fait d'ajouter des commits locaux ... voui mais tant que le merge ne sera pas utilisable franchement j'en veux pas.
Et les features ... ben c'est aujourd'hui que j'en ai besoin :(
Intéressant tout ça...
On est en train d'essayer de faire quelque chose du genre justement (utilisation des branches entre autre)
Par contre c'est vrai que la perte des infos de merge me plait moyen, c'est pourquoi je cherche à utiliser git total avec juste une passerelle ... si ça existe.
Par contre, en passant, y-a-t-il eu des problèmes lors de l'utilisation de git-svn (sur 18 mois je pense que oui) ?
En fait j'ai pas de cahier des charges précis.
Le vrai besoin est de simplifier les branches (qu'on me parle pas de svk) pour que ce soit utilisé le plus possible (l'usage des branches répond à beaucoup de problèmes qu'on rencontre)
Donc je me suis penché sur git-svn (pour le moment je trouve ça très bien) mais si je peux passer direct en git ça ne serait que mieux, histoire de ne pas passer sur git-svn maintenant pour certains, et dans 2 mois de passer sur git. Surtout que le svn commence seulement à ressembler à quelque chose (personne s'en occupait, ça commitait n'importe comment, pas de log, pas de tags, pas de branche - ni même de dossier trunk - ...)
Mais mon problème est dans l'usage d'un tel outil par des personnes qui ... s'en foutent en quelque sorte, à qui ça n'apportera peut-être pas grand chose.
Maintenant, si c'est pas possible, si ça fait perdre trop d'informations, etc ... forcément ça devient problématique.
L'histoire de passer l'historique à plat entre autre...
Question subsidiaire : existe-t-il toujours des branches svn / autre de linux ? qqn sait comment elles sont faites / maintenues ?
j'sais pas moi, genre la question qu'on te pose lorsque tu crée un journal quoi...
après l'affichage c'est un autre problème...
(en plus t'as un compte suffisamment vieux pour connaître ça, non ?)
je suis en train de regarder cette vidéo
Cette vidéo est beaucoup beaucoup plus intéressante que je ne le pensais, même si on ne veut pas utiliser git. Je pense que quiconque réfléchissant un peu aux outils à utiliser pour faire du dev peuvent / devraient la regarder (bon après c'est du grand Torvalds hein, faut aimer ;) )
Sinon, pour le merge en svn, soit je ne suis pas allé assez loin, soit j'ai mal compris, soit pour moi c'était sur cvs :)
Il y a quand même eu des améliorations dans svn 1.5 mais c'est toujours pas au niveau attendu je trouve - enfin ça dépend de ce qu'on veut en faire...
note en passant : m'attendant évidemment à une telle remarque (c'est comme l'orthaugraffe ça dépend juste des modes) j'ai même passé mon journal en deuxième page pour calmer l'ardeur de certains qui, il faut croire, sont dérangés par lire un journal parlant un peu de technique au milieu des journaux politiques ou réchauffés d'hadopi)
ra mais oui, c'est ça la solution !
ha non, y'a rien non plus, un commentaire vide, j'ai du rêver... ;)
L'info c'est que j'aimerais bien savoir comment se passent les migrations de softs svn -> un vrai truc, comment ça galère, comment gérer des miroirs, et que plein de monde ici utilise ça, et que j'avais envie de donner mon avis sur svn qui n'est pas génial pour certains point et que ....
Par contre tu aurais du lire un peu plus loin l'aide que tu cites, faut pas s'arrêter tout de suite hein ;)
Juste parce que j'ai oublié...
on trouve pas mal de chose pour faire des miroirs git -> svn mais unidirectionnel
Les miroirs svn sont toujours en lecture seule et aucun processus réel de synchronisation existe...
> a) Selon eux, il a ete prouve que les pays avec un systeme de brevet ont un taux d'innovation et recherche plus eleve que les autres, notamment de par le fait que le systeme de brevet force a reveler la methode alors que le secret de fabrication empeche les autres de s'en inspirer pour creer qqe chose de nouveau
C'est bien pour ça que les brevets ont étés créés, à une époque où trop de secrets disparaissaient dans la tombe de leur inventeur.
Le brevet force l'inventeur à publier son invention, dans le cas contraire espionnage industriel ou vol d'idée, la contrepartie du brevet étant évidemment de protéger son invention.
Mais évidemment aucun lien avec l'informatique ;)
> b + c1 + c2
effet "pervers" du système, si t'es pas gros tu galères
> un thème par défaut qui ferait plaisir à tout le monde ça n'existe pas.
ça c'est sur, mais le thème actuel, avec des flammes, des icones en très gros, toussa, quelqu'un l'utilise pour de vrai ?
Franchement j'aimerais bien avoir un vrai dock à la mac, aussi évolué.
J'en ai essayé pas mal, j'ai utilisé pas mal de temps un cairo dock 1.6.3 et j'ai compilé récemment le 2
Mais il n'est pas resté plus d'une demi heure.
Le dialogue de configuration est horrible je trouve (très, trop, gnome / compiz) très dur de retrouver quelque chose dedans et surtout de faire ce qu'on souhaite.
Les thèmes ne m'ont pas emballé du tout, les applets non plus.
Mais si on met tout ça de côté (ça reste de la config) ça ne me va toujours pas.
Ptetre que c'est parce que je suis sous kde, ou que j'ai des softs plus "étrange" (j'utilise principalement firefox / eclipse - 1 ou 2 de lancé très souvent / evolution / plein d'autres trucs répartis sur mes 6 bureaux) mais j'arrive pas du tout à m'y faire.
J'ai souvent des applis qui ne sont pas "liées" au lanceur et rien que pour ça le dock en devient inutile pour moi.
Ce qui me plairait (et c'est je crois ce qui était indiqué avec gnome-do et probablement aussi avec le futur de plasma) c'est _juste_ un bon mélange entre mes lanceurs et mes applications lancées, sans effets (juste un petit overlay) pas de trucs qui tourne, rien à part la possibilité de le mettre dans une barre normale, de coller autour l'heure et la zone de notification et c'est tout.
Ca serait vraiment bien, mais pour le moment rien de ce que j'ai testé n'y arrive vraiment, au niveau effets par exemple c'est bien fait, bien travaillé mais au niveau de la fonctionnalité de base je trouve que ça coince toujours.
ben c'est le problème avec un peu tous les "framework" js...
Il y en a trop, trop qui font la même chose ou presque, et beaucoup (tous ?) sont incompatibles...
En même temps, il viendrait pas l'idée à beaucoup de faire une appli en C++ stl + qt + mfc...
Mais pour js, on arrive quand même à un moment où une amélioration du langage pourrait être intéressante en rendant inutile pas mal de frameworks et où on pourrait enfin faire de bonnes libs utilisables... mais bon faut compter sur ie pour que ça marche pas... (et là on regarde avec envie action script qui se basent sur de l'ecmascript mais de manière plus sympa que le js des navigateurs ... en tout cas plus utilisable)
ben c'est pas parfait le fichier à plat et tu l'indiques même ...
> gestion des accès concurrents
Et pour le coup c'est pas forcément rien... et c'est pas non plus à coup de cp que tu vas le gérer...
et pour l'histoire de versionner la conf ou d'en faire une sauvegarde souvent les autres systèmes ont des procédures de backup...
Non pas que je défende gconf & co mais tu aurais pu trouver mieux comme arguments...
Mais lire du code avec certains mots dans une langue, d'autres dans une autre c'est pas cohérent du tout.
isfile(fichierentree) c'est pas beau ;)
isfile(input) est un peu plus logique comme écriture...
> j'étudie toute contribution
Ben juste comme dit plus haut, code en anglais ;)
C'est juste une habitude assez pratique et surtout le code est plus cohérent, avec un bon et vrai langage ça se lit presque comme si on lisait des phrases.
[^] # Re: Git sous Windows
Posté par CrEv (site web personnel) . En réponse au journal migrations vers de vrai outils de dev.... Évalué à 2.
[^] # Re: Git sous Windows
Posté par CrEv (site web personnel) . En réponse au journal migrations vers de vrai outils de dev.... Évalué à 3.
A priori c'est quand même du niveau de git (du même niveau quoi) mais avec de meilleurs outils pour windows / eclipse (important pour moi)
Du moment que les fonctionnalités sont là ;)
(sous linux uniquement j'utiliserais git)
A priori par contre il existe plusieurs interfaces à svn, contrairement à git
[^] # Re: Les jounrnaux...
Posté par CrEv (site web personnel) . En réponse au journal migrations vers de vrai outils de dev.... Évalué à 2.
Au début il tape sur cvs mais ensuite, au delà du fait que pour lui cvs et svn est quasi identique, il tape aussi sur la gestion (ou non gestion) du merge dans subversion
[^] # Re: Je suis intéressé
Posté par CrEv (site web personnel) . En réponse au journal migrations vers de vrai outils de dev.... Évalué à 2.
Ceci explique cela...
Fais-en un peu plus et tu comprendras ;)
Tiré d'un journal précédent, mais vécu de trop nombreuses fois :
(on peut remplacer tortoise par n'importe quel client svn hein...
(journal : https://linuxfr.org/~NoNo/26146.html )
[^] # Re: Je suis intéressé
Posté par CrEv (site web personnel) . En réponse au journal migrations vers de vrai outils de dev.... Évalué à 6.
Moi ce qui m'intéresse aujourd'hui dans un truc comme git (s'il y a autre chose de mieux ça me gène pas hein ;)) c'est justement pas l'aspect décentralisé (même si c'est pratique) mais l'aspect branches.
Aujourd'hui, je dois me préparer à maintenir un trunk, 2 à 3 branches de maintenance, 1, 2 ou plus ça dépend branches de dev expérimental / choses ne rentrant pas dans le trunk par projet. (c'est du grossier)
avec un truc comme ça et un système comme svn c'est galère.
Alors oui c'est technique, mais ça pue.
Dans certains cas il est interdit à certaines personnes de commiter sur des branches de maintenance. Problème : certaines personnes vont tout de même créer des correctifs mais ne pourront jamais les versionner -> c'est le bordel, les commits ne ressemblent plus à rien, c'est chiant à faire, et s'ils sont pas intégrés rapidement c'est horrible.
Avec un système de branche ... c'est plus facile.
Le côté décentralisé ... ben heu ... c'est pas ce que je recherche, mais ça peu avoir des côtés intéressant, surtout lorsque l'un des développeurs veut se lancer dans une expérimentation sans polluer la branche principale, ni créer de branche distante sur le répo principal.
De puis, pour mon cas, ça reste une utilisation assez professionnelle et dans ce cas c'est pas l'outil qui pose des problèmes de communication, loin de là.
D'ailleurs un tel outil permet dans certains cas de mieux communiquer :
plutôt que de se retrouver un jour avec des commits apparaissant n'importe comment sans avertir les développeurs en charge, on va au contraire apprendre qu'untel a fait des modifs dans sa branche / nous a envoyé des patch et on va les intégrer.
Alors oui, gestion des droits, toussa, mais ça ne répond pas toujours aux règles fines qu'on souhaite.
(je sais pas si je me fais bien comprendre là...)
Un VCS décentralisé ne favorise pas plus le travail individuel, mais il garanti à chacun de pouvoir versionner son taff (très important, surtout quand on voit que certains ne comprenent toujours pas l'intéret...) à chacun de pouvoir améliorer le taff de l'autre, et aux responsables de pouvoir améliorer l'ensemble en prenant facilement les idées de tous.
Ca fait un peu fouilli dit comme ça mais c'est au contraire poser un cadre, des outils pour le réguler facilement.
> Moi, je préfère le travail collectif et donc, je n'utiliserai jamais git à moins d'y être forcé. J'aime bien SVN, il fait ce que je veux, point. Les features qui manquent, elles arriveront un jour, je ne me fait pas de souci.
C'est une erreur je pense, git est simplement un meilleur outil que svn. Il manque beaucoup trop de feature, et le fait d'ajouter des commits locaux ... voui mais tant que le merge ne sera pas utilisable franchement j'en veux pas.
Et les features ... ben c'est aujourd'hui que j'en ai besoin :(
[^] # Re: Les jounrnaux...
Posté par CrEv (site web personnel) . En réponse au journal migrations vers de vrai outils de dev.... Évalué à 3.
pourtant si je vais sur http://linuxfr.org/journal/new.html on me demande bien si je veux le publier en première ou deuxième page... (selon XP :))
[^] # Re: git-svn n'est pas parfait
Posté par CrEv (site web personnel) . En réponse au journal migrations vers de vrai outils de dev.... Évalué à 2.
On est en train d'essayer de faire quelque chose du genre justement (utilisation des branches entre autre)
Par contre c'est vrai que la perte des infos de merge me plait moyen, c'est pourquoi je cherche à utiliser git total avec juste une passerelle ... si ça existe.
Par contre, en passant, y-a-t-il eu des problèmes lors de l'utilisation de git-svn (sur 18 mois je pense que oui) ?
En fait j'ai pas de cahier des charges précis.
Le vrai besoin est de simplifier les branches (qu'on me parle pas de svk) pour que ce soit utilisé le plus possible (l'usage des branches répond à beaucoup de problèmes qu'on rencontre)
Donc je me suis penché sur git-svn (pour le moment je trouve ça très bien) mais si je peux passer direct en git ça ne serait que mieux, histoire de ne pas passer sur git-svn maintenant pour certains, et dans 2 mois de passer sur git. Surtout que le svn commence seulement à ressembler à quelque chose (personne s'en occupait, ça commitait n'importe comment, pas de log, pas de tags, pas de branche - ni même de dossier trunk - ...)
Mais mon problème est dans l'usage d'un tel outil par des personnes qui ... s'en foutent en quelque sorte, à qui ça n'apportera peut-être pas grand chose.
Maintenant, si c'est pas possible, si ça fait perdre trop d'informations, etc ... forcément ça devient problématique.
L'histoire de passer l'historique à plat entre autre...
Question subsidiaire : existe-t-il toujours des branches svn / autre de linux ? qqn sait comment elles sont faites / maintenues ?
[^] # Re: Les jounrnaux...
Posté par CrEv (site web personnel) . En réponse au journal migrations vers de vrai outils de dev.... Évalué à 3.
après l'affichage c'est un autre problème...
(en plus t'as un compte suffisamment vieux pour connaître ça, non ?)
[^] # Re: Les jounrnaux...
Posté par CrEv (site web personnel) . En réponse au journal migrations vers de vrai outils de dev.... Évalué à 2.
Cette vidéo est beaucoup beaucoup plus intéressante que je ne le pensais, même si on ne veut pas utiliser git. Je pense que quiconque réfléchissant un peu aux outils à utiliser pour faire du dev peuvent / devraient la regarder (bon après c'est du grand Torvalds hein, faut aimer ;) )
Sinon, pour le merge en svn, soit je ne suis pas allé assez loin, soit j'ai mal compris, soit pour moi c'était sur cvs :)
Il y a quand même eu des améliorations dans svn 1.5 mais c'est toujours pas au niveau attendu je trouve - enfin ça dépend de ce qu'on veut en faire...
[^] # Re: Les jounrnaux...
Posté par CrEv (site web personnel) . En réponse au journal migrations vers de vrai outils de dev.... Évalué à 7.
[^] # Re: Les jounrnaux...
Posté par CrEv (site web personnel) . En réponse au journal migrations vers de vrai outils de dev.... Évalué à 7.
ha non, y'a rien non plus, un commentaire vide, j'ai du rêver... ;)
L'info c'est que j'aimerais bien savoir comment se passent les migrations de softs svn -> un vrai truc, comment ça galère, comment gérer des miroirs, et que plein de monde ici utilise ça, et que j'avais envie de donner mon avis sur svn qui n'est pas génial pour certains point et que ....
Par contre tu aurais du lire un peu plus loin l'aide que tu cites, faut pas s'arrêter tout de suite hein ;)
# oublis
Posté par CrEv (site web personnel) . En réponse au journal migrations vers de vrai outils de dev.... Évalué à 3.
on trouve pas mal de chose pour faire des miroirs git -> svn mais unidirectionnel
Les miroirs svn sont toujours en lecture seule et aucun processus réel de synchronisation existe...
Par contre si quelqu'un connait un tel soft :)
[^] # Re: mandriva mini
Posté par CrEv (site web personnel) . En réponse à la dépêche Test de la Mandriva 2009.1. Évalué à 3.
si encore c'était dans la signature...
[^] # Re: miam
Posté par CrEv (site web personnel) . En réponse au journal Discussion interessante dans un bar. Évalué à 5.
# spa faux
Posté par CrEv (site web personnel) . En réponse au journal Discussion interessante dans un bar. Évalué à 3.
C'est bien pour ça que les brevets ont étés créés, à une époque où trop de secrets disparaissaient dans la tombe de leur inventeur.
Le brevet force l'inventeur à publier son invention, dans le cas contraire espionnage industriel ou vol d'idée, la contrepartie du brevet étant évidemment de protéger son invention.
Mais évidemment aucun lien avec l'informatique ;)
> b + c1 + c2
effet "pervers" du système, si t'es pas gros tu galères
[^] # Re: Linux ne sera jamais prêt
Posté par CrEv (site web personnel) . En réponse au journal pourquoi Linux n'est pas (encore) prêt pour le bureau. Évalué à 10.
♜♞♝♛♚♝♞♜ ♟♟♟♟♟♟♟♟ ♙ ♙♙♙♙ ♙♙♙ ♖♘♗♕♔♗♘♖[^] # Re: Soucis à la pelle
Posté par CrEv (site web personnel) . En réponse à la dépêche Mandriva Linux 2009.1 Spring est disponible. Évalué à 1.
Ben vu que et à moins que tu ais des morceaux de kde4.2 dans xfce ... je pense pas...
> les drivers nvidia qui ont évolué ?
heu, le rapport entre des drivers d'écran et la souris ?
Ok c'est X qui gère les 2, mais ça reste des drivers différents non ?
[^] # Re: Less is more
Posté par CrEv (site web personnel) . En réponse à la dépêche Sortie de Cairo-Dock 2.0.0. Évalué à 1.
ça c'est sur, mais le thème actuel, avec des flammes, des icones en très gros, toussa, quelqu'un l'utilise pour de vrai ?
Franchement j'aimerais bien avoir un vrai dock à la mac, aussi évolué.
J'en ai essayé pas mal, j'ai utilisé pas mal de temps un cairo dock 1.6.3 et j'ai compilé récemment le 2
Mais il n'est pas resté plus d'une demi heure.
Le dialogue de configuration est horrible je trouve (très, trop, gnome / compiz) très dur de retrouver quelque chose dedans et surtout de faire ce qu'on souhaite.
Les thèmes ne m'ont pas emballé du tout, les applets non plus.
Mais si on met tout ça de côté (ça reste de la config) ça ne me va toujours pas.
Ptetre que c'est parce que je suis sous kde, ou que j'ai des softs plus "étrange" (j'utilise principalement firefox / eclipse - 1 ou 2 de lancé très souvent / evolution / plein d'autres trucs répartis sur mes 6 bureaux) mais j'arrive pas du tout à m'y faire.
J'ai souvent des applis qui ne sont pas "liées" au lanceur et rien que pour ça le dock en devient inutile pour moi.
Ce qui me plairait (et c'est je crois ce qui était indiqué avec gnome-do et probablement aussi avec le futur de plasma) c'est _juste_ un bon mélange entre mes lanceurs et mes applications lancées, sans effets (juste un petit overlay) pas de trucs qui tourne, rien à part la possibilité de le mettre dans une barre normale, de coller autour l'heure et la zone de notification et c'est tout.
Ca serait vraiment bien, mais pour le moment rien de ce que j'ai testé n'y arrive vraiment, au niveau effets par exemple c'est bien fait, bien travaillé mais au niveau de la fonctionnalité de base je trouve que ça coince toujours.
ps : oui je sais yaka focon ...
[^] # Re: concernant le Javascript
Posté par CrEv (site web personnel) . En réponse à la dépêche Veille technologique sur le web. Évalué à 4.
Il y en a trop, trop qui font la même chose ou presque, et beaucoup (tous ?) sont incompatibles...
En même temps, il viendrait pas l'idée à beaucoup de faire une appli en C++ stl + qt + mfc...
Mais pour js, on arrive quand même à un moment où une amélioration du langage pourrait être intéressante en rendant inutile pas mal de frameworks et où on pourrait enfin faire de bonnes libs utilisables... mais bon faut compter sur ie pour que ça marche pas... (et là on regarde avec envie action script qui se basent sur de l'ecmascript mais de manière plus sympa que le js des navigateurs ... en tout cas plus utilisable)
[^] # Re: But?
Posté par CrEv (site web personnel) . En réponse à la dépêche Sortie de ReactOS 0.3.9. Évalué à 1.
[^] # Re: But?
Posté par CrEv (site web personnel) . En réponse à la dépêche Sortie de ReactOS 0.3.9. Évalué à 3.
> gestion des accès concurrents
Et pour le coup c'est pas forcément rien... et c'est pas non plus à coup de cp que tu vas le gérer...
et pour l'histoire de versionner la conf ou d'en faire une sauvegarde souvent les autres systèmes ont des procédures de backup...
Non pas que je défende gconf & co mais tu aurais pu trouver mieux comme arguments...
[^] # Re: Le point de vue du vieux geek
Posté par CrEv (site web personnel) . En réponse à la dépêche E17 est annoncé.. Évalué à 3.
http://www.kde.org/screenshots/images/large/kde2final_1.jpg
http://www.linuxplanet.com/graphics/screenshots/RpmDrake.png
Bon par contre, j'ai pas retrouvé (pas cherché beaucoup non plus) de screenshot gnome)
C'est ptetre pas hyper sexy mais quand même plus sympa que les trois premiers liens je trouve...
[^] # Re: Bad design
Posté par CrEv (site web personnel) . En réponse à la dépêche Bélier 0.6 : Outil d'automatisation de connexions ssh complexes. Évalué à 2.
Mais lire du code avec certains mots dans une langue, d'autres dans une autre c'est pas cohérent du tout.
isfile(fichierentree) c'est pas beau ;)
isfile(input) est un peu plus logique comme écriture...
> j'étudie toute contribution
Ben juste comme dit plus haut, code en anglais ;)
C'est juste une habitude assez pratique et surtout le code est plus cohérent, avec un bon et vrai langage ça se lit presque comme si on lisait des phrases.
[^] # Re: Bad design
Posté par CrEv (site web personnel) . En réponse à la dépêche Bélier 0.6 : Outil d'automatisation de connexions ssh complexes. Évalué à 6.
En même temps, si on lit le code on a des trucs comme :
if self.options[0].nomfichier is not Noneelif not isfile(fichierentree):Et là, c'est ni beau ni élégant, ni clair, qu'on le regarde en français ou en anglais
[^] # Re: Login me manque...
Posté par CrEv (site web personnel) . En réponse au journal Explorez les richesses du langage Python. Évalué à 4.
C'est pas parce que c'est python que c'est le premier numéro du genre hein ...
Il y a eu, il n'y a pas si longtemps, un HS sur ruby par exemple
Ok, en fait c'était en novembre/décembre 2007 : http://www.ed-diamond.com/produit.php?produit=512
Et avant il y avait déjà eu un hors série sur php5 en septembre/octobre 2004 : http://www.ed-diamond.com/produit.php?produit=367