Development

Какую организацию API выбрать для проекта: RestAPI или GraphQL? Rest API удобен для использования в сервисах и проектирования сервисов. Но не удобен для GUI т.к. REST предполагает разделение сущностей на отдельные ендпоинты, а в GUI мы хотим видеть все и сразу. GraphQL удобен для GUI за счет того, что можно просто описать, что нужно показать, а там оно уже само разберется. Но это неудобно для сервисов. Но почему нам стоит выбирать между REST и GraphQL? Почему не взять лучшее из обоих. Если REST подходит для проектирования сервисов и использования в сервисах то давайте его там и использовать. Если GraphQL удобен для GUI то давайте его использовать для конечных приложений (web, ios, android, etc). Мы можем последовать Separation of Concerns принципу и использовать те инструменты, которые лучше подходят контексту. Мы можем проектировать внутренние сервисы на REST, но делать отдельные bff для приложений, которые внутри уже используют то, что удобно им. Например, GraphQL.

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

Статья про Session-Based Test Management. Метод был описан еще в нулевых. Если коротко, то метод предлагает ставить процесс тестирования примерно так: - Лид группы определяет стратегию и план тестирования - Тестировщики тестируют - В конце тестирования создается отчет, в котором, в том числе, указываются сколько времени ушло на само тестирование, сколько на поиск багов и сколько на административную рутину - После этого мы можем анализировать, как бы улучшить процесс тестирования На мой взгляд достаточно бюрократизированная схема, но она хотя бы имеет цикл обратной связи. И кажется она подходит для бучения джунов-тестеров.

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

40 бесит практисов для интеграционного тестирования сервисов на nodejs. Многие советы никак не привязаны к технологическому стеку

Практически для любого контента нам нужно уметь показывать 4 состояния: - ожидание - загрузка данных - ошибка загрузки - успешная загрузка В статье рассматриваются два способа реализации этих состояний в react компоненте. По сути это: - условия в разметке - отдельные компоненты Оба способа имеют свои плюсы и минусы и подходят в разных контекстах

Статья про антипаттерн, когда чаилд-компонент работает с передаваемым ему апи, зная его реализацию В частности, когда в чаилд компонент передаётся setState от родителя Из минусов статьи - аргументация. Это плохо потому что это плохо и вообще не надо так.

GitHub запустился в 2008 году и очень быстро стал популярным. В том числе популяризировалась и модель Pull Request + Code Review. В 2010 году была опубликована книга Continuous Delivery, в рамках которой предлагается коммитить сразу в мастер и не рекомендуется делать долго-живущие фиче-ветки. Эта два совершенно разных подхода, которые подходят разным контекстам. Подход GitHub'а подходит open-source проектам, потому что: - В проекты в GitHub'е нельзя просто так комитить в мастер - Нет четкого заказчика Подход Continious Delivery больше подходит agile проектам, где все разработчики могут комитить сразу в мастер и есть четкий заказчик. Эти два подхода конфликтуют. Почему же в коммерческой разработке все используют подход, который больше подходит для open source проектов? А именно, почему практически все разрабатывают с помощью Pull Request и Code Review? Автор статьи связывает это с тем, что процесс разработки как в Open Source более прозрачен. Разработчики во время Code Review видят практики, которые применяют другие разработчики. В то время как при применении Continous Delivery сложно увидеть практики, применяемые другими разработчиками. От себя добавлю, что инструментов, позволяющих проводить Code Review на Pull Request'ах - достаточно много. В то же время инструментов, позволяющих делать удобный Continious Code Review на мастере - нет совсем

Github вырос в 2 раза за полтора года. GitHub стал достаточно большим, чтобы ощущать неудобство от монолита: - можно случайно все сломать - большой кусок кода - все разработчики завязаны на 1 стек Поэтому было принято решение понемногу вводить микросервисы. В статье описаны проблемы, с которыми столкнулись в GitHub. И их решения. В статье вы не увидите ничего нового, если вы уже мастер микросервисов. П

Есть несколько популярных фреймворков для приоритезации задач. - ICE/RICE scoring (reach, impact, confidence, effort) - Value vs complexity 2X2 matrix - Stakeholder scoring Все они примерно одинаковы, нужно дать оценку идеям по трем пунктам: - Сколько это принесет денег - Как сложно это сделать Вопросов может быть больше или они могут быть поставлены по другому, но в целом они сводятся к этим двум оценкам. Эти фреймворки не работают, потому что их результаты очень неточны. Они хорошо выделяют задачи которые легко сделать и приносят много ценности и которые сложно сделать и не приносят ценности. Но такие задачи легко видны и без применения фреймворков приоритезации. Решение проблемы приоритезации в другом: продуктовая команда должна сфокусироваться на меньшем количестве задач, но на таких, в которые верит вся продуктовая команда. Не смотря на то, что эти фреймворки не помогают с приоритезацией, они могут помочь в другом. Эти фреймворки хорошо визуализируют, почему некоторые запросы стейкхолдеров не следует брать в работу. В этом случае эти фреймворки выполняются роль платформы для обсуждения. Есть и другие методы приоритезации: - Kano model - Opportunity scoring - Buy-a-feature method Они работают лучше, но по-другому и имеют свои проблемы

Эвристики эффективной разработки. Очередной манифест с лозунгами. Но в целом все верно.

У вас есть 2 обьекта одного типа Type. type Type = { a: string, b: number } Функция принимает параметр key типа keyof Type и перебрасывает из одного обьекта значение key в другой обьект. function fn(key: keyof Type) { obj1[key] = obj2[key] } В этом случае Typescript будет думать, будто-бы мы ЛЮБОЙ ключ obj2 кидаем в ЛЮБОЙ ДРУГОЙ ключ obj1. Т.е. rак будто пытаемся записать string | number либо в поле с типом string, либо в поле с типом number. Typescript кинет ошибку т.к. ему нужно доказать что мы правильно перезаписываем поля. Такое поведение неочевидно, потому что для разработчика ожидаемое поведение другое. Из кода понятно, что мы не можем тут записать неправильный тип данных. Решение для этой проблемы, а также пара других похожих проблем можно прочитать в статье.

Сначала на свет появился Selenium, позволивший автоматизировать тестирование в браузерах с использованием протокола WebDriver. Этот протокол стандартизирован W3C и именно благодаря ему с помощью Selenium возможно тестировать почти все браузеры. Затем на свет вышел Chrome Devtools Protocol (CDP) и puppeteer. Он, обьективно говоря, удобнее всем. Кроме одного факта - работает только с chromium based браузерами. Текущие самые популярные платформы для написания браузерных тестов - cypress и puppeteer, работают на CDP. Чуть позже Microsoft анонсировала playwright. Инструмент имеет апи как у puppeteer, но умеет автоматизировать safari и firefox (если не ошибаюсь). А теперь комитет W3C стандартизирует WebDriver-BiDi - который должен взять плюсы CDP, но убрать из них специфику хрома и стать единым новым протоколом для общения с браузерами.

Имплементация обьекта Result из Rust на typescript. Result очень похож на монаду Maybe (если я правильно помню эту монаду) - может содержать или результат или ошибку, но перед тем как работать с результатом нужно проверить, содержится ли в Result ошибка или результат. Выглядит интересно.

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

Паттеры для замены легаси на что-то новое. Сам процесс замены можно разбить на следующие состоявляющие: - Понять, чего хотим достичь - Разбить проблему на мелкие части - Успешно заделиверить эти части - Изменить организацию так, чтобы новое решение не превратилось в новое легаси В статье рассказывается об анти-паттернах переписывания легаси: - переписывание всего разом - переписывание потому что "новая технология" - переписывание без понимания, чего хотим достичь - переделывавние технической части или бизнесовой изолированно друг от друга В целом для хорошей замены легаси компонента на новвый, нужно - уметь в архитектуру - быть agile - понимать зачем это бизнесу - менять не только саму систему, но и все процессы и организацию вокруг системы Обязательно к прочтению всем, кто хочет менять легаси

Статья про то, как чаты, из идеи асинхронного общения превратились плохое синхронное общение. Также указаны принципы хорошего асинхронного общения. Но ни слова о том, как перестать делать плохо и начать делать хорошо

Еще одна статья про проектирование маленьгого react приложения вместе с xstate

Пошаговый пример проектирования небольшой страницы с помощью XState

Тул для удобной автоматической публикации npm пакетов от Microsoft. - Синхронизирует гит и нпм - Генерирует ченджлоги - Сам поднимает версии по семверу - Работает как с моно-репо и так и single-репо - 0-config

Эффект свидетеля - психологический эффект, проявляющийся в том, что люди, оказавшиеся свидетелями чрезвычайной ситуации, не пытаются помочь пострадавшим. Он также может работать в бытовых ситуация и на работе. Вы, наверное, часто сталкивались с проявлением этого эффекта, когда кто-то говорит "нужен доброволец который сделает Х", но никто не отзывается. Каждый думает, что он недостаточно подходит для этой роли. Статья предлагает бороться с эффектом свидетеля следующим образом: - Предлагайте сделать целевое действие конкретным людям. При этом ответ "нет" не должен игнорироваться - При поиске добровольца ограничивайте время поиска. Например, "ищу добровольца для Х следующие 3 дня, потом выберу кого нибудь" - Предлагайте другого человека, если это пойдет на пользу процессу - Даже "эй, Боб, помоги мне найти того кто сделает Х" лучше чем "Ищу добровольца чтобы сделать Х"

Статья про эргономику на рабочем месте. Рассматриваются стулья, столы и работа стоя.

Социальная ленность - эффект в психологии, заключающийся в том, что чем больше группа людей, тем меньше производительность каждого участника группы. Эффект подтверждается большим количеством независимых исследований. Это обьясняет почему из каждого утюга слышано про то, что команды должны быть маленькими. В маленьких командах, около 5 человек согласно исследованиям, социальная ленность не проявляется. Интересные факты из исследований: - Женщины и люди из восточных культур меньше подвержены социальной ленности. - При рассмотрении распределенных и собранных в одном месте команд, выяснилось, что распределенные команды меньше подвержены социальной ленности (нет смысла делать видимость работы) - Люди, занимающиеся командными видами спорта, менее подвержены социальной ленности. мое ИМХО, люди играющие в командные компьютерные игры также должны быть менее подвержены этому эффекту. Одна из причин возникновения эффекта: чем больше группа, тем менее виден эффект от усилий конкретного человека. Способы борьбы: - Человек должен чувствовать, что его работа важна для команды - Работа в группе, которая приносит удовольствие. хороший пример - парное программирование, если оно всем нравится. - Работа с интересными задачами - Четкие, ясные цели - Оценка индивидуальной работы сотрудника, вместо оценки работы всей команды Эффект также перекликается с другими психологическими теориями, например с Social identity theory В общем: - научно доказано, что размер команды имеет значение - очень важно чтобы человек получал удовольствие от работы и чувствовал свой импакт на происходящее. Ну и судя по исследованиям - идеальные тиммейты это женщины из восточной азии, играющие в командные виды спорта

Организация своих заметок - непростая задача. Есть много инструментов и подходов к накоплению знаний через заметки. Большинство популярных на сегодняшний день инструментов проповедуют подход, в котором необходимо фиксировать текущее состояние знания. Например, вы узнали что-то год назад, теперь узнали об этом же факте что-то новое - вы должны обновить заметку в своей базе знаний. Этот подход не похож на то, как работает память. В вашей памяти останется 2 знания: как вы знали раньше и что вы узнали нового. Подход Incremental note-taking, описанный в статье, пытается это повторить. Вместо того, чтобы обновить старую заметку, следует сделать новую и соединить с предыдущей. Также важен контекст, в котором заметка появилась - например время, когда она появилась, и место, где она появилась. В статье рассматриваются еще разные аспекты работы памяти и организации заметок, а также как реализовать Incremental note-taking подход используя существующие инструменты для ведения базы знаний.

Расширение для vscode для автоматического рефакторинга JS и TS кода. Некоторые рефакторинги выглядят весьма впечатляюще

Статья от Dr. Axel Rauschmayer про монорепы с использованием npm, который умеет в workspaces, и примером правильной настройки tsconfig в рамках монорепы

Вот кажется совсем недавно выходил yarn2. Но теперь готовится к выходу yarn3. По ссылке краткое описание изменений

Статья от Пятерочки про микрофронтенды на практике. Ребята делают новый Личный Кабинет сотрудника и делают его с микрофронтендами. В рамках статьи кратко рассказаны архитектура и тех стек (redux + mobx) и варианты реализации микрофронтендов, которые они рассмотрели тлдр: - рассмотрели iframe, но есть свои очевидные недостатки. - рассмотрели публикацию npm пакетов и интеграцию пакетов в приложение. В целом удобно разрабатывать, но очень неудобно интегрировать и релизить В итоге сделали с помощью webpack module federation - каждый модуль разрабатывается и деплоится отдельно, а затем в приложении все собирается с помощью webpack module federation. ИМХО, достаточно таки храброе решение для продакшна в текущей ситуации. Ну и неожиданно пятерочка удивила хорошим постом на хабре с собственным контентом. Редкость в наше время.

Немецкая газета Netzwelt ускорила сайт и увеличила доход от рекламы на 18%. В статье кратко рассказаны оптимизации, примененные сайтом. Из интересного - доходы увеличились не только от ускорения перформанса, но и от изменения показа самой рекламы. Т.е. эксперимент был нечистый. Самое значимое изменение - сделали fixed баннер, теперь пользователи всегда видят баннер на странице. В целом хорошая статья для тех, у кого похожая область - показ текстового контента, который напрямую не монетизируется (СМИ, блоги (площадки для блогов, коммунити площадки)

В фронтенд-проекте мы вынуждены использовать разные инструменты для разных видов тестирования: - jest для обычных тестов - storybook для скриншот-тестов - cypress (или чтото похожее) для тестов в браузере В статье рассматривается проблема обьединения всех test coverage в один единый test-coverage. tldr: команда istanbul-merge умеет склеивать несколько репортов в один