вы не поняли о чем там. даже отдаленно. я придумал протокол, избавляющий от написания фронта. а унылость идет от MD, туда (в гугл) жаловаться и надо. а я поддержу.
Я пойду дальше автора и заявлю что вообще фронт-енд программинг - унылая шляпа (вот это все JS, HTML, CSS, зоопарк мутных фреймворков) и должно умереть во имя добра. Стараясь ускорить этот процесс придумал как вообще не прикаcаясь ко всему этому получать готовые фронты для всех девайсов/отображателей, программируя только на том языке, который нравится (вообщем любом). для data science/business апликух, где стандартного MD достаточно.
Написал на flutter (тоже гадость, но меньшего порядка) авто-фронт, юзаю для себя и своих заказчиков, и в общем доволен. Уверен, что подобная моей технология прибьет нафиг всю эту камарилью рано или поздно. А пока до этого не додумались монстры, я тихо сижу и радуюсь, что я вне этого безумия. ну почти так.
Там косяк с этими provide/inject : inject можно вызвать только из setup. Если писать без setup (смысла не несет для меня), то низзя. Кроме того залочили прередачу глобов через Vue.propotype. Фиг с ними, сделал обмен мимо их неудобных тулз. Не люблю тупые ограничения.
По мойму этот OpenAPI унылая шляпа, столько некрасивого мусора со всех сторон. Я вообще "не пишу код для взаимодействия с для взаимодействия с бэкендом" равно как и сам фронт-енд, а получаю его сразу из моих данных с помощью авто-фронтэндера. https://github.com/Claus1/unigui если что.
Даже сейчас можно не кодить фронт и верстку для бизнес программ, получая интерфейс просто из данных. А уж позже и подавно. Пример https://github.com/Claus1/unigui
Подскажите, уже кто-то додумался до идеи-реализации автоматической балансировки набора взаимодействующий приложений. Например, я разработал кучу сервисов и хочу чтобы они автоматом масштабировались в облаке и я не хочу учить-знать на чем это будет делаться Mezos, OpenStack, kube… Все сервисы доступаются локально до любого нужного через localhost, поэтому могут быть развернуты, отмасштабированы, продублированы как угодно. Зачем мне знать то, что я не хочу. Зачем делать работу, которая может быть сделана автоматом?
«Мы хотим, чтобы модель доставала знания не из своих весов, а из этой внешней базы знаний.» Напомнило «хотим чтоб пироги в рот лезли сами». Увы, летать на деревянной лошадке в нашей реальности не получается.
Спасибо, и впрямь интересно, допер уже кто до нормального парсинга на каком-то семантико-синтаксическом словаре для инглиша. Так то только по частям речи парсинг может норм работать будет только для простейших предложений. Последнее обнаружено мной при создании семантического анализатора для русиша.
Было бы норм сравнить эту схему со схемой без всяких ухищрений с resnet transfer learning, стоит ли овчинка выделки. а так непонятно, радоваться за вас, или наоборот.
Для этого и нужны 2-4 фото. чтобы сделать пересечение по компонентам. Вероятно из вектора можно выделить измерения, которые описывают нужный семантический фактор. остальные в игнор. Если CLIP простанство линейно и ортогонально по компонентам. Надеюсь что так.
Спасибо за статью! 1. Мне кажется, что генерация модели Текст-вектор можно избежать) Есть же универсальная, по ней получаем N векторов для классификации и получив вектор картинки ищем ближайшие классификатора, причем расстояние до них — мера вероятности. 2. Много интересней лично мне поиск картинка — ближайшие картинки по 2-4 примерам. Слова искажают смысл больше чем изображения, а выявить общность по минимуму изображений в векторах аналитически — интересно. Предварительно CLIP вполне годится для этого. Согласны?
Я ортодокс: смотрю что можно сделать изнутри проги. Оттуда генерить код нормальным способом как могу в динамических языках и в Nim, Crystal, Scala — не могу. Просить юзера изучать/использовать тулчейны чтобы он смог использовать мою либу не считаю разумным. но спасибо за наводку.
зачем им этот мусор? дай бог научится с правильным текстом работать норм, а потом уже, бесясь с жиру, можно хоть на пингвиний.
например,хоть один, чтобы сразу давал многопользовательский универсальный GUI и работал для всех языков, по крайней мере в теории?
вы не поняли о чем там. даже отдаленно. я придумал протокол, избавляющий от написания фронта. а унылость идет от MD, туда (в гугл) жаловаться и надо. а я поддержу.
Я пойду дальше автора и заявлю что вообще фронт-енд программинг - унылая шляпа (вот это все JS, HTML, CSS, зоопарк мутных фреймворков) и должно умереть во имя добра. Стараясь ускорить этот процесс придумал как вообще не прикаcаясь ко всему этому получать готовые фронты для всех девайсов/отображателей, программируя только на том языке, который нравится (вообщем любом). для data science/business апликух, где стандартного MD достаточно.
Написал на flutter (тоже гадость, но меньшего порядка) авто-фронт, юзаю для себя и своих заказчиков, и в общем доволен. Уверен, что подобная моей технология прибьет нафиг всю эту камарилью рано или поздно. А пока до этого не додумались монстры, я тихо сижу и радуюсь, что я вне этого безумия. ну почти так.
что придумал https://github.com/Claus1/unigui
Там косяк с этими provide/inject : inject можно вызвать только из setup. Если писать без setup (смысла не несет для меня), то низзя. Кроме того залочили прередачу глобов через Vue.propotype. Фиг с ними, сделал обмен мимо их неудобных тулз. Не люблю тупые ограничения.
По мойму этот OpenAPI унылая шляпа, столько некрасивого мусора со всех сторон. Я вообще "не пишу код для взаимодействия с для взаимодействия с бэкендом" равно как и сам фронт-енд, а получаю его сразу из моих данных с помощью авто-фронтэндера. https://github.com/Claus1/unigui если что.
Даже сейчас можно не кодить фронт и верстку для бизнес программ, получая интерфейс просто из данных. А уж позже и подавно. Пример https://github.com/Claus1/unigui