自宅では(も)職場と同じくMacBook Pro 13inchを使っていて、デスクに向かうときはLGの4Kモニタをクラムシェルモード、USB type-C接続で使っているんですが、まぁ普通モニタのスピーカーというのはあまりいい音はしません。まぁ、おまけみたいなものなので仕方ないんですけど。そんなわけでモニタからは音を出さず、音はPCのスピーカーから出してました。 私は基本的にあまりPCで音楽を聴く、ということはしない人間なので、特にそれでも不満はないままここまで来たんですけど、先月から新型コロナウイルス感染症(COVID-19)流行のあおりを受けてヘイシャでもリモートワークで仕事をする、という形になりました。 そうすると、これまでは帰宅後食事やら風呂やら、の後くらいから寝るまでしか自宅ではPCに向かっていなかったのが一気に一日中へと伸びました。ミーティングの類いもzoomで行うことになり、これを機にスピーカーでも買おうかな、なんて思っていたところ、Ankerがリモートワーク特集 でいくつかの商品(元々は4種類か5種類くらい対象商品があったんですけど、売り切れたのか現在は3種類になってますね)が半額、その中にBluetoothスピーカーもある、という話を聞きまして、購入に踏み切りました。 今回購入したのはSoundCore Motion B という商品です。一年半位前に発売された商品で、Bluetooth接続、IPX7規格の防水性能、最大12時間連続再生可能なバッテリーというのが売りの商品です。 また、こちらの商品は二台を一台のPCにつなぐことで二台で一つのステレオとして使用できる(わかりにくい)という機能もあります。 せっかく半額なのだし、二台買っても一台分、二台でつなぐとどんな感じなのかもちょっとやってみたい、ということで二台購入しました。 届いた商品がこちら。Ankerらしく、小柄なパッケージです。発送はAmazonが代行しているようで、Amazon Japanからの荷物として届きました(が、箱はAmazonの箱ではありませんでした)。輸送用の段ボール箱も小さめだったため、一瞬「二個頼んだよな・・・？」と不安になりましたが、ちゃんと二個入ってました。 箱の上面には商品の売りと内容物が書いてあります。内容物が少なすぎて、左側のWhat’s In The Boxと右側の内容物の間が開きすぎていて戸惑います。 側面。完全防水と12時間再生、との記載があります。完全防水とのことですけど、仕様としてはIPX7なので、防水特性としては1mの水深に30分浸かってもOK、という感じですね。 箱下部のテープ(?)を剥がして開封。飾り気のない白い箱が姿を現します。 右側にプルタブ(?)があるので、付属品がはいっている箱で蓋されている、という状態ですね。 白い箱を取り出すと、本体が姿を現します。充電器とかと同じく、薄い袋に入っています。 内容品を取り出した様子。おなじみHappy? Not Happy?の紙とUser Manual、充電ケーブルが入っていました。充電ケーブルはMicro USB Micro-Bです。User Manualはちゃんと各国語で書かれています。 二台積んだ様子。わかりにくいですけど、上部にボタンがついています。これに充電ケーブルを挿して、左右で使用します。 ステレオで接続する場合はまず両方のスピーカーを起動し、ステレオモードにします。スピーカー同士がつながった後(状態変化がわかりにくい・・・)、PCに接続します。 PC側の表示は一台分として表示されます。二台バラバラに管理する必要はない、ということですね。 で、肝心の音ですが、もちろんモニタやPC本体の音より圧倒的に良いと思います。スピーカーとしての音質がすごく良いかというと、まぁBluetoothの時点でそこそこ、という感じだと思いますが、私としては特に問題ない音質です。 きちんと右、左から別々に音が出ていて、センターの音はセンターあたりから聞こえている様な気がします。 パッケージにもBig Soundと記載がありましたが、音量は大きめだと思います。 音量設定を下記スクリーンショットくらいに設定していますが、MBPのスピーカーで音量をバーの真ん中位に設定したときと同じくらいの音量がでています。 まぁみんながみんな二台買うのがいいかというと、それはよくわかんないですけど、すごく高いものという訳でもないので、そこそこのPC用スピーカーを探している、というかたはこれを機に二台えいっと買ってみても良いのではないでしょうか。

昨晩の晩ご飯として、サーモンを低温調理でやりましたので、記録に残しておきます。 なお、使用したサーモンは刺身用のサーモンを使用しています。多分刺身用じゃなくても良いとは思うんですが、ちょっと怖かったので。 使用するサーモンはこちら。近所の西友で割引になっていたもので、300g前後で600円弱だった気がします。二人分です。 水気を適当に拭いた後、半分にざっくりと切ってステンレスのトレー？バット？に置きます。実家にはバットというものは存在しなかったんですが、使ってみると非常に便利です。100均でも売っているので、適当に数枚そろえておくとなんだかんだ重宝します。 塩と水と砂糖を何やら混ぜ合わせたものに浸します。細かい分量はオライリーさんの「家庭の低温調理 」を参照してください。なお、私は紙の本を買いましたが、電子書籍で買ってiPadかなんかに表示しながら調理するのがおすすめです。結構厚い本なので、とにかく取り回しがしにくいので。 我が家のバットでは若干サーモンが液体から出てしまうので、キッチンペーパー的なものに液体をしみこませて上からかぶせておきました。この状態で20分ほど放置します。 その間に水槽(というかバケツですけど)を暖めておきます。今回は52度でやります。水道から普通にお湯(できれば少し温度設定をあげたもの)をためるとあたため時間が短縮できます。多分。 20分経過したものがこちら。あんまり見た目は変わってない気がします。 流水でさっと洗って余分な塩気を落とし、ペーパーで水分をとります。なんか筋がピロピロしててキモい。 キャノーラ油をまんべんなくまぶし、ジッパーつきの袋に投入します。写真のものはIKEAの袋です。まだ袋の口は閉じていません。 いわゆる水圧法で空気を抜き、袋の口を閉じて52度で20分やります。あたためている間にソースを作ったりするのですが、昨日はパスタを作ったりもしたので、結局40分くらい放置してしまいました。「家庭の低温調理」には30分までと書いてあったのですが、まぁ40分でも大丈夫です。 ソース単体の写真は取り忘れてしまったんですけど、味噌とディジョンマスタード、蜂蜜、レモン汁、すりおろした生姜、ごま油とキャノーラ油をよしなに混ぜたモノです。適当にスプーンで混ぜても案外ちゃんと乳化するもんですね。 ソースをかけた後七味をかけていますが、買ってから大分たった七味なので、辛みも香りも何もない物体になってしまっていました。 おいしかったです。まる。

Language Server Protocol (以下LSP)はこれまでエディタ/IDEが独自に実装する必要があった、補完や定義参照、静的解析によるエラー分析などをサービスとして実現するためのプロトコルです。 LSPを実装したクライアントは、Language Serverを提供している言語であれば何でも補完や定義参照、静的解析といった便利機能を使用することができます。 Microsoftが2016年にその仕様を公開してから、多くのエディタ用のLSPのクライアント実装が作られ、また各種言語用のLanguage Serverも公開されています。 Go言語も例に漏れずLanguage Serverの実装がいくつか存在します。今回は準公式提供のgopls を使用して設定してみます。 もちろんemacsにも複数のLSP Client実装がありますが、今回はlsp-mode を使用します。 まずはemacs用のパッケージをインストールします。次のモノをpackage-installかpackage-list-packagesか、そのあたりでよしなにインストールします。 lsp-mode lsp-ui company-lsp インストールできたら、(私はuse-packageを使っているので)設定ファイルにuse-packageの設定を入れておきます。ついでにgo用の設定も入れておきましょう。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 ;; Golang (defun lsp-go-install-save-hooks() (add-hook 'before-save-hook #'lsp-format-buffer t t) (add-hook 'before-save-hook #'lsp-organize-imports t t)) (use-package go-mode :ensure t :mode (("\\.go\\'" . go-mode)) :init (add-hook 'go-mode-hook #'lsp-go-install-save-hooks)) ;; Language Server (use-package lsp-mode :ensure t :hook (go-mode . lsp-deferred) :commands (lsp lsp-deferred)) (use-package lsp-ui :ensure t :commands lsp-ui-mode) (use-package company-lsp :ensure t :commands company-lsp) goplsのインストールもしましょう。 ...

ここ数日、FlutterでAndroidアプリを書く、ということに入門してみています。 Androidアプリの開発自体は大分前(無印Galaxy Sを使っていた頃なので、EclairとかFroyoとかの頃)にすこしだけやったことがあるんですが、そのころと比べるとかなり簡単に、きれいなアプリがシュッと動いて、ちょっとばかし感動しています。 扨、Flutter/Android開発の環境構築ですが、ほとんどのドキュメントがAndroid Studioを前提としており、私のようなemacsユーザがどうしたらいいのか、ちょっとばかし躓きそうなので、メモがてら残しておきます。 なお、基本的な手順は公式サイト に準じます。また、環境はmacOS Catalina バージョン 10.15.1、emacsはbrewで入れるemacs-mac 26.3です。 Flutterのバージョンは執筆時点でv1.12.13+hotfix.5でした。 Flutter SDKのインストール 公式サイト のダウンロードリンクからFlutter SDKをダウンロードしてきて解凍、任意の場所に配置します。私はなんとなくで$HOME/.local/flutter以下に配置しています。 1 2 3 $ wget https://storage.googleapis.com/flutter_infra/releases/stable/macos/flutter_macos_v1.12.13+hotfix.5-stable.zip $ unzip flutter_macos_v1.12.13+hotfix.5-stable.zip $ mv flutter $HOME/.local/ 配置できたらPATHを通します。 私はzshを使っているので、$HOME/.zshrcに以下の行を追加しました。 1 2 # Flutter SDK export PATH="$PATH:$HOME/.local/flutter/bin" PATHを通したら、flutter --versionでちゃんとPATHが通っているかを確認します。 Android SDKのインストール 公式サイト の手順ではAndroid Studioを入れろとのことですが、emacsを使う予定なので、Android Studioはインストールせず、Android SDKのみをインストールします。 Android Studioのサイト へアクセスし、DOWNLOAD OPTIONS をクリックしてCommand line tools onlyのところからmacOS用のCommand line toolsをダウンロード、Flutter SDKと同様に適宜配置してPATHを通すか、簡単にbrew cask install android-sdkとします。 私は今回はbrewで入れました。(Flutter SDKもbrewで配布されていますが、Flutter SDKは少し古かったので、公式からダウンロードしてきた方が良さそうです) brew cask install android-sdkをしたときにもメッセージが出ますが、android-sdkを使用するにはJDK 8が必要なので、brew cask install adoptopenjdk8としてJDKもインストールしておきます。 ...

‌ 2020年に入って早1週間が経過しましたが、皆様いかがお過ごしでしょうか。 一年の振り返り！みたいのはあんまりやるつもりがなかったのですが、あまりにもみんなやっていて目につくので、これはやった方が良い物なのか・・・と思い直し、遅ればせながら振り返ってみようかと思います。 1月 そういえば2018年振り返りみたいなブログ書いてないんですが、2019年は心おだやかに生きたいと思っております — nasa9084@某某某某(0x1a) (@nasa9084) January 3, 2019 twitterによると、2019年は心おだやかに生きたいというのが目標だった様子。あまり心穏やかには生きられませんでした。合掌。 そういえば昨年は年明け早々インフルエンザにかかったんでした。 一月はLOCALのイベントに行ったり、YAPC::Tokyoに行ったりしていた様子。ここ半年はカンファレンス/勉強会参加数も減ってきてしまっているので、ここらでちょっと頑張りたいところです。 2月 ONIconをやったり、自作ケーブルを作り始めたり。 gomaconfやcookpadtechconfもこのあたりだったようです。 3月 ペティナイフが欲しい — nasa9084@某某某某(0x1a) (@nasa9084) March 1, 2019 ペティナイフ、ネット上でもいろんな人が「便利！」って言ってて、しかしまぁ三徳で不自由してなかったんですけど、買ってみたら実際メチャクチャ便利で、正直三徳よりペティを使うことの方が圧倒的に多い。 LINE.goというイベントを開催したのも3月でした。 朝ご飯 pic.twitter.com/PLRDDJEOCY — nasa9084@某某某某(0x1a) (@nasa9084) March 4, 2019 ご神体は今も職場の机にまつられています。なんと今は鳥居もついています 4月 皆さん技術書典の進捗どうですか — nasa9084@某某某某(0x1a) (@nasa9084) April 2, 2019 今もまた、技術書典の進捗に追われています。 たいした意味もなく近所のコインランドリーで枕を洗濯した結果、ドラム式洗濯乾燥機がほしくなってる — nasa9084@某某某某(0x1a) (@nasa9084) April 12, 2019 この後勢いよくドラム式洗濯機を買いました。最高。 5月 PyCon mini sapporoが5月だったらしいです。GoConでしゃべったのもこのあたりだったらしい。 改めて。でかい。 pic.twitter.com/zO9TLfdhy8 — nasa9084@某某某某(0x1a) (@nasa9084) May 29, 2019 OSC19doも5末〜6始でしたね 6月 鰹節食べ放題 pic.twitter.com/c6ouIwcHis — nasa9084@某某某某(0x1a) (@nasa9084) June 11, 2019 ところで、まとめを書くのも疲れてきました。 7月 Golang 101を開催したのが7月だったようす。またやりたいんですが、会場が難しいですね。 進捗です pic.twitter.com/cbZGgdeHiA — nasa9084@某某某某(0x1a) (@nasa9084) July 27, 2019 次の技術書典に向けて、これの第二巻を書いています。 ...

明けましておめでとうございます。 本年もどうぞよろしくお願いいたします。 扨、もう一昨年になりますが、趣味サーバーのインフラをKubernetesで整えた件 という記事を投稿しました。 その後紆余曲折ございまして、これらを再構成しましたので、改めて記録に残しておこうと思います。 紆余曲折 まずは紆余曲折とは？という話から始めましょう。 当時、Kubernetes用のPersistent VolumeはGlusterFSを使用していました。最初はこれで問題なかったのですが、一部のアプリケーション(具体的にはRedmine)を動かしていく上で、非常に速度が遅い、ということが問題となりました。 調査の上、どうやら遅い原因がGlusterFSであり、Cephに置き換えることである程度速度を改善することができそうだ、という見込みが立ったため、前述の記事を投稿してから約二ヶ月後にGlusterFSをCeph RBDへと置き換えました 。 その後、NTT-X Store でSSDが安かったため、12台ほどSSDを購入、すべての物理ボリュームをHDDからSSDに置き換え、RAID1+0で再構成しました。 同時に、以前はローカルボリュームを直接使用していたOpenNebulaのストレージ部も分散構成にするべく、物理マシン上に直接Cephを構成、これをOpenNebulaとKubernetesでシェアする形にしました。 これでうまくいったか？と思ったのですが、どっこい、どうやらDL360G6のRAIDカードとSSDの相性(しかもファームウェア単位)が悪いらしく、一週間〜一ヶ月程度で、故障もないのにRAIDから抜けてしまう、という問題が発生しました。 on Kubernetes on OpenNebulaで稼働していた本ブログの運用にも影響が出たため、一旦本ブログを(今は亡き)CloudGarage へと退避、SSDの交換をNTT-X Storeへと申請しました。 その後無事SSDは新品交換され、その間に某社 から廃棄するということでいただいてきたDL360G7が三台ほど導入されたため、これを基盤として再度プライベートクラウド基盤を構築することと相成りました。 現在の構成 再構成した、とはいえ、構成は大きくは変わっていません。 IaaS基盤としてOpenNebula/KVMを使用しているのも変わりませんし、コンテナ基盤としてKubernetesを使用しているのも変わりません。 強いて言えば、本ブログのストレージは最近までSQLiteを使用していましたが、外部MySQLへと移行したくらいでしょうか。 物理層 物理サーバとしては前述の通り、DL360G7を使用しています。適当にメモリを増設しており、それぞれ次の様になっています。 8コア16スレッド、36GB 8コア16スレッド、47GB 8コア16スレッド、49GB メモリの量はできるだけそろえたかったんですが、計算が面倒うまくそろえることができませんでした。 OSはCentOS 7を使用しています。最初はCentOS 8でやろうとしたんですが、もろもろパッケージがうまくインストールできず、7に落ち着きました。なんとかなってくれ。 これらに、OpenNebulaおよびCeph MIMICをインストールしてあります。Ceph Nautilusにアップデートしたいんですが、安定しているのだろうか・・・ VM層 OpenNebula/KVMを使用したIaaSの上にVMをポチポチと立てられるようになっています。OpenNebulaのストレージはCephを使用しています。VMも基本的にはCentOS 7を使用しています。 また、DBやPrometheusなど一部のアプリケーションをVMとして構築してあります。 以前はK8s上でPrometheusなども管理していたのですが、(主にストレージの)管理が面倒だったので、今回はVMにDockerをインストールして個別に起動しています。 コンテナ層 コンテナ基盤はKubernetesで、相も変わらずKubespray を使用して構築しています。便利便利。現在はKubernetes 1.16.3です。 PersistentVolume用のStorageClassはPM上のCephをOpenNebulaと共用で使用しています。手前味噌ですが、Ceph RBDをKubernetesのStorageClassとして登録する を見ながら設定しました。 Service type LoadBalancerの実装としてMetalLB を、Ingress実装としてNGINX Ingress Controller を導入してあります。また、HTTPSの証明書を自動設定するため、cert-manager を導入しています。以前はうまくインストールできないことがあり困ったりもしたのですが、今回は特にトラブルもなくスムーズに導入できました。だいぶCRDの構造が変わっていたので、以前導入していて、再度構成する必要がある人は注意が必要かもしれません。 証明書を取得する方法はDNS01で、CloudFlareを使用しているのも変わりません。

本記事はGo2 Advent Calendar の20日目の記事です。昨日はyaegashiさんによる、jsonx.go でした。 皆さんはOpenAPI Specification というモノをご存じでしょうか。OpenAPI SpecificationはJSONまたはYAMLでREST APIを表現するための仕様で、現在バージョン3.0.2 が最新です。いわゆるSwagger の後継で、バージョン1系、2系がSwagger、3系以降がOpenAPI、ということになっています(Swaggerなら聞いたことがある/使っているという人も多いのではないでしょうか)。 OpenAPI Specificationは人間にも機械にも(比較的)読みやすい仕様書として、コード生成や、ドキュメントページの生成に使用することが可能です。 個人的には専らコード生成に使用しており、Go言語向けの実装としてgithub.com/nasa9084/go-openapi (以下go-openapi)を実装・公開しています。 go-openapiは2017年ごろから細々と実装を続けており、(多分)二番目か三番目には古いと思われるOpenAPIのGo実装です。 基本的にはただひたすらOpenAPIのオブジェクトをGoの構造体として定義、値のバリデーション関数を用意しているといったもので、特別な機能はほとんどありません。 YAMLのパーサも、go-yaml/yaml を使用しており、自前では実装していません。 そんな中、@goccy さんが、encoding/jsonとコンパチなインターフェースを持ったYAMLパーサを開発した、という話を耳にし、これを機に、とgo-openapiの実装を一から書き直し始めました。 もともと、パースは完全にgo-yaml/yamlに依存しており、Unmarshal系のメソッドも実装していなかった(途中から全部書くのはつらかったので・・・)ため、一部バリデーションに必要な関数を埋め込んだりもできなかったので、書き直したいとは思っていたのです。 現時点ではまだマージしておらず 、書いている途中なのですが、大きな変更点として次の様なものがあります。 もともとパブリックだったフィールドをすべてプライベートに変更し、ゲッターをはやした 各構造体に対応するUnmarshalYAML()メソッドをすべてコード生成するようにした YAMLパーサはgithub.com/goccy/go-yaml に乗り換えた rootオブジェクトを各構造体に埋め込むことで、バリデーションをとりやすくした 今後はよりコード生成に便利なメソッドを追加していきたいと思っています。 時間の都合で今日はここまで。技術的な話が全然無い記事になってしまった・・・

buildersconは「知らなかった、を聞く」あるいは英語で “Discover Something New"をスローガンとした、IT技術者向けの技術カンファレンスです。2016年、2017年、2018年、2019年と@lestrrat さんが主催として開催してきて、私もコアスタッフとして関わってきました。 そんなbuildersconですが、2020年は子育てで多忙な@lestrratさんに代わり、私(@nasa9084 )が主催として開催に向けて準備を進めていくことになりました！ まぁ、今のところはやるぞ！という話だけで細かい話はこれからですが、皆さんどうぞよろしくお願いいたします。

昨日のこと。jszwedko/go-circleci というパッケージを使用してCircleCI EnterprizeのAPIを叩くという処理を実装していたのですが、どうにもうまくいかない。正直に言ってこのパッケージはドキュメントがしっかりしている、という訳ではないし、エラーメッセージを見ても何がだめなのか(そもそも現在使用しているCircleCI Enterpriseで使用できるかもよくわかっていなかった)わからない。 しかしまぁ、自分でHTTP requestを作ったりしてあれやこれややるのもまぁ面倒であるので、なんとかデバッグしたいと思ったのですが、外部のパッケージをフォークして変更を加えてデバッグする・・・という様なことはもちろんやりたくないわけです。 このパッケージは*http.Client を指定できます。*http.Clientはインターフェースではなく構造体なので、別の実装に置き換えるということはできません。が、その実装はほぼほぼ後述するhttp.RoundTripperなため、http.RoundTripperをラップして、HTTP requestとHTTP responseをログに吐けばまぁ、何が問題かわかるだろう、と考えました。 そんなモノは誰かがすでに書いているだろう、というのはさておき、http.RoundTripperを実際にいじってみるということはやったことがなかったので、勉強がてらnasa9084/go-logtransport なるものを書きました。 書いていく途中で、考えたことなど、記録に残しておくのも良さそうと思ったため、本記事とします。 http.Clientとhttp.RoundTripper Go言語でHTTPのリクエストを発行するには基本として*http.Client というものを使用します。簡便のため、GET 、POST 、Head についてはパッケージグローバルの関数も用意されてはいるのですが、これらも内部的にはパッケージグローバルで宣言されたDefaultClient という*http.Client が使用されています。 *http.Clientはゼロ値で使用できるようにまとめられた構造体で、DefaultClient は*http.Client{}と宣言されています。 普段はこの*http.Clientを使用してHTTPの通信を行うわけですが、実は*http.Clientはそれほど多くの機能は持っていません。実際、持っているフィールドはたったの4つ(Go1.13時点)しかないのです。*http.Clientはリダイレクトやクッキーなどの一部の処理だけを受け持っていて、実際のHTTP通信のほとんどはフィールドとして保持しているhttp.RoudTripperが行います。 http.RoundTripperはインターフェースとして定義されていて、自由に差し替えをすることができます。特に指定していない場合は*http.Transportがデフォルトの実装として使用されます。 Goの他の標準パッケージの例に漏れず、http.RoundTripperは非常にシンプルなインターフェースで、次の様に定義されています。 1 2 3 type RoundTripper interface { RoundTrip(*Request) (*Response, error) } RoundTrip()がHTTP requestを受け取り、HTTP responseを返します。つまり、requestのログをとり、子RoundTripperのRoundTrip()を実行し、Responseのログをとってそのまま返す、という様なラッパーを書けば良さそうです。 1 2 3 4 5 6 7 8 9 func (t *Transport) RoundTrip(r *http.Request) (*http.Response, error) { // Requestのログをとる resp, _ := t.Transport.RoundTrip(r) // responseのログをとる return resp, nil } 実際にrequestとresponseのログをとるには、net/http/httputilパッケージのDump系関数が使用できます。今回はクライアント側の実装なので、httputil.DumpRequestOutとhttputil.DumpResponseを使用します。 テスト 実装の詳細はそれほど難しい内容ではないのでさておき、テストをどう書くか、という話をしましょう。 HTTPに関連したテストを書くとき、Go言語ではnet/http/httptestを使用すると便利です。 テストを書くにあたり、最初は子RoundTripperをモックして、適当にResponseを返すモノをつくればよいか、と思ったのですが、いい感じにテスト用のResponseを作成するのは面倒そうでした。 そういえば今日、http.Transportにロガーを仕込むの書いてみて、テストを書くのにRequestとResponse生成したいな・・・って考えてhttptestにないか見て、なんでないんや！って一瞬おこだったけどhttptest.Server使えばええんや、とすぐに思い直したのでアレがそれでそんな感じでした(とりとめが無い — nasa9084@某某某某(0x1a) (@nasa9084) October 31, 2019 しかし素直にhttptest.Serverを使えば、クライアント側では一切テスト用に特殊な実装を使用することなく、普通にリクエストをしてレスポンスを受けることができます(httptest.Serverは日常的に使っているのに、なぜ忘れていたのか・・・)。 これを使用して、シュッと適当なハンドラをサーブしてことなきをえました。 ...

TL;DR s == ""とlen(s) == 0は等価 文字列比較か、長さ比較か Go言語で文字列が空かどうかを調べるには次の二つの方法があります。 1 2 3 4 5 6 7 8 9 // 1: 文字列を空文字列と比較する if s == "" { // do something } // 2: 文字列の長さが0かどうか調べる if len(s) == "" { // do something } 標準パッケージ・サードパーティパッケージともに、どちらの書き方も散見されます。 どちらを使うのが良いのでしょうか？ 答えはどちらでも良いだそうです。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 package benchmark_test import "testing" var somethingString = "hogehogefugafuga" func BenchmarkCompareString(b *testing.B) { for i := 0; i < b.N; i++ { if somethingString == "" { } } } func BenchmarkCompareStringByLength(b *testing.B) { for i := 0; i < b.N; i++ { if len(somethingString) == 0 { } } } このコードに対して go tool compile -Sした結果が以下。 BenchmarkCompareStringとBenchmarkCompareStringByLengthでは同じ内容となっています。 ...