Размышления и впечатления, которые не хочется держать в себе. О программировании в частности. Ну и о творчестве, и о жизни вообще.
Подведены итоги конкурса Nikon Small World 2011. Официальные результаты можно увидеть на сайте проекта. А здесь подборка снимков-конкурсантов в заметно большем размере (для комфортного разглядывания некоторых нужны солидные мониторы). Под катом три снимка, которые понравились лично мне.
(Да, если кому интересно – аналогичная заметка об этом же конкурсе 2010 года)
Узнал о юбилее на OpenNet. Так что от души поздравляю Брама Мулленара, всех разработчиков, внесших свой вклад в ViM, а так же всех пользователей этого редактора (коим я являюсь уже семь лет)!
PS. Если кому-то интересно, то вот моя заметка 2-х летней давности о том, каким образом я дошел до ViM-а ;)
В обсуждении заметки “Нашел интересное в очередном потоке сознания Стива Йегга” я выказал намерение написать о том, почему я считаю хорошими принципы взаимодействия компонентов, озвученные в 2002 году основателем Amazon Джефом Безосом. Тема интересная, но только сейчас нашлось достаточно времени чтобы вернуться к ней.
Итак, вкратце упомянутые принципы в моем русском варианте звучат следующим образом:
1) Все команды начиная с данного момента должны предоставлять данные и функциональность своих компонентов посредством сервисов со специфицированными интерфейсами.
2) Компоненты должны взаимодействовать друг с другом посредством этих интерфейсов.
3) Не должно быть никаких других форм взаимодействия: ни непосредственной линковки, ни прямого чтения хранилищ данных другой команды, ни модели разделяемой памяти, ни каких “черных входов” или чего-то подобного. Единственная разрешенная форма коммуникации – вызовы интерфейсов через сеть.
4) Без разницы какая технология будет использоваться. HTTP, CORBA, Publisher-Subscriber, слабанная на коленке – все равно, это не важно.
5) Все без исключения интерфейсы должны с самого начала проектироваться с прицелом на взаимодействие с внешним миром. Т.е. команды должны планировать и проектировать свои интерфейсы так, чтобы их можно было предоставить разработчикам вне компании. Без исключений.
На мой взгляд, эти принципы могут применяться и для распределенных программных комплексов много меньшего масштаба, нежели платформа Amazon. И в этом случае я бы заменил пункт #5 – поставил бы на его место правило о том, что интерфейсы должны быть асинхронными, ориентированными на обмен сообщениями. И только в крайних случаях они могут быть синхронными, основанными на чем-то вроде удаленных вызовов.
Теперь, после освежения темы в памяти, можно перейти к перечислению достоинств такой модели.
Первое (важное с точки зрения эксплуатации): такой подход позволяет эксплуатировать каждый из компонентов независимо друг от друга. Это затрагивает множество аспектов. Например, масштабирование. Когда конкретный компонент перестает справляться с нагрузкой, можно заниматься его разгоном независимо от других – докупать новые сервера, увеличивать дисковые массивы, производить обновление железа и пр. – вплоть до переезда на совсем другие аппаратные и программные платформы. Скажем, работал компонент на одном сервере с Windows, а перебрался на Linux-овый кластер с балансировщиком нагрузки на входе. При том, что остальные компоненты могут не иметь возможности подобной миграции в принципе (например, привязаны к железякам, драйвера для которых есть только под одну платформу).
Второе (важное с точки зрения разработки): такой подход позволяет разрабатывать компоненты независимо друг от друга. Без оглядки на используемые технологии и их частные особенности. Здесь я противопоставляю взаимодействие с удаленным компонентом взаимодействию через непосредственную линковку кода компонента с вашим кодом. Допустим, в приложении нужно иметь возможность шифрования/подписи данных с использованием HSM. Код по взаимодействию с HSM можно просто прилинковать к своему коду. Но тогда возникают разнообразные проблемы интеграции – на каком языке написан сторонний компонент, совместим ли он с нашей версией компилятора? Какие фреймворки и их конкретные версии используются – совместимы ли они с тем, что используем мы? Какие особенности есть в работе с компонентом – нужно ли его явно инициализировать/деинициализировать, если нужно, то на контексте какой нити это нужно делать? Как компонент может влиять на работу нашего приложения – насколько он дружит с многопоточностью, может ли он непредсказуемо сильно загрузить процессор или вдруг отожрать много памяти? Обо всем этом не нужно думать, если компонент внешний, мы общаемся с ним только через сеть и работает он фиг знает где. Модуль работы с HSM-мом можно сделать на C++, а свой код мы без лишнего геморроя можем написать на Ruby.
Третье (важное как с точки зрения разработки, так и с точки зрения эксплуатации): такой подход позволяет очень гибко и разнообразно менять потоки данных между компонентами. Зачастую совершенно прозрачно для самих компонентов. Особенно в варианте, когда используется асинхронный обмен сообщениями. Простой пример. Допустим, есть компонент A версии 1.0. Мы хотим ввести в эксплуатацию его следующую версию 1.1, но очень плавно – направив сначала на новую версии только 5% от запросов, затем 10%, затем 50% и только убедившись в полной работоспособности, все 100%. Делается это посредством балансировщика, который устанавливается перед двумя версиями компонентов A. Сначала он пропускает 95% запросов на версию 1.0, а 5% – на версию 1.1. Затем пропорции меняются. Когда происходит полный переход на версию 1.1 этот промежуточный компонент может быть вообще устранен. При этом ни сами компоненты A, ни их клиенты даже не догадываются о том, что параллельно работают разные версии.
Такое “прозрачное” вмешательство в потоки данных позволяет делать интересные вещи. Например, фильтровать поток запросов, удаляя из них заведомо неправильные или потенциально опасные. Проводить преобразование запросов “на лету” (скажем, заменять в платежных запросах устаревший код валюты на актуальный). Сглаживать пики нагрузки и делать поток запросов равномерным. Либо же контролировать объем потока, отсекая “лишние” запросы, тем самым предохраняя компоненты от перегрузки. И т.д., и т.п. Причем, повторюсь, делать это в случае асинхронного обмена сообщениями, на мой взгляд, много проще, чем при синхронном взаимодействии.
Вот как-то так. Наверняка есть и другие “за” (равно как и “против”), но три вышеозвученных момента сразу же приходят на ум.
http://www.openmama.org/ – проект OpenMAMA (где MAMA расшифровывается как Middleware Agnostic Messaging API).
Ну вот как относиться к проекту с таким названием? ;) Хотя до иби-ИксЭмЭль, конечно, не дотягивает.
Чтобы не потерять этот момент в комментариях к предыдущей заметке выношу его в отдельный пост.
Спорт развивает очень важные качества, а именно:
1) умение пересилить себя, заставить себя сделать то, что раньше не мог;
2) умение справиться с поражением.
Последнее качество очень важно, ведь спорт – это обязательные, неизбежные поражения. Пусть даже у выдающихся спортсменов их и не много, но все-таки они есть. И они заставляют нас вновь и вновь начинать путь к следующей победе.
Очень полезные качества чтобы не потеряться в жизни, я считаю.
PS. И если для пункта 1) достаточно только собственного труда (работы над собой), то вот для пункта 2) обязательно нужна соревновательная практика. И как раз дартс – это такой вид спорта, который позволяет получать ее даже в совсем уже не молодом возрасте. Равно как и бильярд, например.
Просто невероятно. Прям такой-то дартсотоксикоз ;)
За последний месяц несколько раз пытался в течении всего одного дня удержаться от подходов к доске. Пока ни разу не удалось. Сегодня очередная попытка. Еще и половины дня не прошло, а у меня уже сильные подозрения, что вновь не получится :) Upd. Тем не менее, мне это удалось! ;)
Вспоминается молодость, когда я еще курил. Вроде бы заставить себя провести день без сигарет было намного проще.
PS. Вот здесь нашел несколько глав из автобиографии Эрика Бристоу – многократного Чемпиона Мира, легенде дартса, чей звездный час пришелся на 1980-1990-е. Он пишет, что в молодости тренировался целыми днями, бросил школу, дартс занимал столько времени, что даже на нормальные романы с девушками его уже не оставалось. Это как бы иллюстрация того, насколько непростым видом спорта оказался дартс. Жаль, что я не знал этого раньше :)
Подошло время очередного кинообзора. В этом месяце мне попались несколько очень даже приличных фильмов из Юго-Восточной Азии (Южной Кореи, Гонконга). Был приятно удивлен. Собираюсь посмотреть еще несколько фильмов оттуда.
Сразу хочу выделить один корейский фильм – Олдбой. Так уж получилось, что я его раньше не видел. Посмотрел только сейчас. Не могу сказать, что фильм мне понравился, но впечатлен я сильно. Его имеет смысл посмотреть просто для того, чтобы узнать, что такие фильмы бывают.
Ну а дальше обычный список фильмов по убыванию их ценности для меня.
Преследователь. Отличный сюжет. Добротно сделан. Несколько моментов просто чрезвычайно сильные.
Я видел дьявола. Непростой и тяжелый фильм. Может чуть затянутый.
Успеть за 30 минут. Динамично и забавно.
Несносные боссы. Комедия явно не семейная. Зато смешная.
Преступная любовь. Снят в своеобразной манере. Но мне понравился.
Око небесное. Простенько. Тем не менее, захватывает.
Таможня дает добро. Не так плохо, временами смешно. Жалко, что слишком много глупых диалогов (хотя может здесь качество перевода сказывается).
Рейдер. Приятно, что российский. Но какой-то он весь угловатый, лубочный, шаблонный что ли. Плюс к тому часто предсказуемый, слишком часто невероятный.
Земля вампиров. На удивление неплохо. Атмосфера фильма удалась, проникаешься. Правда сюжетный ход с "шибко умным" вампиром оказался слишком надуманным и выбивающимся из общей колеи. Хотя это, наверное, единственная серьезная претензия к такому рода фильму.
Ковбои против пришельцев. Не торкнуло. Не смотря на наличие звездных акторов и приличный бюджет.
Первый мститель. Редкая хрень. Хотя вложенные в фильм деньги на экране видны, да.
Соседка по комнате. Не сильно правдоподобно. Зато настолько гламурно, что от вида такой всей из себя красавицы, отличницы, спортсменки (т.е. главной героини) через полчаса после начала фильма начинает тошнить.
Состоялся релиз версии 1.9.3 языка программирования Ruby!
Это плавное продолжение развития ветки 1.9, никаких ломающих совместимость изменений не обещают. Полный список нововведений можно увидеть в документике NEWS.
Скачать новую версию можно отсюда: http://ftp.ruby-lang.org/pub/ruby/1.9 (под именем ruby-1.9.3-p0). Бинарников под Win пока нет :( (как обычно, появятся недели две-три спустя).