Thursday, July 20, 2017

KMC 40th Anniversary Conference

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

Monday, July 11, 2016

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

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のコードになっていくと思います。

Thursday, March 17, 2016

Go 1.6 Release Party @ Tokyo

これももう一ヶ月前になりますが、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アプリケーション開発

既に発売されてもう2ヶ月近くたってしまいましたが、「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円とかのがある)になってますね。

Tuesday, December 2, 2014

Go Conference 2014 autumn

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の話あたりをするんじゃないかと思っていたんです。
1年の間にレビューした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」に ”名前を売り出すときに一番大事なことは、時期尚早かなと思うくらいでスタートすることだ。たいていの人は自分を売り込むときに消極的になる。君は教えるべきものを持っている。もう準備万端だと感じることは 決してない。この瞬間に始めてもいいくらいだ。"と書かれていたのを実践してみました。

Tuesday, November 25, 2014

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

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

Wednesday, December 4, 2013

Code Readability

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++は言語として自由度が高すぎるというか、これといったスタイル標準がないせいで、例えばChromiumWebKitではだいぶ印象が違って、別の言語というかんじもします。

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はださず、なおすべき点があればコンパイラがエラーをはきます。 他にもgovetgolintとかもあってよくある問題はコンピュータがみつけてくれます。 Go言語のReadabilityはidiomをちゃんと使っているかどうかという点になってきます。Go言語にも言語の罠はないとはいいませんが、言語仕様もシンプルなので、コードはだいたい見たとおりになっているのもcode reviewしやすいです。

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

Monday, July 15, 2013

FSIJ月例会: GnuPG

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をちゃんとやらないといけないんですが、ちゃんとやるのはたいへんですね。

Saturday, April 13, 2013

Go Conference 2013 Spring

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言語のプレゼンをするのには便利です。