kozawa のたまに気になること

リンクの少ないでもぶろぐ・・・にせぶろぐ?
スポンサーサイト

一定期間更新がないため広告を表示しています

| - | | - | - |
Nagoya.php vol.9

Nagoya.php vol.9 - Nagoya.php | Doorkeeper へ行ってきました。

ソフトウェアの世界にいますが、仕事でPHP書いたのはつい最近少しやったのが初めてだったぐらいなのでお勉強に。

前日お酒付きの打ち合わせが遅かったので、持参するノートの開発環境のインストールをしてなくて、当日wifiで IDEからMAMPから全部インストールとかいう体たらくで、開始時点でまだ設定が終わっていなかった…orz。

ろくなコードはかけてないのでとても公表したくないレベルなんですが、(時間ぎりぎりになってやっと汚いコードが動いた ので次の課題に進めず、しかも一部間違っていました。他の言語ならもうちょっとましに作ったのに…orz
出来のいいコードを当日公開したベテランの方々hidenorigoto/Nagoya.Dk9 77web/Nagoya.php.Vol9や、後日公開した方kenjis/Nagoya.php.vol.9-DouKakuなど、みなさんさすがです。 読むだけでも参考になりました。

LTもなかなか良かったです。

体力的限界その他の都合で懇親できなかったのが残念です。

まぁ、懇親って得意じゃないんですが(汗

| 言語 | 10:21 | comments(1) | trackbacks(0) |
なごやかJava ゆるふわテストツール編
なごやかJava ゆるふわテストツール編 - connpass`に参加しての感想を。
私は体調不良で遅れて参加だたですが(発表で言えば「Selenium導入事例紹介(仮)」の終わりごろから参加。時間は押して進行してたので14:30頃だったかしら)。

みなさんすばらしい発表でした。といっても自分がふぬけでとても理解し切れてないので、感想もまともに言えません。

きょんさん夫婦が子連れ(乳児)参加ということでお二方もうまく子供をあやしながら(あれは大変であったはずである)、みんな快く迎えていて、その辺は模範ともいえるようなところではありますが、きょんさんリスペクト。

まともに感想なんか言えないので、発表「テストの自動化を考える前に」を伺って自分の自分が見かけた「テストでひどい目にあう例(ただし、非TDD。非TDDにおける部分的テスト自動化含む)」を書いてみようかな。もしこんなだめなやり方でTDD 目指すとTDDにもなれずにただただ泣きを見る、と思います。(もし、フリータイムがあったらこういう話をしたらよかったんだろうか。いや私のようなヘタレな話題ではダメだよなぁ…。資料のない即興プレゼンへたっぴぃだしなおのことだ) ※TDDと呼べるものでなければテストの自動化は意味がないなどという意図はありません。念のため

例1)
モジュール単位のテスト自動化がまったくなくて「画面からDBまで結合」した大きな単位でテストの自動化を入れたある例。
そこで「一つのテストだなるべく多くの項目をチェックできるようにテスト設計をしっかりすること」という指示が。
仕様が固定された範囲内でのバグ取りのための再テストの時はまだよかったが、一度テスト完了Fixの後、仕様変更後には、修正範囲が限定的であっても、テスト仕様(自動化データ)の修正点があまりに多すぎて再利用を前提とした予算・工程は組まれず、捨てられた。
これは、まぁ、自動化に悲劇というよりテスト仕様の再利用の悲劇といった方がいいかもしれませんが(自動化以外の仕様やin/out条件定義作業の方がずっとコストがかかっているので)、自動化部分に投じたコストも回収できたかどうか怪しい…。まぁ、自動化自体のコストはこの例ではゴミだったかもしれないです(ツールもアホではないので)

例2)
VisualStudioの単体テスト機能を使って、「テストによるコードカバレッジ100%」になるようにテストコードを書くことを命じられたあるプロジェクト。もちろん、これも、TDDに向かないコードに対しての指示でした(ただ、このプロジェクトは既存コードの低予算でのマイグレーション案件だったので、そもそも既存コードあり、リファクタリング予算なし、という制約だった)。
「バカでかくて複雑な単一メソッド」が癌で、仕様変更なり大きな回収が入る度にカバレッジ100%行かなくなってしまった。ところが、その主な理由は、その後通らなくなってしまったコードに問題があるからではなく、ある修正のために、その部分を通る条件となる元データがかわってしまったが、その条件を満たすデータを作り出すのがあまりに大変であった例。
最初だけ100%で、以下は100%をあきらめるという運用で回避状態だったわけですが、こいつの場合も、当初書いたテストコードは「必要十分」でないゴミが発生したわけです(まともなTDDでものちに要らなくなるテストがゼロと決まってはいないでしょうが、ゴミ発生率が高くて割が合わなかった、という話です)。
テスト自動化自体がまったく無駄だったということはないのですが、コスパは悪かったし、一度かかげた100%が捨てられる等、品質目的に対してかかげられた施策が途中でよれたわけで、品質管理の観点からもどうだったんですかね(現実的に目標や対策を途中で見直すことが悪いというわけではないのですが、なし崩しだとどうなんすかね、評価もしづらいので…)
こちらの場合は、こういうものだと割り切ってやる限りにおいてはコスパが悪いといっても許容範囲だったかもしれない。。。

すんません。マサカリ投げて私に勉強させてください…。
| pc/net | 10:48 | comments(1) | trackbacks(0) |
デシジョンテーブルでMECEをニッチに突き詰めたら実は奥が深いかもしれない話

この記事は、主にITシステム設計書書きな人な気がしまして、それ以外の人にも役に立つことがありますが、なにぶんニッチです。ななめ読みしてか
もっというとフローチャート脳な人向けの記事かもしれません。

さて、デシジョンテーブルとは何ぞやというと、デシジョン・テーブルを活用するのようにいい記事がありますので、そこを読んでもらうとよいでしょう。

例えば、設計書で「この場合はこれをやって、この場合はこれをやる」みたいな話、まぁ条件と結果が1対1とかなら、いいんですけど、これが複雑になった場合、「人間が読む文書」として、網羅性とかそういうのを見落としやすくなるんですよね。目でチェックの漏れが起きやすい。手続き型言語プログラマーやフローチャート脳の人が設計書を書くとif-elseのように

1)何々ならば
1−1)何々する
2)何々でなければ
1−2)何々する
みたいな設計書を書きがちです。
このぐらいならまだいいんですけど、組み合わせやifの階層が深くなると、以下のようなデシジョンテーブル的な表現の方が組み合わせと結果の組み合わせの誤りをチェックをしやすくなります。デシジョンテーブル、素敵です。
場合分けについての、漏れとか重複とかのミスを防ぐ方法の一つとして使えます。

で、ここからが、私が気になっているもっとニッチな話になります。

デシジョン・テーブルを活用する の最初の例を見ましょう。これでいうと条件記述が3つで、すべてYesとNoだけの値を取っています。
この例の場合、「レンジ時間セット」と「トースト時間セット」は同時には成り立たないという前提で書かれています。読み手がそれを誤解する恐れがないときはこれでもいいのですが、網羅性の漏れチェックを容易にするという観点から私が推奨したい記述方法の解説を始めます。もちろん、こういうのはドキュメントの目的次第ですがそれは大前提として…。

まずは網羅性や重複などがないことを重視します。
デシジョンテーブル記事図0
しかし、これに厳格にこだわると、条件の数が増えた時
1)条件記述が多い時
2)条件指定の値の種類が多い時
に全部の組み合わせを入れるととんでもないことになり、結局「人間の目じゃ見てらんないよ」という点において大差ないじゃないか、ということになると思います(条件部分の場合分けの漏れや重複の排除だけならロジカルに並んでさえいれば根性でチェックする余地はありますが、動作記述部が合ってるかを他の条件との関連を見ながらチェックするなどを考えると絶望的になると思います。特に動作記述部分の内容が条件毎にある程度関連があって離れた行同士で規則性があるような場合とか、見るのが大変です。 ※余談、プログラムでチェックするとか、Excelのフィルタでチェックするのであって目だけで見るわけじゃないよ、という方向の解決策を探すなら以下の話はあまり関係がなくなります)。

そこで、条件部のミスしなさと表のサイズ爆発防止をいい感じで両立する方法はないか、といった時、例えばこういう書き方もできます。今回の例の表だと、結果的にこのように書き換えても意味が同じになります。
デシジョンテーブル記事図0.5
※ここでこっそり「不問」という表現を入れてあります。これは便利な簡略化方法で有用だと思います(-とか他にも記法はありますが、「不問」が誤解の余地が少なくて個人的お勧めです)。
デシジョンテーブル記事図1

これの欠点の一つとして、条件記述の並び順をかえてしまっているので、逆に見づらくなっている面があって万能ではないのです。が、ひとまずこの方法を使った場合の話を続けます。また、こういうまとめ方は表の改定容易性を下げている側面もあると思いますがそれも脇におきます。

さて、次が「条件指定の値の種類が多い時」の問題です。ここで「レンジの生産工場」を追加の条件とし、実は工場は100以上ある、とします。
デシジョンテーブル記事図2
元の定義通り全部書いてると、表がすごいことになります。もちろん、それでも書いておくべき名ことというのはあるので、その時はそういうものとして対処を考えるしかないですが妙案はここにはありません。しかし、「漏れもダブりもない」ことをチェックするだけでも大変で、その上で、それぞれ全部についての他の項目や結果との整合を確かめるのも涙目です。
これを、工場が100個あるとはいえ、いくつかのグループに分けることができる場合、見かけの見通しは少しよくなります。まとめた場合、それぞれが一グループであることの正しさも見なければいけないので、一長一短ではあります。※少し乱暴に言えば、技術者よりの人がみる仕様書的なものや辞書的なものなら全部個別記述してなんぼでしょうし、業務の場合分けなどは、これとこれが同じ、と固められて見えることのメリットは大きいと思います。
デシジョンテーブル記事図3

ここで、こういう記述もあり得ます。
デシジョンテーブル記事図4
条件「レンジの生産工場」に項目の漏れがないということは割と容易にわかります ※記述された仕様全体として正しいかはまた別ですが、一覧性がいい方が全体をチェックしやすいので、そこにメリットがあります。
業務の仕様書で条件記述(今回の表で言う条件の縦の個数)が多数のものだと、しばしばこういうのがあります。
「商品の品番コードを条件とする」みたいな場合には、どうしてもホワイトリストで網羅することができず、「〜以外」を条件に入れないと網羅性に問題があることがあるので、今回の私がこれを書いている目的では「〜以外」は積極的に使うべきという発想になります。もちろん、網羅性が自明である時はあります。レンジ時間でYとNの二値であるのが自明なのに「〜以外」の出る幕があるのかと言われると、この場合は要らないと思います。しかし、大量のドキュメントをこの方式で統一しようとするときっと「どれが自明でどれが自明でないか」悩む場面には結局出くわすと思います。特段これにいい解決法とか思いつかないので、「〜以外」はなるべく使う方向でがんばって悩みましょうという程度にします。
この「〜以外」の一つの欠点は上記の「ABC」と「ABC以外」ぐらいだとたいした問題はないのですが、このリストが長くて複雑な場合、表のメンテ性が低下してしまいます。「1〜10」「13〜18」「21,25,29」に対して「1〜10,13〜18,21,25,29以外」とかだと、曖昧性はないけれど、二重記述による記述誤りのリスクが増えてしまいます(読むのも長くて鬱陶しいしその誤りがないかをチェックする負荷も高いということになる)。

「〜以外」の二重記述からの回避方法としては「左記以外」などというのもあります。これはこれで便利なのですが、「〜以外」の導入が結局別の問題を発生させる例が出てきてしまうので、次はその話です。
まずこの例だと、うまく行きそうな気がします。
デシジョンテーブル記事図5

しかし、こちらの例だと、問題があります。
デシジョンテーブル記事図6 「左記」が指定する範囲がわかりにくいのです。今回私の使っている階層構造の条件表記だと、最上位の条件では誤解の余地がほぼないのですが、二段目以降に使うと途端に問題が起きます。
まぁこれも、読み方を以下のように上の段で絞られた範囲とする、などと定義することで回避することも可能は可能ですが、誤読誘発の恐れは増えます。また、「このルールに従ってみんなで書いてね」という標準化に使うと、このルールが徹底されないでめんどくさいことになるリスクは、ここまで書いてきた他のルールと比べても高いのではと推定します(経験談を元に可能性を推定しています)。
デシジョンテーブル記事図7

今回のお題はひとまずここまでです。もっとこれが何を言わんとしているのかもっと明瞭に伝えるには「一見大丈夫に見えるけどMECE的に間違ってる例」や「一見大丈夫に見えるけど解釈に揺れの余地がある誤解を招く例」を例題として色々作って演習問題にするのが一番よいのかもしれないなぁと今更思っています。もっと分かり易く書けば有用度が上がる記事になるのになどと思いつつ今回の品質で妥協して公開します。

まとめると(話を蒸し返しているのですが)、冒頭にリンクした記事でも仕様の記述の明確化の手段としてデシジョンテーブルを紹介しています。
私の問題意識もそこで、しばしばエンジニアは設計書にフローチャート式だったり、if分岐の羅列で書いてしまうのです。これが、ロジックが正しいのかを非エンジニアの人間がチェックするのが難しくなるのでは、それを比較的容易にしたいという方法の一つとしてデシジョンテーブルを持ち出しています。エンジニアでもif分岐の羅列だと、MECEのチェックやロジックの正しさのチェックは結局難しくなります。
仕様記述書の書式として、作業者(ワーカー/PG)にこの方式を強いることでフローチャート/if文式より、「レビューしやすい」設計書ができるのでは、ということです。
ただ、ここまでに色々書いてきて「この場合はうんたら」というのがいくつか出ています。書きたいものが何かによって最適な表はきっとかわります。杓子定規にルール化して守らせると、場合によってとんでもない不自由な表が出来上がりかねません。この辺に標準化ルールとしてのデシジョンテーブル表記法工夫の限界があります。都度表記の利点と限界を加味して工夫してコンパクトにまとめればもっとも都合がよいのですが…。

| pc/net | 08:30 | comments(0) | trackbacks(0) |
名古屋合同懇親会 2014 忘年会
NGK2014B / 名古屋合同懇親会 2014 忘年会
とっても久々にこの手のイベントに顔を出した気がします。
というかNGKははじめてです…orz。 私が存じ上げない方もさくさんでした。

みなさん個性的かつレベルの高いLTで、自分の老害っぷりを再認識して死にたみが高まりました。
順不同で適当にコメントを書きます。雑すぎて失礼な感じになってますが、みなさんリスペクトしてますし、何より私自身の生存報告として書いてる感じなので、なにとぞご容赦ください。

進化するVimはどこへ行くのか。
入院中の点滴等ではりがぐさぐさ状態だとDSみたいなゲーム機は両手本気操作で死ぬ。そりゃそうだ。
ITプランニングさんかっこいい。
OpenStreetMap、興味を持って以降、まともなGPS関係のガジェットへの出費が出来てなくてあこがれだけ抱くばかり…今度こそもうちょっとまじめにいじってみたい…。
IPv6どこへいく。
misocaさん、まだまだ人材募集中広告出されてるようで、実にうらやましい限りです。自分もそういうのに賭けてみたいわぁ。金じゃなく。
フィールドワークさんの帳票素敵。オフィスが愛知県内でも個性的なポジションにあるようで、光る魅力的な企業。
concrete5、katzuenoさんから色々すばらしさを聞いてきましたが、ちゃんとその魅力を理解できるひど調べたことがないのがちょっと自分がもったいない。なによりuenoさんご結婚おめでとうございます。
よんたさんの求人アピール。まだ若いんだし、若いからこそ、こういうコミュニティにある企業さんの中でいい話がまとまったりしそうな勝手な期待をします。まだ若いんだし。年齢だけの問題じゃないけど、私がやってもお祈りアタックを食らいまくるので、本当にお先真っ暗です。
登別クマ牧場、行きたいんですけどね…北海道に上陸したことがない…。
有栖川電算さん、あのラジオ体操アプリ、あれって腰に入れて使うのが正解なんでしょうか。使い方がわからないのですが。そうやってカロリー測定されてるんでしょうか。
えいとすさんのジョブチェンジ。優秀な方なので、さすがです。
ぶれいすさんのExcelで使えるFCellのお話。超ほしい。
maedaさんのEmacsの話。まえださんかっくいい。
smogamiさんのお話、Javaもっと勉強したい…。
コスモルートさんもとがったことやってますね。活躍を応援します。
みずぴー大先生、iOSでSKKとか、クレイジーな素敵なこと。リリースされたら入れてみます。
RKTMさん、登山のすすめがかっこいい…運動したい。。。
こくぼさんの「子持ちになるとかわる生活あるある」。まぁ、そうですね。しまじろうの侵略ぶりに抵抗するの、難易度高いです。
dabitsさんの発表もかっこよかったー。
ネットモチ、実は私は食べてません。フィリップさん今度食べさせてください。

みなさんからエネルギーをもらうとともに死にたみもなかなか刺激された一日でございました。

 
| pc/net | 09:03 | comments(0) | trackbacks(0) |
イテラブルとイテレータブル
 このネタの発端は、mozilla.jpの製品リリースページで、JavaScriptに関係する機能の説明でiterableの訳語として過去「イテラブル」にしていたのを「イテレータブル」になっていたものを、結局現在は指摘で「イテラブル」になった件。

まぁ、そんなに厳密だったり汎用的だったりする意見はないんですけれども。

とりあえず英語の世界だけで見ると、辞書引いてもIterableは載っててもIteratableが載ってる辞書は見つけにくい。辞書だけが正しい英語ってことではないですが、ざっと調べた限りでは(この調査の信憑性は高くないことを強く宣言)、「特別な意味が付与されているのでなければ、まともな編集さんやネイティブチェックではIteratableはIterableに直されることが多いでしょう」と。 で、これはまぁ英単語として。

で、元のネタはプログラミング言語としての専門用語という色のついた文脈です。APIとかでIterator関係で、Javaなんかも既に「Iterable」ってのを持ってます。「Iteratable」でぐぐる検索すると・・・日本人の記事が多いですね。しかし、英語で書かれたと思しき、しかし英語ネイティブではなさそうな界隈ではAPI等にIteratableと使っているものが複数見つかり、「類推でこういう英単語があると思う英語学習(?)エンジニアにおいては日本語圏ならずとも、欧州言語ネイティブと思しき界隈でも見つかる程度には「それっぽい」表現なんだなぁ(サンプル少ないぐぐる結果で見てるので「それっぽい」程度の度合いは不明です)、などと思ったりは。

まぁこれが、日本のカタカナ語と考えれば「十分に定着してなければどっちでもいいじゃん」感はないではなく、「イテレイター」というカタカナ語から派生したと考えれば「イテレータブル」というのは「英語のバイアスのかかった日本語の造語」としてはありうる範囲かなぁ(しかし時に和製英語として、ひどいときには批判されることもあろうかと、しかし、イテラブルよりイテレータブルの方が意味がわかりやすいという日本人はそれなりにいそう。そのあたりの議論では広範囲の論点に共通する明確な結論というのもなかなか得にくい気がしないでもないです)。
しかし、本文脈に限定すれば、「技術用語」であって、Mozilla.jpの技術記述ですので、「専門用語としてより正しいっぽい方を優先するのがよいのでは」という気はしてきて、そうすると、日本でも各種英語圏API使うわけで、大御所はIterable使ってるものがみつかるわけで、今回のドキュメントは「技術的に正しい用語とされる確率が高そうな」「イテラブル」が無難じゃないですかね。などと。

#用語のゆれをぐぐる件数を絶対基準にするというのもある意味では一貫性があって面白いスタンスなんですけど、実際私も簡易検査に使うことはあるんですが、「イテラブル」と「イテレータブル」のぐぐる結果はどっちかに軍配を与えていいと思えるほど差がありませんでした(「どっちかに軍配を与えていいと思えるほどの差、の基準は完全俺理論です)。
#1件でも多ければそれを取るメソッドは、私は支持しないけど、一貫してれば批判する気があまり起きない程度にはつじつまがあってるなぁと思うのですが、この方法の問題点といえば、「比較している一方の単語は別の意味でも使われてて、今探したい意味だけ絞り込むのが難しいことがある」とか「イベントリスナ」と「イベントハンドラ」という対になる単語が何度も出てくる文章を書くのに「リスナ/リスナー」「ハンドラ/ハンドラー」のどっちを取るかで検索すると、「リスナ/ハンドラ」は対で使われることも多い(対で使われている場合は通常「−」の有無は統一されている)が、ドキュメントによっては「リスナ」だけ記述があって、「ハンドラ」が出てこない文書も非常に多く(これはプログラミングにおける「リスナ/ハンドラ」の役割と使用頻度をある程度体感している方なら同意してもらえそうだけれども、この場合、あるときに調べたとき「リスナ」は「リスナー」が多く、「ハンドラ」は「ハンドラ」が多かった。件数主義だと「リスナー/ハンドラ」になって、ついになる単語で「−」ポリシーがかわっしまう、という弊害(この弊害が大きいのかどうかは話は単純ではないですが) まぁ色々気になる点を挙げるときりがない感がありますが、まぁ
大抵の人には気にしてもあんまりいいことがなさそうな気はします。

というわけで、お後がよろしいようで。
 
| - | 00:53 | comments(0) | trackbacks(0) |
今更ながら
オンライン追跡者を識別する〜日経サイエンス2012年7月号より | 日経サイエンス 日経サイエンスはIT関係の記事もたまには載るのだけれども、2012/7号で上記タイトルはCollusionの話。今更ですが。ウェブに全文載ってるので本誌は今更必要かって感じですが。
| Mozilla | 09:10 | comments(0) | trackbacks(0) |
NHKスペシャル|コンピューター革命最強×最速の頭脳誕生 に便乗して本の紹介
NHKスペシャル|コンピューター革命最強×最速の頭脳誕生

まだ再放送がありますが、自分が読んだ本などから番組に大なり小なり関係したなぁと思ったものをいくつか紹介。まぁ、読んだものからだけなので、番組の「良い」関連書籍一覧ではありません。

IBM 奇跡の“ワトソン”プロジェクト: 人工知能はクイズ王の夢をみる 感想 スティーヴン・ベイカー - 読書メーター
割と最初の方に出てきたIBMの人工知能コンピュータ「ワトソン」について。技術的な解説はそんなに深くはない一般書です。もちろんこれは−本書を信じれば−人工知能としては素晴らしい到達点の記録ですが、あくまでクイズ番組向けにチューニングされたもので、もちろん、それ以外の問題に答えられないということはないですが、その辺のQAサイトの質問を問うたとして、出場したクイズ番組とまったく同じ正解率・速度を示すというものではないはずです(じゃあどの程度かと言われても私にはわかりません…)関連記事にIBMのスパコンが、クイズ問題を間違えた理由 « WIRED.jp Archives とか IBM 質問応答システム“ワトソン”がクイズ番組に挑戦! - Japan とか

コンピュータ同士の接続で高速で株価が乱高下する社会に関しては…そのものずばりではないですが、【書評】『つながりすぎた世界』ウィリアム・H・ダビドウ著、酒井泰介訳 - MSN産経ニュース つながりすぎた世界 感想 ウィリアム・H・ダビドウ - 読書メーター 私自身はこの書籍の見解にまったく同意ではないのですが(私自身はこの本をそこまで高くは評価してないものの、この書評から感じる悪印象よりはまともだ、と言いたい)。この本を手がかりに紹介されている本も読むと面白いかもと。そういえばソフトウェア社会のゆくえ 感想 玉井 哲雄 - 読書メーター とか、東証誤発注問題取り扱ってたなぁとか。ised 情報社会の倫理と設計 設計篇 感想 東 浩紀 - 読書メーター ised 情報社会の倫理と設計 倫理篇 感想 東 浩紀 - 読書メーター とか、既にちょっと古い気はするけど、情報社会のありかたへの議論。この議論が示唆する方向は私はそんなに支持するわけではないけれど、選ばれた論者が示す論点はそれなりに面白く。 膨張する監視社会 個人識別システムの進化とリスク 感想 デイヴィッド・ライアン - 読書メーター こちらはどちらかというとつながり社会への批判的なポイントを。どんどん番組のテーマからずれていく(汗)でも、こういうテーマなら ブラック・スワン―不確実性とリスクの本質 感想 ナシーム・ニコラス・タレブ - 読書メーター ブラック・スワン―不確実性とリスクの本質 感想 ナシーム・ニコラス・タレブ - 読書メーター も外せないかな。この本はもはや情報化社会本ですらないけど。まぁでもこうやって紹介するならポジティブ系本「フラット化する世界」紹介しろよって言われそう(日本で有名な数名の本は敢えて除くけどま、いいでしょ)。

脳のシミュレーション関連だと、脳の情報を読み解く BMIが開く未来 感想 川人 光男 - 読書メーター とか面白かったですね。これ系で特定分野を掘り下げた におい・香りの情報通信 感想 外池 光雄 - 読書メーター も面白く読んだかな。コミュニケーションするロボットは創れるか―記号創発システムへの構成論的アプローチ 感想 谷口 忠大 - 読書メーター もいいかも。

ある意味ではビッグデータ関係ということでは、 フェイスブック 若き天才の野望 感想 デビッド・カークパトリック - 読書メーター も、フェイスブックが繋げた社会とはといった言及も。

この辺で終わると、きっと、鈴木先生(誰)が、ゲーデル、エッシャー、バッハ―あるいは不思議の環 20周年記念版 感想 ダグラス・R. ホフスタッター - 読書メーター 系を外すなよとか、エルンスト・フリードリッヒ・シューマッハー(代表は『スモール イズ ビューティフル』)とイヴァン・イリイチぐらい紹介しとけとか言われそう。まぁこの辺になると番組との「直接の」関係を聞かれても私には答えられない範囲ですが、情報化社会との兼ね合いで彼らの論点を重要と思う人はいるかと思います。
| - | 23:27 | comments(0) | trackbacks(0) |
文書水増しアプリが欲しい
 きっと既に誰かが言ってて探せば構想はきっとあるし、断片的には既にそんなソフトはありそうな気がするけど、単に自分が調べてないだけです。

とはいっても、ニーズ自体はきっとあると思われるものの、ニッチすぎて開発費用を売り上げで元が取れる気がしない点がとても痛いです。

第1のニーズ。「なるべく意味を変えない言い換え候補をなるべく出してくれて、候補は数多く出せる能力があり、候補を出す際に文字数の増減量がちゃんとわかること」。だである→ですます的なものは勿論、類語辞典的なものから、漢字を仮名に開いて字数を稼ぐとか送り仮名のバリエーションで字数が違うとか、カタカナ表記の表記ゆれによる字数の違いとか、通常類語辞典ではカバーされてなさそうな「かもしれない」が「かもしれないがはっきりしない」に無意味に文字を増やす言い換えなどもサジェストしてくれる(厳密には意味が違うけどそこは脇におく)。

第2のニーズ。もちろん、ここで元の文章の文体を見てなるべくなら文体の変わらない変更を優先して出してくれるような機能も必須(前述のものでは漢字を仮名に開いたり送り仮名の揺れを利用する場合、どういうのを選ぶのかは本来は文体に左右されるというか、どういうルールで全体を統一するか等、まぁともかく地の文とあまりに浮いた字数稼ぎはあまりよくないということで…)。

第3のニーズ。全体を指定文字数にぴったり合わせるサジェスト。これは文字数を増やす方も減らす方も。ここで、単なる総字数指定以外にも、原稿用紙的な縦横文字数の枠で、改行や段落字下げ等を意識して行数を意識した文字数合わせも欲しい(ページをぴったりに納める系のテクニック)。変則的な紙面レイアウトにあるような写真や図の回り込みも対応しているとなおよい…。

などと要らんことを考えております。アホですね、私。
| 言語 | 06:23 | comments(0) | trackbacks(0) |
愛国的アルファベット呼称

本記事はネタです。

世間でアルファベットと呼ばれることの多い英字等。ここは議論の簡略化のために英字「ABCDEFGHIJKLMNOPQRSTUVWXYZ」の26文字に限る。この制限は趣旨には影響がない。この英字の各文字の日本での呼称は英語の影響を受けた「えーびーしーでぃーいーえふぎー」などとなっている。これを愛国的に「あーべーせーでーえーふーげー」などと変更するべきではなかろうかという提案である。この愛国的、の最大の基準は「日本語のローマ字表記上の各文字と発音の関連がわかりやすくすること」である。なのでこの点においては子音に使われる文字Bがべーであるのかびーであるのかはあまり問題ではない。この変更を行うのには大きなメリットがある。それは「えーびーしー」のという読み方を覚えても単語を読んだりする時に役にたつ度合いが少ないことにある。わざわざ英語のバイアスのかかった「えーびーし」と覚えたところでAを英語で「えー」と読む事ももちろんあるのだが、fanなら「あ」の方がずっと近いし、あまりにも「えー」より遠い場合が多すぎる。他の文字も子音に主に使われる文字も例外が多すぎる。そして、勿論なにより日本語のローマ字表記上の読みとはもっと異なる。こんな不便極まりない話しがあろうか。しかし、これがドイツ語スペイン語イタリア語フランス語等になると、その言語におけるアルファベット個別の読み方と発音の対応関係はずっとよく、例外が減る。実のところドイツ語スペイン語イタリア語フランス語であればどれを選んでも英語的読みよりは日本式ローマ字読みとの対応がずっといい、がドイツ語を選ぶとCのツェーは読みにくいしJのヨットは日本語にJを使うとじぇーなどの方が都合がいい。他を選んでも大なり小なりイマイチの文字がある。なので、これらの間をとって日本っぽくすればよい。そうすると、英語以外であるドイツ語スペイン語イタリア語フランス語などの言語を覚える時にも余計な英語読みの呪縛から多少なりとも離れて学習し易くなるというメリットまである。

「あーびーせーでーえーふーげーへーいーじぇーけーえるむーぬーおーぺーくーらーすーてーうーう゛ぃーわーえっくすーやーぜー」などなど。LとRをどっちも日本語ではら業だからどっちもらーと読んではさすがに都合が悪いのでラ行っぽさの強いRを優先してらーにしてLは違う呼び名にした。ほとんど日本語で使わないXはほとんどどうでもよい。強いて言えば日本語ローマ字変換IME等では使われることがあるのでその読みのどれかから選んでもよかったのだがXに関してはどれを選んでも無理筋っぽかったので諦めた。など。

繰り返すがジョークである。幾ばくかの本音を上記に織り交ぜてはあるが、詭弁の山であり、「仮にラテン文字の日本での名称を敢えて問題提起する時に重要な論点が網羅」されているわけでもなければ、「名称変更のメリットがデメリットを上回ると私自身が考えている」わけでもなく、「変更を訴える意図」自体が書いている本人にまったくないのであしからず。このネタの再利用の際には本人の意図しない(詭弁のつもりがない、等の)単なるデタラメが混じっている危険も大いにありうることに注意すること。

| 言語 | 00:49 | comments(0) | trackbacks(0) |
OSC Nagoya 2012

オープンソースカンファレンス2012 Nagoya - オープンソースの文化祭! に少しだけ行ってきました。

まぁ、色々他の予定との都合があってあんまり居られなかったんですけど。あと、あちこち体を痛めていてたちっぱがつらかったのもある><。
時間の都合その他で聞けたセミナーはオープンソースカンファレンス2012 Nagoya - イベント案内 | 2012-05-12 (土): 全てのエンジニアのためのWeb標準技術とのつきあい方だけでした。

講演の50分の中で講師が「こんなことを言うとMozilla Japanの浅井さん(dynamis)にお壊れるけど」とかざっと数えて7回ぐらいは浅井さんがどーのって言ってたと思う。満席すぎて座れなくって足が痛かったの…。

その他ブース感想とか。OSC浜松やる予定なんだー。浜松ぐらいの都市でやるのはそれはそれで地元へ広がりやすくていいかもね、とか。Mozilla Japanブースは人が多くって、昼過ぎ浅井さんが休む暇がなさそうだった…。LibreOfficeのアンケートに答えたり。毎年恒例スタンプラリーやってきたり。それにしても萌えキャラを全面に出したブースの多さが。増えましたねぇ。傾向として中小企業でわざわざOSCに出展する企業により目立つ気がしたのは気のせいなのかなんなのか。コミュニティ系でもわんくまさんも同人誌かわいいし(本の中身もコミュニティも勿論いいですよ!)、プロ生さんもいいキャラしてるし。まぁいろいろで思い出したらまだ書く事はいっぱいありそうだけどさっさとアップしてしまおう。

Check
| pc/net | 18:30 | comments(0) | trackbacks(0) |
Firefox3 Meter レビュープラス
 123456
78910111213
14151617181920
21222324252627
28293031   
<< August 2016 >>
+ NEW ENTRIES
+ CATEGORIES
+ ARCHIVES
+ LINKS
+ PROFILE