This manual gathers together the key insights into API design that were discovered through many years of software development on the Qt application development framework at Trolltech (now part of Nokia). When designing and implementing a library, you should also keep other factors in mind, such as efficiency and ease of implementation, in addition to pure API considerations. And although the focus is on public APIs, there is no harm in applying the principles described here when writing application code or internal library code.[Qt!] Examples from Qt’s history are presented in blocks like this one. If you are new to Qt, you might find some of these examples obscure. Don’t hesitate to ask your colleagues for details. Also, many of the examples come from classes on which I worked, for the simple reason that I know those best. Other classes could have provided just as good examples.
Впрочем, эта система во многом построена на подходах традиционных энциклопедий и не всегда срабатывает в отношении программного обеспечения. Свободное ПО особенно подвержено атакам о "незначимости" или невозможности проверить фактическую сторону дела, поскольку в традиционных источниках, которые редакторы Википедии считают "значимыми", статьи о свободном ПО могут не публиковаться, а часто и просто отсутствуют для свободного ПО в каких-нибудь не очень популярных областях. Хорошая подборка проблем описана в предложениях по изменению критерия значимости для свободного ПО: http://en.wikipedia.org/wiki/Wikipe
Мы столкнулись с этим неожиданно в Midgard Project. Статья о Мидгарде была предложена к удалению в связи с "невозможностью найти нетривиальное упоминание во вторичных значимых источниках". То, что проект существует уже десять лет, используется или использовался в крупных внедрениях по миру (в 2005 на нем был сделан сайт электронного правительства Новой Зеландии, проработавший до 2008, он включен в программу исследований семантических сетей для интернет-проектов еврокомиссии, а с 2007 на нем работает maemo.org), не имеет значения, потому что об этом не пишут в крупных изданиях, вроде cnn.com и тому подобных.
Практически неделю мы пытались хоть что-то предложить в качестве аргументации, собирали ссылки и искали старые статьи. В конце концов, статью отстояли, "но осадок остался". Нас даже обвинили в попытках повлиять на "редакторов Википедии" в их выборе -- путем обсуждения проблемы вне Википедии. Дискуссия по поводу предложений в критерии значимости СПО тоже очень показательна.
Внутренности Франкенкамеры представлены OMAP3530, упрощенной версией чипа, который стоит в Nokia N900. На этом OMAP3 запушен GNU/Linux, собранный Eino-Ville Talvala. Эдди (как он предпочитает себя называть на американский манер) также улучшил и поддерживает драйвера для работы с сигнальным процессором ISP внутри OMAP3 (внутри OMAP3 на самом деле четыре процессора -- ARMv7, Neon, DSP и ISP). Качество драйверов от TI довольно посредственное, так что любые улучшения в этой области только приветствуются, тем более, что версия от Эдди работает на 2.6.31, самом распоследнем ядре.
Сама по себе камера напоминает Лейку где-нибудь так 50-60 лет назад. Качество получаемой картинки приблизительно соответствует Nokia N95. С этой стороны весь проект можно было бы и закрыть, особенно для обывателя (подумаешь, изобрели велосипед). На самом деле, все только тут и ( начинается )
Если вдруг вы будете в это время в Амстердаме и вас не интересуют обзорные рассказы о Rygel, Mer и адаптации приложений GNOME, добро пожаловать в аудиторию 770.
http://wiki.maemo.org/Maemo_Summit_
http://www.ifosslr.org/, в первом номере анализ настоящего хакерского дела -- Jacobsen v Katzer and Kamind Associates, о ПО для управления моделями железных дорог -- с точки зрения законов и юридических традиций США и Великобритании.
Ошибки акуммулируются тут: http://www.intellinuxwireless.org/bugzi
Интересно, что я не могу поймать kernel panic в логах, они просто не успевают записаться на диск. Максимум, что видно -- wlan0 (WE) : Wireless Event too big (342) -- только если я в среде с точкой 802.11n.
Рекомендую следить за прогрессом по вышеприведенной ссылке.
Microsoft присоединяется к разработке Samba
Как сообщили участники проекта Samba, разработчики Active Directory из Microsoft начали работу по улучшению Samba в плане совместимости с Active Directory и протоколом CIFS. В качестве первого шага они передали необходимую документацию и спецификации на протоколы.
Первые шаги в данном направлении были сделаны Microsoft на конференции Samba eXPerience 2008. Где были представлены доклады: "Model-Based Quality Assurance of the SMB2 Protocol Document" и "SMB Version 2: Scaling From Kilobits to Gigabits".
Ни заголовок новости, ни содержимое первого абзаца не отражают реальности. Во-первых, Microsoft не присоединяется к разработке Samba. Microsoft принуждена судом к открытию спецификаций на протоколы, по которым взаимодействуют между собой сервер рабочих групп и его клиенты. Документация на эти протоколы, полученная Samba Team в декабре 2007, безусловно полезна, но не надо переоценивать деятельность коммерческой компании, принужденной к этому юридической системой. То, что в дальнейшем она открыла еще больше спецификации на несвязанные темы, не означает, что компания фундаментально изменилась.
С другой стороны, в Microsoft последнее десятилетие присутствует системный кризис в разработке ключевых компонент операционной системы. В частности, долгое время отдельные элементы (стек протоколов CIFS, драйвер NTFS) не имели нормальной внутренней документации, кроме кода, приходилось прибегать к внешним сотрудникам для получения приемлемых результатов (документирование NTFS в 1998, "археология CIFS" в 2008). Сам код был плохо приспособлен к изменяющемуся состоянию внешней среды (рост применений в высоколатентных сетях, увеличение проблем с безопасностью в сетевой инфраструктуре). Поэтому к апрелю 2008, к SambaXP, Microsoft подошел с необходимостью реинжиниринга собственных процессов разработки, тестирования и проектирования сложных компонент ОС.
Встречи и дискуссии во время SambaXP и последующих встреч, одну из которых описывает Эндрю Бартлетт, идут на пользу обеим сторонам, это очевидно. Не нужно только делать из этого выводы в стиле "Microsoft присоединяется к разработке Samba". Пока единственным практическим взносом в разработку Samba от Microsoft является man-страница smbtorture в Samba4. Именно потому, что это самый важный компонент Samba для Microsoft -- в методологии тестирования CIFS взгляды Samba Team и Microsoft существенно расходятся и лидирует тут совсем не Microsoft.
Открытие документации -- это попытка убить зайцев на многих фронтах, из которых вынужденная помощь конкурентам является скорее меньшим злом, чем выигрыш от достижений. Crowd-sourcing по документации (Microsoft обязана решением суда отвечать в четко отведенное время на запросы лицензиатов WSPP, а "дыр" в документации много), перекрестное опыление в методологии тестирования ПО, методах оптимизации систем для высоколатентных соединений важны и стоят тех средств, которые они вкладывают (в июньском отчете минюста США говорилось о группе сотрудников Microsoft и контракторов более 700 человек, занятых на этом фронте).
Так что "в качестве первого шага" стоит скорее рассматривать не передачу документации, а отказ от аппеляции. И не забывать, что публичные коммерческие компании прежде всего направлены на увеличение дохода держателей своих акций, а не помощь своим конкурентам. Последнее играет важную роль до тех пор, пока помогает оптимизировать извлечение прибыли. Подтверждением может служить и практическая польза задавания вопросов через публичный форум разработчиков, где многие вопросы остаются без ответов значительно дольше, чем хотелось бы, в отличие от рассылки для сабконтракторов PFIF. Рынок IT сегодня сильно отличается от черно-белой картины, которая существует в головах подтверждающих новости на ЛОРе.
![[info]](http://l-stat.livejournal.com/img/userinfo.gif){kind=small}
bugware я играюсь с Vala и построением интерфейсов на GTK+. Vala -- это такой продвинутый макротранслятор с C#-подобного по синтаксису языка на C с активным применением GObject. Все, что не очень хорошо читалось в коде на C при программировании GTK+, преображается в Vala.( Вот маленький пример с Gtk.Builder )Внутри у нее неонка, уже упоминавшаяся Scale-out File System (SoFS), внутри которой есть еще две неонки: Samba 3 и CTDB 1.0. И вот без них слонов не было бы. :-)
Важность этого дела состоит в том, что Artistic License опирается на ту же концепцию значимых условий в авторском праве, на которой выстроены Creative Commons, GNU General Public License и некоторые другие свободные лицензии. То, что суд прямо ссылается на них в обосновании решения, позволяет разработчикам свободного ПО в рамках прецедентного законодательства США иметь хорошие шансы на положительные решения по делам об нарушении их авторских прав.
Другим важным аспектом стало разъяснение суда того, что отсутствие финансовых условий в лицензии не является разрешением не соблюдать остальные условия лицензии. Суд специально объясняет, что именно структура условий в свободной лицензии Artistic License позволяет автору организовать распространение и работу над его произведением таким образом, что автор получает доход от производных работ. То, что этот доход не выражается в финансовых терминах, не делает условия менее защищенными юридически.
Текст решения очень хорошо сформулирован. Вот типичный пример:
The clear language of the Artistic License creates conditions to protect the economic rights at issue in the granting of a public license. These conditions govern the rights to modify and distribute the computer programs and files included in the downloadable software package. The attribution and modification transparency requirements directly serve to drive traffic to the open source incubation page and to inform downstream users of the project, which is a significant economic goal of the copyright holder that the law will enforce. Through this controlled spread of information, the copyright holder gains creative collaborators to the open source project; by requiring that changes made by downstream users be visible to the copyright holder and others, the copyright holder learns about the uses for his software and gains others' knowledge that can be used to advance future software releases.
При чем здесь "любишь кататься"? Дело в том, что Якобсен организовал проект по созданию ПО для управления моделями поездов. А Катцер и его компания использовали код из проекта Якобсена для своих коммерческих продуктов (моделей поездов и систем управления ими) с нарушением условий Artistic License. Если вспомнить, что термин "хакеры" пришел из MIT 60-х годов, где студенты и сотрудники занимались моделированием железнодорожного движения и были увлечены построением сложных сетей переключения семафоров и стрелок, то историчность этого дела станет понятна...
http://www.youtube.com/v/L2SED6sewR
Рекомендую.
В третий раз за последний год перечитываю Ульриха Дреппера "Что каждый программист должен знать о памяти" и не устаю находить что-нибудь новое.
Тем, кто поедет на "Протву": до встречи! Надеюсь, что до вечера понедельника, когда я по идее должен прочитать свой доклад, мой голос не сядет окончательно и я смогу не только показать всякие забавные скринкасты, но и остаться говорящим, а не кашляющим. В связи с этим видеозаписей докладов в этом году не будет, по крайней мере, от нашей с
droggy команды.В эмптинарии выложил статью, которую писал для LVEE'08: История одной войны. Так как там комментирование отключено, можно комментировать здесь. Статья должна быть уже опубликована в июльском номере белорусских "Сетевых решений", полностью отданном материалам с LVEE.
Over 750 Microsoft employees and contingent staff are involved in work on the MCPP
technical documentation. Given the substantial overlap between the MCPP and the European
Work Group Server Protocol Program, all of these individuals devote their efforts to work that
relates to both programs or that is exclusive to the MCPP.
Of these, approximately 320 product team engineers and program managers are actively
involved in the creation and review of the technical content of the documentation. There are
over 25 full-time employees and over 50 contingent staff working as technical writers, editors,
and production technicians. Additionally, as the protocol testing effort continues, approximately
40 full-time employees and approximately 360 contingent and vendor staff work as software test
designers, test engineers, and test architects. Significant attention to and involvement in the
technical documentation and the MCPP extend through all levels of the Microsoft organization
and draw upon the resources of numerous product engineering, business, technical, and legal groups, as well as company management.
Надо сказать, что это только для исполнения решения суда о программе MCPP (результат антимонопольного разбирательства в США). По программе WSPP (результат антимонопольного разбирательства в ЕС) такой отчет пока недоступен, но врядли будет преувеличением сказать, что общее число сотрудников, привлеченных для публичного или доступного за небольшую сумму документирования программных интерфейсов между Windows сервером и клиентом, сопоставимо с размерами серьезной IT-компании в России. Даже если усреднить расходы на сотрудника где-то в районе $100К USD в год (не зарплаты, а полные расходы на содержание сотрудника), то это будет порядка $75 MUSD в год. Серьезный бюджет.
Можно ли было его избежать? Возможно, но врядли целиком -- ведь даже учитывая, что подобные вложения в разработку и поддержание в актуальном состоянии документации в 40000 страниц были бы распределены по годам, ежегодные расходы все равно составляли бы около десятка миллионов долларов. Практика последних двух месяцев, за которые я имею возможность участвовать в работе программы WSPP как контрактор PFIF (стать им может любой разработчик свободного ПО, которому требуется доступ к протоколам, включенным в WSPP), показывает, что многие документы неполны. В них отсутствуют описания некоторых полей, форматов представления структур (например, строковое представление бинарных описателей объектов в запросах в AD), зависимостей между компонентами клиент-серверных связей (например, версия клиента проверяется разными программами и на основании проверки выполняются разные операции -- запрос в AD или обращение по MS RPC, а точный перечень зависимостей не указан и не понятно, как версию кодировать). Конечно, это неудивительно, учитывая объемы и сроки, да и Microsoft не очень-то и сопротивляется: пока все запросы на восполнение пробелов отрабатываются достаточно корректно и полно.
С моей точки зрения та цена (финансовая и отвлечением ресурсов), которую сейчас Microsoft платит за антимонопольное поведение, должна послужить хорошим уроком всем, кто считает, что при создании сложных вычислительных систем можно игнорировать окружающую действительность. Ни одна компания или проект по разработке ПО не живет в вакууме, работы практически во всех случаях строятся на использовании и итеративном улучшении существовавших ранее подходов, протоколов и кода. Так что делать вид, что ты изолирован, уникален, а больше ничего вокруг не существует, обойдется себе дороже. В этом смысле открытые стандарты и протоколы служат не только полезную службу потребителям, гарантируя им возможность конкуренции среди производителей, но и являются эффективным способом экономии собственных расходов в компаниях в долгосрочной перспективе. Созидающим компаниям в IT-отрасли действительно нельзя работать, руководствуясь краткосрочными приоритетами.
I used to work for Ricoh USA in their imaging division and security is very loose, they're very naive about employee theft, that's japanese culture. Anyway, they ended up spending US500k installing security/camera system after some guy stole a 4kg industrial-grade block of gold from a plating machine.
В недавно прочитанной книге Дэна Эйрели "Предсказуемо иррациональное" отдельная глава посвящена теме офисного воровства. О том, как мы считаем некоторые поступки допустимыми, а некоторые -- аморальными. Например, стащить из офиса ручку с логотипом или напечатать себе что-то личное на офисном принтере многие не считают аморальным, а вот унести неохраняемые четыре киллограмма промышленного золота -- аморально. Вот в программировании заимствование кода без соблюдения лицензионных условий считается нарушением закона, однако во многих компаниях не обнаруживается из-за того, что за самим кодом следят программисты, которые его пишут, а не независимая "служба интеллектуального контроля". В результате, довольно часто приходится слышать о том, что "мы бы этот код уже давно открыли под свободной лицензией, но нам требуется еще время для урегулирования взаимоотношений с третьими лицами". В переводе на русский: код либо был лицензирован у другой компании, либо просто "позаимствован" из открытого источника без уточнения деталей лицензии и сама эта лицензия была нарушена, а теперь вот надо разбираться...
Конечно, случаев второго рода не так уж и много, мы будем джентельменами и поверим на слово, что вопрос в урегулировании контрактных взаимоотношений и переписывании кода. Крупные компании, наступив на подобные грабли, вводят очень жесткие ограничения для своих сотрудников. Microsoft, например, в контракте запрещает разработчикам смотреть в любой код, не написанный в Microsoft -- если только они не работают в специальных подразделениях, в которых такое ограничение снято, опять же, специальным решением -- например, в Microsoft Research.
Последний случай происходит как раз на моих глазах. На SambaXP приезжала команда из Microsoft -- менеджеры, исследователи, разработчики -- с которыми мы обсуждали вопросы документирования и тестирования протоколов SMB и SMB2. Из всех этих ребят только два человека могли официально смотреть в код -- какой угодно, не обязательно под GNU GPL -- написанный за пределами Microsoft. Понятно, что обсуждение того, где в реализациях протокола присутствуют ошибки, невозможно без нормального анализа средств тестирования, в том числе и последовательности выполняемых операций.
В результате, приходилось эзоповым языком объяснять где и что выполняется в то время, как можно было бы показать 10-20 строчек кода и закрыть вопрос навсегда. Прошло два месяца, в понедельник начинается очередная встреча, уже в Рэдмонде, но вопрос пока до конца не решен, хотя есть небольшое продвижение вперед -- будут встречи с юристами. :-)
Культурные столкновения порой принимают довольно интересные формы. Среди разработчиков свободного ПО очень популярны списки рассылок как механизм взаимодействия и ведения дискуссий. Так уж сложилось, это отличное современное средство-альтернатива традиционной письменной дискуссии, которая доминировала в академической среде предыдущие три века (переписка между учеными в XVII-XX веках была исключительно активной). Списки рассылки позволяют добиться нужного ритма работы для всех участников, потому что каждый живет в своем ритме и ускорять/замедлять его не намерен. Список рассылки позволяет отвечать на вопросы ровно в том темпе, который тебя устраивает, не говоря уже о развитых механизмах работы с почтовыми архивами.
С другой стороны, среди разработчиков, использующих MSDN, популярно использование форумов для общения с разработчиками из Microsoft. Казалось бы, довольно тривиально сделать такой форум, у которого была бы своя рассылка и пользователю MSDN было бы все равно, через что работать -- через браузер или почтовую программу. Так уж сложилось, пусть нам и трудно в это поверить, но в инфраструктуре MSDN нет вообще поддержки списков рассылок на том уровне, на котором реализована работа с форумами. И трансляторов между форумами и рассылками тоже нет. Не в этом ли кроется такое странное для пользователей рассылок требование вновь приходящих завести форумы?
Культурные столкновения проходят через нас, мы испытываем их даже, если не выезжаем зарубеж. От нас самих зависит, насколько они изменят нас и сможем ли мы изменить тех, кто несет нам "чужое". Впрочем, не стоит забывать что является целью, а что -- инструментом для ее достижения.
Prevent, ранее известный как Stanford Checker, довольно хорошо отлавливает разные ошибки вроде переполнения буферов и обращения по неправильным указателям, средний показатель ошибок там, где их на самом деле нет, составляет около 14%, это довольно низкое значение. Samba Team имеет доступ к результатам прогона Prevent по разным веткам Samba, мы даже попали в "круг второй" -- проекты, хорошо реагирующие на найденные ошибки и получающие доступ к более продвинутым функциям Prevent (11 проектов). Coverity периодически (обычно раз-два в день) запускает Prevent и делает доступным протоколы запуска участникам проекта. Например, у нас сейчас показатель 0.018 ошибок на 1000 строк кода, то есть, приблизительно одна ошибка на 56 тысяч строк кода, если я не ошибся с расчетами.
Coverity подвела итоги проекта за последние два года в отчете "Scan Open Source" (PDF, документ этот требует бесплатной регистрации на сайте Coverity). Некоторые интересные факты из него:
- за два года общее количество обнаруживаемых ошибок в проектах сократилось на 16%;
- между размером проекта и количеством ошибок существует всего-лишь линейная зависимость, а не экспоненциальная, как считалось раньше;
- усложнение функций не ведет к увеличению количества ошибок в них, несмотря на то, что так думают практически все программисты;
- наибольшее число ошибок приходится на обращения по нулевому указателю (27.95%) и утечку памяти (25.73%), а наименьшее -- на переполнение динамически распределенных буферов (0.31%) и использование негативных смещений до тестирования (0.21%).
Интересно, что на текущий момент общая база проанализированного кода в Prevent составляет около двух миллиардов уникальных строк, из которых 250 миллионов уникальных строк кода доступно под свободными лицензиями. Coverity, правда, отказывается проводить какие-либо сравнения качества между проприетарным и свободным кодом, ссылаясь на "несравнимость" в тех условиях, которые у них есть. К тому же, аудитории программистов пересекаются, поскольку многие "днем" пишут проприетарный код, а "ночью" -- свободный. Так что судить производительность доктора Джекилла и мистера Хайда Coverity не решается.