К сожалению, вы продолжаете вести себя также неадекватно, как и начали, чем лишь подтверждаете свою близость к тому мему, на который так обиделись.
Если вам не сложно, внимательно перечитайте ветку обсуждения, которая началась с того, что вы ответили на вопрос, заданный не вам, упомянули ЗОЖ, который не имеет никакого отношения к теме поста и конкретного обсуждения, а потом начали употреблять слова «алкоголик» и «быдло»…
Может быть вы и не больны «зож головного мозга», но тогда не стоит проявлять соответствующие симптомы :)
За соответствием содержимого надписям на упаковке следит роспортребнадзор и иже с ним. А если уж не верить написанному, то где гарантия, что в дорогой колбасе «из мяса» состав указан верно?
Неправильная у вас цитата…
Не было такого диалога, вот в чём фокус.
Со стороны присутствующих получилось так, что одни люди обсуждали про пиво, но тут нарисовались вы со своим ЗОЖ. Вашего мнения не спросили, вы сами с ним пришли, да ещё и влезли в чужой разговор.
Это само по себе не очень, так вы ещё и обиделись, когда вас попросили не тыкать своим ЗОЖ, стали обзываться…
За то и пострадали.
Посыл статьи хороший, но примеры неудачные.
Основная проблема — смешаны в кучу разные значения слова «качество». В тексте есть как минимум три значения:
— Качество производства
— Качество продукта
— Качественные характеристики продукта
Когда на колбасе пишут, что она качественная — это про качество производства (т.е. в неё попадает именно то, что написано на упаковке и даже примерно в тех же количествах).
Когда на этикетке указан ГОСТ или ТУ — это позволяет оценить качество продукта с точки зрения соответствия нормам.
А когда вы говорите, что хотите колбасу из мяса, или чтобы в ней не было сои — вы предъявляете требования к качественным характеристикам.
И механизмы обратной связи у всех видов качества разный.
Качество производства — это экономика конкретного процесса.
Качество продукта — регулируется законами.
Качественные характеристики — это маркетинг.
Покупателю в первую очередь важны характеристики, по которым он выбирает товар. Соответствие госту — плюшка, завлекающая купить чуть более дорогой товар. Но тот, кто хочет купить колбасу из мяса не будет покупать продукт переработки отходов производства той самой колбасы.
Магазину важны те самые госты и ту и даже качество производства, ибо это влияет на стабильность продаж, но важно только как некий маркер (ну может ещё влияет на договорные отношения с поставщиками). А конкретные характеристики подбираются под покупателя, тут уж продавец порой сам не будет употреблять то, что продаёт.
Производителю сложнее всего. Ему приходится как-то учитывать всё, и на всех видах качества ставить рамки, т.к. ширина ассортимента и эффективность контроля качества увеличивает себестоимость.
Так что, как это не грустно, часто качество плохое не потому, что не хотят, а потому, что не вписывается в бюджет.
Примечание: лично я за качественный продукт. И сам такой делать стараюсь, и рублём (по мере возможности) за оный голосую.
И ни коей мере не предлагаю забивать на проблемы качества, но, имхо, без понимания причин и возможных следствий — ничего хорошего скорее всего не получится.
инстанцируемый классс Console, да еще который бы работал на любом потоке
— не вижу никакой проблемы с консолью, скорее наоборот, не могу придумать, зафига мне инстанцируемый класс? Не, если мне захочется чего-то особого повытворять со стандартными потоками ввода/вывода, я знаю где их взять и что с ними можно сделать. Но при этом нахожу статический Console удобнее любой альтернативы в 99% случаев…
Чтобы ответить на вопрос «где рамки» надо знать инфраструктуру обработки запроса в конкретной системе/фреймворке.
Конкретно .Net снимает с меня эту головную боль, предоставляя удобный и доступный инструмент.
И не надо «много запросов в рамках одного потока» — это тот головняк, который лучше обходить стороной. Лучше, когда наоборот, много потоков на один запрос, и при этом никаких мучений — оно само работает.
Лично я не разу не видел разумного вопроса «а как мне сделать несколько этого Current». У вас есть такой пример?
А вы в юнит-тестах используете транзакции и подключение к БД? Каким боком эти две темы соприкасаются? У меня ни разу не было проблем в юнит-тестах с транзакциями :), несмотря на то, что приходилось писать тестовый провайдер базы в котором юнит-тест задавал результат транзакции…
Вам никто не мешает реализовать свой собственный механизм управления транзакциями, но вот код провайдеров доступа к БД, или прочим транзакционным штукам, никак не должны зависеть от вашей фантазии о том, как оно будет лучше.
Механизм транзакций в .Net — это внутренний стандарт, которому следуют все те, кто пишет системные библиотеки для других. И все потребители этих библиотек ожидают стандартного поведения, безо всяких преферансов и куртизанок :)
И ещё раз — Current тут не статическая переменная, а аксессор к текущему контексту транзакции.
И это стандарт, и не только для .Net.
Например, для бэкенда, HttpContext.Current даёт доступ к веб-запросу, в рамках которого исполняется код. Аналоги есть в других фреймворках, и почти везде это будет та или иная глобальная точка доступа…
Вот по сути там всё сильно сложнее… Можете сами заглянуть в исходники…
А таки да, как изволите получать доступ к контексту исполнения? Наверно, в JavaScript-е не смущает везде в браузере доступная переменная window.document?
Или та же консоль? Откуда всё это брать, как и ещё 100500 объектов, описывающих контекст исполнения?
А я вот не понял, при чём тут C#?, и уж тем более «интересный код»?
Ни ООП, ни мощи .Net…
Даже единственное Linq-выражение записано в SQL-стиле, хотя, что мешало написать: var cross = Enumerable.Range(0, field.GetLength(0)).Count(j => field[j, i] == 1);
Офисный планктон (он же «офисное быдло», «канцелярская крыса»,«козявка приказная» и т. п.) — работники умственного труда с пониженной творческой составляющей, проводящие жизнь в офисах и прочих управлениях, но не относимые к инженерам: низшие менеджеры, бухгалтеры, секретутки, и т. д. Являют собой передаточные механизмы, винтики и смазку в механизмах управления, учета, планирования, финансов. Быстрорастущий пролетариат постиндустриального мира.
Если вам не сложно, внимательно перечитайте ветку обсуждения, которая началась с того, что вы ответили на вопрос, заданный не вам, упомянули ЗОЖ, который не имеет никакого отношения к теме поста и конкретного обсуждения, а потом начали употреблять слова «алкоголик» и «быдло»…
Может быть вы и не больны «зож головного мозга», но тогда не стоит проявлять соответствующие симптомы :)
Не было такого диалога, вот в чём фокус.
Со стороны присутствующих получилось так, что одни люди обсуждали про пиво, но тут нарисовались вы со своим ЗОЖ. Вашего мнения не спросили, вы сами с ним пришли, да ещё и влезли в чужой разговор.
Это само по себе не очень, так вы ещё и обиделись, когда вас попросили не тыкать своим ЗОЖ, стали обзываться…
За то и пострадали.
Основная проблема — смешаны в кучу разные значения слова «качество». В тексте есть как минимум три значения:
— Качество производства
— Качество продукта
— Качественные характеристики продукта
Когда на колбасе пишут, что она качественная — это про качество производства (т.е. в неё попадает именно то, что написано на упаковке и даже примерно в тех же количествах).
Когда на этикетке указан ГОСТ или ТУ — это позволяет оценить качество продукта с точки зрения соответствия нормам.
А когда вы говорите, что хотите колбасу из мяса, или чтобы в ней не было сои — вы предъявляете требования к качественным характеристикам.
И механизмы обратной связи у всех видов качества разный.
Качество производства — это экономика конкретного процесса.
Качество продукта — регулируется законами.
Качественные характеристики — это маркетинг.
Покупателю в первую очередь важны характеристики, по которым он выбирает товар. Соответствие госту — плюшка, завлекающая купить чуть более дорогой товар. Но тот, кто хочет купить колбасу из мяса не будет покупать продукт переработки отходов производства той самой колбасы.
Магазину важны те самые госты и ту и даже качество производства, ибо это влияет на стабильность продаж, но важно только как некий маркер (ну может ещё влияет на договорные отношения с поставщиками). А конкретные характеристики подбираются под покупателя, тут уж продавец порой сам не будет употреблять то, что продаёт.
Производителю сложнее всего. Ему приходится как-то учитывать всё, и на всех видах качества ставить рамки, т.к. ширина ассортимента и эффективность контроля качества увеличивает себестоимость.
Так что, как это не грустно, часто качество плохое не потому, что не хотят, а потому, что не вписывается в бюджет.
Примечание: лично я за качественный продукт. И сам такой делать стараюсь, и рублём (по мере возможности) за оный голосую.
И ни коей мере не предлагаю забивать на проблемы качества, но, имхо, без понимания причин и возможных следствий — ничего хорошего скорее всего не получится.
— не вижу связи с вашим «как мне сделать несколько этого Current»
Сами приплели тут десктоп, а теперь как бы и не при делах? :)
— не вижу никакой проблемы с консолью, скорее наоборот, не могу придумать, зафига мне инстанцируемый класс? Не, если мне захочется чего-то особого повытворять со стандартными потоками ввода/вывода, я знаю где их взять и что с ними можно сделать. Но при этом нахожу статический Console удобнее любой альтернативы в 99% случаев…
Конкретно .Net снимает с меня эту головную боль, предоставляя удобный и доступный инструмент.
И не надо «много запросов в рамках одного потока» — это тот головняк, который лучше обходить стороной. Лучше, когда наоборот, много потоков на один запрос, и при этом никаких мучений — оно само работает.
Лично я не разу не видел разумного вопроса «а как мне сделать несколько этого Current». У вас есть такой пример?
И да, на другие вопросы будут ответы?
Механизм транзакций в .Net — это внутренний стандарт, которому следуют все те, кто пишет системные библиотеки для других. И все потребители этих библиотек ожидают стандартного поведения, безо всяких преферансов и куртизанок :)
И ещё раз — Current тут не статическая переменная, а аксессор к текущему контексту транзакции.
И это стандарт, и не только для .Net.
Например, для бэкенда, HttpContext.Current даёт доступ к веб-запросу, в рамках которого исполняется код. Аналоги есть в других фреймворках, и почти везде это будет та или иная глобальная точка доступа…
А таки да, как изволите получать доступ к контексту исполнения? Наверно, в JavaScript-е не смущает везде в браузере доступная переменная window.document?
Или та же консоль? Откуда всё это брать, как и ещё 100500 объектов, описывающих контекст исполнения?
Ни ООП, ни мощи .Net…
Даже единственное Linq-выражение записано в SQL-стиле, хотя, что мешало написать:
var cross = Enumerable.Range(0, field.GetLength(0)).Count(j => field[j, i] == 1);А планктон — это уже другое.