岡崎図書館事件、もう一つの真相（フィクション） - hatenablog.utashiro.com
先週末、情報ネットワーク法学会とデジタルフォレンジック研究会共催の「技術屋と法律屋の座談会」というイベントに参加してきました。パネルディスカッションの中で、これからの利用者が考えるべきことというようなお題で、次のような意味の意見を表明させて頂いた。 利用者として、自動化がどこまで許されるかについては慎重に考える必要がある。自分では当たり前だと思っても、他の利用者からすると何かずるをしているように見られる可能性もある。電車の席に座ろうとしたら、若者が後ろから走ってきて座ってしまったというような印象を受ける人がいるかもしれないことにも配慮すべきだ。 この考えをもう少し進めると、岡崎図書館で起きた事件にもう一つのシナリオが見えてくる。それは図書館関係者は、初期段階からクローリングの意図を知っていたというものだ。 最初は原因不明のトラブルだったのかもしれない。図書館が運用業者に問い合わせてログ情報
世界でいちばんひどい生放送サイトをつくったらわりと流行った件 - はてなポイント３万を使い切るまで死なない日記
そろそろ話しても害はないと思うので昔話をしてみる。 ２年前ぐらいにCGMベースの生放送サイトをつくったときの話だ。 すでに生放送のシステムは１年前に運用開始していて、いろいろな番組をつくって配信していたのだが、自前で番組までつくるモデル（公式生放送）ではスケールして成立するビジネスモデルをつくるのが難しい。だから、もともとユーザが自分で生放送ができるサイトで勝負するというのが当初からの戦略で、１年間やっていた公式生放送は、成功できるユーザ生放送システムとはどう実装すればいいのかを探るためのプロトタイプという意味合いが強かった。 年末を目標としてサービスを立ち上げるという目標でユーザ生放送企画開発チームが発足したのは２年前の夏前ぐらいだ。開発期間が半年ぐらいしかなかったが、すでに公式生放送のシステムは１年ぐらい運用していてベースとなる技術は蓄積されていたのでそれほど不可能な目標ではなかった。
にひりずむ::しんぷる - Git ライクなコマンドライン引数を処理できる Getopt::Compact::WithCmd を書いた
近いうちに水性ペンを買います。（挨拶） コマンドライン引数を処理するモジュールっていっぱいありますね！ありすぎてどれがいいかよくわからないし、「まぁぶっちゃけ Getopt::Long さえあれば大体いいよね！コアだし！」って感じですが、まぁなんか書いた。 xaicron's p5-Getopt-Compact-WithCmd at master - GitHub App::Cmdとかありますが、あれはモジュール化しなきゃいけなくて、大変めんどうです。*1 俺は一枚のスクリプトに書きたいんだ！！ サブコマンド前提 usage は自動生成 default や required の指定が可能 依存が少ない（かも）*2 という感じです。最初は、Getopt::Compactを継承して書いてたんですが、途中からなんかあびゃーってなったのでやめました。使い方は大体一緒ですが。 Getopt::Com
Wikipedia が記事の履歴をどのように DB に格納してるか調べてみた - てっく煮ブログ
Wikipedia は過去の編集履歴もサイト上から確認できるようになっているのだが、どのようなデータ構造で情報を保存しているのか気になって調べてみた。MediaWiki を見ればいいWikipedia のソースコードは MediaWiki として公開されているので、これのソースコードを見たり、試しに動かしたりして把握していった。MediaWiki は PHP で開発されている。今回は調査時点での最新バージョン 1.16.0 を利用して調査した。と思ったら MediaWiki に DB 構造が書いてある記事のデータやユーザー情報は全て DB(PostgreSQL or MySQL or SQLite) に保存されるようだ。手っ取り早く SQLite を使ってローカル環境で動かしてみて DB を覗いてみた。DB を眺めつつ、いろいろ調べてたら MediaWiki のサイト上にテーブル構造を示し
Kazuho@Cybozu Labs: String::Filter っていうモジュール書いた - 続: (Twitter の XSS 脆弱性に関連して) 構造化テキストの正しいエスケープ手法について
先のエントリ「(Twitter の XSS 脆弱性に関連して) 構造化テキストの正しいエスケープ手法について」の続き。 弾さんが「404 Blog Not Found:DHTML - 構造化テキストは構造化するのがやっぱ正しい」で示されているような DOM ベースの操作を行えば、原理的に XSS 脆弱性を防ぐことができます。ただ、クライアントサイド JavaScript によるレンダリングはウェブの構造を破壊するという点で筋が悪い（テーブルと FONT タグを利用したページレイアウトが批判されていた頃を覚えていらっしゃいますでしょうか。JavaScript によるレンダリングはウェブのリンク構造も破壊するので一層たちが悪いというのが自分の考え）ですし、サーバサイドでの DOM 操作は重たいので、できれば避けたいところです。 構造化テキストの HTML への変換は、よほど複雑な記法でない限り
Linux でシステムの起動時に 1 度だけ処理を実行する。 - D.
システムの起動時に一度だけ実行する処理は、普通は /etc/rc.local に書くわけだが 、1 ファイルにすべてを書いてしまうと管理が煩雑になったりする。まとまった処理ごとにファイルを分けておいたほうが管理が楽だ。 そこで /etc/rc.local の内容を以下の通りにする。 #!/bin/sh if [ -d /etc/rc.local.d ]; then for i in /etc/rc.local.d/*; do if [ -r $i ]; then . $i fi done unset i fi exit 0 /etc/rc.local.d というディレクトリを用意する。ここにシェルスクリプトの書かれたテキストファイルを入れておくと上のスクリプトによってすべて実行されることになる。ファイル名は何でも良い。 イー・モバイル端末が本体に接続されていれば接続する例 (ネットブック等
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
