トップ > 2007年6月

少しでも本を速く読むために

一部で話題になっているようなので。

別に速読できないし多読なわけでもないが、平均よりは速い部類だと思う。

で、思うことを。
本を読むのが遅い人は、心の中で音読することが多いのでは?
「心の中で発音せず、字面をそのまま理解する」と言うのを意識するだけで読むのが早くなると思う。

理解力とか語彙力とか知識量とか、そんなのも読書スピードに関係するとは思うけど、「心の中で順に発音しながら読む」というのを止められるかが一番最初のハードルになる気がする。

| 07-06-28 15:28 | コメント (0) | トラックバック (0)

おすすめ! - 脳が冴える15の習慣

日曜日に審判で栃木に出かけたので、行きの宇都宮線でグリーン車にのって新書を2冊読んできた。そのうちの1冊がこれ。かなりオススメ。

脳が冴える15の習慣―記憶・集中・思考力を高める
築山 節
日本放送出版協会 (2006/11)
売り上げランキング: 2507
おすすめ度の平均: 5.0
5 具体的でわかりやすい良書
5 インスタントではないが、効果が出やすい
2 期待はずれ

すごい目新しいことが書いてあるわけではないが、それゆえに日常生活ですぐに活用できる。
特に身にしみたのが以下の二つ。

「習慣2 集中力を高める」の中に書いてある、脳の基本回転数の話。基本回転数(集中力や素早い頭の回転)は上げようと思ってもいつでも上げられるものではなく、ウォーミングアップをしたり、時間などの制約を課したりすることが重要という話。確かに上手く行っているときはここに書かれているような習慣を実行しているし、だらだらしちゃうときの例も自分にぴったり当てはまる。

それから、「習慣4 脳の持続力を高める」の中の前頭葉を鍛えると言う話。面倒臭くって中々実行に移せない、実行に移しても乗り切れなくてすぐに休憩してしまう、そんな怠け者体質の私にはぴったりの内容だった。

その他にもためになる話がいろいろ。
この本を読んで、目新しいことがないために「当たり前の話じゃん」という人もいると思う。
でも、根拠も示しながら当たり前のことを説明していて、自分が何をすればどんな効果があるのか良くわかる。
当たり前だと思っていてもできてないこともたくさんあるし。

新書で安いし、読む価値ありだと思う。

| 07-06-28 15:19 | コメント (1) | トラックバック (1)

MacBook欲しい(独り言)

ノートPCがなんとなく欲しいんだけど、MacBookに惹かれる。
Macデビューか?

Proは必要なさそう。
普通のMacBookの真ん中のモデルくらいで十分かな。

買ってしまうか?
どうしよう。

| 07-06-28 11:14 | コメント (1) | トラックバック (0)

先週からの勉強進捗

Djangoの認証関連機能の復習。
ユーザー登録・認証はとりあえず動いたっぽい。

デザインはやっぱり無理。
動けばいいということにする。

初jQuery。
dom操作とAjax関連機能とjson.js。
こんなところで今回は足りそう。
全体的にシンプルで使いやすそう。

というわけで「Djangoで簡単なサービスを作るよ。来週までに。」なんていったものの遅れ気味。
この辺が怠け者クオリティ。
「来週まで」というのは「来週いっぱいで作る」の意味だったということにしよう。

言い訳すると先週末から風邪気味で、土曜日は空手の稽古で、日曜日は栃木まで遠征して審判で・・・。

言い訳は置いといて、何か一人で作るときには休日 or 深夜を使って動くところまで一気に作るのが良いと実感した。だらだらすると、形ができるまでの時間が長すぎる。

| 07-06-26 12:03 | コメント (0) | トラックバック (0)

アジャイル導入も難しいけど、要件定義ですべてを決めろはもっと難しいかな。

おととい「アジャイルな要求管理って難しそうだな」というエントリーを書いたが、それを実感するような記事があった。
「こんな状況確かによくあるよな」という内容。

定まらない要件、ユーザーからのむちゃな要求 - @IT自分戦略研究所

(2ページ目)予算が決まった後からできるだけ多くの要求を出し、少しでも多くの機能を実装させようというポリシーの持ち主だったのです。「これも当然やってくれるんですよね?」というひと言に、これまでも多くのメンバーが泣かされていました。

開発者の視点から書いてあるので一方的な物言いではあるが、確かにこういう顧客担当者はいるだろう。
そしてこれに対する対応は、要求のあるべき姿を考えて実際には必要ないということを顧客担当者に分かってもらった・・・というものだ。

もし、本当に必要なものだったらどうしたんだろう?
予算や品質とのトレードオフを突きつけて、ここまでやらないほうがお客様にとっても良い方向になる・・・なんて話をするのが目に浮かぶ。

使う前から、本当に必要になるかどうかをどう判断するんだろう。
システム化+新業務フローをほぼ同時にスタートさせたいときなど、事前の要件定義ですべてを最良の形で決めきれるとはとても思えない。
もちろんベストエフォートで、それなりに良いシステムができるように要件定義するんだけど。

この筆者の場合は、顧客の立場から本当に必要なものを判断していいシステムを作ったのだろうけど、やっぱり構造的に無理があるよな。

実際の開発現場では大きなウォーターフォールが未だに多く、こういう状況は日常茶飯事だと思う。
これを意識改革して、アジャイルなどの新たな考え方に持っていくのは、難しいのが分かっていても取り組んでいくべきだと再認識した。

@ITの記事の趣旨とは違う感想だと思うけど。

| 07-06-22 22:26 | コメント (0) | トラックバック (0)

携帯サイトの文字コードってUTF-8だとどれくらいまずいの?

djangoで携帯サイト。(UTF8以外のエンコードでサイト公開)を見て、素朴な疑問で思ったんだけど、携帯サイトをsjisで作らないとどれくらい問題があるんだろう?

一部の古い携帯で閲覧できなくなるのはわかる(※)。
それって実際ユーザーの何割くらいいるんだろう?
携帯サイトを良く使うようなユーザーなら、そんなに古い携帯使わないんじゃないかとも思う。

Google Calendarを携帯で閲覧できる簡単な仕組みをUTF-8で作って仲間内で使っているが、見られないという話も聞いたことないし。

古い携帯が対応していない以外の問題は何かあるのかな?
仕事で作った携帯サイトは全部sjisだったし何も疑問はなかったんだけど、急にutf-8でダメな理由がそれほど無い気がしてきた。

どうなんでしょう?

※素晴らしいまとめがあった ⇒miniturbo::Memo - 携帯電話での文字コード対応表 まとめ

| 07-06-22 13:23 | コメント (0) | トラックバック (0)

アジャイルな要求管理って難しそうだな

JavaWorld Day 2007 - アジャイル開発の伝道師が明かす、プロジェクト成功の秘訣 | マイコミジャーナルを読んだ。
参考になる話が書いてあったが、このままじゃ実現は難しいなあと感じたことを書いてみる。

何が難しいかってこれ。

アジャイルな要求管理(Agile Software Requirements Management)

アジャイル開発では、個々の要求に優先順位を付け、優先度の高い順に開発に取り組んでいく。開発の初期段階ですべての要求をモデリングするウォーターフォール型プロセスとは異なり、情報が揃った段階で分析ができるため作業を効率的に進められる。「要求の変化に柔軟に対応できるため、競合優位性につながる」(Ambler氏)という。

これを実現させるためには、顧客の継続的なコミットが必ず必要。要件を決めたら自分の役目は終わり、あとはシステム屋さんが作るだけと思っている顧客じゃ難しい。
常に要求の優先順位付けを行いながら、出来上がったもののチェックをしてさらに改善案を検討して・・・というのを継続しなきゃいけないわけだ。
アジャイルではないけど似たような開発スキームを取り入れた例で、開発側とシステム部門は「忙しさは通常のウォーターフォールと変わらない or 楽になった」と言っているのに対して、要求の出し元は「明らかに大変になった」と答えていたのも聞いたことがある。

現在のSIなどの受託開発に構造的問題があるというのは分かるが、それに慣れてシステム開発を自分たちのものだと感じていない発注側の意識改革も当然必要になる。
アジャイル開発導入にあたって、一番高いハードルはここなんじゃないかと思う。

開発側の人が顧客(システム部門じゃなく要求の出し元)に非常に近い位置に入り、顧客の視点・立場でプロジェクトを引っ張るくらいになれればこのハードルも越えられるのかな。

| 07-06-20 10:26 | コメント (0) | トラックバック (0)

怠惰な人のための資料整理方法

紙の資料や書類を上手く整理して取っておくことが苦手。
きれいにファイリングして取っておこうとしても、必ず途中で挫折してしまう。
結果的に初期検討の資料だけきれいに揃っていて、大事な資料はファイリングされていない状態になる。

ただし、あるやり方が身についてからは頭を悩ませることが少なくなった。
単純にきれいに整理することをあきらめたということなんだけど。

方法はこれだけ。
「使った資料を上に積み重ねる」
シンプルで何も悩むことがない。これは楽。
資料はとにかくスタックの上に置くだけ。高くなりすぎたら下のほうから捨てればよい。

最初はめんどくさくなって積み重ねているだけだったんだけど、これで何も困らないことが分かった。よく使うものが上にあって仕事がしやすくなったくらい。

もう少し詳しくいうとこんな感じ。

  • 書類は上に積み重ねていく
  • 書類の分類にはあまり悩まない
  • 一まとまりに保存したい資料はクリアファイルに入れて積み重ねる
  • スタックの中の資料を使っても一番上におく
  • 紙の高さが気になったら一気に捨てる
  • 上のほうに積まれている必要そうな資料だけは捨てないでおく
  • どうしても大事な書類はさすがに別の場所に保存しておく(ほとんど無いけど)

番外編で以下の二つも有効

  • 電子データで保存する
  • 同じ会議に出ている資料整理が得意な人を覚えておく(いざとなったらその人に借りることにする)

セキュリティの都合上、机の上に資料を置いてはいけない場合も、深めの引き出しを書類スタック用に使えばいいと思う。

| 07-06-20 09:04 | コメント (0) | トラックバック (0)

Djangoで簡単なサービスを作るよ。来週までに。

重い腰が上がらず、最近全く手を動かしていない。勉強記録を残そうと思って立ち上げたブログも活用しきれていない。
怠け病が発病しっぱなし。

ということで無理矢理宣言して作ってしまおうと思う。

基本的に自分用便利ツールだけど、無理矢理公開するっていったほうがモチベーションがあがるのかな。
自分を追い込まないとまたダラダラしそうだから、ドメインまで取ってしまった。

少なくとも来週までに自分で使える状態にはする。上手く行けば公開するかも??

課題は全くセンスのないデザインと、認証周りかな。

| 07-06-19 11:03 | コメント (2) | トラックバック (0)

niftyのアバウトミーに登録してみた

モノはためしと言うことで。

mixiからは落ちこぼれてる(※)けど、これくらいライトな感じだとありかもしれない。

学生時代に始めてプロバイダと契約したのがinfoweb。それからずっとniftyなので、ニフニフ動画なんてやってたとしても心情的に応援したい。

※ 随分前に登録したけど使ってない。日記の馴れ合いっぽいのを見てついていけなくなった。基本的に不精なんだな。

| 07-06-18 10:12 | コメント (0) | トラックバック (0)

全て |  1  |  2  |  3 

« 2007年5月   2007年7月 »