G.bleu a écrit 186 commentaires

Je ne connaissais pas, merci pour l'info !
Ça a l'air assez jeune, tu as des retours d'expérience dessus ?

De la pub pour quoi ?
Pour Heroku (qui est un super service, c'est vrai) ? Je donne des solutions alternatives
Pour appliquer des bonnes pratiques pour rendre ses applications meilleurs ? Assurément !
Pour Docker ? c'est le bon journal non ;-)

Une application c'est parfois un service TCP, un service http + une base de données : 3 containers ou un groupe de 3 ou 1 seul container ?

L'idée de Docker c'est de découper son application en briques de bases, puis de conteneuriser ces briques.
Dans ton cas on a :
- une base de donnée : sur le site de docker son fourni des conteneurs tout prêt pour la plupart des bdd
- un service TCP, un service http : vu que http passe par TCP, je ne suis pas sûr de ce que tu veux dire, mais si il s'agit de deux services différents (un serveur web + un tracker de torrent d'iso linux), tu vas donc créer deux conteneurs docker (en écrivant deux Dockerfile)

Quel sont les applications non dockerisables ?

Tout est potentiellement dockerisable ("quels sont les applications non exécutable dans une vm ?"), toutefois une application dont les composants sont fortement couplés se prêtera beaucoup moins (par exemple si ton application nécessite que ta base de donnée soit en local, ton Dockerfile va se complexifier, et la base de donnée va faire grossir l'image du conteneur qui deviendra difficilement portable avec le temps)

Docker n'est il pas la VM java du siècle dernier ? , en gros va t il réussir la ou java à échoué ?

Où est-ce que java a échoué ? Pas dans le monde des serveurs où il est très présent ! Docker ne sert pas à empaqueter une application client (encore que, certain y pensent comme solution d'isolation, bien que ce ne soit pas au point pour le moment).
Java avais l'avantage de permettre au admin sys de déployer sur un serveur (pouvant être une architecture powerPC, sparc etc…) un binaire compilé par l'équipe de dev (travaillant sur x86), de nos jours les parts de marché de x86/amd64 sont écrasantes (et beaucoup de langages sont interprétés), on est donc en droit de se foutre de la gueule de java tous les vendredi ;-)

Si il y a une chose qui a changé la vie de mes applications web, c'est le passage du iaas (vm amazon "aws ec2") au paas (heroku):

• avec aws, on te file une vm et tu installes l'OS, configure le routage, fait les mises à jours, gère les logs etc… C'est lourd au quotidien, mais la galère arrive vraiment quand on commence à vouloir hébergé sa base de donnée avec redondance (et sauvegardes récurentes), à scaller ses serveurs en fonction de la charge

• avec Heroku, tu donnes ton code, tu précise ses dépendances et c'est tout ! Toute la maintenance sans rapport avec ton code est sous-traité à un spécialiste, les questions de scalabilité ne sont qu'un curseur à régler (voir rien du tout si on demande une scalabilité automatiquement !), on ne raisonne plus en terme de serveurs mais en terme de services.

La philosophie derrière cette révolution, c'est le concept de l'application aux 12 facteurs (traduction libre, allez voir http://12factor.net/). En respectant ces 12 règles, on obtient une architecture moderne® qui simplifie énormément le cycle de vie des applications.

Le rapport avec Docker ? Heroku utilise son propre système de conteneurisation des applications (le "slug"), Docker permet donc de disposer d'un format standard et open-source d'empaquetage des applications.
Grace à cette technologie le monde du PAAS est en pleine expansion :
- le projet Deis qui vise fournir une stack comme Heroku avec Docker (http://deis.io/)
- Amazon à lancé Beanstalk pour héberger des conteneurs Docker
- Des clouds basés sur docker se lancent à la pelle (premier lien sur google http://www.centurylinklabs.com/top-10-startups-built-on-docker/)

J'imagine qu'à l'avenir on pourra très simplement passer d'un fournisseur de cloud à l'autre (voir héberger son application via plusieurs fournisseurs) grâce à Docker, ce qui favorisera la concurrence (et donc baisse des $$$ ainsi que moindre dépendance aux géants comme Amazon et Google).

Ma fois 2.9%, c'est le genre de part de marché qui me ferait dire que windows phone n'est pas prêt pour le desktop…

Pour en avoir fait pas mal dans un précédent projet, le XLST (en plus de son illisibilité chronique dû à XML) prend vite en complexité dès qu'on utilise des fonctionnalités un peu avancé
- deux versions (v1 et v2) plus ou moins incompatibles et en concurrence
- peu de documentation sur internet et surtout divisé entre v1 et v2 ce qui induit souvent en erreur si la version n'est pas précisé
- la création de fonctions n'est pas intuitive du tout (le fait que ce soit du fonctionnel n'aidant bien sûr pas les gens qui n'y sont pas habitué, soit un bon paquet de programmeurs !)

Bref pour contribuer à du XLST il faut déjà bien le connaître sous peine de passer beaucoup de temps à faire des choses assez triviales, là où Python (qui n'est certes pas très à son avantage ici) est bien plus simple à modifier, même pour un néophyte

Personnellement je me demande pourquoi ils ne sont pas partit sur un moteur de template comme il existe pléthore dans le monde web (au hasard, léger et puissant : http://jinja.pocoo.org/docs/dev/)

J'aurais tout fait en nodejs. Tellement plus facile à installer in fine. De plus je doute qu'aucun de ces composants n'ai pas son équivalent dans npm.

Au contraire je trouve qu'utiliser Docker est une bonne idée pour déployer facilement : un service web peut être développé en ouatmille technos (typiquement ici OPA qui te rebute…) mais cela n'est d'aucun intérêt pour l'utilisateur (comprendre : celui qui va déployer, et qui veut le faire vite sans galérer et sans devoir apprendre un nouvel environnement) qui se focalise légitimement sur ce qui le concerne (i.g. fonctionnalités, performances, stabilité…)

C'est plutôt calme niveau candidats, j'imagine que beaucoup d'étudiants ont déjà trouvé leur stage, à moins que ce ne soit l'effet "fêtes de noël"…

Ma foi, on tient une piste intéressante sur les causes de son suicide…

Puisqu'on est dans la couleur, je ne résiste pas à l'envie de partager ma découverte du jour : un petit caviar de mauvaise foie issue du ~/.bashrc de ubuntu/debian par défaut.

# uncomment for a colored prompt, if the terminal has the capability; turned
# off by default to not distract the user: the focus in a terminal window
# should be on the output of commands, not on the prompt
#force_color_prompt=yes

En gros si tu utilises la couleur dans ton prompt, c'est que t'es un n00b frivole !
Mince, moi qui croyait que ça servait à repérer le début d'une commande instantanément quand on navigue dans son historique, à avoir une aide visuelle pour savoir si on est en local ou sur une autre machine en ssh ou encore si on est sur une console root etc…

C'est grâce à ce genre de foutage de gueule qu'on s'est saigné les yeux pendant des décennies sur les sorties de gcc (miam les erreurs de templates C++ hyper-verbeuses en monochrome !) jusqu'à ce que clang arrive et que la vindicte populaire force gcc à s'aligner dessus.

à part de leur demander de t'envoyer une version sur papier

Oui, mais si il n'a pas de boite aux lettres ? ;-)

Sur ce coup gloire à dash !
Avec tout le parc ubuntu l'utilisant à la place de bash comme /bin/sh (j'imagine que c'est pareil pour debian), ça exclu quand même un bon nombre de serveur.

Évidemment jusqu'à ce qu'une faille analogue soit trouvée dans dash… à ce moment il nous restera eshell !

Bien simple : le Figaro titrera "un robot dépasse les légendaires lois de la robotique !" et oliwoude nous fera enfin un bon flim sur le sujet…

C'est ennuyeux quand on voit sur quoi pointe ta page perso ;-)….

Mais Bram sait-il faire des merveilles sur sa codebase avec 10.000USD ? ;-)

Wolfire Games avait libéré le code de Lugaru après son passage sur le Humble Bundle…
Resultat des petits enfoirés malins on fait un portage sur iphone (illégal puisque utilisant les "assets" propriétaires) pour se faire du blé à pas cher !

1er lien trouvé sur le sujet via google

Quand on pense à la situation précaire de la plupart des indies, c'est sûr que prendre un tel risque pour un bénéfice financier quasi nul tient de l'acte de foi (ou du marketing auprès des barbus linuxiens…)

Les différences visibles à l'œil nu sont assez subjectives, d'où l'utilisation de métriques «mathématiques» pour départager les formats.

Partant du principe que jpeg/WebP sont des formats destinés à un utilisateur final pour une utilisation ne nécessitant pas une grande qualité (autrement on utilise forcement un format sans pertes), je trouve l'argumentation de Google pertinente : une image quasiment similaire pour l'oeil humain, mais 30% plus petite.

Enfin, il est possible d’écrire des fonctions imbriquées (nested functions, fonctions à l’intérieur d’autres fonctions), contrairement au C, C++ ou Java.

C'est faisable en C ! (bien que fortement découragé et non standard…)
http://gcc.gnu.org/onlinedocs/gcc/Nested-Functions.html

L'option semble manquer !

Bon ok, je ne l'utilise pas encore : mon Peak+ arrive mi-septembre
Mais quelle joie ce sera de brûler délaisser mon Android à ce moment là !

Au vu de asm.js, j'ai un peu de mal avec l'argument "trop lent". En fait ça me fait penser aux mecs qui disent que Java est "trop lent"…
D'ailleurs, vu que ce dernier est la solution que tu as choisis pour Newton Adventure, j'aimerais bien que tu développe ton avis sur Javascript.

Personnellement de ce que j'ai fait de dev avec Javascript et j'aurai plutôt tendance à dire que c'est un langage trop permissif ce qui rend le code rapidement très sale si on n'y fait pas attention. Par contre la rapidité de développement et de déploiement est vraiment flagrante comparé à du C++

Si Intel pouvait former une nouvelle architecture propre, moderne et correctement construite, les gains pourraient être énormes.

Itanium quoi ;-)

# define likely(x) __builtin_expect(!!(x), 1)
# define unlikely(x) __builtin_expect(!!(x), 0)

Une idée pour le "!!(x)" ?
C'est pour être sûr que ce qui est passé en paramètre est un booléen ? (i.g. !42 == 0, !0 == 1 ==> !!(42) == 1 )

Tu aurais dû faire un journal pour ce très bon article, c'est moins volatile que le forum !

Personnellement, le projet sur lequel je travail au boulot est très gros (plusieurs milliers de fichiers dont des centaines de makefiles, récursif bien sûr !)
C'est une vrai horreur à faire marcher :
- illisible, des milliers de lignes qui s'appellent dans tous les sens…
- utilisation massive de variables global qui vont rester dans le shell (donc aucune garantie sur l'état
- scripts de nettoyage trop vieux (nettoient pas tout voir plante carrément !)
- lenteur (des dizaines de secondes juste pour vérifier les dépendances)
- Et bien sûr le moindre changement tient de la gageure !

À côté de ça, mon expérience sur les autotools m'a définitivement convaincu que ce remède est pire que le mal :
- extrêmement bordélique (pan ! voila 10 fichiers en plus dans la racine de ton projet…)
- très lent (mention spéciale au configure)
- mal documenté et complexe à utiliser (la semaine dernière j'ai cherché à modifier un script autotools d'un vieux projet… j'ai laissé tombé après 1h de tâtonnement…)

Au final j'en suis arrivé à la conclusion suivante (complètement opposée à la tienne ! ⁾ : La simplicité avant tout !
- Autant que possible : pas de système de build ! De nos jours, combien de projet on vraiment besoin d'être écrit en C/C++ plutôt qu'en Python ?
- Pour les tout petit projets : Makefile tout seul avec grosso modo trois règles toutes simples (build, clean, %.o:%c)
- Pour le reste : CMake (avec Clang et ninja, mais c'est une question de goûts et ça se change en 2s). Un seul fichier de configuration simple et ça roule tout seul !

Je pense qu’il est important de reconnaître que vous ne pouvez pas avoir 100% de sécurité mais aussi 100% de respect de la vie privée et zéro inconvénient. Vous savez, nous allons devoir faire des choix de société.

Quand j'avais vu Obama faire ce discourt aux infos, j'ai toute suite pensé à ce qu'avait dit ce père fondateur :
“Une société prête a sacrifier un peu de liberté contre un peu de sécurité ne mérite ni l’une, ni l’autre, et finit par perdre les deux”

Je suis confus, l'article complet dont parlait le journal répond entièrement à mes questions

Un grand bravo pour un tel projet, et surtout une telle débauche d'information et de documentation. Vous n'allez pas à la Scipy2013 pour rien !