Страницы

Cmake заметки.

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

  1. Установим set(CMAKE_AUTOMOC OFF)
  2. Определим переменную header set(header ..... ) в которой перечислим необходимые для moc заголовочные файлы.
  3. Скажем qt5_wrap_cpp(moc ${header})
  4. В add_library добавим ${moc}
После этих манипуляций cmake будет рад в каталоге сборке создать внутренние служебные каталоги с созданными moc-файлами. Конфликтов имен при такой сборке не будет.


[898]


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

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

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

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

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

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

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


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

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

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

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

[900] Планы на день.


Актуализируюсь после полного обновления Glan- ядра. Перешел на внутреннюю стек-машину.

  • Подсистема мониторинга спящих (временно разъединенных) сессий. Служебный сервер, существующий на каждом узле сервера приложений.
    • PortAnnouncer - PortAnnouncerServer
    • PortGetter  PortGetterServer
    • PortDeannouncer PortDeannouncerServer
  • Реализация процесса-коммуникатора для клиента восстанавливающего свое соединение.


Еще 900 шагов к цели

Времени остается все меньше и меньше. А дела?
С коммуникатором дела клеятся вяло. Подача и презентация проекта в GenerationS успехом не увенчалась.
Фрии проект приняла, пройдено очередное собеседование и нас пригласили в программу акселератора на июнь 2017 года. Предложение в разработке, обсуждается. Но дожить же еще надо.
Партнеры в Москве усиленно проводят переговоры с фондами и прямыми инвесторами.
Наш переговорщик будет неформально представлять проект на инвестиционных форумах в Сочи и Краснодаре.
Но переговоры переговорами, а непосредственно работать над проектом приходится мне в гордом одиночестве.
За последние месяцы наработано очень много материала, который надо привести в порядок, актуализировать.
Для себя я формально выделил 900 дней для проактивной бизнес-сети и реализации ограниченного набора софт-проектов. Потом хочу немного переключиться и заняться другими мне интересными делами.



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

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

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

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

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

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

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

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

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


Позволю себе процитировать небольшой фрагмент.

Кроме того, госмессенджер должен будет работать через веб-браузеры (Chrome, Firefox, Safari), а также работать в виде SaaS-решения (Software is the Service). Продукт должен будет иметь возможность работать и в офлайне, предоставляя доступ к архиву сообщений.
Верно ли я понимаю суть цитаты? Если будет предоставлена возможность работать в офлайне, то сообщения будут храниться локально на рабочем месте пользователя. Мы говорим о "толстом клиенте". 

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

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

Такие вот различная постановка задачи.

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

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

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


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

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


http://rb.ru/story/5-predictions-by-belski/
Related Posts Plugin for WordPress, Blogger...