今回はGitHubの話。 基本的な使い方は入門書がいくらでも出ているので今更私が解説するまでもないけど、ブランチ運用については腑に落ちるまで少し苦労したので今回は自分流のブランチ運用をメモとして残しておこうと思う。 ガチの開発勢から色々と文句を言わるかもしれないけど、趣味開発なのでご容赦願いたい。 thomの2ブランチ開発フロー 私は次の表の1～8のような流れで開発を進めている。 このブログの読者はExcelマクロ開発者が多いのでバージョン管理システムを使わないExcel開発を例えとして挙げてみた。対比させるとGitでやっている作業が何をしているのか少しは分かりやすいかなと思う。 本来は2～4を繰り返してこまめにdevブランチを更新しつつ、ある程度キリの良いところで充分にテストをしたうえでmasterへ取り込むんだけど、なんせ一人で開発していてユーザーも大抵自分ひとりというケースが多いので

これまでいろんな現場でWebフロントエンド開発をしてきて、メンテナンスしやすく効率の高いWebフロントエンド開発をする上で重要になる考えが自分なりにまとまってきたので記事にしてみます。 Worse is Betterという考え方 自分が見てきた中でWebフロントエンドの開発効率が落ちてしまう一番の要因は、きれいで理論的には優れているアーキテクチャを構築しようとしてそれ自体がもたらす複雑性を支えきれないというパターンです。 少し前にフロントエンドにClean Architecture（以下CA、あの同心円の図を指すのは誤用に近いですがここではそれに乗ります）を導入する記事が流行ったと思いますがあんな感じです。ああいったクラスベースでDIが重要となる設計手法はサーバーサイドのJavaでSpringを使うのとは違ってReactがサポートしているものではないため、CAの実現自体に高い設計スキルが必

確かに、パッと見で 「なんだこれ？」 になりますね。 意味のないコメントとして　else 句ごと削除してしまって良さそうにみえます。 しかし、実はこの「何もしない」コードは、 プログラミング（理論）的に面白い側面を持っている ので、簡単に記事にまとめてみたいと思います（記事中では Swift に似た擬似コードを使用します）。 キーワード if 式、網羅的パターンマッチ、参照透過、副作用、モナドと単位元 else 句が省略できる条件 例えば、次のコード例を考えてみます： let array: Array<Int> = ... var positiveArray: Array<Int> = [] // var = 可変変数 for x in array { if x > 0 { positiveArray.append(x) } else { // 何もしない } } ここでは array か