業務を進める上で障害となる問題を解決してしまいたい。でもそれに取り組むことが許可されない。時間や予算をもらえない。このままでは問題がどんどん大きくなって、いずれ手に負えなくなってしまう—— 組織に身を置いていれば、1度は経験するかもしれないストレスです。それを何度も重ねるようなことになると、問題を指摘する気すら失せてしまいます。どうせ聞いてもらえない。言うだけ無駄。そう感じるようになります。組織を去ることすら考えるようになるでしょう。 そもそもなぜ、問題解決に取り組むことに理解が得られないのでしょうか。そこにはいくつかの段階があるのですが、実は、最初の段階でつまづいてしまっていることが多いように感じます。 それは、“問題の存在” 自体が相手に理解されていない、ということです。そうであるなら、解決への取り組みに必要性を感じてもらえるはずもありません。 存在しない問題に解決策など必要ない問題解

Object-Oriented Conference 2024で発表した資料です。 https://fortee.jp/oocon-2024/proposal/b31c9818-3cb8-4350-adfe-cbc839cdf829 ビジネスの専門知識（ドメイン）を中心に据えたドメイン駆動設計に…

以下の文章は、Paul Graham による How to Start Google の日本語訳である。 本翻訳文書については、Shiro Kawai さんに誤訳の訂正を頂きました。ありがとうございました。 （これは、14～15歳の子たちに、いずれスタートアップを始めたいと思ったら何をやるべきかについて私が行った講演である。多くの学校が、スタートアップについて生徒に何か教えるべきだと考えている。これこそが、私が学校が生徒に教えるべきと思っていることだ。） あなた方のほとんどが、いわゆる現実世界に放り出されたら、いずれはある種の職に就かねばならないと考えているでしょう。それは正しくなくて、今日、私はあなた方が職に就かなくて済むために使える技を指南します。 その技は、自分の会社を始めることです。つまり、それは働くのを避ける技ではありません。自分の会社を始めたら、普通の職に就いた場合よりも懸命に

去年末から続いていた余裕のない日々も終息し、仕事以外であれこれ考える時間が持てるようになった。その間にアンリアルエンジンは当たり前に進化、ユーザーもますます増えて共有される情報も豊富になり、取り残されたたような寂しさを感じています。 このブログもほぼ１年間更新していないにもかかわらず、それなりのアクセス数に何となく後ろめたさを覚えつつも、少しでも誰かの役に立てているかと思うと書いてよかったと思っています。 さてさて ゲージ100本ノック 発端は、チームメンバーの後輩がシェーダーを勉強しようと既存のアセットを睨みながら難しい顔をしているのを見て、いい教材がないことに気づいたことだった。 UI でシェーダーを使う機会は多いと思う。（UEからUIのお仕事を始めた方にはマテリアルと言ったほうがいいかもしれないけど、ひとまず シェーダー と表記して進めます） 使わなくても UI は作れますが、使いこ

「良いコード／悪いコードで学ぶ設計入門」という本がとても売れているようです。私の所属している開発チームでも、何人か購入した人がいたので、私も購入して一通り読んでみました。 結果として、いくつかの考えが整理され、私としてはこの本によって考えが深まり、本を読んで考えた事自体は有意義であったと思いました。ただし一方で、あまり知識がない状態で（自分の中での判断軸が無い状態で）この本を読むと、色々と誤解が生まれるのではないか？という事を感じました。 一つの技術書がこれだけ売れるという事はそんなに多くはない事だと思うので、つまり、 その内容が改善されるとその効果は相対的に大きい という事になります。そこで、私が本を読んでいて思ったことや、この本の内容で正しいこと、現在も賛否両論とされること、事実として認識が間違っているであろうこと、この本で触れられていないが設計において大事なこと、などについてまとめて

内容がネガティブに取られそうで、公式なところに書くべきではないので個人ブログで書きます。 この記事は、公式なブログで僕が書いた「社内横断の技術組織をはじめました」という記事へのアンサーブログになります。 ※元の記事は探せば出てきそうだし、個人的なブログと紐付けるべきではないのであえて出しません。 特定の誰かを陥れる目的ではなく、完全に個人の責任として、始めたものを終わらせてしまったことへの事の顛末を記録する目的で書きます。 はじめに 始めた理由 CTOの不在 品質面に対するレビュー不足 技術広報の不足 それぞれの施策の結果 時間がかかってみんなストレスが溜まる新規レビュー 当たり障りの無いことしか表現できない運用レビュー 兼任状態が続き、進まない新規技術検証 やる必要の薄い「全社」広報 終わった理由 成果が出せなくて、そもそも証明出来ないかもしれない 問題解決は組織じゃなくても出来ると気が

TotT 102 GTAC 61 James Whittaker 42 Misko Hevery 32 Code Health 30 Anthony Vallone 27 Patrick Copeland 23 Jobs 18 Andrew Trenk 13 C++ 11 Patrik Höglund 8 JavaScript 7 Allen Hutchison 6 George Pirocanac 6 Zhanyong Wan 6 Harry Robinson 5 Java 5 Julian Harty 5 Adam Bender 4 Alberto Savoia 4 Ben Yu 4 Erik Kuefler 4 Philip Zembrod 4 Shyam Seshadri 4 Chrome 3 Dillon Bly 3 John Thomas 3 Lesley Katzen 3 M

目次 環境 Unreal Engineで使用可能なDelegateについて C++でDelegateを記述する方法 Singlecast delegateの場合(DECLARE_DELEGATE) Multicast delegateの場合(DECLARE_MULTICAST_DELEGATE) Dynamic singlecast delegateの場合(DECLARE_DYNAMIC_DELEGATE) Eventの場合(DECLARE_EVENT) Dynamic Multicast delegateの場合(DECLARE_DYNAMIC_MULTICAST_DELEGATE) Blueprintで呼び出し可能なDelegateをC++で記述する方法 Dynamic Multicast delegateを使用する(Event Dispacher相当) Singlecast deleg

最近では珍しくもないMODの実装について、自分なりにまとめることにした。 方法の記載は確かにあるけど、情報源が足りない… というか「作る」情報はあっても、ゲーム内でそれを引き出して扱う情報が足りないと思う。 なのでUEにおけるMODとはどういうものか説明を残しておきたい。 ※この記事はゲーム本体を完成させパッケージ化できていることを前提にしてるのでご了承を。 記事にする実装内容は大きく分けて５つ ただし長いので分割する予定。今回は１～２当たりの内容となる MODを作成するには MODをゲームで適応させるには Steamワークショップ対応①MODのアップロード Steamワークショップ対応②MODのインストール インストールしたMODの削除について 実装までの前置きが長いので不要な人は序盤を飛ばしても大丈夫です 目次 前置き：MODとは？ ①「MOD」ってなんぞや？ ②そもそもUEにおけるM

はじめに 無料、有料問わず色々な所ゲームに使える素材というのが公開されていて、 僕も個人で開発してる全てのゲームでお世話になっています。 Unity アセットストア - ゲーム制作のための最高のアセット 素材と一口に言ってもBGMやSE、画像や3Dモデルにフォント等など、色々な物がありますが、 その中でも意外と一番見つからなくて困るのがUIではないでしょうか。 まだ海外のゲームっぽい素材であれば結構あるのですが、 日本のゲームっぽいUI素材となるの本当に希少です。 UIは違う素材を組み合わせて使うというのが(素人には)難しいため、セットで欲しいですし、 画像生成AIでもまだ作り辛いジャンルというのも希少性に拍車をかけているのかもしれません。 と言う事で今回はゲームで使えるUI素材が売っている場所と、 意外と見つからないオススメの日本のゲームっぽいUI素材の紹介です！ Unity Asset

UE5で新しく実装された非同期処理APIシステムにTask Systemと呼ばれるものが追加されています。これは日本のゲーム業界で呼ばれる一般的なタスクシステムと呼ばれるものとは全く違い、C++で簡単に汎用的な非同期処理を実現するためのジョブマネージャーです。 UE4から汎用的な非同期処理を実現するためにはTaskGraphというシステムが存在していましたが、TaskGraphはプログラミング初心者が利用するには非常にハードルが高い内容となっており、非同期処理の専門家でないと扱いが難しいものでした。Task Systemは複雑化していた非同期処理のコードを簡潔に記載できるようになるだけではなく、依存関係の処理や同期が必要な共有リソースへのアクセス、更にはPipeと呼ばれるタスクを連続して実行するタスクチェーンの仕組みが同時に用意されています。 非同期処理の扱いは難しいものがありますが、UE

Unityを学ぶための動画を集めたサイト「Unity Learning Materials」。ユニティ・テクノロジーズ・ジャパンの安原氏が、ゲーム制作に使う数学について解説しました。Part2は、式の読み方について。複雑な式に対してどの部分に注目するかを解説し、少しでも数式に向き合えるコツについて話しました。​​ 数式を見る時間をどうにか3秒まで伸ばしたい 安原祐二氏（以下、安原）：次はパート2ですね。ここではかなりフワッとした話をします。数学の話をする時は、どれだけ間違ったことを言わないかと気をつけなければならないので本当に大変なんですが、ここは本当にフワッとした情緒的な話をしていきたいと思います。そのほうがわかりやすいことも多いかと思うので、お話として聞いてみてください。 これはマサチューセッツ工科大学の購買部で売っているTシャツで、僕の同僚が買ってきてくれたお土産です。これがグッズと

はじめに スタンフォード大学の John Ousterhout 教授が執筆された “A Philosophy of Software Design”(以下 APoSD と略す) という書籍をご存じでしょうか？ 書籍のタイトルを直訳すると、「ソフトウェア設計の哲学」となります。書籍の内容はまさに、ソフトウェア設計について扱っています。 本書籍をベースに、「A Philosophy of Software Design を30分でざっと理解する」というお題で社内ランチ勉強会が開催されました。本記事執筆者である岩瀬(@iwashi86)が発表者であり、勉強会資料は以下のとおりです。 スライド P.4 に記載したとおり、本書籍は John Ousterhout 教授の意見が強く反映されており、ソフトウェアエンジニアであれば、議論を呼ぶ箇所があります。実際、勉強会の実況Slackでは、「これはどうな

Value Objectとは何であるか? マーチン・ファウラーのPatterns of Enterprise Application Architecture(PofEAA)やエヴァンス・エリックのDomain Driven Design: Tackling Complexity in the Heart of Software(DDD)が原典であるが、PofEAAではこう切り出している。 When programming, I often find it's useful to represent things as a compound. プログラミング時は物をcompound(合成物)として表現すると便利なことがしばしばある。 例えば2次元空間上での座標のように複数のメンバ(属性)を持つ物は便利である、と。しかしそれらを比較する方法は一意ではない、そこで Objects that a

AWS Lambda を使用した Web アプリケーションの開発プロジェクトで、バックエンド・フロントエンド・インフラを一貫して開発をしてきました。 改めてどのように開発をしていたのか、使った技術スタックや各サービスをどのように活用したかを整理したいと思い記事にしました。今後サーバーレス開発を行う際の技術選定の参考にしていただければ幸いです。 前提 Web アプリケーションです。 管理画面用の内部 Web API、外部のサービスと連携するための外部 Web API があります。 処理としてはリソースの CRUD がメインです。 管理画面は SPA で、バックエンドの Web API にリクエストします。 開発メンバーは 4 人ほどで、フロントエンドエンジニア、バックエンドエンジニアといった区分けはしていませんでした。 機能ごとにメンバー全員がバックエンドからフロントエンドまでを一気通貫で実

「変数のスコープは狭いほど良い」と妄信する 変数でもメソッド名でもクラス名でも言えることだが、単純に「スコープは狭いほどよい」という方針でプログラムすると、逆に保守性も可読性も悪いプログラムができあがることがけっこうある*1。 実際、「あちこちから頻繁にアクセスするようなオブジェクトやメソッド」は、スコープをぐっと広くしてしまった方が(場合によってはグローバル変数やグローバル関数にしてしまった方が)、いちいちパラメータ渡しのバケツリレーをせずに、オブジェクトや機能を使うことができ、プログラムの可読性も保守性もずっと向上することがけっこうある。 たとえば、プログラムのいろいろな箇所から比較的頻繁にアクセスする必要があるようなオブジェクトや機能がバインド(格納)された変数やメソッドのスコープをクラスやメソッド内のローカルにして、それを使うときは、いちいち各クラスやメソッドにパラメータ渡しのチェ

Javaのgetter/setterのお話。 僕は当時を語るには若すぎるのだけど、過去を振り返って書いてみる。当時を知る人は誤りがあれば指摘してほしいし、情報があればコメントなりトラックバックなりして欲しい。前世紀の話というのは今となっては探すことがなかなか難しくなりつつある。 「privateな変数にpublicなアクセサを定義する」？ - ネットの海の片隅で getter/setterとは何か Javaのオブジェクトにフィールドがあったとして、そのフィールドに値を設定するメソッドがsetter(せったー)、そのフィールドの値を取得するメソッドがgetter(げったー)と呼ばれる。慣習としてsetterはsetXXX(int value)といった様にsetから始まる名前をつけ、引数はひとつ。戻り値はvoid型。getterはgetXXX()といった様にgetから始まる名前をつけ、引数はな

オブジェクト指向には、カメラがやっとついたころのガラケーのイメージがある - きしだの Hatena の件。基本的には同意。ただちょっと切り口が違うので自分の意見を言っておく。ただ、このテーマで何度か書こうとして失敗していて、今回も成功しているとはいえない。 宣言的プログラミングの時代 現代の主流は「宣言的プログラミング」であると思っている。これはリソースの宣言と、その状態遷移の手続きや振る舞いの付与が中心にある。 宣言型プログラミング - Wikipedia その代表的な例がフロントエンドの React と、バックエンドの k8s で、どちらも時系列に基づいた状態の宣言と、フレームワーク側による状態遷移処理、 Reconcillation(調停) が基礎にある。 フロントエンドとバックエンドという両極端な世界で、この変化が起きたのがこの時代を反映したものであると思う。 例えば、jQuer

ソフトウェアの世界には「悪い方が良い」原則という有名なエッセイがある。キレイにレイヤ分けされた一貫性のある良いデザインよりも、一見手抜きっぽい悪いデザインのほうが実は良いときもあるという話だ。この逆説的なデザイン原則を僕は身をもって体験したことがある。それについてちょっと書いてみようと思う。 僕はlldというリンカの現行バージョンのオリジナル作者だ。リンカというのはコンパイラと組み合わせて使うもので、実行ファイルやDLLを作るのに使用される。lldはプロダクトとしてはかなり成功していて、標準のシステムリンカとして採用しているOSがいくつかあったり、GoogleやFacebookなど皆が知っているような大規模サイトの中で広く使われていたりする。 現在のlldは2世代目で、第1世代のlldは僕がプロジェクトに参加する前から存在していたのだけど、数年前にそれを捨てて一から書き直すということになっ

まとめプログラミング未経験から1ヶ月ほどで、将棋の評価値の新たな方法でのグラフ化を行うPythonツールを作った。 https://github.com/k-the-p/notherscore この記事は2本立てです。プログラミングより結果のグラフや将棋に興味がある方はもう一方の将棋編から読むことをおすすめします。 未経験から1ヶ月！Pythonで観る将ライフを向上させた話（将棋編） 目標評価値以外の観る将の楽しみとして、手の広さの可視化を提案するAIはわれわれアマチュアの将棋への親しみを大幅に向上させてくれた一方で、棋士が悩みに悩んだ結果として評価値が下がる手を指してしまったときに、「悪手きたwwww」と騒ぐ主にABEMAのコメント欄には忸怩たる思いがあった。 とはいえ、もう評価値を知らなかった時代に後戻りするなんてことは誰にもできないだろう。そして、電王戦から将棋にハマった自分自身とし