WebPackを使ってRailsからJavaScriptを楽に良い感じに分離する - Qiita
はじめに フロントエンドへスプラトゥーンを決めるために、Rails プロジェクト内で JavaScript を楽に良い感じに分離する方法を考えてみました。 先人たちが様々な方法を提示してくださっていましたが、設定が大掛かりだったり、何種類かのツールを活用したりと、自分にはどうもハードルが高かったため、より簡単な方法を模索しました。 TL;DR Initial commit で、この記事でこれから行う設定をコミットしています。 necojackarc-sandbox/rails_with_webpack 特徴 Sprockets の良い所はそのまま活用 導入ツールは実質 WebPack のみ 設定項目が少なく簡単 おそらくほぼメンテナンスフリー 概要 以下のような流れで、JavaScript のコーディング、ビルド、配信を行います。 frontendディレクトリ以下で JavaScript
現場.fm というフロントエンドの現場について話すラジオを始めた - mizchi's blog
現場.fm 現場.fm https://genba.fm/ 第0回: https://genba.fm/react-vs-angular/ RSS: https://genba.fm/podcast.xml Podcast(審査中): https://genba.fm/podcast.xml mizchi(主にReactの人) と armorik83 (主にAngularの人) でフロントエンドで現場の肌感などを話すラジオです。混沌としたフロントエンドの雰囲気などでみなさんのやっていく気持ちなどをサポートしたいという意図。 Jxck さんの mozaic.fm が未来の仕様とかを話すのに対して、こっちは現場の愚直な話がメインとしています。 Podcast は死ぬほど雑なアイコン(Atomのスクショ)にしたので怒られて再審査かも。 このメンバーの意図 React vs Angular、みんな
リクルートテクノロジーズのフロントエンド開発 2016 - from scratch
前書き このエントリーは Recruit Engineers Advent Calendar の 1日目の記事です。 www.adventar.org リクルートテクノロジーズのフロントエンド開発 リクルートテクノロジーズではいくつもの並行するタスクが走っていて、プラットフォーム基盤と呼ばれる基盤技術開発とインフラソリューションと呼ばれるインフラ開発、後はアプリケーション開発支援などのタスクが存在します。 アプリケーション開発支援の中でもウェブフロントエンド開発は目下のところ重要タスクとされており、色んなやり方をトライアルしています。 基本的には、 React Redux Node.js という組み合わせでフロントエンド開発をしています。 主には以前 ubb.jp というイベントで発表したこの資料に記載されている内容でやっていますが、諸々補足します。 リッチなウェブアプリケーションを作るた
あのライブラリは何故誕生したの?のまとめ - Qiita
はじめに 最近、フロントエンドのライブラリ乱立問題について盛り上がってました。 自分はnobkzさんの以下の文に全てがまとまっていると思います。 僕の最初の違和感は、「技術的な流行り」に乗ることに何の価値があるのだろうか?ということである。もちろん、最新のツールやフレームワークはより何かが良くなってるかもしれない。しかし、 それをあなたのプロジェクトで採用するには何の価値があるだろうか? 「最近のフロントエンドへの違和感 - nobkzのブログ」より 裏を返せば、新しいライブラリの内容、特に「どのような問題を解決するためにこのライブラリが生まれたのか」という思想を把握しておくことは重要だと言えます。 つまりは、 "How?(ライブラリの使い方)" よりも "Why?(なぜそのライブラリが必要なのか)" を学んでおこう ということです。この記事では どのような既存の問題・要求を どう解決して
5年間開発しているRailsプロジェクトにReact + Reduxを導入した話 by Shimpei Takamatsu | Wantedly, Inc.
こんにちは、WantedlyのWebエンジニアの高松です。 このエンジニアブログでも何度かReact関連の話題が出ていますが、WantedlyではReact + Reduxを中心としたWebフロントエンドの技術スタックを導入して開発しています。 今回はスタックの導入方法や勘所について、詳しく解説してみたいと思います。特に既存のRails環境にReactなどの導入を検討していらっしゃる方の参考になれば、と思います。 今回の内容は以前発表した以下のスライドを元にしています。 これまでのWantedlyのフロントエンド開発 まず、今回のスタック導入前のWantedlyのフロントエンド開発がどのようなものであったのかについてご説明します。 Wantedlyの開発リポジトリを参照すると、最初のコミットは2011年9月になっています。現在は社内でもマイクロサービス化の動きが始まっていますが、基本的にW
アーキテクチャよりも設計を重視しよう – 米政府18Fチームの提案 | POSTD
注釈： CASH LAYER：キャッシュレイヤ FRONT END：フロントエンド ASSET SERVE：アセットを供給 WEB SERVER W/ROUND ROBIN FAILOVER：ラウンドロビンとフェールオーバーを実装したWebサーバ THE CLOUD：クラウド ALL READS! ：全ての読み込み WRITES：書く READS：読む MASTER：マスタ INPORTANT POINTY THINGS：重要な鋭い情報 MULTI MASTER DB CLUSTER：複数のマスタからなるデータベースの集合体 「エンジニアはまずアーキテクチャの全体像から始めるべき」、というのが先人たちの知恵からの教訓となっています。データベースを使ったサービスが他のサービスと関係する様子を、線や矢印で表したのが上の図です。キャッシュレイヤ、ロードバランサ、その他の複雑な形も上図の情報フロー
フロントエンドで知っておきたい要素指定の考え方 - pixiv inside [archive]
みなさんはじめまして、ピクシブのフロントエンドエンジニア id:koharusugiura です。 JavaScript を用いた開発を行う際に jQuery や React、vue.js といったライブラリーを使う方は多いでしょう。これらのライブラリーは共通して DOM を扱うライブラリーとなります。 DOM についての説明は長くなるのでここでは省きますが、簡単に説明すると HTML や XML の構造を表現するための仕様です。DOM は JavaScript のためだけにある仕様ではなく、 Java や Python など、多くの言語に対応する仕様です。 前述した各ライブラリーは多くのウェブブラウザー間の差異を吸収してくれるため、非常に便利なものです。しかし、その機能の豊富さからライブラリー自体のサイズは大きく、ウェブブラウザーで読み込むファイルの数や合計の容量が増えてしまいます。状況
![フロントエンドで知っておきたい要素指定の考え方 - pixiv inside [archive]](https://cdn-ak-scissors.b.st-hatena.com/image/square/06141560504fa4e927919dd41de3eab52a11d032/height=288;version=1;width=512/http%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fk%2Fkoharusugiura%2F20151222%2F20151222103513.png)
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
DDDってなんだろう？