問題のある実装パターン 共通実装 以下のような applog パッケージ上のロガー実装を考えましょう。ここでは Go 標準の log.Logger をラップしていますが，様々な実装に拡張できることを想定しています。 package applog import ( "fmt" "log" "os" ) type Logger interface { Info(message string) Error(message string) } func NewLogger() Logger { return &logger{ inner: log.New(os.Stdout, "", log.LstdFlags), } } var _ Logger = (*logger)(nil) type logger struct { inner *log.Logger } func (l *logger)
Go ではバイト列と文字列は異なる内部データとして扱っています。[]byte から string へ変換したり、またその逆を行う際にはキャストが必要になります。ですので string はイミュータブルになります。 しかしイミュータブルなのは理解しつつもバイト列を文字列にする為に無駄なアロケートをしたくない場合もあります。これまで Go ではドキュメントに明文化していなかった為に色々な作法が生まれてしまっていました。その代表的な物が以下です。 s := *(*string)(unsafe.Pointer(&b)) 本来は、Go のバイト列の内部は SliceHeader という構造体により管理されています。 type SliceHeader struct { Data uintptr Len int Cap int } また string は以下の StringHeader で管理されて
はじめに Go Secure Coding Practice とは コンテンツ一覧 良かったところ 注意すべきところ 最後に はじめに こんにちは。SRE の izzii です。 テックタッチのエンジニア規模もそれなりに拡大し、若手の採用も進んできたため、セキュアコーディングを徹底していきたいという思いがあり、まずは意識改革ということで勉強会を実施しました。セキュアコーディングを目的とした場合には教育だけでなく Static application security testing (SAST) の導入といった方法もあるのですが、まずは自分を含めた開発メンバーにノウハウをインストールすることにしました。セキュアコーディングへの意識が高まれば、いづれ SAST の導入の際に抵抗感も少ないだろうと考えています。いきなり SAST を導入しても、誤検知が煩くて浸透しないリスクもありうると考えてい
動的型付けプログラミング言語や、class を持つようなプログラミング言語を使う場合、そのフィールドメンバの定義順などを意識する事は少ないかもしれません。 Go は struct という、C言語が持っている構造体と同じ様にメモリ配置され、構造体そのものをレシーバとして、メソッドを定義しつつプログラミングを行います。struct はデータ構造そのものを示し、それが大きくなるにつれ、当然ながらメモリ使用量も多くなります。 さて、例えば以下のコードを実行すると、struct 100 個分のサイズは幾らになるでしょうか。 package main import ( "fmt" "unsafe" ) type Account struct { TimeZone struct { Name string `json:"name"` UtcOffset int `json:"utc_
今回も小ネタ。 Go でコードを書く人にはお馴染みの話題であるが，たまたま見つけたので。 お題はこのコード： package main import "fmt" func main() { var a *string = nil var b interface{} = a fmt.Println("a == nil:", a == nil) // true fmt.Println("b == nil:", b == nil) // false fmt.Println("a == b: ", a == b) // true } 実際の実行結果はこちら。 Go における nil はポインタ値のある状態を示すもので，いわゆる「null 参照」を指している。それだけだったら b == nil は true になりそうなものだが， interface 型が絡むと少し複雑になる。 実は interfa
はじめに 本記事は、 DeNA Advent Calendar 2020 の 11 日目の記事です。 突然ですが、「コンパイラのコードを読んでみよう」なんて言われても、「どうせ巨大で難解で複雑なロジックを理解しないと読めないんでしょ？」と思いませんか。 コンパイラの構造を理解しようとしても聞いたことのないような専門用語がずらりと並び、コードを読もうとしたらそれらをすべて完全に理解してないと一行も理解できないんじゃないか...。Go のコンパイラ gc のソースコードを読むまでは、私もそう思っていました。 しかし、あまりにも暇な休日のある日、思い立って gc のコードを読んでみました。すると、「コンパイル」という難解な響きの処理も、一つひとつを小さなタスクに分解することで、少しずつ読み進めることができると分かったのです！ 何よりも感動したことは、 gc そのものが全て Go で書かれていて、
var hoge *Hoge if condition != nil { hoge, err := https://t.co/3dOQ15DCmc(ctx, hoge_key) if err != nil { return nil, err } fmt.Printf("%v", *hoge) } else { hoge = nil } こんな感じのコードで死んでたんですが、うっかりhogeがnil担っちゃうの防ぐにはどうしたら・・・（文字数 — chidakiyo (@chidakiyo) February 26, 2020 こういった場合に便利なのがオフィシャルが提供している解析コマンド shadow です。(相変わらずググらび...) インストールは以下を実行します。 $ go get golang.org/x/tools/go/analysis/passes/shadow/cmd/s
Go + echo + Docker + VSCode + Remote Containers で開発環境の構築 (ホットリロードとステップ実行対応)GoDockerdocker-composeVSCoderealize 背景 Go + echo で api サーバーを実装するにあたり開発環境を構築した際のメモ。 Docker で動かしたい。 VSCode の Remote Containers を試したい。 ホットリロード欲しい。 ステップ実行したい。 成果物 https://github.com/f-sugar/golang-docker ホスト Docker 19.03.1 docker-compose 1.24.1 VSCode 1.42.0 ms-vscode-remote.remote-containers 0.101.0 コンテナ内 go 1.13.7 realize 2.1
golangで書いたプログラムをDockerで動かしOOMが発生した際になるべく情報を残して殺される方法を紹介します。 2020/08/16追記: この記事の内容はgolangに関してはやや現実的ではなくなってしまいました。 詳しくは続編を参照してください。 TL;DR golang製のプログラムは仮想メモリ(VSZ)の確保に失敗するとgoroutineのダンプを吐いて死ぬ DockerのOOMはRSSベースで検出時にSIGKILLを投げてくる Docker利用時にVSZで制限をかけるスクリプトを書いた golang製のプログラムはlinux-amd64において最低でも101MBのVSZを要求する VSZの制限がそれより小さいと当然起動できない 実際のRSSは3MB程度で起動する Background コンテナ内で動いているプロダクション上のgolang製のプログラムが時々OOMに殺されて
ファイルを一括でリネームしたいことはありませんか。私はあります。ということで作りました。 インストールはHomebrew brew install itchyny/tap/mmv または以下のコマンドでできます。 go get github.com/itchyny/mmv/cmd/mmv スクリーンショットではvimが起動していますが、 $EDITOR が設定されていればそれを使って編集することができます。 エディターでファイル名を編集して一括でリネームするというのは、新しい発想ではありません。 実際、多くのソフトウェア (特にファイラー) がこの機能を実装しています。 massren vimv qmv Vim plugin vimfiler Defx Vaffle fila.vim Emacs Dired 私はvimfilerの一括リネーム機能をよく使っていました。 特に不満はないのです
Custom software development Tailored software solutions and software augmentation services to meet unique business needs, drive operational efficiency, and stimulate business expansion Read more Development teams Dedicated development teams and professionals that work exclusively on your project and ensure top-notch tailored solutions Read more IT consulting Expert guidance on leveraging advanced
普段 Golang でサーバコードを書くときはもっぱら Emacs を使っています。Go Modules に移行してから gocode が動作しなくなったので最近はやりの LSP(Language Server Protocol) を導入することにしました。Go の Language Server は gopls 、Emacs のLSPクライアントは eglot を使います 動作確認バージョン Emacs 26系 Golang 1.12.x Emacsは25以上、Golangは1.11以上なら問題なく動作するはずです。 gopls のインストール Go の Language Server は3種類あります。一番下の gopls が Golang の公式 Language Server です。 go-langserver bingo gopls 一長一短あるようですが公式が安心そうなので g
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Golang で推論 昨今では「機械学習と言えば Python」「Python と言えば機械学習」と思われがちなのですが、推論用途であれば学習済みモデルを利用して色々なプログラミング言語から扱えます。Go から扱える機械学習ライブラリの内、学習済みモデルが利用できる物としてはおおよそ以下の3つに絞られます。 TensorFlow TensorFlow Lite ONNX Golang で TensorFlow Golang で TensorFlow を利用する場合はオフィシャルから Go の binding が提供されているので Go
144labの入江田です。 今回TinyGoという素敵なプロダクトを試してみました。 TinyGoとは TinyGoは本家Go言語の組み込み向けのサブセット版。 本家Go言語はPOSIX-OSに対する機能依存が大きく、リッチなランタイムを持っています。その為、本来はOSを持たない組み込み用途には不向きでした。 TinyGoはPOSIX-OSに依存する機能を簡易的な実装で代用しつつLLVM（コンパイラを作る為のフレームワーク）を使って組み込み向けアーキテクチャをサポートするGo言語のコンパイラです。 つまりサポートするCPUアーキテクチャはLLVMがサポートするものを前提にしています。 リポジトリ https://github.com/tinygo-org/tinygo ドキュメント https://tinygo.org/ サポートアーキテクチャ ARMのCortex-M0系 WebAsse
ライブラリ探すなら基本awesome go見とけばいいけど、いろいろ楽するためという観点で、思い出した順に適当に追記していく。気が向いたらサンプルも書く gojson https://github.com/ChimeraCoder/gojson jsonのデータを渡すとそれに対応するstructを生成してくれる。JSON APIを利用するときに楽ができる。既存APIのリプレイスをGoでやるときとかも良い。 goquery https://github.com/PuerkitoBio/goquery JQueryっぽくhtmlをパースしたり検索したりして楽ができる。自前でhtmlのパースなんか書いてられない。 goreq https://github.com/franela/goreq net/httpパッケージで、httpリクエストを飛ばすのは結構面倒だったりいろんな書き方があったりしてヘ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
