Пейзажи -- это совершенно не мое, поэтому стараюсь их и не снимать. Но вчера, в ожидании салюта, настраивая камеру, сделал несколько снимков. Один из которых настолько понравился, что рука не поднялась удалить его вместе со всем остальным шлаком.
1.4/35mm, ISO200, f=11, 5s
1.4/35mm, ISO=6400, f=1.4, 1/30s
Вчерашний салют изначально был назначен на 22:00. Я заявился к 21:30 чтобы занять место и подготовиться. Но, внезапно выяснилось, что салют перенесен на 23:00. Уходить не хотелось, а заняться чем-то нужно было...
Снимать салюты -- очень интересное и непростое дело :) Попробовал в прошлом году, процесс понравился, а вот результат -- не очень. Поэтому вчера, зная что будет салют к Дню Победы, подготовился: еще раз проштудировал Интернет, взял штатив, 35mm объектив -- и отправился заблаговременно занимать место на берегу пруда, над которым должен был состоятся салют.
В условиях индивидуального труда необходимость в подобных механизмах отсутствует -- координация осуществляется непосредственно в сознании человека. Но дайте ему в помочь второго работника, и ситуация существенно изменится. Теперь придется координироваться двум "головам". Люди, работающие бок о бок в небольших группах, приспосабливаются друг к другу, как правило, неформально; для них самой удобной формой координации является взаиморегулирование, взаимное приспособление. Однако, с увеличением числа членов группы координировать процесс труда неформальными способами становится все труднее. Возникает необходимость в лидере. Контроль над деятельностью группы переходит к одному человеку -- в итоге снова к одной голове, которая руководит остальными; оптимальным механизмом координации становится прямой контроль.Книга написана в 1983 (является упрощенным вариантом более развернутой книги "Structuring of Organizations: A Synthesis of the Research" 1979-го года), переведена на русский язык в 2001-м году.
При дальнейшем усложнении труда проявляется еще одна устойчивая тенденция -- к стандартизации. Решая задачи простые и однообразные, организация может положиться на стандартизацию самого труда. Но необходимость выполнения более сложных задач заставляют организацию обратиться к стандартизации выпуска, т.е. спецификации результатов труда, оставляя выбор рабочего процесса за работником. С другой стороны, стандартизировать результаты очень сложного труда зачастую невозможно, и тогда организация обращается к стандартизации квалификации работников. Однако, если разделенный на задачи труд не удается стандартизировать, возможно, придется, пройдя весь цикл, вернуться к самому простому, но наиболее удобному координационному механизму -- взаимному согласованию.
В продолжение вчерашней темы. Читаю сейчас обзорную книгу "M2M Communications. A System Approach" под редакцией David Boswarthick, Omar Elloumi и Olivier Hersent. Дошел до главы, в которой пытаются привести обоснования использования REST-механизмов для организации M2M взаимодействий. Наткнулся на прекрасное:
The main concept of REST is that a distributed application is composed of resources, which are stateful pieces of information residing on one or more servers. Regardless of their content, in REST it is possible to manipulate resources through a uniform interface that is composed of four basic interactions: CREATE, UPDATE, DELETE, and READ. Each of these operations is composed of request and response messages, and, with the exception of CREATE, they are idempotent, meaning that the end result of each operation is unchanged regardless of how many times the operation itself is repeated. In other words, these operations do not have side effects, meaning that it is possible to distribute resources and to use proxy functions.
Или, на русском языке, при беглом переводе:
Основная концепция REST-а в том, что распределенное приложение собирается из ресурсов, которые представляют из себя кусочки информации со своим собственным состоянием, расположенные на одном или более серверов. Вне зависимости от их содержания, в REST можно манипулировать ресурсами посредством унифицированного интерфейса, состоящего из четырех базовых операций: CREATE, UPDATE, DELETE и READ. Каждая из этих операций состоит из сообщений запрос-ответ, и, за исключением CREATE, эти операции являются идемпотентными, что означает, что результат каждой операции остается неизменным вне зависимости о того, как много раз операция была повторена. Другими словами, эти операции не имеют побочных эффектов, что означает возможность распределения ресурсов и использования проксирующих механизмов.
За последние годы работы настолько часто приходилось натыкаться на проблемы со здравым смыслом и отсутствием элементарной технической грамотности в материалах маркетологов/продуктологов, что подобные фрагменты вызывают у меня непроизвольные и неконтролируемые приступы идиосинкразии :(
Я еще могу согласиться с тем, что операция READ может считаться идемпотентной (хотя, если речь идет о распределенном приложении, в котором доступ к ресурсу могут одновременно выполнять несколько компонентов, идемпотентность READ -- это открытый вопрос, зависящий от параллельно выполняемых операций UPDATE и DELETE). Возможно, мне сложно будет найти достаточно аргументов, чтобы опровергнуть идемпотентность операции UPDATE (но уж точно нельзя считать, что операция UPDATE не имеет побочных эффектов). А вот идемпотентность операции DELETE -- это бред.
И, действительно, спустя буквально несколько страниц после процитированного выше пассажа читаем:
There are also two other HTTP methods, POST and DELETE, which are both non-idempotent operations and are typically used to create and destroy resources, respectively.
Или, по-русски:
Есть еще два других HTTP-метода, POST и DELETE, которые не идемпотентны и обычно используются для создания и удаления ресурсов, соответственно.
С учетом того, что HTTP-GET реализует операцию READ, HTTP-PUT -- UPDATE, HTTP-POST -- CREATE, а HTTP-DELETE -- DELETE, все встает на свои места. DELETE не может быть идемпотентной операций так же, как и CREATE.
Ну и еще прекрасное оттуда же, чтобы два раза не вставать:
Simple HTML and Javascript is all that is needed to create fully fledged M2M applications.
Как же изменилось все за последние 20 лет! Для создания полноценного приложения в области machine-2-machime взаимодействия всего-то и нужно-то HTML да JavaScript :(((
Куда катиться мир?
Третий день читаю различные материалы по ETSI-шным спецификациям в области Machine-2-Machine взаимодействия. Офигиваю от количества аббревиатур. Cпецы в области телекоммуникаций мастера придумывать труднозапоминаемые и не-пойми-как-расшифровываемые буквосочетания :) Хотя порождение разума телекоммуникационщиков мне ближе по духу, нежели длинныеНазванияВерблюжьегоСтиля от укушенных SOAP-ом, иногда приходиться признать свое полное бессилие в понимании происходящего.
Вот, например, из наболевшего: dIa, mIa, mId, mIm. Вторая буква во всех трех названиях -- это I (Ай, а не строчная Эл).
Две из этих аббревиатур официально (см. TR 102 725) расшифровываются как M2M application Interface (это mIa) и M2M device Interface (это mId). Две другие никак не расшифровываются (либо я пока еще расшифровки не встретил).
Служат эти аббревиатуры для обозначения интерфейсов, которые используются для разных целей:
Возможно, кто-то из читателей подумает, что знай он расшифровку NA/DA/GA/NSCL и пр. вышеперечисленного, ему было бы проще. Зря ;)
NA -- это Network Applications (т.е. приложения, которые находятся в прикладном домене и, собственно говоря, выполняют основную бизнес-логику). DA -- это Device Applications (т.е. приложение, которые размещаются внутри умного устройства и обеспечивают его функционирование). GA -- это Gateway Applications (т.е. приложения, которые выполняют роль шлюза для нескольких DA, расположенных внутри одного умного устройства). *SCL -- это Service Capabilities Layer, т.е. сервисный слой, осуществляющий поддержку основных функций на соответствующем уровне: DSCL (Device Service Capabilities Layer) на уровне устройства, GSCL (Gateway Service Capabilities Layer) на уровне шлюза внутри устройства, NSCL (Network Service Capabilities Layer) на сетевом логическом уровне, обеспечивающем агрегацию нескольких подчиненных DA, GA, DSCL и/или GSCL.
Стало проще понять и запомнить, чем отличается mIa от mId? ;)
Мне более менее помогает вот эта картинка из TS 102 690:
Но не надолго. Минут через 10 опять все путаешь :(
И я вот понять не могу: какой же логикой руководствовались изобретатели этих названий?
PS. Походу, у авторов ETSI M2M спецификаций, кроме всего прочего, еще RESTful головного мозга. В крайне тяжелой форме.
4-го мая 2014 в 66-й школе Гомеля прошел первый, пробный минитурнир по дартс. Собралось 8 игроков, играли в 501 single-in/double-out.
Формула была следующей: сначала разбили игроков на две группы по 4-ре человека. В группах играли по круговой системе каждый с каждым, матчи до 2-х побед. Результаты игр в группах стали основой для посева игроков на олимпийку, которая началась с 1/4-й финала. В четвертьфинале играли до 3-х побед, в полуфинале до 4-х, финал -- до 5-ти.
Результаты игр плей-офф:
1/4 финала
Охотников Е. 3-0 Шапорев А.
Денисов П. 3-1 Школдин А.
Барзыкин А. 3-1 Федорцов А.
Захаренко С. 3-0 Свириденко С.
1/2 финала
Охотников Е. 4-3 Денисов П.
Барзыкин А. 4-3 Захаренко С.
Финал
Охотников Е. 5-4 Барзыкин А.
Бонусы турнира (таки да, таковые есть не смотря на малый состав и краткий формат):
Лучший лег: Охотников Е., 17 дротиков.
Закрытие через Bull: Денисов П.
180: Барзыкин А., 1 раз.
Очень хочется отметить игру Сергея Захаренко. Очень здорово играет человек. Чуть-чуть не хватило опыта и везения, выход в финал и даже победа была вполне реальной. Для первого боевого крещения отличные результаты.
Пару слов о своих ощущениях. Зал классный, удобный, теплый. Уже готово три щита для мишеней, играли на двух, т.к. это соответствовало формату соревнований. Со временем будут еще щиты и хорошая подсветка для мишеней. Реально проведение турниров на 6-ти, а то и 7-ми мишенях одновременно. Так что есть куда развиваться. Это очень радует. Не радует разве что то, что в последние месяцы было мало возможностей для тенировок и участия в турнирах. Игровой практики, фактически, ноль и это сказалось: такого адреналина я не ловил уже очень-очень давно. Каким чудом мне удалось вытянуть игры с Пашей Денисовым (проигрывая 2-3 в матче до 4-х побед) и с Лёшей Барзыкиным (проигрывая в финале 3-4 в матче до 5-ти побед) не знаю. Просто невероятное везение.
Всем коллегам-дартсменам, которые сделали возможным проведение этого турнира, огромное человеческое спасибо! Было очень здорово. Надеюсь, в конце мая проведем следующий турнир, уже большим составом, на большем количестве мишеней.
Ну и совсем немного фотографий.
Вчера у нас в Гомеле произошло небольшое, практически незаметное, но очень знаковое событие: впервые удалось сыграть на большой площадке, которая может собрать 30-40 игроков!
Произошло это благодаря замечательному человеку, преподавателю физкультры 66-й школы г.Гомеля Сергею Захаренко.
Я знаю, что в Гомеле есть люди, которые интересуются и увлекаются дартсом, либо для себя, либо в рамках проводящихся профсоюзами соревнований. Однако, по-настоящему заметное в масштабе нашей страны дартс-движение в Гомеле, полагаю, зародилось внутри компании Интервэйл-Гомель четыре года назад. Именно весной 2010-го в офисе Интервэйл-Гомель начали проходить небольшие турниры и стал формироваться неформальный дартс-клуб. Уже в ноябре 2010-го мы выбрались на республиканские соревнования под эгидой Белорусской Профессиональной Федерации Дартса в Минск. С тех пор представители дартс-клуба Интервэйл-Гомель регулярно участвуют в республиканских и международных турнирах, и не просто участвуют, а побеждают и занимают призовые места.
За прошедшие 4-ре года существования нашего дартс-клуба мы неоднократно задавались вопросом выхода за пределы офиса и организации чего-то вроде городского дартс-клуба. С проведением городских и областных соревнований, а затем, по мере накопления опыта, и республиканских, а может быть и международных турниров (как это произошло совсем недавно в Могилеве). Но все упиралось в отсутствие двух вещей: зала для проведения соревнований и подсобного помещения для хранения стендов и оборудования...
Благодаря инициативе Сергея Захаренко, который сам нас разыскал и предложил свою помощь, у гомельского дартса может появится своя площадка и свое оборудование для проведения соревнований. На базе 66-й школы в Волотове. Вчера, 4-го мая, мы провели на этой площадке первый минитурнир.
Это было невероятно круто. Соревнования, пусть даже такие небольшие, но проходящие на спортивной площадке и в режиме non-stop, это совсем, совсем не то, что офисный турнир! Это действительно соревнования -- с адреналином, с усталостью, с кучей отвлекающих факторов и пр. и пр. И теперь, чтобы испытать, что же это такое, гомельчанам не нужно ездить в Минск, Могилев, Смоленск или Прибалику. Сложно передать, насколько это важный шаг вперед!
Теперь нужно сделать следующий шаг. Мы собираемся выработать подходящее для игроков расписание встреч на базе 66-й школы. Будем ли мы собираться один раз в месяц или два раза, а может чаще? Будут ли это тренировки или внутригородские турниры? Может быть мы сможем организовать что-то вроде Кубка Гомеля с какой-то формулой подсчета рейтинга игроков, с регулярным проведением этапов в течении года и финальным турниром в декабре или январе? Или же мы придумаем что-то еще?
В общем, все зависит от нас. Поэтому у меня просьба к читателям из Гомеля: сделайте, пожалуйста, репост этой заметки или ссылки на нее у себя -- в Google+, ВКонтакте, в Facebook-е, в Twitter-е... Где угодно. Главное, чтобы этот текст попал на глаза максимальному числу гомельских дарстменов. На это нужно всего несколько секунд, а дело вы можете сделать большое.
Для самих дартсменов, которые бы хотели участвовать в соревнованиях в Гомеле и, тем более, могли бы помочь становлению гомельского дартса: со мной можно связаться по email: eao197 на yahoo точка com. Либо же через комментарии к этой заметке.
Возможно, лучшая серия, снятая мной за последнее время. Хотя, наверняка я не объективен, т.к. фотограф был пьян в момент фотосъемки, и совершенно не трезв во время обработки и выбраковки снимков :)
