Физика движения локомотива такая: чем он мощнее, тем лучше он трётся о рельс и больше тянет. При этом чем больше вам нужно тянуть, тем тяжелее должен быть локомотив, чтобы не проскальзывать по рельсу. А чем тяжелее он будет, тем больше шансов повредить рельс. В итоге примерно к 2000-м годам вся эта система достигла равновесия: более-менее устаканились ТТХ отечественных локомотивов с учётом ширины колеи и допустимого износа пути.



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

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

Давайте покажу завод «Уральские локомотивы» — но не ту часть, где прекрасные Ласточки, а ту, где самый хардкор.

Я хотела бы начать этот пост очень пафосно. Например, так: «Я работаю в бизнесе уже 10 лет, получила железное сердце и обросла панцирем». Или так: «Да-да, Хабр, я работник коммерческой службы: когда-то аналитик, потом продажник, потом маркетолог. Я тот самый, кого вы все не любите». В конце концов, именно так должен выглядеть пост первого января. Но нет. Никакого пафоса и романтики. Работаю в коммерции ИТ-компаний некруглые 11,5 лет. Была всем: разработчиком, проджектом, маркетологом, продажником, внедренцем, редактором, ИТ-консультантом. До этого была на госслужбе и преподавала. И я сегодня, несмотря на сто доводов против, могу сказать: «Бизнес, я люблю тебя!» Ну понятно, что развитие этой мысли под катом.

Сложно представить человека, у которого перед выходом на сцену не дрожали бы коленки. Особенно, если ТАМ ждут 100 (200) человек, а за плечами у вас только выступление на школьном утреннике.

Но есть несколько проверенных советов, как бороться со страхом перед выступлениями, которыми и хочу поделиться в статье.

В Яндекс.Деньгах хранится масса важной для комфортной работы пользователя информации. Настройки профилей и подписки на штрафы тоже нужно бэкапить, чем и занимается у нас связка из Barman Backup & Recovery for PostgreSQL и pg_receivexlog.

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

Так как базы данных Яндекс.Денег вынуждены хранить массу второстепенной и временной информации, однажды такое решение перестало быть оптимальным. Поэтому в инфраструктуре появился распределенный Data Grid с функциями in-memory базы данных на базе Hazelcast.

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

В этом материале я продолжаю делиться полевым опытом работы с системой сбора логов на базе Heka и ElasticSearch.

На этот раз рассказ пойдет про миграцию данных между двумя кластерами ElasticSearch 2.2 и 5.2.2, которая стоила немалых нервов лично мне. Как-никак, предстояло перевезти 24 миллиарда записей, не сломав уже работающую систему.

Прошлая статья закончилась на том, что система работает, логи поступают и складываются в кластер ElasticSearch, доступен их просмотр в реальном времени через Kibana. Но кластер изначально был собран со значительным запасом по памяти как раз на вырост.

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

Рассказывать о долгом и тернистом пути всегда непросто. Однако за последние годы инфраструктура разработки Яндекс.Денег сделала большой шаг в сторону автоматизации самого важного для нас процесса — релиза, о чем просто грех не рассказать. Фактически получилось полноценное решение Continuous Integration и Continuous Delivery на базе связки Bitbucket, Jenkins и Jira.

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

Система построена на базе стека EHK (Elasticsearch/Heka/Kibana), с прицелом на работу практически в реальном времени. Особый упор сделаю на тонкие места и нюансы обработки миллиардов строк текста в сутки.

К сожалению, у меня нет опыта работы с микросервисами, но около года назад я очень активно интересовался этой темой и изучил все источники информации, какие смог найти. Я просмотрел несколько выступлений на конференциях, прочитал несколько статей очень авторитетных и опытных специалистов вроде Мартина Фаулера, Фреда Джорджа, Эдриана Кокрофта и Криса Ричардсона, чтобы как можно больше узнать о микросервисах. Эта статья — результат моих изысканий.

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

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

— Мы делаем систему управления электронным обучением…

— Мы провели исследование поведения посетителей на нашем сайте…

— Наша компания была основана более ста лет назад…

Это просто удивительно как люди любят так поступать. Они с первых секунд садятся на уши аудитории рассказом про себя:

— Мы предлагаем SAAS-решение…

— Наши технологии…

И мое любимое:

— Начну рассказ с того, кто мы такие…

Почему все так уверены, что именно это в первую очередь интересует слушателей? Единственное что выступающий гарантированно получит в таком выступлении — это претензии к себе лично и своей компании.

Я видел как один из директоров Microsoft схлопотал громкое улюлюканье, а представитель Ростелекома — едкий троллинг из зала только потому, что выступили по этому шаблону.

Почему каждый раз это происходит?

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

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

С какими проблемами я столкнулся при портировании?

Дочитал на днях сабжевую книжку. Вышла она еще в 2008 году (а предыдущее издание и того раньше), но мне она попалась только недавно. По идее, читать ее надо было бы после книги Фаулера «Рефакторинг. Улучшение существующего кода», на которую Кириевски постоянно ссылается, но до Фаулера я пока не добрался, хотя это и не особо затруднило чтение. Вторая книга, которую лучше всего прочитать заранее, это «Приемы объектно-ориентированного проектирования. Паттерны проектирования» банды четырех.

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

Кликабельно. Картинка не моя, вот оригинал.

Периодически появляются сайты, где дизайнеры оставили easter eggs (пасхальные яйца) — приколы, которые видны при определенном стечении событий, ну например по клику мышки в определенном месте.
Интересную подборку таких сайтов смотрите под катом.

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

Публикую пост от имени gibbzy:

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

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

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

Паттерны проектирования

Википедия — там, в принципе, на хорошем уровне все описано и приведены примеры на разных языках.
Базовая книга – классика:
«Приемы объектно-ориентированного проектирования. Паттерны проектирования» — читал книгу давно, и раза 3. Вам того же советую. Даст возможность понимать большое количество терминов, произносимых другими разработчиками.

Рефакторинг

«Рефакторинг. Улучшение существующего кода» — вероятно, эта книга сделала революцию в написании кода. Читается быстро и интересно. Методы рефакторинга должны отложиться в голове до конца жизни. Ваш код отныне будет лучше. В книге есть упоминание про юнит тестинг.

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

Вот исходный вопрос:

Как используется ключевое слово yield в Python? Что оно делает?

Например, я пытаюсь понять этот код (**):

def _get_child_candidates(self, distance, min_dist, max_dist):
    if self._leftchild and distance - max_dist < self._median:
        yield self._leftchild
    if self._rightchild and distance + max_dist >= self._median:
        yield self._rightchild

Вызывается он так:

result, candidates = list(), [self]
while candidates:
    node = candidates.pop()
    distance = node._get_dist(obj)
    if distance <= max_dist and distance >= min_dist:
        result.extend(node._values)
        candidates.extend(node._get_child_candidates(distance, min_dist, max_dist))
        return result

Что происходит при вызове метода _get_child_candidates? Возвращается список, какой-то элемент? Вызывается ли он снова? Когда последующие вызовы прекращаются?

** Код принадлежит Jochen Schulz (jrschulz), который написал отличную Python-библиотеку для метрических пространств. Вот ссылка на исходники: http://well-adjusted.de/~jrschulz/mspace/