в Netty воркеры так и берутся из пула, из того, что передается в ChannelFactory. Документация вроде рекомендует cores*2, хотя конечно, это дело разработчика, сколько дать воркеров.
да, длинные операции нельзя в асинхронных обработчиках делать. Впрочем, в приведенном случае это компенсируется Executors.newCachedThreadPool(), так что будет работать, но иногда как синхронный поток-на-хэндлер сервер, а это, видимо не то, что вам хотелось. Для подобных вещей в Netty есть несколько механизмов, например ExecutionHandler. Можно еще и чанковый ридер прикрутить, но это несколько сложнее.
1. Если на на каждый выход (микрофон и скапйп) поставить плагин Pan, то можно развести по стерео-каналам ведущего и скайповых участников. Понятно, не для того, чтоб звучало в разных ушах, но для упрощения пост-обработки.
2. Иногда то, что слышишь сам, это не то, что nicesast посылает. Тут помогает поставить Vu Meters или Menu Bar Meters и смотреть уровни глазами.
3. Если есть возможность записи бэкапа, то очень стоит его иметь. Т.е. просто включить в nicecast звук и записывать с выхода мака на внешнее усторйство.
не богохульствуй :) я сам придумал, хотя придумка на поверхности и при внимательном поиске на форуме дропбокса можно найти этот метод, как и пол дюжины прочих. Единственное, что я не описал и чему посвящена большая часть это заметки — как прикрутить к этому делу Macfusion. Мне оно не надо, у меня локально этот раздел маунитится автоматически.
я ни полслова не сказал про российские компании и понять как российские компании оправдывают недальновидность того, кто «не читал, но кликну» — я решительно не в силах. Ну не хотите читать что подписываете, не читайте, дело ваше. но рассказывать что «это нормально» мне не надо. Это ненормально, эти глупо.
чего «ха-ха» то? Да, нес и не только телефон. У него, как впрочем и у других продуктов, очень внятная методика возврата. Ведь очевидно, что надо думать, на что соглашаешься, ну а если не согласен — ну значит вернул и нашел то, что подходит.
чот значит «где-то есть»? оно очень явно возникает при активации телефона. Не нравится — не соглашайтесь. Я не раз и не два не соглашался, если мне такие условия мне не нравились. Кто же вам виноват, что вы соглашаетесь с чем попало а потом говорите «ой, я не читал, там много букв»
я не очень понимаю, какой в этой статье особенный контекст, который делает прямую и явную неграмотность автора текста настолько неважной. Может не неграмотность, но умышленное введения читателя в заблуждение, я не знаю. Да и контекст этот мне трудно определить. Это про что, вообще было? Про «Все мы слышали множество оправданий, почему кто-то не использует TDD» или все таки про «Я не пишу юнит тесты… »? Подобная мешанина встречается на каждом шагу и вносит в нестойкие головы тех, кто тесты еще не пишет твердое, но очень ошибочное определение — юнит тесты это TDD
Несколько странная статья. Первый абзац – автор говорит про TDD, потом вводная «Все мы слышали множество оправданий, почему кто-то не использует TDD», но весь остальной текст по сути к TDD относится постольку-посколько. По сути, речь идет о поводах не писать юнит тесты (на что намекает заголовок), а вовсе не про использование/не использование TDD методологии.
Вообще, подобным совмещением TDD и юнит тестов, пропагандисты TDD добиваются обратного результата. Человек копнет глубже в TDD, поймет что это такое, вздрогнет и больше не подойдет к юнит тестам вообще. И ничего странного, ведь все «знатоки» прямо отождествляют эти два, совершенно разноуровневых понятия.
результат загрузки pdf книги получился хуже, чем оригинал, и хуже, чем показывает все остальное. Вот пример — dl.getdropbox.com/u/71582/screenshot-20101228-34133.png (левая часть из orangereader, правая из более другой читалки
вот и я тоже не понял при чем тут TDD равно как и BDD. Возможно пример #2 относится как-то к TDD, но это осталось за пределами заметки. А вообще, из текста возникает (во всяком случае у мена) ложное впечатление, что вся разница между «типичными юнит тестами», TDD и BDD в наименовании методов и степени грануляции тестов. Также, я не смог понять обещанной «покажу разницу между TDD и BDD». Вот если бы не знал то подумал, что там вся соль в именовании тестов и их размере, что на самом деле является просто характеристикой осмысленных и читабельных тестов.
более чем согласен с критикой и где там харизма я не знаю. Но я знаю что там престраннейшая и откровенно идиотская навигация, очень посредственный и часто просто тупой саппорт, постоянные попытки чего-то незаметно продать. Короче, из моего опыта — очень посредственный сервис, если бы не лень я давно бы от них куда ушел.
тут ведь написано «для просмотра видеотрансляции понадобиться мак с операционной системой Mac OS X Snow Leopard и браузером Safari». Кому какое дело, что там остальные поддерживают
ну ваш комент показывает что либо вы не читали заметку до конца, либо вы просто потролить хотите, либо вам просто плевать на " Вторая просьба: не стоит устраивать особого осуждения по сути моих задач."
1. Если на на каждый выход (микрофон и скапйп) поставить плагин Pan, то можно развести по стерео-каналам ведущего и скайповых участников. Понятно, не для того, чтоб звучало в разных ушах, но для упрощения пост-обработки.
2. Иногда то, что слышишь сам, это не то, что nicesast посылает. Тут помогает поставить Vu Meters или Menu Bar Meters и смотреть уровни глазами.
3. Если есть возможность записи бэкапа, то очень стоит его иметь. Т.е. просто включить в nicecast звук и записывать с выхода мака на внешнее усторйство.
Вообще, подобным совмещением TDD и юнит тестов, пропагандисты TDD добиваются обратного результата. Человек копнет глубже в TDD, поймет что это такое, вздрогнет и больше не подойдет к юнит тестам вообще. И ничего странного, ведь все «знатоки» прямо отождествляют эти два, совершенно разноуровневых понятия.