テストケースはもっと書かねばならんが、テスト通ったと言っても最低限すぎるので
November 18, 2025 at 6:50 AM
テストケースはもっと書かねばならんが、テスト通ったと言っても最低限すぎるので
かなり面倒な処理になると思ってたら書いてるうちに既存の実装うまく使ってかなりいい感じに抽象化されたので結果としてそこそこスッキリ収まった
そしてテストも通った！
そしてテストも通った！
November 18, 2025 at 6:48 AM
かなり面倒な処理になると思ってたら書いてるうちに既存の実装うまく使ってかなりいい感じに抽象化されたので結果としてそこそこスッキリ収まった
そしてテストも通った！
そしてテストも通った！
実装に穴があってそれを埋めようとしたけど複雑な仕様になるのは間違いないので丁寧にやらんとバグの温床になるやつなんだ、まだ途中だけどめっちゃ疲れる
November 18, 2025 at 3:43 AM
実装に穴があってそれを埋めようとしたけど複雑な仕様になるのは間違いないので丁寧にやらんとバグの温床になるやつなんだ、まだ途中だけどめっちゃ疲れる
いぬが太ってきちゃったので運動させる、にんげんもする
November 16, 2025 at 4:47 AM
いぬが太ってきちゃったので運動させる、にんげんもする
実装方針が変わった…というか変えざるを得なかったのでそこをやってた
検討が甘かったのもあるんだけどやはりそもそも難しいんだね、目標とする機能を実現するために複雑さが増すところを考慮していない上でだからもうね
うまく着地できるのかしら…
検討が甘かったのもあるんだけどやはりそもそも難しいんだね、目標とする機能を実現するために複雑さが増すところを考慮していない上でだからもうね
うまく着地できるのかしら…
November 14, 2025 at 6:03 AM
実装方針が変わった…というか変えざるを得なかったのでそこをやってた
検討が甘かったのもあるんだけどやはりそもそも難しいんだね、目標とする機能を実現するために複雑さが増すところを考慮していない上でだからもうね
うまく着地できるのかしら…
検討が甘かったのもあるんだけどやはりそもそも難しいんだね、目標とする機能を実現するために複雑さが増すところを考慮していない上でだからもうね
うまく着地できるのかしら…
だからこれ言い出すと**まっとうな一次創作者の作品を勝手に改変して作品イメージぶち壊すえっちな薄い本売る**のも同じ理由で排除しなきゃいけないじゃん、なんで絵師様ってこういう発言で自己矛盾感じないんだろ
生成AIの是非以前に自分たちが何やってるのか分かってないことがヤバすぎるんよね
生成AIの是非以前に自分たちが何やってるのか分かってないことがヤバすぎるんよね
せめて人間らしく。生成AI絵師（ユーザー）のコミケ参入で大荒れする絵描き界隈。迫られる運営の対応。 - posfie
コミケC107のAI参戦についてのまとめです。
posfie.com
November 11, 2025 at 9:31 AM
だからこれ言い出すと**まっとうな一次創作者の作品を勝手に改変して作品イメージぶち壊すえっちな薄い本売る**のも同じ理由で排除しなきゃいけないじゃん、なんで絵師様ってこういう発言で自己矛盾感じないんだろ
生成AIの是非以前に自分たちが何やってるのか分かってないことがヤバすぎるんよね
生成AIの是非以前に自分たちが何やってるのか分かってないことがヤバすぎるんよね
ある機能においてほしいデータが仕組み上どうにも得られないので仕組みの方を変えてみるか、そのデータは他でも使えるかもしれないし！と変更を始めたところ影響範囲が広すぎた上に今後実装する機能にもそのデータに関する記述が増えることを考えたらこの変更は明らかにやっちゃいけないものだと気付き急いで元通りにした
データ自体は工夫してなんとかそれっぽいものを得られるようにしたところ無事テストが通らなかったのでクソァ！
データ自体は工夫してなんとかそれっぽいものを得られるようにしたところ無事テストが通らなかったのでクソァ！
November 7, 2025 at 9:23 AM
ある機能においてほしいデータが仕組み上どうにも得られないので仕組みの方を変えてみるか、そのデータは他でも使えるかもしれないし！と変更を始めたところ影響範囲が広すぎた上に今後実装する機能にもそのデータに関する記述が増えることを考えたらこの変更は明らかにやっちゃいけないものだと気付き急いで元通りにした
データ自体は工夫してなんとかそれっぽいものを得られるようにしたところ無事テストが通らなかったのでクソァ！
データ自体は工夫してなんとかそれっぽいものを得られるようにしたところ無事テストが通らなかったのでクソァ！
とりあえず最小限のテスト書いてから実装を始めたもののぜんぜん集中できない、熱あるからか
November 5, 2025 at 6:37 AM
とりあえず最小限のテスト書いてから実装を始めたもののぜんぜん集中できない、熱あるからか
今でも実は引数の型指定でクラス名書くとそのクラスのインスタンスだけ受けるということができるんだ誰もしらんけど
November 5, 2025 at 2:26 AM
今でも実は引数の型指定でクラス名書くとそのクラスのインスタンスだけ受けるということができるんだ誰もしらんけど
interfaceとか実装予定はあるもののどうやって実装するかとかまったく決まってないけどドキュメントの別の項目で存在をほのめかしちゃったからもう実装するしかないゾ
November 5, 2025 at 2:24 AM
interfaceとか実装予定はあるもののどうやって実装するかとかまったく決まってないけどドキュメントの別の項目で存在をほのめかしちゃったからもう実装するしかないゾ
constやletは完全に不変であることを保証したいんだけどclassインスタンスやCOMオブジェクトだとそうもいかないので困ってたんだよね
let foo = Foo() // class Foo のインスタンス
foo.a = 1 // 代入であれば防げる (エラー扱いにできる
foo.set_a(2) // メソッドで変更されるのは防げない
dim foo2 = foo // 参照をコピー
foo2.a = 1 // これも防げない
なのでそもそもletやconstではオブジェクト参照的な値で初期化しようとしたとこでエラーにすれば良いのではないかってね
let foo = Foo() // class Foo のインスタンス
foo.a = 1 // 代入であれば防げる (エラー扱いにできる
foo.set_a(2) // メソッドで変更されるのは防げない
dim foo2 = foo // 参照をコピー
foo2.a = 1 // これも防げない
なのでそもそもletやconstではオブジェクト参照的な値で初期化しようとしたとこでエラーにすれば良いのではないかってね
November 3, 2025 at 1:54 PM
constやletは完全に不変であることを保証したいんだけどclassインスタンスやCOMオブジェクトだとそうもいかないので困ってたんだよね
let foo = Foo() // class Foo のインスタンス
foo.a = 1 // 代入であれば防げる (エラー扱いにできる
foo.set_a(2) // メソッドで変更されるのは防げない
dim foo2 = foo // 参照をコピー
foo2.a = 1 // これも防げない
なのでそもそもletやconstではオブジェクト参照的な値で初期化しようとしたとこでエラーにすれば良いのではないかってね
let foo = Foo() // class Foo のインスタンス
foo.a = 1 // 代入であれば防げる (エラー扱いにできる
foo.set_a(2) // メソッドで変更されるのは防げない
dim foo2 = foo // 参照をコピー
foo2.a = 1 // これも防げない
なのでそもそもletやconstではオブジェクト参照的な値で初期化しようとしたとこでエラーにすれば良いのではないかってね
ティアーズのSwitch2エディションをアプリと連携しつつやりたいんだけれど、ニンテンドーオンライン入り直さないとたぶんアプリがだめだよね
November 3, 2025 at 9:16 AM
ティアーズのSwitch2エディションをアプリと連携しつつやりたいんだけれど、ニンテンドーオンライン入り直さないとたぶんアプリがだめだよね
12月のDLCももう来月だと思うとはえーもんだな
November 3, 2025 at 9:15 AM
12月のDLCももう来月だと思うとはえーもんだな
今日ついにファンタジーライフiのみんなのお願い (クエスト) の見えてるやつをすべて終わらせた
やっとガチャから砂時計のレシピが出たのでそれの製作をしつつめんどくさくてやってなかったコガネムシの採取もやった
やっとガチャから砂時計のレシピが出たのでそれの製作をしつつめんどくさくてやってなかったコガネムシの採取もやった
November 3, 2025 at 9:14 AM
今日ついにファンタジーライフiのみんなのお願い (クエスト) の見えてるやつをすべて終わらせた
やっとガチャから砂時計のレシピが出たのでそれの製作をしつつめんどくさくてやってなかったコガネムシの採取もやった
やっとガチャから砂時計のレシピが出たのでそれの製作をしつつめんどくさくてやってなかったコガネムシの採取もやった
プログラミングで一番楽しいのはこうやって何をどうやって実装しようか考えてる時なので、半分娯楽だからセーフ！
November 1, 2025 at 4:08 PM
プログラミングで一番楽しいのはこうやって何をどうやって実装しようか考えてる時なので、半分娯楽だからセーフ！
ユーザー定義関数の引数定義を表す型を考えていたら、デフォルト値のある引数や可変長引数は引数リストの最後にないといけないという制約が取っ払えそうな感じになってきた
November 1, 2025 at 4:06 PM
ユーザー定義関数の引数定義を表す型を考えていたら、デフォルト値のある引数や可変長引数は引数リストの最後にないといけないという制約が取っ払えそうな感じになってきた
ドキュメントに書いたことはすべて実装しなければいけないわけだからドキュメントが先行しすぎるの良くないのだけれどなんか流れでいろいろ書いちゃう…ちょっとやり方見直さないとまずいな
せめてテストだけでも書ければ良いのだが…テストさえあればそれ全部通るまで帰れま10できるので…
先にテスト書く、だと仕様の見落とししやすい問題があってやはりドキュメントありきが良い
せめてテストだけでも書ければ良いのだが…テストさえあればそれ全部通るまで帰れま10できるので…
先にテスト書く、だと仕様の見落とししやすい問題があってやはりドキュメントありきが良い
October 31, 2025 at 4:00 PM
ドキュメントに書いたことはすべて実装しなければいけないわけだからドキュメントが先行しすぎるの良くないのだけれどなんか流れでいろいろ書いちゃう…ちょっとやり方見直さないとまずいな
せめてテストだけでも書ければ良いのだが…テストさえあればそれ全部通るまで帰れま10できるので…
先にテスト書く、だと仕様の見落とししやすい問題があってやはりドキュメントありきが良い
せめてテストだけでも書ければ良いのだが…テストさえあればそれ全部通るまで帰れま10できるので…
先にテスト書く、だと仕様の見落とししやすい問題があってやはりドキュメントありきが良い
ドキュメントにすべての仕様を書いていくことでおれがなにを実装すべきなのか迷わなくなるし、ユーザーマニュアルとして見れば書いてないことがもし起きてしまったら不具合を疑えるというわけなんよ
問題はユーザーがドキュメントを読まないことだが…
問題はユーザーがドキュメントを読まないことだが…
October 31, 2025 at 3:53 PM
ドキュメントにすべての仕様を書いていくことでおれがなにを実装すべきなのか迷わなくなるし、ユーザーマニュアルとして見れば書いてないことがもし起きてしまったら不具合を疑えるというわけなんよ
問題はユーザーがドキュメントを読まないことだが…
問題はユーザーがドキュメントを読まないことだが…
1. ドキュメントを書く
2. テストを書く
3. 機能を実装する
という方針は間違ってないと思うんだけど、1で時間がかかりすぎるな
なんかこう思いついたらわかりやすさのために細かいことも書くのでそれはもう手厚いドキュメントが書き上がるのだがそうするとね、どうしてもね
2. テストを書く
3. 機能を実装する
という方針は間違ってないと思うんだけど、1で時間がかかりすぎるな
なんかこう思いついたらわかりやすさのために細かいことも書くのでそれはもう手厚いドキュメントが書き上がるのだがそうするとね、どうしてもね
October 31, 2025 at 8:23 AM
1. ドキュメントを書く
2. テストを書く
3. 機能を実装する
という方針は間違ってないと思うんだけど、1で時間がかかりすぎるな
なんかこう思いついたらわかりやすさのために細かいことも書くのでそれはもう手厚いドキュメントが書き上がるのだがそうするとね、どうしてもね
2. テストを書く
3. 機能を実装する
という方針は間違ってないと思うんだけど、1で時間がかかりすぎるな
なんかこう思いついたらわかりやすさのために細かいことも書くのでそれはもう手厚いドキュメントが書き上がるのだがそうするとね、どうしてもね
今だと
if = 1
みたいなキーワードと同名の識別子を使った式の文に対応できないので明日これをどうにかする
if = 1
みたいなキーワードと同名の識別子を使った式の文に対応できないので明日これをどうにかする
October 30, 2025 at 1:54 PM
今だと
if = 1
みたいなキーワードと同名の識別子を使った式の文に対応できないので明日これをどうにかする
if = 1
みたいなキーワードと同名の識別子を使った式の文に対応できないので明日これをどうにかする
とはいえ意味解析だけにして十分な速度出せるかはわからない
時間差で結果返すやつやらないとダメかもしれんが時間差で結果返すやつやり方がさっぱりわからねえんだ
時間差で結果返すやつやらないとダメかもしれんが時間差で結果返すやつやり方がさっぱりわからねえんだ
October 30, 2025 at 6:42 AM
とはいえ意味解析だけにして十分な速度出せるかはわからない
時間差で結果返すやつやらないとダメかもしれんが時間差で結果返すやつやり方がさっぱりわからねえんだ
時間差で結果返すやつやらないとダメかもしれんが時間差で結果返すやつやり方がさっぱりわからねえんだ
なんやかんや考えたけどやはり意味解析は個別に解析器書くしかねえかなという結論
構文解析と併記できればトークンが現れた状況による分岐だとかに気を使うのが一回で済むけど、意味解析が短いスパンでアホほど実行されることを考えるとその都度構文解析されるの無駄だしなあ
構文解析と併記できればトークンが現れた状況による分岐だとかに気を使うのが一回で済むけど、意味解析が短いスパンでアホほど実行されることを考えるとその都度構文解析されるの無駄だしなあ
October 30, 2025 at 6:41 AM
なんやかんや考えたけどやはり意味解析は個別に解析器書くしかねえかなという結論
構文解析と併記できればトークンが現れた状況による分岐だとかに気を使うのが一回で済むけど、意味解析が短いスパンでアホほど実行されることを考えるとその都度構文解析されるの無駄だしなあ
構文解析と併記できればトークンが現れた状況による分岐だとかに気を使うのが一回で済むけど、意味解析が短いスパンでアホほど実行されることを考えるとその都度構文解析されるの無駄だしなあ
意味付けparserどうすっかなー
最初は独立したparser書こうかと思ったけど構文解析と一緒にやったほうがいいのかなー
構文解析結果から意味付け抜き出すみたいなことしたほうがいいのかな
最初は独立したparser書こうかと思ったけど構文解析と一緒にやったほうがいいのかなー
構文解析結果から意味付け抜き出すみたいなことしたほうがいいのかな
October 29, 2025 at 3:03 PM
意味付けparserどうすっかなー
最初は独立したparser書こうかと思ったけど構文解析と一緒にやったほうがいいのかなー
構文解析結果から意味付け抜き出すみたいなことしたほうがいいのかな
最初は独立したparser書こうかと思ったけど構文解析と一緒にやったほうがいいのかなー
構文解析結果から意味付け抜き出すみたいなことしたほうがいいのかな
重複宣言で解析エラーにする処理を書いて、そのために色々治す必要が出て今ようやくテスト通るとこまで行った
October 29, 2025 at 7:07 AM
重複宣言で解析エラーにする処理を書いて、そのために色々治す必要が出て今ようやくテスト通るとこまで行った