Posts

emacs yasnippet の snippet を対応させるモード名に / 等のファイル名に使用できない文字がある場合

emacs で snippet を管理するパッケージに yasnippet がある。 yasnippet はメジャーモード毎に snippet を登録しておき、 編集中のメジャーモードに合せて snippet を呼び出すことができる。 yasnippet に snippet を登録するには、 変数 yas-snippet-dirs で指定しているディレクトリ内に メジャーモード名のディレクトリを作成し、 そのメジャーモード名のディレクトリ内に snippet 情報を記述したファイルを置く。 これにより、 yasnippet のロード時、あるいは M-x yas-reload-all 実行時に、 snippet が yasnippet に登録される。 ここで問題がある。 説明した通り

LuneScript の開発工数

LuneScript の開発を続けて約 2 年経過。 2年間ずっと開発し続けているわけではないけど、 かなりの時間を LuneScript の開発にあてている。 そんな訳で、今回は LuneScript の開発工数を概算してみる。 もちろん、作業時間の記録なんて面倒なことはしていないので、 あくまで概算である。 開発作業 LuneScript に限ったことではないが、 github で個人開発する際は、 だいたい次のように開発を進めている。 作業項目(TODOリスト)を doc/todo.org にリストアップする TODOリストを順次潰して

Google Cloud Functions の deploy で 'missing dot in first path element; Error ID: 3182a79f' エラー

GCP から「Go 1.11 は使えなくなるから Go 1.13 にして」という通知があったので、 忘れないうちに Go 1.13 にして deploy をしたら、次のエラーが出た。 ERROR: (gcloud.functions.deploy) OperationError: code=13, message=Build failed: go mod: -require=xxxxxx/hoge/foo@v0.0.0: invalid path: malformed module path "xxxxxx/hoge/foo": missing dot in first path element; Error ID: 3182a79f どうやら、モジュールの先頭ディレクトリは FQDN の形式しないと NG になったようだ。 いままでは . を含まない適当な名前にしてたんだが、 「xxxxxx/hoge/foo の xxxxxx に . が含まれてない == FQDN ではない」、 ということで NG っぽい。 xxxxxx を github pages の自分の

LuneScript の Google 検索ワード

先日、 Google 翻訳で lunescript が固有名詞として認識された可能性について ネタにしたが、 どうやら本当に lunescript が固有名詞として認識されたのではないかと思われる。 というのも、 google の検索バーに lunesc まで入力すると、 上のように lunescript が候補に挙げられる。 google の単語として登録されたからといって、 LuneScript の認知度が上った訳でもないが、何となく嬉しい。 なお、 lunescript を検索した際の関連ワードは次の通り。 ちゃんと lua を認識している。 念のため、次の状態で確認している

デュアルブートの ubuntu を upgrade したら windows の BitLocker が PIN の認証失敗するようになった

イマドキは少数派だと思うが、 PC に ubuntu と windows のデュアルブートを設定している。 さらに面倒なことに、 windows は BitLocker で暗号化 & PIN 認証を設定している。 そして、この状態で ubuntu を apt upgrade したら、 何故か windows ブート時の BitLocker の PIN 認証が失敗するようになった。 PIN を間違えているはずはないのだが、何度やっても PIN 認証が通らない。 しかたがないので、 BitLocker の回復キーを入力したところ問題なく起動した。 そういえば ubuntu の apt upgrade 実行時、grub の更新が掛った。 その際、

Go 言語 (golang) について思ったこと

Go の勉強を兼て「これ」を Go で作っていたんだが、その時感じた Go の特徴をまとめておく。 Go は気軽に書けるのに、非常に高い実行パフォーマンスを出せる使い勝手の良い言語だと思う。 また、パッケージマネージャを言語自身に内蔵しているため、 拡張パッケージが揃っていて、今後さらにパッケージが充実して使える言語になるだろう。 こんな様なことは、もう誰もが書いていることだと思うので、 以降では、もう少し違った角度で Go につい

LuneScript の Google 翻訳

以前 lunescript の紹介記事を書いている時に、 lunescript の日本語訳がふと気になったんで調べていたんだが、 その時の Google 翻訳の結果が衝撃的だった。 <https://ifritjp.github.io/documents/lunescript/tutorial1/#headline-3> で、久し振りに Google 翻訳で lunescript を翻訳してみた。 その結果は次の通り。 めでたく lunescript の日本語訳が lunescript になった。 これは、 LuneScript が Google に固有名詞として認識されたということだろうか? それとも、該当する単語が登録されていないから、 とりあえずそのまま表示しているだけなんだろうか?

dot のレイアウト指定

tunnel ツールのネタを書いた時、 dot を使ってグラフを作った。 dot は手軽にグラフを書ける便利なツールだが、 レイアウト制御に難があると思う。 グラフ作成ツールの利点と欠点 dot などのグラフ作成ツールの利点には次が挙げられる。 ノードのリンクを指定するだけで、後はツールが良い感じにグラフを自動で作成してくれる。 パワポ等でグラフを作成するのと比べると、これは大きな利点だ。 そして多くの場合、ツールが作成するグラフは、それなり

go の proxy server (github.com/elazarl/goproxy) の使い方

go で proxy server を建てるには、 github.com/elazarl/goproxy を使うと簡単に実現できる。 https://github.com/elazarl/goproxy github の readme を見れば、簡単な使い方が載っているので特に問題はないだろう。 ただ、一点だけハマったポイントがあるので書いておく。 proxy 環境下で goproxy を使う場合の注意点 1 2 3 4 5 6 7 8 9 10 11 12 13 package main import ( "github.com/elazarl/goproxy" "log" "net/http" ) func main() { proxy := goproxy.NewProxyHttpServer() proxy.Verbose = true log.Fatal(http.ListenAndServe(":8080", proxy)) } github の readme にサンプルとして上記コードが載っている。 基本的にこれで問題ないのだが、 proxy 環境下で動かす場合には注意が必要だ。 多くの場合、 proxy 環境下

Tunnel/Reverse Tunnel over websocket を作った

とある理由から 「Tunnel/Reverse Tunnel over websocket」 が必要になったので作ってみた。 「Tunnel/Reverse Tunnel over websocket」 が何かというと、 「websocket を tunnel にして別の TCP 通信を通すもの」だ。 「Tunnel/Reverse Tunnel over websocket」 とは 「Tunnel/Reverse Tunnel over websocket」を少し具体的にいうと、 次のような構成で通信を可能にするモノだ。 frame