腕木通信で遊ぼう
1983年徳島県生まれ。大阪在住。散歩が趣味の組込エンジニア。エアコンの配管や室外機のある風景など、普段着の街を見るのが好き。日常的すぎて誰も気にしないようなモノに気付いていきたい。（動画インタビュー） 前の記事：網戸越しに景色を撮ると自分ちの庭みたいに見える ＞ 個人サイト NEKOPLA Tumblr 腕木通信とは 腕木通信は、1793年にクロード・シャップによって発明された通信手段である。今でもよく知られているモールス信号（電信）が登場するよりも前の話だ。 どんな感じで情報を送るのか、自作の腕木通信機で試してみた。例として「我が輩は猫である、名前はまだない（WAGAHAI HA NEKO DEARU NAMAE HA MADA NAI）」というのを送ってみよう。 このクネクネした動きが「猫である（NEKODEARU）」を表している 全文は動画でどうぞ モールス信号はトン（・）とツー（
1. はじめに JavaScriptデザインパターンは、JavaScriptを使ってプログラムを書くときによく出くわす問題を解決するためのガイドです。これらのパターンの背後にある考え方を理解することで、自分の問題に適用することができます。また、これらのパターンが自分のコードに役立つ場合を見つけることもできます。 2. モジュールパターン モジュールパターンは、JavaScriptのモジュールシステムの一部で、データを保護する方法を提供します。これは、モジュール内のプライベートなデータと動作を保護し、一方で公開APIを提供する方法です。これにより、プライベートとパブリックのアクセスレベルを持つ自己完結型のモジュールオブジェクトを作成することができます。 これは、JavaやC++のような言語でクラスにアクセス修飾子を使用するのに似ています。 JavaScriptでは、クロージャを使用してモジュ
エンジニア歴1年の僕がドメイン駆動設計(DDD)を参考にLaravelのプロジェクトをフルリニューアルした話 - Hajimari Tech Blog| 株式会社Hajimari
こんにちは！ はじめまして！ 2020年7月からPIECE事業部でエンジニアをさせてもらっています。 野澤です。 今回、PIECEというサービスのリニューアルを担当させてもらったのでその時のことについて書きたいと思います！ まだ若輩者なので至らない点が多々あると思いますが フルリニューアルってどんな事したんだろう〜？ Hajimariのエンジニアはどんな仕事をしてるんだろう〜？ って思った人はぜひ読んで見てください！ ※ドメイン駆動設計の説明も書いたのですがボリュームが多くなってしまいました… ドメイン駆動設計について概要知りたいという方は是非読んでみてください。 クリーンアーキテクチャの説明やモデリングのやり方などは説明していません。 ご了承ください。 PIECEリファクタリングプロジェクトの概要 PIECEとはどのようなサービスなのか リニューアルの目的 リニューアル施策 ドメイン駆動
まんが 「オブジェクト指向ユーザーインターフェース」
表紙 The Art of User Interface Design ジ・アート・オブ ユーザーインターフェースデザイン 藤井 幸多 少年と博士が並んでいる 扉絵 オブジェクト指向ユーザーインターフェース 健太が思考の中からオブジェクトを手で取り出し、アプリのデザインへ埋め込んでいる それを見守る博士と母親 橘 健太（以下 健太）「決めた！アプリを作る！！」 健太の母「え？アプリ？」 健太「うん！毎日いろんなものを見つけるんだけど図鑑に載ってないものが多くて」 健太「だから見つけたものを記録するアプリを作りたいんだ」 健太の母「それはいいアイデアね！！でも困ったわ。お母さんそういうこと全然詳しくないのよ。あ！イリュウ博士に聞いてみたらどうかしら？」 健太「手品師のジョンおじさん？」 健太の母「そうよ。確かコンピュータに詳しかったはずよ」 射留（いりゅう）研究所 ジョン・イリュウ博士（以下
2023年 研究開発部 新卒技術研修 ~ 実践編 ~ - Sansan Tech Blog
こんにちは、研究開発部 Architectグループの藤岡です。 4/26（水）〜 4/28（金）で研究開発部内の技術研修を行ったので、その内容を公開します。 目次 目次 研修の目的 研修の概要 実践編の概要 アプリケーションを作成 バッチを作成 gokartとは パイプラインを実装 APIを作成 FastAPI とは APIを実装 ディレクトリ構成 実行 Webアプリを作成 Streamlitとは Webアプリを実装 Docker化 デプロイ ECRにイメージをプッシュ アプリケーション基盤 Circuitについて アプリのマニフェストを作成 研修終了後 終わりに 研修の目的 この研修の主な目的は、新卒社員がスムーズに業務に入れるようにすることです。 研究開発部にはさまざまなバックグラウンドを持つ研究員が入社するため、チーム開発の経験がない方もいます。 そのため、Gitの操作やプルリクエス
概要 こんにちは、Offers を運営している株式会社 overflow の Software Engineer（主戦場はフロントエンド）の Kazuya です。2022 年 2 月入社でそこまで日が経っていないので、今回は社内の技術スタックではなく、今後社内でも検討されるかもしれない「BFF」について触れていきたいと思います。BFF（Backend For Frontend）導入することで得られるメリット/デメリット、GraphQL を用いた技術スタック事例など紹介していますので、ぜひ参考にしてもらえればと思います。 BFF とは？ BFF とは、Backend For Frontendの略称で、「フロントエンドとバックエンドの中間に配置され双方の複雑な処理を緩和させる責務を持つアーキテクチャ設計パターン」のことです。これだけだと分かりづらいので簡単にまとめると、「バックエンドの API
CQRSはなぜEvent Sourcingになってしまうのか、まとめてみたいと思います。 なぜまとめるか、それはCQRSにとってEvent Sourcingはオプションだと誤解されている方が多いからです。この記事を書いてる本人も最初はそう思っていましたが、実際に開発・運用を経験してみるとCQRSにとってEvent Sourcingはほぼ必須で、認識を改めるべきだと気づきました。なので、原義に基づいたうえで、Event SourcingではないCQRSがなぜよくない設計になるのか解説します。 その前に松岡さんの記事について。 CQRSの領域ではモデルを完全に分ける 松岡さんの記事には”CQRSはモデルを完全に分ける必要はない”と書かれていますが、知識がないと誤解しがちですが文字のまま意味を取るといけません。こちらの言及は、システムのうち、モデルをC/Qに分割するCQRS領域とモデルを分割しな
クラス設計の考え方とやり方 クラス設計の目的 - ソフトウェアの複雑さを扱いやすくする - ソフトウェアの変更を楽で安全にする クラス設計の三つの視点 - 関心の分離 - 依存関係 - モジュール性 クラス設計の５つの技法 - 計算判断と入出力の分離 - 中核と周辺の分離…
Rustでの 抽象化 3パターンについて
※この記事は全然入門記事ではないです。Javaなどのオブジェクト指向言語とRustをある程度理解している前提での記事です。あと、メモ程度に雑に書いています。 今回は抽象化がテーマです。オブジェクト指向の多態相当のことをRustでどうのように解決すればいいのでしょうか。個々の実装型の都合によらず、呼び出し側は統一的なインターフェイスで操作するケースはRustでもあるはずです。 オブジェクト指向言語の設計に慣れていると、Rustで設計するときにどうしたらいいかわからないことがあります。なぜならRustには継承がないからです…。まぁJavaと比べるとだいぶ違うので頭を切り替える必要があります。今回はそういう感じの記事です。 では、早速デザインパターンを題材にして考えてみましょう。 抽象化について 簡単なコマンドパターンから考えます。 ここでは単純に渡した文字列を標準出力するコマンドを考えます。以
CQRS設計パターンをモダナイズする
CQRSとは CQRS（Command Query Responsibility Segregation、コマンド・クエリ責務分離）は、ソフトウェアアーキテクチャパターンの一つで、つまりシステムのコマンド部分をクエリ部分から分離します。基本的な考え方は、データの書き込み操作（コマンド）と読み取り操作（クエリ）を異なるモデルで扱うことです。これにより、スケーラビリティ/パフォーマンス/セキュリティの観点で柔軟な設計が可能となり、クエリ要件に合わせて最適化が実現できます。 CQRSの基本構成としては、 コマンドモデル（書き込みモデル）：データの作成、更新、削除といった書き込み操作を担当します。このモデルは、データの整合性と一貫性を確保するために最適化されています。 クエリモデル（読み取りモデル）：データの読み取り操作を担当します。このモデルは、クエリのパフォーマンスを最大化するために最適化され
オブジェクト指向歴25年のオブジェクト指向おじさんが語るオブジェクト指向設計の処方箋 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事のターゲット この記事は以下の人々を対象としています。 オブジェクト指向を一通りわかっている人。 オブジェクト指向の設計力を高めたい人。 オブジェクト指向を使っているのに、設計が綺麗にならず悩んでいる人。 プログラムが大きくなるとオブジェクト指向設計が破綻する人。 オブジェクト指向に限界を感じている人。 共同開発メンバーの設計力に差があって困っている人。 以下の人は対象外です。 オブジェクト指向が何なのかわからない人。 オブジェクト指向を極めている人。 関数型など別のパラダイムに活路を既に見いだしている人。 オブジェクトは責任ベ
オブジェクト指向プログラミング入門
きしだൠ(K1S) @kis オブジェクト指向について、技術的には「オブジェクト指向は差分プログラミングとデータ分類をまぜて考えてややこしくなる。分離せよ。そして差分プログラミングにはラムダを使え。データ分類のときはオブジェクト指向じゃなく型を考えろ」っていう主張になった。 2022-02-28 12:22:33 きしだൠ(K1S) @kis 「オブジェクト指向は差分プログラミングとデータ分類を同時に行う手法」という見方。 もっといえば、継承の用途を差分プログラミングとデータ分類の2種類にわけた。その上でそれぞれについてのオブジェクト指向離れを考えた。 2022-02-28 12:25:12 きしだൠ(K1S) @kis ここから考えると、オブジェクト指向の技術的欠点は差分プログラミングとデータ分類を不可分に考えてしまったところか。 継承を使うと差分プログラミングとデータ分類が同時にできて
デザインパターン - Refactoring.Guru
デザインパターンは、 ソフトウェアの設計でよく 起きる問題に対する典型的な解決方法です。 パターンの一つ一つは、 自分のコードの設計 の一つ一つは、 自分のコードの設計上の問題に 合わせて調整可能な設計図のようなものです。
オブジェクト指向でなぜつくるのか 第2版 作者:平澤 章発売日: 2014/03/05メディア: Kindle版 目次 目次 背景・目的 参考文献 オブジェクト指向のイメージ 大変な作業を無くせる バグをなるべく混入させないための基礎 クラス中のメソッド数を少なくする メソッド中のステップ数を少なくする クラス中の行数を小さくする ネストを小さくする 変数をむやみやたらに作らない ライブラリ、コンポーネントを使う メモリ使用量とループ回数を考える IOアクセスは最小限にとどめる 同じことを書かない なるべくテスト可能なコードを書く 送り出すデータは厳密に、受け取るデータは寛容に シンプルなインターフェース 複雑な内部状態を定義しない コメントをなるべく書かない コメントアウトしない 良い名前を付ける 背景・目的 良いプログラムを作るには「オブジェクト指向設計をする」とよく言われていますが、
22:22 21/11/20 ボレロ村上(村上原野)さんと constexpr のこと 去る2020年2月、縄文陶芸家にしてC++プログラマという希有な二つの顔を持つ人物がこの世を去りました。 ボレロ村上 (村上原野) 氏です。 正直なところ、陶芸家としての彼の側面については私はほとんど何も知らないに等しいです。 残された作品を見て何かを語れるほど芸術に通じているわけでもありません。 いつか機会があれば見に行こうと思っていた村上さんの作品を目にする最初の機会も、 昨年訪れた追悼展になってしまいました。 ただ、それでも私は、彼自身の登壇発表の資料 であったり、 そして何よりも縄文・陶芸に造詣の深い方々の記された幾つかの文章によって、 彼が一体何を成し遂げたのか、成し遂げようとしていたのかに触れることができています。 この夏にはクラウドファンディングで 作品集 も出版され、誰でも手にとって縄文
２つのオブジェクト指向ーメッセージ・パッシングと抽象データ型 - Hot Heart, Cool Mind.
オブジェクト指向には、もともとアラン・ケイが創案したメッセージ・パッシングのオブジェクト指向と、その後、抽象データ型から発展したオブジェクト指向の２つがあって、その２つは、プログラム言語の機構の面からは共通する要素も多いのだけどプログラミングに対するビジョンという点では相当に異なっている、という見方があります。 これに関しては、id:sumim さんが「二つのオブジェクト指向とそれぞれのメリット」という行き届いた論考を公開しておられて、僕などはそれを読んで頭を整理した口です。 その後、それを踏まえて自分なりに両者の違いを考えてツイートしましたが、言葉足らずな点もあったので、内容を整理するとともに加筆しました。 言語機構に惑わされるな この２つのオブジェクト指向は、実現する機構の面では似ています。オブジェクト指向の３要素として「カプセル化、継承、ポリモフィズム」があると言われますが、そうした
スライド概要 2022.11.2 Women Developers Summit 2022 「プログラミング未経験のエンジニア女子が、アウトプット頑張ったら 設計わかるようになれちゃった話」 --- 「私、エンジニア向いてなかったかも……」 プログラミング未経験で新卒入社。新人研修でいきなりつまづき、業務配属後も当然、分からないことばかり。 実装だけじゃなく設計もできるようになりたいけど、コードが理解できないし、質問すらできない。 本セッションでは、そんな「よわよわ・崖っぷち」エンジニアだった当時入社二年目の私が、『デザインパターン』の学習とその成果のアウトプットを経て、後輩に設計を説明できるようになるまでに取り組んだこと、学んだことについてお話ししたいと思います。
Understanding design patterns in TypeScript and Node.js - LogRocket Blog
Ganesh Mani I'm a full-stack developer, Android application/game developer, and tech enthusiast who loves to work with current technologies in web, mobile, the IoT, machine learning, and data science. Editor’s note: This article was updated 27 September 2022 to include information about state patterns and anti-patterns in TypeScript, as well as to make general revisions to the article. Design patt
最近、よく目にするデータフォーマットに「JSONC」があります。これはJavaScriptでお馴染みのJSON形式にコメントを記述できるよう拡張したものです。Visual Studio Codeでも採用されており、設定ファイルとして利用されることが増えています。そこで、JSONCの記法やJavaScriptから使う方法を確認してみましょう。 JSONCは可読性の高いデータフォーマット JSONCとは 「JSONC(JSON with comments)」とはJSONにJavaScriptスタイルのコメントを記述できるようにしたデータフォーマットです。そのため、基本的にデータフォーマットのJSONなのですが、そこにJavaScript風のコメントである「// コメント」と「/* コメント */」を記述できるようにしたものです。 冒頭で紹介したように、プログラミング用のエディタ「Visual
OOPに対する問題は誇張されている
Young Coderより(M)。 50年経った今でも、私たちはプログラミングの支配的なパラダイムについて混乱しています。 マシュー・マクドナルド 何人かの敵を引き付けなければ、開発世界を何十年も支配することはできません。そして、オブジェクト指向プログラミングは、新旧数十種類の言語の概念的基盤を提供していますが、確かに敵もいます。 そのためか、私たちはOOPについての終わりのない一連のホットテイクに苦しんでいる理由です。彼らはOOPを、生産性を破壊する災厄であるとか、一連のごまかしのプログラミング・パターンであるとか、貧しいプログラマが無能さを隠すために設計された平凡なツールであるとか説明してきました。OOPは死んだとさえ宣言されたことがありました(14年前ですので、割り引いて下さい)。 OOPの4つの柱 これらすべての暴言に共通しているのは、現代のソフトウェア設計の落とし穴のいくつかを(
「“開発者体験”で世界をエンパワメントする1日。」と題し、チームや組織の課題に日々取り組む方々に向けて開催された「Developer eXperience Day CTO/VPoE Conference 2021」。ここで、READYFOR株式会社の仙塲氏が「『Userクラス』で考える技術的負債解消の観点」をテーマに登壇。次にUserクラスの問題と、その解決方法を紹介します。前回の記事はこちらから。 Userクラスが抱える問題 ここでやっとUserクラスが抱える問題。Userクラスを今のモデリング観点と照らし合わせてみると、個人顧客と法人顧客の関心事の異なる問題を、たった1つのUserクラスで取り扱ってしまっています。つまり、複数の問題解決のために、Userクラスが流用されている構造です。特定の問題解決を意図した構造になっていないんです。 このユーザーというのは、個人でも法人でもどうとでも
フロントエンドとオブジェクト指向
フロントエンドの実装にオブジェクト指向をどのように取り入れるかを考えます。 動機 近年のフロントエンドは、Reactなどのフレームワークを使ったコンポーネントベースの設計が主流だと思います。コンポーネントは、HTMLによるマークアップ、CSSによるスタイリング、JavaScriptによる振る舞いがひとまとめにされた、再利用可能な部品です。 コンポーネントの設計を考えていると、次のような疑問が生じます。 何を基準にコンポーネントで分割すればよいか。 コンポーネントの粒度はどれくらいが適切なのか。 どのタイミングで抽象化すれば開発コストが無駄にならないか。 分業した際にコンポーネントの分割や粒度の基準をどのように統一するべきか。 そこで、いろいろ調べたり試したりしたところ、フロントエンドの設計にオブジェクト指向を取り入れることが、これらの答えの一つになるのではないかと考えました。 この記事では
GoFの次に覚えたいデザインパターン ～Specificationパターン～ - RAKUS Developers Blog | ラクス エンジニアブログ
ビジネスアプリケーションとビジネスルール 用語について パターン適用前 Specification パターン Hard Coded Specification Parameterized Specification Composite Specification 条件の再利用性が向上する テスト性が向上する ルールと条件を統一したインターフェースで扱える 動的にルールを構成できる まとめ 関連するデザインパターン Strategy パターン Composite パターン Interpreter パターン 参考文献 補足 ビジネスアプリケーションとビジネスルール 楽楽精算開発部の id:smdr3s です。主に Java を使ったサーバーサイドを担当しています。 弊社のサービスである楽楽精算は、その名のとおり経費精算のサービスです。主に企業にお勤めの方が、業務での移動時ににかかった交通費や業
Google Cloud の IAM で、開発体制や組織の文化に合わせて検討したこと - Hatena Developer Blog
システムプラットフォーム部で SRE をやっている id:nabeop です。システムプラットフォーム部を一言で表すと、基盤を横断的に見る部署という感じです。 過去の発表などでもたびたび言及していますが、はてなのいくつかのサービスは AWS 上で構築されており、これまで「クラウドに構築する」は「AWS で構築する」とほぼ同義な世界でした。 ただし、AWS 以外も全く使っていなかったわけではなく、小さなプロジェクトや個人では Google Cloud の利用もありました。また最近は、各サービスで技術選択の多様化が進み「Google Cloud 上でサービスを構築する」という選択肢も十分ありえる状態になってきました。 このため、各サービスで Google Cloud の利用が本格化する前に、安心して使えるように IAM (Identity and Access Management) など環境
> BTC: bc1qs0sq7agz5j30qnqz9m60xj4tt8th6aazgw7kxr ETH: 0x1D834755b5e889703930AC9b784CB625B3cd833E USDT(Tron): TPrCq8LxGykQ4as3o1oB8V7x1w2YPU2o5n Ton: UQAtBuFWI3H_LpHfEToil4iYemtfmyzlaJpahM3tFSoxomYQ Doge: D7GMQdKhKC9ymbT9PtcetSFTQjyPRRfkwTdismiss OOP: the worst thing that happened to programming [2/24/2025] In this article, we will try to understand why OOP is the worst thing that happened to prog
私は普段、家の脱衣所で仕事をしているのだが、デスクの隣にある縦型洗濯機がちょうどいい高さということもあり、そこにいつも仕事中に参照する本を積んでいる。洗濯機の蓋もまさか、漬物石みたいに本が置かれることになるなんて思ってもみなかっただろう。それらの本は主に、その時々の仕事に関係するものとか、読みかけのものだったりするから、頻繁に入れ替わっていくのだけど、ずっと置いているお気に入りが、いくつかある。そのうちの一つが、OOUI 本こと『オブジェクト指向 UI デザイン 使いやすいソフトウェアの原理』- ソシオメディア株式会社、上野 学、藤井 幸多（著） 上野 学（監修）だ。 出版されてから 3 年以上たっても、私は時折この本をふと、開いてみてはいつの間にか没頭し、そういえば私は仕事をしていたんだっけな、みたいになってしまう。端的に言って大好きだ。この 3 年間で読書会も 2 度主催したことがある
@shin1x1さんの独立したコアレイヤパターンを JS(TS)でも利用できるといいかなと思い、サンプルコードを作成してみた。 独立したコアレイヤパターンとは？ アーキテクチャパターンのひとつ コアレイヤとアプリケーションレイヤの 2 つのレイヤからなる コアレイヤ コアレイヤロジックやビジネスロジックを実装する 外部の IF(WebAPI や DB の orm など)には依存しない アプリケーションレイヤ コアレイヤと外部の IF の連携を実装する 外部の IF(WebAPI や DB の orm など)に依存する スーパーヒーローがいなくても使えるパターン ゴール サンプルとして、記事に対するファボ(お気に入り)を設定・解除する機能のユースケースを作成する。 サンプルリポジトリ ohnaka0410/Vue-Ts-Independent-Core-Layer-Pattern 実装 ベー
Published Jun 13, 2025 Our Research feature uses multiple Claude agents to explore complex topics more effectively. We share the engineering challenges and the lessons we learned from building this system. Claude now has Research capabilities that allow it to search across the web, Google Workspace, and any integrations to accomplish complex tasks. The journey of this multi-agent system from proto
An image of a factory from https://unsplash.com/photos/6xeDIZgoPawはじめにこんにちは, FinatextグループのNowcastでデータエンジニア/データサイエンティストをやっている隅田(@yummydum)と申します. データパイプラインを開発していると, データベースからデータを取り出し, 加工し, 結果を再度データベースに格納するという操作を(時には複雑なSQL等を通じて)行うことがよくあると思います. パイプラインの品質を高めるためにこれらの操作はしっかりテストされるべきです. テストの際にプロダクション環境のデータベースを使う訳にはいかないので, プロダクション環境に似せたテスト用のデータベースにテストデータを格納しておき, これをテストに用いれば良さそうです. しかし, テストデータはうまく管理しないと保守性や可
Lispとオブジェクトシステム
Lispとオブジェクト、オブジェクト指向システムを概観します。
はじめに rust-unofficialというところの出しているRust Design Patternsの日本語訳が見つからなかったため、理解のために翻訳してみました（分からないところは DeepL に頼りました）。 今回は Introduction と Idioms の部分です（デザインパターン・アンチパターン編の翻訳はこちらにあります）。 FFI の部分はよく分からなかったためスキップしています。 不慣れなため翻訳間違いなどある可能性が高いです（教えていただきたいです）。 以下から本文です。 Introduction デザインパターン プログラムを開発するとき、私たちは多くの問題を解決しなければなりません。プログラムは問題の解決方法と見ることができます。また、プログラムは多くの異なった問題の解決方法の集まりと見ることもできます。これらの解決方法の全てが一緒に大きな問題の解決へと働きかけ
2024年3月24日(日)「 Object-Oriented Conference 2024 」に開催された、弁護士ドットコム サーバサイドエンジニアの貞森友章が登壇した際の資料です。 イベントURL：https://fortee.jp/oocon-2024/proposal/aac7a433-4…
今回はアプリケーションアーキテクチャを学ぶ最初の一歩として、「MVC」や「3 層アーキテクチャ」などの基本的な用語の意味や関係性を整理する「改めて整理するアプリケーション設計の基本」。ここで大嶋氏が登壇。最後に、本来のアクティブレコードの設計パターンと役割について整理します。前回はこちらから。 アクティブレコード系のO/Rマッパーを使用している場合のステップアップ方法大嶋勇樹氏：次に「Controllerに全部書く」からのステップアップの例2を出していこうと思います。 （スライドを示して）今度はRuby on RailsやLaravelといった、アクティブレコード系のO/Rマッパーを使う例を考えてみようと思います。よくある苦しくなりやすい構成はこうなっています。 最近はやはりRailsやLaravelを使って開発している例も多いし、入門で勉強する方も多いのですが、このRails、Larav
オブジェクト指向とは何か、という問いについて - Hot Heart, Cool Mind.
４月も半ばを過ぎて、新入社員がプログラミング研修を受ける季節になったからだろうと思うが、オブジェクト指向談義が再燃している。ほとんど年中行事だ。 今年は、オブジェクト指向という用語をアラン・ケイの言った意味で使うのは「特権的」だという主張まで出たりした。 ギブソンが考えた「アフォーダンス」は、使い手と道具の関係性に関する概念だが、ノーマンはそれを「誤用」し、道具のデザインがもつ特性の話にした。現在では後者の方が広く受け入れられているように思うが、だからといって、アフォーダンスという用語はノーマンの意味で理解すべきだ、という話になるだろうか。 よくいって、アフォーダンスというひとつの言葉に対して２つの意味内容が「事実上」存在するということだ。そして、「本来の」アフォーダンスは、と言えば、ギブソンのそれを指すに決まっているではないか。 それは、特権云々の問題ではなく、アフォーダンスと言う言葉を
Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...
本当のオブジェクト指向の話をしよう - Qiita
この記事はC#アドベントカレンダー5日目の記事です。 2時間くらい間に合いませんでした はじめに 今年もアドカレの季節がやってきましたので、今年もさっそく記事を書いていきます。 ずっといつか書こうと思っていた、「オブジェクト指向って何？」に対する自分なりの答えです。 多分かなり長くなる気がするので、気長に読んでいただけると幸いです。 オブジェクト指向って何？ よくある説明 さっそくですが、「オブジェクト指向」とは何か。ひとまず既存の説明を検索してみましょう。 「ある役割を持ったモノ」ごとにクラス（プログラム全体の設計図）を分割し、モノとモノとの関係性を定義していくことでシステムを作り上げようとするシステム構成の考え方のこと。 オブジェクト指向とは、コンピュータプログラムの設計や実装についての考え方の一つで、互いに密接に関連するデータと手続き（処理手順）を「オブジェクト」（object）と呼
この記事は移転しました。約2秒後に新記事へ移動します。移動しない場合はココをクリックしてください。
【C#】インターフェイスの利点が理解できない人は「インターフェイスには３つのタイプがある」ことを理解しよう - Qiita
##はじめに C#を始めとするオブジェクト指向言語には「インターフェイス」という機能があります。 これを使うと良い設計になるというのはよく言われていますが、具体的にインターフェイスを使うとどう良いことがあるのか、というのは実感しづらい人も多いと思います。 僕もC#学びたての頃はほんとうにインターフェイスの利点が理解できず苦しみました。しかし、この記事で説明する「インターフェイスには３つのタイプがある」ことを理解して以来、もうインターフェイスが便利すぎて、インターフェイスなしではコーディングできない体質になってしまいました。 そこでこの記事では、インターフェイスを使う利点がいまいち理解できていない人が、インターフェイスを使いたくて使いたくて仕方がなくなるようにすることを目的として書きました。 注意点として、僕はC#の開発者でもなければ指導者でもないので、あくまで個人的な意見として参考にしてい
Metaに学ぶ、大規模開発のデータフェッチ設計と最適化
本稿で扱うデータフェッチは高速なサーバー間通信を前提にしているため、バックエンドは細粒度なREST APIで設計することが最適だと考えます。 データフェッチの設計パターン 筆者の考えでは、データフェッチの設計は大きく2パターンに分けられます。データフェッチ層を設けるなどするような中央集権型の設計と、データフェッチコロケーションに代表される自律分散型の設計です。 中央集権型: 責務を集約し、一元管理を重視する 自律分散型: 責務を末端に分散し、自律性を重視する MetaやReactにおける自律分散型の設計の歴史については、筆者の前回の記事で詳細に解説しています。興味のある方はご参照ください。 解説 冒頭で触れたように、Metaでは自律分散型の設計が重視されており、特に大規模開発の保守性において重要だと考えられています。データフェッチ層を設けるような中央集権型の設計はなぜ好まれないのでしょう？
クソコード動画『カプセル化 Mk-II』 で考える 上手くカプセル化できない理由 / encapsulation2
オブジェクト指向カンファレンス2024 クソコード動画『カプセル化 Mk-II』 https://twitter.com/MinoDriven/status/1771763728234537310 下記セッションで用いたスライドです https://fortee.jp/oocon-202…
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
JavaScriptデザインパターン入門 - Qiita
流行りのBFFアーキテクチャとは？｜Offers Tech Blog
CQRSはなぜEvent Sourcingになってしまうのか - かとじゅんの技術日誌
これだけは知っておきたいクラス設計の基礎知識 version 2
オブジェクト指向プログラミングについて学んだ事のメモ - EurekaMoments
ボレロ村上(村上原野)さんと constexpr のこと - d.y.d.
プログラミング未経験のエンジニア女子が、アウトプット頑張ったら 設計わかるようになれちゃった話 | ドクセル
ゼロからはじめるJavaScript(18) 可読性と表現力の高いデータ形式「JSONC」を活用しよう
モデリングの仕方がUserクラスの負債化をまねく 分割設計で爆死しないための2つの考え方
OOP: the worst thing that happened to programming
『オブジェクト指向 UI デザイン』 に書かれていないもの｜ai
独立したコアレイヤパターンをJavaScript(TypeScript)で実装してみる
How we built our multi-agent research system
Factory patternでデータベースのテストを効率化する
『Rust Design Patterns』を翻訳してみました（Idiom 編） - Qiita
実務への応用例から考える 変更に強いオブジェクト指向設計
重要なのは「基本を押さえ、適したものを採用すること」 “本来の役割”を押さえたアプリケーション設計 | ログミーBusiness
Java Persistenceを使ったアーキテクチュア：パターンと戦略
非オブジェクト指向言語Juliaで書くオブジェクト指向 - SE教育パパむううみんのブログ