2017年
2017年のまとめ。サクッと振り返り。
去年のはこちら 2016年
仕事/プライベート
振り返ると色々新たなことをやれた年かなと思います
- try!swiftへの参加
- buildersconのコアスタッフ業/アプリ申請
- iOSDCでの発表
しかし、Qiitaやこのブログへのアウトプットが少なかったかなと思っています。
地に足をつけて学んだこと考えていることを外に出して行かないと、インプットするだけの頭でっかちになりそうな気がしているので、
"自分で意味を咀嚼し、自分でそれを素振りし、自分の言葉としてアウトプットする"
必要性を感じた年でした。
✈️
- 石垣島
- 広島
石垣島に言った際は天気があまり良くなく消化不良気味だったので、
また天気が良いタイミングを見計らってリベンジしたいところ。
来年の目標
"勝負どころでは、ごちゃごちゃ考えるな。単純に、簡単に考えろ"
決断力 (角川oneテーマ21)
自分は考えすぎて行動することが遅れ、良くない方向に倒れることが多いので、
良い意味で考えすぎ(フットワークを軽く)ないように心掛けたい。
考えすぎず、行動することで、一つの行動から勢いが付きます。
止まっている岩を押す時も、最初が一番力が必要です。しかし、一度転がりだしてしまえば、力はあまり必要がありません。
止まってしまう時間をいかに少なくするか？がとても大事です。
「勢い」出していくぞ!!
夢追時力発
真田幸村の名言を一つ。
夢をつかんだ奴より、 夢を追っている奴の方が、時に力を発揮する。
言い換えてみると、
「夢を叶えて満足している人よりも、夢に向かって努力している人の方が自分を成長させることができる。」
時にと言っている通り、必ずは保証などできず"夢"を実現するために日々精進することを勧めています。
"夢"と言えるような、大層なものは自分は持ち合わせていないと思っていましたが、
植松努さんのTEDの動画を見てみると、"夢"を持つことの大切さを教えくれます。
夢とは「今できないことを、追いかけること」
やりたいけど、できないと思うことだらけですよね。
そしたら、できることしかやらなくなるんですよね。(失敗したくないから)
けど、少なからず"こうあるべきだ"とか将来"こうなっていたい"みたいな思いはあります。
これも立派な"夢"と言っていいものかと。
できない理由を探すのではなく、できる理由を考える
「どうせ無理を無くそう」
悩むくらいならやってみようと思うこと。"どうすればできる"かを考え、
それに向けて邁進すれば自ずと能力はつくもの == 夢追時力発 なんだろうなぁと楽観的に考えています。
退職した
2017/12/15が株式会社セプテーニ・オリジナルの最終出社でした(退職は12月末)。
約2年の在籍で、GANMA!に関しては業務委託の頃から3年半ほど関わっていました。
現在は2週間ほどある有給を消化しており、来年から社会復帰します。
在職中何してたの
元々は全員が全て出来た方が良いであろうという構想のもとサーバーサイド(API開発)もAndroidもWebも行っていましたが、直近1年間はiOSアプリの運用・開発を担当していました。
を経験できたのはとても貴重でした。しんどい事もありましたが総じて楽しかったです！！
セプオリの良かった事
環境
研修がえげつなく充実していたり、
2017年セプテーニ・オリジナルの新人研修について - Septeni Engineer's Blog
開発合宿楽しそうだったり、
2泊3日の開発合宿に行ってきました！ in 湯河原 - Septeni Engineer's Blog
もちろん、開発環境周りも充実してる。
セプテーニ・オリジナルの開発環境・福利厚生について - Septeni Engineer's Blog
怠けるために、教育に対するコストを惜しまない (怠らない) 点はよかったなぁと思います。
あと、エンジニアの提案ベース(もちろん適正な理由を踏まえた上)で平日の業務時間を活用し合宿を開催できたりと素晴らしいと思います。
技術指針
明文化してあることで共通理解を目指す上での基盤となっており、
技術指針に記載の文化が浸透しているのが好きな所です。
転職の動機
環境を変えたかったです。
慣れによる所だったり、些細なことだったり、まぁ色々ありますが。
プロダクトは好きだし、働く仲間もチームも勿論好きですが、その環境に甘えている自分に気がつきました。
自分は今一度何がしたくて、今後どうなりたいかを考えた際に、
1番の下手くそでいたい
と思ったのが大きいです。
情熱プログラマー1章4からの引用
伝説のジャズ・ギタリストPat Methenyが若いミュージシャンたちにアドバイスするときの決まり文句がある。
「どんなバンドを演るときも、一番下手なプレイヤーでいろ」
...
バンドの中で一番下手くそな存在でいると、不思議なことが起こる。いつの間にか周りに溶け込めるようになっていることだ。
憧れのミュージシャンに溶け込める理由は、僕自身の演奏が彼らの演奏みたいに変化していったからだ。
人間の本能としてプログラムされている集団心理で、集団の習慣などを採り入れようとするものがある。その習性のおかげで、プログラマとしても、チームで一番下手くそでいることで、どういうわけか自分自身が賢くなるんだ。
...そもそも、下手くそだと思える集団に「誘われた」という時点で、自分はそんなにひどいものではない。
そして、一番下手くそになろうと努めたところで、本当にそうはならないものだ。
- 作者: Chad Fowler,でびあんぐる
- 出版社/メーカー: オーム社
- 発売日: 2010/02/26
- メディア: 単行本（ソフトカバー）
- 購入: 24人 クリック: 683回
- この商品を含むブログ (126件) を見る
僕自身が思っているエンジニア感、目指す方向性の中で、
より強くて厳しい環境にて成長していきたかった 1番の下手くそでいたい と考え転職するに至りました。
(勿論、成長に関しては会社に求めるのではなく個人の活動や意識によるところが大きいのも承知な上で)
転職先に関して
正式な入社を終えてから詳しく書こうと思いますが、
- 普段自分自身が使うようなサービスである
- 共に働く人
を重視し決めました。
今後どうするよ
しばらくはiOS専任でより深い知識が求められるような環境で、
「自分自身のブランディング」を目指します。
最後に
転職に際し、最後の機能開発をちゃんと行いたいというわがままを尊重して下さり、日程の調整にも快く応じてくださった皆様には本当に感謝です。
ありがとうございました🙇
また今までお世話になった皆様に感謝しつつ、これからもやっていきます💪
引き続き、よろしくお願いします！
builderscon tokyo 2017にコアスタッフとして参加しました！
builderscon tokyo 2017にコアスタッフとして参加しました。
セッションに関しての感想はどなたかが書いていると思うので、運営として行ったことを書きます。
そもそも何故コアスタッフとして参加しようとしたか
同僚兼運営を行っている@morizoooさんに勢いのある若者枠?として誘われたのがきっかけです。 と言うのは半分本気で半分冗談ww
コアスタッフ用のSlackチームでは勢いのあるアイコンを登録してましたが、いざスタッフMTGで牧さんと初めて会った際にイメージ違うと言われましたね😂😂😂
真面目な事言うと、
- カンファレンスを企画や運営として関わり作り上げていくのは単純に楽しそう
- 主催している勉強会にノウハウを持って帰りたい
- 自分が変わるきっかけが欲しかった
と思い参加を決めました！
スタッフとして何をしたか
- スポンサー様から頂いたロゴの管理/サイトへの掲載
- ボランティアスタッフの取りまとめ、リーダー的なポジション
- 当日はほぼほぼメインホールにいました
- iOSアプリの作成(これは勝手にやりました)
スポンサーロゴの掲載について
まずは頂いたロゴをレギュレーションに沿って加工します。
最初は作業に時間がかかったのですが、慣れてくると楽しいものですね、Illustrator力、Sketch力が上がりました💪
次にスポンサー登録です。こちらに関してはほとんどが自動化されているので脳が死んでてもできました(自動化最高！)
ボランティアスタッフの取りまとめについて
事前にtwitterやブログで告知を行い、たくさんの方にご協力して頂きました。本当にありがとうございます！！！
monmonさんはじめ当日スタッフの皆様から学ぶことはとても多かったです！
他にはスタッフ向けのあんちょこ作成を行いました。
- 受付スタッフのやる事リスト
- 部屋スタッフのやる事リスト(録画確認、タイムキーパー作業など)
- 司会のカンペ
- その他(ゴミ捨てや避難経路など)
などを記載したチートシートですね。これを大量に印刷し配りました(任意でスマホにもPDFのインストールもしてもらいました)。
現在はbuilderscon tokyo 2017に特化した内容となっていますが、汎用化できる余地はあるので修正し公開したいなと思っています。
当日の作業について
前夜祭では名札を配ったりノベルティを渡すなどの受付補助を行いました。
当初はPeatixのチケット番号と紐づいた名札番号を目グレップで探しあて渡すというなんとも原始的な作業で効率が悪かったので、机の位置を調整しつつ直接参加者の方に探して頂くなど工夫をしました。
アイデアを出しトラブル対応や効率化を測るのもスタッフとしての醍醐味ですね。(目グレップ中はSlackを開く余裕が無かったので、炎上案件しゃもじで増員を求めたかった。。)
2, 3日目はメインホールのリーダーを@uessy_akrさんと一緒にやりました。
1番の懸念点だった同時通訳用のレシーバーの紛失ですが、こちら全て回収できました！！！！！！！
回収の協力をしてくださった参加者のみなさんありがとうございます！
大きなトラブルもなくこなせたかなーと思いつつも、2階席がある部屋での質問者へのマイク受け渡し係の配置や、照明の調整など次回改善すべき課題も見つかったなといったところです。
iOSアプリ作成
うん。とにかくブラックでしたw
マジでこれはきつかった
— ざわざわ👻 (@to4iki) August 4, 2017
#builderscon
反省/改善点は山のようにありますが、とにかくアイデアを出しからの着工が遅すぎた！これに尽きる。
また、ネタバレになるので書けないのですがビルコン開催中にさらなるトラブルがありました。。
やはり炎上案件しゃもじが欲しかったですねー
詳細はiOSDC Japan 2017で報告したいと思います！
設計に関してのエントリがあるので興味のある方は是非！
to4iki.hatenablog.jp
参加してみて
クロージングスピーチでの牧さんの言葉がとても印象的でした、
技術力は当然だが、「つながり」が重要なのではないか
カンファレンスでは自分の「安全地帯」の外に飛び出そう
今回スタッフ&アプリ作成をしているのもあって声を書けてもらうことが多かったです。
自分からも懇親会などで多くの人に声をかけ話すことができました。
普段属するコミュニティを越え全く異なるバックグラウンドの人たちと話すこともできました。
スタッフという立場でもありますが、いち参加者として新たなつながりを持てたのはbuildersconのおかげです。
控えめにいって最高でした！
来年があれば、自分で企画考えたり、スピーカー側に行けたらいいな！
最後に
ペパボラップの歌詞どんなだっけなと気になり出してまた聞いている← #builderscon
— ざわざわ👻 (@to4iki) August 6, 2017
builderscon iOSアプリの簡易説明
先日、スタッフとして関わっているbuildersconのiOSアプリをリリースしました！🎉
本エントリで簡易的なアプリの紹介と構成の紹介を行います。
追記
この紹介は v1.0.0 時点でのアプリ構成を説明しており、
最新版では構造など更新が入っています。
機能
- 複数日付のタイムテーブル表示
- フロアマップ表示
- QRコードーリーダーの搭載
構成/設計
project構成はDDDのレイヤードアーキテクチャをベースに、
関心毎の分離(描画処理と業務ロジック)ができるよう下記のような構成にしています。
── AppDelegate.swift
├── data
│ ├── dataSource
│ │ └── SessionDataSource.swift
│ ├── extension
│ │ ├── CollectionExtension.swift
│ ├── storage
│ │ ├── DiskCache.swift
├── domain
│ ├── repository
│ │ └── SessionRepository.swift
│ ├── translater
│ │ ├── TimetableTranslater.swift
│ └── usecase
│ └── TimetableUseCase.swift
├── environment
│ ├── Config.swift
└── presentation
├── view
│ ├── Timetable.storyboard
├── viewController
│ └── TimetableViewController.swift
└── viewModel
├── Timetable.swift
当初はレイヤー毎の責務分離がはっきりしている + テスタビリティが高いClean Architectureの導入を考えていたのですが、
- 現状、そこまで複雑なアプリになりえない想定だったのでオーバースペック気味
- とにかく時間がなかったので開発速度優先
- 但し、責務分離の観点で費用対効果が高そうなクラス分けは取り入れる
上記3点の理由から一部取り入れています。
描画
複数日付のタイムテーブルの表示には、下記2つのライブラリを使用しています。
セル結合部分はとても泥臭い実装をしているので、リファクタリングしたいところ。
ネットワーク関連
buildersconにはAPIが用意されています
JSON Hyper-Schemaに対応しているので、これに沿った形式でSwiftのマッピング用のクラスを生成できればよかったのですが、最初は必要な項目も限られるし自分で定義した方が早いなと判断し自前でクライアントを作成しました。
クライアントはコールバックベースで完了時の処理を実装しているのですが、
ネストが深くなってきた + テストが書きづらいという理由から、呼び出し側で非同期オブジェクトを返すような形式にラップしたいなと考えております。#61
キャッシュ
当初よりオフライン及びキャッシュ対応はマストで入れようと決めていたので、下記の方針で実装しています。
- 初回アプリインストール後はディスクに書き込んだデータを使用
- Repositoryの実装で、ディスクから取得するかAPI経由で取得するかを隠蔽(API経由で取得した場合はディスクに書き込み)
- 起動時にAPI経由で最新のデータを読み込みバックグラウンドでディスクに書き込んでおく
3つめはpull to refresh(引っ張って更新)でデータ再取得/再描画すべきだとは思いつ、初回バージョンでは富豪的にAPIを叩くようにしています。
Repositoryの実装はこんな感じ
func find(completion: @escaping (Result<Conference, RepositoryError>) -> Void) { localDataSource.find { localResult in if case .success(let value) = localResult { completion(.success(value)) } else { self.remoteDataSource.find { remoteResult in switch remoteResult { case .success(let value): completion(.success(value)) self.localDataSource.store(value) { writed in if case .failure(let error) = writed { log.error("store error: \(error.localizedDescription)") } } case .failure(let error): completion(.failure(.find(error))) } } } } }
うう、ネストが深い。。
また、APIのtokenを公開できない都合上、普段開発するDebugビルドの際にはプロジェクトに埋め込んだFileからデータを読み込むようにしています。
開発手順
セットアップ
リポジトリは個人アカウント配下にありますが、ゆくゆくはbuilderscon配下に移動予定です。
READMEにも書いてありますが、
Ruby製のツール(fastlane..)を幾つか使用しているので、Bundlerでローカルにgemの依存をインストール。*1
$ bundle install --path vendor/bundleiOS/Swift関連の依存ライブラリをCarthageを使ってインストール。
$ carthage bootstrap --platform iOS(任意)SwiftLintをローカルマシンにインストール。
ビルド
シミュレーターで開発する分には、Xcodeでprojectを立ち上げProduct > Run(⌘R)で実行可能です。
実機に転送したい場合は、Xcode8.xでのiPhone実機デバッグメモ - Qiitaを参考に、projectファイル内のSigning/Teamを自分の登録してあるAppleIDに置き換え試してみてください。
まとめ
ざっくりとアプリの全体像を説明しました。
まだまだ追加したい機能やbugfixもあります(Issues)ので、ご興味のある方はPRを送ってくれると嬉しいです！
そして皆さん！ 8/3, 4, 5にbuilderscon tokyo 2017が開催されます！
参加する方は、是非アプリをインストールし使ってみてくださいー！😄
*1:現時点ではマストではないので、1はスキップ可能
try! Swift Tokyo 2017に参加した
3/2~3/4に開催された www.tryswift.co
に参加してきました。
会社からの支援でチケットは購入して貰っていたので一般参加者として。
またカンファレンスの裏側の仕組みを知りたい。少しでも貢献したいと思いボランティアスタッフをやらせてもらいました。
ボランティアスタッフとして何をしたか
簡単に紹介すると
- 設営
- スポンサーブースのお手伝い
- ノベルティ(シールやパンフレット)をエコバッグに詰める作業
- 受付の案内
- 質問時のマイク係
を行いました。
700名の受付という事もあり、時間をかけすぎたら後続が詰まるという焦りの中なんとかこなせたと思います。
日本人以外の参加者も多いカンファレンスという事もあり 、慣れない英語での対応に苦労しました。。
セッション開始後は、マイク係として会場袖に待機。
try! Swiftは1トラック構成で行っているので、ほぼほぼ全てのセッションを見ることが出来ました😊
参加者として
#tryswiftconf をひたすら眺める&呟いていました。
幾つか気になったセッションの内容をメモしていたので共有します。
テスト可能なコードを書くということの２つの側面
@mbrandonwさんのセッション
関数を完全にテスト可能にするためのものが２つあります。作用の分離と共作用を表面化です。この２つの側面の背景にある理論を探り、どのようにすればテスト容易なコードに導けるかを示します。
サンプルコード: 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
- 6万アプリしかSpotlight検索に対応していない
- iOS10以降は、Spotlight検索をアプリ内で継続できる
- SearchAPI
Spotlightで色んな情報を検索でき、Spotlightからアプリにスムーズに遷移できるものです。
- WWDC2015で発表されたiOS9 Search APIsまとめ - NSBlogger
- iOS 9の「Search API Best Practices and FAQs」が公開されたので読み解いてみた - Qiita
- AppSearchに表示したくないという場合、CSSearchableItemにexpirationDateセットする
- UniversalLinks
- 以前まではwildcard形式で対応していたが、一部ページを除外したいときはNOTを使うようにする
- App Searchプログラミングガイド：ユニバーサルリンクへの対応
- Spotlight経由で50%のお客さんがアプリを起動している？
@niwatako さんの書き起こし niwatako.hatenablog.jp
ハッカソン
3日目のハッカソンは参加者として参加しました。
アクターモデルに関して知見はなかったのですが、並行処理はもちろん、
iOSにおける通知実装の一つの案として興味があったので、今回作成するSwiftActorのサンプル実装を書きました(未完成..)
惜しくも入賞は逃してしまったけど、
@rizumitaさん @ikesyoさん @applideveloperさんはじめ、優秀な方々と貴重な時間を過ごせてとても楽しく勉強になりました!
(iOSクライアントの実装において、アクターモデルの有用性を示すのは中々難しかったです。。)
SwiftActorの開発は継続していくので、興味のある方はPRを!*1
参加してみて
- 国際色豊か、Swiftのことを話し合う最高の"場"でした
- 英語ちゃんとやろう
- Rikoちゃんかわいい
Meet Riko 👏👏👏 Thank you @yucovin for the design & @zen_prog for the name! #tryswiftconf pic.twitter.com/P7Ukte8rl6
— try! Swift Tokyo (@tryswiftconf) 2017年3月3日
*1:Slackチームもありますよ
