И отдельно про начинающих разработчиков — полностью согласен

Проблемы разных компаний: Дмитрий Мананников по мотивам статьи о проблемах больших компаний приводит доводы «за» и «против» работы как в больших компаниях, так и в стартапах — http://telegra.ph/Problemy-raznyh-kompanij-11-09

Последний шанс попасть на воркшоп! Начнётся сегодня в 13:00 по Москве

​​Что нужно сделать, когда выпускаешь приложение в продакшен (load balancing, логгирование, деплой без недоступности приложения и прочее).

Чеклист Алексея Мигутского: https://github.com/mr-mig/going-to-production/blob/master/serverside-checklist.md

#учу_nodejs_в_продакшене

Антон пишет про пункт Security во вчерашнем чеклисте:

Ну там в основном хорошие вещи кроме пары непонятных моментов, меня больше всего security смущает

Public-Key-Pins

он уже умирает https://www.theregister.co.uk/2017/10/30/google_hpkp/

потом HSTS и HPKP это опасные вещи, которыми несложно надолго или навсегда окирпичить свой сайт

я уже с этим сталкивался как пользователь: магазин в минске напечатал адрес на своих дисконтных картах, а эта страница навсегда сломана из-за HSTS, а перепечатать адрес на всех картах они не могут

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

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

а если и решил, что они стоят того, то использовать их очень осторожно

​​Подробнее про продакшен-практики.

Как балансировать загрузку, деплоить без даунтайма, перезапускать проект после рестарта сервера и писать логи/считать метрики: http://caines.ca/blog/2014/06/01/production-quality-node-dot-js-web-apps-part-i/

#учу_nodejs_в_продакшене

Андрей Романов суммирует, зачем и как разбивать файл с кодом приложения на несколько файлов поменьше ↓

(+ А я писал, как делать это в Вебпаке: https://iamakulov.com/notes/webpack-front-end-size-caching/#task-improve-caching)

Введение в кодсплиттинг (по мотивам доклада с React Conf 2017)

Склеивать весь JS в один большой бандл — плохой тон. Если код приложения немного изменился,
пользователю придётся заново скачивать не только обновлённый код самого приложения,
но и все его зависимости (например, React, Angular и другие довольно тяжёлые библиотеки
и фреймворки).

Большой бандл нужно разделять как минимум на две части: первый файл — все зависимости
приложения, они меняются редко; второй файл — сам код приложения, он меняется
гораздо чаще. Подключаемые файлы нужно кешировать, чтобы пользователь
скачивал только изменённые файлы. При таком подходе после каждого обновления приложения
пользователю не придётся заново скачивать все те же зависимости.

Можно пойти ещё дальше и разделить приложение на файлы, содержащие логику
отдельных частей приложения. Для этого в будущем появится нативный механизм
асинхронной загрузки ES-модулей, который, тем не менее, можно использовать уже
сейчас. Это динамический import(), его особенности:
— на текущий момент stage 3;
— работает со вторым Вебпаком;
— возвращает промис;
— позволяет использовать динамические имена модулей;
– требует babel-плагин syntax-dynamic-import.

Запись воркшопа по Вебпаку с позапрошлой субботы: https://www.youtube.com/playlist?list=PLTbz5Wv5vNcs0zKKmF0DSo6m05RnMqUXk

Давайте поможем Дену:

привет! Можно обратиться к тебе с просьбой? Готовлю доклад, пока что для локального митапа (а дальше посмотрим), должно получится интересное исследование. Тема -- различие мобильных веб приложений и нативных; всевозможные баги, хаки, что можно и что нельзя пофиксить. В черновике уже есть кейсов 10, но хочется покрыть больше. Репостнишь в канал? Писать сюда -> @denilin

​​Про преимущества веб-приложений, кстати, есть классная статья Ильи Бирмана: The future of the web and native apps