ウェブサイトのスクリーンショット・スナップショットで皆さんどうやって撮影されてるでしょうか？
まあ手軽なのはgazoとかで配布してるスナップショット用ソフトインストールでもしてブラウザの見えてる部分を撮影してるかもしれません。
画面のスナップショットだけではウェブサイトページ全景、スクロールしたもっと下のほうまで撮影ができなくて、加工切抜きとかはこっちのフォトレタッチソフトでするんで「ウェブサイトページの全体を撮影したスクリーンショット」だけくれるようなものないかなー？とか思ってました。
んで、あーfirefoxならなんかアドオンとかあるかなーとか思って検索しましたらありました。

firefox本体に付いてましたｗ。何も導入する必要はありません。（ver36.0.1で確認）

「ツール」–「Web開発」–「開発ツール表示」とし、開発ツールを表示させます。
開発ツール触ったことない人はなんだかHTML出てきてドキっとするかもしれませんが心の問題は各自処理していただきたい。

歯車マークの「開発ツールのオプション」–「ページ全体のスクリーンショットを撮影します」にチェックを入れるとカメラマークが出てきました。
これでOK。これでおしまい。簡単でしょう？あとは利用するだけ。

1. ウェブページ表示
2. 開発ツール表示
3. カメラボタン押下
4. ダウンロードフォルダに撮影された画像が作成される。

あとはその撮影された画像を切り抜くなり、貼り付けるなり、ぼかすなり、モザイクかけるなり「お好きにすればいいじゃない？ねえそうでしょう爺？」「はっ、まったくその通りでございますお嬢様」という事です

まぁ撮影時に「撮影完了しました！」とかダイアログ出るわけでもなくホゲー・・・と何事もなく撮影できたのかできなかったのかわからんというちょっとしたワガママお嬢様お茶目仕様です。けど、やるべき仕事はきちんとやっていて、「あーやっぱりお嬢様はきちんとお勉強なさっていて成績はトップクラスなんだなぁ」というところです。
動く広告にタイミング合わせてボタン押してもきちんとそのカメラボタン押したときのスナップショットだったので狙った瞬間の画像を得ることができました。

ウェブ開発ツールになぜか力を入れてくださってるmozillafirefoxさんですけど、これはめちゃくちゃ便利すぎるわ
最初からチェックボックス入れておいてほしいぐらいの機能。

いつも怪しげな情報を載せてるこのブログですが
リビジョンの存在も気にせず書きまくってたら１記事１２リビジョンとか。
あーこれはまずいなとリビジョンの消し方を探っていたのですが、通常使えるBettar Delete Revisionとかいうリビジョンバッサリやっちゃうプラグインが、SQLiteDBでワードプレス運用してる場合使えないんだと。

だもんでさらに手動で削除しようかとおもい検索。

DELETE FROM wp_posts WHERE post_status = 'inherit' ;

inheritステータスでwp_postsに保存されてるからそれ削除しな、ということだったので削除。
ついでにどうせ消したところ容量に加算されてるだろうから圧縮かましてしたら６００Ｋbyte→１．５Ｍbyte

え・・・なんで？
わからん。まぁＤＢもどして普通に使えてるからまあいいか。。。ホントニ？・・・

追記：
なんかやっぱだめそうだった。特にpost_typeがattachmentのやつけしちゃまずいかんじ。
画像がアップロードはされてるがメディアにでてこない。ＤＢもどしたー
select * FROM wp_posts WHERE ((post_status='inherit') and not(post_type='attachment'))
これで出てくるやつは消していいのかなぁ・・・よーわからん

追記２：
DELETE FROM wp_posts WHERE post_type = 'revision' ;
これでいいとの記述もあったし、自分のＤＢみても消しても問題なさそうではある。確認はしてない

追記３：

• wp_term_relationships
• wp_postmeta

テーブルも関係あるらしい。こんなＳＱＬをネットで見つけた
DELETE a,b,c FROM wp_posts a
LEFT JOIN wp_term_relationships b ON (a.ID = b.object_id)
LEFT JOIN wp_postmeta c ON (a.ID = c.post_id)
WHERE a.post_type = 'revision'

あとSQLite Integrationのプラグイン互換性チェック＆改造方法にこんなコードもあった
$sql = "SELECT ID FROM $wpdb->posts WHERE post_type = 'revision'";
$col_id = $wpdb->get_col($sql);
$id_to_delete = implode(',', $col_id);
$queries[] = "DELETE * FROM $wpdb->posts WHERE ID IN ($id_to_delete)";
$queries[] = "DELETE * FROM $wpdb->term_relatiionships WHERE object_id IN ($id_to_delete)";
$queries[] = "DELETE * FROM $wpdb->postmeta WHERE post_id IN ($id_to_delete)";
foreach ($queries as $query) {
$wpdb->query($query);
}
ワードプレスの中身しらん初心者だがやりたいことはわかる。

wp_postsのpost_type=’revision’のIDを記憶しておいて、これらのテーブルの同IDのレコードも消すのがいいらしいがauto-draftが消えないとか色々問題もあるのかなぁ
せっかくリビジョン考えた仕組みになってるのになんで削除機能をワードプレス本体が持ってないのか謎だなぁ。
画像とかのリレーションもデータベースのリレー切れたら無いも同然だし。
テーマいじる管理画面よりもそういうののほうが大事な気がするんだけど。まあ愚痴終了。

Fix mobile usability issues found on　http://[登録自サイト]
みたいなメールが来てた。
まーなんだかお節介でもありやさしくもある母の愛のようなメール。。
なんかいくつか問題あるようだから時間がある時に対応しよう
正直モバイル対応とか面倒でやってられん。大事なのかもしれんが

2chがAPI導入を予定しており騒がしくなっております。

現管理人jimと元管理人ひろゆきとの確執
↓
決別、２ｃｈ住人は居残り
↓
ひろゆきは2ch.SCをたちあげ2chのデータ吸い上げ(datファイル)、2ch.scはログを貯め、それを商用利用
↓
嫌儲はそれに反発し、「西村最低だな」

という流れ。元管理人離脱で決着したかにみえたこの問題も結局サーバ代金かせぐため金の問題が解決していなかったようです。

現管理人jimは２月中旬ごろ2chにAPIを導入を予定。いままで各スレッドのdatファイルを直にHTTP経由で取りにいけたものを、今後開発される2chAPIを通してのdat利用に制限するとのこと。

今まで２ｃｈ現行スレのログであるところのdatファイルは、スレがある間はいつでも取りにいけたし取りにいくのは容易。普通にWebスクレイピングするよりも格段に楽で、多種多様な２ｃｈ専用ブラウザもそれを利用して開発されていた。dat取得すれば誰でも簡単に早く2chの内容をコピー・閲覧・保存など利用できてた。

それをまぁ制限しようとするわけですね。APIを利用することで専用ブラウザ作者に登録させ、datを取得してもらう・２ｃｈの内容を再配布し商用利用しようとする人には制限する。。というかんじ

２月中旬　API導入を3/3以降することを発表
↓
そのAPI開発・利用の許諾はJaneStyleという専ブラ作者の山下
↓
山下、専ブラ作者たちにAPI利用許諾をするよう広報
↓
JaneXeno,JaneViewは様子見、もしくは対応しない
他の専ブラも開発停止してるものも多くごく一部の限られた専ブラのみ対応するかんじに
↓
３／２　２ｃｈニュース板（旧・嫌儲・＋）で２ｃｈ卒業スレッド立つ。移住か恭順という名の家畜か
↓
３／３早朝　APIでエラー発生。対応表明していた２ｃｈ専ブラ軒並みダウン、むしろ未対応の専ブラからのアクセスが捗る。

・・・なんだこれｗ

CoreseverのApach/PHPバージョンアップメンテナンスを境にたまにInternalServerErrorがおこり、ページが表示されないことがある。

Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator, info@coreserver.jp and inform them of the time the error occurred, and anything you might have done that may have caused the error.
More information about this error may be available in the server error log.


調査した結果、原因はわからん

えーと

• 「php_flag ***」「php_value ***」とか.htaccessに設定していた場合に起こるとか書いてあったしそれを.user.iniに変更しろ
• WordPressの場合wp-config.phpを手動で編集していないか、編集しているときはUTF8N(BOMなし)で保存しろ

とか書いてあるけど当てはまらない

2chに相談しても安かろう悪かろうアキラメロンとのこと

どうしてもマズイ状況の場合は
「コアサーバ管理画面」
－「サポート」
－「お問い合せフォーム（VALUE-DOMAINサポートトピック）」
にてサポートをうけるしかないかも。俺はまぁ２０アクセスに１回ぐらいだからどうしてもページが表示されないってほどでもないからサポート頼るのはもっと酷くなってからかなと思ってる。

また何かわかったら記事を書こう

管理メニューのパスワード再発行にてパスワード再発行した場合新しいパスワードが発行されます。
その場合現在使っていたphpmyadminにログインする際のベーシック認証のパスワードもログインパスワードの上位４桁利用して使っているから変わると思っていたのですが、自動で変更はされません。

• 以前からのパスワードを使い続ける
• もしくは自分で変更する

いずれかを選択することになります。

■phpmyadminに入る際のベーシック認証のパスワードを変更する方法

変更する場合、「管理メニュー」-「ツール」で
htpasswdの生成にてユーザ名とパスワードを入力＆パスワード生成ボタン

• htpasswdの文字列と
• .htaccessのサンプル

２つが生成されます。

必要なのはhtpasswdの文字列のほうです。

[アカウント]/public_html/log/.htpasswdの内容を、上記の文字列に変更して保存。
これだけでいいです。

※ハマリポイント
.htaccessのサンプルは下手に[アカウント]/public_html/log/.htaccessに反映してはいけません。
AuthUserFile /virtual/[アカウント]/.htpasswd
・・・
となっており、使用する.htpasswdへのディレクトリパスが変わってしまいます。

.htpasswdの変更だけを行ってください。

あとまぁ変更する際には一時的にも変更するファイルのバックアップとってくださいね。
これやってたのですぐ戻せた。あぶなかったわー。やってなかったらますます混乱したことでしょう。

あとユーザが作ったものか言語仕様上の命令かが学びはじめだと混乱しちゃうんですよね。それで理解をとめちゃって先に進まない。
知識の蓄積がすすまない→理解がすすまない→学ぶのをやめると、こうなっちゃいがちなんですよね
あとインスタンスとクラスの違いについても理解ができない部分でもあります。
プログラムはその行に飛べば実行してくれるものというおっさんプログラマ的かんがえだとはまっちゃう。
その書いたプログラムの実体がない場合があるのが理解できなかったりします。オブジェクト指向型だと変数を用意するかのごとく
オブジェクトを用意する必要があったりしてなぜ動かないということがあったりします。
上から下へ流れるようなプログラムを書いてきたおっさん的にはつらいものがあります。
でおっさんプログラマ的に何を強みにするかというと過去の知識・経験です。昔使って大丈夫だったコードを再利用・過去やったパターンだと上手くいくかも、こうやって書いておけば間違いないし拡張性に優れる、このコードはテストもしているので大丈夫だというのを早い段階で判断し、使っていくことがおっさんプログラマの強みになったします。

つまり知識と理解と経験と判断の正しさをもってプログラマとしての強みをだしていかないといけない。

という雑記を３つもつかったことでようやくサイトの目的に戻ってきた。まあつまりたまには自分の部屋でも掃除をしようかなというのと同じような気持ちってことです。