World of granshe.

最後に

この春、6年間、仕事漬けだった人生を終えて、
新しい人生をスタートしました。

私はとても運がいい人間だと思っています。
行きたい高校にいけたし、行きたい大学にもいけた。
Webの仕事をしたいと思っていても、なかなか就職できない人がいる中で、わたしは新卒として、正社員として、Web制作の仕事に就けた。
制作業務でなく、会社のマネジメント業務にも関わり、この年で、会社がどういうことを考えているのか、経営側の考えも、理解することができた。
新しい人生を生きると決めたときも、未経験の私を拾ってくれる会社に出会えた。
本当に、私は恵まれていると思います。

ただ、そんな自分でも、
何かを得る代わりに、犠牲にしたものがあったし、
持ちきれなくて捨ててきたものもたくさんありました。

たぶんこれを捨てたほうがうまくいくから、と思って割り切って捨てたこともあれば、
両方持とうと思ったけどどうにも持ちきれなくて捨てたこともあるし、
たぶん、別のほうを捨てていたら、今とは別の人生を歩んでいたかもしれない、と今でも思い出す選択もあります。

人生の帰路に立ち、迷うこともたくさんあるけれど、
いつだって選ばない道が出てきます。

選んだ道で挫折をしたり、辛い、苦しい思いをするたびに、
あのとき別の選択をしていたらと思うことが、私自身何度かありました。

だけど、あるとき、
今私が生きている人生は、多くの選択肢の一つなだけ、なんだと思うようになりました。

発想は完全に中二病ですが、
別の選択をした私の人生は、別の選択をした私が、こことは別の世界で、精一杯生きているから、
あのとき諦めた未来を、別の選択をした私はきっと手にしているから、
だから、今この選択をした私の人生を、胸を張って生きようと、
そう考えるようになりました。

これからも、楽しいことばかりじゃないし、つらい思いも、苦しい思いもすると思いますが、
いつか別の道が見えるまで、この道を進んでいきます。

ゴールデンウィークあたりになったら、新しくブログを作ろうかなと思ってます。
ちなみに、自分の買った食べ物をひたすらアップするブログになる予定です。

最後に、私の大好きなクロノクロスのエピローグを引用して終わりたいと思います。

こうして、ひとつの物語は
幕を閉じる。

ながい時間が、すぎて・・・・・・・・・・
つかの間の夢はとおく過ぎ去り・・・・・・・・・
残されたのは、わたしと、
思い出だけ・・・・・・・・・・・・。

でも、いつかきっとまた会える、
あなたと、わたしは・・・・・・・・・・・。
別の場所、別の時間で・・・・・・・・・・・・・・。

互いにそうと気づくことは
ないかも知れないけれど・・・・・・・・・・・・。

知らない扉を開いて、
もうひとつの現実に出会う、
もうひとつの今日を生きよう。
物語は終わっても、
人生はつづく・・・・・・・・・・

だから、その時まで・・・・・・・・・・・
ごきげんよう。

分業のおしごとへの葛藤2

いつのまにか3末になってしまいました。
最後にどうしても書きたいことがあるので明日を最後の投稿にしたいと思います。

分業のおしごとへの葛藤、
もうひとつは、働く時間を自分でコントロールするのがとても難しい、ということでした。

ディレクターは忙しく、外出がち。
制作への依頼は夕方、定時を過ぎることも少なくはない。
デザイナーが既に帰っている場合、ちょっとした業務であれば自分が担当する。
デザイナーが残っていても、設計が必要になる作業であれば、デザイナーのデザインが完成するのを待ち、そこから作業に入る。

ディレクターが悪い？
とは思わない。

ほとんどのディレクターはたくさんの案件を掛け持ちしている。
一つの案件に割ける時間は少ない。どうがんばっても依頼が遅くなってしまうこともある。
そもそもお客さんの依頼が遅れた、という場合だってある。
一概にディレクターを責めることはできない。

ではデザイナーが悪い？
それも違う。

定時に帰って、定時後に修正依頼が来たら、咎められるべきでしょうか？
仕事がなかったら早く帰りたい。誰だってそうでしょう。
何も悪いことじゃない。

でも、今の会社では、職種に限らず
遅く残っている人が割を食うという現実があった。

作業者が早く帰ってしまえば、残っている作業者にお願いが行く。
残っている作業者は負担がより増える。

そして、仕事を引き受ける「可否」も、人によって違った。
無理に案件を引き受けない人もいれば、多少無理してでも、部署であふれた案件をもらう人もいる。

それは、個人が悪いと言われれば、それまでなのだろう。
遅くまで仕事をしたくなければ、嫌だと言えばいい。

でも誰も案件に入れなくて、誰かに振らざるを得ないとき、結局いつも「無理できる人」が割を食う。

案件が忙しくて手伝ってほしい、と言ったが、誰からも入れないと回答をもらったが、
実際には自分より早く帰っている人がたくさんいる。

誰も入れない案件を無理してもらって、ひとりで会社に残り、働く。
同僚への不信感が募り、孤独を深めていく。それを繰り返すと、そのうち、その人も、他の人が忙しいときに手伝わなくなる。

でも、
「じゃあみんなで仕事を分散しましょう」
ということは解決策にはならない。

「無理ができる人」と、「単に仕事が遅い人」の線引きが難しいから。

「早く帰れないのは仕事が遅いからでしょ？どうして私が手伝わなければいけないの？」
という場合も確かにあったから。

わたしには、その意見も理解できた。
だから、誰が悪いわけでもない。

それでも、そんな状況を見るたびに心が痛かった。
だから、手を差し伸べられるときは、なるべく差し伸べるようにした。
だけど、それも限界になって。

だから、結局、そこから目を背けたかっただけなんだと、思います。
その不公平さを見たくなかったから。だからその環境から逃げて、見ないようにしたかったんだと。
そう思いました。

分業のおしごとへの葛藤1

こんばんわ、ゆーりです。
3月も終わりに近づき、かなりチラシの裏になっていて申し訳ありませんが、
どうかご了承ください。

このブログにも何度か書いていますが、
私は受託でWeb制作を請け負う会社で働いていて、
仕事は、ディレクター、デザイナー、コーダーで分業することが多いです。

特に私が働いている部署は、わりと大規模な構築案件を請け負うことが多かったので、
部署内のメンバーもデザインとコーディングを兼任する人はほとんどいませんでした。

とはいえ、元々コーディングしかできなかった私は、会社に入る前からWeb制作を分業でやることが多かったので、
「こんなデザイン組めなくない？」という状況には慣れていたので、逆に
「こんなデザイン組めないよね？というのをどうやって組むかが、自分の腕の見せどころだ」
と思っていました。

それに変化が訪れたのは、私が在職して、3年を過ぎて仕事にも慣れてきたころ。
CSS3が使われはじめ、スマホサイト、RWDサイトの案件が増えはじめたころでした。

今でこそフラットデザインが流行っていますが、
当時はCSS3が微妙に知られ始め、角丸やグラデーションがCSSでできるらしいよ！という情報だけがひろまり、デザインで多用され、
CSSで組んだら「IEでも同じ見た目じゃないとダメだって」といわれ結局画像で組みなおしたり。
角丸＆グラデーションのボックスがあるたびに、たくさんdivを増やしたり、文字量が増えても大丈夫なように、背景画像を伸ばして実装してあげたり。

CSS3くらいならまだよかったのですが、
RWDにもなると、PCとSP、ワンソースで提供するにもかかわらず、そもそものワイヤーフレームの時点で、明らかにPCサイト／スマホサイトでコンテンツが違っていたり。
デザインで出来上がったものを見ても、PC幅、SP幅で使いまわすはずの画像の縦横比が違っていたり。

そしてそれと同じころ、キャリアをある程度積んで、周りが見えるようになって、
仕事を進めていくうえで納得ができないことも増えた。

先ほど挙げた例もそうですが、
自分よりも経験の浅いディレクターと組む機会が増え、お客様にちゃんと説明できてるのかな？と疑問に思ったり。
それとは逆に、自分が仕事でミスをしたときは、お客様とやり取りするディレクターが謝ることになる。
「謝るのがディレクターの仕事だから」
と言ってくれたけれど、申し訳なく思ったし、
自分で責任が取れればと感じることが多くあった。

それが積み重なっていくうち、分業で働くことに、ストレスを感じ始めるようになっていきました。

どうしてそうするのか、の理由がほしかった。
理由さえわかれば、divだらけのサイトだって作るし、IE8用のCSSを書くことだって納得できた。
理由さえわかれば、お客さんの要望に合う、別の方法を提案することだってできるかもしれない。

「自分ではどうすることもできない」部分が多いことにフラストレーションを感じ始めていた。
だから、仕事の全てを自分で全てできるようになれば、納得ができると思った。
自分ではどうにもできない「他人のせい」を少なくして、「自分のせい」の範囲を増やしたかった。

この会社でそれをするには、自分ひとりで案件を回せるようになるという選択肢しかない、と考えた。

でも、それを思いついたときには、既にフロントエンドエンジニアとしてのキャリアを積みすぎていた。
というよりも、もはやフロントエンドエンジニアとしてしか使い物にならなくなっていた、というほうが正しい。

私がディレクションもやり、デザインもやるということは、一人で回せる規模の案件しかやらないことになる。
大規模案件を持って、設計、JS、CMS構築にまで携わってきた人間が一人抜けることと同じだ。
そして今さら、ディレクションやデザインを学んだところで、ものになるのはずっと先だろう。

それは、会社にとってメリットがあるのか？
という疑問を、説得できる言葉が見つからなかった。

きっと私が、本気でそれをやりたいと言ったら、会社はきっとそのチャンスを提供してくれたと思います。
でも、それを提案できるくらいの、本気度と、覚悟が、私にはありませんでした。

その先も、その働き方で生きていくのか？と自分に問いかけたとき、
「そうだよ、ディレクションも、デザインも学んで、この会社でずっと働いていくんだ。」
という気持ちにはなれなかったのでした。

「好きなことを仕事にしてはいけない」という意味

今月でWeb制作のおしごとを引退する私ですが、
その退職理由の15％くらいを占めるのが「好きなことは仕事にしてはいけない」という言葉の意味に気付いたからです。

なのでそれについて書いてみたいと思います。

高校生のとき、自宅にWindows98がやってきて、
私はWebという世界を知りました。

そこから、HTMLを学び始め、大学に入学してから、Webサイトを作る仕事があること、
そして、HTMLを書く人＝マークアップエンジニアという職種があることを知り、デザインセンスが皆無のわたしはそこからマークアップエンジニアを目指すことになりました。

文章をどうマークアップするか、考えるのが好きでした。
CSSでできることが増えるたびに、嬉しくて、
HTMLを、CSSを書くことが楽しくて、これを仕事にできたらいいなと思っていました。

世の中には、仕事は仕事と割り切ってこなし、プライベートを楽しむ人と、
好きなことを仕事にする人の2パターンがありますが、
私は完全に後者でした。

「好きなことは仕事にしてはいけない」という言葉は知っていましたが、
好きじゃないことを仕事にするのは考えられなかった。
就職活動のときも、Web制作会社以外は受けなかったし、
受からなければアルバイトで入社すればいいと思っていました。

ただ、実際に働いてみると、仕事としてのWebと、自分の好きなWebには隔たりがありました。

私はHTMLが好きだったので、なるべくキレイなコードを書きたかったけれど、
運用しやすさ、多様なデザインに対応するため、
たくさんのクラスが出現し、たくさんのマージン調整クラスを書き、たくさんのspanやdivが生まれていきました。

理想のマークアップは何度も思い描いたけれど、
それを仕事で生かせる機会は、本当にごくわずかでした。
（もし、自分が受託ではなく、内製の制作会社にいたら、違ったのかもしれないですが。）

でも、目的があれば、それは仕方がないことだと割り切れました。
そのサイトを運用するのは、自分ではないから。
だから、なるべく努力はするけど、ある程度目をつぶらなければいけない部分はある。
そう思って仕事を続けていました。
実際、HTMLやCSSを書くのは好きだから、今まで仕事を続けてこられたのだと思います。

だけどしばらくして、お客さんから「サイトをリニューアルしたらPVが2倍になりました！！」というお話を聞くよりも、
自分が納得したマークアップができたWebサイトを作ったときのほうが、ずっと嬉しいことに気付きました。

もちろん、お客さんのことを全く考えていないわけじゃなかった。
自分なりに、GAだって解析したしアクセシビリティだってユーザビリティだって考えて仕事はしていた。
それでも、一番嬉しいのは、自分の納得のいくマークアップができたときでした。

そのときに、
自分は、作品としてのWebが好きなだけで、商品としてのWebに興味がないんだ、ということが、わかりました。

そしてそれが「好きなことを仕事にしてはいけない」という言葉の意味だったのか、と、
理解しました。

絵が好きだからといって、デザイナーに向いているわけではない。
デザイナーは、デザインによって問題を解決する仕事。
自分が好きなようにデザインしていても、それが問題解決にならなければ、意味がない。

それと同じで、私は自分のフロントエンドの技術でお客様の問題を解決したかったのではなく、
ただ単純に、HTMLが、CSSが好きだっただけ。
ただ書くのが楽しかっただけ。

私はただ、実践で素早くマークアップをするよりも、じっくり考えて、納得のいくマークアップを探したかった。
クラスなんていっぱいつけたくなかったし、spanもdivも何重に使いたくはなかった。
デザインなんかよりもマークアップを優先させたかった。
納期なんかよりも、自分が納得いくまでマークアップを模索したかったんだと。

でも、それで食べていけるほど、私には技術力と覚悟がなかった。
絵が好きだからといって、誰もが芸術家になって食べていけるわけではないように。

好きなことは仕事にしていい。
その考え方は間違っていないと、今でも思います。
私の人生においては、好きじゃないことを仕事にするのは、やはり考えられないことなので。

でも、「絵が好きだから、デザイナーになる」というような安易な考え方をしてその道を選ぶと、いずれ続かなくなります。

デザイナーになれるのは、自分の持っているデザイン技術を生かして、お客様の問題をどう解決するか考えられる人、自分の持っているデザイン技術で、誰かを喜ばせることが嬉しい、と考えられる人です。

「自分が好きな絵を描きたい」のと、「絵を描くことが好きだから、それを生かして仕事をしたい」の間には、言葉以上に大きな隔たりがある。

それを今さら体感したので、書いてみました。

無期限更新停止のおしらせ

大変ご無沙汰しております。ゆーりと申します。

私事で恐縮ですが、このたび、3月いっぱいで現職のWeb制作会社を退職することにしました。

Webの世界から完全に足を洗うことにはならないのですが、
自分自身の中では、フロントエンドエンジニアとしての人生は現在の会社で終わりにするつもりでいます。

Web制作技術の情報をお求めで、このブログを購読していただいたり、Twitter等でフォローしてくださっている方がもし、いらっしゃいましたら、解除いただくことをおすすめいたします。

このブログは、私がマークアップエンジニアの端くれとして、自分がインプットしたものを、少しでもアウトプットができれば、と思ってはじめたものでした。

屋号にはとても愛着があるので、もしかしていつか、どこかで、別のかたちでブログを書きはじめようかと思っていますが、この場所での更新は3月をもちまして無期限の更新停止といたします。

今の会社には新卒で入社して、丸6年、フロントエンドエンジニアとして働いてきました。

次の職場には多分その半分くらいの経験しか持っていけないくらい、今とは仕事内容が変わります。

正直、迷いもありましたし、今でも、本当にこの道でいいのか、不安になるときもあります。

それでも、自分の目指すところに向かっていると、信じているので。

これから先、どんな未来が待っているのか、自分でもわからないですが、

何もしないで後悔するよりは、何かして後悔したほうがいいに決まっているので。

これからも前に進んでいくつもりです。

なので残り1ヶ月は、私が現職で得たもの、失ったもの、

などについて、たれ流していきたいと思います。

CSS Nite LP35「マルチデバイス対応 2014」に行ってきた

気付いたら半年以上ご無沙汰していました･･･。生きてます。

ひさしぶりにセミナーに参加してきたのでレポートを書いてみます。とてもざっくりと。

基調講演：スマホサイトの今、スマートデバイスのこれから

たにぐちさんのお話ははじめて聞くのですが、とてもお話がわかりやすく、スッと脳内に入っていく感じでした。

技術は日々進歩し、新しい端末が出て、回線も早くなっていくわけで、そういった未来が確かにあります。

パフォーマンスだいじだよ。サイト軽くしようよ。と言ってみても、「今はLTEでてるよ？」とか、「コレが増加するとどれくらい重くなるの？たいしたことないよね」みたいな発言に対し、うまく説得できない自分がいたんですが。
（「表示が速くて悪いことはない」という名言も、実際には届かないことが多い）

今、最新端末より1世代型落ちの機種を使った、格安スマートフォンが相次いで発売されている。 Appleはそういったことはしないので、それらは無論Android端末。そして、それらはスマートフォンを持っていない、アプリなども使いこなす必要がない一般の人向け。それらの回線は、総じて遅い。

新しい端末が出ても、しばらくは古い端末が回線も遅いまま、供給され続ける。そうやって、安いAndroid端末がこれから増えるのではという予想。

自分が想像していた未来とは全く違う視点にとても驚かされたし、今回のイベントの中で一番「すごいや！」と目からウロコだったのはこの基調講演でした。

レスポンシブWebデザインのワークフロー

とてもわかりやすい内容でした。RWDやりたての方には、とても学ぶことの多いお話だったと思います。

RWDはウォーターフローよりはアジャイルが向いてる。分業している場合は、コーダーは上流工程にまで関わることでうまくいくよ。それぞれの職域を越えていこうね。というお話。

自分個人としては、自分が思っていること、考えていることをそのまま代弁していただいたような感じで、「自分の考えてることは間違ってないんだ」「方向性はコレでいいんだな」と再確認できました。

ブレークポイントについても触れられていて、自分としてもブレークポイントについては最近言いたいことがいっぱいあるので（他のブログでも示唆されてるような二番煎じ的な感じですが）いずれ機会があれば･･･。

マルチデバイス対応な実案件で使う、Bootstrap のすゝめ

自分はBootstrap否定派だったのですが、あぁ、そう使えばいいのね。なるほどねー！と感じました。

ただ、『最初っからBootstrap使わない想定だと無理だね。』というところがハードルが高くて。心が折れちゃいました。
弊社はほぼ分業制で、これでワイヤー書いてね、みたいなテンプレートが既にあるので、なかなかここが難しいんだな･･･と。

フレームワーク系は『class名がセマンティックじゃないからやだよ』と思っていたのですが、Sassのextend使えばclass名好きに指定できるよね！というお話をされていてなるほどそれはそうだなぁと思いました。

スマートデバイス時代のJavaScript

ちょうど案件でzepto.jsを使おうと思っていたので、タイミングがとてもよかったです。

強いて言えば、最近TypeScriptに興味があったので、TypeScriptについてもう少し詳しく説明いただけると嬉しかったが･･･ここまでの流れから、たぶん今回のセミナーは初級者向けっぽいな、という流れだったので、あきらめて涙をのむ。

jQueryでJS書くのが当たり前になっているけど、スマートデバイスの回線のことを考えると、ほかのライブラリについても考えていいんじゃないか？プリプロセッサ使ってもいいしさ！という内容。

個人的にはセッションで紹介されていたvanilla.jsが非常にツボりました。すごいぜvanilla.js！！
･･････勉強します｀；ω；´

あと、Angular.jsも勉強してみては？というコメントを聞いて、勉強しようと思いました。
ホント、最近現場離れ気味なので、技術系疎いっす･･･。

UI設計に役立つ！意外と知らないiOS/Androidの流儀

Androidと、iOSの仕様の違いを比較しながら解説されていたプログラムでした。

基本的には、仕様書の中での2つのOSの差異を、対談しながら拾っていった感じでした。

一番印象に残ったのは、「Pure Android」という項目がAndroid側のガイドラインにあること。
「他のOS（iOSやWindowsなど）の概念を持ち込まないでくれ」というのが明示されているそうです。
わざわざ記載されているのはiOSのアプリのインタフェースがAndroidアプリにそのまま持ち込まれがちで、統一感がなくなってしまった経緯があるからだとか。

トラブルシューティング 2014

登壇したお二人のかけあいが面白くて楽しく聞けました。ちょっと会社を見学してみたくなりました。

セッションの本題ではないものの、やっぱりGrunt（タスクランナー）すごいなというのが感想でした。
メディアクエリーの記述をひとまとめにしてくれるcombine-media-queries。
あとはセッションで直接紹介されてはなかったけど、プロパティの記述順を整理してくれるcsscombや、もはやデフォルトになっているauto-prefixerやlivereloadX。

Gruntは導入のハードルが高くて、なかなか前に進めなかったんですが、これはやってみないといかんな。。。とあらためて実感しました。

あとは、最後のほうに紹介されていたpleeease。
ポストプロセッサとプリプロセッサの違いがわからなかった自分はこちらの記事で勉強しました。 CSSポストプロセッサー時代の到来

所感

セミナーの内容としてはわりと初級者向けの内容で、参加したことに後悔はしていませんが、自分にとっては物足りないといえば物足りないというか。フォローアップ参加だけしていても元は取れたような気はします。

ただ、今回はちゃんと名刺を持って行ったこともあって（前回は仕組みがわからず持っていかなかった）、コミュ症の自分にしては幸運にも、お近くに座っていた数名の方と少しお話しすることができました。それはセミナーに参加しないとできないことだったので、自分にとっては大きな収穫でした。

制作会社のなかではわりと大きめの規模な会社に勤めていることもあって、社名をご存知の方も多く驚きました。（自分はポンコツですが

最近、わりと会社の上流の部分に顔を出すことが多くなったので、会社の仕組みとか具体的に説明することができるようになった自分がおり、「コーディング楽しいよね！会社のこと？おっきいかいしゃだし上の人が考えてることはわかんないです☆」みたいな受け答えをすることもなく、自分、大人になったなぁとしみじみしたりしました。

ということで以上になります。
今後はもうちょっと頻繁に記事を書いていきたいですね。。。
ネタはぽつぽつあるんですが、なかなかまとめきれないです･･･（涙

CSSプリプロセッサについて～Sass、LESS、Stylus

すいません、『わたしの作業環境』シリーズでつなげようと思ったんですが急遽気になるネタを見つけてしまって。

CSSプリプロセッサ（CSS拡張メタ言語）広まってきて久しい？ですが、有名どころはSass、LESS、Stylusだと思います。
サーバサイドがどうとか、環境が必要とか、インストールに関する内容はなんとなく知ってはいるのですが、
具体的な機能や文法の違いを明確に知らなかったので、ふと検索してみると私にぴったりのスライドが見つかりましたので抜粋して紹介したいと思います。

毎度のお断りで恐縮ですが、超意訳です。
詳細はぜひ、本家のスライドをご覧くださいませ。英語わからなくても、コードが書いてあるので読みやすいスライドだと思います。
CSS PreprocessorsSass, Less and StylusPatrick Arlt - @patrickarlt

で、結局どれがいいの？

という問いに、@patrickarltさんは
『端的に言えばSassかStylus』。丁寧に言うと
『Ruby使ってんならSass。Node使ってんならStylus。コマンドライン（いわゆる「黒い画面」）が嫌いなやつはLESSな。』
とのこと。

どう違うの？

Sassの特徴

@extend　→　クラス名は違うけど、ベースのスタイルが同じときに、2回同じコードを書くのはめんどくさい。それを簡単にするのが@extend。
@media　→　mediaqueryをセレクタの中に書ける！
@content　→　自分が使いこなせてない機能なので説明が難しいですが、ある条件ではこのスタイルをあてたいけど、という条件分岐に容易に対応できるものだと思います。
Compass　→　言わずもがな。

LESSの特徴

Mixins　→　CSSのプロパティを記述する場所に、CSSのクラス名を指定するだけで、そのクラスのスタイルが読み込まれる。（変数として格納する必要なし）
Namespacing Mixins　→　CSSとLESSのクラス名のかぶりを防ぐのに使える機能みたいなのですが、使える場面がぱっと場面が浮かびませんでした･･･。
Scoped Variables　→　CSSのセレクタ内で変数の上書きができる。
クライアントサイドでコンパイルができる。（使用時にRubyやNodeのインストールが不要）

Stylusの特徴

CSSの記述に必要なコロン「：」、セミコロン「；」を半角スペースで代用できる
forループやif文などを用いた条件分岐をプログラミング言語に近い感じで行える。
CSS3のキーフレームの実装がとっても楽
APIでいろいろできるらしい（すみません、曖昧で。。。）
Nib　→　SassでいうCompassみたいなもの。

自分はSassしか使ったことがなかったのですが、
Nodeをインストールしてるので、Stylusはありかもなぁと思いました。
日常的にCompassやNibの機能を使いこなしてるような人だと、たぶんLESSに戻るのはつらいのかなぁと。
LESSでもCompassやNibにあたるものはないという認識なんですが、存在するんですかね。。。

MacユーザーはデフォルトでRubyが入ってるので、Sassへの敷居は低いかもしれないですね。
自分は会社でも家でもWinユーザですが、周りでもやっぱりRubyのインストールにてこずる人は多いので。

LESSとStylusの特長をほぼ知らなかったので、勉強になりました。

わたしの作業環境：Sass＆Compass編

お疲れ様です、完全社畜と化しております。
でもそれには理由があって、今後のために「今」必要だという、自身の判断でやっています。
なので、今までのキャリアの中では、仕事量に比べて、精神的には非常に前向きに仕事ができてます。

ということで、ネタとしては今さら感満載ですが、
最近作業環境をガラッと？変えました。
今度社内勉強会に向けてまとめようと思ってるので、事前にここに書いてみます。

一応サブタイトルとして
「Sass＆Compass＋Sublime＋LiveReload」ってついてまして（自分の中で）、
3本立てでお送りする予定です。

時間がなかったので、とりいそぎSass＆Compassから。

Sass＆Compass

今回の隠れサブタイトルの中で最初に導入したものがコレです。
最初は、「CSS3のprefixをつけてくれる便利なやつ」だと思ってたのですが、
それだけじゃない。
そして今も、きっとこんなもんじゃない。まだ使い切れていない何かがある。と思ってます。

ちなみにSassとCompassインストールしている前提で、自分がどういう機能を使っているのかを書いています。
自分は下記サイトを見てインストール含め基本的なところを学びました。

前準備

自分はいつも下記の指定を最初にしています。

@import "compass"; // compassを使うときの指定です。たいてい使います。
$experimental-support-for-svg: true; //IE9でgradientしたいときは必ず。

機能1：入れ子

個人的には最近はあまり使わないですが、CSSを深い入れ子にするときにSassは便利です。

Sassなし

#container{
max-width:960px
}
#container .hdg01{
font-size:
}
#container .txt01{
line-height:1.5;
}
#container .txt01 a{
color:#9cf;
}

Sassあり

#container{
max-width:960px;
  .hdg01{
  font-size:1.25em;
  }
  .txt01{
  line-height:1.5;
    a{
    color:#9cf;
    }
  }
}

Sassではこんな感じで書けます。

入れ子でCSSを書くのがあまり好きではないのと、
インデントがあまり好きではないので、最近はあまり使わなくなりました。
（インデントしなくても書けるんですが、読みづらい

機能2：import

一昔前に、@importでCSSを1ファイルにインポートするのが流行ってませんでしたか？
私もやってました。
その後、@importだとパフォーマンスが悪いということで、CSSは@importせず、直接1ファイルで読み込むのが主流になりました。

私自身、大きなサイトを作ることがあまりなかったので、スタイルを1ファイルでさせることに対して、苦労はほとんどなかったのですが、
最近、CSSを大量に書く機会が増え、コードを探しにくくなってきました。
そこでimport。

この記述を書くと、sassが勝手にCSSファイルをまとめて結合してくれます！素敵！

結合したいファイルの頭にはアンダースコア「_」をつけます。
（CSSファイルとして出力されることはなくなります）
basic.scss（出力ファイル）のほかに、_base.scss、_modules.scss を作ります。
basic.scssに下記の記述をします。（アンダースコアは除いてOKだそう。
```
@import "base", "modules";
```
書き出すと、basic.css内に、_base.scss、_modules.scssの内容が出力された状態になります。

管理は複数ファイルだけど、最終的に出力されるCSSは一つになるので、便利。
複数人で設計をする際も、マージの心配をせず作業することができますしね。

機能3：Mixin

良く使う機能をmixinとして保存しておくことができます。

たとえば自分が良く使うのは、これ。

@mixin iAbs {
content: "";
display: block;
position: absolute;
}

擬似要素をbefore＆afterでアイコンをつけるとき用のmixinです。

IE8以上対応の案件ですと、私はsprite＋before＆afterを多用します。
毎回登場するたびにスタイルを書くのが苦痛だったのですが、mixinを使うと指定が楽にすみます。

Mixinなし

.xxx:before{
content: "";
display: block;
position: absolute;
top:10px;
left:0;
}

.xxx:after{
content: "";
display: block;
position: absolute;
top:50%;
right:0;
}

.ttt:before{
content: "";
display: block;
position: absolute;
top:10px;
left:10px;

記述場所がくっついていればいいんですが、いろんな場所で使ったりするので、コピーしてくるのが大変です。
そこで、mixinを使うと、こうなります。

@mixin iAbs {
content: "";
display: block;
position: absolute;
}

.xxx:before{
@include iAbs;
top:10px;
left:0;
}

.xxx:after{
@include iAbs;
top:50%;
right:0;
}

.ttt:before{
@include iAbs;
top:10px;
left:10px;
}

楽ですね！

他にも、色をmixinでストックしておけば、
サイトで使われている配色を少し変えたいときも、1箇所に色の指定をまとめておけば、
置換することなく、変更することができて便利なのです。

機能4：自動prefix

Compassを使うと、自動でprefixを生成してくれます。
現状、自分が使っているのは下記。です。

@include box-sizing(border-box);
@include background-image(linear-gradient(#efefef 0%, #dfdfdf 100%)); 
@include rotate(-45deg);

機能5：Sprite

CompassにはSpriteを簡単に生成してくれる機能があります。
一度使うと、これなしでは生きていけなくなります。

使い方（設定

$icon-spacing:2px; // 生成されるsprite画像の、画像同士のスペースです。
$icon-sprite-dimensions:true; // sprite内のアイコンの幅・高さを出力します。
@import "icon/*.png"; // iconフォルダに入ったpng画像をsprite化する、という指定です。

Sass側で、画像の出力先を指定することができます。
Sassのconfig.rb内で

images_dir = "shared/images"

と記述していた場合、sprite画像は「shared/images」配下につくられます。

その出力先のフォルダ内に、sprite用の任意の名前のフォルダを作ります。
上の例でいくと、「icon」というフォルダです。

@import "icon/*.png"

sass側の画像の出力先「shared/images」からの相対パスを記述します。

このフォルダの名前は任意で変更できます。sprite画像を複数作る場合は、下記のように指定します。

$icon-spacing:2px;
$hdg-spacing:2px;
$icon-sprite-dimensions:true;
$hdg-sprite-dimensions:true;
@import "icon/*.png";
@import "hdg/*.png";

これらの指定をして、iconフォルダに、spriteしたい画像を入れていきます。

これをコンパイルすると、自動でに結合してくれます。
結合したファイルの名前は、フォルダ名と同じになります（この例の場合、icon.png）

なお、普通にspriteを作ると、ランダム文字列が生成されます。（キャッシュ対策？）
これを消したい場合は、下記のような指定をconfig.rbに追記します。

# Make a copy of sprites with a name that has no uniqueness of the hash.
on_sprite_saved do |filename|
  if File.exists?(filename)
    FileUtils.cp filename, filename.gsub(%r{-s[a-z0-9]{10}\.png$}, '.png')
    # Note: Compass outputs both with and without random hash images.
    # To not keep the one with hash, add: (Thanks to RaphaelDDL for this)
    FileUtils.rm_rf(filename)
  end
end
 
# Replace in stylesheets generated references to sprites
# by their counterparts without the hash uniqueness.
on_stylesheet_saved do |filename|
  if File.exists?(filename)
    css = File.read filename
    File.open(filename, 'w+') do |f|
      f << css.gsub(%r{-s[a-z0-9]{10}\.png}, '.png')
    end
  end
end

また、画像をひとつにまとめてくれるだけじゃなく、CSS側での指定も自動で行ってくれます。

Sassの記述

nav a:after{
content: "";
display: block;
position: absolute;
top:10px;
left:0;
@include icon-sprite(arrow1);
}

// ※さっきのmixinを記述すると、もっと簡単に。
nav a:after{
@include iAbs;
top:10px;
left:0;
@include icon-sprite(arrow1);
}

出力されるCSS

nav a:after {
  background: url('/shared/images/icon.png') no-repeat;
}
nav a:after{
content: "";
display: block;
position: absolute;
top:10px;
left:0;
background-position: 0 -39px;
height: 11px;
width: 11px;
}

画像ファイルが増えても、background-positionを再計算してくれます。
便利ですね！

こういうのは実際に動いてるの見せないと、なかなかやってみようかなっていう気にならないですよね。実際にはライブコーディングでやれたらなぁと思ってます。

別に、「みんなこれ使えよ！」ってわけじゃないですけど、こーいう便利ツールを知ってると、楽しくなるよ、ということは伝えたいです。

Markdownで記事を書く、データベース不要のCMS、Picoを使ってみた

だいぶご無沙汰しておりました。
久しぶりに自分のブログを見に行ったら広告が出現していて震えました。前回から3ヶ月も経っていたとは。。。

激務に激務を重ね、ようやく落ち着いてきたので、広告消すためにも記事を。

案件が落ち着いてきたというのもあり、今までまわりになかった技術に手を出すようになり始めました。
今さらながらSublime Text2を使ってみたり、Emmetをつついてみたり。Markdownについても最近触れる機会が多く。

そんなときに、Markdownでコンテンツを記述する、データベース不要のCMS『Pico』なるものを見つけたので、今回ご紹介いたします（通販風）。

Picoとは

本家サイトはこちらです。→Pico
すっげえシンプルで、（DBを使わないので）表示がめっちゃ早いCMS。Webを簡単に作れるぜ！（超意訳）
とのこと。

特長は、データベースがなく、テキストをマークダウン形式で書くところ。
ヘッダーとフッターとサイドナビをPHPで自動で付与します。編集も可能です。
URLのルールとかはPico本家のドキュメントを見てください（割愛）。

ファイルはマークダウン形式（拡張子は「.md」）で生成して、直接サーバ上に置きます。
簡単にファイルを作成できるプラグインは後ほどご紹介します。
あ、データベースは必要ありませんが、PHPは必要です。PHP 5.2.4以上のバージョンが必要です。

自分は、Twitterでお気に入り登録した記事が埋もれて探せなくなるのを救出するために、
まとめリンク集をためしに作ってみました。（まだ調整中ですがフライングで

導入方法

1．ダウンロード

Picoダウンロードページから、Downloadボタンを押してファイルを取ってきます。

このタイミングで、同時にプラグインも落としました。
Picoプラグインページから、お好みのプラグインを取ってきます。
自分はあまりRSSに興味がなかったので（ブログとして使う想定ではないので）RSSは除き、それ以外の二つはダウンロードしました。
以降は、上記プラグインをダウンロードした前提で話が進みます（汗）。すみません。

2．サーバにアップ

PicoはPHP 5.2.4以上がサーバにインストールされている必要があります。

PHPのバージョンを確認したら、Pico-masterの中身をお好きなディレクトリにアップします。
ダウンロードしたプラグインは、Pico本体の「/plugins/」ディレクトリの中に入れてください。

Pico Editorというプラグインは、入れるとWeb上でMarkdown形式で記事を記載＆プレビューでき、自動でファイルを保存してくれるのでぜひ入れることをオススメします。

3．Pico Editorの設定

Pico Editorをダウンロードしたら、フォルダ内にある「pico_editor_config.php」を開きます。
任意のパスワードを設定してください。（何でもかまいません。）
パスワードはそのまま指定するのではなく、ジェネレータで変換したものを入れてください。

パスワードの設定が終わったら、Pico本体のpluginsディレクトリの中にアップします。

アップが終わったら、アップロードした場所のURLの後ろに /admin/ を入力すると、ログイン画面が開きます。
先ほど設定したパスワードを入力して、ログインします。

ログインすると、デフォルトのファイルが3つほど表示されていると思います。

何度か試してみたのですが、どうもこのエディタは、エディタ上で作られてないファイルは編集も削除も出来ないようです。
なので、デフォルトのファイルに関しては、エディタからではなく、サーバ側から直接削除します。

わたしは、Pico本体の「/content/」フォルダの中に入っている「/sub/」ディレクトリ配下の.md ファイルを削除し、
Pico本体の「/content/」フォルダの直下に入っている「index.md」をテキストエディタで編集してトップページを作りました。

4．サイトの設定

サイトのタイトルを編集するには、Pico本体のルートフォルダにある「config.php」を修正します。
初期状態では全てがコメントアウトになっている状態なので、タイトルを変えたい場合は、
$config['site_title'] = 'Pico';
をコメントの外に出して調整します。

ヘッダーやフッターなど、共通部分のHTMLを変更したり、スタイルを変えたい場合は、
「/themes/default/」のHTMLとCSSを直接修正するか、
あたらしく「/themes/」ディレクトリにテーマ用ディレクトリを作成し、「config.php」に
$config['theme'] = 'ディレクトリ名'
を指定してください。

5．Pico Editorを使って記事を追加

http://アップロードURL/admin/ にアクセスし、ログインして記事投稿画面に遷移します。
画面の左側上部にある「＋」マークでページを追加します。

ページ追加のコツですが、2点あります。

please enter a post titleの画面では、ファイル名（英数字）を入力すること。
新規作成すると、テキスト内にコメントで「Title:」と入っている部分があるので、そのファイル名を日本語に変更する。

そうすると、ディレクトリ名は英数字になり、サイト内のメニューとしては日本語が表記されるようになります。

エディタの右下に「目のマーク」があるのですが、これを押すとマークダウンされたものが簡易的にプレビューされます。

文字を入力していると、画面右上に「Saved」というアイコンが出ますが、
このエディタでは情報はリアルタイムにセーブされます。

「Saved」というアイコンが出る前に別のページに遷移しようとすると、
「セーブしてないからデータ消えるよ？いいの？（実際は英語）」とアラートが出るので、キャンセルを押して、
しばらく待つか、適当に文字を入力してみるか、「目のマーク」を押してプレビューしていると「Saved」が出るので、セーブされたことを確認して別のページに移動してください。
セーブまでには若干のタイムラグがあります。

ちなみに、Pico Editorを使わなくても、「ファイル名.md」でファイルを作成して保存し、
「/content/」ディレクトリ配下にFTPでファイルをアップロードすれば、ページを作ることは可能です。

一度セッティングが終わって使い慣れれば、かなり楽です。
セッティングするまでと、軌道に乗るまではだいぶ大変かもしれませんが･･･（笑

自分が主につまづいたポイントを整理します。

アップロードしたけど、トップページが表示されない。
→PHPのバージョンが足りていなかった。
Pico Editorで記事が編集できない。
→Pico Editorで作成したファイルでないと、編集が出来ないようです。（デフォルトで入っているファイルは編集できない）
Markdownの記法を忘れた。
→Markdownの文法はこちら

一度マークダウンに慣れると、HTMLもマークダウンで書いてしまいたくなります（笑）ぜひおためしくださいませ。

レスポンシブWebデザインにおけるコーダーの役割

先日、Twitterで
『レスポンシブWebデザインをする際に、ナビゲーションなどをPC用とSP用の2種類、HTML内に書いて、出し分けることがあるようだ』
というようなことをつぶやいたのですが、自分では思ってもいないところでリツイートされました。

自分はちょっとした愚痴のつもりで書いたのですが、これはもうちょっと深く考えるべき問題なのかもしれない。と感じ、
自分なりにもうちょっと考察して、人と話して、自分なりの答えが見つかったので書いてみます。

私の周辺では、レスポンシブWebデザイン（以下、RWD）の案件をやるとき、「PC用」「スマホ用」2種類のデザインをお客さんに提出し、それをベースにコーディングすることが多いです。
PCサイトとスマートフォン最適化サイトを両方作るのと同じような手法です。
いわゆる「スマートフォン最適化」では、PCとスマホ用のHTMLは別で作れますので、デザイン上の制約はあまりありません。

でも、RWDは1つのHTMLを複数のデバイスにうまくフィットさせるための技術。
「PC用」「スマホ用」に別で作られたデザインを、1つのHTMLで実装する、ということではありません。
冷静に考えれば、2つの異なるデザインを1つのHTMLで実装しようとすること自体、不可能ではないでしょうか？

でも、RWDというあたらしい手法が誤解され、免罪符として使われ、
「RWDだからしょうがないんだろうな」と言って、
「PC用」「スマホ用」で、どう考えても1ソースで組めないようなデザインでも、 HTML内に複数回要素を繰り返して、mediaqueryでウィンドウ幅によってdisplayを切り替えて実装してしまう、という例があるようなんです。

マークアップエンジニアとして普通に考えたら、
HTML内に同じコンテンツを2回繰り返して、それをdisplayで表示切替する、なんていうのはありえない手法です。

それが、なんだか『角丸実装するのに不要なdivちょっと入れようかな。仕方ないけど。』くらいのレベルで、
同じコンテンツをHTML内に複数回入れることが行われていたんです。

『デザインはもう変えられないから、仕方なくやった。』

という理由で。

これは、今まで、弊社が主に「分業」で案件をすすめてきたことに起因していると考えています。

ディレクター、デザイナーは、コーディングの技術的な部分に関してはあまりよく知らない。
コーダーはデザインに関して、あまり積極的に関わらない（受身）。

だから、コーディング可否の判断がされないデザインがあがってきて、
「デザインは絶対に変えられないもの」だと刷り込まれたコーダーはそのまま組む。
という図式になってしまっている。

従来のWeb制作ならそれでもよかった（よくはないけど）。
ただ、「RWD」という1つのHTMLで実装しなければいけない案件で、「PC用」「スマホ用」の複数パターンのデザインが上がってくる現状を考えると、
この図式なら『デザインはもう変えられないから、仕方なくやった。』
ということになるのは必然かな、と感じる自分もいました。

それを、
『ディレクター、デザイナーが技術的なことを知らないから、悪いんだ！』
『自分はコーダーとしてがんばってる、何も悪くないんだ！』

と結論付けるのは簡単ですが、上記の考えではおそらく、何の解決にもなりません。
なぜなら、あまりに「他力本願」だからです。

ディレクターがもっとRWDについて学べばいいんだ、デザイナーがCSSをもっと学ぶべきなんだ、
という意見は正しいし、本来ならそうすべきでしょう。
でも、「他人を変える」のは非常に難しいことなんです。

何かを変えたいとき、その一番の近道は「自分が変わる」こと。
だから、「自分（コーダー）がどう変わったら解決するのか？」を考えました。

じゃあ具体的にどうするのか？

『コーダーがデザインすればいい』んです。

作業フローはこうです。

ベースのデザイン（これがPCかスマホかは決めの問題だが、とりあえず1枚）をデザイナーに作ってもらう。
ベースのデザインを元に、コーダーがmediaqueryで動きを作っていく。
それをデザイナー、ディレクターにプロトタイプとして出して、動きのレビューをしていく。

よくよく考えれば、
そもそも「レスポンシブWebデザイン」で、「PC用の見た目」「スマホ用の見た目」をデザインすること自体がおかしいのですから、ベースのデザインテイストだけデザイナーに作ってもらって、それ以外は全部コーダーで巻き取ってしまえば、全てうまくいくのです。

今までコーダーは、デザイナーの作ったデザインを、そのまま組めばよかった。
基本的にデザイナーはコーダーに相談せずデザインをしていたし、
コーダーがデザイナーに意見を言うこともほとんどなかった。

でも、上記のフローでは、デザインのベースはデザイナーが作るけれど、それを「アレンジする力」がコーダーに求められます。
コーダーがデザインについて学び、他のサイトの事例について勉強する必要があります。

『そこまでコーダーがやるの？』と思う人もいるかもしれません。
もし『ディレクターやデザイナーに勉強させる』ことが出来るなら、やらなくてもいいと思っています。
でも、「他人が変えられない」なら、「自分が変わるしかない」んです。

それに気づかされて、正直「怖い」と感じた自分がいました。
「デザインをやりたい」と思いながらも、デザインすることから逃げて、
結局デザイナーに全て任せて、デザインを見て、「これはできません」と言っている自分がいたことに気づいたんです。

年齢が上がるにつれて「変化」することをためらうようになる、というのは感じていましたが、
自分自身が無意識のうちに、抵抗していたんだということに気づきました。

コーディングの知識だけじゃなくて、UIやIAの知識や、他のサイトのデザインを収集して、自分の仕事の幅を広げる。
今までマークアップしかしてこなかった自分には、かなり大きな変化です。
でも、むしろこれが出来るようになれば、コーダーとしての自分のワクが広がるのではないか。
そう考えたとき、自分がずっと感じていた、「コーダーってこの先あるんだろうか」という漠然とした不安が、すっと晴れた気がしたんです。

年齢を重ねるにつれて、「変化」するために必要なエネルギーは大きくなります。
でも、自分は恐れずに「変化」していきたいと、改めて思いました。