Привет, Хабр! Я Никита Иванов, техлид команды «Видео» в KION. В ИТ я уже девять лет, а последние пять работаю с Go. Сегодня расскажу, какую задачу считаю идеальной для собеседования на позицию Go-разработчика. Этот текст — переработка моего доклада с митапа МТС True Tech Go, видеоверсию можно посмотреть тут.

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

Однажды мне стало интересно: а что будет, если отправить пакет с несуществующим транспортным протоколом? Не TCP, не UDP, не ICMP — вообще что-то выдуманное. Пропустит ли его ОС? Дойдет ли он хотя бы до сетевого интерфейса? Не зарежет ли его какой-нибудь промежуточный маршрутизатор? А вдруг он еще и быстрее обычного дойдет, потому что никто не знает, что с ним делать?

Ответа у меня не было. Так что я решил проверить.

Давайте будем честными.

Простые промпты наподобие "Напиши статью из 1500 слов под заголовком: Топ-10 продуктов, которые разрушают вашу печень» не дадут вам и 1% тех результатов, которые способен дать Chat GPT.

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

Если Вы - мидл, и Вас стали мучать такие вопросы — поздравляю, Вы на верном пути. Ведь профессиональный рост не происходит с переводом на должность - новый сениор должен родиться, и это как раз муки такого рождения.

Да, мы уже знаем самые популярные практики: KISS, DRY, YAGNI, SOLID, что там ещё... Мы умеем их применять. Но нас не покидает чувство, что все эти практики объединяет общая научная основа. Знаете, это как с Менделеевым, который на основе закономерностей практически по наитию составил периодическую систему, а потом открыли электроны и всё встало на свои места.

У меня для вас хорошие новости: научная основа есть. Это предметно-ориентированное проектирование.

Но есть и плохая новость: тема настолько новая и непростая в изучении, что какая-никакая популярность к ней пришла лет 5 назад, и до сих пор совсем небольшое число разработчиков достаточно хорошо в ней разбирается.

Но есть ещё одна хорошая новость: в статье ниже я постараюсь дать максимально понятный ответ, что же такое предметно-ориентированное проектирование.

Начнём.

Привет, Хабр!

В предыдущей статье мы разобрали, как не ломать себе карьеру, бездумно используя unwrap() или игнорируя ошибки через let _ =. Но давайте честно: это были цветочки. Настоящие проблемы начинаются там, где ваш код работает «почти идеально», а потом, под грохот продакшена, вы осознаете, что все было далеко не так гладко.

Сегодня вторая часть. Разберем несколько ошибок, которые выглядят безобидно, но тащат за собой баги, утечки памяти и необъяснимые фризы.

Начнем с первой проблемы при работе с .iter() и .iter_mut.

Введение

Терминология

• «Забытый слой пирамиды автоматических тестов» (Майк Кон, 2009)
• «Пирамида тестов» (Мартин Фаулер, 2012)
• «Блог отдела тестирования Google» (Google, 2015)
• «Пирамида тестов на практике» (Хэм Фокке, 2018)

Всем привет! Меня зовут Андрей, я DevOps инженер.

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

На тот момент, мне бы хотелось найти одну большую статью, пусть и не полностью, но достаточно подробно описывающую процессы управления кластером K8s, деплоя и обслуживания приложений в нём.

Примерно такую статью я постарался написать.

Всем привет! Предметно-ориентированное проектирование, на мой взгляд, является недопонятым подходом, о котором многие говорят, но немногие его действительно применяют.

Одним из относительно простых в реализации и полезных в архитектурном смысле паттернов, на мой взгляд, являются события предметной области (Domain Events). В данной статье я бы хотел рассказать о возможных вариантах реализации этого шаблона DDD с использованием .NET.

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

MetalLB — это решение для балансировки нагрузки в средах Kubernetes, которые не имеют доступа к встроенным балансировщикам, как в облачных провайдерах. Этот инструмент предлагает простой и эффективный способ добиться внешней доступности для сервисов в Kubernetes с помощью собственной инфраструктуры.

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

Привет, Хабр! Представляю вашему вниманию перевод статьи "Learning Parser Combinators With Rust".

Эта статья учит основам комбинаторных парсеров людей, которые уже знакомы с Rust. Предполагается, что никаких других знаний не требуется, а всё, что не имеет прямого отношения к Rust, а также некоторые неожиданные аспекты его использования, будут объяснены. Эта статья не поможет вам выучить Rust, если вы его ещё не знаете, и в этом случае, вы, вероятнее всего, не поймёте комбинаторные парсеры хорошо. Если вы хотите изучить Rust, я рекомендую книгу "Язык программирования Rust".

Вероятно, вы уже слышали о соревновании под названием "The One Billion Row Challenge" (1brc), если же нет, то предлагаю ознакомиться с репозиторием 1brc Гуннара Морлинга.

Моё участие в проекте было мотивировано присутствием в нём двух моих коллег, которые достигли лидирующих позиций.

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

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

В статье разберем особенности аутентификации применительно к протоколу WebSocket и технологии Server-Sent Events, обсудим, какие нюансы могут быть, когда клиентская часть находится в браузере, и на что еще стоит обратить внимание, чтобы избежать неочевидных проблем.

А еще заодно поговорим про уязвимость Cross-Site WebSocket Hijacking (CSWSH) и в целом посмотрим на многие вопросы через призму информационной безопасности.

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

В этой статье мы научимся писать полноценный gRPC сервис на Go на примере сервера авторизации с полноценной архитектурой, готовой к продакшену. Мы напишем как серверную часть, так и клиентскую. В качестве клиента мы возьмём мой сервис — URL Shortener, о котором у меня также есть статья и видео-гайд на ютубе. Попутно мы познакомимся с базовыми подходами к работе с авторизацией. И в конце настроим автоматический деплой сервиса с помощью GitHub Actions на удалённый сервер.

Видео-версия этого гайда с более подробными объяснениями

Исходный код проекта: https://github.com/GolangLessons/sso

Итого, наш план:

• Напишем простой, но полноценный gRPC-сервис
• Разберемся с базовыми принципами работы авторизации — чтобы не было скучно
• Настроим автоматический деплой в прод — потому что руками деплоить лень
• Подружим его с уже готовым сервисом URL Shortener — чтобы был практический смысл
• Напишем полноценные функциональные тесты

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

Кратко обо мне: меня зовут Николай Тузов, я много лет занимаюсь разработкой на Go, очень люблю этот язык. Также веду свой YouTube-канал.

Всем привет. Меня зовут Динис, я старший разработчик в БФТ-Холдинге.

В данной статье приведен план по созданию сервиса авторизации через систему ЕСИА. Тема будет интересна тем, кто внедряет такой сервис для своего приложения. В статье я собрал ключевые выдержки из документации с частями кода, а весь код вы можете найти в конце статьи по ссылке на GitHub.

Что такое ЕСИА?

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

Здравствуйте, меня зовут Тимофей, и я алкоголик программирую, чтобы писать музыку. Судя по всему, недуг мой прогрессирует:

- Пять лет назад, когда я впервые услышал про LilyPond — язык программирования, на котором можно писать партитуры в текстовом редакторе — я посмеялся над гиком, что это придумал, и прошёл дальше.
- Два года назад я прочитал код партитуры из примеров — удивился, насколько логично и музыкально он выглядит, подивился задротству автора, и пошёл набирать ноты в MuseScore.
- В этом году я пишу экспортёр MIDI из Reaper в исходники LilyPond, а сегодня зарелизил rea-rs: фреймворк для написания расширений для Reaper на rust.

И, несмотря на то, что в этом альфа-релизе >16 300 строк, я всё ещё считаю, что занимаюсь «бытовым программированием». Имею в виду что-то вроде готовки: можно, конечно, сходить в ресторан, когда хочется чего-то эдакого, но в ресторан каждый день не набегаешься. А то, что погреб на даче потихоньку превращается в винодельню — так это побочный эффект. Зато всё своё, домашнее, натуральное.

В последнее время, подобные мысли я проговаривал не как здоровый сарказм, а как симптомы болезни: мол, «это не хумус, видео не передаёт запах»! Но, намедни, моя музыкальная школа подогнала мне мак с Finale и полным комплектом Adobe на борту, чтобы совместно работать над сборником рождественских песен. И… Holly crap, I was damn right! Но расскажу по порядку, как я дошёл до жизни такой.

Весь минувший месяц я глаз не мог оторвать от языка программирования Rust, ведь его конёк – создание современных программ, обеспечивающих безопасную работу с памятью. За прошедшие годы появилось несколько языков, которые позиционировались как «инструмент что надо» для написания надёжного бекенд-софта. Постепенно маятник качнулся от Java/C++ к Go и Rust, выстроенных на многолетних разработках по теории языков программирования. Суть – в создании инструментов, которые были бы эффективны именно в наш век.

Мне поставили задачу: сформировать документ через Adobe API. Требований было минимум - главное сформировать документ из шаблона. Шаблон я мог отформатировать в нужный мне формат без проблем. Но сам формат, как его использовать и как это связать с API я не знал. Поэтому нырнул в документацию.

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

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

Вот и меня посетило желание что-нибудь написать для читателей Хабра. Чем же ещё заняться в отпуске?

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