タグ

ブックマーク / numb86-tech.hatenablog.com (9)

  • 『UNIXという考え方―その設計思想と哲学』を読んだ - 30歳からのプログラミング

    UNIX やそのツールはどのような考えに基づいて作られているのか解説した。 UNIX が開発されていくなかで培われていった文化や考え方について書かれている。 www.ohmsha.co.jp UNIX が具体的にどのように動いているのかではなく、 UNIX はなぜそのように動いているのか、ということが主題。 そのため、 UNIX に限らずソフトウェア開発全般に適用できるような内容になっている。ソフトウェアだけでなく「ものを作る」こと全般に応用できる内容も多いかもしれない。 私も、現時点では UNIX そのものに対する熱意や探究心はあまりないので、 UNIX について知るためではなく開発の参考になる考え方がないかと思って読んだ。 9 つの定理が紹介されているのだが、まず思ったのは、「言うは易く行うは難し」という感じの定理ばかりだなということ。 例えばシンプルに保て、小ささを維持しろ、という

    『UNIXという考え方―その設計思想と哲学』を読んだ - 30歳からのプログラミング
  • React の新しい概念「トランジション」で React アプリの応答性を改善する - 30歳からのプログラミング

    React v18 には多くの改善や新機能が盛り込まれる予定だが、そのなかでも特に注目を集めると思われるのが、Concurrent Features と呼ばれる一連の機能。 これらの機能を使うことで、コンポーネントのレンダリングについてより柔軟な設定が可能になり、上手く使えばパフォーマンスや UX の向上を実現できる。 この記事では Concurrent Features のひとつであるstartTransitionと、それを使いこなす上で重要な概念である「トランジション」について説明する。 この記事ではコンセプトの説明や具体例の提示のみを行う。詳細を知りたい場合は以下を参照。 一年前の記事であるため古くなっている部分もあるが、根幹は大きく変わっていないと認識している。 なお、上記の記事には「Concurrent Mode」という用語がタイトルに入っているが、これは今後は使われなくなってい

    React の新しい概念「トランジション」で React アプリの応答性を改善する - 30歳からのプログラミング
  • 『THE MODEL』を読んだ - 30歳からのプログラミング

    「科学的な営業」に興味があり、その分野の定番のひとつである『THE MODEL』を読んだ。 どのように営業プロセスを構築し機能させるのかについてコンパクトにまとまっているので、特に BtoB SaaS を提供している企業で働いている開発者は、一度読んでおくとよいと思う。 www.shoeisha.co.jp なんとなくの印象だが、「営業」というものについて、自分とは縁遠いもの、別の世界のもの、という感覚を持っている開発者は多いかもしれない。 自分もそうだった。むしろ、かなり悪い印象を抱いていた。 新卒で入った信用金庫の営業スタイルが絵に描いたような根性論、精神論だったのが大きい。 「飛び込み営業をすれば嫌がられるし、何度も訪問すれば怒られる。それでも諦めずに通い続けることで根性を認めてもらえて、取引してもらえるんだ」ということを役員が真顔で語っていたし、「昔は「契約するまで帰りません」と玄

    『THE MODEL』を読んだ - 30歳からのプログラミング
  • フロントエンドのパフォーマンスチューニングを俯瞰する - 30歳からのプログラミング

    去年からフロントエンドのパフォーマンスについて断続的に学んでいるが、自分の頭のなかにある知識はどれも断片的で、まとまりを欠いているような感覚があった。 知識と知識がつながっておらず、各施策が何のために行われるのかも、必ずしも自明ではなかった。何となく「パフォーマンスに効果がある」と言ってしまうが、それが何を指しているのかは実は曖昧だった。 このような状態では新しい知識を得ていくのが難しいというか、効率的に行えないように思えた。議論の背景が分からないし、文脈や問題意識を上手く掴めないから。何の話をしているのかよく分からない、という状態になりがち。書かれてあることの意味は分かっても論旨を掴めているわけではないから、自分のなかに定着しない。 そこで、現時点で自分が知っていることを整理して、自分なりに分類しておくことにした。 当たり前だが、どのテクニックがどの程度有効なのかは、状況によって違う。

    フロントエンドのパフォーマンスチューニングを俯瞰する - 30歳からのプログラミング
  • React.memo を使ったパフォーマンス最適化について - 30歳からのプログラミング

    パフォーマンス・チューニングには、「こうすれば必ず上手くいく」という方法論や銀の弾丸はなく、地道に試行と計測を繰り返すしかない。 しかしだからこそ、基的な考え方や仕組みを理解することが大切であり、それがなければ、どのように対処していけばいいのか見当をつけることすら出来ず、的外れな対応をすることにもなりかねない。 React.memoを使った処理の最適化は、React アプリのパフォーマンス改善のための、基となるテクニックのひとつである。 この記事のコードは React のv16.10.2で動作確認している。 メモ化という概念 React アプリのパフォーマンス最適化を理解するためにはまず、メモ化(Memoization)という概念を把握しておく必要がある。 大雑把に言ってしまうとメモ化とは、何らかの計算によって得られた値を記録しておき、その値が再度必要になったときに、再計算することなく

    React.memo を使ったパフォーマンス最適化について - 30歳からのプログラミング
  • React の状態管理についての論点整理 - 30歳からのプログラミング

    なぜグローバルな Store を作るのか React アプリの設計論では、複数のコンポーネントで利用する値をどのように管理するか、というテーマがよく話題になる。 前提として、コンポーネントは小さく分割すべき、という考え方がまずある。 これは React に特有のものではなく、プログラミングの一般論として、ひとつひとつの関数は小さくするのがベストプラクティスだとされる。それには様々な理由があるが、単一責任の原則、疎結合、テスタブル、などがよく理由として挙げられる。 React のコンポーネントも同じで、肥大化しないように管理することが、保守しやすいアプリへの道だ。いかに適切な粒度でコンポーネントを分割できるかが、React を使いこなす上で重要となる。 だがコンポーネントを分割していくと、複数のコンポーネントで共通の値を扱う、という状況が発生しうる。 それにどのように対処するか、というのが、

    React の状態管理についての論点整理 - 30歳からのプログラミング
  • SPA フルリニューアル計画における技術選定や設計思想(2019年2月版) - 30歳からのプログラミング

    SPA のフルリニューアルを技術選定や設計からやることになった。 前回の記事も、そのために検討や調査を行っている際に生まれた副産物をまとめたものだ。 目指すべきは変更しやすいシステムであり、そしてそれは、堅牢性を実現することで達成されるはずだという結論に至った。 numb86-tech.hatenablog.com 今回の記事では、堅牢なシステムの実現に向けてどんな技術を選んだのかを記録しておく。 まだ検証フェーズというか、試し書きや検証を行っている段階なので、今後変わる可能性はある。 前提 現行のアプリは Rails アプリで、その上に Vue を載せて SPA を作っている。 フロントエンドのビルドは Webpacker 。別のプロダクトでは Webpacker を剥がしてしまったが、このプロダクトでは実現できていない。 ビュー関連の処理について、どこまでを Rails でやってどこか

    SPA フルリニューアル計画における技術選定や設計思想(2019年2月版) - 30歳からのプログラミング
  • async/awaitを使った非同期処理の書き方 - 30歳からのプログラミング

    ES2017で仕様に入ったAsyncFunctionとawait単項演算子。 これらを使うと非同期処理を同期的に書くことができ、非同期処理のループもシンプルに書けるようになる。 この記事の内容は全てNode.jsのv8.6.0で動作確認している。 非同期処理の基礎はこちら。 AsyncFunction 関数定義の前にasyncとつけると、その関数はAsyncFunctionになる。 async function myFunc(){ return 'foo'; } console.log(myFunc); // [AsyncFunction: myFunc] console.log(myFunc()); // Promise { 'foo' } myFunc().then(res => console.log(res)); // foo 非同期処理をシンプルに書けていることが分かる。 Asy

    async/awaitを使った非同期処理の書き方 - 30歳からのプログラミング
  • Node.js+React+ReduxでTwitterクライアントを作った - 30歳からのプログラミング

    ReactとReduxの習作として、ブラウザで動くTwitterクライアントを作った。 サーバーサイドはNode.js。Expressも使っている。 JavaScriptだけでこういったものが作れるのだからすごい。 APIとやり取りをして情報を送受信し、それを元にビューを構築。 ユーザーのアクションを受け取ってまたAPIとやり取りをして。 といった、フロントエンド開発っぽいことをやれたのはよかった。 特にホーム画面は、SPAっぽいものを作れたと思う。 無論、いろいろと課題も残っているけど。 サーバーサイドレンダリングをやれていないから初回のレンダリングに時間が掛かってしまうし、タイムラインはREST APIではなくStreaming APIで自動取得できるようにしたかった。 時間がなくて断念した。 開発スピード、というのは今後の大きな課題だと思う。 とはいえ、所期の目的は達成できた。 Re

    Node.js+React+ReduxでTwitterクライアントを作った - 30歳からのプログラミング
    yuiseki
    yuiseki 2017/05/26
  • 1