カフェイン復帰
朝にコーヒーか緑茶を飲むように戻った。それ以降は飲まない。カフェインを取りたいというより、コーヒーや緑茶の香りを嗅ぎたい。特に冬は体の起動が遅いので、香りを含め五感を刺激することは大切に思うように心変わりした。 コーヒーは相変わらずモカエキスプレスで淹れている。安定の味で気持ちが良い。メリタのドリッパーでドリップで淹れたりもしていたが、ドリップケトルが欲しいなとか、ケメックスが欲しいなとか考えてしまう。お金を使う誘惑を振り切るため、原点に戻った。 お金と言いつつ、温度調節可能な電気ケトルは欲しくなってしまった。2年くらい前から増え始めたが、ドリップ専用の細い注ぎ口のものが多く、敬遠していた。最近は普通の注ぎ口のものも増え、タイガーのもののように下の台が大きくないものあり、気になっている。
Dropboxの(S)CSSスタイル・ガイドの所感 - Weblog - Hail2u.net
Dropbox社内のスタイル・ガイドを読んでいた。スタイル・ガイドとなっているがCSSのコーディング規約の方のスタイル・ガイドだ。最近のシンプル回帰の傾向と違い、かなり厳しいようだ。完全に守ってるとしたらかなりすごい。 特に特徴的だったのはCSSプロパティーの記述順だろう。近頃は「もう面倒なのでアルファベット順で……」という規約が多い。対してDropboxのそれはいくつかに大きくジャンル分けして記述するようになっているようだ。そのジャンルの中では順不同なのも面白い。そのカテゴリ分けもレイアウト、インラインの見た目、ブロックの見た目、その他と妥当に分かれている。 コンポーネント分けのパターンも考慮すると、多くはその分けられたカテゴリのどれかひとつだけを使うようにクラス分けされるはずなので、実質意味がないようにも見えるところに興味を持った。複数のカテゴリのプロパティーが混ざったらそのクラスはお
Hail2u
Hail2uは、幅広い話題の記事や、おすすめのウェブページ、読んだ本などを公開している、ながしまきょう(hail2u)の個人ウェブサイトです。CSSや、HTML、ウェブ標準についての話題が多く、JavaScriptやサーバーサイドの話がそれに続きます。近年は特に話題を限定せずにいろいろ書いています。 最近の雑多な記録 3か月ごとの定期リリースでvim-css3-syntaxのv2.4.0を出した。 松岡美術館にモディリアーニなどの所蔵品が出てくる展覧会を見に行く。 マイナー番号が上がり、いろいろ変わったが、雰囲気は変わっていない。 GitHubにはブランチActivityという機能があり、そこでは強制プッシュなどで見えなくなったコミットのハッシュも見つかるようだ。 2023年の12月に行った展覧会の後期を見に、再びWHAT MUSEUMへ行く。 よくよく考えたつもりでESRのMagSafe
2000本記事
これで通算2000本目の記事。ブログにおける2000本記事は、プロ野球の2000本安打に匹敵するのではないか。そう考えると、「数シーズン棒に振ったのにも関わらず、2000本安打達成しててすごい！」みたいな感じに。ならない。 継続は力なり的な事言う人いるけど、ウェブサイトには当てはまらない。特にブログでは記事単位での評価に終始されるので、継続することにはあまり意味はない。たったひとつのまずい記事で、積み重ねてきたものはあっけなく崩れ、そのことすらもすぐに忘れられる。ウェブサイトが継続してきたことそれ自体は、インターネットに何も影響を与えない。 そう思いながら2000本書いてきたけど、本当に何も起きてない。この2000本はいったいなんだったのか。これからもぬっとりと適当な感じでだらだらやっていき、死ぬまで実験しようと思う。
Gruntべったり
Gruntをよく使うようになったけど、プロジェクトの中心にどっかと存在していると不自由なことが多い気がするなーと感じている。Gruntべったり、つまりプロジェクトをGruntに強く依存させるとポータブルである保証のあるタスクだけを使う(書く)ことを強いられる。Gruntはその雑な自由度が良い所で、そこに何かしらの制限が加わってしまうのはその良さを低減させてしまうと思う。 Node.js自体にクロスプラットフォームだけどさほど書かれるスクリプトのポータビリティを意識した作りになってないような印象を持っている。そのためその上で動くGruntでポータビリティとかなんの冗談だとか思ってしまう。 Gruntの開発チームが公式にメンテナンスしているgrunt-contrib-*は確かに安定して優秀で、大体のことはポータブルなそれらで事足りたりする。だけど簡単なタスクを書いて使いたい時はもちろんあるし、
ID使っても別に問題ない
CSSでID使うの良くない……どころか、ID使うのはゴミクズカスみたいな風潮で辛い。その根拠はいくつかあり、それらはCSSだけをただそのまま書く場合には納得出来ないこともないかなーと思うので余計に辛い。特にOOCSSのようなアプローチではIDは混ぜるな危険。だからといってIDを使わないのがベスト・プラクティスなわけじゃない。 CSS Lintの利用が広まり、これがID使うなって怒るのも原因の一端な気がする。Disallow IDs in selectorsではIDの問題点として以下のようなものを取り上げている。 However, IDs have a downside: they are completely unique and therefore cannot be reused. つまりユニークなため再利用できないというマイナスの面がある、と。確かに再利用できない。でもこれはマイナス
プロジェクト: ロレム・イプサム
@ub_pnrが日本語英語数字がちょうどよく混ざったライセンスフリーの文書を探している。とつぶやいてた。僕もダミー文章にはWikipediaから英数字が混じっていることが多いIT系の記事とかを拾ってきてたけど、CC BY-SAとかなのでリンク張ったりとかちょっと公の場で使うには面倒臭い感じで、パブリック・ドメインのそういう文書群は欲しいと思ってた。ということでそういうダミー文章のためのロレム・イプサム(roremu ipusamu)というCC0なプロジェクトを作った。 主な用途としては、CSSのプレビューやアプリケーションのモックアップに使うダミー文章を想定している。スタイル・ガイドを書く時の仮テキストに使ったり、ブログのテーマのプレビューを作成するために使ったり、アプリ・ストアに載せるスクリーンショットを取る時に使ったりなどなど。CC0なのでどのように使っても良いし、改変しても良い。 こ
Digg ReaderとAOL Readerにはがっかりだ
Google Readerという巨人亡き後の権力の座が欲しいだけ……というとあまりにも攻撃的だけど、少なくとも両者共に未来を見ていないようなものだった。これからのRSSリーダーに必要な物は何なのかみたいなものを考えた形跡がまったく感じられない。Google Readerが描けなかった世界を見せてくれるというような期待を、特にDigg Readerの方に持っていたのでとてもがっかりした。 Feedlyと違ってスクラッチから作るわけだし、機能が足りないのは仕方ない。でもGoogle Readerに無い何かがあって初めて継続して提供されうるようなサービスになるはずで、単なるリプレースでは同じように終了するだけじゃないのか。このままじゃ変なクローラーが増えただけで何にもならない。もちろんこの時点で何か革命的な機能があるべきだみたいなことは考えていないけど、両者を使ってRSSを読み進めても何かワクワ
Drawic
フッターのアイコンをSVGにした。GitHubにリポジトリも作っておいた。ぴくせる・ぱーふぇくとってなんでしたっけ……。 暗い背景向けの白いアイコンのみだけど、まぁそこは普通のSVGなのでエディターで開いてfillプロパティーの値を変えれば好きな色に変更できる。二種類ある矢印系には全方位を用意しなかったけど、transform属性でrotate()関数を利用して方向を調節できるのでそれで(若干中心をずらしてあるのでtranslate()も併用した方が良い)。 shape-rendering: crispEdges with crispEdges (Left) vs. w/o crispEdges (Right) Deliciousのアイコンはrect要素を組み合わせたものなので、そのままでは拡大・縮小すると端がぼやけることがある。そういう時はみんなが独自実装したCSSのimage-rend
GitHubで今開いているコミットをmasterの最新と比較する
GitHubには任意の二点間のスナップショット差分を見るためのCompareというビューがある。各リポジトリのページからこの機能にアクセスするUIがないのでマイナーな気がするけど、アクティビティーとかでちょっと使われてたりするので見たことはあるはず。CompareビューにはリポジトリのURLの最後に/compareと付けるだけで入ることができ、開かれるダイアログで任意のタグやブランチ、SHA1ハッシュを入力すると差分がズラッと並んでくれる。特定のコミットのページからは特にUIはないのだけどURLをちょっと書き換えるだけでmasterの最新との差分を見ることができる。 具体的には https://github.com/hail2u/normalize.scss/commit/58d8597e5b6df43e9ad6023ac68f10e7ec47e139 というような特定のコミットを参照して
なぜnormalize.cssなのか
リセットでは弊害がありすぎるとか、ノーマライズの控えめなところが良いとか、まぁいろいろだとは思う。僕はそもそもリセットとかノーマライズとか自分で書いていないルールを取り込むのが好きではないので、なるべくその類のものの使用は最小限に抑えたい。YUI CSS Resetなどでは好むと好まざるに関わらず全て取り込まないとならないけど、normalize.cssではブラウザ間での差異を統一するための各コードが独立しているので、必要なものだけを取り込むなどというような使い方も難しくない。そういった自分の書くCSSとブラウザー側の実装の緩衝材(polyfill)として機能するというところがnormalize.cssを気に入った理由で、これからも使っていきたい理由。 各ルールを個別にインポートできるようにした形でnormalize.scssを作ったのはつまりそういうことで、Sassで手軽に使えるように…
Flexbox、おもしろいですよ？
Translation of: Learn You a Flexbox for Great Good! | The Haystack. written by Stephen Hay Flexboxについて知っていますか？ 多分、名前は聞いたことがあるでしょう。もしかしたらチュートリアルくらいは読んだことがあるかもしれません。既に試していたりしますか？ Flexboxという代物についてあまり聞いたことがなかったり、前に試してから随分と経つなら、そのFlexboxに関する知識のことは一旦全て忘れてしまいましょう！ 現時点での最新版である2011年11月29日にリリースされた仕様では完全に別物になっています。 訳注 2012年3月22日に新しく公開されたWorking Draftでもまた大きな変更が加わり、この文書の一部はそのWDにそぐわないものになっています。大筋は変わりませんし、2012年3
Bashmarks
ちょっと前からBashにブックマーク機能を持たせるシェルスクリプト、Bashmarksを使ってます。bookmarkでカレント・ディレクトリをブックマークして、いつでもgoで移動できるようになるというただそれだけのものですけど、結構便利に使ってます。補完もあるのでブックマーク名忘れても安心です！ インストールは適当な場所に保存して、~/.bashrcでsourceするだけです。 source ~/bin/bashmarks.sh ブックマークするのはbookmarkコマンドです。 $ bookmark foo これでカレント・ディレクトリがfooという名前でブックマークされます。入力のしやすさを考慮して小文字でブックマークすると良さそうです。 $ go foo とするといつでも移動できるようになります。 $ bookmarksshow でブックマークの一覧が参照できますが、goコマンドには
フロートした要素に続くリスト
通常フロートした要素とデフォルトの文書フローで配置された要素は重なります。CSS 2.1仕様書のフロートの解説にある図Dがその例です。なので、通常フロートした要素に続くリストはそのブレット(や数字等)がフロートした要素の下に隠れてしまいます。この挙動には結構困らされることが多いですが、実はoverflow: autoとすると簡単に回避できます。 Demo: ul after floated element デモのようにリストにoverflow: autoするだけで、キレイにリストが配置されるようになります。overflow: autoを使った場合と使わなかった場合でどう重なりに違いが出るかわかるように、outlineプロパティーでピンクの線を引いておきました。 これはブラウザの挙動がたまたまそうなったということではなく、実にさり気なくCSS 2.1仕様書にも記述があります。 The bor
ディテール
Webページにおける細かいパーツを正しく実装することがユーザー経験の向上につながるということについて書かれたUI: Getting the Details Rightを読んだ。WordPressの結構な人気テーマでもタブがあたかもパンくずリストのように表示されていたりするし、頭ではわかってても実践にまでは至らないことも多そう。 Getting the Details Rightではいくつかの有名なパターンを例に、こう実装するとユーザーが混乱しにくいという説明をしている。例えばスライドショーでは切り替えの矢印以外にも「いくつくらい画像が用意されていて、今何番目を表示しているのか」を示すドットを使ったインジケーターが重要であるとしている。また、画像や画面の切り替えにも簡単なアニメーションを導入することによって、ユーザーに「どう切り替わったのかをアニメーションで示すことによって戻る方法を示唆でき
mit-license.org
Open Source InitiativeのMITライセンスのページのURLを使ってMITライセンスと明示している人は結構多いと思います。ライセンス全文コピペするの面倒ですしね……。ただその場合は権利者の名前等を予め書き、ライセンス条項については以下のURLを参照……などと注意書きも含めた方が無難です。そういうのを「忘れるし！ 面倒だし！」と思ったRemy Sharpがmit-license.orgというウェブサービスを作ってくれました。 登録するとユーザー名をサブドメインとしたURLが確保されます。例えば僕の場合はhail2u.mit-license.orgです。このページを見るとわかるように権利者の名前と発行年、オプションとしてWebサイトのURLにリンクを張れたりもします。 curlでJSONを送りつけるという方法でも登録できるみたいですが、JSONファイルの登録とバッティングした
GoogleのCDNを使うか単にcatするか
有名ライブラリ、例えばjQueryを利用する時GoogleのCDNを使うことが多いけど、どうせ依存するなら単にcatしてまとめても良い(はず)。つまりHTTPリクエストがひとつ増えるデメリットと転送量の低下を期待するメリットのどちらがそのWebサイトにとって効果的かを考えなくてはならない。 Webサイトの規模が大きくハードウェア性能に余裕があるなら、転送量が増えることはデメリットには成り得ないのでcatする方がメリットが大きそう。そしてWebサイトにアクセスできればそのライブラリに依存したスクリプトが動くことをかなりの確率で保証できる。対して規模が小さいなら転送量の増加はコストの増加につながりやすく厳しい。HTTPリクエストの増加はユーザーに負担を求めることになるが、Google CDNのようなキャッシュが大いに期待できるものならなんとかメリットが上回りそう。 というのが僕のイメージなんだ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
fixed in relative
ul after floated element