RAKUS Developers Blog | ラクス エンジニアブログ

株式会社ラクスのITエンジニアによる技術ブログです。

新人エンジニアが「JavaScriptで遊ぶ」べき3つの理由

こんにちは。エンジニアのmickey-STRANGEです。 今まではめんどくさがりをテーマに、「簡単に○○する方法」を紹介してきました。

tech-blog.rakus.co.jp

今回の記事では、3年目になった私が、これまでのエンジニア生活の中でやっててよかったと感じる「JavaScriptで遊ぶ」ことについてお話したいと思います。

エンジニアになると周りから「勉強しといた方がいいよ」「いろんな技術触っといた方がいいよ」と声をかけられることが多いと思います。 しかし、何から手を付けていいか分からない、どんな技術を、どんな言語を触ってみればいいか分からない、と最初は思うかもしれません。
そういった新人エンジニアの方が勉強と気負い過ぎず、軽い気持ちで「JavaScriptで遊ぶ」ことから始めるメリットについてお話していきます。

実行環境の準備が要らない

JavaScriptの実行環境はブラウザです。勉強を始めるための環境構築というフェーズが必要ありません。 テスト用のHTMLファイルさえ用意してしまえばブラウザで開くだけで実行してくれます。

ただ、最初はHTMLの記述とJavaScriptの記述を同時に考えるのが難しいと思います。そんな時は普段見るサイトのHTML構成をそのまま引っ張ってくることをお勧めします。 実際に公開されているHTML構成なので作り込みがされていて、簡単にしっかりとしたテスト用HTMLを用意することができます。 こうすることで、自分でベースのHTMLを用意しなくてもJavaScriptの練習が出来るようになります。

環境構築が必要ないのは、とっつきやすさという面でかなりの強さになりますね。

実際に使える業務知識が得られる

JavaScriptは業務でもよく使う言語です。Web系エンジニアなら当然、画面上の動きはJavaScriptで記述することになります。 とはいえ、非同期処理があったり、画面上のユーザ操作との兼ね合いがあったりで、実行順が分かりにくくなる傾向があり、私の周りでもJavaScriptに対して苦手意識を持つメンバがちらほらいます。

私も最初はそうでしたが、JavaScriptでちょくちょく遊んでいた結果、大規模な画面改修タスクを担当することになっても怯まなくなり、今では苦手意識は自分ではほぼないと感じています。

また、JavaScriptはもはやブラウザ上だけの言語だけではなく、JavaScriptベースの言語でネイティブアプリの画面を構成できたり、サーバサイドの処理を記述したりすることもできます。 以前投稿されたGASも、JavaScriptベースの言語だったりします。

tech-blog.rakus.co.jp

JavaScriptは他の言語と比べて、得た知識がどこかで業務に繋がる可能性の高い言語であるといえるでしょう。

小さな改善がすぐにできるようになる

普段見るサイトやブラウザアクセスするシステムの画面に対して、使いにくいなーめんどくさいなー、と思ったことはありませんか? そんな時はchrome拡張機能のTampermonkeyがおすすめです。

chrome.google.com

Tampermonkeyは、指定したURLのページが開いたときに自動でJavaScriptを実行してくれる拡張機能です。 これを利用することで、普段使うシステムの画面をちょっと使いやすくする、といったことが気軽に行えます。
また、作成したスクリプトは他のメンバのTampermonkeyの画面に貼り付けしてもらうだけで共有が出来るので、小さな改善をすぐチームに共有することが出来ます。

私も社内の基幹システムの膨大な数のメニューをいい感じに検索出来るスクリプトを作成して、チーム内に共有していたのですが、いつの間にか広まっていき、他のチームの方から感想をいただくこともありました。 用事がない限り他チームの方に話しかける機会はあまりないので、こういった面でもとてもよかったと思います。

さいごに

私が感じた「JavaScriptで遊ぶ」ことで得られたよかった点をまとめてみました。いかがでしたでしょうか。 とっつきやすく業務に繋がりやすく改善にもつながる、というのはかなりのメリットだと思います。
また、JavaScriptajaxを用いることで他システムのAPIを叩くことも可能ですので、1つのスクリプト内で出来ることの幅がかなり広いです。

「勉強しよう」と思うと難しいかもしれませんが、このページのここをこうしたいな、を原動力に「JavaScriptで遊ぶ」感覚で手を付け始めると楽しさが分かっていただけるかと思います。 楽しいという感覚になってしまえば勝手に持続するので、遊び感覚でスキルアップしてみましょう!

新卒社員&ベトナムメンバーの歓迎会を開催いたしました!

はじめに

エンジニアのFM_Harmonyです。
Rakus Developers Blogには、何度か記事を投稿させていただきました。

tech-blog.rakus.co.jp ↑前回の投稿記事はこちらです

さて、今年も早いもので7月初旬に開発部へ新卒社員が配属されました。
また、同時期にオフショア先のベトナム子会社から出張者の受け入れを行いました。

そこで先日、新卒社員&ベトナムメンバーの歓迎会を開催いたしました!
歓迎会の内容をまとめましたので、みなさまにラクス社内の雰囲気が伝われば幸いです。

交流の様子

f:id:FM_Harmony:20180731115223j:plain

まずは自己紹介から行いました、名前と顔を覚えていただくのは重要です。

f:id:FM_Harmony:20180731115100j:plain

今回は、普段のビアバッシュで用意しているものよりも、豪華な食事をご用意させていただきました!
参加された方に伺ったところ、みなさんご満足いただけたようで何よりです。

f:id:FM_Harmony:20180731115118j:plain

普段はなかなか話す機会のない、先輩や管理職の方ともこうして話す機会を設けることができるのが、歓迎会のよいところです。
新卒の方も積極的に話しかけています。

f:id:FM_Harmony:20180731115206j:plain

ベトナムのメンバーの方はすっかり日本のメンバーとも打ち解けられようで、こうして記念撮影も行っておられました。

アイスブレイク:ペーパータワー

会の終わりごろには、アイスブレイク(Ice break)としてペーパータワーというゲームを行いました!
簡単に説明しますと、A4用紙20枚を使って最も高いタワーを作ったチームが勝利するというゲームです。

では、ゲームの様子を写真とともにご覧ください。

ルール紹介

今回は以下のようなルールでゲームを実施いたしました。

  • 1チーム4~5名で行う
  • 2回ゲームを行い、それぞれで勝利チームを決定する
  • 作戦を検討する時間は5分、実際にタワーを組み立てる時間も5分とする
  • 利用して良いのは、A4用紙20枚および紙テープ1m分のみとする

↓ルールはこちらのサイトを参考にさせていただきました
heart-quake.com

↓ルール紹介の様子、彼の厳正な審査により各チームの勝敗が決まります f:id:FM_Harmony:20180725195741j:plain

作戦タイム

↓あるチームの作戦会議の様子、このプランニングにより作業がスムーズに行えるか決まります f:id:FM_Harmony:20180725195906j:plain

↓別のチームの様子、紙を片手に作戦会議中です
f:id:FM_Harmony:20180725195913j:plain

ベトナムメンバーの方々は1チームとして集まっていただきました
f:id:FM_Harmony:20180725195936j:plain

続いて実際の組み立ての様子といきたかったのですが、残念なことに撮影担当者もゲームに参加していたため、組み立て時の写真はありませんでした…
そのため、結果発表の様子に移りたいと思います。

結果発表

↓計測の様子、タワーが倒れないようみなさん必死です
f:id:FM_Harmony:20180725202210j:plain

↓中には予想外の組み立て方をされたチームも!
f:id:FM_Harmony:20180725202215j:plain

肝心の結果はどうなったかというと、なんと2回ともベトナムメンバーチームの勝利でした!!

↓成果物と一緒に記念撮影、みなさんおめでとうございます!
f:id:FM_Harmony:20180725200855j:plain

おわりに

というところで、今回はここまでとさせていただきます。
この記事を通して、みなさまにラクスという会社の雰囲気を伝えることができたのであれば幸いです。

今回は私もイベント開催を担当したのですが、本当に楽しい歓迎会を開催することができて良かったです。
また、新人やベトナムの方だけでなく、私たちも普段あまり話す機会のない方とお話しできたことも良かったと思いました。

最後になりますが、新卒の方にはこれからの活躍を、ベトナムの方には日本で貴重な経験が得られるよう、心から祈っております。

この前登壇してた人にまたもインタビューしてみた

こんにちは。開発エンジニアのamdaba_sk(ペンネーム未定)です。

前回の冒頭で、ちょろっと以下のように書きました。

「OWASP ZAPについて調べてみた」という記事を書きました。単体テスト中にこっそり使ってみようかと思っていたのですが、手元の環境ではポート待ち受けでエラーが出てしまって放置しています……。

この件について、実はポート番号を選べばローカルプロキシとして使えそうだということがわかったのでそのことで続報を、と思ったのですが。

いいタイミングでまたもあの人が目立ってくれましたね!

2018.kphpug.jp

tech-blog.rakus.co.jp

先日開催された PHP カンファレンス関西 2018 にラクスのエンジニアが登壇しました。我らが坂田くんがそのうちの一人として参加しています。

当日は私も見に行きました。開始前のえらく緊張してそわそわしている姿と、発表中の堂々と話す姿のギャップが激しかったのがすごく印象的でした。

というわけで、このブログへの次の投稿もこれをネタにするしかあるまいと思った次第です。例によって雑談に見せかけてまた坂田くんにインタビューしてみましたので、その時の話を今回は書こうと思います。 (※本人了承済み。ただし写真は気恥ずかしいのでやっぱりNGだそうです。ほんともう今さらな感じもしますが)

なおイベントそのものと、弊社がこのイベントに公式に参加することになった経緯などについてはリンク先をご覧ください。

カフェスペースにて

PHPカンファレンス関西の開催された翌週、私はいい感じに話を聞けるタイミングを見計らっていました。坂田くんは何やら忙しそうで、なかなか昼食もいっしょに行けない様子。無理に時間を作ってもらうのも悪いのでどうしたものかと思っていたところ、ちょっとした休憩でも取るつもりなのかコップを持って執務室を出ていく坂田くんの姿が。私はチャンスとばかりに後を追いました。

ペンネーム未定(以後ペン未)「というわけでお話をしましょう」

坂田くん(以後 坂田)「何が『というわけ』なんだ……。ていうかそのメモ紙とペンは何? またブログのネタにされるやつ?」

ペン未「ちっ、君のような勘のいいガキは……」

坂田「嫌いだというなら無理にお話しなくてもいいのだけど」

ペン未「いやいや好きだから。もうめっちゃ好き。察しがよくて助かるわ~」

スピーカーディナーのこと

ペン未「前日にも業務後に何か行ってたよね?」

坂田「スピーカーディナーっていうのに参加してた。当日はお互い発表があって話す時間が取れないからだと」

ペン未「飲み会自体あんまり好きじゃないって言ってたのによく行く気になったね」

坂田「せっかくの機会だからと思って。社外の人と交流する機会もあんまりないし」

ペン未「どんな感じだった?」

坂田「ネットの知り合いとのオフ会って感じだった。みんな私服だし、『もしかして、○○さんですか?』みたいな声のかけ方とかも。全員集まるまで適当にだべってる感じもまさしく」

ペン未「へー。その場にいた人はみんなお互い初対面だった感じ?」

坂田「いや、けっこう知り合いって感じの人も多かったかな。毎回登壇してるような人とか、現運営、元運営みたいな人達はお互いに知り合いで、むしろ私みたいな新参者の方が珍しかったような印象。それもあってちょっと話に加わりづらい感じがした」

坂田「でも実行委員長の人は席も近かったしけっこう話せた。そういえば今回はスポンサーの応募も例年よりすごく多かったみたいで、しかも初めてスポンサーするってところも多かったらしい。それで問合せがいっぱい来て対応が大変だったとか」

ペン未「そうなんだ。それはちょっと申し訳なかった感じがあるね……」

当日のこと

ペン未「発表直前はめっちゃそわそわしてたよね。坂田くんでも緊張するんだって思った」

坂田「私だって緊張ぐらいします。ビアバッシュの発表のときだって緊張してるんですが」

ペン未「全然そうは見えない」

坂田「それ他の人にも言われたんだけど。なんでそう見られているのか……」

ペン未「それは君がそういう振る舞いをしているからとしか言いようがないけど。でもあの時はことさら緊張してたってことでしょう?」

坂田「まあね。発表が始まってからは多少落ち着くんだけど、発表前の5分間は結構つらかった」

ペン未「発表前にパソコントラブルもあったしね」

坂田「そうそれ。私の持ってる唯一のノートパソコンが元XPで現Linux搭載の古いやつで、もともと使えるかどうかわからないねって話はしてたのだけど。VGAのケーブルがあったから自分のパソコン繋げられると思っのに、いざ繋げてからパソコン起動させてみるとなぜかログインできなくなっているという。わけが分からなかったし時間も無かったから急遽パソコンを貸してもらった」

ペン未「あせってパスワードミスってただけでは」

坂田「間違ってはいなかったと思うのだけどなあ。後でVGAを外してから同じようにログイン試行してみたら普通に入れたし」

ペン未「まあでも発表始まったら急にスイッチ入った感じだったよね。なんか練習よりも一段と分かりやすくなってたような気がするし。何か準備してた?」

坂田「別に直前に特別なことはしてない。スライド見返すとかその程度で」

ペン未「それで話せるとかすごいな。時間もほぼぴったりだったよね」

坂田「時間は、実はちょっと遅いかもって思ってた。一回時計を見たのだけどいつ始まっていつ終わらないといけないのかわからくなって、もういいやって」

ペン未「まじで。それめっちゃ不安じゃない?」

坂田「今思うと不安なんだけど、発表中はなぜか時間のこと忘れてられたんだよね。不思議なことに」

坂田「でも発表中に出ていっちゃた人がいたのは残念だったなあ」

ペン未「あー、そういえばいたね。でもそれって仕方ないんじゃない?」

坂田「そうかもしれないけど。でも今思い返してみると、確かに『Laravelの良かったところ』のセクションは確かに聞いててつまらないかもとも思うんだよね。Laravelの宣伝してるだけみたいな感じになってて。といってもどう変えればいいのかよくわからないのだけど」

ペン未「まあそれは今後の課題ということで。また同じような発表をする機会があればその時考え直してみるといいですね」

坂田「そうですね。そう頻繁に同じような発表をすることになっても困るけど」

そして仕事はつづく

まだまだ話は引き出せそうでしたが、息抜きには十分なほどに話をしていました。 私たちは話をするうちに飲み干してしまったお茶を入れなおし、自席に戻りました。

これからは会社としてもPHPカンファレンスのようなイベント、勉強会への参加を推進していくとのことなので、坂田くんに活躍してもらう機会が今後もたびたびあるのでしょう。 私は心の中でエールを送りつつ、先ほど聞いた話をブログにまとめるべくキーボードをたたくのでした。

PHP カンファレンス関西 2018 に登壇してきました

@kawanamiyuu です。以前の投稿でお知らせしましたとおり、先日開催された PHP カンファレンス関西 2018 にラクスのエンジニアが登壇しました。 また、ラクスはシルバースポンサーとしてイベントに協賛いたしました。

f:id:kawanamiyuu:20180720104230j:plainf:id:kawanamiyuu:20180720104256j:plain
f:id:kawanamiyuu:20180720113549j:plainf:id:kawanamiyuu:20180720114104j:plain

イベント概要

2018.kphpug.jp

登壇

チャットディーラーの高速開発を支える Laravel(30分セッション)

speakerdeck.com

f:id:kawanamiyuu:20180720111516j:plain

(本人コメント)

PHP カンファレンスに限らず技術系のイベント初参加でした。最終的に私が登壇することになりましたが、会社としての参加が決まってからネタ出し、アウトライン作成、資料作成、発表練習等、最後までチームで準備を進めました。当日もちろん緊張はしましたが、不安を感じずに発表ができたのはチームのみんなのおかげです。 また発表以外の時間では聞く側としても楽しめましたし、勉強にもなりました。これからはもっと積極的にこういった社外のイベントや勉強会に参加してみようかなと思い始めています。

mixed 型なんてけしからんと社内チャットでつぶやいたら炎上した(ライトニングトーク

私、@kawanamiyuu も実はライトニングトークが採択されましたので話してきました。

speakerdeck.com

f:id:kawanamiyuu:20180720104725j:plain

(本人コメント)

今回がカンファレンスでの初 LT 体験でした。ネタはけっこう前から温めていて、社内のビアバッシュとかで話そうかと思っていましたが、今回弊社のエンジニアが 30 分セッションにも登壇するし、LT もやったれ!と思って応募したら採択されて、ドキドキしたけどとても楽しめました。 イベント 2 日前にオフィスで行った公開発表練習では 1 分半も時間が余ってしまい焦りましたが、自主練の結果、本番では時間ちょうどくらいで終われて安心しました。ほんとうはドラを鳴らされてみたかったです (^m^)

所感

今回、ラクスにとって初めての技術イベントへの協賛および登壇でした*1。いろいろ勝手が分からず、ちゃんとイベント当日まで漕ぎ着けることができるか不安でしたが、担当サービスを横断した登壇推進チームで協力して資料作成や発表練習を行い、当日、自分の会社のエンジニアが目の前で発表している姿を見てとても嬉しくなりました。 今後も継続して技術イベントに登壇していけるよう、また、コミュニティに貢献していけるよう、開発組織のレベルアップやエンジニアリング文化の醸造に取り組んでいきたいと思います。

*1:これまでも弊社のエンジニアがプライベートで技術イベントで登壇することはありましたが、開発部の公式な取り組みとして登壇や協賛を行ったのは初めてでした。

【図多め】APIを使ってGoogleサービスを操る

Google APIとは、Googleが提供するのサービスやプラットフォームを扱えるAPIです。 これらのAPIを使いこなすことで、Googleのサービスを自身のアプリケーションへ組み込み、様々なことを実現できます。

ここでは、Gmailを扱うAPIと、GoogleDriveを扱うAPIPHPアプリケーションから利用する例に紹介します。 (内容は2018年7月現在の情報です。)

この記事の内容

今回は、Google APIのガイドに記載されているQuickstartを用いて、OAuth認証を行いAPIを実行します。*1

概要は以下の図のような感じです。

この記事では、「その1:プロジェクトの用意」で、Google Cloud プラットフォームにプロジェクトを用意し、 「その2:認証情報の作成」にて、OAuthに必要な認証情報ファイルの作成、 「その3:APIを叩く」でサンプルプログラムを用いて上記図の①~④に示す認証処理とAPIの実行を行います。

少し内容が長くなってしまったので、目次を見て必要な情報のところをご覧ください。

(余談ですが、恥ずかしながら、この記事を書くまで、私は「OAuth」を、他のシステムで認証するから「Other Auth」の略だと思っていました。正しくは「Open Auth」ですね。。。)


その0:Googleアカウントの用意

言わずもがな、APIを利用して操作するGoogleアカウントが必要です。 詳しい方法は割愛。作成したら、ログインしてください。


その1:プロジェクトの用意

APIを利用するため、Googleアカウントに紐づいたプロジェクトを作成する必要があります。

プロジェクトを作成する

使用するGoogleアカウントにログインしたら、Google Cloud プラットフォームにアクセスしましょう。

左上のハンバーガーメニューから、「IAMと管理 > リソースの管理」を選択します。

リソースの管理画面に、「プロジェクトを作成」リンクがあるので、クリックします。

その後の画面でプロジェクト名を入力し、「作成」します。 これでプロジェクトが作成できました。 (少し画面表示に時間がかかることがあります。)

プロジェクトで使用するAPIを指定する

次に、作成したプロジェクトで使用するAPIを指定します。 Google Cloudプラットフォームの画面上部から、先ほど作成したプロジェクトを選択した状態で、「APIとサービス > ライブラリ」を選択します。 ここでは、使用することができるGoogleAPIライブラリを選ぶことがあります。 どのAPIも面白そうですが、とりあえず今回は「Gmail」と「GoogleDrive」を利用するので、まず、「Gmail API」を探し、「有効にする」を選択します。 これで、このプロジェクトでGmail APIを有効にすることができます。 なお、この画面からはGmail APIのガイドやリファレンスなどのドキュメントを閲覧することができます。

同様に、「Google Drive API」を、APIライブラリから探し、有効にします。

これで、使いたいAPIを有効にしたプロジェクトが作成できます。


その2:認証情報の作成

さて、プロジェクトは準備できましたが、APIを叩くにあたり、認証が必要です。 次は認証情報を作成し、自分が作成するアプリケーションからのリクエストのみを受け付けるようにしましょう。

Google Cloudプラットフォームの画面上部から、先ほど作成したプロジェクトを選択した状態で、「APIとサービス > 認証情報」を選択します。

その後、「認証情報を作成」から「OAuth クライアント ID の作成」をクリックします。

OAuth 2.0 クライアント ID を作成する

OAuthの設定をするにあたり、まずはAPIを叩くアプリケーションの種類を指定します。

今回は、「その他」を選んでください。APIガイドに載っている「Quickstart」を使うためには、「その他」を選ぶ必要があります。 選択したら、クライアントの識別名を入力し、作成します。

OAuth 2.0 同意画面を設定する

次に、 OAuth 2.0 同意画面の設定を行うため、 「認証情報を作成」から「OAuth 2.0 同意画面」を選択します。 OAuth 2.0 同意画面とは、設定しているAPIによってユーザのデータへアクセスするときに、表示される画面で、データへのアクセス前に認証を行う画面のことです。

この画面で認証を行うため、メールアドレスと、表示する任意のアプリ名を指定します。 ここで指定したアプリ名は、以下のように認証画面にて表示されます。

設定出来たら「次へ」ボタンを押下します。

これで認証情報の作成が完了しました。

ハンバーガーメニューから、「APIとサービス > 認証情報」を選択すると、認証情報が作成できていることが確認できます。


その3:APIを叩く

次に、アプリケーションからGoogle APIの認証を行い実際にAPIを実行します。

ここからはGmail APIの公式ドキュメントを参考にしながら進めましょう。 「APIとサービス > ライブラリ」から「Gmail API」を探し出し、「チュートリアルとドキュメント」の「Learn more」をクリックし、公式ドキュメントを表示します。

表示したら、「ガイド」タブの「Quickstarts」から、使用する言語を選択します。 今回はPHPで説明します。他の言語でAPIを扱いたい場合は、対象の言語を選択して、頑張ってください。(←丸投げ)

PHPのQuickstartでは、Step1~Step4の手順が紹介されていますが、Step1のAPIを有効化する手順はもう完了しているので、Step2から行います。

Google Client Libraryのインストール

QuickstartのStep2です。GoogleAPIを使用するために、Google Client Libraryをインストールする必要があります。 PHPの場合、composerを用いることで簡単にインストールできます。

composer require google/apiclient:^2.0

認証情報をダウンロード

先ほど作成したOAuth2.0クライアントの認証情報が記載されたJSONファイルをダウンロードします。 Google Cloud プラットフォームのメニューから、「APIとサービス > 認証情報」を選択し、先ほど作成したOAuth2.0クライアントのダウンロードアイコンをクリックすることで、ダウンロードできます。

ダウンロードしたクライアントの認証情報ファイルは、次のサンプルプログラム実行で使います。

サンプルプログラムの作成

QuickstartのStep3です。quickstart.phpという名前で以下のコードを保存します。

<?php
require __DIR__ . '/vendor/autoload.php';

if (php_sapi_name() != 'cli') {
    throw new Exception('This application must be run on the command line.');
}

/**
 * 指定した権限が付与されたAPIクライアントを返す
 * @return 権限が付与されたGoogle_Clientオブジェクト
 */
function getClient()
{
    $client = new Google_Client();
    $client->setApplicationName('Gmail API PHP Quickstart');
    $client->setScopes(Google_Service_Gmail::GMAIL_READONLY); // ※1:スコープの設定
    $client->setAuthConfig('credentials.json');  // 取得したJSONファイルのパス
    $client->setAccessType('offline');

    // クライアント証明書ファイルが存在しない場合(初回実行時)は
    // 認証情報JSONファイルを用いて取得する。
    // 存在する場合(2回目以降の実行時)は、クライアント証明書を読み込む。
    $credentialsPath = 'token.json';  // クライアント証明書ファイルのパス
    if (file_exists($credentialsPath)) {
        $accessToken = json_decode(file_get_contents($credentialsPath), true);
    } else {
        // ユーザからの認証を行う
        $authUrl = $client->createAuthUrl();
        printf("Open the following link in your browser:\n%s\n", $authUrl);
        print 'Enter verification code: ';
        $authCode = trim(fgets(STDIN));

        // 認証コードをアクセストークンに変換する
        $accessToken = $client->fetchAccessTokenWithAuthCode($authCode);

        // クライアント証明書をファイルに保存する
        if (!file_exists(dirname($credentialsPath))) {
            mkdir(dirname($credentialsPath), 0700, true);
        }
        file_put_contents($credentialsPath, json_encode($accessToken));
        printf("Credentials saved to %s\n", $credentialsPath);
    }
    $client->setAccessToken($accessToken);

    // クライアント証明書が有効期限切れの場合は更新し、ファイルへ保存しなおす
    if ($client->isAccessTokenExpired()) {
        $client->fetchAccessTokenWithRefreshToken($client->getRefreshToken());
        file_put_contents($credentialsPath, json_encode($client->getAccessToken()));
    }
    return $client;
}

/**
 * メイン処理
 */
// APIクライアントを作成し、サービスオブジェクトを作成する
$client = getClient();
$service = new Google_Service_Gmail($client);  // 使用するAPIごとのサービスオブジェクトを作成

// Print the labels in the user's account.
$user = 'me';
$results = $service->users_labels->listUsersLabels($user);

if (count($results->getLabels()) == 0) {
  print "No labels found.\n";
} else {
  print "Labels:\n";
  foreach ($results->getLabels() as $label) {
    printf("- %s\n", $label->getName());
  }
}

上記コードでは、大きく分けて、以下の処理を行っており、一部APIの実行目的によって変更する必要があります。

  • APIクライアントオブジェクトの取得
    • クライアント証明書の取得と更新
    • APIクライアントオブジェクトの作成
  • 利用するAPIのサービスオブジェクト作成

APIクライアントオブジェクトの取得

APIを実行するクライアントのオブジェクトを作成します。 作成時には、先ほどダウンロードした、クライアントの認証情報を利用して、クライアント証明書を取得し、ファイルに保存します。 クライアント証明書には、特別な設定をしない限り利用期限があり、利用期限が過ぎていた場合は更新されます。

また、クライアントオブジェクトを作成する際に、「スコープ」を指定します。 「スコープ」は、そのクライアントが、APIを用いて「どこまでの操作が実行できるか」を指定するものです。(コード内コメント※1) スコープはAPIを使って何を実行したいのかによるため、場合によって書き換える必要があります。 スコープは各サービスオブジェクトの定数を指定するか、APIガイドにあるURIを指定することで、設定できます。

たとえば、Gmailでメールを送信したい場合は以下の通りに書き換えます。

$client = new Google_Client();
$client->setScopes(Google_Service_Gmail::GMAIL_SEND);

Google Driveでファイルをアップロードしたい場合はこんな感じ。

$client = new Google_Client();
$client->setScopes(Google_Service_Drive::DRIVE);

複数のスコープを指定する場合は、定数を配列に格納することで可能です。

$client = new Google_Client();
$scopeList = array(Google_Service_Gmail::GMAIL_SEND, Google_Service_Drive::DRIVE);
$client->setScopes($scopeList);

利用するAPIのサービスオブジェクト作成

取得したクライアントオブジェクトを利用して、各サービスのAPIを扱うためのサービスオブジェクトを作成します。 ここは各サービスごとに異なるため、ドキュメントをご覧ください。 作成したサービスオブジェクトを使うことで、そのサービスのAPIリクエストが可能になります。

サンプルプログラムの実行

作成したサンプルプログラムをコマンドラインから実行します。

$ php quickstart.php

実行すると、URLが表示され、入力待ちになりますので、表示されたURLへブラウザからアクセスしてください。 アクセスすると、認証情報の作成時に設定したOAuth 2.0の同意画面が表示されますので、画面に従って実行を許可してください。アクセストークンが表示されるので、コマンドラインにコピペすることで、クライアント証明書を取得することができます。

次回実行時からは、この作業で取得したクライアント証明書をもとに認証を行うため、同意画面での実行許可は不要になります。

また、サンプルプログラムはGmailAPIガイドから取得しましたが、この認証で今回作ったプロジェクトへの認証ができるので、他APIも利用可能になります。

これでAPIを実行する準備はできました。 あとは各サービスオブジェクトのメソッドを使ってGmailを送ったり、Google Driveを操作したりできます。

例として、Gmailでメールを送るときのコードを記載します。*2

/**
   * Gmailを送信する
   */
  public function sendGmail($client) {
    $data = "";
    $data .= "To:xxxx@xxx.xxx.xx\n";
    $data .= "Subject: メールたいとる\n";
    $data .= "\n"; // ヘッダーと本文を区切る空行
    $data .= "本文";

    $data = base64_encode($data); //base64エンコード

    $service = new Google_Service_Gmail($client);
    $msg = new Google_Service_Gmail_Message();
    $msg->setRaw($data);
    $result = $service->users_messages->send('me', $msg);
    return $result;
  }

◆TECH PLAY
techplay.jp

◆connpass
rakus.connpass.com

Swiftのextensionとprotocolについて

はじめに

ラクスエンジニアのstrongWhiteです。今回はSwiftのextensionとprotocolについて書きます。
私がSwiftを勉強し始めたころは、この2つの概念がよくわかっていませんでした。
2つとも似ているようで全く違うので、両者について簡単にまとめてみます。

extensionとは

extension(拡張)とは、特定のクラスや構造体、データ型など、名前はそのままにプロパティやメソッドを追加する機能です。
Javaでいうと「継承」と似ています。Javaの「継承」はクラスのプロパティやメソッドを引き継いだ別名のクラスを作るのに対し、Swiftの「拡張」は名前はそのままになるのが特徴です。

extensionの使い方

それではextensionを使った簡単なプログラムを書いてみましょう。今回はデータ型の拡張を行ってみます。
extensionを使って、Swiftに標準で備わっているデータ型(例.Int、String)を拡張してみます。

extension String {
    func isLongString() -> Bool {
        if self.count <= 20 {
            return false
        }
        return true
    }
}

let text = "RAKUS Developers Blog"
print(text.isLongString())

// 実行結果:true

サンプルプログラムでは、String型を拡張し、文字数が20文字以上かどうかを判別する簡単な関数を定義しています。
このように、extensionを使えば、変数の値の比較や加工処理を、既存のデータ型にメソッドを追加することで実現できます。
私は今まで「データ型の定義を拡張できる」ような言語に出会ったことがなかったので、この辺りはとても新鮮な感覚でした。

protocolとは

お次はprotocolです。protocolとは、クラスの挙動や振る舞いを決めたものです。クラスでは、プロパティや挙動を細かく記述していきますが、protocolでは、インタフェースのみを定義します。実際の挙動はprotocolを採用するクラス側で記述します。

protocolの使い方

ではprotocolを使った簡単なプログラムを書いてみます。今回は列挙型にprotocolを適用してみます。

protocol BaseProtocol {
    var type: String { get }
}

enum Blood: BaseProtocol {
    case AB
    case A
    case B
    case O
    
    var type: String {
        switch self {
        case .AB: return "AB型"
        case .A: return "A型"
        case .B: return "B型"
        case .O: return "O型"
        }
    }
}

print("あなたの血液型は" + Blood.AB.type + "です")

// 実行結果:あなたの血液型はAB型です

サンプルプログラムでは、血液型を列挙型で定義してみました。また、ベースとなるprotocolとして、BaseProtocol(そのままですが)を採用しています。
また、列挙型のほうで、BaseProtocolに定義してあるtype変数を宣言しないとコンパイルエラーになります。

最後に

Swiftのextensionとprotocolについて、違いがよくわかっていなかったので勉強してみました。
それぞれ身近なJavaを例に挙げて、extension→継承、protocol→インタフェースであると解説しましたが、Swiftを知らない人でも少しはイメージができたのではないでしょうか。
皆さんもこの辺りを勉強してみるとよりSwiftが面白いと感じるかと思います。


  • エンジニア中途採用サイト
    ラクスでは、エンジニア・デザイナーの中途採用を積極的に行っております!
    ご興味ありましたら是非ご確認をお願いします。
    20210916153018
    https://career-recruit.rakus.co.jp/career_engineer/

  • カジュアル面談お申込みフォーム
    どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。
    以下フォームよりお申込みください。
    forms.gle

  • イベント情報
    会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください! rakus.connpass.com

アジャイルなふりかえりにチェックイン!「場を設定する」アクティビティを実践しよう

id:radiocat です。中学のとき美術の先生に美術科への進学を勧められたことがありますが、それ以降は描いた絵を褒められたことがありません(後述)。

アジャイルな開発チーム以外でも近年は「ふりかえり」を行っているチームは多いのではないでしょうか? 従来型の開発プロセスでは「反省会」とも呼ばれますが、これまでやってきた事を振り返って未来に向けた改善アクションを見つけるという点ではどちらも同じです。そして、そのような改善に向けて振り返る会議の前にまず行うのが「チェックイン」です。

チェックインとは?

ふりかえりの「場を設定する」アクティビティの1つで、『アジャイルレトロスペクティブズ』という書籍で紹介されています。

目的

この書籍の中で、チェックインの目的は以下のように説明されています。

余計なことを考えずに、レトロスペクティブに集中してもらう。レトロスペクティブから何を得たいのかを明確にしてもらう。

ふりかえりの場に意識を集中してもらい、チームでどういう議論がしたいのかを発信して参加者の目線を合わせるための作業なのです。

やりかた

  1. 簡単な質問を1つする
  2. メンバーは順番に質問に答える

たったこれだけです。例えば、ふりかえりのファシリテーターが「今の気持ちを一言で答えてください」という質問をして、メンバーが「嬉しい」とか「悲しい」などと順番に答えます。

「場を設定する」ということ

チェックインのように「場を設定する」ことについて『アジャイルレトロスペクティブズ』の中で次のように説明されています。

部屋にいる全員に口を開いてもらう。最初に喋らなかったら、ずっと何も喋らなくてもいいという暗黙の了解を得たと思ってしまう。レトロスペクティブの肝はグループで考え、一緒に学んでいくことなので、全員参加が不可欠である。

たった一言ですが、質問に答えてもらうだけで全員に参加意識を持ってもらえます。また、答えた内容によってその人がどういう気持ちで会議に臨んでいるのかを知ることができます。例えば「嬉しいと感じているのは自分だけかもしれない」と思うと発言がしにくいかもしれませんが、全員の気持ちを知っていればそのような不安が減って発言のハードルが下がります。

つまり全員が一言ずつ喋ることで、その人自身の発言のハードルを下げるとともに、周りのメンバーの発言のハードルを下げることにも繋がるのです。

場を設定するアクティビティ

このような場を設定するアクティビティには様々なやりかたがあります。我々のチームでもいくつか実践してみたので、それらの一部を紹介します。

One Word

今の気持ちを一言で表現してもらいます。実際にやってみた結果は次のような回答でした。

f:id:radiocat:20180710194707p:plain:w300

一言では言い表わせれなかったメンバーもいますが、そういう気持ちなんだなと受け止めます。逆に一言だと意図がわからないものもあります。例えば「早い」は開発スピードのことなのか、作った機能のことなのかわかりません。ふりかえりの目線を合わせるためにも、必要に応じてどういう意味なのか聞いてみても良いでしょう。ただし、まだ場を設定するタイミングなので議論に発展するようならいったん止めてあとで議論するようにします。

漢字1文字

今の気持ちを漢字1文字で表現してもらいます。このケースでは順番に回答していくうちに、他のメンバーと被らないようにと、色々考えて回答するようになって後半のメンバーが苦戦するというせめぎ合いも起こりました。

f:id:radiocat:20180710192853p:plain:w400

自分の気持ちに適した漢字を選ぼうとすると意外と難しく、色々考えることでふりかえりに向けて集中できる効果もあります。One Wordと同じで意図がわからない漢字の場合はなぜその漢字なのか聞いてみても良いでしょう。

Happiness Rader

今の気持ちを顔文字で表現してもらいます。この時はどんな顔かを聞いてファシリテーターがホワイトボードに書きました。

f:id:radiocat:20180710194844p:plain:w300

参加者に自分で書いてもらっても良いですが、「どんな顔ですか?」と聞くことでどんな気持ちなのかがわかります。ただ、言葉で表現された気持ちを絵で表さなければならないので、ファシリテーターの絵心も場の設定に影響しそうです…

f:id:radiocat:20180710195115p:plain:w300

絵の得意なメンバーが見かねて代わりに書いてくれました。絵心がある人が描くほうが、参加者も今の気持ちを言葉で表現しやすいかもしれません…

3 dots

今の気持ちを3段階のドットで表現してもらいます。短時間かつシンプルに表現できるのが最大のメリットです。

f:id:radiocat:20180712094402p:plain:w300

顔文字と違って最速で表現できますが、なんとなく物足りなさはあります。3種類しかないので複雑な気持ちを表すことはできません。チームが複雑な課題をたくさん抱えているような場合は、みんな1ドットという回答でそれぞれが抱えている気持ちの違いはわからないという結果になる可能性があります。

Good & News

良かったことと新しい気づきを共有してもらいます。

前向きな意見を集めるような場の設定に有効です。ふりかえりで課題がたくさん出ることが予想される場合にあえて最初に前向きな意見を求めてみるという使い方もあります。気付きの共有はやや時間が長くなりがちなので時間が少ない場合には向いていないかもしれません。

希望と懸念

ふりかえりに対する希望と懸念事項を共有してもらいます。

参加者それぞれがふりかえりをどういう場にしたいかが比較的わかりやすく表現されます。ただ、これも少し時間がかかるアクティビティです。

以降は我々のチームではまだ試したことはありませんが、書籍等で紹介されているものです。

DPA(Design the Partnership Alliance)

決め事を作ります(どんな雰囲気で話すかなど)。

事前にその場の雰囲気をどうするかを参加者で話し合って決めるので、スムーズに議論に入れそうです。

Keep+Wakattakoto

良かったことと分かったことを共有してもらいます。

Good & Newsと似ていますが、KPTのKをより意識した場の設定ができるかもしれません。

連想ゲーム

起きたことを一言づつ隣の人に連想ゲームします。

漢字1文字と同じで、考えることで意識を集中することができそうです。また、ゲーム感覚で場を和ませる効果もありそうです。

おわりに

我々のチームでは、これらのアクティビティの中から1つを参加したメンバーに選択してもらっています。参加者が主体的に考えたり選択してもらうことで、ふりかえりの場が設定されます。

このような場を設定するアクティビティはふりかえりだけのための手法ではありません。議論に集中するために参加者同士で意識合わせをすることが目的なので、ふりかえり以外の会議でも活用できる場面はあります。

会議の場で次のような課題を感じたことはないでしょうか?

  • 発言する人が少ない
  • 自由な意見が出てこない
  • いつも同じ人の意見でチームの方針が決まる

もし、このような課題を感じたら「場を設定する」ことからはじめてみると良いかもしれません。


参考

ふりかえりワークショップ~実践&実践~ - Speaker Deck


  • エンジニア中途採用サイト
    ラクスでは、エンジニア・デザイナーの中途採用を積極的に行っております!
    ご興味ありましたら是非ご確認をお願いします。
    20210916153018
    https://career-recruit.rakus.co.jp/career_engineer/

  • カジュアル面談お申込みフォーム
    どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。
    以下フォームよりお申込みください。
    forms.gle

  • イベント情報
    会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください! rakus.connpass.com

Copyright © RAKUS Co., Ltd. All rights reserved.