Twitter, Uber, Shopify… investissent dans les nouveaux MacBook Pro

Florian Innocente |

Les nouveaux MacBook Pro ont la cote dans certaines équipes de développement, comme en témoignent plusieurs ingénieurs sur Twitter. Ils s'enthousiasment de l'arrivée de ces machines et de leurs performances.

John Szumski, développeur chez Twitter raconte, que des MacBook Pro M1 Max chargés à bloc sont en train d'être déployés auprès de tous ses collègues spécialisés iOS et Android (il ne donne pas de chiffres sur leur nombre). Et d'ajouter qu'ils ont pu constater des « progrès à la fois dans les performances et la tenue en charge processeur », deux points qui posaient problèmes avec leurs Mac Intel.

Ingénieur chez Reddit, Jameson Williams, rapporte que les temps de compilation des versions Android de l'app du service ont été divisés par deux (cette tâche prend désormais un peu moins de 6 minutes avec ces M1). Là aussi ce sont des M1 Max avec 64 Go de RAM qui ont été achetés.

En prenant en compte les 9 personnes de l'équipe et la moyenne de 4 compilations quotidiennes pour chacune d'elles, il estime à 100 000 $ le gain annuel en productivité sur un an, en échange d'un investissement de 32 000 $ dans ces portables. Des temps de compilation nettement réduits c'est moins de risque de perdre le fil de ce qu'on faisait ou d'être distrait par autre chose, constate Jameson Williams qui promet de publier prochainement des observations plus détaillées.

Chez Uber également, des MacBook Pro 16" M1 Max à 64 Go sont en train d'être distribués à tous les développeurs iOS, nouvelles recrues incluses, précise Mahyar McDonald. Cette configuration pourrait devenir la norme pour tous ses collègues à brève échéance.

Et que deviennent les portables Intel remplacés par de l'Apple Silicon, eh bien les salariés peuvent les garder pour eux, déclare Robin Senior chez Shopify, où une commande des derniers Macbook Pro M1 a été passée pour tous les membres de l'équipe R&D.

Ces courts témoignages font également passer l'idée que fournir d'aussi puissantes machines aux développeurs est aussi une manière de les cajoler, on ne les équipe pas juste d'un portable comme un autre. Le responsable technique d'OpsLevel, Kenneth Rose, a rebondi sur ces tweets pour écrire que ses nouveaux ingénieurs recevraient également ce portable ultra-rapide.

Cela va dans le sens de ce qu'expliquait l'un des consultants Apple en entreprise dans un précédent article. Il arrive que des sociétés misent sur l'attrait du matériel Apple pour attirer leurs futurs employés.

Interview : confinement, télétravail… les leçons de la crise pour les consultants Apple des entreprises

Interview : confinement, télétravail… les leçons de la crise pour les consultants Apple des entreprises

Néanmoins il ne suffit pas de substituer une machine par une autre. Les opérations réalisées avec ces portables ne sont pas de la simple bureautique. John Szumski insiste sur le temps passé et les gros efforts consacrés à valider ces machines ARM ainsi que Monterey, avec toutes les parties concernées chez Twitter (responsables informatique, développeurs des outils, etc) : « Ça va plus loin que de simplement remplir un chèque ».

avatar fousfous | 

Même pour de la bureautique on gagnerait à ne pas être sur des PC qui nécessite un appel au SAV toutes les semaines...

avatar pocketalex | 

@fousfous

Dans mon ancienne boite, le remplacement du "petit" parc informatique, constitué de 100% de PC, par 100% de Mac a fait baisser le taux d'intervention du IT de 4h par semaine à 4h par trimestre...

Quant aux machines, leur remplacement est passé de 3 ans à 8 ans

Mais à part ça, les Macs, c'est plus cher 🤣

avatar zoubi2 | 

@pocketalex

Ben mon 'ieux... 😳

avatar YetOneOtherGit | 

@zoubi2

"Ben mon 'ieux... 😳"

On a des chiffres de retour d’expérience, allant dans la même direction mais moins extrêmes, de quelques grands comptes dont IBM

avatar rikki finefleur | 

pocketalex.
Ça j’aimerai bien avoir la description des interventions faites sur l'ancien parc et sur le nouveau.
Car pour avoir gérer plusieurs parcs c'est rarement l'os qui en cause.. Très rarement.
Mais plutôt des pbs d'imprimantes, des pbs logiciels, des pbs réseau, des défaillances hardware ... ou des boulettes de l'utilisateur :)

Or on va retrouver exactement ces pbs sur un autre OS.
Après effectivement si ta machine ne sert plus qu'à browser dans un navigateur , il est alors inutile d'acheter une machine chère vu que tu n'utilises plus du tout ses capacités.
Par contre dans le milieu du graphisme et de la 3D , beaucoup ont basculé sur du PC.

avatar YetOneOtherGit | 

@rikki finefleur

« Car pour avoir gérer plusieurs parcs c'est rarement l'os qui en cause.. »

Mais la personne qui gère le parc dans ce cas ? 🤣🤣🤣🤣🤣

avatar YetOneOtherGit | 

@rikki finefleur

« Par contre dans le milieu du graphisme et de la 3D , beaucoup ont basculé sur du PC. »

Tu mélanges deux milieux qui n’ont rien à voir :
- Sur le 3D CGI le Mac n’y a jamais eu une place sérieuse professionnelle. Le marché était en premier lieux sur des stations Unix type Silicon Graphics avant de basculer sur station de travail Wintel voir GNU\Linux.
- Pour le graphisme 2D le Mac y tiens une belle position historique qui est très loin de se démentir.

Après il est surprenant et assez illogique que tu évoques ces marchés de niche en commentaire à une actualité de ce type 😎

avatar YetOneOtherGit | 

@rikki finefleur

"Mais plutôt des pbs d'imprimantes, des pbs logiciels, des pbs réseau, des défaillances hardware ... ou des boulettes de l'utilisateur :)
Or on va retrouver exactement ces pbs sur un autre OS."

Ne nombreuses études de grands comptes ayant des parcs conséquents de Mac montre un gain réel de TCO 😎

Mais évidemment cela n’a que peu de valeur au regard de ton « expérience personnelle » 😄😄😄🤣

avatar rikki finefleur | 

Au lieu de troller comme une nouille, amènes des stats précises. ..
Pour avoir travailler sur des parcs comme edf qui ne sont pas des petits parcs, ils savent parfaitement le contenu des interventions..
Excuses moi , mais donner le chiffres en l'air comme le fait ibm sans aucun détail , c'est bon pour les commerciaux vendant des dépliants.
C'est sans doute pourquoi tu l'as repris comme bon commercial que tu es.

Enfin cher commercial, si les chiffres étaient aussi magiques qu'ils sont vendus, ne vous en faites pas que tout le monde serait passé sur mac, ce qui n'est pas du tout le cas en entreprise. Mais c'est sur les gens ne doivent avoir votre "expertise" commerciale. 🤣

avatar YetOneOtherGit | 

@rikki finefleur

"C'est sans doute pourquoi tu l'as repris comme bon commercial que tu es."

😂😂😂😂

Un « commercial » qui peut te donner des leçons de sciences informatiques pour que tu dépasses tes vagues compréhensions approximative de bricoleur du dimanche 😜

avatar YetOneOtherGit | 

@rikki finefleur

« Enfin cher commercial, si les chiffres étaient aussi magiques qu'ils sont vendus, ne vous en faites pas que tout le monde serait passé sur mac, ce qui n'est pas du tout le cas en entreprise. Mais c'est sur les gens ne doivent avoir votre "expertise" commerciale. 🤣 »

Si tu était capable de produire autre chose que des argumentum ad personam pour essayer de donner quelques corps à un semblant d’argument spécieux tu constaterait qu’au de ta vision manichéenne assez ridicule qu’une part conséquente des fortunes 500 possède aujourd’hui un parc important de Mac ce qui est un des grands succès de l’ère TC.

Ils n’y jamais eu autant de Mac en usage professionnel et ce dans toutes les tailles d’entreprises, jusqu’aux très grands comptes et cela ne cesse de croître.

avatar fte | 

@YetOneOtherGit

"Ne nombreuses études de grands comptes ayant des parcs conséquents de Mac montre un gain réel de TCO 😎"

Il serait intéressant qu’une telle étude soit réalisée à prestations équivalentes. Car ce n’est, pour celles que j’ai survolé, jamais le cas.

Là où les PC sont intégrés aux services réseau, profitent du déploiement automatique des applications, roaming, accès aux ressources administratives… les Mac sont laissés aux bons services des utilisateurs, et des clouderies. Les PC d’infrastructure sont considérés dans le pan d’étude PC, rarement dans le pan d’étude Mac.

C’est sûr qu’à prestations moindres, on abaisse certains coûts autrement importants.

J’attends de voir une étude qui ne soit pas lourdement déséquilibrée.

Quant aux machines pour la compilation et l’exécution des apps / simulateur / debugger, pour réduire le cycle de travail, il faut, qu’importe le système, du SSD rapide, rapide dans le sens beaucoup d’opérations par secondes, pas nécessairement beaucoup de GB par seconde, de la mémoire en quantité substantielle pour que la totalité des applications de production tiennent en mémoire, mon standard est 64 GB aujourd’hui, et des coeurs, dans cet ordre. La compilation étant incrementale, il n’y a pas de grosse contrainte sur le nombre de coeurs. Un équilibre raisonnable est bienvenu entre fréquence max et nombre de coeurs, afin de ne pas trop perdre en single thread. Les machines de build et tests automatiques ont par contre bénéfice à multiplier les coeurs car elles recompilent tout à chaque test automatique. Pas les postes de développement.

Ces MBP cochent toutes les cases importantes. Il n’y a pas tant de laptops cochant toutes les cases. SSD, pas un problème. Mémoire, c’est un problème. Si 32 GB n’est plus une exception, encore que ce ne soit pas la norme, 64 GB est loin d’être courant. Bien entendu sur une machine de bureau le problème est inexistant.

Après il faut considérer l’application développée et ses besoins. C’est un autre chapitre.

avatar YetOneOtherGit | 

@fte

"Quant aux machines pour la compilation et l’exécution des apps / simulateur / debugger, pour réduire le cycle de travail, il faut, qu’importe le système, du SSD rapide, rapide dans le sens beaucoup d’opérations par secondes, pas nécessairement beaucoup de GB par seconde, de la mémoire en quantité substantielle pour que la totalité des applications de production tiennent en mémoire, mon standard est 64 GB aujourd’hui, et des coeurs, dans cet ordre. La compilation étant incrementale, il n’y a pas de grosse contrainte sur le nombre de coeurs. Un équilibre raisonnable est bienvenu entre fréquence max et nombre de coeurs, afin de ne pas trop perdre en single thread. Les machines de build et tests automatiques ont par contre bénéfice à multiplier les coeurs car elles recompilent tout à chaque test automatique. Pas les postes de développement."

Sur la news ? C’est du flan en grande partie 😉

Ils se font plaisir avec de belles machines.

avatar YetOneOtherGit | 

@fte

"C’est sûr qu’à prestations moindres, on abaisse certains coûts autrement importants."

Là c’est assez discutable un TCO est un TCO et de plus chez IBM où le choix est laissé aux salariés le type de retours sur investissement produit par les salariés doit être assez équivalent.

avatar fte | 

@YetOneOtherGit

"Là c’est assez discutable un TCO est un TCO"

Un tco est un tco.

Mais si le t inclut plus de choses d’un côté que de l’autre, de l’infrastructure, voilà. T veut bien dire total… machine, maintenance, services, et infrastructure. Le déploiement d’applications en particulier est vite coûteux : installer, valider, packager, déployer, ressources locales et serveurs, rinse and repeat pour chaque revision… sans même envisager les dépendances. C’est sûr que laisser les utilisateurs faire le job, job réduit à son minimum, abaisse les coûts, d’autant que ce job est souvent considéré comme gratuit (comptabilisé sur les salaires d’autres départements que l’informatique). Plus de validation, plus de packaging, plus d’infrastructure de déploiement… quelques problèmes ponctuels certes.

avatar YetOneOtherGit | 

@fte

"Mais si le t inclut plus de choses d’un côté que de l’autre,"

Aucune importance pour une entreprise ce qui compte c’est toujours le rapport coût / bénéfice.

Si la productivité des utilisateurs de Mac est moindre ce serait un pb mais le périmètre des prestations pour atteindre cette productivité n’a. strictement aucune importance. 😉

avatar YetOneOtherGit | 

@fte

"Plus de validation, plus de packaging, plus d’infrastructure de déploiement… "

Donc des abaissements de coûts 🤑

Si l’utilisateur peut se débrouiller par lui même c’est tout bénéfice pour le TCO et c’est positif 😎

avatar fte | 

@YetOneOtherGit

"Donc des abaissements de coûts 🤑"

Qu’est-ce qui empêche d’adopter la même approche avec des PC ? Chacun installe ses apps, plus de roaming, plus de déploiement automatique d’apps… bref, ce que fait souvent une PME. D’ailleurs…

Et tu sais quoi ? Dans ce cas de figure les quelques TCO que j’ai croisé sont très similaires. Sauf sur un point : le coût de l’immobilisation d’une machine très supérieur chez Apple.

L’ultime stratégie de réduction du TCO étant le BYOD, en rejetant l’ensemble des coûts sur l’utilisateur. Il y a quelques boîtes de consultants mondialement connues qui ont fait ça.

C’est du marketing Apple, ces discussions sur le TCO.

Les réels TCO ne dépendent que fort peu du choix des postes clients. Les coûts sont sur l’infrastructure et les services. D’où les succès du cloud. Infrastructures et services mutualisés et dynamiques. Et des MDM.

avatar YetOneOtherGit | 

@fte

"Qu’est-ce qui empêche d’adopter la même approche avec des PC ?"

Sur la même approche sur des PC l’abaissement du TCO est semble-t-il moindre au regard des chiffres d’entreprises ayant les deux flottes sur des usages équivalents 😎

avatar fte | 

@YetOneOtherGit

"semble-t-il"

Je n’ai jamais vu d’étude de ce genre vraiment comparable. Avec Windows, j’ai toujours vu du serveur, ne serait-ce qu’Active Directory, en oeuvre, avec la nécessaire et incontournable redondance et backups associés.

Quand aux PME pour lesquelles je suis intervenu, la différence de coûts au final s’est systématiquement révélée similaire, mais je ne généraliserai évidemment pas.

Bref. Semble-t-il est approprié, je pense. Je n’ai pas de référence adéquate. Tu semble-t-il me laisse penser que tu n’en as pas non plus.

avatar YetOneOtherGit | 

@fte

" tu sais quoi ? Dans ce cas de figure les quelques TCO que j’ai croisé sont très similaires. Sauf sur un point : le coût de l’immobilisation d’une machine très supérieur chez Apple."

Sur les parc relativement conséquents Apple a aujourd’hui des offres de services du même type que les concurrents à des tarifs négociés attractifs.

https://www.apple.com/fr/support/professional/

Par contre sur toutes les études comparatives que j’ai vu les utilisateurs Mac s’en sortent mieux sans avoir besoin de demander un soutien que ceux de PC.

Et tu sais que je ne suis absolument pas un ennemi de Window 😉

avatar fte | 

@YetOneOtherGit

"les parc relativement conséquents"

Je parlais de PME. Pour ces entreprises, ça revient a avoir du matériel redondant pour pallier à l’immobilisation d’une ou plusieurs machines pendant une semaine ou deux, voire pire.

Le Mac Pro Poubelle et ses horribles cartes vidéo ont été une catastrophe de ce point de vue, avec des semaines d’immobilisation à chaque panne et souvent rebelotte avec les cartes remplacées mais ayant le même problème. J’ai une comptabilité de tristes records de passages au SAV avec ces machines.

Ca coûte très cher d’avoir une telle machine « au cas où ». Ou de bosser sur un iMac le temps que la vraie machine revienne.

Bref. C’est anecdotique. Ca n’a somme toute que peu de poids dans le budget total informatique, sauf pour les TPE.

"Par contre sur toutes les études comparatives que j’ai vu les utilisateurs Mac s’en sortent mieux sans avoir besoin de demander un soutien que ceux de PC."

On s’en fout. Si c’est l’utilisateur qui règle son problème, c’est pas les services informatiques, donc ça n’est pas comptabilisé dans le TCO.

C’est tout l’intérêt du BYOD, sous le couvert que chacun puisse choisir et utiliser les outils qui plaisent, c’est démerdes-toi. Tu as choisi un Mac, tu as choisi un iPad, tu as choisi Linux, assumes. Ici on ne supporte que les trucs sérieux, Windows, et encore, seulement si tu n’as pas trop foutu la merde. Combien de fois je l’ai entendu celle-là…

Mais je ne nie évidemment pas que les Mac ont probablement moins de problèmes. Mais c’est aussi souvent lié au fait que les services réseau sont réduits au minimum, et les imprimantes locales soit en AirPrint soit USB au lieu de serveurs d’impression, et également lié à la qualité globale des machines, avec des économies claires sur les laptops Windows. Dans mon labo par exemple, je peux imprimer sur la grosse imprimante relieuse depuis le PC, mais pas depuis les Mac. Je dois y aller avec une clé USB et imprimer directement sur la machine, 4 étages plus bas. L’installation d’Office sur les Mac, c’est à la mano par bibi aussi.

Bref. Mon point est que je pense (pense, avec arguments) que toutes choses étant égales, PC ou Mac clients sont dans le même ordre de grandeur de coûts. L’infrastructure cloud est identique. L’infrastructure locale lorsqu’il y en a est PC.

avatar YetOneOtherGit | 

@fte

"Je parlais de PME"

Ok j’avais pas compris ce cadre ici, là effectivement Apple ne propose rien et il n’y a quasiment plus de VAR

avatar YetOneOtherGit | 

@fte

"On s’en fout. Si c’est l’utilisateur qui règle son problème, c’est pas les services informatiques, donc ça n’est pas comptabilisé dans le TCO."

Tu plaisantes ?

C’est une réduction de coûts d’administration qui impact le TCO de façon positive 😉

Plus l’utilisateur est autonome meilleur est le TCO, c’est un élément clé de la réduction des coûts

avatar fte | 

@YetOneOtherGit

« Plus l’utilisateur est autonome meilleur est le TCO, c’est un élément clé de la réduction des coûts »

C’est ce que je voulais dire. Le temps perdu par l’utilisateur pour faire le boulot d’installation, pour régler les problèmes, n’est pas pris en compte dans le coût total, conduisant à une réduction du TCO.

Tu imagines bien à quel point la métrique est de fait foireuse.

avatar YetOneOtherGit | 

@fte

"Tu imagines bien à quel point la métrique est de fait foireuse."

Ca dépend, l’utilisateur lambda va rapidement perdre patience et appeler le support si la tâche est conséquente.

Je ne suis pas certain que le biais issu d’une perte de temps ou de productivité soit si conséquent.

avatar YetOneOtherGit | 

@fte

"Bref. Mon point est que je pense (pense, avec arguments) que toutes choses étant égales, PC ou Mac clients sont dans le même ordre de grandeur de coûts. "

Et c’est là où nous divergeons : un TCO ce n’est pas « toute chose égale par ailleurs » c’est un coût par poste. La seule chose qui doit être mise en regard c’est la part bénéfice face à ce coût.

avatar YetOneOtherGit | 

@fte

"Les réels TCO ne dépendent que fort peu du choix des postes clients. Les coûts sont sur l’infrastructure et les services."

Là tu parts sur une définition assez discutable du TCO qui sur un post client n’est lié qu’aux coûts directement liés au cycle d’exploitation de la machine et non aux infrastructures

avatar fte | 

@YetOneOtherGit

"Là tu parts sur une définition assez discutable du TCO qui sur un post client n’est lié qu’aux coûts directement liés au cycle d’exploitation de la machine et non aux infrastructures"

C’est une fausse vision. S’il y a des postes Windows avec roaming profiles, avec distribution d’applications, avec services divers, ils doivent être inclus dans le TCO. Sinon ce n’est plus du TCO, c’est du COCO (client only cost of ownership).

Le fait de ne pas à avoir à installer Multisim ou Autodesk sur mon PC est un confort que l’infrastructure me fournit.

avatar YetOneOtherGit | 

@fte

"C’est une fausse vision"

Nope c’est une des visions du TCO assez standard, tu peux élargir le périmètre mais là cela devient très délicat de fixer la limite.

Beaucoup de pratiques se limite au cycle d’exploitation de la machine et séparent ce qui relève du client et de l’infrastructure.

Je vais aller fouiller les doc de références et de normalisation 😋🤓

avatar fte | 

@YetOneOtherGit

"Beaucoup de pratiques se limite au cycle d’exploitation de la machine et séparent ce qui relève du client et de l’infrastructure.
Je vais aller fouiller les doc de références et de normalisation 😋🤓"

Volontiers.

Ici en pratique, banques, assurances, le TCO incorpore toujours l’infrastructure nécessaire pour Active Directory, pour les roaming profiles, pour MECM ou similaire et servers applicatifs, et les supports premier et deuxième niveau.

Ce qui est généralement exclu : les services bureautique - imprimantes locales ou centre d’impression -, le support troisième niveau. La connectique réseau est toujours exclue, à l’exception des éventuelles cartes réseau ou adaptateurs.

avatar YetOneOtherGit | 

@fte

"Ici en pratique, banques, assurances, le TCO incorpore toujours l’infrastructure nécessaire pour Active Directory, pour les roaming profiles, pour MECM ou similaire et servers applicatifs, et les supports premier et deuxième niveau."

Est-ce un particularisme Suisse ou pas ?

Blague à part le concept semble avoir comme souvent un périmètre assez variable effectivement 😉

avatar YetOneOtherGit | 

@fte

In fine tu recommanderais un parc de Mac conséquent à une major ou non ?

Car finalement là est la question

avatar fte | 

@YetOneOtherGit

"In fine tu recommanderais un parc de Mac conséquent à une major ou non ?
Car finalement là est la question"

HELL NO.

avatar YetOneOtherGit | 

@fte

"HELL NO."

Visiblement pas mal de décideurs ne partagent pas cette arbitrage et m’est avis que la position du Mac chez les fortune 500 ne va cesser de continuer sa belle croissance.

Le passage de quasiment tous les frontaux des grandes solutions professionnelles sur des approches web lève bien des barrières tout comme l’arrivée à des postes de responsabilité de décideurs n’ayant pas les vieilles haines contre Apple des générations précédentes.

avatar fte | 

@YetOneOtherGit

Alors, ma posture est celle-ci, pour quelques bonnes raisons.

La première est que lorsqu’il y a une possibilité de Mac, c’est très souvent que l’entreprise se converti au BYOD. Une partie des coûts informatiques sont reportés sur les employés, sans contrepartie. Certains s’en fichent, d’autres pas, mais c’est imposé à tous.

La deuxième est que fort peu de services support sont formés et que si assistance il y a avec les PC perso, pour un Mac la réponse classique est : oh, Mac, non, ça on fait pas, il va falloir vous débrouiller ou voir avec Apple.

La troisième est que c’est un calvaire d’intégrer des Mac dans une infrastructure métier sécurisée. On pouvait compter sur les couches UNIX pour s’en sortir assez confortablement - avec des compétences UNIX -, mais c’était avant Catalina, ou Big Sur, ou arm. La régression est conséquente de ce côté, et se poursuit.

Dans mon labo, il y a plein de Mac. Ils sont sur un réseau spécial peu sécurisé. Il y a un PC. Pour les tâches administratives, basiquement. Ou pour imprimer au centre d’impression. Réseau sécurisé. Les Mac en sont exclus. Et c’est moi qui doit m’en occuper et assurer leur bon fonctionnement. Y compris cette merde de macOS Server. C’est absolument officiel, les Mac sont fournis par les services informatiques (selon mes specs d’ailleurs, ils n’y connaissent rien), mais assorti du commentaire suivant : on n’intervient que s’il y a panne matérielle, le reste, votre problème. Il y a pourtant des Mac en respect de directives fédérales, ce n’est pas juste une fantaisie. Ce n’est ni dans mon cahier des charges, ni sur ma fiche de paie.

C’est classique.

Je ne généralise pas au monde. Mais je vais me permettre de généraliser à une majorité de grandes entreprises installées en Suisse romande, j’ai encore assez de contacts dans ce microcosme dans ma région pour me le permettre.

En bref, je ne dis pas que ce n’est pas possible. Je dis que la volonté de service n’existe pas, la volonté de former le personnel informatique n’existe pas, au contraire, la volonté de réduire les coûts seule existe. BYOD et démerdez-vous, ou PC miteux tout verrouillé.

Je ne trouve pas cela acceptable.

avatar YetOneOtherGit | 

@fte

Ce que tu décris correspond effectivement à un pan des réalités mais au final pourrait ouvrir à une discussion bien plus large : l’évolution forte des pratiques des entreprises quant à la gestion du parc informatique sur les postes clients.

La tendance est d’essayer de dépendre le moins possible de l’administration de ce poste client et de se focaliser sur le pan serveur.

Un retour finalement à une informatique centralisée s’appuyant sur les technologies web.

Cela change bien des choses et ouvre d’interessant espace aux Mac.

avatar fte | 

@YetOneOtherGit

"Cela change bien des choses et ouvre d’interessant espace aux Mac."

Absolument, je ne le nie pas. Mais au prix du déplacement de la responsabilité du poste client sur l’employé plutôt que les services informatiques, acquisition et maintenance.

Autant je suis OK avec la liberté de choix, autant je suis OK avec le déplacement des applications métier sur le serveur et le navigateur, autant je ne suis pas OK avec le transfert des coûts et de la maintenance sur l’employé.

avatar YetOneOtherGit | 

@fte

"autant je ne suis pas OK avec le transfert des coûts et de la maintenance sur l’employé"

Gauchiste 😜😉

Au regard de la qualité moyenne du support IT pas si loin de The IT Crowd ce n’est peut-être pas un mal 👿 😉

avatar YetOneOtherGit | 

@fte

Pour le reste il est quand même remarquable de constater la place que c’est octroyer le Mac chez les fortune 500 et le nombre de majors ayant aujourd’hui des parc conséquent de Mac.

Un des nombreux succès de TC 😉

avatar PiRMeZuR | 

Je ne travaille pas dans ces équipes et je n'ai aucune peine à imaginer que ces acquisitions valent le coup pour ces équipes mais je doute un peu des bénéfices dont ils parlent en pratique. Qui recompile tout de zéro pour tester une nouvelle ligne de son code ? Avec Xcode ou Android Studio, tout est incrémental depuis longtemps, et les tests sont normalement effectués sur serveur, éventuellement quelques fois en local sur la machine quand on en écrit un nouveau.

Donc calculer le retour sur investissement à partir du temps total de compilation, je trouve ça abusé. L'argument de l'attractivité me parait plus pertinent, beaucoup de développeurs sont fascinés par les performances brutes de leur machine, c'est un concours de celui qui a la plus grosse...

avatar Insomnia | 

@PiRMeZuR

Ça fait juste de la pub pour les marques 😁

avatar pocketalex | 

@ PiRMeZuR

il y a des zozos partout, mais les lead IT de chez Twitter, Reddit, Uber ... je sais pas, mais j'aurais tendance au premier abord à leur accorder un minimum de crédibilité

avatar YetOneOtherGit | 

@pocketalex

"il y a des zozos partout, mais les lead IT de chez Twitter, Reddit, Uber ... je sais pas, mais j'aurais tendance au premier abord à leur accorder un minimum de crédibilité"

On a des spécialistes qui connaissent visiblement mieux les pratiques de développement et de gestion du cycle de vie de ces entreprises que les responsables des dites entreprises 🤣🤣🤣🤣🙄

Visiblement ils n’ont pas la moindre idée des pratiques dont il est question et crois comme souvent que ce qu’ils font eux est universel.

TDD, CI/CD, AB Testing, cross-plateform, cycle de vie … connais pas.

avatar Tibimac | 

@PiRMeZuR

Théoriquement vrai, pratiquement faux. Si le code est bien modularisé et qu'on ne change pas le scheme de compil et que Xcode n'a pas décidé de tout recompiler sans qu'on comprenne bien pourquoi alors oui c'est vrai.
Mais par exemple mettre en commentaire une fonction dont sa signature et pas uniquement son contenu peut amener Xcode a "tout" recompiler car une signature de méthode a disparue.

Bref dans les faits il est assez fréquent d'avoir à tout recompiler, et d'ailleurs c'est peut-être de ces compilations dont il est question. Il est probable qu'il y ait par développeur plus que 4 compilations par jour, des petites et puis ~ 4 grosses.

avatar Nico_Belgium | 

@PiRMeZuR

Je bosse avec Xcode et je dois régulièrement (et beaucoup plus qu’une fois par jour) compiler l’intégralité de mon projet.

Le plus souvent pour combler une défaillance du dit outil mais tout de même..

avatar Florian Innocente | 
Le bonhomme de Twitter a ajouté ça par la suite :
avatar ErGo_404 | 

On parle de développeurs qui bossent sur des apps dont les temps de compilation sont monstrueux.

Typiquement ce sont des équipes qui sont obligées de développer leurs propres chaînes de compilation pour contourner les limites des outils standards, notamment sur Android.

Bref le besoin et le gain n'est pas le même que pour une app traditionnelle.

avatar cocotux | 

@ErGo_404

Pourtant Twitter ça semble pas insurmontable comme appli 🤣

avatar YetOneOtherGit | 

@cocotux

« Pourtant Twitter ça semble pas insurmontable comme appli 🤣 »

Essayes donc de t’y frotter avec les divers front (web, ios, android) et le back …

#yakafokon 🤩

Pages

CONNEXION UTILISATEUR