Вообще-то это много. Очень много. Это 1/8 секунды или 8 кадров при 60 fps.
Я давно хочу клавиатуру на магнитных свичах и герконах, такая была у меня в 90х годах. Это беспрецедентная надёжность, тишина хода и мягкость нажатия. Но мир свернул не туда, популярными стали именно механические клавиатуры.
Да, тут не герконы, а датчики холла. Действительно интереснее, можно регистрировать скорость нажатия (как на миди-клавиатурах). Правда зачем - вопрос открытый. Может чтобы капсом кричать.
Датчики холла должны (при грамотной реализации) ещё одно преимущество иметь. Возможность поочерёдного скана блоков клавиш. Что исключает фантомные срабатывания "AS" + "W" = "Q". Как на оптомеханике.
Я бы взял... Но исполнение... Всратый дизайн, полное отсутствие F блока, эскейп на "Ё", нет ни стрелок, ни нампада. Ни. Че. Го.
Хороший разработчик в первую очередь должен уметь писать хороший код.
Очень хороший разработчик должен уметь писать плохой код. С полным пониманием того, какие углы срезал и какой ценой. Собственно, чтобы осмысленно писать плохой код, надо сначала научиться писать хороший. А чтобы научиться писать хороший код, надо написать много плохого. Собственно, Programming, Motherf*cker
Сама идея добавлять аннотации выглядит как костыль для непродуманной технологии. Сами анализаторы могут поменяться, в них могут внедрить AI или что там модно будет. А аннотации останутся в исходниках. И в привычках мейнтейнеров (которые ещё поменять надо будет).
Моё мнение - тут надо искать zero cost решение. Всё по той же причине, про которую говорил Торвальдс - не надо дополнительной когнитивной нагрузки на мейнтейнеров. Им и так тяжело.
Плюс психологический такой фактор. Ты профи, работаешь двадцать лет с кодом, а тебя какой-то санитайзер заставляет расписаться, что ты точно знаешь, что тут может быть переполнение. Серьёзно?
Торвальдс и не должен предлагать решение. Представьте, что в вашу работу постоянно лезут с идиотскими "оптимизациями", не зная, как это всё работает. А на ваши аргументы предлагают вам самим решить проблему.
Вообще-то Торвальдс прав и вполне внятно обосновал свою точку зрения. Если делаете инструмент, то от него должно быть больше пользы, чем вреда. Он даже расписал, в каких конкретных случаях переполнение используется осмысленно.
Существуют всяческие анализаторы кода, которые становятся умнее и умнее. Я не вижу какой-то принципиальной проблемы, чтобы научить анализатор правильно обрабатывать намеренные переполнения, имея перед собой паттерны их применения.
В таких разработках, как разработка компилятора, в первую очередь заботятся об обратной совместимости, потому что никому не надо переписывать то, на что потрачены тысячи человеко-лет. Я так понял, что Кис предлагает сломать совместимость. Вот только за это я бы его подальше ещё послал.
Может быть действительно, не стоит трогать компилятор и добавить статический анализатор в воркфлоу.
Вот удивляюсь с людей, которые ноут приравнивают к компьютеру. Я вот привык к десктопу, к его полноценным мониторам, клавиатурам, мышам. Можно, конечно, это всё подключить и к ноуту. Но он же будет выть как зараза, сводя на нет все преимущества бесшумности.
Ну и плоская клавиатура на мой вкус фу. Я такое не ем.
А зачем тогда корпус переделывать? Просто отпиливаем дисплей и получаем готовый системный блок. Жёсткость уже за нас инженеры рассчитали и применили нужные материалы. Бонусом имеем встроенный бесперебойник, встроенную клавиатуру и тачпад.
Был бы экран, вообще можно было бы пользоваться автономно...
Лень ещё как существует. Мы миллионами лет были рептилиями и каких-то 10 тыс лет назад у нас появилась перфронтальная кора головного мозга, что по меркам эволюции - секунды. Именно она отвечает за долгосрочное планирование жизни и дела, которые помогут в будущем. Если она рептилию победит, конечно. Рептилия хочет жрат и спат.
Вот когда побеждает рептилия, это и называется лень. Мы делаем то, что делают рептилии - экономим силы и запасаем жиры и делаем это в ущерб своему будущему, прекрасно об этом зная.
При рассмотрении приложения в комплексе, внезапно оказывается, что функционально неполная абстракция - это именно что SQL. Именно SQL ограничен декларативной парадигмой, а сверхсложную логику пишут на языках общего назначения.
ORM в следствии своей парадигмы, толкает на написание работы с данными внутри кода, что приводит цельности логики и его дальнейшему рефакторингу.
Про безопасность - это вообще не к орм. Просто потому что орм - маппер. То, что он умеет генерировать sql, не накладывает на него обязанность следить за уязвимостями протоколов. И вообще обычно канал orm-db защищён по умолчанию.
ролевые модели в БД умеют генерировать
Кхм. С этого места пожалуйста поподробнее. Мне кажется, что мне вас есть чем приятно удивить.
Да ладно. А MyBatis какие данные маппит? Случайно не реляционные? Может оно XML парсит?
Я же загуглить успел. MyBatis вполне себе ORM, на хабре статьи про неё есть. Внезапно с тегом ORM. Я не разобрался, умеет ли оно в джоин. Скорее всего нет. Там концепция "сам напиши свои джойны, я только маплю".
Язык SQL декларативный. В том порядке, в котором захочет СУБД. Проще её саму спросить. Индексы БД не обязана использовать, но обычно использует. Если данных много - крутите кэши под ваш сценарий. Может у вас хэви инсерт, а для селекта можно подождать - тогда кэши не спасут.
Сомневайтесь, это полезно. Проясню ремарку: сегодняшние orm, пока в них не внедрили нейросети, очень сильно ограничены по функционалу. В сгенерированных запросах нет ничего сложного. Нет латерал джойнов, в юнионы по-моему ни одна не умеет. Даже group by с having умеют единицы. Про CTE вообще молчу. Человек намного изощрённее любой ORM. Естественная нейросеть способна нагородить куда более ужасную и изощрённую конструкцию, чем самый продвинутый фреймворк
In theory, theory and practice are the same.In practice, they are not.
После переписывания на какой-нибудь шарп огромная хранимка начинает работать в разы быстрее. Почему? Просто потому, что стала понятнее и программист начал понимать, что запрашивать, что нет. Попробовал несколько вариантов построения. Просто думал на другом уровне, абстрагируясь от нагромождения sql.
p.s. триггеры, юники, ключи и прочие констрейнты работают не только для встроенного языка
Если вам сложно не нагородить десятиэтажных конструкций, может вам не надо в айти? Айти всё-таки про огромное количество вариантов, как сделать одно и то же. Здесь нет точного рецепта, как правильнее. Тут самому приходится выбирать пути, ошибаться и пробовать снова. И ещё нести ответственность за выбранные решения.
Специально сконструированный язык базы данных действительно быстрее за счёт быстрого доступа. В теории.
На практике эта скорость никому не нужна, пока приложение не умеет делать то, что оно должно делать. Быстро, но фигню - это не надо.
На практике получается парадоксальная ситуация: переписанная логика pl/sql в сишарп начинает работать быстрее в разы. Как такое возможно? Теоретически никак. Доступ к данным у шарпа по определению медленнее.
Это одно из самых распространённых заблуждений об ORM, которые я встречал. Делать сложные запросы - это не задача ORM. ORM в первую очередь - маппер. ORM и SQL вообще ортогональны в этом вопросе.
Тут так: если хотите читаемый и поддерживаемый код: пишете на орм. Хотите любить гусей - пишете на чистом sql. Как-то одно другому мешает? На практике оказывается, что сложные запросы нужны, мягко скажем, не в критичном количестве. А ежедневная рутина делается проще на орм.
Некоторые ORM вообще могут работать с raw sql. Просто позволяют писать запросы, и после делают маппинг на объекты.
Да, извиняюсь, не заметил порядок
Вообще-то это много. Очень много. Это 1/8 секунды или 8 кадров при 60 fps.
Я давно хочу клавиатуру на магнитных свичах и герконах, такая была у меня в 90х годах. Это беспрецедентная надёжность, тишина хода и мягкость нажатия. Но мир свернул не туда, популярными стали именно механические клавиатуры.
Да, тут не герконы, а датчики холла. Действительно интереснее, можно регистрировать скорость нажатия (как на миди-клавиатурах). Правда зачем - вопрос открытый. Может чтобы капсом кричать.
Датчики холла должны (при грамотной реализации) ещё одно преимущество иметь. Возможность поочерёдного скана блоков клавиш. Что исключает фантомные срабатывания "AS" + "W" = "Q". Как на оптомеханике.
Я бы взял... Но исполнение... Всратый дизайн, полное отсутствие F блока, эскейп на "Ё", нет ни стрелок, ни нампада. Ни. Че. Го.
Очень хороший разработчик должен уметь писать плохой код. С полным пониманием того, какие углы срезал и какой ценой. Собственно, чтобы осмысленно писать плохой код, надо сначала научиться писать хороший. А чтобы научиться писать хороший код, надо написать много плохого. Собственно, Programming, Motherf*cker
Сама идея добавлять аннотации выглядит как костыль для непродуманной технологии. Сами анализаторы могут поменяться, в них могут внедрить AI или что там модно будет. А аннотации останутся в исходниках. И в привычках мейнтейнеров (которые ещё поменять надо будет).
Моё мнение - тут надо искать zero cost решение. Всё по той же причине, про которую говорил Торвальдс - не надо дополнительной когнитивной нагрузки на мейнтейнеров. Им и так тяжело.
Плюс психологический такой фактор. Ты профи, работаешь двадцать лет с кодом, а тебя какой-то санитайзер заставляет расписаться, что ты точно знаешь, что тут может быть переполнение. Серьёзно?
Торвальдс и не должен предлагать решение. Представьте, что в вашу работу постоянно лезут с идиотскими "оптимизациями", не зная, как это всё работает. А на ваши аргументы предлагают вам самим решить проблему.
Вообще-то Торвальдс прав и вполне внятно обосновал свою точку зрения. Если делаете инструмент, то от него должно быть больше пользы, чем вреда. Он даже расписал, в каких конкретных случаях переполнение используется осмысленно.
Существуют всяческие анализаторы кода, которые становятся умнее и умнее. Я не вижу какой-то принципиальной проблемы, чтобы научить анализатор правильно обрабатывать намеренные переполнения, имея перед собой паттерны их применения.
В таких разработках, как разработка компилятора, в первую очередь заботятся об обратной совместимости, потому что никому не надо переписывать то, на что потрачены тысячи человеко-лет. Я так понял, что Кис предлагает сломать совместимость. Вот только за это я бы его подальше ещё послал.
Может быть действительно, не стоит трогать компилятор и добавить статический анализатор в воркфлоу.
Вот удивляюсь с людей, которые ноут приравнивают к компьютеру. Я вот привык к десктопу, к его полноценным мониторам, клавиатурам, мышам. Можно, конечно, это всё подключить и к ноуту. Но он же будет выть как зараза, сводя на нет все преимущества бесшумности.
Ну и плоская клавиатура на мой вкус фу. Я такое не ем.
Главное, чтобы Nvidia не поставила пробел куда не надо )
А зачем тогда корпус переделывать? Просто отпиливаем дисплей и получаем готовый системный блок. Жёсткость уже за нас инженеры рассчитали и применили нужные материалы. Бонусом имеем встроенный бесперебойник, встроенную клавиатуру и тачпад.
Был бы экран, вообще можно было бы пользоваться автономно...
Лень ещё как существует. Мы миллионами лет были рептилиями и каких-то 10 тыс лет назад у нас появилась перфронтальная кора головного мозга, что по меркам эволюции - секунды. Именно она отвечает за долгосрочное планирование жизни и дела, которые помогут в будущем. Если она рептилию победит, конечно. Рептилия хочет жрат и спат.
Вот когда побеждает рептилия, это и называется лень. Мы делаем то, что делают рептилии - экономим силы и запасаем жиры и делаем это в ущерб своему будущему, прекрасно об этом зная.
Вот это вот лень, а не то, что у вас в статье.
При рассмотрении приложения в комплексе, внезапно оказывается, что функционально неполная абстракция - это именно что SQL. Именно SQL ограничен декларативной парадигмой, а сверхсложную логику пишут на языках общего назначения.
ORM в следствии своей парадигмы, толкает на написание работы с данными внутри кода, что приводит цельности логики и его дальнейшему рефакторингу.
Про безопасность - это вообще не к орм. Просто потому что орм - маппер. То, что он умеет генерировать sql, не накладывает на него обязанность следить за уязвимостями протоколов. И вообще обычно канал orm-db защищён по умолчанию.
Кхм. С этого места пожалуйста поподробнее. Мне кажется, что мне вас есть чем приятно удивить.
Да ладно. А MyBatis какие данные маппит? Случайно не реляционные? Может оно XML парсит?
Я же загуглить успел. MyBatis вполне себе ORM, на хабре статьи про неё есть. Внезапно с тегом ORM. Я не разобрался, умеет ли оно в джоин. Скорее всего нет. Там концепция "сам напиши свои джойны, я только маплю".
Дружище, определись уже. Либо оно мапит данные на класс, то тогда оно ORM, либо не маппит, тогда оно не ORM.
Язык SQL декларативный. В том порядке, в котором захочет СУБД. Проще её саму спросить. Индексы БД не обязана использовать, но обычно использует. Если данных много - крутите кэши под ваш сценарий. Может у вас хэви инсерт, а для селекта можно подождать - тогда кэши не спасут.
Сомневайтесь, это полезно. Проясню ремарку: сегодняшние orm, пока в них не внедрили нейросети, очень сильно ограничены по функционалу. В сгенерированных запросах нет ничего сложного. Нет латерал джойнов, в юнионы по-моему ни одна не умеет. Даже group by с having умеют единицы. Про CTE вообще молчу. Человек намного изощрённее любой ORM. Естественная нейросеть способна нагородить куда более ужасную и изощрённую конструкцию, чем самый продвинутый фреймворк
В теории всё так. But.
In theory, theory and practice are the same. In practice, they are not.
После переписывания на какой-нибудь шарп огромная хранимка начинает работать в разы быстрее. Почему? Просто потому, что стала понятнее и программист начал понимать, что запрашивать, что нет. Попробовал несколько вариантов построения. Просто думал на другом уровне, абстрагируясь от нагромождения sql.
p.s. триггеры, юники, ключи и прочие констрейнты работают не только для встроенного языка
Если вам сложно не нагородить десятиэтажных конструкций, может вам не надо в айти? Айти всё-таки про огромное количество вариантов, как сделать одно и то же. Здесь нет точного рецепта, как правильнее. Тут самому приходится выбирать пути, ошибаться и пробовать снова. И ещё нести ответственность за выбранные решения.
И кто вам запретит писать сложные тяжёлые запросы? У вас кто-то насильно отбирает SQL?
Специально сконструированный язык базы данных действительно быстрее за счёт быстрого доступа. В теории.
На практике эта скорость никому не нужна, пока приложение не умеет делать то, что оно должно делать. Быстро, но фигню - это не надо.
На практике получается парадоксальная ситуация: переписанная логика pl/sql в сишарп начинает работать быстрее в разы. Как такое возможно? Теоретически никак. Доступ к данным у шарпа по определению медленнее.
Это ORM. По определению.
Заманчиво. Орм без недостатков орм. Как это?
Собственно, меня огорчает, что люди противопоставляют ORM чистому SQL. Одно другому не мешает. ОРМ - маппинг. SQL - язык запросов.
Простите, а зачем вам база данных в контроллере с 16кб памяти?
Это одно из самых распространённых заблуждений об ORM, которые я встречал. Делать сложные запросы - это не задача ORM. ORM в первую очередь - маппер. ORM и SQL вообще ортогональны в этом вопросе.
Тут так: если хотите читаемый и поддерживаемый код: пишете на орм. Хотите любить гусей - пишете на чистом sql. Как-то одно другому мешает? На практике оказывается, что сложные запросы нужны, мягко скажем, не в критичном количестве. А ежедневная рутина делается проще на орм.
Некоторые ORM вообще могут работать с raw sql. Просто позволяют писать запросы, и после делают маппинг на объекты.