Journal De tout, de rien, des liens, du vrac (mais moins bookmarks cette fois)

• # horaires et autres

  Posté par gaaaaaAab le 12 juin 2012 à 00:27. Évalué à 7.

  

  En parlant de postes, pour vous développeurs (enfin ça peut sûrement s'appliquer à d'autres) comment se passe votre temps de travail ?

  je ne rentre plus dans la case développeur, parce que je fais aussi d'autres trucs, mais je ne l'ai pas complètement quitté non plus, alors je réponds.

  Etes-vous contraint par des horaires strictes ?

  Théoriquement, oui, mais aucun "petit chef" n'a vraiment réussi à m'imposer de les respecter, et les "pas petits chefs", avec sagesse, me laissent tranquille :-)

  Horaire libres ?

  du coup, assez libre, mais ça reste dans une plage horaire "raisonnable", genre j'arrive avant midi (en gros entre 9h30 et 11h, tendance chaotique) et je pars entre 19h30 et 22 h 30 (hors amplitude exceptionnelle, je suis déjà arrivé avant 8 h, et parti à minuit).

  Finalement, dans quel cas êtes vous le plus productif

  à partir de 17/18 h, quand tout le monde s'est un peu barré et que je suis un peu tranquille. Comme je commence à être un vieux de la vieille, je passe pas mal de temps en traitement d'interruptions diverses et variées dans la journée. A noter que mon périmètre déborde un peu du côté de l'architecture, du coaching, de la discussion de spec fonctionnelles, voire de discussion sur les process en plus de tâches de dev.

  combien d'heures par jour de boulot ?

  variable. Certaines journées, ça veut pas. A ce moment là, je force pas, je fais le tour des bureaux, je papote, je m''auto forme ou je fais des trucs chiants mais nécessaires et je me barre tôt. Je n'ai jamais suffisamment observé pour faire de moyennes, mais à la louche, je dirais que je suis plus du côté de 4/5 h de moyenne que de 2/3 h.
  A relativiser par le fait que j'ai appris à compter les réunions/discussions ou on a parfois un peu l'impression de "ne pas travailler" comme du travail même si ça rentre pas dans la case "développement" ou si ça ne peut pas se justifier sur un décompte de temps.
  A noter aussi que je suis en temps partiel, et que du coup, ça densifie un peu les journées pour rester à peu près en phase avec ce que fait le reste de l'équipe.

  Concernant l'illusion d'avoir 8 heures productives en moyenne par jour, et la nécessité d'être comptable de 8 heures par jour, j'ai l'impression que les deux notes que tu cites enfoncent un peu des portes ouvertes. Il y bien que l'encadrement à la feuille excel et les couches hautes du management qui ne sont pas conscients de ça.

  • [^] # Re: horaires et autres

    Posté par CrEv (site web personnel) le 12 juin 2012 à 08:43. Évalué à 4.

    

    Merci pour ce retour, finalement ça va bien dans le sens de ce que je pense.
    Y compris sur la partie productive passé 17h. C'est d'ailleurs parfois assez frustrant, de passer la journée (quand tu dois faire tes heures et non avoir un résultat) à ne "rien" faire, pour finalement être productif et efficace juste avant de partir. Là on se dit que quelque chose cloche mine de rien…

    Concernant l'illusion d'avoir 8 heures productives en moyenne par jour, et la nécessité d'être comptable de 8 heures par jour, j'ai l'impression que les deux notes que tu cites enfoncent un peu des portes ouvertes. Il y bien que l'encadrement à la feuille excel et les couches hautes du management qui ne sont pas conscients de ça.

    Et pourtant… En fait j'aimerais bien pouvoir être de ton avis.
    Mais la réalité dans beaucoup d'entreprise est toute autre.
    Beaucoup d'entreprises donnent des contrats cadre aux ingénieurs et développeurs (c'est mieux pour le calcul des heures sup) mais obligent une présence physique minimum de 39h. Du coup, le côté gestion du temps et variation est pour le moins inexistant. Enfin si, tu as toujours le droit de faire plus d'heures que prévus.

    Et je ne parle pas des hautes couches du management, je parle aussi d'entreprises où il y a uniquement 3 niveaux de hiérarchie, donc assez peu de management au final.
    Mais pour beaucoup de monde encore, le développeur ou l'ingénieur plus globalement, doit forcément faire toutes ces heures d'un bloc. Et que contraindre à rester au boulot résous les problèmes (alors que j'aurais un peu l'impression que c'est l'inverse). Ha oui, et aussi que toutes les minutes (ou presque) peuvent et doivent être réellement productives.
    "Quoi, surfer sur le net, faire de la veille ? Nan mais bosse un peu à la place" est malheureusement très courant.
    En fait, souvent, cela vient de personnes qui ne connaissent pas le travail effectué, qui n'ont malheureusement pas vraiment idée de comment ça fonctionne.
    Et pourtant, l'organisation du temps de travail reste dans les prérogatives d'un cadre (au moins un minimum). Au final, on a une dualité assez particulière, néfaste (c'est au final moins productif et mauvais à moyen/long terme, y compris en terme de ressenti et d'image) et pourtant très courante.

    • [^] # Re: horaires et autres

      Posté par gaaaaaAab le 12 juin 2012 à 15:17. Évalué à 1.

      

      Enfin si, tu as toujours le droit de faire plus d'heures que prévus.

      ç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 …

      Pour rebondir sur les heures de présence, c'est vrai que je suis dans une structure assez grosse (quelques milliers de personnes) et dans un secteur d'activité technique. Je veux bien croire quand la petite boite pour laquelle l'IT n'est qu'une fonction support, la compréhension des enjeux de dév soit moins bonne.

      d'accord aussi pour dire que le dév est une activité créative, et, pour une part, artisanale même. Dans la situation que tu décris, c'est bien de savoir s'exprimer pour arriver à mettre les enjeux à la portée des non techos. A force de patience, c'est possible de les former/éduquer pour qu'ils appréhendent mieux comment formuler leurs besoins, ce qu'il peuvent attendre et dans quel délai.

      • [^] # Re: horaires et autres

        Posté par CrEv (site web personnel) le 12 juin 2012 à 15:22. Évalué à 5.

        

        ç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 :-(

        • [^] # Re: horaires et autres

          Posté par gaaaaaAab le 12 juin 2012 à 15:23. Évalué à 4.

          

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

          ha ben … mauvaise boite, changer boite ;-)

• # 0day sql

  Posté par ʭ ☯ le 12 juin 2012 à 08:12. Évalué à 4.

  

  Pour le 0 day, pas grand monde n'a l'air d'être concerné, en tout cas pas mes vieilles Mandriva serveurs ni les Mageia.

  ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

  • [^] # Re: 0day sql

    Posté par CrEv (site web personnel) le 12 juin 2012 à 08:44. Évalué à 3.

    

    Pareil, pourtant j'ai voulu testé, je me suis dit que j'allais enfin m'amuser un peu :)
    Mais non. Pffff !

  • [^] # Re: 0day sql

    Posté par yellowiscool le 12 juin 2012 à 08:54. Évalué à 4.

    

    Sur ubuntu 12.04 en x86_64 ça fonctionne. Ça doit faire un certain nombre de serveurs fraîchement installés.

    Envoyé depuis mon lapin.

    • [^] # Re: 0day sql

      Posté par mike.simonson le 12 juin 2012 à 15:29. Évalué à 1.

      

      Je ne sais pas ce que tu as installé mais chez moi ça ne fonctionne pas.
      ubuntu 12.04 en x86_64 mis à jour la semaine passée

• # Temps de travail

  Posté par barmic le 12 juin 2012 à 08:54. Évalué à 6.

  

  Souvent, au bout de quelques kilomètres je trouvais la solution. Alors je la notais pour le faire le lendemain matin.

  Au final, n'aurais-je pas été gagnant (et mon entreprise également) à pouvoir m'échapper un moment puis revenir avec la solution ?

  Prend des pauses (des vrais). Dans MiB3, l'agent K parle de « technique de la patisserie ». Tu te déconcentre et tu ouvre ton esprit à de nouveaux horizons. Mais ça marche aussi sans patisserie.

  Donc j'attendais en gros.

  Je suis toujours surpris de voir ça. J'ai une TODO liste des trucs que dès que j'aurais le temps j'aimerais bien faire sur le projet, longues comme le bras de trucs qui se font en une demi heure ou en 10 jours ouvrés. Si je bloque ou entre deux tâches j'en prends une dont le temps correspond à ce que j'ai et c'est parti.

  Sinon si tu veux un retourd, là où je suis on doit faire 7h38 je crois de travail par jour. On doit arriver avant 10h je crois le matin et rester jusqu'à 15h l'après midi je crois. Personne ne va venir vérifier si tu fais bien tout comme il faut. Moi je travail grosso modo de 8h30 à 17 ou 20h (généralement plutôt entre 18 et 19h) selon la charge de travail. Je prends 1h à midi sauf quand je prends plus (ça arrive de temps en temps).

  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • [^] # Re: Temps de travail

    Posté par CrEv (site web personnel) le 12 juin 2012 à 09:07. Évalué à 1.

    

    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.

    • [^] # Re: Temps de travail

      Posté par barmic le 12 juin 2012 à 10:05. Évalué à 3.

      

      à vous entendre il y aurait pas mal de boites qui le permettent pourtant, étrange car c'est pas mon ressenti

      Je n'ai travaillé que dans des grosses boites peut être que ça joue.

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

• # Injection de dépendance

  Posté par barmic le 12 juin 2012 à 09:14. Évalué à 3.

  

  D'ailleurs, pour ceux qui font du java, vous connaissez Guice ? C'est un système d'injection de dépendance vraiment bien foutu, développé par Google. De mon côté ça a complètement changé mon point de vue sur Java. J'ai enfin pu faire du java qui soit agréable avec ça et je conseil à tous ceux qui font du java d'aller voir d'un peu plus près.

  Je ne comprends vraiment pas ce que ça apporte face à ce que propose Java EE et l'injection de référence par anotation qui est je trouve très pratique. À chaque fois que je regarde les autres injecteurs, les exemples me font plus peur qu'autre chose.

  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • [^] # Re: Injection de dépendance

    Posté par CrEv (site web personnel) le 12 juin 2012 à 09:26. Évalué à 3.

    

    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.

    • [^] # Re: Injection de dépendance

      Posté par barmic le 12 juin 2012 à 09:56. Évalué à 4.

      

      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.

      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 :

      public class RealBillingService implements BillingService {
        private final CreditCardProcessor processor;
        private final TransactionLog transactionLog;
      
        @Inject
        public RealBillingService(CreditCardProcessor processor,
            TransactionLog transactionLog) {
          this.processor = processor;
          this.transactionLog = transactionLog;
        }
      
        public Receipt chargeOrder(PizzaOrder order, CreditCard creditCard) {
          try {
            ChargeResult result = processor.charge(creditCard, order.getAmount());
            transactionLog.logChargeResult(result);
      
            return result.wasSuccessful()
                ? Receipt.forSuccessfulCharge(order.getAmount())
                : Receipt.forDeclinedCharge(result.getDeclineMessage());
           } catch (UnreachableException e) {
            transactionLog.logConnectException(e);
            return Receipt.forSystemFailure(e.getMessage());
          }
        }
      }
      
      

      À quoi ça nous sert de voir l'implémentation de chargeOrder() ? En la retirant on sait mieux quoi aller voir et on comprends plus vite, je trouve.

      public class RealBillingService implements BillingService {
        private final CreditCardProcessor processor;
        private final TransactionLog transactionLog;
      
        @Inject
        public RealBillingService(CreditCardProcessor processor,
            TransactionLog transactionLog) {
          this.processor = processor;
          this.transactionLog = transactionLog;
        }
      
        public Receipt chargeOrder(PizzaOrder order, CreditCard creditCard) {
          // usage of processor and transactionLog
        }
      }
      
      

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

      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)

      Si c'est pour faire du web, web profile roxx des pandats roux. Le packaging est trivial et tu garde les avantages des serveurs d'applications (si si il y en a, la configuration de datasources par l'exploitant par exemple).

      Personnellement ce que j'aimerais bien essayer quand j'en aurais l'occasion c'est Jonas, qui mèle OSGi et serveur d'application (il est par exemple facile de virer des pants entiers de JEE).

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Injection de dépendance

        Posté par CrEv (site web personnel) le 12 juin 2012 à 10:08. Évalué à 3.

        

        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)

        • [^] # Re: Injection de dépendance

          Posté par barmic le 12 juin 2012 à 10:24. Évalué à 3.

          

          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.

          Là où je travail on utilise pas mal des datasources ainsi que les transactions, c'est assez pratique (mais je comprends que ça ne s'utilise pas partout et que ce n'est pas utile à tout le monde).

          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)

          Il faudrait regarder plus en détail, mais je crois que tu peut créer tes bundle OSGi et les déployer sur jonas sans faire de réseau.

          qui communiquent avec le reste en RPC (faut dire que le contexte c'est archi distribuée)

          Tu entends quoi par RPC ? Nous nous utilisons JMS pour ce genre de choses ça permet de faire de la répartition de charge (on a des files qui envoient vers différents serveurs) et de gérer la fiabilité (les messages sont « persistés » et on a un agent coté client qui renvoie les messages s'il y a eu un problème). Couplé aux transactions, on garantie que quand un message a bien était consommé il n'y a eu aucun problème lors de son traitement (sinon la transaction aurait était détruite (rollback)). On défini aussi des règles du type « si un message s'est raté 3 fois sur cette file, il est envoyé à celle là ».

          C'est très pratique au final.

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: Injection de dépendance

            Posté par CrEv (site web personnel) le 12 juin 2012 à 10:31. Évalué à 3.

            

            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.

            • [^] # Re: Injection de dépendance

              Posté par barmic le 12 juin 2012 à 10:54. Évalué à 3.

              

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

              Je voulais dire que rien oblige qu'il soit accessible, ni qu'il accède à des machines distantes.

              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

              Ok la grosse différence avec JMS c'est que l'un est synchrone et pas l'autre.

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: Injection de dépendance

      Posté par allcolor (site web personnel) le 12 juin 2012 à 10:36. Évalué à 2.

      

      Qu'est-ce que ça apporte par rapport à spring ? J'utilise spring depuis des années et ça me semble bien plus puissant et ça n'a pas besoin de javaEE.

      A première vue, je préfère largement les @Service et @autowired de spring que ce que je vois dans Guice…

      • [^] # Re: Injection de dépendance

        Posté par CrEv (site web personnel) le 12 juin 2012 à 11:11. Évalué à 3.

        

        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 !

        • [^] # Re: Injection de dépendance

          Posté par allcolor (site web personnel) le 12 juin 2012 à 11:37. Évalué à 3.

          

          Déjà, l'xml de configuration plus je peux m'en passer mieux je me porte.

          Tu peux t'en passer en spring (avec les annotations justement et l'autoconfig).

          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);

          Ben en spring je fais comme ceci:

          package xxx.yyy.zzz;
          @Service("monService")
          public class CustomerServiceImpl implements CustomerService {
             @Autowired
             private CustomerDAO customerDAO;
             ...
          }
          
          package xxx.yyy.zzz;
          @Service("monDao")
          public class CustomerDaoImpl implements CustomerDao {
             ...
          }
          
          
          public class MaClassQuiUtiliseUnService {
             @Autowired
             private CustomerService customerService;
             ...
          }
          
          

          Et dans l'xml spring, la seule chose que tu mets c'est ceci:

          <context:annotation-config/>
              <!-- pour chaque package que tu veux scanner -->
          <context:component-scan  base-package="xxx.yyy.zzz">
              <context:include-filter type="aspectj" expression="xxx.yyy.zzz.**" />
          </context:component-scan>
          
          

          Et c'est tout.

          En plus avec spring, tu as la gestion des transaction (avec les annotations @Transactional) et encore bien d'autres trucs très pratique.

          • [^] # Re: Injection de dépendance

            Posté par CrEv (site web personnel) le 12 juin 2012 à 12:00. Évalué à 3.

            

            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)

            • [^] # Re: Injection de dépendance

              Posté par allcolor (site web personnel) le 12 juin 2012 à 12:16. Évalué à 3.

              

              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.

              Pareil avec Spring, vu qu'il suffit dans la config soit de mettre des exclusions ou de scanner des packages différents, soit de qualifié l'annotation autowired/

              http://static.springsource.org/spring/docs/2.5.x/api/org/springframework/beans/factory/annotation/Qualifier.html

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

              Pareil avec Spring, tu fais un :

              @Service("cache") 
              ...
              @Service("nocache")
              ...
              
              

              et pour l'endroit ou c'est injecté :

              @Autowired
              @Qualifier("cache")
              ...
              
              @Autowired
              @Qualifier("nocache")
              ...
              
              

              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 ;-)

              • [^] # Re: Injection de dépendance

                Posté par CrEv (site web personnel) le 12 juin 2012 à 12:30. Évalué à 3.

                

                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 :)

                • [^] # Re: Injection de dépendance

                  Posté par barmic le 12 juin 2012 à 14:54. Évalué à 4.

                  

                  Moi je dirais merci à vous deux pour m'avoir un peu plus montré des techno que je ne connais que mal mais qui sont intéressantes :)

                  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

• # Durée du travail

  Posté par khivapia le 12 juin 2012 à 09:31. Évalué à 4.

  

  La véritable question du travail effectif n'est en effet pas le temps de travail mais le temps de concentration (body time vs brain time dans Peopleware, bouquin de management d'équipe de R&D que je vous recommande chaudement).

  Une mesure plus correcte que le simple reporting "à l'heure" pourrait être le reporting des heures où on a pu travailler sans être dérangé, c'est-à-dire des heures où on a pu se concentrer et le rester suffisamment pour être réellement à 100%, sans être dérangé par le boss, par un appel téléphonique, par le bruit ambiant d'un openspace, par l'appel général 'Mr Machin est prié de rappeler le 0101' etc. etc.

  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.

  • [^] # Re: Durée du travail

    Posté par CrEv (site web personnel) le 12 juin 2012 à 09:42. Évalué à 3.

    

    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 :-(

    • [^] # Re: Durée du travail

      Posté par Albert_ le 12 juin 2012 à 11:00. Évalué à 4.

      

      Le probleme c'est que la metric est faite par et pour l'administration. On a ce probleme a mon boulot et cela est n'importe quoi. La recherche continuel de la productivite tue la creativite et comme l'administration est passe de mode: "on est la pour aider le reste de l'entreprise a faire leur boulot" a un role "Garde-Chiourne", on va vers des extremes debiles.

      Du coup, la glandouille et la perte de temps sur internet se generalise et ceci explique aussi l'explosion des reseaux sociaux. Mais la presence physique est la et l'administration est contente.

      • [^] # Re: Durée du travail

        Posté par CrEv (site web personnel) le 12 juin 2012 à 11:16. Évalué à 2.

        

        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.

        • [^] # Re: Durée du travail

          Posté par Albert_ le 12 juin 2012 à 11:25. Évalué à 2.

          

          Le probleme, la ou je bosse, c'est le poid et l'importance de l'administration et surtout que cette derniere a totalement oublie ou change sa mission. En gros, l'administration a "hijacker" le pouvoir et s'attribue des competences qu'elle n'a pas et a cote de cela ne fait pas son boulot.

          Ex: cette semaine, je dois remplir avec mes collegues un papier pour une mission, la meme pour tout le monde, la seul difference dans le papier c'est le nom, on a chacun du passer 10 minutes a remplir le papier, a l'apporter a l'administration, qui devait remplir une autre partie et qui nous a demande d'aller chercher le papier(vi vi les secretaires ne se deplacent pas ici) pour nous dire de l'envoyer par faxe. Le meme faxe pour tout le monde. Si ca ce n'etait pas de la pur tache administrative je n'ai rien compris…
          Resultat, beaucoup de temps perdu et de l'enervement (car ca nous fait CHIER de faire ce genre de papier).

        • [^] # Re: Durée du travail

          Posté par djano le 27 juillet 2012 à 13:51. Évalué à 3.

          

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

          Ça c'est typique d'un management qui vit par et pour les chiffres et n'accorde aucune place a la créativité humaine:
          "You can't manage what you don't measure", ok, mais "Beware of what you ask, because you might well get what you ask for" :)

          Et la typiquement, s'ils mesurent la présence, ils ne faudra pas s’étonner s'ils n'obtiennent que la présence :)

          A contrario, je me souviens d'une boite qui faisait pointer les employés. Le jour ou ils ont voulu retirer les pointeuses, les employés ont protesté parce que du coup il allaient plus travailler :D

    • [^] # Re:Duréedu travail

      Posté par Juke (site web personnel) le 14 juin 2012 à 09:34. Évalué à 2.

      

      Genre une lettre à poster, dans la journée tu peux pas, même si tu tournes en rond.

      Ce genre de cas existe t-il vraiment ? Je veux dire dans les boites des linuxfriens, pas dans une usine Ford.
      Parce qu'en regle generale nous quand on a une lettre à poster (Are you from the past ?) on la descend au courrier et ça partira le lendemain, et quand c'est un colis à expedier on nous fait pas chier pour quelques minutes à la poste.

      • [^] # Re:Duréedu travail

        Posté par CrEv (site web personnel) le 14 juin 2012 à 10:05. Évalué à 4.

        

        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.

  • [^] # Re: Durée du travail

    Posté par palm123 (site web personnel) le 12 juin 2012 à 10:24. Évalué à 3.

    

    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.

    Remarque pertinente, mais hélas, je crois que le "management" (ton N+1) passe son temps à remplir des tableaux de bord et raisonne uniquement en temps filé à une personne. Tu as eu 50 h/ 3 mois/… pour faire cela, donc c'est terminé. Non ???
    Non.
    Tu as fait de la maintenance pompier sur des softs mal écrits/jamais terminés, ton voisin de bureau de l'open space hurle dans son téléphone (je l'ai vécu, j'allais me promener dans ce cas, j'ai du mal à me concentrer avec 90 Db), l'environnement de DEV/UAT/Nonreg n'était pas dispo, le soft dont tu avais besoin n'était pas encore installé par l'autre équipe…

    Comme je l'avais dit dans un autre post, dans les grosses structures, beaucoup de personnes passent leur temps à colorier des tableurs Excel (ou autre documents). Les informaticiens incompétents dont je parlais étaient IMHO des personnes tout à fait compétentes quand elles sont arrivées.

    ウィズコロナ

    • [^] # Re: Durée du travail

      Posté par mornik le 12 juin 2012 à 11:12. Évalué à 2.

      

      J'irai même plus loin.
      Pour justifier ta présence, ou la location du prestataire, on demande à chaque personnes de remplir un compte rendu d'activité ou chaque "activité" possède un code spécifique unique (donc écriture pour le projet toto = code 1, écriture sur le projet tata = code 3 etc ..)
      Toute ton activité doit être justifiée de la sorte. Résultat, si tu n'as pas de code, tu bosse pas. ça change rien pour l'interne qui sera de toute façon payé.

      Productivité 0, tableau des chef 1

      Parfois, ce n'est pas moi qui bosse, mais ma machine (j'suis con j'aime pas faire ce que la machine peut faire)
      Productivité 1, tableau des chefs 0 - car on va pas lui dire au chef qu'on a bien gérer la journée ;-)

      Mais c'est vrai que la productivité en prend en coup avec le bruit "des autres". Je sais pas s'il existe une étude sur l'impact des openspaces sur la productivité.

      • [^] # Re: Durée du travail

        Posté par CrEv (site web personnel) le 12 juin 2012 à 11:21. Évalué à 3.

        

        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)

        • [^] # Re: Durée du travail

          Posté par khivapia le 12 juin 2012 à 13:30. Évalué à 5.

          

          le problème de l'espace il est vrai. Vu certains loyers, pas toujours évident.
          Enfin même si le loyer est de 60€ du mètre carré (un très bon bureau sur Paris), s'il y a en moyenne 15m² par personne (c'est bien large, l'État voudrait réduire à 12m² en moyenne pour les fonctionnaires) ça ne fait jamais que 900€ par mois. À 4000 euros de dépense en salaire par mois pour la boîte (mettons 2000€ nets), ce n'est clairement pas gratter 10% sur l'immobilier qui va faire de réelles économies ! Il sera toujours plus intéressant de faire travailler quelqu'un à son plein potentiel dans les conditions dont il a besoin.

          • [^] # Re: Durée du travail

            Posté par CrEv (site web personnel) le 12 juin 2012 à 14:18. Évalué à 4.

            

            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/

        • [^] # Re: Durée du travail

          Posté par Croconux le 12 juin 2012 à 20:20. Évalué à 3.

          

          Il y a le problème de l'espace il est vrai. Vu certains loyers, pas toujours évident.

          Les loyers dans le centre des grandes villes, oui. Mais pourquoi vouloir a tous pris avoir ses bureau dans le coin le plus hype de Paris ? Il y a plein de place disponible dès qu'on s'éloigne un peu des centres. L'informatique est quand même l'un des rares métiers où on peut travailler de presque n'importe où. Alors pourquoi la plupart des jobs sont à Paris ?

          Ensuite souvent le vrai problème c'est la communication.

          Mettre les gens dans le même bureau abouti à l'effet inverse comme tu le fait remarquer. Ce qui est frappant c'est que cet argument est malgré tout avancé par les décisionnaires qui, eux, ont leur bureau séparé. L'open space c'est bien mais pour les autres, en somme.

          • [^] # Re: Durée du travail

            Posté par Axone le 13 juin 2012 à 09:38. Évalué à 4.

            

            Mais pourquoi vouloir a tous pris avoir ses bureau dans le coin le plus hype de Paris ? Il y a plein de place disponible dès qu'on s'éloigne un peu des centres.

            Les salariés aiment bien quand c'est au centre (de paris par exemple). L'accès y est facile en transport en commun de toute la banlieue. Si une boite déménage en périphérie, forcément, il y a des gens qui vont être lésés (temps de transport rallongés, desserte moins bonne, etc.).
            On mécontente une bonne partie des salariés.

            • [^] # Re: Durée du travail

              Posté par palm123 (site web personnel) le 13 juin 2012 à 20:21. Évalué à 3.

              

              Dans mon cas de parisien, l'avantage que je vois est que je peux donner rendez-vous à un pote et manger avec lui le midi. On fait au pire tous les 2 la moitié du chemin, et ça prend pas trop longtemps. Quand tu es trop loin, à moins d'un coup de bol (un pote dans la même banlieue), c'est injouable.

              ウィズコロナ

          • [^] # Re: Durée du travail

            Posté par khivapia le 13 juin 2012 à 11:09. Évalué à 4.

            

            Mettre les gens dans le même bureau abouti à l'effet inverse comme tu le fait remarquer.
            Il y a pourtant un compromis : plutôt qu'un openspace complet, mettre 2 à 4 personnes par bureau, en les regroupant selon les projets communs ; on a rarement vraiment besoin de parler très souvent à tout le monde !

            Ça a l'avantage de la bonne communication tout en gardant une bonne ambiance de travail (silence, calme).

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.