Leave the Web Alone

“Сенсационный” Opera Unite даже в моём телефоне живёт уже с год - с функционально аналогичными возможностями обмена сообщениями, доступа различного уровня к файлам, контактам и даже периферии (камере) и т.д.; и путь посетителя к сайту тоже проходит через промежуточный сервер Opera Nokia.

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

Руль в багажнике

Популярнейший сервис Twitter показывает мне это сообщение уже около года:

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

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

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

Прекрасный новый мир

Во-вторых, движение мышью — подвести, нажать, передвинуть, отпустить — не повторяет никакого моторного навыка из реального мира, связанного с листанием; это тоже плохо.

За последнее время несколько раз в разных ситуациях столкнулся с этим утверждением - мол, информационная среда должна быть привычной, повторять объекты из реального мира. Но что такое "реальный мир", когда действительно массовой информатизации уже всяко больше десяти лет?

Например, я лишь с трудом могу вспомнить, когда я в последний раз читал бумажную книгу (и каждый раз, когда всё-таки приходится, надеюсь, что не придётся больше никогда). Соответственно, описанная выше необходимость листать страницы меня изрядно раздражает. То же самое и с другими общими для современных интерфейсов понятиями, например, "рабочим столом" - если бы "в реальной жизни" у меня была возможность обходиться без поверхности, куда сложены все используемые предметы, если бы я точно так же, как и в электронной среде, мог бы достать любой предмет из любого шкафа в любой комнате любого здания за пару секунд, вспомнив его имя, тип или содержимое, стол был бы нужен только как подпорка под компьютер (да и та со временем, хочется надеяться, перестанет быть нужной).

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

Решение со слайдером по ссылке действительно, впрочем, неудобное, но по другой причине.

Слон на кита налезет

Прошло уже довольно много времени, а я так и не понял, почему Wolfram Alpha с поразительной настойчивостью все сравнивают с Google. Строго говоря, WA ищет не в web, а в собственной “базе знаний”, источники данных которой, насколько я понял, хоть и многочисленны, но вполне детерменированы и типизированы - что принципиально отличает задачу “сервиса-знатока” от задачи поисковика, работающего с информацией, про которую ничего заранее не известно (и установление её релевантности – главная часть этой задачи).

В интерпретации запросов (ещё одно поле, на котором можно было бы отличиться) у WA тоже всё на поверку довольно жёстко, в рамках обескураживающе конечного языка – скажем, информация, которую можно получить по какому-либо городу, заранее предопределена (расстояния, население и т.д.). Таким образом, в зависимости от запроса можно получить разве что ту или иную её часть – и изобретательно подходить к запросу с тем, чтобы получить какие-то необычные, не предусмотренные авторами зависимости и сравнения, бессмысленно.

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

Неожиданные ассоциации

In other words, it tells them they'd better keep using a Microsoft Office license and make a particular attention to only accepting MS-ODF files as correct or face the wrath of arbitrarily corrupt files. Here Microsoft is building 8-meter tall walls and every single user becomes a Palestinian.

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

Хотя какой-то специальный умысел здесь вполне возможен, нельзя не отметить, что ровно то же самое имеет место и в “родном” для MS формате OOXML, где legacy-фрагменты содержатся в виде двоичных блоков, обрамлённых для соблюдения структуры тегами. И в этом случае умысел заподозрить гораздо сложнее, т.к. это обстоятельство принесло огромные проблемы в процессе международной стандартизации формата. Тем не менее, обеспечить всю необходимую legacy-поддержку (от которой, фактически, свободен “мир ODF”) без этого не удалось.

“А сколько надо?”

Вступительное видео:

В своё время я был очень удивлён тем, что анализ информации из неформализованных источников (СМИ) является вполне будничной задачей для современных информационных технологий.  Это оказалась вполне практическая, а не экспериментально-теоретическая область со своими флагманами в отрасли с положенным разнообразием продуктов: коробочных, “самописных” на платформе одного из нескольких наиболее популярных “движков” и даже с предложениями функционала от третьих сторон по подписке.

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

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

Languages should die

Довольно активно обсуждается призыв чаще, пользуясь аналогиями автора, провоцировать мутации в языках программирования для их же блага: http://olabini.com/blog/2009/04/languages-should-die/

Одним из недостатков аналогии как приёма является соблазн использования её “в обратную сторону”, то есть использования не для демонстрации своего предположения, а для его доказательства.

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

“Нужно доказать, что жираф – птица. Проведём аналогию: жираф длинношеий, как цапля, а цапля птица – значит, жираф умеет летать”.

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

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

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

Да, существующее сейчас положение, когда на выбор языка влияет множество “внезадачных” факторов (например, окружающая инфраструктура, в которой будет функционировать ПО, необходимость развития и поддержки, доступность на рынке специалистов в этом конкретном языке и т.д.), просуществует ещё очень долго. И все эти факторы для подавляющего большинства программых продуктов очень важны. Но если брать во внимание подобные практические бизнес-вопросы, то описанный подход “fork your language” совершенно некорректен по очевидным причинам (не хвататало только своего языка у каждой команды).

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

Sup dawg i herd u like English

В очередной подборке старых "компьютерных" рекламных объявлений встретилось описание действительно красивого решения:

Даже жаль, что идея не получила распространения.

Использование площадки в личных целях

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

Пока ещё нахожусь в Москве, но возможны и звонки, и приезд на интервью. Разрешение на работу и сертификация работодателя не требуются (Tier 1).

Если вдруг вы можете что-то по этому поводу сказать, мой адрес akopov@yurriakopov.info. Спасибо.

“Проще родить нового, чем отмыть старых”

Cloud Platform Storage: Relational vs. Scale-Out

Действительно интересный вопрос, хотя объяснение поверхностное: опущена важная деталь – являются ли описанные недостатки реляционных БД неотъемлимо присущими самой модели, или же конкретным существующим реализациям.

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