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

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

Но все уже осознали, ведь жить с этим как-то надо. А Java программисты даже неплохо живут. Потому что в Java есть модель памяти — Java Memory Model (JMM), которая предоставляет достаточно простые правила для написания корректного многопоточного кода.

И правил этих достаточно для большинства программ. Если вы их не знаете, но пишите или хотите писать многопоточные программы на Java, то лучше как можно скорее ознакомиться с ними. А если знаете, но вам не хватает контекста или интересно узнать откуда растут ноги у JMM, тогда статья может вам помочь.

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

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

Что же делать? Как работать с Игнатом? Добро пожаловать под кат!

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

Для минимизации ручного труда мы решили воспользоваться одним из инструментов трассировки. О том, как и для чего можно использовать трассировку и как это делали мы, и пойдет речь в этой статье.

Какая главная проблема в разработке программного обеспечения (а может и вообще в любой работе)? Когда я задавал вопрос коллегам, получал разные ответы: изменения требований, несоответствия ожиданий, качество кода, взаимодействие с другими командами… суммируя для себя — коммуникация является одной из самых важных проблем.

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

Пытаясь решать эту проблему, люди пишут детальное ТЗ. Но решает ли это проблему? Те же вопросы, как мне видится, задавали Боб Мартин и Мартин Фаулер вместе со своими коллегами, когда писали Agile Manifest в феврале 2001 года. Попробуем разобраться вместе в этом вопросе, да и в самом Agile манифесте.

Все, кто хоть немного знаком со Scrum, наверняка знают три его коротких характеристики:

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

Работая Scrum Мастером в Hubber, я постоянно открываю для себя новые грани последней характеристики.

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

На конференции Joker 2018 я рассказал, с какими проблемами столкнулся сам при переходе к Spring Boot 2 и как они решаются. А теперь специально для Хабра — текстовая версия этого доклада. Для удобства в посте есть и видеозапись, и оглавление: можно не читать всё целиком, а перейти непосредственно к волнующей вас проблеме.

В декабре 2013 года я удалил свой аккаунт LinkedIn. Как я повторял в эмоциональном посте на Facebook, выяснилось, что я рассылаю друзьям назойливые письма «Дэн Шлоссер пригласил вас присоединиться к LinkedIn». Смущённый, я потратил несколько часов, копаясь в настройках и меню LinkedIn в поисках причины.


Оказалось, что во время регистрации аккаунта несколько лет назад LinkedIn хитростью заставил меня импортировать адресную книгу. Если бы они использовали её содержимое только для предложения контактов на LinkedIn, может, я бы не возражал, но они пошли дальше. На странице «Люди, которых вы можете знать» LinkedIn вставил несколько кнопок для приглашения контактов из адресной книги на LinkedIn и сделал эти кнопки в таком стиле, как будто эти люди уже на LinkedIn и я могу связаться с ними. Отличие между этими двумя видами кнопок было ничтожным. В результате я отправлял эти спамерские письма, думая что отправляю запрос на добавление в друзья внутри социальной сети.

Гибкость — без сомнения хорошая вещь, и в манифесте Agile есть смысл. По сравнению с хрупкой практикой под названием «водопад», Agile заметно лучше. Тем не менее, на практике гибкие подходы часто наносят глубокий вред, и в действительности вряд ли здесь уместна дихотомия Agile/Waterfall.

Я видел, как множество вариантов Agile, называемых Scrum, реально убивают компанию. Под «убивают» я имею в виду не «ухудшение культуры», а скорее когда акции компании падают почти на 90% за два года.

Что такое Agile?

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

В последнем посте я рассказывал о Kubernetes, о том, как ThoughtSpot использует его для собственных нужд по поддержке разработки. Сегодня хотелось бы продолжить разговор о короткой, но от того не менее интересной истории отладки, которая произошла совсем недавно. Статья базируется на том, что containerization != virtualization. К тому же наглядно показывается, как контейнеризированные процессы конкурируют за ресурсы даже при оптимальных ограничениях по cgroup и высокой производительности машины.

Каким требованиям должно удовлетворять хранилище метаданных для облачного сервиса? Да не самого обычного, а для enterprise с поддержкой географически распределенных датацентров и Active-Active. Очевидно, система должна хорошо масштабироваться, быть отказоустойчивой и хотелось бы, чтобы было возможно реализовать настраиваемую консистентность операций.

Под все эти требования подходит только Cassandra, а ничто другое не подходит. Надо заметить, Cassandra действительно классная, но работа с ней напоминает американские горки.


В докладе на Highload++ 2017 Андрей Смирнов (smira) решил, что о хорошем говорить неинтересно, зато подробно рассказал, про каждую проблему, с которой пришлось столкнуться: про потерю и порчу данных, про зомби и потерю производительности. Эти истории и вправду напоминают катание на горках, но на все проблемы находится решение, за которым добро пожаловать под кат.

О спикере: Андрей Смирнов работает в компании Virtustream, реализующей облачное хранилище для enterprise. Идея состоит в том, что условно Amazon делает облако для всех, а Virtustream делает специфические вещи, которые необходимы большой компании.

Или как сэкономить 15% и более от бюджета на разработку

Я профессионально работаю с Unreal Engine уже более 9 лет. За это время я освоил множество специальностей и занимал разные должности в разработке игр: от разработчика-«пехотинца» до менеджера больших команд разработчиков игр и даже консультировал инвесторов игровых компаний.

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

Если у игровой компании в Лос-Анджелесе появляется проблема с Unreal Engine 4, которую никто не может решить, в конце концов звонят мне. Я пишу эту статью, чтобы объяснить, почему мне звонят, как избежать необходимости таких звонков, и что я обычно делаю, получив такой звонок.

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

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

Вы можете удивиться: зачем же разработчику ПО думать о механизме кэширования в CPU? Отвечу. С одной стороны, многие понятия из концепции когерентности кэша непосредственно применимы в распределённых системах и на уровнях изоляции СУБД. Например, представление реализации когерентности в аппаратных кэшах помогает лучше понять разницу в моделях согласованности (консистентности) — отличие строгой согласованности (strong consistency) от согласованности в конечном счёте (eventual consistency). У вас могут появиться новые идеи, как лучше обеспечить согласованность в распределённых системах, используя исследования и принципы из аппаратного обеспечения.

С другой стороны, неправильные представления о кэшах часто приводят к ложным утверждениям, особенно когда речь идёт о параллелизме и состоянии гонки. Например, часто говорят о трудности параллельного программирования, потому что «у разных ядер в кэшах могут быть разные/устаревшие значения». Или что квалификатор volatile в языках вроде Java нужен, чтобы «предотвратить локальное кэширование общих данных» и принудительно «читать/записывать только в основную память».

Многие боятся публичных выступлений. Говорят даже, что страх публичных выступлений – самый сильный страх человека. Наверное, они никогда не пробовали уволить человека. Для любого начинающего руководителя, да и для многих опытных, это то еще испытание.

Давайте разбираться, почему иногда приходится расставаться с сотрудниками и как провести это расставание максимально сглажено для обоих сторон.

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

Реляционные базы данных (РБД) используются повсюду. Они бывают самых разных видов, от маленьких и полезных SQLite до мощных Teradata. Но в то же время существует очень немного статей, объясняющих принцип действия и устройство реляционных баз данных. Да и те, что есть — довольно поверхностные, без особых подробностей. Зато по более «модным» направлениям (большие данные, NoSQL или JS) написано гораздо больше статей, причём куда более глубоких. Вероятно, такая ситуация сложилась из-за того, что реляционные БД — вещь «старая» и слишком скучная, чтобы разбирать её вне университетских программ, исследовательских работ и книг.

На самом деле, мало кто действительно понимает, как работают реляционные БД. А многие разработчики очень не любят, когда они чего-то не понимают. Если реляционные БД используют порядка 40 лет, значит тому есть причина. РБД — штука очень интересная, поскольку в ее основе лежат полезные и широко используемые понятия. Если вы хотели бы разобраться в том, как работают РБД, то эта статья для вас.

SPF (Sender Policy Framework), полное название можно перевести как «Основы политики отправителя для авторизации использования домена в Email» — протокол, посредством которого домен электронной почты может указать, какие хосты Интернет авторизованы использовать этот домен в командах SMTP HELO и MAIL FROM. Публикация политики SPF не требует никакого дополнительного софта и поэтому чрезвычайно проста: достаточно добавить в зону DNS запись типа TXT, содержащую политику, пример записи есть в конце статьи. Для работы с SPF есть многочисленные мануалы и даже онлайн-конструкторы.

Первая версия стандарта SPF принята более 10 лет назад. За это время были созданы многочисленные реализации, выработаны практики применения и появилась свежая версия стандарта. Но самое удивительное, что почему-то именно SPF, более чем любой другой стандарт, оброс за 10 лет невероятным количеством мифов и заблуждений, которые кочуют из статьи в статью и с завидной регулярностью выскакивают в обсуждениях и ответах на вопросы на форумах. А протокол, казалось бы, такой простой: внедрение занимает всего пару минут. Давайте попробуем вспомнить и разобрать наиболее частые заблуждения.

TL;DR — рекомендации в конце.

В первой части рассказа я утверждал, что основной причиной деградации культуры в компаниях является найм, удержание и продвижение «редисок» (наемных работников, чей недостаток эмпатии вызывает межличностные конфликты). В качестве системного решения этой проблемы я показал матрицу «Производительность-Ценности». Давайте посмотрим глубже и постараемся понять причины поведения редисок, и то, насколько крупные компании могут справится с ним без больших потерь.

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

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

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

Автор: Эдвард Гори

Синдром хронической усталости (СХУ) — снижение жизненного тонуса в организме и значительное нервное истощение. СХУ характеризуется десятками симптомов, но многие из них связаны и с другими нарушениями.

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

На конференции HighLoad++ 2016 руководитель разработки «М-Тех» Вадим Мадисон рассказал о росте от системы, для которой сотня микросервисов казалась огромным числом, до нагруженного проекта, где пара тысяч микросервисов — обыденность.

Тема моего доклада — то, как мы запускали в продакшн микросервисы на достаточно нагруженном проекте. Это некий агрегированный опыт, но поскольку я работаю в компании «M-Tех», то давайте я пару слов расскажу о том, кто мы.

Если коротко, то мы занимаемся видеоотдачей — отдаём видео в реальном времени. Мы являемся видеоплатформой для «НТВ-Плюс» и «Матч ТВ». Это 300 тысяч одновременных пользователей, которые прибегают за 5 минут. Это 300 терабайт контента, который мы отдаем в час. Это такая интересная задача. Как это всё обслужить?

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

Роман Гребенников объясняет сложность построения распределённых систем. Это — доклад Highload++ 2016.

Всем привет, меня зовут Гребенников Роман. Я работаю в компании Findify. Мы делаем поиск для онлайн-магазинов. Но разговор не об этом. В компании Findify я занимаюсь распределенными системами.

Что же такое распределённые системы?