2014-05-02

スキルのステ振り

あと約11ヶ月で長かったモラトリアム期間が終了し、晴れてTOKYOでエンジニアをすることになる。今までは何も知らなかったからいろいろとがむしゃら勉強してきたけど、ここいらで一度今後のステ振りについて考えてみた。

少し前までは企画からマケからデザインから開発運用まで何でもこなす、スーパーフルスタックな、グロースハッカー的な存在を目指してたけど、自分には向いていない気がしてきた。僕はビジネスにあまり興味を持てないし、マネージャーになる気もない。

今僕が最も興味があるのは、ソフトウェアのアプリケーションレイヤーの設計で、特にWebフロントエンドの設計だ。この分野はまだ設計のデファクトの解がなく、考えるのが楽しいし、ステータスを振り続けようと思ってる。

ステータスは、だいたいどこかに極振った方が、結果チーム内で役割を持てる。まんべんなく振ると一見便利そうだけど、だいたい使い物にならない。ある環境やある敵を想定して振ると、汎用性がなくなる。また時間というリソースは有限なので、効率よく経験値を稼がないといけない。

このことは全て、小1からずっとやってるポケモンから学んだ。

ポケットモンスター X

出版社/メーカー: 任天堂
発売日: 2013/10/12
メディア: Video Game
この商品を含むブログ (1件) を見る

ポケットモンスター Y

出版社/メーカー: 任天堂
発売日: 2013/10/12
メディア: Video Game
この商品を含むブログ (1件) を見る

2014-04-07

世の中のCSSプリプロセッサーがどれもクソだから自作したった

タイトルは釣りです。Stylusは最高だと思うし、Sassはいつも使っています。Lessは…うん、いい感じだと思います。

Yet Another CSS Preprocessor

YACP(Yet Another CSS Preprocessor)という、CSS プリプロセッサーを作った。名前は考えるのめんどうだったので適当に付けた。作ったと言っても、前回のブログを書いたときに作ったrework-rule-bindingを使ってreworkでビルドしただけ。

インストールはnpmから。

$ npm install -g yacp

autoprefixerを組み込んでいるので、ベンダープレフィックスを気にしなくていい。SassみたいにCompassのCSS3のmixinを@includeする必要もない。

他にはrework-varsも使っていて、W3Cの変数定義の構文が使える。

/* input.css */
:root {
  var-font-lg: 18px;
}

.btn-lg {
  box-shadow: 5px 5px;
  font-size: var(font-lg);
  padding: 5px 10px;
}

コンパイルは、

$ yacp < input.css > output.css

で、こうなる。

/* output.css */
.btn {
  /* ベンダープレフィックスの付与 */
  -webkit-box-shadow: 10px 10px;
  box-shadow: 10px 10px;
  /* 変数の展開 */
  font-size: 18px;
  padding: 5px 10px;
}

でも1番の特徴というか他のCSS プリプロセッサーとの差別化としては、rework-rule-bindingで特定のルールセットのカスケーディングを禁止できることだ。rework-rule-bindingにより、丸かっこ「()」で囲んだセレクタと「%」から始まるセレクタが持つルールセットはカスケードしない。

またYACPでは、「%」から始まるセレクタのみ継承対象であり、このセレクタはSassのプレースホルダーセレクタと同様に出力されない。

%att {
  color: red;
  font-weight: normal;
}

.attBox {
  /* %attを継承 */
  extends: %att;
  padding: 15px;
}

こんな感じで使う。継承するときの構文は、extend:, extends:, inherit:, inherits:が使える。

CSS プリプロセッサー

前回の記事にも書いたけど、現状のCSS プリプロセッサーはCSSに便利なシンタックスシュガーを定義したものに過ぎず、DRYを加速させることはできるが本質的にCSSの設計を良くするものではない。

しかし、CSS プリプロセッサーは必要だと思う。いや、CSS プリプロセッサーが必要というよりも、SassやStylusにある"@extend"を使った、他のルールセットを継承する機能が必要なのである。

他のルールセットを継承することにより、意味のレベルでルールセットを分けることができる。これにより、ついにオブジェクト指向 CSSを真に実現することができる。CSS プリプロセッサーの必要性についてはこの記事に書かれており、大いに賛成している。

しかしSassやStylusでは、継承元のルールセットもカスケーディングにより上書きされていく。

/* Sass(.scss) */
.att {
  color: red;
  font-weight: normal;
}
.attBox {
  @extend .att;
  padding: 15px;
}
.att {
  font-size: 14px;
}

Sassでこのように書くと結果は以下のようになる。

/* 出力 */
.att, .attBox {
  color: red;
  font-weight: normal;
}
.attBox {
  padding: 15px;
}
.att, .attBox {
  font-size: 14px;
}

このように継承元となるルールセット(.att)はカスケーディングし、継承先で予期せぬ結果になる場合がある。またSassやStylusでは、プレースホルダーセレクタ以外のルールセットも継承することができるので、安易に@extendし、膨れ上がったCSSファイルを幾度と見てきた。

その点YACPでは、プレースホルダーセレクタだけしか継承できないので下手な使い方をしてCSSファイルが大きくなることもない。しかもその継承元はカスケーディングされないという保証がある。

CSSの在り方

CSSはどうあるべきなのだろうと考える。CSSはもともと文書に簡単なレイアウトと装飾を施すための言語だった。しかしCSS3には、柔軟なレイアウトや複雑な装飾を施すための多くのプロパティが追加された。またこれからも増え続けていくであろう、デバイス幅の異なる未知の端末に1ソースで対応する、レスポンシブWebデザインという思想がある。これらの理由から、近年のCSSの記述は複雑化してきている。

CSSは、ただWebのビジュアルデザインを表現できれば良いというものではない。Webサイトのパフォーマンスの観点からもそうだし、CSSも他のプログラミング言語と同様に保守の対象であるべきである。

ここまで書いたことは当たり前のことかもしれないが、現状CSSはかなり適当に書かれ、杜撰な管理がされていることは少なくない。その理由はCSSの記述が柔軟すぎることにもあるが、そもそもCSSを書く人はほとんどがデザイナー上がりの人で、思った通りのビジュアルが表現できればいいと考えているからではないか。また、プログラマはビジュアルが絡む分野を避ける傾向がある気もする。その点@tjholowaychukとかはすごいなあと思ってる。いやはやー、日本で僕ぐらい頭使ってCSS書いてる人ってどのくらいいるのかなあと思う。

ああ、ついつい偉そうなことを言ってしまった。これもまあ、セルフブランディングということで。自分にプレッシャーをかけて精進していきたい。

2014-04-04

CSSのカスケーディングを禁止する

rework-rule-bindingという、CSSのカスケーディングを禁止する構文を追加するReworkプラグインを書いた。

Rework

Reworkは、@tjholowaychukや@necolasらが立ち上げているプロジェクト。Reworkのプラグインを書くことによって、開発者は独自のCSSのプリプロセスを定義することができる。Twitter社は、twitter.comでReworkで作ったプリプロセッサーを使用しているらしい。

rework-rule-binding

rework-rule-bindingは、CSSにカスケーディングを禁止する構文を提供する。

(.bind-rule) {
  padding: 15px;
  border: 1px solid #999;
}

/* error */
.bind-rule {
  padding: 0px;
}
/* error */
(.bind-rule) {
  border: none;
}

このように、丸かっこ「()」でセレクタを囲むとそのルールセットは束縛（binding）され、カスケーディングできなくなる。

カスケーディング

CSS（Cascading Style Sheets）はカスケーディングという機能により、スタイル指定が段階的に引き継がれる。

rework-rule-bindingはそのカスケーディングを禁止する。これはCSSの思想を否定することかもしれない。しかしCSSの設計が破綻しやすい原因として、カスケーディングが一役買っているように思う。そもそも、CSSのような宣言的に記述する言語はそこで定義されたもの（CSSの場合ルールセット）の上書きはされるべきではない。

アート活動

rework-rule-bindingは概念実証として作ったアート作品みたいなもので、普段の考え方から若干ズレた存在を認識することで、既存の道具の有り様を捉え直せれば良いかなと思ってつくった。

CSSの設計については多くの人に語られており、OOCSS、BEM、SMACSSのように様々な思想（概念）が生み出されてきた。しかしこれらの思想は、CSS職人たちが長年の経験から導き出したもので、初心者がこれを知ったところですぐに実践できるものではない。それに僕には、どれもただの命名規則やコーディング規約のようなものに思えた。

またSassやLess、StylusといったCSS プリプロセッサーはCSSに変数やmixin、条件文等の機能を追加し、CSSをプログラマブルに記述できるようにした。しかしこれらのプリプロセッサーはCSSにシンタックスシュガーを定義したものに過ぎず、DRYを加速させることはできるが本質的にCSSの設計を良くするものではない。

理想的なCSSとは何か。CSSに限った話ではない。今自分が使っている技術、道具は自分にとって一体どういう存在なのか、ということに考えが行くようになれば良い。そして時にはその技術の思想さえも疑い、より良いものにしたい。このようなことを考えてrework-rule-bindingは作られた。

ここまで書いたことは全部嘘で、本当は何も考えてなくて単純に面白ければいいと思ってつくった。

参考にしたサイト

2014-03-24

初めてQiitaに投稿した話

前に別のブログに書いた記事をQiitaに投稿してみた。

このブログはrootsっていう静的サイトジェネレーターで作って、借りているVPSでホスティングしている。まだまだ僕にはコンテンツ力がないので（？）、全然見てもらえていない。

その点Qiitaの方が見てもらえるし、ストックやはてブ等フィードバックがあってモチベーションが上がった。

作ったものとか、勉強した技術とかをちょっとまとめるのにQiita最高だなって思った。

2014-03-23

エンジニアの生存戦略としてのブログ

ブログを書き始めて、ブログを書いても、自分が本当に伝えたいことはなかなか相手には伝わっていないなと感じる。自分や他の人が書いた記事の（ブックマーク）コメントやツイートを読んでも、その記事の本質とは異なるところで、共感や批判をされる。

そもそもブログを書くときは、言葉の表現とかどうすれば理解しやすいかを熟考する。書いたあともよく推敲し、来るフィードバックに胸を躍らせながら公開する。

しかし、読み手の立場になって考えてみると、多くの場合その記事は、ただTwitterやSNSで拡散されてきたものであったり、検索したキーワードで引っかかったものの1つだろう。自分で金を払った本でさえ熟読することは稀なのに、誰かわからない人のブログ記事を熟読するわけがない。

ここまで書いたけど、エンジニアとして売名していくにはコード書くしかないってなった。

プログラミングのTipsみたいなものはQiitaに書いていこうと思った。

終わり

2014-03-18

RailsユーザーからRailsエンジニアへ

最近、Railsを使い始めた。前回のエントリーでも書いた通り、Railsはそこらのフルスタックフレームワークよりもフルスタックで、学習コストが高いと思う。

railsコマンドによるコードの自動生成や、多くのrakeタスク、存在価値がわからないViewHelperなど、DHH氏の考えたWebアプリケーション開発をするレールが敷かれている。 DHH氏曰く、「Rails is omakase」で、"Railsユーザー"は氏の考えに文句を言ってはいけない（嫌なら使わなければいい）。

Railsアプリを自分好みに作りこんでいく、DHH氏の手の上で踊らないようにするにはどうすればいいか。

最終的にはRailsのソースコードを読むところに行き着くが、そのためにはRubyの言語仕様とRackについての理解を深めるべきだと思う。そりゃそうか。

Rubyの言語仕様を勉強するのは当たり前として、Rack（というかWSGI）の思想や概念を知って、Rackアプリケーションやミドルウェアがどう定義されているのかを理解すべきである。この図が何を示しているいるのかがわかるぐらいには。また、RubyGemsには多くの便利なライブラリ、ツールが登録されていて、それらの実装を見てみるといいと思う。

Railsを含めRubyのフレームワークは、Rackとgemのおかげでカスタマイズしやすいと思っている。 PHPの場合だと、PHPはWebアプリ開発に特化した言語であり、言語レベルで専用の機能（スーパーグローバル変数等）を持っているため、Webサーバーとの間にミドルウェアを挟みにくい。また、Composer+Packagistもgemと比べて貧弱なように思う。

なんか偉そうなことを書いたけど、自分自身まだまだ勉強不足なので精進していきたい。

コンテンツ消費者から技術者へ

RailsユーザーからRailsエンジニアへ、というタイトルだが、これはどんな技術についても言うことができる。僕がぱっと思いついたのは、僕のまわりにいるiOSやAndroid等のスマホエンジニアだ。

彼らは、XcodeやEclipseの使い方に習熟していてGUIの操作でViewを組み立てるし、SDKにも詳しい。僕はネイティブのフロントを書けないので、本当に尊敬している。でも、彼らを見て思うのが（学生だからだと思うけど）、IDEやSDKの機能にはないことができないということだ。

彼らはXcodeというツールを使っている、コンテンツを消費しているだけの人で、モノを作ることはできるけど、技術者ではないように思える。クリエイターっていう表現の方が近い。

別にそれがいけないことだとは全く思ってないけど、なんだかもやもやして、ウッってなったから書いた。

パーフェクトRuby (PERFECT SERIES 6)

作者: Rubyサポーターズ,すがわらまさのり,寺田玄太郎,三村益隆,近藤宇智朗,橋立友宏,関口亮一
出版社/メーカー: 技術評論社
発売日: 2013/08/10
メディア: 大型本
この商品を含むブログ (15件) を見る

2014-03-12

Ruby初心者がRailsとGrapeでREST APIを作る

Backbone.jsを使ったアプリケーションのバックエンドのAPIを作ることになった。普段サーバーサイドを書くときはPHPを使ってたけど、勉強も兼ねてRubyを使った。

Railsのお勉強

Rubyでアプリケーションを書くときはRailsを使うのが当たり前みたいになってると思う。Railsは以前少し触ってみたけど、よくわからなくなって結局やめてしまった。今回は、Ruby on Rails Tutorialを手を動かしながらやった。ほぼRuby初心者だったので、Rack？Rake？Bundler？Rspec？なにそれ状態だったけど、調べながらひと通りやってみた。Railsとその周辺の技術をふわっと理解することができた。Railsはそんじょそこらのフルスタックフレームワークよりもフルスタックで、学習コストがめちゃくちゃ高いと思う。

Grape

RubyでAPI作るのいろいろ調べてたら、Grapeっていうgemと出会った。GrapeはRubyでREST APIを作るのに特化したマイクロフレームワークで、Sinatraの影響を受けている。

class API < Grape::API
  prefix 'api'
  version 'v1', using: :path
  format :json

  resource :book do
    get do
      Book.all
    end

    delete ':id' do
      Book.find(params[:id]).destroy
    end
  end
end

このようにURLの構造に沿った記述ができ、直感的に書きやすい。公式ドキュメントがしっかりしているので、使い方は読めばだいたいわかると思う。作ったサンプルはGitHubにあげた。

Grapeが使いやすそうだったので、Railsを使わずにGrapeだけでAPIを作ろうと思ったけど、RailsのModel周り（ActiveRecordとかmigrationとか）が便利だったので、やはり組み合わせて使うことにした。Webフレームワークは「ルーティング+リッチなModel」ぐらいがちょうどいいと思う。ViewHelperとかいらない。

Front-end × Rails

最近Webフロントエンドの技術が発展していて、フロントエンドなエンジニアの人はそれぞれ自分のやりやすい環境を持っていると思う。例えば僕だと「HTMLはJade、CSSはStylusを使って、bowerでライブラリ管理して、Gruntかgulpでビルドする」とか個人で作る分にはしたい。RailsにはAsset Pipelineがあるから、Gruntを使いたいときはどうするんだろう。

だから、RailsというかバックエンドはAPIのみを提供し、クライアントでDOMを構築する方がフロントとバックエンドで完全に分業できるし、どっちのエンジニアにとってもいいと思う。

API設計

今回、はじめてバックエンドはAPIを提供するだけで、あとはクライアントでがんばるっていう開発をしている。始める前は「APIってControllerからViewを介さずにjsonで返すだけだろ」ぐらいに思ってたけど、全然そんなことなかった。

どこまでをクライアントで、どこからをサーバーのロジックとして持つのがいいのかよくわからない。ただCRUDだけ提供すると無駄にHTTPリクエストが増えるし、詳細な操作ができるAPIにするとRPCっぽくなる。今はそこらへんを思考錯誤しながら作ってる。

今回はクライアントとしてWebブラウザのみを想定してるけど、iOSやAndroidも使うこと想定したり、バージョニングを考慮すべきだろうと思う。設計考えるのおもしろいし、もっと勉強しないといけない。

参考にしたWebページたち

Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)

作者: 山本陽平
出版社/メーカー: 技術評論社
発売日: 2010/04/08
メディア: 単行本（ソフトカバー）
購入: 143人クリック: 4,320回
この商品を含むブログ (174件) を見る