milk_is_my_life

2 ноября 2015, Saint Petersburg, Russia

# Понедельник 141 твит

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

7:35

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

7:39

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

7:45

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

8:13

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

8:15

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

8:23

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

8:35

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

8:37

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

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

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

9:30
@jsunderhood как вам тимсити? Сложно первый раз было запускать/настраивать?
9:50
@jsunderhood тогда слишком много надо знать, чтобы быть хорошим во всем, я, считаю, не зря это все делегируется
9:51

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

9:53
Есть такая штука "Full Stack engineer" - его задача, не смотреть на все через "щель" в люке @hellbeast92 @jsunderhood @jsunderhood
9:54
@jsunderhood фронтенд в docker контейнерах? Только если под фронтендом подразумевается universal приложение. А это далеко не всегда так.
9:54

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

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

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

9:58
@jsunderhood еще как поддается. Есть package.json. Договоритесь в команде, об описании интерфейса в package.json и автоматизируйте
10:02
@jsunderhood вы же предлагаете docker. Это значит что стандарт - это просто бинарник докера. А что и как внутри - забота отдельного
10:02
@jsunderhood программиста. В итоге каждый внутри будет делать как захочет. А это еще хуже.
10:02

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

10:10
@jsunderhood я не вижу что хорошего в том, что снаружи все хорошо, а внутри как прийдется. Представь себе червивое яблоко.
10:13
@jsunderhood пока яблоко не трогаешь - оно снаружи красивое. А если нажать немного, развалится. Вот такая у меня аналогия.
10:13
@jsunderhood не-не. Изоляция тут вместо стандарта внутри приложения. Вот это и вызывает такую аналогию. Изоляция - ок, вне этого контекста.
10:16
смотрится круто, но как решается базовая задача "zero downtime deploy"? @jsunderhood
10:18

недоступен

10:21
Docker - это как минимум еще один слой для возможного падения. Но он не достаточен для создания "production ready" системы @jsunderhood
10:23
@rubyunderhood @jsunderhood подтверждаю, были случаи неодинаковой работы аппы в контейнере на разных системах, вплоть до отказа
10:26
Конечно есть. Наелись им как и распираемым react - leopard.in.ua/presentations/… - как говорится минимум для "docker" @jsunderhood
10:28
А значит придется использовать еще какие то слои, для полноценного решения, что увеличивает количество улов отказа @jsunderhood
10:33
@gusnkt @jsunderhood это вопрос организации команды
11:12
@gusnkt @jsunderhood всегда есть переключение контекста
11:13
@hellbeast92 достаточно понимать что это, как и зачем. Иначе будут «негодные админы, которые нам билдить на сервере не дают» @jsunderhood
11:14
@shuvalov_anton @jsunderhood @hellbeast92 умение поднять свой собственный CI очень важно
11:16
@iamstarkov @jsunderhood @shuvalov_anton @hellbeast92 Есть неплохой self-hosted CI - drone.io
11:18

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

11:34

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

11:36

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

11:36
@jsunderhood отдельная git ветка production и автоапдейт по этой ветке
11:54
@jsunderhood `$git push dokku master` кажется ок
11:55
@jsunderhood э, ребята, вы Docker то читали? Вы просто перенесли свою виртуалку в docker, а это не docker-way
11:55

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

12:08
@jsunderhood в Docker главное правило: 1 контейнер - 1 главный процесс с PID 1, он сам выступает в роле супервайзера
12:08
@jsunderhood если наборот, то зависнет одно из приложений в контейнере: место кончилось, очередь образовалась, что-то еще — хана контейнеру
12:09
@jsunderhood у вас должно быть например 3 контейнера app-nginx, app-node, app-database
12:16
@jsunderhood и выкатывать приложение только в app-node, и если на лету код не подхватывается, то рестарт мелкого контейнера будет шустрым
12:16

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

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

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

12:35

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

12:36

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

12:38

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

12:55

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

12:58

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

13:00

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

13:01

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

13:09

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

13:10

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

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

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

13:47

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

13:49

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

14:03
@jsunderhood ну некоторые компании поощряют личные проекты, выделяют там дни на них, особенно если это open source
14:05
@jsunderhood личные проекты разные бывает, если ты в рамках своей основной работы решил какую-то общую задачу это можно запулить в опенсурс
14:14
меньше сплю и выделяю на не важное ("игры", "сериалы/кино") меньше времени @jsunderhood
14:14
@jsunderhood я думаю, что хотя бы завести свой бложик - это уже неплохой свой проект
14:14

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

14:16
NDA главное при этом не нарушить :D @lapanoid @jsunderhood @jsunderhood
14:16
.@rubyunderhood @lapanoid @jsunderhood вот кстати насчет опенсорса на рабочем месте. По сути - ты тратишь деньги работодателя - на опенсорс
14:16
.@rubyunderhood @lapanoid @jsunderhood у нас, все что сделанно на работе - принадлежит компании. Опенсорс - в свободное время.
14:16
@jsunderhood эм, именно chai-as-promised и берет на себя заботу, завернуть done в промис.
14:17
У меня был такой - оплачивал опенсорс, что получался из проектов, но он был под акаунтом компании заказчика @mr_The @lapanoid @jsunderhood
14:18
@mr_The @rubyunderhood @jsunderhood Я не предлагаю втихую выкладыать это равносильно воровству. Можно убедить работодателя что это выгодно
14:19
@mr_The @jsunderhood @rubyunderhood @lapanoid это плохая позиция, надо ко всему подходить с умом. хороший опенсорс — HR брэнд для компании
14:20
github.com/sendgridlabs/g… - пример такого опенсорса @mr_The @lapanoid @jsunderhood
14:20
@mr_The @jsunderhood @rubyunderhood @lapanoid что выливается в экономию денег компании
14:20

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

14:22
Или же наоборот - риск потерять лицо компании. Когда ты сам - проще @sevaisnotcow @mr_The @jsunderhood @lapanoid @jsunderhood
14:22
@mr_The @rubyunderhood @jsunderhood в опенсорсе код который вы отдали бесплатно, бесплатно улучшается и тестится комьюнити + travis и проч
14:22
Если он вообще кому то потребуется - а может так же успешно и "загнивать" в публичном репозитории @lapanoid @mr_The @jsunderhood
14:23
@rubyunderhood @sevaisnotcow @mr_The @jsunderhood какой-то сумрачный риск, прохие проекты редко громкие ими просто не пользуются
14:23

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

14:24
@rubyunderhood @jsunderhood @mr_The это означает, что решили не общую задачу, или непонятно как использовать - тайные знания внутри компании
14:25
@jsunderhood нет, ты не понял. async функция возвращает промис. chai без плагинов не понимает промисы.
14:25

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

14:26
Проблема, что мы любим указывать на success case, но плохих еще больше - просто о них не трубят @lapanoid @jsunderhood @mr_The @jsunderhood
14:28
done() callback в помощь, что бы тест дождался @jsunderhood
14:29

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

14:29
@gusnkt @jsunderhood Зато mocha понимает.
14:29
@rubyunderhood @jsunderhood Нет, done как раз нужен был до промисов, с ними нет смысла.
14:29
@rubyunderhood @jsunderhood @mr_The критика это часть культуры opensource, если есть страх ее - нет смысла выкладывать
14:30
почему не удобно? тот же контроль выполнения кода (я сообщил, когда тест кейс завершился) @jsunderhood
14:31
Поэтому одному и проще: компания может быть не заинтересована в подобном риске (им и так хорошо) @lapanoid @jsunderhood @mr_The @jsunderhood
14:31

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

14:34

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

14:35
Подход - "все в опенсорсе становится лучше" - точно не работает всегда @jsunderhood @lapanoid @mr_The
14:35
@RReverser @jsunderhood @rubyunderhood просто return промиса делаем и счастье
14:49
@jsunderhood каламбур как раз удачный)
15:06
@lapanoid Критики бояться не стоит. Выложил код, получил горшок говна и знаешь куда подрости :) @rubyunderhood @jsunderhood @mr_The
15:57
Немного про инструменты. Один из самых популярных инструментов у меня в работе — виртуалки с разными IE.
16:29

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

18:23

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

18:25

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

18:26

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

18:28

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

18:30

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

18:31

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

18:32

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

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

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

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

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

18:55

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

18:56

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

18:59

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

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

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

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

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

19:05
@jsunderhood уже ж был
19:18

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

19:19

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

19:44

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

19:46
@jsunderhood а стили вместе с компонентами не распространяете? У вас же там горстка проектов?
19:49
@jsunderhood или стайлгайдом все покрыто?
19:49

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

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

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

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

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

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

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

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

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

21:42

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

21:46

# Вторник 75 твитов

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

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

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

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

7:22

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

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

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

7:41

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

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

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

7:46

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

7:47

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

7:51

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

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

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

8:12

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

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

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

8:15
@rubyunderhood @jsunderhood @as_Crazy @rainrb Это не обязательно, чтобы использовать эффективно реакт. Достаточно понимать концепции.
8:16
@jsunderhood обновления на сайте jsunderhood.ru
например jsunderhood.ru/RReverser/ и у всех авторов тоже pic.twitter.com/eQubaISatM
10:03
@denysdovhan @jsunderhood Problem Driven Development
10:38

Job Safe Driven Development

10:39

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

10:42

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

10:44

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

10:45

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

10:47

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

10:48

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

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

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

10:52

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

10:53
Ну если взяли react, то какой уже backbone в таком случае? @jsunderhood
10:55
На react нужен pub-sub (flux), а не MV* @jsunderhood
10:56
@jsunderhood я делал гугл табличку - по критерию выписывал как каждый flux соответсвует goo.gl/x84KPf + есть репа со всеми flux
11:09

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

11:10

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

11:11

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

11:13

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

11:15
@jsunderhood а проблем с роутингом у вас нет? Вот у меня есть ключевая проблема с flux и redux - где хранить данные, нужные одной странице?
11:56
@lapanoid @jsunderhood Кстати Redux сейчас не имеет зависимости от React (в табличке имеет)
11:58
@jsunderhood @lapanoid Oh shi~~~ Поправьте чтобы сохранялся выбранный язык! Хотя бы в пределах сериала. )
12:01
@jsunderhood не, ну допустим у вас есть список постов и страница на пост. Где хранить 1 пост?
12:11

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

16:54

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

16:57

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

16:59

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

17:01

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

17:03
@jsunderhood когда-то я херачил код script'ами в head, а теперь кладу ссылками в конец body и внутри оборачиваю в !function(){}()
17:03
Пишу на universal - node, react, hot-reload, прочее счастье. Но тут возник вопрос: неужели нет hot reload для express? @jsunderhood
17:15
@rubyunderhood @jsunderhood миддлвары мутирующие res, мне кажется сильно осложняют задачу
17:15
@jsunderhood но раньше можно было еще и исправить код в браузере, который обновлял файлы в проекте.
17:16
@jsunderhood так вот это было еще круче чем эти ваши хот-релоады :)
17:28
А по поводу отключения - с движением в SPA это пока мечты. Сейчас многие будут смеяться, если им сказать "а если JS выключить" @nick_jastix
18:59
Такоя я могу тоже без JS :D @jsunderhood @nick_jastix pic.twitter.com/5oNmCYN5Wp
19:02
Перейти то я могу, но толку от этих квадратов Малевича? @jsunderhood @nick_jastix pic.twitter.com/W2GJoKbxzq
19:06
@jsunderhood @rubyunderhood @nick_jastix до полной загрузки страницы выглядит страшненько (WP8.1) pic.twitter.com/clER14o0dY
19:07
Хороший пример - try.discourse.org, который написан на Ember, но при отключении JS работает @jsunderhood @nick_jastix
19:12
@rubyunderhood @jsunderhood современный веб: на одном сайте нужно отключить жс, чтобы работало. На другом - включить.
19:13
Обфускаторы сборки React, которые не позволят так нагло оперировать props и state в prod @jsunderhood @nick_jastix pic.twitter.com/4tCXUAeoXi
19:27
В разнообразии сила. Пример: доминирование IE6 в вебе к чему привело @jsunderhood @nick_jastix pic.twitter.com/GIyZygDtEM
19:31
Да потому что веб перерос этот язык. Поэтому у нас появились babel, typescript, coffescript и прочие препроцессоры @jsunderhood @nick_jastix
19:45
Реально? Такие вопросы? Да на них кто угодно ответит @jsunderhood @nick_jastix
19:55

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

19:55

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

20:43
@jsunderhood нет, только не футбол! Давай лучше про фичи es7. async/await использует кто-нибудь уже? Как ощущения?
20:52
@jsunderhood а bind-operator? Я на него и сам подсел, и коллег подсадил и теперь немного волнуюсь, что оно в стандарт не попадёт.
21:26
@jsunderhood а что значит «плохо транспилится»? Неэффективно? Отлаживать неудобно? На первый взгляд вроде норм.
21:30
@maxmaximov @jsunderhood Если я не ошибаюсь то вы можно попробовать async/await в новом IE с чакрой.
21:53
@xgrommx @jsunderhood ну да, это просто сахар (как и половина всех новых фич из es6/es7)
21:53
@jsunderhood @maxmaximov поподробней плз. На нагрузочных тестах по скорости и памяти сервис полный async/await показал себя вполне норм.
21:53
@xgrommx @maxmaximov @jsunderhood
Это называется T_PAAMAYIM_NEKUDOTAYIM /cc @RReverser
21:55
@jsunderhood 50rps на 6 воркерах (6 cpu), нагрузка на фронте <30%, дальше сдохло api. Повторить не смогу, уже ушёл с этого проекта.
22:03

# Среда 20 твитов

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

12:25

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

12:26
@jsunderhood С чего это задача тестировщков? Всегда писал такие тесты сам.
13:35
@jsunderhood Что именно интересно? :)
13:42

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

13:45
@jsunderhood решал проблему рефакторинга недокументированного легаси. Предварительно покрывал смесью функциональных и юнит тестов.
14:20
TDD, BDD - тесты пишут девелоперы @jsunderhood
14:20

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

14:28
@jsunderhood ещё не убрали, только собираются esdiscuss.org/topic/an-updat…
15:21
@jsunderhood с Babel перешли или как?
15:21
@jsunderhood Только stage 0, только хардкор :)
15:22
@jsunderhood интересно ваше мнение. Почему для вас кажется это сомнительной фичей?
15:48
@jsunderhood у нас переходят на TypeScript. Поэтому моя консоль теперь всегда красная
16:24
@jsunderhood из аргументов называли: CommonJS, es6, типизация, проще понимать. На практике я вижу больше минусов, чем плюсов
16:31
@jsunderhood а библиотеки для совместимости какие-нибудь использовали?
16:36
@jsunderhood чем понравился casperjs? Он же нерасширяемый!
19:31
@jsunderhood он подсаживает на себя. Потом понадобится прикрутить что-то к тестам, а не получится. Лучше разделить framework,asserts,browser
19:46
@jsunderhood Не первый это скажу, но автоматизированные тесты есть задача разработчика. Тестеры пусть делают то, что сложно формализовать
21:05
@jsunderhood собрать стек самому из phantomjs, mocha и chai например. Или из jest с чем-нибудь
21:05
@jsunderhood @boriscoder Selenium + mocha + chai
21:06

# Четверг 12 твитов

@jsunderhood пишу и мне кажется это задача dev'ов если нет тестера, а часто его нет. С тестами есть уверенность
6:38
@VovanR @jsunderhood а какие минусы?
6:59
@dmitryshimkin @jsunderhood например сторонние либы в основном идут без tsd, а те, что есть, часто устаревшие. Консоль всегда красная =(
6:59
@VovanR @jsunderhood @dmitryshimkin да взял тайпскрипт на проект с реактом. выпилил уже, задолбало поддерживать =(
7:05

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

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

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

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

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

15:17

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

15:18

# Пятница 52 твита

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

15:06

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

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

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

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

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

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

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

15:21
@jsunderhood why not @droneio from the start?
15:23

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

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

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

18:19

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

18:23
@jsunderhood брейнфак рулез! Он вечен. Остальные рано или поздно умрут.
18:25
@jsunderhood А какие знаешь?
18:25

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

18:29

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

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

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

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

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

18:47

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

18:48
@Semenov @jsunderhood плюсую за clojure) а потом - haskell
18:50
@jsunderhood Дляобщего развития можешь Clojure попробовать
18:52
@jsunderhood так это и на js тогда можно
18:57

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

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

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

19:03

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

19:04
@jsunderhood ну и зря, какой бы огромный опыт велосипедов у тебя не был, фреймворк диктует свои паттерны и имеет определенные особенности.
19:09
@jsunderhood нанимать того, кто с ними не знаком — потеря времени и вероятность говнокода или того, что разработчик просто не справится.
19:09

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

19:11

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

19:12

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

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

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

19:21

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

20:12

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

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

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

20:48
@raxpost @SilentImp @jsunderhood опенсорс жалует новичков
20:56
@SilentImp @jsunderhood бывает сложно придумать небесмысленный проект на новом языке/технологии, а в опенсорс новичков не жалуют
20:57
@SilentImp @raxpost @jsunderhood главная мысль была: зачем учить абсолютно незнакомый язык, не имея понятия, куда его применить?
21:10

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

21:14
@jsunderhood clojure - другой мир совершенно
21:18
@jsunderhood @nikitonsky потом “первый” язык применять вообще не захочется.
21:43

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

21:44
@serhey_shmyg @jsunderhood у нового @moikrug переодически бывают новые интересные вакансии (я именно про их твиттер)
21:51
@jsunderhood он тоже clojure)
21:52
@jsunderhood попробуй и измени своё мнение навсегда :)
З.Ы. язык эт еще не все, экосистема играет большую роль
23:06

# Суббота 14 твитов

@jsunderhood а нам ведь так не хватает принципиально новых паттернов...

:) twitter.com/twenty/status/…

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

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

8:00
@akochemasov @jsunderhood гугл аналитикс ;)
8:11
@akochemasov @jsunderhood, sentry или bugsnag.
8:50
@Chudesnov @akochemasov @jsunderhood нет, нужно самому перехватывать onerror и слать в GA сustom event.
developers.google.com/analytics/devg…
10:00
@Chudesnov @akochemasov @jsunderhood плюсы: гибкость, риайлтайм и вся мощь отчетов GA. Минусы: стектрейсы не войдут, понимает только строки
10:00
Via #reactiflux, how to automatically create a vendor bundle with your #webpack production build: pic.twitter.com/Ynjymnt07U
10:20

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

12:59

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

13:00

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

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

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

18:37

# Воскресенье 19 твитов

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

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

9:15

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

9:22

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

9:24
@jsunderhood Source Code Pro!
9:28
@jsunderhood на самом деле функционально это так: map(some, arr)
9:41
@jsunderhood atom + fira ванлав pic.twitter.com/aAfugpxS64

А лигатуры откуда? twitter.com/iamstarkov/sta…

9:41
@jsunderhood Точнее `map(fn, coll, ...)`. Данные всегда в конце.
9:42
@jsunderhood после этого плагина atom.io/packages/atom-… только atom
9:42

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

9:44
@naorunaoru плюсую. Я чего только не перепробовал, и только он прижился @jsunderhood
9:45
@jsunderhood Sublime и Hack! И будет тебе счастье. github.com/chrissimpkins/…
9:54
@jsunderhood у меня атом считай не работает на 4к мониторе,все пищит и глючит. Вообще после полугода на атоме возврат на саблайм — как домой

А у меня с ресайзом проблемы. Чуть окно подвинул или на другой монитор перетащил — лови артефакты twitter.com/sevaisnotcow/s…

9:56

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

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

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

10:25

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

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

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

16:59

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

19:27

github.com

other