ゼロから学ぶGo言語プログラミング（2）　Goの簡単な全体像

プログラミング Golang

とりあえず、今の自分が気になった、キャッチーなところだけ。

Goはどんな言語？

Goは、Googleが開発し2009年に発表したプログラミング言語です。 Googleの述べた特徴の訳がGo言語とは - golang.jpに掲載されているので、引用します。

これを見ると、特徴そのものがシンプルです。 一番に"シンプル"を掲げていることは、Go言語全体に流れる思想なのかも知れません。 上で挙げたFAQ - golang.jpを見ると、開発動機には、やはりシンプルさが大きいようです。

CやC++のような位置付けでも使える言語を目指しつつ、スクリプト言語のような手軽さ、シンプルさも両立したい、という感じでしょうか。 Appleが発表したSwiftも似た雰囲気ですが、これから出てくる新しい言語の主流はこういうコンセプトを目指すのかも知れません。

コンパイル型の言語

私はこれまでPHP・Python・JavaScirptと、いわゆるWeb向きのスクリプト言語ばかりに浅く触れてきたので、明示的にコンパイルが必要な言語へのイメージがほとんどありません。

C#ではコンパイルっぽい操作を伴いましたが、使い捨てのツールを作るばかりで、言語や機構はほとんど理解していません。 コンパイルが機械語への翻訳で、動作速度が速い、コンパイル時に最適化が行われる、という程度。

コンパイルとは何か、なぜGoはコンパイルを選んだのか。 Goを学ぶ中で、コンパイルの理解も進める必要がありそうです。

並列処理

Goの特徴として標準で並列処理に対応している、というのが謳われています。 しかしここでもシンプルさを求めた結果、多少耳慣れたスレッドやプロセスでなく、「ゴルーチン」と「チャネル」という概念を導入しているようです。

ゴルーチン辺りを見ると、"go"というキーワードを無名関数に添えるだけで、複雑な管理をしなくても、シンプルに並列性を持たせることができるようです。

この並列処理の容易さは、Goの優れた点として挙げられるのをよく目にするので、しっかり学ぶ価値がありそうです。

名称

Goは囲碁から採られたそうです。 ようですが、"Go"ではあまりに区別しにくいため、日本語の場合は「Go言語」、その他では「Golang」と表記されることが多いようです。

マスコットキャラクター

f:id:belbo:20140606104654p:plain

by The Go Gopher - The Go Blog

Goのマスコットキャラクター、Go Gopherです。

作者はRenee Frenchで、マスコットとして採用された経緯は以下の記事が詳しい。

ラジオ局のプロモーション用に生まれ、ベル研のメンバーのアバターに。あのPlan 9のキモかわいいウサギはgopherの遠い親戚的なもの…。

マスコットもPlan 9つながり、主要な設計者のひとり、ロブ・パイクはPlan 9開発を率いた人物、コンパイラのコマンド（gccgo - golang.jp）もPlan 9由来ということで、GoはPlan 9の色々を断片的に受け継いでいるようです。

次はHello Worldで、コードを見てみます。

ゼロから学ぶGo言語プログラミング（1）　はじめに

Golang プログラミング

f:id:belbo:20140606104654p:plain

本職ではありませんが、プログラミングが好きです。 でも週末自分の趣味に関係して、その時々興味のあるものを触るばかりで、何かに集中してしっかり学んできませんでした。 知人のプログラマと話す内に、そろそろ「これはしっかり把握したぞ」と言えるものが欲しくなりました。

最近、Go言語が気になっています。 Googleが開発したこの言語は、採用事例もどんどん増え始め、Dockerという先進的なプロダクトでも使用されているそうです。 私はGoogle App EngineというGoogleのPaaSが好きなんですが、ここでもGoは対応言語のひとつに採用されています。

このGo言語、以前一度はしっかり学んでみようと手を付けたのですが、少し仕事が忙しくなっただけで放置してしまいました。 しかし爆発的な普及の兆しも見え始めて、学ぶのに良い情報もどんどん増えていきそうなので、改めて取り組んでみます。 当時からGoを取り巻く状況も色々変わっているようですし、この際ゼロから学び直そうと思います。

現時点の自分の力量

  • HTMLやCSSはひと通り扱えるし、最新の動向にもそこそこ対応できている
  • JavaScriptは単発で何かを作るのは十分可能、しかしプロフェッショナルには程遠い
  • PHPはOSSのプロダクトを触る内にある程度習得
  • PythonはGoogle App Engineで色々自分用のアプリケーションを書いていて楽しいが、かなり浅いレベルでしか使っていない
  • PowerShellとかC#とかSQLとかFileMakerとか、全部少しずつ使える
  • Goはサンプルを動かしたり、ちょっとした操作を試し、小さなappengineアプリケーションを作った程度

つまりは、深く真髄をつかむまでいったものが無く、その場その場で必要なところだけつまみ食いしているような状態です。 HMTL・CSSとJavaScriptとPHPはある程度できるけど、どれも浅くしか…という人は、日本に結構な数いると思います。

一番の問題は、プログラミングにおける色々な概念を、必要な時に必要な分だけ、自分なりの解釈をして習得した気になり、理論や検証を全然していない点。 芯が通った拠り所がないので、新たな何かを学ぶほど、ふらふらとぼんやりした理解を繰り返してしまいます。

書き出してみると深刻で、ここはひとつ、Goを通してひとつのプログラミング言語をじっくり学んで、これからの楽しいプログラミング生活を改善していこうと思います。 Goそのものを学ぶというより、Goを通じてプログラミングを学ぶのが目標です。

どうやって学ぶか

情報源

この手の変化が激しい分野の場合、新しい書籍であっても、手に入れた時点ですでに、最新の状況と多少なりともずれがあります。 その辺りはうまく噛み砕けると良いのでしょうが、私はどうもそのずれに引っかかりやすいので、なるべくWebのみで学ぼうと思います。

まず頼りになる公式サイトや定番のサイト。

はじめなので、まずはこの辺りを参考にして、Goの大まかなイメージをつかむことにします。 まずはあまり実際の仕様に踏み込まず、概念や学ぶ上でとっかかりになりそうな点を確認。

Goへの注目が高まって、他にも日本語の良いリソースが増えているので、おいおい選んでいこうと思います。

環境の構築

この手の言語学習では、最初の環境構築に手間取ったり、環境ごと、言語側の開発状況によってつまずいたりがあり得ます。 そこではじめのはじめには、ブラウザ上でGoが試せる以下を利用します。

Go Playground

f:id:belbo:20140606104605j:plain

ここで取っ掛かりを掴んで、コンパイルを行うローカルの環境を、きちんと構築してみようと思います。

大きく値下げしたGoogle App Engineを更に低コストで使う工夫（1）　Small Opsの活用

Google App Engine プログラミング

アマチュアですがプログラミングが好きで、特にGoogle App Engineであれこれ試しています。

登場時こそ大きな注目を集めたGoogle App Engineですが、癖が強く、価格改定などの紆余曲折もあって、EC2などAWSと比べると、最近まで随分下火になっていました。 それがGoogleのクラウドプラットフォーム戦略強化や、大きめの成功事例も出始めたことで、ここ数ヶ月、また注目されはじめているように感じます。

Google App Engineの魅力として一番に挙げられやすいのが、無料でも使える点です。 本来はスケール性こそ最大の魅力ですが、やはり無料枠の存在は大きいです。 無料で使い始められるからこそ、私のような資金の無い個人でも色々試せますし。 しかし無料で収まるような小さな用途であれば、格安のVPSなどを小分けにして使った方が、開発にPaaS的な制約もなく、ロックインもされません。

無料にこだわるんでなく、スケール性という最大の魅力を活かせるような方向で、どう不要なコストを減らすかという考え方が健全だと思います。 そこで、これまで自分がGoogle App Engine使ってきて試した、コストを抑えるための工夫を、少ないですがひとつずつおさらいしてみます。

まずは最近もっともインパクトのあった、DatastoreのSmall Ops無料化について。

大幅値下げと課金設定

おさらい前にまず、最近の大幅な値下げと、課金設定の重要性について。

2014年4月1日からの新料金体系による大幅値下げ

この1～2年でGoogle App Engineを試し、コストを理由に見限った方は、一度今回の新料金体系を確認してみてください。 以下のページに詳細がありますが、これまでの料金設定を知っていると、かなり攻撃的に見えます。

最もインパクトが大きいのは、DatastoreのSmall Ops無料化。 後述しますが、これのお陰でDatastore周りのコストをかなり下げる余地が出てきました。 Datastoreでは更にReadやWriteのOpsも値下げされています。

Instanceの料金も、$0.05/instance hourからに値下げ。 他に、メール送信やPagespeed、そしてプレビュー中ですがソケットAPIも無料化。

これらの料金見直しと、同じく値下げされたGoogle BigqueryやGoogle Compute Engineなど、他のGoogle Cloud Platformサービスと組み合わせを考えれば、以前よりappengineの魅力は大きく増したと思います。

課金設定した方が良い

appengineは無料で始められるのが大きな魅力です。 ただ、実際に運用するのであれば課金設定だけはしておくべきで、以下の理由があります。

  • Socketなど課金設定をしておかないと使用できないAPIがある
  • 課金設定で各リソースやAPIのQuota Limitが大きく増える

ということで、課金設定は是非しておくべきです。 課金上限は非常に小さくできますし、課金される程アプリケーションが利用されているのなら、ペイできる収益を生む余地はある筈です。

Datastoreのコスト抑制

なんといってもGoogle App Engineの特徴であり、選定からの除外理由にもなるのが、標準のデータベースであるDatastoreです。

DatastoreはGoogleのBigtableを、PaaS用に提供しているような代物です。 スケールアウトを重視した分散KVSであり、そのためRDBMSと比べると制約が色々あるように感じます。 DatastoreはRDBMSで当たり前だった正規化が逆効果となったり、クエリに制限があったり、また設計次第でとてつもなくコストが違ってきます。

今回はSmall Opsを採り上げますが、はじめに少しDatastoreのオペレーションについて。

3種類のops

Datastoreに対する操作はPythonやJava、Goなど各言語のAPIで行いますが、内部では3種類のオペレーション（Ops）に分解され、課金もこのOps単位で行われます。 そのOpsには以下の3種類があります。

Read Ops
エンティティの取得時に発生
Write Ops
エンティティの登録時（削除含む）に発生
Small Ops
キーのみを返すクエリなどで発生

これらOpsの内、ReadとWriteは 100,000回あたり$0.06という料金ですが、Smallは値下げによって無料となりました。

Small Opsの活用

$0.001でも無料とは雲泥の差で、Smallが無料になった以上、とことんこれを活用する方向に調整すべきです。 もちろん、今後の値上げ再び有料化される可能性はゼロではありませんが、そもそもDatastoreの構造上、Small OpsはReadやWriteに比べて低価格に設定されるべきものであり、活用すべきことに変わりはありません。

Small Opsは、キーのみを返すクエリによって発生します（数値idに値を割り当てる場合にも発生しますが、コストにそう響くわけではないので省きます）。 キーやエンティティというDatastoreの構造が関わってくるのですが、要は「インデックスだけを見て返せるクエリはSmall Ops」という事です。

Datastoreは、原則として非常に単純なスキャンしかできないエンティティに対して、柔軟なクエリを実行するため、別途インデックスを生成しています。 そのインデックスにはクエリの対象となる値とキーを、全て列記して保持しており、インデックスに載っていないエンティティは、クエリで検出できません。 クエリによってインデックスが走査され、該当するキーを見つけ出すことで、エンティティを特定できます。

この発見したキーからエンティティ本体を読み出す際に、本来はReadが発生します。 しかしインデックスを見るだけで済む場合には、より低コストなSmall Opsとなります。 これがキーのみを返すクエリです。

キーのみを返すクエリ

無料のSmall Opsはクエリにおいて活用します。

DatastoreはKVSであり、キーによってエンティティを取得できます。 しかしそれだけでアプリケーションを構築するのは難しく、RDBMSのような問い合わせが必要です。 それを実現するのがクエリです。

クエリは前述の通り、インデックスの走査です。 エンティティが持つ値に基いて生成されるインデックスは、掲載されるべき全エンティティの値とキーがペアになった表です。 このインデックスの走査時に「キーのみを返す」と指定する事。 これがSmall Opsです。

実はこのキーのみを返すクエリを用いない場合、つまり通常のクエリでは、用途によっては非常に大きな無駄が生じます。 インデックスを走査して該当するキーを抽出し、そのキーを用いて対応するエンティティを取得、そのエンティティをクエリの結果を返す、というのが通常のクエリの流れです。 しかしカウント目的やオフセットを含む場合など、該当した全てのエンティティ本体が必要でない場合、最大で該当したエンティティの数だけ、無駄なRead Opsが発生してしまいます。 クエリの結果としてキーだけを受け取ることで、このような無駄を排除出来ます。

もちろん、エンティティ本体が必要な場合は、結果のキーからエンティティを取得するため、Read Opsが発生します。 しかしクエリの目的や状況に応じて、キーで留めたり、必要な分のみエンティティを取得したりと、無駄なReadの発生を防ぐことが出来ます。

無料のクエリ

値下げによるSmall Opsの無料化では、無料のクエリが可能になり、クエリの利用の幅が広がりました。

まず、クエリのオプションによって発生するOpsの違いです。

通常のクエリ1件
1 Read Ops + 該当エンティティ* Read Ops
キーのみのクエリ
1 Small Ops（但し必要なエンティティ分のRead Ops）

このように、通常のクエリでは最低1回のRead Opsが発生し、更に該当するエンティティの分のRead Opsが発生します。 キーのみを返すクエリではSmall Opsしか発生しませんが、従来はこれが有料でした。

キーを指定して取得できれば1 Read Opsで済みます。 安いとはいえ有料のSmall Opsの発生を抑えるには、クエリを実行しなくてもキーが特定できるような設計が必要です。 しかしSmall Opsが無料となった以上、キーのみを返すクエリを使う限りは、クエリは無料で実行できることになります。 もちろんクエリ無しにキーで直接取得するのに比べれば、多少遅延は発生します。 しかし「クエリでキーのみを取得」 → 「必要なエンティティのみをキーで取得」という手順を、どの状況でもコストの違いなく利用できる方が、メリットは大きいと思います。

各言語別のキー

最後に、キーのみを返すクエリの指定方法を説明する、各言語のリファレンス。 Pythonはdbとndbという2つのパッケージがありますが、特に理由がなければ、ndbを使った方が良いでしょう。

D-Waveの量子コンピューター入門に最適な記事まとめ

コンピューターアーキテクチャ

実用的な量子コンピューターを開発・販売しているという、カナダのD-Wave社。 「その原理は量子コンピューターと呼べるのか？」という疑問を持たれながらも、ロッキードマーチン、GoogleやNasaの採用で注目を浴び、最近ついに日経新聞にも掲載されだしました。

昔から見ていたサイトやその著者が丁寧に紹介していたこともあって、名前だけは知っていましたが、これから更に話題を集めていくと思います。 そこで、D-Wave社の量子コンピューター（とされているもの）の基本を知るのに便利な、日本語のリソースを集めました。

Ando's Processor Information より

Ando's Microprocessor Informationは、研究者でもありコンピューターアーキテクチャ解説の著者でもあるHisa Ando（安藤壽茂）氏が、2001年から続けている業界の話題をまとめた素晴らしいサイトです。 後述の解説記事にもAndo氏の著が含まれています。

D-wave社の初出は2007年。 登場のインパクト、そこから少し間を置いて、懐疑の目、そして採用や検証の広がりなど、これまでの経緯が見えてきます。

Hisa Ando氏の解説記事

マイナビニュースはテクノロジー系のニッチな話題も取り扱っていて、Hisa Ando氏の記事も多数掲載されています。

Cool Chipsのレポートは特に詳細で、実践的な利用の解説も載っており、D-Waveがどのように現実的な問題を解くのか、その一端が見えます。

総論・その他

『ビルマ・シンガポールの従軍慰安所 （日本語仮訳版） 』を読む（2）　皇国臣民意識

韓国

いわゆる慰安婦問題の資料としてだけでなく、読み物としても面白い『ビルマ・シンガポールの従軍慰安所 （日本語仮訳版） 』。この日記から興味深い箇所を紹介します。

資料原文は以下のサイトから、PDFでもダウンロードできます。 発見者であるソウル大名誉教授の安秉直氏、日本語仮訳版監訳の京都大学大学院の堀和生氏、神戸大学大学院の木村幹氏に感謝。

日記を知った犬鍋さんの記事は以下。

皇国臣民

紹介のはじまりとして、著者が日記に残した皇国臣民としての意識を見てみます。

なお「皇国臣民」としていますが、日記に自身を直接そう称する箇所はありません。 日記を読んでしっくり来たため、犬鍋さんの記事から拝借したものです。

さて、日記だからといって完全に私的なものではなく、後代の目を意識している面があって当然です。 しかしこの日記では実に淡々と日々の出来事ばかりを記しており、読まれる事を想定しているとは考えにくい地味さです。 「～～で起き、朝食を食べた」「遊んだ」と、その中身に全く触れない場合がほとんどで、まるでタイムカードのよう。 何かを伝えようという意思は感じられません。 皆無とは言えないけれど虚栄も誹謗も極薄く、素直な自分用の記録だったのだろうと考えます。

一定の皇民化教育を受け、国外で慰安婦業を営み、ハングル漢字文で綴る。 朝鮮でそこそこの成功していながら、戦時下政策の煽りも遠因にあって落ちぶれ、南国に流れる。 全ての朝鮮出身の人民が同じであった筈はありませんが、ひとつの実例が見えると、やはり強いです。 できれば彼の日記全てだけでなく、同じような品質の他の日記が読んでみたいものです。

そんな彼の、皇国臣民としての意識。 実は日記全編に散りばめられてなどおらず、ほとんどは年末年始の節目にだけ集中しています。

2つの元日

昭和18年1月1日金曜日、晴天、19/21

大東亜聖戦、2度目の昭和18（1943）年の新春を迎え、1億の民草は伏してどうか陛下のご健康であられますことと皇室の末永きご繁栄をお祝い申し上げるところである。私は遠く故郷を離れ、ビルマのアキャブ市慰安所である勘八倶楽部で起きて東の方に宮城に向かって遙拜し、故郷の両親と兄弟、そして妻子のことを思い、幸せを祈った。東天の日差しも分かっているかのように、皇軍の武運長久と国家隆昌を祝福してくれる。どうか今年一年も無事に幸運の中で過ごせるように…。家内の弟と○桓君は慰安婦を連れて連隊本部その他3～4ヶ所に新年挨拶に行って来た。一線陣中で迎えた元日も暮れて夜になり、今年の幸運を夢見て、何日か眠れなく辛かったのだがつい深く寝た。

公開されている日記は昭和18年（1943年）の元日から始まっています。 特別な日だからこそですが、のっけから「大東亜聖戦」「1億の民草は伏して」と、皇国臣民としての自覚溢れる記述です。 元日という節目で想いを馳せるのは、皇国の行く末と、自身の未来。 そして東の宮城、つまり遠く東の皇居を拝む。 「皇軍の武運長久と国家隆昌」という表現からは、日本と併合された朝鮮が既に一体であり認識が感じられます。

しかし日記全体と比べると、皇国や天皇について触れる箇所では、やけに強く固い表現が目立ちます。 原文は漢文的な表現の混ざったハングル漢字混用文らしいので、日本語訳だけが著しく漢字表現を修正しているということはないでしょう。 日記ですらそういった表現を用いるというのは、それだけの畏れが反映されているのでしょうか。

この1年後、日本語仮訳版では2度目であり最後の元日は、更に仰々しい表現が目立ちます。

昭和19年 土曜日、晴天

晨暉、暁曇を破って、海上に日が昇り、ここに昭和19年の春を硝煙の下に迎えた。神武天皇の惟神の大道に遵い、万世不易の国基を定めてから正に2604年、1億民衆は俯伏して陛下の聖壽無窮と皇室の彌栄なることを奉祝するばかりだ。征戦ここに第3年、皇軍必勝の態勢は既に成り、大東亜10億民衆もまたわが国に協力して、共同目標の達成に忠実たり。速やかに姦凶を討滅し、その非望を粉砕し、アジアの解放、世界新秩序の建設を完成して、大訓の聖旨に副奉する。それにより皇威を四海に輝かせなければならない。昭和19年こそ、敵の死命を制圧する決戦の年だ。私は元日早朝7時頃に起きて洗顔をし、精神を整えた後、東天遠く宮城に向かって遥拝し、皇軍の武運長久を祈った。故郷の父母、兄弟、妻子の安在なることも祝願した。南方で年を越すのもこれですでに2回目である。今年こそ幸運に過ごせますように。そしてすべての仕事が計画通りに行くように。私は今年で40歳の半生を送った。歳月は過ぎ、人生は白髪ばかりを生やす。値千金の貴重な歳月を、有意義に過ごしていこう。大山君と菊水倶楽部の主人の西原君の招待を受け、新年の酒肴を満腹まで味わい、楽しく遊んでから、帰路、共栄劇場で映画を観てカトンの宿舎へ帰ってきて寝た。故郷の父母、兄弟、妻子とともに新年を迎えることができず、非常に悲しくて残念である。いつ、家族と一緒に、新年を迎えられるだろうか。

「万世不易の国基を定めてから正に2604年」と皇紀で始まり、力強い讃えの言葉が並びます。 続くのは聖戦を讃え誇り、武運を願う言葉。 正に皇国臣民の鑑のようで、これほどの表現でこのような思いを、元日の日記に綴る朝鮮出身者が市井にいたのは面白いです。 彼は慰安婦業を営んでいた以上、日記に関わらず、現在の韓国では間違いなく非難されるでしょう。 しかしもしも、もっと多くの朝鮮半島出身者が同じような思いだったとしたら、現代の韓国ではどう取り扱われるのでしょうか。 日帝絶対悪を掲げ、日本的なものの否定を育んでしまったことで、時代の連続性は断たれ、矛盾を孕んでしまったように見えます。 自己の一部を否定し続けなければならない、そういう道は、本当に気の毒にです。

さて、淡々とした日記において珍しく激しい記述は、何に根ざすものでしょうか。

日記ではこの前日、つまり昭和18年の大晦日に、その1年を振り返る記述があります。 そこでは日本側のプロパガンダベースとは言え、戦況を詳しく追いかけていたこと、苦戦も知りつつ、それでも日本の勝利を願う心が見えます。 前年は山本五十六が戦死し、アッツなどの玉砕、徴兵年齢引き下げなど、明らかに不穏な戦況が続いている。 皇国の民草なのだという自覚と、その皇国の未来への不安がせめぎ合い、感情が洩れてしまったのでしょう。 またその不安ゆえに、自身の行く末に対しても、より強い嘆きと鼓舞が見えます。

時代のゆらぎ

古い日記が公開されていないため大いに推測ですが、彼はその半生のどこかで、皇国臣民たる自身を自覚したはずです。 元日の強い文言は、臣民としての自覚なしに書けるものではないと思います。 一方で、繰り返される日常の中にはそのような言葉はほとんど無い。 そして後半には、戦況への言及は淡くなり、妻の死を嘆き神を恨む。 船中で迎えた1944年の大晦日には、皇国への言及はたったのひとこともない。

彼は確かに皇国臣民を自覚し、それに相応しい自分も意識していたのでしょうが、将来の不安がそれを揺らがせる程度の自覚でもあったのではないでしょうか。 彼の戦後は日記が公開されておらず、また1945～1950年という激変期の部分が見つかっていないので分かりません。 しかし意外とすんなり、韓国人になれたのではないかと思います。

1905年生まれなので、5歳前後で韓国併合。 独立運動を経て統治が緩やかになり、投資と旧い悪性の排除などで、発展していく故国。 思春期青年期をそういう激変とともに歩み、反発はありながらも日本であることを受け入れ始めていた朝鮮に生きる。 そして事業を興して成功し、挫折。 同時に日中戦争、太平洋戦争と、属す皇国は戦争という方法を選ぶ。 自らは南方へ落ちながら、その戦争が生み出す慰安婦業で糊口をしのぐ。 このままでは駄目なのだと無為の日々を悔み、しかし立ち上がれないでいる。

こういった彼の状況全てが積み重なって、元日には皇国を思い、惨めな自分を奮い立たせるも、荒れる戦況にそれどころでなくなっていく、そういう日々が生まれたのではないでしょうか。

次は、日記の中の遊興を見てみます。