GeneralZod a écrit 2316 commentaires

J'utilise Fedora 19 sur toutes mes machines depuis l'alpha et ça ronronne ^{^}

ils en pensent que ça auraient été bien que les devs de Mate et/ou Cinnamon auraient bien été avisés de les consulter. Non pas pour les dissuader mais au moins, éviter les forks inutiles (beaucoup de composants ont été forkés sauvagement sans réfléchir) et collaborer ensemble.
Dans le cas de Cinnamon, ça aurait pu être un simple jeu d'extensions et si il y avait des manques dans l'API des extensions, ça aurait pu être remonté upstream pour être corrigé.

Quant à la qualité de Mate et/ou Cinnamon, elle est juste déplorable, la première fois que j'ai utilisé Cinnamon, il m'a fallu 5 minutes pour trouver un bug dans le panel le rendant inutilisable, le corriger puis soumettre une pull request. La qualité du code est moindre que dans GNOME de ce que j'en ai vu, et dans mon entourage, ce fut tellement plantogène (plusieurs fois par jour) que j'en vois plus beaucoup des Mate, Cinnamon (pourtant, la quasi-totalité était passé à Mint à un moment donné, ils sont tous revenu à Ubuntu et pour une partie sur GNOME 3)

Pour connaitre plusieurs anciens (et actuels) d'Arkoon (et avoir bossé avec l'un des fondateurs), c'est une boite qui développe certes des produits non-libre mais plutôt sympathique:
* contribution à des projets libres:
http://open-source.arkoon.net/
* méthodes agiles (Scrum) pour de vrai (et par l'ersatz vendu par certaines SSII pour paraitre cool).
http://open.arkoon.net/aoc/blog/blog/archives/les-methodes-agiles-chez-arkoon%C2%A0-etre-agile-pour-nous-une-ga
* un contexte stimulant (beaucoup de veille techno sur la sécurité, quelques hackatons dans l'année, des collègues plutôt bons dans leur domaine)

Même si il n'y a pas que du positif, c'est une boite qui est plutôt dans le haut du panier pour les ingénieurs.

J'avais posé la question à un dev de GCC pour savoir si c'était pour troller CLang ou bien normal qu'on incorpore de nouvelles fonctionnalités dans une version patch.
De fait, les patchs qui apportent la touche au support du langage C++11 (et pas la bibliothèque standard) étaient prêts depuis longtemps mais l'auteur original Bronek Kozicki a eu des soucis pour l'assignation de copyright à la FSF du côté de son employeur..
http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00024.html

Donc non, ça n'était pas pour coiffer au poteau CLang, qui lui arrivera avec une libc++ qui implémente entièrement la bibliothèque standard C++11. Quoi que soit Linux, on utilise habituellement libstdc++ ce qui remet à égalité GCC et CLang à ce niveau là. Mais c'est très bien qu'il y ait plusieurs implémentations de la dernière norme et que les prochaines soient déjà en cours d'intégration !
http://clang.llvm.org/cxx_status.html
http://gcc.gnu.org/projects/cxx1y.html

Ansible a été développé par un ancien Product Manager de Puppet Labs par ailleurs (et également l'auteur original de Cobbler et Func). ;)

Il faut voir, mais je crois qu'on peut virer énormément de choses du plus gros des IDE, eclipse.

C'est fastidieux -AMHA, plus que d'adapter un Vim/Emacs à son besoin-, et t'as des IDE qui sont très monolithiques.

Mais là où tu y gagne c'est que ces éditeurs von généralement t'offrir une abstraction du système de build, du gestionnaire de version etc pour au final te permettre d'en changer facilement.

J'ai un très mauvais souvenir des abstraction de systèmes de constructions, sachant que j'utilise autohell ou CMake qui sont déjà des abstractions de haut-niveau. Quant aux SCM, Emacs et Vim proposent une très bonne intégration, bien supérieure à ce que j'ai vu dans les IDE.
De fait, on en change assez rarement (sinon, ça indique un problème plus grave au sein du projet et/ou de l'équipe)

Là tu parle d'imposer un IDE à un ensemble de personne. Comme tu le dis c'est aussi intelligent de forcer l'utilisation d'emacs que de forcer l'utilisation de netbeans.

Régulièrement, j'entends des pairs dirent qu'il faut imposer un environnement commun, pour garantir que tout le monde suit les mêmes conventions. En gros, on file un machin pré-configuré et on espère -à juste titre- que les clampins soient trop fainéants pour le reconfigurer.
Bien évidemment, les mecs ont des accidents claviers et committent du code mal formaté ou des espaces qui trainent (les mecs oublient aussi d'appuyer sur le bon bouton qui reformatte le tout), etc. => c'est un processus lourd et infantilisant qui oublie l'essentiel: livrer un produit qui apporte une valeur ajoutée aux clients et le faire de manière professionnelle.

Qui maitre 100% de son éditeur de texte, de son gestionnaire de version et de son shell ?

Comme pour toute chose, pour maitriser un outil ou une technique, il faut s'entrainer régulièrement.

Ce qui m'agace vraiment c'est les développeurs incapables de coder sans IDE (qu'on soit moins productifs sans ses outils, je peux comprendre). Mais même si la pente initiale est plus douce, un IDE demande également un temps d'apprentissage non négligeable. J'ai déjà vu des gugusses bloqués parce qu'ils ne trouvaient pas la fonction qui allait bien, ou les conflits avec le code généré qu'on édite manuellement (don't do that), les commits monolithiques foireux etc …
C'est plus un problème de personnes qu'un problème d'outillage, mais bon.

Si vous voulez m'entendre râler vraiment, on peut parler des tests, ou des mecs qui détournent les bonnes pratiques de développement (aka Shitware Crapsmanship)

Tu trouve que vim ou emacs ont une courbe d'apprentissage simple ?

Non, mais je n'ai pas à "apprendre" un IDE pour chaque langage, framework etc. Je te concède que la pente initiale est beaucoup plus raide avec Emacs ou Vim.

Au passage, quelqu'un connaît un bon mode à Emacs pour avoir une vraie complétion plus intelligente aur le M-/ ? avec liste de suggestions et tout et tout ?

auto-complete pour les jolies popup
semantic pour la complétion sémantique en C, C++
jedi/ac-python.py (plugin auto-complete) pour Python
RSense pour Ruby
etc…

Les IDE proposent beaucoup de fonctionnalités qui peuvent améliorer la productivité des développeurs mais ils:

• inflation des fonctionnalités inutilisées voire inutiles (loi de Pareto 80/20 etc.) qui rend plus difficile la courbe d'apprentissage

• souvent très spécialisé pour une configuration donnée, dès qu'on en sort, on en revient à la gadoue (Eclipse/Netbeans/Intellij sont des blagues pour faire du C++) et le "savoir-faire" acquis n'est pas réutilisable.

• ont souvent des éditeurs assez pauvres comparés à Emacs/Vim

• chacun a un workflow personnel différent, ça explique les guéguerres Emacs/Vim, Eclipse/Intellij etc., c'est illusoire de vouloir fournir un IDE pré-configuré pour tous. On ne fait que planter des bâtons dans les roues des gens.

Le plus important, c'est:

• d'automatiser au maximum les tâches chiantes pour le développeur

• de réutiliser le "savoir-faire" acquis

L'avantage du NoIDE, c'est qu'une fois que tu as maitrisé ton environnement de base, il est adapté à ton workflow personnel (pas ou peu de gâchis), complètement maitrisé (qui maitrise 100% de son IDE ?) et s'adapte rapidement à un changement de contexte.

Je ne dis pas que les IDE c'est inutile, juste que ça n'est pas la panacée, dans certains cas, il y a un réel gain de productivité (Eclipse pour faire du Java, QtCreator pour du Qt etc.). Tout ça pour te dire que non, ça n'est pas une compétence indispensable (je préfère un bon développeur bien outillé qu'un développeur médiocre + super IDE), ça peut figurer sur le CV si ça a un rapport avec le poste.
Personnellement, je n'impose aucun environnement de développement, les seules règles étant:
* coding standard <= à respecter strictement (chacun configure son environnement pour, j'ai fait des confs emacs et vim basiques pour démarrer)
* pas des fichiers liés à un IDE dans le SCM <= ils sont souvent réécrits par ceux-ci et polluent l'historique
* revue de code systématique
* auto-régulation dans le nombre de langages, frameworks par projet et au niveau de l'équipe (formule empirique: chienlit = nb de pers * tps d'apprentissage * exp(nb changements de contexte))
Je suis sensé travailler avec des ingénieurs, je ne devrais pas avoir à décider de leur environnement de travail, à eux de s'organiser pour arriver à un résultat professionnel et de collaborer avec les autres.

C/C++

Moi, je réponds pas à des annonces qui me parlent du langage C/C++

L'ensemble parait complexe mais de fait, l'architecture d'OpenStack est relativement simple par rapport aux problématiques adressés.
OpenStack est conçu autour d'une architecture SOA autour d'un bus de messagerie (par défaut RabbitMQ, mais également QPid ou bien zeromq en brokerless), la plupart des services sont utilisables indépendamment.
Sur le diagramme, chaque rectangle correspond à un service, Nova mis à part, ils sont relativement simples, en gros, t'as un frontend API et un backend pour faire le boulot. Dans le cas de Nova, c'est le composant central et il doit s'interfacer à plusieurs services pour fournir des fonctionnalités (gestion des autorisations, images, réseaux, stockage etc.)

En comparaison, Eucalyptus semble avoir une architecture plus simple mais chaque composant est nettement plus complexe que dans le cas d'OpenStack. Malgré un leadership distribué (Cf. l'implémentation), je trouve fascinant qu'OpenStack ait une conception aussi bien définie et une implémentation qui reste compréhensible et avec des snippets de code très élégants (et instructifs)
Par exemple, Doug Hellmann a extrait/développé des paquetages Python pour les besoins d'OpenStack qui utilisent de manières très astucieuses setuptools/distribute:

• stevedore: architecture de plugin

• Cliff: gestion CLI

Marconi c'est le mieux meilleur projet d'OpenStack, faut faire des demandes de pulls dessus !

Merci de me signaler cette initiative qui est effectivement à suivre :)

Pour l'ORM, on a déjà répondu.
Pour les middlewares WSGI, Django propose les apps, mais du coup ça fragmente l'écosystème: Django ne peut pas monter une application WSGI facilement (chose qui est extrêmement courante dans le monde Ruby), se prive de composants éprouvés (notamment repoze.*) et inversement les app Django ne sont pas réutilisables dans une app WSGI classique.
Supposons que tu veuilles migrer progressivement une application d'un framework à l'autre ou réécrire certaines parties avec un framework plus adapté (par exemple un endpoint API extrêmement sollicité), n'importe quel framework WSGI te permettra de le faire assez simplement, avec Django, tu es obligé d'en réécrire une bonne partie.
La question est de savoir si oui ou non, c'est un problème dans ton contexte ? Le but de Django c'est de monter rapidement des applications web de manière propre et la mission est réussie. Mais il y a différents cas où Django n'est pas forcément la meilleure solution: intégration à un système existant, endpoint API etc.

Je partage ton opinion sur Django ORM, sans l'intégration poussée au reste qui rattrape le tout, c'est une belle #?@!§ d'autant plus quand on le compare à l'existant (SQLA, Storm, Peewee). Mais pour moi, le véritable inconvénient de Django est le non support de la norme WSGI.
Je ne parle pas de la partie déploiement, mais des middlewares qui font tout l'intérêt de la chose. Ça fait des années que RoR supporte Rack (plus ou moins l'équivalent rubyiste de WSGI).

je me demande comment font les dév. utilisant Django pour toutes les tâches de backoffice.

La plupart du temps, SQLA est capable d'importer n'importe qu'elles tables sans problèmes, mais Django ORM non. Le plus simple c'est de concevoir sa base avec Django ORM et d'utiliser un vrai ORM pour le backend. J'aime pas trop l'idée que ça se fasse dans ce sens mais c'est le plus simple.
Sinon, t'abstrait complétement la base de données métiers mais ça demande plus de taff.

La vraie force de Django c'est qu'il réponds à 80% des besoins avec un minimum d'efforts, là où d'autres frameworks comme Pyramid, Flask, etc. t'offrent plus de puissance mais au prix d'une configuration un peu plus longue et l'utilisation de plugins tiers.
Le seul vrai concurrent dans la catégorie framework tout-en-un que Django ait vraiment connu c'est TurboGears, mais les différentes migrations (TG 1/ 1.1/2.x etc.) et leurs aléas, une documentation moins complète, et une gestion de projet parfois chaotique (TG3 il est où ?) ont fait que ce qui était en 2006/2007 un produit supérieur à Django, aujourd'hui, un projet clairement sur le déclin (beaucoup sont passé à Pyramid).
Au final, Django est dans la lignée "Get the shit done", avec une très bonne finition (migration de version, documentation, etc.)

Quitte à buller autant le faire au bureau, ça soulève moins de questions …

OBS est une excellente usine de construction de paquetages et de distributions, openSuSE la seule distribution qui a sérieusement tenté -pas forcément concrétisé- de fournir un outil réutilisable pour d'autres distros.

Voilà les versions de Xen empaquetés dans Fedora:
F16 & 17: xen 4.1.4
F18 & 19 & 20: Xen 4.2.1
On n'a jamais eu de soucis à fournir des versions à jour pour la partie user-space, par contre, jusqu'à l'intégration de l'hyperviseur dans le master de Linux, c'était la galère pour avoir un noyau dom0 compatible sous Fedora (même si un développeur de RH s'est occupé d'en fournir un plus ou moins régulièrement dans un dépôt personnel).

Quant à moi, je suis sans mots face à ce concentré de stupidité

Le digne successeur d'ESR …

Au vu du passif de chromium, on s'oriente très probablement vers la solution 2.

Euh, je vois qu'Apple et Google contribuent à peu près autant l'un que l'autre (check les camemberts plus bas)
Par ailleurs, Google se plaint de ne pas pouvoir intégrer son modèle multiprocessus dans WK, mais à l'origine c'est eux qui ont fait le choix de le développer dans un coin, au point que WK2 a été développé pour offrir les mêmes fonctionnalités dans la branche principale (et ce en concertation avec tout les acteurs).
Non, la raison du fork n'est pas "Le gentil Google a été spolié par le méchant Apple qui veut partager le pouvoir", non, Google veut clairement faire chier Apple. On risque de retomber dans les pires travers de la guerre des navigateurs.
Qui va payer pour les conneries de Google ? les standards ouverts et l'intéropérabilité.

Euh, Google s'en branle des autres, suffit de voir le bordel que c'est Chromium, la plupart des libs sont forkés en interne, aucun effort n'est fait pour collaborer avec la communauté.

Apple c'était guère mieux, jusqu'à ce que les développeurs de KDE tapent une bonne gueulante.

Google était déjà le contributeur le plus actif de Webkit depuis quelques années mais sans être vraiment celui qui prend les décisions.

Les chiffres ? Ils ont contribués quoi ? Le moteur javascript, le modèle multiprocessus, etc… tout ça a été développé dans un coin sans jamais en discuter avec la communauté WebKit, et aucune volonté de réintégrer ça.

De fait, la version de WebKit fourni par Google était un fork, un bon fork bien crade qui ne portait pas son nom.

Installer redmine et git, je ne vois pas en quoi c'est "beaucoup plus complexe"

à installer non, à installer proprement et à maintenir -hint: le fork ChiliProject améliore de loin ce point-, c'est autre chose. Fossil remplit peut-être une niche mais il le fait très bien.

Pierre-Yves administrait juste le serveur et faisait les paquetages Fedora, il n'était pas développeur du projet -ce qui soit dit en passant, l'a bien amusé de l'apprendre par le biais de linuxfr -
En revanche, les mainteneurs ne souhaitent pas l'arrêt du projet non plus, donc à suivre.

On doit pas fréquenter les mêmes développeurs, la plupart se plaignent plutôt des messages cryptiques de GCC