Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Result presentation slide

350 views

Published on

Result presentation slide

Published in: Engineering
  • Be the first to comment

Result presentation slide

  1. 1. 自己紹介 名前: 三島 大学: 山梨大学 大学院 医工農学総合教育部 修士課程 工学専攻 コンピュータ理工学コース 2年 趣味: ゲーム(『UNI’S ON AIR』) 1人旅・バイク 出身地: 徳島県 育ちはメキシコ(スペイン語は喋れません。。。) 開発: ペットの顔認証 ユーザのレビュー分類 現状 ゴール
  2. 2. インターンシップの概要  課題1:新機能ログ出力の機能追加(9日) • 環境構築(1日) • 実装(3日) • テスト(2日) • レビュー(4日)  課題2:管理画面に新機能項目を追加(4日) • 実装(4日)
  3. 3. 新機能ログ出力の機能追加(9日)  なぜログを保存するのか? • 各アイテムの確率の妥当性を判断 • 不具合の調査 • ユーザーからの質問に対する回答  現状の課題 • ログ出力はまだ実装されていない
  4. 4. 新機能ログ出力の機能追加(9日)  何をやったのか • ログテーブルを実装 • 関連しているデータベースを理解 • 新機能のコードを理解 • テストをRspecで実装 非同期処理 記録 RDS:Log DB timestamp : 日時 user_id : ユーザー ・・・ timestamp : 日時 user_id : ユーザー ・・・ timestamp : 日時 user_id : ユーザー ・・・
  5. 5.  テスト • 先にテストを実装 • プルリクした時に無関係なコードでエラー  理解しやすいコード • プルリクした時に番犬に噛まれる • 主観で分かり易い変数名を定義  膨大な量のコード • (Ruby or 自作)メソッドなのか区別がつかない 課題1を通して苦労した点 静的コード解析ツール:RuboCop CIツール :CircleCI
  6. 6.  テスト • 既存コードを参照 • ローカルリポジトリを更新してプッシュ • テストの重要性  理解しやすいコード • RuboCopのコマンドの後に「-a」 • 客観的なレビューの重要性  膨大な数のコード • 要点を絞ってコードを見て理解する力 • リファレンスを調査 • (メソッド名 or クラス名)で検索 課題1を通して学習した・感じた点 静的コード解析ツール :RuboCop CIツール :CircleCI $ rubocop -a $ git feach $ git rebase $ git push –f
  7. 7. 管理画面に新機能項目を追加(4日)  マスターデータとは • ゲーム内で不変の共通パラメータ群 (武器の強さ、名前、アイコンなど)  マスターデータがなぜ必要なのか? • ゲームの構成情報を決定 • ゲームバランスの調整  現状の課題 プランナー(非エンジニア)が操作しやすく、 マスターデータを登録できる
  8. 8.  実装 • Ruby on Rails のgemであるActiveAdminを利用 • 仕様書に基づいて項目を追加 管理画面に新機能項目を追加(4日)  課題に対してどう対処したか? • 値を記入からプルダウンに変更 • アイテムIDをアイテム名に変更 • 英語と日本語の表記 操作しやすい仕様を意識
  9. 9.  操作しやすいView • 主観だと分からない • HCIを考慮したデザイン選択が難しい (チェックボックス、プルダウンなど)  仕様の見方 • 複数テーブルの関連付けが難しい 課題2を通して苦労した点 RuboCopCircleCI
  10. 10. 課題2を通して学習した・感じた点  操作しやすいView • メンターから客観的な評価をして頂く • 既存のコードを参照  仕様の見方 • 新機能の全体仕様を確認 • binding.pryでデバック • (has_many , belongs_to)メソッドで関連付け
  11. 11. インターンシップを通して感じたこと  コミュニケーションの頻度  当事者意識
  12. 12. コミュニケーションの頻度  エンジニア同士のコミュニケーション • ウェルカムランチ • 1on1 4回 • LT会 2回 • エンジニアコミュニケーション制度 • エンジニアミーティング  エンジニア以外のコミュニケーション • チームランチ • ふらり横丁 • 忘年会 9回 3回 13日間で ほぼ毎日イベントが発生!!
  13. 13. コミュニケーションの頻度  本の概要(Team Geek) ソフトウェア開発を効果的かつ効率的にするためのチームの作り方  1.5 3本柱 人間関係を円滑にするだけでなく、 健全な対話とコラボレーションの基盤となる: 謙虚(Humility)、尊敬(Respect)、信頼(Trust) HRTが大事  2.4 成功する文化のコミュニケーションパターン 同期コミュニケーションに人数を減らし 非同期コミュニケーションの人数を増やす  2.9 すべてはコードに通ず コードを書くことを目的とする強いチームを作るには、膨大な コミュニケーションが必要となる Brian W. Fitzpatrick, Ben Collins-Sussman 「Team Geek」(オライリージャパン, 2013年)
  14. 14. コミュニケーションの頻度  コミュニケーションを通して 技術的用語が多く出てくる  知らない単語を調査  日報に調査結果を記述してアウトプット Vimはいいぞ~ 効率的なインプット&アウトプットに繋がる Datadogは〜 Mackerelは〜
  15. 15. 当事者意識  本の概要(THE TEAM 5つの法則) チームの成果を上げる「チームの法則」と 現代社会に対する活用方法  チームの一員としての携わり方 • 「ログDB設計に対してどんどん意見を出してください」 • 実際のサービスに取り入れる機能を実装  第1章 Aim(目標設定)の設定 チームが何のために存在し、 どんな影響を与えていくべきなのかをすべてのメン バーが意識し、自発的に行動し、 成果を上げるチーム作り 麻野耕司「THE TEAM 5つの法則」(幻冬舎, 2019年)
  16. 16. 最後に  まとめ • 実際のサービスに使われる機能を実装 • 現場のチーム開発を体験 • 強い(成果をあげる)チームを作る文化  感想 • 個人とチームの違いを学べた • 現場の知識を学べた貴重な体験でした • 目黒周辺のご飯は美味
  17. 17. ペットの顔認証 モデル図 ③カスケード型分類器 ②Haar-Like特徴 ①画像抽出・データ作成
  18. 18. ユーザのレビュー分類 モデル図 SNS/コミュニティ クリエイター 感情分析 ・ネガティブ ・ポジティブ レビュー分類 ・操作性 ・デザイン メッセージ1 操作性/ネガティブ メッセージ2 操作性/ポジティブ メッセージ3 デザイン/ポジティブメッセージ1 メッセージ2 メッセージ3 曖昧性解消 提示  「SNS」などの大量のメッセージから感情分析、レビュー分類に適用  分析したメッセージをクリエイターに提示 • 貢献 • 概要  効率的なユーザ意見の把握  クリエイターのコンテンツ創造の手助け  ユーザの利用率増加

×