Не до конца понял решаемую бизнес задачу, для какого проекта нужны таблицы историчности? Почему таблицы истории создаются руками через скрипт, а не через код системы или ещё как-то?
Пишу на react приложения, когда меняется state, то перерисовывается только компонент, в которым этот state поменялся и его дочерние. По идеи, каждый раз всё дерево перерисовывать не нужно. Почему в angular, большом и крутом enterprise Фреймворка чего-то подобного и уже давно реализованного не было и это только недавно добавили? Или я не правильно прочитал начало статьи?
Так... Тогда другой вопрос, а ускорение разработки чего вы хотите добиться? У нас есть разработка разных бэкенд приложений, которые представляют собой веб-серверы. Я вот к примеру работаю в области бизнес систем, там очень много бизнес логики, что объект а нужно обработать таким образом и бла-бла-бла. И вот обвязка веб сервера там не такая и большая, по сравнению с бизнес логикой. Того, что вы упростите написание веб части, почти ничего не поменяет в плане бизнес задачи. Или речь про то, что вы хотите разработать некоторый аналог nginx, который маршрутизирует некоторый контент и маршрутизирует запросы между разными серверами? Для задачи того, что на сервер А приходят запросы от 3-х разных сайтов и их нужно перенаправить на нужные сервера в режиме прокси - с этим прекрасно справляется nginx, и там просто нужно чуть-чуть написать конфига. Для этого я не буду писать каждый раз новый веб-сервер на c#.
Не очень понял. Имеется в виду web сервер, а называется просто сервер? Для меня сервер - это куча железа, на нём поднимается гипервизор и там виртуалки, на которых только поднимаются web сервера и web сервисы. Но у автора что-то с терминологией. Плюс вообще не понял, чем этот проект на rust лучше asp net core на c#, который я использую сейчас. Так что очень интересно, но не понятно.
То есть для того, что бы добавить поддержку своего вуза нужно эту поддержку запрограммировать и написать разработчику оригинального приложения? Как-то эта схема выглядит не очень. После прочтения статьи мне представлялось это проще.
Очень странный паттерн. Словосочетание "reverse proxy" обычно используют для обозначения proxy сервера, который перенаправляет запросы из интернета на поднятый на локальном порту сервис. И гуглится именно это. Паттерн proxy, о котором я слышал, и который есть в списке известных и общепринятых паттернов, он вообще о другом. Получается, вы этот паттерн выдумали, при этом название крайне неудачное.
Вы описываете проблему, что при обновлении системы приходится останавливать сервер и вносить изменения во все компоненты системы. Данный паттерн в том виде, в котором вы его описали, данную проблему не решает.
Вообще, можно уйти в сторону микросервисов, чтобы обновлять их постепенно, не останавливая работу всего приложения. Или, что есть ещё лучше вариант, мы поднимает второй сервер со следующей версией приложения и постепенно балансировщиком перекидываем пользователей на новый сервер, потом выключаем сервак со старой версией. И не надо внедрять изуверскией паттерны, которые переусложняют логику на ровном месте.
Статья ни о чём, написана ради рекламы компании и её открытых уроков.
В названии статьи ошибка, модульная память была в видеокартах давным давно, корректнее сказать "почему современные карты не имеют модульной памяти". Кроме этого в самой статье неточности и ошибки. Например, что если сделать память модульной, то ухудшиться охлаждение. Что бредятина, так как из-за близкого расположения к GPU чипу охлаждение памяти страдает из-за наличие рядом мощного источника тепла, а если память будет далеко от чипа, то охлаждение выиграет, но вот задержки возрастут. И такие косяки по всей статье, потому что автор не удосужился её вычитать и перепроверить.
Несколько лет уже я работаю как разработчик одной бизнес системы, и там порой возникают ситуации с некоторой магией, которая при детальном изучении довольно быстро разрушается, так как любое поведение программы имеет причину. С нейронками эта логика уже немного не работает, но если позиционировать их как программы, то работает. И если LLM запущена в режиме только вывод значений, без дообучение на лету, то скорее всего Бард и не менял бы своего решения, своей реакции. Следовательно я склоняюсь к мысли, что Бард работал в режиме изменения своих весов от сообщений пользователей каким-то образом, и вы под этот механизм попали, либо вся статья брехня (уж слишком фантастично она звучит, извините).
Я попробую посмотреть как сейчас работает Бард или как оно сейчас называется. Потому что при первом приближении это выглядит как бред. И на локальной LLM я такого точно не получу, как я думаю, если я всё правильно понимаю, да и вы в конце статьи об этом написали, что запертые локально системы не смогут показать такого поведения и это тупик по вашему мнению.
Ну, речь больше не о стилистике, а о манере повествования, содержание технических деталей и домыслов. Слишком как-то фантастично это звучит и я совершенно без понятия, как проверить то, что описано в статье. Может это так и было, а может это всё выдумка. Вы вроде занимаетесь ИИ , но даже предположений о том, почему бард так себя вёл и как это возможно, я не заметил в статье. Возможно, я не прав, поэтому и пишу комментарий этот.
Flyingbear s1 сборка состоит из прикручивания экрана и чуть-чуть на пару минут возни с хотендом, по сути принтер собран из коробки и печатает почти из коробки. В том смысле что его нужно капельку собрать, а дальше он автокалибруется и сразу нормально печатает. Мне лично понравился. Один раз начал глючить термистор спустя месяц что ли, переподключил его и всё стало нормально. Больше проблем с принтером у меня не было никаких.
Ага, а самоё весёлое, когда на твоём стенде всё работает, а у заказчика ничего не работает. Конфиги вроде одинаковые, всё вроде одинаково, но не работает. И вот сидишь часами в созвоне с заказчиком и просишь их дёргать разные штуки чтобы понять что именно не работает и почему. Спустя пару дней разница в конфигах находится и разница в инфраструктуре тоже.
Статья выглядит странно. С одной стороны обозревается довольно мощный инструмент, но используется он для простой задачи, которая решается и более простыми и лаконичными инструментами типо той же linq функцией where , только тут мы конструируем выражение очень сложным и неудобным способом.
Я видел в коде реального проекта, где деревья выражений использовались чтобы построить фильтрацию по любым полям. То есть на входе некий класс фильтра, где есть строка, которая переводится в поле модели и в зависимости от типа поля строиться выражение. Показали бы такой код, вопросов бы к вам не было.
К тому же сложность туториала высокая, а разбираемые примеры не такие и сложные.
Вот интересно, если рисунок и узор повторяется, нельзя ли вывести аналитическую формулу?
Не до конца понял решаемую бизнес задачу, для какого проекта нужны таблицы историчности? Почему таблицы истории создаются руками через скрипт, а не через код системы или ещё как-то?
Пишу на react приложения, когда меняется state, то перерисовывается только компонент, в которым этот state поменялся и его дочерние. По идеи, каждый раз всё дерево перерисовывать не нужно. Почему в angular, большом и крутом enterprise Фреймворка чего-то подобного и уже давно реализованного не было и это только недавно добавили? Или я не правильно прочитал начало статьи?
Так... Тогда другой вопрос, а ускорение разработки чего вы хотите добиться? У нас есть разработка разных бэкенд приложений, которые представляют собой веб-серверы. Я вот к примеру работаю в области бизнес систем, там очень много бизнес логики, что объект а нужно обработать таким образом и бла-бла-бла. И вот обвязка веб сервера там не такая и большая, по сравнению с бизнес логикой. Того, что вы упростите написание веб части, почти ничего не поменяет в плане бизнес задачи.
Или речь про то, что вы хотите разработать некоторый аналог nginx, который маршрутизирует некоторый контент и маршрутизирует запросы между разными серверами? Для задачи того, что на сервер А приходят запросы от 3-х разных сайтов и их нужно перенаправить на нужные сервера в режиме прокси - с этим прекрасно справляется nginx, и там просто нужно чуть-чуть написать конфига. Для этого я не буду писать каждый раз новый веб-сервер на c#.
Не очень понял. Имеется в виду web сервер, а называется просто сервер? Для меня сервер - это куча железа, на нём поднимается гипервизор и там виртуалки, на которых только поднимаются web сервера и web сервисы. Но у автора что-то с терминологией. Плюс вообще не понял, чем этот проект на rust лучше asp net core на c#, который я использую сейчас. Так что очень интересно, но не понятно.
То есть для того, что бы добавить поддержку своего вуза нужно эту поддержку запрограммировать и написать разработчику оригинального приложения? Как-то эта схема выглядит не очень. После прочтения статьи мне представлялось это проще.
Очень странный паттерн. Словосочетание "reverse proxy" обычно используют для обозначения proxy сервера, который перенаправляет запросы из интернета на поднятый на локальном порту сервис. И гуглится именно это. Паттерн proxy, о котором я слышал, и который есть в списке известных и общепринятых паттернов, он вообще о другом. Получается, вы этот паттерн выдумали, при этом название крайне неудачное.
Вы описываете проблему, что при обновлении системы приходится останавливать сервер и вносить изменения во все компоненты системы. Данный паттерн в том виде, в котором вы его описали, данную проблему не решает.
Вообще, можно уйти в сторону микросервисов, чтобы обновлять их постепенно, не останавливая работу всего приложения. Или, что есть ещё лучше вариант, мы поднимает второй сервер со следующей версией приложения и постепенно балансировщиком перекидываем пользователей на новый сервер, потом выключаем сервак со старой версией. И не надо внедрять изуверскией паттерны, которые переусложняют логику на ровном месте.
Статья ни о чём, написана ради рекламы компании и её открытых уроков.
В названии статьи ошибка, модульная память была в видеокартах давным давно, корректнее сказать "почему современные карты не имеют модульной памяти". Кроме этого в самой статье неточности и ошибки. Например, что если сделать память модульной, то ухудшиться охлаждение. Что бредятина, так как из-за близкого расположения к GPU чипу охлаждение памяти страдает из-за наличие рядом мощного источника тепла, а если память будет далеко от чипа, то охлаждение выиграет, но вот задержки возрастут. И такие косяки по всей статье, потому что автор не удосужился её вычитать и перепроверить.
Несколько лет уже я работаю как разработчик одной бизнес системы, и там порой возникают ситуации с некоторой магией, которая при детальном изучении довольно быстро разрушается, так как любое поведение программы имеет причину. С нейронками эта логика уже немного не работает, но если позиционировать их как программы, то работает. И если LLM запущена в режиме только вывод значений, без дообучение на лету, то скорее всего Бард и не менял бы своего решения, своей реакции. Следовательно я склоняюсь к мысли, что Бард работал в режиме изменения своих весов от сообщений пользователей каким-то образом, и вы под этот механизм попали, либо вся статья брехня (уж слишком фантастично она звучит, извините).
Я попробую посмотреть как сейчас работает Бард или как оно сейчас называется. Потому что при первом приближении это выглядит как бред. И на локальной LLM я такого точно не получу, как я думаю, если я всё правильно понимаю, да и вы в конце статьи об этом написали, что запертые локально системы не смогут показать такого поведения и это тупик по вашему мнению.
Ну, речь больше не о стилистике, а о манере повествования, содержание технических деталей и домыслов. Слишком как-то фантастично это звучит и я совершенно без понятия, как проверить то, что описано в статье. Может это так и было, а может это всё выдумка. Вы вроде занимаетесь ИИ , но даже предположений о том, почему бард так себя вёл и как это возможно, я не заметил в статье. Возможно, я не прав, поэтому и пишу комментарий этот.
Пока не дочитал до конца, но выглядит как Крипипаста, а не как статья на Хабре. Вы серьёзно ?
Flyingbear s1 сборка состоит из прикручивания экрана и чуть-чуть на пару минут возни с хотендом, по сути принтер собран из коробки и печатает почти из коробки. В том смысле что его нужно капельку собрать, а дальше он автокалибруется и сразу нормально печатает. Мне лично понравился. Один раз начал глючить термистор спустя месяц что ли, переподключил его и всё стало нормально. Больше проблем с принтером у меня не было никаких.
Ага, а самоё весёлое, когда на твоём стенде всё работает, а у заказчика ничего не работает. Конфиги вроде одинаковые, всё вроде одинаково, но не работает. И вот сидишь часами в созвоне с заказчиком и просишь их дёргать разные штуки чтобы понять что именно не работает и почему. Спустя пару дней разница в конфигах находится и разница в инфраструктуре тоже.
Статья выглядит странно. С одной стороны обозревается довольно мощный инструмент, но используется он для простой задачи, которая решается и более простыми и лаконичными инструментами типо той же linq функцией where , только тут мы конструируем выражение очень сложным и неудобным способом.
Я видел в коде реального проекта, где деревья выражений использовались чтобы построить фильтрацию по любым полям. То есть на входе некий класс фильтра, где есть строка, которая переводится в поле модели и в зависимости от типа поля строиться выражение. Показали бы такой код, вопросов бы к вам не было.
К тому же сложность туториала высокая, а разбираемые примеры не такие и сложные.