2023年6月1日木曜日

自分のホームページのコードをリファクタリングしたので感想

自分のホームページのコードをリファクタリングしたので感想

ホームページはこちら

コード概要

  • Ruby + Sinatra
  • redis

エディタは emacs で solargraph + robe で開発しています

リファクタ方針

  • ハッシュベースのルーティング定義をクラス化
  • rubocop の導入
  • TwitterAPI v2 への対応

クラス化について

routing = {
  '/about': {
    tpl: :about
  },
  '/apps': {
    tpl: :apps
  }
}

...

routing.each do |path, info|
  get path do
    # パスに応じて特定の処理をする場合は分岐
    erb info[:tpl]
  end
end

こんな感じでハッシュで定義してループで動的にルーティングを定義していたのを

class AboutPage < Sinatra::Base
  def initialize
    @path = '/about'
    @tpl = :about
  end

  def routing
    AboutPage.get @path do
      erb @tpl
    end
  end
end

こんな感じでクラスベースにして Rack::URLMap.new に設定します

メリット

  • ルーティングごとに分岐しなければいけない処理が複雑化しない
  • xxxPage クラスの親クラスを作って共通処理を抽象化できる
  • もしくは Mix-in を使って処理を共通化し特定のページでのみ使い回せる

デメリット

  • ルーティングを追加する際にクラスを追加しなければならない
  • ファイルが増える

rubocop について

基本は rubocop が出す警告などは全部対応します

基本辛いが特に辛い点

  • Metrics/MethodLength
  • Metrics/AbcSize

Method に限らず Block, Class, Module が長すぎるという警告に対応するのは大変です
個人的には以下のように対応しています

  • メソッドに分割
  • 抽象クラスの作成
  • One line 記述を使う
  • ハッシュなどのデータは外部ファイルに移動して JSON.parse(File.read('xx.json')) する

rubocop っぽいコードになる

特に以下のような記述が増えます

  • ガード
  • 細かいメソッドやモジュール、クラスに分割される
  • クエスチョンマークを使ったメソッドが増える
  • get set などを使ったメソッド名が消える
  • freeze がよく出る
  • __dir__ がよく出る
  • クラスやモジュールの先頭に必ずコメントが出てくる
  • do .. end or {} の使い方が明確になる
  • ハッシュは {key: 'value'} のような記述になる
  • ダブルクォートは使わなくなる
  • リテラルが増える

特に2つ目の細かいメソッドやモジュールへの分割ですがこれが個人的に何ともというか本当に良いコードになっているのか微妙でコードを読むときにいろいろなところにジャンプしなければいけないのが辛いかなと思っています
行は増えますが単純に上から処理を辿って行くだけで読み解くことができるコードのほうが自分は見やすいかなと思っています

rubocop は他の言語の linter に比べてかなり厳しい印象です

TwitterAPI v2 化について

古いアプリが pending され使えなくなっていたので新しく作り直したのと新しいアプリは v2 を使うようにしました (参考)

gem によっては v1.1 しか使っていないので v2 化していない部分は自作しました

全体通して

個人的にリファクタリングはテストを書くくらい嫌いです
理由はリファクタリングが直接利益につながることが少ないからです
また際限がなくどこまでもできてしまうのと人による好み (バイアス) により記述が変わるので正解がありません

今回のリファクタリングの目的はコードをキレイにしてメンテナンスしやすいコードにするというよりかは Ruby 力を高めるためにやりました

コードフォーマットについて

外部に公開しているコードは linter などを適用したほうがいいと思うのですが Ruby の場合いろいろな linter や formatter があるのでなかなか万人に共通するコードにするのは難しいかなと思います

また Sorbet や Tapioca など静的解析ツールがまだまだどうなるかわからないのでそれに追従すると特殊な記述がコード内にいろいろと現れます

lsp の登場による影響なのかもと思ったりしていますが最近は Type hint がやたら流行っている気がします
型があったほうが堅牢なコードにはなりやすいとは思います
ただ Ruby の場合 lsp のために (エディタのために) コード内に記述しなければいけないコードがあったりするのでそこは少し本質とは異なるので歯がゆいかなと思っています (実際になくても動くのであればないほうがいいのかなと)

Ruby の場合は無理して Type hint しなくてもいいのかなと思っています
Try & Error や Spec テストで補えばいいのかもしれません

テストについて

大規模リファクタリングをするときにテストがあるかないかで負荷がだいぶ変わってくる気がします
特にユニットテストではなく外部からテストするような運用テストなどがしっかり備わっているかどうかで大規模リファクタリングに踏み出せるかどうかが決まると言ってもおかしくないかなと思います

2023年5月12日金曜日

LINE-mqttbot を localhost でテストする方法

LINE-mqttbot を localhost でテストする方法

概要

自作の LINE-mqttbot のデバッグ方法をいつも忘れてるのでメモしておきます

ngrok を使います

環境

準備その1: コード取得

準備その2: MQTTブローカーの準備

なんでも OK です
今回は CloudMQTT を使います

準備その3: LINEビジネスアプリの登録

https://developers.line.biz/console/ ここから登録します LINE アカウントがあれば登録できます

トークンなどの必要な情報をメモしておきましょう

  • チャネルID (LINE_CHANNEL_ID)

  • チャネルシークレット (LINE_CHANNEL_SECRET)

  • チャネルトークン (LINE_CHANNEL_TOKEN)

「セキュリティ設定」の IP アドレス制限は今はないらしいので既存の設定がある場合は削除しておきましょう

起動する

LINE と MQTTブローカの必要な情報を環境変数に設定して起動します

LINE_CHANNEL_SECRET=caxxx \
LINE_CHANNEL_TOKEN=Ckxxx \
MQTT_HOST=m11.cloudmqtt.com \
MQTT_PORT=10707 \
MQTT_TOPIC=topic_name \
MQTT_SUB_TOPIC=topic_name \
MQTT_QOS=0 \
MQTT_USERNAME=username  \
MQTT_PASSWORD=xxxxxxxxxxxx \
bundle exec rackup config.ru

ngrok でグローバルからアクセスできるようにする

9292 ポートで起動するのでそれを ngrok でアクセスできるようにします

  • ngrok http 9292

払い出された URL はメモしておきましょう

ngrok の URL を LINEビジネスアプリのWebhook URL に設定する

  • MessaginAPI 設定 -> Webhook 設定 -> Webhook URL

https://xxx.jp.ngrok.io/callback という感じでちゃんと最後に /callback を設定するのを忘れないようにしましょう

動作確認

  • mosquitto_sub -h m11.cloudmqtt.com -p 10707 -t 'topic_name' -u 'username' -P 'xxxxxxxx'

でメッセージが受け取れるか確認します

あとは携帯やデスクトップ版の LINE アプリから LINE ビジネスアプリと友達になりメッセージを送信して MQTT にまでメッセージが来るか確認すれば OK です

最後に

ngrok の URL は毎回ランダムなものが払い出されるのでそのたびに LINE ビジネスアプリの WebhookURL に設定してあげましょう
ローカルでの動作確認なのでランダムで払い出される URL のほうがセキュアかなと思います (ngrok の場合 URL さえ知っていれば誰でもアクセスできてしまうので)

トラブルシューティング

CloudMQTT は長時間使われていないと停止するので Connection Refuse になる場合は一旦 ResetDB してみてください

2023年4月4日火曜日

家族四人でディズニーランドに行くとかかる料金

家族四人でディズニーランドに行くとかかる料金

備忘録として残しておきます
2023年2月の時点での料金になります
時期によっても異なる部分はあると思います
夕食はパーク内では取らなかったので夕食代は除外しています

まぁ高いですね

構成

  • 大人2人
  • 小人1人
  • 幼児1人

合計

47780円

入場料

  • 8400 * 2 = 16800円
  • 5000 * 1 = 5000円

小計 21800円

交通費

  • 高速代 1950円 * 2 = 3900円
  • ガソリン代 1000円
  • 駐車場代 2500円
  • 車代 7210円

小計 14610円

飲食代

昼飯 (ヒューイ・デューイ・ルーイのグッドタイム・カフェ)

  • ミッキーピザ (チェダーチーズ&ソーセージ) 1230円 * 2 = 2460円
  • グローブシェイプ・エッグチキンパオ 1080円 * 2 = 2160円

軽食

  • ミッキーチュロス(シナモン) 450円 * 3 = 1350円
  • スモーキーターキレッグ 900円 * 2 = 1800円
  • 飲み物 200円 * 2 = 400円

小計 8170円

お土産

  • バウムクーヘン 1400円
  • カチューシャ (スパンコールキラキラ) 1800円

小計 3200円

2023年3月1日水曜日

ダイソンV6メンテナンスメモ

ダイソンV6メンテナンスメモ

2016年に購入したV6を未だに現役で使用しています
長く使い続けるためのメンテナンス方法を紹介します

バッテリー

  • 2,3年に一回は交換が必要
  • 4000mAh でも 30 分くらいしかフル稼働しない
  • 参考

フィルタ

掃除

  • 1ヶ月に一回は水洗いすること
  • 縦長とMaxボタンがあるところのフィルタ
  • 乾燥が必須なので予備で2セットあると便利

交換

  • 2,3年に一回は交換が必要
  • 交換の目安は縦長のフィルタが洗っても真っ黒な状態になったら

モーターヘッド

モーターブラシ掃除

  • 半年もしくは1年に一回は水洗いすること

モーターヘッド掃除

  • 半年もしくは1年に一回は水洗いすること
  • 六角星型ドライバがあれば解体可能
  • 特にモーターブラシが当たるシャーシの部分はかなり汚れやすい

ジャバラ

  • 2,3年に一回は交換が必要
  • モーターヘッドとロングパイプの間くらいにあるジャバラ
  • 首振りを多用しているといつの間にかボロボロになっている
  • ここがボロボロのままにしておくとモーターヘッド装着時の吸引力がかなり落ちる
  • モーターヘッド装着時に移動が軽くなり始めるとジャバラがボロボロになっている可能性がある

交換

  • 動かなくなったら交換でOK
  • 電気が届いていない、モーターが焼ききれているなどが考えられ対策できない
  • ジャバラに関しては別途購入して交換できるのでジャバラがボロボロになってもモーターヘッド自体の交換が必要なわけではないので注意

最後に

フィルタを毎月洗いつつ一年に一回各種パーツのメンテや調子を見ればいいかなと思います

2023年2月13日月曜日

育児について感じていること

育児について感じていること

二人の子供をそれなりに育児してきて感じたことをまとめておきます
あくまでも個人的な意見になります

コンテキスト

こちら

人間だからイライラはするが基本は怒らない

育児の極意はこれに尽きると言ってもいいかなと思います
とにかく怒らないことイライラをいかに避け抑えるかだと思います

たまーに自分も怒りますがほぼ怒らないようにしています
理由はいろいろありますが一番は自分が怒っても誰も何も得をしないからです (怒っても意味がない)

やりたいようにやらせてあげる、絶対ダメなことはダメだとしかる、メリハリが大事

怒らないと言っても躾はしっかりします
「ルールを守らなかったとき」に躾をします
子供と同じ目線に座りしっかり前を見て子供に言い聞かせます
ただこのときも怒ってはいけません
あくまでも躾として言い聞かせているという意識が大事です
怒ってしまうと子供にも怒りの気持ちが伝わり悲しい気持ちになってしまうのでそれだと躾の意味がありません
「怒ってはいないんだよ、ちゃんとルールは守ろうね」というのが伝わるようにしてあげます

基本はやりたいようにやらせてあげています
子供が「公園でもっと遊びたい」「大人のものを使ってみたい触ってみたい」ときなど子供の好奇心による行動は基本的には制限しないようにしています (もちろんルールをやぶったり、危険ものは触らせてはダメです)

というのも例えば公園で遊んでいて無理に「帰るよー」と言っても子供は帰りません (たぶん経験している人は多いと思います)
そういうときは逆に飽きるまで遊ばせてあげると結構すんなり帰ってくれます
子供といえど結局は人なのでお腹が空いたり疲れたりすれば帰ろうと気持ちになるんだと思います

大人の都合で帰るとかダメとか言うのは結果的にいろんな意味で遠回りすることが多い気がしています

子供の行動を予測してこれからどういうことが起きるかある程度予測できればあまりイライラしない

子育てでイライラしない方法の一つとして「予測」があると思っています

例えばご飯を食べているときに茶碗をひっくり返したり水をこぼして水浸しになることがよくあります
このときに「なにやってるの!」と怒ってはいけません
子供なのでそういうことは多分にあります
そこでイライラしてしまうのはそういうことが起きないと先入観を持ってしまっているからで人間は予期しないことが起こるとイライラしたりします

だったら始めから「これからご飯だから床が大変なことになるだろうなー」「よごれてもいいように準備しておこう」と思っておけばいざ先程のことが起きても意外とイライラせずサッと対応できます
逆に予測を裏切って子供がまったくこぼさず上手に食べれると勝負に勝ったような気分になり子供を褒めたりいいことが起きやすくなると思っています

こんな感じであらゆることを事前に予測しておくと少しでもイライラを抑えられるようになるかなと思います

大人の都合と子供の都合

  • 大人・・・時間がない、やることがある
  • 子供・・・遊びたい、やりたい

こんなときにいかに子供を優先できる余裕が持てるか持てないかかなと思います

自分を俯瞰できるようにする

これは怒ってしまっているときに使えるテクニックで怒りを鎮めるときにいいかなと思っています

子供にでも何にでもそうですが怒っているときにその怒っている自分を俯瞰して見てみましょう (見てみましょうと言っても普段から俯瞰的に自分が見れていないとなかなか難しいですが)
そうすると「あーなにやってるんだろうなー」とか「子供にマジ切れしてる自分の姿はかなしいなー」などと感じることができるようになります
そうすると自分を抑えることができます

一歩引いて他人の目線から自分を見ると自分がどういう状態なのかすぐに把握でき、自分のニュートラルな状態にすぐに戻すことができるようになります

子供の気持ちになってみる

俯瞰することは子供の気持ちになってみることに近いかなと思います
どうして子供が泣いているのか、どうして子供がそうしたいのかというのが子供の立場になって考えてみるとわかることがあるかなと思います

ルーチン化する

子育ては単純ではないですがやること自体は単純なことが多くルーチン化することができます
たとえば「仕事終わり -> 保育園のお迎え -> 公園で遊ぶ -> 帰ってきて手洗いうがい -> お風呂沸かす -> お風呂入れる -> からだ拭く -> クリーム塗る -> パジャマ着る」という流れは毎日自分がやっている流れなのですが毎日のようにやっていると体が慣れてきて大変だなと思わなくなります
やって当然だと思えてきます

またやることがわかっているので無駄な時間を使わずに最短距離で駆け抜けることができるのでストレスなく進めることができるようになります

たまにイレギュラーなことは当然起こりますがその場合も「予測」と「俯瞰」で何とかなります

慣れるが怠惰になってはいけない

ルーチン化することはいいことではあるのですが慣れすぎて怠惰になってはいけないかなと思っています
人間は慣れてしまうと怠惰になり思わぬミスを招いたりします
慣れという流れの中に少しでもノイズが入ってくるとそれだけでイライラしたりします

ルーチン化しつつも常にそのルーチンの精度をあげる、成長させるという意識を持ちながらやるといいかなと思っています

ルーチン化した上で効率化する

ルーチンをリファクタすることはいいことです
実はルーチンの中に無駄なことやいらないことがあったりするのでそういったものは削ぎ落としましょう
またルーチンの精度を上げるために新たにものを取り入れるのもいいと思います
例えば先程のルーチンの中だとお風呂から上がったら必ずクリームを塗ってパジャマに着替えるという流れがあります
この流れの中で「タオル」や「クリーム」「パジャマ」などは事前に準備しおくことができます
事前に準備しておけば子供たちもやることがわかるし協力もしてくれるので時間の節約にもなります

こんな感じで自動化ではないですが事前に準備できることを前もってやっておいたりしておくと楽にこなせるようになったりします

おもちゃの扱いについて

これも子育てテクニックなのですが子供が遊ぶおもちゃはちょっと工夫するだけで長く飽きずに使えるかなと思っています

定期的に入れ替える

我が家ではおもちゃの置き場所は2つあり「常に子供の目につくおもちゃ置き場」と「保管しておくおもちゃ置き場」があります
大事なのは後者で後者は子供だけだと簡単に取り出せない場所にあります

子供は新しいおもちゃを買ってあげるとすごく喜びます
しかし一週間、一ヶ月もすると大抵飽きて遊ばなくなってしまいます
せっかく買ってあげたおもちゃをすぐに遊ばなくなると大人も悲しいのでおもちゃは定期的に入れ替えてあげるようにしています

ちょっと面倒かもしれませんがこれだけでもかなり効果があるかなと思っています
またもう少し言うとおもちゃは雑多に置かずにきれいにしまっておくと子供も毎日新鮮な気持ちでおもちゃと遊んでくれるような気がしています

自分の趣味を必ず持つ

ここからは少し話が変わりますが子育てを長く楽しく続けるテクニックの一つとして自分のコントロールが非常に重要だと思っています

「予測」や「俯瞰」は子育ての中のテクニックですが子育て以外でも自分をコントロールできるようにしておくと結果的に子育てにもいい影響があるかなと思っています

趣味でなくてもいいのですが自分への「ご褒美」的にものを作っておきましょう
自分では感じないけどストレスが溜まっているケースは少なからずあるのでそういったストレスを発散できるような趣味があるといいかなと思っています

大人になってから没頭できる趣味を探すのは本当に難しいと思っています
それは時間や場所が制限されるからです
仕事と子育てで大抵の時間が取られてしまうのは当然ですが自由な場所に行けないというのも趣味が作れない一つの要因かなと思っています
限られた時間と場所の中で何か一つでいいからストレスを発散させられるものがあるといいかなと思っています

なぜなら子育て中でもその趣味ができると思えるようになると頑張れる燃料になるからです

何かしらの犠牲は必要

お父さんなのかお母さんなのかは状況によりますがどちらかが何かしらの犠牲を払って子育てに時間をさく必要がでてきます

犠牲はいろいろありますが例えば

  • 今まではガッツリ残業できていたができなくなる (逆にいいことだと思います)
  • 今までは週末にスポーツをしていたけどできなくなる
  • 朝はゆっくり出社していたけど学校や保育園の時間があるからできなくなる

などなどいろいろあるとは思いますが大事なことは「今までできていたことができなくなる」という認識は事前に持っておいたほうがいいかなと思します

逆に子どもたちと一緒に入れる時間が増えるというのもあるので子どもたちと新しい趣味に一緒に挑戦するのもいいかなと思います

その他、所感など

  • 5歳くらいになるとかなり楽になる
  • (これから先どうなるかはわからないが) 一番つらかったのは2.5から3.5歳

最後に

子育てに正解はありません
日々試行錯誤です

子どもたちと一緒に日々成長していく自分を楽しみましょう

2023年1月22日日曜日

いいコードとはなにか考える

いいコードとはなにか考える

つらつらと思っていることを書き連ねてみます

まとめ

  • シンプルイズベスト
  • コードがいいかわるいかよりもコードを深く理解しているかが重要
  • バグがなければ何でもいいんじゃないか

メンテナンス性について

  • いいコードはメンテナンスのしやすいコードなのか
  • メンテナンスしやすいコードは気軽に変更できる、変更しても影響が小さいなどがあると思う
  • でも結局はコードをしっかり理解しているかどうかな気がする
  • コードを理解していないと気軽に変更も影響範囲もわからないので
  • あとはテスト周りがしっかりしているか、ユニットテストのカバレッジやe2eテストがあるか、CDできる環境があるかも重要
  • 毎回手動でテストするのは辛いし、そうなっているとリファクタリングする気も起きなくなる
  • 今はいいコードだと思って書いても結局1, 2年後見たとときに理解できなかったダメなのでは
  • 何も気にせずファイル1つで全部そこに上から順番に処理するようなスクリプトならどうだろうか

手法について

  • 世の中にはコーディングに関するいろいろな手法や書籍がある
  • いろいろあるがいろいろありすぎて困る
  • 個人的には一番意識するべきは結局シンプルイズベストだと思う
  • いかにシンプルに無駄なことをしていないか=いいコードなのかも
  • コードをシンプルに書くとは簡単に言えば一番上から順番に実行されていくコード
  • いきなりどっかに飛んだり暗黙的なハンドラが呼び出されたりしない
  • あるゴールがあるときにいろいろな書き方があるがその中から最適を選択できるかどうか
  • 選択できるかどうかは経験則だと思う
  • いきなり良いコードは書けないから徐々に良いコードにしていけばいいと思う
  • それをできるかどうかも結局はコードをしっかりと理解しているかが重要だと思う

可読性について

  • いいコードは読みやすいコードなのか
  • メンテナンスしやすいコード=読みやすいコードと言えるのだろうか
  • 結局コードを知るためにはある程度学習しないとダメだとは思う
  • いいコードだと学習時間が短いとは限らない
  • コード把握までの時間を短くするにはドキュメントとトライアンドエラーさせることだと思う
  • いいコードはしっかり抽象化できるている、重複がないというのがよくあるケースだと思うが個人的には抽象化されてすぎていても良くないと思う
  • その心はコードがいろいろなところに分散しすぎていて追いづらいというのがある
  • 可読性を高める最強の要素は「コメント」と「ドキュメント」なのかもしれない
  • チームが日本人なら無理に英語にしないで積極的に日本語を使っていいと思う、コミットメッセージとかIssueとか

バグとの関連について

  • いいコードはバグのないコードなのか
  • 個人的にはこれはイコールではないと思う
  • わるいコードでも全然バグを踏まないコードもあると思っている
  • むしろレガシーコードのほうが安定しているケースもあると思う、いいとは思わないが
  • いいコードにしようと思ってバグを埋め込んではいけない
  • がバグをおそれてリファクタリングしないのもダメだと思う、難しい
  • 結局バグを生み出さないこと品質を担保することが大目的なのであればレガシーコードを運用し続けるのも手だと思う
  • ただ将来の技術的負債になることは間違いない
  • レガシーコードにバグがいきなり発生して誰も直せないパターンとかはあるある
  • レガシーコードを書き換えてモダンコードにするよりかは式年遷宮で全部書き換えるのがいいと思う
  • 当然インタフェースは変えないようにしなければいけないが
  • v2移行などで多少のインタフェース変更が出てしまうことはよくあるのでその場合はドキュメントやコミュニケーションでカバーするしかない

そもそも悪いコードとはなにか

  • 相対する言葉の悪いコードとはなにか
  • アンチパターン的なことなのだろうか
  • 悪いコードを書かないようにすれば自然といいこーどになるのかもしれない
  • そのコードが悪いと客観的に感じることができるかも重要
  • なかなかそれは経験がないと難しいかもしれない

チームビルディングについて

  • いいコードは人によって異なると思っている
  • なのでチームで一つのコードを開発すると個人の思想や経験がコードに反映されてしまうことがある
  • そういうときのために設計思想や開発手法やデザインパターンやフレームワークみたいなものがあるんだと思う
  • がそれでも多少のブレはある
  • 基本はチーム内でコーディング規約などを決める感じにはなる
  • いいコードを書くためにはある程度の経験が必要だと思っている
  • なので経験のある人の思想がチーム内のコーディング規約に大きな影響を与えてしまう可能性がある
  • チームがそれを合意できるのであれば問題ないが押し付けるのはよくないと思う
  • すでに安定しているコードに対してわざわざそれを適用するのかという判断も重要
  • 将来大きな技術的負債になるのであればやるくらいでいいと思う
  • 全員が全員同じレベルのコーダになるのは本当に難しい

テストについて

  • テストもいいコードとして書く必要があるか
  • テストも抽象化やリファクタリングをし続けたほうがいいのか
  • そこまでのコストが割けるか、売上には直結しない
  • プロダクトの品質には影響するかもしれない
  • テストの目的はカバレッジを100%にすることではなく開発者の精神安定
  • テストがしっかり書けている -> 積極的に安心して書き換えできるという意識が重要
  • ただ個人的に思うのはテストはおまけでしかないので面倒だということ
  • その面倒な作業を誰かがやらなければならないということ
  • 分担すればいいというのもあるがそうするとテストコードの書き方がバラバラになりテストの保守性が下がってしまったりする
  • 個人的にはテストコードを書くのは嫌いである

コンテキストによっても違う

  • ちょろっとスクリプトを書くときには
  • Webアプリケーションやスマホアプリのときには
  • 一時的にしか使わない場合
  • 将来的に継続的に使う場合
  • どんなときでもクラスベースなコーディングが必要なのか

番外編: AIにがんばってもらう

  • copilot のような自動生成にがんばってもらう
  • AI が書くほうがいいコードなはず
  • AIではないがコードジェネレータを作成するのもいいと思う

問題: どっちがいいコードなのだろうか

A

puts "hello"

B

require 'logger'

class Message

  @@logger = Logger.new(STDOUT)

  def initialize(title)
    @title = title
  end

  def say()
    @@logger.info @title
  end
end

Message.new("hello").say
  • 用途にもよる?
  • 将来どうメンテナンスしていくか?
  • 経験のあるなしに影響する?

2023年1月14日土曜日

ヴァンパイアサバイバーiOS版プレイメモ

ヴァンパイアサバイバーiOS版プレイメモ

環境

  • iOS 版バンパイアサバイバー 1.2.119
  • 無料

プレイ時間

たぶん 40 時間くらい

操作について

  • 画面を上下左右に動かすことでキャラクターを動かす
  • ストップボタンが右上にあるので押しづらい
  • ランドスケープでもポートレートでもプレイ可能
  • 画面が小さい端末だとステージの最後のラッシュとかは見えないかも

ゲームについて

クリア

  • 一応各ステージクリアはあるがそれよりもレリックや装備開放、仲間開放などがクリア要素は強そう
    • ゲームトップにあるアンロック、コレクション、シークレット一覧を全部アンロックできればクリアでもいいかも
    • シークレットキャラの出現方法は正直攻略サイトを見ないとわからない
    • スマホ版の場合 exdash と toastie と smith iv はシークレットの一覧画面から矢印で呪文入力になるのでそこで呪文を入れて開放する
  • ステージ5とユーダイモニアMにはそれっぽいボスがいる
    • ユーダイモニアMのクリア後に極大聖年が手に入るがコレクションにない場合は一回ステージでレベル上げをして武器として取得すればコレクションに入る
  • 30秒後の最後の悪魔は倒すことができる、倒すとたまご5つと最後に白黒の悪魔が出てきて倒される
    • 倒すとレッドデスというキャラが使えるようになる
  • シグマが強すぎる
    • コレクションコンプリートで使えるようになる

ボスラッシュ難しすぎ

  • 敵の強さはこちらのレベルで変わるのでゲームキラーのアルカナを使うことで敵を弱くして簡単にクリアすることもできる

武器について

序盤はニンニク

ほぼワンパンで倒せるので経験値稼ぎが楽

強いと思った武器

基本進化すれば全部強い
特に序盤から強いと思ったのは

  • 時止めナイフ (進化しなくても鬼強)
  • 鳥 (進化が面倒)
  • 二丁拳銃 (進化が面倒)
  • ナイフ (連射が楽しい)
  • 魔法杖 (学術書が強い)

好きな武器

  • 時止めナイフ

よく使う組み合わせ

序盤、ステージクリア目的

  • キャラ武器
  • 時止めナイフ
  • 魔法杖
  • 雷の指輪
  • 月桂樹
  • ナイフ or 斧 or 炎の杖

終盤、最強セット

  • 勝利の剣
  • ナイフ (子手)
  • 魔法杖 (学術書)
  • 雷の指輪 (複写)
  • 炎の杖 (ほうれんそう)
  • ミススペルの炎 (トローナ)

あと人枠は翼とか骸骨とか

あまり使わない武器

  • 五芒星
  • ドリル

キャラについて

  • 足の速いキャラは強い
    • 序盤だとクロチ
  • シークレットキャラも強い

金策

  • いろいろやり方はあるらしいけどシグマでムーンゴロウをハイパー+反転で適当にやるのが一番楽
  • アルカナで黄金色のディスコを選択する
  • 仮面とか骸骨あたりをいい感じにレベル上げしていく

唯一開放できなかったシークレット

  • 「前に所有されたいた棺桶の下を見る」がどうしてもアンロックすることができなかった
  • 2回目の棺桶がどのステージにも出現しなくてどうしようもなくなった
  • 全キャラを必ず一回プレイするとかコレクションを全部開放するとかキャラ強化を全部行うとかやったけどダメだった
  • 何か他に条件があるのだろうか

敵キャラについて

なぜか 105 番のラスボスだけはユーダイモニアMを2回クリアしないと一覧に載らなかった

最後に

一回 15分 or 30 分のプレイなので複数回プレイするだけであっという間に時間がなくなる