設計の考え方とやり方
#asken_dev「設計の考え方とやり方」勉強会 https://asken.connpass.com/event/254709/ ・良い設計は悪い設計より変更が楽で安全である ・ドメインモデル方式のクラス設計 ・イミュータブル方式のテーブル設計 ・設計スキルの身につけかた ・設計の…
Use Singleton Pattern Or Not?
In this article, I will go through the cons and pros of the singleton pattern, and in much more detail, I will answer the question above. Where are Singletons Supposed To Be Used?Let’s start with a definition of this pattern by referring to refactoring.Guru. Singleton is a creational design pattern that lets you ensure that a class has only one instance while providing a global access point to thi
Design Patterns 15 Years Later: An Interview with Erich Gamma, Richard Helm, and Ralph Johnson | Design Patterns 15 Years Later: An Interview with Erich Gamma, Richard Helm, and Ralph Johnson | InformIT
Erich Gamma, Richard Helm, and Ralph Johnson talk to Larry O'Brien about Design Patterns, 15 years later. Larry O'Brien: 85,000 apps for the iPhone have been developed and deployed in the past year-and-change. One can write a globally-accessible "Hello, World! The time is X" Web page in just one line of PHP, for instance. "Designing object-oriented software is hard," are the first words of Design
良いコードとは何か - エンジニア新卒研修 スライド公開｜CyberZ Developer
CyberZ CTO室のメンバーの森 (@at_sushi_at) です。 先日、株式会社サイバーエージェントの2021年度 エンジニア新卒研修でコードの品質に関する講義を行いました。 そこで話した内容とスライドを完全公開します。 45分の内容のため、かなり長いですが、個人的にぜひ一読して欲しい内容になっています。 はじめに こんにちは、森 篤史と言います。2019年度入社で今年で3年目になります。株式会社CyberZのOPENREC.tvというプロダクトでAndroidアプリチームのリーダをやっています。 最近はプログラムを書く仕事以外に、次世代マネジメント室という全社横断組織でDevelopers Blogの改善プロジェクトを実行したり、CyberZ CTO室で組織活性化に取り組んでいます。 あと、2019年度の未踏スーパークリエータにも認定されました。 メインの仕事としては、入社して
UE4 ネットワークマルチプレイヤーゲームを作る時の役割について - Let's Enjoy Unreal Engine
ここ最近はUE4でネットワークを使ったマルチプレイヤーゲームを作る機会が多くなってきました。UE4はエンジン自体が最初からネットワークマルチプレイヤーを幅広くサポートしています。しかし、実際に制作を行うためにはエンジン独特のノウハウが必要で、これらを解説している情報というのは少ないというのが現状です。 そこで今回はUE4でネットワークマルチプレイヤーゲームを作るための設計やクラスごとの役割についてを解説したいと思います。UE4のネットワーク周りについてのドキュメントは以下のページにありますのでこちらも参考にしてください。 docs.unrealengine.com またUE4でネットワークを扱う際に非常に重要な部分となる所有権とRPCについて、ヒストリアさんのブログ記事が非常に参考になるので、こちらもどうぞ。 historia.co.jp 今回の記事はListenサーバー、Dedicate
Smart UI パターンが再評価される世界 - id:onk のはてなブログ
設計ナイト2020 を受けて、今どんなアーキテクチャを選ぶべきかという話をしたくなったのだ。 kichijojipm.connpass.com 設計ナイトで高ぶった結果1時間コースの発表資料が完成したので供養場所を探しています。聞いてくれ！！！— Takafumi ONAKA (@onk) 2020年11月1日 お前誰よ 2000年代前半に SI 2000年代後半にブログ、SNS 2010年代にソーシャルゲーム 2020年代に UGC サービス をやってきた人間。数百万〜数億行のデータ、月間数千万〜数十億 imp 程度を主戦場にしています。 今日の話 DDD と PofEAA から学ぶパターン/アンチパターン Rails によって発見された、密結合で速く走れるソフトウェア 今求められているアーキテクチャ 昂ぶって 15,000 字ぐらい書いてしまった。 DDD と PofEAA から学ぶパ
Rustに影響を与えた言語たち - Qiita
各カラムの意味は次のとおりです。言語の特徴は主にWikipediaを参考にしていますが、正確な分類は困難なため多少の独断と偏見が含まれていることをご了承ください。 登場年代 プログラミング言語が登場した年代です。前後3年の誤差は見逃してください FP(関数型プログラミング) 言語がFPを強くサポートしているかを示しています 程々にサポートしている場合は△を示しています OOP（オブジェクト指向プログラミング） 言語がOOPを強くサポートしているかを示しています 並行計算 アクターや CSP/π計算モデルの特徴を言語が強くサポートしているかを示しています 外部ライブラリを使えばできるよ！みたいなものは除外します 静的型付け 言語の最も主要な処理系が静的型付けをサポートしているかを示しています パラメータ多相 言語がパラメータ多相をサポートしているかを示しています ジェネリクス(Java)、テ
クリーンアーキテクチャのUsecaseはなぜControllerへ値を返すのではなくOutput PortとしてPresenterを呼び出すのか - Runner in the High
何を言っているのかと言うと、みんな大好きクリーンアーキテクチャの右下に図示されているFlow of Controlのこと。 黒線が引かれているということは、つまりUsecaseの中でOutput Portのインターフェイスを持つPresenterの関数なりが最終的に実行されるということである。 ここで湧き上がってくる疑念は「UsecaseがPresenterを呼び出さなくてもControllerに返り値とかで値を返して、Controller経由でPresenterに渡して実行しても同じなんじゃないの？」である。つまりOutput Portというインターフェイスそのものを撤廃してControllerにPresenterを使わせるアイデアである。たしかに、仮にこの方針で行ったとしても依存の方向が壊されることはない。 Software Engineeringでは同様の質問がかなり盛り上がっている
「割れ窓」を増やさないためのコード設計 / design not to broke additional window
PHPカンファレンス沖縄 2019で話したレガシーコード改善手法の一つについてです
Worse Is Better
Worse Is Better（悪いほうが良い） Richard P. Gabriel (Original article: Worse Is Better. Japanese translation by Hisashi Morita.) "worse is better"として知られる考え方では、ソフトウェアを作る際には（おそらく他の分野でも同様に）最小限のものをまず作り、そして必要に応じて育てるほうがよいとされる。Christopher Alexander*なら"piecemeal growth"（一口分ずつの成長）と呼んだかもしれない。その考えがどのように進化したかを話そう。 1984から1994まで、私は"Lucid, Inc."というLispを生業とする会社を所有していた。1989の時点で、Lispビジネスが好調ではないことは明らかだった。ひとつにはAIを生業とする会社が泥沼に
デザインの「悪い方がよい」原則 The Rise of "Worse is Better"
デザインの「悪い方がよい」原則 The Rise of "Worse is Better" rpg@lucid.com 日本語訳: daiti-m@is.aist-nara.ac.jp 私や Common Lisp と CLOS のデザイナーのほとんどは、MIT/Stanford 方式の設計に親しんでいる。 この方式の核心は、「正しい」やり方をせよ、という ことにつきる。デザイナーにとっては、以下の点をすべて正しく満たすことが 重要である。 簡潔性 デザインは実装と使用法の両面において単純でなければならない。 このとき、使用法が単純な方が、実装が単純なことより重要である。 正当性 デザインはすべての点において正しいものでなければならない。 誤りは許されない。 一貫性 デザインは一貫性を欠いたものであってはならない。一貫性を保つ ためには完全性は少しだけ犠牲にしてもよい。一貫性は 正当性と同
別視点から理解するクリーンアーキテクチャと適用限界 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 概要 クリーンアーキテクチャを勉強した際， 「これって実際に自分がプロダクトを作るときにはどう設計するの？」 という疑問が浮かびました． 本に載っている内容を追うことはできる．しかし，その本から外れたような概念を扱うようになると，途端に右往左往してしまうことがありました． 特にクラスの依存関係への言及は多いのですが，実際の処理フローまでは書かれていません．そのため，クラスはかけるのですが，一通りの処理が書けないとなりました．．ある程度のフローが想像できないため，クラスや関数の機能の責任範囲が分からない．実装できない．といったことに私は陥
「設計なんて不要でしょ」について - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 経緯 以前とある席で偶然シニアエンジニアの方と設計について議論することがありました。 その時に特に耳に残っていたのは以下の様な内容です。 クリーンアーキテクチャってテストしやすくする為のですよね？ 設計はコード書ける人が他のコードを書ける人に威張るための道具なのではないか？ 設計を学習するならブロックチェーンとかを勉強して技術力を高めるべきなのではないか？ リーダブルコードさえ読んでいれば設計は必要ないのではないか？ 設計なんて不要でしょ その方はかなり詳しく設計の歴史をしっていて尤もな事を言っていましたが、平成も終わる頃においてはその
モードレスはどこから来たか – オブジェクト指向UIの起源 – | Backdrop
いや、「モードレスはどこから来たか」ではなく、本来の疑問は「モードはどこから来たか」なのだ。なぜなら自然界にモードはないから。 モードは何もないところに生まれる形だ。混沌に生じた秩序だ。例えばファッションがそう。一般的にモードという言葉は、新しい流行や様式を指す。そして文化的な多様性と進化を促す力として肯定的に受け取られている。つまりモードはデザイン性の証なのだ。 しかしユーザーインターフェースデザインの分野、特にコンピュータソフトウェアの操作性に関するテーマにおいては、モードはほとんどすべてのシステムが宿している原罪として、解決すべき問題として扱われる。 なぜ原罪なのかと言えば、コンピュータというものの発想自体の中に、用途によって役割を変える道具 ＝ 無数のモードを持つ多目的な存在としての性質が込められているからだ。そしてコンピュータは、その宿命であるモードによって、生得的に使いにくいと
Designing Fluid Interfaces - WWDC18 - Videos - Apple Developer
Discover the techniques used to create the fluid gestural interface of iPhone X. Learn how to design with gestures and motion that feel intuitive and natural, making your app a delight to use. Resources Explore the Human Interface Guidelines Positioning content relative to the safe area UIView HD Video SD Video Presentation Slides (PDF) Hey, guys. Thank you. Thanks for coming by, guys. Welcome to
書籍「Clean Architecture 達人に学ぶソフトウェアの構造と設計」を読んだので大事なポイントを自分のためにまとめてみた - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに Clean Architecture 達人に学ぶソフトウェアの構造と設計を読んだ。 なぜソースコードを綺麗に書くのかから始まり、オブジェクト指向、コンポーネントの原則、アーキテクチャと体系的にまとまっている良い内容だった。 この記事では、本書の内容の引用を踏まえながら自分の考えの振り返りをまとめたものである。 実際にGoで実装したりしたので、なにか間違いなどあれば指摘していただきたい。 クリーンアーキテクチャの書籍を読んだのでAPIサーバを実装してみた 対象読者 ・Clean Architecture 達人に学ぶソフトウェアの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Smalltalk: Conceptual Integrity in Action.
文脈と名前で設計をマスターする本
モーヲタでつか… : にぽたん研究所
オブジェクト指向とは何ですか？
