В 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).

В компании $WORK мы столкнулись с необходимостью "плавного завершения работы" наших сервисов. Грациозное завершение работы позволяет убедиться в том, что система правильно финиширует перед завершением. В качестве аналогии можно привести ситуацию, когда человек пытается правильно завершить телефонный разговор перед тем, как перейти к следующей встрече, а не просто бросает трубку на середине фразы.

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

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

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

Это полное изложение замечательного доклада Роба Пайка "Concurrency is Not Parallelism". Иллюстрации и диаграммы воссозданы, исходный код взят дословно со слайдов, за исключением комментариев, которые в некоторых местах были расширены.

Это третья статья из серии, состоящей из трёх частей, в которой мы рассмотрим механику и семантику планировщика в Go. Эта статья посвящена конкурентности.

Сборник реальных советов по написанию сопровождаемых программ на языке Go. Автор - Dave Cheney, опытный разработчик на Go и один из его ведущих пропагандистов.

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

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

Сборник реальных советов по написанию сопровождаемых программ на языке Go. Автор - Dave Cheney, опытный разработчик на Go и один из его ведущих пропагандистов.

Сборник реальных советов по написанию сопровождаемых программ на языке Go. Автор - Dave Cheney, опытный разработчик на Go и один из его ведущих пропагандистов.

"Правильно заданный вопрос - половина ответа". Осваиваю профессию Prompt Engineering. Это ответы на вопросы. Мопед не мой. Спасибо, Codeium. Не обрабатывал наводящие подвопросы, а надо бы. Но может быть кому-то пригодится и в таком виде.

Здравствуйте! Меня зовут Андрей. Больше известен, как #кодеротбога (это самоирония, если что). Осваиваю Flutter в режиме «live-code», уже 567 трансляций. Без купюр – «from zero to hero», начиная с учебника по Dart и до полноценного «open-source» проекта в продакшене. А ещё, я скоро заканчиваю собственный онлайн-курс на 100 часов занятий – учитель учится у своих учеников. Благодаря интенсивной практике и предыдущему богатому опыту на ReactJS, сформировал набор соглашений, который хочу представить для получения фидбека: «Ваш звонок очень важен для нас, оставайтесь на линии».

Спрашивается, о чём мой проект? А я сам не знаю. Планы меняются. Идей много. Но всегда есть общий базовый функционал. Вот я пока про это. Уже 5 месяцев. После весеннего обострения, в приступе одиночества, хочу поделиться некоторыми наработками.

Четыре месяца назад взялся за единорожку. В который раз. И всё же плох тот солдат, который не стремится к генеральским штанам.

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

Конечно же буду выкладывать в Open Source, что приносит свои очевидные плоды. А ещё хочу стримы — зачем? Не ответил для себя полностью, но какие успехи по пунктам:

Мне не хватало возможности полноценно читать специальную литературу в PDF. Если говорить про ридеры, то это недостаточный размер страницы и черно-белый текст (примеры кода обязательно должны быть в цвете). На десктопе — тоже не вариант. Понятно, что материал гораздо более лучше усваивается лёжа на диване. Нужен планшет с максимально большим экраном.

На примере обычного блога (получение из API данных для post-comments), продемонстрирую, как покрываю тестами redux-слой. Исходники доступны тут.