C# CODING GUIDELINES 2024 - Qiita
このドキュメントについて 命名規則、コーディング規則を遵守して生産性を向上させることを目的としています。 自分で書いたコードでも長い間メンテナンスしなければ他人のコードと同じです。 一定の規則に従い、読みやすく、バグの少ない、メンテナンスのしやすいコードを目指しましょう。 規約に従うことは、多くの問題を改善し、技術的負債を減らします。 本書は、以下のページを参考にしています。 Microsoft Learn / .NET / C# / コーディングスタイル / C# 識別子の名前付け規則と表記規則 Microsoft Learn / .NET / C# / コーディングスタイル / 一般的な C# のコード規則 以下のガイドラインは、過去のものなので、最新の事情を反映していませんが、大部分は適用できます。 Microsoft Learn / .NET / フレームワーク デザインのガイドラ
SDF Based Transition Blending for Shadow Threshold Map - ながむしメモ
セルルックキャラクターの顔の陰制御に用いられるShadow Threshold Mapを生成する仕組みについて. 連番二値画像からMapを合成するメイン部分の説明を試みます. SDFによる補間で Shadow Threshold Map を連番画像から自動生成するツール をGitHubのSDFツールの中にUPしました. EUW_GenerateShadowThresholdMap がツール自体. 現状は全画像が等間隔な閾値になります. 合成方法の説明などドキュメントは後で(∩´∀｀)∩https://t.co/6GdbEja9o3#UE5 pic.twitter.com/52QUQek23i— なが (@nagakagachi) 2023年12月5日 概要 UE5上のツールとしては以下のSDF関連ツールに含まれています. ブラックボックス無しでBPとマテリアルとして実装しているので詳細はそ
リファクタリングの道標：リファクタリングを通じて組織を改善していく - トレタ開発者ブログ
こんにちは。トレタ技術顧問の奥野 (@okunokentaro) です。先日のブログ記事『奥野さんと社員のリファクタリング部屋 -リポジトリ層のディレクトリをどう作る？-』に対して多くの反響をいただき、ありがとうございます。いただいたご意見やご質問の一つひとつが非常に貴重であり、大変感謝しています。 いくつか個別に質問をいただくことがあったのですが、それらの質問を要約すると「リファクタリング後のコードもまだツッコミどころだらけでは？」や「リポジトリ層という名前がまずおかしいのでは？」という二つの点に集約されました。これらの質問はとても理解できます。今回の記事では、具体的な個別の質問への個別の回答は控えさせていただきますが、全体的な方針とテーマについてお伝えした上で、トレタが取り組んでいるリファクタリングは何を目指しているのかというお話をします。 前提と目的 今回のブログ記事『リファクタリン
「IT業界の『奥が深い症候群』」について：バッドノウハウと「奥が深い症候群」再考 - 新・日々録 by TRASH BOX@Eel
IT業界には「奥が深い症候群」って言葉があってな 使いにくいシステムを使いこなすことに喜びを感じて、使いこなせない人間を見ると罵倒する そういう人が幅を利かせていつまでも改善がされない そんな症状だ https://anond.hatelabo.jp/20200603093957 ソフトウェア・エンジニアが使うツールには、使い勝手の良くないものが割と存在する。その辺の事情に関してはバッドノウハウと「奥が深い症候群」で語られている内容が詳しいのだが、必ずしもそれが全てではない。 例えばGitは、まあ15年ほど開発が続けられているツールではあるが、それでもどちらかと言えば後発のバージョン管理システムだ。しかしオープンソースの有名どころバージョン管理システムを歴史順に「CVS・Subversion・Git」と並べた時、Gitは最後発なのにも関わらず、使いこなせないというユーザは最も多いように見え
三善カレえぇ。 (播磨町/カレー)
リクエスト予約希望条件をお店に申し込み、お店からの確定の連絡をもって、予約が成立します。 1 予約の申し込み ご希望の条件を当サイトよりご入力ください。 2 お店からのメール ご予約が承れるか、お店からの返信メールが届きます。 3 お店へ来店 予約が確定した場合、そのままお店へお越しください。
ソフトウェア開発現場の「失敗」集めてみた。 42の失敗事例で学ぶチーム開発のうまい進めかた | 翔泳社
やらかしたくないエンジニアに贈る「失敗の教科書」! 失敗事例で学ぶ、よくある落とし穴の回避策 ソフトウェア開発は、どんなときも順調に進むとは限りません。チームで開発を進めるエンジニアたちは、開発の足を止める「落とし穴」の数々と向き合わなければなりません。 「いつのまにか機能が肥大化していて、手がつけられなくなった…」 「仕様がまったく共有されていないまま、開発が進んでいた…」 「ちょっとしたコード変更が一日分の工数を奪った…」 本書は、このような落とし穴にハマってしまった開発現場の「失敗エピソード」を面白おかしく紹介する、失敗事例集です。事例は架空の開発現場を舞台にしたフィクションですが、著者自らが体験した経験をベースに構成しているので、臨場感たっぷり。読んでいるだけで冷や汗が浮かびます。 また、失敗につながる落とし穴を回避したり、抜け出すための方法も解説しています。新しく開発チームを率い
マルスと「熟練が必要なUI」についての議論
JRの職員がマルスを操作する動画が話題になった。 この動画について、職人性を賞賛する立場と、UIとして問題があるという立場が対立していた。 nobkzさんのこの記事は、「熟練が必要なのはUIとして問題がある」という立場での記述だとおもう。 一連の話題に対して違和感を持ったが、違和感の源泉は明確で、「UIとしてよいかどうか」という立論自体に机上の論理以上のものにならないということもあるが、そもそも「マルスとはどういうシステムなのか」が議論されていないことがおおきい。 わたしもマルスについて名前は知ってはいたものの、具体的にはどういうシステムであるかは知らなかったので、少し調べてみることにした。 マルスについて Twitter(X)で話題になっていたもとの動画はこちらである。 ここだけ取り上げてみて、マルスの良し悪しを論じるのは鉛筆を取り上げて絵の良し悪しを論じるようなものだとおもう。 次の動
自動化するならちゃんとエラーを出せ。想定しろ。不安になれ。 - じゃあ、おうちで学べる
はじめに 自動化やツール開発において、通常時に上手くいくのは当たり前です。大切なのは失敗を想定することです。自動化したツールがエラーも出さずに実行結果的にも成功してるので動いていると思っていたら、実は問題が発生していて泣いた経験は、多くの人にあるのではないでしょうか。エラーを出力し、適切に失敗させて、ログに記録することで、問題の早期発見と迅速な対応が可能になります。また、エラーが発生する可能性のある箇所を事前に想定し、適切に処理することで、ツールの信頼性と安定性が向上します。 しかし、エラーハンドリングができていても、それだけでは不十分です。優れた自動化ツールは、環境の変化に柔軟に対応できるようにコードが設計されているべきです。 また、自動化ツールの完成度を高めるには、エラーハンドリングだけでなく、保守性、拡張性、ユーザビリティなども考慮する必要があります。 自動化ツールを開発する際は、常
neverthrow で局所的に Result 型を使い、 try-catch より安全に記述する
Result 型 (類似するものとして Either Monad の方が有名かもしれません) を導入する場合、アプリケーション全体の設計を変えたり、全箇所を書き換える必要はありません。 neverthrow は部分的に使用でき影響範囲も閉じるので、局所的に使い始めることができます。 (Rust のような) Result 型 とは ざっくり言うと関数の処理の結果と成否を 1 つの型 Result<T, E> で表したものです。(T は期待する結果の型、 E はエラーを表現する型) 筆者は詳しくはないのですが、 Haskell 等にある Either<L, R> とは厳密には違うようです(Either は両方の値が使用可能であることを前提としている？) 参考: Rust ではなぜ、Either 型ではなく Result 型を採用しているのか neverthrow とは TypeScript で
浮動小数点数の min / max - Qiita
多くのプログラミング言語には、「2つ以上の数値が与えられた時、その最小値あるいは最大値」を返す関数 (min / max) が用意されている。入力が整数や有理数であれば難しい話はないのだが、対象が浮動小数点数の場合は厄介な問題が起こる。具体的には、「NaN の扱い」と「0 の符号の扱い」だ。 浮動小数点数の NaN は、皆さんご存知の通り、順序付けられない。NaN が絡む場合の min / max 演算については、「入力に NaN が含まれていたら結果も NaN とする」「NaN を入力の欠落として扱い、NaN でない入力があればそれを返す」などの立場が考えられる。 もっと細かいことを言うと、NaN を返す場合に入力で与えられた NaN を返すか、正規化された NaN を返すかという違いもありうるし、signaling NaN の扱いも議論の余地があるかもしれないが、この記事では細かいこと
特別寄稿 インドに抜かれ「GDP5位」なぜ、日本は凋落一途か／中野剛志・評論家
特別寄稿 インドに抜かれ「GDP5位」なぜ、日本は凋落一途か／中野剛志・評論家 日本だけが成長しなくなったのは、この30年間の政策担当者が誤った経済政策を行い、世界でも突出して愚かだったから。 2024年6月号 BUSINESS ［失われた30年］ 日本は、2023年のドル建ての名目国内総生産（GDP）でドイツに抜かれ、世界第4位に転落した。世界第2位の地位を中国に明け渡したのは、2010年である。しかし、中国の場合は人口が日本よりはるかに多く、また高度成長期にあった。このため、人口減少局面にある成熟社会の日本が名目GDPで中国に凌駕されるのは仕方がないというような見方が、当時は、まだ大勢を占めていた。しかし、ドイツの人口は8300万人と日本より少なく、人口が増加しているわけでもない成熟社会である。しかも、近年はドイツ経済も停滞が続いていた。特に23年はマイナス成長だったのである。したがっ
EMアルゴリズム - Wikipedia
EMアルゴリズム（英: expectation–maximization algorithm）とは、統計学において、確率モデルのパラメータを最尤推定する手法の一つであり、観測不可能な潜在変数に確率モデルが依存する場合に用いられる。EM法、期待値最大化法（きたいちさいだいかほう）[1][2]とも呼ばれる。その一般性の高さから、機械学習、音声認識、因子分析など、広汎な応用がある[1]。 EMアルゴリズムは反復法の一種であり、期待値(英: expectation, E) ステップと最大化 (英: maximization, M)ステップを交互に繰り返すことで計算が進行する。Eステップでは、現在推定されている潜在変数の分布に基づいて、モデルの尤度の期待値を計算する。Mステップでは、E ステップで求まった尤度の期待値を最大化するようなパラメータを求める。M ステップで求まったパラメータは、次の E
EMアルゴリズム徹底解説 - Qiita
ステップ2 $r_{nk}$を固定して$J$を$\mu_k$で偏微分して最小化します。 式変形をすると、 クラスタ$k$の最適なCentroidは上記のように、クラスター$k$に所属しているデータの平均であることがわかりました。 上記より最初のデモンストレーションで行っていたアルゴリズムは損失関数$J$の最適化によって導出されたものを適用していたことがわかります。 2−3. 実装 上記で示した２ステップを計算して、イテレーションを回すだけのシンプルなプログラムです。最後に更新前のmuと更新後のmuの差を取り、それがある程度小さくなったら収束したと判断し、イテレーションを止めるようにしています。 下記はアルゴリズム部分の抜粋です。プログラムの全文はコチラにあります。 for _iter in range(100): # Step 1 =============================
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Generalized ridge regression and smoothing splines
GitHub - alexpatel/lean-ex: exercises for LEAN theorem prover
GitHub - leanprover-community/mathematics_in_lean: The user home repository for the Mathematics in Lean tutorial.
trimesh package - trimesh 4.4.7 documentation
GitHub - shapely/shapely: Manipulation and analysis of geometric objects
Shapely — Shapely 2.0.6 documentation
Newton Raphson Fractals