フロントエンド開発は混乱する

今回はフロント寄りのお話です。

昨今、フロントエンド界隈ではいろんなライブラリやツールが出てきており、新しく学ぼうという人は何からやればいいか見当もつかないということが多いように思います。
「そもそもjQueryがあればええやん」とか「ツールの使い方覚えるの面倒やな」といった方も一定数いると思います。
私が本格的にフロントエンドで開発するようになったのは今年に入ってからですが、この数ヶ月で数えきれないほどのライブラリやツールの名前を聞きました。
ですが今、個人開発で使っているのは片手で済む程度なので、結局は環境や技術レベルなどの制約で随時必要なものを覚えていけばいいんじゃないかなと思っています。

ということで本題です。
今回はあくまでも概要の説明なので、気になった方は私のGithub・Bitbucketを参照いただくか、直接ご質問いただければよいかと思います。

npm (https://www.npmjs.com/)

Ruby→「gem」、PHP→「composer」、Python→「pip」、Java→「Maven」、C#→「NuGet」のようなイメージです。
必要なパッケージのインストールと、依存関係を解決するためのツールですね。
こいつが無いと開発が始まらないと言っても良いぐらい、よく使われています。
基本的にnode.jsで開発する際のパッケージを管理するためのものですが、フロントエンド開発にもそのまま使えます。
似たようなものにbower(https://bower.io/)というツールもあります。

Sass (http://sass-lang.com/)

CSSメタ言語と言われるものです(lessやstylusも同様)。
通常のCSSではできないクラスのネストや変数定義・条件分岐などを含めて記載することができ、作成したファイルをCSSファイルに変換するというものです。
先のnpmパッケージに「node-sass」というパッケージがあり、以下のようなコマンドを実行すればsassファイル保存時にCSSファイルを自動生成してくれます。

「-w」がwatchするためのオプションなので、これをつけなければコマンド実行時点の対象ファイル変換のみ行います。
「-o」はファイルの出力先を指定しています(他にもオプションがあります)。

webpack (https://webpack.github.io/)

一言で言うと、「いろんな生成物を指定に乗っ取ってまとめてくれるすごいヤツ」といった感じでしょうか。
例えば開発時に機能単位で分けたファイルを、実運用時のために「難読化」して「1つのファイルにまとめる」といった作業でもコマンド一発でやってくれます。

これも「node-sass」同様、ファイルの変更を監視するオプションがあります(-w)。
他にも「–colors」で出力に色を付ける、「–progress」で処理経過を出力するなどオプションが豊富です。
細かい設定は「–config」で指定したJSファイルに記載します。

gulp (http://gulpjs.com/)

開発時のルーチンワークやファイル監視などのタスクを実行するためのツールです。
webpackは複数ファイルを適切な単位でまとめる(変換する)といった作業が中心になりますが、こちらはタスクランナーに特化したツールです。
jsファイルにタスク単位で細かい作業を書いておけば、コマンド一発ですべてやってくれます。
gulpfile.jsにタスク「watch」を定義しておけば、以下で実行できます。

先のnode-sassでは入力ファイルが1つなので、複数のscssファイルを1つのファイルとして出力する場合や複数ツールを関連付けて1つのタスクとする場合に便利です(連携パッケージも多いです)。

babel (https://babeljs.io/)

モダンなフレームワークやライブラリだとes2015というJavascript仕様に則って開発することが多いですが、これは現状のブラウザでサポートされていない機能も多くあります。
これを解決するのがbabelです。
設定ファイル(.babelrc)を書いておいて、webpackやgulpとセットで使うことが多いです。

色々書きましたが、正直「こんなにツール使わなあかんならjQueryでええやん」と思いませんか。
半年近くフロントエンドに関わっていた私もほぼ同感です。
少人数での開発やクラス・モジュール設計が適切にできるようなケースではせいぜいnpmとsassだけあれば良いと思っています。
ただ、jQueryは簡単に機能が実装できる反面、テストや保守フェーズで影響が読みにくい部分が多いです。
es2015やタスクランナーを使うとブラウザで動作確認するまでにいくらか手間がかかりますが、そのあたりは開発・保守のしやすさとトレードオフかなと思っています。

結局のところ、プロジェクトに合わせて必要なものを取捨選択すればいいということに尽きますが、開発時の検討材料にしていただければ幸いです。
次回はvue.jsについて書きます。

↓当サイトのドメインは以下で取得しました。

CakePHP3で「.env」を使う

世間一般に言われる「ゴールデンウィーク」も今日が最終日ですが、皆様いかがお過ごしでしょうか。
ちなみに、私はずっと開発に集中していました。

さて、今回はCakePHP3で.envファイルを利用する方法についてここに記載しておきます。
Laravelではプロジェクトルートに「.env」ファイルを配置し、その中に設定した値を利用して環境菅野差異を吸収するという手法が取られています(このファイルはバージョン管理外とします)。

Javaを長くやってきた私は、アプリケーションサーバに設定する手法を主に使ってきたので、PHPのWebアプリで使う環境変数はすべてApacheに指定していました。
ただ、最近Webサーバをnginxに変えた際、環境変数の設定に手こずり、あげく「ほんとにこれで良いのか?」となっていました。
アプリ単位で管理するのならそれが良いのかなと今では思っていますので、同様のことをCakePHP3でも実施したというのが今回の対応です。
※ソースはこちらにもあります。

ファイルの配置

まずはプロジェクトルートに「.env」を配置します。
今回はini形式にします。

設定読み込み処理追加

リクエスト時に読み込まれるファイルに以下を記載します。
※今回私は「paths.php」に記載しましたが、「bootstrap.php」のほうが良いと思います。

これで、コード上で「.env」に定義したファイルを読み込むことができます。

ちなみに、より柔軟に対応できる「PHP dotenv」というライブラリもありますが、今回はファイル名固定かつ最低限値が読み込めればよかったので、上記対応としました。

↓当サイトのドメインは以下で取得しました。

mixにしてみる

お久しぶりです。
今回は以前苦戦したlaravel-elixir → laravel-mixにした際の手順を記載します。
同じように苦戦する方が出ないことを願って、かつ自分が忘れないためのメモです。

なお、laravel5.3以前 → 5.4以降へのアップグレードを検討している人向けです。
laravel自体のアップグレードはこちら

最近、フロントエンドはタスクランナー中心の開発が増えてきました。
laravelでは、これまでlaravel-elixirというパッケージを利用してscssやes2015・JSフレームワークの監視・公開ファイルへの変換を行っていました。
laravel5.4にて、上記に代わってlaravel-mixというパッケージが利用されるようになりました。
これまで内部的に利用していたgulpを利用せず、webpackの機能で変換処理を行っています。

手順

1. laravel-mixをインストールします。

※注意点
laravel-mixは以下を参照し、できるだけ最新のバージョンを利用してください。
古いバージョンだとsassの変換や圧縮が動作しないことがありました。
https://github.com/JeffreyWay/laravel-mix/releases

2. larave-elixir(とあれば関連パッケージ)をアンインストールします。

3. package.jsonにnpm scriptを定義します(既存のdev、prodは削除してください)。

4. package.jsonと同じディレクトリにwebpack.mix.jsを生成し、gulpfile.jsを削除します。

基本的にはこれで動作します。
個人的には、デフォルトでvuejsやreactを利用できるのはとても良いなと感じています(そのぶん依存ライブラリがとても多いですが)。

↓当サイトのドメインは以下で取得しました。

Djangoを利用してアプリを作る

以前も少し書きましたが、C#とASP.NETで作成していた自分用の「レシピ管理システム」を、現在Djangoで作り直しています。
※リポジトリはこちら

DjangoはPythonで作られたフルスタックフレームワークです。
よく言語比較をされるRubyではRuby on Railsが有名であり、そちらのほうが巷では人気がありますが、
昨今の機械学習ブームも手伝ってPythonという言語自体はとても注目されています。

以前バッチ処理でPythonを利用していた私としては、せっかくなのでWebアプリも作ってみようということで挑戦することにしました。
ただ、Djangoに関する文献やドキュメントは英語が多く、最低限動作させるのにも結構苦労しましたので、今後Djangoを学ぶ方の役に立てばいいなと思いこの記事を書きます。

ちなみにチュートリアルは基本日本語ページですが、半分ぐらいは英語ページのままだったりします。

プロジェクト≠アプリケーション

他言語でWebフレームワーク利用経験があると、まずここで混乱します(私もそうでした)。

たとえば「CakePHP」の場合、以下コマンドでアプリケーションを作成して、それをそのままプロジェクトとして利用します。

先ほどあげた「Ruby on Rails」も同様です。

Djangoの場合、プロジェクト内で機能や用途に応じてアプリを分けるという方針で開発することになります。
最近のソーシャルゲームだと、ユーザ情報、イベント情報、手持ちのキャラクターなどはすべて別アプリで、それらをまとめて1つのプロジェクトとして管理するようです。
※ここらへんは、作成中のレシピ管理システムにはまだ反映できていません…。

プロジェクト作成

アプリ作成

利用する主なファイル

他のフレームワークであるような「MVC構成」とは少し異なります。
作成したアプリで以下のファイルが配置されますので、それぞれの中で一括管理するようです。

  • urls.py…ルーティング関連
  • views.py…コントローラ関連
  • models.py…モデル関連

urls.pyは、デフォルトではプロジェクト・各アプリそれぞれにあります。
プロジェクトのurls.pyではパスを各アプリへの振り分けを行い、各アプリではそれ以下のパスの振り分けを行っています。

以上、ひとまず基本部分でした。
テンプレートでのヘルパー利用やモデルの設定についても触れたいのですが、それは次回以降にまわします。
興味を持っていただけた方は、まずは上記Bitbucketのリポジトリをご覧ください。

↓当サイトのドメインは以下で取得しました。

サービスはリリースしてからが勝負

以前、健康診断で引っかかったことをきっかけに、自分用にレシピをまとめるサイトを作成しました。
その当時興味があったASP.NET(C#)で作成したのですが、サーバとして利用しているUbuntuへのデプロイが面倒だったこともあり(当時はMonoもそこまでメジャーじゃなかったので)、あまりメンテナンスできておりませんでした。

そして最近、これをPythonで書き直そうとしています。
Pythonは以前からバッチ処理で利用していたのですが、Webフレームワークとして利用してみたかったということと、今後様々な分野で活かせそうだという期待を込めて本格的に学習することに決めました。

フレームワークには一番メジャーなDjangoを使っているのですが、日本語のドキュメントがほとんどないのでかなり大変です。
困ったときは以下のリファレンスを参照するようにしています(日本語用のページですが、英語のままの部分も多いです)。
Django ドキュメント

1つのプロジェクトに複数のアプリがぶら下がるという構成にはまだ慣れないですが、フルスタックフレームワークということもあり開発は比較的スムーズに進んでいます。
まずは3月中に運用開始できることを目標にしています。

次回はこのDjangoを使った基本的な開発について触れようと思います。

↓当サイトのドメインは以下で取得しました。