ScalaMatsuri 2016をスポンサードしました

先日、東京国際交流館で開催されたScalaをテーマにした日本最大級のカンファレンスScalaMatsuri 2016を侍スポンサーとしてスポンサードさせて頂きました。

ScalaMatsuriのクオリティは素晴らしく、様々な参加者層それぞれが楽しめたのではないでしょうか。

関数型プログラミング・Reactive Streamsなどの話題が多く、セッションのバラエティも富んでいました。参加したセッションによっては過去に聞いた事があった話も含まれていましたが、現状に合わせたブラッシュアップがされていたり、再度理解を深めたり・これから考えていかないといけない事を改めて実感できました。

Reactive Systemsに関しては「どうやってソリューションに適用するパタンを作っていけるか」がポイントとなってきそうです。Reactive Systemsはマイクロサービスを意識する事も必要で、SIerでいう下記のような要素の総合力が求められ、やりがいもあります。（最初からマイクロサービス前提で進める事に対するアンチパタンも存在する現状で、手法が先にならず問題解決領域でアプローチをしていけるパタンを模索するという意味でもやりがいがあります。）

• チーム熟練度
• 顧客との開発方針の詰め方
• 運用ナレッジ

今回のスポンサードをしようとしたきっかけは、Scala先駆者インタビューという企画をやろうと思ったコンセプトに似ていました。大した貢献はできませんでしたが、Scala求人情報を通してSIerとしての取り組みを少しでもお伝えできたので、また一歩踏み出せた感もあり、祭りが終わった後にもやって良かったと感じています。たぶん、弊社だけではなくScalaMatsuriにスポンサーを名乗り出るほど華々しい成果をあげているわけでもないと尻込みしている、SIerさんもいると思います。小さな成果や取り組みでもいいと思うで、事例や取り組みがで目に見える形で公開されていくことで業界に波及していくのではないでしょうか。そういう状況がそう遠くない内にくる事を期待しています！

海外の方を招いて、コンセプト通りの素晴らしい場を提供をしてくださった運営チームの方々ありがとうございました、来年1年間で実践力と失敗も積み重ね、スポンサードという形以外でもScalaコミュニティへの貢献やSIer界隈での波及に寄与していければと考えています。

最後になりましたが、ScalaMatsuriに合わせて弊社のScalaに関する取り組みや状況を書いた求人情報を公開しました。横浜というロケーションで働きたいと関心がある方や、オフィスに見学・遊びに行ってみたいという方は気軽にお声がけください。

Wantedly紹介

2016年 新年を迎え

新年あけましておめでとうございます。

昨年は多くの、本当に多くのお客様やパートナーの方々に支えられ、そして何より社員皆の努力により苦しいながらも実り多き一年を過ごすことができました。ありがとうございました。本年も一年、何卒よろしくお願いいたします。我々のビジョン「システムで人々をしあわせにする」を少しずつでもカタチにしていけるよう、より一層の努力をして参りたいと思います。

さて、アットウェアは年末12月24日が創業の日であり、また12月が期首にあたりますから、第12期がスタートしたばかりです。第12期に向けての取り組みなどは年末のatWare Advent Calendar 2015の中で私をはじめ皆が触れてくれていますので、ここでは割愛をします。一ヶ月経過したものの、まだまだそれが成果に繋がる状況にもなく、むしろ十分に形式知化できていなくてやや混乱した状態。それらを皆で考え試行錯誤しつつも歩みを進めている実感が心地よくもあります。

この年末年始の休暇中は、これらの取り組みをいまいちど自分の中で整理をし、これからのことを考える良い時間となりました。頭が良くないので本を読むのも得意ではないのですが、積読だった本を引っ張りだして現状と照らしあわせたり、やろうとしていることを再確認するのに本屋さんで仕入れてきたり。また、昨年末には米国ザッポス社やパタゴニア社を視察させていただく機会を得て、自分の中で悶々としていたものや会社としてあるいは経営者として不足していることを確認することもできました。

私個人としては、今年一年はしっかりと内と未来に目を向け、12歳（人間でいえば小学校を卒業する歳）となるアットウェアが大人へと成長していける骨格を作りなおすことに集中したいと考えています。会社としては新たな事業へのチャレンジを幾つか計画していますし、今まで積み上げてきたことをさらに成熟させていかねばなりませんが、優秀な社員がたくさんいますので、きっと彼ら彼女らが成し遂げてくれるものと思います。皆を信じ、私には私にしかできないこと（それは事業の推進を任せっきりにするのではなく裏方として支援しつつ私にしかできない判断をすることとその先を考えること）に覚悟をもって取り組んでいきます。

「我(々)がやりたいことをやる」だけではなく、「我(々)にしかやれないことをやる」。これが今年のテーマです。

納会 2015

みなさん、こんにちは。年末はいかがお過ごしでしょうか。納会ではカメラ小僧もどきを演じていた新人のまっさんこと、山本です。カメラのセンスがないのかぼくが撮影した写真は全て黄色っぽいです。ショックです。実家が北海道ということもあり、函館ラボの納会にも参加してきました。納会参加レポートで、今年のアットウェアブログを締めたいと思います。

At 横浜 YOKOHAMA Office

横浜の納会は、大掃除から始まって、アットウェアアワードの発表、そして、懇親会という流れで行われました。

 

大掃除

エンジニア、バックオフィス、役員が一緒になって、自分たちが働く場所の掃除をしました。私は前日にアットウェアアワードの準備をしたり、徹夜をしたり、寝たりしていたので遅刻してしまいました。私のデスクの前だけ、ほこりがたくさんありました。ほこりを残していただいておいてありがとうございます。

アットウェアアワード

アットウェアアワードは、有志で応募したエンジニア達が、社内で抱えている問題をITで解決というものでした。勤怠に関するものや、個人的な悩みに関わるもの、ミーティングルームの空き情報を管理するもの、Backlogと連携させたものなどなど様々な種類のエントリーがありました。

私はテックなポイントが取れないと判断したため、ネタに走りました。とてもよくないと思います。

懇親会

会社で、料理を食したり、飲み物を飲みながら、今年一年の労をねぎらいました。労をねぎらうという言葉を人生で初めて使いました。

表彰式

勤続10年を迎えた方々、ここの目標に対する評価など様々な観点において、表彰式が行われました。ハワイ出身のジェフさんにもしっかり英語で表彰しました。ベトナム出身のナムさんは最近日本語がバリバリできるようになってきたため、日本語で表彰しました。ベトナムからの刺客のナムさんとフイさんは日本語の上達が早すぎます。僕も彼らのように英語を学びたいものです。

View fullsize

View fullsize

View fullsize

View fullsize

View fullsize

View fullsize

 

アワード結果発表

完成度の評価が高かった牧野さんへの表彰

お昼に行われたアットウェアアワード結果発表が行われました。アワードは、プレゼン、技術力、アイディア、完成度といった4つの要素から点数がつけられ、それぞれ点数が一番高かった人、総合的に点数が高かった人が表彰されました。

優勝は、ジョージさん（左下）の姫路城2.0でした。写真がないのが残念すぎます。アワードの結果は追ってブログで紹介したいと思います。しれっと私もプレゼン賞をいただきました。

View fullsize

View fullsize

View fullsize

View fullsize

View fullsize

At 函館 HAKODATE Lab

寒々とした函館駅

函館の納会は、大掃除から始まって、懇親会という流れで行われました。

私は、出身が北海道ということもあり、実家への通り道ということもあって、函館ラボの納会にも参加しました。お土産を何も持っていかなかったかつ、大掃除にも参加しなかったため、ひどくイジられました。ちなみに函館では、ぼくが帰ったあたりから、雪がバンバン降り始めたようです。さすが前厄エンジニアです。

懇親会

卓球台がオフィスに置いてあると今風でかっこいい気がするのですが、函館オフィスの置き方、使い方は何かが間違っているような気がします。私が函館ラボに顔を出した時はいつも、この卓球台にはネットは装着されていません。ですが、ついに懇親会のあと卓球を....しませんでした。やはり彼らはあの台をただのテーブルとしか思っていないようです。全国の卓球ファンに謝ります、ごめんなさい。

---

さいごに

さて、ざっくりと、アットウェアの2015年の納会を振り返りました。 2015年12月から12期が始まり、アットウェアも新たな体制で年を迎えようとしています。来年はどのようなことが待ち受けているのかワクワクしますね。アットウェアブログをご覧頂きありがとうございました。
それでは、来年もアットウェアブログをよろしくお願いいたします。皆様、よいお年を。

23歳で前厄になるのでお参りしてきた

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

今日12月24日は弊社、アットウェアの創立記念日であり、アドベントの最後の日である。世の中はアドベントの最後の日、つまりクリスマスイブだというのに、僕らはいつも通り働いている。創立記念日というものは、社員みんなでパーティー的な催しがあるものだと思っていた。今の所、僕のカレンダーにそのような予定はない。

さて、1993年生まれ酉年の僕らは前厄になるのだから、何かしらの厄をどうにかするため、お参りしなければならない。よくよく考えてみれば、「お参り」ではなく、「お祓い」という言葉が適切だろう。どちらにしろ、ベトナム人の同期に、この違いを説明しなければならないと思うと少し億劫である。お墓を蹴っちゃいけないくらいの宗教観しか持っていない僕は、「厄年」というものがそもそもなにか気になって検索した。インターネットとは便利なものである。

“厄年というのは、陰陽道で教育、宣伝されているもので、その年齢になると厄災が降りかかるとされています。平安時代には、すでに厄年という概念があり、現在まで長いこと受け継がれてきている風習です。”

— yakuyear.com/about/what.html

そういうことか、いや、意味がわからない。なぜその年になると厄災が降りかかりますということが決まっているのか、そもそも厄災とはなんなのか、降りかかるものか、いろいろ突っ込みどころはあるが、「災い」という漢字が入っている以上、良くないことが起きることらしい。ある年に生まれた子供たちが、皆同じタイミングに災いが起きるなどというのは悲しすぎる。悲しい風習だということはわかった。

“厄年を民俗学的に見ると、『役年』になります。ある一定の年齢になると、神社やお寺で『役』をするという習慣からです。『役』になると、それなりに身を清め、行いを慎まなければいけませんでした。その役を終えて、はじめて一人前の社会人として、周囲の人から認められたといいます。
次第に、この『役』の年齢に差し掛かる頃には、精神的なものや肉体的なことに変化が起こりやすく、体を壊したり、思いも寄らぬ受難を受けたりするという、人生の節目になっていることが分かってきました。昔の人は、厄年を『役年』とすることで、役についた者に様々な制約をもうけ、『厄』から逃れていたのです。”

— yakuyear.com/about/what.html

やっぱり意味がわからない。僕の読解力がなさすぎるのか、ヤクヤク言いすぎているこのサイトのどちらかが悪い。明らかに前者だ。23歳くらいにもなれば、それなりの役を任されて、いろんなことがあるから頑張れ的なニュアンスだと思っておけばいいだろうか。

OK Google ここから一番ちかい神社は？

と話しかけてはみたものの期待通りの結果は得られず、普通に検索した。わからないことがあったら検索する。それでもわからなければ誰かに聞けばいい。昼休みに先輩につれられて、真相を確かめに近くの神社へ向かった。

今年のクリスマスのみなとみらいには、福山雅治がいろんなところにいる。福山雅治にも厄年があったのだろうか、あったはずだ。あったと信じたい。

平日の昼間だというのに、桜木町とみなとみらいをつなぐ動く歩道には沢山人がいる。さすが観光地だ。

場所がわからず、遠回りをしてしまった。正直、桜木町駅は通らなくてもよかった。

現在、弊社で開発を進めているの新プロダクトについて先輩と話しながら神社にたどりついた。

たどりついた、が....

工事中だった。

おわりに

アドベントカレンダーをご愛読いただき、ありがとうございます。今日でアドベントカレンダーも終わりです。新人という立場ながら、ブログを書かせていただけたことをとても嬉しく思います。弊社は高い技術力を持ったエンジニア集団です。自分は、まだまだヒヨッコプログラマ故、このような記事しか書けませんが、ゆくゆくは技術的なブログやアウトプットも公開していければと思っています。

今年、新卒として働き始めたあなたも、来年新卒になるあなたも、研究を続けるあなたも、新しいステージ、新しい役で、活躍することを願っています。信仰心が強い、おばあちゃんや上司に怒られないように時間が空いた際は、厄払いをしに神社へ出かけてみてはいかがでしょうか。

---

アットウェアではエンジニアを募集中！

キャリア採用・新卒採用

Scala先駆者インタビューも絶賛公開中！！

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

なるほどわかった！？色彩のお話し

みなさんこんにちは。不破@エンジニアです。最近はWordPressのお仕事を頂いており、高速WordPressを実現させるべく日々がんばっております。あと最近はスプラトゥーンにはまりつつある感じです。

今日のテーマは「色彩のお話」です。 最近のアプリケーション開発ではプロトタイプを制作するケースが非常に増えてきました。 Bootstrapの登場や普及などもあり、デザイナーやコーダーではないエンジニアもWebアプリケーションやスマートフォンアプリのプロトタイプを開発するようになりました。 その一方で、色彩についてよく考えないスマートフォンアプリやWebサイトが増えているように思えます。

そんな私もデザインや色彩については素人です。色々思うところがあって、色彩検定3級の勉強をしています。 今回は、エンジニアが知っておくべき色彩の知識についてまとめました。

色の三属性

「色の三属性」は学校で習った人も多いと思います。色には

• 色相
• 明度
• 彩度

があります。 色相は「色みの違い」を意味し、「青緑」「紫」「赤紫」など10の色相がJIS規格で決まっています。 色相を順番に配置したものを、「色相環」(下図)といいます。

Wikipedia 色相

明度は「明るさ」を示し、彩度は「鮮やかさ」を示します。彩度が低くなると灰色に近い色になり、逆に彩度が上がると派手な色になります。

補色

色相間の対面にある色の組み合わせを「補色」といいます。 先ほどの色相環図を見ると、非常におおざっぱな見方をすると「赤」の補色は「緑」になります。

例

補色は、背景色を決定するのに使用します。たとえば、「赤色文字の背景色」を考えましょう。今回は背景色の上に文字(「あ」)を描いてみます。

「赤」の補色は「緑(緑と青を混ぜた感じ)」です。補色を背景にすると、こうなります。

いい感じに赤色の「あ」が映っています。これなら「あ」という文字をすぐ認識することが出来ます。

今度は補色ではなく、色相環的に隣り合わせの色を組み合わせてみます。するとこうなってしまいます。

お互いの色が似通っているせいでよくわからなくなりました。 このように、補色になっていないと読みにくくなります。

Webサービスで「なんかこの色見にくい・・・」と感じた場合、「お互いに補色になっていない」ことが多いようです。

色がもたらす心理的効果

「暖色」と「寒色」

赤・橙・黄のように「暖かさ」を感じるような色を「暖色系」といいます。 この時期にヨドバシカメラの暖房機コーナーに行くと、オレンジ色や赤色をベースにしています。暖房機コーナーにある色は基本的に「暖色系なんだ」と思っていただけるといいとおもいます。 文字通り「暖かさ」を示すだけではなく、食欲を訴える色としても使われます。食品パッケージにもよく使われています。また、レシピサイトにも暖色系を使ったサイトが多く見られるのもこのためだそうです。(寒色系が全く使われないわけではありません。)

逆に青系の色は「寒色」といい、文字通り涼しさを感じます。夏になるとヨドバシカメラでエアコンコーナーへ行くと青基調の配置になっているのはこのためです。 また、夏のかき氷やアイスも寒色系を使うことで涼しさを引き立てています。この場合は「おいしい！」よりも「涼しい！」をアピールするために寒色系の色を使うことが多いみたいです。

Webアプリケーションを作るにあたっても、ターゲットに合わせて「暖色」「寒色」を意識してみましょう。 たとえば、食品を扱うサイトであれば明度を低めにしたオレンジ色を使うなど考えることができます。プロトタイプ開発にあたっても、この点だけでも気にしてみるとだいぶ変わります。

色の「視認性」

これはドキュメントを作る時にも心掛けたいポイントです。文字が読みにくいWebサイトになってしまうと、PV数にも直結することになるので注意が必要です。 色の視認性は「背景との明度の差(コントラスト)が大きい」ほど認識しやすくなります。 明るい背景色に対して文字を載せたい場合、明度が低い(黒色など)色を選択します。

違和感を感じたら？

開発中のUIに「なんか見にくい・・・」や「目が疲れる」といったことを感じることが多々あると思います。 ただ、デザイナーさんに「なんか目に悪くない？」と言っただけではなかなか理解されないこともあるかもしれません。 そんなときに、「補色にすればどうですか？」のような具体的な用語が使えると、デザイナーさんにもスムーズに理解してもらえます。

間違いがあったら

この記事は素人が書いています。参考文献をベースにしながら書いていますが、間違いがありましたらお手数ですが不破までメール(fuwa at atware.co.jp)でお知らせください。できるだけ早く修正します。

明日はどうなる？

気づけばアドベントカレンダーも明日で終わりのようです。今年もあとわずかで、今週金曜日は弊社の最終営業日です。 ラストを決めるのは、あの新人です。

参考・引用文献

今回この記事を執筆するにあたって、下記の書籍を参考にさせていただきました。 また、色相環の画像はWikipediaより引用しています。 Wikipedia 色相

• ウェブ配色コーディネートカタログ(坂本邦夫 著)

• 人を惹きつける 美しいウェブサイトの作り方 人に伝わるデザインと制作のレッスン

いずれの本も、デザイナーではない私が読んでもわかりやすい内容で今後の開発にも活かしたい内容でした。年末休みに更に深く読んでいきたいですね。

みなとみらいの冬

こんばんは。アットウェアの女子社員です。

みなとみらいで働く私たちにとっては、「みなとみらい」は職場ですが、観光やショッピング目的で遊びにくる方も多くいらっしゃるとおもいます。 (いやいや、むしろ、そういう人の方が多いでしょぉ)

「みなとみらい」では、季節に応じた様々なイベント/催しが開かれ、毎日「みなとみらい」に出社する私たちは、仕事をしながら四季折々の「みなとみらい」を楽しむことができます。

さて、もうすぐ今年が終わろうとしているこの時期にあるイベントと言えば、Xmasですね。

そうなんです、さすがは「みなとみらい」。色々なXmasツリーやイルミネーションをみることができます。

atWare Advent Calendar 2015 の22日目は、この時期だけ楽しめる「みなとみらい」を写真でご紹介します。

では、さっそく、定時後、このオフィスを起点にぐるっとカメラ女子風に徘徊してきたルートに沿ってご案内します。

まずは、私たちのオフィスのあるみなとみらいセンタービルのXmasツリーです。 このオフィスに移転してきたのが12月だったこともあり、移転当日、このツリーをみて感激したことを覚えています。 ココだけのお話ですが、このビルでは何度かCMや雑誌の撮影をしているのをみかけたことがあるんです。そうなんです、お仕事の合間に有名人をみることもできちゃいます。

続いて、お向かいにあるクイーンズスクエアの入り口です。

一度建物に入り、そのまま通り抜けてat!のテラスに出ます。 すると、コスモワールドの観覧車を背景に素敵なイルミネーションをみることができます。 ココでは、スマフォで自撮りをしている方がたくさんいました。

再び、建物に入り海の方へ歩きます。すると、「キューピッドツリー」が出現します。 このツリーは1日に6回、音と光のショーが行われます。

それでは、来た道を戻って桜木町方面へ建物の中をずんずん歩きます。一度、外に出されますが、そんなことは気にせずに、ランドマークプラザへ入り、またまた、ずんずん歩くと真ん中あたりにツリーが現れます。おそらく、ツリーとしては「みなとみらい」で一番有名な場所です。

はい、そうなんです。何も知らずにココへ来た私は驚きました。 例年とは趣が違うのです。ココでも決まった時間になると音楽が流れ、ツリーと名曲を一緒に楽しむことができるので、得した気分になります。

さて、次は、建物を出て道路を渡って、マークイズへ移動します。

お気づきでしょうか。実は先ほどのツリーと対になっています。 ランドマークは「強さ」。そして、マークイズは「やさしさ」をイメージしているそうです。

それでは、せっかく入った建物をまた外にでて、横浜側に道路を渡ると、そこはみなとみらいテラスです。ここでは、水を使ったイルミネーションをみることができます。

そろそろ、体も冷えてきたのでオフィスに戻ります。

このブログでは最後になりますが、私たちアットウェアでもXmasツリーを飾っています。

ここでは紹介しきれないほど、たくさんのイルミネーションやツリーが「みなとみらい」では楽しめます。みなさんもぜひ一度、「みなとみらい」にいらしてみませんか？

さて、今年のAdventCalendarも後2日となりました。 明日は、札幌から来た彼が素敵なお話をしてくれます。

認定スクラムマスター研修に参加しました

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

2015年10月19日、20日に東京で開催された認定スクラムマスター研修に参加してきました。

講師のJames O. Coplienさんと川口さんにも感謝するとともに、成長のチャンスを与えてくれた会社に感謝しています。

これまで1年ほどアジャイルでの開発に携わってきましたが、今回の研修に参加することで再認識できたことや新しい発見もたくさんありました。

忘れないうちに、私が感じたスクラムの間違いやすい点や感想をまとめてみます。

まずは、スクラムの概念で間違いやすいところからです。

POはデイリースクラムに参加する必要はない？

　　スクラムガイドには特に決まりはないですが、POは定期的にデイリースクラムに参加したほうがいいです。

　　理由としては、まずPOもスクラムチームの一員です。

　　POはビジネス価値と詳細要求仕様を開発チームに届ける役割を担っています。デイリースクラムで開発チームの発言をきくことで、「届ける内容」をよりわかりやすいものにすることができます。

スプリントレトロスペクティブ（振り返り）におけるPOの役割は何ですか？

　　どのようにPOが関与するのかは、スクラムチームが定義します。

スプリントレビューの主な目的は何ですか？

　　ステークホルダーが、チームが作ったものを確認し、次に何をすべきかについての意見を与えるためです。

スプリント中に、変更があったらどうしますか？

　　変更はビジネス価値があり、プロダクトオーナーが許容できる期間内にチームが対応でき、かつプロダクトオーナーが承認した場合は、開発作業中いつでも受け入れます。

チームは最初のスプリントでは何を行いますか？

　　スプリントゴールを定義します。

次は、超個人的な感想です。

スクラムはイノベーションを生み出せる

　　まず、スクラムの特徴である「改善」です。「改善」の延長線上にイノベーションがあるというのはよく耳にする話です。

　　そして、スクラムはチームで仕事を進めるためのフレームワークにすぎないと思われるかもしれないですが、独創的問題解決プロセスを活用することでイノベーションを起こします。このプロセスの1つは、解決方法を探るときは、チームメンバーが集合してブレストを行い、アイディアを上げていきます。そして、全員が様々な意見を出し、それを参考にブレストすると、更にアイディアの質も量もよくなります。

常に優先順位の高いものから消化していく

　　POがエンドユーザのフィードバックや市場状況の変化に応じて、価値が大きくなるものを優先して順位をつけ、常にその優先度が高いものから消化していくことで、無駄を最大限に減らすことができます。

オープンで生産的なチーム

　　スクラムでは、チームメンバーに指示を出したり、チームの方向性を決めるリーダーは存在しません。

　　全部がそうではないと思いますが、一部の保守的な開発チームには、タブーとなっている話題があり、通りたくない道を進まないようにしています。まれに、自分に割りあたったタスクが何のためにあるかがわからない時もあります。

　　アジャイルでは、温かくあいまいではなく、オープンで生産的なチームを作ろうとしています。

　　チームメンバーは一人一人が常に自分のやっていることに責任を持ち、自分がやっていることでどんな価値を生み出していくのかを理解し、誰もが議論を始めることができ、そして、誰もが言い難いことをいえます。

　　スクラムチームではのんびりすることはありません。ただ待つだけの人もいません。

チームの疲弊を防げる

　　「リリース日に合わせてスコープを調整する」あるいは「スコープに合わせてリリース日を調整する」。

　　リリースに向けて追い上げることはしないことで、スケジュールに追われて疲弊になることはないです。

「場」を大事にする

　　スクラムでは関係者が同じ場所に集まって、コミュニケーションを大事にしています。

　　POがエンドユーザーの声をよく聞く、開発チームはPOの仕様をよく聞く、自分が作りたいものだけを作ったら単なる自己満足にすぎません。エンドユーザーにとって、価値のあるものを作れなければなりません。

バグはいいことだ

　　英語で言うと、”Safe-Fail, NOT Fail-Safe”です。スクラムは安全に失敗をさせます。

you should be what you want to be

　　スティーブ・ジョブズがスタンフォード大学での卒業スピーチの最後でも似たことをおっしゃっていました。

　　ただ、現実は甘くなく、いろいろな”障害”が発生します。

　　例え障害があっても、自分ができることは必ずあるはずです。自分ができることを探し、実行しましょう。

最後に

スクラムマスターの資格が取れても、それは終わりではなく、ただのスタートです。（講義中にCoplienさんがおっしゃったことです。）

私自身スクラムマスターの認定をうけてもうすぐで2ヶ月がたちますが、日々の仕事で大きな変化はありません。学んだ知識を日々の仕事にどう活かしていくのかを常に考えています。

自分は何ができるのか、何か改善できることがないのかを常に心かけ、毎日の小さな努力のつみ重ねが、いつか点と点を結ぶことができると信じています。

メンター（Mentor）って、なんだろう？

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

３回目の登場！！最近ハッピー絶好調からは遠ざかった、プライベート絶不調の荒木です。

社会人になって、誰もが不安や期待の中、うまくやっていきたいと願い、疑問を抱えながら進んでいく。そんななかで、「こんな人になりたい」「この人と話すと疑問が解消される」「なんでこんなことまでやってくれるの」って人に出会う。逆にそんな人になれたら、どんなに嬉しい事だろうか！

そのような人になってほしい。全員が良いメンターになれればいい会社になる。

そんなこんなで今期からアットウェアではメンター制度を導入しました。

導入開始

全員が一人以上のメンターを指名し契約を交わす。業務に支障の出ない形をとってすすめる。

心構え

特に新人は自力で学ぶことが重要。技術や文化、責任についてもまずは体験しながら学ぶ。なんでもかんでも支援という形でやり過ぎてはいけない。話しすぎたり、説明し過ぎるとメンティにとって良いことはない。どれだけの支援を必要としているかを把握する。そのためにコミュニケーションをしっかりとり、信頼関係を築いていくことを心がける。

内発的に

素直な気持ちで、接してはいるが、好ましい方向に進むように仕向ける力が必要。 そして、本当にメンティが困って、立ち往生し、悩んでいる時には、さっと隣に座って、声を掛ける。 適切なタイミングで、適切な言葉で声をかけ、モチベーションを上げることも必要。 内発的動機づけとなってやる気を増幅させ、仕事、プライベート、会社、チーム、いろんなことに目標を立てやる気を高めることで、自主的に伸びるようにやっていく。

エンジニアの特性

そもそもエンジニアはメンターになりたがらないね。同じ問題に３倍以上かかるかもしれない人に、自力で学ばせる機会を与える余力が無いからなのかな？

でもそうでない人もいる。自分が新人のころよく遅くまで付き合ってくれた先輩がいたけど、多分気にかけてくださっていたんだと思う。

まだ始まったばかり、バスの前に立ってしまってはバスは出発できない。まずは出発しなくてはことは始まらないよね。早く乗り込もうぜ！

最後に

私もメンターをやらせてもらうことになりました。正直メンターに指名されるとはまったく思っていませんでした。メンターに選んでもらって光栄で嬉しい。この機会を挑戦し高い成果を出せるように一緒にやっていきたい。

ということで、今日はここまで、

明日はCuteで、一番信頼を寄せているあの人の登場です！！乞うご期待ください！！！

社内用の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. みなさん、さようなら。