ペンギン村 Tech Blog

技術をこよなく愛するエンジニア集団が在住するペンギン村から、世界へ役立つ(かもしれない)技術情報を発信する技術系ブログです。某アラレちゃんが済む村とは一切関係ありません。んちゃ!

Swift 4.2 の変更点を iOSDC 2018 で話してきました

どうも、最近は「進撃の巨人 3期」が楽しみな tobi462 です。

しかし、最近一部の人達から「シュタインズ・ゲート ゼロ」を強烈に推されプレッシャーを感じる今日このごろです。いや原作こそ未プレイですがアニメ初期は見てますし、全話配信されたら見ようと思ってはいたんですよ?

レギュラートーク30分

はい、ということで iOSDC Japan 2018 にて 30分 のレギュラートークをさせていただきました。

去年は LT で発表させていただいたのですが、今年はレギュラートーク、しかも今までに経験したことがない 30 分の発表ということで、資料作り・発表練習ともに苦労した面も多いのですが、良い経験が出来たと思います。

正直なところを言うと、こんな平凡な(あるいは中身の透明性が高い)テーマを聞きに来る人はいないのではないかと思っていたのですが、予想に反して聞きに来てくれた人が多かったので嬉しかったです。

このテーマであれば後で資料を見れば十分だ、と判断された方も多いのではないかと思います。少なくとも私が参加者であればそういう判断をしていたと思います(苦笑)。まぁしかしスライドの出来はわりと良いと自負しているので、参加されなかった方もよろしければご覧いただければと思います。

今年の iOSDC

f:id:yu_dotnet2004:20180903003226p:plain

正直なところ「疲れた」というのが一番の感想でしょうか(笑)

登壇も含めて 3.5日 という日程はさして生易しいものではなく、もう若くない私としては日に日に消耗していた感もあります。 (ええぃ!スタッフの体力は化物か!)

しかし、イベントの質としては明らかに去年よりパワーアップしていました。とくに、

  • ルーキーズLT、iOSエンジニアに聞いてほしいトーク
  • Wifiネットワークの高速・安定化、無限コーヒー

といった点は非常に良かったと私は感じました。

初心者でも登壇しやすい空気を作りつつテーマの幅を広げ、イベント参加者がよりイベントを楽しめるようにする仕組み、ということを実現したスタッフの方々には頭が上がりません。

異なる関わり方

今回、iOSDC を陰ながら応援しようと思い、CfPの検索サービスを「ペンギン村 Tech」の一部の有志で開発しました。

blog.penginmura.tech

実は iOSDC 最終日に GCP の無料枠を使い果たしサービスダウン しているのですがそれはさておき。

当初、CfP の一覧を快適に見られるようにし、興味のあるトークを見つけやすくすることで、開発者の興味があるトークをSNSやブログでシェアしやすいようにするという狙いがありました。

今年は CfP が(たしか) 540 本も提出されたのですが、公式のプロポーザル一覧は検索もなければ10件ごとのページングによる画面遷移が必要で、とても興味があるトークがSNSでシェアされるようなUXが提供されているとは感じられなかった為です(そもそもプロポーザル一覧のページさえ見つけられない人もいたのではないかと思います)。

それゆえにこのサービスの企画初期の時点から SPA で開発することは決定していました。

この取り組みが功を奏したのかは実際のところわかりませんが、Twitterでは「役に立った」というコメントをいくつかいただけ、間接的ながらイベントに関わることが出来たのではないかと思います。

実のところ「API提供」や「iOS/Androidアプリの提供」も視野に入れていたのですが、開発メンバー3名のうち2名がレギュラートークに登壇することもあり、リソース的にそれは叶いませんでした。このあたりは来年(もありますよね?)、改善していけたらと思ったりします。

終わりに

まぁ、つまるところ「楽しかった!」です(笑)

私は基本的に人見知りで、こういう場でのコミュニケーションが苦手なのですが、発表・聴講・スピーカーディナーなどを通じて多くの開発者とコミュニケーションが取れて嬉しかったです。

私自身が iOS アプリ開発からしばらく離れていることもあり、他の登壇者のトークではとても多くのことを学べたと感じます。

そんなわけで関わってくれた多くの人に感謝の意を示しつつ、来年もまた楽しみにしています。 f:id:yu_dotnet2004:20180903003150p:plain

では。

iOSDC2018に参加してきました!

ども、かむいです。

 

僕は今回iOSDC初参加でした。
以前から行きたかったのですが、お仕事が…参加費が…CfPが…ごにょごにょ


そんなこんなでCfPは見事に不当選だったものの、ついにスポンサーチケットという素晴らしいアイテムを駆使して参加することが出来ました!


f:id:kamui_project_tony:20180902195937j:image


行った感想ですが、マジでハッピーな4日間でした!!


普段の勉強会でも参加するだけで刺激を受けるというのに、著名な方や初めてお会いする方、初めて登壇される方々のセッションをずーーっと1日中聴けるという体験は今年一番の思い出になりました。

 

f:id:kamui_project_tony:20180902200004j:image

ランチはどれも美味しかった…


また今回僕の同僚でもあり、31日のルーキーズ枠でも登壇した@hayatanさんの発表は応援する側ながら僕も緊張しっぱなしでした。無事終えられて良かったです。お疲れ様でした!mm
f:id:kamui_project_tony:20180902200031j:image

この人数の前で発表をやってのけるとか…メタルスライム倒した時並のレベリングが出来たに違いありません。


特に彼の発表テーマであった設計の話は、今彼と一緒に死にそうになりながら取り組んでいることの内容でして、その成果を以下の著名な方々に評価して頂けたことは彼と同じくらい僕も嬉しいツイートとなりました。

 

 

 

 

なお、前回の記事にもあった通りペンギン村から2名が参加し、彼らの勇士もしっかり見届けることが出来ました。きっと彼らからも思いの丈が追って聞けることでしょう(チラッ


最後に、参加された方々は(ほぼ)iOSエンジニアで、同じ苦労をされてる人たちとお話できたのはとても良かったです。
普段勉強会でお会いしてる人、改めてどんな仕事をしているか深くお話しできた人、はじめましてな人。
ここまで繋がりを多く持てるイベントもiOSDCならではなんだなぁと思えました。


また来年こそは、CfP投げまくって、登壇を勝ち取りたいと思います!


f:id:kamui_project_tony:20180902221541j:image

 

運営スタッフの皆さま、登壇・参加された皆さま、登壇頑張った同じ村民のtobi462さんk_miyasakaさん、そして自分、乙!!!

ペンギン村 Tech から 2名 が iOSDC 2018 に登壇します

f:id:yu_dotnet2004:20180829182353p:plain

どうもご無沙汰しています tobi462 です。iOSDC Japan 2018 の開催がついに明日にせまりましたね。

以前の記事で軽くふれましたが、ペンギン村 Tech からは私と k_miyasaka の2名が登壇します。

blog.penginmura.tech

せっかくなのでトークに対する一言コメントを紹介したいと思います。まぁお約束的な感じですね(笑)

Swift 4.2 はどのような進化をしているのか

  • tobi462
  • 2018/08/31 11:20〜 Track B レギュラートーク(30分)

Xcode 10 から Swift 4.2 に変更となりますが、変更点のチェックはお済みでしょうか? CfPを出す現時点で Swift 4.2 には 18個の Proposal が実装されています。 本トークでは時間の許す限りで、すべての Proposal についてその解説を努めていきたいと思います。

https://fortee.jp/iosdc-japan-2018/proposal/a355f634-3855-40ff-882e-328704bd6136

一言コメント

コメントするまでもなく内容が透けて見えるトーク概要ですが(苦笑)、30分という短時間でプロポーザルをざっと駆け巡って「効率的にキャッチアップしてもらう」というのを目標にしています。

ただ、それだけだと味気ないと感じたので 今までの Swift の歴史を振り返ってみた上で、Swift 4.2 がどのように進化しているのかという構成にしてみました。

30分という短時間で多くを語ることは出来ませんが、楽しんでもらえたらと思っています。

果たして30分以内に本当にすべてを喋り切ることができるのか、それもあるいは見どころの一つかもしれません(が、がんばるぞい・・・)

LLDBを最大限活用してみる。

  • k_miyasaka
  • 2018/09/02 15:10〜 Track B レギュラートーク(15分)

XCODEのデバッグ機能は便利で、スタックトレースとpoコマンドの入力だけでもゴリゴリとデバッグできる方が多くいらっしゃると思いますが、 それらはLLDBの機能の氷山の一角です。 不具合の原因検知、修正だけでなく、 リビルドせずにコンソールからUIを変更するなど新規コーディングでも活用できる方法を発表致します。

https://fortee.jp/iosdc-japan-2018/proposal/db9e05a4-2357-4140-8274-c642e158f1d9

一言コメント

現在のSwiftはOptional Bindingやenum、structなど、静的に安全を保障できる機能が多々あります。

その反作用として、デバッグ実行時の操作のの自由度はObjective-Cに比べると格段に下がっています。

プログラミングはデバッグの時間が大半を占めるといわれているので、Swiftのデバッグ手法については改善の余地が多々あると思います。

今回はLLDBのもつ無限のポテンシャルを生かし、そのいくつかの手法、方針を提案させていただきます。

おわりに

そんなわけで、登壇者からの一言コメント紹介でした。

あとは皆様との機会があえば当日の発表でお会いしましょう。(べ、べつに私達のトークを聞きに来てほしいってわけじゃないんだからね///)

では。

iOSDC 2018 のプロポーザル一覧を閲覧できるサービスを公開しました。

この度、ペンギン村 Tech のエンジニア3名で iOSDC 2018 の プロポーザル(CfP)一覧を閲覧・検索できるサービスを公開しました! iosdc-cfps.penginmura.tech

f:id:yu_dotnet2004:20180723234118p:plain

Web UI は SPA で開発し、画面遷移なしで快適に見られるようにしてみました。

1stリリースでは一覧表示のみでしたが、現在では採択ラベルの表示・フィルタリング・キーワード検索にも対応しており、今後も少しずつ改善していきたいと思っています。

なぜ作ったか?

これは私個人の話になるのですが、私は去年 LT を採択され iOSDC 2017 にて登壇させていただきました。 iosdc.jp

参加して感じたのは、カンファレンスをより楽しいものにしようとするスタッフ達の想い・情熱でした。

そんなわけで「来年はスタッフをやるぞ!」と意気込んでいたのですが、ふとプロポーザル一覧をもっと手軽に見れたらいいのにと思い、仲間内の Slack で以下の発言をしました。

f:id:yu_dotnet2004:20180717020254p:plain

そんな雑な振り方から始まり、賛同してくださった仲間と開発を始め、気づけばリリースしていたというわけです。

インフラ

サービスは GKE(Google Kubernetes Engine)上に構築しており、ゼロダウンタイムでのアップデートを実現しています。

なぜ GKE を選択したかを始め、どのような技術を利用したかについては今後記事にしていきたいと思っています。

まぁ、ペンギン村で Kubernetes入門 の輪読会を始めたのが影響しているのは間違いないでしょうか。 blog.penginmura.tech

まとめ

そんなわけでサブタイトルは「iOSDC 2018 応援サイト」として、こんな我々でもiOSDCを応援できたら「それはとっても素敵だな」という感じで作らせていただきました。(アニメネタを自重できない

幸いにも今年の iOSDC 2018 でも CfP が採択され、今回の開発メンバーである私 tobi462k-miyasaka が登壇させて頂く予定です。

Swift 4.2 はどのような進化をしているのか by Yusuke Hosonuma | プロポーザル | iOSDC Japan 2018 - fortee.jp

LLDBを最大限活用してみる。 by k_miyasaka | プロポーザル | iOSDC Japan 2018 - fortee.jp

今年も楽しい iOSDC になることを心から願っています。

We believe in iOSDC 2018.

Xcode 10 betaにおけるSource ControlとAsset Catalogの新機能のお話

f:id:kamui_project_tony:20180701181028p:plain

はじめに

ども、かむいです
気がついたら2018年も7月に突入してますね(´・ω・`)
投稿がご無沙汰だったので、先月弊社で登壇したイベントがあったので、その話について書きたいと思います

WWDC18報告会 in 弊社

dmmcj.connpass.com

当日はまさかの申込数約200人と大変注目を浴びたイベントとなりましたmm
登壇1番手として変なプレッシャーもあったり(´・ω・`)

そんな中で発表した内容がこちら
https://speakerdeck.com/tony1224/wwdc18-cherry-pick-xcode-10-beta

WWDC18 cherry-pick Xcode 10 beta

というお題目で発表しました
ただXcode絡みのテーマのセッションは複数あったので、その中から

  • Source Control Workflows in Xcode

developer.apple.com

  • Optimizing App Assets

developer.apple.com

の2つについて話しました

Source Control Workflows in Xcode

XcodeにあるSource Control機能がパワーアップしたよ!というお話
具体的には

- Git上の差分をエディタ上に表示
    - 色線で変更行, 競合行が色分けで表示される
- GitLab, Bitbucketもサポート対象に追加
- pullボタンで--rebaseオプションを設定可能に
    - チェックボックスの初期値設定はPreferenceより変更可
- Xcode上でSSHキーの登録, 更新ができるようになった

ていうもの
競合箇所は競合した行のコミッター情報とか、競合した箇所の修正対応(こちらの変更を取り消す, 競合差分を見る)とかもできたりしてより便利に
ちなみにXcodeの3大競合あるあるファイル

- .storyboard
- .xib
- .pbxproj

ではこの機能に反映されては無いようでした
ただここは素直にPull時に指摘される箇所ではあるので、その時点で解消できれば問題ありませんね

ちなみに僕のプロジェクトでは .pbxproj の競合についてはXcodeGenで対処する予定です
まだ実際に使い倒してみての選定ではないため、完全に熟知したタイミングで僕も記事を書こうと思っています

qiita.com

Optimizing For Assets

Asset Catalogの中がパワーアップしたよ!というお話
ただiOS12における新機能はセッションで話された4項目のうちの1項目のみだったので、その項目のみ話させてもらいました
(10分LTだったので意図的に省いてしまったのもありますが)

ちなみにXcodeの話ちゃうやんけってツッコミがあるのですが、Asset Catalogだしまぁいいよねて魂胆です

Session Talk1: Apple Deep Pixcel Imgae Compression

ていうのが今回iOS12から追加されました
Asset Catalogに格納されているリソースをiOS12端末にインストールする場合、これまでと違い最大20%※のサイズダウンを実現させてまっせというもの
※色や画像など、全てをAsset Catalogでまかなっていた場合による差分値なのではという推測です
(セッションでもここについては言及してませんでしたが、自分のアプリで検証済)
そのため画像のみの管理で20%のサイズダウンを発揮できるものでは無さそうです

iOSerの方々はどのあたりまでAsset Catalogを活用されてますでしょうか?

僕は個人アプリの場合

  • 色: 🙅‍♂️ColorUtil.swift とか作って定数で管理。Asset CatalogのColor SetもiOS11からしか使えないというバージョン都合もあったり
  • 動画/音源: 🙅‍♀️ Data Setで入れられるんですよね。まだ対応できてませんでした(´・ω・`)

dev.classmethod.jp

  • 画像: 🙆‍♂️ ただVector使えてなかったり解像度も2xのみだったりしてました

結論: 20%のサイズダウンは出来ずorz

なので諸々のリソースをAsset Catalogに突っ込んでいくと、今後は良いことがあるよという話でした
色はiOS10をカバーするかどうか問題が残るので、チームで相談してみても良いかもしれません

Session Talk3: Cataloging - Namespace

f:id:kamui_project_tony:20180701175919p:plain

最後にこちら発表では話せなかったネタを1つ
Swiftでは相変わらず名前空間が無いよ状態なんですが、Asset Catalog上では名前空間は使えるんですよ奥さんってのを発表されてました
R.swiftも使ってこれを活かせるとかなり便利だったので、僕のプロジェクトでもこれを活かしていく予定です

実装方法もすでにまとめられてる方がいましたので紹介させて頂きます

qiita.com

さいごに

とにもかくにも、発表疲れました(´・ω・`)
当面は勉強会で登壇予定はないものの、8-9月に行われるiOSDC2018にCfP出しました
当選されることがあれば、次回はそのあたりかなと思ってます

ただ申込数半端ないって!多すぎて締め切りのアディッショナルタイムが8時間やもん!そんなん出来ひんやん普通!

なので落ちてもリジェクトコンにすら受かるか怪しい
その場合は技術書典5に申し込んだので、そこで改めて本の形で発表したいッス

え、そこも落ちるの?(´・ω・`)
泣いちゃうよ?(´・ω・`)

Dockerハンズオンをやってみた - Kubernetes輪読会#0

どうも、Nintendo Switch版の斑鳩が配信されるの楽しみな tobi462(過去記事) です。

斑鳩はSTGとしての面白さは当然のこと、硬派なストーリー設定も素晴らしく・・・おっとこれを語りだすと長くなるのでやめておきましょう。

Kubernetes輪読会

さて、ペンギン村のエンジニア数人で Kubernetes の輪読会をすることになりました。

輪読会の対象となる技術書は以下です。

Kubernetes は Google が公開した OSS のコンテナオーケストレーションツールですが、GCP(Google Cloud Platform) に続いて、AWS(Amazon Web Service)も公式にサポートし、実質的にコンテナオーケストレーションツールの標準として君臨したと言えます。

オーケストレーションとは、負荷に応じてコンテナの数を変更して負荷分散を図ったり、アプリケーションの差し替えを用意にしてくれる仕組みのようです。つまり、コンテナ単体では面倒だったことをいろいろサポートしてくれるようです。(このあたりの理解は怪しいです、なにせこれから輪読会を通じて学ぶのですから)

始動 #0

さて、そんなわけで始めることになったのですが、ペンギン村のエンジニアはモバイルに属しているエンジニアが殆どなので、実のところ Kubenetes 以前に Docker についてもあまり馴染みがありません。

そんなわけで初回は #0 ということで、Docker の勉強会的なものをやることになりました。さすがに Kubernetes などのオーケストレーションを理解する前に Docker などのコンテナ技術の基礎は必須だよね、という流れです。

今回は Docker についてある程度知識がある tobi462(過去記事) がハンズオンを開催することで、 Docker やコンテナ技術の基本的なところを理解しあおうという事になりました。

コワーキングスペース

というわけで初回は以下のコワーキングスペースを利用させていただきました。

co-forest.com

コワーキングスペースによっては静かで喋りづらい雰囲気もあったりするのですが、ここは「会話OK」と紹介されていてディスカッションもしやすそうだったので選ばせていただきました。

打ち合わせっぽい会話が聞こえてきたりもしますが、決してガヤガヤしすぎて集中できないというレベルではないのでなかなかバランスの取れた場所なのかなと思います。以前は Swift の TDD を検証するペアプロでも利用させていただいており、こういったディスカッションしつつ何かをやりたいときには絶好の場所だなと感じています。

今回、#0 を開催して結構気に入ったので、今後の輪読会もここで開催していこうかという話になっています 。(他にも良い場所があったら是非教えてください)

Docker ハンズオン

さて、そんなわけで今回のメインコンテンツである Docker ハンズオンです。

外部ディスプレイに映して、それを見ながらやってもらおうと考えていたのですが、ディスプレイケーブルを忘れてしまったので Slack に随時書き込みながら進める形にしました。

実際には口頭で補足説明もしながらだったので、文章にすると多少情報は欠けてしまうのですが、せっかくなので記事に書かせていただこうと思います。

インストール

最初に以下をインストールしてもらいました。

実のところ Docker のハンズオンとしては後半2つは不要なのですが、ハイパーバイザ型とコンテナ型で起動速度の違いを実感してもらおうという意図と、便利だからせっかくだし入れちゃおうぜみたいな感じで一緒にインストールしてもらいました(おぃ

Docker 入門

講師:
 まずは伝統の Hello world からにしましょうか。ターミナルで以下のコマンドを叩いてみてください。

$ docker run hello-world

講師:
 なにやらダウンロードされた後に Hello World 的なものが表示されたと思います。 docker run は指定したイメージをコンテナとして起動するコマンドで、今回は hello-world というイメージ名を指定しています。Docker は指定したイメージがなければ自動的に Dockerレジストリからイメージをダウンロードして実行してくれる仕組みになっています。

 さて、今回の起動したコンテナを見てみましょう。

$ docker ps -a
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS                     PORTS               NAMES
1b0a41707472        hello-world         "/hello"            2 minutes ago       Exited (0) 2 minutes ago                       hungry_lovelace

講師:
 -a は終了したコンテナも表示するというオプションで、今回のように Hello world を出力した後に終了するコンテナを表示する場合には指定が必要になります。

 出力されたカラムの意味は以下のとおりです。

カラム 説明
CONTAINER ID コンテナの一意なIDで、自動的に振られる
IMAGE どのイメージをもとにして生成されたコンテナか
COMMAND なんのコマンドが実行されたか
CREATED いつ生成されたか
STATUS どういう状態か。今回は Exited で終了していることがわかる
PORTS ポートの設定が表示されるが、今回は関係ないので表示なし
NAMES コンテナの名前。生成時に指定することも出来るが、そうでなければ自動で振られる。コンテナIDの代わりに使用できる

参加者:
 CONTAINER IDNAMES は起動ごとに変わってるみたいですね。

講師:
 そうですね、同じ Docker Image からいくつでもコンテナを作れるようになっています。これはオブジェクト指向における クラスオブジェクト の関係と考えると分かりやすいかもしれません。

講師:
 せっかくのでイメージの一覧も見てみましょう。

$ docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
hello-world         latest              e38bc07ac18e        6 weeks ago         1.85kB

 それぞれのカラムの意味は以下のとおりです。

カラム 説明
REPOSITORY イメージ名
TAG イメージにつけられるタグで、例えばバージョンを指定できたりします。例えば Swift というイメージがあって、 TAG としては 4.04.1 などに複数あるイメージです。つまりタグを使ってバージョン違いも共存可能ということです。
IMAGE ID イメージの一意なID
CREATED いつ生成されたか
SIZE 最終的なイメージのサイズです。最終的というところがポイントで、ベースのイメージは共有されるようになっています。Gitのコミットグラフにおける親コミットをイメージいただけると分かりやすいかもしれません。

講師:
 さて次にイメージの削除を試してみましょう。

$ docker rmi hello-world
Error response from daemon: conflict: unable to remove repository reference "hello-world" (must force) - container a1ad796bab25 is using its referenced image e38bc07ac18e

 エラーになったと思います。これはそのイメージから作られたコンテナが存在する場合には、警告としてエラーになるようになっているためです。ちなみに rmi の最後の iimage の略だと思います、少なくともそう考えておくと分かりやすいです。

講師:
 ではコンテナを先に削除してみましょう。コンテナのIDの調べ方は・・・ docker ps でしたね、自分の環境にあわせて変更してください。

$ docker rm a1ad796bab25

 何回か起動した場合は複数回必要になるので注意してください。

参加者:
 以下のように複数指定もできるのですね。

$ docker rm 881770fa6d68 6ee4de437fa3
881770fa6d68
6ee4de437fa3

講師:
 全部消したら、先程の rmi をもう一度試してみましょう。今度は消せるはずです。

 うまくいきましたね?

参加者:
 はーい!

講師:
 ところで終了したコンテナを一気に消したいと思う機会は多いはずです。その場合は以下のようにすることで一気に削除できます。

$ docker rm $(docker ps -aq)

 どこかのタイミングで試してみると良いでしょう。-q は コンテナID のみを表示するオプションなので、それで列挙して一気に指定するイメージです。

講師:
 ここからVagrantに移りますが、その前に以下のコマンドでUbuntuを落としておきましょう。

$ docker pull ubuntu

 pull はイメージをDockerレジストリからダウンロードするコマンドです。docker images でローカルにダウンロードされた一覧が見れるはずです。

 試しにTagを指定して pull もしてみましょう。

$ docker pull ubuntu:16.04

 : のあとに指定してるのが Tag で、 docker images でも表示されていたものです。Tag を省略した場合は、 latest というタグが使用されるようになっています。

$ docker images | grep ubuntu
ubuntu              16.04                  0b1edfbffd27        4 weeks ago         113MB
ubuntu              latest                 452a96d81c30        4 weeks ago         79.6MB

 最初にタグなしで pull したものは latest というタグのものがDLされているのがわかるかと思います。

参加者:
 確かに。 Using default tag: latest

<ここで軽くコーヒーブレイク>

Vagrant も触ってみる(ハイパーバイザ型の仮想化を試してみる)

講師:
 さて、コーヒーブレイクが済んだところで(?)Vagrant も触っていきましょう。まずはワークディレクトリを作りましょう。(どこでも良いです

$ mkdir -p ~/Vagrant/Ubuntu_1604

 ワークディレクトリに移動後、以下のコマンドを叩いてみましょう。

$ vagrant init bento/ubuntu-16.04

 そういえば Vagrant の説明を何もしてませんでしたね・・・

参加者:
 Vagrant入門:https://thinkit.co.jp/story/2015/03/19/5740

講師:
 Vagrant は雑に言うと、 仮想環境をCLIで操作できるようにするものです。

 例えば Mac上では、VirtualBox というOracleが提供しているハイパーバイザ型仮想化ソフトウェアがありますが、VagrantはそれをCLIで操ることの出来るものです。

 では以下のコマンドを叩いてVMを起動してみましょう。

$ vagrant up

 ちなみに VMVirtual Machine の略で、すなわち「仮想マシン」です。

 説明が遅くなりましたが、 init したタイミングで Vagrantfile というものが作成されています。

$ ls
Vagrantfile

 これは VM を生成するための料理本(クックブック)のようなもので、ここに設定された内容に従ってVMが立ち上がるようになっています。

 さて、ここで VirtualBox を起動してみましょう。

<という算段だっただが、ダウンロードに時間がかかりすぎたので講師の画面を見せることに>

講師:
 さて、Vagrant up は時間がかかるので先にスクリーンショットを張ってしまいます。

f:id:yu_dotnet2004:20180527205041p:plain

 仮想マシンが Runningになっているのが分かると思います。今回は Vagrant から操作して起動しましたが、VirtualBox の画面から同じことをすることも可能です。しかし、CLIで簡単に VM を立ち上げられるようになっていることが分かると思います。

 以下のようにすることで起動したVMに ssh でログインすることが出来るようになっています。

$ vagrant ssh

参加者:
 なるほど、最近の仮想化ってこんなに簡単になってるんですね。

Docker に戻る(ハイパーバイザ型とコンテナ型の違いについて)

講師:
 では、同じ Ubuntu 16.04 をDockerで起動してみましょう。

$ docker run ubuntu:16.04

参加者:
 は、や、い

<ここからハイパーバイザ型とコンテナ仮想型の違いをメタファを使っていろいろ解説した・・・が、何を喋ったか覚えてないので覚えてる範囲で書き起こし>

講師:
 これがコンテナ型仮想化の強い点で、起動が圧倒的に速いのです。ハイパーバイザ型はハードウェアをエミュレーションするので、実行時のオーバーヘッドが大きいのに比べて、コンテナ型はOSの機能を使ってシミュレートしているイメージで実際にはプロセスとして実行されるようになっています。

 Androidの開発を行った経験がある方は、Androidのエミュレータがすごく重いと感じたことがあると思います。これはエミュレーション、すなわちハードウェアレベルで仮想化しているためで、エミュレータ上で動く Android OS は自身が物理ハードウェアで動いているのかエミュレータで動いているのか区別がつかないのです。

 そう、Matrix のように。

参加者:
 ・・・。

講師:
 はい、面白くなかったですねw

参加者:
 いや、普通になるほどって納得してました。

講師:
 iOS のシミュレータは軽いと感じたことはあると思いますが、これはハードウェアエミュレーションしているわけではなく、シミュレーションで近似値を得ようとしているだけなので計算量が少ないためです。ちょっと強引ですが天気予報みたいなものかもしれません、あれもシミュレーションで近似値を予測している点では似ています。

 そんなわけでハイパーバイザ型はAndroidのエミュレータのように実行時のオーバーヘッドが大きいのです。それに比べてコンテナ型はiOSのシミュレータのようにオーバーヘッドが少ないわけですね。

 コンテナ型仮想化はこのオーバーヘッドの少なさ、起動の速さが流行った要因の一つのような気がします。例えば、AWS Lambda に代表される FaaS はトリガーにより発火するタイミングでコンテナを生成し、その中で関数を実行することで完全な独立性を確保しています。Heroku に代表される PaaS でも裏ではコンテナ型仮想化技術を活用しているケースも多いようです。

 ただ、ハイパーバイザ型仮想化にメリットが無いわけではなく、ホストOSとは異なるOSをインストールすることも出来るという利点もあります。

自分で Docker Image を作る

講師:
 さて、今までは既存の Image を使いましたが、そろそろ自分でもイメージを作りたいですよね?

 まずは作業ディレクトリを作りましょう(どこでもOKです

$ mkdir -p ~/Desktop/DockerWork

 Dockerfile という名前で以下のファイルを作ってみましょう。

FROM ubuntu:16.04

CMD [ "date" ]

 ファイルが作り終わったらイメージをビルドしてみましょう。

$ docker build -t ubuntu_date .

参加者:
 なにやらエラーになりました・・・

講師:  あー、最後の . を忘れないようにしてください。build は最後に . が必要な点に注意しましょう。

講師:
 成功すれば自分がビルドしたイメージが images で表示されるはずですっ!

$ docker images
REPOSITORY          TAG                    IMAGE ID            CREATED              SIZE
ubuntu_date         latest                 4f8b6dc9e250        About a minute ago   113MB

 今回は FROM でベースイメージとして ubuntu:16.04 を指定して、その上に変更をしている感じです。ちなみに ubuntu:16.04 は先程ダウンロードしたはずなので、今回はダウンロードが必要なかったはずです。

 以下のコマンドで確認してみると対応関係が分かりやすいかもしれません。

$ docker images | grep ubuntu
ubuntu_date         latest                 4f8b6dc9e250        6 minutes ago       113MB
ubuntu              16.04                  0b1edfbffd27        4 weeks ago         113MB
ubuntu              latest                 452a96d81c30        4 weeks ago         79.6MB

 では、自分で丹精込めてビルドした Image から コンテナ を起動してみましょう!

$ docker run ubuntu_date
Sat May 26 06:28:17 UTC 2018

参加者:
 これはコンテナ上の Ubuntu で date が実行されているということ?

講師:
 はい、そのとおりです!

講師:
 build でイメージを作成して、 run でイメージからコンテナを作成して起動します。

 ちなみに以下のコマンドでイメージの変更履歴が見れます。

$ docker history ubuntu_date
IMAGE               CREATED             CREATED BY                                      SIZE                COMMENT
4f8b6dc9e250        10 minutes ago      /bin/sh -c #(nop)  CMD ["date"]                 0B
0b1edfbffd27        4 weeks ago         /bin/sh -c #(nop)  CMD ["/bin/bash"]            0B
<missing>           4 weeks ago         /bin/sh -c mkdir -p /run/systemd && echo 'do…   7B
<missing>           4 weeks ago         /bin/sh -c sed -i 's/^#\s*\(deb.*universe\)$…   2.76kB
<missing>           4 weeks ago         /bin/sh -c rm -rf /var/lib/apt/lists/*          0B
<missing>           4 weeks ago         /bin/sh -c set -xe   && echo '#!/bin/sh' > /…   745B
<missing>           4 weeks ago         /bin/sh -c #(nop) ADD file:592c2540de1c70763…   113MB

 Dockerfile で自分が指定した CMD ["date"] が最後の履歴として表示されているのがわかるかと思います。

<ここで参加者1名が、そのあとの用事のために離脱したので終了>

スペシャルメニュー

<せっかくなのでちょっとしたおまけメニューを用意>

cargo で Rustプロジェクトを作って、それをDockerコンテナ上でビルド・実行してみよう!

FROM rust:1.26.0

WORKDIR /usr/src/myapp

COPY . .

RUN cargo install

CMD [ "hello" ]

cargo の使い方を忘れちゃったかな? 以下で作れるよ。

$ cargo new --bin hello

参加者の感想

参加者A:
 勉強会のモチベーションが分かった
 コンテナがあればサーバーサイドできる気がしてきた

参加者B:
 ハンズオンありがとうございました!わかりやすかったです!

おわり

まぁ今回はこんな感じで、 Kubernetes 読書会 #0 - Docker勉強会、みたいなものをやりました。

実のところ事前準備するつもりが全くできず、ぶっつけ本番になってしまったのですが、そのわりには楽しんでもらえる内容でできたかな、と個人的にはわりと満足しています。

そして連載ブログにしようぜ、という話があがったのはこれをやった後だったので、情報としては欠けてしまった部分も多いかもしれません・・・が、参考になる人もいると思ったので記事にしてみました。

輪読会は続くよ

さて、次回以降はついに Kubernetes の輪読会に入っていきます。楽しみですね。

というわけで、今回は休日の輪読会というか Docker ハンズオンの内容を記事にしてみました。

ではまた。

Xcode 9 の New Build System を試す

この素晴らしきビルドシステムに祝福を。

どうも tobi462(過去記事)です。

さて、Xcode 9 から新しいビルドシステムが導入されたのは記憶に新しいですが、9.3 の時点でも Preview となっており標準のビルドシステムにはなっていません。

すでに他記事でも紹介や現状のビルドシステムとの比較がされていますが、実際に自分でやってみないと信用しない質のエンジニアなので、今回は自分で試してみた結果です。

追記(2018/05/27):
逆にビルド時間が長くなったり、そもそもエラーでビルドできないケースもあるようです。現時点では Preview 扱いなので、そのうち改善されるかもしれません。

Tl;Dr

  • 以下のパフォーマンス向上結果が得られた
    • Clean Build で 95%
    • 差分ビルドで 90%
  • Swift 4.2 のツールチェーンではビルドエラーになった
  • 自分のPJで試して問題なさそうなら積極的に使っても良さそう?

New Build System ?

What’s New in Xcode を見ると以下のように書かれています。

New in Xcode 9 – Preview of a new build system written in Swift. Currently, This system is optional but it will become the default in a future version of Xcode

  • Added a preview of a new build system written in Swift.
  • Provides higher reliability.
  • Catches many project configuration problems.
  • Improves overall build-system performance.

Note, build system performance does not include the compilers, linkers, and other tools used by the build system.

  • 将来的には標準のビルドシステムになる
  • Swift で書かれた
  • 高い信頼性
  • プロジェクト設定の多くの問題を取得
  • ビルドシステム全体のパフォーマンス向上

Swift で書かれたということは、以前は他の言語だったということでしょうが、Swift にすることでパフォーマンス向上が計れた部分もあるのでしょうか。

ちなみに Notes にかかれていますが、コンパイラやリンカなどの他ツールを利用している形になっているので、それらのパフォーマンス向上はないようです。

つまり、プロジェクト構造からビルドすべきファイルを抽出し、妥当なスケジューリングと並列性でコンパイラやリンカを実行するという部分がビルドシステムであり、そこのパフォーマンスや安定性が向上したという感じでしょうか。(あまりこの分野には詳しくないのですが)

検証環境

今回は、モダンなiOS環境を試し続けている(ことを目標としている)以下の個人リポジトリにてパフォーマンス比較を行ってみることにしました。

github.com

環境は以下のとおりです。

・Xcode 9.3
・MacBook Pro (13-inch, 2017)
・Processor 2.5 GHz Intel Core i7
・Memory 16 GB 2133 MHz LPDDR3
・macOS High Sierra 10.13.4

プロジェクトに適用する

FIle > Workspace Settings… を選び f:id:yu_dotnet2004:20180519200043p:plain

ダイアログの Build SystemNew Build System (Preview) を選択します。 f:id:yu_dotnet2004:20180519200055p:plain

Shared Workspace Settings: だけで十分かなと思ったのですが、念のため Per-User Workspace Settings: の方も変更しました。

ちなみに Shared Workspace Settings: の方を変更すると以下のファイルが作成されるようです。

xxx.xcworkspace/xcshareddata/WorkspaceSettings.xcsettings:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
       <key>BuildSystemType</key>
       <string>Latest</string>
</dict>
</plist>

実行速度を比較する

現状の Xcode では標準でビルド時間が出力されないので、Terminal から以下のコマンドを実行して表示されるようにします。

$ defaults write com.apple.dt.Xcode ShowBuildOperationDuration YES

設定すると以下のような感じで、ビルドにかかった時間が表示されるようになります。 f:id:yu_dotnet2004:20180519200119p:plain

Clean Build

まずはクリーンビルドの比較からです。5回ずつ試してみました。

既存の Standard Build System では、Clean(Cmd + Shift + K)のあとでファイルのIndex化が行われているようだったので、それが完全に終わってからビルドを実行するようにしました。

結果は以下のとおりです。

[Standard Build System]
23.425
22.945
21.240
21.006
21.196

[New Build System]
21.797
20.825
20.602
20.402
20.392

平均値で比較すると 94.7% 程度になり、少しパフォーマンスが上がっているようです。個人的に Clean Build はさほど差がでないと予想していたので、これは少し驚きました。

ちなみに New Build System ではCleanが恐ろしく速かった、というより一瞬になっていました。

俺でなきゃ見逃しちゃうね。

差分ビルド

さて期待している差分ビルドの方です。

こちらは少し雑ですが、1ファイルだけ変更を加えてビルドを再実行する形で計測してみました。

結果は以下のとおりです。

[Standard Build System]
1.492
1.528
1.462
1.472
1.473

[New Build System]
1.329
1.345
1.308
1.312
1.436

これだけ短い時間だと妥当に計測できているかは少し微妙ですが、平均値で比較すると 90.6% となり、まぁ少なくとも遅くはなっていないようです。

Swift 4.2 の Toolchain ではビルドエラー

Xcode 9.3 には Swift 4.1 までしか入ってないですが、今は Swift の 公式ページ から Swift 4.2 の開発版のツールチェーンを入手することが出来ます。(少し前までは自分でビルドするしか無かったのですが;

f:id:yu_dotnet2004:20180519200143p:plain

試しに Swift 4.2 のツールチェーンでも New Build System を試してみたのですが、これはビルドエラーとなりました。

ビルドシステムはコンパイラやリンカと密接に連携するため、このあたりは相性的なものがあるのかもしれません。Swift ツールチェーンを切り替えることが多い方は、こういった問題も起こりうると覚えておくと良いかもしれません。

まとめ

Tl;DR とほぼ同じですが;

  • 以下のパフォーマンス向上結果が得られた
    • Clean Build で 95%
    • 差分ビルドで 90%
  • New Build System では Clean が高速化して一瞬になっていた
  • Swift 4.2 のツールチェーンではビルドエラーになった
  • 自分のPJで試して問題なさそうなら積極的に使っても良さそう?

というわけで検証結果でした。