​JS Tidbits - MediaStream API. Статья о том, чем является WebRTC в общем и Mediastream API в частности. Статья не очень глубоко погружается в то, как исользовать данные API, но станет отличной отправной точкой для начинающих → http://bit.ly/2x0yeKF
——————————————
Поддержать нас

​Анимированное руководство по CSS flex. Наглядное руководство о том, как работает flexbox от команды tproger → http://bit.ly/2WNHNw0
——————————————
Поддержать нас

​Styling In Modern Web Apps. Крутой пост с обзором современных способов стилизации приложений. BEM, SCSS, CSS-in-JS и Design systems. Очень рекомендую → http://bit.ly/2XoAutW
——————————————
Поддержать нас

​Нужны ли препроцессоры в 2019 году. Размышления Людмилы Мжачих в своем блоге на Medium → http://bit.ly/2wZR5pd
——————————————
Поддержать нас

​A Deep Dive into Redux. Пишем и тестируем свой Redux на Typenoscript → http://bit.ly/2XUDVWv
——————————————
Поддержать нас

​​Изучаем Docker. Перевод серии статей по основам контейнеризации приложений:

1. Основы
2. Термины и концепции
3. Dockerfile
4. Уменьшение образов и ускорение их сборки
5. Команды
6. Работа с данными

​Темный день для Vue.js. Кликбейтный заголовок)). Но сама статья о новом RFC от Эвана Ю, существенно меняющем апи компонентов и реакции сообщества на него → http://bit.ly/2Funskz
——————————————
Поддержать нас

​Как делать сайты в 2019 году. Набор техник, которые стоит не забывать использовать при разработке сайтов в 2019. Рекомендую → http://bit.ly/2xa0hr1
——————————————
Поддержать нас

​Сервис-воркеры в поиске Google. Подробности внедрения сервис-воркеров для более эффективного кэширования поисковой выдачи и удобной работы в офлайне — http://bit.ly/2IJUwXQ
——————————————
Поддержать нас

​Don’t eject your Create React App. Наткнулся на крутую статью, которую нужно прочитать всем, перед тем как eject-ить свое приложение, созданное через CRA → http://bit.ly/2X4Ndhp
——————————————
Поддержать нас

​The cost of JavaScript in 2019. Свежая статья от Эдди Османи, о том, на что стоить обратить внимание при оптимизации перформанса js-кода и улучшениях в V8 в 2019 → http://bit.ly/2XvVUp3
——————————————
Поддержать нас

​Пузырьковая сортировка на JavaScript. Частый вопрос на собесеедованиях на Миддла и выше, поэтому переходим, читаем → http://bit.ly/2IPkpFH
——————————————
Поддержать нас

​Всё, что нужно знать об async/await. Циклы, контроль потоков, ограничения. Крутой цикл статей о промисах, Event Loop и асинхронщине в джавасткипте → http://bit.ly/2IPXWIG
——————————————
Поддержать нас

​Надёжный JavaScript: в погоне за мифом. Крутое видео от Ильи Климова о том, как писать надёжный и производительный код на js и много всего другого 👍 -> http://bit.ly/2NirZg9
——————————————
Поддержать нас

​Всем привет 😎.

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

В любом случае - спасибо что читаете 😁

​Profiling React performance with React 16 and Chrome Devtools. Хорошая статья, о фишках DevTools, которые помогут вам лучше проводить исследования перформанса в React → http://bit.ly/2LujFYu
——————————————
Поддержать нас

Как работает Google со своим кодом или немного про монорепозитарии.

Google использует монорепозитарий. Это значит:
✅ Что весь код хранится в одном репозитории. Это несколько миллиардов строк кода. Размер репозитория 86 ТБ.
✅ Это значит, что каждый сотрудник имеет сразу доступ ко всем проектам Google.
✅ Все всегда вливается в HEAD (master/trunk).
✅ Все зависимости также находятся в репозитории.

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

Теперь вопросы и ответы:

Вопрос: Как это влияет на деплоймент?
Ответ: Деплоймент это независимая процедура и деплоить они могу свои микросервисы раздельно.

Вопрос: Получается у Google нет ревью кода?
Ответ: Ревью кода и тесты есть, и это ключевая часть процесса разработки. Просто, для этого есть отдельный инструмент/инфраструктура.

Вопрос: Как такой репозитория клонировать на локальную машину?
Ответ: Репозиторий не клонируется, а используется виртуальная файловая система.

Вопрос: Как происходит работа над Chromium, если это open source проекты?
Ответ: Chromium и Android не находятся в этой монорепе.

Вопрос: Если нет версионности и я разработчик какой-то общей библиотеки и я решил поменять API, как не сломать чужой код?
Ответ: Ты должен будешь исправить код всех других проектов, которые зависят от твоей библиотеки. Также каждый разработчик должен помнить, что кто-то другой может обновить библиотеку и поэтому хорошая практика писать тесты для обнаружений проблем со сторонними библиотеками. Также в Google есть хорошие инструменты, которые позволяет быстро найти библиотеки зависимые от твоей и сделать быстро замены в коде.

Вопрос: Если двум разным версиям приложения нужны разные версии рантайма/языка?
Ответ: В Google всегда используется одна версия. Если переводят на новую версию, то все продукты будут переведены на новую версию рантайма/языка. Вместо того, чтобы каждая команда искала инструменты и способы перевести весь код на новую версию рантайма/языка, это сделает централизованно одна команда.

Вопрос: Кто еще использует монорепозитарий?
Ответ: Из того, что я знаю - это Facebook и Twitter

Вопрос: Нравится ли сотрудникам такой подход?
Ответ: Да, большинство сотрудников Google поддерживают такой подход.

В целом, преимущества монорепозитарий сродни преимуществам монолита - это выше консистеность кода.
✅ Использование одного стиля (общий стайлгайд и правила статического анализа)
✅ Зависимость от одной версии рантайма/языка.
✅ Зависимости от одинаковых версий библиотек.

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

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

Но консистеность кода для нас очень важна:
✅ Мы используем единый подход к архитектуре на большинстве проектов (описывал тут https://news.1rj.ru/str/jabanoscript/36)
✅ Мы начинаем проекты с единого бойлерплейта.
✅ Мы активно используем инструменты для статического анализа кода. Мы не просто используем eslint и его плагины по максимуму, мы еще имеем конфиг eslint на всю компанию. И ко всему этому, мы пишем еще свои плагины для eslint
4. Мы используем общий набор библиотек. К примеру для валидации мы создали LIVR, который работает одинаково в JavaScript, PHP, Perl (и на многих других платформах).

Если хотите знать больше про монорепозитарии, вот ряд интересных ссылок:
1. Why Google Stores Billions of Lines of Code in a Single Repository
2. Monolithic Repositories with Ciera Jaspan
3. Monorepos in the Wild
4. Monorepos: Please don’t!

​Lessons Learned: Code Splitting with Webpack and React. Интересный пост о тех преимуществах, которые мы получаем, внедряя code-splitting на своих проектах -> http://bit.ly/2XHXLau
——————————————
Поддержать нас

​Где изучать frontend. Часто спрашивают, поэтому решил систематизировать, поэтому переходите и не забывайте подписываться 😄 → http://bit.ly/2IYDJjY
——————————————
Поддержать нас

​Level Up with WebAssembly. Книга о применении WASM в браузере → http://bit.ly/2YwBqKi
——————————————
Поддержать нас

​Говорим о CSS по-новому. Рейчел Эндрю с обзором современных техник создания раскладки и написания семантически-правильной верстки → http://bit.ly/2J6BAm4