Морис Херлихи — обладатель целых двух премий Дейкстры. Первая — за работу по «Wait-Free Synchronization» (Brown University) и вторая, более свежая, — «Transactional Memory: Architectural Support for Lock-Free Data Structures» (Virginia Tech University). Премию Дейкстры дают за работы, значимость и влияние которых были заметны на протяжении не менее десяти лет и, очевидно, Морис — один из самых известных специалистов в области. На данный момент он работает профессором в Брауновском университете и имеет множество достижений на целый абзац длиной. Сейчас он занимается исследованиями блокчейна в контексте классических распределенных вычислений.

Ранее Морис уже приезжал в Россию на SPTCC (видеозапись) и cделал отличную встречу сообщества Java-разработчиков JUG.ru в Питере (видеозапись).

Этот хабрапост  — большое интервью с Морисом Херлихи. В нем обсуждаются следующие темы:

• Взаимодействие академической сферы и индустрии;
• Фундамент для исследований блокчейна;
• Откуда берутся прорывные идеи. Влияние популярности;
• PhD под руководством Барбары Лисков;
• Мир в ожидании многоядерности;
• Новому миру – новые проблемы. NVM, NUMA и взлом архитектуры;
• Компиляторы против процессоров, RISC vs CISC, shared memory vs message passing;
• Искусство написания хрупкого многопоточного кода;
• Как обучить студентов написанию сложного многопоточного кода;
• Новое издание книги «The Art of Multiprocessor Programming»;
• Как изобреталась транзакционная память;   
• Почему стоит проводить исследования в области распределенных вычислений;
• Остановилось ли развитие алгоритмов, и как жить дальше;
• Работа в Брауновском Университете;
• Разница между исследованиями в университете и внутри корпорации;
• Hydra и SPTDC.

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

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

Мы работаем с большими объемами медиа данных: видео, рендеры, фото, иллюстрации. Чтобы обеспечивать коллективную работу, нам нужен постоянный общий доступ ко всем этим файлам.

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

Мы сравним популярные облачные хранилища для бизнеса: Google Drive, DropBox, Citrix ShareFile и Microsoft OneDrive.

Наши требования к облачному хранилищу:

• Безлимитный объем данных — у нас много данных, в среднем около 10ТБ. Не хочется постоянно думать сколько нужно докупить места в этом месяце и почему вдруг кончилась квота.
• Версионность файлов и логирование — git приучил нас, что все изменения можно видеть и откатить. Поэтому и с файлами должны быть точно так же: любое изменение, удаление должно быть обратимо и легко контролироваться.
• Права доступа — никаких больше общих папок доступных всем. Каждый сотрудник должен иметь свою область видимости.
• Upload без регистрации — клиенты не должны больше искать файлообменники, чтобы прислать нам тяжелый файл. Файлы должны сразу загружаться в наше хранилище без промежуточных сервисов.

Давеча на глаза мне тут попалось аж две статьи из одного корпоративного блога, касающиеся облаков — одна про Kubernetes, а во второй была попытка замера производительности по методике, которая мне показалась сомнительной (спойлер — и не зря).

Про K8s мне тоже есть что сказать, но поговорим про производительность.

Недоверие к результатам было вызвано многими факторами, но основными из них для меня стали следующие: параметров запуска тестов не было, количество итераций не озвучено, как выбирались машины не озвучено, подробной конфигурации тоже не было. Сомнительно, в общем.
В целом, я пользуюсь в основном Google Cloud и AWS (в сумме уже с десяток лет опыта по ним набежало) и с отечественными облачными провайдерам особо не работаю, но, по стечению обстоятельств, у меня есть активные аккаунты в Selectel, MCS, Я.Облаке и, после этого теста, еще и в Azure.

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

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

Результаты получились не сказать чтобы феноменальными, но на мой взгляд крайне любопытными.

Интересующихся прошу под кат.

От переводчика: данный текст даётся с незначительными сокращениями по причине местами излишней «разжёванности» материала. Автор абсолютно справедливо предупреждает, что отдельные темы покажутся чересчур простыми или общеизвестными. Тем не менее, лично мне этот текст помог упорядочить имеющиеся знания по анализу сложности алгоритмов. Надеюсь, что он будет полезен и кому-то ещё.
Из-за большого объёма оригинальной статьи я разбила её на части, которых в общей сложности будет четыре.
Я (как всегда) буду крайне признательна за любые замечания в личку по улучшению качества перевода.

Введение

Многие современные программисты, пишущие классные и широко распространённые программы, имеют крайне смутное представление о теоретической информатике. Это не мешает им оставаться прекрасными творческими специалистами, и мы благодарны за то, что они создают.

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

Каталог:
Один
Два
Три

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

Грамотная работа с памятью!!! За все время использования у меня своп файл не увеличился ни на Килобайт. По этому Фаерфокс с 10-20 окнами сворачивается / разворачивается в/из трея как пуля. Такого эффекта я на винде добивался с отключенным свопом и с переносом tmp файлов на RAM диск.

Или к примеру μTorrent — у меня нет никаких оснований сомневаться в компетентности его авторов, но вот про работу памяти в Windows они со всей очевидностью знают мало. Не забываем и товарищей, производящих софт для слежения за производительностью и не имеющих ни малейшего понятия об управлении памятью в Windows (и поднявших по этому поводу истерику на пол интернета, на Ars-е даже был разбор полетов). Но самое потрясающее, что я видел всвязи с управлением памятью — это совет переместить pagefile на RAM-диск:

Из моих трех гигабайт под RAM disk был выделен один (на тот момент, когда на лаптопе еще была установлена XP), на котором я создал своп на 768МБ ...

Цель данной статьи — не полное описание работы менеджера памяти (не хватит ни места ни опыта), а попытка пролить хоть немного света на темное царство мифов и суеверий, окружающих вопросы управления памятью в Windows.

Всем привет.

Очередная статья от «курсов изучения английского» сподвигла меня написать свои заметки. Этой статьёй я надеюсь ответить на некоторые вопросы изучающих язык и отговорить от глупых советов «запомнить вот эти 10/15/20 слов/конструкций», которые подаются как некие секреты языка.

Сейчас я использую лишь 2 языка: русский и английский, хотя в разное время учил также украинский, немецкий и французский. Английский изучаю с 6 лет и мне повезло с преподавателями (хоть и не со всеми), где-то со старших классов школы имею уровень C1-C2. Хочу поговорить как о планировании в изучении языка, так и о каких-то приёмах.

Товарищи инженеры, как и было обещано в анонсе, половина лекций (а это 51) уже доступны для просмотра на ютюбе и я продолжу их записывать в 2019 году. Часть из нужно будет перезаписать, потому, что в первых лекциях не самый лучший звук и потому, что очень простые темы у меня пока не очень хорошо получаются. Лучше вышли сложные и актуальные темы, которые мне и самому более интересно рассказывать. Я бы не сказал, что это курс для начинающих, скорее, это курс для тех, кто уже знает синтаксис. За это время поступило множество предложений, как улучшить способ подачи материала: делить на более короткие лекции, подготовить задачи для практического освоения, записывать семинары и ответы на вопросы студентов, добавить в программу разбор целого ряда спорных и холиварных тем. Но не все сразу, я и так посвящаю этому треть жизни.

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

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

Последнее время ко мне часто обращаются начинающие тимлиды и руководители продуктов с вопросами: а что почитать на тему управления? что почитать на тему планирования? что почитать про управление рисками?

Я читал и читаю довольно много книг. Хорошие книги, которые мне понравилось, записываю, чтобы потом порекомендовать. Я решил сделать небольшую подборку must have книг, которые должен прочитать каждый начинающий руководитель. Одно из требований, чтобы эти книги были не только полезными, но и интересными. Книги должны заинтересовать человека развиваться в управлении, ни в коем случае не демотивировать.

Пока подготовка к московскому DotNext идёт полным ходом, мы открыли доступ к видеозаписям докладов с прошедшей летом конференции. По ссылке — полный плейлист, а под катом — топ-5 докладов по отзывам участников. Говоря «топ», мы не имеем в виду наши любимые доклады или выбор каких-то «экспертов» — лучшие отобраны на основе взвешенной оценки от 80% участников конференции. Как думаете, чьё выступление зрители оценили выше — перфоманс-эксперта Саши Гольдштейна или харизматичного Дино Эспозито?

Хабр, привет!

Мы продолжаем приоткрывать дверь в технологическую кухню Retail Rocket. В сегодняшней статье мы решили поделиться историей о нашем «корпоративном backend`е», речь пойдет о рабочем месте для разработчика. Та самая зона комфорта, которая окружает нас в жизни, но является не менее важной, чем выбор стека технологий.

Передо мной встала задача подготовить рабочее место для нового члена команды разработки, казалось бы, что может быть проще? На практике оказалось все гораздо сложнее, чем я ожидал. Раньше мы покупали стол «Галант» в IKEA, любое офисное кресло + MacBook Pro – и у нас готово новое рабочее место.


Старое рабочее место .NET разработчика в офисе Retail Rocket

С тех пор прошло 2 года, мы выросли, у нас изменился стиль работы — пора подбирать новую конфигурацию. Половина нашей команды работает на технологическом стеке от Microsoft. Это большой проект в Visual Studio 2015 + Resharper: 26 приложений, 9 библиотек, 3 проекта с тестами, что в сумме на момент публикации статьи дает 4 312 файлов и более 60 тыс. строк кода. Плюс IIS с компиляцией и запуском приложения на локальной машине, что накладывает повышенные требования к вычислительной мощности используемого оборудования.

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

У нас сотни программных проектов на поддержке, некоторые из них поддерживаются нами почти десять лет. Нетрудно догадаться, что понятие maintainable кода (переведу это понятие как код, легкий в поддержке) является у нас одним из основных. По счастливому стечению обстоятельств легкий в поддержке код также является и легким для (unit-)тестирования, легким для освоения новыми членами команды и т.д. Скорее всего, это связано с тем, что для создания maintainable кода приходится озаботиться хорошей архитектурой проекта и завести несколько хороших привычек.
В этой статье и поговорим о таких привычках, благодаря которым часто хорошая архитектура получается сама собой. Постараюсь также иллюстрировать все хорошими примерами.

Другие статьи цикла:
Хроники лаборатории: как мы молотый кофе считали софтом для анализа клеточных структур
Компот из кофейных сухофруктов. Знакомимся с каскарой — лучшим другом велосипедиста

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

На Хабре/Гиктаймсе уже не раз обсуждался кофе и все, что с ним связано. Я решил написать пост, посвященный этому напитку и различным эффектам кофеина с медицинской точки зрения. Если хватит времени — возможно это будет цикл статей с экспериментами над людьми, computer vision и прочим непотребством. Увидим. А пока, товарищи кофеиноманы и им сочувствующие, добро пожаловать под кат.

Peter Welch
30 апреля 2014 г.
Об авторе. Peter Welch писатель и программист, автор книги «And Then I Thought I Was a Fish», автор блога «Still Drinking».


Изображение: Joe Raedle/Getty Images

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

Они правы. Мордор — отстой, и копание тоннеля гораздо трудозатратнее, чем тыкание в клавиши, если конечно вы не муравей. Но для галочки, давайте договоримся о том, что стресс и безумие — это плохо? Отлично.

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

Ритм вашего сердца учащается, когда вы проверяете свой банковский счет в день начисления зарплаты: вы вполне уверены, что обнаружите стандартную сумму, которую вам обычно выплачивают… но в конце этого числа оказывается еще один ноль! Постойте-ка, что!?! Сработало, теперь вы богаты! Или скоро станете таковым, если эта схема добычи легких денег будет действовать и дальше. Как же долго это поле ввода находилось на сайте?

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

После небольшого разговора о том, как вы провели выходные, она собирается уходить, но потом оборачивается и говорит: «О, кстати, я только что внесла в твой календарь встречу, чтобы чуть позже сегодня обсудить твое недавнее увеличение зарплаты. Пожалуйста, подготовь доказательства того, что новый уровень твоей ставки соответствует актуальным показателям на рынке». Тут вы начинаете убеждаться в реальности происходящего.

Институт развития интернета предлагает внести в строительные нормы и правила (СНиПы) требование к новостройкам, по которому дом не смогут ввести в эксплуатацию без оптоволоконных кабелей для подключения каждой квартиры к сети, сообщают «Известия».

Технологии хранения данных — отдельная тема. Не так давно мы косвенно затрагивали ее в нашем материале об управления дисковым пространством сервера.

Сегодня мы поговорим о том, как команда поискового сервиса Algolia пыталась решить внезапно возникшую проблему с SSD-дисками.

Всем привет!

Две недели назад в Москве прошла очередная встреча CodeFreeze. Нашим гостем стал Евгений Кривошеев, признанный российский эксперт в области архитектуры программных систем, консультант из Scrumtrek/Skilltrek. Евгений прочитал офигеннейшую лекцию по архитектуре, как он любит и умеет.



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

• Точки зрения на систему, или Почему мы слепнем при проектировании
• Адресация ключевых рисков, или Гордыня убивает
• Учитываем контекст, или Как не долбиться в закрытую дверь

В предыдущей части были рассмотрены основы уровней изоляции транзакций. Здесь я постараюсь копнуть чуть глубже и рассказать при помощи каких инструментов MS SQL Server реализует уровни изоляции.

Как вы могли видеть в предыдущем разделе, существует два способа поддержания изоляции:

• Основанный на блокировке ресурсов
• Основанный на создании версионной копии ресурсов.

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

Мне часто приходилось сталкиваться с тем, что люди прекрасно понимают, что такое транзакции в базе данных и для чего они нужны, но при этом не всегда умеют ими правильно пользоваться. Безусловно, для достижения 80-го уровня сакрального знания нужно иметь не один год опыта и прочесть множество толстенных книг по SQL. Поэтому в этой статье я даже не буду пытаться описать всё, что может быть связано с транзакциями в MS SQL. Я хочу затронуть один простой, но очень важный вопрос, который разработчики часто упускают из вида – уровни изоляции транзакций.
Несмотря на то, что тема очень проста, во многих источниках она освящается плохо – информации либо очень мало, либо очень много. Т.е. прочитав 5-6 кратких теоретических определений невозможно их применить на практике. Для уверенного понимания предмета статьи нужно обращаться к специализированной литературе, но там информации на столько много, что далеко не каждый может уделить необходимое время для её усваивания.
Сегодня я хочу поделиться своим простым рецептом, который помог мне раз и на всегда запомнить особенности уровней изоляции транзакций и по сей день помогает без проблем принимать взвешенные решения о выборе необходимого уровня.