Beeeat’s log

Beeeat’s log

プログラミングで出くわした知識やツール、日常生活、働き方その他色々なことをメモしていくブログ

BusyBox が提供している timeout コマンドの -t オプションが不要になっていた

BusyBox AWS CodeBuild Linux

きっかけ

CI/CDとしてAWS CodeBuildを使っているのだが、突然timeout: unrecognized option: tで突然失敗するようになった。 失敗したコマンドがドキュメントにある下記のコマンドである docs.aws.amazon.com

- timeout -t 15 sh -c "until docker info; do echo .; sleep 1; done"

原因

色々調べた結果、どうやらtimeoutコマンドを提供しているBusyBoxがv1.30.1になった際に引数の変更があったようだ

そもそも、BusyBoxって何?

そこまで、詳しくないのですいませんが、Wikiから引用

BusyBox は、Coreutilsなど標準UNIXコマンドで重要な多数のプログラムを単一の実行ファイルに「詰め込んで」提供する、特殊な方式のプログラムである ja.wikipedia.org

実際に確認してみた

確認したところ、該当のコミットはこれであることがわかった

timeout: fix arguments to match coreutils

直訳すると、「timeoutコマンドをcoreutilsと一致するように引数を修正」というのがわかる git.busybox.net

対応策

対応策は簡単で単純で下記のように-tを除けばOK。これで、AWS CodeBuildも動くようになった

- timeout 15 sh -c "until docker info; do echo .; sleep 1; done"

UTMパラメーターの値をGoogle Tag Manager(GTM)の変数で取得する

Google Tag Manager Treasure Data GTM

最近、Treasure Dataのタグ(td-js-sdk)をGoogle Tag Manager(以下、GTM)経由で配信することをやっていることがきっかけとなり、GTMの知識が身に着いてきたのでまとめておく。
改めて感じましたがGTM便利ですね。 github.com 今回はhtttps://hoge.com&utm_sns=facebookというURLのutm_snsの値であるfacebookという文字列を取得する方法を例に対象のサービスのURLに付与されているUTMパラメータの値を取得する方法をメモ。

やり方

タグのカスタムHTMLにJavaScriptを書くやり方もあるが、GTM側で変数という機能があるのでそれを使う 要素タイプはクエリを選択。あとは、右上にある保存を押すと簡単にUTMパラメータの中身を取得できる

f:id:bake0937:20181029085823p:plain

※ #(フラグメント)のUTMパラメータを選択したい場合(例としてはhtttps://hoge.com#utm_sns=facebookという場合)は要素タイプをフラグメントに設定するようだ。しかしこちらの記事にあるとおり、一部の広告プラットフォームではサポートされていない等のデメリットがあるようなので今回はUTMパラメータはクエリを想定して設定する
www.idimension.com

これだけで簡単にUTMパラメーターの値が取得できて便利ですね。
これでTreasure DataへUTMパラメーターの値を送信する準備ができました。
今度はさらなるGTMの機能についてやtd-js-sdkについての記事を書こうと思います。

その他の参考記事: https://qiita.com/aqril_1132/items/3e9061d349dc580e4ad7

Realtime Data StudioでGoogle Data Studioで複数ページあるレポートを指定した秒数に自動でページ遷移する

Google Data Studio Chrome 拡張機能

Google Data Studioで複数ページあるレポートを空港の到着ロビーやイベントブースにあるディスプレイみたいに指定した秒数に自動的にページ遷移したくなった。
色々調べてみると、Chrome拡張のRealtime Data Studioというものがあるようだ。

chrome.google.com

使い方

今回はテスト用に2ページ分あるレポートを適当に作り、ビューで表示した時に30秒後に自動的にページ遷移するようにする

1ページ目 f:id:bake0937:20180522020833p:plain 2ページ目 f:id:bake0937:20180522020846p:plain

  1. Realtime Data Studioを GoogleChromeに入れる(Vivaldiブラウザでも入れることができ、動きました)
  2. 作成したダッシュボードにアクセスし、ビューで表示する
    f:id:bake0937:20180522021255p:plain

  3. Realtime Data Studioのアイコンをクリックすると以下のような設定ウィンドが表示されるのでCycle Pagesにチェックする
    今回は、30秒ごとにページ遷移するようにしたいので以下のように設定し、SAVEを押す
    f:id:bake0937:20180522022106p:plain

  4. ページをリロードして30秒待つと次のページへ自動で遷移されます
    (gif画像作らなくてすんません)

これでレポートを全画面表示にすると、指定した秒数に良い感じに自動でページ遷移するようになりました。
イベントブース等でレポートをPCやタブレットに表示して展示したい時とかに使えそうですね。
また、こういうChrome拡張を自由に作れるようになったら色々世界が広がりそうとも感じました。
基本はHTML、CSS、JavaScriptなのかぁ...

GitHubのpermalinkを使ってPull Requestやissueで載せるコードをわかりやすくしよう

GitHub

GitHubでissueやPull Requestに残す時にコードのリンクの貼ったコメントをよくやる。
しかし、こんな感じでコードを選択した状態のURLを f:id:bake0937:20180522005845p:plain こんな感じでリンクを貼ったコメントをすると、もし将来的に該当箇所のコードに対して手を加えた後にこのリンクを クリックすると、おそらく本来選択した箇所とはズレて表示されるので、過去のissueやPull Requestを調べる時にコードが追えない
(しかも、パッと見わかりづらい) f:id:bake0937:20180522012127p:plain

GitHubのpermalinkを使う

GitHubでは、permalinkという機能があり、permalinkは将来的にコードを変更しても、 本来選択した箇所とはズレて表示されることはなく、さらに直接コードが表示される。

やり方

  1. 従来通り、まず1行選択した状態からSHIFTキーを推しながら、選択したいところまでの行をクリックする。 そうすると、横に...という表示が出てくる f:id:bake0937:20180522011013p:plain
  2. ...をクリックした後、Copy permalinkというリンクをクリックするとCopied!という表示になり、 クリップボードにpermalinkがコピーされる。
    ...をクリックするのが面倒なら1.の状態でyキーを押して、ブラウザのURL欄を見ると permalinkが生成されているため、それをコピーしてもOK! f:id:bake0937:20180522011308p:plain
  3. あとは、生成したpermalinkをPull Requestのissueで貼ってみると... f:id:bake0937:20180522012005p:plain

こんな感じでpermalinkにする前のコードのリンクに比べて、明らかにわかりやすくなりました!
普段GitHubを利用している時にpermalinkであることに気づかずに貼ってコメントした時に、
「アレ? 何かよくわかんないけどわかりやすくなってる!」 みたいな感じでよくわかっていなかった機能ですが最近、先輩エンジニアの方に教えて頂いてやっとわかりました!!

参考

公式に思いっきり書いてありました😅
Getting permanent links to files - GitHub Help
Creating a permanent link to a code snippet - GitHub Help

開発用ブランチにMasterブランチの最新コードを取り込む

Git

開発用(作業用)のブランチを切って開発している時に、最新のmaterの更新内容を開発用ブランチに反映したい時がある。 Tortoise-SVNとかだと、確か右クリック→更新みたいなことをすれば、すぐに反映できた気がするが、gitでのやり方をメモしておく。色々調べて実践してみたが、どうやらgit rebase masterをして、git push origin 開発ブランチ名などをすると自分のプルリクエストのcommitの画面に他人のcommitが混ざるみたいだ(3回くらいそういうことをやっちまったので良い加減メモに残す) そのため、GtiHubで自分のプルリクエストのcommitの画面に他人のcommitを混ざらないようにして開発用ブランチにMasterブランチの最新コードを取り込むには以下のようにやれば良さそうだ。

※ もし、作業途中のものでcommit出来るものがあればcommitしておく
# masterブランチへ移動
git checkout master
# git pullでmasterを最新に
git pull origin master
# 開発用ブランチへ移動
git checkout 開発用ブランチ
# mergeコマンドでmaserの内容を取り込む
git merge origin master

これでもし、コンフリクト(競合)が発生した場合は個人的には、

  1. コンフリクトしたファイルはmaster側の更新内容を反映させる(自分の更新内容は消える)
  2. git commit でコンフリクトを解消する
  3. コンフリクトしたファイルに自分の更新内容を反映させる(git diffなどで差分を見ながら行う)
  4. 自分の更新内容をcommitする
  5. git push origin 開発用ブランチ

とやれば、競合は解決、自分の更新内容が反映される GitHub上のプルリクエストでも競合した時に、resolve conflictsボタンで競合を解決できるみたいだが、 個人的にはこっちのやり方がやりやすいなと思った。

「来月もプレミアムに過ごすためのインフラ構成管理ツール入門編」に参加しました。

勉強会 Ansible Serverspec インフラ 構成管理ツール Itamae

先日、Tech-Circle主催の「来月もプレミアムに過ごすためのインフラ構成管理ツール入門編」に参加しました。 techcircle.connpass.com 私はオリジナルのサービスをHerokuにアップしているのですが、その開発環境の構成管理ができるように構成管理ツールを導入してみたいと最近思うようになり、実際に使われている方の話を聞いてみたいとちょうど思っていました。

講師と発表内容(資料)

講師:@bbrfkrさん
発表内容(資料): 発表内容(資料)はこちらにまとめられております。
詳細はこちらを御覧ください。

www.slideshare.net

講座内で出た質問

印象に残ったところだけですが講座内で出た質問はこんな感じでした。

Q1.Serverspecのドキュメントではshould記法を使うべきかexpect記法を使うべきか?

A.基本的には好きな方を使えば良いと思います。

ここは人によっては議論になりそうですね。ちなみに参考程度ですが、Serverspec開発者の方のツイートがこの記事を書いている時に目に留まりました。

Q2.レシピ(playbook)はどのような流れで作るのか

A.レシピ(playbook)の作り方

  1. 検証環境を作る
  2. 手動で構築する(この時に実行したコマンドを記録しておく(コマンドラインツールのhistory機能がオススメ))
  3. Servespecでテストコードを作成する
  4. 作成したテストコードを実行し、結果がパスしたか確認する これで手動構築したコマンドの品質が担保される
  5. 別の検証環境を作る(もしくは検証環境を一番最初の状態に戻す)
  6. 作成したテストコードの結果がパスしたコマンドをレシピ(playbook)化する
  7. レシピ(playbook)を実行し、自動構築する
  8. 作成したテストコードを実行し、結果がパスされるか確認する これで、レシピ(playbook)の品質=手動構築したコマンドの品質になることが担保される。
  9. 本番環境でレシピ(playbook)を実行する!

※レシピをリファクタリングした場合は、リファクタリングしたレシピで自動構築後に作成したテストコードを実行し、結果がパスされるか確認する

レシピの作り方は人それぞれだとは思いますが大変参考になりました。以前、ドットインストールのAnsible入門をやった時に何故あんなキレイな流れでレシピ(playbook)が作れるのか疑問に感じていたのでこの質問を通して何となく腑に落ちました。試行錯誤しながらレシピ(playbook)を作っているのですね。 この他の作り方を周りに聞いてみるのは参考になりそうです。

LT枠

LTで参加された方のslideはこちらです。

Takeshi Kuramochiさん

www.slideshare.net

@setoazusaさん

www.slideshare.net

@ike_daiさん

www.slideshare.net

感想

このイベントを通して、構成管理ツールにチャレンジするモチベーションが上がりました。
itamaeとAnsible、どちらを使うかは悩みますがまずはどちらも軽く触ってみてどっちが自分にとって使いやすそうか模索してみるのが良いのかもしれません。
イベント終了後、@bbrfkrさんにこれから構成管理ツールを入門する人向けのオススメ本を聞いてみたところ「入門Ansible」という本をご紹介頂きました。

出版年数は少し古いですが、基本的な使い方やplaybookの作り方など一通り学べるそうです。
チェックしてみます!

「【学生＆若手エンジニア向け勉強会】エンジニアのためのブログ講座」に参加しました

勉強会

お久しぶりです。 先日、サポーターズ主催の「エンジニアのためのブログ講座」というイベントに参加しました。
今回はこのイベントに参加して得たことや感想を書きたいと思います。

講師と発表内容(資料)

講師:@ktanaka117さん
発表内容(資料): 発表内容(資料)はこちらにまとめられております。
詳細はこちらを御覧ください。
こちらの記事も参考になりました。

講座内で出た質問

印象に残ったところだけですが講座内で出た質問はこんな感じでした。

  • Q1.記事を投稿する際に気をつけていることはありますか

    A.技術的な記事を書く場合は検証用のプロジェクト(環境)を都度作成しています。

    確かに一回試した結果を記事にするのではなく、検証用の環境を作って確認したことを記事にすることで再現性を上げるのは記事の質を上げる方法の一つだと思いました。

  • Q2.実名を使うかハンドルネームを使うのか悩んでいます

    A.基本的にはどっちでも良いと思います。私の場合は、自分のブログを読んでくれた人とイベントでお会いした時に 「あ!あのブログを書いた人ですね!」とわかりやすくするようにしています。

    ここは私もブログの開設前にとても悩みました。個人的にはまずはハンドルネームで始めてみて、ブログを書きながら名前をどうするか決めていけば良いのかなと思いました。

  • Q3.「ブログを始めたての頃」と「現在」で記事の作成時間はどれくらいですか

    A.基本的には記事の作成時間は記事の内容にもよります。ただ、ホントに始めたての頃は2週間くらい掛かりました。現在では早いと1時間。かかっても2,3日くらい。イベントレポートだと早い時で懇親会が始まる頃に投稿している場合もあります。

    これはホントに凄いと感じました。「継続は力なり」というのはこういうことなんだなと率直に感じました。

    感想

    今回、このイベントに参加したことで記事を書く上でのTipsを得ることができ、とても勉強になりました。加えて以下のようなことも感じました。

  • 書きたいことを書きたい時に書く
    自分でブログを始めてみて感じたのは普段何気なく見ている記事は読みやすく、わかりやすいんだなぁと感じました。なので、そういった記事のレベルを目指す!!….のはとても良い事です。しかし、まずは書きたい時に書きたいことを投稿し、継続していくことで段々と記事の質を上げていくのが良いのかと思いました。小さい内容でもまずは気楽に投稿してみる。もしかすると普段見ているブロガーさんの一番最初に投稿された記事から最新の記事までざぁーっと見てみることで記事の書き方がどのように変化していったのかを見てみるのは参考になるかもとふと思いました。

  • 仲間に見てもらってみる
    もし、投稿する記事に自信がない場合は気の合う仲間を数人集めてグループを作って、記事を見てもらうのも手なのかと思いました。 情報共有サービスとして、esa.ioやQiita:Teamなどがありますが、 私の場合は、Kibelaというサービスを利用しています。

    Kibela - 個人の発信を組織の力にする情報共有ツール

    現在(2017/04/02時点)は5人までのグループなら無料で作成可能で、Markdown記法で記事が書けるようです。 「この記事はこのまま投稿できそうだな。この記事はみんなに見てもらうか」といった具合にしていくうちに段々と自分で記事を投稿できるようになっていくのかもしれないですね。

ということで、今回得たことを徐々にこのブログに反映させていこうと思います!

今回参加した勉強会のページはこちらです。