Sass/SCSSフレームワークのCompassの1.0.0.rc.0(執筆しているときの最新版は1.0.0.rc.1)が、ようやくSource Mapを出力できるようになりました。Source Mapとは、コンパイル後のcssからデバッグコンソールでコンパイル前のソースが見えるあれです。
出力の仕方は、config.rbに
sass_options = { :sourcemap => true }
としておくだけ。
インストール方法は、
gem install compass --pre
とするか、bundleや、rails、middlemanなんかを使っている場合は、Gemfileに
gem 'compass', '~> 1.0.0.rc.0'
と書いてから、
bundle install
すれば良いです。
なんかCoffeescriptをGruntでコンパイルして、concatしたりとかだるいなーってずーっと思ってました。
Classとかを他のファイルから参照しようとするとwindow.classNameとか@classNameとかにしないといけないですし、ファイル名順に結合するので、アルファベット順で後ろにくるクラスを読もうとするとエラー吐いたり、いまいち依存関係が見えなかったり。
小規模な開発であれば問題ないのですが、Coffeescriptで大量にClassを作ったりすると、結構大きな問題になってきます。かといってrequire.jsとか面倒くさい。
というわけで、最近流行のbrowserifyを使ってみました。
npmとbrowserifyを使ったクライアントサイドのウェブアプリ開発
Browserify: それはrequire()を使うための魔法の杖
ざっくり言うと、ブラウザで、node.jsのようなrequireが使えるようになるツールです。
たとえば、以下のようなHoge.coffeeがあるとすると
class Hoge
piyo: ->
module.exports = Hoge
以下のコードで、読み込んでくることができるという代物です。
Hoge = require("./Hoge")
hoge = new Hoge()
debowerifyとかをtransformに指定しておくと、bowerでインストールしたモジュールなんかも取ってこれるので、大変素敵です。
$ = require("jquery")
それをgruntでファイル監視して自動化するようにしたのがこちらです。
module.exports = function(grunt) {
grunt.initConfig({
dir: {
coffee: 'coffee',
javascripts: 'javascripts'
},
esteWatch: {
options: {
dirs: [ 'coffee/**' ],
extensions: ['coffee'],
}
coffee: function(filepath) {
return ["browserify"];
}
},
browserify: {
dist: {
files: {
'javascripts/all.js': ['coffee/all.coffee']
},
options: {
transform: ['coffeeify', "debowerify"],
browserifyOptions: {
extensions: ['.coffee']
}
}
}
}
});
grunt.loadNpmTasks('grunt-browserify');
grunt.registerTask('default', ['esteWatch']);
};
transformにcoffeeifyを設定しておくと、CoffeeScriptでもコンパイルできるようになります。
browserifyOptionsのextensionsに.coffeeを指定しておくと、CoffeeScriptのファイルでも拡張子を省略してrequireできました。
名前空間も汚染しないし、依存するClass等は明示的になるし、読み込み順に左右されないJSを書くことができるようになります。その代わり、$ = require(“jquery”)等は各ファイルで行う必要があります。実行時には一度しか読み込まれないようなので、パフォーマンス的にもよろしいです。
GruntでBowerしたり、Coffeeしたり、ConcatしてJSを書いている人にはホントに便利です。
SUblime Text歴もそろそろ２年ほどになりますが、Pluginやらをがんがん突っ込んでるせいで、職場の環境と、家のマシンの環境がばらばらになってきます。これ何とかならないかなーと思ってググったら、ありました。Sublime Text 3でも2でもどっちでもできるみたいです。
いろいろ書いてありますが、要は、 ~/Library/Application Support/Sublime Text 3/Packages/ 等に入っているUserディレクトリをDoropboxで共有してあげればいいみたいです。Alfredや1Passwordなんかと同じ方式ですね。
Packageだけじゃなくて、Preferences.sublime-settingsやら、言語ごとの設定や、テーマも共有されたりします。
これで設定をGistに残したり、Package install しまくりともおさらば！
5/17の土曜日に、はじめてのハッカソン Vol.3に行ってきました。
みまさんにお誘いいただいていたのですが、前回・前々回は都合がつかずに不参加。で、今回は都合がついたので、参加しようと。
勉強とか後回しにしがちなので、こういうきっかけをいただけるのはありがたいことです。ほんとに。
デザイナーがいなかったので、ロゴはみまさんに助けていただきました。かわいい。
んでとりあえず、こんなものをつくりました。
レポジトリはこちら https://github.com/torounit/catsearch
HTML5 Geolocation api を使って現在地の緯度経度を取得し、その近くで撮影された（であろう）猫の写真をひたすら表示します。
あと、検索窓に適当なスポット名（「東京タワー」とか）入れるとそこの近くの猫の写真を表示します。
という非常に単純なサービスです。
API等で取得した緯度経度と、検索文字列「instagram.com%20猫%20OR%20ねこ」をTwitterの「search/tweets」に投げます。そして、帰ってきたTweetからURLを取り出しそれをinstagramのAPIに投げて、画像の情報を取得するという流れです。
instagramのEmbedding EndpointsというAPIにURLを投げ、帰ってきた情報から画像IDと取り出し、もう一度別のAPIに投げるという非効率な実装をしているので、めちゃめちゃ重いです。そんなわけで一度取った情報はサーバーにキャッシュするようにしています。
いまブログ書きながら、ドキュメント見てたらこの部分無くても良さそうな感じですね。。。。せつない。。。
検索機能の実装は、Google Map APIで、住所から緯度経度を取得し投げているだけです。Google Map APIすごい。
最初はinstagramの/media/searchを叩いて近所の写真をとってこれるし、余裕でしょ！とかテキトーなことを考えてたのですが、いざやってみると全然猫の写真ないし、paginationはこのAPIに無さそうだし、開始1時間くらいは「詰んだ？」とかずーっと思ってました。
そしてその後、TwitterAPIを使う方向に切り替えたんですけど、TwitterだとBotは多いし、名前も検索対象だったりするので、精度的にお話にならなかったんですが、”instagram.com”を含むツイートのみに絞ると案外、そこそこ目的のものに近い結果が取得できたので、何とかなりました。追い詰められると人間なかなかがんばれるもんですね。
そんなわけで、instagramの写真をTwitterで探すという、謎な実装になってます。
とりあえず、最初のアイデア出しのときに、ただひたすら猫への愛情だけを語り、実装をろくに考えずにやったのはまずったなぁと。そんな私におつきあいいただいたOgataさんには、大変な感謝です。はい。
また、仕様的にはめちゃめちゃシンプルでコードの量もかなり少ない方だと思いますが、それでも結構ぎりぎりまで作業する羽目になってました。2時間くらい時間余らせて、そこで機能追加したいなぁとか最初は思っていたんですけどね・・・・。
自分がアイデアを出してというのも初めてだったんですが、最初の段階で、ディレクトリ構造やら、ファイルの受け渡し方法だとか、ちゃんと決めておけばよかったなぁとも。2人のチームでもファイルのマージやらで苦労しました。3人とかだったら崩壊してるかもですね・・・。
日々の制作のやり方などを改めて考えさせられます。
とにかく技術面以外の部分で考えさせられることが多かった気がします。
まぁ反省材料も多かったのですが、それでも14時過ぎから19時半という短い時間の中、実際に動作するものが作れたのはよかったのかなと。懇親会のビールがとても美味しかったです。
なかなか普段得られない気づきがあって、ものすごい勉強になった1日でした。
スタッフの皆様ありがとうございました！
すっかりBEM道を邁進中の今日のこの頃ですが、ちょっとSCSSでやったときのはまりごと。
別に、https://gist.github.com/juno/6182957でも言及されているとおり、全てのセレクタをBEMにする必要はないのですが、BEMってないCSSを同時に使うには、ちょっと注意が必要です。
たとえば
.hoge {
p {
margin: 1em;
}
&__piyo {
margin: 0;
}
}
こんなやつ。
.hoge {
p {
margin: 1em;
}
.piyo {
margin: 0;
}
}
とCSSと書くのと、同じノリで書くと痛い目に見ます。
NO BEM であれば、.hoge p.piyoのmarginは0なのですが、
BEMった場合、.hoge pのほうが、BEMったセレクタの.hoge__piyoより優先度が高くなってしまいます。結果、先ほどのpのmarginは1emとなります。なので、BEMなCSSを書くのを結構強制されがちです。
CSSのオーバーライドがしづらくなるわけですね。
WordPressやら、CMSの本文部分のCSSを書くときにちょっと面倒なコトになりそうです。
その代わり、破綻しにくいCSSを作りやすいかもしれません。
SMACSSで言うところのbaseの設計が大変にはなったり、かといってbaseにごりごり書きすぎると、モジュール周りでmarginやらpaddingのリセットをいっぱい書く羽目になったり。
難しいですね。CSS。
bowerを使ってjsをパッケージ管理したかったんです。
でも普通に使うと、bower_componentsから、ファイルを動かしたり、scriptタグをたくさん書いたり、いろいろめんどくさいです。
そんなときに、grunt-bower-concatがものすごく便利です。
このタスクを回すと、bower_componentsの中のjsを取り出し、結合して一つのjsにまとめてくれます。
また、その際、依存関係を解決しながら読み込み順などを設定して結合します。
jsをインストールする際、
bower install hoge grunt bower_concat
とするだけで、JavaScriptのインストールが完了します。scriptタグを書いたりしなくても大丈夫。非常にbowerが手軽に扱えます。PHPのComposerくらいお手軽につかえます。
npm install grunt-bower-concat --save-dev
にて、モジュールをインストール後、Gruntfileに
bower_concat:
all:
dest: 'assets/js/lib.js'
exclude: [
'jquery',
'modernizr'
]
bowerOptions:
relative: false
と、設定を書きます。destは、吐き出しファイル名、excludeには、除外するライブラリを記述します。bowerOptionsは正直よくわかりません。そのほかのオプションは、Githubを参照してください。
Gruntfileはこんな感じになります。
https://gist.github.com/torounit/10652847
最新版がbowerで配布されるようなモジュールなどを扱うときは死ぬほど便利です。作成されたjsをgrunt-contrib-uglifyなどで、圧縮したりするのも楽勝です。
ただ、CSSには対応していません。
また、bower.jsonのmainが記述されていないものもだめだったりします。まぁ、主要なライブラリは結構ちゃんと動くので。。。。。
Custom Post Type Permalinks 0.9.5.4をリリースしました。
3.9でのテストと、バグフィックスがメインになっています。
WordPress › Custom Post Type Permalinks « WordPress Plugins
Github: torounit/custom-post-type-permalinks
バグレポート、Pull Request、お酒、コーヒーメーカー、フードプロセッサー、ミキサーなどなど、お待ちしてます。
先日、LessでBEMってみたらかなりさくさくコーディングできた！という話という記事で、Sassを全力でDisったような気がしますが、
いい加減にsass3.3を導入しようとついに一念発起して、sass3.3.0.rc.3を突っ込んでみました。
Compassも1.0.0の開発版にアップデートし、いざ、SassでBEMるぞ！！！と、かの有名なBEM用Mix-in
@mixin e($name) {
@at-root #{&}__#{$name} {
@content;
}
}
@mixin m($name) {
@at-root #{&}--#{$name} {
@content;
}
}
を突っ込んでみたんですが、このMix-inでコンパイルエラー。これはrc.2にしてみたらうまくいったのですが、Compassのバージョンを落としたりが面倒くさくて挫折。rc.3のバグなのかな？と思っていました。
そして、本日、rc.4が出ていたので、改めて再トライ。しかし同じエラーが出現。これはいくら何でも。。。と思い、Sassどうした！って思っていたのですが、試しに、
@mixin e($name) {
@at-root &__#{$name} {
@content;
}
}
@mixin m($name) {
@at-root &--#{$name} {
@content;
}
}
としてみたら、コンパイルが通ってしまいました。
ちゃんとMix-inも無事動きます！
rc.3でも動きました。Oh…
もちろん、これも動きます！しかも、@at-root書かなくても大丈夫。Lessとかと全く同じ挙動です。
BEM用Mix-inなんていらんかったんや・・・・・
.foo {
&__bar {
}
}
SassのRC版は、
gem install sass --pre
Compassは、
gem install compass --pre
でインストールできます。
やっぱりSassは最強でした。
Custom Post Type Permalinks 0.9.5をリリースしました。
WordPress › Custom Post Type Permalinks « WordPress Plugins
機能面での修正は、PHP5.4対応とか、WordPress3.8でテストしたとかその程度です。
コードを全面的に見直して、がっつりリファクタリングを行っております。去年の夏から取り組んではいたのですがだいぶかかってしまいました。
今まで一つのファイル・クラスで行っていたものを複数の小さなモジュールに分離しています。
ここのモジュールは基本的に独立しているのでアドオン形式の機能追加なども可能です。
あとソースコードも読みやすくなったはずです。（たぶん。）そんなわけでじゃんじゃんプルリクエストをいただければありがたいです。
レポジトリはこちら。
torounit/custom-post-type-permalinks
パッチ・プルリクエスト・issue・フィードバック等よろしくお願いします。m(_ _)m
新年明けましておめでとうございます。
今年もWordPressでCSSな1年にしたいと思います。よろしくお願いします。
年末年始は実家に帰省してぐだぐだしていたのですが、その中でいろいろ気づかされたことをつらつらと。
ぼくの父親について。
日常生活レベルでは、それなりに見えているようです。
インターネットもばりばりやっていますし、iTunesもばりばりに使っているようでした。パソコン組んだり、カードを挿したりなどはできる様子。
現在Windows7を使っているのですが、フォントサイズは125%、テーマを「ハイコントラスト #1」のフォント周りをカスタマイズしたものにして使っていました。
こんな感じの画面でパソコンを使っています。
このOSのテーマ設定、Chrome・Safari等には適用されず、IEは適用されました。さっき検証したところ、firefoxにも適用されるようです。
こんな感じにgoogleは見えます。
IEでの検証です。
それなりに見やすいですね。ただ検索ボタンがいなくなりました。左上のロゴはfirefoxでは見えました。
購入するボタンが見えない。ロゴも見えない。
意外にこれは見やすかった。
ブログはテキストベースなので割と読みやすいかも。
文字色は反転しますが、画像は反転しないですね。なので、画像の周りが白くなったり、見えなくなったりいろいろと不具合が出てきます。
背景が黒くなったとき、テキストを画像化したものは当然見えなくなってしまうことが多いです。テキストベースであれば、ある程度アクセシビリティを担保しやすいと思います。
また、色などはかなり無視されますし、背景画像は表示されません。なのでCSS Spriteやっていたところは表示されません。ただし、imgタグであれば表示されます。
CSSでのマウスオーバーなどは考え直さないといけないことが多そうです。
Googleの検索結果に枠がついたところは、border:1px solid transparent;が設定されていました。
アクセシビリティという話題の時に必ず音声ブラウザという単語が出ますが、それだけじゃないなというのは当然知識としては知っているし考えるけれど、実感として得るものがありました。
“Webアクセシビリティ”とは、”Webを利用するすべての人が、年齢や身体的制約、利用環境等に関係なく、Webで提供されている情報に問題なくアクセスし、コンテンツや機能を利用できること”ということができます。そして、そのようなWebコンテンツを”アクセシブルなWeb”といったりします。
引用元：Webアクセシビリティとは？／基礎知識 － Webアクセシビリティポータルサイト『infoaxia(インフォアクシア)』
みんなにとって使いやすくって大事なことです。
画像のaltを入れるだとか、小手先では到底ケアできる問題ではない、本質的なアプローチが必要だと思います。
62歳の父親がAmazonで買い物したりiTunesストアで音楽を買う時代です。
すべての人に同じ見た目を、同じ体験ってのはそもそも不可能だという前提を改めてかみしめた上で最適なデザイン、ユーザーインターフェイスを考えなくてはいけないですね。
こう言うのって重箱の隅をつつくようだし、きりがないことだとは思います。
でも、周りを見渡せば、裸眼って実は珍しい。僕も小学生からメガネな人間です。もしかしたら僕もそう遠くない将来、「目は一応見えるけれど・・・・」という異なる可能性は十分にあると思っています。
そうなったときに、ネットで音楽やら本やら買えないのは嫌だし、歳をとっても目がもっと悪くなっても、WEB見ていたいです。
だからこそ、人ごとにせず、制作者自身が向き合っていかなければいけない問題だと思います。
まだまだ研究の余地が山ほどありそうで、WEBって楽しいですね。
追記：続編書きました。
BEMを使ったCSSのクラス設計(MindBEMding)ですが、これをSassでやろうとすると、結構泣けてきます。
たとえばこんな感じになるんでしょうかね。
$block: ".block";
#{$block} {
display: block;
}
#{$block}__element {
border: 1px solid #CCC;
}
#{$block}__element_modifier {
border-color: #FFF;
}
また、Sass 3.3以降だと、
.block {
display: block;
@at-root {
#{&}__element {
border: 1px solid #CCC;
@at-root {
#{&}--modifier {
border-color: #FFF;
}
}
}
}
//もしくはこんな感じ
@at-root {
#{&}__element {
border: 1px solid #CCC;
}
#{&}__element--modifier {
border-color: #FFF;
}
}
}
こんな感じで、BEMれるようです。
参考: BEMという命名規則とSass 3.3の新しい記法 – アインシュタインの電話番号
ただ、@at-rootなどを乱発したり、いちいちshiftをおしながら#{&}って入力していくのは、ちょっと大変すぎるなと個人的には感じます。というかめんどくさい。せっかくネストして楽にかけるはずのCSSが、より大変になっている気がしてしまいまして。
Lessだと、こんな感じに書けて、
.block {
display: block;
&__element {
border: 1px solid #CCC;
&--modifier {
border-color: #FFF;
}
}
}
このソースを、lessをcssに変換(less2css) | Magonote-toolsにコピペするなり、普通にlessで走らせるなりすると、
.block {
display: block;
}
.block__element {
border: 1px solid #CCC;
}
.block__element--modifier {
border-color: #FFF;
}
こうなります。こんな感じでLessはネストしつつ、しっかりBEMなCSSが出力されます。非常に直感的です！
SassとLessの大きな違いとなっていたextendがLess1.4から実装されましたが、&を含むセレクタのextendはできないようです。また、実際に出力されるセレクタを指定してもextendはできないようです。
なので、.block__element–modifierに.block__elementのスタイルを継承するようなことはできず、html側で両方のclassを指定する必要があります。
BEMという命名規則とSass 3.3の新しい記法 – アインシュタインの電話番号でも言及されていた、HTMLが冗長になってしまうと言う問題に対処することは難しいです。
Windowsでも導入が簡単・JavaScriptとの相性が良いなどのSassには無いメリットもあるし、Compassでよく使うMixin等の移植もそこまで難しくないです。CssSpriteもCompass以外のツールで対応できますしね。
Sassに比べるとCompassのようなフレームワークが無かったり、extendもSassのほうが若干協力だとかで
なかなかLessを使おうという場面は少ないとは思いますが、それでもBEMとの相性がよいというのはなかなか見逃せない部分じゃないかなと思います。
LessのextendもSassには無い書き方があったりしておもしろいですし、用途によって使い分けるとなかなか楽しいんじゃないですかね。
iPhone + SafariでCSSのデバッグなんかをよくやったりしますが、Androidにもあるよなぁー。いちいちエミュレータとかいろいろ立ち上げてやるが嫌だなぁー。とか思っていたら、
SDK不要Android端末のリモートデバッグChrome拡張機能「ADB」
こんなものがあるようです。
こんな感じで、PCのChromeからデベロッパーツールを開いたり、AndroidのChromeを操作することもできます。
詳細な紹介は元記事を参照してください。
をChromeにインストールするとPC側の準備完了。
これで使える！と思いきや、端末側も設定がいるようです。
まず、設定 -> 端末情報 -> ビルド番号を7回タップ。
すると、「デベロッパーになりました」というメッセージが表示されますので、設定のトップページに戻ると、
「開発者向けオプション」という項目が追加されています。その中の「USBデバッグ」を有効にします。
これで、AndroidをUSBでPCにつないでADBを起動すると、ブラウザからCSSいじったり、JSいじったりできちゃいます！！
Androidのケーブルの抜き差しが多発するので、ケーブルがだめになったりコネクタを傷めたりしないよう、優しく取り扱ってあげましょう。