初回から毎年参加している LL イベントの LLoT – Lightweight Language of Things に今年も参加しました。

今回は昼と夜の2部開催ということで、初の2部開催だったLLDNのTシャツを着て行きました。

以下はそのメモです。

開会

時間が厳しいということで手短に説明をして始まりました。

Language Update

これも時間が短いのか、どんどん進んでいきました。

Java Update

  • http://www.slideshare.net/torutk/llot2016-java-update
  • Java の紹介
  • Java の歴史
  • 10 年に一度大きな変更 : 2004 ジェネリクス、2014 ラムダ式
  • Java の近況
  • Java Update - Java SE 8
  • ラムダ式
  • インタフェースへの実装
  • static メソッドの実装、default メソッドの実装
  • メリット: 既存のインタフェースにメソッドを追加しても壊れない
  • JavaFX 8
  • Java SE 9 と LL との関係は時間の関係で省略

Language Update PHP 編

  • http://www.slideshare.net/hnw/laungage-update-php
  • 近頃の PHP 界隈
  • トピック 1: PHP 7 速いよ!
  • 10年ぶりのメジャーバージョンアップ
  • 他の言語ならマイナーバージョンアップ相当
  • 内部実装の大変更・高速化
  • 広報互換性は原則維持
  • 何を高速化したのか?
  • 特徴的だった取り組み
  • WordPress をベンチマーク対象として高速化を進めた
  • 高速化チームに一定の裁量を渡した
  • PHP 7 の性能
  • 高速化って必要だったの?
  • Facebook 製の別実装 (HHVM) が倍以上高速だった
  • データ構造を見直す良い機会だった
  • トピック 2: PHP 7.1 リリースへ
  • 2016 年 12 月頃 PHP 7.1.0 リリース予定
  • 目立った変更点
  • トピック 3: エコシステム定着
  • ここ数年で Composer の利用が定着
  • 参加者を増やしつつ破綻しない仕組み
  • 「ユーザー名/パッケージ名」で登録
  • 対応する GitHub/BitBucket の URL を登録する
  • トピック 4: 開発支援環境の普及
  • IDE、特に PhpStorm 利用者が増えている印象
  • トピック 5: 他の言語の「普通」を採用
  • トピック 6: 地方コミュニティ活性化
  • PHPカンファレンスが日本各地で開催 (2016年は4箇所)

Perl Language Update

  • Perl 6 クリスマスバージョン
  • Rakudo Perl 6
  • Rakudo の実行環境
  • 長年 Perl 6 の土台となってきた Parrot はついに完全引退
  • Rakudo Star
  • 四半期に一度くらいのペースでリリースが続いている
  • Perl 5 の近況
  • 地味に更新が続いている
  • Perl 5.14 で実験的に導入された auto deref が削除
  • 5.20 で実験的に導入された postderef 機能が正式化
  • @{$arrayref} -> $arrayref->@*
  • %{$hashref} -> $hashref->%*
  • YAPC::Hokkaido 2016
  • http://yapcjapan.org/2016hokkaido/

Python の今、ぶっちゃけ

def add(a: int, b: int) -> int:
    return a + b
  • typing モジュール
  • Python 3.5 で追加された
  • Python 3.2~3.4 では php install typing すれば良い
  • 他 Python 3.5
  • async (async def, async for…), await 構文
  • 行列計算演算子 @
  • Python 3 を使っているか - 使っている
  • Python 2,3 議論は終わった
  • Python 3 に対応していないライブラリーはない
  • さっさと移行しろフェーズ
  • 環境まわり
  • pip が標準でインストールされる
  • pyvenv も標準でインストールされる
  • どうやっているか
  • 公式 Mac バイナリーしか使わない : python.org
  • パッチバージョン何でも良い
  • 周辺の話
  • データ系が多い話
  • Django

Language Update JS

  • http://www.slideshare.net/teppeis/javascript-language-update-2016-llot
  • 周辺の話が多すぎるので、言語仕様の話だけ
  • ECMAScript
  • ES2015
  • 5年ぶりの大きな変更
  • WEB+DB PRESS 87 参照
  • ES6 compat-table score
  • ES2016
  • 2016/6/14 公開
  • 新機能は2つだけ
  • Array.prototype.includes
  • Exponentiation Operator
  • 新しい仕様策定プロセス
  • 仕様提案を 5 段階の Stage で管理
  • 最終 Stage に到達した仕様をまとめて、毎年6月にES20XXとしてリリース
  • 最終 Stage に進むには2つの実装が必要
  • GitHub でオープンに議論
  • もはや言語バージョンは無意味
  • “ES20XX” みたいなバージョンは意味が薄い
  • 個別機能の Stage や実装状況が重要
  • compat-table を見ておこう
  • ES2017
  • Async Functions
  • ES6 Modules
  • 大激論中
  • ES6 ではシンタックスのみを仕様化
  • 実装はまだまだこれから

最近の Ruby

  • http://qiita.com/takahashim/items/a0afa8765682f2cce659
  • Ruby 最新情報
  • RubyKaigi 2016
  • 安定版 : Ruby 2.3.1
  • 現在開発中の Ruby 2.4.0
  • 基本的に地味
  • 派手な奴は 3.0 に期待
  • Ruby 2.4 の変更点
  • Fixnum と Bignum が Integer に統合
  • 内部実装の違いという見せ方に変わる
  • 普通に利用している分にはあまり問題にならない
  • C拡張ライブラリが死ぬ
  • 現状では即死するようになっている
  • 2.4.0 リリース時には?
  • String#{downcase,upcase,capitalize} の Unicode 対応
  • 今までは ASCII の範囲内では正しく動作
  • 広く Unicode に対応できるように
  • 後置 rescue の構文
  • a = Date.parse “foo” rescue nil
  • a = Date.parse(“foo”) rescue nil
  • Enumerable#sum, Array#sum
  • 今までは各種ライブラリ側で実装
  • 2.4 で標準
  • 浮動小数点演算で誤差がたまらない実装を採用
  • Array#inject(:+) だと誤差がたまるので注意
  • Regexp#match? の導入
  • CGI.unescape 高速化
  • スレッド内での例外処理の向上
  • 細かい高速化
  • 今後の予定
  • 2016/9 Preview 2
  • 2016/11 Preview 3
  • 2016/12 RC
  • 2016/12/25 リリース
  • 他実装の話
  • JRuby
  • JRuby 9000 (9.1.2.0)
  • Rubinius
  • Rubinius 3.56
  • Rubinius X
  • mruby
  • mruby 1.2.0 (2015/11/18)
  • mrbgems
  • mruby CLI
  • H2O に組み込まれた
  • Opal
  • AltJS
  • Opal v0.10.1
  • Playground / TryRuby v4

後置 rescue の件は変更が入った時に、p(1 if true) みたいなのが通らない (引数は文ではなく p((1 if true)) のように式にしないといけない) のと同じように (使いにくい) 仕様だと思っていたので、ちょっと驚いた覚えがあります。

夜の部の時に聞いたのですが、 Ruby/Tk が gem として外だしされ、開発場所が https://github.com/ruby/tk になり、 ruby 本体のレポジトリから削除されたという話が抜けていたそうです。

openssl も https://github.com/ruby/openssl で開発が進んでいますが、 ruby 本体のレポジトリでの扱いはどうなるんでしょうか。 rake や Ruby/Tk みたいに削除されて gems/bundled_gems に入るのか、 rubygems や rdoc のように gem になるけど ruby 本体のレポジトリにも適宜取り込んでいくのか。 多分後者だと思っているのですが。

2016-08-30 追記: やはり openssl は本体のレポジトリにも取り込んでいく gem (default gem) になったようです。 それから、 Ruby 2.4.0 では tk の他に xmlrpc も bundled gem になるようです。

キーボードにこだわろう

  • どのくらいキーボードにお金をかけているか会場にアンケート
  • 0円 (ノートPC のそのままなど) から数万円までどの価格帯でもそれなり。
  • 5万円以上はさすがにいなかった。
  • 登壇者紹介

アメリカ西部のカウボーイたちは、馬が死ぬと馬はそこに残していくが、どんなに砂漠を歩こうとも、鞍は自分で担いで往く。馬は消耗品であり、鞍は自分の体に馴染んだインタフェースだからだ。 いまやパソコンは消耗品であり、キーボードは大切な、生涯使えるインタフェースであることを忘れてはいけない。 [東京大学 名誉教授 和田英一]

  • PFU 無刻印の話など
  • RealForce の歴史
  • 1981 キーボード試作機完成
  • 2000 リアルフォース発売
  • 2012 リアルフォース10周年
  • (なぜか12年なのに10周年)
  • 金融向けなどの専用キーボードのノウハウをリアルフォースに活用

  • とあるギークのキーボード遍歴
  • 作業環境
  • キーボード: ErgoDox, ErgoDox EZ, ノート PC 付属 (US 配列)
  • 2000年まではあまり高価でないフルサイズキーボード
  • 2000年〜2004年頃 会社マシンのキーボード
  • 2004年頃 Happy Hacking Keyboard Professional
  • 静電容量無接点方式
  • タイピングが軽いというのを重視していて、コンパクトでキーが少ないことには興味がなかった
  • 2006年頃 ストレートネック
  • 2011年頃 Realforce 87UB
  • ファンクションキーが欲しい
  • KDE ではグローバルショートカットを多用
  • カーソルキーも欲しい
  • 静電容量無接点方式でファンクションキーのついている、テンキーのないキーボードとして Realforce 87UB
  • 2015年〜 ErgoDox + ErgoDox EZ
  • セパレートによるリラックスした姿勢
  • HHK Pro や Realforce は良いキーボードだが、長時間タイプすると肩や腕が疲れる
  • 手首の角度
  • 水平ではなくろくろの角度が自然
  • 親指の活用
  • ErgoDox では左右 6 (8?) つずつ
  • 究極のカスタマイズ性
  • すべてのキーをカスタマイズ可能
  • ErgoDox Configurator
  • 全ての指に負担を分散
  • レイヤー機能
  • キー数が足りない分はレイヤーで補う
  • カスタマイズは永遠に続く

  • http://www.topre.co.jp/products/elec/keyboards/features.html の 入力部の構造 の説明
  • 部品の写真で説明
  • 入力部の構造 の下の 荷重特性 の話
  • キーボード配列が斜めにずれているのはタイプライターのハンマーが重ならないようにしていたのが由来
  • ErgoDox のセパレートの話
  • 某大学教授は HHKB 2台で”エルゴノミック”
  • Kinesis の縦に並んでいるのは最初は違和感があったが慣れたら他のキーボードとの使い分けも問題なくなった
  • 親指でシフトキーの話
  • Kinesis は凹んでいるが逆に山になっているキーボードを使ったことがある人はいるかというアンケートをしてみたら、いなさそうだった。
  • ErgoDox でレイヤー切り替えを親指で、数字キーのところがレイヤーが切り替わるとファンクションキーになるようにしている話

  • ハードウェアよりの話に戻す
  • ロールオーバーの話
  • USB の規格で制限がある
  • ロールオーバーというのはキーの同時押しのときの話
  • キートップの材質の話
  • 輪島塗で 50 万円の世界一高いキーボード
  • フットペダルの話は時間がないので省略

  • 会場から質問タイム
  • 耐久性の話があったが、使い込めば手になじむというのはどうなのかという話
  • 貴重な意見をありがとうございます
  • 人間の方が訓練されているのではないかという説
  • 左手のみとか右手のみとかの話
  • ErgoDox の USB チップのメーカーがなんとか (よくわからなかった)
  • Dvorak 配列は片手用がある
  • 無刻印の日本語キーボードが欲しいという話
  • HHKB はキートップも別買いできるという返答
  • ErgoDox を使うとき、肘は固定しているのかという話
  • パームは固定しているが、肘は固定してない
  • アームレストにはバナナがちょうどいいらしいです。 https://twitter.com/MiUKi_None/status/733594800608305152

昼休み

  • この時間に 3F に T シャツ引換に行きました。
  • プログラミングElixir」を買いました。消費税分割引で 2,800 円でした。
  • さくらのクラウドのクーポン (2万円分) をもらいました。今まで何度も使う前に失効させてしまっているので、今度こそちゃんと使いたいと思いました。
  • フォーチューンクッキーをもらったら、これもさくらインターネットのものでした。

Dynamic Typing 再考

「動的型付けされる」といった言い回しは 誤っているといって差し支えなく、おそらく「動的検査される」と言い換えるべきであるが、標準的に使われる用語法である。 型システム入門 2 ページより引用

  • 静的型付け vs 動的型付け
  • Lightweight Language
  • もともとは Dynamic Language だった
  • 1980年代: 動的 (Smalltalk)
  • 1990年代: 静的 (C++, Java)
  • 2000年代: 動的 (LL, Objective-C)
  • 2010年代: 静的 (Scala, Go, Swift, Kotlin)
  • 2020年代: ????
  • どちらが良いのか?
  • 結局好みの問題になる
  • 現代の動的型付け言語: JavaScript, Ruby, Smalltalk
  • Dynamic Typing 再考 JavaScript 編
  • AltJS 乱世の生き残りは『型』
  • TypeScript (MS), Flowtype (Facebook), Closure Compiler (Google)
  • 背景
  • 他の便利機能は ES6 で満足された
  • JavaScript での大規模開発が一般的に
  • ブラウザでは JS 以外の選択肢がない
  • 型の付け方
  • TypeScript: 後置型修飾
  • Closure Compiler: JSDoc
  • Flowtype: 後置型修飾 or 独自コメント
  • どれも JavaScript に変換が必要
  • Status of Static Typing in ECMAScript https://ecmascript-daily.github.io/pages/status-of-static-typing-in-ecmascript/
  • どれも午前中の説明で出てきた Stage 0 で終了している
  • TypeScript は言語、 Closure Compiler と Flowtype はチェックツール
  • ECMAScript 4 での失敗があるので後方互換性に問題のある変更は入りにくそう
  • もともと型定義がないので、ライブラリで困る
  • TypeScript はコミュニティベースで頑張っている
  • Flowtype などは互換性がないので TypeScript の資産は流用できない
  • TypeScript の型定義はライブラリによって品質がバラバラ、ライブラリのバージョンアップに弱い
  • Flowtype はライブラリごと再開発している
  • jQuery ぐらいメジャーだとどれでも対応しているが power assert ぐらいだと微妙
  • 標準ライブラリや DOM は割と明確に型が決まっている
  • 完全に動的なものだと型付けがあまり役に立たない
  • ES6 で class が入ったので型付けに優しくなっている
  • まつもとさん: JavaScript のようにみんなでやっていると意思の統一が難しそう
  • 梅澤さん: JavaScript 関連については今は様子見中
  • TypeScript は一定のレベルにきた感じ
  • まつもとさん
  • 80年代は Smalltalk や Lisp のような動的なものしかなかった
  • C++ や Java やリスコフの置換原則などがでてきた
  • DRY 原則
  • duck typing
  • 型を書かなくてもプログラムは動く
  • 動いているプログラムに型を書くのは冗長で DRY 原則に反する
  • IO クラスと書いてしまうと IO のサブクラスではない IO のふりをするオブジェクトを渡せなくなる
  • 未来に対する可能性を閉じない
  • 静的型と動的型の振り子は20年周期ぐらいと感じている
  • Ruby 3 は構想中
  • 静的な型チェックは入れたい
  • ポリシーは絶対に型を書きたくない
  • 具体的な型を書くというのは脳の負荷が高いので Lightweight (Language) ではない
  • コンパイラが矛盾を指摘してくれるようにしたい
  • ライブラリはテストを書くはずなので、その実行時の情報を蓄積すれば IDE の補助やコンパイル時の型チェックに使えるのではないか
  • 1.8 から 1.9 の非互換があったがみんな移行してくれた、 3 倍ぐらい高速化していたからではないか (ベンチマークによっては 50 倍ぐらい)
  • 実装はまだ
  • Erlang のダイアライザーではコメントで書くものを実行時の情報でやろうとしている
  • 普通に書かせると nominal typing になるが structual typing にしたい
  • String と書くと String のメソッドすべてを実装しないと通らないとかいうのは避けたい
  • 梅澤さん: Smalltalk の話に似ている部分があった (型は書きたくないという感じ)
  • Smalltalk 80 よりも Smalltalk 76 の方が Ruby に似ている
  • 梅澤さん
  • Smalltalk とは
  • ミニマリズムの言語
  • すべてはオブジェクト
  • オブジェクトがメッセージ送信する
  • の2つのみで成り立つ
  • プログラミング言語の壁
  • 使う人、作る人、言語を作る人
  • Smalltalk には上の区別がない
  • 自由の世界の重要性
  • デモ: http://www.slideshare.net/umejava/multilines
  • http://www.slideshare.net/umejava/supersupersubsub は時間がないので省略
  • 静的型の導入
  • Typed Smalltalk (1988)
  • StrongTalk (1993)
  • SmallInterfaces (2000)
  • Gradualtalk (2014)
  • 産業界では実のところあまり困っていない
  • オブジェクトが答えてくれる
  • ALLSTOCKER.com by SORABITO
  • バックエンドは Smalltalk でフロントエンドは JavaScript を普通に書いている
  • 関係ないけど SqueakJS というのもあるという紹介
  • 会場から質問 (1個だけ)
  • 型はプログラマの意図を伝えるもの、動的型ではユニットテストが相当するのではないか、DRY 原則との関連はどうか
  • まつもとさん: テストも本当は書きたくないが、必要悪として書いている

休憩

  • T シャツの引き換えやキーボードの展示などの 3F はこの時間まで

Kotlin vs Swift

  • 新言語はモバイル開発をどう変えるか

  • 言語仕様や特長, 開発者へのメリット
  • Kotlin
  • そもそも Kotlin とは? Better Java
  • Kotlin の特徴: 簡単, Interop, Android, 安全
  • 簡単: クラスとプロパティ
  • 簡単: データクラス
  • 簡単: 拡張関数
  • 安全: Null安全
  • モバイル開発者にとってのメリット: Interop, Android, 効率
  • Swift
  • https://github.com/kishikawakatsumi/KeychainAccess
  • Swift とは?
  • 2014年のWWDCで発表された
  • C, Objective-C と極めて高い互換性がある
  • 2015年からオープンソース
  • Swift の言語仕様や特長
  • Statically typed
  • Strongly typed
  • 動的な性質はほとんどない
  • 動的な性質が使いたい場合は Objective-C ランタイムを使う
  • No Garbage Collections
  • Playground (超すごい REPL)
  • 型安全
  • Statically typed
  • Strongly typed
  • Casting (as?)
  • Optional Type
  • モダンな言語仕様
  • Type Inference (型推論)
  • Optional Type
  • Generics
  • Pattern Matching
  • First-class functions
  • Operator Overloading
  • Protocol Extensions
  • Open Source
  • IBM Swift Sandbox
  • Serverside Swift
  • Swift Evolution
  • 基本データ型
  • No GC!
  • Automatic Reference Counting (ARC)
  • 循環参照が解放できない
  • オブジェクトの解放が予測可能
  • Playground (超すごい REPL) はあとで

  • 会場アンケート
  • Kotlin 使っている方: いない?
  • Swift 使っている方: 少ない?
  • Objective-C 使っている方: 少ない?
  • モバイル開発している方: そもそも少ない?

  • 注意点や落とし穴
  • Kotlin
  • Java用ツールやフレームワークまわり
  • Kotlin コードのコンパイル後の姿を想像するスキルが求められる
  • 例えば JUnit
  • static field に @DataPoints をつけたい
  • companion object と @JvmField を使う
  • Swift
  • ソースコード・バイナリ互換性
  • Swift のバージョンアップに対応するのが大変
  • 50M ぐらいのランタイムをみんな抱えている
  • コンパイラの安定性
  • Segmentation Fault: 11
  • https://github.com/practicalswift/swift-compiler-crashes
  • コンパイラが検出しない変更
  • エラーメッセージがわかりにくい
  • リファクタリング機能がまだない

  • 今後のバージョンアップ
  • Kotlin
  • バージョン1.1で追加予定の機能
  • コルーチン、型エイリアス、Bound Callable Reference, etc.
  • Swift 3
  • API デザインガイドライン
  • Objective-C API との親和性 (より Swift らしく)
  • 構文における一貫性の向上
  • ツールチェーンの安定化
  • パフォーマンス
  • メッセージの改善
  • Swift 3.x (Spring 2017), Swift 4 (Fall 2017)
  • Source/ABI 安定化
  • 品質とパフォーマンスの向上
  • Generics の高機能化
  • Memory ownership model
  • 並列プログラミングモデル
  • Reflection
  • C++

  • フリートーク
  • Swift で Objective-C を嫌がっていた Web フロントエンド開発者が iOS アプリも開発してくれるようになった。
  • Kotlin でコード量が減った。コレクション操作とかサードパーティライブラリなどが不要になった。 Null の扱いに安心感がある。
  • 会場から
  • Kotlin の IDE は? Java だと Android Studio
  • Android Studio に Kotlin のプラグインがある。
  • IntelliJ IDEA
  • Swift と C/Objective-C との親和性。ダブルポインタ(?)で困った。
  • 回答聞き取れず
  • Kotlin と Swift との関係性。 iOS と Android の両対応したいときとか。
  • GUI のフレームワークの思想やコンセプトが違いすぎるので、両方やるのが無難
  • どちらもサーバー側もできる。たとえば Kotlin は Servlet とかもできる。
  • Swift のサーバー側はまだ厳しい。 Objective-C のランタイムのない環境はまだまだ。
  • 両対応するために JavaScript という選択肢もあるが、どちらにしろ茨の道
  • Playground の話
  • iOS 10 から iPad でも動く
  • iPad の Playground のデモ
  • 補完とかもしっかり動く
  • Drag and Drop で編集とか

抽選

  • 恒例のボール投げ
  • 今年はもらえなかった

エンディング

LLoT Night

会場が地下ということもあり、電波が入らなかったのと、食事中ということもありメモがとれませんでした。

フロントエンドだめ自慢

  • React.js と Riot.js の話でした。
  • https://speakerdeck.com/cognitom/llot-night-riot-dot-js
  • Riot.js は Qiita の記事で見たことがあると言う程度だったので、会場に Riot.js を知っている人という問いかけがあったときに一応手をあげました。
  • Riot.js はコアコミッターが砂漠に消えたという話が印象深かったです。
  • Riot.js はコンパイラが正規表現ということで、若干の不安を感じます。
  • Riot.js の innerHTML を使っているというのは、どういう点がダメなのかわかりませんでした。
  • React の方はどういう話だったのか思い出せませんでした。(資料公開待ち)

帰ってきたデモ自慢

5分で出来るIoT

デモがうまく動かず、結局あらかじめ用意していた動画を流して終了でした。

プロジェクト°D ツワモノどもが夢の跡

みどころに「昨年のプロジェクト℃の続編」とありましたが、冒頭ではどいういう話か思い出せませんでしたが、内容を聞けばそういう話もあったなあと思い出しました。

結局デモはなかった?

Googleカレンダーで図書館の貸出予約状況を管理するLiblendrsv(Ruby)

  • 本借りすぎじゃないかと法林さんからのツッコミがありましたが、その通りだと思いました。
  • デモ自体はブラウザーが勝手に動いて面白そうな感じだったが、ウインドウがプロジェクター側にちゃんと出ていなくて、移動させてくる必要があったりして、ちょっと残念な感じでした。
  • https://github.com/hotuta/Liblendrsv
  • 一貫して Calendar を Calender と間違っているのが気になりました。
  • pit というパスワードを別途管理するライブラリは存在は知っていたけど、使ったことはないなあと思いました。

エンディング

  • 19:45頃
  • 昼の部と違って音楽のみ
  • 再度アンケートのお願い http://ll.jus.or.jp/2016/enquete
  • 会場が 20:00 までなのできりのいいところで帰るようにという話
Disqus Comments

Kazuhiro NISHIYAMA

Ruby のコミッターとかやってます。 フルスタックエンジニア(って何?)かもしれません。 About znzに主なアカウントをまとめました。

znz znz


Published