Про диалектический материализм и ПО для Android

Есть такая фраза, являющаяся непреложной истиной для каждого сторонника диалектического материализма — «Бытие определяет сознание». Естественно, всякие идеалисты используют противоположные вариант — «Сознание определяет бытие», после чего жестоко ругаются с материалистами.

А вот в разработке ПО, видимо, можно сформулировать аналогичную вещь: «Возможности железа определяют методику разработки ПО». Я об этом писал на примере Arduino, а вот еще пример, не менее поучительный. Недавно видел у [info]belnetmon ссылку на статью о разработке ПО для мобильной операционки Android. Что же нам в ней советуют?

Ресурсы нужно экономить.
Нужно мгновенно выдавать реакцию на действия и поддерживать обратную связь с пользователем.
Производительность приложения главная цель. Нужно постоянно в процессе разработки оптимизировать производительность, не оставляя эту работу на потом.
Нужно измерять время выполнения, протоколировать и анализировать ход выполнения приложения, узкие участки кода, возникновения событий, выделение памяти, время жизни объектов. Что не измеряется, то нельзя оптимизировать.
Избегайте создания лишних объектов.
По возможности делайте методы статичными.
Используйте прямой доступ к полям вместо методов посредников.
Используйте static final для констант.
Не используйте enum там, где достаточно обычной переменной целого типа.

Все это вытекает из возможностей «железа». Современные мобильники и КПК сравнимы по производительности с «персоналками» где-то десятилетней давности (причем очень «грубо» — например, над 24 доступными для процесса мегабайтами ОЗУ в 2000-м году посмеялись бы). Вспомним, что происходило в программировании в те далекие времена.

Бывшие паскалисты (спасибо дядьке Фаронову!) успешно освоили «программирование мышкой» в Delphi. Сишники разделились на два лагеря — первые вслед за паскалистами поклялись в вечной любви к фирме Borland и пользовались CBuilder, вторые забыли TurboC, как страшный сон, и переметнулись в стан любителей Microsoft Visual Studio 6.0. С++ использовался в варианте «C on steroids» — слова «инкапсуляция», «наследование» и «полиморфизм» до многих доходили слабо, зато «заклинания» типа TForm1.OnClick() весьма понравились. Надо ли говорить, что полноценного стандарта C++ не было реализовано нигде, библиотека STL зачастую отличалась непредсказуемым поведением (например, в книжке Б. Кернигана и Р. Пайка «Практика программирования», вышедшей в 1998 году, приводится пример, когда один из Windows-компиляторов С++ был снабжен ужасно медленной версией входящего в STL дека), да и поведение компиляторов иногда оставляло желать лучшего (кто помнит, почему не стоит писать «for(int i=0; i < N; i++)" в VC++ 6.0?). Языки программирования, отличные от C и Pascal, в нашем Отечестве не котировались (по причине неведомо кем культивируемой веры в крутость русских программистов), а в Буржундии к тому времени уже по достоинству оценили хоть и более медленные, зато более "безопасные" Java и Visual Basic. Кстати, там же, в Буржундии, как раз к 2000-му году вылезли из своих нор мамонты и динозавры - знатоки FORTRAN, поправили где надо год и отправились на заслуженный отдых, пока им в аду прогулы считают. Замечу, что "интерпретируемые" языки, с "безопасными" типами, где программисту полностью закрыт доступ к опасным возможностям, появились лишь по той причине, что буржуины всегда умели считать деньги и прекрасно понимали, что дешевле нанять десяток индусов, чем двух сишников - больше шансов получить на выходе программу, не заваливающую систему два раза в час, да и следствие из закона Мура - если ваша программа тормозит, отложите выпуск - уже было взято на вооружение. С другой стороны, "Практика программирования" Кернигана и Пайка тоже написана не на пустом месте и не потеряла актуальность в начале 2000-х (а то и сейчас, во всяком случае, многие похапешники после нее будут плакать кровавыми слезами). Несмотря на все замечательные возможности языков, очень большое внимание уделялось и производительности - часто даже в ущерб языковым возможностям (например, самописный hashmap часто оказывался существенно быстрее STL-ного, в результате чего мог считаться предпочтительнее). В общем, советы по программированию для Android лишний раз напоминают, что удобные возможности языка и среды выполнения зачастую сильно влияют на производительность программы - причем зачастую отрицательно. PS А вот более развернуто мое мнение про Arduino: http://community.livejournal.com/ru_radio_electr/759218.html?thread=12768946

А кому счетчик расхода воды нужен?

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

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

Надо ли говорить, что большинство подмосковных «управляющих компаний» слыхом не слыхивали об установке счетчиков и тарифах на водоснабжение «по счетчику»?

Про паровоз

Кстати, я нашел, почему Cortonовская игрушка с паровозиком не работает в Firefox и, наверное, Opera.

Выложил доработанную для этих браузеров и Cortona 3D Plugin (с другими не работает, но ИМХО препятствий для прикручивания, скажем, blaxxun, не имеется) версию, если у кого-то есть Firefox или Opera и желание проверить — жмите на ссылку (предварительно поставив Cortona Plugin):

http://shura.luberetsky.ru/parovoz

Нужен включенный JavaScript, но кто сейчас его выключает, кроме параноиков?

UPD Выяснилось, что в Opera работает не очень хорошо, а в Firefox и других Netscape-образных очень странно работает drag-and-drop (которым мы строим дорогу). Исправленную версию выложу вечером, а вскоре добавлю и поддержку blaxxun (только придется строить дорогу не дрыг-енд-дропом, а каким-то более другим способом).

UPD2 Выложил поправленную для Firefox версию.

Еще за VRML

Надежда отечественного геймдева [info]golergka как-то спрашивал в комментах, зачем нужны VRML-ные извращения. А я сейчас на наглядном примере покажу, зачем.

На данный момент «мейнстримом» в плане динамического контента в вебе является Adobe Flash, правда, с начала 2000-х сильно сдавший позиции в пользу более универсального Ajax. Во всяком случае, извращения тех лет, вроде «сайтов целиком на Flash», встречаются реже и реже — «изобразительные» и «технические» возможности Flash теперь реализуют с использованием HTML, CSS и Javascript.

Единственная область, где позиции Flash до сих пор сильны — это динамическая графика. Если, к примеру, текстовую «мочиловку» такого типа:

И плодть его содрыгнулыся от боли, и страшные черные птицы обклювали иго со всех сторон…
А злой волшебник Хухур достал иликрическую пилу и стал, весело хохоча, отпиливать ему ногу и отпилил ее три раза! Воистину!..
И он, хохоча, откусил ему глаз…
Злая колдунья острым ножом разрезывала плоть жертвы…
Его жилы, хохоча, хрустнули под ударом стальной дубины, и кровь толстым потоком затопила Долину Смерти…
Воистину прольется кровь, ибо да будет так!!!

…думаю, этого достаточно — все же видели игрушки типа «Бойцовского клуба», где «мочилово» представляет собой длинный лог того, кто откусил кому яйца, в общем, если такую мочиловку попытаться снабдить графикой, то придется использовать Flash — нормальное рисование в Javascript+HTML совершенно недоступно (а когда все дойдут до поддержки HTML5 и элемента Canvas — я не скажу, да и никто не скажет).

В принципе, ничего против Flash я не имею — это довольно удобное средство отображения динамически меняющихся двумерных картинок. Но вот когда речь заходит о трехмерности…

Конечно, трехмерная графика с «оперативным» рендерингом на ПК применяется уже лет 20, вспомним тот же Wolfenstein 3D или Doom. Математическая основа 3D-графики прекрасно известна, и реализация «софтверного» рендерера не должна вызывать больших проблем при использовании любого языка высокого уровня (хоть того же ECMAScript). Недостаточная производительность скриптовых языков уже лет пять как не является проблемой, в чем нас пытаются убедить «веб-программисты». Но это теория. А что мы имеем на практике? Для Flash существует десяток софтверных 3D-«движков». Как говорит про них Википедия,

Скорость работы перечисленных движков зависит от используемой версии Flash Player, но в целом пока не достаточно высока.

Естественно, верить википедии на слово не стоит, а лучше убедиться лично, что я и проделал. Думаю, [info]golergka прекрасно известна многопользовательская игра «Танки онлайн«, в 2009 году ставшая «прорывом года» в использовании Flash.

tanki

Немного поиграл в эту «техническую заслугу» отечественных флешеров. Как игра — вполне приятно, ничего против не имею. Но насчет поразительной 3D-графики — не соглашусь. Графика довольно примитивна и каким-то прорывом является лишь для браузерных игр. А достигается это просто невероятной ценой — на моей не особо «дохлой» машине загрузка процессора достигала, держитесь за стул, 60-70%. Неудивительно — уже лет 10-15 для обсчета сложных 3D-сцен применяют либо очень низкоуровневые языки (вплоть до «оптимизации» на уровне ассемблерных кодов), либо специализированные графические процессоры. Flash не имеет доступа ни к тому, ни к другому.

В общем, по уровню графики все это напомнило мне виденную еще в начале 2000-х «игрушку» с паровозиком, сделанную фирмой Parallel Graphics для демонстрации возможностей своего VRML-браузера.

parovoz

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

Для работы потребуется VRML-плагин, причем желательно — Cortona 3D Viewer. Скачать его можно на сайте производителя.

PS Не надо понимать эту запись, как «Flash говно, VRML форева». Просто мне хочется показать, что в разработке 3D-контента для веба существует не только современный мейнстрим (в виде Flash и софтверного рендера) и не только перспективные разработки (Silverlight, JavaFX), но и «хорошо забытое старое». Кстати, поддержка асинхронных запросов к серверу в VRML тоже была прописана в стандарте 1997 года (в виде функции CreateVRMLfromURL()), просто применений ей тогда не нашлось.

UPD Почему-то Parallel Graphics не любит браузеры, отличные от IE, хотя их плагин в них прекрасно работает. Видимо, срабатывают ограничения из начала 2000-х.

Ктулху фхтагн!

void Rlyeh
(int mene[], int wgah, int nagl) {
int Ia, fhtagn;
if (wgah>=nagl) return;
swap (mene,wgah,(wgah+nagl)/2);
fhtagn = wgah;
for (Ia=wgah+1; Ia<=nagl; Ia++)
if (mene[Ia]<mene[wgah])
swap (mene,++fhtagn,Ia);
swap (mene,wgah,fhtagn);
Rlyeh (mene,wgah,fhtagn-1);
Rlyeh (mene,fhtagn+1,nagl);
} // PH'NGLUI MGLW'NAFH CTHULHU!

Отсюда: http://www.bobhobbs.com/files/kr_lovecraft.html.

Make me unsee it

Приходится иногда сталкиваться в программировании с такими «костылями», что даже не знаешь, стоять или падать.

Вот, например, извращенная задачка в веб-программировании. Есть два сайта — один на ASP.NET под IIS, другой на PHP под Apache. Первый крутится по адресу, к примеру, http://webserver:80/, другой — http://webserver:8080/. Задача — на первом сайте есть ссылка, открывающая окошко со страничкой второго сайта, оттуда надо передать JavaScript-ом какие-то данные в родительское окно. Думаю, все видели вот такие «палитры», так что представить в состоянии.

Разница в том, что «палитра» расположена немного по другому адресу и может подпадать под блокировку «кроссдоменной» передачи данных. Причем самое интересное — это то, что каждый из трех популярных браузеров понимает «кроссдоменность» по-разному.

Internet Explorer всех версий вообще не делает различий между domain.com:80 и domain.com:8080. Соответственно, все работает правильно.

Firefox считает такие «домены» разными и по умолчанию блокирует передачу. Правда, спасает вот такое заклинание, произнесенное перед открытием «палитры» в родительском окне и в дочернем — до передачи данных:

document.domain = document.domain;

Смысл заклинания совершенно необъясним, поэтому «это нельзя понять, это надо запомнить».

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

Вопрос фанатам «альтернативных браузеров»: и чего же вы добились, обвиняя Microsoft и Internet Explorer во всех смертных грехах, начиная от монополизма? Похоже, только того, что в каждом из браузеров надо применять свои «костыли и подпорки», а любая программа на JavaScript начинается с разбора трех случаев.

PS К сожалению, ни прикрутить ASP.NET к Apache, ни PHP к IIS нереально — апачевский модуль для ASP.NET совершенно не хочет работать, а PHP-шная часть сайта существенно использует апачевские возможности по работе с .htaccess.

Про форматы файлов

Только наши отечественные разработчики в ответ на предложение переделать доисторический бинарный формат файла в что-то более современное на основе XML могут заявить, что потеря одного байта в XML приведет к ВСЕЛЕНСКОЙ КОТОКЛИЗЬМЕ (предположим, что враги сперли вот такую скобочку: < — и тогда мы все умрем, адин-адин-адин), а уж их-то бинарный формат от такой неприятности защищен. Ага, от потери байта медным тазом накроются все таблицы смещений в файле, и мы даже не заметим этого, потому как ихнее глючное поделие регулярно вылетает с такими ошибками.

А может, этим деятелям хочется привязать народ к своей софтине — ведь XML в определенном смысле самодокументирующийся, в отличие от. Главное — не раскрывать (всех) секретов своего глючного формата, хе-хе. Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious.

PS Все надежды жадных до денег разрабов (да-да, документация «без гарантий совместимости с последующими версиями» за бабло) перечеркивает WinHEX. А кроме того, умение с умным видом смотреть на файл в шестнадцатеричном виде вызывает неподдельное уважение у всяческих PHP-программистов, особенно если сопровождать сей процесс высказываниями: «ага, это у нас 16-битное целое» :)

Про две Кореи

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

Вывод: северо- и южнокорейская пропаганда о хорошей жизни «простого корейского народа» неотличима.

Памятник лениномедведу

Разбираюсь сейчас с одной системой построения 3D-моделей местности. Система отечественная, поэтому вместе с фонарными столбами, заводскими трубами, чахлыми деревьями и кустарниками, а также другими элементами депрессивного российского пейзажа среди стандартных элементов имеется памятник Ленину, призванный изображать одного из многочисленных гипсовых Ильичей, указывающих путь пролетариату.

lenins

За фотографии начала 30-х годов с базы Треста по изготовлению художественно-скульптурной продукции спасибо [info]dedushkin1.

Дело, конечно, не в Ильиче, тем более, что такое скульптурное произведение есть в каждом райцентре, и ни один чиновник не одобрит 3D-модель своего Кобылозадовска, если не узнает там скверик перед горадминистрацией. Просто 3D-модель памятнега совершенно замечательна в своей простоте.

Если вы думаете, что эти модели грузятся там из какого-нибудь 3DS или VRML, на худой конец, вы глубоко ошибаетесь. У советских собственная гордость, на буржуев смотрим свысока! Для моделей объектов применен собственный 3D-формат (кстати, не лишенный смысла — например, примитив «вертикальная стенка по границе объекта» позволяет рисовать очень многие архитектурные формы — от заборов до многоэтажных домов). Для объектов, лишенных стенок, предлагается примитив «знак» — две перпендикулярные вертикальные плоскости с наложенной текстурой. Так получаются замечательные елочки-березки, фонарные столбы, заводские трубы и тому подобные объекты.

Замечательное свойство «знака» состоит в том, что текстура накладывается на обе плоскости одновременно, поэтому вместо одного плоского Ильича получается нечто непонятное, показывающее путь в светлое будущее одновременно двумя руками — приблизительно так:

Preved

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

Свириденку послали

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

podtirka

Все получилось ровно так, как я и предполагал — в милиции не захотели заниматься чем-то непонятным, для проформы написали в «Яндекс», а затем «установили» отсутствие признаков состава преступления.

Кстати, обращу внимание «опытных пользователей компьютера» на то, что государственные органы (не только в России, но и в любой другой стране) — это не компьютер, и на клик мышкой по кнопке заявление они предпочтут выдать кучу объяснений, почему этого сделать нельзя. Вот замечательная фраза:

Четверть работы адвокатов по уголовным делам — представитель потерпевшего. Она сводится к принуждению правоохранительных органов выполнять свою работу. Это можно делать и самому, только научиться надо.

Отсюда делаем вывод: денег на оплату услуг адвоката у свиристенкова нет, налоги он не платит, какого хрена по первому его свистку менты должны начать носом землю рыть в поисках каких-то хакеров?

Про функциональность

Поубывав бы всех, кто вместо слова «функциональность» (например, применительно к компьютерным программам) употребляет слово «Функционал«.

Про одно маленькое извращение

Посетители интернетов «со стажем», наверное, помнят про язык VRML, появившийся еще в 1997 году и позволявший описывать трехмерные пространства в «читаемом» виде. Практически для каждого браузера существовали плагины, позволявшие встраивать окошко с 3D-контентом на HTML-страницы. Даже я в далеком 2002 году не остался в стороне от использования VRML на домашней страничке и нарисовал в нем какое-то подобие сортира или станции метро «Кузьминки» — почему-то мне очень понравилась текстура кафельной плитки в каком-то VRML-редакторе.

Почему-то совершенно незамеченной в то время осталась возможность VRML-плагинов взаимодействовать со страничкой, в которой они находятся. Web 1.0 тихо исчез, уступив место для динамических сайтов с JavaScript, DHTML и AJAX (все эти три слова означают примерно одно и то же, разница в гламурности). VRML вообще не отличался особыми красотами, анимация там была в зачаточном состоянии (ЕМНИП, делалась она средствами реализованного там же JavaScript, но писать всякие «эффекты» приходилось практически вручную), а о возможности изменения 3D-сцены по полученным откуда-то «снаружи» командам никто не задумывался.

Теперь — о своем опыте прикручивания модного AJAX к немодному VRML. Конечно, можно было бы выбрать в качестве 3D-среды более современный X3D — дальнейшее развитие VRML, но для него попросту нет приличных плагинов для браузера. Для VRML я использовал Cortona 3D.

В общем, задача состояла в следующем. Есть трехмерная сцена с «лампочками», которые могут гореть, например, красным, желтым и зеленым — например, представим себе модель перекрестка со светофорами и база данных, даже проще — регулярно обновляющийся XML-файл, в котором записано, каким цветом горит какая «лампочка». Надо, чтобы трехмерная сцена динамически изменялась, отслеживая изменения в XML-файле, и при этом не требовала никаких действий от пользователя.

Естественно, задача очень легко решается, если отказаться от использования всяких VRML-ных хитростей, а сделать все с использованием обычного HTML и AJAX. С другой стороны, можно управлять VRML-сценой через JavaScript в браузере. Почему-то эта возможность VRML используется настолько редко, что о ее существовании в рунете не упоминают, а в буржуйских интернетах удалось найти лишь перепевы курсовой работы по программированию в университе Нэпира, что находится в доброй старой Англии. Надо ли говорить о том, что про объединие AJAX и VRML не написано вообще ничего? Решается же вышеописанная задача буквально парой десятков строк кода.

Конечно, можно решить ту же задачу тысячей разных способов. Например, можно отображать трехмерные объекты с использованием Flash. Можно использовать не VRML и не V3D, а какой-нибудь гугловский O3D или даже COLLADA. Пожалуй, всерьез использовать это могут только разработчики браузерных говноигр. Кстати, графика в современных VRML-плагинах вполне «на уровне» и не уступает многим более серьезным играм. Ну что, как насчет Lineage прямо в браузере?

PS Кстати, Cortona3D не работает с примером Turtle Graphics. Там требуется совсем небольшая доработка, но раскрывать этот маленький секрет я пока не буду.

Про офферы в соцсетях

Тут мой бывший одноклассник [info]golergka продвигает идею «офферов» в играх для соцсетей. Вкратце, «оффер» — это способ заставить игроков в фермера или танчики какие-нибудь выполнять полезную работу за ЖРАТ, то есть за виртуальные ништяки. Выглядит это так: предположим, кому-то в танкофермере хочется Pzkpfw. IX Schweine, а деньги платить не хочется. Тогда истинный ариец идет на биржу этих самых офферов и находит «работу», оцененную в стоимость этого самого швайна девятого уровня. Например, с 16:00 до 18:00 10 июля 2010 года покрасить забор у станции «Выхино». Будущий Гудериан идет к станции «Выхино», ищет «работодателя», красит не один, а два забора, а за работу не получает ничего — то есть, конечно, получает вожделенный «Швайн», но вот покрашенного забора тот не стоит.

Можно с помощью «офферов» разводить лохов на покупку всякого барахла: «Только сегодня! Купите у нас универсальный патентованный держатель для яиц и получите три катка от «Тигра» совершенно бесплатно». Естественно, катки — виртуальные, а яйцедержалка и ее стоимость вполне себе реальные. В общем, идея с оплатой реальных действий электронными ценностями вполне себе неплоха. В профите остаются все — и те, кто предлагает «работу» (где вы найдете лохов, готовых вкалывать за три копейки? Только среди фермеров и танкистов), и те, кто продает виртуальные товары в играх (себестоимость свиньи — ноль целых, ноль десятых, а деньги за нее все равно перечислятся), и организатор биржи, загребающий нехилый процент со всех сделок.

Уже сейчас видно, что все это будет глючить и тормозить офферы выродятся в некоторое подобие «заработков в интернете». Предлагаю на выбор несколько вариантов использования. Первый, самый очевидный — предлагать в офферах выполнить какие-то СЕОшные действия, типа зайти на сайт и кликнуть по тыще баннеров. Оплата — заниженная минимум вдвое (а для конечного фермера, если Макс будет брать не очень большой процент, например, предписанные Торой, Библией и Кораном 50% — то вчетверо). Второй, более сложный — «перекачивание» денег из одного кармана в другой. Делается, а точнее — тырится с фейсбука, какая-нибудь игра для вконтакта. Всякие свиньи девятого уровня и прочие вундервафли предлагаются за «офферы» того же сеошного содержания. Так издержки снижаются еще вдвое. PROFIT!

PS Почему я считаю, что все это выродится в поиск «живых ботов» для SEO или спаморасылок? Просто это единственная отрасль рунетовской экономики, которая хоть как-то жизнеспособна. Да и опыт использования школьников-«манимейкеров» огромный. Разница разве в том, что школьники будут получать не вебманевские фантики, а всяких высокоуровневых свиней, мышей, тигров и пантер. Может, оно и выгоднее окажется.

Мифический Arduino-месяц

Прочитал недавно известную книгу Ф. Брукса «Мифический человеко-месяц». А сегодня в комментариях у [info]bitoniau увидел довольно распространенное мнение — мол, известная демоплата Arduino не нужна, можно собрать то же самое «ручками», то есть съездить в «Чип-и-Дейл», купить паяльник ватт на двести, припой — лучше всего ПОС-40, флюс — канифольку смрадную, текстолит гетинакс, хлорное железо, микроконтролер, горсточку бракованных деталей, набор тупых мелких сверл, затем загадить мерзким раствором пол-квартиры, взять паяльник за «не тот» конец, собрать программатор, плату с микроконтролером, потом поставить на компьютере AVRStudio, WinAVR и еще кучу всякой дряни, сжечь LPT-порт при прошивке — и все это только для того, чтобы поморгать диодиком. Мало кто сейчас следует книжке Борисова и тренируется «на кошках», то есть на выпаянных неизвестно откуда КТ315. А зря, ибо когда Борисов начинает рассказывать о цифровых микросхемах (и на этом, кстати, книжка уже почти заканчивается), «юный радиолюбитель» превращается в закоренелого паялу, а для такого запаять 24-ногое чудо враждебной техники — раз плюнуть.

Казалось бы, чего общего может быть у умещающегося в одном DIP-корпусе микроконтролера и огромной IBM System/360, занимавшей несколько шкафов и жравшей немерянное количество электроэнергии, и какое отношение книга Брукса может иметь к «единоличной» разработке программ для МК? Дело не в том, что микроконтролер близок по своим «ресурсам» к «суперкомпьютерам» прошлых лет (System/360 всяко покруче будет!). Просто в те времена еще не было замечательных линуксов, работающих на кофеварках, и программы писались на сравнительно низком (не плохом, а приближенном к «железу») уровне. А особенно верно это для операционной системы совершенно новой машины — основываясь на опыте разработки которой, Брукс и написал книгу.

Вот один только абзац:

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

Этот опыт, однако, сослужил плохую службу при программировании новой машины. Лабораторные разработки, предварительные или ранние выпуски компьютеров не работают должным образом, не работают надежно и не остаются неизменными день ото дня. <…> И хуже всего неопределенность, лишающая стимула копаться в своем коде в поисках ошибки — ее может там вовсе не быть.

Программирование для микроконтроллерных систем — в чистом виде системное программирование для «новой машины». Да, микроконтроллер — довольно хорошо изученная и документированная штука, но вот трудность вызывает сборка «первой схемы», особенно, если это схема на МК. Разве может начинающий знать, что керамический конденсатор необходимо разместить как можно ближе к корпусу микросхемы? А то, что блокировочные конденсаторы для пары микросхем вовсе не стоит заменять одним, пусть даже и с емкостью, равной суммарной? А нюансы, связанные с подключением кварца?

Непонятно, почему «светодиодная моргалка», собранная «по всем правилам», не хочет работать. Дело ли в программе, в прошивальщике, в программаторе, в схеме, в монтаже — начинающему не понять. А применительно к AVR — вспомним хотя бы о «фузах», неправильной установкой которых так легко угробить контроллер (купленный, естественно, в единственном экземпляре).

Современный программист привык к тому, что железо всегда работает нормально, именно поэтому многие, спаявшие простейшую схему на МК, так никогда и не находят «соплю» между ножками. Демоплаты как раз и решают проблему с «нестабильностью» собранного новичком в «паяльном деле» «железа». Как минимум, повышается шанс запустить первую программу на нормально работающем «железе».

Касательно Arduino — лично я не вижу ничего особо выдающегося в этой плате. Разве что какой-то набор функций (своего рода «ОС») и Bootloader — вот и все, чем эта штуковина отличается от других плат. Ну и пиар, соответственно.

Для разговора про ардуиновскую «стандартную библиотеку» хочу вновь обратиться к истории. Технологии и методы программирования развивались в тесной связи с развитием возможностей «железа». Та же Simula оказалась невостребованной в конце 60-х — для тогдашних компьютеров более естественными оказались «процедурные» языки. Приведу маленький пример.

Для не очень хорошего программиста на Java или любом другом подобном языке вполне естественно написать что-то вроде:

var s = new String();

for(var i = 0; i < 100; i++) String += i + ",";

Кое-кто может сослаться на историю маляра Шлёмы, но речь немного не об этом, тем более что класс String можно реализовать и без недостатков сишных строк. Если кто-то, подобно тому не очень хорошему программисту, не читал книжек по Java или другим языкам со "сборкой мусора", то предлагаю проследить, что же происходит в цикле. При каждой его итерации создается несколько экземпляров класса String, которые не уничтожаются сразу после окончания вычисления (как в C++), а остаются в памяти.

То, что мы не заботимся о явном выделении памяти и ее освобождении, и называется абстракцией. Нас не волнуют такие вещи, как стек, страницы памяти и прочие малопонятные вещи. Даже мусор за нами должен собрать "сборщик мусора" (кстати, тоже сделанный в Simula).

Естественно, что за возможность написать код, наподобие приведенного выше, надо чем-то расплачиваться - а именно, ресурсами выполняющей эту гадость машины. Комфорт программиста, не заботящегося о "смысле", скрытом за легко читаемой строчкой, оплачивается памятью, тактами процессора и прочими ныне почти забытыми понятиями. Именно поэтому Simula и оказалась не нужна в 60-х. А вот разработанный практически в те же годы C оказался гораздо интереснее для компьютеров с очень сильно ограниченной памятью, да и на тех же AVR широко используется.

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

Зато кому-то стало легче - не надо изучать такой непонятный RS-232, достаточно лишь написать Serial.println(15 - 10) :) А потом начинаются пляски с бубном около ООП-шных изысков, реализованных на неподходящей для этого системе.

PS Я ни в коем случае не утверждаю, что объектно-ориентированное програмирование, преобразование типов и прочие замечательные особенности соременных языков программирования - это "аццтой". Они действительно облегчают жизнь. Сборка мусора - это гораздо лучше, чем ручное управление памятью, примерно настолько же, насколько современная автоматическая коробка передач превосходит ручную. Только вот не надо пытаться присобачить "автомат" к "Жигулям" (за ссылку спасибо [info]onfall).

Ненависти псто

Писал сегодня некоторое «пояснение» к написанному мной куску программы. Пришлось немного «разъяснить» примененную в программе аппроксимацию, для чего в ворде (!), пусть даже 2007-м, была с трудом напечатана такая формула:

formula-word

Для того, чтобы напечатать эту формулу, мне понадобилось пять (!) минут — в основном ушедших на тыканье мышкой в панельку с «компонентами» формулы. Посчитайте, сколько времени займет печать такой строчки в TeX:

$$B = B_{11} \frac{x-x_2}{x_1-x_2} \frac{y-y_2}{y_1-y_2} + B_{21} \frac{x-x_2}{x_1-x_2} \frac{y-y_1}{y_2-y_1} + B_{12} \frac{x-x_1}{x_2-x_1} \frac{y-y_2}{y_1-y_2} + B_{22} \frac{x-x_1}{x_2-x_1} \frac{y-y_1}{y_2-y_1}$$

А теперь давайте обозначим дроби \frac{x-x_2}{x_1-x_2} и \frac{y-y_2}{y_1-y_2}, например, греческими буквами хи и кси. В TeX-е:

$$B = B_{11} \chi \xi + B_{21} \chi (1 - \xi) + B_{12} (1 - \chi) \xi + B_{22} (1 - \chi) (1 - \xi)$$

В ворде… В ворде предстоит долгое тыканье в меню вставки символа. Почему-то из всего греческого алфавита в «быстром доступе» находится 13 букв. Хорошо хоть, что тэта и эпсилон — в двух начертаниях. Выбор букв меня тоже удивляет.

В общем, даже это можно стерпеть. Раздражает другое. При перемещении слева направо по формуле типа x-x2 совершенно нелогично перемещается курсор. В общем-то, логика в этом есть, и я, как программист, ее понимаю. Формула просто-напросто разбита на подформулы, примерно так:

formula-tree

При нажатии курсорных клавиш происходит обход этого дерева. Фокус последовательно перемещается от левого x ко всей формуле, затем к «подформуле» из правого x и двойки, затем к правому x, затем к двойке. Если мне хочется нажать Delete, когда курсор стоит перед правым x, то удаляется не правый x, а вся подформула целиком.

Замечу, что если использовать «старые» средства ворда и сделать подчеркивание «шрифтовыми» средствами — subscript и superscript долгое время были в ворде чуть ли не единственными нормальными инструментами для ввода чего-то, похожего на формулы, то курсор будет перемещаться более логично, строго слева направо.

Мораль? Не надо в WYSIWYG-редакторе смешивать программное представление элементов с «графическим». Вопрос на засыпку: курсор стоит в последней строке таблицы, таблица представлена в памяти одномерным массивом (думаю, все представляют такой «метод» адресации — a[m*N+n]). Куда должен переместиться курсор при нажатии клавиши «вниз»?

Неправильный ответ — какая нам разница, в какой клетке какой строки стоит курсор? Просто инкрементируем индекс активной ячейки, как и в прочих случаях.

Правильный ответ один: никуда не должен перемещаться.

Правильный ответ два: в первую ячейку того же столбца таблицы.

Правильный ответ три: курсор должен переместиться наружу таблицы.

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

Конечно, порадовала (наконец-то!) удобная система стилей и заголовков. Из малозаметного пункта на перегруженной опциями панели предыдущих версий Word стили превратились в едва ли не самый заметный элемент на «ленте». Я всегда подкалывал [info]vanchez, когда тот колупался в майкрософтском редакторе с его слабыми (если не пользоваться пресловутыми стилями) возможностями по созданию всяческих оглавлений, демонстрируя ему замечательные возможности LaTeX. А ведь возможности по созданию «логической» структуры документа были еще в Word 6.0 (кто помнит такую древность?), да и в руководстве Microsoft Press по Word 7.0 были описаны.

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

Кстати, а кто до сегодняшнего дня знал о возможностях ворда по оформлению содержания? А кто пользовался?

Смотрел статистику сайта

А кто на меня ссылки на лепре дает?

http://foto.leprosorium.ru/comments/852908
http://leprosorium.ru/users/faortto/comments/
http://business.leprosorium.ru/comments/762829
http://leprosorium.ru/users/140003/comments/