2008年5月31日土曜日

わかる人だけには貴重な映像

今はなき西ヶ原のキャンパスが...

10年前くらいでしょうか。わかる人にしかわからない、とても貴重な映像。

mixiの日記から発見しました。

YouTube - GOMES THE HITMAN "tsubomi"


サークル棟の階段下のピアノとか懐かしい。

これで見るだけでも校舎やサークル棟は十分汚い感じですが、個人的にはもっと汚い印象を持っていました。ちょっと片付けた感じが見受けられる。

映っている人の方も個人的には相当懐かしい。

でも彼らの最近を知らないせいか「若い!」とは思わなかった自分に驚いた。

2008年5月28日水曜日

これはいい!Programming First Development

これはいいなあ。
Developers [Test] Summit 2008(デブサミTest)で、ひがやすを氏が紹介したというソフトウェア開発方法論「Programming First Development」。

「テストをすべきなのは知っているが,現実にはできない」という現場の状況をいかに打破するか,気鋭のソフト開発者とテスト技術者がパネル討論:ITpro

この方法論では,要件定義のあとにドキュメントを書くのではなく,いきなりプログラミングしてしまう。プロトタイプではなく,本番で使うプログラムの8割くらいを作ってしまうのである。紙で書いた仕様書をユーザーにレビューしてもらう代わりに,プログラムを動かしてユーザーが実際に触ることで動作を確認してもらう。保守に必要な基本設計書や外部設計書は後で書く
プログラミングの際には,実装優先でとりあえずテストは考えない。シナリオ・ベースでテストしていき,バグを発見したら,その周辺でユニット・テストを書く。「バグは偏在していることが多い」(ひが氏)からだ。
「大規模開発ではどのように作業を分割するのか」。これに対しひが氏は「上流の開発者と下流の開発者を分けてしまうと,コミュニケーション・ロスが生じる。一つの機能やユースケースを小さなチームに割り振り,最初から最後まで担当するようにすればいい」と答えた。
プログラムは想像で書いたドキュメントより価値が大きい

これは今まで言語化していなかったけれども、私がいつもとても効率的だろうとイメージしている開発手法にかなり近い。感覚的にはそういう作り方していてもプログラミングをしながら、かなりのホワイトボックスなテストをしているのであって、要するにユニット・テストに関わるドキュメントにかかるコストが耐え難いのである。それに要件定義からプログラミングまで全部に関わりたいなんて言う私にはまさにうってつけである。

「今はSEとプログラマが分かれているのが問題。プログラミングを知らない人が仕様を書くから,実装できない仕様が生まれる。あるいはプログラマが言われたことをそのまま作るだけになってしまう。この状況を打破するには,仕様を考える人とプログラミングする人を同じにしなければならない。1人でできるようになれば全体の工数は減るので,月300万円程度まで単価を上げられる。人月が悪いわけではなく,人月でも単価が高ければいい」

これも大いに同意したい。

ついでにコメントしておくと、私としては「プログラマが言われたことをそのまま作るだけ」になる事の方が罪というか問題が大きい気がする。

SEがプログラミングを知らないなんて事があるのか?という気もしますが、まあプログラミングを知らなくても論理的な思考力・分析力があれば、まともな仕様は書けるのではないかとも思う。
もちろん実際にどれ程そうできる人がいるのかは別だし、プログラミングを知っている人とはちょっと違うコミュニケーションが必要になるかもしれないが、必ずしも悪い話ばかりとは限らないと思う。

それに対してプログラマが言われたままに作るだけというのは、その仕様の業務的な意味を理解しようとしていないという、ある意味で思考停止な状態なわけだ。少なくともエンタープライズなシステム開発においては最低な話である。

その際立った例がいわゆる「IT土方」的にプロジェクトに投入されるソフトウェア開発の初心者なんだろう。
まあ、そんな初心者では「言われたことをそのまま作ることすらままならない」場合もとても多いのだけれど。建前としては彼らがユニットテストを終えた事にしておいて、後のフェーズでほぼ完全に書き直す事もあったりする。

そんな現状を打破し、要件定義からプログラミングまで(少数)精鋭だけで遂行できるプロジェクトがあったら、どんなに楽しく有意義だろうと思ってしまう。

内容はちょっとズレるのかもしれないが、机上の「想像」だけで仕様を固める「ウォーターフォール」な開発手法(及びプロジェクト遂行管理)をいつまで続けていく気なのか、と時々思う。

できる事なら私もこの「Programming First Development」を実践できるようになりたいと思う。

2008年5月26日月曜日

ノウハウ本でも読んだら悩む

これって私にとっては高校生の時に起きた事だなぁと直感的に思いました。

ノウハウ本を捨てよ、悩む力が閉塞を打ち破る:NBonline(日経ビジネス オンライン)

ここ数年、自殺者がものすごく多いでしょう。この10年で30万人が死んでいる。
悩み抜いて、突き抜けると、人間は必ず“横着”になれる。横着になった時、意外と死ぬなんてばからしい、もっとこんな生き方をしてみようか、という考え方になるんじゃないでしょうか。ここで言う横着とは、「悩み抜いて怖いものがなくなる」という状況と同じと考えてもらっても構いません。

私の場合は現実世界の具体的な悩みというよりは、もっと哲学的というか、「何の為に生きるのか?」みたいな事をくどくど考えていた。

結局それに対して明快な答えは出ていないが、とりあえず「自殺だけはないな」と高校生当時にはっきり思った。
死んだ後に自分ができる事なんて想像がつかないし、せっかく生きているのだから、いろんな事を経験して楽しい思いをした方が得じゃん、くらいに開き直った。

そう思ってからは、なるべく顔は下ではなく上に向けるように心がけるようになった。
上向き過ぎで、写真を撮られる時に「あごを引け」とか言われることもあったけど。

とは言っても「好きを貫く」みたいな覚悟を決めたわけでもないから、結局は流れるままになんとなくここまで来たという感じになっているのが現実だったりする。

ノウハウ本は雨後のたけのこのようにありますが、悩んで悩んで、自分の中にある力を見いだしてほしいですね。

最近は「ノウハウ本」みたいなものもよく読むけど、自分に合うもの、納得がいくものだけを都合よくピックアップして自分に応用するのは、悩み考えているからこそできる事だと思う。

だから、ノウハウ本を読まない事にこだわる必要はない。
考えるネタの一つとして利用すればいいし、その方がよほど効率がいいと思う。
考える事自体は目的ではなくて、考えた結果として自分が起こす行動が重要だと思うから、その過程で使えるものは使えばいいと思う。

それはそうと元記事で肝心な本の方はまだ読んでいません。すいません。

TOEIC 2008/05

昨年10月以来でTOEICを受験してきました。

今回の会場は近かったのでよかった。だいたい30分くらいで着いた。

テストの結果は今までとあまり変わらないのかな?という感じがします。
相変わらずリーディングは最後の10問くらいは答えの記入すらできなかった。

ただ、試験終了後の感覚に大きな違いがあった。

過去に受験した時は、試験終了後は脳がすごく疲れた感覚があったけど、今回はそれが全くなくて試験終了後も頭はすごく快適な感じでした。
終始リラックスしながら集中するという事ができていたのかもしれません。

通勤中にpodcastのいろいろな英語番組をかけて英語に耳を晒しているので、英語からストレスを受けにくくなったのかもしれないし、もしかしたらリラックスしながら集中するというのはフォトリーディングの練習の効果かもしれない。

まあ、実際のところはよくわかりませんが、これからも特別な試験対策などせずに時々受験してみるという事を続けたいと思います。

2008年5月24日土曜日

フォトリーディング練習中

最近「フォトリーディング」の練習をしています。それがブログの更新が滞りがちになっている言い訳の一つでもあります。

これは勝間和代さんの『効率が10倍アップする新・知的生産術―自分をグーグル化する方法』を読んで実践してみようと思った事の一つです。
勝間さんはセミナー受講を勧めているのですが、フォトリーディング公式サイトを見ると公開されているスケジュール上はほとんどが満席で2ヵ月先くらいでないと受講できそうになくて、「そんなに待っていられんなぁ」と思って『ホームスタディ講座』を購入してしまいました。

実はそれは今年の2月ごろの話で、申し込んですぐに家に届いたものの手をつけられないでいました。
CDで講義を聞きながら進めていくのですが、ところどころに出てくる演習をちゃんとやろうと思うと、ある程度の落ち着いて取り組めるまとまった時間が必要なので、1枚目のCDを終えた後はなかなかスタートが切れないでいました。

2月に申し込んでおけば受講できたはずの時期もとっくに過ぎて、また後で気づいた事で「満足保証」なんてものもあったようなのですが、その期間もとっくに過ぎて3ヶ月がたった頃、「いい加減、まずいな」と思いました。
そこで、進め方の形にこだわっていても仕方ないという事で、とりあえずガイドブックや学習ガイドのDVDを一通り見てビジュアルなイメージを掴んでおき、後はCDの内容を全てiPodに入れて通勤時間に電車で聞くようにしました。最初の方で「演習は必ず実施して下さい」なんて指示もありますが、とりあえず無視してひたすら電車の中でCDを聞き続けるようにしました。

そんなふうにして一通り聞いてみると、なんとなく全体像が見えてきました。
すると、頭に残っている内容だけでも実際に本を読む時に試せるようになり、そうする事でより細かい内容を振り返るためにガイドブックや『あなたもいままでの10倍速く本が読める』をポイントだけ読み返したりするようになる。そうして徐々にわかってきた感じがして、日々練習できるようになりました。

結果的にはこの『フォトリーディング・ホームスタディ講座』自体を「フォトリーディング・ホールマインド・システム」的に取り組んだ事になったように思います。

セミナー受講した場合の教材がどんなものかは不明ですが、今の私くらいの感覚まで持てるのなら、何度でも繰り返し聞けて費用も比較的安い『ホームスタディ講座』はお得な気がします。もちろんセミナー受講ならではの講師や他の受講者の人達とのインタラクティブな効果もあるのだろうとは思いますが、別にそれは目的ではないと思いますので。

今のところはまだ練習中で本当にそんなすごい効果があるかどうかはよくわからない感じです。
潜在意識をうまく活用できているかどうかなんて事を、顕在意識的に理解するとか実感を得る事自体が矛盾しているようにも思えるので、そんな事が実感できる日は一生来ないのかもしれません。

ただ少なくとも、文章を読むスピード自体は確実に以前より速くなった気はしていますし、まず大まかにも全体を捉えた上で各論の詳細に入っていくというやり方が、人間の情報処理の方法として効率がいいという事を認識できただけでも大きな違いだと思います。

勝間さん自身がセミナー受講した時の感想がまとめてありましたが、今の段階で特に共感できるのが以下の2点です。

日々の生活から起きていることを観察しよう!!: フォトリーディング・セミナーに行ってきました その2

誤解1-フォートリーディングをすれば、本の内容がすらすらーーーーと頭に入るようになると思っていた
実際-フォトリーディングは、「滑りをよくする」、すなわちなんとなく知っている、というデジャブ感をつけるためにやるものだった。
誤解4-フォトリーディングでは文章への読解力が飛躍的に上がるのかと思っていた。
実際-読解力そのものを上げるのではなく、「本はもっとテキトーに読んでも大丈夫なんだ」という考え方を教えてくれるものだった。

というわけでこの『フォトリーディング・ホームスタディ講座』自体もかなりテキトーに扱っています。
今の所、マインドマップは一度も書いてみた事はない。1冊の本を読んだだけではいちいちマインドマップなんて書いていられないというのが、正直なところです。

ただ、仕事上でとるメモなどは見よう見まねでマインドマップ的に書いてみたりはしていますので、マインドマップは別のテーマとして勉強してみようと思っています。

そういえば、まずはきっかけとなった『効率が10倍アップする新・知的生産術―自分をグーグル化する方法』をもう一度フォトリーディングで読むべきなんだろうな。

2008年5月20日火曜日

プログラミングよりアプリ開発か

自分はどっちかな?と思って、軽めにエントリ。

404 Blog Not Found:プログラミングとアプリ開発の違い

プログラミングをしたいのか、自分が作ったプログラムを使わせたいのか。それが問題だ。

基本的には両方楽しめると思うけど、どっちかと言えば後者かな。
別に使うのは他人ではなくて自分自身でもいいんだけど、要は役に立つものとか便利なものが作りたい。
リアルに影響を及ぼすような何かの目的がないと、その過程の楽しみも半減するという感じかな。

仕事上のSIer的システム開発プロジェクトで言えば、要件定義からプログラミングまで全部に関わりたい感じになる。

2008年5月18日日曜日

トラブルゼロなんてありえないけど

細かい事情は知りませんが、これには私も同感。

三菱東京UFJ銀行のシステム障害? いったい何の話だ:東葛人的視点:ITpro

完璧を期すのは、とてつもなく難しい。この程度で済んだのだから、よしとすべきである。

なぜかと言えば、

6000人が作ったシステムは必ず動く:ITpro
最盛期の開発要員6000人,開発工数11万人月,投資額2500億円,取引件数1日1億件。三菱東京UFJ銀行が「Day2」と呼ぶ,勘定系システム一本化プロジェクトの成果物である。6000人のシステムズエンジニア(SE)が作り上げた巨大システムは,2008年5月の連休明けに必ず動くはずだ。

これだけ多くの人間が関わった巨大なシステムにおいてトラブルゼロなんてありえない。
もちろんトラブルが起きているとしても、そのシステムは動いている。
システムが動くかどうかという話とトラブルがゼロかどうかという話は別の事である。

とは言うもののさすがにこれは無理だろうな。

三菱東京UFJ銀行のシステム障害? いったい何の話だ:東葛人的視点:ITpro
今回の件で、三菱東京UFJ銀行に罪があるとしたら、利用者に対して事前に“自衛”を求めなかったことだ。「新システムへの移行に伴って、障害が発生する可能性があります。利用者の皆さんにおかれましては・・・」と告知しておけば、“完璧”にOKの話だ。

これは「情報リテラシー」とはちょっと違うと思うが、システムの不具合は十分ありうるという事が利用者側の「常識」として、言われなくても「自衛」を意識できるようになった方がよいと思ったりもする。でも、それはそれでもっと難しい事だろうけどね。

もちろんシステムを作る側のエンジニアとしては、「ソフトウェアにバグはつきもの」なんて事が「常識」として一般利用者にまで浸透してしまうような状況に甘んじていたくはないだろう。

でも、システム開発というのは完成した後の利用者が享受する利便性とは裏腹に、人手の作業への依存があまりにも大きい。そして、そんな状況は当分改善しそうにない。
様々なサービスにおいてコンピュータシステムが一般人にも直接関わるようになり始めた時代においてはある程度仕方のない事かなと思ってしまう。ここでいう「時代」とは結構長いスパンをイメージしています。コンピュータというものができてから、まだ数10年しか経っていないんだぜ。くらいの感じで。

で、そんなある意味での「屈辱」もバネにしながら、努力して一つ一つの問題解決していく事を地道にやっていくしかないのだろうなと思う。

404 Blog Not Found:(6000)人が作ったシステムは必ずどこか壊れている
誠実であるとは、失敗しないことではない。失敗を防ぐこと、失敗してもそれが致命的にならぬようにすること、そして失敗を直ちに修復することである。ソフトウェアであれば、バグが出にくくすること、バグの影響が全体に波及しないようにすること、そして直ちにデバッグすることとなるだろう。

こういう事ですね。うまく言語化されました。忘れないようにしたいです。

また余談ですが、

三菱東京UFJ銀行のシステム障害? いったい何の話だ:東葛人的視点:ITpro
まあ、IT業界にとっては想定外の特需だったので、それでよかったとも言える。ただ、バンキング・システムという、ほとんど何の付加価値も生み出さない“巨大な金庫”にバカみたいなコストをかけて、いったいどうするのか。そんなカネがあるのなら、預金金利を上げるなり、手数料を下げるなりして、預金者に還元した方がよっぽど社会的責任を果たしたと言える。

 それに、こんな余計な手間のために、IT業界の優秀な技術者を強烈にバキュームし続けた。そのしわ寄せは、金融業界のシステム開発をはじめ各方面に及んでいた。きつめに言えば、社会的に付加価値のない金庫システムの余計な作業のために、社会的に意味のあるシステムの開発機会を奪ったわけだ。

確かに相当な特需だよね。ここ数年の景気回復とも重なって各方面での技術者不足には直接的にも間接的にも大いに影響していただろうし、その影響で思わぬ方向に人生が変わった人もいるんだろうな。
そして、このプロジェクトに吸い込まれていたエンジニア達が今後続々とリリースされていく事になるはずで、自分の仕事にも影響するかもしれない。でもその影響を顕在的に認識できることはめったにないだろうけど。

「優秀な技術者」は常に人手不足なものだからね。

2008年5月17日土曜日

双子の少女の片方がもう片方の胃袋の中で発見

すごい事があるもんだ。

livedoor ニュース - 双子の少女の片方がもう片方の胃袋の中で発見される

胃痛に苦しんでいる9才の少女を診察したところ、長さ約6センチメートルほどの胎児が彼女の胃の中にいることがわかったとのこと。この胎児はいわゆる双生児として本来は生まれるはずだったのに、もう片方(=現在9才の少女)に子宮内で吸収されてしまったらしい。これは50万分の1の確率で発生する現象だそうです。

ただ私としては、この事象そのものよりも、なぜ9才になるまでわからなかったのか、という事の方が不思議に思うのだが。

2008年5月16日金曜日

SIerの技術者の管理業務

少し前の記事ですが、感覚的にはすごくよくわかる。

第6回 SIerのジレンマ:ITpro

とにかくいつも思うのは,現場で使える人は常に“疲弊”しているということ。「仕事が集中するから当たり前」というとそれまでだが,集中する仕事の内容が問題だ。やはりSIerは,技術よりもPM(Project Management)力が求められるので,ある程度技術力があると「もう技術は卒業ね」と言われ,管理業務がふられることになる。

 技術力がある人は,基本的にスマートなので事務処理もそつなくこなす。しかし,決裁や文書管理,はては新人の受け入れなど,SIerには際限なく事務処理があるので,すぐにオーバーワークになる。そのため本業がままならない。

 一方,技術力が無い人は「最低限の技術力をつけようか」と技術習得に集中できる。さらに技術力が無いため,即戦力ではない印象(まかせたら危なっかしい的な印象)しか与えないので,事務処理をまかせられることも無い。さらに先輩からのアドバイスで「わからなかったらアイツに聞けよ」と言われるので,技術力のある人の仕事を増やし,自然と彼らの進捗を妨害してしまう。


そんなに大きなSIerにいるわけではないし、自分で言うのもどうかとも思うが、私も以前は「現場で使える」が故にオーバーワークで常に疲弊している人だった気がする。
しかも「もう技術は卒業ね」なんて事はなく、むしろ技術力でも牽引役でいる事が求めらるそんな立場になってしまった。
しかし、この数年でいろいろ学んで、管理業務が自分の負担にならないようにうまくこなす、場合によっては「かわす」こともできるようになってきたと思う。
もちろん、自分がそうしていられる事を許容できるプロジェクトの現場の状況にも助けられてもいる。
またデスマーチプロジェクトに陥ったりしたら、そんな悠長なことは言っていられないだろう。

それに、どうも「管理業務」と「事務処理」が一括りにされているけど、それってちょっと違うよね。
「事務処理」はその名の通り事務的に余計な事は考えずにさっさと片付ければいいだけだ。
でも、「管理業務」と言ったら、そういう事務処理ももちろん含まれるのだろうが、それよりもむしろ、現場の状況把握にアンテナを張り、問題の改善の為に知恵を絞る事が重要だ。なので、技術力や実務能力の高い人でなければこなせるはずもなく、「できる人」に任せられるのは当然の話なのだと思う。(だからこそ「SIerのジレンマ」なんだよね。)

そんな中で自分自身の技術力の向上が思うようにできない事へのフラストレーションは確かにある。
でも、そこには自分自身の「技術力の向上」に対する考え方の問題があるような気がする。
新人の頃と同じくらいの貪欲さとスピードを持って自分にとっての新しい技術を吸収していけない状況に対する苛立ちなのではないかな、と。

そりゃあ、あの頃と同じようにやるのは無理だよ。
取り組むべき問題にははっきりとした正解がないものが増えてくるから、バグを直してプログラムが正しく動くようになった時のようなはっきりとわかりやすい爽快感がない。それがフラストレーションになるんだよ、たぶん。
正確には「はっきりとした正解がない」のではなく、「正解に至る為の方法がいろいろあり過ぎる」という事だろう。

もう一つの問題はたぶんこれ。
これに対して技術力のある人は,当初の期待に対して,本業以外の負担で成果が削られているにもかかわらず「こんなもんなの?」と思われる。

技術者の業績としてどう評価するのか、という事だろう。

自分の今後の方向性を考える上でも重要なテーマなので、もうしばらく考えていきたいね。

2008年5月5日月曜日

IKEAのテーブルとチェアの組み立てに思う

先日IKEAで買ったテーブルとチェアが届いたので、組み立てをしました。
かなり安いものを選んだつもりですが、それでもちゃんとした木なので(?)結構重い。

こんな記事があるとは。
IKEA HACKS ~ 激安&快適インテリアライフのすすめ ~ | IDEA*IDEA

さて最近IKEAづいていますが、いろいろ細かい失敗もしているのでw、ここらへんで「IKEA Hacks」をまとめておきます。

IKEA初心者の方はよろしければ参考にしてみてください(IKEA常連の方はスルーで・・・)。

事前に読んでおけばよかったです。
でも、これからもしかしたらIKEAづくかもしれないので、もう一度目を通しておきたいと思います。


ところで、店にいる時も思っていたけれど、基本的には全てがセルフサービスというかセルフヘルプなのだが、店側は客がいかに快適にセルフヘルプできるか、に注力している、というそんな印象を受けました。

配送料も結構高いという印象。これも基本的には「自分で車で持って帰って下さい。」なんだよね。
そりゃあ、もちろん自分で車を持つコストに比べたら全然安い。当たり前だ。


人生も基本的にはセルフヘルプなんだよね。

かなり唐突ですが、以前にこんな記事があったのを思い出しました。

Somewhere in a Way to Nowhere: 「自助」の定義に納得
404 Blog Not Found:社会を使って自分を助けろ
「自助」というのは自給自足をすることではない。自分が必要なだけ社会を使い、その社会を維持するのに必要な分だけ社会に使われることのことである。

IKEAにおいても、自分自身のインテリアの計画を立てて、必要なものを自分で揃える。必要があれば店員を見つけて問い合わせる事もできるが、基本的に店員側からは何もしない。社会の有り様そのものが、ショッピングのスタイルに適用されている。
もちろんIKEAの場合、「維持するのに必要な分だけ使われる」というのはお金を払う事にほかならない。

2008年5月4日日曜日

足でギターを弾く

たまたま見てみた「Steve Jobs」のブログに載ってて見つけたのですが、これはすごいす。

YouTube - amazing guitar player


手でもこんな風には弾けないかもしれない。それは練習不足でしかないけど。

『ウェブ時代 5つの定理』とSteve Jobsのスピーチ

梅田望夫氏の『ウェブ時代 5つの定理』を読みました。
本当はだいぶ前に読み終えていましたが、なかなか感想が書けずにいました。

これだけ様々なビジョナリーたちの言葉を意識して集めるだけでも大変な事なのに、タイトル通り「5つの定理」という軸に沿って整理するのはもの凄く大変な作業だったろうなぁと思います。

そのおかげであまり労せずに様々な金言に触れる事ができます。

読後の率直な感覚としては、とにかくスティーブ・ジョブズが目立っていました。
Googleも「第4定理 グーグリネス」と1章を割いて書かれているのだけれども、最も印象に残ったのはスティーブ・ジョブズという感じでした。

特に最後に取り上げてたという事もありますが、2005年のスタンフォード大学の卒業生向けのスピーチの言葉ですね。

P.256-257

君たちの時間は限られている。
その時間を、他の誰かの人生を生きることで無駄遣いしてはいけない。
ドグマにとらわれてはいけない。
それでは他人の思考の結果とともに生きることになる。
他人の意見の雑音で、自分の内なる声を掻き消してはいけない。
最も重要なことは、君たちの心や直感に従う勇気を持つことだ。
心や直感は、君たちが本当になりたいものが何かを、
もうとうの昔に知っているものだ。
だからそれ以外のことは全て二の次でいい。--スティーブ・ジョブズ

Your time is limited, so don't waste it living someone else's life.
Don't be trapped by dogma — which is living with the results of other people's thinking.
Don't let the noise of others' opinions drown out your own inner voice.
And most important, have the courage to follow your heart and intuition.
They somehow already know what you truly want to become.
Everything else is secondary.-----Steve Jobs



そして、もう一つ別の言葉も紹介した上で、

P.258-259
ジョブズのこの二つの英文は、何度も読み返して、覚えてしまってもいいと思います。そして興味を持ったらネット上で日本語訳の全文を読み、英文オリジナルを読み、録画映像も見るといい。そこから必ずや何か得ることがあると信じます。


というわけで「Steve Jobs」でググればすぐに見つかりました。

YouTube - Steve Jobs' 2005 Stanford Commencement Address


で、こちらがその英文。上のYouTubeで聞くのとは微妙に言い回しが違う所が時々あります。でも、大筋では全く問題ありません。シャドーイングなどにも使えるかもしれません。

Text of Steve Jobs' Commencement address (2005)

スピーチの最後を締めくくる言葉が以下の通り。
Stay Hungry. Stay Foolish.

そうか!これはこのスピーチだったのか!

Stay Hungry. Stay Foolish.

I also wish that for myself.

2008年5月3日土曜日

引用文のスタイルを設定

引用文である事をわかりやすくする為に、本文中の<blockquote>タグのスタイルに枠線と背景色を設定してみました。

引用文はこんな感じになる。

ただし今までの記事の大部分では強調(<em></em>)による斜体も設定していた。
なのでこんな感じなる。

こうなるとかえって、うざったい感じかも。

でも、それを直すには各記事を編集しないといけないで、とりあえずいいかな。

また一つ学習したという事で。

2008年5月2日金曜日

4月のミュージックランキング

今月も個人的なミュージックランキング。
相変わらずランダムシャッフルの結果なので、特別な意味はありません。
リンク先もAmazonで、曲名の方は収録されているアルバムへのリンクです。
ちなみに先月はこちら

1位: Hey Lord! by Helloween

1位: To Be With You by MR. BIG

3位: Paul's Solo by MR. BIG

3位: Generation Jedi by Fair Warning

3位: Dancin' Right Into The Flame by MR. BIG

...

しかし、古いなぁ。10年以上前から聴いているものが何も変わっていない感じだね。

2008年5月1日木曜日

4月の記事別アクセス状況まとめ

Google Analyticsによる本blogの4月の記事別アクセス状況(ページビュー)をまとめました。
ちなみに先月分はこちら


  1. Bloggerでトラックバックをできるようにする (2008/04/20)

  2. Google 急上昇ワード (2008/04/23)

  3. 「婚活」時代 (2008/03/09)

  4. Oracle 11g をインストールしてみた (2008/01/28)

  5. UNION と UNION ALL の違い - SQL (2008/02/18)

  6. 「成功本」を読む (2008/04/17)

  7. スーツを着る理由 (2008/04/19)

  8. 『成功本』の著者よりトラックバック (2008/04/28)

  9. 就職氷河期世代の自己責任 (2008/03/01)

  10. mixiがつまらない理由 (2008/02/14)


1位の「Bloggerでトラックバックをできるようにする」は、自分自身でblogのテンプレートをいじりながら何度も表示させて確認していたので、それがかなりカウントされてしまっていると思われます。

なので実質の1位は「Google 急上昇ワード」なのかと思います。
これはGoogle Japan Blogの記事でバックリンクが一番上に載っていたのが影響しているようです。
記事自体には大した事は書いていないので、すぐに戻ったり別のサイトに行ってしまうようですが、、、
バックリンクが載るのはわかっていましたが、これほどアクセス数に影響があるとは思いませんでした。

新しい記事ではないのですが、OracleやSQL関連の記事へのアクセスが結構増えました。
新人さんなどが調べる為にググっていたら、たどり着いた感じでしょうか。

何より4月のトピックといえば、『成功本』の記事について、著者本人のblogにリンクが紹介されて、トラックバックも頂いた事でしょう。

この1ヶ月でずいぶんblogっぽくなってきた感じです。