
Date:2012/04/26 19:06
我こそは「強い精神力」を持っているというみなさん、ぜひこの問題に挑戦して頂きたい。
「強い精神力」を持っている人なら解読できる暗号問題 | ロケットニュース24
暗号文は以下。
7H15 M3554G3 53RV35 7O PR0V3 H0W 0UR M1ND5 C4N D0 4M4Z1NG 7H1NG5! 1MPR3551V3 7H1NG5! 1N 7H3 B3G1NN1NG 17 WA5 H4RD BU7 N0W, 0N 7H15 LIN3 Y0UR M1ND 1S R34D1NG 17 4U70M471C4LLY W17H0U7 3V3N 7H1NK1NG 4B0U7 17, B3 PROUD! 0NLY C3R741N P30PL3 C4N R3AD 7H15. R3 P057 1F U C4N R34D 7H15.
読み方はわかったが、精神力が弱いためこれをすらすら読むことができない!という僕のために、精神力無限大のコンピュータさんにやってもらうようにした。
dankogaiさんにやられる前にな。

Date:2012/03/13 12:23
最近話題のはてブボタンのトラッキング問題で、オプトアウト対策しました。一応プログラミングとかのことを載せてるブログとしては。流行に乗る感じで。
はてなブックマークボタンは2011年9月1日より行動情報の取得をしている - ARTIFACT@ハテナ系
はてブのトラッキング問題で、はてなはアドバンテージを失った - 萌え理論Blog
はてなブックマークボタンのトラッキング問題で高木浩光先生が決別ツイートをするに至った経緯まとめ - NAVER まとめ
はてなブックマークボタン(この記事の上下にも表示されてるB!マーク)は表示するだけでマイクロアドにトラッキングデータを提供しちゃってるぞ許せねえ!という話題です。
そしてこのNAVERまとめも表示しただけでマイクロアドにがんがんデータ送信されちゃってるというこれは皮肉?
広告の仕組み
マイクロアドって会社はユーザの行動追跡データを元に効率よく広告を表示するサービスをやっている。その仕組みはこう:
- パートナーサイトでマイクロアドのjsファイルを読み込んでもらう
- マイクロアドはCookieごとにIDを発行して、jsファイルが読み込まれるたびにそのIDと表示したサイトを関連づける
- これを続けていくと各個人ごとに「にちゃんまとめと日経BPと○○さんのはてダをよく見ている人」とか「○○系のエロサイトと××系のエロサイトを毎日巡回している特殊性癖の人」というふうにWeb閲覧傾向を収集することができる
- マイクロアドで広告を表示するサイトでは、その人のWeb閲覧傾向に沿った広告を選択的に表示できるためクリック率が上がってアフィサイトも広告主も嬉しい
マイクロアドは広告屋さんなので、収集した情報から個人を特定するような使い方は(たとえばはてダの管理画面とかはURLにユーザ名が入ってたりするので技術的には可能だけど)多分していないでしょう。(法律違反が怖いから)
なにがいけないのか
このマイクロアドの仕組み自体が悪いってわけじゃないんです。各大手パートナーサイトはちゃーんと「プライバシーポリシー」っていう誰も読まない文書を公開して、閲覧履歴を広告に使うことをちっちゃく明記しているから合法です。
それでもなんか気持ち悪いという人のためにオプトアウトの方法も目立たないように公開されています。
MicroAdの広告をご覧のお客様へ←ここへ行って「オプトアウト」ボタンをクリックすると収集されなくなるそうです。とりあえず僕はクリックしました。
でもこの「とっくりばー」は?そんなプライバシーポリシーの文書なんてありませんよ?ほとんどのブログにはそんなものないでしょう。
僕がしたことははてなブックマークボタンを設置しただけです。マイクロアドのパートナーサイトになった覚えはありません。
また、はてなブックマークボタンのプライバシーポリシーに同意したのは僕です。実際に行動追跡データを送信されてしまうこのブログの読者ではありません。
しかも以前ははてブボタンを表示しただけでマイクロアドに行動追跡データを送信されるなんてこと、はてブボタンの文書には一言も書いてなかったそうです。そんな機能ついてなかったから。(まあ僕は知らなかったけど!)後出しなのがひどい。
当然、はてブボタン経由でマイクロアドへ行動追跡データが送られて、なにがしかの利益(直接お金でなくても)がマイクロアドからはてなに支払われるんでしょうが、そんなのおかしいよ!だって僕のブログの閲覧履歴を提供してるのになんではてなが儲かるの。いや、このブログのPV数がどうのという話じゃなく。そらまあすんごく少ないわけだけど。
というわけでオプトアウト
といったわけで、ちゃんとこちらのサイトの案内にしたがって、オプトアウト版のはてブボタンを設置しました。マイクロアドへのアクセスが行ってないことも確認しました。
はてなブックマークボタンの作成・設置について
追記
はてなが対応してくれたようです。結局マイクロアドへの送信を全部やめる、と(つまり僕の作業が無駄になりました)。近藤社長名義での平謝りの文章です。はてならしいフランクさです。
ブックマークボタン本来の目的は、「ブックマーク数が分かる」ことと、「簡単にブックマークできる」ことです。このボタンの表示から得た訪問者の行動情報を第三者に提供することは、ボタン本来の目的から考えて間違った情報の使い方でした。
はてなブックマークボタンから収集した行動情報の第三者提供をやめます
それにしてもかさにかかってさらに叩く人の多いこと多いこと。落ちたものをさらに叩くのはマスゴミにかぎったことじゃないようです。

Date:2012/03/12 17:27
あ…ありのまま 今 起こった事を話すぜ!
「PHPでコンストラクタ何回も呼べた」
な… 何を言ってるのか わからねーと思うが おれも何をされたのかわからなかった
新しく入ってきた子に教えてたんですよ。で、
「このコンストラクタってなんのためにあるんですか。普通の関数と何が違うんですか」
と聞かれたんで(なかなか賢い有望な子です)、たぶんいろんな理由でこの仕様が生まれたんだろうけど、僕が思うに一番便利というかこれがないと困るっていうのは、やっぱりコンストラクタ引数を利用してImmutableなオブジェクトを作れるっていうことかな。たとえば、
class MyClass {
private $name;
function __construct($name) {
$this->name = $name;
}
function getName() {
return $this->name;
}
}
こういうクラスを作ると、このクラスは生成-初期化時にname変数が設定された後は二度とnameを変えられないので、Immutable(変更できない)って呼ばれるんだよ。こういうクラスは他のソースコードから取り扱いが簡単になるので設計の複雑さを多少軽減する効果があるんだ。
と、教えていたのです。で、「じゃあ実演してみるね」と軽快に実行コードを作って
$a = new MyClass("Alice");
echo $a->getName(), "\n";
$a->__construct("Bob2");
echo $a->getName(), "\n";
「まさかこんな書き方はできないわけでさ」と言いながらッターン!とF5(実行)キーをタイプしたんです。
は?エラーじゃないの?
頭がどうにかなりそうだった…
おそろしいなPHP!まさかそういうことになってるとはな!PHPには色々驚かされてきたけれど、これもかなりの大ネタだったな!
コンストラクタってただの関数みたい。ただちょっとnewのときに自動で呼ばれるってだけで、あとは他の関数と何も変わらないよ。
っていうのは嘘で、こういう呼び方できるけど、うちの社内では絶対やっちゃダメだからね。絶対だよ!と教えましたとさ。

Date:2012/02/21 12:38
最近はてなブックマークで、ブックマーク数が異常なんじゃないかと思える記事がちらほらとないですか?
なんか明らかに内容が薄いのに1000以上のブクマを集めてて、ホッテントリだからって読みに行ってコメントつけるひとがいて、どんどん増えていく。ブログ全体の記事数みたら・・・いやいやいや記事数10以下って。
(あえて名前は出さない、リンクも貼らない)
これはアカウント大量取得の自動登録とかかと思ってコメント無しのブックマークしてる人をいくつか見てみても、機械っぽいあからさまな感じは受けない。
で、よく見ると、ページの下の方に有料テンプレートの宣伝。
有料テンプレートを買った人向けにあらかじめコツコツと大量取得してたサクラのアカウントでじゃんじゃんブックマーク付けてくれるサービスなんじゃないかと疑うけど証拠も(時間かけて探せば見つかるかもしれないけど)ない。そんな商売…いや、成り立ちそうだよな…
テンプレート屋さんのサイトを見てみたらテンプレートの内部SEOがすごいからそれだけでアクセス数が延びますみたいに書いてあるけど、そんなあほな。今どきの綺麗なHTMLぐらいそこら中にゴロゴロしてるのに、そこだけそんな延びるとか非科学的すぎる。どう考えても何かしてるはず。
というか、はてブを一方的に利用してる?
ためしにlivedoorクリップで検索してみたらクリップ数1とか2とかばっかり。つまり普遍的に良記事だから読まれてるわけじゃなくて、はてブだけの現象。
こういうの、はてなから対策とられたりしてどうなるのか今後目が離せない。

Date:2011/12/12 13:00
お仕事でiPadアプリを作った。画面をいろいろ操作してる間にも裏でスレッドが走ってて定期的にどのファイルをダウンロードするか判定して必要なファイルをダウンロードしたりするやつ。それだけなら別になにも難しくないんだけど、ファイルごと+ファイル群ごと+全体の3種類のプログレス表示とダウンロードが終わったら画面表示をがさっと変更する仕様があったのを甘く見てた。
ダウンロードだけでなくXMLを読み込んでDBに登録したりとかいろいろしてからイベントが上がって画面表示を変更するような作りにしてしまったため、出るわでるわEXC_BAD_ACCESS。
アニメーションして画面遷移したあとイベントリスナを解除してからUIViewControllerをreleaseし終わってるのに、ダウンロードスレッドのほうでイベントループの途中になってしまっているため、zombieオブジェクトに対するメッセージになってしまってEXC_BAD_ACCESSであぼーん。そらそうなるわな。
この程度の設計で間違うとはまだまだだ自分。
反省として、次回こういうものを作る機会があったらこういうつくりにすること、というのを備忘録として書いておこう。
[大方針]
・バックグラウンドスレッドから呼ばれるイベントリスナで画面に関わるAPIを呼ばない。iOSアプリはアニメーションによる遅延実行が多いのでハマる原因になる。
・挙動がカクカクしないよう、負荷を増やさないよう、@synchronizedの箇所を最小限にする、というか、意味的にatomicでなければならないことを表現する以外で@synchronizedを使わない。
[小方針]
・イベントリスナの処理ではModelを変更したり変更フラグをたてたりするだけにする
・画面描画が必要な場面ではNSTimerで0.1秒ごととかの定期実行スレッドを一つ動かしておいて、変更フラグを見て描画範囲を確定して、Modelのデータを取得して表示する。このときModelが変更途中の場合は待つのではなくスルーして次回定期実行時に参照すればよい。
・バックグラウンドスレッドが無駄に増えて行かないように、あらかじめダウンロード用ワーカスレッドを2つとか立ち上げておいて、ダウンロード開始するときはそのスレッドに依頼するようにする
・イベントリスナの処理中でイベントリスナの追加削除を行わない
・SQLiteのコネクションはopenしっぱなしでシングルトンを使い回す
・DBのトランザクション処理だけは@synchronizedで囲む
もう一度結城浩さんのマルチスレッドデザインパターンを読む。

Date:2011/12/05 12:56
タグの閉じ忘れをチェックするブックマークレットが便利。 - バニデザノート
タグの閉じ忘れチェックブックマークレットのはてブ数が増えていっているようで、便利なものつくっとくと放っておいても誰かが見つけるらしいという知見が得られています。
どうもご紹介ありがとうございます。
ブラウザのバージョンが上がっていくなかでどこで使えなくなるかヒヤヒヤしながらも、将来使えなくなっても直す気はあまりないという放置状態ですが、ユーザが多ければソースコードを勝手に変更して公開してくれる人も現れるはずと期待している他人本願。がんばれインターネッツ!
(追記2011/12/9)いまごろ気がついたChrome拡張機能としてリメイクされている、すごいぞインターネッツ。
HTMLタグの閉じ忘れをチェックするChrome拡張機能を作ってみた

Date:2011/10/16 13:50
行ごとクリッカブルにするというのをもう少し改善?してみました。全然知らない人にツッコミいれてすみません。はてブで新着に出てたのでつい。
jQueryでテーブルの行ごとクリックして チェックボックスにチェック出来るよう にするTipsです。ユーザーがデータを 見ながらフォームを送信する際に、分か りやすくしてあげよう、という目的です。 行ごとクリッカブルにする、みたいな感じ。
jQueryでテーブルの行ごとクリックしてチェックボックスにチェックを入れられるようにする - かちびと. net
改善点は以下です。
- 「find()」メソッドと「:checkbox」セレクタ便利
- 「hover(over,out)」メソッド便利
- チェックボックスをクリックしてもちゃんと選択できるよ
- どうせなので選択状態を行全体の色で表現
こういうスクリプトと
$(function() {
$('.data tr').hover(function() {
$(this).addClass('hover_tr');
}, function() {
$(this).removeClass('hover_tr');
}).click(function(evt) {
var $t = $(this);
var chk = $t.find(':checkbox')[0];
if (evt.target != chk) {
chk.checked = !chk.checked;
}
if (chk.checked) {
$t.addClass('checked_tr');
} else {
$t.removeClass('checked_tr');
}
});
});
こういうスタイルシートで実現しています。
.main_txt .data {
border-collapse: collapse;
}
.main_txt .data td {
border:1px solid black;
padding: 4px 10px;
}
.main_txt .data .hover_tr td {
background-color: #f0f0f0;
color: #333;
}
.main_txt .data .checked_tr td {
background-color: #0033aa;
color: white;
border:1px solid white;
}
いじょ!

Date:2011/09/16 16:25
プログラマとしてやっていく(やっていかせる)ことについて、いつも考えてるけど難しいんだよね。
ただ、その中で、ひとつ変わらない大事なことがあります。
プログラマにとって大事なことは「プログラムが組めること」です。
言語を含めて、ツールが使えることが大事というわけではないということです。ライブラリのありかや使い方などを知っていることは大事ではありません。
もちろん、少なくともひとつの言語がちゃんと使えることは大前提です。
プログラマになるための勉強をしている人の前で話をしてきた - きしだのはてな
プログラマとしてやっていくのに大切なことってなんだろう。
逆に、何がないとプログラマとしてやっていけないんだろうと考えてみる。
ていうか、プログラマとしてやっていくってどういう状態を指すことにしようかと戻ってみる。
面倒になって終了…いやそうじゃなくって。
プログラマとしてやっていく、じゃなくて、もうちっとマシなプログラマになるにはどうしたらいいのか。何がないとマシになれないのか。という事を書いてみよう。
やっぱり勉強だよね。それも学ぶ技術が超必要。
学ぶ技術、とは、「
学びたいのです。先生、教えてください。」とするのも本質的なところではそうなんだろうけど、もっと小手先の所でいくと、どこかからパクった技術を再構築して自分の知識体系の中に矛盾なく取り込むことだと思う。
プログラマの仕事は毎日毎日、知らないことやったことないことを調べたり考えたりしてどうにかこうにか解決したりしなかったりパクったり諦めたりの繰り返し。問題はそのパクりでもなんでもいいんだけど、解決を「学び」に直結できるか。
解決=学びにできるなら、解決のスピードが速くなればたくさんの問題を解決できてたくさん学べてもっとマシになる。たくさん知ればよりたくさんの問題を発見できてより深く学べるから知識は雪だるま式に増えていく。
そして、一つの問題を解決する途中で付随する小さな問題たちを面倒くさがらずに一つ一つきちんと解決して知識体系に組み込むことで、雪だるまの成長はもっともっと加速する。
さらにそれをブログやTwitterでアウトプットすることでより加速する可能性もある。(しない場合もある。ソース俺)
以前からずっと、「小さな問題は小さく解決するんだ」って言い続けている。
たとえば大きなアプリを作ってるときに、HTTPS通信でパスワード付きのSOCKSプロキシを通さなきゃいけなくなって、そのやり方は調べなきゃわからないってときに、そのアプリの通信部分をいじってパスワード入力ダイアログ出すように作って全体をビルドするとかサーバーにデプロイするとかして、ログイン画面からたどって2,3クリックしてその場面にたどり着いて、なんていうアホな開発はやめようって言い続けている。
そんなん、小さな1ファイルのコマンドラインツールかなにか、つくるでしょ。それでパスワードなんかソースコードにベタ書きしていろいろパラメータ変えたりして、何度も何度も実行したりして、一番効率よくて一番行儀良い方法を探ってから実際のアプリにコピペするでしょ。それで、あとでその辺の問題が起こったらその小さなコマンドラインツールが問題の切り分けに役立ったりしてハラショーでしょ。
もっと小さな例でいうなら、たとえばPHPの比較演算子がどう動くか調べるとか、
SciTEとかでさくっと動かして調べればそれでいいのに実際のアプリ上で起こってることから類推するとか意味がわからんでしょ。
…(泣)
「もっとプログラミングの勉強してくださいお願い」って言うとき、必ずしも本を買えとかセミナー受けろとかそういうことだけとは限らないんだけどなあ(もちろんそういう体系的に学ぶこともとても良いことなんだけど)。プログラミングの仕事が忙しくて勉強ができないって思っちゃってる人がいたりして、そうじゃないんだけどなあ。それじゃいつまでたっても上手くならなくて簡単なことに時間かかりすぎてずっと忙しいままなんだけどなあ。
自発的に学べない人はやっていけないんだと思う。さらに、経験から学べない人はやってけないんだと思う。
最近年齢とともに学ぶ力が少し減退しているのを感じる。いつまでやっていけるんだろうかね。

Date:2011/09/14 14:15
そりゃそんなの嫌われるだろ。と思ったので。
ワシントン大学の心理学の実験。
実験に参加した者は心理学専攻の学部生たちで、コンピューター・ネットワークを介して他の学生4人と一緒に、あるゲームをするよう求められた。この「他の学生4人」というのは本当は実在せず、コンピューターのプログラムによるものだった。
ゲームでは、参加者1人1人が(実在のプレイヤーも架空のプレイヤーも)、1ラウンドごとにポイントの貯えを与えられる。これらのポイントは、手元に取っておいてもいいし、チームの共有財産として提供しても良い。
チームに差し出したポイントは、額面が2倍になる。参加者はその後、他の4人から供出されたポイントのうち、4分の1までを引き出して個人の貯えに加えることが認められる。ただし、共有財産にポイントを残しておくことで、グループ全体にボーナス点が付く可能性が増すと説明され――ボーナス点の詳細は説明されない――、引き出すポイントを4分の1未満に抑えることが推奨される。ゲームが終了した時点で、参加者たちはそれぞれ、ポイントを実際の商品券に交換できる。
「利他的な人」は嫌われる:実験結果 « WIRED.jp Archives
で、ややこしいからまとめると、
- 被験者には5人でやるゲームって言うけど実は被験者以外の4人はロボ
- ロボのうち一人は妙に自分勝手で自分だけ得しようとする
- 一人は妙にわざわざ損してみんなに得させるような行動をする
さて被験者はどのプレイヤーと次も一緒にゲームしたいか聞いてみた。
自分だけ得しようとするヤツとは当然みんなやりたくないって言う。でもわざわざ損しようとするヤツともやりたくない、と半分以上の人が答えたらしい。
その理由は、「あの人のせいで自分が悪く見える」とか、あの人はルール違反をしているというものだった。利己的でないプレイヤーに、何か裏の目的があると疑う参加者もいた。
「利他的な人」は嫌われる:実験結果 « 2 « WIRED.jp Archives
そりゃそうでしょ。面白いほうの発言「あの人のせいで自分が悪く見える」がとりあげられているけど、ほとんどの人はそういうことじゃなくて「なんか薄気味悪い」と感じたんだろう。行動様式が意味不明だから。自分からわざわざ損しにくるとか、なんか怪しいし、アメリカ人が好きな「フェア」にも合致しない。
また、この実験で、「ボーナス点」というのが実際に加算されていたら、反応は違っただろう。その人のおかげでみんなでどーんと得ができたなら次もその人と一緒にやりたい、と思っただろう。
好かれる「利他的」、もしくは社会や組織が求める「利他的」っていうのは、自分からわざわざ損するだけではなくて、こういう経済ゲームであれば、目先の得をあえて取らないことによりみんなでもっと大きな得をとって自分も得をする、という行動様式であるはず。MMORPGでいえばつまんない壁役回復役をあえて引き受けることでみんなが自由に行動できた結果得られる経験値も多くなる、みたいな(ほんとか?)。
こういう実験結果がでたから「利他的は嫌われる」とか思って引っ込んじゃう人は意気地無し。

Date:2011/09/01 10:49
Objective-Cで任意のクラスに好きなメソッド生やせるってわかってから一気に気持ちが軽くなってCocoaでの開発が嫌じゃなくなってきた。いいよねiPad。いいよねiPhone。
View操作とか文字列操作のメソッド名が単に長いってだけのことにこんなに影響受けてたのかと驚く。考える内容が考えるのに近いスピードで打てない苦痛にこんなに弱いと思わなかった。人間やってみるといろんなことがわかるもんだ。なんかこう、重い足かせ手かせがついてるみたいな気持ちでいっぱいだったんだもの。
Objective-Cで無名カテゴリでprivateなプロパティを実現する方法 | Eudyptes Chrysocomeとかを利用して、retainとかreleaseとか自分でできるだけ書かないんだって決めて、でもそうすると今度はautoreleaseとか書くのが長くてちょっとウザ、となってくる。
self.label = [[[UILabel alloc]init]autorelease];
label.text = @"foobar";
そこでまたオレオレメソッド登場ですよ。(やりすぎ注意)
NSObject_Util.h
@interface NSObject(Util)
//allocしてinitしてautoreleaseして返す
+(id)uNew;
@end
オレオレメソッドは決まったプレフィックスつけてちょっと変な名前にしておこうオレルール。
NSObject_Util.m
#import "NSObject_Util.h"
@implementation NSObject(Util)
//allocしてinitしてautoreleaseして返す
+(id)uNew {
return [[[self alloc]init]autorelease];
}
@end
Objective-Cのselfはクラスとか実装オブジェクトではなくレシーバなので、これでちゃんと使えちゃうのが他の言語とちょっと違って面白い。
self.label = [UILabel uNew];
label.text = @"foobar";
self.button = [UIButton uNew];
self.myobj = [MyClass uNew];