ソフトウェアエンジニア日記かも: 10月 2010

2010年10月31日日曜日

読録 2010年10月

キノの旅VI：時雨沢恵一
キノの旅VII：時雨沢恵一
キノの旅VIII：時雨沢恵一
キノの旅IX：時雨沢恵一
学園キノ。：時雨沢恵一

　トんでます。しばらくはやめておこう。

超鋼女セーラ：寺田とものり

嗤う伊右衛門：京極夏彦

　怖くはないけど、人物の息遣いまで聞こえるような、この生々しさがやっぱりすごいなと思います。

ぼくらは虚空に夜を視る：上遠野浩平

イリヤの空 UFOの夏その1：秋山瑞人

レンタルマギカ～魔法使い、貸します！：三田誠

　なんつうか魔法のサラダボール？。よく一つにまとめられるもんだ。まあ、それが小説ということか。

　試験期間でそんな暇ないはずなのに、10冊読んでる。つまりはそういうことです。

飲録 2010年10月

白金乃露栗黄金：芋焼酎：☆☆☆(甘みと辛味のバランスが良い。すっきりと飲める)
摩無志(まむし)：芋焼酎：☆☆☆(香りが華やかな芋焼酎はかなり飲める)
熟成光年(こうねん)：麦焼酎：☆☆(熟成された甘みと香りは好きになる)

試験期間があったけど先月より飲んでる。試験明けたとたんに、これです。

2010年10月25日月曜日

メールで傷つかないために

メールを読んでカチンときたりするのは、受け手の問題ということだが。
相手はそういう意図で書いたわけではないにも関わらず、そう受け取ってしまうのはままあることなのだ。
そんなこんなでコミュニケーションの齟齬が生じて、嫌味の応酬のようなものが始まると、全く不毛な時間の浪費となる。

じゃあどうしたらいいのかと言えば、相手を変えることは土台無理な話なので、自分が変わる必要に迫られる。
相手の意図を察した上で、相手に不快な印象を与えぬように丁寧に返事を返すわけだ。
これで不毛な諍いをせずに済み、一件落着。。。なんてことはない。

相手は相変わらず、自分の感情を逆立てするような書き方しかしてこない。
自分は紳士的に対応しているにも関わらず、そんなことは相手には伝わらない。
そうして自分にばかり負債が増えていくばかり。
さらに普段顔を合わせていてもあまり良好な関係とは言えない人が相手だとすると、ダメージは大きい。

感情の機敏を察知するような人間にとって、メールというのは、かなり辛いツールなのだ。
相手はその気がないにも関わらず、勝手に自滅していくという恐ろしさだ。

さてどうしたものか。
メールというのはそういうものなのだと頭では理解したつもりでも、感情の起想を抑えることは難しい。
相手がそのつもりなら、自分だってそう返してやるなんてことも、そもそも自分は構造を理解しているので、自分の良心を裏切ることになるため、これも自滅行為だ。

いい解決方法かどうかはわからないけれども。
メールに対して、新しい反応パターンを作ることだろう。
徹底的に矯正して学習して覚えこませるということ。
そもそもが自分の感情起想に原因があるのだから、それを捕らえて、再プログラミングするのはそんなに難しいことではないはず。
こうしてまた一つ人格が分断されていくのだけれども。

そろそろ学校教育とかでメールの書き方や感情表現について教える必要があるのだと思う。

2010年10月17日日曜日

NW試験リベンジ

行ってきました。NW試験。

昨日は一日だらっと過ごしていました。
お昼過ぎまで寝てたり、
ちょっと気になっていたラーメン屋に行ってみたり、
結局一度も参考書は開かずじまい。

そんでもって本日は、
イマイチ体調不良。
眠い、頭痛い。
試験中も別の意味で頭痛かったし。
何この凶悪な相乗効果。試験？試練なのか？...

ま、何とか最後まで頑張ってはみましたか？

ともあれ酒、一月ぶりに酒が飲める。
ひゃっほー！

ゲームで遊べる。
よっしゃー！

しかし、頭が痛いのでまた今度。

2010年10月13日水曜日

Thread内でWakeLockが使いたい

Contextを渡してやればOK

ActivityかServiceにてThreadを生成する際に、自分自身を渡してやります。

view plain print ?

HogeThread thread(this);
thread.start();

HogeThread thread(this);
thread.start();

スレッドでは、コンストラクタでWakeLockを生成してしまいます。

view plain print ?

public class HogeThread extends Thread {
private Context mContext;
private WakeLock mWakeLock;
public HogeThraed(Context context){
mContext = context;
PowerManager pm = (PowerManager)mContext.getSystemService(Context.POWER_SERVICE);
mWakeLock = pm.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "HogeThread");
}
}

public class HogeThread extends Thread {
    private Context mContext;
    private WakeLock mWakeLock;
    public HogeThraed(Context context){
        mContext = context;
        PowerManager pm = (PowerManager)mContext.getSystemService(Context.POWER_SERVICE);
        mWakeLock = pm.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "HogeThread");
    }
}

use-permission name="android.permission.WAKE_LOCK"
をお忘れなく。

2010年10月9日土曜日

CEATEC 2010に行って参った

CEATEC行ってきました。

3Dについて
3Dになったからといって何かが変わるって程ではない。今はまだね。
ただ臨場感が上がるというだけで、本質が大切なことは変わらない。
RPGで言えば、映像だけきれいで、シナリオとかシステムが駄目ではどうしようもないということか。
(ちょっと違う気もするけど。)

Androidについて
どれもこれもプラットフォームに大きな差はない。(同じOSだから、そりゃそうだ)
だからキャリア限定、機種限定のサービスとか、AV機器との連携とかにプレミア感がついているという差だと思う。
本当は、同じプラットフォームを使っているのだから、どれでも同じようにサービスが受けられる方が嬉しいんじゃないかな。前使っていた機種の履歴とか登録情報を引き続き使えるとか。
ま、それじゃあ儲からないんだろうけど。
もっと何か、どこにでも当たり前に置いてあって、自分が手に取ると自分の端末として使えるってぐらいになるといいんだがね。まだ先でしょう。

ARについて
まだまだ日常的に使えるというレベルではないね。

2010年10月2日土曜日

情報共有について再び考える

「課題」という観点で情報共有システムを作ってみたらどうなんだろうか？

Q＆Aのようになるイメージですが、
ある課題に対して、ある人は解決策を持っているとすれば、それはノウハウ共有につながる。
ある課題に対して、現在解決策がないとすれば、それはアイデア創出につながる。

課題は膨大な量になるので、タグ付けをして整理することができる。
また、検索して既に同じ課題が挙がっていないかチェックすることができる。
あるいは、ある程度カテゴリーに分けるようにするべきか...

リンクを貼れること。
ブックマークに登録できること。
画像やパワポなどをUPLOADできること。(またはリンクを貼るでもOK)
ある資料が複数の課題の解決策になっていることもある。と考えると、資料は別の場所に格納すべきか...
資料にもタグやタイトルを付けて管理できること...
課題に対して複数の解決策があるとして、それぞれを別々にかつわかりやすく整理できること

今までにある情報共有システムにはなく、課題に特化することで必要になる要素とは何か？