По-моим наблюдениям (ничего не мерял, чисто субъективно) тормозит сегодня вообще все, включая Хабр, Мегамаркет, ну и все что попадалось на глаза. Т.е. это похоже на просто замедление всего трафика. Или мне кажется?
Да, идея понятна. Практически не очень понятно, насколько оно дообучится само, или же нужен специалист (или два специалиста - один в области ML, а второй в прикладной).
Ну я вот вам так скажу - у меня были проекты на gradle. Не я его туда притащил, но мне пришлось сопровождать. В итоге после изучения я его выпилил и заменил на maven, потому что императивного кода там не было. И не было ничего, что бы требовало писать код для сборки. То есть, то что тут чуть ранее написали про 80% - по моим оценкам очень близко к истине.
Но есть случаи, когда нужно собирать один и тот же проект по-разному, скажем, для разных клиентов. И тогда в сборке появляется логика, отличная от той, что умеет даже make - т.е. от описания зависимостей и списка простых последовательных шагов. И тогда код в сборке нужен.
Ну бизнес логика скорее разная, но типовые решения в нишевых приложениях тоже встречаются. Я не настаиваю, я скорее оцениваю, в каком случае я бы мог для своих нетиповых приложений это все применить. И тут не хватает на первый взгляд именно обучаемости силами пользователя. Потому что буквально сейчас там и допиливать нечего.
Это потому что у вас типовое (более чем) веб приложение. И то, бизнес логику свою вы модели доверять не собираетесь, как я вижу?
А у меня вот в приложении нет ни контроллеров, ни энтити, ни репозиториев - поэтому существующие модели его вообще написать не могут. Потому что такого кода в интернете нет или очень мало. Мне кажется, реальный прогресс в этой области будет тогда, когда я лично и быстро смогу обучить модель на моем коде, т.е. у меня будет не предобученная модель, которая умеет эти вот ваши веб приложения, а некая метамодель, которую я смогу обучить, не будучи специалистом в языковых моделях, скажем так. И которой можно будет объяснить, что вот такие конструкции - это неэффективно по памяти, например, или у них такие-то преимущества. И оно это будет учитывать при генерации, вместе с требованиями. До этого пока что далековато.
Насчет мутабельности я согласен, мутабельные ключи - это немного нонсенс. Но дерево все равно можно построить. Оно не будет такое быстрое, возможно, как хеш таблица, но работать будет.
элементы множества должны быть хэшируемыми, коими словари не являются.
Это относится только к конкретной реализации. Разве в питоне нельзя реализовать множество на базе древовидной структуры? Ну или посчитать хеш для словаря? Ни то ни другое не выглядит логически невозможным.
Ну, разумеется. И люди могли измениться, и вы (и я) в то время не все о людях понимали. Но скажем, краснодипломница - а вы правда не знаете, почему у нее красный диплом, условно говоря, за усидчивость, или потому что умная? Это же обычно ясно уже на первом курсе, не только кто как учится, но и благодаря каким чертам характера?
И я тоже не вижу ничего такого в основании своей студии. Не то что высшее образование, а и высокий ум для этого не надобен. Разумеется, нужны кое-какие черты характера, которые есть не у всех, и предсказать путь в бизнес в институте наверное не так просто.
За 13 лет человек разумеется мог сильно измениться. Но чего и кто стоил тогда за те 6 лет совместного обучения - я прекрасно вспомню и сегодня, хотя выпустился более 40 лет назад. Ну т.е. я о нем знаю что-то, хотя это могло так же устареть, как и его знания по диплому (да и мои).
В тоже время, я по работе встречал таких долбодятлов - выпускников моего же ВУЗа, что рекомендовать кого-то потому что он закончил тот же ВУЗ - разумеется нет.
Когда вы идете по трассе - у вас все внимание сосредоточено на трассе. И как раз свободно катающихся по сторонам вы в нормальной ситуации увидеть не ожидаете.
Не стоит мешать спортивные трассы и трассы для любителей, вообще не стоит, как бы вам этого ни хотелось. А тех кто кататься не умеет и при этом гоняет - тоже стоит гонять и ограничивать.
Ну т.е. идея и реализация может и интересная, но как по мне - это опасный аттракцион. Стоит как минимум продумать безопасность со всех сторон.
Не, ну я не говорил, что пытаться не стоит. Я скорее про то, что доказать бизнесу полезность будет ой как непросто. Ну этож как рефакторинг - поди докажи, что без этого будет дольше и дороже? При этом бизнес, особенно большой, в принципе готов делать много странных вещей, если его кто-то убедит, что они полезны.
Какого проекта? Ну вот смотрите, в моем совершенно реальном примере задействованы 7 систем. Никакого такого проекта, который бы изначально предполагал, что их будет вот ровно столько и они будут делать вот такие вещи - его отродясь никогда не существовало. Одна из систем - это некий "фронтенд" к АБС Диасофт, который работает коннектором к шинам - потому что оная АБС никогда не предусматривала, что ее будут с кем-то так соединять.
То есть, вся вот эта архитектура - продукт многолетнего развития, начало которого я не застал, потому что это было возможно где-то в 90-х. То есть, этому всему, или самым старым из систем, возможно лет 30. Вы думаете, там остался кто-то из тех, кто изначально их проектировал? И грубо говоря, сегодняшнее (на самом деле я оттуда ушел лет 7 назад) состояние таково, что у каждой из 7 систем есть архитектор, но нет никого, кто мог бы это переварить все целиком. В том числе и потому, что целиком это слишком сложно. Вы думаете, почему аналитики на пару месяцев удалились? Потому что аналитики оного Диасофта ничего не знает о системе источнике Мюрекс. И вряд ли быстро сможет узнать, потому что она большая и сложная сама по себе. И наоборот так же.
Ну и да, сейчас это никому не нужно, по большому счету. Оно как-то развивается, и бизнес это как-то устраивает. А будет ли лучше - никто не знает, а проводить такой эксперимент слишком дорого. Всем хочется лучше - но никто не знает верного пути туда.
Нет апдейта, нет делита, просто потому, что не за что зацепиться.
Ну я же вроде ясно написал - логи аудита (или не написал что аудит?). То что у вас в аудите нет удаления и обновления - это плюс, а не минус. Ибо нефиг обновлять документ.
Ротация нужна по переполнению. БД это тупо не умеет.
Все практические случаи что я видел, были партиционированы. Это в общем все, что от них как правило нужно (храним N лет по требованиям регулятора, через год сбрасываем на ленту партиции, и все). И это были ораклы и MS SQL, так что две эти СУБД вполне нормально работают с такими таблицами (объемы - терабайты). MySQL же в моем мире встречался один раз, и я бы сказал, что многовато у него своей специфики, чтобы считать его эталоном.
Ну то есть, я в целом скорее согласен, что решение странное (практически по всем пунктам вашего списка), но так как оно никогда не было мое - мне остается только считать его странным, не более того. И да, мне такие таблицы встречаются хорошо если одна на 10000 обычных, а у меня чужих СУБД для интеграции сотни.
ну это уже зря. Хотя это и странно, но бывают например таблицы, где хранятся просто логи. последовательность у них есть, а вот ключа нет. Это правда странно, работа с ними очень специфична, и я бы может быть сгенерировал бы длинный целочисленный ключ - но эти таблицы что мне попадались, при этом были еще и огромные. Так что создавать большущий индекс тоже не очень хочется.
Да, TOR кстати тоже.
По-моим наблюдениям (ничего не мерял, чисто субъективно) тормозит сегодня вообще все, включая Хабр, Мегамаркет, ну и все что попадалось на глаза. Т.е. это похоже на просто замедление всего трафика. Или мне кажется?
Ну, assembly это все же не совсем про логику. Или это частный случай логики, один из возможных.
Да, идея понятна. Практически не очень понятно, насколько оно дообучится само, или же нужен специалист (или два специалиста - один в области ML, а второй в прикладной).
Ну я вот вам так скажу - у меня были проекты на gradle. Не я его туда притащил, но мне пришлось сопровождать. В итоге после изучения я его выпилил и заменил на maven, потому что императивного кода там не было. И не было ничего, что бы требовало писать код для сборки. То есть, то что тут чуть ранее написали про 80% - по моим оценкам очень близко к истине.
Но есть случаи, когда нужно собирать один и тот же проект по-разному, скажем, для разных клиентов. И тогда в сборке появляется логика, отличная от той, что умеет даже make - т.е. от описания зависимостей и списка простых последовательных шагов. И тогда код в сборке нужен.
Что такое LoRA? Мне только одна такая аббревиатура попадалась, и она не про модели и обучение.
Ну бизнес логика скорее разная, но типовые решения в нишевых приложениях тоже встречаются. Я не настаиваю, я скорее оцениваю, в каком случае я бы мог для своих нетиповых приложений это все применить. И тут не хватает на первый взгляд именно обучаемости силами пользователя. Потому что буквально сейчас там и допиливать нечего.
Это потому что у вас типовое (более чем) веб приложение. И то, бизнес логику свою вы модели доверять не собираетесь, как я вижу?
А у меня вот в приложении нет ни контроллеров, ни энтити, ни репозиториев - поэтому существующие модели его вообще написать не могут. Потому что такого кода в интернете нет или очень мало. Мне кажется, реальный прогресс в этой области будет тогда, когда я лично и быстро смогу обучить модель на моем коде, т.е. у меня будет не предобученная модель, которая умеет эти вот ваши веб приложения, а некая метамодель, которую я смогу обучить, не будучи специалистом в языковых моделях, скажем так. И которой можно будет объяснить, что вот такие конструкции - это неэффективно по памяти, например, или у них такие-то преимущества. И оно это будет учитывать при генерации, вместе с требованиями. До этого пока что далековато.
Насчет мутабельности я согласен, мутабельные ключи - это немного нонсенс. Но дерево все равно можно построить. Оно не будет такое быстрое, возможно, как хеш таблица, но работать будет.
Это относится только к конкретной реализации. Разве в питоне нельзя реализовать множество на базе древовидной структуры? Ну или посчитать хеш для словаря? Ни то ни другое не выглядит логически невозможным.
Ну, разумеется. И люди могли измениться, и вы (и я) в то время не все о людях понимали. Но скажем, краснодипломница - а вы правда не знаете, почему у нее красный диплом, условно говоря, за усидчивость, или потому что умная? Это же обычно ясно уже на первом курсе, не только кто как учится, но и благодаря каким чертам характера?
И я тоже не вижу ничего такого в основании своей студии. Не то что высшее образование, а и высокий ум для этого не надобен. Разумеется, нужны кое-какие черты характера, которые есть не у всех, и предсказать путь в бизнес в институте наверное не так просто.
За 13 лет человек разумеется мог сильно измениться. Но чего и кто стоил тогда за те 6 лет совместного обучения - я прекрасно вспомню и сегодня, хотя выпустился более 40 лет назад. Ну т.е. я о нем знаю что-то, хотя это могло так же устареть, как и его знания по диплому (да и мои).
В тоже время, я по работе встречал таких долбодятлов - выпускников моего же ВУЗа, что рекомендовать кого-то потому что он закончил тот же ВУЗ - разумеется нет.
Соглашусь с предыдущим оратором.
Когда вы идете по трассе - у вас все внимание сосредоточено на трассе. И как раз свободно катающихся по сторонам вы в нормальной ситуации увидеть не ожидаете.
Не стоит мешать спортивные трассы и трассы для любителей, вообще не стоит, как бы вам этого ни хотелось. А тех кто кататься не умеет и при этом гоняет - тоже стоит гонять и ограничивать.
Ну т.е. идея и реализация может и интересная, но как по мне - это опасный аттракцион. Стоит как минимум продумать безопасность со всех сторон.
Не, ну я не говорил, что пытаться не стоит. Я скорее про то, что доказать бизнесу полезность будет ой как непросто. Ну этож как рефакторинг - поди докажи, что без этого будет дольше и дороже? При этом бизнес, особенно большой, в принципе готов делать много странных вещей, если его кто-то убедит, что они полезны.
Какого проекта? Ну вот смотрите, в моем совершенно реальном примере задействованы 7 систем. Никакого такого проекта, который бы изначально предполагал, что их будет вот ровно столько и они будут делать вот такие вещи - его отродясь никогда не существовало. Одна из систем - это некий "фронтенд" к АБС Диасофт, который работает коннектором к шинам - потому что оная АБС никогда не предусматривала, что ее будут с кем-то так соединять.
То есть, вся вот эта архитектура - продукт многолетнего развития, начало которого я не застал, потому что это было возможно где-то в 90-х. То есть, этому всему, или самым старым из систем, возможно лет 30. Вы думаете, там остался кто-то из тех, кто изначально их проектировал? И грубо говоря, сегодняшнее (на самом деле я оттуда ушел лет 7 назад) состояние таково, что у каждой из 7 систем есть архитектор, но нет никого, кто мог бы это переварить все целиком. В том числе и потому, что целиком это слишком сложно. Вы думаете, почему аналитики на пару месяцев удалились? Потому что аналитики оного Диасофта ничего не знает о системе источнике Мюрекс. И вряд ли быстро сможет узнать, потому что она большая и сложная сама по себе. И наоборот так же.
Ну и да, сейчас это никому не нужно, по большому счету. Оно как-то развивается, и бизнес это как-то устраивает. А будет ли лучше - никто не знает, а проводить такой эксперимент слишком дорого. Всем хочется лучше - но никто не знает верного пути туда.
Ну я же вроде ясно написал - логи аудита (или не написал что аудит?). То что у вас в аудите нет удаления и обновления - это плюс, а не минус. Ибо нефиг обновлять документ.
Все практические случаи что я видел, были партиционированы. Это в общем все, что от них как правило нужно (храним N лет по требованиям регулятора, через год сбрасываем на ленту партиции, и все). И это были ораклы и MS SQL, так что две эти СУБД вполне нормально работают с такими таблицами (объемы - терабайты). MySQL же в моем мире встречался один раз, и я бы сказал, что многовато у него своей специфики, чтобы считать его эталоном.
Ну то есть, я в целом скорее согласен, что решение странное (практически по всем пунктам вашего списка), но так как оно никогда не было мое - мне остается только считать его странным, не более того. И да, мне такие таблицы встречаются хорошо если одна на 10000 обычных, а у меня чужих СУБД для интеграции сотни.
ну это уже зря. Хотя это и странно, но бывают например таблицы, где хранятся просто логи. последовательность у них есть, а вот ключа нет. Это правда странно, работа с ними очень специфична, и я бы может быть сгенерировал бы длинный целочисленный ключ - но эти таблицы что мне попадались, при этом были еще и огромные. Так что создавать большущий индекс тоже не очень хочется.
Так я не говорил, что он не нужен. У меня были проекты, где я его использовал, и были где писали на голом SQL, и вообще ничего никуда не мапили.
Ну к сожалению не всегда. Видел кучку проектов, где не было ни FK (что еще бы ладно), ни даже PK.
Так я примерно про это. 10-15 лет назад все было так же, как и сегодня. Был говнокод, и были сложившиеся команды.
Ну не 10-15, побольше. А точнее даже, дело вообще не в годах.
В 2005, т.е. почти 20 лет назад, вокруг меня были вполне устоявшиеся коллективы с приличным коллективным опытом.
А то что бывали и другие, ну так скажете, что сейчас их нет, тех что без опыта и без старших товарищей, которые говнокодят на передовых технологиях?
Само же предположение о репутации... оно вполне валидное.