開発者ポータル Backstage とは - Carpe Diem
背景 開発チームが抱えるよくある課題として システムが変化する一方でドキュメントは更新されず腐る メンバーの流入出によって口伝でかろうじて継承された知見も失われる 検索性が良くないと過去のドキュメントが気づかれず、同じような内容のドキュメントが新規量産される 後から参加したメンバーはどちらが正のドキュメントか分からず混乱する といったことが良くあります。 解決方法としては以下のように、GitHub＆ルールベースで管理するといった例があります。 future-architect.github.io また組織・システムが大きくなってくると認知負荷を低減するためにドメインで区切るような形でチームの分割が始まりますが、 異なるチームによってシステムが管理され、システムの依存関係を全て知っている人がいなくなる CxOレイヤが大規模イベント前に現状を把握したいときに都度時間がかかってしまう チームごと
DXLibのMV1でなんちゃって金属表現 - Qiita
DXLibのMV1でなんちゃって金属表現 今回、金属表現に挑戦してみますが、なんちゃってなので物理ベースレンダリング(PBR)は取り扱いません。 思想そのものには触れますが、DXライブラリとしては難しい気がするので、ホントに「なんちゃって」でやっていきます。 ガチでPBRやりたい人は、Qiitaでも色んな人が解説してますので、そっちを見たほうがいいと思います。 とりあえず実例を見て判断してもらったほうがいいかなと思います。 例 動画はTwitter(X)に上げておきました。 はい、多分DxLibでMV1表示したにしては金属感が出ていると感じるのではないでしょうか？ とりあえず感じない人はブラウザバックなりタブを閉じるなりしてください。たぶんこれ以上読んでも意味はないかなと思いますので。 そもそも何で金属感があまり出ないのか 基本的に現状のDXライブラリのシェーディング方式は「古典的 シェー
Visitorパターンで型によるswitchやif判定を消す - Qiita
今回の話 「Visitorパターン」を使ってswitch文やif文での型分岐を置き換えてみよう、という話です。C#で書いてます。 （サンプルコードはだいぶ端折ってるのであまり突っつかないで下さい） switchやif文のどこが良くないのか 「型の判定によって処理を分岐する」という実装をswitchやifで作ってしまうと、後から構造を変更した際などに問題が起きる可能性があります。 （そもそもオープンクローズド原則違反になってしまう） たとえば「型をみてデータ構造を変換する」といった場合はこの問題を踏みやすいです。 例：データ構造を1:1変換する 「RPGのキャラクター（ジョブ）」という概念があったとしましょう。 これは基底クラスであり、派生先にいくつかのジョブがあってそれぞれで独自のパラメータを保持しています。 /// キャラクターの抽象クラス public abstract class C
DNS浸透いうな - それは言葉狩りじゃなくて
DNS リソースレコードを管理していると、「DNS には浸透期間があるため、DNS の設定変更後は24時間〜72時間お待ちいただく必要があります」などと書かれた DNS 事業者の注意書きを見かけることがあります。 ホスティング業者によって「浸透」等が不適切に使われている例 - www.e-ontap.com DNS浸透言ってるところと言っていないところ【レンタルサーバ編】 - ohesotori.hateblo.jp このような記述が蔓延っているために、DNS 利用者の間で「DNS では設定が浸透するまで待たなければならない」という誤解が広まっています。 また、DNS リソースレコードの地理的な伝播状況を可視化するための DNS Propagation Checker なるツールがいくつか存在しています。 https://www.whatsmydns.net/ https://www.ns
devill.tamachan / binaryeditorbz · GitLab
Admin message The 17.0 major release is coming on May 16, 2024! This version brings many exciting improvements to GitLab, but also removes some deprecated features. We are introducing three breaking change windows during which we expect breaking changes to be deployed to GitLab.com. You can read more about it on our blogpost. The third breaking change window begins 2024-05-06 09:00 UTC and ends 20
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://www.amazon.co.jp/dp/B07SMZ4NKM/