Côtoyant énormément de profs, je peux constater la confusion qu'a engendré le fork parmi les utilisateurs de la suite dans le monde de l'enseignement. Ça irrite pas mal de ne plus trop savoir quel logiciel installer, auparavant c'était simple, on voulait une suite bureautique libre sous windows, c'était OOo, maintenant, euh bah, "t'as qu'à tester les deux ! … Comment ça tu n'as pas que ça à foutre ?"
Pourquoi chercher à tout prix à faire tourner des applis "natives" dans un navigateur web sur un mobile plutôt que d'exécuter directement les applis natives ? Un truc m'échappe.
Ce que je dis, c'est qu'en entretien, si le sujet est abordé par le recruteur, il suffise que je dise que je ne soumets pas mon code à des tests unitaires pour que la plupart d'entre eux ai un à-priori négatif à mon sujet, comme si cet état de fait était limite constitutif d'une faute professionnelle et impliquait une opposition inconditionnelle de ma part à leur mise en œuvre quelle que soit la situation.
Tu comprends bien qu'on est plus trop ici dans l'optique "que faisiez vous avant ?" mais plutôt "qu'êtes vous prêt à faire avec nous ?" et que si tu insistes en disant que tu as pris l'habitude de bosser sans tests unitaires, si l'autre en face n'est pas né de la dernière pluie, va interpréter ça comme "ouais alors lui, je pense qu'il aime pas les tests unitaires, il a des années de stratégie d'évitement (pas forcément au sens négatif du terme) pour les utiliser, ça va pas l'faire avec nous car on bosse en équipe avec parfois des stagiaires qui mettent les mains dans le code, ou bien seulement des gens qui veulent optimiser une routine bas niveau la veille de la mise en prod' et paf le chien"
Pour ma part, je considère que pour un code donnée, il faut toujours assumer que
- on est pas le seul à bosser dessus (même si on est vraiment seul à un moment donné)
- l'autre n'aura pas forcément notre connaissance du code
- l'autre, c'est peut-être nous-même dans quelques mois/années
Ce qu'on te dit, c'est que tu ne cesses de dire que dans ton cas les tests unitaires n'apporterait que peu de valeur ajoutée car tu connais bien le code , mais en entretien (puisque c'est de ça dont vous parliez à la base), on embauche rarement quelqu'un en ayant en tête le fait qu'il sera le seul (non seulement sur une période définie mais également du début à la fin de vie du produit hein, du genre si tu te barres et que quelqu'un reprend ton code, pas de tests unitaires => modification délicate des libs de la part du newbie) à bosser sur un code et le connaîtra tellement qu'il pourra se passer de tests unitaires.
Donc en gros, tu lui diras quoi à l'interviewer ? Que tu pourrais te passer de tests unitaires sur un projet où tu bosserais en solo ? mouaiiis. En effet, bonne chance !
A part les agités du linux, aujourd'hui, télécharger 200 Mo, c'est rien du tout.
"rien du tout" ?!
Tu ne peux pas être sérieux.
Je ne veux pas que ma petite application de gestion de série soit aussi grosse que libreoffice, faut quand même pas déconner !
C'est identique dans l'absolu mais en réalité, ce n'est pas dans la culture des logiciels web que de donner l'accès aux anciennes versions, alors que ça l'est beaucoup plus pour les applications natives.
Sa réponse semble à côté de la plaque, mais ça me fait quand même un peu penser à un gros avantage pour les clients lourds : tu peux retrouver une vieille version d'un logiciel pour une vieille plateforme.
Pour les app web, par contre….
Pour les systèmes linux, je n'ai absolument aucune envie/besoin de distribuer un binaire linké statiquement, bien entendu… (mais j'ai eu besoin de le faire à une époque pour un projet pro prioprio qui devait tourner sur un grand nombre de distros car on avait ni le temps ni les compétences de faire des paquets)
Je prends un exemple, sous windows, un compilation statique d'une appli en Qt permet de réduire la taille de l'application à quelques mega.
Comme ma platforme principale est une archlinux, je n'ai pas envie d'investir pour une licence de visualstudio, j'utilise donc mingw.
Et compiler Qt5 en statique avec mingw, c'est déjà assez "rigolo".
Ensuite, si jamais j'y arrive, on me dit "ah mais oui mais tu peux pas parce qu'une appli QML, il faut un plugin et utiliser les libs dynamique de Qt".
Ok, donc j'en suis là actuellement ; il semble qu'on ne puisse pas distribuer une version complètement statique d'une application Qt QML/QtQuick et qu'il faille embarquer la ribambelle de DLL de Qt et sa horde de plugins.
En fait, je remarque que comme toujours, je galère essentiellement pour windows.
D'ailleurs récemment GMail m'a trié mes mails en trois catégories, de mémoire : Defaut, Social et Commerical, sans que je n'ai rien demandé ou même accepté en me connectant ! On a l'impression d'avoir une secrétaire un peu trop zélée ça fait un peu peur :)
Oui, pareil, pas pu refuser la nouveauté tout de suite. Mais on peut revenir en arrière dans les préférences a posteriori.
Tu as raison.
Mais Jérôme a raison aussi, son point de vue était celui d'un utilisateur, pas du développeur de l'appli qui lui doit gérer l'enfer des plateformes.
Mais pour te rejoindre, en ce moment je fais une appli Qt + QML (principalement pour découvrir QML), je kiffe grave, mais je repousse au maximum le moment où je vais devoir m'attaquer au déploiement sous linux et windows, d'expérience, je sens que ça ne va pas mais alors PAS DU TOUT me plaire.
Le click-droit dans ton appli web tu peux l'oublier parce qu'il sert généralement déjà pour ton brouteur…
Pour l'application dont le journal cause et un bon nombre de celles de google par exemple, le bouton droit est exploité, et généralement fait apparaître un menu contextuel.
C'est moins choquant pour une application web que pour un site.
Curieux de nature, je suis allé lancer le soft et c'est vrai que ça trou le luc.
C'est assez désolant de se dire qu'un truc comme le module de libreoffice qui permet de faire de diagrammes et qui a de nombreuses années derrière lui n'a pas le dixième de l'ergonomie de cette appli… (oui je sais, j'ai qu'à contribuer…)
Rien que dans le détail par exemple :
- Le texte des flêches apparaît au dessus des flèches. Bin ouais, c'est con mais quand on veut faire apparaître du texte sur une flèche, on veut pouvoir le lire :)
- Relier les éléments avec des flèches est infiniment plus intuitif et peut démarrer depuis un bord de chaque élément
- Le texte des éléments est wrappé lorsqu'il commence à dépasser de l'élément
- On peut faire subir une rotation à n'importe quoi très facilement depuis l'élément
- …
Cela s'appelle un exemple, mais sa citation est générale.
Oui mais justement, l'esprit générale de cette citation ne me semble pas trop en phase avec la problématique qui est de développer un truc qui répond aux besoins mais avec un effort modéré porté sur l'optimisation en temps. En général, dans ce genre de cas, on sacrifie rarement l'exactitude des résultats pour l'optimisation, cette dernière vient en plus. Sacrifier l'exactitude des résultats est très souvent lié à des calculs mathématiques.
Mouais. C'est un peu à côté de la plaque, la citation de Linus (bien qu'excellente) concerne les gens qui cherchent la réponse la plus correcte (au sens mathématique) au détriment du temps.
Alors qu'ici, il s'agît de déporter la phase d'optimisation ultérieurement, si besoin.
Je sais bien que de calculer une valeur approximée suffisamment significative n'est pas forcément toujours plus simple que de calculer une valeur exacte, mais pour moi, le message de Linus s'adresse avant tout à ceux qui font un excès de zèle dans l'exactitude.
En même temps, c'est toi qui écris que "Et perso j'aime bien faire du GTK en_c_avec_des_underscore_partout." et que "Bref, quel que soit le langage, suffit d'apprendre à coder.".
Et perso j'aime bien faire du GTK en_c_avec_des_underscore_partout. Au moins je me pose pas la question de savoir OuJeDoisMettreDesMajusculesQuandIlYAUnSigleCommeGTK. Bref, quel que soit le langage, suffit d'apprendre à coder.
Le commentaire auquel tu réponds y va un peu fort, mais je suis allé voir comment on hérite d'un objet en GTK (ou bien d'un QObject), et j'ai fui immédiatement. 3 km de boilerplate code, non merci. /o\
Je comprends l'intérêt de projets comme Vala, par exemple…
En même temps, il s'agissait de pouvoir disposer des fonctionnalités précises d'un environnement lorsqu'on tourne sous cet environnement. Donc se plaindre d'un manque de portabilité dans ce cas, c'est assez cocasse :)
L'égoût et les couleuvres…
Moi j'ai trouvé ça très drôle, humour très pince sans rire, en particulier le passage où il explique être "fier" d'avoir rédigé une copie qui vaut bien un 18 après avoir décrit sa méthode de triche :)
Mais vu la note du journal, en effet, on doit pas être nombreux.
Pauvre patatarte :) se faire ruiner son karma alors que s'il avait fait précédé son journal d'une balise <humour> il aurait probablement eu un score positif ^^
les libs kde sont principalement destinée à implémenter des fonctionnalités "métier" liées au bureau KDE lui-même, pas forcément à étendre les fonctionnalités purement "IHM" (au sens large) (y'en a quand même hein, mais c'est essentiellement des composants spécifiques qui sortent un peu du champ d'un framework "généraliste" tel que Qt)
Bon après, pour vraiment comparer, il faut avoir une connaissance bien complète des deux côtés, je ne sais pas si on peut trouver beaucoup de gens capables d'avoir ces deux casquettes. Surtout vu l'étendue fonctionnelle de ce genre libs en 2013… personnellement je n'essaye même plus de regarder l'arbre des classes de Qt pour ne pas avoir peur :)
Oui pour MacOSX en particulier, Qt se heurte au haut niveau d'abstraction offert par les API.
Leur philosophie est de factoriser au maximum les concepts (même nouveaux), par contre, lorsque MacOS X intègre dans son API un système de carnet d'adresse, on pourrait être en mesure de comprendre que Qt ne va pas immédiatement proposer un QAddressBook dans son API pour rester à niveau. Dans un monde idéal avec une infinité de développeurs, c'est probablement ce qu'il ferait, mais il y a tellement de boulot à faire au niveau des couches du dessous…
Bref, oui, tu as raison, l'intégration des applis Qt sous MacOS X est à mille lieux de ce qu'il est possible de faire avec les outils de développement natifs, c'est une chose à prendre en compte lorsque la cible MacOSX est importante pour son projet.
[^] # Re: Déforker
Posté par Guillaume Denry (site web personnel) . En réponse à la dépêche LibreOffice 4.1 et Apache OpenOffice 4.0 sont de sortie. Évalué à 8.
Côtoyant énormément de profs, je peux constater la confusion qu'a engendré le fork parmi les utilisateurs de la suite dans le monde de l'enseignement. Ça irrite pas mal de ne plus trop savoir quel logiciel installer, auparavant c'était simple, on voulait une suite bureautique libre sous windows, c'était OOo, maintenant, euh bah, "t'as qu'à tester les deux ! … Comment ça tu n'as pas que ça à foutre ?"
[^] # Re: ça marchera jamais?
Posté par Guillaume Denry (site web personnel) . En réponse au journal Ubuntu Edge : Révolution ou bide annoncé ?. Évalué à 6.
Pourquoi chercher à tout prix à faire tourner des applis "natives" dans un navigateur web sur un mobile plutôt que d'exécuter directement les applis natives ? Un truc m'échappe.
[^] # Re: Les tests unitaires, c'est bon, mangez-en :-)
Posté par Guillaume Denry (site web personnel) . En réponse au journal Ce qu'on demande à un développeur aujourd'hui. Évalué à 4.
Tu comprends bien qu'on est plus trop ici dans l'optique "que faisiez vous avant ?" mais plutôt "qu'êtes vous prêt à faire avec nous ?" et que si tu insistes en disant que tu as pris l'habitude de bosser sans tests unitaires, si l'autre en face n'est pas né de la dernière pluie, va interpréter ça comme "ouais alors lui, je pense qu'il aime pas les tests unitaires, il a des années de stratégie d'évitement (pas forcément au sens négatif du terme) pour les utiliser, ça va pas l'faire avec nous car on bosse en équipe avec parfois des stagiaires qui mettent les mains dans le code, ou bien seulement des gens qui veulent optimiser une routine bas niveau la veille de la mise en prod' et paf le chien"
Pour ma part, je considère que pour un code donnée, il faut toujours assumer que
- on est pas le seul à bosser dessus (même si on est vraiment seul à un moment donné)
- l'autre n'aura pas forcément notre connaissance du code
- l'autre, c'est peut-être nous-même dans quelques mois/années
[^] # Re: Les tests unitaires, c'est bon, mangez-en :-)
Posté par Guillaume Denry (site web personnel) . En réponse au journal Ce qu'on demande à un développeur aujourd'hui. Évalué à 4.
Ce qu'on te dit, c'est que tu ne cesses de dire que dans ton cas les tests unitaires n'apporterait que peu de valeur ajoutée car tu connais bien le code , mais en entretien (puisque c'est de ça dont vous parliez à la base), on embauche rarement quelqu'un en ayant en tête le fait qu'il sera le seul (non seulement sur une période définie mais également du début à la fin de vie du produit hein, du genre si tu te barres et que quelqu'un reprend ton code, pas de tests unitaires => modification délicate des libs de la part du newbie) à bosser sur un code et le connaîtra tellement qu'il pourra se passer de tests unitaires.
Donc en gros, tu lui diras quoi à l'interviewer ? Que tu pourrais te passer de tests unitaires sur un projet où tu bosserais en solo ? mouaiiis. En effet, bonne chance !
[^] # Re: Un choix à faire
Posté par Guillaume Denry (site web personnel) . En réponse au journal Et moi qui croyais que le client lourd serait gagnant.... Évalué à 3.
"rien du tout" ?!
Tu ne peux pas être sérieux.
Je ne veux pas que ma petite application de gestion de série soit aussi grosse que libreoffice, faut quand même pas déconner !
[^] # Re: moef
Posté par Guillaume Denry (site web personnel) . En réponse au journal Et moi qui croyais que le client lourd serait gagnant.... Évalué à 3.
C'est identique dans l'absolu mais en réalité, ce n'est pas dans la culture des logiciels web que de donner l'accès aux anciennes versions, alors que ça l'est beaucoup plus pour les applications natives.
Pour DirectX, tu as ça, par exemple http://www.oldversion.fr/windows/directx/
[^] # Re: moef
Posté par Guillaume Denry (site web personnel) . En réponse au journal Et moi qui croyais que le client lourd serait gagnant.... Évalué à 4.
Sa réponse semble à côté de la plaque, mais ça me fait quand même un peu penser à un gros avantage pour les clients lourds : tu peux retrouver une vieille version d'un logiciel pour une vieille plateforme.
Pour les app web, par contre….
[^] # Re: Un choix à faire
Posté par Guillaume Denry (site web personnel) . En réponse au journal Et moi qui croyais que le client lourd serait gagnant.... Évalué à 2.
Pour les systèmes linux, je n'ai absolument aucune envie/besoin de distribuer un binaire linké statiquement, bien entendu… (mais j'ai eu besoin de le faire à une époque pour un projet pro prioprio qui devait tourner sur un grand nombre de distros car on avait ni le temps ni les compétences de faire des paquets)
[^] # Re: Un choix à faire
Posté par Guillaume Denry (site web personnel) . En réponse au journal Et moi qui croyais que le client lourd serait gagnant.... Évalué à 3.
Je prends un exemple, sous windows, un compilation statique d'une appli en Qt permet de réduire la taille de l'application à quelques mega.
Comme ma platforme principale est une archlinux, je n'ai pas envie d'investir pour une licence de visualstudio, j'utilise donc mingw.
Et compiler Qt5 en statique avec mingw, c'est déjà assez "rigolo".
Ensuite, si jamais j'y arrive, on me dit "ah mais oui mais tu peux pas parce qu'une appli QML, il faut un plugin et utiliser les libs dynamique de Qt".
Ok, donc j'en suis là actuellement ; il semble qu'on ne puisse pas distribuer une version complètement statique d'une application Qt QML/QtQuick et qu'il faille embarquer la ribambelle de DLL de Qt et sa horde de plugins.
En fait, je remarque que comme toujours, je galère essentiellement pour windows.
[^] # Re: Réactivité des clients légers.
Posté par Guillaume Denry (site web personnel) . En réponse au journal Et moi qui croyais que le client lourd serait gagnant.... Évalué à 2.
Oui, pareil, pas pu refuser la nouveauté tout de suite. Mais on peut revenir en arrière dans les préférences a posteriori.
[^] # Re: Un choix à faire
Posté par Guillaume Denry (site web personnel) . En réponse au journal Et moi qui croyais que le client lourd serait gagnant.... Évalué à 3.
Tu as raison.
Mais Jérôme a raison aussi, son point de vue était celui d'un utilisateur, pas du développeur de l'appli qui lui doit gérer l'enfer des plateformes.
Mais pour te rejoindre, en ce moment je fais une appli Qt + QML (principalement pour découvrir QML), je kiffe grave, mais je repousse au maximum le moment où je vais devoir m'attaquer au déploiement sous linux et windows, d'expérience, je sens que ça ne va pas mais alors PAS DU TOUT me plaire.
[^] # Re: Réactivité des clients légers.
Posté par Guillaume Denry (site web personnel) . En réponse au journal Et moi qui croyais que le client lourd serait gagnant.... Évalué à 3.
Pour l'application dont le journal cause et un bon nombre de celles de google par exemple, le bouton droit est exploité, et généralement fait apparaître un menu contextuel.
C'est moins choquant pour une application web que pour un site.
# Ouais
Posté par Guillaume Denry (site web personnel) . En réponse au journal Et moi qui croyais que le client lourd serait gagnant.... Évalué à 4.
Curieux de nature, je suis allé lancer le soft et c'est vrai que ça trou le luc.
C'est assez désolant de se dire qu'un truc comme le module de libreoffice qui permet de faire de diagrammes et qui a de nombreuses années derrière lui n'a pas le dixième de l'ergonomie de cette appli… (oui je sais, j'ai qu'à contribuer…)
Rien que dans le détail par exemple :
- Le texte des flêches apparaît au dessus des flèches. Bin ouais, c'est con mais quand on veut faire apparaître du texte sur une flèche, on veut pouvoir le lire :)
- Relier les éléments avec des flèches est infiniment plus intuitif et peut démarrer depuis un bord de chaque élément
- Le texte des éléments est wrappé lorsqu'il commence à dépasser de l'élément
- On peut faire subir une rotation à n'importe quoi très facilement depuis l'élément
- …
[^] # Re: quelques points
Posté par Guillaume Denry (site web personnel) . En réponse à la dépêche De tout, de rien, des bookmarks, du bla bla #29. Évalué à 4.
Oui mais justement, l'esprit générale de cette citation ne me semble pas trop en phase avec la problématique qui est de développer un truc qui répond aux besoins mais avec un effort modéré porté sur l'optimisation en temps. En général, dans ce genre de cas, on sacrifie rarement l'exactitude des résultats pour l'optimisation, cette dernière vient en plus. Sacrifier l'exactitude des résultats est très souvent lié à des calculs mathématiques.
[^] # Re: quelques points
Posté par Guillaume Denry (site web personnel) . En réponse à la dépêche De tout, de rien, des bookmarks, du bla bla #29. Évalué à 3.
Mouais. C'est un peu à côté de la plaque, la citation de Linus (bien qu'excellente) concerne les gens qui cherchent la réponse la plus correcte (au sens mathématique) au détriment du temps.
Alors qu'ici, il s'agît de déporter la phase d'optimisation ultérieurement, si besoin.
Je sais bien que de calculer une valeur approximée suffisamment significative n'est pas forcément toujours plus simple que de calculer une valeur exacte, mais pour moi, le message de Linus s'adresse avant tout à ceux qui font un excès de zèle dans l'exactitude.
[^] # Re: 10 ans...
Posté par Guillaume Denry (site web personnel) . En réponse à la dépêche De tout, de rien, des bookmarks, du bla bla #29. Évalué à 10.
Tu veux dire, "ça coule sous le sens" ?
[^] # Re: émotion
Posté par Guillaume Denry (site web personnel) . En réponse au journal Slackware a vingt ans. Évalué à 9.
Merci, Capitaine premier degré !
[^] # Re: Qt vs Gtk
Posté par Guillaume Denry (site web personnel) . En réponse au journal LXDE, Razor-qt et Qt (et GTK+). Évalué à 4.
En même temps, c'est toi qui écris que "Et perso j'aime bien faire du GTK en_c_avec_des_underscore_partout." et que "Bref, quel que soit le langage, suffit d'apprendre à coder.".
[^] # Re: Qt vs Gtk
Posté par Guillaume Denry (site web personnel) . En réponse au journal LXDE, Razor-qt et Qt (et GTK+). Évalué à 7.
Le commentaire auquel tu réponds y va un peu fort, mais je suis allé voir comment on hérite d'un objet en GTK (ou bien d'un QObject), et j'ai fui immédiatement. 3 km de boilerplate code, non merci. /o\
Je comprends l'intérêt de projets comme Vala, par exemple…
[^] # Re: Qt 4 dans un premier temps puis Qt 5.1 ensuite
Posté par Guillaume Denry (site web personnel) . En réponse au journal LXDE, Razor-qt et Qt (et GTK+). Évalué à 2.
Du genre ? (la réponse m'intéresse vraiment, on a une grosse appli en Qt au boulot et je m'interroge sur l'opportunité de la migrer en Qt 5)
[^] # Re: Migrations ?
Posté par Guillaume Denry (site web personnel) . En réponse à la dépêche Qt 5.1 est juillet. Évalué à 9.
En même temps, il s'agissait de pouvoir disposer des fonctionnalités précises d'un environnement lorsqu'on tourne sous cet environnement. Donc se plaindre d'un manque de portabilité dans ce cas, c'est assez cocasse :)
[^] # Re: o_O'
Posté par Guillaume Denry (site web personnel) . En réponse au journal Privé de bac à cause d'un logiciel propriétaire. Évalué à 4. Dernière modification le 08 juillet 2013 à 10:42.
L'égoût et les couleuvres…
Moi j'ai trouvé ça très drôle, humour très pince sans rire, en particulier le passage où il explique être "fier" d'avoir rédigé une copie qui vaut bien un 18 après avoir décrit sa méthode de triche :)
Mais vu la note du journal, en effet, on doit pas être nombreux.
Pauvre patatarte :) se faire ruiner son karma alors que s'il avait fait précédé son journal d'une balise <humour> il aurait probablement eu un score positif ^^
[^] # Re: bof
Posté par Guillaume Denry (site web personnel) . En réponse au journal LXDE, Razor-qt et Qt (et GTK+). Évalué à 5.
les libs kde sont principalement destinée à implémenter des fonctionnalités "métier" liées au bureau KDE lui-même, pas forcément à étendre les fonctionnalités purement "IHM" (au sens large) (y'en a quand même hein, mais c'est essentiellement des composants spécifiques qui sortent un peu du champ d'un framework "généraliste" tel que Qt)
Bon après, pour vraiment comparer, il faut avoir une connaissance bien complète des deux côtés, je ne sais pas si on peut trouver beaucoup de gens capables d'avoir ces deux casquettes. Surtout vu l'étendue fonctionnelle de ce genre libs en 2013… personnellement je n'essaye même plus de regarder l'arbre des classes de Qt pour ne pas avoir peur :)
[^] # Re: Migrations ?
Posté par Guillaume Denry (site web personnel) . En réponse à la dépêche Qt 5.1 est juillet. Évalué à 10.
Delphi de quelle année ? sur quel type de machine ? avec quelles contraintes ?
[^] # Re: Migrations ?
Posté par Guillaume Denry (site web personnel) . En réponse à la dépêche Qt 5.1 est juillet. Évalué à 5.
Oui pour MacOSX en particulier, Qt se heurte au haut niveau d'abstraction offert par les API.
Leur philosophie est de factoriser au maximum les concepts (même nouveaux), par contre, lorsque MacOS X intègre dans son API un système de carnet d'adresse, on pourrait être en mesure de comprendre que Qt ne va pas immédiatement proposer un QAddressBook dans son API pour rester à niveau. Dans un monde idéal avec une infinité de développeurs, c'est probablement ce qu'il ferait, mais il y a tellement de boulot à faire au niveau des couches du dessous…
Bref, oui, tu as raison, l'intégration des applis Qt sous MacOS X est à mille lieux de ce qu'il est possible de faire avec les outils de développement natifs, c'est une chose à prendre en compte lorsque la cible MacOSX est importante pour son projet.