В своё время Hitachi, когда они принадлежали IBM, с пафосом выпустила серию быстрых дисков с маркировкой DTLA, гигабайт на 40, если мне не изменяет память. Примерно с вероятностью 50/50 они безвозвратно и без возможности восстановления умирали в течение недели-двух после покупки из-за каких-то косяков с конструкцией. Это, в общем-то, довольно быстро пофиксили и поздние варианты DTLA были очень даже ок (у меня самого 4 штуки в RAID'е прожили много лет), но история была очень громкая.
А это уже зависит от конкретного бизнеса. Решение задач клиентов, удовлетворение амбиций собственника бизнеса, благотворительность, решение просто интересных задач, создание какой-нибудь ценности, etc — anything. Прибыль является следствием решения этих задач, но не является их первопричиной. Более того, она даже не обязательна, так как многие предприятия работают как планово убыточные.
Основная цель любого бизнеса — получение прибыли, какие бы высокопарные ценности ни провозглашались в миссии.
Прекратите уже тиражировать этот бред. В общем случае это НЕ так, о чём написано даже в классических учебниках по экономике. Это если мы конечно говорим о нормальном бизнесе, а не о компаниях, которые зарабатывают путём сбора «налога на плоха».
Цитата:
Объединяет как высокопроизводительные анализаторы спектра реального времени, так и бюджетные модели с диапазоном частот до 50 ГГц (до 325 ГГц и выше при использовании внешних смесителей) и полосой анализа до 160 МГц
А в чём проблема? Такие анализаторы есть. Стоят чертовски дорого, но есть и широко применяются. Посмотрите продукцию Agilent, Rohde&Schwarz, Wavetek, Tektronix, Iwatsu и иже с ними. Вот вам, например, аж портативный анализатор на 20 ГГц:
Да, дерьмо — штука заразная. Некоторые как приходят в место, где его едят половниками, их прям так и тянет попробовать. Миллионы мух же не могут ошибаться, это же вкуснятина!
Я не знаю, что это за чувак такой. А за DI я знаю несколько очень простых вещей, неоднократно проверенных на практике в крупных проектах:
1) Всё, что может быть проверено в compile time, должно быть проверено в compile time. DI фактически выносит огромное количество таковых проверок, особенно интеграционных, которые могут быть прозрачно сделаны компилятором, на этап тестов или, того хуже, runtime.
2) Код должен быть однозначен и прозрачен. Это вопрос стоимости его поддержки и качества самого кода в целом. То есть, посмотрев на код, программист должен сходу видеть, как он работает и зачем он сделан. DI прямо этому противоречит, потому что смотря на код с DI сразу возникают вопросы относительно объектов и свойств, которые возникают ниоткуда, создаются непонятно кем, где и когда и непонятно как уничтожающиеся. И это не вопрос понимания DI. Это вопрос того, что взглянув на код с DI вы не имеете возможности его однозначного понимания того, как он работает.
3) Вопрос повторного использования кода и удобства написания тестов (mocks etc) — это вопрос архитектуры и структуры кода, а не наличия или отсутствия DI.
4) DI — это привнесение в код огромного медленного титаника, который не даёт никаких выраженных бенефитов в серьёзном продакшене, кроме кучи геморроя с диагностикой ошибок из разряда «какого чёрта у меня это свойство не проинициализировалось».
Да как бы DI — это в принципе для мазохистов. То есть это не просто способ выстрелить себе в ногу, это способ стрелять себе в ногу три раза в день короткими очередями в автоматическом режиме %)
Мы из bash первое время дергали маскирующиеся под unix-команды вызовы API с java и под нагрузкой машина просто начинала сходить с ума, падало ядро linux с ожиданиями блокировок или CPU уходило под 100%.
Ну всё абсолютно логично, потому что у Java большие издержки за запуск VM. Вы привели как раз пример непонимания того, как надо готовить кошек Java :)
Я 15 лет пишу на C высокоэффективные приложения, и около 10 — на Java. Java может быть очень быстрой, медленнее C, но всё равно очень быстрой. С Java проблемы возникают не из-за технологии, а из-за непонимания разработчиками того, что они делают и во что это выльется в реальности.
Тупо перемножать между собой факторы, а не складывать их. Тогда, при нормальном значении фактора в 1, провал любого из факторов будет приводить к резкому падению всего индекса.
Для того, чтобы это хоть как-то работало, надо как минимум заменить аддитивную систему расчёта индекса мультипликативной. Чтобы провал по любому из факторов приводил к резкому провалу общего индекса. Иначе будут ситуации, когда продавец, пользуясь низким весом составляющей недовольства клиентов будет на неё забивать и брать массой. Какое-то время это будет работать, но потом вы получите толпы недовольных клиентов, которым что-то впарили, и исправлять это придётся долго и муторно.
Опорное напряжение для интегральных ЦАП получается не с резисторов, а с прецизионных подповерхностных зенеровских диодов и их разновидностей. LM329, LTZ1000, etc. Стоят некоторые, кстати, совершенно конских денег, вплоть до $50 за 1 штуку при крупнооптовых партиях.
Прекратите уже тиражировать этот бред. В общем случае это НЕ так, о чём написано даже в классических учебниках по экономике. Это если мы конечно говорим о нормальном бизнесе, а не о компаниях, которые зарабатывают путём сбора «налога на плоха».
www.keysight.com/en/pc-1707666/x-series-signal-analyzers?nid=-33932.0&cc=RU&lc=rus
Цитата:
Объединяет как высокопроизводительные анализаторы спектра реального времени, так и бюджетные модели с диапазоном частот до 50 ГГц (до 325 ГГц и выше при использовании внешних смесителей) и полосой анализа до 160 МГц
А в чём проблема? Такие анализаторы есть. Стоят чертовски дорого, но есть и широко применяются. Посмотрите продукцию Agilent, Rohde&Schwarz, Wavetek, Tektronix, Iwatsu и иже с ними. Вот вам, например, аж портативный анализатор на 20 ГГц:
www.rohde-schwarz.com/en/product/fsh-productstartpage_63493-8180.html
На 100-300ГГц найти анализаторы вам поможет гугл :)
1) Всё, что может быть проверено в compile time, должно быть проверено в compile time. DI фактически выносит огромное количество таковых проверок, особенно интеграционных, которые могут быть прозрачно сделаны компилятором, на этап тестов или, того хуже, runtime.
2) Код должен быть однозначен и прозрачен. Это вопрос стоимости его поддержки и качества самого кода в целом. То есть, посмотрев на код, программист должен сходу видеть, как он работает и зачем он сделан. DI прямо этому противоречит, потому что смотря на код с DI сразу возникают вопросы относительно объектов и свойств, которые возникают ниоткуда, создаются непонятно кем, где и когда и непонятно как уничтожающиеся. И это не вопрос понимания DI. Это вопрос того, что взглянув на код с DI вы не имеете возможности его однозначного понимания того, как он работает.
3) Вопрос повторного использования кода и удобства написания тестов (mocks etc) — это вопрос архитектуры и структуры кода, а не наличия или отсутствия DI.
4) DI — это привнесение в код огромного медленного титаника, который не даёт никаких выраженных бенефитов в серьёзном продакшене, кроме кучи геморроя с диагностикой ошибок из разряда «какого чёрта у меня это свойство не проинициализировалось».
Ну всё абсолютно логично, потому что у Java большие издержки за запуск VM. Вы привели как раз пример непонимания того, как надо готовить
кошекJava :)Это как измерять максимальную скорость, доступную автомобилям, при помощи самосвала КРАЗ.