英語の技術ブログってなんであんなに同じ話題がやたら多いのか、と思うと共に日本語ブログの独自性について考えた

技術ブログに関しては英語と日本語の両方を読むようにしているが、どちらかと言うと日本語の方が各ブログライターごとの独自性が色濃く出ていて、英語の方は「またこの話題か。」と似たような内容を書かれている割合が高い気がする。

以下の内容の英語の技術ブログはタイトル見ただけで内容が想像できるし、もうクリックしたいという気にならない。でもそんな英語ブログ記事は雨後の竹の子のように次から次に出てくる不思議がある。

• なぜテストコードは重要なのかという話
• マイクロサービスがこの世を救う
• アジャイルがプロジェクトマネージメント天国への切符
• ウォーターフォールは地獄への直行便
• ソフトウェアエンジニアのキャリアはこうあるべし
• TDDテスト・ドリブン・デベロップメントについて
• シリコンバレーで活躍する女性エンジニアに対する誤解について（あたしはブロンド美女だけど、モデルじゃなくてJavaエンジニアなの。気安くナンパしないで、みたいなの）

エンジニアがブログを書くことを非難するつもりは毛頭ない。アウトプットは大事なことだし、どんどんするべきだ。
ブログは書いた人がなんの編集や制約を受けることなく、いきなり公の場に発信されるため、最低限のマナーに反しない限りどんなに尖った内容でもOkだし、むしろそうあるべきだと考えていた。

それなのに英語の技術ブログがどれもこれもよく似た話題を扱っているように感じるのは私だけなのだろうか？
もちろん鋭い記事もあるし、技術的に参考になる割合は断然日本語より英語の方が多い。ただ独自性という点は英語ブログにはあまり無いように思える。

理由として英語の人気ブログを抽出するシステムの精度がやけに高いのかもしれない。自然言語処理の分野は当然ながら英語の方が日本語よりも精度が高い。そうなると単に炎上気味にアクセスが上がっているクソ記事と本当に有用なことを書いて上がっている記事の区別精度高いのかな、と。有用な内容はある程度似た内容にはなってしまう。

とにかく英語ブログと比較して日本語の技術ブログは「は？それはないだろ」というような記事も含めてとても独自性に富んでいるように感じる。その分、質としては玉石混交だが、そういう各ライターが尖った発想を発表しまくる日本のブログ文化がまーまー好きだ。

ということで技術的に参考にしたり技術習得する時は英語の記事。なんか変な事を考えてる人の記事が読みたい時は日本語というのが目下のスタイルになっている。

「じゃあ、お前のブログ記事にどれだけ独自性があるんだよ？」などと突っ込まれないように独自性ある記事を書かねば、とは思うのだが。。。

ブログのノウハウを語らせたらこの方の右に出る者無し。なによりノウハウを語るだけでなく自ら正攻法で実践されている点がなによりの証明となっている。

永江一石のネットが面白くてナニが悪い！！: ブログ3年間でバズった59エントリー総まとめ

金がないなら頭を使え　頭がないなら手を動かせ: 永江一石のITマーケティング日記2013-2015 ビジネス編

tango-ruby.hatenablog.com

tango-ruby.hatenablog.com

tango-ruby.hatenablog.com

「100 Tricks to Appear Smart in Meetings」で学ぶ英語圏の職場でのサバイバル術

「100 Tricks to Appear Smart in Meetings」がなんか面白い。ちょっと前にSNSなんかで話題になっていたようだ。英語のキンドル本を買って読んだらやけに面白く、かつ海外の職場でのサバイバルに関して参考になった。

本書の趣旨はシンプル。英語を使う職場でも、その職場や会議で発せられる言葉に実はそんなに価値はない。だからテキトーにこなしておけばいい。くだらない会議の中でもあなただけはクールに見える魔法の言葉を紹介します、というのが趣旨。

ミーティングで使われている時間（本書より）
© Sarah Cooper

６　気まずい沈黙
５　スマフォを見る
４　ちゃんと聞いてなかったから「もう１回言って」と言う
３　会議じゃなくてメールでよかったかもと気がつく
２　次のミーティングを計画する
１　早く終わらせたいからなんでも賛成しておく

みんながさも真面目そうにミーティングに参加しているのを面白おかしく揶揄してしまう本書のエピソードはなんかプッと笑ってしまう。

100 Tricks to Appear Smart In Meetings

本書の一部を紹介する。

会議でクールに見せる方法

エンジニアが話した最後のセリフを繰り返す。（ただしすごくゆっくりと）

エンジニアが難しいこと言い出したら、その話の後で「繰り返すね」と言って、そいつが言った最後のセリフをそのままそっくり繰り返す。ただしとってもゆっくりと。
そいつの賢さは全部あなたが持っていけます。

「その質問って問うべき正しい質問かしら？」と言う

それが正しい質問かどうかを聞くことほど賢そうに見える質問はない。

みんなが気に入りそうなアイデアだったら、「Ship it!（よし出せ、出荷しよう）」と大きめの声で言う

みんながアイディアに興奮して、気に入っているようならこう叫ぶ。「Ship it!（よし出せ、出荷しよう）」ちょっととっぴな印象で、笑う人もいるかもしれない。しかしあなたはこれによって、あたかも会議の結論を導き、ミーティングを成功に終わらせる権限が（実際は無くても）あるように見える。

感想

最後のShip it!の男のドヤ顔と両手を頭の後ろにしたその姿勢にウケた。意識高い系の登場人物の挿絵がまたなんとも面白い。

著者のSarah Cooperは元Googleでデザイナーをしていた経歴の持ち主。
この本を単なる笑いを狙った本とだけ思って読むのはもったいない。多かれ少なかれ英語圏の職場においては「目立ったモノ勝ち」なところはある。海外で働くことになった際に本書のノウハウをそのまま使うのはどうかと思うが、Ship it!の男のように何も考えてなくてもとりあえず目立っておくことは大切なことだと思った次第。

日本語版もあるようだけど、英語版の方が面白さのツボには直接響いてくる。英語が読める人なら英語版の方がおすすめ。

100 Tricks to Appear Smart In Meetings

会議でスマートに見せる100の方法 (早川書房)

tango-ruby.hatenablog.com

tango-ruby.hatenablog.com

tango-ruby.hatenablog.com

tango-ruby.hatenablog.com

RubyのblockやProcを分かったつもりになっていて見事にハマった

反省した。RubyのblockやProcを分かったつもりになっていて、しょうもないところでハマった。自戒を込めてブログに残しておくことにした。

$ ruby -v
ruby 2.3.3p222 (2016-11-21 revision 56859) [x86_64-darwin15]

例１

def method_1
  if block_given?
    puts 'Yes'
    yield
  else
    puts 'No'
  end
end

method_1 { puts 'I am a block' }

つまりmethod_1にI am a blockの出力というブロックを渡して、ブロックが有ればYesと共にそれを出せと。
method_1にはブロック引数が無いが、この例のようにそれが問題になることもなく、yieldすればちゃんと実行される。

実行結果

$ ruby block_sample_1.rb
Yes!
I am a block

例２

def method_1
  if block_given?
    puts 'Yes :method_1'
  else
    puts 'No  :method_1'
  end
  method_2
end

def method_2
  if block_given?
    puts 'Yes :method_2'
    yield
  else
    puts 'No  :method_2'
  end
end

method_1 { puts 'I am a block' }

blockが渡されたmethod_1からmethod_2を呼び出す例。

実行結果

$ ruby block_sample_2.rb
Yes :method_1
No  :method_2

渡されたblockはmethod_1まで。method_2には到達していない。

例３

つまり&引数名にしてブロックをProcオブジェクト化して渡す必要がある。その対策後のコード例がこれ。

def method_1 &block
  if block_given?
    puts 'Yes :method_1'
  else
    puts 'No  :method_1'
  end
  method_2 &block
end

def method_2
  if block_given?
    puts 'Yes :method_2'
    yield
  else
    puts 'No  :method_2'
  end
end

method_1 { puts 'I am a block' }

実行結果
これでしっかりblockがProc化されてmethod_2にまで到達していることが分かる。

$ ruby block_sample_3.rb
Yes :method_1
Yes :method_2
I am a block

例４

def method_1 &block
  if block_given?
    puts 'Yes :method_1'
  else
    puts 'No  :method_1'
  end
  method_2 plus_one 1, &block
end

def plus_one number
  number + 1
end

def method_2 number, &block
  if block_given?
    puts 'Yes :method_2'
    puts number
    yield
  else
    puts 'No  :method_2'
  end
end

method_1 { puts 'I am a block' }

実行結果

$ ruby block_sample_4.rb
Yes :method_1
No  :method_2

method_2にまでブロックが到達していない。これでハマった。とくに例３と変わったことをしているようにも思えない。ただdef plus_one numberを加えただけで、そこにblockはまったく関係無さそう。なぜmethod_2にまでブロックが到達しないのか、しばらく分からなかった。

見つけた答えがこれ。

例５

def method_1 &block
  if block_given?
    puts 'Yes :method_1'
  else
    puts 'No  :method_1'
  end
  method_2 plus_one(1), &block
end

def plus_one number
  number + 1
end

def method_2 number, &block
  if block_given?
    puts 'Yes :method_2'
    puts number
    yield
  else
    puts 'No  :method_2'
  end
end

method_1 { puts 'I am a block' }

実行結果

$ ruby block_sample_5.rb
Yes :method_1
Yes :method_2
2
I am a block

例４との違いはここの（）だけ。

  method_2 plus_one(1), &block

つかれた。。。

tango-ruby.hatenablog.com

tango-ruby.hatenablog.com

tango-ruby.hatenablog.com

tango-ruby.hatenablog.com