Scala先駆者インタビュー Vol.1  ヌーラボ吉澤さん

Scala先駆者インタビュー Vol.1  ヌーラボ吉澤さん

「じゃあ今年、発表してみない?」その言葉でScalaの道が開けた!

  • > インタビューイー ヌーラボ 吉澤
  • > インタビューワー アットウェア 北野

北野:こんにちは、アットウェアの北野です。Scala先駆者インタビュー第一回目は、ヌーラボの吉澤さんとトークしてみたいと思います。ヌーラボさんは、BacklogやCacooという開発者にとっては馴染みのサービス・ツールを開発している会社です。吉澤さんは、ヌーラボの中でもTypetalkというチャットサービスのリーダをしていて、そのプロダクトはScalaで開発されています。早速ですが、吉澤さんはどのようにScalaと出会ったんですか?

ヌーラボ吉澤さん。非常に気さくで人と話すことが大好きな方。

ヌーラボ吉澤さん。非常に気さくで人と話すことが大好きな方。

吉澤:Scalaとの出会いはそんなに昔ではありません。就職した頃は、最初はJava言語を扱うSIerに所属していて、その後の転職ではC#へ転向し、それまでは仕事では全くScalaに触れることはありませんでした。2009年か10年ぐらいの時に、Javaが1.5,16あたりで停滞していた時があったと思うのですが、その頃Scalaという存在を初めて知って、Option やコレクション周りで Java にはない機能を目の当たりにしてちょっと触ってみようとしたのが出会いです。

北野:それで、すぐにTypetalkを開発しようとしたのですか?

吉澤:いえいえ。まだまだ、そんなレベルまでは。仕事で使おうというより、初めてのきっかけは、協業している会社さんと合同で行っている勉強会で「吉澤くん、次、何か発表してみようか?」と無茶ぶり的に誘われたことです(笑)。そのお誘いに乗っかり、Scalaという言語がありますよ、的な内容でその勉強会で発表をしました。当時はまだWebのフレームワークとかも今とは違ってPlayは無く、Liftぐらいしかなくて、ちょっと正直、適応するには早いと思っていました。ただ、当時、世間的にはBDDのライブラリとかも流行り始めていて、そういう点でテストとかだったらいいから使ってみたらいいと思って、その発表をしたと思います。

北野:実際に少しずつ使ってみてどうでしたか?

吉澤:その後ぐらいに、ちょっとずつ使いだして、ちょうどTypetalkを作ろうと思って、それに適応してみようと思って。最初は、自分が作っているものが会社のプロダクトして正式に採用される確約は無く、正直自分の空き時間や趣味の時間なども使いながら作っていました。2012年ぐらいですかね?その時に選んだものは、自分がやってて好きなモノを選ぼう。それが楽しいって思って選んでいました。(笑)

北野:それでScala・Playを?

吉澤:そうですね。その時にJavaだったら、Seaser2とかSpringとか、Rubyなどを選択するというのもあったと思いますが、Seaser2はメンテナンスモードに入って進化が見えなくなっていた所だったし、ちょっといろいろチャレンジしてみたいなぁと思っていた頃でした。その頃、Play1を少し触っていて、面白いフレームワークだったのでやり始めたらちょうどそのタイミングでPlayが2.0のRC版を出しますってアナウンスがあり、この波に乗っかるしかないなって。(笑)全部Scalaで書かれているし。これはもう楽しい!そう思いました。 実際Play2.0に触ってみるとマイグレーションの機能だったり、Seasarでは出来ていたホットリローディングとかのそういう機能とかもあったので、勢いでTypetalkのプロトタイプを作りました。

北野:TypetalkをScalaで作り始めたって話だったんですけど、じゃあ実際作っていく中でScala的に苦労した点とかっていうのはありますか。

吉澤:ちょうどその開発を始めた頃、シンガポール支社の立ち上げで現地勤務になって、本当は勉強会とか日本のいろいろな勉強会へ参加して、色々聞きたかったんですけど、結局、シンガポールとかではそんなに盛んではなくて。手探り状態で、ネットを見ながら書いたところですね。

北野:大変でしたね。それを乗り越えて、素晴らしいプロダクトとしてTypetalkが出来たということをお聞きすると、なんだかいままで以上に愛着が湧いてきます!ところで、Scalaを使い始めた時に参考にした情報はなんでしょうか?

吉澤:そうですね、シンガポールに行くときに、日本からScala 逆引きレシピとかコップ本(Scalaスケーラブルプログラミング)を持って行きました。それ以外にもインターネットは役に立ちましたね。いろいろなリソースはありますから。でも、その中でもその本は、見よう見まねで書いていたあの頃には本当に役に立ちました。

北野:今はTypetalkは複数人で開発をしていると思うんですが、人を増やしていった時の話とか、苦労話や、Scalaイイね話があれば。

吉澤:そうですね。Typetalkが私の個人ワークから、会社のプロダクトへと成長した時に、1人女性の方に入ってもらいました。先ほど紹介した本を参考にしながらScalaに触れてもらったり、簡単な部分からTypetalkの開発を始めてもらったり、レビューをもちろんしながら徐々に進めていって、そしたら自然とScalaメンバが増えていきましたね。彼女に後で聞いてみたんですが、「もうJavaには戻りたくない」っていうぐらいの感じです。どこら辺がいいかっていうところを聞いたら、「やっぱり簡潔に書ける所」っていう。やっぱりJavaだとどうしても冗長になってしまうような所があるようですね。まだまだ私たちもScalaの真髄について学習中なところです。本当の意味で関数型を上手く活用できているか?というとまだだと思っています。

北野:Scalaでここはどうにかして欲しいとか未来への期待があればどこでしょうか?

吉澤:んー、唯一どうにかして欲しいと言えることは、コンパイル速度ですかね!(笑)これはScalaが進化していくに対しての大きな期待です。実際に開発者の方もDottyという新しいコンパイラを作っているとのことですし。

北野:いろいろ、お聞かせ頂いてありがとうございました!それでは、次の方を紹介してもらえますか? 吉澤:えっ、いいとも形式ですか? 北野:いい例えですね。吉澤さんも次の回に来ていただきたいので、ごきげんよう形式にしたいと思います。

吉澤:いいですね!いきます!では、瀬良さんという方はいかがでしょうか?Skinny FrameworkというScalaで書かれているWebアプリフレームワークを開発している方です。非常に活発にオープンソースに貢献されている方で、Scalaの普及にも多く力を注いでいます。

北野:先日のスマートニュースさんで行われた講演を聞かせていただきました。ついでにいうと、弊社、アットウェアの社内で開発しているナレッジシステムSiita(QiitaクローンでScalaで書かれているので、Siitaという)のベースがSkinny Frameworkです。すごく楽しみにしています。ありがとうございます。

CentOS7にCouchDBをインストールしてみた

CentOS7にCouchDBをインストールしてみた

CentOS7にCouchDBをインストールしてみた

みなさん、こんにちは。KEYチームの矢納です。

技術ネタ第6弾!!「CentOS7にCouchDBをインストールしてみた」です。
過去記事の目次はこちらに移動しました。

CouchDBをインストール

yumで簡単でインストールすることができます。
ですが、そのままインストールを行うと1.0.4と非常に古いバージョンがインストールされてしまいます。yumを使わずにインストールするのはこのサイトにあるように非常に面倒です。

  • OSのアップデート・依存関係のインストール
  • Erlang と Mozilla SpiderMonkeyをソースからインストール
  • CouchDBのソースからインストール

    これら無しでインストールの手順を紹介します。

epelレポジトリインストール

# rpm -ivh http://dl.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-5.noarch.rpm

CouchDBのインストール

# yum install -y couchdb

CouchDBに設定・起動

# vi /etc/couchdb/local.ini
12行目
;bind_address = 127.0.0.1
↓
bind_address = 0.0.0.0
# systemctl enable couchdb
# systemctl start couchdb

これだけです。とても簡単ですね。

起動確認

http://your-ip-address:5984/
http://your-ip-address:5984/_utils/

おわりに

簡単にCouchDBのインストールが完了しました。プロジェクトで古いCouchDBを使っているかたはこの際にアップデートしてみてください。

Email: yanou at atware.co.jp

XP祭り2015に参加してきました

XP祭り2015に参加してきました

みなさんこんにちは。KEYチームの武永です。

今回は、先日行われた 「XP祭り2015 “俺も!!”」 に参加してきましたのでそのレポートになります。

XP祭りとは

日本XPユーザグループ(XPJUG)が主催しているイベントです。
2002年より毎年秋に開催されています。
私は今回が初めての参加です。

今回参加したセッション一覧

私が参加したセッションは以下になります。 オープニングは間に合わず基調講演からの参加になりましたが。。。

基調講演「XP lives, XP dies, XP lives again!!」

角征典さんによる基調講演のスライドは以下になります。

基本的に全てスライドに書いてあるので御覧ください。
個人的に印象に残っているのは「ときめき」というワードです。

  • TDD -ときめき駆動開発-とは
    こんまり流片付け術 では「捨てるモノ」ではなく「残すモノ」を選ぶが、 残すかどうか迷った時に「それはときめくか?」と先生は聞くらしい。
    ときめきは個人的なもので教えるものではない、最強のツール。
    エクストリームプログラミング の23章「時を超えたプログラミングの道」は、
    ときめきの道であり、 XPをやるときもみんなが「ときめく」必要がある。
    「ときめくプラクティス」を選ぶべきである。
    XPは「価値」と言ってるけど、それは届けた後にしか分からないよね?
    だから「無駄」とか「価値」じゃなくて、「ときめき」が重要。
    これが「ときめき駆動開発」。TDDだよね!

プラクティスを選定するときに「ときめく」ことが重要というのは個人的にもスゴく共感出来ました。
実際にプラクティスを選定する場面に立ち会わせたことはありませんが、
何かしらの課題を抱えていて、それを解決してくれるかもしれないものに出会った時に「ときめく!」のだろうなとはなんとなく感じることができるので。
このあと1日中「ときめき」というワードがどこかから聞こえてくることや、 セッションの資料に出てくることもあったのでみなさん同じ気持だったのかなとか想像してました。

結構笑えるネタが盛り込まれていたらしいのですが、
私には分からないネタが多くて反応できなかったことが結構ありました(汗)

“共感”でつながるアジャイルチーム

こちらは「共感コミュニケーション」というものをワークショップで体験してみるセッションでした。
スライドは以下になります。

4つのプロセス

  • 観察
    録画再生のように明らかな事実
  • 感情
    自分/相手が感じていること
    エンジニアは感情を出しづらい/感情を抑える傾向にある職業だと本に書かれているらしいです
  • ニーズ
    何を必要としているか
    感情の裏には自分が必要としているものがあるはず
  • リクエスト
    具体的な要求
    叶わなくてもいいから口にだしてみる

このワークショップでは、「感情」と「ニーズ」の部分について 「感情」と「ニーズ」を結びつける練習を行いました。

最初に「自分の感情」を感じるということをしました。
例えば

  • ときめくプラクティスを聞いた時は「面白かった」。なぜなら「ひらめきが欲しい」、「刺激が欲しい」というニーズが「満たされた」からだ。
  • 基調講演を聞いて「ショックを受けた」。なぜなら一部理解できない話があり、「情報や知識がほしい」というニーズが「満たされなかった」からだ。

というように、どのような感情を持っているのか、その感情の元となるニーズを探ることで、
自分・相手が欲しているものは何かということを探っていくことをしました。

「自分の感情」を実際に他の人に上の例文のような形で話してみると 「本当にこの感情とニーズは合致しているな」と改めて納得した部分もありました。
しかし、「この感情はこのニーズと合致しているのか?」と自分に疑問を持って相手と本当のニーズを探してみると新たな発見もありました。
自分のことなのに実際に口に出してみると相手にも伝わるし、自分も新たな発見ができるという非常に面白い体験でした。

次にペアの人の話を聞いて、その裏にある「感情とニーズを探る」ということを行いました。
何かの感情にまつわる1つの出来事を相手に話して、相手はその裏にある「感情」を当てたあと、2人でニーズを探していくという練習でした。

これが非常に難しくもあり、面白い時間でした。
相手の話の裏に隠れている感情を探るのは難しく、そこからニーズを探るのはさらに難しかったですが、
探ろうとして深堀りして聞いていくうちに新しい情報が出てきてもっと相手のことが知れたり、
自分のことを知ってもらえるようになるのだなと感じた時間でした。

TDDライブコーディング

こちらは「ときめき駆動開発」ではなく本当に「テスト駆動開発」の方のTDDライブコーディングです。
まずはTDDについて説明と登壇者のきょんさんが大事にしていることの説明がありました。

TDDの3原則 by Uncle Bob

  • 失敗するテストが出来るまでプロダクトを書いてはいけない
    最初Greenにした時に、一気に追加実装してしまうのはTDDあるあるだがやってはいけない
  • 失敗するテストがある場合にはそれ以上テストを追加してはいけない
  • テストを成功させるプロダクトがある場合にはそれ以上プロダクトを追加してはいけない

要求や設計の反映

テストが失敗した時に判断できるようにする

  • バグを埋め込んでしまったからか。
  • 意図された振る舞いは変わらず関連性があった部分が何処か別の場所に移されていたのか。
  • 振る舞いがもはや正しくない。システムの前提が変わってしまっているのか。

分析と設計

  • 分析には主にミカドメソッドを使う
  • 設計には主にTDD/BDDを使う

そして実際にライブコーディング。
https://gist.github.com/kyonmm/6102436 にあるTODOリストをTDDでコーディングするのを見ていくセッションでした。
もっと時間があればワークショップにしても良かったらしいですが、90分枠でライブコーディングになったらしいです。

ライブコーディングの様子

そして出来上がったコードがコチラ

最初Greenにした時に一気に追加実装してしまうのは割りとやりがちなので気を引き締めたいところです。
きょんさんは非機能系(パフォーマンスとか)のテストも最初から入れるとのことで、
特に性能テストとかは最初から書いておくらしいです。
実際にどういうテストを書くのかあまり想像できていないので個人的に聞いてみたいです。

LT祭り

そしてLT祭り。
毎年レベル高いと聞いていたのですが、噂通りでした。

それぞれ公開されているスライドを以下に紹介しておきます。

クロージング

最後の最後に協賛の出版各社様からの献本が参加者にプレゼントされました。

私はプレゼントを貰える条件の1つ

XP祭りに初参加で、入社5年目以内

という条件に当てはまったのでこちらを頂きました。ありがとうございました。

最後に

非常に良い刺激を受け続けた1日でした。
一度読みましたが、もう一度エクストリームプログラミングを呼んでみようと思いました。
そして今回聞いたものですぐに使えそうなのものはどんどん実践していきたいです。
例えば共感コミュニケーションなどは非常に練習が必要だと思うので常に意識しながら会話していきたいですね。
今回参加できなかった他のセッションも興味深いものが多いので、スライドをあとで見ようと思います。
来年もきっと参加します!!

【告知】TDD勉強会@みなとみらい

【告知】TDD勉強会@みなとみらい

TKG 「Tamago Kake Gohan」じゃなくて、
TDR 「Tokyo Disney Resort」でもなくて、
TDD 「Test Driven Development」

TDD(テスト駆動開発)とは、プログラム開発手法の一種で、プログラムに必要な各機能について、最初にテストを書き(これをテストファーストと言う)、
そのテストが動作する必要最低限な実装をとりあえず行った後、コードを洗練させる、という短い工程を繰り返すスタイルである。
多くのアジャイルソフトウェア開発手法、例えばエクストリーム・プログラミングにおいて強く推奨されている。(wikipedia より

TDD 知ってます?

TDD 実際にどうやるの?

TDD プロジェクトで取り入れたことありますか?

TDD やってみてどうですか?

TDD 気になることありませんか?


そんなギモン・シツモンを抱えている方に朗報です!
JJUG CCC 2014 で TDD に関する登壇経験のあるグロースエクスパートナーズの大中さんを迎えて、
明後日9月18日(金)16時から弊社横浜本社(場所はココ)で「TDD 勉強会」を行います。
まだ参加者募集中ですので、ご興味のある方は是非ともご参加下さい!
https://keyatware.doorkeeper.jp/events/30962

※ JJUG:日本Javaユーザーグループ
※ CCC:Cross Community Conference

Atlassian Stashの耐障害性を高めよう その2 HAセットアップ編

Atlassian Stashの耐障害性を高めよう その2 HAセットアップ編

今回は 前回 「Atlassian Stashの耐障害性を高めよう その1 プランニング編」 の続きとして、
HAクラスタのセットアップを行いたいと思います。

手順はredhat向けのHIGH AVAILABILITY ADD-ON リファレンス を参考に行っていきます

今回の構成

今回は、LinuxのHAクラスタミドルウェアの定番であるPacemakerを使用してクラスタを構成します。

ソフトウェアバージョン
CentOS7.1
Pacemaker1.1.12
Corosync2.3.4
pcs0.9.137

ノード設定

ホスト名IP備考
node01192,168.33.21Stash node #1
node02192,168.33.22Stash node #2
stash192,168.33.101Stash VIP

事前準備

クラスタ構成の際にお互いのノード名を解決出来なければならないので、
/etc/hosts にホストを追加しておきます。

/etc/hosts

192.168.33.21 node01
192.168.33.22 node02

次にクラスタの通信に使用するポートを開放します

# firewall-cmd --permanent --add-service=high-availability
# firewall-cmd --add-service=high-availability

ソフトウェアのインストール

それでは、必要なソフトウェアをインストールしていきます。

# yum install pcs fence-agents-all

コマンドを両方のノードで実行します。
これだけでHAクラスタに必要なソフト一式がインストールされます。

インストールが無事完了したら、クラスタの構成を行うコマンドのデーモンである pcsd を起動します。
また、再起動時に自動的に起動するように設定します。

# systemctl start pcsd
# systemctl enable pcsd

クラスタの構築

次に、node01,node02をメンバーとして、HAクラスタを構築します。

hacluster ユーザーのパスワードを設定

ここでは、マニュアルの推奨に従って、両ノードともに同じパスワードを設定します。

# passwd hacluster

これも両ノードで実行します。

クラスタノードの認証

クラスタノード間の認証設定をします。

# pcs cluster auth node01 node02 -u hacluster -p hacluster

クラスタの作成

クラスタを作成します

pcs cluster setup --start --name stash node01 node02

クラスタ状態の確認

作成したクラスタの状況を確認します。

# pcs cluster status
Cluster Status: Last updated: Mon Sep 14 09:46:54 2015 Last change: Mon Sep 14 09:42:40 2015 by hacluster via crmd on node02
Stack: corosync Current DC: node02 (version 1.1.13-a14efad) - partition with quorum
2 nodes and 0 resources configured

Online: [ node01 node02 ]

PCSD Status: 
  node01: Online
  node02: Online

両ノードがOnlineとなっていればOKです。

STONITH の無効化

ここで、/var/log/messages を確認すると。

Sep 14 11:16:14 localhost pengine[4158]: error: Resource start-up disabled since no STONITH resources
have been defined
Sep 14 11:16:14 localhost pengine[4158]: error: Either configure some or disable STONITH with the ston
ith-enabled option
Sep 14 11:16:14 localhost pengine[4158]: error: NOTE: Clusters with shared data need STONITH to ensure
 data integrity
 
といったエラーが発生しています。
この[ページ][0]によると STONITHと呼ばれるノードが不安定になった場合、自動的に再起動を行う機能が有効になっているものの、その機能を実現するためのリソースが無いためエラーとなってしまっているようです。 現時点ではSTONITHを使用しないため、
pcs property set stonith-enabled=false

を実行し、機能を無効化します。

リソースの作成

クラスタの設定が終わったところで、次にリソースを設定します。
クラスタでのリソースとは、特にクラスタノード間で共有するリソースのことを指します。
例えばアクティブノードが使用する仮想IPなどです。

今回は、ユーザーがアクセスする際に指定する、サービス用の仮想IPをリソースとして追加します。

どちらかのノードでコマンドを実行します。

# pcs resource create stash_vip IPaddr2 ip=192.168.33.101 cidr_netmask=24 op monitor interval=6s

これで、6秒ごとに死活確認を行うIPアドレスの共有リソースが設定されました。
具体的には、アクティブノードに 192.168.33.101 のIPエイリアスが設定されます。

ノード切り替えのテスト

サービス用の仮想IPが割り当てられることが確認出来ましたので、
正しく系切り替えが行えるか確認してみたいと思います。

アクティブノードの障害

アクティブノードの障害時に正常に切り替わるか確認してみましょう。

Active : node01 Standby: node02

の状態で、node01の電源をOFFしてみます。

実施前

# pcs status
Cluster name: stash
Last updated: Mon Sep 14 12:14:31 2015        Last change: Mon Sep 14 11:51:35 2015 by root via crm_attribute on node02
Stack: corosync
Current DC: node02 (version 1.1.13-a14efad) - partition with quorum
2 nodes and 1 resource configured

Online: [ node01 node02 ]

Full list of resources:

 stash_vip    (ocf::heartbeat:IPaddr2):   Started node01

PCSD Status:
  node01: Online
  node02: Online

Daemon Status:
  corosync: active/disabled
  pacemaker: active/disabled
  pcsd: active/enabled

2ノードともオンラインで、stash_vip は node01に割り当てられています。

ここで node01 の電源をOFFにします

# pcs status
Cluster name: stash
Last updated: Mon Sep 14 12:18:31 2015        Last change: Mon Sep 14 11:51:35 2015 by root via crm_attribute on node02
Stack: corosync
Current DC: node02 (version 1.1.13-a14efad) - partition with quorum
2 nodes and 1 resource configured

Online: [ node02 ]
OFFLINE: [ node01 ]

Full list of resources:

 stash_vip    (ocf::heartbeat:IPaddr2):   Started node02

PCSD Status:
  node01: Offline
  node02: Online

Daemon Status:
  corosync: active/enabled
  pacemaker: active/enabled
  pcsd: active/enabled

正常に node02 にIPが切り替わりました。
この間pingを192.168.33.101宛に行っていましたが、今回はpingが途切れる事なくノードが切り替わりました。

スタンバイノードの追加

では、次に稼働中のクラスタに、node01を追加します。

node01を起動し、node01でクラスタを起動します。

# pcs cluster start

正常に node01がクラスタに参加しました、ただアクティブノードはnode02のままです。

pcs status
Cluster name: stash
Last updated: Mon Sep 14 12:24:38 2015        Last change: Mon Sep 14 11:51:35 2015 by root via crm_attribute on node02
Stack: corosync
Current DC: node02 (version 1.1.13-a14efad) - partition with quorum
2 nodes and 1 resource configured

Online: [ node01 node02 ]

Full list of resources:

 stash_vip    (ocf::heartbeat:IPaddr2):   Started node02

PCSD Status:
  node01: Online
  node02: Online

Daemon Status:
  corosync: active/disabled
  pacemaker: active/disabled
  pcsd: active/enabled

アクティブノードの手動切替

最後に、アクティブノードを切り替えます。
片系ずつ切り替えながらメンテナンスする際に威力を発揮しそうです。

アクティブノードをスタンバイ状態にし、強制的にきりかえます。
アクティブノード上で下記のコマンドを実行します。

 # pcs cluster standby
 
正常にノードが切り替わり、node01がアクティブになりました。
# pcs status
Cluster name: stash
Last updated: Mon Sep 14 12:44:33 2015        Last change: Mon Sep 14 12:44:24 2015 by root via crm_attribute on node02
Stack: corosync
Current DC: node02 (version 1.1.13-a14efad) - partition with quorum
2 nodes and 1 resource configured

Node node02: standby
Online: [ node01 ]

Full list of resources:

 stash_vip    (ocf::heartbeat:IPaddr2):   Started node01

PCSD Status:
  node01: Online
  node02: Online

Daemon Status:
  corosync: active/disabled
  pacemaker: active/disabled
  pcsd: active/enabled

ただ、このままですと node01に障害が発生した場合でもnode02に切り替わらないので、 node02のスタンバイ状態を解除します。
スタンバイ状態のノードで以下のコマンドを実行します。

# pcs cluster unstandby
pcs status
Cluster name: stash
Last updated: Mon Sep 14 12:46:29 2015        Last change: Mon Sep 14 12:46:27 2015 by root via crm_attribute on node02
Stack: corosync
Current DC: node02 (version 1.1.13-a14efad) - partition with quorum
2 nodes and 1 resource configured

Online: [ node01 node02 ]

Full list of resources:

 stash_vip    (ocf::heartbeat:IPaddr2):   Started node01

PCSD Status:
  node01: Online
  node02: Online

Daemon Status:
  corosync: active/disabled
  pacemaker: active/disabled
  pcsd: active/enabled

node02がアクティブになりました。

今回はここまで

これでひと通りのクラスタ切り替えの動作の確認が出来ました。
しかしながら、IPの切り替えだけではStashの冗長化は出来ません。
次回は、ストレージの冗長化を設定しStashの冗長化を完成させたいと思います。

参考資料:

RED HAT ENTERPRISE LINUX 7 向け HIGH AVAILABILITY ADD-ON のリファレンスドキュメント
リファレンスなので、ひと通り情報は乗っているが、ステップバイステップで構築の手順となっていなく、コマンド例ももう一声ほしいところ。 総じて、読み解くのに読者の頑張りが必要なドキュメント。。。

CentOS7.1でPacemaker+corosyncによるクラスタを構成する(Part.1)
CentOS7 + Pacemaker でのクラスタ構築からVIP設定までが非常に丁寧にステップバイステップで解説されています。 最終的には、このエントリもほぼ似たような感じになってしまいました。

Javascriptの勉強方法

Javascriptの勉強方法

javascriptを勉強したい、身につけたいと思って何から始めたらいいかわからない方へご参考程度に私がやってきたことをお伝えしたいと思います。

イントロダクション

いきなり英語かよ。と、面を食らってしまいました。でも、まずは知ることから始まるのでココをみておくことが大事です。Google先生に翻訳してもらってもだいたいわかります。

参考になるソースを書いてみる

いままでで一番参考になったのは underscorebackboneです。 きれいな書き方に見えるし、コメントもいいですね。一番好きです。 写経して勉強しました。

デザインパターン

javascriptのソースを見る上でもデザインパターンを知っておくほうがいいですね。ここも英語ですが読んでおくといいですね。

styleガイド

badとgoodが記述されていてとてもわかり易いです。内容も充実しているのでかなり勉強になります。

その他もろもろ

フレームワークとかテストとかjavascript周りの正しい方向を示してくれています。いろいろな環境を知ることが出来て勉強になります。

何か一つフレームワークを使いこなせるようになる

現在の代表的なフレームワークとしてはいろいろあります。

上記3つの中でどれでもいいので一つ使いこなせるようになっておくことが大事です。

プログラミング言語を覚えるのはとても難しいですし、時間が必要ですが、根気よく勉強を続けることで使えるようになってきます。

IntellijでGo言語を開発しよう

IntellijでGo言語を開発しよう

IntelliJでGo言語を開発しよう

みなさん、こんにちは。KEYチームの矢納です。

技術ネタ第5弾!!「IntelliJでGo言語を開発しよう」です。
過去記事の目次はこちらに移動しました。

IntelliJとは?

IntelliJ IDEA(インテリジェイ アイディア)は、チェコに本社を置くJetBrains社が開発した、Java言語など多言語対応の統合開発環境である。 リファクタリング機能をJava用の統合開発環境としては初めて搭載したことでも知られる[1]。変数に型のないプログラミング言語に対してもリファクタリングを提供している。 ZeroTurnaround の調査によると、Java の統合開発環境としては Eclipse に続いて2番目に人気である (2011年はシェア22%[2]、2012年はシェア28%[3])。 https://ja.wikipedia.org/wiki/IntelliJ_IDEA より

基本的にはJava開発で使われるIDEAでは有りますが、私自身がかなり気に入っていますので、他のエディタ等を使いたくありません。なので、どうにかしてIntelliJで開発ができないかと探していたらありました。

なぜGo言語?

今年、Go言語が大好きな新入社員入りました。その人の影響です。ただそれだけです。

構築手順

では、ここからは構築手順を紹介して行きます。

0. Go言語インストール

省略

1.IntelliJのインストール

https://www.jetbrains.com/idea/download/のページから各OSにあった物をダウンロード、インストールしてください。

2.Goプラグインインストール

5番目の画像で入力で入力しているのは https://plugins.jetbrains.com/plugins/alpha/5047 です。

3.GOPATHの設定

Go言語のアプリケーションを作成するにはGOPATHをそのアプリケーションのルートでディレクトリに設定する必要が有ります。IntelliJでは下記の画像のような警告が表示されます。

Configure Go Library をクリック

12.png

サンプルコードを書き、実行。

今回のプログラムは 簡単にWEBサーバを構築する です。

さいごに

これでIntelliJを使ってGo言語アプリケーション開発が可能になりました。Sublimeで満足している方はそれで良いですが、IntelliJを愛している人にはおすすめです。是非やってみてください。

Email: yanou at atware.co.jp

Gebチュートリアル

Gebチュートリアル

みなさんこんにちは。KEYチームの武永です。

先日とある学生さんから以下のようなメールを貰いました。

武永さんのGebのブログを読んでGebに興味が出てきて
実際に動作させてみたいと思ったのですが、 環境構築の仕方が分からず動かせていない状況です。
メールでもブログでもいいのでご助力いただけると幸いです。

詳しく状況を聞いてみると
「いつもはRubyを触っているが、何から手をつけていいのか分からない」
「私がどのような環境で動かしているのか興味がある」との事でした。
こういう連絡が来るとは思っていませんでした。

初歩的な情報でも参考になる方は多いのかなと思ったので今回は環境構築から 公式のサンプルコードの実装と説明の日本語訳 + 簡単なコードの説明を書いていこうと思います。
※英語は得意ではないので訳が100%正しいものとは言えないです。。。

使用する環境

  • Mac OS X Yosemite
  • Java8
  • IntelliJ IDEA14.1 Community Edition

環境構築

さて、さっそく環境構築を進めていきましょう。
とは言っても環境構築自体はGebはGroovyなので全く難しくありません。
※Javaのインストールは省略します。

IntelliJ IDEA14 インストール

既にIntelliJ IDEAがインストールされている方は読み飛ばして大丈夫です。

  1. https://www.jetbrains.com/idea/download/
    上記へアクセス
  2. 「Download Community」ボタンを押下
    「Ultimate Edition」でも問題はありません。
    ダウンロードが始まります。
  3. ダウンロードされた「ideaIC-14.1.4.dmg」を開く
    Intellij IDEA を アプリケーションへドラッグアンドドロップ

IntelliJ IDEAは標準でGroovyに対応しているので準備完了です。

プロジェクト作成

  • new project → Maven → next

Project SDKが設定されていない場合は用意したJDKを選択しておいてください。 JDKの場所はデフォルトならば [/Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home] 上記のようになっています。

  • GroupIdとArtifactIdを入力 → next → ProjectNameを入力 → finish

pom.xmlの編集

pom.xmlを以下のとおりに編集します。

サンプルコード実装

Gebが動く環境は整ったので実装に入ります。
以下の様に「module」と「page」Packageを作成します。

  • module配下に「SelectableLinkModule.groovy」を作成します。
  • module配下に「HighlightsModule.groovy」を作成します。
  • page配下に「GebHomePage.groovy」を作成します。
  • test直下に「GebHomepageSpec.groovy」を作成します。

以上でサンプル実装終了です。
では実際に動かしてみましょう。
「GebHomepageSpec」を左クリック → Run 'GebHomepageSpec' をクリックで実行できます。

実行結果がこちらの動画です。

最後に

まさか私のブログを読んでメールを送ってきてくれるとは思っていなかったのでメールを受け取った時には非常に驚きました。
個人的にはメールを送ってくれた方には是非会ってみたいなと思っています。
今回の記事でGebをとりあえず動かしてみようと思ってくれる人がいると幸いです。

YOKOHAMA MARATHON 2016

YOKOHAMA MARATHON 2016

前回距離が不足していて話題となった横浜マラソンですが、
今回は2016年3月13日(日)に開催が決まり、今月9月1日からエントリーが始まりましたね。(公式サイトこちら

atWare にはマラソン部はありませんが、何人かはフルマラソン経験者がいます。(私もその一人)
先日社員でランチに行った際、スタート・ゴールが弊社のあるみなとみらい地区ということで、横浜マラソンの話題になりました。
するとあまり運動しなさそうなメンバから日頃からトレーニングしているメンバまで、数人がエントリーすることが判明!
地元優先枠や外国人優先枠(こちらは先着順!)があるので、多少当たる確率は多少上がりそうです。

フルマラソンのコースは、横浜の名所を回ります。(公式サイトより)
中華街を通らないのは残念ですね…

みなとみらい大橋[スタート]
 ↓
横浜スタジアム
 ↓
マリンタワー
 ↓
本牧周辺
 ↓
南部市場
 ↓
首都高速湾岸線
 ↓
本牧ふ頭D突堤折返し
 ↓
赤レンガ倉庫
 ↓
みなとみらい
 ↓
パシフィコ横浜[ゴール]  ↓ みなとみらい大橋[スタート]

募集人数は合計25,000人。
内訳はフルマラソン:23,950人、10km:1,000人、10km(車いす):30人、2km(車いす):20人
フルマラソンには以下枠が存在しています。(公式サイトから抜粋)

  1. 地元優先枠:3,000人(申込多数の場合は抽選)
    ・ 横浜市民(2,000人)横浜市在住の方
    ・ 神奈川県民(1,000人)横浜市以外の神奈川県在住の方
  2. 一般枠:19,450人(申込多数の場合は抽選)
    ・ 一般の方
  3. 外国人優先枠:500人(先着順)
    ・ 外国籍の方が優先的に参加できる枠
  4. 横浜マラソンチャレンジ枠:500人
    ・ 横浜マラソンへの参加機会の提供をきっかけとして、
    多くの方がランニングをはじめとしたスポーツを習慣にしていただけるよう、
    各区のマラソン大会や市内の各区スポーツセンターなどで実施する
    ランニング関連事業(ランニング教室やランニングイベントなど)と連携した参加枠を設定します。

フルマラソンであれば4~5時間近く走るまたは歩くことになるので、日常生活では考えられない運動ですね。
一応レースなので、皆さんテンション・アドレナリンが全開となり、本来のペースを保てなくなることが多々あります。
また沿道からは芸能人かのように応援・声援が聞こえてくるので、更に頑張ってしまいます笑
終盤になると、「ロッキーのテーマ」や「負けないで」を用意してくれる方もいて、ランナーに勇気とパワーと与えてくれます。
正直かなり辛いことばかりですが、完走出来た時の達成感は最高に気持ち良いですよ!
これからトレーニングを開始しても間に合いますので、特に横浜市民の方は応募してみてはどうでしょうか?締切は9月30日です。
きっと新たな自分と横浜が発見できますよ!!

Atlassian Stashの耐障害性を高めよう その1 プランニング編

Atlassian Stashの耐障害性を高めよう その1 プランニング編

はじめに

私の所属しているプロジェクトではAtlassian Stash (Git)でソースコードを管理しています。
普段何気なく使用しているGitですが、もはや手放すことが難しい存在です。

そんな中、ふと「もしもStashのデータが消失したら。」と言う事態を想像してみました。
Gitは分散バージョン管理なので、各々のローカルのGitリポジトリをかき集めれば必要なものは復旧できそうです。

どうやらソースコードの消失などの最悪の事態は発生しないことはわかりましたが、
Stashを使用していればサーバーの冗長構成は必要ないでしょうか。

Atlassianのドキュメントによると、Stashに障害が発生した場合、復旧作業をおこなっている間、下記の様な状況になります。

  • できること

    • 開発者
    • コードのコミット
    • ブランチの作成
    • ブランチの切り替え
    • 過去のコミットと差分確認 
    • ...
    • Stashを経由せずに他の開発者のリポジトリからフェッチする
  • できないこと
    • 開発者
    • リポジトリのクローン
    • セントラルリポジトリ(Stash)からのフェッチ
    • セントラルリポジトリ(Stash)へのプッシュ
    • Stash UI へのアクセス (プルリクエストの操作など)
    • CI/CDサーバー
    • リポジトリのクローン
    • 変更点の取得

作業は続行不可能では無いですが、チーム開発を進めていく上でかなりの制限となってしまいそうです。

というわけで、転ばぬ先の杖ということでStashの冗長化に挑戦してみたいと思います。

Stash冗長化について調べてみたところ、本家Atlassianに冗長化についてのドキュメントが用意されていました。

冗長構成のパターン

Atlassianのドキュメントによると、冗長構成には以下の様なパターンがあるようです

構成 復旧時間
Single node hours-days 単一ノード
Cold Standby 2-10 min サーバーはActive StandByともに起動させておくが、StashはActive側のみ起動しておく構成。Active側が障害となった場合StandBy側のStashを起動させ、切り替える
Warm Standby 0-30 Sec Active Standby 双方にStashを起動させておき、Active側が障害となった場合切り替える
Active-Active <5 Sec マルチマスタ&負荷分散構成 ただし Stash Data Center が必要

この構成の内、Active-Active構成をするためには Stash Data Centerを使う必要があるらしく、 予算的に厳しい様な予感がするので今回は見送ることとします。

また、Warm StandBy 構成 はStashがメモリ上にロック情報などを持っているため、現時点でこの構成は取れないそうです。

そうすると、コストとメリットのバランスを考えた場合Cold Standby構成を取るのが良いようです。
(Atlassianのドキュメントもこの構成でクラスタを組んでいます。)

図で表すと、下記の様になります。おおむねAtlassianのドキュメント通りですが、データベースのみ、他のAtlassianプロダクトと共有することを考えて、Stashとは別のサーバーとしています。

細かいソフトウェアのバージョンなどはもう少し調べてみてから決定していきたいと思います。

というわけで、だいたいの構成の目処がついたところで、今回はここまでとしたいと思います。

次回は実際のクラスターの構築を行ってみたいと思います。

みなとみらいサイクリング夏

みなとみらいサイクリング夏

みなとみらいは整備された道が多くちょっとしたサイクリングもいいですよ。

ということで本日はみなとみらいサイクリングをご紹介します。

本日のルートはこちら。約40〜50分のコースです。

スタートはオーケー本社orストア。建設中ですね。

マリノスタウン。

パシフィコ横浜

みなとみらいメインストリート

観覧車

インターコンチネンタル

赤レンガ倉庫

マリンタワー

元町・中華街

ランドマークタワー(ピンぼけしてしまった)

とても道が広く眺めもいいですね。

一箇所、ここだけ左折しないように気をつけてね。

マリンタワーまでは車は少なく気持よく進んであっという間です。

中華街方面に出ると車が多くなるので慎重に進みます。

みなとみらいは小さい街ですが良いポイントが多いです。

それでは。

RaspberryPi上でRedisを動かしてみた

RaspberryPi上でRedisを動かしてみた

みなさん、こんにちは。KEYチームの矢納です。

技術ネタ第4弾!!「RaspberryPi上でRedisを動かしてみた」です。
過去記事の目次はこちらに移動しました。

軽量なデータベース

第2弾でCouchbase Liteを使ってのデータ保存を行いました。ですが、Couchbase Liteを使う際にはCouchbase ServerとSync Gatewayを用意する必要が有ります。RaspberryPi単体で動かしたい場合には向いていません。とはいえ、非力なRaspberryPiにPostgreSQLやMySQLを入れるのは少し抵抗があります。軽量なデータベースを探していたら有りました!!Redisです。

セットアップ

では、RaspberryPiにRedisをインストールします。

$ sudo apt-get install redis-server

インストールすれば、Redisは起動しています、確認してみてください。

$ ps aux | grep redis
    redis     3191  0.1  0.5  27356  2360 ?        Ssl  02:11   0:00 /usr/bin/redis-server /etc/redis/redis.conf
$ netstat -aunt | grep 6379
    tcp        0      0 127.0.0.1:6379          0.0.0.0:*               LISTEN

既に自動起動にもなっています。

sudo chkconfig --list | grep redis-server

起動・停止の仕方も載せておきます。

$ sudo service redis-server stop
$ sudo service redis-server start
$ sudo service redis-server restart

設定

外部設定を許可します。

$ sudo vi /etc/redis/redis.conf
30行目をコメントアウト
# bind 127.0.0.1

パスワードを設定します。

$ sudo vi /etc/redis/redis.conf
166行目にパスワードを記述
requirepass <パスワード>

パスワードを設定する際に注意です。

Redisはとても高速なため、性能の良いマシン上で実行している場合は、毎秒150,000回程度のパスワードチェックを行うことができます。そのため、弱いパスワードであれば簡単に突破されてしまうため、非常に強いパスワードを設定するようにしてください。

Redisの公式ドキュメントに書かれています。

PythonでRedisを触る

PythonでRedisを扱うのにライブラリが用意されています。まずはインストール。

$ sudo pip install redis

実際にコードを書いて行きましょう。

おわりに

今回はRedisの基本の操作方法を行いました。他にも有効期限ありの保存、上書きはしないなど色々とできます。それはご自身でやってみてください。

それでは

Email: yanou at atware.co.jp

学生相手にAgile講習をした話

学生相手にAgile講習をした話

みなさんこんにちは。KEYチームの武永です。

こちらの記事にもあるようにatWareでは今年もインターンシップを受け入れています。 その中で私がインターン生に向けてAgile講習を行ったのでそれについて書いていきます。

Agile講習開催の経緯

KEYチームがメイン担当としてインターン生を受け入れており、
私と円城寺(円城寺の記事はこちらから)が認定スクラムマスターの資格を持っていて
実際のプロジェクトをScrumで取り組んでいることもあり、Agile講習を行うことにしました。
自分のAgileに対する知識・経験の把握と社外の人向けプレゼンの練習になると思って
私がメイン講師になり、円城寺のサポートを受け、講習を行いました。

Agile講習の内容

流れとしてはウォーターフォールの紹介、ウォーターフォールでの問題点から
紙ヒコーキワークショップを実施し、Scrumの説明という流れで行いました。
私はウォーターフォールのプロジェクトを経験したことが無かったので教科書的な説明になってしまいましたが。。。
使用したスライドは以下になります。

講習の様子

函館ラボにもインターン生が来ていたのでリモートで行いました。

以下の動画は実際に紙ヒコーキを飛ばしているところです。
楽しそうに実施してくれて良かったです。

紙ヒコーキワークショップ結果
予測 実測
1 5 1
2 3 4
3 8 10
4 11 8

紙ヒコーキを飛ばしたらみんなで後片付けをした後にScrumの説明を行いました。

本当は2時間程の予定でしたが、1時間半程で終了してしまいました。
学生の頃の経験で10分・20分程度の短いものの時間感覚はあるのですが、
1時間超えというものは初めての事だったので非常に良い経験になりました。

インターン生からの感想

講習後個別に感想を聞いてみました。

  • 分かりやすかった
  • 紙ヒコーキワークショップが楽しかった
  • なんとなく分かった
  • Scrumのことはなんとなく知っていて、ワークショップで「なるほど」となるところが結構あった。

直接聞いたので社交辞令的にプラスの意見が多かったのかは分かりませんが 皆さんから良い感想が聞けて非常に嬉しかったです。

反省点

学生側からはプラスな感想が出来ましたが講習を聞いていた社員からは
「話すの速かった」、「知っている前提の内容が結構あった」などのご指摘を結構受けました。
Agileの知識・経験不足、対象者を考えたプレゼン作りなどなど
自分に不足している部分を改めて実感できた良い経験になりました。

最後に

今回の講習を受けた学生の刺激になり少しでもAgile・Scrumについて勉強するきっかけ作りになれたなら最高だなと感じています。
それと同時に自分ももっとAgile・Scrumについて勉強していこうと思える機会になりました。

またこのような発表する機会があるのなら上手く行った点、反省点を活かして行いたいと思います。

夏のインターンシップ後半戦

夏のインターンシップ後半戦

KEYチームのアライです。
8月28日にインターンシップの前半戦(内容はコチラ)が終わったと同時に8月31日から後半戦がスタート。
後半戦は5名の学生さんを受け入れています。

KEYチームとしては、前半戦はリーンスタートアップ、後半戦はアジャイルに興味のある学生をサポート。
3名の予定が2名となり、少しさびしいチームになってしまいましたが、
基本学生さん達にやりたいこと(アイデア)を考えます。
今回はアイデアを持っている学生さんだったのですぐにテーマが決まり、アジャイル手法で Web サービスを作ることになりました。

まずはサポートメンバと一緒に以下プラクティスを実施。

  • ユーザーストーリーマッピング
  • ストーリーの選択
  • 各ストーリーのタスク出し
  • 計画ゲーム

そしていよいよ開発が始まりました。今回は1イテレーション(約5日間)を2回行います。
歳が近いこともあり、積極的に意見交換しながら進めていけそうです。

自分達が決めた目標を達成するために頑張ることはもちろんですが、会社からあるミッションが与えられています。
他のインターンシップ生や他の社員との交流、アットウェアの事をもっと知って貰いたいなどなど…

彼らにとって、そして私たちにとっても刺激となる3週間。
目標の達成だけではない、日々の過程や交流も大事にして、良い経験となるようにサポートしていきます。
3週間後の成果発表と成長した姿が今から楽しみです!

Atlassian製品のアドバンテージ「Application Link」

Atlassian製品のアドバンテージ「Application Link」

Application Linkとは

アプリケーションリンクとは、Atlassian製品にデフォルトで含まれている、JIRA, Confluence, Stash, FishEye, Crucible, Bambooの各製品を相互に連携させるための機能です。
アプリケーションリンクを設定すると、リンクさせた製品同士が相互に情報をやりとりしたり、お互いの機能を利用することが出来ます。
例えば、JIRAとConfluenceをリンクさせた場合、JIRAのチケットをConfluenceのマクロを利用してリンクさせたり、
ConfluenceでからJIRAのチケットを作成するなど、お互いの利便性を向上させることが出来る機能です。

Atlassian以外の製品でも、CIツールと、リポジトリ管理ツールの連携や、課題管理ツールとCIツールの連携などが用意されている場合もありますが、
違うプロダクトを連携させる場合とくらべてAtlassianのアプリケーションリンクはより密接な連携ができるというメリットがあります。
また、設定も簡単にできるため、「サクッと連携できると思っていたけのに意外とハマった。」ということが起こらない点もメリットといえると思います。

Bamboo + Stash をリンクすると

では、具体的にはどうなるのでしょうか。
Bambooの公式ドキュメント などを見ると、このようなことが書いてあります。

  1. Stashのリポジトリに新しいコードがpushされると自動的にビルドを実行させることが出来ます。(Stash以外のリポジトリの場合ははBambooが定期的に更新を確認する必要があります)
  2. Stashの指定したリポジトリに新しいブランチが作成された場合、Bambooが自動的にそれを検知し、ブランチのビルドプランを作成します。 また、ブランチが削除された場合はBamboo上のブランチに対するビルドプランを自動的に削除することも可能です。
  3. Bambooのビルド結果から、そのビルドに含まれているコミットの変更差分確認画面へダイレクトにジャンプ出来ます。
  4. Bambooのビルドに含まれているStashのコミットのリストをBambooのビルド結果から確認出来ます。
  5. コミットやプルリクエストに対するビルド結果をStash側で確認することが出来ます。

ブランチの自動作成

アプリケーションリンクの機能は業務でも使用していますが、今回はその中でも便利だと感じているブランチの自動作成機能を紹介します。

  1. Bambooのビルドプラン設定からブランチの自動作成設定が出来ます、すべてのブランチを作成 することもできますし、正規表現にマッチするブランチだけを自動作成することも出来ます。
    GitFlowで開発している場合に、featureブランチのみ自動作成するという設定も可能です。

2.Stashで(もしくはGitコマンド経由で)ブランチを作成すると。

3.Bambooが自動的にブランチをビルドプランに追加してくれます。

ビルド対象のリポジトリが少ないうちは、Bambooの管理画面から手動でブランチを追加する作業も苦になりませんが、
リポジトリが増えてくるに連れて徐々に便利さが実感できるようになってきます。

その他の製品のApplication Linkについて

さて、こんなに便利なApplicationLinkですが、今回のBambooとStashの組み合わせ以外にも様々な組み合わせが存在します。
ApplicationLinkを設定することでどんなメリットがあるかは下記リンク先のドキュメントをご参照ください。

Stash

JIRA+Confluence

Bamboo+Confluence

RedmineなどのAtlassian製品以外のツールでも、CIサーバーや、リポジトリ管理ツールなどとの連携は可能ですが、 Atlassian製品で揃える事による「設定が簡単でハマりにくい」というメリットは大きいです。

Atlassian製品をお使いなら非常に便利ですので、是非アプリケーションリンクを活用してみてください。

javascriptのimmutableデータを感じてみよう

javascriptのimmutableデータを感じてみよう

こんにちは、KEYチームの荒木です。本日はjavascriptのimmutableについてです。

今話題としては(もう古いかもしれませんが)immutableですか? javascriptはobject型をのぞく全ての型は不変 (immutable) な値として定義されていますが、不変な値とそうでない値ではどのような違いがあるのかをみてみましょう!

imuutableなデータを扱う

mutableなデータを扱う

ソースの実行結果は

mutableなデータを取得してみると53.768ms

immutableなデータを取得してみると(一度作りなおす必要はありますが)0.221ms

とても早いですね。

簡単に扱うimmutable.jsもありますので是非使ってみてください。

参考1: https://developer.mozilla.org/ja/docs/Web/JavaScript/Data_structures

参考2:https://www.youtube.com/watch?v=I7IdS-PbEgI

RaspberryPiからGoogle Calendar APIを呼んでみた

RaspberryPiからGoogle Calendar APIを呼んでみた

RaspberryPiでGoogle Calendar APIを呼んでみた

みなさん、こんにちは。KEYチームの矢納です。

技術ネタ第3弾!!「RaspberryPiでGoogle Calendar APIを呼んでみた」です。
過去記事の目次はこちらに移動しました。

なぜやろうとしたのか

弊社では会議室の予約にGoogle Caldendarを使用しています。皆さんスケジュール管理をほぼGoogle Calendarを使用しているので、同時に見る事ができて便利です。

さて、弊社には1〜3人しか入れない部屋があります。電話ボックスなどと言われています。もちろんこの部屋も予約可能です。ですが、多くの人が予約をせずにこの部屋を使います。そうすると実際に使おうと思っていた人が使えなくなってしまいます。

ですので、その部屋に入った際にその部屋の予定を表示してあげて、いきなり入った人にお知らせするモノを作ろうと思いました。部屋は小さいのでできればコンパクトに予定を表示したいです。最近、Raspberry Pi公式のディスプレイが発売されたのでそちらに表示させます。

表示の前にGoogle Calendar APIを利用してその部屋の予定を取得する必要が有ります。Raspberry PiでどのようにGoogle APIの呼ぶのかが気になったので、実際にやってみました。

OAuthのやり方

Google APIを使用するには認証をする必要が有ります。パソコンであるのならブラウザでID/PASSを入力するのですが、RaspberryPiには標準ではディスプレイがありません。ではどうすれば良いのでしょうか?

今回はこちらを参考にしました。

OAuthのやり方は右図を見ると分かり易いですね。

  1. Androidですか?iOSか? → いいえ、違います
  2. ブラウザがありますか? → いいえ、ありません

つまり、「Using OAuth 2.0 for Devices」となるのです。


Step1. Client ID と Client secret の作成

ここから、実際にGoogleAPIを呼ぶための準備等を行っていきます。

  1. Google Developers Consoleにアクセス。
  2. Create Project
    • Project Nameは任意に決めてください
  3. 左のメニューから APIs & auth -> credential 選択
  4. Create new Client ID ボタンクリック
    1. Installed Application -> Other -> Create Client ID 選択
    2. 作る際にConsent screenの入力を求められるかもしれません。その際は適当に入力してください。
  5. Client ID と Client secret の出来上がり

Step2. ユーザコードの取得

  1. https://accounts.google.com/o/oauth2/device/code に対してPOSTリクエスト

    • Hedaer: 'Content-Type: application/x-www-form-urlencoded'
    • Parameter: client_id={Step1で取得したClientID}
    • Parameter: scope={こちらを参照} $ curl -d "client_id={Client ID}&scope={scope}" https://accounts.google.com/o/oauth2/device/code

※scopeが複数ある場合は空白でつなげる

レスポンス

{
  "device_code" : "4/4-GMMhmHCXhWEzkobqIHGG_EnNYYsAkukHspeYUk9E8",
  "user_code" : "GQVQ-JKEC",
  "verification_url" : "https://www.google.com/device",
  "expires_in" : 1800,
  "interval" : 5
}

Step3. デバイスの承認

このステップはご自身のパソコンで行ってください。

  1. Step2でのレスポンス内のverification_urlの内容にブラウザでアクセス
  2. 「Enter the code displayed by your device:」と表示されますので、Step2でのレスポンスのdevice_codeではなく user_code を入力してください。
  3. あとは指示の通りに進んでください

Step4. アクセストークンの取得

  1. https://www.googleapis.com/oauth2/v3/token に対してPOSTリクエスト

    • Header: 'Content-Type: application/x-www-form-urlencoded'
    • Parameter: client_id={Step1で取得したClientID}
    • Parameter: client_secret={Step1で取得したClient secret}
    • Parameter: code={Step2でのレスポンスのdevice_code}
    • Parameter: granttype='http://oauth.net/granttype/device/1.0' $ curl -d "clientid={Client ID}&clientsecret={Client secret}&code={devicecode}&granttype=http://oauth.net/grant_type/device/1.0" https://www.googleapis.com/oauth2/v3/token`

レスポンス

{
  "access_token" : "ya29.AHES6ZSuY8f6WFLswSv0HELP2J4cCvFSj-8GiZM0Pr6cgXU",
  "token_type" : "Bearer",
  "expires_in" : 3600,
  "refresh_token" : "1/551G1yXUqgkDGnkfFk6ZbjMLMDIMxo3JFc8lY8CAR-Q"
}

Step5. Google Calender API呼び出し

アクセストークンをパラメータに設定してリクエストを出せば結果が返ってきます。

例) ある特定の日のイベントを取得する。

https://www.googleapis.com/calendar/v3/calendars/{CalendarID}/events?singleEvents=true&orderBy=startTime&timeMin=2015-07-14T00%3A00%3A00.000Z&timeMax=2015-07-15T00%3A00%3A00.000Z&key={access_token}

Calendar APIに関してはこちらのリファレンスページをご参照下さい

さいごに

これでブラウザを持たないデバイスでのGoogle APIの呼び出しができました。アクセストークンには有効期限が有りますので、期限が切れてしまったらリフレッシュトークンを使って更新を行ってください。

Google Calendar APIで予定は取得できるようになったのですが、まだディスプレイが届いていないので実際のモノは作れていません(ToT)。またモノができましたら記事を書くかもしれませんのでお待ちください。

Email: yanou at atware.co.jp

GebでCookieを扱ってみる

GebでCookieを扱ってみる

みなさんこんにちは。KEYチームの武永です。

今回も引き続きGebネタです。 前回の記事は こちら

今回はGebでCookieを触れるのかちょっと個人的に気になったので調査して実際に動かしてみました。

作成したプログラムは以下の様な単純なものです。

  1. 「Yahoo!JAPAN」にアクセス
  2. タイトルの検証
  3. 現在のCookieを全てコンソール上に表示
  4. 以下のようなCookieをセット
    Name : GebCookie
    Value : atware.co.jp
  5. セット後のCookieを全てコンソール上に表示

ソースコードはこちらです

そして実行して表示されたものがこちらになります。

--設定前 Cookie 出力開始-----
name  : btpdb.2wzBV9u.dGZjLjE5ODkzNTc, value : REFZUw
name  : B, value : 5g9cb99atlbkl&b=3&s=3n
name  : btpdb.2wzBV9u.dGZjLjE0MzQzNDg, value : VVNFUg
name  : btpdb.2wzBV9u.dGZjLjE0NDcxNDU, value : UkVRVUVTVFMuMA
--設定前 Cookie 出力終了-----
--設定後 Cookie 出力開始-----
name  : btpdb.2wzBV9u.dGZjLjE5ODkzNTc, value : REFZUw
name  : GebCookie, value : atware.co.jp
name  : B, value : 5g9cb99atlbkl&b=3&s=3n
name  : btpdb.2wzBV9u.dGZjLjE0MzQzNDg, value : VVNFUg
name  : btpdb.2wzBV9u.dGZjLjE0NDcxNDU, value : UkVRVUVTVFMuMA
--設定後 Cookie 出力終了-----

確かに作成したCookieがセットされていることが確認できます(赤字部分)。

このやり方を使えば自分達が意図したとおりにCookieがセットされているかどうかを確認することが出来ますね。
実際にCookieの値を検証するかどうかはプロジェクト次第ではあると思いますが、参考になれば幸いです。

キュウカンチョウ

キュウカンチョウ

KEYチームのアライです。
ご存知の通り、9月1日は防災の日ですね。
幼少期は毎年防災頭巾を被り、避難訓練をしていたことを思い出します。

アットウェアでは万が一に備えて、非常食を備えています。
救缶鳥プロジェクト(http://www.daily-ad.jp/kyucancho/)に賛同し、2014年から始めました。

救缶鳥プロジェクトとは、非常食を供えることで世界の飢餓救済の活動に参加できるプロジェクトで、
賞味期限3年間の非常食(パン缶)を2年間備蓄後、
残り約1年の間に日本中から回収・輸送され、飢餓に苦しむ国々へ届けられる仕組みになっています。

我々ができる事は限られているので、少しでも役に立てればと。

KEY TEAM BLOG ~EPISODEⅢ~

KEY TEAM BLOG ~EPISODEⅢ~

KEYチームのBLOG祭り第三弾として、
今日9月1日から毎日、メンバ日替わりでブログを投稿していきます!

毎日投稿しますので、是非ともご一読下さい!