2013-09-04

（翻訳）英語は私にとって15年にわたって悩みの種です

Translation

はじめに

Redisの開発者である@antirezが一昨日投稿したブログポストにとても共感したので翻訳しました。

English has been my pain for 15 years - <antirez>

作者: 関正生
出版社/メーカー: 中経出版
発売日: 2008/02
メディア: 単行本
購入: 14人クリック: 99回
この商品を含むブログ (31件) を見る

僕が@antirezの文章を翻訳するのは今回が初めてではありません。RedisのドキュメントをまだRedisがバージョン2.0になったばかりの頃に日本語訳したのが最初でした。Redisドキュメント日本語化をしていた当時は翻訳しながら「ドキュメントが整っているなぁ」と感じたと同時に「独特の英語を使うなあ」という印象を受けました。その当時は彼が英語に苦労していた過去のことなど知らなかったので、こうして本エントリを読んで振り返ってみると、苦労しながら英語のドキュメントを整えた彼の労力に本当に頭が下がります。

感じることはたくさんありますが、まずは彼のエントリを読んでみてください。

英語は私にとって15年にわたって悩みの種です

ポール・グレアムがニュースサイトやソフトウェア開発者が注目している彼のブログの中で、IT関連職従事者に必要とされる英語という言語について、非常に重要な問題提起をしました。（追記：こちらも id:yomoyomo の日本語訳があります！ c.f. 創業者の訛り）このエントリは「外国訛り」について触れたことやそもそもインターネット上には大げさに反応したがる人がたくさんいることから大いに賛否両論でましたが、その点は先ほど言った問題提起の中では面白くない議題なので、ここでは省略します。重要な点は、通常誰も「英語問題」について話さない、というところです。そして私はいつもこの点で孤独に感じるのです。まるで私しか気にしていない問題のように感じるのです。なので、このブログポストで、私が英語を使ってきた中で経験してきたことを共有したいと思います。

話せば長くなります

私とsullivanがミラノにあった私の自宅で酔っ払いながら、当時取り組んでいた新しい攻撃方法を編み出そうと頑張っていたことを思い出します。あれは1998年のことで、BUGTRAQの参加者なら見ればわかると思いますが、残念な結果に終わりました：http://seclists.org/bugtraq/1998/Dec/79

ここで2行目の "Instead all others" という部分に注目してください。私はいまだに英語が得意ではありませんが、15年以上かけて上達してきましたし、sullivanにいたっては今やアメリカとイギリスの大学で教鞭をとっているぐらいですから彼は相当流暢であることでしょう。（ネタバレ注意：私はまだ流暢ではありません）さて、それはおいといて問題は、私達はTCP/IPの新しい攻撃方法を紹介しようとしていたのに、二人ともそれを英語では全然うまく書けなかったのです。 1998年の当時、私はすでに英語でうまくコミュニケーションが出来ない、英語で書かれた技術文書は労力をつぎ込まないと読めないという事実から、ものすごく制限を受けているように感じていました。そのことから、私の頭は単純に英語を読むという作業にその50%を使い、実際に読んでいるものを理解するための力は50%以下しか残されていませんでした。

しかしながら、どこかしら、いつも英語はいいものであるということを受け入れていました。人にはいつも技術的な話題では英語を訳さなくて済むようにするアドバイスしています。その理由は、ドキュメントやソースコードのコメントに共通言語を持つことは本当に良いことだと信じていて、実際に英語で書かれた技術文書を理解するために必要なスキルを得るのは多くの人にとって単純な努力だからです。

こうして、1998年から、私は少しずつ英語を勉強して、イタリア語の場合と比較しても変わらないほどにすんなりと英語を読めるようになりました。それどころか、イタリア語でものを書くのと変わらない速さで英語をかけるようにもなりました。書く能力に関しては極小点にあるとしても、あなたがこのブログを読んでいるという事からも、ちゃんと書けていることは証明されています。基本的に私は砕けた簡単な英語をとても速く書くことで学びました。この方法は普通の場合、プログラミングの領域では自分の考えを表現するのには十分ですが、一般的な話題について書くには不十分です。たとえば、私は台所で見つけたものについて何か書こうと思った時に必要な単語がほとんどわかりません。あるいは、複文、仮定法などを含んだ文を書くために必要な文法も知りません。今や私が気になっている話題では容易にコミュニケーションがとれますし、その話題に関しては多かれ少なかれ私が書いたものはみんなが理解できるので、英語を上達させなければ、というプレッシャーは少しずつ減ってきています。。。しかしながら、最近これは私が英語について感じる問題の中では小さなものだとわかったのです。

ヨーロッパ英語、あの面白い言語

なんとかして、自分の用途には快適に英語を読み書きできるようになった一方で、最近まで英語圏の国で実際にコミュニケーションをしたことがほとんどありませんでした。それまでは、英語をいつも（イギリス以外の）他のヨーロッパの人、例えばフランス、ドイツ、スペインといった国の人々との会話に使ってきました。いまや、こうした国々で話される英語が英語学校の授業で話される英語となっています。音声学的に言って、この英語はアメリカ英語やイギリス英語とはほとんど無関係です。これを「BBC英語」と呼ぶ人もいますが、実際は違います。イギリス英語の文法を使っている、音声学的に非常に単純化された英語です。

その英語によって、実際に世界中の人々が容易にコミュニケーションを図れるようになりました。基本的な文法は習得する上で容易で、数ヶ月訓練すれば話せるようになります。単語の発音はヨーロッパ内のイギリス以外の国々ではほぼ一緒です。素晴らしく便利です。

唯一の問題があって、この英語は実際の英語圏の国、イギリス、アメリカ、カナダといった英語が母国語の国とは無関係だ、ということです。

結局英語は崩れつつある

ここであなたに秘密があります。英語と世界という文脈において誰も語らない秘密です。それは「英語は音声学上、砕けた言語だ」ということです。イタリアには長い歴史がありますが、政権が統一されたのはつい最近のことです。異なる地域で異なる方言を使っていて、皆それぞれに非常に強い訛りがありました。 1950年より前に、「TV用言語統一」が起きた時に、まだ皆それぞれ自分たちの方言を使っていて、イタリア語はほんの少数の人間だけしか習得していない状態でした。私の家族がよく使っているシチリア語もイタリア語が現れる何世紀も前から存在しています。（http://ja.wikipedia.org/wiki/%E3%82%B7%E3%83%81%E3%83%AA%E3%82%A2%E8%AA%9E）

それでもなお、面白いのが、ある地域の人が他の地域の人のイタリア語、たとえばスイスの人のイタリア語でさえも理解するのは全く問題がないというところです。イタリア語は音声学的に地球上で最も単純かつ十分な冗長性を備えた言語の一つです。事実、イタリア語は情報エントロピーが低く、単語は通常子音と母音が程よく混ざっています。単語を発音するときに特別なルールはなく、すべての文字の発音を知っていて、いくつかある「gl<母音>」「sc<母音>」という特別な組み合わせさえ覚えておけば、99.9%の単語を初見でも正しく発音することができます。

異なる英語を話す国々から来た人々がコミュニケーションをするときに問題があるという事実が、英語が音声学的にいかにおかしいかということを示す大きなヒントとなっています。たとえば、私や他の非ネイティブの英語話者からすると、イギリス人が口からどんなクソを垂れてるのか、さっぱり全く全然聞き取れません。北米の英語のほうがよっぽど簡単です。

英語のこの「特徴」があるので、私の訛りではなく人が私に話していることを理解する力が問題となります。これは愚見で、前者は私がもっと努力すれば直せる単純なものです。私見ではありますが、ポール・グレアムが「訛り」について触れたのは、この点においてイギリス人やアメリカ人の良くない姿勢です。言わせてもらいますが、あなた方は私達の話していることを理解していない、私達もあなた方が話していることを理解していない、そして一度露骨に理解しようとする線を制限してしまえば、落ち着いて会話を楽しもうとする人なんてほとんどいなくなってしまいますよ。私はイギリス人の英語を理解できないとは言いましたが、すぐに復唱するくらいのことはしますよ。

文章だけで英語を学ぶのは本当に厳しい

私の意見では、私が英語学習に時間がかかった理由のひとつは、英語を全く聴き取りをせずに読み取りの練習を始めてしまったことです。頭の中では、大量の英単語が綴りと実際にはありもしないおかしな発音とが結びついてしまっています。私からのアドバイスとしては、もしいま英語を勉強しているのであれば、すぐに聴き取りも始めて下さい。

Mac OS Xに付属している "say" コマンドが良い助けになります。 "say" コマンドはたいていの英単語をきちんと発音してくれます。発音を学ばずに英語を勉強しては いけません 。

内向的か外向的か

英語に関する経験として最も衝撃を受けたことの一つに、英語を習得していないことがどれほど人を内向的にさせるかという点がありました。私はイタリアという、殆どの人が外交的な国においても外交的で、シチリアというさらに外交的な土地においても外向的で、外向的という要素で構成された家族内においても外向的でした。私は思うにいわゆる目立ちたがり屋なのです（本当はそうは思いたくないのですが、非常に外交的です）。そして、私が英語で話さなければならなくなった途端に、コミュニケーション障壁から外交性はまったく消え去り、その会議に参加したことや、誰かに紹介されることを後悔していました。あれは悪夢でした。

もう手遅れだ、英語を学ぼう

私の意見では、英語は文法が簡単なだけで、共通言語として選択するには間違っています。しかしながら現実は、すでに共通言語としての地位を獲得していて、もうその座を置き換える時間はなく、多くの努力が必要になったとしても英語をうまく話せるようになることを考えるほうがいいでしょう。これは私がいま行っていることで、さらに改善しようとしている部分でもあります。

私が本当に英語を上達させなければならないと感じた他の理由は、10年後には私は職業としてコードを書くことはおそらくなくなって、選択肢としてIT系の管理職になる、もしくはコードを書くことを期待されていない大きなプロジェクトのリーダーとなる、のどちらかだからです。開発者として英語が必要だと感じるとすれば、典型的なIT企業の他の部署に移って、さらには多くのプログラマをマネージメントする立場になっていくにしたがってそう思うようになるでしょう。

一方で、ネイティブの英語話者は、多くの人が英語という習得が大変な言語を本当に頑張って勉強しているということをきちんと理解すべきです。英語の勉強は趣味じゃないんです。英語を修得することは多くの人々がコミュニケーションを円滑にするために行なっている多大な尽力なんです。数週間英語を使わなくなっただけで、英語が言うに及ばないほどすぐに下手になってしまうんですから。

いつかは異なる訛りが1つの理解しやすい標準語にまとまって、それが英語話者の共通語となることを願っています。（翻訳ここまで）

おわりに

ヨーロッパの人でも英語の習得に苦労しているという実体験を赤裸々に公開してもらえると、英語の習得に苦労している自分も励みになります。

僕もアメリカでパスポートから何から盗まれてしまっても自力で帰国するくらいは英語を使えるようになりましたが、それでもネイティブ英語話者の同僚とのコミュニケーションには苦労しています。それは英語だけではない文化の共有ができていなかったりだとか、そういう部分です。これは英語という言語自体の習得だけではどうしようもない部分でしょう。ただ、ことITの世界の話題に関していえば、誰もが共通の文化をもってコミュニケーションが出来るわけで、その習得に労力を割くことは僕も大いに意味があると実感しています。こうやって彼のエントリをそのまま読めるわけですし。

日本には本当に優秀な技術者がたくさんいるにもかかわらず、英語というただ1点だけで損をしている事例を数多く見ているので、1人でも多くの技術者が1文字でも多くその技術を世界の人々に発信出来る日が早く来ればいいなと願っています。

追記

2013.09.05 00:34 : +Jun Mukaiのコメントをもとに訂正
2013.09.05 10:00 : id:yomoyomoのポール・グレアムの原文「創業者の訛り」をリンクとして追加

原著者の許可

@ymotongpoo of course, thank you for translating it
— Salvatore Sanfilippo (@antirez) 2013年9月3日

2013-08-14

実践ベストプラクティスを適用してみる

はじめに

こんにちは、Go界のジェフ・ベゾスです。シアトルのお父さんがGoでおもしろプログラムを書いているようですが、ちょっと気になったので勝手に添削しました。

今日も明日もググったー: golang certificate ssl handshake

元のコード

まず最初のコード。

package main

import (
    "crypto/tls"
    "crypto/x509"
    "fmt"
    "log"
    "os"
)

func main() {
    if len(os.Args) < 1 {
        log.Fatal("You must input a hostname")
    }
    peerCertificates, err := GetCert(os.Args[1])
    if err == nil {
        for i, Cert := range peerCertificates {
            fmt.Printf("i=%d\\n", i)
            fmt.Println(Cert.Issuer.ToRDNSequence())
            fmt.Println(Cert.NotBefore)
            fmt.Println(Cert.NotAfter)
            fmt.Println(Cert.Subject.ToRDNSequence())
        }
    } else {
        log.Fatal(err)
    }
}

func GetCert(host string) ([]*x509.Certificate, error) {
    config := &tls.Config{InsecureSkipVerify: true}
    conn, err := tls.Dial("tcp", host+":443", config)
    var peerCertificates []*x509.Certificate
    if err == nil {
        connectionState := conn.ConnectionState()
        peerCertificates = connectionState.PeerCertificates
    }
    return peerCertificates, err
}

勝手に添削

エラー処理は先に書く

Goには例外処理はありません。通常関数の戻り値を正常値とエラーのタプルとして、異常がある場合にはエラーにError型の何かが入るという形になります。さて、例外処理がない分、エラーの扱いはCと同様、if等で扱うことになります。ベストプラクティスとしては、 err が nil でないパターンを先に処理するべきです。そうしないとif分がネストしやすくなる上にコードが見辛くなります。この間のOSCON 2013でもエラー処理のベストプラクティスとして話されていました。

Twelve Go Best Practices

エラー処理を先にしてみるとコードもちょっと読みやすくなりました。

package main

import (
    "crypto/tls"
    "crypto/x509"
    "fmt"
    "log"
    "os"
)

func main() {
    if len(os.Args) < 1 {
        log.Fatal("You must input a hostname")
    }
    peerCertificates, err := GetCert(os.Args[1])
    if err != nil {
        log.Fatal(err)
        return
    }

    for i, Cert := range peerCertificates {
        fmt.Printf("i=%d\\n", i)
        fmt.Println(Cert.Issuer.ToRDNSequence())
        fmt.Println(Cert.NotBefore)
        fmt.Println(Cert.NotAfter)
        fmt.Println(Cert.Subject.ToRDNSequence())
    }
}

func GetCert(host string) ([]*x509.Certificate, error) {
    config := &tls.Config{InsecureSkipVerify: true}
    conn, err := tls.Dial("tcp", host+":443", config)
    if err != nil {
        return nil, err
    }
    var peerCertificates []*x509.Certificate
    connectionState := conn.ConnectionState()
    peerCertificates = connectionState.PeerCertificates
    return peerCertificates, err
}

型推論を積極的に使う

GoはCとPythonの中間的な文法や記述をしますが、どちらかというとC寄りではあります。ただ、豊富な標準パッケージや型推論、初期化演算子などで、記述量を減らすことが可能になっています。変数宣言も出来るだけ初期化と同時に行ったほうが読みやすいコードになります。

func GetCert(host string) ([]*x509.Certificate, error) {
    config := &tls.Config{InsecureSkipVerify: true}
    conn, err := tls.Dial("tcp", host+":443", config)
    if err != nil {
        return nil, err
    }

    connectionState := conn.ConnectionState()
    peerCertificates := connectionState.PeerCertificates // peerCertificatesは初期化もしちゃう
    return peerCertificates, nil
}

さらに言えば必要ない宣言も減らせるので次のように落ち着きます。

func GetCert(host string) ([]*x509.Certificate, error) {
    config := &tls.Config{InsecureSkipVerify: true}
    conn, err := tls.Dial("tcp", host+":443", config)
    if err != nil {
        return nil, err
    }

    connectionState := conn.ConnectionState()
    return connectionState.PeerCertificates, nil
}

添削後

package main

import (
    "crypto/tls"
    "crypto/x509"
    "fmt"
    "log"
    "os"
)

func main() {
    if len(os.Args) < 1 {
        log.Fatal("You must input a hostname")
    }
    peerCertificates, err := GetCert(os.Args[1])
    if err != nil {
        log.Fatal(err)
        return
    }

    for i, Cert := range peerCertificates {
        fmt.Printf("i=%d\\n", i)
        fmt.Println(Cert.Issuer.ToRDNSequence())
        fmt.Println(Cert.NotBefore)
        fmt.Println(Cert.NotAfter)
        fmt.Println(Cert.Subject.ToRDNSequence())
    }
}

func GetCert(host string) ([]*x509.Certificate, error) {
    config := &tls.Config{InsecureSkipVerify: true}
    conn, err := tls.Dial("tcp", host+":443", config)
    if err != nil {
        return nil, err
    }

    connectionState := conn.ConnectionState()
    return connectionState.PeerCertificates, nil
}

2013-08-05

OSCON 2013でのGo関連の発表

はじめに

こんにちは、Go界の平賀源内です。さて、先月末にOSCON 2013がオレゴンで開催されましたが、その中発表でいくつかGo関連で話題になったものもあったので、一つまとめてみようと思います。

Go関連の発表

Go関連の発表は以下の7つでした。（発表時間順）

特に最後の @bradfitz による dl.google.com をGoで置き換えた話はかなり話題になっていましたね。というわけで以下、僕が注目した順に簡単に内容を紹介します。

dl.google.com: powered by Go (by Brad Fitzpatrick)

スライドはGo製のオリジナルツールで次のURLでホスティングされています。

dl.google.com: Powered by Go

数多の著名なオープンソースプロダクトを作ってきた @bradfitz 先輩ですが、いまはGoのコアチームで働いています。そんな彼が、Google社内でプロダクションユースでGoが使われている例としてdl.google.comをC++からGoに移植した例を紹介し、その中で使われているgroupcacheについても紹介しています。

スライド概要

（スライド #01-#11）Googleのコンテンツダウンロード用サーバであるdl.google.comは、元々2007年にC++で実装されていたが、リクエストが増加するに連れてサーバが逼迫され、速度が有り得ないほど遅くなったので、 @bradfitz はじめとするGoチームが「俺らが書き換えてやるよ！」と言って2012年に書き換えた。
（スライド #12-#17）ここで「なぜコードは悪くなっていくのか」について語っている。はじめは良くても、複雑な要件に対応するためコードも複雑になり、また前提とする環境やスケール感も変わり、さらにドキュメントやテストもないハックやワークアラウンドが増え、メンテナーもどんどん出入りし、あるいは出て行くだけで、メンテがされなくなっていくためである。
（スライド #18-#19） Googleでは上に挙げたような前提が日々変化していて、開発当時は素晴らしかったコードもすぐに古びたものになってしまう。実際にdl.google.comの場合は、シングルスレッドのイベントループが実装されていて、マルチコアCPUでも1コアしか消費せずに固まっていた。
（スライド #20-#30）根本原因はシングルスレッドのイベントループとコンテンツをローカルディスクから配布していたことにあり、それを回避するために諸々行ったが、そもそものイベントループ内でNバイトのデータをコピーするだけでありえない量のコードを書かなければいけなかった。（node.js、Twisted等々他のイベントループを持つフレームワークでも同様）
（スライド #31-#34） Goではそもそも並列性が言語仕様レベルでサポートされてるので、さらっと書けた。その後、少しずつ既存のC++製の部分を置き換えていって、最終的にGo製に置き換わって、遅かったローカルディスクからのデータ読み込みもblobstoreを使うようになり、スタートアップも早くなった。
（スライド #35-#42）dl.google.comではほぼ標準パッケージしか使っていない。net/http、ioのパッケージ内にファイルサーバに必要な型や関数がすべて定義されている。
（スライド #43-#47）groupcacheの紹介。memcachedの代替をするクライアントとサーバ両方のためのライブラリ。poolとpeerを宣言して、その後グローバルで一意なgroupを宣言する。groupにキーを指定すると値が取れる。groupはpeerグループ内で共有され、キーに対応する値はpeerグループ内のいずれかのpeerから取得される。　
（スライド #48-#54）dl.google.comではchunkとio.SectionReaderをうまく使い、複数の値を読み込んでデータを結合して返している。結果としてHTTPの煩わしいロジックから開放され、純粋にビジネスロジックの実装に集中できた。
（スライド #55-#58）サービス自体をバイナリ1つに出来たし、すごくよかった。
（スライド #59）いいことづくめ
（スライド #60-#63）C++版を再実装する理由が見当たらない。dl.google.comの内容はほとんどオープンソースになってるからみんな使ってね。

というわけで、groupcacheがこの日に公開されました。

golang/groupcache · GitHub

Go Best Practices (by Francesc Campoy Flores)

こちらもGoのコアチームにいる @compoy83 からのGoのベストプラクティス集。 @bradfitz のプレゼンはGoの啓蒙寄りな内容だったのに対し、こちらはすでにGoを書いているエンジニアを対象としたノウハウ集でした。挙げられていたベストプラクティスは次のとおり。

こちらもスライドはgo.talksに置いてある。

Twelve Go Best Practices

ベストプラクティスの内容は次の通り。

エラーハンドリングをまず行い、ifのネストを避けろ
エラーハンドリングの繰り返しを避けるために、一時的な型を作る。必要であればtype switchで例外的処理を扱ったり、switchで変数宣言する。関数アダプタを使って例外処理とロジックを分ける。
大事な情報から先に書く。ライセンス情報やドキュメント。import内ではグループ（標準パッケージ or 3rd party）ごとに空行で区切りをつける。補助関数や補助的な型は後ろの方に書く。
ドキュメントを書く
命名時は読んで意味が分かる一番短い名前を付けるように努める
パッケージは複数ファイルで構成する。net/httpを例として次の3つの規則を紹介。「長いファイルは分割する」「テストと本体は分ける」「ドキュメントもdoc.goというファイルに分ける」
パッケージを"go get"した時に便利なようにする
本当に必要なものを書く。structでなくinterfaceを引数に取ることでテストしやすくなる。
独立したパッケージをきちんと分けておく。
API内で並列なコードを避ける。同期なAPIを提供すれば、呼び出し側で簡単に並列にできる。
状態管理にgoroutineを使う。
goroutineリークを避ける。buffered channelやquit channelを使う。

Go Language for Ops and Site Reliability Engineering (by Gustavo Franco)

GoogleのSites Reliability Engineer（インフラ部隊）の人が語るGo言語。このプレゼンはOSCONの3ヶ月前にO'Reilly主催のHangout on Airで既に話されていましたので、動画も貼りました。いわゆるアプリケーションエンジニアとは異なる観点からのGo言語の評価、という点で興味深いプレゼンです。

Go Language for Ops and Site Reliability Engineering

O'Reilly Webcast: Go Language for Ops and Site ...

スライドの要点は下記

インフラエンジニアからしたら、ただ書き捨てのスクリプトが欲しいだけで、新しい言語は覚えたくない。ワンライナーは便利なので使い続けるけど、できれば道具として見れる言語を少しだけ覚えるだけに留めたい。
その点でGoは、オープンソースだし、バイナリが出来ればそれを動かすだけで済むし、ビルドファイルは要らないし、ビルドも速いし、GCはあるし、読みやすいし、RE2は使えるし、テスト、ベンチマーク、プロファイラが全部標準で入ってるので楽。標準パッケージが豊富なのも良い。
またgoroutineとchannelを用いた並列性のサポートがはじめからあるのもよい。
最近のLLが持っているような特徴も兼ね備えていて良い。（map、slice、モジュール機構、struct、メソッド、ポインタ演算のないポインタ）
Google社内はもちろん、Google外にも多くのプロダクションレベルのインフラ環境での利用がある。

啓蒙という視点ではなく、現実的な視点からプロダクションに耐える言語だということを説明しているプレゼンでした。

Rethinking Errors: Learning from Scala and Go (by Bruce Eckel)

今回のOSCONでは珍しいGoogler以外からのGoのプレゼン。その意味で、非常に貴重だし、なによりGoを始めるとすぐに取り沙汰されるGoにおけるエラー処理を言及したプレゼン。資料はこちら。タイトルにはGoとScalaしか書いてないけど、むしろサンプルはPythonで説明している。

Rethinking Errors

スライドの要点

新しいエラー処理機構の潮流として正常系の返り値とエラーを同時に返すというやり方がある
C, C++, Java, Python, Ruby, PHPと、数値またはシグナルを返すところから始まったエラー通知が徐々に例外処理へと変化していったが、制限も大きかった。
Goは初期はエラー処理機構はなく後からpanicとrecoverが追加され、ScalaではEitherまたは専用型で、Pythonでは例外以外にもGoのようにタプルでエラーを返したり専用オブジェクトを返す方法をとれる
Pythonでの例ではあるが、スピーカーの結論は必要以外には例外処理を使わず、通常の分岐処理で対応できるようにしよう、という事のようです。

Goの話はタプルで正常値とエラーを同時に返して、通常の分岐処理で対応できている点がいいね、という話しか出てきてなかったです。

How Learning Go Made Me A Better Programmer (by Johan Euphrosine)

こちらはGoogle App EngineのDeveloper Program Engineerの @proppy による、Goの優れたところ紹介集。時々Python、Java、node.jsとの比較をしながらGoの良いところを挙げている。

0xa things I love about Go

このスライドで上がっているのは次の点

可読性（Pythonとの比較。ほぼPseudo Codeだよ。言語仕様だけでなく、go fmtなどのツールが標準であるのも良い）
エラーハンドリング（Python、Java、node.js、Haskell、Rustとの比較。
標準パッケージ（非常にリッチ。Pythonと比較してもリッチ。）
XMLとJSONの扱い（標準パッケージでサポートされている。XMLとJSONの扱いで一貫性がある。Pythonとの比較。）
パッケージングと配布（ツールが良きに計らってくれて非常に楽。ビルドファイル要らない。Python、Java、node.jsとの比較）
ツール（標準でテスト、文法チェック、パッケージング等々行なってくれる。Python、node.jsとの比較）
並列性のサポート（ランタイムに含まれている。node.js、Pythonとの比較。）
Interface（暗黙的に判定、Compositionも可能。Pythonのduck typingとの比較。）
Composition（複数のstructを組み合わせられる。Interfaceと直交する機能。PythonやRubyのmixinとの比較。）
Community（もりあがってるよ）

Introduction to Go (by Francesc Campoy Flores)

"A Tour of Go" を使ったチュートリアルセッションでした。みなさんもGoを始める時はまずは"A Tour of Go"で文法を学ぶのがベスト。（演習問題は飛ばしていいと思う。）

A Tour of Go

Office Hour with the Gophers (by Brad Fitzpatrick, Johan Euphrosine, Francesc Campoy Flores)

オフィスアワーです。僕も @bradfitz と @compoy83 にまだ直接会って話したこと無いので話してみたい。 @proppy はもしかすると今度のPyCon APAC 2013に来るよ。

おわりに

Goはまだまだ若い言語ですが、OSCONのような場所でしっかりと実例を紹介できるところまで来ていると認識出来たのは素晴らしいですね。groupcacheは今回の目玉でしたが、Google SREのGastavoのスライドにあったように、DockerやPackerやJujuといったインフラ系のツールにGoが使われている点で、流行り廃りでない、本物の存在感を感じ取ることが出来るような気がします。

これからのGoが楽しみですね！

2013-08-03

Google画像検索を使って偽アカウント判定

misc

はじめに

こんにちは、Go界の谷崎潤一郎です。さて、半年ほど前に一時期Facebookの偽アカウントが大量発生しましたが、今もまだしぶとく偽アカウントが発生しているようです。 IT系の知り合いはあまり引っかかってないようですが、地元の友達などは結構簡単に友だち登録してしまっているようです。可愛いお姉さんのプロフィール写真があったら許可したくなっちゃいますよね。でも、色々と危ないんで、スパムアカウントは運営にブロック申請したほうがいいです。まじで。

偽アカウント3つでアウトー！『Facebook』が乗っ取りリスクを警告今すぐ対処しよう - アップス！-iPhoneの無料アプリ情報やニュースを配信中

Google画像検索

しかし、プロフィール写真の可愛いお姉さんが本当にその人なのかどうかは気になっちゃうと思うので、その判定方法を教えます。Google画像検索です。おあつらえ向きに偽アカウントが友達申請してきたので実際に確認してみます。

f:id:ymotongpoo:20130803095720p:plain

写真も可愛らしいうえに、プロフィールで出身地が僕の地元の山梨県。しかも既に僕の地元の友達が2人友達になってしまっていますね。しかしプロフィールが生まれ年と出身地しか無い上に、投稿がプロフィール写真と背景画像の投稿だけという、非常に偽アカウント臭が漂うアカウントです。早速プロフィール写真をGoogle画像検索にかけてみます。まず画像のURLをコピー。

f:id:ymotongpoo:20130803100547p:plain

Googleトップから画像検索に行く。

f:id:ymotongpoo:20130803100231p:plain

カメラのアイコンを押して、さきほどの画像URLを貼り付けて検索。

f:id:ymotongpoo:20130803100737p:plain

f:id:ymotongpoo:20130803100751p:plain

すると、検索結果に台湾ドメインのウェブサイトのURLが出て来ました！

f:id:ymotongpoo:20130803100943p:plain

どうやらこのお姉さんは台湾のどこかにいるようです。

おわりに

いくらプロフィール写真が可愛いからってホイホイ友達申請許可してはダメです。

2013-07-31

#Go羅温泉 #電車でGo というイベントをしてきました

Go Event

はじめに

こんにちは、Go界のアインシュテュルツェンデ・ノイバウテンです。7月にGo界隈の人々でイベントをしてきましたのでここにご報告します。

Go羅温泉

Pythonコミュニティも大きくなりましたが、その中で「Python温泉」というイベントがあります。「ドキッ、男だらけの(ry」状態な2泊3日のハッカソンイベントなわけですが、Goのコミュニティの一でもそういうことしたいよねえ、ということで、箱根温泉街の強羅温泉に行ってきました。朝9:00に新宿に集合して、余裕のロマンスカー乗車で、箱根でちょっと観光しようと思っていたのに、当日はロマンスカーが全部運休、箱根登山鉄道もなかなかの混み具合で大変でした。ラフォーレ強羅の会議室はなかなか広く、結構快適でした。

皆それぞれに持ってきた課題を結構こなせたようで、僕にとっても皆さんにとっても実りある温泉旅行でした。以下、ハイライト箇条書き。

LiveLeak.comでロシア人の動画を探しているとかなりクレイジー
goclipseはいろいろ動かすのがしんどそうなのでやめとこう
強羅温泉は箱根湯本から結構遠い
ラフォーレ強羅の周辺は徒歩30分圏内にはコンビニがないので気をつけろ

幹事行をしてくださった、 @Jxck_ さん、ありがとうございました！

電車でGo

Go羅温泉のあとに「電車でGo」というイベントを行いました。

電車でGo! - connpass

募集告知をした直後にはキチガイイベント認定されました。

完全なキチガイについての情報をお伝え致します URL
2013-03-24 13:59:06 via Twitter for Google TV

実際に行なってみると非常に楽しいイベントで、お子さん連れの参加者も楽しんでくれたようです。なによりお子さんが楽しんでくれました。貸切の都電荒川線。「前にGopher人形乗せていいですか？」と運転手さんに聞いたら「はいはい、なんでも置きな！」とのこと。フランクすぎる。

ハッカソン中の様子

都電荒川線の醍醐味、飛鳥山周辺での路面。

最後三ノ輪橋駅での記念撮影。

撮影の @nuki_pon さん、ありがとうございました！

Goコミュニティではこれからもネタドリブンのイベントをどんどん行なっていこうと思います。どうぞよろしくお願いします。

YAMAGUCHI::weblog

海水パンツとゴーグルで、巨万の富を築きました。カリブの怪物、フリーアルバイター瞳です。

（翻訳）英語は私にとって15年にわたって悩みの種です

はじめに

英語は私にとって15年にわたって悩みの種です

話せば長くなります

ヨーロッパ英語、あの面白い言語

結局英語は崩れつつある

文章だけで英語を学ぶのは本当に厳しい

内向的か外向的か

もう手遅れだ、英語を学ぼう

おわりに

追記

原著者の許可

実践ベストプラクティスを適用してみる

はじめに

元のコード

勝手に添削

エラー処理は先に書く

型推論を積極的に使う

添削後

OSCON 2013でのGo関連の発表

はじめに

Go関連の発表

dl.google.com: powered by Go (by Brad Fitzpatrick)

Go Best Practices (by Francesc Campoy Flores)

Go Language for Ops and Site Reliability Engineering (by Gustavo Franco)

Rethinking Errors: Learning from Scala and Go (by Bruce Eckel)

How Learning Go Made Me A Better Programmer (by Johan Euphrosine)

Introduction to Go (by Francesc Campoy Flores)

Office Hour with the Gophers (by Brad Fitzpatrick, Johan Euphrosine, Francesc Campoy Flores)

おわりに

Google画像検索を使って偽アカウント判定

はじめに

Google画像検索

おわりに

#Go羅温泉 #電車でGo というイベントをしてきました

はじめに

Go羅温泉

電車でGo