HighLoad2007

Обещанный пост о том, как прошел HighLoad. В целом мне понравилось, было интересно.
Хотя присутствовал там определенный бардак: и регистрация началась не сразу, некоторое время все толпились в предбаннике. Доклады отменялись, передвигались. Некоторые докадчики приходили без слайдов и были явно не готовы.

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

Павел Кудинов рассказывал о том, как он любит XML, как XML ему работать и жить помогает. И о том, что он любит REST. Я уже было успела порадоваться за человека, но тут он с гордостью упомянул, что занимается поисковым спамом и радоваться стало сложнее. В процессе доклада он препирался с ребятами из Яндекса, у них получилась грустная такая перепалка.

Анатолий Орлов из Яндекса рассказывал про высокие нагрузки в поиске. Это был один из самых популярных докладов и, пожалуй, самый лучший. Вначале он упомянул, что это не рекламный доклад, а честный. Вообще, да, народ любит скрывать нелицеприятные подробности и рассказывает не о том, как у них все работает, а о том, как оно должно работать...
Что было в докладе. Цифры, цифры, они всех очень интересуют. Точных цифр он не называл, ну чем богаты, что называется...
~30 млн запросов в день
~3 млрд документов.
Покупают самое дорогое серийное оборудование.

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

Тимур Хайруллин (он опять же из Яндекса) рассказывал про нагрузочное тестирование. Из интересного - в Яндексе используют открытые софтины для тестирования плюс пишут свое.
Поиск яндекса здоровый, его копию для тестирования поднять не получится. Тестируют на некой минимальной модели.
Еще Тимур упомянул, что Ajax позволяет уменьшить нагрузку. В зале бубнили, что это не очевидно, и вообще должна бы она, наоборот, повышаться.
Рассказал какое бывает тестирование, чем различается: Performance testing, load testing, stress testing...

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

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

"Инструменты тестирования производительности"
Павел Липский из Рамблера упомянул два: ApacheBench и Apache JMeter. Этот доклад хорошо послушать после доклада Тимура.

Микрософт пытался всех убедить, что Линукс очень дорогой в поддержке, дороже решений от Микрософт. "Если у вас что-то не получится, мы вам поможем". Гики слушали это мрачно и с недоверием. "Ага, уж мы вам медом намажем" - прошептал кто-то у меня за спиной.

Выкатка кода в больших проектах. Доклад не состоялся, поэтому организаторы быстро собрали людей из Яндекса и Рамблера и посадили их отвечать на вопросы. Чего рассказали: в Яндексе используются Дебиановские пакеты, в Рамблере используется какая-то самописная пакетная система. Всё.

Несколько отличался от других доклад "Многоуровневые мониторинг веб-систем класса mission-critical". В основном все рассказывали про какие-то монструозные проекты, здесь речь шла о сравнительно небольшом проекте, который, тем не менее, довольно-таки нагружен и должен работать четко, бесперебойно.
Чего делают: прогоняют регурярно сценарий, который имитирует поведение пользователя. Если чего-то не работает, шлют админам СМСки. Они еще время от времени проверяют реакцию админов - ложные СМСки посреди ночи шлют. Эта информация вызвала оживление в зале. Доклачик сказал, что "это некоторое изуверство" и "это вызывает эмоции и не всегда позитивные".


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


А это теплоход, который приобрел уже широкую известность :-). Там кормили на убой и давали бесплатное пиво.

Еще куча фоток с HighLoad2007.

Размышления на тему сложности C++ на блоге The lonely compiler

The lonely compiler: Синтаксис и семантика, простота и сложность

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

Напряженная неделя: HighLoad-2007 и Exception #06

Давно не была ни на каких конференциях, а на следующей неделе собираюсь посетить сразу две. Во-первых, HighLoad-2007, которую я жду давно и с нетерпением, а во-вторых - Exception #06. Вообще Exception - это конференция питонистов, но мой муж будет там с докладом и я решила съездить с ним за компанию. Послушаю чего там будет, пригодится для общего развития.
Про HighLoad собираюсь написать отдельные посты в блог, про Exception не буду, потому что это совсем не по теме.

О C++0x в Википедии

В Википедии, оказывается, есть очень неплохой раздел про C++0x. Кратко описаны ожидаемые новые возможности языка, с примерами.

Статья The Rise and Fall of CORBA

The Rise and Fall of CORBA - грустная история о том как бюрократы победили.

Системы контроля версий

Source control (revision control, source code management (SCM)) - по-русски это все обычно называют системами контроля версий. Контролировать ими можно много чего, но меня они, конечно, интересуют в плане работы с кодом. Сначала я кратко расскажу про системы контроля версий для тех, кто о них ничего не знает или знает мало, а потом пару слов скажу про выступление Линуса Торвальдса, в котором он рассказывает о Git'е.

Зачем вообще нужен какой-то контроль за кодом? Затем, что без контроля получается бардак. На диске появляются бесконечные копии исходников с загадочными именами: MyProject1, MyProject.backup, MyProject.old, MyProject.oldest. Проку в них никакого нет, потому что все равно уже не вспомнить где какие изменения делались.
Основная идея систем контроля версий - запоминать все внесенные изменения с комментариями. Понятно кто когда что менял, зачем. Главное - можно все эти изменения откатить. Ну а кроме этого систему контроля версий можно обвешать дополнительными фишками и рюшечками.

Самые известные, которые чаще всего упоминаются - CVS, Subversion (SVN), Perforce. Все системы, что я перечислила, объединяет то, что это системы с одним, выделенным сервером, на котором и находится репозиторий с кодом. Скорее всего вы работали с какой-то из них. Если ни с какой не работали, то очень рекомендую поставить Subversion. Его легко и непринужденно можно погонять на одной локальной машине и получить полное представление о работе систем контроля версий.

Небольшой словарик для понимания дальнейшего. Переводами народ себя обычно не утруждает :-).
Транк (trunk) - основная ветка кода
Бранч (branch) - ответвления (для экспериментов, например)
Чекин (Check in (submit, commit)) - отправка кода в репозиторий
Чекаут (Check out) - получение изменения из репозитория.
Конфликты - возникают, когда несколько человек правят один и тот же код, конфликты можно разрешать
Патч - кусок с записанными изменениями, которые можно применить к репозиторию с кодом

Updated 20.07.2008 Вообще терминология расходится, всё зависит от того, о какой именно системе идет речь. Например, "check out" в Perforce имеет несколько иное значение.

Традиционная схема работы с репозиторием в Open Source проектах такова. Есть некто Главный (пусть будет Ведущий программист, неважно). Программисты делают патчи, цепляют их к багам в багтракинговой системе. Главный просматривает их патчи, если все ОК - применяет к коду. В Second Life используется схема работы с патчами. В качестве багтракинговой системы там используется JIRA, в качестве системы контроля версий - Subversion.
В компаниях такая схема тоже иногда применяется, при работе со стажерами. Чтобы кто-то просматривал их код, прежде чем он попадет в репозиторий. Обычные же программисты, как правило, имеют право коммита.

Вот выступление Линуса Торвальдса, в котором он рассказывает про им написанную систему контроля версий Git. Тон рассказа мне не очень понравился, Линус там периодически пытается несмешно шутить по поводу своей популярности. Кстати, по ходу доклада гугловцы упоминают, что у них используется Perforce.

Линус не любит Perforce, не любит CVS, не любит Subversion. Он ратует за распределенные системы контроля версий. Которые, мало того, что убирают точку отказа, но еще делают более простым процесс создания бранчей и позволяют смело экспериментировать с кодом, не вызывая комплексов "засабмитить не то".

Я думаю, Git получит рапространение хотя бы по тому, что его написал Линус. Еще пример использования распределенной системы контроля версий - Bazaar используется при работе над Ubuntu Linux.
Большой список систем контроля версий можно посмотреть в Википедии.

Ссылки по теме:
Boost переехал в Subversion репозиторий

Updated 23.09.2007
M. Sf. в комментариях подробно рассказывает о своем опыте работы с Git'ом

Updated 05.01.2008
Девять причин перейти на Git

Я теперь работаю в компании SeeStorm

Вот уже две недели я работаю в компании SeeStorm. Фактически это подразделение другой, более крупной компании - SPIRIT. Занимаюсь анимированными аватарами. Делаю говорящие головы, проще говоря :-).
Посколько задачи, которые я решаю и буду решать, очень похожи на те, что ставятся перед разработчиками игр, то я буду продолжать делать посты с тегом gamedev. Вообще, постов будет наверное меньше, чем было в последнее время, но я все же постараюсь постить что-нибудь новенькое более менее регулярно.

Новость эта означает еще и то, что сдвинуть с мертвой точки Winding Trail не удалось. Увы.