俺の右腕に眠りし黒竜よ!力を貸してくれっ! ドッカァー!コンポォォーーッズ!!
どうものらぬこです。
某社関係者のどなたかが、類似するエントリー名で記事書いてたら申し訳ないので一応検索してみたのですが、そういうのはなさそうなので、取り敢えずこのフレーズ頂いときます<(__)>*1
というわけで、今回は Docker の話をしようと思います。
dockerとは
今更な話だし、検索すれば答えもたくさん出てくるだろうけど、取り敢えず僕の理解では「軽量でそこそこセキュアで再利用可能なアプリケーションorデータコンテナ」という認識です。
コンテナは基本的にはLinuxOSベースの仮想環境です。マイクロソフト社に御布施をしてWindows Server 2016を導入すれば、Windowsベースの仮想環境を用意することも可能みたいです。 でもそんなお金ないし、僕は今のところその必要性も感じてないので、触ってみたことはありません。
なお、コンテナはあくまで仮想環境なので、実PCで直接動かすことはできません。Dockerというソフトウェアを使って、ホストOSの上に構築した仮想的なLinux環境として動かします。
僕がDockerを触ってみようと思った訳
さて、PHPを使われている方の間では常識なのかもしれませんが、このPHPという言語はなかなか曲者で、マイナーバージョンレベルの更新ですら(7.0->7.1等)、上位互換性(バージョンアップしても今まで動いてたコードはちゃんと動くように作ってるよ的な)が割りと確保されていないことも多いという、個人的には割りとFA?って感じの特徴があります。
ローカルで確認したいとき等、一々PHPのバージョン切り替えるのめんどいし、そういえばdockerとか使えばなんか色々はかどるんじゃないかなとなんとなく思ったのが、最近dockerの勉強を始めたきっかけです
dockerの全貌をなんとなく理解してみる
ある概念を新しく勉強するときは、自分の知っている類似の概念に置き換えてイメージしていくと理解がしやすいと考えています。
dokcerもそんな感じで覚えていきました。
docker hub
Docker Image
- UbuntuやcentOSなどのLiveCD(DVD)メディア的なもの。docker hubに公開されているものをそのまま使うこともできるし、自分でほぼ一から作ることもできる。また、docker hubで公開されているイメージをさらに自分でカスタマイズすることもできる。
- LiveCDと違うのは以下の2つ。
- LiveCDと違って、PCから直接起動することはできない。 * 代わりに、DockerEngineと呼ばれる、DockerImageを動かすための仮想環境を構築するソフトウェア(VMWareとかVirtualPCみたいなやつ)使って、起動中のOSの上に仮想的なLinux環境を新しく立ち上げる(この起動中の環境のことをコンテナっていう)。
- LiveCDは読み取り専用だけど(HDDとかUSBメモリーをマウントすればもちろんマウント先には書き込み可能)、DockerImageには書き込みもできる。
- /root だろうが /etc だろうがどこでも書き込み可能。
- 書き込まれた内容ははDockerImageの中に直接保存されるのではなく、「どのファイルをどういう風に書き換えた」という差分情報のみがDocker Imageとは別の場所に保存されるため、追加、削除、変更内容は元のイメージには影響しない。
- たとえ「rm -rf /」してしまい絶望に飲み込まれたとしても、元のイメージから新しいコンテナを起動すれば全ての変更は無かったことになっています。
Dockerfile
Docker Container
- 起動中のDockerImageのことをコンテナって呼びます。
- 1つのイメージから複数のコンテナを起動することができます。
- 1つのイメージから複数のコンテナを起動しても、それらはお互いに干渉しません。
- 例えば、コンテナAで /etc/apache2/httpd.conf を書き換えても、その変更は コンテナBには適用されません。
- 1つのイメージから複数のコンテナを起動しても、それらはお互いに干渉しません。
- 色々な種類のイメージを用意すれば、色々な種類のコンテナを同時に起動することも勿論できます
- コンテナのリソース(ファイルシステムだったりネットワークリソースだったり)は基本的に隔離されているので、共有はできない。
- ただし、起動時にパラメータで指定したり、Dockerfileに設定を記載しておくことで、ネットワークの特定のポートを使用して通信したり、ファイルシステムの特定のパスをホストOS(Docker Containerを動かしているOS)と共有することなどが可能。
docker-compose
- 本エントリーのタイトルにもなった、なんとなくかっこいいコマンド
- このフレーズは、前職の馬場さん(仮名)によって生み出されたもので、サービスをデプロイするには、このフレーズを馬場さん(仮名)にシャウトしていただかなければならないという暗黙のルールがありました。
- ただし、「俺の右腕に~」の部分は
本人が恥ずかしがって省略されていました
- ただし、「俺の右腕に~」の部分は
- このフレーズは、前職の馬場さん(仮名)によって生み出されたもので、サービスをデプロイするには、このフレーズを馬場さん(仮名)にシャウトしていただかなければならないという暗黙のルールがありました。
- 複数の Dockerコンテナが連携して動作するようなシステム(例えば、nginx+PHPが動いてるコンテナとPostgreSQLが動いているコンテナとRedisが動いているコンテナ、など)で、複数コンテナの連携(ネットワークの接続設定やファイルシステムの共有っぽい設定、各コンテナの起動順序など)をいい感じにいろいろやってくれる、確かにすごいコマンド。
- それぞれのコンテナをどういう風に連携させるのかは docker-compose.yml というファイルに書いておく。
- 現在勉強中。
- 本エントリーのタイトルにもなった、なんとなくかっこいいコマンド
dockerの使い方
動作環境やインストール方法、動作原理なんかは検索すれば腐るほど出てくるのでその辺は書きません。
ここでは、使い始めるとかならず使うコマンドを、僕がよく使うコマンドを中心に備忘録的にまとめておきます。
Docker hubからImage 取得
$ docker pull <リポジトリ名:タグ名> * alpine:latest -> 軽量コンテナ向け * busybox:latest -> データコンテナ向け
alpine linux + apache な Dockerfile
- alpine linux は、Docker Image(基本パック)のサイズ僅か6Mb程のとてもコンパクトなlinuxDistribution
- 起動後のシェルで
# apachectl start
で apacheが起動する# wget http://localhost:80/
で index.html が落ちてくれば成功
FROM alpine:3.6 RUN apk add --no-cache apache2 apache2-utils && \ mkdir /run/apache2 && \ chown apache:apache /run/apache2
Dockerfile -> image 作成
$ docker build [-t <イメージにつける名前] .
作成済Imageの一覧を出力
$ docker images
不要になったImage 削除
$ docker rmi <リポジトリ名:タグ名 or イメージID>
Imageをまとめて削除
$ docker images | awk '{print $3}' | xargs docker rmi * 一部を消したいときは間にgrepなどでフィルタ
作成済Imageからコンテナを作成&起動
オプションがいっぱいありますが、コンテナのTCPポートをホストOS(Dockerを起動しているOS)のTCPポートにマップしたり、ホストOSのファイルシステムパスをコンテナから見えるようにしたりといろいろな設定ができます
$ docker run [-d] [-it] [-p <ホストポート番号>:<コンテナポート番号>] [-v <ホストパス>:<コンテナパス>] [--rm] [--name <コンテナにつける名前>] <イメージ名:タグ名 or イメージID> <起動時に実行するコマンド>
コンテナ一覧
$ docker ps * 起動中コンテナ $ docker ps -a * 停止中コンテナ
コンテナの内部情報を表示
$ docker inspect <コンテナ名 or コンテナID>
コンテナ->イメージ作成
これは、動作中のコンテナのファイルシステムの状態をDocker Imageとして保存するコマンドです。
$ docker commit <コンテナ名 or コンテナID> <イメージ名>
Container 削除
$ docker rm <コンテナ名 or コンテナID>
Container まとめて削除
$ docker ps -a | awk '{print $1}' | xargs docker rm * 一部を消したいときは間にgrepなどでフィルタ
参照されていないデータボリュームを削除
$ docker volume ls $ docker volume prune
Dockerの使いどころ
Dockerの使いどころを僕なりに考えてみました。
開発環境として
例えば、Java,PHP,Ruby等の開発言語 + RDB + Redis + ElasticSearch等のシステムをローカル環境で構築するのはちょっと大変ですが、Dockerで nginxのコンテナ、Java(+ApplicationServer)のコンテナ、RDBのコンテナ…等を用意して、それらの関連を docker-compose.yml で管理してあげれば色々楽ができそうです。
チーム開発をしているような場合には、新しいメンバーが入ってきたときも、それぞれのツールの指定されたバージョンをダウンロードして手順書に従ってインストールなんて面倒なことを毎回やらなくても、Docker入れて、そこのdocker-compose.yml使えば環境できるという状態にすることもできるはずと思います。
例えば、PHPのバージョンアップテストをしたい等の目的で、一時的に複数バージョンのPHPを使いたいときなども、なんかうまくやってくれるはず!
開発周辺ツールのホスト環境として
jenkins とか redmine とか selenium + firefox driver の docker imageや docker-compose.yml などは検索すれば簡単に見つかります。
それぞれの環境のために、サーバ用意してOS入れてRubyだのJavaだの入れてRDB入れてREADME.md見ながらconfig設定して〜をやらなくても、簡単に環境を作ることができるはずです。
「コピペ万歳」です!
テストデータがたっぷり詰まったRDBの格納場所として
このエントリー内では特に説明しませんでしたが、Dokcerはアプリケーションコンテナとして使用する方法の他に、データコンテナとして使用することもできます。
マスターデータのみが入ったクリーンな環境や、リグレッションテスト向けに、毎回同じテストデータが入った環境を簡単に作ることができるようになります。
最後に
Dockerをうまく活用できれば確かに色々捗ることも増えそうです。
でも、夢は広がっていますが、この辺を正しく理解して活用出来るようになるには、もう少し勉強が必要のようです。
余談ですが、1冊くらい書籍も読んでおこうかと思って、先日オライリー本を買いました。
安定のオライリー品質で、内容もわかりやすいし翻訳もとても読みやすいです。
- 作者: Adrian Mouat,Sky株式会社玉川竜司
- 出版社/メーカー: オライリージャパン
- 発売日: 2016/08/17
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (1件) を見る
というわけで、今回の話は以上となります。
お読みいただいてありがとうございました。
俺のPHPがこんなに遅いわけがない 〜メソッドキャッシュのお話〜
どうものらぬこです。
最近仕事でPHPを使い始めました。
というわけで、今回はPHPの話でもしようかと思います。
さて、2年ほど前に在籍していた会社で開発していたシステムの話になるのですが、そのシステムが抱えるDBが、規模が巨大だったりだとか、それなりに複雑なクエリーをいくつも投げなきゃいけないとかありまして、パフォーマンスを出すのに割と苦労していたことがありました。
その時は、一緒に仕事をしていた「自称」天才の某中国人様に、『「クラス名+メソッド名+引数の値をつなげたもの」をキーとして、「戻り値の値」をメソッド呼び出しを丸ごとキャッシュとして保持してくれる仕組み』なるものを作ってもらいまして各種諸問題を解決していただいていたのは今では、今では良い思い出です。
ちなみに、当時はJAVAで開発していたのですが、今回、それと同じような仕組みをPHPで作ってみたいと思います。
今回作るもの
クラス内のインスタンスメソッドの呼び出しをフックして、「クラス名+メソッド名+引数の値をつなげたもの」をキーとして、「戻り値の値」をキャッシュする仕組みを作ります。
既存のシステムになるべく簡単に組み込めるものにします。
キャッシュする部分、キャッシュからデータを取得する部分の実装は適当です(Redisなどのミドルウェア使うなりPHPのプロセス内に Hashなどで保持しとくなりご自由にということで)。
お題として、DBに保存された何らかのマスターデータを問い合わせるというシーンを想定して、DBへの問い合わせ部分(IDを渡すとIDに対応したレコードを返してくれるメソッド)をキャッシュしてみます。
前提となる開発・実行環境の話
僕の環境は下記のような感じです。
- mac mini 2014
- PHP 7.1系(5.6以降なら多分動く)
- postgreSQL 9.6系(サンプルコード動かすのに使ってます)
それほど特殊なことをしているわけではないので、PHP5.6以降(多分もうちょっと古いバージョンでも大丈夫)な環境であれば動作すると思います。
また、組み込み先のプロジェクトは、キャッシュ化したいモジュールが class として定義されていることが前提です。
.phtml 等の htmlなんだかphpなんだか良くわからないコードや、関数という概念が存在しない残念なコード等には組み込むことができません。
早速作ってみる
取り敢えず、コード載せときます。説明とかは後回しで。
キャッシュの仕組みを実装しているコード
まずは、メソッドキャッシュの仕組みを実装しているコードを載せておきます。
コードの中身は後で説明するので、中身わかる方は眺めていただいてもいいですし、よくわからない方は読み飛ばしていただいて大丈夫です。
<?php class MethodCache { private $_instance; private static $_className; public function __construct($instance) { $this->_instance = $instance; $ref = new ReflectionClass($instance); self::$_className = $ref->getName(); } private static $cached = Array(); private function get_cache($key, &$value) { if (isset(self::$cached[$key])) { $value = unserialize(self::$cached[$key]); return true; } else { return false; } } private function put_cache($key, $value) { self::$cached[$key] = serialize($value); } public function __call($method, $arguments) { $calledMethod = self::$_className . '->' . $method . ':' . json_encode($arguments, JSON_UNESCAPED_SLASHES | JSON_UNESCAPED_UNICODE); $ret = null; if (!$this->get_cache($calledMethod, $ret)) { $ret = call_user_func_array(array($this->_instance, $method), $arguments); $this->put_cache($calledMethod, $ret); } return $ret; } public function __get($key) { return $this->_instance->$key; } public function __set($key, $value) { $this->_instance->$key = $value; } }
なお、get_cache() がキャッシュ済データを取得するメソッド, put_cache()がキャッシュに値を追加するメソッドです。
これらのメソッドの中身はサンプル用に適当に作っただけなので(一応、キャッシュするという機能は持っていますが)、Redisなどのミドルウェアを使うように適宜置き換えていただければと思います。 また、実運用ではキャッシュの破棄タイミングなども考慮する必要があるかと思います。
サンプルを作って動かしてみる
ということで、取り敢えずサンプル的なものを作って、実際に動かしてみたいと思います。
なお、phpの5.6以上と、遊び用途で使える適当なRDBが使えることが前提です。
僕の環境は、上の方でも一回書きましたが、php7.1、postgreSQL9.6です。
RDBの準備
まずは、RDBに「id」という名前のprimary key を持つテスト用のテーブルを適当に用意して、データを100件ほどインサートしておきます。 列名などはなんでも構いません。
作業環境を整える
RDBの準備ができたら、ソースの作成に入ります。
まずは適当な作業ディレクトリに移動して、以下のコマンドを打ち込んでください。
mkdir intercepter mkdir dao curl -sS https://getcomposer.org/installer | php
続いて、以下のファイルを順に作成、保存してください。
intercepter/MethodCache.php
まずは、前項で載せた、メソッドキャッシュの仕組みを実装しているコードを intercepter/MethodCache.php
という名前で保存してください。
composer.json
PHPな方にはおなじみのcomposer.json です。 メソッドキャッシュの仕組み自体には不要なのですが、サンプルとしてDBにつなぐために illuminate-database というモジュールを使用しています。
{ "autoload": { "psr-4": { "Dao\\" : "dao/", "" : "intercepter/" } }, "require": { "illuminate/database": "^5.4", "illuminate/events": "^5.4" } }
./dao/ExampleDao.php
illuminate-databaseのモジュールを利用して、DBから値を取ってくるクラス(いわゆるDao)クラスです。
<?php namespace Dao; use Illuminate\Database\Capsule\Manager as Capsule; class ExampleDao { private static $instance = null; private function __construct() { } public static function instance() { if (is_null(self::$instance)) { self::$instance = new \MethodCache(new ExampleDao()); } return self::$instance; } public function findBy($id) { return Capsule::table('test.my_data')->where('id', $id)->first(); } }
./test.php
最後のファイルは、サンプルの本体です。
<?php require_once __DIR__ . "/vendor/autoload.php"; use Illuminate\Database\Capsule\Manager as Capsule; use Illuminate\Events\Dispatcher; use Illuminate\Container\Container; $capsule = new Capsule; $capsule->addConnection([ 'driver' => 'pgsql', 'host' => 'localhost', 'database' => 'example', 'username' => 'noranuk0', 'password' => 'password', 'charset' => 'utf8', 'collation' => 'utf8_unicode_ci', 'prefix' => '', ]); $capsule->setEventDispatcher(new Dispatcher(new Container)); $capsule->setAsGlobal(); $capsule->bootEloquent(); $dao = Dao\ExampleDao::instance(); for ($times = 1; $times < 10; $times++) { $i = 0; $timeStart = microtime(true); for($i = 1; $i <= 100; $i++) { $dao->findBy($i); } $timePassed = microtime(true) - $timeStart; $timePassed *= 1000; print("{$times}回目:{$timePassed}ms\n"); }
なお、DB接続の部分のパラメータは環境に合わせて適切に設定してください。
composer の実行
実際にサンプルを動かす前に、composerを使いautoloadの設定と必要なモジュールのインストールを行います。
以下のコマンドをタイプしてください。
composer installer composer upate
動かしてみようか
ここまでの作業で、サンプルは完成(のはず)です。
早速動かしてみます。
環境により実行時間は異なってくると思いますが、キャッシュが効いている2回目以降は爆速みたいな結果が出てくると思います。
1回目:47.780990600586ms 2回目:0.20217895507812ms 3回目:0.1981258392334ms 4回目:0.22983551025391ms 5回目:0.22292137145996ms 6回目:0.24795532226562ms 7回目:0.1990795135498ms 8回目:0.20503997802734ms 9回目:0.20503997802734ms
既存コードへの取り込み方
高速化したいクラスのインスタンスを生成する際、そのクラスのインスタンスを直接生成するのではなく、new MethodCache(...)
で囲います。
self::$instance = new \MethodCache(new ExampleDao());
こんな感じです。
これで、class内に定義されたメソッドは全てキャッシュ対象となります。
クラスのインスタンスメソッドが呼び出されたときに、過去に同一の引数で呼び出されたことがあり(かつキャッシュが残っていれば)元のメソッドは呼び出さず、キャッシュされた値を返します。
原理
例えば、こんなコードが合ったとします。
$dao = new MethodCache(new ExampleDao());
$dao->findBy($id);
findBy()メソッドは ExampleDao に定義されたメソッドで、MethodCache class には該当メソッドがありません。
PHPで、存在しないメソッドが呼ばれると、 __call() というマジックメソッドが呼ばれます。
今回は、このメソッドの中で、キャッシュがあればそれを返し、なければ元のclassのメソッドを呼び出す、ということをやっております。
課題
class内のメソッドを何でもかんでもキャッシュしたら都合が悪い場合も勿論あると思います。
例えば、取得系のメソッドはキャッシュしたいけど、追加、更新系のメソッドはキャッシュしたくない、などです。
メソッド名で、キャッシュする、しないを判断する仕組みを間に挟んだり、メソッドアノテーション的なもの(PHPにあったっけ・・・?)でなんとかする等、方法はあると思います。
取り敢えず、そろそろ書くのも飽きてきたのと眠くなってきたので、この辺のことはまた今度気が向いたら考えることにします。
取り敢えず、今日の話は、PHPでもAOP的な仕組みを使って、メソッドキャッシュみたいなこともできるよっていう部分の紹介までということで。
最後に
今回の記事の参考にさせていただいた記事の紹介です。
こちらの記事でメソッドの実行時間を取得する目的で使われている仕組みを、メソッドキャッシュのために使ってみました。
大変参考になりました。どうもありがとうございましたm(__)m
ということで、今回のお話は以上となります。
この記事が、PHPな方々にとって何かの参考になれば幸いです。
- 作者: 大重美幸
- 出版社/メーカー: ソーテック社
- 発売日: 2016/07/01
- メディア: 単行本
- この商品を含むブログを見る
世界で一番軽くてシンプル:mac用のシャッフル専用音楽プレーヤー
どうものらぬこです
今日は、とても軽くて、メモリーもほとんど食わないmacで使える音楽プレーヤ(?)を紹介するお話です。
少し前に購入した mac mini にもようやく慣れてきました。
ビデオキャプチャーボード挿してゲーム動画撮りたいとか、TV録画の為にPT3挿したいとか、心はいつまでも高@生の如くエ口ゲープレイを続けたいとか、そういう願望がないのであれば、Windowsもmacも変わんないですね。
さて今回は、macで使える「世界で一番軽いかもしれないシャッフル専用音楽プレーヤー」を紹介してみます。
macには、iTuneというソフトウェアが最初から付いています。
音楽再生もできるし、写真の管理もできる、iPhoneやiPodを持っていればそれらのデバイスとデータを動悸することもできる。
ただ、高機能ソフトウェアの宿命というかなんというか、とにかくメモリー容量を食います。
ライブラリに曲が何も登録されていない状態でも100Mb近くのメモリーを消費しています。
バックグラウンドで音楽再生したいだけなのであれば、もう少し軽いソフトウェアがほしいところです。
というわけで、今回は、超軽量音楽再生ソフトウェアの紹介です。
Windowsにしろmacにしろ、音楽ライブラリーと称してid3タグの情報をDB化して管理してくれる系のアプリが最近の流行りのようです。
でも、そんなのいらないからフォルダ指定したらそのフォルダ以下(サブフォルダ含めて)の曲を順番or適当に再生してくれればそれでいいという人もきっと多いと思います。
今回紹介するのは、そういった人向けのとっっても軽い音楽プレーヤーです。
この音楽プレーヤー、数千曲のmp3ファイルをシャッフル再生中でも消費メモリーは5〜10Mbほどです。
メモリー消費が少ないうえ、作業のじゃまにも全くならないのですが、以下のような事はできません
- ユーザインタフェースがありません。
- プレイヤーのウィンドウもないし、メニューのステータス領域に常駐もしません。
- コンソールアプリというわけでもないのでterminalも不要です。
- 曲が流れていない状態でアプリを起動すると、曲の再生が始まります。
- 曲が流れている状態でアプリをもう一度起動すると、曲の再生が止まります。
- スキップや一時停止など、再生と停止以外の操作はできません。
- 再生中の曲情報(タイトル、アルバム名、作曲者等)は表示できません。
- もちろんアルバムアートも表示できません。
- イコライザとかそんな高級機能ありません。
- でも、音はそこそこいいと思います。
- アプリダウンロードして実行するだけ、という訳にはいきません。
- 自分で作ります。シェルスクリプトを書くところからはじめます。
- 難しいことを知らなくても使えるように、この記事では(ほぼ)コピペでできるように手順を一つ一つ説明しています。
- 自分で作ります。シェルスクリプトを書くところからはじめます。
曲をBGMとして再生できればそれでいいよっていう方で、もし興味ありましたらこの先を読んでみてもよろしいかと思います。
逆に、シンプルでも見た目がきれいな普通の音楽プレーヤーをお探しの場合、この記事はちょっとお役に立てないと思います。
最初にネタばらし
そこそこなんか色々知っている人向けに先にタネ明かしをしてしまうと、中身は .app化した afplayer です。
ただし、afplayer は「曲を1回だけ再生する」という機能しか備わっていないません。シャッフル再生を実現するために、対象音楽ファイルのパス一覧が記載されたプレイリストファイルをランダムソートして、1曲毎にafplayer を起動する方法を取っています。
以下、手順と原理を簡単に説明します。細かい手順は次項で説明します。
- 再生したいmp3ファイル一覧が1行1ファイルの形で書かれたプレイリストファイルを作成します。
- 音楽プレーヤーの正体は「afplayer」というCUI(ターミナル上で動く)アプリです。
- afplayerには、複数の曲を再生する機能が備わっていないため、ランダム再生や曲リストの再生機能は、シェルスクリプト等で補ってやります。
- terminalからそのまま起動するとシェルを1つ専有して邪魔なので nohup ~~~ >/dev/null 2>&1 & で括ってプロセスをshellから切り離します。
- 音楽聞いてる時にスリープされると悲しいので、「caffeinate」というコマンドを利用して、再生中のスリープを抑制しておきます。
- 曲を止めたいときは killで止めちゃいます。
- 毎回コマンド叩くのめんどくさいので、音楽再生中なら停止、再生してなかったら再生開始するシェルスクリプトを作ります。
- terminal立ち上げるのもめんどくさいのでアプリ化して、ついでにいい感じのアイコンもつけてあげます。
- これをdockに載せて完成。アプリアイコン突っつくたびにシャッフル再生開始>停止 を繰り返します。
作ってみる
アプリを作る
アプリを作るといっても、別にプログラム書いたり開発ツール入れたりとかはいらないです。 なんかうまく動かなかったときのために、多少前提知識はあったほうがいいですが、多分コピペで動くように作ってあります。
というわけで、実作業を開始します。
作業は、ターミナルウィンドウ上でコマンドを叩きながら行うので、取り合えずターミナルを起動してください。
最初にプレイリストファイルを作成します。
諸般の事情により、プレイリストは ~/Music/playlist.txt という名前で用意します。
場所を変えたい方は、このあとで出て来る playlist.txt を参照している箇所をなんかいい感じに読み替えたり置き換えたりしてください。
$ cd ~/Music $ find ~/mnt/share/MUSIC -name *.mp3 > ./playlist.txt $ find ~/mnt/share/MUSIC -name *.flac >> ./playlist.txt $ find ~/mnt/share/download -name *.mp3 >> ./playlist.txt
音楽ファイルの保存場所に合わせて、パスの指定は適切に変更してください。
いったんホームディレクトリに戻り、適当な作業ディレクトリを作ります。
$ cd ~ $ mkdir work $ cd work
作成するアプリの雛形を作ります。
$ mkdir shufflePlay.app $ cd shufflePlay.app $ mkdir Contents $ cd Contents $ mkdir MacOS $ mkdir Resources
大文字と小文字、全角と半角の区別に注意してください。
次に、./Contents/MacOS 内に以下の内容の shellscript を作成し、更に実行権限も与えます。
$ cd MacOS $ pwd $ vi play.sh
#!/bin/sh cd ~/Music kill `pgrep -lf /play.sh|awk '{print $1}'` IS_KILLED=$? pkill afplay if [ "$IS_KILLED" -ne 0 ] then echo play start nohup cat playlist.txt | while read x; do echo -e "$RANDOM\t$x"; done | caffeinate -i sort -k1,1n | cut -f 2- | while read x; do afplay -q 1 "$x"; done >/dev/null 2>&1 & else echo play stoped fi
$ chmod +x play.sh
なお、hdmiなどで接続したディスプレイの内蔵スピーカーから音を出している方は、「caffeinate -i ... 」の部分を「caffeinate -id ... 」としてください。
ここまでの作業まで完了すれば、作成したshell script を実行することで曲の再生が始まり、もう一度実行すれば曲の再生が停止するはずです。
$ ./play.sh
うまく動かない場合、これまでの手順の見直しや、スピーカー音量の確認などを行ってください。
アプリの挙動を記載した Info.plist というファイルを ./Contents 以下に作成します。
アプリが起動した時に、先ほど作成したシェルスクリプトを動作させるようにしています。
また、アプリのアイコンの指定もこの中で行っています。
$ cd .. $ vi Info.plist
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>CFBundleExecutable</key> <string>play.sh</string> <key>CFBundleIconFile</key> <string>play.icns</string> </dict> </plist>
最後に、アプリアイコンを作ります。
めんどくさかったらこの手順はスキップしても良いのですが、せっかくなのでアプリのアイコンもそれっぽやつを作りましょう。
絵心がある方は自分で描いてもいいですし、そういうのは先人の資産を活用したいという方は「音楽プレーヤ アイコン」などの検索ワードで検索すれば色々と出てきます。著作権には気をつけつつ、その辺利用するのも一つの手とお思います。
画像の形式は、png が使えればいいのですが、.icns というファイル形式にする必要があります。
下記のサイトを利用すれば、webブラウザで、png 形式の画像を icns ファイルに変換することができます。
ICON CONVERTER: Convert PNG to ICO and ICNS online - iConvert Icons
作成した.icns ファイルは、./Contents/Resources/ ディレクトリに play.icns という名前で保存します。
ここまでの作業で、shufflePlay.app ディレクトリの中はこんな感じになっているはずです
. └── Contents ├── Info.plist ├── MacOS │ ├── nohup.out │ └── play.sh └── Resources └── play.icns
以上で完成です、作ったアプリを Finderなどでアプリケーションディレクトリに移動すれば LaunchPadにアプリが現れるはずです。もちろん アプリをdockにドラッグ&ドロップすれば、dockにも追加することもできます。
試しに、アプリを起動してみると音楽再生が始まります。もう一度起動すると停止します。
以後、アプリを起動するたびに、曲の再生開始>停止>再生開始>停止 が繰り返されるはずです。
参考サイト
今回、参考にさせていただいたサイト様です。
うまく動かない、ということがあれば、こちらのサイトも参考にしてみてください。
caffeinate - Macのスリープを抑制できる純正コマンド | ソフトアンテナブログ
技術/MacOSX/シェルスクリプトを".app"("Bundle")化する - Glamenv-Septzen.net
徹底的にソフトウェアで豊かな音を奏でてみよう - ザリガニが見ていた...。
というわけで、今回の記事はここまでです。
この記事が、皆様の音楽ライフの一助となれば幸いです。
ちなみに、僕が使っているPC用のスピーカーがこちらです。若干低音強めですがいい音で鳴らしてくれます。
KENWOOD AS-BT77 Bluetoothスピーカー 重低音/NFC搭載/ケンウッド シルバー AS-BT77-S
- 出版社/メーカー: JVCケンウッド
- メディア: エレクトロニクス
- この商品を含むブログを見る
最後までお読みいただいてありがとうございました。
- 出版社/メーカー: トランセンド・ジャパン
- 発売日: 2014/08/25
- メディア: Personal Computers
- この商品を含むブログ (2件) を見る
うわっ…私のmac、重すぎ…?ホイール操作のもたつきを完全に解消する方法とは
どうも、のらぬこです。
今回は、mac mini、mac book、iMacなどをUSB接続のWindowsホイールマウスで使っていて、なんかブラウザやOfficeソフト、エディタソフトなどのスクロールがもたつくなーっと感じていたら、それはmacの性能が低いからではなく、macOSがダメなせいです、という話をします。
この記事で紹介する対策アプリを入れれば改善できます。
mac mini、ブラウザがなんか重い・・・
さて、前回記事の話題となった先日購入したmac miniですが、、、
Windows機と比べると、
- 標準のファイラー*1が使いづらい
- samba接続がやたら不安定
- フロントにUSBが1つもないのはどうなの
などなど、色々物申したいことはあるのですが*2、iPhoneアプリ開発というかswiftの勉強目的で毎日頑張って使っております。
さらに、使用開始してからなんとなく感じていたのですが、Webブラウザの動きがなんか重いのです。
ページロードが遅いとか、レンダリングが遅いとか、javascriptが遅いというか、なんかスクロールするとすごいもたつく感じです。
しかも、タブの数、ページによらず常にもったりです。
しばらく使っていて、なんとなく原因がわかってきました。
マウスのホイールをゆっくり回すと全くスクロールしない!
Windowsユーザからすると、早く回そうがゆっくり回そうが「マウスホイール一目盛=3行分スクロール」*3が常識なのですが、macの場合はどうやら違うようでした。
macの場合、ホイールにも加速の仕組みがあるようで、早く回すと高速スクロール(ひと目盛りあたりたくさんスクロール)、ゆっくり回すとゆっくりスクロール(ひと目盛りあたりちょっとだけスクロール)、そして超ゆっくり回すと全くスクロールしないようにできているのだとか。
更に、高速回転、低速回転、超低速回転の判断がつかないマウスホイール最初のひと目盛りでは全くスクロールしないようになっています。
初動が遅れるので当然動きがもったりした感じになる。
もうね、アホかと。お前ら実装し終わってテストして本当にこれでいいと思ったのか、小一時間ほど問い詰めたい気分になりました*4。
解決方法
どうもこの現象、USB接続のホイールマウスのみで発生するようです。
嘘でした、Bluetoothマウスでももったりした動きします。
なので、(あれば)Bluetoothマウス、magic mouse(2)、magic trackpadなど、USB接続ホイールマウス以外のデバイスを使えば、改善するのだと思います(未確認)。
なお、普通のホイールマウスを使いたい場合、USB接続のマウスであれば、USB overdrive というアプリを使うと ホイールの動きをWindowsと同じような感じに変更することができるようになります。
まずは、以下のサイトから usb overdrive をダウンロードし、インストールしてください。有料アプリですが、無料でも使い続けることはできるようです。 ©1999-2017 Alessandro Levi Montalcini
インストール後、再起動を求められたら素直に再起動しましょう。
再起動後、画面左上のりんごアイコンなどから「システム環境設定」を開くと、USB overdrive という項目が増えているのでそいつを選択します。
設定画面が表示されるまで、10秒ほど待たされます。画面が表示されてから10秒後、真ん中の「Register Later」 というボタンが押せるようになります。
なお、「Buy Online」からお金を支払って登録コードを受け取ればこの制限はなくなると思います。
設定画面が表示されたら、[Wheel up]、[Wheel down]を以下のように設定してください。
Direction(方向)は、Windows風なら up => UP down => DOWN で、mac風ならその逆です。 このアプリを入れると、「システム環境設定」→「マウス」のスクロール方向の設定はこのアプリの設定で上書きされます。
speedは、Windowsだと3Lineですが、体感で5Lineくらいがちょうどよいと感じました。お好みで微調整してください。
また、画面左下のSpeed(こちらはポインタ移動速度です)、Acceleration(加速度)の設定も、チェックの有無にかかわらず「システム環境設定」「マウス」の設定は無視されます。標準の設定から変更している場合、こちらで設定し直してください。
macをホイールマウスで使っていて、なんかスクロールが遅れる、ホイール操作がなんかもたつく、ブラウザの動きが重いって常々感じている方がおられましたら、ぜひ一度お試しください。
Logicool ロジクール M720 トライアスロンマウス Bluetooth マルチデバイス Windows Mac OS Chrome OS Android対応 FLOW機能搭載
- 出版社/メーカー: ロジクール
- 発売日: 2016/09/23
- メディア: Personal Computers
- この商品を含むブログ (2件) を見る
今回の話は以上となります。
お読みいただいてありがとうございました。
macをWindowsっぽく快適に使う小技集 for Windowsユーザ
前職で1年ほどmac book使ってましたが、それまではほぼWindows、そして仕事とか自宅鯖とかなんとなくお試し程度にLinuxも使ってたのらぬこ(@noranuk0)です。
そんな僕が、先日 mac mini を買いました。
公式販売価格は88000円(税抜き)なので、約35%引きと割りとお得な買い物だった気がしております。
起動して S.M.A.R.T情報を眺めると通電時間は約800時間、それなりには使われていたと思いますがSSD劣化などの心配は全くなさそうです。
ちなみに、モニター、キーボード*1、マウス*2は自宅で余っていたものを使いまわしております。
さて、ここ1週間は自宅ではほぼほぼmac使いになっているわけなのですが、操作がやっぱりwindowsとはかなり違っているわけでして、やっぱりどうにも使いづらいところが多々出てくるわけで。
仕事ではWindowsマシーンを使っている都合上、特にキーボード、マウスの操作性はできるだけWindowsと同じにしたいと思うわけで。
そんなわけで、色々調べつつ、設定変更やカスタマイズ系アプリを入れるなど行い、結果、Windowsと大体おなじような操作性を手に入れることができました。
今回はそのあたりを紹介したいと思います。
前提条件
僕のmac mini環境はこんな感じです。
- mac OS sierra
- キーボード Windows用 日本語キーボード(無線)
- マウス Windows用 2ボタン+ホイールマウス(無線) OSのバージョン、入力デバイスの種類によっては、今回の記事に書かれていることがうまく実現できないかもしれません。
僕もmacには詳しくないので、もしうまく動かないような場合には、すみませんがお力に離れないと思います。
ちなみに、僕が使ってるキーボード&マウスはこちらです。
LOGICOOL ワイヤレスデスクトップ キーボード&マウスセット ワイヤレスコンボ Unifying対応超小型レシーバー採用 MK520
- 出版社/メーカー: ロジクール
- 発売日: 2010/09/10
- メディア: Personal Computers
- 購入: 3人 クリック: 7回
- この商品を含むブログ (3件) を見る
早速カスタマイズをする
ここからは、「僕がうまくやったやり方」を説明していきます。
マウスホイールのスクロール方向をWindowsと同じ感じに
購入したてのmacは、マウスホイールでのスクロール方向がWindowsと逆向きです。
Windowsと同じ向きにするには設定が必要です。
- 画面上のメニューバーの左端のりんごアイコンから「システム環境設定」を選びます。
- マウス という項目を探して選択します。
- スクロールの方向:ナチュラルのチェックを外します。
- マウスの移動速度(軌跡の速さ)、スクロール速度なども変更できるので、ついでにお好みで変更しても良いかと思います。
日本語入力の切り替えを [半角全角] キーで行う
これ、割と一筋縄では行きません。
入力ソースの切り替えに使用するショートカットキーは、はシステム環境設定のキーボードから変更ができるのですが、日本語Windowsキーボードをmacにつなぐと、半角全角キーが「`」に割り当てられてしまい、このキー単体をショートカットキーとして設定することはできないようになっています。
標準機能だけでなんとかするのはおそらく不可能で、これを実現するにはアプリの力が必要です。
今回は、「Karabiner-Elements」という、キーコードをかなり自由にカスタマイズできるアプリを使います。
ちなみに、僕はmac標準の日本語入力システムの「ことえり」は好きになれない*3ので、「google日本語入力」を使っています。このあとの説明も google日本語入力の場合の説明になっています。色々察して適宜読み替えるなりgoogle日本語入力も合わせて導入するなりしてください。
ちょっと話がそれましたが、本題の実現方法を大まかに言うと以下のようになります
- 「Karabiner-Elements」を使って「全角半角」キーを「F15」とか割りとどうでもいいキーのキーコードに割り当てる。
- システム環境設定で「入力ソースの切り替え」のショートカットキーに「F15」を割り当てる。
ということで、早速やっていきます。
まずはアプリをダウンロード&インストールします。
- Karabiner-Elements アクセスします。
- ページを開いて1画面ほど下にスクロールすると「Project Status」という見出しの下に You can download … みたいな英語が書かれています。
- そこに、dmg ファイルへのリンクが貼られていると思うので、それをダウンロード&インストールします。 なお、インストール後にPCの再起動が必要になります。
ダウンロード&インストールが完了したら、LaunchPadなどからアプリを起動します。
アプリを起動したら、Virtual Keyboard というタブを開き、Keyboard Typeから JIS を選択します。
次に、Simple Modifications タブを開き、 grave_accent_and_tilde(`) *4を f15 に割り当てます。ほか、お好みでキーコードを変更したいキーを自由に追加しても構いません。
僕は、「無変換」を「英数」に、「変換」「カタカナひらがな」を「かな」キーに割り当てる設定も追加しています。
ここまでの作業で、「全角半角」キーを押すと、f15が押されたと macOSさんは認識してくれるようになりました。
今度は、f15キーが押されたら、日本語み↔英語の入力切替を行う設定を行います。
「システム環境設定」を開き、「キーボード」の設定画面を開きます。
「入力ソース」タブを選び入力ソース一覧から「ひらがな(google)」「英数(google)」以外を削除します*5
「ショートカット」タブを選び、「入力ソース」カテゴリーの「入力ソースの次のソースを選択」のショートカットに F15を割り当てます。
とりあえずこれで、「全角半角」キーで日本語↔英語入力の切り替えが実現できました。
なお、かな→カナ変換とか、そういうのは知らんです。Windowsでも使っていなかったので実現できるのかとかすでにあるのかとかは不明でございます。
キーボード文字エリアの右上にある「¥」で「/(バックスラッシュ)」を入力する
UniCodeとかそういうの知らんですわ。「\」を「¥」として表示してるのはなんかもう暗黙の了解っていうかなんていうか。
google日本語入力使っている方はLaunchPadの中に「config dialog」っていう「ひらがなの「あ」」のアイコンあるので、そこから設定できます。
「ことえり」な方は「システム環境設定」の「キーボード」の中辺りから設定できたと思います。
もう少しネタはあるのですが、そろそろ力尽きてきたので、今回はこのへんで、ということで。
お読みいただいてありがとうございました。
mac 関連のその他の記事
androidアプリのCI環境(自動ビルドとテスト版自動配信)を全部無料で整える 其の弐
どうものらぬこです。
今回の話は、開発中androidアプリのソースをgitリポジトリにpushした瞬間、自動テスト(書いていれば)、自動ビルドが走り、成果物(apk)を自動でテスト配信するというお話の第二弾です。
前回記事では、bitriseというモバイル・アプリ向けのCIサービスを利用して、自動ビルド&自動テストするところまでを紹介しました。
今回は、fabricというサービスの一つであるcrashlyticsに含まれるbeta版アプリの配信機能を利用して、開発中アプリを随時テスト端末へ自動配信する方法を紹介します。
fabricは、アプリの収益化、利用者の増加にまつわる様々な問題を分析、解決するようなWeb上のプラットフォームです。
アプリユーザ数、アクティブユーザ率などの集計、クラッシュレポートの収集、そして今回利用するテスト版の配信機能などを備えています。
もともとTwitter社が運営していたのですが、今年の1月にgoogleに売却されたようです。
ただ、アナリティクス的な機能や、クラッシュレポートの収集機能であれば、firebaseというプラットフォームもありますし、機能的にかぶるところも多いです。
fabricのサービスが今後どうなるのかは、正直なところちょっと未知数かもしれません。
とはいえ、手軽にテスト版アプリの自動配信が行えるプラットフォームとしては、現時点ではとても使いやすいと感じているので、当面はこちらを利用していきたいと考えています。
アカウント登録
利用するにはアカウント登録が必要です。
というわけで、まずはfabricのアカウントを取得します。
アカウントの取得は、Fabric - App Development Platform for teams の右上にある、[GET FABRIC]ボタンから行うことができます。
登録は、画面右上の [GET FABRIC] と書かれたボタンから行います。
fabricのダッシュボードにアプリを追加する
アカウント登録が完了したら、fabricのダッシュボードに自動配信を行いたいアプリを登録します。
ダッシュボードへの登録は、対象アプリにfabricのSDKを組み込み、それをいったん起動することで自動的に行われます。
SDKの組み込みは build.gradleやandroidmanifest.xmlへのコード埋め込みのみなので比較的簡単に行えます。
しかし、APIkeyの取得が、現状android studio の pluginから行うしか方法がなさそうです。したがって、SDKの組み込みを行うにはandroid studio へのプラグイン導入が必須な感じとなっております。
Web上に導入手順が細かく書かれているfirebaseと比べるとやっぱりちょっと適当な印象を持ってしまします。いずれはなんとかしていただきたいものです。。
まあ、ここで言っても仕方がないので、ここはめげずに android studio にfabric pluginを導入します。
プラグインの導入は、[File] - [Settings…] メニューを選択して表示されるSettingsダイアログ内の plugins から行うことができます。
インストール完了後、android studio を再起動すると、ツールボタンンに fabricプラグイン起動ボタンが追加されています。
プラグインを起動すると、ログイン画面が表示されるので、先ほど登録したログイン情報を入力してログインします。
fabricで使えるすべての機能が一覧表示されるので、その中から crashlytics を選択します。
crashlyticsは本来は、クラッシュログの収集用のツールですが、テスト版(開発中)のアプリをテスト端末に自動配信する機能も持っています。 今回はそれを了する形になります。
crashlyticsを選択すると、埋め込み用のコードが表示されるので、そのままapplyボタンを押せば、オープン中のプロジェクトにコードが追加されます。
テスト端末などでアプリをデバッグ起動すれば、自動的に fabricのダッシュボードにアプリが追加されます。
fabricにwebからログインすると、確かにダッシュボードにアプリが登録されています。
自動配信を設定する
まずはテスターの方をfabricのプロジェクトメンバーに登録します。
テスター=本人のみというボッチ系開発者の方も、まずは自分をメンバーとして登録する必要があります。
ダッシュボードのサイドメニューから Beta を選択し、Add Testers というボタンを押します。
メールアドレスを聞かれるので、メアドを入力します。
すぐに下記のようなメールが来るので、
テスト対象のアンドロイド端末でメールを開き、本文内の [Let me in] ボタンを押します。
配信管理用アプリのダウンロード&インストールが始まるので、指示に従い配信用アプリをインストールしてください。
Beta というアプリがインストールされるはずです。
以後は、fabricに登録したテストアプリを更新するたびにこのアプリに通知が飛ぶようになっています。
テスターを何人か抱えたチーム開発を行うような場合だけではなく、個人開発中、数台のテスト端末に開発中アプリをまとめて配信したいような場合にも活用できるかと思います。
また、過去のバージョンも保存されているため、一旦旧バージョンに戻して確認するといったことも簡単に行うことができるようになっています。
fabricのアプリを更新する
android版の場合、gradeleコマンドを利用すればfabric経由で簡単に更新版を配信することができます。
- デバッグ版の場合
$ ./gradlew assembleDebug crashlyticsUploadDistributionDebug
- リリース版の場合
$ ./gradlew assembleRelease crashlyticsUploadDistributionRelease
これを自動ビルドを行ってくれるCI環境に組み込めば、developブランチへのpushでdebug版のテスト配信、masterブランチへのpushでrelease版のテスト配信を行うといったことが可能になります。
前回紹介した bitriseの記事でも、そのような設定を行っています。
以上、2回に分けて、androidアプリのCI環境の話と、テスト版自動配信の話をさせていただきました。
お読みいただいてありがとうございました。
androidアプリのCI環境(自動ビルドとテスト版自動配信)を全部無料で整える 其の壱
どうも、のらぬこです。
今回の話は、個人開発しているandroidアプリのソース管理(gitホスティングサービス)、自動ビルド、自動テスト配信環境を全部無料で整えたというお話の第一弾(前半)になっております。
この記事では、これらのことをどのように実現したかという観点で、ソース管理の話から自動ビルド環境を構築したところまでの話をします。
利用したサービスは以下の3つです。
- BitBucket
- Bitrise
- fabric(crashlytics beta配信)
- リリース済アプリのクラッシュ情報を自動で収集、報告してくれる等のサービスが提供されています。
- 今回は、その中の一つ、テスト版をチームメンバーに自動配信するようなサービスを利用します。
なお、今回の話は、Bitbucketアカウント登録から、Bitriseを利用した自動ビルド環境構築までの話になります。
さて、僕はandroidの個人開発を始めた当初から、gitホスティングサービスとしてマイクロソフトが提供しているVisual Studio Team Serviceを利用していました。
ちなみに、Visual Studio Team Serviceはソース管理(gitとMS製のバージョン管理システムに対応)と自動ビルド&デプロイ、Issue管理をひとまとめにしたようなWeb上のサービスになります。
5人以上のチームで使用する場合には有償になりますが、メンバーがそれ未満の場合にはサービス利用は基本無料となり、例えば、プライベートgitリポジトリなども数や容量の制限なく自由にいくつでも作成することができる(逆に、パブリックなリポジトリは作成できない)等、ちょっとほかには見られないような特徴も持っています。
また、.net系のアプリやwebサービスはもちろん、nodejsなwebアプリ、mavenやgradle管理のJVM系言語、androidやxcodeにも対応したCI環境も用意されており、さらにazureへの自動デプロイもできたりして*1、お金はかけたくないけどいろいろ使ってみたい等、用途によってはとても良いサービスだと思います。
Visual Studio Team Serviceについては、以前紹介記事も書いているので、ご興味ありましたら合わせてごらんください。 noranuk0.hatenablog.com
僕ももともとはgitリポジトリのホスティングサービスとしてしか活用していなかったのですが、開発中Androidアプリの自動ビルドもそのうちやりたいなーとは思っていました。
が、Visual Studio Team Serviceで用意されていたAndroidの自動ビルド環境は割と残念な出来栄えで、自動ビルドには成功しませんでした。
どの辺が残念かというと、環境がかなり古く、例えば用意されているsdkバージョンに未だにandroid-19が使われていました。
しかもおそらくアクセス権限関係?でSDKのアップデートもできない状態で、どうにも使用するには堪えないような代物だったんです。
半ばあきらめていたのですが、gitリポジトリにはBitbucketを使い、リポジトリへのpushをトリガーとした自動ビルドにはbitriseを、ビルド済apkの自動配信にはfabricを使えば、僕のやりたいことは全部無料で実現できそうだと分かり、早速試してみました。
結果、自動ビルド&自動配信まで無事に行うことができるようになりました。
前置きが長くなってしまいましたが、これから手順等の紹介をします。
gitリポジトリの移行
まずは、BitBucketのアカウントを作ります。
BitBucketもVSTSと同様に少人数チームであればプライベートリポジトリも割と無制限に作れるようです。
Bitbucketのアカウント作成と他のリポジトリからのソースのインポートについては特に説明の必要ないかと思います。
どうしても何かを見ながらやりたい方はこの辺(↓)でよさげなページを探してください。
bitbucket アカウント作成 - Google 検索
gitはtortoiseGitかSourceTree経由で使っててコマンドとかよく解んないっていう僕みたいな人は、Bitbucketには他のgitホスティングサービスのリポジトリを丸ごとインポートできるUIを持っているので、そいつを使えば移行も簡単です。
ただしその場合、移行後にローカルリポジトリのoriginの向き先を変えるなり、BitBucketからcloneし直すなりしないと後でちょっと残念な気持ちになるかもしれません。
Bitriseで自動ビルド環境を準備する
Bitriseは、iOS, android, unityプロジェクトのCI環境を提供しているモバイルアプリに特化したCIサービスです。
CIによる自動ビルドも、月に200ビルドまでは無料で利用することができるため、個人利用であれば無料枠内で十分に活用できると思います。もちろん、ちゃんとテストを書いていれば、時間制限はあると思いますが、androidエミュレータを利用した自動テストも当然可能です。
ソースコードは、対応するgitホスティングサービスと連携し、そこから取得ことになります。
対応しているgitホスティングサービスは、GitHub, BitBucket, GitLabの3つです。。
実は、この記事を書いていて気が付いたのですが、任意のgitリポジトリを指定することもできたようです*2。
ビルド手順は、workflowと呼ばれるWeb上のツールで設定します。
なお、基本的なテンプレートは最初から用意されており、ソース取得元のgitリポジトリを指定すれば、中身をみてAndroid、iOS、Unityの設定を自動生成してくれるため、特にカスタマイズが必要なければそのまますぐに使えます。
ただし、ビルド結果やビルド済みファイルのダウンロードURLが記入されたメールの配信などは、デフォルトでは行ってくれません。
ビルド結果とダウンロードURLが書かれたメール通知やSlack通知、今回僕が行ったようなfabricを利用したテスト版配信等をやりたい場合は、多少の設定追加、変更などのカスタマイズが必要です。
なお、カスタマイズする場合も、難しいことをする必要は全然ありません。
例えば、特定のURLからファイルをダウンロードしたり、ビルド結果をslackに通知するためのひな型は最初から用意されており、使いたいコンポネントを選択し、URLやAPIキーなどの情報を入力するだけで使えるようになっています。
アプリの署名については、少し注意が必要です。
androidアプリの場合、apkを署名するための鍵が必要になります。
デバッグ用の鍵はbitrise側で用意されているため、特に意識せずともデバッグ用に署名されたapkをビルドしてくれます。しかし、どうも毎回必ず同じ鍵が使用されるわけではないようで、更新版のインストールに失敗してしまうことがありました。
したがって、デバッグビルド用の鍵も自分で用意したほうが良いかもしれません。
独自の(自分で用意した)鍵を使いたい場合も、bitriseが鍵の保存場所を提供してくれているため、別途サーバを用意して鍵をWebからダウンロードできるようにしておく必要も、gitリポジトリに鍵をコミットしておく必要もありません。
僕の場合、ローカル開発環境で使用している鍵と同じものを使いたかったので、bitriseが用意してくれたアップロード場所に、普段開発PCで使用している鍵を登録しています。 qiita.com
無論、リリース向けの鍵についても、同様にbitriseのサーバにアップロードして、リリース版ビルド時にその鍵を参照するように設定しておけば、独自の鍵管理の仕組みを考える必要がなくなります。
ところで、自動ビルドの実行タイミングについてですが、初期設定では全てのブランチへのpush、プルリクをトリガーとして、すべて同じ手順でビルドが実行されるようになっています。
例えば、developへのpush時はdebug版、masterへのpushでリリース版のapkをビルドするような場合には、ワークフローを複数作成し、エディター画面の「trigger pattern」と書かれたリンクから、トリガーの種類と使用するワークフローを関連付けする必要があります。
トリガーには、特定ブランチへのpush時、特定ブランチへのプルリク時、特定パターンのタグがpushされた時を指定することができるようになっています。
これらの設定内容は最終的にはymlに落ちますが、ymlでしか書けないような設定は(おそらく)ありません。
全てGUIツールで設定が可能になっています。
自分が使っているymlの設定はこんな感じです。 developへのpushでデバッグ版、masterへのpushでリリース版がビルドされ、ビルド成功時にはfabric betaへの自動配信までやってくれます。
--- format_version: 1.3.1 default_step_lib_source: https://github.com/bitrise-io/bitrise-steplib.git trigger_map: - push_branch: master workflow: master - push_branch: develop workflow: develop workflows: master: steps: - activate-ssh-key@3.1.1: run_if: '{{getenv "SSH_RSA_PRIVATE_KEY" | ne ""}}' - git-clone: {} - script@1.1.3: title: Do anything with Script step - install-missing-android-tools@1.0.1: {} - gradle-runner: inputs: - gradle_task: "$GRADLE_TASK_PREFIX$POSTFIX_RELEASE $CRASHLYTICS_UPLOAD_DISTRIBUTION_PREFIX$POSTFIX_RELEASE" - deploy-to-bitrise-io@1.2.9: inputs: - notify_user_groups: none - notify_email_list: "$EMAIL_NOTIFICATION" envs: - KEY: '' opts: is_expand: true develop: steps: - activate-ssh-key@3.1.1: is_always_run: true run_if: '{{getenv "SSH_RSA_PRIVATE_KEY" | ne ""}}' - git-clone: is_always_run: true - file-downloader@0.9.1: is_always_run: true inputs: - source: "$BITRISEIO_MYSYNCER_DEBUG_YMEWHJSL_URL" - destination: app/signingConfigs/debug.keystore - script@1.1.3: title: Do anything with Script step is_always_run: true - install-missing-android-tools@1.0.1: is_always_run: true - gradle-runner: is_always_run: true inputs: - gradle_task: "$GRADLE_TASK_PREFIX$POSTFIX_DEBUG $CRASHLYTICS_UPLOAD_DISTRIBUTION_PREFIX$POSTFIX_DEBUG" - deploy-to-bitrise-io@1.2.9: inputs: - notify_email_list: "$EMAIL_NOTIFICATION" app: envs: - opts: is_expand: false GRADLE_BUILD_FILE_PATH: build.gradle - opts: is_expand: false GRADLE_TASK_PREFIX: assemble - opts: is_expand: false GRADLEW_PATH: "./gradlew" - opts: is_expand: true CRASHLYTICS_UPLOAD_DISTRIBUTION_PREFIX: crashlyticsUploadDistribution - opts: is_expand: true POSTFIX_DEBUG: Debug - opts: is_expand: true POSTFIX_RELEASE: RELEASE - opts: is_expand: true EMAIL_NOTIFICATION: ********@gmail.com
fabricbeta配信の話まで書こうと思っていたのですが、そろそろ眠くなってきたので続きはまた今度、ということで。
ちょっと中途半端で終わっていますが、お読みいただいてありがとうございました。
PVがあろうがなかろうが、続編も近日中に公開予定です。