h.hatena.com は生きていた
とっくに引導を渡されたと思っていた h.hatena.com 。実は、まだ生きていた。
http://h.hatena.com/api/statuses/public_timeline.json?count=30
投稿などの URL だと 301 でトップの「終了しました」に飛ばされちゃうけど、
はてなハイクタイムラインAPI をドメインを .hatena.com で使うと、サーバが生きてるだけじゃなくて、投稿もされていることが分かる。
iPhone の非公式アプリ HaikuNeko や、Google Chrome の「どこでもはてなスター」拡張から投稿できているみたい。
☆だけではなく、メモを書き残すこともできる (メモははてなハイクに投稿される)。
どこでもはてなスター (Chrome)とは - はてなキーワード
GitHub にある、「どこでもはてなスター」拡張のソース。
https://github.com/wakaba/chrome-hatena-star-everywhere/blob/master/entry-script.js#L446
function postHaikuEntry (args, nextCode) { var self = this; bg.getRKM (function (rkm) { var xhr = new XMLHttpRequest (); var postURL = 'http://' + bg.config.getDomain ('h') + '/api/statuses/update.json'; xhr.open ('POST', postURL, true);
記事を POST する URL は、bg.config.getDomain() を介して決められている。
getDomain メソッドは、Google Chrome のロケールを見て、h.hatena.ne.jp か h.hatena.com を切り替えている。
https://github.com/wakaba/chrome-hatena-star-everywhere/blob/master/user-config.js#L25
getDomain: function (subdomain) { if (this.get ('tld') == 'jp') { return subdomain + '.hatena.ne.jp'; } else { return subdomain + '.hatena.com'; } }, // getDomain
https://github.com/wakaba/chrome-hatena-star-everywhere/blob/master/user-config.js#L5
UserConfig.prototype = { defaultValues: { allowedURLs: '^https://[^/]+\\.hatena\\.(?:ne\\.jp|com)/', disallowedURLs: '^https://\n^http://[^/.]+/', tld: /^ja(?:_|$)/.test (chrome.i18n.getMessage ('@@ui_locale')) ? 'jp' : 'com', iconType: 'default', nameType: 'nickname', useIconStar: false, }, // defaultValues
投稿してみるべ。
(function() { var xhr = new XMLHttpRequest(); var postURL = 'http://h.hatena.com/api/statuses/update.json'; xhr.open ('POST', postURL, true); xhr.onreadystatechange = function() { if (xhr.readyState == 4) { if (xhr.status < 400) { alert('OK'); console.log(JSON.parse(xhr.responseText)); } } }; xhr.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded'); var data = 'keyword=' + encodeURIComponent('はてなハイク') + '&status=' + encodeURIComponent('h.hatena.com は、まだ生きている!?') + '&source=' + encodeURIComponent('a-kuma3 test') + '&rkm=' + encodeURIComponent(...); // rkm は、h.hatena.ne.jp のページから引っこ抜く xhr.send(data); })();
クロスオリジンの制約があるので、h.hatena.com のページで Bookmarklet として実行。
ログイン状態を表している rkm は、h.hatena.ne.jp のページから引っこ抜いて書いておく。
BASIC 認証があるので、ユーザID と API キーをパスワードとして入力。
はてなハイクAPI で確認。
http://h.hatena.com/api/statuses/public_timeline.json?count=30
h.hatena.ne.jp で投稿を確認。
http://h.hatena.ne.jp/a-kuma3/81808088407040107
でも、h.hatena.com への投稿だから、h.hatena.ne.jp のキーワードページには表示されないの。
http://h.hatena.ne.jp/target?word=%E3%81%AF%E3%81%A6%E3%81%AA%E3%83%8F%E3%82%A4%E3%82%AF
WSH (VBScript) で XMLHTTPRequest
この質問の回答での余禄。
url = ... Set xhr = CreateObject("MSXML2.ServerXMLHTTP") xhr.Open "GET", url, False xhr.Send If xhr.Status < 400 Then WScript.Echo xhr.responseText End If
同期モードになるのは VBScript なので、しゃあない。
プロクシを使うときはこう。
xhr.Open "GET", url, False xhr.setProxy 2, "proxy.foo.com:8080", "" xhr.Send
認証ありのプロクシだと、こんな感じ。
xhr.Open "GET", url, False xhr.setProxy 2, "proxy.foo.com:8080", "" xhr.setProxyCredentials "a-kuma3" , "a-kuma3-password" xhr.Send
例によって、ネタは stackoverflow 。
http://stackoverflow.com/questions/19008874/xmlhttp-request-ajax-with-vbskript-does-not-work-with-proxy-connection
MSXML 6.0 以降、って地雷も、今なら踏む人は少ないか。
MSDN 。
https://msdn.microsoft.com/en-us/library/windows/desktop/aa384059%28v=vs.85%29.aspx
三番目の引数は、プロクシの除外対象。
はてなスクリーンショット拡張 (Firefox) への最後通告
はてなでは、サービスを便利にご利用いただけるツール群を「便利なツール」のページにて提供しておりましたが、現在のご利用状況を鑑み、来たる3月31日をもちましてこちらのページでのツールの提供を終了、一部のツールを廃止することといたしました。
「便利なツール」(拡張、ツールバー、アプリケーション)に掲載されているツールのうち一部の提供を終了します - はてなの日記 - 機能変更、お知らせなど
分かってはいたけれど、運営からの最後通告がとうとう出た。
まあ良い。
幸いにして、MIT License なので好きにさせてもらう。
そういえば、Firefox 46 で、アドオンの署名検証をスキップする xpinstall.signatures.required が効かなくなるという噂があった。
その検証がてらいくつか。
PC でスマホ表示 @はてなブログ
ダイアリーの場合は、スマホで PC 用の URL をアクセスすると、スマホ用の URL に飛ばされる。
http://d.hatena.ne.jp/a-kuma3 ―― PC用
↓
http://d.hatena.ne.jp/a-kuma3/touch ―― スマホ用
でも、はてなブログの場合は URL が変わらない。
見た目が完全に違うので、メディアクエリだけで対応しているというわけでもない。
Agent 偽装すれば良いんだろうけど、できればアドオンを増やしたくない(DevTools では対応してない)なあ、と。
今まで目に入っていなかったのだけれど、記事を書くときのプレビューに「PC」と「スマートフォン」の切り替えがある。
開発ツールでヘッダとパラメータを確認してみたら、device=touch なるパラメータが付いているではないの :-)
パラメータに device=touch を指定すると……
http://a-kuma3.hatenablog.com/entry/touchmode_hatenablog?device=touch
これで、スマホ用のスタイルも PC の開発環境でがんがんいじれちゃう。
ダイエットをすると軽くなるのか?(Firefox の話)
重い。
ひたすら Firefox が重い。
タブを閉じたときにぴたっと固まる。
はてなスクリーンショットが動かなくなったとか騒いでたのだけれど、元々は Firefox が重たくって 64bit 版にしたら解消できるのかも、とか、そういうところから始まってたのだった。
- ふりかえり
- 一度は通った道
- places.sqlite
- さあ、ダイエットだ
- まずは、VACUUM
- レコード数の確認
- ダイエットの方針
- moz_places で消せるレコードの確認
- さあ、ダイエット
- 仕切り直し
- まとめ
- ダイエットの SQL
- 副作用
- その他
- moz_hosts
- プロファイルはバックアップを取るべき
- Bookmark Favicon Changer
ふりかえり
一度は通った道
タブを閉じたときの状況をタスクマネージャーで見ると、CPU は 50% で張り付いたまま(core × 2 なので、実質 使いきってる)。
タブを閉じるときに顕著に重たくなるので、「履歴を残す」とか、「セッションや閉じたウィンドウを残す」とか、そういう処理が引っ張っているんだろう、とは思ってる。
I/O は上がらないけど、特定の svchost.exe なども CPU を使いまくってるので、アンチウィルスソフトに巻き込まれているんだろう。
以前、手違い(とまでは言わないけど)places.sqlite を削除したら、しばらくは軽い状態が続いていたような気がする。
また、ダイエットだな。
places.sqlite
places.sqlite というファイルはアクセスの履歴なんかを抱えているので、使っているうちにどんどん大きくなる。
消せば軽くなるよ、という話はあちこちで見られるのだけれど、ちょっと不便なことも。
- Bookmark を消失する可能性がある
- Bookmark Favicon Changer というアドオン(AMO から消えている...)の設定の一部がリセットされる
64bit 版を使い始めるときに、バックアップをミスって places.sqlite がおかしくなってしまったときには、古いバックアップから favicon の情報をサルベージしたのだけれど、これがまた微妙に面倒で、何度もやりたいような作業ではない。
というわけで、今回はきちんとダイエットしようと思ったのだ。