Визуальный шум - это визуальные элементы, не несущие никакого смысла, но отвлекающие внимание.
А здесь просто примеры нечитаемого текста. С ним понятно как бороться. Есть рекомендуемая контрастность - 4,5:1, есть какой-то угловой размер символов, есть читаемый шрифт, есть нечитаемый.
Ровно наоборот. Предостерегает играть в ясновидение. Это сейчас вам кажется, что без микросервисов не обойтись в будущем, потому что будет миллион клиентов. А реальность может быть куда прозаичнее.
У меня нет трудностей с пониманием английского. Если у вас есть трудности - воспользуйтесь своей же ссылкой.
Добавление слоёв архитектуры "на будущее" имеет свою цену. В виде усложнения дальнейшей разработки. И если, как это часто бывает, оно не окупается, то YAGNI. Это известный антипаттерн и называется "оверинжениринг". И да, он существует. И я часто его вижу в реальности.
Собственно вот и всё. Когда разраб точно знает, что внедрение технологии/фреймворка имеет больше плюсов, чем минусов, то yagni уже не актуален. Он про то, что нужно задумываться над тем, ЗАЧЕМ нужно усложнять себе жизнь, наворачивая новые слои архитектуры. Не больше и не меньше. Просто брать только то, что нужно.
Подстелить соломку помогает, только если знать, где падать будешь. А тупое оборачивание себя целиком в солому вредит. Это просто тупой и бессмысленный расход сеноматериала и своих сил. Yagni как раз про это. Про то, что по умолчанию тебе ничего не нужно.
Этот принцип не запрещает "стелить соломку". Он тебе говорит, что не нужна тебе солома по умолчанию. Нужна только тогда, когда ты знаешь где и от чего.
Есть интеллектуальное большинство, которому всё вредит. И разбить стеклянный предмет могут, порезав руки. Это не значит, что стеклянный предмет вредит, это значит, что им пользоваться не умеют.
YAGNI - это всего лишь способ не делать лишнюю работу. Избегать оверинжениринга заранее. В профессии разработчика, где есть миллион способов решения задачи, это ключевой принцип эффективной работы. И если он вам постоянно вредит, у меня для вас плохие новости.
Мне вот неудобно "_" набирать. Руки уходят с позиции, поэтому змеиные имена печатаются тупо дольше. А привыкнуть можно к любому написанию, да.
LowCode/NoCode - ну про это даже странно говорить. Всегда было игрушкой. Чуть дальше, чем за рельсы - и привет, сделать гораздо сложнее, чем написать код.
Микросервисы конфликтуют с YAGNI. Это не значит, что они плохие, это значит, что их надо использовать, когда они нужны и не брать эту архитектуру по умолчанию. Обычно их берут для того, чтобы упростить процесс разработки, подробив код на маленькие части. Но это только переносит сложности на этап интеграции. Ну и добавляет оверхеда на сериализацию и сетевые задержки.
Когда вы компилируете .NET приложение на C#, вы получаете на выходе IL-код, который потом интерпретируется виртуальной машиной
У вас "компилируете" и "интерпретируется" в одном предложении.
Как и тот же JIT в разы медленнее, чем условный C++ скомпилированный в ассемблер
JIT не может быть медленнее, он компилятор. И нет, не в разы медленнее. Он компилирует не только под конкретную архитектуру, но и под особенности конкретного процессора, что иногда приводит к тому, что C# оказывается быстрее C++.
Ну и надо упомянуть такой режим дотнета, как Native AOT. Это когда JIT компилирует в исполняемый бинарь ДО публикации, а не перед запуском на целевой машине. Я именно так и собираю OrmFactory. К теме статьи - да, там есть сборка под linux arm64. Так что никаких трансляторов не нужно.
Хороший вопрос. Но упоминанием тут не обойтись, это отдельная и глубочайшая кроличья нора.
Я считаю, что задача ORM - работать в рантайме. Весь тулчейн вокруг процесса разработки должен обеспечиваться внешними инструментами. Собственно, я такой инструмент и делаю. Для миграций я сделал отдельный вид генераторов, которым на вход попадает дифф базы данных, а генератор уже под конкретный орм делает миграцию. Это нужно тем, кому необходимо держать историю миграций и создавать ddl откатов.
Это работает так: вы работаете с тестовой и локальной базой и изменяете её без оглядки на миграцию. Когда ваша фича заработала, вы просто сравниваете модель с базой прода и вам генератор выкатывает миграцию. Можно и без миграции накатить изменения на прод, дифф сразу предлагает выбрать изменения, которые нужно накатить.
Такая ошибка будет видна буквально в первом тестовом запуске на этапе разработки, поэтому ее цена - несколько человеко-минут. Лично я вообще разрабатываю с консолью в соседнем окне, чтобы сразу проверять корректность написанного запроса, поэтому шанс выкатить нерабочий запрос мизерный.
Это не так. После переименования поля легко забыть поменять запрос, написанный пару лет назад где-то в редко используемом месте. Это если используется ORM, тогда программа просто не скомпилится, в случае raw SQL это забытое место всплывёт в продакшене и уже сильно позже, когда детали подзабудутся.
Просто в моём понимании ORM - это object-relational mapping. А про трекер я что-то забыл совсем. Он мне кажется таким естественным, что о нём и упоминать не надо. Вроде как у всех так должно быть.
Я не для того месяцы нервов потратил на изучение слепой печати, что бы кривить позвоночник печатая со смещением из-за наличия нумблока.
У меня два вопроса. Как вам помогает слепая печать при наборе цифр? Я тоже умею в слепую печать, но цифры набирать на нампаде гораздо удобнее.
И почему бы не подвинуть ноутбук на пару сантиметров вправо? Я не очень разбираюсь в человеческой анатомии, не знаю, откуда позвоночник в руках, но это действие поможет отцентровать клавишу пробела относительно вашего тела.
Я не работаю в закрытом контуре. Но в году 13-14м работал над одним оборонзаказом. Там писалось на шарпе, всё сертифицировалось и использовалась сертифицированная постгря (с проверенными исходниками).
В широком смысле этого слова, конечно, почти все языки, включая c#, компилируемые.
Нет. Есть интерпретируемые языки. Их целый пласт.
компилируется в IL и дальше выполняется под управлением .net runtime
Нет. IL код не выполняется. Он промежуточный. Он даже так называется.
который сам JIT-компилирует и контролирует работу приложения.
JIT ничего не контролирует. Он компилятор.
И если пофантазировать
Фантазировать можно что угодно. Факт в том, что один и тот же промпт не даёт одного и того же результата. Также, как с мясной нейросетью, необходимо фиксировать алгоритмы обработки в чём-то однозначным, что компилируется всегда в одно и то же.
c++ это пожалуй один из немногих популярных языков, где поддерживаются практически все современные парадигмы программирования, и при этом - он компилируемый. Такими свойствами, управляемые языки не обладают
Как это не обладают? Шарп компилируемый и мультипарадигменный язык высокого уровня. И функциональная парадигма у него более развита, чем у c++. Да, у него нет темплейтов, зато есть рефлекшен.
Рантайм шарпа тоже шаред, если не селфконтейнить и не компилить в нейтив. Здесь уже вам самим выбирать, поставлять вашу версию с дистрибом или требовать её наличие на целевой машине. Другими способами эта дилема не решается.
Во вторых, в дотнете нет виртуальной машины. jit-компилятор есть, он используется, если не комплировалось с native aot. А дальше работает скомпилированный машинный код. Без виртуализации. Без ограниченной среды. Рантайм дальше это уже просто набор библиотек.
Визуальный шум - это визуальные элементы, не несущие никакого смысла, но отвлекающие внимание.
А здесь просто примеры нечитаемого текста. С ним понятно как бороться. Есть рекомендуемая контрастность - 4,5:1, есть какой-то угловой размер символов, есть читаемый шрифт, есть нечитаемый.
Короче, заголовок вводит в заблуждение.
Отучайтесь говорить за весь остальной мир. Те люди, которые поставили плюсов моему комменту - они тоже "остальной мир".
Ровно наоборот. Предостерегает играть в ясновидение. Это сейчас вам кажется, что без микросервисов не обойтись в будущем, потому что будет миллион клиентов. А реальность может быть куда прозаичнее.
У меня нет трудностей с пониманием английского. Если у вас есть трудности - воспользуйтесь своей же ссылкой.
Добавление слоёв архитектуры "на будущее" имеет свою цену. В виде усложнения дальнейшей разработки. И если, как это часто бывает, оно не окупается, то YAGNI. Это известный антипаттерн и называется "оверинжениринг". И да, он существует. И я часто его вижу в реальности.
Собственно вот и всё. Когда разраб точно знает, что внедрение технологии/фреймворка имеет больше плюсов, чем минусов, то yagni уже не актуален. Он про то, что нужно задумываться над тем, ЗАЧЕМ нужно усложнять себе жизнь, наворачивая новые слои архитектуры. Не больше и не меньше. Просто брать только то, что нужно.
К той статье я уже оставлял комментарий
Подстелить соломку помогает, только если знать, где падать будешь. А тупое оборачивание себя целиком в солому вредит. Это просто тупой и бессмысленный расход сеноматериала и своих сил. Yagni как раз про это. Про то, что по умолчанию тебе ничего не нужно.
Этот принцип не запрещает "стелить соломку". Он тебе говорит, что не нужна тебе солома по умолчанию. Нужна только тогда, когда ты знаешь где и от чего.
Есть интеллектуальное большинство, которому всё вредит. И разбить стеклянный предмет могут, порезав руки. Это не значит, что стеклянный предмет вредит, это значит, что им пользоваться не умеют.
YAGNI - это всего лишь способ не делать лишнюю работу. Избегать оверинжениринга заранее. В профессии разработчика, где есть миллион способов решения задачи, это ключевой принцип эффективной работы. И если он вам постоянно вредит, у меня для вас плохие новости.
Мне вот неудобно "_" набирать. Руки уходят с позиции, поэтому змеиные имена печатаются тупо дольше. А привыкнуть можно к любому написанию, да.
LowCode/NoCode - ну про это даже странно говорить. Всегда было игрушкой. Чуть дальше, чем за рельсы - и привет, сделать гораздо сложнее, чем написать код.
Микросервисы конфликтуют с YAGNI. Это не значит, что они плохие, это значит, что их надо использовать, когда они нужны и не брать эту архитектуру по умолчанию. Обычно их берут для того, чтобы упростить процесс разработки, подробив код на маленькие части. Но это только переносит сложности на этап интеграции. Ну и добавляет оверхеда на сериализацию и сетевые задержки.
На личном опыте проверили эффект шершавого кабана?
У вас "компилируете" и "интерпретируется" в одном предложении.
JIT не может быть медленнее, он компилятор. И нет, не в разы медленнее. Он компилирует не только под конкретную архитектуру, но и под особенности конкретного процессора, что иногда приводит к тому, что C# оказывается быстрее C++.
Ну и надо упомянуть такой режим дотнета, как Native AOT. Это когда JIT компилирует в исполняемый бинарь ДО публикации, а не перед запуском на целевой машине. Я именно так и собираю OrmFactory. К теме статьи - да, там есть сборка под linux arm64. Так что никаких трансляторов не нужно.
Хороший вопрос. Но упоминанием тут не обойтись, это отдельная и глубочайшая кроличья нора.
Я считаю, что задача ORM - работать в рантайме. Весь тулчейн вокруг процесса разработки должен обеспечиваться внешними инструментами. Собственно, я такой инструмент и делаю. Для миграций я сделал отдельный вид генераторов, которым на вход попадает дифф базы данных, а генератор уже под конкретный орм делает миграцию. Это нужно тем, кому необходимо держать историю миграций и создавать ddl откатов.
Это работает так: вы работаете с тестовой и локальной базой и изменяете её без оглядки на миграцию. Когда ваша фича заработала, вы просто сравниваете модель с базой прода и вам генератор выкатывает миграцию. Можно и без миграции накатить изменения на прод, дифф сразу предлагает выбрать изменения, которые нужно накатить.
Ну вот не надо ORM заниматься миграциями.
Это не так. После переименования поля легко забыть поменять запрос, написанный пару лет назад где-то в редко используемом месте. Это если используется ORM, тогда программа просто не скомпилится, в случае raw SQL это забытое место всплывёт в продакшене и уже сильно позже, когда детали подзабудутся.
Просто в моём понимании ORM - это object-relational mapping. А про трекер я что-то забыл совсем. Он мне кажется таким естественным, что о нём и упоминать не надо. Вроде как у всех так должно быть.
У меня два вопроса. Как вам помогает слепая печать при наборе цифр? Я тоже умею в слепую печать, но цифры набирать на нампаде гораздо удобнее.
И почему бы не подвинуть ноутбук на пару сантиметров вправо? Я не очень разбираюсь в человеческой анатомии, не знаю, откуда позвоночник в руках, но это действие поможет отцентровать клавишу пробела относительно вашего тела.
Это не придирки к формулировкам, это ключевая особенность дотнета. IL код не выполняется. Он компилируется.
Не по мере надобности, а перед запуском приложения.
Как вы себе представляете машинный код под управлением рантайма? Рантайм это библиотеки и GC. Это ваш код вызывает рантайм.
Я не работаю в закрытом контуре. Но в году 13-14м работал над одним оборонзаказом. Там писалось на шарпе, всё сертифицировалось и использовалась сертифицированная постгря (с проверенными исходниками).
Нет. Есть интерпретируемые языки. Их целый пласт.
Нет. IL код не выполняется. Он промежуточный. Он даже так называется.
JIT ничего не контролирует. Он компилятор.
Фантазировать можно что угодно. Факт в том, что один и тот же промпт не даёт одного и того же результата. Также, как с мясной нейросетью, необходимо фиксировать алгоритмы обработки в чём-то однозначным, что компилируется всегда в одно и то же.
Как это не обладают? Шарп компилируемый и мультипарадигменный язык высокого уровня. И функциональная парадигма у него более развита, чем у c++. Да, у него нет темплейтов, зато есть рефлекшен.
Рантайм шарпа тоже шаред, если не селфконтейнить и не компилить в нейтив. Здесь уже вам самим выбирать, поставлять вашу версию с дистрибом или требовать её наличие на целевой машине. Другими способами эта дилема не решается.
Во вторых, в дотнете нет виртуальной машины. jit-компилятор есть, он используется, если не комплировалось с native aot. А дальше работает скомпилированный машинный код. Без виртуализации. Без ограниченной среды. Рантайм дальше это уже просто набор библиотек.