図解 CSR, SSR, SG(SSG), ISR
何周も遅れてしまっているのですが、フロントエンド周りの勉強に取り組んでいます。色々と遠回りをしつつ、Next.jsに流れ着きました。SSRとかSSGとか分かりにくい言葉が多くて難しそうに感じたので、自分なりの理解を図にしてみました。 Server Side Application サーバーはリクエストを受けると動的にHTML文書を生成して返却する。 1993年にCGIが登場した時から基本的に同じ仕組みであり、今でも主要なアーキテクチャです。 Ajax クライアント（ブラウザ）側のJavaScriptでサーバーから追加データを取得し、DOM操作でページの内容を書き換える。 ページ遷移することなくコンテンツを書き換えることができる手法です。このアーキテクチャが登場してから、Webアプリケーションで実現できるUIや表現の幅が飛躍的に広がりました。 CSR (Client Side Renderi
技術的に難しいことを力技でやってしまうこと - orangeitems’s diary
まあお悩みですけどね、技術的に難しいことってありますよね。で、他のメンバーに任せておくと、いつ終わるかわからない。聞いてもわからんわからんばかりで、こりゃダメだと言う時のことです。 いつものように、それ私が引き取るよ、ってその課題を引き取って、難易度の低いタスクを他のメンバーに任せます。まあそのタスクも大量なので、誰かがやらなきゃいけないし、高度な問題のために大量のタスクが積みあがるのもそれはそれでまずい。適材適所と言えばそうなのですが、本当にこれでいいのかなと毎回思います。 だって、またこの高度な問題に対するトラブルシューティングを見ることなく、メンバーは最終的に「できた」という形を手順書なりなんなりで確認することになります。ああこうやればできたのか、という感動があればまだいいですが、忙しいのでそんなことしている暇は多分ありません。 これ、私はまたスキルを一つ積み上げたのですが、どう考え
堅牢性と変更容易性 - 30歳からのプログラミング
いろいろと考える機会があったので、備忘録としてまとめておく。 システムにおける堅牢性とは何か。 それは、壊れにくいこと、破綻しにくいことだと思う。 では、破綻しているとはどういう状態なのか。 システム全体の複雑さが増していって開発者がコントロールするのが難しくなること。 その結果として、いつの間にかバグが埋め込まれてしまって全く予期しない形でシステムが壊れてしまう、という現象が発生しやすい状態であること。 末期まで行くと、変更を加えること自体が困難になる。何かを修正すると別のところが壊れてしまうという状態になっており、身動きが取れない。 破綻を生み出す原因として何があるか。 頭のなかを整理しきれていないが、思いつくもの。主にフロントエンドの話。 考慮しなければならない要素が多すぎる 状態管理が難しく、複雑性を増している UI（コンポーネントなど）が状態を持っている 様々なコンポーネントが
Dart/Flutterでドメイン駆動設計（DDD）してみた - 導入編 - のんびり精進
カテゴリ別にメモを管理できるアプリの開発を DDD（Domain-driven design）でやってみたものです。 github.com 二つの記事から成り、この記事はその一つ目です。 導入編（本記事） 解決しようとした問題点や、DDD と関連用語の意味の他、モデリング・レイヤ分け・ディレクトリ構成の検討において考えたことなどをまとめています。 実装編 Dart/Flutter での実装を中心としますが、一つ目で触れていない点（集約など）の説明も含みます。 やってみようと思った経緯 何かを作るとき、設計がメチャクチャであっても運良くそれっぽく出来上がることがあります。 小さなものなら直しやすかったり、あるいは問題があまり顕在化しなかったりするかもしれません。 しかし、大きなものでは次第に破綻してしまうことが容易に想像できます。 Flutter でも、小さなアプリを作って学ぶ間は「なんて簡
実践的な設計って、なんだろう？
Devlove 名古屋 2014-5-18 DDD, Object Oriented Design, ドメイン駆動設計 オブジェクト指向設計Read less
SPA フルリニューアル計画における技術選定や設計思想（2019年2月版） - 30歳からのプログラミング
SPA のフルリニューアルを技術選定や設計からやることになった。 前回の記事も、そのために検討や調査を行っている際に生まれた副産物をまとめたものだ。 目指すべきは変更しやすいシステムであり、そしてそれは、堅牢性を実現することで達成されるはずだという結論に至った。 numb86-tech.hatenablog.com 今回の記事では、堅牢なシステムの実現に向けてどんな技術を選んだのかを記録しておく。 まだ検証フェーズというか、試し書きや検証を行っている段階なので、今後変わる可能性はある。 前提 現行のアプリは Rails アプリで、その上に Vue を載せて SPA を作っている。 フロントエンドのビルドは Webpacker 。別のプロダクトでは Webpacker を剥がしてしまったが、このプロダクトでは実現できていない。 ビュー関連の処理について、どこまでを Rails でやってどこか
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
