Goだけで作るフロントエンド
Go のシンタックスだけで HTML とスタイルと JS を構築する「Vecty」というフロントエンド開発キットの紹介 先日 Umeda.go#3 にて登壇して Vecty を紹介しました。資料はこちらです。 Vecty とは？ リポジトリ: https://github.com/gopherjs/vecty GopherJSむけの React-like な frontend development kit です。 GopherJS について 前に書いた紹介記事を参照 Vecty の主な機能は GopherJS の Go 記述を JS へのトランスパイル機能を利用します Go のシンタックスのみで HTML とスタイルとイベントハンドリングを記述 HTML 記述ツリーをコンポーネントとして定義する支援機能 コンポーネントツリーを初期レンダリングする機能 仮想 DOM のようにコンポーネント
ベンダリングのベストプラクティス
Goは大変便利なパッケージ参照やビルドツールチェインを持ってますが・・・。 プライベートリポジトリからのパッケージ参照やリビジョンロックができない。 そこでオレオレですが、ベンダリングテクニックを紹介。 パッケージ管理 Goは公開リポジトリからその時点での最新の版のパッケージを 簡単に自分のGo開発環境に取り込むことができます。 ですが、バイナリリリース型の開発をしていると 以下の４つの機能不足を感じます。 オリジナルリポジトリの消滅やエンバグの影響を受けたくない プライベートリポジトリからのパッケージ参照 リビジョンの固定 依存パッケージの追加や削除を簡単に行いたい （消失対策は何年も維持メンテする上での保険のようなものです） 標準機能としてベンダリング機能が追加 Go1.5で試験導入されたベンダリング機能は 1.6以降では標準機能として使えるようになりました。 GOPATH配下の「ve
Goのアンチパターン
Go書いててなんとなく見えてきた Goでやっちゃいけないパターン WAF導入してらくらくWebアプリ WAF自体が現在群雄割拠状態。 WAF毎にハンドラインターフェースが違うので既存コードつなぐにはラッパーが必要。 どのWAFもLL言語に比べるとまだまだフィーチャーの網羅範囲が狭い。 なのでもちろんLL言語ほど楽には書けないことが多い。 リフレクション使いまくりでトータル性能はLL言語並みに遅いのもある。 Go1.7のcontextパッケージの導入で標準のHTTPハンドラが復権する可能性があり更に荒れる予想。 追記: 楽できるのを期待してWAFを導入するの「やっちゃいけない」とまでは言い過ぎだったかもしれないけれど例のsqlでPrepareを正しく使えていないで性能出なかった件とか、当面WAFを使うなら自分で概ね中身を理解して使う覚悟が必要。 構造体メソッドにロジックを詰め込む Goの思想
GoのパフォーマンスTipsメモ
パフォーマンス維持のコツをコツコツとメモする リフレクションは最後の手段 パフォーマンスに寄与しない部分でのみ使う。 どこがパフォーマンスに寄与するのかが不透明なうちは使用禁止のほうが良い。 一度使い出すとリフレクションは多用したくなる魔力がある。 メモリ使用量 値は8バイトアライメントに置かれるので基本は8バイト長分メモリを専有。 ポインタ変数は64bitCPUで8バイト長 インターフェース型変数は16バイト長〜 （値＋型識別） メモリ確保を含む型コンバートは 型キャスト、アサーションに比べると10倍以上遅い。 同じ値なのに「メモリ確保を含む型コンバート」を複数回行う場合は メモリ消費量は増えるが汎用の変数「interface{}」に 値を保存しておいて参照するほうが速度を維持できる。 ゼロメモリアロケーション 高頻度操作におけるメモリアロック１とゼロの間には大きな速度差がある。 可能で
Goでスケールする実装を書く
スケールする実装を書くためのガイド スケールするために 並列度とアムダールの法則 べき等参照透過性 Lock-FreeとWait-Free アトミックアクセス ロックの局所化 並列度とアムダールの法則 時間単位の場合は繰り返し処理のトータル時間に対し、 並列処理を妨げない処理時間の割合を「並列度」という。 （コードプロファイルを使って求める場合もあるが、 比較的単純なコードでないと計算が複雑になりやすい。） p 並列度 n 並列数 性能比 1/((1-p)+p/n) p=0.9のとき４倍の性能を得るにはn=6が必要。 n=5で４倍の性能を得るにはp=0.938が必要。 n=無限大とすると、性能比は以下の式におちつく。 理論上の性能向上限界 = 1/(1-p) 並列度90%の処理をどれだけ多数コアに分散しても理論上10倍処理効率が限界。 並列度95%の処理をどれだけ多数コアに分散しても理論上
GopherJSの紹介
Javascriptを書きたくないでござる！な人向け。 GopherJSってなに？ Goの記述を100%Javascriptに変換してくれるツール。 サイト: http://www.gopherjs.org GopherJSの特徴 pure-GoなコードをJSの世界で動くように変換する。 goroutineやchanも論理的に動作するように変換。 外部バイナリ(.soなど)への依存のある実装の変換はできません。 CGOももちろんNG。 オンメモリ操作のパッケージなどは100%動く。 jsアーキテクチャとしてビルドされ、GOPATHを既存のものと共存可能。 GoとGopherJS両対応のパッケージも増えてきた。 GopherJS対応ライブラリ honnef.co/go/js/dom github.com/goxjs/gl github.com/goxjs/glfw github.com/go
Go言語のjson-rpcについて - GolangRdyJp
Go標準のjson-rpcはあるにはあるんだけど・・・。 かなーり特殊な実装なので他の言語から利用するのツライ。 これではせっかくの言語依存しないjson-rpcの仕様が泣いちゃうよ！ かといって重厚長大な実装を引き込んでしまうのもなぁ。 ということで、できるだけミニマムな解決方法を考えてみた。 結論 github にてパッケージを公開しました。 go get -u github.com/nobonobo/jsonrpc 以上でインストール完了。 以下をserver.goとかで保存。 package main import ( "log" "net/http" "github.com/nobonobo/jsonrpc" ) type Sample struct{} func (s *Sample) Add(args *[]int, reply *int) error { *reply =
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
goでp2pしよう！
PlayWithGopherJS