マジで今更だと思われるかもしれないが、アニメ『少女☆歌劇 レヴュースタァライト』を鑑賞した。

率直にめちゃくちゃ面白かったので熱量があるうちに軽く整理してみる。

『少女☆歌劇 レヴュースタァライト』との出会い

2018年放映のアニメ作品を2025年になって今更どのように出会ったかでいうと、今年に入ってから友人と「アニメの第一話だけを見て作品のテーマを解剖し結末を予想する」という遊びを定期的に行っていて今作もその中で選ばれた作品だった。

しばらくアニメから離れていた自分としては完全に初見で、どんな作品か全然知らなかった。

1話目を半分くらいまで見て

「あー、ミュージカル風『ラブライブ！』みたいな作品かな」

と感じていた。歌劇に青春を燃やす少女たちの群像劇的な。

しかしその印象は、1話目18分あたりで大きく覆った。

1話目を見た印象と当時のテーマ解剖・結末予想

学園に普段は存在しないエレベーターを見つけ、不思議な地下劇場へと誘われる。

ここまでそういった非日常感を感じない作りだったため、このシーンはかなり面食らった。（あとから調べると当時もそういう反応は多かったようで「意味不明」とか「何これ」みたいな感想は溢れていた模様）

そこからあまりにも印象的な『アタシ 再生産』のカットが挟まり、主人公・愛城華恋を中心とした “レヴュー” と呼ばれる舞台少女たちの戦いが始まっていくという話。

一話目を見終えた時に並べていたテーマの解剖と結末予想は以下（全話見た今見返してみても大きく外してはないような気がしていてちょっと嬉しい）

テーマ解剖

• Revue（歌劇）を見つめ直し（Review）、再生産する物語

レヴュー

• 歌・ダンス・寸劇が組み合わさったショー
• 「情熱のレヴュー」では華恋 vs ひかり（華恋優勢、ひかりは情熱を失いかけているということ？）
  • 海外で打ちのめされた？
• 審判がキリン（高い視座の存在、としてのメタファー？）
  • 華恋はキリンを超えて舞台に飛び入っている（キリンの想定を超える何かを起こしてくれそう）
  • 「わかります…」が「わからない…！」になるのが楽しみだ

東京タワー

• 華恋とひかりの夢の始まりの場所
• 高度経済成長の中で建設された東京タワーは建築期間約1年半という、着工から完成までが異例のスピード工事だったらしい。
  • => 「急成長」のメタファーとして華恋ちゃんのポテンシャルを表現している？

結末予想

• 華恋とひかりのW主演で、悲劇→喜劇（ハッピーエンド）に「再生産」
• 心が見えず、情熱を失いかけていた光と、2人でスタァを目指したい華恋とのコンビが次々にレヴューで勝ち進んでいく。「ぶつかり、いさかい、すれ違いながらも結ばれていく絆」
  • キャラ毎の心情が見えてきたら、各女神枠の予想もできるかな？（まひるちゃんは嫉妬の女神だと思う）
• 99回目でW主演だった西條 クロディーヌ・天堂 真矢がラスボスとして登場。最後のレヴューが始まる
• 圧倒的な実力を前に力及ばずか…という窮地で「いこう、あの舞台へ。輝くスタァに二人で。」
  • ひかりの”再生産”が発火。（東京タワーと対照にエッフェル塔とかビッグベンとかから落ちる演出だと面白い）
  • 一つの頂上ではない、2人が輝くスタァを見出す
  • 『スタァライト』を別れで終わる悲劇→再会で終わる喜劇に再生産し、”最もきらめいたレヴューを見せた” 2人がレヴューを勝ち残る
• これまでの伝統的なスタァライトを再生産し、新しい時代を作り出した第100回 聖翔祭を演じきって最終回（聖翔祭は3月に行われるので、卒業を控えた3年生は演じず、2年生で最後なのでは）
• ばななちゃんが撮影した第100回 聖翔祭の写真を見返しながら「懐かしいね」などと会話しつつ、それぞれの進路が仄めかされる
• 再生産で熱意を取り戻したひかりは再びイギリスへ。いつかくる再会の日に期待しつつそれぞれのスタァへの道を歩み始めて終幕

テーマに沿って再まとめ

• 既存のRevue（スタァライト）を見つめ直して再生産した各キャラクターが今度は己の歌劇（拡大解釈すると人生。舞台少女は歌劇に生きているので）を見つめ直して、各々を再生産していく。

どういう作品だったか・感想

めっっちゃくちゃ面白かった（小並感）。

映像や曲のクオリティももちろんながら、巧みな暗喩が非常に豊富。

トマト、ミロのヴィーナス、紙飛行機、東京タワー、タクシー代…

挙げ出したらキリがないがモチーフやセリフ、演出など随所に暗喩がねじ込まれていて「これってこういう意味なのかな…？」と推察できる作りになっている。

12話で9人のキャラを掘り下げながら充実した展開を作るのは非常に大変だと思うが、この巧みな隠喩や、2人ずつのペアで物語を進めたりなどの工夫で、凄まじく濃密な12話になっている。

再生産総集編と劇場版も見たが、全体通してのテーマとして核は一言でいうと『Revue（Review）＆ Rebuild』とかになるのかなと解釈した。

考察記事も別途作ろうか（とはいえもう巷に出尽くしている感じもあるのでそれこそ今更か…）とも思っているので、ここでは多くは語らないが、「私たちはもう 舞台の上」にいて、最高の舞台(人生)にするために「日々進化」していく必要がある。

進化にも色々あると思うが、人生を大きく変える進化は『既存のものを見つめ直して再生産する』覚悟が必要で、それは舞台少女だけでなく普遍的な教えとしてし見る者に届くのではないだろうか。

面白くなりたい。

大喜利で面白い回答を出したり、ボケに対して面白いツッコミを切り返したりしたい。

そういった所謂「お笑い」的な面白さもそうだし、映画などのコンテンツを受け取って面白い考察をしたい。

これらは個々で見れば別のベクトルの面白さだなと頭では理解しながらも、自分の中では「面白くなりたい」という方向感でどれも鍛え上げたい能力だ。

「面倒だからまとめて一気に鍛え上げることは出来ないかなー」、と怠惰の極みみたいな思考を巡らせていたら、何となく共通項が見えてきた気がしたのでそれらを備忘録的にまとめたい。

大喜利・ツッコミ・考察に共通する能力

詰まるところ「情報から連想されるキーワードを抽出して再構築する能力」なのではと考える。

大喜利の場合は「お題」、ツッコミの場合は「ボケ」、考察の場合は「コンテンツ」を受け取って、まずはそこから連想されるキーワードを抽出する。

例えば大喜利のお題が「こんな本屋は嫌だ」だとした時に、このお題から連想されるキーワードを洗い出す。

後述もするが、ここはとにかく量を出すのが良い。連想キーワードをブレインストーミングする。

連想キーワードが洗い出せたらそこから「再構築」に入る。今回の例は大喜利なので上記のキーワードから「こんな本屋は嫌だ」へのアンサーを考えてみる。

いや、一旦おもしろ度合いについては目を瞑ってほしい。あくまで例ってことで。

もちろん大喜利の上手な人は逐一こんなことをせずとも、脳内でパパッと構築できるのかもしれないが、基本的にはこういう思考プロセスを踏んでいるはずである。

これが「抽出」と「再構築」であり、これをスムーズに行いつつ、大喜利なのかツッコミなのか考察なのかに合わせて適用させていけば各所で高い面白さを発揮できるのではと思う。

抽出は「具材集め」で 再構築は「料理」

「情報から連想されるキーワードを抽出して再構築する能力」は「具材集め」と「料理」に例えるとイメージしやすい。

特定の情報に対して、脳内で関連タグを収集する作業が「具材集め」で、集まった材料を再構築するのが「料理」。

例えばツッコミならスピード感が要求されるので、「具材集め」も「料理」も凝り過ぎずにスパッと出したものがウケやすい。

大喜利はツッコミに比べもう少し時間が取れるので、「具材集め」も「料理」も少々時間をかけて、ストレートなものより凝ったものや、想像の一歩先をいった料理なんかを提供するとウケやすい。

考察ではガッツリと時間を取れるので、「具材集め」で最高の材料を並べてガッツリと「料理」することで、新しい見方や見解を出せるとウケやすい。

この能力はどうやって鍛えればいいか

抽出は「具材集め」、再構築は「料理」、とした時に、何はなくとも具材がないと料理ができない。

そのため基本は 情報から連想されるキーワードを抽出する能力の向上が優先され、再構築はカテゴリに沿ったものをある程度専門的に実践する方が効率的だと考える。

スマートな練習方法を提示したいところだが、今の所自分は愚直に『物や事象に対して連想されるキーワードを出しまくる』というマッチョな方法に着地している。

2017年ごろ、上記画像がミームとして大流行したが、これは非常に的を得ている感覚。

「頭が良い」= 「面白い」ではないのはもちろんなのだが、面白い要素を見つけやすいのはやはり連想が早く多い方ではあるよなと。

そのため大喜利にしろツッコミにしろ考察にしろ、まずは「大量の連想キーワードを素早く洗い出す」というのが面白のコアスキルになってくるのではと思う。

「抽出」と「再構築」の二軸で考えれば、自分がどこが弱いか特定しやすい（自分の場合は「抽出」が足りてないように感じている。有り体にいうと頭が悪い。）

まとめ

仮説「大喜利・ツッコミ・考察などのスキルってある程度共通の能力で伸ばせるのではないか？」
↓
その共通の能力とは「情報から連想されるキーワードを抽出して再構築する能力」なのでは？
↓
抽出を「具材集め」、再構築を「料理」で考えるとイメージしやすく、この二軸で分けると足りない能力を鍛えやすい

うまくハマれば総合的なおもしろスキルを効率よく伸ばすことができるのではとワクワクしている。

Dockerを使って開発しているのですが、ある日突然以下のようなポップアップが表示されました。

Docker.appを開くとコンピューターが破損します。ゴミ箱に入れる必要があります。

これまでキビキビ動いてくれていたのに、いきなりのマルウェア扱い。どうしちゃったんだ…

今回は上記問題の解決方法を備忘録としてまとめていきます。

結論

Dockerをゴミ箱に入れて 公式が公開している回避策コマンドを実行後、Dockerを再インストールする！

以下でもう少し詳細に記載します。

具体的な対応

Docker.appを開くとコンピューターが破損します。ゴミ箱に入れる必要があります。

は何度キャンセルしても繰り返しポップアップが出てくるので一旦 [ゴミ箱に入れる] をクリック。

その後、一旦ゴミ箱の中身を空にします。

「一度Dockerを消して再インストールすることで解決した！」という記事も見かけましたが、私の場合はうまくいかず、検証のタイミングで

“Docker.app”は壊れているため開けません。ゴミ箱に入れる必要があります。

と表示されてしまいました。

調査しているとDocker公式から『Docker Desktop on macOS unable to start due to malware reports 』（マルウェア報告により macOS上のDocke Desktopが起動できない）という障害報告ページを発見。

2025年1月8日 時点のレポートではDocker公式も原因を調査中で、どうやら com.docker.vmnetd または com.docker.sockert のいずれかがマルウェア判定されてしまう ということらしいです。

workaround（回避策）として対応方法を記載してくれているので、上から順に対応します

1. Docker Desktopを終了し、アクティビティモニターを使用して残りのdockerプロセスが実行されていないことを確認。
2. コマンドを実行（ 2の箇所にあるコマンドを上から順に実行 ）
3. Docker Desktopを再起動

上記実行後、無事にDockerが再起動し、正常動作するようになりました。

最後に

障害報告ページを見ると ver4.37 でパッチが当てられたらしく、それ以降のDocker for Macを再インストールすれば治るっぽいんですが、私の環境では再インストールで正常動作しなかったですね…

割と同じ事象で困っている方がSNSなどでも散見されたので、助力になれば幸いです。

改めてブログ書くのって結構良いなと思った。ちょっとその辺りの考えをまとめてみる。

ブログに書き出すことのメリット

詰まるところ、書き出すことのメリットが充実している気がしている。大きいメリットは以下だと思う。

• わかってないところの見える化
• 知識・知見のデータベース化
• 思考ツリーの手綱

わかってないところの見える化

例えばプログラミングについて記事を書こうという時、大抵の場合は「こういう事象に遭遇したから、解決までのプロセスをまとめておこう」とか思って書き始める。

頭の中では 問題提起 → 解決 までのゴールが見えている気がして颯爽と書き出してみるのだが、いざ文章にしようとすると

• 「何でそう思ったんだっけ？」
• 「そもそもこれって何だっけ？」
• 「この言葉って使い方合ってるっけ？」

とか絶対なる（断定）。

頭の中だけで完結してる時は、脳内補完が上手に働いてさも1から100までわかった気でいるのだが、アウトプットしてみると案外5割くらいしか分かってなかったみたいなことがザラにある。

また、他人に説明しようとすることで学習が捗るみたいなデータもあるらしく、これは体感としても納得できる。

わかってないところが見え、わかっている部分をより咀嚼して吸収率を上げる、という行いは結構大きいメリットだと感じる。

知識・知見のデータベース化

私はシンプルにかなり忘れっぽい。

プログラミングでも一度やったことのある手続きとかお作法なんかをどんどん忘れていく。

これはちょっと時間的にも勿体無いので、書いて覚えを良くしていきたい。また、同時に備忘録としてもブログは大いに活躍するはずだ。

楽だからテキストばっかりで書いちゃうけど、写真とか動画とかもどんどん乗せて充実したデータベースにしていくのが良いんだろうな。

思考ツリーの手綱

あんまり利口ではないので、考えているうちに思考があっちこっち行ったり、霧散したりして、まとめるのに時間がかかることがある。

プログラミングでもとりあえず手をつけてみるが

• 「そもそもこの方針で良いんだっけ」
• 「ここ2パターン思いついてたけど、Bパターンって何する予定だったんだっけ」
• 「お腹すいたな。一旦ご飯食べようかな」
• 「ここまで進めてきたけど、そもそも最初からこっちの手法の方が良いっけ」
• 「煮詰まってきたから昼寝しようかな。後にしようかな」

こんな感じになってしまう（よくない）。

ブログ書きながら物事を進めると、時間はかかってしまうが、すんなり思考の軌跡を辿れるのでこれが手綱となり元に戻ってこれることが多い。

思考の解像度向上

「ヤバい」とか「エモい」とか、世の中便利な表現が多いので、よく使ってしまう。

湧き上がった感情を文章化しようとすると「何でエモいと感じたんだっけ？」みたいな考えが巡って、結果意外かつ自分の中で納得感のある表現に落とし込めたりする。

「ああこの”エモさ”って、ここまでの経緯を一気に見せてもらって、自分の過去の経験とも類似するところが多くて共感しきった時に、あのカタルシスだったから響いたのかも」

みたいに理解できると、考えがクリアになって何だか気持ちが良い。自分のことが少し分かった気になれる。

ブログに書き出すことのデメリット

多分デメリットもある。

• 時間がかかる
• うまくまとまらないと萎える

とはいえどっちも、長期的に見れば解決する問題な気がしている。

時間かかる

正直これがネックな部分はある。この記事もなんとなくまとめてみようと軽い気持ちで始めたのに1時間近くタイピングしている。だるい。

• 別にライターとして食ってるブログじゃないのだから力抜く
• デカいことを網羅的にまとめようとしない
• 60%で良いから世に出しちゃう

この辺を意識しつつスピード感というか “フッ軽” 感もって取り組みたい。ブログ書くの面倒って思ったら多分負け。ハードルは低く。

うまくまとまらないと萎える

逆にうまくまとまると気持ちいい。脳がスッキリする感じがある。

多分最初のうちは文章をまとめるの自体が大変なことに感じるが、慣れの部分が大きいと思う。

「考えていることをサクッとまとめる練習」と割り切って、最初はダメでも書き続けてみたい。

ブログは健康に良い（持論）

デトックス作用ある

イライラした時に「なぜイライラするのか」を文章に書き出してみると、意外なほど冷静になれるというライフハックがある。これはブログをやる前からメモ帳とかでやってたので体感としても納得している。

なので「あいつムカつくぜー！全てが嫌いだー！」とか思った時も、具体的にどんなところが嫌いか洗い出そうとすると意外なほど出てこない。

出てきた場合にも「あ、これはこっちの受け取りの問題かもな…」とかちょっと冷静な自分も顔を覗かせたりする。文章化すると客観的になれてそういう点に気づきやすい。そうやっているうちにイライラが少し引いている。

頭の中でモヤモヤ・グルグルしている時間は割ともったいなくて、サクッとアウトプットして客観的に捉えた方が、脳の負荷も溜飲も下がるし良い感じ。

瞑想作用ある

「頭の中が整理されていく感じ」が気持ちよくてドンドン書いているうちに、なんかすごく集中している時がある。

歳取ってくると、何かに没頭している状態って意外と少なくなっていて、これはとても健康に良い気がしている。

ガチで瞑想（マインドフルネス）に取り組んでみていた時期もあったが、10分の瞑想よりも10分ブログで考えを整理した方が個人的にはメリットが多いと感じた。

まとめ

改めて自分にとってブログ書くことって利点が多いと感じたので、ここからの更新頻度はすごいよ。

掲題通り。解決までの道筋を備忘録として残そうと思う。

前提

• t3.medium で稼働しているEC2インスタンスのタイプを r7g.medium に変更してほしいという依頼を受けた
• Auto Scaring GroupなどはじめAWS構成をTerraformで管理しているので、.tfファイルの修正 -> apply を伴う
• アプリ自体は GithubActionでイメージをECRにプッシュし、該当イメージをECSでデプロイする流れ

x86ベース → ARM への移行という障壁

今回の肝はここ。

t3.medium → r7g.medium に変更するということは、アーキテクチャがx86ベース → ARMベースに変更されるというポイントがある。

x86

• パソコンやサーバーで主に使用
• 高性能だけど、電気をたくさん使う
• 複雑な計算が得意
• IntelやAMDが作っている

ARM

• スマートフォンやタブレットで生まれた CPU
• 軽くて省エネ・省電力
• バッテリーが長持ちする
• Amazonが作ったGraviton2/3ベース

簡単に言えば、x86は「パワフルだけど電気を食う」、ARMは「少ない電気で効率的に動く」タイプのCPU、と理解した。

アーキテクチャが変わることによる影響範囲を当時はあまり理解できていなかった。

切り替え自体は楽だが使用するイメージに注意

アーキテクチャが変わるとはいえ、instance_type = "r7g.medium" としてやればいいだけだと考えていた。

が、インスタンスタイプが切り替わったあと、元々動いていたサービス上でタスクが起動しなくなっていることに気づいた。

resource "aws_launch_template" "lt" { name_prefix = "${local.app_name}-lt-" image_id = "ami-0dba57a21a03d3f66" # Arm対応ECS-Optimized AMI instance_type = "r7g.medium" key_name = var.ssh_key_name

原因は image_id だった。

上記修正を行うまで、 単にARM64に対応している最新のimage_idを指定していたが、Arm用の ECS-Optimized AMI を指定してやらないと、DockerやECSエージェントがプリインストールされないため、サービス上でタスクがいつまでも起動しない（ECSとECRが紐づかない）状態となってしまった。（これ気づくの時間かかった…）

こちらを適用後、インスタンスとサービスを再起動することでタスクは動き出した。

Github Actionでエラー

GithubAction実行時に以下のエラー

8 0.190 exec /bin/sh: exec format error

これは Docker ビルド時にコンテナが ベースイメージのアーキテクチャ と 実行環境のアーキテクチャ が一致していなかったために発生するものらしい。

ベースイメージはDockerFile内で node:18-slim を指定していた。これはマルチアーキテクチャに対応してくれることを事前調査済みだったので安心していたが、問題は実行環境のアーキテクチャ。

Github Actionはデフォルトで x86ベース で動作するため、これが不一致の原因だった。

Github Actionでアーキテクチャが異なる環境でプログラムを動作可能にするには、QEMUとBuildxというツールを使うのが一般的だと知った。

 - name: Setup QEMU uses: docker/setup-qemu-action@v2 with: platforms: linux/arm64 - name: Setup Docker Buildx uses: docker/setup-buildx-action@v2

• QEMU: 異なるアーキテクチャをエミュレートのするためのツール
• Buildx: いろんな環境用に効率よくアプリを作るためのツール

らしい。

これらを導入することでbuildも通った。

build時間がめちゃくちゃ長くなった (5分程度 → 30分程度) のが微妙過ぎるが、これはまた別の課題とする。

こんにちは。

Ruby on RailsでWebアプリケーションサービスの開発をしています。

普段のコーディングはVisual Studio Code(VS code)を利用しているのですが、Ruby onRailsの開発をしていると、「この定義元ファイル確認したいなー」なんてことがよくあります。

ショートカット⌘ +⇧+  fなどで全検索してもよいですが、サッと定義元にジャンプできた方が楽ですし早いですよね。

今回は定義元にジャンプする設定をご紹介します。Rails開発している方はぜひ参考にしてみてください。

Railsを書いている時にメソッドの定義に移動する設定

VSCodeの拡張機能「Ruby」導入

まずはVisual Studio Codeの拡張機能『Ruby』を導入します。

Visual Studio CodeでRubyを扱う場合には、ほぼ必須と言ってよいくらい優れた拡張機能です。

まだ導入されていない方はMarketplaceで「Ruby」と検索し導入しましょう。

定義に移動する設定をONに変更

タスクバーからVScodeの[基本設定]=>[設定]をクリック。画面上部[設定の検索]に「Ruby」と入力します。

Ruby:Intellsense の設定を[false]から[rubyLocate]に変更して設定完了です。

定義にジャンプする方法

使い方は簡単。

定義されたメソッドにカーソルを持っていき、⌘ボタンを押した状態でクリックすることで、定義元に一瞬でアクセスできます。

これ有る無しで開発効率が段違いなのでオススメです。

VSCodeでRubyのメソッド定義に移動する方法 まとめ

ということで今回はVScodeで開発する際の、定義元ジャンプの設定についてでした。

VScodeの拡張機能はたくさんあって、各言語似たような設定があることかと思います。

メソッドにすぐ飛べると確認効率も上がり、開発スピードが高速化すること間違いありません。

まだ設定していない方は、一度設定するともう無かった頃には戻れないほど快適なコーディングになるはずです。

ぜひ自身の環境で試してみてください

短いですが、今回はここまで。

こんにちは。

Ruby on RailsでWebアプリケーションサービスの開発をしています。

開発中にvalidatesエラーでrenderするも、renderした画面でエラーメッセージが表示されないという問題に陥りました。

今回その原因と解決方法についてご紹介します。

validatesエラー時にrenderしてもエラーメッセージが表示されない！

作りはまあシンプルで、user_controllerのcreateアクションに成功した時と失敗した時の処理を書いていました。

 def create @user = User.new(user_params) respond_to do |format| if @user.save format.html { redirect_to top_path } else format.html { render 'setting' } end end end

ユーザーmodelでは、名前の未入力バリデーションを記述していました。

class User < ApplicationRecord validates :first_name, presence: true validates :last_name, presence: true
end

ユーザーが名前を未入力でsubmitした場合、バリデーションが走りエラーを返します。

byebugで止めながら処理を見ていきましたが、createアクションでは正常にelseに入っています。

render先のviewでは以下のような処理を書いていました。

  <% if @user.errors.any? %> <p>エラーです！！！！！！！</p> <% end %>

ターミナルから確認しエラーであることも確認しました。

(byebug) @user.errors.any?
true
(byebug) @user.errors.full_messages
["Password can't be blank"]

ビューまでエラーが伝わっており、条件に合致しているにも関わらずエラーメッセージが表示されません。

なんでじゃ！！

validatesエラー時にrenderしてもエラーメッセージが表示されない！ 解決方法

local: true をつける！

ユーザーのnameをsubmitする画面をform_withで作成していました。

<%= form_with model: @user do |f| %> <%= f.text_field :last_name, placeholder: "苗字" %> <%= f.text_field :first_name, placeholder: "名前" %>
<% end %>

form_withはデフォルトでremote: trueになっています。これがエラーメッセージ表示を阻害する原因でした。

Ajaxで処理をしたいわけではないので、明示的にlocal: trueを記述します。

<%= form_with model: @user, local: true do |f| %> <%= f.text_field :last_name, placeholder: "苗字" %> <%= f.text_field :first_name, placeholder: "名前" %>
<% end %>

form_withで作成した入力フォームにlocal: trueを記述した状態で、改めてsubmitします。

先ほど通りvalidateで弾かれて、エラーを抱えた状態で正常に条件分岐して、ビューまでたどり着き……

じゃん！

無事にrender先でバリデーションエラー時のメッセージを表示することができました！よかった〜〜！

validatesエラー時にrenderしてもエラーメッセージが表示されない！ まとめ

ということで今回はRuby on Railsで、バリデーションエラー時にrenderした先でエラーメッセージが表示されない問題の解消方法についてご紹介しました。

form_withにまだ慣れていなくて結構苦戦してしまいました。

Railsのバージョンアップとともに便利になっていくメソッドたちですが、それが果たしてどういった処理をしているのかちゃんと紐解いてやらねばなりませんね。

同じようにバリデーションは効いているのにrender時にエラーメッセージが表示されなくてお困りの方の、参考になれば幸いです。

今回はここまで。

参考サイト

• https://qiita.com/k_senbei/items/a361171f653edcd888ad

こんにちは。

Ruby on Railsを使ってWebアプリケーションを開発しています。

開発中、railsサーバーを立ち上げようとしたらmapping values are not allowed in this context という内容のエラーに遭遇しました。

今回はmapping values are not allowed in this contextでrailsサーバーが立ち上がらない問題の解決方法をご紹介していきます。

mapping values are not allowed in this contextでサーバーが起動しない！

症状としてはターミナルからrails s コマンドを実行時、以下のようなエラーメッセージが表示されました。

# rails s
=> Booting Puma
=> Rails 5.1.6.1 application starting in development
=> Run `rails server -h` for more startup options
Exiting
/usr/local/lib/ruby/2.4.0/psych.rb:377:in `parse': (<unknown>): mapping values are not allowed in this context at line 240 column 10 (Psych::SyntaxError)

(<unknown>): mapping values are not allowed in this context at line 240 column 10 (Psych::SyntaxError)

240行目のマッピング値が許可されない？みたいなことを仰っているようです。

Psych::SyntaxError というメッセージから察するに、構文エラー系な気がしますね。

mapping values are not allowed in this contextでサーバーが起動しない！ 解決方法

.ymlファイルを確認する！

mapping values are not allowed in this context で似たような症状の人がいないか調査してみました。

すると上記の症状は、サーバー起動時に読み込むdatabase.ymlなどのymlファイルに構文エラーがあると発生する症状みたいでした。

今回はRails製の顧客管理Gem『FatFreeCRM』を利用していたのですが、こちらのsetting.default.ymlという設定ファイルに記述ミスがあったことが原因だったようです。

setting.default.ymlを修正して再びサーバーを再起動すると…

root@123e151e45b0:~# rails s
=> Booting Puma
=> Rails 5.1.6.1 application starting in development
=> Run `rails server -h` for more startup options
[640] Puma starting in cluster mode...

mapping values are not allowed in this context のエラーメッセージが解消され、無事にサーバーが立ち上がりました！やった！

mapping values are not allowed in this contextでサーバーが起動しない！ まとめ

ということで今回はmapping values are not allowed in this contextでサーバーが起動できない問題の解消方法についてご紹介いたしました。

最近なにかと多いrailsエラー解消シリーズ。

今回のエラーについては、終わってみればタイポでエラー起こした結果エラー吐かれて、訳も分からずドタバタと調査してしまった感じになっちゃいましたね。恥ずかしい。

恥ずかしさもブログにしたためることで自らの戒めに……なるといいなあ。

短いですが、今回はここまで。

参考サイト

• https://stackoverflow.com/questions/18685702/rails-4-mapping-values-are-not-allowed-in-this-context-at-line-2-column-11-psy

こんにちは。

Ruby on RailsでWebアプリケーションサービスの開発をしています。

Rubyでバッチ処理を作成していて、「文字列を2文字ずつ分割して配列化したいな」というシチュエーションに遭遇しました。

その際に用いた「文字列を任意の文字数で分割する」方法についてご紹介しようと思います。

Rubyで文字列を任意の文字数で分割する方法

やりたいこと

"143000"

上記のような文字列を……

["14", "30", "00"]

のように2文字ずつに変換したいです。

rubyのscanメソッドを使う！

Rubyの「scan」メソッドを利用することで解決できると考えました。

scanメソッドは、引数で指定した正規表現のパターンとマッチする部分を文字列からすべて取り出し、配列にして返します。

マッチする部分がなければ、空の配列を返します。

具体的には以下のように記述します。

a = "143000"
a.scan(/.{1,#{2}}/)

上記のようにscanメソッドを利用してやると、元の6桁の文字列を、2文字ずつの配列に変換することができました！

「2」の部分を変更することで、「何文字ずつ区切るか」を指定することができます。

scanでの文字列分割について、もうちょっと詳しく

正規表現では「.」が改行を除く任意の1文字 として扱われます。

{}の中で「それを何回繰り返すか」という数を指定しています。

今回のケースでは「1回以上最大2回」のため、 .{1,#{2}}  といった書き方になりました。難しいですね正規表現。

1文字ずつの文字列分割の場合は、spritも使えます

splitメソッドは、引数patternを区切り文字として文字列を分割し、配列を返します。

引数の指定のしかたによってさまざまな分割ができます。分割できなかったときは、要素が文字列1つだけの配列を返します。

任意の文字数ではなく単に1文字ずつ分割したいという場合はspritメソッドも使えたりします。

str = "1234567890"
str.split(//) 

上記で叩くと……

=> ["1", "2", "3", "4", "5", "6", "7", "8", "9", "0"]

文字列が1文字ずつ分割されました！

2019/09/21 追記

1文字ずつの文字列分割の場合は、charsメソッドも簡単でいい感じです

charsメソッドは、文字列中の文字を繰り返し取り出します。

ブロック引数charに1文字を入れながら、文字数だけブロックを繰り返します。戻り値はレシーバ自身です。

str = "1234567890"
str.chars
=> ["1", "2", "3", "4", "5", "6", "7", "8", "9", "0"]

spritよりもシンプルに書けていい感じですね。

1文字ずつの文字列分割ならこれで良さそうです！

Rubyで文字列を任意の文字数で分割する方法 まとめ

今回はRubyで「文字列を任意の文字数で分割する方法」についてご紹介しました。。

こういう「やりたいことは分かっているけど、メソッドや書き方がわからない！」みたいな時って調べる単語めっちゃ重要ですよね。

今回は「Ruby 文字列 分割 文字数」みたいなキーワードで調査したため、比較的早くやりたいことにたどり着けましたが、言葉が全然出てこないときがままあります……。

上手に検索するのもエンジニアのスキルかと思うので、目標に対する言語化みたいなところも育てていく必要ありですね。

短いですが、今回はここまで。

参考サイト

• https://qiita.com/paty-fakename/items/990fe9d57864054409e1
• https://ref.xaio.jp/ruby/classes/string/scan

こんにちは。

Androidアプリ開発をしていて、Android App Bundle(.aab)を実機端末にインストールする方法がわからなかったので、調査しました。

成功した方法を備忘録として残しておきます。

Android App Bundle(.aab)を実機端末にインストールする方法

aab実機インストール準備

aabの実機インストールに「bundle tool」というツールを使うので、以下からダウンロードします。（bundle tool……ググラビリティ低めですよね…）

releasesの最新版.jarファイルをダウンロードすればOKです。

aab実機インストール作業

① bundle tool.jarと、出力したandroid app bundle(.abb)、キーストアファイルを同じディレクトリに配置する

ファイルの配置ができたらターミナルからcd で移動しておきます。

② bundle toolを使った、.apks作成コマンドを実行

ターミナルから以下のコマンドを実行します。

java -jar bundletool-all-0.12.0.jar build-apks --bundle=app-release.aab --output=app-release.apks \
--ks=キーストア \
--ks-pass=pass:キーストアのパスワード \
--ks-key-alias=キーのエイリアス \
--key-pass=pass:キーのパスワード

bundle tool.jarのバージョン名や、aabのファイル名など適宜変更してください。

上記成功で.apksという形式のファイルが出来上がります。

③ Macとandroid実機を接続して、apksのインストールコマンドを実行

java -jar bundletool-all-0.10.3.jar install-apks --apks=app-release.apks 

Android実機端末にアプリがインストールされていれば完了です。お疲れさまでした。

私の場合はここで更に以下のエラーが発生しました。

Error: Unable to determine the location of ADB. Please set the --adb flag or define ANDROID_HOME or PATH environment variable.

上記の解決方法についてはこちらの記事でご紹介していますので、同様のエラーでお困りの方は参考にしてみてください。

Android App Bundle(.aab)を実機端末にインストールする方法 まとめ

実際の開発よりも、こういったbuild関連でハマる時間の方が長いですよね。

aab、軽くてダウンロードが早くなったりするらしいですけど、apkに比べて面倒なこと多い印象です。

短いですが、今回はここまで。

参考サイト