TAMINIF’s blog

大阪在住のWebエンジニア。iOSアプリもやってます。勉強会にも参加してます。最近はマネージャー色強め

SkyWayのiOSライブラリ知見二つ/peer.destroyとSKWMediaStream

はじめに

本日ハマったので備忘録を二点残しておきたいと思います。
iOSアプリでSkyWayを使ったアプリを実装する場合に、peerオブジェクトを必ず明示的に破棄するようにしましょう
そして、SKWMediaStreamの操作をするときはメインスレッドで実行しましょう

TL;DR

画面遷移などで一度接続したpeerを破棄する場合は、peer.destroy()しないと次回接続時のSKWNavigator.initialize(peer)を実行した時にエラーが発生しないまま動作がストップする。
SKWMediaStream.addVideoRendererするときはもちろん、SKWMediaStream.closeするときもメインスレッドで実行しないと接続が切れるまでUIがストップする。しかも、止まるのを待たないまま動かし続けるとフリーズする
(completionhandlerのような接続断後に実行できる関数はない)

経緯

どちらも、以前動いていたものが動かなくなって報告をもらってから調査を行なったもの。
ソースコードは一切変更していなったので、なぜ突然動かなくなったのかはわからない。
おそらく以前から動かなくなっていたと思われるが、リリース当初は問題なく動いていたため、いつからかは不明。

peer.destroy()

ビデオ画面に入室 <-> 退室を繰り返した時に2回目のSKWNavigator.initialize(peer)を実行したタイミングでエラーも出ず、次の処理にも進まない事象が発生した。
SkyWayのSwiftライブラリは中のソースコードを読むことが出来ず、ステップ実行でどこで止まっているかもわからないためいくつかのサンプルコードを読んで実行して問題ないことを確認した上で、ビデオ終了時にpeer.destroy()せずにpeerにnilを格納して破棄しているだけであることを発見、解決した。

SKWMediaStream

こちらもビデオ画面に入室 <-> 退室を繰り返した時に、2回目の退室後に入室前画面に戻りはするも、画面がフリーズする事象が発生した。
こっちはどこで処理がストップしているか不明だが、前画面には戻っていて処理は全て完了していたので、こちらもサンプルコードを探して
公式のサンプルではDispatchQueue.main.asyncremoveVideoRendererを実行していたため、こちらを参考に修正することができた。

まとめ

SkyWayのiOSライブラリは情報が少なく、原因を調査するのが難しいので
こういうブログでWebに知見を残していきたい。

精神が疲弊しているので本を読んで勉強する

年末から年明けにかけてここ二ヶ月くらい、公私ともに忙しい日々を過ごしていている。それ自体はありがたいことなのだが、仕事が終わって帰ってくるなりほとんど何もできていない。休日もいろんなところに出かけていて、まともに時間が取れないこともあって、最近はほぼアウトプットできないでいる。
ハードワークというわけじゃなくて、精神的に負荷がかかっているのも影響があると思っているのだが、パソコンを開いてもあまりモチベーションが上がらないまま時間が過ぎてしまう。
何もできないとやっぱり焦りはあって、今はできるだけ頑張れることを頑張るようにしていて、その一環で本を多く読むようにしている。でもインプットするからにはアウトプットもした方が効率が良いし、この二ヶ月で読んだ本について良かった本をアウトプットする。

禅マインド ビギナーズ・マインド (サンガ新書)

Team Geek ―Googleのギークたちはいかにしてチームを作るのか という本で、リーダーシップパターンの中に「禅マスターになる」という章がある。リーダーはどのような状況でも禅の心を持って平静を保ち、知識に沿った判断をするというものである。これとは別に、仕事の上でついつい感情的になってしまう傾向があり、自分を俯瞰する技術を身に付けたいと思ってどうすれば良いか考えたときに、禅を学ぶことを決めてこの本を読んでみた。

このツイートはわりと本音を書いていて、読んだ結果は全然わからなかったというのが正直な感想である。
ただ、禅とはそういうものらしい。本を一冊を読むだけではわからないとは思っていたけれど、禅は学び続けるのでちょっとずつ学びたい。

おとなの教養 私たちはどこから来て、どこへ行くのか? (NHK出版新書)

面談で教養つけた方が良いんじゃない?と指摘をもらって、Amazonで「リーダー 教養」で検索して良さそうなのをいくつか見繕って買った本のひとつ。前にも池上さんの本は読んだことがあったんだけど、この人の本は読みやすくてすぐ読めるのが良い。
歴史や宗教が人を形成していったことがわかりやすく説明されていて、教養がなかった私にも、すでにある人も再認識するという意味で良い本だと思う。

自分は教養をちゃんと理解できているか怪しいけど、これから多くの人と関わる上である程度多くの人が持っている普遍的な情報を持たないといけないと思っていて、こちらも時間をかけて学んでいきたいと考えている。

異文化理解力――相手と自分の真意がわかる ビジネスパーソン必須の教養

世界中の人と仕事をする際に、その国のコミュニケーションの方法、仕事の付き合い、評価の伝え方などそれぞれで違った文化を持っていることを知り、その国に合わせることで仕事をスムーズに進めるという本で、とても参考になった。
日本で働くだけであれば国に合わせるようなことはそうそうないことだが、自分の職場にも海外で育った人が働いて、その前提を持って話をすることはひとつのテクニックだと思うので、実践できればと考えている。

プリンシプル オブ プログラミング 3年目までに身につけたい 一生役立つ101の原理原則

コードもあまり書けていないのだが、この機会に基礎的な本を読もうと思ってこの本を読んだ。
「3年目までに身に付けたい100の原則」とあるように、プログラミングする上で知っておくと綺麗なコードになると思う参考になる本だった。
自分はもう9年目なのですでに遅いかもしれないが、どれだけ時間がたっていてもちゃんと学ぶべき内容だったし、読んで良かったと思う。
コンウェイの法則」など、この業界で何年か働かないとスッと入ってこないような内容もあって、読み直すのもオススメしたい。

リーダーが育つ55の智慧

ニトリに行った時にこの本が積んであるのを見たのと、記事などでこの人の特集を読んだことがあって
気になっていたので、この機会に読んでみた。
上のツイートの通り面白かったし、人には向き不向きがあっていろんな舞台でチャレンジさせてあげるとか、
常に改善を行うなど、実践してみたいと思う内容だった。

今読んでいる本

FACTFULNESS(ファクトフルネス)10の思い込みを乗り越え、データを基に世界を正しく見る習慣

まだ第1章を読んだだけだが、面白そうで楽しみにしている。
私も事実を見ずに印象だけで思い込んでいたので、この本を読んでちゃんと物を見れるようになろうと思う。

まとめ

なんとなくだけど、海外の本で翻訳されたものと日本の本ではボリュームが違うのはなんでだろうと思った。
ちなみに弊社は本を全て会社で購入してもらえるので自分で買った本はない。 いずれまとまったアウトプットはしたいが、そのためにもちょっとずつ勉強できたらと思う。

「別にやっても良いですよ」という人たち

これは自戒の意味も込めて書く。何かやる必要がある時のスタンスの話。

「別にやっても良いですよ」という人たち

チームで何かやる必要があるときに、タイトルのことを言う人を観測範囲で結構見かける。たまに自分も言う。
やってもやらなくても良い時に言う傾向が高いと思うが、あまり良くないと思うのでその理由を書く。

タスクを任せづらい

正直なところ、消極的な人にタスクを任せるのはめんどくさい。
善意での発言かもしれないが、任せるのであれば「やりたいです!」や「やりましょう」と言ってくれる人に任せたい。
これは感情的な話なのかもしれないけど、そういうスタンスでやってくれる人の方が良い結果を出す傾向があると思っていて、
それが誤りでないとわかるまでは、この感覚は信じたいと思う。

自分ができないならまずやらないという姿勢を見せる

そのタスクが技術的・時間的にできないのであれば、チーム内でその姿勢をちゃんと見せた方が良い。
他のチームメンバーの判断を迷わせることになる。
消極的な姿勢はチームに悪い効果だと思う。

やらなくても良いタスクなら最初からやらない

チーム内でタスクの提案が誰かからあった時、それがやる必要があるかどうかをまず判断すべきだけど、
やる必要がないタスクであれば、最初からやらないという決定をすれば良い。
そうなってないなら、やる必要があるタスクだということになる。

やる必要があるなら

結局誰かはやるのだし、面白いタスクでもつまらないタスクでもやった方が良いと思う。その理由も書く。

面白いタスクなら

今までできなかった経験かもしれないし、やってると楽しいタスクかもしれない。
そのタスクをやることで成長できるなら、やらない選択肢はない。

つまらないタスクなら

自分がそのタスクをやることで、他のチームメンバーがより大きなコミットを出せるならそれはチームの功績になる。
特にあなたがマネージャーなら、他のメンバーの障害になりそうなタスクを積極的にやる方が良い。これはTeam Geekにも同様のことが書かれている。
(サーバントリーダー)
ただし、自分の優先度と比較して、それより大事なタスクがあるならちゃんとそっちを先にやろう。これだけは忘れてはいけない。

自分ができないかもしれない時は

技術的に難しい場合は、チームにそれを伝えた上でやるようにしたい。でもチャレンジするのは良いことだと思うので良い機会だと思ってやろうとする方が良いと思う
時間的に難しい場合は、タスクの優先度をちゃんと判断して決めよう。
いずれにしても、積極的にできないことをチームに伝えよう。

まとめ

チームで働く上で、チームに良い結果をコミットしていくことは重要だと考えていて、
そのためには積極的にチームに参加していくようにしたい。
言いたいことを十分に伝えられてないかもしれないけど、いずれにしてもタイトルのスタンスはやらないようにする。

エンジニアたとえ話

特に技術的な話をエンジニアではない人にするときによく採用する手法なのですが、技術的な内容を理解してもらう必要があるときに相手が知ってそうな内容を使ってたとえ話に置き換えることをしています。
なぜそうするのか、その手法と私の考えるメリットについてブログに書いておきます。
自分はこうしているというまとめ的なものです。

例題

開発工数の見積もりをすぐ出せないということを説明するシーン

Aさん「開発工数ってすぐ出せないものなんですか?」
私  「出せないですね。だいたいはわかるんですけど」
私  「たとえば、カレー作ったことありますか?」
Aさん「はい、作れますよ」
私  「カレーって、だいたい1時間あれば作れるじゃないですか」
Aさん「作れますね」
私  「でも、それって材料揃ってる前提じゃないですか」
私  「冷蔵庫開けてみないと材料あるかわからないとか」
私  「調味料揃ってるか確認しないといけないし」
私  「もしなかったら調達しないといけない。そうなると1時間では作れない」
私  「あと、カレーの種類次第では調理時間かかるかもしれないじゃないですか」
私  「キーマカレーだと1時間で作れないかもしれないから、調べないと答えれない」
私  「それが見積もり作業です。もちろんこれが全てではないです」

なぜやるのか、そのメリット

相手の土俵に立って説明できる の一点に尽きます。
だいたい自分がやっていることを説明するときは、業界でしかわからない専門用語を使いがちで
わからない専門用語が入ってきた時点で相手はその理解に頭を使うようになって、説明はほぼ入ってこないです。
なので、まずは相手の知らない用語をなくす必要があります。

ただ、専門用語なしで説明できる内容もないと思っていて、じゃあその専門用語を相手が知っている用語に変えれば相手も理解できるようになります。
上記の例で言うと「工数調査」を「材料を探すこと」「調理器具を確認すること」「カレーの種類を聞くこと」としています。
これなら相手も知っているので、そのあとの説明を聞く余裕が出来ます。
また、相手も自分が知っている内容なので想像しやすくなります。口頭だけのコミュニケーションはもっとも辛いと考えているので、
相手が想像できることを意識して説明すると自分にも相手にも優しくなります。

どうやるか

とにかく何かにたとえてみる

まずはたとえ話が出来ないことには始まらないので、たとえ話をやってみましょう。
エンジニアに説明する時でも良いと思います。共通言語があるとはいえ、別の言葉で話してはいけない訳ではありません。
自分の知らないことでたとえるのはやめておきましょう。間違った意味になるかもしれません。
話した結果、相手が理解できてないとたとえない方が良いまであるので、もしかしたら練習も必要かもしれない。

相手も自分も知っていることで話す

たとえて話が出来たとしても、たとえた結果がまた相手の知らない話であれば意味がありません。
自分と相手の共通知識で話すようにしましょう
なので、説明する相手をちゃんと理解することも必要です。
これは副次的かもしれませんが、コミュニケーションをとることにも繋がります。
そのメリットもあるかもしれません。

まとめ

本質的なことは何もかけていませんが、普段私が意識してやっていることを文章化しました。
特にエンジニアからマネージャーに転進するとき、必ずエンジニアじゃない方と話をする必要が出てきます。
そのとき、スムーズなコミュニケーションができるテクニックだと思っていますので、
別業種の人と話をするのに抵抗がある方は、一度試してみることをお勧めします。

iOSDC 2018に参加してきました

登壇してきました記事はこちら

taminif.hatenablog.jp

iOSDC 2018に参加してきました。とても良かった。


とても良かった

iOSDCとても良かった。去年も一昨年も良かったけど今年も良かった。
東京ではわからないですが、iOSエンジニアがあれだけ集まるのはそうそうありません。しかもその人たちが知見を持ち寄ってコミュニケーションを行うのですから、これほど情報密度が高い場所ができることはまず個人では難しいと思います。
会社でできてもごく一部だと思います。
そんな場所にいて情報収集すれば当然のように自分が知らない情報が見つかりますし、エンジニアとしてのレベルアップにつながると思います。
こういうコミニュティはどんどん参加できるようにしたい。

もっとも良かったこと

今回、設計話を多くの方とすることができて、改めて設計は大事だと認識しました(6回目ぐらい
こういう時にはこうすれば良い、この時はこうすると大変になるなど
自分のケースで話をさせてもらったり、他だとこうしてるって話は大変貴重で
かつ、上で書いた情報密度が高いのでどれも新鮮な情報でした。
こういうことは独学では限界があるし、事例を元に辛かった話や良かった話を聞けると説得力が違うと思うので、機会の少ない中で最大限学べたんじゃないかと思います。
おそらく、使える言語の種類を増やすより、一本芯の通った設計構想を持つ方が、今後のキャリアに活かせると思います。

辛かったこと

褒めてばっかりだと信者化するので、一点だけ。
交流する機会が多いのはありがたいのですが、やはり3.5日は多いです。行かなかければ良いという意見もあると思いますが、チケットやセッションのことを考えると勿体無いという意識が出てしまってよくなかったです。
特に、地方遠征組なので、行かなかった時に他に何するかの選択肢がなく
朝起きて「行かなきゃ」と思ってしまったことは辛いことでした。義務感で参加するようになってた。
一年に二回やってくれる方が嬉しいかもしれません。正直わからない。

終わりに

iOSDCはコミュニケーションの場です。これから非公式イベントがそれぞれ開催され、もちろんリモートでも参加できる体制を作ってくれているのですが
やはりリモートだと単方向通信になることから、参加するけど本当の意味での参加にはならないと考えています。
その意味で、自分のiOSDC 2018はこのブログでおしまいとなります。改めて言うけどとても良かった。
いずれ関西でもできると良いけど、関西の方とあまり出会えなかったので・・
関西で布教活動はしていきたいと思います。来年同じ3.5日でも参加したいし、他の人にも参加を促したいです。

iOSDC 2018に登壇してきました

iOSDC 2018に登壇してきました。まだ最終日これからですが無事喋り終えたのでブログに残しておきます。

WebSocketをiOSに持ち込んで辛い思いをした経験がありますか!? by taminif | プロポーザル | iOSDC Japan 2018 - fortee.jp

speakerdeck.com


発表について

もちろん言えてないことや公に言いづらいこともあるのですが、だいたい練習通り話せたかなと思います。
想定外でもちゃんとレスポンスできて、良い雰囲気にできたんじゃないかなと思います。

序盤で辞書の画面を見せた時に、知ってたら嬉しいですくらいで流そうと思ってたのですがみなさん手を挙げていただいて
私のUXはとてもよかったんですが、聞いていただいている方々に負担かけてしまいました。
手を挙げてアンケート取るスタイルはあまり良くないと個人的には考えているので(しんどいし)話し方を注意しようと思います。

CfPはタイトルや説明部分が弱かったような気がするので、興味を引ける内容を考えれるようにしたい。

反省

一点だけ、記録として残しておきたい反省点があります。
公開用スライドからは削除したのですが、最後に We are Hiring! のスライドを入れたんですけど、ここは笑いを起こせるような構成にすべきでした。
発表内容で盛り上がっても、このスライドで「あーはいはいいつものやつね」的な感じで出しちゃうと最後まで良いとはならないと思うので
出すからには盛り上げれる話し方や出し方をすべきだったと思いました。
次の発表からは、何か一つボケれるようにしておきたいです。

iOSDCについて

まだ終わってないので参加してきましたブログは別で書きます。
すごく楽しいです。体力はギリギリ。

終わりに

最後まで楽しんできます!

                      /|
                 _,,..-/_/ |
                /|/  /  〃| .|
              / ////// //l
                /ィ/ .//  / ///
             l j  ///i ,,.-'"/
                 ', })、./// //
             l   ヽ-‐</
                 ヽ-|     l
           ___,,..∠_     >-.,,_
          r'--、:::::::::::::`ー―‐'::::::::::::|ヽ
            l    \::::::::::::::::::::::::::::::::::::l ノ
.          | #;;::   ∨:::::::::::::::::::::::::::::/ l
         | ┃ ┃ r':ノ:::::::::::::::::::::::::/  |
          l   ┃ l::::::::::::::::::::::::::/ | .l
         ',   ;: /:::::::::::::::::::::::/|   イ
          } 、 ; {:::::::::::ニ=-‐{ .|    |
            l l  l::::::::::::::::::::::::ヽ|、__i__ノ|
         |`ー―'|::::::::::::::::::::::::::',     .|
          |     |:::::::::::::::::::::::::::i    |