Oleg

Текущее и управление

noreply@blogger.com (Oleg Shall) — Fri, 30 Nov 2018 00:11:00 +0000

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

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

И вот настает эпоха цифровых технологий и цифровых двойников. Понятно, что цифровые подходы должны активно использоваться и в управлении и текущей жизни компании, но инструментов обеспечения такой трансформации у фирм явно недостаточно. Что происходит сейчас? Что обычно делает предприниматель на старте? Он запускает фирму на бумажке, работает на бумажке, использует свой мозг и здравый смысл, и только после осознания своих естественных ограничений, начинает использовать внешние подпорки. Электронные таблицы, бухгалтерские программы, CRM, склад, автоматизация общения с партнерами и клиентами. Но это все происходит a posteriori, как результат неспособности совладать с нарастающей сложностью управляемых процессов. Я уже не говорю о чувстве “ложной компетентности”, которое часто захлестывает предпринимателей, играя с ними злую шутку.

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

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

В моей системе я не желаю слышать фразу :”Наверное девочка что-то напортачила (не поняла)”.

Это трудная задача и еще трудней ее решить без поддержки, без инвестиций. Тем интересней результат, тем занятнее процесс. Да, я знаю мнение многих. АСУ не решает задач, не снижает сложность и только увеличивает число работников. В известном смысле это и будет попыткой ответить на этот вопрос.

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

На чем собираемся выходить. В работе есть несколько проектов.

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

Это все будет реализовано в одном едином приложении (и мобильном тоже), что позволит пользователю делать больше дел сразу, а предпринимателю стремительно расширять свою абонентскую базу.

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

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

А если наш путь заинтересует инвесторов, мы будет очень рады обсуждать тонкости взаимодействия.

Если лампы зажигают, значит это кому-то нужно.

noreply@blogger.com (Oleg Shall) — Thu, 12 Jul 2018 14:38:00 +0000

Плавное возгорание лампочки

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

таймерах;
широтно-импульсной модуляции (ШИМ/PWM);
прерываниях;
начальной инициализации в CubeMX.

Вся теоретическая и практическая части относится к микроконтроллерам STM32 в моем случае это STM32F407VG, но ничего страшного, если есть другой микроконтроллер STM с наличием светодиодов и таймеров общего назначения.

Перывания

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

В ARM процессорах управлением прерываний занимается Nested vectored interrupt controller (NVIC). Он позволяет назначать приоритет прерываниям. И в случае если во время выполнения прерывания случиться более приоритетное прерывание, то выполнения текущего прерывания будет остановлено, и начнет выполняться более приоритетное (рисунок ниже).

Временная диаграмма прерываний

Таймеры

Микроконтроллеры серии STM32 имеют около 10 таймеров. Первым таймером, которым вы уже вероятно пользовались в функции void HAL_Delay(uint32_t Delay) является system timer, который присутствует практически во всех ARM Cortex-M процессорах. По умолчанию CubeMX настраивает данный таймер на генерацию прерываний с частотой 1 кГц. А код обработчика прерывания просто выполняет инкремент переменной uwTick библиотеки HAL.

Кроме данного таймера у STM32F3 так же имеются таймеры TIM1-TIM14. Данные таймеры облают большими возможностями чем system timer и имеют следующие возможности:

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

Пример сигналов с широтно-импульсной модуляцией

По функциональности таймеры в STM32 делятся на следующие группы:

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

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

Схема таймера общего назначения

Из основных элементов таймера выделим счетчик (CNT counter) и каналы (TIMx_CH1 — TIMx_CH4).

Рассмотрим сначала работу счетчика. На рисунке ниже изображена линия CK_PSC, от которой работает таймер. Обычно она подключена к системной шине и соответственно работает на частоте процессора. Прежде чем попасть на счетчик частота тактового сигнала уменьшается в PSC + 1 раз (данной значение можно настроить), и потом попадает на счетчик. Счетчик представляет собой обычный регистр. Каждый такт с CK_CNT, увеличивает, либо уменьшает его значение на 1. В случае увеличения, в какой-то момент счётчик достигает значения, которое равно значению в auto-reload регистре. В этот момент генерируется событие, например прерывание, и потом счетчик сбрасывается в 0. После чего весь процесс повторяется снова.

Счетчик таймера

Так например, допустим что частота процессора 48 МГц, счетчик тактируется от системной шины, значение PSC равно 479, а значение autorelaod register равно 1999. В этом случае счетчик инкрементируется с частотой 100 КГц (48000000 / (479+1) = 100000), и с частотой 50 Гц генерирует прерывания (100000 / (1999+1) = 50).

Второй важной частью таймера является канал, обеспечивающий возможности изменения длительности входных сигналов, и генерации ШИМ. Центральной частью канала является capture/compare регистр (рисунок ниже).

Схема первого канала таймера

В режиме сравнения capture/compare регистр заранее записывается некоторое значение, которое постоянно сравнивается со значением счетчика. В случае если это значение меньше или равно значению счетчика, то канал на выходе выдает логическую 1, и если больше логический 0. Например, если значение счетчика изменяется от 0 до 500, то записав в capture/compare 400 или 200, то можно получить на выходе канала сигналы, как показано на рисунке ниже. Так же в момент, когда значение capture/compare равно значению счетчика, можно генерировать прерывания.

В режиме захвата, в результате некоторого события, например, изменения напряжения на пине, в capture/compare регистр записывается текущее значение счетчика, и может вызваться прерывание. Из последнего отметим что таймер имеет один счетчик, но может иметь несколько каналов (таймеры STM32 обычно имеют 4 канала).
Реализация плавного возгорания

Выше описанной теоретической базы достаточно, чтобы реализовать поставленную задачу. Если время для подачи напряжения на светодиод очень мало, то светодиод не успеет полностью возгореть из-за этого он будет выглядеть неярко. И наоборот, если время для подачи напряжения на светодиод велико, то он будет выглядеть ярко. Регулировать время подачи напряжения позволит нам широтно-импульсная модуляция.

Для начала попытаемся сделать неяркое свечения светодиода. Для этого нужно понять с какой частотой должен обновляться счетчик и на какую долю его периода нужно подавать напряжение. Допустим счетчик обновляется с частотой 1Гц, то есть он за 1 секунду достигает какого-то значения записанного в auto-reload регистре и обнуляется. Допустим мы на 1*10^-3 секунды подадим напряжение на диод, то остальные 999*10^-3 секунды напряжение в светодиоде будет равно нулю. Очевидно, что простой в 0.999 секунды будет заметен для глаза, а 0.001 хватает для полного возгорания диода (проверено на практике).

Увеличим частоту обновления счетчика, теперь она будет равна 1кГц, соответственно период будет равен 1*10^-3с, который будет состоять из 1мкс подачи напряжения и 999мкс из нулевого напряжения на светодиоде. Получается диод должен возгорать на 1 микросекунду за каждую миллисекунду. Этого должно хватать…

Давайте теперь запрограммируем это. Для того, чтобы вручную не писать инициализацию воспользуемся средством CubeMX. Для начала необходимо выбрать плату, затем найти пины, которые отвечают за диоды (в STM32F407 это PD12-PD15), нажать на них и в выпадающем списке нужно выбрать TIMx_CHx.

Инициализация светодиодов

Затем найти в правой части окна выбрать привязанный к светодиодам таймер и настроить каналы на ШИМ.

Инициализация каналов таймера на ШИМ

Затем посмотрим на конфигурацию тактирования. Здесь я ничего не менял. Из рисунка видно, что частота процессора является 16МГц.

Clock configuration

Далее «идем» во вкладку Configuration и нажимаем на наш таймер.

Configuration

Теперь преступим к инициализации таймера в соответствии с рассчитанными значениями. В вкладке «Parameter Settings» настраиваем значения Prescaler. Я выставил его на 15, значит частота, с которой будет инкрементироваться счетчик будет 16МГц(частота процессора)/(15+1)=1МГц.

Там же инициируем значение Auto-reload регистра я выставил его в 1000. Следовательно частота обновления счетчика будет 1000/1МГц=1кГц. Именно такие значения мы получили в расчете выше. Далее установим поле Pulse в каждом канале нашего таймера в 1. Этот параметр синоним Capture/Compare регистру и в данном случае соответствует времени (1мкс) подачи напряжения в светодиод (ШИМ).

Инициализация таймера

Далее перейдем во вкладку NVIC Settings и включим там прерывание. Это прерывание возникает тогда, когда значение счетчика равно значению в Auto-reload регистре. (Расскажу чуть позже зачем оно нам нужно).

Включение прерывания

Теперь генерируем код и открываем проект в среде разработки! В main’e после инициализации необходимо стартовать ШИМ на каждом инициализированном канале при помощи функции HAL_TIM_PWM_Start(tim4, TIM_CHANNEL_1).

Перепрошьем контроллер, и если вы все сделали правильно, то диод должен гореть неярко.

Как заставить диод гореть неярко мы разобрались — очень быстро включаем и тут же выключаем не давая ему полностью загореться, а глаз в свою очередь не видит простоя. Для того, чтобы он горел ярче необходимо увеличить время подачи напряжения на диод, то есть, чтобы он постепенно возгорал необходимо постепенно увеличивать значения счетчика capture/compare регистра.

Так как мы включили прерывание, которое будет вызывать обработчик каждый раз, когда значение счетчика будет равно значению Auto-reload регистра, то можно с частотой 1кГц (частота обновления счетчика) увеличивать это значение на 1 или уменьшать в случае затухания.

Перейдем в файл stm32f4xx_it.c и найдем созданную CubeMX’ом функциюvoid TIM4_IRQHandler(void). Это обработчик прерывания, в котором поместим алгоритм программы.

Из листинга программы видно что CurrentPulse увеличивается до тех пор пока не достигнет 1000, что соответствует максимальному значению Auto-reload регистра. При такой конфигурации время возгорания как и время затухания равно 1мс(период обновления счетчика)*1000=1с.

Для того, чтобы работа прерывания по таймеру началась, необходимо в main’е его стартовать и убрать старт ШИМа из предыдущего примера, так как он находится в каждом обработчике.

Старт таймера и его прерывания

После перепрошивки диоды должны плавно возгорать и затухать.

Надеюсь статья была написана доступным языком.
Удачи!

(c) Elijah Shall https://vk.com/@gener_it-plavnoe-vozgoranie-lampochki

Слово о сложности

noreply@blogger.com (Oleg Shall) — Sat, 23 Jun 2018 15:29:00 +0000

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

Заблуждение это настолько устойчиво и старо, что говорили о нем еще со времен древних греков. В новое время серьезно это вопрос поставил Годфрид Лейбниц в своей работе «Рассуждения о метафизике» 1686 года. Потом про это весьма успешно думали и Гёдель, и Гильберт, и Колмогоров, и Чейтин. Всё без толку. Разработчики, часто, не склонны к философскому осмыслению реальности.

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

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

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

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

Кстати, вопросы квантовых вычислений и (берем выше) телепортации объектов (Скотти! Поднимай) упирается именно в вопросы измерений. Ведь если мы будем измерять Спока недостаточно точно, то прилетит совсем не тот Спок. А если точно, то изначального Спока неизбежно надо убить и затратить на это надо огого сколько энергии. (Что же будет с бессмертной душой Спока)

К чему же я так долго подводил?

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

Чем точнее мы хотим описать реальность, тем больше энергии для этого надо затратить. И здесь совершенно не помогут волшебные средства «упрощающие» жизнь исследователя-программиста.

Если вы думаете, что ваш любимый «удобный» язык программирования или среда манипуляции фигурами на экране позволяет вам не думать о сложностях — вы находитесь в плену заблуждений. Язык или среда будет очень приблизительно и очень не точно делать свою работу. А если вам потребуется детальное описание процессов, более тонкая модель, вы неизбежно углубитесь, разберёте проблему до атомов и затратите на это много энергии.

Кстати, вы не заметили, что новые модные языки заметно упростились? Go, Rust, Swift. Языки упростились но усложнились концепции, усложнилась описываемая реальность, а значит, что энергии для описания реальности потребуется очень много.

noreply@blogger.com (Oleg Shall) — Mon, 28 May 2018 13:08:00 +0000

Вот год назад был дикий хайп с Клименко во главе на тему российского мессенджера.

Тогда я, при поддержке “Национальной ассоциации корпоративных директоров”, инициировал попытку обсуждать эту затею в рамках созданного Клименко оргкомитета. Была написана официальная бумага и передана в адрес советника президента. В самом деле, ассоциация штука серьезная, имеет право на законодательную инициативу. В ней живут разные очень компетентные люди. Ассоциация присутствует в 80% компаний с государственным участием. Почему бы нам не сказать “пару умных слов” по этому вопросу. Ответа не поступило. Как происходило обсуждение этого вопроса — не известно. Кому выдали денег — не ясно. Кто победил, за какие заслуги — один Клименко знает.

Ну да Бог с ним, с ответом. Мы же в текущем моменте живем. Что сейчас? Богопротивный телеграм запрещают и активно закрывают. И вот мой вопрос!

Где же обещанный наш, российский мессенджер? Чем он великолепен? Какие у него отличительные качества?

О децентрализации

noreply@blogger.com (Oleg Shall) — Sun, 28 Jan 2018 10:51:00 +0000

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

Каких-нибудь жалких 20 лет назад мир почтовых систем был совершенно децентрализован. Апофеоз децентрализации! На каждом малюсеньком предприятии в углу пылился (и умирал раз в год) серверок, который гонял почту на собственном домене. Правда когда серверок ветшал работа фирмы останавливалась на пару часов (или дней) и под вопли директора в телефон призывался приходящий админ. И конечно каждый приличный гик держал свой сервер дома. Что имеем теперь? Несколько централизованных мировых почтовых, очень даже контролируемых “сами знаете кем”, хабов.

Веб-сайты. Ну конечно, как только появились сайты они начали плодиться у каждого на фирмеах и в домашних подсобках. Что сейчас? Крупные централизованные хост-площадки для сайтов-визиток. Да и нужны ли вообще эти самые сайты? Все вроде уже закончили самовыражаться вычурными шрифтами, кислотными обоями и анимированными снежинками. Для публикации фоток и цитат мудрецов вполне достаточно ленты новостей фейсбука и вконтакта. Даже narod.ru уже кажется не жив.

Мессенджеры! Конечно заря была централизованная. Icq. Кто же не помнит! Но тут же взбунтовались техноанархисты и вспомнили о децентрализации. Свободу попугаям! И придумали jabber/xmpp. Ну совершеннейшая же децентрализация. И опять у каждого приличного гика в подсобке пылился собственный серверок. Что в итоге? Совершеннейшая централизация с подробными записями.

Если хотите мы как-нибудь поговорим о природе этого явления. А сейчас просто помолчим и проникнемся молодецким азартом блокчейн-децентрализаторов. И это было…

Как я воспринимаю историю с блокчейном.

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

В итоге всем будет радостно узнать, что ходы каждого наконец будут записаны.

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

Зажрались мы

noreply@blogger.com (Oleg Shall) — Fri, 12 May 2017 06:34:00 +0000

Зажрались мы. Пора навести порядок! Сколько же можно? Такая террористическая опасность, а тут люди в мессенджерах общаются. Нет у них государственного мышления и осознания сложности момента.

Ну и конечно производителей мессенджеров развелось. Вот я например.

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

Ну да кому это интересно. Представитель Роскомнадзора Вадим Ампелонский лучше знает.

Если мессенджер не выполняет требование Роскомнадзора по регистрации в России или идентификации пользователей, то по решению суда он может быть заблокирован. За неисполнение требований законодательства на владельца мессенджера может быть наложен штраф: для физлиц от 3000 до 5000 рублей; для должностных лиц — от 30 тысяч до 50 тысяч рублей; на юридических лиц — от 800 тысяч до одного миллиона.

В декабре 2016 г. руководитель Роскомнадзора Александр Жаров объяснял, зачем нужна привязка мессенджера к конкретному номеру абонента оператора связи. По словам руководителя Роскомнадзора, речь не идет о проникновении в личную переписку людей. Привязка к номеру нужна спецслужбам, чтобы идентифицировать человека, который в случае чрезвычайной ситуации или террористической атаки пользовался этим номером. «Пока мессенджеры не заключают ни с кем договоров, не платят никаких налогов и живут замечательно», — говорил Жаров. По его словам, после этого операторы «выстроят с мессенджерами товарно-денежные отношения и, таким образом, они опосредованно тоже внесут лепту в российскую экономику».

Dead Moroz

noreply@blogger.com (Oleg Shall) — Wed, 10 May 2017 17:04:00 +0000

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

Он принес мне печальные новости. Ни одна из его, вполне конструктивных, переговорных линий не принесла ожидаемого результата. Несмотря на явный интерес к проекту инвестор сохраняет осторожность. Я начинаю разделять точку зрения некоторых наблюдателей о том, что наши отечественные инвесторы более походят на Деда Мороза. Эдакий мифологический персонаж о котором все говорят, некоторые даже утверждают что его видели и пишут об этом сказочные книги, но существует ли он в реальности? Большой вопрос.

Мы с нашими инициативами постучали в другие двери. Конкурс "Generation-S" отмел нас на старте. ФРИИ пригласил в предакселератор на весьма (с их точки зрения) привлекательных условиях. Они дают 2 миллиона и 970 (как бы не ошибиться) забирают как оплату за курс по продвижению проекта и его упаковки для повышения инвестиционной привлекательности. За это просят смехотворные 15% в бизнесе. (разумеется в случае успеха). А ведь это только начало. А ну как инвестор подтянется. Смущает меня такой деловой подход.

А ведь разговор идет о попытке предоставить множеству бизнесов, магазинчиков и предпринимателей к конечному пользователю в его телефоне. И сделать это максимально комфортным образом через одно маленькое приложение. И дать каждой фирме создать "свое приложение" в этом мире.

Ну что же. Значит не судьба. Буду двигаться своим ходом. Маленькими шажочками, копеечка к копеечке. А конкуренты на этом пути у меня огого какие. Придется интенсивней раскручивать пращу и метить точней.

Куда бы дроны приткнуть?

noreply@blogger.com (Oleg Shall) — Tue, 14 Mar 2017 13:09:00 +0000

Есть у меня весьма приятные знакомые, которым очень хочется помочь и добрым советом и деятельным участием. Они занимаются попытками внедрить в наш простой российский обиход беспилотные летательные аппараты, известные в народе как “БПЛА”.

Многие из нас отцы и рады были рождению сыновей, потому как хочется же в вертолетики поиграть. Все купили, все поиграли. Курс и фарватер, проложенный АСИ на пути технической модернизации нашей богохранимой державы, предполагает использование оных в деле народного хозяйства. На примере наших домашних вертолетиков мы знаем, что летают они мало, заряжаются долго, многих циклов перезарядки дешевые китайские батареи не выдерживают (а своих-то вроде и нет). А куда деваться? На дворе прогресс и трансгуманизм. Вот и создаются на Руси-матушке различные предприятия для этих самых БПЛА. Естественно, с опаской взирая на успехи американских гигинтов, создаются и кластеры объединяющие это все в едином народно-хозяйственном порыве. Все же тоже хотят возить пиццу и пирожки в городе дронами.

Но слабо это, слабо! Нужен размах! Ну какая пицца? Давайте думать как внедрять новые технологии на тучных нивах Ставропольского края. Сели, думаем. Вроде как на бумаге есть дроны с грузоподъемностью до 100 кг., но сколько они летают не очень ясно, сколько заряжаются... Вопросы, вопросы…

Вроде как хорошо бы учинить не аккумуляторные БПЛА, но с ДВС, но не ясно кто такими аппаратами занимается. Другой вопрос насколько они автономны? В смысле беспилотны. В смысле способны без участия человека выполнять какие-то полезные в деловой жизни операции.

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

А вот если бы дрон смог сам переносить из коровника на склад бидоны с молоком. Хотя бы за пару километров. Тогда да. Экономический эффект налицо. Ну или дрон смог бы сам пасти овец перегоняя их на тучные склоны, или сам стоги соломы с поля в силосную яму сваливать. Или хотя бы органический кизяк собирать. Причем сам! Без пульта!

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

Короче. Дорожная карта АСИ — дело конечно хорошее, но между “кропотливой работой” над презентационным слайдом для форсайт-конференций и софтом для распознавания и транспортировки кизяка — дистанция огромна. И ее все равно надо преодолевать ученым и инженерам, чтобы кулак- кровопийца смог экономически эффективно заменить дюжину батраков на красивый дрон с блестящими боками и пропеллерами и заставить его собирать кизяк.

Удивительные дела.

noreply@blogger.com (Oleg Shall) — Tue, 14 Mar 2017 13:09:00 +0000

Удивительные дела творятся в нашем государстве.

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

Недавно имел удовольствие присутствовать на собрании людей, собирающихся сделать очередной “форсайт-кэмп”. Я человек прямой и сразу же задал вопрос о цели этого мероприятия. (А на него планируется где-то из государственных и региональных бюджетов добыть изрядную сумму денег). Ну вот зачем в очередной раз собирать людей? Будет ли там возможность взаимодействовать с реальными инвесторами? Молчание. Для кого собирается этот очередной форум? Чтобы опять помусолить “дорожные карты” АСИ, с наслаждением и придыханием воспроизвести набор загадочных слов, ощутить свою причастность к делу технического прогресса, послушать “визионеров”, которые готовят свои доклады по итогу просмотра канала Discovery-Science.

Движуха ради движухи. Конференция ради конференции. Сколько уже их было? Сколько еще будет? Проведем еще одну!

Ах да! Надо провести бизнес-тренинги и научить молодежь “упаковывать проекты”.

Да Бог же с вами!

Сторителлинг

noreply@blogger.com (Oleg Shall) — Fri, 20 Jan 2017 08:17:00 +0000

Рассказывал одному из переговорщиков суть моего проекта. Ну вот просто так, по шагам.

И придумали люди веб-страницы и стали они множиться под солнцем. И каждый желал себе не волов, но страниц красивых с анимацией и вертикальными параллаксами. И приумножились они и стало их как песка морского... :)
Чтобы в них не потеряться люди придумали поисковые системы. Теперь все зависит от положения в поисковом запросе.
И придумали люди мобильные платформы. И вот тут-то все недостатки веб-решений всплыли и стали выпуклыми. Да насколько, что люди предпочитают пользоваться специально написанными для телефонов и планшетов программами.
И вот опять все стало повторяться. (Ибо нет ничего нового под солнцем.) Каждый магазинчик и каждая лавчонка, не говоря уже о крупных предприятиях, захотели и себе написать приложения. И будет их скоро как песка морского.
Но мы же не можем в свои телефоны поставить миллионы приложений!

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

Google вот внедряет концепцию Instant Application. Но, как он сам говорит, это (фактически) стримминг приложений, терминальное решение. Оно требует серьезного и стабильного канала связи. Но дело даже не в этом. Дело в том, что хостить графические приложения на стороне сервера для терминальной трансляции клиенту - очень дорогое и совершенно непродуктивное занятие.

А вот мы, в рамках проекта Kalpa, придумали срединное решение. Оно позволит:

Передавать интерфейс удаленного приложения максимально компактно,
Графика создается на стороне клиента
Сервер может обрабатывать на порядки больше сессий нежели в терминальном режиме.
А программу писать как простую десктопную
И безопасно конечно. Потому что у клиента ничего не остается. Можно с любовницей переписываться. Жена не узнает.

И создать можно очень интересное глобальное решение. Интернет приложений.

Боты - жалкие шутки. Реальные удобные интерфейсы непосредственно в коммуникаторе или карте - выбор нового времени.

Вот такая история.

К вопросу о кросплатформенности в деле создания мобильных приложений.

noreply@blogger.com (Oleg Shall) — Thu, 19 Jan 2017 17:52:00 +0000

Интересно отметить, что разработчики используют нативные средства создания мобильных приложений. Для платформы Android использует Java, для ios -- Objective-C, для MsPhone -- C#. А для десктопов пишут вообще бог знает на чем.

На практике это означает необходимость содержать несколько команд для поддержки, порой весьма сложного, комплекса FrontEnd систем. Эти команды должны обладать специфическими и значительными компетенциями в своем мире.

Наш подход несколько иной. Используя С++ мы получили возможность разрабатывать системы для всех платформ в единой кодовой базе. Нет необходимости привлекать разработчиков для разных платформ. Компетенции можно поддерживать на высоком уровне, а из взаимозаменяемость позволяет разработчикам без дополнительного обучения заниматься разными платформами.

Мы определенно считаем такой подход значительно более экономичным.

К вопросу об организации оркестратора кластера в деле бесшовного ввода новых версий Kalpa-системы.

noreply@blogger.com (Oleg Shall) — Thu, 05 Jan 2017 07:24:00 +0000

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

За контроль топологии системы. Знает какие узлы существуют в системе и какие службы эти узлы обслуживают.
Мониторит отказ отдельных узлов и перебалансировку топологии системы.
Осуществляет плавное обновление системы.

Каждая служба (кроме слоя сервера приложений) имеет свой набор сетевых портов ожидания. Каждая версия использует только один из трех портов. SystemControl всегда знает расписание портов текущей и прошлой версии. Таким образом можно одновременно держать несколько версионных слоев служб на всем пространстве узлов.

Схематиченый сценарий ввода в работу новой версии все системы таков.

Соединение специальной утилитой с SystemControl и инициация протокола запуска новой версии системы.
Загрузка через SystemControl исполняемых файлов и библиотек всех служб системы.
Активация новой версии SystemControl на новом порте ожидания.
Новая версия SystemControl (из общей со старой версией базы) получает список всех рабочих узлов системы и через старую версию NodeControl, работающую на каждом узле, передает файлы и библиотеки новой версии на каждый узел.
На каждом рабочем узле активируется новая версия NodeControl на новом порте ожидания.
После того как получено подтверждение о запуске новой версии NodeControl начинается процесс активации внутренних служб согласно текущей топологии системы. Стартуют все службы кроме серверов приложения.
После подтверждения старта внутренних служб новая версия SystemControl начинает процесс активации слоя новых версий серверов приложений. Для этого ->

SystemControl соединяется со старой версией NodeControl (на узле AS) и отключает старый сервер приложений.
SystemControl соединяется с новой версией NodeControl (на узле AS) и активирует новую версию сервера приложений.
В службе ASControl все активные AS-серверы удаляются и "взводится" первый рабочий сервер приложения.
Каждый последующий запущенный сервер регистрируется в ASControl, что происходит практически мгновенно.

SystemControl перехватывает управление соединяясь со старой версией NodeControl на всем пространстве запущенных узлов и получает доступ к статистической информации о системе.
Когда на всех узлах AS (ApplicationServer) прекращается обслуживание последней доживающей пользовательской сессии, можно с уверенностью сказать, что все пользователи, использующие старый слой сервера, завершили свою работу.
После завершения работы последнего пользователя старой версии все уровни внутренних служб гасятся через NodeControl каждого узла.
После гасятся сами NodeControl, ASControl и SystemControl старой версии.
Система полностью и плавно переходит на новую версию.

Простой системы (в части обработки поступающих запросов на установку новой сессии) минимален (несколько миллисекунд).

Такая архитектура позволяет держать несколько версионных слоев системы одновременно. Считаю, что 3 одновременно работающих версии более чем достаточно даже для весьма масштабного кластера.

Новости госмессенджеров.

noreply@blogger.com (Oleg Shall) — Tue, 13 Dec 2016 08:19:00 +0000

«Развитие IT-технологий является приоритетом работы правительства Республики Крым. Наш президент в своём послании Федеральному собранию назвал развитие цифровой экономики вопросом национальной безопасности и технологической независимости России. Глава государства обратил особое внимание на риски, связанные с цифровыми технологиями, и необходимость защиты от киберугроз», — отметил Сергей Аксёнов.
Андрей Назаров уточнил, что свои разработки программисты могут представить на третьем ялтинском форуме в апреле следующего года. Отметим, что Назаров также занимает пост председателя правления Ялтинского международного экономического форума.
Госконтрактом с крымским правительством уже заинтересовались разработчики российского мессенджера Dialog, которые участвуют в конкурсе Института развития интернета на создание государственного мессенджера для федеральных чиновников.

«Мы готовы принять участие и в разработке закрытого безопасного мессенджера для крымских чиновников, в свете чего планируем проведение масштабной презентации корпоративного мессенджера Dialog в дни прохождения ялтинского форума в апреле 2017 года», — заявил Андрей Кузнецов, директор по информационным технологиям мессенджера Dialog.

https://russian.rt.com/russia/article/341179-chinovniki-krym-messendzher

Новости часа.

noreply@blogger.com (Oleg Shall) — Mon, 12 Dec 2016 08:48:00 +0000

К вопросу о моем сообщении про QTcpSocket

Может еще рано радоваться, но тикету присвоили статус "Important".
Надеюсь все же разобраться. Я конечно приготовился делать свой HeartBeat. И даже провел подготовительные работы. Но все же...

Опять про QTcpSocket и disconnected

noreply@blogger.com (Oleg Shall) — Mon, 12 Dec 2016 04:33:00 +0000

Казалось бы, все понятно и все ситуации разобраны. Ан нет.
Известная история. Как определить, что tcp-соединение разорвано? Ответ - настройки keepalive.

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

НО

Если после разрыва в сокет были записаны данные, сигнал о разрыве не выбрасывается. Более того, write фиксирует успех записи данных. bytesToWrite показывает 0, что означает, что данные уже записаны в канал. state сокета показывает QAbstractSocket::ConnectedState.

Не поленился написал тестовый пример для демонстрации описываемого эффекта.

void SocketTransport::onConnected()

{
qDebug()<<"OnConnected";
mSocket.setSocketOption(QAbstractSocket::KeepAliveOption, 1);
int Idle=2;
int Count=3;
int Interval=2;
if(setsockopt(static_cast<int>(mSocket.socketDescriptor()), IPPROTO_TCP, TCP_KEEPIDLE,
&Idle, sizeof(Idle))<0)
qDebug()<<"Error setsockopt IPPROTO_TCP, TCP_KEEPIDLE";
if(setsockopt(static_cast<int>(mSocket.socketDescriptor()),IPPROTO_TCP, TCP_KEEPCNT,
&Count, sizeof(Count))<0)
qDebug()<<"Error setsockopt IPPROTO_TCP, TCP_KEEPCNT";
if(setsockopt(static_cast<int>(mSocket.socketDescriptor()), IPPROTO_TCP, TCP_KEEPINTVL,
&Interval, sizeof(Interval))<0)
qDebug()<<"Error setsockopt IPPROTO_TCP, TCP_KEEPINTVL";
mTimer.start(100);
}

void SocketTransport::writeData()

{
qDebug()<<"BYTES to write"<<mSocket.bytesToWrite()<<mSocket.state();
if(mSocket.state()==QAbstractSocket::UnconnectedState)
{
qDebug()<<"Unconnected state";
QCoreApplication::processEvents();
return;
}
QUuid id=QUuid::createUuid();
QByteArray data=id.toByteArray();
qDebug()<<id<<data.size();
qDebug()<<mSocket.write(data, data.size());
//qDebug()<
//QCoreApplication::processEvents();
}

https://drive.google.com/open?id=0B1NCPMWs3oAFVjk3ZVJSNUZIWTg

Определяем параметры KeepAlive и по таймеру пишем в сокет данные. Выдергиваем кабель и получаем описываемый эффект. (по ссылке архив с полным примером). Все тестировалось в Linux c Qt5.7 и Qt5.8

На всякий случай вчера запостил сообщение в Qt-группу и открыл тикет. Что-то мне подсказывает, что результата не будет.

Значит придется делать свои heartbeat эхозапросы. Не ждать же пока ситуация разрешится сама.

Если я не прав, очень прошу наставить на путь истинный.

Cmake заметки.

noreply@blogger.com (Oleg Shall) — Wed, 07 Dec 2016 11:39:00 +0000

После того как cmake научился для Qt5 автоматически "мокать" необходимые заголовки многие разучились это делать руками. А это иногда нужно.
Вот например, есть у вас в одном проекте класс с одинаковым именем, но в разных пространствах имен (и в разных каталогах, разумеется). И не говорите, что так не бывает. Еще как бывает.
Так вот, стандартная опция

set(CMAKE_AUTOMOC ON)

будет генерить файлы с одинаковыми именами в каталоге сборки и обязательно приведет к ошибке.
Что делать? Мокать файлы самому. Для этого.

Установим set(CMAKE_AUTOMOC OFF)
Определим переменную header set(header ..... ) в которой перечислим необходимые для moc заголовочные файлы.
Скажем qt5_wrap_cpp(moc ${header})
В add_library добавим ${moc}

После этих манипуляций cmake будет рад в каталоге сборке создать внутренние служебные каталоги с созданными moc-файлами. Конфликтов имен при такой сборке не будет.

Web и мобильные решения.

noreply@blogger.com (Oleg Shall) — Sun, 04 Dec 2016 08:31:00 +0000

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

На настольных компах недостатки web-решений были терпимыми, но с приходом мобильных платформ пользователь обнаружил недостатки со всей яркой выпуклостью. И он сделал свой выбор!
90% народа на телефонах и планшетах предпочитает специально созданные приложения их web-версиям. Спираль развития технологий начала свой новый виток и вот уже опять все новые и новые фирмы (и даже отдельные люди) захотели создавать свои собственные приложения для телефонов и работать со своими клиентами именно через них. И это верно и хорошо!
Но мы же не можем поставить на свои телефоны тысячи приложений.
Можно использовать терминальный подход и стримить приложения в телефон. Можно в приложения встроить обычный браузер.
Но можно пойти по срединному пути. Нужно научиться создавать множество сетевых быстрых и удобных мобильных приложений и доставлять их пользователю через один единственных клиент. И надо переосмыслить принципы доступа с множеству приложений. Опора на проактивность и интегральные решения могут стать возможностью создать новую экосистему сетевых приложений.

И мы говорим фирмам.
Вы же все равно собираетесь заказывать мобильные приложения. Давайте поиграем в новую игру. В новую проактивную экосистему где ваши услуги будут доступны пользователю сразу и по запросу. Не надо создавать отдельное приложение. Мы создадим вашу фрагмент мозаики и добавим его целое произведение.
Кому нужна эта глупая реклама и "продвижение" в поисковых запросах.

QtCreator 4.2_rc1 (Новая версия. Найденные проблемы.)

noreply@blogger.com (Oleg Shall) — Sat, 03 Dec 2016 08:48:00 +0000

В QtCreator (с некоторых пор) активно использую clang-режим для фоновой постоянной проверки корректности программы. Средство весьма дорогое.
В 4.2 длительное использование большого числа открытый файлов приводит к захвату значительных объемов памяти. Редко используемые файлы, которые однако же открыты в проекте, не выгружаются. (хотя эта особенность была заявлена) Становится практически нормой держать "в голове" 8-9 гигов для работы clangbackend в активном проекте. Хорошая штука, к которой я очень быстро привык. Очень не хочется с ней расставаться.

В clang-режиме при вводе и редактировании QObject::connect первый аргумент (объект генерирующий сигнал) не автокомплетится. При автокомплете сигналов и слотов в новой нотации выставляются скобки (как и в 4.1)

При редактировании конструктора родительский конструктор не автокомплетится.
Автозакрытие и контроль скобок обрабатывается некорректно. (Дозволяет создавать лишние)

Вроде починили постоянные проблемы в настройке системы сборки cmake+makefile+codeblocks. Раньше все норовил переключиться на сmake+ninja+codeblocks.

И конечно особо мерзкий баг - неверно выставляемые #define при создании нового класса. Всегда в дефайнах указывалась полная нотация пространства имен.

Указать эти ошибки в баг-репортах или сами увидят?

Kalpa проактивный бизнес-коммуникатор. Презентация бизнес-плана.

noreply@blogger.com (Oleg Shall) — Wed, 09 Nov 2016 14:20:00 +0000

Kalpa business plan presentation from Oleg Shalnev

Презентация дополнена и улучшена.

Kalpa business plan presentation from Oleg Shalnev

О децентрализации

noreply@blogger.com (Oleg Shall) — Tue, 08 Nov 2016 07:40:00 +0000

Как же радостно наблюдать за бурными обсуждениями светлого децентрализованного будущего. Вот расставим мы по всей "ивановской" майнинг-центры и, натурально, все банки и нотариальные конторы немедленно исчезнут. Но мысли о том, что и это уже было под солнцем не покидают.

Если хотите мы как-нибудь поговорим о природе этого явления. А сейчас просто помолчим и проникнемся молодецким азартом блокчейн-децентрализаторов. И это было...

Как я воспринимаю историю с блокчейном.

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

В итоге всем будет радостно узнать, что ходы каждого наконец будут записаны.

Вы же этого хотели?

Прогнозы и предсказания.

noreply@blogger.com (Oleg Shall) — Wed, 02 Nov 2016 05:02:00 +0000

В этом очередном прогнозе интересна следующая часть.

Все услуги будут доступны через единый интерфейс

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

Ровно эту мысль я и стараюсь донести уже довольно давно. Интересно другое! В Китае эту мысль уже поняли и активно развивают непосредственно в инициативе WeChat.
Экосистема сетевых приложений должна и будет развиваться через единственный интерфейсный канал.

http://rb.ru/story/5-predictions-by-belski/

Почему никто не хочет общаться с вашим чат-ботом

noreply@blogger.com (Oleg Shall) — Sun, 16 Oct 2016 13:07:00 +0000

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

Выражу сомнения еще раз.

В мессенджерах можно и нужно передавать удобные графические интерфейсы.

И мы знаем как это сделать.

Именно поэтому мы развиваем нашу платформу и предлагаем InterfaceMessaging.
Мы можем встраивать приложения непосредственно в мессенджер. И даже дополнительно ничего ставить не надо.

Инвесторы, вы прогораете с инвестициями в боты? Может уже пора исследовать альтернативы?

Ботам предрекали блестящее будущее, в котором они заменяют бизнесу мобильные приложения, но ничего подобного не происходит. Даже по трендам поиска в Google видно: чат-боты резко набрали популярность в апреле 2016 года, когда Facebook открыл для них свой Messenger, и так же быстро её растеряли. Недавно предприниматель Андрей Загоруйко признался, что его стартап, интеллектуальный помощник для клиентов интернет-магазинов Quest.ai, провалился. И это лишь один из примеров.

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

Продакт-дизайнер Дэн Грувер посчитал, что для заказа пиццы в диалоге с ботом нужно нажать на экран 43 раза — против нескольких нажатий в хорошо спроектированном мобильном приложении или на мобильной версии сайта.

http://secretmag.ru/article/2016/10/13/sergej-korol/?utm_source=sffb&utm_medium=social&utm_campaign=glavnaya-problema-sostoit-v-tom--chto-obsch

noreply@blogger.com (Oleg Shall) — Tue, 23 Aug 2016 06:45:00 +0000

Iri presentation (3) from Oleg Shalnev

noreply@blogger.com (Oleg Shall) — Sat, 21 Mar 2015 14:09:00 +0000

«Косвенно тезисы Сноудена подтверждает опрос IT-специалистов, проведенный нами в конце 2014 года. 46% респондентов сообщили, что потеря их мобильного устройства и последующая кража корпоративной информации из его памяти подвергнут риску их компании», — сообщил «Газете.Ru» Оськин.

А я в рамках проекта KalpaCloud давно именно об этом и говорил. Основа безопасности лежит в архитектуре программных систем.
Вы построили мир на вебе, публичной почте. Вы гоняете данные на сторону клиента, которые хранятся во внутренних кешах браузера.
Что же вы еще хотите? Безопасности?

Сравнение WiredTiger c Postgres (домашний тест)

noreply@blogger.com (Oleg Shall) — Sun, 01 Mar 2015 12:59:00 +0000

Когда говорят интересно и показывают фигуры о прекрасном всегда хочется почесать затылок и понять что же есть на самом деле. Не скрою, я весьма воодушевился сообщением о выходе мотора баз данных WiredTiger. Он, как говорят, настолько хорош, что его взяли на вооружение в MongoDB.

Значит надо проверить.

Учинил простой тест. Создается таблица из двух полей. Ключ - строка, значение- строка. Ключ, понятное дело, primary key. Для поля "value" строится индекс. В варианте с Pg получается два индекса. (Как рулит первичным ключем WT еще надо разбираться. Но фактически WT создает только 2 файла а Pg 3(один с данными и 2 с индексами. Значит Pg будет оперировать собственно таблицей и двумя индексами, что всяко сложно)
Добавляемые строки - случайные UUID

В WT создание таблицы выглядит вот так.

ret = session->create(session, "table:access", key_format=S,value_format=S,columns=(key, value)");
ret = session->open_cursor(session, "table:access", NULL, NULL, &cursor);
session->create(session, "index:access:value", "columns=(value)");

Тест для Wt

QTime tm;
tm.start();
for(int i=0; i<1000000 font="" i="" nbsp="">{

QByteArray keyarray=QUuid::createUuid().toString().remove('{').remove('}').toLocal8Bit();
QByteArray valuearray=QUuid::createUuid().toString().remove('{').remove('}').toLocal8Bit();
cursor->set_key(cursor, keyarray.data());
cursor->set_value(cursor, valuearray.data());
ret = cursor->insert(cursor);

}

qDebug()<<"Insert million of pairs"<

Тест для Pg

for(int i=0; i<1000000 br="" i="" nbsp=""> Command.prepare("insert into test(id, value) values(:id, :value)");
Command.bindValue(":id", QUuid::createUuid().toString());
Command.bindValue(":value", QUuid::createUuid().toString());
Command.exec();
}

WT использует отложенную модель записи, потому в PG отключим fsync.

Запускаем тест несколько раз и замерим время работы процедуры на пространстве возрастающих данны По итогу пяти прогонов для WiredTiger получил такие результаты в секундах

97 (Круто)

316 (Прилично)

743

1188

2193

Для Postgres получил

500
690
1000
1196
955

На пятом миллионе WT скис окончательно спустившись до 2193 секунд. При этом Postgres дает стабильные и прогнозируемые результаты.
Давайте не будем забывать, что WiredTiger это ядро, менеджер записей, а Postgres - полновесная база данных со всем набором вытекающих из этого сложностей.

Для очистки совести я добавил шестой миллион записей в Pg в одной транзакции. Получил результат 611.
Честно не очень понимаю что за фигуры показывают на презентации свидетели Wt и Mongo.

Вывод. Конечно я не великий спец в тестировании и со своими драными лаптями зря полез в эту тему, но мне все же кажется, что лучшее - враг хорошего.потому, сижу спокойно на Postgresql иногда поглядывая на новомодные штуки.