Последняя книга Марка была просто
опубликовано Аддисон-Уэсли
Я давно слышал, как Марк Бейтс был отличным оратором, но только в марте на собрании Boston.rb у меня был шанс узнать это сам. Он сделал отличную презентацию под названием « Тестирование многофункциональных клиентских приложений с помощью Jasmine» , о том, как использовать Jasmine и другие инструменты для тестирования веб-приложений, использующих CoffeeScript на клиенте. Это было информативно, интересно и заставляло думать. Несмотря на то, что я был опытным разработчиком Ruby, я никогда не тратил время на то, чтобы правильно использовать CoffeeScript в своих приложениях. Но слушание Марка и его примеры вдохновили меня; Я подумал про себя: «Это то, что мне нужно изучить и использовать как можно скорее».
Несколько недель спустя я был взволнован, когда у меня была возможность взять интервью у Марка — какой лучший способ начать изучение CoffeeScript! Сначала я нашел время, чтобы прочитать его книгу « Программирование на CoffeeScript» , которая была фантастической и очень полезной. Затем мы потратили около часа, чтобы поговорить о CoffeeScript: как он был изобретен, какие другие языки вдохновляли и влияли на CoffeeScript, как разработчик Ruby должен начать его изучать, тестирование и многое другое … Я напечатал основные моменты нашего разговора здесь. Если вы являетесь разработчиком на Ruby и хотите узнать больше о CoffeeScript, у вас есть шанс услышать мнение известного разработчика, автора и руководителя о том, как начать.
Кто такой Марк Бейтс?
Марк Бейтс
Марк Бейтс — основатель и главный архитектор бостонской компании по разработке и консалтингу Meta42 Labs. Он разрабатывает веб-приложения с 1996 года. С момента открытия CoffeeScript он стал лидером в сообществе программистов, представляя группы пользователей и выступая на громких конференциях по всему миру, таких как RubyConf, RailsConf и jQueryConf. Он является автором книг по распределенному программированию на Ruby и программированию на CoffeeScript .
Q: Привет, Марк — спасибо, что поговорили со мной сегодня утром …
Тебе повезло, что я не сплю! Этим утром я случайно принял несколько таблеток тайленола, тот факт, что я сижу прямо сейчас, удивителен …
RailsConf
Q: Я слышал, что вы сделали отличную презентацию CoffeeScript для Rubyist на RailsConf 23 апреля. Как прошло? Как прошла конференция в целом?
Разговор прошел отлично, отличный прием. Помогло то, что у меня было отличное время, утро первого дня, большинство людей были все еще трезвыми, конечно, пьянство, вероятно, помогло бы моей презентации! Судя по людям, которые приходили ко мне во время конференции и даже на самолете, я, должно быть, все сделал правильно, потому что уверен, что сделал несколько обращенных.
Конференция в целом была действительно хорошей. Тема, которую выдвинула DHH, была прогрессом. Продолжайте смотреть в будущее, изучайте новые технологии, продолжайте расти как разработчик. CoffeeScript получил довольно заметное упоминание во время основного выступления, и он упоминался во многих других выступлениях, которые я видел. Я бы сказал, что я слышал, что больше людей обсуждали CoffeeScript, Backbone и Ember больше, чем сам Rails. Действительно показал, куда люди идут со своим развитием.
Вы должны даже использовать CoffeeScript?
Q: Есть люди, которые предпочитают «чистый» синтаксис JavaScript и ему не нравится идея его предварительной компиляции. Это даже хорошая идея использовать CoffeeScript?
Честно говоря, я бы сказал: «хорошо, если вы хотите продолжать писать так, как вам решать». Я считаю, что это очень похоже на то, почему я перешел на Ruby из Java. Очевидно, что в Ruby есть некоторые функции, которых нет в Java, а в Java есть некоторые функции, которых нет в Ruby — есть во всех языках. Я могу написать веб-приложение на Java, точно так же, как на Ruby…
Q: Мы все делали это …
Но я предпочитаю писать это на Ruby, потому что я могу написать гораздо меньше кода, чтобы сделать то же самое. Это то, что я чувствую к CoffeeScript.
Q: Есть ли что-то в красоте или элегантности кода CoffeeScript?
О да — опять то же самое с Java для Ruby. Я могу написать намного меньше кода; это намного чище и легче для чтения; это легче поддерживать. Многие люди говорят, что они ненавидят тот факт, что CoffeeScript является значительным пробелом. Им я всегда говорю: «Ну, как вы форматируете свой JavaScript?» Вы должны делать это в любом случае — вы должны красиво форматировать свой код. В этот момент значение пробела действительно становится незначительным, поскольку вы уже это делаете.
Стоит ли сначала изучать CoffeeScript или JavaScript?
В: Должен ли я изучать JavaScript в первую очередь, до CoffeeScript? Я помню, как Уайетт Грин на том собрании в Бостоне.рб еще раз выступил перед вами, от Ruby до JavaScript . Одна из вещей, которые он сказал, заключалась в том, что он хотел сначала тщательно изучить JavaScript, прежде чем начать изучать CoffeeScript. Как вы думаете, это хорошая идея?
Я думаю, что это должна иметь идея. В моей книге есть множество мест, где я на самом деле рекомендую читателю: «Положи книгу — сначала читай что-нибудь на JavaScript, а потом возвращайся», если они этого не знают. Очень важно, чтобы вы знали, что он делает. Вы узнаете некоторые действительно интересные вещи о JavaScript из CoffeeScript; Я конечно сделал. Это сделало меня лучшим разработчиком JavaScript, но я сначала был разработчиком JavaScript.
В: Можно ли быть обычным разработчиком JavaScript? Или вам действительно нужно хорошо понять это, прежде чем пытаться изучать CoffeeScript?
Вы должны быть, по крайней мере, промежуточным разработчиком JavaScript, потому что некоторые из этих концепций становятся немного пугающими, и CoffeeScript забирает некоторые из этих вещей у вас. Если вы начинаете и не совсем понимаете, что делает функцию функцией или как работают обратные вызовы, или как работают прототипы, вам следует сначала разобраться со всем этим.
Q: … потому что CoffeeScript может усложнить понимание?
Не сложнее, но все это абстрагируется. Знание того, что может сделать JavaScript и как с ним работать, означает, что вы действительно сможете использовать все преимущества, которые предлагает CoffeeScript.
Q: Я полагаю, легче не изучать JavaScript.
Точно. Я вижу, как люди легко переходят на CoffeeScript и генерируют довольно крутой код, не зная, что он на самом деле генерирует. Знаете ли вы, что в тот момент, когда он генерирует что-то, чего они не понимают, он действительно кусает их в задницу? Когда они не понимают, почему объем не является правильным. Или, почему что-то не совпадает с другой вещью, их отсутствие JavaScript действительно повредит им.
Как вы будете изучать CoffeeScript?
В: Если вы являетесь разработчиком на Rails или каким-либо другим разработчиком на Ruby, каков правильный способ изучения CoffeeScript?
Я надеюсь, что прочитав мою книгу, Программирование на CoffeeScript будет отличным способом выучить ее. Для Rubyists в книге есть немного Ruby, но я хотел сделать его доступным для всех, не только для Rubyists. Я использовал Node.js для создания примера приложения в последних трех главах по нескольким причинам:
- Потому что Node.js и CoffeeScript довольно часто связаны друг с другом, и вы видите множество приложений Node, написанных на CoffeeScript.
- Потому что я мог написать серверную часть в CoffeeScript. Это был отличный способ просто углубиться в язык и увидеть реальные примеры использования языка.
Q: Я думал, что это было действительно круто! Я продолжал думать про себя: «Не могу поверить, что пишу сервер на CoffeeScript!»
Да! Это довольно круто. В книге мы пишем сервер и интерфейс на одном языке, в CoffeeScript, что, на мой взгляд, было довольно забавно и круто. Но если бы я сделал это в Rails, то я бы оттолкнул людей PHP, людей Python, людей Java, и не было необходимости писать это на другом языке, потому что я мог написать это на языке книги, который был действительно забавное упражнение.
Для людей из Rails это довольно просто. Вы запускаете Rails, и поддержка CoffeeScript только там. Просто начни его использовать.
Q: Я думаю, что я здесь: я разработчик Rails, но я не эксперт по CoffeeScript. Я использую это здесь или там; это просто отчасти работает. Опять же, это почти слишком просто — вам не нужно тратить время, чтобы глубоко изучить его.
С Rails легко начать использовать CoffeeScript и прийти к точке, когда вы думаете, что знаете это и хорошо это знаете. Это не ужасно большой язык; это на самом деле довольно просто. Но на этом языке есть много действительно классных маленьких скрытых вещей.
В: Если я являюсь разработчиком Rails, я должен просто установить Node.js и изучить его так, как вы это представляете в книге? Или это нормально, просто использовать его внутри Asset Pipeline?
Я думаю, что это нормально, просто использовать его внутри конвейера активов. Использовать его важнее, чем играть с ним. Это то, что я чувствую к любому языку. Я не изучаю язык, строя маленькие игрушечные приложения, я учусь, используя его для реального приложения. Вот как я учусь: тонуть или плавать. Если у вас есть приложение, которое вы создаете, и вам нужен JavaScript, просто начните использовать CoffeeScript! Вы можете смешивать и смешивать обычные файлы JavaScript и CoffeeScript в одном приложении. Вы узнаете больше о CoffeeScript или любом другом языке, используя его по-настоящему, чем когда-либо, просто создав небольшое приложение для работы. Вы начинаете говорить: «Мне действительно нужно научиться делать X, Y и Z, чтобы решить эту проблему».
Q: И поэтому вы должны узнать о X, Y и Z.
Точно; это не надуманная проблема. Ваш бизнес лает на эту функцию, и вы должны научиться делать это.
Происхождение CoffeeScript
Q: Что вдохновило CoffeeScript? Это было вдохновлено Руби? Или по Python? Где его корни?
Он был вдохновлен обоими, и Лиспом, Smalltalk, независимо от того, что взволновало Джереми Ашкенаса . Вот почему, если вы посмотрите на это, оно выглядит как куча разных языков. У него есть значительный пробел в Python, и некоторые вещи, такие как символ @ и определения классов, очень рубеские. Джереми написал это изначально, потому что он прочитал « Как создать свой собственный офигительный язык программирования » Марка-Андре Курнойера . Он прочитал эту книгу и начал с ней возиться. Оригинальная реализация CoffeeScript была на Ruby — оригинальном компиляторе.
Q: Это все в коде C сейчас или что-то?
Нет, все написано на CoffeeScript!
Q: Это написано на самом CoffeeScript? Похоже, Рубинус …
Да. Точно. Это одна из тех вещей, которая всегда поражает меня. Rubinius поражает воображение тем, что это Ruby-реализация, написанная на Ruby, которая работает на Ruby. Как мир не взорвется, когда кто-то запустит сервер Rubinius, я никогда не узнаю.
С чем-то вроде компилятора это немного проще, потому что вы пишете первый компилятор во что-то еще, а затем у вас есть язык, который можно использовать для написания следующего компилятора. Первый компилятор был написан на Ruby. Но затем он взял версию X, написанную на Ruby, а затем написал компилятор CoffeeScript в версии X CoffeeScript. Если вы идете на GitHub , все это в CoffeeScript!
В: С Rubinius замечательно, если вы не уверены, как что-то работает, например, «Как работает метод String.slice?», — вы можете просто посмотреть исходный код Ruby.
Да, с CoffeeScript это все в CoffeeScript. Если вы хотите узнать, как работает поддержка классов в CoffeeScript, просто прочитайте исходный код CoffeeScript и увидите его прямо здесь. Это на самом деле довольно читаемый исходный код. Это гораздо более доступно, чем, например, исходный код Ruby.
Ember.js против Backbone.js
Q: Я хотел спросить вас о Ember.js против Backbone.js . Я не знаю, противоречие это или нет; они вроде разные вещи. Вы сказали, что часто используете Backbone — мне интересно, почему? А ты пробовал Эмбер? Какая разница между ними?
В некоторых отношениях они дико разные. Я думаю, что лучшее сравнение будет Backbone.js против Spine или Knockout . Мне очень нравится Backbone — я нахожу его невероятно простым, простым в использовании и понятным. Это имеет большой смысл для меня. Backbone позволяет вам создавать модели, коллекции и представления для управления вашим HTML, а также обрабатывать события, происходящие в этих моделях и коллекциях, динамически вызывать функции, скажем, для повторного рендеринга, как только он будет обновлен.
Ember использует другой подход и говорит, что вы должны разметить свой HTML определенным образом. И если вы это сделаете, то автоматическое обновление атрибутов произойдет автоматически. Если я правильно размечу свой <h1> с именем пользователя, и в моем объекте User я изменю имя этого пользователя, то этот тег <h1> будет обновлен, и мне больше ничего не нужно делать.
Q: То есть в Backbone вам нужно обновлять себя?
Точно. Но я думаю, что обновление Эмбер одновременно и ловко, и опасно.
Q: Потому что это может происходить, когда вы этого не ожидаете?
Могут быть случаи, когда по какой-либо причине вы не хотите обновлять элементы на странице. Я также не добавляю лишнюю разметку к своим страницам, если она мне не нужна, и это одна из причин, почему мне не нравится Knockout. Knockout работает почти полностью, добавляя дополнительные элементы данных в ваш HTML. Если в дальнейшем вы захотите что-то изменить, то в итоге вы получите все это лишнее.
Одна из вещей, которые мне нравятся в Backbone, это то, что он сокращает количество разметки, которую я должен добавить туда. Мне больше не нужны идентификаторы или даже имена классов, просто чтобы я мог найти определенный элемент. Все они видят взгляды. Если вы пишете свои взгляды правильно, вы можете сделать общий поиск для элемента списка; вам не нужно беспокоиться о том, чтобы убедиться, что это правильный набор элементов списка.
На самом деле я скоро буду писать новую книгу Backbone.
Q: Фантастика! Кстати, как ты начал писать книги? Очень впечатляет, что вы уже опубликовали два …
Я начал писать, напивая Оби Фернандеса в горячей ванне! Оби видел, как я разговаривал на RubyConf 2008 о распределенном программировании, и мы были в джакузи, болтаясь с людьми из Hashrocket , у нас было несколько напитков, и я сказал им, что пара человек спросила меня после моего разговора о том, где получить больше информации о распределенном программировании. Затем Оби сказал мне, что он был редактором серии Ruby в Аддисоне-Уэсли, и что распределенное программирование станет отличной темой для книги… и все пошло дальше.
Тестирование CoffeeScript
В: А вы хотите рассказать читателям о презентации, которую я видел на Boston.rb в марте? Я был поражен, как даже участники Boston.rb не проводили много тестов JavaScript…
Во время этого разговора там было 100 человек, и я спросил аудиторию: «Сколько человек тестируют свой код Ruby?», И 100 человек подняли руку. И это очень показательно для сообщества Ruby. И затем я спросил аудиторию: «Сколько людей пишут код JavaScript?» И снова все подняли руку. Затем я спросил: «Сколько человек тестируют свой код JavaScript?» И только 6 человек подняли руку.
Q: И я не был одним из них, поверьте мне.
Это просто ужасное число. Только 6% разработчиков Ruby в этой комнате тестируют свой JavaScript? И все они пишут JavaScript! Так почему же нормально тестировать Ruby, а не JavaScript?
Вопрос: Я думаю, что причина, по-моему, в том, что JavaScript — маленький чахлый пасынок в семье, и никто не воспринимает это всерьез. И в последние несколько лет большинство людей не писали много JavaScript; здесь было всего несколько строк или их для проверки, немного Ajax и т. д. Итак, я отвечаю на ваш вопрос — вы должны отвечать на вопросы! Но теперь люди вдруг понимают: «Я могу писать большие приложения только с помощью JavaScript».
Я также думаю, что есть опасение, что JavaScript будет слишком сложным для тестирования. Если это нужно запустить в браузере, как я собираюсь это сделать? Как я собираюсь проверить взаимодействие DOM? Как я собираюсь проверить AJAX?
В: Для Rubyists, у которых есть этот страх … что люди должны сделать, чтобы научиться тестировать свой JavaScript?
Это отличный вопрос! Там много хороших ресурсов: посмотрите на Жасмин , посмотрите на Мокку , посмотрите на Чай . Есть много действительно хороших библиотек, которые напоминают библиотеки, которые вы уже используете для тестирования Ruby.
Q: Да, в вашей презентации меня поразило, насколько Жасмин выглядит как RSpec.
Точно. То же самое с Мокко и Чаем: они очень похожи на RSpec.
Одна из вещей, которая меня очень удивляет, до такой степени, что если бы у меня было время и желание, я бы, вероятно, села и попыталась написать большой запрос на загрузку для Rails 4, это то, что Rails не включает тестирование инструменты для JavaScript.
Когда они представили конвейер ресурсов и CoffeeScript в Rails 3.1 — и я думаю, что CoffeeScript снижает барьер для входа при тестировании в JavaScript, потому что это кажется гораздо более естественным, чем при написании Ruby, — почему они не включают инструменты тестирования? Это весит в моей голове. С самого начала в Rails была тестовая среда, и так много внимания уделялось: «Посмотрите, как просто протестировать ваш код».
Q: Честно говоря, это большая причина, почему это завоевало популярность — потому что это было там во-первых.
… и потому что это было легко сделать. Rails сделали это очень просто. Я буду честен — за все мои годы написания Java спросите меня, сколько юнит-тестов Java я написал! Это было не много; Я не собираюсь вам врать! И появился Rails, и вау, там был Test :: Unit, которым я не был фанатом, но он был тут же, выпечен, и я мог легко начать тестирование.
Так что команда никогда не использовала инструменты тестирования для JavaScript, поражает меня. То, что я продемонстрировал на Boston.rb, должно было быть в рамках. И каждый раз, когда Rails генерирует один из этих файлов .coffee для вас, он должен генерировать для вас тест.
Благодарность!
Q: Спасибо за ваше время, Марк!
Конечно, спасибо, Пат.