CrEv a écrit 4577 commentaires

Oui ton exemple est lisible. Mais ça se lit quand même comme deux conditions séparées par un 'et' là où l'autre solution se lit immédiatement comme un intervalle (et c'est juste mieux, sans être transcendant évidemment)
Par contre, il y a un cas tordu : celui où la ligne est quand même plus grande, où le code est en prod, où il faut corriger à la vas vite un problème : et dans ce cas, parfois, l'une des deux variables seulement sera changée. Dans l'autre cas (intervalle) c'est pas possible. Alors oui, on va me dire que c'est pas vrai, que c'est parce que le dev est mauvais, etc. Oui. Mais la réalité c'est que ce genre de cas existe. Et qu'il y a un tas de choses bonnes à prendre pour éviter ce genre de problème.

Les mots clefs pour les conditions négatives […] ça apporte à peut près rien et ça permet d'écrire des conditions négative dans dans une condition négative et ça c'est bien moins lisible.

Déjà sur la fin : et alors ? On devrait refuser car il peut y avoir un mauvais usage, c'est ça ? Des mauvais usages il y en a tout le temps, et c'est pas l'ajout de unless qui va empêcher les mauvaises écritures, ni les favoriser.

entre

display if !empty

ou

display unless empty

mon choix est vite fait, je préfère la deuxième solution. Et comme pour le premier problème, si je peux virer le ! c'est parfois préférable. Il m'est arrivé de voir des codes qui ne fonctionnaient pas, les développeurs ont cherché pendant pas mal d'heures, pour finalement, bien après, se rendre compte que c'était juste à cause du !. Alors idem, on va dire que c'est pas possible, que c'est des mauvais dev. Mais quoi qu'il en soit ce cas arrive. L'ajout de unless permet de gagner beaucoup en expressivité et est moins source d'erreur. Evidemment celui qui écrit unless !condition là il faut probablement le fouetter…

Mais évidemment là c'est des cas simples.

En js j'écris souvent :

if (!('id' in plop)) {
  // ...
}

et ce serait beaucoup mieux, plus lisible et moins source d'erreur d'avoir :

unless 'id' in plop
  # ...

Après, parfois j'ai quand même l'impression que certains (je ne te vises pas forcément hein ;) ) sont tellement habitués à avoir des langages pauvres (et ne parlons même pas de java…) que le moindre ajout d'expressivité est mal perçu. Et c'est vraiment dommage.

Ha non, je m’insurge !!

Un cédérom !

Et pour bouquiner tranquillement, une bédé.

Bon, sur-ce je retourne coder, ça pique moins les yeux…

Si tu es heureux avec git

pour le moment ça va

toujours connecté

pas forcément, mais pas besoin d'être toujours connecté avec un DCVS quelconque…

tu fais appel à pleins de services hébergés

pas forcément non plus

Pour les branches, ce que je veux dire c'est qu'il existe pas mal de façons de faire. Les branches de git et mercurial par exemple ne sont pas identiques. Si je ne me trompe dans git une branche n'est qu'un pointeur vers un commit (en gros hein) alors que sous mercurial une branche est une méta donnée d'un commit.
Et dans les faits ça change pas mal de choses, dans les deux cas en bien et en mal en fait…
Avec mercurial il est super simple par exemple d'avoir des branches anonymes (donc sans nom) juste pour corriger un truc. Il suffit de revenir à un commit antérieur, et de faire un nouveau commit. Et hop, on récupère un nouvel head sur la branche. On peut alors le fusionner et c'est ok.
Evidemment on peut faire un équivalent en git tout de même (et inversement pour les spécificités de git, même si c'est pas toujours évident).

Prenez des gens qui font du git et collez les sous mercurial, vous verrez leur tête lorsqu'ils faudra utiliser les branches…

D'où ma question, surtout pour ceux qui auraient utiliser les 2 (ou plus).

Ce qui est intéressant, c'est que la documentation, le bug tracking ainsi que le site web et même la configuration du dépôt peuvent être versionnés.

Ca part contre c'est un bon point, il est vrai.

fossil est ce dont tu n'as même pas osé rêver.

Heu, comment dire…
C'est probablement pas mal, mais ça ne me tente absolument pas.
Ce que je cherche c'est plutôt quelque chose pour faciliter git et les opérations annexes (par exemple code review, ce dont fossil ne s'occupe pas).

Il y a plein de raisons pour lesquelles je souhaite utiliser git et pas autre chose, et l'une d'elle est que de la sorte je suis compatible avec plein d'outils, plateformes, etc. Il devient hyper simple de créer un miroir ailleurs par exemple. Je vais très facilement trouver un connecteur pour un soft d'intégration continue, etc.

Fossil ça me semble bien pour… heu… oué bon juste pour faire un petit truc dans un coin. Mais ça ne me donne que moyennement confiance (probablement à tord) et super pas envie en fait…

Et le côté exécutable de 1Mo, argument souvent annoncé, est vraiment pas un critère pour moi pour le coup. Le côté j'ai pleins d'outils qui bouffent du git est beaucoup plus pertinent

Et d'ailleurs, pour savoir, comment il se comporte en distribué ? Branches, anonymes ou non, publiées sur le serveur ou non, facilité à revenir en arrière, etc ? Et qu'on ne dise pas comme tous les DCVS car vu les différences (y compris côté simplement utilisation agréable ou non) entre git, bzr et mercurial il y a forcément des différences à fossil

Bof du sucre syntaxique sans grand intéret

Du sucre syntaxique oui, absolument.
Sans grand intérêt je ne suis pas d'accord.
L'intérêt peut être (si utilisé à bon escient) une meilleure lisibilité et une compréhension plus facile du code.

if (score > 10 && score < 100) {
  displayGreenBadge();
}

displayGreeBadge if 10 < score < 100

est, je trouve, plus sympa, plus lisible et plus compréhensible.
Evidemment ça ne change pas grand chose au final. Mais une plus grande lisibilité c'est aussi moins de risques d'erreur, une maintenance plus facile, moins de risques de régressions, etc.

C'est comme le fait d'avoir des conditions inversées (écrire plop() if (...) plutôt que if (...) { plop(); } ou avoir des mots clés pour les conditions négatives (unless)

A priori elles sont aussi dispo en https
Je vais voir si je peux les charger en relatives (sans http/https, comme c'est fait d'ailleurs pour les css embarquées de linuxfr, voir la news) et dans ce cas ça devrait aller

ok. Le truc c'est que tu dois probablement refuser les polices externes. Et donc tu utilises les polices de bases, qui n'ont pas la même taille.
Si tu débloque les polices ça devrait être mieux. Et sinon je verrai pour rajouter un peu plus d'espace si c'est possible.

J'y avais pensé, mais le truc c'est que je trouve qu'elles sont pas très belles en fait… et surtout hyper classiques car quasi clone de Arial. Et je voulais quelque chose d'un peu plus "sympa". Mais je garde tout de même l'idée sous le coude.

Pour le style de code, j'ai noté ce sera corrigé.

Pour ce qui est de la séparation de la barre d'outil, je vais la changer. Mais pour ce qui est de la repérer, en fait le truc le plus simple c'est quelle est toujours au même endroit ;)

Pour le titre trop long, tu aurais une capture ?
Car chez moi ça donne ça :

Ha oué, alors ça…
En fait le tableau est trop large pour la place que je lui alloue. Donc j'ai préféré dégrader certains titres (ou même directement certaines colonnes dans le suivi par exemple) pour réduire l'espace des colonnes et garder les titres lisibles.
Mais je viens de penser qu'il faut que j'essaie avec une rotation des libellés, peut-être que ça peut suffire (soit une rotation, type 45° de tous les titres, soit une écriture verticale). A voir

Ben de rien, moi ça me fait plaisir de la faire et plaisir de la voir utilisée. Et surtout la CSS est là où elle en est justement par vos retours et critiques, ce qui permet de confronter les points de vue et de l'améliorer.
Elle est déjà bien plus fournie et va bien plus loin que ce que je pensais initialement, et c'est pas encore fini :)

Sympa :)
Je vais tester, même si je pense qu'elle est un peu trop grasse. Mais ça se tente, et je rajouterai un screenshot pour que vous voyez ce que ça donne.

Ha ok. Pourtant moi je la trouve pas mal, avec un W sympa. Et j'aime bien le côté police assez grande mais hauteur d'x assez faible.

Numans j'aime pas trop pour les titre, trop rond et pas assez dense entre autre.
Mais par contre aucun problème si tu as des suggestions :)

ha oué l'a tu es quand même vraiment dur… comic sans ms…

plus sérieusement de quelle police parles-tu ? celle du corps des messages ? si oui c'est entre autre l'une qui était choisie dans les commentaires dans le précédent journal. dur de contenter tout le monde…

par contre rien n'empêche que la police soit différente dans la prochaine version,il suffit de m'en indiquer une autre ;) j'ai pas beaucoup de critères, juste que le corps soit assez léger pour avoir une police en 14px qui ne fasse pas grasse, pas trop sombre. donc si certains ont des suggestions je suis ok

Heu… comment dire…
Tu es sur d'utiliser les bonnes urls ?
Car le logo est cliquable et les liens en haut ont étés espacés.

Pour les urls (il est vrai que j'aurais du les rappeler dans le journal) :

• fond clair, code clair : http://ybr.phpnet.org/linuxfr/light_light_code.css
• fond clair, code sombre : http://ybr.phpnet.org/linuxfr/light_dark_code.css
• fond sombre, code sombre : http://ybr.phpnet.org/linuxfr/dark_dark_code.css
• fond sombre, code clair : http://ybr.phpnet.org/linuxfr/dark_light_code.css

Sinon, ben cool ça fait plaisir de voir les gens l'utiliser (même si je l'ai faite en priorité pour moi ;) )

Bon, je viens de passer la version 2 (je n'ai pas refais les screenshots pour le moment)

Vous devriez donc voir un certain nombre de changements.

Si jamais ça ne convient pas (entre autre la police à changé) dites le moi ici ou sur github.

Et si vous voulez certaines choses pour la suivante, dites le (ici ou sur github) sachant que je vais déjà m'occuper du côté "responsive"

Ha oui, c'est vrai, les titres sont verticaux sur la feuille de base.
Je vais regarder (en même temps que pour le nom de l'utilisateur) si je peux trouver un style simple pour le faire un peu autrement.

Pour le "revenir en haut de page" je vais essayer autrement : l'intégrer (visuellement au moins) dans la toolbar pour l'avoir en permanence accessible. Mais ce sera pour la prochaine version (avec les histoires de design étroits, larges, etc)

Hum, je dirais que c'est plutôt à indiquer ici ;-)

Je verrai pour voir les boutons < > alors.
Par contre ça arrivera un peu plus tard, je pense que je vais revoir la CSS pour avoir réellement plusieurs affichages : mode mobile portrait, mobile paysage, faible largeur, largeur normale et wide

Mais ça fait quand même du boulot, donc ce sera pas dans la prochaine release

OK, merci de ces retours.

J'ai donc fait un petit mix pour le moment :

• numans pour le corps
• Josefin Sans pour les titres
• Josefin Slab pour les titres dans les contenus (par ex sommaires) car Josefin Sans s'affiche alors plutôt mal (par contre c'est une police Serif, mais je trouve que ça passe quand même)

J'ai aussi viré certaines bordures pour alléger un peu le style.

Le tout devrait être dispo demain au plus tard (si tout se passe bien comme prévu ;-) )

Ha oui, à noter que sous chrome windows l'affichage est plutôt crade (pas d'anti aliasing) alors que sous firefox, firefox linux c'est beaucoup mieux

Vraiment cool toutes ces nouveautés !

Entre autre l'ajout de la balise de viewport est vraiment bien pour les mobiles.

<meta content="width=device-width" name="viewport">

Si je ne me trompe, le fait d'héberger les CSS devraient permettre de servir ces CSS en https, non ? Dans ce cas, fini les navigateurs qui râlent si on navigue en https et que la css perso est en http !

Merci pour ces améliorations !

Je reviens sur l'histoire de la police.
J'ai fais quelques tests, à vous me de dire ce qu'il vous semble intéressant comme police (bon c'est pas dit que je reteste pas d'autres polices, mais en voici déjà quelques unes :)

• josefin
• advant
• numans
• century gothic, celle de base

J'oubliais, il y a aussi quicksand qui me plait pas mal mais j'ai un problème de capture d'écran étrange avec… mais à évaluer aussi

…(javascript)…

Arg, c’est moins intéressant tout d’un coup

Hum, pour quelle réelle raison ?

s'étonnant que sur Zino j'ai pu dire une annerie

1. C'est bien plus qu'une ânerie
2. C'est pas spécifique à zin[od]
3. Franchement, vas-t-en. Arrête tes délires. Lorsqu'on voit que certains accordaient plus de crédit à Jayce qu'à toi ça devrait te faire comprendre qu'il faut vraiment que tu arrêtes car là t'est tombé bien bas. En fait même comme divertissement tu deviens trop lourd.

// De rien, CrEv. C'est cadeau :)

Oué ben tu peux repartir avec, je m'en serais vraiment bien passé de tout ton discours incohérent et surtout inutile