My Way Archives

巷ではPS3ハックが賑わってるみたいなので
自分もやってみた。

ストロベリーリナックスっていうお店で扱ってるUSBマイコンボードAT90USB162。
買うとUSB端子、セラミックコンデンサ、ジャンパーピンだけがバラになってて
それらを回路図の通りにハンダで取り付ければ完成。
完成品より安く済むし、ハンダ取り付けってトコロが少し面白かったので購入。
完成したらWindowsで認識させて、
マイコンのチップにhexファイルを書き込んで完了。
LEDはこのキットには無いのですが、無くても困らないのでスルー。
後はPS3に取り付けて電源オン→イジェクトボタンで動作確認。
っていうか、このサイト見たとおりにやっただけ
　　　　　　　　　　　　　　　→MobileHackerz再起動日記(blog)
PS3起動してXMBでInstall Package Filesが出てればPS3のハック完了。

背景はPSPと統一してるので気にしないで下さい。
後はUSBメモリに入れた署名無しソフトウェアをインストールすれば
何かPS3で色々遊べるらしい。
PS3HDDに手持ちのPS3ゲームをインストールしたり
そのインストールしたゲームを起動したりとか
PS3にFTPサーバー建ててファイル転送も可能に。
ウチもSSの通り、FTPd入れたり、バックアップマネージャー入れたけど
手持ちのMGS4はバックアップマネージャーじゃ
上手く動かないらしいので入れた意味が無かった。
仕方が無いのでFTPd立ち上げてFFFTPでPS3のファイル内容参照して
「おぉーっ」て思ったり
SNESエミュ起動してツクール2立ち上げて「音割れひでぇｗｗ」って思ったりしてた。
しかもあくまでPS3上で動いてるので画面サイズはテレビいっぱいではないので
SFCでやるより画面が小さくなる罠。
PSPやWiiと同様、導入だけしたら満足して終了って事になった。
自作マシンも組みあがってOS入れると満足する私。
DIO様は過程や方法などどうでもよいと言ってたけど
私は結果や方法などどうでもいいらしい。過程が楽しければ。

blog記事に対してコメントするとエラーが出たり
ウチ側の問題でblog再構築する際にエラーが出るのが
大抵blogpetが自動投稿した記事になってるので
とりあえずblogpetからの自動投稿をオフにする事に。
カテゴリを振ったblogpet記事はエラーが出ないので
内部的な問題なのかもしれない。
とはいえ、MySQLに変える前はカテゴリ振らなくてもエラーなんぞでてないので
やっぱりMySQLが問題なのかもしれない。
カテゴリ管理や、再構築無しでカテゴリ振り分けやらがもっと簡単に出来て
それらの処理も早ければいいんだけど
そこまでくるとMT使わないのが最善って事になってしまう。
いやまぁ、blog記事が全て移行できてもっと簡単なものがあればいいんだけど
そんなのあるならとっくに話題になってるわなぁ･･･。
因みにどんなに便利でも記事が他人に管理されるレンタルサービスは絶対使わない。
突き詰めれば自宅サーバーでもパケットレベルではISPに管理されてるけど
生データそのものは自宅のHDDに入ってるわけだから別問題。

拍手の文字化け問題。
前回9月1日のエントリーで解決したと思っていたら
新着拍手だけが何故か文字化けしたり
そもそも作成されるxmlファイルは文字化けしたままだったので
そこを何とかしようとした。
で、前回みたいに書き込み前にUTF-8にしたらいいだろうと思っていたら
xmlファイルではそれが通用しなかった･･･。
細かい仕様がよく分かっていないので、
ファイル出力前の変数をそのままエンコする事が出来ないらしい。
多分変数の型とかクラスの問題だと思うけど･･･。
そしたらふと気付いたのが、ページタイトルが文字化けするんなら
ページタイトル取得の時点でエンコすれば良いと。
実際ページタイトルを取得しているのはページ側に貼ってあるjsファイルなので
jsファイルのタイトル取得部分に手を加えようとしたら
JavaScriptでエンコするのは手間がかかるらしいので断念。
っていうか、そもそもここでエンコしてしまったら
他の、この間直した現在文字化けしてない詳細ログ側が
UTF-8をUTF-8にエンコしようとしてしまうので
そこでまた問題が出そうだったからjsファイル側でやるのは宜しくないと判断。
というわけで、結果的にphp側でjsファイルから取得した
ページタイトルの格納されてる変数だけをピンポイントでエンコする事にして解決。
そもそも、この部分がsjisだから全てのファイルのデフォルトが
sjisになってたんじゃないだろうか･･･。

何があったか分からんけど
何も弄ってないのにMTがエラー出すようになった。
具体的にはページの再構築が出来なくなった。
MySQLにしてからコメント、再構築の処理速度改善以外いい事が何一つ無い。

blogpetカテゴリを作ったはいいものの
blogpetの自動投稿はカテゴリ指定が出来ないので困る。
あとコメントが重いのは大体原因が分かった。
単純にエントリー数があまりに多い為。
コメントを投稿すると、左のサイドバーの最新コメント一覧の中に並びますが
コメントが投稿される度にここを更新しなきゃいけないので
エントリー数が多ければ多いほど、更新しなきゃいけないファイルが増えます。
だからエントリー数が多いから重い。
そんだけの事。
phpなんだからコメント投稿に関しては
コメント一覧のみ動的に更新してくれればいいんだけど
その辺はやり方がわかりません。
っていうかMTの仕様で出来るのかもわかりません。
実現できればコメント投稿時に更新するのは
コメントが投稿された該当エントリーと、
コメント一覧の動的phpテンプレートだけで済むので
何と2つのファイル更新だけで済むのである。
うは･･･夢がひろがりんぐ･･･(‘A`)
出来れば苦労しねーよ･･･。
因みに全然どうでもいいんだけど
MT4にしてから使えなくなってた㌧とか㌧とか㌧とか⑨とかが
UTF-8にしたお陰で使えるようになりました。
何で最初に気がつかなかったんだろう･･･。

とりあえずカテゴリの中でエントリーが少ないカテゴリは整理してみた。
C77オフレポとか物凄く少ないハズなのに
何故か30近くエントリーがあったり、ノビ漫画も20件越えてたので
これらは厳密にカテゴリ振り直しを行って、現在は正常なエントリー数になってます。
他にもイラストカテゴリが500件越えてたりとあまりにおかしかったけど
エントリー数が多すぎて半分くらいしか整頓されていません。
雑記とPC関連、そしてイラストカテゴリの3つがくっついてるエントリーもあって
これら3つのカテゴリの件数が多い為にエントリーを区別するのが困難だし
本文見ながらやるわけにもいかないので（管理画面の使い勝手がクソな為）
これらはしばし放置とします。
エントリーが見れないわけじゃないしね。
ただ、最低でも管理画面のエントリー一覧で
「カテゴリが付けられていないエントリー」
というフィルタを何故用意してないのか疑問。
現在、チェックをつけたエントリーに
一括でカテゴリを振るプラグインを使っていますが
こいつは一括でカテゴリ振れるけど、外す場合は
カテゴリ全部外すという選択肢しかなく
一度外してからエントリー一覧の中で
カテゴリがないエントリーをいちいち探さなければならず
さっきチェックつけた記事をまた200件の中から探すのは非常に非効率なので
カテゴリが無いエントリーを表示するフィルタか
○○のカテゴリを外すといったプラグインの機能が欲しくて仕方が無い。
っていうか、そもそもインポートしたら
勝手に付けても無いカテゴリがくっつくMTのクソ仕様が一番問題なんだけどさ･･･。
因みにえいぶら㌧の絵板のphp文字化けは全て解消しました。
phpだけじゃなく、既に作られているhtmlやlogファイルも
UTF-8にしなきゃいけなかったのに最初気付かず、テスト投稿して
全部文字化けして事前に取ったバックアップから書き戻したのは内緒だ。
その後更にテスト投稿して出来たファイルもUTF-8になったから
多分絵を投稿しても大丈夫だと思う。

この間データベースを変えたのは記事にしましたが
ふとblogを見返すと色々おかしい事になってるのに気付いた。
まずOld Entryが全部文字化けしてる件。
これはphpがシフトJISからUTF-8に変わったからなので再構築して解決。
その他にもOld Entryにスパムコメントが溜まっていたので
コメントそのものを禁止する事に。
どうせ古い記事はコメントされても私が見ないからね。
あとは現行blogの方でカテゴリが増殖しているのに気付いたが
そもそもなんで同じカテゴリを選択したというフラグが立つのかが分からない。
例えば「雑記」というカテゴリつけたのに、更に「雑記」というカテゴリが何故か付与され
そのエントリーだけ開くと
2010年9月6日 16：00　雑記　｜　雑記
といった表示になっている。
MTにはメインカテゴリとサブカテゴリって概念はあるので
その記事に対してメインでつけたカテゴリと、サブでつけたカテゴリを
区別する事が出来るのですが
同じカテゴリがメインとサブになってるのはどう見てもおかしいだろ。
データベースをインポートした時点からおかしかったのかも分からないけど
MTの管理画面の仕様では1つずつ記事を開いては
全部のカテゴリを一旦外してから、再度正しいカテゴリを付け直す
といった手順が必要になり、1つあたりにかかる時間が1分前後なので
1000件全部見直した上で付け直しとなると時間がいくらあっても足らないので
面倒くせぇからこのままにします。
一旦カテゴリを外してしまうと、
この記事はどのカテゴリに入れるべきなのかという判断は
タイトルで判断するか、1つずつ開いて本文で判断するかを決めなければならず
非常に非効率だからです。
タイトルだけで判断できるなら一覧表示すればまとめて管理できるのだけれど
わたしゃ元々エントリータイトルはまともなものをつけないので分からんのです。
あと、この1000件の記事の中で何故か改行が死んでたり
レイアウト崩れてるエントリーもあるので、そいつらはどうにかする予定。

気付けばコレピクのサービスが遂に終わっていたので
サイドバーをちょいと整理。
ココロさんもぶっちゃけblogに連動していない
ただの広告バナーみたいなもんになったので外してみた。
そいやFFXIVのオープンβが始まったらしいので
落としてきたらアップデートが終わらない不具合に遭遇した。
いいですね、ROβ初期の頃の匂いがします。
出来ないならできないでそれで別にいいんですが。
どうせ本腰入れてやらないだろうし。

ネトゲ依存になると、話題が全部
そのネトゲの話になるっていうのはよくあるし
話題を変えようとしても必ずその話題にされてしまうっていう。
だからネトゲ依存症なんだけど
私も最近は何を話そうとしても仕事の話しか出ない。
これはある意味仕事依存症なんじゃないだろうか。
と思ったけど、仕事が忙しければそれだけ他の事が出来ないんだから
話題が仕事しか出ないのは当然だよなとも思った。
元々興味がある事は気が向けばすぐ知識にしたい人なのに
ここまでボキャブラリーが落ちてくるとは思わなかった。
現状打破＝人材確保　なのでどうにも解決できないのがもどかしいなぁ･･･。

今回の文字コードの問題でまた少し知識が増えたので
実害はほとんど無いけど以前から度々文字化けしまくっていた
拍手のログ画面をどうにかする事にしました。
拍手自体はまったく問題なく使えるので
利用者には全然実害無いのですが
管理側としては拍手を貰った該当の記事タイトルは文字化けするし
コメントも一部文字化けするので憶測で参照したりしてたので
あんまり困るものでもないけれど、折角文字コード問題やらの解決方法が判ったので
修正して見た次第。
ウチで使っている拍手はレンタルサービスではなく
phpで作られたgj（グッジョブ）というプログラムで
設置と設定だけすればあとは勝手に各記事ごとに拍手ボタンが追加されて
拍手ボタンを押せば記事ごとにログを作成し
どの記事に対してボタンが押されたか、コメントが入ったか
何回押されたかを全部単独で集計してくれるので
限りなくレンタルサービス並の機能を持っているので便利です。
ですが、これ何故か
作成されたログが取得した記事タイトルが時々文字化けします。
ウチの環境が悪いのかgjの問題なのか判りかねてましたが
文字化けと言えば文字コードなので、文字コードも調べたけれど
作者ページではgjはUTF-8で作られてるというだけでそれ以外の情報は無し。
でもログを調べるとShift_JIS。何でログだけsjisなのか。
ただまぁそれでも動いていたので問題は無いのですが･･･。
で、今回blog全部をUTF-8にしたのでphpプログラムは
無条件でUTF-8でエンコされるようになってしまったので
拍手のログを見るページも全部UTF-8になってしまい
ログも全部文字化けしてしまったので不便になってしまいました。
このページだけ従来のShift_JISで表示するようにすればいいのですが
折角なら全部UTF-8になるように改造しようかと。
プログラムソースが（横に）長いので追記に↓

調子こいてすいませんでした。
あんだけMTクソとか言っておいて
実は自分の設定がミスってました･･･。
コメントのエラー、確かに設定ミスではありましたが
現状シフトJISの状態で直すのは無理でした。
その原因は結局特定できず
全てをMySQLにした直後と同様にUTF-8に設定変更。
これだとトップページが文字化けします。
METAタグにも間違いなくUTF-8が入ってるし
一部のブラウザでMETAタグを無視するっていう対策の為に
HEADタグのすぐ下にMETAタグ置いたりしてるので
IEでも問題が出ないようにしてあります。
っていうかChromeでも文字化けしてるのでIEだけの問題じゃなかった。
で、ふとトップページをダウンロードしてhtml保存してみる。
サイドバー等、他のレンタルサービスガジェットの問題もあるかもしれないので
ローカル保存すればそれらのアクセスを遮断できるという目的で表示。
うむ、ガジェットは表示された挙句に文字化けも起こらない。
つまり、htmlだといいのにネット上のphpはダメ。
そこでピンときてphp側のphp.iniを覗いてみる･･･。
default_charset = “Shift_JIS”
てめええかあああああああああああああああ！！！！！
はい、phpファイルは強制的にシフトJISを使う設定になってました。
UTF-8にしてApache再起動で
普通にIEでもデフォルトでUTF-8エンコードするように。
そして文字化けやら文字コードが正常になったので
コメント投稿も問題なく出来るように。
コメント欄に何も入れてなくてもエラーが出てた所から見ると
UTF-8とシフトJISの文字化けでhtmlソースそのものがどっかでバグってしまい
それでコメント投稿時のcgiかjsファイルか何かが正常に呼び出されなかったか
それらの呼び出し時に渡す引数か何かもバグってたのかもしれない。
というわけでコメント欄は復活しましたが
コメント設定はMTのバージョンが3の頃から変えてなかったので
認証サービスは無かったのですが
MT4からはデフォルトで認証があったりするので
今回、コメント許可→禁止→許可にした際に
MT4仕様のコメントになってしまった為に、コメントするにはなんたらとか
サインインしてくださいとかいった表示か出るかも。
まぁなんにせよ半年くらい放置するかもと書いたのに2時間ほどで解決。
相変わらず思い切り回り道してから解答に辿り着くのが私。
そしてこれだけ苦労したのに
肝心のコメント投稿時間はSQLiteと同じくらい重いまま。
これはもうMT4の仕様なんだろうか･･･やっぱりMTはクソだ。

MySQLに変更してから
やっぱり以前と同様にコメントが投稿できない問題に再来。
だけど今回またSQLiteに戻しては意味が無いので
根本的な解決策が見つかるまでコメントが出来ないようになりました。
直接そのエントリーに対してコメント残す場合は拍手にお願いいたします。
コメント投稿時に出るエラーメッセージをぐぐったら
出てくるのはファイル送信時に発生するメッセージと同様。
つまり、そっちのファイル送信時の解決策しか出てないのである。
そんなのは我々が二千年前に通過した所なので関係ないのだが
肝心のこっちの問題に関してはまったく情報が無い。
考えられる原因としてはblog記事が全部シフトJISに対して
MySQLのデータベースはUTF-8をシフトJISに変えたとしても
MTそのものがUTF-8で作られてるからどっかで怒られてる感じ。
だけどこのblogをUTF-8にするとIEでは確実に文字化けする。
ブラウザのエンコードをUTF-8にすればいいんだが
ウチを見にくる度にエンコード設定でUTF-8にするのは面倒だろう･･･。
相変わらずMETAタグでUTF-8を指定した所でブラウザは無視しやがるので
METAタグに頼るわけにはいかないから
ウチを見に来て普通に表示する分にはシフトJISが一番都合がいいわけである。
どのブラウザでもシフトJISなら確実にエンコードミスも無く表示されるし。
相変わらずブログの説明部分は文字化けしたままだけど
こっちもMySQLのデータベースのテーブルが
作成した当時はUTF-8だから後でMySQL自体をシフトJISに変えても
データベースのテーブルはUTF-8のままだからなんだろう･･･。
これは変え方が分からない。
色々クソ面倒なMTよりWordPressの方がいいと聞くけど
今更cgi設置型blogシステムを
また新たに設置の仕方やカスタマイズ覚える気になれん･･･。
多分コメントの問題、半年くらい放置しそう。
だってまったくお手上げだもん。
写真うｐテスト。もちろんエラーは出ない。

東京帰り途中のSAで食べたメロンパン。
TVの帰れまなんたらで出てきたやつらしいけど
これが本当のメロンパンって感じだった。
だって中に夕張メロンクリーム入ってるもん。
ただ、どう見ても食いかけなのがいただけない。歯型ついてるし。

ずーーーっと昔にこのblogを始めた頃
システムが重くなったらSQLのデータベースソフトを変えろとあったので
MySQLに変えたところ
blogは投稿出来てもコメントがまったく出来ないという不具合に遭遇して
結局SQLiteに変えたわけだが
SQLiteは件数が多くなると全てを重くするという変な特性があって
ウチの過去ログOld Entryは400～500件だったのに対して
こちら本家MyWayは既に900件を越えているので
最近は非常に投稿も遅ければコメント投稿すら30秒以上かかる始末。
確かにSQLiteは件数が少なければMySQL＜SQLiteなんだけど
件数が多くなればなるほど重さが増していき
最終的にはMySQL＞SQLiteになるというわけである。
ウチのblogシステムMovable Typeも4以降は元々重かったわけですが
最近はコメント投稿が重過ぎるというのは閲覧者側にも負担なので
MySQLに変えようと思った次第。
ただ、1日半くらいかかるほど手順が面倒で、
更に間違えるとやり直しという凄まじい仕様。
っていうか、ヘタしたら全てがなくなる危険も孕んでいるという不便この上ない。
既存のデータベースはあるんだから
ささっと別のデータベースに移行できればいいのに･･･。
と各ソフトの垣根を越えた無茶な事思ったけれど
そもそもデータベースが増えただけで重くなるという
このMTそのもののクソ仕様が問題だと思う。
何か復旧作業に疲れ果てたので備忘録は後日。
･･･それよりもこのエントリーすら正常な文字コードで投稿されるかも不安だ。

デスクトップの壁紙を久し振りに全部更新。

ネコピヨ一色に。
2枚のうち必ずツインテが一人いるのは何かの陰謀だろうか。
といってもこの間までは2人ともツインテだったが。
あずにゃん + 初音ミク
あずにゃん + つくもたん
初音ミク + つくもたん
ツインテが良くて何が悪い！

ふと気付いたら。

目がかさなっとる･･･。
うん、そんだけ。

いつも通りにくそ忙しい配達に出発
↓
車自走不能
↓
レッカー移動
↓
同僚の車に荷物移し変えて再出発
↓
他の同僚とも合流して残ったお店を分散
↓
何とか終了
車の不具合の前兆を既に2ヶ月も前に上に報告していたにも関わらず
まったく修理する事無く放置させた結果。
もしこれが高速移動中に自走不能になってたら
命の危険もあったのに、どんだけ腐ってるんだこの会社。
あと営業所が自走不能になった場所から2kmくらいの近所にあったのに
40kmも離れた場所の会社にレッカー依頼した三菱もおかしい。
自社にレッカーがなかったとしてももっと近所にレッカー会社あるだろ･･･。

ご立腹。半そでのせいで中途半端に日焼けした。