29 November 2011

Гуглиный суслик


Вот ты суслика видишь?... Нет?... А ведь он есть!

I.

Осилил на выходных пару обучающих материалов (типа такого) по новому (?) революционному (?) языку программирования Go от Google.


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

25 November 2011

Горбатого могила исправит

Давно слежу за творчеством Джона, нашего, Кармака.
Он несомненный гений, мощный математик и алгоритмист. Но при этом -- редкостный гавнокодер. 



На старости лет Джон решил наконец-то выучить что-то сложнее Си, взявшись за C++. Первый серьезный плюсовый проект Джона -- Doom 3, сырцы которого были выложены на этой неделе в публичный доступ. Я, повизгивая от злорадства, тут же кинулся их качать, дабы убедиться в своих прогнозах -- миру открылась очередная порция говнокода. 

Так оно и оказалось. 

24 November 2011

Android ICS: эй, где мой любимый USB mass storage?

В Сети поднялась волна праведного гнева -- в Galaxy Nexus, который работает на самой последней версии Android, для USB не был обнаружен режим Mass Storage. Некоторые придурки вообще устроили по этому поводу ритуальные пляски с криками "ваш Google тоже загоняет вас в ональное рабство! я же говорил!".



На самом деле, вся эта история не стоит и выеденного яйца.

Режим USB Mass Storage хорошая и удобная штука, но у нее есть один существенный недостаток -- это низкоуровневый, а значит монопольный, режим доступа к устройству. Т.е. если вы кому-то предоставляете такой доступ к накопителю, сами вы этого доступа лишаетесь. Именно поэтому в подавляющем большинстве телефонов, при активации режима UMS, они переходят в специальный режим блокировки, когда с телефоном ничего нельзя сделать. Некоторые телефоны при этом еще и выходят из GSM сети, а завершение работы в режиме UMS приводит к перезагрузке телефона. В смартфонах режим UMS обычно реализован через демонтирование накопителя. При этом, если у вас были запущены программы, которые работали с этим накопителем, в них начнут сыпаться ошибки, которые часто приводят к аварийному завершению их работы.

Теперь про Android. Изначально предполагалось, что в этой ОС создается отдельный системный раздел, используемый для установки программ и хранения их данных.

Предполагалось, что этот раздел:
а) использует специально оптимизированную и высоконадежную файловую систему (не FAT32);
б) использует специальную, более быструю и надежную, флеш память;
в) размер его, в сравнении со встроенной памятью общего назначения (которая обычно начинается от 8 Гб) относительно не велик.

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

То, что мы видим в Galaxy Nexus, есть простое и очевидное решение этого наболевшего вопроса. Вся встроенная флеш память выделена под системный раздел, вместо того, чтобы быть разбитой на два куска -- небольшой системный плюс большой общего назначения разделы. Очевидно, что это гораздо более удобный подход в каждодневном использовании. Побочный эффект такого решения -- невозможность предоставить режим UMS для этого раздела, т.к. очевидно, что система не может продолжить свою работу, демонтировав свой системный раздел для монопольного доступа по USB.
Теперь для доступа по USB к единственному (системному) разделу нам предлагают использовать Media Transfer Protocol, штуку более высокоуровневую, т.к. тут идет манипулирование не на уровне секторов устройства, а на уровне примитивов файловой системы. Фактически происходит абстрагирование клиента от деталей файловой системы, что позволяет, к примеру, давать доступ к ФС, с которой клиент вообще не умеет работать (актуально для связки Windows + Android, т.к. последний использует файловые системы, характерные для Linux, с которыми не дружат ОС от Microsoft). Другое достоинство MTP -- возможность предоставления доступа к устройству в кооперативном режиме, когда, к примеру, с накопителем работает и Android и ПК через USB одновременно.

Пользователям Windows (макоебам: ваше место в айтюнсе с айфоном) замена UMS на MTP не несет вообще никаких существенных изменений. Как копировали файлы в "проводнике", так и будут продолжать копировать. Более того, юзеры продвинутые тоже не пострадают, потому что, например, MTP плагин существует для того же Total Commander'а. Как по мне, при наличии быстрого Wi-Fi куда как проще кидать файлы с его помощью; уверен, для Android софта для подобных целей есть воз и маленькая тележка.
По скорости работы между UMS и MTP каких-то существенных различий быть не должно. Более, вполне возможны реализации, когда MTP работает быстрее.

Крики о "закручивании гаек" -- истерика не очень далеких людей.
Это по-прежнему личное дело OEM, в каком соотношении разбивать внутреннюю память, т.е. права создания выделенного системного раздела (а-ля олдскульный Android) никто никого не лишал, и мотивация здесь может быть только одна -- удобство пользователей.
И да, любимых SD карточек, с которыми можно работать по UMS, нас тоже никто не лишал.

Люди! О чем вообще весь этот сыр-бор?

Официальный комментарий по ситуации -- http://habrahabr.ru/blogs/android/133172/

зы. Кстати, в iOS тоже есть специальный системный раздел (около 2 Гб в iPad первого поколения). Но он не используется для установки приложений, тут находятся исполняемые файлы самой ОС плюс всевозможные временные файлы. Мотивация создания такого раздела -- более высокая надежность системы и корректная работа в условиях исчерпания свободного места на накопителе.

17 November 2011

C++11: революция или работа над ошибками?

"... и много много радости детишкам принесла!"
из детской песенки

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


Кликабельно до размера настольных обоев

У языка C++ сложная судьба. Страуструп поступил очень мудро, обеспечив практически полную совместимость своего детища со сверх популярным и тогда, и что более удивительно -- сейчас, Си. Если бы не этот шаг, вряд ли бы плюсы стали бы тем, чем они стали. Но это достоинство языка с каждым днем становится все большим и большим его недостатком, добавляя множество дыр и низкоуровневых проблем в язык вроде как высокоуровневый и современный. Многие до сих пор так толком и не понимаю, что С и C++ это два совершенно разных языка, на которых нужно писать совершенно по-разному. И расхожее сочетание "C/C++" это просто какой-то root of all evil. Мне сплошь и рядом попадаются люди, которые худо-бедно программировали на Си, потом за день выучили ключевое слово "class" и стали считать себя большими гуру в плюсах (к примеру, такой случай). "Специалист" подобного рода узнается слету -- у него в коде вы обязательно найдете любимый printf... Плюсы очень мощный и одновременно довольно сложный инструмент, на овладение и глубокое понимание которого требуется много времени. Без полной перестройки мозгов начать программировать на C++ после С никак не получится, и те, кто этого не понимает, серьезно портят репутацию языка. Когда Линус Торвальдс, ни черта на смыслящий в C++, начинает поучать других на тему, почему плюсы это зло, выглядит это чертовски комично.

Другая историческая проблема языка -- очень позднее принятие стандарта и мучительно долгое подтягивание компиляторов под его требования. Плюсы начали очень активно использоваться в индустрии с начала 90-х. Стандарт был принят только в 98-м. Более менее приличные компиляторы появились только в 2000-х.
В середине 90-х излишне консервативные товарищи имели все основания говорить о том, что исключения в C++ это какое-то баловство и новомодная ересь, и именно из той эпохи тянется взгляд на язык как на "си с классами", которое, к сожалению, широко используется и до сих пор.

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

16 November 2011

Ретроспектива

"Не надо придумывать ничего нового!... Читайте лучше старое. Помедленнее" 
Жванецкий

В последнее время почему-то крутится в голове цитата из Вильяма, нашего, Шекспира: "Something is rotten in the state of Denmark". Следом в цепочке шальных ассоциаций всплывает наш старый фильм, со Смоктуновским в главной роли. Картина такая очень мрачная, средневековая... Вспомнил, что когда-то писал обзор для блога, решил попробовать его найти, освежить в памяти. 

CD-RIPer в жж? Я знал его...

В жж поиска нет. Единственный способ поиска -- через Яндекс, но хитрожопый поисковик как-то сильно выборочно индексирует записи в блогах; судя по всему, совсем уж непопулярные записи в индекс не попадают. Итого, запрос "cd-riper гамлет" дает какую-то ерунду. Искать через функцию "архив" в жж для многолетнего блога -- застрелиться проще. Каждый раз выручает одно -- в силу полной уебищности редактора текста в жж, я всегда писал записи в специальный документ. Сначала в MsWord. Потом -- в Google Docs. В итоге, полез туда и легко нашел своего "Гамлета". Рядом была заметка на тему кризиса, поэтому появился ориентир для поиска в архиве жж -- осень 2008-го. 

Это я все к чему... Сунул я нос в документ со старыми записями для блога, начал читать, и не мог остановиться. Все-таки я тот еще сукин сын. Ну а с учетом того, что в то время аудитория у меня была с гулькин нос (непризнанный гений! таких у нас -- каждый второй в жж!), на злободневные темы я пишу редко, все больше о вечном, ну и общий уровень у меня такой, что как грит Вильянов (правда, про себя) можно не только читать, но и перечитывать, короче, решил я, прикола ради, вытащить пару записей из той эпохи. Если понравится -- можно будет повторять на регулярной основе. 

Итак, маленький кусочек ноября 2008. 


11 November 2011

The UNIX way

Один наш проект, работающий на ARM/Linux, внезапно начал вылетать с доставляющей надписью "I/O possible" во время работы со звуковой картой. 

Я не сильно большой знаток *NIX систем и Linux, специализируюсь больше на разработке кросс-платформенных решений, а тут как раз представился удобный случай повнимательнее взглянуть на знаменитые сигналы UNIX. 


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

Итак, что было обнаружено при курении man-pages.

#1. Сам подход с асинхронными вызовами в непонятно каком контексте может и был прогрессивным решением лет тридцать назад. В XXI же веке, когда без использования threads даже "хело ворлд" не напишешь, это выглядит откровенным долбоебиз архаизмом. Заводишь себе отдельный поток и ставишь в нем wait на интересующие тебя события... Правда, в Linux, по-моему, так и не добавили человеческий wait для множества разнородных объектов, но это уже детали.

09 November 2011

Про конечные автоматы

Что-то тянет меня в последнее время на поднятие градуса гиковости (с) в бложике. Гражданские, простите, постараюсь иногда про вас вспоминать!

Конечные автоматы и т.н. автоматное программирование -- вещи, с которыми программисты часто сталкиваются при решение задач лексического и синтаксического разбора, при описании поведения объектов в играх, при реализации всевозможных протоколов связи. 

По сути дела, Finite State Machine (FSM) это некий объект, у которого есть состояние, описываемое конечным множеством значений, плюс есть некое конечное множество событий, которые могут быть поданы на вход такому объекту. Самый простой пример FSM это, например, выключатель. Объект с двумя состояниями "вкл" и "выкл" и двумя событиями -- "включить" и "выключить". 

Другой простой пример -- автоматическая дверь с датчиком контроля состояния

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

04 November 2011

План захвата мира


Кликабельно. Творческая кухня -- так я для себя расписывал добавление одной фичи в существующий проект.

01 November 2011

Замес о программировании

Краткое содержание: Delphi must die, говнокодинг как признак приближающегося конца света в следующем году, Python -- давай сделаем это по-быстрому!

Ррррр!

Есть у меня такая добрая ежегодная традиция -- писать пост скорби о Delphi (вот, к примеру, прошлогодний). 


#1. Ручное управление памятью -- чума XXI века. 
Языки без GC или хотя бы RAII давно пора отправить на заслуженный отдых. 
В упор не понимаю людей, которые после богатого плюсового опыта дауншифтятся обратно на си. 
И еще. Кэп утверждает, что вводить исключения в язык без GC/RAII может только человек с крайне специфическим чувством юмора. Try. Finally.