Shinji Yamada

このエントリーは 3-shake Advent Calendar 2022 19日目の記事です。dogggggoさんによる Config Controller でポリシー制御をしながら Google Cloud のリソースを管理するでした。いきなりですが、Reckonerをご存知でしょうか。3-shakeが提供しているノーコード型ETLツール/データ連携ツールです。ベンチャー企業の課題Reckonerに触れる前に経緯や前段の話を少しします。Reckonerを触ってみるさぁReckonerを触っていくぞ！となったものの、いきなりチーム単位で導入して使っていくのは難しいというのは経験上わかっていました。新しいことやるのにパワーは必要です。最初が肝心なので勢いよく開発メンバーのいるSlackチャンネルに突撃しました。ユーザー目線でReckonerを触ってみてわかった機能は以下。接続できるアプリケーションがあらかじめ用意されている接続できるアプリケーションは認証情報を設定するだけでデータを引っ張ってくることができる対応していないアプリケーションやサービスはHTTPリクエストを書くことができるHTTPレスポンスはcsvやJSON形式で扱うことができ、JSON Pathsでパースすることができる接続できるアプリケーションにはGoogle Spreadsheetを始め、DWHやDB、KintoneやSlackなんかも使えたりします。いくつかのHTTPリクエストを試してみて認証付きAPIを叩けることが確認できたのでサンプルで何か作ってみようかなーと考えたのですが、情シスのHello Worldをやることにしました。GitHub名寄せ表です。GitHub名寄せ表をReckonerでつくってみるではお題が決まったところでさっそくつくっていきましょう。GitHub APIを叩くGoogle Spreadsheetに書き込むGitHub APIを叩くところを用意Reckonerのワークフローを開き、HTTPを配置すると入力画面が出てくるので必要な情報を入れます。必要なヘッダについてはこちら。            APIエンドポイントやヘッダのパラメータ            JSON Pathsはこんな感じで書きますプレビューで設定したパラメータでレスポンスが受け取れているかが確認できるので、よければ保存しておきます。            APIリクエストが成功すれば結果が表示されますこれでGitHubのmembersが取れるようになりました。Google Spreadsheetの準備まずはGitHubアカウントを書き込むためのGoogle Spreadsheetを準備しておきます。            スプレッドシートIDはGoogle SpreadsheetのURLから取得したものを入れます            APIリクエストが成功すれば結果が表示されますOrganizationに入れたGitHubアカウントを追記するようにするしかしながら、ここまでで用意したものだとAPIで取れたデータを毎回上書きすることになってしまって使い物になりません。ReckonerはETLなのでデータの加工も当然ながらできます。今回はGoogle SpreadsheetとGitHub APIの差分を取って、それをInsertするようにします。            変換の差分機能を使います差分機能を使うことで新たにInviteされたGitHubアカウントを抽出することができます。            データ取得 → 差分 → Insertのフロー完成こうすることで日々運用でOrganizationにGitHubアカウントを追加してもSpreadSheetに書き込まれます。            InsertされたGitHubアカウントにメールアドレスを添えてあげれば名寄せ表は完成見事ノーコードでGitHub名寄せ表がつくれましたね。最初は使い方を覚える必要がありますが、それさえ出来てしまえば欲しいデータが簡単につくれました。いかがでしたでしょうか。簡単ではありますがETLツールReckonerを紹介しました。無料トライアルにチャレンジしてみてください。新料金プランが用意されたようなのでこちらもチェックしてみてください。

Reckonerを使ってGitHub名寄せ表をつくってみた

先日まで面白法人カヤックに勤めていました。転職の経緯も書こうと思ったのですが、内面の変化や会社との関係性など多岐に渡りけっこうなボリュームになりそうだったので分けることにしました。転職のためにやったこと久しく転職活動をしておらず、ポートフォリオや職務経歴書というものがなくどこから手を付けたらいいのやらという状態で、つまりは自分の整理ができていないところからのスタートでした。また、Wantedlyの内容を充実させたことにより少しずつスカウトをいただく機会が増えました。転職活動を振り返って転職活動を始めるまでは沈んでいたこともあり、スカウトをいただいただけでも大変ありがたかったです。ありがたいことに合計17ほどスカウトをいただきました。多いのか少ないのかはわかりませんが、こんな自分にも興味を持ってくださって素直にうれしかったです。PCのキッティングやアカウント管理など日常業務をやる担当はいるコーポレート部門の社員が情シスを兼任(情シスは未経験)情シス部門を立ち上げたいカジュアル面談といいつつ、半分は相談のような面談もあり情シスで悩みを抱えている会社がたくさんあるという現状を知るきっかけにもなりました。それは、「情シス担当者を育てられる環境をつくること」です。そして、自身のチャレンジしてみたいこととニーズがマッチした会社と出会いました。転職先とこれからやっていきたいことその出会った会社というのはスリーシェイクです。SreakeやSecurify,Reckonerといったサービスの運用のお困りごとを手助けできるサービスを展開しています。スリーシェイクは現状100人に満たない規模で情シスには若手が1人います。PCキッティングやアカウント管理など日常業務で手一杯情報システム部として見たときにできていないところを強化していきたいそれをやるのに何をやっていけばいいかわからないという感じでした。最後にこれをお読みいただいた方の中には前職から筆者を知っていただいている方もいるかもしれません。あいも変わらずやっておりますので、何かあれば(もしくは何もなくても)遊びに伺います。お気軽にお声がけください。

10年ぶりに転職しました

どうも、ご無沙汰しておりました。Hugo Themeの変更ブログのホスティングをGAEからCloudflare Pagesに移行記事の管理をbitbucketからGitHubに移行Google Analyticsの対応記事内の手入れHugo Themeの変更どこから手を付けようかなと整理したところ、今まで使っていたThemeがmarkdown記法に対応していなかったというのもあって見た目のところから変えることにした。hugo-theme-stackこのThemeは見た目がすっきりでコンテンツが並べやすそうだったので選びました。今回はフロント自体はさっくり終わらせたかったのでなるたけシンプルなものにしています。ホスティングをGAEからCloudflare Pagesに移行GAEにした経緯はこちらに書いてあるのですが、もともとGCSでホスティングしていたのをhttps化できればよかったんですが、ロードバランサーを置くとお金がかかりそうだなということでGAEに移行していました。AWS AmplifyCloudflare PagesGitHub PagesちなみにこれらはJAMstackホスティングに類するサービスです。各サービスは無料枠、もしくはローコストで運用できるという魅力もあるためどれもよさそうでしたが今まで使ったことがないという理由でCloudflareを使ってみることにしました。Cloudflare Pagesではリポジトリとブランチを指定するだけですぐにエンドポイントを払い出してくれるので5分とかからずに初期設定が完了できました。また、Cloudflare Pagesは静的ジェネレーターを使用する前提になっているので、Build configrationsで普段使っているFrameworkを選択してあげるだけでOKです。リポジトリをBitbucketからGitHubに移行ブログ記事の管理は長らくBitbucketを利用していたのですが、ブログを書き始めた当時は無償でプライベートリポジトリを使えるのがBitbucketしかなかったからでした。いい感じにcloneしていい感じにpushするとできそうだなというのはわかっていたので以下を参考にしつつ移行しました。How to migrate from Bitbucket to GitHubGoogle Analyticsの対応ここまできてようやくリニューアルの当初の本題なんですが、hugo-theme-stackはGA4に対応しているようなのでconfigにGA4の測定IDをセッティングすればそれだけでOKでした。googleanalytics = your measurementID記事内の手入れ最後が何気に大変だったのですが、書き溜めていた記事の記法が統一されていなかったり目立つところがいくつかあったのでついでにやってしまいました。lists記法の統一画像がlocalだったりGoogle Driveにホスティングしてたりしたのをlocalに統一shortcodeを整えるあとはフォントがデフォルトだと日本語ではないのでReferenceを見ながらlayoutを追加。Custom font family for article content最初はGA4対応どうするかな〜から始まったブログリニューアルでしたが、こまめに手入れしていればこんな大掛かりにならずに済みましたね…ブログの運用自体がsandboxというところもあるので、これを機に年単位でガッとやらずに小さい単位でやっていきたい所存です。

ブログを久しぶりにリニューアル

builderscon2019はスタッフ参加でもめちゃくちゃ学びがあった

いやー、今回のbuildersconも楽しかったですね〜！さっそくですが、今回のbuidlersconでもたくさんの刺激をいただけたので、その感想などをとりとめなく書き留めておきます。カンファレンスに思うこと今回のbuildersconについてあれこれ書く前に3年くらいこの手のカンファレンスに参加してきて感じていることについて少し。・ 失敗体験、そこから得た学び・ 苦悩したプロセス・ 検証における自分なりの答えみたいなのが特におもしろいと思っている。個人的によかったセッション前夜祭、本編含めどのセッションもとても楽しませていただきましたが、その中でも個人的によかったと思うものをいくつか紹介します。[知らなかった、時に困るWebサービスのセキュリティ対策]こちらはGMOペパボ株式会社 @tnmtさんのセッションです。siteslide何がよかったって、会社で起こった不正アクセスの情報漏えいについて誠実に内容を発表されてたことですよね。[つらくないマルチテナンシーを求めて: 全て見せます！ SmartHR データベース移行プロジェクトの裏側]こちらは株式会社SmartHR @purintaiさんのセッションです。siteslideSmartHRのエンジニアの方と話す機会があって、その時にもマルチテナントで苦労している、というお話を聞いたことがあってその全貌が聞けるというので楽しみにしていました。[なぜ私はキーボードを作るのか]こちらもGMOペパボ株式会社の方で@j_o_lantern0422さんのセッションです。siteslide私も自キ勢なのでセッションが楽しみと言うより他社の自キ勢の方と知り合えたのがよかったです。全体を通しての感想テーマの一つとして「ギーク達のお祭り」となっているので、やっぱり濃い内容のセッションが多くて、刺激と知見が得られるのは本当レベル高い。よかったことアフターパーティーでのことなんですが、懇親会でメンターとかマネジメントとか評価とかの他社の話が聞けて最高すぎたしそういうセッションを聞きたい人がビルコンに来る層にわりと居そうだなと思ったので何かバリューを出せるようにやっていくかーという決意表明— jigyakkuma (@jigyakkuma_) September 7, 2018ということがあって、@shiba_yu36さんと互いの会社において包み隠さず濃い意見交換できたのがめちゃくちゃありがたかったです。スタッフへのフィードバック牧さんがスタッフに対してもフィードバックほしい！と渇望されていたので書きます。強い人にベストトークの票が偏りがち問題は新人賞(初めてbuildersconで登壇した人の最多得票)みたいな枠でも設けたらいいのでは、というアイディアメインホール入口に受付があるのでどうしても混雑しがち(構造上しゃーないとも思う)ノベルティの水は置いてたら喉乾いた人が適当に飲むから常設しておいてほしかった(最後に無理やり渡すのはスポンサーにも失礼な感じがした)各部屋のキャパシティが限界を越えてて観たいセッションが見れないというのがいくつかあったので次はもう少し規模を大きくしてパシフィコとかでやるんだろうなーという期待個人的には前回あったオサレな朝食はよかったので今回なくなったのは寂しかった(諸事情でなくなったんだろうということで理解はしてる)とはいえ、全体を通してみたときの満足度や快適度はかなり高かったと思う(悪いところを拾い上げればキリがないし)こんな感じでしょうか。最後に最近、感情をなくして仕事をただただこなすマンになってて元気がなかったんですが、いろんな方とお話しさせていただいたりセッションを聞いてたくさん力をもらえたような気がします。こういったカンファレンスが開催できるコミュニティを今後も大事にしていくべきなんだろうなーと思い、これからも微力ながらサポーターとして応援します！

builderscon2018もやっぱり最高だった

blogをhttpsにするといって幾星霜— jigyakkuma (@jigyakkuma_) March 4, 2018ということで重い腰を上げて取り掛かることにしました。腰が重かった理由がいくつかありまして、ブログはHUGOで generate してるので静的コンテンツが配信できればいいGCS が https 化してくれるのを待っていた静的コンテンツの配信に GAE はなーという想いなどがあって目をそむけ続けてましたが、https に切り替えないとダメだーというギリギリのタイミングでやるとろくなことがない気がしたのでやることにしました。GAE で SSL をマネージドしてくれるようになったのでそれを使うことにします。移行前の準備まずは GAE で動いているものがないので移行して動くことを確認できる環境を作ります。goappを使ってローカル環境で動作確認が行えるようCloud SDK for Goを入れておきます。goaap serveでローカルでサーバが立ち上がるので localhost:8080 でブラウザから確認できます。ひとつ注意点としては hugo 自体は build されないので、記事を書いてコンテンツの内容を確認するのであればhugo server -wを使うのがよいです。goapp はあくまでも GAE として動作するかの確認に使います。移行作業GAE への移行作業自体はこちらのブログでわかりやすく解説されているので参考にしました。secure: alwaysですが、SSL 証明書の適用は GCP のコンソールより GAE →設定を開いてカスタムドメインの追加をしておく必要があります。デプロイデプロイは今までどおり CircleCIで行うのですが、ローカルでデプロイできるのを確認してから CircleCI の config.yml を書くことにします。Cloud SDKを入れて、以下の command で対象プロジェクトを設定しておきます。gcloud config set project [GCP project ID]その後はデプロイは該当プロジェクトのディレクトリに移動してgcloud app deployを叩くだけでデプロイできます。デプロイできるのを確認できたら、ブログの repository においてある.circleci/config.yml を差し替えます。ひとつポイントをあげるとすると、GAE はバージョンを指定しないとバージョンごとにインスタンスを作ってくれるのですが、ブログの運用くらいだとオーバースペックなので(前バージョンに戻す必要はないので)デプロイ時にオプションでバージョン固定にしています。最後にここまでくれば作業は完了です。あとは今まで同様、markdown で記事を書いて commit すればブログが更新されます。めでたしめでたし。

ブログを GCS Hosting から GAE に移行して https 化

はいさーい！みなさんお元気ですか？YAPC::Okinawa 2018 ONNASON を堪能して帰路の途中です。約 6 年ほど前に今の会社に転職してからいろいろなカンファレンスに参加させていただきましたが、飛行機に乗るようなカンファレンスに行けるとは思ってもいなかったので今回は本当にうれしい経験となりました。JPA主催になってからの YAPC は初めてだったのですが、スタッフの方々も参加者も暖かみのある雰囲気があって「あー！これこれ！！」となり、やっぱりこの界隈のコミュニティが好きだなと再認識できました。謝辞スタッフの皆さま、運営ありがとうございました。前夜祭では登壇を含めいろいろお世話になり感謝でございます。次は場所を提供いただきました沖縄科学技術大学院大学(OIST)です。今回講堂をメインホールとしてお借りしましたが、椅子の座り心地、各席のコンセント配備や使いやすいテーブルなど非常に快適に聴講することができました。沖縄科学技術大学院大学、自然に囲まれたこの広いキャンパスで学べるの、最高の環境ぽい pic.twitter.com/6a681jtQmi— jigyakkuma (@jigyakkuma_) March 3, 2018　(当日はどしゃ降りだったのが悔やまれますが大自然の中にあるキャンパスは想像以上に居心地がよかったです)あと、今回は会社の手厚いサポートにより参加することができましたのでこの場で紹介いたします。スポンサーいただいた企業様のおかげで素晴らしいカンファレンスが開催できたことに感謝いたします。雑感やっぱり地方開催は最高！というのが感想の 9 割でした。懇親会では「関東のカンファレンスには興味があるけど中々行けない」「転職を考えたときにもオフィス訪問ができないのがネック」というよく聞く話が出てきて地方のカンファレンスに初めて参加して大変さがよくわかった。のと同時にだからこそ地方で開催することの意味はあるというのも伝わりました。YAPC::Okinawa 2018YAPC は 2015 以来の参加で、その時はいろんなジャンルの技術カンファレンスという感じだったのですが、地方開催になってからは Perl 色が強くなり(というか Perl のカンファレンスなのでそれが当たり前っちゃ当たり前なんですが)、Perl というプログラミング言語が育んできたコミュニティのよさ、というのを肌で感じました。今は仕事で Perl を書いているというのもあって、Perl ネタのトークは刺激や発見があって Perl を書いてると YAPC が数倍おもしろくなるな(これも当たり前ですが)というのも目の当たりにしました。2018 年春の Perl@karupaneruraさんの Perl 最新情報についての話。定期的に開催しているカンファレンスだからこそ出来る Perl の最新情報が得られるというトークは私のような情報収集をサボりがちな人間には非常にありがたいです。＠ INC まわりは最近ハマったというのもあってなるほどな〜となりました。スライドInline モジュールの世界@moznionさんの Inline モジュールを採用してしまったプロジェクトを供養させるためのトーク。仕事で使うと地獄をみるという知見が得られて有益でした。スライドPerl コーディングテクニック 2018@akiymさんの Perl をコーディングするときのあれこれ。use Strict や Validator などコードを書くときによく出てくるあれこれの話が聞けたのがよかったです。Perl は TMTOWTDI の精神なので好きに書くのがよいというのと好きに書けますというのが独特の文化だなぁというのがよくわかりました。ブログ前夜祭前夜祭では「A Spacemacs Journey -果てしないエディタの旅-」 というタイトルでトークさせていただきましたが、ところどころ検証が足りていなくて発表に間に合っていなかったのと、スライドみながら話そうと思ったらディスプレイの配置が遠かったのとスピーカーモードにしたら手元がめっちゃ小さい表示でスライドが見えず勢いだけの微妙な内容になってしまっていて申し訳なかったということで猛省しております。LTこれが隣の席に座ってる若手エンジニアに「せっかくYAPC::Okinawaに行くならLTもどう？」と声かけたら二つ返事で応募してて最高かよってなった— jigyakkuma (@jigyakkuma_) February 28, 2018こうよ！！！ベストLTは @_serinuntius さんです！ pic.twitter.com/fs4tGtwXQc— yapcjapan (@yapcjapan) March 3, 2018この若者はワシが育てた(ｷﾘｯと言いたいところですが、「カンファレンスで LT したいと思ってたんですよ」「LT の勘所はなんとなく掴んでたのでウケてよかったです」など新人とは思えない返答だったので、そんなこといいながらベスト LT 賞を取っちゃう最近の若者はほんとスゲぇ。最後にサーバサイドのエンジニアをやり始めて数ヶ月とはいえ、プロトコル、Perl のこと、ミドルウェア、運用など知らないことがまだまだたくさんあるというのを痛感するし、仕事でもインターネットでも今以上に貢献したいと思っているので、ベースのスキルを身に着けながらみんなが聴きたくなるような話ができるよう得意分野をみつけようと思いました。おまけ今回、YAPC::Okinawa の翌日に帰ったのですが、14 時の便にしたら思いの外、ゆっくりする時間がなくてお土産を散策して終わってしまったのがもったいなかったので、また YAPC::Okinawa を開催してもらってまた沖縄に遊びにいきたいです！！

YAPC::Okinawa 2018 ONNASON に参加できて最高だった話

皆さまいかがお過ごしでしょうか。2018/3/3(土)に開催されるYAPC::Okinawa 2018 ONNASONに先立ち、恒例の前夜祭でトークさせていただく運びとなりました！わいわいPerl について話せることがないながらも YAPC で登壇させていただく機会をいただいて人生が変わってと言っても過言ではないくらいお世話になっているカンファレンスなんですが、今回はちょっと Perl の話ができそうでとても楽しみです。応募したトークは「A Spacemacs Journey - 果てしないエディタの旅 -」ということで愛用している Spacemacs で Perl を書くにはどうするのがいいのかという内容で、残念ながら本編からは漏れてしまったのですが前夜祭でのトークはいかがでしょうかと運営スタッフの方からお声がけいただいたので 2 つ返事をして沖縄行きが決定しました。決まってからすぐに発表スライドを作り始めたのですが、「せっかくなので Spacemacs のよさを知ってほしい」と思いながら書き始めたら機能紹介の羅列みたいになってしまって社内からのフィードバックでも「Spacemacs ならではの話をしたほうがいい」「体験談や思っていることを参加者は聞きたいはず」など、カンファレンスでトークすることの意義を見失うところでした。その結果、機能紹介は完全に切り出してトーク前の資料とすることにしました。　ちなみにですが、この資料は補足となるので、ここに書いてある内容にはほとんど触れない予定です！それでは前夜祭でお会いしましょう！！！！

YAPC::Okinawa 2018 前夜祭で Spacemacs の話をします(予告編)

前回は準備編として自作キーボードの検討や購入について触れました。組み立ての前に部品が揃ったらさっそく組み立てたいところですが、その前に組み立ての流れを整理してきましょう。PCB にスイッチダイオードや抵抗、リセット用スイッチや TRRS  Jack をはんだ付けするトッププレートにキースイッチをしっかりはめるキースイッチと PCB をはんだ付けするPro Micro をはんだ付けするファームを焼いて動作確認LED を取り付けるトッププレートとボトムプレートをネジとスペーサーで止めるキートップを取り付ける手順にすると多いですが、電子工作をしたことがある方であれば 1 日あればだいたい終わります。Build Guideに沿って進めていくのがよいです。英文ですが読めば欲しい情報が書いてあったりします。しかし、読むとわかるのですが Iris のマニュアルは途中までしか書かれていないので注意が必要です。はんだ付けはんだ付け自体はそう難しくないのですが、知識が乏しくて悩んだところがありました。スイッチダイオードと抵抗の取り付け方向スイッチダイオードは極性があるので取り付ける方向を間違えると正しく動作しなくなります。で、Iris はというと、左右関係なく黒いラインが下にくるように配置してはんだ付けすればよいです。はんだ付けの注意点はんだ付け自体はそう難しくないのですが、1 点注意するとすれば極力高さを出さないということでしょうか。部品を浮かせないはんだを必要以上に盛らないを心がけてください。2 点で止めるダイオードやキースイッチはまだ修正できますが、Pro Micro は浮いたままはんだ付けしてしまうと取り返しがつかなくなってしまいます。浮いてないか何度も確認しながら慎重にはんだ付けするのが失敗をしないコツでした。キースイッチとプレートの関係最初、PCB とプレートをどのように固定するのかというのがいろいろ調べてみても情報が出てこなくてだいぶ困りました。LED テープライトの取り付けこれは Iris の Build Guide に書かれておらず、Iris を組み立てた方々の blog を漁りましたが、うまくいかず割と苦労しました。Nyquistの Build Guide を眺めていたらビンゴでした。master 側の RGB から信号を出力master 側の Extra Data から RGB の信号を出力Slave 側は Extra Data からの RGB 信号を入力とすると配線する必要があったようです。Tips細々としたメモ:浮きがなければスペーサーはギリギリ 9mm でもいけそうボトムプレートは接地面にネジが出てしまうのでゴム足があるとよいキートップのホームポジションがわからないのでエポキシ系接着剤を少量たらしたらいい感じにわかりやすくなったボディをアクリルにするならカラー入りのクリアなタイプがかっこいい最後にIris を使ってみた感想としては親指シフトは慣れてくれば指の移動が減ってよい格子配列は指が困惑しがち内側のキーは少し押しにくいのでスタビライザーをつけて 1 キーにしてしまってもよいかも60%はちょうどよかったというところでした。まだ慣れていないところもありますが概ね満足しているのと、キーボード作るの面白いので、またよさげな PCB みつけたら作ろうかなと画策しています。それでは皆さまもよい自作キーボードライフをお過ごしください！

Iris で自作キーボードを作った(組立編)

素晴らしい世の中になったもので、キーボードも楽に自作できる時代が来ましたね。自作キーボードの検討まずは何を作るのか、というのを決めるところからですよね。・ キー数が少なすぎるのはあまり好みではないこれらの条件だと一番情報量の多い Let’s Split は候補から外れてしまいました。40%キーはさすがにレイヤーのスイッチングが多すぎて実用するのがしんどそう、というところが本音でした。Irisという PCB がみつかり、要件が揃ってそうだったので、こちらで作ってみることにしました。パーツの購入次は必要な部品の購入です。今回は・ お気に入りの MX Cherry Black 相当のキースイッチにしたいというオーダーで揃えました。名称価格購入先備考Iris PCB(Rev 2.1a)¥2,749keeb.ioKey Switch(Getoron Black)¥1,848keeb.io多めに購入Micro USB Cable¥329keeb.ioPro Micro¥1,800Amazon左右それぞれに必要なので 2 個購入Key Cap¥3,456TALP多めに購入アクリルプレート¥1,800コーナンカット代は含まないスペーサー(M2x10mm)¥600Amazonネジ(M2x6mm)¥1,000Amazon4 極ケーブル¥650AmazonLED テープライト(WS2818B)¥1,280Amazon買ったのは 60 個だけど使ったのは 8 個リード線¥500Amazonエポキシ系接着剤¥500AmazonPro Micro のコネクタ部分の強化用合計¥16,512金額は市販のメカニカルキーボードと比べてもそう高くはないですね。Iris はキットになっていて、スイッチングダイオードやリセットスイッチ、TRRS Jack なんかもセットになってるので自作キーボードが初めての方も安心ですね。購入での注意すべきポイントわーわー言うほどのポイントはないのですが、ポイントかなと思うところを少し書いておきます。・ 要件を決めておいてまとめて買う(迷いながら買い足しを何回もしてしまってリードタイムがわりとあった)公式の図面に記載があるので参考にするくらいでしょうか。あとは共同購入といったのも見かけるので、そういったのを利用してみるのもいいかもしれないです。組立編でお会いしましょう！

Iris で自作キーボードを作った(準備編)

めっきり寒くなってきましたがいかがお過ごしでしょうか。転職しようと思ったきっかけ遡ること今年の年初、今の会社(とか部署)でもう働きたくないって事案が相次いで重なり、入社してから 5 年も経過してるからここいらで潮時かな…と一人でモヤモヤしながら思い詰めてました。転職活動中の出来事決意してからは自分が今までやってきた仕事にマッチしそうな Web の会社にお話を伺ったり面談をお願いしました。部署異動の検討当時は私が担当する情シス(社内インフラと社内で呼ばれている)はリソースとしては 1.7 人くらいだったのと適任者は社内外でもそうみつからないので、簡単に「部署異動したいです！」とは言えない状況でした。そんな中で部署異動を勧めていただいた時にスッと楽になったのは今でも覚えています。部署異動が決まってから部署異動が決定したものの、リソース問題は残っており色々調整を図っていたところ奇跡が起きました。後任が採用できたのです。現在10月からソーシャルゲーム事業部というところでスマホゲームのサーバサイドエンジニアとして Perl を書いております。振り返り結果として部署異動という選択はよかったです。一緒に働いている人たちは好きなのと今回のモヤモヤの理由は会社を絶対に離れたいということではなかったというのが大きいとは思います。最後に人それぞれいろんな選択があるかと思うので、今の境遇にモヤモヤしてる人の何かの参考になれば幸いです。

転職をしようとした結果、部署異動した話

久しぶりのブログ更新ですが、エンジニアリングとは無縁の話です。私は同僚と華金について真剣に議論する機会があったので、真面目な気持ちで議論してみました。最高の華金にするにはどうすればいいかという議論を真剣にしています pic.twitter.com/oCWRHOESul— jigyakkuma (@jigyakkuma_) June 16, 2017どうすれば最高の華金になるかの議論が白熱してます pic.twitter.com/SfnOwAoSky— jigyakkuma (@jigyakkuma_) June 16, 2017「華金なんて好きにお酒でも飲んでりゃいいでしょｗｗｗ」とお思いの方もいらっしゃるかと思いますが、我々は「華金を最高のものにするにはどうすればいいか」というお題を設けてみました。華金とは一体なんなのかまずは華金とは何か、という整理をすべきであると考えました。華金を楽しむために我々は仕事をしている華金は仕事でバリューを出した結果であり、華金をするためにバリューを出せるようにする華金をするにはバリューを出せばいいので、どうやってバリューを出すかを考えるバリューを出すことが目的ではなく、あくまでも華金をすることを目的とすればよいこう書くと「仕事でバリュー出せとかいう意識高い系の話かよー」と勘違いしてしまうかもしれないですが、それは全くの誤解です。また、華金は単に飲み会をすればいいというわけでもなく、お酒の席が苦手であれば別の好きなことをやればよいレイトショーを観に行く、ゲーム大会を開催するなども立派な華金となり得ると、各々が最高と思えることをやればそれが華金と言えるので、華金の定義や形式張ったものは不要です。最高の華金とは何か次に、最高の華金とは何かについて考えてみます。最高の華金をしたい人たちが最高の華金をやるためのモチベーションをもって最高の華金を全力で楽しむが最高の華金ではないかと考えます。最高の華金は華金が始まる前から始まっているでは次に、華金はどうすれば最高になるのかを考えてみます。華金に対しての意識を高めるとか面倒くさそう冒頭にも書きましたが、「楽しく飲みに行きたいだけなのに、こういう話はメンドクセー！！！」という話も出ました。たしかにおっしゃるとおりです。華金力の高い人材を育成するでは、ここで言う「華金力の高い人材」とは何を指すのか。「華金をコーディネートでき、かつそれを主体的に広めていける人材」華金に誘える人が周りにいないぞ…どうすれば…たしかに、人によってはそういうケースもありますよね。そこまでしてなんで華金がしたいの？ここまで、華金華金と言ってきましたが、なんでそこまでして華金がしたいの？という疑問が出てきてもおかしくないですね。「限りある華金という瞬間を少しでも最高にしたい」最後に最後まで読んでいただきありがとうございます。華金は誰もが楽しめるエンターテイメントエンターテイメントを楽しむなら妥協はするな限りある華金に全力で挑めといったところでしょうか。おじさんになっていくと内臓やら足腰がやられてきて自由が効かなくなってきます。もしかすると家族の事情でそれどころではなくなってしまうかもしれません。人生における「華金」という最高の瞬間には特別な価値があり、それを謳歌できるうちに全力になるのは決して悪いものではないと思います。多少偏った話もあったかと思いますが、皆様がそれぞれ幸せについて考えるきっかけになれば幸いです。

華金について真剣に議論して出した答え

最近、作業環境を ApricityOS に変えました。gnome ベースなのとおしゃれな見た目なのが気に入っているのですが、1 つ困ってることがありました。業務で社内用 Gyazo が用意されているので、それを使っているのですが、自作クライアントを dock から起動させたい、ただそれだけなんですがそのあたりがよくわかってなかったので調べてみました。Dash to dockApricityOS は gnome extentions のDash to dockを採用していました。(Dash to dock のイメージ)Setting などを見たところ、Dash to dock はあくまでも dock なのでアプリの管理を行っているわけではないようです。ヒントがなくて悩むどっかにアプリを定義してるところありそうなのになかなか見つけられんなーと思いながらあれこれしていると ApricityOS に ice というアプリが入っているのに気づく。“Apricity OS lets you put your favorite web apps on the desktop with ICE, a simple SSB (Site Specific Browser) manager. “と書いてあったので試してみたらサイトをシングルアプリとして起動できるようによしなにしてくれるツールであった。このツールを使うとサイトがアプリとして起動できるように dock に追加されていて「おっ！もしや？？」となった。desktop entry先ほどの ice で登録したアプリがどっかにファイルとして生成されてるのは明白だったので探ってみると.desktop というファイルが置かれており、ここでようやく desktop entry を知ることができた(長かった)。desktop entryはリンク先にほぼほぼ書いてあるのですが、freedesktop.orgの仕様があり、フォーマットに沿ったファイルを/usr/share/applications とか ~/.local/share/applications に設置することでアプリケーションのデスクトップエントリとしてショートカットを配置できるようです。今回は以下のようなファイルを~/.local/share/applications に配置しました。配置するとこんな感じ(Gyazo アイコンがそれです)gnome 系を使っていたこともあったのに desktop entry について知らなかったのでいい勉強になりました。

desktop entry で自作アプリの登録方法

夏はカンファレンスの時期ですね！謝辞YAP(achimon)C::Asia Hachioji の Organizers、スタッフの皆様、場所を提供いただきましたMicrosoft 様、ありがとうございました！経緯YAP(achimon)C::Asia Hachioji(以後 yapc8oji)、最初は傍観していたのですが、主催者の方が「応募頼む！！！！」みたいな悲痛の叫びをされていたので賑やかしで応募したのが経緯でした。「応募の Issue がわいわいしてればいいかー」くらいの気持ちだったのですが、ありがたくも採択いただき、少々焦りましたが粛々と資料を作成し始めました。苦悩資料作るといつも思いますが、「ちゃんと説明したいけど、ウケも狙いたいし、どういう方向性がいいのかなー」みたいな葛藤があって、書いては消しを繰り返してました…内容今回は実際に運用している AWS アカウントと AWS IAM 管理の社内の仕組みを事例として話しました。反省「仕組みを紹介する」、ということ自体は Blog でもできるから、それ以外のところをうまく伝える、楽しんでもらえる構成にすべきだったなーというのがありました。次回はスピリチュアルな話ができるネタで挑戦したいと思います。感想話す内容は割とニッチであるので覚悟はしていたので、見に来ていただいた方々には感謝です。少しでも皆様の参考になったのであれば幸いです。あとはプレゼンのうまさ(抑揚やアイスブレイク、場の空気づくりなど)はまだまだなので、エンターテイメント性は上げていきたいところです。それでは、またどこかでお会いしましょう！！！！１今年もノベルティのステッカーあります #yapc8ojiB pic.twitter.com/s7b7Q1YBte— jigyakkuma (@jigyakkuma_) July 2, 2016[追記]運営の方に動画をアップロードいただきましたので以下よりご覧ください！

YAP(achimon)C::Asia Hachioji 2016 に参加(登壇)させていただいきました 

GCPUG Shonan も 4 回目の開催。今回も GAE の話題が中心でした。GCPUG Shonan vol.3<いつものお礼>茅ヶ崎 login 様、ありがとうございました！appengine ja nigntに登壇された方々をお招きしての GAE 事例あれこれ紹介といった内容でした。GAE のアクセス制限app.yaml に login Element を設定しておくとアクセス制限ができる。参考 URL- url: /admin/.*  script: admin.app  login: adminみたいにしておくと、GCP Console の IAM で Admin 権限を付与したユーザのみがアクセスできるページが作れるというもの。GAE からのメール送信制限社内で GAE を使ったツールを作成するに当たって、要件としてメールの送信があったのでメール送信数の制限については参考になった。AppEngine quotaGAE flexible environment私の知っている GAE はいわいる GAE Standard environment と呼ばれるものでした。AppEngine typeGAE のカスタムドメイン設定GAE でカスタムドメイン設定を行うと、設定したアカウントからは設定が見えるが他ユーザからは GCP Console を見てもカスタムドメインの設定がされていないように見えるとのこと。また、懇親会もいつものように盛り上がったので、その様子も。懇親会🍒🍒🍒 #gcpug pic.twitter.com/UaBTyUk5xi— Ryuji Tsutsui (@ryu22e) June 19, 2016GCPUG Shonan にはさくらんぼが出る 📝 #gcpug pic.twitter.com/iARp3XYCMP— sou (@sou) June 19, 2016GCPUG Shonan スタッフの@tora470さんの差し入れのさくらんぼでキャッキャする感じでした。あと、今回は appengine ja night で登壇された方々にも参加いただいたのでいつも以上にわいわいできてよかったと思います。地域密着イベントではありますが、参加人数にも限界があるので遠方から足を運んでいただける方には感謝しかないですね！

GCPUG Shonan vol.3 に参加してきた

今回はいつもお世話になってる terminal の話です。今使ってるのが manjaro linux(KDE)なんですが、こちらは yakuake で使っていて、maia という theme できれいに統一されてたのと背景画像の透過の調整が難しかったのでカスタマイズせずに使ってました。今回も guake のスライドショーやるかーと思って cron を仕込もうかと思ったら Arch ではデフォルトで cron 入れねぇみたいなのが書いてあったので systemd の timer を仕込むことにしました。guake-slideshow.shまずはスライドショーをやってくれす shell script ですが、これは gconftool-2 を使って切り替えます。guake-slideshow.serviceguake-slideshow.sh を叩く systemd の service です。shell script や画像のあるディレクトリはここで調整するようにしてます。guake-slideshow.timersystemd に仕掛ける timer です。Setting$ cd ~/bin$ lsguake-slideshow.sh$ cd ~$ mkdir -p ~/.config/systemd/user && $_$ lsguake-slideshow.service guake-slideshow.timer$ systemctl --user start guake-slideshow.timersystemd に関する記事は探せばたくさん出てくるので、ここでは手順をメモする程度にとどめます。仕事でよく目にする terminal だからこそ、好きなアニメ画像などを切り替えるだけで捗るってもんですね！

guake の背景画像を systemd でいい感じに切り替える

前回は GAE 勉強会(過去 blog はこちら)でしたが今回はハンズオンということで GAE を実際に触る回でした。GCPUG Shonan feat.GAE vol.2<恒例のお礼>茅ヶ崎 login 様、ありがとうございました！今回はハンズオンということもあり以下のような構成でした。GAE の導入主催の@nuki_ponさんより GAE についての簡単な説明。GAE で静的コンテンツの配信ここからはハンズオン形式で GAE を触ってみることに。https://github.com/FreeGufo/gae-static-templateはまりどころはそこまでないとは思いますが、ここに記載ない内容で行くと、「Google Developer Console」を使用可能な状態にしておくというのがあります。https://console.cloud.google.comにアクセスし、クレジットカードを登録してから初める必要があります。あとは GAE だけでなく、GCP 全般に言えることとしてはプロジェクト作成時にプロジェクト名を入力するのですが、その際に自動的にプロジェクト ID が付与されるので、各サービスで指定する場合はプロジェクト ID とするのが注意点です。WordPress on GAE後半は@ryu22eさんに WordPress を GAE 動かすハンズオンを行っていただきました。資料と参考 blogを見ながら進めると簡単に構築できました。懇親会今回は前回とは違う顔ぶれとなり、テーマがよかったのかフロントをメインにされている女性の方も参加いただいていたので、幅広い方に知っていただくという意味ではよい方向に向かっているのかなと思いました。最後に今後も参加予定なので、もしこの blog を見て参加しよう！という気になった方がいましたら気軽にお声がけいただけると幸いです。

GCPUG Shonan vol.2 に参加してきた

前回は vol.0 ということで正式な開催ではなかったのかな？という感じでしたが、晴れて GCPUG Shonan の vol.1 が開催されるということで今回も参加してきました。(前回参加の blog はこちら)今回もスタッフの皆様ならびにご協力いただきました茅ヶ崎 login 様、ありがとうございました！GCPUG Shonan vol.1 は 3 本立てでした。GCPUG Getting Started主催の@nuki_ponさんから GCPUG の開催に当たってのもろもろの話。ここにまとまっているので読んだほうが早いです。自営 de GAE@secondarykeyさんによる GCP の簡単な紹介と GAE の導入についての解説をしていただきました。資料はこちら)GAE の特徴や連携できる機能などをまとめていただいており、ざっくり知るのにちょうどいい内容でした。GAE と GAS@soundtrickerさんの主に GoogleAppsScript の話。資料はこちら)GoogleAppsScript のメリットをわかりやすく教えていただきました。あと参考になったのは GAE と Pub/Sub で使うというのは良さそうな感じでした。Datastore について@sinmetalさんの Google Cloud Datastore についての話。下調べしてなかったのですが、AWS でいうところのDynamoDBでした。資料はこちら)Datastore については使ってないので DynamoDB と比較しにくいですが、機能やパフォーマンスは Datastore に分があるように感じました。GCP トレーニングの講師もされている方なので、お礼も兼ねてここで宣伝させていただきます。懇親会今回も食事とお酒をご用意いただき、和気あいあいと会話させていただきました。最後に都内で開催される凄腕エンジニアが集まる勉強会もいいのですが、地元開催のイベントで地元を盛り上げつつその近辺のエンジニアが繋がるというのも中々楽しいのではとは思っております。今回は地元メンバーが 3 人ということだったので、これからも繋がっていけるエンジニアが 1 人でも増えればいいなと思っておりますので、次回以降も参加して活性化をお手伝いできればとは思います。

GCPUG Shonan vol.1 に参加してきた

購入したのが 3 ヶ月も前なんですが、持ち歩きながらコツコツ読んでようやく読み終わったので感想をまとめようと思いました。「たのしいインフラの歩き方」、ページ数が多いので電子書籍にするか迷いましたがカバーが可愛かったので本にしました pic.twitter.com/ZwgdH1Izbu— jigyakkuma (@jigyakkuma_) September 8, 2015tweet にもあるように不順な動機で電子書籍ではなく本を購入しましたが、内容が技術書というよりは丁寧に書かれた秘めたる想いという感じだったので本で読むといい感じでした。この書籍は Introduction にも書いてある通り、技術書というよりは著者の経験を元に書かれたインフラに関するまとめとなるもので、そこには共感できる内容もたくさん書かれており、単なる技術書からでは得られない大切なことばかりが書かれてました。670 ページとかなりボリュームはあるので章をわけて感想を整理したいと思います。インフラの心得ここではインフラの中でどのカテゴリにも当てはまるような基本的なことが書かれていました。スタートアップ期に必要なことスタートアップではオフィス設計からネットワーク構築、開発環境(PC など)の管理や NAS や社内サーバを用意するなど意外とやることが多い。そんなところが触れられていたが私自身もこの章に書かれているようなところを現職で担っており、共感できる部分が非常に多くうれしかった。イベント(1)引っ越しオフィスの引っ越しは私も経験したことがあるので、その記憶を照らし合わせながらこの章を読みました。ゼロから構築するのではなく、既に稼働しているものを移設するという構築当初と別の問題が浮上してくるところも「あるある」感があってよかったです。中小企業期に求められることこの章では会社規模が大きくなってきた時に段々とインフラや社内システムなどの責任が重くなってくるのでそれにどう対処していくべきかといったところが触れられてました。イベント(2)事業拡大社内のとあるサービスもオンプレから AWS に移行したことがありましたが、その際にネックとなったのがデータセンターの増設でした。大規模に向けてこの章ではよくある既存環境をどうスケールさせていくかについて触れられています。私自身、業務で直接サーバのインフラ部分を担当することはないのですが、監視・負荷分散・ Infrastructure as Code など知っておくべき内容が多く書かれていたのがよかったですし、広く触れられているので初級編の教科書代わりにしてもよさそう。イベント(3)コスト削減データセンターのクローズ作業や不要なサーバの整理など、コストについてまわるところは日常的に取り組んでいることもあり共感できるところも多かったです。求道者の心得インフラは適用範囲が広く、自分にとってどんな知識が必要かを時間という制約の中でいかに身につけていくかというのは常日頃から意識したいと再認識した。また、そこも含めていちエンジニアとしての技量が測られると思うし、インフラに限らずこれからもエンジニアとしてやっていくならそういった意識も大事にしていきたい。インフラを支える基礎知識インフラの領域とは言わず、エンジニアであれば広く知っておきたいことが書かれているのとサラッと読めるボリュームが GOOD。最後に感想を書くのに振り返りながら軽く読み直しましたが、改めて思ったのが本書に書かれている内容の幅が広すぎて著者は一体何者だ…という感想でした。また所々に書きましたが、共感できる箇所が本当に多くて読んでて面白かったし、自分と同じような体験が書籍として公の場に出たことが素直に喜ばしかったです。会社の中で呼ばれる「インフラ」といった内容は網羅されており、また間口が広い構成になっているのでインフラエンジニアに限らず気軽に読んでいただき、少しでもインフラというジャンルに興味を持っていただける人が増えればと願います。

「たのしいインフラの歩き方」を読み終えて

タイトルの通り、GCPUG が湘南(今回は茅ヶ崎)で開催されるということでお邪魔してきました。まずは開催いただきましたスタッフの皆様ありがとうございました！AIZAC 様もありがとうございました！ロケーションが最高でした。GCPUGに来た pic.twitter.com/lkfEXWj1kC— jigyakkuma (@jigyakkuma_) November 29, 2015行く前は GCPUG の趣旨がはっきりとわかっていませんでしたが、大規模な勉強会というよりかは小規模で対話しながら参加者に理解を深めてもらうといったイベントでした(今回はハンズオン)。作業環境準備まずはじめに作業環境の準備をしましたが、Developer Console の Cloud Shell を立ち上げるだけで終わった。Cloud Shellけっこう便利だし、今後使う機会が増えるかもと思ったのでポイントを整理Google Cloud Shellディストリビューションは Debian(確認した時点でバージョンは 8.2)ツール類が色々入ってる(Available tools)言語も色々入れてくれてる(Go は 1.5 が入ってた)(Language support)Docker on GCE作業用のインスタンスを立ち上げるインスタンスに ssh でつなぐDocker pull & runこの辺りでもいくつかポイントがあったOS 自体の機能がいらない用途なら軽量ディストリビューション Alpine linux の Docker image を使うのオススメインスタンスのメタデータをとってこれる API が用意されている(Storing and Retrieving Instance Metadata)Instance Metadata の詳細についてはハンズオンを行っていただいた大橋さんが後ほど記事にしてまとめてくださるそうなので楽しみに待ってます。その他Docker machine ちょっと触ってみたDocker コマンドの説明DockerHub の注意点Google Container Registryの紹介最後は懇親会でみんなでわいわいしました。ハンズオンの参加は初めてだったんですが、各人が手を動かしたり詰まったところを教え合ったりというのは参加者同士の距離も縮まり一体感があっていいなーと思いました。地元開催ということもあり微力ながら力添えが出来ればと思っておりますので今後も参加していこうかと思います。

GCPUG Shonan vol.0 に参加してきた

Hugo + wercker + gcs にしてみた！とか言ってますが S3 使ってたのを GCS に変えただけって話です。blogを参考にしていただけるといいかと思います。先日、GCS にデプロイする wercker のstepsを見つけ、早速試してみたのですがうまくいかず。werckerでGCSにデプロイするやつ、なんかうまくいかないなーと思ってたけど.botoファイルをechoで作るときに-eオプション抜けてて改行が出来てなかったっていう初歩的ミスやった...— jigyakkuma (@jigyakkuma_) October 10, 2015というオマヌケなミスでした。以下が現時点で使用している wercker.yml です。これで作成したバケットにデプロイされるところまではよかったんですが、GCS の public 設定がよくわかんなーと思いながら調べてると参考になるblogがあったのでこちらを元に設定。ここをちゃんと読めば書いてそうなのであとで読もうかと思います…次はサイト監視したいなーと思うので、そのあたりで何にしようか検討中です。

blog の環境を Hugo + wercker + GCS にしてみた

社内とある一言から話は始まった。awsのサポートから返信来たのslackにながしたいんだけどSNSで通知とかできないんだろうか— fujiwara (@fujiwara) September 16, 2015弊社の場合、AWS のアカウントを親アカウント+各プロジェクト毎のアカウント(常時 50 以上はある)といった形で運用しているので AWS SNS を各アカウントに設定するのしんどいのと深淵なる理由により Gmail で受信した AWS のメールを from でフィルタして転送というのもうまくいかなかったので GoogleAppsScript を書いた。これにトリガーを 1 分周期で回しておくといい感じに slack へメールを投げてくれる。こんな感じで通知がきます。やりたかったのはメールヘッダに[X-AMAZON-MAIL-RELAY-TYPE: notification]っていう丁度いい感じのカスタムヘッダがあったのでこれが来たら slack に投げるってのをやってます。社内が Slack になってからコミュニケーションツールであーだこーだすることが増えた気がしますが、作業環境が改善されていくのを体感できるのはけっこう楽しいのですね！[追記]ここの容量制限には[Gmail の読み取りと書き込み（送信以外）]で 50,000 個/日って書いてるけど、どこでひっかかってるんだ…https://docs.google.com/macros/dashboard

AWS からのメールをいい感じに slack に通知するやつ

とうとう終わってしまった YAPC::Asia、全身全霊でもって楽しませていただきました。トークの振り返りYAPC::Asia2015 はスピーカーとして参加させていただき、貴重な体験をさせていただいたと共に登壇を通して少しでも YAPC::Asia に恩返しできたらという想いでした。YAPC::Asia2015 に登壇させていただいたからこそ感じられたことも合わせてご覧いただければと思います。YAPC::Asia の意義私の周りでよく聞いたり感じたのが「同窓会っぽい」ってとこです。雑感そういえば昨年も YAPC::Asia に参加させていただき、「次回は個人スポンサーとして参加します！！」みたいなことを言ってたのは宣言通り個人スポンサーチケットを購入できたのでそこはよかったです。これからのこと「カンファレンスに参加したいならやりたい人がやればいい！」とは思うものの、簡単にできるものではないし、主催者になりたいわけではないというのが本音ではある。最後にイベントや勉強会にはちょくちょく顔を出していますので見かけましたらお気軽にお声がけいただけると嬉しいです。一緒にわいわいしましょう！！謝辞運営スタッフ個人・企業スポンサースピーカーYAPC::Asia に参加された皆様YAPC::Asia2015 に関わった全ての皆様があってこそ最高のカンファレンスになりましたので末筆となりますが厚く御礼申し上げます。

YAPC::Asia2015 の所感と俺達のこれから

皆様YAPC 全体を通した感想は明日書くとして、ここでは最後の YAPC::Asia で登壇させていただいた貴重な機会について触れたいと思います。周りの応援振り返ってみると、ここまでこれたのは周りの応援あってこそだなーというのが実感としてありました。@Konboiさん、登壇前の応援や後にお声がけいただいた方々。登壇後の反応トークに足を運んでいただく方々に少しでも楽しんでいただきつつ役に立つ話が出来ればという心情で準備に取り組みました。登壇から見えたもの今回取り上げた取り組みでは不完全なところがあり、そこはしっかりと質疑応答で突っ込まれました。得るもの ＜ 与えるものとなるのが理想であるし、自身のトークがそうなっていなかったと後から気付いたところは非常に反省であると言えます。最後に大きなカンファレンスで一同がワイワイする機会ってそんなにないし、やっぱりみんなでワイワイするのは楽しい。余談Twitter アイコンのステッカー（ぱんつあり/ぱんつなし）を用意しましたのでもし受け取っていただける方はお声がけいただけばお渡しいたします！追記公式ページ URL とスライドは以下からご参照ください。YAPC::Asia2015 それは僕たちのドメイン・ DNS 運用

YAPC::Asia2015 に登壇させていただいたからこそ感じられたこと

いよいよ YAPC::Asia 2015 もいよいよ開催間近ですね。勢いだけでトークを応募させていただき、トーク採択という奇跡が起こって気絶しそうになったのがもう 2 ヶ月も前のこと。早いものですね。詳細については以下のリンクをご覧いただくのが早いかと思いますのでご興味ございましたらクリックをお願いいたします。http://yapcasia.org/2015/talk/show/e8eebd70-f906-11e4-8f91-8ab37d574c3aそれでは YAPC::Asia 2015 でお会いできることを楽しみにしております！！！！！がんばって資料仕上げます！！！！！！１

YAPC::Asia 2015 でドメイン・ DNS の運用について話します

最近 CI を触る機会があるというのとGitHub Pagesの設定をいじっていたら名前解決のところのトラブルでイライラしたのでAWS S3に乗り換えたというメモです。まずは手前で使う CI ですが、Hugo との組み合わせで割と使ってる事例が多いって安直な理由でとりあえずwerckerを使ってみることにしました。参考記事としてdeeeet さんの記事をめちゃ読みました。ほんと先人には感謝ですね。m0t0k1ch1 さんの記事も参考にさせていただいております。blog を octopress から Hugo に乗り換えたメモなので興味がございましたらこちらもご覧ください。それでは各項目で何をしたかザッと書いていきます。準備リポジトリまずリポジトリですが、元となる md ファイルをオープンにしたくなかったのでbitbucketのプライベートリポジトリを使うことにしました。ディレクトリ構成はこんな感じです。.├── archetypes    //md ファイルのフォーマット├── config.toml   //Theme の設定ファイル├── content│   └── post      //md ファイル├── public        //Hugo で build したファイルが置かれる、リポジトリで管理しないので ignore してる├── static        //画像もろもろ│   ├── assets│   └── images│       └── post  //記事に使う画像置き場├─── themes       //好きな theme を git submodule で配置└─── wercker.ymlHugoCI 回すまでは手動で build して public ディレクトリに出来た生成物を GitHub Pages 用リポジトリに push するみたいなのやってました。今は新しい記事の作成とローカルで記事のプレビューに使ってるくらいです。wercker冒頭でも書きましたがwerckerを今回は使っています。CircleCIでもよかったのですが、こちらは業務で使う機会があったというのもあり採択しませんでした。それでは wercker の準備ですが、サクッと SignUp したらApplicationsから Application を作っちゃいます。注意点としては筆者の wercker.yml で指定している box は docker 用ではないので「Docker enabled. See our stacks documentation for more details.」のチェックは入れないようにします。GitHubやbitbucketだとリポジトリの指定も簡単だし、deploy key を入れてリポジトリにアクセスできるようにしてくれるので便利。あとは用意した wercker.yml をリポジトリに突っ込みます。以下が用意した yml です。他の CI もそうですが yml 見ればどの CI 使ってるのかがわかっていいですね。box や step はExploreにいろいろ置かれているので必要なものを組み合わせればすぐに使い始められて便利。AWS S3普段 AWS を使ってないのであれば AWS アカウントから作成するのは少々手間ですね…（筆者も今回のために個人の AWS アカウントを作りました）S3 でドメインと同名の bucket を作成、site の hosting を有効にして index document:index.html にしておく作成した bucket に deploy するための IAM アカウントを作成するdeploy できる権限の policy を作成する作成した IAM アカウントに作成した deploy 用 policy をアタッチするとなります。ちなみに IAM でアカウントを作成した際に ID と SECRET が発行されますが、これは wercker に設定するので控えておきます（後ほどでも ID/SECRET は発行できます）。DNSS3 で bucket を作成すると endpoint が表示されるのでそちらに向け先を変えておく。仕上げここまでが下準備となります。ここからは準備したものを流れに沿って設定していきます。werckerApplication > Setting > Environment variablesより、wercker.yml で使う環境変数を設定します。KEY,SECRET は AWS の IAM アカウント作成時に発行した ID/SECRET を入れます。次は Deploy targets を設定します。HerokuやOpenShiftであれば API Key や Token を入れるだけでよしなに Deploy してくれるようですが、それ以外の場合は yml にて Deploy の step でどうにかする感じです。Build が成功すると「Deploy to」というのが出てきて deploy 先を選択しないと deploy されないので target 名と branch を入れて deploy 先を作っておく。後はリポジトリに md ファイルを push してやれば自動で blog に投稿できる！！！！！という算段です。AWS S3を使用したのですが、最終的にはGoogle Cloud Storageに移行したいので GCS 用 step 作ろうかとは思ってます。

blog の環境を Hugo + wercker + s3 にしてみた

gyagoyle 〜 Gyazo client for linux 〜必要に駆られたので作ってみました。jigyakkuma/gyagoyle本家のクライアントツールが Ruby で用意されていたのと、会社で使っている社内 Gyazo のクライアント用によしなに設定したかった(Basic 認証もかかっている関係)ので作りました。mattnさんがすでに同名で作成されてたのでちょっと困りましたね…おぞましい石像に進化した」という感じです。機能はGyazo-for-Linuxを参考にひと通り実装しております(したつもり)。go get で取ってきて実行すれば gyazo.com に upload できるように作ってあるので通常用途でも問題なく使えるようにしました。まだまだ go の書き方や機能部分でイケてないところもあるかと思いますのでご指南いただけますと非常に嬉しく思います。これからもどんどんgo書くぞー

gyagoyle という Gyazo クライアント作りました

ブログを github pages に置くのはいいけど、blog の theme を変えた時に repo を一掃しちゃってその度に「あれ 404 のままやん」ってなってるので自分用のメモ。custom domain のファイルを作成し、repo に commit する。echo example.com > CNAME

GitHub Pages でいっつもハマるのでメモ

皆様、いかがお過ごしでしょうか。そういえば先日こんな勉強会で登壇させていただく機会がございました。旅する勉強会 tech.kayac meetup #0まずは会場まで足を運んでいただきました来場者の方々に深くお礼申し上げます。普段、表立つことが少ない立ち位置なのですが、部署やジャンルをごちゃ混ぜでやるにあたって GoogleApps を取り上げてみてもいいのでは？ということで今回チャンスをいただきました。このテーマ、みんな興味もってくれる？会社の名前を背負った勉強会は集まる層がちょっと違う？せっかく足を運んでいただいたのにガッカリさせないか？など、企画時にお題は決めたものの内容で苦悩してました。そもそも勉強会って興味あるテーマ以外の話もけっこうある知らないジャンルだからこそためになる、知見が広がるセッション自体が面白いと満足度はあがると、お邪魔させていただいた勉強会を思い出してたら吹っ切れたので、要所にネタのエッセンスを入れつつ、楽しくトークさせていただきました。資料自体のサンプルが少ないというのもあるので、せめてデモをやって GoogleAppsScript の動作などを見ていただけたらよかったのですが、1 人でトークが弾んじゃってデモをする時間がなかったというのが心残りでした。あとはハッシュタグの Tweet でこの人何人殺してんだろw #techkayac— Daisuke Murase (@typester) February 25, 2015管理部門に優しくしないと殺られる、という知見が得られた #techkayac— Daisuke Murase (@typester) February 25, 2015と、誤解を招く内容がありましたが、私は至って温和です。安心してください、大丈夫ですので。最後に個人的な感想を述べさせていただくとやっぱり人前で話すのは刺激受けるし刺激を与えられるからいい社内外問わずわいわいやるの楽しい今後もわいわいしていきたいし、わいわいしてる人を増やしたいといったところでしょうか。せっかくやるからには楽しんでもらいたいし、気持ちよく終わりたい、というのは心がけたつもりなので次回以降もご参加いただける皆様に少しでもおもてなしできればと思います。以下当日の資料となります。セッションの内容はこれが全てではないですが、なんとなく雰囲気を感じていただければと思います。

旅する勉強会 tech.kayac meetup #0 に登壇しました

今まで blog は octopress で書いてたのですが、先日ひさしぶりに「おっしゃ！書くか！」ってなって octopress コマンド叩いたらエラー出てて「めんどくせええぇぇぇぇーーーー!!!1」ってなってたらdeeeetさんのOctopuses から Hugo へ移行したをナイスなタイミングで読んだので便乗して Hugo に乗り換えてみました。使い方はHugoのDocsに丁寧にかかれているのでオススメです。やったこととしては・ Theme の選定とカスタマイズTheme の選定hugoThemesに Theme が用意されている。Theme を作れるほどのスキルはなかったのでこの中からチョイスしてカスタマイズすることにしました。日に日に Theme が増えているようなのでこまめにチェックするといいかもしれないです。また、Theme の preview サイトが coming soon となっているので待ち遠しいですね。Theme のカスタマイズとりあえず Theme をいろいろ見てみてlanyonがよさげだったのでとりあえずこれをベースにカスタマイズしました。といっても sidebar の項目をメンテしたりsharebuttonを突っ込んだりしたくらいです。config.toml の作成Hugo はtomlが使えるということだったので config ファイルは toml にしてみました。参考までに使用している現在の config.toml は以下となります。contentdir = "content"layoutdir = "layouts"publishdir = "public"baseurl = "https://blog.jigyakkuma.org"[indexes]  category = "categories"  tag = "tags"[params]  Title = "俺よりイケてないエンジニアはいない"  description = "jigyakkuma's blog"  DateForm = "Jan 02 , 2006"  languageCode = "ja"  countryCode = "ja"[permalinks]    post = "/:year/:month/:day/:filename/"[params.Twitter]  Account = "@jigyakkuma_"  Url = "https://twitter.com/jigyakkuma_"[params.Github]  Url = "https://github.com/jigyakkuma"  UserName = "jigyakkuma"こんな感じでパラメータを定義しておいて{{ .Site.Params.Twitter.Account }}で layout 用の html に突っ込んどくと使えます。感想最初は便乗して乗り換えてみるか！くらいの感じでしたが、Hugo が Go で実装されているというところもあって Go の環境があれば go get してすぐに使い始められるのは個人的には楽でした。ディレクトリ構成もシンプルなのでわかりやすくて good。$ tree -L 1.├── archetypes├── config.toml├── content├── layouts├── public└── staticpublic 内のファイルをサーバに置けば(この blog は github pages)公開されますが、どこにどういう風に deploy するかでやり方が様々なので導入の際は事前に考えておいたほうがよさそうです。まだまだ発展途上で、どう進化していくのか楽しみなのでもう少し使い込んでみたいと思います。

blog を octopress から Hugo に乗り換えたメモ

謝辞まず初めに YAPC::Asia 2014 に参加させていただきましてありがとうございました。また、このイベントに関わった運営スタッフ個人・企業スポンサースピーカー会場をお貸しいただきました慶応義塾大学 日吉キャンパスの皆様に厚く御礼申し上げます。初めて YAPC に参加して思ったこと近年は言語の壁を超えてたくさんのエンジニアが集まる YAPC、その噂以上に熱気と勢いに翻弄されっぱなしでした。あとはインターネットではよくお見かけするエンジニアの方も実物がわからずにお名前を伺って初めて「あぁ、あの方か！！」となることがあって失礼な場面も少なからずあったなという反省はありました。よかったところたくさんの運営スタッフの方のおかげで存分に YAPC を楽しめたところ。あとはスポンサー様による無限コーヒーや懇親会、HUB のビール 1,000 杯提供など、人が集まる仕掛けがたくさんあったこと。人の温かみを感じるイベントは意外と少ないと私は思っているので、感謝の限りでしたし、エンジニアから愛されている意味がとてもよく伝わってきました。気になったところセッションによっては人が集中してしまって多目的教室のキャパシティを超えてしまっていたので落ち着いて聞くことができなかったのは少し残念でした。セッションについてお世辞抜きにどのセッションも見応えがあって大満足でした。普段聞くことのないエンジニアの想いや考え方、実例から伺える努力や苦悩の裏側など、人とエンジニアリングの関わりみたいなところに特に面白さを感じました。スピリチュアルな話とかけっこう好きなので、そっちよりのセッションを割と聞いてました。YAPC を通じて感じたこと人とのつながりは自身を成長させてくれる人が成長する上で、たくさんのことを知る、というのはとても重要なものだと思います。中でもその人が経験してきた体験談というのは情報として価値のあるものであるし、そんな体験談を聞くことができる機会というのは自分も周りも一緒に成長していくことができる貴重な時間であるということ。せっかくの貴重な機会を無駄にしない普段知り合う機会のないインターネット上の有名な方々にお会いするまたとないチャンス。それにたくさんの人と話す機会自体もそんなにないので積極的に絡むべきだし、そういった意味で懇親会は非常によかったです。モチベーションがあがるやはり周りからの刺激は自身の気持ちを高ぶらせてくれます。人によって差はあると思いますが、モチベーションを１人で維持・向上させるというのは難しいので、YAPC のような規模の大きいお祭りに参加するというのはエンジニアとして必要なことであると捉えてます。最後に今回は一般チケットでの参加でしたが、4,000 円でありあまるほどの価値があったと思っています。次回は是非とも個人スポンサーとして参加させていただければと思います。こうやってエンジニアが集まるお祭りもそうはないので、いちエンジニアとして YAPC を大切にしていければと思います。あとは諸事情により 2 日目に参加できなかったので来年こそは全日程に参加したいですね！！

YAPC::Asia 2014 1 日目の感想

先日、iOS と Android のアプリを別のアカウントに移行する作業をしてました。Android はどうかというと、アプリ移行申請ページなるものから申請を行い、GooglePlay Developer Support の方々がせっせと設定を変更してくれるみたいです。今回申請するにあたり、うまくいかず時間を要してしまったのでメモ程度に残しておきたいと思います。Android アプリ移行の簡単な流れAndroid アプリの申請ページに辿り着くGooglePlay developer アカウントの準備 プライベートチャンネルのアプリ収益化されたアプリApplication Transfer RequestDeveloper Account Registration の意味を盛大に履き違えるここでズッポリはまってしまった。Application Transfer Request で「Developer Account Registration」と書いてあり、私は GooglePlay developer や GoogleWallet からそれらしいコードを探したが見つからない。Click the Developer Registration order (This may be titled “ Google - Google Play ”)  が、GooglePlay developer 開設時に支払った登録料であることに気づく。というかちゃんと読んで理解してればすぐに気づくはず。いつもの文章をしっかり読まない性格が招いたトラブルだったなーと反省しました…が、まさか GooglePlay developer 開設時の登録料の登録 ID とは思いもよりませんでしたね…

GooglePlay Developer のアカウント移行時にハマったのでメモ

先日、GAS でいつものようにコードを組んでいたのですが、どうも処理が追いつかずサーバ側のタイムアウトが発生する事案に遭遇。以下の記事にもあるように、GAS は API をコールしまくると途端に処理速度が低下するのはよくある話で、今回のコードも何の考えもなしにループの終了条件で getLastRow()を設定していた。[GAS][スプレッドシート]処理速>    度を向上するには: 逆引き Google Apps Scriptいつもならバグ見つかってよかったー、で終わってしまうのですがちょっと気になることがあったので検証してみました。【検証】 GAS の処理が遅いって言われてるけど、実際どうなの？ということで今回はよくやりそうな処理のサンプルを作ってみたので実測値を見てみる。[検証 1]for 文に getLastRow()を突っ込んだ場合の処理遅延以下のコードを実行してみる。	function speedCheck1() {	  var ss = SpreadsheetApp.openById(SS_KEY).getActiveSheet();  	  var counter = ss.getLastRow();   	 Logger.log('speed check start:getLastRow()'); 	 for(var i = 0;i < ss.getLastRow();i++){} 	 Logger.log('speed check end:getLastRow()->count:'+i);	  Logger.log('speed check start:counter'); 	 for(var i = 0;i < counter;i++){}	  Logger.log('speed check end:counter->count:'+i);	}	結果は以下。	[13-10-24 00:31:46:496 JST] speed check start:getLastRow()	[13-10-24 00:31:54:044 JST] speed check end:getLastRow()->count:100	[13-10-24 00:31:54:045 JST] speed check start:counter	[13-10-24 00:31:54:045 JST] speed check end:counter->count:100[検証 2]ループ内でスプレッドシートの値を getValue()しちゃった場合の処理遅延次はこちらのコード。	function speedCheck2() {	  var ss = SpreadsheetApp.openById(SS_KEY).getActiveSheet();	  var array = ss.getDataRange().getValues();	  var counter = ss.getLastRow();	  var result = new Array();  	  Logger.log('speed check start:getValue()');	  for(var i = 0;i < counter;i++){ 	   result[i] = ss.getRange(i+1,1).getValue();	  } 	  Logger.log('speed check end:getValue()->count:'+i); 	  Logger.log('speed check start:assignment'); 	  for(var i = 0;i < counter;i++){	    result[i] = array[i][0]; 	  } 	  Logger.log('speed check end:assignment->count:'+i);	}結果結果はご覧の通り。	[13-10-24 00:36:15:285 JST] speed check start:getLastRow()	[13-10-24 00:36:22:977 JST] speed check end:getLastRow()->count:100	[13-10-24 00:36:22:977 JST] speed check start:counter	[13-10-24 00:36:22:978 JST] speed check end:counter->count:100整理すると[検証 1] 7452ms  [検証 2] 7692ms  という結果でした。メソッドによって 1call 当たりの処理速度は当然ながら変わってくると思いますので参考程度に見てもらえればと思います。しかしながら 100 回 call しただけで 7 秒以上の差が出ているのは驚きなので、複雑な処理になっている時ほど処理を改善すると効果絶大です。処理速度にお悩みでしたらコード内にこういった処理が潜んでいるかもしれません。