最速攻略！ Reactの `use` RFC
皆さんこんにちは。最近のReact界隈で話題になっているのは次のRFCです。 そこで、この記事ではさっそくRFCを理解することを目指します。 ただし、このRFCはSuspenseに深く関わるものです。SuspenseはReact 18でもう正式リリースされていますから、この記事ではSuspenseは前提知識とします。もしまだSuspenseをよく知らないのであれば、ぜひ次の記事で学習してください。 また、RFCはあくまでReactの新機能のアイデアを公開するものであり、これが必ず実装されるとは限らない点にご注意ください。例えば、過去にはuseEventというRFCが注目を集めていましたが、意見が集まった結果としてそのRFCは実装されずにクローズされました（RFCが無駄だったというわけではなく、再度検討してよりアイデアがブラッシュアップされることになります）。 新しい use API このR
Ruby 2.7 adds shorthand syntax for arguments forwarding
Ruby 2.7 added a new shorthand syntax ... for forwarding arguments to a method. Need for a new operator Currently we do have * and ** operators for single and keyword arguments. These are used to specify any number of arguments or convert array or hashes to several arguments. The ... operator The idea of ... operator is to capture all and forward arguments irrespective of type. So we can forward s
dev.toのServiceクラスについてDDDとPofEAAを読んで考察してみた
RailsにおけるServiceクラスに関する設計的な話は、プロジェクトの性質や開発チームの状況によって色々な意見があり、これといった解りやすい結論が出ていない状況だと思っています。 この状況において、ある程度の規模のOSSのServiceクラスの活用事例を取り上げて、考察することは意義がありそうだと思いました。 また、ServiceクラスのアイデアはRailsやWeb開発に関わらず、幅広い分野のソフトウェア開発で適用できるものなので、そういった意味でも価値がありそうだと思い、記事にしてみました。 対象とするOSSプロジェクトは、爆速技術記事サービスで有名な dev.to です。 まず、dev.toにおけるServiceクラスの活用方法を見た後で、ソフトウェア設計に関する名著である、Patterns of Enterprise Application Architecture と Doma
Patterns of Enterprise Application Architecture - Martin Fowler's Bliki (ja)
Martin Fowler氏とAddison-Wesley Pub Coの許可を得て、パターンカタログの翻訳を行っています。 ※書籍の邦訳とは一切関係ありません。 PofEAAのパターンカタログから読始めるとよいでしょう。 パターンカタログの日本語版 パターンカタログの英日対応表 上記のカタログでは書籍の訳語を踏襲していますが、各ページでは「できるだけ正しい」訳語を使うようにしています。邦訳版のパターン名に関する議論などは、JapanesePatternNamesを参照。 ページ一覧 アクティブレコード アプリケーションコントローラ 関連テーブルマッピング BBS パターンカタログ パターンカタログの比較表 パターンカタログ（日本語） クラステーブル継承 クライアントセッションステート 粗粒度ロック 具象テーブル継承 データマッパー データ転送オブジェクト データベースセッションステート
ServiceとDCIについて - かとじゅんの技術日誌
面白そうなネタがあったので、自分なりの考えをまとめてみる。 Ruby/Rails 用 DI コンテナ Dee をつくった、あるいは Ruby のカルチャーについて この記事はRuby用のDIコンテナの話題なんですが、DCIについても言及されているようです。比較軸はDIそのものというより、サービスとDCIだと思うので、それについてダラダラといくつか考えをまとめてみます。多分返事になるようでならないかも。それと宗教上の都合でDDDの視点から書きます...。 サービスという言葉はあいまい まず、簡単に前提の整理から。単に"サービス"って言葉が何を指すのか結構曖昧です。 サービスは簡単にいうと手続きとか振る舞いのことですが、細かくいうと、PofEAAでいうサービスと、DDDいうサービスは、目的が異なります。前者はアプリケーションのためにドメインモデルを再利用可能にするためのものです。後者はドメイン
混乱しがちなサービスという概念について - かとじゅんの技術日誌
社内でサービスがよくわからないという話になったので、考察を少しまとめておきます。 過去のエントリでも以下のように触れましたが、もう少しかみ砕いてみよう。 サービスという言葉はあいまい まず、簡単に前提の整理から。単に"サービス"って言葉が何を指すのか結構曖昧です。 サービスは簡単にいうと手続きとか振る舞いのことですが、細かくいうと、PofEAAでいうサービスと、DDDいうサービスは、目的が異なります。前者はアプリケーションのためにドメインモデルを再利用可能にするためのものです。後者はドメインの知識を表している振る舞いです。これはのちほど詳しく説明します。 まぁこのあたりは具体例がないと理解しがたいですが、レイヤーの違いによって責務が異なるという感じです。DDDのサービスの章では、サービスには、アプリケーション層、ドメイン層、インフラストラクチャ層と、複数のレイヤーに存在すると言及されていま
Rails：Service層を運用して良かったところ、悪かったところ - Qiita
1年前くらいにRailsの設計にDDD(ドメイン駆動設計)のService層を導入し、Modelの肥大化対策をしました。 この記事では、まずどのようなルールでService層が組み込まれているかと、1年間運用してみて良かったところ、悪かったところの感想を書きます。 [2018/05追記] 最近ではサービス層の導入は賛否両論あるようなので、導入する際は自分のプロジェクトに合っているかどうかを十分にご検討ください！ Service層を導入するきっかけになった問題点 Modelの肥大化 Model間の複雑な依存関係 多数のミドルウェアの導入による複雑さの倍増 これらにより.. メンテナンスやテストがしにくい コードが整理されていないのでとにかく読みづらい Model複雑化の例 <ユーザがECサイトの商品をお気に入り(like)にするメソッドを書く場合> 処理に関連するテーブル my_itemsテ
JavaやC#の常識が通用しないRubyのprivateメソッド - give IT a try
衝撃を受けたできごと 最近Rubyを勉強しています。 JavaやC#でオブジェクト指向プログラミングの基本はマスターしてるから、Rubyもそのあたりは楽勝〜！・・・と思っていたら、JavaやC#の常識が全く通用しない振る舞いに遭遇してかなり衝撃を受けました。それは、 privateメソッドはサブクラスからも呼び出せる ・・・ということです！！がーん。 たとえば、JavaやC#だと自分のクラス内でprivateメソッドが使われていない場合、不要なメソッドとして削除できます。(リフレクションを使って呼び出される可能性はここでは無視ね) しかし、Rubyでは誰かがサブクラスを作って呼び出している可能性があるので、privateメソッドを削除する場合は注意が必要です。メソッド名を変更する場合も同様ですね。 また、知らずに親クラスと同名のprivateメソッドを定義すると、予期せず親クラスの実装をオ
オブジェクト指向の呪いと、その避け方 - mizchi's blog
このテーマで書く前に、まず、最初に自分に多少の偏りがあることを認めておかなくてはなりません。 オブジェクト指向より、関数指向寄り オブジェクト指向のアプローチは有用だが、ただしそれを実現する手段はクラスと継承ではない。 階層化されたツリー構造(GUI/リレーショナルな参照構造)に埋め込まれる状態はコード品質を悪化させるので、できるだけ出現するべきではない。 ただし、状態は確実に存在する。だからこそ慎重に扱うべきだ、という派閥です アンチパターン: 特に理由もないクラスメソッドへの所属 何かのバリデータを実装したいとします。 その関数がどこに所属するかについて、よく見るこれらの実装は全部アンチパターンといっていいと思います export class Validator { static validate() {...} } export class Validator { validate(
継承は禁止するべき
キチガイに刃物、ゴミプログラマに継承。危険なものは取り上げるべきだ。 オブジェクト指向プログラミングにおける継承は強力な手法であるが、これを正しく使えるプログラマは残念なことに極めて少ない。たいていの場合、継承を使うことで却ってプログラムの保守を困難にしてしまう。継承のアンチパターンの最たるものは、単なるメソッドやメンバ変数の共有のために継承を使うパターンだ。これを行うとデータが密結合になってバグの原因になり、プログラムを把握することも極めて困難になる。 そもそも、熟達したプログラマの感覚では、業務で書くアプリケーションの実装に継承を使うべき局面などほとんど無い。ライブラリ等のより低レベルな処理で仕様が確定しているものについては、継承が効果的となる場合もあるが、複雑なアプリケーションのロジックに継承を使うのはほとんどの場合、時期尚早な抽象化となる。 また、凡庸なプログラマが継承で実現したい
リスコフの置換原則 - Wikipedia
この記事には複数の問題があります。改善やノートページでの議論にご協力ください。 出典がまったく示されていないか不十分です。内容に関する文献や情報源が必要です。（2021年12月） 脚注による出典や参考文献の参照が不十分です。脚注を追加してください。（2021年12月） ほとんどまたは完全に一つの出典に頼っています。（2021年12月） 独自研究が含まれているおそれがあります。（2021年12月） 出典検索?: "リスコフの置換原則" – ニュース · 書籍 · スカラー · CiNii · J-STAGE · NDL · dlib.jp · ジャパンサーチ · TWL リスコフの置換原則の概念は、バーバラ・リスコフにより初めて導入された。2010年に撮影された写真。 リスコフの置換原則（りすこふのちかんげんそく、英: Liskov substitution principle）は、オブジェ
Rails のサービスクラスでのマイルールとちょっとしたコツ - Qiita
動機 Railsにおけるサービスクラスのオリジナルルール という記事をたまたま見つけ、「自分ならこう書くかな」と感じたことがいくつかあったので、記事にしてみました。 なお の参考記事の中でさらに参考にされている 肥大化したActiveRecordモデルをリファクタリングする7つの方法(翻訳) という記事のコードを、この記事でも説明のために用いようと思います。そこで、以下は 2 つの記事をこのように呼称します。 参考記事 1: Railsにおけるサービスクラスのオリジナルルール 参考記事 2: 肥大化したActiveRecordモデルをリファクタリングする7つの方法(翻訳) さらに翻訳元の記事: 7 Patterns to Refactor Fat ActiveRecord Models ルール 1. クラス名は「動詞 (+ 目的語)」にする 参考記事 1 のものとほぼ同じルールです。末尾に
Railsで重要なパターンpart 1: Service Object（翻訳）
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Essential RubyOnRails patterns — part 1: Service Objects 公開日: 2017/06/13 著者: Błażej Kosmowski サイト: selleo.com パターンの種別は原則として英語表記にしました。 2017/10/16: 初版公開 2022/03/17: 更新 Service Object（単にServiceと呼ばれることもあります）は、肥大化したActiveRecordモデルを分割し↓、コントローラをスリムかつ読みやすくするうえで非常に有用な、Ruby on Rails開発における一種の聖杯とも呼ぶべきパターンです。 肥大化したActiveRecordモデルをリファクタリングする7つの方法（翻訳） どんなときにService Objectを使うか このパターン
闇の住人*猟奇殺人者たちの宴*
ここは闇に隠れし者たちが集う宴の場所。 さぁ 日常という名の衣を脱ぎ捨てましょう... 貴方は番目の犠牲者です up 2010.3.18 お勧め！↓↓ *MENU*
2ちゃんねるの開設当初の裏話をひろゆきが発言
rei@サブアカウント @Shanice79540635 2chのシステムは実はひろゆき氏が作ったものではなく「あめぞう掲示板」の全コピーであり、尚且つあめぞうは全盛期は（カウンタが正確なら）日本1のアクセス数を達成していた…という事実はインターネット古参勢もあまり知っていないんだよな twitter.com/iikagenni_siro… 小山（凍） @iikagenni_siro_ ゼロ年代初頭のITバブル期に日本で最大級アクセスが集まるサイトでありながら、金融機関からの融資もIPOも経ずひたすら個人サイトの延長で運営し続け、最終的にオワコンになった2chって日本の起業風土がゴミカスであることの象徴みたいな事例だと思うんですよね。ひろゆきの無能だけが理由ではない。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - forem/forem: For empowering community 🌱
Overriding private superclass methods in Ruby
GitHub - discourse/discourse: A platform for community discussion. Free, open, simple.
GitHub - mastodon/mastodon: Your self-hosted, globally interconnected microblogging community
RandomA11y - Endless collection of accessible color combos