Лучшее за 2007 год

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

C++
В целом за год постов по С++ было маловато. Некоторым интересом пользовались Указатели на функцию, коллбэки и функторы, Что делает выражение вида delete p и Мультиметоды.

Программирование
Передовые технологии Гугла - самый популярный пост этого года. Куча ссылок, перепечаток, высокое количество просмотров в течение всего года.
С большим отрывом от него, но все равно очень популярны: Глубокий веб, Работа с большими числами, Системы контроля версий, Архитектуры Амазона и YouTube.

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

Лучшее из старого
Были посты из предыдущих лет, которые были очень популярны и в течение 2007 тоже.
Это .kkrieger, Точки следования, Нарисовать граф красиво и Хорошие книги по С++ для начинающих.


Как обычно, у меня полно планов на будущее. Немного, совсем слегка, причешу дизайн блога. Надо будет слоган в названии поменять, а то он перестал соответствовать действительности. Например, про DirectX я сейчас вообще практически не пишу, зато пишу много про что другое... Я впишу туда какую-нибудь загадочно-обтекаемую фразу. И правую менюшку надо будет проредить, а то что-то она захламилась. Ну и, конечно, в планах много всяких интересных заметок, надеюсь что у меня дойдут руки дописать и опубликовать большинство их них.

С Новым Годом! Оставайтесь с нами :-)

Ссылки по теме:
Лучшее за 2006 год
Лучшее за 2005 год

Высокие технологии в Сбербанке

blog.lexa.ru: Сбербанк сделал мой день

Меня поразил не только удивительный квест, который нужно пройти пользователю, чтобы получить апдейт. Меня поразил острый дефицит пустых CD болванок в Сбербанке.

Amazon SimpleDB

По блогам расползается информация об Amazon SimpleDB. Это распределенное хранилище данных, которым можно будет пользоваться за умеренную плату. Сейчас SimpleDB пока вышла в закрытую бету. REST интерфейс, максимально простые запросы. И, между прочим, "SimpleDB is built on top of Erlang". На официальной страничке Амазона упоминают, что "вам теперь не нужен DBA". Похоже, они намереваются серьезно конкурировать с тем же Ораклом, например.
SimpleDB пытаются сравнивать с BigTable, хотя BigTable предназначена для хранения данных Гугла, доступ пользователям туда не предоставляется.
Вообще интересно, в области хранения данных интерес смещается от реляционных баз данных к большим распределенным хэшам.

Ссылки по теме:
What You Need To Know About Amazon SimpleDB
Amazon SimpleDB - Technical Overview
Amazon SimpleDB Developer Guide
Архитектуры Амазона и YouTube

Updated 31.12.2007:
The Current Pros and Cons List for SimpleDB
Product: Amazon's SimpleDB

Microsoft Dryad

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

Доклад вообще хороший. Но есть неприятные моменты. Во-первых, несколько раз подчеркивается, что это "как MapReduce, только лучше". То есть MapReduce их очень задевает.
Во-вторых, докладчик сильно нервничает, но явно на пустом месте. На вопросе про устойчивость к ошибкам его разве что не трясло. При этом он явно знает о чем говорит, что-то где-то забыл, но это нормально...

По ссылке с Geeking with Greg.

Ссылки по теме:
Кроме видео, есть документ Dryad: Distributed Data-Parallel Programs from Sequential Building Blocks
Про MapReduce можно почитать здесь: Передовые технологии Гугла.

Here Comes Another Bubble

Клип "на злобу дня", что называется :-)


Спасибо Maniac'у за ссылку.

Герб Саттер сегодня будет выступать в Second Life

Герб Саттер сегодня появится во вселенной Second Life на мероприятии, посвященном параллелизму. Официальное название мероприятия: SOFTWARE AND THE CONCURRENCY REVOLUTION: DESIGNING FOR MULTIPLE CORES. Обещают что еще там появятся лучшие инженеры Интела.
Время дано штатовское, я заюзала Time Zone Converter и выяснила, что мероприятие состоится в 19.00 - 22.00 по Москве, Герб Саттер будет выступать 20.00 - 21.00.
Регистрация тут.
Трансляция для тех, у кого нет аккаунта в Second Life или кто не может залогиниться тут.

Специалисты из D-Wave выступили в MIT

На блоге Скотта Ааронсона дали ссылку на слайды выступления D-Wave в MIT'е. Это те люди, которые утверждают, что сделали квантовый компьютер. Скотт отзывается об этом выступлении довольно прохладно, ничего действительно интересного они не рассказали.
Еще в комментариях Скотт рекомендовал почитать вот эти лекции тем, кто интересуется квантовыми вычислениями.

Архитектуры Амазона и YouTube

По ссылке с lktalks нашла интересный сайт, посвященный архитектуре больших систем - High Scalability. Там много чего есть, но наибольший интерес, конечно, вызвают архитектуры известных проектов. Я почитала про те, что посоветованы на lktalks и сделала небольшой обзор. На High Scalability все описано подробнее.

Amazon.com
Amazon - самый известный Интернет-магазин.
Используют: Linux, Oracle, C++, Perl, Mason, Java, Jboss, Servlets

У них более 55 миллионов активных аккаунтов. Начали они с одного приложения, которое общалось с бэкэндом. Написано это все было на C++.
Сегодняшняя архитектура Амазона слабосвязная. Построена вокруг сервисов. Это дало им изоляцию, которая позволят строить многочисленные софтверные компоненты быстро и независимо.
Все разрослось на сотни сервисов и несколько серверов приложений, которые агрегируют информацию с сервисов. Например, приложение, которое рендерит странички amazon.com, это один из таких серверов приложений.
Технологии третьих сторон для амазоновского сайта масштабировать тяжело. До определеного момента все работает, а потом уже не работает. Амазоновцам пришлось все свое строить.

Они не придерживаются какого-то одного подхода. Где-то используют
jboss/java, но используют они только сервлеты, больше ничего из J2EE не используют.
C++ для обработки запросов. Perl/Mason для построения контента.

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

Используют как SOAP, так и REST. ~30 процентов SOAP'а.

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

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

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

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

Открой свою систему, предоставь API и ты создашь экосистему вокруг своих приложений.

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

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

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

Разработчикам лучше знать какие именно тулзы делают их более продуктивными и какие именно тулзы подходят для конкретной работы.

YouTube
Используют: Apache, Python, Linux (SuSe), MySQL, psyco (динамический компилятор python->C), lighttpd вместо Apache
Для балансировки загрузки и кэширования статического контента используют NetScalar.

YouTube - это 100 миллионов просмотров в день.
2 сисадмина, 2 архитектора софта по масштабированию

2 девелопера, 2 сетевых инженера, 1 специалист по БД.

Их рецепт как управиться с быстрым ростом системы :

while (true)
{
  identify_and_fix_bottlenecks();
  drink();
  sleep();
  notice_new_bottleneck();
}

Питон способствует быстрой разработке. Питоновский код обычно не является узким местом, проблемы вызывают RPC.

Каждое видео хостится на мини - кластере. Каждое видео обслуживается более чем одной машиной.

Советуют использовать простое и дешевое оборудование. Держать как можно меньше оборудования между пользователем и контентом. Использовать серийное оборудование. Более дорогое оборудование означает более дорогую поддержку, причем при этом вряд ли найдешь какую-нибудь помощь в Интернете если что.

Неожиданной проблемой оказалась работа с тамбнейлами. Это очень много очень маленьких картинок. По 4 на каждое видео. Проблемы с обслуживанием большого количества маленьких объектов - много приходится рыскать по диску, много запросов в секунду происходит, потому что на одной странице может быть до 60 тамбнейлов. Апач с такой нагрузкой справляется плохо. Пробовали использовать squid вместе с Апачем, пробовали lighttpd. В итоге они стали использовать Гугловский BigTable и это решило все их проблемы. (От себя добавлю, что с использованием BigTable у них наступило настолько полное счастье, что оно выглядит подозрительно. Ну не может быть чтобы вообще никаких проблем не было)
Для хранения метаданных (пользователи, описания) используют MySQL.

Наиболее интересные выводы
Надо уметь расставлять приоритеты. Надо знать, что в твоем сервисе является наиболее важным и концентрировать ресурсы именно там.
Ну и - Keep it simple!


Еще там есть описание архитектур Google и Flickr.

Ссылки по теме:
Про Google я как-то писала довольно подробно
Также на High Scalability упоминалась ссылка на Introduction to Distributed System Design

C++0x - сборка мусора и потоки

Герб Саттер пишет, что опциональная автоматическая сборка мусора не будет добавлена в новый стандарт языка. Однако, будут убраны вещи, которые ей препятствуют.
For C++0x, we're not going to add explicit support for garbage collection, and only intend to find ways to remove blocking issues like pointer hiding that make it difficult to add garbage collection in a C++ implementation.

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

С потоками у них тоже не все ладится, но все же в каком-то виде они будут.

Более того, они не укладываются в расписание и не факт, что это будет C++09.

:-(

Сервис "Болтуны"

Мы (SeeStorm то есть) поучаствовали в создании сервиса "Болтуны". Смысл сервиса - создать анимированное поздравление с Хэллоуином.
Собственно там можно составить базовое представление о том, что же такое анимированные аватары, о которых я писала. Базовое - потому что мы можем больше. :-)
Моего кода там нет. Правда, по ходу дела пригодилась одна моя тулза.

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

Сначала там в основном подростки матерились. Но через некоторое время пошел креатив. Вот наиболее интересные ролики.
О вреде курения

По этой ссылке нашла еще два
Маша подходит к краю крыши
Эй, плотник, сколоти мне гроб

Ссылки по теме:
Прекрасное произведение Желязны на тему Хэллоуина "Ночь в тоскливом октябре".

Пост The Last Language War

"I am joined on stage tonight by many distinguished, high-profile computer programming languages. Each is highly regarded by its devotees, and I for one look forward to hearing what each has to say."
The Last Language War / Language Trolling Post You'll Ever Need To Read (Hopefully) - прикольный диалог языков программирования.

Спасибо Maniac'у за ссылку.

Про эзотерические языки

По ссылке с поста lrrr Эзотерические языки - самый полный список нашла очень забавную статью Путеводитель автостопщика по потаенным знаниям.
И еще про эзотерические языки есть в Википедии.

Пост Comparing the Microsoft and Google tool chains

Некто Джэк Палевич (Jack Palevich) перешел работать из Микрософта в Гугл. И сравнивает теперь тулзы, которые он использовал в Микрософте с тулзами, которые используются в Гуле: Comparing the Microsoft and Google tool chains. И там, и там все фигово с системами контроля версий. Интересно, что Гугл гораздо щедрее в том, что касается закупки харда для разработчиков.

Статья Reading C type declarations

Чтение сложных объявлений типов в C/C++ задача непростая. Нет, все когда-то слышали, что надо идти кажется направо, а потом вроде налево и тем еще что-то про скобки было, но вот такое объявление может поставить в тупик:

int (*(*)())()

В статье Reading C type declarations приведено подробное описание и наглядные примеры расшифровки таких объявлений. Встречаются они редко, но всегда в самое неподходящее время...

Слайды How to Design a Good API and Why it Matters

Слайды How to Design a Good API and Why it Matters помогут сдизайнить API за который вас будут поминать исключительно добрым словом.

Кусок оттуда:

Characteristics of a Good API

• Easy to learn
  
• Easy to use, even without documentation
  
• Hard to misuse
  
• Easy to read and maintain code that uses it
  
• Sufficiently powerful to satisfy requirements
  
• Easy to extend
  
• Appropriate to audience
  

Червь "Шторм"

Детективная история. С начала года по Интернету активно распространяется червь "Шторм". Количество инфицированных машин оценить сложно, по разным оценкам от 1 до 50 миллионов. Отследить его довольно сложно. Он не использует центральный сервер для координации своих действий, а использует нечто вроде p2p сети и вообще всячески шифруется. Особенно ничего страшного не делает, видимо, ждет чего-то. Специалисты по безопасности волнуются.
По слухам его делают какие-то русские хакеры. Слухи эти совершенно необоснованные, по-моему, это что-то вроде генетического страха перед русскими хакерами.

Спасибо Maniac'у за ссылку.

Ссылки по теме:
The Storm Worm
Storm Worm DDoS Attack

Как прошел Exception #06

Отлично прошел! Очень популярное мероприятие, оказывается. Был народ не только из Киева и даже не только из Украины. Были замечены девелоперы из Екатеринбурга и из Москвы. Организаторы постарались на славу. Мы общались с Иваном Пирогом, Дмитрием Кожевиным и Максом Ищенко, большое им спасибо, конференция была организована замечательно.

Подробное описание можно посмотреть здесь: Exception Log.

Официальные фотографии и видеозапись пока вроде не выложили. Выложат - я тут ссылку добавлю.

Материалы Exception#6 на официальном сайте

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 не удалось. Увы.

Пост "Разработка AI в стратегических компьютерных играх"

Андрей Плахов опубликовал посты о разработке ИИ по материалам КРИ2004 с комментариями года нынешнего.
Разработка AI в стратегических компьютерных играх
Разработка AI в стратегических компьютерных играх II

Updated 02.09.2007
Разработка AI в стратегических компьютерных играх III

Очень интересно.

Код New Blue Pill доступен для скачивания

История с Blue Pill имеет продолжение.
Invisible Things Lab написала New Blue Pill, на страничке Blue Pill Project выложены исходники и слайды. И есть еще пост Джоанны в блоге.
Чего пишут. Рассказывают, что методы обнаружения, предложенные ранее, работать не будут и вот почему. Обнаружение состоит из двух этапов.
1. Понять, что используется виртуализация.
2. Понять, что виртуализация используется злонамеренно, ну в данном случае, что это Blue Pill работает.

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

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

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

Самое интересное. Чего там с их Challenge'ем-то.
Джоанна пишет, что вопрос, почему она поставила свое условие с одной секундой остается как упражнение читателю. Я так понимаю, это нужно для работы Blue Chicken.
Говорит, что Challenge они выиграет легко, просто на части компьютеров запустит виртуальную машину с чем-нибудь безобидным и отличить это от Blue Pill будет невозможно. То есть подстрахуется, на случай, если Blue Chicken не справиться.
Про тонну денег, которую она хочет - ни слова. А пока она от этого требования не откажется, ничего не будет.

Updated 05.08.2007:
Пташек написал пост у себя и сказал, что они отлично смогут распознать как минимум неожиданную виртуализацию (unexpected virtualization). Подробности тут: Joanna’s Response To Our Talk.
Updated 07.08.2007:
Пташек выложил ссылку на их слайды.

Страничка Криса Хекера

Крис Хекер (Chris Hecker) - про свою должность пишет, что он Technology Fellow, Maxis/Electronic Arts. Работает над Spore.

На его страничке много чего интересного, меня в первую очередь заинтересовал его доклад How To Animate a Character You've Never Seen Before. Это слайды и аудиозапись с GDC'07. Жалко, что нет видео. Он явно много жестикулирует, демки какие-то показывает. Вот этого всего не видно.



Формат для свой странички он выбрал странный. Это wiki. Но там можно получать обновления по RSS и e-mail, то есть от блога практически не отличается.

Ссылки по теме
Уилл Райт об игре Spore

Текстурирование Google Earth

На блоге RealityPrime Ави Бар-Зив (Avi Bar-Zeev) публикует серию постов под названием How Google Earth [Really] Works. Ави участвовал в разработке Google Earth на начальном этапе. Тогда это еще не имело отношение к Гуглу, называлось Earthviewer и было потом Гуглом куплено.
Первый пост был как раз о текстурировании. Их подход к текстурированию называется Universal Texture и защищен патентом. Ави как раз занимался реализацией Universal Texture. В его посте приведена ссылка на статью, подробно описывающую работу этого подхода. Он рассказывает о текстурировании очень подробно, останавливаясь на таких базовых вещах как билинейная фильтрация и мипмэппинг. Я это все опущу, если не знаете что это такое - я привела ссылки, да и самого Ави можно почитать. У меня здесь будет что-то вроде краткого пересказа статьи The Clipmap: A Virtual Mipmap, на которую ссылается Ави.

Вкратце отрисовка земного шара на клиенте выглядит так: надо нарисовать кусок земной поверхности и положить на него текстуру Земли, снятую со спутника.
Итоговая текстура у них получилась размером 40 млн на 20 млн текселов. Плюс мипмэп уровни, стандартные, по степеням двойки. Как уже можно догадаться размер получается большой. На самом деле примерно 11 петабайт. Много, короче. А это все надо передать по сети клиенту. И наложить на машине пользователя на кусок земного шара, а в оперативную память такое не влезет. Обычное решение в таком случае - текстуру порезать на куски, хранить не целиком, а кусками, и уже с ними работать. Тут, правда, всплывают проблемы с совмещением этих кусков, появляются ограничения на геометрию. Разработчики решили, что эти проблемы им не нужны, что у них Свой Путь и они ничего резать на куски не будут. А будут хранить всю текстуру целиком, а на клиента передавать только то подмножество, которое клиенту в данный момент нужно. В итоге получается, что клиенту нужно где-то 35 мегабайт. Тут все зависит от качества текстуры, его ведь можно варьировать, Ави пишет, что достаточно 17 мегабайт.

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

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

В The Clipmap: A Virtual Mipmap это все описано подробно и загрузочно, с наглядными схемами.

По ходу своего рассказа Ави высказывает интересную идею - скрестить Google Earth и Second Life (Кстати, исходники клиента Second Life открыты, их можно посмотреть прямо сейчас).

Ссылки по теме:
Ланс Виллиамс изобрел мипмэппинг в 1983 году и описал его в работе Pyramidal parametrics.

На этой неделе планирую работы на блоге

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

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

Безопасность в С++

C++: A Cautionary Tale, or, 1 Hour Of Your Black Hat Trip is Spoken For - Томас Пташек рассказывает почему язык С++ небезопасен. Критикует следующие моменты.

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

delete. В С++ есть выражение delete и есть delete[]. И их очень легко перепутать. У меня есть старый пост про работу delete'ов Что делает выражение вида delete p. Пташек дает ссылку на Attacking delete and delete [] in C++, где гораздо подробнее рассказывается о работе delete'ов, со схемами использования ошибок программистов для всяких злобных дел.

STL. Итераторы, например, вектора становятся невалидными после изменения этого вектора.

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

Цитата из поста Пташека:
"Я - специалист по безопасности, которому платят, чтобы проискивать исходники самых крупных и известных C++ продуктов и, проблема в том, что я продолжаю находить ошибки. Просто знать как надо делать недостаточно."

Объявление функции или экземпляра класса?

Интересная проблема из переписки. Есть код вида:

class CFoo
{
public:
    CFoo(int i)
    { 
      cout<<"CFoo::CFoo(int i)"<<endl; 
    }

    CFoo() 
    {
      cout<<"CFoo::CFoo()"<<endl;
    }

    void Print()
    {
       cout<<"CFoo::Print"<<endl;
    }
};


int main(int argc, char* argv[])
{
    CFoo foo1(1);
    foo1.Print(); 

    CFoo foo2;
    foo2.Print();

    CFoo foo3();
    foo3.Print(); //ошибка
}

Этот код не будет откомпилирован. На foo3.Print() компилятор скажет что-то вроде.

error: request for member `Print' in `foo3', which is of non-class
type `CFoo ()()'

Тут все дело в том, что объявление вида
T f();
распознается компилятором не как объявление экземпляра класса, а как объявление функции. (Стандарт, 8.5/8).
То есть CFoo foo3(); - это функция без параметров, возвращающая CFoo.

Чтобы таки объявить экземпляр класса надо сделать так
T f = T();

или так

T f;

Ссылки по теме:
comp.lang.c++.moderated - ambiguity resolution between function declaration and object declaration

Герб Саттер будет вести колонку в DDJ по параллелизму

Герб Саттер начал вести колонку в DDJ, посвященную параллелизму. Первая статья уже вышла, называется The Pillars of Concurrency. Посвящена тому, что когда люди говорят о параллелизме, то зачастую имеют в виду разные вещи. То есть как раз тому, с чем возникли проблемы в комментариях к посту Google, PeakStream и RapidMind.
Герб Саттер грозится, что, возможно, книжку выпустит по результатам этих статей...

Рутковска против команды Пташека

У Not a kernel guy прочитала. Джоанна Рутковска, специалист в области безопасности, написала некий руткит, который назвала Blue Pill (это из "Матрицы" название). Этот руткит позволяет получить полный контроль над Вистой, при этом его обнаружить никак нельзя. Вернее, это Джоанна утверждает, что обнаружить его никак нельзя. Есть люди, которые считают, что очень даже можно и они готовы это доказать. Их всего четверо, на них ссылаются как на "команду Пташека", потому что Томас Пташек у них вроде как за главного. Они предложили установить Blue Pill на один из двух компьютеров. Команда Пташека напишет детектор, который обнаружит на какой из них установлен Blue Pill. Джоанна вроде как этот вызов приняла, но с оговорками. Некоторые оговорки нормальные - она хочет, чтобы в эксперименте участвовали не две машины, а пять. Это справедливо, чтобы эксперимент был показательным двух машин мало, там угадать легко. Но кроме этого она хочет много денег. В итоге она сейчас с командой Пташека препирается. Чем дело кончится непонятно, но народ оживился, ибо мероприятие может получиться веселое.

Напоследок куча ссылок:
Rutkowska Faces 'Blue Pill' Rootkit Challenge - обсуждение происходящего на Слэшдоте

invisible things - блог стартапа Джоанны. Пока только она туда и пишет


Rutkowska on Cheating Physical Memory Acquisition: Details

Joanna’s Shocking Confession: There Exists Some Amount Of Money For Which I Would Agree To See BluePill Detected By Lawson, Ferrie, Dai Zovi and Ptacek.

Five Hackers Who Left a Mark on 2006

Книги по Форту онлайн

На Lambda the Ultimate дали ссылки на книги по Форту. Может, пригодятся кому...
Thinking Forth
Starting Forth

Видеодоклады о C++0x

Lawrence Crowl: New Features in the Next C++ Standard
Bjarne Stroustrup: C++0x Initialization Lists
Lawrence Crowl: C++ Threads
Doug Gregor:Concepts Extending C++ Templates For Generic Programming

Кстати, кое-что из C++0x обещают имплементировать уже в gcc4.3. Фичи из С++0x надо будет включать ключом -std=c++0x.

По ссылке с Sutter's Mill.

Google, PeakStream и RapidMind

После того, как Google купил PeakStream появилось много заметок в духе "Google is evil". По слухам, команда пикстримовцев была раздроблена и программисты теперь разбросаны по разным проектам. Обидно это тем, что PeakStream делал интересный продукт в области параллельных вычислений, а теперь плодами их работы смогут насладиться не все желающие, а только Google. Вскоре после приобретения сайт www.peakstreaminc.com перестал отзываться. Его осколки можно еще наковырять в гугловском кэше. Ничего конкретного про технологию я там не нашла, так общие замечания.
В качестве основного конкурента PeakStream упоминается RapidMind и там с документацией все получше. Я немного почитала про то, что делает RapidMind, предполагаю, что PeakStream делал что-то в том же духе. RapidMind'овский продукт можно бесплатно скачать и опробовать, кстати. Но я пока ограничилась только чтением статей.
Идея этого всего состоит в автомагическом распараллеливании программы. Программист пишет код, который сам, без каких либо усилий со стороны программиста, пытается распараллелиться. Может распараллелиться на многоядерном процессоре. Может на GPU - прикинется, что его данные - это текстура и будет вычисляться на GPU. RapidMind для реализации этой затеи сделал нечто, что называет "параллельный язык программирования, встроенный в C++". Хорошо это все тем, что программисту не нужно задумываться в процессе написания о том, как именно это все будет распараллелено. Но придется научиться с этим параллельным языком программирования работать, на С++ он не похож. Работает это все с обычными C++ компиляторами.
Вообще интересно, насколько это удобно в работе и получит ли оно массовое распространение.

Заметка про первый язык программирования Plankalkül

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

Updated 26.06.2007: В комментариях справедливо заметили, что эта статья в Википедии есть в русском переводе: Планкалкюль

Сравнение C++/CORBA, Erlang и GdH

По ссылке с Lambda the Ultimate нашла работу Evaluating High-Level Distributed Language Constructs (.pdf). Авторы исследования переписывают куски телекоммуникационного софта и смотрят на размер результирующего кода. Меньше всего код получается на GdH (Glasgow Distributed Haskell), побольше на Erlang'е, ну а на С++ там вообще какие-то монструозные размеры.
Выводы не так очевидны. Они сами признаются, что не так-то просто оценить качество результирующего софта. Сами авторы таки считают лучшим код на Erlang'е, потому что кода получилось значительно меньше чем на С++, а GdH - это такая экспериментальная штука.
Но кроме размера кода интересно было бы узнать как этот софт дальше работал, легко ли было его развивать. Сложно оценить чистоту эксперимента - они пишут, что софт на разных языках писали разные разработчики примерно одинаковой квалификации, но квалификация штука такая, ее померить сложно. С++ обеспечивает работу на более низком уровне, это преподносится как недостаток. А что если софт нужно потюнить на низком уровне, что тут может предложить Erlang? Автоматическая сборка мусора рассматривается однозначно в плюс Erlang'у. Да, оно конечно удобно, но поскольку ее контролировать затруднительно, что если мусор начнет собираться в совершенно неподходящее время?
Так что по одному только количеству строчек кода судить нельзя. Но из того, что я слышала об Erlang'е, он действительно хорош для разработки распределенных систем.

Ссылки по теме:
Phil Trinders Publications

Семинар Supporting Search in a Multilingual World

Егор Азанов на своем блоге рекламирует семинар Supporting Search in a Multilingual World, который состоится 21-го числа в московском офисе Яндекса. Регистрация на него, насколько я поняла, свободная. Ну там по ссылке все подробности есть.

EASTL

Ссылки на EASTL я встречала в течение довольно продолжительного времени, вот наконец почитала о том, что это такое.
Electronic Arts не устраивали существующие реализации STL и они сделали свою. Вот здесь лежит ее подробное описание EASTL - Electronic Arts Standard Template Library.

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

Интерфейс в EASTL постарались сохранить по максимуму такой же как и в STL. Удалось это не всегда, аллокаторы у них несколько отличаются от STL'евских. Кроме того, в EASTL есть контейнеры и алгоритмы, которых в STL нет.

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

В конце текста приведена впечатляющая таблица сравнения производительности STL и EASTL.

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

Если будут какие-нибудь свободно доступные реализации EASTL, интересно было бы их опробовать.

Статья Evolving a language in and for the real world: C++ 1991-2006

Evolving a language in and for the real world: C++ 1991-2006 - статья Бьярна Страуструпа про развитие языка С++. Статья эта написана специально для выступления на конференции HOPL III. На нее дали ссылку на Lambda the Ultimate, после чего ее стали активно обсуждать разработчики, я уже видела много ссылок на нее. Практически все сравнивают ее с книгой D&E, Страуструп эту свою книгу тоже в статье часто вспоминает.
А сама статья очень интересная. В небольшой объем Страуструп уместил кучу самой разной информации. Например, рассказывает про STL, как он долго мучался, пытаясь придумать что-либо подобное. Про проблемы, которые возникают при попытке прикрутить к С++ автоматическую сборку мусора. Рассказывает что такое generic programming (хороший перевод на русский не знаю, увы) и метапрограммирование шаблонов (template metaprogramming). Упоминает ABI и интересный термин - "bug compatibility". Рассказывает о Java и .NET, дает примеры из C++0x и высказывает свое мнение о причинах успеха С++.
Написано хорошо, читается легко, мне очень понравилось.

Блог Mathematical paintings and sculptures

Блог Mathematical paintings and sculptures посвящен работам Эшера и его последователей. Бутылки Клейна, фракталы, невозможные фигуры и все в таком духе. Очень красиво.
Картинка оттуда:

Temperal Paradox

Patrick's Picks

Нашла по ссылке с 0xDE.

Ссылка по теме:
Замечательный художник Морис Эшер

Язык программирования LOLCODE

Свежепридуманный язык. Датируется 25 мая 2007.
Как пишет его автор, Адам Линдсэй (Adam Lindsay): "This is a love letter to very clever people who are slightly bored."
Для него уже есть какие-то интерпретаторы и компиляторы, которые я не смотрела. Подсветку для highlight.js даже уже сделали. Быстро народ работает.

Программы на LOLCODE выглядят примерно вот так:

HAI
CAN HAS STDIO?
PLZ OPEN FILE "LOLCATS.TXT"?
 AWSUM THX
  VISIBLE FILE
 O NOES
  INVISIBLE "ERROR!"
KTHXBYE

На официальном сайте есть идея сделать фреймворк какой-нибудь. Типа LOLCODE ON MONORAIL.

Как пасти котов

Как пасти котов - это известная книга по управлению программистами. Я не читала, но, говорят, хорошая. А вот одна компания идею выпаса котов использовала в своей рекламе. Очень неплохо получилось.

Нашла по ссылке с sozy.livejournal.com

Memoization

Memoization (я встречала только один перевод на русский и он ужасен - "мемоизация") - это оптимизационный прием, который подробно с примерами описан в Википедии. Буквы r там в середине нет, все правильно!
Опишу вкратце. Идея состоит в том, чтобы результат вызова функции заносить в таблицу какую-нибудь. Позже, получив те же аргументы во второй раз, можно все заново не считать, а из этой таблицы вытащить. Таблица эта - не данность, она заполняется в процессе мемоизации. В итоге получаются некоторые потери по памяти в обмен на выигрыш по скорости. При этом надо помнить, что функция функции рознь и не для каждой функции этот метод можно использовать.

Выступление The emperor's old clothes

The emperor's old clothes (.pdf) - это текст выступления Хоара. Оказывается, это выступление довольно известное, но я вот о нем только сейчас узнала. Почитала, интересно. Хоар там много рассказывает об Алголе, об ошибках, допущенных при разработке Алгол68.

Спор Таненбаума-Торвальдса (1992г)

В 1992 году, когда Линукс был еще мало известен, Таненбаум и Торвальдс поспорили в группе comp.os.minix. Все началось с того, что Таненбаум раскритиковал то, что Торвальдс сделал Линукс монолитным, ведь надо использовать микроядро, оно лучше. А Линукс отбрасывает людей в 70-е. Линус Торвальдс не мог на такое не прореагировать и, со словами "Time for some serious flamefesting!", ринулся отвечать.
Несмотря на то, что сообщения перемежаются небольшими наездами, например Таненбаум, который преподает в вузе, говорит, что он Линусу никогда бы хорошую оценку не поставил: "Be thankful you are not my student. You would not get a high grade for such a design :-) "... Так вот, несмотря на наезды, это очень познавательная дискуссия на тему проектирования операционных систем. Сейчас она еще интереснее, потому что Линукс получил широкое распространение. Поэтому особенно любопытно читать доводы Таненбаума почему Линукс - ОС уже устаревшая на момент выхода.

Ссылки по теме:
comp.os.minix LINUX is obsolete - тот самый спор
Tanenbaum-Torvalds debate - статья в Википедии
"Just for fun. Рассказ нечаянного революционера" - биография Торвальдса

Может ли main возвращать void

Вообще по Стандарту C++ функция main обязана возвращать int. Насколько мне известно, так же обстоят дела и в Стандарте С. И объявление функции main как void main формально ведет к undefined behavior. Тем не менее, main очень часто объявляют как void, особенно в синтетических примерах, код при это генерируется нормально. В принципе, объявление main как void может привести к проблемам, в частности код может получиться непортируемым.
Возвращаемый результат функции main иногда становится предметом вялых религиозных споров. Лично я чаще объявляю void main.

Ссылки по теме:
Can I write "void main()"? Страуструп в своем FAQ'e рассказывает, что объявлять main как void некорректно

У меня теперь Ajax-powered блог

Я уже очень давно хотела сделать нормальную секцию последних комментариев. Потому что долгое время у меня на блоге были не последние комментарии, а последнии комментарии к последним постам. Делалось это через хак, предложенный Блоггером. Все это было криво и неудобно.
Сейчас Блоггер модернизируют чуть ли не каждый день. В частности, появился фид комментариев, которого раньше не было. Можно перейти на новый шаблон, который обладает большими возможностями, чем старый. Вроде как там и последние комментарии довольно просто подключить. Но переходить на новый шаблон мне было лень. Поэтому я решила как-нибудь встроить комментарии из фида на страницу.
Муж дал мне свою ajax'овую рыбу и на ее основе я написала код, который вытягивает из фида комментариев последние несколько и встраивает их в sidebar. В IE оно не работает, виноват не Ajax, виноват фид комментариев.
Так что у меня появился повод написать про Ajax. Муж отказывается писать посты про Ajax, он считает что и так уже слишком много про него написано, а он знает про Ajax недостаточно (скромничает то есть). Я так не считаю, так что я напишу что знаю.
HTML страничка представляет собой набор тегов, которые браузер как-то разбирает. По итогам разбора браузер формирует так называемое DOM-дерево. DOM расшифровывается как document object model. Это дерево можно просмотреть. В FireFox это здесь: Tools->DOM Inspector. Более того, в DOM-инспекторе вы можете его поменять.
Некоторое время назад, не помню когда, появилась интересная штука с трудно произносимым названием XMLHttpRequest и мне пришлось с ней поработать году эдак в 2003. Позже она станет известна как Ajax. Расшифровывается как "Asynchronous JavaScript and XML". Если объяснять по-человечески, то это означает, что, используя язык JavaScript, вы можете откуда-нибудь запросить, скажем, XML документ. Но и это еще не все. После получения данные из этого XML'а вы можете встроить в DOM дерево. Перестраивание DOM дерева выглядит красиво, как смена страницы без перезагрузки. В 2003 это смотрелось просто волшебно, ну и сейчас тоже ничего смотрится, хотя стало уже привычным.
Итак, мне нужно запросить фид комментарив и встроить его в DOM дерево. Код того, как это делается, можно посмотреть в исходнике основной странички блога.

function createRequest(){ 
  try{
    return new XMLHttpRequest(); //создаю объект запроса
  } catch(Exception) {
    return new ActiveXObject("Msxml2.XMLHTTP"); 
    //если  создание не удалось, то это IE(<7)
    //здесь все происходит несколько иначе  
  }//try
}//createRequest

function getXML() {// функция получения XML
  //тут лежит фид комментариев
  var url = 'http://alenacpp.blogspot.com/feeds/comments/full'; 
  var request = createRequest();

  //создаю красивую картинку, которая будет веселить пользователя, 
  //пока XML не прогрузится
  //в случае быстрого соединения ее не видно
  //картинка опциональна, можно ее не добавлять вообще
  var image = document.createElement('IMG');
  image.src = "http://www.softwaremaniacs.org/Images/alenacpp/ajax-loader.gif";  

  request.onreadystatechange = function() { 
  //callback, который отрабатывает по ходу запроса
    if (request.readyState != 4) //запрос окончен
      return;
    image.parentNode.removeChild(image); //убираю красивую картинку
    if (request.status != 200) //запрос окончен без ошибок
      return;    
    //полученный XML передаю в функцию парсинга   
    parseComments(request.responseXML);     
  }//onreadystatechange
  
  //вставляю красивую картинку в DOM-дерево
  var comments = document.getElementById('LastComments');
  comments.parentNode.insertBefore(image, comments);
  
  request.open('GET', url);
  request.send('');  
}//getXML

function parseComments(xml) { 
  var comments = document.getElementById('LastComments'); 
  //это UL, к которому я буду добавлять LI элементы

  var elements = xml.getElementsByTagName('entry'); 
  //получаю элементы с нужным мне тегом
  for (var i = 0; i < elements.length && i<6; i++) {    
    var li = comments.appendChild(document.createElement('LI')); //создаю LI
    
    //создаю ссылку на комментарии
    var links = elements[i].getElementsByTagName('link');
    var link;
    for (var j = 0; j < links.length; j++) {
      var rel = links[j].getAttribute('rel');
      var type = links[j].getAttribute('type');
      
      if(rel == 'alternate' && type == 'text/html') {
        link = links[j].getAttribute('href');
        break;
      }
    }
    
    //создаю дату
    var date = elements[i].getElementsByTagName('published')[0].firstChild.nodeValue;
    var date = date.replace(/(\d+)\-(\d+)\-(\d+).*/, '$3.$2.$1');    
    
    //заполняю LI
    li.innerHTML = date+" :: "+'<a href="'+link+'" >'+elements[i].getElementsByTagName('author')[0].getElementsByTagName('name')[0].firstChild.nodeValue +'</a>';
  }//for
}//parseComments

getXML(); //функция, инициирущая загрузку XML

Если вы смотрели код главной страницы блога, то заметили, что там все слегка не так. Это потому что подлые блоггеровцы поменяли возвращаемый content-type фида комментариев после того, как я добавила этот кусок ajax'а. Пришлось слегка извратиться, изврат не работает в IE. Поэтому мне все же, наверное, придется переходить на новый шаблон.

Ссылки по теме:
Бонус - генератор красивых картинок на загрузку

Маленький спеллчекер

В статье How to Write a Spelling Corrector Питер Норвиг пишет маленький спеллчекер (21 строка на Питоне) и подробно рассказывает как он работает.
Вчера на teideal glic deisbhéalach Брайан О'Салливан написал о портировании этого кода на Хаскелл: Norvig’s spell checker and idiomatic Haskell.

Ссылки на описание архитектуры Итаниумов

На блоге Not a kernel guy приведено несколько ссылок для интересующихся архитектурой Итаниумов: Отладка кода на Itanium (IA-64).

Начато бета-тестирование декомпилятора Hex-Rays

Hex-Rays - декомпилятор, над которым работает Ильфак Гильфанов, автор дизассемблера IDA Pro. Он немного рассказывал об этом декомпиляторе на своем блоге: Decompilation gets real. Сегодня же он написал, что теперь у этого декомпилятора появилось имя и по нему уже есть небольшой мануал.
Декомпилятор не может восстанавливать исходники по бинарникам, как может показаться. Но он может генерировать неплохой код, который гораздо проще анализировать, чем то, что выдаст дизассемблер. Выглядит это вот так:


Там в комментариях вспомнили другой декомпилятор, REC. Я с ним немного знакома, я его использовала когда играла в ngsec games и мне этот REC понравился. Так вот в комментариях говорят, что Hex-Rays сильно круче. От себя добавлю, что у REC'а есть одно очень сильное преимущество - он халявный :-).

Книга "Стандарты программирования на С++"

Книга "Стандарты программирования на С++. 101 правило и рекомендация" у меня была в списке "надо прочесть". Я ее прочла, могу теперь поделиться впечатлениями.

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

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

Я ее читала в русском переводе. В целом он мне понравился, хотя перевод несколько странен. Там, например, переведены термины, которые обычно не переводятся: public inheritance переведено как "открытое наследование" вместо привычного "публичное наследование". Временами из-под русского текста хищно проглядывает текст оригинала: "Позволение вызывающему коду непосредственно работать с внутренними данными класса работает против представленной им абстракции и поддерживаемых им инвариантов."

Где купить:

"Стандарты программирования на С++" на Ozon.ru
А я в Библио-Глобусе покупала

Ссылки по теме:
Хорошие книги по С++
Хорошие книги по организации кода

Teraflops Research Chip

Teraflops Research Chip - экспериментальный чип, разработанный Интелом. Весь из себя инновационный 80-ядерный, а главное - очень быстрый, как видно из названия. На страничке Интела, посвященной этому чипу, есть описание, художественные фотографии и видеоролик.

Sergey_, спасибо за ссылку. (это уже становится доброй традицией :-) )

Пост "Золотой век русского программиста"

Пост на блоге Сергея Розовика - Золотой век русского программиста. Интересный взгляд на российский IT сектор.

Вообще очень советую этот блог почитать, меня особенно раздел "Архитектура" радует. Вот этот пост мне очень нравится: Complexity Fighting.

Делаю категории

В новой версии Блоггера появились категории и, как вы, возможно, уже заметили я начала ими пользоваться. В русской версии Блоггера они почему-то называются "ярлыками", но суть та же.

Итак, я хочу сделать минимальное количество максимально полезных категорий.
Буду делать это очень аккуратно, буду смотреть как это влияет на синдикацию в ЖЖ. Очень не хотелось бы опять весь блог туда вывалить ненароком. После некоторых раздумий я решила сделать следующие категории:
cpp - посты про С++
programming - посты по программированию, но не по С++. Я раздумывала на тем, не использовать ли два тега для С++ постов - cpp и programming. Уже несколько таких двойных постов прошло. Но затем я подумала, что это будет очень неудобно людям, которые хотят почитать о программировании, но C++ им не интересен.
fun - сюда попадает все несерьезное типа непростой жизни тараканов и кулинарных заметок
robots - редкие посты про роботов
gamedev - посты о разработке игр. Сюда же попадут посты про DirectX
books - посты о книгах
me - редкие заметки непосредственно обо мне и об этом блоге

После расстановки этих "ярлыков", я опубликую линки на фиды по каждой из категорий.

Идеи были следующие: если вы программируете на С++ и юморить вам особо некогда - подписывайтесь на cpp и, опционально, на programming.
Если вас интересует программирование, но не на C++ - тег programming ваш.
Если вам программирования и так хватает, то тег fun.
Возможны варианты вплоть до таких экзотических как: вы занимаетесь закупкой книг по программированию - тег books.

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

После категорий буду разбираться с фидами комментариев.

Мультиметоды

Что такое мультиметод обычно объясняется на одном классическом примере. Вот у нас есть иерархия неких фигур.

struct  Shape            {...};
struct  Square   : Shape {...};
struct  Triangle : Shape {...};

И надо уметь строить их пересечение.

bool    overlap( Square& a, Triangle& b) {...}
bool    overlap( Triangle& a, Square& b) {...}
bool    overlap( Shape& a, Square& b)    {...}
bool    overlap( Square& b, Shape& a)    {...}

И хочется, чтобы можно было определить функцию вроде

bool    overlap( virtual Shape& a, virtual Shape& b);

При вызове которой автомагически бы выбирался нужный из вариантов overlap.
Формальное определение этого всего: "механизм мультиметодов - механизм вызова виртуальных функций на базе более чем одного объекта".

В своей книге "Дизайн и Эволюция С++" (13.8) Страуструп рассказывает, что очень хотел бы, чтобы мультиметоды были в С++, но вот как-то не сложилось. И в С++09 тоже не сложится, похоже. Предложения по мультиметодам они задвинули куда-то далеко. Вот официальные бумаги по этим предложениям раз и два. (все примеры кода взяты оттуда, кстати)

Мультиметоды можно сделать с использованием RTTI и dynamic_cast'ов. Например вот так: Multiple Dispatch. A new approach using templates and RTTI. Там не все так просто, потому что хочется, чтобы не нужно было делать двойную работу и чтобы не нужно было переписывать куски кода в случае появления новых фигур.

Можно обойтись без RTTI и dynamic_cast'ов. Например как здесь: MultiMethods in C++: Finding a complete solution. Код получается довольно тяжелый. По мне так лучше с RTTI.

Про мультиметоды много и загрузочно можно почитать у Александреску в "Современном проектирование на С++". Глава 11. Она так и называется "Мультиметоды".

Ссылки по теме:
Multiple dispatch - статья в Википедии

Fotowoosh - трехмерное изображение по фотографии

Статья A New Dimension for Your Photos. Web service Fotowoosh wants to be the Flickr of 3-D рассказывает о новом веб-сервисе Fotowoosh. Этот веб-сервис есть результат исследований, проводившихся в университете Карнеги Мэллон (Carnegie Mellon University). Народ там научился генерировать трехмерные изображения по фотографии. Нужна только одна фотография, обратите внимание. С мая месяца обещают запустить бета-версию, на сайте есть подписка для желающих. Пока же можно посмотреть ролик с демонстрацией возможностей и получить готовые модели с их тестовых фотографий. Ролик есть на основной странице, но у меня он глючил и притормаживал, поэтому я скачивала авишки вот отсюда.

Результат выдают в формате VRML, хотят еще и флэш сделать. Они туда еще собираются анимацию добавить. Ну чтобы пешеходы бегали, машины ездили.

Детальные рассказы о том как это работает можно найти здесь.

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

Sergey_, спасибо за ссылку.

Статья Джоэла Спольски Recruiting the Top 1 Percent

В статье Recruiting the Top 1 Percent Джоэл Спольски подробно рассказывает о том как им удается нанять лучших разработчиков.
На самом деле он об этом рассказывает уже давно на своем сайте. Но тут все очень удобно собрано в одну статью. Основные мысли такие: нанять лучших уже на этапе обучения в колледже. При найме обращаться с людьми очень-очень вежливо, даже с теми, которые не подходят, и тем самым создать хорошую репутацию компании.
Репутация - большое дело, кстати. Вокруг компаний с плохой репутацией с течением времени создается вакуум, потом HR-менеджеры таких компаний не могут никого нанять и недоумевают "где все?".

Перехват Ван Эйка для жидкокристаллических мониторов

В пятницу на NewScientist появилась статья Seeing through walls, в которой рассказывается о том, что Маркусу Куну, исследователю из Кэмбриджского Университета, удалось осуществить перехват Ван Эйка для жидкокристаллических мониторов. Сегодня об этом рассказал Хабр.

На слэшдоте говорят, что это совсем не новость, этот опыт Кун поставил еще в 2004 году. При этом ссылаются на его работу Electromagnetic Eavesdropping Risks of Flat-Panel Displays(.pdf).

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

В заключание куча ссылок.
Security Limits for Compromising Emanations(.pdf) - еще одна работа Куна
A Trial of the Interception of Display Image using Emanation of Electromagnetic Wave - исследования японцев все на ту же тему
Optical Emission Security – Frequently Asked Questions - FAQ все того же Куна
12 вопросов о корректных измерениях побочных электромагнитных излучений - русскоязычная статья о перехвате электромагнитых излучений
van Eck phreaking - страничка в Википедии
Electromagnetic Radiation from Video Display Units: An Eavesdropping Risk? - статья того самого Ван Эйка с красивыми схемами и пояснениями как оно работает

Спасибо Maniac'у за ссылку

Несколько интервью с идолами параллельного программирования

На блоге Thinking Parallel последнее время пубиковалась серия интервью с людьми, известными в мире параллельного программирования.

Interviewing the Parallel Programming Idols - пост с ссылками на все интервью и список вопросов

Чтобы никуда не ходить, не искать - все интервью списком.

• Джо Армстронг об Эрланге
  
• Уильям Гопп об MPI
  
• Санжив Шах об OpenMP
  
• Дэвид Бутенхоф о POSIX'овых потоках
  
• Джо Даффи о .NET-Threads. У него еще есть блог: Generalities & Details: Adventures in the High-tech Underbelly
  

Квантовый компьютер Орион. Что это было?

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

Квантовые компьютеры состоят из кубитов, подробнее об этом можно почитать в Википедии. До настоящего времени были разработки, которые представляли лишь теоретический интерес, но, увы, не удавалось сделать ничего практически полезного. Более-менее удавалось заставить работать системы из 12 кубитов максимум. Построить такую систему - это лишь одна из проблем. Надо уметь квантовый компьютер как-то программировать и считывать информацию. Да, работают квантовые компьютеры при очень низких температурах. Поэтому к нему придется поставлять еще и большой холодильник. Это может расстроить пользователей. Вот здесь есть упоминание о разработках IBM в этой области: P=NP and other trivia.

Тут появляется компания D-Wave, которая говорит, что они построили квантовый компьютер из 16 кубитов, который годится для коммерческого использования. Называется он Орион и умеет решать паззл Судоку. Решение паззла можно лицезреть на YouTube.


Еще, говорят они, у нас все классно масштабируется. И в этом году они представят систему из 512 кубитов. А к концу 2008 из 1024.
Научная общественность до сих пор пребывает в легком шоке после таких заявлений.

Для охлаждения у них используется криогенная установка от Leiden Cryogenics. "У нас таких три штуки". Охлаждается все до 0.005K.

Схема процессора, использовавшегося во время демонстрации Ориона

Кроме видео с решением паззла на YouTube есть еще несколько. Например:
D:Wave's Dr. Geordie Rose
Quantum Computer "Running"

Дальше народ пытается понять, а что это вообще было.

На слэшдоте родились огромные флеймы.
Quantum Computer Demoed, Plays Sudoku
Scientists Dubious of Quantum Computing Claims

Специалист по квантовым компьютерам, а также известный блоггер Скотт Ааронсон публикует The Orion Quantum Computer Anti-Hype FAQ, на который потом часто ссылаются и в прессе, и в Интернете, когда говорят, почему история с Орионом выглядит подозрительно, мягко говоря.
Скотт Ааронсон вообще известен тем, что прямо говорит то, что думает. Например, на его блоге раскрыта тема хм, хм... biting vaginas.

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

9 марта NASA заявляет, что причастно к разработке Ориона, что вызывает новую волну недоумения на слэшдоте.
NASA Backs Quantum Computing Claim

Кроме введение в крайнее недоумения ученых, они получили еще один результат. Они привлекли 45 миллионов долларов инвестиций.
Если это все гон, то непонятно чего они добиваются? Ну да, получат кучу инвестиций и что? Более того, вся их деятельность говорит о том, что они действитель упорно пытаются построить квантовый компьютер. Я сужу по официальному сайту и блогу одного из их топов: rose.blog.

Как они это все пытаются программировать я не нашла. Но я пошла и посмотрела вакансии у них на сайте. Вот список технологий из всех вакансий
COMMON LISP, Linux
J2EE, Spring, or Rails
XML, SOAP, XML-RPC
Python, Ruby, PHP, Groovy
Знание С идет в плюс. С++ не упоминается.

Ну что, ждем конца 2008...

Ссылки по теме:
Q&A: D-Wave's Geordie Rose - статья и интервью в Technology Review

Scientists Dubious of Quantum Claims - статья в International Business Times

NP-complete Problems and Physical Reality (.pdf) - статья Скотта Ааронсона

The Quantum Pontiff - блог специалиста по квантовым вычислениям, который в нескольких постах высказывает свое мнение о D-Wave