by shigemk2

当面は技術的なことしか書かない

はてなブログのブログカードを挿入するEmacs Lisp

ブログネタをEmacsでメモってるとやっぱりリンクの生成とか手入力するのは面倒なので、 Emacs Lispを書きました。

昨日の新規機能を受けまして。

「ブログカード」をOGPなどに対応しました。さまざまなWebページをコンパクトに整形して掲載できます - はてなブログ開発ブログ

(defun hatena-embed(arg)
  (interactive "sInsert URL:")
  (insert (format "[%s:embed]" arg))
  )
(global-set-key (kbd "C-x v C") 'hatena-embed)

Xitrum Web Framework ライブコーディング #ScalaMatsuri

Xitrum Scalaのフレームワーク httpサーバとしての機能も持つ。非同期のクラスタリング

  • 資料が豊富
  • 構築が容易
  • ライブラリの活用によるパフォーマンスの高さ
  • スケーラブル

ルーティングの自動収集

Connect

  • CORS、i18n

発表の趣旨

2013 LTの発表時ではXitrumは2系 現在は3系

ファイルのモニタリングなど大幅なアップデート

http://xitrum-framework.github.io/guide/3.18/ja/index.html

Node.js vs Play #ScalaMatsuri

LinkedIn Yevgeniy Brikman

Node.jsもヘビーに使っていた

express

Node.js vs Play 比較

Node.js

学習
  • Node.jsの学習は簡単
  • 6行書くだけでスタートできる
  • express.jsは8行
  • nodeを実行するだけでサーバが起動
  • 本もいっぱいある
  • APIのドキュメントも整備されている
  • Stack Overflowもおすすめ
  • Node.jsの学習曲線は緩やか
開発
  • URLパラメータやパースパラメータを抽出出来る
  • プラグインがある
  • ただ、XML処理などはライブラリを自分で探す必要がある
  • キャッシュに関しては内部でやるのでおすすめしない
  • socket.ioは強い
  • プラグインを揃えて使う
テスト
  • テストは満点
セキュリティ
  • CSRFはデフォじゃない
  • Node.jsにはevalがあるが、evalとかsettimeoutには致命的な脆弱性がある
ビルド
  • npm(コミュニティが大きい)
  • 複雑なビルドの場合はGruntとかを使う
  • 学習曲線は緩やか
デプロイ
  • ホスティングサービスはすごい充実してる
  • let it crash気味なので再起動は必須
  • monitで死活監視したりする
  • デプロイは一応全部Node.js内で出来る
  • nginxなどのサポート
デバッグ
  • 満点
  • IDEでデバッグ可能
スケーリング
  • ベンチマークは早い
  • 複数のデータアクセスの場合はNode.jsのほうが早い
  • non-blocking
  • ひとつでもblockingな呼び出しがあれば死ぬかもしれない
メンテナンス
  • JSはいたるところにあるので、情報やコードが入手しやすい
  • JSも関数型書けるよ!
  • ロボットでもJSをかけるよ
  • ソースの共有も可能
  • コアは安定している
  • 型がはっきりしないのは地味にエグい
  • メンテナンスは苦痛
  • スコープのルールが壊れているし、block scopeなんてないからメンテ性ない
  • コールバック地獄
  • コアは安定していてもライブラリは不安定
  • thisにいろんな意味があるのは悪夢
コミュニティ
  • Node.jsのほうがStackOverflowの質問数は多いけど、それはNode.jsがわかりにくいため、かつユーザー数が多いため
  • 雇用数は多い

Play

学習
  • いきなり35行のファイルやらフォルダやら
  • とにかくファイルがいっぱい
  • サノバビッチ
  • sbtがjarをいろいろとダウンロード
  • Activatorテンプレートはサンプルコードも含む
  • 学習曲線はNode.jsに劣る
  • 本は少なめ
開発
  • 静的型づけ
  • Scalaにコンパイル
  • SQLだとPlayに軍配が上がる
  • DB系ライブラリの出来は良い(NoSQLだと同じ感じ)
  • フルスタック
  • クライアントサイドは自分で書かないといけない
テスト
  • テストは満点
セキュリティ
  • CSRFはデフォじゃない
  • evalな脆弱性は少ない
ビルド
  • sbt(インタラクティブなビルドツール)
  • 学習曲線は厳しい
  • Ivyで依存性を管理。でもIvyは遅い
  • Rhinoはとても遅い
デプロイ
  • ホスティングサービスは多くない
  • (nginxをかます必要があるかも)
デバッグ
  • ブラウザ上に表示
  • ツールも豊富
スケーリング
  • ベンチマークは早い
  • non-blocking
  • JDBCでブロック
メンテナンス
  • 学習曲線は厳しいが高い生産性を維持できる
  • 型システムはありがたい
  • 表現がいい
  • 20年選手JVMで動いている
  • 同期か非同期か自分で選べる
  • コンパイル遅い
  • コールバックヘルもない
  • sbtでインクリメンタルコンパイルができる
  • Scalaは複雑
  • Playは安定しているけど後方互換性がない
  • 成熟しているとはいえない
  • Playのバージョンアップはライブラリ群のバージョンアップを伴う
コミュニティ
  • 第20位の言語(比較的マイナー)
  • TypeSafeの運用サポート
  • Javaのライブラリが使える

ただし、web frameworkの評価は総合的に行う必要がある

Solid and Sustainable Development in Scala #ScalaMatsuri

  • Scalaを使う会社が増えている
  • でも3年経つとレガシー化する
  • アプデしようとしてもコストがかかる

Skinny Framework AWScala

ScalikeJDBC(Simple JDBC)

QueryDSL

Skinny Framework

  • Scala on Rails
  • Full-stack features
  • Web Development

(Good Parts)

based Class-based OOP

  • Scala case class is simpler than Java beans with (great) Lombok
  • Scala high-order functions are simpler than Java 8 Stream API
  • Immutability is well-treated in Scala
  • Java decisively beats Scala with compile speed

Immutability

  • Do away with mutable states

Trait Chaos

  • Mixing traits can show you terrible chaos

Coding Style Tips

  • Use sbt-scalariform without question(cf. gofmt)

The Real As-Is

  • Abstraction often improves things, but that:s not always the best way to solve real-world problems

Skinny ORM

ORM built on ScalikeJDBC

not Only compiler

scoverage

Avoid SBT Hacks

sbt is not so easy for Scala newbies

The same issue as Ruby gems, eco-system is still so smaller than Ruby's one

Nosurprises for NewComer

newcomesers may not show scala well

スライドはいずこへ

はてなにおけるScala活用事例 #ScalaMatsuri

新しいプロダクトでなんでScalaを選んだのか

なんでPerl

  • 型チェックしている言語はハッカーが使う言語ではない
  • CPAN

そして数年後

  • レガシーコードが残っている
  • スマホアプリなど様々な需要
  • テストやレビューはやるけどそれでも足りなくて500
  • やっぱり型システムはいるよね

なんでScala

  • mackerelを商用で使ってみよう
  • mackerel-agentはもともと社内ツールであった
  • 役割ごとに表示
  • ホストが変わってもグラフが表示される
  • Nagios的な警告メール発砲

  • 最初は外注も使ってた

  • 初のB2B
  • nginxとredis以外は初採用の技術ばかり
  • Scala Play Slick Nginx Go Graphite PostgreSQL

なんでScala

  • モダンな型システム
  • アドホックなポリモーフィズム
  • データタイプ
  • B2B向けに安定したやつ
  • 実績のある言語

  • Scalaを書ける人がいた

  • Java8(リリースされてなかった)

  • Haskell(書ける人いなかった)
  • Go/Ruby(型システムじゃなかった)

Scala開発について

Play

  • ルーティング テンプレートエンジンなどフルスタック
  • カスタマイズが自由
  • Twirl
  • Angularjsのテンプレート
  • MVC(Perlのときは状態をもったオブジェクトが多かった)
  • 型クラスを使ってマッピング
  • ルータに型がつくように

  • routing

  • 型安全

  • コンパイルが遅いのでモジュールを分割して作っている

  • CoreTypes→Core Models Core Views→Core Controllers

Slick

  • TypeSafeなクエリ、生クエリ両方書けるクエリジェネレータ
  • バージョンアップが大変
  • 慣れないと読めない
  • 複雑なクエリも簡単かつ安全に書ける

開発フロー

  • Gitで管理
  • EmacsやVimでもいけるよ
  • developブランチへmerge

タスク管理

  • GitHub issues/pull request
  • Tag
  • Milestone
  • Scrumでやってて、Sprintがマイルストーン
  • CIはJenkins(Perl時代よりまじめにJenkinsを使うようになった)
  • 1時間から20分へ
  • パラレルでやってる

  • デプロイのプロセスをだれでも出来るようにするために、masterへのPRを執事が自動で生成してくれている

デプロイ

  • PerlだとCapistrano(+Graceful Start)

Scalaのよいところ

  • 静的型づけがとてもよい
  • ライブラリが充実
  • 関数型言語

Scalaの悪いところ

  • コンパイルが遅い
  • モジュールを分割してもなお遅い
  • 学習コストが高い
  • job queueの標準はどれなのか
  • モックがだるい

結論

Perlには戻れない

【追記あり】グリー初のScalaプロダクト!チャットサービス公開までの苦労と工夫 #ScalaMatsuri

GreeChat

アクティビティの活性化を目的とする

数十万人の利用を目的とするバックエンドの構築

  • 対象者はこれからScalaを使ってなんかアプリを作る人向け
  • チーム開発
  • 問題点

Scalaを選んだ理由

GREEChatの要件

  • 何十万人のユーザー
  • リアルタイム
  • 少ないサーバ(サーバ資源の効率化)
  • 保守性(5年以上)

候補

  • PHP(社内で使っているから。)
  • ストリーミングの問題
  • シングルスレッド マルチプロセス(サーバを効率よく使うのが難しい)
  • 保守性の問題
  • セミコロン

  • Scala

  • 並行プログラミングとの親和性とサーバ台数を減らせる
  • 一つのプロセス、複数のコネクション
  • 関数型言語→副作用がない→保守性
  • 社内技術の活性化
  • コード量を少なく
  • 社内にScala大好きな人がいた

どのようにScalaを学んでいったか

2/7(チームでのScala力の向上)

  • 自主学習(基本的な構文の理解)
  • コップ本
  • 逆引きレシピは網羅性が高い
  • Twitterのwebドキュメント
  • EffectiveScala
  • オープンソースのコードを読む
  • Twitterの人
  • チームでの勉強会
  • 個々の学びをチームで共有
  • 階乗計算問題をコードを書いてチームで見せ合う(varを使うとバグのもと)
  • 必要最小限の副作用
  • ペアプロ
  • 効果的な学習
  • ツールの使い方の共有

まとめ1

  • 並行プログラミングとの親和性
  • 経験者の負荷は高め

GREE Chatのアーキテクチャ

  • キューで分かれている

API Server

  • リクエストを受け付けて、イベントをキューに積む
  • ロジックを非同期で書く
  • 非同期前提
  • finagle(サーバだけでなくクライアントとしても使っている)

EventBusServer

  • akka
  • 並行分散処理をより簡単に書く
  • 競合やデッドロックのことを考える必要がなくなる
  • 耐障害性をサポート

Stream Server

  • 接続数を増やしたい…
  • ユーザ情報をメモリで管理
  • akkaやfinagleを利用した非同期処理

まとめ2

  • サーバをキューで分けてる
  • 非同期と親和性の高いfinagle
  • 並行処理が出来るakka

開発の問題点

JVM

Scalaライブラリの自作

  • シャーディングライブラリが必要だった
  • GREEにはもともとシャーディングライブラリがあったけど、それはPHP用だった
  • AuroraとChatシステム
  • auto_incrementをPKとするとinsertに時間がかからないけどuuidをPKとすると時間がかかる
  • Snowflakeに代わるライトウェイトなやつを作りたかった(→Cornflake)
  • シャーディングをするためのライブラリをOSSとするけど、組み込みに時間がかかった

まとめ3

  • 並行プログラミングとの親和性
  • チームとの共有
  • アーキテクチャはAkkaとFinagle
  • ライブラリの自作とOSSへの貢献

追記

一部削除しました。

Silkで編むデータフロー #ScalaMatsuri

データ処理をいかに簡単にするか

TDのひと

SQLをクラウドで使ってもらう

TDではScalaはつかっていないけど、ScalaでTDを使うとなるとこうなるんじゃねっていう

ループだと遅いのでインデックスを貼る

書き方

代わりにSparkSQLを使う

Silk ループがない

http://wifo5-03.informatik.uni-mannheim.de/bizer/silk/

ナズェヒツヨウナンディス

Silk

プラットフォームの切り替え

What's a macro? #ScalaMatsuri

  • マクロって何
  • マクロのなにがいいの
  • マクロを使ってコードを書くとどうなるか
  • マクロの今後

Scala2.1.0から入ってきた

マクロを使うのは簡単、マクロを作るのは難しい

  • コードを作るコード
  • Scalaのシンタックスでコードを組む
  • コンパイラがコンパイル時に実行する

マクロ以前

  • sbtプラグインを使う
  • 今も使ってるけど
  • ASTコンパイラプラグイン(別のプラグインを使う必要がない)

なぜマクロ

  • プラグインあるじゃん
  • プラグインのお作法を学ぶのはしんどい
  • コードがシンプルになる
  • 必要なときだけコードを生成する
  • 余計なものを生成しない
  • パフォーマンス
  • マクロはみんなの味方

マクロを使おう

  • import scala.language.experimental.macros
  • -language:experimental.macros(コンパイル時引数指定)

  • マクロを使うコードとマクロが書かれたコードは別々にコンパイルする必要がある

  • 同時にコンパイル出来ない

Def Macros

http://docs.scala-lang.org/ja/overviews/macros/overview.html

コードを置き換えてくれる

logger.debug(s"Some $expensive message!")

if(logger.isDebugEnabled)
logger.debug(s"Some $expensive message!")

キーワードはマクロで。

マクロ例(Emacs Lisp) http://e-arrows.sakura.ne.jp/2010/03/macros-in-emacs-el.html

ドライアプローチ 2.11はホワイトボックスとブラックボックスに分かれている

http://scalamacros.org/paperstalks/2014-06-17-EasyMetaprogrammingForEveryone.pdf

よいところ

  • 自動生成
  • 静的チェック

わるいところ

ライブラリを使うユーザーにはやさしくないので複雑

meta 実際に使う人向けにシンプルに

Scalaマクロの使いドコロ

  • Code生成
  • 静的型チェック

まとめ

  • OSSコミュニティレベルで積極的に使っていけば、フィードバックが得られる
  • あまり枯れていないので改善点は多い
  • Scalaマクロは過渡期

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

DSPの話

今日言わないこと

  • Scalaでハイパフォーマンスシステムを作る方法
  • コンパイル時間
  • どっちが良い言語?

動的型付けと静的型付けの戦争はどっちでもいい

どちらもオブジェクト指向ベース 無名関数

class定義はScalaとRubyで同じ

まとめ

  • 生産性を高めようという目的意識は似ている
  • 問題解決のためのアプローチを知るのは重要