note株式会社 / iOS エンジニア
未来
未来
今はなにをやってみたいのかわかっていないのですが、 習慣化、ドキュメンテーション、タスク管理など生活と近いサービスにかかわりたいなとおもっています。
2019年11月 - 2022年3月
個性を考慮して行動変容を支援するソフトウェアの開発
未踏アドバンストに採択されたプロジェクトのメンバーとして開発を行いました。 プロジェクトには大きく分類して、4つの開発を行いました。 - Python を使った機械学習 - Rails を使ったウェブサービス - 過去の実績で使った React Native アプリ - 実証実験用の複数の Flutter アプリ これらをつかって、個人個人にあわせた習慣化を支援するというプロジェクトになります。 Rails, React Native, Flutter アプリの開発が私の担当範囲となります。 Pythonの機械学習のアルゴリズム自体の選定などにはかかわっていませんが、部分的には開発を行いました。 React Native 版アプリは古いアプリだっため、現在の環境ではうごかない状態でした。 最新にしたかったのですが、一部ライブラリの開発がとまっていてうごかないなどの問題があったため、その部分を取り除いたりし、中途半端にうごく状態にまでもっていき、Flutter でアプリを作り直しました。 Flutter では、手洗いを支援するアプリ、学習を支援するアプリ、コンテンツ閲覧をうながすアプリなどを開発しました。 このうち、開発の中心だったのは学習を支援するアプリで、これが前述のRNで作られていたアプリでした。
2020年4月 - 2021年2月
Flutter アプリ開発
WebView を中心としたFlutterアプリ開発を行っています。 Flutter の WebView Plugin には公式のものとコミュニティのものがあり、プロジェクトの当初は公式のものの完成度が非常に低かったため、flutter_webview_pluginというコミュニティのものを使っていました。 1年ほどたったころ、アプリのメンテナンスの一環として、webview_flutter プラグインに変更しました。 - Flutter - Provider - Firestore - Firebase Cloud Messaging - Web側からカメラや Web RTC を使った機能 また、各種データや通知を管理する管理画面( Hosting ) も開発しました。 Flutter は基本的に非ネイティブですが、webview については各プラットフォームのネイティブのものが使われています。 そのため、プラットフォームに依存した不具合が発生したりもしました。 具体的には、 - カメラやWeb RTCを使う際の権限まわり - アラートの表示 これらをプラグインに手を入れてバイパスするようにしたり、不具合を修正したりしました。 GitHub Actions を使いテスト、ビルド、デプロイまで行っています。 またサービスによっては、Rails や TypeScript で管理画面を作ったりもしています。
2019年11月
2015年4月 - 2019年10月
RDSのデータをBigqueryに入れる
提供していたサービスの内容上、かなり重要な個人情報を持っている状態でしたが、このプロジェクト以前では、ユーザのデータは本番 DB の中にだけ存在し、統計分析や解析などを実施することはほとんどできませんでした。これらのデータから個人情報に該当するデータなどを削除し、匿名化を進めたユーザデータを BigQuery にも複製するということを行いました。 ただし、データベースの規模的に全てのデータを同期し続けることは困難で、日毎の partitiontime を設定して管理するようにしました。 データの移行には Embulk を使い、データが正しく入っているかどうかの確認のために、GAS を使って Bigquery のレコード数などを Slack に投稿するようにしました。 バッチ処理は Kuroko2 を使い実施しています。 このプロジェクトの保守は現在も継続して行っていて、最近ではいれるデータの文字を正規化したりするなどを増やしています。
2016年5月 - 2019年11月
オフィス内のネットワーク環境とJenkinsの整備
以下の文章を書いたときには Jenkins 大好きでしたが、今は、Github Actions と Self hosted runner にくら替えしています。 Self hosted Runner すごくいいです。 ---- あまり優秀な Jenkins おじさんはできていないですが、社内で Jenkins のマネジメントをしています。 また、Jenkins のアイコンなどを使って、ChatOps 的に Reply を投げると指定したブランチのアプリをビルドしたり、Github の issue の進捗度合いなどを Slack に投稿する偽 Jenkins の管理をしています。 社内ではそれらの、Jenkins の皮を被っただけの偽物も含めて Jenkins と呼んで、親しまれています。 それぞれの ChatOps 機能などに、独自のアイコンを使うというのもよかったと思うのですが、Jenkins というペルソナを勝手に作って、テストが落ちているときは怒っている Jenkins、通ったらいつもの Jenkins といった風にしたのは、いい選択だったと思っています。 何故ならば、特定のキャラクターとしての Jenkins がいるおかげで、会話の中で話題にしやすくなる。また、多機能な Jenkins となっているので、じゃあ、あれも Jenkins にやらせてみようか。という風に気軽に機能を追加しやすくなりました。 Jenkins などではなく、アイドルアイコンでやるというのもありとは思うんですが、テストが通らなくて、そのアイドルのことが嫌いになるといったことがおこると非常に良くないので、Jenkins というのはちょうどいい距離感のおじさんだと思います。 Jenkins 愛が強くてポエムになってしまっているのですが、「Jenkins」でやっていることとしては。 - Deploygate への複数ターゲットの Deploy (Jenkins) - Danger の実行 (Jenkins) - Carthage や Bundle のアップデートおよび、テスト、Pull Request の作成 (Jenkins) - Unit Test (Jenkins) - UI Test (Jenkins) - iTunes Connect 用の Build ( Jenkins ) - ChatOps で特定の Branch を Build ( Jenkins, hubot) - 朝会のお知らせ ( AWS Lambda) - Issue の進捗状況(AWS Lambda) - 定期的なタスクのお知らせ (AWS Lambda) - Bigquery へのデータ送信状況 (GAS) - 本番環境、ステージング環境へのデプロイ - etc GAS や AWS Lambda を使っているのはそれぞれのリソースにアクセスする必要があったりするためです。(Jenkins)と書いているのは Jenkins CI で動いている Jenkins です。また、Jenkins でやっていることの多くは、Fastlane を使って実装されています。 社内で Jenkins を快適に動かし続けるために、社内の WIFI についても管理しています。 Jenkins サーバ自体は、止まると絶対に仕事ができなくなるみたいなものではないので、結構オフィスの端っことかの微妙な位置にいます。そのため、そこまでしっかりと Wifi を飛ばすためには少しは、Wifi について考えないといけないという状態になります。 したがって、Jenkins にいいネットワークを用意することは、オフィスにいいネットワークを用意することに繋がります。RTX1210 とバッファローの WifiAP を組み合わせて、社内ネットワークを構築、管理しています。 結局、Jenkins は WifiAP のそばに置くことになったので、それほど Jenkins にはネットワークの状況は関係なくなったのですが、継続して RTX1210 と AP を管理しています。
2015年7月 - 2019年11月
開発環境の改善
iOS アプリチームに以下のツールやサービスを導入し、Developer experience を向上させました。 - Bitrise - Danger - SwiftLint - SwiftFormat - Fastlane なお、現在 Bitrise と Jenkins を併用しているのですが、Bitrise 一本にする予定です。 CI では、以下の処理を行っています。 - テスト - ドッグフーディング用のデプロイ - リリース用デプロイ(審査にも出します) - Danger Swiftlint や、SwiftFormat は Xcode で実行するようにしています。 これらを導入したことで、無駄やなんどもやることにかかる時間がへり、快適な開発環境を導入できました。
2015年4月 - 2019年11月
ISMSおよび銀行API契約関連,電子決済等代行業者取得に向けた準備の補助
このプロジェクトは,技術関連の内容よりも事務やオフィスのセキュリティ対策といった内容が中心となります.ただし,このプロジェクトをもとに技術関連の作業が必要となる場合もありましたが,インフラプロジェクトなどに含まれているためここでは,それ以外の部分いついて書きます。 現職はユーザの個人情報や比較的コアな情報を取り扱う業種だったため,ISMS を数年前に取得しました。 セキュリティに関連する資料や規則,文章としては存在していなかった現状の明文化などの補助を行いました。 また,銀行などと契約する際に,社内のセキュリティについて取りまとめたチェックシートを作成する必要があり,その作成などを行なっていました.セキュリティチェックシートは,まるで尋問されてるみたいと言わせるような,過酷なものでした。 電子決済等代行業の取得にさいしても、同様に進めました。
2019年1月 - 2019年9月
Titanium アプリからSwiftアプリへの移植
400 万ダウンロード以上されていた Titanium アプリを Swift を使いほぼスクラッチで作りなおしました。 期間としてはおよそ 2 年かかっています。最初の 1 年はほぼ私一人で、後述のプロジェクトや他の業務の傍進めていました。 かなりの期間私一人、もしくは、私と業務委託やアルバイトの方という状態でした。そのため、基本的なアプリの設計や技術選択、実装などは私が行いました。 比較的新しい技術、自動化、結合度、凝集度などを考えて設計を進めていました。 元々のアプリは高機能ではあったのですが、仕様書や完全な API 仕様書などがほとんどなかった状態が一番大変でした。それ以外は、ひたすら機能を作り続けていくというだったため、困難さという点では最初に基本的な設計方針などを決めた後はひたすら実装を進めていくという内容でした。 使っているライブラリや技術としては、以下のものがあります。 - ReactiveCocoa - MVVM - Realm - Himotoki - APIKit - Codable RxSwift ではなく ReactiveCocoa を採用した理由ですが単純にその時の時点では RxSwift は存在しなかったというのが大きいです。ReactiveCocoa を使い、アーキテクチャとしては MVVM 風にしました。 また、データベースとして、Realm を使っています。スレッドをまたぐために、API→HimotokiClass→RealmModel→Dictionary→HimotokiClass という変換をスムーズに行う仕組みを作っていました。 しかし、この手法はオーバーヘッドが非常に大きいため、現在では直接使うように変更しました。 一通り、Titanium から Swift への移行が終わったタイミングで、新しいバージョンとして Swift 版をリリースしました。
2015年4月 - 2016年3月
RDS MySQL から RDS Aurora 移行
RDS for MySQL で構築されたデータベースから特定のテーブルを RDS for Aurora に置き換えました。 対象となったテーブルはメインデータベースの 1 つで億単位のレコードが入っていました。また、レコードは随時増えつづけていて、ユーザ数が増加すればレコードの増加量も増えるという状態でした。 通常であれば、テーブルを別データベースにする必要がないレベルの負荷しかデータベースにはかかっていませんでした。しかし、テーブルに設定されたパーティションが枯渇するという状態になったため、メンテが必要になりました。 まず、オンライン DDL や pt-online-schema-change を用いて、本番環境と類似する環境で導入テストを行いました。 しかし、デッドロックが発生し更新失敗しました。 そのため、当初予定していた、無停止メンテを諦め、停止メンテを実施することになりました。 DB 負荷や容量を考えた場合、1 台の DB で管理するよりも、シャーディングを行った方がいいのではないかと考えました。 シャーディングされた環境というのを構築したことはありませんでした。 しかし、負荷を分散し、デッドロックを抑えるという点ではシャーディングによる負荷分散は優れていると判断し実施することにしました。 シャーディングを実施する準備を完了した直後に、RDS for Aurora が Tokyo Region にきてたことがわかりました。 シャーディングをやめ Aurora にした理由としては、あまり大きなものはなかったのですが、容量問題や性能という点から Aurora の方が MySQL を使い続けるよりも良いということ、それと、元々やりたかったことは負荷分散ではなく、パーティションを増やすということだったので、Aurora で良いと判断しました。 簡単な手順としては、MySQL のスナップショットから Aurora を作成し、Aurora 側ではパーティションを書き換えました。 その後、MySQL のリードレプリカとして Aurora 側を設定しました。 十分に 2 台が同期取れた後、接続先を Aurora に変更するということをして、MySQL を Aurora に変更するということを行いました。 このことを Aurora が Tokyo にやってきた比較的早いタイミングで実施しました その頃 Aurora 自体の安定性にも若干の問題があったりしたのですが念のために、Aurora と MySQL の両方の体制にしておくなどをしていました。 また、Aurora が突然重くなり使えなくなるという事象がありました。原因としては、サービス側で発行されていた特定のクエリが Aurora と相性が悪いという点でした。その修正自体は私ではなく別の方が担当していたのですが、原因の究明を行い無事に見つけられました。このとき Slow query を table に抽出するようにしていたのですが、それが別の Aurora の不具合によってサービス停止に追いやられるという事態もありましたが、そちらについてもなんとか解消しました。。
2015年7月 - 2015年11月
2015年
2015年
2015年3月
中信イノベーション賞
PickUp
高校の時にステージイベントを企画運営
Trigger
プログラミング教室
京都クリエイティブワークショップ
プログラミング教室
2015年2月
喫茶店の厨房
2013年3月
2009年3月
プール監視員
2009年3月
2009年3月
2020年4月 - 2021年2月
2019年11月
2016年5月 - 2019年11月
2015年7月 - 2019年11月
2015年4月 - 2019年11月
さらに表示
2015年1月
2015年1月
2015年1月
2015年1月
さらに表示
日本語 - ネイティブ
アプリをインストールして、知り合いの最新の活躍をフォローしよう