Часто говорят, что писать SQL вручную и маппить ResultSet в модели через getXXX()/setXXX() — скучно и неудобно. Возможно. Но это всего лишь эмоции разработчиков.
Это не эмоции разработчиков. Ручной маппинг - это непаханное поле для граблей и ошибок. ORM делает маппинг за тебя и он даёт гарантию, что маппинг всегда корректный и там нет ошибок. В отличии от ИИшечки, кстати.
ORM - это та штука, которая не просто делает эту работу с гарантией, она ещё и здорово облегчает переделку/рефакторинг.
Во-первых надо разделять вопросы. Ответ "почему чайник не светит" - просто потому, что интенсивность излучения зависит от четвёртой степени температуры. По сравнению с солнцем чайник холодный.
Это исчерпывающий ответ на первый вопрос. Потому что дальше можно задавать вопросы сколько угодно.
Например: а почему в недрах солнца высокое давление? Откуда там взялась изначально температура? Почему при этой температуре и этом давлении происходит синтез? Почему при синтезе выделяется именно вот столько энергии? И откуда взялась гравитация?
Надо смотреть по ядрам и потокам. 12700 это 20 потоков и 25-30 процентов - это полная загрузка 5-6 потоков или трёх ядер. В x3d смысл как раз в том, что производительности на ядро больше за счёт кэша. То есть те самые ядра, которые являются узким местом, начинают работать быстрее.
Если хоть одно ядро упирается в 100%, то узкое место - процессор. Можно по-другому посмотреть: если во время игры видеокарта не загружена на 100%, то узкое место - процессор.
Среди людей есть интроверты, которым совершенно нормально в одиночестве и они не сходят с ума.
А вообще у людей есть нейромедиаторы. Фокус в том, что скорость "раскачки" нейромедиаторов намного ниже, чем у мыслей в чистом виде и они работают ровно также, как амортизаторы в машине - не дают раскачиваться и гасят пиковые колебания.
Это прямо идеальный пример, когда комментарий рассказывает "почему именно так", а не "что делает метод". И это правильный комментарий.
Но тут есть один нюанс. Этот комментарий должен быть не перед методом, который делает что-то в соответствии с "№ .... ФЗ", а где-то посередине кода, прямо перед вызовом этого метода. Потому что сам метод не знает о том, зачем его вызывают и в соответствии с каким ФЗ. Он просто делает свою работу, когда от него требуют.
Вы так пишете, как-будто если код внутри нашего проекта, то просто у всех программистов в команде идеальное знание кода и что какая часть делает
Я пишу так, как будто у всех программистов в команде есть представление о предметной области и они хорошо знают язык программирования. И они хотя бы в курсе архитектурных решений того куска кода, на который смотрят.
Этого уровня вполне достаточно, чтобы не засорять код бессмысленными комментариями, и в то же время эта планка достаточно низка, чтобы можно было её считать квалификационным барьером.
Комментарии, рассчитанные на читателя, не обладающего соответствующей квалификацией не делают код понятнее для этого читателя. Но затрудняют работу над проектом тем, кто проходит квалификационный барьер.
А давайте не путать публичные библиотечные функции с кодовой базой внутреннего проекта? Там всё-таки разные требования.
Вот к чему такое чёрно-белое мышление?
Вот расставление редфлагов по признаку "не пишу для каждой функции комментарий" и есть чёрно-белое мышление. Или кандидат думает как мы, или он плохой.
Потому что их надо уметь писать
Потому что вырываете слова из контекста. Если комментарий пишется по принципу "всё должно быть задокументировано", то в нём смысла нет. Когда комментарий пишется по принципу "тут надо бы пояснить читателю", то в нём смысла на порядок больше.
ReadFileReturnsZeroOnSuccessAndNegativeOneOnError
"readfile". Не силён в чистых сях, но существуют конвенции. 0, если выполнилось без ошибок, -1, если была ошибка. Конвенциальности в именование не вносятся. Это во-первых.
А во-вторых опять же, не надо путать публичные библиотечные функции с кодовой базой внутреннего проекта.
Если кандидат говорит «мой код самодокументируем» или «не пишу комментарии, они устаревают» — красный флаг.
А что он не так говорит? Уж сколько раз твердили миру, что если пишете комментарий о том, что этот метод делает - значит у вас неправильное название. И да, я видел команды, которые своё неумение в нейминг пытаются компенсировать комментариями. И да, комментарии потом забывают править, они устаревают. Всё правильно.
А остальные комментарии по правилу "всё должно быть документировано" являются просто мусором, забивающим контекстное окно. В итоге код с комментариями понимать гораздо сложнее, потому что комментарии бесполезны, а нейминг отвратительный. Приходится по каждому методу проходить и смотреть, что он там на самом деле делает.
Человек может умеет работать с наименованиями. А у вас сразу ред флаг. Не надо так.
Вот жалко, что в таблице нет Native AOT compability. Да в принципе я уже вижу, что у вас примерно всё на рефлекшене, а значит в native aot работать не будет.
Жаль. Как раз сейчас мне нужен парсинг команд cli для native aot приложения.
У нас нет "пространства". У нас есть "пространство-время". И мы не можем просто разнести локальную систему в пространстве, не разнеся её во времени.
Короче, я понял. Вы не в курсе этой проблемы. И немножко не понимаете о чём я.
Попробую чуть подробнее. И сам же отвечу на свой вопрос. Это событие происходит только в точке отсчёта наблюдателя. То есть для первого наблюдателя момент "коллапса" по его системе, а для второго - в его. Потому что без наблюдателя никакого "коллапса" не наблюдается. Об этом говорит тот самый эксперимент про "квантовый ластик", когда частица меняет поведение в зависимости от того, как обрабатываются сигналы детекторов. ПОСЛЕ всех взаимодействий. И наблюдатель - это не детектор. Просто потому что в одном случае детектор вызывает "коллапс", а в другом - нет. Без изменения схемы взаимодействия.
Но я не к квантовому ластику вёл, не спешите радоваться. Он только дополняет картину. Сейчас важно то, что никакое состояние никуда не передаётся. И частицы не "видят", что за ними наблюдают. Да и с чего бы вдруг? Они просто частицы. Они не умеют говорить, они не умеют наблюдать. И они не умеют коллапсировать оттого, что где-то там учёный пронаблюдал спутанную частицу. Вообще - коллапс волновой функции - это наблюдение. И без наблюдателя его не будет. А теперь вопрос: а может это не пара частиц обретает конкретное состояние, а наблюдатель входит в спутанность с этой парой?
А вы понимаете, что термина "сразу" для нелокальной системы не существует?
Допустим, есть две спутанные частицы, разнесённые на расстоянии. Есть три наблюдателя - рядом с первой частицей, рядом со второй и ровно посередине. Частицы измеряются одновременно для центрального наблюдателя. В системе первого наблюдателя первой вскрывается первая частица, с точки зрения второго - вторая. И теперь вопрос - а в какой момент изменяется состояние всей системы?
Nullable types, вроде "int?", params[], async/await, не?
Тут по каждому пункту просто дикая дичь написана. Какой ещё ContinueWith, вы чего...
Я просто вижу, что автор вообще не понимает шарп. Ну совсем. Ни капельки. Ну не понимает и не понимает, ладно. Но статью зачем писать?
Это не эмоции разработчиков. Ручной маппинг - это непаханное поле для граблей и ошибок. ORM делает маппинг за тебя и он даёт гарантию, что маппинг всегда корректный и там нет ошибок. В отличии от ИИшечки, кстати.
ORM - это та штука, которая не просто делает эту работу с гарантией, она ещё и здорово облегчает переделку/рефакторинг.
Во-первых надо разделять вопросы. Ответ "почему чайник не светит" - просто потому, что интенсивность излучения зависит от четвёртой степени температуры. По сравнению с солнцем чайник холодный.
Это исчерпывающий ответ на первый вопрос. Потому что дальше можно задавать вопросы сколько угодно.
Например: а почему в недрах солнца высокое давление? Откуда там взялась изначально температура? Почему при этой температуре и этом давлении происходит синтез? Почему при синтезе выделяется именно вот столько энергии? И откуда взялась гравитация?
Надо смотреть по ядрам и потокам. 12700 это 20 потоков и 25-30 процентов - это полная загрузка 5-6 потоков или трёх ядер. В x3d смысл как раз в том, что производительности на ядро больше за счёт кэша. То есть те самые ядра, которые являются узким местом, начинают работать быстрее.
Если хоть одно ядро упирается в 100%, то узкое место - процессор. Можно по-другому посмотреть: если во время игры видеокарта не загружена на 100%, то узкое место - процессор.
Среди людей есть интроверты, которым совершенно нормально в одиночестве и они не сходят с ума.
А вообще у людей есть нейромедиаторы. Фокус в том, что скорость "раскачки" нейромедиаторов намного ниже, чем у мыслей в чистом виде и они работают ровно также, как амортизаторы в машине - не дают раскачиваться и гасят пиковые колебания.
Это прямо идеальный пример, когда комментарий рассказывает "почему именно так", а не "что делает метод". И это правильный комментарий.
Но тут есть один нюанс. Этот комментарий должен быть не перед методом, который делает что-то в соответствии с "№ .... ФЗ", а где-то посередине кода, прямо перед вызовом этого метода. Потому что сам метод не знает о том, зачем его вызывают и в соответствии с каким ФЗ. Он просто делает свою работу, когда от него требуют.
Я пишу так, как будто у всех программистов в команде есть представление о предметной области и они хорошо знают язык программирования. И они хотя бы в курсе архитектурных решений того куска кода, на который смотрят.
Этого уровня вполне достаточно, чтобы не засорять код бессмысленными комментариями, и в то же время эта планка достаточно низка, чтобы можно было её считать квалификационным барьером.
Комментарии, рассчитанные на читателя, не обладающего соответствующей квалификацией не делают код понятнее для этого читателя. Но затрудняют работу над проектом тем, кто проходит квалификационный барьер.
А давайте не путать публичные библиотечные функции с кодовой базой внутреннего проекта? Там всё-таки разные требования.
Вот расставление редфлагов по признаку "не пишу для каждой функции комментарий" и есть чёрно-белое мышление. Или кандидат думает как мы, или он плохой.
Потому что вырываете слова из контекста. Если комментарий пишется по принципу "всё должно быть задокументировано", то в нём смысла нет. Когда комментарий пишется по принципу "тут надо бы пояснить читателю", то в нём смысла на порядок больше.
"readfile". Не силён в чистых сях, но существуют конвенции. 0, если выполнилось без ошибок, -1, если была ошибка. Конвенциальности в именование не вносятся. Это во-первых.
А во-вторых опять же, не надо путать публичные библиотечные функции с кодовой базой внутреннего проекта.
Не "зачем это делает". А "почему именно так". Зачем это метод делает решает не метод, а вызывающая сторона. Ей виднее зачем.
А что он не так говорит? Уж сколько раз твердили миру, что если пишете комментарий о том, что этот метод делает - значит у вас неправильное название. И да, я видел команды, которые своё неумение в нейминг пытаются компенсировать комментариями. И да, комментарии потом забывают править, они устаревают. Всё правильно.
А остальные комментарии по правилу "всё должно быть документировано" являются просто мусором, забивающим контекстное окно. В итоге код с комментариями понимать гораздо сложнее, потому что комментарии бесполезны, а нейминг отвратительный. Приходится по каждому методу проходить и смотреть, что он там на самом деле делает.
Человек может умеет работать с наименованиями. А у вас сразу ред флаг. Не надо так.
Вот жалко, что в таблице нет Native AOT compability. Да в принципе я уже вижу, что у вас примерно всё на рефлекшене, а значит в native aot работать не будет.
Жаль. Как раз сейчас мне нужен парсинг команд cli для native aot приложения.
Энштейн говорил, что нет случайности в определения спина. И ещё что-то про нелокальное взаимодействие.
Теория скрытых параметров - это как пример, как могут обстоять дела на самом деле. Вот она была опровергнута. Она одна.
А нелокальное взаимодействие не было доказано. Как и то, что спин случаен. Так что не играет.
Музей поддельного искусства?
Я уже над неймингом и маркетингом для вашего проекта работаю, возьмёте в команду?
Секретный индейский ритуал
Отлично, я договариваюсь с судьями и подаю на вас в суд. Теперь либо вы суд проигрываете, либо отдаёте мне исходный код.
Может и нет. А вот квантовый ластик есть.
В том, что когда хронометры будут физически разноситься, то время у них уйдёт. Ок?
И когда один хронометр потом поднесут ко второму, они будут показывать разное время. Просто потому что их разносили в разные стороны.
У нас нет "пространства". У нас есть "пространство-время". И мы не можем просто разнести локальную систему в пространстве, не разнеся её во времени.
Короче, я понял. Вы не в курсе этой проблемы. И немножко не понимаете о чём я.
Попробую чуть подробнее. И сам же отвечу на свой вопрос. Это событие происходит только в точке отсчёта наблюдателя. То есть для первого наблюдателя момент "коллапса" по его системе, а для второго - в его. Потому что без наблюдателя никакого "коллапса" не наблюдается. Об этом говорит тот самый эксперимент про "квантовый ластик", когда частица меняет поведение в зависимости от того, как обрабатываются сигналы детекторов. ПОСЛЕ всех взаимодействий. И наблюдатель - это не детектор. Просто потому что в одном случае детектор вызывает "коллапс", а в другом - нет. Без изменения схемы взаимодействия.
Но я не к квантовому ластику вёл, не спешите радоваться. Он только дополняет картину. Сейчас важно то, что никакое состояние никуда не передаётся. И частицы не "видят", что за ними наблюдают. Да и с чего бы вдруг? Они просто частицы. Они не умеют говорить, они не умеют наблюдать. И они не умеют коллапсировать оттого, что где-то там учёный пронаблюдал спутанную частицу. Вообще - коллапс волновой функции - это наблюдение. И без наблюдателя его не будет. А теперь вопрос: а может это не пара частиц обретает конкретное состояние, а наблюдатель входит в спутанность с этой парой?
А вы понимаете, что термина "сразу" для нелокальной системы не существует?
Допустим, есть две спутанные частицы, разнесённые на расстоянии. Есть три наблюдателя - рядом с первой частицей, рядом со второй и ровно посередине. Частицы измеряются одновременно для центрального наблюдателя. В системе первого наблюдателя первой вскрывается первая частица, с точки зрения второго - вторая. И теперь вопрос - а в какой момент изменяется состояние всей системы?
Я осмелюсь спросить: а корреляция состояния и доказанность передачи состояния со сверхсветовой скоростью для вас одно и то же?