  |
はてなキーワード: TEXTとは
Gamewithが憎い。
私は昨年リリースされた某人気ソーシャルゲームの攻略ブログを運営している。
そのアプリの元作品が大好きなことから、自意識過剰かもしれないが熱量と知識量では日本でもトップクラスだと思っている。
Gamewithは、昨年上場を果たしたゲーム攻略サイトの大手だ。
おそらくソーシャルゲームアプリで検索したら、アプリによっては公式を超えてトップに表示されるレベルで、Googleからの評価が高い。
攻略ブログを運営している私にとってGamewithはもちろんライバルになる。
私のブログはGamewithにとっては吹けば飛ぶような規模だが、それでも人によっては私のブログの情報を優先してくれることが多いレベルになってきた。
そして、日々アプリの勉強をすればするほど、Gamewithの情報の杜撰さに腹が立っている。
負け犬の遠吠えかもしれないが、ここで吐き出させて欲しい。
Gamewithが憎い。
明らかにゲームをプレイしていないようなライターが書いた情報が憎い。
絶っっっっ対に○○○○では攻略不可能なキャラクターを「○○○○を使えば可能性が見えてくる」などと偉そうな文体で公開している。
私は実際に検証を行い、実際に攻略可能なキャラクターをピックアップし掲載しているが、これに負けているかと思うと頭を抱えたくなる。
どうやらゲーム攻略サイト業界は、いい加減でも攻略記事を書いたもの勝ちで、攻略情報が事実がそうでないかはさほど重要ではないらしい。
Gamewithが憎い。
私がある攻略情報を発見し、これは喜んでもらえるだろうと思い書いた記事が、その後に速攻でGamewithにパクられた。
Gamewithも発見したのなら何も文句はないが、それを引き起こすための条件やら何やらがすべて私の記事と一緒だった。
（別の条件だと再現できるか分からないからすべて真似たものだと思われる。普通は被らない。）
しかもGamewithの管理画面らしきものから、私の攻略ブログのその記事に対するアクセスが確認されたことから、私の記事を意識してパクったことは99%確実だと思われる。
しかし誰もパクリ情報など疑うことなく、むしろGamewithを称賛する声が多かった。
Gamewithの圧倒的知名度の前では、最先端の情報を公開してもそれをGamewithが取り扱えば、むしろこちらがパクった側になるらしい。
Gamewithが憎い。
Googleの評価を盾に、UIの糞さを誤魔化している行為が憎い。
あるツールで、絶対整数しか入力し得ないフォームで、普通に[input type="text"]などを使用している。
それiOSとかで入力すると数値入力モードにならないけど、ツールの開発者は実際に自分でツールを活用しようと思ったことがあるのか。
それとも[input type="number"]も知らないのか。
私の開発したツールは、少なくともGamewithと比較したら絶対に使い勝手が良いと自負しているか、もちろん検索順位は負けている。
Gamewithの圧倒的知名度の前では、UIの快適さなど、さほど重要ではないらしい。
Gamewithが憎い。
そんなGamewithを過大評価しているGoogleも憎い。
「アプリ名 攻略」などで1位はまだしも、アプリ単体名で公式よりもGamewithが上に来るのは正しい評価なのか。
関係のない話だが、私は戦国時代が好きで、織田信長について調べようと「信長」と入力したら、Gamewithのモンスト（信長）が2位に来た時はブチ切れそうになった。
以上、負け犬の遠吠えでした。
写研：
???：
クジラは海面に跳ねあがり、空中に身を躍らせた。彼らのコミュニケーションだ。
モリサワ：
武士道はそのシンボルである桜花と等しく、日本の地に固有の花である。
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz?!1234567890
永
あたらしい朝が来た希望の朝だ
喜びに胸を開け青空仰げラジオの声に健やかな胸をこの香る風に開けよ
ABCDEFGHIJKLMNOPQRSTUVWXYZ@&(^^)!?abcdefghijklmnopqrstuvwxyz.
windowsでコンピューターの世界が広がります。1234567890
Mac：
あのイーハトーヴォのすきとおった風、夏でも底に冷たさをもつ青いそら、うつくしい森で飾られたモリーオ市、郊外のぎらぎらひかる草の波。
いろは歌：
いろはにほへとちりぬるをわかよたれそつねならむうゐのおくやまけふこえてあさきゆめみしゑひもせす
色はにほへど散りぬるを我が世たれぞ常ならむ有為の奥山今日越えて浅き夢見じ酔ひもせず
The quick brown fox jumps over the lazy dog.
旧Google Font：
Grumpy wizards make toxic brew for the evil Queen and Jack.
Google Font：
All their equipment and instruments are alive.
―――フィリップ・ディック『Mr. Spaceship』より―――
アルファベットの羅列：
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz.
よく使われる漢字：
永 東 国 鷹、鬱 愛
個人的にはアルファベットなら「g」とか、ひらがななら「な」とか「や」とか「を」とか個性が出るものは含めて欲しい気がする。
当方、フリーの IT 技術者。ある Web ベースのシステムを開発しているのだが、プロジェクトのマネージャー、リーダーをはじめとするメンバーの無知と無理解のおかげで作業が進まずに困っています。
ブラウザーのキャッシュの仕組みを少しでも知っている人なら、非 IT 系の方でも読めるように書きました。ぜひ助言をお願いします。
私は発注元(A 社)に客先常駐している。私が契約しているのは A 社のグループ会社である B 社だ。
A 社内のチームメンバーは以下のとおり。
さて、今開発しているシステム(以下システム P)はもともとスタンドアローンで運用する形態だったが、最近クラウドバージョンの提供も始まり、現在はスタンドアローンバージョンとクラウドバージョンの並行開発となっている。X さん、Y さん、Z さんは主にクラウドサーバーの管理や、私や W さんが作った部分のテストを担当している。
クラウドバージョンの初めてのアップデートを控えた 6 月に問題が発覚した。コードをアップデートすると、ブラウザーのキャッシュが効いていて表示がおかしくなるというのだ。
プログラマー以外の 4 人は実は Web システムの案件は初めてで、ブラウザーのキャッシュの仕組みすら理解していない。X さんから相談を受け、「Web アプリケーションからブラウザーのキャッシュをクリアーすることはできない。代わりに、HTML から読み込まれる外部リソースの後ろに『?v=3.14』のようなダミーのクエリー文字列をつければよい。アップデートのたびに数字を変える。これは一般的に採用されている手法で、これ以外の解決策はない」ということを伝えた。具体的にコードエディター上で修正イメージを見せて、すべてに対応するのに 1 日あればできる、とも。
これで「そうですか、ではお願いします」となれば、テストを含めて 2、3 日で終わった話なのだが、ここから長い混乱が始まる。
X さんから、「変更箇所をなるべく少なくしたいので、前回リリース分と今回リリース分で変更のあったファイルのリストを出してほしい」と言われる。変更のないリソースにはクエリー文字列をつけたくないらしい。
内心呆れつつ、Git (ソースコード管理システム)でファイルの変更履歴を調べ、一覧表を提出した。X さんに「それぞれのページでソースコードを確認し、この一覧表に載っているファイルにはクエリー文字列がついていることをひとつひとつ確認するのですよね。却って手間が掛かりますよ。それよりも、すべてのファイルを対象にしたほうが作るほうもテストするほうも楽です」と伝えた。
6 月も残り 1 週間を切ったある日、Z さんから、「実際に問題になっているのはどのファイルのどの部分か、スタイルシートのどのクラス・ID 指定が効いていないのか、V さんが知りたがっている。原因解明に必要なので調べるように」と指示が出る。
私は「ブラウザーのキャッシュが効いているためで、キャッシュを消すか無効にすれば直る。今までも修正のたびにテストではキャッシュを消してもらっていたでしょう」と説明するが、調べろ調べろと繰り返すばかり。「そんなことを調べて何になるんですか。キャッシュの問題ですよ?」と言うと、Z さんは手をわなわな震わせて、「お客さまが知りたいと言っているのに、『そんなことを調べて何になるんですか』とはどういうことですか!」と声を荒らげる。しまいには「お客さまのご要望にお応えして私たちはお金をもらっている。お客さまからの依頼なら応えるのが当たり前」と言い出す。技術的に意味がないことをいくら説明するも理解されない。
非プログラマー 4 氏の知識の底上げをしないといつまで経っても平行線だと思い、Redmine (課題管理システム)にブラウザーのキャッシュの仕組みを解説する文書を投稿した。ほぼ同じものを以下に掲載する。非技術者にも分かりやすく書いたつもりだ。あまり細かいことを説明しても混乱させるだけだと思い、リクエストヘッダーの Cache-Control や Expires などは説明を省いた。
キャッシュとは
キャッシュ(cache) とは、一度読み込んだデータを内部に保存しておく機構のことです。2 回目以降の読み込み時はキャッシュを読み込むことで、処理時間の短縮を図ります。
ウェブブラウザーにおけるキャッシュは一般に、HTML ファイルおよび HTML から読み込まれる外部リソース(スタイルシートファイル、JavaScript ファイル、画像ファイルなど)に対して適用されます。
キャッシュが作られるタイミング
ブラウザーがあるファイルを読み込もうとする時、キャッシュがなければ実ファイルを読み込んだ上でそのファイルの内容をキャッシュします。
キャッシュが破棄されるタイミング
キャッシュがいつ破棄されるのかは完全にブラウザー依存です。異なるファイルのキャッシュが同じ期間だけ存在するかどうかも分かりません。
キャッシュはユーザーがブラウザーの操作で明示的に削除(クリアー)することはできますが、 サーバー側からクライアント(ブラウザー)のキャッシュをクリアーすることはできません。
ウェブアプリケーションのキャッシュ対策
ウェブアプリケーションをアップデートした際、クライアントのキャッシュを無効にするために、以下の手法がよく使われます。
＜ link rel="stylesheet" type="text/css" href="style.css" ＞ ＜ script type='text/javascript' src='script.js' ＞＜ /script ＞ ＜ img src="picture.jpg" alt="" width="640" height="480" ＞このような外部リソース読み込みについて、ファイル名の後ろにクエリー文字列を追加します。
＜ link rel="stylesheet" type="text/css" href="style.css?v=2.4.0" ＞ ＜ script type="text/javascript" src="script.js?v=2.4.0" ＞＜ /script ＞ ＜ img src="picture.jpg?v=2.4.0" alt="" width="640" height="480" ＞スクリプトでない静的ファイルにクエリー文字列を付加しても、読み込まれるファイルは同じです。つまり、
style.cssとstyle.css?v=2.4.0は同じ style.css というファイルを指します。ブラウザーが style.css をキャッシュしている状態で、この行を読み込んだとします。
＜ link rel="stylesheet" type="text/css" href="style.css?v=2.4.0" ＞ブラウザーは「
style.css?v=2.4.0というファイルはキャッシュにない」と判断し、style.css?v=2.4.0 というファイルを読み込みます。結果として、ディスク上の style.css が読み込まれてスタイルシートが更新されます。この HTML をまた読み込んだ時は、「
style.css?v=2.4.0というファイルはキャッシュ済み」と判断し、ディスク上のファイルではなくキャッシュを利用します。ウェブアプリケーションをバージョン 2.5.0 にアップデートする時には、「
?v=2.4.0」の部分を「?v=2.5.0」に書き換えてリリースします。＜ link rel="stylesheet" type="text/css" href="style.css?v=2.5.0" ＞ ＜ script type="text/javascript" src="script.js?v=2.5.0" ＞＜ /script ＞ ＜ img src="picture.jpg?v=2.5.0" alt="" width="640" height="480" ＞同様の仕組みで、2.4.0 時代のキャッシュがあっても 2.5.0 用に書き換えられたファイルが読み込まれ、キャッシュの問題は起こりません。
この手法は、キャッシュ問題を解決する手段としては一般的に用いられているものです。俗に「キャッシュバスター (cachebuster)」とも呼ばれます。
数日経った日の午後。Y さんが A4 判数ページにもなる「調査報告書」を作成した。問題になっているスタイルシートについて前回リリース分と今回リリース予定分の差分を取り、それぞれの行について「新規」「変更」「削除」の印をつけ、「とりあえず、このクラス指定が効いていないだけなので、HTML 中にインラインスタイル(＜ div style="..." ＞)で指定すればよい」と結論づけていた。
報告書には「状況から見て、変更・削除されたスタイル指定は影響が出るらしい。新規に追加した部分については影響がないようだ」とも。私が書いた説明を読んでいないのか、理解できなかったのか。
この報告書を元に、X さんから「この行とこの行にインラインスタイルを指定してください。これで暫定対応とします」と指示が出た。
私は「この修正は何ら根本的な対策になっていないことは理解していますか。『現状で問題になっている箇所』は、この環境でたまたまそうなっているだけの話で、ほかのお客さまの環境では別の画面が崩れるかもしれないのです。それを承知の上で、これを暫定対応としてよいのですね」と X さんに確認。X さんは「はい」とだけ答えたので、黙って作業を完了した。Git のコミットメッセージに「この方法は何の効果もないこと、それでも作業をしてよいのかを X さんに確認の上、作業」と書いてコミットした。
しばらくすると X さんから「うまく表示されています。OK です」と報告があった。
夕方、私が帰ろうとすると、X さんが Y さんに「画面がおかしい」と言っている。横から覗くと、先ほど「暫定対応」とやらを入れた画面で、表示は正常だがボタンを押しても何の反応もない。私は静かに「JavaScript のキャッシュですね」。
聞けば、Y さんは「キャッシュはスタイルシートにだけ効く」と思い込んでいたらしい。やはり先の説明を読んでいないようだ。そして、Y さんの環境ではボタンは有効だったとも。
私は「Y さんの環境では(JavaScript の)古いキャッシュは効いていなかった。X さんのところではキャッシュが効いていた。これが、私が言っている『環境依存』の意味です。昼の暫定対応ではダメなんです。半月前から私が言っているように、すべての外部リソース読み込みにキャッシュバスターをつけないと解決にならないんです」と伝える。
Y さんは観念した様子で、「キャッシュバスターって、一部分にだけ適用することもできますか」と聞く。この人、理解してないなと思いつつ、「はい、できますよ」と返すと、「では、問題の発生している範囲を調査して、問題が起こっているファイルにだけキャッシュバスターを……」。やはり何も分かっていない。
私は繰り返し、ブラウザーのキャッシュは環境依存なのですべての外部リソース読み込みにキャッシュバスターを付加しないと無意味だと説明した上で、こう付け加えた。
「指示されたことだけを黙ってやっていれば、そりゃあそっちのほうがラクですよ。でも、喧嘩をしてでも、場の雰囲気を悪くしてでも自分の意見を主張するのは、技術者としてのちっぽけな良心からです。お願いですから、専門家の言うことを聞いてください。私の意見が信用ならないのでしたら、ほかの技術者に意見を聞いてください」
この数日後、本件の対応を先送りにすることが決まったと X さんから報告があった。
聞けば、リリースを急いでいるのは特定の顧客の要望によるものらしい。その顧客はスタンドアローンバージョンを利用しているので、アップデートの現地作業の際にブラウザーのキャッシュを消してくればいいとのこと。
リリースに間に合わない間に合わないとあれだけ騒いでいたのに。プロジェクト管理がまるでできていない。
そして今日の夕方、この件についてレビューを開きたいとプロジェクトマネージャーの V さんから言われる。レビューって、何をやればいいんだろう。何をすれば気が済むんだろう。Redmine に書いた説明を読んで理解してもらえれば、やるべきことはひとつしかないと分かろうものなのに。
X さんから質問を受ける。「例の件、ほかの方法はないんでしょうか。『こういう方法もあるけれど、工数が掛かるので採用しません』というのがもしあれば話が進めやすいかと」。残念ながらありません、せいぜいファイル名そのものを変更するくらいですが、本質的には同じことですし管理の手間が増大します、と伝えた。
ついでに、X さんに「あの説明を読んで、よく分からない部分があったら教えてください」と尋ねると、実は忙しくて斜め読みしかしていないと白状された。その状態で対応策を一生懸命協議していたのですな。
レビューの席でまた一悶着ありそうだ。どうやったら彼らを納得させられるのだろうか。信用できない技術者に説明してもらったって、信じないんだったら意味がないのにねえ。
文字数制限に引っかかってしまい、末尾が切れてしまっていました。続きはこちらに書きました。
Sublime Textの記事を書こうとしたところ、こんな記事があったのでmacユーザーとして書いてみます。
読んだ記事
http://diary.netank.net/entry/2017/06/07/202630
＝＝
>なぜコスパ最悪な"Mac"を使っているの？Windowsサイコーじゃん
>MacBook Proの価格を調べてみると、Appleストアで一番安いTouch BarとTouch IDなしの13インチモデルで税込15万4224円です。
>Intel Core i5（デュアルコア 2.3GHz）
>です。性能的には、Windowsのベーシックモデル（普及帯モデル）と同程度。
>皆さんが欲しいであろうTouch Bar（Fキーの部分がディスプレイ）と
>Touch ID（指紋認証）機能付きモデルはもっと高くて、税込214,704円～となりま>す。
>Intel Core i5（デュアルコア 3.1GHz）
>この性能でこの価格。あなたはどう思いますか？しかも、Macって家電量販店での値引きもほぼ不可能です。
⇨同感です。10年選手ですが、macのおかげで散財させられています。
>
>最新のMacBookProやMacBook無印には普通のUSB端子がありません。スマホなどでも使われ始めている小型のUSBタイプCにすべて置き換わってい
>USBタイプCから普通のUSBに変換するケーブルも売られていますが、わざわざ使うのが面倒です。USBタイプCを採用する機器も登場していますが、>需要が少ないためか滅茶苦茶高いです。
>Windows機であれば、超薄型なモデルでも従来のUSB端子が付いている場合がほとんど。
>普通のUSB端子を廃止するとか頭おかしいです。どう考えたって不便でしょ。
⇨同感です。それまで仲良くしてた仕様をいきなり切ったり困りものですよ。
>Macを使う人の多くが、本体デザインの美しさが理由じゃないでしょうか？確かにカッコよくて、美しいデザインであることは僕も否定しません。
>（最近では群馬でもMacBookをスタバで使う人が登場してます。恥ずかしくないのって思ってます。）
>重たくないですか？
>美しいアルミボディーを採用したためか、MacBookPro13インチで1.37kgもあります。Windowsノートなら、ほぼ同程度のスペックで1kgを切って
>いるモデルも沢山あります。13インチなのにモバイル向きではないのが残念すぎます。
>性能の低いMacBook無印なら0.92kgですが、性能のわりに価格が高いので個人的にありえない選択です。
>Windowsノートはデザインがカッコ悪いと批判するMacユーザーも多いですが、Windows機の良いところは種類が豊富なところです。
>デザイン優先のカッコいいモデルから、低価格で実用性重視のモデル、頑丈で軽量なモデルまで様々です。
>デザインが美しいWindows機なんていくらでもありますよ。ちゃんと探しましたか？
⇨同感です。macは美しいですが、確かにwinでもキレイなものはいくらでもありますよね。
>MacOSのすばらしさを主張する人もいますが、それはないですね。MACにできてWindowsにできないことなんてほぼないと思います。
>足りない機能はフリーソフトでいくらでも拡張できます。
>ソフトの豊富さではWindowsが圧勝です。MAC向けにしかなかった一部のプロ向けソフトも、現在ではウィンドウズ版もちゃんとあります。
⇨同感です。過去はそうだったかもしれませんが、winも同様に素晴らしいものを持っています。
>一部の業界を除いて、ほぼすべての会社のPCはWindowsです。あなたの会社のPCもWindowsだと思います。
>僕が製造業で仕事をしていたころは、自社や取引先を含めて、MACを使っている人なんて一人もいませんでした。全員Windowsです。
>どんなことでも同じですが、全く操作性の違うものを2つ併用して使うのは辛いです。会社はWindows、自宅はMACというのはイライラするはずです。
>実は僕も2年位前にMacBookProを使っていたことがあるのですが、やはり共通性という面で苦労しました。
>結局、会社に合わせる形でMacBookProは売却してWindows機を買いなおしました。
⇨同感です。二兎追うものは一兎をも得ずです。
>会社がWindowsなので、大学生は絶対にWindowsを選ぶべきです。会社に入ってから、「Windows触ったことありません」なんて
>就職後のことも考えれば、圧倒的にシェアが高いWindowsを選ぶべきだと僕は思います。
>まぁ、フリーランスとかデザイン業を目指しているのであれば、MACでも良いかもしれませんが。
⇨同感です。入社という未来があるのに今がよければという考えはもってのほかです。
>MACはウイルスに感染しにくいことを自慢する人も多いですが、それも間違いです。MAC向けのウイルスなんて大量に存在しています。
>Windowsよりユーザー数が少ないから、あまり話題にならないだけです。
>ちゃんと、MAC向けのウイルス対策ソフトだって売られてますよ。安全だという思い込みによって、セキュリティー意識が低下する方が怖いです。
>ちなみに、Windows10ならOS自体にウイルス対策機能が搭載されています。家庭利用なら別途ウイルス対策ソフトを入れなくてもウイルスに
⇨同感です。意識が低下して感染する可能性は大いにありますね。
>MACはソフトもハードもAppleが作っています。そのため、安定性が高いとか、ソフトの最適化が進んでいるとか、主張する人も多いです。
>でも、僕がMacBookProを使っていた時は、特別なソフトをインストールしていないにも関わらず、結構フリーズしてましたよ。
>頻繁に動作不良問題も発生しているので、大して安定しているとも言い難いと思います。
>そもそも、MAC OSって、BSD系UNIXベースなので、Appleが一からOSを作っているわけではないです。
>最近のWindowsはほぼブルースクリーンやフリーズが発生しないですし・・・MAC OSがWindowsより安定しているという主張は納得いきません。
⇨同感です。急な不調を訴えて働くなったりでは困りますよね。
>MACユーザーはよくWindowsのフォントが酷いとか、UIがダサいとか、批判します。でも、それって本当でしょうか？
>僕はWindowsのUIやフォントは好きですよ。むしろMACのようにデザイン重視ではなく、実用性も考慮しているので、使いやすいと思います。
>正直言って、Macのフォントは無駄にアンチエイリアスを利かせすぎていて、綺麗だけど見やすくはないと思うんですよね。
⇨同感です。外見だけでなく実用性も備えているべきですよね。
>たしかにMacのトラックパッドは使いやすいと思いますが、最近のWindows機もかなり改善されています。
>激安モデルはあまり良いさわり心地とは言えませんが、MACと同価格帯の高級機であれば、凄く使いやすいと思います。
>そもそも、僕はMacBookのような大きなトラックパッドが嫌いです。キーボード入力時に誤動作する可能性が高いので、僕はレッツノートの様な小型タイプが好みです。
⇨同感です。昔はそうだったかもしれませんが他を探せばいくらでもいいものはありますよね。
＝＝
winにはとても素晴らしいPCがたくさんあります、価格も申し分ない。
それに比べてmacはコスパ良くないですし急にフリーズだってします。さっきもしました。
本気で苛立つことだって1度や2度ではありません。
そう認めてもなお、どうしてmacを使い続けるのか。
それは。
そう言えば、Sublime Textは「恋に落ちるエディター」と呼ばれています。
よかった、最後に元々書きたいことが書けました。
日本人にとって、直訳という言葉は「機械的に文法に沿って訳語を並べて、意味不明の訳文を作ること」といった印象が強い。意味が通じる翻訳をするには、意訳、つまり元の文を理解した上でその内容を自分の言葉で書き直す必要があると考えられている。
しかし英語で直訳を表わす"literal translation"は、そういった言葉ではない。もちろん、機械的に置き換えて意味の通じない文を作ってしまうことも言うのだが、"literal translation"は「原文に忠実である」というポジティブな側面を持っていて、formalで立派な翻訳という感覚を伴う。
それはつまり、「意訳」に良い印象がないということでもある。それは「意訳」に当たる適切な英語表現がないことでも分かる。
https://www.onehourtranslation.com/translation/blog/literal-translation-vs-conveying-sense-text
ここでは"literal translation vs. conveying the sense of the text"(直訳 vs. テキストの意味を伝えること)というタイトルになっている。日本人から見ると「"直訳 vs."と来たら『意訳』が来るに決まっているだろう」と言いたくなる。しかし、英語で意訳という言葉は、直訳とvs.出来るほどの市民権を得ていない。
英語の翻訳はフランス語やラテン語といったヨーロッパ圏の言語から知識を取り入れるために行われることが多く、ヨーロッパ圏の近縁語同士では直訳は有効な方法論だ。結果として、"literal translation"は立派でフォーマルな翻訳という意味合いが生じた。
対して、訳者が勝手に自分なりの表現を加えてしまうと、fidelity(原文に対する忠実さ)が欠けているという批判の対象になる。
たとえば、私は素人ながらアニメの英語翻訳に関わったことがあるのだが、海外のアニメオタクは意訳を嫌う。佐藤さんはSatou-san,斎藤先輩はSaitou-senpaiだし、学校の先生の敬称は英語だとMr.なのだが、犬塚先生はInuzuka-senseiだ。
たとえば、アニメのセリフに「ありえなくね？」と出てきたら、文字通り"That's impossible, right?"と訳すのが好まれ、意味を汲み取って"Are you kidding?"と訳したりすると、"over-translation"とか"liberal translation"などと言われて叩かれてしまう。日本人の私から見ると、とても理不尽に感じるが、彼らの感性はそうなっている。
この問題についてググっていたら「literal translationが良いというのは神話だ」という海外の人の意見を見つけた。これを言っているのが日本語の英訳をしている人だというのも示唆的だ。
日本では英語文献を翻訳するのが主なので、literal translation、直訳はほとんど役に立たず、ひどい翻訳の代名詞のようになっている。英語話者にとっての日本語の英訳でも同じだろう。
基本的に、英語圏でTranslationと呼ばれているものと、日本で翻訳と呼ばれているものは、行為としては似ているが、内実は全く異なっている。
英語圏で行われているのは直訳であり、我々がやっているのは意訳だ。英語圏でやっているのは文法ルールと訳語を覚えて他言語に当てはめ、原文を出来るだけ変えずに英語に直すことであるが、我々がやっているのは「他言語を(何らかの方法で)理解し、その内容を自分なりに日本語で作文する」という行為である
直訳が役に立たないということは、つまり文法ルールを覚え、日本語の訳語を覚えて適用しても、英語を理解することは出来ないということだ。
これは残酷な現実であるが、「いくつの文法ルールを覚え、何万の訳語を覚えても、英語を理解することは出来ない」
これは文法や訳語が不必要だと言っているのではない。文法や訳語はヒントにはなる。だが、答えにはならない。
はっきりいえば、ヒントを一生懸命集めて暗記しても、意味がない。文法ルールをいくつ暗記しようと、英単語の訳語をいくつ暗記しようと、それは英語力ではない。
身も蓋もない言い方になってしまうが、法則化出来ないなんらかのプロセスによって、英語を直接理解する能力。それが英語力だ。
そして直訳が出来ない、つまり英語を日本語に変換して理解するための法則が導けないという事実から分かるのは、日本語を理解している我々の脳をどういじくっても、それを英語に適用することは出来ないということだ。
それはつまり、「英語を理解するための脳の回路を、日本語とは別にゼロから構築する必要がある」ということに他ならない。赤ん坊が新しい言語を習得するときのように、何年もかけて、少しずつ脳を開発していき、英語を理解できる脳を構築していくしかないのである。
どこかの英語学習体験記で読んだことがあるのだが、「留学に行った所、フィンランドの学習者と同部屋になった。フィンランドの学習者はひたすら単語帳を眺め、英単語だけをひたすら覚えていたが、それによってあっという間に英語が出来るようになっていた。だから、私も一生懸命単語帳を眺めることにした」といったものだ。
これがつまり、直訳が可能な言語を使用している脳と、直訳できない言語を使用している脳の違いだ。欧州の人々は基本的に、母国語を理解するために使っている脳を英語向けにアレンジするだけで、英語ができるようになる。我々はそうではない。
たしかその体験記の終わりは、「一生懸命英単語を覚えた結果、留学を終える頃にはかなり英語ができるようになっていた」となっていたように思う。しかし私が声を大にして言いたいのは「それは英単語を覚えたおかげではない」
日本の英語学習界には、留学神話がある。「留学さえすれば英語は出来るようになる。留学しないといつまでたっても英語ができるようにはならない」というものだ。
もちろん留学さえすれば英語ができるようになるというのは嘘だ。それはもちろん神話でしかない。「留学して、英語を使わざるを得ない環境に自分を追い込み、一生懸命英語に取り組めば英語は出来るようになる」というのは正しいが、「留学はしたものの、日本人同士で固まって遊んでいただけで、勉強はしていない」といった生活で英語ができるようになるはずもない。実はそういう日本人留学生は数多い。
しかし「留学しなければ英語ができるようにはならない」というのは真実を突いている。
日本の英語教育に従って、文法ルールを覚え、訳語を覚え、どんなに努力を続けても、英語ができるようにはならない。留学して、日本の英語教育から離れ、ただがむしゃらに英語と格闘すれば、それだけで英語は出来るようになる。
そして「がむしゃらに英語と格闘する」ためには、留学は別に必須ではない。がむしゃらに英語の本を読む事もできるし、映画を見てもいい。海外英語フォーラムに書き込んでもいいし、Lang-8で英語で日記をつけてネイティブに添削してもらうのも、アジア圏のネイティブとスカイプ英会話をやるのも良いだろう。
がむしゃらに英語と格闘することが必要なだけだ。そしてそれ以外に英語ができるようになる方法はない。
http://www.nikkei.com/article/DGXLASDG25H1M_V20C15A5CR0000/
全国の公立中学・高校の英語教員のうち、英検準１級以上かそれに相当する資格を取得しているのは中学で28.8％、高校で55.4％だったことが25日、文部科学省の2014年度英語教育調査で分かった。政府の教育振興基本計画は17年度までに中学で50％、高校で75％との目標を掲げている。英語教員のいっそうのレベルアップが必要な状況が浮かんだ。
高校の英語教師で英検準一級が55%、半分近くが英検準一級を持っていないということだ。準一級を持ってないということは、日本の文法・単語の暗記中心の教育をする能力すら疑問符がつく。
準一級の問題は、日本の英語教育で教えられたとおりに暗記した単語を当てはめ、文法ルールにそって直訳すれば理解出来る、日本人向けの英語もどきでしかない。それが分からないということは、英語もどきを教える資格もないということだ。
もちろん教師は聖職として尊敬されるべき存在であり、それを指揮するのは霞が関文部科学省のエリート官僚であるから、自分たちが教えているのが「実際には役に立たない英語もどきです」とは言えない。「私たちは英語がよく分かりませんし、『生徒をちゃんと英語が出来るようにしろ』と言われても出来るわけありませんよ。むしろ、そんなやり方を知っているなら教えて下さいよ」などと口が裂けても言えるはずがない。
それに対して一方では「聞き流すだけで英語がペラペラに！」とか「たった100語で英語は出来る！」とか「頻出フレーズを暗記すれば日常会話はバッチリ！」とか、英語教育界はオカルトだらけである。
もちろん商売でやってるのであるから、「がむしゃらに英語と格闘しろ、それ以外ない」などと言えるはずもないのだが、そんなことを言っていても誰も英語が出来るようにならない。なんとかならないものだろうか。
私が実践してきた、オススメの、実際はがむしゃらにやるだけの英語学習法を紹介しておく。
http://anond.hatelabo.jp/20170526220542
http://anond.hatelabo.jp/20170524213622
http://anond.hatelabo.jp/20170522214348
コメントを頂いた。本を読んでもTOEIC3000語が覚えられない、ということだった。
TOEICのリーディングは結構速読が必要なので、その実力が身につくまで、100万語ぐらい、500ページのペーパーバックを12冊分程度読まないと、普通は最後までたどり着かないんじゃないかと思う。12冊分を辞書を引きながら、単語や表現の感覚を感じ取りながら舐めるように読めば、どうやっても8000語程度の単語を感覚的に理解できる、生きた語彙力が身についてるはずだ。必要なのは暗記力ではなく、文を深く読み、英語表現の意味を感じとる力だ。記憶は忘れるけれど、感覚は忘れない。忘れたと思っていても残っていて、何度か同じ表現を見かければ、その都度感覚は強化され磨かれていく。
単語を覚えるというのは読書の途中で自動的についてくるもので、ピクニックの途中で摘める野イチゴのようなものだ。しかし英語学習者は読書というピクニックには出かけず、ピクニックの準備だけを念入りに行っているように感じている。「自分にはピクニックも難しい。ピクニックに出かけたらヤマで遭難するかもしれない。その時のために食料を買い込んでおこう」と言いながら、辛い奴隷労働をして腐りかけのイチゴを買い込んでいるように見える。ヤマに出ればいくらでもおいしい野イチゴが摘めるのに、ヤマに行っても腐ってて使い物にならない表面だけの単語知識を必死で暗記しているように感じている。これは本当によくないことだと思う。
もう一つコメントを頂いた。学習者は英英辞典はオックスフォードでなく、ロングマンをやるべき、というご意見だ。
辞書から得られるものは単語の理解ではなく、ヒントでしかない。ヒントを英語で貰っても基本的に英語学習者にはわかりにくい。英英辞典自体を読み物として楽しめないなら、英英辞典を見ても英和より効率が悪いと考えている。もちろんロングマンが読み物として楽しい、読んで頭に入りやすいという方がいるならその方が良いと思う。私はオックスフォードが読み物として楽しいので使っているが、面倒な時はウェブリオに走っている。
この記事は長文すぎて最後が切れていたので、二つに分割したものの後半部分だ。前半部分はこの記事と繋がりがあるようでないのだが、いろいろと書いた。 http://anond.hatelabo.jp/20170529095534
ネタがなくなったので、多分この増田で吠える英語考察は今回でしばらく休止するかと思います。今まで長文をご覧いただいた方、コメントを頂いた方、ありがとうございました。
http://anond.hatelabo.jp/20170524171732
ＦＡＱはあくまでＦＡＱだからね。手続きの正当性をなぜＦＡＱでみているのか、どの部分を持って手続きの問題がある、とツイート主がおっしゃってるのかわかりませんが、マニュアルにちゃんと書いてあって、ふつうに執り行われてる手続きであるとは思いますよ。そもそも国連の特別報告者はあくまで準司法quasi-judicialで、問題提起が大事だって書いてあるし、これが初動なわけだから、内容が不適切だとおっしゃるなら質問にちゃんと答えりゃいいんですよ。とりあえずツイート主が言ってることは根拠がないですよ。むしろ、人権侵害がある国にこそ公開でやることで回答する動機づけをしてるのは明らかだし。
国際機関を含む多国間交渉の場は利害も考え方もまちまちだから、手続きが大事で、そこを外すと何も進まなくなる。日本政府は問題を指摘しつつも誠実に対応する（ことが求められる）が、他の国（人権侵害のひどい国）なら「回答する前に書簡が政府攻撃に使われた」として回答拒否の口実にしてくるはず。
これは実例に照らして真反対。緊急性や重大性が低く、相手がちゃんと回答してくる可能性が高い場合にこそconfidentialにしている。
今回の書簡は基本的には「質問」であり、当該政府からの回答に加え、別途行ったその他の調査内容と合わせて検討し、国連人権理事会に報告書を提出するのが特別ラポルトゥールへの委託内容。その報告書はまだ単なる個人作成の文書であるがこの時点で公開されて議論の対象となる。書簡公開はルール違反。
これも事実誤認でルール違反じゃない。ちゃんと書いたように，マニュアルに認められている。
送られた書簡とそれに対する受け取った回答の文章は、受任者が対応した報告書を作成するときまで機密にするか、受任者が、特定の状況によって、それ以前に行動が必要であると決定する。
37. The text of all communications sent and responses received thereon is confidential until such time as they are published in relevant reports of mandateholders or mandate-holders determine that the specific circumstances require action to be taken before that time.
プレスリリースを即座にすることも認められている。
重大な懸念や、政府が書簡に対して本質的な回答が出来ない状態が続く場合などの適切な状況では、受任者は個人で、あるいは他の受任者（特別報告者、作業部会など）プレスリリースやプレスカンファレンス、その他の公的な意見表明などを行う場合がある。
一般的に言って、受任者は政府との対話の中で、プレスリリースなどのプレス向けの声明を発出する前にそのことを明らかにするべきである。受任者が、書簡の中で、プレスリリース等をすぐにおこなう意向を示したい時は、書簡の中にそのような意向を記載することが出来る。受任者は、懸念された国からの応答に対しても公平に明らかにするべきである。
49. In appropriate situations, including those of grave concern or in which a Government has repeatedly failed to provide a substantive response to communications, a Special Procedure mandate-holder may issue a press statement, other public statement or hold a press conference, either individually or jointly with other mandate-holders.
50. In general, mandate holders should engage in a dialogue with the Government through the communications procedure before resorting to a press release or other public statement. When a mandate holder sends a communication with the intention of issuing a press release shortly thereafter, such intention could be indicated to the Government in the communication. Mandate holders should indicate fairly the responses provided by concerned States.
とされているように、初動が一方的に公開であることは別に認められているし、反論の公平性は、反論文を同じ場所に掲示することで保とうという意思が見える。
また前に書いたように、イギリスのSnooper's charterについては、就任直後にガーディアンのインタビューでいきなり問題提起しており、不必要にテロの危険性をマスコミが翼賛的に報道している状態に苦言を呈しているけど別にイギリスは「反論の機会もなしにメディアでしゃべるなんて！」とも批判もしてない。（なぜインタビューされたかというと、このケナタッチ氏の就任は、アメリカがメルケルとかを盗聴してたことが明らかになったのちだったので、親アメリカ派のエストニア人候補が反対されたという経緯でヨーロッパではその就任が注目されていた。）そしてイギリス政府は、ガーディアンに政府の見解を送り、ガーディアンもそれを掲載した。ただそれだけの話なんだよ。
当然指摘は一方的になされるので、誤認があるなら反論すればいいだけなんだよね。我が国の対応が際立ってみっともないだけ。
greasemonkey書いて戻るボタン押さなくて良くした。
// ==UserScript== // @name anond easy track back // @description anond easy track back // @namespace http://anond.hatelabo.jp/ // @include http://anond.hatelabo.jp/* // @require https://code.jquery.com/jquery-3.2.1.min.js // ==/UserScript== (function() { var url = window.location.href, isEditPage = url.slice(url.lastIndexOf('/')).startsWith('/edit'); if (isEditPage) { appendTrackBackContent(); } else { appendEditLink(); } })(); function appendTrackBackContent(){ var postId, match = $('#text-title').val().match(/anond:(\d{14})/); if (match.length>1){ postId = match[1]; } else { return; } jQuery.ajaxSetup({async:false}); var content = ''; $.get('http://anond.hatelabo.jp/' + postId, function(data){ var section = $(data).find('.section'); var title = $(section).children('h3').text().slice(1); $(section).children('p:not([class])').each(function(idx, val){ content += $(val).text() + "<br/>"; }); content = '<hr><h4>' + title + '</h4><p><small>' + content + '</small></p>'; }); jQuery.ajaxSetup({async:true}); $(content).insertAfter('.post-submit'); } function appendEditLink () { var masudaId = $('#bannersub .username a').text(); $('h3').each(function (idx, val){ var postId = $(val).children(":first-child").attr("href").slice(1); $(val).append(' <a href="http://anond.hatelabo.jp/' + masudaId + '/edit?title=Re: [anond:' + postId + ':title]">\u2190</a>'); }); }
タイトルに「anond:14桁の番号」があったらそっから引っ張ってきて画面下に表示する。
大なり小なりとかがエンコードされてるけど普通に表示する方法よくわからない。ちなみに直さないと使えない。
http://anond.hatelabo.jp/20070612084049
一部これの真似
http://techwave.jp/archives/a-source-code-written-by-mr-mikitani.html
書き直してみた
void reverse(char* text, int length)
{
int i = 0;
int j = length;
char temp;
temp = text[i];
text[j] = temp;
i++;
j--;
}
}
int add_comma(int n, int length, char *out)
{
int i = 1;
int j = 0;
n = n / 10;
while (n > 0) {
if ((i % 3) == 0) {
out[j] = ',';
j++;
}
i++;
j++;
n = n / 10;
}
return -1;
}
reverse(out, j);
return j;
}
最初のきっかけは「何これ？」っていうハテナマークだったのよね。
何がって、３月７日（火）に発売された週刊スパ！の後半カラーページに
幸福の科学の星野源のイタコ本の宣伝が丸々１ページのってたのよね。
それでも、のせたというのはすごく広告料が高かったと思うのよね。
ただまあ、本の広告をのせるくらいは仕方ない、まあいいじゃないと思うよね。
でもね、ヤフーニュースを見てたら、ヘンな記事を見つけたのよ。それが下の記事ね。
「星野源は前世でも恋ダンス？“幸福の科学カフェ”で芸能人の前世を調べてみた」
http://zasshi.news.yahoo.co.jp/article?a=20170304-00668142-jspa-life
この記事は当然女子スパ！にものってるのよね。記事の公開日は両方とも３月４日（土）。
http://megalodon.jp/2017-0309-2116-55/https://joshi-spa.jp:443/668142
http://megalodon.jp/2017-0309-2125-50/https://joshi-spa.jp:443/668142?page=2
スパ！のスタンスってもっとイジワルな視線とかがあってもおかしくないと思うのよ。
でもこの記事は幸福の科学を笑うわけでもなく、銀座のカフェを紹介して、最後には
「というわけで、潜入してみて感じたことは、「うん、なんだかいいカフェかもしれない」ってことですね」
３月４日に女子スパ！に幸福の科学のカフェの宣伝みたいな記事がのって、
これって偶然なのかな？
リスク大きすぎると思うのよね。雑誌やってる人ならわかるでしょ？
雑誌って、よくあるのよね。
スキャンダルがのる、ちょうどおなじ時期に広告がのる予定があると、
スキャンダルをのせる時期を少し遅くしたりするの。
それだからこの女子スパ！の記事もおもしろおかしい内容にするなら公開する時期をずらせばいいんだよね。
でも、そんなことはせずに、淡々と幸福の科学がやってるカフェを紹介してるのよ。
広告が乗る寸前のタイミングに、無断で潜入取材っていうリスクを背負ってまで。
それでこの記事はライターのクレジット表記が＜TEXT／女子SPA!編集部＞なのよね。
見てみればわかるけど、女子スパ！の記事の多くはライターの名前がのってるのに、
ライターを守るため？ 別に幸福の科学をバカにしてる記事でもないのに？
前にもステマが取り沙汰されたことはあったけどあのときは何か売るくらいだったでしょ？
javascript:var%20t=((window.getSelection&&window.getSelection())||(document.getSelection&&document.getSelection())||(document.selection&&document.selection.createRange&&document.selection.createRange().text));var%20e=(document.charset||document.characterSet);if(t!=''){location.href='http://translate.google.com/?text='+t+'&hl=ja&langpair=auto|ja&tbb=1&ie='+e;}else{location.href='http://translate.google.com/translate?u='+encodeURIComponent(location.href)+'&hl=ja&langpair=auto|ja&tbb=1&ie='+e;};
これをブックマークレットとして呼び出すだけで英語がスラスラ読める。
スゴイ。
あんな難しそうだった英文が実は「痩せたいけどご飯が美味しくてつい食べ過ぎちゃって困るの＞＜」とかいう女の子のかわいい愚痴だったよ。
変に感情が入ってきて。
Tampermonkey
https://chrome.google.com/webstore/detail/tampermonkey/dhdgffkkebhmkfjojejmpbldmpobfkfo?hl=ja
https://addons.mozilla.org/de/firefox/addon/greasemonkey/
// ==UserScript==
// @name unvisualizer
// @namespace http://anond.hatelabo.jp/
// @description unvisualize section including specific word at Hatelabo::AnonymousDiary
// @include http://anond.hatelabo.jp/*
// @exclude http://anond.hatelabo.jp/hatena/*
// ==/UserScript==
(function() {
var target = document.evaluate(
"//div[@class='section' and descendant::*[contains(text(),'Troyes') or contains(text(),'fiorentina') or contains(text(),'genoa') or contains(text(),'forums.zoho') or contains(text(),'medhelp.zendesk') or contains(text(),'.co.uk/') or contains(text(),'elbertcountyrepublicans') or contains(text(),'purob.com') or contains(text(),'imvu.com') or contains(text(),'thelittleonescollection') or contains(text(),'nfyi.org') or contains(text(),'usa-fox-tv.kinja.com') or contains(text(),'livestream1.odiblogs.com') or contains(text(),'reddit.com') or contains(text(),'huffduffer.com') or contains(text(),'healthunlocked.com')or contains(text(),'surveymonkey.com')or contains(text(),'yakmari.kinja.com')or contains(text(),'putlockeronline') or contains(text(),'freefullmovies.website') or contains(text(),'change.org')or contains(text(),'nervefullmovie.com') or contains(text(),'navtv.co.za')or contains(text(),'Hrvatska')]]",
document,
null,
XPathResult.UNORDERED_NODE_SNAPSHOT_TYPE,
null);
for(var i=0; i<target.snapshotLength; i++) {</p>
target.snapshotItem(i).style.display = "none";
}
})();
// or contains(text(),'')
ついでにこの記事も消える
NGワードは適宜追加してください
text.ssig33.com - 俺が糸柳和法に関して知ってること
ドワンゴは糸柳を雇用した時点で、異常者であることが分かって採ったんだから、その辺ちゃんとケアすべきでしょ。ここで解雇したら「障害者を障害を理由にクビにする会社」ってイメージ持たれることになるよ。障害者を雇ったのだからそれは責任を果すべきだ。
↓
はてなブックマーク - kawango のブックマーク - 2011年3月14日
今回の件で糸柳を解雇するか/できるかは置いといて、障害者だからといって企業がいくら害をなされても面倒みなければいけないなんて主張を認めるなら、どんな企業も障害者は絶対に雇うべきじゃない。
棒読みちゃんTipsにあるLimeChat用スクリプト「BouyomiLimeChat.js」を改造し、英語のテキストを読み上げないようにします。
参考 : 棒読みちゃん Tips
ここでは英語のテキストとは「半角英数字記号(=アスキー文字)のみで構成されたテキスト」とします。
40行目の「function talkChat(prefix, text) {」の次行に次のコードを挿入。
if (text.match(/^[\x20-\x7E]+$/)) return;
以上です。
同じような行を更に追加することで、読み上げないテキストの種類を増やせます。
text.match(/この部分/)を書き換えることで、好きなテキストを無視できます。"この部分"は正規表現で指定します。
if (text.match(/^[\x20-\x7E]+$/)) return;
if (text.match(/https?:/)) return;
棒読みちゃんTipsの「●スクリプトを利用する方法」はLimeChat2.40だとそのまま使えないようです。2.40向けに書き直したものを以下に記載します。
1.スクリプトファイルをダウンロードする こちらのスクリプトをダウンロードしてください。 ZIP形式ですので、展開してください。 2.ファイルを配置する LimeChatのメニューから「設定→スクリプトの設定」を開く。 「スクリプトフォルダを開く」ボタンを押す。 開いたフォルダに「BouyomiLimeChat.js」を置く。 3.LimeChat側でスクリプトを有効にする LimeChatのメニューから「設定→スクリプトの設定」を開く。 スクリプトの設定画面で、「BouyomiLimeChat.js」の行を右クリックし、○を付ける。 スクリプトの設定画面の閉じるボタンを押す。
私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくまで単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。
要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのである。ググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか。
ここで挙げているコミットログは全て実際のコミットログからの転載である。当然ながら各コミットログの著作権はそれぞれの書き手にある。いずれも各英文でググれば出てくるし、フェアユースの範囲なら許してくれるだろうと考え名前とプロジェクト名は割愛したが、ここにお詫びと感謝を述べておきたい。
抽出条件だが、参考にできそうなコミットログを多く含んでいそうなリポジトリを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以上用例を転載してあるので、それを読むだけでも多少は効果があるんじゃないかと思う。同じようにコミットログ書きたくねぇなぁ英語わっかんねぇなぁと思っている人にとって、何か役に立つところがあれば幸いである。