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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В этой статье я создам приложение на основе открытой и бесплатной платформы 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-систему останавливает не финансовые затраты на покупку и доработку, а необходимость миграции со старой системы. У них есть сотни или даже тысячи пользователей, которые выполняют свои бизнес-процессы в одной программе, и каким-то образом их нужно всех пересадить в другую без какой-либо остановки для бизнеса.

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

В последнее время на рынке появилось огромное количество новых языков программирования: Go, Swift, Rust, Dart, Julia, Kotlin, Hack, Bosque – и это только из числа тех, которые на слуху.
Ценность того, что эти языки привносят в мир программирования, тяжело переоценить, но, как правильно в прошлом году отмечал Y Combinator, говоря про инструменты разработки:

Фреймворки становятся лучше, языки немного умнее, но в основном мы делаем то же самое.

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

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

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

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

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

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

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

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

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

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

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

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

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