はてなキーワード: 名詞とは
単に自分が知らんだけで,すでにあるかもしれない。上ほど緊急性・重要性が高い。
1.アルミホイルを噛んだときに感じるクオリアに対応する擬音 → 歯が○○○○する
2.イクラちゃん・ドラえもんの足音に対応する擬音 → ○○○○
3.おっさんがするくしゃみの「ハーックション!,…ちくしょう!」の「ちくしょう」に該当する部分の名詞 → ○○○○
4.言いながら,すでに言ったことを後悔し始める現象 → ○○現象
5.大してエロくもないページ・動画シーンで絶頂してしまったときの気持ち(形容詞) → ○○しい
6.コミュニティは狭ければ狭いほど,掟が強ければ強いほどその結束力を増す → コミュニティの○○性
7.うまく聞き取れなかったとき,でもとりあえずしておく返事(名詞),または返事をすること(動詞) → ○○(する)
8.あえて本気を出さないことで,「これは本気じゃないから失敗するのは当然」と保険をかける行為 → ○○を○○る
9.ホッテントリを読んだ後ブコメを見たら,多数派が自分の意見と正反対だったときに,さも自分は多数派だったかのように記憶を上書きし,スターを付ける人間(主に俺)につけるべき俗称 → ○○○○○
(*1)が(*2)で(*3)を(*4)したとき、(*5)な(*6)が(*7)(*8)。
今から(*8)年くらいのノーベル平和賞(*9)の(*10)を(*11)る!
xevraさんなんかはすでにゆるキャラと化していて、はてなも面白いテーマパークになりつつあるなあと感じている現在、
かれのアクセスになるのは癪なので特定できる名詞は出さないが、
特徴として、彼は人気記事にことごとくトラックバックして自分の考えを綴っている。
その考えがとても稚拙で訴求力が低く分析も甘いためなにも心に響かない。
故にブクマも本当につかず、いつも自分でつけたであろう「1user」がタイトルの横にかがやいている。
そんな誰も納得も共感しない、打率が低すぎて素振りしかしていないのだが、継続だけはしている。
今回こそはと記事を覗くと、相も変わらずそこには分析口調のただの主観が綴られている。
人気記事にトラックバックされた彼のブログのタイトルを見るたびに、
通りすぎざるをえなくなりシニカルな笑いがこみ上げてくる。
彼は若くしてプログラミングの世界に入り、数多くのツールやサイトを構築しています。
私は出会った時こそ向上心のある素晴らしい子ではないか、と思いました。
その頃僕は学校でのストレスで毎朝気持ち悪くなったりしていて遅刻が数回あったので、より優れている人だと間違えた解釈をしていました。
しかし、その人の心の奥深くまで踏み込んだ暁には、彼が大変に面倒であることを知ってしまいました。
ある日のこと、僕が彼とあるゲームで作業をしている時、「おいおいおいおいおいおいおいおい」というメッセージが飛んで来ました。
何事かと思ったらアイテムをここの倉庫に入れないでそこに入れろ、とのことでした。僕は物事一つ指摘するのにそこまでオーバーじゃなくてもいいだろうと思いましたが、彼が中学生になったばかりのこともあってそこまで気にせず流していました。
しかし一緒にゲームをしていると不必要に注意を強調したり、何か僕がすると全部悪いかのように振る舞うので、僕も無視できず「文章と実際に発音して会話をする状況とでは受け取る人の感じ方は違う。文章の表現を柔らかくしたほうがいい」と伝えたら「?」とだけ帰って来て、僕がもっと詳しく説明しても微妙な反応だったのでけっこうイライラしました。
彼は基本的に短い文章にも主語をつけません。名詞を修飾したいのか主語の動作を表したいのかわからないことが多く、また「あれ」という言葉を多用していて雰囲気でしか感じ取れません。 人の気持ちを考えられないのは、果たして良い技術者と言えるでしょうか?技術者には多くのコミュニケーションが必要で、その職種上具体的な発言が重要となるでしょう。もっとも彼は将来何になるか考えてないようですが、腐っても便所で形成されるTwitterやSNS、インターネットに入り浸ってどうするのでしょうか。国語も数学も英語も、理社も小学6年から進んでいません。かろうじて読み慣れた単語のある英語ドキュメントをほんの少しだけ読めるぐらいで、いわば世の中知らずです。インターネットは現実の全てを代替できません。いくら文章上でやり取りを繰り返しても、彼の使うサービスで残るのは嫉妬と悲しみと苛立ちと自尊心の欠如でしょう。家族はどう思うのか?理解できません。インターネットリテラシーどころか伝達のエチケットさえ守れないようでは将来明らかにまずいでしょう。まだ救いは消えていません。周りの大人が少しでも時間を割いて、彼を社会的な自立ができる人間に導いてほしい限りです。
文字種が多いから日本語ダメというが、文字種によって文法的な役割が大体推測できるので読むのが速くなるという利点がある。例えばカタカナならほとんど名詞だと推測できる。
さらに日本語は単語についている助詞によって語の役割が決まる(そのため語順は比較的自由になる)ため、タグである助詞を見つけるのがとても大切になる。かな漢字混じり文によって漢字やカタカナの間に助詞が浮び上がって見えるために助詞を見つけやすくなっている。
またfMRIで脳を観察してみると、表音文字と表意文字では処理する領域が分かれており、これらを併用することにって効率的に脳を使えている可能性がある。
一方で、音声に関していえば、日本語は音素が少ないので単位時間当たりの情報量は減る。結果として同音異義語が多くなり文脈を読む必要がある。
まとめると、日本語のかな漢字混じり文は視認性、情報密度に優れており、速く読むことができる。しかし話し言葉でいえば欧米の言語の方が情報密度が高く短時間で意味を伝えられる。
私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくまで単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。
要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのである。ググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか。
ここで挙げているコミットログは全て実際のコミットログからの転載である。当然ながら各コミットログの著作権はそれぞれの書き手にある。いずれも各英文でググれば出てくるし、フェアユースの範囲なら許してくれるだろうと考え名前とプロジェクト名は割愛したが、ここにお詫びと感謝を述べておきたい。
抽出条件だが、参考にできそうなコミットログを多く含んでいそうなリポジトリをGitHubのSTARの多い方からざっと目で見て適当に選び、それぞれ最新コミットから5000件抽出した(あわせて前処理として、コミットログ冒頭のタグ情報は消去した)。
atomのみ5400件抽出していたため、計25400件のコミットログがベースである。このうち、以下の条件に合致するものは参考例にすべきでないとして一律排除した。
こうして残った8540件を眺めながら、適当に切り出したのがこの用例集である。個人的に「うーんこの」と思った表現も、散見される場合は載せた。
ということで、以下用例を羅列していく。
以上の用例をふまえ、今回の参考ログ8540件から先頭の単語を出現回数で並べると次のようになった。
Add | 1149 |
Fix | 1014 |
Update | 584 |
Remove | 566 |
Use | 382 |
Don't | 260 |
Make | 228 |
Move | 178 |
Change | 103 |
Rename | 85 |
Improve | 76 |
Avoid | 68 |
Allow | 65 |
Implement | 60 |
Handle | 58 |
コミットログの基本形はもちろん動詞 + 名詞である。名詞は固有名詞、複数形、不可算名詞が多いが、単数形の場合の冠詞は 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以上用例を転載してあるので、それを読むだけでも多少は効果があるんじゃないかと思う。同じようにコミットログ書きたくねぇなぁ英語わっかんねぇなぁと思っている人にとって、何か役に立つところがあれば幸いである。
イギリスのEU離脱問題で、Twitterとかで「スコットランドは日本でいえば北海道みたいなものだからー」という人が意外に多くてびっくり。
スコットランドは北海道と地理的環境は似ているけど、歴史的に言えば全然違うよ。
強いていえば、東北地方だよ。特にアイヌ文化がそこそこ残っている東北北部。
まあ、北海道こそアイヌ文化の本場だけどさ、スコットランド的な意味では歴史性が全然違うんだよ。
現代では東北も会津地方以外は「維新史観」に洗脳されて、他の地方との歴史の連続性を当然視する向きがあるけどね。
そんなわけで、イギリスの各行政区分「国(country)」を日本にあてはめると、
東北を除く本州の大部分。ロンドンは東京へ遷都されずに京都がそのまま首都になった感じ。
あと、カンタベリー大聖堂のあるイングランド南東部は、お遍路とか宗教的な聖地という意味で四国に近いかな。
でも、実はイングランド王室って、発祥がフランスだったりするので、日本に無理やりあてはめると
中国大陸発祥の一族が日本を征服したことになってしまうので、まるで騎馬民族征服王朝説ですね(笑)
ちなみに、イギリスとフランスの文化的な関係は、日本と中国の関係に結構似てます。
九州に近い。王太子が「ウェールズ公(Prince of Wales)」と呼ばれるように、他の地域に比べてイングランドとの一体性が強い。
九州(宮崎県)が皇室のルーツであるように、かの有名な「アーサー王の伝説」もウェールズに縁が深い。
ウェールズ人は怒りっぽいというステロタイプがあるけど、熊本人が怒りっぽい(肥後もっこす)というのとちょっと似てる。
上で述べたように、東北地方に近い。中央政府(イングランド)にずっと対抗してきた歴史があり、文化や(遺伝子レベルで見た)人種も結構違う。
東北地方の地名にはアイヌ語に由来するものが多い(気仙沼の「ヌマ」とか)けど、スコットランドも独自の語彙が少なくない(ゲール語)。
じゃあ、同じケルト文化圏のコーンウェールとかどうなんだと突っ込まれそうだけど、強いていえば北陸~東北の日本海側あたりですかね?
この地域こそ北海道に近い。でも、本当は朝鮮併合後に日本から独立しなかった朝鮮半島、というイメージが最も似ている。
カトリックを中心とした民族運動についていけなかったプロテスタント系の住民が多く、アイルランド共和国から分離したので、
無理やりイメージすれば、今の北朝鮮にあたる地域(平壌~新義州あたり)だけが日本から独立しなかったという感じ。
ほら、こう書くだけでどうしてテロを伴う激しい独立運動が起きたか簡単に理解できるでしょう? 最近はまったく平和ですが。
ついでに言うと、マン島とか王室保護領は、独自の文化圏という意味で沖縄および八重山諸島っぽい感じですかね。
<追記>
この前バラエティ番組で "United Kingdom" を「連合国」って訳したフリップを使っていたけど、
United Kingdom は「国連(United Nations)」とは違って、United が形容している名詞が単数形だから、
「(複数の)王国群の連合」ではなくて、「(複数の王国が)統合された単一王国」が正しいのね。
実は「連合王国」という公式訳はちょっと誤訳気味だというのは業界(何の業界だw)では有名な話。
もともとは字書きなんですが、以前に数年ほどDTMにハマっておりました
15曲ほど作ってみたのち、「ああ、向いてないんだな」と実感しましてやめたのですが、そのときに歌詞を考えた経験がちょっと懐かしいです
最近になって、歌詞に困るDTMerさんの話を耳にしまして、歌詞の書き方くらい検索したら出てくるんじゃないかと思って検索したら本当に山ほど出てきたので、順番に読んでみて納得したりこいつなに言ってんだと思ったり技巧派に感心したりして大変楽しかったのですが、なんか気になるところもありました
テーマとか世界観とか押韻とか破擦音とか基本的なところはいろんなサイトさんを見てください
あと、たぶん有料の書籍などでは普通に書かれているんじゃないかと思いますので過剰な期待はしないでください
単なる個人的まとめです
・メロとイントネーションをあわせる
ありがちなのが、歌詞では「好きなの?」と疑問形なのに、耳にすると「好きなの」と告白してるようにしか聞こえないといったパターン
メロが音階上がるところはイントネーションも上がる言葉、下がるところは下がる言葉を使ってください
わざと逆にもっていって強調する術もありますが、多用は禁物です
・同音異義語に注意する
「疾走」「失踪」とかです
「夜の闇にシッソウ」など、どちらでも通ります
間違えられることは少ないと思うのですが、とくに体言止めの場合には注意が必要です
・撥音に気をつける
「ん」です
一音として数えないほうがいいことも多いですしテンポもよくなります
もともと発音しにくく、強調する場所で使われると歌いにくくなりますし、補正するのも大変だと思います
ボーカルさんが上手ならそれほど気にすることはありませんし、歌うときにしゃくることが前提で強調させるのは逆にいいと思います
・促音は一音として扱うか
「っ」です
一音として扱わないほうがいいことが多いのですが、フレーズごと強調したいときだけは数えるのもありでしょう
長音「ー」として扱うことで強制的にしゃくらせることも可という感じでしょうか
ずっと真面目に一音一字はだるいので、二番のAやBをわざとすこしあわない字数にして変化をつけるのもありです
四分音符を八分音符ふたつに刻んだりですね
わりとよくあります
メロやオケとの兼ね合いで考えてください
「夢」を「希望」に置き換えたとすると、夢は曖昧に憧れるものに対し、希望は明確に求めるものの意味合いが強くなります
前者は夢見る乙女もしくは玉の輿狙いでしょうが、後者は王子様その人にすでに心当たりがあるようです
・耳慣れない言葉は浮く
かっこいい言葉や気を惹く言葉を探すより、よく使う言葉のかっこいい言い回し、気を惹くフレーズを考えたほうが失敗しません
「漆黒の夜に君とふたりで」より「暗い部屋で朝を待つ僕ら」のほうがマシです
さすがに「漆黒」とか使う方はもういなさそうですが
などとまあ長々と書いてみたのですが、実際に歌詞の書き方なんてものを全部きっちり守っていたらたいがいつまらないものしかできないでしょうね、というのが実感です
---
1年の間、プログラマとして働いていたが、続けていくことが無理だと思い、さようならする話。
プログラマになる前は、コーヒー屋で働いていた。しかし、色々とあり辞め、職業訓練校に通ってプログラミング(php)を学び、60人ほどのソフトウェア開発会社に就職した。
会社に入ると、まずC#の研修があった。研修と言っても、C#で内製ツールを独りで作るという研修だった。この研修中に「あれ、オレ、プログラム書けねー」と思ったりしたが、研修は終えることができたし、社内の人にも「なかなか良く出来ている」と言ってもらえ、大丈夫だろうと思っていた。
研修が終わり、C#の社内で実際に使われているツールに、機能をいくつか追加する仕事を振られた。前任者にどんな設計になっているのか大雑把に聞き、なんとなくイメージができ、コードを読み始めたのだが、これが全く意味不明で、何のために有るかがわからないクラスが大量にあった。名詞の王国だと思った。前任者に、何故このクラスは、この単位で分割されているのか聞くと、「単一責任の原則だよ」とか「hogeパターン使うと、後から機能追加しやすいじゃん」というような回答をもらった。納得は出来なかったが、プルリクも承認されて、このツールがデプロイされていたので、社内的にも、このコードは、クソコードと言われる物では無いはずだと思ったので、自分もプログラムを書き続けていれば、こんな感じの設計に慣れてくるんだろうと思った。モヤモヤは残っていたものの、仕事はしなければいけないので、前任者のコードに習うように、クラスを追加したりして、機能を追加した。プルリクを出すと、設計には何も言われずに、タイポや、テストコードを注意されただけだった。指摘された点を修正すると承認された。振られた仕事は完遂した。が、結局最後まで、モヤモヤは消えなかった。むしろ、モヤモヤモヤモヤになった。
次に振られた仕事は、内製ツールを設計から自分で行い作成する仕事だった。言語はGoだった。Goで書いてと言われた時は、以前からの自分のモヤモヤはオブジェクト指向のせいで、モヤモヤしているんじゃないかとも思っていたので、喜んで!という感じであった。が、Goを触ってみると、結局、Goも継承の無いオブジェクト指向言語やないかと思った。Goの標準ライブラリのinterface名もHogerみたいな感じに接尾辞に-erを持ってくることが慣習らしく、この命名だと、interfaceを満たす構造体自身が-erになるので、正にオブジェクトだなぁと思った。巷での「Goはオブジェクト指向ではない」というのに期待していたのだが、自分にとっては、とてもオブジェクトしていました。
Goに対する印象は良くなくなったが、ツールの設計をしないといけなかったので、Goの構造体をC#のクラスに見立て、前回の前任者のコードのように、単一責任も持つ構造体に(無駄に)分けて、プログラムを書いて、プルリクを出した。自分でクソなコードだと思いながら。だけれどもレビューでは、「errorのチェック忘れ」「標準ライブラリにこの機能ある」「こんな風に書ける」といった感じだった。こんなコードで良いんかよと思ったが、良いらしい。ワケワカメだった。
ここらで、プログラムを書く仕事は、無理だと悟った。現実世界は、自分が自然だと思う方法と違う方法で、プログラミングをすることを強要してくる。
ちなみに、仕事ではC#とGoを書いていましたが、オブジェクト指向と仲良くなるためにSqueak(Smalltalk)で、オレオレ言語を作ってみたりもしましたが、何が嬉しくて、オブジェクト同士のメッセージパッシングでプログラムを作るのかわかりませんでした。
Clojureは、気持ち良くプログラムを書いていても、Javaが顔を出すところでフラストレーションが溜まってしまって、つらくなりました。
Common Lispは、自分が触った言語の中でも、秀でて良いと思いました。プログラマを辞めても、プログラム書く必要に迫られたらCommon Lispで書こうと思うくらいにです。Land of Lispが楽しいです。あと、CLOSの総称関数の考え方が大好きです。
最後に、この投稿は、一種の決別の表明です。いつまでも、自分に向いていなかったことに、時間を掛けてしまっている自分との決別です。