初回から毎年参加している 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 の今、ぶっちゃけ

http://www.slideshare.net/hirokiky/llot-python-65410202
Type Hinting : 型ヒント
Python 標準で型を明記できる
Python 自体は制約を与えない
IDE などが利用する

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 ではシンタックスのみを仕様化
実装はまだまだこれから

キーボードにこだわろう

どのくらいキーボードにお金をかけているか会場にアンケート
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 再考

登壇者紹介
各言語の詳しい人
再考は最高とかけている
動的型付けとは何か
TAPL こと型システム入門

「動的型付けされる」といった言い回しは誤っているといって差し支えなく、おそらく「動的検査される」と言い換えるべきであるが、標準的に使われる用語法である。型システム入門 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 で編集とか

抽選

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

エンディング

恒例の会場の写真などが入っていて当日作成されたビデオ上映
アンケートのお願い http://ll.jus.or.jp/2016/enquete

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 までなのできりのいいところで帰るようにという話

LLoTに参加した

開会

Language Update

Java Update

Language Update PHP 編

Perl Language Update

Python の今、ぶっちゃけ

Language Update JS

最近の Ruby

キーボードにこだわろう

昼休み

Dynamic Typing 再考

休憩

Kotlin vs Swift

抽選

エンディング

LLoT Night

フロントエンドだめ自慢

帰ってきたデモ自慢

5分で出来るIoT

プロジェクト°D ﾂﾜﾓﾉどもが夢の跡

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

エンディング

Written by

Kazuhiro NISHIYAMA

Supported by