Шаблоны проектирования распределенных систем предоставляют разработчикам проверенные решения и передовые методы проектирования и внедрения распределенных приложений.

Оценка 360 градусов, часто упоминаемая как "360-градусная обратная связь", представляет собой отличный инструмент в сфере управления персоналом и развития лидерских качеств. В отличие от традиционных методов оценки, где руководитель или непосредственный начальник оценивает работу подчиненного, 360 градусов включает в себя обратную связь от широкого круга людей, включая коллег, подчиненных, руководителей и даже клиентов. Такой подход позволяет получить более полную и объективную картину компетенций, поведения и взаимодействия сотрудника внутри организации.

Как известно, многие реляционные базы данных, а в данном конкретном случае PostgreSQL, обещают нам, что наши транзакции будут обладать соответствовать критериям ACID (Атомарность, Согласованность, Изолированность, Сохраняемость), при должном уровне конфигурирования тех или иных настроек.

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

А не будем мы о ней говорить прямо сейчас, потому что для начала хотелось бы поговорить о том, как в принципе выполняется запрос? Речь пойдет об одной машине Postgres, не рассматривая вопросы репликации и согласованности реплик.

Давайте представим ситуацию, что у нас есть база данных, в которой есть простенькая таблица:

В прошлой публикации мы обсудили механизм парсинга, оптимизации и исполнения запроса в PostgreSQL. В процессе обсуждения, был также затронут WAL (Write-Ahead Log). Давайте разберемся, что же это такое.

WAL, он же Write Ahead Log - бинарный лог, хранящий в бинарном виде непоcредственные результаты исполнения транзакций, модифицирующих текущее состояние данных. Речь идет о запросах INSERT, UPDATE и DELETE.

WAL обеспечивает Durability из ACID, т.е. сохранность данных в случае любых возможных сбоев.  Тем не менее, ошибочно представлять себе WAL как бэкап данных. Смысл данного механизма не в хранении копии всех созданных и измененных данных с момента создания бд.

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

Всем привет! Меня зовут Виктор Василенко, я техлид и Solution-архитектор. Я работал в Яндексе и X5 Group и уже не первый год сотрудничаю с Практикумом. Я делюсь опытом на курсах «Алгоритмы и структуры данных» и «Асинхронное программирование на Python».

Архитектор ПО — это специалист, ответственный за проектирование структуры и организацию системы или продукта. Роль архитектора в IT-компании включает в себя не только технические задачи, но часто и коммуникационные и организационные обязанности. Также архитектор является промежуточным звеном между бизнес-процессами и технологическими решениями.

Пока что индустрия не может чётко определить эту деятельность как профессию. В общероссийском классификаторе профессий ОКПДТР архитектор встречается скорее ландшафтный, чем программного обеспечения. В вузах вы не сможете найти специальность «Архитектура программного обеспечения». 

Границы профессии достаточно размытые, и часто это не профессия и должность, а скорее роль. Задачи разнятся: архитектор должен уметь писать код и документировать его для коллег, в то же время он может коммуницировать с бизнесом и заказчиками, выстраивать стратегию развития компании на годы вперед. 

В этой статье я хочу поделиться своим видением роли архитектора ПО и рассказать:

Кто такой архитектор ПО и какие они бывают;

Чем занимается архитектор решений в компаниях разного масштаба;

Чем отличаются инженеры от архитекторов ПО;

Какие обычно задачи стоят перед архитектором ПО;

Конкретно: какие нужны навыки и компетенции;

Как перейти из инженера на позицию архитектора.

В предыдущей статье мы обсудили стратегические паттерны, а теперь давайте углубимся в тактические. Важно помнить: в DDD тактика без стратегии теряет смысл! Если вы не знаете, как правильно разделить систему, отдел или предприятие на контексты и поддомены, ваши усилия, направленные на тактические паттерны, вряд ли принесут плоды. Стратегическое мышление в сочетании с тактическими подходами поможет создать эффективную и гибкую архитектуру, способную справляться с изменениями и требованиями бизнеса.

Прим. перев.: системный архитектор Avery Pennarun, создавший VPN-решение Tailscale на базе WireGuard, размышляет об отличиях монолитов с модулями от микросервисов. Он рассказывает об эволюции подхода к модульности вообще и о том, почему изоляция до сих пор далека от совершенства, а также делится своим мнением о том, когда проводить границы между сервисами рационально.

В последнее время меня часто спрашивают, в каких случаях переход на микросервисы — хорошая затея. В статье «Systems design explains the world» я размышляю о таких типичных проблемах, как эффект второй системы, дилемма инноваторов и других. Может ли проектирование систем дать ответ на вопрос о микросервисах? Да, хотя ответы могут вам не понравиться.

Всем привет! С вами Женя, разработчик Dodo Engineering и один из ведущих подкаста «Читаем вместе». Он посвящен IT-книгам. В каждом сезоне мы планируем читать и разбирать одну книгу. Уже подходит к концу первый сезон, который мы посвятили книге Fundamentals of Software Architecture. Она написана архитекторами для архитекторов, но разработчикам, особенно тем, которые интересуются, как создавать работающие системы, тоже может быть очень интересна и полезна.

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

Не можете найти концов, почему было принято то или иное решение? Рассказываете коллегам по сто раз одно и то же? Обсуждения в мессенджерах превращаются в срачи на десятки сообщений?

Знакомо? Нам тоже. Но мы смогли победить эти проблемы.

Под катом выжимка из главы и нашего выпуска, а также практический опыт Dodo Engineering, как правильно оформлять и хранить архитектурные решения.

Модульный монолит — это подход к проектированию приложений, который позволяет, с одной стороны, отложить во времени операционную сложность использования микросервисов, а с другой — избежать превращения монолитной системы в большой комок грязи. Сама идея модульности не нова и основана на давно известных принципах Separation of Concerns и Information Hiding. Но не так-то просто перейти от абстрактных принципов к пониманию, как их реально использовать на практике.

На Хабре не так много информации о модульных монолитах в целом и практически ничего о конкретных вариантах их реализации. Но об этом есть серия статей у Камиля Гржибека. Сегодня поделюсь переводом первой из них.

Микросервисная архитектура

Теорию вероятностей спрашивают и на собеседованиях, и на экзаменах, также она является фундаментом для многих методов машинного обучения. По моим наблюдениям студентам явно не хватает того курса теор вера, который есть в ВУЗах, чтобы научиться решать основные задачи — необходимы дополнительные материалы. В этой статье хотел бы поделиться моими самыми любимыми материалами и источниками для освоения теории вероятностей, имея за плечами крепкую школьную базу и скромные навыки в математическом анализе и линейной алгебре.

Количество выпускников онлайн-школ продолжает расти, однако многие сталкиваются с трудностями при поиске первой работы в IT. Да и джунам, у которых есть небольшой опыт приходится несладко (статистики у меня нет, просто по общим наблюдениям в соц. сетях). У них встает резонный вопрос: Как подготовиться к собеседованию в IT? Хотелось сделать продукт, от которого будет польза при подготовки к собесам, но который бы обходился для меня минимумом затрат.

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

Пару раз на предыдущих местах работы я попадал на проект, где не было документации. Все знания о проекте были у разных коллег, а некоторые части систем вообще были «чёрными ящиками».

Что делать, когда попал в проект без документации? Ответ простой — уходить!

А если серьёзно, отсутствие документации — возможность для прокачки хардов и софтов. Мне приходилось собирать информацию по крупицам и минимизировать bus‑фактор. В статье дам пошаговую инструкцию, чтобы облегчить жизнь тем, кто попадёт в аналогичную ситуацию.

Мы, студенты из МИФИ, Даниил и Александр, пришли на стажировку в Сбербанк в департамент SberData, который занимается развитием внутренней корпоративной аналитической платформы (КАП).Это современная платформа с удобными инструментами созданная для закрытия полного спектра потребностей Сбера в работе с данными, таких как хранение, интеграция, разнообразная аналитика, отчетность, моделирование и контроль качества данных. Все эти направления было бы трудно развивать без отдельного R&D подразделения, в составе которого мы и работаем. Сегодня мы хотим поделиться нашим исследованием в области проектирования алгоритмов в выявлении «токсичных» SQL‑запросов с помощью машинного обучения. Почему же запросы называются именно «токсичные»? Они затрачивают на своё выполнение слишком большое количество ресурсов, а именно времени. На самом деле не только время, но для упрощения мы будем считать только время, так как это ключевой параметр.

Статья посвящена исследованию существующих подходов и их апробации на открытых данных. В качестве общедоступных данных были выбраны данные из таких бенчмарков, как TPC‑H и BIRD. Помимо этого, в статье рассматриваются некоторые трудности, с которыми мы столкнулись при работе над задачей, например, генерация данных и SQL‑запросов, а также миграция между диалектами SQL. В конце статьи мы опишем оригинальный подход, к которому по итогу пришли. В следующей статье мы расскажем о применении полученного опыта для реальной промышленной системы.

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

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

🔜 Как вы будете рекомендовать девушек в анкетах знакомств, если не вычислите статистическую вероятность симпатии от огонечков на шести сторисах?

🔜 Как вы будете подсчитывать успех кражи внутренних данных компании в обход NDA?

🔜 Может ограбить банк не такая уж плохая идея с вашими вводными данными?

Байес — это палочка-выручалочка.

По статистике 90% мужчин и девушек, что знают метод МСМС, лучше пахнут и получают на 100% больше взаимных симпатий.

Хотите также? — читайте нашу статью по Байесовской статистике в ML для самых маленьких.

Руководитель проекта должен любить людей. И любить с людьми общаться. Потому что к только вы становитесь Руководителем проектов, вам нужно начинать говорить с кучей народа: с командой – это минимум несколько человек, с заказчиками – это тоже часто несколько человек. Еще есть линейный руководитель, руководители команды, руководители заказчиков, релиз менеджеры, инженеры поддержки, внешние эксперты - короче, если вы не любите разговаривать с людьми, если долгое общение вас сильно утомляет, лучше всерьез подумать о какой-то другой работе.

Неопытному руководителю очень просто запутаться в этом треше из созвонов, чатов в Телеге, писем в почте и устных договоренностей. Эта статья поможет распутаться: понять, какие есть каналы коммуникаций и как ими пользоваться.

Действительно ли надо всегда звонить, а не писать письмо? Какие еще есть варианты?

Как правильно и экологично проводить встречи?

Как не превращать встречи в ППР?

Обо всем этом коротко ниже.

Это очередная статья о том, чего не рассказывают на курсах РП: о тех самых софт-скиллах, которые потребуются Руководителю проектов с самого первого дня работы. Если вам интересны такие истории, читайте другие мои статьи на Хабре и подписывайтесь на мой ТГ канал "Морковка спереди, морковка сзади".

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

Звание «сениор», когда-то бывшее признаком большого опыта и знаний, обесценилось больше всего. Сегодня разработчиков начинают величать «сениорами» невероятно быстро, часто всего спустя три-четыре года работы. Как будто путь к «сениорству», бывший когда-то марафоном нарабатывания навыков и разнопланового опыта, превратился в спринтерский забег.

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

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

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

И потому мы с вами разберём 7 способов выявить причины выгорания и устранить их.

Счастливый сотрудник - успешная компания.

Ревью - важный этап разработки и одна из самых частых точек взаимодействия разработчиков с кодом и между собой, особенно в распределенных командах. Один разработчик пишет код, другой (ревьюер) - проверяет написанное, а тимлид хочет, чтобы ревью было быстрым и качественным.

Что же можно сделать в каждой из трех ролей, чтобы все остались довольны (и целы)?