Hatena::ブログ(Diary)

西尾泰和のはてなダイアリー

2016-11-12

Google翻訳を試してみた

精度が上がったと話題のGoogle翻訳で僕が書いた日本語を訳してみて、その英文を見て意味が分かるかどうか、英文に違和感があるかないかを検証する。

What is Moyamoya?

まあわかる。

The purpose of this book is to solve the "Moyamoya on programming".

引用符の閉じ位置とかtheとかに違和感があるけど、まあわかる。

Everyone is learning programming, "What is object-oriented? I do not know like I understood ..." You may have felt moaiyoya such as.

これは書き直しが必要そう。元の日本語が「わかったようなわからないような…」という文字列を含む複雑な構造だから訳せないんだな。

In this book I would like to help solve such mooyamoya and refresh it.

and以降は削った方がいいかもな。

Moyamoya is not understood, I do not understand well, I can not understand well.

Moyamoya is a mental state such as "I do not understand well" or "I can not understand well."かな。

So what is understanding?

うん通じそう。こういうケースって冠詞いらないんですかね?

Makoto Nagao wrote in "What is" Understanding "" Understanding the sentence is to reconstruct the written content in the reader ".

引用符が乱れてるけど、まあ理解できる。

Moyamoya is a state in which the knowledge input to the brain by sentences etc. does not connect with other knowledge that he owned, fluffy floating.

割と訳しにくい原文だと思うんだけど、理解できる訳になっている。日本人etc.使いすぎって英会話の先生によく言われるけどこの文章でも「by sentences etc. 」はいらない気がする。

Even in this state, you may be able to spit the knowledge as it is like a parrot as it is.

「as it is like a parrot as it is」が微妙。先のas it isは「与えられた知識を与えられた形のまま吐き出すことしかできない」なのでas it was givenかなと思うし、like a parrot as it isのas it isが必要なのかどうかよくわからん。あえて訳出するにしても「まるであなたがオウムであるかのように」だからitじゃなくてyouだろう。

あと日本人的な曖昧表現が気になる。英語で書くなら「Even in this state, you can spit ...」と言い切った方がすっきりしそう。

However, we can not connect it with another knowledge.

文脈上、このweはyouの間違い。


もうちょっと技術的な話を試してみよう。

First, it is a concept of "implementing general functions in superclasses and implementing specialized functions in subclasses"? This is a design policy that superclass is generalization of subclass and subclass is specialization of superclass. This design policy matches the idea of ​​"class = classification".

いや、なぜ疑問形……。そこを直せばだいたい意味は取れそう。

The second one is the idea of ​​"extracting the intersection of multiple classes as its superclass?" This is a design policy of "extracting common parts" that is similar to mathematical factorization rather than generalization / specialization. This design policy matches the idea of ​​"sharing common parts of processing" already familiar with how to make functions.

こちらも疑問形。原文を確認したら"「複数のクラスの共通部分をそのスーパークラスとして抽出すればいいのではないか?」という考え方です"とか書いてたからそのせいだな。あとさっきはconceptでこっちはideaだな。


-----

実験をしての所感

It is not satisfactory quality as it is, but probably it can be passed as it is. Since you can see what you want to say in most places without referring to the original text, the labor of the work of correcting the translations made in Google Translate will be much less. Perhaps in this state you could also outsource "to correct sentences to be naturally" to people in English-speaking countries who do not understand Japanese.

そのままで満足できるクオリティではないけど、たぶんそのままでも通じる。原文を参照しなくても大部分の箇所で何を言いたいのかがわかるので、Google翻訳で作った下訳を修正していく作業の手間がだいぶ減る。たぶんこの状態なら日本語の分からない英語圏の人に「文章を自然になるように直して」って外注することもできそう。

2016-01-08

Windowsで会場のLANにつなぎつつインターネットはiPhoneのテザリングを使う

会場のLANにIRCサーバが立っているのでそこに接続したいが、ホテルから外に向かうネットワークがへぼい場合、インターネットへの接続は自分のiPhoneなどをUSB接続してテザリングした方が快適だったりする。両立するにはどうすればいいか、という話。

まあ「ルーティングの設定をする」が正解なのだろうけど、Windowsでどうやるのかなぁと思って検索して調べたもでやり方をメモしておく。

まず今のルーティングテーブルを表示してみる。関係なさそうなところは削除してある。会場のLANが 192.168.200.0/24 で、チャットサーバーは192.168.200.5で立っている。

>route print

IPv4 ルート テーブル
===========================================================================
アクティブ ルート:
ネットワーク宛先        ネットマスク          ゲートウェイ       インターフェイス  メトリック
          0.0.0.0          0.0.0.0    192.168.200.1   192.168.200.99     25
          0.0.0.0          0.0.0.0      172.20.10.1      172.20.10.7     20
    192.168.200.0    255.255.255.0            リンク上    192.168.200.99    281
   192.168.200.99  255.255.255.255            リンク上    192.168.200.99    281
  192.168.200.255  255.255.255.255            リンク上    192.168.200.99    281

一番上の行を消せばいいだけのように思うので以下のように実行。

> route DELETE 0.0.0.0 MASK 0.0.0.0 192.168.200.1
 OK!

もう一度printしてみたらちゃんと削除されてた。僕の期待していたように振舞っているのかtracertで確認。

> tracert 8.8.8.8

google-public-dns-a.google.com [8.8.8.8] へのルートをトレースしています
経由するホップ数は最大 30 です:

  1     1 ms    <1 ms    <1 ms  172.20.10.1
(以下略)

> tracert 192.168.200.5

192.168.200.5 へのルートをトレースしています。経由するホップ数は最大 30 です

  1     2 ms     1 ms     6 ms  192.168.200.5

トレースを完了しました。

ちゃんと確認するためには、削除する前に「8.8.8.8にアクセスしたときに192.168.200.1を通る」を検証しておくべきだったな。


続き。翌日。

元に戻ってる。

IPv4 ルート テーブル
===========================================================================
アクティブ ルート:
ネットワーク宛先        ネットマスク          ゲートウェイ       インターフェイス  メトリック
          0.0.0.0          0.0.0.0    192.168.200.1   192.168.200.99     25
          0.0.0.0          0.0.0.0      172.20.10.1      172.20.10.7     20

ということに変に接続が切れるので気づいた。

~$ git clone https://github.com/miyo/geister_server.java.git
Cloning into 'geister_server.java'...
fatal: unable to access 'https://github.com/miyo/geister_server.java.git/': Failed to connect to github.com port 443: Connection refused

~$ git clone https://github.com/miyo/geister_server.java.git
Cloning into 'geister_server.java'...
error: RPC failed; result=6, HTTP code = 0
fatal: The remote end hung up unexpectedly

あれー、ちゃんとiPhoneの側を通っているなぁ。

> tracert github.com

github.com [192.30.252.130] へのルートをトレースしています
経由するホップ数は最大 30 です:

  1     2 ms    <1 ms    <1 ms  172.20.10.1

ルートをDELETEしたらエラーメッセージが変わった。

~$ git clone https://github.com/miyo/geister_server.java.git
Cloning into 'geister_server.java'...
fatal: unable to access 'https://github.com/miyo/geister_server.java.git/': Could not resolve host: github.com

~$ git clone https://github.com/miyo/geister_server.java.git
Cloning into 'geister_server.java'...
fatal: unable to access 'https://github.com/miyo/geister_server.java.git/': Could not resolve host: github.com

うーん、どうしたらいいいのかな。名前解決できないことが問題の根っこじゃなさそうだ。

~$ git clone https://192.30.252.129/miyo/geister_server.java.git
Cloning into 'geister_server.java'...
fatal: unable to access 'https://192.30.252.129/miyo/geister_server.java.git/': Failed to connect to 192.30.252.129 port 443: Connection timed out

2015-04-26

Facebookに書き続けることは損失なのではと思い始めた

ブログの更新頻度が落ちてるのは、Facebookに書いた方が有益なフィードバックの頻度が高くて、ついついそっちに書いてしまうから。

そうやってFacebookにばかり書いていると「あれ、この前Facebookに認知心理学が生まれてきた流れについて書いたと思うんだが、あれどこだったかな、参考にしたいのだが…」なんてことが起こるようになってきた。以前であれば、だいたいそういうのは自分のブログに書いているので、Googleに行って「西尾泰和 認知心理学」とかで検索すればすぐ見つかった。しかしFacebookに書いたものはそういうわけにはいかない。

で、発掘するのにすごく時間がかかったり、発掘できなくてあきらめてしまったりする。これってものすごい損失なのではないか?クロールして手元に保存して検索できるようにする必要があるのではないか?

そしてそのクロールもまた手軽ではない。エクスポートの機能はあるけどリプライで書き連ねていった文章はエクスポートされないし。うーん、どうやってFacebookのロックインから逃れるか…。と、とりあえずブログに書いてみた。

-----

画像を貼ったりとか、リプライで書き足していったりとかが、このブログよりだいぶ書きやすいんだよねぇ。

追記

この記事に頂いたフィードバックを本人が気づいた順に、どういう経路かも含めてメモ

  • Facebookコメント: IFTTTでevernoteとGoogle Driveに書き出している
  • Facebookコメント: BloggerとFacebookの両方に書いている
  • Facebookメッセージ: アクティビティログから検索ができる
  • はてぶ連携でのTwitterメンション: 自分が検索したいだけならEvernote連携でよいのでは?
  • Twitterエゴサーチ: 言語設定を英語にしておけば検索できる
  • はてなブックマークコメント: 検索窓に Posts about 〜 by my friends、Posts about 〜 by me などと入力すると過去記事も検索できる
  • はてなブックマークコメント: 漠然と公開したものは長期にわたって読めるようにはなってない(だからフローの場に書き散らすのではなく、きちんとストック用に工数を掛けて作るべきという主張だろうか。確かに一理ある)

まとめ

英語UIだと検索できるという話は、少なくとも僕の環境では「This search isn't available yet」と言われてしまうので、まだ使えないようですね。とりあえずEvernote連携をして今後書いたものはストックされるようにし、過去の記事はアクティビティログで検索しようと思います。

追記

Facebookのアーカイブ機能を使ってWallをエクスポートし、そこからの検索で目的の記事が2014年12月30日であることが判明した。しかし、エクスポートされたWallの更新一覧には、その更新に対してリプライした内容は含まれない。リプライした内容を得たいが、アーカイブからその記事へのリンクは存在しないのでたどりつけない。その記事に含まれているキーワードでアクティビティログを検索してもヒットしない。たまたま年の終わりの方の記事だったのでアクティビティログで2014年を開いたらすぐに見つかった。

こんなのがあった: How To Backup & Archive All Your Facebook Data 追記: この拡張は僕の環境ではうまく動かなかった

追記

作った: Facebookの全アクティビティログをファイルに書き出すツールを作った

2015-01-29

Pythonで本文抽出

Pythonでウェブページから本文抽出がしたくて、ググったら弊社の中谷のWebページの本文抽出 (nakatani @ cybozu labs)をPythonに移植したもの(yono/python-extractcontent)が見つかったのでとりあえずそれを使ってみたんだけど、Google Ad Sectionがついていて100%の成功率のはずのこのブログを対象にして本文抽出に失敗して空文字列を返してくるので、あれれおかしいなー、と思ったら。

https://github.com/yono/python-extractcontent/blob/master/extractcontent.py#L80

いや、正規表現の途中で改行するんだったらVERBOSEオプションが必要ですよ。(?isx)するなりre.compileでre.VERBOSEつけるなり、もしくは文字列分割して改行が入らなくするなり。

とか考えながら修正してプルリクエストしようかと思ったらFork 5とか表示されていて、確認してみたらフォーク先で修正されていた。

https://github.com/petitviolet/python-extractcontent/commit/7e91da3824023c1fa305d5f25a8f9d7e39277809

なのでこれから本文抽出する人はこちらを使ったほうがいいよ、という結論でした。 https://github.com/petitviolet/python-extractcontent

自分への教訓:Googleで検索して一番上に来たからといって一番メンテされているとは限らない。

2014-12-03

HTTPよりHTTPSの方が速い?それSPDYですから!

HTTP vs HTTPS Test — Does encryption make websites slower or faster?というサイトでHTTPとHTTPSの速度の比較ができて、しかもHTTPSの方が速い、なぜ?という話をFacebookで見て、僕もChromeで試してみたら確かに速い。なぜ?

SPDYですよね。参考文献:Web表示の高速化を実現するSPDYとHTTP/2.0の標準化 | 最新の技術・取り組み | IIJ

SPDYが使われているかどうかを確認できるSPDY indicator - Chrome Web Storeをインストールして試してみたら「SPDY3.1が使われています」という表示が出た。

chrome://net-internals/#spdy を見ると以下のようになっていた。Force SPDY Alwaysをtrueにするか、SPDY Enabledをfalseにして条件を同じにして比較したいのだけど設定の仕方がわからなかった。

SPDY Enabled: true
Use Alternate Protocol: true
Force SPDY Always: false
Force SPDY Over SSL: true

幸い手元に「SPDY未対応なWindows7版のIE11」があったので、こちらで試してみると「Oops. Your browser is outdated and cannot provide accurate test results. Please install the latest version of your favorite browser. 」とか言いやがる。無視して実行するとHTTPとHTTPSで速度に大差なし。

ようするに、このベンチマークはHTTPとHTTPSを比べているというよりは、SPDYなしとSPDYありを比べてる。そこんところ明記しないと真摯でないな。



とここまで書いてからこのサイトに言及しているサイトを調べたら「HTTPS(SPDY)」と「HTTP」ではどちらが高速に接続できるか体感できる「HTTP vs HTTPS Test」 - GIGAZINEが見つかって、この時点ではHTTPSのボタンに「HTTPS(SPDY)」と書かれていたことが判明。現時点では書かれていない。なぜだ……。