2017年6月19日月曜日

[Visual Studio 2017] インデント問題を解決する? .editorconfig を使ってみた

Visual Studio 2017 からプラグインインストール不要で EditorConfig が使えるようになったので、遅ればせながら使ってみました。
2017 のリリース直後に試して、ブログにしようと思ってましたが、なんだかんだでこの時期になってしまいました。
なので、特に"これ"という情報はありません(;´・ω・)。が、editorconfig 便利だなーということだけ紹介します。

EditorConfig とは?
EditorConfig はインデントのタブ派 vs スペース派などのルールを書式化し、個人のエディタ設定によらず、コーディングスタイルの統一ができるようになるものです。


チーム内のスタイル統一が容易になるのもメリットですが、個人的には1つのエディタでプロジェクトごとの設定を意識せずにコーディングできるとこが便利だなーと思いました。

Visual Studio の場合ですと、インデントの設定はグローバルに1つだけなので、タブ派なプロジェクトとスペース派なプロジェクトを跨いで作業するのは大変でした。
これが、Visual Studio 2017 から EditorConfig が使えるようになったので、とっても捗ります!
(※ 2017 以前でも拡張機能をインストールすることで使用できます)

iutest の .editorconfig
root = true
 
 [*]
 indent_style = space
 indent_size = 4
 insert_final_newline = true
 
 [Makefile]
 indent_style = tab
 
 [*.{cpp,hpp,ipp}}
 charset = utf-8-bom
 
 [*.py]
 charset = utf-8
 
 [*.{yml,html}]
 indent_size = 2

これをルートディレクトリに配置するだけで、Visual Studio が自動的に設定を読み込んで、インデントなど指定した通りに編集できるようになります。

設定できる項目
公式にまとまっているので、そちらを参照してください。

https://github.com/editorconfig/editorconfig/wiki/EditorConfig-Properties




editorconfig、本当に便利なんで、会社でもリポジトリに突っ込んでいこうと思いました。
今回は以上です。ではでは。

2017年6月12日月曜日

[Docker] docker-compose で作成されるデフォルト network でハマった備忘録

こんにちは。
ブログズミ: [Docker] 始めてみたけど躓きまくってるので備忘録として残しておくよ
上記記事から、一ヶ月くらい経って、docker-compose も使うようになってきました。
Docker はもとより、ネットワークとかの知識がほとんどない素人ですが、多少覚えてきました。

それにしても、docker-compose 便利ですね!
環境変数とか設定を Dockerfile から追い出せるし、--build-arg も docker-compose.yml に書けるし、
Docker ホストが起動したときに自動起動したい場合も、"restart: always" を書いとけば OK ですし、
ブログズミ: [Windows][Docker] Host および コンテナの起動をスタートアップに登録」とか、
いらんかったわ!って感じです。

でもハマった
まぁ、でもハマりますよね。
今回ハマったのはネットワーク絡み。

Dockerfile からビルドして docker run したコンテナからは通じるのに、
それを docker-compose で run すると通じない…
そんなことがありました。

docker-compose が作成する network
docker-compose run すると、{サービス名}_default という名前で network が作成されます。

$ docker-compose up -d
Creating network "hoge_hoge_default" with the default driver

こんな感じでログが出ていると思います。

Docker 管理下のネットワークは docker network ls で確認できます。
$ docker network ls
a8c84238aaaa        bridge             bridge              local
f9b622381b6a        host               host                local
7061554ce0f1        hoge_hoge_default  bridge              local
f1c24d1dda82        none               null                local

さらに、詳細を docker network inspect {ネットワーク名} で確認できます。

$ docker network inspect hoge_hoge_default
[
    {
        "Name": "hubot2_bridge",
        "Id": "1d3906e507b39eb08cf6d7326058eb62c447772371c4d2b692765c25778a4d11",
        "Created": "2017-05-23T11:41:13.819782229Z",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": null,
            "Config": [
                {
                    "Subnet": "172.18.0.0/16",
                    "Gateway": "172.18.0.1/16"
                }
            ]
        },
        "Internal": false,
        "Attachable": false,
        "Containers": {
            "72917816824f2d5fe76ba854a49766787fd1bb54928fd903d251fc9dfa5a2f69": {
                "Name": "hoge_hoge_1",
                "EndpointID": "219cb4cbd809b4d3d7e5f4d1118abe87fe5e4d44222ace5e6022119366827d60",
                "MacAddress": "02:42:ac:12:00:02",
                "IPv4Address": "172.18.0.2/16",
                "IPv6Address": ""
            }
        },
        "Options": {},
        "Labels": {}
    }
]


で、これが目的にネットワークと衝突してて通じてなかったようです。

解決方法
docker-compose.yml にネットワークの設定を書き足します。
参考:https://github.com/docker/compose/issues/2582

services:
  hoge:
    networks:
      - bridge

networks:
  bridge:
    driver: bridge
    ipam:
      driver: default
      config:
      - subnet: 172.16.238.0/24
        gateway: 172.16.238.1

これで、network の subnet/gateway を指定できるので、都合の良い設定すれば解決するはずです。



また、1つ docker のことがわかった気がします。
今回は以上です。では。

2017年6月5日月曜日

Wandbox のコンパイラー追加を通知する環境を作った

Wandbox で対応コンパイラーが増えたら、自分宛てにツイートしてくれる環境を作りました。



構成
Appveyor + Zapier

概要
https://github.com/srz-zumix/wandbox-news
ソースコードをみていただければ、どんなことやっているかはわかると思います。
特に難しいことはしてなくて、Wandbox API で取ってきたリストを成果物として保存して、前回との差分があれば Webhook を投げます。
あとは、Zapier で Webhook を受け取ってツイートするだけです。

その他
最初は、Google App Engine とか Circle CI とか使おうと思ってましたが、定期ビルド、Webhook Notification、成果物の保存・取得ができる Appveyor に落ち着きました。

あとは、Notification でカスタム json を作るのに、ちょっと手間取りました。
デフォルトで送ると Zapier で message を取るのがめんどくさかった(というか、うまくできない?)ので、カスタムで送るようにしてます。
url が secure 指定できなかったので、Web UI 設定にしてますが、appveyor.yml にコメントで書いてあるので参考にしてください。

では。


※更新なしが FAIL 更新ありが PASS になっているが、どちらも PASS にできるならしたい。
※Webhook を発行するトリガーとして、ステータスを利用しているため。
※最初は逆だったが、成果物取得で落ちてくるのが lastSuccessBuild のものだったため、更新があったときを PASS にしている。

※Zapier で tweet する際に改行がスペースに置換されてしまっている。
※改行のまま tweet したい。

2017年5月29日月曜日

[Visual Studio] 1行の文字数制限のガイドラインを表示する

cpplint とかでよく1行あたりの文字数に対してい警告が出たりしますよね?
プロジェクトによっては、"厳守" であったり、"できるだけ対応" であったり、ルールが違うと思います。

これ、lint にかける前に意識してコーディングしたいな~と思いました。
自分の場合、厳しいルールの環境ではなかったので、強制的に改行するようなものではなく、
ガイドライン引けるものがないか探して見たところ、ドンピシャなものがあったので紹介します。


Editor Guidelines
Editor Guidelines 拡張機能を使います。


これをインストールすると、エディタの右クリックメニューに「Guidelines」が追加されます。

「Add Guideline」をクリックすると、このようにガイドラインが表示されます。



短い!!


ということで、
文字数を指定する場合は、「コマンドウィンドウ」を開いて以下のコマンドを打ち込みます。
(既に Add してると失敗するので、Remove しておいてください)

Edit.AddGuideline 100




これで、任意の文字数のところにガイドラインが引けました!


ちょっとしたことですが、これでまた Visual Studio が便利になりました~
ではでは。

2017年5月22日月曜日

[Visual Studio] VS2017 のスタートページをカスタマイズする

Visual Studio 2017 になって、デフォルトのスタートページが変わりました。
が、レイアウトが変わってピン留めしたプロジェクトや履歴が見づらくなってしまいました。(個人的に)

VS2017:

VS2015:


スタートページもカスタマイズできる!
Visual Studio では拡張機能により様々な機能を追加したり、ツールと連携したり、見た目を変えたりできますが、スタートページもカスタマイズできます!
(いままで変えたい思わなかったので、VS2017 になって始めて知りました)

拡張機能を作成して、自分好みのスタートページを作ることもできますが、今回は既に Marketplace にある拡張機能を使ってみました。

BetterStartPage 拡張機能
「ツール」>「拡張機能と更新プログラム」から「BetterStartPage」をインストールしてください。


インストールしたら、「ツール」>「オプション」>「スタートアップ」を開いて、
「スタート ページのカスタマイズ」で「BetterStartPage」を選択してください。


BetterStartPage の設定
BetterStartPage にするとスタートページに、「Favorites」が追加されます。
ここで、任意のソリューション/プロジェクトを登録できます。


まずは、グレーのエリアで右クリック。「Edit Mode」をクリックします。


下のような状態になるので、「New Group」をクリックします。
(グループとプロジェクトのカラムは自由に変えてください)


グループが追加されるので、適当に名前をつけて、右上にあるプロジェクトの追加ボタンを押します。
ファイル選択ダイアログが開くので、お好きなソリューション/プロジェクトを選択してください。


追加すると、以下のようになります。


編集が終わったら、もう一度右クリックをして Edit Mode を終了します。(当たり判定が狭いかも…)


設定は以上です。


結果
設定した結果はこんな感じになります。


もっと、THE Visual Studio 2015 !! な見た目を期待してたんですが(全体的に)、それでも多少使いやすくなったような気がします。
できれば、最近使ったファイルから、Favorites に追加できればもっとよかったんですが…

ともあれ、スタートページも拡張機能でカスタマイズできることがわかりましたので、是非作ってみてください。
便利なものを待ってます。

2017年5月15日月曜日

設定 XML ファイルが壊れて SourceTree が起動しなくなった場合の対応

PC が強制終了して SourceTree が起動しなくなってしまった!!

この症状、二度目なので未来の自分のために書き残しておく。

慌てない慌てない
まずは、なんで起動しないのかイベントビューアでログを確認しましょう。

XML ファイルのオープンで落ちていた場合は、このまま読み続けてください。
それ以外の場合は、もう一度ググりなおしてください m(__)m

コンフィグファイルを確認する
SourceTree の設定ファイルが壊れている疑いがあるので、user.config ファイルを確認しましょう。

user.config は %USERPROFILE%\AppData\Local\Atlassian\SourceTree_Url_**** フォルダの中にあります。(*** はユニークID)
上記フォルダを開くと、SourceTree のバージョンごとにフォルダがあると思いますので、
現在使っているバージョンのフォルダを開いてください。

そこに、 user.config ファイルがあるので、テキストエディターなどで開きます。
すると、以下のようにノードが閉じられていないファイルになってしまってました。

そうでない場合は、Google ホームに戻ります m(__)m

コンフィグファイルを修復する
修復する、といってもファイルを消すだけです。
(※古いバージョンのフォルダがない場合は、設定消えることになるかも)

SourceTree は user.config がなかったら、古いバージョンの user.config から再作成するようなので、
壊れている user.config ファイルを消せば、古い設定から修復されます。
(1つ前のバージョンの user.config も壊れていたらそれも消す。以下繰り返し。)

ファイルを消したら、普通に SourceTree を起動してください。
問題なく起動するはずです!

起動しない!!という方、ごめんなさい m(__)m
他の情報を探してください。

最後に
未来の自分がこのブログを見ることがないことを祈ります(-人-)

2017年5月8日月曜日

[CI] Bitrise 始めました



今回も CI サービスの紹介でございます。
今回は「Bitrise」です。

http://devcenter.bitrise.io/
In short Bitrise is a Continuous Integration and Delivery (CI/CD) Platform as a Service (PaaS) with a main focus on mobile app development (iOS, Android, Xamarin, ...).

こちらに書かれているように Bitrise はモバイルをメインターゲットとした CI/CD サービスです。
今回、iutest では CMake で生成した Xcode プロジェクトをビルド(テスト)する CI サービスとして利用を開始しました。

このブログで紹介するということは、もちろんフリープランが存在します。


200ビルド/月、10分/ビルド、と少し制限厳し目ですが、iutest で使う分にはなんとかなりそうです。

Sign up
では、早速 Sign up しましょう。
「Start building for free」ボタンを押すと、まずは以下のようなアカウント登録画面が表示されます。
通常のメールアドレスの他、Github,Bitbucket,GitLab アカウントが選択できますので、お好きなものを選択してください。



続いて、簡単なアンケートが出ます。答えても答えなくても OK です。


次にパスワード設定をします。Github などのアカウントを利用した場合でも必須のようです。


これで登録完了です。


app 追加
Sign Up できたので早速ジョブ(app)を作っていきましょう。
「+Add first app」ボタンをクリックすると、リポジトリ選択画面になります。
目的のリポジトリを選択してください。


次はリポジトリアクセス設定です。
iutest では 「AUTOMATIC 」、 「No, auto-add SSH Key」としました。必要に応じて変更してください。


つづいて、セットアップの検証が行われます。
対象ブランチを選択して「Next」を押します。


検証が始まるので待ちます。


検証が終わるとビルドコンフィグが開きます。

Xamarin が選ばれてますが、おそらく Visual Studio の .sln ファイルを検出したからでしょう。
ただ、iutest は Xamarin 使ってません。ここは「MANUAL」で設定をします。

今回は、Xcode ビルド(とテスト)をしたいので、「macOS」とか「iOS」を選択したいところですが、プロジェクトファイルや Scheme を要求されるため、「OTHER/MAUNUAL」から「Xcode on macOS」な Stack を選択して次へ。



最後に Webhook 設定をします。
特に理由がなければ、「Register」で良いと思います。Push and PR が Bitrise に通知されます。


これで、作成完了です!


ワークフローを作成する
Bitrise では Workflow で処理を記述します。

Workflow タブをクリックすると Editor が開きます。




既存のステップがたくさんありますが、Script を使うと bash script ので目的にあったステップがない場合は、これを使えばなんとかなると思います。



フローが完成したら、SAVE ボタンを押して保存しましょう。
※ ちなみに、ワークフローは複数作成でき、master のときは A 、 develop のときは B のようなこともできますし、
ワークフロー同士をつなげることもできます。


特定ブランチを除外する
デフォルトの設定だとすべてのブランチを対象にワークフローが始まるようになってますが、特定のブランチは CI したくない場合(iutest の場合は gh-pages)は、「Workflow Editor」の「Triggers」から設定を変更できます。
Push / PR / Tag それぞれにトリガーの設定が可能で、ここでどのワークフローと連結するかも設定できます。

※ exclude 指定ができると良かったのですが…

バッジ
最後にお約束のバッジです。
バッジは「Dashboard」の上の方にある「バッジ」をクリックすると Markdown などのテキストが取得できます。




最後に
今回 iutest では CMake + Xocde build のために Bitrise を使いました。
これであれば正直 Bitrise じゃなくてもできます。(Travis CI や Circle CI は Mac OS ワーカーを使えたはず)

ただ、最初にも書いたように Bitrise はモバイルアプリをメインターゲットにしているので、
それらの開発をしている方は一度試してみてはいかがでしょうか?
きっと、他の CI サービスにはない旨味があるのではないでしょうか。

今回は以上です。では。

2017年5月1日月曜日

[Docker] ENV にコマンドの結果を使えない問題の回避策

Dockerfile の ENV で環境変数を設定する際に、コマンドの実行結果を利用したいと思ったのですが、
現在それはできないようです。

ENV NACL_SDK_ROOT $(find /nacl_sdk -maxdepth 1 -type d -name 'pepper_*')

回避策として、以下のようにしました。

.bashrc に export を書く
RUN echo 'export NACL_SDK_ROOT="$(find /nacl_sdk -maxdepth 1 -type d -name 'pepper_*')"' >> ~/.bashrc

こちらであれば、bash を起動すると環境変数が設定されます。

.profile に export を書く
RUN echo 'export NACL_SDK_ROOT="$(find /nacl_sdk -maxdepth 1 -type d -name 'pepper_*')"' >> ~/.profile

この場合は、ログイン時に環境変数が設定されるので、
docker run hoge bash するときに -l オプションもつけます。
docker run -it hoge bash -l

2017年4月24日月曜日

[Windows][Docker] Host および コンテナの起動をスタートアップに登録

ブログズミ: [Docker] 始めてみたけど躓きまくってるので備忘録として残しておくよ
Docker 始めてみましたが、とりあえず、なので空いてる Windows マシンで動かしてる感じです。

そうすると、マシン再起動することがあったりして、そのたびに Docker を起動するのは面倒でした。
なので、スタートアップに登録してみました。

やり方はとっても簡単です。
「Docker Quickstart Terminal」ショートカットをコピーして、末尾に docker start コマンドを記入するだけです。
(Docker Toobox に付属してる start.sh に引数を渡すと、最後に実行してくれるので、それを利用しています。)
"C:\Program Files\Git\bin\bash.exe" --login -i "C:\Program Files\Docker Toolbox\start.sh" docker start 

あとはこれをスタートアップフォルダにツッコんでください。
簡単ですね^^

今回は以上です。




2017年4月17日月曜日

[CI] Codefresh を始めました



Codefresh というサービスを知ったので使ってみました。
(ちょうど Google Test の互換性テストを Travis CI から引っ越ししようかなと思っていたので、タイミングが良かった)
Codefresh は Docker 対応を売りにした CI サービスのようです。
が、個人的には Docker 使ったことがないですし、iutest のテストでも使う必要がないので、全くもって Codefresh の旨味を使うことがないです。
なので、Docker 的な話は公式サイトや以下のような記事を参照してくださいm(__)m


ともあれ、そこに CI サービスがあれば使うおじさんなので(もはや、手段と目的がごっちゃになってますが)始めて行きましょう。

Pricing
ちなみに Codefresh も (オープンソースであれば) 無料から始めることができます。
フリープランでは並列ビルドなし、Environment も1つだけです。


Environment
Codefresh ではビルドした Docker イメージ(Service)からコンテナを実行することができます。
この実行環境が Environment です。
フリープランだとこれが1つに限定されます。
今回は特に使わないので、省略します。

アカウント作成
アカウント作成をしていきましょう。
最初にログインアカウントとして Github or Bitbucket の選択をします。(今回は Github を選択)


権限要求されるので問題なければ許可しましょう。


アカウント名やメールアドレスが自動で入力されます。変更が不要であれば「NEXT」をクリック。


このあとアンケートが少しありますが、飛ばしてしまっても構いません。


これでアカウント作成は完了です。

サービスの作成
Codefresh では他の CI サービスでいうジョブのことをサービスと表現します。
やることは他の CI サービスとほとんど同じです。

まずは、リポジトリを選択しましょう。



リポジトリを選択したら、サービスを何で構築するかを「YAML」「Dockerfile」「Template」から選択します。
今回は「TEMPLATE」を選択。


プラットフォームの選択画面になるので、条件に合うものを選択します。
今回は「Ubuntu」を選択。


Dockefile が作成されます。
編集はあとでもできるので次に進んでしまって問題ないです。


これでサービスが作成できました。
「BUILD」ボタンを押して実行してみましょう。
テンプレートから変更していないので成功するはずです。



テスト
Codefresh では、作成した Docker image に対してテストを実行することができます。
テストは「Unit Test Script」に記述します。


特に難しいことはなく、コマンドを書いていくだけです。
これで iutest の CI 環境としては完成です。
Codefresh の特徴を活かすのであれば、このあと Launch するのがいいのでしょうが、iutesst はサービスではないのでここまでです。

最後にお約束のバッジ
バッジは「General Settings」のバッジをクリックすると Markdown テキストなどが得られます。




今回は以上です。では。