Поддерживаю! Я хоть и программист, но на днях навайбкодил плагины для Obsidian - потратил на это пару часов и теперь довольный пользуюсь. И хотелось поделиться, но это не статья уровня Хабра (по крайней мере не того Хабра который я бы хотел видеть), но вот прям под отдельным хабом я бы написал - так как эти плагины мне помогают в изучении языка.
Вот да - я знал что у Netflix это уже есть и здесь не удивился. Но если комменты почитать - то прям люди первый раз про это услышали и думают что это только в Иви.
Проблема не в том что это автор не сам написал - на хабре полно отличных переводов. Проблема в том что это сгенерированный текст который часто содержит ошибки которые не могут быть исправны - если у текста есть автор, то ему можно указать на ошибки и он даже если не исправит, то по крайней мере будет это знать и в следующий раз их не допустит. А с нейрослопом это бесполезно - llm не учтёт наши комментарии.
Ну это от вашего кейса зависит - если вам просто данные сохранить, не смотря в их структуру. То конечно не нужно к ним привязываться - просто как byte array сохраняете и всё. Но если нужно как то следить чтобы они не повторялись при обновлении, то надо смотреть как они там устроены. И если их структура поменяется, то да, у вас тоже нужно поменять схему и т.п.
За 20 лет в индустрии скажу что это зависит от предметной области. Но практически везде где я работал - хранились исторические данные
На текущем месте работы почти каждый месяц приходят запросы вида - а почему тут такое значение? кто поменял? а раньше же по другому было?
Вот последний раз это было несколько недель назад - раньше работало, а потом перестало и начали смотреть почему - а там в таблице запись поменяли, в которой конфигурация хранилась. И так как у нас есть историческая таблица - увидели кто и когда это сделал.
Ну т.е. всё равно приходим к тому что нужно хранить created, updated? И они не нужны примерно в 99%, но вот когда нужны - вот тут прям без них ни как. Это как логи - зачем в них смотреть когда всё работает? Но если что-то не так - они как раз кстати.
Есть llm, есть спорные моменты, но у нас же не научное сообщество, а инженерное и тут как известно нет серебряной пули - для какого-то приложения всё это будет работать, а для другого - нет. Так что хорошо что обсуждаем. И автор в комментах дискуссию ведёт, а не просто запостил. :-)
С rur rub пример не валиден - это же валюта другая стала.
Вообще я бы общее правило сделал - если ваше приложение данными не владеет, а просто сохраняет как есть, то тут суррогатнай ключ не нужен. (С другой стороны не всегда ясно какой тут натуральный ключ использовать, но в моей практике обычно понятно было) И курсы валют как раз хороший пример - всё что вам дали и вы записали как есть.
Но если ваше приложение создаёт данные - то оно и ключ может записать.
Вот когда вы точно уверены что это это внешне значение можно использовать как первичный ключ? Сегодня мы думаем что у нас у пользователя email - уникальный, а завтра он поменяется, или вообще будет две копии пользователя с одним email но второй будет помечен как deleted.
И когда ключи стандартизированны - типа всегда число. То можно в коде писать generic квери для обработки кучи разных таблиц одинаково.
На счёт перфоманса не понял - если там нет индексов, то в чём проблема?
Вообще ни разу не спорное. И я бы ещё добавил что лучше хранить историю изменений таблицы, для доступа к последней версии записи ввести что-то вроде is_last.
Потому что когда на проде что-то пройдёт не так и к тебе придут с вопросом, а почему тут такие значения, то гораздо удобнее ответ получить из селекта. Где будет по шагам расписано что именно кто и когда менял, чем ходить по логам и искать что там вообще было.
Логи в любом случае нужны, но из базы это всё удобнее получить и более наглядно.
И так как мы в будущее плохо смотрим, то я выбрал простую стратегию - всегда пишем, а если как то это будет негативно влиять (ни разу с этим не сталкивался, но всё же) то явно конкретно в этом месте не используем.
Но вообще всё зависит от бизнеса. В банках важно, кто когда что-то поменял (с них потом спросят), поэтому тут лучше всё писать. Где нибудь в pet project - наверное нет.
Согласен. Вот это сейчас происходит на рынке 3d принтеров:
Этому рынку уже несколько десятков лет. Из которых лет 10 уже можно было самому купить принтер за вполне демократичную цену. Но всё это было сложно и требовало прям знаний и погружения в тему. И не смотря на это было куча производителей. Но несколько лет назад пришли бывшие сотрудники DJI и по сути стали стандартом со своими BambuLab принтерами. Т.е. несмотря даже уже на развитый рынок с конкурентами - хороший продукт легко занимает большую долю. И реплики хуже, не получается скопировать.
Поддерживаю! Я хоть и программист, но на днях навайбкодил плагины для Obsidian - потратил на это пару часов и теперь довольный пользуюсь. И хотелось поделиться, но это не статья уровня Хабра (по крайней мере не того Хабра который я бы хотел видеть), но вот прям под отдельным хабом я бы написал - так как эти плагины мне помогают в изучении языка.
Мне кажется вот эта бы статья была бы интереснее, чем очередное описание вайб кодинга. :-)
Вот да - я знал что у Netflix это уже есть и здесь не удивился. Но если комменты почитать - то прям люди первый раз про это услышали и думают что это только в Иви.
Вот оно будущее разработки - одна llm беседует с другой llm через людей! :-)
Да! Писал как-то такой код в тестах :-)
У chat gpt похоже есть этот промт - он сказал chat gpt версии 5.3
Почитал ваши статьи, теперь понятно почему вы топите за нейрослоп - вы сами его используете. :-)
Проблема не в том что это автор не сам написал - на хабре полно отличных переводов. Проблема в том что это сгенерированный текст который часто содержит ошибки которые не могут быть исправны - если у текста есть автор, то ему можно указать на ошибки и он даже если не исправит, то по крайней мере будет это знать и в следующий раз их не допустит. А с нейрослопом это бесполезно - llm не учтёт наши комментарии.
Отличная статья! Люблю когда в кишках VM копаются :-)
А как вы вытащили асм код? Какой тулзой?
Хм, может и так - я тогда просто через reflection менял ( типа как здесь https://stackoverflow.com/questions/3301635/change-private-static-final-field-using-java-reflection )
А вроде final давно уже нельзя менять. У нас в 21 уже не работало, по крайней мере.
Ну это от вашего кейса зависит - если вам просто данные сохранить, не смотря в их структуру. То конечно не нужно к ним привязываться - просто как byte array сохраняете и всё. Но если нужно как то следить чтобы они не повторялись при обновлении, то надо смотреть как они там устроены. И если их структура поменяется, то да, у вас тоже нужно поменять схему и т.п.
Ха ха, да, есть такое. :-)
Но вот железо обычно тонет, но не в ртути. Вот может эти железные правила обычно работают, но в некоторых условиях - нет :-D
За 20 лет в индустрии скажу что это зависит от предметной области. Но практически везде где я работал - хранились исторические данные
На текущем месте работы почти каждый месяц приходят запросы вида - а почему тут такое значение? кто поменял? а раньше же по другому было?
Вот последний раз это было несколько недель назад - раньше работало, а потом перестало и начали смотреть почему - а там в таблице запись поменяли, в которой конфигурация хранилась. И так как у нас есть историческая таблица - увидели кто и когда это сделал.
Ну т.е. всё равно приходим к тому что нужно хранить created, updated? И они не нужны примерно в 99%, но вот когда нужны - вот тут прям без них ни как. Это как логи - зачем в них смотреть когда всё работает? Но если что-то не так - они как раз кстати.
Мне вообще статья понравилась.
Есть llm, есть спорные моменты, но у нас же не научное сообщество, а инженерное и тут как известно нет серебряной пули - для какого-то приложения всё это будет работать, а для другого - нет. Так что хорошо что обсуждаем. И автор в комментах дискуссию ведёт, а не просто запостил. :-)
С rur rub пример не валиден - это же валюта другая стала.
Вообще я бы общее правило сделал - если ваше приложение данными не владеет, а просто сохраняет как есть, то тут суррогатнай ключ не нужен. (С другой стороны не всегда ясно какой тут натуральный ключ использовать, но в моей практике обычно понятно было) И курсы валют как раз хороший пример - всё что вам дали и вы записали как есть.
Но если ваше приложение создаёт данные - то оно и ключ может записать.
Сорри, но дальше комментарий можно не читать.
Вот когда вы точно уверены что это это внешне значение можно использовать как первичный ключ? Сегодня мы думаем что у нас у пользователя email - уникальный, а завтра он поменяется, или вообще будет две копии пользователя с одним email но второй будет помечен как deleted.
И когда ключи стандартизированны - типа всегда число. То можно в коде писать generic квери для обработки кучи разных таблиц одинаково.
На счёт перфоманса не понял - если там нет индексов, то в чём проблема?
Вообще ни разу не спорное. И я бы ещё добавил что лучше хранить историю изменений таблицы, для доступа к последней версии записи ввести что-то вроде is_last.
Потому что когда на проде что-то пройдёт не так и к тебе придут с вопросом, а почему тут такие значения, то гораздо удобнее ответ получить из селекта. Где будет по шагам расписано что именно кто и когда менял, чем ходить по логам и искать что там вообще было.
Логи в любом случае нужны, но из базы это всё удобнее получить и более наглядно.
И так как мы в будущее плохо смотрим, то я выбрал простую стратегию - всегда пишем, а если как то это будет негативно влиять (ни разу с этим не сталкивался, но всё же) то явно конкретно в этом месте не используем.
Но вообще всё зависит от бизнеса. В банках важно, кто когда что-то поменял (с них потом спросят), поэтому тут лучше всё писать. Где нибудь в pet project - наверное нет.
Согласен. Вот это сейчас происходит на рынке 3d принтеров:
Этому рынку уже несколько десятков лет. Из которых лет 10 уже можно было самому купить принтер за вполне демократичную цену. Но всё это было сложно и требовало прям знаний и погружения в тему. И не смотря на это было куча производителей. Но несколько лет назад пришли бывшие сотрудники DJI и по сути стали стандартом со своими BambuLab принтерами. Т.е. несмотря даже уже на развитый рынок с конкурентами - хороший продукт легко занимает большую долю. И реплики хуже, не получается скопировать.