GPT-2でブログ記事のタイトルをTogetterまとめ風にする「面白いのでやってみて」 - 詩と創作・思索のひろば
オレ定義だけど Togetter まとめ風というのはこういうやつ。 散歩で急にシロクマと会っても食べるのは肉だけにしたほうがいい「肝臓1gに含まれるビタミンAが致死量を超える」 - Togetter まとめタイトルの終わりに誰かのツイートの引用を挿入する、という形式。よくできたもので、誰かの生の声が入っているだけで、感想やハイライトを抽出し、ちょっと気を引くことができる。まあ一種の演出で、ニュースサイトがやってることもある。 タイトルでアテンションを奪い合わなければならない宿命におけるクリック最適化の手法ということだろう。今回はこれを真似してみることにする。すでに書かれた自分のブログ記事に、括弧書きでセリフっぽいものの引用を捏造して付け加えることで魅力がアップするのか、という実験だ。 こういう生成系のタスクも、とりあえず HuggingFace+Google Colaboratory でや
自作したRISC-V向けCコンパイラでセルフホストまでこぎつけた - 詩と創作・思索のひろば
低レイヤを知りたい人のためのCコンパイラ作成入門 まさに低レイヤのことが分かっておらず、以前から気になっていたこの本。取り掛かってみたところ思いのほかスイスイ進められて、勢いに乗ってセルフホスト（自分が書いたコンパイラで自分自身をコンパイルするところ）までいけたので記念に書いておく。正確には C コンパイラのサブセットです。 GitHub - motemen/mocc 全体的な進め方は、 上記の本の通りに進めていく。 それ以降は自作の 8queen が普通に書けるように機能を強化。 それ以降はセルフホストを目標に進める。 プリプロセッサやリンカは作らず、C からアセンブリまで。 という感じ。自分は手を動かさないと進んでる気がしないので、まずは書いてみつつわからない所があれば調べる、というスタンスでいく。 あと、せっかくなので RISC-V の勉強もしたかったのでこれ向けに書く。なので実行は
Chrome仕事術 - 詩と創作・思索のひろば
いろいろ工夫した結果、最近 Chrome さばきが良くなってきた気がするので、やっていることを書いておく。 タブが必要になる時刻でグループ化しておく 忙しい一日の予定を立てる際に、あらかじめ必要な資料・会場をタブで開いて時刻を打っておくと便利。終わったらまとめて閉じることもできる。 Chromeのタブを必要になる時刻でグループ化しておくライフハック pic.twitter.com/P8RQLy7h9K— 美顔器 (@motemen) 2022年8月22日 ページのブックマークタイトルを自分用に変更する ブラウザのブックマークはあまり有効活用してなかったけど、タイトルを自分用につけておくとロケーションバーからの検索に便利なことを体感している。<プレフィクス> | <検索用ワード>, ... という感じでタイトルを設定していて、プレフィクスは ミーティングの議事録など会場: mtg 1on1
コードレビューのときに見ているところ - 詩と創作・思索のひろば
あるときコードレビューするときにどういうところ見てるんですか？ と訊かれてたしかに自分でもあまり言語化したことはなかったな、と気づいたので簡単に書いておく。 変更意図が要求に沿っているか そもそも実現しようとしていることが、ユーザやプロダクトオーナーの要求に沿っているか。モデリングや実装のコンテキストを自分でも把握しておく。 関連する別の変更やイシューなど、自分が知っていて相手が知らない有意義な情報があったらコメントする。 モデリングが妥当か モデルによって意図が表現できているか。仕事が適切な粒度で明確に切り分けられているか。意図のない共通化がなされていないか。 わかりやすい名前がつけられているか。ここが混乱していると何かがよくないサイン。既存のコードがすでに……ということもある。そういう場合は改善できそうな道筋について議論できるとベター。 仕事にあったインタフェースになっているか。テスト
Makefileの代わりにnpm scripts+zxを使う - 詩と創作・思索のひろば
そこそこの規模があるプロジェクトで実行すべきタスクを定義するとき、初手として Makefile を使いがち。 Pros make は事実上どんな環境にもあることを期待してよい シェルで実行されるコマンドをそのまま書ける タスクの依存関係が明示できる Cons make では positional arguments が使えない 少し複雑なことをしようとすると Makefile 専用の文法を覚える必要がある 現代では、ファイルベースのタスクの依存関係は make が発明されたころほどは必要ではない Docker とか Go とか Webpack がよしなにしてくれることが多い 例: docker compose のラッパー ちょっとしたコマンドのラッパーを書きたいことがある。Makefile を書きはじめたらすべてのエントリポイントを make にしたい。ということで、以下のような Make
Gitのおすすめエイリアス5選 - 詩と創作・思索のひろば
緊急新人エンジニア応援企画！ ということで自分が Git のエイリアスとして設定している便利コマンドを紹介していく。 直前のコミットに追いコミットする (git fixit) git commit --amend --no-edit もろもろ整えて git push しよう、とすると「あっちょっと修正したい」となるのはよくあること。その際いちいちコミットメッセージを書いて rebase するかというとそんな面倒はとりたくなく、一撃で終わらせたい。--no-edit でコミットメッセージを編集せずに --amend できる。 git fixit に設定している。git commit の引数をそのまま受け付けるので、git fixit -a や git fixit <file> のように使える。 メインブランチに戻る (git com) f() { remote_head=$(git symb
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 の解釈はものによって異なってくるのもまた困る。これはプレーンな文字列を渡しているのでこういう困難が出てくるのであって、最近はクリップボードでリッチなコンテンツを受け渡しすることが
Wordleの漢字バージョン「漢字ル」を作った - 詩と創作・思索のひろば
漢字ル こういうやつです。ぜひトライしてみてくださいね。 プロトタイピングのつもりができてしまった！ 漢字版 Wordle。激ムズ 漢字ル 1 8/20 ⬜⬜🟥🟧 ⬜🟥⬜⬜ ⬜⬜⬜⬜ ⬜⬜⬜⬜ 🟥🟥⬜⬜ 🟧⬜🟥⬜ 🟩⬜⬜⬜ 🟩🟩🟩🟩https://t.co/jgITM4Edb4 pic.twitter.com/oQLiWL8kun— 美顔器 (@motemen) 2022年2月2日 本家の Wordle を知らない人向けに解説すると、四字熟語当てクイズです。指定された回数のうちに当てないといけませんが、試行のたびに文字が合っているかどうかを教えてくれるので、絞り込みながら推理していきます。 漢字ルの独特なところは、文字単体だけではなく、漢字を構成するパーツ単位でもヒントが出るところ。以下のように、「匕」「耂」といったパーツが（たとえば「老」に）マッチしているようなヒ
Alfredの代替としてRaycastを使っている - 詩と創作・思索のひろば
新春ツール入れ替えシリーズです。macOS における Spotlight 的なランチャーツールとして Alfred を長いこと使ってきたが、最近 Raycast を使ってみてこれがよかったので、以来ずっと使い続けている。 Raycast - Supercharged productivity 開発者のための便利ツールという売り文句のようで、そういう点がまさに気に入った。 カレンダーの次の予定が表示される まずこれがいい。これだけで十分使える。ランチャーを起動したときにカレンダーの次の予定を表示してくれる。Enter でそのまま Meet や Zoom を開いてくれるのでキーボードから手を離す必要がない。 もともとカレンダーの確認には Dato を使っていたし今も使ってるが、これでミーティングへのアクセスがかなりよくなった。 コミュニティベースの Store で機能を追加できる https:
Goのswitch文を生成するツール - 詩と創作・思索のひろば
GitHub - motemen/go-switchgen 昔作ったソフトウェアをちょっとメンテしたシリーズ。Go で switch 文を自動生成したいよーってときに使えるやつです。 case 文が exhaustive になるようにいちいち書いてくのが面倒なので、機械にやらせる。 こんなやつ欲しいんだが……ってなったときに、オレならこういう名前のツールを作る！ って思った名前で過去の自分が作ってることに一貫性を感じる。まあ世の中にすでに3つくらい実装のありそうなやつではある。 % go install github.com/motemen/go-switchgen/cmd/goswitchgen@latest 使い方 fully-qualified な型を指定すると、その型を持つ値に対する switch 文を生成します。case に挙げられるのは、同じパッケージに定義されている値や型。
Dockerfile をベースイメージの更新に自動で追従させる - 詩と創作・思索のひろば
前回のエントリで作った Docker イメージ motemen/datastore-emulator は、google/cloud-sdk をベースにしているが、このベースイメージがけっこうな頻度で更新される。とうぜん自分はその追従に手を煩わせる気はなくて、全部自動でやってほしい。 やりたかったこと google/cloud-sdk:x.y.z がリリースされたら、 リポジトリ中の ./Dockerfile と ./alpine/Dockerfile の FROM を google/cloud-sdk:x.y.z(-alpine) に更新し、 x.y.z タグを打って git push することで、 Docker Hub に x.y.z(-alpine) タグとしてリリースする これを自動かつ無料で実現したい。 採用しなかった案: 自分でなんか作る はじめは適当な GitHub Actio
ghq など、github.com/motemen 下のリポジトリを x-motemen Org に移しています - 詩と創作・思索のひろば
もうけっこう前のことになりますが、github.com/motemen 下にあったリポジトリの一部を github.com/x-motemen organization に移管しました。コードやバイナリの配布形式によって、ユーザ側で対処する必要があったりなかったりしますが、それぞれのリポジトリにおける指示（あれば）に従ってもらえればと思います。 https://github.com/x-motemen/ghq https://github.com/x-motemen/blogsync https://github.com/x-motemen/gobump https://github.com/x-motemen/git-pr-release もともとこれらは id:Songmu、id:itchyny、id:onk らにアクティブにメンテされているもので、motemen 個人はほぼ完全にノー
テキストを画面に流していくアプリをElectronで作った - 詩と創作・思索のひろば
この記事は、はてなエンジニア Advent Calendar 2019の12日目の記事です。 任意のテキストを画面に流していきたいことってありませんか？ ぼくはあります。定期的にエンジニアみんなの前でスライドを映しつつ話す機会があって、そんなとき Slack で実況的に反応がなされることがあるんだけど、Slack 映しっぱなしにするわけにもいかず、話し終わってあとからコメントに気づく……ってこともまあまあある。そんなとき、画面のスライドに重ねてコメントが流れてくれると自分も聞き手も共有できてうれしい。わけです。 それを達成するための1ステップとして、任意のテキストを画面に次々流してくれるアプリをElectronで作りました。 GitHub - motemen/TextCast じつは過去のこのエントリたちも、「Slack の発言をリアルタイムにデスクトップに流したい」という欲望からうまれた
ターミナルでSlackを読む - 詩と創作・思索のひろば
Slackはそのクライアントがそれなりに、かなりよくできていて、これでほとんど困ることはないんだけど、そうは言ってももうちょっとプログラマブルに取り扱いたいこともある。 そういう場合にもよいAPIが用意されていて、Real Time Messaging API ってのがある。こいつはWebSocketでSlackの発言をはじめ、あらゆるイベントのJSONを送りつけてくれるやつ。ひとまずこれを標準出力に流すことができれば、あとは好きに料理できるはずだ。 というわけで作ったのがこちら。書いたことなかったのでRustです。ちょうどいいネタだった。 GitHub - motemen/slack-stream-json slack-stream-json というバイナリが、SLACK_TOKEN 環境変数を設定した上で起動してやると、RTM APIによって得られたイベントのJSONをそのまま標準出力
ISUCON9予選敗退（H::W::A::Abyss::Abyss::Abyss） #isucon - 詩と創作・思索のひろば
ISUCON9 2日目結果と本選出場者決定のお知らせ : ISUCON公式Blog 日曜日に行われたISUCON9予選に参加し、敗退してきました。前掲の記事の「失格となったチーム」がわたしたちです。チームメンバーは id:t_kyt と id:mechairoi。 去年も予選敗退していて、最近LINE本社に行ってないな～と思っていたので今年は勝ちたかった。今年もはてな京都オフィスで予選に参加。 事前の作戦が大事なので、「コミュニケーションが大切」「マニュアルを読む」を確認した。 だいたいハマり出すとコミュニケーションが減ったり同じことをやりだしたりしてチームとしての効率が下がってしまうので、一時間ごとにタイマーを鳴らしてそこで話そう、という作戦を立てていた。あとは alp と pprof と pt-query-digest でボトルネックを見ていくというシンプルな戦略。 あと、1日目の結果
Go の関数を context 対応するツール - 詩と創作・思索のひろば
最初から完璧な設計と実装ができているなら苦労はないわけだけど、実際にはそうもいかない。具体的にはある程度の規模になってくると「あーこの関数 context.Context 対応したい！」みたいな気持ちが湧いてくるわけです。context 対応ってのは、第一引数に ctx context.Context を追加することですね。 そういうことをやるツールを書きました。 GitHub - motemen/go-ctxize: Rewrite functions to have "Context"s go get github.com/motemen/go-ctxize/cmd/goctxize で、goctxize というバイナリが手に入ります。 サンプル README やテストにある例だけど、 // $GOPATH/src/example.com/foo/foo.go package foo
Google Apps Script でメールの自動アーカイブ - 詩と創作・思索のひろば
メールってやつはプッシュ型のタスク生成・情報取得ツールとしてすげー便利に使ってるのですが、受信トレイを綺麗に保つのには不断の努力が必要で、放っておくとすぐに管理不能な状態にまで膨れあがってしまう（いちおう、いわゆる Inbox Zero を理想として、とはいえそこからは遠いところにいます）。 ちょっと見ないすきに溜まったメールをザザーッと処理するんだけど、毎回これアーカイブしてるよな……と思うものもある。こういうものを機械に処理させられないとしたら、それは技術の敗北である。というわけでなんとかしたい。たとえば、最新情報であったり現在のステータスを知るために受け取ってるメールってのは、定期的に増えてくる一方で、古くなったものには価値がないので、勝手に消えていってほしいわけです。 具体的には、以下のようなメールを自動で処理したい。 【毎日更新】Kindle日替わりセール 前日のやつは不要 〇〇
最近のGoプロジェクトのMakefile - 詩と創作・思索のひろば
最近は仕事でも新しくGoのプロジェクトをイチからはじめることが増えてきて、コピペ元が欲しくなるので、スナップショットとして残しておきます。とくに Go でウェブアプリケーションを書くような場合を想定していて、npm エコシステムにも乗っていきます。 大まかな方針としては、 self-contained である グローバルな環境を汚染しない コマンド一発で開発環境が再現できる ……というところを目指します。 motemen/prchecklist がこれを達成しているつもりなので、以下、これを例に見ていきます。 依存ライブラリは dep なり何かしらのツールと Go 標準の vendoring で管理すればよい一方、そのツール自体であったり、他の開発中に必要なツール（golint とか gobump とか）であったりのインストールをどうするかという話。 npm であれば devDepende
prchecklist でリリース Pull Request のチェックフローをスムーズに行う - 詩と創作・思索のひろば
背景 GitHub を使った開発では、 master ブランチがいつでも本番に出せる状態として、 master から切った develop ブランチを開発のベースとし、 各フィーチャは develop から切って develop にマージし、 リリースのタイミングで develop を master にマージ、リリース ……という流れを pull request ベースで行うのがよくあるパターンのひとつだと思います。リリースの際、ステージングや QA という名前のついた本番前環境でそれぞれの機能が正しく動いているか確認するのもよくあるフローです。 このチェックを pull request 本文のチェックボックスを使って行おう、というアイデアを実装したのが git-pr-release で、もともと id:hitode909 がチーム向けにこしらえたものをパクった汎用化したものでした。この仕
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
