パンうめぇ

園児ニアの日記帳

「オブジェクト指向でなぜつくるのか」読書ログ

「オブジェクト指向でなぜつくるのか」を読破したので読書ログを残します．

一章はオブジェクト指向の全体像です．さっと読んだのでログなしです．

感想

オブジェクト指向について，何となく理解しているようでしていない状態から

を知見として得ることができました．

特にポリモーフィズムに学べたのが大きいです．

著者はOOPが説明の際に現実世界に例えられることに対して「現実世界とソフトウエアにはギャップがある」と一石を投じており，現実世界との違いをわかりやすく説明しています． また仕組みだけでなく「なぜ，オブジェクト指向である必要があるのか」という本質的な部分について重点的に解説しており，何となくOOPでプログラムを書いている人にお勧めできる本です．

個人的にはメモリの視点からOOPを眺める5章，関数型言語について書かれた13章が知的好奇心をくすぐられて面白かったです． 関数型言語の概要は，授業でも掴みきれなかったにもかかわらずこの本を通して全体概要を理解することができました．

またOOPだけでなく，プログラミング言語全体の流れを俯瞰したいという人にもお勧めします．

www.amazon.co.jp

Webを支える技術読書ログ

Webを支える技術を読破したので読書ログを残します．

↑ 13章も含む

感想

  • 普段よく聞いているが理解があやふやな言葉「RESTful，ステートレス」等の一通りの概要
  • webサービスの設計方法

について学べたのが大きいです．

基本が詰まっており，応用が効く考え方を得られました．

より専門的なことを学ぶには各技術スタックごとの書籍を読む必要がありますが，大まかなwebの仕組みを学ぶには良い本だと感じました．

webエンジニアとして働くに当たって一回は目を通した方がいい書籍だと思います！

自身の成果物にデプロイしていきたいです．

www.amazon.co.jp

2020振り返り

https://1.bp.blogspot.com/-0-VrA-zoZ0E/WK7fKPKPVkI/AAAAAAABCBQ/1OS-nwYjBMA_iwWKouoLZStze_Uwyc8TwCLcB/s800/pose_furikaeru_man.png

大変な年だった．コロナ渦でライブにもいけず，インターンや就活もオンラインという特殊な環境で実施，慣れない部分もあり苦労した．

一方大学生活史上最も外の世界に触れ，学ぶことが多い年でもあった．

振り返っていく．

f:id:kanekou:20201231180243p:plain
大まかに

  • 1月 ~ 2月: 卒論(とライブ)
  • 3月: 技術バイト
  • 4月 ~ 8月: 技術バイト，授業，インターン選考
  • 8月 ~ 10月: インターン
  • 10月 ~ : 就活

1月 ~ 2月: 卒論(とライブ)

卒論発表にめちゃくちゃ追われていた．あまりにもきついので，発表2週間前に関東ライブに逃避行した．

のライブを見に行った．現実を忘れて浴びるごちうさ楽曲は罪悪感も良いスパイスとなり，キマりました．

アフロのライブは推しが美人すぎてキョドっていた．公開アフレコのクオリティの高さに衝撃を受け，声優の凄さを肌で感じた．またライブパートでY.O.L.O!!!!!を回収でき，「アフロのファンでよかった...」とクソデカ感情なった．

D4DJのライブはオルスタだったので，泳いで前に行った． さえチがビビるほどギターうまかった．

ちなみに卒論の進捗がやばいため，ライブ以外の時間(1日6,7時間)は宿に籠もって実験と論文執筆を進めていた．というか自動スクリプトをライブ中にも走らせて研究を進めていた．

帰沖後も死ぬ気で論文を書き，発表の練習をしていた記憶がある．発表前日から当日まで一夜漬けでみんなで発表練習をした．

なんとか無事発表を終えて気絶し，参加予定の打ち上げ中盤頃に絶起した．

3月:技術バイト

去年の11月から続けていた技術バイトを3月いっぱいでやめた． Go, Nuxtでwebアプリを作っており，型の安全性を体感した．

4月 ~ 8月: バイト，授業，インターン選考

バイト

元々関わっていたRailsを使ったプロジェクトに再ジョインした． 以前はサーバーサイドが主だったが，インフラ周りを担当させてもらった．

その後新規プロジェクトにジョインし，DBの設計にも携わらせてもらった． モデルを大量に作ってテストをゴリゴリに書いた記憶がある．

完全リモートなので，認識の違いが生まれないようなテキストコミュニケーションを意識した開発を行った．しかしうまく伝えられない場面も多く，四苦八苦していた．

授業

オンラインでの実施となり，家に作業場所がないのでキツかった．できるだけ研究室にいた． 院の授業は基本的に英語の論文を読んでスライド発表という流れなので，英語力とプレゼン力がついたのはありがたかった．

UI/UXについて議論し，実際にアプリケーションを開発する授業もあり楽しかった思い出．

ただ全体として課題が多く，研究室の同志と協力することで片付けられたのは大きい．友達大事．

インターン選考

7月ごろ？からインターンの選考を受け始めた．

結論から述べると10社受けて3社受かった．

コロナの影響もあるのか，基本的に公開されているインターンは倍率がエグかったと思う．

軽く病みそうになるくらいには精神を消耗する活動だった．個人的にP社に行きたかったので最後の面接で落ちたのは悔しい思い出である．

公開されているインターンの多くはコーディングテストがあり，アルゴリズム力を鍛える必要があると痛感した． とはいえそれなりに倍率のある選考を突破することでき，今までのAtcoderの積み重ね(なお灰色)が生かされたと思う．

8月 ~ 10月: インターン

一番濃い時期だった．3社のインターンに参加した．

GA tecnologies

詳細はここを見てほしい．「Rails完全に理解した自分」が挫折を味わうことになる．

ただここでの経験はかなり生きた．自分に足りないところを重点的に学んだことで，後のインターンで壊滅的につまずくことを防いだ．

具体的にはフロントとバックエンドを分けたアーキテクチャパターンでの

  • API設計
  • サーバサイドの実装(jsonでの通信)
  • トークンを利用した認証・認可

である．プロのコードから得られることは多く，今でも困ったときに拝見している．

Media do tech internship

2週間でサービスの企画立案，開発を行うインターンシップに参加した．

オンライン環境で知らない人たちと開発するので，最初とても人見知りしてしまい，精神的にキツかった．

しかし「開発する上で，いかに心理的安全性を確保するか」をチーム全員で考え，ルール化したことで後半とても開発しやすい環境となった．個人的に最もチームビルディングが成功したイベントだった．

ルールはこんな感じ

- 質問はすぐにする(10分)
- 良い雰囲気を作る（褒める，リアクション，ため口）
- モーニングルーティンで役職決めを行う
- ファシリテータは認識の共有をワークの初め等定期的に行う
- ワークはそれぞれ3分程度余裕をとる（タイムキーパーは時間経過の報告）
- 共有サイトを決める（Notion）
- 個人ワークを多くとることを意識する
- ピッチ練習の時間に前日のTryを確認する
- 1時間に10分休憩
- 作業終了時は報告する

毎日のKPT分析で活動を振り返り，ルールを更新していった．

オンライン開発において心理的安全性を担保するチームルールはかなり有効ということを学んだ．

Sansan tech intenship trigger

詳細はここを見てほしい． チームメンバーのレベルがとても高く，開発しててワクワクした．特にプレゼンに対する作り込みは今まで経験したどのイベントよりも凄かった．

一貫して情報共有と時間管理の重要性を強く学んだイベントだった．

ただここら辺は前回のインターンでルール化できていたので，早めに組み込めなかったのは反省点．

夏のインターンを終えて

技術も難しいが，チームビルディングも難しい．しかしとても重要だと学んだ．

「強いチーム」を作る上で大事なのは言語化だと思う． オンラインだと情報量が減るので，伝え方を意識しないと情報は伝わらない． 共通認識を持たなければチームはうまく回らないので，そのための言語化手法について学べたのは大きかった．

またインターンを学んだこと，やってみたいことをバイトで述べると経験させてもらえたのでありがたかった．

10月 ~ 12月: 就活

待ちに待った就活がやってきました()． ここら辺はnoteにお気持ちを表明しているので見てほしい．

note.com

辛い部分も多いですが，前向きに頑張ります．

一年を振り返ってみて

「why?」を意識するようになった

より本質を意識するようになったと思う．例えば技術スタックだと，

  • なぜこの技術はこのように実装されているのか
  • なぜこの技術が採用されたのか

サービス立案だと

  • なぜこのサービスをやるのか
  • このサービスを通じて本当に届けたいことってなんだろう

みたいな感じ．

少し前まではRailsのレールに乗って実装することでweb appをわかった気になっていたが，Railsが裏で行っていることを深堀りしたくなったし，「そもそもなぜオブジェクト志向なのか？」，みたいなところもちゃんと知りたくなった．

実装知識も大事だが，技術スタックの背景，思想を知らなければ応用は効かなさそう．「FWに書かされている」エンジニア にはなりたくない．なので来年はよりCSに近いところにフォーカスしていくつもりです．

またGolangなどの静的型付け言語でweb appを作ってみて，動的型付けとの違いを学びたいと思う．

最後に

コロナでオンライン開催になったことで，色々な技術イベントに参加しやすくなったのは利点だと思う．

なんだかんだ刺激的で楽しい年だったので，来年も良い年にしていきたいです．

Sansan Tech Internship Trigger 2020 に参加しました

10/5 - 10/16までの10日間，SansanのTech Internship Trigger 2020に参加してきました！

ビジネスと技術の結びつきについて学びの多いインターンでした．

jp.corp-sansan.com

このインターンは最初の4日間でSansanトップエンジニアの講師の方の講義を受け，実際にプロダクトの立案と開発を行い，最終日にSansan本社で発表という流れでした． 講義は以下の5つで構成されていました．

ちなみに優勝したグループは賞金30万円貰えます．やばい

参加前

参加確定のお知らせをいただいた時は，驚きと喜びを同時に感じました． ただ，本当に自分でいいのか？技術的についてこれるのか？という不安でいっぱいでした． なのでRailsで認証周りやAPIの構築練習などを行い不安を埋めていました．

また事前にチーム分けの参考として，ストレングスファインダーやエニアグラムを用いた特性分析を行いました． 僕の特性としては，以下の項目が挙げられました．

ストレングスファインダー

  1. 回復思考
  2. 調和性
  3. 責任感
  4. アレンジ
  5. 目標思考

エニアグラム

  1. 知識を得て観察する人
  2. 安全を求め慎重に行動する人

かなり自覚がありました．特に回復思考と調和性は自身の思考パターンにかなり近い内容でした． ストレングスファインダーの5つの特性のうち4つが実行力に振られており，行動力の高さが記されていました． 実行力は強みだと感じていたので，納得できました．

チームビルディング

本番１日目ではチームが発表されました． 特性と技術スタックを元にチームメンバーが組まれました．

その後チームメイトのストレングスファインダーとエニアグラムを元にそれぞれの特性への理解を深めました． 心理的安全性を担保する目的で，メンバーそれぞれの強みや弱み，どう接して欲しいか等を打ち明けるプロセスを踏みました． これは後の開発時に役に経つ内容でした． メンバーがされたら嫌なことを意識できたので，衝突することは合ってもチームが分裂することはありませんでした． また自身の調和性を生かして，チームの雰囲気を多少なりとも調和することもできました．

後のアイデアだしやチーム開発でも各メンバーの特性が現れることがあり，思ったより特性が出ていて面白いな〜と思いました．

またストレングスファインダーコーチの方に，自身の強みや弱みについて解説もいただきました． 私は回復思考が強いため，調和性と組み合わせるとチーム間の人間関係を修復へと向かわせる特性がありました． 一方で，チーム内で重大な決断をする際には調和性がマイナスに働く可能性もあるようです． 人を観察して何を感じているのか察するのが得意なので，マイナス面も含め納得できる内容でした．

講義

月曜から木曜までプロダクト開発に必要な5項目について講義を受けました．

ソフトウェアビジネスと開発

最初にCTO藤倉さんの講義がありました．ソフトウェアがビジネスとして成り立つための基本的な考え方(市場の顕在性と潜在性，収益構造など)を教えていただきました． エンジニアは技術力だけでなく，ビジネスと結びつける力が必要ということを学びました．

最初ビジネス何それ美味しいの？状態だったので，プロダクト思考という考え方を学べたのは大きな収穫でした．

プロダクトマネジメント

Product Managerの加藤さんによるプロダクトマネジメントの講義がありました． プロダクトを立案する上での考え方やツール，仮説検証の重要さを学びました． 特に印象深かったのは，ゴールデンサークル理論の「why」の部分です． 後のアイデア出しでは「why」を意識することで解決したい課題の本質が見えてきて，深掘りの助けになりました．

クラウドの概要と非機能要件

Sansanのインフラを構築している落合さんによるクラウドアーキテクチャについての講義がありました． オンプレと比較したクラウドの特徴や，事業への活用例，最近の傾向などを学びました． クラウドはあまり手につけていない領域なので，かなり新鮮な内容でした(難しかった)． まともな質問ができるほどの基本知識がなかったのが少し悔やまれます．

非機能要件についても学びました．認識のズレが起きやすく，上流過程できちんと定義する必要があることを知りました．

チーム開発方法論

サービス開発部の石畑さんによるチーム開発の方法についての講義です． 不確実性に強いチームを作り上げる上での，情報共有の重要性を教えていただきました． 今回のように初めてあった人同士で2週間の開発を乗り切るには，認識のズレを防ぐことが最重要だと考えているので，把握すべき内容だと思いました．

オンラインでの開発は対面より情報共有の工夫が必要ですよね．

後のチーム活動でもうまく伝えきれない，意図が読み取れないことがあり，情報共有については悩み工夫しました(いつも悩んでる)．

アプリケーションアーキテクチャ概論

プロダクト開発部の荒川さんによる，アプリケーションアーキテクチャの概要についての講義です． フロントエンド，バックエンド両方のアーキテクチャを俯瞰して見渡せる講義内容だったため，普段RailsのMVCで開発している自身の視野を広くしてくれました． また一番技術的な内容だったのでワクワクしました．

クリーンアーキテクチャ...ツイッターでよく見る単語や(小並感)

アイデアだし

講義あとはチームに分かれてビジネスの立案を行いました． miroにそれぞれのアイデアを出し議論する流れなのですが，一向に話し合いが進まず一時はチーム破綻を運営に心配されてたようです😁

話し合いが進まない要因として以下が挙げられます．

言語化しない

これが一番大きいです． 文字に起こさず口頭で議論を重ねることで何度も同じ話題を掘り起こし，大幅にタイムロスしてしまいました． 石畑さんが述べていた情報共有がうまく取れていない状況です． 共同編集ツール(Google Docs)に議論内容を議事録として記すことで，共通認識が取れ円滑に進むようになりました．

時間制限を設けない

だらだら同じ議論を繰り返した結果，話がまとまらず変な方向に向かうことが多くありました． そこで明確に時間制約を設けた結果，意思決定が円滑に進み，アイデアもまとまりが出ました．

なんとかまとまった

上の要因とアイデア出しの難しさもあり，かなり苦戦しましたが4日目の木曜夜にビジネスの流れをまとめました． ユーザーストーリーマップとカスタマージャーニー，リーンキャンバスを作成し，構想を言語化することができました． 予定より一日オーバーしてしまいましたが，作りたいものが定まったことにホッとしました．

途中CTOの藤倉さんやProduct Managerの加藤さん，人事の小守さんに壁打ちしてもらい 貴重なアドバイスをいただけてとてもありがたかったです🙏

f:id:kanekou:20201020162330p:plain
ユーザーストーリーマップ
f:id:kanekou:20201018170741p:plain
カスタマージャーニーとリーンキャンバス

いや〜構想立てるのしんどかったほんま　

開発

ビジネスモデルの話し合いが終わり技術の話になると，皆水を得た魚のように元気になりました😃

まずAPIとDBに関して設計を行いました． 共通認識をとるために全員で設計を行いドキュメントにまとめました．

その後フロントとバックエンドに分かれて開発を行いました． 僕はバックエンドでAPIの開発に取り組みました．

5日目の夕会で，人事の方に7日目の火曜日には開発が終わると豪語してましたが，普通に最終発表一日前まで続いていました．

技術選定

Golangの採用

僕自身はRailsが一番得意なのですが，バックエンドの技術選定でGoとRailsどちらかを選択する際にGolangに挑戦したい気持ちで採用しました． 結果的にAPIの半数を実装することができました． とはいえリソースの多いAPIは実装スピードが足りず，難しいところを任せきりになってしまったので悔しさと申し訳ない気持ちで一杯でした．

でも実装してて楽しかったし，挑戦して良かったと思います． 記法がシンプルな分，書いたコードしか動かないためプログラミングの地力が着く気がしました． 特に型制約には苦しめられましたが，普段Rubyで意識しないところなので鍛えられました．

何よりわからないところを根気強く教えてくれたチームメイトには感謝しきれません． むしろ考えすぎてしまうところがあり，もう少し早めに聞くべきだったなと思います．

クリーンアーキテクチャの採用

今回は特定のFWを使わずに簡易的なクリーンアーキテクチャで実装を行いました． 理由としては以下が挙げられます．

  • 将来的なスケールを考慮した時に責任を分離できること
  • 完全なクリーンアーキテクチャを短時間で実装するのは困難だと判断

普段FW便りで開発していたので，疎結合なアーキテクチャの実装は学ぶ部分が多くありました． また，とっつきやすいよう簡易的な構成を採用したため把握しやすく，土日のキャッチアップもあり実装に落とし込むことができました．

プレゼン作成

発表2日前の水曜夜から怒涛のプレゼン作成が始まりました(まじ怒涛)．

  • 雑にスライドを記述，検証アンケートの実施(水曜 20:00 - 23:00)
  • 沖縄→東京まで移動(木曜 10:00 - 18:00)
  • ホテル着，プレゼン作成(木曜 18:00 - 27:00)
  • 気絶(木曜 27:30 - 金曜 8:00)
  • 発表(金曜 10:30 - 11:00)

特にアピールしたいことはビジネスモデルなので，投資家向けに作成することになりました． そのためアーキテクチャやチーム開発についての説明は少なく，ビジネスモデルやプロダクトマネジメントについてのスライドを多めに作りました．

プレゼン本番

Sansan本社に集合し，プレゼン発表を行いました． メンバーと会うのは初めてなのでオフ会みたいな雰囲気でした(行ったことないけど)

発表者じゃないけど発表前は少し緊張してました．

本番では発表メンバーが説得力抜群のプレゼンで，プロダクトの存在価値を徹底的に伝えてくれました．感謝🙏

質問に関しては僕も受け応えることができました． 特にチーム開発については，心理的安全性ついての工夫点をアピールすることができました．

docs.google.com

レビュー

プレゼン後は講師陣からありがたいレビューをいただきました．

良かった点

特にプレゼンが評価されました．プロダクトの存在価値をきちんと言語できている点で好評をいただきました． 準備の甲斐あった〜

アプリケーションの技術選定については，限られた開発期間の中で挑戦する領域とそうでない領域のバランスを評価されました． 簡易的なクリーンアーキテクチャの選定は好手だったようです．

クラウドアーキテクチャについては，うまくAWSを活用していた印象を受けたと講評をいただきました． またgithub actionでデプロイを自動化したところも評価をいただきました．

改善点

ビジネスモデルについては，収益構造があまりよく見えないとの評価をいただきました． 確かに収益の具体的な構造，どれくらいの収益が見込めるかについては深堀りできていなかったので反省です．

チーム開発においては，スライドにあまり内容を含めていなかったため工夫点が見えづらいと講評をいただきました． それなりに工夫はしていたのですが，プレゼン対象が投資家という理由で深く言及しませんでした（だとしても収益構造甘いのはダメだよね)．

結果発表

優勝とはなりませんでした〜〜〜

しかし自分たちの伝えたいことは伝えられて，ちゃんと評価されていたので後悔はないです． 僕自身はやり切った感がありました．

ただ優勝したチームは全ての評価観点でバランス良く，納得のいく内容でした．

プレゼン対象を絞った戦略は悪くなかったと思うんだけどな〜

振り返り

最後にチームのみんなで振り返りコンテンツを行いました． 特に議題に上がったのはやはり議事録の作成と時間制限でした． 下は振り返りの一部です．

できたこと

  • プレゼンテーション
  • 作ろうと思ったプロダクトの実装

できなかったこと

  • ドキュメントのメンテナンス
  • バックエンドとフロントエンドの進捗確認

次ハッカソンやるなら

  • 時間を制限しろ
  • 議事録を作れ
  • 朝夕会で確認を取れ

チームの強み

  • 手を動かせる
  • 温厚
  • 雰囲気
  • 自信

一時は破綻が心配されてましたが，最終的にどのグループよりも雰囲気は明るかったと思います． みんなキャラ濃くて会場で一番うるさいグループだったと思います(すみませんでした)

全体を振り返って

参加できて良かったと思えるイベントでした． 技術面，チーム開発，ビジネス立案で大きな経験を得ることができました．

技術面

適度な挫折を得ることができました． 自分に足りないところを修正し，同年代に負けないつよつよエンジニアに近づきたいです． 特にGolangとフロントエンドの知識を身につけていきたい所存です．

チーム開発の難しさ

オンラインという環境の中でのチーム活動の難しさを体験できたことは一番大きいです． 技術バイトでも言語化は意識してきましたが，最初それをサボったことにより重要性を痛感しました． 言語化することで共通理解が得られ自信をもって質問できるので，心理的安全性の面でも大きな利点だと感じてます．

また時間管理の重要性も実感しました． 長い時間だらだらアイデアを考えるのではなく時間を定め意思決定のスピードを早くすると，驚くほどスピーディに話し合いが進みました．

ビジネス立案

収益構造について初めて考えました． その中でビジネスを考える難しさと，少しばかりの楽しさを知ることができました．

またエンジニアとして価値提供の考えを得ることができました．

ビジネスについては明らかに知識不足だなあと感じたので精進します．

ハイレベルな同志との出会い

ハイレベルなメンバーとの出会いはすごく刺激になりました． 大学とはレベルが段違いなので自分の水準が上がりました．(あっとこーだー緑以上が過半数なの怖い...) 環境を変えると効率よく成長できると感じました．

こうして欲しかった

イベントに対しての要望として，メンターさんが欲しかったです． 一時はかなり迷走していたので．議論があらぬ方向に向かった際に助け舟を出していただけると助かったと思います．

最後に

今回のハッカソンは高速なインプットとアウトプットを必要としているためかなりしんどい時もありましたが(特にビジネス立案)，頭抱えて脳汁垂らした分成長できたと思います． 大学では得られない，エンジニアとして働く上で必要となる考え方を学べました．

達成感！

作成したアプリ(イベント名: Trigger 2020) kikitutu.web.app

GA technologiesのハッカソンに参加しました

GA technologiesさんのハッカソンが8/29と8/30にあり，参加してきました． このハッカソンは日常のアナログな課題をXテックで解決するというのが趣旨のイベントです． またメンターの方はサポートだけでなく一要員として開発に加わるため，プロの技術を学べるのが利点だと思います．

何を開発したのか

KizkuAIちゃんというアプリを開発しました．

f:id:kanekou:20200903202613p:plain
このアプリを一言でいうと，AIが気が利くお知らせを通知してくれるiosアプリです．

機能としては主に2つ．

  • ユーザーの動向から，興味のあるニューストピックを解析し，朝，昼，晩の決まった時刻にニュースを通知
  • 熱中症や天気に関わる情報をいち早くお届け

今回は下の機能は実装できませんでした． また上の機能に関しても，ユーザー認証周りは実装できたのですが，Railsとiosとの連携が完全には実装できませんでした．こちらに関しては後述します．

なぜ開発しようと思ったのか．

コロナ影響下で一人で過ごす時間が増えて寂しいという意見と，熱中症で倒れる人が多く，事前に通知してくれるだけでも役に立ちそうという意見がありました． 当初は熱中症&コロナの通知アプリにしようとしてましたが，コロナAPIの自動取得が少し辛そうなのと，DeepLearningを学んでいるメンバーがいたのでAIを駆使したアプリを作りたいという思いが一致し，機能として追加しました．

主な構成

アーキテクチャとしては，ニュースを解析しトピックを振り分けるFluskサーバー，ニュース情報やユーザーの動向を保存し，情報を元におすすめニュースをiosに渡すRilaAPIサーバー，ユーザーとニュース情報を受け取り表示するios(Swift)で構成されてます． 私はRails APIの実装を担当しました．

f:id:kanekou:20200904111958p:plain

開発1週間前

メンバー，メンターの方との初顔合わせでした．学生のメンバーはそれぞれ全くバックグランドが違っており(ios, DeepLearning, Web)，面白くなりそうだなあと感じたのと，開発うまくいくのかなという不安がありました．

話し合いは皆積極的に発言していて，メンターの方のサポートもありどんどん話がまとまっていきました． 課題に対しての着眼点が聡明で，大まかな仕様決定までのスピード感があったと感じます． その週の水，木，金の三日間は集中講義でかなりキツキツでしたが，夜に集まってアイデアだしと技術リサーチ報告，設計などを行いました． 特に設計はメンターさん主導のもと進めてもらい，かなり勉強になる内容でした． 必要要件の理解とそれに対する設計がすぐに思いつくプロに対して凄みを感じたのと，自身の経験の少なさがこの時からすでに浮き彫りになっていて，悔しさを感じていました．

本番

ニュースレコメンド機能を先に実装する運びで，モデルの構築とバリデーションの制定を設計書をもとに行いました． このあたりの作業は普段の開発業務で行っているため，難なく進めることができました．

RailsAPIナニモワカラナイ

しかし問題はこのあとのAPI構築にありました． APIを用いた認証機構を作る時に，どのように作成すれば良いのかイメージが湧かず，メンターさんとペアプロしながら助けていただきました． しかしRailsAPIの認証ロジックを理解するのに頭が一杯一杯でビジネスロジックを理解するまで脳が追いつかず，ある処理がどのような背景で記述されているのか理解が追いつかなくなってきました． 2日間という短い時間の中で，新たな仕様の追加や変化に対して脳のリソースを割り振ることができず，わからない仕様がさらにわからないくなるという悪循環が生まれてしまいました． メンターさんの作業スピードに僕がついてこれず，結局頼りっぱなしとなってしまったことを猛反してます．．．

逆にデプロイの部分ではHerokuの知識が少しあったので，メンターさんに意見を述べながらデプロイを進めることができたと思います．

成果(Railsサイド)

できたところ

  • 機械学習のサーバーからトピック分類されたニュースを定期的に取得しDBに保存
  • ios側とのユーザー認証
  • herokuにrailsとsidekiqをホスディング

できなかったこと

  • iosにニュース情報を渡す処理
  • ユーザーが見た回数を記録し，ニュースのレコメンドに使用

iosとの連携がほぼうまくいってないのは悔しい結果となりました． 圧倒的にAPIの知識が足りず悔しい結果となりました．

機械学習サーバーとの連携が取れたのはよかったです． 機械学習有識者がapiサーバーも立ててくれて，思ったより高い精度で分類されたデータが取得できたので頭が上がりません🥺

プレゼン

プレゼンは他のメンバーの方が発表してくださったのですが，とてもわかりやすい発表だったと思います． 人工知能を使ったアプリは僕たちだけだったので，インパクトはかなり強かったと自負しています．

質問答えられず

iosとの連携がどこまでできたのかについて問われたのですが，どこまでできたのか完全把握ができておらず，答えることができませんでした． これはある実装に手間がかかったため，その他の実装をメンターさんに任せっきりとなってしまった結果，状況を完全理解できずに起こってしまった結果となりました． プレゼンの打ち合わせ時間が個人的にがあまり取れていなかったため，作業を中断してでも入念にやり取りを行うべきだと学びました．

結果

優勝とはなりませんでしたが，かなりいい線までいっていたらしいです． メンバーの強みを生かした構成でアプリを開発できたのはよかったと思います． アイデアはかなり自信があるので，未実装部分を実装してどこかでリベンジしたい...!

所感

業務等でRailsを数年前から触っていて，それなりに理解したと思っていたのですが，「完全に理解した」レベルだということがわかりショックでした． 知識不足で足をひっぱってしまったなと感じてます． APIに関しては最近実装する機会があり少しだけ理解していたつもりでしたが，応用となるとイメージが湧かず，まだ身についてないことを痛感しました． やはり慣れていないことは応用できないですね． 今まで比較的簡単な構成で開発してきたので，jsonでネイティブクライアントとやり取りを行う構成で経験を積まなければならないと感じました．

また仕様についてですが，より細かく文書化すればよかっと感じています． 準備段階での仕様書は作成していましたが，本番中は口頭でのやり取りで，共通認識が取れていなかったのが反省点です．

これから

技術においてもハッカソン全体においても，やはり「慣れ」は重要で，経験してるのとしてないのとでは絶対的な差があると感じます． 今回は慣れない環境の中，技術的なことに脳のリソースを全振りしてしまい全体を見渡せていなかったと思います． 技術的な点については知識を積む必要がありますが，ハッカソン全体に関して言えば経験を積んで慣れていくしかないのかなと考えています． 今回は反省点がたくさん見え，わからないところがわかったので良い経験になりました． 次は今より全体を俯瞰できるよう修正し，ハッカソンという状況下で爪痕を残せるように頑張ります．

github.com

Rails APIを高速に立ち上げる

ハッカソンで高速にAPIサーバーを立ち上げるためのメモです．

Rails API 立ち上げ

1 プロジェクト作成

$ rails new rails_api --api --skip-bundle
$ bundle install

2 create db

$ rails generate scaffold User name:string
$ rails db:create
$ rails db:migrate

3 routing設定

  • route.rb
Rails.application.routes.draw do
  # For details on the DSL available within this file, see https://guides.rubyonrails.org/routing.html
  scope :api, defaults: { format: :json } do
    resources :users
  end
end

4 access! localhost:3000/api/users

post

% curl -X POST -H "Content-Type: application/json" -d '{"name": "hoge"}' http://localhost:3000/api/users

get

% curl http://localhost:3000/api/users

Heroku Deploy

1 heroku create heat-monitor

2 sqlite3をdevelopment, testに移動し，productionにpgを追加． herokuはpostgresqlを使うので， production環境ではpostgresqlに変更する．

group :production do
  gem 'pg'
end

roup :development, :test do
  # Call 'byebug' anywhere in the code to stop execution and get a debugger console
  gem 'byebug', platforms: [:mri, :mingw, :x64_mingw]
  gem 'sqlite3', '~> 1.4'
end

3 bundle install % bundle install --without production

4 database.ymlを変更

production:
  <<: *default
#  database: db/production.sqlite3
  adapter: postgresql
  encoding: unicode
  pool: 5

5 コミット git add -A & git commit -m "first commit"

6 herokuにpush git push heroku master

7 heroku環境でmigrate heroku run rails db:migrate

8 access!(4とほぼ同じ)

参考サイト