memoメモ

最近はGo言語関連で。φ(..)メモメモ

gotypeコマンドでgolangのastの結果を視覚化する

golang

qiitaより転載

GolangのASTを可視化するツールを作った でastのステキな可視化がされていて出番は少ないかもしれませんが、gotypeコマンドでもastの結果を可視化できます。

これは何?

Go言語のソースコードを解析する際の補助的なツールです。 astパッケージを使う際のデバッグなどに役に立つと思います。

インストール

導入は:

$ go get code.google.com/p/go.tools/cmd/gotype

でok。

簡単な使い方:

例えば:

package main

import (
    "fmt"
)

func main() {
    fmt.Println("Hello, 世界")
}

を入れてみると以下のようになります:

$ gotype -ast main.go
     0  *ast.File {
     1  .  Package: main.go:1:1
     2  .  Name: *ast.Ident {
     3  .  .  NamePos: main.go:1:9
     4  .  .  Name: "main"
     5  .  }
     6  .  Decls: []ast.Decl (len = 2) {
     7  .  .  0: *ast.GenDecl {
     8  .  .  .  TokPos: main.go:3:1
     9  .  .  .  Tok: import
    10  .  .  .  Lparen: main.go:3:8
    11  .  .  .  Specs: []ast.Spec (len = 1) {
    12  .  .  .  .  0: *ast.ImportSpec {
    13  .  .  .  .  .  Path: *ast.BasicLit {
    14  .  .  .  .  .  .  ValuePos: main.go:4:2
    15  .  .  .  .  .  .  Kind: STRING
    16  .  .  .  .  .  .  Value: "\"fmt\""
    17  .  .  .  .  .  }
    18  .  .  .  .  .  EndPos: -
    19  .  .  .  .  }
    20  .  .  .  }
    21  .  .  .  Rparen: main.go:5:1
    22  .  .  }
    23  .  .  1: *ast.FuncDecl {
    24  .  .  .  Name: *ast.Ident {
    25  .  .  .  .  NamePos: main.go:7:6
    26  .  .  .  .  Name: "main"
    27  .  .  .  .  Obj: *ast.Object {
    28  .  .  .  .  .  Kind: func
    29  .  .  .  .  .  Name: "main"
    30  .  .  .  .  .  Decl: *(obj @ 23)
    31  .  .  .  .  }
    32  .  .  .  }
    33  .  .  .  Type: *ast.FuncType {
    34  .  .  .  .  Func: main.go:7:1
    35  .  .  .  .  Params: *ast.FieldList {
    36  .  .  .  .  .  Opening: main.go:7:10
    37  .  .  .  .  .  Closing: main.go:7:11
    38  .  .  .  .  }
    39  .  .  .  }
    40  .  .  .  Body: *ast.BlockStmt {
    41  .  .  .  .  Lbrace: main.go:7:13
    42  .  .  .  .  List: []ast.Stmt (len = 1) {
    43  .  .  .  .  .  0: *ast.ExprStmt {
    44  .  .  .  .  .  .  X: *ast.CallExpr {
    45  .  .  .  .  .  .  .  Fun: *ast.SelectorExpr {
    46  .  .  .  .  .  .  .  .  X: *ast.Ident {
    47  .  .  .  .  .  .  .  .  .  NamePos: main.go:8:2
    48  .  .  .  .  .  .  .  .  .  Name: "fmt"
    49  .  .  .  .  .  .  .  .  }
    50  .  .  .  .  .  .  .  .  Sel: *ast.Ident {
    51  .  .  .  .  .  .  .  .  .  NamePos: main.go:8:6
    52  .  .  .  .  .  .  .  .  .  Name: "Println"
    53  .  .  .  .  .  .  .  .  }
    54  .  .  .  .  .  .  .  }
    55  .  .  .  .  .  .  .  Lparen: main.go:8:13
    56  .  .  .  .  .  .  .  Args: []ast.Expr (len = 1) {
    57  .  .  .  .  .  .  .  .  0: *ast.BasicLit {
    58  .  .  .  .  .  .  .  .  .  ValuePos: main.go:8:14
    59  .  .  .  .  .  .  .  .  .  Kind: STRING
    60  .  .  .  .  .  .  .  .  .  Value: "\"Hello, 世界\""
    61  .  .  .  .  .  .  .  .  }
    62  .  .  .  .  .  .  .  }
    63  .  .  .  .  .  .  .  Ellipsis: -
    64  .  .  .  .  .  .  .  Rparen: main.go:8:29
    65  .  .  .  .  .  .  }
    66  .  .  .  .  .  }
    67  .  .  .  .  }
    68  .  .  .  .  Rbrace: main.go:9:1
    69  .  .  .  }
    70  .  .  }
    71  .  }
    72  .  Scope: *ast.Scope {
    73  .  .  Objects: map[string]*ast.Object (len = 1) {
    74  .  .  .  "main": *(obj @ 27)
    75  .  .  }
    76  .  }
    77  .  Imports: []*ast.ImportSpec (len = 1) {
    78  .  .  0: *(obj @ 12)
    79  .  }
    80  .  Unresolved: []*ast.Ident (len = 1) {
    81  .  .  0: *(obj @ 46)
    82  .  }
    83  }

-commentを合わせて入れればコメント行も解析します。

godocはこちら gotype

Book「APIデザインの極意」

Java Book

APIデザインの極意 を、この本の訳者の @yoshiki_shibata さんがレビューを募集していたので応募してみました。

手にとって中身をパラパラとみてみると、文字がぎっしり。本はEffective Javaより多少分厚いくらいですが、中の情報量がもの凄いです。このレビューを出すのが遅くなってしまった理由でもあります。

中には、APIをデザインする上で、何を考え、どうしておくべきか、どうしてこうするべきか、するとどうなるのか、なにに失敗したのかがしっかりと書かれています。コードはそれほど多くありません（最後は除く）が、Javaの知識があると背景をつかみやすいと思います。説明はNetBeansの開発経験などを元にした内容で書かれていますが、他に適用できる話が多いです。全てを読むには根気が要ると思いますので、何人か集めて読書会をするのもいいと思います。

簡単に中を紹介すると、第2部では、Effective Javaに続くような話があり、Effective Javaを読んだ方は是非読んでおくことをおすすめします。 第3部では、はじめの13章で軽く息抜きをしてから、APIを公開、維持する際の話がメインになります。APIは公開以前と公開以降では全く異なる性質を持つようになります。

以下、気になった所のメモを少し：

  • 無知な利用が成功するためには、 APIがライブラリの本質的な真意をきちんと反映していることが重要。2章より。
  • APIは自己文書化されている必要があり、つまりドキュメントが無くても使えるようにしておく必要がある。2章より。
  • APIは公開するものが少ないほどよい。ユースケースに確信が持てないときは公開しない。5章より。
  • 単一のAPIで構成されるライブラリはほとんどない。APIが対象としている複数の目的と複数のグループが存在する。ユーザの必要性に合わせてAPIを構成すべし。8章より。
  • テスト容易性を考えずにフレームワークを作成することは、開発者を不快にさせる。9章より。
  • API設計に問題がなく期待通りうまく運用されていれば「何も」起きない。「何もない」ことが大きな成功であることを示すことは難しい。14章より。

昨今APIをめぐるこんなトラブルもあり、今後のAPI設計の方向性が心配ですが、良いインターフェースの定義は広く使われるようになって欲しいですね。日本語で読めるようになったこの本でAPI設計に関する先人の知恵を読んでおくことをおすすめします！

APIデザインの極意 Java/NetBeansアーキテクト探究ノート

APIデザインの極意 Java/NetBeansアーキテクト探究ノート

EFFECTIVE JAVA 第2版 (The Java Series)

EFFECTIVE JAVA 第2版 (The Java Series)

Apple's SSL/TLS bugの件 #golang

golang

Apple's SSL/TLS bugの件で。

golangだとそもそも括弧強要されるし、gofmtでインデントが強制されるのでわりとすぐに気づくのかもと思ったのでメモ。

そもそもエラーになる：

package main

import "fmt"

func main() {
    var err error = nil
    if err != nil 
        goto fail
        goto fail
 
    fmt.Println("Hello, playground")
fail:
    fmt.Println("Hello, fail")
}

http://play.golang.org/p/lcgZDh-ji4

修正＆gofmtでこうなる：

package main

import "fmt"

func main() {
    var err error = nil
    if err != nil {
        goto fail
    }
    goto fail

    fmt.Println("Hello, playground")
fail:
    fmt.Println("Hello, fail")
}

http://play.golang.org/p/hinPttq13L

気づくかな。

goto文をつかうこと自体は悪く無いと思う。

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

CODE COMPLETE 第2版 上

CODE COMPLETE 第2版 上

CODE COMPLETE 第2版 下

CODE COMPLETE 第2版 下

デブサミ2014へ行ってきた #devsumi

event

devsumi 2014

デブサミ2014を見てきたのでメモ。 公式のまとめはこちら： デブサミ2014 講演関連資料まとめ

【13-A-1】クラウドがもたらした多様な破壊と創造（新野淳一/玉川憲/佐俣奈緒子/仲暁子/長谷川秀樹/三村真宗/吉田浩一郎/大石良）

クラウド:

  • すぐ、リソース無限、安い、どこでも、自由。
  • 個人の成長の場になってる（サーバ、ネットワーク、仮想化、ストレージ、CI、Agile、コミュニティ、勉強会、etc） 会社内だけで最新の知識を得るのはムズカシイ

流行りの言葉:

印象に残ったモノ:

  • Amazon: 「10年経っても変わらないもののほうが大事」
  • 東急ハンズ: おもろないITを壊す。全員エンジニアにして手を動かす
  • Coiney: 既存のクレジットのしくみを根本から変える

感想:

10年後も大衆の身の回りにあるもの・ことはなんだろう。

Coineyの市場の調査が徹底的になされていて素直に感心してしまった（当たり前なのだろうけど。）。

【13-A-5】成功と失敗の狭間に横たわる2つのマネジメント（中村洋〔DevLOVE関西〕）

slide: http://www.slideshare.net/YohNakamura/developerssummit2014yohhatu

2つのマネジメント:

  • 期待マネジメント

    • 話しあう
    • 相手に期待していることは？
    • 相手から期待されていることは？
    • お互いの期待を表明して擦り合わせる

  • モチベーションマネジメント

    • モチベーション:乱高下がある
    • 自分で管理する
    • 調子を上げるスイッチはなにか
    • 共感できてるか
    • サーバントリーダーシップ
    • 成功体験を増やす

【13-D-6】快適さはWebサービスの生命線！Webアプリのパフォーマンスを最高にするために心がけること（新村信〔アカマイ・テクノロジーズ〕）

  • akamaiでインターネットトラフィックの15〜30％を仕切っている
  • 2013のトラフィックの最大瞬間風速は21.6Tbps
  • コンテンツの転送に時間がかかるとユーザをロストする
  • Twitter Bootstrapなどにみるレスポンシブ・ウェブデザインでは、必要以上のコンテンツをクライアントへ送信している
  • 各サーバのコンテンツは細々としたチューニングをしていない（する余裕が無い）
  • コンテンツの転送をアカマイサーバで高速化するしくみ:
    • HTMLを先読みし、コンテンツを先にキャッシュしてクライアントへ送りつける
    • 架空のサイトをつくり、クライアントにそこのコンテンツを取りに行かせる（クライアントの同時コネクション数を増やすため）
    • 動的に画像の品質を変更する
  • 都内、日本国内で使うネットワークはそんなに遅くない

感想:

高速化のしくみは自分が予想していたより派手なやり方をしていて、これって開発している時に予期せぬ動きをしてハマってしまうのではないかと思ってしまった。自分の知識が足りないからそう思うだけで、おそらくそんなことはないのだろう。

【14-A-1】Webの現在過去未来（竹迫良範〔サイボウズ・ラボ〕/和田裕介/宮川達彦）

  • IDのネームスペースの問題
    • 同じアカウントを他のサービスでも利用したい
  • e-mailの失効問題
    • e-mail以外での本人確認手段が必要
  • OpenID
    • プロトコルはしっかり残っていて、知らず知らずのうちにバックグラウンドで使われていることが多い
  • Oauth
    • IdentificationとAuthorize
  • MobileWeb
    • Webからネイティブへの流れ
    • はじめはネイティブ（iOSなど）の開発者が少なかったからWebだった
    • 今はネイティブのメリットを活かせる
    • ユーザもネイティブアプリの方を使うみたい
    • Webだからできないということもない
  • Amazon、iOS
    • ユーザがお金を払うしくみ、土壌がある
  • 電子書籍
    • Amazonで独自出版できる
    • 電子書籍を出版する場合、どう宣伝するか、が問題
    • githubなどを活用して書籍開発
    • git pushでamazonの電子書籍の更新ができるとカッコイイ
  • メールマガジン
    • メールにお金を払うのは日本独特
    • メールはユニバーサルに使える
    • 多くの人が使える
    • 夜間飛行にみるあたらしいメールマガジンもでている
  • Podcast
    • iTunesの中では一番審査レベルが低い
    • 音源を配信するサーバを自分で用意しておけばよくて、RSSに音源のリンクがついたようなもの。
    • PodcastはOpenWebの形になっている
  • その他
    • AWSの稼働率は高いが、万が一ダウンしてしまっても何もできない（それがいいということ話もある）
    • 今のWebは、それぞれ個別にカスタマイズされたWebの世界を見ている（今後、GoogleGlassなどで実世界もそうなってくると気持ち悪さがある）
    • 乗り換えられる緩やかなプラットフォーム

感想:

インターネット上のID（アカウント）はIDなのにIDじゃないっていうのはずっと気になっているけど、なかなかむずかしい問題。 モバイルについては、1、2年前まではHTML5の登場でネイティブよりWebアプリだって言われていたような気がするが、ここでの話はネイティブアプリが有利だよという話で、今となってはなるほどそうかという感じだった。

電子書籍は、せっかくデータで提供できるのに更新しにくいとかそういう話があって残念な感じがしてた。話の中にでてきたgithubから出版までのパイプラインがしっかりできれば個人出版も生きやすくなりそう。

Rebuild.fm Podcastの中の人、宮川さん(@miyagawa)を生で見ることができたので満足です。

【14-C-4】DeNAにおけるゲーム以外の新規事業の立ち上げ方（沖津貴智〔ディー・エヌ・エー〕）

slide: https://speakerdeck.com/okitsutakatomo/debusami2014-14-c-4-denaniokerugemuyi-wai-falsexin-gui-shi-ye-falseli-tishang-gefang

  • Scrum
    • はじめは忠実に（アナログで）
    • 各自が考えて行動できるように
    • 開発に対して庶務的なサポータがいる
    • 短い単位（日）でのプランニング、振り返り
  • リーン
    • 検証
    • 使う機能、使わない機能の判断
  • 全員が各リポジトリを共有している
  • 非エンジニアでもgithub＆PullRequest
  • 対象機種のカバー率よりスピード感

感想:

非エンジニア（デザイナ）もプルリクできるのはすてき。

【14-C-5】モーションセンサーの現状と2014年の予測（中村薫〔Natural Software〕）

slide: http://www.slideshare.net/kaorun55/devicelove

  • 3D・モーションセンサ
    • 低価格化
    • KinectV2で性能UP
    • LeapMotionもPCに組み込まれはじめている
    • iPadにもセンサがつく日も近いかも
    • 3Dプリンタはあるけど、3Dのスキャナは課題
  • 超音波、空気砲で何も無いところに触感を得る
  • RICOH THETA + Oculus Riftで場の提供

感想:

THETAとLeapMotionは持ってて遊んではいるけどもなかなか時間を投資できてない今日このごろ。 空気砲を使って感覚を与えるというアイディアは素直におもしろいと感じた。

【14-D-5】iOSアプリケーションの継続的デリバリー～エンタープライズ品質のiOSアプリケーションを目指して～（梅原直樹〔リコー〕）

slide: http://www.slideshare.net/numeha/ios-31199969

となりのセッションを見に行ったので、こちらは後日スライドを拝見させていただきました。

  • 価値あるソフトウェアを早く継続的にデリバリーし、お客様を満足させなくてはならない
  • プロジェクト開始時にリリースまでのパイプラインを作る
  • リリースのリズムを作る

感想:

うちのチームでもこんなふうにできたらいいなぁと。しないとね。

【14-B-6】ソフトウェア工学からコンピューターサイエンスへ - 今後のシステムアーキテクチャーに必要な技術的切り口とその裏側（萩原正義〔日本マイクロソフト〕）

slide: http://www.slideshare.net/MasayoshiHagiwara/dev-summit20140214

感想:

ソフトウェア工学は社会人になってから重要視するようになったが、コンピュータサイエンスもちゃんとやっていかないと生き残れそうにないな、と。

全体

雪でどうなることかと思いましたが、時間の短縮のおかげで最後まで参加できてよかったです。

タイトルと内容があってない講演がちらほらあったように思いました。

デブサミ関係者の方、ありがとうございました。

drone.ioで最新のMercurialを使う

Linux CI

たぶん私くらいしか必要としてないかもですがメモします。

drone.ioではubuntu12.04を使っているということもあり、古いバージョンのものがちらほらあります。aptで対応してもいいですが、いろいろとアップデートに時間もかかるので手っ取り早くdebでいれちゃいます。

以下をdrone.ioに入れます：

lsb_release -a
hg version
sudo apt-get remove mercurial
sudo apt-get remove mercurial-common
curl -s -o mercurial-common.deb http://http.us.debian.org/debian/pool/main/m/mercurial/mercurial-common_2.8.2-1_all.deb 
curl -s -o mercurial.deb http://http.us.debian.org/debian/pool/main/m/mercurial/mercurial_2.8.2-1_amd64.deb
sudo dpkg -i mercurial-common.deb
sudo dpkg -i mercurial.deb
hg version

とすると、以下のようにバージョンが2.8.2になります（途中省略）：

$ lsb_release -a
Distributor ID: Ubuntu
Description:    Ubuntu 12.04.2 LTS
Release:    12.04
Codename:   precise
No LSB modules are available.
$ hg version
Mercurial Distributed SCM (version 2.0.2)
(see http://mercurial.selenic.com for more information)

Copyright (C) 2005-2011 Matt Mackall and others
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
:
$ hg version
Mercurial Distributed SCM (version 2.8.2)
(see http://mercurial.selenic.com for more information)

Copyright (C) 2005-2013 Matt Mackall and others
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

めでたしめでたし。

入門TortoiseHg + Mercurial

入門TortoiseHg + Mercurial

vagrantでhttpプロキシを超える

VM memo

たまにプロキシに引っかかりますよね。たまに。

プロキシがあると、vagrantでvagrant upしたらapt-getとかwgetとかに失敗します。 docker使うときにもこれ有効です。

解決法:

https://github.com/tmatilai/vagrant-proxyconf を使う

セットアップ

インストール:

$ vagrant plugin install vagrant-proxyconf

Vagrantfile:

Vagrantfileに:

Vagrant.configure("2") do |config|
  config.proxy.http     = "<http_proxy>"
  config.proxy.https    = "<http_proxy>"
  config.proxy.ftp      = "<http_proxy>"
  config.proxy.no_proxy = "localhost,127.0.0.1,.example.com"
end

<http_proxy>の部分は http://[user:pass@]host:port の形式にする。

これでOK。

入門Chef Solo - Infrastructure as Code

入門Chef Solo - Infrastructure as Code

Vagrant入門ガイド

Vagrant入門ガイド

Vagrant: Up and Running

Vagrant: Up and Running

linux用のgodocのバイナリをOSXでつくる

golang Linux

クロスコンパイルメモ。

以前もクロスコンパイルをやったけど、OSXでlinux用のgodocを作ったときのメモ。 linuxでもwindows上でもできます（windowsはmingwの環境を整える必要がありますが。。）

前提:

手順

  1. ターゲットにする環境に合わせて GOOS, GOARCH をexportしておく (参考:http://golang.org/doc/install/source#environment)
  2. クロスコンパイルできるようにgoの環境を整える
  3. go get(go install)でターゲットのコードをビルドする

例

$ export GOOS=linux; export GOARCH=386
$ cd ~/go/src
$ ./all.bash
$ go get code.google.com/p/go.tools/cmd/godoc

とすると、 ~/go/bin/linux_386/ に godoc のバイナリができてる

godocは特殊なので ~/go/bin 以下にできます。ほかの普通のコマンド（例えば、 go get github.com/golang/lint/golintなど）は $GOPATH/bin/linux_386/ に配置されるはずです。