背景

さまざまな理由で，iTunes のアルバムアートワークを画像として抽出したいときがあるでしょう． たとえば，ざっとサムネイルとして眺めてみたいとか．

抽出した画像の2次利用や公衆配信は，明白に知財侵害なのでダメ絶対，です． 細かいことをいうと，個人利用の範囲でも厳密には，マズいような気もします． 本エントリは，技術的にはできますよね，的なお話． …ということで，ひとつよしなに．

もう一週間ほど前になりますが，EE Timesという組込み業界系メディアにとある記事が掲載されました．

• “トヨタの急加速事故は欠陥だらけのファームウェアが原因？――原告側調査の詳細”

2007年に米国オクラホマ州で、トヨタ自動車の乗用車「カムリ」が急加速したことによる死亡事故が発生した。事故をめぐる訴訟において、原告側証人として事故原因の調査を行った組み込みソフトウェアの専門家は、裁判で「カムリのエンジン制御モジュール（ECM）のファームウェアに重大な欠陥が見つかった」と報告した。

だそうです． 通常，組込み業界系メディアが一般の…プログラマ界隈でさえ…取り上げられることは滅多にないのですが，Twitter の TL を軸にして眺めていたところ，割と広く拡散したように見えます． トヨタという知名度，クルマという日常生活に深く関わるものに関すること，加えて，コード品質からの切り口は，組込み業界以外のプログラマでも話題にしやすかったということがあったのだろうと思います．

背景

最近の AOSP は，対応するビルドホストもターゲットも増えたため，prebuilt バイナリの量が膨大になってきました．これが sync の時間を伸ばし，ビルドマシンのストレージを圧迫しています．

しかし，対応しないビルドホストやターゲットの prebuilt バイナリは，不要なわけです． 一部の Android 系プロジェクト (Android-x86 とか) では， manifest.xml を編集して，不要なプロジェクトを削除しています． しかし，ターゲットはさておき，ビルドホストは複数あったほうが開発者を増やすためには望ましいと言えます． また，AOSP の新しいリリースごとに manifest.xml の再編集を行うのは骨の折れる作業です．

このような状況を解消するために，repo には group という機能があります． 日本語のみならず，英語圏でも纏まって解説されている例は，ざっとググった限りでは無いようです．