Автор: RCamel

В прошлом месяце я стал счастливым обладателем лицензионной Delphi XE и вместе с ней был вынужден сделать шаг к Юникоду. Конечно переход на Юникод в Delphi продолжается уже несколько лет, но от этого он не стал менее болезненным. С такими вещами, как явное указание типов строк ShortString и AnsiString все более или менее понятно. Эти моменты разжевывались Embarcodero давно и подробно. Основная головная боль была с самодельным компонентом. Когда-то я придумал, что метод компонента будет возвращать значение, через изменяемый параметр функции, типа ShortString. Вот тут то я и попал, оказалось, что подобный параметр возвращает все, что угодно, кроме нужного результата. Выход конечно нашелся, но пришлось переделывать компонент, так что бы он возвращал результат в виде результата функции. Как не странно заработало, но три дня как не бывало.

Второй момент который меня существенно удивил, было отсутствие прямого и корректного преобразования переменной типа Char в переменную типа AnsiChar. Когда любой компонент из VCL возвращает нажатие клавиши, это буква помещается в Char, который по умолчанию (причем которое невозможно изменить) является символом Юникода. Мне же нужен был обычный символ в интервале от 0 до 255. Простое приведение

KeyA:=AnsiChar(Key)

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

var
  StA : AnsiString ;
  KeyA : AnsiChar ;
begin
  StA:=Key ;        // присваиваем Unicode символ строке AnsiString,
                    // при этом компилятор добавляет преобразование
                    // типа строки
  KeyA:=StA[1] ;    // берем 1-й символ получившейся строки
end ;

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

Ярким примером того, что стандартизация побеждает является история программы «1С:Бухгалтерия». В свое время разработчиком был провозглашен лозунг «Методологичность выше технологичности». В результате этого программа работала временами медленно, но выполняла все операции требуемые бухгалтеру. Результат налицо. Программа является практическим монополистом рынка бухгалтерских программ.

Еще один яркий пример система «Экспресс». Это та система через которую продаются билеты на поезд. Первый вариант системы был создан еще в Советском Союзе. На весьма скромной аппаратной платформе система работала с огромной скоростью. Это достигалось благодаря программной оптимизации. При разработке системы не использовались стандартные СУБД, все было запрограммировано для достижения максимальной производительности. Во второй половине 90-х годов, когда настало время менять систему команда разработчиков была в восхищении от того, как оптимально все сделали их предшественники. Но к сожалению жизнь требовала использования стандартных СУБД и стандартных средств работы с ними. В итоге систему переписали заново, но для обеспечения такой же функциональности для новой системы потребовалось оборудование большей производительности и цены. Причем производительность нового оборудования была в сотни раз больше.

Глубоко уважаемая поисковая система Яндекс, по какой то одной ей известной причине считает этот сайт не достойным для индексации. Сей факт меня очень расстроил и я решил пообщаться с мифическим персонажем имя которому Платон Щукин. Сразу скажу, что общаться с ним не просто. Он все время норовит прислать стандартный ответ, мол, наш поисковый робот шарит и как только он найдет на страницах сайта уникальную и полезную пользователям информацию, так страницы сайта сразу же попадут в индекс.

В этом ответе меня смутила лишь одна вещь. Как бездушная машина может определить полезность информации. С уникальностью информации все просто. Если одно и то же повторяется на тысячах сайтов, то в принципе 1001 сайт можно не включать в индекс по причине не уникальности информации. А вот как определить полезность какой либо информации? Правильный ответ никак! Полезность той или иной вещи или информации полностью зависит от контекста или ситуации. Классический пример в сказке про царя Мидаса. Все к чему прикасался сей царь превращалось в золото. Первоначально царь считал золото крайне нужным и полезным, но затем ситуация изменилась. Царю захотелось кушать и то же самое золото стало крайне бесполезным, в отличии от той еды, которая в него превращалась.

Если вдуматься в ситуацию, то поисковая система Яндекс, в лице Платона Щукина,  крайне не осмотрительно рекомендует наполнять сайт полезной информацией, так как оценить информацию по критерию полезности принципиально невозможно в отрыве от контекста.