よく知らないアプリケーションの性能と戦わないといけないときの防衛術（前編） - Qiita
よく知らないアプリケーションの性能と戦う、という状況 SNSにキャンペーン載せたらバズってサイトがずっと503なんです、なんとかなりませんか？ バッチがいつもの時間に終わらないんですけど、急ぎ見てください！ みたいな連絡を、そろそろ帰るかと思った21時とか明け方5時とかに電話が鳴って受けることって、そこそこあると思うんです。 私が設計したわけでもなく開発したわけでもなく、レビュー参加とかで辛うじて全体は分かるけど、いまからソース見る時間もないし、開発した方は性能面の対処が覚束ない。突然性能面で火を噴いてなぜか自分が召喚されて2~3時間でどうにかしたい、という闇な状況にどういうふうに対応していたっけ自分、というのを経験則100%で書いてみようと思います。 この前編は道具の紹介(OS編)、中編は道具の紹介(Java)、後編は道具の紹介(PostgreSQL)です。 中編 → https://q
射影行列 - Qiita
射影行列とは 射影行列は、あるベクトルに作用させると、そのベクトルの部分空間成分を取り出すような行列である。 射影行列がなぜ重要かというと、線型方程式系の最小二乗解と密接に関係しているからである。 最小二乗解は一般逆行列を使って求められるが、一般逆行列の表式の意味を理解しようとすると、射影行列を知っておくのが一番てっとり早いのである。 射影行列の表式 ストラングの教科書1に従って、行列$A$の列ベクトルたちの張る空間を列空間と呼ぶことにする2。 このとき、$A$の列空間への射影行列は $ A (A^T A)^{-1} A^T $ であることが知られている3。 この記事ではこの表式を導出したいと思う。 導出の前置き 前出のストラングの教科書では、直交性を使って示されている。 しかし、ここでは、双対基底というものを使うことで、射影行列がより簡潔かつ一般的に書けることを示した上で、元々の表式も導
多相レコードで多相バリアントを表現する - Qiita
SML# のマニュアルには、多相レコードで多相バリアントを表現する方法が説明されているがどうもわかりにくいらしい。もう少し単純な例から始めてみよう。 レコードでバリアントを表現する まず、多相でないレコードでバリアントを表現することを考える。
レコードとバリアントの双対性について - Qiita
{-# LANGUAGE Rank2Types #-} -- パターンマッチ自体をレコードとして表現する data MatchEither a b c = MatchEither { whenLeft :: a -> c, whenRight :: b -> c } -- レコードとして表現されたバリアント newtype RecEither a b = RecEither { unRecEither :: forall c. MatchEither a b c -> c } -- コンストラクタ left :: a -> RecEither a b left x = RecEither (\match -> whenLeft match x) right :: b -> RecEither a b right x = RecEither (\match -> whenRight matc
劣微分・劣勾配と共役関数の可視化 - Qiita
最適化や凸解析の本のわりと序盤に登場するトピックに 劣微分・劣勾配 と 共役関数 があります。いずれも凸関数にとって特に重要な概念ですが、通常の書籍だと当然動きのない図でしか描かれていないため、イメージしづらい方もいるでしょう。そこで代表的な凸関数について、劣微分・劣勾配および共役関数のアニメーションを作りました（初めて本格的にGoogle Colabを使いました）。本の図よりはもっと鮮やかにイメージでき理解が深まるかと思います。なお、厳密には「閉真凸関数」などと呼ぶべき箇所を簡単のために単に「凸関数」と記述しています。厳密な定義などは専門書（例えば [福島2001,冨岡2015]）を参照ください。 多変数関数 $f$ のある一点 $x$ での傾き（昇る方向）を表すベクトルを 勾配 と呼び $\nabla f(x)$ と表しますが、微分不可能な点では勾配を求めることができません。この問題を
5歳娘「パパ、型はドキュメントだよ？」 - Qiita
とある休日 娘（5歳）「パパ、今日はお休みだから一緒にゲームしよ？」 ワイ「ええで！なんのゲームする？」 ワイ「スーパー正男ブラザーズでもやろか？」 娘「ううん」 娘「コードジャンケンしよ！」 ワイ「なんや、その恐ろしそうな名前のゲームは。。。」 娘「なんか仕様を決めて、どっちが読みやすいコードで実装できるか勝負するの！」 ワイ「おお、ええで」 ワイ「流石に5歳児には負けへんで！」 ワイ「6歳児だと危ういけどな！」 娘「じゃあ、ママ」 娘「何か仕様をちょうだい！」 よめ太郎「ええで」 仕様: 数値を文字列に変換する よめ太郎「仕様、考えたで」 よめ太郎「数値を文字列に変換する、っちゅう内容や！」 【いま考えた仕様書】 とあるAPIから0〜2の数値が返ってくるとする 0〜2の数値は、ユーザーの申込進捗状況を表しているものとする 0〜2の数値は、それぞれ以下の状態を表している 0 → 申込書到
Windowsフォームでの高DPI(Hi-DPI)対応のコツ - Qiita
はじめに Windowsフォームアプリをなるべく簡単に高DPI(Hi-DPI)対応させるコツをまとめました。 Windowsフォームの自動スケーリング機能を活用します。 今回やらないこと 下記機能が.NET Framework 4.7でサポートされましたが、実装コストが高いので対応はしません。 起動中のDPI変更サポート (Dynamic DPI) モニタ別のDPIサポート (Per monitor DPI) 対応方法 アプリケーションマニフェストの設定をする プロジェクトにアプリケーションマニフェストファイルapp.manifestを追加し、下記の設定を記入します。 この設定でWindowsが高DPIサポート済と認識してくれるので、表示がぼやけることが無くなります。 <application xmlns="urn:schemas-microsoft-com:asm.v3"> <windo
単一責任原則で無責任な多目的クラスを爆殺する - Qiita
この記事は クラウドワークスアドベントカレンダー2020 8日目の記事です。 概要 こんにちは、クソコードを爆殺リファクタリングするのが大好きなミノ駆動です。 今回は単一責任原則の話です。 単一責任原則はSOLID原則のひとつとして有名で、2020年のオブジェクト指向カンファレンスのアンケートでも、SOLID原則の中で最も人気がありました。 皆さんは単一責任原則を遵守した設計をしていますか。 どんな構造が単一責任設計で、一方どんな構造が単一責任でない設計か、明確に意識していますか。説明できますでしょうか。 ところで「単一責任原則とはなんぞや」について、少なくとも私の観測範囲では、概念的な話にとどまっているものが多く、コードレベルで具体的に説明しているものは少ないように感じます。 そうした状況からか、単一責任原則の解釈が人によって違っていたりしているように感じます。 本記事は、今一度単一責任
0歳娘「パパ、型を作る関数はないの？」 - Qiita
2015年、とある休日 よめ太郎「あ・・・あんた！」 よめ太郎「こっち来て！！！」 ワイ「ど、どうしたん？」 ワイ「えらい大っきい声出して」 よめ太郎「娘ちゃんが初めて立ったんや！」 娘（0歳）「ヨチ・・・ヨチ・・・」 ワイ「おお・・・！」 ワイ「これはめでたいこっちゃ・・・！」 娘「・・・パパァ・・・」 ワイ「！？」 ワイ「いま、パパ言うたで！？」 ワイ「立ったと同時に言葉も喋れるんか！？」 ワイ「なんて末恐ろしい子や・・・！」 娘「・・・エテ・・・教エテ・・・」 ワイ「な、なんや喋っとるで・・・」 ワイ「なんや、娘ちゃん・・・？」 娘「・・・パパ・・・」 娘「・・・プログラミング・・・教エテ・・・」 ワイ「ファッ！？」 ワイ「Hello, World!でええか・・・？」 よめ太郎「いや、Hello, World!は産声で言うてたわ」 ワイ「せやった！」 ワイ「お医者さんが思わず・・・」
レビューする人も、される人も知っておきたい！開発プロセスごとのレビュー観点チェックリスト - Qiita
この記事はモチベーションクラウドシリーズのアドベントカレンダー7日目の記事です。 こんにちは。リンクアンドモチベーション、モチベーションクラウド開発チームの江上です。 モチベーションクラウドの開発チームは、新卒メンバーも多数参加していることもあり、開発プロセスを細かめに定義しています。その開発プロセスにおいてそれぞれに、「レビュー観点チェックリスト」を作成しているので、それを公開していきたいと思います。 全てのチームで有効とはいかないものの、何かの気付きになればいいなと思います。また、「こういう観点もあるよね」というFBは大歓迎ですのでぜひよろしくお願いします。 開発プロセスの定義 現状の開発プロセス 現在モチベーションクラウドの開発チームは以下のようなプロセスを前提にして動いています。 関係者レビューは実際には実装のレビューに近しいですが、実装レビューはコードレビューと紐付けたいので、あ
7万行のJavaScriptコードをTypeScriptに移行した話 - Qiita
はじめに 今関わっているプロジェクトで7万行以上のコードを、JavaScriptからTypeScriptに移行するというのを経験しました。 移行するにあたっての準備や手順、実際にやってみて感じたことなどを共有します。 プロジェクトの概要 フルスタックWEBアプリケーション フロントエンド: JavaScript + React バックエンド: Node.js + Express.js + GraphQL なぜそもそもTypeScriptを採用しなかったのか 事前に技術選定をした際に、TypeScriptを利用するかどうかの議論はありました。 当時は以下の理由から採用しないという選択に至りました。 JavaScriptの開発に慣れていたため、TypeScript型定義=面倒というイメージが強かった 「スピードが命」と考えており、TypeScriptを使うことで開発効率が下がると思っていた プ
C++からRustに移行して1年経って思ったこと - Qiita
はじめに この記事は「プログラミング技術の変化で得られた知見・苦労話【PR】パソナテック Advent Calendar 2020」のために書かれたものです。 僕は去年の11月から一念発起してRustの勉強を初めて趣味で同人ゲームを開発しています。元々C++を4年程使っていて「C++最高、みんなC++使おう」とか友人に布教していました。しかし、C++プログラマは「一番自分たちの言語の批判に対して強くなる」と言われるほどC++はよくディスられます。もちろん僕も例外ではありませんでした（笑）。 一応僕もPythonを適当に使うようになってからC++のcppとhppを組み合わせるようなCの名残を感じるところや他言語と比べたときの標準ライブラリの貧弱さ、コードが冗長になりやすい点など使いにくいなあと思いはじめましていました。ですがPythonはあくまでも適当に使ってただけでしたし、一通り書けるJa
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - rust-ndarray/ndarray: ndarray: an N-dimensional array with array views, multidimensional slicing, and efficient operations
GitHub - dimforge/nalgebra: Linear algebra library for Rust.