Если бы этот подход действительно так хорошо работал, кто‑нибудь бы уже написал весь необходимый тулинг и сэкономил бы своей компании миллионы.
Нет, хороший тулинг требует усилий на его разработку и других трудновыполнимых условий. Поэтому обходятся вечными "временными решениями" в стиле тяп-ляп. Поскольку разрабатывать хранилище данных с методологией 6NF непосредственно на SQL чрезвычайно трудозатратно и чревато ошибками, то берут экселевские таблички с метаданными и обрабатывают их на Python. Тоже трудозатратно, но не так ужасно, как на SQL. Системные аналитики, которые готовят таблички с метаданными, Python'ом практически не владеют, но хорошо владеют SQL. Поэтому нужны еще и разработчики на Python. И всё равно технология 6NF+Excel+Python+SQL слишком сложна для большинства компаний. DSL решил бы эту проблему - он похож на SQL, и удобен для системных аналитиков.
Ну или разбогател бы, продавая коробочный продукт.
На таких вещах как компилятор, разбогатеть невозможно. Спиратят, скопируют.
Ситуация, что среди всех разработчиков мира просто никто не догадался, но вот вы открыли миру глаза, и сейчас народ побежит бесплатно реализовывать вашу задумку, представляется маловероятной.
Действительно, никто пока не догадался сделать DSL для 6NF. Есть красивая и удобная (хотя местами странная и переусложненная) ERD для 6NF под названием Anchor Modeler, которая выдает непонятный программный код огромного объема на SQL Server (энтузиасты сделали плагины и для других СУБД). Но именно DSL для 6NF нет в природе. Вы, наверное, не догадываетесь, сколько есть прекрасного оупенсорсного софта. Яркий пример - PostgreSQL.
Скорее всего, это узкоспециализированная задача, нужная малому кругу лиц.
В России 6NF (под брендом Anchor Modeling) используют Авито, Яндекс Такси и ВТБ. Это не значит, что другим компаниям это не нужно. Но применение 6NF без DSL сложно, мало какая компания может себе это позволить, и поэтому нет хайпа. А раз нет хайпа, то мало кто вообще знает про 6NF и тем более понимает ее.
Отсутствие активности вокруг вашей статьи косвенно подтверждает эту версию.
Вовсе нет. Просто чем сложнее и дальше от быта тема, тем меньше активности на Хабре. Миллион статей про Arduino и нелепые требования к резюме, и полторы статьи про хранилища данных.
Вы просто пишете несколько библиотечных функций
Попробуйте сделать MVP. Может быть, его разовьют. Python выглядит подходящим для такой роли и имеет весьма изощренные способы работы со строками.
Чувствуется, что Вы вообще не в теме, и не смотрели репозиторий по ссылке в статье. 6NF экономит огромные человеческие и вычислительные ресурсы при внесении изменений в хранилища данных. И это веский стимул для разработки DSL! Но из-за отсутствия удобных инстпрументов 6NF используется в очень небольшом количестве компаний. Писать километровые запросы для 6NF на SQL очень трудоемко и чревато ошибками.
А то, что Вы предложили, - вообще не решение, а ухудшение,так как вместо километровых запросов на SQL Вы по сути предлагаете писать еще более трудоемкие программы на C# при отсутствии разработчиков на C# в штате. Ни за какую пару вечеров это сделать невозможно. Каждое изменение в структуре данных придется анализировать и программировать заново, так как набор параметров будет всякий раз совершенно разный. Плюс к тому, СУБД не понимает C#, а значит всё-таки придется делать транслятор с C# на SQL или другие языки, которые поддерживает СУБД, либо вносить изменения в ядро СУБД на языке C (для PostgreSQL), что равно по трудоемкости разработке транслятора с DSL.
DSL предназначен для системных аналитиков, которые хорошо владеют SQL, но в лучшем случае имеют поверхностное представление о C#. Не хотелось бы даже привлекать Python, котрым системные аналитики (в отличие от аналитиков данных) владеют плохо. Лучше всего было бы оставаться в экосистеме SQL, а именно, внедрить DSL в PostgreSQL
Проблема совершенно очевидная: беспилотным автомобилям нужна неразрывная сеть "умных" изолированных магистральных дорог или полос движения без перекрестков, где эти беспилотные автомобили смогут проявить свои лучшие качества (высокая скорость, короткие дистанции между транспортными средствами, высокая провозная способность дорог, предотвращение перегрузки дорог, согласование транспортных потоков и т.п.). Там, где беспилотные автомобили запускают в специальных зонах, всё более-менее, хотя они там тащатся с черепашьей скоростью. Но их упорно пытаются выпихнуть в дикие условия мегаполисов с наглыми и неумелыми водителями, ямами на дорогах и т.п. Конечно, провал за провалом. И никакими усовершенствованиями беспилотных автомобилей эту проблему не решить. Камеры будут утыкаться в пробку впереди, "подрезающие" автомобили с соседних полос движения и неадекватов на электросамокатах. Да там хоть обвешайся камерами и лидарами, никакие суперкомпьютеры и ИИ не помогут. На обычных дорогах нужно или снизить скорость до относительно безопасных 20 км/ч, или передать управление водителю.
Legacy must die. Любая информационная система лет через 10-20 обрушивается под тяжестью накопленных ошибок или новых требований и заменяется новой. Вот для этого и нужно новое средство разработки
Ну что ж, давайте попросим сообщество провести эксперимент - отредактировать AST с помощью LLM и посмотреть, что из этого получится. Мне кажется, что ничего хорошего, так как LLM часто теряет контекст, галлюцинирует, забывает, своевольничает и т.п.
У ИИ очень плохо с логикой, но зато "хорошо" с галлюцинациями. Проблема как раз в текстовой основе, в том, что LLM думает не структурно, а является просто гипертрофированной системой автодополнения кода или T9. Грубо говоря, LLM - это балаболка. Решая техническую проблему человек сначала думает структурно, иногда даже зрительными образами. А потом эту структуру он транслирует в речевой поток, который строится путем "автодополнения", как и в LLM. Но у LLM нет в основе четкого структурного представления действительности, а есть только зыбкие и противоречивые правила, заимствованные из промптов. Поэтому и посредственные результаты. Сейчас все еще господствует ошибочное представление, что LLM решат все наши проблемы, и поэтому нужно просто расслабиться и ничего больше не предпринимать.
Отказ от текстового программного кода - это как раз попытка использовать реальное превосходство человека над LLM в способе мышления. И это может дать гораздо более качественный и экономически эффективный программный код (учитывая цену ошибки и необходимость в код-ревью). При этом LLM вполне может использоваться для поиска, подсказок и т.п.
Нужные мутации уже есть (их при желании можно найти в интернете, и это не блок-схемы). Но они еще неразвитые. А на развитие нужен капитал. А чтобы он появился, действительно нужен какой-то веский стимул (безопасность?). Но пока всех устраивает разработка по принципу тяп-ляп и в продакшн, я такого стимула тоже не вижу. Проблема еще и в том, что разработка инструментов (компиляторы, линтеры, IDE) редко бывает выгодной - компании или пользуются пиратскими инструментами, или дают своим разработчикам что-нибудь оупенсорсное. Видимо, лед тронется, когда когда-нибудь крупная IT компания решит сделать инструмент для себя, и каким-то неожиданным образом ее взгляд упадет на идею хранения программного кода в AST или, может быть, с помощью языка разметки AST.
Реакция здесь очень разная. Например, сейчас у Вашей статьи уже 30 плюсов, значит, есть много сторонников. Люди зачастую на любые новшества реагируют негативно (см. синдром утенка), но это не означает что они правы. Прав тот, кто окажется прав в конечном счете, а игра еще только начата.
Есть еще один важный момент: графическое программирование на основе всякого рода блок-схем (программирование роботов, Дракон, Camunda, Anchor Modeler, ETL) дискредитировало идею отказа от текстового представления программного кода. Блок-схемы имеют очень ограниченный успех в узких нишах, потому что блок-схемы неудобны для больших проектов (не умещаются в поле зрения, требуют усилий по поиску блоков и изменению расположения блоков), порождают плохой программный код и имеют ограниченные выразительные возможности (не реализуют многие необходимые возможности языков программирования). Но большинство людей просто не представляют себе других вариантов, кроме бесконечного листинга текстового программного кода (в лучшем случае разделенного на модули) или столь же неоглядной блок-схемы.
Я думаю, что визуальное представление программного кода должно быть блочным - не в смысле блоков блок-схем любого типа, а в смысле структурного программирования. Циклы и ветвления должны отображаться в виде блоков-виджетов в прокручиваемой вкладке или карточке. Последовательно обрабатываемые инструкции должны образовывать вертикальные списки, как строки в программном коде на Python. Вкладки и карточки должны организовываться в базу данных с различными инструментами поиска, а не только с поиском по древовидному списку. Модули должны организовываться в слои и иные группы, соответствующие выбранным архитектурным паттернам.
Вместо клавиатурного ввода должны в основном использоваться разнообразные средства интерфейса, в том числе с использованием автодополнения кода и ИИ. Потребуется внести изменения и в синтаксис языка. Например, точки с запятой для разделения операторов и фигурные скобки для тела функции уже не будут нужны - их заменят виджеты.
Система управления версиями должна быть встроенной (Git, прощай!). Должны быть встроенные средства для удаленной работы. Для предотвращения vendor lock-in должны быть открытые стандарты, форматы и протоколы.
А вообще многие комментарии к этой статье, направленные против отказа от текста, на самом деле полезны для отказа от текста, так как эти комментарии раскрывают реальные проблемы, для которых нужно просто найти решение.
Вспомним теперь, что на самом деле большинство ветвей эволюции были тупиковыми, а их представители вымерли, не оставив потомства. И где теперь эти трилобиты, динозавры и саблезубые тигры? Эволюция никогда не кончается. Утверждать, что текст - это венец творения, - это примерно то же самое, что утверждать, что 640 КБ хватит всем
Не нужно ничего парсить. AST должно строиться непосредственно средствами инструмента со встроенным линтером, а не парситься из текста программного кода. Тогда будет невозможно сделать что-нибудь некомпилируемое.
Сомнительные аргументы. Помимо молотка, лопаты и колеса уже давно существуют шуруповерт, экскаватор и лодка/самолет/поезд на магнитной подушке. А кроме привычного нам текста есть схемы, таблицы и графический интерфейс. Тоже, кстати, созданные людьми для людей. И наскальная живопись появилась задолго до глиняных табличек с текстом. Удивитиельно, что многие разработчики настолько консервативны, что сходу и не задумываясь отторгают всё, что не связано с текстовым редактором, к которому когда-то были приучены.
Было бы ошибкой сериализовать в текст! Если уж Вы решились порвать с текстом, то нужно это делать не только в способе хранения программного кода, но и в способе отображения программного кода человеку. Никому на самом деле не нужен единый текст программы (листинг), если логически он состоит из проектов, слоев, модулей, функций, циклов и т.п. Способ отображения программного кода должен повторять его логическую структуру. Для этого есть самые разнообразные элементы интерфейса: вкладки, карточки, блоки, древовидные списки и т.д.
То, за что Вы взялись, совершенно правильно. Но это не что-то совершенно новое. Советую изучить имеющийся опыт в этой области:
Эксперты из разных областей считают, что уровень софинансирования в размере 70% при 30% собственных средств может быть доступен для крупных предприятий
Крупные предприятия не родят ничего принципиально нового из-за своей забюрократизированности, неповоротливости и внутренних интриг. Стартапы и эксперты останутся за бортом. Деньги "освоят". Красивые отчеты нарисуют. 30% якобы расходов бизнеса профинансируют за счет 70% субсидии - по части схематозов нам нет равных
такой уровень возмещения трат стимулирует искать дополнительное финансирование из внебюджетных источников
"Скупой платит дважды"
100% компенсации привело бы к росту расходов государства без мотивации для бизнеса
О какой такой мотивации бизнеса речь? Мы хотим "НИОКР по современным технологиям", или чтобы толстосумы рискнули своими 30% ради только им выгодных проектов? Или тот, кто предоставляет субсидию, хочет "соломки подстелить", разделив ответственность с бизнесом?
Заявки принимают до 9 июля 2025 года
Аутсайдеры не рассматриваются. Только свои, у которых заявки уже готовы
процент компенсации должен зависеть от объёма НИОКР и успеха коммерциализации, при этом приоритет следует отдать химии и материаловедению. Также эксперты отмечают критичность развития микроэлектроники
Так всё-таки прибыль или же современные технологии и безопасность компонентной базы?
Понятно, почему современные технологии рождаются только в оборонке. Узколобый бухгалтерский подход и пресловутые распилы не позволяют им появиться в гражданских отраслях
Добавили бы линию уже пройденного пути, а то при отключениях GPS и глючной ориентации карты "по направлению движения" невозможно понять, где находишься и в какую сторону движешься. На сложной местности приходится включать еще и Gaia GPS, переключаться между ним и навигатором, и батарея разряжается очень быстро.
А еще пригодилось бы отображение линии маршрута до цели (или хотя бы метки или стрелки, указывающей нужное направление движения) на экране телефона в режиме видоискателя (как перед фотосъемкой).
И еще было бы хорошо выделять названия полей: Образующих первичный ключ - жирным шрифтом Содержащих UUID - синим #0043CE (для индексируемых или входящих в первичный ключ) или оранжевым #F34900 (в остальных случаях) шрифтом Дат начала и окончания действия записи - зеленым шрифтом #56B259 Даты создания записи и номера версии записи - фиолетовым шрифтом #B45CC0
Нет, хороший тулинг требует усилий на его разработку и других трудновыполнимых условий. Поэтому обходятся вечными "временными решениями" в стиле тяп-ляп. Поскольку разрабатывать хранилище данных с методологией 6NF непосредственно на SQL чрезвычайно трудозатратно и чревато ошибками, то берут экселевские таблички с метаданными и обрабатывают их на Python. Тоже трудозатратно, но не так ужасно, как на SQL. Системные аналитики, которые готовят таблички с метаданными, Python'ом практически не владеют, но хорошо владеют SQL. Поэтому нужны еще и разработчики на Python. И всё равно технология 6NF+Excel+Python+SQL слишком сложна для большинства компаний. DSL решил бы эту проблему - он похож на SQL, и удобен для системных аналитиков.
На таких вещах как компилятор, разбогатеть невозможно. Спиратят, скопируют.
Действительно, никто пока не догадался сделать DSL для 6NF. Есть красивая и удобная (хотя местами странная и переусложненная) ERD для 6NF под названием Anchor Modeler, которая выдает непонятный программный код огромного объема на SQL Server (энтузиасты сделали плагины и для других СУБД). Но именно DSL для 6NF нет в природе. Вы, наверное, не догадываетесь, сколько есть прекрасного оупенсорсного софта. Яркий пример - PostgreSQL.
В России 6NF (под брендом Anchor Modeling) используют Авито, Яндекс Такси и ВТБ. Это не значит, что другим компаниям это не нужно. Но применение 6NF без DSL сложно, мало какая компания может себе это позволить, и поэтому нет хайпа. А раз нет хайпа, то мало кто вообще знает про 6NF и тем более понимает ее.
Вовсе нет. Просто чем сложнее и дальше от быта тема, тем меньше активности на Хабре. Миллион статей про Arduino и нелепые требования к резюме, и полторы статьи про хранилища данных.
Попробуйте сделать MVP. Может быть, его разовьют. Python выглядит подходящим для такой роли и имеет весьма изощренные способы работы со строками.
Чувствуется, что Вы вообще не в теме, и не смотрели репозиторий по ссылке в статье. 6NF экономит огромные человеческие и вычислительные ресурсы при внесении изменений в хранилища данных. И это веский стимул для разработки DSL! Но из-за отсутствия удобных инстпрументов 6NF используется в очень небольшом количестве компаний. Писать километровые запросы для 6NF на SQL очень трудоемко и чревато ошибками.
А то, что Вы предложили, - вообще не решение, а ухудшение,так как вместо километровых запросов на SQL Вы по сути предлагаете писать еще более трудоемкие программы на C# при отсутствии разработчиков на C# в штате. Ни за какую пару вечеров это сделать невозможно. Каждое изменение в структуре данных придется анализировать и программировать заново, так как набор параметров будет всякий раз совершенно разный. Плюс к тому, СУБД не понимает C#, а значит всё-таки придется делать транслятор с C# на SQL или другие языки, которые поддерживает СУБД, либо вносить изменения в ядро СУБД на языке C (для PostgreSQL), что равно по трудоемкости разработке транслятора с DSL.
DSL предназначен для системных аналитиков, которые хорошо владеют SQL, но в лучшем случае имеют поверхностное представление о C#. Не хотелось бы даже привлекать Python, котрым системные аналитики (в отличие от аналитиков данных) владеют плохо. Лучше всего было бы оставаться в экосистеме SQL, а именно, внедрить DSL в PostgreSQL
Трюкачество - это антипаттерн, а не "фундамент". Такой переусложненный программный код писать не нужно, а узнать, что он выдает, можно простым тестом
А Microsoft Access или 1С не пробовали? Зачем сразу из пушки по воробьям?
Проблема совершенно очевидная: беспилотным автомобилям нужна неразрывная сеть "умных" изолированных магистральных дорог или полос движения без перекрестков, где эти беспилотные автомобили смогут проявить свои лучшие качества (высокая скорость, короткие дистанции между транспортными средствами, высокая провозная способность дорог, предотвращение перегрузки дорог, согласование транспортных потоков и т.п.). Там, где беспилотные автомобили запускают в специальных зонах, всё более-менее, хотя они там тащатся с черепашьей скоростью. Но их упорно пытаются выпихнуть в дикие условия мегаполисов с наглыми и неумелыми водителями, ямами на дорогах и т.п. Конечно, провал за провалом. И никакими усовершенствованиями беспилотных автомобилей эту проблему не решить. Камеры будут утыкаться в пробку впереди, "подрезающие" автомобили с соседних полос движения и неадекватов на электросамокатах. Да там хоть обвешайся камерами и лидарами, никакие суперкомпьютеры и ИИ не помогут. На обычных дорогах нужно или снизить скорость до относительно безопасных 20 км/ч, или передать управление водителю.
А как насчет генерации UUIDv7?
commit
Documentation
Legacy must die. Любая информационная система лет через 10-20 обрушивается под тяжестью накопленных ошибок или новых требований и заменяется новой. Вот для этого и нужно новое средство разработки
Ну что ж, давайте попросим сообщество провести эксперимент - отредактировать AST с помощью LLM и посмотреть, что из этого получится. Мне кажется, что ничего хорошего, так как LLM часто теряет контекст, галлюцинирует, забывает, своевольничает и т.п.
В виме - никак. А также в ноутпаде++, блокноте и т.п. древних редакторах. Нужно новое средство разработки, которого еще нет
У ИИ очень плохо с логикой, но зато "хорошо" с галлюцинациями. Проблема как раз в текстовой основе, в том, что LLM думает не структурно, а является просто гипертрофированной системой автодополнения кода или T9. Грубо говоря, LLM - это балаболка. Решая техническую проблему человек сначала думает структурно, иногда даже зрительными образами. А потом эту структуру он транслирует в речевой поток, который строится путем "автодополнения", как и в LLM. Но у LLM нет в основе четкого структурного представления действительности, а есть только зыбкие и противоречивые правила, заимствованные из промптов. Поэтому и посредственные результаты. Сейчас все еще господствует ошибочное представление, что LLM решат все наши проблемы, и поэтому нужно просто расслабиться и ничего больше не предпринимать.
Отказ от текстового программного кода - это как раз попытка использовать реальное превосходство человека над LLM в способе мышления. И это может дать гораздо более качественный и экономически эффективный программный код (учитывая цену ошибки и необходимость в код-ревью). При этом LLM вполне может использоваться для поиска, подсказок и т.п.
Нужные мутации уже есть (их при желании можно найти в интернете, и это не блок-схемы). Но они еще неразвитые. А на развитие нужен капитал. А чтобы он появился, действительно нужен какой-то веский стимул (безопасность?). Но пока всех устраивает разработка по принципу тяп-ляп и в продакшн, я такого стимула тоже не вижу. Проблема еще и в том, что разработка инструментов (компиляторы, линтеры, IDE) редко бывает выгодной - компании или пользуются пиратскими инструментами, или дают своим разработчикам что-нибудь оупенсорсное. Видимо, лед тронется, когда когда-нибудь крупная IT компания решит сделать инструмент для себя, и каким-то неожиданным образом ее взгляд упадет на идею хранения программного кода в AST или, может быть, с помощью языка разметки AST.
Реакция здесь очень разная. Например, сейчас у Вашей статьи уже 30 плюсов, значит, есть много сторонников. Люди зачастую на любые новшества реагируют негативно (см. синдром утенка), но это не означает что они правы. Прав тот, кто окажется прав в конечном счете, а игра еще только начата.
Есть еще один важный момент: графическое программирование на основе всякого рода блок-схем (программирование роботов, Дракон, Camunda, Anchor Modeler, ETL) дискредитировало идею отказа от текстового представления программного кода. Блок-схемы имеют очень ограниченный успех в узких нишах, потому что блок-схемы неудобны для больших проектов (не умещаются в поле зрения, требуют усилий по поиску блоков и изменению расположения блоков), порождают плохой программный код и имеют ограниченные выразительные возможности (не реализуют многие необходимые возможности языков программирования). Но большинство людей просто не представляют себе других вариантов, кроме бесконечного листинга текстового программного кода (в лучшем случае разделенного на модули) или столь же неоглядной блок-схемы.
Я думаю, что визуальное представление программного кода должно быть блочным - не в смысле блоков блок-схем любого типа, а в смысле структурного программирования. Циклы и ветвления должны отображаться в виде блоков-виджетов в прокручиваемой вкладке или карточке. Последовательно обрабатываемые инструкции должны образовывать вертикальные списки, как строки в программном коде на Python. Вкладки и карточки должны организовываться в базу данных с различными инструментами поиска, а не только с поиском по древовидному списку. Модули должны организовываться в слои и иные группы, соответствующие выбранным архитектурным паттернам.
Вместо клавиатурного ввода должны в основном использоваться разнообразные средства интерфейса, в том числе с использованием автодополнения кода и ИИ. Потребуется внести изменения и в синтаксис языка. Например, точки с запятой для разделения операторов и фигурные скобки для тела функции уже не будут нужны - их заменят виджеты.
Система управления версиями должна быть встроенной (Git, прощай!). Должны быть встроенные средства для удаленной работы. Для предотвращения vendor lock-in должны быть открытые стандарты, форматы и протоколы.
А вообще многие комментарии к этой статье, направленные против отказа от текста, на самом деле полезны для отказа от текста, так как эти комментарии раскрывают реальные проблемы, для которых нужно просто найти решение.
Ну, значит, AST должно допускать заглушки, которые должны по-разному обрабатываться в разных режимах компиляции
Вспомним теперь, что на самом деле большинство ветвей эволюции были тупиковыми, а их представители вымерли, не оставив потомства. И где теперь эти трилобиты, динозавры и саблезубые тигры? Эволюция никогда не кончается. Утверждать, что текст - это венец творения, - это примерно то же самое, что утверждать, что 640 КБ хватит всем
Не нужно ничего парсить. AST должно строиться непосредственно средствами инструмента со встроенным линтером, а не парситься из текста программного кода. Тогда будет невозможно сделать что-нибудь некомпилируемое.
Сомнительные аргументы. Помимо молотка, лопаты и колеса уже давно существуют шуруповерт, экскаватор и лодка/самолет/поезд на магнитной подушке. А кроме привычного нам текста есть схемы, таблицы и графический интерфейс. Тоже, кстати, созданные людьми для людей. И наскальная живопись появилась задолго до глиняных табличек с текстом. Удивитиельно, что многие разработчики настолько консервативны, что сходу и не задумываясь отторгают всё, что не связано с текстовым редактором, к которому когда-то были приучены.
Было бы ошибкой сериализовать в текст! Если уж Вы решились порвать с текстом, то нужно это делать не только в способе хранения программного кода, но и в способе отображения программного кода человеку. Никому на самом деле не нужен единый текст программы (листинг), если логически он состоит из проектов, слоев, модулей, функций, циклов и т.п. Способ отображения программного кода должен повторять его логическую структуру. Для этого есть самые разнообразные элементы интерфейса: вкладки, карточки, блоки, древовидные списки и т.д.
То, за что Вы взялись, совершенно правильно. Но это не что-то совершенно новое. Советую изучить имеющийся опыт в этой области:
https://zouev.blogspot.com/2008/09/blog-post.html
https://habr.com/ru/companies/infopulse/articles/302146/
https://devby.io/news/programmirovanie-bez-tekstovyh-faylov
https://guilabs.net/
https://sites.google.com/site/purebuilder/
Крупные предприятия не родят ничего принципиально нового из-за своей забюрократизированности, неповоротливости и внутренних интриг. Стартапы и эксперты останутся за бортом. Деньги "освоят". Красивые отчеты нарисуют. 30% якобы расходов бизнеса профинансируют за счет 70% субсидии - по части схематозов нам нет равных
"Скупой платит дважды"
О какой такой мотивации бизнеса речь? Мы хотим "НИОКР по современным технологиям", или чтобы толстосумы рискнули своими 30% ради только им выгодных проектов? Или тот, кто предоставляет субсидию, хочет "соломки подстелить", разделив ответственность с бизнесом?
Аутсайдеры не рассматриваются. Только свои, у которых заявки уже готовы
Так всё-таки прибыль или же современные технологии и безопасность компонентной базы?
Понятно, почему современные технологии рождаются только в оборонке. Узколобый бухгалтерский подход и пресловутые распилы не позволяют им появиться в гражданских отраслях
Добавили бы линию уже пройденного пути, а то при отключениях GPS и глючной ориентации карты "по направлению движения" невозможно понять, где находишься и в какую сторону движешься. На сложной местности приходится включать еще и Gaia GPS, переключаться между ним и навигатором, и батарея разряжается очень быстро.
А еще пригодилось бы отображение линии маршрута до цели (или хотя бы метки или стрелки, указывающей нужное направление движения) на экране телефона в режиме видоискателя (как перед фотосъемкой).
И еще было бы хорошо выделять названия полей:
Образующих первичный ключ - жирным шрифтом
Содержащих UUID - синим #0043CE (для индексируемых или входящих в первичный ключ) или оранжевым #F34900 (в остальных случаях) шрифтом
Дат начала и окончания действия записи - зеленым шрифтом #56B259
Даты создания записи и номера версии записи - фиолетовым шрифтом #B45CC0