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

Вступительное слово

Считается, что «киллер фичей» СКВ Git является легковесное ветвление. Я ощутил это преимущество в полной мере, ведь я перешел на Git с SVN, где ветвление было достаточно дорогим процессом: для создания ветки нужно было скопировать весь рабочий каталог. В Git все проще: создание ветки подразумевает лишь создание нового указателя на определенный коммит в папке .git/refs/heads, который является файлом с 40 байтами текста, хешем коммита.

Основными командами пользовательского уровня для ветвления в Git являются git-branch, git-checkout, git-rebase, git-log и, конечно же, git-merge. Для себя я считаю git-merge зоной наибольшей ответственности, точкой огромной магической энергии и больших возможностей. Но это достаточно сложная команда, и даже достаточно длительный опыт работы с Git порой бывает недостаточным для освоение всех ее тонкостей и умения применить ее наиболее эффективно в какой-либо нестандартной ситуации.

Попробуем же разобраться в тонкостях git-merge и приручить эту великую магию.

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

Чтобы понять, как все это работает, давайте начнем с показателей Stack Overflow. Итак, ниже приводится статистика за 12 ноября 2013 и 9 февраля 2016 года:


Вы можете спросить, почему существенно сократилась продолжительность обработки в ASP.Net по сравнению с 2013 годом (когда было 757 часов) несмотря на прибавление 61 миллиона запросов в день. Это произошло как и из-за модернизации оборудования в начале 2015 года, так и из-за некоторого изменения параметров в самих приложениях. Пожалуйста, не забывайте, что производительность – это наша отличительная особенность. Если Вы хотите, чтобы я более подробно рассказал о характеристиках оборудования – без проблем. В следующем посте будут подробные спецификации железа всех серверов, которые обеспечивают работу сайта.

Итак, что изменилось за прошедшие 2 года? Кроме замены некоторых серверов и сетевого оборудования, не очень многое. Вот укрупненный список хардварной части, которая обеспечивает работу ресурса (выделены различия по сравнению с 2013 годом):

• 4 Microsoft SQL Servers (новое железо для 2-х из них);
• 11 Web-серверов IIS (новое оборудование);
• 2 сервера Redis (новое оборудование);
• 3 сервера Tag Engine (новое оборудование для 2-х из 3-х);
• 3 сервера Elasticsearch (те же, старые);
• 4 балансировщика нагрузки HAProxy (добавлено 2 для поддержки CloudFlare);
• 2 брандмауэра Fortinet 800C (вместо Cisco 5525-X ASAs);
• 2 маршрутизатора Cisco ASR-1001 (вместо маршрутизаторов Cisco 3945);
• 2 маршрутизатора Cisco ASR-1001-x (новые!).

Что нам необходимо, чтобы запустить Stack Overflow? Этот процесс не сильно изменился с 2013 года, но из-за оптимизации и нового железа, нам необходим только один web-сервер. Мы этого не хотели, но несколько раз успешно проверили. Вношу ясность: я заявляю, что это работает. Я не утверждаю, что это (запуск SO на единственном web-сервере) — хорошая затея, хотя каждый раз выглядит весьма забавно.

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

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

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

Итак…

Кому

• Тем кто на Ruby on Rails
• Кто желает знать кто из пользователей онлайн, но ещё не задумывался как
• Для кого не проблема использовать Redis (по причине хостинга например)

    Решение вопроса в сети пользователь или нет — это наверное как правило установка временной метки при обращении пользователя к приложению, а при необходимости узнать его (пользователя) текущий статус — сверка с этой временной меткой. Какой подход выбрать — решать Вам, но тот подход который предлагаю я — прост и не использует SQL базу данных, вместо этого используется Redis и одна из его встроенных возможностей — время жизни ключа (expire).

Здравствуй, Хабрахабр! Недавно у меня возникла необходимость развернуть свое Rails web-приложение на Heroku и я, к своему удивлению, не нашел почти ничего об этом на просторах не только Хабра, но и рунета в целом, поэтому я решил поделиться с вами своим опытом. Подробности о том, что и как я делал находятся под катом!

Доброго времени суток, user.

Не так давно у меня возникла задача сделать прототип для одного проекта. В него входила работа с Facebook Graph API. Поковыряв некоторые гемы, я понял, что они для меня не совсем удобные или же реализуют нужный функционал уж слишком сложно. И тут в моей голове всплыла старая идея о написании своего гема. Загуглив массу запросов по этой теме, не нашел полной информации, тем более на русскоязычных ресурсах. Вот так и возникла идея этой статьи. Руководство названо «почти полным», так как тут освещены не все аспекты, а лишь те, которые минимально необходимы и желательны для начала существования продукта вашего воображения. Прошу под кат!

Всем привет! По моему мнению, каждый программист должен стремиться к автоматизации и оптимизации всего, что движется и еще нет. В этой статье будет рассказано о том, как автоматизировать рабочий процесс Ruby on Rails разработчика с помощью Ruby гема под названием Guard. Эта статья в первую очередь полезна Ruby разработчикам, но может пригодиться и другим.

Что такое Guard?

Хочу рассказать Вам о наболевшем: о работе с AR в целом и с Relation в частности; предостеречь от стандартных садовых изделий, которые легко могут испортить жизнь и сделать код медленным и прожорливым. Повествование будет основываться на Rails 3.2 и ActiveRecord того же разлива. В Rails 4, конечно же, много чего нового и полезного, но на него ещё перейти нужно, да и фундамент в любом случае один и тот же.

Сей материал, по большей части, предназначен для начинающих, ибо автору очень больно смотреть на извлечение содержимого целых таблиц в память в виде ActiveRecord объектов и на прочие отстрелы конечностей при использовании AR. Разработчикам, познавшим дзен, топик вряд ли принесёт пользу, они могут лишь Помочь, дополнив его своими примерами и назиданиями.

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

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

Проблема

Было приложение, использующее Ruby on Rails, и стандартный набор гемов (вроде devise). На одной из страниц необходимо было выводить информацию о текущих активных пользователях.

Решение

Первой же мыслью было при каждом запросе записывать в текущего юзера время этого самого запроса и, таким образом, зная таймаут сессии, можно было вычислить, кто активен, а кто нет. Но таймаут стоял порядка 15 минут, поэтому если вкладку просто закрыли — то он все еще будет «активным» на протяжении этого времени. Уменьшать таймаут сессии было нельзя. Да и вариант каждый раз обновлять запись в базе выглядел немного костыльно, учитывая, что одновременных активных юзеров было порядка 2к. Из самых быстрых и простых вариантов — реализация используя вебсокеты + redis.

Faye vs WebsocketRails

tldr; В итоге был выбран faye.

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

Плюсов у websocket-rails я не нашел, зато минусы были очевидные: последнее обновление было довольно давно, на каждое подключение открывался отдельный поток, что потенциально могло заддосить наш и так не очень мощный сервер. Faye в свою очередь работает через event machine и полностью асинхронный, плюс постоянно обновляется.

Думаю многим знакомо понятие «борьба за staging», когда все разработчики одновременно за день до релиза хотят поделиться своими наработками, чтобы тестировщик их проверил как можно скорее и не пришлось всю ночь править баги, да? Кому интересно посмотреть как мы решаем данную проблему для RoR-проектов с помощью Capistrano прошу под кат.

Capistrano — любимый многими rails-разработчиками инструмент, с помощью которого можно быстро и без заморочек автоматизировать развертывание вашего приложения. Capistrano — стандарт де-факто для системы развертывания RoR, must-know технология для любого уважающего себя рубиста, тот инструмент, которому в своё время завидовали разработчики на python и PHP.
Несмотря на комфорт, от которого не хочется отказываться, чем более сложные задачи мне приходилось решать, тем чаще Capistrano показывал себя к ним не приспособленным.

Я отметил следующие недостатки:

• Известные проблемы со скоростью. Вследствие своей универсальности, Capistrano деплоит медленно, выполняя лишние проверки и вызовы, которые вы не всегда можете контролировать.
• Последовательный деплой. Небыстрое время развертывания нужно умножить на количество целевых серверов (однако, можно настроить распараллеливание комманд явным образом).
• Сильная связанность с рельсами. Конфиги и зависимости Capistrano переплетаются с приложением, становясь его частью. Нельзя создать новое окружение-развертывания (например сервера для раннего выкатывания функционала) без создания нового rails-окружения. В сложных ситуациях Capistrano заставляет уходить от хорошей практики держать только development, test и production окружения.
• Плагины — палка о двух концах. Давая возможность быстро “прикрутить” развертывание той или иной зависимости приложения, плагины лишают вас контроля ситуации, заставляют действовать так, как действует разработчик плагина. О влиянии лишних “телодвижений” плагинов на скорость деплоя я написал выше.
• Сложный деплой гетерогенных приложений. Трендом последних лет в рельсах стало выделение самых тяжелых (бекграундных или сетевых) задач в отдельные сервисы, не обязательно написанные на ruby. В такой ситуации capistrano заставляет вас плодить зоопарк из разных систем развертывания для разных языков и технологий.

Многие ruby-разработчики перешли на Mina или решают свои проблемы с помощью ещё более сложных систем управления конфигурациями вроде Chef и Puppet. Все они имеют свои особенности и недостатки и в разной степени решают описанные выше проблемы. Мне же удалось их решить их с помощью Ansible, не растеряв преимуществ Capistrano, к которым я привык.

Ansible это инструмент для управления конфигурациями и в его задачи входит не только описанное в этой статье выполнение удаленных команд на серверах для развертывания и управления отдельным приложением, но и автоматизация серверного администрирования посредством хранимых серверных конфигураций (ролей на языке Ansible). А значит Ansible (как впрочем и Chef и Puppet) позволяет гораздо больше, чем Capistrano и в конечном счете они все не идут с ним ни в какое сравнение. Однако, задача этой статьи дать rails-разработчикам отправную точку для миграции и разъяснить на этом примере основы Ansible. В конце этой статьи, волшебная команда cap production deploy превратится в ansible-playbook deploy.yml -i inventory/production
Кому интересно как — прошу под кат.

В течении последних двух месяцев работал над плагином redmine_intouch для компании Centos-admin.ru.

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

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

Перво-наперво хочу оговориться. Эта статья о реализации логики хранения настроек проекта в плагине для Redmine.

Т.к. это плагин, то использовать сторонние гемы, в которых данный функционал реализован — крайне нежелательно, во избежание конфликтов с логикой самого Redmine.

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



Как видно из скриншота, нужно как-то хранить данные с трёх спойлеров, в каждом из которых по несколько вкладок, а на каждой вкладке масса чекбоксов.

Gulp.js это потоковый сборщик проектов на JS. Он использует Stream и действительно является очень быстрым. Для примера у меня есть проект где около тысячи stylus файлов, GruntJS нужно примерно 2.5 секунды на сборку и 2 секунды на обработку autoprefixer'ом. Gulp все это делает за 0.5 секунды выигрывая у GruntJS минимум в 4 раза.



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

В этой статье будет больше практики, мы соберем среду разработки фронтенда используя Jade и Stylus, запустим локальный сервер и подключим Livereload. Проект я выложил на Github, экспериментируйте.

«Советы основателя» в очередной раз знакомят читателей «Мегамозга» со звёздами IT-рынка, основателями и управляющими собственного бизнеса.

Сергей родился в Нижнем Новгороде в 1978 году, образование: MBA Лондонской школы бизнеса.
Более 10 лет работал в металлургии, управляя европейскими активами ОАО «ТМК», в качестве консультанта McKinsey & Co занимался повышением операционной эффективности предприятий, в том числе – внедрением системы непрерывного совершенствования.

В 2012 году Сергей создал проект Шефмаркет – доставку на дом наборов продуктов с рецептами, клиент лишь выбирает подписку на доставку (ужин, диета или витаминные коктейли) из большого набора в 400 блюд, а доставка работает в Москве, Санкт-Петербурге и Нижнем Новгороде.

На сегодняшний день Шефмаркет доставляет более 6000 заказов в месяц, показывая трёхкратный рост год от года. Выручка компании – более 20 миллионов рублей в месяц.

Вот какими советами Сергей Ашин поделился с аудиторией «Мегамозга».

pro-cras-ti-na-tion |prəˌkrastəˈnāSHən, prō-|
существительное
задержка или откладывание чего-либо: первый совет — избегайте прокрастинации.

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

Избегать прокрастинации. Так элегантно в своей простоте…

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

Нет, «избегайте прокрастинации» — хороший совет только для не настоящих прокрастинаторов. Для тех, кто говорит «Я захожу на Facebook несколько раз в день на работе. Я такой прокрастинатор!». Это те люди, которые будут говорить настоящему прокрастинатору «Не откладывай дела на потом и у тебя все будет хорошо».

Дело в том, что ни словари ни не настоящие прокрастинаторы не понимают, что для настоящих прокрастинаторов прокрастинация — не дополнительная опция. Это что-то, что они не знают как не делать.

Про то, что такое Scrum и с чем его едят написаны миллионы статей. Однако большинство из них предполагают, что до скрама существует некий вакуум, либо наоборот жесткая среда с ведением процессов по PMBOK и др. Множество авторов пишут про «нулевой спринт» в начинающимся проекте, про подбор идеальной команды, про выбор длины спринта, однако в свое время я не нашел большого количества статей про внедрение Agile методологий в существующую среду, в которой до этого не было методологий, но уже были сложившиеся традиции.

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

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