Ok....

Personne. Enfin Sony a annoncé un truc en début de semaine mais bon...

Ouais mais c'est PS4 only non?

nan, c'est complètement le moment. C'est juste suivre la mode de "tout sur le web".
 
J'en ai plein le cul de voir tous les outils qui marchent que sous windows, les installeurs dans tous les sens pour des logiciels qui tiennent très bien dans une page web. Y'a rien sous mac, les mecs sont tous à sauver des vieux PC de bureau sous win XP dédicacés à leur CNC.
 
Les logiciels de calcul de vitesse de coupe, les logiciels de calcul d'engrenages, les logiciels de gravure etc. Rien de tout ça ne nécessite un exécutable et un installeur, c'est juste une tradition.
 
C'est pas couillu, c'est juste rattraper un certain retard. Par contre ça veut dire que quand je développe, je joue avec des parcours d'outils et il vaut mieux pas trop se planter (enfin pour fêter 2014 j'ai installé un arrêt d'urgence sur ma machine, j'ai installé des boutons de fin de course aussi, mais j'ai pas encore eu le courage de faire l'électronique et le code).

Bouerf, Valve et le hardware... le seul truc qu'ils ont c'est leur manette de jeu et même ça apparemment ça enchante pas les foules.
Après oui, c'est clair qu'ils ont un coup à jouer, là.
 
C'est marrant, j'aurais pensé que les mecs à l'origine de l'Oculus iraient jusqu'au bout en montant leur boîte et tout. Vu l'engouement massif, c'était bien parti pour se faire des couilles en or. Mais bon, 2 milliards ça doit changer des points de vue aussi

Ouaip, ils auraient clairement pu se faire un gros nom dans le JV, à la Valve, mais aussi en dehors avec toutes les applications pro possibles ! Avant gardistes et seuls sur le marché, en quelques années ils avaient largement de quoi faire fortune et développer la VR dans une voie surement beaucoup plus "saine" que ce que FB pourrait faire ...

 
 
 
 
Ok....
 
1 : en IDE gratuit, y'a quoi? Pour info, la population de développeurs cible produit du code de mauvaise qualité en Java, malgré SONAR, les alertes PMD/Checkstyle dans l'IDE, etc.. Est-ce que c'est pas risqué de les faire partir sur du JS?
Quand on dit "oui, il y a", je veux bien, mais est-ce qu'il y a des retours d'expérience dessus, un peu? Ici, on a des mecs qui donnent des objectifs sur les métriques SONAR : on peut mesurer la qualité du code facilement?
 
 
2 : ok, je reste un peu dubitatif quand je vois les monstres d'IHM qu'on nous demande de pondre, mais je ferais des essais.  
 
3 : ok.. Donc pour monter une équipe de 10 mecs à pas cher et à qui on puisse faire confiance pour pas faire QUE de la merde, c'est encore tôt, quoi. (déjà qu'en Java, c'est pas possible, alors en JS..)
 
Autres questions :
 
4 : Modularité et isolation : une des forces de GWT dans notre modèle, c'est qu'on peut avoir sur la même page l'appli A, basée sur les widgets 1.2, et l'appli B, basée sur les widgets 1.3, tout ça parce qu'à la compil, GWT va prendre le code de la bonne version des widgets pour pondre le JS, et les JSs des applis A et B sont isolés (par nommage et par construction). Donc, si entre l'API des widgets 1.2 et 1.3, y'a des trucs qui changent, ça ne pose pas de problème. Idem pour les CSS, qui sont obfusquées et préfixées automatiquement par le compilateur, selon qu'elles sont apportées par l'appli A ou B. Vu qu'en JS, on n'a que les namespaces pour gérer ça, est-ce que ça sera possible facilement? (évidement, sans avoir à modifier le code au delà des différences d'API pour passer de widgets 1.2 à widgets 1.3)
 
5 : chargement différé : le code splitting de GWT permet en ajoutant simplement une instruction, de couper le code en 2 fichiers JS, dont le second sera chargé au moment de l'utilisation. Le compilateur se démerde pour déterminer ce qui est utilisé pas plusieurs fragments de code et le charger avec le premier (et en 2.6 ,il sait faire ça de manière "itérative" pour déterminer s'il est plus rentable de merger des fragments que d'ajouter un bout dans le fragment commun). Ca se fait facilement, ça, ou pas trop?
 
 
Pour le moment, on a une SSII qui nous a fait une appli Angular/Boostrap pour le mobile (on la récupère cette semaine)..  
 
La "stratégie mobile", pour le moment, c'est "on fait du Angular/Bootstrap/Phonegap parce que des experts nous ont dit que c'est le mieux" (dans l'absolu, pourquoi pas, je regrette juste que dans notre cas d'espèce, ils n'aient pas évalué la pertinence de mgwt/GWTPhonegap, vu qu'on a des compétences mutualisables), et "on aura une équipe dédiée au mobile, sans connaissance métier"... (A ce moment là, je comprends pas pourquoi on les fait pas faire à l'extérieur, mais bon)
 
Bref... Nous pend au nez la question du PDG : "pourquoi 2 frameworks?". Donc mon N+2 nous a demandé d'évaluer la pertinence d'une convergence de notre framework GWT vers ce genre de technos.. Evidemment, il ne veut payer ni des IDE corrects, ni des développeurs de top niveau (on recrute essentiellement sur sortie de stage, ou parmi les prestas. Les prestas étant d'un niveau très hétérogène, et on ne recrute pas forcément les meilleurs)
 
Vous noterez le rapport subtil entre la question du PDG, et l'idée d'évaluer les solutions GWT pour la mobilité.. .Mais bon, mon N+2 - qui ne connaît rien au dev - juge que c'est pas pertinent.
 
Any thoughts about all this shit?

Bon, Ghost c'est pas mal en fait. Un peu trop jeune tout de même, ça manque d'antispam pour aller en prod tout de suite.

Ah moi je pense pas ça, non.
 
Mais nos managers n'ont aucune idée du niveau des mecs, de l'absence de motivation assez générale pour les sujets techniques à la base, qui s'accroît avec la pression sur le pissage de code qu'ils leur mettent, et toutes autres considérations du même style.
 
Le top management, ils vont juste voir que "ouais, regardez, SSII ils ont fait un super proto de la mort pour la visionneuse de données médicales, alors que notre implem GWT elle est toute lente"
 
On a beau leur dire que côté GWT ça a été codé avec les pieds (le service d'accès aux données est appelé 5 fois de trop, par exemple... etc... Le tout est dûment répertorié dans les revues de code, que les équipes de devs ne prennent pas en compte parce que la resorption de la dette passe toujours en dernier).
 
Bref. Moi j'ai bien envie de m'y mettre à ces trucs là, pour voir.. Je vais essayer MGWT, aussi, pour pas mourir idiot.

Ah moi je pense pas ça, non.
 
Mais nos managers n'ont aucune idée du niveau des mecs, de l'absence de motivation assez générale pour les sujets techniques à la base, qui s'accroît avec la pression sur le pissage de code qu'ils leur mettent, et toutes autres considérations du même style.
 
Le top management, ils vont juste voir que "ouais, regardez, SSII ils ont fait un super proto de la mort pour la visionneuse de données médicales, alors que notre implem GWT elle est toute lente"
 
On a beau leur dire que côté GWT ça a été codé avec les pieds (le service d'accès aux données est appelé 5 fois de trop, par exemple... etc... Le tout est dûment répertorié dans les revues de code, que les équipes de devs ne prennent pas en compte parce que la resorption de la dette passe toujours en dernier).
 
Bref. Moi j'ai bien envie de m'y mettre à ces trucs là, pour voir.. Je vais essayer MGWT, aussi, pour pas mourir idiot.

Oh putain
 
C'est qui les concurrent d'Oculus déjà?

 
Il y a quand même une flopée de personnes qui affirment sans broncher que git c'est simple et que git ça marche et que git a des outils qui facilitent la prise en main au détriment du contrôle. Un peu comme Ubuntu pour linux, le concept du machin est absurde j'ai mis quelques années à le réaliser : Linux n'est pas fait pour ceux qui ne veulent pas comprendre comment ça marche. Globalement c'est contre ce discours que je m'insurge violemment.

 
 
Ok....
 
1 : en IDE gratuit, y'a quoi? Pour info, la population de développeurs cible produit du code de mauvaise qualité en Java, malgré SONAR, les alertes PMD/Checkstyle dans l'IDE, etc.. Est-ce que c'est pas risqué de les faire partir sur du JS?
Quand on dit "oui, il y a", je veux bien, mais est-ce qu'il y a des retours d'expérience dessus, un peu? Ici, on a des mecs qui donnent des objectifs sur les métriques SONAR : on peut mesurer la qualité du code facilement?
 
 
2 : ok, je reste un peu dubitatif quand je vois les monstres d'IHM qu'on nous demande de pondre, mais je ferais des essais.  
 
3 : ok.. Donc pour monter une équipe de 10 mecs à pas cher et à qui on puisse faire confiance pour pas faire QUE de la merde, c'est encore tôt, quoi. (déjà qu'en Java, c'est pas possible, alors en JS..)
 
Autres questions :
 
4 : Modularité et isolation : une des forces de GWT dans notre modèle, c'est qu'on peut avoir sur la même page l'appli A, basée sur les widgets 1.2, et l'appli B, basée sur les widgets 1.3, tout ça parce qu'à la compil, GWT va prendre le code de la bonne version des widgets pour pondre le JS, et les JSs des applis A et B sont isolés (par nommage et par construction). Donc, si entre l'API des widgets 1.2 et 1.3, y'a des trucs qui changent, ça ne pose pas de problème. Idem pour les CSS, qui sont obfusquées et préfixées automatiquement par le compilateur, selon qu'elles sont apportées par l'appli A ou B. Vu qu'en JS, on n'a que les namespaces pour gérer ça, est-ce que ça sera possible facilement? (évidement, sans avoir à modifier le code au delà des différences d'API pour passer de widgets 1.2 à widgets 1.3)
 
5 : chargement différé : le code splitting de GWT permet en ajoutant simplement une instruction, de couper le code en 2 fichiers JS, dont le second sera chargé au moment de l'utilisation. Le compilateur se démerde pour déterminer ce qui est utilisé pas plusieurs fragments de code et le charger avec le premier (et en 2.6 ,il sait faire ça de manière "itérative" pour déterminer s'il est plus rentable de merger des fragments que d'ajouter un bout dans le fragment commun). Ca se fait facilement, ça, ou pas trop?
 
 
Pour le moment, on a une SSII qui nous a fait une appli Angular/Boostrap pour le mobile (on la récupère cette semaine)..  
 
La "stratégie mobile", pour le moment, c'est "on fait du Angular/Bootstrap/Phonegap parce que des experts nous ont dit que c'est le mieux" (dans l'absolu, pourquoi pas, je regrette juste que dans notre cas d'espèce, ils n'aient pas évalué la pertinence de mgwt/GWTPhonegap, vu qu'on a des compétences mutualisables), et "on aura une équipe dédiée au mobile, sans connaissance métier"... (A ce moment là, je comprends pas pourquoi on les fait pas faire à l'extérieur, mais bon)
 
Bref... Nous pend au nez la question du PDG : "pourquoi 2 frameworks?". Donc mon N+2 nous a demandé d'évaluer la pertinence d'une convergence de notre framework GWT vers ce genre de technos.. Evidemment, il ne veut payer ni des IDE corrects, ni des développeurs de top niveau (on recrute essentiellement sur sortie de stage, ou parmi les prestas. Les prestas étant d'un niveau très hétérogène, et on ne recrute pas forcément les meilleurs)
 
Vous noterez le rapport subtil entre la question du PDG, et l'idée d'évaluer les solutions GWT pour la mobilité.. .Mais bon, mon N+2 - qui ne connaît rien au dev - juge que c'est pas pertinent.
 
Any thoughts about all this shit?

Et donc fb qui rachète oculus, ça peut pas être juste de l'investissement?

il vous faut un directeur technique.

Et donc fb qui rachète oculus, ça peut pas être juste de l'investissement? Genre Google avec Vuze, même si dans ce cas y a une corrélation directe.

C'est trop tôt pour le dire mais ce qui fait peur à tout le monde, c'est que FB personnalise le truc : besoin d'un compte FB pour s'en servir, interactions avec FB ("jean-michel a joué à EVE Online 15h hier" ), pubs et toutes les dérives y afférent, etc...
La com de Zuckerberg, c'était pour dire "on va mettre en place tout un côté social", genre assister à un match ou des cours sans quitter ta maison. Pourquoi pas, faut voir. Maintenant, fallait-il mettre 2 milliards sur la table pour concrétiser tout ça ? Stait pas moins cher d'acheter 100 kits de dev ? Bref, on verra quand des trucs concrets émergeront.

en plus le mec il s'appelle Zukerberg, et ces gens là pour qu'ils mettent la main au portefeuille, c'est sûrement pour une bonne raison, 'fin j'me comprends ...

C'est trop tôt pour le dire mais ce qui fait peur à tout le monde, c'est que FB personnalise le truc : besoin d'un compte FB pour s'en servir, interactions avec FB ("jean-michel a joué à EVE Online 15h hier" ), pubs et toutes les dérives y afférent, etc...
La com de Zuckerberg, c'était pour dire "on va mettre en place tout un côté social", genre assister à un match ou des cours sans quitter ta maison. Pourquoi pas, faut voir. Maintenant, fallait-il mettre 2 milliards sur la table pour concrétiser tout ça ? Stait pas moins cher d'acheter 100 kits de dev ? Bref, on verra quand des trucs concrets émergeront.

en plus le mec il s'appelle Zukerberg, et ces gens là pour qu'ils mettent la main au portefeuille, c'est sûrement pour une bonne raison, 'fin j'me comprends ...

Y a 2 choses: l'exclusivité de le techno pour le moment, et montrer que fb est toujours au top malgré les users vieillissants sur fb.

Et puis 2 milliard ok mais tout est pas en cash loin de la, le risque est limite pour fb.

Taiche> \o/ j'vais passer à la télé, j'appelle toute ma famille de Lille pour les prévenir \o/

en plus le mec il s'appelle Zukerberg, et ces gens là pour qu'ils mettent la main au portefeuille, c'est sûrement pour une bonne raison, 'fin j'me comprends ...

TIL: time -l (sauf que c'est chiant, sous zsh "time" est un builtin, faut explicitement invoquer le binaire)

Tu peux aussi choisir Confessions Intimes

git c'est relou. Mais c'est vrai que dans l'open-source ne pas avoir les features de github c'est relou.
Là je bosse avec une lib qui est sous SVN chez sourceforge, j'ai pas envie d'avoir les droits de commit, juste d'envoyer des patch, c'est relou.

alors que sur github, tu vois le fichier, tu vois l'erreur, tu cliques, tu corriges, et le mec est prévenu, il peut intégrer refuser ou commenter le changement direct.

 
En Open Source (je me répète un peu ) tu as GitLab qui est très proche de GitHub quand même

 
En Open Source (je me répète un peu ) tu as GitLab qui est très proche de GitHub quand même

Faut potentiellement passer explicitement par le binaire (/usr/bin/time). Les gros shell (bash, zsh, fish) ont un builtin time qui a pas -l (dash a pas de builtin par contre, ksh non plus apparemment)