2018年1月30日火曜日

Visual Studio Code のワークスペース設定で拡張子の関連付けをする

VS Codeで標準の拡張子以外に言語のサポート機能を有効化する方法 - Qiita
拡張子の関連づけ方法は、こちらに書いてあるとおりに、files.associations を設定すれば可能です。
"files.associations": {
    "*.ipp":"cpp"
}

上記記事ではユーザー設定にこの記述をしてましたが、ワークスペース設定に書く場合は、settings 要素の中にこれを記述します。
"settings": {
    "files.associations": {
        "*.ipp":"cpp"
    }
}

ワークスペース設定は、設定(Command + , )を開いたときにタブ表示されますので、そこで編集が可能です。


プロジェクト独自な拡張子を使っている場合は、ワークスペース設定に書いておくと親切ですね。

2018年1月24日水曜日

Sync Settings for Visual Studio Code

Atom から Visual Studio Code に変えたけど設定同期をしていなかったなと思いセットアップしました。
Atom のときは Gist に設定を追いて同期するものを使っていたので、同じような拡張機能があれば〜と思ってたら同じのがありました。

Settings Sync


というわけで早速インストール。



セットアップ
拡張機能をインストールしたら、Gist にアップロード/ダウンロードする設定をしていきます。
まずは、Visual Studio Code を開いて、Shift + Alt + U を押すかコマンドパレットから「>Sync: Update / Upload Settings」を実行します。
すると、ブラウザで Github の Personal access tokens のページが開きます。


ここで作成するトークンを利用して、Gist にアクセスし設定を管理してもらいます。
「Generate new token」を押してトークンを作成しましょう。

アクセス権限の設定画面になるので、「repo」「gist」「user」にチェックを入れます。

ドキュメントによると「gist」のみで良いはずですが、現在はこの3つが必要なようです。
(※作ったトークンの権限は後で変更できるので試してみても大丈夫なので、気になる方は検証してもいいかも)

「Generate token」ボタンを押します。


トークンが作成されますので、こちらをコピーします。


Visual Studio Code に戻って、以下のようにトークンの入力を待っている状態になっていると思うので、コピーしたトークンをペーストして、ENTER。


これで設定は完了です。
設定のアップロード/ダウンロード
設定のアップロードは Ctrl + Shift + U です。
実行すると以下のように出力にログが出ます。


Gist を開いてみましょう。
アップロードされた設定ができていると思います。


ダウンロードするときは Ctrl + Shift + D です。

自動アップロード/ダウンロード時の注意
変更されたときに自動アップロード、起動時に自動ダウンロードするように設定ができます。
ただし、複数環境で同時に使用する場合は、一方の変更が取り消されてしまったりするので注意が必要です。

自分の場合、起動するときだけ自動ダウンロードにしています。
楽なんですが何か変更をしたときにアップロードを忘れるとやり直しになるので注意。
(特に拡張機能インストールして再読込させるときに忘れがち)

手動でやるのが無難かもしれません。。。

ホストを GitHub Enterprise にする
ホストを GitHub Enterprise にする場合は、Visual Studio Code の設定に以下を足します。
"sync.host": "hogehoge.fuga.com",
    "sync.pathPrefix": "/api/v3",
(host にアドレス、pathPrefix はデフォルトから変えてる場合はそれに変える)

設定の手順は同じですが、トークン作成時に開く WEB ページが指定したホストではなく、GitHub のページを開くので注意!
設定としてはちゃんと指定したホストを見に行くようになっているので、自動で開かれるページは無視して GitHub Enterprise の方でトークンを作成し、セットアップしてください。
(これハマりました・・・)

今回は以上。では。

2018年1月15日月曜日

[Travis CI] Resource temporarily unavailable で失敗する問題の回避策

The Travis CI Blog: Trusty as default Linux is coming

Travis CI で Precise を使っていたのですが、EoL とのことなので Trusty に変更しました。
そしたらビルドが盛大に失敗しまくってテンヤワンヤ。。
だいたい解消できたので、その時の対応をブログに残しておきます。
wine を使うジョブが未だ対応中なのです。。一旦コメントアウト中)

Resource temporarily unavailable
一部は apt-get してくるパッケージが変わっていたなど、設定の問題だったのですが、残りのほとんどがログが途中で途切れて exit 1 してました。
その中の、一部のジョブで「Resource temporarily unavailable」が出て失敗してたので、これをヒントに解決(回避)しました、というお話。

以前のワーカーイメージを使う(失敗)
最初にこれを試しました。(結果は失敗です)

これを試したのは、検索したときにこちらの issue がヒットして、そこに最初に書いてあったため。
Large writes to stdout sometimes fail with "Resource temporarily unavailable". · Issue #4704 · travis-ci/travis-ci


方法としては、.travis.yml ファイルに以下の一行を追加するだけです。
group: deprecated-2017Q2


が、結果変わらず。


The Travis CI Blog: The new Ubuntu Trusty 14.04 images are now live!
ここを見たら、sudo: false じゃダメだし、2017/9/1 まで保存って書いてあるので、もう使えない workaround でした・・・

sudo: required にする(意味なし)
そもそも、sudo less にして sudo: false にしてたものの、Precise だと Docker コンテナがなく、sudo: required と同じワーカーで実行されてました。
というわけで、sudo: required にして試してみました。


が、これも結果変わらず


脱線しますが、コンテナが使えるようになってあらためて確認すると、起動が 20 秒超から数百ミリ秒になってました。速くていいですねぇ。
頑張って sudo less にした甲斐がありました。

stdout/stderr のノンブロッキングモードを外す
最初にみてた issue (Large writes to stdout sometimes fail with "Resource temporarily unavailable". · Issue #4704 · travis-ci/travis-ci) のさらに下のほうに、別の workaround があってそこを見ると標準出力(エラー)のノンブロッキングモードを外す方法がありました。

Travis has a new nasty trick: it puts stdout in nonblock mode! · SpiNNakerManchester/SupportScripts@1a4a4b8
こちらを参考に、同じようにブロッキングモードになるようにしてみました。


結果は成功

ログを見ると stderr がノンブロッキングモードになっていたみたいです。


これでほとんどの失敗が解決しました。
この記事が誰かの助けになれば幸いです。では。

2018年1月12日金曜日

新しく無料で使える CI サービスを探しています

Travis CI で wine を使ったテストが失敗するようになって解決するのに時間がかかりそうな予感がしたので、新しい環境(CI サービス)を探すことにしました。
(順番が前後しますが、Travis CI での失敗については来週のブログで話す予定でした)
目的は Travis CI でやっていた mingw + wine のテストを引っ越すことです。

で、自分は結構 CI サービスを使い尽くしているため、"新しいもの" となると割りと探すの大変そうだな~と思ってました。




ないかなーと思ってググっていたらすごくいいまとめがあったので、速攻でブログにしました。


27 Best hosted continuous integration services as of 2018 - Slant

ちょっとこれを参考に探しみようと思います。

2018年1月10日水曜日

AppVeyor のフリーアカウントで定期ビルドが無効になっていたので有効化した

Scheduled builds for free accounts | AppVeyor

最近気づいたのですが、AppVeyor のフリーアカウントで定期ビルドがデフォルト無効になってました。
有料機能になったわけではなく、オプショナル機能として有効化依頼を出せば使えるっぽいです。

定期ビルド機能は、Wandbox の更新チェックに利用してたのですが、2ヶ月ほど停止してました・・・


実際にプロジェクトページに行って、設定しようとするとこうなります。


というわけで、有効化依頼をしました。
連絡手段はなんでも良さそうでした(メール、フォーラムTwitter)。
最初 Twitter で連絡してみたのですが、レスポンスがなかなかなかったので、こちらのフォーラムを参考に同じ感じで依頼を出したところ、すぐに有効化していただけました!


外部サービスから Webhook で定期ビルドしようか、とか
別の CI サービスへの引っ越し、とか
サービス連携サービスで実装しなおす、とか
いろいろ考えましたけど、案外簡単に有効化できたのでよかったです。

ではでは。

2018年1月4日木曜日

せっかく東京に来たので作業カフェ(ノマドカフェ)をまとめていきます

新年明けましておめでとうございます。今年もよろしくお願いします。
さて、私は本日からお仕事です。

東京へ来てもうすぐ3ヶ月になり、日々の生活には大分慣れてきました。
とはいえ、普段行かないところのことは全くもってわからず。
正月は近くで初詣を済まして、ぐーたらしてました。
東京で正月を過ごすのにオススメなとことかあったら教えて下さいm(__)m
(京都市内はバスで大抵の場所に行けたので、その点は楽でしたね。混むから出ないけど…)


2018年最初の投稿は、(東京へ来て3ヶ月しか経ってませんが)憧れの?ノマドカフェ生活の一部を紹介します。ここいいよ!ってお店があったら是非是非コメントください!!



新宿~渋谷あたりが多いですが、たまには遠出もしたいですね。
行ったことがないところは、デフォルトの青色マーカーにしてます。そのうち行きたいところ。
暖色ほど個人的にお気に入りなところです。

のちのち、IFTTT のような連携サービスを使ってチェックインとかできるようにして、訪問回数を自動集計とかできたらなーなんて思ってます。

直近のベストカフェ
「スターバックスコーヒー西武高田馬場駅店」です!
出勤前に立ち寄れるってのが大きいのですが、9割以上電源席を確保できますし、Wifi もあるので完璧です。ただし、長時間の作業はちょっと椅子が辛いかもです。

全くもって万人受けしない情報でしたが、ちょくちょく更新しているのでよかったら見てやってください。
では〜