わんくま同盟ホーム わんくま同盟の最新記事 MyBlog    Ognac試行部屋   
Skip Navigation Links
ホームExpand ホーム


  最近のテンキーとキーボード
最近のテンキーには「TABキー」がついてます。いつから付いているのかは知りません。 入力項目のカーソル移動をエンターキーで行うことの可否は昔からの課題で、未だに実装者依存のようです。 画面単位のSubmitの役目をどこに負わせるかとの兼ね合いの問題です。 汎用機端末では、カーソル飛ばしはEnterキー/Tab キーで、Submitは実行キーという風に、3種類のキーが存在しました。 この場合、Enterキーでは、Tab順でなく、物理配置の左上から右下への移動が可能だったように記憶してます。 PCが普及し、106/109キーボードが普及したときに、「実行キー」が消滅したことにより、カーソル飛ばし問題が浮上したようてす。 機能的には、カーソル移動とSubmitの2つの機能が必要なので、キーも2つで充分というのは、納得できます。 ただ、実務操作の特性を精査しないで、決めたような印象を受けます。 汎用機ユーザーは、Enterと実行キーを使い分けていた.....これは、慣れれば解消します。 アプリは 伝票入力する場面は、「左手で原始伝票をめくり、右手はテンキー部分固定で、入力する」を想定しているのが多い。TABキーが左しかないので、カーソル飛ばしがTABキーだと、操作しづらい。そこから、エンターキーによる項目飛ばしの要望が出てくると考えてます。 Webアプリでエントリー画面作るときは、特に操作性は悩ましくなります。 タブキーが右にあれは、すんなり解消するのになぁ。と思ってました。 ふと、テンキーを眺めていると、タブキーが付いている! これで、嫌な実装から逃れられる。と喜んだものの、フルキーボードは右にTabキーがない。 すべての入力系ユーザーにテンキーを備えるのは、強制できないし、..... キーボードのキータッチなどの物理的な向上はありますが、キー配置という、根源的な部分は固定化されているのは、不満ですね。 その割には、方向キーや Home/End/Insert/Delete等のキー配置は個々異なっているし、 右にTabキーが何故ないのだろう。 タイプライタのキー配置の謂われも、「使用頻度の高い文字が使いやすい指にくるようにした」という説と、 「活字がインクリボンを叩くアームが、もつれないように、頻度の高い文字と低い文字の配置を調整して、アーム動線の交通整理をした」という説もあり、趣旨が正反対のようですね。 物理的なアームがなくなった今日でも 「QWERTY」配置に縛られるのは、慣れだけの問題なのだろうか。一度普及したら、環境が変わっても改良できない工業製品の宿命なのだろうか。 親指シフトや50音順キーボードが振るわなかっしね。 真にこの配置が使い勝手が良いのか、慣れているから使いよいと錯覚させられているのか? Fullキーボードのキー配置に不満はないのだろうか。

 
  1有効なカンマを含むCSVの分離~Regex
有効なカンマを含むCSVの分離~Regex 123 , "a , bb ,cc " , ' 漢字、ひらがな、カタカナ' , 備後国 ,上州 こういうデータがCSV形式で提供されることが、往々にしてあります。 ExcelなどのアプリケーションでCSV出力したとき、データとして","があったとき、"か'で括ることになっているのかもしれません。 受け取る側で、"か'を考慮して分離する必要があります。処理としては最初から読んでいき、Quateの出現回数の偶数奇数で有効カンマか否かの判定すれば、良いのですが、正規表現で実装してみました。 ここ 最後に ","が付かないとき、最後の項目を落とし勝ちです、肯定先読み(?=(,|$))で対処すると、1つのパターンで対処できます。 パターン = "\s*(?["']?)(?.*?)(?(a)\k)\s*(?=(,|$))" ・少し解説 切り出した単語は Group名 に格納されます。 "~" もしくは '~' もしくは {無冠}から{無冠} の区別は (?["']?) で判定します。 "か ' のいずれかが始まると、に値が格納されます。{無冠}の時は、は未確定で続行されます。 が確定しているときは(?(a)\k)が有効で、の種別で括った範囲が に格納されます。 が未確定のときは(?(a)\k)が無視されねので普通に に格納されます。
  2郵便番号CSVの県名、市区名、町域名をXML化する
郵便番号CSVの県名、市区名、町域名をXML化する Ognacの試行頁に 「郵便番号CSVの県名、市区名、町域名をXML化する。」を追加しました。 http://www.ognogn.com/Regex/ZIP_CSV__2__XML.aspx 郵便番号CSV形式のデータから XML Fileを 正規表現のReplace で作成する例です。 正規表現のReplaceだと字面だけの置換なので、制約が多いのですが、Regexでは、Delegate 機能でコールバック処理が可能になってます。 言語で、データ加工が自在にできるので、手軽に変換プログラムが書けて便利です。
  3明治以前は 明治を含める・含めない?
10以下、10以上は "10"を含めます。 10未満、10超は10を含みめません。 条件句の設計で以下のような場合分けは頻出します。 1台~3台 3台~ と書けば 1<=n and n <3 3<=n and n =<∞ と解釈されるでしょう。しかしここは誤解を生む可能性があるので 1台~2台 3台~ と書いた方が良いとされまます。 規約によっては "~" を禁じているのもあります。しかし 1台以上、3台以下... 3台以上 ... というのをレビューOKにしてはいけません。 「1台以上、3台以下」.という表現はありません。「1台以上、3台未満」となります。 ここまでは数学・算数的な定義で解消します。つまり「前」「後」「未満」「超」は基準点を含みません。「以」は含めます。 「100と200を含まない」という表現はバグがあります。「100と(200を含まない)」と取ると、100はどちらにも該当するので"200を含まない"の一文と同意になり100は含まれます。 「(100と200)を含まない」と取ると、100は含まれません。修飾関係がアヤフヤな表現は、バグの元ですね。 しかし、明治以前といえば、明治を含めるか含めないか? 人に聞くと半々に分かれます。(懇親会でもそうでした)国語の教師にきいても、文法的には判断できないんだそうです。 しかし、社会(言語)通念上、明治以前の年号と言えば、明治を含めません。明治以後の人物には、乃木希典等の人が該当するように明治を含めます。 こちらの以前・以後の基準点の処理は文意で決まりそうです。 仕様書に平成以前、平成以後という制約は登場しそうですね。2000年以後、2000年以前 と仕様書に書いてあればどうでしょう。 開発者は、設計者に確認してから実装して欲しいです。そのような仕様書が仕様バグだというのは言い過ぎでしょうか。設計者も判断が付かないケースもあるので、業務仕様を確認する必要もありそうです。 要件定義の段階で、 「2001年以前」といった文言が入っているようだと、要注意です。 自然会話語では、矛盾のない表現は無理なのでしょう。ここからも自然言語をブログラム言語にするは厳しいモノがあると思うのです。(二次会でこのような話しをしたような気がして書いてみました。)
  4明記されていないことの意味
前回、規則(法律や規約)に関することを書いたのですが、規則に明記されていないことの扱いが気になりました。 「明記無し」という意味は複数あるように感じます。 ・自明で常識なので明記しない : 万人共通の常識なんて存在しないのに、「常識だから明記しない」その結果、誤認によるトラブルが発生する。 ・規則集が、肯定形の列挙で構成されているとき(bbbはしても良い。xxxxの時はyyyyをする。zzzzの時はaaaをする)の、明記無き事は、してはいけないのでしょう。 ・規則集が、否定形の列挙で構成されているとき(cccはしてはいけない。xxxの時はyyyyをしてはいけない。)の、明記無き事は、してもよいのでしょう。 ・肯定形と否定形が混在しているときの、明記無き事は、判断が付きません。 システムの規則は、しても良いことを列挙したほうが、悪影響は少なく、誤認による不具合は少ないようです。 教典に「誕生日」の記述がないので、「誕生日を祝わない」とする集団もあります。 システム開発など、するべき事が明確なケースは、「してもよい」ことを列挙することで、制約を課して、守備範囲を小さくするのも手段でしょう。 それ以外のケースでは、これは、ネガティプに作用すると考えています。 「明記された事しかできない」ことは、新しい行為を試すことが不可能になるから「進歩を否定すること」になると思います。「明記されたことはしてはダメ」としても、すべてのダメ事を明記するのは不可能です。「明記無きことは何をしても良い」と理解する人が現れかねません。 明記無きことは、「社会通念上の判断に従う」ことになるのでしょうが、これは、常識判断を迫ることになり、「万人に共通な常識はない」ことに反します。 単に言葉遊びに過ぎないのかもしれませんが、明文化の難しさと、規則の立脚基盤ってアヤフヤだなぁと感じます。
  5大坂と大阪
大阪は明治未満(明治含まず)は大坂でした。 『摂葉落穂集』(文化5年)には、坂は不吉な文字として忌み嫌う人がいたことが書かれているので、「坂」という字を嫌われていたようです。 廃藩置県の時に、土に返るのを忌みって阪の字に変えたと雑学本には書かれています。  それなら、文化時代に地名を変えても良いはずで、なぜ明治初期に変えたのかが引っかかってました。 先日読んだ本「漢字は日本語」(小駒勝美著)には坂が阪になったのは「説文解字」に起因するとあります。 「説文解字」は字形の元(活字の元)になるもので、そこに掲載されているものを本字としたようです。そこには、「坂」はなく「阪」しか無かったらしい。「阪」と「坂」は同一文字の異形だそうです。 「斉藤さん」と「斎藤さん」の字は略字関係でく、別の字だそうです。しかし、少なくない人は略字だと認識してるようです。 嶋と島と嶋は同じ、峰と峯も同じ。漢字の旁や偏の位置関係は関係なく、上下左右どこにつけても、意味は同一というルールだつたようです。それが、この字が正しくて、この字が間違っていると人為的に区別しただけのようです。 「御璽」の難しい、璽が常用/当用漢字で、「猫」が含まれていないかなど、裏話も説得力があります。 利便性よりも、憲法に書かれている字が常用/当用漢字に含まれていないのは「問題だ」と認識したようです。おかしな話です。  この書では言及してませんが、画数もいい加減なところがあって、新字と旧字と略字で画数が変わったり1画省略しただけの字とかがあるので、画数判断は意味が薄れることが読み取れます。  新旧JIS漢字問題・Vista漢字問題にも言及しているので、一読の価値ありと感じました。  雑学本は面白いので良く購入するのでずが、根拠まで踏み込んでないが残念です。項目が多いので無理なのでしょうね。 追求すると未知の世界への入れるので、海里図として読んでます。


御託

ソース