ABOUT US

Our development agency is committed to providing you the best service.

OUR TEAM

The awesome people behind our brand ... and their life motto.

  • Neila Jovan

    Head Hunter

    I long for the raised voice, the howl of rage or love.

  • Mathew McNalis

    Marketing CEO

    Contented with little, yet wishing for much more.

  • Michael Duo

    Developer

    If anything is worth doing, it's worth overdoing.

OUR SKILLS

We pride ourselves with strong, flexible and top notch skills.

Marketing

Development 90%
Design 80%
Marketing 70%

Websites

Development 90%
Design 80%
Marketing 70%

PR

Development 90%
Design 80%
Marketing 70%

ACHIEVEMENTS

We help our clients integrate, analyze, and use their data to improve their business.

150

GREAT PROJECTS

300

HAPPY CLIENTS

650

COFFEES DRUNK

1568

FACEBOOK LIKES

STRATEGY & CREATIVITY

Phasellus iaculis dolor nec urna nullam. Vivamus mattis blandit porttitor nullam.

PORTFOLIO

We pride ourselves on bringing a fresh perspective and effective marketing to each project.

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

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


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

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

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

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

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

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

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

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

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

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


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

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

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

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

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



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

    В сети можно встретить кучу статей и видео на эту тему, но на мой взгляд очень много интересной теоретической и практической части остаются без внимания. В этой статье вы узнаете о: 
    • таймерах; 
    • широтно-импульсной модуляции (ШИМ/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 делятся на следующие группы:
    1. базовые таймеры. Умеют только генерировать прерывания с заданной частотой; 
    2. таймеры общего назначения. Имеют весь функционал базовых таймеров, но также могут измерять длительность импульсов и генерировать сигналы с широтно-импульсной модуляцией;
    3. расширенные таймеры. Умеют делать тоже самое, что и таймер общего назначения, но имеют дополнительные возможности по генерации сигналов для управления двигателями и периферией.
    Рассмотрим общую структуру таймера на примере таймера общего назначения, представленного на рисунке ниже. Не пугайтесь ее, все проще, чем кажется, тем более далеко не все элементы нужно понимать для осознания работы таймеров ;)

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

    Из основных элементов таймера выделим счетчик (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
  • Слово о сложности

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Copyright (c) Oleg Shall. Технологии Blogger.

    WHAT WE DO

    We've been developing corporate tailored services for clients for 30 years.

    CONTACT US

    For enquiries you can contact us in several different ways. Contact details are below.

    Oleg_old

    • Street :Road Street 00
    • Person :Person
    • Phone :+045 123 755 755
    • Country :POLAND
    • Email :contact@heaven.com

    Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.

    Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation.