npmコマンドでよく書くパターンにGitで固定のファイルをステージしてコミットするというようなものがある。なんらかの処理を行うメインコマンドのpostコマンドでよくやる。まれにその固定のファイルが更新されないこともあり、その時コミットしてしまうとcommitサブコマンドが正常に(終了コード0で)終了しない。これを避けるためにはステージされることで更新があったかどうかをチェックする必要があることになる。それはdiffサブコマンドの--exit-codeオプションを使うとうまく書くことができる。 例えば更新されているかもしれないfooというファイルをステージして、更新があった場合にのみコミットしたい、とすると以下のようにコマンドをつなげれば良い。 $ git add foo && git diff --cached --exit-code --quiet || git commit --mes

TwitterやInstagram、Pinboardのアカウントを消したので、それらでやっていたことを自前でやりはじめている。それぞれの過去の投稿をインポートし、RSSもそれぞれ作った。あとは/feedを全部入りにするつもりだが、ちょうど1年くらい前に購読先を変えさせたので、ちょっとやりづらい。でももう少ししたら変える。こうして個人ウェブサイトへと回帰した。 ポートフォリオではない個人ウェブサイトが、どういうものだったか、はっきりと思い出せない。カウンターとかリンク集があったとか、フレームで作られていたとか、ウェブリングとか、些末なことは思い出せる。しかし、どういう雰囲気だったのかまったく思い出せない。 外に放つというより、内に向かうものだったような気はする。そういう感じが出していけるとうれしい。 コンテンツが大きく追加された関係上、ホーム・ページや完全なログのページなどをいじっている。ま

WWD Japanのウェブサイトがリニューアルして、スッキリした見やすそうな印象のものに変わった。しかし実際のところ見やすさは見せかけだけで、ナビゲーションをクリックしても見当違いのタブに切り替わったり、ニュース一覧からニュースをクリックしたら、要約ページへ移動するだけで、本文へはもう一度クリックしなければならなかったりする。中でもひどいのがMobile Safariでの閲覧だ。 このウェブサイトではスクロールをほぼ自前で制御しようとしているため、常にこのようにMobile SafariのURLバーとツールバーが上下にそれぞれ表示され続ける。その上、最上端にロゴとグローバル・ナビゲーション、最下端に広告がそれぞれ固定位置であるので、コンテンツの領域がかなり制限されている。iPhone 5SやSEどころか6+や7+でさえも致命的なのではないかと感じられる狭さだ。 とにかく文書を読ませようとい

近所にできたLOFTでBackJoyという骨盤をサポートして腰への負担を軽減する座布団を試してみた。ちょっと違和感はあったものの使用感はいきなり良かった。ただ即購入には至らず、レンタルがあるようなので試していた。ともかくハイエンドにしようとリリーフ・グリップというモデルにした。540円で2週間レンタルできる。 使用感 いきなり座ってみても確かに姿勢が良くなる。深く座って太ももを下げるとグッとお尻の方が持ち上がり、前傾になってていても猫背度が大きく減る。劇的にグイグイサポートされるというわけではなく、骨の位置を調節してくれるという形で、負担は太ももの圧迫感くらいだろう。椅子との相性はある程度あるが、座面の硬さはあまり選ばないので、椅子の高さを調節できれば大きな問題ではなさそうだ。 最初は30分くらいで変な感じになったが、少し慣れてくると1時間くらいは座っていられた。ただ落ち着かないので車の運

Responsive Tables in Pure CSSという記事を読んだ。狭い画面での表のレンダリングに問題があって、それを解決したいということは勿論わかるのだけど、これはないなという感想しか残らない。表は行と列の交点でデータを把握でき、その上下左右と簡単に比較できるというためのものであって、そういった機能を破壊してビューポートに収めようというのはもはやレスポンシブではない。 レスポンシブ・ウェブ・デザインが広まってから何度もこの類いのものを見せられてきた。もしこのように各行を展開して表示したいようなコンテンツであるのなら、dl要素を使うべきで、それを広い画面ではコンパクトに表のようにデザインするべきだろう。逆に表である必要があるのなら、変にセルが縮まったりしないように調節し、横にスクロールして閲覧できるようにするべきだ。 ただ確かにモバイル機器のブラウザーでの表の閲覧には難がある。せ

agで特定の拡張子のファイルだけに対して再帰的に検索したいなと思っていたけどやり方がわからなかった。*.txtは可能だけど再帰的に検索してくれないし、**/*.txtは受け付けてくれないし……。Twitterでボヤいたら「ag -Gとかあるんだ」とかエアーを見たので調べてみたらまさにこれだった。 -Gオプションでは正規表現を使ってファイル名を指定する。 $ ag foo -G \.txt$ これで.txtで終わるファイルからのみ再帰的に検索できる。よく使うファイル名のパターンを指定済みのエイリアスをいくつか作っておくと良さそう。

MovableTypeとWordPressとJekyllとHugoや、Gruntとgulp、SassとLESSとStylus、果てはjQueryなどの話はスケールやパターンを変えて繰り返される。その話はあたかも特定の何かに依存することが良くないとか新しいこっちのがすごいぞというように結論づけられることが多くて、僕にはちょっと頷けないこともあったりする。大切なのは何を解決しようとしていたかを忘れないことだと思う。複雑化しそうな場合にそこから先へ踏み込まずに我慢する期間がいるとかかも。 GNU makeでいいじゃん的な結論はそれは確かにビルドという点ではそうなんだけど、Gruntが解決しようとしていたのはそこじゃない。npmという生態系の中で完結させやすいタスク実行環境を手軽に用意することができることで、それ以上でもそれ以下でもない。実行速度以外にも腐臭を放つAPIやプラグイン間で一貫性のない

Webフォントを非同期に読むテクニックはいくつかあるけど、その理由についてまとめられた文章は少ない。僕は非同期に読み込むのは3つのそれぞれ違う分野での問題を解決するためだと考えている。どの問題も致命的なものではないので、非同期に読み込むべきかどうかはそれらをどう捉えるかで変わってくる。 Webフォントのファイルサイズ 最もわかりやすいのはファイルサイズ、つまり転送量の問題。日本語フォントを例に上げるまでもなく、そこそこの範囲のユニコード記号や絵文字をサポートするだけでもかなりのサイズになる。カーニングやリガチャなどを加えれば更に大きくなるだろう。非同期に読み込むことにより、ダウンロードが終了するまでページの読み込みが終わらないなどということは避けられる。 しかし、これは日本語フォントでもたかだか3から5MBほどなので、それほど気にすることではない。モバイルのことを考慮してようやく「できれば

Webフォントの読み込みは@importだと色々まずいので、主にlink要素を使って並列に読み込むわけだけど、これもまた貴重なHTTPリクエスト数を消費するとか、CSSのパース完了が少し遅れるなどあって、完璧な解というわけじゃない。それを非同期にWebフォント定義の含まれるCSSファイルを読み込むようにして、Webフォントのロードをページのレンダリングと並行して行わせるのはどうか、という試み。 非同期化することによりWebフォント定義の含まれるCSSファイルのリクエストとパースが、ページのレンダリングと並行して行われるようになる。head要素内でlink要素を直接書いた場合は、Webフォント定義の含まれるCSSのリクエストとパース後にページのレンダリングが始まることが多いので、体感速度(ページのレンダリングの開始までの所要時間)は向上する可能性が高い。 動的なlink要素の追加 いわゆるソ

SassでBEMを利用して変数名を付けようとして、今までハイフンのみでどうにかしていた変数名を書き換えていた時に気づいたんだけど、Sassの変数名ではハイフン(-)とアンダースコア(_)が同一視される。バグだと思ってIssue立てたら、3.0.0でSCSS記法を追加した時に入れた仕様だという返事だった。 -と_が同一視されるということはどういうことかというと、以下の変数はすべて同じとみなされるということで、すべての変数の値は最後に定義した変数の値になる。 $foo--bar: "foo--bar"; $foo-_bar: "foo-_bar"; $foo_-bar: "foo_-bar"; $foo__bar: "foo__bar"; .test-foo--bar { content: $foo--bar; } .test-foo-_bar { content: $foo-_bar; }

HTML Standardsの中でも屈指のややこしさな気がする4.8.1.1 Requirements for providing text to act as an alternative for imagesを全容を把握しやすいように箇条書きにして日本語に訳した文書、HTMLにおけるimg要素のalt属性を作成した。 ややこしいというよりも説明それ自体はかなり親切なんだけど、その親切さのお陰で情報量がものすごく多いため読んでるうちにポロポロと読んだことを忘れていく気がする。なので、サンプルコードや仕様書特有の正確だけど持って回りすぎた難しい言い回し等を省いたこの箇条書きならなんとなく覚えられると思う。その上で原文の実践的なサンプルコードを読めば理解がかなり進むんじゃないかと。 HTML Standardsにはこういうアンチョコ・セクションはいくつかあって、他だと4.4 Sections

git log --graph --onelineをメインに使っていたんだけど、現在時刻に対する相対的な時刻とかコミッターの名前とか表示したくなったので色々いじってた。%C(white bold blue)とかでターミナルの色を参照して文字色と背景色を指定することができるということを理解するまでが長かった……。 上記スクリーンショットのようなgit logは以下のようなコマンドで実現できる。 $ git log --graph --pretty='format:%C(yellow)%h%Cblue%d%Creset %s %C(black bold)%an, %ar%Creset' %dで参照名(ブランチやタグ、リモートブランチ)を、%anでコミッターの名前を、%arでコミットの相対的な日付を表示するようにして、%Cで色を変えている。%Credと%Cblue、%Cgreen以外を使う場合は

HTML5時代に向いていそうな(S)CSSの書き方を模索しています。SCSSで書くのでモジュール式に色々分割した方が良さそうだな……とか色々試してますが、なかなかこれ！　というものに辿りつけません……。ということで、ここ最近の書き方をメモがてら晒してみる試みです。 実際にこのサイトで使っているSCSSファイルを抜粋しつつ列記していきます。 style.scss style.cssになるSCSSファイルではCSSは書かないようにします。ただし例外としてCSS文法での@importルールはその必要性からここに書きます。Webフォントなんかで使いますね。それ以外はSCSSの@importでモジュール化した各種SCSSファイルを読み込んでいきます。 @import url("http://fonts.googleapis.com/css?family=Pacifico"); @import "va

諸方面からお叱りの言葉しかいただけない#!なURLは様々な問題をはらんでいますが、来るべき未来(もうすぐですよ！)におけるメンテナンス性という問題についてAdactioで取り上げられていました。#!の表面的な凶悪さに思考停止していて、こういった本質的な問題についてはまったく考えていなかった気がします。 その問題というのは、#!なURLからHistory APIなどを利用してクリーンなURLに乗り換えよう(戻そう)としても、古い#!なURLを有効なままにするためにはサーバー側の何か(単純なリダイレクトやmod_rewriteなど)ではどうしようもないので、クライアント側での(JavaScriptを利用した)リダイレクトを提供する機能を提供し続けなければならないというメンテナンス性の悪さです。 この#!なURLのメンテナンス性の悪さという問題は、URLの#以降はクライアント側の扱いなので、クラ

ミニブログの隆盛以降ウェブ上でよく見かける吹き出しをCSSで作るお話。単色のものはかなり前に書いた。今回はそれに枠線をつけてみよう！　みよう！　みよう！ Demo: Bordered Speech Bubble 枠線は単なるsolidなborderで少し角を丸めただけ。 尻尾を付ける :before擬似要素を使う。デモの3番目のサンプルのように、まず枠線と同じ色で三角形を作る。三角形は以前のエントリで書いた手法と同じで、左右のborderをtransparentにすることによって作る。 .speech-bubble:before { border-top-width: 16px; border-right-width: 16px; border-bottom-width: 0; border-left-width: 16px; border-color: #369 transparent;

多くの人がDive Into HTML5のコンテンツの中で最も気になるであろう(X)HTML( 4)からHTML5への移行を題材として、HTML5の書き方や新しい要素などの説明したWhat Does It All Mean?の日本語訳、「結局どうすればいいの？」を公開した。前に二度全部訳そうと思って、言い回しの複雑さにさじを投げたが、今回はとりあえず自分が一番最初に熟読したWhat Does It All Mean?に絞って訳した。 この章は既存のウェブページのHTML5への移行を題材としているだけで、移行法についての解説とは少し違う。そう読んでもそんなに期待外れではないが、脱線が特に序盤に多いので、細かいことに興味はないならHeadersあたりから読んでも良いかも。もちろんこの文書はHTML5の完全な解説ではないので、例えばaside要素やsection要素の詳しい説明などは欠けているし