iOSDC 2025を終えて

はじめに

iOSDC 2025に一般参加としてオンライン＋オフラインで参加したレポ。

参加された方はもちろん、iOSDCをまだご存知ない方のための内容も込めたので、どなたでもお気軽に読んでいただければ嬉しい。

iOSDCとは

iOSDCとは、iOS関連技術に携わる人々が集まる技術カンファレンス。

この「関連」というのがミソで、macOSやwatchOS、visionOSなどの他Appleプラットフォームが含まれるのはもはや序の口で、ネットワークやiOSデバイスに繋いで使えるハードウェア、はたまたチームビルディングなど、iOS開発に何かしらの関連があれば具体的な話題は割と何でもありなところが特徴。

2016年から毎年開催されており、今年でちょうど10回目の開催を迎えた。10周年おめでとう！

私とiOSDC

私が最初にiOSDCと出会ったのは第2回にあたる2017年、そこから毎年参加を続けており今回で9回目。

所属企業がスポンサーをしていたことはあるがスポンサーブースの出展経験がないので、9回連続一般参加である。

参加形態は現在のオンライン(ニコニコ生放送)＋オフライン開催となってからは、day0はオンライン、day1以降はオフラインのハイブリッド型が多い。
（day0も本当は行けたら行きたいのだが、懇親会まで体を持たせようと思うと体力が足りず……）

トーク

iOSDCでは各トーク（とパンフレット記事）にフィードバックを送れるのだが、今年はトークの最後に一斉にフィードバックを書こう！という1分間の「フィードバックタイム」が設けられた。

1分じゃ無理だよ〜！と最初は焦ったが、やってみると意外となんとかなる。

時間が限られる以上どうしても短文にはなるが、送り忘れ防止にはかなり効果的で、その場での新鮮な感覚を忘れないうちに書けるところが良かった。

気になったところを調べたりしてからじっくり書きたい場合は後日配信で見返しながら書くのも手。
（あとで見返すのにタイムシフト予約を忘れがちなので、私は毎年iOSDC開催前後だけニコニコプレミアムに課金している）

テーマ傾向について感想

最近KMPについて話を聞く機会が増えてはいたが、今回のiOSDCでもKMP関連のトークが予想以上に多くなっていて驚いた。

ロジック部分だけKMPで共有しつつUIはそれぞれSwift UI / Jetpack Composeで、といった使い方もできるところが利点なのかなと勝手にイメージしている。

個人的には各々ネイティブで全部できるのが理想だなーと考えてはいるが、そうしたくてもできない状況も往々にしてあると思うので、KMPも今後の動向は追っておきたいところ。

Kotlinも勉強しておかないとかな〜という気になってくる。

day 1

day 1からは8月までお世話になっていた古巣・ディップさんのスポンサーセッションをご紹介。

fortee.jp

登壇者の吉田さんとは担当プロダクトが異なっていたが、どこも割と似たような問題を抱えていた。

テストコードすら書けない状態、という表現がなかなか生々しくて伝わりやすかったのではないだろうか。

もし想像がつかなかったら、あなたのチームがご担当のプロダクトコードを良い形に保てているということなので、今後も大切にしていってほしい。

AndroidにはGoogle推奨のアーキテクチャが存在する、というのを吉田さんと話していて初めて知って衝撃を受けたものだった。

AppleはObjective-Cの時代には公式ドキュメントでMVCを推していたこともあったのだが、Swiftにシフトしてからはアーキテクチャに直接言及することがあまりない印象。

という状況のところに、Androidのアーキテクチャの考え方を応用して構造の整理をしながら少しずつテストを書いていける習慣を築き上げたお話。

サテライト会場では最後が切れてしまっていたが、ディップさんは今回のような切実な課題の解決に一緒に向き合ってくれるエンジニアを募集しているので、週3出社でも大丈夫な方はぜひ一度話を聞いてみてほしい。

Sansanさん・ヤプリさんとの合同勉強会も定期的に開催されているので、そちらもぜひ。

day 2

day 2のチームラボさんのスポンサーセッションでは質問をさせていただいたのだが、これだけ何回もiOSDCに参加していながら、トーク後の質問タイムで手を挙げたのは実は今回が初めてだった。

fortee.jp

いつも言うことが浮かばないので他の人の質疑応答を聞くばかりだったのが、この時ばかりはスッと手を挙げていた。

自分で思っていた以上に今CI/CDが自分の中でアツいテーマだったらしい。

前日の疲れが抜けず朝へろへろだったが、これが聞きたくて頑張って滑り込んだのだ。

iOSと直接は関わりがないこともあってか、CI/CDというのは人によって知識量や関心の偏りが生じがちなトピックの一つであることを近年痛感していたので、今回の取り組みの内容に興味があった。

メンバー全員に意識してもらいやすいようまずは指標を定めて可視化してそれを全員で追うようにする、今後の参考にさせていただこうと思った。

ちなみにこの後見事に元気になり、帰宅まで持病の頭痛に襲われることもなく無事に持った。

間違いなくここでテンションが上がったおかげなので、大感謝。

スポンサーブース

私個人の例年と大きく違うところとして、今回は無職での参加となった。

つまり会社の費用で参加している場合と違って、報告義務がない。

勤怠も切らなくていいし、本当に自分が見たいものを好きに見ていい。

であれば、せっかくなら今日この場に来ないとできないことを中心にするか……ということで今年はスポンサーブースをいつもよりも多めに回ってみよう！と考えた。

現時点で今後の予定が何も決まっていないマジの無職だから、就職活動のための情報収集もしないといけないしね！

……と、day1の時点では意気込んでいたものの……

難しい。

時間配分が難しすぎる。

色々回ったつもりだったが、終わってみれば80社のうち10社ほどしか回れなかった。

ビンゴ全列埋まった人たちはどう配分していたのだろう、全部回ろうと思うと1ブースあたりの滞在時間はどうしても短くなってしまうものなのだろうか。
（と書きながら思ったが、古巣のブースでついつい話し込んでしまったので配分も何もなかった。久しぶりに会った人と話せるのもこの場の意義の一つなので仕方がない）

さすがにこれだけの数のスポンサーがいるとブースの内容もさまざまで興味深かった。

個人的には、自社のサービスの紹介にちょっとした遊び心を乗せたものが好み。
特にMagicPodさんの間違い探しは見事にその両方を兼ねていて感激した。
なるほど言われてみるとUIテストというのは間違い探しだ。

ちなみに正答数は8/10で残念ながら全問正解ならず。

懐かしいキャラクターのぬいぐるみが並んだ古巣のブースを眺めながら、キャラクターがいるとこういう時にも見つけて／覚えてもらいやすくていいなあ、とも思った。

在籍中にSlackで見かけてクスッとしてたバイチュー（※「バイトル」のマスコットキャラクター「バイチュー」をあしらったハイチュウ）、ちゃんともらいました。

新しい会場

記念すべき10回目の開催となった今回、これまでと最も大きく変わった点はやはり第2回以来となる会場の変更だろう。

有明にある有明セントラルタワー ホール&カンファレンスでの開催となった。

私にとっては昨年までの開催地であった早稲田大学理工学部キャンパス（西早稲田)が割と近場であったので、昨年までに比べると移動時間が2倍近くかかるようになってしまったのがちょっと痛手。

こればっかりは、どこで開催しても近い人と遠い人が必ず出てくるので、なんとも難しいところだ。

東京ビッグサイトや東京ガーデンシアターなどイベント会場が集中している場所柄、他の大型イベントとぶつかる可能性があり、実際day2はビッグサイトの大型イベントとぶつかったので、周辺の宿や当日朝の電車、お昼の飲食店は大変だったかもしれない。
（かもしれない、というのはday1の疲れが抜けきらず遅れて参加したため。結果として混雑は回避できた）

会場と同じセントラルタワーに入っている飲食店が土日は休業というのもちょっと痛い。

そうなると次にあてにするのは向かいにある有明パークだが、ビッグサイトのイベントに参加する人もまずここをあたるので、大型イベントにぶつかった場合、混雑は避けられない。

TOC有明やTFT（東京ファッションタウン）まで歩く手もあるが、少し距離があるので行って帰ってくるだけでそれなりの時間がかかってしまうのが難点。

セントラルタワーの店舗のうちローソンだけは営業しているので、買ってきて会場内でさっと食べる人の姿も見られた。

会場での軽食やお菓子の提供もあるが、念のため食事の代わりにできるものを持ち歩いておくと安心できる。

私の場合は試しに買っておいた「ENEMOTI」と「もち麦満腹バー」が役に立った。

どこで食べるか悩んで軽食提供コーナーの前にあるテーブルの並びで食べていたが、エスカレーターから降りてすぐの場所で目立つおかげか、ばったり知り合いに何人か会えたりもした。

おそらくそれを想定して組まれた配置だったのだろうと思う。よく考えられている。

悩ましかった話が続いてしまったが、個人的に新しい会場の良かったところとして、貸切は安心できると感じた。

昨年まで大学の一角をお借りしていたので、夏休み中とは言っても部活や研究のために学生さんが来ていることがあり、自販機や休憩スペースを使うことに申し訳なさがどうしてもあった。

Track Aだけフロアが違うのが最初戸惑ったが、エスカレーターで移動できるのは楽で良い。

エスカレーターの上りと下りで知り合いとすれ違うことが何度かあって、ちょっと面白かった。会えていそうで会えていない。

今回の会場で新しく増えたのが、満席になったセッションを別室のスクリーン上で配信経由で見ることができるサテライト会場。

いわゆるライブビューイングである。

今年はこれがあったことで満席の絶望がいくらか和らいだ（それでもすぐ埋まってしまったが）。

試している人を見かけなかったが、おそらくトーク最後の質問は同室でないとできなかったかもしれない。

参加を迷っている人へ

ここまであまりちゃんとしたレポになっていなくて恐縮なのだが、何かしらの理由で参加を躊躇している人の不安を少しでも解消できればと願って、Q&A形式で書いてみる。

Q：iOSDC楽しそうだけど、自分はiOSエンジニアじゃないので場違いになりそうで心配です。

A：全く問題ないです。むしろ最近はクロスプラットフォームの影響もあってか他の分野から登壇する人も増えてきています。
何ならエンジニアじゃなくたって興味さえあればOK。
エンジニアと一緒にお仕事するデザイナーさん、マーケターさん、チームのマネージャーさんなど。
その場合専門性が高いトークの内容を理解するのは難しいかもしれないが、スポンサー参加であればブースに立って訪れる人と話したり、まずはLTだけ覗いてみるのも良いかも。

Q：iOSエンジニアだけど、iOS関連の知り合いが誰もいないので、ひとりで行っても浮きそう。

A：個人的には、そう思う人こそぜひ会場に来てみてほしい。こういう場に来ると自然と知り合いができます。
私も、初参加の時点ではiOSの知り合いゼロだった。
新卒で入った会社で最初のiOSエンジニアになり、外との交流がなかった私に隣のチームの先輩にこういうのあるよと教えてもらったのがiOSDCとの出会いだった。
特に懇親会が絶好のチャンス。
近くに来た人に話しかけてみたり、聞きに行ったセッションのスピーカーに出会えれば感想を伝えるのも良い。
日頃から定期的に自社や有志で勉強会を開催してくれている人たちも大勢いるので、そういった場への参加のきっかけにもなる。
他の勉強会で知り合った人とiOSDCでまた会える。
こうなれば、もうひとりじゃなくなっている。

Q：会場は行ける距離ではあるんだけど、参加できない日があるから、オンラインのみ参加かな……

A：費用さえ大丈夫なら、1日でも半日でも来られる可能性があればぜひともオフライン＋オンラインチケットをおすすめします。
オフライン参加の場合も配信を見る権利はついてくるので、最終日のLT以降だけ会場行きたい！とかも全然あり。
こうして参加スタイルを自由に選べるのもiOSDCの魅力の一つ。

さいごに

途中チラッと言及した通り現在無職で、これから就活なので来年のこの時期に自分がどうなっているかまだわからないが、間違いなくiOSDCには参加する。
来年のiOSDCでお会いしましょう。

iOSDC会場で僕と握手！！

Slack Events API + GASで簡易的にGitHubのアクティビティを見てみる

この記事は Ubiregi Advent Calendar 2020 21日目のエントリです。

本日は、GitHub上のアクティビティを監視・集計する方法としてこんなやり方もできる、という小ネタをご紹介。

Pull Request(以下、PR)やIssueの状況をウォッチするために、GitHubのSlack Appを連携させて使っている人も多いだろう。
対象のリポジトリや項目をスラッシュコマンドで設定すれば、それぞれのアクティビティがSlack上に流れてくるというもの。

これはつまり、GitHub上のアクティビティをSlackのチャンネル投稿イベントとしてSlack Events APIで扱うことができるということでもある。
GitHub連携をしているSlackチャンネルの投稿を監視するだけで、マージ待ちのPRをリスト化したり、PRのopenからcloseまでの時間を計測したりといったことが簡易的ながら可能になる。

そんなことしなくても普通にGitHub webhooks使えばいいじゃん、と言われればまったくその通り。
そこが小ネタたる所以である。
とはいえ、Slack Events APIをすでに使い慣れている場合はもちろんのこと、

• チャンネル投稿の読み取り権限(channels:history)さえ設定すれば、SlackのGitHub連携に流しているイベント全てが取得できる
• リポジトリのAdmin権限が不要

といった特徴があるので、こちらの方が使いやすい場面ももしかしたらあるかもしれない。

ここでは、GASでSlack上のGitHub通知の内容を取得できるようにするまでの流れと、取得した情報のどこに何が入っているかまでを紹介する。

GASプロジェクトの準備

Slack Appの実装にここではGoogle Apps Script(以下、GAS)を使用する。

GASを選択するメリットとして次のようなものが挙げられる。

• Googleアカウントがあればすぐに使い始められる
• 実行回数が無制限
  • 1回あたりの実行時間には6分までという制限があるが、Slackの投稿イベントで飛んでくるjsonはとても小さいので、よほど複雑で重たい集計をしようとしない限りは収まるはず
• スプレッドシートなど他のGoogleサービスとの連携が容易
  • 集計結果をそのまま共有可能な形にしたり、スプレッドシートの数式も組み合わせて集計自体を楽にすることもできる

※V8ランタイム登場前に書いた少し古いコードであること、元々jsが専門外であることなどから、洗練されたコードにはなっていない点は何卒ご容赦いただきたい。

プロジェクトの作成

GASのホームから「新しいプロジェクト」を押して新規のGASプロジェクトを作成する。
スプレッドシートと組み合わせて使うことが決まっていれば、まずスプレッドシートを作成して ツール＞スクリプトエディタ と進んでシートに紐づいたプロジェクトとして作成してもいい。

URL確認イベントへの対応

このプロジェクトでSlackからのイベント通知を扱っていくわけだが、イベント通知の送信先URLを設定すると同時にURLの確認イベントが飛んでくる。
中身を実装する前に、まずその対応を先に入れておくと設定がスムーズである。

GASでは doPost() という名前の関数を実装しておくと、WebアプリとしてデプロイしたときのPOSTリクエストの受け口になる。
こんな感じで、url_verificationイベントが飛んできたらその中に含まれるchallengeというフィールドの値をそのまま返すようにする。

function doPost(e) {
  if (e.postData == "FileUpload") {
    var contents = JSON.parse(e.postData.contents);
    var type = contents.type;

    //URL確認
    if (type == "url_verification") {
      return ContentService.createTextOutput(JSON.stringify(contents.challenge)).setMimeType(ContentService.MimeType.TEXT);
    }
  }
}

ここまででいったん、右上の デプロイ＞新しいデプロイ から、現在の状態をWebアプリとしてデプロイする。
ここで「アクセスできるユーザー」は「全員」になっている必要がある。

一度デプロイすると、 デプロイ＞デプロイを管理 からURLが取得できるようになる。

Slack Appの準備

Slack Events APIのイベントを受け取るにはSlack Appを作成することになる。
ここでは今回やること向けに特化したポイントに絞って説明していくので、Slack App自体のセットアップ方法などについては別途ドキュメントを参照されたい。

Enabling interactions with bots | Slack

ワークスペースで利用するボットの作成 | Slack

スコープの設定

作成したSlack AppのOAuth & Permissionsのメニューからスコープを設定する。

投稿イベントの取得自体は、Bot Tokenのチャンネル投稿の読み取り権限 channels:history さえあれば動作する。
集計結果を投稿させたい場合などは書き込み権限 chat:write も必要になる。

User Tokenはここでは使用しない。

イベントへの登録

Event Subscriptionsのメニューから Enable Events のスイッチをOnにし、受け取るイベントを設定する。

前述の通りチャンネル投稿を見たいだけなので、Bot User Eventsの message.channels を選べばOK。

channels:history スコープが必要なことはここで言われるので、こちらを先に設定しても良い。

イベントの通知先URLの設定

同じくEvent Subscriptionsのメニューで、イベントの通知先URLを設定する。
Request URL の欄に先ほど作ったGASプロジェクトのURLを貼り付ける。

先ほど作っておいたURL確認の実装が正しければ、すぐに確認が完了し Verified というラベルと緑色のチェックマークがつく。

これで、Slackからチャンネル投稿を受け取る準備ができた。

GitHub通知の投稿内容の取得

message.channels イベントで飛んでくるjsonの中身はこのようになっている。
ここから event 要素を取り出して見れば良いのだが、全てのチャンネルに投稿があるたびにこの関数が呼び出されることになるので、まず扱うケースを適切に絞り込んでいく必要がある。
チャンネルIDが監視したいチャンネルでない・発言者がGitHub Appではない投稿は全て除外してしまおう。

function doPost(e) {
  if (e.postData == "FileUpload") {
    var contents = JSON.parse(e.postData.contents);
    var type = contents.type;

    //URL確認
    if (type == "url_verification") {
      return ContentService.createTextOutput(JSON.stringify(contents.challenge)).setMimeType(ContentService.MimeType.TEXT);
    }
    else if (type == "event_callback") {
      var event = contents.event;
      var event_type = event.type;
      
      if (event_type == "message") {
        var user = event.user; //投稿したユーザーID
        var channel = event.channel; //投稿があったチャンネルID
        if(channel == <監視したいチャンネルID> && user == <GitHub AppのユーザーID>){
          //投稿内容を取得
          var attachment = event.attachments[0];
        }
        //それ以外は何もしない
        return null;
      }
    }
  }
}

GitHub Appの投稿から情報を取得する際にわかりにくいのが、内容が全て attachments 扱いであるという点。
attachments は配列として返されるので、内容にアクセスする前にまず配列として取得してから1つ目の要素を取り出す必要がある。

Pull request opened by hogehoge のメッセージなどいかにも本文、 text であるように見えるのに、実際は attachments の中の pretext 要素である。

attachments 要素のフィールド一覧は公式ドキュメントの以下のセクションで見ることができる。
Creating rich message layouts | Slack

GitHubの通知の項目はそれぞれ以下のフィールドに格納されている。

項目	attachments内のフィールド名
本文(Pull request opened by hogehoge など)	pretext
PRやIssueのauthor名	author_name
PRやIssueのタイトル	title
PRやIssueへのリンク	title_link
PRやIssueの本文	text
リポジトリ名	footer
イベントが作成された日時のタイムスタンプ	ts

さらに、タイトルについては #id タイトル の形式にまとめられているので、少し乱暴だが

  var title = attachment.title;
  var id = title.match(/[0-9\s+]/g).join('');
  id = id.split(' ')[0];

こんなことをやると、PRやIssueのIDだけを取り出すことも可能になる。

ステータスについては pretext に opened 、merged、closed などの単語が含まれているかどうか、で簡易的に判別が可能である。

全てのイベントは日時も一緒にわかっているので(タイムスタンプからの変換は必要だが)、これらの項目を使った集計となるとけっこういろんなことができる。
集計以外にも、例えばPRがマージされたらデプロイ手順を投稿する、といった使い方もできる。

簡易的に、を繰り返しているのはこれらの仕様は変わる可能性があるためである。
Slack向けGitHub Appのソースコードは以下で公開されているので、「なんか挙動変わったかな」と思ったら覗いてみると良いかもしれない。
(この記事は過去の実装経験に加え現時点でのGitHub Appのコードもざっと確認した上で書いている。が、もし見落としがあればご容赦願いたい)
https://github.com/integrations/slack

応用例についてはまた機会があれば触れる……かもしれない。

iOSDC 2020感想！

めちゃくちゃお久しぶりです。

半年ぶりくらいだろうか、生きてます。

始めてすぐから月に1回くらいしか書いていなかったが、まあ見事にサボっている。

ところで、このブログを始めたときのご挨拶が以下の記事。

ごあいさつ - Y.Graceの記録

そう、iOSDC。

iOSDC！！(大声)

さすがにこれは何か書かないと、このブログを作った意味がないと言っても過言ではない。

特に印象に残ったトークのピックアップとその一言感想まとめを並べるくらいしかできなさそうだが、最初のハードルを下げておかないとほんとうにやらない人間なので、とにかくやってみることにする。

前提：iOSDCとわたし

• iOSDCには2017年から参加しており、今回が4回目
• いずれも、参加形態はトークを伴わない一般参加枠
• iOSDC中、よくランチについて大騒ぎしている食い意地の塊がわたし

#iosdc 言う機会逃してましたが毎日提供されるお昼ごはんがすっっっっっごく美味しかったんですよ去年に引き続き　カンファレンス体験としては地味に重要なところなのではないでしょうか……！おいしいごはん、だいじ。

— Y.Grace (@y_01011001) 2018年9月2日

お昼休みが終わる前に食い意地の張った疑問を放流しますけど、お弁当どれ選んでも必ず入ってる赤紫色の天ぷらみたいなやつって何者でしょうね……？昨日は部屋が暗いから分からないとおもってたけど、今日明るい部屋で改めて見ても何だか分からなかった……気になって夜しか眠れない #iosdc

— Y.Grace (@y_01011001) 2019年9月7日

 

前夜祭

• オーディオの処理に明るくなくとも聞きやすいと感じるわかりやすさ
• 某広告SDKで、広告のAVSessionを取り出して設定をしておかないと(それ自体は音声を扱わないアプリであっても)裏で再生中の音楽が動画広告に止められてしまう、などというアクシデントを経験したりもしたので、この辺りは自分が直接音声を扱わなくても知っておくに越したことはないなと思った

• ハードウェア側の知識がさっぱりぽんなのでハードルを感じていたHome Kitだったが、案外何とかできそう、やってみたいかも、という気持ちになれた
• 最近、家電の制御をちょいちょい自動化したり音声入力対応しているチームメイトがちらほら居るので、少し気になってきているところ

1日目

• RxSwiftがいまいちあたまに入らず、まあ3rd partyだし無理に入れなくても……と言い訳して避けてきた身で、Combineこそは向き合わねばならないと思いつつ全然向き合えていなかったので、ここまで詳しい解説に出会えたのは幸いだった
• タイムシフト期間中にもう少し見返して、理解を深めたいところ
• もう1年経つのか……確かにそろそろやらなきゃか……という気持ちに実際なったので、このタイトルすごいと感じた

• 設計に関しての意識が弱いまんま生きてきてしまったわたしが、今頃になってようやく学んでいるのがまさにこういう話で、今聞けてとてもありがたかった
• 勉強になった、とだけ言ってしまうと月並みなので、何だろうな……漠然としていた疑問から、もう少し具体的に考えていけそうなきっかけをもらえた気がする
• 処理の流れを一方向にする、という話についてはここ↓などでも読んでいて、改めてこれが肝の一つなのだなと実感した
  Clean architecture for iOS (VIPER/VIP) | by Saad El Oulladi | Medium

• 今の会社に移って初めてiPadを扱うことになったわたしが最初に取り組んだのがマルチタスク(Slide OverやSplit View)対応だったが、複数ウィンドウ対応については見送っていて知識が少ないところだったので興味深く聞いていた
• SceneDelegate対応……しないとな……
• iOS 12は年末頃には切れそうかなー

2日目

• Storyboardの分割ってRefactorメニューからできたんだ……というのを初めて知った。今までコピペしてた……
• 特定のOSバージョンだけ表示する画面の分け方など、コード側でif availableを書きまくるしかないとばかり思っていたので、なるほど……！と言いまくっていた

• 現代のプログラミング教育必須化には懐疑的な立場なのだが、こういうことを教われる場があるのはいいな〜〜〜と思えた、ほんとうに大切なこと
• 初回審査のリジェクト0という成果が半端ない

全体

• オンライン開催ゆえ、遅刻しても最初から聴けるし、同時刻の別トラックのトークもその日のうちに聴けるのはありがたかった
• Today's updateとかで長谷川さんが画面に登場するのすごくよかった、後述の通り寂しかったので……
• コメント欄にさりげなくご本人が降臨してたりするのがちょっと面白かったが、さっと質疑応答できてたところなど見ると事前収録なのはよかったのだろうなと思った
• LTがちょっと大変そうだった、Zoom越し(だっけ)のLiveとなると自分の音声がどう聞こえているかとかチェック難しいよね
• オーディオ勢の音声が安定しているのはさすがと思ったが、それ以外のスピーカーさんもほとんど音声クリアですごいと思った

個人的反省

• オンライン開催だからって油断していたらチケットを買うのが遅れてしまった……気がついたときにはすでにノベルティボックス終了、無念……
• ニコニコ動画とかログインしたのが10年以上ぶりで、そもそも使い方ろくに知らないので右も左もわからなかった……もうちょっと予習しておくんだった
• 「あれ、居たの？見かけなかったけど」と思ってくださった方もいるかもしれない。家の用事が重なったり、具合が悪くてちょっと寝たりで絶妙に時間が合わなくて、ほとんどのトークを追っかけ再生で見ることになり、コメントはできないわDiscordも間に合わないわ、時間ずれちゃってるから実況ツイも全くできないわで、けっこう寂しいことになってしまった
• 反省の反省なのだが、時間外だからと諦めきってDiscordは覗きもしなかったのだが、雑談chならもしかしたら誰か居たかもしれない……覗いてみればよかった

余談：個人的進歩

• 「サンプルコードが……読める……読めるぞ……！」
• やっとSwiftにも目が慣れてきたので、今年はみなさんのサンプルコードをスッと読めるようになった。やったね。

総合的な感想としては「よかったけど、来年はオフラインがいい」かなーという気持ち。

来年はわいわいお話できたらいいな。

お疲れ様でした！

45cm水槽に引越し

今年の目標の一つであった水槽のサイズアップが無事に完了してしばらく経ったので、記録を残しておく。

どう変わったか

水槽

27cmキューブ　オールガラス水槽　アクロ27
→ 45cmフレーム水槽 プログレ450
水量にして約15L→約37L

旧環境に言及したことがなかったが、27cmキューブという小型も小型の水槽であった。
30cmキューブではでかすぎる気がして、かと言って25cmキューブでは心許なくて選んだサイズだった。
20kgくらいだからギリギリ……とメタルラックにおそるおそるハードウレタンを敷いてこの27cmキューブを置いていた。
そんな自己責任アクアリウムからもついに卒業である。
とはいえ最初に覚える水槽としてはちょうど良いサイズ感だったかもしれないとも思うし、トリートメント水槽として今後も使うことになりそう。 実に約2.5倍のサイズアップになった。
この大きさでフレームレスは怖いなと感じたので、枠付きのプログレを選択した。
使えなくなったり使いにくくなった機材もあるにはあるが、基本的には安定感があって安心できる印象。

水槽台はGEXの2段式のものを使用。
下段にはいまのところ予備のプラケースやバケツなどを置いているが、こちらも45cm水槽一式を置けるつくりになっているので、稚魚などのプラケースなどはここに置けそう。

現環境で一つ心配なのが水位。
旧環境では濾過が水作エイトのみで、水位はヒーターさえ浸かっていればOKだったので、地震に備えて水位を上から5cm以下に抑えた結果だいたい15Lだったのだが、今回は上部フィルターの都合でかなりギリギリまで水を入れないといけなくなり、約37Lが死守ラインになってしまった。
この線の上まで水を入れてください！を厳守するとフレームの上から3cmくらいしかない。
地震が来たときに溢れないか、夏場に冷却ファンを回したらあっという間に最低水位線を下回らないか、色々不安である。 これでも従来品よりも水中モーターの位置を下げたと書いてあったので、以前は本当にスレスレだったのかもしれない。

濾過

水作エイトS
→スーパーターボトリプルボックス450＋ボトムボックス450

水作エイトにはずいぶん世話になったのだが、45cm水槽でMを使うかというと……現物の大きさを見るとやっぱやめようという気持ちになった。
検討の結果、上部＋底面の組み合わせにした。
外部は私のようなうっかり屋が使うとメンテのたびに外し方を間違えて床を水浸しにすると思ったので避けた。
プロホースを使った底砂の掃除はけっこう好きな方でサボらない自信があったので、底面フィルターを採用してみた。 上部フィルターとの組み合わせなので、エアーポンプは使わず水中モーターのみ。
エアーポンプを動かさないのは外掛けフィルターを使っていたとき以来だが、やはり静か……。
置き場所が旧環境よりも枕元から離れたのもあり、モーター音はほぼ気にならず、水の流れる音が聞こえる程度。
(旧環境で使っていたエアーポンプは水作の水心で、エアーポンプとしてはかなり静かなものではあるのだが、やはりないと違う)
ちなみにこの組み合わせで繋ぐのであればボトムボックス用接続パーツは不要だったのだが、要ると思って買ってしまった……。

ヒーター

温度固定式55W
→GEX ヒートナビ 120

買い替えついでに、温度可変式にしてみた。
稚魚水槽で温度可変式を使っていて、水中モーターや気温の変動など水温に影響する外部要因があるときに調整ができるのが便利だと感じたので。
温度可変式だとONになっているときにランプが点くものが多いので動作状況が見えやすいというのもある。
縦でも横でも置けるのが地味に便利。
25℃に設定して、25.5℃あたりにキープしてくれている。

照明

ニッソー スマートタッチ
→フラットLED SS 4052

これはプログレのセットに入っていたのをそのまま使っている。
防滴仕様でないので水槽に蓋をした状態でないと危ないため、蓋を開けるたびに濡れない場所にどかさないといけないのが少々面倒ではあるが、軽さと明るさと色味は好き。
楊貴妃のオレンジがとても綺麗に見える。

底砂

水作のメダカ飼育基本6点セットに付属していた砂利
→水作　珪砂

これには色々あって、ほんとうは同じものを買ったつもりだった。
たぶん商品としては同じもののモデルチェンジの境目を跨いだのではないかという気がする。
というのも、水作のメダカ飼育基本6点セットの箱での底砂の表記が「底砂(珪砂)」となっていて、某通販で水作の「珪砂」という商品を見るとまさにそれと同じ姿をしていたので、同じものを買い足すつもりで買った。
すると届いたのは水作の珪砂という名の、まったく特性の異なる砂であった。
いま水作のホームページを見にいけば珪砂という名で載っているのはこの砂なので、某通販が入れ間違えたのでもない。
おそらく昔は珪砂という名前で砂利を販売していたのが現在の砂にモデルチェンジして、私が買ったメダカ飼育基本6点セットに入っていたのは旧モデルの砂利の生き残りだったのではないかと勝手に推測している。
想定より細かい砂が来てしまったので、ボトムボックスには百均の洗濯ネットを被せて使っていて、いまのところ詰まった様子はない。
とはいえ、明るい色のとても綺麗な砂なので、これはこれで良かったと思う。

水草

小さなマツモ数本
→ すごく立派なマツモ大量、アヌビアスナナ付き流木

水草はいずれもアクアフォレストで購入。
アヌビアスナナは水槽を大きくするなら入れてみたいとかねがね思っていた。
流木付きなので置くだけでかんたん、かわいい。
基本的にはマツモ中心にしておこうと思っていたので、お店で元気よく
「(^o^)マツモ5本クダサーイ！」
と叫んだところ1本の大きさを勘違いしていて、マツモのおばけみたいなのが5房きた。
あっという間にマツモの森ができあがった。
水草専門店のマツモを完全にナメていた。
少し多すぎだろうかと心配したのだが、いまのところ夜間に酸素が不足する様子もなく、むしろいじめっ子に追いかけ回された子がスッと隠れるなどして逃げ切ることができていたり、時折葉の間で休んでいたりと、マツモの森の居心地はそう悪くないようだ。
おまけに硝酸塩をガンガン吸ってくれているようで、増加ペースはかなり緩やか。 あるのとないのとでは大違いだと思った。
ただしすごい勢いで伸びるので、週に1回はトリミングしないとえらいことになる。

作業期間

セットから引っ越しまでおよそ7日間。
置き場所を変えたので、置き換えではなく予めセットしておいてそこに移すという通常の引越し。
まずキッズに先に移動してもらい、1日様子を見て問題ないことを確認してからおとなたちも移動、と引越しには2日をかけた。
なかなかの強行日程だったとはおもうが、現環境にすぐに慣れてくれたようで、各自のんびり過ごしている。

所感

水槽台を置くために大きな古い本棚を撤去する必要があったり、なかなか大掛かりな移行作業だった。
セットこそ大変だったが、水量が多い方が水質の変化が緩やかというのは言われている通りの印象。
何よりめだかたちが心なしか以前より伸び伸び暮らせていそうなのが嬉しい。

広さに余裕ができたところで新しい子をお迎えしたい気持ちになってくるが、それが叶うのはいつになるだろうか……。

繁殖ふりかえり

卵の状態で年を越して1月上旬に孵った稚魚たちが、先日ようやく親水槽に合流を果たした。
めだかを飼い始めて最初の繁殖はこれでひと段落したと言って良さそうなので、少しはエンジニアらしく、KPTの形で振り返ってみる。
(iOS話もしたためてはいるのだがなかなかまとまらなくて……)

Keep

ゾウリムシ

これは非常に万能で役に立った。

スポイトで水槽に適量放り込んでおくだけで良く、粉のえさのようにあげ過ぎを気にすることもない(もちろん限度はある)。
これのおかげで、日中えさをあげられない我が家でも多くの針子たちが生き延びてくれた。
稚魚の他にも、ボスめだかにえさを独占されてお腹を空かせていた大人のめだかにこっそり食べてもらうものとしても役立った。

米の研ぎ汁だけで簡単に殖やせて維持も簡単なので、育てておいて損はない。
猛烈に臭いという痛い欠点はあるが、口の狭い容器にそっと蓋を置いておくくらいなら部屋に置いていてもそれほど気にならなかった。
与えるときにはどうしても臭うのでそのときは仕方ない、むせる。

培養容器はペットボトルのほかに、チャームで水草ポットとして売られていたパスタ入れのような容器も使っている。
この容器は円筒形をしているぶんペットボトルよりも足し水がし易く、けっこう扱いやすい。

メダカバイコム

バイコムシリーズのメダカ向けモデル。
今回稚魚水槽で初めて使ったのだが、キャップで測って入れるだけのこいつは非常に使いやすく、効果も実感できた。
稼働後間もないスポンジフィルターとバイオろ材をセットしたばかりのスペースパワーフィットプラスを併用した環境に投入したところ、数日で亜硝酸が出なくなり、硝酸塩の増加もかなり緩やかで、減ったぶんの足し水と掃除のみで基本的に水換えは不要の環境ができた。
(稚魚6匹に対して約7Lのプラケースを用いたので水量の余裕も関係あったとは思う)

毛糸の産卵床

市販のスポンジ製の産卵床をなかなか使ってくれず、結局そのへんに落として「卵？どっかやっちゃったー」とお母さんめだかが言うので、茶色の毛糸を使って自作してみた。
目指したのはホテイアオイの根である。
ちょっと長すぎて存在感がありすぎたのだが、ちゃんと使ってくれた。
これを使い始めてからやっと採卵できるようになった。
この色は使わないなあと余らせていた糸だったので、使い道が見つかってありがたい。

なかなか良い出来では？！とおもっていた

浮かべてみるとまるでタコ…………

でかいスポイト

GEXから出ている、めだかの稚魚育成用にという触れ込みのでかいスポイト。
ほんとうにでかいのでけっこう扱いは難しいのだが、卵をそーっと移動したりするにはこのくらいの太さが良い。
また水槽の底掃除に大変便利な大きさだった。
便利なのだが扱いはほんとうに難しい。
吸い込んだあと先の方からどうしても少しこぼすので、卵を運ぶときは吸い込んだらすぐに反対側の手で先を塞ぐようにして持つことでなんとかした。
卵だからそうしたが、ゴミを捨てるときにはあまりやりたくないものである……。

---

Problem

投げ込み式フィルター

わかってた……わかってたはずなのだ、稚魚に投げ込み式はいかんというのは。

最初に使っていたプラケースは深さが足りず、手持ちのスポンジフィルターが設置できなかった。
まだ針子と言えば針子だが隙間に対してギリギリくらいの大きさにはなっているから、水作エイトコアミニくらいなら大丈夫だろう！と油断した。
エアレーションもしていたから、そのエアストーンがぶくぶくに変わるだけで問題ないと思っていたのだ。
大問題だった。
せっかくゾウリムシのおかげで生き延びていた針子たちの半数近くが吸い込まれて亡くなった。 申し訳ないことをしてしまった……。

---

Try

最初から大きなプラケースで孵化させる

もうこうして言葉にしてしまうと当然なのだが、最初からスポンジフィルターを設置できる大きさのプラケースを用いるべき。

ただ無精卵でないかどうか・発眼しているかどうか見極めるには小さい容器が見やすかったので、採卵したらまず見やすい容器に取り分けて数日観察した後、発眼を確認できたらスポンジフィルターを稼働させたプラケースにでかいスポイトでそーっと移動するのが良さそうだと思った。

---

一番やらかしたのはとにかくフィルター吸い込み事件だったと思う……
それでもなんとか6匹の稚魚が幼魚まで育ってくれている。
大変ではあったがやはりこれも醍醐味だよなあと実感したので、殖やしていきたいと思ったし、今後めだか以外の魚も飼うとしたら水槽で繁殖できる種類を選ぶと思う。
それには現在の27cmキューブ水槽では小さすぎるので、今年の目標は実に『45cm水槽立ち上げ』である。
現在絶賛準備中。

地震にビビる。水位と蓋は大事

久々の緊急地震速報で飛び起きた。

めだかたちを家に迎えてから初めて震度3級の地震を経験したが、なかなかに怖かった。
真っ先にやばいとおもったのがベビー水槽。
昔使っていたプラケースを引っ張り出してきて使っていたもので、蓋がなかった。
おまけに前の晩の水換え時に少し水を多く入れすぎ、蓋がないからじきに蒸発するだろうとそのまま寝たらおもいっきりフラグであった。
飛び起きてすぐに手で押さえて揺れの影響を軽減させようとしたが、次第に揺れが大きくなってきたので棚から離す必要があるとおもい、持ち上げたまま頑張って静止するように努めてなんとか凌げた。
咄嗟に持ち上げられたのは3.5Lのプラケースならではであったとおもう。
それで手が塞がってしまったのでおとな水槽には何もできず、不安の中見守っていたが、もともと水位を少し浅めにしていて上から5cm以上の余裕があったおかげか、幸い蓋の隙間から溢れるようなことはなかった。
外掛けフィルターを使用していた頃は上から2〜3cmくらいまで水が入っていたので、その状態だったらどうなっていたか……。

めだかたちは少々パニックだったが、水面よりも底の方が揺れないことに早々に気付いてサッと土管の中に隠れる子も居た。賢い。

現在7匹居るベビーはそろそろベビーというよりはキッズの大きさになってきて、倍のサイズのプラケースに引っ越しを考えて立ち上げている途中だった。
そんなわけで手が塞がっていたのでその立ち上げ途中のキッズ水槽も見守ることしかできなかったのだが、そちらも水位には余裕を持たせてあったので溢れることはなかった。
が、やはり蓋はあるに越したことはないので自作したほうがいいかもしれない。

一方おとな水槽も、ガラス蓋があるとはいえ、上部フィルターや外掛けフィルターを使用しない状態ではガラス蓋は隙間が多すぎると今回改めて感じたので、別の蓋のほうがいいのかもしれない。

蓋自作の機運高まる……？

水槽立ち上げまでの道のり

水槽を始めたのはごく最近で、前職を辞めて有給消化に入ってからのこと。

辞め側の一番しんどかった時期に、帰宅後なぜか「熱帯魚 飼い方」でググったまま寝落ちていたことが何度もあった。

まったく脈絡のないことでなぜそんなことをしていたのか自分でも謎なのだが、子供の頃から水族館が大好きだった私が極限の状態で求めた癒しがお魚ということだと捉え、ググって寝落ちた検索結果を片っ端から眺めるうちに改良めだかに興味を持ち、有給消化に入ると同時に最初のめだか水槽を始めた。

一度のリセットを経て現在は楊貴妃4匹、幹之1匹の計5匹と、年明けに生まれたばかりのベビーたちと暮らしている。

12月の親水槽。楊貴妃たちが合流して間もない頃

しれっと書いたが最初に作った水槽は様々な失敗を重ね、おむかえした6匹全員を失い、1ヶ月足らずでリセットする羽目になった。

外掛けフィルターを訳もわからずそのまま使ったり、底砂掃除の正しいやりかたも弁えていないのに底砂を厚く敷いたり、水面にえさを大量にぶちまけてしまったのに換水の対処が遅れたり……失敗が山盛りであったと反省しているが、そのうえさらに不運も重なった。

おむかえした子の中に元々尾腐れ病と水カビ病の初期症状を併発していた子が居たり(初日に気付けず、後日これはもしや？となったときに初日に撮った写真を見返したら最初からだった)、さらに水草には貝、極め付けにミズメイガの幼虫までついてくるという不運ぶり。

水草は水道水でジャブジャブ濯いではあったが、そんなものでは足りないことも知らず……。

不自然にスパッと切れたアナカリスの葉をあちこちで見かけては不思議におもいながら過ごし、やがて誰も居なくなった水槽を洗おうと覗き込んだら羽化したてのミズメイガと目が合って絶叫したものだった。

めだかたちを死なせてしまったのは完全に自分の責任ではあるものの、病気の子が紛れていたのは事実なので、なんとなく通販で生体を買うのはやめておこうかな……という気持ちに。

あとアナカリス。蛾はつらい。

第2陣は地元のホームセンターから楊貴妃1ペア、幹之1ペアをおむかえ。

輸送時間が短ければ負担も少ないはず、と踏んだからだったが、また気合いが色々と空回りして、トリートメント水槽で様子を見ていた僅か1週間の間に実に4匹のうち3匹が☆に。

その中にはものすごく美人の楊貴妃♀も居り、気に入っていたのでかなり凹んだ。

唯一生き延びたヒレ長気味の幹之♂はよほど丈夫らしい。

最初は水面からえさを食べられず水中に落としてやる必要があったが、他の子が居なくなってひとりになるとふつうに水面から食べられるようになった。

それからはよく食べるし好き嫌いもしない。

その横でメイン水槽を作り直した。

フィルターは素直に投げ込み式にして、水草を植えないので底砂は掃除のしやすさのために浅めに敷いた。

実際に底砂掃除をしてみると掃除がしやすく、この方法は自分には合っていたと思う。

投げ込み式にした理由は、せっかくバクテリアが住み着いたかもしれないろ材を2〜3週間に一度のペースでまるごと捨ててしまう外掛けは初心者にとって扱いが難しいのでは？と感じたため。

写真にも写っている通り、水草はマツモにした。

アナカリスはちょっとトラウマである。

少しの間、幹之くんは水槽を広々と使って一人暮らしを謳歌することに。

第3陣は新宿のアクアフォレストから楊貴妃2ペアをおむかえ。

この子たちは実に丈夫で、トリートメント水槽に来た初日こそ落ち着かなさそうにしていたものの、2日目以降はえさはよく食べるしフンの状態も良く、病気もしたことがない。

問題なさそうだったので2週間ほどでメイン水槽に合流。

うち1匹は間もなくお母さんにもなった。

父親は幹之ではないかと見ているがまだ子供に特徴が出ていないので定かでない。

ただ彼らは仲はあまり良くないようで、しょっちゅう喧嘩をする。

約15Lに5匹で暮らしているので、そこまで過密というほど過密でもないはずなのだが、閉鎖空間ゆえ縄張りが気になるのかもしれない。

繁殖行動が見られた時期には鰭が傷つくくらいに激しい喧嘩をしていて悩んだが、最近は落ち着いてきた。

この5匹が集結してようやく、水槽が立ち上がったと言ってもいいかもしれないところまで水が落ち着いてきた。

飼育を始めてから実に2ヶ月後のことである。

おとなたちはだいぶ落ち着いてきてくれたので、最近は初の稚魚飼育で毎日あたふたしている。

なんとかこの子たちも無事におとなまで育て上げ、親たちと一緒に暮らせるようにしたい。