Senior | Lead | Architect .NET Core Developer
Онбординг — это не просто «рассказать, как у нас всё устроено». Это ежедневная, изматывающая работа, которую часто делают в фоне.
Рассказываем, как с помощью ИИ разгрузить команду и ускорить адаптацию новичков — без потерь в качестве и продуктивности.
ИИ уже пишет код, управляет проектами и общается с коллегами. Но можно ли прямо сейчас доверить ему всю офисную работу? Исследователи протестировали 7 самых мощных нейросетей на 175 реальных задачах. Спойлер: полностью заменить сотрудников нейросети пока не могут. Но давайте разберемся, что именно у них получается лучше всего, какие задачи еще вызывают трудности и стоит ли уже сегодня нанимать себе цифрового помощника в штат.
В управлении командами есть скрытое искусство — искусство тонкой настройки процессов вместо бесконечных героических подвигов. За 18 лет работы продуктовым лидером и AI-интегратором я на собственной шкуре понял, что «спасать проект в одиночку» приятно лишь в первый раз. Дальше — выгорание, несостыковка ожиданий и хрупкий хаос. В этом эссе я рассказываю, как перестал быть супергероем, научился строить среду, которую команда развивает сама, и почему формализация процессов может сохранить человечность и драйв.
Финансы, ритейл, соцсети, облака – везде свои тараканы, но требования схожи: чтобы летало и не падало. Балансировка нагрузки – это как фундамент для небоскреба. Криво зальешь – все рухнет. И вот тут стандартный Round Robin, при всей его простоте, часто оказывается тем самым кривым фундаментом.
Переход от монолита к микросервисной архитектуре приносит гибкость и масштабируемость, но и создает новые сложности. Одна из ключевых проблем –согласованность данных и транзакции. В монолите обычно можно обернуть несколько операций одной ACID-транзакцией: либо все операции выполняются успешно, либо при ошибке происходит полный откат. В мире микросервисов такой прямолинейный подход не работает. Каждый сервис автономен, у каждого своя база данных, и общаются они через сеть. Как результат, гарантировать атомарность и целостность процессов, охватывающих несколько сервисов, непросто. Возникает риск частичных обновлений: одна часть системы изменилась, а другая – нет, что приводит к неконсистентным (несогласованным) состояниям данных.
Чтобы решить эту проблему, разработаны специальные паттерны и протоколы управления распределёнными транзакциями. В этой статье детально рассмотрим ограничения классических ACID-транзакций в распределённой архитектуре, а также два подхода к распределённым транзакциям – сага (SAGA) и двухфазный коммит (2PC). Разберём мотивацию, принципы работы, преимущества и недостатки каждого, сравним их по критериям. Кроме того, обсудим альтернативные подходы, такие как TCC (Try-Confirm-Cancel), паттерн Outbox, а также кратко упомянем eventual consistency, транзакционные сообщения, инструменты вроде Atomikos и др. В завершение – практические рекомендации, как выбрать подходящий способ обеспечения согласованности в ваших микросервисах.
Здравствуйте, меня зовут Дмитрий Карловский и я.. придерживаюсь следующей парадигмы мышления: всякое определение должно иметь чёткую границу между тем, что ему соответствует, и тем, что не соответствует.
К сожалению, часто можно встретить споры о пересекающихся определениях, словно они взаимоисключают друг друга. Не менее часто можно встретить ложную дилемму между двумя терминами не покрывающими всё множество сущностей.
Что ж, позвольте внести ясность и предложить вам непротиворечивую классификацию парадигм - подходов к написанию кода, во многом определяющих способ мышления человека по донесению задачи до кремниевого исполнителя.
git clone https://www.bamsoftware.com/git/zipbomb.gitzipbomb-20190702.zip
git clone https://www.bamsoftware.com/git/zipbomb-paper.git
Оценивать ли время на выполнение задач в IT? А может быть просто пойти и начать делать? А может быть можно оценить объем задач, а не время? И что же вообще нужно и можно оценить?
В этой статья я рассказываю про 4 метода оценивания задач в IT — от угадывания до хороших и честных расчётов.
Однажды мне стало интересно: а что будет, если отправить пакет с несуществующим транспортным протоколом? Не TCP, не UDP, не ICMP — вообще что-то выдуманное. Пропустит ли его ОС? Дойдет ли он хотя бы до сетевого интерфейса? Не зарежет ли его какой-нибудь промежуточный маршрутизатор? А вдруг он еще и быстрее обычного дойдет, потому что никто не знает, что с ним делать?
Ответа у меня не было. Так что я решил проверить.
Привет, меня зовут Илья. Я основал Perfect Wiki — SaaS продукт для создания внутренних баз знаний компании, который работает прямо внутри Microsoft Teams. Мы сделали простой и удобный инструмент для хранения, редактирования и обмена знаниями внутри компании. Всё началось с желания решить одну конкретную боль: встроенная Wiki в Microsoft Teams была неудобной, а достойной альтернативы с полноценной интеграцией просто не существовало.
В этой статье я хочу рассказать, как появилась сама идея, какие ошибки я допускал, как нашёл первых клиентов и как постепенно за пять лет дошёл до стабильного дохода в $250,000 в год. Всё это — без инвесторов, команды из 20 человек и “раунда A”.
System Design Interview — пожалуй, один из самых «бесформенных» этапов технического собеседования. Здесь важно не найти единственно верное решение, а продемонстрировать системное мышление, умение работать с абстракциями, логически выстраивать архитектуру и аргументированно делать выбор технологий.
Александр Кучук, эксперт сообщества Spring АйО, подготовил авторскую статью, в которой шагом показывает, как структурировать интервью, какие вопросы задавать, как рассуждать и что оценит интервьюер.
Кстати, Александр ведет репозиторий с заметками: https://github.com/qcha/JBook
За последние несколько лет я перестроил свой процесс найма разработчиков, начал по-другому готовиться к собеседованиям и проверять нужные навыки. Как мне кажется, у меня получилось повысить свою продуктивность и научиться нанимать подходящих разработчиков в проекты, где я работаю.
Пару недель назад меня попросили помочь на техническом собеседовании для Senior/Lead backend-разработчика и поделиться опытом. В процессе я формализовал несколько правил, которых придерживаюсь при проверке кандидатов. Чем я и хочу поделиться.
Ниже — мои советы по проведению интервью с конкретными примерами. Уточню, что это не подробное руководство по найму на конкретную должность, а универсальные рекомендации для всех интервью с разработчиками.
Привет. Мне 32 года, идентифицирую себя как Middle Frontend Developer. У меня почти 7 лет опыта работы, из которых только три я считаю релевантными, где я работал с современными технологиями типа React, TypeScript, GraphQL и т.д. До этого работа заключалась в разработке сайтов с использованием JQuery.
В конце марта мы с женой узнали, что наше заявление на получение Канадских виз одобрено и уже через три недели нам нужно быть там. Она стала иностранным студентом на одногодичной последипломной программе с последующим получением разрешения на работу. Я, как супруг, получил открытое разрешение на работу и могу работать на любого работодателя.
Исследование принципов Domain-driven Design (DDD) на примере кейса "Аутсорсинг"
Статья демонстрирует эволюцию от простой анемичной доменной модели к сложному решению в стиле DDD, охватывая ключевые концепции, такие как единый язык, ограниченный контекст, агрегаты и доменные события.
В завершающей части руководства от Google мы фокусируемся на лучших практиках и тонкостях мастерства промпт-инжиниринга. Изучаем все аспекты работы с БЯМ: от контроля температуры и Top-K/Top-P параметров до применения таких техник как промптинг с отступлением, цепочки рассуждений и ReAct. Разбираем преимущества использования структурированных форматов и переменных в промптах. Завершается статья практическими советами по документированию, тестированию и оптимизации промптов. Это не просто руководство — это комплексная система знаний, позволяющая максимально эффективно использовать возможности больших языковых моделей.
Представляю вашему вниманию перевод статьи "Prompt Engineering" (Промпт-инжиниринг) авторства Lee Boonstra - Software Engineer Tech Lead, Office of the CTO в Google.
Это первая часть из цикла трех статей, где мы разберем основы промпт-инжиниринга и базовые техники взаимодействия с большими языковыми моделями. Вы узнаете, как настраивать параметры моделей, использовать различные типы промптов и получать предсказуемые, релевантные результаты. Несмотря на фокус оригинала на Gemini/Vertex AI, описанные принципы применимы ко всем современным моделям ИИ.
Всем привет, меня зовут Стас, я техлид в Mish Product Lab.
Тема возникла не просто так: внутри команды у нас было немало споров и дискуссий о том, какой инструмент для проксирования и терминации SSL лучше использовать в различных ситуациях. Изначально все наши гипотезы были основаны больше на личных предпочтениях, чем на реальных данных. Мы долго спорили, надеясь, что истина будет где-то рядом с нашими любимыми решениями. Но в итоге пришли к выводу, что единственный способ получить действительно объективный ответ — это протестировать и сравнить различные варианты на практике.
Именно так родилась идея провести сравнительный анализ производительности HAProxy, Envoy, Nginx, Caddy и Traefik с поддержкой SSL/TLS. Мы хотели понять, какой из инструментов «из коробки» предоставляет наилучшую производительность и минимальные накладные расходы, особенно при обработке SSL-трафика, который, как известно, требует дополнительных ресурсов из-за шифрования и дешифрования.
Хочу начать с личной предыстории. Давным‑давно, как и многие из вас, я читал умные книжки: «Чистый код» и «Чистая архитектура» Роберта Мартина, «Совершенный код» Стива Макконнелла и другие.
Также не обошли меня и классические принципы проектирования — SOLID, KISS, DRY — и, думаю, каждый читатель добавит сюда свои.
Безусловно, это всё важные и фундаментальные вещи.
Но однажды на горизонте появилось DDD — предметно‑ориентированное проектирование в изложении Эрика Эванса. Именно его «синяя книга» стала культовой и задала язык для архитектурного мышления.
Позже я открыл и «красную книгу» Вона Вернона, где DDD уже рассматривался с точки зрения практической имплементации: архитектура, код, реальные подходы в проектах.
Читая Эванса, рассматривая его диаграммы классов и примеры кода, я всё думал: как он это делает?
Самым большим открытием для меня стало то, что книга DDD хоть и показывает стратегические и тактические приёмы — агрегаты, объекты‑значения, спецификации, фабрики и т. д. — но не учит проектировать саму предметную область.
Складывалось ощущение, что мы это уже откуда‑то должны были знать. А откуда — остаётся загадкой.
Гугл выпустили простую и понятную инструкцию, как настраивать модель, как создавать промпты, что влияет на результат, и небольшие лайфхаки. Оригинал.
Дальше будет небольшая выжимка и перевод с помощью ChatGPT.
Промпт-инжиниринг — это навык создания эффективных входных данных (запросов), чтобы направлять эти мощные модели ИИ к генерации конкретных, точных и полезных результатов, которые вам нужны.
Что такое Промпт-инжиниринг?
Большая Языковая Модель(БЯМ) работает, предсказывая наиболее вероятную последовательность слов (или «токенов»), следующую за вашим вводом. Когда вы пишете запрос, вы, по сути, задаете начальную точку и направление для этого процесса предсказания. Промпт-инжиниринг включает в себя:
Индексы – это «ускорители» доступа к данным в базах данных. Правильно выбранные индексы могут многократно ускорить запросы, что особенно критично в highload-системах с большими объёмами данных и большим числом запросов. Однако за ускорение чтения приходится платить усложнением записи и дополнительным расходом памяти. В этой статье мы подробно рассмотрим, как работают разные типы индексов в реляционных СУБД, как выбирать индекс под конкретный запрос, обсудим подводные камни (например, блоат, переиндексация, избыточные индексы) и затронем индексацию в NoSQL (MongoDB, Cassandra). Завершим чеклистом, который поможет выбрать оптимальный индекс под вашу задачу.