プロダクトセキュリティの「共通言語」を作る ― 技術教育と Policy as Code を例に / "Language" for Product Security
![Hello, Prometheus!! Goで作るexporter自作入門 / 180727 LT](https://cdn-ak-scissors.b.st-hatena.com/image/square/c5bc6dafe86e607abdb6c9d4982950640c7c920c/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F86308ebe22a045b5a30dae4a252484c1%2Fslide_0.jpg%3F10472786)
はじめに 今年に入ってから仕事でGolang書いてるのでスケジューラあたりについて調べた。ググってもあんまり資料が多くなかったんでまとめる。ソースコードを参照する時はGo 1.9.3を見た。わかりやすさを重視してあえて雑に説明しているところがあるけどご了承ください。 多分間違ってるところあるんで詳しい人は優しく教えてください。 goroutineあたりの基本的な話 goroutineはグリーンスレッド、つまりOSのスレッドは直接使ってない。なので、goroutineを作ることはネイティブスレッドを作る処理よりもはるかにコストが安い。このgoroutineを複数作るとランタイムが勝手にマルチスレッドで実行する。詳細は後述。 また、メインルーチンもgoroutineとして管理される。 スケジューリングの登場人物 重要な登場人物はM, G, Pの3人。 M(Machine) OSのスレッドに対応
Go言語はシンプルさを念頭にデザインされた言語です。仕様は単純明瞭さのために小さく収められていますが、そのため表現力に欠けているとか、コードが冗長になるという印象を持つ人も多いでしょう。有名なところでは、ジェネリクスや例外といった機能が(今のところ)存在しないことが問題にされることが多いようです。 一般に、ソフトウェアエンジニアリングというものは書かれる言語だけに依るものではありません。視点を拡げてGoを取りまくツール群を含めて見てみると、go fmt や goimports といったツールが広く使われていること、また go generate コマンドの存在などを見ても、Goという言語には、人間のプログラミングを機械によってさまざまな面から補助しようという態度があります。
サーバサイドエンジニアの @b4b4r07 です。この記事は Go Advent Calendar 2016 の 19 日目です。今回は Go (Revel フレームワーク) で書かれていた API サーバをフルスクラッチで書き直したお話をします。 Revel とは A high productivity, full-stack web framework for the Go language 公式の説明にあるように、Revel は高機能でフルスタックな Web フレームワークです。 複雑なルーティングや、パラメータのパーシング、テンプレート機能など、Web アプリケーションを作ろうとなったときに必要な手段はたいてい兼ね揃えているようです。公式ドキュメントに詳しく書かれています。 Revel 以外にも Go 製の Web フレームワークは多数あり、有名どころだと以下のようなものが挙げられ
来月ぐらいにはGo 1.7がリリースされそうなのですが、CONTRIBUTORSに名前が載せられそう( https://github.com/golang/go/blob/release-branch.go1.7/CONTRIBUTORS#L915 )なので記念エントリです。 内容自体は、4月にあったGoCon 2016 Spring( http://gocon.connpass.com/event/27521/ )での発表済みです。 tl;dr 一部のディストリの最新版でlinux/386でビルドしたバイナリが起動すらできない、というバグがあった 問題はruntimeのアセンブラ部分だったけど、なんとかパッチ書けた パッチ提出→コードレビュー→やりとり→マージまで、3日程度とスムーズに進行できた https://go-review.googlesource.com/#/c/21190/
cgoを用いるとCのライブラリをGoバイナリにリンクしたり、Goパッケージの一部をCで書いたりできる。更にGo 1.5以降では、GoのパッケージをC用の静的ライブラリまたは動的ライブラリにまとめておいて、Cからリンクすることもできる。 これらの機能はすべてgo buildコマンドに統合されているので、普段は特にcgoを使っていることを意識することは少ない。しかし、pure goのコードのビルドにしたところでその裏側ではコンパイラ、アセンブラ、リンカが走っているわけである。ではcgoの場合をこの水準で見るとどのような処理が行われているのだろうか。 要は、gcc(1)の裏ではcc1, as, collect2なんかが走ってるよね、cgoではどうなってるの? という話が本稿の話題である。 なお、Goのオブジェクトファイルがプラットフォーム独立な(ELFとかではない)フォーマットであることや、Go
github.com fireap = fire + reap です。 Consul Event を発火(fire)して、受信側でそれを収穫(reap)する、という意で。 読み方は「ファイリープ」で良いかと思ってます。 どんなツール? GitHub に上げた README.md より、かいつまんで日本語に変換しつつ説明します。 ノード数 N に対して O(log N) で動作するデプロイツールです。 が、実際にはデプロイに限らず任意のコマンドを実行できるので、README の中ではデプロイツールとは書いておらず、「高速タスクランナー」としています。 fujiwara/stretcher や sorah/mamiya は O(1) なので、それらが使える環境(S3 的な I/O やトラフィックの上限が非常に高いストレージがある)でデプロイを速くしたいという場合は、それらを使えばよろしいかと。
1. The document discusses RESTful APIs and gRPC, comparing their characteristics and use cases. 2. RESTful APIs typically use HTTP and JSON to access resources via URLs while gRPC uses protocol buffers and HTTP/2 for efficient streaming and RPC. 3. gRPC is better suited for microservices and mobile apps due to its ability to handle streaming and performance, while REST is more widely used due to i
あれ、 "-s"では変わってないですね…darwin環境ではでないのかななld周りのなにかだと思うのでそれはあとで追うとして、元々が26MBだったのが、5.2MBまで減りました。 圧縮に upx -9 を使った場合、かかった時間は15.70秒でそこそこ時間がかかりますね。3回ほど実行してだいたい同じぐらいでした。伸長時は0.10秒ほどでした。もちろんメモリなどにも依存しますので、この結果は鵜呑みには出来ませんが、あくまで目安として。 さらにいうと、 upx -1 で圧縮した場合は 0.78秒しかかかりません。それでいて、6.4MBと充分な圧縮効率となりました。この辺りはターゲットとする環境に合わせて決めればいいと思いますが、 -1 で十分な気もします。 まとめ¶ Goのバイナリが大きい問題は、ldflagsとUPXを使うことである程度解決できるのではないか、という話でした。 UPX知らなか
Go言語の開発をしようとして色々調べたんだけど結構大変だったのでまとめ。 基本的にMacでの作業を前提としています。 Goのインストール MacならHomebrewで一発。 $ brew install go GOPATH環境変数? Goでは、GOPATHという環境変数を設定すると、そこが作業スペースとなります。 ひとまずどこでも好きな場所をGOPATHに設定しましょう。 また、$GOPATH/binをPATHに通しておきます。 $ export GOPATH=$HOME/go $ export PATH=$PATH:$GOPATH/bin 同様の内容を.bashrcなどにも入れておきます。 すると、 $ go get [package name] とすることで、importできるパッケージが自動的にダウンロードしてインストールするという便利な仕組みがあります。 例えば、revelというW
事の始まり それはD言語くんへの嫉妬から始まった。 D言語くんの繁殖についての仮説 lsを間違えてdlと入力してしまったときに、D言語くんが通り過ぎるコマンド くっ悔しい... そしてショボいAAで2番煎じ。 lsを間違えてgolと入力してしまったときに、Gopherが通り過ぎるコマンド書いた。 こんなはずじゃない! 僕らの Gopher 君はこんなチープじゃない! 明日来てください。本物の Gopher をお見せしますよ。 — mattn (@mattn_jp) December 15, 2015 (本当はもうちょっと前から作ってましたが) 本物のGopher君とは そして今回、これを公開するに至った。 まずはこれをご覧頂きたい。 !!!!!!!!!!!!1 こいつ・・・ 動くぞ・・・ golang で書いたデスクトップマスコットです。起動すると画面のタスクバーの上をウロウロします。たま
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く