Home

Portfolio2022/2/18 1:442022/12/23 3:28
 

ソーシャル

 
 

Tech Post

[Swift]protocol extensionの上手な使い方
InstantiateというSwiftライブラリの内部実装を調査した内容をメモがわりに置いておきます。 Instantiate(GitHub) はViewControllerのサブクラスなどが依存するクラスをDI(Dependency Injection)したい時などに、よしなにしてくれる便利なprotocolが実装されています。 参考: DI(Dependency Injection) の解説 - Qiita 例えば、ViewControllerがViewModelを依存させたい！という場面があることとします。 上記のようにViewControllerを宣言してからViewModelをなんらかのメソッド(今回は inject メソッド)で呼び出しても良いですが、これではメソッドの呼び忘れなどのヒューマンエラーが起こりうるのです。 そこで、Instantiateを利用すると下記のように初期化時に保証できるようになります。 なるほど、便利ですね！ かなり簡潔に見えますがこれはどうやって実装されているのでしょうか？ まず、依存させたいクラス(上記ではViewModel)をどうやってViewControllerに設定するかですが、下記のように特定のprotocolに準拠させるだけです。 StoryboardでViewContorllerのUIを作っていれば StoryboardInstantiatableで、Nibであれば NibInstantiatable になります。 また、 InstantiateStandard は同じクラス名のファイルを自動的に検出していい感じにしてくれるのでimportすると良いです。 この StoryboardInstantiatableは injectable を継承しています。 また、ViewController初期化時に、内部でStoryboardからViewControllerを生成し、injectメソッドを呼んでくれています。 そして、このinjectメソッドは protocol extension としてあらかじめ実装されています。 (わかりやすさのために簡略化しています) Injectable.swift Storyboard+UIViewController.swift もともとのInjectableには Dependency = Void とあり、すでに型が指定されています。 そのまま使うとするならViewModelなどの型を指定できず、Voidが入ってしまうのでは？という疑問が出てきます。 Playgroundでも用意して実際に試しながら読むとさらに理解が深まるかと思います。 このprotocolの仕様を追うのにまず理解すべきは associatedtype についてです。 まずは下記のようにprotocolで associatedtype としてDependencyを用いるように定義してみます。(*1) また、各VCが typealias として定義し具体型として実装できます。 では、ここでprotocol自身で定義しつつ特定の型を指定してみましょう。(*2) protocolを継承したclass(ここではVoidVC)では省略可能であることがわかります。 一方、StringVCでは Dependency = String として上書きできます。 上記ではどちらのVCからcallメソッドを呼んでも、( *1 )とおなじ結果が得られます。 ではcallメソッドを実装してみましょう。 上記を省略した形で下記のように書くこともできます。 callメソッドの引数に注目すると Dependency と String と違って見えます。 もうお気づきの方がいるかもしれませんが、callメソッドのdependencyに具体型を定義することで、コンパイラが typealiase Dependency = String として勝手に解釈してコンパイルが通るようになります。 これがViewModelなどのように様々な型を依存させることができる仕組みです 今回は Instantiate というライブラリを題材に、内部実装をみていきました。 上記について少しでも理解の一助になれれば幸いです。 Swiftの言語仕様をうまく使っていてとても参考になりますね。👏 こうやってOSSの実装方法を調査してみるととても勉強になるので継続的にやっていけたらと思います。 最後までお読みいただきありがとうございました。
https://zenn.dev/mtfum/articles/b89b254bedfc6f
 
Post
 

メディア

11. フロントエンドエンジニアのキャリアパス
bkkcast はフィードバックを積極的に受け付けています。聞いてみたいことがあれば 質問箱もしくは @bkkcast まで連絡ください！ 1. フロントエンドエンジニアのキャリアパス (0:30) 発端は勝又さんのツイート フロントエンドエンジニアは CTO になれないのか？ @laiso アプリ開発をやる人がいないから始めた 昔からいるアプリエンジニアは Web 系から来たわけではない？ @mtfum くらいの若いエンジニアはフロントやアプリから入ってくる事が多い @tamanyan55 学生時代 CakePHP など Web App や API 開発をしていた @tamanyan55 入社のタイミングでアプリリニューアルの話があり面白そうだから iOS エンジニアとしてキャリアをスタートした 将来的に「CTO」を目指している方は、キャリアのどこかで「バックエンド」を経験しておいた方が良いというか、他の職種の方がCTOになれないということはないんですが「CTOがバックエンドのことを分からない」というのは致命的ですし、バックエンド出身のCTOがやっぱり多いという印象はありますね(^.^;)- 勝又健太@テック系Youtuber (@poly_soft) September 24, 2018 ネイティブアプリ開発を最初のキャリアに選んだこと、後悔はしていないが、普通にバックエンドアーキテクトで実績作った方がよかった。 今やってる内容をちゃんと形にして、自分の強みにしないと。- たまにゃん・バンコクエンジニア🇹🇭 (@tamanyan55) October 2, 2018 2.
https://bkkcast.me/011/
18. スタートアップのセキュリティ問題
bkkcast はフィードバックを積極的に受け付けています。聞いてみたいことがあれば 質問箱もしくは @bkkcast まで連絡ください！ 1. 最近Webサービスの脆弱性が話題になっている (0:30) Peing-質問箱-(公式)の脆弱性問題 質問箱のユーザーのページに行くとアクセストークンが見えている 質問箱の公式アカウントが乗っ取られた 宅ふぁいる便は平文でパスワードを保存されていた！？ サービス内にパスワードを保持すると怖い 二段階認証を徹底した方がよい 2. スタートアップで働くエンジニアがセキュリティ面で気をつける事1 (7:45) 大企業だったら、セキュリティソフトを利用する セキュリティスペシャリストのチームがある会社もある XSS（クロスサイトスクリプリング）を防ぐようにする モデルのデータをそのままtoJSONすると中に個人情報や認証情報が含まれないように気をつける Firebaseを扱う上での脆弱性問題 XSSを防ぐために、 タグをフォームに入力してみる 3. スタートアップで働くエンジニアがセキュリティ面で気をつける事2 (18:40) @tejitak が以前所属していた企業だとプロダクトをリリースする時に、必ずセキュリティ診断ソフトを通す @tejitak トークンらしきものが存在した時にアラートしてくれる Laravel等のフレームワークはそのまま使えば、ある程度セキュリティは担保してくれる 代表的なセキュリティ問題（XSS）は把握しておく リリース前にHTMLのソースなどを見て、問題がないかを確認する プログラミングスクールではセキュリティについて教えてくれない？？ 現場に入らないと、なぜセキュリティ対策をしないと駄目なのか分からない
https://bkkcast.me/018/
 
Share on Twitter