jhc_ a écrit 45 commentaires

Oui c'est clair :)

• la stacktrace est la même quoi qu'il arrive avec Coffee, donc aucune difficulté supplémentaire
• lire la traduction de Coffee :

Si on regarde les traductions :

eat food for food in ['toast', 'cheese', 'wine']

Devient :

var courses, dish, food, foods, i, _i, _j, _k, _len, _len1, _len2, _ref;

_ref = ['toast', 'cheese', 'wine'];
for (_i = 0, _len = _ref.length; _i < _len; _i++) {
  food = _ref[_i];
  eat(food);
}

Pour les trucs simples, c'est juste trivial :

if this.studyingEconomics
  buy()  while supply > demand
  sell() until supply > demand

Devient :

var lyrics, num;

if (this.studyingEconomics) {
  while (supply > demand) {
    buy();
  }
  while (!(supply > demand)) {
    sell();
  }
}

Mais cela ne va pas plus loin en terme de complexité. Peut importe ce que tu écris, ce n'est jamais à un ordre de complexité supérieur à celui-ci.

Bref j'en arrive à me dire que c'est une question subjective, je pensais que tes problèmes étaient plus complexe que cela, du genre de ce que tu peux trouver dans Jquery (encore que si j'avais à choisir, j'implémenterais en Coffee plutôt qu'en JS).

Pour ma part, en toute honnêteté je dois pas mettre plus de 5 secondes à trouver le coffee correspondant. Après, mon code ressemble pour deux gouttes d'eau à du Ruby, au sens où je découpe bien plus que du code JS habituel où c'est généralement la fête des callbacks dans tous les sens, cela doit peser dans la balance.

Après clairement, avec une source map, ce sera juste transparent et rendra l'adoption plus aisée.

Un minimum oui. Après tu n'as pas du tout besoin d'être un expert pour être à l'aise. C'est juste du javascript élégant et moderne. C'est sur qu'après si tu ne piges pas le javascript au point de paniquer devant une closure, c'est pas fait pour toi. Mais bon si tu en es là, c'est que tu es un débutant auquel cas autant éviter de rajouter une couche.

L'intérêt est justement d'avoir quelque chose de facile d'accès pour quelqu'un qui connait le js, pas d'apprendre quelque chose de nouveau et donc pas forcément évident à appréhender ( cf Clojure-script ).

Prenons le problème dans l'autre sens. Si pour coder en Coffee tu n'as pas besoin de connaitre JS, ça sous entend que tu n'utiliseras pas de librairies en Javascript. Adieu JQuery, Backbone et autres consorts. Tu n'utiliseras que des trucs en Coffe ou rewrappant du Js en coffee. Donc ça limite énormément l'écosystème tout comme l'adoption. Finalement, tu désignes avec ton affirmation que Clojure script a plus d'intérêt que Coffee.
Au sens théorique peut être, dans la pratique tu vois bien pourtant que c'est limité comme intérêt à l'heure actuelle. Oui tu peux faire du JS avec du clojure script sans piger une seule ligne de js. Mais niveau productivité tu es dans la merde et tu es dans une niche : l'intérêt est bien plus limité encore.

En gros, si tu connais js, tu peux pondre du Coffee. C'est un outil destiné aux devs web qui ont une base suffisante de js, il est là pour résoudre un problème simple, écrire du Javascript c'est chiant au point d'avoir besoin d'outils externes, genre JSLint. Là du coup, tu écris dans un truc simple à comprendre pour un dev web compétent et un minimum expérimenté. L'intérêt pour cette population à la taille conséquente est très net.

Effectivement si typer tes fonctions et des paramètres est faisable coté Coffee avec les mêmes commentaires, tu pourras pas typer toutes les vars intérmédiaires de coffee ( genre les splats ou ranges par exemple ).

Plus je comprends ton cas de figure, plus je pense que Coffee est pas adapté. Ca fait peut être trop de "bruit" par rapport à du js sur autant de code d'un coup.

Pour ce qui est des bugs potentiels et du debug, tu dois en effet avoir probablement une base de code bien plus complexe que nous, surtout si tu as autant de JS. Dans ce contexte là, je n'ai pas d'avis du coup.

Tu pourrais décrire un exemple de bug que tu rencontres ? Je suis curieux de voir si vraiment Coffee complexifierait le truc ou pas. C'est sûr dans tous les cas que ça décalerait énormément les numéros de lignes mais de toute façon tu t'en sers peu vu que tu te repères à la fonction plutôt qu'à la ligne, ce qui est beaucoup plus simple.

PS : thanks pour l'exemple sur le closure compiler, c'est plus intéressant que ce que je pensais :)

HS : je vais avoir l'air naif, mais j'y avais même pas pensé :) j'étais juste un peu surpris de voir mon comment plié comme un vulgaire spam sur reddit :) Thanks du coup :)

En effet, je n'ai pas détaillé le quasiment. Le cas le plus complexe que tu peux avoir c'est les => qui sont transformés en apply. Le switch case peut potentiellement devenir dégeulasse de mémoire. Mais rien qui s'approche de la soupe que tu peux obtenir avec Pyjama.

Conclusion, c'est quasiment tout le temps nickel, sauf parfois où c'est juste un peu moche mais jamais trop complexe à gérer.

Quand je debug, c'est généralement tout connement un truc à telle ligne, je regarde, je reconnais direct le bout de coffee en question, à la ligne près ou au pire, à la fonction vu que ça c'est pas transformé. Cela ne m'a jamais posé de problèmes.

Mes assets passe à travers https://github.com/sstephenson/sprockets ça concatène juste bêtement vu que j'ai pas besoin d'obfu en soit.

Pour Closure Compiler, j'ai googlé vite fait et effectivement cela ne semble pas parfait, mais ça marche vu que dans l'absolu du coffee c'est juste du JS. Après, je ne m'en sers pas donc je peux pas trop t'aider là dessus.

Le seul truc qui peut s'avérer chiant c'est d'incorporer Coffee dans le workflow de ton projet si ton framework le gère pas nativement. Rails c'est transparent, je suis certain que pour Django on doit trouver la même chose.

HS : C'est bien la première fois que je me fais moinsser sur Linuxfr (ok je poste peu), à part un désaccord (ce pour quoi moinsser n'est pas la réponse appropriée), j'ai du mal à voir ce qui peut expliquer ça. L'auteur peut il se manifester, que je comprenne ?

Je retrouve souvent cet argument en discutant de Coffee. S'il est valide pour quasiment tout ce qui compile en js, ce n'est pas le cas pour Coffee. Je t'invite vraiment à regarder plus en détail ce qui est compilé. Tu découvriras que c'est quasiment le js que tu aurais écris toi même à la main en étant rigoureux.

Pour faire un retour d'expérience, j'ai deux applications qui tournent avec des milliers de ligne de CoffeeScript et je n'ai jamais rencontré de problème au débug. Quand j'ai un truc qui foire, dans la console de chrome, je regarde la ligne, et je sais exactement en un coup d'oeil où c'est dans mon CoffeeScript. Nous sommes 4 à travailler sur cette base de code, dont un stagiaire et personne ne rencontre ce genre de problème. Il s'agit juste d'un tout petit effort mental, qui s'acquiert rapidement. La correspondance est, j'insiste, triviale à établir.

Par contre, les gains sont énormes, tellement ça évite les pièges habituels :) sans même parler du confort de coder avec.

Je te conseille fortement de regarder CoffeeScript.

Il s'agit d'une très légère couche syntaxique au dessus de Javascript qui :

• génère du Javascript lisible par l'être humain, à part deux trois constructions, tu as quasiment une correspondance 1 à 1 entre le Coffee et le JS
• apporte les compréhensions de liste comme en python
• supprime complètement les lourdeurs syntaxiques inhérentes au Javascript

Et surtout :

• Te protège des différents pièges du js, notamment les comparaisons avec les types qui font n'importe quoi.

C'est superbe completement a la masse mais superbe et bien caracteristique de l'education nationale qui ne regarde que son interet propre sans penser a ceux des eleves/etudiants.

Je te trouve un peu dur là. Et si il y avait une raison logique à présenter Scheme aux étudiants ? Et si des tas d'enseignants avait pesé le pour et le contre avant de proposer un tel choix ? Et si la raison d'être de Scheme n'était pas, par hasard hein, de tout simplement faciliter l'apprentissage de l'informatique ? Et pourquoi l'auteur a écrit un livre pour apprendre la programmation avec le scheme ? Ils sont cons ces gens là peut être ?

Je cite la page wikipedia de Scheme histoire d'étayer un peu mes propos :

Scheme follows a minimalist design philosophy specifying a small standard core with powerful tools for language extension. Its compactness and elegance have made it popular with educators, language designers, programmers, implementors, and hobbyists.

Avant de m'étayer sur les qualités pédagogiques du Scheme, prenons au hasard le cas du C, choix classique dans pas mal de formations.

Grosso modo, voici ce qui t'attends :

• La syntaxe est cryptique pour un débutant, il y a les ";" les "*", les "{}", les "[]" et les "()"
• Le langage est fortement typé, encore une notion de plus à aborder
• Il faut expliquer comment fonctionne la mémoire, hello malloc
• les trois quarts de tes étudiants se casseront les dents sur les pointeurs, tu viens de leur expliquer le principe de la variable que déjà tu introduis le concept d'une variable qui en référence une autre
• Créer un concept abstrait aussi simple qu'une liste requiert l'apprentissage de quasiment tout le langage : structures, pointeurs, allocation mémoire, ...

En gros tu vas te retrouver à présenter à des étudiants, qui n'ont jamais programmé de leurs vies, des concepts complètement nouveaux, le tout dilué dans une syntaxe rigoureuse bien assaisoné de notions d'architecture d'un ordinateur ( et pourquoi il faut compiler monsieur ? ).

Je te laisse imaginer le résultat final, tiré de mes propres expériences :

• Les geeks se baladent et dorment pendant ton cours car ils s'ennuient, ils se sont cassés les dents sur ces concepts bien avant. Note à l'examen : 20 et ils parent une heure avant
• Les bons élèves, à force d'acharnement finiront par y arriver et obtiendrons entre 12 et 16 selon les profils et l'assiduité.
• Les élèves moyens gratterons un 10 à 12 péniblement

On prend ces élèves, et paf le C++ l'année d'après. Là, c'est 10 maxi. Non pas que les élèves soit glands, c'est juste que si tu rajoutes l'aspect OO, les templates et autres joyeusetés, il te reste vraiment pas grand monde pour arriver à correctement assimiler toutes les notions aussi vites. ( Et là on arrive au java, super ya pu de pointeurs ! OLOLOOL eclipse ctro bien ! et il corrige même la syntaxe à la volée. Enjoy le java haut en couleur, pour alimenter DailyWTF ).

Concrètement, tu fais toujours face au même problème, les élèves sont des gens normaux, pas plus cons que les autres, ils sont tous capables de comprendre ( sauf exceptions ) des algos simples, des hiérarchies basiques, mais la moindre montée en niveau se solde par un échec.

Donc là, on soulève un problème pédagogique, et mon avis personnel sur le sujet est que tu as trop de bruit pédagogique. Trop de conneries syntaxiques, trop de conneries reliée au matériel dont ils se foutent complètement car ils ne deviendront pas forcément des développeurs acharnés, mais peut être des physiciens, biologistes, ou je ne sais quoi d'autre.

Maintenant tu débarques avec le scheme.

• La syntaxe est abordée très rapidement, simple à maitriser : (function arg1 arg2 ...), #f #t 123 "salut" et \a \b \c
• La récursivité et autres concepts abstraits fondamentaux sont abordés directement.
• Pas de types à gérer explicitement
• Le fonctionnel est plus logique mathématiquement, même si les étudiants ne s'en rendent pas compte
• On peut quand même aller voir des concepts bien avancés si le besoin se présente

Bref, quand tu introduis Scheme tu :

• permets aux étudiants d'apprendre les bases de la programmation
• mets de cotés les concepts inutiles en dehors de toute direction autre qu'informatique
• peux faire réfléchir des étudiants à des problèmes complexes, sur le plan algorithmique comme générer des grilles de sudoku avec différentes approches ( va faire ça en C, faudra déjà qu'ils compilent leurs projets sans fail de syntaxe, sans manger la mémoire sur une boucle foireuse )

Voilà, selon moi apprendre à programmer c'est plus intégrer un raisonnement, une approche, qu'aller faire semblant de coder en bricolant de la syntaxe et un tri à bulle. Après, il n'y a rien de magique, apprendre à programmer, ça reste un exercice complexe, si on pouvait éviter de paumer les gens sur les détails, ce serait pas mal non ?

PS : Et après le scheme, généralement vient le C et le C++ un peu plus tard dans le cursus, et cela se passe bien mieux, car les étudiants savent déjà ce qu'est une variable, une fonction et vont finalement pouvoir concentrer leur apprentissage sur la syntaxe, l'aspect impératif et la gestion de la mémoire tranquillement.

Euh oui, j'ai fait un abus de langage sur le "vieux".

Pour préciser :

Ca bouge généralement énormément sur l'écosystème Ruby / Rails, particulièrement ce dernier, qui a énormément évolué entre 1.X et 3.X.

Il a fallu un beau moment pour que Redmine bascule sur Rails 2.X, le code était peu refactorisé, tu pouvais trouver de nombreux exemples de mauvaises pratiques dans celui-ci, typiquement des gros controllers et des modèles tout fins, des choix en terme de design qui n'étaient pas forcément très judicieux.

Par vieux, j'entendais du code que tu peux aisément détecter comme à refactor rapidement pour délit de saleté, qui est resté bien trop longtemps dans cet état ( une belle collection de bad practices par endroits ). Typiquement, le passage à Rails 2.X était l'occasion de nettoyer par exemple.

Pour achever la bête :

L'auteur a focalisé son développement sur les fonctionnalités au lieu de plus passer de temps à refactor, pour éviter d'atteindre le seuil critique du chateau de carte.

D'ailleurs, ce point a été atteint vu que Eric Davis a quitté le navire.

C'est un peu couillon cette histoire, Redmine malgré un manque de polissage à mon goût coté ergonomie, propose pas mal de fonctionnalités intéressantes (et autant de plugins) d'où sa popularité, mais bon, le code crade, tu finis toujours par le payer.

Mais par contre j'ai vraiment des problemes de lenteur sur mes instances redmine, avec des serveurs tres corrects(ram,cpu,bandwidth) qui gerent tres bien d'autres applis web en php ou django.

Avec quoi hoste tu ton instance ( proxy -> mongrel, passenger, nginx, fastcgi ) pour que ce soit aussi lent que tu le décris ?

Par contre, si Ruby 1.8.X est pas clairement pas franchement folichon niveau perf ( heureusement que 1.9.X est là =) ) le coté sale du code implique souvent un code lent, donc méfie toi de ton estimation de la gourmandise de Redmine niveau resources quand tu compares avec tes autres applis :)

Il doit faire référence à celles là : http://www.ruby-lang.org/en/news/2008/06/20/arbitrary-code-e(...) massivement employée en pleine guerre de hype et trollwar Ruby / Python ya un an ou deux.

Depuis, c'est quasiment la paix sur Internet, même Zed est calme, on s'ennuie ferme :)

Pour moi le plus gros inconvenient c'est que c'est RoR/Ruby. Je n'aime pas parce que c'est lente, bourre de trous de securite, et surtout, je ne peux pas faire de modifications parce que je ne connais pas ruby. Malgres ca, je l'ai choisi et je ne regrette pas.

A l'époque où Redmine est sorti, effectivement, on peut pas dire que Ruby 1.8 était une fusée, c'était un peu lent, gourmand en mémoire.

Après, aujourd'hui, franchement, Ruby 1.9 + Rails 3, c'est franchement pas la même qu'avant, après, bien entendu, tu ne peux pas être au courant si tu ne codes pas avec ces outils là.

Ce que je veux dire par là, c'est que le raccourci Redmine est lent à cause de Ruby est un peu limite, c'est peut être Redmine lui même le responsable :)

Redmine est un vieux projet qui s'est baladé avec du vieux code obscur ou franchement crade pendant un bon moment, il y a pas mal de passages qui était carrément l'inverse de bonne pratiques recommendées habituellement. Cela a changé au fil du temps, doucement mais sûrement.

Après, ça fait un moment que j'ai changé de solution, je trouve l'outil bien trop "bloated" et il ne correspond plus à mes propres besoins ( Basecamp + Github aujourd'hui ).

Je ne comprends pas pourquoi tu opposes CoffeeScript et JQuery, il n'y a aucun rapport entre les deux. L'un est une surcouche au javascript, l'autre est une librairie, tu peux écrire du CoffeeScript qui se sert de JQuery de manière complètement transparente, vu que ton CoffeeScript sort du js, j'en ai encore écris hier.

A la base, c'est le truc qui m'emmerdait clairement le plus. Lors d'une mission en freelance quand j'étais encore étudiant où je refaisais le LAN d'une boite, j'ai pété un plomb car je me plantais tout le temps.

Il y a 3 ans, j'ai acheté un mac, séduit par le discours d'un pote dév vraiment talentueux, qu'on peut résumer à : tu t'en fous t'allumes ça marche et tu code, plutôt que de te faire chier à le maintenir. Et franchement, le clavier aujourd'hui j'adore, certes les trucs comme [] sont avec pomme maj 5 et ° mais c'est vraiment plus agréable pour coder, je me tords moins les doigts. Pareil pour |, pomme maj L, trois touches, mais plus simple à attraper. Jte parle pas non plus de @ qui est dispo directement, ce qui est franchement agréable, surtout si tu codes en Ruby où t'en as partout.

Enfin, la manière dont le clavier est fait, sa résistance, sa profondeur, me convient vraiment et je fais moins de fautes, en comparaison je garde un souvenir horrible des claviers DELLs biseautés.

git
zsh
screen

Comme écrit dans la news, c'est inspiré de Sinatra, donc typiquement simple et rapide à écrire, tant que tes besoins restent précis et bien déterminés. Après, n'ayant pas utilisé Dancer, je peux pas t'en dire plus.

Pour ce qui est du framework léger, personnellement, je trouve cela particulièrement efficace à maintenir, quand il s'agit d'un site qui remplit une petite paire de fonctionnalités, ou typiquement un webservice. Et c'est violemment rapide à écrire. Etant utilisateur de Rails et Sinatra, je réparti essentiellement en fonction de différent critères :

- est-ce que le site rempli une seule et unique fonction ? ( ex : un blog, ca stream juste des articles en opposition au dernier Facebook-like que ton client veut implémenter pour permettre à ses employés de s'échanger moultes stratégies business )
- est-ce que le site est touffu ? au sens des fonctionnalités, un blog avec des catégories, archive non, un blog avec intégration machin facebook, twitter, flux rss, gestion de pages façon CMS, multi-user => Rails
- est-ce que la personne a l'origine du projet est atteinte de featurite ( envie régulière et soudaine d'ajouter des fonctionnalités ) : le site va devenir vite un beau bordel, le code va tendre vers le point de rupture : le moment où je vais réécrire dans Sinatra des morceaux similaire à ce qui est fait dans Rails.

Honnêtement, les deux premiers points sont assez triviaux à déterminer une fois que l'on a joué avec le lourd et le léger, autant le troisième est assez particulier à appréhender. Le pire étant le moment où tu te dis, merde j'aurais du écrire ça en Rails ( ou Django, ou ce que tu veux, pourvu que ce soit lourd ).

Bref, c'est un peu comme tout, si tu te plantes d'approche, tu vas douiller, et tout faire avec le lourd, c'est faire un pas vers la médiocrité, vu que tu sauras jamais quand utiliser le léger et profiter de ses avantages. Faut prendre des risques, et accepter de se planter : projets perso/internes pour apprendre à choisir.

J'ai été membre de l'association en question pendant mes études, les membres partent deux fois par an en moyenne, au Burkina Faso quand j'y étais d'ailleurs.

Tu peux voir ici : http://wedus.org/presentation.html ce qui est fait grosso modo avec le matos, et pour avoir la partie plus humanitaire, tu trouveras ici tout ce qu'il te faut : http://eah.wedus.org/index.php?page=medias

C'est des gens sérieux, je me serais pas autorisé de venir balancer un lien vers une association à moins d'être sûr de l'engagement de ceux-ci.

Les centres restent actif et viennent se greffer à un réseau d'écoles et de différents centres installés par EAH.

Je réitère donc, c'est sûrement un des moyens les plus sympa de donner du matériel.

Tu peux donner ton matériel, même des vieux coucous ( pas le Pentium II quand même ) à l'association Wedus, qui repackage tout et l'envoit en Afrique pour monter des centres scolaires en Afrique.

Tu peux visiter le site là : http://wedus.org/

Ce n'est pas très à jour mais l'association fonctionne et part habituellement deux fois par an, à coup de container bourré de PC reconditionné. Ils vont d'ailleurs bientôt partir il me semble, j'ai croisé le matos sous plastique à bulle dans les salles où il stockent récemment.

Ça c'est l'effet Apple. Apple a une réputation de simplicité depuis des années (et ça n'a été qu'en s'améliorant), ce qui fait que les gens ont l'impression d'être débile s'il n'arrive pas à faire ce qu'ils veulent et se forcent donc. J'ai déjà vu des gens faire des trucs très compliqué sur mac alors qu'il trouvaient des opérations beaucoup plus simple trop compliqué sur Windows.

Peut être qu'ils ont simplement réussi ? S'ils arrivent à faire des choses compliqués qu'ils n'arrivaient pas à faire avant, c'est un signe de progrès non ? Corrige moi si je me trompe, mais la difficulté de la tâche est estimée par ton jugement, qui est différent de celui de l'utilisateur final non ?

Par contre, à propos de la réputation de simplicité, je pensais cela aussi, avant de m'amuser à exposer à ce genre de matériel des utilisateurs lambda. On m'a rétorqué souvent : "Mais c'est un truc de pro Apple, je vais jamais m'en sortir". C'est pas une vérité absolue hein, juste un retour d'expérience.

En quoi ça diffère avec Android?

Marché moins lucratif pour l'instant, en raison du taux de pénétration de l'iphone vis à vis des mobiles android. Et de l'incitation très forte à acheter des applications chez Apple.

Si c'était si pourri les Iphones, ça marcherait pas aussi bien non ?
Les end-users n'avaient rien avant Windows. Avant l'Iphone tu avais des dizaines de PDA différents, proposant toutes les fonctionnalités présentes. Tu compares un choix forcé à un libre choix. Néanmoins, cet effet s'estompe de nos jours ( ma mère à une Ubuntu et s'en accomode très bien ! ).

A propos des innovations.

Ma mère et mon père, sont tous deux équipés de PDA depuis des années de par leurs tafs respectifs. Donc, les fonctionnalités que tu décris sont couvertes depuis des années, en terme d'innovation technologiques. Mais le fait est que ni l'un ni l'autre n'ont pu utiliser ces fonctionnalités car c'était trop complexe, trop bordélique, trop "informatique".

Ma mère, tentée par le coté "féminin" de l'iphone 3GS et ses trucs arrondis a fini par en demander un pour changer son PDA. Ma mère arrive désormais à aller sur le net, elle a compris comment télécharger une application, elle se sert des pages jaunes en appli, du shotgun pour amuser ses commerciaux, bref : elle arrive à s'en servir.

Pour elle, c'est l'iPhone qui lui permet d'accéder à ces fonctionnalités. Mon père, plutôt technophile bricoleur, est équippé d'un HTC aux fonctionnalités touffues ( j'ai oublié le modèle ), se sert tout juste de son calendrier et envoit jamais de mail avec par ce que c'est la merde avec son stylet et son UI toute tassée. Il a joué avec l'iphone de ma mère plusieurs fois, il a installé des applications, et il est devenu fan de Instapaper ( qui permet de save une page web depuis ton navigateur pour la lire plus tard depuis l'iphone, avec un CSS façon noir sur blanc dépouillé ). Bref, il utilise le téléphone en entier, il m'a envoyé des photos par mail sans que j'ai à lui expliquer comment cela fonctionne. Avec son HTC, ce n'est jamais arrivé. Alors je pige pas trop comment il a pu ne pas y arriver avec le HTC, mais je me dis qu'un être humain et un power user, ça fonctionne pas tout à fait pareil, juste je constate.

Bref, autant l'un que l'autre, ont découvert des fonctionnalités qui existent depuis mathusalem. Mais une innovation ça peut être :

- Technologique ( les écrans LED, un nouveau scheduler, ... )
- Marketing ( l'app store, itunes ( player groupé avec la boutique, les applications Facebook )
- Ergonomie ( l'ui de l'iphone, les multi bureaux, etc ... )
- Pédagogique ( E-Learning par exemple )
- Méthodologique ( Dev Agile, TDD, et autres consorts )
- ...

Ici, sur LinuxFR il est clair que tout le monde entend innovation technologique. Mais faut bien comprendre que monsieur et madame Michu s'ils ont pas accès au truc parce qu'aucun produit n'est assez convaincant à leurs yeux, il n'existe pas. D'ailleurs, pour ma mère, le multitâche c'est un truc qu'elle trouve bien trop compliqué.

Conclusion, tout le monde ne fait pas des produits pour les powerusers, Apple ne fait pas d'innovation technologique, c'est tout autour qu'il le font.

C'est du business, ils sont là pour gagner du pognon. D'ailleurs, dans la vrai vie, rarement les choses se vendent au "juste prix", elles se vendent au prix que les gens sont prêt à mettre.

C'est pour ça que toi qui sais, tu prendras pas un Iphone. C'est aussi pour ça que moi qui sait aussi, je prends un iPhone. Je suis pas plus con qu'un autre, c'est juste qu'Apple a réussi à me proposer un système ou payer est si peu chiant pour avoir une application que je préfère le faire que jailbreaker et galérer. D'ailleurs, finalement, j'ai pris goût au coté pour madame michu : mon Iphone il fait pile ce que je demande, et il le fait bien et le prix me convient. D'ailleurs je peux aussi me faire du pognon en vendant des applications, c'est cool non ?

(C'est comme Steam d'ailleurs, j'ai acheté des jeux dessus, parce que c'était pratique et simple, flemme de pirater quand c'est aussi basique, par contre, ma Nintendo DS hum).

La finalité de ma réponse est simplement qu'il est question de point de vue. Je suis parfaitement d'accord avec toi sur la partie technologique, c'est du déjà vu de A à Z. C'est juste que c'est suffisamment bien foutu et innovant sur d'autres plans pour fonctionner sur le marché.

Pour les mêmes raisons, j'ai un macbook pro. Par contre, j'ai de l'unix sur tous mes serveurs, et tout je bosse qu'avec de l'open source, parce que j'aime ça.

Si c'était si pourri les Iphones, ça marcherait pas aussi bien non ?

Je serais curieux de voir le nombre de dyno / plan nécessaire pour faire tourner LinuxFR chez Heroku tiens.

Webrick est un serveur de développement histoire de pas avoir à installer apache sur ta box pour coder, personne hosterait quoi que ce soit sur ce serveur hein ( vu les perfs du trucs, faudrait être courageux ).

Passenger, ca mange de la ram, mais ça tourne bien du coup :)

Par contre, Redmine est lent, c'est pas une histoire de langage ou de framework, c'est juste que c'est un peu une usine à gaz ...

Tout à fait, c'est un pari que j'ai pris, et pour l'instant je ne suis pas déçu.

Après la notion de modulaire est la même qu'ailleurs, tu peux changer la RAM pour peu que tu vérifies que ça passe avant, un disque dur bah aucun problème, c'est le même que dans ton laptop. Une fois que tu as bouclé la garantie bien entendu. Tu trouves un paquet de pièces détachées , comme pour les autres laptops.

C'est un peu comme l'eternel débat Mercedes et ses pièces qui coutent cher, mais qui cassent pas, face aux Peugeots pas chère, mais qui sont susceptible de casser.

Non je change pas de télé tous les ans, il se trouve que ma télé je me promène pas avec tous les jours dans mon sac, je me pose pas dans des cafés, parcs.

Le macbook noir que j'ai vendu j'ai fait les 400 coups avec, et pourtant il a pas un pet.

Par contre, tu vois le DELL 640m que j'avais avant, au bout de 6 mois il était disloqué, avec du jeu partout. Pourtant, c'était trimballé dans une pochette. Et le Dell d'avant, il a tenu un an.

De quoi parles-tu justement ? NoSQL ? ORM ?

Oui, j'en ai vendu dans ma famille, le plus agé que j'ai 'revu' a désormais 3 ans, et se porte comme un charme, batterie qui tient 3h30 ( c'est un vieux macbook noir ).

Ce que j'essayais de mettre en exergue était que les macs en général, se revendent bien car ils ont une durée de vie supérieure justement.

Au risque de me faire taper sur les doigts.

Les macs, ya un avantage assez sympathique. Ca se vend cher. Tous les ans, après la fin de la garantie, je vends mon mac book pro. Le truc c'est que j'ai peu être eu du bol, mais après un an, ils sont comme neufs, c'est à dire batterie impec, l'écran qui bouge pas d'un poil quand je place sur un angle donné ( contrairement à un dell 620m qui a tenu à peine trois mois avant de commencer à avoir du jeu ). Donc je le vends avec un prix très correct par rapport à un PC classique. En moyenne, je dépense entre 300 et 400 euros par pour un investissement initial de 1500 euros pour m'acheter un mac book pro dernier cri.

Je fais régulièrement le crevard, tarifs étudiants avec les assos de mon école, et désormais achat avec ma propre boite pour gratter la TVA, mais le jeu en vaut la chandèle. Oui c'est pas très funky niveau engagement dans le libre, mais sincèrement, je regrette de ne pas avoir de meilleure alternative, surtout que finalement OSX est devenu mon OS principal ( bah sur ma workstation hein, sur mes serveurs, c'est propre, debian / *BSD selon les besoins ).

Résultat, chaque année, j'ai une machine neuve, ça me coûte pas si cher que ça à l'année sachant que je m'en sers pour le boulot ( je suis à mon compte ).

Après, d'un point de vue global, sachant que j'ai fait une école d'ingé, donc j'ai fréquenté une belle poignée de connards à laptops :), j'ose présenter ici ma conclusion, Mac c'est cher, mais franchement, ça vieillit bien mieux, modulo cas particuliers foireux. Mis à part les IBM increvables, j'ai rien vu d'aussi costaud que des macs.

Je me permets de préciser que j'étais avant un des premier à taper sur Apple pour ses prix prohibitifs, mais après avoir acheté un nombre incalculable de machines dans ma vie de geek, j'en suis arrivé à la conclusion que je me soucie plus de la finition, de la solidité de la coque, que des perfs, dont toute façon je me contre-tape, vu que je suis dev de métier, et pas gamer.

Moralité, si t'as assez de thune, achète un MBP, et fourgue ça sur ebay chaque année, tu perds peu par an par rapport à un DELL/IBM car notre pote Steve est une brute en marketing.