Author: Mutsumi

こんなものを作りました。 Yuheiさんの記事に大きな影響を受けて作りました。 私は情報収集は主にXでやっていますが、気になる記事をお気に入りするものの、見返すことはほぼありません。「これは重要だ、後でみよう」と思ってお気に入りをつけることが結構あるのですが、時間があっても見返さず、ついつい新しいツイートを追ってしまいます。消化すべきコンテンツは溜まっていくのに目の前の新しい情報ばかり追っていて、まるで負けが込んでいるのにスロットを回し続けるギャンブル狂いと変わらんなとか思ったりします。Xのお気に入り欄は人間の恥部。 そんなところにClineを活用してはてブを勝手にポッドキャストにしてくれるアプリを作ったというYuheiNakasakaさんの記事を見て、これはもしかして、自分の夢を叶えられるかも！と思って真似をした記事がこちらになります。 技術的にはこんな感じです。 リポジトリはこちら https://github.com/Mutsumix/twitter-audio 設計はこんな感じ https://github.com/Mutsumix/twitter-audio/blob/main/DESIGN.md （.clinerules が効いているかの確認のためにケロロ軍曹の話し方を強制しているのがドキュメントにも反映されてしまっています） コードは1行も書きませんでした。Clineから上がってきた提案を「いいね」「APIはこれ使ってね」「それはアカン警察」とか最初に伝えて、あとはひたすら進捗を眺めていました。TypeScriptとか全然書けないのですが、数千行のコードが完成して興奮します。 工夫としては、XのAPIは有料で高いので、IFTTTを使用しています。Xでお気に入りをすると、スプレッドシートに内容やリンク、日時といった情報が飛びます。本当はブックマークをしたものだけデータを飛ばせたら、勉強したい技術系コンテンツだけに絞れて良いのですが、できないのか、やり方見つけられませんでした。で、IFTTTについてもXとの連携は有料（3ドル）ですが、XのAPI（200ドル/月！）を使うよりは安いので我慢します。 また、音声合成にはElevenLabsを使っています。過去に英語のスピーチ練習で使った時に非常に滑らかなアクセントに感動したので、APIでも活用することにしました。 あとは、やっぱり最終的に聞けるコンテンツにするための調整に一番時間がかかりました。 いくつかの塊に分けた要約をつなげていきなり音声合成するのではなく、もう一度全体の構成を見直させることにしたのもちょっとした工夫です。 ただ、聞いたところ記事の重複や漢字の読み間違いや聞いていて面白くないなど、粗さが目立ちます。 今の所自分が聞くだけのコンテンツなので振り返りのために活用できれば良いのですが、今後外部向けに音声コンテンツ作成をする場合もあるかもしれないので、この辺りのノウハウは積み重ねていこうと思いました。 メモ 今後やりたいこと

ばんくしさんがホストを務めている聴くエンジニアtypeというポッドキャスト番組にテスト駆動開発で有名な和田卓人（t-wada）さんが出ていた時の回で、面白い発言が多かったのでハッとしたところをメモ。 https://voicy.jp/channel/785857/6602165 #1 ばんくしさんがホストをやってる「聴くエンジニアtype」というポッドキャストでt-wadaさんゲストだったので聞いている。 エンジニアとしての腕を維持するためにいまだに受託開発やっているのが驚きだったけど、エージェント型のAIによるプラグラミングの隆盛に、かなり危機感とか焦燥感を感じていると話していた。自分で考える時間とか手を動かすのに時間を確保している、という大ベテランの姿を見習わざるをえない。

ばんくしさんがホストを務めている聴くエンジニアtypeというポッドキャスト番組にRubyの開発者まつもとゆきひろさんが出ていた時の回で、面白い発言が多かったのでハッとしたところをメモ。 https://voicy.jp/channel/785857/6449154 #1 #2 #3 #4

技術書典18に向けて書くか、と思ったらRe:VIEWの使い方とか色々さっぱり忘れていたので、未来の自分に向けてのメモ リポジトリについて 前回作成時はTechBooster の Re:VIEW 用の書籍テンプレート をクローンして作っていた。今回はそれを元に作成した自分用リポジトリをクローンする方法をとった。（書籍サイズなどの設定を使い回すため） git clone https://github.com/Mutsumix/hydroponics_tbf17.gitcd original-reporm -rf .gitgit init 初コミット前の掃除 作成にあたり以下をいじった tbf17となっているところをtbf18に一括で置換 config.yamlの設定（書名、発行年月日などを修正） ./articles/catalog.yml（目次を設定しているところ）をはじめにとあとがきの章だけ残してあとは削除 ./articles/images 配下の画像も削除（前回は最後に軽くするために一括で変換していた記憶がある）。ただし、表紙と裏表紙は消すと出力できなくなるので残す。 README.mdも技術書典18の内容に合わせて修正 ビルドについて dockerにRe:VIEWのイメージが残っていたので、それはそのまま使うことにした。最新は5.9だけどとりあえず5.8でいくことにした。 PDF出力のコマンドがわからなかったがこれで出力できた docker run –rm -v $(pwd)/articles:/work vvakame/review:5.8 /bin/sh -c “cd /work && rake pdf” 紙版・電子版 紙版の場合は本文と表紙・裏表紙画像は別で入稿するので、本文だけのPDFを生成する 電子版の場合は表紙・裏表紙込みで販売サイトにアップする必要がある。 設定をするのは./articles/config.ymlの プッシュ ここまでやって、問題なくPDFが出力されるのを確認して、GitHubにプッシュ。 git add .git commit -m “Initial commit”git remote add origin https://github.com/Mutsumix/hydroponics_tbf18.gitgit…

有料のTODOアプリを使っている。毎日の投薬、家族カードの引き落とし口座への振り込み、帰りにスーパーで牛乳を買う。そんな些細なタスクを管理するのに便利だからだ。 生活していると頭に常に「何かやり残しがないだろうか？」という考えが巡ってしまう性格なので、TODOリストがあると安心する。RPGだと、NPC全員に声をかけないと気が済まないタイプだ。そういう意味でも、このアプリは非常に役立っている。 TODOリストに残る未完のタスク TODOリストには、思いついたものをどんどん追加していく。最新のものはリストの一番下に追加される。簡単に終わるタスクを片付けていくと、必然的に難しいタスクはリストの上部に残る。 今、そのリストの一番上にあるタスクというのが、「人生の目標を探る」というものだ。 このタスクを追加したのは、2024年2月28日、朝8時43分。平日の出勤中。なぜこの時間にこんな重いタスクを思いついたのかは、もはや思い出せない。ただ、おそらく「人生の目標を決め、それを細かいタスクに落とし込めば、人生を充実させられる」といった趣旨の本を当時読んでいて影響を受けたのだと思う。 とはいえ、1年近く未消化のまま放置されていて完了できる見込みは全くない。「牛乳を買う」と並べるには重すぎるタスクだと思う。帰宅途中に寄ったスーパーで人生の目標が売っていたらいいのに。 しかし、TODOリストの最上部に居座らせておくのも気持ちが悪い。いい加減、決着をつけようと思った。 そもそも、目標は必要なのか？ 結論めいたことを最初に言うと、人生の目標ははっきりと決める必要はないと思う。 目標とは、個人の価値観を実現するための手段だと言いかえられる。人は状況によって価値（役割）を持ち、それを果たせば次の価値（役割）が生まれる。たとえば道を歩いていて倒れている人を見つけたら介抱したとする。倒れている人に適切な医療的処置を施すなり、医療機関に送り届けるという作業が終われば、もうその役割は消えてなくなる。地域の祭りを運営する人も、祭りが終われば普通の住人に戻る。仕事も、家庭も、学校も、地域での活動も、本質的にはそれと変わらない。 「目標を持つこと」が大事だという価値観に乗っかって、「自分らしく生きよう」と考える人は多い。SNSを開くと頼んでもいないのにそんなメッセージが次から次へと流れてくる。自分のインスタはそんなのばっかりだけれど、そのほとんどがミニマリストやFIREのような、誰かが作ったマニュアルをなぞる生き方になっているのを見ると、人の想像力や評価軸なんて、その程度のものなのかもしれないと思う。 宮崎駿が、エヴァの制作で心身ともに疲弊していた庵野秀明に「自我なんて、いくら探求したところで空洞なんだから」と言ったというのをどこかで読んだ記憶がある。この言葉には共感する。 「自分探し」の旅に出る人もいるけれど、そもそも探すべき「自分」というものは存在するのだろうか。むしろ、その時々でその人の価値（役割）が変わっていくのが自然ではないか。 過酷な世界と「役割」の話 出版社で働いていた時、「一生懸命頑張っていれば、結果は後からついてくる」とピュアに信じ、激務をこなしていた。しかし、その結果、心身を壊して鬱のような状態になり結果的に退職した。 そのとき、ジブリ映画を見るのが辛かった。なぜなら、ジブリ映画の中では労働が賞賛されている。サツキもシータもキキも千尋も、義務教育期間中にもかかわらず、とにかくビシバシ働く。 「目標を見つけ、それに向かって邁進する」ことが美しいとされる世界では、そうなれなかった人生は暗に否定される。「情熱大陸」や「プロフェッショナル」も同じような理由で見るのが辛かった。だから必死に目標を探そうとしていた。 この世界は過酷だ。一度失敗したら、次のチャンスはないかもしれない。社会のセーフティネットは細る一方で、そんな中で正気を保ち続け一つの目標に向けて頑張り続けるのは無理がある。 でも、もし「正気を保つこと」が難しいのなら、せめて「今、自分にできる役割を果たすこと」に目を向けてもいいのではないか。 では、人生の目標とは ここまで考えたうえで、無理やり「人生の目標」を言葉にするなら、こうなる。 「その時々の役割を全うすること」 何か大きなことを成し遂げるのではなく、ただ、目の前の役割を、その時できるかぎり果たしていくこと。 それが、TODOリストの最上部に鎮座していたタスクへの今の所の答えだ。 今日は休み。息子と出かけたついでに彼の好きなグミを買って帰ろう。近くの花屋にも寄って、妻に花を買おう。 その道すがらチェックボックスをタップしてこのタスクを完了させた。

子どもの頃、大人たちは「今どきの子はゲームの影響で、人生を簡単にリセットできると思っている」と言っていた。でも、むしろ逆ではないかと思う。ゲームをしていた方が、人生の取り返しのつかなさに敏感になる。 そう思うようになったきっかけは、パワプロシリーズのダイジョーブ博士の手術イベント。あれは一発勝負で、失敗すれば選手生命はほぼ終わる。初期のタイトルを除けばリセット技が使えなかったから、慎重に考えざるを得ない。しかし考えたところで結局は運の要素が大きい。 人生も同じで、選択肢は無限にあるように見えて、実際には就職や結婚、転居、一つひとつが再現性のない取り返しのつかない選択になっている。 余談だけれど、ダイジョーブ博士の名前の由来は、トミー・ジョン手術を考案したフランク・ジョーブ博士らしい。名付けた人の秀逸なセンスを賞賛したい

子どもが登園する時に持たせる持ち物の中に昼食時に使うウェットティッシュがある。自分が子どもの頃はおしぼりを持たせられていた記憶があるが、今どきはウェットティッシュを持たせるルールのようなので、他の持ち物と一緒にそれをカバンに入れる。ウェティは個包装のものを用意しないといけない。近くの百円ショップで探すと10枚入りで売っている。つまり一つ十円ということになる。 十円という金額は別に高くはないと思われるだろうが、私のなんか気になるラインに引っかかってしまった。たかだか10円なのでそんなこと気にするよりサブスクを節約した方が遥かに家計への効果は大きいのだが、気になったもんはしょうがない 私はウェ活（ウェットティッシュ活動）を始めることにした。コンビニで買い物をした時に必要でもないのに「ウェットティッシュください」と言って集めるようになった。また、昼食や立ち寄ったカフェで提供されたウェットティッシュを使わず持ち帰る、ということをするようになった。 しかしそれでは毎日の必要を賄えるほどにはならず、渋々百円ショップの単価10円のウェットティッシュを買うことが続いた。そんなこんなでダイソーのウェットティッシュを持たせた日には、子どもが10円玉で口を拭いてゴミ箱に捨てている直接的なイメージが私を襲い嗚咽を漏らしてしまうようになった。 妻に相談したところ、同じ問題意識を持っており、ウェ活に参加してくれた。さらには妻の両親にそのことを話してくれた。すると義母が我が家を訪問した際にウェットティッシュを施してくれるようになった。この人と結婚してよかった、と思った。 そうした努力が功を奏し、今は供給が需要を上回り、ウェットティッシュリッチ状態である。ウェティ・スーパーリッチ。 このことから私は一つのことを学んだ。 自分が叶えたいと思うことは心に留めておかず、周囲に宣言する。そうすることで周囲が協力してくれる状況が生まれ、願望が実現する、もしくは実現が早まることがある この法則をウェットティッシュの法則（Law of Wet Tissue）と呼ぶこととする。

昔金がなかった時（今もないけど）、Uber eatsの配達員をしていた。 アプリで申請をし、配達用のカバンを所定の場所に受け取りに行った。5,000円必要だったがカバンを返すときには返してもらえると説明を受けた。外国人が同じ列に並んでいたが日本語能力が足りないことを理由に窓口で断られていた記憶がある。 Uber配達員用のアプリを立ち上げしばらくすると、通知が届く。 「近くでオーダーがあります。取りに行きますか？」 オーダーを受けるかどうかは早い者勝ち。通知に応答すると、店舗までのコースが示され、配達する食品を受け取ると、次は配達先へのルートが示される。アプリの指示に従い配達が完了すると、今回配達した距離と金額が画面に表示される。 これの繰り返し。 最初の配達が完了した時、なんて画期的で快適な働き方なんだと驚いた。 これまでアルバイトは単発・長期含めていくつも経験してきたが、面倒臭い人付き合いなしに仕事が完結することにとにかく衝撃を受けた。 仕事終わりや土日に時間を見つけてはUberの配達員をした。平日なら3,000〜4,000円。土日は1万円近くは稼いでいたと思う。 そのうち、どこにいけばオーダーを受け取りやすいか、いかに高単価の注文をゲットできるかの勘が働き、ウィンドサーフィンのように風が読めるようになってくる（当然ウィンドサーフィンはやったことない） その他、毎週のように配達をしていると色んなことがわかってくる。 天気が悪い日は配達員が減り、オーダーが増えるので配達単価が上がって稼ぎが良くなる。 メニューは豊富にあるのにオーダーのほとんどはマック。 働きたくない時は働かないで良いのはいいのだが、そうなると当然収入はゼロ。これまでのバイトはめんどくせーなーと思いながら適当に働いても時給は発生していた。 配達先の半分くらいはタワマン。今まで足を踏み入れたことがないような高級なマンションに何度も入った。 そのうちこんなことを考えるようになった。 「一生懸命高校の時勉強して東京に来てサークルで部長やって海外にも行ってボランティアもやってその結果が金持ちにマックを届ける仕事ってなんなんだろう」 ある日、マックを届けにタワマンに行ったら自分より年下のガキが出てきて嫌になってやめた。

個人用のメモです App.tsxのインポート文にこれを仕込む import * as Updates from ‘expo-updates’; パッケージをインストール npx expo install expo-updates アプリをビルドして、ストアにリリース eas build –platform ios –profile production その後、EAS Updateをプロジェクトに追加： eas update:configure アップデートをプッシュ： eas update –branch production –message “アップデートのコメント”

こちらの記事でiOSアプリのリリースのざっくりとした流れを確認したので、今回は2025年1月時点でのAndroidアプリのリリース手順を見ていきたいと思います。 結論から言うと、iOSのリリース時に作成したアイコンやストアに公開する用のキャプチャなどを使いまわせた関係で、1時間で申請まで終わりました。 事前準備 事前にこれらの設定を済ましてある前提。 設定ファイルの準備 iOSの時と同様。app.jsonを編集する Expoの設定 iOSの時と同様。eas.jsonがなければ作成し、編集する アイコンの作成 iOSの時と同様。使いまわすときはサイズが違うので注意。1 MB 以下、512 x 512という要件がある（iOSは1024 x 1024） キーストアの生成 iOSでもやったアプリの署名に必要な基本的な認証情報の設定をAndroidではキーストアと言ったりします。例によってめんどくさいんですが、Expoを使うと簡単です。以下のコマンドを打って、選択肢から適当なものを選んでいくだけで完了します eas credentials 本番リリースであればproductionを選択し、最初のビルドなのでKeystoreを選択して新規作成するような選択肢をターミナル上で選んでいきます。 アプリのビルド eas build –platform android このコマンドでExpoのサイト上でビルドをしてアプリのファイルを生成してくれます。初回だったからか10分弱かかりました。 iOSではここからさらにストアへの提出がコマンド一発でできました。Androidの場合は事前の設定が煩雑そうなので、ビルド後のファイルをExpoの管理画面からダウンロードし、それを手動でアップロードすることにしています。 Google Play Consoleで新規アプリ作成 iOS同様、一番時間が取られるところです。Androidの方が、提供する情報が多い気がします。広告のありなしや、ニュース関係のアプリなのかどうか、個人情報を収集するか否かなどの質問に答える必要があります。今回サンプルで作成したアプリは、特に問題のあるような中身はないので、サクサク進められました。 プライバシーポリシーのリンクを設定しなきゃいけない箇所があったので、そこは個人開発の場合は用意するのが面倒だなと思いました。 ターゲットユーザーは13歳以上としておくのが面倒がなくて良いかも。 あと手こずりそうなのが、Androidの場合、アイコンやアプリの操作画面のキャプチャとは別で「フィーチャー グラフィック」というものを提出しなければなりません。 PlayStore内での広告・宣伝に使うような横長の画像で「15 MB 以下、1,024 x 500 ピクセル」という要件が決められています。しょうがないので適当に作ります。 さらに、「7 インチ タブレット版のスクリーンショット」、「10 インチ タブレット版のスクリーンショット」もアップロード必須のようです。しかし、スマホ用にアップロードしたサイズの画像をそのまま使いまわせるので、特に準備は不要です。 アプリの提出 質問への回答と画像の提出があらかた終わると、アプリのアップロードができます。iOSの場合、eas submitコマンドでビルドを直接送信できましたが、Androidの場合、サービスアカウントのJSONキーファイルの設定などが必要でかえって面倒なので、Expoのサイトからダウンロードした.aab形式のファイルをアップロードします。 最後に審査に提出して完了です。 審査 これを書いている現在も審査中のステータスなので、審査が完了したら、追記をしたいと思います。 結論 ReactNativeとExpoを活用したケースですが、複雑なアプリでなければ、1時間程度でアプリの申請ができることがわかりました。…