Share
C'est l'heure; mettre en file d'attente le thème "Going the Distance" de Rocky. Sur le ring rouge: Ryan Allen, le développeur extraordinaire d'Envato, qui a construit le FlashDen original avec ses mains nues et froides. Dans le coin bleu: Michael Wales, un membre bien connu des communautés PHP et CodeIgniter. La bataille? PHP vs Ruby. Bats toi!
Il est à noter que ce type de débat a un but purement ludique et éducatif. Il y a des moments où vous choisissez PHP pour un projet et d'autres fois où vous optez pour Ruby. Le but de cette série est cependant d'apprendre Comment et quand pour prendre ce genre de décisions. Plutôt que "votre langue craint," ces débats sont destinés à décrire Pourquoi vous pouvez, dans certaines situations, choisir l’un sur l’autre.
Ryan Allen est un ingénieur en logiciels et systèmes Web qui travaille pour Envato depuis toujours. Il a construit et supporté les premières versions des Envato Marketplaces dans Ruby on Rails, et s’occupe maintenant des systèmes Tuts +, entre autres choses..
Michael Wales est un développeur Web pour des agences du gouvernement américain et contribue activement aux communautés PHP et CodeIgniter..
Ryan: PHP a été l’un des premiers langages de programmation avec lequel j’ai travaillé (mis à part ActionScript et de très brefs Visual Basic). J'ai commencé à construire avec PHP en 2001. J'y travaillais presque exclusivement jusqu'à fin 2005, lorsque Ruby (et Rails) prenait sa place..
Michael: PHP était mon introduction au monde du développement Web, en 1999. Je voudrais donc dire que je comprends très bien sa position dans notre secteur, son histoire et la direction dans laquelle il se dirige. Ruby, comme beaucoup d’autres, a attiré mon attention avec la sortie de Rails et le succès de 37signals. J'ai une compréhension assez solide de Ruby, en tant que langage de script dans mes fonctions d’administrateur système (Capistrano), ainsi que de projets personnels et amusants (la bibliothèque de développement de jeux Gosu et Rails). J’ai honte d’avouer que je ne connais pas aussi bien les dernières versions de Rails et c’est définitivement sur ma liste de choses à me rappeler..
Michael: Malheureusement, je ne peux pas vous donner de réponse définitive, du moins pas ce que vous attendez, car PHP et Ruby sont deux bêtes totalement différentes. PHP est un amalgame de langage et de framework Web dans un seul paquet, tandis que Ruby est un langage de programmation avec de nombreux frameworks disponibles..
Si votre objectif est le développement Web et que c'est tout ce sur quoi vous voulez vraiment vous concentrer maintenant, je vous conseillerais certainement d'apprendre le PHP d'abord.
Donc, si votre objectif est le développement Web et que vous ne souhaitiez vraiment vous concentrer que sur ce projet, je vous conseillerais certainement d’apprendre le PHP pour diverses raisons:
En tant que développeur avec 12 ans d'expérience, j'apprécie les raccourcis apportés par Rails à notre industrie; mais c’est uniquement parce que je comprends ce qui se passe réellement dans les coulisses.
Si vous souhaitez devenir un développeur (développeur Web, script d’administration système, développeur de jeux, développeur d’API) qui comprend les concepts informatiques de bas niveau, la programmation orientée objet et, d’une manière générale, perfectionnez vos compétences en matière de pensée critique - cela va sans dire, commencez par Ruby, c'est un langage de programmation réel (rappelez-vous, PHP est un framework web déguisé en langage).
Du point de vue des développeurs Web, je pense qu'il s'agit également d'un des inconvénients de Ruby (et de Python, BTW): est-ce qu'il n'y a vraiment pas de? Niveau intermédiaire? point d'accès. Soit vous comprenez le protocole HTTP, avec la possibilité d'écrire votre propre pile, de haut en bas, ou vous allez avec l'un des "magiques", tenez votre main pour faire un framework CRUD-system?.
C'est vraiment le domaine dans lequel PHP brille. Si vous dépassez les limites de CRUD, vous n'avez pas besoin de comprendre parfaitement le fonctionnement d'un serveur HTTP pour concrétiser vos rêves..
Ryan: Si je devais enseigner à quelqu'un la programmation à partir de rien, je préférerais lui apprendre Ruby (problèmes de configuration des environnements de côté - bien que cela devienne plus facile). Une façon courante de démarrer quelqu'un (après peut-être des variables et leur impression) est d'expliquer les tableaux avec, par exemple, un exemple de liste de courses, prenez ce bit de PHP:
Accentsconagua
$ shopping_list = array ('Milk', 'Cheese', 'Hovercraft'); pour ($ i = 0; $ i < count($shopping_list); $i++) echo $shopping_list[$i]; Quand j'ai appris PHP, on m'a appris à utiliser les boucles for (comme je l'étais dans ActionScript), lorsqu'une boucle foreach plus succincte et moins sujette aux erreurs existait déjà (comme c'était également le cas dans ActionScript). Je devais tout apprendre sur cette chose $ i = 0, cette chose à tester et cette chose incrémentielle. C'était si déroutant! Le nombre de fois que j'ai foiré pour les boucles est indénombrable (sans jeu de mots). Voici à quoi ressemblerait la même chose dans Ruby:
shopping_list = ['Lait', 'Fromage', 'Aéroglisseur'] shopping_list.each do | shopping_item | met shopping_item end
Il y a beaucoup moins de syntaxe, et les itérateurs sont, à mon sens, beaucoup plus faciles à comprendre et à utiliser. Mais par souci de complétude, voici l'exemple PHP mais avec un foreach:
$ shopping_list = array ('Milk', 'Cheese', 'Hovercraft'); foreach ($ shopping_list en tant que $ shopping_item) echo $ shopping_item; Eh bien, ce n'est pas si grave en fait! Je pense que vous ne devriez utiliser que pour les boucles qui comptent jusqu'à 10, et ainsi de suite, car chaque lecture est tellement plus facile à lire et à enseigner et beaucoup plus difficile à berner. Et les itérateurs sont encore meilleurs, alors j'irais avec Ruby.
Ryan: Le point de vente pour moi (en 2005) était le cadre Rails. J'avais essayé le développement Web avec Python, mais étant inexpérimenté, j'avais un peu de difficulté, ne sachant pas quoi faire ni où regarder (mais j'ai réussi à construire certaines choses, alors prenez ça!), Mais je voulais vraiment J'utilise Python au jour le jour parce que j’ai eu l’impression que sa conception était meilleure, plus réfléchie et que j’aimais la syntaxe. Et parce que les serpents sont plus froids que les éléphants.
ActiveRecord était tellement incroyable!
N'ayant jamais travaillé en PHP avec autre chose que ADODB, et ayant échoué à faire un ORM plusieurs fois (je ne savais pas ce qu'était un ORM, mais je savais que je voulais quelque chose qui mappait les classes sur des tables de base de données), quand j'ai vu ActiveRecord pour la première fois c'était comme si tous mes Noëls étaient venus à la fois.
Je connaissais assez bien les bases de données relationnelles, mais j'en avais marre d'écrire le même code à plusieurs reprises. ActiveRecord était juste, tellement, tellement incroyable! Et Ruby était assez proche de Python. J'étais heureux en tant que Larry (quel qu’il soit) d’avoir un cadre qui me permettrait de travailler et de commencer à construire des choses. Donc pour moi c'était l'amour d'une bibliothèque et l'amour de la syntaxe.
De nos jours, nous avons des tas de bibliothèques Ruby étonnantes écrites par des individus talentueux, des bibliothèques telles que Sinatra (un framework web léger), Nokogiri (un analyseur HTML / XML), Sequel (une bibliothèque de base de données de haut niveau), RSpec (une bibliothèque de tests automatisés). Toutes ces bibliothèques sont installables en tant que RubyGems que j'ai trouvé beaucoup plus facile et convivial à utiliser que le système PEAR de PHP.
La communauté est encore assez dynamique, même quelques années après, et les entreprises recrutent des développeurs Ruby comme des petits pains. Apparemment, Ruby 1.9 est presque aussi rapide que PHP, il existe donc de nombreux arguments de vente.!
Apparemment, Ruby 1.9 est presque aussi rapide que PHP, il existe donc de nombreux arguments de vente.!
Michael: Je pense que c'est simplement une progression naturelle des développeurs (du développement Web à la recherche d'une connaissance globale des langages POO et d'une formation générale en informatique) en général - je sais que c'est la voie que j'ai empruntée..
Je pense que le plus grand inconvénient, à ce jour, est la pratique consistant à choisir une langue et à s'y tenir jusqu'à la mort. Ce n'est pas comme ça que le monde réel fonctionne.
Je me considère comme un? Développeur? - Par conséquent, la langue est une qualification ambiguë en tant que marque de télévision pour un vendeur Best Buy. Il y a des cas dans lesquels je choisis PHP (s'il existe un calendrier extrêmement court - en dehors de CRUD, c'est la langue dans laquelle je suis le plus familier), il y en a d'autres dans lesquels je sélectionne Ruby (déploiement via Capistrano ou CRUD de base avec Rails) et , encore plus loin, Python - que je préfère pour les tâches d’administration de serveur et l’analyse de divers fichiers.
Michael: Je pense que les développeurs peuvent très souvent se laisser prendre au «nouveau point chaud, vieux éclaté». engouement. C’est la raison pour laquelle mon équipe s’assoit toujours avant de commencer un projet, elle énonce les exigences (en termes d’utilisateur et de développeur - qui sont deux choses très différentes) et nous en discutons avec très peu de préférences de langage / framework. . La semaine dernière, nous avons analysé quelques Go de journaux de messagerie avec Perl. Cette semaine, nous avons construit une application dont la vue principale était un ExtJS GridPanel (car nous avons étendu les fichiers de base CodeIgniter qui gèrent toute situation qu'ExtJS nous envoie avec 3 lignes de code)..
Tout est question de combien de temps avons-nous et comment pouvons-nous produire le meilleur produit dans ce laps de temps?
Ryan: Absolument, certaines personnes (y compris moi-même) s'habituent à concevoir des choses d'une manière qui leur donne envie de ne pas réapprendre et de changer toutes leurs habitudes durement acquises. Une fois que vous êtes productif avec quelque chose, pourquoi voudriez-vous changer??
Une autre école de pensée est que plus vous maîtriserez les langages et les outils, vous pourrez combiner les meilleures techniques et idées, quel que soit l'environnement dans lequel vous travaillez (ils disent cela de l'apprentissage du LISP, mais je ne l'ai pas encore appris. ).
Les jeunes programmeurs vont sauter sur les nouveautés brillantes, mais à mesure que vous vieillissez et que vous êtes plus mature, vous voulez travailler avec de petits outils simples et robustes. Si vous n'utilisez pas toutes les fonctionnalités et toutes les bibliothèques disponibles dans Ruby, vous pouvez devenir simple et robuste sans trop de problèmes..
Un mot: maintenance.
Ryan: Oui, un mot: maintenance. Les projets logiciels ont tendance à nécessiter des modifications au fil du temps, et l'auteur initial du programme ne sera pas toujours la personne qui apporte les modifications. Supposons que les téléports soient inventés et qu'il existe une conférence mondiale sur Ruby et que chaque développeur Ruby compétent dans le monde y a sa place (téléports rock!). Supposons maintenant que la Terre est supposément une Terre du Milieu et que Smaug, le dragon, est plutôt contrarié par toute cette histoire de Ruby (les dragons préfèrent Python, voyez-vous) et décide de rendre visite à tous les développeurs, malgré tout. Maintenant, il ne reste plus de développeurs Ruby expérimentés dans le monde, oh mon Dieu! Maintenant, vous avez ce problème de ne pas avoir un pool de développeurs Ruby disponible pour travailler sur vos projets. Qu'est-ce qu'on va faire Gandalf?
Quand je choisis des outils, je pense souvent à qui va devoir maintenir le projet si je suis renversé par un bus (ou si ma moto tombe en panne, ce qui est plus probable).
Je n'écrirais certainement rien en Haskell, en LISP ou même en F #, car nous aurions de la difficulté à embaucher quelqu'un qui pourrait ou qui travaillerait dessus. La disponibilité du talent et du talent existant dans une entreprise influence alors beaucoup ma décision.
Dans un autre cas, j’envisagerais le libellé, à savoir si je vendais un produit, par exemple un CMS personnalisé vendu sur Code Canyon. Je ne l'écrirais pas en Ruby, car l'hébergement Web standard ne le supporte généralement pas. Alors que PHP est assez facilement disponible partout et que les concepteurs de sites Web et les programmeurs moins expérimentés le connaissent un peu.
Dans un autre cas, j’envisagerais le libellé, à savoir si je vendais un produit, par exemple un CMS personnalisé vendu sur Code Canyon. Je ne l'écrirais pas en Ruby, car l'hébergement Web standard ne le supporte généralement pas. Alors que PHP est assez facilement disponible partout et que les concepteurs de sites Web et les programmeurs moins expérimentés le connaissent un peu.
Michael: Voir mes réponses pour # 3 / # 4.
Michael: Personnellement, je recommanderais le framework Django pour Python. Il a été conçu dans cet objectif: permettre aux développeurs de travailler à la modélisation et à l'affichage des données à l'écran aussi rapidement que possible, avec des balises faciles à utiliser pour permettre aux concepteurs de présenter les données de manière élégante, pendant que les développeurs continuent. travailler sur les règles métier dans un cycle simultané.
Ryan: Si vous avez l'habitude de combiner HTML et CSS et de les télécharger via FTP, je vous recommanderais probablement PHP, car il présente peu de barrières à l'entrée car vous connaissez déjà sa métaphore (Wrap your code in .php extension! Allez-vous! Mais si vous avez commencé à prendre la programmation au sérieux, je vous suggérerais de vous diversifier et d'examiner d'autres éléments (tels que Ruby) pour élargir vos horizons..
Quand les choses tournent mal, votre manque de connaissances va revenir et vous piquer.
Souvent, je vois des programmeurs PHP travailler avec des bases de données relationnelles et comprendre très mal leur fonctionnement. Vous pouvez donc vraiment faire avancer les choses sans une compréhension approfondie des technologies avec lesquelles vous travaillez (vous utilisez rarement PHP seul), mais lorsque tout va mal, votre manque de connaissances vous reviendra et vous mordra. Combien de temps avez-vous à investir pour apprendre ces choses? Pouvez-vous demander de l'aide si vous êtes bloqué? Apprenez-vous PHP pour pouvoir travailler avec, ou juste pour vous amuser? Le choix est une question assez ouverte qui dépend de vos objectifs..
En ce qui concerne les terminaux, ils sont, en résumé, géniaux. Je les utilise tout le temps. Oui, ils ont une courbe d'apprentissage (mais qu'est-ce qui ne l'est pas?). Une fois que vous les maîtrisez et commencez à écrire vos propres petits programmes, vous ne pouvez pas continuer sans eux. Pour être honnête, l’invite de commande dans Windows ne m'a pas semblé très utile, mais une fois que j’ai opté pour un Mac et que j’ai eu accès à tout le divertissement * nix sous le capot, il est devenu plutôt productif..
Ruby a du battage, du dynamisme et du sex-appeal.
Ryan: Je dirais que Ruby a actuellement quelque chose que PHP ne fait pas, c'est du battage publicitaire, du dynamisme et du sex-appeal. Ruby est sans aucun doute sexy. Les femmes adorent ça. Les hommes veulent être comme ça. Godzilla le craint. Je suggérerais de rejoindre un groupe d'utilisateurs Ruby et de trouver un groupe diversifié de personnes qui aiment simplement coder, aiment créer des choses et la technologie en général. Quand j'ai commencé à rencontrer des gens de la communauté Ruby locale, c'était la première fois de ma vie je me sentais comme si j'étais avec mon peuple.? Honnêtement, je pensais être le seul programmeur de la planète à se soucier de leur travail jusque-là. C'était très rafraîchissant et j'ai beaucoup appris depuis, principalement des gens que j'ai rencontrés à travers ces groupes.
Voici un secret: si PHP publiait une mise à jour officielle avec une syntaxe alternative (plus semblable à Ruby / Python) et encapsulait la bibliothèque standard existante dans le style des bibliothèques Ruby populaires (et la rendait cohérente), et disposait d'une compatibilité ascendante et d'une capacité de intégrer avec le code hérité, ce serait un produit tueur. Ne dis à personne que j'ai dit ça.
Michael: Facilité de déploiement, introduction élégante aux concepts de niveau inférieur du développement Web et plus d'un siècle de documentation et de meilleures pratiques éprouvées.
Michael: Encore une fois - facilité de déploiement, introduction élégante aux concepts de niveau inférieur du développement Web et plus d'un siècle de documentation et de meilleures pratiques éprouvées.
Mais sérieusement - en raison de la faible barrière à l'entrée avec PHP, il peut être difficile de faire la différence entre quelqu'un qui sait vraiment de quoi il parle et quelqu'un du même niveau de compétence que vous qui disposait d'un domaine libre pour un blog. De plus, en raison de la grande ancienneté de PHP, il y a beaucoup de contenu - et tout n'est pas bon.
Ce n'est pas un problème unique de PHP - un coup d'œil rapide sur W3Schools.com détruira les rêves de tout promoteur de xHTML, JavaScript, CSS ou PHP.
Les développeurs PHP souffrent du syndrome non inventé ici.?
Il peut être très facile, lorsque vous apprenez une langue, de trouver ce que vous croyez être une ressource faisant autorité (qui pourrait être périmée ou tout simplement fausse) et de suivre en conséquence ce qu’elles enseignent? vous. C’est quelque chose que la communauté PHP a besoin de mieux pour - diffuser le "droit"? manière d'accomplir certaines tâches. J'admets que la communauté Ruby a l'avantage ici, Rick Olson a résolu l'authentification pour tout le monde lorsqu'il a publié le plugin Restful-Authentication. J
Les développeurs PHP, pour leurs premières années, souffrent du syndrome non inventé ici. - ce que je ne crois pas être une mauvaise chose (jusqu'à ce qu'ils commencent à le vendre ou à le transmettre à d'autres). Je pense que la mentalité derrière un nouveau développeur, connaissant PHP pour la première fois, est qu'ils veulent vraiment comprendre exactement ce qui se passe - et PHP fait un travail parfait en leur donnant suffisamment de corde pour se pendre. - assez révélateur pour apprendre, mais vous allez probablement vous faire mal. Considérant que, et pour ne pas négliger le plugin de Rick (qui est un système d'authentification génial), les développeurs de Rails sont prêts à assumer que ce gars-là a bien compris et qu'il continue son chemin.
PHP est devenu immensément populaire parce qu'il était au bon endroit au bon moment.
Ryan: Je dirais que PHP est devenu immensément populaire parce qu'il était au bon endroit au bon moment. Les alternatives pour le développement côté serveur nécessitaient à l’époque beaucoup de connaissances en programmation. Pourtant, de nombreuses personnes qui ne se considéraient jamais comme des programmeurs lançaient déjà des choses avec HTML et CSS. Après la même métaphore de déploiement et une compréhension de base de la création de sites Web, vous pouvez créer des programmes modérément utiles et les lancer sur un hôte Web partagé peu coûteux. Ou vous pouvez en télécharger un que quelqu'un d'autre en a créé et le modifier un peu parce que le code HTML et le code ont été mélangés.
Une autre chose qui a favorisé PHP a été l'essor de sites tels que le produit cPanel et les fournisseurs d'hébergement d'hébergement Web en étiquetage blanc. Chaque homme et son chien pourraient devenir un hôte Web à faible coût et sans aucune connaissance technique. Chaque homme et son chien souhaitaient un site Web et un hébergement bon marché. PHP et MySQL étaient standard sur ces configurations partagées, et ils étaient partout (et le sont toujours).
Les meilleurs ne «gagnent» pas toujours, beaucoup de gens sont toujours contrariés par la perte de SmallTalk par Java, bien que les personnes que j'ai rencontrées (des vétérans du logiciel sérieux) qui étaient présentes lorsque cela s'est produit se disent bien chez elles à Ruby.!
Ryan: Ce n'est pas très gentil, mais je dirais que les critiques courantes de PHP sont tout à fait valables et sont dues à la façon dont le? Langage? a été conçu (ou plutôt non conçu). PHP est né d’un certain nombre de scripts CGI écrits par l’auteur original en C (ou Perl?), Et le cas habituel de la raison pour laquelle PHP a fonctionné de la sorte était si? Je pouvais avoir un programmeur C écrivant des scripts pour le Web en seulement quelques jours?.
Je ne me rappelle jamais avoir demandé à un programmeur C de me créer une application Web!
Ruby, d’autre part, a été conçu pour tirer le meilleur de plusieurs langues afin de créer quelque chose qui était une joie de travailler avec, c’est inspiré de Smalltalk, Perl, LISP et d’autres, et cela se voit..
Une très grande différence entre PHP et Ruby pour moi est que Ruby vous encourage à travailler avec leurs types de données de base tels que Hashes et Arrays, où je ne les ai jamais trouvés naturels en PHP. Le nombre de fois où j'ai dû rechercher l'ordre des arguments pour String et Arrays en PHP est ahurissant.
Le nombre de fois où je ne me souvenais plus si telle ou telle fonction avait des soulignés ou non était tout aussi gênant. J'utilisais Zend IDE, je n'avais donc pas à m'en souvenir, mais je n'aimais pas l'IDE. C'était comme si vous étiez damné si vous agissiez et damné si vous ne le faisiez pas. Il n'y a pas de cohérence dans la bibliothèque standard de PHP et c'est frustrant pour un ours enragé dans une cabine téléphonique. En Ruby, je passe rarement du temps à documenter des types de données courants car les interactions courantes sont si faciles à mémoriser..
Une fois que vous aurez commencé à utiliser les fonctionnalités du module Ruby's Enumerable, vous vous demanderez comment vous avez pu vous en passer, rose, jure!
Michael: Je pense que cela reflète la faible barrière à l'entrée et la curiosité héritée des développeurs PHP pour vraiment comprendre ce qui se passe. J'avais lu / étudié des centaines de livres blancs, blogs, articles sur les systèmes d'authentification - mais ce n'est que lorsque j'ai créé le mien que je me suis vraiment senti comme si je savais ce qui se passait. Je crois que les nouveaux développeurs PHP sont impatients de partager ce qu'ils ont fait avec le reste du monde et sont souvent critiqués pour cela, parce qu'ils n'ont pas suivi les meilleures pratiques ou les modèles de sécurité éprouvés..
Michael: Je pense que PHP et Ruby ont tous deux de sérieux problèmes dans leur documentation - et pour des raisons complètement opposées.
PHP a une tonne de documentation, grâce à son ancienneté - vous pouvez trouver la réponse à n'importe quelle question en effectuant une recherche rapide sur Google. Est-ce la meilleure solution? Peut-être peut-être pas?
Rails grandit si vite que même moi, j'ai du mal à suivre.
Ruby a une excellente documentation, mais en réalité, cela semble être une question de cadre contre cadre, nous allons donc supposer que Rails. Rails a connu une croissance si rapide que même moi, j'ai du mal à suivre. La documentation de l'API Rails est excellente; mais lorsqu'il s'agit de documentation tierce (livres, articles de blog, réponses StackOverflow), elles sont toutes obsolètes et, si vous suivez ces informations, il est très difficile de résoudre le problème et de le résoudre..
À cet égard, je pense que PHP a l'avantage que les frameworks individuels (CodeIgniter, FuelPHP, Kohana, CakePHP, etc.) peuvent atténuer cet effet jusqu'à un certain point - si vous utilisez l'un de ces frameworks, il est simple d'aller chercher la réponse définitive pour ce que vous cherchez.
Ryan: Lorsque j'utilisais PHP, on a beaucoup insisté sur la qualité des commentaires dans la documentation PHP.net. La philosophie semblait être de «rédiger la documentation une fois et de laisser les gens ajouter leurs deux sous». Le problème, c’est que les commentaires sont présentés par ordre d’affichage, ce qui signifie que les bons commentaires ne filtrent pas vers le haut, et que les informations partagées dans ces commentaires n’ont pas été intégrées à la documentation en temps voulu (ou pas du tout)..
Une grande partie de l'API commune est incluse dans le noyau PHP, ce qui ne change pas souvent, alors je pense qu'une solution wiki serait plus appropriée. De cette façon, la communauté pourrait modifier la documentation officielle, suggérer des modifications, suggérer des exemples, intégrer les avantages tirés des commentaires à ce que les gens voient en premier. Cela serait utile (surtout pour un débutant).
Les cours sur Java renseignent d'abord les gens sur le polymorphisme et étudient ce qu'ils font: concevoir d'abord avec des hiérarchies de classes! Ça me rend fou!
Dans Ruby, de nombreuses bibliothèques couramment utilisées sont sur GitHub, où les utilisateurs peuvent soumettre de petites modifications et améliorations qui sont intégrées dans un cycle de publication généralement normal. La documentation est jumelée dans le code à l'aide de RDoc (qui est similaire à PHPDoc). Lorsque vous installez une gem, cette documentation est générée sur votre système local. Pendant la majeure partie de mon travail, je lirai soit la documentation principale sur rubydoc.info, soit localement sur ma machine, ou, le cas échéant, le code source des bibliothèques lui-même..
Nous avons entendu les pensées de Ryan et de Michael, et vous avez certainement votre propre opinion. Continuer le débat dans les commentaires!
