WebbyLab developers baseline
Только что закончили беседу про команды на fwdays. Получилось у нас не сильно структурировано, но душевно 🙂. Просто в формате стрима. И в связи с этим хотел поделиться документом, который вспоминал во время обсуждения.

Этот документ описывает базовый набор общих знаний для разработчика (frontent, backend etc). Это маленькая толика того, что дается в университете и что может пригодиться на работе, поможет в проектировании, поможет в отладке приложений, поможет в собеседованиях.

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

Попробуйте сделать даже просто для себя все эти задачки.

ССЫЛКА НА ДОКУМЕНТ: https://bit.ly/3vO4EFa

Как вам документ? 🙂

Хитрости при кэшировании

Пару дней назад с коллегой на работе обсуждали инвалидацию кэшей и я вспомнил подход, который мы использовали на mail.ua еще в 2008 году. Когда при изменении одной сущности в базе, вы должны инвалидировать множество ключей. Для этого мы тегируем все связанные ключи, которые нужно будет инвалидировать определенным тегом с версией. И когда хотим все инвалидировать, просто увеличиваем глобальную версию тега (хранится отдельно). Затем при вычитке данных из кэша мы смотрим не устаревшая ли версия тега там.

Это интересный подход, который может быть полезен в различных ситуациях. К примеру, такой подход я использовал и при написании движка Excel на JS. Для каждой ячейки есть кэш, и когда пользователь нажимает recompute, то нужно сбросить все кэши в ячейках и затем постепенно наполнять по время расчета. В связи с этим в каждой ячейке хранится версия кэша, если она устарела (то есть меньше глобальной версии, которая инкрементируется при вызове recompute), то кэш считается невалидным.

Очень хорошо описано в этой статье 2008 года: https://habr.com/ru/post/43539/

Рекомендую все серию статей, там много интересных трюков. К примеру, мы тогда использовали такой же "Счетчик онлайнеров". (Термин "фронтенд" относится именно к серверам, а не к UI приложению. Не запутайтесь)

Пишите в комментариях, какие еще интересные подходы приходилось использовать при работе с кэшами 🙂

Серия выпусков про облака на Software Engineering Daily
Когда-то я уже писал про мой любимый инженерный подкаст - SE Daily

На этой неделе вышла целая серия с обсуждениями всех облачных провайдеров: AWS, Google Cloud, Digital Ocean, MS Azure, Oracle Cloud.

✅ AWS with Pete Cheslock
✅ Azure with Troy Hunt
✅ GCP with Liz Fong-Jones
✅ Digital Ocean with John Allspaw
✅ Oracle Cloud with Salman Paracha

Это из вас не сделает специалиста по облачной инфраструктуре, но явно добавит контекcта.
Рекомендую!

Случай с потерянными DNS пакетами

В поддержке Google Cloud есть такие ребята, как TSE (Technical Solutions Engineer) - это такие себе мастера дебага. Они годами работают над решением различных технических проблем заказчика и многие их истории просто великолепные. Одна из таких историй есть в публичном доступе.🙈

По сути, это крутая история про вопрос с собеседования "Что происходит, когда вы адресную строку браузера адрес и нажимаете enter" 🤓
Рекомендую к прочтению!

ССЫЛКА: https://cloud.google.com/blog/topics/inside-google-cloud/google-cloud-support-engineer-solves-a-tough-dns-case

Как вам история? 🙂

Доклад про Developers Baseline на Odessajs 2021

В эти выходные (28-29 августа) буду в Одессе на OdessaJS (https://odessajs.org) с докладом про Developers Baseline (https://t.me/jabascript/125).

Выступаю на OdessaJS уже 4й год. Всегда приятная атмосфера, доклады на берегу моря, крутое автепати 🔥🔥🔥

Если соскучились по оффлайн ивентам, то специально для подписчков канала попросил скидку. Вот промокоды:
✅ speakers_friends@odessajs - 15% скидки
✅ TurskyiFriend@OdessaJS50 - 50% скидки на 4 использования

Пишите в комментах, кто тоже будет на ОдессаЖС 🙂

До встречи в Одессе!

System Design Interview
Многие крупные компании требуют прохождения System Design Interview, еще его называют NALSD (Non-Abstract Large System Design) Interview .

Ваша задача - уметь понять требования к системе и спроектировать ее.

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

И уже делился серией постов со ссылками на интересные доклады:
✅ Real-Time Delivery Architecture at Twitter
✅ The Evolution of Reddit.com's Architecture
✅ Scaling Instagram Infrastructure
✅ Evolution of Financial Exchange Architectures

Но если вы только начинаете, то где изучить азы?

Основная проблема в том, что многие видео на Youtube по System Design сделаны людьми, которые сами просто готовятся к собеседованиям, но такие системы не строили. И часто в этих видео не хватает глубины.

🔥Но есть канал на Youtube, который я очень рекомендую. Канал уже давно не обновляется и на нем всего 6 видео. Автор начал записывать, а потом бросил по какой-то причине, но сразу чувствуется, что человек в теме :)

ССЫЛКА НА YOUTUBE КАНАЛ: https://www.youtube.com/c/SystemDesignInterview/videos
Смотрите все 6 видео от самых старых к самым свежим!

Как Uber реализовал в своем мобильном приложении фейловер переключение между серверами?

В WebbyLab мы всегда задаем на собеседованиях вопрос: "Что происходит, когда пользователь вводит в адресную строку браузера URL, с момента нажатия enter и до момента возврата страницы". Задаем мы его всем: фронтендерам, бекендерам, мобильщикам, тестировщикам, джунам, мидлам, сеньорам и милордам. Важно, что если, человек занимается разработкой интернет-приложений, чтобы он знал хоть немного про то, как работает Интернет. Да, все знать нельзя, но и для разных позиций ожидается разный уровень знаний. На практике я много раз наблюдал ситуацию, когда сотрудники, которые видят более полную картину, приходят к более эффективным решениям.

В контексте этого, решил поделиться хорошей статьей от Uber, как они реализовали failover handler на фронте (хоть и мобильном) -
https://eng.uber.com/eng-failover-handling/

Вышло 3х минутное интервью со мной с OdessaJS 2021 🙂
Получилось позитивно - https://youtu.be/wifIrqzRkug
Спасибо организаторам за крутой ивент!

Также должно быть видео доклада, но скину его скоро отдельным постом вместе с детальным анонсом платформы https://my-talks.net/

my-talks.net - открытая бета нашей платформы для спикерского портфолио.

Немного предыстории. Изначально, у меня был список докладов на гитхаб, но с ним не сильно удобно работать. В итоге, появилась идея сделать лучший сервис для спикерского портфолио. Это не каталог ивентов и не сервис резюме, а именно сервис докладов спикера. Часто людям интересен спикер и его доклады, а не просто ивент.

Так появился my-talks.net 😀

Что можно сделать при помощи сервиса?

Для спикера:
✅ Удобно хранить доклады со ссылками на видео в одном месте (легко добавлять доклады, когда с одной темой на нескольких конфах выступал).
✅ Использовать как ссылку в CV (или в профиль Linkedin)
✅ Скидывать организаторам конференции, когда нужно предоставить список докладов (вместо со ссылками на презентации и видео).
✅ Доклады в выдаче Googlе (уделяем много внимания SEO)

Для слушателей же это возможность:
✅ Найти все доклады спикера в одном месте
✅ Подписаться на спикера
✅ Попросить уведомить про появления видео к докладу (прошедшему или предстоящему).

Для организаторов конференций это возможность найти спикера.

Работа по сервису еще в процессе, но движется очень активно. Вот так выглядит список моих докладов на нем - https://my-talks.net/viktor-turskyi

Как помочь сервису:
✴️ Добавить свои доклады или подписаться на спикеров
✴️ Сообщить о багах
✴️ Нарисовать логотип. Нам очень нужен :)
✴️ Предложить идея для монетизации.
✴️ Фидбек по улучшению сервиса
✴️ Скидывайте ссылки, если знаете похожие сервисы (я не нашел ничего такого)

Как вам сервис? 🙂

VSCode в браузере 😎
Вы просто заходите на https://vscode.dev/ и сразу пользуетесь VSCode. Удобно, когда рабочее окружение не требует настройки и можно начать работать в привычных инструментах сразу. VSCode - это только часть экосистемы, нужно закрыть остальные аспекты всего процесса разработки. Github Codespaces как раз пробует решить эту проблему. Интересно будет понаблюдать за другими игроками рынка.

Но главное, чем я хочу поделиться, это докладом Эриха Гаммы (один из авторов gof-овских "Design Patterns") про то, как они в MS 10 лет разрабатывали VScode - история создания и интересные архитектурные решения.
Легкое получасовое видео для вечера пятницы 😉

ССЫЛКА НА ДОКЛАД: https://www.youtube.com/watch?v=hilznKQij7A

Доставили книгу. Детально описывает процессы и тулинг Гугла (написана гуглерами и некоторые используют для оебординга ее). Интересно будет сравнить с реальностью все 🙂
Книга есть в электронке даже
https://abseil.io/resources/swe_at_google.2.pdf

Напишу в канал небольшое ревью после прочтения.

Пишите в комментах, какие книги по разработке вам понравились. Что полезного можно прочитать разработчикам? 🙂

Должен ли фронтендер думать про XSS?

Коротко: Да! Должен!

Я уже не один раз слышал от фронтендеров, что за безопасность должен думать бэкенд разработчик и пускай там делают защиту от XSS. Да, на бэкенде можно снизить риски (к примеру, настроить CSP было бы правильно), но корневая причина находится именно на фронте. И это ответственность фронтендера думать про защиту от XSS.

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

Почему фронтендер?
⭕ Причина 1️⃣: XSS - это проблема процесса рендеринга данных.
Одни и те же данные можно использовать по разному в разных ситуациях и разных клиентах (браузер, консоль, мобильное приложение). И мы должны рендерить данные безопасно. Сегодня они могут прийти с надежного бэкенда, а завтра с какого-то внешнего, к примеру. Нет причины, чтобы использовать небезопасный рендеринг на клиенте (возможно за редким исключением).

Если этой причины мало, то переходим к следующей 🙂.

⭕ Причина 2️⃣: бэкендер не следит за изменениями фронтенда.
Бэкенд-разработчик на заморачивается у вас там просто textarea на фронте или WYSIWYG-редактор.

Давайте проведем мысленный эксперимент. У нас есть REST API endpoint, который возвращает информацию про пользователя и там два поля: "name" и "bio". Эти два поля отображаются обычным текстом в интерфейсе. И тут приходит продакт-менеджер и говорит, давай дадим пользователям возможность форматировать текст в bio. Ты подключаешь какой-то редактор и в этот момент твое приложение становится уязвимым к XSS, если ты про это не подумаешь.

Почему так произойдет?
❓ Есть ли гарантия того, что бэкендер знает, что нужно сделать изменения на бэке, если задача была чисто фронтовая?
❓ Есть ли гарантия того, что ваш продакт-менеджер поставит бэкендеру задачу про XSS вместе с фронтовой задачей для тебя?
❓ Если ты не знаешь про XSS, то как ты поставишь задачу бэкендеру?
❓ Если ты не знаешь про XSS, то как ты добавишь защиту на фронте?

В итоге бэкендер не в курсе, продакт не занимается этими вопросами, а фронтендер считаешь, что это не его ответственность. То есть, даже с процессной стороны возникает проблема.

Если этих двух причин мало, то переходим к следующей 🙂.

⭕ Причина 3️⃣: бэкенд должен знать про верстку фронта, чтобы сделать правильную защиту.

Стандартный механизм защиты это использования санитайзера (внешния библиотека типа DOMPurify) Никогда не используйте регулярки для защиты от XSS❗.

Но это настолько стандартная для фронтенда задача, что сейчас утверждается браузерный API (https://wicg.github.io/sanitizer-api/). Только это уже говорит о том, что этим должны пользоваться фронтендеры.

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

Цитирую: "If the user data is available in string form and the developer wishes to sanitize it now, but apply the result to the DOM later, then the Sanitizer must be informed about the context that it will be used."

Примеры:
sanitizer.sanitizeFor("div", htmlMarkup);
sanitizer.sanitizeFor("table", htmlMarkup);


То есть бэкенд не просто должен знать, что вы будете использовать строку как html, но и должен знать как у вас сверстана страница.

Общий вывод: фронт не должен ожидать безопасных данных с сервера и должен думать про безопасный рендеринг всегда!

Надеюсь, мне удалось убедить фронтендеров задуматься про XSS 🤓

Как я переключился с прекрасного Perl-а на ужасный JS

25 ноября в рамках "FWDays: JS is back" буду делать онлайн доклад на тему "Как я переключился с прекрасного Perl-а на ужасный JS"

Я использую JavaScript с 2006 года. Тогда я делал одностраничные приложения для IE6 на JS (это был ES3) и бэкэнд на Perl. JS был болью. Лучше ли он теперь? 😀

В докладе покажу принципиальное отличие современного JS от Perl. Как одни и те же проблемы можно решить разными способами. Надеюсь дать вам более широкое представление о том, что могут предоставить языки программирования.

Будьте готовы к интерактиву, чтобы помочь мне с простыми задачами на JavaScript 🤓

Также фоловить мои доклады можете и подписаться на уведомления про то, что появилось видео к этому докладу можете на my-talks.net (но видео будет только в следующем году, да и без интерактива)

Регистрируйтесь!

Как вам тема? 🙂

HTTP security headers

Безопасность вашего приложения можно повысить при помощи дополнительных HTTP заголовков.

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

Это настолько простая и полезная возможность, но не многие про нее знают, что мы решили добавить раздел по основным хедерам в "бейзлайн" (про "WebbyLab developers baseline" почитать можно тут - https://t.me/jabascript/125)

Смотрите раздел HTTP Security headers.
ССЫЛКА НА ДОКУМЕНТ: https://bit.ly/3vO4EFa

Что думаете по поводу HTTP security headers? Используете у себя на проектах? Слышали ли до этого?

Подписывайся и на мой твиттер👍🏻

Много всего, что не попало сюда в канал, в моем Твиттере.

Если интересно, подписывайся и на https://twitter.com/ViktorTurskyi

Каждый день по интересному факту про Google публикую https://twitter.com/viktorturskyi/status/1459966682454188036?s=21

Подписывайся!)
Обратная связь в виде ретвитов/лайков/комментарив приветствуются. Если конечно такой контент нравится)

Онлайн конференция "Fwdays: JS is back" начанается в среду, 2 бесплатных промокода для подписчков.

Про свой доклад, где расскажу как я переходил с Perl на JS, я уже делал пост. Хочу сделать доклад фаново, придумал много примеров, но это будет работать, только если будет интерактив - подключайся 25 ноября утром (четверг)

Трансляция в Zoom будет бесплатной, но предварительно регистрируйся

Также, я себе сделал личный топ из 5-ти докладов, которые обязательно хочу посмотреть:
✅ Wix Serverless from inside [ukr]. Я разработчик serverless платформы в Google Cloud и опыт Wix мне очень интересен.

✅ How to Use Bazel to Manage Monorepos: The Grammarly Front-End Team’s Experience [rus]. Bazel это опен-сорс версия гугловой системы сборки. Я все еще пытаюсь понять ее преимущества и недостатки. И опыт ребят и Grammarly очень интересен.

✅ Discussion on System Design [UA][RU]. Эту тему я просто люблю 🙂

✅ How does Node.js optimize JavaScript code? Eugene Obrezkov. Тут 2 причины. Первая - Женя крутой спец и может сделать хороший deep-dive. Вторая - я когда-то делал движок Excel на JavaScript и тогда мне пришлось разбираться во внутренностях v8, чтобы выжать максимальную производительность. Интересно, как дела сейчас с этим.

✅ Node.js Development in 2022: trends and techniques. Nikita Galkin. Никита всегда следит за трендами и этот доклад хорошая возможность быть в теме.

Бонус для подписчиков:
Мне очень нравится модель участия от Fwdays :
🔹 Free Online (регистрация бесплатно и только трансляции)
🔹 Full Online (запись всех эфиров)
🔹 Online Full Swag (для ценителей мерча)

И у меня есть 2 промокода на 100% скидки на "Full Online".
Розыграем их во вторник рано утром.

Для участия в розыгрыше нужно:
1. Оставить любой комментарий к этому посту.
2. Заволофить любого спикера на https://my-talks.net/

Начинаем https://us02web.zoom.us/j/85162497213

Какой гаджет/девайс нравится?

Думаю над подарком себе на Новый год. Ищу идеи и решил спросить у подписчиков 🙂

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

Обновление my-talks.net

Большое спасибо за фидбек по платформе. Мы сделали много улучшений. Решил описать, что поменялось:

Упростили добавляние доклада
✅ Теперь есть возможность сгенерировать картинку к докладу в один клик, если не хочется заливать собственную. Найти картинку - было основной сложностью, при добавлении доклада.
✅ Поменяли селекты, на автокомполит с поиском.
✅ Добавили полный список языков в выбор языка.

Другие улучшения
✅ У нас есть логотип 🙂
✅ Теперь спикеры с предстоящими докладами попадают в топ списка.
✅ Убрали разделения на типы пользователей (подписчики/спикеры). Теперь спикеры тоже могут подписываться на других спикеров, а подписчики могут в будущем создать доклад при желании.
✅ Теперь есть возможность добавить предстоящий интересующий доклад в Google календарь.
✅ Улучшили дизайн страницы со спикерами.
✅ Добавили имя спикера на страницу с докладом.
✅ Сделали подписи на кнопках более понятными.
✅ Переделали главную страницу.

Раздел Call for papers🔥🔥🔥
Это главное улучшение. Раздел Call for papers - это возможность подать доклад на конфу в несколько кликов. Просто выбираете конференцию, выбираете "Существующий доклад" или "Новый доклад", заполняете пару полей и вся информация уходит организаторам ивента. Раздел пока пуской, но скоро будет ряд ивентов в нем.

Как помочь сервису:
✴️ Добавить свои доклады или подписаться на спикеров
✴️ Сообщить о багах
✴️ Фидбек по улучшению сервиса
✴️ Скидывайте ссылки, если знаете похожие сервисы