ssk blog

バンコクで働くエンジニアのメモ

SwiftのCodableのモデルを作るためにquicktypeがすごく便利だった話

Swaggerで定義されたレスポンスのモデルを作るときに、Swaggerを確認しながら書くのがめんどさくなと思っていました。

そんなときに便利なのが、quicktypeです。

詳しくは、このブログを見ればわかるので、簡単にどんなものか書きます。

quicktypeに使い方


例えばSwaggerにこんなレスポンスがあったとします。

{
  "id": 1,
  "name": "hoge",
  "age": 16,
  "tags": [
      {
          "id": 1,
          "label": "肉好き"
      },{
          "id": 2,
          "label": "魚好き"
      },{
          "id": 3,
          "label": "お酒好き"
      }
      ]
}


これをquicktypeに貼り付けると...

f:id:ssktm:20180207205539p:plain


即座に右側にCodableのモデルが表示され、これをコピペすればモデルを作成することができます。


ちなみにStructやClass、Swiftのversionも指定することができます。

f:id:ssktm:20180207205955p:plain


Swaggerに定義するだけで、クライアントも含めて自動生成して開発できるようにしたら楽だけど、既存のプロジェクトでやるのは色々大変だな...
blog.techium.jp

開発チームのリーダーになってやって良かった3つのこと【役割明確化】【タスクの見える化】【相互理解】

会社のデベロッパーブログで書こうと思っていましたが、別の内容を書いたので、個人ブログで書きます。

自分の背景

新卒4年目で、新規事業2つ → 子会社の立ち上げを2社経験し、現在は、3年前にリリースした売り上げが絶好調のプロジェクトにいます。
今までAndroid/iOSの開発をしていて、2社目の子会社ではスクラムマスターを兼任し、『チームでモノ作ること』についてに勉強になりました。
作ったサービスはすべて失敗しましたが...組織や新規事業の作り方について多くの学びが多くありました。

去年、今のチームに異動し、半年後にiOSチームのリーダーになりました。
iOSチームは、全員自分より年上で技術力も高く、そのような状況で自分がチームリーダーになってやって良かったを3つのことを紹介します。

やった3つのこと

役割の明確化

自分の役割は、『iOSチームのアウトプットを最大化』することだ思っています。
すべてに責任を持ってやるには限界があり、技術が高かったり、チーム歴が長く細かい仕様を把握しているメンバーがいます。
そこで、役割マップを作りました。
役割マップを作ることで、誰が何をやるのか明確になり、各自に責任感がでて、チームとしてのパフォーマンスが上がったと思います。

役割マップのはだいたいこんな感じです(実際に作った役割マップは外部に公開できません。笑)。
役割マップは、状態を定義して、そこから分解していく方法が良いと思います。
f:id:ssktm:20180204223831p:plain

タスクの見える化

誰が何をやっているのか、カンバン(Zenhub)を使ってわかるようにしました。
スクラムっぽい開発のやり方をしてますが、本に書いてある通りにガチガチにするのは良くないと思います。
チームの雰囲気やメンバーの性格を考慮して、スクラム開発のエッセンスを取り入れるくらいが良いと感じてます。
ちなみに、スクラム開発をするときに本を何冊か読みましたが、この本が一番勉強になりました。


やりたいことは、「誰が何をやっているのかZenhubのボードを見たらわかる」ということです。
Zenhubのボードを死なせないために、朝会でZenhubのボードを見ながら、各自が今やっていること・やることを共有してもらいました。

また、月曜日にタスクのプランニング、金曜日にタスクの振り返りをしました。
これによって、チームの連携力が増し、プランナーにタスクの状況を説明しやすくなったと思います。

相互理解

相互理解とは、「お互いを知ること」です。
正直、これが1番重要だと思います。
Googleが社内で行なった調査で、生産性の高いチームに唯一共通することは、「心理的な安全性」らしいです。


相互理解のために、チームメンバー全員にストレングスファインダー(経費)をしてもらいました。
ストレングスファインダーとは、Webテストをすることで自分の強みを知ることができる本(ツール)です。


ストレングスファインダーの結果を全員に共有してもらい、それに関して話すというイベントを行いました。
結果はesaにまとめ、誰でも見れるようにしました。
また、各自の強みを考慮して役割マップも作りました。


ちなみに自分のストレングスファインダーはこうなりました。
みんなで、強みからモデル考えました。自分は『スティーブ・ジョブズ』になりました。笑
モデルが『菩薩』の人もいました^^

モデル『スティーブ・ジョブズ』
1.着想
2.個別化
3.戦略性
4.コミュニケーション
5.未来志向

最後に

自分は、チームが良くなるように実験感覚でいろいろ試してます。
正解の方法がないから、試行錯誤しながらやるのは楽しいと感じてます。
紹介したことが、良いなと思ったら試してみてください。

iOSアプリのアイコンを申請しないで変更する方法をしてAppleにリジェクトされた話

iOSアプリのアイコンを申請しないで変更する方法

iOSアプリのアイコンを申請しないで変更する方法は知っていますか?

この機能は、iOS10.3から使用可能です。
審査なしでiOSアプリのアイコンを変更する方法については、こちらに書いてあります。

qiita.com


やってみたかったこと

アイコンをハロウィンやクリスマスなどの期間だけ変えたい!!!
つまり、◯月◯日〜◯月◯日の間だけ、特別なアイコンを表示するみたいなことをやりたかったです。

実際に実装して申請した結果

リジェクトをくらいました。。。

Guideline 4.6 - Design - Alternate App Icons


We noticed that your app includes user-selectable icons but does not fulfill all of the requirements for using alternate icons. Specifically, 

  • your app includes user-selectable icons but does not provide a way to change the icons within the app.
Next Steps To resolve this issue, please ensure that your app's icons can only be changed at the user's request, are relevant to the content and functionality of your app, and can be reverted back to your app's original icon. For more information on user-selectable icons, including information on appropriate app icon sizes, please review the App Icon page of the iOS Human Interface Guidelines.

時限式のアイコンはダメで、アプリ内でユーザーがアイコンを変えれるようにしないといけないんですね....。
勉強になりました。

以上

『お金2.0 新しい経済のルールと生き方』を読み、仮想通貨や今後の働き方について考えさせられた


kindle

『お金2.0 新しい経済のルールと生き方』を読み、ここ最近読んだ本の中で1番面白く、学びが多かったです。

本書を読んでいくなかで、覚えておきたいと思った部分を紹介します。

お金と仮想通貨について

本書のタイトルである「お金」とは何かをいうと、『価値を運ぶツール』であり、保存、尺度、交換の役割があるものです。
紀元前1600年前からお金はあり、中央銀行がお金を刷って国の経済をコントロールしたのは最近(1694年)のことである。


仮想通貨が最近話題になることが多いですが、「仮想通貨は詐欺だ!あやしい!お金の代わりにならない」と言った意見も聞きます。
お金の歴史から考えると誤った考えかもしれないと思いました。


本書の中で、『新しいものは出てきたときに、それに似た業界の前提知識があると、その知識に当てはめて新しいものを見てしまう傾向があり、それが今でいう仮想通貨のことであり、全く新しいルールで回っている新しい仕組みとして考えるべきである』と書いてありました。

この考えは共感ができ、日本円ができたのも最近のことで、昔は貝殻がお金の変わりだったように時代とともに貨幣は変わっていくので、自分の既存の知識の枠で物事を考えるのは良くないと思いました。

【持続的に成長する組織】【拡大するサービス】を作るために経済システムを取り入れる

ここらへんの話は、組織やサービスを作る上で非常に参考になりました。


まず、経済システムという言葉を聞いてなんのことかイメージできる人は少ないと思います。
本書で言う経済システムとは、『人間が関わる活動をうまく回すための仕組み』であり、5要素から成り立っているとありました。

経済システムを構成する5要素
  • インセンティブ・・・報酬が明確であること
  • リアルタイム・・・時間によって変化する=常に状況が変化する
  • 不確実性・・・運と実力の両方の要素がある(未来が予測できない)
  • ヒエラルキー・・・階層や序列の可視化
  • コミュニケーション・・・経済システムに参加する参加者同士のコミュニケーション


成長する企業や拡大するサービスは、個人依存せずに仕組みで動き、経済システムの5要素をうまく取り入れているとあり、Facebookや小米(中国の端末メーカー)を例に出して5要素を解説する部分は興味深かったです。


インセンティブやヒエラルキーが必要な要素なのは想像できましたが、個人的に不確実性という要素が気になりました。
不確実性がない方が、安定した環境を提供でき拡大できると思っていました。


本書の中で、不確実性を説明している部分で

  • 「不果実性が全くない世界では想像力を働かせて積極的に何かを取り組む意欲が失われる」
  • 「生まれた瞬間から死ぬまでの結果がわかってしまう世界があったら必死に生きたいと思うか?」
  • 「自らの思考と努力でコントロールできる要素と全くコントロールできない要素がバランスよく混ざっている環境の方が持続的な発展が望める」


ということが書いてあり、確かに自分は、チャレンジのないずっと安定している職場だったらいつか飽きて転職するなと思いました。

人間の脳と経済システムと自然の関係

本書の中で、人間の脳と経済システムと自然の関係は、人間の脳 < 経済システム < 自然であると書いてあります。

経済システムを理解するためには、人間の脳を知ることが近道です。
人間の脳には報酬系という神経回路があり、それによって経済システムは上手く回っています。
経済の仕組みと似ているのが、自然界であり、自然が経済に似ているのではなく、経済が自然に似ていたから、資本主義がここまで広く普及したとありました。

人間の脳の仕組みを使って経済システムの5要素を説明している部分はとても面白く、納得する部分も多かったです。
また、ダ・ヴィンチがどうして音楽、数学、芸術、力学など様々な分野で類な才能を発揮したかについても書いてあり読んでみてください。

小並みな感想ですが、脳の仕組みについて、勉強したいなと思いました。

テクノロジーとお金

本書の中で、これからの10年を考えるキーワードとして『分散化』をあげていました。
『テクノロジーによって仕組みの分散化』が進んでいくと言う話があり、UberAirbnbを紹介しています。
そして、この分散化は経済にも起こるありました。


今、仮想通貨は投資目的(自分も。笑)で盛りがっていますが、これからトークン(ネットワーク内で流通する通貨)を用いて、国家がやってきたことを企業や個人が簡単にできるようになり、その中で経済圏が作られるようになります。
これによって、国家のお金の価値(重要性)がなくなります。


多くの国で仮想通貨に規制をかけようとしていますが、国家を守るために各国が規制をかけるのは当然だと思いました。

  • 200 年前に中央銀行が通貨を管理するのはおかしいという議論がされた
  • 40年前に金の代わりに紙幣を使うが、ただの紙切れでは?という議論がされた


今では当たり前のことでも、中央銀行や紙幣がでてきたときにいろんな批判がありました。
時代やテクノロジーの進化によって、お金が仮想通貨に変わっても、20年後から見たら不思議なことではないのかなと思いました。

資本主義から価値主義へ

本書の中で、分散化によって国家のお金の価値が下がり、資本主義から価値主義に変わっていくという話がありました。

価値主義とは価値とは
  • 有用性としての価値

役に立つかという観点で考えた価値

  • 内面的な価値

共感、興奮、愛情などの実生活で役に立つかわからないけど、人の内面にポジティブな効果を及びすもの

  • 社会的な価値

個人ではなく、社会全体の持続性を高める活動


資本主義は、有用性としての価値だけを見てます。
しかし最近は、テクノロジーによって、内面的な価値も数字化できるようになりました。
これによって、内面的な価値をお金に交換することができます。
内面的な価値をお金に交換している例として、youtuberやインスタグラマーなどを説明している部分があり面白かったです。


今後は、お金などの資本に変換される前の価値を中心とした世界に変わっていくとあり、自分の価値をいかにあげるを考えて働くべきだなと感じました。


詳しい内容は、ぜひ読んで見てください!!!


kindle

XcodeのコードカバレッジをCircleCIでCoverallsに飛ばし可視化する方法

こんにちは。
CyberAgentAdventCalendar13日目を担当するsskです。
タップル誕生のiOSアプリを作っています。

先日、「普段の開発でなかなかできないことで、ユーザーにメリットがあるものならなんでもOK」っという目的で1泊2日の開発合宿に行ってきました。

iOSチームでやりたいことリストを作成し、自分は『テスト書く』にしました。
本当はFaceIDを使ったログインとかやりたかったけどね...

やりたいことリスト

- テスト書く
- FaceIDを使ったログイン
- 3Dタッチ
- Cloud Firestore
- etc...


開発合宿で、自分は以下のことをしました


この記事では、カバレッジを可視化する方法について書きたいと思います。

カバレッジを可視化する方法

① CoverallsにGithubリポジトリを連携

カバレッジの取得には、Coverallsを使いました。

CoverallsにGithubリポジトリを連携させるとSWFT SET UP FOR COVERALLSという画面になります。
TravisCIを使っていれば、設定が簡単そうです。
今のプロジェクトではCircleCIを使っているので、spec_helper.rbに設定を書けばCoverallsにカバレッジを飛ばすことができそうです!

...正直、何を書けば良いかわかりません。

f:id:ssktm:20171211203704p:plain


DOCSを見るとCommunity developed Swift supportがありました。


f:id:ssktm:20171211204523p:plain



realm/SwiftCovを見ると、もう終了していました....

f:id:ssktm:20171211204826p:plain


② slatherを使ってCoverallsにカバレッジを飛ばす

SwiftCovは終わってたので、似たようなライブラリであるslatherを使いました。
https://github.com/SlatherOrg/slather
github.com


設定することは3つだけです。

Gemfileに gem 'slather'を追加
 gem 'slather'
circle.ymlに bundle exec slather を追加
 post:
   - bundle exec slather
.slather.ymlを作成
 ci_service: circleci
 coverage_service: coveralls
 coverage_access_token: Coverallsに書いてあるrepo_token
 xcodeproj: 〇〇.xcodeproj
 workspace: 〇〇.xcworkspace
 scheme: 〇〇


これでCircleCIを回したら、コードカバレッジが飛ばすことができました。

f:id:ssktm:20171211211007p:plain


ん?テスト書いてないのにすでに5%あるぞ!?


Xcodeのコードカバレッジは、『アプリ起動時に呼ばれるコードは、カバレッジに含まれる』ようです
詳しくはこちらの記事に書きました。

補足: slatherとfastlaneについて

slatherは、fastlaneのActionにあるので、設定をすればターミナルからコマンドを叩いてテストを実行してカバレッジを送ることができます。
(ちょっと試してみましたが、上手くいかず...早くテストを書きたかったので断念しました)

f:id:ssktm:20171212213513p:plain


おわりに


最終的にGtihubのREADMEにバッジを貼りました。

f:id:ssktm:20171211212813p:plain


テストを書かないでプルリクを出すとカバレッジが下がってSome checks were not successfulになるので、チームメンバーがテストをいつも意識するようになりました。みんな嫌がっています。笑

f:id:ssktm:20171211213127p:plain


タップル誕生では、少しのバグによって発生する機会損失が大きく、カバレッジを意識する仕組みを導入し、テストの土台を作ることで、「ここはバグが出そうだからテストを書いておくか」という意識に(少しは)なったと思います。
また、t_wadaさんにTDDワークショップを受けて、テストを書くことでコードが綺麗になることは身を持って実感したので、テストは積極的に書いていきたいです。


ちなみに開発合宿では、コードカバレッジを可視化したあと、テストをひたすら書いてましたが、1%くらいしかカバレッジは上げることができませんでした!
以上!

XcodeでiOS(Swift)のカバレッジの計測方法 〜テストを書かなくても100%にできる!?〜

Xcodeでコードカバレッジを表示する方法は、こちらのブログを見てください。

コードカバレッジについて

AppleのDeveloperサイトには、コードカバレッジの説明があります。
Code Coverageの説明

Code coverage is a feature in Xcode 7 that enables you to visualize and measure how much of your code is being exercised by tests. With code coverage, you can determine whether your tests are doing the job you intended.

簡単に翻訳すると、テストでどれくらいのコードが実行されているかわかるものです。

コードカバレッジの計測方法

新規プロジェクトを作ってコードカバレッジを測定してみました。

f:id:ssktm:20171210223734p:plain


テストを書いてないのにカバレッジが37.93%ありました。


コードカバレッジってテストでどれくらいのコードが実行されているかわかるものではないのか...!?


アプリ起動時に呼ばれるコードは、カバレッジに含まれるみたいです。

テスト書かなくてもコードカバレッジを100%にできる

『アプリ起動時に呼ばれるコードは、カバレッジに含まれる』ということがわかったので、新規プロジェクトを作成したときに呼ばれないメソッドを削除するとテストを書かなくてもコードカバレッジが100%になります。

f:id:ssktm:20171210224939p:plain




テストを書いたときにコードカバレッジが思った以上に高くて、調べたらこの仕組みがわかりました。
実際のカバレッジは、1%もないです!テスト頑張ろう!

XcodeのTestでCoverageを表示する方法をスクショで簡単に紹介

そろそろちゃんとテスト書こうと最近思っている日々です。

ゴール

テストを実行したときに、Coverageが表示されている

f:id:ssktm:20171207215702p:plain

方法

① Product -> Scheme -> Edit Schemeをクリック

f:id:ssktm:20171207215906p:plain

② Gather coverage dataにチェックを入れる

f:id:ssktm:20171207215952p:plain

③ チェックを入れた状態でテストを実行するとCoverageが表示されます。

f:id:ssktm:20171207215702p:plain


補足

Gather coverage dataにチェックを入れないで、テストを実行すると何も表示されません。

f:id:ssktm:20171207220246p:plain