読者です 読者をやめる 読者になる 読者になる

あおみかんのブログ

フリーランスのIT系エンジニア。ゲーム制作スタジオ4th cluster代表。

最近のWeb開発技術フロントエンド周りのまとめ(2014年)

主に知人向けに、最近のWeb開発技術について、私が最近知る限りの事をまとめておきます。

VagrantとかChefみたいに、おおまかに知っているだけで使ってないものも紹介しています。間違いがあったらコメントを頂ければ訂正しますので、ご指摘下さい。

また、フロントエンドよりの記述が多く、インフラやバックエンドのことには触れていません。

大前提

パッケージマネジメントシステムの有用性

Linuxのサーバーサイドでは当然、パッケージマネジメントシステムが存在しますが、ソフトウェア開発においてもこれは非常に重要になります。

などなど。

こういったシステムを使うことの利点として以下があります。

  • ライブラリの公式の入手場所が辿りやすい
  • どこからどこまでがライブラリか分かりやすい
  • プロダクト特有のコードと、ライブラリのコードが分離される
  • ライブラリのバージョンアップがしやすい

相互に重複気味な表現もありますがご容赦。

Rails界隈の知識です

もしかするとTomcatなどから進化した界隈ではまた別の最適化があるかもしれません。 .NET界隈もVSでBootstrapが使える様になったりしてるらしいので、色々あるようです。 node界隈にも僕は詳しくないです。 PHPは知りませんが、Ruby界隈と割と業界が近いのでそれほど差異がないかRubyより劣る事が多いように思います。

ローカルで開発してリモートにデプロイ

基本的に、近年はローカルで開発して、リモートにデプロイするのが普通だと思います。 その方がGUIベースのIDEも使えるし、本番環境を壊す恐れが少ないからです。

但し、デプロイはセキュリティの観点や、考慮すべき事項の多さから往々にして属人的になりやすいです。詳しくは後述します。

コンパイルする簡易言語たち

アセンブリC言語の歴史をWebが同じように辿っているだけなのですが。
Webブラウザはその基盤となる言語を変更しにくいです。(CPUの命令セットが変更しにくいのと同様) HTML、CSSJavaScriptといったマークアップ言語およびプログラミング言語がそれにあたります。

Sass(SCSS) および LESS

SassとLESSは、CSSを書き出すための言語です。
私は数年前はLESSを使っていたのですが、 @extend が使える点などから、今ではSassに乗り換えています。

簡単にCSSが書けるだけであれば、大きな利便性はないのですが、@extend、@mixinなどの機能と、後述するCSSフレームワークとの相性が抜群です。

CoffeeScript

JSはプロトタイプベースだったり、this問題が起きたり、そもそも言語を問わず非同期処理は難しかったり、DOMが難しかったり、身につけるのが大変な言語ですが、CoffeeScriptは、それを少しだけ楽にしてくれます。少しだけです。

minifyとの相性

css,jsはminifyすることがありますが、セミコロンがないJSとかだと、minifyしたときにバグを生んでしまうことがあります。 上記の言語を使っていると、そういった問題が起きにくいように思います。

リソースをコンパイルするSprockets

Rails3.1に導入されたAsset pipeline(及びベースとなるSprockets)では、js,cssを簡単にコンパイルすることが出来る上、ハッシュ値を利用してキャッシュが有効にならないようにするなどの機能も有していて便利です。

また、上記のパッケージマネジャとの相性も考えられていて、パッケージマネジャで追加されたライブラリをJSやCSSの先頭で指定することで、それらを読み込むようにできます。(require, require_tree)
読み込んだファイルはSprocketsの設定にも依りますが、小規模なサイトであれば1つのJS,CSSに統合してしまうのが良いです。 そうすることで、コストの高い無駄なHTTPリクエストを減らすことができて、サイトの表示が非常に高速になります。

類似: hamlとslim

railsではhtmlコードを吐き出すためにerbという、PHPと似たような形式の、HTMLのRubyのコードを埋め込む仕組みが使われてきましたが、htmlの閉じタグってムダですよね。 ...ということで、最近はhamlやslimといった記法が使われます。

自動リロード

少し前から、自動リロードがアツいように思います。

検証する端末を全てデスクに広げておいて、コードを変更すると全てでリロードされる、なんてのも可能です。

livereload (guard-livereload)とか、Yeomanとか。

特に、HTML/CSSを記述するときはかなり手軽になって良いです。 マルチディスプレイとの相性が良いです。 表示を確認する画面、コードを書く画面、デザインファイルを参照する画面で3画面欲しいですね。 表示の確認はiPadとかのタブレットデバイスでも良いですけど。

ローカル環境の構築とデプロイ

デプロイ

デプロイは一般に面倒です。 ミスったときのロールバックはどうするのとか、変更されたファイルを選んでそれだけアップロードしたいなーとか、上記のコンパイルする言語を先にコンパイルしなきゃなーとか・・・。 で、その状況を放置して行くと、プロジェクトリーダーしかデプロイ方法が分からないといったことになって、リーダーが疲れているときに酷いミスをやらかして大変なことになるわけです。

これを防ぐために、デプロイの一連の処理はスクリプトとして記述するのが最近のトレンドです。
先のパッケージマネジャでライブラリをインストールするような処理もサーバー側で出来るので、直接転送する量が少なくて済む、なんてメリットもあります。

Rails界隈でのデプロイツールはCapistranoデファクトスタンダードです。普通はgitと併用します。

ローカル環境の構築

でもさ、複数人で開発してるときってローカル環境を構築するのが面倒じゃん。だから本番環境でそのまま開発すれば、よくね?

・・・という声が聞こえてきそうですが、一発殴って良いですかね?
面倒なのは事実なんですが、ChefとかVagrantとかで解決するようです。 基本的にはローカルにプロジェクト固有の開発用の仮想マシンを立ち上げて、開発者全員が同じ設定の開発環境を自動セットアップ出来るような仕組みです。 Chefに関しては本番環境で使うことの方が多いかも知れません。

CSSフレームワーク、JSフレームワーク

CSSもJSも、毎回似たようなことばかり書くのに辟易した偉い人達が、さまざまな知見を集約してくれました。昔とは大違いなので、CSSを1から書くとか、もうやめましょう。

CSSフレームワーク

特に有名なのがTwitter Bootstrapでしょう。 バージョン3ではHTML5対応、レスポンシブデザイン対応が行われ、クラス名も以前のrow-fluidといった面倒なのが減って、デザインも含めて以前より洗練されました。
バージョン3になってからは「これBootstrap臭がするな・・・」といった、特有の画面になることが減ったように思います。 トレンドがシンプルな(いわゆるフラット)デザインになっているのも大きいでしょうね。

にわかCSS原理主義者は、Bootstrapを使うとHTMLに直接classを定義するからセマンティックではないといったことを言うかもしれませんが、上記のsassを使うとそういった事はなくせます。自分が独自に定義したclassでextendすれば良いのですね。 尚「にわかCSS原理主義者」というのは過去の私です。。。

短いファイルでもsassのコンパイルに10秒以上かかるのがネックでしょうか。 でも、1から書くよりはやいことが多いと思います。

JSフレームワーク

以前からjQueryデファクトスタンダードとなっていますが、より動的なシステムでは、JSフレームワークが流行っているようです。
特に、変数のバインディングの面倒を減らしてくれる、MVVMアーキテクチャを採用したものが主流です。 Angular.jsとかBackbone.js とかそのへん。

よく動くサイトを作るときに重宝するでしょうね。

bowerを使おう

JS、CSSフレームワークを導入するとき、ついついダウンロードして所定のフォルダに入れて満足してしまいがちですが、冒頭で述べたメリットの裏返しがデメリットとなってしまうわけですね。
なので、bowerを使ってパッケージ管理をしましょう。

rails界隈では、Sprockets周りのサポートなども自動でやってくれるrails-jqueryとかbootstrap-sassとかいうgemが数多く用意されてるんですが、若干ブラックボックスが多くて、一長一短だったり。 Railsアプリを書いてる時はgemベースのものでも良いですが、bowerは他の環境でも使えるので良いです。

IDEもご検討下さい

ぼくはRubyMineちゃん!

vimとかemacsとかで出来るのは分かるのですが、個人的にはGUIによる開発の方が好みです。 環境構築に時間をかける必要が少ない気がします。 まぁ、お金払ってるし。。

おわりに

珍しく早起きしたので、脳内にあったWeb知識を一気に解放してみました。

7年ぐらい前はYahooのYUIが強かったと思うんですが、最近はGoogle,Twitterあたりが便利なものを出してるみたいです。
加えて、Web自体がここ数年で経済的にもかなり発達したので、上記のようなWeb開発をサポートすること自体をビジネスにしている会社も増えた様に思います。 herokuとかその辺ですね。

これからも、Web業界は発展を続けるでしょう。 どんな風になってるか、楽しみですね。