Shuntiger Tech Diary

iOS/Androidエンジニアが気になる技術やガジェットなどを気のままお届けするブログ

先輩に質問するときに用意していること

実装のことやバグのことで、先輩に聞くとあっという間に解決することがある。

質問する側もされる側も経験してみて、 自分は先輩に聞く時に何をしているか、簡単にまとめてみた。

How

  • 状況を伝える、何をしようとしていたか。

そもそも手順が間違っていたりなどで、このタイミングで解決することが多い。

  • エラー内容、詳細

どういうエラーが出ているのか。

  • 質問する前に試したこと

何個かは試した上で質問しに行く。 これを試して、こうすれば上手くいくと思ったのですが...など。

あった方が、どういう状況かを把握しやすくなり、問題解決が早くなる気がする。

  • バージョン(必要であれば)

いつ確認するか

30分ほど試してみて、ひとりで解決できそうになければ確認する。 Qiitaの記事では15分でわからなかったら確認するとあった。

問題が起きた時は

【1】最初の15分は自分自身で解決を試みる

【2】15分後も解決していなかったら必ず人に聞く

前者を守らないと他人の時間を無駄にし、後者を守らないと自分の時間を無駄にする。

15分調べてわからないことはそれが今の自分の実力、とのこと😓

気付き

これができればstackoverflowやteratailで質問する時もこわくない!😁

他にもAWSの障害があったときの報告手順が参考になりそうだった。

https://aws.amazon.com/jp/premiumsupport/tech-support-guidelines/

参考

www.youtube.com

qiita.com

www.hyuki.com

tkybpp.hatenablog.com

【iOS】コードレビューをする上で気をつけること

最初にファイルのimportをみる

  • 1つのファイルにimportが4~5つもあったらファイル内で色々やらせすぎなので、分ける必要がある。

"!"マークで検索をかける。

  • "!"マークは強制アンラップ、なければ無いほうがいい。強制アンラップは避ける。

ロジックを見て冗長であり、まとめられそうかみる、

  • 冗長の場合、冗長でない書き方をレクチャーする。
  • for文 で回しているのをmap使った方がいいとか。
  • 仕様がわからない場合、ロジックはレビュアーにお任せする。あくまでコード面で冗長性がないかを確認。

リードエンジニアのレビューを踏襲して真似してみる。

  • 真似してみてリードエンジニアの考え方を学ぶ

Swiftらしくかけているかを意識する。

  • Objective-CからSwift移行の場合など。
  • Swiftyに。

また思いついたら追記します。

ミニマムにDIについてまとめてみた

  • DI = イニシャライザやメソッドなどを使って外からオブジェクトを注入すること。
  • テストコードを書けばDIについて理解が深まる。
  • プロジェクトではRoutingなどで使う。

DIを使わないパターン。汎用性がない

class DogPark {

 private var dog = Dog()

}

イニシャライザでDIを使っているパターン

  • 注入する型はProtocolを指定すればテストが容易
class DogPark {

  // Protocolを使わないとDog型のみなので、テストの時の汎用性がない。
  private var dog: Dog?

  // Protocolに準拠しておけばよいので使い回しができる。
  private var dog: DogProtocol?

  init(dog: DogProtocol) {
    self.dog = dog
  }

}

メソッドでDIを使っているパターン

class DogPark {
  func inject(dog: DogProtocol) {

    self.dog = dog

  }
}

ClassをProtocolに準拠させる

// DogProtocolに準拠させる。
protocol DogProtocol { }

class FakeDog: DogProtocol { }

class MockDog: DogProtocol { }

呼び出し側 イニシャライザパターン

  • MVP、MVVMでもDIは使う。
HogeClass {
  
  // MVP
  let fakeDog = FakeDog()
  let dogPark = dogPark(dog: dog)
  
  // MVVM
  let viewModel = ViewModel(dog: fakeDog)
  let vc = ViewController(viewModel: viewModel)

}   

呼び出し側 メソッドパターン

  • 外からメソッドを使ってDIする。
HogeClass {
  let dogPark = DogPark()
  let fakeDog = FakeDog()

  dogPark.inject(dog: fakeDog)
}

参考

qiita.com

【書評】学びを結果に変えるアウトプット大全

学びを結果に変えるアウトプット大全 (Sanctuary books)

学びを結果に変えるアウトプット大全 (Sanctuary books)

ビフォー

渋谷の大盛堂書店で目に入ってチラ読みして購入した。 今の個人的流行は「ブログを書く」ことなので、ブログの章を読んでたら欲しくなった。 また結構アウトプット足りてないなとしばしば感じてるので、そこを克服できればと思った。 エンジニアは特にアウトプットが重要と言われているので。

気付き

  • プレゼンスライドをつくる
    • ノートを2ページ見開きで使って、時計をイメージして右上、右下、左下、左上と話す内容を記載していく。
    • 話す内容が決まったらスライドを作成する。
  • 本を書く時は30%を目標に仕上げて3回くらいブラッシュアップして100%を目指す。
  • スマホは見るだけではなくアウトプットのツールに
    • 電車、ランチなどのスキマ時間を利用する。
  • 読書感想テンプレート -「ビフォー」+「気付き」+「TODO」という型で記載する。
    • この記事も型に沿って書いています、実感として型に習うと結構筆が進む...!
  • 情報発信の圧倒的なメリット
    • 内面の変化: フィードバック効果、アウトプット力UP、緊張感、楽しい
    • 現実の変化: 人が集まる、評価UP、仕事の依頼

TODO

  • ブログでアウトプットする、週2回以上更新できたら理想。
  • インプット3割、アウトプット7割を心がける。
  • 睡眠を7時間以上とる。睡眠が足りていないと良質なアウトプットができない、とも書いてあったため。

【書評】現場で困らない!ITエンジニアのための英語リーディング

この本を読む前はドキュメントやメールなどの英文をGoogle翻訳にかけて英語の意味を理解しようとしていた。 ただChrome拡張機能であるポップアップ翻訳がXcodeのドキュメントでは使えなかったりとか、自動翻訳が意味がわからなかったりとかで、 英語の原文を読むリーディング力を求められる機会は多々あった。

気付き

  • gitのコミットメッセージの書き方
  • リーディングをするときは英文は区切って読むこと。
  • 日本語に翻訳して読まないこと。
  • 原文のままで理解すること。
  • 理解するには語彙力・単語を知っていることが重要。
  • 高校卒業までの3000語を覚えれば85%読める。
  • 英文の中でOxford3000語が何%含まれているか調べられるサイトがある。 https://www.oxfordlearnersdictionaries.com/text-checker/
  • CallKitのOverViewをテキストチェッカーで調べてみたら78%がOxford3000で使われている単語だった。 f:id:hyaku-juu-ichi:20200211193035p:plain f:id:hyaku-juu-ichi:20200211193123p:plain

  • ちなみにA1、A2っていうのは英語のレベルのよう。

    • A1 英検3級〜5級
    • A2 英検準2級

準2まで分かれば70%は理解できるのね...

f:id:hyaku-juu-ichi:20200211193531j:plain

引用: cambridgecentre.jp

TODO

  • Oxford3000語を覚えようと思った。
  • なるべく原文で読む努力をする。
  • 特徴語と呼ばれるIT形の現場でよく使われる単語は読者特典の単語集を読んで学ぶ。
  • 今やるならスタディサプリをやる。

iOSDC2019に行ったときのこと

心の奥底でiOSDCに行った時のことを書こうと思って思って

結構引っかかってたんだけど、時間が経ってしまった😂

パソコン持ってがっつりメモしたはずなんだけどなー...。

去年のことだから今更感もあるし..

ブログは熱が冷めないうちに書くべきですね。

 

ただ会社のフィードには書いてました。

https://www.wantedly.com/companies/caraquri/post_articles/187609

AppStoreに審査を提出する前に用意しておきたいこと

  • 年齢制限の確認
  • カテゴリ
  • サポートURL
  • プライバシーポリシーURL
  • サブタイトル(iOS 11以降のApp StoreおよびmacOS Mojave以降のMac App Storeで、App名の下に表示されるAppの概要。)
  • App プレビューとスクリーンショット(AppStoreに掲載する画像)
  • プロモーション用テキスト(プロモーション用テキストを使用すると、更新内容を提出することなく、App Store の訪問者に現在の App の機能について知らせることができます。このテキストは、iOS 11 以降および macOS 10.13 以降を搭載した端末を使用するカスタマーに対して、App Store の説明の上に表示されます。)
  • 概要(特長や機能の詳細など、App に関する説明です。Apple Watch App でも使用されます。)
  • キーワード (Appについて説明するキーワードを1つ以上含めてください。キーワードを使用すると、App Storeでより正確な検索結果が表示されます。各キーワードは半角カンマ、全角カンマ、またはその両方を使用して区切ってください。)
  • Copyright(App の独占権を入手した年、所有する人物または組織の名前の順に入力してください(例:「2008 Acme Inc.」)。URLを提供しないでください。)
  • 連絡先(名前(フルネーム)、電話番号、メールアドレス)

サポートURL、プライバシーポリシーURL、App プレビューとスクリーンショットは時間がかかるので余裕を持って用意する。