この記事は 一休.com Advent Calendar 2024 7 日目の記事です。 宿泊事業本部 ユーザー向け開発チームの原です。 一休.com と Yahoo!トラベルの主にフロントエンドの開発を担当しています。 今回は、普段の開発でコードを書き始める前段階で Design Doc を作ることで、円滑な開発を進められるようになったというお話をします。 チーム構成について まず、前提を共有するために私達が普段どのような体制で開発しているかを説明します。 私が所属している宿泊事業本部 ユーザー向け開発チームは、一休.com と Yahoo!トラベルの主に toC のユーザー向けの機能開発をしています。ユーザー向け開発チームのメインのミッションはユーザー体験を向上させることであり、そういった施策の機能開発を素早くリリースできることを大事にしています。 一方、プロダクト開発においては機能開
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? こんにちは、Unity Adnvent Calender 202415日目の記事になります。 私Shitakamiは普段JobSystemを使った魚群シミュレーションを開発してまして、ここ最近はゲームに転用する試みをしていました。 今回はこれらコンテンツやゲームの開発で考えた設計と実際に開発で感じた所感についてまとめます。 前提 この記事ではUnity JobSystemについて解説しておりません🙇♂️ JobSystemの詳細は以下の記事などを参考にしていただけると助かります。 背景 簡単にどのようなものを作っていて、設計を考える
前提 ViewとModelは、MVPのViewとModelのイメージ 以下は自分の認識 MVxはそもそもViewをView以外とどう切り離すかの話なので、Model＝View以外の処理 DDDなどのドメインは、システム化するメインのルール、仕様のこと Model⊃ドメインの関係 UnityにおけるViewとは ViewというとGUI、画面を想像しがちだが、ViewとはUI、ユーザーインターフェイスである。ユーザーとの境界面の入出力全般を指す。 そしてUnityの持つ主な機能のほとんどはユーザーインターフェイスを担当するものである。 引用元：https://commons.wikimedia.org/wiki/File:Linux_kernel_INPUT_OUPUT_evdev_gem_USB_framebuffer.svg 人とソフトウェアの間にはハードウェアが存在し、ハードウェアと通信
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 普段はクラス設計の話をよくしているのですが、今回はより大局的な「アーキテクチャ設計」の話です。 この記事では「非ゲームアプリケーションを、クリーンアーキテクチャを意識してUnityで作るとどんなアーキテクチャとなるのか」を紹介します。 前回「VoicevoxClientSharp: C#やUnityからVOICEVOXで音声合成するライブラリの紹介」という記事を投稿しました。 「VoicevoxClientSharp」というライブラリをせっかく作ったのだから、それを使ったサンプルアプリケーションを作ってみようと考えました。そし
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? もう10年ぐらい前の話なので懺悔として記載します。 背景 まだ駆け出しのネットワークエンジニアだった私は、先輩から「こういうルータ作ったんだけど動作検証しといて」と資料一式を渡されました。 店舗の重要性が増してきたため、店舗のWAN回線を冗長化したいという商談でした。既存環境の設計書やコンフィグもあり、追加WANルータのコンフィグも既に先輩が作ってくれていました。私は試験仕様書を書き、検証環境を組み、冗長化試験を行いました。特にコンフィグを訂正することもなく試験は完了したため、先輩に引き渡しました。なのに・・・本番環境ではうまく動かなか
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事は、Unity Advent Calendar 2024 (シリーズ1) 4日目の記事です。 はじめに Unityを使って開発を行う際、主軸となる成果物はMonoBehaviorを継承したコンポーネントスクリプトです。StartやUpdateなど、あらかじめ用意されたライフタイムイベントに処理を記述し、シーン上のGameObjectにアタッチするだけで動作するため、直感的で分かりやすい仕組みといえます。このおかげで、Unityでは初心者でも比較的簡単に自分のアイデアを形にできる環境が整っています。 しかし、Unityの活用方法は
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 最初に 本記事では、Unityでのマルチシーンエディティング（Multi Scene Editing）機能につい、開発で役立つ知識や実装方法を紹介します。 マルチシーンエディティングについて知ることで、プロジェクトの画面構成の幅が広がり、開発効率を向上させるきっかけになるでしょう。この記事が、プロジェクト開発の土台作りの一助になれば幸いです。 この記事の対象者は次の通りです。 プロジェクトの初期段階で、どのような画面構築システムを採用すべきか悩んでいる方 すでにプロジェクトでマルチシーンエディティングを導入しているが、まだ使い方をよく知
人工衛星の設計って，ふつうの機器の場合と何が違うの？という質問をたまにされるので，具体例を思いつくまま挙げてみます．一般論というよりも自分の経験による部分が大きいので，JAXAやNASAの衛星ではこの限りではないかも． 宇宙環境の3大強敵 宇宙で動くモノをつくるにあたって，考慮すべき敵は3つ． 真空 熱 放射線 色んな人が色んな環境で使う自動車なんかと比べると，環境が精度よく予測出来るのである意味楽．このほかにデブリもリスクだけど，設計で回避できるようなモノではない． 電気・電子系の開発 fail safe, fail operativeの徹底 修理が出来ない分，偶発故障に対する耐性を十分持つ必要がある．電子部品の故障モード（オープンORショート），偶発故障率（MIL-HDBK-217などを使う），システムへの影響度（FMEA）から，必要十分な対応を取る．「Aが壊れた時のためにBを用意しよ
この記事では、「アジャイルはウォーターフォール時代の何を反省するのか」「アジャイルで何が改善するのか」について、個人的な考えを説明します 極端なことを言っている部分はあるので、誤解している箇所や異論があれば、やさしくコメントで教えていただければ幸いです 言いたいこと 「ウォーターフォール＝諸悪の根源」というのは誤解で、問題は請負契約にある 請負契約で「顧客の真の要望が実現されない」のは当然、インセンティブ設計がおかしい 日本版のアジャイルソフトウェア開発宣言には「外注よりも内製を」と書くべき 競争に勝つためには内製化は進む(でも内製化はとても難しい) ベンダーへ「君はアジャイルをやるか迷える立場じゃないよ」 目次 用語 ウォーターフォールは本当に諸悪の根源か？ 「ウォーターフォール＝諸悪の根源」という誤解 問題の原因は請負契約 なぜ請負契約は失敗しやすいのか？ ベンダーは「システム開発だけ
「すべてのライフサイクルモデルの祖は、ウォーターフォールモデルである」とは、スティーブ・マコネルの言葉だ1。また、ソフトウェア開発ライフサイクル（SDLC）に関するGitHubの文書では、広く採用された最初のSDLCがウォーターフォールモデルであるとされている2。 そこに、ウォーターフォールを学ぶことに対する価値がある。それは、スクラムを導入し、アジャイルソフトウェア開発を実践する組織にも言えることだろう。いや、そうであるからこそだ。どんなソフトウェア開発プロセスモデルであろうと、ウォーターフォールから派生したり、何らかの影響を受けていると考えられる。したがって、ウォーターフォールへの理解から、自分達がやっていることの本質を見いだせるのではないだろうか。 ウォーターフォールなんて誰でも知っていると思うかもしれないが、そうとも限らない。確かにウォーターフォール未経験のソフトウェア開発者は少な
2. 吉羽龍太郎 / Ryutaro YOSHIBA / ryuzee ✤ 株式会社アトラクタCTO /アジャイルコーチ / 翻訳者 ✤ Scrum Alliance 認定スクラムトレーナー ✤ X(Twitter): @ryuzee / https://www.ryuzee.com/ 2 4. 株式会社アトラクタについて ✤ 社名：株式会社アトラクタ 英文表記：Attractor Inc. / https://www.attractor.co.jp ✤ 設立：2016年12月 ✤ 所在：東京都港区 ✤ 開発プロセスに関するコンサルティングやトレーニングを提供 ✤ アジャイル開発 / DevOps / チーム育成 / クラウドコンピューティング / ドメインモデリングな どが専門領域 4 5. アトラクタのアジャイルコーチングで 持続的に成果を出し続けるアジャイルチームを作る 「あなたのゴ
はじめに 株式会社tacomsでCTOやってる井上です！ tacomsは複数デリバリーサービスを1台のタブレットにまとめたり、様々なPOSレジ会社と連携してオペレーションをシームレスにする「Camel」というプロダクトを提供している会社でして、プロダクトの属性上めちゃくちゃ連携している会社数が多いのが特徴です。（様々な属性の連携パートナーを合わせるとなんとざっくり30以上！！！） また、tacomsではPublicAPIも作っているため、連携先のAPIに合わせて開発するだけでなく、連携先に使ってもらう汎用APIの開発にも取り組んでいます。 外部APIを使う側、作る側の双方を開発してきた経験から、連携開発に取り組む上でのスタンスや考慮事項をまとめてみました。少しでも皆さんのお役に立てると幸いです！ 外部API連携の定義 おおよそ一般的な認識だと思いますが、外部APIを 「連携先の会社が開発し
はじめに こんにちは。プログラマの境田です。 この業界に入って10年以上経ち、様々なゲーム開発に携わってきました。 その中でゲーム開発を少しでも円滑にするため、ツールもいくつか作成しました。 今回は私が経験したこと、学んだツールづくりで必要なものや大事なものを記載しようと思います。 初歩中の初歩の内容になりますが、ツールづくりに興味がある方など、読んでいただくと幸いです。 制作環境 入社したての頃はWin32でツールを作成していましたが、ゲームの質の向上に合わせ、制作コストを軽減させつつ、質の高いツールを作れるようになるため、現在はWPFを活用しています。 C#言語を使用し、コントロールの追加、操作が容易に行え、低コストで様々な機能を作成することができ、重宝しています。 グラフィック表示などを行う場合は、UnityやUEを使用すると作成しやすそうですが、簡易的なツールでしたらこちらを使用す
これはなに？ こんにちは、DMM.comのミノ駆動です。 プラットフォーム開発本部 Developer Productivity Group 横断チームにて、 プラットフォームの設計品質向上に取り組んでいます。 さて、ネット上ではソフトウェア開発における「良いコードとは何か」をめぐって、 いろんな意見が交錯したり、 ときには激論を呼んだりします。 収拾がつかないこともしばしばです。 この記事は、良いコードを考えるうえでの要素を整理し、 建設的な議論を助けることを目的とします。 これはなに？ この記事の理解目標 良いコードをめぐる議論 議論1: 何をもって良いコードなのか 議論2: 良いコードはどうやったら書けるのか 議論3: 「綺麗なコード（良いコード） vs 動くコード」問題 議論改善のために提案します 提案1: ソフトウェア品質特性の観点でコードの良し悪しを判断しよう 提案2: 原理原
はじめに エンジニアのみなさま、日々の学習本当にお疲れ様です！ また本記事まで足を運んでいただき本当に感謝です。 約3分程度で読めるので最後まで読んでもらえると幸いです。 要件定義関連の記事の投稿をしました。時間あればぜひ読んでみてください。 今回は「非機能要件」の 可用性 性能・拡張性 運用・保守性 移行性 セキュリティ システム環境・エコロジー の6項目について理解を深めてアウトプットしようと思います。 非機能要件｜6項目について 1. 可用性 システムが継続して利用可能な状態を維持する能力を指します。『稼働率』 で表現されます。システムは定期メンテナンスや予期しない障害により、一時的に利用できなくなることがあります。可用性は、稼働している時間と停止から復旧までの時間の割合で決まります。たとえば、Amazonの「Amazon ECS」サービスは 『99.99%』 の稼働率を保証しており
本日は人生の数ある選択肢のなかから、こちらのブログを読むという行動を選んでくださいまして、まことにありがとうございます。 はじめに プログラミングの世界には多くの指針や原則が存在します。Chris Zimmerman氏の「The Rules of Programming」（邦題：ルールズ・オブ・プログラミング ―より良いコードを書くための21のルール）は、不変の知恵を凝縮した一冊です。これらの原則は、多くの開発現場で活用できる有益な内容となっていると思いました。 The Rules of Programming: How to Write Better Code (English Edition) 作者:Zimmerman, ChrisO'Reilly MediaAmazon 本書は、大ヒットゲーム『Ghost of Tsushima』などで知られるゲーム制作スタジオ、Sucker Pun
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
