Всем привет! С вами в эфире @milk_is_my_life. Последние 6 лет я занимаюсь фронтэндом, работаю в SPB TV.

Т.к. компания совсем небольшая в мои обязанности входит все, от собственно кода до окружения для тестирования, деплоя и запуска на серверах

Мы используем continuous integration (teamcity), а для production-серверов - docker. А что вы используете для запуска приложения?

Говоря простыми словами, докер - это легкая и "дешевая" виртуальная машина. Для ее запуска не требуются дополнительные мощности и вес (...)

(...) образов также умеренный. Таким образом, на выходе мы имеем полностью изолированную среду (ос) для запуска приложения.

Если у вас не один проект, то, что-то подобное вам необходимо. Т.к. вы можете использовать разные версии nodejs, разные конфигурации nginx

И наконец, самое важное - полную переносимость и масштабируемость. Нужен еще один сервер? Просто запусти на нем еще один контейнер!

Ну и конечно - эта технология все еще молода. Нестабильная работа в ряде случаев, непонятные баги и косяки, совместимость с разными (...)

(...) версиями ядра линккс - все это иногда добавляет ложку дегтя, куда же без нее в нашем деле.

@jsunderhood а вы уверены что это относится к фронтенду? И js-у? Мне, кажется, это тема для DevOps-ов)

никто, лучше самого разработчика, не знает, как должна быть настроена среда для запуска его приложения.

@jsunderhood как вам тимсити? Сложно первый раз было запускать/настраивать?

@jsunderhood тогда слишком много надо знать, чтобы быть хорошим во всем, я, считаю, не зря это все делегируется

окружения для запуска своего проекта - задача разработчика. также, как и деплой, например.

Есть такая штука "Full Stack engineer" - его задача, не смотреть на все через "щель" в люке @hellbeast92 @jsunderhood @jsunderhood

@jsunderhood фронтенд в docker контейнерах? Только если под фронтендом подразумевается universal приложение. А это далеко не всегда так.

статику, и как именно. кроме того, допустим, у вас на 1 сервере 5 приложений. как конфигурить nginx в этом случае?

@jsunderhood эту информацию можно написать в readme проекта. Это одна папка, причем обычно одна и та же для всех проектов: build, dist

(…) потребуется это же приложения на другом сервере - могут возникнуть конфликты конфигураций

@jsunderhood еще как поддается. Есть package.json. Договоритесь в команде, об описании интерфейса в package.json и автоматизируйте

@jsunderhood вы же предлагаете docker. Это значит что стандарт - это просто бинарник докера. А что и как внутри - забота отдельного

@jsunderhood программиста. В итоге каждый внутри будет делать как захочет. А это еще хуже.

пример базового конфига. на выходе мы будем иметь образ с установленной centos7, nginx, nodejs 4.1.1 и собственно нашим приложением.

bit.ly/1LLwsh4

@jsunderhood я не вижу что хорошего в том, что снаружи все хорошо, а внутри как прийдется. Представь себе червивое яблоко.

@jsunderhood пока яблоко не трогаешь - оно снаружи красивое. А если нажать немного, развалится. Вот такая у меня аналогия.

@jsunderhood не-не. Изоляция тут вместо стандарта внутри приложения. Вот это и вызывает такую аналогию. Изоляция - ок, вне этого контекста.

смотрится круто, но как решается базовая задача "zero downtime deploy"? @jsunderhood

недоступен

Docker - это как минимум еще один слой для возможного падения. Но он не достаточен для создания "production ready" системы @jsunderhood

@rubyunderhood @jsunderhood подтверждаю, были случаи неодинаковой работы аппы в контейнере на разных системах, вплоть до отказа

Конечно есть. Наелись им как и распираемым react - leopard.in.ua/presentations/… - как говорится минимум для "docker" @jsunderhood

А значит придется использовать еще какие то слои, для полноценного решения, что увеличивает количество улов отказа @jsunderhood

@gusnkt @jsunderhood это вопрос организации команды

@gusnkt @jsunderhood всегда есть переключение контекста

@hellbeast92 достаточно понимать что это, как и зачем. Иначе будут «негодные админы, которые нам билдить на сервере не дают» @jsunderhood

@shuvalov_anton @jsunderhood @hellbeast92 умение поднять свой собственный CI очень важно

@iamstarkov @jsunderhood @shuvalov_anton @hellbeast92 Есть неплохой self-hosted CI - drone.io

давайте параллельно запустим еще один тред. его тема - деплой. после того, как вы определились с развертыванием приложения, как вы это (…)

приложение доставите на сервера? ssh, rsync, etc? мы выбрали для этой цели ansible. сложновато на первых порах, но оно того стоит.

а как деплоите вы?

@jsunderhood отдельная git ветка production и автоапдейт по этой ветке

@jsunderhood `$git push dokku master` кажется ок

@jsunderhood э, ребята, вы Docker то читали? Вы просто перенесли свою виртуалку в docker, а это не docker-way

запускаем вместе. это разруливается в entrypoint

@jsunderhood в Docker главное правило: 1 контейнер - 1 главный процесс с PID 1, он сам выступает в роле супервайзера

@jsunderhood если наборот, то зависнет одно из приложений в контейнере: место кончилось, очередь образовалась, что-то еще — хана контейнеру

@jsunderhood у вас должно быть например 3 контейнера app-nginx, app-node, app-database

@jsunderhood и выкатывать приложение только в app-node, и если на лету код не подхватывается, то рестарт мелкого контейнера будет шустрым

их приложение (рельсовое) состоит по-моему из 4 или 5 контейнеров: сайдкик, бд, рельса, что-то еще.

@jsunderhood как выглядит flow разработки в docker фронтенда? Или ты в контейнер только результат отдаешь, а остальное по старинке?

отличный вопрос и это следующая наша тема - окружение для разработки. мы решили не использовать докер при разработке, потому что это

оказалось неудобно - на линуксе и маке докер работает по-разному, плюс не совсем понятно как развернуть наш привычный стэк с hot-loader и

browsersync. поэтому разработка ведется по-старинке, а докер собирается в момент деплоя и для тестов.

ну а собственно наш стэк:
react, redux, sass.
для девелопмента:
webpack, babel, eslint, npm scripts
для тестов:
karma, mocha, chai, sinon.

кстати, финт ушами. для тестирования асинхронных операций крайне удобно использовать async/await. пример: gist.github.com/tadjik1/2874d2…

плюс в том, что в одном тесте у вас может быть несколько асинхронных операций, и вы их даже можете чейнить. заботу об это берет на себя не..

какой-нибудь плагин типа chai-as-promised с не очень удобный апи, а сам js!

почему мы не используем gulp/grunt/broccoli/…? потому что у нас есть nodejs! а заботу обо всех source файлах на себя берёт webpack.

а в dev-моде с помощью его middleware мы получаем удобное средство для апдейта приложения без перезагрузки страницы.

итого: webpack → nodejs (наше универсальное приложение) → webpack middleware (+react-transform) → browsersync.

@jsunderhood собираем AMI для staging потом этот же образ пускаем в прод после тестов. Образ билдим ansible

у меня, кстати, практически нет личных проектов. у меня ни разу еще не получалось заниматься чем-то своим вместе с основной работой.

а если всё-таки я начинал заниматься каким-то "левым" проектом - значит я лентяйничал на работе или просто не было интересных задач =)

так вот. если у вас есть личные проекты, раскройте секрет - как вам это удаётся?

@jsunderhood ну некоторые компании поощряют личные проекты, выделяют там дни на них, особенно если это open source

@jsunderhood личные проекты разные бывает, если ты в рамках своей основной работы решил какую-то общую задачу это можно запулить в опенсурс

меньше сплю и выделяю на не важное ("игры", "сериалы/кино") меньше времени @jsunderhood

@jsunderhood я думаю, что хотя бы завести свой бложик - это уже неплохой свой проект

пожалуй, единственный реальный кейс, который видится мне - ты в рамках своей основной задачи решил какую-то проблему, и это похоже на либу

NDA главное при этом не нарушить :D @lapanoid @jsunderhood @jsunderhood

.@rubyunderhood @lapanoid @jsunderhood вот кстати насчет опенсорса на рабочем месте. По сути - ты тратишь деньги работодателя - на опенсорс

.@rubyunderhood @lapanoid @jsunderhood у нас, все что сделанно на работе - принадлежит компании. Опенсорс - в свободное время.

@jsunderhood эм, именно chai-as-promised и берет на себя заботу, завернуть done в промис.

У меня был такой - оплачивал опенсорс, что получался из проектов, но он был под акаунтом компании заказчика @mr_The @lapanoid @jsunderhood

@mr_The @rubyunderhood @jsunderhood Я не предлагаю втихую выкладыать это равносильно воровству. Можно убедить работодателя что это выгодно

@mr_The @jsunderhood @rubyunderhood @lapanoid это плохая позиция, надо ко всему подходить с умом. хороший опенсорс — HR брэнд для компании

github.com/sendgridlabs/g… - пример такого опенсорса @mr_The @lapanoid @jsunderhood

@mr_The @jsunderhood @rubyunderhood @lapanoid что выливается в экономию денег компании

а также способствует более удачному хайрингу. а также привлекает сообщество, которое помогает исправлять баги и развивать продукт.

Или же наоборот - риск потерять лицо компании. Когда ты сам - проще @sevaisnotcow @mr_The @jsunderhood @lapanoid @jsunderhood

@mr_The @rubyunderhood @jsunderhood в опенсорсе код который вы отдали бесплатно, бесплатно улучшается и тестится комьюнити + travis и проч

Если он вообще кому то потребуется - а может так же успешно и "загнивать" в публичном репозитории @lapanoid @mr_The @jsunderhood

@rubyunderhood @sevaisnotcow @mr_The @jsunderhood какой-то сумрачный риск, прохие проекты редко громкие ими просто не пользуются

я полностью согласен. примеры: kitty php от vk, reactjs от fb.

@rubyunderhood @jsunderhood @mr_The это означает, что решили не общую задачу, или непонятно как использовать - тайные знания внутри компании

@jsunderhood нет, ты не понял. async функция возвращает промис. chai без плагинов не понимает промисы.

посмотри gist. внутри синхронного чая используется асинхронный вызов. этот подход удобнее, чем оборачивание в плагины.

Проблема, что мы любим указывать на success case, но плохих еще больше - просто о них не трубят @lapanoid @jsunderhood @mr_The @jsunderhood

done() callback в помощь, что бы тест дождался @jsunderhood

я не хочу заморачиваться с done(), это ведь неудобно в тестах, так?

@gusnkt @jsunderhood Зато mocha понимает.

@rubyunderhood @jsunderhood Нет, done как раз нужен был до промисов, с ними нет смысла.

@rubyunderhood @jsunderhood @mr_The критика это часть культуры opensource, если есть страх ее - нет смысла выкладывать

почему не удобно? тот же контроль выполнения кода (я сообщил, когда тест кейс завершился) @jsunderhood

Поэтому одному и проще: компания может быть не заинтересована в подобном риске (им и так хорошо) @lapanoid @jsunderhood @mr_The @jsunderhood

ну т.е. если ты работаешь в компании, где никто не хочет ничего менять - мб стоит сменить её?

перечитал, и понял какой неудачный каламбур получился =) я имел ввиду смену работы, конечно. а то ведь и jquery работает, зачем нам SPA?

Подход - "все в опенсорсе становится лучше" - точно не работает всегда @jsunderhood @lapanoid @mr_The

@RReverser @jsunderhood @rubyunderhood просто return промиса делаем и счастье

@jsunderhood каламбур как раз удачный)

@lapanoid Критики бояться не стоит. Выложил код, получил горшок говна и знаешь куда подрости :) @rubyunderhood @jsunderhood @mr_The

Немного про инструменты. Один из самых популярных инструментов у меня в работе — виртуалки с разными IE.

Раз такая пьянка, давайте пройдемся по выбранному стэку. Начнем с реакта, конечно, он же такой модный :)

Итак, почему мы выбрали его. Это был долгий путь, мы последние 2-2.5 года писали на нокауте (mvvm- паттерн). Но затем стало понятно, что

Этот подход плохо сочетается с переносимостью. В условиях, когда у тебя параллельно 5-6 проектов, это невероятно дорого.

Далее был рассмотрен hmvc, который вроде бы решал эти проблемы, но не до конца и опять-таки основная боль виделась в M и C

Ну и в итоге мы поняли, что правильный путь - компоненты. Мы стали использовать компоненты, которые предоставляет knockout, это было почти

То, что нам нужно. Но нам сильно стал мешать 2-way data-binding, который вносил много путаницы. Таким образом мы и пришли к реакту.

Все маркетинговые штучки типа виртуального дома, сервер-рендеринга к нам пришли уже сами собой, и мы им очень рады, нет проблем с сео,

@jsunderhood risovach.ru/upload/2014/04…

Именно! Самая большая прелесть состоит в том, что кодовую базу на компоненты удается переводить, а не писать все с нуля.

@jsunderhood а может ли сообщество порекомендовать newbie-level материлов про серверный рендеринг? Прям для тупых, вчера пузырек написал

Я так понимаю речь идет про реакт? Если да, то я не смогу помочь, т.к. пришел в него уже опытным разработчиком, и мне хватило документации

@jsunderhood если есть не про реакт, тоже ок, там сам отфильтрую

Для меня это все началось с nerds.airbnb.com/isomorphic-jav…. Но тогда я даже не мечтал, что смогу сделать что-то подобное, про реакт не слышал ничег

Мне казалось, что за этим должны стоять огромные компании, и сотни суровых разработчиков. А потом появился реакт, и это стало доступно всем

Помню прибежал тогда к рубистам, говорю, смотрите, как было бы круто! Вернуть не пустую страницу с крутилкой, а сразу маркап, не вкрячивать

пререндер, а просто заботиться о мета тэгах и правильной верстке. ну они конечно не поняли ничего, чуть в дурку не сослали.

@_sashashakun немного outdated, но суть особо не поменялась medium.com/@alexfedoseev/… @jsunderhood

Если быть честным, они до сих пор не очень в курсе, что там за контейнер с нодой появился, и зачем она нужна для обычной статики :)

Соскучился по русскоязычному сообществу, наконец то записался на @jsunderhood. Ждите на неделе с 23 ноября.

А будет холивар с поклонниками CSSInJS? Запасаться попкорном? :)

@jsunderhood уже ж был

Холиваров много не бывает ☝

Следующий элемент нашего стэка - сасс. Выбор был прост, мы его используем уже давно, все наши проблемы он успешно решает.

На всякий случай посмотрели на postcss, посмотрели на css-модули, не смогли придумать проблем, которые они бы нам позволили решить

@jsunderhood а стили вместе с компонентами не распространяете? У вас же там горстка проектов?

@jsunderhood или стайлгайдом все покрыто?

Стили конечно с компонентами живут, а изоляция обеспечивается бэм-именованиями классов

@jsunderhood так а подключаете как к проекту стили каждого компонента?

Мы импортим стили прямо в компоненте, нам вебпак позволяет это делать.

@jsunderhood ручное именование классов это боль, css-модули сильно удобнее + строки сильно короче

@jsunderhood программист ленив в этом его супер сила и если можно спихнуть что-то на машину-он обязан это сделать. Бэм добавляет кучу рутины

Ну в целом я с вами согласен, мне не очень нравится как все получается с бэмом.Но перейти на css-modules будет очень просто,вернемся к этому

@jsunderhood и у вас получается один жирный жс бандл, который грузится и блокирует приложение?
Стили отдельно не выносите? Above-the-fold?

Почему же? ExtractPlugin в продакшн выносит все стили в отдельный файл.

@jsunderhood асинхронных операций очень мало. 99% тестов должны проходить синхронно

Интересная мысль. Но я говорю про тот 1%, который тестировать тоже надо

@mr_mig_by @jsunderhood можно чанки с CSS webpack.github.io/docs/styleshee…

Завтра мы с вами обсудим самую сложную часть нашей системы-работу с данными. Флакс, редакс, mvc, mvvm, baobab, angular (не знаю как назвать)

@jsunderhood предлагаю всем ведущим, помимо ссылок на используемые технологии, давать еще и ссылки на проекты, где они это все используют

ru.spbtv.com

@jsunderhood CSS Modules нужны для тех же проблем, что решает БЭМ. Можно сказать, что CSS Modules просто БЭМ автоматически.

пожалуй, я тут соглашусь. я не знаю, почему мы не взяли просто css-modules =)

@jsunderhood сразу видно что это SPA. Сначала загружается список каналов, а потом We're sorry, only available inside Russia. Почему так?

Дело в том, что каналы загружаются еще на сервере, а проверка геопозиции происходит уже на клиенте. Фактически это баг, я поправлю.

Давайте поразрушаем стереотипы? Стереотипы будем брать из твиттера про руби.Там почему-то тоже обсуждался реакт.Ну а что им еще обсуждать?)

universal - ok, но рендерит template в строки мог и mustache на сервере, а разрулить забор данных на разных уровнях? @rainrb @jsunderhood

Стереотип 1. Реакт, это не темплейт энжин, jsx !== jade|hbr|etc. То, что реакт умеет рендериться в строку и даже в нейтив - его природа

Стереотип 2. Раз реакт такой крутой, то как мне сделать ...? Реакт настолько крут, что вы даже приложение должны писать сами.

Ну если вы знаете как устроен react virtual dom внутри и почему другие имплементации пока быстрее - плюс Вам @as_Crazy @jsunderhood @rainrb

Ну и конечно же, скорость виртуального дома.Забудьте о виртуальном доме, вам надо писать приложение. Ом, элм, virtual dom, берите,что хотите

Если же вы не знакомы с хаскелем или хотите писать для браузера на жс - реакт на данный момент отличный выбор!

Ну и последний стереотип: реакт - не панацея. Да, скоро появится что-то новое. Но то, что он принес в жс - выгодно его отличает от

Фреймворков старого образца: смотрите, у нас такой 2-way, а у нас такой, а у нас директивы, а у нас коллекции, своя система модулей и т.д.

@jsunderhood в nginx можно конфиги инклудить из директории — пусть каждый там себе файлик заведёт и при деплое обновляет каким-нить chef

При таком подходе (1 nginx), никто не гарантирует, что ваши конфиги не будут конфликтовать друг с другом. Не всегда это так, но разгребать

Горы конфигов каждый раз было мучительно

@jsunderhood а ещё статику можно на CDN положить и забыть

Ну так статика - это наше приложение, а сдн - наши сервера. Это никак не противоречит идее изоляции приложений на сервере, так?

@rubyunderhood @jsunderhood @as_Crazy @rainrb Это не обязательно, чтобы использовать эффективно реакт. Достаточно понимать концепции.

@jsunderhood обновления на сайте jsunderhood.ru
например jsunderhood.ru/RReverser/ и у всех авторов тоже pic.twitter.com/eQubaISatM

@denysdovhan @jsunderhood Problem Driven Development

Job Safe Driven Development

Ну что, переходим к вопросу о работе с данными. Мы выбрали redux by @dan_abramov. Почему? Начнем с критериев отбора:

1. возможность "кэшировать" данные. пользователь, загрузив список фильмов, например, должен иметь возможность открыть страницу с фильмом

или если пропадёт интернет (на мобилке) он должен иметь "ходить" по приложению, видя те данные, которые уже были им загружены

таким образом вопрос "кэширования" сводится к вопросу удобной работы с данными на уровне данных, если проще - минимум абстракций

почему, например, мы не взяли бекбон с его моделями и коллекциями. потому что работать с коллекциями, в которых у моделей есть связанные

сущности - очень и очень сложно. гораздо проще оперировать js-сущностями, такими как массив, хэш, используя встроенные методы map, reduce…

кешировать данные и отдавать кешированное можно на уровне диспатчера - для этого не нужен redux, нужен просто flux @jsunderhood

абсолютно верно! это я еще не подошел к redux, это я просто говорю, почему не backbone.

@jsunderhood backbone-style, имеется ввиду, с его моделями и коллекциями

Ну если взяли react, то какой уже backbone в таком случае? @jsunderhood

На react нужен pub-sub (flux), а не MV* @jsunderhood

@jsunderhood я делал гугл табличку - по критерию выписывал как каждый flux соответсвует goo.gl/x84KPf + есть репа со всеми flux

после того, как мы поняли, что флакс - то, что нам нужно, мы стали уже перебирать реализации. пописав на "классическом" быстро поняли, что

это мука. очень много бойлерплейта, "независимые" сторы, waitfor и т.д. тогда же попался на глаза очень приятный flummox, который

вскоре стал deprecated в пользу redux. также, мы всерьез рассматривали baobab (christianalfoni.github.io/javascript/201…) и nuclear (github.com/optimizely/nuc…)

но как обычно в таких делах грамотный маркетинг, и простота api redux довольно легко уделали всех конкурентов. +хот-релоад, система плагинов

@jsunderhood а проблем с роутингом у вас нет? Вот у меня есть ключевая проблема с flux и redux - где хранить данные, нужные одной странице?

@lapanoid @jsunderhood Кстати Redux сейчас не имеет зависимости от React (в табличке имеет)

@jsunderhood @lapanoid Oh shi~~~ Поправьте чтобы сохранялся выбранный язык! Хотя бы в пределах сериала. )

@jsunderhood не, ну допустим у вас есть список постов и страница на пост. Где хранить 1 пост?

Давайте поговорим про окружение для разработки. Когда-то мы использовали nginx и галп вотчеры, теперь вебпак и браузерсинк. Хот релоад-круто

Помню эти муки, как повторить стейт, в котором у тебя поехала форма, или вообще ошибка произошла какая-нибудь

@jsunderhood умение написать кучу кода, который разом начинал работать в браузере - вот это истинное мастерство. Презентации Брета казались

@jsunderhood чудом из другого мира

Я не знаю откуда у меня столько ностальгии, сегодня просто был тяжелый день :)

@jsunderhood когда-то я херачил код script'ами в head, а теперь кладу ссылками в конец body и внутри оборачиваю в !function(){}()

Пишу на universal - node, react, hot-reload, прочее счастье. Но тут возник вопрос: неужели нет hot reload для express? @jsunderhood

@rubyunderhood @jsunderhood миддлвары мутирующие res, мне кажется сильно осложняют задачу

@jsunderhood но раньше можно было еще и исправить код в браузере, который обновлял файлы в проекте.

@jsunderhood так вот это было еще круче чем эти ваши хот-релоады :)

А по поводу отключения - с движением в SPA это пока мечты. Сейчас многие будут смеяться, если им сказать "а если JS выключить" @nick_jastix

Такоя я могу тоже без JS :D @jsunderhood @nick_jastix pic.twitter.com/5oNmCYN5Wp

Перейти то я могу, но толку от этих квадратов Малевича? @jsunderhood @nick_jastix pic.twitter.com/W2GJoKbxzq

@jsunderhood @rubyunderhood @nick_jastix до полной загрузки страницы выглядит страшненько (WP8.1) pic.twitter.com/clER14o0dY

Хороший пример - try.discourse.org, который написан на Ember, но при отключении JS работает @jsunderhood @nick_jastix

@rubyunderhood @jsunderhood современный веб: на одном сайте нужно отключить жс, чтобы работало. На другом - включить.

Обфускаторы сборки React, которые не позволят так нагло оперировать props и state в prod @jsunderhood @nick_jastix pic.twitter.com/4tCXUAeoXi

В разнообразии сила. Пример: доминирование IE6 в вебе к чему привело @jsunderhood @nick_jastix pic.twitter.com/GIyZygDtEM

Да потому что веб перерос этот язык. Поэтому у нас появились babel, typescript, coffescript и прочие препроцессоры @jsunderhood @nick_jastix

Реально? Такие вопросы? Да на них кто угодно ответит @jsunderhood @nick_jastix

Хотелось помечтать, налетели рубисты

Может о чем-нибудь отвлечённом? Смотрит кто-нибудь цска, болеет за ребят?

@alexeyraspopov @rubyunderhood @jsunderhood reactunderhood.

@jsunderhood нет, только не футбол! Давай лучше про фичи es7. async/await использует кто-нибудь уже? Как ощущения?

@jsunderhood а bind-operator? Я на него и сам подсел, и коллег подсадил и теперь немного волнуюсь, что оно в стандарт не попадёт.

@jsunderhood а что значит «плохо транспилится»? Неэффективно? Отлаживать неудобно? На первый взгляд вроде норм.

@maxmaximov @jsunderhood Если я не ошибаюсь то вы можно попробовать async/await в новом IE с чакрой.

@xgrommx @jsunderhood ну да, это просто сахар (как и половина всех новых фич из es6/es7)

@jsunderhood @maxmaximov поподробней плз. На нагрузочных тестах по скорости и памяти сервис полный async/await показал себя вполне норм.

@xgrommx @maxmaximov @jsunderhood
Это называется T_PAAMAYIM_NEKUDOTAYIM /cc @RReverser

@jsunderhood 50rps на 6 воркерах (6 cpu), нагрузка на фронте <30%, дальше сдохло api. Повторить не смогу, уже ушёл с этого проекта.

А кто-нибудь пишет функциональные тесты? Понимаю, что это задача тестировщиков, но тем не менее

Недавно задумал на тимсити перед собственно деплоем прогонять тесты на приложении. Понравился casperjs.

@jsunderhood С чего это задача тестировщков? Всегда писал такие тесты сам.

@jsunderhood Что именно интересно? :)

Между тем, из стандарта es7 убрали object.observe. Мне вот сразу казалось это крайне сомнительной фичей.

@jsunderhood решал проблему рефакторинга недокументированного легаси. Предварительно покрывал смесью функциональных и юнит тестов.

TDD, BDD - тесты пишут девелоперы @jsunderhood

Хотел еще спросить, кто еще не использует es6 в работе? Мы вот хоть и с боями, но перешли на него в начале года. Только хорошие эмоции

@jsunderhood ещё не убрали, только собираются esdiscuss.org/topic/an-updat…

@jsunderhood с Babel перешли или как?

@jsunderhood Только stage 0, только хардкор :)

@jsunderhood интересно ваше мнение. Почему для вас кажется это сомнительной фичей?

@jsunderhood у нас переходят на TypeScript. Поэтому моя консоль теперь всегда красная

@jsunderhood из аргументов называли: CommonJS, es6, типизация, проще понимать. На практике я вижу больше минусов, чем плюсов

@jsunderhood а библиотеки для совместимости какие-нибудь использовали?

@jsunderhood чем понравился casperjs? Он же нерасширяемый!

@jsunderhood он подсаживает на себя. Потом понадобится прикрутить что-то к тестам, а не получится. Лучше разделить framework,asserts,browser

@jsunderhood Не первый это скажу, но автоматизированные тесты есть задача разработчика. Тестеры пусть делают то, что сложно формализовать

@jsunderhood собрать стек самому из phantomjs, mocha и chai например. Или из jest с чем-нибудь

@jsunderhood @boriscoder Selenium + mocha + chai

@jsunderhood пишу и мне кажется это задача dev'ов если нет тестера, а часто его нет. С тестами есть уверенность

@VovanR @jsunderhood а какие минусы?

@dmitryshimkin @jsunderhood например сторонние либы в основном идут без tsd, а те, что есть, часто устаревшие. Консоль всегда красная =(

@VovanR @jsunderhood @dmitryshimkin да взял тайпскрипт на проект с реактом. выпилил уже, задолбало поддерживать =(

@rubyunderhood @jsunderhood @nick_jastix Rise of the Compilers - Brendan Eich youtu.be/PlmsweSNhTw, brendaneich.com/2015/06/from-a…

интересна тема обучения.последнее время появилось невероятное кол-во курсов, учебников и пр.но лично для меня эталон learn.javascript.ru

@jsunderhood да. крутой продукт. что думаешь про @YDKJS ?

возможно не все знают, но learn.javascript написан на nodejs и его код находится в open source. github.com/iliakan/javasc…

@jsunderhood мы в @htmlacademy_ru понемногу пишем на es6. Сплошное удовольствие.

кстати, у меня такой вопрос. документируете ли вы код, и какие средства для этого используете? любимый jsdoc, к сожалению, не понимает es6.

вроде как есть возможность использовать dev-версию jsdoc, кто-нибудь настраивал?

@jsunderhood github.com/esdoc/esdoc

второй день подряд полностью поглощен докером =) удалось перенести все процессы (тесты, генерацию документации, e2e и т.д.)внутрь контейнера

@jsunderhood почти travis получился из тимсити

@jsunderhood а зачем документацию в контейнере генерировать?

для генерации документации тоже нужно специально окружение (nodejs), это окружение поднято в докере

@jsunderhood у тебя это делает CI. Это уже контейнер. В чем проблема в нем поставить node?

один ci используется для многих проектов, и каждому может потребоваться своя версия ноды, например

@jsunderhood если она действительно понадобится - nvm. Но скорее всего все запустится на той же версии, что и проект.

nvm не решает всех проблем: может различаться ос, и компилируемые пакеты могут не заработать.

@jsunderhood why not @droneio from the start?

because we are using private git repository and self-hosted teamcity as CI server

@jsunderhood могут. А в действительности есть такие проблемы, или это решение предположительно возможных?

Конечно реальные, у меня на ноуте мак, на прод серверах центос, как мне собрать контейнер локально? (Если нет доступа к ci)

Хочу начать изучение нового языка.Не для практических целей, а скорее для более фундаментальных знаний.Выбираю между scala, closure, haskell

@jsunderhood брейнфак рулез! Он вечен. Остальные рано или поздно умрут.

@jsunderhood А какие знаешь?

Самый большой опыт - js, писал на c, c++. Немного на руби и пхп.

Это, кстати, мой комплекс - я думаю, хороший программист обязан свободно владеть набором языков. Даже если в работе используешь только 1.

@jsunderhood виртуалку развернуть с нужной системой на маке?

Так докер - это тоже виртуалка, и апнуть версию centos, в ней гораздо проще. Кроме того, образы можно наследовать, что добавляет гибкости

@jsunderhood постоянно прыгаю в проекте между js и ruby . всегда легкий затык, пока переключусь

@jsunderhood Попробуй Elm.

Ну это как с выбором фреймворка для js - я не хочу учиться писать классы 1000 и 1 способом, хочу больше думать про алгоритмы и стр. данных

Ну и с человеческим синтаксисом, конечно. Поэтому не с, например. (Не хочу никого обидеть, это личное мнение)

@Semenov @jsunderhood плюсую за clojure) а потом - haskell

@jsunderhood Дляобщего развития можешь Clojure попробовать

@jsunderhood так это и на js тогда можно

Ну я же начал с того, что хочу выучить новый язык. Js позволяет многое конечно, но есть и другие

@jsunderhood а захочешь сменить работу, без опыта в фреймворках не берут - реальность :( как будто это важнее самого знания джс.

Это конечно субъективно, но таких компаний все меньше. Например, у нас знание фреймворков вообще неважно, важно лишь знание языка и опыт.

Причем опыт программирования на любом языке.

@jsunderhood ну и зря, какой бы огромный опыт велосипедов у тебя не был, фреймворк диктует свои паттерны и имеет определенные особенности.

@jsunderhood нанимать того, кто с ними не знаком — потеря времени и вероятность говнокода или того, что разработчик просто не справится.

боюсь, что меня обвинят в очередном холиваре, но я не согласен ни с одним выводом. а раз ведущий на этой неделе я, то я расскажу свою правду

ни angualr, ни ember, ни knockoutjs, ни react, ни что-нибудь еще не предложили миру "своих" паттернов. максимум - свои реализации mvc,mvvm..

программист неплохого уровня сможет достаточно быстро "пересесть" с одного фреймворка на другой, даже если они написаны на разных языках

@jsunderhood offtop. Поделитесь ресурсами для поиска работы ?

не специалист в вопросе поиска работы — но в России по-моему работают хорошо 2: linkedin и hh

У нас внутри компании был случай, когда js стал рубистом, а еще на работу во фронтэнд взяли студента 5-го курса с опытом java.

И оба - прекрасные специалисты!

@jsunderhood Java - это не приговор!

@jsunderhood а вот интересно как владеть свободно, если без практики все эти туториалы вылетают из головы через месяц

А вот хороший вопрос. А вот не знаю :) но думаю, что выучив раз, легко вспомнить по справочнику.

@raxpost @SilentImp @jsunderhood опенсорс жалует новичков

@SilentImp @jsunderhood бывает сложно придумать небесмысленный проект на новом языке/технологии, а в опенсорс новичков не жалуют

@SilentImp @raxpost @jsunderhood главная мысль была: зачем учить абсолютно незнакомый язык, не имея понятия, куда его применить?

Я знаю куда его применить. @nikitonsky не даст соврать, идеи одного языка отлично работают в другом

@jsunderhood clojure - другой мир совершенно

@jsunderhood @nikitonsky потом “первый” язык применять вообще не захочется.

Не думаю, что closurescript больше подходит для фронтэнда, чем что-либо

@serhey_shmyg @jsunderhood у нового @moikrug переодически бывают новые интересные вакансии (я именно про их твиттер)

@jsunderhood он тоже clojure)

@jsunderhood попробуй и измени своё мнение навсегда :)
З.Ы. язык эт еще не все, экосистема играет большую роль

@jsunderhood подскажите системы для мониторинга и логирования фронтенда?

мы используем bugsnag, он платный. насчет логгирования не знаю даже, консоль? а вообще всё зависит от требований.

@akochemasov @jsunderhood гугл аналитикс ;)

@akochemasov @jsunderhood Sentry + Raven

@akochemasov @jsunderhood, sentry или bugsnag.

@Chudesnov @akochemasov @jsunderhood нет, нужно самому перехватывать onerror и слать в GA сustom event.
developers.google.com/analytics/devg…

@Chudesnov @akochemasov @jsunderhood плюсы: гибкость, риайлтайм и вся мощь отчетов GA. Минусы: стектрейсы не войдут, понимает только строки

Via #reactiflux, how to automatically create a vendor bundle with your #webpack production build: pic.twitter.com/Ynjymnt07U

Разделяете ли вы итоговый код приложения на бандлы? Если да, то каким образом? Мне способ с require.ensure кажется громоздким, и особого

Смысла в таком разделении я не вижу. Буду ждать либо человеческий апи (в идеале его отсутствие), либо уже системные лоадеры js

Это я не про бандл с вендорами говорю - его как раз стоит выделять и кэшировать на клиенте.

@jsunderhood стоит ли разделять на бандлы, если можно все так и оставить в отдельных файлах и поставить http/2 ...

Если можно было его так просто поставить...

@jsunderhood пришёл добрый @kinday и принёс на сайт Лайкли от @ilyabirman
Проверяйте jsunderhood.ru pic.twitter.com/vY8SPqaVaw

Кстати, каждый ui разработчик должен отличать дефис от тире и ставить в тексте правильные кавычки.Это очень просто с раскладкой @ilyabirman

Оказывается [1,2,3].map... — это не функционально, а map([1,2,3], ...) да. Хотя наверное стоило догадаться и без Elm.

Никак не могу выбрать шрифт и редактор, борьба идет между fira и droid, и между atom и webstorm.

@jsunderhood Source Code Pro!

@jsunderhood на самом деле функционально это так: map(some, arr)

@jsunderhood Точнее `map(fn, coll, ...)`. Данные всегда в конце.

@jsunderhood после этого плагина atom.io/packages/atom-… только atom

Почему я не пользуюсь атомом всегда (мне он тоже очень нравится) — мне очень удобно работать с гит в вебшторме.

@naorunaoru плюсую. Я чего только не перепробовал, и только он прижился @jsunderhood

@jsunderhood Sublime и Hack! И будет тебе счастье. github.com/chrissimpkins/…

По поводу тем: уже довольно давно я использую только светлые темы, мне код читать проще.

@jsunderhood я вас умоляю, любое "проще" результат привычки :) правильнее говорить "не пробовал использовать хотя бы неделю"

Да пробовал, конечно. Просто гораздо удобнее нажать кнопку, тут же зарезолвить конфликт, и тут же писать код.

Хотя наверное стоит привыкать делать все через терминал

@jsunderhood, теперь имя текущего автора красуется на главной: jsunderhood.ru

Время фразы: «Мам, смотри, я в телевизоре!»

Пришла пора прощаться. Спасибо большое всем за внимание, спасибо что читали и отвечали, с вами было интересно! В эфире был @milk_is_my_life