Все такие статьи структурно однобоки. Берут проблемные места других языков и показывают как их сделать хорошо. Это хорошо. Но не может быть, что в других языках нет хороших мест, которые альтернативой реализуются проблемно. А вот об этом ни слова. Либо читать другую однобокую статью, "хейт".
Возьмем классическое "беспроблемное" наследование много-от-одного. Структура на 5 полей, реализация на 15 методов. В одном наследнике переопределяется метод 7, в другом 7 и 9, в третьем 8, 9 и добавляется 16 "служебный". Какой-то из них может добавить поле в состояние. Другой может стать предком для еще одного наследника. Переопределение какого-то метода, лишь добавление всего одной операции до или после метода предка.
Как? Трейты? Еще трейты? Добавление нового класса в проект потребует переписать существующий код? А без переписывания? Я не знаю. Пока присматриваюсь, хоть уже и долго. Но нигде не встречал удобного решения вполне рядовых задач.
Вы не это предлагаете. Возможно я сам некорректно выразился. Явно вывести, это разделение на "в этом миграции", а вот "в этом запросы". Снижение связности, модульность, гибкость.
Можно резюмировать ваш подход: источник истины — схема описанная миграциями. Именно так, неразрывно. В этом его сила и... слабость. Например:
снимает необходимость с ваших джавистов, растовщиков и тд знать чего-либо про SQL
А если сам с усам? Не хочу каждый запрос отдавать в репозиторий администратора. Останется вне контроля? А если захочется? Клонировать репозиторий миграций, при наличии живой базы?
Буду думать надо разделением контроля. Получить поток данных без DBError и принять поток данных без TypeError. И всё на уровне не запроса, а запросОВ. Извлекаются нужные метаданные, устраняется дублирование, проверяются атомарные токены, при необходимости имеем аналог sourceMap для возврата от токенов к исходному коду запросов.
Ну да. Источник истины для схемы код миграций. Источник истины для запросов схема данных.
В целом все хорошо. Но код миграций надо вывести из-под приложения. Явно!!! Отдельная версионируемая сущность. Ничего не знающая про приложения. Но приложения могут знать про миграции. Мейнтейнером при этом может быть как "владелец" приложения, так и любой другой субъект. На суть это не влияет, только на организацию процесса.
В этом что-то есть. Спасибо за приведение моих размышлений в порядок.
У вас по сути гибридный подход. Миграции code-first, ведь sql это тоже код; запросы проверяются strorage-first. В случае "чужой" базы, при много приложений к одной базе, её структура вам доступна в режиме read only. Научимся удобно работать при таких ограничениях, будет удобно всегда. Но если концепция хоть частично содержит code-first, удобно не будет.
Вспомнил свой давний эксперимент времен Дельфи. В самой базе хранил repr_rus и description полей. И что-то при новом взгляде, в этом есть.
Мы сейчас говорим фактически о метаданных. Данных (DML) описания данных (schema). Которые могут "расползтись". Но база данных, в том числе инструмент обеспечения ссылочной целостности данных. В том числе ссылочной целостности с схемой, хранящейся в служебных таблицах.
Так какая часть у запросов может разойтись со схемой? И почему бы ее не хранить в "уголке" этой схемы? Источник истины не [только] база, но и данные под ее ссылочным контролем.
Вы кажется сейчас совместили приложение у пользователя и приложение у разработчика.
Что произойдет у пользователя, в случае расхождения со схемой, причем расхождения такого, которое можно поймать типобезопасностью/программно? Приложение упадет. Так или иначе. При старте или в процессе, выбор неоднозначный. Возможно текущая сессия не затронет измененный участок развесистой схемы. Тогда пусть работает?
А у разработчика... это не столько фича, сколько, кмк, смещение источника истины. Много-к-одному должно решаться иначе, концептуально, либо начнутся костыли натягивания одного на другое.
И еще, считаю один-к частным случаем много-к. Если научиться хорошо и удобно работать с "чужой" схемой, расширить дополнительными плюшками при "владении" своей намного проще.
Понятно. Однако связь проект-хранилище один-к-одному хоть и распространена, но далеко не единственная. Актуальна периодическая проверка корректности интеграции, по событию или расписанию. Либо, как уже упоминали, отдельный абстрагированный от языка слой в роли истины. Либо, все (?) базы внутри себя уже хранят этот, примененный к ним истинный DDL. Чем не источник?
Это не в критику вашего проекта, а лишь определение областей применения.
Все узкие места вроде известны. Но почему нет для них шаблонных решений, либо их недостаточно популяризуют. Нужна графовая структура? Берешь библиотеку, описываешь узлы и связи, цепляешь полезную нагрузку — пользуешься. Привык к определенным паттернам наследования, переопределить пару методов из пачки, добавить пару возможностей включая небольшое расширение внутреннего состояния? Смотришь best practice и делаешь удобно в концепциях языка. Раз сделал, два сделал, посоветовал коллеге, вот и нету слабых мест. Остались только сильные.
Я не знаю, что нужно. Вам виднее. Может сложно, а может и не так.
Предлагая в качестве образца древние движки, я обжегся на человеческом восприятии. Говорю, смотрите на просодию, а люди слыша древнюю фонетику, сразу ставят крест. Но вроде вы специалисты и такое не грозит. Существовал синтезатор — Loquendo Olga. В ее исполнении, стихи интонировались вполне приемлемо. Если не твердая четверка, так тройка с плюсом.
Идеал вещь эфемерная, поэтому радует сам процесс движения к нему. Спасибо.
Из идей... я наиболее чувствителен к интонированию. Включая пунктуационные паузы, как внутри, так и между предложениями. Там тоже немало нюансов. Поэтому предложу для внутреннего тестирования использовать стихи. На них все моменты наиболее заметны. А уж что покажется вам достойным улучшения, смотрите сами. Не стоит ожидать профессиональной артистической декламации, но уровень школьника на 4 балла (по 5-балльной системе) вполне достижим при ограниченных системных ресурсах.
Мне не хватает "наследования" местного контекстного меню. Чтобы он просматривал наличие файла по всем папкам пути. FarMenu.ini в \dev не откроется из \dev\project
Последнее поколение, если не произойдет качественный скачок.
Изначально видел ущербной задачу построения логической модели на базе языковой. Каждый раз перелопачивать терабайты текстов, строя лишь статистическую модель с некоторыми обобщениями на скрытых слоях. Языковая и логическая должны быть разделены. Логическая должна обучаться на а) персистентном и б) дистиллированном графе знаний. Никакой дублированности, которую оценивает статистика. Только логика связей, только хардкор. Будут затраты на его первоначальное составление. Скорее всего с помощью тех же LLM, но в дальнейшем только пополнение. Устраненная избыточность категорически снизит затраты на обучение, поиск обобщений.
Согласен. Но несмотря на это, статья, точнее ее подача, мне немного помогла. Позволила чётко сформулировать одну из мыслей. Промежуточные этапы не нуждаются в финальных гарантиях. Чем дальше этап от финального, тем больше они вредят.
Удивлен, что нигде этого раньше не встречал. Все только восхищаются финальными. И даже если вред упоминается, была тут серия статей про Раст в гейминге, цельная мысль так и не сформировалась.
Насколько понравились первые два-три предложения статьи, настолько отвратило остальное.
Когда-нибудь шили одежду на заказ? Первая примерка, возможно вторая. Все наживую. Висит, подвернуто, на нитках или булавках. На манекене портного, до показа вам, еще "страшнее". Все прекрасно понимают, что в этом никто не пойдет на улицу. Но уже видно продукт, его слабые места, где не хватает или топорщится, где "не идёт", которые также легко на булавках или мелком подправить.
Еще веселее выглядит конструирование более сложных продуктов. Из агрегатов, которые из узлов, а те из деталей. Промежуточные этапы выглядят как чудовищные франкенштейны.
А что же с нашим любимцем? Всё или ничего! Никого не волнует, что "портному" может быть плевать, если где-то что-то разойдется, оторвется, перекосит, упадет с ошибкой выполнения. Потому сейчас он другим занят. Не упадет, потому что то место выполняться не будет. Но будь добр запускать только в состоянии "можно выйти на улицу".
И нет, это не претензия языку. А лишь что не всё красивое, всегда полезно. Одних может привлечь, а других отвратить.
Нейросети это не только LLM которые называют ИИ, но и много других применений. Сильно "не только". И знания наработанные в одной области перетекают в другие. Могут на это надеяться инвесторы, на b2b сегмент? Вполне. А вот пузырь LLM ака ИИ, может и лопнет. А может и не скоро лопнет, а может просто сдуется, а может наконец-то создадут иную архитектуру "думающей" сети. Способную действительно раюотать со смыслами и последовательно учиться на дистиллированных данных, как это делает обычный школьник. Гадать можно долго.
А почему VladimitPutin1952# за секунды? Не сарказм, а отсутствие понимания механизмов подбора.
Если с цифробуквенными все ясно, вариативность токенов — 2 * количество букв + количество цифр + количество спецсимволов, — а дальше простая комбинаторика от количества токенов. То что с приведенным примером? Да у нас всего 5 токенов — Vladimir, t, Putin, 1952, #. Но их вариативность зашкаливает. И это мы сейчас оцениваем известную схему — имя, замена последней буквы, фамилия, год, спецсимвол, — которая по условиям задачи нам тоже неизвестна. Так какова реальная сложность данного пароля?
А в чем сложность принять решение о наполнении самим? И даже менять его между релизами. Лишь бы механизм был.
Сами признаете, что таких слов мало. Что дает намек, вы про них уже знаете. И просто не знаете, как с ними оперировать. Точнее, приняли решение ничего не делать.
Хардкодить ифами это конечно жестко. Словарный метод коррекции, с наполнением распространенными исключениями — вполне предсказуемо. Инфлюенсеры... оценивать надо статистически. 1 решивший слушать кафЕ против 9 считающими нормальным кафэ, это кмк не аргумент.
Именно что таких слов мало. Но каждое из них бьет больно. Не предлагаю "подтирать сопельки" каждому слову или каждому пользователю. Речь исключительно об основных словах с основным предпочтением фонетики.
У меня другой попутный вопрос возник: Как оценивать "крупность"? Распространенность устной речи; распространенность письменных материалов; распространенность письменных нуждающихся в озвучке — это разные значения. Текст-в-речь связывает две среды.
Все такие статьи структурно однобоки. Берут проблемные места других языков и показывают как их сделать хорошо. Это хорошо. Но не может быть, что в других языках нет хороших мест, которые альтернативой реализуются проблемно. А вот об этом ни слова. Либо читать другую однобокую статью, "хейт".
Возьмем классическое "беспроблемное" наследование много-от-одного. Структура на 5 полей, реализация на 15 методов. В одном наследнике переопределяется метод 7, в другом 7 и 9, в третьем 8, 9 и добавляется 16 "служебный". Какой-то из них может добавить поле в состояние. Другой может стать предком для еще одного наследника. Переопределение какого-то метода, лишь добавление всего одной операции до или после метода предка.
Как? Трейты? Еще трейты? Добавление нового класса в проект потребует переписать существующий код? А без переписывания? Я не знаю. Пока присматриваюсь, хоть уже и долго. Но нигде не встречал удобного решения вполне рядовых задач.
Вы не это предлагаете. Возможно я сам некорректно выразился. Явно вывести, это разделение на "в этом миграции", а вот "в этом запросы". Снижение связности, модульность, гибкость.
Можно резюмировать ваш подход: источник истины — схема описанная миграциями. Именно так, неразрывно. В этом его сила и... слабость. Например:
А если сам с усам? Не хочу каждый запрос отдавать в репозиторий администратора. Останется вне контроля? А если захочется? Клонировать репозиторий миграций, при наличии живой базы?
Буду думать надо разделением контроля. Получить поток данных без DBError и принять поток данных без TypeError. И всё на уровне не запроса, а запросОВ. Извлекаются нужные метаданные, устраняется дублирование, проверяются атомарные токены, при необходимости имеем аналог sourceMap для возврата от токенов к исходному коду запросов.
Ну да. Источник истины для схемы код миграций. Источник истины для запросов схема данных.
В целом все хорошо. Но код миграций надо вывести из-под приложения. Явно!!! Отдельная версионируемая сущность. Ничего не знающая про приложения. Но приложения могут знать про миграции. Мейнтейнером при этом может быть как "владелец" приложения, так и любой другой субъект. На суть это не влияет, только на организацию процесса.
В этом что-то есть. Спасибо за приведение моих размышлений в порядок.
У вас по сути гибридный подход. Миграции code-first, ведь sql это тоже код; запросы проверяются strorage-first. В случае "чужой" базы, при много приложений к одной базе, её структура вам доступна в режиме read only. Научимся удобно работать при таких ограничениях, будет удобно всегда. Но если концепция хоть частично содержит code-first, удобно не будет.
Вспомнил свой давний эксперимент времен Дельфи. В самой базе хранил repr_rus и description полей. И что-то при новом взгляде, в этом есть.
Мы сейчас говорим фактически о метаданных. Данных (DML) описания данных (schema). Которые могут "расползтись". Но база данных, в том числе инструмент обеспечения ссылочной целостности данных. В том числе ссылочной целостности с схемой, хранящейся в служебных таблицах.
Так какая часть у запросов может разойтись со схемой? И почему бы ее не хранить в "уголке" этой схемы? Источник истины не [только] база, но и данные под ее ссылочным контролем.
Вы кажется сейчас совместили приложение у пользователя и приложение у разработчика.
Что произойдет у пользователя, в случае расхождения со схемой, причем расхождения такого, которое можно поймать типобезопасностью/программно? Приложение упадет. Так или иначе. При старте или в процессе, выбор неоднозначный. Возможно текущая сессия не затронет измененный участок развесистой схемы. Тогда пусть работает?
А у разработчика... это не столько фича, сколько, кмк, смещение источника истины. Много-к-одному должно решаться иначе, концептуально, либо начнутся костыли натягивания одного на другое.
И еще, считаю один-к частным случаем много-к. Если научиться хорошо и удобно работать с "чужой" схемой, расширить дополнительными плюшками при "владении" своей намного проще.
Понятно. Однако связь проект-хранилище один-к-одному хоть и распространена, но далеко не единственная. Актуальна периодическая проверка корректности интеграции, по событию или расписанию. Либо, как уже упоминали, отдельный абстрагированный от языка слой в роли истины. Либо, все (?) базы внутри себя уже хранят этот, примененный к ним истинный DDL. Чем не источник?
Это не в критику вашего проекта, а лишь определение областей применения.
Уточните пожалуйста, migrations это таки code-first или я недопонял? А если поправили базу через DDL? Или вообще ее схема/миграции вне нашего доступа?
Все узкие места вроде известны. Но почему нет для них шаблонных решений, либо их недостаточно популяризуют. Нужна графовая структура? Берешь библиотеку, описываешь узлы и связи, цепляешь полезную нагрузку — пользуешься. Привык к определенным паттернам наследования, переопределить пару методов из пачки, добавить пару возможностей включая небольшое расширение внутреннего состояния? Смотришь best practice и делаешь удобно в концепциях языка. Раз сделал, два сделал, посоветовал коллеге, вот и нету слабых мест. Остались только сильные.
Я не знаю, что нужно. Вам виднее. Может сложно, а может и не так.
Предлагая в качестве образца древние движки, я обжегся на человеческом восприятии. Говорю, смотрите на просодию, а люди слыша древнюю фонетику, сразу ставят крест. Но вроде вы специалисты и такое не грозит. Существовал синтезатор — Loquendo Olga. В ее исполнении, стихи интонировались вполне приемлемо. Если не твердая четверка, так тройка с плюсом.
Образец на 4pda, для скачивания требуется регистрация.
Идеал вещь эфемерная, поэтому радует сам процесс движения к нему. Спасибо.
Из идей... я наиболее чувствителен к интонированию. Включая пунктуационные паузы, как внутри, так и между предложениями. Там тоже немало нюансов. Поэтому предложу для внутреннего тестирования использовать стихи. На них все моменты наиболее заметны. А уж что покажется вам достойным улучшения, смотрите сами. Не стоит ожидать профессиональной артистической декламации, но уровень школьника на 4 балла (по 5-балльной системе) вполне достижим при ограниченных системных ресурсах.
Мне не хватает "наследования" местного контекстного меню. Чтобы он просматривал наличие файла по всем папкам пути. FarMenu.ini в \dev не откроется из \dev\project
Последнее поколение, если не произойдет качественный скачок.
Изначально видел ущербной задачу построения логической модели на базе языковой. Каждый раз перелопачивать терабайты текстов, строя лишь статистическую модель с некоторыми обобщениями на скрытых слоях. Языковая и логическая должны быть разделены. Логическая должна обучаться на а) персистентном и б) дистиллированном графе знаний. Никакой дублированности, которую оценивает статистика. Только логика связей, только хардкор. Будут затраты на его первоначальное составление. Скорее всего с помощью тех же LLM, но в дальнейшем только пополнение. Устраненная избыточность категорически снизит затраты на обучение, поиск обобщений.
Согласен. Но несмотря на это, статья, точнее ее подача, мне немного помогла. Позволила чётко сформулировать одну из мыслей. Промежуточные этапы не нуждаются в финальных гарантиях. Чем дальше этап от финального, тем больше они вредят.
Удивлен, что нигде этого раньше не встречал. Все только восхищаются финальными. И даже если вред упоминается, была тут серия статей про Раст в гейминге, цельная мысль так и не сформировалась.
Насколько понравились первые два-три предложения статьи, настолько отвратило остальное.
Когда-нибудь шили одежду на заказ? Первая примерка, возможно вторая. Все наживую. Висит, подвернуто, на нитках или булавках. На манекене портного, до показа вам, еще "страшнее". Все прекрасно понимают, что в этом никто не пойдет на улицу. Но уже видно продукт, его слабые места, где не хватает или топорщится, где "не идёт", которые также легко на булавках или мелком подправить.
Еще веселее выглядит конструирование более сложных продуктов. Из агрегатов, которые из узлов, а те из деталей. Промежуточные этапы выглядят как чудовищные франкенштейны.
А что же с нашим любимцем? Всё или ничего! Никого не волнует, что "портному" может быть плевать, если где-то что-то разойдется, оторвется, перекосит, упадет с ошибкой выполнения. Потому сейчас он другим занят. Не упадет, потому что то место выполняться не будет. Но будь добр запускать только в состоянии "можно выйти на улицу".
И нет, это не претензия языку. А лишь что не всё красивое, всегда полезно. Одних может привлечь, а других отвратить.
Нейросети это не только LLM которые называют ИИ, но и много других применений. Сильно "не только". И знания наработанные в одной области перетекают в другие. Могут на это надеяться инвесторы, на b2b сегмент? Вполне. А вот пузырь LLM ака ИИ, может и лопнет. А может и не скоро лопнет, а может просто сдуется, а может наконец-то создадут иную архитектуру "думающей" сети. Способную действительно раюотать со смыслами и последовательно учиться на дистиллированных данных, как это делает обычный школьник. Гадать можно долго.
А почему VladimitPutin1952# за секунды? Не сарказм, а отсутствие понимания механизмов подбора.
Если с цифробуквенными все ясно, вариативность токенов — 2 * количество букв + количество цифр + количество спецсимволов, — а дальше простая комбинаторика от количества токенов. То что с приведенным примером? Да у нас всего 5 токенов — Vladimir, t, Putin, 1952, #. Но их вариативность зашкаливает. И это мы сейчас оцениваем известную схему — имя, замена последней буквы, фамилия, год, спецсимвол, — которая по условиям задачи нам тоже неизвестна. Так какова реальная сложность данного пароля?
А в чем сложность принять решение о наполнении самим? И даже менять его между релизами. Лишь бы механизм был.
Сами признаете, что таких слов мало. Что дает намек, вы про них уже знаете. И просто не знаете, как с ними оперировать. Точнее, приняли решение ничего не делать.
Хардкодить ифами это конечно жестко. Словарный метод коррекции, с наполнением распространенными исключениями — вполне предсказуемо. Инфлюенсеры... оценивать надо статистически. 1 решивший слушать кафЕ против 9 считающими нормальным кафэ, это кмк не аргумент.
Именно что таких слов мало. Но каждое из них бьет больно. Не предлагаю "подтирать сопельки" каждому слову или каждому пользователю. Речь исключительно об основных словах с основным предпочтением фонетики.
У меня другой попутный вопрос возник: Как оценивать "крупность"? Распространенность устной речи; распространенность письменных материалов; распространенность письменных нуждающихся в озвучке — это разные значения. Текст-в-речь связывает две среды.