Pythonista で近年はGo言語にハマっています。

package main import "log" type S struct { value interface{} } func (s *S) Get() interface{} { return s.value } type Value interface { Get() interface{} } func Do() Value { var res *S if false { res = &S{123} } return res } func main() { v := Do() if v == nil { log.Fatal("v is empty!") } log.Println("v is not empty:", v) } 空判定に引っかからず、有意な値を返されたという処理フローになっちゃうという問題。 Typed-nil問題について これは「Typed-nil」問題といっ

ソフトウェアの品質 通常ソフトウェアの品質を高く保つには以下の手続きを継続する必要があります。 イディオムやアルゴリズムを適切なものを正しく選択してコードを記述する コンパイルにより誤りを検出・修正してコードの正確さを高める 静的解析により誤りを検出・修正してコードの正確さを高める 各種テストの実行により誤りを検出・修正してコードの正確さを高める レビューにより誤りを検出・修正してコードの正確さを高める なぜ継続する必要があるのかというと、ソフトウェアをゼロバグでリリースするのは困難だからです。リリース後実運用にて発覚する問題点があれば上記の手続きをもう一度踏む必要があるからです。 ソフトウェアの品質を下げる要因のひとつが「ポカ」で、ざっくりいうとこれは「うっかり正しくない記述をしてしまったりする」ことです。 実は多くの種類があるポカ ランタイム検出項目のうち、言語処理系によってはコンパイ

andlabs/ui、lxn/walkは簡素なウィジェットセットだけをサポート。fyne、Qtベースは豊富なウィジェットセットを持つ。いずれも少人数でメンテしていることを考えると、コンパクトなツールキットで活発な活動中のものが品質面でおすすめです。 IMEサポートの有無は日本語圏でのGUI提供において重要なファクター 英語圏生まれのGUIライブラリの多くはIMEサポートをあまり考慮していない GLFWはIMEサポートのPRが何年も取り込まれない状況がつづいている HTMLベース（ChromeやWebView）ならIMEサポートを内包している 自作系はどうしてもギョッとする挙動や細かく期待しない挙動にちょくちょく出会ってしまう（例えば日本語のワードラップ未対応など） HTML系はUIを構築していく上でのほとんどのケースで細かい問題に対する解決策がちゃんとある クロス環境対応ということであれば

マルチコア化の未来予測 半世紀前にSF映画「2001年宇宙の旅」に登場するコンピューターHAL-9000が並列コンピューティングの未来を示しました。マルチコアで構成されたコンピューターの物理コアを取り除いてもすぐにクラッシュせずに性能ダウンして処理が継続するという演出がありました。 当時ですらシングルコアコンピューティングの限界が予想されていて、現状のコンピューティングがマルチコア化しているという未来をしっかり予測できていたことがわかります。 演出はコア数に応じてコンピューティング性能がスケールしていることを表現しています。これはマルチコアスケールするソフトウェア実装の未来を示していたと思います。 シングルコア性能向上の頭打ち 2003年以降あたりはCPUの動作周波数が伸び悩み出したところ。 https://queue.acm.org/detail.cfm?id=2181798 より その

https://www.kbaba1001.com/entry/2021/09/17/073149 （該当記事が削除されました） RubyのサービスをGoで置き換えるのは３倍人手がかかる 何するにも機能不足 JSONの読み書きにわざわざ構造体書くの面倒 同僚がGoを選ぼうとしたら愚かな選択ですねと答える サーバーサイド開発にGoを使うのは危険 っぽい内容だったかと。 だいぶGoの特徴や既存の言語との考え方の違いが広まってきてるのかなぁと思っていた矢先だったので十年くらい前のような指摘をあえて今されていてびっくりした。 正直、ここに書かれたようなヘイト項目は既出すぎるので、もし影響の大きい項目を多くの人が同様に嫌っているならばGoはここまでの人気のある処理系になることはなかったと思う。（もしくは多くの人が嫌ってはいるが影響の小さい項目ということ） Goは出た当初、こういうヘイトが世界中のブロ

Go 言語での便利な Tips を紹介していきます。 「GO111MODULE=on」を設定しよう！ 最近、いろんなサードパーティパッケージが Go モジュールサポートへの修正が進んでいます。 その中で、GO111MODULE=auto のデフォルト値のままだと go get に失敗するものが目立つようになりました。Go1.16 からは「GO111MODULE=on」がデフォルト値になる予定なので、それまでは各自「GO111MODULE=on」を設定しちゃいましょう！ ドキュメント通り「go get」してもうまくインストールできない場合は「GO111MODULE=on」を指定してリトライしてみてください。 ちなみに OS に関係なく環境変数を書き換える便利なコマンドがあります。

以前書いた Go初心者が気を付けること に解説をつけてみようと思いました。 情報検索や環境構築 golang.jpを見に行ってしまう この辺りはググラビリティの問題ではあるんですが、まだまだ「golang.jp」にたどり着いちゃう人が多いんです（そのせいでなかなか検索ランクも下がらない）。 「golang.jp」はGo0.9の頃の情報からほとんどアップデートされていません。なので今のGoとのミスマッチな情報がまばらにちりばめられている状態ですので見に行かない方がスムーズにGoを学べると思います。（たまたま現状と変わっていない情報を読み物として読むくらいなら良いのですが・・・。） 一応有志のランディングページに指し変わったので、この混乱は収束すると思います。 Golang（ごーらんぐ）と呼んでしまう(by hogedigo) 「Go」というワードのググラビリティの低さから「golang」で検

「ヌル参照の考案は１０億ドル単位の過ち」と語ったホーア氏（Goの並列処理モデルCSPの考案者でもあります）。そしてモダンな言語処理系は「ヌル安全」を持つのが流行です。しかし、Goには完全な「ヌル安全」の仕組みを持ちません。 Goのメモリ安全機能 もちろんGoは完全なヌル安全とは言えないまでもヌルポ参照対策や不正なメモリ参照を防ぐいくつか考慮した仕組みや慣習を持っています。 ポインタの算術移動を許さない言語仕様 確保するメモリは全てゼロ値で初期化済み エラーがnilなら有効な値を返すという慣習 必須のエラーチェックがヌルチェックを兼ねている これらによりGoは完全に「メモリ安全」であり、「ヌル安全まであと一歩」までの仕組みを持っています。それでもヌルポ参照は「ランタイムパニック」という形で現れます。 ランタイムパニック Goでは「ランタイムパニック=コードの不備の通知」です。 多くのコードの

Goにはioパッケージにまつわるbyte単位のストリーミング処理機能が素敵なので、その良さを紹介してみようと思います。 io.Reader/io.Writerについて ioパッケージにてReaderとWriterのインターフェースは以下のようになっています。 type Reader interface{ Read(b []byte) (sz int, err error) } type Writer interface{ Write(b []byte) (sz int, err error) } 読める書けるだけのシンプルな定義です。このシンプルさが素敵なんです。 派生インターフェース io.Seeker io.Closer io.ReadSeeker io.ReadSeekCloser io.WriterSeeker io.ReadWriteSeeker io.ReadCloser io

WebSocketのツラミ 中継サービスの対応がないと切れる ルーターによっては長時間アクセスがないと切れる 切れたら繋ぎなおすのはクライアントの実装次第 セキュアにつなぐためにはサーバーもクライアントも新バージョンのサポートが必要 接続数が膨れず、安定して接続を維持するのには結構ノウハウが求められる 単純に切れたら即繋ぐでは中継やサーバーに問題が発生することもある そこでEventSourceですよ メジャーブラウザでサポート・互換性も高い プロトコル仕様がただのHTTPロングポール＋アルファ なのでほとんどの接続経路で中継トラブルが少ない JSのEventSource実装がセッション維持を頑張ってくれる サーバーから切断されたら再接続をしようとする 特にGoなら標準機能でさっくりサーバーが書ける クライアント実装 let es = new EventSource("/sse"); es

循環インポートの問題点 現代のプログラミング言語の多くは１パスでプログラムコードを解釈します。インタプリタ型は当然としてC/C++も例外ではありません。つまり「コンパイル・実行」されるまでにソースコードを２度パースすることはありません。 さらにプログラム言語の多くは多重定義はバグの元なのでエラー扱いになります。なので対策の無いヘッダーファイルをincludeした時、再度同じヘッダーファイルが参照された場合に「多重定義」になってしまいます。 C/C++ではそのような「多重定義」を回避するために「インクルードガード」という対策をヘッダーファイルに施します。C/C++ではプリプロセッサという仕掛けに依存していてコンパイラは重複する定義がそれぞれどこのファイルを読み込んだ結果かを判別できません。なので「インクルードガード」という対策がヘッダーに必要なのです。 しかし、「インクルードガード」は方針が

Kryptonのスマホアプリの配布が終了してしまいました・・・事実上この仕組みの利用はできなくなっていくでしょう。残念です。 SSH/U2F認証をスマホで代行する「Krypton」というツールが便利でとても気に入っています。その使い方と良さをご紹介します！ 以前は「Kryptonite」という名前でSSH認証の代行の仕組みだけをサポートしていましたが、現在は「Krypton」という名称でU2F認証の代行をメインにおいているようです。 オープンソースでZeroTrustインフラにおいてセキュアを保つ仕掛けがウリで、一昨年Akamaiに吸収されました。 機能 一般ユーザー向け U2F認証代行 開発者向け SSH公開鍵認証代行 Gitのコミット署名代行 いずれも、「秘密鍵で署名をする機能」の応用です。 概念的にはU2Fドングル内にあるセキュアチップと呼ばれる「耐タンパー性の秘密鍵保持・署名ハード

この記事はGo 言語 Advent Calendar 2023のシリーズ２の４日目の記事です（穴があったので入りました！）。 goroutineの特徴 コルーチンをベースにコルーチンの以下の点を改良 言語組み込みワード「go」にて起動できる M:Nスレッドシステム採用によりマルチコア分散処理が可能 ブロッキングを検出したらネイティブスレッドが独立 プリエンプティブ性を追加(Go1.14以降) 以上により、goroutineスレッドシステムはコードを書く人にとって「ネイティブスレッド」の感覚で実装を書くことができ、「コルーチン」のようにメモリやタスクスイッチ負荷が小さく、「コルーチン」のような面倒な制約（期待するレイテンシ以上にCPUビジーにしてはいけないなど）も無いといういいとこどりのスレッドシステムになりました。 ネイティブスレッドライクによる特性 ネイティブスレッドを使ったプログラミン

ProやEnterpriseエディションの場合 Win＋Rから「gpedit.msc」を起動。以下の画面を参考にシンボリックリンク作成権限をユーザーに付与。Windowsにログインしなおすことで有効に。 Homeエディションの場合

この記事はGoのコードをいくらか書いていてもっとGoらしい書き方に興味を持ってからみてね！（Go初見で読んでも響かない内容です） Goは「シンプルで迷いなく書ける」というのが売りではあるのですが、 実際書き始めると、「あれ？これどうやって書くほうがいいの？」ってポイントにちょくちょく巡り合います。そのようなポイントを思い出しながら今思うベターな書き方を紹介しようと思う。 err変数束縛について err変数の受け取りを複数回繰り返していると「:=」だけで書けないという状況に出会うでしょう。 err := funcA() if err != nil { ... } err := funcB() // <- コンパイルエラー： "no new variables on left side of :=" if err != nil { ... }

Goのエラーハンドリングが採ったスタイル 多値返し 直積（関数の返値とエラーを両方返す） try-finallyをdeferという機構でカバー panicはプロセスを落とすためのもの Goはこの戦略でエラーハンドリングを行うとしましたので、「多値はなぜタプルじゃないんだ？」、「直和（返値orエラー）で十分じゃ？」「panic-recoverでtry-catchできそう？」などいう様な他の処理系の風習を持ち込むことは意味がありません。そしてそれらの提案の多くはすでに検討されリジェクトされてきた経緯があります。 「try組み込み関数」プロポーザルなんかも検討されマージ直前くらいまで進んだこともありますが、「Goのエラーハンドリング」にとって一長一短がありました。その欠点課題は解決できずに最終的にリジェクトされました。 「多値返し」は実にCPUフレンドリーな機構で、C言語の関数呼び出し規約にちょ

CGOフリーなSQLiteドライバーmodernc.org/sqlite は 以下のC記述をGoにトランスレートする仕組みで作られたPure-GoなSQLite3ドライバーです。 https://gitlab.com/cznic/ccgo https://gitlab.com/cznic/libc これを利用して型安全なORM「ent」でつかう方法をまとめてみます。 ドライバーラッパー entがsqliteドライバーに要求するForeignKeysフラグがmodernc.org/sqlite では標準でスイッチできないのでそこをサポートするコードを差し込みます。幸い、ドライバー名はsqlite3ではなくsqliteで重複していないのでsqlite3で登録することでentがサポートするドライバー名に合わせることができます。 sqlite_driver.go package main impo

よく知られる良さ ネイティブコード出力で実行効率が良い コードの可読性を重視している 開発でよく使うツールがバンドル クロスビルドが簡単にできる コンパイルが遅くない（LLライクにrunできる） 並行処理の抽象化を組み込み言語仕様にもつ メモリ安全である 上記の一部に解説を加えつつあまり言及されない良さを以下にまとめます。 依存解決が最小限で決定的 ここにも書きましたが、Goの依存解決は常に 最小限のダウンロード 最小の範囲でのみビルドを実行 だけが走ります。これを一度体験すると、従来のパッケージ依存管理が冗長で余計なものをビルドしすぎることに気づくでしょう。これらに相当の時間を奪われているのです。 また、Goモジュール機構によりそのバージョン選択は決定的に安定動作するバージョンに決められます。このことのメリットは数ヶ月後のリビルドで安定してビルドできることで実感できるでしょう。 開発環境

Goのプロジェクトをどの様なファイル構成で配置すれば良いか読み物が少ないという指摘を見たのでまとめてみようと思う。 GOPATHについて Go1.16がリリースされたことでGo-Moduleによるプロジェクト構成が標準で推奨されることになりました。（Go1.11までさかのぼってGo-Moduleは使える様になってます） Go-Moduleモードでは「GOPATH配下にプロジェクトを置かなければならない」という制約からは解放されています。なので、実質GOPATHはどこを指していても構わないし設定されていなくても「ユーザーホーム/go」というデフォルトの場所が決まっているので開発できます。 おすすめの環境変数設定は以下の２つだけ。 「GOPATH=~/.go」（WindowsはGOPATH=％USERPROFILE%\.go） 「PATH=＄GOPATH/bin:$PATH」（Windowsは