ChatGPTに撮影時の条件込みで画像の内容を説明してもらって、ImageFXで生成するとほぼ同じ画像を作れておもしろい - hitode909の日記
タイムラインで流れてきたポストから、Googleが作っているImageFXが作ってくれる画像のクオリティが高いように見えたので、触ってみていた。 ImageFXの作例 これが自分で撮った紅葉の写真で、 こっちが、Image FXに、京都の紅葉、50mm f1.4バブルボケ、とか伝えて作ってもらったもの。 ChatGPTに同じ入力を渡すと、こんな画像なので、仕上がりの違いがわかると思う。 どこか嘘っぽいというかメルヘンな仕上がりになりがち。 ここまでできるなら、手持ちの画像そっくりな画像を作れるのでは、と思って試してみる。 手持ちのラーメンの画像そっくりなラーメン画像を作る ChatGPTに、自分で撮影したラーメンの写真をアップロードして、この画像を作るためのプロンプトを作って、とお願いする。 この画像と同じ写真を生成AIで作りたいので、プロンプトを生成してください。内容だけでなく、レンズの
ADRのレビューのスタンスはあまり研究されていない気がする - hitode909の日記
ADRは書く機会より読む機会のほうが多いのだけど、読んでいて、冗長だったり、長いと感じると、もっと小さくならないの？って聞きたくなる。 それと同時に、失礼なことをしてないかハラハラする。 これがコードだったら、文のレベルと振る舞いのレベルは切り離されているので、振る舞いを変えずにリファクタリングして小さくできることは明らか。 文章の場合は、削ると、文章が働く役割は自明でないことから、せっかく書いたんですけど、みたいな気分になるような気がする。 文章を扱うときには、問題vs私達になりにくくて、容易に人vs人になってしまう。 普段、編集提案機能のないツールでADRを書いていて、議論のコーナーを作って自然文でやり取りしているのだけど、これではツールの支援が足りなくて、めんどくさい。 レビュワーという立場でファシリテーションしに行くか、意見だけ書いて著者にファシリテーションしてもらうかなど、どの強
ささいなことに、わざわざ「良いと思います！」って言うようにしている - hitode909の日記
いろんな人の相談役をやっているのだけど、ささいなことに、わざわざ「良いと思います！」って言うようにしている。 この調子でいいと思います！ってわざわざ言う 言われた方からは、迷うことなく進めたら良いのだな、ということが伝わる 意見を言えるチャンスがあったら「この調子でよさそうだけど、ゆくゆくはこんな問題に直面しそうですね」とか、ちょっと意見をはさんでおく 頭出ししておいたら考えてもらえるかもしれないし、想定と違ったら、えっそんなことはないんですけど…と早めに変なことに気づけるかもしれない シニアっぽいロールの人物としては、聞かれてもないのに、良いと思います！って言っておくのが大事。 やってみてもらって、うまくいかなかったら、想定と違ってうまくいかなかったんですけど、って声をかけてもらえる。 最初の段階で黙っていたら、どういうスタンスだったのか不明で、相談しにいくときに、まず、どう思いますか？
リーダーっぽい人が忙しくても、忙しいって言ってると感じが悪い - hitode909の日記
すみません、私から発表があります！忙しくて、マジむかつくんですけど、とかチームの朝会で発表してしまうと、一緒にやってるメンバーからすると、そんなに忙しいのなら声かけるのを遠慮しとこう…となり、会話タイミングが減ったりして、それによってあとで来月そのリカバリでさらに大変なことになり、さらに忙しく、こんなことなら先月のうちにしっかりやっておくべきでしたな、ということがありえるので、あまり、忙しくしていても、忙しすぎる、って言えない、という問題がある。 よく、ここは問題VS私たちでいきましょう、とか言うけど、主にメンバーたちと仕事している場合は、問題←→私たち←→私、で、私は直接問題と繋がっていない、私たちの手助けをしている、ということがあって、問題の先が私たちにいきつくので、あまり具体的なProblemを連発しづらくて、毎日の会話の実りが少ない、とか、ペアプロの進捗が悪い、とか言うと、個別のメ
未知の道に突入せず、まずは半分知ってるくらいの状態になる - hitode909の日記
Perl製アプリケーションからGraphQLを喋ってみたい、ということがあって昨年末に2週間くらいでプロトタイピングしていた。 CPANにGraphQLというライブラリが公開されていて、社内の利用実績もあるので、これをいきなり使ってみても良かったのだけど、自分はGraphQLについては、耳では知っていて、GitHubのAPIを呼び出したことがある、くらいで、実際に実装したことはなかった。 このような状態で突き進むと、問題に遭遇したときに2パターンの怪しさが出てきて、切り分けていくことになる。未知のものが多すぎて、プロジェクトXの、トンネルを掘るだけで難しいのに現地の言葉はわからない、みたいな回をイメージしてください。 GraphQL自体への理解が間違っているパターン スキーマ、クエリの書き方が悪い、概念を勘違いしている、など PerlでのGraphQLライブラリの使い方が間違っているパター
テスト、正常系から書くか異常系から書くか - hitode909の日記
今週は同僚と毎日長時間ペアプロしていた。 おもしろかったのが、同僚のテストの書き進め方で、一番複雑な正常系のテストをちゃんと書いてから、その複雑なテストをもとに、いろんな条件を削っていって異常系のテストを作っていく、というところ。 僕は逆で、入力が空なら何も起きない、とか、一番簡単な異常系のテストを書いて、そこだけ通るのを確認して、よしよし、と進めていって、メソッド本来の動きは最後に確認して終わる。 変な進め方だな〜(主観)と思って眺めていたけど、たしかに正常系のテストが通っていれば、あとはバリデーションまわりのチェックとか、例外となる場合のチェックをすれば終わりで、異常系のテストがすごい速さで書かれていておもしろかった。 …という話をしたら、チームメンバーたちは正常系のテストから書きはじめるという人が多くて、正しくことを確認してから、1個ずつ前提となる条件を外してみて試す、と聞いて、同値
時間を区切って設計を打ち切るのはおすすめできない - hitode909の日記
最初にマイルストーンを切って、この週で設計、この週で実装、みたいなことをやるのはおすすめできない。 設計に使える時間を最初に決めた時間までしか使わないということは、どうすればいいか、考えきれてなくても作り始めているということ。 コードは書けていくので、進んでいるようにも見えるけど、問題を先送りしているだけなので、じっくり設計や作戦を詰めていれば気付ける問題に、あとのほうで直面することになる。 この問題を回避するためにはこのように作るべきであった、ということにあとで気づくと手戻りが大きくなり、こんなことをするくらいなら最初に決めておけばよかった、となることが多いと思う。 家を建てることをイメージすると、設計フェーズはここで打ち切って、手を出せるところから始めよう、といきなり柱を建てることをイメージしてほしい。 先のことを見据えると、4本の柱は長方形になっているべきという制約があるけど、そのこ
ISUCON10予選敗退した - hitode909の日記
ISUCON10の予選にid:mangano-itoとid:mizdraと出て予選敗退してきた。 二人はISUCONに出たことないとのことだったので、ISUCONに出たことある人類を増やすのは良い考えだ、というのと、普段からリモートでペアプロしてるので、息のあったメンバーと出てチームビルドのコストを下げよう、という作戦。 全員別拠点で、リモートでの参加なので、コミュニケーションツールをいろいろ用意していた。予選敗退したのであまり参考にならないとは思うけど書いておく。 Discordの音声通話を繋ぎっぱなしにする、常に画面を共有する リモートで無言だと何やってるかわからなくなるので、常にお互い進捗を共有しよう、と、Discordの音声通話を1日中つないでいた。考えたことは何でもしゃべるようにしていて、思いついたあとに、やっぱり違う、と思ったときでもとりあえず口に出していた。Krispのノイズ
今週は技術的な選択の仕方について考えることが多かった - hitode909の日記
今週は技術的な選択の仕方について考えることが多かった。 どうやって決めるか、というだけでなくて、どこに決めポイントがあるか、というところの見極めも難しい。 何も決めずに進んでいって、あとで見返すとすごいことになってしまい、ここをもうちょっと考えておけると良かったね、ということもあるし、考えすぎて重厚に作りすぎだったので、あとからシンプルな形に直していく、ということもある。 個人的には、ふだんはこのように考えています、という手順を書いておくと、 実現方法を考えるだけでなくて、他に取れる作戦がないか考えていく よさそうな方針が、他の作戦と比べてこれが一番良い、という確証を得る 確証が得られないときは、考えて決める 昼休みにプールに行って泳いでいると、これだけ考え続けて何も出てこないということはこれで行くしかない!と決められることが多かった というような形でやっていると思う。これでできるのでこれ
コードを書くには連続した2時間が必要 - hitode909の日記
ある日の午後のスケジュールは、30分ミーティングx2→30分自由時間→そして1.5時間ミーティング、その後は30分自由時間と30分ミーティングを繰り返して定時を迎える…みたいな様子だった。案の定、自由時間で意味ある仕事を進めることはできなかった。 自由な時間が30分あれば、チャットを読んだり、コードレビューしたり、グループウェアを見て回ったり、とかはできる。コードを書くにしても、ここをこう変えれば良いことがわかっていて、書くだけ、とか、ライブラリのバージョンアップ、くらいなら30分で書いてpushしておいて、次の30分でテストが落ちたら直したりして、と進められる。 しかし、そういうことより難しいことをしようとすると、30分だと、さて、問題がどういうものかは分かってきたので、どうしようかな、というあたりで時間切れになってしまう。1時間あれば、ようやくコードを書き始められるかな、というところで
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
