ukai's blog

KMC 40th Anniversary Conference

2017-07-20T12:55:00.000+09:00

開催からだいぶたちますが、6月17日に京都にいってKMC 40th Anniversary Conferenceに参加してきました。
1977年に設立されて今年でちょうど４０周年ということで、conferenceを開いて盛大にお祝いです。私は昭和最後の部員で13代目になります。x68kとかCGAが流行っていた頃になります。 (cf: KMCの歴史） KMCでは大学院時代に386BSDとかLinuxをpc98に移植したりしたのが大プロジェクトでした。
40周年記念イベントでは、Linux/98のこととか、オープンソース活動のこととかキャリア歴とかを話してほしいということだったので、 386BSD(98), Linux/98から、Debianの活動とかhpからGoogleへの転職とかをざっと話しました。
KMC40周年を振り返って、当時の話とかいろいろおもしろかったです。いろんなプロジェクトの興亡や文化の継承があったんですねえ。最近もますます活発に活躍しているみたいでなによりです。
懇親会では、貴重な若木民喜先生の部内誌マンガとかも見ることができました。

『プログラミング言語Go』刊行記念イベント「Goの設計思想を読み解く～実際の開発に活かすために」

2016-07-11T17:34:00.000+09:00

7月6日にジュンク堂にて行われた『プログラミング言語Go』刊行記念イベント「Goの設計思想を読み解く～実際の開発に活かすために」でプログラミング言語Goの訳者である柴田さんと対談してきました。

トークセッションということで特にプレゼン資料的なものはないのですが、sliceの比較や、goroutine IDをあえて提供しないあたりにGoの設計思想であるSimplicity（簡潔性）が色濃くでているとかいう話をしました。実際の開発に活かすには、Goでは具象型(concrete type)でAPIをきちんと考えて設計して、必要なところでinterface型を提供するようにしたほうがいいということを説明しました。特にJavaとかを書いている人とかはまずinterfaceを定義しようとすることが多いのでそれはやめたほうがいいと思います。interface型を先に定義するのはpremature abstraction（早すぎる抽象化）に陥りやすいです。

Goでは言語がシンプルな分、プログラマがしっかり設計し、きちんとコードを書くことが求められます。例えばGoプログラマは複雑な型であってもゼロ値が有効な値になるように設計する努力する必要があります。また、エラー処理に関しても、Goではしっかり設計することが求められます。

できるだけシンプルな具象型をinterfaceを介してうまく組み上げていくことで、複雑な処理をするプログラムを開発していくかんじになります。最初はどう組み合わせばいいかわかりにくいですが、うまく組み合わせることができるようになってくると、読みやすいGoのコードになっていくと思います。

Go 1.6 Release Party @ Tokyo

2016-03-17T23:06:00.001+09:00

これももう一ヶ月前になりますが、2月17日にはてな東京オフィスでGo 1.6 Release Partyがあったので参加してきました。Go 1.6 release partyの東京イベント(by GoCon Tokyo)でした。

Go言語によるWebアプリケーション開発が発売されたあとくらいに「Goらしいコードの書き方とかでなにか発表を」と依頼されたのでGoらしいコードの書き方（ミニ）をしゃべりました。時間は15分くらいだったので内容を interfaceとchanの使い方にしぼりました。このあたりはGo言語がわかりはじめたころに使いすぎてしまう人が多い気がします。 Rob Pike氏がいっているように「Always use the right tool for the job」するよう気をつけましょう。

Go言語によるWebアプリケーション開発

2016-03-17T22:51:00.000+09:00

既に発売されてもう２ヶ月近くたってしまいましたが、「Go言語によるWebアプリケーション開発」の監訳をしました。 `Go Programming Blueprints`の日本語訳です。

タイトルに「Webアプリケーション開発」とありますが、Webアプリケーションだけではなくてコマンドラインツールの開発とかも紹介しています。
Go言語仕様とかの説明はあまりなくて、Goを使ってアプリケーションを書くのはこのようにするという例を紹介した本なので、 tour.golang.orgをしたり、How to write go codeあたりを読んだりしたあとに、手にとってみるといいかと思います。
最初見た時は題材の選択とかがよさそうに思ったのですが、監訳でちゃんと読んでみると原書の時点からコードとか説明で気になるところがたくさんあったので、注をいれたりだいぶ手直ししたりしました。付録もなにか書いてくださいということだったので何を書こうか最初迷ったのですが、Goらしいコード(idiomatic go)を説明したほうがよさそうな気がしたので本文中のコードをreadability reviewとしてみて書き直したらこういうふうにするなぁという感じで書きました。
ちなみに元のコードはgithub.com/matryer/goblueprints、日本語訳版はgithub.com/oreillly-japan/go-programming-blueprintsにあります。
最初は紙の本だけでしたが、Ebookもでているので電子版が欲しい人もどうぞ。
そういえばamazonでは発売当初在庫がすぐなくなって中古が高値で売られてましたが、在庫はもうあるのに中古がまだ高いとかいう不思議な状況(2016-03-17の時点で中古ほぼ新品6912円とかのがある)になってますね。

Go Conference 2014 autumn

2014-12-02T20:48:00.000+09:00

11月30日はGo Conference 2014 autumnに参加してきました。
@yamotongpooさんに11月はじめくらいに、「今度はRob Pike氏をよびますよ」と聞いてすごいと思っていたら、すぐあとくらいに@tenntennさんから、「キーノートを2本立てにして、片方を日本の方にということでキーノートおねがいします」という依頼がきて、Rob Pike氏と並んでキーノートなんかできるかなとややたじろぎましたが、こういうのは断るよりやっておいたほうがいい経験になるだろうと思って具体的な内容を考えるのは後回しにして引き受けました。*1
「日本にフォーカスした話や日本のユーザがこれからGoをやっていこう！となるような内容がよいかなと思います」とのことだったので、どんな内容にするかしばらく考えていたのですが、ふとblogを見直すとちょうど一年位前にGo Readability Approverになっていたので GoのReadabilityについて話すことにしました。Rob Pike氏はタイミング的にGo 1.4の話あたりをするんじゃないかと思っていたんです。
１年の間にレビューしたCLを見なおして、どういうコードにどういうコメントつけたのかを集めて整理しなおすだけで結構大変でした。実際多かったのは「need package comment (or doc comment)」「error string should not be capitalized」あたりです。
CL見直して集めるのもかなり時間がかかりましたが、プレゼンで紹介しやすい短めのコードでポイントを説明できそうなやつを選ぶのもまたかなり大変でした。その後、見なおしてみたら多すぎたので講演時間におさまるようにだいぶ削りました。実際のCLそのままはオープンソースでもないのでさすがによくなさそうだろうと思ったので、プレゼンで紹介したコードは実際のコードを元にした改変バージョンにしてあります。
タイトルは「Go Readability」にしていたのですが、当日朝会場に向かう途中にふと「郷に入っては郷に従え」がうかんできたのでした。クロージングのメッセージにしようかなと最初思いましたが、結局タイトルにすることにしました。
Rob Pike氏は予想とちがって「Simplicity is Complicated」でReadabilityとかが超大事みたいな話になっていたので、Go Readabilityの話ができたのはよかったと思います。

Goに入ってはGoに従え
-- Gopher by Renée French, and tenntenn

Goでは変数名が短くてすむ場合は短いほうがいいとされていて、これが他の言語から来た人の反発を招きやすいようですね。でも数学で数式とか変数名はほとんど一文字なわけで、コンテキストがちゃんとわかっているのなら短くてもわかりやすいです。むしろ長いと読みにくくなりそう。

-coefficentOfLinearTeam ± sqrt(coefficientOfLinearTerm*coefficientOfLinearTerm - 4*coefficientOfSquareTerm*constantTerm) / (2*coefficientOfSquareTerm)

とか。

今回のGoConの発表はGoをproductionに使ってみた系の話が多くてだいぶ普及してきたなぁと感じました。

懇親会では@jxck_さんのコードをレビューしてたんですが、Rob Pike先生から、よりエレガントなコードの手ほどきをしてもらっていました。いいコードを書くにはまだまだ修行が必要です。

後日、officeでRob Pike氏に「よいプレゼンだったから英語にも訳してよ」とリクエストされたので英語版: When in Go, do as Gophers doも作りました。 Rob Pike氏に英語のreviewもしてもらってあります。

We talk about readability all the time, but this is the first public talk I've seen explicitly on the topic and it explains things well. The examples are really good.

とのお言葉をいただきました!

*1 情熱プログラマにも「39: 業界で名前を売ろう Let Your Voice Be Heard」に ”名前を売り出すときに一番大事なことは、時期尚早かなと思うくらいでスタートすることだ。たいていの人は自分を売り込むときに消極的になる。君は教えるべきものを持っている。もう準備万端だと感じることは決してない。この瞬間に始めてもいいくらいだ。"と書かれていたのを実践してみました。

角川インターネット講座 (2) ネットを支えるオープンソースソフトウェアの進化

2014-11-25T23:04:00.000+09:00

角川インターネット講座 (2) ネットを支えるオープンソースソフトウェアの進化に「企業とオープンソース」を寄稿しました。
企業(Hewlett-Packard Labs, Google)の研究者/Software Engineerでありつつ、free software/open source software関係でいろいろやっていた経験からみた"オープンソースソフトウエア"の進化について解説してみました。開発者じゃない人や経営者から見た"オープンソース"とは違うところも多いかと思います。
寄稿して振り返ってみると、最近はgithubなどでカジュアルにソースコードをやりとりするようになり、 Free Software Foundationの提唱するfree softwareも一時期にくらべるとだいぶ下火になってきてるような気がします。ことさらに"free"を主張しなくても自由にプログラミングできるようになってきているのならいいのですが、プログラマじゃない層を守るという観点で自由を許さない環境もなくならならないようです。新しいことを試してみたい人の自由を確保するのと、リテラシーが十分じゃない人の安全を確保するのとのせめぎあいが続いていくのでしょうか。
"自由を守らないといけない”を主張する人の影響力が減ってきてないかなぁと気になっています。

Code Readability

2013-12-04T22:57:00.000+09:00

Go 1.2が12月1日にリリースされました。そして、同時くらいに社内のGo readability approverの一員になったので、ちょっとCode Readabilityについて書いてみようと思います。

Google社内では、主要なプログラミング言語について Readability というのが存在します。「C++のReadabilityを持っている」とは、C++のコードをスタイルガイドに従ったコードを読み書きできる能力があることを意味しています。社内のコードベースと一貫したコードで開発できるということです。Readabilityをもっていない人は、Readabilityを持っている人にcode reviewしてLGTM/Approvalを貰わないとコードをrepositoryにcommit/submitすることができません。

readability approverは、ある開発者がその言語のReadabilityを持っているかどうかを判定する/ある開発者がその言語のReadabilityを持つよう教育する役です。

スタイルガイドは言語ごとに、それぞれの言語の特性にあうように決められています。これらのスタイルは、言語のベストプラクティスや、誤りがちなコーディングを避ける方法を示しています。最初は「ルールがたくさんあって、そんなのいちいち気にしてコードなんか書けない」と思うかもしれませんが、慣れてくるとスタイルガイドにしたがっていないコードに違和感を感じるようになってきます。そしてそういうところにバグが潜んでいることが多いような気がします。

個人的な印象としては…

C++の場合は、かなりGoogle独特のルールがあります。が、code reviewする時に、このスタイルガイドに沿ったコードになっていれば、reviewする範囲をchangeで変更した周辺を見ればすむことがすむ場合がけっこうあるようなかんじです。とはいっても言語の罠が結構あるので、ちゃんとreviewするのはなかなかしんどいです。ツールとしては cpplintがありますし、最近は clang-formatなども使われだしてきているようですね。 C++は言語として自由度が高すぎるというか、これといったスタイル標準がないせいで、例えばChromiumとWebKitではだいぶ印象が違って、別の言語というかんじもします。

Pythonの場合は、基本的にはPython標準と似たかんじだったと思います。ツールとしてはpylintがあります。 Pythonとかはdocstringをきちんと書いておかないとコードが増えてきたときに厳しいですね。しかもそれはしょせんコメントなので、実際のコードと一致してなかったりするとバグの温床になってしまいます。 code reviewする時も、コードの断片からコードが正しいかどうか見分けるのは困難です。文字列にしてもstrかunicodeなのか気をつけてないと、"Failure: 'ascii' codec can't encode character u'\xNN' in position N: ordinal not in range(128)."みたいなエラーがカジュアルにでてしまうし。Pythonはコードを書きやすいのかもしれないけど、正しくないコードも簡単に書けてしまう/コードが正しいか間違っているか判断するのが難しいという印象です。ちゃんとやるにはテストも大量に書いておかないとだんだん不安になる言語です。

Go言語の場合、基本的なスタイルはgofmtでそろえてくれます。コンパイラもwarningはださず、なおすべき点があればコンパイラがエラーをはきます。他にもgovetやgolintとかもあってよくある問題はコンピュータがみつけてくれます。 Go言語のReadabilityはidiomをちゃんと使っているかどうかという点になってきます。Go言語にも言語の罠はないとはいいませんが、言語仕様もシンプルなので、コードはだいたい見たとおりになっているのもcode reviewしやすいです。

というかんじで、最近は「非常に短いほぼ使い捨てなスクリプト」ならshellとかPythonで書くこともありますが、main以外の関数とかclassが欲しくなってきたら、もうGo言語で書いたほうがいいと思いますね。簡単なものならgo run hoge.goでそのまま実行できますし。また既にある程度書かれているperformance criticalなC++プログラムとかは、そのままC++で変更・追加していっていますが、一から開発するんならGo言語で書くほうが楽しいですよ。

FSIJ月例会: GnuPG

2013-07-15T16:58:00.001+09:00

FSIJ理事会、総会の後、FSIJ月例会に参加してきました。 gniibeさんによるGnuPGの"信頼"についての話でした。

そもそもは、大統一Debian勉強会: PGP/GPGキーサインパーティの説明が話を盛りすぎではないかということでした。そこではこのように書かれています

フリーソフトウェアの世界では、ネット上で自分の存在を保証してもらうために、PGP/GPG を使ったWeb of Trust を構築しています。フリーソフトウェアの開発に参加している方、参加を考えている方はこれを機会に参加してみてはいかがでしょうか。
また、開発者以外の方にとっても、ソフトウェアの配布アーカイブに PGP/GPG 署名やハッシュが添付されていることもあり、ソフトウェアの入手時の正当性確認の意味でも重要です。
Debian、Ubuntu、CentOSなどでは、パッケージリポジトリの正当性を確認するために、 PGP/GPG を使ったシステムが採用されています。この信頼性は Web of Trust に基づいているため、Web of Trust の中で各ディストリビューションのリポジトリ管理者とつながることが重要です。

これを読むと「PGP/GPGのWeb of Trustに基づいてパッケージリポジトリの正当性を確認している」ように読めますよね。そしてその「Web of Trustを強くするためにキーサインしましょう」という呼びかけになっています。

しかし、実際のところPGP/GPGのWeb of Trustに基づいておこなわれる操作はほとんどないのではないかという話です。

Debianの場合は次のようになっているはずです。

まず、apt-getでパッケージを取得する時にGPGの署名の確認をおこなっています。これは/etc/apt/trusted.gpgの鍵でReleaseファイルが署名されているかどうかを確認しています。基本的に/etc/apt/trusted.gpgの鍵が信頼できるものとしています。この鍵への署名はあまり重要ではありません。かなり気にしている人ならばこの鍵が自分の知っている人が署名しているか、もしくはディストリビューションの開発者が署名しているかというのを気にするかもしれません。その場合は/etc/apt/trusted.gpgから鍵をはずすなどの作業をする必要があるでしょう(自分のkeyringからのチェーンをaptがみてくれたりはしない)

その前にリポジトリにいれる時に、開発者は*.changes,*.dscに署名してアップロードします。アップロードされたほうがそれらのファイルがdebian-keyringの中にある鍵で署名されているかどうかを確認しています。debian-keyringにはDebianの開発者の鍵しか入っていません。ここでもその鍵に署名があるかどうかは関係ありません。

鍵への署名が重要なのは、debian-keyringにいれてもらう時(Debian開発者になる時)です。この時、Debian開発者候補者は、既存のDebian開発者から署名してもらったGPG鍵をもっている必要があります。そのGPG鍵が確かにその人の使っている鍵であるということを保証するためです。この署名をもらうためにキーサインパーティは、多数の開発者と出会えるよい機会であるといえます。なお、debian-keyringにいれてもらうには、ほかにもいろいろと条件があります(キーサインは身分証明のステップです)。

そのほかにキーサインが重要なのは、その人と直接のやりとりがある場合でしょう。 gitではcommitやtagに署名する機能があるので、gitでpush/pullする時に相手を検証するのに使ったりもします。

いいかたをかえると、リポジトリの信頼性という意味ではキーサインパーティはあまり意味がありません。/etc/apt/trusted.gpgを信頼するか、debian-keyringを信頼するかにかかっています。この場合信頼するかどうかは署名するかどうかはあまり関係ありません。署名しなくても/etc/apt/trusted.gpgは信頼することになっているからです。

GPGでWeb of trustをやるには、キーサインだけじゃなくてtrust dbをちゃんとやらないといけないんですが、ちゃんとやるのはたいへんですね。

BloggerでGoogle+のコメント

2013-04-19T22:13:00.001+09:00

Blogger で Google+ のコメントが見られるようになりましたということなので、さっそく有効にしてみた。

Go Conference 2013 Spring

2013-04-13T23:17:00.000+09:00

Go Conference 2013 Springに参加してきました。

ハンズオンの時間は、放置していたcode.google.com/p/go.net/websocketをいじってました。

プレゼンは「「なぜGoなのか」というところを話してほしい」ということだったので、言語機能の説明よりもどのあたりがいいかを説明してみることにしました。

「最初はキモッって思うかもしれないけど、そのうちかわいく見えてきますよ」というかんじが伝えられたでしょうか。なんでGoをつかうとうれしいかは、大規模なチームの中で大規模なコードをいじらないとなかなかピンとこないかもしれません。

印象としてはこんなかんじかなー

C: 知っている技術者は多い。OOをやるにはめんどい(glibみたいになっていく?)。大規模になってくるとclassとかnamespaceとかないとつらいかんじ
C++: 知っている技術者はそこそこ多い。大規模なプロダクトができる(googleのサーバーとかChromeとか)がビルド時間がとてつもなく長くなっていって開発するのがつらい。C++11以前だと(autoとかないと)書くのもめんどいときが多い。
Java: 知っている技術者はそこそこ多い。(IDEとかの助けがないと)書くのがめんどい。大規模になってくるとIDEではつらい。JavaにかぎらずJVMベースの言語はJVMのチューニングとかがたいへんぽい。
Python: 知っている技術者はそこそこ多い。ちょっとしたプログラムだと簡単。規模がおおきくなってくると詳細をつかむのがむずかしくなってくる(この変数はどういう値(どのclassのobject)になりうるのか? 別のclassのobjectをわたしてもいいのか? とか)。そのうち滅多に通らないコードパスでruntimeエラーで死んで悲しくなる。(つまらないtypoとかだとさらに悲しい)
Ruby: Pythonと似たかんじ。Domain Specific Languageにされてしまったりもするが、そうなるとその方言もしらないと読むのもつらい
JavaScript: 表層をしっている技術者は多いが、ディープなところになるとむずかしすぎし、そういうところで問題がおきると調べるのがむずかしい。大規模になるとClosure Compilerとかの annotationしておかないとつらくなってくる。
ErlangとかHaskellとか: Cプログラマにとっては学習コストがたかそう。

Goだとimplicitなことが少ないのでコードを読む負担がすくないのがいいと思います。型が省略されてるのもその式の型を把握するのは難しくないですし(深い推論とかしてないので)。より詳しくはRob Pike先生のGo at Google: Language Design in the Service of Software Engineering (slides)を読むとよいかと思います。 talks.golang.orgには他にもgo teamのプレゼンがいろいろ置いてあるので見てみることをおすすめします。

発表の資料はhttp://ukai-go-talks.appspot.com/2013/gocon.slide#1に置いてみました。せっかくなのでhttps://code.google.com/p/go.talksをつかってみました。これsyntaxがこんなかんじで、昔のMagicPointを思いだしたりしました…。表現力とかはたいしたことないですが、local版だとplay.golang.orgみたいにcodeの実行ができるので、Go言語のプレゼンをするのには便利です。

マイナビセミナー

2011-11-19T16:02:00.000+09:00

今日は秋葉原UDXのマイナビのイベントで、「ソフトウェアエンジニアに求められること」という題で講演してきました。
変化の速いこの業界、リスクをとらずに現状を維持しようとするのが一番のリスクになっているとかそういう話をしました。参考文献にした情熱プログラマがあまっていたので質問してくれた人達にあげました。

マイナビインタビュー

2011-11-10T23:00:00.000+09:00

11月19日の講演にむけて、1時間ほどインタビューをうけた記事がでました。
Chrome開発者が語る、幸せなエンジニアになるための条件

Google Developer Day 2011 Japan

2011-11-01T23:00:00.000+09:00

今日はGoogle Developer Day 2011 Japan。今年は横浜パシフィコ。
Google Developer Dayも今年で5年目。なんだかんだとフル出場できています。今年ははじめて自分のメインのプロジェクトの話。1年ちょっと前からやっているクラウドコンパイラの話です。社外のDeveloperの皆さんにつかってもらえるようにはまだなっていないのですが、東京発のプロジェクト紹介のひとつとして紹介してみました。

2011-11-GoogleDeveloperDay

当日のプレゼン資料とビデオも公開されています。

G-Cloud Magazine 2011 Autumn

2011-10-04T16:12:00.000+09:00

G-Cloud Magazine 2011 Autumnに、7月頃インタビューされた記事がのっています。
内容はGoogle App EngineのGo言語について。Go言語のどのへんがいいのかとか、なぜGAEでGo言語なのかとかの話になっています。

Chromium/WebKitの開発・内部アーキテクチャについて

2011-06-13T22:47:00.005+09:00

今日は東京大学にて、「Chromium/WebKitの開発・内部アーキテクチャについて」というタイトルでTech Talkをしてきました。

Chromium Design DocsやTech Talksなどを中心に開発者むけ情報からどういう風に開発がすすめれているのかということを説明しました。

創造情報学連携講義VII - 大規模分散処理システム

2011-06-09T22:40:00.004+09:00

東京大学の工藤客員准教授の創造情報学連携講義VIIの第3回の講義をしてきました。
内容は、大規模な分散処理の特徴およびGFS, Chubby, MapReduce, BigTableなどの具体的なシステムでのやり方などについて説明しました。

Go言語 mini tech talk in API Expert meeting

2011-05-25T22:37:00.001+09:00

API Expertミーティングで Go言語のmini tech talkをしました。
内容は Google I/OでGo言語について紹介されていた内容の簡単なまとめになっています。

文字列操作の比較表: RubyとGo言語

2011-02-26T00:37:00.002+09:00

ふとtwitterをみていたら

@ymotongpoo pythonjapan.comとかいうサイトがすごく下品なことをしてる。「文字列操作の比較表」 http://bit.ly/ggAJ0k これは高林さんの記事の丸コピペな上に引用元書いてない。恥を知れ。 http://bit.ly/g9U5M
http://twitter.com/ymotongpoo/status/40615506608128000

というのが目にはいった時に社内buzzに流したらpythonjapanうんぬんよりも言語比較の話がまた再燃。s.to_fはperlでは0+$sだとか、s.to_sは”$s"とか。
そういえばGo言語も比較したらどうなるかせっかくなのでまとめてみた。
問題のpythonjapanはあっという間に消えたようですね。謎のpythonjapan

blog デザインをかえた

2011-02-25T01:07:00.001+09:00

妻が Google Analyticsの勉強をはじめるためにここに埋め込んでみたので、ついでにデザインも新しくしてみた。broken linkになってたのとかもなおしたつもり。
ぼちぼちと去年の分も補完していこうと思う。

Nexus S

2011-01-07T23:55:00.012+09:00

Nexus Sをもらった。
Xperia にくらべるとやや小さめ。Android OSが最新で、テザリングとかができるのがすばらしい。
DoCoMoだとタイプSSバリューにパケホーダイダブルかな。Nexus Sだとスマートフォン定額にはできなくて上限10,395円（税抜9,900円）のやつになるっぽい。
社内buzzで、Angry Birdsがお薦めされていたのでいれてみた。これははまる。

Go言語 Tech Talk

2010-11-29T23:31:00.003+09:00

SydneyオフィスからGo言語のDeveloper Advocate Andrew Gerrandが来日して、 Go言語 Tech Talkをしてくれた。
内容はURL shortenerを作るというもので、簡単なサーバから、複数レプリカして動かすバージョンを作るところまでで、なかなか興味深い内容だった。スライドが公開されています。
通訳がつかなかったので、区切りで簡単なまとめを日本語で説明するのと、質疑応答の翻訳の手助けなどをしました。
togetterされたようですね。

大規模データ処理特論: Google Goの概要

2010-10-27T23:19:00.002+09:00

今日は東工大の大規模データ処理特論の講義のひとつとして「Google Goの概要」というタイトルでしゃべってきた。
基本的にはPPLサマースクール2010の時と同じような内容。なんかあんまり大規模データ処理とは関係が薄いような気が…
Go言語は大規模なプログラミングを書く時にあまり困らないようにするというのが設計のポイントのひとつとなっているそうだけど、そういうところを中心にしたほうがよかったのかもなー。

Google Developer Day 2010 Japan

2010-09-28T23:51:00.001+09:00

今日はGoogle Developer Day 2010 Japan。今年は有楽町の東京国際フォーラム。
今年は、DevFestに続いて「プログラミング言語 Go」。内容は今度は簡単な電卓プログラムをGoで作ってみながらパッケージの仕方などまでの説明をする感じで。しかし電卓は題材としてはそれほどよいわけではなかったのかも。

当日のプレゼン資料とビデオも公開されています。

PPLサマースクール2010: マルチコア時代の新言語

2010-09-12T11:52:00.005+09:00

今日は津田塾大学小平キャンパスにいってPPLサマースクール2010 : マルチコア時代の新言語でしゃべってきた。
自分のセッションの時に来ていればいいという話だったので昼頃に到着して午前のFortressの話は聞かず‥
話は「プログラミング言語Go」で、Goの設計思想や文法、メモリレイアウトやgoroutine,channelの話など。マルチコア時代の新言語といいつつ、マルチコアなあたりはGoではgoroutineとchannelによるCommunicating Sequential Processesなプログラムが書きやすくなっているので、並行処理のわかりやすい構造のプログラムが書きやすくなっているので、マルチコアを有効に使うことができるというあたりかと。
その後、x10の話を聞いた。聞きながら思ったのは、x10と比べるとGoは言語としてサポートする範囲はだいぶコンパクトなので言語仕様も非常に簡単になっているんだなあということ。x10とかでサポートしている分散処理環境なんかは、Goでは(Googleという環境では) MapReduceとかそういうのでやることであって、Go言語自体ではそこまではやらない(そういうフレームワークが書きやすい/使いやすい言語にしようとしている)ように思った。むしろ、そういう話をいれたほうがよかったのかな。

WebSocket BOF

2010-08-31T11:48:00.001+09:00

WebSocket BOFがGoogleオフィスで開催されていたので参加してきた。
みなさんWebSocketをつかっていろいろおもしろいことをしているみたい。早く多くのブラウザで使えるようになるといいのになあ。
しかし、ちょうどwhatwgからhybiに議論がうつりはじめてprotocol仕様の変更がはじまっている頃。その時はすぐに新しいのに落ちつくだろうと思っていたが…
BOFではtipsとして、WebSocketのデバッグする時は chrome://net-internals/ あたりを見ると便利ですよという話をした。ちょっと前に、WebSocket trafficも chrome://net-internals/#events などで見られるようにしたのでした。WebSocket messageの中身は見えないけど handshakeとかは確認できるようになっています。