Sommaire
Introduction
Un numéro de zappé, mais c'était pour la bonne cause : ma css linuxfr-solarized. Finalement ça prend plus de temps que prévu, donc moins de liens collectés. Et faut dire aussi que j'ai l'impression que pas mal de monde a commencé les vacances, donc beaucoup moins d'activité. Donc toute petite revue cette fois-ci, mais revue quand même.
Un peu de contenu
Développement
On commence directement avec du développement web. L'une des questions qui revient toujours est de savoir quelles sont les fonctionnalités supportées et disponibles pour un navigateur. Ce site, haz.io, ne vous renseignera pas sur le support pour l'ensemble des navigateurs, mais mettra en évidence ce que votre navigateur supporte. Et pour quasiment chaque fonctionnalité un lien vers les specs (ou draft) du W3C est réalisé, est ça c'est bien.
Toujours côté web, la fonction css calc()
est désormais non préfixée. Enfin presque, c'est pour firefox 16. C'est une très bonne chose, c'est réellement une fonctionnalité intéressante pour le design web. Voici le bug chez mozilla. Cette fonctionnaltié existe aussi dans IE9, ce qui permet de l'utiliser (en rajoutant les bons préfixes) sur tout navigateur récent, IE >= 9, firefox et webkit.
Pour continuer les précédents numéro, un peu de coffeescript : j'ai découvert qu'on pouvait chainer les comparaisons :
Au lieu d'écrire ça
value < 100 && value > 50
on écrit simplement
100 > value > 50
Mais pourquoi les autres langages n'ont pas ça ?
Une petite astuce toute simple pour ceux qui débutent avec git et qui ont peur des merges. En gros c'est l'utilisation des branches comme bookmark (pour une fois que je peux employer un terme hg
en parlant de git
;-) ) pour pouvoir avoir un point de restauration si on se plante.
Je remonte également un lien trouvé dans un commentaire de nono sur les EBook : une lib javascript pour afficher des maths dans une page web. Entre autre chose une utilisation importante des polices de caractères, ce qui permet au rendu de suivre les zooms. Et ça c'est vraiment bien, bien mieux que n'importe quel plugin, mieux qu'une image, et même mieux qu'une image vectorielle finalement (ne serait-ce que parce que c'est toujours du texte). A avoir sous le coude si vous devez inclure des maths dans de l'html. (d'ailleurs tout ça me fait penser que maintenant que je vais bosser dans les ebooks faudrait peut-être que je me mette à lire les specs…)
Comme vous l'avez probablement remarqué, je suis toujours en quête d'un bon outil pour gérer mes sources, mes bugs, mes code reviews, etc. Cette fois-ci je vous propose phabricator. Phabricator regroupe tout ça et même plus. C'est à la base un projet de facebook et ça me semble plutôt pas mal. Je suis justement en cours d'installation.
Actuellement j'utilise github, j'ai aussi des repositories sur baregit. J'ai aussi une instance de gitorious mais je n'en suis pas totalement satisfait (il manque pas mal de choses, même si le côté hébergement de source fonctionne plutôt bien). J'aimerais en fait pouvoir avoir une instance chez moi d'un équivalent (fonctionnel) à github et simplement avoir des miroirs des sources (pour alléger ma bande passante si certains veulent faire un clone).
Dans la liste des versions à tester, j'ai également gitlab qui vient de passer en version 2.7 avec pas mal de nouveautés.
Misc
Si vous êtes sous gnome, vous apprécierez peut-être ce client mail : Geary. Pour ma part je ne l'ai pas testé, mais il me semble plutôt sympa, au moins pour du mail "perso".
Vous aussi vous avez un site web ? Vous aussi vous stockez des mots de passe ? Alors ne faites simplement pas comme Tesco. Voici un article très intéressant vous rappelant plusieurs règles de sécurité à adopter, en prenant comme contre exemple Tesco. Faut dire qu'ils l'avaient un peu cherché en twittant :
Passwords are stored in a secure way. They're only copied into plain text when pasted automatically into a password reminder mail.
Qu'est ce qui motive les gens ? Les récompenses ? Leur donner le choix ? Les forcer ? Les autonomiser ? Voici un Ted talk plutôt connu dans lequel Dan Pink tente d'apporter quelques réponses : The surprinsing science of motivation. Et pour ceux qui ne le savent pas, le lecteur est plutôt bien fait avec entre autres de nombreuses transcriptions et traductions, liées à la vidéo.
Graphisme & co
Un lien sympa (parmi plein d'autres) pour savoir faire des formes en css.
Liste des liens présentés
Développement
haz.io : http://haz.io
bug mozilla calc() : https://bugzilla.mozilla.org/show_bug.cgi?id=771678
calc dans IE9 http://msdn.microsoft.com/en-us/library/ms537660(v=vs.85).aspx#calc
Chaîner les comparaisons en coffeescript : http://coffeescript.org/#comparisons
Petite astuce pour git : http://sametmax.com/une-astuce-pour-ne-plus-avoir-peur-des-merges-avec-git/
lib javascript pour afficher des maths : http://www.mathjax.org/
phabricator : http://phabricator.org/
baregit : http://baregit.com/
gitorious : http://gitorious.org/
Misc
Geary : http://yorba.org/geary/
règles de sécurité et contre exemple Tesco : http://www.troyhunt.com/2012/07/lessons-in-website-security-anti.html
The surprinsing science of motivation : http://www.ted.com/talks/dan_pink_on_motivation.html
Graphisme & co
- formes en css : http://css-tricks.com/examples/ShapesOfCSS/
# clojure
Posté par lendemain . Évalué à 5.
Je viens de tester:
Tu ne me l'aurais pas montré ça ne m'aurai jamais venu à l'esprit.
[^] # Re: clojure
Posté par djabal . Évalué à 4.
Ça existe aussi en python :
[^] # Re: clojure
Posté par calandoa . Évalué à 1.
Ça marche aussi en C :
(
exit(0);
)[^] # Re: clojure
Posté par Shuba . Évalué à 2. Dernière modification le 31 juillet 2012 à 15:46.
Ou pas:
De manière générale, l'opérateur < renvoie 0 ou 1, et c'est cette valeur qui est utilisée pour la comparaison suivante…
[^] # Re: clojure
Posté par calandoa . Évalué à 2.
Ah, ok merci… mais je crois que de toute façons, mon compilateur est cassé :
[^] # Re: clojure
Posté par Bruno Michel (site web personnel) . Évalué à 1.
Non, ça semble correct.
Par contre, je pense que la ligne
b <-- a;
n'est pas ce que tu voulais faire. Elle s'interprète commeb < (--a);
, du coup la valeur de a passe de 5 à 4 et b qui n'était pas initialisé peut avoir n'importe quelle valeur.[^] # Re: clojure
Posté par Thomas Douillard . Évalué à 5.
Sans vouloir m'avancer je pense qu'on n'écrit pas un programme comme ça purement par hasard ;)
[^] # Re: clojure
Posté par Gui13 (site web personnel) . Évalué à 2.
Troll?
[^] # Re: clojure
Posté par calandoa . Évalué à 2.
Pas du tout, je cherche des gens à inviter à diner jeudi soir.
Et qu'on ne m'accuse pas d'être ambigu, le (
exit(0);
) était quand même explicite.[^] # Re: clojure
Posté par Bruno Michel (site web personnel) . Évalué à 5.
Non, ça ne marche pas en C. Exemple :
En fait,
1 < 2 < 3
va être interprété comme(1 < 2) < 3
.1 < 2
est vrai et renvoie donc1
et1 < 3
est également vrai.Par contre, pour
-3 < -2 < -1
,-3 < -2
est aussi vrai, mais1 < -1
est faux.# Gestion de sources et +, beaucoup plus, et léger, très léger !
Posté par Guillaume D. . Évalué à 4.
Ne cherche plus : fossil est ce dont tu n'as même pas osé rêver.
page principale : http://www.fossil-scm.org
fonctionnalités en + gestion des sources : http://www.fossil-scm.org/xfer/doc/trunk/www/index.wiki
le tout dans un exécutable de moins d'1Mo, installable sur un serveur web, ou seul( il possede son propre serveur !)
[^] # Re: Gestion de sources et +, beaucoup plus, et léger, très léger !
Posté par CrEv (site web personnel) . Évalué à 5.
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
[^] # Re: Gestion de sources et +, beaucoup plus, et léger, très léger !
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Si tu es heureux avec git, toujours connecté et que tu fais appel à pleins de services hébergés, fossil ne te plaira pas.
fossil est simple et c'est sa principale force. Avec git, je me retrouve souvent à passer plus de temps sur la gestion de version que sur mon code…
Oui il y a des branches (je ne sais pas ce qu'anonyme veut dire par contre), on peut revenir en arrière, fusionner facilement.
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.
Le seul truc qui manque vraiment pour moi, c'est les pull requests.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Gestion de sources et +, beaucoup plus, et léger, très léger !
Posté par CrEv (site web personnel) . Évalué à 3.
pour le moment ça va
pas forcément, mais pas besoin d'être toujours connecté avec un DCVS quelconque…
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).
Ca part contre c'est un bon point, il est vrai.
[^] # Re: Gestion de sources et +, beaucoup plus, et léger, très léger !
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Oui pour les sources, mais du fait de son intégration, avec fossil tu as aussi accès au bug tracking et au wiki offline.
Je crois que l'équivalent avec fossil, c'est les branches privées.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Gestion de sources et +, beaucoup plus, et léger, très léger !
Posté par Jux (site web personnel) . Évalué à 3. Dernière modification le 31 juillet 2012 à 16:37.
Tu peux tout à fait faire un répertoire "wiki" et un répertoire "bugs" dans ton projet git et stocker ton wiki et ton bug tracking dedans.
Par exemple, ditz et gollum permettent d'avoir respectivement une gestion des bugs et un wiki offline et de synchroniser tout ça avec git :
https://github.com/github/gollum/
http://ditz.rubyforge.org/
Après c'est une question de goûts et de couleurs entre le tout en un ou pas.
[^] # Re: Gestion de sources et +, beaucoup plus, et léger, très léger !
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Pour moi, c'est surtout une question de temps.
fossil ça marche hors de la boite. Tu peux obtenir beaucoup mieux sur la base de git, mais tu dois bien évaluer le risque de passer plus de temps à tout configurer ton environnement de travail qu'à coder.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Gestion de sources et +, beaucoup plus, et léger, très léger !
Posté par Mildred (site web personnel) . Évalué à 1.
Dans le temps, j'étais fan de mercurial et de sa gestion des branches. Depuis je suis fan de git et de sa version des branches. Et je n'apprécie plus autant mercurial.
Mais au final, ça ne change pas grand chose. Avec git, pas besoin de branches anonymes. Tu peux créer une branche nommée "tmp" et c'est strictement équivalent tant que tu ne push pas tmp sur le dépôt partagé.
# Bof du sucre syntaxique sans grand intéret
Posté par reno . Évalué à 3.
Il y a d'autres langages qui ont ça, mais bon ne me demande pas lesquels ce n'est une fonctionnalité que je retiens (pas grand intérêt)..
Par contre un langage avec un comportement sain des entiers (exception de dépassement ou big Int) ça c'est intéressant (mais pas si fréquent que ça malheureusement) coffeescript étant une surcouche de javascript ne l'a pas d'ailleurs.
[^] # Re: Bof du sucre syntaxique sans grand intéret
Posté par CrEv (site web personnel) . Évalué à 4.
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.
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 queif (...) { plop(); }
ou avoir des mots clés pour les conditions négatives (unless
)[^] # Re: Bof du sucre syntaxique sans grand intéret
Posté par barmic . Évalué à 3.
Tout les langages permettent d'écrire :
Je trouve ça lisible. Les mots clefs pour les conditions négatives je suis pas sûr que ce soit une bonne idée, parce que ç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.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Bof du sucre syntaxique sans grand intéret
Posté par CrEv (site web personnel) . Évalué à 2.
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.
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
ou
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 deunless
permet de gagner beaucoup en expressivité et est moins source d'erreur. Evidemment celui qui écritunless !condition
là il faut probablement le fouetter…Mais évidemment là c'est des cas simples.
En js j'écris souvent :
et ce serait beaucoup mieux, plus lisible et moins source d'erreur d'avoir :
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.
[^] # Re: Bof du sucre syntaxique sans grand intéret
Posté par GuieA_7 (site web personnel) . Évalué à 2.
En python on pourra certes l'écrire comme ça :
mais aussi comme ça :
qui me semble assez proche de ton envie d'expressivité, et sans ajouter de mot clé.
[^] # Re: Bof du sucre syntaxique sans grand intéret
Posté par CrEv (site web personnel) . Évalué à 2.
Et si la condition est plus importante tu te retrouves avec
if not bla bla bla bla
ce qui non ne change rien à!
.En fait j'arrive pas à comprendre ce qui dérange vraiment certains dans le fait d'avoir plus de mots clés dans le langage…
[^] # Re: Bof du sucre syntaxique sans grand intéret
Posté par GuieA_7 (site web personnel) . Évalué à 2.
Je n'ai jamais dit que ça me dérangeait d'ajouter des mots clés ; j'ai juste dit qu'en Python il y avait une alternative sympa à
if !('id' in plop)
, et qui ne nécessite pas de mots clés supplémentaire ; c'est tout.[^] # Re: Bof du sucre syntaxique sans grand intéret
Posté par barmic . Évalué à 3.
C'est pas que ça me dérange. C'est qu'unless me semble peut important.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Bof du sucre syntaxique sans grand intéret
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 2.
Peut-être est-ce une mauvaise idée mais j'utilise régulièrement
J'utilise unless lorsque le cas général est que le code conditionnel doive s'exécuter, et if lorsque le cas général est que le code conditionnel ne doive pas s'exécuter. Dit autrement, unless signifie pour moi « fais cela, sauf si exception », et if signifie « fais cela, seulement si exception ».
Du coup j'ai souvent des unless not, unless, if et if not en fonction de la sémantique du code et de la condition.
[^] # Re: Bof du sucre syntaxique sans grand intéret
Posté par rewind (Mastodon) . Évalué à 5.
En C:
Et hop !
[^] # Re: Bof du sucre syntaxique sans grand intéret
Posté par barmic . Évalué à 3.
Ce n'est pas ce que j'ai dis. J'ai dis que le gain est minime et le risque important.
Je ne suis pas convaincu que unless aide. Il sera toujours possible d'écrire :
Ce genre de chose est une plaie.
Justement je pense qu'il y a plus de chance que ça arrive que de l'aide que ça peut apporter.
Personnellement j'adore perl et profite autant que possible de toute sa richesse (quel pied d'utiliser given/when par exemple). D'une manière générale je fais mon possible pour le rendre conçis (ce qui implique d'éviter un maximum de boucle par exemple là où un tas de méthodes s'appliquent directement sur une liste.
Pour ce qui est du unless, je trouve qu'il ajoute tellement peu de sémantique qu'il n'a pas beaucoup d'importance. Par contre je peste régulièrement de voir tant de programmeurs ne pas utiliser de switch alors qu'il apporte un vrai gain (et qu'il est disponible dans un tas de langage).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Bof du sucre syntaxique sans grand intéret
Posté par nud . Évalué à 1.
En pratique, dans les langages où on a if et unless postfixés, les cas d'utilisations des deux sont davantages liés à la probabilité: "Fais ceci sauf si c'est désactivé" implique que dans le cas normal ce sera fait.
Ceci dit, oui, c'est pas hyper-utile.
[^] # Re: Bof du sucre syntaxique sans grand intéret
Posté par CrEv (site web personnel) . Évalué à 2.
Oui, mais le problème d'aller par là c'est qu'il y a plein de choses qui ne sont pas hyper utiles…
Par exemple, pourquoi écrire :
Alors qu'on pourrait écrire :
C'est pas transcendant non plus…
[^] # Re: Bof du sucre syntaxique sans grand intéret
Posté par Zarmakuizz (site web personnel) . Évalué à 2.
Et puis pourquoi utiliser
Quand on pourrait faire
Le sucre syntaxique est une abomination du démon, il faut créer une version de C-- qui enlève toutes ces fioritures, et SamWang< pourra coder Zino avec.
Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/
[^] # Re: Bof du sucre syntaxique sans grand intéret
Posté par barmic . Évalué à 2.
Le for du C (celui que tu montre) montre une itération. Il est d'ailleurs utilisé bien souvent de manière non-intuitive pour faire autre chose. Le foreach est bien plus pertinent (il apporte de la sémantique en limitant les mauvais cas d'usage).
Je n'avais pas vu la subtilité que propose nud et qui me semble bien plus pertinent que ce que indiquait (et qui laisse libre court à des conditions négatives dans un unless), mais tu vois bien que unless (comme until d'ailleurs) apporte bien moins d'expressivité que for (il en apporte mais moins).
Tu devrais te pencher sur ruby pour voir un tas de manière de faire des boucles de manière très très lisible.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Bof du sucre syntaxique sans grand intéret
Posté par CrEv (site web personnel) . Évalué à 2.
raaaa non, avec
var
c'était du javascript :)Oui, mais c'est pas nécessaire d'avoir un
for
pour çaCe qui est souvent une horreur, et dans ces cas il vaudrait bien mieux des mots clés dédiés (ou des macros si besoin par exemple) qui permettraient de s'approcher de la volonté, de l'intention du programmeur et non de purement l'implémentation.
Ha mais c'est justement pour ces raisons (par exemple
unless
) que j'aime beaucoup ruby. En fait l'expressivité des langages permettent souvent de mettre en évidence l'intention du programmeur, et ça c'est réellement important pour pouvoir comprendre et corriger, maintenir un programme.[^] # Re: Bof du sucre syntaxique sans grand intéret
Posté par barmic . Évalué à 2.
Mince je suis passé vite dessus et le fait que la variable soit déclarée à l’extérieur m'a induit en erreur.
Multiplier les mots clefs ne me semble pas une bonne idée. Une vraie bonne approche pour ça, c'est perl (mais je suis certain qu'un paquet de langages le font aussi bien sinon mieux) : utiliser des fonctions !
Si tu veux utiliser une boucle pour filtrer, tu utilise la méthode grep.
Si tu veux appliquer un bout de code à chaque élément d'une liste, tu utilise map.
Si tu veux faire une réduction, tu utilise reduce.
C'est aussi ce que propose C++ avec la partie algorithm de la STL : http://fr.cppreference.com/w/cpp/algorithm
Pourquoi ajouter des mots clef quand ça peut être fait via de la bibliothèque ?
J'ai juste dis que
unless
apporte très très peu à ce niveau là c'est tout (mais c'est vrai que la nuance que nous a fait remarqué nud change un peu la donne).Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Bof du sucre syntaxique sans grand intéret
Posté par TImaniac (site web personnel) . Évalué à 1.
C# :)
[^] # Re: Bof du sucre syntaxique sans grand intéret
Posté par reno . Évalué à 2.
Pas d'accord: si le '< <' en lui même ne m’impressionne pas beaucoup, C# est vraiment impressionnant dommage que ce soit une technologie Microsoft.
[^] # Re: Bof du sucre syntaxique sans grand intéret
Posté par TImaniac (site web personnel) . Évalué à 2.
Je parlais pas des '< <' mais uniquement d'un langage avec un comportement sain des entiers (exception de dépassement ou big Int).
BigInteger : http://msdn.microsoft.com/en-us/library/system.numerics.biginteger.aspx
checked : http://msdn.microsoft.com/en-us/library/74b4xzyw
[^] # Re: Bof du sucre syntaxique sans grand intéret
Posté par reno . Évalué à 2.
Avec le smiley j'ai cru que c'était une plaisanterie..
Effectivement je compte C# parmi les langages avec un comportement sain pour les entiers.
[^] # Re: Bof du sucre syntaxique sans grand intéret
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 2.
Ben voilà ! Utilise Scheme ou Lisp !
T'as un comportement sain des entiers, la fonctionnalité requise et même mieux :
(apply < '(1 2 3 4 5))
Et ça existe en plein de variations (Gambit, Racket, Gauche, SBCL, Clojure, ), avec au moins une qui te plaira !
# git tag
Posté par woopla . Évalué à 3.
Et pourquoi ne pas utiliser git tag plutôt que de faire un branch?
C'est ce que j'utilise pour éviter de faire le mammouth avant un merge, et pour faire le lien entre les numéros de version et les commits (y'a pas de branches pour la maintenance, on fait tout sur la même branche parce que le code est très spécifique à chaque version).
C'est un peu plus léger et rapide qu'un branch.
[^] # Re: git tag
Posté par Albert_ . Évalué à 2.
Je ne suis pas si sur. Avec git tag j'ai toujours peur d'avoir un commit fait par un dev dans sans branches de developement qui se trouve merge avant le tag. Du coup le tag ne correspond pas a la version voulu. Je me trompe peut etre mais bon vu le coup d'avoir une branche avec git, je prefere me la jouer secure.
[^] # Re: git tag
Posté par Guillaume Knispel . Évalué à 2.
Quoi ?
[^] # Re: git tag
Posté par benoar . Évalué à 2.
Non, les branches sont faites pour ça. Les tags c'est pour marquer des points précis dans ton code, alors qu'un merge ça va recouvrir un ensemble de commits ; mieux vaut une branche pour les tracker correctement. Après, dans l'absolu, les deux sont des refs, donc c'est pareil, mais le tag peut potentiellement avoir plus d'attributs (signature GPG, …).
[^] # Re: git tag
Posté par woopla . Évalué à 2.
Dans son cas, la branch est utile seulement pour pouvoir faire un 'git reset --hard nom_de_branche', au lieu de faire 'git reset --hard id_de_commit'. Et pour autant que je sache, on peut aussi faire 'git reset --hard nom_de_tag'.
Comme c'est marqué en gros sur le site en lien, dans son utilisation ça marche parce que git branch "C’est une putain d’étiquette toute simple". Une étiquette, en anglais ça s'appelle un tag :)
Dans son cas, je ne vois pas la différence entre faire un tag et faire une branche au niveau fonctionnalité recherchée. J'ai loupé quelque chose?
[^] # Re: git tag
Posté par Matthieu Moy (site web personnel) . Évalué à 4.
Une branche et un « lightweight tag » seront exactement équivalents. Dans les deux cas, ce sont des références nommées vers un commit. La vraie différence entre une branche et un tag, c'est que quand on fait « git checkout ; git commit », ça déplace la branche, alors que « git checkout ; git commit » va nous mettre en « detached HEAD » et ne va pas toucher au tag. Pour cette utilisation, je préfère un tag.
Tout ceci étant dit, je ne comprends pas bien pourquoi l'auteur de l'article pointé s'énerve autant pour un merge.
git refuse de démarrer un merge si les fichiers concernés par le merge sont modifiés, et « git reset --merge » ne va réinitialiser que les fichiers concernés par le merge, donc ça marche, sans point de sauvegarde (c'est juste HEAD), et sans « git stash » préalable.
# Geary
Posté par zebra3 . Évalué à 3.
Je confirme, c'est prometteur. Je l'ai testé il y a quelques mois, ça ne marchait pas encore bien mais l'interface est sympathique.
Pour aller avec lui, il se prépare GNOME Calendar bâti au dessus d'Evolution Data Server. Pour l'instant c'est un peu léger mais pareil, ça s'annonce bien d'autant qu'il y a des recherches ici. Par contre, pour tester il faut minimum Evolution 3.5.3.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Geary
Posté par Kekun (site web personnel, Mastodon) . Évalué à 3. Dernière modification le 01 août 2012 à 07:45.
Pour rappel, Geary est développé en collaboration avec le projet elementary dont on retrouve la patte dans l'interface graphique. Il sera le client email par défaut du bureau Pantheon et donc d'elementaryOS Luna (sortie quand c'est prêt mais mon petit doigt me dit "avant la fin de l'année").
Postler, feu le client mail d'elementary, a été déprécié car trop buggué sur la partie service (l'interface fonctionnait très bien et ressemblait comme deux goûtes d'eau à l'actuelle de Geary) a été abandonné au profit de cette collaboration.
Pour information il est for probable que l'interface de Shotwell soit également retravaillée par Daniel Foré, leader et designer en chef d'elementary (Adam Dingle, le big boss de Yorba, attend encore le design parfait pour ça).
# pinry
Posté par Frank-N-Furter . Évalué à 4.
http://overshard.github.com/pinry/
Depending on the time of day, the French go either way.
# La conférence sur TED était très intéressante
Posté par Zarmakuizz (site web personnel) . Évalué à 3.
Merci !
Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/
# dév web
Posté par pralines . Évalué à 1.
tiens, un lien de plus : un autre site qui recense les fonctionnalités de son navigateur (et des autres)
html5test.com
attention, ça enregistre des choses côté serveur (mais apparemment on n'est pas obligé de confirmer qu'on utilise le navigateur truc-muche)
Envoyé depuis mon Archlinux
[^] # Re: dév web
Posté par lordblackfox . Évalué à 4.
Sinon un site avec des tables de compatibilité tout sympa:
http://caniuse.com/
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.