TL;DR module 有効下の go get は -u 相当 (バージョン未指定なら) go.mod の module には /v{2以上の値} という suffix でメジャーバージョンを書く必要がある 省略すると v0 もしくは v1 とみなされる 取得時には go get example.org/foo/bar/v2 のようにする パッケージを取ってくるときはこれで良いが、コマンドの時はリリース済みのメジャーバージョンを機械的に知る方法がないのでキツいね 髄記 言わずと知れた go get 、Goのパッケージをインストールしたり、コマンドをインストールしてくれたり、バージョン管理してくれる偉いやつ。 調べてみると module が有効かどうかで振る舞いが変わるらしい。 src/cmd/go 下をみると module かどうかでコマンドそのものが入れ替わってる。 internal/

2017/11/26 19:30 頃に vim/vim へ pull request を出したカラー絵文字パッチが、 わずか3時間半のうちにマージされました。 制作に関わったのは mattn さん、k-takata さんそして私の3人で、 超優良な品質のパッチという自負はありましたが、 それでもこの短時間でのマージはまったく予想しておらず、 望外のことに喜びと達成感もひとしおです。 ではその余韻の残るうちに、 この色付き絵文字対応パッチ制作の時間的経緯を ログを掘り返して書き記しておきましょう。 本来は Vim アドベントカレンダーのほうにも使えるネタなんですが、 まぁそちらには別のやつを考えましょうってことで。 あ、メッチャ長いんで要注意。 前日譚 まず以前から mattn さんは色付き絵文字を出したいと表明していました。 先日行われた VimConf 2017 でも言っていましたね。

先行販売された書籍 「みんなのGo言語」の紙の実物を著者陣よりも早く入手し読んだので、 夏休みの宿題には少し遅れましたが読書感想などまとめてみます。 来たる 9/9 に発売予定の書籍 みんなのGo言語 が、例によって書泉ブックタワーにおいて先行販売されました。この本屋の店頭には、著者に見本紙が届くよりも早く本が並ぶということで、一部にはとても有名です。そのため僕は、著者よりも早く実物の本を手にして読んで感想を記事にすることを画策し、数日前から足繁く通っては別の本を買ってたりしました。おかげで結構な出費になりました。でも技術書漁りは仕事かつ趣味みたいなところがあるからね。しょうがないね。 9/2先行販売『みんなのGo言語 [現場で使える実践テクニック] 』技術評論社（978-4-7741-8392-3）松木雅幸,mattn,藤原俊一郎,中島大一,牧大輔,鈴木健太著 入荷● Go言語を適材適所

以下のツイートにもある通り、一見 golang は struct を定義しないと JSON を扱えないように見えます。他にも似たようなツイートをチラホラと見かけましたが、それらは全部誤解です。そこでこの記事では、golang でゆるふわ (structを定義せず) に JSON を扱う方法を紹介します。 golang。rubyのようにゆるふわにJSONは扱えない? https://t.co/olsryDHc5G — bamchoh (@bamchoh) 2016年6月24日 この記事では入力の json.Unmarshal() を取り扱いますが、出力の json.Marshal() にも応用できます。 TL;DR json.Unmarshal() には *interface{} を渡せます interface{} は dproxy を使うと、値のアクセスで楽ができます json.Unmar

従来のVim scriptによるゲーム作成時の問題点を解消する、 新しいアーキテクチャを考察してみました。 この記事は Vim script Advent Calendar 2015 の 13日目の記事です。 まずは以下のデモ画像(別ウィンドウ)を見てください。 かなりスムーズに○リオが動いています。実はこれ、全部Vim scriptでできています。 ソースコードは koron/vim-ario に置いてありますので、チェックアウトして gvim -S game.vim することで試せます。ただし動作確認・保証は Windows版の +kaoriya な gvim でしかしておりません。また解像度も画面幅1920ドット無いとおかしなことになるので、異なる環境の場合は各自で調整してPRなどしてください。 操作は以下のとおりです。 h - 左ボタンのトグル l - 右ボタンのトグル f - ジ

最近よく見かけるバッドエンジニアリングの発生パターン。 イカしたフレームワーク/ライブラリが誕生する あるプロダクトがそのフレームワークを利用する フレームワークのスコープから少し外れたことをやるためにハックする フレームワークがセキュリティ問題などにより更新される 3のハックのせいでアップデートできない どーすんだよ、これ。 もちろんハックがシンプルで規模が小さい or 適切な方法ならば、アップデート時にフレームワークのソース読んでなんとかできるわけだけれど。 とくにフレームワークがカジュアルに使えるほど、3のハックを行う人がド素人で、どうにもならなくなるように感じてる。

func execLoop(list []Item) { for _, item := range list { do_something(item) } } list に格納された各 item に対して do_something() を適用する、よくあるタイプのループ処理です。 goroutine で並列化、その副作用 golang ではこの do_something() の適用を超お手軽に並列化できます。あ、もちろん do_something() はリエントラントである前提ですね。

目的 機能を持ったVimスクリプト(プラグイン)を徐々に作る様子を見て、書き方を学習してみよう 作るのはよくあるタイプのプラグイン Javaの単体テスト用クラスファイルを開く(作る)コマンドを作るよ 「ね、簡単でしょう(by ボブ)」と言ってみたい まずは雛形 ひな形としてこんなスクリプトを作ります。 command! -nargs=0 UtestAppend call <SID>UtestAppend() function! s:UtestAppend() echo 'HERE' endfunction " s:UtestAppend() UtestAppendというコマンドを追加 UtestAppendコマンドいが実行されたら ‘HERE’ と表示する ほら、すごく簡単ですね。 Javaだけに作用させる 以下はdiff形式で変更点だけ。 @@ -1,5 +1,17 @@ c

目次 第一話 遭遇編 第二話 スクリプト編 第三話 激闘編 第四話 昇華編 第五話 翻訳編 最終話 未来編 あとがき 勢いだけで書いてきて未回収の伏線もあったりしますが、そろそろ記憶のほうもかなり曖昧になってきましたので、ここで一つの区切りといたします。2011年のお盆の緊急特別企画ということで楽しんでいただければと思います。 幾分古いことですし、またエンタテインメントとしての性格が強いものですので、文章の表現には誇張や創作があることをお赦しください。また文章中に名前をあげました皆々様には、事前の許可などいただかず誠に申し訳ありませんでしたが、なにとぞご理解とご協力の程をお願いいたします。同時にネタになっていただきありがとうございました。 こういう企画文章を集中的に掲載するのってしんどいですけど面白いですね。特にtwitterを中心にほぼリアルタイムに反応をいただけるのが、執筆を進める上で

この記事は Go Advent Calendar 2018 の16日目の記事です。 Golangでプログラムを書く時にログを吐くの、どうしてますか? 本記事ではログを吐く際のコツというか気にして欲しい事項と、 なぜそうなるのかを解説していきます。 一概に「ログを吐く」と言っても、 ライブラリからログを吐く場合とアプリケーションから吐く場合では 相当に事情が異なります。 TL;DR ライブラリ(パッケージ)を書く時は… まずログを吐かないことを検討しましょう。 error で返してライブラリのユーザーにログへ吐かせるかどうかを選ばせましょう。 *log.Logger を使いましょう。 デフォルトは log.Printf に対して吐き(またはそれと同等のログを吐く)、 ライブラリユーザーの設定で任意の *log.Logger に切り替えられるようにしましょう。 自前の Logger インターフ

正規表現はVimに限らずコンピューター上でのテキスト操作において非常に強力です。 しかし学習の難しさも非情で多くのIT技術者、Vimmerが正規表現に苦しんでいるのを幾度となく目の当たりにしています。 ただ正規表現は本当にそんなに難しいのでしょうか。 いいえそんなことはありません。 正規表現は本来とても簡単な原理で学習も容易なのです。 にも関わらず難しいと思われてしまうのは、原理を理解しないまま外見上の機能をそのまま覚えようとするからです。 本記事では正規表現の原理にフォーカスし解説することで、Vimを含む様々な正規表現実装の利用難度を適切にしようという記事です。 本記事は Vim Advent Calendar 2019 の1日目の記事です。 「正規表現」はもともと形式言語という言語学の一分野の研究から生まれました。 言語学というのは言葉を科学的に研究する学問です。 形式言語はその中でも

golangでテストのためだけにinterfaceを書くのが死ぬほど嫌だったので編み出した技を紹介します。 TL;DR テスト(=mock)のためだけにinterfaceは切りたくない 型エイリアスとビルドタグを組み合わせるとinterfaceがなくてもモックが作れる この手法に必要なモックを自動生成するプログラムを作った interfaceは本当に必要なシーンで使うべき Background 現在モックを使った単体テストは一般的です。 Javaでの例を挙げると、モックしたいコンポーネントについて予めinterfaceを定義しておき、モックではそのインターフェースを実装するのが定石です。 しかしgolangのinterfaceはJavaなどのそれとは若干性質が異なるため、テスト=モックのためだけにinterfaceを書くのはオーバーワーク気味です。 そうテストのためだけにinterface

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に殺されて

はじめに 2020年の11月末。 なんとなく自作キーボードでも始めて見るかと思い付きました。 それまで自分にとって自作キーボードはハードウェア技術的にも既知で、 さらに長年使い続けたHHKBから乗り換える気も起こらず見向きもしなかったわけですが 「実際にやってもいないのにわかった気になるのは頭でっかちでよくないな」 と考えてやってみることにしたのです。 ということでやってみて見事にハマりまして 始めて1か月で数台のキーボードを組み立て この5か月で10台を超え20台に迫る勢いでキーボードを組み立て・設計・制作するに至りました。 この記事では自分が作ってきたキーボードたちを振り返ってみたいと思います。 なにぶん数が多いので1つのキーボードにつきなるべく量を絞って以下の観点から書き下していきます。 なぜそのキーボードを選択したのか(作ろうと思ったのか) 作った際の特徴、思い出話とかあれば 作っ