Reprise du message précédent :

si, ils seront moins chers et plus productifs (quantite) mais ca change pas le fait qu'il faille transporter ce qu'ils produisent chez le client et que ca prends du temps et ca coute cher.
 je dis pas que c'est pas interessant, je dis que pour certains produits les nouvelles techno vont changer la donne.

y'a toujours le léger détail de l'économie d'échelle.
 
Et surtout y'a toujours du transport, la grosse feinte avec certaine ville en chine c'est que t'as tout sur place et tu transportes que le produit final, maintenant vas gérer une chaine d'approvisionnement où tu dois transporter *tout* les produits entrants puis produire sur place et ne pas avoir à transporter le produit final. soit tu fait tout arriver avant la production, et t'as intérêt à avoir du capital et du stockage, soit t'essaye de tout synchronizer à arriver en même temps avant le début du batch. T'as pas intérêt à te rater, parce qu'à la moindre merde, tu bloques la chaine avec des produits semi-finis dessus pendant 3 semaines. Si t'es à Shenzen, tu cours au marché et tu retournes à l'usine, t'as perdu 2h de salaire des ouvriers, si t'es à Boston, t'as perdu 3 semaines (ou alors t'as dé-chargé la chaine en attendant, mais dans tous les cas c'est la merde.)
 
Parce que les billes de plastiques elles seront pas made in USA (hum en fait peut-être qu'avec les raffineries, c'est possible), les aimants non plus, les tôles au silicium non plus, le cuivre, les vis, écrous, l'alu extrudé non plus.

Le Eastpak, est léger.
 
C'est ce modèle: http://www.eastpak.com/uk-en/shoul [...] 0+999.html
 
Garanti 30 ans.

Et dans 10ans les ingés/chercheurs ils seront aussi majoritairement en Chine

 
ça me semble assez évident... Perso pour mes vieux jours, je compte même pas sur l'IT pour continuer à m'en sortir, mais bcp plus sur la culture et la musique. Enfin on verra bien... Je fais en sorte de garder toutes les cordes à mon arc en tous cas.

Ouais, d'ailleurs y'a 10 ans on prédisait que nos boulots disparaîtraient en Inde. Je crois que j'en rigole encore.

+1000 même si il y a 10 ans tu têtais encore le sein de ta mère

sinon ayet, ma moman a sa médaille. trop la classe

 
C'est pas faux non plus. Mais je trouve qu'il y a une acceleration maintenant au niveau des produits que la Chine arrive à produire sans nous. Le niveau de leurs smartphone par exemple est au niveau de ce qui se fait ailleurs. Ils sont en train aussi d'énormément progresser dans l'automobile, dans l'aviation etc...  Pas très rassurant quand même...

https://archive.org/details/Programm1984   un peu de prog from 1984

Mais bon le software c'est un peu différent.
J'ai bossé presque 5 ans dans la boîte qui sort deux flagships Android par an, une smartwatch tous les 6 mois, ...
Aucun concurrent ne dispose d'une telle intégration verticale et est capable de suivre ce train.
 
Mais au niveau du software c'est toujours une catastrophe; tu peux pas simplement mettre deux fois plus de ressources humaines sur un projet pour qu'il aille deux fois plus vite. C'est pareil dans l'industrie japonaise, ils sont à la pointe de plusieurs domaines mais leur software est souvent encore très mauvais.
 
Les développeurs chinois ont largement de quoi s'occuper sur le marché domestique, une mentalité pas très ouverte sur le monde, un accès à internet qui ne pousse pas à aller voir ce qu'il se passe ailleurs (et c'est de pire en pire).

 
+1, en soft on a encore de l'avance. Même si en fait ce que je remarque ce sont les Indiens/Asiatiques expatriés sont de plus en plus nombreux. Mais ce sont souvent ceux qui ont suivi un cursus directement en EU ou aux US.
 
Quand aux développements réalisés « in situ » (en Chine notamment), c'est pas ouvert du tout et niveau qualité c'est la catastrophe
 
Est-ce parce que faire du soft ça restera de l'artisanat et que ça « scale » pas comme du hard ? Peut être, je ne sais pas

http://robertkovax.com/protopiper- [...] tual-scale Intéressant.

Moi je m'arrête juste à de la vraie R&D en Chine, je maitrise pas HLM ou Muchacho  

Tant que suffisamment de clients continueront à demander des produits custom oui.
 
Mais il ne faut pas rêver : une grosse partie de l'artisanat fait ne l'est que parce que certains se refusent à utiliser les produits déjà existant qui correspondent. Quand tu vois le nombre d'applis internes dans certaines boîtes qui pourraient être remplacées par des CMS basiques ou du Alfresco, tu te dis qu'il y a de nombreux jobs de dev qui pourraient être supprimés. Ne parlons pas de déployer des solutions venant des éco-systèmes Microsoft, Oracle ou Apache qui proposent vraiment beaucoup de choses qui sont constamment réinventés pour rien.

j"ai l'impression qu'il n'y a que les USA qui savent pondre des soft complexe avec une bonne qualité. Même en Europe, à part peut-être les pays scandinaves, c'est souvent une catastrophe.

http://xkcd.com/1597/
\o/ je suis pas le seul \o/
 
je peux faire mon coming out alors:

Qu'est-ce que je viens faire dans cette discussion ?

 
\o/
 

en fait c'est pas tout à fait vrai, parce qu'avec stackoverflow, on trouve de plus en plus souvent la ligne magique à taper dans la console pour que git arrête de faire chier avec se tête détachée.

si c'est juste ça... quand tu commites sur une tête détachée git te dit ce qu'il faut faire comme commande  

Je sais pas comment vous faites pour vous retrouver avec des têtes détachées

nous non plus remarque

l'autre jour j'en ai eu une superbe: appcode me dit que git marche plus (WTF???) je vais voir en ligne de commande, il fallait accepter les conditions d'utilisation de XCode pour pouvoir utiliser git à nouveau.

 
J'ai un peu forcé sur les vidéos sur Facebook ce soir

Nan mais surtout ya rien de dramatique à être en detached head   ... autant flipper parce qu'on est pas sur la bonne branche à ce niveau là. Tu checkout un commit spécifique, t'es sans tête, rien de sorcier là-dedans. (d'ailleurs avec un bon client genre git extensions c'est vraiment simple ce genre de situations)

(quand je pense qu'egit est en partie développé chez nous, j'ai honte ...)

Sauf que tu commit en detached head puis tu changes de branche ton commit est perdu dans l'hyperespace et tu dois te taper le reflog pour retrouver où il est barré. Dans mercurial toutes les têtes sont "valides" et facile à lister, qu'elles soient nommées ou non, t'as jamais de detached head

c'est pour ça que git te sors un gros warning dans la gueule quand tu commit en detached head et te dit comment faire pour te ratacher, mais les gens ne savent plus lire, il faut dire que git est aussi trop verbeux...
 
du coup j'ai jamais compris pourquoi git n’empêchait pas de le faire, c'est quand même plus efficace que de mettre plein de warning. Les warnings c'est pas idiot-proof

Faut pas oublier que c'est Linus qui a conçu le truc.

 
Je trouve que c'est bien plus compliqué de faire des git rebase sans tout péter que de gérer des commits headless  

 
Puis un jour on te demande de mettre en place un truc servant à stocker des structures de software versionnant chaque élément. Et là, jour après jour les neurones servant à comprendre git sont réutilisés pour essayer de comprendre ce que tu fais et tu finis avec git fetch / git pull et rien d'autre  

C'est sans doute très simple, je n'ai jamais fait ni l'un ni l'autre. C'est cependant caractéristique de cet outil (avec toutes les autres linuxeries) de mettre sous le nez de l'utilisateur tout un tas de concepts certes simples (je te crois sur parole), n'ayant cependant aucun rapport évident avec le besoin qui justifie l'utilisation de l'outil, mais directement à voir avec son implémentation. C'est la philosophie de Linus : pour être libre il faut lire le manuel.

 
Nan mais c'est un outil de satan c'est clair Mais sur la très longue liste des trucs qui puent c'est clairement pas les commits headless le problème ils sont logiques au moins eux.
 
Autant y aller sur ses vrais défauts : la syntaxe débile des commandes, qui n'a aucune logique. Ya qu'à voir comment on gère les branches locales et distantes c'est jamais les même commandes, bravo le mec qui s'est dit que pour effacer une branche distance il fallait pousser la branche locale 'nulle' sur cette dernière. Pis le fait que git clone scale pas du tout dès que le repo est un peu sérieux niveau taille, pis les messages d'erreurs débiles du genre " 'merge' is not possible because you have unmerged files.", etc etc
Je fais tout en command line (linuxien here), sauf git que je refuse d'utiliser sans git extensions (ou sourcetree dans le pire des cas) tellement c'est laid  

autant que je sache quasiment toutes les personnes que j'ai pu croiser utilisent des versions graphiques, get extensions sur linux & co, turtoise git sous windows.
 
Rien que l'add de fichiers pour préparer le commit, ça saoul tellement en ligne de commande...

Ben pas forcément, tu peux rajouter en masse.
Tu fais un git status pour regarder les fichiers non ajoutés .
Et à partir du moment où tu as un .gitignore propre, tu peux faire ça :  
 

Tu fais ça sur mon projet je te défonce. Tous les devs ici doivent utiliser git add -p et git add -N, et interdiction d'utiliser git ci -m sans -e

Quelqu'un ici a déjà utilisé Mercurial sérieusement?
Parce que bon, git est pas super user friendly, mais ni Subversion ni Perforce me manquent...

 
Je ne crois pas qu'il y a plus de 50% utilisant un GUI dans mon entourage.