【Rust】Rust.Tokyo 2019に参加しました！#rust_tokyo

感想

10/26 に開催された、Rust.Tokyo 2019に参加してきました！
Rust.Tokyoは今回初開催で、参加する側としてもドキドキしながらだったのですが、
熱量の高いカンファレンスで、初心者の自分にも大きな学びのある時間でした。
キーノートの講演の段階ででWi-Fiが利用できなくなってしまったのと、
野良APをなるべく出さないようにという事だったのが大変でしたが、
たまたまUSBテザリングできる状態だったので、Twitter上での実況にも参加し、
たくさんのRustaceanの方と交流させていただきました！
参加者・登壇者・運営の皆様、素敵なイベントを本当にありがとうございました！

以下は、記憶が薄くならないうちに参加したセッションの簡単なメモなど。
覚えきれていないもの、抜け・漏れ・勘違いなどあるかもしれませんがご容赦ください。
資料は現時点で見つかったものだけ貼ります。

参加セッション

Rustで安全に実装するための心得

Osuke (@zoom_zoomzo) | Twitter speakerdeck.com

• Rustは基本的には安全にかける言語だが、unsafeを用いるなどしてその制限を超えることができる
  • Rustが検知できる範囲を超えたときに起こりうる脆弱性の一部について紹介
    • 脆弱性自体の紹介となぜそれが起こるのか
    • 脆弱性を回避するための手法・ツール

エッジMLシステムをC/C++からRustへ移行した事例

tkato (@tkato) | Twitter docs.google.com

• Deep Learningを含むシステムのアルゴリズム群をC++からRustに移行した話
  • 移行の背景とその手法
    • R&DをPythonで行っていたが、C++への移植が辛い
    • Rustは高速で安全なため、品質を向上させることができる
    • エコシステムが快適
    • 他の言語と結合しやすい口がある

Rustによる数値計算の現状と課題

てらモス♋ (@termoshtt) | Twitter docs.google.com

• C++ Fortran MATLABなどが多い数値計算の世界でRustを使った話
  • LLVMによる高速化や、Traitなどの言語仕様によって、扱う土壌はできている
  • 公式のツールセットが充実しており、扱いやすい
  • 数値計算の分野での利用事例が少ないためライブラリが少ない
  • GPU・アクセラレータに対応していなくて辛い…

Web-based Data Visualization with Rust and WebAssembly

Yosuke Onoue (@_likr) | Twitter speakerdeck.com

• Web上のデータビジュアライゼーションにWASMを利用した話
  • WebのUI・UXは研究者にも馴染みやすいので、Web上でGUIを構築している
  • Vue.js/WebGL/WASM(Rust)の構成
  • WASMの得意な大きい仕事はRustで、それ以外はJSの棲み分け
    • JSもきっちり書いたら早い
    • WASM呼び出しのコストがあるので、頻繁に呼び出すと遅い
    • 現状はJSよりもWASMの方がCPUのリソースを使えるので、そういうケースに良い
      • WASMからjsを吐かせることもできる

(ここから先、資料見つからなかったので言及少なめです)

いつの間にか社の中核製品にRustが使われていた件について

あずんひ | さいとう | ひーろー (@aznhe21) | Twitter

• 会社の様々なRust採用事例について紹介
  • Rustのプロダクト採用理由は「趣味」
  • 依存ライブラリが多岐に渡る
  • OPTiMはブログやTwitterで様々な技術情報を発信しているので見てほしい

Rustを採用したサービス開発事例について

CADDi 高藤 謙佑さん(Twitter見つからなかったので会社サイトリンク貼ります)
CADDi Rust Engineering

• Rustを採用した事例と教育、設計などについて
  • 採用する理由は安全性、パフォーマンス、エコシステム
  • 教育
    • まずはThe Book読んでもらう
    • 社内にTIPSやコードスニペットを蓄積、共有している
  • 設計
    • どういうときにどういう型を作るか、どうやって作るかなど
  • 会社のドメインに .rs をつけたかったのでつけた
    • セルビアドメイン

Holochain ～真の分散型P2PアプリをRustで作ろう！～

Tatsuya sato (@_tatsuyasato) | Twitter www.canva.com

• Holochainのアーキテクチャとアプリケーションの作り方
  • Holochainとは？
    • ブロックチェーンとは異なる新しい分散型ネットワークのプロトコル
    • P2Pネットワーク上に構築され、中央サーバーを介さずに運用できる
  • アプリの使い方についてサンプルコードを見ながら解説
    • 前半の説明についていけない&後ろの席でコードが読み取れず理解できなかった…
    • 冊子をもらえたので家で読み直したい

Contributing to Rust

Florian Gilcher ∠(・.-)―〉 →◎ (@Argorak) | Twitter

• Rustのコミュニティに参加してContributeしよう！という話
  • 「RustにContributeする」というのはコードを書くだけじゃない
    • 様々な役割があり、それぞれやることも、必要な時間も異なる
    • それぞれのポストについて、簡単な例を見せながら参加する例を紹介
  • コミュニティに参加するのも、抜けるのも簡単
  • Rustを広めることだってContribution!

というわけで、ざっくりですが参加したセッションのまとめでした！
改めて、みなさまお疲れさまでした。
次回も参加できることを願っています！ありがとうございました！

【雑記】学ぶ方向性の選択と集中

新卒の頃から意識している成長法に、死にながら成長するというのがある。
単に無茶ぶりの仕事を倒しながら死んで、結果成長するというのもあるし、
脳が働かなくなるまでとりあえず情報を脳に叩き込み続けて、
つながりを探しながら咀嚼するみたいなことをして勉強をしてきた。

今でもこの習慣は続いていて、毎日複数回はてブのテクノロジータブを開いて流し見するし、
Feedlyの技術系フォルダには山程そういったサイトの更新が表示されている。

この生活のメリットは、自分の技術スタックの範囲外のニュースでも大体目を通すことになること。
否が応でも関連性を意識させられるので、業界の大まかな流れや、流行りなんかがわかるようになる。
デメリットは単純で、情報に溺れて死にがちという点。
少しでも足を止めるとすぐ濁流に飲み込まれるし、追いつこうにも膨大な未読の山ができる。

そういう生活をして20代を過ごしてきたけど、結婚して、
30を目の前にして時間の使い方を考える必要が出てきた。
要は選択と集中で、考えれば当たり前のことなんだけど、
必要とするもの、興味のあるもの、伸ばしたいもの、
それらに絞って掘り下げることが必要なタイミングになってきたのかなぁと思う。

それでいて、今まで広く浅く領域を知っていることで立ち位置を築いて来たのもあって、
果たしてその方法で自らのレゾンデートルを見つけることができるのかという不安もある。

経験年数でいえば7年目で中途半端だし、年齢が区切りになるわけじゃないけど、
不思議とこの一年は色々な物を考えてしまいがち。

【API開発】稼働中のAPIサーバーリプレースの難しさ

TL;DR

• I/Fや仕様が明確でないものを再現しながら移行するのは大変
• まずは情報を集約し、目指すべき形を見つけること
• 既存の実装やシステムへのリスペクトを忘れずに

はじめに

現職に転職して、昨年の4月からアプリのサーバーサイドの開発を行うようになりました。
昨年の4~9月は主に既存のものの追加改修を、10〜4月はアプリ側も含めたフルリニューアルを、
今年度に入ってからはサーバーサイドのみのリプレースという形で、開発を行ってきています。

昨年度はアプリも含めたフルリプレースだったので、すべてのAPIのI/Fをゼロから定義し、
わかりやすいアーキテクチャで作り直すことができました。
しかし今年度行っているのは、稼働中のものとは別に新しくAPIサーバーを再構築し、
既存のアプリに影響ないようダウンタイム無しで移行を行うという作業です。
これは、昨年度行ったリニューアルとは比でなく難しく、大変な作業だなと感じています。
何が辛いのか、どういう方針で立ち向かっているのかについて書いていきたいと思います。

何が辛いのか

IFが定義されてない

開発当初はただのバックエンドの土管として想定されていたようで、
アプリがバックエンドのAPIのパラメータを組み立て、
バックエンドから返却されたレスポンスをそのままアプリに返すような実装でした。
(サーバー側でパラメータの付与・置換を行ったり、レスポンスを加工しているものも存在しました。)

つまり、サービスで利用するAPIとして、どういったリクエストを受けるべきで、
どういったレスポンスを返すべきなのかという定義を行う層が曖昧となってしまっていました。

仕様があまり明確ではない

なぜ共通の処理をもっているのか、どういう意図でまとめなかったのかなど、
実装の理由が不明で、当時の関係者にヒアリングをして回って、調査する必要がありました。

独自フレームワークを使っている

過去に社内で作られたフレームワークを利用して開発が行われていました。
このフレームワークの利用経験がいくらかあればまだ違ったのですが、
入社以降あまり触ったことがなく、ググってトラブルシュートするなども難しかったです。

最終的に目指すべき形

アプリ向けサーバーの最も考えるべき要件は、アプリの開発しやすさだと考えています。
公開するI/Fは最低限とし、複雑な加工が必要な箇所はサーバーで加工して返却するなど、
利用する際に考えることなく利用でき、本当に必要な箇所に意識を向けてもらえる状態こそが、
あるべき形であると考えています。

整理されたI/F、仕様は追加開発や施策の検討のための思考の余力を残し、
より加速したサービス開発を行うことができるでしょう。

やりきるための進め方

• 一般的なフレームワークに寄せる
  幸い、以前の担当者がJerseyで新サーバーを構築し、移植を始めてくれていました。
  この資産をベースに、よりシンプルな形で再構築を進めています。
• 必要なIFだけを定義
  アプリと旧サーバーのロジックを追いかけ、定義されるべき値を洗い出します。
  また、同じような概念はきちんと共通化されたEntityを用いるようにしています。
• 仕様の整理とドキュメント化
  現状の仕様があまり明確ではなかったため、まずは情報の整理を進めました。
  ヒアリングした仕様をドキュメントやコメントに残し、ロジックをシンプルにして、
  正しい状態が何であるかがわかるようにしています。

忘れてはならないこと

ここまで色々書いてきましたが、リプレースに於いて絶対に忘れてはならないことがあります。
それは、既存のものに対してリスペクトを持つことです。
稼働しているものは間違いなく価値を生み出しています。
そこに対しての敬意を忘れてはいけません。
現在の形になっているのはそうせざるを得なかった理由があるはずです。

行うべきはそれらを紐解いて、整理し、より大きな価値を生み出すことです。
どうすることが最も良い状態を生み出せるかを一番に考えて進めましょう。