SpeeeでiOS/Swiftエンジニアをしている id:Mitsuyoshi です。
今年も、会社の参加費サポート制度を利用してtry! Swift Tokyoに参加してきました。

感想

プラットフォーム固有でない発表が去年より多かったように思います。また、公演は言語としてのSwiftについて、LTは使い方の部分という住み分けがされていてよかったです。

普段意識しない、言語の裏側の物事について深く追求する入り口になる、良いイベントでした。

スポンサーブース

スポンサーブースでは、Google Form or パネルにシールを貼るタイプのアンケートに答えると特典を出している企業が多く見られました。参加側としては、ノベルティをもらうときのやましさが低減されていてよかったです。アンケート内容も、ただ情報を回収するだけではなく、自社イベントの招待をくれるなど参加者側メリットを提示しているところもありました。特典は技術書典に出している薄い本を配っている企業が数社あり、私もWantedlyとIBMから頂きました。

f:id:Mitsuyoshi:20180308111749j:plain

図形の組み合わせだけなのにWantedlyとわかるのはすごいですね（左）

IBMの本（右）は完全にSwift寄りの話が書いてあり、言語仕様から始まってサーバーとクライアントを両方Swiftで実装し、モデル層のソースコードを共通化させる、ということを簡潔に説明していました。

Extending Swift Value(s) to the Server

Why adopt Swift? - The Swift language may well be better than what you are currently using.

運営について

面白かった試みとしては、司会の方が推進したアイスブレイクがありました。「この機会にぜひ知らない人と話してください」とアナウンスするだけでは効果が薄かったと思いますが、「相手の言語で話しかけるフレーズを紹介します」という体でユーモラスな例文を紹介しており、参加者にも実際に読み上げさせることでアイスブレイクの抵抗感を減らしていました。その後会場では見知らぬ同士で話している光景が多く見られました。

f:id:Mitsuyoshi:20180302125500j:plain

トーク

特に面白かったトークを紹介します。

AST meta-programming in Swift

岸川さんの、AST(Abstract Syntax Tree) を使ったメタプログラミングについての発表です。

文字起こし：http://niwatako.hatenablog.jp/entry/2018/03/01/175717

ASTの説明と、ASTを利用してソースコードを解釈するとどのようなことが可能になるのかということを紹介していました。その中のひとつ、 SwiftPowerAssert は ビルド前 にソースコードを文字列として編集し、追加機能を挿入してからビルド、テストを行うことで、assertionに新規機能を追加するというものでした。

ソースを読むと文字列として表現されたASTをパースして解釈できる形にした上で、assertionの呼び出し箇所のソースコードを置換しているのがわかります。 Swiftlintも一部ASTの解釈を行なっているlintルールがあるそうで、ASTを扱えるようになるとSwiftプログラミングの周辺ツールの使い勝手が向上しそうです。

気になった人は、スライド中にも出てきた swiftc コマンドを使ってみるとよいと思います。適当なswiftファイルを引数に渡すと、モードに応じた出力が得られます。

# -dump-ast: Parse and type-check input file(s) and dump AST(s)
$ swiftc -dump-ast b.swift
(source_file
  (top_level_code_decl
    (brace_stmt
      (call_expr type='()' location=b.swift:1:1 range=[b.swift:1:1 - line:1:22] nothrow arg_labels=_:
        (declref_expr type='(Any..., String, String) -> ()' location=b.swift:1:1 range=[b.swift:1:1 - line:1:1] decl=Swift.(file).print(_:separator:terminator:) function_ref=single)
        (tuple_shuffle_expr implicit type='(Any..., separator: String, terminator: String)' location=b.swift:1:7 range=[b.swift:1:6 - line:1:22] source_is_scalar elements=[-2, -1, -1] variadic_sources=[0] default_args_owner=Swift.(file).print(_:separator:terminator:)
          (paren_expr type='Any' location=b.swift:1:7 range=[b.swift:1:6 - line:1:22]
            (erasure_expr implicit type='Any' location=b.swift:1:7 range=[b.swift:1:7 - line:1:7]
              (string_literal_expr type='String' location=b.swift:1:7 range=[b.swift:1:7 - line:1:7] encoding=utf8 value="Hello, Swift!" builtin_initializer=Swift.(file).String.init(_builtinStringLiteral:utf8CodeUnitCount:isASCII:) initializer=**NULL**))))))))

なんとなく何をしているかわかりますね。

超解像+CoreML+Swiftを使ってアプリの画像データ転送量削減に挑戦する

データ転送量を削減することで解像度が落ちた画像を、クライアントアプリ側で解像度を復旧するという手法についての発表です。

文字起こし：http://niwatako.hatenablog.jp/entry/2018/03/02/120404

これはすごかったですね。そのような手法が技術的に可能であるのは知っていましたが、

実用的な解像度に戻せる
それを携帯端末で現実的な時間で行える
必要なモデルの容量も小さい

と実用できるレベルになっているとは思っていませんでした。

https://github.com/DeNA/SRCNNKit UIImageViewのextensionになっているので、学習済みモデルさえ用意すれば既存のアプリへの導入は setImage() の置換だけでできるようですね。非常に簡単なインターフェースになっています。

// https://github.com/DeNA/SRCNNKit/blob/master/SRCNN-ios/SRCNNKit/UIImageView%2BSRCNN.swift#L10-L23

extension UIImageView {
    
    public func setSRImage(image src: UIImage) {
        self.image = src
        DispatchQueue.global().async { [weak self] in
            if let output = SRCNNConverter.shared.convert(from: src) {
                DispatchQueue.main.async {
                    self?.image = output
                    self?.layer.add(CATransition(), forKey: nil)
                }
            }
        }
    }
}