初めてのシステムと日記

システムも日記も初めてです。

MacOS MavericksにLaravelをインストール＆そしてハマった

今まで仕事やプライベートで使っていたPHPフレームワークが古くなってきたため、新しいものを探していました。

2014年2月PHPフレームワークのトレンド - demouth::blog

そんな中、上記の記事でLaravelがトレンドっぽいので試してみる事にしました。

　

ドキュメント

　

環境

　

Composerインストール

Laravelを動かすにはComposerが必要との事なのでインストールします。
インストールに関しては下記ブログを参考にさせてもらいました。

# ダウンロード&実行
$ curl -sS https://getcomposer.org/installer | php

# パスが通っている場所へリネーム
$ mv composer.phar /usr/local/bin/composer

　

Laravelインストーラーのダウンロード

次にLaravelをインストーラーをダウンロードします。

# 公式からダウンロード
$ curl -# -O http://laravel.com/laravel.phar
######################################################################## 100.0%

# パーミッション変更
$ ll laravel.phar 
-rw-r--r--  ***** laravel.phar
$ chmod 755 laravel.phar 

# パスが通っている場所へリネーム
$ mv laravel.phar /usr/local/bin/laravel

　

Laravelインストール

準備ができたのでlaravel_testというプロジェクト名でLaravelをインストールします。

$ composer create-project laravel/laravel laravel_test --prefer-dist

# インストールログが表示されるのでひたすら待つ
・
・ 
・

Mcrypt PHP extension required.
Script php artisan clear-compiled handling the post-install-cmd event returned with an error


                      
  [RuntimeException]  
  Error Output:

怒られました。。PHPライブラリのMcryptが必要との事なのでインストールします。

　

Mcryptインストール

これが一番ハマりました。
デフォルトでMacOS MavericksにはPHP5.4が入っていたのでこれにMcryptを追加します。

# libmcryptインストール
$ brew install mcrypt

# 同じバージョンのPHPダウンロード&インストール
$ curl -# -O http://museum.php.net/php5/php-5.4.17.tar.gz
$ tar -xvzf php-5.4.17.tar.gz
$ cd php-5.4.17/ext/mcrypt/
$ phpize
grep: /usr/include/php/main/php.h: No such file or directory
grep: /usr/include/php/Zend/zend_modules.h: No such file or directory
grep: /usr/include/php/Zend/zend_extensions.h: No such file or directory
Configuring for:
PHP Api Version:        
Zend Module Api No:     
Zend Extension Api No:  
Cannot find autoconf. Please check your autoconf installation and the
$PHP_AUTOCONF environment variable. Then, rerun this script.

2つほど怒られました。。

　

1つはautoconfが入ってないとの事なのでこれもインストールします。

# autoconfのダウンロード&インストール
$ curl -# -O http://ftp.gnu.org/gnu/autoconf/autoconf-latest.tar.gz
$ tar -xvzf autoconf-latest.tar.gz 
$ cd autoconf-2.69/
$ ./configure
$ make
$ make install

　

もう1つは調べる限り、Xcode5のコマンドラインツールが入ってないために起きるようです。
Xcode5になって色々設定方法が変わったようで下記を参考にしました。

# Xcodeのパッケージインストール
$ xcode-select --install

記事を見る限りターミナルからいけるようですが、
私は何故かいけなかったのでdeveloper.apple.comからおとなしくダウンロードしました。。

　

そして再度、Mcryptのインストールをします。

# Mcryptインストール
$ phpize 
Configuring for:
PHP Api Version:         20100412
Zend Module Api No:      20100525
Zend Extension Api No:   220100525
$ ./configure
$ make
$ make install

# php.ini更新
$ vim /etc/php.ini
# extension=mcrypt.so を追加

# 確認
$ php -i | grep mcrypt
mcrypt support => enabled

　

再度Laravelインストール

もろもろ準備が出来たので再度Laravelをインストールします。

# Laravelインストール
$ composer create-project laravel/laravel laravel_test --prefer-dist
・
・ 
・
Writing lock file
Generating autoload files
Generating optimized class loader
Application key [ランダムな英数字] set successfully.

# 確認
$ ls -1 laravel_test/
CONTRIBUTING.md
app
artisan
bootstrap
composer.json
composer.lock
phpunit.xml
public
readme.md
server.php
vendor

　

これでLaravelの開発環境が整いました。Laravel、、というよりMacのPHP周りでだいぶ時間を使ってしまいましたが、環境依存なものがなければすぐにインストール出来るかなと思います。

Developers Summit2014に参加してきた #devsumi

http://event.shoeisha.jp/devsumi/20140213/

デブサミ2014の1日目に参加してきたので、その講演メモになります。

　

■グリーにおけるChef導入事例:荒井 良太さん〔グリー〕

まず会場に質問

  • Chefを知っている→ほとんどの人が知っている
  • Chefを使った事がある→半数くらい
  • Chefを仕事で使った事がある→1/3くらい
  • Chefはまだ仕事で使えていないのが現状

Chefとは

  • サーバ構築、更新を自動化するツール
  • サーバのあるべき姿をRuyで書くとセットアップしてくれる
  • 何度実行時手も同じサーバになる
  • Chef社のOSS

今までのよくある光景

  • サーバ運用者とプロダクト担当者がいる
  • プロダクト担当者がサーバください等の依頼を運用者に依頼
  • 運用者が手順書に沿ってセットアップ
  • 終わったら担当者に報告
  • 何か依頼する度に↑の繰り返し(ルーチンワーク)
  • これを自動化する

導入背景

  • 非効率(ルーチンワーク)
  • オペレーションミスの危険(自動化により安定運用を目指す)
  • リードタイム(サーバのデリバリーを素早く行う）

Before Chef

  • Debianパッケージ
    • サーバの役割毎のメタパッケージ
  • 設定ファイルはスクリプトで生成
    • 初見にはつらいもの
  • 設定値
    • パッケージ内
    • サーバ管理システムに問い合わせ
  • サーバ管理システム
    • 社内サーバ情報を管理
    • 運用スクリプト、ツールが依存している
    • Debianパッケージが依存している

導入方針

  • 新規サーバをChefで構築
    • 既存サーバをChefで更新はリスク
  • 既存サーバ管理システムを利用
    • Chefで構築していないサーバも平行運用
    • 運用スクリプトがサーバ管理システムに依存
    • 運用手順がサーバ管理システムに依存
  • 既存のツール、スクリプトが動く状態で移行する
  • Chef SoloとChef Serverをどっち使うか
    • サーバの台数で決める
    • 複数台あるのでChef Serverを選択
    • 結果的にはChef ServerをやめてChef Soloにした

Chef Serverをやめた理由

  • 単一障害点になる
    • 冗長構成はサポートされてない
  • サーバ管理が重複
    • Chef Serverはサーバ管理の役割
    • 既存のサーバ管理システムと役割が重複
  • 運用

Chef Solo + Chef Bridge

  • Chef Bridge
    • Rubyアプリケーション
    • 内製のChef Server
    • HTTP API
    • サーバ管理システムの問い合わせを行う
    • Chef Soloではattributesで指定しているので変更する必要なし
  • GREE Chef Client
    • Chef Soloのラッパー
    • Chef Bridgeから必要なものを取得(ノード、クックブック、ロール)
    • Chef Soloを実行
    • 自動テスト

クックブック

  • オープンソースなクックブックは汎用的に作られている
    • 結果、複雑になりがち
    • 使いこなすのが難しい
  • 基本的に自社でクックブックを作成

Chef入門

  • Chefは学習コストが高い
  • Chef使いを育てる必要がある

クックブックの開発

■テストを書く

　

■なぜテストを書くのか

  • 開発を後押しする
    • TDD
  • Chefを実行 sshでログイン ちゃんと設定されているか確認 クックブックを修正 繰り返しを防ぐ
  • レグレッションを防ぐ
  • ドキュメント代わり
  • 本番サーバの構築テスト
  • テストが遅い問題は継続改修中..

　

■GitHub PR

  • PRで変更を投げる
  • masterに直接pushしない
  • WIP
  • PR上で議論
  • チャットに通知

　

■継続的インテグレーション

  • JenkinsでCI
  • デプロイまで行う

ノード

  • どのクックブック、ロールを利用するか
  • ノード設定のバリデーション
  • ノードの共通化
    • 複数のノードで共通設定がでてくる
    • YAMLで書く

運用、障害発生

  • Chef以前
    • scriptコマンドやscreenでログを取る
    • wikiにコピペ
  • Chef
    • Report Handlerを利用してログを送信
    • Fluentdに保存

　

公式クックブック使いこなすのが大変とか、Chef-Serverやめた背景とかうんうんと頷く機会が多かったですね、どこも直面する問題は一緒。。。

個人的にはChefのテスト周りがとても興味深い話でした。Chefのテスト書くという概念がなかったのですが、話聞いていて確かにテストが一番必要なツールだなと、話にあがった方法は是非試してみたいと思います。(そしていい加減仕事で使いたい)

※発表資料がすでにアップされていました。 https://speakerdeck.com/ryotarai/guriniokeruchefdao-ru-shi-li-ji-cun-falsezi-chan-wohuo-kasixin-siiji-shu-wodao-ru-suru

　

■フロントエンドエンジニア（仮）～え、ちょっとフロントやること多すぎじゃない！？～:石本 光司さん〔サイバーエージェント〕

https://gist.github.com/t32k/8934355

発表資料がすでにあがってました。

http://rmurphey.com/blog/2012/04/12/a-baseline-for-front-end-developers/ http://slid.es/passy/yeoman/fullscreen#/1/1

確かにフロントエンドエンジニアはやる事が多く、かつそのためのツールもたくさんありますね。 最終的にはやはりGruntに落ち着くのかなーという印象でした。

　

■新卒エンジニア研修ですべきことできること:関口 亮一さん[ディー・エヌ・エー]

世にある新卒研修

  • 必要な情報を浴びせる
    • 新卒てんぱる
  • 研修終わり、突撃
    • 受け入れ側；負担多すぎ
    • 研修ガー研修ガーと研修のせいになる

現状の整理

  • 未経験者がほとんど
  • 出来る人は既に出来る
  • 講師は現場エンジニア3人 + 外部講師数名

教える事

  • もう無限にある
  • 絞ったとしても教えるの難しい

やれる範囲でやるようにしてみる

  • できてない
  • やる前に投げてる
  • 講師：トレンドの技術や知識とかよくわからん

現場のニーズの変化

  • サーバサイドだけやってればいい時代じゃない
  • あれもこれも
  • もっともっと成長してくれないと
  • 研修内容がニーズから乖離

研修自体の問題を整理

  • 技術レベルが求める水準に達していない
    • いいから引き上げる
    • 現場エンジニアが直に教える
    • 今まで研修で棚上げしていたことをちゃんと教える
    • 諦めの連鎖を断ち切る
  • 研修でやってきた知識が現場で生きない
    • 局所的な知識や技術は変化に弱い
    • 知識技術は幅広で奥深い上に流動的
    • 特定なものに絞って教えるのはギャンブル
    • とある状況下でしか使えないような知識、現場固有の事情は極力排除
    • 基本的なことをしっかりと
    • 理想を先に彫り込む
  • 現場で教える時間も暇もないからしっかりやって
    • 勝手に学ぶような習慣をつける
    • 問題を正しく認識し、立ち向かえる力
    • 目先の技術より観察眼、応用力を養う
    • 斜め上に進まないようにする力
    • 技術や知識は水準、本質、応用力の3本柱

研修の目標

  • 自走出来るエンジニア

具体的な研修フェーズ

  • 座学
  • 企画
  • 設計
  • 実装

各フェーズでのレビュー

  • 1回1時間 各フェーズ毎に各ステップ5-7回
  • 新卒と講師の1on1
  • 研修の重要ポイント

レビュー風景

  • ホワイトボード
  • ディスプレイ
  • レビューブース
  • アウトプット
  • インプット

レビューで大事な事

  • 正しく論破する
  • 指摘の仕方や1人1人変える
  • 対面
  • レビューでの出来事や内容を記録

進捗と成長度合い

  • フェーズが進んでくると差がでてくる
  • 未知の領域での対処法
  • 論理の構築
  • 弱点の克服

成長に早めに気づいてあげる

  • 成長を促すために手を打つ
  • より合う形に教え方を調整
  • 強みを延ばして弱点を克服するスタイル

成長を正しく計測する

  • 進捗、レビュー、日報、何気ない会話の内容
  • 全て記録
  • プログラムの筆記テスト
  • 1hのデイリーミィーテイングで活用
  • 徹底したデータ化とPDCA

成長に気がつけたら

  • 改善を促す
  • 最初は自力で
  • 改善してこなさそうであれば手助け(フォローアップ)

フォローアップ

  • 毎日、隔日で30分間の講師との1on1
  • プログラミングのハマり解消
  • 問題解決の手法トレーニング
  • 講師のトレーニング
  • 成長促進のための徹底した振り返り
    • KPT
    • 日々のKを蓄積
    • 成長を実感
    • モチベーションアップ

フォローアップで大事な事

  • 良い所を延ばし良くない所を改善
  • ひとりひとり丁寧に
  • 一筋縄ではいかないのでひたすら工夫
  • 改善したらフォローアップを卒業
  • 最終的に自信をつけさせる

フォローアップのすすめ

  • フォローアップを受けた人は急激に成長する人が多かった
  • 時間が許すなら全員やってよかった
  • ただ自分の弱い面と向き合うのは辛い
  • 無理強いは良くない、一人一人きちんと合ったやり方で進める

まとめ

  • 組織のニーズに応えるのも大事だが変化の激しいニーズに応えるのも大変
  • 基本的な技術力、マインド向上は非常に役立っている
  • 新しい技術も本質的な知識、問題定義力が備わっているので吸収が早い
  • 人にフォーカスする事で人材の柔軟性を高めたら組織にフィットしやすくなる
  • 組織の型にはめて人材を育成するより変化に強い
  • 変化の激しい会社や組織に特に有効な研修
  • 実際の技術的な研修内容 http://www.slideshare.net/DaisukeTamada/perl-26371335

　

今日一番聞きたかった講演、現場のニーズに応えるとか研修のせいにされるとかうんうんととても頷きましたw。

私が研修で一番気にしている事は研修を受ける人たちが自分の成長とモチベーションを感じる事、そういう意味ではレビューやフォローアップはとても良さそうな印象でした。(コストがかかるという問題はありますが)

　

■さくらインターネットブース

講演とは別にブース出展がされていて、さくらインターネットでちょっとさくらのクラウドについて色々お話を聞きました。

私はプレイベートで以前さくらVPS→さくらのクラウドに安いという理由で移行したのですが、AWSと違いサーバがあるだけで(停止していても)課金対象になるため辞めたというのを話してみました。さくらの方もそこは問い合わせも多く、さくらインターネット自体も考えているとの事です。実際、AWSと同じような課金体制にするという話もあるとの事でした。

また、私がさくらのクラウドで良いなと思ったのがコントロールパネルの扱い易さで、そこはユーザからも一番評価されているとのことでした。個人的にはさくらインターネットさんのサポート対応は素晴らしいと思ってるので今後に期待しています。

　

この後にも「何故クックパッドのサービス開発は日々進化しているのか」とか面白そうな講演があったのですが私用のため途中退場、、。明日も組織作りやアプリ周りの講演があり面白そうですが、私はこちらに参加してきます。

発表資料は基本的にアップされるようで、アップされたらデブサミのサイトで告知されるとの事です。

　

追記(2014/02/13 22:00)

いくつか講演資料がアップされていました。

　

また、CodeZineさんにブログを掲載してもらったようです、ありがとうございます、ありがとうございます。

デブサミ2014、講演関連資料まとめ:CodeZine

　

講演資料は講演者の方のTwitter見たり、ハッシュタグ(#devsumi)を追うとよいと思います。

Webエンジニアの価値とそのための教育とは

  • 今年30歳になり今後どういうWebエンジニアになるべきか考えてる
  • 会社の教育担当になりどういうWebエンジニアが求められるか考えてる
  • ↑2つの事もあり他のWebエンジニアを客観的に見るようになってる

今年は色々と節目だったり新しい経験があったりなどで、Webエンジニアの価値と教育について考えてました。(今も考え中

　

とりあえず価値について調べてみる

そのままググってみたら次の記事が出てきました。

[特集:ITエンジニアの価値って何？ 1/3] ヘッドハンターが「活躍できる人材か」を見極める4大ポイント - エンジニアtype

Webエンジニアよ、「脱・組織依存」で生き残れ！／リクナビNEXT[転職サイト]

これらの記事ではWebエンジニアの価値は以下が必要となってるっぽいです。

  • 問題解決力
  • 変化対応力
  • 技術力
  • 成果力
  • 誰にも負けない強み

何となくそれっぽいですね。私もWebエンジニアになってから数年はこういう所が価値に繋がると思ってました、特に技術力。

ただ、今ある程度実力がついてプロジェクトや利益など、実装以外の事も考える立場になってからはちょっと微妙に考えが変わりだしてモヤモヤが続いている状態でした、実際これだけで本当にプロジェクトが成り立ち利益もでるのかなと。

　

Webエンジニアの価値は視点によって違うのでは

エンジニアの成長と反抗期 | 外道父の匠

育成や生産効率をテーマにした会食にて、相談された内容は

  • あるエンジニアが実力以上に過信して自己評価する
  • やたら特定の技術に拘って、結局リリースが伸びたり改悪したりする

・・・んだけど、これは何なんだろう、どうしたらいい？というもの。 これに対し、自身の辿った道も思い直して出した返答が

　『それは、エンジニアの反抗期だよ』

もちろんこれは、こどもがヤダヤダ拒否する（＝仕事したくない）本来の意味ではなく 逆に、やり過ぎによる失敗経路への舵切りのことを指しています。 聞き手はこれで非常に納得がいった様子。

この記事を見た時、私のモヤモヤはこれだなと思いました。

  • あるエンジニアが実力以上に過信して自己評価する
  • やたら特定の技術に拘って、結局リリースが伸びたり改悪したりする

Webエンジニアから見た場合、ある程度の自信を持つ事は意欲に繋がる、特定の技術に拘るという事は突き進んでいる、と考えられるので私は個人的に良いと思っています。Webエンジニアの価値として意欲と強みはとても重要だと思うので。

ただ、これが仕事だと異なります。過信はだいたい他のメンバーからの評判が悪いですし、出来ない事を出来ると言ってしまう等のリスクが生じます。特定の技術に拘るという事は、特定の技術を使ったプロジェクトにしかアサイン出来なくなったり、拘りすぎてリソースやプロジェクト管理に影響が出てきます。また、過信と拘りによりそれ以外のプロジェクトは興味がない、稼働が膨らんで利益が出ないなど、言い方が悪いですが扱いづらくお金にならないWebエンジニアになりかねません。それが結果として価値を下げる事に繋がると思います。会社やプロジェクト、他の職種から見た価値と言ってもよいかもしれませんね。

　

Webエンジニアに必要な事

Webエンジニア = 設計、実装する人

こういう概念が一般的に強いかもですし、おそらくこれからWebエンジニアになる人たちはまずこれを頑張ろうと思ってるはずです。そしてそれはWebエンジニアのスタートとしては間違ってはいないですし、Webエンジニアから見た価値になるはずです。

もちろん、それだけがWebエンジニアの仕事ではないです。仕様調整や見積、立場によってはプロジェクト全体を見たりクライアント先に出向いてMTGするなど多岐にわたります。これが仕事から見た価値になると思います。

ただ、Webエンジニアの立場からすると、メインは設計、実装であり、その他の事はあんまりという傾向も強いかなと思います。そのため、Webエンジニアから見た価値と仕事から見た価値は違うのではと思います。(私もあんまり見積とか外出は(ry

　

そんな中、元同僚である id:asonas がこんな記事を書いていました。(タイトルは全く関係ないです)

最近、机を買った話と高専生の話。 - 良いあそなすちゃん

前に前にと走ろうというアツい人と、冷静に確実な判断が下せる人がいい感じに揃っていて、ここぞって時に力がズバ抜ける雰囲気があったのでした。

　

前に前にと走ろうというアツい人 = 技術的好奇心がある = Webエンジニアから見た価値のある人

冷静に確実な判断が下せる人 = 大人なエンジニア = 仕事から見た価値のある人

　

この2つが上手く重なり合うと、それは確かに強い力になるなと私は肌で感じています。

ただ、今のWeb業界のサイクルや状況を考えると、Webエンジニアは1人でこの2つを持ち合わせなければいけないと私は思います。

35歳定年説などという古い言葉がありますが、今尚35歳すぎてもWebエンジニアをしている方々は、冷静な判断をしつつも新しい技術を積極的に取り込んでいる、この2つを併せ持っている気がします。

　

価値のあるWebエンジニアを育てる

ではこの2つの価値を持ち合わせているWebエンジニアをどうすれば育てられるのか。

私は以下の事が育てるのに重要だと感じています。

　

■長期的な教育

新卒研修と言うのは大抵1〜2ヶ月の研修とその後のOJTで終わるのが大半です。Webエンジニアから見た価値はこれで土台が作られ、そのままの流れで自分自身で高めていくものです。そしてこれで教育が終わります。

ただ、仕事から見た価値はこれだけでは到底無理です。プロジェクト管理や見積、利益などを考え実践出来るようになるには、教えるより経験と周りのフォローによって身に付くものです。そのため、1〜2年ほどプロジェクトを経験し、その中で徐々に意識付けを周りのメンバーがし、自分自身で考えれるようにしなければいけないと思います。

そう考えるとWebエンジニアの教育というのは、半年ほどの新卒研修だけではなく、3〜4年くらいの長期的な教育が必要ではと考えています。そしてそれは周りのメンバーの協力があって成り立つものになります。

　

■成長するキッカケを増やす

成長するキッカケは人それぞれだと思いますが、

　

「1つのプロジェクトを責任あるポジションでやる」

　

これが一番のキッカケだと思います、責任あるポジションをやるという事がポイントです。

先ほど新卒研修によりWebエンジニアとしての価値が高められていくと言いましたが、それにより3年目過ぎたあたりから反抗期がやってくると思います。反抗期の要因は様々あると思いますが、責任あるポジションではない所で設計や実装のみをメインにやり続けているのが一番大きいです。1〜2年目は技術的好奇心に満ち溢れているはずなのでこれで問題ないですが、3年目以降になると一人前のWebエンジニアと見られるのが大半なため、その人の価値が変わるポイントになると思います。

それを脱却するためには、責任あるポジション、ようはプロジェクトのメインエンジニアになり、設計、実装だけではなく、プロジェクトや進捗の管理、見積、稼働を考えて利益を出すという所を経験させるのが一番です。そこでWebエンジニアに必要な事を全て経験し意識するようになると思います。

また、一度失敗をしそれを認め改善させるのも良いキッカケだと思います。例えば特定の技術に拘ってリリースした結果、稼働が膨らんだのであればそれの数値を見せ、ここをこうすれば良かったねとか。ここに関しては周りのメンバーの説明や説得が必要不可欠です。

ちなみに私の成長したキッカケは以下2つです。

  • 中規模のプロジェクトを初めてメインになってやり遂げた
  • DBサーバのload average 70 を一晩で1以下に下げた

成長するにあたって重要な事は、その成長したというのを周りも気づく事です。

成長には成功した事による成長と、失敗した事による成長があります。反抗期の場合、失敗したという事をなかなか認めない印象が強いです。そこはやはり周りのメンバーが根気よく説明や説得をする必要があります。Webエンジニアにとって一番重要な目的は売上や結果をだす事であり、その手段が技術や知識です。反抗期なWebエンジニアは技術や知識が目的になる傾向があるため、そこを気づかせる事が大切です。

　

■プロジェクト、会社からの理解

1つのプロジェクトを責任あるポジションでやる、これが成長するキッカケと言いましたが、そうそう上手くキッカケはこないものです。

仕事としてやる以上、リソースや利益、安定性などを考える必要があります。成長させるために未経験の事をさせるというのは、売上やリリースの安定性と相反する事になります。これはプロジェクトや会社の視点から見るとうーんとなってしまいますね。あとは、リードエンジニアと反抗期エンジニアという選択肢があった場合、どうしてもリードエンジニアにお願いしたくなるのも事実です。

ただ、成長するには責任あるポジションでやる事は必要不可欠です。そのため、なるべくリソース管理を上手くやってキッカケを増やす事と、多少プロジェクトが赤になっても許容してもらう事がプロジェクトや会社に理解して欲しい所かなと思います。

　

まとめ

Webエンジニアの価値に対する考えは人それぞれなので答えはないと思います。ただ私の中では、

　

「技術的好奇心を持ちつつ売上を達成し周りの事を考えられる出来る子供と大人のエンジニア」

　

これに尽きるのではと思います。(とても中二病っぽいですがw

若い時にある技術的好奇心を尊重しながら、迷わないように周りがフォローする、そうする事で価値にあるWebエンジニアがたくさん生まれてくるといいなーと妄想してます。

そして私自身もそういうWebエンジニアになり、これからWebエンジニアになる子たちの価値を高めていけるように来年頑張ります。

画像をチラ見せするカルーセルのjQueryプラグイン「peep.carousel」を作った

Javascript jQuery

カルーセルのjQueryプラグインは多数ありますが、
ヤフオクのスマフォ版のように、前や次に画像がある場合にチラ見せをするようなプラグインがない、
という相談を受けたので初めてjQueryプラグインを作成しました。

peep.carousel

f:id:boss_sato:20130922142430p:plain

■GitHub

https://github.com/bossato/peep.carousel

　

■デモ

http://bossato.github.io/peep.carousel/

※デモはブラウザサイズ720pxあたりに最適化するようオプションを指定しています

　

■対応内容

  • レスポンシブ
  • CSS3 3d Transitions
  • マウススライドによるカルーセルのスライド
  • 表示件数の指定(オプション)
  • 前、次にカルーセル候補がある場合のチラ見せ(オプション)
  • 上記チラ見せさせる領域比率(オプション）
  • ページング表示(オプション)

　

■検証端末

　

■設置方法

1.ファイル読込

jQueryとpeep.carouselのJS、CSSファイルを読み込みます。

<link rel="stylesheet" type="text/css" href="peep.carousel/peep.carousel.css">
<script type="text/javascript" src="js/jquery-2.0.0.min.js"></script>
<script type="text/javascript" src="peep.carousel/peep.carousel.js"></script>

2.HTMLコーディング

カルーセル領域をdivで囲み、クラスにpeep-carousel、idに任意のIDを振ります。

<div id="peep1" class="peep-carousel">
  <ul>
    <li><img src="img/sample01.jpg" width="94" height="94"></li>
    <li><img src="img/sample02.jpg" width="94" height="94"></li>
    <li><img src="img/sample03.jpg" width="94" height="94"></li>
    .
    .
    .
  </ul>
</div>

3.プラグイン呼出

任意のIDを指定してpeep.carouselを呼びます。

<script type="text/javascript">
$(function() {
  $('#peep1').peepCarousel();
}); 
</script>

オプション

オプション 項目名 デフォルト値
displayImageNum 表示件数 3
displayPagination ページング表示フラグ true
displaySide チラ見せ表示フラグ true
sidePercent チラ見せ領域比率 1 
<script type="text/javascript">
$(function() {
  var options = {
    displayImageNum   : 4,
    displayPagination : false,
    sidePercent       : 1.5
  };
  $('#peep1').peepCarousel(options); 
}); 
</script>

　

■ライセンス

MIT License
※ライセンス付ける程のものでもないですし自由に利用、改修して欲しいと思ってますが、何かあった際の責任を明確にするために。。 　

■今後の対応予定

  • マウススライドによるカルーセルのスライド(スライドアニメーション付き)
  • 上記のタップ版
  • チラ見せ領域計算の精度向上

　

まだ十分な機能とテストは出来ていませんが、利用してもし何かあればGitHubやTwitterでお気軽に問い合わせて頂ければと思います。

　

余談ですが、jQueryプラグインを作ったのは初めてで色んなサイト、JSソースを参考にさせて頂きました。

　

また、プラグイン作成ではJS、CSSのチューニングやコーディング規約はかなり気を配って対応しました。
以下サイトはとても参考になります。

■チューニング

■コーディング規約

　

最近、フロントエンドによるWebサイト開発の機会が多くなっており、
それに伴いチューニングにも昔に比べだいぶ注目されつつあるなーと思います。
ただフロントエンドのチューニングは本当にチリも積もれば山となる的なイメージです。
少し意識を変えて取り組むだけどもパフォーマンスは変わってくると思うので是非紹介した記事は読んで頂ければと思います。

ChefでApahceとPHPをソースインストールするレシピを書いてみた

Chef PHP Apache

■さくらVPSにChefをインストール - 初めてのシステムと日記
http://bosssato.hatenablog.com/entry/2013/06/23/135552

前回の記事でさくらVPSにChefをインストールしました。
今回はChefを使ってApache、PHPをソースインストールするレシピを書いて実際にインストールしてみます。
(package使えば入るっぽいですが、たぶんyumインストールな気が。。)

今回の内容は私のGitHubに公開しているので、そちらを参考にして頂ければです。 (というのを前から言ってみたかった。)
https://github.com/bossato/chef

　

リポジトリ作成

まずは今回のレシピを格納するリポジトリを作成します。

// chefというリポジトリを作成
$ knife solo init chef

　

クックブック作成

次にApache、PHPそれぞれのクックブックを作成します。

$ cd chef

// Apacheのクックブックを作成
$ knife cookbook create apache -o site-cookbooks

// PHPのクックブックを作成
$ knife cookbook create php -o site-cookbooks

-oはクックブックを作成する先を指定します。
リポジトリを作成すると、cookbooksとsite-cookbooksの2つのクックブックディレクトリが作成されます。
どうやらこれの使い分けは以下のようです。

  • cookbooks : opscodeやGitHubのcookbookなどを格納する
  • site-cookbooks : 独自のcookbookを格納する

基本的に自分で作成するクックブックはsite-cookbooks、
本家opscodeや他の方のクックブックはcookbooksに格納するのが一般的なようです。

　

クックブック、レシピの方針

ここから本格的にApache、PHPのレシピを書いてきますが、方針は以下の通りとします。

  • ソースファイルはfilesに格納
  • 設定ファイルはtemplatesに格納
  • 設定ファイル、レシピ内の値はattributesで管理
  • レシピは上記を利用して書く
  • バージョンアップがあった場合
  • files、templatesに必要に応じてファイル設置
  • attributesの値を変更
  • レシピは基本いじらない

バージョンアップがある度にレシピを書き換えるのはそれなりのコストなため、
files、templates、attributesを上手く使って簡単にバージョンアップ出来るようにしていきます。

※この辺が分からない方は前回の記事の「knifeでクックブックを作成する」を参照して下さい。
http://bosssato.hatenablog.com/entry/2013/06/23/135552

　

Apacheのレシピを書く

まずはインストールするためのソースファイルをfilesに格納します。

$ cd site-cookbooks/apache/
$ wget http://archive.apache.org/dist/httpd/httpd-2.2.24.tar.gz -P files/default/

　

次に設定ファイルをtemplatesに格納します、とりあえずはhttpd.confのみ格納します。
私はインストール済みのApacheの設定ファイルがあったのでそれを使いましたが、
もし手元になければソースファイルを解凍してコピーすれば(たぶん)大丈夫です。

$ cp /usr/local/src/httpd-2.2.24/docs/conf/httpd.conf templates/default/httpd.conf.erb

　

この設定ファイルの値を動的にするため、attributesを設定します。
ここは書くのが大変なので、実際のファイルを参照して下さい。
https://github.com/bossato/chef/blob/master/site-cookbooks/apache/attributes/default.rb

　

設定ファイルでよく変更する項目の値は、↑みたいな感じで配列に格納しました。
そしてこの配列をアサイン出来るようにtemplates/default/httpd.conf.erbも編集します。
これも書くのが大変なので、実際のファイルを見て頂ければ。。
https://github.com/bossato/chef/blob/master/site-cookbooks/apache/templates/default/httpd.conf.erb

例えば以下のような形式で書きます。

ServerRoot "<%= node['apache']['dir'] %>"

そうするとattributes/default.rbで書いた以下が展開されます。

default['apache']['dir']     = "/usr/local/apache2/"

　

下準備が完了したのでレシピを書いていきます。ここは上から解説していきます。
https://github.com/bossato/chef/blob/master/site-cookbooks/apache/recipes/default.rb

cookbook_file "#{node['apache']['src_dir']}#{node['apache']['version']}.tar.gz" do
  mode 0644
end

http://docs.opscode.com/resource_cookbook_file.html
cookbook_fileはfilesに格納したファイルを設置するためのリソースです。
この場合は/usr/local/src/httpd-2.2.24.tar.gzに設置されます。
ファイル名を揃えておく必要があります。

　

bash "install apache" do
  user     node['apache']['install_user']
  cwd      node['apache']['src_dir']
  not_if   "ls #{node['apache']['dir']}"
  notifies :run, 'bash[start apache]', :immediately
  code   <<-EOH
    tar xzf #{node['apache']['version']}.tar.gz
    cd #{node['apache']['version']}
    ./configure #{node['apache']['configure']}
    make
    make install
  EOH
end

http://docs.opscode.com/resource_bash.html
bashはコマンド実行するためのリソースです。
ここではinstall apacheという名前をつけてインストールコマンドを実行してます。
Chefはインストール済みのものがあったらよしなにアップデート、もしくはスルーしてくれますが、
ソースから入れた場合はさすがによしなに対応してくれないようです。
そのため、Apacheが入っているかどうかを確認するためのコマンドを指定する必要があります。

not_if   "ls #{node['apache']['dir']}"

not_ifはもし指定したコマンドが返ってくればbashを実行しないという項目です。
ここではApacheのディレクトリがあればbashを実行しないように指定しています。

notifies :run, 'bash[start apache]', :immediately

ここではapache install実行後、後述するstart apacheを実行します。
:immediatelyはapache install実行後に起動する事を指定しています。

　

bash "start apache" do
  action :nothing
  flags  '-ex'
  user   node['apache']['install_user']
  code   <<-EOH
    #{node['apache']['dir']}bin/apachectl start
  EOH
end

ここではApacheの起動をするbashを書いています。

action :nothing

これはChef実行時に起動しないようにしています。
基本的にこれ単体では実行せず、他から呼び出される関数のようなイメージです。
先ほどのinstall apacheがまさにそういうイメージです。

　

レシピが書き終わったので、JSONに追加してChefを実行します。

$ cat nodes/localhost.json
{
    "run_list": [
        "recipe[apache]"
    ]
}
$ chef-solo -c solo.rb -j ./nodes/localhost.json

https://gist.github.com/bossato/6148793
↑みたいなログが出力されれば成功です。
念のため起動されているかも確認します。

$ ps awux | grep httpd | grep root 
root     10584  0.1  0.3  64668  3700 ?        Ss   11:09   0:00 /usr/local/apache2//bin/httpd -k start
root     10641  0.0  0.0   6380   648 pts/3    S+   11:13   0:00 grep httpd

ちゃんと起動されている事が確認出来ました。
(微妙に/が余計に入ってるのでレシピ修正しておきます。。)

以降、もし何か設定ファイルの更新、バージョンアップ等あれば、
attributesの変更、files、templatesへのファイル設置で、
Chefがファイルの更新を確認して(おそらく)よしなに実行してくれます。

　

PHPのレシピを書く

PHPも同様の方針で書いています。解説するのが面倒くさくなってきたので
詳しくはGitHubを見てもらえれば、Apacheのレシピを理解していれば分かるかと思います。
https://github.com/bossato/chef/tree/master/site-cookbooks/php

　　

Chefで参考にすべき書籍、サイト

Chefはちょっと前から注目され、最近はブログ等でも解説されるようになってきました。
私がChefで参考にした書籍やサイトは以下が主です。

　

■入門Chef Solo - Infrastructure as Code 伊藤直也

入門Chef Solo - Infrastructure as Code

入門Chef Solo - Infrastructure as Code

Chefの入門書として有名ですね、私は基本的な流れはこれを見て学びました。

　

■Resources and Providers Reference - Chef

http://docs.opscode.com/chef/resources.html
公式のドキュメントになります。
国内でも解説ブログが増えたとは言え、情報量がやはり乏しいので公式を見た方が早かったりします。

　

■opscode-cookbooks (Opscode Public Cookbooks)

https://github.com/opscode-cookbooks
これまた公式のクックブック集になります。
attributes、filesなどの使い方、レシピの書き方は非常に参考になります。

　

今回はApacheとPHPをChefを使ってインストールするレシピを書きました。
このような感じでサーバの初期設定をChefで管理し、運用時の管理もChefを使ってやるようにすれば、
Chefを見るだけでサーバの状態が分かるようになります。

また、何よりもChefは書いていて楽しいというのが一番感じる所です。
インフラ対応はたいていのエンジニアは毛嫌いするものですが、
プログラム(しかも今流行のRuby)を書きながらサーバ管理出来るのは楽しいですよ。

さくらVPSにChefをインストール

Chef

Chefとは

■Chef | Opscode http://www.opscode.com/chef/

Rubyで作られたサーバ構成管理ツールです。
サーバへのインストール、設定変更、ユーザ作成等、
設定や更新を自動化しサーバの状態を管理する事が出来ます。

　

Rubyをインストールする

ChefはRubyで作られているので当然Rubyが必要になります。
さくらVPSはデフォルトでRubyが入っていないためインストールします。

ChefはRuby2.x系に対応していないため、ここではRuby1.9系最新をインストールします。

※調べる限りRuby2.x系に対応させるようにする事は可能なようです。
http://at-aka.blogspot.jp/2013/04/chef-solo-ruby-2.0.html

// 必要なパッケージインストール
$ yum install -y gcc-c++ patch readline readline-devel zlib zlib-devel libyaml-devel libffi-devel openssl-devel git

// ソース取得
$ cd /usr/local/src/
$ wget ftp://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.3-p429.tar.gz
$ cd ruby-1.9.3-p429 

// インストール
$ ./configure
$ make
$ make install

// 確認
$ ruby -v
ruby 1.9.3p429 (2013-05-15) [x86_64-linux]

　

Chefをインストールする

Rubyのインストールが終わったらgemを使ってChefをインストールします。

$ gem install chef

　

リポジトリ、クックブック、レシピ

Chefではよく以下の言葉が使われます。

  • レシピ
    • インストールする、設定ファイルを書き換える、ユーザーを作る等の手順をコード化したファイル
    • 例) Apacheをインストールする
  • クックブック
    • あるレシピに必要なファイルやデータをまとめたディレクトリ
    • 例) Apacheをインストールするためのソースファイルを入れる
  • リポジトリ
    • 全てのクックブックをまとめたディレクトリ

　 上記の言葉を用いるとChefは以下の階層で管理されています。

リポジトリ > クックブック > レシピ

　

knifeの設定をする

knifeとはchefの便利コマンドの1つで、
主にリポジトリやクックブックを作成するために使われるコマンドです。

設定をするには以下コマンドを打ちます。

$ knife configure

いろいろ聞かれますが全てデフォルトでOKです。

　

knifeでリポジトリを作成する　

ここからは実際にChefの作業に入ります。
まずはknifeを使ってリポジトリを作成します。

// chef-repoというリポジトリを作成
$ knife solo init chef-repo

// 構造確認
$ tree chef-repo/
chef-repo/
|-- cookbooks
|-- data_bags
|-- nodes
|-- roles
|-- site-cookbooks
`-- solo.rb

　

knifeでクックブックを作成する

リポジトリを作ったので、次にクックブックを作成します

$ cd chef-repo

// cookbooksディレクトリにhelloというクックブックを作成
$ knife cookbook create hello -o cookbooks
** Creating cookbook hello
** Creating README for cookbook: hello
** Creating CHANGELOG for cookbook: hello
** Creating metadata for cookbook: hello

// cookbooksの下にhelloクックブックが作成された
# tree -F
.
|-- cookbooks/
|   `-- hello/
|       |-- CHANGELOG.md
|       |-- README.md
|       |-- attributes/
|       |-- definitions/
|       |-- files/
|       |   `-- default/
|       |-- libraries/
|       |-- metadata.rb
|       |-- providers/
|       |-- recipes/
|       |   `-- default.rb
|       |-- resources/
|       `-- templates/
|           `-- default/
|-- data_bags/
|-- nodes/
|-- roles/
|-- site-cookbooks/
`-- solo.rb

helloクックブックが作成され、データやファイルを格納するディレクトリやレシピが確認出来ました。

各ディレクトリでよく用いられるのは以下があります。※今回は基本的に使いません。

  • attributes, data_bags
    • レシピ、設定ファイル等を扱うテンプレート内で動的に使いたい値を定義するファイルの置き場所
    • attributes：特定のクックブックが対象
    • data_bags：リポジトリ全体が対象
  • files, templates
    • 設定ファイル等の外部ファイルの置き場所
    • files：静的ファイル
    • templates：attributesを用いて動的に値を展開するファイル
  • nodes
    • レシピを記述するJSONファイルの置き場所
    • サーバ毎にファイル設置したりする

　

レシピを編集する

もろもろ設定が終わったので、レシピを作っていきます。
先ほどのクックブック作成でレシピのデフォルトファイルも作られたのでそれを編集します。
ここではとりあえずHellow Chef!というお決まりのログを表示します。

$ vim cookbooks/hello/recipes/default.rb 

#
# Cookbook Name:: hello
# Recipe:: default
#
# Copyright 2013, YOUR_COMPANY_NAME
#
# All rights reserved - Do Not Redistribute
#
log "Hello Chef!"

次にどのレシピを実行するかを記述するJSONファイルを作成します。

このファイルはクックブック作成時には作られてないため、
nodesディレクトリ直下に新規に作成します。

$ vim nodes/localhost.json

// localhost.json
{
    "run_list": [
        "recipe[hello]"
    ]   
}

最後にChefが使うテンポラリディレクトリやパスを指定する設定ファイルを編集します。
ここでは、リポジトリ名の変更と、cookbook_pathを実際に作ったクックブックのpathに合わせればOKです。

$ vim solo.rb

file_cache_path           "/tmp/chef-repo"
data_bag_path             "/tmp/chef-repo/data_bags"
encrypted_data_bag_secret "/tmp/chef-repo/data_bag_key"
cookbook_path             [ "/tmp/chef-repo/site-cookbooks",
                            "/tmp/chef-repo/cookbooks" ]
role_path                 "/tmp/chef-repo/roles"

レシピと設定ファイルの準備が出来たので、実際にChefで動かしてみます。

$ chef-solo -c solo.rb -j ./nodes/localhost.json 
Starting Chef Client, version 11.4.4
Compiling Cookbooks...
Converging 1 resources
Recipe: hello::default
  * log[Hello Chef!] action write

Chef Client finished, 1 resources updated

Hello Chef!が表示されました。
表示されずエラーが出る場合は以下の点を確認して下さい。

  • solo.rbの各pathが間違ってないか
  • nodes/localhost.jsonのsyntaxが正しいか
  • nodes/localhost.jsonで指定しているレシピが正しいか
  • レシピのsyntaxが正しいか

　

まとめ

今回はひとまずさくらVPSでChefをインストールし、動作する所まで対応しました。
これだけだとまだChefの有効性がよく分からんな感じだと思います。

例えば私がよくやるサーバセットアップは、以下が結構お決まりです。

  • FWの設定
  • 不必要なサービス停止
  • 一般ユーザの作成と権限変更
  • Apacheのインストールと設定ファイル変更
  • MySQLのインストールと設定ファイル変更
  • PHPのインストールと設定ファイル変更
  • MySQLのユーザーとDB作成
  • 必要なモジュール群インストール

これをChefで例えると、

  • 1つ1つの作業をレシピに書き換える(初回のみ)
  • サーバ固定の値やミドルウェアバージョンはattributesで持たせる
    • 例えばDNSやIPが違う場合はattributesのみ変更すればOKとなる
  • サーバによっていらないものはJSONファイルのrun_listから消すだけでOK
  • 同じような構成の場合、また一から作業ではなく、リポジトリを持ってきてchef-soloを実行するだけでOK

という感じでルーチンワークだったサーバセットアップが自動化でき、
かつサーバ管理もクックブックやレシピを見れば分かるようになります。

実際、レシピを書いていると普段のサーバセットアップよりも楽しいですし(今流行のRubyだし)、
コストやストレス的な負担も考えると有効なツールだと思います。

Frontrend Vol.4 に参加してきた

jQuery Javascript

Frontrend Vol.4 powered by CyberAgent, Inc. : ATND
http://atnd.org/events/35720

今年初めて参加するセミナーということで、
サイバーエージェントさんが主催するフロントエンド系技術セミナーに行ってきました。


「JavaScript Development Tools – JavaScript開発の効率アップ」 平木 聡さん

「JavaScriptツール初心者から脱初心者へ」という目的で、
JavaScript開発の効率アップが図れるGUI•CUIツールを紹介になります。


JavaScript開発に役立つGUIツールの紹介

■Chrome Developer Tool

■Charles

  • http://www.charlesproxy.com/
  • デバッグ用Proxyサーバーをローカルに立てれる
  • MapLocal
    • URL先のファイルとローカルファイルを掏り替えれる
    • AutoResponderと同様の機能
  • Throttle
    • 回線速度のエミューレート
    • 3G相当の通信の遅さでサイトを見るなどが出来る

■DocHub

■jsFiddle

■jsPerf

■browserling

  • https://browserling.com/
  • 各ブラウザでのテストが可能
  • おそらく社内のみの環境とかではテスト無理な気がします


JavaScript開発に役立つCUIツールの紹介

■JSHint

% brew install node
% npm install -g jshint
% jshint -v
0.9.1
% jshint wrong_pattern.js
wrong_pattern.js: line 2, col 3, Expected 'WIN' to have an indentation at 5 instead at 3.
1 errors


■jq

  • http://stedolan.github.com/jq/
  • JSONプロセッサ
  • JSONの結果をクエリで操作
  • 色んなサービスのAPIからのレスポンスデータを解析するのに便利そうです
% brew install node
% jq --version
jq version 1.1
% cat twitter.json | jq '.' // 見やすく整形
% cat twitter.json | jq '.results[0]' // 1つ目のデータを整形
% cat twitter.json | jq '.results[0]  | {from_user, text}' // 1つ目のデータの指定項目を整形


■Doctor JS

% npm install -g jsctags
% jsctags demo/doctorjs


■Yeoman

  • http://yeoman.io/
  • Webアプリケーション作成支援ライブラリ
  • 既存ライブラリを組み合わせて開発されている
    • Web App (default)
    • AngularJS
    • Backbone
    • BBB (Backbone Boilerplate)
    • Chrome Apps Basic Boilerplate
    • Ember
    • Jasmine
    • Mocha
    • Testacular
% npm install -g jsctags
% curl -L get.yeoman.io | bash


最近のJavaScript開発には役立つツールがあるので、
そのツールを上手く使う事で効率化を図ることが大切。
そしてCUIツールは「黒い画面」だからといって
尻込みせず使うと幸せになれる、とのまとめでした。


「jQuery Performance Tips – jQueryにおける高速化 -」 水野 隼登さん

パフォーマンスチューニングには必ずトレードオフが発生する(可読性が低下する等)、
JavaScriptよりjQueryを使っている方が多い、
その前提を基にjQuery Likeを保ったままのパフォーマンスチューニングに関するお話です。


ファイルサイズを減らす

  • モバイルデバイスにおいて、1kbにつき1msのパース時間が発生
  • jQueryのバージョンによってファイルサイズが異なる
    • 1.9 → 33kb
    • 2.0 → 30kb
  • IE6-8対応用スニペットによるjQueryファイルの出し分け
    • ブラウザに適したファイルサイズの小さいjQueryファイルが呼び出せる
<!--[if lt IE 9]>
    <script src="jquery-1.9.0.js"></script>
<![endif]-->
<!--[if gte IE 9]><!-->
    <script src="jquery-2.0.0.js"></script>
<!--[endif]-->

% grunt custom:-ajax,-css,-deprecated,-dimensions,-effects,-offset


セレクタのチューニング

  • 速いセレクタランキング
    • JavaScriptのネイティヴのメソッドを使ってるか、全検索するか、jQuery独自セレクタを使うかどうかでパフォーマンスが違ってくる
1. $('#id')
2. $('tag')
3. $('.class')
4. $(':first-child')
5. $(':first')

  • 例
$('#target p') → querySelectorAll が使われる
 ↓
$('#target').find('p') → getElementById+.find()+getElementsByTagName

  • キャッシュも活用する
var $target = $('#target'),
$p = $target.find('p');


リフローの影響を考える

  • CSS Reflow - jQuery.com http://www.youtube.com/watch?v=ILvF25ljaoM
  • 描画のフローは段階的に行われている
  • リフローが発生する可能性のあるトリガー
    • CSSの変更/取得 css().addClass(),show(),animate()...
    • DOM要素の操作 html(), text(), append(), focus()...
    • 特定のプロパティの取得 offset(), position()...
    • ユーザー操作 ウィンドウサイズの変更,スクロール,テキスト入力
  • 不要なリフローを避ける
    • CSS()は1回にまとめる
    • リフローが必要な取得系メソッドはキャッシュして使い回す
    • body閉じタグ直前ではなhead閉じタグ直前に記述
  • ボトルネックを解消する
    • 描画コストの高いCSSプロパティ
    • アニメーション
    • ループ処理


最後の戒めの言葉がとても印象的でした。

「小さな効率は忘れよう。
時間の97%について語ろう。
早まった最適化は諸悪の根源だ。 」TONY HOARE（？）


「Testable Javascript – テストしやすいJavaScriptとテストについて -」 斉藤 祐也さん

テストしやすいJavaScriptとは


ユニットテストツールとテスト


ユニットテストツールは色々ありますが、
どのツールにも得意不得意はあるのでとりあえず書いてみる事が重要であること、
テスト自動化という環境を整えれば言い訳しづらくなる等、
JavaScriptのテストはまだ日が浅いとは充実しつつありますね。

僕の感覚的には、リファクタリングしても動作が保証出来るテストを書く事が重要、という印象を受けました。


「jQuery to Backbone – アーキテクチャを意識したJavaScript入門」 佐藤 歩さん

Backboneについて

  • http://backbonejs.org/
  • 構造化の手段を提供するライブラリ → MVC
  • 軽量さといじりやすい柔軟さが売り

jQueryの特徴と役割

  • DOM APIを簡潔に書ける
    • JavaScriptは書けないけどjQueryは書けるという人多そうですしね
  • クロスブラウザの諸問題を解決してくれる
  • プラグインの充実とエコシステム形成
  • 逆にjQueryでも解決してくれない問題もある
    • コードの肥大化
    • スパゲッティーコード
    • テスト
    • メンテナンスのしづらさ
    • →フロントエンド実装の比重が高まってきたため

JavaScriptにおけるMV*の現状

アーキテクチャとデザインパターン

  • Facade 複数の処理をまとめる
  • Singletion ただひとつのオブジェクト
  • Flyweight インスタンス生成
  • Observer イベントを監視
  • Mediator イベントを仲介
  • 急に取りかかるのは難しい → Backboneで実践してみる

Backboneにおけるコンポーネント

  • View
    • 見た目とUIにおける入出力
    • DOM要素の管理
    • イベント制御
  • Model
    • 取り扱うデータの最小単位
    • ストレージとの通信、同期
    • APIやレコードの情報を表現
  • Collection
    • Modelが集合したリスト
    • リスト操作(filter,where..)
  • Router
    • URLによるルーティング


実践踏まえBackboneを紹介してもらいましたが、かなり分かりやすい印象、
かつ既存のjQueryコードをbackboneへ移行というのもそこまでコストかからず出来そうでした。