А в Аимп можно сменить ресемплер? А вообще, сама возможность построить эту цепочку и определила для меня выбор плеера. Т.к. смысл от плеера если в нем ни ресемплинг не изменить, ни сторонний эквалайзер не прикрутить.
Мне, например, foobar2k нужен чтобы организовать тракт типа «ресэмплер (SoX/SRC) -> эквалайзер (Electri-Q) -> лимитер». Я ни разу не специалист по звуку и все такое, но когда я это все лет 10 назад настраивал в первый раз разница ИМХО была слышна практически на любой звуковой карте, причем в случае с SoX улучшение было заметнее всего на lossy низкой частоты. Суть в том что отправляя на звуковую карту любую частоту отличную от «опорной» ее ЦАП последний организует ресемплинг, который обычно заметно хуже тех же SoX/SRC. Львиная доля звуковых карт работает в 48КГц, так что звук ресемплится почти всегда. Если же на звуковую карту сразу посылать ее родные 24бита/48КГц ресемплинга на железе не происходит. Насчет декодера: когда я пересел на него в 2006 году fb2k имел встроенный декодер который работал лучше чем встроенный в WinAMP, но в последний всегда можно было вкрутить плагин от Фраунгофера.
Конечно, поэтому после смены турбины на более мощную приходится менять помпу, менять сами инжекторы, перешивать карту и т.д. Просто у автора в статье об этом вообще ни слова, хотя с его приростом давления может ничего и не понадобится.
22КВт в течение нескольких секунд или 22КВт постоянно — разные вещи. Преодолеть турбо-яму недолго, а дальше ток сбрасывается почти до нуля, только для компенсации веса ротора, до следующего переключения скоростей или остановки. Там на самом деле очень сложная тема с наддувом, т.к. топливные форсунки должны учитывать его давление постоянно, иначе топливо просто не пойдет в камеру сгорания. Ну и опять же мы говорим о большой мощности.
Рассчитывал пару похожих штуковин недавно. Турбояму за счет такой конструкции можно устранить раскручивая уже существующую турбину, как самостоятельное решение — ни на что не годится. Да и готовую турбину раскручивать — даже при поднятии напряжения до 36В сечение проводов конское получается, не говоря уже о требованиях к генератору. При расчетах получалось что движок должен был выдавать 22КВт вроде, что вылилось в 380В мотор от станка с отдельным водяным охлаждением, все остальные решения были слишком громоздкими. На той же Бентайге отдельная проводка 48В для аналогичного решения. По цене рабочее решение получается от $5000 до $17000 без установки. Вобщем для тюнеров пойдет, для обычных автовладельцев смысла нет особого.
Я с точки зрения математики знаю как теория групп помогла «нарушить» электрослабую симметрию. А вот непосредственно физику процессов наивно объяснить не смогу.
Я не физик, могу ошибаться, но нет, не может просто взять и появиться, и очень долго объяснять почему. У каждого поля есть характеристики, которые обсуловлены в свою очередь характеристиками его «переносчиков» и наоборот. Характеристики частицы зависят от спина, энергии и т.д. Соответственно, например, у поля может быть еще один гипотетический переносчик, но он будет распадаться раньше чем успеет что-либо сделать, пробег будет меньше эффективного расстояния поля. Это очень грубое приближение, т.к. для известных полей известны их переносчики и других быть не может. Это очень сложная и интересная область физики, но любые объяснения отнимают тонну времени. Начните с квантовой хромодинамики, может вам понравится.
Вполне очевидно, если знать теорию. Последним «предсказанным» бозоном был бозон Хиггса. Если кратко: новый бозон стандартной моделью не предусмотрен. А для данного кандидата уже даже некоторые характеристики поля известны.
Это не будет работать как мне кажется.На уровне классов и методов даже если взять ТОЛЬКО C# у нас и MSIL, и CER, DI, unsafe и unchecked опционально, горы атрибутов (в том же ASP.NET). Как вы будете например thread-safe конечный автомат для хранения состояния «генерировать». С учетом например что родительский класс CriticalFinalizerObject и имеет некоторые контракты с unmanaged миром, ядро работатет в dispatcher потоке, а задачи на смену состояния приходят как делегаты (и надо еще gate организовать т.к. какие-то команды могут оказаться невалидны к моменту когда диспатчер до них дойдет). У меня например такой год генерируют Razor и T4 на основании шаблонов, интерфейсов компонентов и кучи другого барахла которое я вручную писал. Я если честно всегда был за то чтобы глубоко изучить и действительно научиться пользоваться теми инструментами которые уже существуют, чем городить свой переусложненный огород.
Результатом DI является система (приложение), сконфигуренная под определённый контекст выполнения с конкретным набором зависимостей.
Я вот с кучей сторонних библиотек работаю имея исходники и если честно такое ощущение что на тестирование многие просто забивают. Причем даже если есть свои юнит тесты, они лишь для coverage-попугаев. Наши стресс тесты вышибают кучу софта даже оттестированного в совершенно невероятных местах. При этом крупные проекты, вроде PTVS хорошо оттестированы и детскими их не назовешь, однако DI в них нет. Иногда т.к. обошлись без него, иногда зависимости тащить не хотят.
Кода пишется руками много больше, чем генеририруется.
У кого как. Из шаблонных моделей очень много кода генерируется для передачи данных, доступа к базам данных и т.д. Но это в крупных и очень крупных проектах. Причем для генерации используется все подряд: от UML до шаблонов T4, смотря что удобнее. И пользовательского кода иногда гораздо меньше чем сгенерированного, на порядки. А во вторых, я не могу понять почему вы называете но почему DI «инжектированием». И это не парадокс, как кажется на первый взгляд. DI это скорее о подмене или предоставлении альтернатив, о выборе подходящего инструмента для ситуации. А АОП это как раз об унифицированном расширении, подчастую «post-mortem».
Я различаю паттерны исключительно по типу задачи которую они решают. И тут АОП позволяет ковровой бомбардировкой расширить похожую логику во множестве методов, малой кровью обеспечить синхронизацию и т.д. Причем достигается это по большей части перекомпиляцией, так что это скорее хак и надстройка. DI же это парадигма для развязывания контракта сервиса и его имплементации. Для юнит тестирования, запуска плагинов, развязки версий пакетов и т.д., но все в рамках стандарта языка. Как то так, но это мое субъективное мнение, я вообще не увлекаюсь теорией: что текущую задачу позволяет решить эффективно, то в бой и идет.
Ну как-то я поскромничал, да. У нас большая часть кода: ехал Windsor через Windsor… Но многим разработчикам это ни к чему, особенно если тестирование игнорировать.
Я сначала хотел было написать развернутый ответ, но потом все стер. Потому что в процессе написания понял одну совершено ясную для себя вещь: я бы застрелился на таком «языке» писать. И не кладите, пожалуйста, в одну корзину аспекты и DI. Они решают совершенно разные задачи. И то что для реализации DI приходится использовать dynamic proxies это наследство внутренней реализации C# и других языков. Когда вы действительно встретите проблемы которые для решения требуют использования DI или АОП вы сразу это поймете. А использование этих архитектур в «повседневных задачах» это программирование ради программирования — overengineering чистой воды.
Нет, там уже четвертая по счету стоит. Последний раз я два года назад сменил GTS 250 на GTX 580. Все остальное без изменений, только жестких дисков прибавилось, хотя система на том же самом живет что и при покупке. Но в январе буду апгрейд делать: Visual Studio стала невыносимо тормозить из-за огромных проектов. Если бы не это — оставил бы все как есть.
www.youtube.com/watch?v=mIBg-w6TNLE&feature=youtu.be&t=105
Вы телегу впереди лошади поставили.
У кого как. Из шаблонных моделей очень много кода генерируется для передачи данных, доступа к базам данных и т.д. Но это в крупных и очень крупных проектах. Причем для генерации используется все подряд: от UML до шаблонов T4, смотря что удобнее. И пользовательского кода иногда гораздо меньше чем сгенерированного, на порядки. А во вторых, я не могу понять почему вы называете но почему DI «инжектированием». И это не парадокс, как кажется на первый взгляд. DI это скорее о подмене или предоставлении альтернатив, о выборе подходящего инструмента для ситуации. А АОП это как раз об унифицированном расширении, подчастую «post-mortem».
Краснорубашечники (Джон Скальци)
Слуги правосудия (Энн Леки)
The Fifth Season (Нора Джемисин)
Заводная (Паоло Бачигалупи)
Ложная слепота (Питер Уоттс)
Лавина (Нил Стивенсон)
Никогда не отпускай меня (Кадзуо Исигуро)
Нейромант (Уильям Гибсон)
Задача трех тел (Лю Цысинь)
Бонус трек:
В финале Джон умрёт (Дэвид Вонг)
Ready player one (Эрнест Клайн)
Глубина в небе (Виндж Вернор)