Тег ‘программирование’

Скажите, а с ARM все действительно так плохо?

В одном прожекте возникла необходимость беспроводной передачи неприличного количества данных с АЦП. Даже в самых оптимистичных сценариях получалось, что придется гнать без проводов поток данных порядка 150 кбит/с. Немного? Но при таком потоке “затыкаются” все легкодоступные радиоудлинители UART – неважно, какой там у них радиоинтерфейс – WiFi, Bluetooth, или что-то еще. Более того, большинству из них недоступна скорость выше 115200 бод, что “отсекает” их еще на этапе ознакомления с ТТХ.

В поисках какого-то более подходящего решения набрел на микроконтролер CC3200 производства Texas Instruments. Что мне понравилось? По пунктам:

- ядро Cortex-M4 (хотелось бы, конечно, Cortex-M4F, но и это сойдет);
- встроенный WiFi, по отзывам – действительно быстрый;
- встроенные раздельные модули SPI и SD-host (я сначала думал, изучая примеры, что обмен с SD-картой будет идти с использованием модуля SPI, судя по назначению выводов – но нет, они там никак не связаны);
- возможность переназначать выводы утилитой Pinmux – хочешь, заводи SD-карту на эту сторону микрухи, хочешь – на другую, в общем, все офигенно.

Ну, где у нас АЦП – там хорошо бы и обработать сигнал? Благо в ядре Cortex-M4, в отличие от распространенного Cortex-M3, присутствуют команды, упрощающие цифровую обработку сигналов – например, реализацию всевозможных цифровых фильтров. Но на этом этапе начались какие-то дикие танцы с бубнами :)

Для начала – есть библиотека CMSIS, унифицированная для всех ARM реализация некоторых часто используемых функций. Особенно мне была интересна CMSIS-DSP, часть библиотеки с реализацией функций для цифровой обработки сигнала. Да, я могу написать реализацию какого-нибудь там фильтра Баттерворта или быстрого преобразования Фурье – но оптимизировать его для ARM я вряд ли буду, да и зачем это делать, когда есть готовое общепринятое решение?

Но для использования этого готового решения требуется некоторая поддержка от производителя микроконтролера – и здесь все становится просто ужасно. У Texas Instruments используется своя среда разработки (на основе Eclipse) и свой же компилятор. Может, имей я больше опыта программирования под ARM, я бы настроил что-то более распространенное, но для начала я просто следовал пунктам из Quick Start Guide.

Так вот, основное преимущество Cortex-M4 над Cortex-M3 – поддержка “DSP instruction set” – вообще никак не афишируется производителем в случае CC3200. Да, есть “патч” для одной из относительно старых версий CMSIS, выпущенный Texas Instruments несколько лет назад – но применимость его в случае CC3200 не озвучивается (и действительно, если “втупую” применить этот “патч”, ничего не выйдет). На просторах ютуба нашлось вот такое видео:

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

В конечном итоге CMSIS-DSP я собрал (откомпилированная библиотека из дистрибутива с компилятором TI не очень дружит) – хотя, конечно, некоторые вопросы остались. И главный из них – в заголовке. Неужели любой шаг в сторону от любовно подобранных примеров из SDK превращается в вот такой забег по граблям под руководством индусов?

Гугл, мать его

А что такое замечательное сделали в Android Studio, что она еле ворочается на относительно современном ноутбуке? Eclipse, например, в разы быстрее.

Math Toolkit for Real-Time Development

Прочитал совершенно замечательную книжку Jack Crenshaw “Math Toolkit for Real-Time Development”. Хоть она и предназначена в первую очередь для программистов “встраиваемых систем” – читал с большим удовольствием. А почему? А просто потому, что она в первую очередь – про математику, а не про программирование.

Любой относительно нормальный программист почти не задумывается над тем, как реализованы функции из “стандартной” математической библиотеки. Крайне нечасто возникают и задачи, где надо как-то учитывать, скажем, ограниченную точность чисел с плавающей запятой. Во вводных курсах программирования такие вещи практически никогда не рассматривают, а если и рассматривают – то неправильно. Например, я был в свое время очень удивлен, когда узнал, что некоторые вполне себе профессиональные программисты не имеют никакого представления об IEEE 754, и искренне считают, что вещественные числа в Delphi ведут себя так же, как вещественные числа в школьной математике.

Почему речь идет именно про “встраиваемые системы”? Книжка написана в 2000 году, задолго до того, как появилось представление об Internet of Things – и встраиваемые системы оставались последним местом, где жила всякая экзотика типа восьми- и шестнадцатибитных процессоров. Сейчас это уже немного не так, всякие PIC и AVR в более-менее серьезных местах найти уже трудно, а даже самой простенькой техникой рулят микроконтроллеры, которые по своим характеристикам уже вплотную подбираются к моему первому компьютеру (и заметьте – начинал я отнюдь не со “Спектрума”, я еще не настолько стар!). В общем, о практическом применении этой книжки можно и поспорить.

В общем, будем считать, что эта книга со временем все больше и больше приближается к “чистой”, то есть совершенно бесполезной, математике. Глобально в ней рассматриваются две темы – реализация некоторых “математических” функций, обычно входящих в стандартную библиотеку, и некоторые численные методы – дифференцирование, интегрирование и решение задачи Коши для дифференциальных уравнений. Первая из них возникала в мехматовском “Программировании и работе на ЭВМ”, вторая – в том или ином виде присутствовала в течение всех четырех лет, что на мехмате читается курс околокомпьютерных наук (речь о 2005-2010 годах, сейчас что-то немного поменялось) – но в целом я бы отнес это к второму семестру.

Что можно сказать про первую тему? Да, писать собственные синусы с косинусами приходится немногим. Но очень и очень немногие при необходимости смогут сделать это правильно. Из “остаточных знаний” второго семестра я смог бы навскидку назвать лишь пару-тройку из тех “подводных камней”, что упоминаются в книге. О некоторых вещах речь вообще не заходила ни разу и они оказались для меня сюрпризом. Более того, даже для сравнительно простой задачи – вычисления квадратного корня – приводится несколько алгоритмов, отличающихся требованиями по точности, скорости, наличию или отсутствию математического сопроцессора. Если вам вдруг захочется реализовать вычисление квадратного корня на каком-нибудь AVR – есть и “целочисленный” алгоритм.

Один из шедевров, не побоюсь этого слова, приведенных в книге – функция bitlog(), приближенно вычисляющая логарифм. Вместе с ее кодом – который можно смело использовать для любых Obfuscated C Contest – приводится подробнейшее описание, как и почему она работает.

/* Bitlog function
*
* Invented by Tom Lehman at Invivo Research, Inc.,
* ca. 1990
*
* Gives an integer analog of the log function
* For large x,
*
* B(x) = 8*(log(base 2)(x) – 1)
*/
short bitlog(unsigned long n)
{
    short b;
    // shorten computation for small numbers
    if(n <= 8)
        return (short)(2 * n);
    // find the highest non-zero bit
    b=31;
    while((b > 2) && ((long)n > 0))
    {
        --b;
        n <<= 1;
    }
    n &= 0x70000000;
    n >>= 28;
    cout << b << ' ' << n << endl;
    return (short)n + 8 * (b - 1);
}

Впечатляет? А в книге описано, как подобные алгоритмы разрабатывать, с оценками точности и так далее.

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

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

Что очень важно - такого рода "элементарного" учебника на русском языке я припомнить не могу. Учебники по численным методам рассчитаны на студентов где-то 4 курса и обычно требуют неплохой математической подготовки вместе с серьезным "погружением" в предмет. Книги "для программистов" обходят численные методы стороной - тема эта все-таки довольно специфическая. Ценность же этой книги - в том, что в ней рассматриваются некоторые неочевидные приемы, о которых, как я помню, действительно упоминалось на семинарах - но они сохранились у меня в лучшем случае в виде "остаточных знаний", а в худшем - "вроде это было вот в той книжке" (а по численным методам пришлось почитать довольно много чего интересного, спасибо И. С. Григорьеву и его отношению к прогульщикам-халявщикам).

В общем, мне понравилось.

Хочется напомнить

Московский районный суд г. Калининграда подкинул повод перечитать Falsehoods Programmers Believe About Names. Кто не читал – рекомендую.

Нужно ли программисту высшее образование

Нашел весьма забавные “десять мнений”:

http://eax.me/education/

Половина авторов не знает, что такое “высшее образование”, примерно такое же количество не может толком сформулировать, кто же такой “программист”. Весьма показательно.

Таджикоанглийский

jamshoot-telegram

Один ли я, читая Release Notes на этой картинке, вспоминаю Равшана и Джамшута?

А вот вопросик

А никто не пользовался хостингами SVN+Trac? Например, что скажете про http://www.mysvn.ru/?

GitHub не хочу “по религиозным соображениям”.

Опенсорс и правила хорошего тона

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

- отсутствие документации, даже более-менее полного Javadoc, не говоря уже о руководстве по использованию
- местами странная архитектура
- много кажущихся излишними функций
- полумертвое состояние проекта на github (коммит раз в месяц – это же мало, да?)

Если вам захочется использовать эту штуку в своем проекте – то как только ваши запросы чуть-чуть выйдут за рамки “стандартных”, вам придется лезть в код библиотеки в надежде хоть что-то понять. Лично я справился со своими хотелками, лишь скачав исходники и внеся в них довольно приличные правки.

Короче говоря, сейчас у меня имеется полноценный форк чужой библиотеки. Мне откровенно не нравится ее теперешнее состояние, внутренний перфекционист требует переделывать ее чуть менее, чем полностью. Лицензия там довольно либеральная, позволяющая вытворять с библиотекой что угодно. Но я очень сомневаюсь, что смогу со своими представлениями о том, что должно быть, вписаться в сложившийся вокруг osmdroid “узкий круг ограниченных людей”. Более того, у меня нет времени на то, чтобы отстаивать свою точку зрения (а она у меня явно отличается от “официальной”) в спорах с нынешними разработчиками. А с другой стороны – я сомневаюсь, что у меня хватит времени на поддержание и доведение этого форка до приличного вида.

В общем, как положено поступать в таких случаях?

Я упоролся? Да, я упоролся!

Пытался тут найти способ прикрутить к osmdroid “другую” картографическую проекцию – а так как никакой документации, кроме неполного Javadoc и пары кривых примеров на эту библиотеку в принципе нет, то пришлось читать исходники. И чем дальше, тем больше я убеждался в том, что проще подправить пару-тройку мест в osmdroid, чем заниматься всякой ерундой типа “subclass MapView and return your own custom projection in getProjection()”.

Короче говоря, для того, чтобы решить маленькую и простую задачу – показать в одном приложении карты Bing, OSM, Google и Яндекс – причем уже довольно удовлетворительно решенную, я принимаюсь ковыряться в недрах картографической библиотеки. И чем дальше, тем больше возникают мысли типа “да тут всю систему менять надо!”.

Интересно, дойдет ли до форка Android?

Про карты в интернете

Пытаюсь соорудить приложение на Android, отображающее много разных карт :) Первая попытка – взять WebView, а в него запихать Leaflet, оказалась довольно геморной и неудачной – карта подтормаживала, а при неудачном стечении обстоятельств – выделялась в этом WebView и напрочь отказывалась работать. Более того, оценив размер геморроя, который возникнет, если я захочу, к примеру, перемещать карту вслед за GPS-координатами мобильника, я решил поискать другие решения. Да и вообще, слово Turducken в программировании считается ругательным (а в кулинарии – вовсе нет).

Правда, на Leaflet можно было работать с целой тучей карт. Загибайте пальцы – Bing (схема и спутник), Google (схема и спутник), куча вариаций OSM, ArcGIS (спутник, схема и карта высот), 2ГИС и, по моему опыту, один из лучших вариантов – три карты Яндекса – схема, спутник и “народная”, одна из наиболее точных и удобных. Но недостатки, к сожалению, перевесили :(

На текущий момент я остановился на osmdroid (если наркоманский github все же прикроют – то что-то осталось на Google Code). Так как OSM – штука довольно популярная, то довольно легко удалось запихнуть туда все карты из перечисленных, кроме Яндекса (умники, которые сейчас начнут рассказывать о лицензионных соглашениях картографических сервисов, идут лесом на йух). Наш любимый поисковик решил выпендриться и использовать не сферическую проекцию Меркатора, как подавляющее большинство картографических сервисов в Интернете, а эллиптическую.

Способ “подружить” osmdroid и яндексовские карты нашелся – но работает он немного странно. Более того, разработчики osmdroid в свежих версиях использовать его не рекомендуют – так как сейчас разрабатывается механизм для поддержки произвольных картографических проекций. Впрочем, карта показывается – так что “программа-минимум” по замене Leaflet выполнена.

Но эти “дневники” малоинтересны – а надо бы вытащить на свет божий какую-нибудь гадость и с мерзостной улыбочкой спросить “Ну че?” В качестве такой гадости – рассказы трех “корпораций зла” о картографических проекциях. Итак номер первый, Microsoft и их Bing.

http://msdn.microsoft.com/en-us/library/bb259689.aspx

Очень неплохая статья, содержащая, пожалуй, главное для интересующегося темой программиста – пример кода, достаточного для работы с картами Bing.

Номер второй – Google.

https://developers.google.com/maps/documentation/javascript/maptypes?hl=ru#MapCoordinates

А тут – ни единого примера кода, так как Google на безальтернативной основе требует использовать свой API. Ну хоть представление о нумерации тайлов карты есть, спасибо и на этом.

И наконец, гигант отечественного интернета, Яндекс:

https://tech.yandex.ru/maps/doc/theory/concepts/coordinates-docpage/

Довольно бессвязный текст, содержащий чертову тучу лишней информации. Особенно радуют соседствующие выражения типа “Яндекс.Карты, как и большинство других геоинформационных сервисов, используют проекцию Меркатора” – а рядом “В отличие от некоторых других картографических сервисов, Яндекс.Карты используют эллиптическую (согласно WGS 84), а не сферическую проекцию Меркатора”. Ну и опять же – “используйте наш API”.

Ну а теперь – риторический вопрос – какая из трех “корпораций зла” построила свой бизнес на программировании, а не на продаже рекламы?

Хранить вечно

Несколько лет назад я писал гадости про “Электронный журнал” в школах. Основные претензии состояли в том, что это прекрасное изобретение удваивает работу учителя по составлению отчетности – сначала надо заполнить бумажный журнал, затем – “электронный”. Дело в том, что какой-либо “официальный” статус может иметь только бумажная версия всего этого безобразия. Более того, классные журналы хранятся в архиве в течение 75 лет – если вдруг вас угораздит потерять аттестат, то именно по ним он будет восстанавливаться.

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

Но вот я задумался – а можно ли с помощью современных “компьютерных” технологий гарантировать хранение документа в течение 75 лет, и сколько это будет стоить? Когда я представляю все связанные с этим проблемы (прежде всего организационного характера, технические более-менее решаемы) – то мне начинает казаться, что “бумага” все равно вне конкуренции.

Еще компьютерно-лингвистическое

[info]vitus_wagner пошутил, что

разницы между remote и deleted русские не понимают, используя и для того и для другого слово “удалённый”

В комментариях [info]gleb_kulikov подсказал прекрасный перевод для слова remote (во всяких там remote access и прочих вариантах употребления) – “отдаленный”. Мне кажется, что вполне неплохо, а вам?

Национальная ОС в трехмесячный срок

Пишут:

И.о. президента Украины Александр Турчинов издал указ № 449/2014 о мерах по совершенствованию формирования и реализации государственной политики в сфере информационной безопасности Украины. В тексте документа предлагается проработать вопрос о создании национальной защищенной операционной системы и национального антивирусного программного обеспечения. Также предложено создать специальные программные и технические средства защиты государственных информационных ресурсов и информационно-коммуникационных сетей. Сделать это нужно в трехмесячный срок.

Также предлагается создать национальный медиа-холдинг для подготовки качественного конкурентоспособного информационного продукта. Который будет обеспечивать распространение в мире объективных сведений об общественно-политической ситуации в Украине.

http://biz.liga.net/all/it/novosti/2741965-turchinov-rasporyadilsya-sozdat-ukrainskie-os-i-antivirus.htm

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

Ну и вдогонку – вы когда-нибудь сомневались в том, что “компьютерное пиратство” – это жупел, придуманный для защиты политических интересов США? Не сомневались? И правильно делали:

Офис Торгового представителя (ОТП) США исключил Украину из списка интеллектуальных пиратов, сообщает Министерство иностранных дел (МИД) Украины. 30 апреля ОТП США обнародовал “Специальный доклад 301″ о состоянии защиты прав интеллектуальной собственности в разных странах мира, в т.ч. в Украине. Офис Торгового представителя США решил исключить Украину из нынешнего доклада.

http://biz.liga.net/all/it/novosti/2741970-ssha-isklyuchili-ukrainu-iz-spiska-intellektualnykh-piratov.htm

Турчинов “хороший” – и его можно не наказывать за “пиратство”, Янукович был “плохим” – и Украина занимала заслуженное первое место среди стран с “неблагополучной ситуацией в сфере соблюдения прав на интеллектуальную собственность”.

Еще раз про GNU GPL

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

Например, довольно легко понять, что Кремниевая долина в Калифорнии превратилась в олицетворение передовых технологий вовсе не из-за названия, и не из-за хорошего климата, и даже не только из-за находящегося поблизости кампуса Стенфордского Университета, а, как это не странно, по гораздо более прозаическим причинам. Просто в районе Санта-Клары находилось несколько “исследовательских” структур сначала ВМС США, а затем и NASA – и “высокотехнологические инкубаторы” поначалу занимались производством всяких ништяков для американских военных и околовоенных структур.

В сущности, Кремниевая Долина – такой же “продукт” Холодной войны, как операционная система Unix, Интернет и спутниковая навигация. Все эти штуки обязаны своим рождением если не военным (в лице DARPA), то “оборонным” компаниям – а к “оборонке” что в Штатах, что у нас, можно отнести почти все “высокие технологии”. Это только потом, когда “высокие технологии” превратились в обыденность, а Холодная война закончилась, стало можно заниматься всякими “доткомами” – но не раньше.

Про Unix я вспомнил не зря – потому что с этой операционной системой связана определенная “культура” в программировании и околопрограммистских вопросах. Например, само представление об open source и традиции лицензирования программного обеспечения возникли потому, что Unix с самого начала рассматривался не как коммерческий, а как исследовательский – читай “финансируемый DARPA” – проект. Довольно неожиданным для “советского” человека оказывается то, что “оборонными” разработками в области зарождавшейся тогда Computer Science в США занимались “гражданские” исследователи, да еще и не “секретили” свои разработки – но факт остается фактом, DARPA щедро выделяла деньги в виде исследовательских грантов.

Наследие “исследовательских” традиций и “научной этики”, пришедшей из американских университетов, в мире Unix – это культура open source. Написал полезную программу, реализовал оригинальный алгоритм, разработал протокол обмена данными – поделись с коллегами. Но что характерно – это “исследовательская этика” не ограничивала возможное в будущем коммерческое использование. Собственно, наиболее ярко ее иллюстрируют те лицензии, под которыми распространялось ПО, разработанное в рамках исследовательских программ – так называемые лицензии BSD и MIT.

Нынешний open source отравлен движением Free Software Foundation под руководством сомнительного чувака Ричарда Столлмана и придуманной в рамках этого движения лицензией GNU GPL. Я уже обращал внимание на две проблемы ПО, использующего эту лицензию, которые вытекают из ее “вирусной природы” – оно с трудом “стыкуется” с ПО под “коммерческими” лицензиями, а просто поглядев на лицензированный под GPL код, разработчик сталкивается с тем, что все, что он напишет впоследствии, может оказаться “производным произведением”.

Немного поясню последнее утверждение. В Штатах уже был прецедент (я могу путаться в деталях, буду благодарен за уточнения и пруфлинки), когда человек ушел из Microsoft в организацию, занимавшуюся разработкой чего-то GNUтого, на его беду – прямого конкурента того продукта, над которым он работал в Microsoft. Последние, не будь дураками, подали в суд, утверждая, что тот видел майкрософтский код и теперь “перерабатывает” его в смысле законодательства об авторских правах. Американский суд с этими доводами согласился. Но замените здесь Microsoft на Free Software Foundation в “зеркальной” ситуации и получите совершенно мерзкую ситуацию. GNU GPL – это, по выражению Столлмана, “хак законодательства” – способ использовать всю силу закона против тех, кто делает что-то, не нравящееся Free Software Foundation. “Свободы” в ней не больше, чем в “обычном” EULA любого софтопроизводителя.

Но об этих ограничениях и несуразностях GNU General Public License мало кто задумывается – а зря. Как отмечают в статье, на которую я сослался в своей старой записи, многие авторы лицензированного под GPL кода попросту не понимают условий лицензии, ограничиваясь плохими ее пересказами. Как реагирует неискушенный автор на слово “Free” в “Free Software Foundation”? “Замечательно! Я же хотел поделиться своим кодом со всеми!” – думает он и попадает в страшную ловушку. После этого его код может быть полезен лишь авторам проектов с той же лицензией. Но об этом люди просто не подозревают, после чего рождаются вот такие перлы:

This program is written under GNU General Public License in C programming language. PLEASE NOTE THAT THIS PROGRAM VERSION DOES NOT HANDLE POTENTIALLY OCCURRING INTERRUPTIONS OF COMMUNICATION OR NETWORK CONGESTION SITUATIONS. It may stimulate those intending to write their own client program.

Самое ужасное здесь то, что эта программа – не что иное, как эталонная реализация клиента некоего сетевого протокола, и здесь “вирусная природа” GPL просто вынуждает идти на нарушение GPL. Представьте, что под GPL был бы лицензирован код наподобие такого:


int main(){
return 0;
}

Нетрудно догадаться, что после этого любая программа на C, C++ и куче других языков может быть признана “производным произведением”? Если кто-то увидел бы этот код с припиской “лицензировано под GPL”, то он мог бы забыть о работе программистом и идти в дворники (особо впечатлившиеся могут сейчас пойти помыть глаза с мылом). Аналогично и в этом случае – протокол настолько прост, что лишь посмотрев на “эталонный” клиент, и написав свой, уже можно быть уличенным в создании некошерных производных произведений.

Конечно, намерения автора довольно очевидны – но будучи в плену иллюзий о Free Software Foundation и его “великой светлой миссии”, он подложил немалую свинью всем, кто занимается разработкой любых аналогов данного ПО.

PS Лично я, если бы меня в данном случае приперли к стенке угрозами судебного разбирательства с FSF, попытался бы вывернуться описанным [info]infowatch способом в рамках отечественного законодательства.

Про слово “семафор”

Подведены, но еще не опубликованы итоги “Тотального диктанта”. Организаторы комментируют допущенные участниками орфографические ошибки:

«Чаще всего участниками допускались ошибки в словах: «гармошка», «перрон», «семафор», «палисадник» и «расхристанный». Эти ошибки связаны не столько с незнанием правил русского языка, сколько с реалиями, в которых они употребляются. Например, сейчас немного изменилась культура и формат путешествий, и если слово «семафор» постепенно уходит из речи, то и из письма тоже», – объясняет ситуацию Наталья Кошкарёва, председатель экспертной комиссии Тотального диктанта.

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

Интересно, когда железнодорожный семафор настолько превратится в музейную редкость, что юные программисты будут воспринимать это слово примерно так же, как какой-нибудь “мьютекс”, без привязки к “прототипу”?

Пара слов про heartbleed

На днях прочитал такое мнение по поводу известного бага в OpenSSL:

Yes, tell me more about how crypto should only be written in memory unsafe languages.

Мол, язык C, на котором написана OpenSSL, допускает произвольный доступ к памяти, из-за чего, собственно, и появляется возможность доступа к уже освободившейся памяти, занятой чужими данными. А вот если бы OpenSSL писали на правильном языке, не допускающем таких штук – то все было бы хорошо.

К сожалению, дело не в языке. Начну хотя бы с того, что используемые сегодня процессоры и операционные системы нельзя назвать memory-safe. Любая загруженная библиотека имеет доступ ко всей памяти процесса – и неважно, на каком языке она написана. Предлагается просто поверить в то, что реализация “правильного” языка подобных ошибок не содержит, фактически – перенести ответственность с авторов библиотеки на авторов компилятора или интерпретатора. Напоминает сказку про кашу из топора? Правда, я как-то писал про это, только в другом контексте.

На C, кстати говоря, тоже можно писать в стиле memory-safe. По большому счету это требование – лишь набор некоторых ограничений, которые можно либо соблюдать, либо нет. По большому счету, все упирается в еще одно “критическое” место – реализацию некоторых функций из стандартной библиотеки. Если мы можем предположить, что malloc() и free() реализованы корректно, то можно попробовать доказать или опровергнуть то, что то или иное обращение к памяти будет безопасно. Второй путь, “практический” – реализовать эти функции так, чтобы некорректная работа с памятью приводила к ошибкам и “падению” программы. Так сделано, например, в libc – но…

http://article.gmane.org/gmane.os.openbsd.misc/211963

Оказывается, что в OpenSSL реализованы свои функции распределения памяти, и реализованы они криво (как показывает существование этого бага). А зачем это сделано? Оказывается, на “некоторых платформах” штатные malloc() и free() работают, по мнению авторов OpenSSL, “медленно”.

После этого вы хотите поговорить о “memory-safe”? Уверен, что в таком случае талантливые разработчики OpenSSL найдут еще с десяток причин нарушить это ограничение, как бы вы не старались. Страуструп писал в своем талмуде по C++ (по поводу ключевых слов private и public):

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

То же самое можно сказать, наверное, о любых ограничениях любого языка. От “грязных хаков” может спасти лишь соответствующее к ним отношение в процессе разработки, своеобразная дисциплина разработчиков – а с этим в OpenSSL туговато. Еще раз призываю перечитать слова Тео де Раадта по ссылке выше и убедиться, что даже с тестированием у них печаль-беда:

On ALL PLATFORMS, because that option is the default, and Ted’s tests show you can’t turn it off because they haven’t tested without it in ages. <…> OpenSSL is not developed by a responsible team.

Печально, что такие безответственные люди разрабатывают одну из важнейших библиотек (и дело даже не в криптографии – скажем, даже в нынешнем виде OpenSSL вполне мог бы удовлетворять российским сертификационным требованиям для класса КС1 или даже КС2).

Слышали звон

Имел удовольствие прочитать вот такой текст:

При исправлении учтите пожалуйста сценарии использования поворота экрана, переключения оконного режима. Телефонный сафари очень любит издеваться над пользователями, а наибольший трафик на сайт идёт именно со свзяки iphone/safari 7.

Вы заметили слова “сценарии использования”? Вам ничего не показалось странным? Правильно – “поворот экрана” и “переключение оконного режима” – это не сценарии использования в их обычном понимании. Без чего не бывает настоящего сценария использования? Без цели. “Поворот экрана” и “переключение оконного режима” не служат для решения проблем пользователя, которого он ждет от разрабатываемой системы (в данном случае – сайта; естественно, в случае оконного менеджера все было бы по-другому).

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

При исправлении учтите, пожалуйста, поворот экрана и переключение оконного режима.

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

PS Кстати, вопрос на засыпку “писателям” – чем цель отличается от задачи?

Про вики, SVN и всякое управление проектами

В рамках внедрения в коллективе погромистов модных штук типа системы тикетов и контроля версий остановил свой взгляд на Trac как на веб-морде для всей этой лабуды. Пощупал, понравилось – намного лучше отдельных Media или DocuWiki, websvn и Mantis (всех возможностей которого мы никогда не использовали, а написать инструкцию по его использованию “для идиотов” вообще не представляется возможным).

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

А вообще, чем дальше, тем больше прихожу к мысли, что все легкодоступные “системы управления проектами” типа Trac или Redmine удовлетворяют моим требованиям, хотелкам и заморочкам в лучшем случае на “удовлетворительно”. Вот скажите, почему нельзя нажать в каком-нибудь Trac одну кнопочку и получить в вики страницы типа “Руководство программиста” и все остальные документы, предусмотренные ГОСТами 34 серии? Я же даже не прошу о другой кнопочке, которая распечатает эти страницы в соответствии с ГОСТами 19 серии, переплетет и отнесет в нормоконтроль :)

Нет бога, кроме 3NF, и Тед Кодд пророк ее

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

И кто-то ведь доверяет деньги этим людям, неспособным понять слова “функциональная зависимость” и “нормальная форма”.

Японский автоматический лифчик

Пишут, что японцы изобрели саморасстегивающийся по команде через Bluetooth лифчик:

http://lenta.ru/news/2014/01/27/bra/

Очевидно, что обработку данных о ЧСС, уровне гормонов и прочем состоянии нервной системы надо проводить на самом лифчике, не добавляя в систему лишнего устройства – смартфона с каким-то “приложением”, которое можно подменить. Интересно, одному ли мне пришла в голову мысль об уязвимости устройства перед злохакерами?