はてなユーザーを分りやすくするUserJS (Greasemonkey)
nicovideo_wnp.js at master from miya2000’s wnp — GitHubを参考に、Flashを毎回クリックしなくても勝手に再生されるようにした。
http://d.hatena.ne.jp/javascripter/20081003/1223033435
みんなせっかちなんだなぁ…。更新が滞ってるので、グリモンって事でひとネタ。
はてなにはいろんな人が居るけど、英数字のidだけじゃ有名な人以外誰が誰だか分らない。本当は何度か目にした事がある人も識別できない。そのためにユーザーアイコンがあって凝ったのを登録してる人も居るけど、ほとんどの場所では16x16のごま粒みたいにちっさい表示で何が何だか分らない。ドット絵職人にはいいかも知れないけど。
というわけで作ってみた。はてなの色んな所で、ごま粒ユーザーアイコンにマウスをかざすと「真の姿」を見る事が出来る。
- 使用前
- 使用後(アイコンにマウスをかざしたとき*1)
以下からインストール可能。ただし、Opera9.5でしか試してないんですみません*2。
使ってみると、結構「この人(アイコン)って、本当はこんなだったんだー!」ってなると思う。てか、なった*3。
謝辞とか
「はてなブックマークのアイコンを拡大縮小するボタンを付けるGreasemonkey/SeaHorse Script」を参考というかベースにさせて頂きました。一部の変数名などに面影が残ってます。マウスを合わせる必要がある代わりに、もっとどこででも、もっと大きく分りやすくしました。
-
- オリジナルとの共存を力尽くで実現してます。勢いの産物なのですみません。
- どうせこう改造するならiframeとか使った方がいいんでしょうけど、勢いの産物なのですみません。
*2:ちょっと試した範囲ではFxでもとりあえずは動いた
*3:http://image.blog.livedoor.jp/guideline/imgs/a/9/a9249186.jpg を見たときにちょっと似てる
Amazonの商品を送料無料でセブンイレブンで受け取れるUserJS(Greasemonkey)
Amazon.co.jpは1日、注文した商品をコンビニエンスストアの店頭で受け取れる「コンビニ受取」サービスを開始した。現時点では、対象となるコンビニはローソンのみとなっている。
http://internet.watch.impress.co.jp/cda/news/2008/07/02/20132.html
一番最寄りはセブンイレブンなので。ついでに送料無料だし。というわけで作った奴。Amazon商品ページで7&Yの該当商品 (ISBNがあるもの)ページへのリンクが表示される。
Opera9.5でしか試してない*1。
とりあえず、こっちをインストールしとけば、Amazonの商品ページで、7&Yの当該商品検索結果画面へのリンクができる。
http://userscripts.org/scripts/source/34921.user.js
// ==UserScript== // @name Amazon to 7&y // @namespace http://www.hatena.ne.jp/r-west/ // @description Amazon to 7&y // @include http://*.amazon.* // ==/UserScript== (function(){ function libsearch() { var mainmatch = window.location.href.match(/\/(\d{9}[\d|X])/); if (!mainmatch) { return; } var asin = mainmatch[1]; if (!asin){ return; } var bs = document.getElementsByTagName('b'); for (i in bs) { if (bs[i].getAttribute('class') == 'sans') { var header = bs[i]; break; } } if (!header) { return } var spl_link = document.createElement('a'); spl_link.setAttribute('href', 'http://www.7andy.jp/all/search_result/?kword_in=' + transToIsbn13(asin)); spl_link.innerHTML = '<span style=\"font-size:90%; background-color:#ffffcc;\">» Search 7&Y! </span>'; header.parentNode.insertBefore(spl_link, header.nextSibling); } function transToIsbn13(asin) { var isbn12 = "978" + asin.substring(0,9); var sum=0; for (var i=0 ; i<12 ; i++) { sum = sum + (isbn12.charAt(i)-'0') * (i%2==0 ? 1 : 3); } return isbn12 + ((10-(sum % 10))%10); } libsearch(); })();
こっちもインストールすると、上記で飛んだ7&Yの検索結果ページから、商品詳細ページを開く1クリックの手間が省ける。
http://userscripts.org/scripts/source/34923.user.js
// ==UserScript== // @name 7andY direct by isbn // @namespace http://www.hatena.ne.jp/r-west/ // @include http://www.7andy.jp/all/search_result/* // @description // ==/UserScript== (function () { if(document.referrer.indexOf('amazon')<0){ return; } var zz=document.evaluate('//td/small/a[contains(@href,"detail/-/accd")]',document,document.createNSResolver(document),XPathResult.ORDERED_NODE_SNAPSHOT_TYPE,null); location.href=zz.snapshotItem(0); })();
Yahoo支店版も作ったけど、Yahoo支店だとISBNが入ってない書籍があったので止めた。
*1:超適当だけど。2本組というのもダサい
悲劇のフレームワーク Apache Ant 〜悪魔のantcall〜 (vs depends)
フレームワークっていうよりDSLだけど、いずれも枠組みであって、枠に嵌められるし、外れるとおかしくなる。
フレームワークには大きな枠組みがあって、そのなかで変えるべきところを自分なりに変えれば、そのシステムを好きにすることができます。しかしあくまで「変えるべきところ」がどこなのか、「どのように変えるべき」なのかは他の数多くの制約に従わなければいけません。
http://blog.so-net.ne.jp/shi3z/2008-02-14
Antは元来「Javaでのmake」なんて言われるmake代替ツールだった。その枠組みはこんな感じ
projectとは
- 特定の環境について期待する副作用群の定義
- 期待する副作用は、targetとして定義される
targetとは
- 期待される副作用
- 先に起こされているべき副作用(depends)と本体からなる
- 本体は、一度だけ実行される*1
- 本体は、taskの列として定義する
taskとは
- 実際に副作用を起こす処理
- パラメタライズされており、バリエーションを変えて何度でも実行される
手続き型プログラミング言語のような制御機構や関数・サブルーチンはなく、あるのはmake同様、targetの依存(包含と言った方がよいかも)のみ。つまり、静的に決まった包含関係にある副作用定義群として問題を記述するという枠組みのはずだった*2。
しかし、上記の枠組みは、こんな直感も引き起こしてしまう。
targetとは
- そのproject固有なもの
taskとは
- どのprojectでも使える汎用的なもの
さらに発展して、
targetとは
- そのproject固有な、サブルーチン。
という認識まで生んでしまった。その悪魔の申し子がantcallだ。確かにこれは手続き型言語の発想で制御しやすく、paramもあるし、使い勝手がよい。…ように思える。
targetで指定できるdepends属性ですが、前提条件として実行しておきたいタスクを指定しておくためのものとしてよくつかわれていますよね。タスクをまとめて実行するのには便利と言えば便利ですが、antcallで一つ一つ指定しておいたほうが使いやすかったりします。
http://d.hatena.ne.jp/kompiro/20080210/1202640279
だが、targetはサブルーチンではない。上記の通り、本来、projectとして1度限り起きるはずのものであり、それは本体だけでなく、dependsも含む。この根本的矛盾を無理矢理整合させるため、targetはproject丸ごとを子projectとして起こし直して実行される。これにより、build.xmlなどの定義は丸ごと再パースされるわ、トップレベルに書かれたtaskは再実行されるわ、プロパティを設定しても親には反映されないわ、dependsもみんな実行されるわで、サブルーチンという直感とはかけ離れた振る舞いを示す。
枠組みを外れると根本的な破綻を呼び寄せるのは、枠組み(フレームワーク)として当たり前の事だ。
しかし、実際問題、targetとdependsだけでは不満もあるだろう。でもそれは、antの根幹への否定といえる。それなのに、Antは自身の枠組みをグダグダにする事で応えてしまった。自分の枠組みを否定した枠組み(フレームワーク)。
マシン語?量子論?どこまで掘り下げるとプロ?
マシン語はプログラミングの深淵であり、母であり、基礎です。
http://d.hatena.ne.jp/shi3z/20070911
個人的にマシン語を愛するというのは構わないけど、
プログラムが書ける、という状態は「マシン語が書ける」という状態の延長線上にあるべきで、マシン語を理解していないということはマシンを理解していない、つまりプログラムを理解していないのとほぼ同じだと思います。
http://d.hatena.ne.jp/shi3z/20070911/1189493767
これでは、愛は盲目と引いた目で見てしまう。
元記事のコメントにもあったけど、マシン語必須なら量子力学は?なんて話もあって、結局程度問題、という曖昧な話になりがち。
だから具体的に『仕事に役立つ知識・スキルは須く知る/体得する「べき」』として、「マシン語が書ける」は体得するべきかどうか、をはっきりさせよう。
心構えとか精神論はひとまず置いて、仕事の役に立つかどうか。具体的には、レイヤー化の階層を越えて、プログラミングに影響を与えるかどうか。
たとえば、
- 物理メモリが有限というハード面の事実は、メモリを無駄遣いはダメ、という形でプログラミングに影響を与える。
- ディスクはメモリより遅いというハード面の事実は、無用なディスクアクセスはダメ、という形でプログラミングに影響を与える。
- データはメモリからレジスタにロードして処理してメモリに書き出すというハード面の事実は、レジスタビット長を超えた変数は(ハードでアトミック操作が保証されてないと)マルチスレッドアクセスでは排他しないとダメ、という形でプログラミングに影響を与える。
など。
これらは、必要なハード面の知識ではあるが、マシン語のスキルとは関係ない。そう考えると、「マシン語が書ける」スキルが役に立つ場面が浮かばない*2。というわけで、考えつく限りでは「マシン語が書ける」スキルはプロに必要なスキルではない。
下を意識しなくて良いようにレイヤーというモノがあるわけで、その上で仕事する分には、レイヤーのほころびからの漏れを理解・対処するだけの、下位レイヤー知識があればいい*3。あとはその頻度やインパクトで、他の事とのプライオリティをどう付けるかという話。良い結果を生むために学ぶものは他にも幾らでもある。
(追記)core見る時…。やっぱり『べき』でいうと「必要」かも(汗)
「マシン語を知らない子ども達」の問題点
イデオロギーの問題にされてしまったけど、こっちで書いた通り、ハードやシステムに関する基礎知識はプロとして*1必須なのは当たり前。だって、知らなきゃ正しい仕事ができないんだから。
「http://d.hatena.ne.jp/shi3z/20070911/1189493767 マシン語を知らない子ども達」は、「今の若い奴らはマシン語を知らない!」と嘆いて、いくつかの問題事例を挙げ、「ほら、マシン語使えないとこうだよ」とマシン語の習得を勧めている。ここで挙げられた問題事例はいずれも困ったことばかり。こうFUDを突きつけられると、「やっぱマシン語かなぁ」と思う人が出るのも仕方ない。だが、これらの問題事例はいずれもマシン語の知識とは関係がない問題。マシン語と関係ないことをあげて、マシン語マシン語と煽っている。それらの問題回避・対処に必要なのは、ハードやシステムに関する基礎知識であって、マシン語のスキルではない。
実際のプログラミングや開発・保守で役に立つハードやシステムに関する基礎知識は、普段の自分の体験を思い出しながらさらっと文献を読む程度で足りてしまう。しかし、マシン語で実際プログラムを書くまで求めると、ハードルが上がってしまう。挙げられたような問題をしでかしてしまう技術者には、ほかにも学ばなくてはいけないことはいくらでもあるのに。
もちろん、ハードやシステムに関する基礎知識を学ぶ方法として、マシン語(アセンブリ)でプログラムを書いてみる、というのは時間さえ取れるなら悪くない*2。それに、年配者には思い入れのある体験だろう。年配者じゃなくても小鼻をヒクつかせて語りたい体験かもしれないし、なにより、心ある技術者には魅力的だ。しかし、嘘のFUDでそれを勧めるのは頂けない。
ところで、「マシン語」っていう言い方は、ベーマガ方面出身ですかね?TK-80ではそういう呼び方はしてないような気がするけど。
静的モデリングとモデルレス
なるほど、リアルな現場の知恵、勉強になります。
プログラマの方にとっては、Date型を使わないことへの疑問があるようです。
日付のデータをyyyymmddで扱う理由 - ある地方公務員電算担当のナヤミ
Date型でなく、なぜわざわざyyyymmdd形式で日付のデータを扱うのかというと、自治体の業務においては必要な場合があります。
これで思うことがふたつ。
ひとつは、id:alittlethingさんが示した理由に対する、私の元エントリの考え方の延長。
ひとつには、ユーザである一般職員は業務を行ううえでExcelにデータを切り出して扱うことが多い、ということがあります。
それはシステム境界でのインタフェースについての話で、システム内でのデータの持ち方とイコールではないような。ただ、ユーザが勝手にDB直繋ぎしちゃうようなシステムもあるから、リアリティの点でどこまでかは微妙。
実在しない日付のまま処理せざるを得ない時があります。こういうときには、Date型でデータを持っていると処理不能になりますので
それは、システムの要件に対して、使用したDate型のモデルが適切ではないという問題で、その要件に合うDate型を使うのが解ではないかと。これも、リアリティの点でどこまでかは微妙。
そして、もうひとつ。
それは、私の元エントリの考え方の延長が、リアリティの点で微妙であると言うこと。とくにふたつめのモデルの話。
プログラムを書く時、システムを作る時、そこには必ず大小のモデルの構築がある。構築されるのは、設計時のモデルであり、プログラミング・システム構築は静的モデリングと言える。しかし、プログラムもシステムも生きている。
設計時にはOpen-Closed Principleで申し分ない設計をしていても、想定外の変更で結局モデルを修正する事は、容易に発生する。全体に広くそのモデルへの依存がある場合、そのモデルが満たさない新たな(あるいは当初見落としていた)要求は、膨大な修正コストを強制する。
この場合、Date型を使ってたけど、実はもう一段上の、存在有無を問わない年月日の組み合わせの型が必要だった、と。でも、全体でDate型で使いまくりだと後の祭り。…そこで、抽象モデルですよ。具体型なんて使っちゃダメ。
いやいや、抽象モデルだってモデルであって、結局それは設計時の静的モデル。根本的にはOpen-Closed Principleと同じ話。で、日付を文字列で扱うってのはある意味、究極の抽象化ではある。モデルレス。これを付き進めれば、全てのデータは、byte列で扱えばいかなる制約も受けない。なんでもすべて struct {void* data; int length;}; 。完璧。なんでもできる!。素晴らしい。…ほんとか?
…書いてるうちにgdgdになったので、あとで断りなく直すかも。
(そうかんがえると、Haskellは具体型べったりで*1、生きたプログラムに厳しい言語だなぁ、改めて。)
*1:ADTはあるけど