try! Swift Tokyo 2017に参加した

3/2~3/4に開催された www.tryswift.co

に参加してきました。

会社からの支援でチケットは購入して貰っていたので一般参加者として。
またカンファレンスの裏側の仕組みを知りたい。少しでも貢献したいと思いボランティアスタッフをやらせてもらいました。

ボランティアスタッフとして何をしたか

簡単に紹介すると

  • 設営
    • スポンサーブースのお手伝い
    • ノベルティ(シールやパンフレット)をエコバッグに詰める作業
  • 受付の案内
  • 質問時のマイク係

を行いました。

700名の受付という事もあり、時間をかけすぎたら後続が詰まるという焦りの中なんとかこなせたと思います。
日本人以外の参加者も多いカンファレンスという事もあり 、慣れない英語での対応に苦労しました。。

セッション開始後は、マイク係として会場袖に待機。
try! Swiftは1トラック構成で行っているので、ほぼほぼ全てのセッションを見ることが出来ました😊

参加者として

#tryswiftconf をひたすら眺める&呟いていました。
幾つか気になったセッションの内容をメモしていたので共有します。

テスト可能なコードを書くということの2つの側面

@mbrandonwさんのセッション

関数を完全にテスト可能にするためのものが2つあります。作用の分離と共作用を表面化です。この2つの側面の背景にある理論を探り、どのようにすればテスト容易なコードに導けるかを示します。

サンプルコード: kickstarter/ios-oss

  • テストの目的は、"テストできるコードだけを書きたい"から
  • テスト対象の入/出力に関しての話
  • アウトプットのテストが難しいのは副作用(side effects)があるから
    • => 副作用をコードの境界に持っていく
  • インプットを難しくしているのは共作用(co effects)があるから
    • ある特定の世界の状態がなければ実行できないということ
    • => テストの為に特定の世界を作る(DIと呼ぶ人もいる)
    • 共作用に対してグローバルな関数に直接アクセスしなくて良いように EnvironmentStruct を作成する ios-oss/AppEnvironment.swift
    • テストコードはwithEnvironmentで任意の環境(グローバル変数)を上書きしつつ、テストを実行できるようにしてる ios-oss/XCTestCase+AppEnvironment.swift

@niwatako さんの書き起こし niwatako.hatenablog.jp

iOSにおけるDocument IndexingとApp Search

@gridNAkaさんのセッション

ZalandoのiOSアプリでApp Search機能をどのように使っているのかを説明し、さまざまなタイプのコンテンツ向けのApp Search機能を紹介し、経験と実例を共有します。

サンプルコード: gridNA/appSearchExample

@niwatako さんの書き起こし niwatako.hatenablog.jp

ハッカソン

3日目のハッカソンは参加者として参加しました。

devpost.com

アクターモデルに関して知見はなかったのですが、並行処理はもちろん、
iOSにおける通知実装の一つの案として興味があったので、今回作成するSwiftActorのサンプル実装を書きました(未完成..)

github.com github.com

惜しくも入賞は逃してしまったけど、
@rizumitaさん @ikesyoさん @applideveloperさんはじめ、優秀な方々と貴重な時間を過ごせてとても楽しく勉強になりました!
(iOSクライアントの実装において、アクターモデルの有用性を示すのは中々難しかったです。。)

SwiftActorの開発は継続していくので、興味のある方はPRを!*1

参加してみて

*1:Slackチームもありますよ

迷いなく行動する

而今(にこん)とは、禅問答の言葉で

「今という瞬間」は二度と戻ってこない 「過去」や「未来」をあれこれ思い悩むのではなく今を一生懸命に生きるという教え

この言葉を自分なりに解釈すると、
今を後悔せず、 “迷いなく行動する” ことだと思った。

失敗を選択することがあった際に、ヘコんでしまう時はある。
現状を分析し、未来に不安がる時もある。

但し瞬間瞬間の判断において、出来るだけ迷いは無くしていきたい。
迷うとブレる、自信が無くなる(無さそうに見える)、勿体無い。

2016年

2016年のまとめ。サクッと振り返り。

去年のはこちら 2015年

仕事

昨年度に引き続きiOSを中心に。

など下回りの整備などを数多くこなしていました。

もちろん、下回りの整備/改善系は腐敗を防止(遅らせる)ために必要な作業です。
ただ今年はそこにフォーカスしすぎたのかなと少し反省しています。

来年は、もう少し機能開発とのバランスを意識しようと思います。

プライベート

  • Qiitaに4記事
  • はてなブログ(読書ログ中心)に14記事
  • その他、#shinjukultという身内だけのコミュニティで3回ほどLT

昨年と変わらずくらいのアウトプット量かなと。

来年はより技術的なアウトプットを増やし、対外的な自分マーケティングを意識したいところ。*1

旅行

南の方を中心に(宮古島ベトナム、台湾)
来年もあったかいところに行きたい🌞

来年の目標

  • 個人のプロダクトを持つ
  • iOSに特化しつつも、脇差を準備しておく
  • 対外的なアウトプットを増やす

*1:多少、手段と目的が逆になっても良いところだと考えている

「最強シンプル思考術」を読んだ

スーパープログラマーに学ぶ 最強シンプル思考術

スーパープログラマーに学ぶ 最強シンプル思考術

ものごとに対する本質を見抜く思考法 "モデルベース思考"についての本

TL;DL

  • モデルは意図を説明する存在、知識を"要約"したシンプルで分かりやすい説明
  • "モデルを作る"と"思考する"の両輪を回していくのがモデル化
  • 要素・事象をどのように分割するか、関係性から抽象化・具体化を考えどのようにバラしていくか、バラした要素からどのように全体を適切に説明できるようになるかの往復運動(思考)こそがモデル作りの本質

モデルとは

  • 根本は無駄を省いて物事をシンプルに考える
  • シンプルに考えるためにモデルを使う
  • モデル: 複雑なものごとをシンプルに表現したもの
    • 型がモデル

モデルの作り方

  • 四角(要素)と線(関係)だけであらゆるものに関するモデルを作成できる
  • "分かることは分けること"

モデルを作るメリット

  • モデルを作ると、漏れなく、重なりなく 物事が整理されていることが確認しやすくなる

より良いモデルを作るには

  • なんのためにモデル化するのかを一言で表してみる
  • 具体 is a 抽象
  • 抽象化とは汎用性を高めること。汎用性を高めることで広い文脈でモデルを用いることが出来る
  • モデルを使う場面を意識して、その場面や目的に合った抽象度でモデルを作る

「POODR」を読んだ

Practical Object-Oriented Design in Ruby

オブジェクト指向の規則が纏まっている本。
(依存関係を管理し、インターフェースを作るためのコードの書き方についての規則)

設計に緊張が伴う理由は、これらの規則を破るためです、上手に破ることを学べば、それは設計者の一番の強みとなります。

TL;DL

ソフトウェア設計の核は

  • 作成するソフトウェアの共通部分を探し出しモジュール化する
  • 作成するソフトウェアが将来変更される部分を抽象化し変更しやすくする

1.オブジェクト指向設計

  • オブジェクト指向設計とは多態を実装する部分を決めること、依存関係の管理
    • 如何にI/Fを定義するか、実装オブジェクトを隠し抽象I/Fでやり取りをする
    • 「対応しない」責任を決めることが鍵
  • 設計の行為と実装の行為が乖離したとき、オブジェクト指向ソフトウェアは失敗する
  • 少し知識を得たころが危険。知識が増え、その見返りを求めるようになり、執拗に設計するようになってしまう
  • 不適切な場所に原則を適用し、存在しないところにパターンを見出す。手段と目的が逆になりがち

2.単一責任のクラスを設計する

  • クラスを変更する理由は複数存在してはならない
  • = 一つのクラスには複数の責任(=役割)を持たせない
  • 提供したい機能(責任、役割、関心)
  • 1つのクラスに専念するクラスは、その1つのことをアプリケーションの他の部位から隔離します
    • この隔離によって悪影響を及ぼすことのない変更と重複のない再利用を実現する

3. 依存関係を理解する

  • メソッドチェーンは依存を作り出す
  • DI, 依存の隔離, 抽象への依存
    • クラス内で別のインスタンスを作成するのはやめよう(生成は外で)
    • クラス名を知っておく責任、そのクラスに送るメソッド名を知っておく責任がどこか他のクラスに属するのでは
  • 依存方向の選択
    • “自身より変更されないものに依存しなさい”
    • 領域分け, 方向の制御

4. 柔軟なインターフェースを作る

  • 再利用困難 = 自身について外部に晒しすぎている + 近隣オブジェクトについて知りすぎている
  • 合意と約束を意識する
  • このクラスが必要なのは知ってるけどこれは何をすべきなんだろう => このメッセージを送る必要があるけど誰が応答すべきなのか
    • メッセージを送るためにオブジェクトは存在する
  • オブジェクトがそのコンテキストから完全に独立していることが求められる
  • 誰の責任なのかを明確にする、知識を隔離する
  • 「どのように」を伝えるのではなく「何を」頼むか
  • 「私は自分が何を望んでいるかを知っているし、あなたがあなたの担当分野をやってくれると信じている」
  • 明示的なI/F: 「どのように」よりも「何を」になっている
  • リファクタリング: デメテルの法則(Law of Demeter, LoD)

5. ダックタイピングでコストを削減する

  • オブジェクトが何で「ある」かではなく、何を「する」か
  • ポリモーフィズム: 多態性(多岐にわたるオブジェクトが同じメッセージに応答できる能力)
    • メッセージの送り手は受け手のクラスを気にすることなく、受け手はそれぞれが独自化した振る舞いを提供する

6. 継承によって振る舞いを獲得する

  • 継承とは根本的に"メッセージの自動委譲"の仕組み
    • 理解されなかったメッセージに対して転送経路を定義する
    • 2つのオブジェクト間の継承関係を定義するだけで転送を自動で行う
  • サブクラスはそのスーパークラスを"特化したもの"
  • 新たな継承の階層構造へとリファクタリングする際は、抽象を昇格できるよう具象を降格させないようにする
  • サブクラスがsuperを送る == そのアルゴリズムを知っている
    • p172. post_initialize のようなフックメッセージを用意するだけ。そうすることで、サブクラスは必ず super を呼ぶ責任から逃れら れます。「いつ」初期化が行われるか知らなくてよいのは大きい。結合度の低減です。

7. モジュールでロールの振る舞いを共有する

  • オブジェクトは自身を管理すべき = 自身の振る舞いは自身で持つべき StringUtil.empty(“”)
  • クラスによる継承 == である(is-a) / モジュール == のように振る舞う(behaves-like-a)
  • サブクラスはスーパクラスと置換できる(リスコフの置換原則)
  • サブクラスとスーパークラス疎結合にする(サブクラスからsuperの送信をしたくない)
  • サブクラスが自然と特化できるようにテンプレートメソッドパターンを用いる

8.コンポジションでオブジェクトを組み合わせる

  • コンポジション: 組み合わされた全体が単なる部品の集合以上となるように個別の部品を複雑な全体へと組み合わせる行為
  • 大きいオブジェクトと部品がhas-a関係になることで繋がる
  • コンポーズされたオブジェクトは"ロール"を担うオブジェクトのI/Fに依存する
  • 集約はコンポジションのようなものだが、独立したライフサイクルを持つ
    • コンポジッションは親が消えたら自身も消える、集約は消えない

9. 費用対効果の高いテストを設計する

  • テストの目的はコストの削減
  • 良い設計は自然と抽象に依存する、独立した小さなオブジェクトの集まりになる
  • テストはオブジェクトの境界に入ってくる(受信する)か、出ていく(送信する)メッセージに集中すべき
  • オブジェクトは自身のパブリックインターフェースを構成するメッセージに対して"のみ"、状態についての表明を行うべき
  • 受信メッセージはその戻り値の状態がテストされるべき
  • 送信コマンドメッセージ(副作用)は送られたことがテストされるべき
  • 送信クエリメッセージはテストするべきではない(受け手のパブリックインターフェースの一部なので、必要な状態のテストはそちらで実装しているため)
  • テストダブルとはロールの担い手を様式化したインスタンスで、テストでのみ使われる
  • 大量のプライベートメソッドを持つものは新しいオブジェクトが負う責任かもしれない
  • 状態のテストとは対照的にモックは振る舞いのテスト。メッセージが何を戻すかを表明するのではなく、メッセージが送られているという期待を定義する
    • 送信メッセージが送られたことの証明は、モックに期待を設定すれば終わり
  • 最も良いテストとは対象のコードと疎結合であり全てに対して一度だけテストをし、それが適切な場所で行われているもの(コストを上げることなく価値を追加する)

See also

「小さなチーム、大きな仕事」を読んだ

小さなチーム、大きな仕事〔完全版〕: 37シグナルズ成功の法則

小さなチーム、大きな仕事〔完全版〕: 37シグナルズ成功の法則

  • 作者: ジェイソン・フリード,デイヴィッド・ハイネマイヤー・ハンソン,黒沢 健二,松永 肇一,美谷 広海,祐佳 ヤング
  • 出版社/メーカー: 早川書房
  • 発売日: 2012/01/11
  • メディア: 単行本
  • 購入: 21人 クリック: 325回
  • この商品を含むブログ (36件) を見る

「37シグナルズ」の仕事を行う上での哲学・思想が詰まった本

仕事の進め方だけではなく、生産性をどのようにして維持するか、競合相手についてどう考えるか、プロモーションをどう行うか、人を雇うときの考え方、どのようにしてダメージコントロールするか、会社文化に対する考え方など多方面の話題に触れている。

著者のビジネス体験がそのまま綴ってあるが、根本の考え方は"ソフトウェア開発"(小さく回していくアジャイルUNIX思想)に通ずるものがあると感じた。

TL;DL

思うだけでは何も変わらない。動き出すこと(形にすること)が大切

気になった箇所をメモ。

計画は予想にすぎない
  • 計画を作っただけで、実際には制御できないものをコントロールした気になる
  • 計画なしに仕事をするのは恐ろしく思えるかもしれない。しかし現実と折り合わない計画にしたがうのは、もっと恐ろしいことだ
失敗から学ぶことは過大評価されている
  • してはいけないことについては学べるが、次になにをすべきかがわからない
  • 一方で、成功から学ぶことは、次の手段を与えてくれる
制約を受け入れる
  • 少なければ少ないほどよい。資源が制限されると、それでなんとかしなければならなくなる。そこに無駄の余地はなく、創造性が求められる
  • 中途半端な一つの製品ではなく、よくできた半分の製品
  • ディテールは後から
決断して前進する
  • これについて考えようではなく、これについて決断を下そうと思う
  • 何かを説明する必要があるときそれを形にしてみよう
解決策はそこそこのもので構わない
  • 柔道のような(最も少ない動きから最も多くを得る)解決策を見つける
  • その課題をとっとと片付けて次につなぐ何かを作るだけ
熱意を優先順位と混同するな
  • 「素晴らしいアイデア」はしばらく棚に上げておこう
  • イデアを思いつくことはいいことだ。落ち着いてから、そのアイデアの優先順位を評価しよう
ヒーローにはなるな
  • やめることが最善の方法となりうることを覚えておこう
  • 本当のヒーローは、仕事をさっさと片付ける方法を見つけだし、とっくに帰宅している
基本的にノーと言おう
  • ただ正直でいよう
料理人を見習う
  • 彼らが有名なのは、自身の知っていることを全て外に出し皆と共有しているからだ
  • 共有することを恐れてはならない
造花が好きな人はいない
  • 欠点を見せることを恐れてはならない。不完全さはリアルであり、人はリアルなものに反応する
  • 不完全の美しさ(ワビサビ) = 本質だけになるまで切り落とす。だが詩を取り除いてはいけない
文化は作るものではない
  • 文化はつくるものではなく、自然に発達するものである。新しい会社には独自の文化がない
  • 文化とはふだんの振る舞いの副産物だ。文化とは方針ではない。無理に文化をつくろうと考えないこと。熟成には時間がかかる
  • いる人の振る舞いや思い考え方が文化になる
ひらめきには賞味期限がある
  • イデアは不死身だ。永遠だ
  • 一方ひらめきは永遠に持続できるものではない
  • ひらめきとは「今」のものだ。虜にされたら仕事に専念すること

See also

雑に考えてみる

雑な発想を活かすチーム作り - クックパッド開発者ブログ

GitHub上にリポジトリを作成するのも、そうだけど、 ローカルマシンに"zatsu"ディレクトリを作成して、 ここに雑にメモした文章や一時的に試してみた系のスニペットなど格納することにしよう。

todoistに”雑”プロジェクトも作成したので、雑なタスクはここに追加していこう。

雑アイデアをタスクへ
雑な発言を許容することは、常に志向を発散させることに他なりません。業務プロセスとして雑さを扱うためには、これを然るべきタイミングでうまく収束させる必要があります。

もちろん、"雑"を"放っておくと意味のないものがたまるだけなので、 然るべきタイミングで棚卸ししないといけない。