CrEv a écrit 4577 commentaires

Nan mais c'est des jeux de société, pas des jeux vidéo !

ces applications servent à faire des choses utiles, genre bosser.

Tu veux dire qu'il y a réellement des gens qui écrivent des applications qui servent à quelque chose ? Enfin je veux dire quelque chose d'autre que mouler au travail ? o_O

Le déploiement est plus facile car centralisé, c'est vrai.

En natif c'est également possible, via l'app store, les dépots linux et le windows store. Idem sur les smartphones. Cet argument en faveur du web est caduc.

Heu non ce n'est pas caduc, bien au contraire.
Pour une app web, tu as une URL à maintenir, un dépôt quoi.
Pour du natif tu as quoi ?

• 1 windows store
• 1 app store
• 1 play store
• n (n > 3 ou 4 si tu veux que ce soit intéressant) dépôts linux à gérer

Franchement côté facilité de déploiement on a vu mieux.

Mais non, c'est pas la faute d'OVH c'est la faute à github m'enfin !

la dernière fois qu'on a partagé un patch, on nous a débauché le gars. depuis j'ai interdit de publier les diffs.
-- tweet

oublié de préciser "sur github, avec du bigdata au cul pour alimenter les chasseurs de têtes". sur nos serveurs ftp no soucis.
-- tweet

un mec se barre pour ses raisons. no regret. ça nous a permit de découvrir la vraie motivation de github ..
-- tweet

un gars qui cherche à partir, partira. ce que j'ai interdit, c'est d'alimenter le bigdata de github
-- tweet

les sites comme github permettent de répertorier, faire les stats, les actions sur la communauté de dev.
-- tweet

Je ne suis pas certains que ce soit réellement github le fautif… Si un gars est débauché c'est autant la "faute" de la boite qui débauche que de la boite actuelle. Trop souvent les boites "oublient" que c'est aussi à elles de s'arranger pour que les employés n'aient pas envie de partir.

De rien, content d'occuper ton temps libre ;-)

CrEv, tu pourrais pas trouver de sujets et des documents moins intéressants ?

Si ce n'est que ça, on doit pouvoir s'arranger !
Voici donc les liens que je ne placerai pas dans une prochaine news (trop vieux, moins intéressants, juste pas envie, etc) :

Devel

• A better way to learn AngularJS : http://www.thinkster.io/
• Welcome to the wonderful world of noBackend where frontend developers build full stack apps, without thinking about the backend : http://nobackend.org/
• La boite à outils de la parallaxe : http://www.webdesignertrends.com/2012/07/la-boite-a-outils-de-la-parallaxe/
• 3dxml (format d'échange 3D, plutôt orienté CAO) : http://www.3ds.com/fr/products-services/3dvia/3d-xml/00/
• De l'artisanat aux bases de l'industrialisation : http://fr.slideshare.net/tut_tuuut/de-lartisanat-aux-bases-de-lindustrialisation avec une vidéo planquée au milieu d'un billet sur les braguettes… (désolé Agnès ;-) http://ploque.net/plok/2013/07/ce-quon-ne-dit-pas-dans-les-bouquins-sur-la-grossesse/

Misc

• Toyota Kata an alternative to agile restrospectives : http://hakanforss.wordpress.com/2012/04/25/agile-lego-toyota-kata-an-alternative-to-retrospectives/
• Kanban : faire des promesses que vous pouvez tenir : http://blog.xebia.fr/2013/06/12/kanban-faire-des-promesses-que-vous-pouvez-tenir/
• Infographie sur le secteur aéronautique : http://www.grouperandstad.fr/files/img_grf/pdf/Infographie_Aeronautique_fleuron_de_lindustrie_francaise.pdf
• Les ATR 600 étendent leur rayon d'action : http://www.usinenouvelle.com/article/les-atr-600-etendent-leur-rayon-d-action.N198648
• Travailler sur ses deux pieds (prez pour vanter les mérites de la position debout pour travailler) : http://real34.github.io/slides/travailler-sur-ses-deux-pieds/#/
• La compétitivité et la France, une grande histoire d'amour depuis la fin des années 90 : http://www.usinenouvelle.com/article/competitivite-une-etude-souligne-le-decrochage-de-la-france-depuis-1997.N198040
• Innovation Jugaad : Redevenons ingénieux : http://www.amazon.fr/Innovation-Jugaad-Redevons-ing%C3%A9nieux-Radjou/dp/2354560966 (d'ailleurs si quelqu'un a un retour sur ce livre ça m'intéresse vraiment)
• La relation entre Atlassian et les recruteurs (ça me donne aussi l'envie d'écrire un billet un peu dans le même genre, mais entre un candidat - moi - et les recruteurs…) : https://www.atlassian.com/company/careers/recruiters

Graphisme, design, photos, etc

• Asiles abandonnés : http://io9.com/six-abandoned-asylums-with-genuinely-chilling-backstori-512154481
• Des stations de métro justes… sublimes : http://io9.com/eye-poppingly-gorgeous-underground-stations-from-around-508669563

Voilou, j'espère que je t'ai bien pourri tout ton temps libre avec tout ça, à la prochaine ! :-p

Merci à toi :-) Avec de la chance le prochain sera dans un peu moins longtemps…

Et voilà encore une fois la preuve de la supériorité des technologies ruby sur python !!

Mais si je vous promet qu'on est vendredi !

J'ai fait ce court journal

Je pense que tu devrais en faire une dépêche, en outre ça aurait une plus grande visibilité.

il me semble que ce logiciel, bien que fort intéressant et développé depuis 3 ans, n'a pas encore été évoqué sur LinuxFR.

Et non ;-) Il a été évoqué ici et aussi ici par exemple. Mais j'en conviens, il y a plus de détails dans ce journal, d'où l'intérêt encore à mon avis de le passer en dépêche.

Oui mais est-ce qu'il est toujours utilisé ? ;-)

En fait c'est surtout que au final j'ai l'impression qu'on passe notre temps à refaire la même chose.
On cherche sur pas mal de plans à résoudre encore et toujours les mêmes problèmes, typiquement faire évoluer les composants de base (listes déroulantes, avoir des onglets, etc). XUL, Flex, WPF/E étaient par certains côtés des tentatives d'améliorations de cela.

Alors oui, il y a beaucoup de choses plus intéressantes, javascript est bien plus important, la programmation côté serveur est toujours plus "agréable" par exemple. L'interface évolue aussi, on a des meilleurs inputs (date, mail, etc, gestion d'élément requis dans un formulaire, layout, etc). Mais d'un autre côté rien ne change. Les outils sont meilleurs mais bon, c'est tout de même un peu toujours le même problème qu'avant.

Peut-être est-ce moi qui ait une mauvaise vision du monde du web, c'est une possibilité. Peut-être ne vois-je pas le chemin accompli mais beaucoup plus le chemin qu'il resterait à accomplir.

une discussion sur du code PHP pourri

Tu as un pointeur ? ;-)

Donc oui, il faut l'écrire. Mais il faut aussi le justifier, sinon ça ne sert à rien

Oui, et il faut aussi que ce soit pertinent vis à vis du contexte. Les règles ne s'appliquent pas toujours de la même manière dans tous les domaines. Par exemple dans un domaine critique, je verrais surtout de petites méthodes, très facilement testables, peu de profondeur dans chacune, etc. Parfois dans de la glue, du code non métier, le problème et l'intérêt peut varier.

Pas tout à fait mais Rails a 9 ans. C'est pas si mal que ça, non ?

Ça c'est sur que ça reste un problème…

Maintenant, disons qu'on peut limiter la casse en fixant des règles au niveau des navigateurs supportés (genre les firefox depuis le dernier ESR, les 2 ou 3 derniers chrome, les 2 derniers IE uniquement, etc)
Avec ça tu peux faire du grand public, du perso, voir même du pro si tu vise un parc "correct" (oui je sais certains se mettent enfin à IE7 mais bon…)
De toute façon ce n'est que de cette manière que les choses avanceront réellement.

• [NIH] (les [] sont en trop)

• « Don't get demoralized by bad estimates ! »

  La forme initiale estimates! n'est-elle pas correcte ? En anglais il n'y a pas d'espace devant la ponctuation, non ? Après, vu que c'est inséré dans un texte français, je ne sais pas comment on doit l'écrire.

Et sinon, merci aux correcteurs, j'avais essayé de le nettoyer avant mais j'ai vu que j'avais laissé certaines erreurs donc merci encore.

Je bosse actuellement sur l'implémentation de ca, algo page 8

Forcément si tu n'y mets pas un peu du tiens ! ;-)

Plus sérieusement, je vois ces règles pour les objets "classiques", pas pour les (gros) algos. Et comme tu le dis, il s'agit surtout de bon sens. D'ailleurs je trouve que certaines règles ne sont pas forcément bonnes, genre limiter à deux membres. C'est bien sur les cas d'écoles, mais dans la vrai vie tu as quand même souvent une structure complexe, logique, propre qui en contient plus.

Et de toute façon, appliquer bêtement les règles ça ne marche que très rarement ;-)

Mais celles-ci peuvent faire une base assez correcte pour bosser, tant qu'on n'est pas dans une grosse complexité algorithmique, dans ce cas le problèmes est tout autre à mon avis.

Et on pourrait aussi dire que l'un des avantages de Sass c'est Compass.

Mais d'un autre côté la vérification des logiciels open source n'est que théorique. En théorie on peut lire le code, en théorie des gens le font, et en théorie on trouve les problèmes. Ce qu'il y oppose c'est que d'une part il n'y a pas tant de monde que ça qui le lit (et dans une grosse boite il y a aussi du monde qui lit le code, fait des revues, etc), et que en pratique détecter une faille est d'une part complexe, d'autre part ne fonctionne pas toujours (toujours l'exemple de debian ssh)

En théorie vérifier un logiciel open source est plus facile.
En pratique je n'en suis malheureusement pas toujours convaincu. Là où par contre ça peut être meilleur, c'est dans les cas où il y a revue de code systématique avant commit dans la branche principale. Là je pense que ça commence à être meilleur que les fermés.

C'est triste ton avis sur le saucisson…

Mais dans aucune des catégories Linuxfr.isées.

Dans ce cas tu peux peut-être aussi expliquer dans quelle catégorie. Et je pense que les commentaires sont aussi là pour ça.

Pas grave [bla bla]

C'est bien pour ça qu'en entête il est précisé :

La liste des options proposées est volontairement limitée : tout l'intérêt (ou son absence) de ce type de sondage réside dans le fait de forcer les participants à faire un choix. Les réponses multiples sont interdites pour les mêmes raisons. Il est donc inutile de se plaindre au sujet du faible nombre de réponses proposées, ou de l'impossibilité de choisir plusieurs réponses. 76,78% des sondés estiment que ces sondages sont ineptes.

Oui mais justement, moi je préfère moins bouger.
Par exemple avoir un clavier sans pavé numérique et un touchpad à côté ou devant. C'est parfois juste horrible de devoir bouger le bras pour attraper la souris pour ensuite la bouger, alors que le touchpad est beaucoup plus proche et que je ferai de plus faibles mouvement.
Il n'y a bien que pour (rarement) jouer que j'utiliser une souris si j'ai le choix.

Hum, j'ai quand même l'impression que sur un (bon) touchpad (oui genre celui des mac, désolé mais rien que la surface est plus intéressante que la majorité de ceux de "PC") on n'a pas à bouger beaucoup.
Et par exemple pour choper un trackball il faut que je déplace beaucoup plus le bras que pour aller choper un touchpad.
Mais c'est vrai qu'en remplacement d'une souris j'aimerais bien.

À mon avis ce n'est pas une façon très efficace de gérer ses fenêtres

Faut voir… moi je trouve ça très bien, en tout cas en complément d'autres moyens. Et faut croire que beaucoup d'utilisateurs trouvent que c'est pas si mal que ça.

Inutile sur un ordinateur de bureau ou portable : c'est un truc de tablette ou de téléphone tactile ça

Question bête, mais as-tu déjà essayé (pour de vrai) avant de dire que c'est inutile ?
En fait c'est comme un touchpad vs trackpoint, forcément un touch pad c'est inutile.

Au contraire, un grand touchpad bien placé et des gestures c'est bien plus pratique qu'une souris, et parfois même que des raccourcis claviers même si, encore une fois, c'est complémentaire.
Mais par exemple pouvoir faire défiler une page avec une gesture au lieu de prendre la molette ou de placer le doigt dans une zone ridiculement petite à l'extrémité du touchpad est juste vraiment pratique.

Bref, lancé de troll loupé, je dirais.

Vu ta réponse je ne pense pas, bien au contraire !

Tu as raison, je ne sais pas si il y avait à proprement parlé une "revue de code". Ce que j'entendais c'est surtout le côté "je commit, c'est visible sur un dépot, sur une mailling list, souvent sur un bug tracker, etc". Et donc en général pas fait en catimini de manière opaque.
Après, peut-être que s'il y avait eu une "vrai" revue de code ça ne serait peut-être pas arrivé (mais ce n'est pas certain non plus) et mine de rien c'est aussi ce qui est fait dans le monde proprio ;-)

sauf que de nos jours, c'est un peu tard ("time to market", l'autre a pris a place et pas qu'un peu).

Sauf que de nos jours c'est tumblr qui a pris la place si tu veux un blog…

Donc ça montre que d'une part tu peux très bien avoir une nouvelle plateforme si elle est jugée plus intéressante que les autres, les choses se font et se défont très vite et c'est plutôt bien. Mais d'un autre côté, il faudrait aussi que dotclear ait quelque chose de différent, de plus, que les autres. Sans cela, objectivement, pourquoi utiliser dotclear ?
(et je dis ça en tant qu'ancien utilisateur de dotclear, même si je suis passé à une solution maison et plus geek on va dire)

L'étude des failles de sécurité se fait de toutes façons au niveau de l'assembleur ou par fuzzing, donc en boîte noire

Et ? Je suppose que pas mal de monde s'y essaie, non ?
Et surtout dans ce cas que ce soit linux ou windows ça ne change strictement rien alors.