Go ではバイト列と文字列は異なる内部データとして扱っています。[]byte から string へ変換したり、またその逆を行う際にはキャストが必要になります。ですので string はイミュータブルになります。 しかしイミュータブルなのは理解しつつもバイト列を文字列にする為に無駄なアロケートをしたくない場合もあります。これまで Go ではドキュメントに明文化していなかった為に色々な作法が生まれてしまっていました。その代表的な物が以下です。 s := *(*string)(unsafe.Pointer(&b)) 本来は、Go のバイト列の内部は SliceHeader という構造体により管理されています。 type SliceHeader struct { Data uintptr Len  int Cap  int } また string は以下の StringHeader で管理されて

みなさん Fuzz testing ってご存じでしょうか。 人間が作る物は必ずといっていいほどバグが存在します。そしてそのコードをテストする人間も必ずバグを見逃します。 想定していなかった境界値テスト等、人間には先入観という物があり、それが邪魔をして簡単にバグを見逃します。昨今、この様な誰も気付かなかったバグの隙間を突く様な脆弱性が沢山見つかっています。 物によっては重大インシデントに発展する物まであります。 こういった人間では想定できない様なバグを見付けてくれるのが Fuzz testing です。Fuzz testing を実施する事で、ソフトウェアは頑丈になり安全にもなりえます。 本日、Go の master ブランチに Fuzz testing の機能が入りました。 [dev.fuzz] Merge remote-tracking branch 'origin/dev.fuzz'

おなじみC/C++から使えるJSONライブラリを紹介するコーナー。まずは過去のまとめ。 ヘッダファイルだけでC++から使えるJSONパーサ「picojson」が凄い！ 何も見ずにC++でjsonパーサが書けるか試してみた。 C言語から使えるJSONパーサ、JSMNを試してみた。 僕がboost::asioとboost::property_treeを使いHTTPプロキシ環境下で非同期にGoogle Search APIから検索するまでにやった、たった一つの事。 C言語から使えるJSONパーサ、parson が思った以上に良い仕事をしている。 最速と言われる JSON パーサ「rapidjson」が本当に爆速なのか試してみた。 C言語から使えるJSONパーサ、jansson がとても直感的で良い C++ で STL フレンドリに扱えるJSONパーサ「json.hpp」 これまで C++ から扱

執筆者様に Twitter でお声掛け頂き、発売前ながら献本頂く事になりました。執筆された森下様、送付頂いた技術評論社様、ありがとうございました。 Visual Studio Code は登場から色々な機能を取り込みつつ着実にユーザを増やし、統合開発環境としては今や飛ぶ鳥を落とす勢いになった言って良いでしょう。以下は 2019 年の Stackoverflow Survey で公開された有名な開発環境の調査結果です。 僕は普段は Vim というテキストエディタを使っていますが、実は僕は色々なテキストエディタを試します。Emacs も人並み程度使えますし、Visual Studio Code も拡張を自分で書いた事がある程度には使っています。 Search results - mattn | Visual Studio Code , Visual Studio Marketplace ...

はじめに 以下の記事では、僕の Vim の構成について記述しています。本来はこの記事で vim-lsp の導入方法と私的 Go 編集環境について書こうと思っていましたが、あまりにも長くなってしまったので別途書く事にしました。僕は Windows と Linux しか使わないので、皆さんの環境で使うとうまく動かない可能性があります。また僕は最新の Vim 8 しか使いません。古めの Vim を使いません。neovim も使いません。それらをお使いの方はうまく動かない可能性があります。ご了承下さい。なお設定ファイルの配置スタイルは完全に僕個人の趣味ですので必ずしも僕の構成が正しい訳ではありません。 ぼくのかんがえたさいきょうの Vim こうせい Vim の設定は vimrc に記述するのですが、その設定方法には「汚くさせない」ための工夫が必要だと思っています。以下は僕が行っている「vimrc

はじめに 今年も Vim の国際会議 VimConf 2019 に参加してきました。本格的に国際会議という位置づけに移ってからほぼ4年目、その内3年をスタッフとして参加させて頂きました。 昨年、Vim の作者 Bram Moolenaar 氏を呼べたのはもちろん素晴らしい事ですが、今年も vim-lsp の作者である Prabir Shrestha 氏、neovim のメインメンテナである Justin M. Keyes 氏に登壇頂けたのは、企業スポンサー様の皆さま、個人スポンサーの皆さま、そして当日会場を盛り上げて頂いた皆さまのおかげです。ありがとうございました。 参加したいと思いながらもなんとなく尻込みして来れなかった方、非常に残念です。良い話が沢山聞けました。スライドが後から公開されると思いますが、これだけは言っておきます。熱量やそれを見ている会場の皆さんの期待、懇親会で Vim と

8月に Google Developers Expert となり、新米の様にオロオロとしています。過去の GDE ミーティングの議事録を見せて頂いているのですが Google Document に保存されており、Go だけでなく他のカテゴリの GDE に関する物も含めると全てに目を通すのはなかなか骨が折れます。技術者なので問題は技術で解決すべく、これらの資料を grep 検索できる様にしました。 Google Document はエクスポートすると Microsoft Word の形式となるので、Microsoft Word から Markdown に変換するプログラムを書けばテキスト検索もできるし、なんならそのまま GitHub に貼り付けてしまう事もできます。 GitHub - mattn/docx2md docx2md Convert Microsoft Word Document

はじめに まず始めに言っておかなければなりません。 gocode 今まで本当にありがとう この記事は、Go 言語歴10年になる僕がこれまで愛用してきた Go 言語のコード補完ソフトウェア gocode の歴史と功績、そして今、gocode 自らがその役割を終えようとしている姿をぜひ皆さんに知って頂きたいという思いから Go Advent Calendar 2018 の記事として起こしました。この記事では gocode が歩んできた歴史と苦悩を少しでも皆さんに分かる様に解説させて頂きつつ、そして次にやってくる Go 言語のコード補完の未来についてご紹介したいと思います。Vim について多めに書かれていますが、Visual Studio Code での Go 開発にも影響する話です。 gocode とは gocode は nsf 氏が開発した Go 言語のコード補完サーバです。 GitHub

僕のこれまで人生の中で、2日間まるまる Vim の事を考えるなんて事なんて無かったし、今思い返してもとても刺激的な日でした。 まず始めに、VimConf というイベントを産み出してくれた ujihisa さん、kaoriya さん、運営に関わった皆さん、そしてスポンサー頂いた企業の皆様、個人スポンサーをして頂いた皆さん、本当にありがとうございました。 中には参加できないにも関わらず VimConf が上手く行く事を願って個人スポンサーになってくれた方も沢山いました。本当にありがとうございます。 今回 Vim の作者 Bram Moolenaar 氏を VimConf 2018 に呼べたのは皆さんのお力あってこそだと思っています。 これまで VimConf はどちらかというと、こじんまりしたイメージのイベントでしたが、「Bram Moolenaar 氏を呼ぶに相応しい国際会議として開催すべき

Let's Encrypt という無料の SSL を提供しているサービスがあり、これを簡単に操作できる CLI として Lego というツールがあります。以前から Lego に MyDNS をサポートして貰おうとプルリクエスト を送っていたのですが、ようやく本日マージされました。 環境変数 MYDNSJP_MASTER_ID と MYDNSJP_PASSWORD を設定した上で以下の様に実行すると登録されます。 $ lego -m your@email.com -a -x http-01 -x tls-alpn-01 --dns mydnsjp -s https://acme-staging-v02.api.letsencrypt.org/directory -d xxx.mydns.jp -d *.xxx.mydns.jp run また更新したい場合は以下の様に実行して下さい。 $ le

Twitter で「読みたい」と呟いたら著者の武内覚さんから献本しましょうかとお声を掛けて頂いたので即答でお願いしました。 僕はいつも Linux でしか動作しないソフトウェアを Windows に対応させるパッチを書いたりしているので、普段 Windows しか触っていないと思われがちですが、実は僕が Linux を触り始めたのは 1996 年にトッパンから出版された「Linux 入門」くらい昔だったりします。ちょうど Linux 2.0 が出た頃だったと思います。その頃の Linux はようやく SMB カーネルが出た頃で、まだまだお遊び感のある OS で不安定でもありました。ディストリビューションもほぼ Slackware くらいしか無かったかもしれません。 あの頃の Linux はインターネットを検索しても殆ど情報が出て来ず、本気で調べるにはソースコードを読むしかありませんでした。

8/31、patch 8.0.1026 で Linux 版 Vim のとある挙動が修正されました。 patch 8.0.1026: GTK on-the-spot input has problems - vim/vim@5c6dbcb - GitHub https://github.com/vim/vim/commit/5c6dbcb03fa552d7b0e61c8fcf425147eb6bf7d5 この修正は、Linux 版 Vim の IME (Input Method Editor) の挙動を修正する物ですが、この1つのパッチの為に多くの開発者が動いたという話です。 Vim と IME と僕 このパッチ、多い時で月に100個以上もリリースされる大量のパッチの1つに過ぎないのですが、実はこのパッチには思い入れがあり記事にせずにいられませんでした。この問題が修正されるまでに至った経緯を

今日とある場所で虫が入り込む瞬間を見た。虫といってもバグの方。それはプログラマ向けの Q&A サイトで始まった。質問の内容はこうだ。 文字列には0または4がだけが含まれる。文字列は 4 から始まり、例えば 440, 44, 40, 4400, 4440 など、これらは正しいとするが 404 は正しくない。今のところ、私は 0 の直後に 4 が現れるかどうかでチェックしている。これは果たして効率的だろうか。 始め僕はこの質問文をちゃんと読んでおらず、正規表現を使ってこれを実装した。 package main import ( "regexp" ) func check(s string) bool { return regexp.MustCompile(`^4+0*$`).MatchString(s) } func main() { for _, tt := range []string{"

元ネタはずいぶんと昔の記事なのだけど。 編集距離 (Levenshtein Distance) - naoyaのはてなダイアリー ■ 編集距離 (Levenshtein Distance) 昨日 最長共通部分列問題 (LCS) について触れました。ついでなので編集距離のアルゴリズムについても整理してみます。 編集距離 (レーベン... http://d.hatena.ne.jp/naoya/20090329/1238307757 思い付きはまったく関係ない所から。 mp3 が数千ファイル入ってるフォルダで何かの手違いで同じ曲が入ってしまう事が結構あって重複取り去る作業してた。ID3が違ってるとMD5も違うのでレーベンシュタインの文字列距離を使ってファイル名が似てるの調べたら422ファイル消せる事が分かった。 — Vim芸人 (@mattn_jp) February 25, 2017 これを

Twitter で「言語のしくみ」読みたいなって呟いたら Matz 本人から「献本しましょうか」とメンション頂いて即答でお願いしました。ありがとうございます。 ひさびさ紙の本を通勤電車の中で立ちながら読んだので手がだるくなりました。なんだか懐かしい感じがしました。 さてこの本ですが、一言で言うとこんな本です。 Ruby のパパこと Matz が雑誌の連載に追われながら試行錯誤して作ったプログラミング言語「Streem」を解説する本 聞こえが悪かったらすみません。言いたいのはこの「試行錯誤」がとても良いエッセンスになっている点なのです。実際にはその連載記事をまとめた物に対して、この当時はこの様に考えていたが後になってみると実は良く無かったといった振り返り「タイムマシンコラム」で構成されています。 この連載が1つの本に纏められた事でプログラミング言語設計者の葛藤が非常に良く表されているな、そう

Bash on Ubuntu on Windows (以下 BoW) は Windows コマンドプロンプトを使って実行される。今までであれば Windows のコマンドプロンプトはエスケープシーケンスを認識しなかったので cmd.exe そのものでは vt100 等の端末環境を用意できませんでした。しかし Windows10 の cmd.exe では新しいコンソールモードが用意されています。 Console Virtual Terminal Sequences (Windows) Virtual terminal sequences are control character sequences that can control cursor movement, color/font mode, and other operations. https://msdn.microsoft.c

とりあえず issues 関連は出来てるので、これを使うコマンドラインプログラムを書いた。 $ go get github.com/mattn/go-redmine/godmine 名前は中二病っぽいけど「godmine」という名前にした。 使い方は、例えば issue の一覧であれば $ godmine issue list もしくは $ godmine i l issue の登録は $ godmine issue create "なんてこった" "大変だ！" みたいにするか $ godmine issue append で起動するテキストエディタ(環境変数EDITORを参照しunix改行コードが扱えるテキストエディタのみ使用可能)で ### Subject Here ### ### Description Here ### 上記の部分を書き換えて保存終了する。 設定ファイルは ~/.c

[D] Windowsはターミナルがダメだから使えないってのは過去の話? 基本的にはいい感じに見えますが、いくつか問題は発覚してます。 http://blog.drikin.com/2015/01/windows-2.html 僕は Cygwin よりも msys2 が好きです 理由は最後の方に書きます。 cygwin は windows 上に完全な POSIX を提供するのが目的であって、msys2 は native な windows アプリケーションをビルドするのが目的なのでゴールが違うのよね。そして僕は全て cygwin で染められるのが好きじゃ無い。それだけの話です。 — mattn (@mattn_jp) April 10, 2016 もちろん msys2 を POSIX 環境としても使いますが、一番の目的は cmd.exe から Windows ネイティブなアプリケーションを

« golang で画像アップロードが簡単に出来る go-imageupload を使ってみた。 | Main | SQLite3でカジュアルにズンドコキヨシ » コマンドラインから JSON を扱うツールとしては jq が一般的ですが、例えば ls を実行した結果を JSON の Array にしたいであったり、コマンドライン引数から簡単に Object を作りたいといった場合には一旦考え込まないといけないくらい使い方が難しかったりします。そんな中でひょいと現れたのが jo です。 GitHub - jpmens/jo: JSON output from a shell JSON output from a shell https://github.com/jpmens/jo 作者である jpmens さんがなぜ jo を作るに至ったかをブログに書いています。 Jan-Piet Mens

先日、GitHub Pages が Jekyll 3.0 になりました。 GitHub Pages now faster and simpler with Jekyll 3.0 · GitHub GitHub Pages is now running the latest major version of Jekyll, Jekyll 3.0 , and with it, many of th... https://github.com/blog/2100-github-pages-now-faster-and-simpler-with-jekyll-3-0 速くなったという事でとても喜ばしいのですが、良い事はそれだけではなかった。GitHub Pages を使ってのブログ作成方法については、これまでこのブログでも幾つか紹介して来ました。 Big Sky :: Jekyllで始める簡単ブロ