mikhailov's posterous http://railsgeek.com Most recent posts at mikhailov's posterous posterous.com Sun, 12 Feb 2012 08:46:00 -0800 toster Ruby http://railsgeek.com/toster-ruby http://railsgeek.com/toster-ruby

Сразу говорю - ребята, это было круто! Кто не попал на #toster, обязательно посмотрите слайды и видео, когда оно будет доступно. 

Самым интересным для меня были докдады:

- Грегг Поллак "Decyphering Rails 3" 

- Фабиу Акита "Understanding the Rails Web Model and Scalability Options" 

- Джош Калдеримис "Travis CI. Splitting your app into smaller pieces"

- Иван Евтухович "Как мы делали Groupon"

- Джонатан Лейтон "Attributes Unwrapped: Lessons under the surface of active record"

Конференция началась с трехчасового перелета из Омска в Москву вместе с Андреем Дерябиным (Evil Martians), мы классно поговорили и поиграли в какую-то стратегию на iPad. На станции метро мы встретили питерских марсиан, вместе в которыми отправились в Digital October, было холодно, но весело. Все предвещало удивительный день полный хороших впечатлений и новых знакомств. 

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

Я также очень благодарен #toster-у за знакомство с Филиппом из Львова и Алексом Сулим из Краснодара. Ярослав и Нат ответили на некоторые насущные мне вопросы, прямо так сказали как и что. 

Кратко о результатах конференции:
- Техническая подготовка 5/5 (площадка Digital October - самое подходящее место)
- Организационная подготовка 3/5 (отсутствие кофе и наличие бумажной анкеты)
- Подбор докладчиков 5/5 (доклады Фабио, Грегг, Иван и Джонатан нивелировали скукоту по jRuby)
- Аудитория 5/5 (тут были "ну почти все")

Самое главное, зачем я поехал на #toster - это люди, с которыми я не был знаком лично, но знал многое о них. Как результат, заряд энергии на следующие несколько месяцев и неутолимое желание поехать вновь!

Теперь подробно по докладам, что меня зацепило:

- Грегг Поллак, тот самый человек, которые побуждает меня заниматься построением архитектуры и ее поддержанием на хорошем уровне, начиная с изучения теории паттернов масштабирования. Его скринкасты по масштабированию (Rails Scaling Lab) высокого уровня, каждый вопрос разбирается детально и полно. Один из слайдов доклада Грегга говорит о следующем: "Пусть вас не смущает чужой код, не бойтесь писать свой". Он разобрал некоторые моменты о метапрограммировании, как правильно и как неправильно, каждый довод подтвержден детальным профилированием. Но самое яркое впечатление оставил рассказ о паттерне MicroKernel Design, который говорит о модулярности, уменьшения связности и использовании минимального базового класса, подмешивая модули к которому, можно добиться требуемой функциональности. Об этом же писал Иегуда Катз в своих пяти статьях о Rails 3. Насколько мне известно, в ActiveModule этот паттерн также активно используется, когда вы примешиваете только то, что вам нужно без лишнего overhead-а.
Далее Грегг показал, что alias_method_chain иногда целесообразно заменить вызовом базового класса через super, и, на самом деле, код чище и нагляднее в данном конкретном случае
Заключающей частью доклада был замечательный mix-in ActiveSupport::Concern от Joshua Peek. Он очень хорошо описан в одной из статей на хабре в блоге по Ruby On Rails, с ним код выглядит более прозрачно. Если в Вашем приложении многое разбито на модули, то этот mix-in поможет убрать лишний код по переопределению include и class_eval. И снова докладчик напомнил о необходимости чтения кода и добро так намекнул на OSS. 

- Фабиу Акита - один из немногих докладчиков, которые говорят и подтверждают свои мысли цифрами, графиками и пережитом опытом использовании в production. О чем говорил Фабиу: выносите код в бекграунд, используйте паттерны ассинхронного программирования, если вы остро столкнулись с проблемой горизонтального масштабирования. А также типичные для веб-приложений такие инструменты как реверсивный-прокси для снижения нагрузки на стороне сервера и кэширования всего, что имеет смысл кэшировать. Очередь сообщений также является типичной практикой и применяется для масштабирования приложения, размазывая пиковую нагрузку по времени. Паттерн "реактор" (Фабиу просто его объяснил как "a big loop") заслуживает отдельного внимания, так как подходит он далеко не всегда, но является ключевым звеном в распределенной архитектуре, без которого проблему часто решают вертикальным масштабированием (как все знают, это может быть тупиковым путем). Далее докладчик рассказал о недостатках HTTP 1.0/1.1 и необходимости задуматься о переходе на WebSocket (с обязательным fallback для IE), также была затронута тема PubSub паттерна, он отлично ложится на вебсокеты. Самым разумным со стороны Фабиу было предложить "решение для бедных", которые не хотят поддерживать собственную платформу для обеспечения пиковых ситуаций - Pusher.com - очередь сообщений с http трансфером, удобен в использовании и полностью production ready.

Иван Евтухович - этот парень сделал мой день, его сдержанность на сцене и прямота за кулисами показала весь Rework в деле, абсолютно прагматичный подход, абсолютный здравый смысл и просвещенное понимание того, что нужно бизнесу. "Вы пишите тесты" - "только юнит-тесты и только на бизнес-логику", "Сколько у вас серверов и какая отказоустойчивость" - "5 серверов и хороший админ", "Вас DDOS-ят" - "Да, когда это происходит, мы знаем как решить эту проблему за 15 минут", "Как часто вы деплоите" - "Иногда также часто, как Github (от одного до нескольких раз в день)". "Что вы делаете, когда что-то ломается" - "Быстро чиним", "Сколько у вас сотрудников" - "15 и почти каждый занимается OSS, что добавляет нам карму". Продолжать бессмысленно, надо сдаваться :)

Джош Калдеримис - этот парень просто взорвал зал своей харизмой и настроением. Давайте поблагодарим его небольшим donation здесь https://love.travis-ci.org/

 

Permalink | Leave a comment  »

]]> http://posterous.com/images/profile/missing-user-75.png http://posterous.com/users/4xgikh2uglPj Anatoly Mikhailov mikhailov Anatoly Mikhailov Sat, 03 Dec 2011 20:40:00 -0800 Яндекс Субботник | 03.12.2011 #yasubbotnik http://railsgeek.com/-03122011-yasubbotnik http://railsgeek.com/-03122011-yasubbotnik
В эти выходные я был в Питере на достаточно интересном мероприятии. Компания Яндекс устраивает подобного формата конференции с 2009 года, но в этом году Питерский офис компании впервые (и причем дважды) принял участников субботника, за что им огромное спасибо!

Первые впечатления о формате мероприятия:

1) молодая аудитория, не заметил кого-то старше 30
2) соотношение субъективно полезных докладов к неполезным 50/50
3) есть возможность спросить и узнать как работает Яндекс изнутри

Кратко о докладах (часть из них я пропустил):

Кир вцелом рассказал о том, как меняется взаимодействие пользователя с мобильным устройством и привел пример  реализции 'почти нативного' слайдера средствами CSS3, это как раз та фишка,  которую я каждый день использую, читая новости с iphone. 
Тема тач-интерфейсов достаточно сложная, учитывая зоопарк используемых мобильных платформ, но web, определенно, уходит на мобильные устройства и пользователям просто необходимы привычные им тач и жесты в мобильном браузере.

Серьезный подход в разработке UI, основанный на таргетированной статистике по карте кликов. Каждый слайд презентации на своем месте, ничего лишнего, все последовательно и по шагам.
Вот почему Яндексом так удобно пользоваться, вы теперь знаете, что Анастасия Ларкина следит за тем, куда вы кликаете.

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

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

В стиле Стива Джобса, максимально доступно с перефразированием каждой фразы по 3 раза, но очень интересно.
Мы ждали от Сергея, что он скажет что-то новое, что решит проблемы распределения нагрузки в нагруженном User Generated Content проекте. Нового мы не услышали, зато освежили типичные паттерны масштабирования в данной задачи, а именно:
  - вынести всю работу с данными в модель, так как сервера приложений в отличии от баз данных
    горизонтально масштабируются как горячие пирожки
  - остерегайтесь триггеров и хранимых процедур, так как версионность работы с ними не так проста, как на уровне приложения
  - никаких JOIN-ов, только простые запросы, которые легко загоняются в кэш
  - аггрегировать данные по минимально-возможному ключу
  - инвалидация кэша по колбэку
  - пиши в master, читай со slave, но помни про replication lag
  - кэшировать только часто используемые данные, так как накладные расходы на кэширования "всего подряд" не только высоки, но также польза от них сомнительна, если cache hit будет низким
  - промежуточное кэширования аггрегированных функций, например, счетчиков с последующим 
    периодическим пересчетом, кроме того, с счетчиками лучше работать через методы increment, decrement
  - PubSub - подписка на изменения во френдленте, но годится не всегда и не везде
  - в UGC проектах вместо готового html предпочтительно кэширование промежуточных 
    "сырых данных", которые удобно реиспользовать в разных блоках с разным уровнем доступа
  - на каждый сервер с приложением поставить промежуточный кэширующий бэкенд, чтобы разгрузить базу на чтение, кэшировать можно при первом запросе к базе - прозрачно для приложения.

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

Вот и самое главное, зачем я поехал на #yasubbotnik.
Не могу вспомнить сколько вопросов я задал Екатерине, но на каждый из них получил компетентный ответ.
Тема горизонтального масштабирования хранилища данных нетривиальна и не имеет конкретных паттернов решения задачи, каждый метод (High Availability, High Performance) имеет свои наборы типовых практик, но,
  опять же, здесь все намного сложнее, чем кажется на первый взгляд.

  Одним из моих главный вопросов были:

  - нагрузка, нагрузка и еще нагрузка - справляется ли MySQL с поставленными ему задачами
  - MySQL еще актуален или смотреть в сторону PostgreSQL, либо NoSQL решения
  - как реплицировать и правильно "пилить", то есть шардить/партиционировать базу 
  - как бэкапить без блокировок
  - есть ли какие специфичные конфиги mysql и используют ли Яндекс сборку от Percona

Ответы:

1) master-slave репликации с записью в мастер, чтение со слейвов хорошо показывает себя на работе с огромными объемами данных, таким образом подобные типовые решения ложатся и на такие нагрузки

2) MongoDB используется в продакшне и ведет себя достаточно неплохо, особенно учитывая Replica Sets с автоматической отказоустойчивостью

3) в основном используется MySQL 5.1-5.5, стандартная сборка - достаточно хорошо себя ведет на продашкне с очень-очень большими объемами (надо просто уметь ее готовить)

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

5) из-за больших объемов бэкапы делаются на уровне файловой системы (rsync, tar)

6) шардирование - почти-серебряная-пуля, если знаешь по какому признаку шардить. отказойчивость мета-базы предлагается master-master репликаций и разным offset-ом

Общее впечатление о конференции и компетентности сотрудников Яндекса - 10/10. Планирую посещать субботники настолько часто, насколько это возможно

 

Permalink | Leave a comment  »

]]> http://posterous.com/images/profile/missing-user-75.png http://posterous.com/users/4xgikh2uglPj Anatoly Mikhailov mikhailov Anatoly Mikhailov Wed, 23 Feb 2011 10:17:00 -0800 Everything else is secondary http://railsgeek.com/everything-else-is-secondary http://railsgeek.com/everything-else-is-secondary
"Your time is limited, so don't waste it living someone else's life. Don't be trapped by dogma - which is living with the results of other people's thinking. Don't let the noise of other's opinions drown out your own inner voice. And most important, have the courage to follow your heart and intuition. They somehow already know what you truly want to become. Everything else is secondary." Steve Jobs

Permalink | Leave a comment  »

]]> http://posterous.com/images/profile/missing-user-75.png http://posterous.com/users/4xgikh2uglPj Anatoly Mikhailov mikhailov Anatoly Mikhailov Wed, 24 Nov 2010 08:30:00 -0800 Nginx пример отличного конфига, нужен ли очередной? http://railsgeek.com/nginx http://railsgeek.com/nginx

зачем трогать то, что и без того работает? вопрос логичный, но сподручный стареющему организму/мозгу.

всегда есть то, что то новое почитать, написать, придумать, ну и, наконец, оптимизировать. так уже получилось, что мне сложно представить себе свою работу без постоянного прогресса. это касается обновления, изменения конфигурационных файлов переданных мне на сопровождение 8 серверов помимо основной разработки серверной и клиентской части проекта. одно, что не трогаю - это action script/flex

все работает и не надо ничего менять, но нет... надо, получилось убедить заказчика и все в итоге от этого выиграли. речь пойдет о кратком, но лаконичном конфигурационном файле nginx + passenger. перед тем, как продолжить читать, откройте в отдельном окне сам конфиг - http://twitter.com/amikhailov/status/7091350897950720

  • passenger_pool_idle_time 0; - если у вас один запущенный проект на сервере, либо памяти хватает на все активный проекты, то смело отключайте засыпание passenger при неактивности. имеет смысл, если запуск приложения длиться более нескольких секунд
  • passenger_max_pool_size 15; - опять же, если с памятью все хорошо и нет недостатка, то не жалейте ее, пусть расходуется по назначению
  • gzip on; - сжатие текстового контента уже считается признаком хорошего тона
  • passenger_pre_start https : // 127.0.0.1/; - если ваше приложение запускается более нескольких секунд (речь идет об инициализации всех библиотек + кода) - скажите nginx-у, сделать это автоматически после очередного деплоймента
  • rewrite ^(.*) https://$host$1 permanent; - один из проектов, который я разработываю, не имеет public-контента, соответственно было принято решение приобрести ssl-сертификат и весь функционал спрятать за ним. здесь нет смысла вешать инстансы приложения на 80 порты, делаем редирект на https силами самого сервера. можно забыть про ssl_requirement
  • location ~ \.php$ { deny all; } - обнаружил, что многие боты проверяют наличие phpmyadmin и прочее, нам оно здесь ни к чему, блокируем, пусть рельсам будет проще
  • passenger_min_instances 10; - возвращаясь к первым пунктам, есть достаточно памяти - смело позволяйте запускать столько инстанцов, сколько вам надо
  • location @503 {} - правило хорошего тона, во время деплоймента использовать заглушку - чтобы пользователи были в курсе, почему сервер временно не отвечает. для того, чтобы это использовать - скажите capistrano создавать файл maintenance.html на время деплоймента
  • location ~* \.(png|gif|jpg|jpeg|css|js|swf|ico)(\?[0-9]+)?$ {} - убираем логирование доступа к статике, добавляем заголовки max-expire, 
    SSL контент по умолчанию кэшируется только в памяти, закрывая браузер это кэш обнуляется. поэтому добавим заголовок, чтобы кэшировать статику на жесткий диск - add_header Cache-Control public;

рад, если кому то пригодится

Permalink | Leave a comment  »

]]> http://posterous.com/images/profile/missing-user-75.png http://posterous.com/users/4xgikh2uglPj Anatoly Mikhailov mikhailov Anatoly Mikhailov Wed, 24 Nov 2010 07:53:00 -0800 software development http://railsgeek.com/34389494 http://railsgeek.com/34389494

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

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

кратко мысли:

  • ценно только то, что сейчас + небольшая перспектива (не более 2-4 недель)
  • когда разрабатываю делаю немного больше, чем просят - пытаюсь предугадать следующий шаг заказчика
  • все высокие слова и сложные термины надо сразу исключить + постараться игнорировать тех, кто этим увлекается
  • идеальная команда должна быть не более 5-7 человек - для проекта любого масштаба, лучше меньше, но лучше
  • если требуется больше ресурсов - значит код пишется не тот, либо инструменты не те, или же требования надо сокращать, вообщем оставить саму суть

после прочтениея Rework как то перевернулось все в голове и стало сейчас печально вспоминать все подергивания бывшего руководителя в сторону интерпрайзизма и его зациклинность на техниках, стандартах, сертификации

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

 

Permalink | Leave a comment  »

]]> http://posterous.com/images/profile/missing-user-75.png http://posterous.com/users/4xgikh2uglPj Anatoly Mikhailov mikhailov Anatoly Mikhailov