bowerを窓から捨てて、全てbrowserifyで管理へ移行

先日、bowerから依存関係ツールをbrowserifyへ移行しました。
一気に移行するのはあれだったので、段階を経て、debowerifyというbowerでインストールしたものを、browserifyでできるツールを入れてみました。

ただ、まぁ必要ないよね。。
ということになりまして、今回bowerで入れたものを全て、browserifyで管理するようにしてみました。

bowerはbower.jsonに書かれたフロントエンドのjavascriptモジュールを管理してくれるツールです。
これからはフロントエンドだぜぇぇって騒いでる僕はとりあえず導入しておけと、導入していました。

ただ、nodejsのデフォルトのモジュール管理ツールであるnpmをプロジェクト毎に管理する場合は、package.jsonで管理します。

これをフロントエンドでも使えるようにしてくれたbrowserifyを導入したし、
bower使う必要がなくなりました。
bowerでたくさんのモジュールを管理している人は、また考えようなのですが、
僕の場合はundersocreとjqueryのミニマム構成。秒速で乗り換えられると判断して、乗り換えました。

手順

実際のコミットログは下記のPRに全て残ってます。

Npm init by koheisg · Pull Request #7 · koheisg/scaffold-generator

まとめ

まぁ、自分のように小さなアプリケーションだと簡単ですけど。。
大きなアプリケーションだとちょっといろいろ考えないといけませんよね。
ただ、bowerからbrowserifyに移行する場合は、一旦debowerifyを噛ませるというのはありかなぁと思いました。

iTunesオルタナセール来てたやん。。

iTunesのセール来ました。

グレイテストロックヒッツに続いて、オルタナティヴヒッツですよ。

メール自体は4/9に配信されてました。

 

今見てるところだと、この間紹介?したレッチリのカリフォルニケーションとかバッチリ入ってますね。

これはこれはオルタナ世代には、かなりガッツンとくるセールだ。。

アップルストアへのリンク

browserifyを使ってみた。

あんまりjavascriptに詳しくない人間が、jqueryとunderscoreで scaffold generator(railsのscaffoldコマンドをブラウザから作成するSPA)つくったのですが。。 イマイチいまどきのjavascriptぽくなっていないわけです。 テストも書きたいし、reactとかもやっってみたいし、、 やりたいことはいっぱいあったのですが、まず依存管理ツールを導入するべく requirejsを導入してみましたが、browserify のが良いというのを聞きしました。

@koheiSG mocha + power-assert なら全力でサポートできますぞ (あと RequireJS よりは browserify がおすすめです)

— Takuto Wada (@t_wada) 2015, 3月 15

※ twadaさんがmochaとかpower-assertと言ってるのはテスト書きたいとかも言ってたからです。いやぁ、全力でサポートいただけるようにちょくちょくやっていかないと。。 というわけで、browserifyを導入していきます。

導入方法

まずは、なにはともあれ、browserifyをインストールします。

$ npm install -g browserify
$ npm install debowerify

そして既に、モジュール管理は全てbowerを使用しているため、debowerifyもインストールします。 browserifyでは、requireを書くだけで、簡単に依存関係が解決できます。javascript以外の言語みたいですね。まぁnodejsでは当たり前の話。

$ = require('jquery');
_ = require('underscore');

このように記述します。 そのあと、browserifyコマンドで行います。-tオプションでdebowerifyを指定します。

$ browserify -t debowerify app.js -o bundle.js

エラーなく完了したら、bundle.jsができています。 現状のHTMLはこんな感じでbowerで入れたモジュールを全て読み込んでいます。

<script type="text/javascript" src="./bower_components/jquery/dist/jquery.min.js"></script>
<script type="text/javascript" src="./bower_components/bootstrap/dist/js/bootstrap.min.js"></script>
<script type="text/javascript" src="./bower_components/underscore/underscore-min.js"></script>

これらを全て削除して、下記に一元化します。

<script type="text/javascript" src="./bundle.js"></script>

これで完了です。 今回のソースの変更履歴は こちらのPRで確認できます。

requirejsとの比較

requirejsは日本語の情報も少なくて、すでにbowerで導入したscaffold generatorでは導入するのに手こずりました。(といっても、導入したのが結構前で何にはまったかは忘れた) browserifyも同様に日本語の情報はまだまだ少ないのですが、DSL的なことを書かなくていいのですっきりしていますね。

browserify init by koheisg · Pull Request #6 · koheisg/scaffold-generator Requirejs by koheisg · Pull Request #5 · koheisg/scaffold-generator

この2つを比べると非常にわかりやすいですかね。 require.config みたいなものを書かなくて良いのは、非常にbrowserifyの強みだと思います。

会社の評価の話

僕は多分年の割りにはいろんな会社を経験してる方で、プログラマにしてはいろいろな会社と取引したりプロジェクトを進めて来たりしてきました。

あの会社はだめだ。

とか

あの会社はいい。

直感的に、感じることがあります。

もちろん、みなさんも感じたことありますよね。
それはずっと同じ会社にいる人も感じたことあると思います。

上司や同僚もあの会社はあんな感じだから、、

こうしといた方がいいとか、ああした方がいいとか、アドバイスしてくれます。

これが、いわゆる会社に対するざっくりとした評判ってやつですね。

いろんな会社を渡り歩いているとは言え、狭いIT業界なので同じ会社が取引会社に含まれていることもあります。
そうすると、以前の職場でのその会社に対する印象が刷り込まれてるわけです。

例えば、以前の職場でいい印象がなかった会社があったとします。
そうすると、「あー、この会社はああだからなー」と思ってた矢先に。。

上司から「この会社とはすごいいい関係値が築けてるから、それは崩したくないんだよねー」

「え?◯社が?」 と思うわけです。

でも、意外とこういうことってあるんですよね。

会社の評価は視点が変われば、全然異なります。

まとめ

会社の立場が変われば、会社の評価も変わります。
だから、自分のベストを尽くして、可能な限りいろいろな取引先とWin-Winな関係値を築いていきたいなぁと思う日々なのでした。

7つの習慣の第4の習慣ですね。


7つの習慣-成功には原則があった!

ピンチの時に環境を変えるのは、逃げでもなんでない

「仕事このままでいいのかなぁ、と思って」

友達から相談を受けました。

端的にまとめるとそう思っている理由は下記でした。

まだ彼女は24歳なので、誰にでもあることを重く受け止めしまってるようにも思えます。

「じゃぁ、仕事辞めちゃえば?」

否定されるのはわかっていながら、聞いてみました。

「でも、それって逃げじゃないですか?」

仕事を辞めることは逃げでもなんでもない

こういう思考回路の人思ったより多いですね。

確かに何もせずにその場から逃げ出すのは逃げです。

努力して、何かを変えようと挑戦して、それでも結果ダメだったから辞めるというのは、逃げではありません。戦略的撤退です。

例えば、東大を目指してたとします。

でも、受験に失敗しました。

滑り止めの大学に入って何もしないのは逃げです。

しかし、切り換えて大学生活で何かの成果を残そうと努力するのであれば、逃げではありません。

成功させるためにやることが職場を去ることなら、辞めればいい

自分で目標を設定して、努力したのにできないのであれば、環境のせいにして辞めてもいいと僕は思っています。

そんな気合じゃ、何事もできないと思うかもしれませんが、そんなことはありません。

PDCAのCが要

大事なのは環境のせいにするタイミングで十分に考察を行うことです。

なぜできなかったのか、どうすればできたのか。

PDCAでいうチェックですね。

大体、自分独りだとこのチェックができないことが多いです。

僕はコーチングを学んだことで、このチェックを上手にやる方法をいくつか知っています。

記事も長くなってきたので、今日はこの当たりで。

一緒にチェックして欲しいという方は、 twitterまでご連絡ください。