Пузырьковая сортировка на 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
——————————————
Поддержать нас
——————————————
Поддержать нас
Forwarded from Жабаскрипт (веде Віктор Турський)
Как работает 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!
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
Spam Detection APIs. Обзор инструментов для борьбы со спамом, имеющих удобный api → http://bit.ly/2xrYDRI
——————————————
Поддержать нас
——————————————
Поддержать нас
Как настроить веб-аналитику на AMP страницах. Способы настройки аналитики (не только Google analytics) на AMP-страницах → http://bit.ly/2Ns1u85
——————————————
Поддержать нас
——————————————
Поддержать нас
CSS Custom Properties In The Cascade. Как CSS Custom Properties помогают бороться с перекрытием свойств в каскаде. Крутая статья с множеством примеров на smashingmahazine → http://bit.ly/2XLGUUj
——————————————
Поддержать нас
——————————————
Поддержать нас
Improving Redux state transfer performance with JSON.parse(). Прикольный способ, как ускорить TTI при SSR c помощью вынесения Redux store в отдельный скрипт → http://bit.ly/2FOutwz
——————————————
Поддержать нас
——————————————
Поддержать нас
The future of the web. Крутое видео о том, как мы пришли к нынешнему состоянию веба и чего ждать дальше → http://bit.ly/2JfgkLe
——————————————
Поддержать нас
——————————————
Поддержать нас
Как Fiber сделал React значительно быстрее. Очень интересное видео о внутренних механизмах работы Fiber. Очень советую чтоб понять внутреннюю магию React → http://bit.ly/2Jeo3sM
——————————————
Поддержать нас
——————————————
Поддержать нас
Advanced React Hooks Concepts — through Snake!. Глубокое погружение в Hooks на примере игры Змейка → http://bit.ly/2YFqfyZ
——————————————
Поддержать нас
——————————————
Поддержать нас
CORS – Cross-Origin Communication in the Modern Web. Разбор того, как устроен CORS со стороны сервера и клиента → http://bit.ly/2xBht9b
——————————————
Поддержать нас
——————————————
Поддержать нас
The Future of Websites: Headless CMSs. В свете популяризации JAM-стека, появляется такое понятие как Headless CMS. В статье подробнее рассказывается что это и какие виды данных CMS бывают → http://bit.ly/2S0bjsK
——————————————
Поддержать нас
——————————————
Поддержать нас
What Is the Native Payment Request API?. Новая фича, позволяющая проводить платежи нативными методами. Уже в стандарте, но поддержка браузеров пока не особо, но ознакомится интересно → http://bit.ly/2XzEJE3
——————————————
Поддержать нас
——————————————
Поддержать нас
Most Used JavaScript Frameworks for Quick Software Development: Which to Choose. Слабые и сильные стороны, все как обычно. Но если вы стоите на распутье - отсюда можно начать → http://bit.ly/2S6ezCL
——————————————
Поддержать нас
——————————————
Поддержать нас