[prog] Не могу не выдернуть из контекста пассаж про верификацию программ

Персонаж с ником gandjustas у меня уже мелькал – цитировал я его высказывания с RSDN. С удовольствием сделаю это еще раз.

Итак, замечательная фраза:

Главное преимущество managed кода знаешь?
Это простая верифицируемость на клиенте. То есть непосредственно перед исполнением можно статически проверить что код не делает ничего криминального. Таким образом не нужны становятся аппаратные средства защиты, так как они рассчитаны на отлов тех же самых проблем, но в процессе исполнения.

На что его вполне резонно спросили:

А что именно значит "ничего криминального"? Если программа делит единицу на миллиардный по счету бит числа пи, как верификатор поймет, что там деление на ноль? Если идет обращение к массиву с нетривиально вычисляемым индексом, как верификатор угадает, нет ли выхода за пределы? Если идет загрузка модуля с вычисляемым именем и вызов функции из него, как статический верификатор узнает, что за функция будет вызвана?

И тут последовал совершенно феноменальный ответ:

Я с теорией верифцирования не сильно знаком, но верификация и сейчас производится.

И там же:

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

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

Verification and Validation (software)
Formal methods

PS. Кстати говоря, то, о чем говорит gandjustas – проверка отсутствия обращения по неверным указателям, проверка отсутствия выхода за пределы массивов, перезапись переменных на стеке и пр. – вовсе не являются свойствами управляемого кода. Компилирующиеся в нативный код языки со сборкой мусора и контролем за массивами и отсутствием адресной арифметики (Oberon, Eiffel, OCaml и, отчасти, Ada) дают точно такую же безопасность. Может быть даже большую, поскольку Ada контролирует в run-time корректность преобразований типов (afaik, если вы объявите тип A как 1..10, а тип B как 5..11, и попробуете преобразовать значение 2 от типа A к типу B, то получите исключение в run-time).

[life.cinema] Очередной кинообзор

Подошло время очередного кинообзора.

Крисалис. Качественная европейская фантастика. Получил удовольствие от просмотра. Тот нечастый случай, когда слегка затянутая и неспешная манера подачи материала оказывается очень в тему.

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

Олимпус Иферно. Мне понравилось. И снято нормально. И идеологический заряд в нем правильный, и в хорошей дозе.

Неудачники. Очень милая сказка о борьбе добра со злом и,чуть-чуть, о любви. По стилю сильно напоминает Амели, что и не удивительно -- снимал-то их один режиссер.

Команда "А". Отличный пример качественно сделанного развлекательного боевика. Отключаешь мозги и наслаждаешься зрелищем.

Граница. Очень черный и жестокий фильм. Давно ничего подобного не видел. Людям с чувствительной психикой на самом деле лучше воздержаться от просмотра.

Химера. Вполне себе нормальная фантастика. Чуточку растянуто, по-моему. Может местами недостаточно напряжения. Временами предсказуемо. Но смотреть можно.

Тринадцатый отдел. По-моему, это хороший и добротный французкий криминальный фильм. Но мне попался вариант с очень плохим переводом, поэтому в полной мере оценить фильм не удалось.

Большой солдат. Один из лучших, на мой взгляд, фильмов с Джеки Чаном. Так что поклонникам этого актера есть смысл посмотреть его. Хотя в фильме Джеки, как мне показалось, сыграл необычную для себя роль.

Экзамен. Хороший фантастический и психологический триллер. По сюжету сильно напоминает фильм Метод, но если метод является чистой психологической драмой с элементами триллера, то в Экзамене очень сильна фантастическая составляющая.

Ж.К.В.Д. Весьма необычный фильм с участием Жана-Клода Ван Дамма. Актер играет как бы самого себя. В отзывах о фильме я читал, что это лучшая драматическая роль Ван Дамма. Но лично мне длинный монолог главного героя, в котором как раз и усмотрели талант Жана-Клода, показался чужеродным в фильме. Если бы не он, то была бы вполне нормальная почти криминальная драма.

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

Валгалла: Сага о викинге. Редкая мудота с парой-тройкой очень коротких, но натуралистично сделанных поединков.

[prog] Расскажу о своем опыте периодической отсылки e-mail-ов

В продолжение вчерашней заметки поделюсь своим небольшим опытом. Для обслуживания своего софта на серверах мы разработали несколько маленьких рубиновых (написанных на языке Ruby) инструментов под общим названием pma tools. Например, там есть инструмент log_archiver, который архивирует старые логи. И инструмент too_old_eraser, который отвечает за удаление слишком старых архивов и вспомогательных файлов. И еще несколько специализированных скриптов.

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

Решили мы это дело просто. Каждый скрипт из состава pma tools логировал свои действия. А логгер анализировал, какие сообщение идут из скрипта. Если в лог файл попадали только сообщения с уровнями важности DEBUG, INFO и NOTICE, то такой лог считался успешным. А вот если в лог попадало хотя бы одно сообщение с уровнями WARN, ERROR или FATAL, то такой лог объявлялся проблемным.

Успешные и проблемные логи раскладывались по разным каталогам. Система каталогов вот такая:

log/
`- log_archiver/
   `- ok/
   `- problems/
`- too_old_eraser/
   `- ok/
   `- problems/
...

Т.е. если какой-то скрипт работает без проблем, то содержимое его каталога ok постоянно пополняется. Если же в его работе возникает сбой, то появляется новый файл в каталоге problems.

За всем этим хозяйством следит самый главный скрипт – result_analyzer. Он запускался периодически и проверяет содержимое каталогов ok и problems для каждого из компонентов. Если он находит новые файлы в каталоге problems, то формирует e-mail системному администратору о проблеме компонента. Если же он обнаруживает, что для компонента слишком долго нет новых файлов в каталоге ok – что, обычно, свидетельствовало о том, что компонент забыли настроить и запустить – то системному администратору сообщается и об этом.

Поскольку result_analyzer запускается где-то раз в 15 минут и за один проход собирает все проблемные логи в один e-mail по каждому из компонентов, то это дало разумный компромисс между оперативностью отсылки уведомления о проблеме и количеством этих уведомлений.

Так же result_analyzer удаляет устаревшие файлы логов из каталогов ok и problems. Причем его можно настроить так, чтобы у разных типов логов время жизни было разным. Скажем, успешные логи живут не более 2-х часов, а проблемные логи – не менее 3 дней.

Вот такой велосипед мы собрали на коленке лет пять назад. До сих пор работает :)

[prog] О том, как не просто просто отсылать уведомления по e-mail

Когда-то давным-давно, мой коллега написал инструмент для автоматического рестарта приложений на работающих в режиме 24x7 серверах. И добавил в этот инструмент полезную фичу: при падении и рестарте процесса на указанный в конфигурации e-mail отсылалось уведомление. Вроде бы важная и удобная штука.

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

С тех пор, когда какое-то приложение начинает отсылать e-mail уведомления, я всегда делаю ограничитель – не более N исходящих писем за какой-то интервал времени. Например, не больше 3-х писем за 10 минут.

Но интересно другое. Раз в несколько лет кто-нибудь из молодых коллег, который по молодости не застал первого инцидента, делает свою отсылку e-mail-ов… Чтобы в очередной раз наступить на те же самые грабли и самому набить эту шишку. Тогда как я пребываю в полной уверенности, что о фактах “спам-рассылок” из-за непредвиденных ситуаций все знают, и используют ограничения на количество отсылаемых писем. Вот и получается, что тот, кто знает – молчит, а тот, кто не знает, даже не догадывается :/

Так что лучше я скажу:

Если нужно организовать рассылку e-mail уведомлений о каких-то событиях, то следует сразу же реализовать ограничение на количество отсылаемых e-mail-ов. Чтобы избежать массированной спам-рассылки при наступлении жопы (а она обязательно наступит).

PS. Думаю, не сложно было догадаться, что данный пост был вызван очередным фактом засирания моего почтового ящика самодельной e-mail рассылкой ;)

PPS. А еще в некоторых случаях кроме отсылки e-mail-ов, нужно рассылать уведомления и по SMS. С этим делом нужно быть вдвойне, а то и втройне осторожнее. SMS-ки подороже e-mail-ов будут ;)

[work.humour] Хорошая картинка на профессиональную тему

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

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

[prog.flame] Так вот об изобретении новых языков программирования

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

Сразу обозначу свою колокольню – я занимаюсь разработкой важного для компании софта, который должен иметь как можно меньше багов, который живет и развивается долго (основной проект был запущен в эксплуатацию в 2002-м). Это означает, что я не могу сегодня написать один проект на D, внедрить его и забыть, чтобы завтра второй проект написать на OCaml, а послезавтра в третьем проекте использовать AliceML. Мне, по большому счету, нужен один универсальный, компилируемый, статически-типизированный язык. Который будет достаточно распространенным к моменту начала его использования мной, и который не загнется сам в ближайшие пять лет, и библиотеки для которого будут жить и развиваться. Да и самих библиотек должно быть много и разных, и очень хорошего качества.

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

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

Но не это самое страшное. Вот, скажем, для конечного пользователя уже не важна сама по себе конкретная операционная система. По большому счету ему все равно, какой тип планировщика в его ОС и даже какая файловая система у него на диске. Зато важен прикладной софт. А еще важнее – наличие драйверов для имеющееся у него железа. Т.о. прикладные программы и драйвера для самого широкого спектра устройств – вот что сейчас гораздо важнее деталей работы операционной системы.

А это значит, что вход нового игрока на рынок десктопных ОС чрезвычайно дорог – стоимость обеспечения новой ОС софтом и драйверами многократно превышает стоимость самой ОС. Поэтому-то мы не видим на рынке десктопных ОС никаких значимых новых игроков – все те же лица: Windows, Linux, MacOS. По большому счету и все.

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

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

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

Следствие из этого – сейчас язык программирования становится всего лишь некой синтаксической приправой к уже существующей платформе. Платформ этих, грубо говоря, можно насчитать всего три: нативный код на C/C++, JVM и .NET. Отдельными островками можно назвать Perl, Python, Ruby, Tcl/Tk (эти все за счет своего далеко не молодого возраста – у них было время обрасти “мясом”), а так же модные в последнее время Objective-C (за счет выстреливших Apple-вских игрушек) и Haskell-я с Erlang-ом (за счет интереса к ФП, да и, опять же, далеко не молодого возраста обоих).

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

Поэтому, из чисто практических соображений, новые языки должны создаваться для уже существующих мейнстримовых платформ. Как раз по этому пути идут Groovy, Scala, Clojure, F#. Наличие готовых библиотек и возможность простой интеграции с основным языком целевой платформы резко повышают их шансы.

Однако, тут возникает другой вопрос. А какой смысл пользователю отказываться от основного, уже привычного и знакомого ему основного языка платформы в пользу чего-то нового?

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

И другая сторона медали. Вот есть Java, которую сейчас можно рассматривать в качестве основного клея для разработки на JVM. Если вы пишете на Java, то ваш код будет доступен и из Scala, и из Groovy, и из JRuby, и из Clojure. А вот если вы пишете на Scala, то для Groovy программиста ваши разработки могут оказаться просто недоступными. Ну или сильно урезанными из-за необходимости прокладывания мостиков из Scala в Java, а затем в Groovy.

Означает ли это, что у новых языков нет вообще шансов? ;)

Есть, конечно. Поскольку существует такой серьезный фактор как моральное устаревание. Скажем, C++ сейчас – это старый уродец. Когда за плечами по 15-20 лет программирования на C++, хочется хоть на старости лет попрограммировать на чем-нибудь более простом, предсказуемом и приятном. (С++ спокойно можно заменить на Java, а лет через пять-семь и на C#) Плюс подрастает новое поколение, для которого какой-нибудь C++ или Java – как Фортран и Бейсик во времена моей молодости. Не есть рулез и все ;)

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

Но опять же... Сегодня новый язык программирования должен обязательно быть бесплатным. Но при этом обладать первоклассными инструментами и широкой поддержкой. Это возможно только, если в язык вложится какой-нибудь крупный игрок. Вот, например, Scala. Живет за счет ETH. F# разрабатывается в MS Research. Разработчики JRuby были наняты тогда еще Sun-ом на фултайм. Go появился на свет в Google. Только один бренд, который стоит за этими языками, дает им такие преимущества, которых никогда не будет у мега-языка от Васи Пупкина из Урюпинска.

В общем, если бы у меня спросили, при каких условиях стоит начинать разработку нового языка программирования, я бы ответил так:

• только, если язык будет нацелен на одну из трех больших платформ (C/C++, JVM, .NET) и
• только, если язык будет спонсироваться очень крупным игроком на IT-рынке.

Сюда бы я добавил еще одно условие (хотя оно, как видно на примере Scala и F#, необязательное): только если язык будет использоваться в серьезных разработках крупным игроком IT-рынка (смотрим на примеры Erlang и Go).

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

Тем не менее, большинство из представленных на Emerging Languages Camp языков как раз не удовлетворяют хотя бы одному из упомянутых условий. Т.е. они обречены на годы безвестности и ограниченного использования группкой энтузиастов. Т.е. их разрабочикам важен не столько результат – создание мейнстримового языка программирования, сколько сам процесс языкостроительства. Собственно, как и собаке важны не столько чистые яйца, сколько сам процесс их вылизывания :)

Напоследок подчеркну еще раз, что речь шла именно об языках общего назначения. Специализированные языки, как и специализированные операционки – это совсем другой коленкор. Там другая специфика, другие масштабы, другая конкуренция, совсем другие шансы на выживание. Аналогично и с экспериментальными языками, разрабатываемыми в исследовательских лабораториях. Вроде Spec# от MS – захотели проверить идею, выпустили язык, оценили результаты и опубликовали их. Язык свое дело сделал. Его будущее, по большому счету, уже никому не важно. Зато что-то из Spec# может со временем проникнуть в C# или куда-то еще. Собственно, в этом и была цель – эксперимент, а не продукт.

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

[prog] Большая и интересная презентация об Akka – агентном фреймворке для Scala

Akka: Simpler Scalability, Fault-Tolerance, Concurrency & Remoting through Actors

View more presentations from jboner.

Сайт фреймворка – http://akkasource.org/ 

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

[prog] Прям бум языкостроения какой-то :)

Временами складывается впечатление, что сейчас только ленивый не создает и не продвигает собственные языки программирования. Вот недавно прошла конференция OSCON 2010, в рамках состоялся Emerging Languages Camp, где обсуждались следующие новые (и не очень) языки программирования:

• AmbientTalk – язык, который поддерживает какую-то новую парадигму – ambient-oriented programming. Вроде бы предназначен для разработки приложений, которые вынуждены работать сразу на нескольких мобильных устройствах в ненадежной сетевой среде;
• BitC – относительно новый низкоуровневый, но очень-очень безопасный язык для системного программирования;
• Clojure – очередная реинкарнация Lisp-а, на этот раз для JVM (нужно заметить, что о Clojure сейчас очень много говорят, а применяют, думаю, намного реже);
• CoffeeScript – язык, который транслируется в JavaScript;
• Coherence – какой-то новый язык, как я понимаю, со встроенной поддержкой конкурентности;
• Cola – статически-типизированный язык, который компилируется в .NET или в Parrot VM;
• D – много обещавший когда-то нынешний долгострой;
• F# – раскрученная благодаря MS производная от OCaml-а на .NET;
• Factor – еще один новый функциональный язык, ориентированный на высокую производительность;
• Fancy – какой-то язык, с похожим на Ruby и Smalltalk синтаксисом;
• Frink – язык и система для вычислений;
• Go – ну куда же без самого обещающего нативного языка последнего времени, да еще от Google ;)
• Gosu – еще какой-то язык, чей сайт у меня сегодня не открылся вообще. Поэтому что это за зверь совершенно не понятно :)
• Io – не новый язык с прототипным ООП и собственной VM;
• Ioke – еще один язык для JVM от еще одного разработчика JRuby, вобрал в себя идеи из Io, Smalltalk, Lisp и Ruby;
• Kodu – язык для визуального программирования игр от MS Research;
• Mirah – бывший Duby, новый язык от одного из разработчиков JRuby. Ruby-новый синтаксис, но статическая типизация и генерация быстрого Java-байткода;
• Newspeak – новый язык, который пытается брать идеи из Self, Smalltalk и Beta;
• Noop – новый язык, который, если мне отшибает память, пару лет назад начали разрабатывать Google-овцы. Ориентирован на JVM;
• Objective-J – язык и фреймворк для разработки Web-приложений без необходимости знать о HTML, CSS и прочей лабуды;
• ooc – статически-типизированный современный мультипарадигменный язык, транслирующийся в C-шный код.
• Slate – прототипный ОО язык, берущий идеи из Self, Smalltalk и CLOS;
• Stratified JavaScript – расширение JavaScript для более мощной поддержки конкурентности;
• Thyrd – еще один язык для визуального программирования;
• Tyron – какой-то язык, синтаксис которого является помесью Python и Smalltak;
• Ur – новый функциональный язык, который, по заверениям авторов, имеет более мощную систему типов, чем Haskell;

Если добавить сюда еще и Zimbu, Groovy с Groovy++, а так же Lisaac, то знатный зоопарк новых языков получается. Не знаю кто что думает, но когда я смотрю на этот список языков, то вспоминаю русскую житейскую мудрость – когда собаке делать нечего, она яйца лижет.

В подготовке данного материала были использованы ссылки:

http://olabini.com/blog/tag/emerging-languages/
http://emerginglangs.com/speakers/

PS. Из всего списка у меня появилось желание посмотреть поближе только на ooc.

[life.sport.darts] Посмотрел финальные игры World Matchplay 2010

Благодаря ссылкам на сайте www.smotrisport.com удалось посмотреть одну четвертьфинальную, обе полуфинальные и финальную игру World Matchplay. В прямом эфире.

Классно! Когда сам понимаешь, что к чему, выглядит все это совсем, совсем по-другому. Особенно, когда у игроков появляется шанс на лег в 9-ть дротиков. А еще больше – когда игрок в завершении лега мажет D16, потом D8… :)

Только что закончился финал. Фил Тейлор сделал Раймонда ван Барнивелда 18-12. Матч получился хоть и напряженным, но не интригующим. Какое-то неоспаримое преимущество Тейлора все время ощущалось. В особенности, когда он сделал несколько очень важных 100+ завершений, не дав ван Барнивелду перехватить инициативу. Чего тут поделаешь, Тейлор есть Тейлор. Барнивелд хотя бы серьезное сопротивление ему оказал, а то в четвертьфинале и полуфинале противники Тейлора смогли взять всего по четыре(!) лега.

В общем, отличная это игра – дартс. Я рад, что увлекся. Чего всем и желаю :)

[life.photo] Пейзажи Владимира Сковородникова

Ближайшие несколько выпусков “Знакомства с фотомастером” будут посвящены замечательному фотографу Владимиру Сковородникову. Сегодня публикуются фотографии из его фотоальбомов “Ильчир” и “Байкал”.