社内用のChrome Extensionを作って公開した話

この記事は atWare Advent Calendar 2015 の19日目の記事です。

みなさん、こんにちは。最近モンハンXにハマっている武永です。

今回はモンハンの話！！。。。。。は全く関係なく、社内用にGoogleChrome Extensionを作って公開した話をしていきます。
モンハンの話をしてもいいのですが、会社のブログですることではないということで。。。
最後の抵抗に画像だけモンハンを使いましたが。。。

何を作ったのか？どうして作ったのか？

作成したものは一言で言ってしまうとGmailからBacklogの課題にスターを付けるというものです。
atWareでは課題管理にBacklogを使っています。
そして日報・週報・月報をBacklogに課題として書いていくという取り組みをしています。（日報などを課題として上げるという運用はどうなんだという話は今回は脇に置いておきます）
Backlogには課題にスター（いいねのようなもの）を付けることができます。日報などをせっかく書いたのに反応が少ないと悲しくありませんか？モチベーションが下がりませんか？
私はモチベーションが下がる1人です。
こういう状況に他の社員の人にはなってほしくないけど日報などに毎回コメントを書くのも難しいよね。ということで私は「日報を読んだよ!!」という意味も込めてスターを付けています。

課題を追加するとメールが送られてくるのですが、そのメール内には課題の内容が全て書かれています。
メールを見るだけで日報は読めているのに毎回その課題にBacklog上でアクセスしてスターを付けるのも面倒だなと感じていました。
大した手間ではありませんが、自分の勉強のためと少しでも楽になればいいやということでメールから直接スターを付けれるようにしよう！と考えて作り始めました。

最初は公開する気はあまりなかった

前述の通り自分の勉強のためという理由も大きかったので作っても社内で公開するという考えはありませんでした。
では何故公開しようと思ったのか。
atWareではatWare Awardという社員が何か作成したものを出品するコンテストがあります。（atWare Awardの詳細は今回は省略させていただきます）
そこで作ったChrome Extensionを発表した結果

公開して欲しい
Chrome ExtensionだけではなくFirefox アドオン版も欲しい

という声があって、「あー意外と需要あるんだ」とそこで初めて実感しました。
それなら公開しよう！！ということで社員限定で公開し始めました。

公開した結果

自分の環境だと安定して動作していたので公開しても大丈夫かなと思っていました。
しかし、いざ公開してみると

エラーのalertが出た
APIキーを入力する画面が出てこない

など結構問題を指摘されました。
環境差分ってやっぱりあるのかーというのが感想です。
自分の環境で動いたからと言って必ずしも動くわけではないという基本的なことが頭から抜け落ちていました。
Chrome Extensionは内部のコードを見ることができるので簡単にコードレビューをしてくれた方もいました。
そこで指摘されて気づいた不安定要素などもあったのでありがたいですね。

自分で作って自分で動かして満足するのではなく、公開して他の人にも使ってもらうことで自分の成長にも繋がると改めて実感した出来事でした。

最後に

色々と不具合もあったのでもっと安定したものを作っていきたいなと思っています。
あと要望もあったFirefox アドオンも作ってみたいですね。（まだ全然手を付けられていない）
今回で社内用のツールって使われる、使われないはとりあえず置いておいて、自分の気づいたところから作ってみて公開していいんだ！！というモチベーションに繋がりました。
自分の勉強にもなるし、上手くいって使われるようになるといいなぁと。。。

RethinkDB + Go Lang

この記事は atWare Advent Calendar 2015 の18日目の記事です。

皆さん、こんにちは。4回目の登場の矢納です。
今回はプロジェクトで使っている技術紹介です。

何を使っているの？

現在私のプロジェクトはWebサービスを作成中です。メンバーは2、３人で行っています。この人数なのでフロント・バックエンド両方の開発を進めています。フロントエンドはReact.js + ES6、バックエンドはGo言語を使って開発を行っていますDBにはRethinkDBを使っています。

RethinkDBのライブラリ

RethinkDBには多くのAPIが用意されています。それらを使って操作を行います。RethinkDBには管理画面が用意されており、その画面からAPIを呼び出す事ができます。

この管理画面ではJavaScriptでスクリプトを記述します。オフィシャルで出ているドライバーは４つ。JavaScript, Ruby, Python, Javaです(参照)。ですが、今回はGo言語を使っての開発です。ではどうするか。コミュニティが作成しているgorethinkを使います。

どうやって使うの？

これは至って簡単。
まず最初にインストール。

$ go get -u github.com/dancannon/gorethink

DBとの接続。

import rdb "github.com/dancannon/gorethink"

session, err := rdb.Connect(rdb.ConnectOpts{
    Address: "192.168.50.50",
    Database: "test",
    AuthKey: "J98p2JgcdAXd2V2d",
})

などと、基本的なやり方はGithubに書いてありますので、そちらを参照して下さい。

これで終わるのも寂しいので個人的に少し悩んだQueryをご紹介。
私はよく管理画面でJavaScriptでQueryを作成してから、Go言語になおしていきます。

r.db('test').table('user').
  filter(function(user) { return user('role').ne(90); }).
  filter(function(user) { retrun user('isDeleted').ne(true); })('email');

これはUserテーブルからroleが90以外かつisDeletedにフラグがtrueでないユーザのemailの情報を取得するといううクリプトです。これをGo言語で書くと

resp, err := rdb.Table('user').
Filter(rdb.Row.Field("role").Ne(90)).
Filter(rdb.Row.Field("isDeleted").Ne(true)).
Field("email").
Run(database.Session())

となります。

さいごに

Go言語もRethinkDBもかなり早いです。RethinkDBはリアルタイム性をかなり重視しています。またGo言語もシンプルになるように考えられている言語なのでとても良い言語です(個人の感想です)。

Scala先駆者インタビュー VOL.3 ビズリーチ竹添さん 〜後編〜

Scalaをやり始めるきっかけに貢献していければ...

インタビューイー ビズリーチ 竹添

インタビューワー アットウェア 浅野/エリシール/ジェフ エムスリー 瀬良

---

Scala先駆者インタビュー VOL.3 ビズリーチ竹添さん 〜前編〜から続き

瀬良：Scala Days 2015に参加したりScala meetupを開催したり、アクティブに活動しているJeffさんからも竹添さんに聞いてみたいことはないでしょうか？

Jeff：そうですね。最近Twitterでも話題になったり、Scala Days 2015でキーノートで紹介された次世代のScalaコンパイラについて聞いてみたいですね。次世代のDottyコンパイラはJVMで動作できるバイトコードやJavaScriptまで一気通貫して生成できるものですが、そのあたりについてどう思いますか？

瀬良：僕らはScalaが好きなのでScala.jsにも興味がありますが、世間一般的にはあまり関心度は高くないような気がします。現在のコンパイル速度が速くないので、そこは一般的な方々が気にしているところでもあります。将来的にコンパイルが速くなれば状況が違ってくるのですが、現在は劇的に速くなる兆候は見られていません。

竹添：Scala.jsについてですが、今、弊社の一部のプロジェクトではTypeScriptを使っています。既存のJavaScriptと同時に使えるというのが大きくて、必要なところだけタイプセーフにできます。Scala.jsは基本的に全てScala.jsの世界に持ってこないといけないのでハードルが非常に高いんですよね。Scala.jsのアプローチがこのまま続くのかはわからないのですが、今の状態だとカジュアルに使うのは厳しいんじゃないかと感じています。

Jeff：Dottyコンパイラを使うと一気通貫してコンパイルできる点以外に、他にメリットと感じているところはありますか？

竹添：今はパッと思いつきませんが、コンパイルが速くなると嬉しくなりますね。

瀬良：もしコンパイルが早くなるとしたら、差分コンパイルだけでなく、フルコンパイルも早くなるかが気になりますね。SBTサーバーなどの取り組みもうまくいくといいですが、どうでしょうね。

浅野：ScalaMatsuriが直前に控えていてScala熱は高まるばかりですが、昔からScalaコミュニティの姿を見ている竹添さんにはどう見えますか？

竹添：エッジが立っている人は先に行って裾野との距離感が5年前と比べるととてつもなく広がったと感じています。

瀬良：どういう所でしょうか？

竹添：新しい領域に踏み込んだり細部を突き詰めて成果を出してくださる方々がいます。それとは別に、新たに使ってくれる人がいてScalaのコミュニティが大きくなっていかないと未来がないと思っています。役割分担だと考えますが、そういう泥臭い所を逆に先端でやっている人が頑張るのは少し違うと思っていて、その辺りを個人的にも会社的にも力を入れていけるといいなと考えています。

Scala逆引きレシピ本を書いた理由も当時すぐ現場に入ってリファレンスにできる本がなかったので、必要だなと思って書いたのと、初心者向けの勉強会をしたりしました。こういう事は全体として重要だと思っています。

この辺りは他の言語と比べるとギャップがあると感じます。

浅野：飛び抜けている人とやり始めた人との中間層が抜けているということでしょうか？

竹添：そうですね。Scalaをやり始めるにあたり、最初から知らなくてもいいことがあって、最初はビビる必要はないのに恐怖感を与えてしまっている所があります。そこに難しさを感じます。

浅野：Scalaをすでに実践的に使っている人に聞くと「関数型プログラミングを完璧に最初から求めなくてもいいよ」「Better Javaとして使うのもいいと思います」という声も聞きます。それでも今からScalaをやろうとした時にハードルの高さを感じてしまいそうなポイントはありますか？

竹添：使うフレームワークに敷居の高さを感じるかどうかですね。PlayやSlickは最初の選択肢になりやすいのですが、例えばJSONのReads、Writesを記述する必要が出てきた場合に、Javaならリクフレクション1発で終わっていたところが、どうしてこれが必要なのかを説明しても理解されなかったり、セッションやクッキーの扱いが直感的でなかったりするところも障壁になったりします。

また、入門者がフレームワークのコードを見て解決できるかというと難しいですね。

比較的理解しやすいScalatraやSkinny Frameworkなどを使って入っていくと心理的抵抗感はないと思いますが、Playが標準的なフレームワークとなってきたので、Playの教育をせざるをえなくなってきています。

瀬良：私はScalatraやSkinnyFrameworkのメンテナをやっているという事もあって、Servletで済むプロジェクトはそれでいいじゃないかなと思っていますが、ScalaなんだからScalaらしくFutureでやったほうがいいという意見も周りではあったりします。

もう少し言うと、関数型プログラミングとオブジェクト指向プログラミングの対比やFutureの用途の使い分けなどがあります。要件によってはServletでも支障がない場合もあったりするので棲みわけが今後は進んでくるのかなと思います。

竹添：あまり標準的ではないものを使っていくとフレームワークの開発が止まってしまったりといった危険性もあるので、Typesafe社がその辺りの選択肢も用意くれると嬉しいのですが、現在はScalatraやSkinnyといったコミュニティベースのものしか選択がありません。特に受託開発で使う場合はServletで十分なケースに対して標準的な選択肢があると嬉しいのではないかと思います。

私も業務アプリケーションの受託開発では必要以上にパフォーマンスやスケーラビリティが要求されるケースもありませんし、Servletで良い部分もあるのではと思ってやっていました。

浅野：少し話はかわって、Scalaを使っていてワクワクすることはありますか？

竹添：...（少し考え） 新しいものがどんどん出てくるのがテンションが上がりますね。Scala.jsもそうですが、実用的かどうかはさておき、本当に使えるかわからないけど面白いからやってみたというフェーズはJavaでもあったのですが、次第と成熟したプラットホームになると少なくなくなってきます。Scalaは今面白いからやってみたというフェーズで、postgresql-asyncのような興味深いものもたくさん出てきてますよね（笑）

瀬良：postgresql-asyncはNettyを使って実装されている、完全にJDBCを使わず同じようなことを自前で全部やっているやつですね。

竹添：はい。直接PostgreSQLと通信していてノンブロッキングIOで処理するというドライバーです。

瀬良：ブラジルの人が1人で書いてポンッと出てきたというのは今Javaではあまりないですよね。

竹添：そういう面白いものがどんどん出てきたり、ライブラリも使っていると新しい発見もあったりしてそういうところが一番ワクワクしますね。

瀬良：Scalaの普及を助けるという方向性でやっていきたいことや計画していることはありますか？

竹添：Scalaの新しい本を出したいと思っています。とある書籍の翻訳をやっていたり、それとは別に「プログラミング自体を初めてする初心者の人がScalaで」という趣旨の本の企画を考えています。

浅野：竹添さんが作られている、GitBucketの話も合わせて聞かせてください。

竹添：Scalaにとって、Scalaを触り始めるきっかけになるようなキラーアプリが少なく、GitBucketにはプラグインの仕組みがあるので、例えば「Tracのプラグインを作りたいからPythonをやり始めました」というような、ユーザがカスタマイズを通してScalaをやり始めるきっかけになれればいいなと思っています。

すごく熱心にパッチやプラグインを作ってくださっているユーザも増えてきています。

時には「Pythonしかやったことないからすごく難しいんだけどどうすればいい？」って質問もきたことがあります（笑）

浅野：そういう時はどう返信するんですか？

竹添：「いい勉強になると思うよ」っていいました。

瀬良：こういう事をきっかけにScalaをやり始めるというのはいいですね。

竹添：そうですね。これをきっかけにしてもらえると嬉しいです。GitBucketは本体を機能満載にすると身動きが取りづらくなってしますので、プラグインベースにしていきたいと考えています。

瀬良：UIもプラグインで作れるのでイメージとしてはJenkinsに近いのでしょうか？

竹添：はい。プラグインで自由度高く実装できる仕組みにしています。今ならプラグイン数も少なく手をつけれそうな所も多いのでチャンスです（笑）

瀬良：他にもこの機会に竹添さんに聞いてみたいことは...

浅野：Akkaについてはどうでしょうか？普段使っていますか？

竹添：普段使っていますが、なかなか厳しいところがあります。というのも、モニタリングがしづらいという点です。

標準でモニタリング機能がなく、メッセージがどこまで到達しているのか、どこかで詰まっているのかといったことを把握することが難しいためデバッグが困難になります。今はKamonを使ってGrafanaで可視化するということを試しているのですが、AspectJで実現されている仕組みということもあって、Akkaがバージョンアップした時にKamonを追従してアップデートしてくれないという運用リスクがありそうです。Akka自体にJMXなどで監視の口があるといいなと思います。

瀬良：Kamon をすすめる声を聞いたことがあります。

最近、Reactive Streamsが良さそうと言う人が日本で増えてきたのですが、例えばReactive Streamsのバックプレッシャーなどの状態をモニタできるようになればいいなと思います。それが標準的にTypesafeプラットホームで使えるようになればいいですね。

それと、ビズリーチさんの実務での成果をぜひオープンソースにして欲しいですね（笑）

竹添：リフレクションを使ってAkkaの中を確認したのですが、Akkaが中でデータを持っていなくて、通信の口もなく、そうするとKamonのようにインターセプトするようなやり方になってしまいます。

瀬良：Akka HTTPについては？

竹添：今は自社のサービスの使い方でアプリケーションレイヤーでそこまで必要性が出てくるかどうかを見極めています。Akka HTTPを利用すると並列度が上がってFutureベースになっていき、スレッドプールサイズの調整の制御が難しくなるので、透過的にスレッドプール増減を含め管理してくれるフレームワークがあると楽でいいのになと思います。

瀬良：Play 2.0 がでた直後の頃、Akkaの設定をデフォルトのまま本番稼働したところ想定していたほど性能が出ず、スレッドプールのサイズを大きくする必要があったという話はよく聞かれましたね。

竹添：Akka難しいですね。クラスターにして大きくするべきなのか、1個ずつ立ててリモートでラウンドロビンで回した方がいいのか、いろんな組み方ができるので難しいですね。

瀬良：Actorモデルのシステムデザインってみんながスムーズにできるものでしょうか？

竹添：私はシンプルな使い方しかしていませんが、大きなものになってくると運用も設定も難しいでしょうね。

Jeff:Akkaは仕組み的には単純ですがとてもパワフルなプロダクトで、そういう所が好きで私もよく使うのですが、 Sparkのような大規模な分散フレームワークを作るとすると大変かもしれません。小規模のアプリケーションでAkkaを使用していますが、知り合いから聞いた話になりますが、規模が大きくなってきて複数のシステムが関連あってくるようなアプリケーションではトラブルシューティングが非常に難しいと言っていました。

AkkaはSpringのような便利なアプリケーションフレームになっているので、用途に応じて選択して使えば素晴らしいアプリケーションを作ることができるはずです。

瀬良：Scala習熟度が様々なチームメンバーと一緒にScalaプロジェクトをやってみて発見したことや気づきはありましたか？

竹添：最初はimplicitを多用して指摘を受けるという人がいたりしました。単純に機能を知らない人もいたり、traitの使い道はある程度指針を決める必要はあると感じました。そうしないとチームとしてブレが出たり、後から入った人がわからなかったり、レビューが好き嫌いの趣向で不毛になってしまいがちです。

瀬良：今はこういう風にしていますという、ルールやスタイルはありますか？

竹添：チームによってレベル感や使っているライブラリなども違うので、チーム毎にルールを決めてもらうようにしています。習熟しているチームはscalazを普通に使っていたり、関数型のスタイルを推奨していたりします。

瀬良：私たちのチームもチーム毎に違います。ルールや使うツールを他チームに押し付けるような形にはしていません。

竹添：うちはインフラ周り担当者の負担を考え、最低限WebアプリケーションフレームワークはPlayに統一しようという話はしていますが、必要性に応じてバージョンやそれ以外のフレームワークは変えたりします。

浅野：長時間ありがとうございました。最後に一言お願いします！

瀬良：Scalaの将来について聞きたいですね。2年後くらいの。例えば自分のScalaとの関わり方など。

竹添：たくさんの人に使ってもらえるものを作りたいと思っています。私はツールを作るのが昔から好きでEclipseプラグインを作ったり、今はGitBucketを作っているのですが、ユーザ数は多い反面、Scalaユーザに知られていない印象があるので、知ってもらえたら嬉しいです。

ScalaがJavaの置き換えになるほどの爆発的な普及はしないと思いますが、5年くらい前に今の状況は想像できていませんでした。予想より普及はしているので2年後はどうなるかわかりませんが、普及に少しでも貢献できたらと思います。

浅野：次回のインタビューの人をご紹介いただけないでしょうか。

竹添：私はSIを離れてしまいましたが、現在進行形でSIerでScalaの導入に尽力されているTISの前出さんのお話を聞いてみたいので、声をかけてみますね。

浅野：ありがとうございます。

お知らせ

ビズリーチでは「スタンバイ」という求人検索エンジンを作っています。

スタンバイのシステムではScalaがバックエンドで動いています。もしよければご参照ください。

あとがき

前回までインタビューアをしていた北野さんが急病でダウンで欠席し、当日に急遽私がインタビューアを引き受けて、拙さもありながらもゆったりとした時間の中で竹添さんに色々と自分の言葉でお話を聞ける貴重な体験でした。そういう状況を察してか瀬良さんも様々な質問をしてくださり感謝しています。当日の雰囲気を写真と文章でしかお伝えできませんが、原稿起こしをしている際に再度ワクワクしてしまった事はお二人の魅力の他ありません。どうもありがとうございました。

2015.12.17 Asano

Scala先駆者インタビュー VOL.3 ビズリーチ竹添さん 〜前編〜

「Scalaのアドバンテージはどういうところか？」を深く考えた先に

インタビューイー ビズリーチ 竹添

インタビューワー アットウェア 浅野/エリシール/ジェフ エムスリー 瀬良

---

浅野：今日は前回の瀬良さんからのご紹介で、GitBucket という Scala で書かれているオープンソースのGitHubクローンを開発されている、ビズリーチのCTO室チーフアーキテクト竹添さんです。まずは、瀬良さんから次の紹介者として竹添さんをご指名頂いた経緯をお願いします。

瀬良：このScala先駆者インタビューで、最初にヌーラボの吉澤さん、次に私という流れできましたので、毛色を変えた話をできたら面白いんじゃないかと思いました。というのも、Scalaインタビューを実施されているアットウェアさんが受託開発をやっています。そこで、前職で受託開発をして現在では自社サービスをやっており、双方でScalaを採用した竹添さんに、前職を離れてみて感じたことや受託開発当時をふりかえりながら様々な視点で話をできたらいいなと思いました。

竹添：受託開発では結構大変でしたね。技術的な採用決定権がある仕事ばかりではなかったので、Scalaをどういう切り口でお客さんに導入してもらうかといったあたりは最初苦労しました。

浅野：弊社だと、アットウェアのバリューを出してエンドユーザや顧客に価値を届けるためには、技術的決定権だったりいいと思えるものが提案できるという要素は必要だと感じていまして、ある程度技術的なところは裁量をもたせてもらいプロジェクトを進めさせていただくことが多いです。

竹添：そういう技術的決定権やいいものを提案しやすい状況の時にScalaのアドバンテージはどういうところだと考えていますか？前職の時そういうことをよく考えていました。

浅野：私はまだまだScala駆け出しでありきたりの言葉になりますが、後発の言語ということもありマルチコア時代の並列処理が書きやすく、扱いがしやすいのと、分散環境に対して最小限のリソースを最大限に活かしていくという辺りでうまく適用できる辺りと考えています。

瀬良：Jeffさんにも話を聞いてみたいですね。

Jeff：つい最近、1ヶ月でアプリケーションのプロトタイプを完成したいという方がいらっしゃいました。（冗談っぽく）その時私は「この要件だと1ヶ月以内でJavaでやるにはちょっと厳しいですね。逆にScalaで問題なければ、何とかなりますよ。」と言いました。これが、今までのベストアンサーかもしれません（笑）。

全員：アハハハ（笑）。

Jeff：話に戻ると、お客さんにScalaを他のプログラミング言語の代わりに売りにした時は、基本的にはScalaだけではなくTypesafe社の他の技術と一緒に紹介することによって、この技術群の全体的な有用性を強調しています。

竹添：なかなか難しいところですよね。やっぱり何ができるようになるのか、保守を5年～10年して欲しいという話があったり、コストもJavaで作った時と比べてどれくらい安くなるのか、早くできるのかのアドバンテージが出せないとなかなか難しいと当時思っていました。テクノロジーの話だけだと説得力がなくて、一般的な業務アプリケーションではScalaの特徴である並列処理などのメリットも出しづらく、保守でもOSやハードやミドルウェアもすでに購入が決まっていていることもあったりで、そこに突っ込んでいくことが難しかったです。

また、お客様は技術者ではないことも多いのでテクノロジーの話をしても伝わらないこともあります。

瀬良：それっていつ頃ですか？

竹添：2010年ころから取り組み始めてScala Conferenceのちょっと前くらいまでの頃の話ですね。

瀬良：Scalaのバージョンが2.9でTypesafe社もまだ設立前、Play2がちょうど出たあたりの頃でしょうか。Red Hat 社でいうJBossのような土壌がなくて、進みにくい時代ですよね？

竹添：Scalaとしては当時はPlayがネームバリューがあって、巷ではScalaの名前を聞きはじめ非同期とか分散処理に強いという情報が本に載り始めた頃で、Playという単語で攻めていく感じでした。あとは、「うちとしてもトライアルなので一緒にやらせてください」とお願いしたり、Javaで作ったシステムのリプレース案件もあり、当時Seasarの行く先がなさそうだったので、「新しいものにしていかないと保守が辛くなっていきますよ」という話をしていました。

瀬良：アットウェアさんはTypesafeのコンサルティングパートナーということで、興味があって聞きたいことなのですが、Typesafeのコンサルテーションサービスは私が知る範囲ではまだまだ利用が進んでいないように感じています。問い合わせは感覚的に想定より多いものなんでしょうか？

Jeff： クライアントは興味は持ちますが、Scalaを使うところまでなかなかいかず、Javaなど枯れた技術を望まれている事が多いです。ScalaでというよりSparkの問い合わせが多くそれに合わせてScalaがやりやすいので、Scalaを勧めることもあります。

竹添：前職では10名くらいのチームでアジャイルで小さいプロジェクトを短期間でイテレーティブにやっていました。長い間Javaでずっとやっていましたが、これ以上Javaでやっていても生産性が上がっていかないなという頭打ち感があって、他に何か新しいものをやっていく必要性を感じました。

プロジェクト自体が小さく、限られたメンバーなのでやっていけたというところもあります。

プロジェクト規模によってはScalaで生産性をあげるということよりも、きっちり仕様に従って動くものを作ることが重視されることもあります。また、Sparkが普及したからといってScalaのデベロッパーがすごい増えるかというとそういう風には思えず、Web界隈では使われはじめてきていても、エンタープライズな開発にScalaが使われていくようにならないと、全体としてScalaデベロッパーのボリュームが増えたかという観点で厳しくて、やっぱりSIerの数の力というのはすごいという事を現職になってから強く感じました。

瀬良：竹添さんが前職でやっていたプロジェクトは割と少数精鋭でやっている事が多かったと聞いてますが、社内で相談を受ける案件は大きなプロジェクトも多かったのではないでしょうか。

そういう大きい案件は、Javaで作られた基幹システムの一部をリプレースする提案だったり、全体のリプレースに向けた提案だったり前提はあるとは思いますが、Scalaを売りにいこうとしていた大きな案件のタイプと、どう合わなかったのかを教えていただけないでしょうか？

竹添：特定のプロジェクトというより次期システムの計画を立てている段階であったり、Seasarを使っているけど今後どうしていこうか考えているという話が多かったです。大きなプロジェクトだとScalaをできる人を集めるのが難しいという理由が一番大きかったです。

当時はJava8のリリースが控えていたので無理にScalaに行かなくてもというのはありました。

浅野：違う軸で話をしますと、Java6〜7時代の停滞時期もあり、コップ本（コップ本は通称で「Scalaスケーラブルプログラミング」という書籍名です）の発売でScalaの波がきたのを感じました。

瀬良：メインでScalaを使っている人が増えてきましたね。

竹添：実は若い頃LispやHaskellをやっており言語のフィロソフィーには共感していました。ただ、それらの関数型言語は仕事で使うには無理かなと思っていたのですが、Scalaの登場ではじめて仕事で「業務と関数型の力を両立」させられる言語に出会ったというのを感じました。当時の同僚がScalaをずっと前からやっていてはじめて聞いた時には「やっぱりまだ厳しいんじゃないかな」という話をしていたのですが、それから暫く経ってSeasarの次をどうしようかという時に「Scalaはやっぱいけるかも」という話をしたのを覚えています。

瀬良：このあたりの話は以前にもおっしゃっていましたね。竹添さんの立場も変わって1年以上経ちました。違うスタイルでScalaと関わってきています。今の視点でお話が聞けると面白いんじゃないかと思います。

竹添：現職ではスタンバイという求人情報の検索サービスを作っているのですが、最初プロジェクト立ち上げの段階から数十人規模のチームを作らないといけなくて、Scalaで大丈夫かなという心配がありました。

最初から大きくしていく事も想定しておりマイクロサービスも視野に入れていました。 Scalaでやると決めたら育成や採用に力を入る必要があって、前職では無理だなと思っていたが実際にやってみたら意外とできました。

瀬良：どういう工夫をされたのでしょうか？

浅野：育てるという面で社内にScalaを浸透させて駆動していくまでにどういった道のりがあったのか教えてください。

竹添：2本立てとなります。まずは、リクルーティングは絶対に必要ですがすぐにできるようにはなりませんので、外部での発表や記事の執筆などを積極的に行いブランディングに努めました。最近ではScalaで仕事をする上での候補に入れてもらえるようにはなってきて、効果が出てきています。それと両輪で社内の育成をやっています。

基本的にその時点でスキルが不足してもScalaをやりたいと思ってくれている人にプロジェクトに参加してもらうようにしています。いくらJavaで出来る方でもScalaをやってみると詰まってしまう場合もあります。一つ目としては人を選ぶという事と、二つ目にはScalaを普通にしちゃうというのがあります。

最初は難しいと感じる事も多く、例えば「他の言語ではこんな事をしなくてもいいのに」といった話が出てくるのですが、「簡単じゃん」とか「なんでわからないの？」など普通論のレベルをあげちゃうと人はできるものだなと。また、最終的にはどこかで諦める事も必要です。必要以上にScalaらしい書き方を強要することはしません。「ここは本当はこう書くべきだと」というのはあるのですが、要件や機能を満たしていれば納期との兼ね合いを見てどこかで妥協していくという事もしています。そうやって人間的な運用をしています。

瀬良：スタンバイチームではどれくらいの人がいるんですか？

竹添：Scalaが書けるエンジニアは20人くらいはいると思います。フロントエンドとサーバーサイドを分けていて、フロントはフロントエンジニアだけで開発できるようにしています。Scalaエンジニアはバックエンドを担当し、全員がScalaを知っていないといけないという状況にしようとしていないので、それなりの人数でもやっていけています。

瀬良：それって結構大事ですよね。

浅野：できる人でやるという感じでしょうか？

瀬良：HTMLやCSSを書く人がScalaのSBTを起動しないと開発できないというのを避けないと現場が大変になってしまいますよね。

竹添：そういう仕組みで工夫できるところもあると思っています。

瀬良：ビズリーチさんのようにScalaを書けるエンジニアを10人くらい増したいなと思った時に他の会社でもやれそうなことは？（笑）

竹添：「楽しいと思ってもらえるか」ということですね。私が開催していたわけではないのですが、最初は有志で毎朝勉強会をしていました。座学で勉強というよりは、楽しくディスカッションしたり、達成感を感じる宿題を出して「できた！！」というような、心を壁に作らせない、苦手意識を持たせないというようなことができるといいのではと思います。

浅野：学ぶ時は、すぐに動いて、すぐに確認できて、すぐに効果が見える、というのがモチベーションに繋がるなと思います。取り組む時に「こういうライブラリを動かしてみよう」とか「これを使ってみよう」などテーマを持って勉強会を開催されているのでしょうか？

竹添：最初はひたすらコレクションの使い方というのをやっていて「インとアウトをこういう形にしてみよう」という問題を、GitHubですぐにダウンロードして動かせる雛形プロジェクトを作っておいて、そこでサクッとプログラミングできるような準備をして実施してました。

コレクション操作はパズルみたいなところがあるので、面白いのではないでしょうか。Futureをひたすらずーっと1週間やるというようなトレーニングもやっていたみたいです（笑）

瀬良：それは楽しいですね。（笑）

竹添：人によって面白さを感じるポイントも違うみたいです（笑）

後編へ続く...

一緒に働きたいと思える人

この記事は atWare Advent Calendar 2015 の17日目の記事です。

どうも、こんにちは。三嶋です。atWare Advent Calenderの15日目、16日目と新人のネタが続いていますが、3人目となる僕も、新人目線で今までのことを振り返りたいと思います。 なお、本記事の内容は以前に投稿した記事にを参照改変した日本語版となりますので、英語で読みたい方はそちらもどうぞ。

2015年4月にatWareに入社してから半年以上が過ぎました。私の出身は北海道の函館にある、函館高専専攻科というところです。 学生時代は主に機械工学を専攻していましたが、授業以外では主に機械学習やプログラミングなどに興味を持って勉強してました。 現在は、社外でエンタープライズ向けのWebアプリ開発のプロジェクトに参画しています。

atWareとの出会いは約2年前の夏季インターンシップに参加したことがきっかけでした。当時は、学校で習ったC言語以外のプログラミング言語には触れていなかった上にアプリ開発などの経験もありませんでしたが、学校で習った以外のプログラミングなども勉強たいという気持ちは持っていました。その時、たまたまatWareからのインターンシップ募集を見つけて、参加申し込みをしました。 函館に居た当時はIT企業というもの自体にかなり固いイメージを持っていたせいか、atWareのブログをみながら、仲良さそうに写真とってるなーとか思ったり、プログで社員の方のボケを交えた投稿など（もちろん心に響く名言を連ねた素敵な投稿もありました）を見てはどんな会社なのか、どんな人たちなのだろうかと興味深々だったのを憶えています。 インターンシップに参加した際にも、社員の方とのコミュニケーションは楽しく感じられましたし、みんなで一緒にランチを食べる機会を毎週設けたり、朝のゴミ捨て当番をダーツで決めたりと社員同士の交流を大切にしていた雰囲気にとても好感を持ちました。

学生当時に観ていたatWareブログに載っていた写真

就職活動などで会社を選ぶ際には、働く場所、勤務体制や福利厚生、会社の雰囲気など多々考慮することがあるかと思いますが、私は「人が多すぎない」ことと「そこで働いている人に共感を持てるか」ということが特に重要だと思っていました。 人が多すぎなければ、自分の会社でどんな人が働いているのかというのが見えやすくなりますし、社員同士のつながりというものがより深めやすいだろうと考えていました。atWareはすでに"アットホーム"な雰囲気を持っており、社員同士がお互いを気にかけ合うようなことを自然にやっているなと感じました。その雰囲気に自分も混じりたいと思いました。 インターンシップを受ける前は自分が将来何をして働きたいのかという部分にばかりフォーカスしていましたが、インターンシップをきっかけに、誰と働きたいのか、どういった雰囲気で働きたいのかというところが自分の中では重要な観点に変わりました。 atWareの入社試験を受けた際には自分のIT技術に対する知識や経験が不足していることは自覚していましたが、一緒に働いてみたいという思いを持って試験を受けて縁あって、現在に至るというところです。

現在では、atWareという会社の雰囲気を作っている社員の皆さんと同じ雰囲気で働けていることが楽しいと感じますし、自分を偽ることなく素直に表現できているのかなと感じています。 社外のプロジェクトで関わる人達のみならず、帰社した際には気軽に自分に声をかけてきてくれたり、色々なアドバイスをくれる人達自分がいて、入社前に思っていたような雰囲気を感じることができています。これからは、より一層自分からも積極的に声をかけたり、自分にエネルギーをあたえてくれる雰囲気を持続していけるように行動できたら良いなと思います。

私の住んでいた地域はIT企業が少なく、atWareという会社が刺激的で印象強かったのかもしれませんが、関東に出てくると又さらにいろんな企業があって、それぞれが面白い文化を持っていると思います。新しい環境からくるストレス、一人暮らし、遠距離恋愛など不安な要素は多々あるかもしれませんが、ネガティブな気持ちは取り去って一度関東に出向いてみると新しい発見があるかもしれません。様々なコミュニティーや勉強会も沢山開催されているので、そこに参加して交流を広げるなど、今後私自身も積極的にチャレンジしていきたいなと思います。 では、新しい出会いを楽しんでください！

明日は、ここ最近大活躍のあの人です!!!!

atWareでの僕の生活

Xin chào mọi người tôi là Nam, tôi đến từ Bình Dương, Việt Nam. Ngày 6 tháng 6 năm 2015, một mình tôi rời xa đất Việt để đặt chân lên đất Nhật, điều đó đồng nghĩa với việc tôi không thể gặp mặt bạn bè, gia đình, thầy cô khi tôi muốn. Làm việc trong một môi trường mới, ăn những loại thức ăn mới và tiếp xúc với những người mới đó là tương lai của tôi ít nhất là trong vài năm tới. Nhưng tôi luôn có niềm tin rằng, mọi thứ mới sẽ dần quen, mọi thử thách sẽ được vượt quá, mọi khó khăn sẽ có giải pháp. Mỗi lúc tôi gặp khó khăn tôi luôn nói với chính mình “everything will be ok”. Hơn 6 tháng ở đây, mọi thứ với mình trở nên quen thuộc. Giờ đây tôi có thể tự làm nhiều thứ, tôi đã có thể giao tiếp về công cuộc sống hằng ngày bằng tiếng Nhật với mọi người. Mỗi ngày sau mỗi giờ học tiếng Nhật tôi lại trở về nhà “Công Ty" của mình và bắt đầu một ngày làm việc.

Công ty của tôi mọi người thường hay gọi với cái tên rất gần gũi là atWare. Lúc mới qua tôi cũng không biết cái tên này có ý nghĩa gì nữa. Tôi đã nghĩ đi nghĩ lại nhiều lần thì thấy là nó vô nghĩa. Thực tế chứng minh là tôi đã sai vì nó có ý nghĩa từ lúc công ty thành lập, chuyện đó là 13 năm về trước lúc đó tôi chỉ là thằng học sinh cấp 2 chưa biết gì :D. Nói về ý nghĩa tên công ty thì nó là cả một câu chuyện dài nên mọi người có nhả hứng thì liên hệ với tôi qua gmail “lainam@atware.co.jp” tôi sẽ trò chuyện cùng bạn.

ベトナムと日本の学生がインターンシップで夏にatWareで働きました。

Nói về những người quyền lực ở atWare thì có 4 vị lãnh đạo đó là xếp: Kitano-さん, Makino-さん, Matsudate-さん, Shigeta-さん. Nhiều năm trước 4 vị gặp nhau và cùng chung một mục tiêu "Make people happy with software services". Các bạn cùng trang lứa với tôi gồm: Mas-さん, Yanouさん, Hirakuさん, Huyさん, Takenaga-さん. 4 người bạn cùng trang lứa với tôi thường xuyên nói chuyện, giúp đỡ tôi nhất có lẻ họ hiểu cái tôi muốn, cái tôi quan tâm là gì và luôn luôn sẵn sàng giúp đỡ lúc tôi cần. Những đồng nghiệp và là cấp trên đáng mến của tôi: Ishigami-さん, Shiho-さん, Satake-さん, Kuriyama-さん, Jeff-san, Araki-さん, Akagi-さん, ... Mỗi người đều có một quê hương, tính cách, công việc khác nhau nhưng đều có chung đức tính là siêng năng, chăm chỉ, tốt bụng.

Mỗi ngày sau khi kết thúc việc học tiếng Nhật ở trường thì tôi cắp sách lên công ty để làm việc. Trước khi vào công ty tôi thường tự mua cho mình một 弁当 (hình như là cơm hộp thì phải) và cùng ăn với mọi người ở trên công ty. Công ty atWare của tôi có rất nhiều phòng (giành cho nhiều mục đích khác nhau) và tôi thường chọn khu vực nhà bếp để ăn, Nguyên nhân đơn giản là vì ở nhà bếp có bánh trái, nước uống tha hồ lại có cả bảng đen, tôi thường vừa ăn vừa học nơi ấy. Ông bà thường có câu vừa ăn vừa học nuốt hết chữ, mà tôi chả quan tâm lắm đâu. Vừa ăn no, vừa nhớ được tiếng Nhật là vui mãn nguyện rồi ^^.

お弁当をMARK ISで買って食べます。安くないですけど、おいしいです。

kitchenで食べながら、日本語を勉強しています。

Sau giờ ăn thì công việc buổi chiều bắt đầu, mọi người lại tập trung vào màn hình máy tính và coding. ở công Ty tôi thì mọi người họp rất thường xuyên, Một ngày họp 2 3 lần là chuyện bình thường ở atWare, riêng bản thân tôi thấy họp nhiều rất có ích, họp nhiều giúp mọi người làm cùng dự án hiểu hơn về vấn đề đang có, đang tồn đọng, hiểu hơn về việc đang làm, sẽ làm, giúp cho công việc và giao tiếp giữa mọi người được thuận dễ dàng hơn. Đôi lúc làm việc căng thẳng tôi thường cầm máy tính đi hết chỗ ngày tới chỗ kia để thay đổi không khí (tất nhiên là ở trong công Ty), không muốn ngồi thì đứng làm việc cũng rất tốt, thỉnh thoảng tôi thích phòng cách vừa làm vừa đứng thế này, chân, tay, não đều hoạt động cùng một lúc (mỏi ơi là mỏi ~~). Gần chỗ tôi làm là một gian hàng lớn nhỏ các loại bánh, đủ chủng loại từ viên cho tới miếng loại nào cũng ngon ngang nhau. Mỗi khi đi ngang qua tôi hay bốc vài bịch nhỏ mang tới bàn làm việc để trau dồi thêm năng lượng để có sức chiến đấu tiếp. Về đồ ăn thì đó chưa phải là thứ tôi thích nhất, cái tôi thích nhất là 1 tủ lạnh kem tha hồ mà lựa chỉ với ¥100. Không khi nào nó hết kem cả, hết lại đầy lại.

この冷蔵庫にはいろいろな飲み物やアイスクリームがたさん入っています。

0円で食べられます。

    Buổi chiều tối từ văn phòng atWare nhìn ra bên ngoài rất là đẹp, bạn có thể ngắm hoàng hôn tại đây và chụp ảnh bạn thích. Từ 7h trở đi bạn có thể ra về nhưng mỗi thành viên trong đại gia đình atWare chúng tôi thường ở lại lâu hơn, không biết vì sao có lẻ do nhiều việc cũng hoặc có thể là do nét văn hoá của công Ty nhưng nó thật đáng quý làm sao.

atWareからは夕日がみえます。とてもきれいです。

    Giấc mơ của tôi sau này trở thành một kiến trúc sư phầm mềm

明日は丁寧な彼が登場します。 (本文の日本語訳は準備中です)　

2015年度、新入社員になった僕らは来年...

僕の名前は山本真平。出身は北海道。公立はこだて未来大学を今年卒業して、晴れて4月からアットウェアで働き始めた。大学のころまで「ヤマ」などと呼ばれていたが、いろいろあって関東では「マッサン」と呼ばれている。そして名乗っている。案外気に入っている。

会社でアドベントカレンダーが始まって、もう半分くらいのところまで来てしまった。最近は忘年会シーズンということもあってか幹事などの仕事が重なって、アドベントカレンダーのことなどすっかり忘れていた。なにせ僕の本業はプログラマーであり、そういったことは広報がやってくれればいいのだから。とは思いつつも弊社は広報は広報以外の業務が多すぎて機能していない。おかげで会社は回っている。みんなの協力があってこその弊社なのだ。

というか、アドベントカレンダーってなに？くらいの次元にいる僕はこの盛り上がりを上手に享受できないでいた。もともとアドベントカレンダーとは、クリスマスに乗じて発火するイベントで、クリスマスがくるまでの日々を待ちわびる子供たちのためのものである。というのは、僕の勝手な解釈であり、Wikipediaでは以下のように書かれている。

“アドベントカレンダー（Advent calendar）は、クリスマスまでの期間に日数を数えるために使用されるカレンダーである。アドベントの期間（イエス・キリストの降誕を待ち望む期間）に窓を毎日ひとつずつ開けていくカレンダーである。すべての窓を開け終わるとクリスマスを迎えたことになる。”

Photo by Jupiterimages/Polka Dot / Getty Images

写真からもわかるように、誰もがどこかで見たことがあるであろう、あれのことをいうらしい。

アドベントカレンダーの起源は、19世紀の初頭まで遡るらしい。そのころ日本にはクリスマスを祝う文化があっただろうか、僕にはわからない。

Wikipediaにも記載されているように、IT企業界隈では、毎日ブログを投稿していくイベントがいつからか流行り出したらしい。弊社も頑張ってここまで繋いでるらしい。

22歳の新卒が北海道から出てきて感じたこと、思ったことを書いてくれと広報的なきれいな人に言われたが、ここまでアドベントカレンダーのことしか書いてない。実際感じてきたことなど多すぎて、書ききれない。さらに言えばこの仕事が始まるまでの朝の数分でまとめ上げることなどできるわけがないのである。

ただこれだけは言える。早生まれの酉年で今年会社に入った、もしくは入らなかった諸君、

来年の僕たちは....

前厄だ。

思い悩む僕のもとに先輩が寄ってきてこんなことを言った。「これから、神社行くぞ」

僕「？？？」

次回のマッサンのブログは、「23歳で前厄になるのでお参りしてきた。」です。
乞うご期待。

明日は僕が会社で一番愛する彼の登場です。
つながれ僕らのアドベントカレンダー。

Rundeck でジョブスケジューリング

この記事は atWare Advent Calendar 2015 の14日目の記事です。

みなさん、こんばんは。小松です。

本日は、 Rundeck について書きます。

Rundeck とは

Rundeck はオープンソース、フリーライセンス (Apache 2.0 License) の Java 製のジョブスケジューラです。

Web GUI を備えており、機能も豊富です。プラグインによる拡張もできます。

Google Trends で見る人気の推移

うなぎのぼりです！

ちなみに Azkaban をならべてみようとしたら、ハリーポッターの力が強すぎて比較になりませんでした。。。

導入方法

ここ からダウンロードすることができます。

余談ですが、ダウンロードページを初めて開いた当時、私は左側にあまり注意が行かず、「最新バージョンは Get the Source なのか？漢らしいな！」などと勘違いをしました。

手っ取り早く試すには jar をダウンロードしてきて java -jar rundeck-launcher-2.6.2.jar で実行しましょう。

ダウンロードページには .jar or .deb で、 RHEL/CentOS はハブられてしまったのか、と少々憂鬱になりかけますが、ご安心ください。 「Previous Versions」の下にリンクされている「RPM」から「最新版」の .rpm が取得できます。

使い方

このあたりは、たくさん他のサイトの記事にありますし、ここでは省略します。 もっとも、起動さえできれば、結構直感的にジョブ追加ができるような UI です。

導入の経緯やその後

これだけではちっとも面白くないので、 Rundeck を使うことになった経緯を書きます。 お客様のシステム移行（データセンタ→AWS）案件において、旧環境では JP1/AJS 構築されていた統合監視・ジョブ管理システムのうち、ジョブ管理の部分を Rundeck で置き換えることになったためです。

移行後、約半年間動かしていますが、 Rundeck 自体は極めて安定稼働しています。 （ジョブ数は全部（日次・週次・月次）で170個程度あります）

総じて Rundeck は非常に良いです。プラグインも Groovy で簡単にかけます。

ただ、他のジョブ管理システムに劣っているところもあります。

Rundeck のいけてないところ

• ジョブネット図の機能がない
  • JP1/AJS では実行中のジョブがジョブネット図のどこにあるのかわかったのが運用上大変便利だったのですが、同じような機能は Rundeck にはありません（ただし、ジョブの中に複数ステップを記述している場合、どのステップを実行中か、はわかります）
• 異常終了ジョブ ステップからの再実行機能がない
  • これは結構泣けます。ジョブの途中のステップで異常終了してしまうと、「ジョブを複製して、成功したジョブ ステップを削除し」再実行する必要があります。複雑なジョブネットだと、「ジョブの編集が正しくできているか」にすごい神経を使います。

ただ、上記のような欠点を補ってあまりある便利な GUI が載っているので、使ったことの無い方は一度ためしてみるとよいです。 cron を置き換えるだけなら全く不足はありません。

明日（15日目）のアドベントカレンダー

明日は、少しやんちゃな若さ溢れる新人の彼です！

RaspberryPi Display

この記事は atWare Advent Calendar 2015 の13日目の記事です。

みなさん、こんにちは。矢納です。Advent Calendar 3回目の登場です。

今回は10月ぐらいに購入したRaspberry Pi 7" Touch Screen LCDについてです。

注文したら、このような箱で届きました。なかなかに大きな箱でした。この中にディスプレイとディスプレイの基盤、その基盤とディスプレイを繋ぐケーブル、基盤とRaspberryPiを繋ぐケーブルが入っています。写真は撮り忘れてしまいました、すみません(^^;
またこの中にはスタンドが入っていなので、スタンドを自作するか購入する必要があります。今回はそれも購入しました。配達物の品目がアクリル板になって届きました。スタンドは複数のアクリル板を組み合わせて完成です。

私は少し変わったスタンドを買ってしまいましたが、今はamazonに違うスタンドも売っているのでそちらのほうがいいかと思います。

さて、ディスプレイとRaspberryPiを接続したら起動です。最新のRaspbianにしていると自動でGUIモードで起動するようになっていますので、わざわざ startx のコマンドを入力する必要がありません。接触が悪いと起動しない・再起動を繰り返す等の動きをすると思いますので、その際はケーブルを繋ぎ直してみてください。

アプリケーション開発

RspberryPiにディスプレイがついたのでGUIアプリを作ろうと思います。今回は社内の会議室の状況確認・その場で予約ができるものを作っていきたいと思います。社内の会議室の予約はGoogle Calendarを使っているのでGoogle Calendar APIを使って予約状況を取得します。RaspberryPiからGoogle Calendar APIの呼び方はこちらのブログを見て下さい。

会議室の予約状況取得は問題ありません。GUIアプリ開発に問題があるのです。私はRaspberryPiを使って開発をする際はPythonを使うことにしています。ですが、今までPythonを使ってGUIアプリを作った時はありません。まず、作れるのかもどうか知りませんでした。 調べたらありました。というかRaspberryPiの公式でおすすめしてました。

Kivy

これはクロスプラットフォーム開発できるGUIのライブラリですね。今回はこれを使います、

Kivyインストール

こちらにインストール手順がありますので、参照して下さい。
基本的にはこちらの手順通りでOKです。そして、これだけは忘れないで下さい。
この設定を入れないとタッチが反応しません。表示はできます。私はこれに2週間ぐらい悩みました。

おわりに

これでタッチを対応したのでアプリ作りです。Kivyはドキュメントを豊富なのでつまずいてもなとかできると思います。最後に開発途中の画面を見せて終わりです。
明日は「ジョブのスケジュールは任せておけ！」の彼です。

Email: yanou at atware.co.jp

失敗するということ

失敗するということはカッコ悪い。と思っていた。 失敗したら不都合なことが起こる。と子供の頃からずっとそう思っていた。

でも、２年半前、テネシー州ナッシュビルで開催されたAgile国際会議 Agile2013で Linda Risingに久しぶりに会った時に、「失敗していい。失敗は学ぶこと。失敗を恐れていては何もできない。失敗を早くたくさんすることで、道が開く」と教えてもらった。衝撃が走った。失敗していいんだと。

彼女のAgile2011での講演がYoutubeにある。講演題名はThe Power of an Agile Mindset.

彼女の言葉には力がある。比較的細い線の体から出ているとは思わないパワーがある。言っていることに説得力もあり、かつ情熱もある。彼女のようなMindsetを持ちあわせ、人々の話に耳を傾けられる人になりたいと思った。

そして、いままで挑戦していなかったこともいろいろやろうと誓った。 ベトナム、英語、サービス開発。 新しい世界や価値観を受け入れ、自分の信じる方向に強く向かっていく。 同時にたくさんのことをすることができない。が、ひとつひとつ力を注いでやれば、少しずつではあるができることがわかってきた。

そして今年の12月からアットウェアとして第１２期が始まった。新たな期。新たなチャレンジ。 数年前のAdventCalendarで書いたアットウェアの未来を創るべく、失敗を恐れず、諦めず、泥臭く、アクションしていきます！

みなさんおつきあいください。 ご静聴ありがとうございました。

atware 2-day hackathon in Vietnam 2015

Xin chào mọi người

Hello everyone, I'm Huy. This is blog is for atWare Advent calendar 2015, 10th day.

This January (2015) is the first time we held a hackathon at Ho Chi Minh University of technology in Vietnam. More than 20 team registered, over 50 students joined the event. It's quite a great experience that we have ever had. And I want to share those experience with you through this blog.

Prepare for the event

I'm the only Vietnamese in the company at that time so I helped contacting with the university in Vietnam to hold the event. It's kind of exciting to be able to come back to school. Took some time to contact with the university, negotiate about the facility and PR for the event but we did it.

One day before the event, we arrived to Ho Chi Minh city in early morning, headed to school and prepared facility for the event. Mr.Duy, a teacher at the university and also takes responsible for faculty facility, met us at the university and showed us the room for the Hackathon again. They're computer labs for students and capable of 100 students, ready for the event!

Hackathon first day

Around 8 a.m, all teams gathered in one room. Kitano-san (my boss) announced the theme for the Hackathon. The theme is "smile". The theme idea is based on the company mission that atWare has always been making customers and users since established.

After announcing the hackathon, students could freely implement their application. Most team stayed at the labs to developing. Some teams moved to their own "lab" to implement their IoT product.

We had great chance to walk around, talk with students and see how they are working. There were up to about 15 teams in the labs so it was quite crowded. Everyone were discussing, drawing, coding...

One corner of the labs

First day passed by quite fast. We were only able to stay in the lab to 5 p.m. After that, some teams kept on working until midnight in convenient store or their own house.

Hackathon second day

Teams were rushing to finish their application. Many team skipped the lunch because they wanted to spend more time on developing. However, few teams finished and went around, helped other team. We also made a tour and let students "pitch" about their idea. It's the greatest chance for student talk about their idea and we could ask them more about their product because each team only have less than 10 minutes to present in the afternoon.

Student pitched their idea

In the afternoon, after all teams presented their work, we had party in a nearby restaurant. Teams are allowed to vote to others. we, judgers, have higher weight in the judgement, but look like the winner was quite clear. It's an IoT product, named Rito (implied "Very good" in Vietnamese, credited by creator). Rito is a smart pillow with emotion. Whenever you hold it tight enough, it will smile. If you stop holding it for a while, it’ll be sad. 

It’s a great experience. I hoped that the hackathon could somehow inspired student making something that makes people happy, like our company's mission for 11 years "Make people happy by system".

Tạm biệt. Goodbye. みなさん、さようなら。

北海道から横浜に移住して良かったこと・困ったこと

みなさんこんにちは。北海道出身のエンジニア 不破です。

今回は、「地方に住んでいるけど、関東でお仕事してみたい！」という人向けに書いています。

2年前まで北海道にいました。

私は生まれも育ちも北海道(ほとんどを函館で生活し、札幌で就職)です。ちょうど2年前までは北海道札幌市で仕事をしていました。(ちなみに今と同じくWebアプリケーション(+インフラ構築担当)エンジニアでした)

そこから数ヶ月後、「内地でも仕事してみたい！」という思いから横浜に移住してアットウェアに入社しました。

※「内地」(ないち)とは、関東のことを指しています。北海道の人はこの言葉を使うことが多いようです。私も使っています。

今回のAdvent Calendarは、内地に引っ越してきて困った事などなどを書いてみようと思います。

よかった事

まず良かったことから書いていきます。

勉強会・イベントがとにかく多い

札幌でもIT系の勉強会は結構開催されているのですが、東京での開催数には遠く及びません。 connpassで見ても東京開催のイベントが圧倒的に多いです。 実際、横浜に引っ越してきてから勉強会への参加数が増えた気がします。

Amazonの荷物がその日に届く

横浜に引っ越してきて驚きました。「注文したその日に荷物が来るなんて！」と・・・

北海道の場合、「お急ぎ便」で注文しても届くまで中1日ぐらいかかります。「当日お届け便」は完全にエリア外ですし、最近始まったAmazon Prime Nowもありません。

なので「翌日に届く」というのはカルチャーショックでした。というか、1時間で届くってのもなかなかすごいですね・・・

ちなみに、北海道(地域にもよりますが)では雑誌など出版物も発売日から数日遅れて書店やコンビニに並びます。更に冬になると悪天候などで更に遅れます。

その他、

• 日帰りでコミケに行ける
• 気軽に秋葉原まで電子部品を買いに行ける

などなど色々あります。

困ったこと

家賃が高い

とにかく家賃が高いです。札幌では1Kのアパートに住んでいたのですが、その時の家賃は3万円でした。しかも地下鉄駅(南北線麻生駅)から徒歩10分以内で大通やすすきのへ行きやすい立地でした。

そして横浜へ引っ越してきたのですが、家賃が2倍の6万円になりました! さらにワンルームになったので部屋の広さも半分になりました！

引っ越した直後は敷金の支払いもあったので、一時期家計が大変なことになりました。

住民税が高い

札幌市に納めていた住民税と比較すると、横浜市の住民税が2倍ぐらいになりました。(年収が上がったというのもありますが・・・)

その他物価が高い

北海道にはセイコーマートというコンビニチェーンがあるのですが、ここだとやきそば等お惣菜1パックを80円ぐらいという驚きの価格で買えます。勿論横浜にはそんなのありません。

また、札幌で仕事中にお昼を食べに行くと大体500円ぐらいで定食が食べられるのですが、横浜になると1000円を余裕で超えます。 外食ばかりだと家計が圧迫されるので、自炊する回数が増えた気がします。

ちなみに札幌では1000円出すと寿司が食えます。

500円出せば、これぐらいの大きさの親子丼が出てきます。

意外と交通機関が貧弱だった

東京・横浜にはJR/東急東横線/みなとみらい線/市営地下鉄などなど交通機関があり、充実しているように見えます。 ただ、どこかで人身事故が起こると玉突き式に他の路線が遅れ出すなど、意外と貧弱だと感じました。

また北海道ではありえない事なのですが、東京で雪が降ると各線で運休まで出るというのには驚きました。

ちなみに北海道におけるJRの遅延・運休理由で多いのは

• 大雪(それに関連するドア故障など)
• 大雨
• 鹿など動物をはねてしまう

だと思います。その他、車両火災も多い気がします。

・・・いかがでしょうか！まだまだ書きたいことは沢山あるのですが、これぐらいにしておきます。

まとめると、

• 東京は勉強会がとにかく多くて楽しい
• Amazon生活が捗る
• ただし物価も家賃も高くなる。
• たまには北海道に帰りたい！おいしいお寿司食べたい！

となります。要するに、土地それぞれにメリット・デメリットがあるということです。 自分の生活スタイルや自分自身のこだわりとあわせて考えてみるのはどうでしょうか。

それでは！

マフラー

この記事は atWare Advent Calendar 2015 の8日目の記事です。

「仕事仲間にはすごく恵まれている」

仕事を初めて一番かな。

いままでに、いろんな仕事のやり方をいろんな人々から教えられた。

そして今年、意見を通してくれる機会が多く与えられた。

感謝。

この感謝を言葉で伝えるのは簡単だか、それは俺の流儀ではない。

「仕事でベストを尽くす」

それぞれ違う仕事を行い、関係性がそれぞれ違う。

仕事でどれだけ全力を出せたかを、客観的に見てもらうしかない。

今年は、今の自分のベストを伝えられたんじゃないかと思っています。

自分が関わる仕事を、今まで以上に仲間たちに楽しんで取り組んでもらう。

そのために、一層、”認められる人”を目指します。

というわけで、まじめにタイトルとはまったく関係なくなってしまいましたが、荒木でした。

次はなんとあのエンジニアの登場です。お楽しみに！！

第12期に向けて

このエントリは atWare Advent Calendar 2015 の第7日目です。

前回に続き、今日は第12期に向けての取り組みとして、事業方針の一部を紹介します。 当社のミッションは「システムで人々をしあわせにする」。今期もこのミッションを達成すべく、ここ数年の事業方針を踏襲した事業の推進と企業としての成長を図っていきます。

当社はこれまでSI／受託システム開発を請け負うことを主な生業とし、顧客である企業を通じて社会の人々に対してしあわせを届けて参りました。特に昨今は、システムが顧客企業の業務効率化を図る、つまりは企業のビジネスを支援するものから、システム自体がビジネスを駆動する、単なる便利なツールから企業のビジネスそのものであることが多くなってきました。システムを利用する人も一般のコンシューマーであり、利用する環境も多様化しています。当然ながら要求は多岐に渡り、また変化のスピードも速く、システムを開発あるいは保守する我々も顧客のシステム部門から言われたことをやっているだけでは、十分な満足を得ることはできません。顧客のビジネスそのものを理解し、その先にいる利用者に我々自身がしあわせを届けるんだという立場で顧客と共に働く、「恊働」をより強力に社内に浸透していきます。具体的には、従来から取り組んできたスクラムなどのアジャイル開発プロセスと保守と開発が一体となって取り組むDevOpsを融合したアットウェアメソッドを確立します。その上で社内で取り組む全てのSI/受託開発プロジェクトをこれに則って推進し、顧客企業との協働、さらにはより多くの利用者にしあわせを届けて参ります。

一方、ここ数年、取り組んできたTypesafe社とのシステム開発パートナーを中心としたReact SystemおよびNoSQLデータベースCouchbaseなどの大規模並列分散／並行データ処理技術に対しても、体制を強化すると共に社内外のナレッジも整備して、より高い価値、これまで経験したことのないしあわせを提供できるようにして参ります。具体的な取り組みも近いうちにお知らせできるものと思います。

また、当社がより多くの利用者に直接しあわせを届けるための施策も強化して参ります。こちらも近いうちにお知らせできるものと思います。

これらの事業をより強力にスピーディーに実行できるよう、社内の組織編成を大幅に改革しました。まだ試行錯誤で取り組んでいる段階ですので、いずれ整備が進み、成果が出てきたころにあらためてご紹介できればと思います。

毎年、中長期の方針とこれまでの反省を踏まえて、期首に事業計画を立てていますが、ここ数年それが十分には達成できないでおり、、経営者としての責任を痛感しています。 この一年は、これまで以上の覚悟を持って取り組んでいきます。社員の皆やパートナーさん、さらにはお客様と共に、より多くの人に、より価値の高いしあわせを届けていけるよう、精一杯努力していきます。

下呂温泉旅行

この記事は atWare Advent Calendar 2015 の6日目の記事です。

みなさん、こんにちは。矢納です。Advent Calendar 2回目の登場です。

今回は社員同士の交流について、紹介していきたいと思います。
今回、ランチや飲み会等のありきたりな紹介ではなく、11/28, 29に下呂温泉までのぷち旅行の様子を紹介したいと思います。

なぜ下呂温泉？？

目的無しで旅行に行くのは個人的にはないと思ってます。今回の目的は「紅葉を見に行こう」です。会社に外国籍の方がいて、彼らが「紅葉見に行きましょう！」と行ってきたのが始まりです。それから社員に声をかけて、人集め、行く場所を決めるのですが、これが大変！
参加者の1人が「温泉は必須だよね！？」と言うのです。さらに温泉はそれなりの質を求めてきます。紅葉と温泉が堪能できるところ。色々探しましたが良いところが見つからず困ってました。
ある時、ふと「下呂温泉」がひらめきました。流石に紅葉の時期じゃないだろうと思いましたが、紅葉の時期でした。半分冗談で言ったらそこに決定しました。
これで下呂温泉に行くことが決定しました。

計画

行く場所が決定したら、今度は行動計画を立てます。こういうのを作るのはとても楽しいので夢中になって作ってしまいますね。スライドで計画を作り、概算の予算を算出し、他のメンバーの同意を得ていく。面白いですね！！
ですが、計画を立ててる時に「計画通りに進む旅行なんてないけどなぁ」と思ってました(^^;

出発

計画も立てたし、宿も予約したし、これでOKですね。では出発しましょう！

今回は車での移動です。横浜から下呂温泉まで約370kmらしいです。推定5時間。レンタカーを借りて、朝8時に横浜を出発です。まずは東京メンバーを迎えに八王子まで下道で行き、その後高速になりました。休憩に使ったSAは談合坂、双葉、諏訪、神坂(PA)でした。

談合坂SAはEXPASAになっています。EXPASEとは“なんぞや”と思う方はとても大きなSAと思って下さい。ここで朝食？昼食？を食べました(英語だとbrunchです)。

双葉SAは富士山をきれいに見れるSAとして有名なところです。写真では伝えれませんが、なかなかにきれいに富士山を見ることができます。

諏訪SAには知っている人は知っている、温泉があります。私は知りませんでしたけどね(^^; ここは温泉もそうですが、諏訪湖が一望できるのでかなりいところですね。

もう一度休憩をはさみ、その後下呂に直行です。下呂についたころには17時になってました。

下呂温泉

17時についたので外は少し暗くなっていました。車を駐車場に止め、観光です。

最初は下呂温泉神社に行きました。神社と言っていますが、そんなすごいものではありませんでした(笑)。ちょっとした祠があるだけでした。

次に行ったのは、さるぼぼ神社です。ここはそれなりに有名らしくたくさん人がいましたが、神社にしてはかなり小さめかと思いますね。さるぼぼは写真に写っているものです。赤い体をしており、顔が無いですね。

その後、少し街を探索してホテルではない温泉に向かいました。巌立峡ひめしゃがの湯です。ここは炭酸温泉で有名です。この炭酸温泉は飲むこともできるし、料理にもつけます。なのでペットボトルに入れて持ち帰ることも可能です。また、化粧水の代わりにもなるとのことです。私は持ち帰っておりません。荷物になるので(笑)

夕食はこの温泉と一緒になっているレストランで食べました。私は飛騨牛の料理を食べました。写真は後ほど。

その後、ホテルに戻り、温泉に入って就寝です。一緒に行った人たちは疲れて寝てしまいました。せっかくトランプとUNOを持っていったのに......

二日目は合掌村に行きました。ここには少しばかりの紅葉がありました。そうです！ここでやっと紅葉が出てきました。ですが、少しだったのでこれは紅葉旅行ではなく温泉旅行だなと思いましたね。ここは古い民家、足湯等があってとても面白かったです。足湯は下呂にはたくさんあるのですがね(^^;

お昼はまたもや飛騨牛料理です。ひつまぶしのうなぎを飛騨牛にしたものです。とても美味しいので皆さん食べに行ってみてください。お店はせん田です。

View fullsize

View fullsize

おわりに

色々と楽しんだ後は帰るだけです。帰りのほうがやはり体力的にも精神的にはキツイですね。渋滞に2回。小仏トンネルと海老名なのでいつもなのですが......。他にも圏央道はとても走りやすかったりしてよかった部分もあります。

最後にみんなでの集合写真です。

View fullsize

View fullsize

View fullsize

View fullsize

いかがだったでしょうか。たまにこのようなこともやって、社員同士の交流等を深めています。
さて、明日は最近何かやりたくてたまらない方の登場です。

Email: yanou at atware.co.jp

GEEKSCHOOLって？

こんにちは。 栗山です。 アットウェアに入社し、これまで色々な業務を担当させていただいておりますが、 今期からは広報・採用と、外への働きがメインとなる業務も行うこととなりました。

そこで、atWare Advent Calendar 2015 の5日目の今日は、広報担当のわたしから、 GEEKSCHOOLの紹介です。

では、さっそくですが、GEEKSCHOOLを紹介していきます。

GEEKSCHOOLとは？

私共、株式会社アットウェアと株式会社永和システムマネジメントさん、ウルシステムズ株式会社さんと力を合わせ運営している学生を対象とした勉強会です。 この勉強会や各種イベントでは、わたしたちの知識・技術・経験から、自分の道を既に決定している学生はもちろん、進路を決めかねている学生の方々に目には見えないプレゼントを届けています。

GEEKSCHOOLの対象は？

IT業界／進路に関連することで悩んだり困ったりしている学生のみなさんを対象としています。

• 就職したら即戦力として働けるようになりたい。その為に、どういう勉強をしたらいいかを知りたい
• 実際の現場ではどんな技術が使われているのか知りたい
• 授業にはない技術を学びたい
• IT系の授業は受けていないが、ITの技術を学びたい
• 就職活動をする前に、IT業界がどんなところなのかを理解したい
• ITエンジニアで働く人と仲良くなりたい
• IT業界に興味を持っている学生の友達を作りたい
• インターンシップに行く時間はないけど、IT業界のことを知りたい
• SEとかPGとかって、実際は何をするのか知りたい

GEEKSCHOOLのウリ

• 参加費が無料
• 講師はすべて現役のエンジニア
• オンラインで講師に質問ができる
• 懇親会やハッカソンなどのイベントで受講生
• 講師とコミュニケーションがとれる
• 様々なプレゼント
• などなど

GEEKSCHOOLの歴史

第1期

• 2015/04/25 オープン記念イベント
• 2015/05/01 第1期説明会&RaspberryPIミニハンズオン
• 2015/05/08 第1期説明会&RaspberryPIミニハンズオン
• 2015/05/14 第1期(Vol1) JavaによるWeb開発の最前線
• 2015/05/30 第1期(Vol2) SQL 〜情報技術社会に一番無くてはならない大事な技術〜
• 2015/06/11 第1期(Vol3) TDD & Pull Request ～動作するきれいなコードを目指そう～
• 2015/06/27 第1期(Vol4) Javascript, React.jsを使ったWebページ開発のハンズオン
• 2015/07/08 第1期(Vol5) アジャイル開発 ～チーム運営プロセスをゲームで学ぶ～
• 2015/07/17 第1期(Vol6) システム開発の要。要件定義そのテクニック
• 2015/08/08 サマーハッカソン
• 2015/09/12 IchigoJamを組み立ててBASICを触れてみよう!

第2期

2016/1、2月開校予定

これから社会にでる方々の「これから」に少しでもお力になれるよう、講義内容を日々検討しています。 リクエストがある方は、ぜひ、ご連絡ください。

GEEKSCHOOLスタッフ一同、学生のみなさんにお会いできることを楽しみにしています。

では、明日の6日目は、凛々しい顔が板についてきた、若手の彼が再登場します！！

社員合宿2015

4日目ですね。リーダーを卒業し、雨の中でも毎朝走っているアラフォーの荒木です。

風邪気味で体調も悪い最近ですが（そりゃそうだ）、

さて、今年の9月に全社員が集まって2日間合宿を実施いたしました。

全社員が集まって話し合うのは何年ぶりでしょうか？

準備

準備は2ヶ月前から!!

目的、内容、会場プラン、ご飯の準備、インビテーションカード作成、会場設営などなど、

みんなで仲良く準備を行いました。

ご飯の用意楽しかったですね。

今回はワールドカフェで行いました。

ワールドカフェは、カフェのようなリラックスした雰囲気で対話を行う手法ですね。

まずは、やり方の説明。相手の話をよく聞き、相手の意見を否定せず、意見を受け入れ、深い洞察を行い、アイデアを掛けあわせ、楽しく会話を行うこと！

模造紙に気になったことを書き込んでね。絵でもいいよ！！

んっと、普段行わない感じなので、違和感ありますね。

今回は1ラウンド30分を5ラウンドを予定。途中でカフェタイムをいれて、楽しくすすめるように企画しました。

1ラウンド目スタート

ぎこちない感じで1ラウンド目！！

2ラウンド目スタート

こんな感じ？とおもいつつ、2ラウンド目！！

カフェタイム

美味しいミスド

3ラウンド目スタート

随分なれてきた3ラウンド目！！

和菓子タイム

美味しい団子

4ラウンド目スタート

なかなか終わらなかった4ラウンド！！

アイスを食べて、瞑想

うまいーーーー

5ラウンド目スタート

最後は落ち着いて。最終ラウンド！！

最後に

いろんなかたが、いろんな思いで来たとは思いますが、 主体的に望んでくれたことが一番よかったですね。

というわけで、

次はキュートなあの方です。お楽しみに！！

君はどのエディタ・IDEを使っている？

この記事は atWare Advent Calendar 2015 の3日目の記事です。

みなさん、こんにちは。矢納です。
昨日のブログから

明日はYanouさんによる「IntelliJについて」です。というのを期待したいと思います！えっ！？

と来ましたので、今回は開発するには欠かせないエディタ・IDEについて少しおしゃべりしたいと思います。

Integrated Development Environment

さて、みなさんはどのIDEをよく使っていますでしょうか？

• Eclipse
• Visual Studio
• IntelliJ
• NetBeans
• Android Studio

などなど。たくさんありますね。Wikipediaにもたくさん書いてありますね。

以前、私はEclipseをよく使っていましたが、あるプロジェクトを境にIntelliJを使い始め、今や開発は全てそれを使って行うほどです。

最初はキーマップやプロジェクトの開き方、細かな設定等のやり方がわからず苦戦しました。その様子を見ている周りからも「IntelliJって何が嬉しいの？」などとよく言われました。と、いうことで個人的な意見を言わせてもらいます。

プラグイン導入が簡単

プラグインが対応しているファイルを開くと自動的に上図のようなレコメンドをしてきます。あとはInstall pluginsを押して、再起動でインストール完了です。
最初からプラグインを検索せずともファイルを開くだけでプラグインがインストールできます。

初期プラグインが色々と

IntelliJをインストールした時点で様々なプラグインがインストールされています。Eclipseだとm2eやandroid等は自分でインストールする必要がありますが、IntelliJの場合だとそれらがある程度最初に準備が整っています。これは楽ちんですね。

その他細かいところ

IntelliJからターミナルを開くことができ、その場でコマンドを実行できます。これで別にターミナル用にウィンドウを開く必要がありません。

他にも「いいな」と思うことはありますが、基本的には他のIDEでもできますので、省略です。

ちょっと?残念なところ

IntelliJにはcomminity版とultimate版が存在しています。

「大した差なんてないでしょε-(￣ヘ￣)┌」と思ったあなた！！

残念！それなりにあります笑。

• 使えるプラグインの数がかなり減ります。
• 補完機能がなくなる言語も出てきます。

これら２つだけでかなり開発がやりにくくなります。ultimateはそれなりのお値段ですので色々と悩んでから買って下さい。あっ、個人的にはIntelliJ押しです。

エディタ

エディタは正直なんでもいいと思いますね。私は開発は全てIntelliJなのでエディタは単なるメモにしか使っていないので、特に書くことは無いですね。

さいごに

エディタ・IDEの話をしようと思いましたが、結局IntelliJの話をしてしまいました。皆さん、使い慣れた開発のし易いIDE・エディタを使って下さい。他に乗り換えるときは3ヶ月ぐらいかかると思っていれば、どのIDEでも使いこなせますよ！！

明日はどんなときにでも頼りになる男の出番です。

Email: yanou at atware.co.jp

Vimで学ぶ「適切な速度」で処理をするということについて

Vimで学ぶ「適切な速度」で処理をするということについて

この記事は atWare Advent Calendar 2015 の2日目の記事です。

昨年はボードゲームでリアルなコミュニケーションというタイトルでモノポリーについて記事を書きましたが、今年はモノポリーかVimのどちらの記事を書くか苦渋の末に迷ってVimをお題にしたので、イメージだけはモノポリーにしてみました。

今日書くエントリーは適切な速度で処理をするということをVimをとおして学んでみたいと思います。

Vimとは

一般的にVi互換で機能拡張が入ったエディタという事でプログラマやサーバー管理者などに普及しています。 弊社内の統計値によると72%の社員が今年になってこのエディタを使った事があるそうです。

このエディタの特徴として起動が速い事で一般的に知られています。もう少し突っ込んだ話しをするとVimというよりViが軽くてどこのサーバーにでもインストールされているということでしょうか。

さらにいうと、一般的なLinuxOSですとviコマンドがVimコマンドのvi compatibleモードのエイリアスとなっている事はわりと弊社社内をはじめVimを使った事ある人には知れ渡ってきていることですね。

さて、viコマンドの起動はなぜ速いのでしょうか？理由は結構わかりやすく、C言語で書かれてていることに加え、数十年速度や機能改善をされ続けた成熟したプログラムというのに加え、もう一つ大きな理由として余分な機能を読みこまず、起動しているという事です。

Vimの魅力としてカスタマイズできることにあります。VimはVim scriptというVim専用のスクリプト言語で機能拡張を行う事ができるのですが、デフォルトのVimではいくつかのデフォルトプラグインを読み込み起動しています。

ディストリビューションやカスタマイズビルド（例えばMacVimやKaoriyaパッチVimなど）版のVimによって違いはありますが、例えば

$ ls /usr/share/vim/vim73/plugin/
README.txt           netrwPlugin.vim      tohtml.vim
getscriptPlugin.vim  rrhelper.vim         vimballPlugin.vim
gzip.vim             spellfile.vim        zipPlugin.vim
matchparen.vim       tarPlugin.vim

私の環境のVimにはこんなプラグインがインストールされていました。 gzip.vimはvimでzipファイルを開いた時に展開せずにVimでアーカイブ内のファイルを閲覧・編集できるというプラグインです。viコマンドではこのcompatibleモードで起動するのでこのプラグインは読み込まれませんが、vimコマンドで起動すれば読み込まれてから起動します。

こういうデフォルトプラグイン数個なら体感的に差はありませんが、便利なプラグインがGitHubやvim.orgで公開されており、自分のスタイルに合った便利な機能を追加しようとプラグインをどんどん増やしていくと体感できるほどに遅くなる事があります。これは、Vimに限った事ではなく他のエディタでもよくあることですね。

ただ遅いだけではない

いよいよ本題に入っていきます。みなさんパフォーマンスチューニングの時に測定していますか？ 今の時代なら感覚に頼らずメトリクスや速度測定をして数値に基づいてチューニングしていくのが一般的ですよね。

一般的な手法を用いて遅さを実感してみたいと思います。

VimはC言語で書かれてコンパイルされて実行されていますが、機能拡張は基本的にはVim sciprtという言語で動的に実されます。

まずは、Vimをプラグイン読み込みせず、compatibleモードかつvimの設定ファイルも読み込まずに起動速度を測定できるオプションもつけて起動してみましょう。

$vim -u NONE --noplugin --startuptime vim-startup.log

そうするとこんな結果になりました。

$cat vim-startup.log


times in msec
 clock   self+sourced   self:  sourced script
 clock   elapsed:              other lines

000.010  000.010: --- VIM STARTING ---
000.093  000.083: Allocated generic buffers
000.106  000.013: GUI prepared
000.494  000.388: locale set
000.500  000.006: clipboard setup
000.507  000.007: window checked
001.124  000.617: inits 1
001.137  000.013: parsing arguments
001.523  000.386: expanding arguments
005.239  003.716: shell init
005.492  000.253: Termcap init
005.535  000.043: inits 2
007.877  002.342: init highlight
007.880  000.003: sourcing vimrc file(s)
007.890  000.010: inits 3
007.910  000.020: setting raw mode
007.928  000.018: start termcap
007.950  000.022: clearing screen
008.044  000.094: opening buffers
008.047  000.003: BufEnter autocommands
008.051  000.004: editing files in windows
008.073  000.022: VimEnter autocommands
008.080  000.007: before starting main loop
008.681  000.601: first screen update
008.684  000.003: --- VIM STARTED ---

8msで起動できました。

VimScriptを読み込んで起動

こんな簡単な再帰呼び出しを行うシンプルなVim scriptを書きました。

$cat recursive.vim

"set maxfuncdepth=100
function! s:Recursive(count)
    "echo a:count
    if a:count > 1
        call s:Recursive(a:count - 1)
    endif
endfunction

call s:Recursive(1)

先ほどと同じ容量でVim scriptを読み込んで起動してみます。

$vim -S recursive.vim -u NONE --noplugin --startuptime vim-startup.log

結果を表示してみましょう。

$cat vim-startup.log

times in msec
 clock   self+sourced   self:  sourced script
 clock   elapsed:              other lines

000.006  000.006: --- VIM STARTING ---
000.077  000.071: Allocated generic buffers
000.088  000.011: GUI prepared
000.416  000.328: locale set
000.421  000.005: clipboard setup
000.427  000.006: window checked
001.019  000.592: inits 1
001.034  000.015: parsing arguments
001.421  000.387: expanding arguments
005.263  003.842: shell init
005.522  000.259: Termcap init
005.567  000.045: inits 2
007.934  002.367: init highlight
007.937  000.003: sourcing vimrc file(s)
007.947  000.010: inits 3
007.968  000.021: setting raw mode
007.985  000.017: start termcap
008.007  000.022: clearing screen
008.100  000.093: opening buffers
008.103  000.003: BufEnter autocommands
008.107  000.004: editing files in windows
008.332  000.080  000.080: sourcing recursive.vim
008.345  000.158: executing command arguments
008.346  000.001: VimEnter autocommands
008.351  000.005: before starting main loop
009.246  000.895: first screen update
009.248  000.002: --- VIM STARTED ---

なっ、なんと先ほど8msだった起動速度が9msになってしまいました。 1msも起動速度が遅くなってしまったらこれは非常に困ってしまいますね。 生産性が悪くなって仕方なくなるかもしれません。少し大げさでした...

Vim scriptの関数呼び出しを増やしてみる

先ほどは関数呼び出し1回だけだったものを100回の再帰呼び出しに変えてみます。 関数内では処理はないに等しいのでほぼ関数呼び出しだけのコストになります。

結果は下記の通り。

times in msec
 clock   self+sourced   self:  sourced script
 clock   elapsed:              other lines

000.008  000.008: --- VIM STARTING ---
000.090  000.082: Allocated generic buffers
000.103  000.013: GUI prepared
000.498  000.395: locale set
000.504  000.006: clipboard setup
000.511  000.007: window checked
001.193  000.682: inits 1
001.212  000.019: parsing arguments
001.740  000.528: expanding arguments
005.770  004.030: shell init
006.042  000.272: Termcap init
006.088  000.046: inits 2
008.466  002.378: init highlight
008.469  000.003: sourcing vimrc file(s)
008.479  000.010: inits 3
008.500  000.021: setting raw mode
008.518  000.018: start termcap
008.545  000.027: clearing screen
008.642  000.097: opening buffers
008.646  000.004: BufEnter autocommands
008.650  000.004: editing files in windows
010.080  001.279  001.279: sourcing recursive.vim
010.098  000.169: executing command arguments
010.100  000.002: VimEnter autocommands
010.105  000.005: before starting main loop
010.635  000.530: first screen update
010.638  000.003: --- VIM STARTED ---

先ほどは、9msで終わったところが10ms後半になってしまいました。 着目したいところがあるのでピックアップしてみたいと思います。

008.332  000.080  000.080: sourcing recursive.vim
010.080  001.279  001.279: sourcing recursive.vim

1回の関数呼び出しの際に80µsecだったところが、15倍ほど時間がかかっていますね。 関数呼び出し1つで数十µsecは遅いと感じましたか？速いと感じましたか？

あなたの普段使っている言語。例えばJavaやPythonやRubyやGoではどれくらいのコストでしょうか？ 非機能要件でシステムのレスポンス要求のオーダーはどれくらいに設定していますか？

秒単位の事もあれば、msec単位のこともあります。これがレイテンシも含め数十msecで処理したいシステムなら致命的な程遅いのです。また、チリも積もればなんとやらでプラグインの用途によってはUIが体感的に遅いと感じてしまう事もあります。

そういう時にどういうアプローチがとれるでしょうか？

アプローチ

一般的なWebアプリと同じような発想のアプローチをとることができます。

Rubyでも速度を担保したい場合にnativeにコンパイルしたモジュールを部分的に利用することがありますね。同じようにVimからもネイティブなモジュールを呼び出す事ができます。 他にもVimではPythonやLuaのインターフェースを使うということもできますので、Vim script以外の言語を利用するというアプローチもありですね。

アプリケーションを丸ごと置き換えるのではなく部分最適というものです。

「適切な速度」で処理をするということについて

とは言ったものの、富豪的にリソースを扱える時代でもシビアにならないといけない時とそうでない時の差はやはり存在します。

Vimを例に出しましたが何ごとも適材適所で、実装でひたすらがんばるというのもやり方の一つですし、部分的なネイティブで部分的に最適化もいいでしょう。また、MessagePackやZeroMQのようものを使い、プロトコルを決めてロスを最小限にし効率良く処理するという、分割して粗結合にする方法もありかもしれません。

適切な速度を言語レベルで担保しようとするのか、システム全体で担保しようとするのか、それだけでも視点は違ってきます。

大きな視点で考えた場合には影響範囲は留まる所をしれませんね！！ 非機能要件で必要な速度を担保しつつ、クラウドリソースを活用したうえでアーキテクチャ次第で色んなアプローチがとれるので、そこを考えていくのは本当に面白いです。

まとめ

本記事は@kamichiduさんの発表にインスパイアを受け書きました。 興味深い面白い発表してくださりそして発表後の小話にもつきあって頂きました。この場を借りて感謝の言葉をお伝えしたいです。ありがとうございます。

自分なりに普段の業務を通じて感じていた所がVimを通してあらためて気づけたというのは非常に面白かったです。なお、このエントリーはVim Advent Calendar 2015を兼ねません。

明日はYanouさんによる「IntelliJについて」です。というのを期待したいと思います！えっ！？