屋久島レイアウトに挑戦する - ③注水! -
ついに屋久島水槽に注水した!
sakura-hidemaru.hatenablog.com
底床用の風山石を撒いたり、後景にブルームウッドを添えたりして少しディテールもプラス。
あとは豊栄養防止のアマゾンフロッグ先生を別の水槽から拝借
Read more
屋久島レイアウトに挑戦する - ②1か月半たって -
sakura-hidemaru.hatenablog.com
屋久島水槽のミスト式を初めて1か月半がたった。
セットしたのが5月末とかだから、ほぼ2か月?
写真で見た感じは、違いがよく分からない。
キノコ
1か月目くらいの朝に見るとキノコが生えてたりしました。
Read moreコリドラスも★になった
帰宅すると、チェリーシュリンプ*2、コリドラスハブロースス*1が★になっていた。
エビでなく、魚も死ぬというのは確実に何か致命的な因子があるに違いない。
ハブローススは水温系とガラスの間で挟まって死んでたため、事故の可能性もゼロとは言えないが、弱ってなければそれ位脱出できるだろう
昨日の事実
- えさ不足を疑い、えさを増やした
- 水質を疑い、水換え量を1/5から1/4に増やした
- 上記3死体意外に脱皮殻があった。
- 亜硝酸・硝酸塩はゼロ
餌の増量で硝酸塩や亜硝酸が即日急増するとも思えない。脱皮殻も踏まえると水替えのショックという事なのか?
しかし換水量を増やしたと言っても、1/4、それも点滴法で換えておりにわかには信じられない。
取り敢えず、えさ不足の線はない気がしてきたので、餌は少量、換水も少量の超低燃費な方針でしばらく放置していこう。
正直、ビーシュリンプとかでもないのにここまで不安定だと人間が疲れてくるので。。。
エビのポツポツ死が始まった
こないだ、久しぶりにエビの死体を見つけたと騒いでいたが、それから今日まで約2週間で6匹のチェリーシュリンプが亡くなってしまった。
原因が分からん。。。
分かっている事実は下記。水質チェックは6in1基準なので曖昧
- pH:6.5~7.0?
- 硬度:低めで安定
- 硝酸塩・亜硝酸:ゼロ
- 水温:26~27℃で推移
- 約3か月前からマツモと浮草を少しずつ減らしている
- 約3か月前から水換え頻度を週2回から週1回に変更している
- 約1か月前からマジックリーフを1枚入れている
- 約1か月前から餌と液肥を減らしている
- 約1か月前に底面をプロホースで掃除した
- 2週間ほど前から冷却ファンを設置している
- 1週間前からシャワーパイプを水上に出している
- ポツポツ死が始まってから、抱卵個体をみていない
- 今日見た死体は脱ぎかけの殻が付いていた(脱皮不全?)
- 外部フィルターは立ち上げ時より2~3週に一度飼育水で濯いでいる
- コリドラスとオトシンは元気そう
推測の難度が高すぎる。。。
- 抱卵個体もいない事から、環境に慢性的な問題がありそう
- 確認した1匹以外も脱皮不全の可能性がある?
- →マジックリーフによる硬度低下?
- →餌を減らしたことも関係している?
- 冷却ファン始動直前は水温が28℃あった
- →急な水温低下によるダメージ?
- →→冷却ファンが直接原因ならばそろそろポツポツ死が収まるはず
今の所の仮説としては、
「マジックリーフによる軟水化と餌削減でミネラル不足した環境において、水温の変化により始まった脱皮の失敗が続出している」
一応説明としてはこれでも通るのだが、確信を持てないし真相は分からない。
やはりオーソドックスに水質悪化を疑いたい気もするのだが、6in1で検出できないレベルの亜硝酸がエビの致死量を満たしている可能性はあるのだろうか。。。
TDD(テスト駆動開発)とRDBは相性が悪い?
SQLがテストコード化できない
SQLをテストコード化する方法ってあるんですかね?ちょっと調べた限りはない気がしている。
テスト用のDBを立ててCRUDのお掃除の仕組みを作るとかが落としどころなのだろうか。どうあがいても、テストコード単体に閉じない何らかの構築が必要になる気がする。
SQL沼つらい
SQLのテストコードとか言ってる時点で察することかもしれないが、今扱ってるシステムは、大量かつ複雑なSQLに依存したつくりになっている。行数もさることながら、使っているRDBMS特有の関数や使用もゴリゴリ使いまくっている。
テストケースを洗い出すのも、手動でDBをチマチマいじりながらテストするのも、非常に辛い。
テストが辛いため、既存のSQLを触るのが嫌になる。だから、既存のSQLにWHERE句を1行足しただけみたいなSQLが脇からポコポコ生えて沼が深くなっていく。
アプリケーションで頑張れ?
SQLにロジック依存した設計がそもそもイケてない。アプリケーションでドメイン定義して、どうぞ。
と言いたくもなるが、訳もなくSQL依存しているわけではなく、専らパフォーマンスが理由でそうなってるのだと理解している。
件のシステムは巨大かつデータ量が半端ないため、速度やメモリ節約の観点から、RDB側でテーブルをJOINしまくってヒント句などを駆使してパフォーマンスを出さざるを得ないのだ。少なくともチーム内ではそのような理解に落ち着いている。
この問題をうまく設計やツールで対処する方法はあるのか?