フロントエンドの段階的モダナイズ、のための自走設計 (株式会社スタディスト様)
株式会社スタディスト様の依頼で、フロントエンド傭兵として、Rails 内の巨大SPA の段階的なモダナイズの提案を行った事例紹介です。 いつもはパフォーマンス視点で仕事にかかるのですが、今回はマクロな設計視点でソースコードを読んでいきます。一旦は中期ゴールを提案しつつ、その作業の必要性を通して、なぜその変更が必要なのかという解説をしていきました。 コスパが良い部分からやりたいですね。でもコスパ感覚は人それぞれです。あくまでフロントエンド専門家の自分が優先度付けるなら、という観点でやっていきます。 今回の仕事にあたっていくつかの技術的な課題を取り上げますが、それはスタディスト様に問題があるという話ではありません。むしろ問題を修正しようという意思が強く、実際1ヶ月の期間中にいくつかの修正をマージすることもできています。 以下、敬称略。注意点として、今回の内容は中の人達が見返すための記述が多いの
Vue.js設計地図 〜設計概念の依存関係からフロントエンド設計を見つめ直す〜
こんにちは。PLAID Software Engineer, tai-hey ( @Victoria_Peak_ ) です。 まえがき 私はプレイドに入社して1年ほどとなりますが、業務で Vue.js の開発を経験し、自身がフロントの実装にメインで携わり、サービス設計から実装まで取り組む中で設計について思慮することが多くなりました。 プレイドは SPA を実現可能な Vue.js を採用しているのですが、設計をしていく中で、設計のヒントをネット上で検索をしてみても、チュートリアルや部分的な設計の話はでてくるものの、設計概念の依存関係を表すものが無いことに気づきました。 そこで、今回のブログはフロントエンドに関連する設計概念を整理し、それぞれの依存関係を可視化することで今後のスムーズな開発に役立てるべく考察したいと思います。 プレイドでは、会社として開発プロセスを具体的に定義しているわけでは
メンテナンスしやすいVueComponentを設計するために気をつけていること
はじめに VueをつかってWebアプリケーションを実装するとき、Componentをどう切るかって誰でも一度は悩みますよね(悩みますよね？)。とりあえず思いつくままに切ってみたり、繰り返し使いそうなもので切ってみたり、CSSのスコープで切ってみたり…。いろいろな切り口があると思います。 この「いろいろな切り口」でコンポーネントを切ることができる点が、コンポーネント設計を難しくしている所以だと考えています。 そこで今回は、どのような切り口・観点でコンポーネントを切ればよいのか、そのときに気をつけるべきことは何か、といったComponentの設計方法についてまとめてみます。 すべての実用ケースを想定できているわけではないと思いますが、大小いくつかのWebアプリを開発する際に利用してみて今のところいい感じに運用できている方法です(というか自然と収束して出来上がった考え方という感じです)。 はじめ
同僚のコードレビューでこんなにクラスの設計が良くなったという話 - Qiita
弊社では、案件とは関係のないプロジェクトでも業務時間中にみんなにコードレビューを依頼できる時間が確保されています(参加は任意)。案件のコードレビューを依頼したり、ちょっとした個人の制作物を見てらったりと使い方は色々です。 先日、TypeScriptの練習にQiitaのAPIを叩いていて記事を表示するブログウィジェットを作成しました。このウィジェットのレビューを依頼したところ、クラスの設計について具体的な指摘と、それに対する改善を経験できたのでこの記事に記載します。 今回作ったQiitaWidgetの要件 Qiitaの公式APIV2から記事とユーザー情報を取得し、HTMLテンプレートに表示する 投稿の合計いいね数を算出するために、あるユーザーの投稿を全件取得する (このために複数回リクエストの送信とレスポンスデータの結合を行う) パラメータによってユーザー、いいね数によるソート、表示件数、ラ
さいきんReact, Reduxでやっている設計 - しゅみは人間の分析です
はじめに ブラウザでGUIアプリケーションを作らなくても良い牧歌的な時代は終わりつつあります。個人的な意見としてはブラウザはドキュメントビューアのままでいて、複雑なGUIアプリケーションはネイティブアプリケーションとして実装されてほしいのですが、そうは言ってもお仕事で人間にとって負担の低いUIを作っていく必要があるのです。 Railsでサーバアプリケーションを書きつつ管理画面はネイティブでなんてことはコスト的に実現できません。かといって長期的に運用されるシステムを作ると、システムを運用するためのUIが操作しやすいに越したことはありません。Bootstrapを使っててきとうなフォームを並べただけの画面を作って怒られた経験はありませんか？ たとえサーバ開発者だとしても、我々は使いやすいUIを求め続ける必要があります。 react, redux 複雑なGUIを作るためのフレームワークも乱立の時代
JavaScript Url DispatcherとかRouterについて調べた
あるいは kanazawa.js v1.0.1 勉強会 : ATND に参加してきた。（前回と同じパターンの使い回し） なぜdispatcher（あるいは router）か実はピンときてなかったけど、なんかこういう手法があるっぽいということだけ知ってた。 pixiv Tech MeetingでpixivのJSの話をしました から辿れるスライドを見てなるほどなと思った。自分がいちばんなるほどと思ったのは WAFの不自由さ というか layout ファイルの <script> を可変にできるように仕組み用意していちいちそこに何か文字送ったりするのってめんどくさいよねというか、要するに script loading も DRY に ってことじゃないかな。もっかい整理すると layout ファイルで JavaScript のライブラリの読み込みは共通にできるでも layout ファイルの中に手を出
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
