無料ブログはココログ

« 2006年6月 | トップページ | 2006年8月 »

エクセルでカーソルキーがおかしくなる

ここのところエクセル(Microsoft Excel)がおかしくなっていました。カーソル(矢印)キーを動かしてもセルが移動せず、スクロールしてしまうのです。セル移動するだけなのに、マウスを使わなければなりません。エクセルの設定を見ても関係しそうなものはありません。

実はこれは、プリントスクリーン(PrtSC)の横辺りにあるScrLk(スクロールロック)が効いていたのです。「キーボードの特殊キー」なるページを見つけてようやくわかりました。このページからスクロールロックの箇所を引用させていただくと

元々は3270端末でカーソルを移動させないようにするキー。 Excelでは、ScrollLockがオンになった状態でカーソルキーを押すと、選択したセルはそのままでワークシート全体が移動する。

もともとは色々なアプリケーションでスクロールするはずですが、私の使うソフトウェアのうち、まじめに対応したものがエクセルだけだったようです。ほかのアプリケーションで問題が生じなかったので、エクセルの問題だと思ってかなり悩みました。

この機能を使っている人も少しはいるのでしょうけど、結構危険な機能だと思います。

このエントリーをはてなブックマークに追加

仕様からポリシーへ - SS2006基調講演 -

熊本で参加したソフトウェアシンポジウム2006のキーノート・スピーチは九大大学院の安浦先生による「『価値』や『信用』を取り扱うDependableな情報技術に向けて」でした。

話の中心は現金貨幣の情報モデルで、クレジットでもポイントでもなく、現金のモデルのお話で、中州でお金を使ってもばれない、ATMからの認証だけでなくユーザによるATMの認証が必要、生体認証が破られたら鍵を変えられないので非常に危険、などの興味深いお話でした。

しかし、その前振りはもっとインパクトがありました。興味深かった内容をあげると、こんな感じです。

  • 対象が生体、ハードウェア、情報と変化してシステムの不安定性が増大した
  • サービス中心になり、価値や信用の移動速度が劇的に変化した
  • 仕様からポリシーへ:specification-based から policy-based の技術へ
  • ネットワークやファームのダウンロード、外部の変化、局所技術の変化などにより境界が不明確化している
  • 社会情報基盤のグランドデザインとしてわかりやすい原理が必要
  • 「何ができるかより、どうあるべきか」を考えることが重要

このうち、「仕様からポリシーへ」「わかりやすい原理」という考え方は、「アジャイルと規律」の中でベーム先生が「システムのシステム」と言われている、システムが有機的に結合した複雑なシステムを、全体的に整理する方法として有望だと思いました。

また、人の理解できるシステムを作ると言う意味で、リーンソフトウェア開発(決定をできるだけ遅らせるプルシステムできるだけ速く提供するCMM/CMMIの利用)のシンプルルールにつながるものを感じました。

システムを開発する際に、問題を整理することは重要です。しかし、経済性を重視するあまり、すでにあるものをベースにしてしまい、問題をより複雑にしている。そんな私たちに、エンジニアとしてのあり方を問いかけられたような気がしました。

太平燕(タイピーエン) 、御飯の友、酒場通り、山うにとうふ

Taipien 太平燕は、最近、熊本ではやっていてインスタントやカップめんまであり、自治体まで宣伝しているという食べ物です。見た目は麺の細い長崎ちゃんぽんですけど、スープはあっさり、麺は春雨です。四海楼という昔から太平燕をやっている中華料理屋さんでいただきました。

地元の方によるろと、ここはほかのお店より味が薄めだそうです。なお、熊本では、給食に似たようなおかずがあったそうです。熊本太平燕倶楽部なるWebページにも同様の内容が書かれています。熊本では昔からあった料理のようです。

Gohan お土産に買ったのが「御飯の友」、飲み屋のお姉さんに教えてもらいました。もっと今風のパッケージをイメージしていましたが、渋いフォントが良い感じです。いりこと白ゴマの素朴なふりかけです。熊本にしかないそうです。

Sakabast 熊本で残念だったのが、Bar酒場にいけなかったことです。ちょっと体調がすぐれなかったので、今回は少しおとなしくしていました。気にしながら歩いていていると、「酒場通り」を見つけました。引力を感じつつも、今後の課題とさせていただきました。

そうそう、お酒のアテに抜群だったのが「山うにとうふ」。豆腐を味噌に漬け込んだものでまるでウニのような珍味です。鶴屋で売っているそうですが、製造元でも色々な種類が通信販売されているようなのでリンクしておきます。

リレー(させられた)ツバメ

ソフトウェアシンポジウムでは色々な方とお話をしました。そんな中、「リレーツバメは足元が広くてすばらしい」とF先生が言われていて、たしかに狭くはないけれどそんなに広かったかなぁと思いつつ、帰路に着きました。

Tsubame すると熊本からの帰り乗ったリレーツバメの足元が広い!私の短い足では頑張らないと前の席に届きません!なるほど、これだったのですね。息の車両はそれほど広くなかったので、車両によるのでしょうね。

快適なひとときが終わると、厳しい現実が待ち構えていました。乗り換え時間が7分しかないのに4分も遅れました。連絡する列車になっているので、発車を遅らせてくれましたが、

「発車時刻ですが、乗り換えのお客様が乗られるまでお待ちください。乗り換えのお客様がすみましたら、すぐに発車します」

とかアナウンスが流れたら、走らざるを得ないですよね。仕方がないので、博多駅で猛ダッシュ!勘弁してくださ~い、、

九州大吟醸

Kyudai1 国立大学の独立行政法人化に伴い、各大学が特色を出そうと努力されているようです。
Kyudai2_1 国立大学法人になった九州大学では、NPO法人と共同で日本酒を販売されています(詳しくは下記リンク参照)。その名も

九州大吟醸

「九州・大吟醸」でも「九州大・吟醸」でもなく「九州大・大吟醸」のゴロが悪いので、「九州大吟醸」としているそうです。日本酒は西に行くほど味が濃くなっているように思いますが、このお酒は大吟醸らしく、さらっと飲みやすいお酒です。

ネットワークや九大生協で買えるようです(net横丁とか、Yahoo!ショッピングとか)。

Profa_1 SS2006では、A教授の差し入れをおいしくいただきました。写真は宣伝活動に余念のないA教授です(ご本人から掲載許可をいただきました。ありがとうございます)。

IT技術者を幸せにするには

ITmedia News にショッキングな記事が出ていました。

「日本のIT技術者、幸せではない」──MSの課題
マイクロソフトのヒューストン社長は、新年度の課題として「IT技術者の地位向上」を掲げる。「あまり幸せではない」ためだ。

この記事はマイクロソフトのダレン・ヒューストン社長が、経営方針説明会で話された内容です。同社が「ITスキルの向上を支援していく」前提としてお話された内容です。

この記事は、さらにスラッシュドット・ジャパンでも取り上げられて、多くの意見が寄せられています。批判的な意見の多くは、「技術力をつけても仕事が集中して不幸になるだけ」という、悲しくて、情けなくなるようなコメントでした。

この元記事を読んだとき、最も気になったのは、なぜ幸せでないとされているかです。

「日本のITプロは『社内のPCを購入する』という決定はできても、プロジェクトなどの上位の大きな決定には参加できてないようだ」

この事実の原因が技術力にあるというのは、多くの日本企業に当てはまらないと思います。私が思うのは、日本の企業は組織構造ピラミッド型で、しかも強固であることです。このことが日本企業の強みであり、弱さであると思ってます。

主なソフトウェア危機は、巨大なソフトウェアを開発すること、品質の高いソフトウェアを開発することだと言われています。かつては、バグのないことすなわち信頼性がソフトウェアの主要な品質だと考えられてきました。

しかし、ソフトウェアの機能が高度化するにつれ、ユーザの求めるソフトウェアが開発されているか、すなわちユーザにとっての品質が重要視され、様々なアジャイルソフトウェア開発が提案されてきました。

アジャイルソフトウェア開発が注目される中、日本では導入される企業と、どうも普及しにくい企業に分かれていると思います。導入が遅れる原因は簡単です。技術者がいないこと、そして管理しにくいからです。

管理可能なことでないと実施させてもらえない。それは、当たり前の問題の発生を減らします。これ派大きなメリットである反面、独創的なアイデアや社員のやる気をなくします。

構造化プログラミングからオブジェクト指向に、ソフトウェア開発のパラダイムはシフトしてきました。これは、トップダウンでの開発には限界があり、ボトムアップな要素を入れる必要があったこと、開発を効率化する再利用には、小さなオブジェクトの組み合わせが有効であったからだと思います。

IT技術者を幸せにするには、ソフトウェア開発で生じたようなパラダイムシフトが、組織にも生じる必要があるのかもしれません。トップダウンで管理されるのでなく、自律的で協調的な高度なITエンジニアを育成できる組織が求められていると思います。

それは、上の記事にある教育的なことも含むでしょうが、重要なのはITエンジニアが自立的に行動する組織文化ではないでしょうか?

「<<」の読み方-第11回 Ruby勉強会@関西-

新しい文化は関西から始まるのかもしれません。
Ruby関西の勉強会では、新しい技術やディープな話のほか、Ruby 初級者向けレッスンが行われます。レッスンのお題は「イテレータ」、繰り返し処理を簡単に処理する方法の解説でした。例題でArrayの最後に追加する際にメソッド「<<」(Pushとおなじ)が出てきました。これは

Array << obj

とすると、もともとの配列の最後に"obj"が追加されるものです(マニュアル)。さて、このメソッド、なんと呼ぶでしょう?「小なり小なり」ですか?

そんな呼び方をするあなたは、たぶん職業プログラマでしょう。そんな呼び方はやめましょう。「クク」と呼んでください。呼びにくい言葉は、言い換えれば良いのです。ギャル文字風の呼び方などと言ってはいけません。

この呼び方は「みかか」以上のショックでした(「みかか」はチャット中にNTTと打とうとして、入力モードを間違えて「みかか」と打ってしまったことがきっかけで、露骨に書くのがはばかれるときなどに、いわば隠語としてはやりました)。「なんだそれ」と思わせて、あとから「ああ、そうか」と思わせる不思議な呼び方です。

それだけではありません。「クク」はパソコンの創成期を思い起こさせます。そう、プログラミングが仕事でなく、趣味だった時代です。プログラムのソースが雑誌(マイコン、アスキー、IO、のちにOh!PC)に載っていて、誰もがそれを打ち込んでいたころのお話です。

膨大なプログラムを一人で打つのは大変なので、一人がプログラムを音読し、もう一人がタイプする。そんな協調作業が普通に行われていました。

読むのも大変で、読みにくい記号は、新しい読み方を与えられました。

( : かっこ
) :  こっか
! : バン

こんな感じで、それぞれ工夫したものです。

さていつからだったでしょうか。プログラミングが仕事になり、新人研修で「開き括弧」なんて真面目に呼ぶようになりました。また、人にプログラムのコードを伝えるときは、合理的だからとメールなどが増え、音読して伝えることも少なくなりました。

Ruby勉強会での出来事は、プログラムを音読して人に伝える過程でおきました。その意味を考えると、Rubyは私たちにプログラミングの楽しみを取り戻させてくれようとしているような気がします。これは画期的な出来事、社会の変革だと思います。

みなさんに提案します。「<<」は「クク」と読みましょう。

とようけ屋の豆腐

Toyouke mixiでとくぢろうさんに教えて頂いたとようけ屋の豆腐を食べてみました。
スーパーにもあるとの事だったので探してみると、近所のダイエーの京豆腐コーナーにありました。木綿豆腐の冷奴がおいしいそうですが、すっかり忘れて一つだけ残っていた寄せ豆腐を買ってみました。

巷で話題の男前豆腐店風に吹かれて豆腐屋ジョニー(リンク先はエキサイトニュース)はプリンのような食感と大豆の中心だけを使ったような(実際は知りません)まろやかな甘さで、硬派な服装の軟派野郎と言った感じです。これに対して、とようけ屋は正統派です。

口に入れた瞬間にまさに豆腐というような大豆の皮の風味を感じます。食感は滑らかなのにしっかりしていて、揚げ豆腐の中の部分のような固めの食感でした。いわば紳士的なナイスミドルといった感じでした。

どっちもお酒にあいそうです。こんなことを書いていたら、生協のにがり充填豆腐が食べたくなってきました。なんか村田蔵六(大村益次郎)みたいですね。“豆腐一丁、酒一合”ではたぶん足りませんが、、、

« 2006年6月 | トップページ | 2006年8月 »