マウス(ロジクール M325)の電池が切れた 2回目
[マウス(ロジクール M325)の電池が切れた - ぽひゅっとメモ]
http://d.hatena.ne.jp/fre_oik/20120211/1328926370
前回の電池切れ・交換日が2/11
今回切れたのがさっき。7/10から7/11にかけて。
前回は
9/14 〜 2/11
約5ヶ月
今回は
2/11 〜 7/11
約5ヶ月
結構ハードに使って、常時電源ON
以上の使用結果から・・・
電源常時ONでも、平常の使用の範囲で使っていれば大体5〜7ヶ月くらいは持つと思います。
ある程度信頼出来る数字になったと思うので購入の際の参考としてください。
単三電池1本で酷使してこれだけもつんでコストパフォーマンスはいいほうじゃないかなー
ネトゲ(TalesWeaver)用に適当に作った軽いWebアプリをherokuにデプロイして公開
最近書いてなかったので技術系の記事
たいしたことはしてない
ネトゲ(TalesWeaver)用に適当に作った軽いWebアプリをherokuにデプロイして公開。
・WebサーバーをWebrickからThinにする。
・静的ページをページキャッシュさせる。
・ヘッダー、フッター、サイドメニューなどをフラグメントキャッシュさせる。
・ユーザーによるDB操作は行わず、データはマスターデータ(参照系)のみのため、Modelに全件数をALL_RECORD_COUNTで持たせてcount文クエリを発行させないようにする。
ってことでレスポンスを高速化。
CSSを改行・スペースを消す圧縮をかけてサイズを減らすというのもよかったかも。
あとMemcache使いたかったけど(5MBまで無料アドオン)、クレジットカード登録が必要で今持ち合わせてなかったので涙を飲んで妥協。
あまりDB接続してSQLのリクエストを発生させたくないけれど、DB設計とかクエリの最適化、インデックスの利用等はしてるので良いかな…。
大体5msで返ってきてるし。
herokuのDBってPostgreSQLなんだけど、詳細チューニングは多分出来ない気がする(特に無料の範疇では)。
たまにherokuの負荷が集中してるのか？ってときはクエリが90msくらいになる場合もあるけど、Viewの描画速度に体感する差はなかった。
あとなんかheroku run rake db:seedを何回かやってたら、1~370のID(≒レコード数)を持つテーブルで、
1
193
2
3
4
...
370
と謎な現象が起きた。
heroku run rake db:resetで直って再現性はなし。
あと
heroku logs --tail
でログ監視してると、ごくごく稀に
Error H16 (Redirect to http://herokuapp.com) -> GET 略
と出るが、再現する方法がよくわからん。301エラー起こす。
以上。
最近TalesWeaverやってないけれど、使ってくれる人が増えたらいいなー。
お粗末なつくりなのでURLは載せられない・・・
マウス(ロジクール M325)の電池がもうちょっとで切れそう
前回より頻繁に使っているからだと思うけど、前より早く切れそう。
もしくは電池の種類とかによっても若干寿命変わるのかな。
また切れたら記事にする。
マウス(ロジクール M325)の電池が切れた
[ロジクールのワイヤレスマウスM305から、M325にマウスを変えた - ぽひゅっとメモ]
http://d.hatena.ne.jp/fre_oik/20110914/1316015428
こちらの記事(2011/9/14)で書いた、
ロジクールのM325マウスの電池が今さっき切れました。
・9月(14日〜) 購入
・10月
・11月
・12月
・1月
・2月(〜11日)
おおよそ6ヶ月持ったみたい。
単三電池1本なので、これはなかなか電池の持ちがいいね。
前まで使ってたM305は、大体3ヶ月前後で電池が切れてたので、ずいぶん伸びたな。
次に電池が切れるのは8月くらいかな？
購入を検討してる人は参考にどうぞ。
光る才能、魅力
無事転職（？）して月曜から新しい職場で勤務が始まりました。
とは言え、転職斡旋業者を通して、新規職場からは業務委託(早い話が派遣)の状態で、
先行きは分からないものがあります。
最後まで2社悩み、決めた1社で、
そこには多々要因がありました。
最終的には知人の客観的意見と後押しが決め手となったのですが・・・
ちょっとした大手会社ではありますので、
やはり著名人はいらっしゃいます。
あの記事みたよ！
あの発表の人だよね！
なんて、世間じゃよくある話ですが、
実際その著名人を抱える会社はそう多くないものです。
また、そういった著名人を幾人か抱える会社だとしても、
大企業であれば交流の機会はなかなか持てない場合もあると思っています。
今回、ちょっと拝見した記事およびに発表された方が、
同プロジェクトにいらっしゃって、話す機会も持てました。
そんなに社交的に外部と交流を持っていないのでちょっとドキドキしましたｗｗ
やはり感じたのは、光る才能や人と違ったセンスや魅力、独特のオーラがあったことでしょうか。
凡小な自分だからこそ、よりそういった部分を感じたのかもしれませんが・・・。
今後、同じようにとは中々言えませんが、
その方のように情報を発信する側として、知識や情報を蓄えていけたらなと思った1日でした。
パーミッションでこけまくる
sudo権限を与えるとか、
色々ちまちまとやってます。
sbinにPATHが通ってなくて、
ifconfigとか色々コマンドにパスが通っておらず・・・
調べたら.bash_profileに書けばよさげだったけれども、
なかったのと作ってもうまくいかなかったので.bashrcに
と入れたり・・・。
PATH=$PATH:/usr/local/sbin:/usr/sbin:/sbin
export PATH
後は多々permission deniedで怒られたら、
そのディレクトリのアクセス権限777にしてしまえウヒョー！！
としまくってしまった。
セキュリティ的にはザルになってしまうので非常によろしくないのは理解しつつも、知識が皆無なのでお作法的によろしくなくてもあしからず・・・。
徐々に覚えていければと思いつつも、まずは動く環境構築優先したのでorz
ほんでもってよくある問題、
MySQLの文字コードがlatin1になってて文字化けする！！
ってのを直そうと、my.cnfをいじって再起動！！
が、failedする・・・。
root権限じゃないとだめなのか、sudoだ！
としてみたら、
どうもmy.cnfがignoreとか言われて無視されてるくさい。
当然MySQLクライアントから
CREATE DATABASE test;
USE test;
SHOW variables LIKE 'char%';
としても、latin1のまま。
ぐぐったら出てきたのが↓
【sunadaaの日記 : my.cnfを無視させないようにする - livedoor Blog（ブログ）】
http://blog.livedoor.jp/sunadaa/archives/50450721.html
Permissionか！！！
777になってたのを660にしましたorz
ほんで再起動したらうまくいったーーー。
いかん、適当なノリで777にした結果のツケが後で色々まわってきそうだ・・・。
ある意味自分の理解力に対する勉強の仕方としてはちょうどいい気はするけれど、やっちまった感は否めないorz
