はてなブックマーク

同僚がSoraのコードをくれる、というのでインストールしてみたら、なぜかコードなしでそのまま使えた。貼り付けコードがないので、リンクを1個ずつ開いて見てください。 https://sora.chatgpt.com/p/s_68e32523830881919ff29e465b5a16fc https://sora.chatgpt.com/p/s_68e34acafc0c81918650b3739b41b6d5 https://sora.chatgpt.com/p/s_68e3b5c56e8081919bfd20884ded7615 https://sora.chatgpt.com/p/s_68e43f90f4ac81918df3b612413f147e 子に見せたらそこそこウケていて、仕事が終わらないの曲は保育園に行くときにも口ずさんでいた。 今日これやってたの？って聞かれたから、そうだよ、

最近、子がひらがなの勉強をしていて、だんだん読み書きできるようになってきているのだけど、「へ」は「へそのへ」、「そ」は「へそのそ」、など、独特の覚え方をしている。 また、友達の名前を語呂合わせで覚えたりしている。 市販の五十音表には、「へ」と「そ」の両方にへそが書いていないし、友達の名前もなく、馴染みのない言葉が書かれていたりする。 子といっしょに一文字ずつ、好きな絵を設定できたら学習に役立つだろうと思って、ブラウザ上で五十音表に好きな画像を設定できるツールをAIと作った。 hitode909.github.io こんな感じで、「か」に鴨川、「き」にキーマカレー、「お」におにぎり、など、好きな画像を設定できる。 無事、「へ」も「そ」もへその画像がくっついて、友達の顔が印字された五十音表を作ることができた。 印刷してあげたら、気に入って壁に貼ったり、真似して字を書いたりと、楽しんでくれている

ふりかえりとか、KPTをやっていると、「じゃあ、ここにこういうチェックを入れたら？」という話には簡単にたどり着ける。 ただ、それを繰り返していくと、ルールだらけになってしまうし、どんなルールがあったか覚えていられない。 ルールをつけたり外したりしているだけで、べつに常用が良くなっていない、ということがありがち。 プロセスを改善して、仕組みでカバーしよう、というのは大事だけど、それだけではダメで、それ以外のところも大事だよね、ということを、いろんな場所で喋っている。 ただ、それ以外の部分は何？というと、あまり言語化できていない。 専門技術 プロセスが扱い方を扱っているのに対して、こちらは、扱う対象のこと。プログラミングとかデザインとか 小説家をイメージして、何日までに何章を書く、という計画がうまくても、一方、書く内容が面白くなかったら、結果の小説はおもしろくない 論理的な思考 決断に至る検討

Kindleの本の読み上げ機能は、以前はFire HDかAlexaアプリのみ対応していたと思う。 子が小さいときにはベビーカーを押しながら、長大な日記とかを読んでた。 Alexaアプリは、〇〇を読んで、って言ったら読んでくれるけど、音声だけで操作するのは難しくて、1冊も読めたことはない。車で聞けたらいいはずなのだけど…。 最近気づいたのが、iOS、Android、macOSそれぞれのKindleアプリにもアシストリーダー機能が搭載されている。 なぜかデフォルトでオフになっていて、Aaのボタンからオプトインすると使える。 macOSでも聞けるけど、フォーカスを外すと止まるので、ながら聞きはできない。スマホとか持ってきてパソコンの横に置くのが良いと思う。 Windows版には、まだないのかも。わかりません。 appllio.com このことに気づいてから、家事をしながら読みかけの本を2.5倍速

以下のカラス避け画像配布のページを見て、いいな、と思ったので、自作を試みた。ChatGPTにお願いして、アニメーションするJSを書いてもらう。これをゴミ置き場に向けて、窓からプロジェクターで投影すると、ジェネレーティブなカラス避けが実装された私道となって、アートな地域って感じで、地域貢献できると思う。 www.hyugacity.jp （9/2 6:37追記、朝になって見たら日向市のサイトからはページが消えてた。かっこよすぎてクレームが来たんだろうか？） これはサンプル。続きを読むとアニメーションが続々でてきます。 最後のは、ChatGPTに、あなたが思う効果的なカラスよけを考えて、とお願いしたらこれがでてきた。目玉のシーンと斜線のシーン、2シーンの切り替えでカラスを威嚇しているらしい。AIがカラスに対するビジュアルを考えている、AI×カラス、という構図がおもしろいと思う。

発注者の心得のつづき 対象象について学ぶ姿勢があるとより良い 家の注文をするなら、何を重視して暮らしたいか、という分析、研究、学びが求められる 何を注文したいか、という優先事項は発注者が定める必要がある 我々の打ち合わせ中にあったのは、基礎の高さについて、高くすれば玄関ポーチに階段ができるけど家の中は結露しない。一方、事情があって低くしたい場合は家には入りやすいが結露の恐れあり、と説明してもらって、我々がどちらか決めた これは絶対こっち、として、受注者が決めることではなく、メリット、デメリットや、発注者の重視することをふまえて、発注者が決定するもの トレードオフがあるもので、技術選定をするときに遭遇するものと同じ 堅牢だけど構築に苦労する vs 壊れやすいけど一瞬で作れる、どっちがいい？など。絶対前者ではなく、状況による 発注者側に、対象について学ぶ姿勢がないということは、「私は素人なので

最近はコードを書くときには、なんでもClaude Codeに書いてもらってるのだけど、何が便利かというと、MTGの開始時にお願いして、MTG中ほったらかしにして、終わった頃に見たら進捗が出ている。多少変でも、そこから手直ししたら使えるものになるので、大満足。 人によって印象がちがうけど、期待通りに書いてもらえない、と不満を言っている人はフルタイムで開発している人で、そういった人は自分で1の進捗を出せていたものが0.5になっていて不満で、一方、満足している人は、もともと自分でコードを書く時間がなくて何も作れていなかったのが、ちょっとは作れるようになる、という、0が0.5になっているので満足している、ということかもしれない。 また、フルタイムで開発する人は要件が曖昧なビジネスロジックの実装をしていて、前提知識が多いので、ちょっとしたプロンプトくらいではうまく作れない。 コードを書くのがメインじ

個人で、なんらかの特注品を、専門家に発注するときに、どんなところに気をつけられるとスムーズだろう、と考えていて、発注者への心得をChatGPTとやりとりしてアジェンダを作ってもらった。 1. 発注は「完成品を買う」ことではありません サブウェイのトッピングや靴のセミオーダーとは違い、オーダーメイドはゼロから形にしていくプロセス。 完成品を選ぶのではなく「一緒に作る」ことが前提です。 2. 発注はスキル ― 人生を通じて上達するもの 初めての発注はうまくいかなくて当たり前。 「次の発注のために学ぶ」という姿勢が大切です。 「できあがってからクレーム」ではなく、事前の工夫が重要。 3. イメージのすり合わせを重ねましょう 曖昧なまま進めると大きな手戻りに。 途中の試作品や進捗を見て、こまめにフィードバックすること。 認識の違いが出たときは「合ってなかったですね」と柔らかく修正。 4. 手戻りに

期末、期初でオフィスに人が集まっていたので、チームの中の暮らしで、理想の暮らしはどっち？と話していた。 すべて非同期化して、1日作業に没頭できる、という没頭パターン 何でも一緒にやる。1日おしゃべりしながらペア、モブ活動している、という何でも協力パターン 個人的にはペアプロしている時間が一番楽しくて、1日中ペア活動して過ごしたいと考えている。 どうやったらうまくいくか考えるのが好きなので、それを他人とおしゃべりしながら取り組めるのも楽しいし、途中で集中力が切れて、気づいたらSpotifyのプレイリスト作成している、みたいなこともなく、うまく集中できる。 自分で試してはいないけど、隣の人が試した結果、くらいの情報（おばあちゃんの知恵袋みたいなもの）を少しずつもらえるので、誰とペアプロしていても、一つくらいは知らなかったことを教えてもらえる。 横に誰かいると、ちょっとした凡ミスにすぐに気づいて

きのう良いメンバーになり方の日記の続き。 本を読むのが好きや得意な人なら、せっせと読んで、参考文献から次のテーマを探して、自由研究を勝手に進められるんだけど、そんなに積極的に本を読めない人もいる、という現象がある。 ※本読むのが良いメンバー、と言っているわけではないです。 本を読める余裕のある人や、もともと本が好きな人は勝手に読んでいく 良い本を見つけたときに、読んでもらうには？の取り組みも色々試している 1冊、この本がいいよと紹介 本好きな人でないと読んでくれない 読むのに時間がかかる人だと1冊紹介して数ヶ月取り組む、となるので先が長い 1ページ抜粋して、ふせんなどを貼ってオフィスに置いておき、ここがおすすめ、という扱いにする そのページだけ読めばエッセンスはわかる、とか、気になってもらうきっかけに使う チームの皆で読み合わせをする。スクラム導入したい、というときに、SCRUM BOOT

長年開発を続けているページでは、Bootstrapなど、ページ自体のスタイルを丸ごと上書きしてしまうCSSライブラリが読み込まれていることがある。 一方、最近はReactコンポーネントを作って、スタイルはCSS Modulesで当てたい、という機会が増えている。 CSS Modulesを使うと、コンポーネントに適用スタイルを明示的に指定することができるが、そこにページ丸ごと上書きCSSライブラリが混ざってくると、思うようにスタイルが当たらない、ということになる。 たとえば、Bootstrapを読み込んだページのpタグには、margin bottom: 10pxのようなスタイルが問答無用で指定されてしまう。 こういうしがらみから逃れる手法は無いのかな、と思って、Bootstrapを読み込み済みの歴史のあるページでは、Shadow DOMなどを使ったらBootstrapの依存を消せますか？など

ケント・ベックの最近出た本。 ケント・ベックは、プログラミング界のアース・ウィンド&ファイアーくらいの立ち位置のレジェンド。エクストリームプログラミングなどを提唱していた人。 リファクタリングは本来、振る舞いを変更せず、という前提があったのが、いつのまにか世間のリファクタリングは振る舞いを破壊するようになってしまった。本書ではちょっとした改善を「整頓」と呼んでいる コミュニティに、最初は面白い人が集まってくるけど、だんだん面白くない人がやってきて、そのコミュニティはおしまい、みたいな話と通じる気がする。そのうち整頓も破壊行為と同一視され嫌われていきそう。 かなりレジェンドな立ち位置の人の本だけど、意味の切れ目に、空行を入れよう、というテクニックが紹介されている 今やらない直したいことリストを「お楽しみリスト」として取っておくテクニックが紹介されている 社内では「おやつ」と呼ばれている 近年

データを見える化するだけでは効果がなく、その対話が重要、という本。ただの対話ではなくて、ガチ対話、と呼ばれている。 体重計に乗ってはいるけどとくに改善活動はおこなわない、という人はよくいると思うので、そのとおりだと思う。 データはなにかツールがあって自動計測される、というものではなくても、アンケートでもいい。 また、一度やるだけじゃなくて、定期的にやる。メルカリ社の事例なども載っていて、3ヶ月ごとに組織構造が変わるので3ヶ月ごとにデータを取って話し合いというのをやっているらしい。 うちの会社だと半年ごとか、四半期面談というのもやって目標を調整していたりすうるので、3ヶ月ごとにやるのはよさそう。 データを見ながら皆で話しましょう、というときに、リーダーが先に喋るとその後、異を唱えにくくなってしまうので、管理職やリーダーは意見表明を最後にしましょう、という記述があった。 平安時代の「陣定（じん

「プログラマーって普通に会話していても性格悪いと感じる人が多いんだけど、なんで？」と言っている人をたまに見る。 プログラマーのなかには、相手の言葉尻を捕らえて、細かいことを言って、難癖をつけてくる人がいる、私はプログラマーではないんですが、とっつきにくいし、変なこと言うと怒られそうで怖いです、という指摘。 その質問への回答としては、この2つの説明ができる。 日常会話、RFC説（日常会話の文章をRFCだと思って読んでいる） 日常会話、ソースコード説（日常会話をソースコードだと思って話を聞くと例外が気になる） 日常会話、RFC説 お近くのプログラマーに好きなRFCを聞くと、好きな数字が返ってくる。僕は9535。 コンピュータ同士がやりとりするうえでは、約束ごとを決める必要があって、RFCは、ジャンルごとにルールが集まったもの。 RFCでは、「〇〇しなければならない」と言ったら絶対で、それを守ら

LLMの使い方で、よく使っているのが、人間が制作したものをAIに簡単にチェックしてもらう、ということ。 以前作った、ブログを批評してくれるイルカは毎日常用している。 1つの文章を見てもらうだけでなく、2つの文章間に齟齬や、矛盾がないか見てもらう、ということも、たびたびやっている。 人にドキュメントを見せる前などはとくにそう。 同僚にチェックしてもらう前に、ちょっとした誤字とか、ここが意味不明です、みたいなところにつっこんでもらうと、最低限の品質を保てると考えている。 2つの文章を見比べるシチュエーションは、以下のようにいろいろと考えられる。 実装とテストの内容に齟齬がないかチェックしてもらう 実装とドキュメントの内容に齟齬がないかチェックしてもらう エンジニア向けと企画メンバー向けのドキュメントを見比べてもらう 自分のもとに届いた、受け取った情報と、自分の返答の流れがおかしなことになってな

以前より、JavaScriptなどで簡単なコードを書いて、絵やアニメーションを作る趣味がある。 たとえばオンライン画像の背景画像を作るとか。 blog.sushi.money AIと何か作る趣味もあって、デスクトップ壁紙を作ったりしている。 blog.sushi.money 2年前には変な時計を作ってもらっていた。 blog.sushi.money 壁紙を作ったら次はスクリーンセーバーだ、というのは自然な流れなので、コーディングエージェントと一緒に作った。 Xcodeで書き始める、ということはせずに、ペライチのHTMLをまずは開発して、それをスクリーンセーバーとして設定する、という流れ。 リポジトリ GitHub - hitode909/sketch-20250502-random-visual デプロイされたページ https://hitode909.github.io/sketch-2

Ruby Kaigi 2日目。 技術書店が出店しているので、ちらちら覗きに行った。 昼休みに高橋さん（高橋メソッドの高橋さん）が本を紹介してくれるイベントがあると聞いて、キッチンカーに並ぶのを断念して行ってみたら、1時間にわたって延々と本を紹介されていて、尋常でない本好きな人だ、と感動した。 コードレビューの方法に関する本が紹介されてたので、買って、サインをもらった。 ふだんの仕事ではぼぼ自分で実装する時間はあまりなく、コードレビューしてたら一日が終わる、という形でコードと関わっているので、参考になりそうだし、チームメンバーたちも大量のコードをレビューし合っているので、紹介しようと思う。ぱらぱらめくったら、コードレビューのコメント欄で、クイズを出さないこと、とあって笑った。 伝わるコードレビュー 開発チームの生産性を高める「上手な伝え方」の教科書 作者:鳥井 雪,諸永 彩夏,久保 優子翔泳

きのうChatGPTにお願いして作ってもらったブログの編集画面にイルカが出てきて本文を読んでアドバイスをくれるuser.jsだけど、ずっとTampermonkeyを使っているのもいかがなものか、と思って、普通の拡張機能にしてもらった。 user.jsは1ファイルあれば動くので、ChatGPTに聞いて作ってもらうのが楽だった。手元のエディタの準備が要らなくて、ブラウザで完結する。 一方、Chrome拡張はいろんなファイルを正しく配置する必要があって、ブラウザからコピペだけではなくて、手元のファイルシステムに切り貼りして置いていくような活動が必要。 AIエージェントなら複数ファイル読み書きできるので、練習にはちょうどよさそう、と、CLINEの練習も兼ねてやってみた。 https://github.com/hitode909/chrome-extension-blog-dolphin tampe