Наверх ▲

Смена web-платформы «на лету»

Евгения Фирсова Евгения Фирсова Руководитель отдела веб-интерфейсов, Яндекс.Деньги.
View more presentations from rit2010.
Евгения Фирсова: Добрый день, меня зовут Евгения Фирсова, я работаю в компании «Яндекс». Задача, которая встала передо мной «Яндекс.Деньги». Но я буду очень стараться не называть наши технологии и наши языки разработки, потому что, наверное, это не принципиально. Моя цель - рассказать о смене веб-платформы.

Какая задача передо мной встала?

Представьте, что у нас есть сайт. Очень условная схема его работы показана на иллюстрации. Есть веб-сервер, на котором запущена некая среда разработки, есть некий back (серверные языки программирования, базы данных, внешние и внутренние компоненты — неважно, это некие источники данных). Есть то, что у меня названо xsl — это верстка. Собственно, чем мы занимаемся? Надо эти данные преобразовать в вид, необходимый для пользователя.

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

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

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

Мы понимаем, что под новую среду исполнения нам придется переписывать имеющийся код. Старый в новой среде работать не будет: налицо несовместимость. Выясняется, что есть и ограничение ресурсов. Что имеется в виду? Если мы будем переписывать код на новый язык, у нас не будет людей, которые умеют работать с этими новыми технологиями.

Набирать их оснований нет и возможности нет. Мы должны ограничиться той командой, которая есть. Причем работать придется «по-живому» — экспериментировать и выкатывать продукт.

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

«Яндекс.Деньги» — это платежная система, у нас платежный сервис. Мы не можем позволить себе простои. Мы не можем позволить себе усложнить жизнь пользователям. Мы не можем предъявлять новые требования типа: «А теперь все поставили flash дружно!». Такого рода вещи для нас недопустимы. Это наше ограничение.

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

Почему это важно?

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

Соответственно, мы должны учитывать, насколько мы можем замедлить процесс, чтобы нас не уволили. И не сказали: «Нет, ребята, не нужна нам ваша новая платформа. Давайте по-другому».

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

Иногда получалось кого-то уговорить, иногда нет. Было принципиально выяснить, позволят нам обновить платформу или заставят нас работать на старых технологиях.

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

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

Как следует поразмыслив, мы нашли технологическое решение, оно напрашивалось само собой. У нас не такие масштабы, чтобы "поднять" отдельный сервер и делать на нем новую версию. Мы не можем себе это позволить. Текущая версия развивается очень быстро, к тому же она большая, там много функционала. Никто не позволит  нам отдельную (англ. standalone) версию делать. Это нереально.

Значит, перетаскивать новый функционал на новую схему придется по частям, по страницам.

Я уже говорила, что у нас из-за смены среды получается несовместимый код. Немного подумав, мы решили, что не будем себя ограничивать, раз мы все меняем. Мы меняем веб-сервер на новый просто потому, что он лучше работает с новой средой исполнения.

Схема примерно следующая. Все пользовательские запросы попадают на первый сервер, который "решает" — либо он сам отдает страницу, либо проксирует на другой. Оба сервера работают одинаково, но возникает проксирование. Реализован набор правил относительно того, какой сервер и какая среда какую страницу или функционал отдает пользователю.

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

Сначала мы хотели сделать следующее. Мы рассуждали следующим образом: «У нас есть сервер, там все хорошо. В течение года мы на новый сервер будем какие-то страницы перетаскивать. Давайте оставим все, как есть. Только новому серверу новые страницы отдадим». Мы успели остановиться и еще раз хорошо подумать. Поняли, что критерии должны быть несколько другими.

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

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

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

«Переходный» период длинный. Есть масса сложностей и сомнений. Возникают риски. Можно сравнить риски в каждой ситуации. Понятно, что при старом сервере на входе риски никакие. Мы как разрабатывали, так и разрабатываем. Что-то новое может сломаться.

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

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

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

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

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

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

Очень важно, чтобы первую страницу можно было "откатывать". Понятно, что не любую выкладку можно "откатить". Сильное визуальное изменение индексной страницы нельзя откатить. Пользователи сразу вопросы зададут.

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

Процесс начала перехода медленный. Нам хочется что-то поменять, но страшно, а заказчику изменений не очень хочется, потому что он в другом заинтересован. Должен быть кто-то, кто будет этот процесс "толкать". Заказчик внешний, заказчик внутренний, какой-то лидер группы (англ. team lead). Должен быть кто-то, кому это очень надо.

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

Первая страница должна быть простой в реализации. У нас и так много забот. Пусть она будет простая. Кроме того, простота первой страницы поможет нам в случае возникновения проблем быстро найти их источник. Мы оперативно узнаем, где проблема — в бизнес-логике, которую мы реализовали, или, например, в проксировании, или в том, что новая схема не держит нагрузку. На маленьких, ничтожных изменениях легче понимать, что пошло не так.

Предположим, первую страницу мы "выкатили". Следующие несколько примерно такие же. Мы заботимся об "откате", мы себе не доверяем, мы еще не профессионалы, разумеется. Мы выбираем максимально разные страницы. На любом портале есть какие-то близкие страницы. У нас, например, есть торговый ряд — там множество витрин. Можно десять витрин "перетащить", но это неинтересно.

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

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

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

Насколько крупный? Речь шла об индексной странице портала, странице успеха платежа. Почему мы решились на подобный шаг, несмотря на недостаток опыта?

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

Скорость в качестве действенного стимула очень важна.

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

Все, о чём я говорю, несколько напоминает рефакторинг. Мы берем готовое и переписываем. Чем не рефакторинг?

Момент выбран удачно - надо отдавать себе в этом отчет. Мы переписываем код для совместимости, следовательно имеем право на рефакторинг. Но не стоит им увлекаться. Сам по себе рефакторинг может занять столько времени, что основная цель (смена платформы) не будет достигнута.

Какие бывают риски?

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

Например, у вас есть код, написанный на "Cи". Вы его переписываете на C++, но при этом не используете аспектно-ориентированное программирование (АОП). Вы можете его использовать, но зачем? Существует объектно-ориентированное программирование, которым надо пользоваться.

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

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

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

Для бизнеса риски, конечно, тоже присутствуют. Срыв сроков - один из них. Им нет дела до всех наших внутренних рефакторингов. Им интересно, когда обещанное будет воплощено в жизнь. Мы можем пообещать и не выполнить из-за того, что в расчетах была допущено ошибка. Такая ситуация тоже возможна.

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

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

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

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

К счастью, у нас такого пока не было и, надеюсь, не будет. Что делать в этой ситуации, честно говоря, сказать затрудняюсь. Могу только посочувствовать.

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

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

Допустим, обычно мы какую-то страницу делаем за неделю. Говорю на всякий случай: «Потребуется две недели». Если этого времени не хватит, прибавляем еще неделю.

Есть еще и такая вещь, как рефакторинг. Удастся ли запланировать его бещ ущерба для внедрения бизнес-функционала, — это открытый вопрос. Рефакторинг должен давать результат. Нас интересует не внутренняя красота кода, а конкретный результат для пользователя.

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

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

Наконец, нужно учитывать возможный рост портала. Допустим, сейчас я знаю, что у нас на портале столько-то страниц, есть такой-то функционал, и переписывание существующего займет столько-то.

Но я не могу знать, какой объем нового функционала мне закажут в течение «переходного» периода. Я могу только примерно оценить это и заложить это время в срок. Никто не может остановить заказ нового функционала на полтора года просто потому, что у нас запланирована миграция. Так не бывает.

Далее я расскажу про специфичные проблемы, которые возникают при поддержке «переходного» периода в разных отделах.

Начнем с отдела разработки Самая неприятная вещь - это пересечение кода. О чем речь? У нас есть какой-то код, который предназначен для старой среды, и есть код, который предназначен для новой среды. Разумеется, и там, и там есть "куски", которые "делают" одно и то же.

Какими они могут быть? Если повезет, это окажется, например, библиотека, элемент, который работает и там, и там без изменений. Это просто супер! Надо всего лишь придумать, как этот код и в старую, и в новую версии подключать из единого источника. Но нельзя копировать в разные репозитории один и тот же кусок библиотеки. Это как-то странно.

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

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

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

Если у нас есть общий код, который и там, и там эту шапку рисует — это хорошо. Если код несовместимый, если приходится вручную вносить эту несчастную ссылку в две разные функции — это проблема. Большая часть кода, конечно, несовместима. Надо просто уметь работать. Это не столько технологическая проблема (запрограммировали два раза — это нормально), сколько организационная. Должен быть кто-то, кто знает, в какой момент и в каком объеме нужно делать перенос и синхронизацию.

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

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

Например, это кусок библиотеки. Сейчас он используется только на старых страницах. Будет он использоваться на новых? Будет. Тогда нужно это учитывать и переписывать. Не будет? Значит, перепишем когда-нибудь потом.

Если изменения вносятся сразу в новый код, появляется обратная задача: нужно ли нам вспоминать, что где-то в старом это есть и переписывать туда? Заказчик об этом не знает. Заказчика это вообще не волнует. Такие решения  принимаются на уровне того человека, который весь этот код (новый, старый — неважно) держит в голове и понимает, как он используется и где он потенциально может использоваться.

Работа лидера группы очень важна. Без него схема вообще не "живет". Сразу все рассинхронизируется, появятся различия, которые недопустимы.

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

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

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

С синхронизацией разработки вроде все понятно. Сложно, но есть человек, который держит это в голове, и это работает. Как обеспечить синхронность выкладки, релиза? Я знаю только два способа. Наверняка есть другие, но я знаю два.

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

Есть такая вещь, как «рубильник». Я много о них говорила раньше. Это возможность сделать релиз, выложить функционал таким образом, что он будет доступен пользователю не сразу. Потом можно включить его какими-то другими, внерелизными способами. С помощью CMS или файлов конфигурации. Так или иначе, это делается независимо.

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

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

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

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

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

Что мы получили? Да, мы перешли на новую технологию, на новый сервер, на новую среду. Переписали код, почистили его, улучшили и ускорили. Это только в плюс.

Мы получили опыт работы с новыми технологиями. Ранее мы не умели этого. За «переходный» период мы многое научились делать не хуже, а, может быть, и лучше, чем в ходе работы с прежними технологиями.

Дальше мы можем развивать то, что уже есть. Или начать планирование следующего перехода, следующей смены технологий, что вполне допустимо.

На этом я заканчиваю и готова ответить на ваши вопросы. Спасибо.

Вопросы и ответы

Вопрос:
— Вы говорили про код, а как быть с базами данных? У вас базы есть? Они как-то меняются в процессе перехода?
Евгения Фирсова:
— Содержимое баз данных?
Вопрос:
— Структура.
Евгения Фирсова:
— Это зависит от того, какая конкретно бизнес-задача решается. Да, для некоторых структуры меняются.
Вопрос:
— Как с этим мириться? Они же не одни, наверное?
Евгения Фирсова:
— Никак не мириться. Делать так, чтобы новая структура включала в себя старую, чтобы она со старым и с новым кодом, грубо говоря, работала. Можно добавить в таблицу новое поле, а удалить старое нельзя, пока процесс не закончен. Даже если оно нам уже не нужно.
Вопрос:
— Вы упомянули нагрузочное тестирование на маленьких страницах. Как примерно вы это делаете?
Евгения Фирсова:
— У нас есть примерный профиль пользовательской нагрузки на наших "боевых" серверах. Мы знаем, как этот профиль наложить на посещаемость конкретной страницы, и нагружаем ее так или чуть больше. Чтобы понять, будет страница "жить" под "боевой" нагрузкой или нет.
Вопрос:
— Вы жаловались, что у вас большая проблема с общим кодом. Общие модули в CVS и SVN. Вы не пробовали распределенные системы контроля версий использовать?
Евгения Фирсова:
— Не пробовали и пробовать не будем. В большей степени из-за сложностей организационного рода. Распределенные системы предполагают, что у каждого есть локальный репозиторий, с которым можно совершенно независимо работать. У нас платежная система. Речи быть не может о том, чтобы у человека была локальная копия всего кода. Ее просто "уведут". Работа идет со строго защищенным репозиторием. Он один. Распределенные системы мы использовать не можем.
Реплика:
— Я добавлю. Вы дали общий ответ. Фактически вы не ответили на мой вопрос. Для нагрузочного тестирования, скорее всего, вы используете GMeter или аналоги. Вы можете эту информацию открыть?
Евгения Фирсова:
— Специалист по нагрузочному тестированию вам ответит.
Тимур Хайруллин, руководитель службы нагрузочного тестирования в Яндекс:
— Что конкретно вас интересует?
Вопрос:
— Средства, программное обеспечение. Какими инструментами вы тестируете?
Тимур Хайруллин:
— Своими собственными.
Вопрос:
— Спасибо.
Евгения Фирсова:
— Еще раз спасибо за внимание.

Комментарии

Нет ни одного комментария

Только пользователи могут оставлять комментарии

Возможно, вам будет интересно:

Артём Гавриченков

Артём Гавриченков

Ведущий разработчик в компании "Highload Lab".

В докладе описаны типичные ошибки программирования при написании серверных приложений на основе TCP-сокетов.

Сергей Аверин

Сергей Аверин

Руковожу разработкой проектов в Баду. Программирую server-side. Конференционный маньяк. Среди проектов, которые я делал — Хабрахабр, dirty.ru, trendclub.ru. Специализируюсь на больших/сложных веб-проектах.

twitter: twitter.com/ryba_xek
facebook: facebook.com/ryba.xek

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

Игорь Сысоев

Игорь Сысоев

Технический директор Nginx.

Интервью с разработчиком HTTP-сервера nginx, который используется на каждом десятом российском интернет-сайте.