「単数形」を含む日記

■

quattro formaggi と言ってほしかった。

formaggio は単数形、formaggi は複数形。

Permalink | 記事への反応(0) | 13:19

ツイートシェア

■

単数形は「ニョッコ」

Permalink | 記事への反応(0) | 00:09

ツイートシェア

■1文字大和言葉の同音異義語

「日本語は同音異義語が多い」という風説に挙げられるのが漢語ばかりなので、大和言葉の例を調べてみた。

現代語だけに絞った表

ことわりがき

• 除いたもの
  • 動詞の終止形・連用形
  • 動詞や形容詞などの語幹
  • 省略形
    • 例：「あたしンち」の「ち」→「うち」の略語
• 古語・現代語の判定は緩めです。判断つかないのはフィーリングで付けました。
• 間違いあればそのうち直します。
• 英訳はやまとことばのニュアンスを捕捉するために漢字と合わせてお使いください。厳密な訳でない場合があります。
• 例に挙げた地名は単なる当て字の場合があります。
  • 当て字と思われるので除いた例：大垂水峠　→　稜線のたるむ地形にちなむか

Permalink | 記事への反応(0) | 23:08

ツイートシェア

■gitにおけるコミットログ/メッセージ例文集100

私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくまで単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。

要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのである。ググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか。

仕方なく自分でまとめたので、増田に垂れ流しておく。

はじめに

ここで挙げているコミットログは全て実際のコミットログからの転載である。当然ながら各コミットログの著作権はそれぞれの書き手にある。いずれも各英文でググれば出てくるし、フェアユースの範囲なら許してくれるだろうと考え名前とプロジェクト名は割愛したが、ここにお詫びと感謝を述べておきたい。

抽出条件だが、参考にできそうなコミットログを多く含んでいそうなリポジトリをGitHubのSTARの多い方からざっと目で見て適当に選び、それぞれ最新コミットから5000件抽出した（あわせて前処理として、コミットログ冒頭のタグ情報は消去した）。

結果として対象としたリポジトリは以下の通り。

• swift
• atom
• electron
• rails
• tensorflow

atomのみ5400件抽出していたため、計25400件のコミットログがベースである。このうち、以下の条件に合致するものは参考例にすべきでないとして一律排除した。

• ピリオドで終わっているもの(4535件)
• 小文字で始まっているもの(2242件)
• 過去形, 現在進行形で始まっているもの(1044件)
• Merge/Revertで始まっているもの(6555件)
• 絵文字を使っているもの(2171件)
• その他バージョン番号のみ等、参考にならないと判断したもの(313件)

こうして残った8540件を眺めながら、適当に切り出したのがこの用例集である。個人的に「うーんこの」と思った表現も、散見される場合は載せた。

ということで、以下用例を羅列していく。

用例集

オプションやフラグ、メニューを追加した

• Add -enable-experimental-nested-generic-types frontend flag
• Add --main-process flag to run specs in the main process
• Add Throws flag and ThrowsLoc to AbstractFunctionDecl
• Add "event" parameter for "click" handler of MenuItem
• Add File > Exit menu on Windows

ファイルを追加した

• Add npm start script
• Add build script
• Add SkUserConfig.h with blank SkDebugf macro

メソッドや機能を追加した

• Add TypeLowering::hasFixedSize()
• Add overflow scrolling
• Add convenience API for demangling
• Add a typealias to avoid a build ordering dependency between projects
• Add a helper method mayHaveOpenedArchetypeOperands to SILInstruction

実装を別のものへ切り替えた

• Use args.resourcePath instead of args.devResourcePath
• Use arrays instead of while loops
• Use auto instead of repeating explicit class names
• Use weak pointer instead of manual bookkeeping
• Change all uses of 'CInt' to 'Int32' in the SDK overlay
• Change Integer#year to return a Fixnum instead of a Float to improve consistency

新しく何かに対応した/機能上の制約を取り払った

• Add support for closure contexts to readMetadataFromInstance()
• Add support for activating and deactivating package-specific keymaps
• Add support for launching HTML files directly
• Add support for allocators that require tensors with zero
• Make it possible to call `reflect` multiple times
• Make it possible to set a data type for variables that come out of constants
• Allow atom-pane to be shrunk independently of its contents' width
• Allow null TextEditorComponent::domNode during visibility check

何かを使うようにした

• Use const for util require
• Use FoldingSetNode for ProtocolType
• Use unique text editor title in window and tab titles
• Use an empty object if metadata is ~null
• Use target_link_libraries for fat executable dependencies
• Use existing flatMapToOptionalTests dataset

より好ましい実装に改良した

• Make the clone function more generic
• Make IO faster for v8 compile cache
• Make model constructor argument to addViewProvider optional
• Make Browser::Quit more robust
• Make Menu.getApplicationMenu() public
• Improve incompatible native module error message
• Improve readability of multi-line command
• Improve folds behavior when duplicating lines
• Improve deprecated message on webPreferences options

何かを出来ない/しないようにした

• Don't bail reading a metadata instance if swift_isaMask isn't available
• Don't exit until the parent asks for an instance
• Don't include Parent pointer in Nominal/BoundGeneric TypeRef uniquing
• Don't use MatchesExtension for matching filters
• Don't use ES6 class for AutoUpdater windows class
• Don't use MatchesExtension for matching filters
• Avoid `distinct` if a subquery has already materialized
• Avoid infinite recursion when bad values are passed to tz aware fields

オブジェクトの内容や挙動を確認しやすくした

• Emit capture descriptors in their own section
• Emit field metadata for @objc classes
• Emit reflection info for protocols

Assertを追加した

• Add assert for role with app name in label
• Add assertions for no available bookmark
• Add asserts for properties

不要なコードを除去した

• Remove some dead code
• Remove some unused enum declaration
• Remove unused variable
• Remove unnecessary line feeds
• Remove trailing whitespace
• Remove debug statement
• Remove redundant mapType{Into,OutOf}Context() calls

コードを移動した

• Move function signature analysis to a Util
• Move markInvalidGenericSignature() to a method on TypeChecker
• Move diagnostic for stored properties in protocols from type checking to validation
• Move Doxygen converter into a proper MarkupASTNode visitor
• Move Module require to top

名前を修正した

• Rename environment -> environmentHelpers
• Rename watchProjectPath to watchProjectPaths
• Rename generic arguments
• s/grammarName/grammar
• fullVersion -> writeFullVersion

小さなバグやタイポを修正した, 警告を潰した

• Fix typos
• Fix a typo
• Fix a test
• Fix typo in DevTools Extensions tutorial
• Fix DownloadingState typo
• Fix includes order
• Fix mistake in tvOS availability
• Fix cpplint warnings
• Fix wrong markdown
• Add missing return
• Add missing period in comment

バグや好ましくない挙動を修正した

• Fix a memory leak in FSO
• Fix lifetime issues in ManagedBuffer.value
• Fix mangling for nested generic types
• Fix memory corruption in another circularity check
• Fix thread-unsafety in Process.Argument initialization
• Fix "Object has been destroyed" error in "page-title-updated" event
• Make Error.prepareStackTrace read-only (again)
• Make string slicing tests standalone
• Make sure showing success dialogs works correctly
• Make sure to emit closure bodies only once
• Make sure all native resources get freed on exit
• Make sure temp file will be cleaned up when base::Move fails

テスト、コメント、ドキュメントを追加した

• Add tests for pending pane items
• Add validation test for projecting existentials
• Add a basic test for opening an editor in largeFileMode if >= 2MB
• Add specs for moveSelectionLeft()
• Add failing spec for Menu.buildFromTemplate
• Add comment about map key/values
• Add TODO about blinkFeatures -> enableBlinkFeatures
• Add a design-decisions section to the CONTRIBUTING guide
• Add style.less examples
• Add docs for app.getLocale()
• Add documentation for --proxy-bypass-list

テストを削除した

• Remove a redundant test
• Remove an empty test

テスト、コメントを修正した

• Fix comment
• Fix outdated comment
• Fix failing specs on Windows
• Fix PersistentVector test for powerpc64{le}
• Update specs for deferred activation hooks
• Update successor/predecessor in validation tests
• Update some tests to use LifetimeTracked instead of hand-rolled canaries

ドキュメントを修正した

• Update README.md
• Update docs for marker callback
• Update documentation for mark*Position
• Update link to solarized-dark-syntax
• Improve documentation of `ses.cookies.set()`
• Improve readability in CSRF section of guide
• Improve spec description

表現傾向とまとめ

以上の用例をふまえ、今回の参考ログ8540件から先頭の単語を出現回数で並べると次のようになった。

コミットログの基本形はもちろん動詞 + 名詞である。名詞は固有名詞、複数形、不可算名詞が多いが、単数形の場合の冠詞は a が使われるか、あるいは省略される。the はまず使われない。

何かを追加した、という表現では非常に広く Add が使われる。メソッドからテスト、ドキュメントに至るまで大概これでまかなえる。

一方、何かを修正した、という表現では広く Fix が使われる。「何か」は typo や crash といった単語からメソッド名まで幅広い名詞を取るが、動名詞はあまり取らないのと、that節は取らないのでその点は注意が必要である。

Fix は「何かが正しく動くようにした」ことを示し、正しい動作内容が何かを説明しない。そこで正しい動作内容に言及したい場合は Make sure が使われる（こちらはthat節が取れる）。ただし Fix よりもニュアンス的に重い表現と思われ、Fix を使わず Make sure ばかり使うのはちょっとキモいのではないかと思う（Ensure はさらに重い表現っぽい）。

また、Fix は typo 以外でのドキュメント修正に対して使われることは稀である。対して Update はドキュメント、コメント、テストに使われ、本体のコードの修正に対しては使われない。本体コードの修正にあわせてテストも更新したなら Update が使われる。ただ、テスト機構それ自体のバグを修正したなら Fix である。

無駄な何かを単純に除去したなら Remove を使う。これまでのもの(A)から別のもの(B)に切り替えたのであれば Use B instead of A か Change A to B が使われる。新たに何かを利用するようにしたのであれば Use を、利用を取りやめた場合は Don't use を使うことが多い。

何かをしないようにしたなら Don't を、内部実装の効率化なら Make A + 比較級/形容詞 か Improve が使われる。

中身の変更を伴わない単なる名前の変更なら Rename A to B、コードや機能の論理上の場所を移動させたなら Move A to B である。

この辺はリファクタリングと呼ばれる行為と思うが、Refactor というぼんやりした動詞はあまり使われず、このように変更内容の種類に応じて動詞が使い分けられている。

余談

コミットログにはWhyを書くべきだ、というのを何かで見かけたので because とか since を使ったログがどの程度あるかを調べたが、8540件のうち22件だった。基本的に短く、シンプルに、一目で意味が取れるログが好まれる傾向がある。例えば get rid of とか2件しか使われておらず、圧倒的に remove である。

一方で、シンプルな単語だけど開始単語としては使われないものもある。例えば次のような単語である。Expand(9)、Extend(8)、Print(5)、Optimize(5)、Publish(4)、Append(4)、Modify(3)、Manage(2)、Revise(2)、Dump(2)、Insert(2)、Migrate(2)、Enhance(1)、Edit(1) 。いずれもカッコ内は8540件に対する冒頭での登場回数である。結局、より一般的で平易な単語で表せたり、Refactor同様に抽象度が高すぎると使われないのだろう。

おわりに

8000件もログを見たおかげで、迷いなくコミットメッセージが思いつくようになったのが個人的には今回書いてて最大の収穫だった。たぶんカンニングペーパーを作る行為それ自体が効率のいい学習になるという話と同じだと思う。

このまとめも100以上用例を転載してあるので、それを読むだけでも多少は効果があるんじゃないかと思う。同じようにコミットログ書きたくねぇなぁ英語わっかんねぇなぁと思っている人にとって、何か役に立つところがあれば幸いである。

Permalink | 記事への反応(4) | 09:24

ツイートシェア

■日本的にいうとスコットランドは北海道、じゃない。

イギリスのEU離脱問題で、Twitterとかで「スコットランドは日本でいえば北海道みたいなものだからー」という人が意外に多くてびっくり。

スコットランドは北海道と地理的環境は似ているけど、歴史的に言えば全然違うよ。

強いていえば、東北地方だよ。特にアイヌ文化がそこそこ残っている東北北部。

まあ、北海道こそアイヌ文化の本場だけどさ、スコットランド的な意味では歴史性が全然違うんだよ。

現代では東北も会津地方以外は「維新史観」に洗脳されて、他の地方との歴史の連続性を当然視する向きがあるけどね。

そんなわけで、イギリスの各行政区分「国（country）」を日本にあてはめると、

イングランド：

東北を除く本州の大部分。ロンドンは東京へ遷都されずに京都がそのまま首都になった感じ。

あと、カンタベリー大聖堂のあるイングランド南東部は、お遍路とか宗教的な聖地という意味で四国に近いかな。

でも、実はイングランド王室って、発祥がフランスだったりするので、日本に無理やりあてはめると

中国大陸発祥の一族が日本を征服したことになってしまうので、まるで騎馬民族征服王朝説ですね（笑）

ちなみに、イギリスとフランスの文化的な関係は、日本と中国の関係に結構似てます。

ウェールズ：

九州に近い。王太子が「ウェールズ公（Prince of Wales）」と呼ばれるように、他の地域に比べてイングランドとの一体性が強い。

九州（宮崎県）が皇室のルーツであるように、かの有名な「アーサー王の伝説」もウェールズに縁が深い。

ウェールズ人は怒りっぽいというステロタイプがあるけど、熊本人が怒りっぽい（肥後もっこす）というのとちょっと似てる。

スコットランド：

上で述べたように、東北地方に近い。中央政府（イングランド）にずっと対抗してきた歴史があり、文化や（遺伝子レベルで見た）人種も結構違う。

東北地方の地名にはアイヌ語に由来するものが多い（気仙沼の「ヌマ」とか）けど、スコットランドも独自の語彙が少なくない（ゲール語）。

じゃあ、同じケルト文化圏のコーンウェールとかどうなんだと突っ込まれそうだけど、強いていえば北陸～東北の日本海側あたりですかね？

北アイルランド：

この地域こそ北海道に近い。でも、本当は朝鮮併合後に日本から独立しなかった朝鮮半島、というイメージが最も似ている。

カトリックを中心とした民族運動についていけなかったプロテスタント系の住民が多く、アイルランド共和国から分離したので、

無理やりイメージすれば、今の北朝鮮にあたる地域（平壌～新義州あたり）だけが日本から独立しなかったという感じ。

ほら、こう書くだけでどうしてテロを伴う激しい独立運動が起きたか簡単に理解できるでしょう？ 最近はまったく平和ですが。

ついでに言うと、マン島とか王室保護領は、独自の文化圏という意味で沖縄および八重山諸島っぽい感じですかね。

＜追記＞

この前バラエティ番組で "United Kingdom" を「連合国」って訳したフリップを使っていたけど、

United Kingdom は「国連（United Nations）」とは違って、United が形容している名詞が単数形だから、

「（複数の）王国群の連合」ではなくて、「（複数の王国が）統合された単一王国」が正しいのね。

実は「連合王国」という公式訳はちょっと誤訳気味だというのは業界（何の業界だｗ）では有名な話。

イギリスはイングランド王室が各王国の王位を兼業することで、形式的に各王国の形を残しながらも

事実上の統一国家になった王国なんですね。

だから、複数王国の連合ではなくて、複数王国が統合された単一王国と理解するべきなんです。

Permalink | 記事への反応(3) | 21:43

ツイートシェア

■英語が学ばれない、誰でも分かる簡単な理由（ヒントは水曜日）。

もちろん様々な理由があるけれど、手軽に説明できる例として、私は「水曜日」を挙げている。英語で書いてみようか。

WEDNESDAY

さあ、読んでみよう。……うぇどねすでい？

不正解、「うぇんずでい」だ。

WE「D」N「E」SDAY　

括弧の部分は“発音しない”。

なぜ発音しないアルファベットを書くのか、発音する「E」と発音しない「E」の違いとは。法則性があるのか。大半の人が経験したであろう“躓き”だ。ほとんどの人は、この「水曜日」で英語を学ぶことに対して精神的障壁が出来る。

何かを学ぶ際、例えば算数だと方式だとか、いわゆる“パターン”を見出すよな。「1+1=2」を学んだ際、それとは別に「2+2=4」とかを学ぶ必要はない。だって、足し算を覚えればできるんだから。

言語も同じで、読み方や書き方に法則性を見出せば、その単語そのものを知らなくても大抵は読めたりする。その単語の意味を学ぶだけでいい。つまり、アルファベットの書き方と読み方を覚えれば、それを組み合わせた単語も読めるはずだ。と思った矢先に「水曜日」というよく使いそうな単語で「発音しないアルファベットがある」、更に「法則性もない」という“例外”をぶち込んでくる。

この“例外”の厄介なところは、「発音しないアルファベットが存在する」ということだけしか学べないところだ。法則性がなく、本当の意味で“例外”なのだ。なのでその都度、「発音しないアルファベットが存在する単語」の読み書き（そしてその単語のもつ意味も含めて）覚えないといけない。平面な道に一部だけ凹凸があるような、これら“例外”は学ぶ側に負担を与える。

この後も、「BERRY」などで「なぜ『R』が2ついるんだ？」となる。そして「BURY」という綴りが違うのに発音が全く同じ単語が登場し、「なぜ同じ発音なんだ」、「なぜ『BURY』の方は『R』が一個だけなんだ」、「こんなことになるなら、『無発音』という概念いらないだろ」と激昂するのは誰もが通る道だろう。

次点では、「MAN」の複数形が「MEN」、「複数形だけど単数形と同じ綴り」という単語などの登場が共感できるところだろうか。

もう分かっただろう。英語が学ばれにくい理由は単純明快。言語として洗練されていないからだ。つまり覚えにくい。

なにせ英語は様々な国の言語がもとになっており、いわばキメラ生命体。それで洗練されていたとしたら奇跡というほかない。そして、英語は特にそれが顕著なだけで、ほとんどの国の言語はそこまで洗練されていない。

もちろん、日本語だってお世辞にも洗練されているとはいえない。けれど、私たち日本に住んでいる人はそれを日常で使っているから、多少の違和は受け入れられる。更にいえば世界共通語ではないから、別に洗練されていなくてもいい。別の国の人に無理して学んで貰う必要がないのだから。

ちなみに、上記の例は本国の人がしていた話を参考にした。つまり、英語に慣れ親しんでいる人ですら、不満の多い言語ということだ。本国の人ですら不満の出る言語を、他国の人がうまく学べないからといって、個人の問題で片付けてしまうのは間違っていると私は考える。

英語を世界共通語にしなければいいのか、という話ではない。英語は洗練されていない。だから覚えにくい。という前提を共通認識にしようという話だ。それを踏まえたとき、今の「英語の勉強のさせ方」ももう少し最適化されていくのではないだろうか、というのが私の淡い期待だ。

Permalink | 記事への反応(5) | 00:00

ツイートシェア

■not前後の省略２

Introduction (Grammar in Your Pocket Book 1) (English Edition) の一節。

While real names are given for some parts of speech,

you won’t be overwhelmed with them.

Remember,

it’s what they do that counts,

not so much what they’re called.

However,

if you plan to go on “Jeopardy!” or get a better job or impress your friends,

you’ll need to know the difference between an adjective and an adverb.

「what they do that counts」は、

what they (=real names) do に that counts っていう関係代名詞節がかかってるもの？

real names = 本名; 実名

http://ejje.weblio.jp/content/real+name

count = 2a大切である，重きをなす 《★進行形なし》.

http://ejje.weblio.jp/content/count

訳は、「彼らが（習慣とか仕事として、過去から現在、さらに未来へ）行ってきた価値あること」かな？

「that counts」が do の目的語である可能性はない。

もしそうだったら、whatで抜き出されている目的語に当たるパーツがwhat節内からなくなるし、

そもそもthatという単数形とcountsっていう複数形が食い違う。

っていうか急にググりながら考えてたらわかった。

違う。

「that counts」は、「what they do」にかかる関係代名詞節じゃない。

何か適当にググってたら出てきたこの格言でわかった。

It is not what they take away from you that counts. It's what you do with what you have left.

Hubert H. Humphrey

Read more at http://www.brainyquote.com/quotes/quotes/h/huberthhu103505.html#0ui9Zodf0sZgODF5.99

http://www.brainyquote.com/quotes/quotes/h/huberthhu103505.html

そもそもwhat節を関係代名詞節で修飾、限定することって英文法的に可能なんだろうか。

それが可能だったとして、

what they do that countsが1つの名詞節だったら、

it’s what they do that counts, の最初の it が何を指してるのか不明だし。

最初のitは、that節を指してるってことを今理解した。

「that counts」で「価値あるもの」っていう名詞節になって、それを仮主語のitで受けて、「what they do」ですと言っている構造か。

やっと理解できた。

上の格言は、

「何を失ったか（＝奪われたか）は重要ではない。残されたものをどう扱うかが重要である。」っていう意味だ。

It's what you do with what you have left の後ろに、that countsが省略されている。

文頭のitはこの省略されたthat節を受けている。

結局、「it’s what they do that counts, 」の訳は、

「重要なのは（価値があるのは）彼らが行っている（行ってきた）こと（＝仕事、活動等）である。」が正しいことになる。

んで、やっと

not so much what they’re called.

のnotの前後に省略されているものが何か検討できる。

まず、

notが「Remember」にかかるものだと解釈するのは間違いだっていうのは俺にも理解できる。

Do Not Remember so much what they’re called. 彼らが何と呼ばれているかあまり思い出すな！

これはおかしい。

明らかにおかしい。

正しい省略前の文章を考える。

①(It's not) what they’re called (that counts so much).

これは間違いな気がする。

②That does not count so much is what they’re called.

これは文章構造自体が変わってるし、間違いだろう。

となると、これか？

③(It's )not so much what they’re called (that counts ).

ひょっとするとこれが正しいかもしれない。

④It's what they’re called that does not count so much .

直訳だと、あまり重要でないことは彼らが何と呼ばれていたかである、となる。

総合的には③が正解っぽいけどね。

まっ、「not so much」が「count＝重要である、価値がある」にかかるって理解しときます。

はい。

Permalink | 記事への反応(0) | 19:17

ツイートシェア

■http://anond.hatelabo.jp/20140513124958

データベース関連でも単数形と複数形どっちにしようか命名規則で悩んでしまう

Permalink | 記事への反応(0) | 12:56

ツイートシェア

■単数形と複数形は区別してよ

プログラムの話ね。

別に英語の文法としてだけじゃなく、実用的に問題あるっしょ？

List＜String＞ name = getName();

なんでこれが平気なんだよ。読みづれーよ。

namesだろ？

nameListでもいいか。

Permalink | 記事への反応(2) | 12:49

ツイートシェア