С развитием научных методов и инструментария учёные получают возможность точнее определить возраст нашей галактики и получить больше данных для понимания того, как она развивалась. В этом им помогает анализ таких небесных объектов, как глобулярные (шаровые) кластеры. Ниже я хотел бы рассказать немного подробнее об этих объектах и о том, к каким выводам пришли астрономы на текущий день.
23 сентября этого года лучшие программисты страны сразятся друг с другом в финальном раунде российского чемпионата по спортивному программированию, Russian Code Cup 2013 (RCC). Это будет уже третий финал организованной Mail.Ru Group олимпиады, призванной не только поддержать престиж российских программистов в мире, но и популяризировать программирование как таковое.
В преддверии третьего финала мы решили взять интервью у спикеров RCC 2013 — Дмитрия Склярова, Эдварда Йордона и Кена Голдберга. Но сначала давайте вспомним об основателях языков программирования, благодаря которым сегодняшнее программное обеспечение является именно таким, каким мы его знаем.
Обеспечение устойчивости к сбоям — задача нетривиальная. Для нее нет стандартного решения. Есть некие общие паттерны, компоненты. Но даже в рамках одной организации для обеспечения фолт-толерантности разных узлов применяются разные решения. Что уж говорить о сравнении подходов в разных организациях.
Кто-то оставляет проблему на «авось», кто-то вешает баннер на «пятисотку» и пытается зарабатывать на сбоях деньги. Кто-то пользуется стандартными решениями от поставщиков баз данных или сетевых устройств. А кто-то уходит в модные нынче «облака».
Ясно одно — по мере роста бизнеса обеспечение устойчивости к сбоям (даже не процедур восстановления после сбоев) становится всё более острой проблемой. От количества аварий в год начинает зависеть репутация компании, при больших временах простоя становится неудобно пользоваться сервисом, и т.д. Причин много.
В этой статье мы рассмотрим один из наших способов обеспечения устойчивости к сбоям. Под устойчивостью будем понимать сохранение работоспособности системы при выходе из строя как можно большего количества узлов этой самой системы.
Не знаю, как для вас, а для меня этот праздник был всегда каким-то несерьёзным. Возможно, это потому, что уважения к календарным праздникам у меня всю жизнь было мало. Они обезличивают событие, делают его каким-то общим (т.е. ничьим), и в остатке получаются лишь формальные поздравления (штампованные и приевшиеся) и выходной день (если, к примеру, это 23 февраля или подобные праздники).
Мы, программисты, чаще всего интроверты, потому что такой склад характера позволяет сконцентрироваться на интересной задаче, укрывшись в своём «пузыре» от внешних раздражителей.
Читать полностью »
Для сборки проекта, запуска тестов и проверки качества кода мы (в проекте «Календарь Mail.ru») используем Jenkins CI. Запуск сборки происходит сразу же после пуша в репозиторий git (по хуку) и, конечно же, хочется своевременно получать информацию о провалившихся сборках. С одной стороны, уведомления по email вроде бы достаточно, с другой стороны хочется чего-то более заметного и весёлого.
Читать полностью »
Тестирование интерфейса в юзабилити-лаборатори
Я уверен, каждый из вас проходил этап от «мне фича нравится — значит, нравится всем» до «если конверсия по графикам растет, значит, фича нужная». Поэтому «как побороть в себе слепое» я рассказывать не буду. А поделиться хочу нижеописанным опытом.
В прошлом году я открыл для себя прекрасный канал бесценной информации — прямое общение с пользователем. Именно прямое, а не через письма обратной связи и, тем более, графики.
Выкатываю я новый функционал. Смотрю на графики: все хорошо, я прихожу на исследование довольный (кстати, у нас отличная лаборатория). Пользователь говорит: «Вы тут недавно новое добавили, мне не нравится, хочу отключить».
Читать полностью »
В начале 2012 года в Mail.Ru Group было реорганизовано e-commerce-направление, и перед нами встала задача провести обновление всех сервисов. В рамках обновления интерфейсы всех проектов были приведены к единому знаменателю. В этом посте я расскажу о том, что на практике дает унификация, и какими методами можно свести к минимуму затраты при работе с масштабными проектами.
В направление электронной коммерции Mail.Ru Group входят Товары, Деньги, Недвижимость и Путешествия. Кроме них, в течение года мы работали над новыми продуктами — спутниками основных сервисов. Итогом стало появление новых проектов Авиабилеты, Финансы и Ремонт.
Нашей основной задачей было создать в сжатые сроки базовый интерфейс, который позднее можно и нужно будет совершенствовать и масштабировать.
Хочу поделиться опытом изучения Tarantool. Про все преимущества и особенности самого Тарантула я писать не буду, на эту тему было много статей (например, эта, эта и эта). Этот пост рассказывает о том, как начать работать с тарантулом и про некоторые особенности и вкусности которые можно получить из коробки.
Читать полностью »
Как часто друзья и родственники, не связанные с IT, просили вас рассказать, что нового на работе, а вы, увлекаясь, начинали говорить вроде на русском, но совершенно непонятном для них языке? Мы создали наш словарь терминов, в который вошли как внутренний сленг отдельных проектов, так и достояние широкой общественности. Надеемся, эта компиляция поможет айтишникам при необходимости выразить свои мысли на языке маглов, а неайтишникам – понять, что айтишники несут. Ну и просто повеселит всех. Ведь пятница!
Код добра – программный код, очевидно содержащий непоправимые улучшения.
Котятоемкий код — очень некрасивое техническое решение. Выражение обязано своим происхождением предположению, что каждый раз, когда программист пишет строчку некрасивого кода, бог убивает котенка.
Непоправимо улучшить – запилить годное, но не до конца проверенное изменение функционала. Синоним — необратимо улучшить.
Мясной коммит (ковровый коммит) – правка, судя по количеству и характеру изменений, наверняка содержащая непоправимые улучшения.
Тупач – очень срочная задача, результаты работ по которой должны попасть в бранч для выкатываемой версии. Образовано от to patch.
Минорный тупач – задача горит – сильнее некуда, но уж очень мелкая.
Глубокий ToDo Later — (отправить задачу в глубокий тудулейтер) статус задачи в таск-трекере отложена на неопределенный срок.
Подпереть костылями – реализовать функциональность за счет непредусмотренного временного решения.
Шрапнельные правки – огромное количество мелких правок по всему проекту, которые очень сложно оттестировать.
Скриптюня — очень классный скрипт, экономит кучу времени, практически лучший друг оператора.
Читать полностью »
Изначально в нашем IMAP-сервере использовался epoll-реактор собственной разработки. Как всегда, в процессе эксплуатации и роста нагрузки потихоньку набегают замечания, в результате чего со временем начинает накапливаться технический долг и замедляться разработка.
В нашем случае были также изначальные архитектурные замечания.
Лирическое отступление про IProto: протокол очень простой: заголовок из трёх полей типа uint32_t: команда, номер пакета, длинна данных. За счет поля «номер пакета» сервер может отвечать на запросы в любом порядке, а клиент может ждать ответа в асинхронном стиле и слать следующий запрос. В Mail.Ru Group он используется повсеместно — начиная с нашей Tarantool, и заканчивая сервисом антибрутфорса.
Поэтому было решено сделать тестовую версию, используя boost::asio. В этом посте я расскажу о переезде на реактор boost::asio, о его преимуществах и о подводных камнях, с которыми мы столкнулись.
