Нет и не будет никакого AGI. Дело не вычислительных мощностях. Дело в непонимании что такое человек и его сознание и искуственным путем это создать нельзя ни сейчас, ни в обозримом будущем. Муравей не может создать человека. А человеческая цивилизация в основной своей массе пока не очень далеко ушла от муравьев по интеллекту.
Я не математик, но как программист, неплохо владеющий SQL стал бы решать эту задачу средствами SQL. И если эта задача действительно насущно необходима, то внес бы изменения в архитектуру этой системы с целью эффективной отработки SQL запросов по этой задаче на этапе логина и выхода из него. В общем все просто , если не ставить целью разработку сложных алгоритмов , когда можно эту задачу решить проще и быстрее. Это тоже разработка алгоритма, но в отличие от ЯП алгоритм в SQL это другой тип мышления, это работа со множествами, их пересечениями и отношениями. Просто глядя на диаграмму, мне почемуто вспомнился способ умножения чисел с помощью вертикальных линий, и здесь то же самое, если провести вертикальную черту то количество пересечений с отрезком или просто суммирование на интервале это и есть количество одновременных логинов. От этого можно и отталкиваться.
Да, именно так. Если логи закинуть в БД то без всяких математических алгоритмов можно эту задачу решить элементарными SQL запросами c оконными функциями. При наличии индексов по датам все будет летать.
Многие вещи можно делать намного проще через таблицы и хранимые процедуры. Но это типа антипаттерн сегодня, и логику размазывают по клиенту со всеми левыми билиотеками и фреймворками и прочими прелестями в дальнейшем. Впрочем в серверной логике нужен стиль и принцип тоже, иначе будет больно.
Когда deepseek ответил мне неправильно по поводу использования одного оператора в sqlite, на мои повторные указания что это не работает он зациклился. Я очень быстро нашел ответ почему не работает оператор в stack overflow, кстати. Но есть и удачные ответы, вполне рабочие.
Нейронки не научат вас что-то делать руками и головой. Играть на музыкальном инструменте, варить металл, строгать доски, рисовать картины, писать стихи, водить автомобиль, самолет, поезд и т д и т п. Там, где требуются навыки и знания, ИИ не поможет. Знать как делать и и уметь так делать - разные вещи, разные функции обучения мозга. Так что в этом плане все остается по прежнему.
Есть такое с СУБД. В Delphi в примере подключения АТTACH DATABASE в SQLite с использованием Firedac deepseek предлагает использовать exec все место правильного execsql. Исправляет только после указания на ошибку. С insert и on conflict без where то же самое, зацикливается и не указывает на ошибку в SQLite , где обязательно должен быть в запросе where. Нужно добавлять where true. Глаз да глаз нужен за этим deepseek. Хотя в stackoverflow эта проблема описана давно.
Выше писал про вариант времянки из теплицы. Есть еще вариант бани из нее же. Лучше небольшую теплицу использовать . У меня 2x4. Двойной поликарбонат. Два отсека. Пол из лиственницы в отсеке парилки. Специальная печка - парогенератор Скоропарка. Это вверху обычной печки бак с кипящей водой и герметичной крышкой. Внутри труба по которой пар из бака проходит через зону нагрева и становится перегретым, выходит наружу и нагревает помещение до параметров русской бани 60/40. Летом за полчаса, зимой минут 40-50. Материал теплицы поликарбонат снаружи и внутри. Внутри надо его плотно подгонять, чтобы минимизировать щели, иначе зимой пар пойдет со всех щелей. При нагреве поликарбонат не выделяет никакой химии, так как это просто углерод. Да и нагрев внутри невысокий, максимум до 70С. Стенки из минерита вокруг печки с двух строн защищают поликарбонат от печки . Но нужна вентиляция как приточная так и отточная с трубой снаружи. В инструкции к печи все описано. Труба из печи выходит горизонтально и поднимается на 5 метров. Это для тяги по инструкции. Мачту для трубы сварил сам из профиля 4x20 и вкопал на метр. Вполне надежно получилось. Пользуюсь уже 4-й год. Летом и зимой. В минус 20 можно париться. Зимой вентиляцию можно уменьшать и после использования открывать для просушки, пока баня горячая. Каменка есть небольшая, заполнил пространство между печкой и ее тепловым кожухом, использовал жадеит. Печка на бетонном блоке c керамогранитом стоит. ПОЛОК из лиственницы верхними досками из липы тоже сделал сам, так как габариты были ограничены. Пол раз в год обрабатываем специальным маслом для пола. Никакого вреда для здоровья от поликарбоната нет, проверено на себе.
не совсем конечно дешево и бюджетно, но получилось практично. Основной дом пока достраиваю. Но жить круглогодично не планирую в нем, летом и в межсесонье, а зимой есть куда спокойно приехать и отдохнуть. Если внезапно отключают электричество, то есть генератор инверторный на 3 кВТ. Точно не даст замерзнуть.
Может кому-то пригодится. Помещение нагревается за 30 мин. до +20C зимой при -20С. Я сделал его из обычной теплицы, разделенной на два отсека перегородкой и дверью. Но нужен двойной слой поликарбоната, внутри и снаружи, иначе будет конденсат на стенах. Сверху кладется еще утеплитель с фольгой и закрывается еще одним слоем поликарбоната. Пол деревянный из шпунтовки. Вентиляция - два приточных клапана на торцевой стене большого отсека и труба с регулируемым клапаном через малый отсек на улицу. Пол под теплицей вентилируется тоже, на зиму вентиляцию под полом закрываю. Отопители электрические. Конвектор 2 квт с терморегулятором и два напольных инфракрасника с терморегуляторами по 700 ватт для прогрева пола, утепленного войлоком и ковролином сверху. Конечно, здесь нет санузла и прочих плюшек, но в такой схеме не надо постоянно отапливать это помещение зимой. В солнечную погоду температура в помещении +25 при внешней температуре +7 без отопления. До - 5 и при солнечной погоде в помещении всегда плюс 5-10С. Не страшен и переход через точку росы, конденсата не образуется при включении отопления в этой теплице. Так как участок недалеко от дома , в 20 минутах езды, то при приезде включаешь отопление зимой и через 30 минут комфорная температура +20 внутри. А пока все прогревается просто чистишь дорожки и территорию у ворот от снега, можно лопатой, можно снегоуборщиком. Можно даже ночевать зимой, до -10 вполне комфортно, если для прогрева холодой постели прогреть ее электропростынью за час до сна. Минусы - отсутствие звукоизоляции, помещение нет смысла закрывать на замок от воров ( не держать ничего ценного), летом днем температура в нем в солнечную погоду может быть до +35С. Впрочем и бытовки не спасают от воров, только они разворотят все, двери, окна и все равно доберутся до желаемого. У меня уже два года это помещение эксплуатируется и в общем все нормально.Нет никакой плесени или чего-то еще нехорошего. На ввод электричества поставил переключатель, дифавтомат и обычные автоматы внутри теплицы на каждый отопитель. Если надо куда уехать на несколько часов и вернуться, оставляю включенными инфракрасники, они пожаробезопасные. Теплица пережила ураган и осталась на месте, когда рядом упали сосны и березы, к счастью ее не задели.
Система разработанная мною в в 2001 г. на SQL SERVER и DELPHI для одного дилера и содержащая CRM для менеджеров ,ЗАКАЗЫ,Снабжение,Отгрузки, Склад , хранилище документов в SQL Server и имеющая по тому времени много таких иновационных вещей как вычисляемые складские остатки , изменение приоритеов заказов с учетом скадских запасов и оплат и учетом частичных отгрузок , автоформирование спецификаций для комплектации заказов для снабжения , формирование счетов предложений и счетов на оплату, счетов фактур и накладных, импорт документов 1С бухгалтерию и т п. Система прожила 10 лет без особых проблем в связи с тем что логика все была в хранимых процедурах на сервере и клиент на DELPHI . Но к тому времени и контора стала хиреть и разваливаться, вернее стали разваливать, так как функцию дойной коровы она выполнила. Недавно посмотрел свой SQL код . В общем все неплохо выглядит, а прошло больше 20 лет.
Насчет XML - некоторые особо одаренные программеры использовали XML не только для конфигов, но и в качестве локальной базы данных(!), редактируемой пользователем. Иногда файлик мог содержать больше сотни страниц в notepad и структура его была не очень простая. И все это надо было периодически редактировать, копировать и править куски, добавлять уровни вложенности и т д и т п. Уровень вложенности не ограничен был ничем. Это была адова работа, перенести все эти файлы в базу данных автоматизированным способом, потому что одаренный программер ушел из компании, оставив такое наследство, которое потребовалось развивать. Вернее переписать с нуля.
На Lora нужна базовая станция, а это недешевое удовольствие. Это не СИ, поэтому использовать его в промышленных условиях нельзя. Нужна сертификация, возможно искозащита для взрывоопасных сред и тд и тп. В общем бытовая вещь или сигнализатор для умных домов. Не более. К тому же нет выносных модулей для измерения температуры среды- термопары, платина .А воздух измерять мало кому надо.
Если CRM не на WEB то все гораздо проще. Иногда WEB это либо дань моде или даже человеческий фактор, программисты не умеють писать не на WEB. Отсюда ненужные трехзвенки, PHP и пр. пр. пр.
Смотря для каких целей используются такие платформы. Все помешаны на web. А для задач работы со сложным измерительным оборудованием и интеллектуальными датчиками та же LabVIEW незаменима, е если еще в связке с сервером SQL то вообще стабильнее системы трудно представить. Задачи можно решать любые. Это конечно не сайты, а МЕS cистемы, тестирование и мониторинг оборудования и т п. Одна из моих систем работает через собственный dsl , другая тестирует платы и работает с изделиями по modbus, взаимодействует через общую БД с другой стстемой. Да, тут проблема в кадрах, и высококвалифицированных. Но на моих глазах программист под микроконтроллеры освоил за полгода ту же LabVIEW и написал крутую программу по работе по протоколу Hart c оборудованием и хранением конфигураций в XML. Поначалу его немного корежило, так как была привычка писать код, но привык. Так и нужно делать, переучивать сложившихся программеров под лоу код. Вторая специальность. Уже может и то и это. Да, это нишевые области, но они тоже нужны, не только один сплошной web.
У меня была задача перенести около 50 файлов XML в базу данных SQL. Наследство старой программы, которая использовала XML в качестве базы данных и элементов интерфейса. и редактировалась эта XML пользователем. Некоторые файлы были больше сотни страниц. Нужно было сохранить связи в дереве объектов тоже. От 2 до 4 уровня вложенности. Все пришлось делать не регулярками, а переносить в таблицу sql сервера и далее уже обрабатывать запросами, выдергивая нужную информацию и заполняя полдесятка таблиц.
Предпочитаю db- first и серверную логику, a модель доступа к данным в отдельной таблице, без хранения на клиенте. Конечно задачи у всех разные, на моих задачах такая модель полностью оправдала себя за несколько лет эксплуатации.
Нет и не будет никакого AGI. Дело не вычислительных мощностях. Дело в непонимании что такое человек и его сознание и искуственным путем это создать нельзя ни сейчас, ни в обозримом будущем. Муравей не может создать человека. А человеческая цивилизация в основной своей массе пока не очень далеко ушла от муравьев по интеллекту.
Я не математик, но как программист, неплохо владеющий SQL стал бы решать эту задачу средствами SQL. И если эта задача действительно насущно необходима, то внес бы изменения в архитектуру этой системы с целью эффективной отработки SQL запросов по этой задаче на этапе логина и выхода из него. В общем все просто , если не ставить целью разработку сложных алгоритмов , когда можно эту задачу решить проще и быстрее. Это тоже разработка алгоритма, но в отличие от ЯП алгоритм в SQL это другой тип мышления, это работа со множествами, их пересечениями и отношениями. Просто глядя на диаграмму, мне почемуто вспомнился способ умножения чисел с помощью вертикальных линий, и здесь то же самое, если провести вертикальную черту то количество пересечений с отрезком или просто суммирование на интервале это и есть количество одновременных логинов. От этого можно и отталкиваться.
Да, именно так. Если логи закинуть в БД то без всяких математических алгоритмов можно эту задачу решить элементарными SQL запросами c оконными функциями. При наличии индексов по датам все будет летать.
Многие вещи можно делать намного проще через таблицы и хранимые процедуры. Но это типа антипаттерн сегодня, и логику размазывают по клиенту со всеми левыми билиотеками и фреймворками и прочими прелестями в дальнейшем. Впрочем в серверной логике нужен стиль и принцип тоже, иначе будет больно.
В sql server также как в статье ситуация. Сегодня подобной оптимизацией занимался.
Когда deepseek ответил мне неправильно по поводу использования одного оператора в sqlite, на мои повторные указания что это не работает он зациклился. Я очень быстро нашел ответ почему не работает оператор в stack overflow, кстати. Но есть и удачные ответы, вполне рабочие.
Нейронки не научат вас что-то делать руками и головой. Играть на музыкальном инструменте, варить металл, строгать доски, рисовать картины, писать стихи, водить автомобиль, самолет, поезд и т д и т п. Там, где требуются навыки и знания, ИИ не поможет. Знать как делать и и уметь так делать - разные вещи, разные функции обучения мозга. Так что в этом плане все остается по прежнему.
Есть такое с СУБД. В Delphi в примере подключения АТTACH DATABASE в SQLite с использованием Firedac deepseek предлагает использовать exec все место правильного execsql. Исправляет только после указания на ошибку. С insert и on conflict без where то же самое, зацикливается и не указывает на ошибку в SQLite , где обязательно должен быть в запросе where. Нужно добавлять where true. Глаз да глаз нужен за этим deepseek. Хотя в stackoverflow эта проблема описана давно.
Вопрос: исправлена ли работа INSERT c ON CONFLICT и отсутствием WHERE? Надо было добавлять WHERE TRUE
Выше писал про вариант времянки из теплицы. Есть еще вариант бани из нее же. Лучше небольшую теплицу использовать . У меня 2x4. Двойной поликарбонат. Два отсека. Пол из лиственницы в отсеке парилки. Специальная печка - парогенератор Скоропарка. Это вверху обычной печки бак с кипящей водой и герметичной крышкой. Внутри труба по которой пар из бака проходит через зону нагрева и становится перегретым, выходит наружу и нагревает помещение до параметров русской бани 60/40. Летом за полчаса, зимой минут 40-50. Материал теплицы поликарбонат снаружи и внутри. Внутри надо его плотно подгонять, чтобы минимизировать щели, иначе зимой пар пойдет со всех щелей. При нагреве поликарбонат не выделяет никакой химии, так как это просто углерод. Да и нагрев внутри невысокий, максимум до 70С. Стенки из минерита вокруг печки с двух строн защищают поликарбонат от печки . Но нужна вентиляция как приточная так и отточная с трубой снаружи. В инструкции к печи все описано. Труба из печи выходит горизонтально и поднимается на 5 метров. Это для тяги по инструкции. Мачту для трубы сварил сам из профиля 4x20 и вкопал на метр. Вполне надежно получилось. Пользуюсь уже 4-й год. Летом и зимой. В минус 20 можно париться. Зимой вентиляцию можно уменьшать и после использования открывать для просушки, пока баня горячая. Каменка есть небольшая, заполнил пространство между печкой и ее тепловым кожухом, использовал жадеит. Печка на бетонном блоке c керамогранитом стоит. ПОЛОК из лиственницы верхними досками из липы тоже сделал сам, так как габариты были ограничены. Пол раз в год обрабатываем специальным маслом для пола. Никакого вреда для здоровья от поликарбоната нет, проверено на себе.
не совсем конечно дешево и бюджетно, но получилось практично. Основной дом пока достраиваю. Но жить круглогодично не планирую в нем, летом и в межсесонье, а зимой есть куда спокойно приехать и отдохнуть. Если внезапно отключают электричество, то есть генератор инверторный на 3 кВТ. Точно не даст замерзнуть.
Может кому-то пригодится. Помещение нагревается за 30 мин. до +20C зимой при -20С. Я сделал его из обычной теплицы, разделенной на два отсека перегородкой и дверью. Но нужен двойной слой поликарбоната, внутри и снаружи, иначе будет конденсат на стенах. Сверху кладется еще утеплитель с фольгой и закрывается еще одним слоем поликарбоната. Пол деревянный из шпунтовки. Вентиляция - два приточных клапана на торцевой стене большого отсека и труба с регулируемым клапаном через малый отсек на улицу. Пол под теплицей вентилируется тоже, на зиму вентиляцию под полом закрываю. Отопители электрические. Конвектор 2 квт с терморегулятором и два напольных инфракрасника с терморегуляторами по 700 ватт для прогрева пола, утепленного войлоком и ковролином сверху. Конечно, здесь нет санузла и прочих плюшек, но в такой схеме не надо постоянно отапливать это помещение зимой. В солнечную погоду температура в помещении +25 при внешней температуре +7 без отопления. До - 5 и при солнечной погоде в помещении всегда плюс 5-10С. Не страшен и переход через точку росы, конденсата не образуется при включении отопления в этой теплице. Так как участок недалеко от дома , в 20 минутах езды, то при приезде включаешь отопление зимой и через 30 минут комфорная температура +20 внутри. А пока все прогревается просто чистишь дорожки и территорию у ворот от снега, можно лопатой, можно снегоуборщиком. Можно даже ночевать зимой, до -10 вполне комфортно, если для прогрева холодой постели прогреть ее электропростынью за час до сна. Минусы - отсутствие звукоизоляции, помещение нет смысла закрывать на замок от воров ( не держать ничего ценного), летом днем температура в нем в солнечную погоду может быть до +35С. Впрочем и бытовки не спасают от воров, только они разворотят все, двери, окна и все равно доберутся до желаемого. У меня уже два года это помещение эксплуатируется и в общем все нормально.Нет никакой плесени или чего-то еще нехорошего. На ввод электричества поставил переключатель, дифавтомат и обычные автоматы внутри теплицы на каждый отопитель. Если надо куда уехать на несколько часов и вернуться, оставляю включенными инфракрасники, они пожаробезопасные. Теплица пережила ураган и осталась на месте, когда рядом упали сосны и березы, к счастью ее не задели.
Система разработанная мною в в 2001 г. на SQL SERVER и DELPHI для одного дилера и содержащая CRM для менеджеров ,ЗАКАЗЫ,Снабжение,Отгрузки, Склад , хранилище документов в SQL Server и имеющая по тому времени много таких иновационных вещей как вычисляемые складские остатки , изменение приоритеов заказов с учетом скадских запасов и оплат и учетом частичных отгрузок , автоформирование спецификаций для комплектации заказов для снабжения , формирование счетов предложений и счетов на оплату, счетов фактур и накладных, импорт документов 1С бухгалтерию и т п. Система прожила 10 лет без особых проблем в связи с тем что логика все была в хранимых процедурах на сервере и клиент на DELPHI . Но к тому времени и контора стала хиреть и разваливаться, вернее стали разваливать, так как функцию дойной коровы она выполнила. Недавно посмотрел свой SQL код . В общем все неплохо выглядит, а прошло больше 20 лет.
Насчет XML - некоторые особо одаренные программеры использовали XML не только для конфигов, но и в качестве локальной базы данных(!), редактируемой пользователем. Иногда файлик мог содержать больше сотни страниц в notepad и структура его была не очень простая. И все это надо было периодически редактировать, копировать и править куски, добавлять уровни вложенности и т д и т п. Уровень вложенности не ограничен был ничем. Это была адова работа, перенести все эти файлы в базу данных автоматизированным способом, потому что одаренный программер ушел из компании, оставив такое наследство, которое потребовалось развивать. Вернее переписать с нуля.
Правильно писал один товарищ, что стейтмашины это зло. Видимо теперь и вы понимаете это.
На Lora нужна базовая станция, а это недешевое удовольствие. Это не СИ, поэтому использовать его в промышленных условиях нельзя. Нужна сертификация, возможно искозащита для взрывоопасных сред и тд и тп. В общем бытовая вещь или сигнализатор для умных домов. Не более. К тому же нет выносных модулей для измерения температуры среды- термопары, платина .А воздух измерять мало кому надо.
Если CRM не на WEB то все гораздо проще. Иногда WEB это либо дань моде или даже человеческий фактор, программисты не умеють писать не на WEB. Отсюда ненужные трехзвенки, PHP и пр. пр. пр.
Смотря для каких целей используются такие платформы. Все помешаны на web. А для задач работы со сложным измерительным оборудованием и интеллектуальными датчиками та же LabVIEW незаменима, е если еще в связке с сервером SQL то вообще стабильнее системы трудно представить. Задачи можно решать любые. Это конечно не сайты, а МЕS cистемы, тестирование и мониторинг оборудования и т п. Одна из моих систем работает через собственный dsl , другая тестирует платы и работает с изделиями по modbus, взаимодействует через общую БД с другой стстемой. Да, тут проблема в кадрах, и высококвалифицированных. Но на моих глазах программист под микроконтроллеры освоил за полгода ту же LabVIEW и написал крутую программу по работе по протоколу Hart c оборудованием и хранением конфигураций в XML. Поначалу его немного корежило, так как была привычка писать код, но привык. Так и нужно делать, переучивать сложившихся программеров под лоу код. Вторая специальность. Уже может и то и это. Да, это нишевые области, но они тоже нужны, не только один сплошной web.
У меня была задача перенести около 50 файлов XML в базу данных SQL. Наследство старой программы, которая использовала XML в качестве базы данных и элементов интерфейса. и редактировалась эта XML пользователем. Некоторые файлы были больше сотни страниц. Нужно было сохранить связи в дереве объектов тоже. От 2 до 4 уровня вложенности. Все пришлось делать не регулярками, а переносить в таблицу sql сервера и далее уже обрабатывать запросами, выдергивая нужную информацию и заполняя полдесятка таблиц.
Предпочитаю db- first и серверную логику, a модель доступа к данным в отдельной таблице, без хранения на клиенте. Конечно задачи у всех разные, на моих задачах такая модель полностью оправдала себя за несколько лет эксплуатации.