#ScalaMatsuri 2016に参加しました！ #Scala #Akka

2016年1月30日(土)〜31日(日)にて開催された、ScalaMatsuri2016に参加しました。

ScalaMatsuri 2016｜日本最大級の Scala のカンファレンス

当日はScalaにおける海外の有名人(Typesafe CTOやAkka、Scala-jsコミッタ、ScalaTest作者など)が参加され、登壇もされていました。
英語でのセッションも多かったですが、トランスレータの方々が同時通訳をされており、英語がわからなくても講演を聞くことができました。
技術的な内容を通訳するというのはそれだけで大変だったと思われますが、その業界に強い方々だったのか、特に違和感なく聞くことができました。
ぜひ次回もあってほしいなと思いました。

参加人数も過去最大で、スタッフの方々におかれましては、事前準備、および当日の運営、本当にお疲れ様でした。

楽しく参加でき、またScalaに対する自分の考えを深掘りすることができました。
ありがとうございました。

参加したセッション

1日目

  • Refactoring in Scala
  • 猫という考え方
  • Dockerをベースとしたインフラ上でのPlay frameworkアプリケーション本番運用ノウハウ
  • アジアから Scala OSS に貢献するということ
  • みんなの関数型プログラミング
  • レジリエンスが無ければ、他は無いも同じ
  • The Zen of Akka
  • ドワンゴアカウントシステムを支えるScala技術

2日目(アンカンファレンス)

  • Domain Specific Language(NASA, Guardianの話題)
  • Scalaz入門
  • Async Testing in ScalaTest 3.0
  • Typesafeの人にリアクティブについて聞こう
  • DDD+CQRS+EventSourcing実装する会(Akkaパフォーマンスチューニングについて話してみよう会)
  • パネルディスカッション：Scala社内教育

今回のScalaMatsuriを通して思ったこと

今回のScalaMatsuriは前回に比べ、どのようにして使うべきか、どのようにして社内に導入すべきかみたいな話は割と少なく、事例が多くなってきた印象を受けました。

個人的に参加させていただいて一番の収穫は、Akkaに関する知見を深められたことだと思います。

もちろん、抽象化による純粋関数型Scalaの考察も面白かったし、大変興味深いものでした。
しかし今回はそれ以上に、システムアーキテクチャにScalaやAkkaをどのように利用していくか、
Akkaをコアにした周辺エコシステムに関するお話が非常に面白く、色々考える事ができました。

レジリエンスを高めるためのお話、Akkaを扱う上での考え方、AkkaでDDD+CQRSを実装することに関する考察、すべて実システム稼働を見据えた積極的な議論に参加することができたと思います。

Better Java的な位置付けでたまたま出会ったScalaに、3年間取り組み続けた判断は間違っていなかったということを確認することができたカンファレンスでした。

Akka in Action読もっと！

Scala関西Summit2015のスタッフをしました！ #scala_ks

なんの

http://summit.scala-kansai.org/

スタッフとして参加した経緯

以前からScalaに興味を持っていたこともあり、参加させてもらっていた勉強会で発表した過去から@aa7thさんにお声がけいただきました。

Scala関西勉強会

なにをやったか

  • サブホールのコーヒーケータリングの手配、設置指示
  • メインホールのタイムキープ
  • 懇親会でビールを飲むマシーンになる

思ったこと

  • メインスタッフの方々ありがとうございました！
    私はScala関西Summitの開催が発表されたあとにお手伝いをした、いわゆるサブスタッフなのですが、ここまで大きなイベントを関西で開催しようとしたこと、またたくさんのプライベートな時間を費やして準備され、イベントのために尽力されたことには頭が上がりません。 本当にありがとうございました。そして、お疲れ様でした。

  • NSCの方々ありがとうございました！
    今回イベントネットワークを構築していただいただけでなく、様々なイベント経験から当日の設営〜運営までサポートしていただき、本当にありがとうございました。 ネットワーク品質もすごく良いので、みなさまもぜひどうぞ！(?) NSCとは

  • スピーカーのみなさま、スポンサーのみなさま、ありがとうございました！
    いまの日本のScalaを引っ張っていっておられる方々や企業のみなさまのご協力で、素晴らしいイベントにすることが出来ました。スピーカー、スポンサーのみなさまがいなければ、もちろん開催なんてできなかったと思います。 本当にありがとうございました。

  • 参加者のみなさま、ありがとうございました！
    よくイベントの主催者さんたちが、「このような会を開催出来たのも、参加してくださったみなさまのおかげです！」っていうセリフがあると思いますが、あれは本当にそう言ってるんだなぁと体感しました。 自分が参加者の立場の時は、「参加するだけで、なんか受け身だよな...」と思っていましたが、参加してこのようなイベントを盛り上げること自体が、コミュニティにとって+1で、その+1がいっぱい集まるとすごい力になるのだと、改めて思いました。 参加していただいたみなさま、本当にありがとうございました。

まとめ

  • 本当にありがとうございました。(感謝の気持)
  • Scala最高！(2015年8月1日現在)

GitBucketのポート番号を変更する。HTTPSで動かす。

GitBucket Git
最近個人的に利用しています。
普通に"java -jar"で起動したらポート番号は"8080"になるんですが、
他のアプリと被ってたのでポート番号を変更して起動させました。

java -jar gitbucket.war --port=8880

下記を参考にしました。
https://github.com/takezoe/gitbucket/blob/master/src/main/java/JettyLauncher.java

HTTPSでアクセスする

HTTPSでアクセスする際は、フロントにリバースプロキシを設置して、
そこから振り分けるようにしました。
(リバースプロキシまでは"https"。プロキシとGitBucket間は"http")

その際、GitBucketの生成するリンクが"http"になってしまうので、
GitBucketの[Administration] > [System Settings] > [Base URL]に下記のように設定します。

https://hostname/gitbucket

上記の場合、リバースプロキシで"/gitbucket"へのアクセスをGitBucketに"http"で転送するようにすれば、
うまく接続できるはずです。

上記設定をしても、"http"でのアクセスは相変わらずできてしまうので、"iptables"でシャットダウンしてしまいましょう。

ちなみに証明書が自己証明の場合、Gitコマンドでこけるので、
証明書確認を無視する設定を".bashrc"にでも突っ込んでおく必要があります。

export GIT_SSL_NO_VERIFY=true >> ~/.bashrc

では楽しいGitライフを。

FTPSのポート番号(21 or 990?)

サーバ FTP
FTPSは21番ポートと990番ポートが制御用に使われることがあって、
その違いがわからなかったので、調べたことメモ。

FTPSには2つのモードがある。

  • 明示的な暗号化(Explicit)
    　"FTP"の代わりに"FTPS"が21番ポートで受け付ける。
    　クライアントに暗号化を強制させることができる。
  • 暗黙的な暗号化(Implicit)
    　"FTP"を通常通り21番ポートで受け付け、"FTPS"は990番ポートで受け付ける。
    　クライアントは好きな方を選ぶことができる。
詳細は引用(引用元)

Explicit
サーバの USERコマンドに対してクライアントがユーザ名の代わりにAUTH SSL/AUTH TLSを発行し、サーバからの応答受信後クライアントからSSL/TLSハンドシェイクを開始し、SSL/TLSセッション確立後にログインを開始する方式。
すなわち、非暗号化状態で接続を開始し、ユーザ名とパスワードを検証する直前にセキュアなデータ接続を行う。

Implicit
いきなりクライアントからSSL/TLSハンドシェイクを開始し、SSL/TLS セッション確立後にログインを開始する方式。
すなわち、クライアントはサーバへのすべての要求をセキュア状態で送信する。

ちなみに"SFTP"は22番ポート。
("SFTP"は"SSH"のオプション的なもので、"FTP"とはそもそも異なる)

まだまだ勉強不足だーね＾＾；