ボードゲーム『バラージ』完走。(そして感想)

2019年の12月に購入したボードゲーム『バラージ』。ようやく崩す機会に恵まれました。(導入ルールのみ)

資源管理に加えて時間も管理。強烈なインタラクションと(ほぼ)アブストラクトがもたらすシビアなゲーム展開にシビれました。

ゲーム概要

舞台は20世紀初頭、水力発電が異様に発達したif世界のヨーロッパ(とアメリカ)。

プレイヤーは国を代表する電力会社のCEOとなってアルプスの一地域に

  • ダムを建て
  • 発電設備を敷設して

電力を生み出していきます。所定量の電力を生み出すことによって契約を履行すれば企業に更なる繁栄をもたらしてくれるでしょう。

しかし、繁栄を目指すのはあなただけではありません。

  • 限られた土地
  • 限られた資源
  • 限られた人員

を対処していき、誰が最も電力を生み出すことができるでしょうか?

ゲームシステム

基本はワーカープレースメントになっています。

ワーカープレースメント特有のアクションスペースの奪い合いがあるものの、
追加のワーカーやクレジットを支払うことで同じスペースを利用できる分、ブロックされる可能性は減ります。

もう一つの特徴は、建築がロンデルシステムとなっていること。

  1. 建築のアクションスペース(個人ボード)にワーカーを配置
  2. 必要な作業機器と作業タイルをホイール(ロンデル)に投入
  3. 一メモリずらして所定箇所に建築
  4. メモリが一回転すれば投入したタイルと機器は返ってくる

これによって、一部の施設を延々と建てることを防ぐと共に、どうやって機器を“回転”させるかの時間管理も必要になってきます。

ゲームで思ったこと

この段階で述べますが、重ゲームだけあって人を選びます。

電力を生み出すまでの手間と達成感

  1. 自分/中立のダム-任意の導管-自分の発電所が全て繋がっていること
  2. ダムに水が蓄えられていること

が前提条件。上記のロンデルによってこれらを敷設するための資源管理がシビア。それだけに、一度でも発電できたときの喜びは得難いものがあります。

その上、一度敷設してしまえば(水の横取りがない限り)再度繰り返し使えます。この、得点源のエンジンビルドが本ゲームの醍醐味です。

運がほぼ絡まない完全実力ゲーム

運が絡む部分は(導入ルールでは)契約タイルのめくれ具合のみ。上級ルールでも特許タイルが加わる程度です。

そのため、プレイヤーには戦略と立ち回りが求められます。先の電力を生み出すことの達成感は、この戦略が成ってこそ得られるので、最初から最後まで思考回路は発電所のタービンのようにフル回転です。

没入感と戦略性

メインボードに存在するのは

  • ダム
  • 導管
  • 発電所

と非常にイメージしやすいため、箱庭感が満載です。上記も国によって形状や色が異なるので「ここはこの国の支配地域である」というのも一瞥しやすくなっています。

契約履行の条件も「電力をどれだけ生み出せるか」とシンプルなので、いかにして生産効率を上げていくかに集中できます。

それ故に「他の国と喧嘩して水利を得るか」「自分だけが得をするにはどこに陣取るか」などの戦略性も問われます。もちろん、ワーカープレースメント特有のアクションスペースの奪い合いも絡みます。

まとめ

  • 膨大なコンポーネント
  • それらを展開するための広大なスペース
  • 長大なインストとプレイ時間

はいずれもユーロゲームの骨頂という形。プレイヤーの強さの差がそのまま得点差として現れるため、断じて万人向けではありません。

とはいえ:洗練されたルールや良質なコンポーネントがもたらすプレイ体験は確かな満足感でした。

本項を執筆時点では一回のみのプレイとはいえ、既に「次はどの国を使おうか」「どうすればうまくインストできるか?」「三人以上だとどういうプレイ感になるのか?」などの思考で満たされています。

個人的に、この手のゲームにしては管理する資源がスッキリとまとまっているのも好感度です。

縦の背景、横の背景。

こちらの生地で作った背景の使い方、視点を変えました。

普通に、背景として使うのはもちろんですが、構造上、立体感のある背景。

「寝かせてみても面白いのでは」と思っての検証です。

結果はこの通り。トレリスの厚みがそのまま座らせる際の台として機能。figmaサイズだったらちょうど椅子として機能します。

また、ねんどろいどの場合もうまく背後の支柱を隠す形になりました。

「視点を変える」だけではなく「他の向きでも試す」も今後の選択肢となりました。

Mod_Securityが検知したIPアドレスの自動遮断スクリプト・修正。

以下のスクリプトを修正しました。

このスクリプトの主な動き

  1. Mod_Securityが検知したエラーログからIPアドレスのみを抜き出す。
  2. 重複を排除した上でsuscpicious_ip.YYYYMMDD形式で保存。
  3. 全てのsuscpicious_ip.YYYYMMDDを統合する。
  4. ここからnegativelist.txtを作成する。
  5. negativelist.txtの中に疑陽性(自身のアクセス元)のIPを排除する。
  6. Webサービスを再起動する。

そうして、「一度でもMod_Securityが疑わしいと検知すれば、次回以降のアクセスを許さない」という、言わば“ONE OUTS”システムを採用しています。

この可読性を高めました。

スクリプトが動く前提

  • ApacheとMod_Securityを運用している。
  • 以下のように、「negativelist.txt」に記録されたIP全てをブロックするようにしている。

apacheバーチャルサイト設定の抜粋

# Mod Security
SecRuleEngine On
## ModSecurity有効化
SecRequestBodyInMemoryLimit 524288000
SecRequestBodyLimit 524288000
## ファイルのアップロードをできるようにします。
    # ネガティブリスト
    SecRule REMOTE_ADDR "@pmFromFile negativelist.txt" "phase:1,id:2,deny,msg:'Negativelisted IP address'"

修正したスクリプト

※ 教義・信仰に沿ったエディタで記載します。

  • negativelist.sh
#!/bin/bash
# このシェルスクリプトは、変数で定義したエラーログからIPアドレスを抽出し、
# suspicious_ipディレクトリに保存し、その後、特定のIPアドレスを削除して
# /etc/apache2/sites-available/negativelist.txtに書き込むものです。

# 読み込むログのディレクトリとファイル名を変数指定
log_dir="/var/lib/redmine/log"
log_file="error.log"

# 除外するIPアドレスをファイルで指定
exclude_ips_file="/path/to/exclude_ips.txt"

# IPアドレスを抽出して重複を排除し、ファイルに保存
cd "$log_dir"
awk 'match($0,/[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+/) { print substr($0, RSTART, RLENGTH) }' "$log_file" | sort | uniq > "$log_dir/suspicious_ip/suspicious_ip.$(date +%Y%m%d)"
chown www-data:www-data "$log_dir/suspicious_ip/suspicious_ip.$(date +%Y%m%d)"

# 過去のIPアドレスを読み込んで重複を排除し、ファイルに保存
cat "$log_dir/suspicious_ip/suspicious_ip."2* | sort | uniq > "$log_dir/suspicious_ip_all.txt"
chown www-data:www-data "$log_dir/suspicious_ip_all.txt"

# 新たにリストに書き起こす
cat "$log_dir/suspicious_ip_all.txt" > /etc/apache2/sites-available/negativelist.txt

# 除外するIPアドレスをファイルから削除
while IFS= read -r exclude_ip; do
  sed -i "/$exclude_ip/d" /etc/apache2/sites-available/negativelist.txt
done < "$exclude_ips_file"

# Apacheを再起動
systemctl restart apache2.service
  • 除外するIPアドレスリスト

※ 教義・信仰に沿ったエディタで作成します。

  • exclude_ips.txt 記載例
192.168.0.1
172.28.0.1
# 一行ずつ記載

記載後の設定

  • スクリプトの所有者変更
sudo chown root:root negativelist.sh
  • スクリプトの実行権付与
sudo chmod 744 negativelist.sh
  • cron登録
sudo crontab -e -u root
  • cron内容
0 6 * * * /home/manualmaton/bin/negativelist.sh

これによって、スクリプトを変数化。他のサーバへの転用を行いやすくしました。

氷水で出す紅茶/緑茶。

蒸し暑くなってきたことで、この出番が増えました。

普段から飲んでいるお茶はコクよりも喉ごしを重要視しています。
そんな自分に合っていて、今の季節にも合う入れ方が「お茶の氷水出し」です。

用意するもの

  • 茶葉
  • たっぷり入るティーポット

手順

茶葉を少なめに入れます。

よく洗って乾かしたティーポットに茶葉を入れます。

後述する理由により茶こしは使わずに直接。後で漉すのが嫌な方はお茶バッグに入れておきます。

量は少なめ。お湯で入れる場合の半分(あるいは1/3ぐらい)が適当でした。特にダージリンや緑茶などは多く入れすぎると渋みが出ます。

ティーポットに氷をぶち込みます。

山ほど入れていきましょう。この手順があるため、ポット備え付けの茶こしは使いません。

水を注ぎます。

ティーポットの隙間を埋めるように注いでいきます。

冷蔵庫に入れて一晩ほど待ちます。

氷が溶けきらない等の場合は調整してください。

完成

(こちらはダージリンとフレーバーティーを合わせたものです)

一晩置くとこのようになります。氷やシロップなどを入れてグラスに注ぎます。

お湯で入れるお茶と違ってタンニンやカフェインが抽出しにくい代わりに甘みと喉ごしにステータスを振った飲み物となります。

備考

  • 茶葉はできる限り新しいものを用います。
  • 早めに飲みきってください。(熱湯で抽出していないため消費期限は極めて短いです)
  • 緑茶の場合は茶葉が更に少なく、抽出時間も短くなります。

スマートウォッチ、バンドの追加。

5月の連休最終日に購入したスマートウォッチ。

備え付けのシリコンバンドで蒸れてかぶれてしまうという問題点は替えのバンドで解決。懸念事項だった「かぶれ」も特に見られなかったので、先日、買い足しました。

最初に買った一本がボディの色に合わせた明るい緑だったので、今回は紺です。

購入したナイロンバンドがQuick Releaseに対応しているので、外すのはピンをずらすだけでした。

装着もその逆になります。

全体的な見た目なこの通り。明るい色から落ち着いた色へと変わります。

先日の東京都心でのサイクリングで、自転車でどの道をどれぐらい走ったかまで記録することも検証できたので、これはできる限り使っていこうと思います。

iPad miniカバー差し替え。

利用しているカバーがへたれてきたので、差し替えです。

左側が今まで使ってきたもの。周囲の塗装ははげてきており、折りたたみのスタンドもへたれるようになりました。

そこで、Amazonで適当なノーブランド品を注文。(右の画像)

縁が明るいラベンダー色。Apple Pencilも問題なく充電状態で収納可能です。

裏面はアクリル仕様となっていて、金属面の光沢がより映えるようになっていました。

数年ぶりの自転車輪行。

きっと5年とかそういうレベルです。

比較的天気が安定していた週末、ブロンプトンを携えて東京都内を走ってきました。

スタート地点はここ、レインボーブリッジの下。

最後にここを訪れたときと比べて

  • 全体的なオーバーホールを施され
  • ペダルのビンディングはなし。

というのが違い。また、輪行袋は納車時に一緒に片キャスター付きのものに回帰しています。

地味にサイクルスタンドもついているので、安定性は更に高くなりました。

途中で愛宕神社の坂を登り切ったり、

桜田門やら国会を通り抜けたり

久方ぶりに20kmは走った気がします。

Let’s Encryptの証明書をRSA方式で更新。

以前ご案内した、Let's Encryptのデフォルト暗号化形式がデフォルトでECDSA方式に変更されたという話。

ただ、サーバの環境によっては、この暗号化形式をサポートしていない事があります。(ワイルドカード証明書を様々なサーバに適用するケースでありがちです)
本来ならばサーバそのもののバージョンアップを図るべきでしょうが、運用によってはままならず。

そんなときにLet's Encryptの暗号化を従来のRSA方式に変える方法をメモしておきます。

前提

  • Let's EncryptでSSLを利用している。
  • 適用するサーバがECDSA方式の暗号化形式に対応していない。

作業手順

Let's Encrypt(Certbot)サーバで実施します。

ここでは、

  • hoge.example.com ドメインのワイルドカード証明書を取得し
  • 有効期限前にhoge@example.com宛にメールを送付する

として手順を示します。

証明書更新

sudo certbot certonly --manual -d\
*.hoge.example.com\
 -m hoge@example.com\
 --agree-tos --manual-public-ip-logging-ok\
 --key-type rsa --preferred-challenges dns-01
# ディレクトリやメールアドレスは自身の環境に合わせます。
# --key-type rsa を明示します

この後、DNSでTXTレコードを設定するよう求められるので、それに従いDNSの所有権を確認します。

確認されたら証明書は更新されます。

証明書と鍵の整合性確認

openssl x509 -pubkey -in /etc/letsencrypt/live/hoge.example.com/cert.pem -noout | openssl md5
(stdin)= ハッシュ値
# SSL証明書ファイル

openssl pkey -pubout -in /etc/letsencrypt/live/hoge.example.com/pprivkey.pem | openssl md5
(stdin)= ハッシュ値
# 秘密鍵ファイル

## Let's Encryptで指定されたディレクトリや証明書・秘密鍵を指定してください
## 2つのハッシュ値が合っていれば証明書と秘密鍵の整合性は取れています

証明書の鍵方式確認

openssl rsa -text -noout -in /etc/letsencrypt/live/hoge.example.com/pprivkey.pem
# 正常に表示されればRSA方式で暗号化されています

後は、指定したディレクトリの証明書や秘密鍵を適切に他サーバに適用します。

メモのテンプレ化。(メモポン導入)

付箋やメモ用紙を伝言メモなどに変える文具「メモポン」。そのガンダム版が出るというリリースを見たのが今年(2023年)1月の話。

それが先日、到着しました。

パッケージ外観&開封

パッケージとしてはこの形。一般的な付箋の大きさに合わせているだけあって、インパクトはかなりのものです。

外側の梱包を外していくと、広くて大きいスタンプが出てきました。

印影

インクは既に充填された状態なので、さっそく、手帳に押してみます。

インクの乗りは予想以上。スタンプと言うより「印刷」というのがイメージに近いです。

これだけの大きさの「許可」と「否」はプライベートで使うに留めておいたほうが賢明です。

使い勝手が高いのがハロのチェックリスト。これなら手帳でのToDoを瞬時に呼び出せるという形。

ここ数年「書く」「記録する」が完全に日課になったので、メモのテンプレを促進する道具はありがたいです。

Redmineの不正アクセス対策。(ufwと二段階認証)

概要

AWS Lightsailに構築しているRedmine。 不審なアクセスがあったので対応を行いました。

アクセスの内容

とてもシンプルに、チケットの新規発行画面に何回もアクセスしているというもの。

正規のリクエストなのでWAFでブロックされません。(解析システム:matomoで検知した次第です)

そもそも自分しかアカウントを用意していないため、この時点で不正アクセスの兆候だと判断。以下、対処を行います。

ufwでの処理

  • ufwによるブロック
sudo ufw deny from IPアドレス
# より確実を期すためにIPアドレスのネットワークアドレスを指定しました (xxx.xxx.xxx.0/24)
  • 設定確認
sudo ufw status numbered
# Anywhere DENY IN 上記で指定したIP/ネットワークアドレスを確認します
  • 設定反映
sudo ufw reload
# ファイアウォールを再読込しましたと出れば反映完了です

これでひとまず不審なアクセス元は遮断。

Redmineログイン強化

筆者が用いているRedmine4.2は二段階認証が標準で備わっていますので、それを有効化します。

  1. Redmineに管理者権限でログインします。
  2. 万一に備えて別のブラウザでもログインしっぱなしにします。
  3. 管理>設定>認証に移動します。
  4. 二段階認証を「必須」にして保存します。

その後、(別ブラウザでログインしたまま)Redmineにログイン。

後は二段階認証プロセス(Google認証システムを用いました)で指示に従ってQRコードを読み込み、生成されたコードを読み込むだけ。

ひとまず、これでID/PWによるログインに加えて認証システムの二段階で不正アクセスの被害を抑えます。

Page 76 of 246

Powered by WordPress & Theme by Anders Norén