Google Cloud Certified - Professional Cloud Architect を取得

Google Cloud Certified - Professional Cloud Architect を取得したのでメモ

Google Cloud Certified - Professional Cloud Architect とは？

公式サイトより

Professional Cloud Architect とは、Google Cloud の技術を組織が活用するために必要なクラウド アーキテクチャと Google Cloud Platform に関する専門的な知識を有することを認められ、ビジネス目標を実現するために、スケーラブルで高可用性を備え、堅牢でかつ安全な動的ソリューションを設計、開発、管理できる者

せっかくGCPに触れており、試験料も会社負担でできそうなので腕試しに受けてみることにした。

著者のバックグラウンド

• GCPは日常的に接している(教えたりする)が、他者の広い範囲の設計に携わることはない
• GAEやBigQuery、Dataflowなどアプリケーション寄りのことは詳しいがGKE、ネットワーク、VPCに関連することは多少触れた程度

勉強リソース

• 公式ドキュメント
• CourseraのArchitecting with Google Cloud Platform Specialization

基本的に公式ドキュメントを読み込んでおけば問題なさそうな印象を受けた。ただ全部読むのは難しいので大事なことを全体的に広く浅く学ぶにはCourseraのGCPに特化したコースが良かったと思う。本ならGoogle Cloud Platform エンタープライズ設計ガイドに目を通すといいかも。

自分の場合、VPC ネットワークやロードバランシング、GKEについてはこのコースでまず触れ、詳細を知りたいものに関しては公式ドキュメントを読み込んだ。 加えて、Courseraはクラスのまとめに試験があるのでテスト前日に試験をやり直して知識を確認するのも良いと思う。

また、クラウドアーキテクチャの試験であるためベストプラクティスを知ることも大切だと思う。GCPの方からゲームや分析フローに関してリファレンスアーキテクチャを含むブログがいくつか出ていて参考になったし、純粋に読み物としても面白かった。

• クラウド上のゲームインフラの概要
• アーキテクチャ: 分析イベントとログの大規模取り込みの最適化

試験を受けての所感

2018年11月に試験が刷新されたらしいが、まず第一印象として想像していたよりは難しかった。例えばCI/CDに関して特定のシナリオでデプロイを行いたい場合にリポジトリやビルドツール、GKEやGCEのどれをどのように組み合わせてどういったオプションを付けると思い通りの事ができるかという現実的かつ包括的な問題がいくつかあったし、そもそもオプションを知らないと答えられないような問題もあった。*1 個人的にはケーススタディに関連したの問題の方が簡単だった。これはコマンドのオプションのような問題は知っているかどうかの問題のため知らないと答えようがないが、ケーススタディは与えられたシナリオを解決するには何が必要かと考えるもので、各プロダクトで何ができるかとユースケースを知っていたら四択問題だと自然と答えは絞り込まれていくためだと思う。

おわりに

暫定合格はその場で出るが、正式な通知は次の日に来た。試験に受かるとバックパックかフリースが貰えるが、今回のタイミングではどれも品切れ中でしばらく待たないといけないらしい。 個人的にはこの資格に通ったからと言って直接的な恩恵はないが、クラウドアーキテクチャの質問をされたら前よりは自身を持って答えられる気がする。

*1:自分が自身のない問題はやはりGKEとGCEに関するものだった

Google Apps Scriptで野球部の成績管理を自動化してみた

背景

今年は会社の野球部で成績を可視化しており、チームが強い*1ため結果表は皆の平日中の楽しみの1つである。しかし入力はLINEでそれぞれのプレイヤーが申告したものをキャプテンが仕事中に手動入力しExcelにまとめ、結果は業務連絡のEmailに貼り付けられ送られておりキャプテンの負荷が大きように見えた(彼の趣味だけど)。この冗長な作業はエンジニアとして黙って見過ごせなかったのとGASに興味もあったのでいい機会と思って勉強しつつツールを作った。

成果物

• 成績入力フォーム

成績の入力はGASで定義され自動生成されたGoogle Formを使った。それぞれのプレイヤーが結果を入れたらデータは自動でGoogleスプレッドシートへ保存される。

入力フォーム

*結果表

GASではstaticなWebページを作成・公開をすることができる。サーバーはGoogleのものを使えてタダ。便利。

今回の利用では試合ごとの試合成績の表示、全試合でのトータルの成績表示、打撃指標でのランキングの作成と表示を自動で行う。 以下は名前が出ないように切り取ったもの。

打撃成績一覧

作り方

以下のスライドに実際に使った技術要素に触れつつGASは何ができるのかをまとめた。実際にどうやるかはキーワードをもとにググったらすぐに出ると思う.

ここで作ったコードはGitHubにアップした。初めてGASに触れて3日で打者用投手用入力から表示まで作れたがテストは書いてないし力技も多い。。。

Google Apps Script Overview from Tatsuya Fukui

www.slideshare.net

GASを使ってみた所感

思っていた以上に便利だった。G Suitesのドキュメントにプログラムから簡単にアクセスできてデータを扱え、WebサイトやFormの公開もできる。 プライベートで何か小さなことをするときには積極的に使っていきたいし、GCPのプロダクトとの組み合わせも試してみたい。

Useful Links

本家のサイト。必要な情報はほぼここにある。 developers.google.com

GASからのスプレッドシートの利用方法 qiita.com

GASを利用するときのプラクティス例 qiita.com

ローカル開発用のツール https://github.com/google/clasp

*1:4試合連続コールド！最高かよ！！

2015年に読んだ好みのIT本まとめ

今年読んで印象に残った・良かったと思った本をまとめてみた。IT以外の本も入っている。

人工知能は人間を超えるか (角川ＥＰＵＢ選書)

今年は人工知能がバズり、特にディープラーニングに注目が集まった。ディープラーニングは学習の過程で特徴を導き出し、自ら概念を作り出せる。Googleの猫の認識が有名。

この本では基本的な人工知能の仕組みやディープラーニングのアルゴリズムも紹介し、著者の人工知能に対する認識 ー タイトルの通り人工知能は人類を越えるのかについて書かれている。その答えには是非この本を読んで触れて欲しいし、著者の想いを感じた後に自身でも考える価値のあるテーマだと思う。

エリック・エヴァンスのドメイン駆動設計

おそらく多くの人は既に知っているドメイン駆動設計の本。ドメインはアプリケーションのコンポーネントの担当エリアのようなものであり、ドメインの中でモデルと設計・実装は相互に密接に結びつきお互いにフィードバックを与えあるべきであること、言葉は共通に使える”ユニバーサル言語”を仕様するべきであること、またドメイン間のやり取りは基本的に特定のインターフェース意外では行わないこと(e.g.車ドメインのハンドル、運転設備だけが人ドメインから見えエンジン等のコンポーネントは隠されている)等ソフトウェアを設計思想が詳しく書かれている。

厳密なDDDを行わないとしても、ソフトウェアアーキテクトとしてレベルを上げるためには必読の本。

コンサルタントの秘密―技術アドバイスの人間学

コンサルタントとして持つべきマインドセットが書いてある。 コンサルタントと言ってもいわゆる経営コンサル的なMECEやWhy So? So What?的な考え方ではなく(これらも学ぶ価値のあることでありロジカル・シンキング―論理的な思考と構成のスキル (Best solution) や考える技術・書く技術―問題解決力を伸ばすピラミッド原則が良本)、エンジニアやその他の職種にも当てはまる共通の問題に対する考え方やあるべき姿勢が書いてある。以下のキーワードが気になるなら読む価値あり。

• 問題の本質は常に人にある - 技術的問題に直面しているとしても元をたどれば人にある
• 問題の提示 - 問題を指摘することで同時にマネジメントの失敗を暴いてはならない。コンサルタントに依頼するということは何かしら問題・課題があるということ。
• オレンジジューステスト - 問題解決方の提示と同時にそのコスト・価格を提示する。出来る/出来ないのだけを答える人は信用出来ない。
• ゴーマン法則 - 欠陥を転じて機能とする。見つかった欠陥は必ずしも負ではなく、活かす道もある。

アプレンティスシップ・パターン　―徒弟制度に学ぶ熟練技術者の技と心得 (THEORY/IN/PRACTICE)

技術者として学ぶ姿勢や、これから出会う困難との立ち向かい方へのアドバイスが詰まった本。 師弟関係の考え方をベースとして、1. 自らの置かれている状況 2. 本来はどうあるべきか 3. 問題を決するために取るべき行動という形で「パターン」として紹介されている。

デッドライン

トム・デマルコによって書かれた、ソフトウェアプロジェクト管理についての小説。主人公はアメリカで仕事を辞めた後、美人に会ったと思ったら東欧の共産国でのプロジェクト運営に巻き込まれれる...小説。(大事なことなので二回言いました)

短すぎる納期、わからず屋の上司、メンバーの衝突など、プロジェクト運営でよくぶつかる共通の問題を物語の中に上手く取り込み、その対応方法や考え方を主人公トムキンスの学びとして紹介している。最後のオチも意外(?)で物語としてもIT本としても面白い。

ファスト&スロー(上) あなたの意思はどのように決まるか? (ハヤカワ・ノンフィクション文庫)

心理学、意思決定についての本。ファストアンドスローというタイトルの通り人間の思考には2通りあり、1つめのファストな方が直感、2つ目のスローな方が論理という考え方。

人は何かを見聞きした時、まずファストな思考が機能し、経験等から無自覚のうちにに答えを導き出す。対して、スローな思考が出てくると注意深く物事を観察、理解し順序立てて物事を考える。しかしこれらの思考は必ずしも独立して働かなかったり、アンカリングによる印象操作、ファストな思考に働きかけるハロー効果等などがあり、実験を通して人の考えや印象に影響をあたえるものは何か、人の解釈はどう働くのかについて研究されている。 UIやマーケティングの人は特に読む価値あり。

ポーカーの大会に参加してみた

今年の始めからテキサス・ホールデムというカジノでよく行われている形式のポーカーを始めた。 手元に2枚のカード、場には最終的に5枚のカードが公開され計7枚の中から好きな5枚を使用して役を作る形式のものだ。

ルール自体は簡単だが、チップの掛け方や相手との駆け引きなど奥が深い。

先日行われていた全日本ポーカー選手権(AJPC)に参加した所、あと10人いなくなったら入賞というところまで残って結局脱落してしまった。

トーナメント形式は初めてだったが、初心者でも打ち回し次第で経験の長い人と対等に渡り合えるのがポーカーの面白いところだと思う。(根拠のない手を打った方がだいたい負ける。)

出ているカードとポッドサイズ(掛けられたチップの量)から期待値を計算したり、これまでの相手の動きから相手の強さを予想して勝負するか引くか考えていく感じは、理屈で考えつつも感覚的なものも大切にするプログラマ好みの遊びなんじゃないかと勝手に思っている。

もっと一緒にやる人が増えたら嬉しいので気になったら試しに遊んでみて欲しいし、一人で勉強しづらいなら声をかけて欲しい。 ちなみに海外で行われているポーカーの大会は数億円という賞金がもらえるものもあり、日本の大会で勝ち進むとそういった大会に出れたりもする。

用途別で以下の本がオススメ

ルールを勉強したい人に

ポーカー教室

ルールは知っているがなかなか勝てない人に

フィル・ゴードンのポーカー攻略法 入門編 カジノブックシリーズ

トーナメントの戦い方を知りたい人に

アグレッシブポーカー　トーナメントを制覇しろ

オンラインポーカーで稼ぎたい人に

フィル・ゴードンのデジタルポーカー

後輩プログラマに入社する前に身につけて欲しい考えと技術要素

はじめに

組織でチームとして開発をすることは、趣味で行うプログラミングをや学生が研究のために開発をするのとはまた異なる知識やスキルが必要となる。本文ではチーム・業務環境での開発に明るくない人を対象としてその考え方の違いや、身につけて欲しい知識としてCI、テスト、DB周りの事を紹介する。

プロフェッショナルとして組織で開発するということ

学生や個人で開発をすることと、企業で開発をすることの大きな違いとして、金銭等を対価にシステムの運営を期待されていることや不特定多数との共同作業が求められることなどが挙げられる。

プロフェッショナルとして

企業で開発をするということは基本的にはお金を対価に製品・サービスを提供することだ。「僕の変更でちょっとシステム止まっちゃった、動くまで1時間待って」では済まないのである(最近たまに見る光景ではある)。"Don't Ship the Shit"だ。貴方の研究のアルゴリズムが間違ってたせいでプレゼン資料に誤ったデータを載せて教授に注意されるのとはわけ違うわけだ。

こういった問題を防ぎ、プロフェッショナルとして製品やサービスを提供するにはコードクオリティの向上が必要だ。今回紹介する技術要素は全てここに関わってくる。

チームとして

組織における開発はとにかく関わる人が多い。大学等での開発はほとんどが個人、もしくは先輩後輩で密にコミュニケーションの小さなチームで異なる部分に着目しての開発だろうか。 その点企業での開発はほとんどがチーム、多きなものでは数十、数百人がひとつのプロダクトを開発するために関わるだろう。 更に貴方のチームメイトは今一緒に働く人達だけじゃなく、将来入ってくる人々も貴方の加える変更の影響を受けるチームメイトなのだ。

この様に企業では不特定多数の人が関わり一つのものをつくり上げることを意識しなければいけない。

身につけて欲しい技術要素

CI (継続的インテグレーション)

CI (継続的インテグレーション)はソフトウェアのビルドやテストを継続的に行い、ソフトウェア品質の維持を保つための仕組みである。ここではgit、svnなどのバージョン管理システムから継続的デリバリなどの一連の流れを含めてCIとして挙げてある。

VCS (バージョン管理システム)

最近は学生等にも広く浸透していると思うがgitやsvnなどのバージョン管理システムは安定した開発を続けるために非常に重要だ。 既存のコードに変更を変更を加えて何かを試したいときにファイルの名前を変えたりコードをコメントアウトするのは筋が悪い。 行うべきはコードのコミットであり、後はツールが履歴の記録やdiffの生成を簡単に行ってくれる。

また、VCSを利用することでコードの共有が圧倒的に容易になる。チームで開発をするときにはひとつのリポジトリからコードを取得しメンバーの開発した成果は最終的にひとつのリポジトリに入れられる。この際は自分の成果が他のモノを壊していないか充分に確認してから行うべきだ。 自分の変更が他の人に共有される事を意識してコミット時のコメントは他のチームメイトや将来自分が見返した時に意図が伝わりやすいものを意識しよう。

GitHub実践入門 ~Pull Requestによる開発の変革 (WEB+DB PRESS plus)

Subversion実践入門:達人プログラマに学ぶバージョン管理(第2版)

コードレビュー

コードレビューはその名の通りコードの出来を皆で確認するプロセスだ。ここに辿り着くまでにはたいてい幾つもの苦労があるが、これも大きな関門だ。ある意味自分のデキのshowcaseであり、実力が判断される場だ。見苦しいshitを皆の前に出さないように気をつけよう。

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

CI (継続的インテグレーション)

個人での開発のレベルでCIをきっちりと行っている人は多くはないかもしれないが、CIは手間のかかるビルドをビルド自動で定期的に行う事を可能にし、その際ビルド結果に対するテストも可能にする。これを継続的に行うことでコードの異常を素早く発見することができ、自動化されているため一度設定してしまえば手間も少ない。多くの場合、JenkinsやTeamCityなどのツールが使われている。

環境にもよるが、共有リポジトリにコミットがあったらビルドを走らせるという設定をしている場は多いだろう。コミットは必ずビルド・テストが全て適切に行えるとローカルで確認してから行うようにしよう。(万が一共有のビルドをクラッシュさせた場合には直すまで鬼のように電話やメールがくるという可能性も否定出来ない。)

継続的インテグレーション入門

開発ツール徹底攻略 (WEB+DB PRESS plus)

継続的デリバリ

企業文化にもよるだろうが、多くの場合は変更が出来たらすぐに変更をリリースというわけではない。 1週間や1ヶ月に一度プロダクションリリースの日があり、その日を目標にある機能を作成しQA環境でのテスト、ユーザを巻き込んだUATをパスし準備万端の状態でリリースを行うことが望まれている。 きたるその日に備えて我々プログラマは日々コードとにらめっこするのだ。

個人的にはチェックイン後のビルドが走る度に最新のコードがQA環境に自動でデプロイされ、UAT環境には基本的なテストをパスしたRC(Release Candidate)のみがデプロイされるというような設定が好きだ。 UAT後の変更は有り得る話だが、基本的にUATまでには出来る限り全ての確認を終えあとはリリースをするだけだという状態で臨みたい。 最後に急な仕様変更を求めてくるクライアントはクソ食らえだ！

Jenkins実践入門　?ビルド・テスト・デプロイを自動化する技術 (WEB+DB PRESS plus)

チーム開発実践入門 ~共同作業を円滑に行うツール・メソッド (WEB+DB PRESS plus)

テスト

企業での開発はテスト！テスト！テスト！！だ。 学生時代に研究用のコードにテストを書いていた人はあまり見たことがないが、企業ではそうはいかない。 成果の出来を確認し、クライアントのもとに届けるまでにはユニットテスト、レグレッションテスト、インテグレーションテスト等々様々な切り口からのテストが必要となる。(それぞれのテストの意図がわからない人は今すぐググろう) テストを書くことは意図せぬ変更からチームメイトを守り、将来再びそのコードに訪れる自分を守ることに繋がる。

最近はコードの中で完結する従来のようなテストのみでなく、ユーザも巻き込んで仕様書をインプットとしたりテストケースをプログラムに詳しくない人にも書かせることを可能にしたFitnesseや、(マウス)ポインタをハイジャックして実際のGUIを用いてテストをするSikuliといったものまである。 テストに詳しくなって強固な開発基盤を構築する事を意識しよう。

JUnit実践入門 ~体系的に学ぶユニットテストの技法 (WEB+DB PRESS plus)

実践アジャイルテスト テスターとアジャイルチームのための実践ガイド (IT Architects’Archive ソフトウェア開発の実践)

DB (SQL)

ここではDBの設計等ではなく、SQLクエリの話だ。(余談だがEnglish SpeakersはSQLを”えすきゅーえる”と発音するのではなく"しーくる"と言う)

アドホックなクエリ、プログラムに組み込むクエリどちらの場合もとにかくパフォーマンスを意識するべきだ。 プロダクションDBでなにか探しものをするときに酷いクエリを走らせてCPUを専有しシステム全体のスループットを落としましたなどとなったら目も当てられない。

クエリの設計・実行を行う場合にはどのインデックスを使用するのか、クエリプランはどのようになるか、充分なフィルタはされているのか、ストアドプロシジャにするべきか否か等をよく考えてから行動をするようにして欲しい。

良記事：開発者のためのSQLパフォーマンスの全て

達人に学ぶ SQL徹底指南書 (CodeZine BOOKS)

SQLアンチパターン

まとめ

以上で新人のプログラマに働く前に最低限抑えて欲しいことを挙げたが、実際に働き出したらここに挙げたような事でもわからないことに多くぶつかると思う。 そんな場合にはこんなことを聞いてもいいのかと思い悩まずにどんどん先輩に質問して欲しい。 多分先輩社員はなんだかんだ後輩が来るのが楽しみであるだろうし、新人の成長はチーム全体の生産性の向上につながるのでそのための協力は惜しまない。 この文を読んでくれた人が良いデベロッパとして楽しい環境で開発を続けられることを祈っている。

IDEA IntelliJにおけるGroovyの開発環境設定メモ

IntelliJでGroovyを導入しようと思ったら思ったより手間取ったのでメモ。

IntelliJでprojectを作ると最初にに[No library selected]というメッセージが出てSDRの指定を要求される。ここでSDKを見つけるのに時間がかかった。

homebrewを利用してインストールしてした場合には"/usr/local/Cellar/groovy/"がインストールパスとなり、IntelliJでは"/usr/local/Cellar/groovy/[version]/libexec"をSDKのパスとして指定。

しばらくはPythonを離れてGroovyで精進しないと。。。

プログラミングGROOVY

Groovyイン・アクション

2014年に出版された好みのIT関係本まとめ

2014年に読んだ本の中から主に2014年(及び2013年)に出版された自分好みの本をざっとリストアップする。

APIデザインの極意 Java/NetBeansアーキテクト探究ノート

タイトル通りAPIデザインについて詳しく書かれた本。読者としてはJavaデベロッパを想定しておりJava特有のJDKのバージョン互換性やソースコード互換性に言及しているが、OOPの素養がある人なら読み進められると思う。なおカバーの隅には「※本書はプログラミングの初心者向けではありません。」などと書いてある。

APIデザインの極意 Java/NetBeansアーキテクト探究ノート

Javaエンジニア養成読本 [現場で役立つ最新知識、満載!] (Software Design plus)

最近のJava事情についてエンタープライズ用から普通?のJava、またJava8で導入された機能についてざっと書かれている。普段Java以外の言語でプログラミングをしている人にオススメ。普段からJavaを扱っている人も立ち読みですましたら充分だと思うけど一度手にとって眺めてみたら新しい発見があるかも。

Javaエンジニア養成読本 [現場で役立つ最新知識、満載!] (Software Design plus)

人月の神話【新装版】

銀の弾丸でおなじみ人月の神話。本来ならこの本は10年前に出版されているのだが新装版が2014年に出ているのでここに挙げる。 このバージョンでは最初の人月の神話が出版されてから20年が経ち、初版からの反省点やより主張を強めた点が述べられている。 今日では初版の発行より40年が経っているわけだがこの本で述べられた内容は未だに実際の現場でも当てはまる点が多く、ソフトウェア開発の本質に多く触れられている。 (銀の弾丸、欲しい。）

人月の神話【新装版】

おもしろいゲームシナリオの作り方 ―41の人気ゲームに学ぶ企画構成テクニック (GAME|DEV|LAB)

FFやひぐらしの鳴く頃に、GTAなどの実際のゲームで例を挙げつつストーリーのインタラクティブ性や分岐によってゲームを5つのタイプに分けて説明している。自分は普段ゲームを作るわけでもなくプレーもそこまでしないがなるほどと思いつつ、ついつい見入ってしまった。 また、シナリオの組み立て方として"ヒーローズ・ジャーニー"のフレームワークを紹介しており、ストーリーは旅立ち、通過儀礼、帰還の三幕に分けられ、各幕はさらに細分化される。これはシナリオを作ってみたい、作り始めたばかりという人には必見だろう。 三幕構成についてはこのブログがおすすめ。

ちなみに、友人曰くクロノトリガーをやってない人には人権が無いらしい。

おもしろいゲームシナリオの作り方 ―41の人気ゲームに学ぶ企画構成テクニック (GAME|DEV|LAB)

アルゴリズムが世界を支配する (角川ＥＰＵＢ選書)

この本にはこちらの記事でも触れたが、アルゴリズムは進化を続け私達の生活にどんどん入り込んでくる。その実例にこの本で触れ、今後の超情報社会との付き合い方を考える切っ掛けにしたら良いだろう。

アルゴリズムが世界を支配する (角川ＥＰＵＢ選書)

ルールを変える思考法 (角川EPUB選書)

角川ドワンゴ会長の川上量生氏のインタビューをまとめた本。自分は元記事ゲーマーはもっと経営者を目指すべき！ - 4Gamer.netをずっと追っており、Webの削られてない部分にも大事なものが含まれているので個人的にはWebで読むのがオススメ。川上氏独特の世界観により解釈された、次世代のコンテンツ業界およびインターネット全体の行く末を考える上で重要な要素がそこら中に散りばめられている。

本が出た後の元記事でも特に以下のものは必読。

電王戦は，21世紀を生きる人類を映し出す鏡なのかも――将棋棋士・谷川浩司氏がゲストの「ゲーマーはもっと経営者を目指すべき！」第16回 - 4Gamer.net

人類は「機械が生み出す知財」にどう向き合うべきか――SF作家・藤井太洋氏がゲストの「ゲーマーはもっと経営者を目指すべき！」第19回 - 4Gamer.net

任天堂・岩田氏をゲストに送る「ゲーマーはもっと経営者を目指すべき！」最終回――経営とは「コトとヒト」の両方について考える「最適化ゲーム」 - 4Gamer.net

ルールを変える思考法 (角川EPUB選書)

2014の読書関連ではこのブログ 2014年に読んだ技術書で良かったもの - うさぎ組 も俺好みでした。

感想・意見ありましたらTwitterでご連絡下さい。現場からは以上です。