ПРО АЛГОРИТМЫ НА СОБЕСЕДОВАНИЕ
Раньше я искренне не понимал, зачем некоторые IT‑компании так помешаны на алгоритмах.
Казалось, на реальных проектах алгоритмические задачи почти не встречаются, и фронт‑ и бэкенд‑разработка сводится к знанию фреймворков, «перекладыванию JSON-чиков» и API.
Однако за несколько лет участия в десятках собеседований и после собственного опыта в разработке я убедился: алгоритмы — это самый надёжный способ оценить не только знание синтаксиса, но и скорость разработки и качество мышления на собеседовании. Все остальное можно заучить и «натаскаться» проходя собеседования.
Личный пример.
В начале карьеры я мог быстро писать CRUD на знакомом фреймворке, но на реальную задачу уходило по несколько дней: то упирался в нестандартный кейс, то долго выстраивал логику, код писал не быстро. После целенаправленного изучения алгоритмов и регулярной практики на LeetCode время на решение типичных задач сократилось в разы: я просто «видел» шаблон и быстро его имплементировал.
Почему это не прихоть компаний
Алгоритмические задачи — это как игра на фортепиано: профессионал, играющий разные жанры и виртуозно владеющий инструментом, способен «прочувствовать» любую мелодию и сразу попасть в нужный темп и тон. Так же и разработчик, хорошо натренировавший алгоритмическое мышление, в коде «чувствует» структуру задачи и без лишних проб и ошибок строит оптимальное решение. А скорость выполнения задач - очень важный показатель.
Можно выучить и зазубрить любую теорию: computer science, устройство языка, SQL и NoSQL, брокеры сообщений. Но алгоритмы - это тот навык, который прививается со временем.
Конечно, перегибать палку не стоит: несколько тяжелейших секций на графах и динамическом программировании, далеких от повседневных задач, часто лишь валят кандидатов и отнимают время (возможно это тактичный способ слить кандидата). Главное, что дают алгоритмы — шаблоны мышления и «насмотренность», благодаря которым вы почти на автопилоте пишете чистый, понятный и эффективный код.
Пишите в комментариях, практикуете ли вы алгоритмические задачи, и если да, видите ли у себя прогресс в скорости разработки?
Раньше я искренне не понимал, зачем некоторые IT‑компании так помешаны на алгоритмах.
Казалось, на реальных проектах алгоритмические задачи почти не встречаются, и фронт‑ и бэкенд‑разработка сводится к знанию фреймворков, «перекладыванию JSON-чиков» и API.
Однако за несколько лет участия в десятках собеседований и после собственного опыта в разработке я убедился: алгоритмы — это самый надёжный способ оценить не только знание синтаксиса, но и скорость разработки и качество мышления на собеседовании. Все остальное можно заучить и «натаскаться» проходя собеседования.
Личный пример.
В начале карьеры я мог быстро писать CRUD на знакомом фреймворке, но на реальную задачу уходило по несколько дней: то упирался в нестандартный кейс, то долго выстраивал логику, код писал не быстро. После целенаправленного изучения алгоритмов и регулярной практики на LeetCode время на решение типичных задач сократилось в разы: я просто «видел» шаблон и быстро его имплементировал.
Почему это не прихоть компаний
Алгоритмические задачи — это как игра на фортепиано: профессионал, играющий разные жанры и виртуозно владеющий инструментом, способен «прочувствовать» любую мелодию и сразу попасть в нужный темп и тон. Так же и разработчик, хорошо натренировавший алгоритмическое мышление, в коде «чувствует» структуру задачи и без лишних проб и ошибок строит оптимальное решение. А скорость выполнения задач - очень важный показатель.
Можно выучить и зазубрить любую теорию: computer science, устройство языка, SQL и NoSQL, брокеры сообщений. Но алгоритмы - это тот навык, который прививается со временем.
Конечно, перегибать палку не стоит: несколько тяжелейших секций на графах и динамическом программировании, далеких от повседневных задач, часто лишь валят кандидатов и отнимают время (возможно это тактичный способ слить кандидата). Главное, что дают алгоритмы — шаблоны мышления и «насмотренность», благодаря которым вы почти на автопилоте пишете чистый, понятный и эффективный код.
Пишите в комментариях, практикуете ли вы алгоритмические задачи, и если да, видите ли у себя прогресс в скорости разработки?
👍12🔥3🗿2👏1
Так случилось, что мне пришлось плотно потрогать python 👩💻 в рамках рабочих задач)
Мне стало интересно: а к вы относитесь к вакансиям, в которых в требуется разработка на нескольких языках?
Мне стало интересно: а к вы относитесь к вакансиям, в которых в требуется разработка на нескольких языках?
Anonymous Poll
29%
Положительно – считаю, что это расширяет кругозор и прокачивает навыки.
27%
Положительно, если компания предоставляет обучение и поддержку – важно иметь время и ресурсы на осво
15%
Нейтрально – готов(а) работать на нескольких языках, если требования обоснованы.
21%
Зависит от проекта/языка – готов(а) осваивать новый язык, если это интересно и проект стоящий.
7%
Отрицательно – предпочитаю специализироваться на одном языке.
🔥6❤1
Полгода я вылизывал каждую лекцию, каждое задание, чтобы ты мог изучить Go без воды, с нуля и с фокусом на реальные задачи.
⠀
— быстро и системно освоить Go
— без воды, устаревших туториалов и "постоянно что-то гуглить"
— научиться писать реальные сервисы и пройти собес
⠀
Обновляется постоянно. Не как статьи или книги — он будет жить вместе с языком.
⠀
— Лаконичные уроки + практика
— Пошаговая структура от азов до настоящих API и тестов
— Бесплатные модули для ознакомления
— Постоянные обновления под новые версии Go и best practices
⠀
По промокоду UTOPIA до 15 мая.
Итоговая цена — 5179₽ вместо 7399₽
(И да, ты получаешь доступ навсегда, с обновлениями)
⠀
⠀
Если есть вопросы — пиши, помогу разобраться.
Go — это просто, когда тебя ведут по делу.
⠀
P.S. Это не просто курс. Это путь, который я сам когда-то прошёл. И теперь передаю его тебе — в концентрированной, работающей и честной форме.
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍22🔥17❤7🤔2🏆2🗿2👎1
Go 1.24+ и фиксация инструментов: наконец-то по-человечески
Я тут узнал отличную новость: теперь оказывается можно нормально фиксировать dev-инструменты — прямо в
Например, если ты используешь
Это добавит в
И дальше можно:
Всё! Теперь:
— Версия
— Команда
— Можно забыть про
А раньше что?
Костыли:
—
—
— магия в README, которую никто не читал
Теперь всё по-взрослому, понятно и воспроизводимо.
Go продолжает радовать!🙌
Я тут узнал отличную новость: теперь оказывается можно нормально фиксировать dev-инструменты — прямо в
go.mod, без костылей.Например, если ты используешь
oapi-codegen (а ты точно его используешь, если генерируешь сервер/клиента из OpenAPI v3, ведь так?)):go get -tool github.com/oapi-codegen/oapi-codegen/v2/cmd/oapi-codegen@latest
Это добавит в
go.mod строку:tool github.com/oapi-codegen/oapi-codegen/v2/cmd/oapi-codegen
И дальше можно:
go install tool
//go:generate go tool oapi-codegen -config cfg.yaml ../../api.yaml
Всё! Теперь:
— Версия
oapi-codegen зафиксирована— Команда
go install tool установит его любому разработчику— Можно забыть про
tools.go и ручное go installА раньше что?
Костыли:
—
tools.go с анонимными импортами (import _ )—
makefile с GOBIN=./bin go install и GOBIN=./bin go generate — магия в README, которую никто не читал
Теперь всё по-взрослому, понятно и воспроизводимо.
Go продолжает радовать!
Please open Telegram to view this post
VIEW IN TELEGRAM
ИЗЯЩНАЯ РАБОТА С ОШИБКАМИ В GO, ИЛИ КАК ИХ СРАВНИВАТЬ
Обычное
❓ Как работает
Когда ты используешь
Под капотом
❓ А что делает
Иногда нужно не просто узнать, была ли ошибка определённого типа, но и получить доступ к её полям. Например:
Ты можешь доставать полезные данные из ошибки, если она реализует нужный тип. Это особенно удобно, когда у тебя есть логика, завязанная на тип ошибки (например, логирование по коду, трассировка и т.д.).
❓ Как кастомизировать сравнение — метод
Ты даже можешь сам определить, когда твоя ошибка считается «равной» другой. Для этого нужно реализовать метод
Теперь, даже если сообщения об ошибках разные, но коды совпадают —
❓ Когда и где это реально нужно (примеры из практики)
— В библиотеках: ты возвращаешь ошибки вроде
— В сервисах: API может возвращать ошибки с кодами, а внутри тебе удобно описывать их кастомными типами — и потом ловить их по
— В middleware: например, хочешь логировать всё, кроме
— В gRPC/HTTP-хендлерах: удобно классифицировать ошибки и автоматически подставлять нужный статус код в ответе
— В CLI-инструментах: логика выхода с кодами ошибок может зависеть от типа ошибки, а не только от текста
Если ты до сих пор сравниваешь ошибки через
Больше примеров работы с ошибками даю в бесплатном уроке на своем курсе Go!
P.S. все еще действует промокод на скидку 30% -
Обычное
err == myErr в Go работает не всегда так, как ты ожидаешь. Особенно если ты оборачиваешь ошибку через fmt.Errorf("context: %w", err). В таких случаях Go предоставляет более мощные инструменты — errors.Is и errors.As.errors.IsКогда ты используешь
%w в fmt.Errorf (врапинг ошибки), ты как бы упаковываешь одну ошибку внутрь другой, добавляя контекст. errors.Is умеет разворачивать такие обёртки и проверять, есть ли внутри нужная ошибка:var ErrNotFound = errors.New("not found")
err := fmt.Errorf("ошибка в поиске: %w", ErrNotFound)
if errors.Is(err, ErrNotFound) {
fmt.Println("Ничего не найдено")
}Под капотом
errors.Is делает так: если ошибка обёрнута через %w, она вызывает Unwrap() и идёт по цепочке, пока не найдёт нужную. Если ты просто сравнишь err == ErrNotFound, то получишь false, потому что это уже не тот же объект — он обёрнут.errors.AsИногда нужно не просто узнать, была ли ошибка определённого типа, но и получить доступ к её полям. Например:
type MyError struct {
Code int
Msg string
}
func (e *MyError) Error() string {
return fmt.Sprintf("code: %d, msg: %s", e.Code, e.Msg)
}
err := &MyError{Code: 499, Msg: "custom"}
var myErr *MyError
if errors.As(err, &myErr) {
fmt.Println("У нас ошибка кода", myErr.Code)
}Ты можешь доставать полезные данные из ошибки, если она реализует нужный тип. Это особенно удобно, когда у тебя есть логика, завязанная на тип ошибки (например, логирование по коду, трассировка и т.д.).
Is()Ты даже можешь сам определить, когда твоя ошибка считается «равной» другой. Для этого нужно реализовать метод
Is(target error) в своей реализации:type HttpError struct {
Code int
Msg string
}
func (e *HttpError) Error() string {
return fmt.Sprintf("HTTP %d: %s", e.Code, e.Msg)
}
func (e *HttpError) Is(target error) bool {
t, ok := target.(*HttpError)
return ok && e.Code == t.Code
}Теперь, даже если сообщения об ошибках разные, но коды совпадают —
errors.Is вернёт true:var Err404 = &HttpError{Code: 404}
err := fmt.Errorf("обёрнутая ошибка: %w", &HttpError{Code: 404, Msg: "page not found"})
if errors.Is(err, Err404) {
fmt.Println("Обнаружена 404")
}— В библиотеках: ты возвращаешь ошибки вроде
ErrInvalidConfig или ErrNotConnected, и хочешь, чтобы пользователи могли их отловить независимо от контекста— В сервисах: API может возвращать ошибки с кодами, а внутри тебе удобно описывать их кастомными типами — и потом ловить их по
errors.Is— В middleware: например, хочешь логировать всё, кроме
ErrUnauthorized — тогда errors.Is(err, ErrUnauthorized) спасёт от лишнего шума— В gRPC/HTTP-хендлерах: удобно классифицировать ошибки и автоматически подставлять нужный статус код в ответе
— В CLI-инструментах: логика выхода с кодами ошибок может зависеть от типа ошибки, а не только от текста
Если ты до сих пор сравниваешь ошибки через
==, самое время освоить errors.Is и errors.As. Это делает твой код гибким, читаемым и гораздо ближе к надёжной архитектуре. Go даёт тебе все инструменты — просто используй их.Больше примеров работы с ошибками даю в бесплатном уроке на своем курсе Go!
P.S. все еще действует промокод на скидку 30% -
FEINPlease open Telegram to view this post
VIEW IN TELEGRAM
👍12❤7⚡3👏2🔥1
Всё о разработке | Леонид Ченский pinned «Всем привет! Меня зовут Леонид Ченский, и я решил начать вести свой канал, посвященный разным темам из жизни разработчика. Расскажу немного о себе: ➡️ мне 25 лет ➡️ закончил университет им.Баумана, факультет Информационного Управления с красным дипломом … »
В середине 2000-х инженеры Google — Роб Пайк, Кен Томпсон, Роберт Грисмер — писали миллионы строк на C++ и Java.
Они строили распределённые системы, писали под высокие нагрузки, но с каждым годом сталкивались с одними и теми же болями:
—
—
—
— Код расползался, его невозможно было читать, а уж тем более — быстро понимать
Роб Пайк прямо говорил:
Мы были недовольны масштабируемостью программирования — не систем, а команд.
Именно тогда в Google всерьёз задумываются о новом языке.
Что они хотели от него?
– минимальный синтаксис
– быстрый компилятор
– простую конкурентность
– читаемость на первом месте
– минимум магии и синтаксического сахара
Go не должен быть «умным». Он должен быть понятным.
Не как игрушка.
А как ответ на очень конкретную боль — в реальной разработке, с реальными дедлайнами, в самых нагруженных системах мира.
Пару цитат от создателей:
🗣 Rob Pike:
"Go was born out of frustration with existing languages.
"C++ compilation times were killing us. We’d make a small change and wait forever."
"Go is not about innovation. It’s about making the right compromises."
— Go at Google (2012)
"I can’t tell you how many times I’ve had to dig through 5 layers of indirection in Java just to understand what a function does."
— Google Tech Talk (2012)
🗣 Robert Griesemer (V8, Go):
"It was time to ask: what do we actually need? Go is the result of that question."
"Languages that grew organically became too complex. We wanted to reset the baseline."
— Go Proverbs Talk (2015)
Постепенно Go стал вытеснять Python в инфраструктуре, Perl в автоматизации, Java в микросервисах. Сегодня Go — основа k8s, Docker, Prometheus, Etcd и тысяч продакшн-сервисов в Google, Meta, Uber, Netflix и т.д.
Go придумали, чтобы писать быстро, читать легко и меньше страдать (я бы сказала начать наконец-то получать удовольствие от процесса разработки).
И это работает!
Просто открой Go-код — и всё поймёшь.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍16❤4💯2🔥1
This media is not supported in your browser
VIEW IN TELEGRAM
Ставь 🔥 , если так было и ❤️, если не закомо)
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥17❤6🤣3💯2
Обработка ошибок в Go остаётся прежней — и это прекрасно.
Недавняя статья от команды Go напомнила:
остаётся основным способом обработки ошибок. Несмотря на десятки предложений, язык не уходит в магию, а сохраняет простоту и читаемость. И слава богу!
От себя добавлю: мне близка такая идеология. Ещё в C++ я впервые почувствовал радость, когда увидел
— вместо try/catch можно было просто передавать ошибку по ссылке:
P.S. Подробно о работе с ошибками рассказываю в бесплатном уроке на своем курсе Go!
Недавняя статья от команды Go напомнила:
if err != nil
остаётся основным способом обработки ошибок. Несмотря на десятки предложений, язык не уходит в магию, а сохраняет простоту и читаемость. И слава богу!
От себя добавлю: мне близка такая идеология. Ещё в C++ я впервые почувствовал радость, когда увидел
boost::error_code
— вместо try/catch можно было просто передавать ошибку по ссылке:
boost::system::error_code ec;
do_something(ec);
if (ec) {
// обработка ошибки
}
P.S. Подробно о работе с ошибками рассказываю в бесплатном уроке на своем курсе Go!
👍9🔥6🆒3👎1
🔥 На этой неделе было жарко — и не только из-за погоды.
Мне досталась задача с категорией «что это вообще такое?» — реализовать аутентификацию в БД через JWT. Да-да, не в backend-приложении, а прямо в базу данных.
⠀
На первый взгляд — странная идея. На второй — всё ещё странная. Но раз надо, значит, разберёмся.
Первая остановка — знакомство с CQL и SASL. Сначала всё выглядело как очередная боль с патчами в движок БД. Но потом пришлагениальная здравая мысль: «А может, не будем трогать исходники БД, а обойдёмся встроенным механизмом
⠀
Почему бы и нет. Чтобы быстро проверить гипотезу, накидал мини-сервер на Python, который выступает в роли PAM-скрипта. Почему Python? Потому что
не надо компилировать,
править и деплоить, когда нужно ковыряться в auth flow прямо на тачке, скорость важнее всего.
На бумаге всё работало. В реальности — нет.
Документация уверяла, что всё ок. Но мы же с вами знаем: лучшая документация — это исходный код.
⠀
Погружаюсь в C++ код БД — и, неожиданно, кайфую.
Там тебе и
Увы, выяснилось, что в моей версии БД нужного функционала просто нет — поддержка
Собираем образ с нужной версией. Через ONE HOUR LATER я вспоминаю, почему не скучаю по C++: сборка проекта — это медитация, но против воли.
⠀
Обновил базу. Начинается весёлый блок под названием «танцы с бубном вокруг
Теперь самое интересное: пробуем отправить JWT. И… ничего! Ошибка! Даже не ошибка — тишина. В логах — пусто. Скрипт даже не вызвался.
⠀
Значит, где-то на пути client → DB → saslauthd → pam → мой скрипт
что-то сломалось. Подозрение на длину токена.
Лезу в код БД — там всё ок, длина пароля кодируется 2 байтами, ограничений на буфер жестких нет, можно пихать токены хоть длиной 65536. Лезу глубже — в исходники saslauthd (да-да, снова та самая документация).
И вот он, убийца надежды:
Ладно, значит, пишем свой
Снова Python, снова быстрая проверка. И... ура! Всё работает!
Теперь можно коннектиться к БД с JWT в 2025 году. Без хаков, без патчей. Просто красиво.
Осталось дело за малым: переписать всё на Go, для скорости, стабильности идушевного спокойствия перформанса. Но это уже не сегодня…
Итого, за неделю удалось потрогать Python и Go, вспомнить C и С++, поперекладывать байтики и доказать работоспособность идеи.
А у вас как неделя прошла? Были задачки на стыке "невозможно" и "ну попробуем"?
Мне досталась задача с категорией «что это вообще такое?» — реализовать аутентификацию в БД через JWT. Да-да, не в backend-приложении, а прямо в базу данных.
⠀
На первый взгляд — странная идея. На второй — всё ещё странная. Но раз надо, значит, разберёмся.
Первая остановка — знакомство с CQL и SASL. Сначала всё выглядело как очередная боль с патчами в движок БД. Но потом пришла
saslauthd + pam?»⠀
Почему бы и нет. Чтобы быстро проверить гипотезу, накидал мини-сервер на Python, который выступает в роли PAM-скрипта. Почему Python? Потому что
не надо компилировать,
править и деплоить, когда нужно ковыряться в auth flow прямо на тачке, скорость важнее всего.
На бумаге всё работало. В реальности — нет.
Документация уверяла, что всё ок. Но мы же с вами знаем: лучшая документация — это исходный код.
⠀
Погружаюсь в C++ код БД — и, неожиданно, кайфую.
Там тебе и
coroutines, и lambda, и futures, и promises, и iterators. Весь код на C++23 как он есть. После Go, где всё прямолинейно, минималистично и «пресно», это было как попасть в пряничный домик. Уровень сахара подскочил до предельного уровня, частота пульса подскочила. Еще пару дней придется отходить…Увы, выяснилось, что в моей версии БД нужного функционала просто нет — поддержка
saslauthd появилась позже.Собираем образ с нужной версией. Через ONE HOUR LATER я вспоминаю, почему не скучаю по C++: сборка проекта — это медитация, но против воли.
⠀
Обновил базу. Начинается весёлый блок под названием «танцы с бубном вокруг
saslauthd и pam». Попытка номер ∞, и наконец — успех. Скрипт принимает тестовый admin/admin — можно жить!Теперь самое интересное: пробуем отправить JWT. И… ничего! Ошибка! Даже не ошибка — тишина. В логах — пусто. Скрипт даже не вызвался.
⠀
Значит, где-то на пути client → DB → saslauthd → pam → мой скрипт
что-то сломалось. Подозрение на длину токена.
Лезу в код БД — там всё ок, длина пароля кодируется 2 байтами, ограничений на буфер жестких нет, можно пихать токены хоть длиной 65536. Лезу глубже — в исходники saslauthd (да-да, снова та самая документация).
И вот он, убийца надежды:
#define MAX_BUF_LEN 256
🙃 Да, кто ж в 2000-х думал, что кто-то будет пихать в пароль пару килобайт JSONа. Протокол может, а реализация — нет.Ладно, значит, пишем свой
saslauthd.Снова Python, снова быстрая проверка. И... ура! Всё работает!
Теперь можно коннектиться к БД с JWT в 2025 году. Без хаков, без патчей. Просто красиво.
Осталось дело за малым: переписать всё на Go, для скорости, стабильности и
Итого, за неделю удалось потрогать Python и Go, вспомнить C и С++, поперекладывать байтики и доказать работоспособность идеи.
А у вас как неделя прошла? Были задачки на стыке "невозможно" и "ну попробуем"?
2👍19❤3🆒3
Ozon Tech Community Platform Meetup
20 июня | 19:00 | Москва и онлайн
Команда платформы Ozon раскроет в красках с чем сталкивается и какие решения внедрили!
Регистрация — занимайте себе место заранее.
20 июня | 19:00 | Москва и онлайн
Команда платформы Ozon раскроет в красках с чем сталкивается и какие решения внедрили!
Регистрация — занимайте себе место заранее.
🔥4❤2🆒2⚡1
В Go 1.25 подъедет синтаксический сахар для WaitGroup. Это, конечно, здорово, однако такое уже давно реализовано в библиотеке github.com/sourcegraph/conc. Могли бы добавить больше конструкций...
В своих проектах охотно использую conc, а вы?
В своих проектах охотно использую conc, а вы?
🔥10💔3👍2🆒2
В продолжение к предыдущему посту...
в Go 1.25
- появится новый пакет
- json/v2 - "быстрее, выше, сильнее"
-
- Новый эксперементальный сборщик мусора
Больше деталий можно найти в гайде тут
в Go 1.25
- появится новый пакет
synctest для удобного тестирования concurrency кода (реально долгожданная вещь)- json/v2 - "быстрее, выше, сильнее"
-
GOMAXPROCS теперь корректно работает в контейнерах- Новый эксперементальный сборщик мусора
Green Tea (обещает работать лучше при аллокации маленьких объектов в большом количестве) Больше деталий можно найти в гайде тут
antonz.org
JSON evolution in Go: from v1 to v2
Reviewing the key changes in json/v2.
👍7❤3
В этом году Ozon снова делает большую инженерную конференцию E-CODE. На этот раз я член программного комитета секции Backend и объявляю сбор заявок📲
Если вы — миддл+ и глубоко копаете в Go, C# или Java, нам есть о чём поговорить.
🔍 Что мы ищем:
— Хардкорные доклады (пару настоящих мясных штук)
— Практические и универсальные темы, понятные всем из бэкенда
👂 Что особенно хочется услышать в этом году:
👩💻 Go
— Внутрянка Go, сети оптимизации и новые фичи языка, которые принесли пользу
— Архитектура больших приложений
— Как писать масштабируемый Go-код
— Нативные решения (не коробки)
— Работа с БД: что используете, как, зачем, полехные лайфхаки и workaround
👩💻 C#
— Архитектура, паттерны, практики — с оглядкой на реальный опыт
— И тоже — глубже, чем поверхностная обёртка SDK
👩💻 Java
— Без Spring'а, пожалуйста (ничего личного)
— Теория языковых фич
— Сборщики мусора и внутренняя кухня JVM
👩💻 Универсальное (для всех языков):
— Алгебраические типы данных
— Отказоустойчивость: гарантии доставки и обработки
— Архитектурные подходы, применимые в любой стеке
Если вы давно хотели рассказать что-то сложное, важное, нетиповое — самое время.
🔗 Подать доклад можно по ссылке
Если вы — миддл+ и глубоко копаете в Go, C# или Java, нам есть о чём поговорить.
— Хардкорные доклады (пару настоящих мясных штук)
— Практические и универсальные темы, понятные всем из бэкенда
— Внутрянка Go, сети оптимизации и новые фичи языка, которые принесли пользу
— Архитектура больших приложений
— Как писать масштабируемый Go-код
— Нативные решения (не коробки)
— Работа с БД: что используете, как, зачем, полехные лайфхаки и workaround
— Архитектура, паттерны, практики — с оглядкой на реальный опыт
— И тоже — глубже, чем поверхностная обёртка SDK
— Без Spring'а, пожалуйста (ничего личного)
— Теория языковых фич
— Сборщики мусора и внутренняя кухня JVM
— Алгебраические типы данных
— Отказоустойчивость: гарантии доставки и обработки
— Архитектурные подходы, применимые в любой стеке
Если вы давно хотели рассказать что-то сложное, важное, нетиповое — самое время.
Please open Telegram to view this post
VIEW IN TELEGRAM
E-CODE 2025 — IT-конференция от Ozon Tech // 13 и 14 сентября // Москва и онлайн
Инфраструктура и DevOps, С# и Go, iOS и Android, машинное обучение, тестирование, менеджмент, приглашенные гости.
1❤8🔥6👍4