Три раза был свидетелем, как программисту МК предлагали напарника, помощника, а тот говорил:
А программисту напарник вовсе не нужен. Взаимодействие с другим программистом - это дополнительные сложности, всегда. А то, что результат получается медленнее - это не забота программиста. Программист в результате не заинтересован чисто объективно: ему деньги за процесс труда плятят, а не за результат. Реально, заинтересованные лица тут - владельцы бизнеса и их представители - менеджеры.
А по факту проблема в том, что без TDD (Test Driven Development) совместная разработка реально не работает
Как это: везде - работает, а при программировании микроконтроллеров - нет? Что это такая специфика именно для микроконтроллеров? В своей области я что-то такого не замечал, что без TDD никак. Вполне программировал совместно ещё в те времена, когда о TDD и слыхом не слыхали. Правда, не для микроконтроллеров, а для десктопов, на Delphi.
Неужели для микроконтроллеров нельзя найти способ организации разработки подешевле? Не знаю, как там у вас в микроконтроллерах, а я тут вот развликаюсь написанием чисто самодельной библиотеки (Middleware для ASP.NET Core) в соответствии с наилучшими практиками: могу себе позволить, потому что надо мной погонщик с кнутом не стоит. Так вот для этой библиотеки полное покрытие тестами (xUnit+Moq+VS 2022) - это примерно раза в два больше кода, чем в самой библиотеке. Причем, это - с максимальным выносом общего для тестов кода в общие классы и методы тестового проекта. Я понимаю, конечно, что код библиотеки - он не простой, там куча асинхронщины и параллельщины, которую как раз и проверять надо, а тестов - наоборот простой: там копипасты с мелкими правками много. Но даже если кода требуется не в три, а в два раза больше - это IMHO дорого, слишком.
А в реальной разработке для микроконтроллеров и без TDD явно есть чего улучшать. Вон, вчера сын принес с работы историю про смежников-эмбедщиков. Он сам не эбедщик вообще-то, но с их изделиями ему приходится работать, и плотно. Суть истории: смежники сделали для них железку, и она в целом работает стабильно, но тут доработки потребовались. А с этим оказалось сложно, потому что смежники начали чинить то, что не сломалось - добавили (чисто в прошивку в новую) какую-то не особо нужнуую фичу (вроде как, со слов - запись логов в флеш-память). После чего железка через полсуток работы стала виснуть. Казалось бы, нет ничего проще - вернтуься к стабильной версии и танцевать от нее - ан нет: исходники стабильной версии продолбаны. Потому что CVS/SVN/Git/Mercurial смежники ниасилили. А вы говорите - TDD!
То, что автор дал себе труд написать статью для начинающих - это хорошо, пусть даже статья - набор банальностей (допускаю, начинающим они будут внове). Плохо, что среди ваших рекомендаций затесались весьма сомнительные.. Потому статью к прочтению я не рекомендую даже начинающим. Однако как отдельный плюс статьи отмечу, что в ней нет ссылки на телеграм-канал автора. Все бы авторы так делали...
Некоторые сомнительные рекомендации:
Очевидно, вклад в чужой репозиторий требует прочтения чужого кода, что само по себе учит новому.
Есть такое новое, которому лучше не учиться. Пример - да прямо там рядом на картинке. После того, как в C# появились автоматические свойства (auto property) - уже больше 10 лет как ЕМНИП - совершенно незачем для реализации доступа к полю/свойству только для чтения приделывать ещё и теневую переменную. Да и до того незачем было городить две реализации: оптимизация путем замены свойства полем выгляит явно сомнительной и, скорее всего, преждевременной: метод получения свойства чтение поля почти наверняка будет встроен в код по месту. И, кстати, давать примеры кода лучше не картинкой а вставкой кода.
Рас ты хочешь внести изменения в чужой код, значит это… Рефакторинг! Отличный способ попрактиковаться в этом направлении. Приятное с полезным.
Видишь повторяющиеся строки кода? Вынеси в отдельный метод.
Если кто-нибудь начнет бездумно выносить повторяющиеся строки в отдельный метод, то добром это не кончится - эти повторяющиеся строки часто имеют шанс при дальнейшем развитии проекта меняться в разных местах по-разному - с неприятными последствиями для того метода, куда их вынесли (и да, слово "Рас" поправьте).
Вежливость, конструктивность помогут тебе.
Для вежливости мало использовать вежливые выражения (кстати, вы почему то этим правилом в статье пренебрегаете и обращаетесь на "ты" к совершенно незнакомым вам людям). Вежливость неплохо бы проявлять и делом - например, отформатировать запрос на изменение так, чтобы его было бы удобно читать. В частности - таки офрмить список изменений как список, а не валить всё в одну кучу текста, как у вас на картинке: приводя такой пример, вы учите начинающих плохому.
Вы точно не запутались в том, что вы хотите мне доказать? А то я вас прошу "указать где написано про вызов, содержащий только один запрос" в некоей фразе , а вы мне стремитесь доказать, что вообще " К вызову, содержащему только один запрос, эта фраза относиться не может". Ну, если так, то я даже обсуждать это ваше доказательство не буду - самого по себе признания моей правоты мне хватит.
Или вы что-то другое хотели написать?
PS То что вы хотели на самом деле сказать, вы уже уточнили, и против конкретно именно этого я, как уже написал выше, не возражаю. Я возражаю против однозначности вашей интерпретации чужой фразы. Но по этому поводу, ещё раз повторю, лучше переспросить автора фразы.
Нет, досточно указать где написано про "вызов, содержащий только один запрос" в комментарии, на который вы решили возразить- причем, явно написано, а не между строк. Потому что если ещё и учесть контекст в виде предыдущего комментария и цитаты из статьи в нем, то очевидно (мне, по крайней мере), что речь идет об установки одной транзакции на вызов, содержащий несколько запросов.
Но вообще я ещё раз предлагаю вам не заниматься тут "лингвистической экспертизой", а дождаться ответа на прямо поставленный вопрос автору высказывания.
Если в вызове больше одного запроса, даже если они только на чтение, то не установка Transactional может привести к неконсистентности данных при любом уровне изоляции. С этим согласны?
С этим я и не спорил, я с самого начала говорил про одну тразакцию на несколько запросов, и даже пример про это привел. И что с того?
Если не поставить Transactional на вызов, содержащий несколько запросов...
А если поставить (да ещё и бездумно, как говорил автор обсуждаемого комментария)? Прямо "над методом где выполняется несколько SQL запросов на чтение " (цитата из оригинального, до правки, варианта статьи)? Такой вариант прочтения вам в голову не приходил?
Так что предлагаю не заниматься тут герменевтикой, а подождать, что скажет автор обсуждаемого комментария.
Вы, похоже, не так поняли утверждение (не свосем однозначное, да) , однако сразу кинулись его опровергать. А я вот так понял, что утверждавший имел в виду вызов метода с несколькими запросами на чтение к БД внутри него - а в этом сценарии уровень изоляции имеет значение.
Ну, для вас такая безапелляционность - это норма. А вот я пока что, прежде чем спорить дальше, попробую подождать уточнения от @martin_wanderer
последующие запросы могут считать запись зафиксированную до завершения предыдущих запросов.
Уточните: что вы имели в виду? Если запись с изменением, зафиксированным после момента начала транзакции с уровнем изоляции снимка, но до первого обращения к записи в этой транзакции, то утверждение неверно. По крайней мере, в общем случае, в схеме хранения с поддержкой снимков: там у СУБД достаточно информации, чтобы найти старую версию записи и вернуть ее, даже если к этой записи транзакция ранее не обращалась.
И ЕМНИП оно реально неверно (было, в те давние времена) для конкретного Interbase 4. Тамошняя приблуда для интерактивной работы с БД - wisql.exe - при посылке первого же запроса открывала транзакцию (с изоляцией формально, если по тогдашним стандартам - REPEATBLE READ, но по жизни это был снимок, в Interbase была многоверсионная схема хранения), и сидела в ней, пока транзакцию явно не завершишь. В результате при отладке прогаммы на Delphi можно было внезапно не увидеть в wisql сделанное программой и зафиксированное изменение, потому что час назад в wisql был сделан и забыт запрос к совершенно другой таблице, а транзакция так и осталась висеть.
Кажется, вы решили тут поспорить за социализм с капитализмом. Если так - то это не со мной.
Потому что с советским социализмом, то есть - с идеей централизованного рационального управления общественным производством - все понятно: не выдерживает конкуренции в нынешних условиях, а потому - не жилец.
PS Лично для меня это - к счастью. Поскольку все те имманентные этой модели особенности, про которые, к примеру, писал фон Хайек в "Дороге к рабству" - они не сочетаются с моей главной личной ценностью - волей (это когда "чтобы у нас все было и чтобы нам за это ничего не было", не путать со "свободой", которая, как известно, "осознанная необходимость"). И лично я рад, что эти особенности - на которые я в достатке нагляделся в своей комсомольской молодости - не явлются неизбежными. Но ценности - это дело глубоко личное, я вот свои никому не навязываю.
Давайте все-таки смотреть не на уровне лозунгов, а на уровне производственных отношений: это продуктивнее.
Капитализм на этом уровне отличается от социализма советского образца наличием частной собственности на средства производства: в СССР средства производства считались официально общенародными (или часть - кооперативными) а реально ими распоряжалась в своих интересах номенклатура. И производство управлялось не через рыночный механизм, а централизовано. И на практике выяснилось, что это, централизованное, управление менее эффективно (впрочем, это ещё экономист фон Мизес примерно на заре Советской власти предсказывал). Но ещё раз подчеркиваю: жто всё абстракции, описывающе общество, в лучшем случае, только в основных чертах, а если начать углубляться в конкретику, то там можно найти всякое.
Впрочем, в мире существуют и гибридные системы организации общественного производства, которые одной из этих абстракций описываются плохо. Это там, где частная собственность на средства производства сохраняется, но возможности распоряжения ею сильно ограничиваются а конкретные способы - часто навязываются государством. Обычно это называют "госкапитализм". Такова, в целом (насколько я знаю), экономика современного Китая. Такова же была и экономическая система национал-социалистической Германии (впрочем, ее лидеры предпочитали называть свою систему социализмом, наверное, потому что тогда социализм в Европе был моден).
PS Кстати, фраза "социализм означает: общее благо выше личных интересов", если кто не в курсе - это из того, немецкого национального, социализма: это цитатат из перевода текста из хрестоматии для немецкой молодежи 1938 года. Первоисточник именно этой фразы мне неизвестен, но подозреваю. И, кстати, именно в том же тексте, но дальше, есть куда более известная фраза, на языке оригинала - "Jedem das Seine". Впрочем, в контексте текущей дискуссии это никакого значения не имеет.
Социализм - это абстракция. Как и капитализм. А реальное общество одной абстракцией не описывается. К тому же, социализм - это ещё и слово, которое часто понимают по-разному: для кого-то это - "первая фаза коммунистического общества", а для кого-то "социализм означает: общее благо выше личных интересов" (и далее по тексту, который в РФ публиковать нельзя).
Я не хочу спорить об абстракциях и тем более - о словах. Потому что считаю, что эти темы - не для Хабра: они плохо сочетаются с знаниями, профессиональным опытом и направлениями деятельности большинства участников здешнего сообщества ( смоими - тоже, да). Я всего лишь стараюсь сообщать факты, максимум - делать из них очевидные выводы. И по поводу СССР я всего лишь сообщил факт, что и как там называлось.
Не вижу в тексте вашего оппонента причинной связи между установкой счетчиков и появлением возможности регулирования температуры помещения. Этот текст никак не опровергает утверждения, что ваш оппонент считает, что это - вещи независимые: он пишет о том, что начисление оплаты по поквартирному счетчику дает возможность за счет регулировки получить тепло от соседей, за их счет, а не саму возможность регулировки.
PS Я там в предыдущем комментарии кое-что дополнил.
Глупость, это демагогия этого товарища, который пишет чушь, уверяя, что регулировка отопления возможна только с поквартирными счетчиками.
Не дадите ссылку, где именно он такое написал? А то я что-то такого у него нигде не видел.
А "меня убедили" относится чисто к тем рассчетам в одной из предыдущих статей автора, где он считал тепловые потоки в многоквартирном доме. Я в этих рассчетах ошибки не нашел.
PS Я гляжу, вы там с оппонентами усиленно так спорите за тарифы, будто они имеют прямое отношение к издержкам на производство тепла. А это не так: тарифы - регулируемые, устанавливаются бюрократами, и кто из естественных монополистов сумел лучше обосновать свои, типа, расходы перед бюрократией, тот и получает больше. Экономические соображения тут не сильно при чем.
Ресурс этих самых жестких рук (к котрым еще и должны прилагаться тоже руки, но чистые, с горячем сердцем и холодной головой) - он весьма ограничен. Его хватает не только лишь на всех.
А там где не хватает, там получается не рынок, а рыночек - тот самый, последствия того, как он порешал, вы тут, я гляжу, с @Doliosв ветке выше активно обсуждаете - и последствия внезапно оказываются далеки от теоретических.
А ещё бывают последствия, как в Усть-Куте в 2001 или в Климовске в этом году (а если брать и быв. СССР, то ещё и Алчевск-2006 вспоминается). Короче - катастрофические аварии. А децентрализованные системы таким катастрофическим отказам куда меньше подвержены.
Так что пусть государственные проекты будут как-нибудь сами по себе, а мы тут - сами по себе.
Сейчас наступила эра капиталистического индивидуализма и погони за личной выгодой, причём даже в ущерб общественной целесообразности.
Проблема с общественной целесообразностью - в том, что в достаточно большой системе невозможно рассчитать, какое именно общественное поведение является общественно целесообразным, а какое - нет (т.н. "калькуляционный аргумент"). В частности, опыт СССР наглядно показал в масштабе всего народного хозяйства в условиях, когда направление развития не очевидно (т.е. не в варианте "Всё для фронта, всё для победы") рассчитать действительно невозможно: рыночная экономика показала значительно лучшие результаты.
Этот вывод - он неочевидный (особенно если вместо всего народного хозяйства рассматривать системы меньшего масштаба), но практикой, той самой, советской, он подтвержен. Так что ресурсами и методами для эффективного рационального централизованного управления всей экономикой человечество на данный момент не располагает. Если перевести на язык марксизма - производительные силы (а технологии управления общественным производством - это, очевидно, часть производительных сил) для перехода к социализму и коммунизму сейчас развиты недостаточно. Так что лучшее, что коммунисты могут сделать для перехода к своему любимому коммунизму - это развивать эти самые технологии, информационные по своей природе. Чем, собственно, сообщество Хабра в большинстве своем и занимается, как бы кто тут к коммунизму ни относился.
Так вот, централизованное теплоснабжение с рыночными механизмами сочетается очень плохо: это - естественная монополия, рынком она не регулируется. Так что, возможно, локальные системы отопления, при всей их меньшей энергоэффективности - они все же оказываются для общества полезнее: ими управлять специально не надо, рынок с этим справится сам. А может - и не полезнее: тут смотреть конкретно надо, с кучей цифр и фактов на руках (которыми я не располагаю), а общие рассуждения тут уже бесполезны.
PS Но конкретно поквартирные счетчики тепловой энергии в многоквартирных домах с их реальным (а, подозреваю - и любым экономически обоснованным) уровнем межквартирной теплоизоляции - это таки глупость, вы меня в этом убедили.
PPS При всем при том, статье - плюс: в ней есть само ценное - рассказ про то, как что устроено в реальности.
В СССР, если официально, был "социализм как первая фаза коммунистического общества". Если говорить конкретно про Застой и Пятилетку Пышных Похорон (при Брежневе и его приемниках вплоть до Горби) то в СССР был "развитой социализм". Это был если, опять же, официально, "переходный этап от капитализма к коммунизму", а в реальности к нему добавлялось дополнительное описание: "когда за деньги уже ничего не купишь, а без денег ещё ничего не дают" (цитатат из тогдашнего анекдота). То есть управление экономикой было разрегулировано и разрегулировалось ещё дальше. Именно поэтому пришлось вернтуься к капитализму.
Авито буквально на днях опубликовало статистику: Цитата:
Рост числа вакансий не влияет на рост зарплат. Это показывает свежая статистика «Авито-Работа» по отрасли маркетплейсов. В сравнении с 2022 годом, в 2023 г. число вакансий для специалистов сегмента маркетплейсов выросло в 2,3 раза, а средние предлагаемые зарплаты увеличились лишь на 2%, до 47.841 руб. С учётом инфляции в 7,5% реальная средняя зарплата даже упала на 5% - и это при таком увеличении спроса на работников. «Топ самых востребованных сотрудников сферы маркетплейсов возглавили маркетологи. Спрос на них год к году вырос в 3,5 раза, а средние зарплатные предложения остались практически неизменными и составили 46.438 руб.».
Ув. Григорий, а вы уверены, что статистика по всяким там "менеджерам маркетплейсов" дает достаточные основания, чтобы судить о состоянии рынка труда разработчиков? Больно уж разные требования предъявляют эти профессии а потому больно уж различаются эти сегменты рынка труда.
Специалистам сегмента маркетплейсов не требуется какая-то особая и редко встречающаяся и трудно преобретаемая квалификация (или как сейчас модно говорить - хард-скиллы). А для разработчиков ограничение числа кандидатов из-за требований по квалификации являются ключевыми для описания положения на этом сегменте рынка труда: рынок перенасыщен малоквалифцированными кандидатами, желающими работать разработчиками, в то время как поиск кандидата в нужной мере квалифицированного, чтбы он был способен работать достаточно продуктивно, чтобы его имело смысл эксплуатировать, составляет проблему.
Английский язык. Документации на что угодно на русском языке и до 2.14 и тем более 2.22 было очень мало для чего-то сложнее do wr, сейчас информации все меньше и меньше
Алаверды. Если кто-то думает, что были хорошие времена с документацией на русском языке, то зря. Даже в СССР, где вся документация была на русском языке, польза от знания английского языка была ощутима. По крайней мере, лично я ощутил ее на своем опыте чтения документации по ЕС ЭВМ. После некоторых мучений я придумал способ, как ее читать и не сойти при этом с ума: надо было предложения из нее перевести на английский дословно, а потом попытаться понять, про что там на самом деле написано. Обычно получалось - благо наш физкультурный техникум в г.Долгопрудном был с английским уклоном, и английскому языку нас учили настоящим образом: вплоть до конвертации долгов по английскому в долг перед Родиной.
Когда новый код с soft delete на проде, старый уникальный индекс нужно удалить. Иначе он не даст добавить новые записи, аналогичные удаленным с помощью soft delete. C другой стороны, нельзя удалять старый уникальный индекс, пока работает старый код.
Нам пришла идея: вместе с новым partial индексом создать временный поисковый индекс — аналогичный старому, но без ограничения уникальности.
...
В этом случае в любой момент релиза поисковые запросы будут работать быстро, и мы не получим проблем со вставкой новых записей.
Вы не пробовали оценить вероятность появления в таблице по-настоящему дублирующих записей (с deleted_at is null)? А то ведь буде такая появится, то ваш замечательный частичный индекс просто не создастся.
PS Есть еще пара вопросов, чисто технических, но они не в тему IMHO. Потому что тема - она как уронить бой и выжить после этого.
Вы тут описали лабораторные условия, не имеющие никакого отношения к реальному коду в современном C#.
Я описал контрпример к вашему чрезмерно общему утверждению. А к действительности это тоже очень даже может поиметь отношение, если, к примеру, потребуется организовать пересчет значений ячеек в электронной таблице. Но не это главное.
Вообще, я гляжу, вы тут друг сдругом спорите, даже не опрделив, что означает понятие "асинхронный". А так спорить можно долго и бестолку. И я, если что, в такого рода дискуссии участвовать не немерен.
Лично я привык вообще думать не в этих новомодных терминах, а -в понятиях "задача", "поток выполнения(который по-анлийски - flow, а не thread), "многозадачность" - "кооперативная" и "вытесняющая" - "исполнитель" (обычно - "исполнительное устройство", но может быть и человек), "параллельность" работы разных исполнителей и прочим из старых книжек, по которым я учился: проблема неэффективности чисто поледовательного выполнения, если что, была осознана в индустрии еще лет шестьдесят назад, если не больше. Я знаю, как эти понятия определить для себя и, если надо - сформулировать для других, чтобы определиться, о чем речь.
По этим понятиям новомодная асинхронность - это старая добрая кооперативная (она же, для людей моего поколения - колхозная) многозадачность, основанная на переключении потока выполнения на исполнительном устройстве от задчи к задаче в заранее определенных в программе точках. И получила она распространение потому, что переключение выполнения в заранее неопределенных точках ("вытесняющая многозадачность") в современных архитектурах компьютеров обходится заметно дороже.
Асинхронная операция, например сетевой запрос, будет выполняться в любом случае.
Попробую таки уточнить в вышеуказанных терминах. Асинхронность для операции, как я понял, означает, что для нее есть альтернативный исполнитель, выполняющий ее независимо от основного (под которым подразумевается CPU). Если так, то ничто не мешает в наше время сделать асинхроной и чисто вычислительную операцию. У современных CPU есть несколько независимо работающих ядер, каждое из которых может поддерживать независимый поток выполнения, которому можно поручить выполнение другой задачи.
Более того, современный CPU в реальности состоит из некоторого количества более или менее специализированных исполнительных устройств, работающих более-менее параллельно, так что для более полной их загрузки может иметь смысл спланировать выполнение на них двух квазинезависимых потоков: Intel, к примеру, использует эту технологию, называя ее hyper-threading. А потому в ряде применений вполне может быть осмысленно разделить операции, даже упирающиеся в один CPU, но требующие, в основном, разных исполнительных устройств этого CPU, на две задачи для двух потоков, выполняющихся, пусть и на одном ядре, но в значительной степени параллельно. Например, если программа считает какой-нибудь условный матан и результаты выводит в какой-нибудь условный джейсон - то есть, для этого сравнивает и перемещает байтики, складывает-вычитает чисто целые числа и делает прочие простые операции. то такая программа вполне может почти что параллельно на одном и том же ядре CPU в одном потоке считать матан, а в другом - делать из него джейсон, тем самым более полно загружая все исполнительные устройства ядра.
Пока что как-то так. Если далее будут конструктивные замечания и вопросы в рамках согласованной системы понятий (свою предлагаю, но на ней не настаиваю) - готов обсуждать дальше. А заниматься герменевтикой (т.е. толкованием священных текстов) - увольте, это как-нибудь без меня.
По поводу сравнения со StringBuilder. Какие именно сценарии интересуют? В
В общем-то - любые манипуляции со строками. Но это так, чисто пожелания, чисто посмотреть, чтобы знать на будущее. В отличие от гражданина, страдающего тут по UTF-8, с практической стороны у меня сейчас никаких нужд пока нет.
А программисту напарник вовсе не нужен. Взаимодействие с другим программистом - это дополнительные сложности, всегда. А то, что результат получается медленнее - это не забота программиста. Программист в результате не заинтересован чисто объективно: ему деньги за процесс труда плятят, а не за результат. Реально, заинтересованные лица тут - владельцы бизнеса и их представители - менеджеры.
Как это: везде - работает, а при программировании микроконтроллеров - нет? Что это такая специфика именно для микроконтроллеров? В своей области я что-то такого не замечал, что без TDD никак. Вполне программировал совместно ещё в те времена, когда о TDD и слыхом не слыхали. Правда, не для микроконтроллеров, а для десктопов, на Delphi.
Неужели для микроконтроллеров нельзя найти способ организации разработки подешевле? Не знаю, как там у вас в микроконтроллерах, а я тут вот развликаюсь написанием чисто самодельной библиотеки (Middleware для ASP.NET Core) в соответствии с наилучшими практиками: могу себе позволить, потому что надо мной погонщик с кнутом не стоит. Так вот для этой библиотеки полное покрытие тестами (xUnit+Moq+VS 2022) - это примерно раза в два больше кода, чем в самой библиотеке. Причем, это - с максимальным выносом общего для тестов кода в общие классы и методы тестового проекта. Я понимаю, конечно, что код библиотеки - он не простой, там куча асинхронщины и параллельщины, которую как раз и проверять надо, а тестов - наоборот простой: там копипасты с мелкими правками много. Но даже если кода требуется не в три, а в два раза больше - это IMHO дорого, слишком.
А в реальной разработке для микроконтроллеров и без TDD явно есть чего улучшать. Вон, вчера сын принес с работы историю про смежников-эмбедщиков. Он сам не эбедщик вообще-то, но с их изделиями ему приходится работать, и плотно. Суть истории: смежники сделали для них железку, и она в целом работает стабильно, но тут доработки потребовались. А с этим оказалось сложно, потому что смежники начали чинить то, что не сломалось - добавили (чисто в прошивку в новую) какую-то не особо нужнуую фичу (вроде как, со слов - запись логов в флеш-память). После чего железка через полсуток работы стала виснуть. Казалось бы, нет ничего проще - вернтуься к стабильной версии и танцевать от нее - ан нет: исходники стабильной версии продолбаны. Потому что CVS/SVN/Git/Mercurial смежники ниасилили. А вы говорите - TDD!
То, что автор дал себе труд написать статью для начинающих - это хорошо, пусть даже статья - набор банальностей (допускаю, начинающим они будут внове). Плохо, что среди ваших рекомендаций затесались весьма сомнительные.. Потому статью к прочтению я не рекомендую даже начинающим. Однако как отдельный плюс статьи отмечу, что в ней нет ссылки на телеграм-канал автора. Все бы авторы так делали...
Некоторые сомнительные рекомендации:
Есть такое новое, которому лучше не учиться. Пример - да прямо там рядом на картинке. После того, как в C# появились автоматические свойства (auto property) - уже больше 10 лет как ЕМНИП - совершенно незачем для реализации доступа к полю/свойству только для чтения приделывать ещё и теневую переменную. Да и до того незачем было городить две реализации: оптимизация путем замены свойства полем выгляит явно сомнительной и, скорее всего, преждевременной: метод получения свойства чтение поля почти наверняка будет встроен в код по месту. И, кстати, давать примеры кода лучше не картинкой а вставкой кода.
Если кто-нибудь начнет бездумно выносить повторяющиеся строки в отдельный метод, то добром это не кончится - эти повторяющиеся строки часто имеют шанс при дальнейшем развитии проекта меняться в разных местах по-разному - с неприятными последствиями для того метода, куда их вынесли (и да, слово "Рас" поправьте).
Для вежливости мало использовать вежливые выражения (кстати, вы почему то этим правилом в статье пренебрегаете и обращаетесь на "ты" к совершенно незнакомым вам людям). Вежливость неплохо бы проявлять и делом - например, отформатировать запрос на изменение так, чтобы его было бы удобно читать. В частности - таки офрмить список изменений как список, а не валить всё в одну кучу текста, как у вас на картинке: приводя такой пример, вы учите начинающих плохому.
Вы точно не запутались в том, что вы хотите мне доказать? А то я вас прошу "указать где написано про вызов, содержащий только один запрос" в некоей фразе , а вы мне стремитесь доказать, что вообще " К вызову, содержащему только один запрос, эта фраза относиться не может". Ну, если так, то я даже обсуждать это ваше доказательство не буду - самого по себе признания моей правоты мне хватит.
Или вы что-то другое хотели написать?
PS То что вы хотели на самом деле сказать, вы уже уточнили, и против конкретно именно этого я, как уже написал выше, не возражаю. Я возражаю против однозначности вашей интерпретации чужой фразы. Но по этому поводу, ещё раз повторю, лучше переспросить автора фразы.
Нет, досточно указать где написано про "вызов, содержащий только один запрос" в комментарии, на который вы решили возразить- причем, явно написано, а не между строк. Потому что если ещё и учесть контекст в виде предыдущего комментария и цитаты из статьи в нем, то очевидно (мне, по крайней мере), что речь идет об установки одной транзакции на вызов, содержащий несколько запросов.
Но вообще я ещё раз предлагаю вам не заниматься тут "лингвистической экспертизой", а дождаться ответа на прямо поставленный вопрос автору высказывания.
С этим я и не спорил, я с самого начала говорил про одну тразакцию на несколько запросов, и даже пример про это привел. И что с того?
Я же написал. Читайте.
А если поставить (да ещё и бездумно, как говорил автор обсуждаемого комментария)? Прямо "над методом где выполняется несколько SQL запросов на чтение " (цитата из оригинального, до правки, варианта статьи)? Такой вариант прочтения вам в голову не приходил?
Так что предлагаю не заниматься тут герменевтикой, а подождать, что скажет автор обсуждаемого комментария.
Вы, похоже, не так поняли утверждение (не свосем однозначное, да) , однако сразу кинулись его опровергать. А я вот так понял, что утверждавший имел в виду вызов метода с несколькими запросами на чтение к БД внутри него - а в этом сценарии уровень изоляции имеет значение.
Ну, для вас такая безапелляционность - это норма. А вот я пока что, прежде чем спорить дальше, попробую подождать уточнения от @martin_wanderer
Уточните: что вы имели в виду? Если запись с изменением, зафиксированным после момента начала транзакции с уровнем изоляции снимка, но до первого обращения к записи в этой транзакции, то утверждение неверно. По крайней мере, в общем случае, в схеме хранения с поддержкой снимков: там у СУБД достаточно информации, чтобы найти старую версию записи и вернуть ее, даже если к этой записи транзакция ранее не обращалась.
И ЕМНИП оно реально неверно (было, в те давние времена) для конкретного Interbase 4. Тамошняя приблуда для интерактивной работы с БД - wisql.exe - при посылке первого же запроса открывала транзакцию (с изоляцией формально, если по тогдашним стандартам - REPEATBLE READ, но по жизни это был снимок, в Interbase была многоверсионная схема хранения), и сидела в ней, пока транзакцию явно не завершишь. В результате при отладке прогаммы на Delphi можно было внезапно не увидеть в wisql сделанное программой и зафиксированное изменение, потому что час назад в wisql был сделан и забыт запрос к совершенно другой таблице, а транзакция так и осталась висеть.
Кажется, вы решили тут поспорить за социализм с капитализмом. Если так - то это не со мной.
Потому что с советским социализмом, то есть - с идеей централизованного рационального управления общественным производством - все понятно: не выдерживает конкуренции в нынешних условиях, а потому - не жилец.
PS Лично для меня это - к счастью. Поскольку все те имманентные этой модели особенности, про которые, к примеру, писал фон Хайек в "Дороге к рабству" - они не сочетаются с моей главной личной ценностью - волей (это когда "чтобы у нас все было и чтобы нам за это ничего не было", не путать со "свободой", которая, как известно, "осознанная необходимость"). И лично я рад, что эти особенности - на которые я в достатке нагляделся в своей комсомольской молодости - не явлются неизбежными. Но ценности - это дело глубоко личное, я вот свои никому не навязываю.
Давайте все-таки смотреть не на уровне лозунгов, а на уровне производственных отношений: это продуктивнее.
Капитализм на этом уровне отличается от социализма советского образца наличием частной собственности на средства производства: в СССР средства производства считались официально общенародными (или часть - кооперативными) а реально ими распоряжалась в своих интересах номенклатура. И производство управлялось не через рыночный механизм, а централизовано. И на практике выяснилось, что это, централизованное, управление менее эффективно (впрочем, это ещё экономист фон Мизес примерно на заре Советской власти предсказывал). Но ещё раз подчеркиваю: жто всё абстракции, описывающе общество, в лучшем случае, только в основных чертах, а если начать углубляться в конкретику, то там можно найти всякое.
Впрочем, в мире существуют и гибридные системы организации общественного производства, которые одной из этих абстракций описываются плохо. Это там, где частная собственность на средства производства сохраняется, но возможности распоряжения ею сильно ограничиваются а конкретные способы - часто навязываются государством. Обычно это называют "госкапитализм". Такова, в целом (насколько я знаю), экономика современного Китая. Такова же была и экономическая система национал-социалистической Германии (впрочем, ее лидеры предпочитали называть свою систему социализмом, наверное, потому что тогда социализм в Европе был моден).
PS Кстати, фраза "социализм означает: общее благо выше личных интересов", если кто не в курсе - это из того, немецкого национального, социализма: это цитатат из перевода текста из хрестоматии для немецкой молодежи 1938 года. Первоисточник именно этой фразы мне неизвестен, но подозреваю. И, кстати, именно в том же тексте, но дальше, есть куда более известная фраза, на языке оригинала - "Jedem das Seine". Впрочем, в контексте текущей дискуссии это никакого значения не имеет.
Социализм - это абстракция. Как и капитализм. А реальное общество одной абстракцией не описывается. К тому же, социализм - это ещё и слово, которое часто понимают по-разному: для кого-то это - "первая фаза коммунистического общества", а для кого-то "социализм означает: общее благо выше личных интересов" (и далее по тексту, который в РФ публиковать нельзя).
Я не хочу спорить об абстракциях и тем более - о словах. Потому что считаю, что эти темы - не для Хабра: они плохо сочетаются с знаниями, профессиональным опытом и направлениями деятельности большинства участников здешнего сообщества ( смоими - тоже, да). Я всего лишь стараюсь сообщать факты, максимум - делать из них очевидные выводы. И по поводу СССР я всего лишь сообщил факт, что и как там называлось.
Не вижу в тексте вашего оппонента причинной связи между установкой счетчиков и появлением возможности регулирования температуры помещения. Этот текст никак не опровергает утверждения, что ваш оппонент считает, что это - вещи независимые: он пишет о том, что начисление оплаты по поквартирному счетчику дает возможность за счет регулировки получить тепло от соседей, за их счет, а не саму возможность регулировки.
PS Я там в предыдущем комментарии кое-что дополнил.
Не дадите ссылку, где именно он такое написал? А то я что-то такого у него нигде не видел.
А "меня убедили" относится чисто к тем рассчетам в одной из предыдущих статей автора, где он считал тепловые потоки в многоквартирном доме. Я в этих рассчетах ошибки не нашел.
PS Я гляжу, вы там с оппонентами усиленно так спорите за тарифы, будто они имеют прямое отношение к издержкам на производство тепла. А это не так: тарифы - регулируемые, устанавливаются бюрократами, и кто из естественных монополистов сумел лучше обосновать свои, типа, расходы перед бюрократией, тот и получает больше. Экономические соображения тут не сильно при чем.
Ресурс этих самых жестких рук (к котрым еще и должны прилагаться тоже руки, но чистые, с горячем сердцем и холодной головой) - он весьма ограничен. Его хватает не только лишь на всех.
А там где не хватает, там получается не рынок, а рыночек - тот самый, последствия того, как он порешал, вы тут, я гляжу, с @Doliosв ветке выше активно обсуждаете - и последствия внезапно оказываются далеки от теоретических.
А ещё бывают последствия, как в Усть-Куте в 2001 или в Климовске в этом году (а если брать и быв. СССР, то ещё и Алчевск-2006 вспоминается). Короче - катастрофические аварии. А децентрализованные системы таким катастрофическим отказам куда меньше подвержены.
Так что пусть государственные проекты будут как-нибудь сами по себе, а мы тут - сами по себе.
Проблема с общественной целесообразностью - в том, что в достаточно большой системе невозможно рассчитать, какое именно общественное поведение является общественно целесообразным, а какое - нет (т.н. "калькуляционный аргумент"). В частности, опыт СССР наглядно показал в масштабе всего народного хозяйства в условиях, когда направление развития не очевидно (т.е. не в варианте "Всё для фронта, всё для победы") рассчитать действительно невозможно: рыночная экономика показала значительно лучшие результаты.
Этот вывод - он неочевидный (особенно если вместо всего народного хозяйства рассматривать системы меньшего масштаба), но практикой, той самой, советской, он подтвержен. Так что ресурсами и методами для эффективного рационального централизованного управления всей экономикой человечество на данный момент не располагает. Если перевести на язык марксизма - производительные силы (а технологии управления общественным производством - это, очевидно, часть производительных сил) для перехода к социализму и коммунизму сейчас развиты недостаточно. Так что лучшее, что коммунисты могут сделать для перехода к своему любимому коммунизму - это развивать эти самые технологии, информационные по своей природе. Чем, собственно, сообщество Хабра в большинстве своем и занимается, как бы кто тут к коммунизму ни относился.
Так вот, централизованное теплоснабжение с рыночными механизмами сочетается очень плохо: это - естественная монополия, рынком она не регулируется. Так что, возможно, локальные системы отопления, при всей их меньшей энергоэффективности - они все же оказываются для общества полезнее: ими управлять специально не надо, рынок с этим справится сам. А может - и не полезнее: тут смотреть конкретно надо, с кучей цифр и фактов на руках (которыми я не располагаю), а общие рассуждения тут уже бесполезны.
PS Но конкретно поквартирные счетчики тепловой энергии в многоквартирных домах с их реальным (а, подозреваю - и любым экономически обоснованным) уровнем межквартирной теплоизоляции - это таки глупость, вы меня в этом убедили.
PPS При всем при том, статье - плюс: в ней есть само ценное - рассказ про то, как что устроено в реальности.
В СССР, если официально, был "социализм как первая фаза коммунистического общества". Если говорить конкретно про Застой и Пятилетку Пышных Похорон (при Брежневе и его приемниках вплоть до Горби) то в СССР был "развитой социализм". Это был если, опять же, официально, "переходный этап от капитализма к коммунизму", а в реальности к нему добавлялось дополнительное описание: "когда за деньги уже ничего не купишь, а без денег ещё ничего не дают" (цитатат из тогдашнего анекдота). То есть управление экономикой было разрегулировано и разрегулировалось ещё дальше. Именно поэтому пришлось вернтуься к капитализму.
Ув. Григорий, а вы уверены, что статистика по всяким там "менеджерам маркетплейсов" дает достаточные основания, чтобы судить о состоянии рынка труда разработчиков? Больно уж разные требования предъявляют эти профессии а потому больно уж различаются эти сегменты рынка труда.
Специалистам сегмента маркетплейсов не требуется какая-то особая и редко встречающаяся и трудно преобретаемая квалификация (или как сейчас модно говорить - хард-скиллы). А для разработчиков ограничение числа кандидатов из-за требований по квалификации являются ключевыми для описания положения на этом сегменте рынка труда: рынок перенасыщен малоквалифцированными кандидатами, желающими работать разработчиками, в то время как поиск кандидата в нужной мере квалифицированного, чтбы он был способен работать достаточно продуктивно, чтобы его имело смысл эксплуатировать, составляет проблему.
Алаверды. Если кто-то думает, что были хорошие времена с документацией на русском языке, то зря. Даже в СССР, где вся документация была на русском языке, польза от знания английского языка была ощутима. По крайней мере, лично я ощутил ее на своем опыте чтения документации по ЕС ЭВМ. После некоторых мучений я придумал способ, как ее читать и не сойти при этом с ума: надо было предложения из нее перевести на английский дословно, а потом попытаться понять, про что там на самом деле написано. Обычно получалось - благо наш физкультурный техникум в г.Долгопрудном был с английским уклоном, и английскому языку нас учили настоящим образом: вплоть до конвертации долгов по английскому в долг перед Родиной.
Вы не пробовали оценить вероятность появления в таблице по-настоящему дублирующих записей (с deleted_at is null)? А то ведь буде такая появится, то ваш замечательный частичный индекс просто не создастся.
PS Есть еще пара вопросов, чисто технических, но они не в тему IMHO. Потому что тема - она как уронить бой и выжить после этого.
Я описал контрпример к вашему чрезмерно общему утверждению. А к действительности это тоже очень даже может поиметь отношение, если, к примеру, потребуется организовать пересчет значений ячеек в электронной таблице. Но не это главное.
Вообще, я гляжу, вы тут друг сдругом спорите, даже не опрделив, что означает понятие "асинхронный". А так спорить можно долго и бестолку. И я, если что, в такого рода дискуссии участвовать не немерен.
Лично я привык вообще думать не в этих новомодных терминах, а -в понятиях "задача", "поток выполнения(который по-анлийски - flow, а не thread), "многозадачность" - "кооперативная" и "вытесняющая" - "исполнитель" (обычно - "исполнительное устройство", но может быть и человек), "параллельность" работы разных исполнителей и прочим из старых книжек, по которым я учился: проблема неэффективности чисто поледовательного выполнения, если что, была осознана в индустрии еще лет шестьдесят назад, если не больше. Я знаю, как эти понятия определить для себя и, если надо - сформулировать для других, чтобы определиться, о чем речь.
По этим понятиям новомодная асинхронность - это старая добрая кооперативная (она же, для людей моего поколения - колхозная) многозадачность, основанная на переключении потока выполнения на исполнительном устройстве от задчи к задаче в заранее определенных в программе точках. И получила она распространение потому, что переключение выполнения в заранее неопределенных точках ("вытесняющая многозадачность") в современных архитектурах компьютеров обходится заметно дороже.
Попробую таки уточнить в вышеуказанных терминах. Асинхронность для операции, как я понял, означает, что для нее есть альтернативный исполнитель, выполняющий ее независимо от основного (под которым подразумевается CPU). Если так, то ничто не мешает в наше время сделать асинхроной и чисто вычислительную операцию. У современных CPU есть несколько независимо работающих ядер, каждое из которых может поддерживать независимый поток выполнения, которому можно поручить выполнение другой задачи.
Более того, современный CPU в реальности состоит из некоторого количества более или менее специализированных исполнительных устройств, работающих более-менее параллельно, так что для более полной их загрузки может иметь смысл спланировать выполнение на них двух квазинезависимых потоков: Intel, к примеру, использует эту технологию, называя ее hyper-threading. А потому в ряде применений вполне может быть осмысленно разделить операции, даже упирающиеся в один CPU, но требующие, в основном, разных исполнительных устройств этого CPU, на две задачи для двух потоков, выполняющихся, пусть и на одном ядре, но в значительной степени параллельно. Например, если программа считает какой-нибудь условный матан и результаты выводит в какой-нибудь условный джейсон - то есть, для этого сравнивает и перемещает байтики, складывает-вычитает чисто целые числа и делает прочие простые операции. то такая программа вполне может почти что параллельно на одном и том же ядре CPU в одном потоке считать матан, а в другом - делать из него джейсон, тем самым более полно загружая все исполнительные устройства ядра.
Пока что как-то так. Если далее будут конструктивные замечания и вопросы в рамках согласованной системы понятий (свою предлагаю, но на ней не настаиваю) - готов обсуждать дальше. А заниматься герменевтикой (т.е. толкованием священных текстов) - увольте, это как-нибудь без меня.
В общем-то - любые манипуляции со строками. Но это так, чисто пожелания, чисто посмотреть, чтобы знать на будущее. В отличие от гражданина, страдающего тут по UTF-8, с практической стороны у меня сейчас никаких нужд пока нет.