ブックマーク / blog.sushi.money (116)

  • Macで毎分スクリーンショットを撮って手元に貯めておくスクリプト - hitode909の日記

    書いてたテキストエリアがどっかいく、みたいなことがたびたびあって、スクショを定期的に取っていればこんなことにならないのに…と思っていた。 先日、Redash用に、がんばって書いたSQLがどっかいってしまい、ものすごく悲しい、という出来事があったのであ、あまりに悲しさに、重い腰を上げてスクリプトを書いた。 きのうがんばって書いたRedashクエリを保存せずに消してしまった悲しみから、Macの画面のスクリーンショットを撮り続けるスクリプトを書いて、xbar経由で毎分実行してキャプチャし続けている。Macに入ってるOCR機能も呼び出して検索できるようにしたい https://t.co/ibVVCLZszg— 趣味はマリンスポーツです (@hitode909) 2023年11月30日 やっていること 画面全体のスクショを撮って、デスクトップ内のフォルダに置いていく 複数ディスプレイを使ってる場合も

    Macで毎分スクリーンショットを撮って手元に貯めておくスクリプト - hitode909の日記
  • オンライン会議用の背景画像を生成するやつを作った - hitode909の日記

    id:minemuracoffeeさんがAIを使って描いた絵を背景画像に設定されてる、というのをあさイチで見て、背景画像を自作するのは良いな、と思ったので、ちょっとブラウザでお絵かきするページを作って、ジェネレータを作った。 https://cute-grey-juice.glitch.me/ 使い方は簡単で、上のページをブラウザで開くだけ。 ただ開くとカラフルな絵文字が出るのだけど、好きな字を入れると、入力された字をもとに作ってくれる。 入力された文字と文字コードの近い文字をランダムに選んで埋めていく。 背景色とか具合文字の埋め具合はランダムなので、気に入るまでリロードする形。 2文字以上のときは単に繰り返すようにしたので、拝承ってひたすら書かれた背景画像を生成できる。 生成用のURLもシェアできるので、ここからみんな好きな拝承画像を作れる。 https://cute-grey-juic

    オンライン会議用の背景画像を生成するやつを作った - hitode909の日記
  • ユーザースクリプトが書きにくくなると初学者が自由に練習できる場が減っていきそう - hitode909の日記

    DTMをどうやって始めるかというと、テレビとかで流れてる曲を耳コピで打ち込んで匿名掲示板に放流する、するとボコボコに叩かれる、それを糧に成長していくかただちに脱落していく、そういう流れがあったのだけど、近年はJASRACが手作りMIDIに対する集金を始めたそうで、雑MIDIを公開すると著作権料を徴収されてしまう、これでは初学者が耳コピからDTMを始めるルートが閉ざされてしまっているのでは、という話が20年前くらいにはあった。 Greasemonkeyとかユーザースクリプトとかも同様な雰囲気があると思って、おおらかな時代は乱雑なコードを書いて好きに動かしていた。 blog.sushi.money blog.sushi.money 現代のChromeは.user.jsをブラウザにドロップしてもすんなり動かしてくれなくて、雑なJSを書いて動かしたい、という衝動をかなえるための参入障壁が上がってい

    ユーザースクリプトが書きにくくなると初学者が自由に練習できる場が減っていきそう - hitode909の日記
  • 怠惰 - hitode909の日記

    エンジニアは怠惰を求めるべし、という話があって、実際に仕事してるエンジニアを見ると、「楽になりたいなァ〜」みたいなことを、うわごとのようにつぶやいている。 ここで、そんなに楽になりたいなら、何もしなくていいよ、とか言って、半年間なにもしなくても給料をもらえます、という状況を作ればいいかと言うと、そんなことはない。 「楽になりたいなァ〜」、を丁寧に翻訳すると、「人間の代わりに機械に仕事をさせたたり、ルールを整理したりして、その作業自体をなくしてしまいたい、そうしたら楽になるだろうな、そして、その変化の過程で得られる達成感を得たいなァ〜」、というようなニュアンスが隠れている。 なので、仕事をしていて、目指すべき良い状態というのは、何もしなくて良くなったときや、大型連休を取れるとき、ではなくて、仕事で達成感を得たとき、だと思う。 休みたいときに休めないのは避けるべき状態。でも、大量に休めたらいい

    怠惰 - hitode909の日記
  • 仕事の種類が増えてもめちゃめちゃにならないためには - hitode909の日記

    かかえている仕事の量や種類が多すぎてめちゃめちゃになっているときは、何からやればいいかわからなくなっていたり、タスクの存在を忘れ去っていたり、気にしてなかったところでリマインドされて、やべっとなったりしている。 溜めていって一気に片付けるよりは、そもそも溜めていかないような心がけが必要。 宿題をどこかにメモしておく プライイベートでも仕事でも、Todoistを使っている 最近は依存関係をつけられるのが好きなので、Asanaに寄せて、みんなで見てるプロジェクトにつっこんでいくのが忘れにくくて良さそう、と思ってきている ペアで進める 「あとでやっときまーす」だと忘れそうだけど、誰か誘ってカレンダーに入れて、時間を抑えて一緒にやると忘れ去りにくい ペアプロで手伝うとか、決まった時間に手伝いに行くという関わり方なら無限に関わって行ける。抑えた時間だけ集中して進めればよい これが設計の相談役として、

    仕事の種類が増えてもめちゃめちゃにならないためには - hitode909の日記
  • 毎週やってる定例会のアジェンダに「これは月末の会で」としておくとスキップされがち - hitode909の日記

    開発しているアプリケーションのフロントエンドの様子を見る会(フロントエンド草むしり会)を毎週30分ずつ開催している。 式次第の雰囲気を紹介するとこういう形で、毎週見るメトリクスやエラーに加えて、月に1回くらい様子を見たい項目もある。 アップデート関連は、Pull Requestが出たら都度対処するのだけど、それに加えて最近の様子はどうだろう、と眺める時間を取りたい。そういうものは月に1回くらい見ることにしている。 毎週 この会の大義を確認しよう 終わってない宿題を眺めよう エラーのメトリクスを見よう パフォーマンスのメトリクスを見よう 月の初めの会のみ Dependency Dashboardのアップデート候補を見よう Dependabot alertsを見よう ここで「月の初めの会のみ」としているのがポイントで、今回が月の初めかどうかは誰が見ても明らかで、間違いが起きにくい。 これを仮に

    毎週やってる定例会のアジェンダに「これは月末の会で」としておくとスキップされがち - hitode909の日記
  • UI上のラベルや説明文をどこにどれくらい書くべきか - hitode909の日記

    インタラクションのあるUIを作っていると、UIパーツのみからは挙動を読み解けない場合があって、そういうときには、一言説明を添える、ということをやる。 こういうときに、どこにどれくらいの説明があれば必要かつ十分か、ということを学べる機会はあまりない気がする。 アルバイト氏のPull Requestのレビューをしていたら、これだと何が起きるかわからないので説明を添えたいよね〜って話をしていたのだけど、そういえばこういうことはどこで学べるのだっけ?というのが気になってきたのだった。 ブログチームでブログを作っていた頃には、編集メンバーが画面のレビューをしてくれて、ここのUIの文言はこれくらいのことを書けば必要かつ十分で、ヘルプの言い回しや告知とも整合性が取れてよいのではないでしょうか、みたいなことを一緒に考えてくれていて、勉強になっていた。 ブログのサイドバーから、説明文を消し去ると、フォームに

    UI上のラベルや説明文をどこにどれくらい書くべきか - hitode909の日記
  • 承認ではなくて、よさそう、と思って暮らしている - hitode909の日記

    普通に書いたdiffは、関心がさまざまなところに散らばっていたたり、書きかけだったりで、意味のまとまりがないもので、それを整形して、説明を書いたものがPull Requestであり、コードレビューは、そのまとまりごとに、他人から見て理解可能であるという承認する行為、という理解をしていた。 なので、レビューを通すことは、動くことに賭けて、以後、動かなかったら責任を取る、みたいなイメージはあまり持っていなかった。 レビュワーの責任をどこまでと規定するか考えて、責任が大きい順に並べていくと レビューを通した以上、以後は私の責任です、という態度 職人魂を感じる 見たところよさそうに思いました、という態度 通りすがり風情を感じる まったくの無責任なので、工数最小化のために何が来てもapproveする、という態度 やっつけ仕事 かるぱさんのチームでは1になっているのかな(追記)こうなっている、というこ

    承認ではなくて、よさそう、と思って暮らしている - hitode909の日記
  • Google Maps上で二点間の中心点を観察できるページを作った - hitode909の日記

    最近引越し先を探していて、もうちょっと北がいいとか、通勤を考えるとうちのオフィスに近いほうがいいか、とかディスカッションしていたのだけど、実際のところ中心点はどこなのか?と気になってきた。 Google Maps上で経路は見えるけど中心点は見えないので、ちょっとAPIを呼んで可視化するページを作った。 きのうの深夜と今朝の早朝にちょっとずつ作ってるうちに方向性がぶれてきて、中心点に、「愛」と書かれたピンがプロットされる。 オフィス間の中心見ての通り、我が家の職場の中心点は御所の中心付近で、ここに住むと双方への通勤が非常に快適になることがわかった。 せっかくなので好きなキーワードを入力して、好きな場所と場所の中央を見えるようにしている。 よく冗談で、いまから東京オフィスと京都オフィスの中心で集まって、そこで宴会をしよう!とか言っているのだけど、その正確な場所を割り出せる。 はてな京都オフィス

    Google Maps上で二点間の中心点を観察できるページを作った - hitode909の日記
  • コンビニでコーヒーを買うときに思うこと - hitode909の日記

    コンビニでコーヒーを買うと、機械がコーヒーを淹れてくれて、「おいしいコーヒーが出来上がりました」って表示されたりする。 そのたびに、これは絶対におかしい!!と思って、なぜなら、おいしいかどうかは顧客が決めることであって、コーヒーマシンが決めることではない、と感じる。 その直後に、このように、文言を一言一句読んで、この文章は文面通りに読み取るとおかしい、みたいなことを考えているのもおかしいな、と思って嫌な気持ちになる。 ここまでが1セットで、これをコーヒーを1杯ずつ買うたびに毎回思っている。 もうひとつ思ったのは、今日、保育園を見学に行ったら、水槽に「ガラスを叩くと、魚はどう感じるかな?」みたいなことが書いてあって、これも文面通りに読んで、経験主義的なアプローチを適用すると、とりあえずガラスをバシバシ叩いて魚の様子を見ることになりそうだな、と思った。 そういうことを思うたびに、人としての心が

    コンビニでコーヒーを買うときに思うこと - hitode909の日記
  • 個人で作ったツールをなんでもDocker Hubに上げる姿勢に違和感を感じてきた - hitode909の日記

    docker pullしてdocker runするだけで動いて便利じゃん、各言語のセットアップとかも省けるのでどこでも動いてありがたい、と思っていて、個人で作ってるツールもDocker Hubに上げたりしていた。 でも最近は、そういう時代でもないのかな、と思ってきている。 各言語でのライブラリ管理と二重の管理になってしまう Node.jsで作ったツールのイメージを作ると、awesome-tool2.0っていうdockerイメージの中にawesome-tool2.0がインストールされていて、そのイメージにNode.jsも同梱する形になる。 awesome-tool3.0をリリースするときには、まずはnpmに3.0を公開して、そのあとでDockerHubにもビルドして公開する、という流れになる。 各言語のパッケージマネージャのライフサイクルと別に、DockerHubへの公開、というフローが挟ま

    個人で作ったツールをなんでもDocker Hubに上げる姿勢に違和感を感じてきた - hitode909の日記
  • 歌詞の音階と実際の音がずれている曲が気になる - hitode909の日記

    ミ♭ファソの歌詞がドレミ、にくわえて、ファシ♭ソファの歌詞がソラシド これは前から知っていて、嫌だな、と思ってた。 ドド♯ド♯ド♯の歌詞がドレミファ はじめてのおつかいって昔あったよね、と話してたらイントロでドレミファドレミファって歌ってるのを発見してしまった。 サビではドレミファソラシドって言ってるけど音階はソラドレミファ♯ソなのでここは転調されてるのだと思えばギリギリ耐えられる。イントロのドレミファドレミファはきびしいと思う。 こういう曲だけを集めていつかDJデビューしたい。 ほかにこういう状態になっている曲を知ってたら教えてください。 そういえば、ヤマハ音楽教室で歌うドレミファソラファミレドは一致していてうれしい。すべての曲がこういう形になってほしいものですね。 追記 コメント欄で教えてもらえた。まとまってておもしろい。上記2曲はこの動画でも冒頭の2曲で、代表的な音ずれソングっぽい。

    歌詞の音階と実際の音がずれている曲が気になる - hitode909の日記
  • はてなマンガチームの魅力、それは新しいツールをとりあえず使ってみること - hitode909の日記

    最近、SlackのHuddleっていう、チャンネルから離れずに通話できる機能を使っていて、ミーティングないときはとりあえずジョインするようにしている。 同じく予定のない間はジョインしているメンバーがいるので、いろいろと声をかけながら調査したり、その場で確認をとりながら作業を進めたりできている。 今日話したことは以下のような話題。以下のいずれの話題についても、今日話す予定になかったけど、その場でちょこちょこと直せたり、調査が進んだりした。 週末いいことありましたか、みたいな雑談 同僚が使ってるイヤホンの音量ボタンをリズムよく連打するとクラッシュする、という良い情報を教えてもらえた 今日発生した不具合の原因が、以前からのキャッシュの出し分けロジックに関連していそうという話 キャッシュの出し分け方針をディレクターに確認しよう、といってissueを入れて方針決めを進めた データベースのパーティショ

    はてなマンガチームの魅力、それは新しいツールをとりあえず使ってみること - hitode909の日記
  • shitをdropする - hitode909の日記

    ヒップホップをやっている人たち、新作はshit、リリースすることをdropと呼んでるのがかっこいいと思う。 shitはかっこいいものとしてみなされていて、shitはdropするものである、というのが一つめにある。 二つめは、新作は生理現象として作っていくものだし、これからも、死ぬまで作り続けます、という意気込みを感じる。 三つめとしては、日語的な文化圏で考えるとものすごい卑下のようにも聞こえる。大草原の小さな家、の小さな家部分と同じジャンル。大草原は1つめのかっこいいshitで、小さな家はへりくだりshit。 そう考えると、shitを欠かさずすくって展示することは生まれ持った行動ではなくて、shitの常設展示に至るまでには1ステップ動機が必要になりそう。 私はブログに5000shitGitHubに200shitくらい展示しています、ということになるけど、なぜこんなことをしているかという

    shitをdropする - hitode909の日記
  • ネイティブアプリからGraphQLを叩くときにどこまでパラメータ化するか - hitode909の日記

    GraphQLを使って、ネイティブアプリにさまざまな集計方法のランキングを出す、というときについて考えている。 たとえば、ソーシャルブックマークアプリを作っているなら、「総合」「一般」「世の中」「政治と経済」みたいに、カテゴリごとのランキングを出すことがイメージできると思う。 どのようなqueryを用意して、どこまでパラメータ化するか、どこまで自由にするかによって、サーバークライアント間の責任分担や、その後の変更コストが変わってくる。 サーバーサイドで制御する rankings: [Ranking!]!みたいに、クライアントからは「ランキングください」とだけ送るパターンを考えられる。クライアントでは、Arrayの返ってきた順に画面上に表示する。 良い点 サーバーサイドでランキングの定義を持てるので、APIだけでなく、ウェブの画面に表示するランキングなど、他の面との仕様を揃えやすい 変更がサ

    ネイティブアプリからGraphQLを叩くときにどこまでパラメータ化するか - hitode909の日記
  • リモートワーク大全 - hitode909の日記

    リモートワークでの働き化ががちゃんと定まってない、他社の事例を参考にしよう、という話があったので読んでみた。シックス・アパートの人たちのリモートワーク情報が載っている文化が明文化されている 信頼、性善説に基づいて無駄を省こう、みたいな、主となる方針が明文化されているのが良いと思った。 リモートワークで暮らす上で、こっちとこっちなら、どっちが望ましい状態なんだっけ、というときに、毎回、個人で考えるんじゃなくて、ここに立ち返るとこっち、とすぐに判断できそうだし、そこは前提として議論が進むので楽そう。こういうものがないと、真に生産性が上がるのはどっち?とか、生産性上げたいんだっけ、それよりはこっちのほうが大事、とか、どこから議論を出発するか苦労することになる。 ちょっとしたTIPSがまとまっている YESともNOともとれる,曖昧な返事をやめよう、みたいな、ちょっとしたテクニックが載っていた

    リモートワーク大全 - hitode909の日記
  • プログラミングでサクセス…!!!みたいなCMをよく見るようになってきた - hitode909の日記

    プログラミングでサクセス…!!!みたいなCMをやっているのをよく見るようになった。 一昔前はブログのアフィリエイト収入で一発当てるぞ、とか、YouTuberとなって一発当てる、その前はビットコイン、ゴルフ券、チューリップ…みたいに、その時どきの盛り上がりがある。 盛り上がるのはいいのだけど、そのあとで盛り下がったときに、いまさら〇〇をやるなんて時代遅れ、みたいに、誰もやらなくなると困ると思って、ビットコインはだれも買わなくてもいいんだけど、プログラミングをやろうとする人が減ると困りそう。 ふだん仕事していて、なんでこんなにやることがあるのか?それは一部の人類が全人類分のプログラムを書いているためであり、人類皆が自分に必要なくらいのプログラムを書けるようになってほしい、と思うことがあって、プログラミングのリテラシが向上することは賛成だけど、プログラミングできればただちにメッチャ儲かるわけでは

    プログラミングでサクセス…!!!みたいなCMをよく見るようになってきた - hitode909の日記
  • テンション上がらないときは誰か呼んできてペア作業すると良い - hitode909の日記

    という話を2年くらい前に社内ブログにちょろっと書いていたのをid:aerealが探していたので発掘しておきました。 個人的なテンション上がらないときのおすすめテクニックは誰か呼んできてペア作業することで、ブログチームにいたときは困ったらはこべさんをペアプロしましょうって呼んできて、僕は横から応援する係に回り、代わりに書いてもらってた。 逆の立場のときもあり、テンションが下がったときに助け合える関係になってるとチームとして強くなれそう。 はこべさん(id:hakobe932)はパソコンダンプカーみたいな感じの人で、なんでも倒していってくれるので、助けを求めるとすべてが解決する。 助けを求めて、名乗り出てくれた人にやってもらう、というのがひどい話でもあるけど、人によって得意不得意があり、呼ばれて出てきた方は苦にならず進めてくれることもある。 あまりに面倒な作業とか、ふたりともテンション上がらな

    テンション上がらないときは誰か呼んできてペア作業すると良い - hitode909の日記
  • 家族用メーリングリストを作ってユーザー登録に使っておけばよかった - hitode909の日記

    家族内での情報共有や管理について、お金の管理は共用の口座と家族カードで、とか、情報共有はScrapboxで、とか、快適になっているのだけど、唯一、やっておけばよかったなというのが、メーリングリストを作っておくこと。 一緒に住んでると同じ情報にアクセスしたいことがしばしばあるのだけど、そういうときに、二人で使える共用のユーザーアカウントがあると便利なことがあると思う。 たとえば飛行機のチケットを取るときとか、予約の確認メール必ず転送したり、その後フライトがキャンセルになったらそのメールも転送したりと、たいへんめんどくさい。インドに行ったときにフライトがどんどんキャンセルになって、のメールアドレスに届いて、どこまで転送してもらったっけ、とわけわからなくなっていた。 各種手続きに使うメールアドレスをメーリングリストにしておくほうが緊急のメールが来たときに早く気付けそう 不確実性コーンを見て心を

    家族用メーリングリストを作ってユーザー登録に使っておけばよかった - hitode909の日記
  • フィードバック入門 耳の痛いことを伝えて部下と職場を立て直す技術 - hitode909の日記

    自分はマネージャではないのだけど、おすすめされたので読んでみた。 これまで、1on1でのフィードバックというと、まずは良いニュース、そして悪いニュース、そしてさらに良いニュース、みたいなサンドイッチ技しか知らなかったけど、このでは体系化されていて、こういう考え方でやりましょう、というフレームワークを教えてくれたり、後半では具体的に、こういうときはこうするべし、みたいなテクニックを教えてくれる。ちなみに、このでは、サンドイッチ技は都合の良いところだけ記憶に残るのでよろしくないとされている。 前半の、枠組みを教えてくれるところはおもしろかった。客観的なデータを集めに行こう、とか。あとは、学生のときにバイトで入ってすぐくらいのときに、社長がぷらぷら歩いていて、元気?楽しい?って聞いてきて、この人はなんでプラプラ歩いてやってくるんだろう?と思ってただけど、こういうを読むと、声を書けて回って情