small_duck a écrit 139 commentaires

Ce qui me gêne dans le "getInstance" sans paramètres, c'est que les paramètres dont le singleton avait besoin pour sa construction deviennent implicites. Par exemple, une connexion à une base de données doit elle-même devenir un singleton, lequel va utiliser le singleton de la configuration, lequel est forcé d'utiliser des variables globales pour retrouver une variable d'environnement ou un paramètre en ligne de commande pour retrouver un fichier ou une surcharge d'option.

Et là, tout est implicite, tout est global, et c'est la galère pour faire tourner un test unitaire ou pour créer une instance locale avec des paramètres différents.

Idéalement, on n'utiliserait donc pas de singleton du tout, mais parfois, c'est la solution la moins laide. Je suis d'accord avec toi que d'avoir à repasser les paramètres à chaque fois est dangereux, et cela doit certainement être évité autant que possible. Mais je crois qu'il y a des cas où, bien documenté, quand les paramètres à passer sont peu ambigus comme un fichier de config, un loggeur ou une connexion à une base de données, alors c'est la moins pire des solutions.

À consommer avec modération, donc :)

Tout à fait, puisque l'on ne peut pas prévoir si l'objet sera réellement instancié, ou si l'on va renvoyer un objet déjà existant.

Si par exemple, on passe une connexion vers une base de données, il est raisonnable de l'ignorer si l'objet existe déjà, parce ce que nouvel objet ou pas, son utilisation sera exactement la même. L'appelant n'étant pas sûr d'être le premier, il ne peut que passer les paramètres, qui seront utilisés ou pas.

Si maintenant les paramètres peuvent être différents d'un appel à l'autre, la sémantique change complètement car on s'attend alors probablement à récupérer un objet différent en fonction des paramètres, et peut-être faut-il utiliser l'approche moins générique avec un conteneur associatif qui lie les paramètres à l'instance qui va bien.

Il y a encore des projets passionnants en C++. Je travaille sur un gros système financier sous fortes contraintes de performance et de latence dont la plus grosse partie sort d'une base de code d'environ 2 million de lignes de C++, dont une grosse moitié est générée via une moulinette maison.

Pour nous, le C++ a vraiment très bien marché. Nous avons pu utiliser les fonctionnalités du langage pour monter un cadre orienté événements qui fait la part belle à l'héritage multiple: je m'enregistre sur toutes les sources de données qui m'intéressent, et je me fais appeler sur mon objet de manière thread-safe. Comme ces sources de données se ressemblent beaucoup, nous utilisons à fond les templates pour factoriser le code et réduire la duplication. Nous utilisons le plus possible la bibliothèque standard, qui s'est étoffée et est maintenant de très bonne qualité.

Nous pouvons nous interfacer avec des bases de données en écrivant des adapteurs RAII autour de leurs API C, avec des variadic templates pour avoir des types sûrs, nous avons un accès bas niveau sur le disque et sur le réseau, et pouvons bénéficier de tout un tas d'outils de mesure de performances, de Valgrind à gprof en passant par Intel VTune. Nous utilisons même Wt, une bibliothèque qui propose la création d'applications Web que l'on code comme en QT, pour nos interfaces utilisateurs.

Comme nous avons la main sur tout ce qui se passe, il est aisé, quand c'est nécessaire, de descendre aussi bas que voulu: éviter les allocations, faire attention au principe de localité, voire tenter de transformer les "if" pour réduire les branches.

Tout cela est également possible en Java, par exemple, mais éviter les allocations en Java présuppose de passer par des réservoirs d'objets et devient rapidement moche. Avec le C++, nous arrivons souvent à encapsuler ces constructions très bas niveau derrière de belles interfaces afin de garder un ensemble propre et bien architecturé.

Développeur sur une plateforme financière, le support vient me dire qu'une donnée n'a pas été mise à jour. Je leur propose de relancer le service adéquat, me disant qu'en 30 secondes ça sera revenu, et que tous les postes clients ayant les infos en cache, ça ne se sentira même pas. On relance, et puis ça met un peu plus longtemps que prévu à charger les données depuis la base…

Derrière moi, j'entends monter le grondement sourd de la salle de marché, les traders commencent à parler de plus en plus fort, on entend des cris de "pourquoi mes ordres ne passent pas???".

Le support re-route rapidement les ordres vers l'ancienne plateforme, et tout s'est remis à marcher (nous étions en Beta, et nous avions donc des solutions de secours), donc pas de conséquences, mais je me suis senti très bête.

Merci à l'équipe Postgres pour leur travail d'une qualité peu commune. J'avais poussé mon équipe à utiliser Postgres plutôt que MySQL il y a de cela quelques années, et malgré des DBAs peu chauds au début nous avons aujourd'hui une douzaine de bases et des terra-octets de données pour des applications très critiques, et tout cela fonctionne plutôt bien.

Notre équipe est peut-être un peu particulière en cela que nous n'utilisons pas d'ORM, et sommes donc plutôt près du métal. Cela permet d'utiliser à fond les spécificités du SGBDR, pour les performances (COPY) comme pour les fonctionnalités (type tableau).

Je vais rajouter le bouquin à ma liste du Père Noël.

Jolie, cette image!

Je dirais qu'il faut des années de pratique intensive de Blender pour faire une telle image à partir de zéro. Maintenant, je doute que l'artiste qui a créé cette image ait tout fait à partir de zéro, même, et surtout, si il a des années de pratique.

Le personnage semble tout droit sortir d'une bibliothèque de personnages, peut-être Poser. Il existe de nombreux greffons pour modéliser de la végétation. Les textures des maisons et du bord du canal semblent en grande partie être des textures photos, et je ne serais pas surpris si les maisons elles-mêmes ainsi que le bateau viennent de banques d'objets.

Après, la composition est excellente, tout a été très bien intégré, les matériaux sont impeccables et l'éclairage est également très beau. Mais l'artiste pro, qui travaille à partir d'un budget et avec des contraintes de temps, investira dans des greffons et les banques d'objets et de textures, pour pouvoir se concentrer sur sa valeur ajoutée.

Les amateurs que nous sommes auront très certainement une approche très différente.

Je confirme, on peut faire plein de choses assez fun avec l'édition vidéo intégrée à Blender. Je vais voir si j'ai assez de matériel pour en faire une dépêche.

J'ai essentiellement appris via les tutos vidéo. Après, il y a les bons tutos et les mauvais tutos, mais souvent, je trouve la parlotte utile pour comprendre la logique de l'artiste, et pourquoi certaines approches fonctionnent mieux que d'autres.

Mes tutos préférés sont ceux d'Andrew Price, le Blender Guru. Ce sont des tutos longs (Plus de 2 heures réparties sur 4 vidéos juste pour modéliser une enclume !), mais variés et souvent spectaculaires.

Et même franchement au delà à lire les Dingodossiers, la rubrique à brac, et les autres… Tiens, pas plus tard que la semaine dernière, je me remémorais cette séquence dans l'"enfant sauvage", où le gamin se lève tout d'un coup, et colle 3 pains au professeur. Le "Mémento du dessinateur de bandes", également, est un petit bijou, où il se moque gentiment des clichés sur les héros de bandes dessinées.

Quelques précisions:

Le Wifi est stable, et l'on ne perd pas la connexion. Le problème que je rencontre est que régulièrement, quand je rentre chez moi, la liste des points d'accès n'a pas été rafraîchie, et je vois encore les réseaux qu'il y a autour de mon boulot. Cela finit par se corriger, mais il est plus rapide de désactiver puis de réactiver le Wifi pour récupérer ma connexion à la maison. Pas top, certes, mais pas une honte non plus.

Les notifications SMS ont toujours parfaitement fonctionné. Ce qui ne fonctionne pas, ce sont les notifications pour les e-mails (le développeur de Dekko a expliqué pourquoi, mais je n'ai rien compris), et les notifications Telegram, elles, fonctionnent de manière un petit peu aléatoire.

Voilà!

Non, et c'est bien dommage :)

Les applications dans les dépôts Ubuntu, même compilées pour ARM, sont faites pour tourner dans un environnement X, alors que Ubuntu Touch utilise MIR.

En revanche, il est théoriquement possible de recompiler une application Qt existante au dessus du SDK Ubuntu, et là ça pourrait marcher.

Le SSO est aussi intéressant à la construction, car il permet d'économiser une allocation par rapport au COW, si par exemple l'on construit les données via une constante, ou encore via un char * d'une API C (au hasard, une API de base de données) ou d'un objet différent (par exemple, extraction d'une std::string depuis un std::fstream).

Parce que les allocations sont si chères par rapport à une bête copie de quelques octets, mon instinct est que le SSO sera un gain global de performances pour la plupart des applications. Si j'obtiens des benchmarks intéressants, je les posterai.

J'attends ce changement d'implémentation de std::string avec impatience. L'optimisation précédente, qui était d'utiliser de la copie sur écriture, était de moins en moins efficace dans les applications lourdement parallèles tournant sur des serveurs à grand nombre de cœurs, car il faut acquérir des mutex (cher!) et faire des barrières mémoire pour flusher les caches de chaque cœur (très cher!) tout le temps.

Avec la nouvelle optimisation SSO (pour "short string optimisation", optimisation des petites chaînes), l'idée est que l'on peut encoder les chaines courtes au sein même de la structure de chaîne, en utilisant l'emplacement mémoire du pointeur pour y mettre ses caractères. Tant que la chaîne est plus petite que la longueur du pointeur, on y met directement les données, dès qu'elle est plus grande, cette zone mémoire redevient un pointeur vers un emplacement sur le tas. Copier des petites chaînes devient alors très bon marché. Ça tombe bien, bon nombre de programmes passent un temps formidable à copier des petites chaînes.

J'ai commencé à recenser les bibliothèques tierces utilisées par notre système. Dès que nos amis de chez Red Hat nous sortent un Developer Toolkit avec g++ 5.1, je recompile tout!

Au passage j'ai jamais compris pourquoi il y a le choix "Appliquer les MàJ et éteindre" et pas aussi le choix "Appliquer les MàJ et redémarrer"…

Ça se tient: une mise à jour peut prendre un certain temps, et la plupart des gens qui veulent redémarrer veulent reprendre la main le plus vite possible. Alors que si l'on avait l'intention d'éteindre, et donc ne pas revenir à sa machine pendant un moment, qu'elle mette 15 minutes de plus n'est pas très important.

Alors après, si l'on veut redémarrer justement pour appliquer les mises à jour, ça n'est pas ergonomique, mais nos amis de chez Microsoft ont du penser qu'il s'agissait du cas minoritaire.

Salut!

J'arrive un peu après la bataille, mais voila néanmoins mon avis.

Tout d'abord, ayant récemment, et à mon corps défendant, fait pas mal de Java, j'ai pu apprécier l'intégration du langage avec ses outils, la simplicité du build, et la gestion de dépendances façon Maven ou Ivy. Je n'ai pas pu retrouver une intégration aussi bonne avec le C++, je comprends donc ta douleur.

Je suis passé par de nombreux IDE, mais je n'ai jamais rien trouvé qui me satisfasse complètement. CodeBlocks était probablement un des meilleurs. J'ai entendu beaucoup de bien de QCreator. Mais la solution qui a fonctionné pour moi, c'est ce bon vieux Emacs. En utilisant le modes compilation, qui permettent d'aller à l'erreur via un clic ou via une touche du clavier, et le mode gdb, qui permet, via gdb-many-windows, d'obtenir un très bon environnement de debug, l'on se retrouve avec une solution très intégrée et productive. Pub inside, je détaille mon utilisation d'Emacs dans ma série Coder efficacement avec Emacs (les posts les plus anciens ne sont pas correctement taggés, mais ils ne sont pas difficiles à trouver).

Pour la solution de build, il n'existe pas de remède miracle. Ton choix semble judicieux, cmake est très utilisé et devient de plus en plus une référence, mais l'outil gagne à être un petit peu étudié, l'utilisation des modules simplifie énormément la vie.

Le temps de compilation est toujours aussi problématique. J'ai utilisé dans le passé les en-têtes pré-compilées, mais j'en suis revenu, ayant trouvé qu'un peu d'attention dans les #include et qu'une utilisation massive de la forward declaration me donnait de bien meilleurs résultats. Surtout, utiliser Boost le plus parcimonieusement possible, en particulier dans les fichiers d'en-tête, et utiliser plutôt les primitives de la bibliothèque standard, laquelle s'est bien étoffée avec une panoplie de pointeurs intelligents, de primitives pour gérer le parallélisme, la mesure du temps ou même les expressions régulières.

Au passage le linker "gold" (Goooooold linker!!!!) améliore fortement les performances à l'édition de liens, ce qui est toujours ça de pris.

Ccache et distcc aident également beaucoup, mais c'est encore du boulot supplémentaire de mettre tout cela en place.

Je ne peux que t'encourager à investir un peu de temps pour te construire un environnement aux petits oignons, et à tirer meilleur parti du langage. D'excellentes bibliothèques sont disponibles pour programmer des jeux. Nommons en particulier SFML, le couteau suisse de l'interaction avec le matériel (vidéo, audio, contrôleurs), et OpenSceneGraph, qui est un graphe de scène basé sur OpenGL, et dont les capacités sont remarquables.

Bon courage!

Eh oui, quand bien même cela semble une hérésie à première vue, nous avons une grosse base de code en C++, et voulions quelques outils Web pour configurer nos services. Nous utilisons WT pour une approche par composants très agréable, on a vraiment l'impression de faire du QT, sauf que ça apparaît dans un navigateur. C'est léger, et ça s'intègre très bien avec du C++ dit "moderne". C'est pour de l'utilisation en interne, donc on ne se casse pas trop le bol avec les styles, mais c'est probablement un petit peu difficile à rendre vraiment joli.

Nous utilisons également cppcms, qui est nettement plus bas niveau, pour afficher de gros rapports pas trop interactifs (une grosse table qui se met à jour régulièrement via Ajax). Cela nécessite d'écrire beaucoup de Javascript soi-même, par contre.

Complètement. Dans le meilleur des cas, on se dit que si le logiciel est bien, après un petit moment, on fera un don. Et puis on oublie. Mais la plupart du temps, c'est gratuit, on prend. C'est humain.

Rhaaa, flûteuuuu, il s'agit en effet de la groseille à maquereau, également, si l'on en croit Wikipédia, appelée croupoux, croque poux, gratte poux, ou pétasse (!). Je m'en vais réviser tous mes fruits rouges (avec travaux pratiques!).

Souscription démarrée, plus qu'à être patient :)

Leur site est très joli, mais un peu fouillis, j'ai failli abandonner quand, à force de cliquer, je me suis retrouvé à promettre $1000 sans savoir comment annuler… Je vais me refaire une cure de Big Bucks Bunny pour faire passer.

Intéressant, l'article reflète bien les avantages de Blender pour obtenir ce genre d'icônes: approche vectorielle, textures procédurales, et résultat plus réaliste.

Mes quelques tentatives dans ce domaine: http://aubedesheros.blogspot.co.uk/search/label/blender

En particulier, j'ai pris note de comment obtenir un arrière-plan transparent pour le rendu PNG, ce qui change complètement la vie.

J'adore Blender. Je m'en sers plus particulièrement pour modeler des icônes pour mes applications, je trouve que cela permet une approche plus précise et un bien meilleur rendu que mes tentatives "à main levée" dans Gimp ou même Inkscape.

Il est facile d'ajuster le modèle, de changer un angle de caméra, de bidouiller une couleur ou une texture, et avec quelques outils de base, modelage par extrusion, textures procédurales pour la couleur et pour les normales, on atteint quelque chose de plutôt joli.

Une même requête ne peut malheureusement pas tourner sur plusieurs CPUs en parallèle dans Postgresql. De ce que j'en comprends, ce serait assez difficile à mettre en oeuvre, en particulier parce que Postgresql n'utilise pas de threads, mais de multiples processus, mais les développeurs y travaillent (voir par exemple http://www.databasesoup.com/2013/05/postgresql-new-development-priorities-4_20.html)

Pour moi, les grosses questions seront: est-ce que ce sera libre? Est-ce que je serai root dessus? Est-ce que je pourrai installer n'importe quel paquet Ubuntu? Et est-ce que Steam fournira des jeux?

Je me tâte vraiment à participer, mais c'était plutôt une tablette libre, que je voulais… (Vivaldi a l'air de bouger?)

En effet, c'est à Londres, et d'autant que je puisse comparer nous payons bien nos développeurs.

Je ne compte pas recevoir des réponses parfaites à toutes mes questions. Le but est de faire réfléchir le candidat, et s'il ne connaît pas par coeur la complexité d'insertion dans un std::set, c'est une bonne occasion de le faire réfléchir sur les opérations de base sur les arbres binaires.

Mais au final, c'est l'attitude qui compte le plus. On fait tous des erreurs et on ne peut pas tout savoir, mais l'envie d'apprendre et de s'améliorer, la petite étincelle dans les yeux quand ils découvrent quelque chose de nouveau, c'est ce qui fait généralement le bon candidat, je trouve. La manière dont un candidat va réagir lorsqu'on lui donne finalement la réponse à un problème sur lequel il vient de plancher est incroyablement utile pour le juger, d'ailleurs. Et j'ai horreur des entretiens dans lesquels on ne donne pas la réponse au candidat à la fin. C'est généralement le signe que les questions cherchent à coller ou à coincer le candidat, plutôt qu'à démarrer la conversation lui laissant sa chance de montrer là où il est bon.

Ma première question en entretien (C++): "Quel est ton conteneur préféré?". Ensuite, je les grille dessus. Complexité de toutes les opérations, détails d'implémentation, efficacité vis à vis des caches du CPU, algorithmes standards (fusion de deux conteneurs triés…). Quant on est allé au fond des choses, je fais écrire un peu de code avec des templates (par exemple, retourner le max d'un conteneur), ce qui permet de reparler un peu des performances (incrémenter un itérateur de vecteur et un itérateur de liste, par exemple).

Après, quelques questions de culture générale sur les ordres de grandeur en temps pour accéder à un registre, la mémoire cache, la mémoire, le disque, et le réseau.

On parle ensuite un petit peu multithread, de réseau, de SQL.

Enfin, je les fait parler un peu de leur expérience, en leur demandant ce qu'ils considèrent comme étant la chose la plus difficile qu'ils aient faite cette année.

Et puis, c'est à eux de poser des questions :)