どりきん @drikin@mstdn.guru

ドリカフェ、タイムライン追うと
参加してなくても楽しくなっちゃう。楽しさのおすそ分けをありがとうございました。
改めて、スタッフの皆様、お疲れさまでした。そしてありがとうございました。

取り敢えず、三体は買った

「どうですか？松尾さん。BMPCC4Kと8.9インチモバイルモニタでミニマムVLOG環境ですよ！」
「もういいから三体の話しようぜ」

#ドリカフェ #leicasummicron35mm

ドリカフェ、2次会とも楽しかった。参加してくださったみなさん、裏方でいろいろ動いてくださったみなさん、ありがとうございました。

そしてファミリー青木のみなさんも素晴らしかった。家庭大事、と思った。

#ドリカフェ、オフ会初参加で本当に楽しかったから、今回行けなかったひとが次回参加できるといいな

フォトンエッジさんのインスパイア受けましてw

さっそくステッカー張りましたよ👍

ドリカフェサイコーでした！！
沢山のグルドン民ともお話し出来て楽しかった👍

楽しいオフ会終わり。お疲れ様です

ドリカフェ、2次会、皆さんありがとうございました。とても楽しかったです

帰宅して湯舟に浸かりながら、グルドンはいいですなぁ

もし第2回ドリカフェがあったら、「第1回に参加できなかった人優先枠」もあったらよさそうですね。

そういえば自分もしっかりBMPCC4Kの解像度みてなかったですが、このくらいの解像度で写真とれます
一応rawで撮影できるのでサムネで撮るのにもかなり良いかと！

ドリカフェをマネージした皆さん本当にお疲れ様でした&ありがとうございました

本編301のドキュメントの話にも通じるけど、バグレポートを書くのは読み手のことを考えて書くと良い。

前から順に読んで操作していくと、自分がバグだと思う現象が再現できるととても読みやすい。特に自分が無意識にしている操作をきちんと分解して書く（例: 「あいう、と入力」より「IMEをオンにして、aiuとタイプしてreturn」とかね）

また、自分が「こうあるべき」と考える結果を併せて記述しておくことも大事。

ま、プロじゃないので完璧なバグレポートを書くのは難しいかもしれないけど、読み手への配慮をするだけで随分と違うと思う。

で、技術文書なので思惑とかプライドは捨てて、現象を淡々と書く。「何でこんなヘボイバグが残ってるんだよ！」と憤ってても、文章は冷静に。

フォトンエッジさんの装備。ありがとうございます

さすアマ

ドリママ、ドリ姉さんには、最初のステッカーの配送で手書きメッセージまで入れて頂いてありがとうございました。
と感謝を伝えていただきたい

完成！！