Vimmer、Visual Studio Codeを使う - 詩と創作・思索のひろば
まだ汚れを知らない若者だったころに「プログラムはね、これを使って書くんだよ」と言われて以来Vimは友達だと思ってずっと（15年くらい）使ってきたが、最近は、とくに新しく何かを書くときにはVSCodeを使うようになってきた。コードを書く間隔が広がってきたせいか、新しい技術や言語に対応することができておらず、なんか最初からいい感じになってるエディタを重宝する。歳を取ってきたからなんだろうな、と素直に思うけれど、自分向けになにかをカスタマイズすることにあまり熱を感じなくなっていて、すでにあるよいと分かっているものに自分を調整していくことを選ぶようになってきた。 とはいえ身体はVimに慣れきってるのでVSCodeを使い始めたときはVSCodeVimを使っている……いた、というのが今回の話。よくできてるとは思うが、とにかくu（アンドゥ）の挙動が本家と違うのがどうも身体に合わない。逆にストレスが高まっ
GPT-2でブログ記事のタイトルをTogetterまとめ風にする「面白いのでやってみて」 - 詩と創作・思索のひろば
オレ定義だけど Togetter まとめ風というのはこういうやつ。 散歩で急にシロクマと会っても食べるのは肉だけにしたほうがいい「肝臓1gに含まれるビタミンAが致死量を超える」 - Togetter まとめタイトルの終わりに誰かのツイートの引用を挿入する、という形式。よくできたもので、誰かの生の声が入っているだけで、感想やハイライトを抽出し、ちょっと気を引くことができる。まあ一種の演出で、ニュースサイトがやってることもある。 タイトルでアテンションを奪い合わなければならない宿命におけるクリック最適化の手法ということだろう。今回はこれを真似してみることにする。すでに書かれた自分のブログ記事に、括弧書きでセリフっぽいものの引用を捏造して付け加えることで魅力がアップするのか、という実験だ。 こういう生成系のタスクも、とりあえず HuggingFace+Google Colaboratory でや
コードレビューのときに見ているところ - 詩と創作・思索のひろば
あるときコードレビューするときにどういうところ見てるんですか？ と訊かれてたしかに自分でもあまり言語化したことはなかったな、と気づいたので簡単に書いておく。 変更意図が要求に沿っているか そもそも実現しようとしていることが、ユーザやプロダクトオーナーの要求に沿っているか。モデリングや実装のコンテキストを自分でも把握しておく。 関連する別の変更やイシューなど、自分が知っていて相手が知らない有意義な情報があったらコメントする。 モデリングが妥当か モデルによって意図が表現できているか。仕事が適切な粒度で明確に切り分けられているか。意図のない共通化がなされていないか。 わかりやすい名前がつけられているか。ここが混乱していると何かがよくないサイン。既存のコードがすでに……ということもある。そういう場合は改善できそうな道筋について議論できるとベター。 仕事にあったインタフェースになっているか。テスト
Googleカレンダーをターミナルからキーボードで操作する - 詩と創作・思索のひろば
全部キーボードで済ませたいシリーズです。 多忙な現代人の一日はその日の予定チェックから始まるわけです。普段であれば定期的な間隔で組まれたミーティングのリズムに身を委ねればいいわけですが、そこに非定型的なミーティングが紛れ込んでくる。これは採用面接など外部との機会であることが多く、そのぶん重要です。事前に入れてあるものを避けて予定を組もうとすると、参加者の数に応じて困難さが増していくので、ある程度は既存のものに被せて予定に招待してもらうことにしていると、いつの間にかダブルブッキングの嵐になっている。直前になって慌てて一方のミーティングに参加しないことを告げる……みたいなことを繰り返していてはいけませんね。 そういうわけで事前にカレンダーの重複を確認して、必要に応じて辞退したり再調整したりしたい。だけどそれを Google カレンダーのウェブ UI からマウスでポチポチやるのは非常につらい……
DevTools上でesbuildするChrome拡張を書いた - 詩と創作・思索のひろば
社内ではドキュメントの共有に Scrapbox が活発に使われており、するといきおい UserCSS や UserScript もさかんである。具体的には、/customize という共有のプロジェクトがあってみんなの自慢の装飾やカスタマイズが共有されている。これを個々人で import して使うんである。 こんな感じ。 自分の場合は /motemen/UserCSS/common に常に適用したいスタイルを書いておいて各プロジェクトから読み込んでいる。このページからさらに、共有プロジェクトや他人の個人プロジェクトページからよさそうな設定を import している次第。 つまりは多段インポート。こういうことを続けていると、だんだんと読み込みの遅さが気になってくる。こういうのはバンドルすればいいのだけど、巷のツールを普通に使うことはできない。インポートしてるリソースに認証がかかっているからだ
SlackやGoogle Docsにページへのリンクを共有するなら圧倒的にcocopyが楽 - 詩と創作・思索のひろば
Scrapbox のような Wiki 的なツールでは URL にページ名が入ることが多く、URL を見るだけでどんな内容なのか想像がついてよい一方で、こういう URL を Slack や Google Docs のような別の場所に共有するとパーセントエンコーディングされた URL になってしまい意味がわからなくなる。日本語を書いていることだけが分かる状態。 マルチバイトしかないと本当にわからないね Slack がアクセスできない URL だと、プレビューも展開してくれないしね。かといってデコードした状態の URL を貼っても、変なところで途切れたりする。 ・（中黒）でリンクが途切れている 文字は難しい……。URL の解釈はものによって異なってくるのもまた困る。これはプレーンな文字列を渡しているのでこういう困難が出てくるのであって、最近はクリップボードでリッチなコンテンツを受け渡しすることが
Alfredの代替としてRaycastを使っている - 詩と創作・思索のひろば
新春ツール入れ替えシリーズです。macOS における Spotlight 的なランチャーツールとして Alfred を長いこと使ってきたが、最近 Raycast を使ってみてこれがよかったので、以来ずっと使い続けている。 Raycast - Supercharged productivity 開発者のための便利ツールという売り文句のようで、そういう点がまさに気に入った。 カレンダーの次の予定が表示される まずこれがいい。これだけで十分使える。ランチャーを起動したときにカレンダーの次の予定を表示してくれる。Enter でそのまま Meet や Zoom を開いてくれるのでキーボードから手を離す必要がない。 もともとカレンダーの確認には Dato を使っていたし今も使ってるが、これでミーティングへのアクセスがかなりよくなった。 コミュニティベースの Store で機能を追加できる https:
Goで知らないフィールドのあるJSONを取り扱う - 詩と創作・思索のひろば
野良 HTTP JSON API クライアントを作ってると、API が返してくる JSON の形に確信が持てないし、「これ何に使うんだろ」みたいなフィールドもあったりして struct にエンコードするのをサボったりする。 そういったコードがライブラリとして使われる余地を残すとすると、struct で表現されていないデータにも何らかの方法でアクセスできるようにしておきたい。こういうパターンあるんじゃないかと思うが、みんなどうやってるのか分からなかったのでメモ。 まあ素直に、json.RawMessage を struct に持たせておくのが一番よいだろう。冗長にはなるが、構造体の定義されたフィールドに便利なデータはあるし、より詳細に見たいなら RawMessage 経由で生データを見ればよい。ということにする。また、RawMessage を保持している場合は JSON 化したときにこれをそ
2022年、タスク管理をTickTickで行う - 詩と創作・思索のひろば
TikTok じゃないよ。 TickTick: Todo list, checklist and task manager app for Android, iPhone and Web チームのタスクマネジメントに Asana を使っていたのでそれに合わせて個人タスクもそこに積んでいたのだけど、Asana も積極的に使いたいわけではなかったし、年末から別のものを探していた。新しく選ぶなら一番重視したいのはやはり、カレンダーの予定の隙間にタスクを挿入できること。前にも自前で実装したことがある（カレンダーでタスクを管理することとその実装 - 詩と創作・思索のひろば）けど、こういうのはちゃんとビジネスとしてやってる人びとに任せたほうが改善もメンテもされるしいいのは当然。 いくつか見てみたところ、TickTick というのがよかったのでこれを使ってみている。いわゆる普通のタスク管理ツールという感
ISUCON11予選敗退（92604点、30位） #isucon - 詩と創作・思索のひろば
ISUCON11 オンライン予選 全てのチームのスコア（参考値） : ISUCON公式Blog チームは カラアゲネイティブ-ng。92604点、30位だった。通過ラインが 106094 点だったのでもうひと伸びあれば、というところで悔しい。 メンバーは去年と同じく songmu & toricls。予選の問題を見たときは AWS、IoT、時系列データベース、おれらの得意分野じゃんとか言って笑ってた。 「クラウドネイティブだから再起動とか言われてもわかんない」とか言って笑ってたあの頃に戻りたい— 美顔器 (@motemen) 2021年8月23日 やったこととおぼえていること: 実装は Go。 今回は去年の個人的な反省を活かして自分が構築、songmu & tori でアプリケーションを見る、という感じで進めていった。といっても songmu さんの秘伝の Makefile を頼りに見様見
mod_perlのDockerイメージをghcr.ioに上げた - 詩と創作・思索のひろば
趣味で mod_perl の Docker イメージを作っています。 Docker Hub の無料版における autobuild が終了となり、GitHub Packages Container Registry に移行することにした。 https://github.com/motemen/docker-mod_perl/pkgs/container/mod_perl {perl_version}-{httpd_version}-{mod_perl_version} て感じのタグ付けです。httpd ベースなので OS のバージョンは勝手に上がる（！） リポジトリでは、Perl のバージョンごとにディレクトリを掘っている。これを Autobuild するにはウェブからポチポチするのが必要で、バージョンを増やすたびに一つひとつ追加するのが面倒だったんだけど、GHCR なら GitHub Ac
Goでプライベートネットワークへのアクセスを制限する - 詩と創作・思索のひろば
Go において、いわゆる SSRF (Server Side Request Forgery) を防ぐような目的で、内部 IP アドレスにアクセスしない HTTP クライアントを作るには hakobe/paranoidhttp が便利だった。ただ、近年ではこれが作られて以降の Go 側のアップデートとして、net.Dialer.Control の登場がある（Go 1.11 より）。 type Dialer struct { ... // If Control is not nil, it is called after creating the network // connection but before actually dialing. // // Network and address parameters passed to Control method are not //
作業ログと履歴をシンプルに共有できる furoshiki ってツールを書いた - 詩と創作・思索のひろば
おはようございます。この記事ははてなエンジニアアドベントカレンダー2017の25日目の記事です。昨日は id:alpicola さんによる 社内で機械学習ハッカソンを開催しました でした。 サービスのデプロイをはじめとして、チーム内の開発者が共通して担当すべき業務というのはさまざまに存在し、基本的に定型化されているものですが、開発者が手元で実行するなど自動化までは行えていないような場合、以下のような点が問題になります。 作業履歴が共有されない 同様に作業中に意図しない不具合が生じた場合、エラーログが実行した環境にしか残らない それぞれ、デプロイのタイミングを Mackerel や Slack に投稿して共有する、Gist にエラー時のログを貼るなど、チームに合わせた方法が存在していることと思います。また作業環境を同一にするため、チームにデプロイサーバを用意して作業はそこで行う、という方法も
チャンネルを使って、決まった数のリソースをgoroutine間で共有するパターン - 詩と創作・思索のひろば
生成が重いリソース（や重い処理の実行権）を goroutine 間で共有し使いまわすようなパターンです。よく知られていて名前がついていそうだけど、ぐぐっても分からなかったので書いておく。 コネクションプールに近い感じで、最初にリソースを生成したあと、それらを大事に取り回します。リソースが空いてなかったら goroutine は待つことにする。sync.Pool は「プールにあったら使うけど、なかったら新しく作る」くらいの感じなので、ちょっとスタンスが違う。 チャンネルによる実装は簡単で、以下のエントリにも書いたセマフォを応用すればよい。 ざっくりと書いてみた例がこちら: https://play.golang.org/p/QWAXsA_89Y チャンネルによるセマフォの実装は、「バッファありチャンネルに何か（struct{}）を挿入できた goroutine が実行の権利を持つ」というもの
go get gobin.cc/PROGNAME でプログラムをゲットできる URL shortener っぽいサイトを作った - 詩と創作・思索のひろば
夏休みの自由研究です。 ghr を go get したいんだけど作者の e の数って何個だったっけ……と悩んでいたらそもそも違う ID でした、けどそれも思い出せない！ って経験ありませんか？ たいていの場合、プログラム名だけは覚えていて、その正確なパスまでは覚えていないものです。 そこでその名前だけから欲しいプログラムを go get できる gobin.cc というサイトを作りました。一種の URL shortener サービスだと思ってもらえればよさそうです。 go get gobin.cc/gore などとすると、github.com/motemen/gore と同じものが go get されます。おー、便利！ 実装 プログラム名からその完全なパッケージパスを自動的に再現するのは難しいのもあり、対応しているプログラムは手動管理のファイルである SOURCES に記載されています。そ
gobump で Go プロジェクトのバージョニングをおこなう - 詩と創作・思索のひろば
Go に限らず、公開しているプロジェクトのバージョニングは必要だけれど面倒なタスクのひとつで、プロジェクトのメンテナンスを続けていくつもりがあるのなら、ほぼ必ず通らなければならない道でしょう。ここで話題にしているのは Git などによるソースコードのバージョン管理ではなく、たとえばバージョン 3.1.4 といった、リリースされるソフトウェアの公開バージョンをどう運用するか、という話です。 バイナリとして配布する前提のプロジェクトであればソース中で var version string と宣言した変数に、ビルド時に -ldflags '-X main.Version 3.1.4' などとしてバージョンを設定するという方法もありますが、go get による配布ができるのなら、提供側としては楽ができます。たとえば gore は開発者向けということでバイナリの配布をしていませんが、リリース作業がな
go-cli: ドキュメントとともにコマンドラインツールを作る - 詩と創作・思索のひろば
hub-pr を作るとき、（ghq などで使っていた）codegangsta/cli ではなく新しいライブラリを試してみようと思って mitchellh/cli を使ってみたけど、何かしっくりこないものがあったので、せっかくだし、と自作してみた。今回の要件は以下のとおり。 （go や git のように）サブコマンドがある コマンドラインオプションの解析には標準の flag パッケージをつかう コマンドを追加するのが面倒でない で、go-cli（ドキュメント）。 コマンドの実装 hub-pr のソースコードが一番のサンプルだけど、コマンドは以下のような関数で表現される。 func doCheckout(flags *flag.FlagSet, args []string) error { 各コマンドの実装は初期化された *flag.FlagSet とコマンドの引数（プログラムの第1引数がコマ
オレ流 Pull Request 作業フロー - 詩と創作・思索のひろば
チームで作業する同じリポジトリの中で Pull Request を送り合うのではなく、オープンソースプロジェクトに外部から PR がやってくる場合の話です。 最近のフロー 送られてきた PR に対しては、大まかには仕様の話、実装方針の話、具体的な実装の話を詰めながらマージできるように持っていくわけだけれど、それがほとんど満足いく状態になっていてマージしたいと思うタイミングになっても、変数の名前付けだとか、ちょっとした処理の書き方だとかで、相手にお願いするよりは自分で手を加えてからマージした方が手っ取り早いことがある。そういう時は PR 元のブランチを手元にチェックアウトして、そのブランチを自分の変更で進めた上で master にマージするようにすると、push 時に PR も閉じられて便利です。 motemen/lgtm.sh#1 の例。分かりにくいれど、PR にさらに 1 コミット足して
コード補完もできる Go の REPL「gore」を作った - 詩と創作・思索のひろば
タイトルの通りです。Go は LL 的に使える、とはよく申しますが、そういう意識で使っていると REPL 的なことをしたいときに困りがちですよね。そこで作りました。gore。いい名前ですね。 motemen/gore · GitHub 以下のスクリーンキャストでだいたいの雰囲気をお察し下さい。 （スクリーンキャストは cho45/KeyCast を使って撮影しました） 特徴 gore の特徴は以下の通りです。 ラインエディタと履歴 複数行入力 パッケージのインポート、補完つき 式および文を実行可能 コード補完（nsf/gocode を利用） プリティプリント（k0kubun/pp か davecgh/go-spew がおすすめ） ドキュメントも引ける（godoc が必要） 以上のように、非常に便利なものになっております。むしろこの程度 REPL には当然あってほしい機能だとも言える。 イン
blogsync ではてなブログのエントリをローカルと同期する - 詩と創作・思索のひろば
こんにちは、はてなチーフアプリケーションエンジニアの id:motemen です。今日ははてなエンジニアアドベントカレンダー2014 の 22 日目として、はてなブログのエントリをローカルと同期するツール blogsync を紹介します。昨日は id:tarao による gulpで依存関係を考慮した自動コンパイル でした。 はてなブログは CMS としても非常に便利に使えるウェブサービスで、実際Mackerel のヘルプもはてなブログで運用しています。ドキュメントのようなコンテンツはいろいろな人が触り、頻繁に書き換えるので変更履歴を残したいところ、また慣れたエディタで編集したいものですが、はてなブログ単体にそういう機能は当然ありません。そこで個人的に はてなブログ AtomPub を用いて、はてなブログのエントリをローカルのファイルシステムに保存するツールを Go で書いて、使ってみていま
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
