Ｋ２さんの雑記

■ 筋肉痛が...

さすがにちょっと筋肉痛。いや、ほとんどないのだが、ちょっとだけ。毎日使っていると筋肉痛というのはほとんど出ませんね。

花脊は超えてしまったので、これでほとんどの坂は登れるだろうという自信がついた。今回のコースをトレーニングコースとして何回か走るか、それとも朽木や琵琶湖方面に足を延ばして、100km超コースにトライするか。いろいろ夢は広がります。

なお、自転車のギヤ比は、MTBというよりも、ほとんど前トリプルのロードバイクのギヤ比（一番軽いのは、30T/25T）ですので、結構やるなと自画自賛(^^;

■ やっと追いついた

長い間放置していたサポートBBSのコメントに、やっと答えることができました。一部すぐに返事がもらえなかった人が不平を書いていましたが、すんません。

業務ではないので、気が乗るときもあれば気が乗らないときもある。腹の虫の居所で機嫌悪いときもある。忙しいときも体調が悪いときもある。そういう中で、できるだけ真摯に社会貢献するつもりで営みを続けております。

そういう事情は、この雑記なんかをじっくり読んでいただかないとわからないと思うので、察していただけない場合があるのは重々承知しています。ある程度はわかってくれない人がいても仕方がないと割り切っております。

細く長く続けさせていただきます。「太く」の時代がまた来るといいですねー(笑)。

■ 風邪ー

完全復調には至らない...　今日の午前中２時間の会議（自分が進行役）は、かなりつらかった。熱はないはずだが熱っぽいような気がするし、途中で息切れするし。

このまま治ってくれることを切に希望。

■ エクセルのここがきらい！

• 同じファイル名のファイルは同時に開けない
• セルの中で、タブ・インデントが効かない
• MDIなところ
• アンドゥに回数制限があるところ
• リドゥがない
• F2を打ち間違えてF1を押すと...泣きそう
• オープン・セーブダイアログが独自ダイアログで、一部機能が使えない

他にもいろいろあるけど、最近特にきらいなところが目立ってきた。なぜなら、エクセルに文章を投入する機会が増えたから。

なぜかわからんのだけど、世間でエクセルで文書書くのってはやってない？　そういう人がどんどん増えてきている。たとえば報告書をエクセルで書いたり、仕様書をエクセルで書いたり。

それだけなら個人の自由なのだが、会社が指定する定型フォームがどんどんエクセル化している。その世界では玄人の芸術的な技があるようで、狙ったフォームを特殊な技を駆使して実現している。

フォームはエクセルの方が作りやすいのは認めよう。しかし、そこに原稿用紙にして１枚以上とかの文章を書きたくない。箇条書きも使えないし、通常の文書書きのキー操作から逸脱している操作があるため、効率が悪い。例えば、セルの中での改行はALT+ENTER。これだけでも流れるような業務を止めてしまうのだが、タブキーに至っては次のセルに飛んでいってしまう。

行頭にキャレットを移動しようとしてHOMEキーを押すと、モードによって動作が変わるのだ。モードと言っても普通は気づかないようなモードである。すなわち、あるセルを選択していきなり文字を打ち出した場合は、HOMEキーで行の先頭のセルにフォーカスが飛んでいってしまう。F2を押してセルを編集状態にしている場合は、HOMEキーで入力中の文字の行頭に移動する。両者のモードに、外観的な何の違いもないし、HOMEキー・ENDキーなどの動作以外に機能的な違いも見られないため、ユーザーは区別して操作を覚えることが困難である。ユーザーが気づかないモードによってキーの動作が変わるため、最悪のユーザーインターフェイスになっている。

F1を押すとヘルプが出る。業務をするには邪魔でしかないオフィスアシスタントを隠しておくと、通常のヘルプが出るのだが、またこのヘルプが凝っている。どうして他のベンダー（私のようなオンラインソフト作家も含めて）が、Microsoftの意図するUIに注意深くそろえているのに、Microsoftはその標準をいとも簡単に破ってしまうのだろう。ま、なんせこの凝ったヘルプは重いのである。表示されるまで数十秒かかる。普段ヘルプなんて使用しないから、まぁ時間がかかっても許せるのだが、問題は押し間違えてF1を押してしまったとき。

セルを編集する場合、F2なんてとんでもないところのキーを押さないといけない。このキーをタッチタイプで押すときに、まれにF1のミスタッチをやってしまう。そうすると、システムが固まったように感じてしまう。この瞬間が本当に情けない。タッチタイプでミスをするというのは、大抵は急いで文書を作成している時であるから、この数十秒が永遠の時間のように感じてしまうのだ...　F2をセル編集に割り当てたのは、たぶんLotusだったりするのだろう。だから、それは攻められない。ヘルプを軽くしてくれ。HTMLHelpシステムを普通に使ってくれ。

もうね、毎度毎度いうことだけど、MicrosoftはOSのデフェクトスタンダードを持っており、オフィスソフトに関してもそうである。その自負があるなら、「普通」のものを作ってくれ。バージョンアップしてどんどん普通化していく方向に開発が進むなら、涙を流して喜ぶよ。ありえないが...

一番悪いのは、無理な用途にエクセルを使おうとしていることかもしれないが、ワードがエクセル以上に嫌われているため、ある程度仕方がないところもある。ワードももっと普通にして欲しい。奇をてらったことはいらないよ。普通に普通のアプリを供給してくれ。

なお、冒頭のリストに関して、若干説明をしておこう。

• 同じファイル名のファイルは同時に開けない

  よく知られた話。違うフォルダに入っている同じ名前のファイルは、同時に開くことができない。工夫としては、別プロセスのエクセルを開けば、そこで開くことができる。エクセルをスタートメニューなどからもう一つ開いてみよう。

• セルの中で、タブ・インデントが効かない

  文章書かせるなら、箇条書きくらい使いたい。ワードのお節介な援用機能はいらないから、エクセルで箇条書きとかインデントを使わせてください。

• MDIなところ

  両面に開いて文書を比べたりするときに不都合。特にマルチディスプレイの場合。これも別プロセスのエクセルを開けば避けることができるが、エクセル２枚を立ち上げたときの動作が少し不安定な要素がある。

  なお、これに関しては、Acrobatはもっとひどい。AcrobatこそSDI化してくれー。

• アンドゥに回数制限があるところ

  今時のソフトでこれがあるなんて。存在を忘れていていたたたとなる。

• リドゥがない

  ワードにしてもエクセルにしても、リドゥーは欲しい。

• F2を打ち間違えてF1を押すと...泣きそう

  本文参照。

• オープン・セーブダイアログが独自ダイアログで、一部機能が使えない

  どうしてわざわざ独自ダイアログにする必要があるのだろうか。すぐに思い出せないのだが困る場面がたまにある。

■ My Life Between Silicon Valley and Japan - 悲観主義とオプティミズム

オプティミズムとは、まったくもって「意志」の問題なのである。

全く持ってその通りだと、心の中で叫びました。

■ ハブダイナモの電球が切れた

SHIMANO製のハブダイナモ用の電球が、２日前に切れた。切れやすいとは訊いていたが、自分の番が回ってきてしまった。

確か、結構高かったんだよな。発注しなきゃ。

■ 液晶モニタが壊れた

NANAOの16.1インチの液晶モニタが壊れた。10万円くらいしたのだが、なんか作りが安っぽかったし、画質もあまりよくないし、まぁ古いし仕方ないか。

３万円くらいの17inchまたは19inch横長を物色中。

■ フレッツ光プレミアム

昨日工事があって、無事開通。昨日の夜、４時間くらいかけてCTUともともと持っていたルータのセットアップをした。

しかし、CTU達をどこに置くかとか、屋内のLAN配線をどうするかとかがまだ未解決。計画を立てて、必要なケーブルを買い出しに行った。

今日は昼から屋内配線のやり直し。かなり面倒な作業だが仕方ない。きれいにやりましょう。

■ もう壊れたりやり直したりしなきゃいけないものなかったけ？

そういえば、前の自転車のCRS-2の処分をしなきゃいけない。部品をはずして、今の自転車に移植するなど面倒な作業が残っている。

実は、急に火曜日から中国出張が決まってしまった。土曜日まで。その準備もしなきゃいけない。

月曜日は、ECCの進級テスト。進級は決まっているのだが、テストは決まった後にやるというよくわからないテスト。絶対に落ちるなとスタッフから言われているのだが、それってちょっと勝手じゃない(笑)。

なんかえらくせわしなく忙しいのだった。

■ Pythonの関数返り値定義

Pythonも並列で進めている。案の定こんがらがってきてます(笑)

Pythonの関数は、返り値があるものについて、関数定義ヘッダ行には何も書かず、本体の中でreturnで値を返すかだけで決まるらしい。

これって、関数ヘッダを見ても、関数の仕様がわからないことになるので、ソースの可読性に問題はないのだろうか。

また関数本体で、分岐でreturnが複数ある場合、返す値の型がそれぞれ違った場合はどうなるのだろうか。

２点ともきっとナイスなアイデアで解決されているのだと思うが、今の時点ではちょっと疑問。

■ Swiftの関数返り値定義

Swiftの場合は、関数返り値は、関数ヘッダの後に 「->」を追加して型指定するのだが、この「->」って、なんか違和感。この文字自体に意味づけがないので、なんか言語仕様として美しさに欠ける感じがしています。

どうして他の言語ではあまり採用されていないフォーマットを使っているのか、よくわからず、ちょっといやな感じがしています。

■ Xcodeでのオブジェクトとコードの接続

例えばstoryboard（画面設計するペイン）で、キャンバスの上にテキストフィールドを置いても、どうやらその部品に名前はつかないようだ。

これを、ViewController.swiftというコードが書かれたファイルに関連づける時（クラスのプロパティとしてテキストフィールドオブジェクトをコードに追加する）、初めて名前をつけるようだ。

これで、クラスのコード中で、この部品にアクセスできるようになる。

このクラスのオブジェクトに関連づけられたプロパティのコードをOutletと呼ぶらしい。

@IBOutlet weak var nameTextField: UITextField!

こんな行がViewControllerのクラスに追加される。この行中の単語ひとつひとつがまた難しい……

■ イベントハンドラ

Xcodeではイベントハンドラという言葉は使われていないようだ。アクションメソッドというのが正しいか。

   @IBAction func setDefaultLabelText(_ sender: UIButton) {

こんな行で始まる。中括弧内にコードを書く。

ボタンに対するアクションメソッドは、ボタンからControlキーを押しながらViewControllerコード内にボタンをドラッグすれば簡単に作れる。

テキストフィールドに対するアクションメソッドはそう簡単にはいかない。

まず、ViewControllerを、UITextFieldDelegateからも継承させなければならない。これは手作業で行う。

class ViewController: UIViewController, UITextFieldDelegate {

その後、ViewControllerのviewDidLoad()メソッド内で、テキストフィールドのdelegateプロパティに、自分をつっこむ。

   override func viewDidLoad() {
       super.viewDidLoad()
       // Handle the text field's user input through deletate callbacks.
       nameTextField.delegate = self
   }

これで、テキストフィールドのアクションメソッドが、ViewControllerの中に定義できるようになったので、手書きでアクションメソッドを挿入する。

func textFieldShouldReturn(_ textField: UITextField) -> Bool {

}

ここまでやらないといけない。これをスパルタンと言わずしてなんと言おう(笑)。

こうやって手書きで関連づけないと、テキストフィールドのイベントがViewControllerに通知されない。こうやって解説を二度読んで、誰にも読まれないであろうこの日記を書いて、やっとなんとなく理解できてきた。

もうちょっと簡単にイベントハンドラを作成できるようにしてもよかったのではないか？＞apple。

■ 慣れないCapsキー

どうしても、CapsキーをCommandキーと間違えて押してしまう。仕事で使用しているLet's NoteのControllキーがちょうどその位置にあるので、コピーペーストなどの時に小指でそのキーを押してしまう。同じようにMacBookでも小指でCapsを押しながら、Cだのアンドゥのzなどを押してしまう。

このCapsキー、標準の環境設定で、他のキーの機能に変更できるらしい。さっそくCommandキーに変更してみました。

だいぶ使いやすくなりそうな気がします。