今まで自分で作ったものが十数個、仕事で5社ぐらいの redux を見てきたので、その結果思うところを書く。 前提として、自分はエコシステムに乗るという意味で今では redux 肯定派だが、redux それ自身が過剰に抱えている複雑さはもっと分解されるべきだ、という立場。 Redux がうまく設計されているとどうなるか 一貫した一つの設計論に従うので、考えることがなくなる 難しさが廃されるのではなく、難しい部分が一箇所に集中する。React Component の末端では、何も考えることがなくなる。状態管理という難しい部分を作る人と、末端のコンポーネントのデザインに注力する人を分けられる。 大規模になっても設計が破綻しにくい、というエンタープライズ向きな特性を持つ。が、その技術基盤は(静的)関数型由来の考えが多く、基礎設計や基盤理解にはハイスキルが要求され、需要と適用対象のミスマッチを感じる
Googleが設立し、Alphabet傘下の子会社として運営されているテクノロジインキュベーターのJigsawが米国時間10月3日、ISPレベルのDNS操作への対抗策として、DNSクエリを暗号化できるAndroidアプリ「Intra」をリリースした。 DNS操作は、独裁的な政権や悪質なISPがネット検閲に用いる最も一般的な手法の1つで、ニュースサイト、情報ポータル、ソーシャルメディアプラットフォーム、望ましくないソフトウェアなどへのアクセスを遮断するのに利用されている。 Intraは、独裁政権が支配する国のISPなど、国家レベルの監視能力を備えた第3者からDNSのトラフィックを隠すことで、DNSが操作されるのを防ぐ。 技術的に見ると、Intraは「DNS over HTTPS」（DoH）というまだ新しいテクノロジを実装している。この技術はまもなく、Internet Engineering
昔はよくわかっていなくて、今は身にしみてよくわかっていることの一つは、追加した行数がマイナスのパッチは素晴らしいということだ。コードは削除できるなら消したいし、自分の書いたコードであれ、誰かが消してくれたらとてもよいことだと思う。 昔はがんばって書いたコードはなるべく「活用」したいと思っていた。活用というのはつまり、捨てるのはなんとなくもったいないから、そのコードをなるべく消さずにすませたいということだ。 しかし無理にコードを生かしておくことの意味など何もない。 コードの履歴などは全部いったん置いておいて、ある時点のソースコードを初めて見たものとしよう。そのソースコードが、そのプログラムが実装するべき機能を実装するために十分かつ最小限のコードであるのと、十分かつ最小限のコードに加えて何かよくわからないコードのどちらかであるとしたら、どちらのほうがいいコードだと思うだろうか？ 前者のほうがい
大昔の話だけど、公共関係のミッションクリティカルなシステムの構築に関わっていたことがあった。止まっても人が死んだりとかはしないけど、それなりの時間止まったりしたら各方面にいろいろ面倒なことになるようなシステムだった。 しかし、そこに導入しようとしていた機器は結構新しいもので、わりと不安定だった。二重化されていたと思うんだけど、頻繁に片方がハングしてしまうというような問題があった。その状態でもう片方もハングすると完全にシステムがダウンしてしまうので、これはなんとかしなければいけないということになった。 そこで誰かが、シリアルポートがついていて、それ経由でコマンドを送ると電源の差込口ごとに電源のオン・オフができる電源タップというのをみつけてきて、それを間に噛ませようという話になった。マシンの状態を監視しておいて、おかしくなったら自動でコンセント抜き差し的なことをして復帰させようというのだ。そし
なにかの機能を実現するためにコードを書いているというのに、そこから脱線して意味不明なコードを書く人たちがいる。汎用性は高いつもりらしいけど無意味に難しいものを作りたがったり、必要がないのに「念のため」に既存の機能を残したがったりする人たちがいる。どうやら柔軟性あるいは汎用性が至上の価値であって、その価値に反するものはなんであれよくないものだと思っている人たちがいるようだ。 そういう考え方は間違っていると思う。 ある機能を実現するにはいろいろな方法がある。プログラマはそのうち一つの方法を選んでそれを実装しなければいけない。機能を実装する前は無限の可能性がありえたが、機能を実装したあとは具体的に実装したこと以外のことはできない。芸術家が大きな大理石のブロックから一つの彫刻を削りだすように、具体化することによってそれ以外のありえた形というのがなくなってしまうが、それは避けられないことだ。全部の可
コンパイラなどを作り始めると本来自分が作りたかったわけではないものについてもせっせとコードを書かないといけなくなる。とくに標準ライブラリの貧弱なCで書いているからそうなってしまうんだろうけど、文字列とかハッシュテーブルみたいな基本的なものも自分で書かないといけない。仮に、ライブラリが充実していたとしても、コンパイルする言語の文法の細かいポイントなどは個別に作り込んでいかなくてはいけない。そういうのはただ複雑なだけで、別に何か勉強になるとかそういうものではなく、ただ地道にコードを書いていかないといけないだけのものだ。 こういう話はコンパイラに限ったものではない。なにを作るにしても、自分の最初から作りたいと思っていたところのコードは分量にして1割とか2割とかで、残りはただ単にひたすらガシガシと書いていかないといけないだけのものだったりする。本質的なものではないなら書かずになんとかならないかな？
機構と方針の分離[1]とは、計算機科学における設計原則の1つ。機構（操作の認可と資源配分を制御するシステム実装部分）は、どの操作を認可するかやどの資源を割り当てるかといった決定を行う際の方針を表すべきでない（あるいは過度に制限すべきでない）という考え方である。 主にセキュリティ機構（認証と認可）に関して議論されるが、様々な資源配分問題（CPUスケジューリング、メモリ割り当て、Quality of Serviceなど）にも当てはまる考え方であり、オブジェクト抽象化全般に関わる課題でもある。 機構と方針を分離すべきだと主張した計算機科学者として Per Brinch Hansen がいる[2][3]。 1987年の論文で Artsyらは「機構と方針を極端に分離」させたオペレーティングシステムの設計技法を論じた[4][5]。 Chervenakらは2000年の論文で、「機構中立性」と「方針中立性
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
