CrEv a écrit 4577 commentaires

Histoire de continuer :

16) Que penses-tu des tendances actuelles dans le domaine des environnements de bureau (unité, Gnome 3) ?

Je sais que c'est sympa de traduire les termes Anglais mais là… ;-)

ben étant donné que c'est fait en php je dirais que tu te rends sur l'url où tu l'as décompressé.
Tu l'as bien décompressé dans un serveur web gérant le php, non ? (désolé mais j'ai pas réussi à saisir si en fait tu posais une vrai question ou pas)

c'est la première fois que je vois un nazi de la typo

Pour ceux que le sujet intéresse (enfin sans être un nazi non plus), il y a par exemple ce bouquin : http://www.adverbum.fr/webgrids-fradier-anne-sophie-atelier-perrousseaux_ouvrage-perrousseaux_4kd26i9rxoms.html#

Je ne l'ai pas encore fini mais il y a une chose qui est bien, c'est qu'il est écrit entre autre qu'il faut bien faire la différence entre la typo sur support physique et la typo sur le web. L'intérêt et les possibilités ne sont justement pas les mêmes. Et notamment il faut faire très attention lorsqu'on verrouille la taille des colonnes car il est possible, sans changer de css, de modifier la taille des caractères et donc pour une taille donnée le nombre de caractères par ligne par exemple (enfin c'est plus complexe que ça).

Nan mais c'est rien, t'as juste presque une heure de retard…

On peut ainsi voir Linux en costume de pingouin manchot… (https://linuxfr.org/nodes/94509/comments/1359988)

Tu t'es perdu sur la banquise pendant ce temps ? ;-)

On a l'impression d'être un vrai hacker :)

Ha, un peu comme le |337 5p34k alors ! T'as l'impression mais en fait non.

(bon, j'dis ça, mais j'ai codé pendant pas mal de temps sous emacs, y compris professionnellement, y compris sous windows…)

Ce genre de cas existe (ok là c'est un peu caricatural mais c'est pour la bonne cause).
Evidemment on peut toujours quitter un instant, pour aller chercher un colis (enfin ça pas trop…) pour aller à un rdv, médecin ou autre.
Mais c'est toujours pour quelque chose, toujours avec une excuse. Alors que ce qui serait intéressant c'est de pouvoir le faire juste parce que tu as fini ton taff ou que tu perds ton temps à tourner en rond. Et ces cas là ne fonctionnent pas alors que ce serait parfois plus bénéfiques pour tout le monde.

et tu as d'autres exemples ? Car là on a l'impression que tu as juste bloqué sur un seul cas et c'est tout… mais bon, tu sais, ça se soigne hein ;-)

Tout comme certains logiciels demandent une Redhat mais sont indiqués non compatible centos. C'est beaucoup pour des histoires de support et/ou de test. Mais pas forcément une histoire de réelle compatibilité.

De la à dire que cette nouveauté nécessite de scrapper d'urgence tous les systèmes d'init actuels parce qu'ils seraient tous pourris alors que tout le monde contourne ce problème très simplement, c'est juste du grand n'importe quoi !

Ce qui ne semble pas être l'avis de beaucoup de monde qui développe ces softs ou ces distribs.

Et bon, avancer l'argument qu'on contourne (donc fait crade un truc qui ne devrait pas l'être) est justement une raison de virer et de passer à systemd alors.

Ca c'est la question qu'il faudrait poser à Gnome par exemple, mais aussi aux distribs.
Car ça m'étonnerais vraiment qu'ils se mettent tous à systemd juste pour emmerder les unix lovers de linuxfr…

systemd devient, de plus en plus, un composant difficile à remplacer…

C'est pas un peu le contraire ? Que les composants actuels se font de plus en plus remplacer par systemd.

Mais dans ce cas, c'est peut-être que certains trouvent dans systemd une meilleur réponse à leurs problèmes/souhaits que les autres solutions, non ? Et dans ce cas si certains ne veulent pas de systemd peut-être faudrait-il qu'ils proposent autre chose de mieux (par mieux j'entend qui réponde mieux aux problèmes sous toutes leurs coutures, c'est pas forcément uniquement mieux techniquement)

dans l'ensemble ça fonctionne rudement bien

Et qu'est ce qui ne fonctionne pas de ton côté ?

Pour ma part, après avoir lu quelques news ici sur owncloud et suite à des mésaventures de serveur perso, j'ai fini par en installer un.
La première chose c'est que l'installation et les mises à jour sont vraiment faciles (du bête php/mysql tout classique à installer). Donc ça c'est bien.
Et aujourd'hui j'ai commencé à poser mes fichiers (après mise à jour en 4.0.2). J'ai donc essayé de faire comme avec Google Drive :

• installation du client
• login
• configuration du répertoire
• ajout des fichiers

Bon, ben sans appel : ça ne fonctionne pas :

• il n'arrive pas à me créer les répertoires
• lorsque je crée les répertoires il les trouve bien mais n'arrive pas à ajouter les fichiers. Enfin si, il passe son temps à ajouter un fichier puis le supprimer avant d'ajouter le suivant. Et ainsi de suite. Résultat, rien d'intéressant du tout

Par contre, drag&drop dans la fenêtre, ça fonctionne.
Il ne me reste plus qu'à changer la config de mon php histoire d'aller un peu plus loin (j'ai des fichiers de plus de 1Go) et ça pourrait peut-être remplacer mon Google Drive (où j'occupe déjà 4.2Go…)

Dans tous les cas je dirais que c'est encourageant, mais qu'il ne faut pas négliger la partie applications. Ha oui, et qu'une interface qui ne se recharge pas tout le temps serait beaucoup plus sympa.
Mais c'est intéressant.

ça, à part quelques cadres éclairés qui forcent les gens à rentrer chez eux, c'est clair qu'on t'interdira rarement de faire plus d'heure …

Ce que je voulais dire c'est qu'en général ça ne fonctionne que dans un sens : si tu es en retard (ou pas d'ailleurs) tu peux faire des heures en plus, mais si tu es réellement en avance parce que tu as mieux bossé tu ne peux pas partir plus tôt.

quand la petite boite pour laquelle l'IT n'est qu'une fonction support

Malheureusement je parle là d'éditeurs de logiciels, donc de boites où la création vient réellement du développement :-(

Les différences sont normales, ou plutôt peuvent s'expliquer : le premier exemple que j'ai indiqué utilise vraiment et de manière très propre la library closure alors que le deuxième bench est plus ancien et sur du code "de bench" moins propre et n'utilisant pas tout ce qui est à dispo (oui c'est dommage pour un bench).
Il faut bien comprendre que les outils Google donnent leur plein potentiel lorsqu'ils sont tous utilisés ensemble.
Et l'utilisation de la library closure permet, lorsque associée au compilateur, d'avoir des gains vraiment important. L'utilisation du compilateur seul est bonne mais on peut mieux faire.

Par exemple, jamais avec la lib closure on ne fait utiliser document.getElementById. Tout simplement car c'est un appel natif donc on ne peut pas le renommer. On utilise donc goog.dom.getElement. Et à la compilation c'est transformé en quelque chose de beaucoup plus court, comme c. Si on répète ça souvent et pour un peu tous les cas, on obtient des différences significatives.
Après ça va plus loin, certains comportement de la lib ou du compilateur sont là dans le but de créer des portions similaires afin de pouvoir mieux être compressées par gzip (qui utilise un dictionnaire).

Je peux pas faire une étude vraiment précise mais les meilleurs gains sont vraiment lorsqu'on utilise la totalité des éléments. Et par contre, dernier point de variation, la suppression du code mort peut expliquer de nombreuses différences. Si dans les deux codes j'utilise une lib, mais dans un cas j'en exploite 20% et dans l'autre 80% le résultat sera totalement différent. Dans le premier cas la compilation supprime 80% du code, dans l'autre seulement 20.

Malheureusement le prix n'est pas le seul problème. Parfois, trouver des bureaux suffisamment grand peut être un problème. Mais sur le fond, entièrement d'accord.
Et d'ailleurs, ce que je disais par "symptomatique d'un manque d'engagement et d'investissement" est plus vaste que juste l'espace et se retrouve, je pense dans ton "faire travailler quelqu'un à son plein potentiel dans les conditions dont il a besoin".

De la même manière que tout ceci, combien de personnes travaillant dans le dev on du matériel, comment dire, pas agréable voir trop vieux ?
Pour ma part il m'est arrivé d'être embauché pour faire des applis web … sans avoir accès au net. Ou plus globalement avec du matériel limite (qualité souris / clavier par exemple, et pourtant c'est pas le plus cher surtout pour la durée de vie) ou simplement écran. Là j'ai un 19" 1440x900. Et pourtant, quel confort d'avoir un écran d'au moins 21". Et franchement, c'est pas au prix de l'objet, surtout si on estime que les quelques euros investis vont être récupéré par un meilleur confort donc un meilleur boulot.

Mais voilà, on veut souvent faire à bas coup :-(

Tiens, ça me fait penser, voici un petit lien sur le même sujet : http://www.developpez.com/actu/42633/-Le-projet-de-loi-des-droits-du-developpeur-quelles-conditions-doivent-remplir-les-entreprises-pour-que-le-developpeur-puisse-reussir/

Enfin, à ce que je vois spring est plus ancien (ça vaut ce que ça vaut), permet tout ce que fais guice et plus et est plus "connu"… à priori, je vais rester sur spring ;-)

Je pense que c'est par contre deux approches différentes, même si l'objectif et les fonctionnalités sont les mêmes (enfin et que à priori spring est plus lent).

Que tu restes sur spring ne m'étonne pas vraiment :) En fait ma remarque "dev java allez voir" s'adresse essentiellement à deux types de dev java : ceux qui ne font pas d'injection de dépendances et ceux qui font du jee

En tout cas merci, j'aurai appris des choses sur spring avec tout ça :)

Ha mais j'ai quand même l'impression qu'il y a une grosse différence.
Dans ton cas tout est fait par annotation des classes / membres.

Dans Guice c'est possible avec @ImplementedBy et @ProvidedBy si j'ai bien compris ce que fait spring (voir http://code.google.com/p/google-guice/wiki/JustInTimeBindings)

Mais c'est une énorme différence avec la ligne que j'ai citée.
Le truc c'est que je peux très bien avoir un code, une lib, qui contient différents modules. Avec chacun des injections différentes. A mon code appelant de charger le bon module.
Je peux également avoir des injections "paramétrées" avec @Named par exemple (http://code.google.com/p/google-guice/wiki/BindingAnnotations). Et également de l'injection d'instances (http://code.google.com/p/google-guice/wiki/InstanceBindings).

Pour prendre un exemple réel. Voici la partie "lib" de mon code (bon ok, c'est pas purement réel mais c'est basé sur du réel) :

// Bind de l'interface Searches vers une implémentation directe (pas de cache des résultats)
bind(Searches.class).annotatedWith(Names.named("nocache")).to(SearchesNoCache.class);
// Bind de mon cache loader (guava) pour injection
bind(SearchesCacheLoader.class);
// Bind de l'interface Searches vers une implémentation utilisant le cache loader
bind(Searches.class).annotatedWith(Names.named("cache")).to(SearchesCache.class);

Dans mon code appelant, je peux injecter Searches et en l'annotant différement j'aurai l'une ou l'autre des implémentations.

@Inject
@Named("nocache")
private Searches searches;

// ou

@Inject
@Named("cache")
private Searches searches;

Et pour aller plus loin, je peux très bien avoir le fonctionnement suivant. Dans ma lib, j'ai deux modules différents :

Module nocache = new AbstractModule() {
  @Override
  protected void configure() {
    bind(Searches.class).to(SearchesNoCache.class);
  }
};

Module cache = new AbstractModule() {
  @Override
  protected void configure() {
    bind(Searches.class).annotatedWith(Names.named("nocache"))to(SearchesNoCache.class);
    bind(SearchesCacheLoader.class);
    bind(Searches.class).to(SearchesCache.class);
  }
};

Dans ce cas, il me suffit de choisir le bon module lors de la création de l'injecteur. Le truc c'est que la config peut être un paramètre, une variable système, une constante ou propriété au build, etc.
Et donc je fais mes profiles facilement en ayant un seul code de base mais un comportement totalement différent.

Injector injector = Guice.createInjector(needcache ? cache : nocache);
// ok, tant qu'à faire ce ne sera pas des variables mais on colle un new ici, ça sert à rien
// d'instancier à l'avance, mais c'est juste pour que l'exemple soit facile

(si je suis pas clair, n'hésite pas. Et si spring le permet ça m'intéresse quand même)

Je sais pas s'il existe une étude sur l'impact des openspaces sur la productivité.

Pour ma part j'ai souvent l'impression que l'open space est une mauvaise solution a un vrai problème. Enfin à deux vrais problèmes.
Il y a le problème de l'espace il est vrai. Vu certains loyers, pas toujours évident. Et un open space bien fait ça économise de la place. Bon après on pourrai aussi dire que c'est symptomatique d'un manque d'engagement et d'investissement.
Ensuite souvent le vrai problème c'est la communication. Et plutôt que de traiter le problème, certains se disent qu'en mettant tout le monde au même endroit va de fait résoudre le problème.
Moi ce que je vois c'est que même dans un open space, tout le monde se colle de la musique histoire de s'isoler. Et là c'est pire au final (enfin moi j'ai toujours - déjà au collège en fait - travaillé en musique, je ne supporte pas vraiment le silence alors la musique me permet de me concentrer) car la communication en pâti réellement.

D'ailleurs, je me souviens que pBpG avait un coup expliqué que lorsqu'il choisissait son team chez MS il ne regardait que les teams en bureau individuel. Pour ma part je n'ai jamais connus ça, et j'aimerais bien essayer un jour. pBpG, y'a pas des études là dessus chez MS ? Ou ceux qui bossent chez Google par exemple, je crois que c'est plus en open space, non ? (je prend les deux boites là en exemple car je me dis qu'il y a plus de chance d'avoir une étude chez eux que chez un éditeur de 50 personnes)

Tout à fait. Et c'est vraiment malheureux. Finalement en voulant forcer les gens à être performant et créatifs, ont a l'effet absolument inverse.

Mais la question est alors : comment faire pour changer ça ? Comment arriver à faire comprendre à ces gens que ce n'est pas la présence qui est importante, ni le nombre d'heure, mais le résultat final ?

Si quelqu'un ne vient que 5 heures par jour mais produit le résultat escompté, n'est-ce pas une très bonne chose ? Le problème c'est que dans des cas comme ça j'ai plutôt tendance à croire que l'administration va plutôt se dire : qu'il fasse 8h comme ça et ce sera mieux. Hors peut-être que le résultat provient du fait que la personne ne fait que 5h réellement productives et qu'en essayant de contraindre à plus on va faire baisser cette productivité au risque de passer en dessous de l'efficacité précédente.

note : je n'ai jamais utilisé spring, alors ce n'est qu'un ressenti et peut-être pas précis (mais je te laisse corriger si je me trompe, au moins j'apprendrai un peu plus sur spring)

Si je prend quelques comparaisons entre spring et guice (http://blog.octo.com/comparaison-google-guice-et-spring/ ou http://code.google.com/p/google-guice/wiki/SpringComparison) voici ce que j'en retire.
Déjà, l'xml de configuration plus je peux m'en passer mieux je me porte. Là, avec ma stack et guice je n'utilise même plus web.xml pour binder mes servlets / ressources, et c'est tant mieux.

Entre

<bean id="customerDAO" class="xxx.yyy.zzz.CustomerDAOImpl"></bean>
<bean id="customerService" class="xxx.yyy.zzz.CustomerServiceImpl"
  p:customerDAO-ref="customerDAO">
</bean>

et

bind(CustomerDAO.class).to(CustomerDAOImpl.class).in(Scopes.SINGLETON);

y'a pas vraiment photo de mon point de vue.

Après, si on prend le @autowired d'après les papiers de google ça semble parfois plutôt problématique, y compris niveau performances.

Maintenant, comme dit à un autre endroit, le truc c'est aussi que je me sert de Guice en dehors d'un contexte web. Et avec Peaberry. Donc c'est royal.

Et pour finir dans mon choix (ou non choix de framework comme spring) j'ai pris le parti d'avoir un assemblage propre et cohérent de composants plutôt que de partir sur un framework où je ne vais pas tout utiliser, ou les choix ne seront pas ceux que je souhaite, et où ne serait-ce que les performances vont en pâtir.

Le résultat de mon choix c'est, sur un serveur moyen, 7000 req/s avec 100 utilisateurs simultanés, là ou beaucoup, à fonctionnalité équivalente, arrivent difficilement à toucher les 4000. L'explication est pourtant simple : rien qui ne soit pas utile et des composants performants. Et hop !

tu peut créer tes bundle OSGi et les déployer sur jonas sans faire de réseau

Qu'est ce que tu entends par "sans faire de réseau" ?

Là je suis vraiment dans une archi distribuée, avec système de fichier et base distribuée (hadoop en fait) avec de multiples serveurs et de multiples services.

Tu entends quoi par RPC ?

Certains services embarquent un serveur RPC. Et d'autres, consommateurs, ont un client RPC. Et donc ça leur permet de communiquer entre eux facilement même en étant sur des machines diverses. Par exemple les frontend vont pouvoir demander, via RPC, à des services disposés sur des machines spécifiques d'effectuer des traitement et de retourner le résultat. Remote procedure call

Pour la partie file et règles, dans hadoop l'une des solutions et de gérer ça au travers de zookeeper. C'est assez puissant au final.

Je ne sais pas en regardant avec plus d'attention, je comprends mieux comment ça marche. Peut être que le fait que la moitié de certains exemples ne sert pas leurs idées n'aide pas. Par exemple :

Possible. Je dirais juste que ce qui est intéressant c'est vraiment de le tester.
Et si tu veux tester avec du web, voici un combo sympa :

• Jetty
• Guice
• Guice servlet
• Jersey-guice

Avec ça, tu as une stack qui te permet de faire du web, des servlets mais aussi du Rest tout en étant light et agréable. Le tout managé par l'injection de dépendance. J'avais fait une petite démo ici (https://github.com/CrEv/Taist) mais elle inclus aussi closure-templates donc c'est un peu plus complet (ha oui et il y a aussi du gson et du guava dans le lot). Ca peut donner une idée.

Sitebricks semble aussi assez intéressant mine de rien.

Ensuite pour Java EE, ne pas vouloir se fader un serveur d'application et se fader un Felix ou Equinox, c'est un choix.

Ben disons que c'est pas du tout pareil quand même. Felix (et OSGi) me permettent beaucoup de choses, entre autre des mises à jour des services à la volée. Ce n'est pas sur le même plan, OSGi n'a pas les mêmes buts, même s'il est vrai que ça rajoute parfois de la lourdeur (mais pas tant que ça je trouve)

les avantages des serveurs d'applications (si si il y en a, la configuration de datasources par l'exploitant par exemple).

Oué, c'est typiquement ce dont je ne peux pas me servir. JPA est inutilisable dans mon contexte par exemple. Donc on vire des gros avantages des serveurs d'applications.

c'est Jonas, qui mèle OSGi et serveur d'application

Ha oui, intéressant c'est vrai. Le truc c'est que je voulais que certains modules puissent s'exécuter aussi bien dans un contexte web que pas (par exemple pour certains modules métiers dont on à rien à carré qu'ils touchent au web, qui sont sur leurs propres machines et qui communiquent avec le reste en RPC (faut dire que le contexte c'est archi distribuée)

Ha tiens, ça ne fera qu'un bouquin de plus à mettre sur ma liste… :)

En fait c'est compliqué, je pense, de comptabiliser réellement. Et je ne suis pas sur que les heures sans être dérangé sont une bonne métrique (si jamais il y en aurait une).

Mais sur l'histoire de compter, je me souviens que dans certaines entreprise il est mine de rien très compliqué de leur faire comprendre que dans une journée de travail de 8h on ne peut pas placer 8h de codage pur. Déjà parce que le métier ne se résume pas du tout à ça. Et ensuite parce que c'est impossible d'être efficace et productif 8h. Alors lorsqu'on commence à parler de 6 à 7h (ce qui est tout de même illusoire) on voit que ça pose déjà problème. Leur faire comprendre qu'en réalité c'est 4 à 5h, et que pour être réellement productif il faut pouvoir s'échapper…

En tout cas être obligé d'attendre que tout le monde soit parti pour se sentir productif devrait être un signe d'alerte pour le management.

Pour ma part lorsque ça arrive c'est qu'il m'est impossible de me concentrer suffisamment avant (trop de bruit, trop de perturbations, …) mais parfois c'est plus complexe. C'est juste que le sujet demande pas mal de réflexion avant de se lancer dedans. Et donc après plusieurs heures à naviguer (en réalité tout en pensant au sujet finalement) alors la solution ou le débloquage survient. Par contre, ce temps aurait pu être bien mieux utilisé avec un peu de liberté. Genre une lettre à poster, dans la journée tu peux pas, même si tu tournes en rond. Et une fois arrivé le soir, alors que tu tiens la solution … ben non, faut partir poster la lettre avant que ça ferme. Et là tout le monde est perdant :-(

La principale chose que ça apporte déjà c'est que ce n'est pas JavaEE.
En fait le truc c'est surtout qu'on oublie ce truc ignoble qu'est JavaEE. C'est donc très facilement utilisable dans tout et n'importe quoi, pas que dans du web (et on oublie les serveurs d'application, on fait tourner ça dans du jetty qui poutre, on oublie glassfish qui fonctionne quand il veut, qui se debug mal et qui les brises, on fait des choses légère, on prend que ce qu'on veut et pas une stack énorme qui au final est typiquement overingeneered)

Après, qu'il y ait des ressemblances est normal étant donné que Guice est une implémentation de la JSR330 et je pense que dans JEE aussi, non ?
Par contre, il y a beaucoup plus de choses que juste l'implémentation de la JSR et c'est là où il se démarque.

Par contre, je suis surpris tout de même. En quoi les exemples de Guice peuvent faire peur ? C'est une vrai question car j'ai vraiment le sentiment inverse.

Et pour donner un autre avantage de Guice : là où je bosse on utilise beaucoup OSGi. Le problème c'est que à ce moment on se retrouve en quelque sorte avec deux injections. L'injection Guice (ou autre) et l'injection OSGi (avec iPojo - beurk - ou à la mano). Et là où Guice apporte un réel plus, c'est avec Peaberry. A partir de là tous mes services OSGi sont injectables exactement de la même manière que mon classes bindés classiquement dans Guice. Et c'est réellement vraiment pratique. Je trouve qu'on arrive enfin à partir de là à une utilisation potable de Java, beaucoup moins lourde qu'à l'habitude.

Prend des pauses (des vrais)

C'est malheureusement ce qui n'est pas toujours admis… (à vous entendre il y aurait pas mal de boites qui le permettent pourtant, étrange car c'est pas mon ressenti).

Je suis toujours surpris de voir ça. J'ai une TODO liste

Oui mais non :

Je cherchais quand même, j'étais pas en train de me promener sur facebook

C'était probablement mal dit, mais je ne me tournais pas les pouces tout le temps.
Mais parfois, tu es réellement bloqué sur un point. Et il n'y a pas autre chose (c'est pas une généralité, mais ça peut arriver). Et dans ce cas, étant réellement bloqué, ben tu continues a chercher. Et tu ne trouve pas. C'est ça que j'appelais "attendre".

Au contraire, il aurait réellement fallu que je puisse me barrer, aller faire n'importe quoi, et je serais revenu pour m'occuper de la solution.
Mais bon, au delà il y a très souvent un réel problème de confiance aussi.

Sinon si tu veux un retourd, là où je suis on doit faire 7h38 je crois de travail par jour.

Ok, j'ai pas du poser la question de la bonne manière. Combien de temps effectif. Productif. Est-ce plutôt 3h, 4h 5h ? C'est quand même rare d'être productif (réellement) plus de 7h par jours mine de rien.