”あー良い本だなぁー”って思うような考え方とか、取り組み方とかが書いてある本って、”自分の会社の人に読んで欲しいなぁー”って思ったりしますよね。
でも、そう思ってしまうことこと自体についてんーーっと考えてしまうこのごろ。
その人が今興味持っていることや、知識の量、タイミングによって、「ぐっ」とくる内容って多分違うんですよね。
今日読んだこの本...これも良い本だなぁーって思ったわけですが、この本を1年前に紹介されたら読んだのかなぁ?今日と同じように感動できたのかなぁ?と思うとちょっと分からない。
あと思うのは、
”周りの人に読んでほしい”と思ってしまう時点で、周りに頼ってしまっている...周りが変化して欲しいと望んでいる...って事の現れなのかなぁと。
言い換えると、自分自身のことを良く見れてない、見ようとしてないって事なんじゃないかなと。
これはちょっと反省。
自分自身が、おお!この本いい! とか この意見めっちゃよくない? とか出たときに、なんで周りは乗ってこないんだろう...と思ってしまうのは多分人間ならだれにでもあるエゴかな。
最高なのは自分と周りの人が同じタイミングにいること。
そうするには、仕事以外の雑談のコミュニケーションが豊富でないと難しいんですよね。
そうそう、もう一つ思った事。
会社内でのMLで何件かメールのやり取りがあったあと、社長のメールで、
「否定な意見だけではなくて、建設的な意見を求む」
ような言葉があったんですが、まぁこの言葉自体は変な言葉ではないですよね。
でも、その場の状況をふと冷静に考えてみると、
* 周りからは否定的な意見ばかり...という発言をしている人自身は別にそういうつもりで言っているんじゃない。
* 無関心の人よりは、よっぽど熱心に考えたから意見が出てきている。
* 否定的な意見だから建設的な意見を...と言ってしまう事時点でその人の考え、疑問、問いかけを全くゼロに戻してしまっている。それでいいのか?その人は無視されたと思うだろう。もうその人から意見は出ないかもしれない。
* それを見た人達は素朴な疑問や不安をぶつけることは出来なくなってメールが途絶える。
* 建設的ないい意見て、考える時間や、周りの人と話合うことをしないと出せないと思うが、そんな時間を作ってないんだから、すぐに出ないだろう
* メールは手軽で便利な道具だけど、文章として残ってしまうものであるので、簡単な意見って出しずらい。しかも場の雰囲気がそんなになってしまうと余計に....
* そして、経営者からみたら "どうしてうちの社員は消極的なんだろう"と多分悩むんだろう。
なんて思いました。
もっとざっくばらんな雰囲気な会社だったらいいんかもしれないけど。
そんな事を考えつつ、私個人と会社とのWinWinな関係ってなんだろう? 今まで通りに自分の意見をだらだらメールに書くのはどうなんだろう? とちょっと悩んでる日々。
2008年8月27日水曜日
2008年8月20日水曜日
AdobeAIRでのバージョンチェックと自動更新
AdobeAIRで作成した自作アプリケーションで最新バージョンをリリースしたら、旧バージョンの人に更新をしてほしいですよねー。
で、よく見かける方法として、アプリケーションで自動的にチェックして、「最新バージョンがあるけど更新しますか?」と促してあげる方法をASlimTimerでは使っています。
その方法を、AdobeAir-自動Updateに書いてみました。
方法としては、
自分で最新バージョンの情報をWEBに上げといて、それを読み込んで実行中のアプリケーションのバージョンとをチェック。
違っていたら、最新バージョンのモジュールをダウンロードして、後はflash.desktop.Updaterにお任せ です。
記事はコードもあって長文になってるんですが、やっていることは↑だけ。
しかもコードはASlimTimerのをそのままコピペ。しかも最後にはASlimTimerの宣伝付き(笑)
まぁ、それはさておいて、何か自作アプリをAIRで作る際には、始めから入れておくのをオススメ!
で、よく見かける方法として、アプリケーションで自動的にチェックして、「最新バージョンがあるけど更新しますか?」と促してあげる方法をASlimTimerでは使っています。
その方法を、AdobeAir-自動Updateに書いてみました。
方法としては、
自分で最新バージョンの情報をWEBに上げといて、それを読み込んで実行中のアプリケーションのバージョンとをチェック。
違っていたら、最新バージョンのモジュールをダウンロードして、後はflash.desktop.Updaterにお任せ です。
記事はコードもあって長文になってるんですが、やっていることは↑だけ。
しかもコードはASlimTimerのをそのままコピペ。しかも最後にはASlimTimerの宣伝付き(笑)
まぁ、それはさておいて、何か自作アプリをAIRで作る際には、始めから入れておくのをオススメ!
2008年8月18日月曜日
グーグルで人間はバカになる?
グーグルで人間はバカになる?という記事がCOURRiER Japonに載っていたのをお昼食事中に読みました。
記事の内容は、「最近、長文の文章や、本が読むのに耐えれられなくなった」ということ。
ネット上の情報を見るときは、大量の情報から目的のものを探し出すため、そんなに熟読はせずKeywordをささっと読んでいくことって多いんですが、頭がそれに慣れてしまって・・・というのが理由だろう・・・というお話。
日本でも「地頭力」という言葉は少し前に流行りましたが、同じようなことですよね。
みんな、少なからず実感として湧いてきた って状態だから、流行ったんでしょぅ。
脳の順応力ってすごく高いらしくて、「大量の情報から目的のものを探す」ことが多くなると、それに順応した脳になっていき・・・代わりに使われない機能(熟読)は低下していくらしい。
脳って凄いよねー。 そうでないと頭パンクして人間は変になっちゃぅんでしょぅ。
「大量の情報から目的のものを探す」というのは、重要な能力だし、そんなに機械的な作業ってわけでもないし・・・バカになるってほどでもないんちゃぅかなぁ?
今までの機械的な作業から解放されて新たな脳の働きが活性化! なんて。< SF小説読みすぎ
・・・まぁ、確かに、最近は何か新しいことしてみよぅ!と思っても、アイデアになるようなネタをネットサーフィンでGETしたりすることも多いし・・・少なからず脳はGoogle的になっちゃってるんかもしれないけど。
Googleでは、人工知能を本格的に検討している・・・という話の延長上に「2001年宇宙の旅」の話が出てました。
この映画は1965年に作成を開始したらしいのですが、現時点で再びみたら、また違う感覚で楽しいのかも? 今でも話題として出てくる映画ってすごいですよね。
「2001年宇宙の旅」のストーリーってほとんど覚えてないんですが、なんかまた見たくなったなぁ!
記事の内容は、「最近、長文の文章や、本が読むのに耐えれられなくなった」ということ。
ネット上の情報を見るときは、大量の情報から目的のものを探し出すため、そんなに熟読はせずKeywordをささっと読んでいくことって多いんですが、頭がそれに慣れてしまって・・・というのが理由だろう・・・というお話。
日本でも「地頭力」という言葉は少し前に流行りましたが、同じようなことですよね。
みんな、少なからず実感として湧いてきた って状態だから、流行ったんでしょぅ。
脳の順応力ってすごく高いらしくて、「大量の情報から目的のものを探す」ことが多くなると、それに順応した脳になっていき・・・代わりに使われない機能(熟読)は低下していくらしい。
脳って凄いよねー。 そうでないと頭パンクして人間は変になっちゃぅんでしょぅ。
「大量の情報から目的のものを探す」というのは、重要な能力だし、そんなに機械的な作業ってわけでもないし・・・バカになるってほどでもないんちゃぅかなぁ?
今までの機械的な作業から解放されて新たな脳の働きが活性化! なんて。< SF小説読みすぎ
・・・まぁ、確かに、最近は何か新しいことしてみよぅ!と思っても、アイデアになるようなネタをネットサーフィンでGETしたりすることも多いし・・・少なからず脳はGoogle的になっちゃってるんかもしれないけど。
Googleでは、人工知能を本格的に検討している・・・という話の延長上に「2001年宇宙の旅」の話が出てました。
この映画は1965年に作成を開始したらしいのですが、現時点で再びみたら、また違う感覚で楽しいのかも? 今でも話題として出てくる映画ってすごいですよね。
「2001年宇宙の旅」のストーリーってほとんど覚えてないんですが、なんかまた見たくなったなぁ!
ASlimTimerの第一弾をリリース
SlimTimerのAirクライアントとして、ASlimTimerをリリースしてみました!
残念ながらオフライン対応は未だなんですが、オンラインでの通常の動作は行なえるようになっていると思います。
SlimTimerを使っている方は、ぜひ使ってみてください!
ダウンロードはこちらから。
ASlimTimer
残念ながらオフライン対応は未だなんですが、オンラインでの通常の動作は行なえるようになっていると思います。
SlimTimerを使っている方は、ぜひ使ってみてください!
ダウンロードはこちらから。
ASlimTimer
2008年8月9日土曜日
スーパーごろ寝クッション
スーパーごろ寝クッションが届きました!全体像はこんな感じ。

使ってみるとこんな感じ。

なかなか快適でしたよ。あごをつけてるとアトが付きそうなので、タオルをひいて使用中です。
多分、中国製であろうこのクッションで、オリンピックの開会式もダラダラ見ました〜
付属の紙には

...と、シリアル番号なし!というのが笑えるっ
このクッション、約8,000円と安くはないのですが、我が家ではなんと!2台稼働中です。
試したい方は我が家にいらしてくださいぃ〜!

使ってみるとこんな感じ。

なかなか快適でしたよ。あごをつけてるとアトが付きそうなので、タオルをひいて使用中です。
多分、中国製であろうこのクッションで、オリンピックの開会式もダラダラ見ました〜
付属の紙には

...と、シリアル番号なし!というのが笑えるっ
このクッション、約8,000円と安くはないのですが、我が家ではなんと!2台稼働中です。
試したい方は我が家にいらしてくださいぃ〜!
2008年8月8日金曜日
AirでのKeyEvent
作成中のSlimTimerにてKeyboardのショートカットを作るため、KeyEventの取得方法を色々みていました。
で、GoogleSiteに記事を登録しました。
Air画面でのKeyイベント
Contentsはこんな感じ
サンプルをみていたら、KeyCodeの定数が使われていなくて直接数値が埋め込まれているのが多くて、えーありえへん!って思っていたんだけど、よくよくみると、Keyboardってクラスに定数があるのを発見。
そりゃそうよねー。気づいてよかった。
で、GoogleSiteに記事を登録しました。
Air画面でのKeyイベント
Contentsはこんな感じ
1. Keyイベントの登録方法
2. GUIコントロール部品でのKeyListener
3. 画面内でのKeyListener
3.1 mx:WindowedApplicationの場合
3.2 mx:Windowの場合
3.3 mx:TitleWindowの場合
4. Airアプリケーション全体へのKeyListener
5. 複数EventListenerを登録した場合の順序
サンプルをみていたら、KeyCodeの定数が使われていなくて直接数値が埋め込まれているのが多くて、えーありえへん!って思っていたんだけど、よくよくみると、Keyboardってクラスに定数があるのを発見。
そりゃそうよねー。気づいてよかった。
2008年8月7日木曜日
2008年8月6日水曜日
大きいものに巻かれてしまえ
...って最近思うんですよ。
ブログはBlogger使っているんですが、機能的には他のBlogの方がいいかもしれない。
つぶやきはTwitter使ってるんですが、他の似たようなサービスの方が機能が良くて、落ちにくいかもしれない。
メールはGmail使っているし、Google信者といわれても、「はい。そうですよ」と答えている。
これらを使っていると、いろんなサービスとの連携とか、ツールとか、対応してくれている可能性が高いんですよね。
API公開されているソフトというものもポイント高いですよね。
だって、API公開されていたら、本体の機能がしょぼくても誰かが良いもの作ってくれてるかもしれない。API公開されててメジャーのものならば、誰かが作ってる...って可能性は凄く大きい。
メジャーのものならば、更新も頻繁にやってくれる可能性も高い。
逆にマイナーのものは更新とまっちゃぅかもしれない。
メジャーのものを避けて、よさそうなマイナーのものを選びたくなる衝動はあるんですが、このご時世の場合、少々使い勝手が悪いぐらいであればメジャーのものを選ぶのが賢いですよ、多分。
んでもって、今は何が一番使われているのか...?をチェックしつつ、バシバシ乗り換えていくのがよさそう。
今はGoogleが強いし、一般ユーザにいろんなものを無料で提供してくれる(StreetViewも感動した)けど、もし力が弱くなった...とか...ほかのものが台頭してきたらどうするのか?
サクっと乗り換えてしまったらいいんですよ。簡単〜♪
何かにしがみついている理由もないしね。
ブログはBlogger使っているんですが、機能的には他のBlogの方がいいかもしれない。
つぶやきはTwitter使ってるんですが、他の似たようなサービスの方が機能が良くて、落ちにくいかもしれない。
メールはGmail使っているし、Google信者といわれても、「はい。そうですよ」と答えている。
これらを使っていると、いろんなサービスとの連携とか、ツールとか、対応してくれている可能性が高いんですよね。
API公開されているソフトというものもポイント高いですよね。
だって、API公開されていたら、本体の機能がしょぼくても誰かが良いもの作ってくれてるかもしれない。API公開されててメジャーのものならば、誰かが作ってる...って可能性は凄く大きい。
メジャーのものならば、更新も頻繁にやってくれる可能性も高い。
逆にマイナーのものは更新とまっちゃぅかもしれない。
メジャーのものを避けて、よさそうなマイナーのものを選びたくなる衝動はあるんですが、このご時世の場合、少々使い勝手が悪いぐらいであればメジャーのものを選ぶのが賢いですよ、多分。
んでもって、今は何が一番使われているのか...?をチェックしつつ、バシバシ乗り換えていくのがよさそう。
今はGoogleが強いし、一般ユーザにいろんなものを無料で提供してくれる(StreetViewも感動した)けど、もし力が弱くなった...とか...ほかのものが台頭してきたらどうするのか?
サクっと乗り換えてしまったらいいんですよ。簡単〜♪
何かにしがみついている理由もないしね。
2008年8月2日土曜日
アジャイルはソースコードの中にも。
今日は、Wicket勉強会に参加してきました!
会社はたまたま盆休みの休暇を出していた日だったし...会場は家からめちゃめちゃ近いし...ということで、用意してもらったような勉強会ww
業務でもちゃんと使って上手く行っている所が既にあるんだなー!
話の中で、コード量を少なくして設定で楽にする...というのを行なうと、Wicketの良さが半減してしまうんじゃないか?って話があったんですが、ここは考えさせられる所ですよね。
WicketはJavaでコーディングできるからこそ、楽しいし、設定とソースとちょこちょこ移動しなくていいからテンポがよくなるし...ってのでイイ!というのがありますものね。
ここは「バランスが肝心」ってやつなんでしょう。
処理パターンとか...作業メンバーのスキルとか...によっても変わるし、Wicketだからこうしなさい!というものは、やっぱり言えないですよね。
でも、”こぅいぅ方法がある”ということを知らないと、どうしよぅ?と考えたときの選択肢も増えない。
知識というのは、そのときに必要じゃなくても必要ですねー。
そういえば、テレビで脳科学者の茂木先生が、
...ってな事を言っていました。(言い回しはちょっと違ったかも。。)
ソフトウェアを作るってことは、全く同じものを作る訳でないから、毎回新しいものの生み出し!なんですよね。
方法は色々知っておいて、自分で何かを生み出すときには、色んな引き出しを用意しておきたいものです。
懇親会は参加しなかったんですが...盛り上がったのかな?
家に帰ってからは、会社の後輩とSkypeでテストケースのパターンの話をしました。
テストケースって基本全てのパターンを網羅するってのは基本なんですが、それを真面目にやろうとすると、パターンの乗算的に考えていくと、現実的でない量になるので...どうしたらいいのか?という質問だったんですが....
ソースコードの作りがどうなるのか?も全く不明な状態だと、「全部のパターン網羅」としか安全な言い方はないんですよね。
でも、ここで、「じゃーこのパターンだけでいいよ」って指示を出してしまうと、「そのパターンが満たされていたらOK」として作業完了されるのも不安がのこるし...
しかも、ソースコード、テストケースを作成するのは、Javaの知識があまりない人達という前提もあって、回答は私には難しかった。
Javaを書き慣れている人がやるのであれば、同じようなソースを複数のソースに記述することはないだろうし、ソースコードの書き方からみて、ここらへんはヤバイから集中してテストをしよう。とかも分かるだろうし...って事で、ある程度は判断できると思うので始めはお任せして、実際ほかのテストでバグが見つかったらテストケースの追加...ってしていくのですけどもねぇー。
さっきのWicketの話題とちょっと似ているなと思うのが、
「これは、こうすべきだ」と定型化してしまうと、作業の効率が悪くなったり、ソースコードの見通しが悪くなってしまったり...ってなるのは、やっぱり避けられない。
新たに何かを生み出す作業なのだから、作業者が常に、”バランス”を考え、”変化に対応” していくのは必要なんでしょぅ。
一つのコードの中にもアジャイルの姿勢で効率化をはかれ ってことですね!
会社の後輩から、「え?これはしても良い事なんですか?」って言われるときが度々あります。こっちの方法の方がいい!と途中で思ったんなら、そのときに相談してよーって思ってしまう訳ですが、これって、後輩が新人の頃に「これは、こーやって作成して」って定型の指示を忠実に守ってきたから...ってのもあるんですよね、多分。
ここの所は、反省。
新人に対してであっても、教えることは、
「こういうパターンはこうやって実装するんだよ」ってことよりも、
「こうした方が、より良くない?と常に考えることだよ」って事を教えていく事の方が大事なのかもなぁー。
会社はたまたま盆休みの休暇を出していた日だったし...会場は家からめちゃめちゃ近いし...ということで、用意してもらったような勉強会ww
業務でもちゃんと使って上手く行っている所が既にあるんだなー!
話の中で、コード量を少なくして設定で楽にする...というのを行なうと、Wicketの良さが半減してしまうんじゃないか?って話があったんですが、ここは考えさせられる所ですよね。
WicketはJavaでコーディングできるからこそ、楽しいし、設定とソースとちょこちょこ移動しなくていいからテンポがよくなるし...ってのでイイ!というのがありますものね。
ここは「バランスが肝心」ってやつなんでしょう。
処理パターンとか...作業メンバーのスキルとか...によっても変わるし、Wicketだからこうしなさい!というものは、やっぱり言えないですよね。
でも、”こぅいぅ方法がある”ということを知らないと、どうしよぅ?と考えたときの選択肢も増えない。
知識というのは、そのときに必要じゃなくても必要ですねー。
そういえば、テレビで脳科学者の茂木先生が、
新しい事を生み出すということは、今までの経験情報の引き出しから引っ張ってくる作業だ。
...ってな事を言っていました。(言い回しはちょっと違ったかも。。)
ソフトウェアを作るってことは、全く同じものを作る訳でないから、毎回新しいものの生み出し!なんですよね。
方法は色々知っておいて、自分で何かを生み出すときには、色んな引き出しを用意しておきたいものです。
懇親会は参加しなかったんですが...盛り上がったのかな?
家に帰ってからは、会社の後輩とSkypeでテストケースのパターンの話をしました。
テストケースって基本全てのパターンを網羅するってのは基本なんですが、それを真面目にやろうとすると、パターンの乗算的に考えていくと、現実的でない量になるので...どうしたらいいのか?という質問だったんですが....
ソースコードの作りがどうなるのか?も全く不明な状態だと、「全部のパターン網羅」としか安全な言い方はないんですよね。
でも、ここで、「じゃーこのパターンだけでいいよ」って指示を出してしまうと、「そのパターンが満たされていたらOK」として作業完了されるのも不安がのこるし...
しかも、ソースコード、テストケースを作成するのは、Javaの知識があまりない人達という前提もあって、回答は私には難しかった。
Javaを書き慣れている人がやるのであれば、同じようなソースを複数のソースに記述することはないだろうし、ソースコードの書き方からみて、ここらへんはヤバイから集中してテストをしよう。とかも分かるだろうし...って事で、ある程度は判断できると思うので始めはお任せして、実際ほかのテストでバグが見つかったらテストケースの追加...ってしていくのですけどもねぇー。
さっきのWicketの話題とちょっと似ているなと思うのが、
「これは、こうすべきだ」と定型化してしまうと、作業の効率が悪くなったり、ソースコードの見通しが悪くなってしまったり...ってなるのは、やっぱり避けられない。
新たに何かを生み出す作業なのだから、作業者が常に、”バランス”を考え、”変化に対応” していくのは必要なんでしょぅ。
一つのコードの中にもアジャイルの姿勢で効率化をはかれ ってことですね!
会社の後輩から、「え?これはしても良い事なんですか?」って言われるときが度々あります。こっちの方法の方がいい!と途中で思ったんなら、そのときに相談してよーって思ってしまう訳ですが、これって、後輩が新人の頃に「これは、こーやって作成して」って定型の指示を忠実に守ってきたから...ってのもあるんですよね、多分。
ここの所は、反省。
新人に対してであっても、教えることは、
「こういうパターンはこうやって実装するんだよ」ってことよりも、
「こうした方が、より良くない?と常に考えることだよ」って事を教えていく事の方が大事なのかもなぁー。