Графические оболочки *

В первой части мы показали как создать алгоритм работы на основе «конечных автоматов» в SimInTech и использовать его совместно с «классическими» алгоритмами в виде функционально блочных диаграмм.

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

Введение

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

В настоящее время все необходимые настройки реализованы в специальной библиотеке блоков, которая обеспечивает создание моделей систем в виде конечных автоматов, (представление State Flow) и может быть использована при создании моделей управления.

В данной статье показан пример использования элементов библиотеки «Конечные автоматы» для создания системы управления.

Нашел пару опросов на эту тему за 2012 год, стало интересно как сейчас обстоят дела.

Заодно решил добавить возможность выбирать несколько, если на PC и ноутбуке они разные.

Урок №1
Данная статья написана для новичков, которые (как и я) хотят научиться писать программы для Андроид с использованием OpenGL. Основные мысли и код взяты из замечательной книги Кевина Бразалера «OpenGL ES 2 for Android. A Quick-Start Guide by Kevin Brothaler» (1).
Зачем же пересказывать, спросите вы? Дело в том, что перед этой книгой я прочитал еще десяток статей на эту тему и код Кевина у меня сразу не пошёл (в книге среда разработки Eclipse, а у меня Android Studio). Поэтому, решил написать эту статью так, чтобы было понятно, прежде всего, самому себе.
Для начала давайте выясним, что такое OpenGL. Если почитать Википедию (2), то увидим следующее:
«OpenGL (Open Graphics Library) — спецификация, определяющая независимый от языка программирования платформонезависимый программный интерфейс для написания приложений, использующих двумерную и трёхмерную компьютерную графику.
Включает более 300 функций для рисования сложных трёхмерных сцен из простых примитивов. Используется при создании компьютерных игр, САПР, виртуальной реальности, визуализации в научных исследованиях. На платформе Windows конкурирует с Direct3D.»
Мы будем изучать укороченную версию OpenGL ES 2 (в дальнейшем OpenGL). Укоротили её по понятным причинам, у Андроид малая операционная память по сравнению с настольными ПК, наличие виртуальной машины Java также накладывает определенные ограничения. Наверно есть еще много причин, почему это сделали, но нас это не должно волновать. Просто нужно знать, что есть прекрасный инструмент OpenGL и надо научиться им пользоваться!

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


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

Но возможно ли настроить BIM-процесс на базе открытых форматов и, если да, то с чего начать? Как от красивой теории перейти к практике? Мы постарались ответить на эти вопросы в онлайн лекции, проведенной на прошлой неделе. В рамках мероприятия мы, рассматривая теорию, привели пример практического взаимодействия между двумя BIM решениями: венгерским программным продуктом для архитектурного проектирования ARCHICAD и российским инженерным решением nanoCAD Электро для проектирования электротехнической части здания.

Материал настоятельно рекомендуется лицам, интересующимся информационным моделированием (технологией BIM) и новостями из мира САПР.

UPG от автора: данная статья была написана 2 года назад (а это очень много для ИТ-отрасли), но по-прежнему является одной из самых читаемых. 16.11.2018 года я прочитал вебинар для Университета Минстроя (https://niisf.org/), в котором дал обновленную информацию. Наверное, я обновлю эту статью в соответствии с последними изменениями рынка и теории BIM, но сейчас желающие могут посмотреть материал на YouTube-канале организаторов вебинара: www.youtube.com/watch?v=lKVkE1reOVY

В последнее время разговоров о BIM много: эту технологию называют нашим будущим, проводятся семинары, на которых аргументируют необходимость ее внедрения, приводят расчеты, показывают красивые иллюстрации, демонстрируют успехи… Со скоростью роста сугробов в снегопад появляются BIM-эксперты, «евангелисты», менеджеры, преподаватели. В общем, технология явно активно входит в нашу жизнь.


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

Это обзор и частичный перевод статьи Advait Sarkar из Computer Laboratory, University of Cambridge «The impact of syntax colouring on program comprehension».

Краткое содержание

Взяли 10 случайных «computer science» студентов-магистров из University of Cambridge (на самом деле 7, так как 3 очкарика оказались частично несовместимы с оборудованием Tobii2 X120 eye tracker). Предложили разбираться с короткими вычислительными задачами на Python (надо было назвать корректный результат выполнения кода). Замеряли время выполнения задач. Не давали ничего записывать на бумажке (только думать, можно вслух). Следили за глазами с помощью упомянутой окулографической системы.

В конце попросили оценить свой опыт в программировании (да, с учетом возможного эффект Даннинга — Крюгера).

Выводы

• Подсветка помогает быстрее понимать код. На примере 6 задач с общим временем решения в 13 — 20 минут:
  
  • 8.4 секунды разницы между медианами времени выполнения задачи (с гипотезой, что для больших задач эффект становится заметнее)
  • значительное (на 23 штуки) уменьшение количества переключений внимания (переводов и фиксации взгяда с места чтения на различимо другую область задания)
• эффективность помощи обратнопропорциональна квалификации (но нелинейно, т.е. не установлено, что когда-то подсветка перестанет помогать)
• работает только в том случае, если вы знаете что каким цветом подсвечивается
• мозг может игнорировать подсказки подсветки, если вы «ищете свободным поиском» (т.е. подсветка не мешает размышлять)

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



В общем, все хорошо, всем цветов!

Графики, цифры и более подробные выводы из статьи:

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

Он-лайн переводчик Oxford Dictionaries провозгласил словом 2015 года вовсе не слово, а один из emoji, известный в интернете как «лицо со слезами радости». В прошлом году победу одержало слово «vape» (электронная сигарета), а за год до него — излюбленное «selfie». Традиция выбирать слово года продолжается с 2004, но никогда прежде подобной чести не удостаивалась картинка.

Это 4-я статья цикла по разработке, управляемой моделями. В предыдущих статьях мы познакомились с OCL и метамоделями, Eclipse Modeling Framework и Sirius. Сегодня научимся описывать метамодели в текстовой нотации (а не в виде диаграмм как раньше) и познакомимся с табличным представлением моделей в Sirius. Сделаем это на примере кризиса среднего возраста и метода анализа иерархий. Возможно, это пригодится вам при разработке ИИ в играх, при принятии решений или в работе.

Все мы, так или иначе, пользуемся Photoshop. Но знаем ли мы историю возникновения знаменитого графического редактора? Когда я был моложе, и впервые увидел, как работают в Photoshop, то задался вопросом: Каким же умным нужно быть, чтобы все это придумать? Рунет просто завален уроками, переводами уроков, и обзорами плагинов к фотошопу. Я решил добавить разнообразия и рассказать вам о том, как все начиналось.

Это третья статья цикла, посвященного разработке, управляемой моделями. В предыдущих статьях мы разбирались с OCL и метамоделями, создавали свою метамодель для языка Anchor с древовидным редактором. Сегодня сделаем редактор Anchor-диаграмм.

Добрый день, Иван
Здравствуйте

Расскажите, пожалуйста, что такое проект Code Club, с чего он начинался, кто его придумал?
Code Club — это британская инициатива по обучению детей 9-11 лет основам программирования. Она возникла около трех лет назад и с тех пор бурно развивается — в начале в самой Великобритании, а спустя некоторое время и по всему миру. В Великобритании сейчас уже более 2000 локаций, там это всё поддерживается на государственном уровне: есть база волонтёров, есть база локаций — всё очень серьёзно организовано. После перехода рубежа в 1000 локаций проект начал выходить на международный уровень. Примерно с лета 2013 года заработал сайт codeclubworld.org — занимаются им те же британцы, но задача у них уже более глобальная: координировать обучение детей программированию по всему миру, дать возможность каждому ребёнку получить знания об основах информатики.

Тогда же, летом 2013-го года было объявлено о старте осенью проекта Code Club в Украине. Были названы первые города, в которых планировалось открытие первых локаций и были контактные данные координатора. Так всё начиналось.

Что входит в программу обучения?
Первые семестры проекта Code Club рассказывают о разработке программ с помощью визуального программирования. Мы учим детей работе в среде Scratch — это разработка MIT, которая создавалась именно под возраст 9-11 лет. В следующих семестрах Code Club изучается HTML, CSS и Python.

В nanoCAD Plus 7, который вышел 18 мая 2015 года, появился ряд функций, существенно расширяющих область применения и позиционирование платформы nanoCAD. Мы предлагаем вниманию наших читателей ряд технических статей, в которых подробнее погружаемся в эти функции, рассматриваем «какими возможностями они обладают» и «как их можно применить на практике». Данная статья посвящена функции «Перспективной навигации».

^{Aqua Mine}

Введение

После многолетнего доминирования дисплеев с высокой плотностью пикселей на мобильных устройствах, данная тенденция наконец-то дошла и до лаптопов с десктопами. По моему мнению, производители не ставили HiDPI-матрицы в основном из-за слабой поддержки DPI, отличных от 96, в Windows. К счастью, ситуация заметно улучшилась с выходом Windows 8 с Modern UI, хотя в десктопном режиме все еще далеко не идеальная — люди до сих пор жалуются на 3200×1800 при 13.3" в лаптопах и сомневаются о покупке 4K UHD 23.8"-монитора.

DPI и Linux

Возможность установки произвольного значения DPI появилась еще во времена Xfree86, но следует понимать, что это просто значение, которое ничего не делает само по себе. Его считывают и используют программы и компоненты, которые и принимают решение, каким образом отразить изменение DPI на экране. Если текст следует установленному значению DPI в 95% случаев (спасибо xft!), то размер элементов зависит от используемого окружения рабочего стола и тулкитов, на которых написаны приложения.

GTK+ 3-приложения поддерживают как целочисленный скейлинг элементов и дробный скейлинг шрифтов, так и изменение DPI на лету, без перезапуска приложений. Скейлингом элементов управляет переменная окружения GDK_SCALE, а скейлингом шрифтов — GDK_DPI_SCALE.
По умолчанию, шрифты скейлятся вместе с элементами. Таким образом, при DPI 96 и GDK_SCALE=2, вы получите шрифт, словно он с DPI 192. Чтобы отменить скейлинг шрифтов, достаточно установить переменную окружения GDK_DPI_SCALE в 0.5 (для GDK_SCALE=2).
Qt4 не умеет скейлить элементы. Для применения нового значения DPI требуется перезапуск приложения.
Qt5, начиная с версии 5.4, поддерживает целочисленный скейлинг элементов через переменную окружения QT_DEVICE_PIXEL_RATIO. DPI менять на лету нельзя, как и в Qt4, но работы в этом направлении ведутся и будут доступны с релизом Qt 5.6, как и скейлинг на каждый монитор отдельно.
WxWidgets-приложения ведут себя так же, как GTK+ 3, только не поддерживают скейлинг элементов.

Я попытался выяснить, какие DE можно комфортно использовать с HiDPI-мониторами. Тестирование проводилось на лаптопе с 12.5" 1366×768 (125 DPI) с подключенным внешним 23.8"-монитором с разрешением 3840×2160 (185 DPI).

27 февраля состоялся очередной Python Meetup. В этот раз мы обсуждали:

• Hy — диалект, который позволяет Lisp-разработчикам использовать библиотеки Python, а Python’истам найти решение для некоторых проблем языка, например, отсутствия скобочек.
• Toga — библиотека построения интерфейсов на Python, которая с первого взгляда выглядит как простой и универсальный инструмент, но на деле имеет ряд недоработок.

Во время Lightning Talk участники делились опытом экспорта .doc-файлов и идеями использования AST для трансляции Python в Ruby, JavaScript, C++ и др.

В последнее время появилось достаточно много мониторов с высоким разрешением, 150 dbi и выше, особенно в ноутбуках. И при этом всё выглядит жутко маленьким.
Причина этого — система думает что у Вашего монитора разрешение 96..100 dpi.
Решать это только увеличением размера шрифта неправильно, т.к. размеры всех остальных элеменов интерфейса остаются маленькими. Надо чтобы графическая оболочка сама это делала.

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

Ниже будет идти список где что поправить, все параметры привожу для своего монитора — 13,3" при 2560x1600, это даёт 226 dpi. Более высокое разрешение сейчас я видел только в ноутбуке Fujistu U904 — 262 dpi.

Третья часть моего поста (предыдущую можно найти тут)

В этом кусочке назначаем кнопки мыши и клавиатуры. Небольшое примечание: для Mod4 + PrntScr я назначил делать скриншот выделенной области, а на просто PtntScrn скриншот всего экрана, но второй случай не работает — не доходят руки разобраться (для скриншотов вам понадобится установить пакет xsnap

Продолжение моего т.н. знакомства с WM Awesome

Первая часть статьи тут.

Тут объявляем все виджеты, которые буду использоваться. Сразу стоит отметить баг — при нажатии клавиши «отключить звук» звук исчезает, при повторном нажатии — на виджете отображает, что звук включён, но его нету. Приходится прописывать команду вручную в консоли, странно. Пока не нашёл как его исправить. И ещё смущает отображаение громкости — 90% по факту ~70 единиц в alsamixer, надо бы исправить, но никак не дойдёт руки. Ну а остальное вроде как интуитивно понятно

Разговор пойдёт о моём первом знакомстве с таким оконным менеджером, как Awesome. Долгое время я использовал Gnome2, потом пробовал Gnome3, решил испробовать kde, но ничего из этого не удовлетворило меня. Да, к слову, у меня Gentoo. Да, статья ориентирована на таких же как и я новичков — дабы упростить жизнь.