しょぼちむさんがKotlinをやらない理由を考えてみた

はじめに

このエントリーは しょぼちむ Advent Calendar 2014 の 12日目として書かれたものです。

11日目は、@uemmra3さんの「扶養～ 」です。

13日目は、@yy_yankさんの「Kotlinアイドルのあるべき姿」です。

Kotlinとは

みんなお世話になっているウィキペディアから引用すると、こういう言語です。

Kotlin（ことりん、コトリン）は、ジェットブレインズ社のアンドリー・ブレスラフ、ドミトリー・ジェメロフが開発した、静的型付けのオブジェクト指向プログラミング言語である。

プロジェクトのページは、http://kotlinlang.org/。
レポジトリは、JetBrains/kotlin。

デモはこちらから出来ます。

日本でKotlinと聞くと、やはり自称Kotlinエヴァンジェリストこと@ngsw_taroさんの存在を忘れてはいけません。

今年のアドベントカレンダーは、Kotlin Advent Calendar 2014です。
21日には、我らがしょぼちむさんが記事を書いてくださるみたいです。
楽しみですね。

なぜか

しょぼちむさんが、Kotlinやると宣言したのは、ちょうど1年前の模様です。

かわいいKotlin勉強会に行ったら生活変わった！　 Kotlin Advent Calendar 2013

この一年で、私も幾つかの勉強会でそれらしい(中の)人とお会いすることが出来ました。

Clojureの勉強会で発表するほど積極的になられたのは、素晴らしいことだと思います。

とはいえ、やはりKotlinアイドル(?)がここまで頑なにKotlinのレポジトリを作らないのも、気になるところではあります。

そこでGitHubで「Kotlin」を検索してみると、いろいろヒントがありそうです。

一番スターが多いのは、やはりKotlin本家ですね。Githubでは、スターを付けた人を「Stargazers」と呼んでいるみたいです。

では、本家のStargazersを見てみましょう。

日本の方もかなりスターを付けているみたいですね。

しかし残念ながらやはり頑ななアイドル、2014年12月12日午前0時では、見かけることが出来ませんでした。

そこまでしてやらないとなると、やはり確固たる意思みたいなものを感じます。

ということで、本題のなぜやらないのかを考えてみました。

• Clojureでスクショに魅力を感じた。
• VBAで手一杯だった。
• うらがみさんが教えてくれなかった。
• ClojureやJavaを使っての女子力アップに忙しかった。

思いつくだけでも、これくらいありますね。

その他にもありそうですが、どれもKotlinより優先順位が高いと判断されてしまった模様です。

残念です。

いつの日か

そこで、まずはKotlin本家のスターをつけることから勧めたいと思います。

あなたとKotlin、今すぐアイドル。

JVMアイドルへの道も一歩から。

見守ってあげましょう。

Kotlinのレポジトリが作られるその日まで。

退職しました

2014年11月30日を持って7年間在籍した会社を退職しました。

転職理由

転職活動の時に作った資料には、こんな事書いてました。

新しい技術に挑戦できる環境で、技術力がある人と一緒に仕事をしたかったからです。

きっかけは、Java8がリリースされた時に対する会社内での受け止められ方を知った時でした。
Java8がリリースされた後、様々な媒体から資料を得たり、勉強会に参加して実際に触れてみたりした内容を社内で共有しても、反応が返って来ませんでした。
導入されるのは後かも知れませんが、準備しておかなければ、実際に決まってから取り組んでも遅いということを提案いたしましたが、その後の反応は芳しくありませんでした。
また、技術についていろいろと相談したいことがあったとしても、相談出来る人が社内におらず、意見を求める事が難しい状況でした。
さらに、新しい技術について検証を行う際も、与えられた開発環境では検証を行うことが出来ず、十分な結果を得ることが出来ませんでした。

理由として、今後エンジニアとして生きていく事を考えた際に、今の環境では手詰まりとなる危機感が一番大きかったと思います。
会社が周辺環境の変化についていけてない状況を改善する方向性を打ち出さ無かったのは、決定的でした。

経緯

入社した2007年は例年に比べて採用状況がよくなっていた模様で、大学を8年もやっていた人間にはまたとない機会でした。
しかし、よくなっていたとはいえスタートラインに立てただけの人間には、やはり厳しい状況でした。

2007年の1月になって、今の会社が内定を出してくれたお陰で職を手にすることが出来ました。
配属後は、勤怠を中心とした、給与、人事の業務管理システムの開発を担当することになりました。
主にJavaで作られたWebアプリケーションである自社パッケージを、顧客の就業規則等に併せてカスタマイズを行うのが業務でした。
とある会社の勤怠管理システムの案件では、要件定義から保守運用までの各工程に携わってました。

20人にも満たない会社だったので、必然的に一人で出来る事を増やさないと仕事が回りませんし、教えてくれる人もいない方が多かったので、自ら学ばなければならない状況だったので、初めの4年は暗中模索の状態でした。

2011年の東日本大震災は、五反田で被災して、徒歩で帰宅したのを覚えてます。震災の影響とか関係なく炎上してました。
その案件が終わった後すぐに別の炎上してる案件に突っ込まれたので、いろいろ考えさせられました。

振り返ってみて自分の中で何か変わったキッカケは、Seasar Conference 2009 WhiteのS305-2: テスト駆動開発のこころ (TDD はじめの一歩)にあるのかなと思います。

当時は、Seasar2に触ったことがないのにも関わらず、Javaのイベントで気軽に行けそうだと思って参加してました。
2011年にTDDBC横浜に参加して、和田さんの講演を聞いて以前に参加してたのを思い出してました。

その後、アジャイルサムライ読書会の横浜道場に参加するようになって変わった実感がありました。
アジャイルサムライに出会ってからの3年は、とても勉強になりました。
たくさんの師匠に出会って、イベントに参加したり、講師をさせてもらったり等業務だけでは知り得なかった事を体験することが出来ました。

その3年で最も会社の中で実感したのは、アジャイルサムライの一節として出てきた「誰もがこの働き方を気に入るわけじゃない」でした。
社内勉強会等開催してもう一人の仲間を探したり作ろうとしてましたが、結局、出来ず仕舞いでした。
そして、転職理由へと繋がってしまいました。

これから

独りのエンジニアとして、何が出来るのか、何が足りないのか、何がしたいのか、何になりたいのかを考えた結果の転職でした。
小さな会社だった為か、裁量がある程度もらえたおかげで、いろいろ試行錯誤出来ましたし、勉強しなければ生きていけない環境だったので、量が質に転化するまで経験出来たのは、感謝しています。
本当にありがとうございました。

次の会社は、12月1日からです。
一ヶ月位有給休暇しようとしましたが、残念ながら11月末が納期だったので結局1日くらいしか消化出来ませんでした。
まぁ、自分のようなダメ人間が社会復帰するには時間がかかるのは分かっているので、良かったのかも知れないです。

最後に、例のリストはこちらです。ご査収ください。

JJUG CCC 2014 Fallに参加してきました #jjug_ccc

JJUG CCC 2014 Fall

きっかけ

これまで使ってきたGradleについてJJUG CCCで発表してみようかなと思って春に応募してみましたが、あえなく落選してしまいました。
秋にはリベンジしたいと思って、どんなネタがいいかなと考えていましたが、JJUG ナイト・セミナー 「ビール片手にLT&納涼会」で話した内容から、Groovyに繋がるような内容にしてみようと思い、応募してみたところ何故か当たってしまいました。

今までLTや長くても15分くらいしか人前で話すことが無かったので、50分をどう扱ったら良いのかいろいろ悩みました。

スライド

セッションは、Gradleで始めるGroovy expandです。
発表した資料はこちらです。

補足

Gradle徹底入門が出版されたということで、本の内容の紹介を含め、Gradleで使うにはGroovyでどんなことを知っておくと良いか等を話すことにしました。

初めはAndroid Studio使ってGradle Tutorial : Part 5 : Gradle App Engine PluginからGradle Tutorial : Part 7 : Android Studio + App Engine + GradleをGroovy, Groovy on Androidでやってみたいなとか考えてましたが、当日までの準備してると間に合わない状況になったのと、トラブルを避けようと思い、全編スライドでの説明にしました。
いずれ何かの機会でチャレンジしてみたいと思います。

スライドや発表では紹介しきれていない箇所がGradleにはあるので、まずは徹底入門を購入していただいてもらうといいと思います。
ちょっとしたスクリプトを書く場合にも使えますし、Javaのライブラリを駆使してタスクを組み上げたりすることも出来ます。

現場ではAntやMavenでレールを外れることもあると思います。
そういった場合にXMLではなく、ビルドスクリプトとしてGroovyを使うことが出来るので、無理をせずにやりたいことが出来るのがGradleの良い所だと思います。
自分がまとめで言いたかった事は、Javaを知っているとGradleやGroovyを使うハードルは低いので、まず試してみて日頃の業務を改善してみてはいかがでしょうか。ということです。

最後に

セッションに参加して下さった皆様ありがとうございました。
初めての発表で、ご期待に添えない、説明が至らない箇所、お聞き苦しい点などあったと思います。
それでも最後の拍手はとても暖かく、嬉しい気持ちでいっぱいでした。

発表の途中でいろいろGroovyやGradleについて質問をしてみましたが、使っている人が増えてきているのを実感しました。
主催しているYokohama.groovyを、今回の発表で興味を持って下さった方々にとってより良いコミュニティにしていきたいと思いました。

今回のJJUG CCCはどのセッションも魅力的で楽しい内容でした。
昼食や懇親会では、普段はtwitterでしかやりとりをしてない人とお会い出来て楽しかったです。

あと、Java養成読本の著者の方がいらっしゃっていたのでサインをしてもらうことも出来て良かったです。

JJUG、セッションの発表者、スポンサー、参加者の皆様、ありがとうございました。

ScalaMatsuri 2014に参加してきました 2日目 #ScalaMatsuri

ScalaMatsuri 2014
http://scalaconfjp.doorkeeper.jp/events/13535

#ScalaMatsuri 二日目「アンカンファレンス」
http://togetter.com/li/717660

2日目

1日目のレポートはこちら

1日目に引き続いて参加してきました。
アンカンファレンスは初めて参加しましたが、どんどんセッションが決まっていく様子は、とても楽しかったです。
スキルが高い人達が多かったから多かったかも知れませんが、発表できる人がいたり、scala以外のセッションがあったりと本当にお祭りのような雰囲気でした。

そういったいろいろと盛り沢山な中、以下のセッションに参加しました。

• Getting Started with Haskell for Scala Programmers
  
• Actor の話 by 吉田さん @xuwei_k
  
• Getting Started with Spark by Aaron
  
• Scala, the simple parts by 小田好先生 (Martin Odersky)
  
• The Code Clinic by guest speakers!
  
• Scaling Scala (panel discussion) by @xuwei_k、瀬良さん、かとじゅんさん、にわさん、ふくはらさん

どのセッションも充実しててとても楽しかったです。
参加出来なかったセッションもTLを見る限り、面白そうでした。

次回開催されるとしたら、アンカンファレンスあると絶対楽しいと思います。

両日とも内容の濃いいい一日を過ごすことが出来ました。
スタッフの方々には感謝の言葉しかありません。

スポンサーの皆様、スタッフの皆様、Speakerの方々、最後にOdersky先生ありがとうございました。

Getting Started with Haskell for Scala Programmers

GREEの方がHaskellとScalaの違いについて話されていました。
Scalazではどう取り入れているのかも、同時に知ることが出来たので良かったです。

Actor の話 by 吉田さん @xuwei_k

ScalaのRedis Clientを使った事があり、それにAkkaが使われてたため、よくわからないまま使っていたこともあり、参加してみました。
実際に使われてる方は、Sprayで利用してる人が多いみたいです。
やはり、テストが難しいらしくsleepするコードを埋めるため時間もかかるみたいです。

Akkaについて呟いたところ、以下のようなコメントを頂きました。@okapiesさん、ありがとうございます。

@grimrose けっきょく「Erlang を Scala に持ち込んだもの」なんだろうと思います。 #ScalaMatsuri2
— Yuta Okamoto (@okapies) 2014, 9月 7

Getting Started with Spark by Aaron

Apache Sparkを始めるだけなら、tarを解凍してscriptを実行するだけですぐ使えるのは、素晴らしいと思いました。
スピードが早くて追いつくのを途中で諦めましたが、@ueshinさんがgistにしてくださったので、後で試しながらやってみたいと思います。

Scala, the simple parts by 小田好先生 (Martin Odersky)

Scala - The Simple Parts, SFScala presentation from Odersky

Scalaがどういった思想で設計されているかを知ることが出来ました。
2日間Odersky先生の講義を聞けたのは、とてもいい経験でした。

The Code Clinic by guest speakers!

Odersky先生他、1日目のspeakerの人たちからコードレビューを受けられるという事で、手を上げて下さった方がいらっしゃいました。
コメントやドットと括弧については、リーダブルコードでも出てきた話でした。
Scalaでは、パターンマッチを使えるのでcase classと併せて積極的に使っていく方向に持っていくのが、見てて興味深かったです。

Scaling Scala (panel discussion) by @xuwei_k、瀬良さん、かとじゅんさん、にわさん、ふくはらさん

Scalaを実際に使われてる方々が、日々どう対応してるのか、どう考えているのか知ることが出来て、いい勉強になりました。
アンカンファレンスならではの面白さが詰まった、最後に考えされられるいいセッションでした。

ScalaMatsuri 2014に参加してきました 1日目 #ScalaMatsuri

ScalaMatsuri 2014
http://scalaconfjp.doorkeeper.jp/events/13535





#ScalaMatsuri 一日目の様子
http://togetter.com/li/717717

ScalaMasturi 2014

今年からScalaの勉強を始めたので、参加してみたいと思ってました。
やはり、Martin Odersky先生が招待されているのが一番の理由ですね。
金額も気にせずチケットを買いました。

2日間参加しましたが、とても内容が濃くScalaにどっぷり浸かる事が出来ました。
Twitterのタイムラインでお見かけしてた人たちや、関西から参加されている方々とお会いできたので、楽しむことが出来ました。

次回開催される事になったら、お手伝いが出来ればいいなと考えております。
今回のスタッフの方々には、Scalaを実際に使われてる人が多く、お話を聞いてみたいと思っているので、
そういった人たちがもっと発信出来るようにサポート出来れば幸いです。

1日目

The Evolution of Scala / Scala進化論 from scalaconfjp

基調講演では、Martin Odersky先生によるScalaの歴史を聴け、哲学というか思想を知ることが出来ました。
言語開発をしてる方のお話は、その人なりの信念みたいなものを感じることが出来るので、とてもおもしろいですね。
視点などもフレームワークを作ってる方と違ったりして、そういった点でも興味深かったです。

その後は以下のセッションに参加しました。

• sbt、傾向と対策
• Fifty Rapture One-Liners in Forty Minutes
  
• Node.js vs Play Framework
  
• Solid and Sustainable Development in Scala
  
• Apache Spark を用いた Big Data パイプラインの統一
  
• グリー初のScalaプロダクト！チャットサービス公開までの苦労と工夫
  
• Silkで編むデータフロー
  
• 国技と Scala

sbt、傾向と対策

sbt, past and future / sbt, 傾向と対策 from scalaconfjp

sbtは、Gradleユーザの自分からするといろいろと未知な部分があったりするので、セッションでどう使っていけばいいのか知れたのは良かったです。
Gradleにも導入されたzincもsbtのおかげというのも知れて良かったです。

Fifty Rapture One-Liners in Forty Minutes

Raptureは、JSONを返すAPIサーバのテストとかで使うと見やすくなるのかなというのが印象的でした。
scalaのマクロでここまで出来るのは知らなかったので、今後も楽しみです。

Node.js vs Play Framework

Node.js vs Play Framework (with Japanese subtitles) from Yevgeniy Brikman

LinkedInはPlayの他にもいろいろなフレームワークを試しているそうです。
あと、あの話の落とし方は関西でも通ずるそうです。
どのフレームワークを選ぶかは、会社やプロジェクトに依存してしまいますが、周りの情報に踊らされずに検証して見合ったものを使いたいものです。

Solid and Sustainable Development in Scala

Solid And Sustainable Development in Scala from Kazuhiro Sera

@seratch_jaさんが、現実と理想を見据えてscalaでどう対処していくのか、Skinny frameworkでは同対処したのかを、ほぼ全編英語で話されてました。
Skinny frameworkは、個人で使っていることもあり、作られた方がどういう思いで作られたのか知ることが出来て良かったです。

Apache Spark を用いた Big Data パイプラインの統一

Building a Unified Data Pipline in Spark / Apache Sparkを用いたBig Dataパイプラインの統一 from scalaconfjp

databricksの方がデモしながら説明されていましたが、解析結果が数秒で返ってきて、しかもグラフが見やすいのは、衝撃的でした。
また、SparkSQLがSQLに似てて扱いやすく、細かいところはScalaで対応できるのは、Sparkの魅力的な一面を見ることが出来ました。

グリー初のScalaプロダクト！チャットサービス公開までの苦労と工夫

The Trial and Error in Releasing GREE Chat. GREE's First Scala Product / グリー初のScalaプロダクト | チャットサービス公開までの苦労と工夫 from scalaconfjp

GREEでのScalaとDDDを使ったプロジェクトのお話は、以前の勉強会で@j5ik2oさんのお話を聞いていたので、実際に参画されている方のお話はとても興味深かったです。

Silkで編むデータフロー

xerialさんが、fluentdを使ったテストで使っているxerial/fluentd-standaloneを作られてた方だというのを初めて知りました。
Silkのお話で、WhatとHowを分けて同じコードで実装側をいろいろと変えれるようにするのが印象的でした。

国技と Scala

バックエンドにscalaを採用した内容については、エンジニアが採用する技術を選択できるdwangoならではの評価だと感じました。
また、親方 Driven Developmentもとても興味深かったです。

RubyからScalaへ: There's more than two ways to do it

RubyとScalaのどちらが良いというのではなく単純に比較されてて、それぞれの長所を淡々と話されてました。
大トリでしかもScalaを業務で使っている人が多い中、素晴らしい発表でした。

２日目に続きます