先日 RubyKaigi なんかでいろんな人から「Podcast 聴いてます！」といってもらえたのはうれしかったんですが、ある人から「どこで録音してるんですか？」と聞かれました。「家ですね」と答えたら、「え、じゃあゲストの人を家に呼んでるんですか？」と返ってきたのはちょっとおもしろかったです。
配信・録音は Skype でやっています。日米で離れていることもよくあって、スケジューリングが割りと大変。収録自体は Skype Call Recorder などでそのまま録音もできます（実際自分の声はこれで録音しています）が、クオリティを上げるためにローカルでも録音したものをマージしています。この辺の話は Podcast Recording and Editing に書きました。
で、ライブ配信をするにあたって、単に Skype 上で流れている音を配信するなら Soundflower, Line-In, Garage Band なんかを駆使すれば できそうです。が、
- Skype と配信で（ただでさえ細い）自宅の帯域を占有したくない
配信用の Skype bot アカウントを作成し、実際に収録時にボイスチャットに参加させます。contact オンリーにしておいて、自動でaccept するようにしておくと便利ですね。操作は LogMeIn から。
あとは配信用のアプリに Soundflower 2ch を入力として入れればOK。ライブ配信に使っている Mixlr では入力ソースをカスタマイズできるので、ここで選択すればOK。配信スケジュールの設定や iOS アプリからの視聴からもできていいですね。
ライブ配信のスケジュールはだいぶ不定期ですが、iCal フィード を google calendar 上に用意したので、リアルタイムにツッコミを入れたい、という場合にはこちらも利用してみてください。
Here’s what it looks like when it comes to editing my (semi-badly recorded) Podcast episodes.
When I first heard 5by5/Mule’s podcasts, i was really impressed by the audio quality of their shows, since like many of you, i had a feeling that “Podcast is by amateurs and audio is mediocre at best”. I was blown away.
So I did a little bit of research before starting my show, because I wanted to make it sound good too. Jason Snell’s article on MacWorld explains the current method of my recording.Skype, Everyone Records, GarageBand
The tl;dr for that is, I use Skype Call Recorder to record both my audio and guest(s) on Skype, on separate tracks. It’s great that it records my audio locally, not via Skype, so it’s a direct input from my Mic.
I ask guests to record their local audio using QuickTime too and send files after recording. Then I synchronize them with Skype’s recorded audio, then discard the Skype audio file.
Now I get everyone’s locally recorded audio, on separate tracks on GarageBand, and I only need to edit when there’re murmuring or conflicts, etc. In Theory.
I’m often asked how long it takes to edit the show - if the show is one hour, it usually takes 2 to 3 hours.Microphone and Headphones
Recent episodes needed a little bit more of my editing work than previously - this is not to particularly blame anyone but the technologies/hardware, because it’s a mere audio leak on other’s ends.
Basically when I speak, my voice leaks on the guest’s track because their mic picks up the audio from the earpiece, and makes an echo/delay sound effect that I need to cancel out. That leads to the chaotic GarageBand editing shown earlier. Noise gate works to cancel that, but it also cancels the valid voice and i avoid doing it.
I ask everyone to use headphone/earphone, but sometimes the microphone is too close to them, or the headphone is not solid enough and leak audio from there. It doesn’t seem to happen to everyone (which is good), so it should definitely be related to the combination/setup of the microphone and headphones.
In terms of not leaking audio, Over-the-ear Headphones should be the best, but unless you have a microphone with monitoring capabilities (like Yeti :D), it might be difficult to hear what you speak while speaking.
I guess this is one of the difficulties of doing the show with irregular guests, since we can’t ask guests to invest some money on microphones/headphones, which I would if I do recurring/fixed guests :)Tips
Here’s a simple thing: don’t use Apple’s iPhone headset. Its audio isn’t bad, but it picks up a lot from its earpiece, and makes a big noise when touched with your clothes. Speaking of Apple, Macbook Pro Retina’s dual USB microphone is fantastic, assuming you don’t have a big ambient noise.
Also, some of the Japanese podcast shows I listen to have severe audio quality issues (although I’m not sure if they read this in English ;p) - Just don’t record the show in a cafe/restaurant with big ambient noise. Also, double your bitrate and make a mono MP3, rather than low bitrate stereo files.
Anyway this was my current setup. For the latest episode 11 where we talked about Google I/O, we also experimented with the live streaming with Mixlr. I will explain the setup about it (pretty simple if you have a spare Mac mini) later if you’re interested :)
tl;dr Today possibly for the first time ever, CPAN toolchain ecosystem all support test requirements as separate from build requirements. I can’t be happier ever.
Little bit of history. Timeline might be not in the correct order.
Module::Install always had test_requires() with forward compatibility in mind. However META spec v1.4 didn’t support specifying test requirements separate from build requirements. So the most tools merge them as a build requirement, including Module::Install itself. This means most of the Test:: module dependencies, even though they are only used for testing, were installed even when
notest options is supplied (with CPAN.pm and cpanminus).
META spec v2.0 came out, and it allows META (and MYMETA) to specify test requirements separately.
cpanm supported parsing test requirements separately, and skips installing test prereqs when —notest is in use. But at that time, most of the tools did not support emitting test requires apart from build requires.
Except Module::Build::Tiny, which just copies
MYMETA.json upon installation, so if you use an authoring tool such as Dist::Zilla or Milla to emit META.json with test requirements apart, it will be skipped.
Now, what should happen is to update
Build.PL to make use of these new features - I patched Dist::Zilla so that MakeMaker and ModuleBuild emitters will use test_requires when the installer has the version with the support for it.
I’m trying to fix Module::Install similarly, but as of this writing I’m not that hopeful - if someone wants to take over my work to make it merged that’d be super. But at this point I’d rather give up and stop using Module::Install.
Anyway, now when you have a module that is only used for testing, it will be (and has to be) declared and emitted correctly as a test dependency, and when you run CPAN installers, at least cpanm, with “no test” option, they won’t be installed. This is a very important milestone.
Ok, that was a little link bait title.
I’ve been a big fan of Module::Install - it automatically figures out the metadata of my module with just
all_from, and does the right thing creating META files. Then it bundles itself in inc/ so that if you install from CPAN you don’t need to have Module::Install pre-installed.
But not everybody likes it, especially contributors who need to install plugins before doing anything, or users who want to grab the latest from git.
The problem is, Module::Install is just a wrapper for MakeMaker, and MakeMaker and Module::Build are not the right tool to create a distribution.
Dist::Zilla is a pioneer in this field, to provide the complete authoring environment for the CPAN distribution, while having the ability to export MakeMaker/Module::Build compatible build files, so that end users don’t need to have that upon installation.
However Dist::Zilla kind of sucks. Well, that was a strong word - it has been coded and maintained actively, so it’s great. But its user experience could have a little improvements.
Milla is my first attempt to address that issue. It is a set of profile - PluginBundle, MintingProfile and command line wrapper, so that you can use it with almost zero-configuration and should do the right thing.
There’s some limitation and assumption that do not work for everybody, but at least for me I hope to replace 95% of my CPAN modules with Milla in the coming weeks.
Here’s a screencast to show you how to use it.
If you already have modules written with MakeMaker/Module::Install + ShipIt, see the Migration document for the details. I might make a new screencast just for the migration.
Hope you enjoy Milla. If you dislike the 195 dependencies it needs, check out our sister project Minilla as well.