Запуск Raspberry Pi с полной поддержкой графики на microSD, навсегда остающейся в режиме read-only после установки системы. Отсутствие какой-либо записи данных на флэш-память повышает надёжность устройства, приближая его к промышленному классу изделий. Пошаговая инструкция. Небольшой театр инженерного абсурда для развлечения аудитории.

Мне понадобилось сетевое устройство с открытым кодом и выходом HDMI, и я решил попробовать Малиновый Прог. Да, я именно так предлагаю переводить Pi: Прог. Понятное дело, даже одноплатнику нужна операционка. И вот, захожу я на официальный сайт, ожидая встретить там подробное руководство по созданию суровой, неломаемой Вещи à la turnkey box. Но народ, как ни в чём не бывало, устанавливает Ubuntu (т.е. Raspbian Jessie) прямо на microSD, размещая и swap там же. Как обычный десктоп, face palm.

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

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

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

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

По уровню сложности язык платформы не сильно отличался от SQL, который изначально создавался не для программистов, а для бизнес пользователей. Поэтому мы также решили указать в качестве должности “Бизнес аналитик”.

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

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

Совсем недавно мы опубликовали статью с описанием проблем одной из самых популярных технологий, используемых в IT, и на наше удивление она вызвала достаточно живой интерес (во всяком случае для технической статьи). Поэтому мы решили на этом не останавливаться, и сегодня мы «идем в гости» к одному из самых популярных продуктов на российском рынке разработки бизнес-приложений — платформе 1С.

Так сложилось, что на хабре многие 1С не любят, но порой складывается впечатление, что немногие из этих людей хорошо понимают, за что они его не любят. Этой статьей мы восполним этот пробел и убьем сразу двух зайцев: с одной стороны, расскажем, как в 1С все устроено изнутри, а с другой стороны — почему это все работает не так как нужно / хотелось бы. Надо сказать, что 1С многими своими решениями смог реально нас удивить, впрочем, не будем забегать вперед.

Статей с критикой 1С на Хабре достаточно (например, один, два, три), но, на мой взгляд, они либо слишком много внимания уделяют всяким мелочам, вроде неправильной организации меню, либо рассуждают о слишком абстрактных вещах, в которых 1С, возможно, и не виноват. В этой же статье, как и в статье про SQL, речь пойдет исключительно о фундаментальных (и вполне осязаемых) проблемах, которые касаются всех и каждого, кто разрабатывает / дорабатывает решения на 1С, и приводят либо к существенному росту порога вхождения, либо к серьезному падению производительности, либо к значительным трудозатратам со стороны разработчика.

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

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

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

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

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

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

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

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

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

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

Весь код для реализации этого приложения будет состоять из около 300 значащих строк.

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

Однако, одна из проблем такого подхода заключается в том, что это значительно удорожает и замедляет сам процесс разработки. Что если всего этого нет? Тогда на помощь приходит IDE, благодаря которой можно изучить текущую логику по “голому” коду.

Когда мы разрабатывали платформу lsFusion со встроенным языком, то у нас было несколько вариантов. Либо изобретать велосипед, и писать с нуля свою собственную IDE, как сделал в свое время 1С, или реализовать плагин к уже существующей. Мы пошли по второму пути, и в этой статье я покажу, что получилось.

В 1С одним из ключевых элементов системы являются регистры. Этот термин имеет свой аналог в английском языке — ledger. Он первоначально появился в бухгалтерской практике, но со временем его логика начала использоваться и в других сферах.

В отличие от 1С, где регистры являются одним из встроенных типов, в самой платформе lsFusion такого понятия нет. Зато в ней есть наследование, полиморфизм и агрегации, что, в частности, позволяет реализовать аналогичную логику регистров. В этой статье на примерах я покажу как именно.

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

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

Без преувеличения можно сказать, что SQL — один из самых распространенных в мире языков. Информационные системы могут быть написаны на Java, Python, JavaScript, C#, PHP и десятке других языков, но SQL база в том или ином виде будет в абсолютном большинстве таких систем. Среди бизнес-приложений процент систем, использующих SQL, вообще стремится к 100%.

При этом большинство существующих материалов о SQL на хабре и других ресурсах сводятся к простым вопросам, вроде: «какие типы соединений бывают», «чем левое соединение отличается от правого», «что такое триггеры» и так далее. Более того, в этих материалах практически ничего не говорится о проблемах SQL (и его реализациях), которых на самом деле очень и очень немало. Поэтому мы решили восполнить оба этих пробела: с одной стороны рассказать, как многие вещи в SQL работают изнутри, а с другой стороны — почему они работают не так как нужно / хотелось бы.

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

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

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

Итак, мы продали клиенту программный B2B продукт.

На презентации ему все нравилось, но в ходе внедрения выяснилось, что кое-что все-таки не подходит. Можно конечно сказать что нужно следовать “best practice”, и изменить себя под продукт, а не наоборот. Это может сработать, если у вас есть сильный бренд (например, из трех больших букв, и вы можете послать всех на три маленькие буквы). В противном случае, вам быстро объяснят, что заказчик добился всего благодаря своим уникальным бизнес-процессам, и давайте-ка, лучше меняйте свой продукт, или ничего не получится. Есть вариант отказаться и сослаться на то, что лицензии уже куплены, и с подводной лодки деваться уже некуда. Но на относительно узких рынках такая стратегия долго работать не будет.

Приходится дорабатывать.

Во время проведения WWDC 2019, одним из самым больших и захватывающих моментом был анонс релиза SwiftUI. SwiftUI — это совершенно новый фреймворк, который позволяет проектировать и разрабатывать пользовательские интерфейсы с написанием меньшего количества кода, декларативным способом.

В отличие от UIKit, который обычно использовался в сочетании с storyboards, SwiftUI полностью основан на программном коде. Тем не менее, синтаксис очень прост для понимания и проект можно быстро просмотреть с помощью Automatic Preview.

Поскольку SwiftUI использует язык Swift, он позволяет создавать приложения той же сложности с гораздо меньшим количеством кода. Более того, использование SwiftUI автоматически позволяет приложению использовать такие функции, как Dynamic Type, Dark Mode, Localization и Accessibility. Кроме того, он доступен на всех платформах, включая macOS, iOS, iPadOS, watchOS и tvOS. Итак, теперь ваш код пользовательского интерфейса может быть синхронизирован на всех платформах, что дает больше времени для того, чтобы сосредоточиться на второстепенном платформо-зависимом коде.

Всем привет, дорогие друзья! Вот сижу, смотрю на бесконечную простыню кода, провожу ревью с баночкой ред була. Прошел год. Год, блин, всего лишь год — так много и так мало одновременно. На этот год у нас были наполеоновские планы, и сейчас кажется, что мы мало что успели. С другой стороны — нам удалось сделать кое-что, что достойно войти в анналы айти с пометкой «Слабоумие и отвага». Я бы назвал эту историю «Как запилить свой движок с тулзами и рендером с нуля всего за год». Издание выйдет на несколько томов, но куда деваться, надо с чего-то начинать. Так что погнали!

Ровно год назад мы стартовали с проектом, о котором я теперь планирую писать во всех подробностях. С высоты полученного опыта могу смело заявить: это одна из самых рискованных и амбициозных штук, которую мы когда-либо затевали. Думаю, опыт нашей команды будет полезен другим гейм-разработчикам, ну а игроков он как минимум повеселит.

Третья и заключительная часть серии статей о языке lsFusion (ссылки на первую и вторую части)

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

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

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

В этой статье я покажу, каким образом такая концепция позволяет быстро и удобно балансировать запись и чтение в базу данных без какого-либо изменения логики работы. Похожий функционал попытались реализовать в современных коммерческих СУБД (в частности, Oracle и Microsoft SQL Server). В конце статьи я покажу, что получилось у них, мягко говоря, не очень.

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

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

Мир баз данных давно захвачен реляционными СУБД, в которых используется язык SQL. Настолько сильно, что появляющиеся разновидности называют NoSQL. Им удалось отбить себе определенное место на этом рынке, но реляционные СУБД умирать не собираются, и продолжают активно использоваться для своих целей.

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