Контур проводит исследование о том, как живёт .NET-сообщество в России. Анкета активна до 15 июля.
Вопросов чуть больше 20, но большинство из них закрытые, так что много времени не займет. Мы не спрашиваем ваши персональные данные и зарплатные вилки. Мы хотим узнать, как C# разработчики обмениваются знаниями и какие выбирают инструменты для развития.
Об итогах напишем на Хабре.
Привет Хабр! Это мой первый пост, и я просто хотелось спросить, стоит ли уходить в Go? У меня есть небольшая база в программировании, делал сайты на реакт и ларавел, реализовывал бэкенд с Солид и паттернами, писал на нативном пхп файловые обменники и апи. Не много знаю базы данных соответственно, гит, докер. Сейчас засматриваюсь на Go, где то вычитал что мол крутая штука для бигтехов в России, а сам я студент и пока сижу на шее у родителей, но в следующем году я окончу к курс, и хочу где то месяца за 4-5 изучить все нужное в го и во всех других сопутствующих технологиях для разработки высоконагруженных приложений и микросервисов и всякого подобного. Стоит ли сворачивать на этот путь, или добить стек ларавел плюс вью? Немного боюсь, так как слышал что в го нужны уже 25 летние синьоры со стажем работы минимум в 20 лет, но и не хочется проторчать всю жизнь в челябинской галере на фуллстеке за 70 деревянных на руки.
Control Plane и User Plane в мобильной связи: зачем нужны два типа трафика и как они работают
Опорная сеть — это мозг мобильной связи. Именно она делает возможными звонки, мобильный интернет и все функции, к которым мы привыкли. Когда базовая станция ловит сигнал, переводит его в цифровой вид и передает дальше — в дело вступает опорная сеть. Она решает, что это за данные, кому они адресованы, есть ли у абонента на них право и куда их направить.
На ней держится все: авторизация пользователей, выдача IP-адресов, маршрутизация трафика, подсчет минут и гигабайт, подключение сервисов и связь между базовыми станциями и внешним интернетом. Все, что выходит за рамки простого «поймать сигнал», — уже ее зона ответственности.
Физически между базовой станцией и опорной сетью проходят два потока:
Control Plane — управляющий трафик. Отвечает за процедуры подключения к сети, аутентификации, переключения между станциями, сессий и т. д.
User Plane — пользовательский трафик. Это все, что идет от приложений пользователя: стриминговые сервисы, мессенджеры, браузер и так далее.
Они разделены как логически, так и физически. Такой подход нужен, чтобы обеспечивать надежность, безопасность и гибкость.
В статье Елена Степанова, ведущий инженер-программист в YADRO, объясняет, чем опорная сеть отличается от базовой станции, зачем в 5G сотни микросервисов и как устроена архитектура мобильной связи.
-50% на видеокурсы Слёрма
После жаркого лета останутся не только красивый загар и яркие впечатления, но и новые компетенции и карьерные возможности.
Забирайте курсы в записи по промокоду LETO2025 и учитесь, где и когда удобно, даже в отпуске:
Apache Kafka База: 50 000₽ 🪄 25 000₽
Data Science: 35 000₽ 🪄 17 500₽
CI/CD с Jenkins: 30 000₽ 🪄 15 000₽
и другие варианты выгодного обучения. Подробности — на сайте.
Акция действует с 1 по 31 июля.
Карма vs Инженерная честность: Почему рейтинги убивают экспертизу
Есть в инженерной культуре наивная вера: если система имеет метрики и правила - она безусловно и по умолчанию объективна. Карма на Хабре тому идеальный контрпример. Формально всё честно: пост → оценка → рейтинг. На практике же это цифровой аналог пассивно-агрессивного "не зашло". Без объяснений. Без контекста.
Социальная инженерия вместо экспертной оценки
Главный парадокс: чтобы выжить, ты должен угадывать не истину, а ожидания аудитории. Тон, формат, табу. Это краш-тест на конформизм:
Написал, что 80% мониторинга в проде — это фейковый SLO? → Минус ("негатив").
Сказал, что ChatGPT пишет ТЗ лучше джуна? → Минус ("ересь").
Осмелился быть лаконичным без смайликов? → Минус ("агрессия").
Почему так? Потому что карма измеряет не глубину мысли, а комфорт восприятия. Инженерная точность = высокомерие. Прямолинейность = токсичность. Даже если за этим — годы практики и статистика.
Карма как инструмент подавления инакомыслия
Самое циничное на мой взгляд, найдутся и оппоненты, несомненно, это - непрозрачность. Минус прилетает анонимно, без мандата на критику. И неважно, что твой вклад в тему - как у топ-комментатора. Система молчит, а ты получаешь ярлык "ненадёжного".
Итог:
Действительно качественные и экспертные умы, готовые спорить и рушить догмы, — уходят.
Остаются те, кто мастерски жонглирует банальностями в дружелюбной обёртке. Звучит довольно резко, соглашусь. Но иначе не донести усть мысли.
Платформа медленно превращается в клуб взаимного одобрения.
Что делать?
Игнорировать карму как погрешность системы (но тогда зачем она?).
Требовать мандат для минусов ("Укажи причину: факт ошибка/оффтоп/токсичность"). Хотя у кого тут истребуешь - не нравится, двери на кнопке "выйти".
Ввести верифицированную карму - например, чисто теоретически, только от пользователей с 100+ постами в профильных хабах.
Пока же мы имеем соцсеть, где алгоритмическая справедливость проигрывает человеческой... нетерпимости.
P.S. Этот текст - эксперимент. Проверим, сколько стоит сказать: "Император голый". За инженерную честность - не жалко.
P.P.S. Карма — временна. Культура дискуссии — вечна.
Приглашаем на бесплатный вебинар «Как стартовать в Java и не потеряться: структура, инструменты, кейсы».
📅 Дата: 8 июля
⏰ Время: 18:00–19:00 (Мск)
Java — один из самых востребованных языков, но с чего начать, если вокруг столько информации, а подходы быстро устаревают? В прямом эфире разберем:
✔️ С чего начать в Java, чтобы не тратить время на устаревшие методы
✔️ Ключевые инструменты (JUnit, Maven, Git) — как их применять с первых шагов
✔️ Кейсы, которые помогут на собеседованиях и в реальных проектах
✔️ Как избежать типичных ошибок новичков и сразу писать чистый код
Почему стоит прийти?
🔹 Узнаете, как быстро войти в Java с актуальными знаниями
🔹 Увидите разбор реальных примеров и учебных проектов
🔹 Получите рекомендации по ресурсам и дальнейшему развитию
👨🎓 Спикер: Судакевич Игорь — преподаватель международного уровня, более 15 лет работает в ИТ. Уполномоченный инструктор корпорации Oracle. Магистр компьютерно-информационных технологий. Инструктор платформы Udemy.
Хочу поделиться с вами видением хорошей архитектуры Go проекта, к которой я пришёл на данный момент и также интересно послушать ваши варианты и мнения по данному поводу.
Моё видение:
У нас ядро приложения это сервисный слой (юзкейсы), именно ядро самая основная часть приложения, которая взаимодействует с какой‑то логикой.
Если логика основана на внешних компонентах, то для связи ядра с компонентом(адаптер) и обратно используются абстракции в виде интерфейса(порт). При этом неважно какая связь (от ядра к компоненту или наоборот), внешние компоненты реализуют интерфейсы ядра и не содержат бизнес‑логики, они лишь преобразуют данные к форматам, понятным ядру (интерфейсы также основаны на моделях ядра).
Так как мы не хотим, чтобы логика из ядра уходила во внешние компоненты (по моему мнению, это повлечет переплетение зависимостей и нарушение принципов разделения ответственности), то вся логика должна выполняться на уровне ядра (например, вместо default значений полей в базе, мы создаём модель на уровне ядра, а база служит лишь в качестве хранилища, не выполняя какой‑либо бизнес логики). То есть бизнес‑валидация (инварианты агрегатов) остаётся в ядре, а адаптеры проводят schema‑валидацию (обязательные поля и форматы) до передачи в юзкейсы, тем самым мы избегаем лишних вызовов ядра (при некорректных данных), и не засоряя само ядро валидацией (отличным примером служит то, когда HTTP адаптер валидирует модель до передачи её в юзкейсы).
При этом всё, самое лучше место для интерфейсов (портов) будет отдельный пакет в ядре, к которому могут иметь доступ адаптеры, чтобы проверить реализации контракта (при это адаптеры будут "знать" лишь интерфейсы, а не весь сервисный слой, если бы порты хранились бы в месте использования), а также сами сервисы могут спокойно ссылаться на данные интерфейсы, не подтягивая их с адаптеров (в том случае, если бы мы хранили интерфейсы по месту имплементации).
То есть я считаю идеальной архитектурой для большинства Go проектов, работающих на основании адаптеров (к примеру, REST или gRPC сервис) гексагональную архитектуру с включением подхода DDD.
У меня остались также холиварные вопросы к вам. Как считаете:
Передавать в юзкейсы структуру или поля по отдельности?
Должно ли хранилище, в виде БД например, иметь валидацию данных? Операции по крону? Дефолтные значения полей?
Транзакции: где их начинать/заканчивать?
Когда и где вводить versioning: в HTTP‑уровне, в домене (разные агрегаты) или в репозиториях (Multi‑tenant)?
Должны ли доменные ошибки возвращать rich‑error (с кодом/контекстом) или достаточно обычных error с текстом?
Можно ли развернуть кластер Kubernetes на процессоре с открытой архитектурой RISC-V?
Короткий ответ: нет.
К сожалению, на данный момент «классический» K8s неполноценно портирован на RISC-V. Один из необходимых модулей K8s — kubelet — отказался запускаться на RISC-V-машине (в роли нее — микрокомпьютер Lichee Pi 4A).
Зато облегченная версия оркестратора K3s и Docker Swarm заработали на RISC-V, но с разными компромиссами:
→ Docker Swarm проще в развертывании.
→ K3s — более гибкий в работе, так как поддерживает Kubernetes-инструменты.
В синтетических тестах (stress-ng) K3s показал лучшую производительность на матричных вычислениях — он обошел показатели Docker Swarm примерно в 16 раз. В цифрах: 2.996 bogo ops/s (K3s) против 188 bogo ops/s (Docker Swarm). Возможно, это связано с оптимизацией Kubernetes или меньшими накладными расходами: K3s потребляет меньше ресурсов на фоновые процессы, такие как управление кластером и сетью, что важно для маломощных устройств.
Интересно узнать больше? Тогда переходите по ссылке и читайте подробности экспертимента по заапуску известных оркестраторов на RISC-V.
Как развернуть среду разработки и сервис управления проектами в облаке?
Группа IT-компаний Lad сократила время запуска клиентских проектов, автоматизировала сборку клиентских приложений для iOS и развернула производительную инфраструктуру для публичных сервисов. И все это — на инфраструктуре Selectel.
В основе инфраструктуры — облачные серверы с быстрым запуском, автомасштабированием и возможностью использовать подход GitOps.
Чтобы автоматизировать сборку клиентских приложений для iOS, компания арендовала в Selectel серверы Mac mini®.
За производительность инфраструктуры для публичных сервисов отвечает связка из Managed Kubernetes, Container Registry и S3. Она позволяет поддерживать микросервисную архитектуру с отказоустойчивыми кластерами, автоскейлингом и надежным хранением файлов.
Как группа IT-компаний Lad развернула окружения для разработки и тестирования, а также запустила сервис для управления проектами и ИИ-ассистента для бизнеса, читайте в Академии Selectel.
Вайб-кодинг это TDD в блестящей обёртке и с хорошим пиаром. Change my mind.
И в этом очень-очень много иронии. Давайте прямо: за дцать лет TDD не стал ни стандартом де факто, ни даже общепризнанной хорошей практикой. Если оценим комментарии к местным статьям про TDD, то они скорее всего будут негативными. Даже саму необходимость юнит-тестов постоянно подвергают критике.
Дцать лет апологеты пытаются продвинуть TDD под предлогом улучшения надежности систем и снижения количества дефектов. И дцать лет их полоскают.
Но тут приходит Андрей Карпатый (разработчик ИИ, научно-технический просветитель, ныне больше с креном в инфоцыганство) и говорит страшную вещь. А давайте детально опишем поведение юнита со всеми корнеркейсами и скормим нейронке. А когда нейронка выдаст не совсем то - уточним описание. И так по кругу, пока результат не станет идеальным.
И все такие: ВАУ!!!111 10 ИЗ 10, ГОСПОДИ, 10 ИЗ 10!1
Внезапно оказалось, что если продумать спецификацию, то кодинг - дело техники. А если еще обмазать тестами, то надежность будет железобетонная. И чем детальнее спека, тем лучше результат. Кто бы мог подумать! Хотя погодите-ка...
Мои коллеги по ИТ-компании "Криптонит" пишут на Go. Я попросила их придумать ошибку — сможете её найти? Ждём в комментариях ваши варианты.
package main
import "fmt"
type User struct {
name string
meta map[string]string
}
func (u *User) SetMeta(key, value string) {
u.meta[key] = value
}
func main() {
u := &User{name: "Alice"}
u.SetMeta("role", "admin")
fmt.Println("Meta:", u.meta)
}.
.
.
ОСТОРОЖНО! ДАЛЬШЕ СПОЙЛЕР
В main() мы создаём указатель на User, но не инициализируем вложенную map[string]string (Meta)
Присвоение значения через u.Meta[key] = value, вызовет панику (panic: assignment to entry in nil map), потому что u.Meta всё ещё nil, и в Go нельзя присваивать значения в nil-мапу.
Одним из вариантов было бы добавить функцию NewUser(), создавать пользователя через нее, и сразу инициализировать мапу:
func NewUser(name string) *User {
return &User{
name: name,
meta: make(map[string]string),
}
}
func main() {
u := NewUser("Alice")
u.SetMeta("role", "admin")
fmt.Println("Meta:", u.meta)
}Второй вариант решения изменить SetMeta что бы инициализировать мапу, если она равна nil
func (u *User) SetMeta(key, value string) {
if u.meta == nil {
u.meta = make(map[string]string)
}
u.meta[key] = valueОшибку и решение нам помог составить Алексей Косов, системный инженер департамента инфраструктуры в «Криптоните». Его материал про особенности, применение, плюсы и минусы Golang можно прочитать в этой статье.
Вы наконец победили. Потратив большую часть карьеры на охоту за багами, вы достигли невозможного: багов нет. Вообще. Пусто. Доска с багами пуста, QA тихо плачет в углу, а CI-сервер бездельничает, ровно светясь скучно-зелёным цветом. Но вместо того чтобы попасть в рай, вы оказываетесь в лимбе. Если вы играли в игры начала нулевых, это похоже на выход за границы карты: голый ландшафт, странная геометрия и надпись от разработчика: «Ты не должен был оказаться здесь. Но раз уж оказался — молодец, конечно, только смысла в этом нет».
Что происходит дальше? Ничего хорошего. Первый сюрприз — вас никто не похвалит. Бонуса нет, промоушена тоже. Менеджер лениво листает ваш performance-review, хмурится и спрашивает: «А что ты делал весь квартал?» Ты отвечаешь: «Я избавил нас от багов». Он пожимает плечами: «Так они и раньше вроде не были критичными».
Кто-то бросится чинить метрики, и начнётся новый головняк, потому что вы уж слишком постарались. «Багов не может не быть, значит, сломана метрика», — уверены все. Предлагаете метрику «отсутствие багов» — слышите в ответ: «Недоказуемо, выборка мала!»
Вы думали, что победа откроет двери в рай, а распахнули портал в лимб, где невозможно доказать собственную полезность. Пару поколений инженеров мы упорно объясняли бизнесу, что «баги бывают, это нормально». Благодаря нам продакт-оунеры научились бравировать SLA с допуском на косяк. Мы воспели «умеренное количество дефектов» как здоровый холестерин IT-организма — и вдруг вы свели холестерин к нулю.
Парадокс: все процессы настроены на борьбу, а не на мир. Метрике нужен враг, а процессу — вызов. Без них графики плоские, алерты молчат. Добро пожаловать туда, где ваши достижения стоят ровно ничего. Вся организационная религия строилась на борьбе с багами. Уничтожив последний баг, вы «убили бога» процесса. Всё, что давало смысл (defect-метрики, ретро-ритуалы, баг-баунти), обесценивается; наступает инженерный нигилизм. Великая битва окончена, триумфаторов нет, система сломана. Баг умер — и ты его убил!
Совет: в следующий спринт оставьте пару багов — ради здоровья экосистемы.
В обсуждениях тестирования микросервисов часто всплывает статья Мартина Фаулера Testing Strategies in a Microservice Architecture. Опубликованная в 2014 году, она опирается на концепцию тестовой пирамиды, сформулированную ещё в 2009-м. С тех пор ландшафт тестирования заметно изменился — в первую очередь за счёт появления и широкого распространения Docker и Testcontainers, которые существенно повлияли на практики и экономику тестирования.
Эта трансформация хорошо отражена в более современных источниках:
Сам Мартин Фаулер также в более поздней статье On the Diverse And Fantastical Shapes of Testing отмечает, что трактовка "юнит-тестов" далеко не однозначна и зависит от контекста.
В контексте вашего проекта это означает, что использование интеграционных тестов в 2025 году оказывается существенно проще, дешевле и эффективнее, чем это предполагалось в рамках модели 2009 года.
В Облаке Рег.ру добавили образ NextCloud + OnlyOffice
Запустили удобное корпоративное хранилище для совместной работы с документами в Облаке Рег.ру. Набор офисных приложений OnlyOffice теперь также доступен в облаке — добавили предустановленный образ NextCloud + OnlyOffice. Обновленное облачное решение предлагает универсальную экосистему для совместной работы:
NextCloud подходит для хранения любых документов и файлов;
OnlyOffice позволяет редактировать документы и закрывает большинство стандартных задач пользователей.
Для заказа доступны облачные серверы во всех локациях. Минимальная конфигурация — 4 vCPU, 16 ГБ RAM, 40 ГБ диска.
Новый образ NextCloud 31 + OnlyOffice 5 уже можно тестировать на нашем сайте.
Оцените свои шансы войти в бигтех: тест от Яндекс Практикума
Если у вас в приоритете — опыт работы над масштабным продуктом и строчка в резюме, с ходу впечатляющая HR-ов… Другими словами, если в ваши карьерные планы входит работа в крупной технологической компании — значит, мы придумали этот тест для вас.
Он поможет сориентироваться: проверить хард- и софтскилы и понять, какие навыки уже на высоком уровне — а что стоит прокачать, чтобы повысить шансы оказаться в бигтехе.
Тест вам подходит, если:
Ваша специальность — разработчик, DevOps-инженер, аналитик данных или ручной тестировщик.
Ваш грейд — джун+ и выше. Нужна теоретическая база, коммерческий опыт или опыт решения учебных проектов на реальных кейсах.
Чтобы давать релевантные задачи, мы консультировались с нанимающими менеджерами Яндекса — они знают, чего ждут от соискателей в больших технологических компаниях.
Что ждет участников Ural Digital Weekend 2025?
1-2 августа в Перми мы проведем уже традиционную конференцию про разработку и управление в IT-компаниях — Ural Digital Weekend 2025. Сейчас уже готова программа всех секций.
В 2025 году на конференции выступят спикеры из Альфа-Банк, Т-Банк, Яндекс, Avito.Tech, Ozon.tech, Битрикс24, SM Lab, Cloud.ru, Островок!, Столото, Scrum.ru, +7 pay, «Девелоника» (ГК Softline), Kokoc.tech, .redev, arcsinus, ARTW, ITECH, Terabit, Лидеры Изменений, Викенд в IT, CreativePeople, Luntry, Юникорн (Ujin), Деврел-бюро, MediaSoft, Product Vision, Partner’s Club, Тэглайн / agency2agency, Spectr и множества других известных компаний.
Программа конференции будет разделена на 3 секции: «Разработка», «Управление разработкой» и «Управление бизнесом».
Полная программа и детали в нашем материале на Habr: https://habr.com/ru/articles/919802/
Запустили продажу SSL-сертификатов для комплексной защиты сайтов и почтовых сервисов
SSL-сертификаты — цифровые решения, обеспечивающих безопасность передачи конфиденциальных данных пользователей. Они создают защищенное HTTPS-соединение, которое шифрует логины, пароли, банковские реквизиты и личную информацию.
У нас вы сможете приобрести все популярные типы SSL-сертификатов для бизнес-сайтов, личного блога, почтовых сервисов, финансовых организаций и других проектов, работающих с персональными данными пользователей, в частности из России и Беларуси:
🔑 DV — быстрая проверка домена.
🔑 OV/EV — расширенная проверка организации.
🔑 Wildcard — защита неограниченного количества поддоменов.
🔑 SAN — решение для мультидоменных проектов
и почтовых сервисов.
Повышайте доверие своих пользователей и улучшайте поисковую оптимизацию!
Паттерны проектирования: как всё начиналось?
Это заключительный эпизод курса «Паттерны и практики написания кода». В нём бэкенд-инженер Юра Афанасьев расскажет про истоки возникновения паттернов, а также объяснит, как урбанизм и проектирование городов помогли в создании книги «Паттерны проектирования». Напоследок Юра также разберёт два фундаментальных правила, описанных в книге «Design Patterns».
Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.
Как сделать неудачную платформу для разработчиков? Обсудили в новом выпуске подкаста про 10 грехов DevEx 🔥
В этот раз наш гость Артём Арюткин, руководитель проекта офиса Яндекс, рассказал Cloud.ru про главные ловушки платформенной разработки, что не является DevEx, а также, какой должна быть идеальная платформа.
А еще в выпуске:
почему стандартные метрики вредны для реального положения дел в команде;
как когнитивная нагрузка убивает продуктивность (и при этом импортозамещение);
чем опасна «гибкость» инструментов и когда стандартизация спасает проекты;
почему онбординг новых разработчиков — лучший стресс-тест для платформы.
Вы знаете этих людей. Вроде умные, вроде опытные. Говорят правильные слова про 'стратегию', 'масштабируемость', 'долгосрочную перспективу'.
Но почему-то через полгода таких разговоров оказывается, что:
баг, который 'уже почти пофиксили' никуда из прода не девался
фича, которую 'вот-вот запустим' — всё ещё в черновиках
команда уже тихо ненавидит слово 'архитектура'
А техлид? Техлид как будто ничего не замечает.
Как это работает (точнее, не работает)
Слова вместо кода
вместо пулл-реквестов - диаграммы.
демо нет - зато вот вам слайды.
вместо решений 'опять' 'давайте обсудим' (читай: 'я не хочу отвечать').
Бесконечный 'анализ'
'Надо подумать над архитектурой' = 'Я не уверен, но боюсь признаться'
'Это нетривиальная задача' = 'Мне лень разбираться'
Ответственность - это не про нас
Любимый приём - щедро размазать вину:
'Это комплексная проблема' (на самом деле: 'виноваты все, а значит — никто').
Реальный кейс (чтобы было не абстрактно)
В одном проекте (Node.js, если важно) техлид 2 месяца 'прорабатывал подход' к рефакторингу.
Провёл 8 митингов, написал 50 страниц документации.
А потом... уволился.
Оставив после себя:
красивые схемы в Confluence
ни одной строчки кода
команду, которая теперь на рефакторинг смотреть не может
Как понять, что ваш техлид центральная часть системы самообмана?
главный результат его работы - не код, а презентации
коронный вопрос - 'А как мы это будем масштабировать?' (но не сам масштабирует)
после разговора с ним хочется или закодить, или закопать
Что прикажете с этим делать?
тупо запретить 'стратегировать' без кода*
нет пулл-реквеста - нет права говорить про архитектуру.
ввести 'день испанского стыда'
раз в месяц техлид показывает руками, что сделал. Не слайды - код.
Задавать всего один вопрос
'Что конкретно изменится после твоего решения?'
Если ответ начинается со слов 'теоретически....' - это тревога.
Вывод
Хороший техлид — не тот, кто красиво говорит о проблемах.
А тот, кто их решает.
Если ваш 'архитектор' только генерирует документы, но не генерирует код - возможно, он уже ИИ.
P.S. Если после этого текста кто-то узнал своего техлида - это не совпадение