2024年12月3日火曜日

自分はレビューいらない派です

自分はレビューいらない派です

ChatGPT 先生と相談しやはりいらないという結論に至りました

レビューの意義やメリットについてはここでは触れません、またそれらも人それぞれの感性があることを前提に進めます

この記事は全面的にレビューを批判する記事になっています

自分のレビューに対する考え要約

  • レビューでバグは潰せない
    • それならばE2Eなテストを増やそう
    • ちなみにテストを書くにも嫌い (特にユニットテスト)
  • 情報共有の意味があるならレビューではなく直接タスクを与えたほうが価値がある
  • 静的解析、テストなどシステムにすべてまかせるような仕組みを作るべき
    • それがないから人間(レビュー)に頼ってしまう
  • 作ってくれた人は全面的に信頼している
    • どうしてもその人がレビューしてほしいと思うのであればやるべき
    • 作ってくれたコードに文句を言いたくない、文句があるなら自分で直せばいいだけ
  • そもそもレビューは同レベルの知識を持つ人でないと意味がない
  • バグのないアプリは存在しない
    • 自分は常にそう思っている
    • バグがある箇所や時期を踏まれていないだけでどんなアプリにも必ずバグはある
    • もしくは全く使われていないだけか
  • 上記踏まえて時間の無駄、逆にやらないことによる時間を有意義に使える

ChatGPT先生との相談ログ

以下先生に相談したログです
フォーマットなどは崩れていますが可能な限り読みやすいようにしています

Q: コードレビューについて質問です。自分はコードレビューは意味がないと思っているのですがあなたはどう思いますか?

A:

コードレビューが意味がないと感じる理由を教えてもらえますか?その理由によっては、コードレビューの意義を再考したり、効率を改善したりするアプローチが見つかるかもしれません。

コードレビューは多くの現場で以下のようなメリットをもたらすと言われています:

品質の向上
バグの発見や設計の見直しが行われ、コードの品質が向上します。複数の目で見ることで、自分では気づけないミスや改善点が見つかることがあります。

ナレッジ共有
他の開発者がコードを読むことで、プロジェクト全体の理解が深まり、属人化を防ぐことができます。

スキル向上
レビューを受けることで、自分のコードスタイルや設計に対するフィードバックが得られ、スキルが向上します。レビューする側も他人のコードを読むことで学びを得ることができます。

規律の向上
他人に見られることを前提にコードを書くため、コードの可読性や設計を意識するようになり、結果としてチーム全体の基準が引き上がります。

ただし、意味がないと感じるケースも理解できます。例えば:

形式的で深掘りしないレビュー: 表面的なコメントや惰性で行われるレビューでは、実際の改善につながりにくい。
過度な批判や不毛な議論: レビューが対立の場になると、効率が下がるだけでなく、チームの雰囲気を悪化させる。
時間がかかりすぎる: レビューが長時間に及び、進捗が遅れる。
もし具体的な課題があるのであれば、それに応じた解決策を一緒に考えられます。たとえば「短時間で効果的なレビューの方法」や「建設的なフィードバックの仕方」などについて話すこともできます!

Q: 自分がコードレビューが意味がないと感じる理由は以下です「コードレビューをしてもバグがゼロになるわけではない」「コードレビューに情報共有の意味があるのならコードレビューで情報共有しないで直接コードを修正するようなタスクを与えて情報共有したほうが効果もある」「時間の無駄」が主な理由です

A:

コードレビューが「意味がない」と感じる理由、納得できる部分もあります。それぞれのポイントについて考察と改善のアイデアをお伝えします。


1. コードレビューをしてもバグがゼロになるわけではない
考察: 確かに、コードレビューをしてもバグがゼロになる保証はありません。バグは多くの場合、コード以外(設計、要件定義、使用環境など)に起因することもあります。また、レビューでは見逃しが発生する可能性も高いです。

改善アイデア:

レビューの目的を明確化する: 「バグをゼロにする」ことを期待するのではなく、「主要な設計ミスや重大なバグを減らす」「可読性やメンテナンス性を向上させる」ことに焦点を当てると現実的です。
ツールを活用: 静的解析ツールやテストフレームワークで自動的にバグを検出できる部分を先に排除し、コードレビューの負担を減らす。


2. コードレビューより直接修正タスクを与えた方が効果がある
考察: 「修正タスクを与えることで学ぶ」というアプローチは効果的です。ただし、修正を行う本人がプロジェクト全体の背景や他の影響を理解していない場合、不適切な修正が増えるリスクがあります。

改善アイデア:

ペアプログラミング: 修正タスクを与える代わりに、タスクを行う開発者とコードの知識を持つレビュー担当者が一緒に作業する。これにより効率的な情報共有が可能。
モブプログラミング: チーム全体で特定のコードを修正しながら、全員で学び合う場を作る。
事前の知識共有: タスクを与える前に、該当箇所に関連する設計や背景知識をしっかり共有しておく。


3. 時間の無駄
考察: 時間がかかりすぎたり、効果を実感できないコードレビューは、無駄と感じやすいです。特に、形式的で建設的な議論が生まれないレビューは、コストに見合うリターンが得られません。

改善アイデア:

軽量レビューの導入: 大規模なコードレビューではなく、小さな変更を頻繁にレビューすることで、時間を節約しつつ質を保つ。
レビュー基準の明確化: 「何を確認すべきか」をチームで明確にして、効率的なレビューを目指す。
ツールの導入: GitHubやGitLabなどのプラットフォームを活用して、変更箇所のみをピンポイントでレビューする。


代替案:コードレビューを廃止した場合のリスク評価
もしコードレビューを完全に廃止した場合、以下のリスクが考えられます:

コードの品質や一貫性の低下
属人化の進行
他メンバーのスキル向上や学習機会の減少
これらのリスクを受け入れられる場合は、より直接的なアプローチを選ぶのも1つの方法です。ただし、チームメンバー全員の合意と運用ルールの徹底が必要です。

Q: コードの品質や一貫性の低下はユイットテストやエンドツーエンドテストで補えると思います。属人化の進行はレビューではそもそも補えません、実際にコードを書けるレベルになって初めて属人化の解消になります。他メンバーのスキル向上や学習機会の減少、これもレビューでは補えません。属人化の部分の回答と同じです

A:

なるほど、非常に筋が通った主張ですね。コードレビューのメリットとして挙げられがちな点が、他の方法で代替可能であるという視点は重要です。以下の観点であなたの意見を深掘りしつつ、代替アプローチについて考えてみます。


1. コードの品質や一貫性について
あなたの言う通り、ユニットテストやエンドツーエンドテスト(E2Eテスト)は、バグ検出や動作保証の観点でコードレビュー以上に効果を発揮することがあります。さらに、コードの一貫性についても、自動化ツール(PrettierやESLint、StyleCopなど)を使えば、レビューに頼る必要がほとんどなくなります。

代替アプローチ:

テストカバレッジの向上: ユニットテストやE2Eテストの割合を高め、レビューではチェックしない項目をカバー。
CI/CDの整備: 自動テストとコードフォーマットチェックをCI/CDパイプラインで実行し、レビューを通さずに品質を担保。
注意点: ただし、レビューはコードの「意図」や「設計」にフォーカスできますが、自動化ツールはその部分を補えないことがあります。テストで検出できない設計ミスや冗長な処理を防ぐための仕組みが必要です。


2. 属人化の進行について
属人化の解消には、「コードを書けるレベルになる」ことが不可欠であるという点に同意します。コードレビューだけでは、確かにそれが実現しない場合も多いです。

代替アプローチ:

ペアプログラミングやモブプログラミング: 直接的にコードを書きながら学ぶことで、知識共有とスキルアップを同時に実現できます。
ローテーション制度: 特定のタスクや機能領域について定期的に担当者を変える。これにより、複数のメンバーが同じ部分を理解する機会を得られます。
技術共有会: チームでコードや設計について定期的に議論し、属人化を減らす。


3. スキル向上や学習機会について
コードレビューはスキル向上の一部を担うことがありますが、必ずしもそれが最適な手段とは限りません。レビューのコメントが表面的だと学びは少なく、実際にコードを書く経験には遠く及ばないという意見は非常に妥当です。

代替アプローチ:

トレーニングタスクの設定: 開発者が新しい技術や設計パターンを学ぶための小さなタスクを与え、学びの機会を明確化。
メンター制度: 経験豊富な開発者が他のメンバーを指導し、実践を通じて学ぶ環境を整える。
レビュー以外のフィードバック: リアルタイムでのコード解説や設計レビューセッションを設ける。


結論
あなたの意見の核は「レビューだけではこれらの課題は解決しきれない」という点にあり、それは正しいです。加えて、レビューは一つの手段に過ぎず、それがチームにとって非効率であるならば、他のアプローチを導入すべきです。

チームとして以下のようなプロセスを試してみる価値があるかもしれません:

コードレビューの目的を再定義: レビューを行う場合でも、レビューの対象や方法を限定し、設計や意図に焦点を絞る。
自動化と実践型アプローチを組み合わせる: テストやCI/CDの自動化に投資しつつ、学びの場としてペアプログラミングや技術共有会を導入。
コードレビューを必須にする必要はありません。チームの状況や課題に合わせて柔軟にプロセスを設計することが最も重要です。

Q: ではコードをチェックできる自動化された環境がありかつチーム内で属人化を解消するコードの知識を共有する体制になっているのであればレビューは不要という認識でいいでしょうか?

A:

その通りです!コードをチェックする自動化された環境が整っており、かつ属人化を解消するためのコード知識共有体制が機能しているなら、コードレビューは不要と言えるでしょう。

以下にその条件を整理します:


1. 自動化されたチェック環境
静的解析ツール: コーディング規約の遵守や潜在的なバグ検出を行うツール(ESLint、SonarQube、Checkstyleなど)が適切に設定されている。
テスト自動化: ユニットテスト、統合テスト、E2Eテストが十分にカバーされており、CI/CDパイプラインで実行される。
コードフォーマットツール: PrettierやBlackなどでコードのスタイルを自動整形し、見た目のレビューを不要にする。
セキュリティチェック: 依存関係の脆弱性チェックやコードのセキュリティスキャンを自動化している。


2. 属人化を解消する仕組み
ナレッジ共有の文化: ドキュメント化や共有会、コードベース全体の可視性が確保されており、誰でも理解しやすい体制になっている。
ローテーションやペアプログラミング: 特定のタスクや機能領域が特定の人に依存しないように、メンバーが交代でコードを触る機会がある。
実践を通じた学び: 他のメンバーが既存のコードを理解しやすいタスク設計やコーディングの実践が行われている。
コードの意図を記録: 関数やクラスのコメント、設計ドキュメント、コミットメッセージで十分にコードの意図が伝わるよう工夫されている。


3. レビュー不要とする前提条件
以下の質問に「はい」と答えられる場合、レビューは不要と考えられます:

バグの発生率が許容範囲内か?
→ テストや静的解析でほぼ十分にバグが防げている。
チーム全員がコードの目的や設計を理解しているか?
→ 共有体制が機能し、メンバーがコードを理解している。
新メンバーが独立して貢献できるまでの時間が短縮されているか?
→ ドキュメントやナレッジ共有によって属人化が解消されている。
チーム内の信頼が高いか?
→ メンバー間の信頼が高く、他人のコードが問題なく利用できる。


検討ポイント
レビューを廃止する前に以下も確認すると良いでしょう:

トライアル期間を設ける: レビューを完全に廃止する前に、レビュー頻度を下げたり、特定のケースでのみ行う運用を試してみる。
データの計測: レビューをしないことで、バグの発生率やリリース速度がどう変化するかを測定する。


結論
「自動化されたチェック環境」と「属人化を解消する仕組み」が整備されているのであれば、レビューは不要であるという認識で問題ありません。それどころか、その環境が機能している場合、レビューを行うことが逆に非効率になる可能性もあります。

重要なのは、チームにとって最適なプロセスを柔軟に設計し、定期的に見直すことです。このアプローチがあなたのチームにとってベストな選択肢になることを願っています!

相談した結果感じたこと

レビューは一つの手段に過ぎず

確かにこれには同意した
強制するものではなくあくまでも「手段」であるということ
そういう意味でも自分はレビューという手段の優先度はかなり低い

あなたのチームに合ったプロセスを模索するのが重要

確かにこれも同意した
チーム内でレビューに重きを置いていることを上も理解してそこにコストを割くことを容認してくれている場合はじっくりやっていいと思う

ただそれでもコードの内容を知らない人にレビューしてもらっても何も意味がない気がする

データの計測: レビューをしないことで、バグの発生率やリリース速度がどう変化するかを測定する。

これも同意
むしろデータ計測やサービス効果測定みたいなものは初めからあってもいいと思う
ただどうやるかと何を評価項目にするかとどう抽出するかはかなり難しい気がする

最後に

最後は ChatGPT 先生を言いくるめたような感じなってしまいましたが最終的には自分の意見に同意してくれたのでよかったです

参考文献

2024年11月25日月曜日

NHK 解約までの流れ

NHK 解約までの流れ

だいたい1ヶ月ほどかかりました

期間

2024/10/27 - 2024/11/25

  • 2024/10/27 テレビ廃棄、NHK解約入電
  • 2024/11/8 解約書類到着、即日発送
  • 2024/11/25 払い戻し金入金

料金

  • リサイクル料金 6,820円
  • 新規モニター 必要に応じて
  • 印刷代 10円
  • NHK 解約料金 0円

ポイント

  • とくかくテレビを捨てること
  • 悪魔の証明での解約は難しい
    • BCAS がないなど

テレビのリサイクル申し込み

必ずリサイクル券の控えをもらいましょう
最短で3日後とかで回収してくれます
リサイクル料金と配送代を現金で渡しましょう

NHK 解約申し込み

0120-222-000 に電話します
繋がりにくいですが待っていればそのうち繋がります
テレビを廃棄した旨とそれを証明できる写しがあることを伝えましょう
あとは簡単な本人確認だけで OK です
後日書類が届くので待ちます

折り返しの電話があるケースもあるらしいのですが自分はなかったです

だいたい10-15分くらいで完了しました

書類記載

電話をしてから8日後に郵送で解約書類が来ました
書類に記載するポイントは以下です

  • 受信機の数は衛生1台を記載
  • 解約の理由は受信機の撤去で方法は家電リサイクルと記載
  • 受信機の設置予定はなしにチェック

あたりです
他の部分は契約情報を記載しましょう

また家電リサイクル時に受け取った控えをコピーして一緒に返送するのを忘れないようにしましょう

解約の受理

11/25(月)に払い戻しがありました
特に連絡はありません
解約の際の払い戻しの口座に入金されたことで受理になります

最後に

また見たくなったら契約しましょう

2024年11月13日水曜日

ドラゴンクエストウォーク、バイキルトなしロマン砲

ドラゴンクエストウォーク、バイキルトなしロマン砲

やり方忘れないようにメモ
将来的にはもっとお手軽にできるワンパンが登場するでしょう

動画

最後に守り人が混乱して「おうえん」を打ててないですが 50 万以上のダメージが出ているので「おうえん」があれば 70 万以上も期待できると思います

ポイント

最終的にはニンジャが以下のようになっていればOKです

  • 攻撃二段階アップ
  • 超きあいため
  • 会心必中 (クシャラミ共有)
  • おうえん
  • 威圧強三段階

この状態で大海の浪漫を打つだけです

期待ダメージ

直撃が来るか来ないかは運次第ですが40万から70万くらいまでのダメージは期待できます

超越の闘志などバフ/デバフの盛り方によってはもっと期待できると思います

流れ詳細

1ターン目

  • ニンジャ -> 超越 or ひかりのたま or ルカニ
  • 天地雷鳴士 -> ルカニ
  • 大神官 -> アンコール -> 守り人 -> バイシオンをニンジャ or 心配なら先にまもりのため
  • 守り人 -> バイシオンをニンジャ or 心配なら先にまもりのため

2ターン目

  • ニンジャ -> 鬼殺し
  • 天地雷鳴士 -> まもりのたて or メタルキングガード
  • 大神官 -> 回復 or まもりのたて or バイシオンまだならここで
  • 守り人 -> まもりのたて or バイシオンまだならここで

3ターン目

  • ニンジャ -> 超気合ため
  • 天地雷鳴士 -> クシャラミをニンジャ
  • 大神官 -> アンコール -> 天地雷鳴士 -> メタル超会心
  • 守り人 -> おうえん

4ターン目

  • ニンジャ -> 大海の浪漫

2ターン目は割と自由に動けるので1ターン目のダメージ具合に応じて臨機応変に対応してください

パーティ詳細

武器/防具

必須なのは

  • ニンジャ -> 銀河の剣
  • 天地雷鳴士 -> メタルキングの剣

です
他2名はバイキルトやラッキータロットを持っていれば絶対そっちのほうがいいです
タンバリン or 円月輪があればそちらのほうがダメージを伸ばせます

防具とこころはアタッカーのニンジャ意外、基本的に耐性盛りで OK です
ニンジャはダメージ覚悟でいきます

今回紹介している動画はりゅうおうなのでりゅうおう耐性のある武器を多めに入れていますがこのあたりは対戦するメガモンに合わせて属性なり変更してください

守り人

天地雷鳴士

大神官

ニンジャ

こころ

必須なのは

  • 天地雷鳴士 -> ルカニが使えるこころ
  • ニンジャ -> 大海の浪漫のダメージが上がるこころ

あたりです

こちらも基本的にはアタッカーはダメージよりでそれ以外の3名は耐性よりにすれば OK です

メガモンに合わせて属性などを変更しましょう

守り人

天地雷鳴士

守り人

ニンジャ

最後に

ぷにぷに肉球ロッド or しんぴの水晶がもっと楽に立ち回れると思います
自分はもっていないのでバイシオン + アンコールで代用している感じです

ボクはまだドラゴンクエストウォークをやっています

2024年9月26日木曜日

ヒゲの脱毛をしました

ヒゲの脱毛をしました

毎週剃るのが面倒なので
そしてたけー

どこで

  • ゴリラクリニック

料金

  • 合計 59,800円

内訳

  • ヒゲ3部位6回 39,800円
  • 麻酔6回 20,000円
  • その他交通費 2,400円

本当はヒゲ3部位3回というのが16,800円だったのでそれにしようと思ったのですが麻酔が使えないので泣く泣く6回にしました

施術期間

  • 1回目 -> 2024/01/24
  • 2回目 -> 2024/03/15
  • 3回目 -> 2024/05/08
  • 4回目 -> 2024/06/20
  • 5回目 -> 2024/08/01
  • 6回目 -> 2024/09/12

ゴリラクリニックでは最低でも6週間開けないとダメなようです

施術について

  • マシンが2種類があるがどっちも結構痛い
  • 麻酔しないともっと痛いらしいが麻酔しててもいたい
  • 施術時はアイマスクして笑気麻酔してあとは機械を当てるだけ
  • 初回はカウンセリングもあるので1時間から2時間ほどかかる
  • 2回目以降は施術だけなので30分程度で終了

効果

1回目

  • 一回目ではそれほど効果は見えず
  • 施術後はヒゲは一度もそらずに放置
  • 10日目から洗顔時に少量のヒゲが手のひらにポロポロと付き始める
  • 特によく取れたのは顎下で顎髭は全然ポロポロ落ちなかった
  • ただ軽く触ってくらいでは全然ポロポロとは落ちない
  • 施術後から18日伸ばし続けた感じは以下の通り (あまりひげの量は変わらない)

2回目

  • レーザーをYAGレーザーに変更した
  • 二回目でもそれほど効果は見えず
  • 施術後はヒゲは一度もそらずに放置
  • 10日くらいから濃いヒゲ部分にもポロポロがきた
  • 施術後から14日伸ばし続けた感じは以下の通り (伸ばした期間が前より短いのでちょっと薄くなった気はする)

3回目

  • YAGレーザー
  • 今回から YAG レーザーのタイプが変わったらしい、強度も一段階アップ
  • 施術後から14日伸ばし続けた感じは以下の通り (伸ばした期間が前より短いのでちょっと薄くなった気はする)
  • このあたりで気付いたが自分のポロポロ期は9日から12日くらいピークらしい
  • あんまり2回目と変わっていない

4回目

  • YAGレーザー
  • 施術後から14日伸ばし続けた感じは以下の通り
  • ポロポロ期は9日から12日
  • ただ鼻下は全く抜けずに顎下だけ抜けた、鼻下は抜けづらいのだろうか
  • このあたりで気付いたがポロポロ取れる髭はある一定の長さより伸びない
  • 今回は結構無理に抜いたのもありキレイに見えてしまう

5回目

  • YAGレーザー
  • 4回目と同じ感想
  • 1回目から見比べると確かに効果がありそうな感じはある

6回目

  • YAGレーザー
  • 適当に手動で抜いてます

やり取りや予約について

  • 意外とアナログで電話や紙ベースでのやり取りがメイン
  • 初診時に契約書を書かされるが全部紙
  • 予約やキャンセルも基本電話、次回予約は施術後にも可能なので基本は施術後に次回予約もしたほうが楽
  • 初回の申し込みだけ Web から
  • アカウント登録などしないのでログインして履歴確認とかができない

感想

6回やって約半年から1年ほど通いました
おそらく効果はあったんだと思いたいです
ただ完全に生えないわけではないので結局ひげ剃りは続けなければダメなようです

たまにはこんな感じで自分に投資するのもいいのかもしれません

もし続きをやったら別記事で記録しようと思います

2024年9月19日木曜日

クレーンゲームおじさん

クレーンゲームおじさん

ギャンブルに通づるおもしろさがある (自論
お金があれば確かに何でも取れるかもしれないがご利用は計画的に

使用した金額と獲得した景品数

  • 金額 -> 81500円
  • 景品数 -> 137個
  • 単価 -> 594.9円

景品数のカウントは大きなぬいぐるみやフィギュアから小さなぬいぐるみ、お菓子までいろいろあり、どんな景品でも1つとしてカウント (100円で複数取れるお菓子は1つとしてカウント)

ゆえに1つの景品に3000円くらいかかったこともあり (さすがに3000円以上を1つの景品に使ったことはない)

獲得した景品の一部紹介

クレーンをやるにあたって大事なことを先に

取れる台を見極める力が一番大事

  • この景品とこの台の設定なら取れそうだと見極められるか
  • 見極められるかは正直「経験」しかない
  • 取れない台はいつまでたっても取れない
  • 厳密に言うと確率が来るまで取れない (確率が来ても取れないこともあるようだが)
  • 取れないときにどうするか考えることが大事
    • 撤退 or 意地になって続けるか
    • 店員さんに相談するか (初期位置、状況説明など
    • ほしい景品が他の店にもあるならそっちで取る
    • どうしてもほしいなら買う
  • お試しに一回プレイするのは大事
    • アームの開き、強さ、押しの強さ、ねじれ、移動制限、下降制限の確認
    • 以下に記載のお店の傾向を掴む
  • 新景品はとりづらい (お金が必要になる)
  • 処分台を見極める

お店の傾向を掴む

  • 設置してある台の傾向 (橋渡しなのか末広なのかペラ輪なのかベタ棒なのかBリングなのかなど
    • 同一の景品でも別設定で置いている場合がある
    • どっちがより取りやすいかの判断
  • 三停止が使えるか
  • 全体的なアームの強さ
  • シールドの高さ、配置
  • 確率以外で取れそうか
  • ハウスルール
    • 平行移動
    • 初期位置
    • ゲット判定

店員さんを使う

  • 使いすぎ注意
  • 初期位置にしたいときは遠慮せずに使う
  • 平行移動ができればしてもらう
  • B リング系などでアームが入らない状態になったらリングをまっすぐにしてもらうとかできるお店ならやってもらう
  • アシストは期待しないこと (アシストランプが付けば別

筐体のクセや特徴を掴む

  • クレナは押しが強い (ときが多い
  • UFOキャッチャーシリーズはどっちかにねじれる (ときが多い
  • トリプルクレーンはぐるぐるが使える (ときが多い
  • グリーンランプがある
  • 三停止が使える

などなど筐体によって特徴があるのである程度把握しておくと良い

学習する

  • Youtube に腐る程クレーンゲーム実況者の動画があるので見て学ぶ
  • 台の種類や特徴、確率機かどうかなど (正確な情報はお店しかわからないので傾向や特徴を掴む)
  • 景品に対する取り方 (技) を覚える
    • 例えば箱なら「タテハメ」「ヨコハメ」など
    • ぬいぐるみなら「寄せ」「タグ」など

景品タイプごとの自分なりのポイント

ぬいぐるみ

  • させるところがとにかくひたすらあればさす
  • タグや紐、縫い付けてある腕の隙間や洋服の隙間など
  • 自力で取れないケースが多い
    • 3本詰め + ツルツル系 (引っ掛けるところがない) ぬいぐるみ
    • タグや紐がゴムなどで止めてある
  • 長いぬいぐるみはどちらからを寄せて来てシールドにかけて落とす
  • 寄せてシールドに乗ったら逆を上げて落とす、そのときできれば重いほうがシールドに乗っているほうがいい
  • 3本爪のぐるぐるアタックは有効ではあるが正直使えないケースが多いのと普通にやったほうが取れるケースもあるので自分はあまり使用しない
  • ぐるぐるは縦でやるほうがいい
  • ぬいぐるみのBCは基本ないが取れちゃうケースもあるのでトライする価値はあり

  • たてはめ、よこはめ
  • 回してはめる、はずしてはめる
  • 奥のバーに滑り止めがない場合はずりあげ
  • お菓子の丸い箱同士が重なっているやつは常に同じ側のアームで低くなったところはつかずに高いところをつく

好きな筐体

基本的には自力ゲット (作業ゲー) できる台は全部好きです

アラカルト

  • タイミングゲー
  • 取りたい景品の位置によってアームの下げ幅が違うことがあるので注意
    • 例えばポチが長いところがアームもいっぱい下がるがポチが初めから短いところはアームも下がらないなど
  • アームの上下左右スピードは筐体依存ではなくお店の設定依存なのでプレイして確認する必要がある
  • アームが下がりきったあとで景品に引っかからないようにアームが少し上がる場合がある (たぶん設定?
  • タイミングさえ掴めば再現性でガンガン取れる
  • 上下のコツは目線を景品の高さに合わせブラさないこと
  • 上に上がってくるアームと景品は必ずどちらも視界に入るようにする (少し斜めから見るといい)
  • 一番下の段などは膝をついて目線をぶらさないのもあり
  • 左右のコツは景品のポチ部分を正面から見ること
  • 左右の場合は爪がポチに入るイメージをすることが大事
  • 上下も左右も景品とアームが近ければ近いほど簡単なので景品が移動できるならアームの近くにおいてもらうこと

ボール転がし

  • 最初はどちらかのアームで寄せて転がす
  • アームで転がせなくなったら逆アームでボールを頂点付きして落とす
  • 最初の段階でボールが転がらない、動きが弱い場合
    • あっさり撤退
    • 寄せ方をもう少し変える (寄せ甘めのほうが動く場合もあり
    • バーと干渉させるようにアームを入れる
  • ボール転がしにおけるバー干渉は結構重要で最後の押しのときもアームをバー干渉させて強制的にボールを動かすことで取れることがある
  • ボール転がしは基本的に大きめの景品が入ることがあるので通常の設定で取れないがボール転がしで同じ景品がある場合はボール転がしのほうが安く取れることがある

Bリング

  • 初期からだとかなり手数を要するケースが多いので注意
  • 基本はアームギリ寄せを攻め続ければなんとかなる
  • できればリングの外側にアームを落とす
  • 交互にやっていけば OK だが場合によっては片側を集中的に攻めるのも OK
  • 両アームあるのであれば逆側のアームで直接 B リングの頂点を突くのも有効
  • ベタ棒、ベタボールのケースがあるがどっちも同じ印象
  • ボール転がし同様 B リングにほしい景品がある場合は B リングを選択するのもあり

わりと取りやすいと感じた筐体

ミニクレーン全般 (ジェミニなど

  • ミニクレーンは普通の筐体に比べて天井が低め(約1000円) なので天井意識もかなり大事
    • もちろんミニでも最新の景品などはもっと天井が高いことは余裕であるので注意
  • 三停止があるかないかが重要、ないと自力はほぼ厳しいかも、ひっかけられるところがあれば別
  • ゴム爪があるかどうかも重要
  • ぐるぐるは使ってもいいが自分はミニクレーンはほとんどぐるぐるは使わない

ゲッタースピン

  • 目印とタイミングを決めてそこから調整
  • 押せなくても引っかかった反動で落ちることもある
  • 基本お菓子
  • お菓子がモリモリに持ってあるほうがいい
  • 2段が基本だが3段あるとより取れる

地雷だった組み合わせ

  • つるつる系景品全般
  • おかし+ベタ棒
  • 橋渡し+ひし形置きおお菓子
    • 下カド取れればワンチャンだがそれなら素直にまっすぐ置きの橋渡しで BC を狙うほうがいい

最後に

自分はほしい景品を取りにクレーンはしていないので景品は何でもとります
その中でもぬいぐるみが一番多いかもです

10万円分くらい練習するばたぶん取りたい景品で取れない景品がなくなるくらいの実力にはなるかなと思います

クレーンの前では熱くなりがちですが心は常に冷静でいましょう

2024年9月7日土曜日

王様の腰掛けビーズ補充メモ

王様の腰掛けビーズ補充メモ

補充したビーズ

Out Style 補充用ビーズ クッション 日本製 (1個, 1ミリ 400g)

1ミリ ビーズなら何でも OK だと思います
400g がおすすめです
それ以上だと1回ですべて使い切るのは難しく保管するのも面倒なためです

人数

  • 2人以上
    • 3人でやるとだいぶ安定すると思います

道具

  • トイレットペーパーの芯
  • テープ
  • はさみ or 糸切りバサミ
  • 裁縫道具 or ミシン

流れ

  1. 補充用ビーズの投入口をカット
  2. 投入口にトイレットペーパーの芯を挿す
  3. 王様の腰掛けの投入口の紐をほどく
  • 初回はかなり細かく縫われているのでほどくのが大変
  • 糸切りバサミで開きながら切っていくのが良い
  1. 補充用ビーズに挿したトイレットペーパーの芯と王様の腰掛けの腰掛けの投入口を合体
  • 王様の腰掛け側の補充口はトイレットペーパーの芯のサイズギリギリなので開きながらいれる
  1. 双方のトイレットペーパー芯が外れないように抑えながらビーズ補充
  2. すべての補充が完了したら王様の腰掛け側の投入口を裁縫する
  • かなり細かく縫わないとビーズが出てくるので注意
  • 一列ではなく複数列縫うのもよし
  • ミシンがあると尚良し

ポイント

  • 補充用ビーズ内にあるビーズを一つ残らず補充するのは不可能なのである程度補充できたらあきらめる
  • 全くビーズがこぼれないで補充するのは不可能なので多少ビーズで汚れるのは諦める

補充間隔

  • 完全に感覚ですが2年に1回400gを補充するといい感じかなと思います

2024年6月26日水曜日

mlx-examples の LoRA を使って kakakikikeke っぽいツイートを自動生成してみた

mlx-examples の LoRA を使って kakakikikeke っぽいツイートを自動生成してみた

画像生成は stable-diffusion を使いました
音声生成は RVC を使いました
今回は文章生成をします

環境

  • macOS 14.5
  • Python 3.10.12
  • mlx-examples 69700d84

学習データの作成

Twitter のアーカイブデータを使います
アーカイブデータ内に tweets.js というツイートを管理しているファイルがあるのでそこから学習データとテストデータと評価データを作成します

学習させるツイートの元では 3 万件ほどありますが全部は学習させません
本当は全部学習させたいのですがマシンのスペックも考慮して 1300 件にしています
テストと評価データはそれぞれ 100 件ずつです

wc -l my_tweet/*
     100 my_tweet/test.jsonl
    1100 my_tweet/train.jsonl
     100 my_tweet/valid.jsonl
    1300 total

このデータセットの量でだいたい 1 時間ほどで LoRA を生成できるので 3 万件学習させても 4 日ほどあれば終わるかもしれません

学習データ作成スクリプト

以下 tweets.js を解析して学習データを作成するための Python スクリプトです
pandas と scikit-learn が必要になります
json ファイルを解析するだけなので pandas も scikit-learn もなしで解析することもできます

import json
from io import StringIO

import pandas as pd
from sklearn.model_selection import train_test_split

# tweets.js を読み込んでツイート情報を辞書に変換
tweets = []
with open("./tweets.js", mode="r") as f:
    for tweet in json.loads(f.read().replace("window.YTD.tweets.part0 = ", "")):
        t = {
            "full_text": tweet["tweet"]["full_text"],
            "created_at": tweet["tweet"]["created_at"],
        }
        tweets.append(t)

# JSONデータをPandas DataFrameに読み込む
df = pd.read_json(StringIO(json.dumps(tweets)))
pd.set_option("display.max_colwidth", 1000)
pd.set_option("display.max_rows", 1000)

# リンクを含むツイートは削除
df = df[~df["full_text"].str.contains("https://")]

print(df.head(100))

# テキスト長が短い学習データTOP1300をデータセットとして扱う
# 学習に時間がかかる場合もしくはメモリを使いすぎる場合は ascending=True にして短い順にするか 1300 の数を小さくすること
df["length"] = df.full_text.str.len()
df = df.sort_values(by="length", ascending=False)
df = df.head(1300)
print(len(df.index))

# データフレームをシャッフル
df = df.sample(frac=1).reset_index(drop=True)

# validとtest用のデータを100件ずつ取り出し、残りをtrainに分割
valid_df, remaining_df = train_test_split(df, test_size=len(df) - 100, random_state=42)
test_df, train_df = train_test_split(
    remaining_df, test_size=len(remaining_df) - 100, random_state=42
)


# ヘルパー関数:データフレームを新しい形式でJSON Linesファイルに変換
def df_to_jsonl(df, file_name):
    with open(file_name, "w", encoding="utf-8") as file:
        for _, row in df.iterrows():
            formatted_data = {"text": f"USER:ツイートして ASSISTANT:{row['full_text']}"}
            file.write(json.dumps(formatted_data, ensure_ascii=False) + "\n")


# 各データセットを対応するJSON Linesファイルに変換
df_to_jsonl(train_df, "./train.jsonl")
df_to_jsonl(valid_df, "./valid.jsonl")
df_to_jsonl(test_df, "./test.jsonl")

最終的には3つのファイルが作成できればいいので解析方法はおまかせします

ベースモデル

学習させるデータが日本語なのでベースモデルも日本語に特化したものを使ったほうがいいです
今回は https://huggingface.co/4bit/ELYZA-japanese-Llama-2-7b-instruct を使いました
また mlx は専用のフォーマットにモデルをコンバートする必要があるのでモデルをダウンロードしたら mlx-examples に含まれる convert.py を使って変換します

  • cd mlx-examples/lora
  • python convert.py --hf-path 4bit/ELYZA-japanese-Llama-2-7b-instruct -q --q-bits 4

コンバートしたモデルは mlx_model 配下に生成されます

学習

生成した学習データと変換した ELYZA のベースモデルを使って LoRA アダプタを生成します

  • python lora.py --model mlx_model --data my_tweet --train --iters 600

反復数も学習時間に影響するためあまり大きくすると学習時間が増えるので注意してください
600 回と 1300 件の学習データで約 1 時間で終了しました

推論

あとはテストします

  • python lora.py --model mlx_model --adapter-file adapters.npz --prompt "USER:ツイートして ASSISTANT:"
Loading pretrained model
Total parameters 1055.199M
Trainable parameters 2.097M
Loading datasets
Generating
USER:ツイートして ASSISTANT:iot_device には iot_device って何だよ、デバイス�も実装したいというときはどうすればいんだろうか。ま�、ros bond とかと同じ�じかな、デバイスに�する
  定を管理するクラスを作るだけだよな

何度か生成してみます

Loading pretrained model
Total parameters 1055.199M
Trainable parameters 2.097M
Loading datasets
Generating
USER:ツイートして ASSISTANT:10.5 10.6 10.7 、、、、10.9 10.10 10.11 を使うために 10 にしてるのか。ios の場合は 10.12 とかだからちゃんとやってるな、という�じ
==========
Loading pretrained model
Total parameters 1055.199M
Trainable parameters 2.097M
Loading datasets
Generating
USER:ツイートして ASSISTANT:airplay の機�ってどこの�品があるんだろうか。これから発表していくためにはコンテナに入れておかないとダメなのだろうか。����も����も結果は同じという
  とを�り返していく
==========
Loading pretrained model
Total parameters 1055.199M
Trainable parameters 2.097M
Loading datasets
Generating
USER:ツイートして ASSISTANT:その google colaboratory だとあるスクリプトをコードで����すか、、、コードの�分ってやつですが、、、そのためにコードの変更�所を����のがいいんだけ
  そのためにもしくは使えるのが
==========

この文字化けは何とかならないのだろうか、、

おまけ: 文字化け対策

てっとり早く対応する場合は生成されたいろいろ弄る前のトークンを最後に print すれば OK です

git diff
diff --git a/lora/lora.py b/lora/lora.py
index a90eda7..411f558 100644
--- a/lora/lora.py
+++ b/lora/lora.py
@@ -312,6 +312,7 @@ def generate(model, prompt, tokenizer, args):
             skip = len(s) - 1
     print(tokenizer.decode(tokens)[skip:], flush=True)
     print("=" * 10)
+    print(f"{s} \n\n")
     if len(tokens) == 0:
         print("No tokens generated for this prompt")
         return

文字化け対策して10個生成してみました

結局その一緒に遊ぶやつとセットにしないとダメなんですか。通信量かかりますが gps ロガーつけている状態じゃないとダメなんですか。そういうわけだからバックグラウンドでおいておいておけばいくらか 

customerservice ルートにログインしたときに dns コマンドによってクラスタの dns サービスを停止していたため、ルートからクラスタにリクエストが行けなくなっていたようだな。対応はわかっているけど now  

docker-compose 使うときは pod とか swarm とかクラスタとか pod とか svc とか nil じゃないという感じのものを指定しないといけないんだけどなー、、、どうすればいいかなー、、、なんかいなくてないのだろうか、、、 

docker-compose の場合、ローカルの machine 名の前に 0 をつけてくればどこでもインストールできるようになったのかな、、docker の proxyswarm とかはプロキシの指定が必要とか面倒だからなー。salt の場合のマシン名でコ 

docker-compose とか YouTube とかで配布するのに役立っているのがコンテナってやつとかパブリッシュなのにコンテナが必要だとか結構あるのかな、コンテナのためのコンテナってのがあるけどどういうことなんだろう 

自前の処理って製品の説明書?移行前のデータをどこまでコピーするのかとかは援助しないかな。そういう時には「自前の処理」という概念がないから。そもそも仕様がわからんわけ 

ブログから個人サイトのための micro-flutter を作るってなると github を使ってできない理由はないだろうけど、blog を用意するとなってみんなが悩むのは同じで、その問題を解決するためにサービスがいくつ 

windows 折りたたみ式のマウスって結局何がいいんだろうか。マウスとして普通の押し出し式のもがいいから私が把持って操作したい、そして折りたたんで持ち歩きたいっていうのが気持ちだった 

確かに android 12 が 2020 年 9 月というのはかなり早い感じ。アップグレードのスケジュールはかなりの傾向があるような気がする。だけどいろいろと理由はあるんだろうか。最終的には google 

iPhone の時のプライスタグが貼り付けできないのか、実は AppStore のプライスタグが使えないのか。 tinder は使っているのにおかしい、とか思う人は apple の審査厨になっているから 

考察: 学習させるデータの修正

今回は「ツイートして」という質問に対して適当にサンプルしたツイートを学習させています
コンテキストも何もない状態の質問なので本当にランダムなツイートを生成してしまいます

ツイートする場合には本来ある程度のコンテキストが含まれていることがあり例えば梅雨の時期だったら雨に関するツイートをしたりだとか WWDC が Google I/O が開催される時期なので Apple や Google に関するツイートをしたりします
なので学習させるデータの質問にコンテキストを持たせることができれば特定の事柄や事象、特定の言葉を含んだツイートを生成することができます

単純に「ツイートして」という質問を学習させるのではなく「6月の雨に関するツイートをして」という感じで質問をカスタムできれば生成する際にも6月の雨に関するツイートを生成することができます
実際に生成する際の質問も「ツイートして」だけではなくテンプレートなどを使って「X月のYYYに関するツイートをして」という感じで自動で X, Y を埋めるようにすればコンテキストを持たせた文章を生成することができると思います

時期に関しては tweets.js に含まれているので簡単に学習データに含ませることができそうですが「YYY に関する」の部分はそう簡単にはいきません
例えばツイート情報を形態素解析してもっとも頻出している単語を YYY に設定することができそうですがそれだけだと正確なコンテキスト情報としては少し甘い気がします
ツイートに「Apple」や「Google」など特定の単語が含まれていれば問題ないですがそうでないツイートもたくさんあり単純のカウントではダメなケースがあります
なのでちゃんとやるのであれば例えばツイートの種類のようなものを判定する必要があるかなと思っており例えば「こんにちわ」や「ねる」「はぁー」みたいな文章ではなく短い単語のみのツイートはコンテキストなしという分類にし特定のコンテキストなり得る単語を含むツイートはコンテキストありとしてその場合は形態素解析を使ってそのツイート内に出現する特徴語を抽出してそれを「YYYに関する」の部分に設定すればそれっぽいコンテキストにはなるかなと思います

このあたりはツイートの自動タグ付けやネガポジ判定のような世界になってくるので論文を漁れば手法は死ぬほど出てくると思います

という感じで学習させるデータをもう少し工夫できれば完全ランダムなツイートしか生成しない問題を解決できるかなと思っています

最後に

まだまだ改善の余地はありそうですが自分っぽいツイートをする流れはだいたい把握できました
あとは学習データを修正したり生成時のプロンプトを変更すればもっと自然なツイートになるかなと思います

これまで画像、音声とやってきましたが文章生成が一番たいへんなイメージです
「自然な」日本語にするのがすごい難しいです