React の状態管理についての論点整理 - 30歳からのプログラミング
なぜグローバルな Store を作るのか React アプリの設計論では、複数のコンポーネントで利用する値をどのように管理するか、というテーマがよく話題になる。 前提として、コンポーネントは小さく分割すべき、という考え方がまずある。 これは React に特有のものではなく、プログラミングの一般論として、ひとつひとつの関数は小さくするのがベストプラクティスだとされる。それには様々な理由があるが、単一責任の原則、疎結合、テスタブル、などがよく理由として挙げられる。 React のコンポーネントも同じで、肥大化しないように管理することが、保守しやすいアプリへの道だ。いかに適切な粒度でコンポーネントを分割できるかが、React を使いこなす上で重要となる。 だがコンポーネントを分割していくと、複数のコンポーネントで共通の値を扱う、という状況が発生しうる。 それにどのように対処するか、というのが、
Rust で DOS
終了 最初にrコマンドで、リアルモードx86のレジスタ群を確認して見ましょう。 下記の図のようになります。 ２行にわたってAX,BXをはじめとする各レジスタの値が16進数で表示されています。 注:debug コマンドでは基本的に16進数を扱います。 COM 形式と EXE 形式 いよいよ DOS で本物のアセンブリを入力していきますが、その前に DOS プログラムの約束事を押さえておきましょう。 DOSプログラムの実行形式には COM 形式とEXE形式があります。 ここでは、より単純な COM 形式を扱います。 COM 形式のプログラムは、アドレス 0x100 から始まる決まりになっています。 先頭の 256 バイトが空いていることに違和感を覚えるかもしれませんが、これは ELF 実行形式の ELF ヘッダーのようのものと思うと理解しやすいでしょう。 先頭のアドレス空間は PSP（Prog
赤黒木の本質 - Qiita
この記事はデータ構造とアルゴリズム Advent Calendar 2019 16日目の記事です。 15日目は@minaminaoさんによる「すごいTrie」です。 17日目は@takilogさんによる「Fréchet距離の計算アルゴリズム」です。 はじめに この記事では有名なデータ構造である赤黒木がなぜあのようなトリッキーな定義になっているのかその本質について解説します。 赤黒木の定義を見てトリッキーと思うかどうかは個人差あるかと思いますが、少なくとも僕が初めて赤黒木を学んだ時はなぜこのような定義になっているのか、そしてどうやって思いついたのか見当がつかずとても不思議に感じました。 しかし、その後赤黒木の成り立ちやその基になったデータ構造について知ると、トリッキーに見えた定義がとても自然であることを実感しました。 おそらく知っている人は当たり前に知っている内容だとは思いますが、知らない人
大規模オンプレミスなヤフーのサーバーインフラの裏側 〜 サーバー調達や運用の流れを紹介します
OEM系→ODM系にシフトした背景ですが、1つは 価格競争力 です。 インフラにおいてプライスは重要な指標です。 また昔と今でヤフーのサーバーの買い方に違いがある事もポイントになっています。 昔のヤフーは、いろいろな部門が、いろいろな構成のサーバーを、いろいろなタイミングで購入していました。 この結果、納期面で有利なOEMを第一選択肢としていました。 またいろいろな構成のサーバーが入る事を考慮した結果、自営保守ではカバーしきれない範囲も多く、ベンダーが提供するサポートに依存している部分もありました。 しかし最近では 自社クラウド環境の普及により、決まった部門決まった構成決まったタイミングで購入するように になってきたため、 納期に関して余裕を持ったスケジューリングができるようになりました。 またクラウド環境で利用できるサーバーはかなりハイスペックなため、価格の数％の違いも大きなビジネスイン
日立社員「社内からQiitaに投稿？できるのそれ」 - Qiita
(2019-12-18 表現を一部訂正しました。) メタ記事。投稿するのにかかる手間に関する投稿です。 1 どうしてこんな記事を書こうと思ったか 日立製作所もガンガンOSS活動をしていることを知ってほしい。日立に興味があるが、OSSコントリビューションは社外発信にどれくらい熱心なのか気になる人向けに、とある一部署の情報をシェアしたい。 タイトルのような感想を持つ弊社内の人に情報発信してもらいたい。 (残念なことに、) 社内の情報共有サイトに書くよりQiitaに書いたほうが読まれそう。 後輩がAdvent Calendarの記事集めに苦労していたので気の毒になったため 注: 全社的な審査プロセスではなく、(株)日立製作所 ITプロダクツ統括本部のやりかたです。 では全社的なプロセスは？他の部署は？ → 詳しい方、（申請の上）コメントください。 ITプロダクツ統括本部って何？ Google i
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
