Архив недели @milk_is_my_life
Понедельник
Всем привет! С вами в эфире @milk_is_my_life. Последние 6 лет я занимаюсь фронтэндом, работаю в SPB TV.
Т.к. компания совсем небольшая в мои обязанности входит все, от собственно кода до окружения для тестирования, деплоя и запуска на серверах
Мы используем continuous integration (teamcity), а для production-серверов - docker. А что вы используете для запуска приложения?
Говоря простыми словами, докер - это легкая и "дешевая" виртуальная машина. Для ее запуска не требуются дополнительные мощности и вес (...)
(...) образов также умеренный. Таким образом, на выходе мы имеем полностью изолированную среду (ос) для запуска приложения.
Если у вас не один проект, то, что-то подобное вам необходимо. Т.к. вы можете использовать разные версии nodejs, разные конфигурации nginx
И наконец, самое важное - полную переносимость и масштабируемость. Нужен еще один сервер? Просто запусти на нем еще один контейнер!
Ну и конечно - эта технология все еще молода. Нестабильная работа в ряде случаев, непонятные баги и косяки, совместимость с разными (...)
(...) версиями ядра линккс - все это иногда добавляет ложку дегтя, куда же без нее в нашем деле.
Тред (@milk_is_my_life)
никто, лучше самого разработчика, не знает, как должна быть настроена среда для запуска его приложения.
окружения для запуска своего проекта - задача разработчика. также, как и деплой, например.
статику, и как именно. кроме того, допустим, у вас на 1 сервере 5 приложений. как конфигурить nginx в этом случае?
(…) потребуется это же приложения на другом сервере - могут возникнуть конфликты конфигураций
пример базового конфига. на выходе мы будем иметь образ с установленной centos7, nginx, nodejs 4.1.1 и собственно нашим приложением.
недоступен
давайте параллельно запустим еще один тред. его тема - деплой. после того, как вы определились с развертыванием приложения, как вы это (…)
приложение доставите на сервера? ssh, rsync, etc? мы выбрали для этой цели ansible. сложновато на первых порах, но оно того стоит.
а как деплоите вы?
запускаем вместе. это разруливается в entrypoint
их приложение (рельсовое) состоит по-моему из 4 или 5 контейнеров: сайдкик, бд, рельса, что-то еще.
Тред (@milk_is_my_life)
отличный вопрос и это следующая наша тема - окружение для разработки. мы решили не использовать докер при разработке, потому что это
оказалось неудобно - на линуксе и маке докер работает по-разному, плюс не совсем понятно как развернуть наш привычный стэк с 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!
Тред (@milk_is_my_life)
почему мы не используем gulp/grunt/broccoli/…? потому что у нас есть nodejs! а заботу обо всех source файлах на себя берёт webpack.
а в dev-моде с помощью его middleware мы получаем удобное средство для апдейта приложения без перезагрузки страницы.
итого: webpack → nodejs (наше универсальное приложение) → webpack middleware (+react-transform) → browsersync.
у меня, кстати, практически нет личных проектов. у меня ни разу еще не получалось заниматься чем-то своим вместе с основной работой.
а если всё-таки я начинал заниматься каким-то "левым" проектом - значит я лентяйничал на работе или просто не было интересных задач =)
так вот. если у вас есть личные проекты, раскройте секрет - как вам это удаётся?
пожалуй, единственный реальный кейс, который видится мне - ты в рамках своей основной задачи решил какую-то проблему, и это похоже на либу
а также способствует более удачному хайрингу. а также привлекает сообщество, которое помогает исправлять баги и развивать продукт.
я полностью согласен. примеры: kitty php от vk, reactjs от fb.
посмотри gist. внутри синхронного чая используется асинхронный вызов. этот подход удобнее, чем оборачивание в плагины.
я не хочу заморачиваться с done(), это ведь неудобно в тестах, так?
ну т.е. если ты работаешь в компании, где никто не хочет ничего менять - мб стоит сменить её?
перечитал, и понял какой неудачный каламбур получился =) я имел ввиду смену работы, конечно. а то ведь и jquery работает, зачем нам SPA?
Тред (@milk_is_my_life)
Раз такая пьянка, давайте пройдемся по выбранному стэку. Начнем с реакта, конечно, он же такой модный :)
Итак, почему мы выбрали его. Это был долгий путь, мы последние 2-2.5 года писали на нокауте (mvvm- паттерн). Но затем стало понятно, что
Этот подход плохо сочетается с переносимостью. В условиях, когда у тебя параллельно 5-6 проектов, это невероятно дорого.
Далее был рассмотрен hmvc, который вроде бы решал эти проблемы, но не до конца и опять-таки основная боль виделась в M и C
Ну и в итоге мы поняли, что правильный путь - компоненты. Мы стали использовать компоненты, которые предоставляет knockout, это было почти
То, что нам нужно. Но нам сильно стал мешать 2-way data-binding, который вносил много путаницы. Таким образом мы и пришли к реакту.
Все маркетинговые штучки типа виртуального дома, сервер-рендеринга к нам пришли уже сами собой, и мы им очень рады, нет проблем с сео,
Тред (@milk_is_my_life)
Именно! Самая большая прелесть состоит в том, что кодовую базу на компоненты удается переводить, а не писать все с нуля.
Я так понимаю речь идет про реакт? Если да, то я не смогу помочь, т.к. пришел в него уже опытным разработчиком, и мне хватило документации
Для меня это все началось с nerds.airbnb.com/isomorphic-jav…. Но тогда я даже не мечтал, что смогу сделать что-то подобное, про реакт не слышал ничег
Мне казалось, что за этим должны стоять огромные компании, и сотни суровых разработчиков. А потом появился реакт, и это стало доступно всем
Помню прибежал тогда к рубистам, говорю, смотрите, как было бы круто! Вернуть не пустую страницу с крутилкой, а сразу маркап, не вкрячивать
пререндер, а просто заботиться о мета тэгах и правильной верстке. ну они конечно не поняли ничего, чуть в дурку не сослали.
Если быть честным, они до сих пор не очень в курсе, что там за контейнер с нодой появился, и зачем она нужна для обычной статики :)
Тред (@milk_is_my_life)
А будет холивар с поклонниками CSSInJS? Запасаться попкорном? :)
Холиваров много не бывает ☝
Следующий элемент нашего стэка - сасс. Выбор был прост, мы его используем уже давно, все наши проблемы он успешно решает.
На всякий случай посмотрели на postcss, посмотрели на css-модули, не смогли придумать проблем, которые они бы нам позволили решить
Стили конечно с компонентами живут, а изоляция обеспечивается бэм-именованиями классов
Мы импортим стили прямо в компоненте, нам вебпак позволяет это делать.
Ну в целом я с вами согласен, мне не очень нравится как все получается с бэмом.Но перейти на css-modules будет очень просто,вернемся к этому
Почему же? ExtractPlugin в продакшн выносит все стили в отдельный файл.
Вторник
Интересная мысль. Но я говорю про тот 1%, который тестировать тоже надо
Завтра мы с вами обсудим самую сложную часть нашей системы-работу с данными. Флакс, редакс, mvc, mvvm, baobab, angular (не знаю как назвать)
пожалуй, я тут соглашусь. я не знаю, почему мы не взяли просто css-modules =)
Дело в том, что каналы загружаются еще на сервере, а проверка геопозиции происходит уже на клиенте. Фактически это баг, я поправлю.
Давайте поразрушаем стереотипы? Стереотипы будем брать из твиттера про руби.Там почему-то тоже обсуждался реакт.Ну а что им еще обсуждать?)
Стереотип 1. Реакт, это не темплейт энжин, jsx !== jade|hbr|etc. То, что реакт умеет рендериться в строку и даже в нейтив - его природа
Стереотип 2. Раз реакт такой крутой, то как мне сделать ...? Реакт настолько крут, что вы даже приложение должны писать сами.
Ну и конечно же, скорость виртуального дома.Забудьте о виртуальном доме, вам надо писать приложение. Ом, элм, virtual dom, берите,что хотите
Если же вы не знакомы с хаскелем или хотите писать для браузера на жс - реакт на данный момент отличный выбор!
Ну и последний стереотип: реакт - не панацея. Да, скоро появится что-то новое. Но то, что он принес в жс - выгодно его отличает от
Фреймворков старого образца: смотрите, у нас такой 2-way, а у нас такой, а у нас директивы, а у нас коллекции, своя система модулей и т.д.
При таком подходе (1 nginx), никто не гарантирует, что ваши конфиги не будут конфликтовать друг с другом. Не всегда это так, но разгребать
Горы конфигов каждый раз было мучительно
Ну так статика - это наше приложение, а сдн - наши сервера. Это никак не противоречит идее изоляции приложений на сервере, так?
Job Safe Driven Development
Ну что, переходим к вопросу о работе с данными. Мы выбрали redux by @dan_abramov. Почему? Начнем с критериев отбора:
возможность "кэшировать" данные. пользователь, загрузив список фильмов, например, должен иметь возможность открыть страницу с фильмом
или если пропадёт интернет (на мобилке) он должен иметь "ходить" по приложению, видя те данные, которые уже были им загружены
таким образом вопрос "кэширования" сводится к вопросу удобной работы с данными на уровне данных, если проще - минимум абстракций
почему, например, мы не взяли бекбон с его моделями и коллекциями. потому что работать с коллекциями, в которых у моделей есть связанные
сущности - очень и очень сложно. гораздо проще оперировать js-сущностями, такими как массив, хэш, используя встроенные методы map, reduce…
абсолютно верно! это я еще не подошел к redux, это я просто говорю, почему не backbone.
после того, как мы поняли, что флакс - то, что нам нужно, мы стали уже перебирать реализации. пописав на "классическом" быстро поняли, что
это мука. очень много бойлерплейта, "независимые" сторы, waitfor и т.д. тогда же попался на глаза очень приятный flummox, который
вскоре стал deprecated в пользу redux. также, мы всерьез рассматривали baobab (christianalfoni.github.io/javascript/201…) и nuclear (github.com/optimizely/nuc…)
но как обычно в таких делах грамотный маркетинг, и простота api redux довольно легко уделали всех конкурентов. +хот-релоад, система плагинов
Тред (@milk_is_my_life)
Давайте поговорим про окружение для разработки. Когда-то мы использовали nginx и галп вотчеры, теперь вебпак и браузерсинк. Хот релоад-круто
Помню эти муки, как повторить стейт, в котором у тебя поехала форма, или вообще ошибка произошла какая-нибудь
Я не знаю откуда у меня столько ностальгии, сегодня просто был тяжелый день :)
Хотелось помечтать, налетели рубисты
Может о чем-нибудь отвлечённом? Смотрит кто-нибудь цска, болеет за ребят?
Среда
А кто-нибудь пишет функциональные тесты? Понимаю, что это задача тестировщиков, но тем не менее
Недавно задумал на тимсити перед собственно деплоем прогонять тесты на приложении. Понравился casperjs.
Между тем, из стандарта es7 убрали object.observe. Мне вот сразу казалось это крайне сомнительной фичей.
Хотел еще спросить, кто еще не использует es6 в работе? Мы вот хоть и с боями, но перешли на него в начале года. Только хорошие эмоции
Четверг
интересна тема обучения.последнее время появилось невероятное кол-во курсов, учебников и пр.но лично для меня эталон learn.javascript.ru
возможно не все знают, но learn.javascript написан на nodejs и его код находится в open source. github.com/iliakan/javasc…
кстати, у меня такой вопрос. документируете ли вы код, и какие средства для этого используете? любимый jsdoc, к сожалению, не понимает es6.
вроде как есть возможность использовать dev-версию jsdoc, кто-нибудь настраивал?
Пятница
второй день подряд полностью поглощен докером =) удалось перенести все процессы (тесты, генерацию документации, e2e и т.д.)внутрь контейнера
для генерации документации тоже нужно специально окружение (nodejs), это окружение поднято в докере
один ci используется для многих проектов, и каждому может потребоваться своя версия ноды, например
nvm не решает всех проблем: может различаться ос, и компилируемые пакеты могут не заработать.
because we are using private git repository and self-hosted teamcity as CI server
Конечно реальные, у меня на ноуте мак, на прод серверах центос, как мне собрать контейнер локально? (Если нет доступа к ci)
Хочу начать изучение нового языка.Не для практических целей, а скорее для более фундаментальных знаний.Выбираю между scala, closure, haskell
Самый большой опыт - js, писал на c, c++. Немного на руби и пхп.
Это, кстати, мой комплекс - я думаю, хороший программист обязан свободно владеть набором языков. Даже если в работе используешь только 1.
Так докер - это тоже виртуалка, и апнуть версию centos, в ней гораздо проще. Кроме того, образы можно наследовать, что добавляет гибкости
Ну это как с выбором фреймворка для js - я не хочу учиться писать классы 1000 и 1 способом, хочу больше думать про алгоритмы и стр. данных
Ну и с человеческим синтаксисом, конечно. Поэтому не с, например. (Не хочу никого обидеть, это личное мнение)
Ну я же начал с того, что хочу выучить новый язык. Js позволяет многое конечно, но есть и другие
Это конечно субъективно, но таких компаний все меньше. Например, у нас знание фреймворков вообще неважно, важно лишь знание языка и опыт.
Причем опыт программирования на любом языке.
боюсь, что меня обвинят в очередном холиваре, но я не согласен ни с одним выводом. а раз ведущий на этой неделе я, то я расскажу свою правду
ни angualr, ни ember, ни knockoutjs, ни react, ни что-нибудь еще не предложили миру "своих" паттернов. максимум - свои реализации mvc,mvvm..
программист неплохого уровня сможет достаточно быстро "пересесть" с одного фреймворка на другой, даже если они написаны на разных языках
не специалист в вопросе поиска работы — но в России по-моему работают хорошо 2: linkedin и hh
У нас внутри компании был случай, когда js стал рубистом, а еще на работу во фронтэнд взяли студента 5-го курса с опытом java.
И оба - прекрасные специалисты!
А вот хороший вопрос. А вот не знаю :) но думаю, что выучив раз, легко вспомнить по справочнику.
Суббота
Я знаю куда его применить. @nikitonsky не даст соврать, идеи одного языка отлично работают в другом
Не думаю, что closurescript больше подходит для фронтэнда, чем что-либо
@jsunderhood а нам ведь так не хватает принципиально новых паттернов...
мы используем bugsnag, он платный. насчет логгирования не знаю даже, консоль? а вообще всё зависит от требований.
Разделяете ли вы итоговый код приложения на бандлы? Если да, то каким образом? Мне способ с require.ensure кажется громоздким, и особого
Смысла в таком разделении я не вижу. Буду ждать либо человеческий апи (в идеале его отсутствие), либо уже системные лоадеры js
Это я не про бандл с вендорами говорю - его как раз стоит выделять и кэшировать на клиенте.
Если можно было его так просто поставить...
Воскресенье
Кстати, каждый ui разработчик должен отличать дефис от тире и ставить в тексте правильные кавычки.Это очень просто с раскладкой @ilyabirman
Оказывается [1,2,3].map... — это не функционально, а map([1,2,3], ...) да. Хотя наверное стоило догадаться и без Elm.
Никак не могу выбрать шрифт и редактор, борьба идет между fira и droid, и между atom и webstorm.
@jsunderhood atom + fira ванлав pic.twitter.com/aAfugpxS64
А лигатуры откуда? twitter.com/iamstarkov/sta…
Почему я не пользуюсь атомом всегда (мне он тоже очень нравится) — мне очень удобно работать с гит в вебшторме.
@jsunderhood у меня атом считай не работает на 4к мониторе,все пищит и глючит. Вообще после полугода на атоме возврат на саблайм — как домой
А у меня с ресайзом проблемы. Чуть окно подвинул или на другой монитор перетащил — лови артефакты twitter.com/sevaisnotcow/s…
По поводу тем: уже довольно давно я использую только светлые темы, мне код читать проще.
Да пробовал, конечно. Просто гораздо удобнее нажать кнопку, тут же зарезолвить конфликт, и тут же писать код.
Хотя наверное стоит привыкать делать все через терминал
Пришла пора прощаться. Спасибо большое всем за внимание, спасибо что читали и отвечали, с вами было интересно! В эфире был @milk_is_my_life
