Подскажите пожалуйста, как теперь читать вообще все посты, а не только подписки? То ли лыжи не едут, то ли я…
UPD: Кажется, нашёл. Вот оно что — Меню -> Посты…
Рефлексия очень помогает, если надо расширить язык — например, реализовать собственный RPC-механизм или сделать скриптовый язык, который прозрачно и безболезненно интегрируется в код — все объекты и типы данных будут видны из скрипта практически автоматически. Но для этого требуется мощная рефлексия времени выполнения, а она за один присест не появится, она требует некоторой эволюции, например, как в Qt.
В дополнение к вашим планам — если кому-нибудь интересно, я бы мог написать статью о том, как сделать из eBox промышленный компьютер, который не боится выключения питания и готов к длительным аптаймам.
Для eBox хорошо подошёл Tiny Core Linux, который использует persistence storage для файловой системы, это даёт полную свободу напрямую выключать ему питание в любое время и быть уверенным в целостности ОС и файловой системы (http://wiki.tinycorelinux.net/wiki:persistence_for_dummies). Увы, на русском подобных статей не нашёл, собирал информацию по крупицам с официального форума.
Ну и могу поделиться образами Tiny Core 4.x для Vortex86 и Vortex86SX, если кому надо. У самого есть в работе eBox 3300MX (промавтоматика) и eBox 2300SX (домашний мини-сервер).
Поделитесь, за сколько примерно реально купить самую младшую на сегодняшний момент модель eBox? Ну, допустим, 2300SX (его с натяжкой хватает на мои нужды).
Можно ли уложиться в $100, включая расходы на доставку?
То же самое для разновидностей 3300 модели (3300A-M, 3300-JSK и т.д.) — минимальная цена примерно какая? Меня интересует мелкий опт.
Было бы очень здорово почитать способы приобрести eBox дешевле, чем на каком-нибудь ipc2u.ru. У них большой ассортимент, но цены немного неадекватные, на мой взгляд.
Можете привести примеры неттопов?
eBox хороши именно в промавтоматике — в них нет ни одной движущейся детали. Требования по аптайму обычно в этой области — месяцы и годы в тяжёлых условиях (перепады температур. пыль и грязь и т.д.).
Спрашиваю, потому что я сам бы с радостью перешёл на что-то более дешёвое, лишь бы полноценная ОС там завелась и можно было заказывать оптом сразу много.
eBox — полезные машинки, особенно в промавтоматике.
Правда, с eBox 2300SX пришлось повозиться для запуска на нём Linux, т.к. в нём отсутствует мат. сопроцессор, и потому пришлось перекомпилировать ядро с включенной эмуляцией.
В Qt 5 ему Q_CORE_EXPORT добавили. Насколько я догадываюсь, он очень плотно должен использоваться для QML, чтобы строить «мост» между скриптовыми объектами и объектами из Qt, может, поэтому…
Можно сделать ещё больше интересных вещей, если обмануть мета-систему, введя фейковый QObject.
Для этого может помочь QMetaObjectBuilder, который, по всей видимости, скоро станет часть публичного API. Например, можно прикидываться любым объектом и делать всякие прокси, которые могут логировать все вызовы Q_INVOKABLE-методов, сигналов и т.д.
Тогда получается, что для решения нетривиальных проблем UI дизайнер должен погружаться в предметную область.
Например, задача — разработать тач-интерфейс для управления беспилотным самолётом. Как такую задачу решить, не будучи разработчиком или хотя бы пользователем, знакомым с предметом?
На мой взгляд, хороший UI дизайнер должен полностью, по уши погрузиться в предметную область и понимать её не хуже (а то и лучше!) разработчиков, поэтому таких людей и мало.
Так ведь программы это и есть те самые DS-языки, которые предоставляют пользователям удобные для их сферы абстракции. Только не всегда DSL должны быть представлены в виде текста, но ведь в некоторых областях эффективны другие способы «программировать»: для дизайнера удобнее крутить ручки в Photoshop, для инженера удобнее строить 3D-модель с помощью мыши и т.д.
А «настоящие» программисты как раз и создают эти DSL с помощью языков общего назначения, облегчая решение задач для «ненастоящих» программистов, однако и те, и другие занимаются программированием (т.е. алгоритмизацией).
Я позавчера собирал под Android на Linux, нашёл косяки с поставляемыми CMake-скриптами и с Android SDK.
Во время компиляции появилась ошибка про отсутствие папки «17.0.0» в одной из подпапок Android SDK, проверил — 17-я версия установлена. Снёс её и переставил — нужная папка появилась.
Запустил приложение на QtQuick 2 на Android, выявилась дичайшая проблема с шрифтами: чем больше длина строк в приложении, тем сильнее артефакты при отрисовке текста, текст становится практически нечитаем.
Ещё не понравились костыли в виде автосгенеренного класса QtQuick2ApplicationViewer и его подпроекте с какими-то шаманскими скриптами деплоя, я просто использовал QQuickView — всё прекрасно завелось.
UPD: Кажется, нашёл. Вот оно что — Меню -> Посты…
Для eBox хорошо подошёл Tiny Core Linux, который использует persistence storage для файловой системы, это даёт полную свободу напрямую выключать ему питание в любое время и быть уверенным в целостности ОС и файловой системы (http://wiki.tinycorelinux.net/wiki:persistence_for_dummies). Увы, на русском подобных статей не нашёл, собирал информацию по крупицам с официального форума.
Ну и могу поделиться образами Tiny Core 4.x для Vortex86 и Vortex86SX, если кому надо. У самого есть в работе eBox 3300MX (промавтоматика) и eBox 2300SX (домашний мини-сервер).
Можно ли уложиться в $100, включая расходы на доставку?
То же самое для разновидностей 3300 модели (3300A-M, 3300-JSK и т.д.) — минимальная цена примерно какая? Меня интересует мелкий опт.
eBox хороши именно в промавтоматике — в них нет ни одной движущейся детали. Требования по аптайму обычно в этой области — месяцы и годы в тяжёлых условиях (перепады температур. пыль и грязь и т.д.).
Спрашиваю, потому что я сам бы с радостью перешёл на что-то более дешёвое, лишь бы полноценная ОС там завелась и можно было заказывать оптом сразу много.
Правда, с eBox 2300SX пришлось повозиться для запуска на нём Linux, т.к. в нём отсутствует мат. сопроцессор, и потому пришлось перекомпилировать ядро с включенной эмуляцией.
Для этого может помочь QMetaObjectBuilder, который, по всей видимости, скоро станет часть публичного API. Например, можно прикидываться любым объектом и делать всякие прокси, которые могут логировать все вызовы Q_INVOKABLE-методов, сигналов и т.д.
Например, задача — разработать тач-интерфейс для управления беспилотным самолётом. Как такую задачу решить, не будучи разработчиком или хотя бы пользователем, знакомым с предметом?
На мой взгляд, хороший UI дизайнер должен полностью, по уши погрузиться в предметную область и понимать её не хуже (а то и лучше!) разработчиков, поэтому таких людей и мало.
А «настоящие» программисты как раз и создают эти DSL с помощью языков общего назначения, облегчая решение задач для «ненастоящих» программистов, однако и те, и другие занимаются программированием (т.е. алгоритмизацией).
Во время компиляции появилась ошибка про отсутствие папки «17.0.0» в одной из подпапок Android SDK, проверил — 17-я версия установлена. Снёс её и переставил — нужная папка появилась.
Запустил приложение на QtQuick 2 на Android, выявилась дичайшая проблема с шрифтами: чем больше длина строк в приложении, тем сильнее артефакты при отрисовке текста, текст становится практически нечитаем.
Ещё не понравились костыли в виде автосгенеренного класса QtQuick2ApplicationViewer и его подпроекте с какими-то шаманскими скриптами деплоя, я просто использовал QQuickView — всё прекрасно завелось.