mtでやってたのをWordPressに移植してみる。

ダウンロード：

• 2chtripize ver.1.0.0
  (2013-07-18 404を修正)

インストール方法：

ダウンロードしたzipを解凍し、出てきた2chtripize.phpをWordPressのwp-content/pluginsにコピーし、管理画面からプラグインを有効化してください。

ライセンスとか

なんとなくCC 。 変更改編再配布ご自由に。

参考：

• MTにトリップ機能を
• MTにトリップ機能を for MT.3.33

仕様とか

• コメントの投稿者に半角#が付いていたら以下をトリップキーとしてトリップを生成します。
• 10桁トリップ対応
• 12桁トリップには非対応。
• ◆/★はそれぞれ◇/☆に変換し偽装を禁止
• データベース保存前にトリップを生成しているため管理者に鳥漏れしない
• cookieには生成前のトリップを保存

TODO

• 管理者の固定トリップ
• キャップ機能

制限事項とか

cookieに生成前のトリップを保存しているため、投稿者が管理者承認前のコメントを表示できない

承認前のコメントはCookieの投稿者名とデータベースのauthor_nameのマッチングで表示しているみたい。
なので、このプラグインを利用すると入力した値(=Cookieの値)とデータベースの値(鳥変換済み)がマッチしなくなるため、自分が投稿した承認前のコメントは表示することができない。

迂回策は次

1. Cookieに変換後のトリップを保存する。
   これが一番対応しやすい。
   プラグインの82行目をコメントアウト(行頭に「//」を追加)する。
   この対応をした場合、米入力欄にはトリップがそのまま表示されることになるため、2度目以降のコメントでそのまま入力してしまうと◆が◇に変換されてしまう。
   使い勝手を考えたらイマイチかも。
2. コメントの承認を外す
   スパム避けなんかはCapchaプラグインを併用することで何とか。
3. エントリの表示で再度トリップに変換しその値でデータベースを検索する
   正直面倒(‘A`)
   そのうち実装するかも。

使えるようになったら紹介エントリ書きます。

新人プログラマーにアドバイスを求められた筆者が考えた、「聞くべきでないアドバイス」のリスト。
10) 例外は使うな(by Joel on Software 等)
9) 負にならない値には unsigned int を使え
8) 実世界に対応したクラスを設計せよ
7) チームでコード記法を統一せよ
6) コメントをたくさん書け
5) public フィールドよりアクセサメソッドを使え
4) 一個しかインスタンスができないなら Singleton パターンを使え
3) 入力は寛大に受け付け、出力は厳しくせよ
2) 最初から重箱の隅までプログラムせよ。後でやろう、は実行されない
1) コードを書く前に設計せよ
秋元@サイボウズ研究所プログラマーBlog: 従うべきでないプログラミングのアドバイス10個

あるあるｗｗｗｗｗｗｗｗｗ
ただ8はある程度従って欲しい。
せっかくOOなんだから。

過去の経験上見た従っちゃいけないアドバイス。

OutOfMemoryExceptionが出るならsystem.gc()でいいじゃない。

ちょｗｗｗｗｗｗｗｗｗ1mmも良くないｗｗｗｗｗｗｗｗｗ
それで後からパフォーマンスが縲怩ﾆかﾜﾛｽｗｗｗｗｗｗ

ファイルを読み込んでStringに貯めて0

貯めるなｗｗｗｗｗｗｗｗだからメモリが足りなくなるんだｗｗｗｗｗｗｗｗｗ
つかせめてStringBufferでも使えと。
それで後からパフォーマンスが縲怩ﾆk（ry

HTTPでのサービス作ってるんだからSocketの勉強なんてしなくていい。

m9（^Д^）ｶｴﾚ

ただ、Flashベースのリッチクライアントってユーザビリティ的にはかなりアレなんだよなぁ。残念ながら。
例えばブラウザのスクロールが使えないとか、内包する１コンテンツにブックマークできないとか。
このへんはAjaxにも通じるものがあるからLocationHashを使ったブックマークとかで対応するしかないか。
スクロールはホイールあたりをうまいこと使・・・えるのか？

スクールで学ぶ 20
通信教育で学ぶ 7

（　Д ）　　　　ﾟ ﾟ

俺の習得方法は

1. リファレンスを読む
2. サンプルコードを読む
3. サンプルコードから新しいプログラムを作ってみる

こんなとこやね。
リファレンスを読むのは言語の記述ルールや、制御構文（if,while,for,case ぐらい）の書き方、例外処理の仕方、演算子の種類とルールあたりを得るため。
このへんはかなり言語の独自性が高いんで、素直にリファレンスを読んだ法が早いと思う。（経験上）
サンプルコードは大抵の言語には標準で付いてくるので、そのへんをざっと読み解いてみる。
とはいえ”Hello World”程度じゃ話にならんので、サンプル中でもっとも高度な事をやってそうなコードを読むことにしてる。
そうすることで、言語の大枠の雰囲気あたりは確実につかむことができる。
あとはひたすらプログラムを書くのみ。
今までの経験と凄まじくかけ離れた言語じゃない限り習得まで1週間もあれば何とかなってると思う。
まぁ使いこなすまでにはもうちっとかかるけどね。

つーかスクールとか通信教育って何？
そんな悠長に学べる会社とかあるのか？（たぶん学生だろうけど）
結局プログラム言語なんてどれを使っても本質的には一緒だから、1つの言語が使いこなせてれば他の言語習得なんてそんな時間がかかるとは思えないけどなぁ。

TRIGLAV
すげええええええ（ﾟДﾟ）ええええええええ
Ajax（HTML+CSS+Javascript+XMLHttpRequest)でブラウザ上で動作するRPGができてるうううう。
これすげぇ。マジすげぇ。

基本的な動作原理：
各エレメントにIDを付加。
エレメントのOnClickハンドラをJavascriptオブジェクトに流し込む。
スクリプト内ではエレメントのpositionをabsoluteに設定し、マウスポジションにあわせて座標を更新する。
使用スクリプト：
/scripts/dragDiv.js
見ての通りXP風ページのdrag.jsからのちょい変更程度。
機知のバグ：
ieで、縦横のスクロールがされている状態だとマウスのポジションが正確に取れない。
諸悪の根源はこれ。
if (isNaN(parseInt(window.scrollX))==false) ix +=window.scrollX ;

つまり縦横のスクロール量を取得するのに、mozilla風にwindow.scrollX/scrollYを使ってるのが原因。
んじゃieでどう取るのよってのが分からなくて放置してた。
その辺上手いことやってるのがwemaのスクリプト。
中を見てみるとieとmozilla、Operaでそれぞれ取得方法を変えてるみたい。

function getMouseY(e){
if(window.opera) //o6!)
return e.clientY
else if(document.all && document.getElementById && (document.compatMode=='CSS1Compat')) // e6
return document.documentElement.scrollTop+event.clientY
else if(document.all) //e4,e5,e6!)
return document.body.scrollTop+event.clientY
else if(document.layers||document.getElementById)
return e.pageY //n4,n6,m1!)
}

こらきっついな。
＃つーかいい加減各ブラウザ共通で使えるクライアントスクリプト出てくれないかね。
この辺がイベント毎にチェックされるのもかなりアレなんでOO風に書き出してみると

var coordinateHandler = null ;
function onLoad(e){
if(window.opera) //o6!)
coordinateHandler = new OperaHandler();
else if(document.all && document.getElementById && (document.compatMode=='CSS1Compat')) // e6
coordinateHandler = new Ie6Handler();
else if(document.all) //e4,e5,e6!)
coordinateHandler = new OldIeHandler();
else if(document.layers||document.getElementById)//n4,n6,m1!)
coordinateHandler = new MozillaHandler();
}
function getMouseY(e){
return coordinateHandler.clientY
}

こんなとこか。
つーかこんなもんとっととインターフェース策定して、ハンドラをベンダーから出してくれないかな。一々動作検証すんのが面倒。

しかし最近はCSSがそれなりに使えるブラウザが増えてきて、HTML+CSS＋Javascriptで遊べることが多くなってきた気がする。
MSNSpacesの設定画面なんかその最たるものか。
IEワールド全快で厳しいけど。

1.目的の製品のページに到達するまでの速度
2.ナビゲーションのわかりやすさ
3.サイト内検索
4.製品ページの見易さ

見る基準としては、

欲しい商品の型番は分かっている。
商品の詳細スペックが知りたい。
基本的に検索エンジンは使用しない。

ちょっと特殊なパターンではある。

一概に言えるのは商品の一覧を文字で出しているサイトの少なさ。
リンクと製品名だけが文字で並んでいればページ内検索で一瞬で飛べるのに、一覧がないもしくは文字情報が少なすぎて検索できないってサイトが多い。
これは一般コンシューマー向けのサイトとしては、できるだけ画像を多くして煌びやかに見せることが販売向上に繋がるってのも分からなくないからアレだけど、手間からすればあってもいいページだと思う。
あとは変なカテゴライズされてるが故に使いづらくなってるケースが多い。
たとえばDellのPrecisionワークステーションあたりだと、個人ユースとして十分耐えれるマシンでありながら、製品ページに到達するためには企業ユーザー向けのページから入らなければならない。そんなに個人に売りたくないのかと。
筐体のサイズからカテゴライズされてるのもある意味困る。
IBMのInteliStationみたいにひとつのモデルの中に複数の筐体がラインナップされてるようなものだと、製品番号から筐体を予想できないので、どっちのページを見ればいいのか困ることになる。
全体的にPCのことをほとんど知らないユーザー向けに作ってるような感じがする。
まぁ。間違ってはないんだけどね。
2のナビゲーションについてはほとんどのページが及第点かと。
大体のページがページ上部に
「トップページ＞（カテゴリ）＞製品＞スペック」
みたいなナビゲーションがあるんでそれで移動経路のさかのぼりがやりやすい。
つかこの手法って結構広まってきたのね。いいことだ。
3.については極めて絶望的。
商品の型番から商品の検索ができるようなサイトはSony以外見当たらない。
HPは見つかってもドライバのダウンロードぐらいしかヒットしないのが惜しい。
そのほかについては検索ページすら見当たらない。
どうなのよソレは。
これがあるだけでサイトが何倍も使いやすくなると思うんだがどうか。
4.については好みもあるけど、製品の概要と詳細を分けるってのがトレンドか。
概ね悪くない。
しかしながら詳細を知ろうとするとPDFでしか見れないってのも散見した。
HP、IBMあたりか。
正直言ってこれはいくらなんでもどうかと思う。
製品カタログの元データをそのままPDFにしました見たいなのは体裁は良くても激しく見づらい。
ユーザビリティという観念からすると一連のナビゲーションの中で突然操作方法が変わるというのは極めてよろしくないかと。
つーかWeb上でPDFを公開することにユーザーがどれほどのメリットを受けるのかと。
はっきり言ってこれは邪魔だと思う。
あとありえねぇと思うのが、新製品ラインナップから外れたとたんに製品ページから消してしまうサイト。Dellとか。
そりゃ新品の販売は無くても情報としての需要は高いだろと。
ある製品が欲しくて、そこに付くメモリーの規格とかAGPの有無や速度、PCIベイの空き具合とか調べようとしても、こういうサイトだとそもそもそれができねぇ。ﾅﾒﾝﾅ。
まぁ中古の販売にメーカーはメリットを受けることが無くても消すこたねーだろと。
公式ページがGeocitiesとかにあるとかでもあるまい。
これはかなり萎える。

普段、検索がメインのサイトを作っているとこんなことを考えてるんだよという雑文。
もうちょい使いやすくなってくれるといいんだけどなぁ。

今評価してるのが古式ゆかしきMVCモデルを採用したフレームワークで、J2EEベースっつーかぶっちゃけServlet+JSP+開発ツールな感じのもの。
ぱっと見生産性なんかはそれなりに高そうだし、値段も安くは無いにせよまぁまぁの費用対効果が出せるんじゃないかなって感じのレベル。
悪くは無い。決して悪くは無いんだけど何かが引っかかる。
引っかかるルーツは結局 前述のスレでも言われてるところの

業界標準になりえないようなローカライズしたシステムに乗ることの是非

なわけだ。
フレームワーク自身は生産効率向上であるとか、生産物の品質向上であるとか、再利用性の確保であるとかそんな感じの目的で作られてる。
まぁそれは否定するポイントでもないんだけど、フレームワーク自体は常にColdSpot(変化の少ないポイント)って性質を持ってるがゆえに、時代の変化に対応できるかどうかってのが焦点になってくると。
変化に対応しないでそのまま枯らすならソレはソレとして、時代を追従するなら更に1歩踏み込んで、フレームワーク自身がどれだけ追従性と柔軟性を持ってるかって話になるわけで、それは突き詰めるとソース公開されてないことには何とも判断できん。
（ブラックボックスから類推することもまぁアリだけどそれはおいといて。）
でもソース公開をしてもらおうとすると製品を買うだけじゃなくて会社対会社でアライアンス契約とかって話になって動く金額の桁がもりっとでかくなるわけで。
そうなるといざ中身が腐ってた時に身動きが取れなくなるわけだ。
そう考えると、話がコンフリクトしちゃってにっちもさっちもいかないんで、視点を変えてStrutsであるとかTurbineであるとかみたいなApache.orgのフレームワークとはナニが違ってどれだけ優れてるのかっちゅー話で。
そう考えるとメリットってのは日本語でQA対応してくれるスタッフがいるとか日本語ドキュメントが揃っているとかの話になりつつ。
何だよ結局英語いやーんってだけの話じゃねーかと。
簡単な英語の読み書きすらできないでITエンジニアですかおめでてーな。ってことで一件落着。
・・・するわけもなく。

つーかIT業界で数年も働けば好む好まざるに関わらず英語で書かれたドキュメントを読む機会なんてのは星の数ほどあるはずで、それなりの量を辞書を片手に読んでりゃ自然とそれなりに理解できるようになるはずなんだが。
俺自身もそうやって読めるようになってきたんだし。
と、ふと周りを見回してみると英語のドキュメント読まない、読んでないエンジニアの多いこと多いこと。
最新の動向のチェックはitmediaと@itとインプレスで十分ですか。そうですか。
W3C勧告やらRFCやらは翻訳出るまで待ちますか。そうですか。
うーむ。
この辺のスタンスの違いは何じゃらほい と考えをめぐらせてみると、フレームワークって枠組みの中でぬくぬくと育ってそこから1歩も出たことないってのがあるんかなと。
ある程度優秀なフレームワークの上で育った生粋のエンジニア達は結局そのフレームワークだけが自分の技術的基盤になっちゃってるから、その外側の動向にもその基盤になってる技術にも目が行かないと。
んでフレームワークが時代に取り残されたときに初めて自分の立ってた足場が如何に脆いものだったかを知る。
で、他のフレームワークに移っておんなじ歴史を繰り返すと。
ぬう。
んで原題のフレームワークのジレンマで、

フレームワークが優秀であればあるほど、それのみを技術基盤とするエンジニアのスキルは低くなる

ということなのかと。

ウチの会社は8年ぐらい前から自社製の開発フレームワークを持ってて、それ以降に入社したエンジニアのほとんどがこれを基盤に育ってきてた。
んで、ここ1-2年ぐらいでフレームワーク自身に限界が来てて事実上発展しなくなった。
そんな時にまわりを見回してみると酷いエンジニアの量がハンパじゃねぇ。

自分で確保したメモリの後始末もできてねぇ。
（余計なとこからガベージコレクションとか聞いてきて妄信してる。つかお前が使ってる言語にGCはついてねぇよ）
簡単な論理演算もできねぇ。
( （A or B) and not( A and B)って何だ。(A xor B) じゃだめなんか）
とりあえず全部メモリに溜め込んでスピードアップですか。
（メモリ使用量100Mって何だ。）

そうなったときに目先優先で使うフレームワークだけ変えてスタンスシフトを図ったところと、長期的なビジョンから思い切ってパラダイムシフトを図ったところにわかれて、前者がそろそろ限界に達してきてる。
そこで、ってわけでもないんだけど今の新しいフレームワークの評価って話が出てきてるわけで。

さてさて、困った。
1エンジニアとしての俺から見ると、短期的な効率は棄てて今こそ（遅すぎるぐらいだけど）パラダイムシフトをせにゃならんでしょと思いつつ、マネージャー視点から見たところの俺は現状それほど体力の残ってるわけでもない会社の状態で短期的な効率を棄てることは会社自体にリスクを背負わせることになるんちゃうかと。
でもそれは同時に、今パラダイムシフトをしていないリスクを先延ばしにするだけなんちゃうんかと。
んじゃ折衷案で、プロジェクトごとにフレームワークを切り替えつつ緩やかにパラダイムシフトを図るのはどうよってなりつつ、でもそれは毎回新しいフレームワークの評価をしつつそれを開発者が使える状況にせにゃならんのかって訳で正直ご免こうむりたい。

さぁ。どうやって報告書書いたもんかな。
あー。めんどくせぇ。
なんで人のケツ拭くのにこんな苦労してんだかな。