Cloud Automator のAPI に後処理が追加されたのでCLIにも追加した件 #cloudautomator #golang #swx
気がついたら
Cloud Automator
のAPIが後処理に対応していました。
Cloud Automator API | /post_processes
https://cloudautomator.com/api_docs/v1/api.html#後処理
APIの詳細は上記の公式サイトを確認してもらうとして、数も多くなさそうなので作ったCLIにも追加しようと思います。
追加した
というわけでv0.1.1
でCloud Automator
APIの後処理に対応するコマンドを追加しました。
下記のようなコマンドでsqs
の後処理を新規に追加することができます。
$ ./ca post-process create \ --name "後処理テスト" \ --service sqs \ --parameters sqs_aws_account_id=1\ ,sqs_queue="example-queue"\ ,sqs_region=ap-northeast-1
--parameters
はobject
型ですので、他のobject
型と同様に
“APIのパラメータ名=値” の形で指定して、パラメータ同士は",“で繋いで表現してください。また、配列を表現する場合は”APIのパラメータ名=値,値,値“のように値を”,“で繋いで表現してください。
まとめ
- 数が多くないので手作業でもなんとかなったが、やっぱりAPI定義から自動で作れるような仕組みは必要
- 今回もAPIドキュメントにTypoがあり、コピペしてそのまま使ったら404で少しハマった・・・
- APIドキュメントのどの部分が更新されたのかわからないので、とりあえず全部目を通して変更点を探す必要があった
- 新規追加はわかりやすいが、既存のAPIにパラメータの追加とかは数が多くなったら見て確認するのは難しい
- テストがないので既存のコード変更後の確認が大変だった
- 足りないところやできていないところを何とかしたい
以上になります。
OneTab のTabリストを整理するCLI をgolang で作ってみた #golang #onetab
便利な
みんな知ってるGoogle Chrome 拡張機能のOneTab
ちょー便利なのでよく使うんですが、気軽に使えすぎてOneTab
のリストがどんどん膨れ上がってきませんか?
・・・と、こんな感じでどんどん増えて行くわけですが
OneTab
に同じURLが登録されているOneTab
側にリストを整理するような個別な機能がない- UI上でマウスを使って移動や削除はできる
- 数が多くなるとこの操作も大変
- リストの登録件数が多くなると重くなる
- PCのスペックにもよるが手元だと2,000件ぐらいから重い
- 登録や削除が重くなる
というわけで、他に需要があるとは思えないCLIを作ってみました。 自分でも使ったのも1回きりというね・・・
作ったのは
使い方は簡単でOneTab
からURLの書き出しで出力されるリストをファイルに保存して
コマンドラインで保存したファイルを指定してコマンドを実行するだけ
$ ./tlc run "your_file_path" -w
-w
オプションでHTTPリクエストでURLがアクセス可能かどうかをチェックします。
やってること
すごい単純なことしかやってませんが
OneTab
から書き出したURLリストを保存したファイルを読み込む- 読み込んだファイルからURLをキーにして
URL文字列が完全一致
するものを削除 - URLで削除したリストを今度は
名称文字列が完全一致
するものを削除 -w
オプションが指定されていた場合、URLがアクセス可能か(status == 200)かどうかチェックする
だけなので、当然ですが
- URL文字列が異なり同じWebページだった場合は違うとみなされる
- 例えばSNSからのリンクがわかるようなパラメータ付きとパラメータ無しのページなど
- 名称文字列が同一でURLが異なる場合は、同一とみなさせる
- すべてのページで同じ名称がつけられているページなど
- URLのアクセスチェックでステータス200以外の場合はアクセスできないとみなされる
- ブラウザと同等の判定はしていないため、ブラウザで見れるのNGと判定される場合がある
という制限?問題点?はあります。
ダメだったこと
簡単にできそうで、できなかったことを書いておこうかと。
- URLからHTMLの内容を取得して、取得した内容をハッシュ値で比較
- セッションIDや広告IDなどのアクセスするたびに異なる値がHTMLに含まれることがある
- これによりハッシュ値が同一のページでも毎回異なる
- URLにアクセスできるかをブラウザと同等の判断で行う
- ブラザと同等となるとブラザそのものでチェックした方が早い
- 現状ではCDNでJSを使ったリダイレクトなどしていると上手く判定できない
- リダイレクト回数が多い場合に上手く判定できない
そもそもよく考えたら、どれもダメだよねーとw
まとめ
- とりあえず動くところまでは出来ている
- golangって便利ですなぁ
- リストの重複を除く仕組みをもうちょっと考える必要がある
- 今ならGoogle Chromeのヘッドレスモードを利用できるならした方が良さそう
- CLIにしたけどWebでできた方が手軽そう
- というか
OneTab
側になんか整理する機能があってもいい気がする - そもそもこんな使い方している人が他にいないかもしれないw
以上になります。
GitHub のREADME にgif 画像を表示する1番簡単な方法 #github #gif
画像を
GitHubのREADMEにgif画像を貼り付けたいってことってありますよね。今回作ってみたこれ↓でも1枚だけ貼り付けたい感じになりました。
当然Google先生でgithub readme gif
とか入力して調べてみるわけですが
github readme gif
https://www.google.co.jp/search?q=github+readme+gif
どーやら↓の2つの方法が主流っぽい感じ?
1
の方法は確かに手軽だけど、それだけのためにbranchが残り続けるのが個人的には好きじゃないので却下。これするなら素直にmaster branchに画像ファイル追加するなぁ
2
の方法は利用したこともあるし、Wiki使ってドキュメント書くならアリだと思うんですが・・・今回はファイル1個なのが迷うところ。
2
と似てるけどGitHub Pages
でも同じようなことは出来ますよね。こっちもページ公開するならアリだと思うけど、今回はファイル1個・・・
もっと手軽に
画像1個で画像自体のバージョン管理が必要ないので、もっと簡単に出来ないかなぁーと。そこで思いついたのが以下の方法になります。
- GitHubのリポジトリにissueを起こして、そのissueに画像を貼り付ける
- issueの画像はMarkdown記法でリンクが記述されているのでそれをコピー
- 画像を貼りたいREADMEにこのリンクを張り付ければOK
今回はこの方法を利用しているので、実際にissueに貼った画像を使ってREADMEに画像を貼り付けています
この方法の良いところ
- issueを作って画像を貼り付けるだけなので手軽
- 余計なbranchが残り続けることもない
- issueなので、そのissueのためにbranch切ってpull request起こせば、なんでこうなってるのかがあとからもわかる
- そもそもREADMEを更新するのでpull requestを起こすはず
- issueなので対応が終わったらcloseしちゃえば良い
- 画像を差し替えたい場合も、差し変えるためのissueを起こせば同様の手順でOK
- issueの画像リンクがMarkdown記法なので、そのままコピペできる
- 何と言っても手軽
ということで、手軽で良い感じかと。 何かの参考になれば。
以上になります。
日経Linux2017年9月号にちょっとだけ載った件 #ITpro #swx #aws
きっかけは
先日↓退職Blogをアップしていたおねーさんが
社内Slackで
「Amazon AIネタで雑誌に書いてみませんかー?締め切り近いけどw」
的な募集をかけていました。なんてゆるいw 素敵すぎる!
Amazon Pollyなら以前にアドベントカレンダーでネタにしたこともあるのでワンチャン!と思いとりあえず手を挙げてみました。
そしたらありがたいことに執筆させてもらえることになりました。
書いたのは
記事を書いたのは↓の「日経Linux2017年9月号」で、内容はAWSのAIサービスについてになります。
実際にはAmazon PollyとAWSの概要についてを担当しました。
書いてみて
- 書くのにあたってAWSサイトを色々見たけど、ドキュメントが多くてしっかり書いてあるのを再認識
- というか、これWebが見らえる環境ならわざわざ紙にする必要があるのかどうか気にするレベル
- 規定の文字数にまとめるのは大変
- 雑誌という限定される中で、編集の方がいろいろ工夫されているのがわかった
- どの業界でもユーザーにどうやって価値を届けるのか?に違いはないんだなぁーと
- こちらが雑誌という媒体に慣れてないため、何度か手間を取らせてしまった
- 次回からもうちょっと色々考えてこちらから提案できるようにしたい
- 知ってるつもりでも、まとめたり再度調べなおしたりすると色々と発見もあり自分でも大変勉強になった
- とにかく良い機会だった
まとめ
- 気になったら是非お手にとっていただければ!
- 日経Linuxに小さいけど自分の名前が載るとかテンション上がる!
- おねーさんと最後にお仕事っぽいことが出来てよかった!
- 雑誌編集の人の雑誌に対する姿勢にいろいろ学べた
- 雑誌だろうと、Webサービスだろうとやっぱりユーザー視点ってすげー大事だなと
- もっと他の業種の人とも一緒に仕事できると、こういう気づきがありそうなので機会があれば積極的にやっていきたい
- 文章書くのに慣れてないから時間がかかった
- けど楽しいので文章書くのも機会があれば積極的にやっていきたい
- こういう良い機会に関われてよかった
- ↑少しですがちゃんと
Cloud Automator
の宣伝もしておりますw
以上になります。
Cloud Automator のAPI を呼び出すCLI をgolang で作ってみた #cloudautomator #golang #swx
知ってますか?
Cloud Automator
というサービスがあるんですが・・・知ってますか?
簡単に言うと 画面からのカンタン操作でAWSの運用を自動化 することが出来るサービスかなーと。画面から操作できるのは大変便利なのですが、大量の定型処理を行う場合にはやっぱりしんどいですよね・・・
しかし、最近Cloud Automator
のAPIが公開されました。
Cloud Automator API
https://cloudautomator.com/api_docs/v1/api.html
APIはあるけど・・・
APIが公開されていれば、プログラムの中から使えるから画面からの操作じゃなくてもなんとかなる!と、現実はそんなに簡単ではないのでなかなか難しいところもありますよね。
じゃーターミナルでcurlを使って頑張ればいいじゃないか!と、思うじゃないですかー
・・・黒い画面大好きな国の人でもちょっと大変という感想がっ!
SDKとかCLI何かがあれば多少は違うのかなぁーと思いつつ、Cloud Automator
のサービススタンスとしては、CLIは難しいラインなのかなぁーとも思いつつ
そこで
仕事で考えるからややこしい話になるんだなぁーと気がついた & 最近議事録や予定調整などしていて、コードも書いてなければAWSも触れてないと気がついたので、せっかくだから公開されているAPIドキュメントを見ながらCLIを作ってみることにしました。
CLIを作るにあたって、身近なCLIを参考にするのが良さそうなので以下の2つを色々見てみました。
自分が使うだけなので、手元のMacとAmazon Linuxで動けばいいのでPythonって選択肢もアリでしたが、やっぱりここは仕事では書く機会がありそうもない大好きな言語であるgolangで作ってみようかと。
golangにはcobraというちょー便利なパッケージがあるので、もちろんこれを利用して作っています。
他にも色々と便利なパッケージがあり、今回は
なんかを利用しています。
また、上記のようにgolangのパッケージをまとめているサイトがいくつかあるので、こういうサイトを利用して必要なパッケージを検索出来るのはありがたいです。
とりあえず
自分用ということで作っていて、とりあえず動くところまではできた感じです↓
golangのクロスコンパイルでMac/Linux/Windows用のバイナリファイルは作りましたが・・・MacとLinuxは動くのは確認しています。Windowsは動かなかったらゴメンなさいw
インストールとか操作については、README.md&ヘルプコマンドの表示で何とかしていただければ・・・
分かりにくいところ
Create Job のAPIで受け取るパラメータのrule_valueとaction_valueが直感的ではないので、少々分かりにくいかもしれません。
Cloud Automator API
https://cloudautomator.com/api_docs/v1/api.html#ジョブ-post
上記のAPIドキュメントを確認すると、rule_valueとaction_valueについてはobject型の値を渡さないといけないようです。
object型はJSONになるのですが、CLIでJSONは結構大変なので今回は以下の例のように対応しています。
$ ./ca job create \ --name "ca job create exsample" \ --aws-account-id 1 \ --rule-type cron \ --rule-value hour=2,minutes=0,schedule_type=weekly,weekly_schedule=monday,friday \ --action-type create_image \ --action-value region=ap-northeast-1\ ,specify_image_instance=identifier\ ,instance_id=i-xxxxxxxxxxxxxxxxx\ ,generation=1\ ,image_name=exsample-ami\ ,description="Job Create Exsample Cloud Automator CLI"\ ,reboot_instance=true\ ,additional_tag_key=name\ ,additional_tag_value=exsample\ ,add_same_tag_to_snapshot=true\ ,trace_status=true\ ,recreate_image_if_ami_status_failed=true
–rule-value hour=2,minutes=0,schedule_type=weekly,weekly_schedule=monday,friday
“APIのパラメータ名=値” の形で指定して、パラメータ同士は",“で繋いで表現してください。また、配列を表現する場合は”APIのパラメータ名=値,値,値“のように値を”,“で繋いで表現してください。
作ってみて
- golang はやっぱり楽しいねーもっと使えるようになりたい
- 各種パッケージで色々できるのは楽でいい
- SORACOMさんのCLIはAPI定義からSDKなんかと一緒に自動生成みたい
- 手で組んでも作れるけど、同じようなコードになっていくから自動生成は幸せになれそうで素敵
Cloud Automator
のAPIも確か API Blueprintを使っていたはずなのでワンチャンあるかも?
API Blueprint | API Blueprint
https://apiblueprint.org/
- object型をCLIで表現するのに困った
- AWS CLIの引数指定の仕方を参考にしてみたが、APIパラメータを知らないと使えない感じもするので悩ましい
- 自分用に作ったのでテストがなかったり、コメントだらけのソースだったりすのでなんとかしたい
- Circleci2.0を使ってみれたのはよかった。速くてすばらしい
- Codeshipも気になるので時間があるときに使ってみたい
- golangで作られたツールのリポジトリを見ると、AppVeyorを利用してWindows環境でテストとビルドをしているところも多いみたいなので気になる
- 使ってみたかったslideshipをやっと使えた
- Markdownでサクサク書けるのは便利
- 簡単に作れるので使っていきたい
- APIドキュメントが間違っている可能性?
Cloud Automator API
https://cloudautomator.com/api_docs/v1/api.html#ジョブ-patch
- API定義からAPIとドキュメントが生成されていない?
- ドキュメントだけ間違っている場合は、このドキュメントを元に作っているので間違った仕様になってしまう
- 上記の場合だとedit処理なのに、id意外も必須とされている・・・
まとめ
- 楽しいのはやっぱり大事だよね
- 手を動かして作っていかないと知らないことも多くなってる
- 自分用でもちゃんと最初からテスト書こう
- もうちょっと頑張ろうと思った
以上になります
Microsoft Azureオンライントレーニングをやってみた #microsoft #azure #mooc
AWSは好きで触る機会も多いのですがここのところ他のサービスやプロダクトはなかなか触る機会がありませんでした。
これではイカン!と思い今回は時間を作って Microsoft Azure
を触ってみました。
なぜAzureか?
先日のGoogle Cloud Nextに参加して、時間があるときに触るならGCPだなーと思っていたんですが・・・
みんな大好きガートナーのマジッククアドラント2017年版のIaaSでAWSに続き2位がAzureだと。
加えて、AWS技術者のためと記載があるオンライントレーニングがあるとのことだったので触ってみる事にしました。
オンライントレーニング
Microsoft Azure
を触ってみるとは言っても、何か急いでやることがあるわけではないので今回はマイクロソフト社が用意している無料のオンライントレーニングを利用してみました。
Azure Training Courses | Microsoft Learning
https://www.microsoft.com/ja-jp/learning/azure-skills-training.aspx
たくさんあるオンライントレーニングの中から、
AWS の専門家のための Microsoft Azure
というわかりやすい名前のものにチャレンジしてみました。AWSはSAアソシエイトしか持ってないので全然専門家ではないのですが・・・
AWS の専門家のための Microsoft Azure | Microsoft Learning
https://openedx.microsoft.com/courses/course-v1:Microsoft+AZURE213x_JPN+2017_T2/about
当然この他にも無料で受講できる多数のオンライントレーニングがあり、今回利用したオンライントレーニングと同様に日本語化されているものも多いので、ご興味ある方は一度見てみることをおすすめします!
次はオンライントレーニングを受講するために必要なアカウントを取得していきたいと思います。
microsoft learning accountの取得
AWS の専門家のための Microsoft Azure | Microsoft Learning
https://openedx.microsoft.com/courses/course-v1:Microsoft+AZURE213x_JPN+2017_T2/about
上記オンライントレーニングサイトで利用するアカウントになります。登録はもちろん無料で入力項目も多くないのですぐに登録できると思います。
登録が完了したら今回受講するコースのAWS の専門家のための Microsoft Azure
を選択して受講ができるようにします。
このトレーニングサイトはOSSで提供されているOpen edX
というプラットフォームを利用してAzure上で動かしているようですねー
無料のAzureアカウントの取得
上記のサイトから登録すると
- ¥20,500の無料クレジット付与
- 30日間の完全無料期間
- 無料期間中の支払いはなし
の状態でAzureを使い始めることができるようです。 クレジットの付与とか期間限定での全サービス無料はすごく良いですねー
30日間の期間が終了しても無料枠が設定されているサービスは複数あるので、継続利用ができるのは助かりますね。
登録するにはクレジットカード
が必要になります。これはサイト上にも記載がありますが課金のためではなく、ID認証に使用されるようです。
また、登録確認のコードがSMSで送られてくるためSMSを利用できる電話番号が必要となります。
もしMicrosoftアカウントを持っていない場合には、まずMicrosoftアカウントの取得が必要となります。
ホーム - Microsoft アカウント
https://www.microsoft.com/ja-jp/msaccount/default.aspx
登録が終了してAzureポータルにログインすると、クレジットが付与されていることを確認することができます。
以上でアカウント関係の準備が終わったので、次はいよいよ本題であるオンライントレーニングを進めていきたいと思います。
オンライントレーニング 実践編
オンライントレーニングサイトにログインして、今回受講するAWS の専門家のための Microsoft Azure
を選択します。
あとはCourseタブを選択して、ドキュメントを順番に読み進めていくことでトレーニングを進めることができます。 ドキュメントはモジュールと言われる単位で章に分けられていて、各モジュールごとに1つのテーマを学習できるようになっています。
取得したAzureアカウントを利用するような部分はラボと呼ばれていて、基本的にはドキュメントに沿って自習していく形になります。
また、説明の動画が用意されていることがあり、動画自体は英語ですが動画横に字幕として日本が表示されているので、個人的に英語に弱いのでとても助かりました。
オンライントレーニングの最後には最終評価
として、これまでのトレーニングで得た知識をチェックする選択式の質問があります。
すべての質問に回答すると、最後にスコアが表示されます。 オンライントレーニングの終わりに任意回答のアンケートがあり、それですべてのオンライントレーニングが終了となります。
オンライントレーニングの詳細な内容については、受講して体験してもらうのが良いと思うので、ぜひチャレンジしてみてください。
まとめ
個人的によかったところと、もうちょっとカイゼンしてもらえたら嬉しいなーと思ったところを記載してみました。
よかったところ
- ドキュメントが細かいところまで詳しく書いてある
- 関連するドキュメントなどにリンクされている
- モジュール単位で分割されているので、知りたい情報や学習したい部分がわかりやすい
- 最後に理解度を試せるのは良い
- Azure Active DirectoryやAzure Resource Managerなど、知らないことも多く勉強になった
- Azure Resource Managerが便利で素敵
- AWSとAzureの比較があることで理解しやすい部分もあった
もうちょっとカイゼン希望
- アカウント取得がちょっと面倒くさい
- オンライントレーニングならSandbox的なところで出来ると嬉しい
- 日本語化がおかしなところがある
- Azureのアイコンとサービス名を覚えるまで大変
- 最終評価で間違った問題だけを見られるとか工夫が欲しい
- もっと言うと間違った問題の正解がわからない
- 間違った問題の正解を表示するか、モジュールのどの部分を学習しなおしするのかリンクなりで案内してほしい
- 復習を行うときに便利だと思う
- CLIの実行がWindows OS前提っぽい?のはちょっと残念
- Linux仮想マシンへの接続は、Windowsより若干面倒に感じる
- Windowsと同じぐらい簡単に出来ると嬉しい
とにかくドキュメント量が多く質も素晴らしいので、丁寧に読んだりリンクされている先まで読んだりしているとなかなかの時間がかかります。
このコースを最大限に活用するため、各モジュールの学習に平均 3 ~ 4 時間をかけることをお勧めします。
と、最初に書かれていたので平均合計時間は 3 ~ 4 時間×6モジュールで18~24時間
かかる想定のようです。
で、実際にはどのぐらい時間がかかったのか?という所ですが・・・今回は細かく計測してないので正確ではないのですが、だいたい20時間前後ではないかと思います。
最初の方は細かくドキュメントを追っていたので思ったより時間がかかった印象で、慣れてきた中盤は引っかかる部分だけ読み込む形になり、Azure Active DirectoryやAzure Resource Managerなどの全然知らなかった項目で、また時間を使った感じになりました。
進め方は人それぞれかと思いますが、AWSの考え方と似ている部分があったり、以下のようにAWSとの比較をしてくれている資料が出てくる部分があったりとしますが、比較で覚えるのではなくAzureが持っている特徴を理解していくのがいいのかなぁーと感じました。
自分のペースで進めていけるので、トータル時間はそこそこ必要ですが無目的にAzureを触るよりは断然お勧めできます。私個人としてはAzure Active DirectoryやAzure Resource Managerのモジュールは大変勉強になりました。
もしAzureアカウントを取得するのが面倒であれば、一旦オンライントレーニングのアカウントだけでも良いので取得して、まとめられた豊富なドキュメントを読んでみるのがいいのではないかと思いますので、ぜひお試しください!
以上になります。
社内のLT大会で「期待値コントロール」について話してみた #swx #lt
今所属しているサーバーワークスでは毎週金曜日にLT大会を開催しています。
発信力強化と発表に慣れるために基本的には全員が発表対象になっています。
今回はLT Advanced Generation !
と称して3チームに分割されて対抗戦として発表することになっています。
これまでの社内LTに関しては以下を見ていただければ、雰囲気をわかってもらえるかと思います。
決まりごと
- テーマは
仕事のはなし
- 持ち時間は5分
- 発表後に投票により順位付けされる
- 全員が最低1度は発表する
チーム対抗戦で発表に投票で順位付けされるのがあるので、好きに発表できるわけじゃないのが難しいところ・・・
過去の発表資料や動画を確認すると自由な人もちらほらいらっしゃいますがw
今回は
今回は技術ネタが間に合わなかったので、個人的にはあまり話す機会のない少しエモい話しをしてみました。
発表中は
さて、今回の発表中は エモい
という言葉を聞いたことがない/使ったことがないという方が数名いて、ちゃんと説明しなかったために伝わらなかった部分があったので、次の機会にはもうちょっと丁寧にいろいろ伝えないとダメだなぁーと
まとめ
- 慣れないテーマで話すときはいつも以上に資料も話も丁寧に
- 意識していろいろやることは重要
- LTのネタ集めは計画的に
宣伝
LTを含めてサーバーワークスのことが気になったら、お気軽にお問い合わせください。オフィス見学もできますので是非お越しください!
以上になります。