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

高校生のとき、自宅に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も何重に使いたくはなかった。
デザインなんかよりもマークアップを優先させたかった。
納期なんかよりも、自分が納得いくまでマークアップを模索したかったんだと。

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

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

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

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

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

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

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

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

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

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

パフォーマンスだいじだよ。サイト軽くしようよ。と言ってみても、「今は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プリプロセッサ（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＋Sublime＋LiveReload」ってついてまして（自分の中で）、
3本立てでお送りする予定です。

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

Sass＆Compass

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

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

• Windows PC に Ruby と Sass を導入する方法
• Windows7にRubyをインストールする
• Sassを覚えよう
• SassとCompassを使って楽しくCSSコーディング！

前準備

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

@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ファイルをまとめて結合してくれます！素敵！

1. 結合したいファイルの頭にはアンダースコア「_」をつけます。
   （CSSファイルとして出力されることはなくなります）
   basic.scss（出力ファイル）のほかに、_base.scss、_modules.scss を作ります。
2. basic.scssに下記の記述をします。（アンダースコアは除いてOKだそう。
   

   @import "base", "modules";

3. 書き出すと、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を再計算してくれます。
便利ですね！

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

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

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

案件が落ち着いてきたというのもあり、今までまわりになかった技術に手を出すようになり始めました。
今さらながら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デザイン（以下、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の知識や、他のサイトのデザインを収集して、自分の仕事の幅を広げる。
今までマークアップしかしてこなかった自分には、かなり大きな変化です。
でも、むしろこれが出来るようになれば、コーダーとしての自分のワクが広がるのではないか。
そう考えたとき、自分がずっと感じていた、「コーダーってこの先あるんだろうか」という漠然とした不安が、すっと晴れた気がしたんです。

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