суббота, 30 августа 2014 г.

[life.photo] Набор хороших советов для street photo, но...

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

Еще раз утверждаюсь в мысли, что подавляющее большинство street-фотографов безуспешно пытаются перевести количество в качество :) Вот здесь очень уважаемый мной фотограф-путешественник Дмитрий Шатров привел интересное высказывание на этот счет: street photo -- это как попытка фотографировать спички, насыпанные в бутылку. Встряхиваем содержимое, фотографируем, если из спичек сложился кораблик, значит получилась хорошая уличная фотография. Если не сложился... Ну значит не получилось :)

пятница, 29 августа 2014 г.

[comp] Как по мне, так это просто отличная дискредитация идей Internet-Of-Things

SlideShare порекомендовал посмотреть:

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

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

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

Потому что реальная работа в этом направлении, как мне представляется, уже ведется. Весьма солидными организациями. Вот, например: GE Healthcare to Use RTI Connext Middleware as Industrial Internet Transport for Medical Systems.

Ну а тем, кто хочет урвать свой кусок от кажущегося им большого пирога под названием Internel-of-Things, остается делать презентации с "умными носками" в качестве примера использования IoT ;)

[prog.flame] Haskell vs C++: анонимусы на LOR-е жгут напалмом

Цинк:

Так что хаскель, как ни крути, это как раз то, чем должны быть кресты, если бы Страустрап не циклился на Си.

четверг, 28 августа 2014 г.

[life.photo] О мастер-классе про повышение резкости в Photoshop от Андрея Журавлева

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

Сухой остаток. Стремиться делать звеняще резкие снимки в Lightroom-е -- это зря тратить свое время. Нужно переползать в Photoshop... Но блин, это ж весь отстроенный рабочий процесс нафиг... :(((

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

[life.war] Узнал интересное про Холодную войну

Оказывается, в США есть Cold War Recognition Certificate (т.е. что-то вроде удостоверения участника Холодной войны)

А к этому удостоверению потихонечку продавливается и соответствующая медаль: The Cold War Medal

Она пока признается только несколькими организациями, но процесс не стоит на месте...

Ну риторический вопрос для тех, кто считает США белыми, пушистыми и совсем-совсем не страшными: а с кем они воевали в Холодной войне и победу над кем они отпраздновали? А ведь об этой победе говорят далеко не последние люди в США и не так давно. Вот, например, Хилари Клинтон в пресс-релизе от 12 апреля 2007:

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

(перевод взят из Wikipedia, первоисточник на английском языке здесь (смотреть первый пресс-релиз))

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

среда, 27 августа 2014 г.

[prog.thoughts] Про использование модели publish/subscribe

В последнее время знакомился с разными инструментами, поддерживающими модель publish/subscribe (в первую очередь речь идет о MQTT и DDS). Подумалось, что в каких-то вещах начинает наблюдаться принцип "если у тебя в руках молоток, то все вокруг выглядит как гвозди". Т.е. модель pub/sub начинают использовать не совсем так, как это нужно.

Где-то pub/sub выглядит вполне естественно. Допустим, есть какой-то датчик температуры воздуха, который раз в 10 минут отсылает в сеть свое текущее значение. Тогда создается тема с именем, например, building-1/floor-2/temp-sensor-3, в которую датчик отсылает свои замеры. Тот, кто хочет читать значения именно этого датчика, тот подписывается именно на эту тему. Тот, кто хочет читать значения всех датчиков температуры с этого этажа, подписывается на несколько тем сразу, скажем, вот так: building-1/floor-2/temp-sensor-#. И таких подписчиков может быть несколько: один собирает информацию для управления климатом (например, когда температура выходит за заданные пределы, включается система кондиционирования), второй архивирует эту информацию для дальнейшей обработки (например, демонстрации графиков-трендов).

Совсем другое дело, когда pub/sub пытаются задействовать для организации взаимодействия друг с другом нескольких компонентов по принципу "запрос-ответ". Предположим, что есть состоящий из нескольких компонентов SMTP-сервер. Компонент-читатель получает очередной email и перед дальнейшей отправкой полученного письма хочет проверить, а не спам ли это. Для этого нужно сделать запрос к компоненту-анализатору-спама. Каким образом? Просто опубликовав запрос в теме spam-checking/request. Анализатор подписан на эту тему и, поэтому, рано или поздно получит этот запрос. Выполнив проверку компонент-анализатор опубликует ответ в теме spam-checking/response.

В принципе, мне уже здесь начинает казаться, что что-то идет не так. Подозрения усиливаются, если предположить, что для увеличения пропускной способности в нашем SMTP-сервере есть несколько компонентов-читателей, каждый из которых принимает email-ы и нуждается в их проверке. Вопрос в том, каким образом компонентам-читателям определяет, кому из них предназначался ответ в spam-checking/response?

Тут напрашивается сразу несколько решений:

  • при публикации сообщения в теме spam-checking/response можно снабдить это сообщение каким-то мета-атрибутом, позволяющим однозначно определить получателя. По этому мета-атрибуту каждый из компонентов-читателей настраивает фильтры для темы spam-checking/response и, благодаря фильтрам, получает только свой трафик. Этот подход требует, чтобы pub/sub-система поддерживала мета-атрибуты (а разработчики знали про этот механизм и могли его использовать);
  • для ответов создается не одна тема, а несколько, по одной на каждый компонент-читатель. Например, spam-checking/response-1, spam-checking/response-2 и т.д. Отсылая запрос компонент-читатель сообщает свой номер и ответ публикуется в той теме, которая создана персонально для этого читателя;
  • каждый компонент-читатель создает свою собственную тему, например, receiver-1/spam-checking-result, receiver-2/spam-checking-result и т.д. Компонент-анализатор должен публиковать свои ответы в соответствующей теме.

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

Думаю так же, что если мы отходим от pub/sub в сторону простых очередей сообщений, то результат, на мой взгляд, получается более логичным. Т.е., если мы строим SMTP-сервер из компонентов на основе message queues, то у каждого компонента появляется своя очередь входящих сообщений. Например, receiver-1-queue, receiver-2-queue, spam-analyzer-queue и т.д. Нужно отправить запрос на анализ очередного письма? Просто пишем его в spam-analyzer-queue, а в качестве обратного адреса указываем имя очереди, в которую нужно отослать ответ (например, receiver-2-queue).

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

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

Имхо, такая модель peer-to-peer взаимодействия компонентов через шину данных хорошо подходит для многостадийной обработки информации. Например, в сложных Web-приложениях, при обработке SMTP- или SMPP-трафика, при обслуживании платежных транзакций и т.д. Гораздо лучше, чем использование publish/subscribe моделей и инструментов. Хотя, у меня сложилось впечатление, что вендоры DDS-решений так не думают :)

PS. В принципе, для peer-to-peer взаимодействия можно использовать и простой синхронный RPC. Но это, на мой взгляд, и масштабируется хуже, и, со временем, могут всплыть вопросы с версионностью данных (расширять сообщения, как показывает практика, проще, чем синхронные интерфейсы, базирующиеся на чем-то вроде CORBA).

PPS. А еще мне кажется, что для задач, с которыми приходилось сталкиваться, нужно иметь промежуточное ПО, которое поддерживает сразу два способа взаимодействия -- и peer-to-peer через шину данных, и publish/subscribe. А местами и data-flow :)

[prog.sobjectizer] Краткое описание so_sysconf на русском языке

В рамках процесса документирования SObjectizer был написан небольшой документ на русском языке, в котором описываются базовые вещи подпроекта SObjectizer System Configurator (или so_sysconf в сокращенном виде). Этот подпроект позволяет размещать кооперации с прикладными агентами в DLL, а затем собирать прикладное приложение из этих DLL как из конструктора LEGO.

Вот это описание: Базис so_sysconf-4.3.

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

Описание so_sysconf-а было сделано сперва на русском языке потому, что так оказалось проще. Со временем, мы переведем это описание на английский и разместим его в Wiki на SourceForge. И с документацией на другие подпроекты, полагаю, будем поступать так же: сначала первое описание на русском, затем его перевод на английский. Очевидно, что это займет больше времени, но так оказывается проще.

вторник, 26 августа 2014 г.

[prog.flame] Слайд для любителей использовать XML/JSON/YAML

Найден в презентации OMG DDS Tutorial Part II:

Т.е. по сравнению с бинарным представлением CDR (используемым в CORBA) текстовые форматы могут давать увеличение объема до 10 раз и снижение производительности до 20 раз.

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

Как я понимаю, CORBA и DDS не поддерживают версионности, поэтому решили попробовать что-то еще. Только вот не понятно, почему не попробовали хотя бы ASN.1 с его extension point-ами. К сожалению, я не помню, был ли Google Protobuf в 2008-м, но мы у себя в 2008-м уже года четыре как использовали собственную ObjESSty, которая, как и ASN.1 BER/PER, сериализовала данные в двоичное представление, да еще и поддерживала версионность данных. Т.е. в очередной раз убеждаюсь, что многие вещи мы на интуитивном уровне делали правильно, но вот выбраться из своего маленького гаражика со своими идеями не смогли :) Кстати говоря, в библиотеке MBAPI, которая добавляет возможность строить распределенные приложения на основе SObjectizer-а, для сериализации используется именно ObjESSty, так что в MBAPI нет проблем с расширением сообщений новыми полями, в отличии от DDS...

PS. Еще одна заметка на счет эффективности XML из моего блога.

[prog] Пара ссылок на PDF-ки на тему DDS

Заглянул краем глаза в такую большую область как DDS (Data Distribution Service for Real-Time Systems). В процессе поиска чего-нибудь полезного нашел два небольших документа, которые позволяют понять, что это такое не закапываясь в огромные толмуды спецификаций:

Messaging Technologies for the Industrial Internet and the Internet of Things Whitepaper (A Comparison Between DDS, AMQP, MQTT, JMS, REST and CoAP). Не очень большой документ, который делает краткий обзор нескольких протоколов/технологий и очерчивает области их применения. Смотреть нужно с некоторой долей скепсиса, т.к. в нем явно чувствуется маркетинговая цель доказать, что DDS круче всех.

The Data Distribution Service Tutorial (ссылка на SlideShare, но оттуда можно скачать и сам PDF-документ). Небольшое введение в использование DDS (примеры на C++, но для Java разработчиков вряд ли будут сложности).

Еще одна похожая презентация от того же автора, но уже от 2015-ого года: The Data Distribution Service Tutorial.

Еще два больших PDF-а с толковыми презентациями (от 2009-го года, но все равно крайне полезными): OMG DDS Tutorial Part I (на 162 слайда) и OMG DDS Tutorial Part II (на 94 слайда).

Очень толковая презентация о применимости и полезности DDS в реальном мире: Why is DDS the Right Technology for the Industrial Internet?

Хорошая презентация о DDS и его применимости вообще, а так же конкретно об OpenSplice: DDS in SCADA, Utilities, Smart Grid and Smart Cities (носит в большей степени технических характер). Плюс еще одна очень большая презентация об OpenSplice на 200 слайдов, по сути, "все-в-одном": и рассказ о DDS и различных его аспектах, и некоторые детали реализации OpenSplice, и пример использования OpenSplice в контроле за авиационным трафиком (последние 10 слайдов): Introducing the OMG DDS to the Aerospace Valley (второе название "OMG DDS: The Data Distribution Service for Real-Time Systems).

Так же могу отметить презентации на SlideShare от Angelo Corsaro, ну и разделы Tutorials и Presentations на официальном портале DDS.

Не совсем про DDS, но зато про M2M (machine-2-machine) и IoT (internet-of-things), т.е. про области, в которых DDS находит широкое применение:

  • Smart City: Many Applications and Devices -- интересная презентация о том, какой спектр инструментов может предложить клиенту компания Eurotech и как эти инструменты используются в решении реальных проблем клиента. Вообще на SlideShare канал этой компании является источником интересных материалов на тему M2M и IoT: SlideShare Eurochannel;
  • Internet Of Things Basics -- интересная презентация на тему IoT и M2M, которая затрагивает очень широкий спектр вопросов -- от бизнес-проблем до особенностей использования разных версий Java на мелких устройствах;
  • Internet of Things -- where OMG's DDS stands -- совсем короткая презентация, коротко рассказывающая об IoT и показывающая роль и место стандарта DDS внутри IoT. Так же на последнем слайде есть список ссылок, которые могут быть полезны интересующимся этой темой;
  • Real-World Applications of OMG Technology in Medicine -- довольно большая презентация, рассказывающая о том, как DDS может применяться в медицине (носит явно маркетинговый характер, т.к. подготовлена вендором DDS-платформы, но представление об одной из областей применения дает).

Для меня, как C++ника, интересной оказалась презентация Standardizing the Data Distribution Service (DDS) API for Modern C++.

PS. Насколько я понял, в области DDS сейчас всего три живых и развивающихся продукта: Connext DDS от RTI, OpenSlice от Prismtech и OpenDDS от Object Computing (OpenDDS полностью OpenSource, построен на основе ACE и TAO теми же людьми). Upd. Есть еще вполне себе живая CoreDX DDS от Twin Oaks Computing.

[prog.flame] Нет Ruby без Ruby-On-Rails?...

Если мне не изменяет склероз, то Макс Лапшин в своих выступлениях и в своем ЖЖ несколько раз говорил, что в дикой природе Ruby без Ruby-On-Rails не существует.

Признаться, меня несколько шокируют такие вещи, хоть я сам от активного использования Ruby отошел года четыре назад. Но с 2004 по 2010 пользовался Ruby ежедневно и вовсе не для Web-а. Да и сейчас каждый день работаю с написанной на Ruby build-системой и в ней так же нет ничего от рельсов.

Но я, все-таки, не показатель, т.к. степень маргинальности слишком часто зашкаливает :) А вот эта новость, попавшаяся мне на глаза, позволяет думать, что я не один такой: R2CORBA success in a heterogeneous setting. Там речь о том, как инструмент R2CORBA использовали для управления радиотелескопами в Калифорнии. Т.е. есть люди, которые спокойно используют Ruby и без Ruby-On-Rails. Полагаю, что таковых сильно меньше, чем рельсовиков, однако, они были, есть и, полагаю, будут. Поэтому, если кому-то нужен хороший скриптовый язык для не связанных с Web-ом задач, то имеет смысл посмотреть на Ruby.

Да, забыл сказать R2CORBA -- это реализация CORBA на Ruby от RemedyIT. Эти же ребята стоят и за ACE, и за TAO, и за OpenDDS (для многих это сомнительная рекомендация ;), понимаю, однако, работающие продукты они делают, этого не отнять.

понедельник, 25 августа 2014 г.

[prog] Вот уж где не ожидал увидеть UML...

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

Вот уж, действительно, о сколько нам открытий чудных... :)

PS. Это фрагмент спецификации протокола RTPS.

воскресенье, 24 августа 2014 г.

[business] Статья для вправления мозгов

Наткнулся на просторах Интернета на статью "Forbes Dream Stories – как нас всех развели.". Маленький фрагмент:

Эксклюзивные бизнесы не делают, на них получают разрешение и на них назначают.

Пример тому – Вконтакте. Все знают мальчика Дурова, но никто не думает о том, что ВК – это бизнес Мирилашвили, пусть и сына, но сына человека, человека из “первой” питерской команды.

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

Мир на самом деле гораздо проще. Суть его – “бизнесфеодализм”, где, если вы не феодал, ваш основной капитал – доверие феодала.