【ネコとか唄とかそんなもの。】

2008年05月 11-20日

よりぬき: 音楽雑記neko写真マンガ美術各種感想悪夢別の月/年

<< < 2008年5月 > >>
1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31
or other month/year

PR:日本留學情報網 taiwan2japan 從台灣向日本

Generated by nDiary version 0.9.4

2008年05月12日(月)

05/12●変更メモ

max-width:56emと足しました。FireFoxは日本語でだいたい56文字にしてくれるっぽいな。

自分が本を書いたときはCSS2実装系がないので、いまの元のCSSデータもCSS1だけで構築した。自分にデザインセンスがないのは昔から分かっているが、本に載せたサンプルの駆動例が残っていることに意味があるだろうと、あのころはしばらく変えなかった。

あれからもう10年目だ−−執筆完了1998年2月。そりゃわたしも年をくうし時代にも遅れるわ。24歳だった青年は34歳のオッサンになりました@2月24日。

ネガティブに言えば、自分の社交性のなさを再確認した10年だった。もっとも、大事な知人が増えたのはこの10年。知識と技術をたくさん身に付けたのもこの10年だわな。

無職+病気のわたしはこれからどうしようかねえ。唯一の武器だと自分が思っていた脳みそも いまは病気でまわらないんだわ。

05/12●脈絡ないけどVLCオプションメモ

"S:\Program Files\VideoLAN\VLC\vlc.exe" --started-from-file "%1" --filter="deinterlace" --deinterlace-mode=blend --aspect-ratio="16:9"

[calender]

2008年05月15日(木)

05/15●「話すとおりに書けばいいのよ」にNGを出す論review

ちょうどいいサンプルが出てきたので書いてみる。−−まとめ不十分だが 載せます。

‖サンプル
「凄いねこの方法。化粧水・乳液をレンジでチンする美容法:アルファルファモザイク

同記事のはてなブックマークほとんどのひとが「凄いネコの方法」と読んでいる。作者意図からすると誤読なのだが、編集者としては「誤読が起こりやすい記述をしたほうが悪い」となる。

この例では、単語の区切りが不明瞭になっている。

‖喋る技法 と 書く技法 の違い

日本は作文技術の教育がズサンで、わたしが子供のころは「みんな、日本語はしゃべれるでしょう? だったら書けます。思ったとおりに書けばいい、話すとおりに書けばいいのよ」てのが横行していた−−改革したという話は聞かないので、たぶん今もだ。

ところが、しゃべる技術と書く技術はまったく違う。

話すときに「すごいねこのほうほう」で意味が通じる理由は、抑揚あるいは無音によって、「すごいね」「この」を区切るから。−−喋るときは喋るときの技術が必要になる。

書くときは 書くときの技術が必要になります。

‖結合力
凄いねこの方法。

一般的な分析技術を使うと、こんなかんじ。

  • 「凄い」は結合力が強い
  • 「ねこ」は結合力が強い(単語が存在するから)
  • 「い」「ね」の分離力が強い
  • →結果、凄いネコと読んでしまう。

「ねこ」じゃなかったら問題ではないか と問われると、実はそのとおりで、「そこ」にするだけで問題は消滅する。「ねそ」という単語はないからだ。

凄いねその方法。

「凄い」をひらがなにするだけでも 誤読の可能性は減る。

すごいねこの方法。
  • 「すごい」は結合力が強くない=「い」「ね」の分離力は弱い
  • 「ねこ」の結合力は強い
  • だが、「ねこの方法」だと全体が通じない
  • →結果、「すごいね この方法」と読んでくれる可能性が高まる。

(どっちにせよ 巧い文章ではない。)

ここで気が付いて欲しいこと→結合力は 品詞(名詞とか形容詞)じゃなく 表記文字で変化する。

‖余談:正則にする

語順を正則にしたほうが 解決が早い。−−この「正則」は教科書文法ではなく、本多勝一の方法にしたがう。

この方法すごいね|この方法は凄いね

分析としては、正則を崩すからテンが必要になる。

  • この文章の正則と思われるものは「この方法は凄いね」
  • 逆転させるのでテンを打つ→「凄いね、この方法は」
  • 味わいのために末尾「は」を消す

本多勝一[日本語の作文技術]講談社Y。当人の政治思想は別として、この本が紹介するライティング技術はすばらしい。)

‖結合力を制御する

きのこる先生(ググってください)は、もともとが正則順序。したがって、テンが使える保証がない。

この先生きのこるには。

テンを打てるかどうかは、前後の文脈による。−−一般の誤解では、「短い文章のときにテンを打っていい箇所」で長文でもテンを打ってしまう。その方法は失敗するケースが多い。このへんは本多勝一の句点法則にまとめが詳しい。

OK:この先、生きのこるには。
NG:いったいぜんたいこの先、生きのこるにはどうしたらいいですか?
OK:いったいぜんたい、この先も生きのこるにはどうしたらいいですか?

この場合は、別の方法で結合力を上げる。漢字にしてもまだ読みにくいが、きのこる先生は発生しない。

この先生き残るには。

さらに分離するため、極論すれば四分アキで物理的に分離。

この先 生き残るには。

まだダメ。もっと分離を良くするために助詞を足す。−−ここまでやって ようやく成立する。このケースなら ひらがなでもギリギリ成立すると思うが いかが?

この先も生き残るには。この先も生きのこるには。

(やっぱ漢字のほうがいいことは間違いないな。)

‖分かち書きを意識しませう

テンとマルは、実は西洋からの輸入の記号だ。その記号が入る前は、日本語はテンマルなしで成立していた。そのころから あるのが分かち書き

英語の分かち書きはスペースを使う。したがって、次の2つ目の文は成立しない。

I do not know. idonoteknow. leave me.

(カンマは長文の句の区切りにしか打たない。日本語でも句の区切りにしか打たないのが原則。分かち書きのためにカンマがあるのではない。)

日本語も、手書きの場合は空白を駆使する。さらに それだけではなく、漢字・ひらがな・カタカナで分かち書きできてしまうのが 日本語のいいところだ。

凄いネコの方法。すごいネコの方法。

記号の種類で分離することによって、誤読の余地がなくなる。−−ただしネコのケースではありますが。

  • 漢字は、意味を明示することで文字の結合を強くする+分かち書きを明示する
  • ひらがな+カタカナも、結合を強めたり分かち書きに使える

こういうのを使いこなすのが「日本語を書ける」状態、書く技術がある状態。これは訓練しないと身につかない。

ちうわけで、喋れても書けるとは限らないですよ>学校教育

(ああそうか。日本語も「てふてふ」のままなら もっと強く意識できたのかもね。発音が「ちょうちょう」でも表記は「てふてふ」だったりした時代。)

‖余談:英語の工夫

わざとくっつけるスラング表記はある。その場合は単語表記が変化する。

I DUNNO. Okay? I do not know. Dunno. leave me.

正則表記すれば「do not know」、音どおりにスラング表記すれば「Dunno」。英語でも喋る技術と書く技術は違う。idonoteknowとはやっぱり書かない。

[calender]

2008年05月16日(金)

05/16●訂正:C言語ポインタの*解説*に→*入門*にreview

指摘受けまして

  • 詳細理解には必要
  • 実装がそうなってる

というわけで、学習要綱構成を再検討します。

目標:

  • (1)ポインタ概念を混乱せず飲み込めるようにする
  • (2)C既存ソースのメンテ時にソースのポインタを読めるようにする

提示:

  • ポインタ説明では、配列との関連より先にmalloc()などを説明したほうがいいのでは

由来:

  • たぶん私はC固有じゃなくて《概念共通》を先に教えたがっている

以下は訂正前のまま。

05/16●C言語ポインタの解説に配列を出すひとが後を絶たないのはなぜだろう論review

‖トンデモ説明が再生産されるメカニズム

4月1日前後に評判になったもの→C/C++のポインタの機能--変数の場所(ZdNet Japanでの記事:沖林正紀)

この記事自体は 「ミスしかない」(正しい部分がほとんどない)ので話題になったのだが。

そのまえに。

なぜC言語入門でポインタの話題を出すとき、配列を例にしたがる著者が多いのだろう? 概念は本質的に無関係なのに。−−実装で繋がっているだけで。

理由は。たぶん。「その著者が勉強したときに そのように習ったから」なのだろうなーと。

1996年ごろからわたしがHTML本のアレが気になったころも、極論すると「書いてるひとが学んだとき、文字サイズはH1と習ったし、インデントはBLOCKQUOTEと習った」ちうのが諸悪の根源だった。それと事情は変わらぬのだろう。

(いまCを実務で使うシーンや需要がどこにあるのかは、実務を知らないわたしには分からぬ。そしてHTMLのときの同様に、《事務が分かるひとで 本を書きたい願望やら時間余裕があるひと》は おらんのだろう。−−同じことはJavascriptでもなんでも発生する。)

教育者教育ができていないと、トンチンカンな本が生産され続け、悪循環になる。どっかできちんと断ち切って欲しいな、と思ったり。

‖目的意識なき学習指導には失敗が多い

本だけじゃないが、スタートとエンドを決めないと、話は散漫になる。

たいていの本は(出版社にいた経験から)言語そのものを文法的に入門解説したり、まあExcelでもWordでもそうなんだが 操作やらソフトそのものを解説したがる。−−でもそれは、スタートも不明瞭だし、エンドも不明瞭だ。

比喩するなら、読者の目標が「イギリス旅行の必要ができたので、間に合わせでもいいから勉強したい」であれば、[指差し英会話]が役に立つ。文法の詳細やら言語比較は必要ないどころか、かえって混乱のもとだ。−−英語なら そういう学習教材がちゃんと出ているが、PC/ITだと少ない あるいは あっても気がつけない程度なのが実情。

たとえばWeb用途でPerlを勉強したいひと向けなら、極論すると制御構文は後回しでいい。わたしなら、こんなかんじで企画を組む。

  • CPANなどのライブラリ充実度を説明
  • 既存ライブラリの探しかたを解説
  • そのライブラリを使えるようにするためのローカル/サーバー設定(どこにファイルを置くetc)
  • 実例

Javascriptでも いまはライブラリ利用がエンドユーザーでもWeb運用仕事でも多いはずで、そうなると いきなりライブラリやらクラスを知る必要があるし、DOMイベントモデルなど言語以外の知識も必要になる。

だが、たいていの本はやっぱり変数宣言やら制御構文から入る。−−経験上、こういう本は「著者が書きやすいことから書いてしまっている」あるいは編集者が分かる部分から書かせてしまっている。

(同様なところで、現役時代2003年に「Excelで日報を書く」本の企画を立てたが、わたしがプレゼン下手なこともあり 一蹴されてしまった。その時代、Excel入門といえば「セルに数字を書くところから始める」と上司は思い込んでいたし、「レポートはWordで書いたほうが便利だから、そう教えては?」といわれた。)(そのネタは編プロさんにあげて、他社から出た。)

だいぶ話がズレた。戻る。

目的意識がない本は、スタートもエンドも散漫で、全体としても役に立たないことが多い。

C言語を使わねばならぬのであれば、ポインタ操作を書くこともあろう。だが、配列から教えるのは たぶん悪き慣習だ。

わたしはさすがにプログラム本の現状を変える力はないのだが、誰かきちんとやってくれんかね? あるいは、すでに良書があるなら、ナレッジまとめを作ってくれんかね?

少なくとも技術評論社から[C言語 ポインタ完全制覇]てのは出ててね。明確に「3・6 頭に叩き込んでおくべきこと ―配列とポインタは別物だ!」と書いてある。本の評判もよかった。→出版社作者

05/16●なぜかC言語ポインタの解説に配列を出すひとの発想を推測review

以下は 私の記述のほうが語弊が多いので削除。

[calender]

2008年05月17日(土)

05/17●ジェネレーションギャップ

xnekoを知らない世代が増えていて驚く。よく考えたら驚くようなことじゃない。

05/17●著作権・商標・仁義、二次創作・二次的著作物 メモreview

自己知識が間違っている/説明もできていない ところが多すぎるので削除。

[calender]


goto: latest or index or 拍手する
2004 01 02 03 04 05 06 07 08 09 10 11 12
2005 01 02 03 04 05 06 07 08 09 10 11 12
2006 01 02 03 04 05 06 07 08 09 10 11 12
2007 01 02 03 04 05 06 07 08 09 10 11 12
2008 01 02 03 04 05 06 07 08 09 10 11 12
2009 01 02 03 04 05 06 07 08 09 10 11 12
2010 01 02 03 04 05 06 07 08 09 10 11 12
2011 01 02 03 04 05 06 07 08 09 10 11 12
2012 01 02 03 04 05 06 07 08 09 10 11 12
2013 01 02 03 04 05 06 07 08 09 10 11 12
2014 01 02 03 04 05 06 07 08 09 10 11 12
2015 01 02 03 04 05 06 07 08 09 10 11 12
2016 01 02 03 04 05 06 07 08 09 10 11 12
2017 01 02 03 04 05 06 07 08 09 10 11 12
2018 01 02 03 04 05 06 07 08 09 10 11 12
2019 01 02 03 04 05 06 07 08 09 10 11 12

よりぬき: 音楽雑記neko写真マンガ美術各種感想悪夢別の月/年

<< < 2008年5月 > >>
1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31
inserted by FC2 system