За время моей недолгой работы инженером-программистом (2,5 года) мне всегда невероятно везло с людьми, которые меня окружали. Я сталкивался с гениальными инженерами, которые, проявляя терпение и оказывая поддержку, делали все возможное, чтобы помочь мне учиться, совершенствоваться и самому становиться лучшим инженером.

В первый день работы в моей первой компании я не понимал, что такое POST-запрос. В начале прошлого года я не знал, что такое GraphQL. До вчерашнего дня я никогда не использовал defer в GoLang.

Теперь, если я оглянусь назад, я легко могу увидеть, насколько далеко я продвинулся. Но когда вы окружены командой чрезвычайно умных и знающих людей, еще проще увидеть, как далеко вам еще предстоит идти. И так же легко это расстояние может превратиться в тревогу и депрессию.

«Сделай работающим, сделай правильным, сделай быстрым». Это мантра, которую вы, вероятно, слышали раньше. Это хорошая мантра, которая помогает вам сосредоточиться на том, чтобы не переусложнять решение. Я пришел к выводу, что обычно достаточно сделать это правильно, обычно это достаточно быстро, если сделать это правильно.

Когда мы начали реализацию подписок GraphQL в Cosmo Router, мы сосредоточились на том, чтобы сделать это работающим. Это было несколько месяцев назад. Это было достаточно хорошо для первой итерации и позволило нам получить отзывы от наших пользователей и лучше понять проблемное пространство.

В процессе того, как мы делали это правильно, мы сократили количество горутин на 99% и потребление памяти на 90% без жертвования производительностью. В этой статье я объясню, как мы достигли этого. Использование Epoll/Kqueue сыграло большую роль в этом, но также переосмысление архитектуры, чтобы она была более событийно‑ориентированной.

В 99designs мы находимся на пути деконструкции нашего PHP-монолита в микросервисную архитектуру, при этом большинство новых сервисов пишется на Go. В этот период наша фронтенд-команда также применила безопасность типов, перейдя с Javascript на TypeScript и React.

После того как мы внедрили безопасность типов в бэкенд и фронтенд, стало очевидно, что наши конечные точки REST, созданные на заказ, не могут преодолеть разрыв между типами. Нам нужен был способ объединить эти системы типов и распутать наши конечные точки API.

Нам нужна была система безопасности типов для API. GraphQL выглядел многообещающе. Однако, изучив его, мы поняли, что не существует серверного подхода, который бы отвечал всем нашим требованиям. Поэтому мы разработали свой собственный, который мы назвали gqlgen.

Спрос на функции поиска растет, и многие разработчики пытаются внедрить их в свои приложения. Однако создание таких приложений с нуля - сложная и трудоемкая задача. К счастью, существует множество библиотек с открытым исходным кодом, позволяющих освободить разработчиков от этого бремени.

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

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

Самый яркий пример - автор научной фантастики Тед Чианг, который недавно задался вопросом, есть ли "способ для И.И. сделать что-то еще, кроме как точить лезвие ножа капитализма?". По данным Insider, сотрудники JPMorgan, возможно, уже страдают от такой динамики благодаря мощным инструментам мониторинга сотрудников компании.

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

Предлагается пошаговое руководство по дообучению Whisper для любого многоязычного набора данных ASR с использованием Hugging Face ? Transformers. Эта заметка содержит подробные объяснения модели Whisper, набора данных Common Voice и теории дообучения, а также код для выполнения шагов по подготовке данных и дообучению. Для более упрощенной версии с меньшим количеством объяснений, но со всем кодом, см. соответствующий Google Colab.

Когда я ищу информацию о принципе KISS в Интернете, я натыкаюсь на множество сайтов, определяющих его в паре строк: важна простота, давайте быть простыми, конец. Они часто не объясняют, что такое простота, почему простота важна и как ее достичь.

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

Вы угадали: мы погрузимся в простоту (и сложность) в этой статье. Я не буду писать обо всех различных способах, которыми сложность может проникнуть в ваш код, но, вместо этого, я постараюсь дать вам краткий обзор различных масок, которые сложность может носить, с множеством примеров. Мы перейдем от самого бизнес-домена, через мелочи (реализацию), чтобы закончить сложностью архитектуры программного обеспечения.

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

В продолжение к заметке Инструкция: как быстро настроить GitLab CI/CD на Flutter-проекте.

Больше спасибо автору, всё получилось относительно легко. Я усложнил задачу: поднял GitLab локально на Хакинтоше, прикрутил executor = "docker" вместо "shell". И началось веселье.

Эта заметка о том, зачем нам нужен пакет coroutine для Go и как он будет выглядеть. Но прежде всего, что такое корутины?

Сегодня каждый программист знаком с вызовами функций (подпрограмм): F вызывает G, которая останавливает F и запускает G. G выполняет свою работу, потенциально вызывая и ожидая другие функции, и в конце концов возвращается. Когда G возвращается, G уже нет, а F продолжает работать. В этой схеме одновременно выполняется только одна функция, а ее вызывающие ожидают, поднимаясь вверх по стеку вызовов.

В отличие от подпрограмм, корутины выполняются конкурентно на разных стеках, но все равно верно, что одновременно выполняется только одна функция, а ее вызывающая сторона ждет. F запускает G, но G не выполняется немедленно. Вместо этого F должен явно возобновить (resume) выполнение G, который затем начинает выполняться. В любой момент G может развернуться и вернуться (yield) назад к F. Это приостановит G и продолжит F операцию возобновления. В конце концов F снова вызывает resume, который приостанавливает F и продолжает G после выхода. И так далее, туда-сюда, пока G не вернется, что приведет к очистке G и продолжению F с последней операции возобновления, с некоторым сигналом для F, что G закончена и F больше не должна пытаться возобновить G. В этом паттерне одновременно выполняется только одна корутина, а ее вызывающая сторона ждет на другом стеке. Они выполняются по очереди в четко определенном, скоординированном порядке.

Это несколько абстрактно. Давайте посмотрим на реальные программы.

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

Однако культура - вещь непростая. Ее нельзя измерить, и хотя она не может быть навязана сверху, здоровая культура требует правильной среды для роста и масштабирования. В этом первом разделе книги The Ultimate Guide to Building Technical Teams мы рассмотрим, что могут сделать организации, чтобы заложить фундамент командной культуры, ориентированной на разработчиков, частью которой они с удовольствием станут.

Этот манифест опубликован пару лет назад, но интересно посмотреть с оглядкой назад.

Прежде чем говорить о функции init в Golang, необходимо понять, что такое пакет в Golang. Программа go организована в пакеты. Пакет собирает несколько исходных файлов в одном каталоге. Он похож на ящик, в котором находятся некоторые инструменты или небольшая машина. Он является отправной точкой для инициализации всего пакета. По-видимому, это соответствует назначению функции init.

Изящное завершение работы (Graceful Shutdown) важно для любого длительного процесса, особенно для того, который обрабатывает состояние. Например, что если вы хотите завершить работу базы данных, поддерживающей ваше приложение, а процесс db не сбрасывает текущее состояние на диск, или что если вы хотите завершить работу веб-сервера с тысячами соединений, но не дожидаетесь окончания запросов. Изящное завершение работы не только положительно сказывается на пользовательском опыте, но и облегчает внутренние операции, что приводит к более счастливым инженерам и менее напряженным SRE.

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

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

Когда вы проводите сессию по событийному моделированию, хорошо, чтобы люди быстро освоились. Используйте эту таблицу для собственного понимания или возьмите ее с собой на семинар, чтобы облегчить начало работы для тех, кто только начинает знакомиться с событийным моделированием.

В Go 1.22 ожидается появление интересного предложения - расширение возможностей по поиску шаблонов (pattern-matching) в мультиплексоре, используемом по умолчанию для обслуживания HTTP в пакете net/http.

Существующий мультиплексор (http.ServeMux) обеспечивает рудиментарное сопоставление путей, но не более того. Это привело к появлению целой индустрии сторонних библиотек для реализации более мощных возможностей. Я рассматривал эти возможности в серии статей "REST-серверы на Go", в частях 1 и 2.

Новый мультиплексор в версии 1.22 позволит значительно сократить отставание от пакетов сторонних разработчиков, обеспечив расширенное согласование. В этой небольшой заметке я кратко расскажу о новом мультиплексоре (mux). Я также вернусь к примеру из серии "REST-серверы на Go" и сравню, как новый stdlib mux справляется с gorilla/mux.

Время от времени необходимо пересматривать свои методы TDD и напоминать себе, каких моделей поведения следует избегать.

Процесс TDD концептуально прост, но по мере его выполнения вы обнаружите, что он бросает вызов вашим навыкам проектирования. Не путайте это с тем, что TDD - это сложно, сложно именно проектирование!

В этой статье приводится ряд антипаттернов TDD и тестирования, а также способы их устранения.

Преимущество программного обеспечения заключается в том, что оно может изменяться. Именно поэтому его называют "soft" обеспечение - оно более податливо, чем аппаратное обеспечение. Отличная команда инженеров должна быть замечательным активом компании, создавая системы, которые могут развиваться вместе с бизнесом, чтобы продолжать приносить пользу.

Так почему же мы так плохо справляемся с этой задачей? Сколько проектов, о которых вы слышали, полностью проваливаются? Или становятся "наследием", и их приходится полностью переписывать (и переписывать тоже часто неудачно!).

Как вообще происходит "отказ" программной системы? Разве ее нельзя просто менять до тех пор, пока она не станет правильной? Именно это нам и обещают!

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

Эта глава является продолжением главы "Введение в приёмочные тесты". Готовый код этой главы можно найти на GitHub.

Приёмочные тесты очень важны, они напрямую влияют на вашу способность уверенно развивать систему с течением времени при разумной стоимости изменений.

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

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

«Покажите мне ваши блок‑схемы и спрячьте ваши таблицы, и я буду продолжать оставаться в замешательстве. Покажите мне ваши таблицы, и мне не понадобятся ваши блок‑схемы — они будут очевидны» — Фред Брукс, автор книги «Мифический человек‑месяц».

В этой главе мы погрузимся в мир тестовых двойников и рассмотрим, как они влияют на процесс тестирования и разработки. Мы раскроем ограничения традиционных mocks (имитаторы), stubs (заглушки) и spies (шпионы) и представим более эффективный и адаптируемый подход с использованием подделок (fakes) и контрактов (contracts).