Faviconの色をcanvasで変える

Apr 16th, 2012

github と github:enterpriseさんのfaviconが見分けがつかないので、Chrome拡張で差し替えることにしました。画像どうしようかとちょっと悩んだけど、色変えるだけでいいだろうとFireworksを起動するも、色を良い感じに変える方法がわからない…。

元がの通り、白黒なので、トーンカーブ的なものではダメそうで、諦めてcanvasでやることにしました。

var favicon=document.getElementsByTagName('img')[0];

var cv = document.createElement('canvas');
cv.width = 16;
cv.height = 16;
document.body.appendChild(cv);
var c = cv.getContext('2d');
c.drawImage(favicon, 0, 0, 16, 16);
var data = c.getImageData(0, 0, 16, 16);
var d = data.data;
for (var i = 0, len = d.length; i < len; i += 4 ) {
  d[i] = 255;
  d[i + 1] = 0;
  d[i + 2] = 0;
}
c.putImageData(data, 0, 0);

var a = document.createElement('a');
a.href = cv.toDataURL();
a.download = 'ge.png';
a.appendChild(cv);
document.body.appendChild(a);

うん、簡単だった。

ほぼ書き終えていた記事があったので、今更ながら公開…。

なぜ CoffeeScript がよいか

Apr 2nd, 2012

なぜ CoffeeScript がダメか - 冬通りに消え行く制服ガールは✖夢物語にリアルを求めない。 - subtechについて。

いや、本当はこのタイトルにするほど CoffeeScript 推しているわけではないのですが、まあそういう建前で書きます。

CoffeeScript のメリット

簡潔に書ける

簡潔であるということは、ソースコードにおいて、本質ではない部分を書かなくてよいということで、逆に言えば必要なことだけが書かれている状態に近くなります。少し慣れればむしろ読みやすくなる(と思います)。

JavaScript の罠を回避できる

var を忘れた変数がグローバル変数になるとか、変数のホイスティングとか、オブジェクトリテラルの最後のカンマとか、 JavaScript の for in は prototype を辿ってしまう問題とか、JavaScript の等価演算子が曖昧すぎて嵌りやすい問題とかとか、 CoffeeScript を使うだけで回避できる問題が結構あります。読む側(レビューする側)としても、注意する部分が少ないのでだいぶ楽になります。

書き方がある程度統一される

インデントが半強制的に揃う。また CoffeeScript を書く場所は実質外部ファイルなので(インラインに CoffeeScript を書く選択肢もないわけではない。 Rails だと coffee-filter とか Barista とか)、インラインにコードを書かれにくくなる。(まあ、 JavaScript で書いちゃえば元も子もないんだけど)

CoffeeScript のデメリット

デバッグしにくい

CoffeeScript のままデバッグできるようになる予定はあるが、今のところ JavaScript として出力されたコードをデバッグすることになる。ある程度長いコードになるとデバッグが大変になってきます。

記号が多めだけど、中途半端

-> や => 、 @ など、記号中心と思わせつつ、3項演算子は if ～ then ～ else ～と書かなければいけなかったりします。3項演算子のイマイチ感は特に強いですね。

将来的に廃れる可能性がある

現在、 ECMAScript6 とかその先の未来の JavaScript について議論が進められており、そこでの CoffeeScript の影響力はすごく大きくなっています。ただ、大きいがゆえに、 ECMAScript が CoffeeScript に近づいていく方向になってきています。というと、 CoffeeScript の長所に聞こえるかもしれませんが、実際は CoffeeScript そのものが採用されるわけではないので、 CoffeeScript は ECMAScript に似た中途半端な言語となってしまう可能性が高くなっています(というような話を edvakf さんが)。

メリットでもデメリットでもないあたり

個人的にポイントなのは、生成される JavaScript がかなり読みやすくて、比較的きれいな JavaScript が生成されるところにあると思っています。 GWT や Dart がはき出す JavaScript はとても人間が読み書きできるレベルではないですが、 CoffeeScript の生成する JavaScript はその正反対です。なので、デバッグは思ったほど大変ではないし、あとで CoffeeScript をやめたくなったら生成された JavaScript に乗り換えるだけでよいのです。極端なことを言えば、CoffeeScript はプロトタイピングだけに使って、メンテナンスは JavaScript の状態で行う運用だって可能です。

なので、今だからこそ CoffeeScript を触ってみるのがいいんじゃないかと思っています。 ECMAScript6 の先取りもできますしね。正直 CoffeeScript がベストとは思ってませんし、この先 CoffeeScript をやめるかもしれませんが、そのときは書きだした JavaScript をコミットし直すだけです。安心して触ってみましょう。

Octopressとgithub Pagesを使ったブログ

Apr 1st, 2012

はてなダイアリーからの移転先をいくつか検討していたのですが、どれもしっくりこない。。当分放置でいいかなと思いかけていたのですが、ちょうどGitHubにブログを設置してみたよ - Shogo’s Blogが目に入って、GitHubに置くのはよさそうだなぁと思い、試してみたのがこちらになります。

設置については、

などなど、参考になる記事はたくさんあるので、その辺の話は割愛します。

で、なぜ、はてなダイアリーから移転しようとしているのかというと、はてなブログの登場によりダイアリーのほうは後方互換的なアレになってしまったこと、DOCTYPEがアレで互換モードなのはまだいい(いや良くはないけど、今更互換モードとか逆に趣があるというか)としても、文字コードがeuc-jpなのは…みたいな感じです。素直にはてなブログにしてもいいんですが、面白くないよなーということで、辿り着いたのがOctopress + github Pagesといった感じです。

ただ、 Octopress は静的にHTMLを作ったりするところが Movable Type を彷彿させます。はてなダイアリーを使い始める前は Movable Type をレンタルサーバーに設置とかしていた時期がありまして、その頃にブログに書いていたのは Movable Type の設置方法だとか、カスタマイズがどうこうとか、ブログパーツを設置してみたとか、そういった内容ばかりでした。しばらくはそういったことを楽しんでいたのですが、ふと自分のブログの意味のなさに気がついてしまったわけです。たぶん、こういった現象は珍しくなくて、Linuxを触ったときもそういった傾向がありました。自由度が高いが故に、そのカスタマイズ自体に時間を取られてしまって、あとで振り返ってみるとすごく狭い範囲しか見えてなかったといった感じです。奥が深い症候群やyak shavingと少し似ています。

で、 Octopress はかなり自由度が高いので、ちょっと警戒しています。うっかりカスタマイズに時間を取られてしまう予感がしています。まあ、今ならその辺を意識してコントロールできそうなので、しばらくは続けてみようかと思っています。

Blog Archives