最近の Twitter はちゃんと動作してるとは思えないので、 Wassr を試してみた。
サクサク動くし、「購読」の簡単さが気持ちいいのでしばらくいるつもり。
でも、足跡機能がいただけない。 興味なければ使わなければいいんだけど、 グロナビにどーんとあるので、
気になってついクリックしちゃう
↓
足跡増えてなくてがっかり
↓
って俺足跡気にしてんじゃん！
っていうことになって自尊心が傷つきかねません。
そんな、虚栄心と自尊心とモテたい気持ちがせめぎあってる、 お前は俺か！みたいな人向けの Greasemonkey 書きました。
// ==UserScript==
// @name noWassrFootmark
// @namespace http://pm.11op.net/
// @description remove footmark from wassr
// @include http://wassr.jp/*
// ==/UserScript==
+function(){
if (location.href=="http://wassr.jp/my/footmark/") {
location.href="http://wassr.jp/my/";
return;
}
var d = document;
var $ = function(id){
return d.getElementById(id);
}
var $$ = function(id){
var node = d.evaluate(id, d, null, XPathResult.ORDERED_NODE_SNAPSHOT_TYPE,null);
var item = [];
for ( var i=0 ; i < node.snapshotLength; i++ ) {
item.push(node.snapshotItem(i));
}
return item;
}
$$("//li/a[@href='http://wassr.jp/my/footmark/']/..")[0].innerHTML = '';
}();
]]>
勝ち組負け組から始まり、SだMだ、ギークだスーツだ、マッチョだウィンプだ、
真ん中分けだ横分けだ、うんこだちんこだと、
こんなのね、どっちでもない場合がほとんどだと思うわけですよ。
どっちかって言うとMとか、強いて言えばギークだとか、
もう何を言ってるんだと。
考えずにどっちかわからないような時点でどっちでもないし、
どっちか決める必要もないわけで。
まあ世の中にはとにかく2つに分けたがる人間とそうでもない人間の2種類がいて、
僕はどっちかと言うと分けたがらない方の人間なので、
強いて言えばそういう分類には興味がないですね。
開発ブログにて、授賞式当日のプレゼン資料を公開してます。
僕はプログラマという、割と裏方の仕事を生業にしているので、
そして特にサーバサイドをメインにやって来たので、
賞レースとは無縁の人間だと思ってました。
だから、今回の受賞に対してはうれしさもありますが、驚きとか、
正直ちょっと怯んでる面もあります。
でも、みんなが褒めてくれたりするので、
なんだかふわふわした気持ちが続いています。
こういう時こそ厳しい意見に耳を傾けつつ、
足下救われないように地に足つけてがんばっていかねば！なんて思ってます。
あと、JSON Editor は一人では決してできなかったものだし、
やっぱチームでの仕事っておもろいなーって思います。
JSON Editor はこれからも育てていきます。
もっと軽くしたいし、AIR ならではって機能もどんどん付けて行きたいです。
UI における「正解」の追求も続けないと。
で、また近いうちに、おもしろいもの、便利なものを
ポロッと生み出したいもんですね。
僕は Adobe AIR にすごい可能性を感じてる。
Adobe AIR の魅力は、いろんな方が既に挙げているように、
等、いろいろあって、僕もやはりそういうところに魅力を感じる。
でも、もう一つ僕がいいなーと思う事があって、
それはアプリの開発時に、WEB・ローカル双方を意識できるということだ。
プログラマがサーバサイドとクライアントサイド両方の言語を学ぶ事で
プログラミングへの理解を深めていくように（僕はまだまだだけど）、
WEB アプリ制作者も Adobe AIR のおかげで
ローカルアプリ作成に気軽に手を出す事ができるので、
WEB・ローカル双方のアプリ開発に携わる事で、
プログラミングと同様のことが言えるんじゃないか。
今後、AIR アプリ開発を通じて頭パーンッなって、
革新的な UI とか出て来ないかなー。
なんて思いながら、ちょこちょこ AIR いじってる。
結構おもろいですよ、AIR。ほんとに。
あとね、AIR アプリ開発って聞くと、
「開発してるふり」みたいな感じがしておもしろい。
エアギターのエアね。
エア開発。
エアプログラミング。
エアエア開発。
ITmedia News：Adobe、「Apollo」改め「Adobe AIR」をβリリース
前から不思議だったんだ。
なんでわざわざそんな検索で不利な名前に名称変更するのか。
でも、さっきお風呂に入ってる時に気が付いた。
それこそが狙いなんだよ。
「AIR」って名前は一般的すぎる。
そんなこと、だれでもわかる。Google だって知ってる。
例えば Google で検索してみると、
なんかよくわからん美容院が1位に出てくる。
そんな具合だから、AIR の話をしようと思ったら、AIR じゃ伝わりにくいから
「Adobe AIR」って書きたくなる。
それこそがアドべの狙いだったんだよ！！
これは AIR を通じて「Adobe」って言葉をインターネットにばらまこうという、
アドビーの陰謀だ！
そしてゆくゆくは「AIR」っていう一般名詞を Adobe と結びつけてしまおうという気なんだ。
きっと今に
「Adobe 製品はインターネットにおける空気のような存在です。」
なんてうまいこと言い始めるぞ。
みんな気をつけろ！
ところで、AIR って Adobe Integrated Runtime の略称だって知ってた？
危険が危ない！
読み：じゅーいち 由来：学園祭か何かで聞いた、フリッパーズギターの コピーバンドの「3a.m.op（邦題 午前3時のオプ）」が結構よかった。 ↓ それが印象に残ってたけど、曲名を間違って「11pm.op」と覚えてた。 ↓ 数字から始まるIDは使えなかったりするので、順番を入れ替えた。 ↓ 発音しにくいので、「じゅーいち」って読むことにした。
初めて勉強会に出て自分の ID を読み上げた時に、なんて発音しづらい名前だろうと思って、
pm11op と書いて「じゅーいち」って読む事にした。
その時は「ピーエムイレブンオーピー」って読んでた。
「スリーエーエムオーオーピー」が元ネタだし。
発音しづらいし、読み上げるの恥ずかしかったから「じゅーいち」って読む事にしたんだけど、
この読みすらも同じくらいの時期に一度お会いした、 studio15(スタジオジュウゴ) さんのパクリだ。
僕は以前、 はてなダイアリーを書いていて、
そこではどちらかというと技術的な話（しょぼいけど）を書いていたので、
しょーもない話はこっちで書こうかとか思ってた。
で、いずれは技術的な話もこのドメインで書こうと思っていて、その時は
am.11op.net てサブドメインでブログ書くつもりだった。
pm.11op.net でしょーもない話して、
am.11op.net で技術の話したら午前の顔と午後の顔みたいでかっこいいやんとか思ってたからなんだけど、
もうそういう切り分け自体が前時代的というか、
そもそも技術面で僕に書ける事なんかそんなにないし、
いつからか「うんこ」とか「ちんこ」とかが無駄に登場するこのブログ内で
技術的な話を書いた時に、いかに説得力を持てるかというところをゴールに考える事にした。
その時点で am.11op.net は消えた。
でも、世の中にはいろんな人がいるもんで、
僕なんかよりもよっぽど「うんこ」についておもしろがることに長けている人がいる。
その人は生活と人格をかけてまで「うんこ」をおもしろがるような人で（面識はないけど、多分そうだ）、
しかもそのためにはうんこを物理的に扱ってしまうことまでできてしまうような人だ。
その現実に直面して、僕はブログを書く気を無くしてしまった。
だって、僕にはもはや書く事が何も無くなってしまったのだ。
うんこのことですら、そういう人の劣化コピーでしかないのだ。
その頃と時を同じくして、自社サイトで本名が晒される。
この時に、僕はそろそろ腹を括るべきだなあと思ったんだ。
そもそも僕は何のためにブログを書こうと思ってたかというと、
別に世界で一番「うんこ」をおもしろがれる人になりたかったわけでもないし、
技術面で一目置かれたいと思ってた訳でもなく、
単にこのハンドル名 pm11op 或いは am11op に何らかの人格を与えたかっただけだ。
ネット上だけで通用する人格。
そういうものに憧れた時期もありました。
でも結局のところ、それは無意味なことだと最近思いつつある。
ネット上で完結する人格なんてあり得ないし、あったとしても無意味だ。
ネット上でしか面識のない人と実際に会うとなった時、
僕はこの「木下 勝（仮名）」という顔と人格と名刺を持って会いに行くのだ。
僕にできる事といったら、ネットだろうがリアルだろうが、
結局「木下 勝（偽名）」にできることの全部或いは一部の切り売りぐらいだし、
それって結局あるがままってことだよね。
「木下 勝（源氏名）」そのものでしかないわけなんですよ。
]]>タイトルはホッテントリメーカーに考えてもらったんだけど、ものすごい普通のタイトルが出来上がってびっくりした。まあ普通でいい。
そしてホッテントリにはならないし、ならなくていい。
今回身に付いたのは9章、クラスの部分。
その前に、まずは prototype チェーンについて guccyon さんのブログでおさらい。
__proto__とprototypeについて - guccyonikki
僕にわかる範囲でまとめると、オブジェクトのプロパティが参照されると、
オッケー。ここで僕は考えた。
それなら、最初に読まれる自分のプロパティで完結する場合が一番早いんじゃないか。
ここでの事の本質は早さじゃないとは思うけど、それでもそう考えた。あまりにも短絡的すぎるけど、考えたったら考えた。
でも実際にはむしろ自分のプロパティを参照する方がパフォーマンスが悪くなる場合もあるようだ。
なんでかなー。
function Rectangle(w, h) { this.w = w; this.h = h; this.area = function(){return this.w * this.h;} }
- (上記のような記述だと、)生成されたすべてのオブジェクトが3つのプロパティを持ってしまう(p.153)
- プロトタイプオブジェクトを使用すると、たくさんのオブジェクトがプロパティを継承し共有できる(p.154)
- あるクラスに10個のオブジェクトがあるとすれば、それぞれのオブジェクトごとにインスタンスプロパティが1個ずつ存在し、全部で10個(p.159)
ってことだからだだね。
試しに以下のクラスを準備して、ベンチマーク取ってみた。
function Test1 (){
this.hoge = 1;
this.fuga = 2;
this.count10000 = function(){var i=0;while(i< 10000 ){i++;}return i;}
}
function Test1 (){
this.hoge = 1;
this.fuga = 2;
this.count10000 = function(){var i=0;while(i< 10000 ){i++;}return i;}
…
this.count10100 = function(){var i=0;while(i< 10100 ){i++;}return i;}
}
function Test3 (){
this.hoge = 1;
this.fuga = 2;
}
Test3.prototype.count10000 = function(){var i=0;while(i< 10000 ){i++;}return i;}
function Test4 (){
this.hoge = 1;
this.fuga = 2;
}
Test4.prototype.count10000 = function(){var i=0;while(i< 10000 ){i++;}return i;}
…
Test4.prototype.count10100 = function(){var i=0;while(i< 10100 ){i++;}return i;}
function Test5 (){
this.hoge = 1;
this.fuga = 2;
}
Test5.count10000 = function(){var i=0;while(i< 10000 ){i++;}return i;}
…
Test5.count10100 = function(){var i=0;while(i< 10100 ){i++;}return i;}
それぞれのクラスを100個ずつインスタンス化し、count10000メソッドを実行させた。
（ただし、Test5 はインスタンス化しただけ）
実行結果
preparing ... let's go! . *** Test1 *** result : 538.986725[ms] . *** Test2 *** result : 822.986725[ms] . *** Test3 *** result : 536.986725[ms] . *** Test4 *** result : 535.986725[ms] . *** Test5 *** result : 537.986725[ms] . finish!
Test2 以外はそれほど変わらない。
Test2 はインスタンス化の時に101個メソッドを持つインスタンスプロパティがコピーされるので、遅い。
だからまあ、プロパティの参照時の早さどうこうじゃないけど。作法として間違ってる。
僕は java を知らない子供たちなので、インスタンスメソッドとかクラスメソッドとか言われてもよくわかんなかったけど、this とか必要ないメソッドはクラスメソッドにしたらいいんだと思う。
ようやく javascript のクラスがわかってきたかなー。
今回、幸いにも LT の時間をいただけたので、拙作(一人で作ったわけじゃないけど)の JSON Editorを紹介して来た。
LT はぐずぐずだったけど、JSON Editor自体は結構好評でよかった。
ujihisa さんが発表10分後にブログで紹介してくれたり
rubyneko - ブラウザ上で動作するJSON Editorがすばらしい、
kanasan さんが30分以内にいきなり拡張スクリプトを書いてくれたり、正直ちょっとチビりそうだった。
初めて懇親会に参加したので、渾身の力を振り絞って懇親会に来た全員に「こんにちは」って言って来た。
懇親会に来た全員の顔と名前も覚えた。覚えてどうすんだっていう話だけど、「あの人がんばってんなー、チクショウ！」なんて思いながら僕もがんばろうと思う。
がんばるっていうか、まあ日々楽しくやっていきたい。
というわけで、主催の kanasan さん, ujihisa さん、運営に携わってるみなさん、ありがとうございました。
みなさんお疲れさまでした。
まだ UI は準備できてないですが、以下のような url でアクセスすることで利用可能です。
http://jsoneditor.net/#uri/{JSONのURL}
(例)twitter のパブリックタイムラインの JSON 読み込み
http://jsoneditor.net/#uri/http://twitter.com/statuses/public_timeline.json
(例)このブログの ATOM フィード 読み込み
http://jsoneditor.net/#uri/http://pm.11op.net/atom.xml
昨日は帰ってくるなり寝てしまったので、日曜の真っ昼間に公開です。。
Kanasan.JS JavaScript第5版読書会#4 & 懇親会
に参加したいので、今更ですがレポートアップします。
--------------------------------------
机が見たことない配置になっててちょっとおもしろかった。
目の錯覚で長く見えたり短く見えたりする矢印みたいなやつの、
長く見える方みたいになってた。
p.115 Array の削除用のメソッドは特にない。splice を使う。
p.116 Array の length プロパティは変更可能
length を変更すると、Array の要素も変更される。
var hoge = [1, 2, 3]
hoge.length = 4; // hoge = [1, 2, 3, undefined]
これが Array オブジェクトのみの特徴。
Array 的なオブジェクトを作ることもできるが、その場合は上記特性は持たない。
Array.cocat は非破壊。
Array はオブジェクトなので、比較する時には toString 等の処理が必要。
これ、javascript 書き始めの頃はは理解できなかったなあ。
[1,2,3] == [1,2,3] // false
arguments は Arguments オブジェクトであって配列ではない。
いわゆる、配列的なオブジェクト。
function h() {
var i = 1;
if(i==1) {
function a() {alert("sss");}
a();
}
}
h();
は実装依存なので、関数リテラルにすべき。
function h() {
var i = 1;
if(i==1) {
var a = function() {alert("sss");}
a();
}
}
arguments.callee.caller も実装依存！
0||function(){console.log(1)}() にすれば式になる
(function(){})() はめんどくさいと思ってたので助かる
+function(){}() でも可？
p.137 arguments.callee とする方が安全
その方が確実に再帰できるし、見た目的にも再帰であることが自明なので。
関数名変更したりもするので。
p.138
関数 property は関数内からのみ参照できる。これ知らなかった。便利。
apply と Math
apply はそういう使い方もできる。
p.140 callee 化
function(a, b ) -> function(a){return function(b){}}
p.144 clousure の例
p.148 Function() コンストラクタは静的スコープを使わない
eval はそのときのスコープを使う
closure の定義についてちょっと意見が別れた感じ。
ということで、初参加の読書会でしたが、こちらもとても勉強になりました。
なかなか復習の時間取れなくてレポート遅延し過ぎました。
主催者及びスタッフの ujihisa さん、Kanasan さん、37to さん、
参加されたみなさん、おつかれさまでした。
それにしても、僕は勉強会に出ると消耗しすぎる。
この日は家に着いてから震えが止まらなくなり、夜半に熱が出た。知恵熱（笑）
高熱にうなされながら見た夢は、やはり javascript のデバッグをしてる夢だった。
例えば、 Gmail 上で「?」キーを押すと表示されるショートカットヘルプから一部引用すると、
Jumping
g then i : Go to Inbox
g then s : Go to Starred conversations
g then t : Go to Sent messages
g then d : Go to Drafts
g then a : Go to All mail
g then c : Go to Contacts
Threadlist selection
* then a : Select all conversations
* then n : Deselect all conversations
* then r : Select read conversations
* then u : Select unread conversations
* then s : Select starred conversations
* then t : Select unstarred conversations
こんな感じ。
これがすごく便利なのでどうやってるのか知りたかったんだけど、
Gmail のソースコードは難読化してあって僕みたいなものには読むことができませんでした。
でも、僕たちには hotkey.js というすばらしいライブラリがあります。
LDR や Fastladderにも使われてるやつですね。
これを拡張して Gmail みたいに複数キーの組み合わせのショートカットを簡単に実現できるようにしました。
これつかって JSON Editor のショートカットをちゃんと vi ライクにするよー。
HotKey.prototype._keyfunc = {};
HotKey.prototype._keylog = [];
HotKey.prototype._interval = 500;
HotKey.prototype._timerid = '';
HotKey.prototype._separater = '+';
HotKey.prototype.invoke = function(input){
input = input || this.lastInput;
var e = this.event;
if (input != 'shift') this._keylog.push(input);
clearTimeout(this._timerid);
var keys = this._keylog.join(this._separater);
if(this._keyfunc.hasOwnProperty(keys)){
this._keyfunc[keys].call(this,e);
this.abort && /*Event.stop(e);*/ e.preventDefault ? e.preventDefault() : e.stopPropagation();
this._keylog = [];
return true;
} else {
var self = this;
this._timerid = setTimeout(function(){self._keylog=[];}, this._interval);
this.abort && /*Event.stop(e);*/ e.preventDefault ? e.preventDefault() : e.stopPropagation();
return true;
}
}
]]>
まずはプロモムービーを見てみてください。(1分30秒)
機能はいろいろとありますが、特にこだわったのは、 ショートカットを使って、キーボードから手を離すことなく全ての操作ができるという点です。
JSON や XML を扱うことがある方はぜひ一度使ってみてください。
開発ブログもありますよ。
]]>
ブログさぼってた内に書きたいことが溜まってるかというと、
これがそうでもない。
それでも、いくつかは書いておきたいこと、書いておかなければならないことがある。
まあそれは追々書いていくとして、
今日帰宅の電車の中で、両サイドから居眠りの女性にもたれ掛かられた。
Twitter にも書いたけど、こんなこと滅多にあるもんじゃない。
記憶が薄れない内にブログにも書いておいた。
総勢50名を超える参加者だったようで。
最近関西でも勉強会が増えてきてうれしい限りだ。
僕も早く MacBook 買って、
もっと勉強会出たりあわよくば発表したりしたいなーとか思いながら
会社で釣り動画サイトを見てた。釣りっても本物の釣りの方ね。
釣り楽しそうだなー。
僕の中で釣りって「キングオブ趣味」って気がする。
もちろん本物の釣りの方。
それだけに敷居が高い。
何せ相手はキングだから。
キングサイズオブ敷居。
専門用語よくわからんし。
車無いとキツイだろうし。
僕ちん車持ってないよ。
それに水辺は危険がいっぱいだし。
変な虫がいたり、水に落ちて死んだりもするらしいよ。妄想だけど。
とかいろいろ考えて脳内完結しつつあるけど、
動画見てたらやっぱり楽しそう。
って何で俺は釣りの話をしているのー。
そんな僕にも、本気で神に祈ったことが何度かある。
前述したが僕は無宗教なので、
ここで言う神とは単に「全知全能の存在」というものだ。
特定の宗教の信仰の対象である神とは全く別のものである。
ちょくちょく神に祈っていたのは高校生の時だ。
神に祈るのは朝の通学時の電車の中でと決まっていた。
別に世界平和を祈っていたわけではない。
僕は田舎に住んでいたので、
電車は1時間に1本しか走っていなかった。
その電車で片道40分かけて、高校に通っていたのだ。
毎日電車に乗っていれば、
電車内で便意を催すことだってある。
途中下車して駅の便所で用を足せば住む話だが、
なんせ田舎なので、無人駅ばかりである。
便所なんかないし、仮にあったとしても
田舎のJRの無人駅の公衆便所というのは
日本の便所カーストの中でも最下層に位置する便所だ。
思春期という人生で一番デリケートな時期に、
そんな所でうんこできるもんか。
しかも、途中下車したら最後、
次の電車まで小一時間何も無い無人駅で過ごすことになる。
もちろん、駅出てもコンビニなんてないよ。
だから、電車内で便意を催しても我慢するしかなかった。
胃腸が弱い方だったので、何度も電車内便意を経験してるうちに、
我慢の仕方の心得はかなり蓄積されていた。
呼吸法とか、波の弱い時の手の抜き方とか。
それでも我慢が限界に達した時、
自分に「今までよくやった」とか言い聞かせ始めた時、
この苦しみから一時的でもいいから開放されてしまいたくなった時、
神に祈ったものだ。
「神様お願いです、○○駅まで我慢させてください」
便意の強い波が来た時には
「もうオナニーしませんから、便意を引かせてください」
って祈ってた。
結果的に、僕は高校時代一度もうんこを漏らしていない。
だから神はいると言いたいのではなくて、
信仰が人を強くするということはあるかもねと言いたいのだ。
これを信仰っていうのはあんまりだが。
あと、ここで言う信仰っていうのは、「祈る対象がある」っていうくらいの意味だ。
そこで初めてプログラミングに出会った。24歳くらいの時だった。
モラトリアム期間を満喫していた僕は「これだ！」と思ったんだと思う。
その講義を受けなかったら僕はプログラマになっていない。
FORTRAN の講義なんて受けてるのはプログラミング初心者ばかりだった。
そのくせ、初心者向けにしては結構難解な課題が毎回出た。
その講義を受けるのは主に化学系の3回生で、その3回生というのは実験に次ぐ実験の毎日だ。
化学実験には半日くらい余裕でかかるし、さらにレポート書いて提出しなきゃいけない。
忙しい3回生に、その時点ですら一生使わないと断言できた FORTRAN の課題をこなす時間なんかなかった。
当然課題の提出率はかなり低く、例え提出したとしてもそれは誰かのコピーに過ぎなかった。
そんあある日、その講義の講師が諭すように語った言葉が今でも忘れられない。
現代人にとって、時間が無いのは当たり前のことである。 「時間がない」ということを言い訳にしてはならない。 それは思考停止に他ならない。 時間は作るものである。
もっとすらすら書けると思ってたけど、だいぶ忘れてた。
まあ、上記のようなことを言ったのだ。
当時の僕にとって、時間は浪費するものだった。
その講義を受けてた学生の90％以上は3回生だったが、
6回生の僕にとってプログラミングは格好の時間潰しだったので、
毎回余裕で課題を提出してた。
だから僕は衝撃を受けた。
時間の流れというのは人によって違うんだと。
それは当たり前のことなんだけど。
人より2,3年無駄に過ごすのも時間の作り方なんじゃないか。
屁理屈だけど、そう思った。今そう思った。
「時間は作るもの」の解釈の仕方は日々変わってるけど、
いつも自分の戒めになってる。
鬱になるほど仕事し続けた前職ではいかに無駄な時間を削るかばかり
を考えてた気がする。寝る間を惜しんだりとか。
通勤は自転車で5分だったりとか。
部屋ではベッドから手が届く範囲に必要なもの（マウスとかキーボードとか含む）が全部置かれていたりとか。
今では通勤時間が作られた時間だ。
毎日往復で3時間を移動時間に費やしてる。賃貸のくせに。
でも、今の僕にはその時間がかなり重要。
何せ1日3時間、妄想し放題だ。
あと、ツレアイが寝た後、夜な夜な30分くらいパワプロやってる。
だから、家でコード書く時間がないんだよね。
というわけで明けましておめでとうございます。