Полистал я тут на днях в метро широко известную в узких кругах книжицу "The Architecture of Open Source Applications" ( http://www.aosabook.org ), и решил написать мини-обзор с цитатами.

Итак, что же мы видим в аннотации?
> If you are a junior developer, and want to learn how your more experienced colleagues think, this book is the place to start. If you are an intermediate
> or senior developer, and want to see how your peers have solved hard design problems, this book can help you too.
Многообещающе, не правда ли? Посмотрим же более подробно, чему хотят нас поучить умудренные опытом мастодонты опенсорса.

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

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

/CHAPTER I/

Первая глава посвящена Asterisk — серверу компьютерной телефонии, который Марк Спенсер начал писать в 1999 году. Его компании для работы была очень нужна такая система, а денег на коммерческий продукт взять было негде, вот он и решил потратить вместо них свое время.

Одним из ключевых понятий в архитектуре Asterisk является канал — абстракция для описания связи между системой и телефонной конечной точкой (telephony endpoint). Типичный сценарий использования — создание двух каналов для коммутации двух конечных точек. При этом есть два вида соединений — generic bridge и native bridge. Второй используется, если обе конечные точки используют общий протокол; первый же является универсальным и используется во всех остальных случаях.

Так вот, перейдем к первому эпиграфу:
> The decision between generic bridging and native bridging is done by comparing the two channels when it is time to bridge them. If both channels indicate
> that they support the same native bridging method, then that will be used. Otherwise, the generic bridging method will be used.
> *To determine whether or not two channels support the same native bridging method, a simple C function pointer comparison is used.* It's certainly not the most elegant method, but
> we have not yet hit any cases where this was not sufficient for our needs.
Оригинальное решение, не правда ли?

/CHAPTER II/

Во второй главе нам расскажут про Audacity — попытку сделать-таки бесплатный звуковой редактор. Пока эта попытка не увенчалась успехом, к сожалению — даже алгоритмы, использованные в Adobe Audition, во многих случаях на порядок превосходят использованные здесь, а отсутствие возможности накладывать эффекты в реальном времени сделало меня в свое время ну очень грустной пандой, когда кто-то на полном серьезе взялся доказывать способность Audacity конкурировать с коммерческими продуктами. Dominic Mazzoni, будучи еще студентом, в 1999 году написал первую версию с целью отладки алгоритмов работы с аудио. Альтернативы у open source сообщества на тот момент не было, потому все быстро бросились "писать на простой".

Это, наверное, наиболее эпичная глава в книге. Ее можно было бы растащить на эпиграфы почти полностью, потому я не смог выбрать что-то одно. Just enjoy.
> It would be good if the architecture of Audacity had a similar guiding principle, a similar kind of discoverability. The closest we have to that is "try
> and be consistent". When adding new code, developers try to follow the style and conventions of code nearby. In practice, though, the Audacity code base
> is a mix of well-structured and less well-structured code. Rather than an overall architecture the analogy of a small city is better: there are some impressive
> buildings but you will also find run-down neighborhoods that are more like a shanty town.
Look and learn, look and learn!

> With a small team of developers, we do not have the resources to do, for example, the in-depth analysis of security loopholes that teams working on Firefox and Thunderbird do. However, we do not want Audacity to provide
> a route to bypass a firewall, so we have a rule not to have TCP/IP connections to or from Audacity at all.
"Волков бояться — в лес не ходить", — как-то говорила мне бабушка.

> Modules go a very long way to counteracting the temptation to fork a project to take it
> in a new direction. We think it's been a very important architectural change for us. We're expecting these advantages but have not seen them yet.
Тут я не смог сдержать улыбку.

> The structure of a program like Audacity clearly is not designed up front. It is something that develops over time. By and large the architecture we now
> have works well for us.
УМВР в действии, куда там этим вашим личкрафтам.

> For example, Audacity currently handles stereo and mono tracks in a special cased way. If you wanted to modify Audacity to handle surround sound you'd need to make changes in
> many classes in Audacity.
Вот так учат в университете Карнеги-Меллон, да?

Кусок главы, озаглавленный "Going Beyond Stereo: The GetLink Story" я бы советовал интересующимся прочитать прямо сейчас. Описанное там настолько фейерично, что я чуть не подавился пуэром при первом прочтении. Из-за достаточно большого объема я не стану приводить его здесь. Вкратце — звуковые каналы связаны между собой в неком подобии связного списка, и есть функция GetLink, возвращающая второй канал при работе со стереодорожкой, и NULL при работе с моно. Получить доступ к бОльшему количеству каналов нельзя *никак* — такое просто не было предусмотрено изначально. Ничего, поправить сотню вызовов в ~26 файлах — не такая уж и большая проблема. Ребята упорные, справятся. Правда есть еще плагины, которые не ждали такой подставы, но ведь это опенсорс, тут каждый сам себе разработчик, исправят со временем.

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

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

/CHAPTER III/

> for for in for; do for=for; done; echo $for

Думаю, bash в особом представлении не нуждается, потому можно сразу начать собирать эпиграфы.
> One historical problem with the shell, as Tom Duff said in his paper about rc, the Plan 9 shell, is that nobody really knows what the Bourne shell grammar
> is.
И вот всё у них так (С)

> Much of the work to recognize the end of the command substitution during the parsing stage is encapsulated into a single function (parse_comsub), which
> knows an uncomfortable amount of shell syntax and duplicates rather more of the token-reading code than is optimal. This function has to know about here
> documents, shell comments, metacharacters and word boundaries, quoting, and when reserved words are acceptable (so it knows when it's in a case statement);
> it took a while to get that right.
Что ж, и на старуху бывает проруха.

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

//Продолжу позже, если кого-то заинтересует )

#ozegzf

18 comments recommend bookmark subscribe