Hiroki Kato
はてなのソフトウェアエンジニアです。学生時代にMac/iOSアプリ開発からエンジニアとしてのキャリアをスタートしました。Apple、Cocoa (touch), Objective-C そして Swift が大好きです。
最近、自分が直面した問題を解決するためのライブラリを作ることがあります。そのようなライブラリは、実際の問題に対する解決策を具現化したものです。今日のSwiftには、解決するべき課題がたくさんあることでしょう。現実のモチベーションに裏付けられた、役に立つライブラリを作ってみませんか。
※前半、カメラ不調のため記録が追いついておりません、Togetterさんのまとめで合わせて様子をご確認下さい！！
前半に、ご自身が作成されたライブラリの紹介と、その着想、ライブラリ化・オープンソース化する姿勢についてお話がありました。
「Motivation based library abstraction 必要は発明の母 ~ライブラリがなければ作ればいいじゃない！ #tryswiftconf」をトゥギャりました。 https://t.co/YEo4hXsPRr
— トゥギャッター開発まとめ (@tg__dev) 2016年3月4日
京都に住んでいます、遊びに来て下さい。案内します。
小さなSwiftのライブラリを作ってきました。 ”必要は発明の母”
3つの事例を紹介します。
UTIKit
ブログには綺麗な写真を載せたいと思います。でも色んな種類があってJpegやPNGをアップロードする時に、MIME Type が必要です。
iOSにはUTIがあり、AppleのOSの中でファイルのタイプを示します。
UTIからは拡張子を取り出すことが出来て、UITypeCopyPreferredIdentifierForTagという関数でファイルタイプを取得できる。でもちょっと難しいのでUTIキットを作りました。
MIME Typeから拡張子を取得するのは沢山コードが必要ですが、UTIKitを使えば、1行で取得可能です。
例えば、jpegという拡張子とMIMEType "image/jpeg"と比較できます。Equitableを実装しています。
jpegは画像ですが、準拠によって画像かどうかを確認することが出来ます。
このようにして、UTIKitではSwiftらしいインターフェースでUTIを扱えるようにしました。およそ考えられるすべての操作が可能です。
これを作ったことで正しいフォーマットでブログアプリで画像をアップロードできるようになりました。
HUDKit
似たようなものでHUDKitという物を作りました。
ブログ記事を書いてデータを送信したら、ユーザーはすぐに見たいかもしれないが、ちょっとまって貰う必要があります。
そして、シェアしたいので、投稿が完了したらSNSにシェアしませんか？と出したいと思う
そういった2つの機能を提供します。
(※記録復活)
文字列でパスの制約を記述してマッチャーで適合したか、そしてパラメータを受け取れる。
パスマッチャーでは＊や{name}など、パターンマッチを利用できる。
WEBでは、GetやPostで条件を分けたい場合がありますが、そういった記述を出来るようにしました。HTTP1.1の定義を表しています。
組み合わせてこのように出来ます。
これで同じコードを繰り返し書く暮らしから開放されます。
これらは全て自分が直面した問題の解決のために作りました。
一般化可能だと考えてライブラリに切り出しました。
どういうことがしたいかというと、問題を抽出して一般化して再利用可能にしたい。
@IBDesignableもそう。
デザイナは行間にこだわりがある。NSAttributedStringを使いますが、@IBInspectableなどを使って、デザイナが直接設定できるようにすることが出来ます。この実装はそのままライブラリにするには乱暴ですが。
まさに今朝Acceptedになった
NSPrefixはまだ残ったりしています。
プロパティビヘイビアがAppleのエンジニアから提案されています。プロパティのdidSetなどと同じ仕組で取り扱えるようにしようというもの。もっといろいろ考慮すべきものがあるのではないかと、改訂が求められている段階です。
SwiftPackageManagerでは言語のコードを混在させられるようにするというProposalがAcceptedです。
これらは新しいライブラリのヒントになると思っています。
いま解決を待っている潜在的な問題がたくさんあることでしょう。
誰かの要望を叶えるアプリを作ることが私たちのやることです。
まずは素晴らしいアプリを作り、もし、他の人にも役に立つことがあったら、ライブラリを作ってコードをシェアすると良いと思います。
世界を良くしたいですね
私からは以上です。
QA
ライブラリを描く時に自分たちが必要な物から作ると思うが、オープンソースにする時に一般化が必要だと思います。どのタイミングで行いますか？
直感に頼っていて、普通にソフトウェアを書く時に、今何かしている問題のドメインが何処にあるか意識せざるを得なくて、クラスを一つ作るにも、それが何のドメインに属するのか考えなくてはいけなくて、そのドメインが、自分のプロダクトに重要なドメインではなくて、別なところにあると思ったら、それはライブラリ化するチャンスだと思っています。
私もライブラリを公開していて、モチベーションが最初はあるが、自分が使わなくなるとモチベーションがなくなって、どう対処するだろうかと思いました。私はモチベーションが下がっているものにPullRequestが来たら、嬉しい半面面倒に感じる。どう対処したら良いか？
モチベーションが自分にも他の人にもなければ、誰にも有用ではない。でもPullRequestが来たら、その人にはモチベーションがある。わたしなら、じゃあ全部お願いしますと、あげちゃいます。
先ほどのライブラリとかは、会社で、企業で、アプリを作っている時に作ったのかと思ったが、はてなとしてはどのようなスタンスか？会社として作ったものをオープンソース化するときに気をつけていることは？
ガイドラインでオープンソース化が推奨されていて、仕事で作ったものは、相談して、コピーライトにHatenaと載せて、自分の名前とはてなの名前で、自分のリポジトリで公開していいということになっている。 でも他の会社から受託で作った時は、私たちには権利がないので公開できない。でもそ言う言う時には、予想して、日曜日にライブラリを書いて公開します。そして、必要になった時に、「あ、そうだ、いいライブラリがあった」といって使います
(会場拍手)
ライブラリ作成に関する知見を得た #tryswiftconf
— snoozelag (@snoozelag) 2016年3月4日
デザイナとの協業を考えると@IBDesignableの駆使はありなのかもしれんね #tryswiftconf
— Tsuyoshi Yonemoto (@yoneapp) 2016年3月4日
モチベーションの話はめっちゃわかる・・・ #tryswiftconf
— 宇佐見 公輔 (@usamik26) 2016年3月4日
