У меня когда-то был профи с аж целым мегабайтом на борту. И для меня осталось без ответа два вопроса к экрану:
Зачем такую сложную адресацию сделали? Это же реально неудобно. Для рисования графики сделали систему адресации спектрума ещё сложнее, ещё неудобнее, а с другой стороны, поломали удобство рисования символов 8х8. Зачем?
Сделали аттрибут для линии 8х1 вместо 8х8. С одной стороны увеличили объём аттрибутов в восемь раз, сравняв с bitfield, а с другой так и не сделали индивидуальные цвета в пикселях. Ну почему? Всего вдвое увеличить объём видеопамяти и были бы полноценные картинки. Уж профик 512 (тем более мегабайт) мог бы себе позволить.
В итоге экран профика оказался такой "ни рыба ни мясо". Для демомейкинга слишком толстый и неповоротливый, для работы с текстом впрочем тоже. Для графики слишком сложный и геморройный из-за неоправданных цветовых аттрибутов. Три цвета в линии 8х1 не нарисуешь.
Вы сами всё написали, ещё и с примерами. В кириллице 33 буквы, в латинице 26. Если вычесть специфичные буквы вроде "W", "X", "Q", получится, что у трети кириллицы нет прямой транслитерации. Можно транслитерировать в сочетания букв, но тут опс: у каждой буквы в сочетании уже есть обратная прямая замена. Выходит, что даже чисто математически - транслитерация операция необратимая.
Проверять конечно надо. Но я думаю, что результат совершенно предсказуем при наличии векторных операций или каком-либо кэше.
Вы абсолютно правы, что ваш алгоритм лучше для минимизации времени каждой выборки. Собственно, я подумал, а можно ли уменьшить максимальное время выборки и думал в сторону размазывания сдвига по операциям записи. Получился тот же алгоритм, что у вас.
Но. Можно сделать ещё лучше. Так сказать объединить алгоритмы. Если у нас известна кратность копирования (например копируется по 128 бит, а юнит у нас инт в 32 бита), то можно писать через 4 записи. Так же дважды, как предлагали.
Я, конечно, знал, что я асоциальное существо и нон-конформист, но похоже, что у меня рекорд )
28 рейтинга минус рис и кошка-жена
Чувствую себя хорошо, пилю стартап, живу на сбережения и проценты по депозитам.
Собственно, результат только подтверждает мысль, что результат теста показывает только результат теста и ничего более. О куче нюансов он не знает и знать не может.
Неа. БД не в курсе про ваши сценарии использования данных. У неё свои представления о прекрасном. Она не знает, когда надо дропнуть кэш, она не угадает, какие данные надо предварительно закешировать, она не в курсе, что вот этот тяжёлый запрос нужен раз в полгода.
Не, не зря. В спецификации той же MySql написано, что корректная работа без PK не гарантируется. Подозреваю, что у всех остальных так же.
Логи записывать в БД - это ещё один повод вызвать полицию. Вот зачем? Есть же тот же самый NLog и ещё куча решений. Выборка логов нужна примерно раз в никогда лет. Ротация нужна по переполнению. БД это тупо не умеет. В файловых логах это мало того, что проще, так ещё и меньше диска занимает и можно выделить хранилище как раз для данных такого рода ценности.
Создавая таблицу без ключа, люди ставят под сомнение сам факт, что тут нужна реляционная система хранения данных. Ну действительно. Нет ключа - нет реляционности. Нет апдейта, нет делита, просто потому, что не за что зацепиться.
Так жук это тот же самый ORM. У него есть свой собственный язык запросов, который транслируется в SQL. И точно также он не покрывает все нюансы SQL и точно также не должен. Фрукт-фрукт.
Про MyBatis уже был спор с кем-то. Утверждали, что он не ORM. Ну да, он просто маппер.
Нафига вам спринг дата я не знаю. Она и мне, если честно не нужна, вместе с жавой. Шарп как-то вкуснее мне оказался. Но то, что есть большая проблема управления сложностью в больших проектах - это факт. Внедрение ORM хорошо помогает с ней справиться, отделяя слой работы с БД от бизнес-логики. Для меня ещё очень важно, что полностью исключаются ошибки маппинга.
Так удобнее )
Скрин IDE в 4К
У меня когда-то был профи с аж целым мегабайтом на борту. И для меня осталось без ответа два вопроса к экрану:
Зачем такую сложную адресацию сделали? Это же реально неудобно. Для рисования графики сделали систему адресации спектрума ещё сложнее, ещё неудобнее, а с другой стороны, поломали удобство рисования символов 8х8. Зачем?
Сделали аттрибут для линии 8х1 вместо 8х8. С одной стороны увеличили объём аттрибутов в восемь раз, сравняв с bitfield, а с другой так и не сделали индивидуальные цвета в пикселях. Ну почему? Всего вдвое увеличить объём видеопамяти и были бы полноценные картинки. Уж профик 512 (тем более мегабайт) мог бы себе позволить.
В итоге экран профика оказался такой "ни рыба ни мясо". Для демомейкинга слишком толстый и неповоротливый, для работы с текстом впрочем тоже. Для графики слишком сложный и геморройный из-за неоправданных цветовых аттрибутов. Три цвета в линии 8х1 не нарисуешь.
???
Так и на чём?
Я теперь понял, что вы сделали. Вы превратили j, y, h в префиксы и постфиксы, не используя их в обратной транслитерации.
То, что вы сделали, действительно может помочь в цели полной обратной совместимости. За счёт читаемости. Но у меня вопрос, а зачем?
Кстати, у вас "y" и "h" используются и как префикс и как постфикс. Соответственно, возможны коллизии.
Yod это ёд или йод? Окей, если не брать эрративы Pasha это пасха или Паша?
Вы сами всё написали, ещё и с примерами. В кириллице 33 буквы, в латинице 26. Если вычесть специфичные буквы вроде "W", "X", "Q", получится, что у трети кириллицы нет прямой транслитерации. Можно транслитерировать в сочетания букв, но тут опс: у каждой буквы в сочетании уже есть обратная прямая замена. Выходит, что даже чисто математически - транслитерация операция необратимая.
Нет
Мммм, пахнуло Мари Кондо. Для диайвайщика это очень плохой совет.
Минусы ставят ввиду абсолютной бессмысленности статьи. Ну и плюс реклама телеграм-канала. Вместе оно понятно, зачем вообще автор здесь.
Проверять конечно надо. Но я думаю, что результат совершенно предсказуем при наличии векторных операций или каком-либо кэше.
Вы абсолютно правы, что ваш алгоритм лучше для минимизации времени каждой выборки. Собственно, я подумал, а можно ли уменьшить максимальное время выборки и думал в сторону размазывания сдвига по операциям записи. Получился тот же алгоритм, что у вас.
Но. Можно сделать ещё лучше. Так сказать объединить алгоритмы. Если у нас известна кратность копирования (например копируется по 128 бит, а юнит у нас инт в 32 бита), то можно писать через 4 записи. Так же дважды, как предлагали.
У вас запись O(1), но дважды.
Можно также брать массив N+M и через каждые M записей сдвигать в ноль. При 2N массиве это будет быстрее, чем дважды писать каждую запись.
"Кажется, у нас новый председатель" (с)
Я, конечно, знал, что я асоциальное существо и нон-конформист, но похоже, что у меня рекорд )
28 рейтинга минус рис и кошка-жена
Чувствую себя хорошо, пилю стартап, живу на сбережения и проценты по депозитам.
Собственно, результат только подтверждает мысль, что результат теста показывает только результат теста и ничего более. О куче нюансов он не знает и знать не может.
Вы не правы в том, что умственный труд - это отдых. Знаете, когда я вагоны грузил, я не так уставал, как при умственном труде.
Конечно, в среднем по больнице, жить стало проще. Основной контраргумент автору - базовые потребности закрываются намного дешевле, ибо прогресс.
С одной стороны прогресс сильно разгрузил простую работу, а с другой научился выжимать всё из интеллектуального труда.
Мы страдаем. Лучше бы я остался вагоны разгружать (хотя кому я вру?)
А, понял, вопросов больше не задаю
Ну вот тут спорно
Неа. БД не в курсе про ваши сценарии использования данных. У неё свои представления о прекрасном. Она не знает, когда надо дропнуть кэш, она не угадает, какие данные надо предварительно закешировать, она не в курсе, что вот этот тяжёлый запрос нужен раз в полгода.
Автомат по ремонту и апгрейду оружия уже предлагали? Можно сделать в корпусе холодильника
Не, не зря. В спецификации той же MySql написано, что корректная работа без PK не гарантируется. Подозреваю, что у всех остальных так же.
Логи записывать в БД - это ещё один повод вызвать полицию. Вот зачем? Есть же тот же самый NLog и ещё куча решений. Выборка логов нужна примерно раз в никогда лет. Ротация нужна по переполнению. БД это тупо не умеет. В файловых логах это мало того, что проще, так ещё и меньше диска занимает и можно выделить хранилище как раз для данных такого рода ценности.
Создавая таблицу без ключа, люди ставят под сомнение сам факт, что тут нужна реляционная система хранения данных. Ну действительно. Нет ключа - нет реляционности. Нет апдейта, нет делита, просто потому, что не за что зацепиться.
Так жук это тот же самый ORM. У него есть свой собственный язык запросов, который транслируется в SQL. И точно также он не покрывает все нюансы SQL и точно также не должен. Фрукт-фрукт.
Про MyBatis уже был спор с кем-то. Утверждали, что он не ORM. Ну да, он просто маппер.
Нафига вам спринг дата я не знаю. Она и мне, если честно не нужна, вместе с жавой. Шарп как-то вкуснее мне оказался. Но то, что есть большая проблема управления сложностью в больших проектах - это факт. Внедрение ORM хорошо помогает с ней справиться, отделяя слой работы с БД от бизнес-логики. Для меня ещё очень важно, что полностью исключаются ошибки маппинга.
Я вызываю полицию!