トップレベルドメイン - Wikipedia
トップレベルドメイン（TLD : top-level domain）は、インターネットの階層型Domain Name Systemの最上位レベルのドメイン名である[10]。トップレベルドメインは名前空間のDNSルートゾーンにインストールされる。これより下位のレベルの全てのドメインでは、トップレベルドメインはドメイン名の最後の部分、すなわち、つまり完全修飾ドメイン名の最後の部分である。例えば、ドメイン名www.example.comでは、トップレベルドメインはcomである。ほとんどのトップレベルドメインの管理に対する責任は、Internet Assigned Numbers Authority(IANA)を運営するInternet Corporation for Assigned Names and Numbers(ICANN)によって特定の組織に委任されており、DNSルートゾーンの維持を担
「CQRSをやる」は「Event Sourcingをやる」とほぼ同義 リアクティブシステムとCQRSを反映した新アーキテクチャの設計思想
Chatwork に所属するエンジニアや外部ゲストなど、多分野のエキスパートたちの登壇を通して、エンジニア組織で取り組んでいる試みなどの知見を提供する「Chatwork Dev Day 」。ここで開発部テックリードの加藤氏が登壇。続いて、Event Sourcingと、新アーキテクチャの具体的な設計内容を紹介します。前回の記事はこちらから。 なぜEvent Sourcingなのか 加藤潤一氏（以下、加藤）：「なぜEvent Sourcingなのか」という話で、Event Sourcingの場合はどうなっているかというと、CRUDのステートソーシングは、最新のエンティティを上書きする考え方です。Event Sourcingは、そのとき発生した変更を追記していく考え方になります。 「状態はどういうふうに作るの？」という話ですが、イベントから状態を導出する考え方です。関数にイベントをapplyし
新卒にも伝わるドメイン駆動設計のアーキテクチャ説明[DDD] - little hands' lab
ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か ドメイン駆動 + オニオンアーキテクチャ概略 以前こちらの記事でアプリケーションアーキテクチャについて書きました。 こちらの記事では比較的ネタ元に忠実な解説をしたのですが、実際これに基づいて人にレイヤの説明をした際、依存性の逆転部分や円形で表現する部分がなかなか伝わりにくいことがありました。 そんな中で、所属プロダクトで新卒含めて大規模なリニューアル案件でDDDを採用することになり、新卒にも伝わるように説明をする必要性が生じました。 結果、新卒にも伝わり、運用が割と回る説明が見つかったのでご紹介したいと思います。 アプリケーションアーキテクチャ全体図 とにかく、何か説明する際はこの図を常に傍に置き、一方通行の依存性を徹底したい、という話をしています。 何かについて議論をする際は、 「それはどの層の責務なの？」 という
![新卒にも伝わるドメイン駆動設計のアーキテクチャ説明[DDD] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/da075520c5346bf5227bf90557a35ccf8b5b07ae/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fl%2Flittle_hands%2F20181210%2F20181210195849.png)
設計/コードレビューで"常に"心がけるポイント - little hands' lab
株式会社ログラスの松岡(@little_hand_s)です。 little-hands.hatenablog.com ↑の記事でドメインオブジェクトの設計方針を書きましたが、それ以外の全般的な設計/レビュー観点について書きます。 非常に汎用性のある内容なので、数多くのプログラミング原則を覚えるより、まずこの観点でチェックできるようにすると即効性が期待できます。 前提として、階層化されたアーキテクチャ(オニオンアーキテクチャなど)を採用しているものとします。 ①レイヤーの責務違反の実装をしていないか ②高凝集/低結合になっているか 高凝集 クラスに関して メソッドに関して 低結合 ③ユニットテストを書きやすいか 合言葉 筆者執筆書籍 現場での導入で困ったら ①レイヤーの責務違反の実装をしていないか 例として、「ユースケース層にドメイン層のルール/制約に関わる実装をしている」場合はNGです。
Rails のメールアドレスバリデーション - 暇人じゃない
いくつかの Rails プロジェクトのメールアドレスのバリデートは、正規表現ではなく mail gem と treetop gem を組み合わせて 行なっている。 Mail::Address.new(address) でアドレスをパースできる パース結果にドメイン部分が存在し、パース結果のアドレスが同一である Treetop で解析したドメイン部分のエレメントが example.com のように 2 つ以上 しかし、mail gem のバージョン 2.6.0 から treetop gem が依存関係から削除されたため、ドメイン部分のエレメントの検証が出来なくなった。 そこで、以下のように処理を変更した。 require 'mail' require 'resolv' class EmailValidator < ActiveModel::EachValidator def validate
DNSとかネームサーバとかRoute53とかAレコードとかCNAMEとかがわからない人のためのまとめ - ふじいけ技術メモ
表題の通り。 いくら調べてもわかるようにまとめてる人がいなくてさすがにムカついたのでまとめた。 この記事の対象読者 「ドメインの設定わかりづらすぎるよお死ぬう」 「DNSサーバとかネームサーバってなんなのマジで・・・」 「AレコードとかCNAMEとかよくわからないしよくわからない理由で設定が拒否された」 「よくわかってないのに動いちゃったしヤバイ気がしてるしこわい」 「Route53に移管っていう単語が死ぬほど出てくるけどそもそもなんなのこれ」 webサーバを公開してから、取得したドメインでそのサーバにアクセスできるようにするまでの流れ さて、まずは全体の大まかな流れを見てみよう。 webサーバでwebサイトを公開する webサーバのIPアドレスを確認する ドメインを取得する ドメインを取得したサービスで、使用するDNSサーバ(ネームサーバ)を設定する DNSサーバでドメインとIPアドレス
自社のメールドメインの代わりにZendeskからメールを送信する方法
自社のメールサーバーに代わってZendeskにメールを送信させる設定は必須ですか？いいえ、 必須ではありません。 この設定を行う必要があるのは、エンドユーザー宛のメッセージにZendeskの社名を表示したくない場合だけです。 Zendeskが外部メールアドレスを使用してメールを送信する場合（サポートアドレスの転送設定を行った場合）、相手先で受信拒否されないように、メールの送信元はzendesk.comとみなされます。ただし、会社のメールドメインの代わりにZendeskがメールを送信できるように設定した場合、Zendeskはzendesk.comからメールを送信せずに会社のドメインから送信することで、ブランドの設定を完全に保持します。 この記事で説明されているタスクを実行しないと、エンドユーザーに次のような画面が表示されることがあります。 次の警告は、外部サポートアドレスの横にあるエージェン
モデル駆動開発(DSL (Domain Specific Language))
概要 まずはじめに、｢モデル化って何？」って話から。 モデル化とは モデル化とは、 現実の問題から、問題解決に必要な部分だけを抜き出して簡単化・抽象化することです。 例えば、物理学なんかでは、物体の運動を考える場合に、 質点（体積 0 の動く点）というものを考えます。 物体の回転や空気抵抗などを無視して考える（逆に言うと無視しても十分な精度が得られる）場合、 物体の体積を考える必要はないので、 体積は無視してしまおうということです。 これが物事の簡単化・抽象化、すなわちモデル化です。 もし物体の回転も考慮する必要がでてくれば、 剛体（どんな力をかけても絶対に変形しない物体）を使ってモデル化します。 さらに、物体の変形や流動性まで考慮する必要があるなら、流体モデルを使います。 質点 → 剛体 → 流体と、 右側に行くほど扱える物理現象の幅は広がりますが、 理論も計算も難しくなります。 回転も
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
