Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

弊社は今週はハックウィークといって通常業務止めて周辺ツール作ったりいつもはできないことをやる週として割り振られている。(その割には昨日Contributionの計算の変更とかリリースしてた気がするが) それで仕事で使ってた browserify_rails が遅すぎて辛かったので、趣味でいつも使ってた watchify をRailsにインテグレーションするgemを作ってみた。 はじめて作ったgemなんで手加減して https://github.com/increments/brwy_rails 。 brwy は browserify_watchify_rails が長すぎて略したけど意味わからん気がする。 watchify とは browserifyと違ってコンパイル後もコンパイラプロセスが中間状態を保持したまま常駐して、依存のファイル監視して差分ビルドを行ってくれる。仕組み知ってたら速く
最近、今まで色々と書いてきてた WebフロントエンドUIの 各モジュールファイルをあらかた書き換えた。別に機能を増やしたりしたわけでないんだけど、最近の JS のモジュール化の動きで今までの方針でもモダン(って良い方があってるかどうかは知らんけど)な方針も使えるように変更したので、その経緯とか結果とかを残しておこうと思った次第です。 今までの書き方は基本的にプロジェクト毎にユニークなグローバルのオブジェクトを作ってそこに各UIのオブジェクトをプロパティとして生やしていくという多分それなりにスタンダードだった方針を取ってた。 これがここ数年でガラッと変わったのでそこら辺についてまず。 JavaScriptにはモジュール化の仕組みがない そもそも、JavaScriptにはコードをモジュール化してそれを必要な際に呼び出して使用するような仕組みが言語仕様として存在しない。 よほど小さいプログラムで
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 昨年の途中からちらほら耳にするものの、まだ「なにそれ美味しいの?」なRollupですが、馴染むと手放せなくなる感じ。どんなものか、使い方から、プラグインのつくりかたまで、概観してみたいと思います。 Rollupって何? 複数ファイルに書かれたJavaScriptを、モジュールなどを読み込みつつ、ひとつのバンドルにしてくれるツール。WebPackとかBrowserifyみたいなやつです。依存モジュールの解決や、AltJSのプリコンパイルしたり、など。大きな特徴として、次の点がよく挙げられます。 生成ファイルが小さい ES6(ES2015)
React初学者のためのガイドで著者のPete Hunt氏がオススメしていたwebpack入門を和訳しました。 意訳が含まれるため、誤りやより良い表現などがあればご指摘頂けると助かります。 原文:https://github.com/petehunt/webpack-howto Webpack入門 このガイドの目的 これはwebpackで物事を成し遂げるためのクックブックです。インスタグラムで実際に使用されているものをほぼ網羅した実践的な内容となっています。 私からのアドバイス:まずはこれをwebpackの参考資料として手元に置いて始めてみましょう。公式ドキュメントは理解を深めるために後で参照することにしましょう。 前提条件 browserify、RequireJSまたは類似したものを知っていること 下記のいずれかに価値を見出していること バンドルの分割 非同期ローディング 画像やCSSの
Browserify使いはじめてしばらくたって、自分なりのコツがつかめてきた気がするのでまとめてみます。 まず今回のコンテキストとしては画面遷移をそれなりに含み、同じモジュールを各画面で使う前提。 SPAだとちょっと考え方が変わるかもしれません。 【対策以前】全部をbundleすると太る Browserify覚えてしばらくは、ページ毎の実行部分も含めてbundle.jsにひとまとめしてたけど、各ページ共通部分があるにもかかわらず別ファイルになってしまい、ブラウザキャッシュも生かせず、ファイルサイズも肥大化して微妙だなぁと感じていました。ビルドも毎回でgulpタスクも重くなりがちでした。 共通部分も別々のファイル ブラウザキャッシュ活かせない ファイルサイズ肥大化 ビルド重め ファイル配置例 . ├── node_modules │ ├── knockout │ └── unders
仕事でgulpを使って僕がよくいじる一部のjsを高速でビルドできるようにしてみたのだが、JSをいじらない人の手元でなにかと差分がおかしくなったり、ビルドするタイミングを伝えないことで問題起きたり、その為に呼ばれて治すのがとにかくめんどくさかったため、思い切ってすべてのビルド工程をbrowserify_railsとbrowserify-incrementalと(そのtransform)に押し込んで、gulpを排除してみた。 そんで、browserify_rails は導入しただけだと嬉しさがあまりないので、スクリプトを書いて一気にcommonjsに置き換えることにした。 browserify_rails に関してはhokacchaさんの記事が便利。 モダンJavaScript開発環境 on Rails - クックパッド開発者ブログ 脇道にそれるが、僕は最初、これをbrowserifyを模した
この記事では、Rails や PHP といったサーバーサイドのプログラミングをメインでやっている人向けに Vue.js を用いた簡単な TODO 管理アプリを作るまでを、2回に分けて解説します。 なお、著者の作業環境の都合上、Mac OSX を対象として記事を執筆しています。 1回目では、Vue.js を用いたアプリのモダンな開発環境構築について説明いたします。 Vue.js とは? Vue.js は「リアクティブなデータバインディング」と「コンポーネントシステム」に主眼を置いたフロントエンド向けの JavaScript ライブラリです。 最も簡単な vue.js の始め方 (script タグで vue.min.js を読み込む) jQuery やその他のライブラリと同じく、 Vue.js もスタンドアロンで動くファイルをて異様してますし、 CDN にて配布もしています。 あなたの HT
以前書いた記事で Browserify の使い方とか Browserify でやりたい事が分かったと思う。 では実際に Browserify を使って今までに書いたコードを Browserify 用に書き直してみる。 といっても大したことはない。1つのオブジェクトなり関数にまとめるだけで良い。 例として、よくあるスムーススクロールのスクリプトを挙げる。 $(function(){ $(".anchorlink").on('click', function(e){ e.preventDefault(); var href = $(this).attr("href"); var speed = 500; var easing = 'swing'; var target = $(href == "#" || href == "" ? 'html' : href); var animatePara
はじめに browserifyは、CommonJSスタイルで書かれたJavaScript (Node.js)のコードをクライアントで実行可能な形式に変換するライブラリです。ここではbrowserifyがビルドの際に用いているbrowser-packが、与えられたコードをどんなコードを出力するのかを見ていきます。browser-packのバージョンは6.0.1。 入力 Readmeにある以下のjsonを試してみる。この形式はちょうどmodule-depsの出力結果と同じもので、browserifyも内部でmodule-depsを利用している。内容は 各モジュールを一意に指すID コードの本体 各モジュールが依存する(内部でrequire()を使って呼び出している)モジュールのパスとID そのモジュールがエントリポイントかどうか の4種類。 (function outer(modules, c
JSをやっていると日々いろんなフレームワークやらツールに出会いますが、 それを人に口で話すときに読み方をなんて読むのかわからなくて変な汗をかく時がたまにあります。 最近、読み方がわからなかった言葉がこれです。 Browserify 私はリアルで人とBrowserifyについて話すことがないので、 口にだすことがありませんでした。 しかし、最近チーム内でBrowserifyを導入することになったので、 Browserifyを口にださなくてはいけなくなりました。 他のメンバーはBrowserifyを知らないのでなんて読むかも当然知りません。 こうゆう状況は、自分が間違えた読み方をしてしまうとみんな間違えて覚えてしまう可能性があります。 うかつに変な読み方をした時の罪は重いのではないかと思います。 そこで私がとった行動を書いておきます。 既存の英単語から名前がとられているか調べて見る。 wiki
gulpでwatch中に、何かしらエラーが発生した場合、通常watchもろともgulpが終了してしまい、もう一度watchをしなくてはならなくなってしまいます。 これが何度もあると非常にストレスが溜まって体に良くない。 ここで便利なのが、gulp-plumber。こいつを用いることによってエラーをした後もwatchが止まらないで済みます。gulp-notifyというやつを入れると通知が出てさらに便利になります。 しかし、browserifyでjsをがっちゃんこさせるときに、jsがおかしいとplumberでもエラーを制御することが出来ませんでした。 gulp-starterで解決 gulp-starter 上記ファイル内の、 gulp/util/handleErrors.js var notify = require("gulp-notify"); module.exports = func
このプロジェクトは以前のプロジェクトにmochaとReactの対応、自動ビルド時間短縮を施した置き換え版です。 GitHubへのリンク 概要 このプロジェクトは、AltJS(TypeScript & CoffeeScript) & Browserify & mocha & React構成の雛形プロジェクトです、以下の機能を持っています。 TypeScript、Browserifyの差分ビルド gulp.watch、Watchifyの変更監視による自動ビルド TypeScript、CoffeeScriptのソースファイルを混在出来る ファイルごとに型が欲しいか、短く書きたいか、で好きな方を選べばいい CoffeeScriptで書いたクラスをTypeScriptでrequireして使う、等 ※当然ですが、型チェックをするならTypeScript同士じゃないとダメ mochaによるテスト また、
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに HTML5でのアプリケーション開発は、エンタープライズ向けアプリケーションでも当たり前のようになってきました。これはSalesforceにおけるアプリケーション開発でも同じです。 Salesforceでのアプリケーション開発はVisualforce/Apexで行うというのが数年ほど続いてきたので、HTML5つまりJavaScriptを主体とするアプリケーション開発にはなれていないベンダーも多数あるかと思います。自分は創業当時からJavaScriptでのSPA(Single Page Application)をメインプロダクトに
こうやってるだけでも出力されたhtmlにはscriptタグが30個ぐらいならんでて、ページの読み込みに10sec以上かかる。 だけど、単にapp/assets/javascriptsをgulp watchとかはしたくない。 なぜならビルドはブラウザのリロード時に変更がある場合だけして欲しかった。 あとwindow.AppNamespace以下にモジュール追加していくのも辛い。 モジュール同士の依存関係もよくわかんないし、何よりwindow.AppNamespace.Modules.UserList.ItemViewとか長すぎ! browserify-railsってやつ使ってみた browserifyがrailsの仕組みの中で動くようになる。 browserify-rails/browserify-rails https://github.com/browserify-rails/brows
スライド 当記事は以前勉強会でLTしたものです。 スライドは下記にあります。 フロントエンド覚えること多すぎ問題 モダンなフロントエンド開発で、入門記事を探そうとすると、 まずwebpackやTypeScript, Babelによるビルド環境構築から始まる記事が多くヒットします。 ですが、Node.jsの初心者がいきなり複数のツールを習得しようとすることが 挫折の原因になっていると感じています。 ですので、まずNode.jsをインストールした直後から、必ず使うことになる、 npmの機能をまず覚えておきましょう。 フロントエンド開発で覚えるべき3つのコマンド 以下の3つだけ覚えておきましょう。 npm init npm install npm run これだけ覚えれば、ひとまずフロントエンド開発を進めることができます。 完璧なワークフローを構築するのは、書いているアプリが大きくなってきてから
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 思い立ったが吉日ということで、プロジェクトのモジュール管理をRequire.jsからBrowserifyへと移行し、その直後にWebpackに移行しました。もうちょっと考えてツールを選ぼうと思います。 さて、Require.jsからBrowserifyへ変えた理由は、シンタックスをCommonJS的に書けるようになって、全体がシンプルになるから、という理由でしたが、BrowserifyからWebpackへの移行は、もうちょっと切ない理由での移行になりました。 Webpackとは ドキュメントも若干わかりづらいですが充実しており、基本的に
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く