5.1さらうどん

@giginetの技術ブログ。ゲーム開発、iOS開発、その他いろいろ

PyConJP 2016で『はじめて作るDjangoプラグイン』というトークをしました #pyconjp

こんにちは。@giginetです。 このたび、9/21, 9/22に開催されたPyCon JP 2016において、『はじめて作るDjangoプラグイン』という発表をさせていただきました。

詳細は以下。

giginet.hateblo.jp

内容としては、上記の記事で紹介しているようなプラグインの開発・保守管理の経験を生かして、 Pythonライブラリのテストやドキュメンテーション、デプロイなどの開発手法をお話ししました。

スライドは以下です。

なんと、録画も配信されています。

ご興味のある方は是非。僕は恥ずかしいので見直していません。

以下、お気持ちなので読まなくて大丈夫です。

発表してみて

とにかく、準備が大変だったの一言に尽きます。

CFPが採択されたのは6月中旬で、丸3ヶ月以上時間があったのですが、 あれこれ構成を考えていたり、下調べをしていたり、既存のライブラリに手を加えていたりで、めちゃくちゃ時間を使いました。

45分の発表時間分のスライドを作るのはもちろん大変だし、発表練習も何度かしたので非常に大変でした。

直前までできていないと焦るタイプなので、10日前には全てスライドと台本はできあがっていたんですが、当日まで落ち着かなくて非常に疲れたので、終わった後のやりきった感は格別でしたね。

一つ言えることは、あんまり根を詰めて準備すると疲れてしまうので、「俺の発表が酷くてもCFPを通した運営が悪いのであって俺は悪くない!!!」ぐらいの気持ちで準備すると心が軽くなってよかったです。もちろん、手を抜いたつもりはありませんが。

個人的には話したいことはすべて話せたし、練習しただけあって、発表自体は全力でできたんじゃないかと思います。

とはいえ、反省の多く残る発表になりました。

まず、テーマ設定というか、タイトルがニッチだったので、お客さんを選んでしまったこと、浅く広く話しすぎてあんまり実装に踏み込めなかったことなどは気にかかっています。

あと、僕は仕事でPythonを使ってるわけでもないし、モバイルアプリやってたり、なぜかゲームの本を書いていたりして、ちょっといろいろやりすぎていて、やはり専門的にやってる人との知識量とか経験の差みたいなのをまざまざと感じたので、もうちょっと一つのことを集中して突き詰めた方がよいなと思いました。

と反省点は多かったんですが「知人が絶賛してた」、「網羅的にまとまっていてよかった」、などの声も聞こえたし、発表してよかったと思います。

PyCon 2016について

今年のPyConは5トラックもあって、扱われているテーマやレベルなどが広く、誰もが楽しめるカンファレンスだったんじゃないかと思います。 やはりPythonの言語の特性上、研究者が多いので、懇親会などでも物理学や、天文学、気象学とか、いろいろな学問の人が集まっていて面白かったです。

去年はPandasやJupyter Notebookといった、データ分析系の分野の勢いを感じたのですが、今年はやはりディープラーニング界隈が盛り上がってましたね。 最近趣味でディープラーニングの勉強を始めていたおかげで、理解が捗ってよかったです。(近々それについての記事も書きたい)

TensorFlowとかもそのうち触ってみたいけど、技術的な興味はあっても、解決したい問題に対するモチベーションがあんまりないというのが悩みです。

反面、同時に5トラックもあって、見たかったのに見れなかったトークがたくさんあったのが残念なところ。 幸い、全て動画が公開されているようなので、そのうち見返したいと思います。

PyConはいいぞ

過去4年出ているのですが、今年は規模も最高だったし、会場も広かったし、基調講演も豪華だったし、Pythonの勢いを感じました。モチベーションも上がった。 運営の皆さん、ありがとうございました。

特に今年はスピーカー懇親会にも参加したのですが、スピーカー懇親会はやはりハイレベルで、いろいろなOSSのコミッターがゴロゴロいるみたいな感じで割と場違い感を感じていました。 スピーカーになると、人見知りでも他の人と話しやすいので、準備は大変だけど、軽い気持ちでCFPを出してみるとよいと思います。

現場からは以上です。

PyCon 2016でPythonのライブラリ開発についてトークします

pycon.jp

こんにちは、@giginetです。

9/21, 9/22に行われるPyCon 2016で『はじめて作るDjangoプラグイン』というタイトルでトークをすることになりました 🎉

PyConには毎年参加していて、今年で4年目。 そろそろCFPでも出してみるか〜と思って、話せそうな内容で適当に出してみたら通ってしまって、今泣きながら準備しています。

仕事ではもっぱらSwiftかObjective-C、もしくはRuby on Railsを書いていて、Pythonはアマチュアです。 とはいえ、Djangoは趣味雑アプリケーションを運営したり、バージョン1.1ぐらいから最近でも書いていて、それなりに知見が溜まってきました。

例えば、以下のような小さいプラグインを何個か作っていたり

giginet.hateblo.jp

友人のid:lambdalisueが開発しているdjango-permissionやdjango-inspectional-registrationのメンテナーをやってたりします。

github.com

github.com

Djangoプラグイン」というタイトルですが、Djangoプラグインを題材にするだけで、テスト手法やPython2/3の両対応などの話をするので、広くライブラリ開発全般に役立つことを願っています。 Pythonのライブラリ作成、調べてもあんまりまとまっていたり、知見が少なくて困っていたので、興味のある方はぜひお越しください。

内容的には去年Qiitaに似たような物を書いています。 qiita.com

ちなみに、カンファレンスと呼ばれる所で話すのは、意外にも今回が初めて。 せっかく東京に出てきたのに、人見知りなのでここ1年ぐらいほとんど勉強会とかにも行ってないし、久しぶりに話すことになるので緊張しています。

現場からは以上です。

UITextFieldに簡単にカスタムキーボード貼るライブラリ作った+iOS UIライブラリのCI改善の話

最近、Swiftでライブラリを作るのが趣味なgiginetです。

最近は仕事でもSwiftを使う機会が多く、金曜の夜に仕事でアプリを作っていたら、突如良い感じの実装になってきたので、週末のやっていきでライブラリが誕生した。

github.com

CustomKeyboardTextField

CustomKeyboardTextField は、カスタムキーボードが貼り付いたテキストフィールドを簡単に生成できるライブラリ。

デモアプリはAppetize.ioに上げてあり、↓で動作確認ができる。

こんな感じで作った動作デモをシュッとブログに埋め込んで使ってもらえるの最高の時代だし、実機実行はもはや時代遅れだから今すぐiPhoneを投げ捨てるべき。

アピールポイントとして、Genericsなどを使ってゴリゴリしているので、簡単に型安全なTextFieldのクラスを生成できる。 よく使うであろうPickerを貼るだけのTextFieldであれば、以下のように一瞬で実装できる。

import CustomKeyboardTextField

struct PokemonPickerKeyboardDataSource: UIPickerViewKeyboardDataSource {
    let elements = ["Bulbasaur", "Charmander", "Squirtle"]
}
typealias PokemonPickerTextField = PickerKeyboardTextField<PokemonPickerKeyboardDataSource>

typealiasで簡単に新たなTextField型を生み出せるのがミソで、上記のように最初の3匹を選ばせたいときなんかは役に立つと思う。

サンプルアプリにあるように、画像を埋め込んだちょっとリッチなピッカーにしたり、一番下の雑ゲームパッドのように完全に独自のUIViewを埋め込むこともできる。

実用的な例で言うと、例えばiOS上でユーザー登録フォームを作っていて、誕生日や性別の選択などのフォームを実装したいという時なんかに使えそう。詳しくはREADMEをどうぞ。

気に入ったら是非 ⭐️ スターをお願いします 🙏

UIライブラリを作ってみて新たな知見

最近はSwiftライブラリ作成マンとして活動しつつあるため、ライブラリの作り方などは何度かブログ記事に書いた。

giginet.hateblo.jp

giginet.hateblo.jp

しかし、UI作るのが面倒であまり好きではなくて今まで作ってこなかったので、今回はUIライブラリ用の知見を何個か紹介したい。

Travis CI+Fastlaneで自動的にAppetize.ioにデプロイする

冒頭に埋め込んだ動作デモはAppetize.ioという、ブラウザ上でiOS/Androidアプリを実行できる素晴らしいサービスを使っている。

今回は、Travis CIでサンプルアプリをビルドして、Fastlaneを使って、自動的にAppetize.ioにアップロードするようにしてみた。

実は以前、この仕組みはこのブログでも紹介していて、今回も以前送ったPRが元になっている。

fastlaneを使ってiOSアプリをブラウザから爆速確認できるようにした - 5.1さらうどん

今回改めて調べてみたら、この記事を書いた時代からいろいろと進化していて

  • Appetize.ioのAPIが進化していて、直接アプリをアップロードできるようになった
    • 以前はどこかにアップロードしておいてURLを参照する形だった
  • Fastlaneにzipアクションやbuild_and_upload_to_appetizeというそのまんまなアクションが追加された

これらを使うと、わずかこれだけでシュッと実装できてしまう。

platform :ios do
  desc "Deploy demo application to Appetize.io"
  lane :deploy_to_appetize do
    build_and_upload_to_appetize(scheme: 'DemoApp', xcodebuild: {project: 'DemoApp.xcodeproj'})
  end
end

これを使ってFastlaneを実行するだけで↑みたいなのが簡単にデプロイできる。

$ fastlane deploy_to_appetize

他に必要なこととしてTravis CIには、セキュアな値を暗号化して環境変数にできる仕組みが実装されていて、それを使ってAPIキー各種をセットしておく必要がある。

$ travis encrypt APPETIZE_API_TOKEN=yourapitoken --add
$ travis encrypt APPETIZE_PUBLICKEY=yourpublickey --add

今回はデフォルトで用意されたアクションを使わずにgitのコミットログを一緒に送るようにしていたりとか若干改良している。 興味のある方はFastfileをどうぞ。

Xcode7.xと8系で同時にテストする

この時期はWWDC後で、現行のバージョンとβ版両方を考えないといけないiOS開発者にとって憂鬱な時期。

とはいえ、以前と比べて大体のことはいろいろな手段で解決できるようになっていて、Travis CIのmatrixの仕組みを使えば複数のコンテナを立ち上げてXcode7と8で同時にテストを実行できる。

f:id:gigi-net:20160808010714p:plain

これを利用してSwift 2.2と2.3両方に対応している。

たまに標準ライブラリの型が変わっていたりして、トリッキーなコードを書く必要があったりするけど、2.2と2.3はほとんど文法的に互換性を保っているので、Xcode8.0で設定を済ませるだけで大体の場合は簡単に2.3対応が行える。

今後3が出てきてからどのように複数環境でテストしていくかという知見はまだない。 ただ、2.x系は今後早々と切り捨てられそうなので、近いうちに3以外は考えなくても良い世界が到来しそう。

UIライブラリのユニットテスト

UI系のライブラリはテストを書きづらく、テストがない場合も多いんだけど、申し訳程度にユニットテストを書いた。

本来はXCUITestなどを使って、しっかりUIテストを書くのが望ましいんだろうけど、面倒でそこまでちゃんと書いていない。 気が向いたらUI Testも増やしてみたい。

感想

ライブラリをいろいろ作ってみて、Protocol Orientedな設計が大分わかってきた気になってきたけど、実は良くわかってなくてまだまだ勉強が足りていないのを痛感する。

他に作ったライブラリも含め、興味があったらぜひご利用ください。

github.com

github.com

github.com