はじめに この連載では共通化とモジュール分割について扱います。この話題においてQiitaで有名な記事のひとつが@MinoDrivenさんの単一責任原則で無責任な多目的クラスを爆殺するでしょう。この記事を未読の方はまずこちらを読むことをお勧めします。本連載では、この記事に書かれているような基礎的な事項については既知であることを前提に、どのようにすれば単一責任原則にそったモジュールの分割を行うことが出来るのかをなるべく 「場合による」という言葉に逃げずに なるべく 網羅的・理論的に 解説します。 いいね、ストックをよろしくお願いします。 対象読者 設計に興味のあるエンジニア 基礎的な設計原則について学んだものの、実際の場面でどのように応用すればいいのかが掴めないエンジニア ミクロな設計についての知識を増やしたい人 ※この記事では、特定のメソッドをどのように作成するべきか、このクラスは複数の処理

データベースシステムに関する入門。データベースの基本概念、データモデリング、リレーショナルデータモデル、データベース言語SQL、リレーショナルデータベース設計論、物理的データ格納法、問合せ処理等について講述する。 （2018年度） 【教科書】 「データベースシステム」(北川博之著、オーム社) 北川 博之筑波大学　計算科学研究センター教授1978年東京大学理学部物理学科卒業。1980年同大学理学系研究科修士課程修了。日本電気（株）勤務の後、筑波大学電子・情報工学系講師、同助教授を経て、現在、筑波大学計算科学研究センター教授。理学博士（東京大学）。データベース、データ統合、データマイニング、ストリーム処理、情報検索、ビッグデータ等の研究に従事。著書「データベースシステム」（オーム社）等。日本データベース学会会長、ACM SIGMOD日本支部委員長等を歴任。情報処理学会フェロー、電子情報通信学会

Welcome to Veloren!Veloren is an action-adventure role-playing game set in a vast fantasy world. 🏕️ Explore enormous mountains, arid deserts, dense jungles, and many more environments⚔️ Discover many different weapons and play styles with dynamic and fast-paced combat🏠 Interact with NPCs and craft equipment in towns to help you on your way☠️ Encounter menacing bosses and fearsome monsters in dun

最近ネットを見ていると要件定義入門的な記事が目についたので思ったことを書いてみる記事。ITシステム開発における要件定義に関するあれこれ。 【2023/10/10追記】続編の記事を書きました。実践要件定義入門 - 勘と経験と読経 目次 要件定義に関するおすすめ書籍 その要件定義は必要か 要件は決められるのか 要件定義をすることがルールで定められているから要件定義をする必要がある 要件は定義できるのか 現行の業務マニュアルをベースに要件定義をするつもりのあなたへ 現行システムをベースに要件定義をするつもりのあなたへ 外部業者を呼ぶ前に考えるべき事 どこから外注するかを考える 要件定義の作業期間を見積もる 要件定義に関するおすすめ書籍 この後に何度も引用することになると思うので、最初に要件定義のおすすめ書籍を紹介しておく。と言っても紹介するのは1つだけだ。 ユーザのための要件定義ガイド第2版 作

Language Server Protocol通称LSPの仕様と、各機能をどうやって実装したら良いかの指針を示します。 対象読者 * 言語処理系を実装する人/したい人 * Language Serverを実装する/したい人 * LSPに興味がある人、日本語のまとまった情報源を探している人 * Language Serverがエディタの裏でどのようなことをしているのか気になる人 本書で解説される機能は以下の通りです。 * Diagnostics (検査) * Completion (補完) * Inlay hint * Hover * Goto definition (定義へ移動) * Find references (参照を表示/移動) * Rename (名前変更) * Code actions * Code lens * Signature help * Command * Docu

小さなゲームを開発することの楽しさや、その作り方について、今までブログに色々書いてきた。 それらの内容を「小さなゲーム開発の楽しみ」という、小さな電子冊子としてまとめた。 楽しさを色々な側面から伝えるべく、以下の内容を盛り込んだ。 小さなゲームとは何か、そしてその制作がなぜ楽しいのかを探る ゲーム開発におけるターゲットデバイスや開発環境の選び方 ゲームの核となるアイデアの考案や、制約を活かしたアイデアの生み出し方 プレイヤーが感じる適切な難しさの設定方法 ゲームをより魅力的にするための「ジューシー」なエフェクトや音の追加方法 自作のライブラリ・エンジンの制作や、絵や音の自動生成方法 コンピュータがゲームを一から開発する可能性についての考察 小さなゲーム開発に興味がある方、またはすで開発している方にとって、なるべく有益な情報を含んだつもりだ。自分の興味に従って書いたため、散発的で多様な内容で

五大メタフィクションインディーゲームとはなにか。えっ、てか、なに（笑い） The Stanley Parable：「ナレーター」に抗う／従う The Hex; トランスジャンルなゲームたち undertale：アンチジャンル Doki Doki Literature Club!（『ドキドキ文芸部！』） ：メタフィクションに向いた職業ーーヴィジュアル・ノヴェル OneShot：あるいはその他のゲームたち おまけの追記：メタフィクションとはなにか。 Emergent Metafiction（創発的なメタフィクション） Immersive metafiction（没入的なメタフィクション） Internal metafiction（内的なメタフィクション） External Metafiction（外的なメタフィクション） おまけ２：参考文献リスト ファッキンホットですわね。 四季がぶっこわれた

はじめに 昨今ではますます Immutable な Domain Model の有用性が認知されているように思います。 また、Domain Model が持つ制約（不変条件）を満たさないインスタンスを作れないようにする事の重要性も広く知られてきており、Always-Valid Domain Model といった名称もついているようです。 ここでは、制約を満たしたDomain Model (Always-Valid Domain Model) しか作成できないようにするファクトリメソッドについて、より柔軟で合成可能性の高いファクトリメソッドを定義する方法を紹介します。 この記事で利用する言語とライブラリのバージョンは以下の通りです。 Scala 3.1.0 cats-core 2.7.0 最初のエラーで全体を失敗とするファクトリメソッド まずは単純に Either を使ったファクトリメソッド

初めまして、購買ソリューショングループ 運用・機能改善チームの稗田です。当社では自社で運営しているECサイト(モノタロウドットコム)から直接商品をご購入いただく他に、他社の購買システムと連携して商品をご購入いただくシステム(大企業連携システム)があります。こちらの大企業連携システムには多くのバッチ処理があるのですが、これまで自動テストがありませんでした。今回はバッチ処理の障害をきっかけに短期間でユニットテストを充実させるためにした工夫や学んだことをお話しします。 ユニットテストを作らなければいけないと思ったきっかけ 障害発生 担当システムやチームの状況 チームの1人として感じたこと お客様やステークホルダーの信頼を取り戻すために ユニットテストを短期間で作成するためにやった工夫 工夫1: 外部協力会社の力を借りる 工夫2: 課題や目的、ルールをドキュメントで共有する 工夫3: リファレンス

こんにちは。技術部平山です。 今回は、ゲームにおけるA/Bテスト について論じます。 「論じます」で始めたことで察しがつくかとも思いますが、今回はブログではありません。 媒体はブログですが、ブログの容量ではない代物になっております。3.5万字(115KB)超えです。 ゲームにおけるA/Bテストについて、実施の方法や問題点、 倫理的側面に至るまで幅広く書き連ねてみました。 読んで欲しいのはどちらかと言えば同僚なのですが、 そういう時にはまず社外に出してしまった方が良いものですので、 ブログにしてしまいます。 比較的同業の方が読むことを想定しているため、 図表を用いてわかりやすくすることはしておりません。 これを書いた人間は何者か 技術的な問題の前に ゲームにおいても構図は全く同じ A/Bテストが可能である条件 A/Bテストの手続きを概観する 振り分け アプリ内振り分けの場合 Firebase

バッチ処理は既に先人の方々が多くのナレッジを公開してくれていますが、それでもなお難しさが変わらないテーマだと思っています。 この記事は、筆者がこれまでの開発経験で気づいたバッチ処理の実装ナレッジを整理し、体系化を目指して文章にしました。 ここでの内容が、より良い課題解決に貢献できれば幸いです。 自身の断片的な思考整理(メモ書き)の延長で内容を整理したため、一部書き振りが統一されておらず、読みにくいかもしれません。ご了承ください。🙏 バッチ処理の難しさバッチ処理は難しい。 人によっては簡単なテーマかもしれませんが、自分は難しいテーマだと思っています。 「難しさの根源は何か？」を考えると、1. 考慮点が多様にあること 2. 解決する課題によって答えが大きく変わること に整理できました。 この2点は、どのソフトウェア開発にも当てはまる項目ではありますが、ことバッチ処理においては顕著に現れます。

はじめに 今でも語り継がれる「原則」は、それだけ価値のあるコンセプトです。 歴史を振り返ることは、失敗を防ぐための効率の良い方法になります。 👑 DRY (Don't repeat yourself) 「同じことを繰り返すな。」 Andy Hunt と Dave Thomas の著書『達人プログラマー』（1999 年）で提唱された原則で、プログラミングに関する最も重要な原則といっても過言ではありません。 DRY 原則だけでなく、どんなデザインパターンやベストプラクティスでも、同じ処理が重複することは基本的に許されていません。 これにはどういう意図が込められているのでしょうか。 🔖 表面的な理由 この原則は、コードの再利用性を高め、そのために疎結合な状態を保つことは、極めて有用なことを示唆します。 1 箇所を直せば済むべき箇所をあちこちに分散させてしまうのは、自分で事故を招いているのと同