This book explores the core principles of functional programming (FP) as they are applied to JavaScript. But what makes this book different is that we approach these principles without drowning in all the heavy terminology. We look at a subset of FP foundational concepts that I call "Functional-Light Programming" (FLP) and apply it to JavaScript.

This book is a balanced, pragmatic look at FP in JavaScript. The first edition is now complete. Read here online for free, or: "Functional-Light JavaScript" explores the core principles of functional programming (FP) as they are applied to JavaScript. But what makes this book different is that we approach these principles without drowning in all the heavy terminology. We look at a subset of FP fou

エンジニアと法律家のための勉強会StudyCode #5 技術と好奇心

→1章のみを無料サンプルとして公開しています。 タイトルのとおり、4/14の技術書典6で「jQuery to Vue.jsで学ぶ レガシーフロントエンド安全改善ガイド」という本を頒布します。 技術同人誌というものを初めて書いていますが、せっかくなら一人でも多くの方に見てもらえると嬉しいので、宣伝させてください。 表紙イラストは鍋料理さん(@yaminaberyouri)に描いていただきました！めっちゃステキ。 目次 1-4章 : 改善のための心構えやレガシーコードの理解、着手前の準備について 5-7章 : サンプルコードをjQuery to Vue.jsに実際に書き換えていく具体例 8章 : コード以外の面で改善をうまく進めていくための話 のような構成になっています。 （なお現在校正作業中なので、内容は多少変わる可能性があります。） どんな内容？ 表紙はとってもカワイイですが、私がここ2年

ECMAScriptの浮動小数点数の丸め関数である Number.prototype.toFixed() について調べてみたところ、浮動小数点数をわかっている人が作った硬派な仕様だと感じたので、解説してみます。 浮動小数点数の丸めの善し悪しについて 私はプログラミング言語の浮動小数点数の丸め処理に興味があり、過去に関連記事を30本以上書いています。こうした活動から得られた知見として、良い丸め関数には次のような性質があると考えています。 仕様がシンプルで直感的であること 仕様が抜け漏れなく文書化されていること バグを作り込みにくい仕様であること どれも良い関数の一般論のような話ですが、丸め処理に限って言えば簡単な話ではありません。そもそも浮動小数点数の性質が人の直感に反するため利用者にとっても実装者にとっても罠が多く、結果として上の条件を満たせないことが多いのです（私が面白いと感じるポイント

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

こんにちは、@mugi_unoです。 MisocaでjQuery製のフロントエンドコードを書き換え続けていた結果、技術書典6に参加することになりました。現在必死で書いております。 farewell_webpacker さて、先日とあるブランチがmasterにマージされ、リリースされました。 farewell : ごきげんよう！、さらば！ farewellの意味・使い方・読み方 | Weblio英和辞書 farewell_webpacker です。 長い間フロントエンドのビルドにはRailsのGemであるWebpackerを使ってきましたが、現在は完全に依存を外しており、純粋なwebpackビルドを行う形に書き換えました。 正直なところ、フロントエンド界隈からは否定的な意見を聞くことも多いWebpackerですが、実際にある程度の期間プロダクションで利用してみて、良いところも辛いところも両方

React は、インタラクティブなユーザインターフェイスの作成にともなう苦痛を取り除きます。アプリケーションの各状態に対応するシンプルな View を設計するだけで、React はデータの変更を検知し、関連するコンポーネントだけを効率的に更新、描画します。 宣言的な View を用いてアプリケーションを構築することで、コードはより見通しが立ちやすく、デバッグのしやすいものになります。 自分自身の状態を管理するカプセル化されたコンポーネントをまず作成し、これらを組み合わせることで複雑なユーザインターフェイスを構築します。 コンポーネントのロジックは、Template ではなく JavaScript そのもので書くことができるので、様々なデータをアプリケーション内で簡単に取り回すことができ、かつ DOM に状態を持たせないようにすることができます。

Reactのチュートリアル、たくさんありますよね。どれも質が高く、どこから手をつければいいかわからなくなっちゃいます。 ですがやはり巷のチュートリアルには面倒な問題もあります。今回は面倒ごとを全部すっ飛ばしてReactでのウェブアプリ作りに入門してみましょう。 Reactを始めるには、まずあれとこれとそれとどれと…… Reactやるには、まずNode.js入れてbabel入れてreact入れてreact-router入れて、ついでにredux入れてreact-redux入れて、redux-saga入れて…… Reactめんどくせえ！！！ってのが正直なところだと思います。はい、私もそう思います。ただ、まあ、色々必要なのも事実なので……。 それでもやっぱり「ReactやるならReactだけやりたい。他はどうでもいい」という気持ちは簡単に捨てられるものではありません。そこで今回はそういう面倒全部

The Efficiency Paradox and How to Save Yourself and the World

React Hooks自体の解説記事はいくつかあるけど, Hooksの登場によってReactがどう変わったのかについて書かれている記事が無かったので書いた 継承, Mixin, HOC, render props, Hooksの登場によって, Reactの副作用分割パターンがどう変遷していったのか分かるようにすることがこの記事の目的

この記事では、Webpackerを使っている Rails アプリからWebpackerを剥がし、webpackを使うようにするための手順を書いていく。 Webpackerを止めたい理由は様々だが、主な理由は以下のような感じだろうか。 現時点ではWebpackerが使用しているwebpackのバージョンは3.xで、最新バージョンに追従できていない webpackの設定の他に、「Webpackerの設定」について学ばなければならず、無駄が多い webpackを直接触れば済む話を、常にWebpackerという仲介者を通して作業しなければならない カスタマイズやマイグレーションの際に、考慮しなければならない要素が増えてしまう 手軽にフロントエンド開発環境を導入できる、というのがWebpackerの利点であり、カスタマイズやらアップデートやらが必要になってしまうのならあまりメリットはない、と個人的に

表示中のHTMLから情報を雑に抜き出して利用するため，ブラウザのデベロッパツールなどでquerySelectorAllしてmapしたい．しかし，querySelectorAllはNodeListを返すので，mapするにはArrayに変換する必要がある． NodeListをArrayに変換するときに短く書く方法ないですかって同僚に聞いたらいろいろ教えてもらえたのでメモ． Array.prototype.slice.callする オーソドックスな手法．昔からこれを書いていて，長くて困っていた．最近はアロー関数を使えるのでちょっと短くなったけど長い． Array.prototype.slice.call(document.querySelectorAll('a')).map(a => a.href) [].slice.callする Array.prototypeのかわりに[]で書く．ちょっと短い

数学 B ビット操作 - set/get/update/clear bits, 2つの乗算/除算, 否定的にする. 等 B 因果関係 B フィボナッチ数 - クラシックとクローズドフォームのバージョン B 素数性テスト (trial division 方法) B ユークリッドアルゴリズム - 最大公約数を計算する (GCD) B 最小公倍数 (LCM) B エラトステネスのふるい - 与えられた限度まですべての素数を見つける B Is Power of Two - 数値が2の累乗であるかどうかを調べる（単純なアルゴリズムとビットごとのアルゴリズム） B パスカルの三角形 B 複素数 - 複素数とその基本演算 B ラジアン＆度 - 度数と逆方向の変換に対するラジアン B 高速電力供給 A 整数パーティション A Liu Hui π アルゴリズム - N-gonsに基づく近似π計算 A 離散フ

Over the years, I’ve noticed patterns in how I tend to approach component APIs and building out applications and libraries. The following is a collection of thoughts, opinions, and advice for defining component APIs that are meant to be more flexible, composable, and easier to understand. None of these are hard-and-fast rules, but they’ve helped guide the way I think about organizing and creating

Reactで組んでる中で、読みやすいコードを書くにはこうしたらいいよというものを紹介します。 よかったらツイッターフォローしてください🙏 https://twitter.com/hmktsu