Reactにおける再利用とテストを容易にする疎結合なUIを目指す3つのTips
はじめに コード上での問題を正確に認識しておかなければ、問題を繰り返すのです。Reactを使用したプロジェクトに参画したり、OSSプロジェクトのソースコードを散見すると複雑な仕様に立ち向かったUIに出会うことがあるでしょう。 複雑な仕様に立ち向かったUIは以下の特徴があると考えています。 bundle size が肥大している 保守や維持の管理が高い 他開発者にこのUIは何をやっているのか、質問をしなければならない。 質問の回答を聞いてもそのUIが実行していることが多様で理解しづらい。 再利用性が低い そのUIを利用するために満たさなければならない条件が多く、新しく似ているUIを実装することになる。 複雑なAPI 片手の指の数では溢れる props の数が存在している ユースケースを満たすために、既存の機能を使えば実装ができるのか、判断がしづらい 上記のようなUIを見かけた場合、どのような
JavaScript の undefined と null を完全に理解する
JavaScript で頻出する undefined と null について語ります。 言語仕様上の違い JavaScript (ECMAScript) において、仕様上 undefined と null は当然ながら明確に区別されています。いくつか言語仕様上の扱いについて挙げてみます。 比較 厳密な比較演算子 === において undefined と null は区別されます。ゆるい比較演算子 == においては両者は区別されません（仕様 7.2.14）。 console.log(undefined === null); // false console.log(undefined == null); // true 他の falsy な値（false とみなされる値）との比較は、ゆるい比較演算子であっても区別されます（仕様 同上）。 console.log(undefined == fa
プログラマーのための原則（2 万字） - Qiita
はじめに 今でも語り継がれる「原則」は、それだけ価値のあるコンセプトです。 歴史を振り返ることは、失敗を防ぐための効率の良い方法になります。 👑 DRY (Don't repeat yourself) 「同じことを繰り返すな。」 Andy Hunt と Dave Thomas の著書『達人プログラマー』（1999 年）で提唱された原則で、プログラミングに関する最も重要な原則といっても過言ではありません。 DRY 原則だけでなく、どんなデザインパターンやベストプラクティスでも、同じ処理が重複することは基本的に許されていません。 これにはどういう意図が込められているのでしょうか。 🔖 表面的な理由 この原則は、コードの再利用性を高め、そのために疎結合な状態を保つことは、極めて有用なことを示唆します。 1 箇所を直せば済むべき箇所をあちこちに分散させてしまうのは、自分で事故を招いているのと同
PostgreSQL 15正式リリース。ソートの改善で最大で400％高速に、SQL標準のMERGEコマンドサポートなど
オープンソースのリレーショナルデータベース「PostgreSQL 15」正式版がリリースされました（日本語版のプレスリリース）。 News: PostgreSQL 15 Released! https://t.co/af3E117bts — PostgreSQL (@PostgreSQL) October 13, 2022 ソートが最大で400％速度向上 PostgreSQL15ではインメモリとディスク上のソートアルゴリズムが改善され、どのデータ型をソートするかによって性能差はあるとされますが、ベンチマークでは25%から400%の速度向上が示されました。 count()、rank()、row_number()、dense_rank()などのウィンドウ関数でも速度が向上しています。 ライトアヘッドログ（WAL）ファイルでLZ4とZstandard (zstd) の圧縮をサポートを追加したこと
ivy が面白い
ivyとはなにか 機械学習の統一を目指すフレームワークです。現在、JAX, TensorFlow, PyTorch, Numpy をサポートしています。JAXはNumpy互換なので、実質的に Tensorflow&Pytorch の共通APIのフレームワーク(かなり乱暴なまとめ方)です。 研究のペーパーでよく見るのはPytorchですが、産業ではTensorflowがよく使われるようです。 下の表にもありますが、開発者の設計思想を読むと「書き換えの手間」が想像以上に労力を必要とする文面が多く見受けられます。 余談で手元にTensorflowとPytorchの本が2冊あるのですが、実装に互換性があればそういう悩みが減って深層学習の学習が身近になるかもしれないですね。 特に初学者は「最初にどの山に登るのがいいのか」で迷うと思うので。 ivy登場以前から、学習済みモデルを異なるプラットフォームで
Web開発版「手が遅い」ことへの処方箋（手付け、手戻り編）
これを読んで欲しい人のターゲット像や前提について Web版開発の話をしています ITのソフトウェアエンジニアの話をしています ある程度チームのやり方に対して影響を与えられる権限がある人 マネージャーかメンバーかはあまり気にしないです 「発言するのは自由だが聞き流されるだけ」ならこの記事を読む意味はないです ある程度裁量権があり、ビジネスサイドとも話ができるチームのメンバーを想定しています 作業の流れの前提について チケットがあって 作業者がそれを取って（自分で取るのか他人にアサインされるのかは問わない） PullRequestの形でレビュー依頼をかけてレビュワーがレビューする OKならmergeしてそのうち本番デプロイ 間にQAが入るかもしれないけどそこは問わない 手が遅いとは何か？ ある作業者のサイクルタイムが他の作業者に比べて長いこと 100の大きさの作業があるチケットを渡した際に、ほ
アメリカの中国に対する半導体規制がガチでキツい件
半導体業界人。 自分の周りでは大ニュースになってる割に世間では全然騒がれてないんだけど、メチャクチャ国際関係にインパクトがあると思われる事件が現在進行形で起きているで紹介したい。 https://www.bloomberg.co.jp/news/articles/2022-10-12/RJNDM6T0G1KW01 https://www.bloomberg.co.jp/news/articles/2022-10-13/RJNXIKDWRGG001 中国で事業を展開している半導体装置メーカーが人員を引き上げるというニュースなんだけど、記事中で取り上げられている装置メーカーのAMAT、ASML、Lam、KLAは世界シェア1位、2位、3位、5位のメーカーであり、それらが人員を一斉に引き上げるという部分にヤバみを感じる。(ちなみに4位は日本の東京エレクトロンだが、アメリカに圧力かけられたら逆らえな
最終的な製品の設計図は欧米と大差ないレベルのものが作れても、実際に動..
最終的な製品の設計図は欧米と大差ないレベルのものが作れても、実際に動く製品を作るには微細加工技術を極めないといけないので製品化が周回遅れになってしまう感じ。1cm角に1Tbデータを記録するメモリーを作りたいとして、1bitのデータを記録する部分を小さくしたり3次元的に積み重ねるための加工が難易度高かったりする。今回ニュースになってるYMTCだと、業界トップメーカーが2020年くらいに製品化したレベルの製品を2022年に製品化してるくらいの感覚。 で、データを記録する部分を小さくしたり3次元的に積み重ねるための加工に使う工作機械=半導体製造装置は日米欧のメーカーでほぼ独占してて、中国メーカーはほとんど存在感がなくて、これから追いつこうとしても技術開発の蓄積に差がありすぎて10年単位で時間がかかる状況。中国政府の半導体自給率向上の目標年の2025年にはどう頑張っても間に合わなくて、普通の小学1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Pythonではじめる地理空間情報