  |
はてなキーワード: DEFとは
i'm so hesitate but I'm begging you please give me answer.
But, at least i have a thorn in my heart.
My doubt right now: Marwan is a person who does not keep own words, does not think that's a bad, does not mind making a friend cry with sadness.
Or Does Marwan like to harass me?
> so i will have time to reply to u
i guess, i misread English, and also your writings were incorrect.
Because we are not native English speaker.
My poor English brain read it like
"I won't be home « only » tmrw. So I « can » have time to reply to u (= My tomorrow is yours)".
But, did you write it with this meaning of ?
"I won't be home « from » tmrw. So I will « might » have time to reply to u."
But in the "tomorrow", you didn't that do.
I was deeply hurt by be broken promise.
I already told you, I cried for real.
自動で安価をつけて返信するプログラムでもこんなに長く複雑になる(一部抜粋)
/**************************************
以下のCSV_DIR, FILE_PATHS, SETTINGSを書き換えてね。 <h3>o- *************************************/</h3>
//CSVファイルが置かれてるディレクトリのパス。投稿前にエラー出たら大体ここの設定ミス。 例："C:\\Users\\sakuraimasahiro\\Documents\\iMacros\\Macros\\rentou\\";
'C:\\Users\\USER\\Desktop\\iMacros\\Macros\\rentou\\';
//ファイルのパス。CSVは絶対パスで、拡張子も必要。iimは相対パスでよく、拡張子不要。
const FILE_PATHS = {
textCsv: CSV_DIR + 'textNoAnker.csv',
//レス用投稿文が書かれたCSV。通常とレス用で分けないなら同じファイルを使えばいい。
replyTextCsv: CSV_DIR + 'textReply.csv',
};
baseWaitTime: 5,
//baseWaitTime+0～waitTimeRange（ランダム）だけ待つ
waitTimeRange: 5,
//連投しすぎだと忠告された場合に処理を一時停止させる時間(秒)
waitTimeForAvoidingPunishment: 60 * 30,
//メール
mail: 'sage',
//名前設定
name: '',
//以下、偽装ワッチョイ設定。浪人でワッチョイを非表示にしてるときだけtrueにしてね。
//妙なニックネーム（ﾜｯﾁｮｲ、ｱｳｱｳｳｰなど）をランダムで決めて付加するかどうか。true=付加する。false=付加しない。
//妙なニックネームの後に付く8桁の文字列をランダムで決めて付加するかどうか。
},
//アンカー無し投稿をするならtrue。しないならfalse。noAnkerPostかreplyPostのどちらかはtrueにすること（両方trueでもOK）。
//アンカー付き投稿（返信）をするならtrue。しないならfalse。もしnoAnkerPostとreplyPostの両方がtrueの場合、投稿は返信が優先され、返信対象が見つからなくなったらアンカー無し投稿をする。
//最初に取得するアンカー無し投稿文CSVファイルの行番号。もし返信用と同じCSVファイルを使うなら-1と入力。
noAnkerPostTextCsvStartRow: 1,
//最初に取得する返信用投稿文CSVファイルの行番号。もしアンカー無しと同じCSVファイルを使うなら-1と入力。
//テキストCSV/返信用テキストCSVの取得行が最終行に達したら最初の行まで戻るかどうか。true=戻る。false=マクロ終了。
//返信する場合、これより小さなレス番には返信しない。返信を投稿すると、この数値は前回の返信先のレス番に更新される。
minAnker: 895,
//返信する場合、名前に以下の文字列を含む投稿にアンカーをつけて返信する(ﾜｯﾁｮｲやIPなど名前フィールドにあるものならなんでも可)。配列で複数指定可能。指定無しなら空配列（[]）。filterNamesとfilterNamesNotIncluded共に無指定ならレス番1から順に返信していく（minAnkerが設定されてればそこから順に）。以下のfilter系は全て併用可能。
//↑とは逆に、名前に以下の文字列を含まない投稿にアンカーをつけて返信する。↑と併用も可能。
//返信する場合、本文に以下の文字列を含む投稿にアンカーをつけて返信する。
filterText: ['自演かな', '自演わらわら', 'スクリプト使うの', '安価ガバ', '>>660', '自演で擁護', '最後' ,'あいうえお', 'かきくけこ', 'さしすせそ', 'なにぬねの', 'はひふへほ', 'まみむめも', 'やいゆえよ', 'やゆよ', 'らりるれろ', 'わいうえを', 'わをん', 'わいうえをん'],
},
//自分のIPアドレスの確認。VPNとかでIPを変更してマクロを動かしてるとき、突然VPNが作動しなくなってIPが元に戻ったときにマクロを止めるためのもの。
//以下の文字列が自分の現在のIPアドレスに含まれている場合、マクロを一時停止する。基本的に自分の本当のIPアドレスを入力。
},
//浪人設定。最後に動作を確認したのは5年くらい前で、今も同じように動作するかは、浪人を持ってないから確認できずわからない。
//浪人にログインしてるかどうかをチェックするかどうか。trueならする。falseならしない。trueにしていてもし浪人にログインしていないことを確認したらログインしにいく。
password: '1234',
},
};
/**************************************
設定箇所終わり。
https://info.5ch.net/index.php/%E6%9B%B8%E3%81%8D%E8%BE%BC%E3%82%81%E3%81%AA%E3%81%84%E6%99%82%E3%81%AE%E6%97%A9%E8%A6%8B%E8%A1%A8 <h3>o- *************************************/</h3>
/**************************************
・NULL演算子(??)は使えない。論理積(&&)は使える。
・オブジェクトの分割代入はできない。
・importはできない。 <h3>o- *************************************/</h3>
/**************************************
関数 <h3>o- *************************************/</h3>
/**
* ここから始まる。
*/
checkSettings();
var _TextCsvCursors = new TextCsvCursors(
SETTINGS.postSettings.noAnkerPostTextCsvStartRow > 0
? SETTINGS.postSettings.noAnkerPostTextCsvStartRow - 1
: SETTINGS.postSettings.noAnkerPostTextCsvStartRow,
SETTINGS.postSettings.textCsvLoop,
),
SETTINGS.postSettings.replyPostTextCsvStartRow > 0
? SETTINGS.postSettings.replyPostTextCsvStartRow - 1
: SETTINGS.postSettings.replyPostTextCsvStartRow,
SETTINGS.postSettings.textCsvLoop,
),
);
var _LoopStatuses = new LoopStatuses(0, SETTINGS.postSettings.minAnker);
const _MyPosterName = new MyPosterName({
name: SETTINGS.nameSettings.name,
});
const _ThreadUrl = openPromptThreadUrl();
//ループ
while (true) {
SETTINGS.ipSettings.checkIp && checkCurrentIpNotTheIp();
//スレを開く
openUrl(_ThreadUrl.fullUrlHttps());
//浪人にログインする設定なら、浪人にログインしているかどうかを確認し、していなければログインしにいく。
if (SETTINGS.roninSettings.checkLogin) {
}
}
if (SETTINGS.postSettings.replyPost) {
const targetAnkerNumber = createPostDOMList()
.filterPostnumberHigher(_LoopStatuses.currentMinAnker())
.filterByPostername(SETTINGS.postSettings.filterNames)
.filterByPosternameNotIncluded(
SETTINGS.postSettings.filterNamesNotIncluded,
)
.filterByText(SETTINGS.postSettings.filterText)
if (targetAnkerNumber !== null) {
const r = _TextCsvCursors.takeNextRowTextAsReply(targetAnkerNumber);
messageDisplay(`返信対象有り。アンカー先: ${targetAnkerNumber}`);
return {
...r,
updatedLoopStatuses:
_LoopStatuses.updateMinAnker(targetAnkerNumber),
};
}
}
if (SETTINGS.postSettings.noAnkerPost) {
//返信対象無し、或いは返信しない設定の場合。アンカー無し投稿文を作る。
const r = _TextCsvCursors.takeNextRowTextAsNoAnker();
messageDisplay('返信対象無し。アンカー無し投稿。');
return {
...r,
updatedLoopStatuses: _LoopStatuses,
};
}
return null;
})();
if (p) {
//投稿。
nickname: SETTINGS.nameSettings.nickname,
korokoro: SETTINGS.nameSettings.korokoro,
area: SETTINGS.nameSettings.area,
}),
SETTINGS.mail,
p.text,
);
//_TextCsvCursorsと_LoopStatusesを更新。
_TextCsvCursors = p.updatedTextCsvCursors;
_LoopStatuses = p.updatedLoopStatuses.incrementPostCount();
`投稿回数: ${_LoopStatuses.currentPostCount()}`,
`minAnker: ${_LoopStatuses.currentMinAnker()}`,
`今回アンカー無し投稿取得行: ${_TextCsvCursors.currentRows().noAnker}`,
`今回アンカー有り投稿取得行: ${_TextCsvCursors.currentRows().reply}`,
]);
} else {
`返信対象が現われるのを待機中...。`,
`投稿回数: ${_LoopStatuses.currentPostCount()}`,
`minAnker: ${_LoopStatuses.currentMinAnker()}`,
`今回アンカー無し投稿取得行: ${_TextCsvCursors.currentRows().noAnker}`,
`今回アンカー有り投稿取得行: ${_TextCsvCursors.currentRows().reply}`,
]);
}
wait(SETTINGS.baseWaitTime + randomRange(0, SETTINGS.waitTimeRange));
}
}
/**
* 投稿処理と投稿結果を見てリトライしたりマクロ終了したり。
* @param {string} serverName サーバー名
* @param {MyPosterName} _MyPosterName
* @param {string} postMail メール
*/
serverName,
postMail,
_MyText,
retryTimes = 0,
) {
const r =
retryTimes === 0
? new ValuesOfPost(serverName, _MyPosterName, postMail, _MyText).post(
postTo5chTread,
)
serverName,
postMail,
_MyText,
).postSubstring(retryTimes, postTo5chTread, postConfirm);
if (r) {
back();
return;
}
wait(7);
const error = createPostErrorMessage().analyze();
messageDisplay(error.message);
if (error.order === 'KILL') {
kill();
} else if (error.order === 'SKIP') {
return;
} else if (error.order === 'TRUNCATE') {
back();
serverName,
postMail,
_MyText,
retryTimes + 1,
);
} else if (error.order === 'WAIT') {
wait(SETTINGS.waitTimeForAvoidingPunishment);
serverName,
postMail,
_MyText,
retryTimes,
);
} else if (error.order === 'LOGIN') {
serverName,
postMail,
_MyText,
retryTimes,
);
}
return;
}
/**
* 現在のIPアドレスに、SETTINGS.ipSettings.avoidTheIpの値が含まれていないことを確認する。含まれていたらマクロを一時停止。
* @returns
*/
function checkCurrentIpNotTheIp() {
openUrl('https://www.cman.jp/network/support/go_access.cgi');
const _IpAdress = createIpAdressFromCMan();
if (_IpAdress.includes(SETTINGS.ipSettings.avoidTheIp)) {
pause('現在のIPに指定した値が含まれていることを確認。');
}
return;
}
/**
* @returns
*/
if (
SETTINGS.postSettings.noAnkerPost === false &&
SETTINGS.postSettings.replyPost === false
) {
return kill('設定エラー。noAnkerPostとreplyPost両方ともfalseになってる。');
}
if (
SETTINGS.postSettings.noAnkerPostTextCsvStartRow < 0 &&
SETTINGS.postSettings.replyPostTextCsvStartRow < 0
) {
return kill(
'設定エラー。noAnkerPostTextCsvStartRowとreplyPostTextCsvStartRow両方とも-1になってる。',
);
}
if (
SETTINGS.postSettings.noAnkerPostTextCsvStartRow === 0 ||
SETTINGS.postSettings.replyPostTextCsvStartRow === 0
) {
return kill(
'設定エラー。noAnkerPostTextCsvStartRow/replyPostTextCsvStartRowの初期値は-1或いは1以上で。',
);
}
}
/**
* 入力フォームを表示して入力されたスレのURLを受け取る。
*/
function openPromptThreadUrl() {
const url = prompt('スレURLを入力');
}
/**
* 開いてるスレのレス全て読み取ってPostListインスタンスを作って返す。
* 重すぎるので使うのやめ。どうやらインスタンスの大量生成が原因な模様。
*/
const posts = window.document.getElementsByClassName('post');
return new PostList(Array.from(posts).map((e) => new Post(e)));
}
/**
* 開いてるスレのレス全て取得してPostDOMListに格納して返す。
* @returns
*/
function createPostDOMList() {
const posts = window.document.getElementsByClassName('post');
for (let index = 0; index < posts.length; index++) {
//HTMLCollectionからElementを1つずつ抽出して配列に。
arrPostDOMList.push(posts.item(index));
}
return new PostDOMList(arrPostDOMList);
}
/**
* 開いてる投稿結果画面に表示されてるエラーを読み取ってPostErrorMessageインスタンスを作って返す。
*/
function createPostErrorMessage() {
window.document
プログラミング未経験から1ヶ月ほどで、将棋の評価値の新たな方法でのグラフ化を行うPythonツールを作った。
https://github.com/k-the-p/notherscore
この記事は2本立てです。プログラミングより結果のグラフや将棋に興味がある方はもう一方の将棋編から読むことをおすすめします。
未経験から1ヶ月！Pythonで観る将ライフを向上させた話（将棋編）
AIはわれわれアマチュアの将棋への親しみを大幅に向上させてくれた一方で、棋士が悩みに悩んだ結果として評価値が下がる手を指してしまったときに、「悪手きたwwww」と騒ぐ主にABEMAのコメント欄には忸怩たる思いがあった。
とはいえ、もう評価値を知らなかった時代に後戻りするなんてことは誰にもできないだろう。そして、電王戦から将棋にハマった自分自身としても、AIを否定はしたくない。
であるなら、AIを用いた新しくよりよい将棋の楽しみ方を探っていくしかないのではないか。
以前から私は、「AIの手を指せるなら人間も苦労しないんだよなあ」と思っていた。あるとき藤森哲也先生がYoutubeチャンネルで言っていたことを聞いて得心がいった。「AIの一手は最強の一手なんです。確かにプラス1000点になるけど一手間違えた瞬間にマイナス何百点になるような綱渡りの手。それよりもアマチュアの皆さんにはプラス数百点で得は少ないけど安全な道、最善の一手を学んで欲しい」（大意）と。
ここで言う「最強の一手」に人間にして最も近いのは紛れもなく藤井聡太四冠であろう。藤森先生はアマチュアに向けて喋っていたが、その葛藤は間違いなくプロの中でもあるはずである。渡辺明三冠が言うように「藤井くんと全く同じスタイルを今から目指しても絶対藤井くんより強くなれない」のは自明であるからして。
私はここにドラマがあると思う。また、最強の一手と最善の一手が等しく「いい手」に見えてしまうわれわれアマチュアとしては、そこを機械に教えてもらえるのであれば、棋力向上にも繋がりそうである。
第1候補手と第2候補手の評価値の差を取ってグラフ化すればよさそう？
（差が小さければ手が広い、差が大きければ絶対手に近い、綱渡り）
目指すのはあくまで便利な将棋ツール。将棋AIを作りたいわけではないので、将棋AI自体は局面を入れたら評価値を吐く謎の箱という扱いでよい。
グラフ化や数値の扱いだけでなく、将棋AIとのやりとりをやってくれるあれこれもあるようなので。
あと習得が楽だと聞いた。その話を教えてくれた人はもう10年間英語学習法をブクマし続けてるけど。
あと「読みやすいコードじゃないと動かない」って設計思想がかっこいい。ついでに言うといわゆる「おまじない」が少なそうなのも魅力。（CのHello worldで挫折した経験あり。studio.hって何……）
プログラム講師をやっている？方が音楽制作を初歩からやってみる、という（残念ながら）リアルタイム視聴者が俺だけしかいないような配信があったので、音楽の基礎（についての知識は持っていた）を教えてあげたお返しのような形で、「pythonでこういうことがしたくてこういうライブラリがあるのはわかった。経験はHTML+CSS（変数導入前、Bootstrapなんてなかった）のみ。どうしたらよいか」という質問をしたら、「progateは簡単すぎると思うのでPaizaが丁度いいのではないか」というアドバイスを頂き、比較もせずに即登録したのだが結果的にはこれがドンピシャだった。
最近流行りの、環境構築不要で講座の内容を書いて覚えるタイプのサイト。
無料で入門講座の序盤を受けていたらふと目に入ったのが、「対象者：これからプログラミングを学びたい方。HTMLがどのようなものかを知っている方。」でYoutuber先生のオススメ完璧か？と思った。そして実際に完璧だった。
基本的に1講座3分+演習1～2問＋やりたければ問題集たくさんという形式なのだが、これが簡単すぎることなく難しすぎることもなく、俺の知識レベルにベストマッチだった。基本的に毎回何か書くことになるので、変数とは～みたいな解説だけで終わる回がほぼ無いのも飽きなくてよい。
Python入門（と言ってはいるがまだこれだけで発展編はない）の見出しは「プログラミングとは」「条件分岐・比較演算子」「ループ処理」「リスト」「辞書」「多次元リスト」「関数」「クラス」「クラス発展」「例外処理」に各5～8講座*3分+演習、という感じ。クラス発展の途中で行けそうだと思ったのでドロップアウトして実製作に移った。実際関数まで理解していれば、この程度の小さなツールには十分だった（もしかしたらクラスを使えば多少楽になった場面はあったかもしれないけど）。
また、これは書いてる今気づいたことだが、上のコースで学んだことで、実際に役立たなかったものはほとんどなかった（強いて挙げれば辞書くらい？使えてないだけかも）。このこともコース構成の優秀さを示している。
ここまででだいたい2週間くらい。
もともとこのサービスは知っていたのと、谷合先生が実際に使っていたように、便利そうなライブラリのcshogiが主にcolab(jupyter)上で動かすことを意図しているようだったので、まずここから入った。最初はcshogiが列挙してくれる特定局面での合法手をリストに入れて、そのリストの項目数＝その局面での合法手の数を出力することから始めた。これは本当に簡単にできて興奮した。
学習と好きなことが直結してると、こんなサンプルコードみたいな簡単なことで喜べるのでコストパフォーマンスがよい。
cshogiのチュートリアルで紹介されているレサ改というAIがどうもmultipv（有望な候補手を2手以上挙げる）に対応してないらしく、強さ的な問題でいずれ手を出すつもりだった予定を繰り上げてやねうら王との連携を試みる。
makeって何？あー、もりかしてMakefileが無いと動かない？（これを書いている今もこんな理解である）みたいな人間でもなんとかやねうら王をビルド？することはできた。レサ改をcshogiに読ませる数行のサンプルコードがとても役に立った。今でもあの完成品らしき拡張子が無いファイルがなんなのか分かってない。（なお、評価関数nn.binが無いと怒られたのでどこのご家庭にもある水匠4のそれをぶち込んだら動いた。評価関数とやねうら王の分担は今もって理解があやふや）（また、途中でAyane[やねうらお氏謹製ライブラリ]も使おうとしたがcolab上では上手く動かす方法が分からなかった）
一応これでcshogiで局面の最善手と次善手およびそれらの評価値を呼び出せるようになったのだが、単にdebugでずらずらと余計なものまで出力するのではなく、重要な指し手周りのinfoだけ出力するようにしようとしたが、上手いやり方がわからず、結局こうなった。
sys.stdout = open('out.txt', 'a') engine.go(listener=print)
ここは絶対もっとマシなやり方があるはずなので、識者の教えを請いたい。
Colab上でまあまあ目処がついたので、この辺りでPythonの環境を作った。ここまでそれをやっていなかった理由は、「おま環」トラブルの可能性をなるだけ遠ざけておきたかったからである。環境が悪いのか俺が悪いのか分からない、というのは初心者にとって限りなきストレスである。あーネットが繋がらなくてルーターの設定や接続とか支払いとか文字通り部屋をひっくり返しながら調べてたら実はフレッツ自体が落ちてた件を思い出してイライラしてきた。cshogiはJupyter上で動かすことを意図しているようなので、それで動かなければ自分の書き方が間違っているのだとほぼ確実にわかる。
まあこの辺りはいろんなサイト見ながら仮想化などしつつ普通に。仮想化が何か分かってないんですけど。
これまでColab上で書いてきたものは多少の書き換えで動いたので、ローカルにJupyter notebookをインストールして、数字の計算とグラフ化を試みる。
ちなみにこの時点で得られているデータはこんな感じ。
go info depth 1 seldepth 1 score cp -47 multipv 1 nodes 483 nps 241500 time 2 pv 3c3d info depth 1 seldepth 1 score cp -86 multipv 2 nodes 483 nps 241500 time 2 pv 4a3b info depth 2 seldepth 2 score cp -53 multipv 1 nodes 847 nps 423500 time 2 pv 3c3d 9g9f info depth 2 seldepth 2 score cp -68 multipv 2 nodes 847 nps 423500 time 2 pv 8c8d 7g7f info depth 10 seldepth 17 score cp -78 multipv 1 nodes 100163 nps 1963980 time 51 pv 8c8d 2f2e 4a3b 7g7f 3c3d 2e2d 2c2d 2h2d 8d8e 6i7h 8e8f 8g8f info depth 10 seldepth 17 score cp -111 multipv 2 nodes 100163 nps 1963980 time 51 pv 3c3d 7g7f bestmove 8c8d ponder 2f2e go info depth 1 seldepth 1 score cp 117 multipv 1 nodes 206 nps 206000 time 1 pv 2f2e info depth 1 seldepth 1 score cp 78 multipv 2 nodes 206 nps 206000 time 1 pv 7g7f ...
今回の小目標は、goで区切られた中から下から2行目と3行目のcpほにゃららを取得していい感じのリストにする、というものだ。この辺りは正規表現でなんとかなるだろうと見通しを立てたが、実際そうなった。
ただ、後手が見たときの評価値が後手目線なので、それだけにマイナスをかけるのはどうするか（そうしなければ、先手+3000点の次が「後手から見て」-2900点だったりして綺麗にグラフにならないのだ）を調べるのに結構時間が掛かった。
また、詰み周りでまたプラスマイナスやカンストの絡む計算をしたくないのもあり、数値にNaNを入れてグラフ表記を省略することにしたのだが、そうするとnumpyの関係で整数(とNaN)しか扱わないのに浮動小数点で計算しなければいけなくなって若干気持ち悪かったり。まあ動くのでヨシ！
この時点で、ローカルにKIFファイルを保存し、pyファイルでcshogiと水匠を動かし、Jupiter notebookを開き評価値グラフと手の広さのグラフを重ねて表示する、というそれなりのものは出来上がった。
簡単に言えばpyファイルで1手10万局面（森内チャンネルに出てたHEROZの方が使ってた数字をそのまま使っているので特に意味は無い）探索させ、最善手と次善手についての生の評価データを吐き出させ、ipynbでそれを整形し、グラフ化している。
基本的に全部VSCode上でできるので、慣れれば計算時間も含めて10数秒で結果が出るのだが、このワークフローはいかにも美しくない。
なので、Flaskという簡単らしいフレームワークを使ってローカルでWebアプリとして使えるようにしようと思った。inputとoutputをどうにかするだけだから余裕やろ。
Google colabを触り始めてからここまで1日。圧倒的成長！
Paizaラーニング再び。後半ではデータベースとか本格的な話もあるようなのだが、txtに書き込む一行掲示板を作るまでの前半部を高速で履修（演習は全部飛ばした）。なるほどー、こうやってやりとりするのね、と最低限は完全に理解した。
Jupyter向けのコードを普通のPythonに直してあっちで数字を出してこっちでそれを受けて元に戻して……とかやってると循環参照か何かで怒られることに。その対策に細かく部分を分けて関数にしたのだが、その場合ってもしかしてdefの内部しか読まれない？（共通部分も読まれると思ってた）（いや、共通部分は読まれるけど他のdef内が見えないのか？何も分からん）なるほど。こうなると関数の内部から上に戻るためにクラスとか欲しくなるのかなーという感想。
最終的にWebに公開しようとこの時点では思ってたので、txtに一旦出力するのが安全性的にどうかとか考えてたのだが、テキストの読み取り周りでハマる。結局抜け出せず諦めた。
以降は、HTMLにダブルクオートが抜けてるのに一時間気づかないとか、FlaskのXSS対策の対策をするとか、ファイルの書き込み設定をミスって2万手くらい蓄積されて評価値グラフが大変なことになったが、原因に気づかずひたすらグラフ生成部を調べ続けるなど、非本質的な問題にかかずらっていたので書くことは特にない。
なので、最初にgitignoreしてなかったせいで1万ファイルくらい上げそうになったけど、それ以外は特に問題も無く。中間報告からここまで2日ほど。結局1ヶ月かけずにプログラミングをそれなりに身につけることが出来た。「プログラムを覚えたければ作りたいものを見つければいい」というのは本当だな、と改めて思った。
https://anond.hatelabo.jp/20220107060727
どれくらい書けるようになったのか、を見たい方は主にvalue_output.py（将棋AIに思考させてデータを取り出す）とgraph.py（データを整形してグラフを書き出す）を見ていただければいいかと思います。
最初にPaizaを教えてくださったYoutuberの方、cshogiを初心者でも使いやすいように作って展示してくださったTadaoYamaoka様、水匠開発者のたややん様、水匠含めこんにちの将棋AIの基盤を作ってくださったやねうらお様、cshogiを通して利用したpython-shogiのKIFパーサーを書いてくださったTasuku SUENAGA様に、厚く御礼申し上げます。
文字列"pattern_A"と"pattern_B"の両方を含まない文字列にマッチさせる正規表現。
/^(?!.*pattern_A)(?!.*pattern_B).*$/
例:
pattern_Apattern_B ←マッチしない
pattern_Bpattern_A ←パターンが前後してもマッチしない
pattern_Cpattern_A ←片方だけでもマッチしない
pattern_Dpattern_Epattern_F ←マッチする
否定先読みで先頭位置に位置マッチすることで、複数の文字列をチェックできる。否定と肯定を組み合わせることも可能。
s/(?＜=\d)(?=(\d{3})+$)/,/
例:(置換前)
1
123
1234
例:(置換後)
1
123
1,234
123,456
1,234,567
123,456,789
1,234,567,890
例:
＜div＞abc＜div＞def＜/div＞ghi＜div＞jkl＜div＞mno＜/div＞pqr＜/div＞stu＜/div＞
否定先読みでマッチ対象ではない文字列位置にマッチしたのち、.で一文字だけ消費させて次の文字をチェックさせるテクニック。
・文章の中に複数種類の単位を持つ数字列がたくさんあるうち、特定の単位だけ除外してマッチする。(例:パック、kg、倍を除外したい)
/[\d.]++(?!パック|kg|倍)/
卵1パック(657.8g)の値段は225円、1.98ドルです。10kg買うと値段は15.202倍になり、約3420円、約30ドルです。
単位が大量にあるので全体を把握することができないのだが、少なくとも特定の単位だけは除外したいことが分かっている場合に使う。
「1番目の数値と2番目の数値を足して3番目の数値にする」、「2番目の数値と3番目の数値を足して4番目の数値にする」、「3番目の数値と4番目の数値を足して5番目の数値にする」、……
という感じで作った数値の列がフィボナッチ数列ね。
で、このルールだけだと「1番目の数値と2番目の数値はどうやって決めるんだ？」ということになるんだけど、それは0と1だと決まってる。
この1番目と2番目のことをプログラミングっぽく書くと、
def Fib( n ):
if n == 1:
return 0
elif n == 2:
return 1
という感じ。
Fib( n )ってのが「n番目の数値(を計算する関数)」ね。
で、計算が必要になる3番目以降だけど、この文章の1行目に書いたことをこのFib( n )を使って書くと、
「Fib( 1 ) + Fib( 2 )を3番目の数値にする」、「Fib( 2 ) + Fib( 3 )を4番目の数値にする」、「Fib( 3 ) + Fib( 4 )を5番目の数値にする」、……
と書ける。
それぞれの文章の後半もFib()を使って書くと
「Fib( 1 ) + Fib( 2 )をFib( 3 )にする」、「Fib( 2 ) + Fib( 3 )をFib( 4 )にする」、「Fib( 3 ) + Fib( 4 )をFib( 5 )にする」、……
という要領。
nを使って一般的に書くと、「Fib( n-1 ) + Fib( n-2 )をFib( n )にする」ということになる。
def Fib( n ):
if n == 1:
return 0
elif n == 2:
return 1
elif n >= 3:
return Fib( n-1 ) + Fib( n-2 )
抽象に依存するってことなんだよね。発想が抽象的でむずかしい。
以下に示すbeforeコードの欠点は、IOに関係する部分とビジネスロジック(誇張)が密結合していることで、このメソッドを変更する理由が複数存在している点である。(単一責任の原則に違反)
変更理由は、IOにnullが入ってくることを考慮するとか、暗号化アルゴリズムを変更するあたりがぱっと浮かんだ。
afterのコードは、readerとwriterを引数から受け取れるようになっていて、インターフェースに依存するようになって、単一責任の原則を守るようになった。
```
# before
def encrypt
end
end
# after
end
end
```
まとめ
「パートIII.Dで、当財団は、ダイムラーが使用した違法操作機器の運用にかかる委託研究について説明する。 ••••••（以下：••••••）が実施したこの調査では、これまで他の利益団体や当局が使用していない根本的に異なる方法論を採用した。端的にいえば、当財団が購入したEuro 6 Test Vehicleでテスト走行を行い、エンジンと排気ガス管理を制御するECU（Electronical Control Unit）から走行中の情報を読み取ったのである。これにより当財団は、試験車両の違法操作機器の根本的なメカニズムと機能を初めて洞察する者となった。本調査により当財団が同定できる限り、少なくとも8つの違法（SCRおよびEGR）操作機器が配備された、驚異的に複雑で洗練された排出詐欺が明らかになった。これらの違法操作機器はそれぞれ、実際の運転条件でシステム全体の効率を大幅に低下させる。ダイムラーのトリックの結果として、これらの違法操作機器はNEDCテストサイクル外でのみ動作する。」
「III.B.1. 序文
255. このセクションでは、当財団は、排出規制および適用される判例法に基づいて、違法操作機器の特性について説明する。 前述のとおり、当財団はとりわけ、2020年4月30日の欧州司法裁判所 Eleanor Sharpston 法務官の意見※に特に注意を払っている。（図14を参照）。」
※「2020年4月30日の欧州司法裁判所 Eleanor Sharpston 法務官の意見」はこちら。↓
"Court of Justice of the European Union PRESS RELEASE No 52/20
Luxembourg, 30 April 2020
Advocate General’s Opinion in Case C-693/18CLCV and Others (defeat device on a diesel engine)
According to Advocate General Sharpston, a device that adjusts upwards the operation of the emission control system of diesel engine vehicles during the approval testing of those vehicles is a ‘defeat device’prohibited by EU law
The objective of slowing down the aging or the clogging-up of the enginedoes not justify the use of such a device"
https://curia.europa.eu/jcms/upload/docs/application/pdf/2020-04/cp200052en.pdf
III.D.1. イントロダクション、研究の関連性、および主要な調査結果
295. このセクションでは、当財団の研究結果について論ずる。 この研究は、その方法論によって、上で説明した研究※とは区別される。 前述のように、この研究は、入力値（周囲温度や車速など）と出力値（PEMSで測定された排出量）を測定するのみならず、ECU自体の内部機能を測定することを目的とする。 テスト中にECUから直接情報を読み取ることにより、ECUの設計と操作を再構築可能である。」
※直前のIII.C で、第三者が公表した調査結果を挙げている。
「296.このアプローチは、概ねメーカーのソースコードがなければ違法操作機器の動作を検出および分析することは不可能であると考えられていることから、これまでどの型式承認当局・関連団体にも採用されていない。間違いなく可能であるとはいえ、費用と時間がかかり、専門知識を用いねばならない。この理由もあって、当財団はこれまでのところ、この研究を単一のテスト車両（本テスト車両）に限定している。本テスト車両は、第306項でさらに指定されているユーロ6対応型メルセデスE350である。モダンなユーロ6車両を選択する理由は、この車両タイプに、EGR（排気ガス再循環）とSCR（選択的触媒反応）の組み合わせからなる高度で複雑な排出制御システムが装備されているためである。このような複合システムでは、SCRシステムが処理の大半を引き継ぐため、EGRシステムはNOx排気負荷を減らすために「ハード」に動作しなくてもよくなる。 Euro 6モデルのECUソフトウェアはEuro 5ソフトウェアの拡張バージョンであるため、以前のバージョンの多くの機能がまだソフトウェアに存在している。調査が示すように、本テスト車両のECUには、機能しているEGR操作機器も多数含まれている。この点で、本研究結果は、EGR装置のみが装備されていた古いメルセデスベンツモデルにも関連している。
297. 要するに、この調査により、SCRとEGRの違法操作機器の範囲が特定された。これらはそれぞれ、特定の条件下でシステムの全体的な効率を大幅に低下させ、これによりSCR触媒コンバーターはほとんどの条件で動作容量のうち最大で60％に制限されることとなる。」
「300. 本調査の結果、違法なSCRおよびEGR操作機器は、NEDC検査下の状況では動作せず、通常の使用状況でのみ動作するようにプログラムされていることが判明した。 違法操作機器は、条件がNEDC検査条件から少しでも逸脱している場合にアクティブになることがわかっている。 さらに、SCR関連のいくつかの違法操作機器には、車両が数か月間使用された後にのみ違法操作機器を操作するように設定されたタイマー機能があり、NEDC検査を確実に通るようになっている。」
「302. 本調査はまた、これらの違法操作ツールのほとんどがソフトウェアの更新後にテスト車両から削除されたことを示している。これは、エンジンの損傷を防止したり、車両の安全な動作を確保したりするために違法操作ツールが必要ないことを意味している。このソフトウェアの更新によって、テスト車両のすべての違法操作機器が実際に削除されたかどうかは明らかではない。……」
III.D.2.a）はじめに
305. 本調査で使用されるメソドロジーは、データ収集、ソフトウェア分析、およびテスト車両から生れたテスト結果の解釈とを、組み合わせることである。306. 前述のように、本テスト車両は、メルセデスベンツ E 350 BlueTEC 4 MATIC Tであり、OM 642型 190 Kw、2987 ccm、6気筒エンジンを搭載している。本テスト車両の検査文書のコピーを別紙57に提示した。……
307. ECUの情報チャネルは複雑で量が多いため（ECUは内部で10,000を超える信号を処理）、イテラティブなプロセスを用いた。 最初のフェーズでは、通常使用中に車両のECUのプロファイルを作成するために、広範なデータ収集が行われた。 排出制御に関連するソフトウェアとデータは、ソフトウェア分析を使用して特定した。 その後、データ収集プロセスをさらに洗練し、より詳細なデータを得た。」
308. 調査中のデータ収集は、OBD-2ポートを使用して実行した。……」
「310.前述のように、ECUソフトウェアのソースコードや完全なドキュメントについては、ダイムラーがその情報を慎重に管理しているために、本調査者はこれらを得ていない。 ただし、ドキュメントやソースコードが利用できないソフトウェアの分析については多くの研究があり、そのような分析はIT業界で定期的に行われている。研究者は、「逆アセンブル」（ソフトウェアが人間が読める形式に変換される）やソフトウェアシミュレーションなどのいわゆるリバースエンジニアリング手法を使用している。 これらの手法により、ソースコードが利用できない文書化されていないソフトウェアの分析が可能になり、本テスト車両のECUソフトウェアの分析にも使用されている。」
315. 本SCRシステムでは、主な制御変数の1つはAdBlueまたはDEF（ディーゼル排気流体）の投与量である。本テスト車両のECU、Bosch EDC17CP57 は、システムに投与されたAdBlueの量を計算する。 SCR触媒コンバーター内で、AdBlueはアンモニアに変換され、次にアンモニアがNOxと酸素と反応して窒素と水に変換される。
316.有効性の尺度は、「SCR除去効率」または「変換効率」である。 SCRの潜在的な効率は、以下を含む多くの物理的条件によって制限される場合がある。
317. 以上のリストは完全なものではないが、適切に機能しているSCRシステムが物理的な制限を受けていることを示している。 これらの制限に対処するために、本ECUソフトウェアには、2つの異なる動作モードが含まれている。
318.最初のモードは、以下「アンモニア負荷モデル」と呼ぶもので、SCRシステムが完全に機能するモードである。 このモードは公的にアクセス可能なメディアでは説明されておらず、この用語自体は文献で使用されている標準ではないことに注意されたい。
319. 2番目のモードは「代替モデル」である。 これは、不正な操作ツールによってアクティブ化されるモードである。 代替モデルがいずれかの操作ツールによってアクティブ化されると、通常SCRは最大60％となる。 特にいくつかの違法操作ツールが同時にアクティブ化されている場合は、効率が大幅に低下する可能性もある。……」
330. 本調査による観察結果の要点は、代替モデルでは、実際の運転条件のほとんどで、SCRシステムのターゲット効率が比較的低い値に保たれるが、これは物理的な制限に基づいていない要因やポリシーの選択によって生じているため、 違法だということである。 言い換えると、SCR触媒でのNOxの還元に直接影響を与えることがない入力に応じて、効率目標が意図的に低い値に低減される。 したがって、これらの要素とポリシーの選択、およびそれらが有効にするメカニズムは、違法な操作手段と見なすことができる。
331. これらの違法なSCR関連の操作ツールは、以下の機能を共有する：
（i）それらは、温度、排気ガスの質量流量といった、極端な条件下で一般的に制御する必要がある物理的特性に応答する。
（ii）ただしそれらは、通常の「実際の」運転条件では、システマティックにアクティべートされる。
（iii）それらは、たとえば、正当化されないヒステリシスを使用することにより、アクティベート後に、ある効果が出るように設計されている。
簡単に言えば、ヒステリシスという用語は、新しい状態への切り替えを引き起こす値と元の状態への戻りを引き起こす値との間に特定の「範囲」がある状態を表す。一般的な例は、特定の温度で加熱がオンになるサーモスタットで、温度が初期値よりも数度低い場合にのみオフになることで、システムのオンとオフが連続して行われないようになっている。今回のケースでいうと、ヒステリシスは、元の状態（この場合は「アンモニア負荷モデル」）に切り替えるしきい値が「代替モデル」が動き出す状態に切り替えるレベルよりもかなり低い（または高い）場合に発生する; そして
（iv）それらはSCRシステムの目標効率を大幅に低下させ、AdBlueの投与を大幅に削減する。これにより、NOx排出量が大幅かつ大幅に増加する。
332. 本調査の結果、8個以上の違法操作機器が発見されたが、そのうち6個はSCRシステム（およびAdBlueの投与量）に関連している。……」
「III.D.4.a）SCR操作ツール1：排気ガスの質量流量
335. 最初の違法SCR操作機器は、SCR触媒コンバーターを通過する排気ガスの体積（排気ガスの質量流量）を参照する。
336. 上述したように、排気ガスの質量流量がSCR触媒の処理能力よりも大きい場合、排気ガスはSCR触媒から逃げることができ、NOxチャージを減らす機会が与えられないこととなる。 これに対処しないと、SCR効率の過大評価につながり、AdBlueのオーバードーズにつながる可能性がある。 このことで、SCR触媒がアンモニアでオーバーフィルされ、アンモニアのスリップが発生する可能性がある。 したがって、質量流量を監視し、過剰なマスフローが通知されたときにSCRのターゲット効率の推定値を下げることは、原則として、有効なストラテジーになる可能性がある。
337. ただし、テスト車両では、フィルタ後の排気ガスの質量流量の制限は、時速170 kgに設定されており、これは、実際の運転状況では約100 km / hに相当する。 このしきい値は、技術的な観点から見て、言い訳けができないほど低くなっている。 このしきい値を超えるとすぐに、ECUは代替モデルに切り替える。 さらに、（-80 kg / hの）強いヒステリシスが適用されるため、負荷モデルに切り替える場合、質量流量は90 kg / h未満でなければならない。 60 km / h程度の低速でも、このしきい値は日常的に超過している。 さらに、エンジンが一定している場合、短時間では負荷モデルに戻らない。
338. この制限は、正確には、SCRシステムの「エージングファクター」によって決まることに注意せよ。この機能に関連して、ECUはSCR触媒コンバーターがその耐用期間中にさらされた温度を記録し、これに基づいて経年変化の影響をモデル化する。ただし、以下のグラフに示すように、この違法操作機器のエージングファクターは、完全な100％（完全に新しい状態）が1％～99％（すなわち実質的に新しい）まで減少するとすぐにアクティブになるように設定されている。すでにその時点で、上限は時速200 kgから時速170 kg へ削減され、下限（ヒステリシス）は時速120 kg / hから時速80 kg / hに削減されている。 NEDC検査は完全に新しい車両で行われるため、輸入検査でこの違法操作デバイスを検出できないと推定できるのである。これに対し、本テスト車両はこれらの観測の時点で70,000マイル走行しており、ソフトウェアは69％のSCRエージングファクターを示していた。」
PS4の『The Last of Us 2』が事前のメタスコア大絶賛一色とは一転していざ発売されると前作ユーザーから賛否両論となりユーザースコアが激低で結果的に主要サイトの中でほぼ唯一批判的に評価していた日本のIGN Japanのレビューが海外ユーザーから再評価される怪現象が起きている。
2020年6月19日に発売されたPS4用ゲーム『The Last of Us Part II』。日本では「ラスアス2」、海外では「TLOU2」と略されることが多い。ソニー・インタラクティブエンタテインメント (SIE) のファーストパーティー（傘下スタジオ）であるノーティドッグ (Naughty Dog) が開発を担当し、SIEより発売された。アメリカのヴァージニア州に本拠地を置くノーティドッグは、『クラッシュバンディクー』シリーズや『ジャック×ダクスター』シリーズ、そして近年では『アンチャーテッド』シリーズによって知られている開発会社であり、2001年よりSIEの傘下スタジオとなっている。
前作『The Last of Us』は2013年にPS3で発売され、2014年にはPS4でリマスター版が発売された。PS3版とPS4版を合わせると現在までに約2000万本以上を売り上げている。メタスコアでは95点を獲得し、数え切れないほどのメディアによって表彰された（ https://en.wikipedia.org/wiki/List_of_accolades_received_by_The_Last_of_Us ）。
ゲームのジャンルとしては三人称視点のアクションアドベンチャーであり、サバイバル、ホラー、ステルス、シューターといった要素を含む。プレイヤーは成人男性のジョエルと少女のエリーを操作し、ゾンビがはびこる終末的世界を生き延びるために冒険を繰り広げる。オープンワールドではなくリニア（一本道）ではあるが、開発チームが「ワイドリニア」と呼ぶ自由度の高いリニアな空間は、開発者の企図した凝ったゲーム体験とプレイヤーの自由な探索という相反するゲーム性をバランス良く両立させるものである。
Metacritic（メタクリティック）というレビュー収集サイトによって、主要ゲームサイトのゲームレビューの点数を収集、平均したもの、それが「メタスコア」であり、それとは別にユーザーが投稿した点数を平均したものが「ユーザースコア」である。
Metacriticは1999年に映画レビューサイトとして始まり、その後サイトの評価収集対象にビデオゲームを加えた。メタスコアは現在では世界で最も重要視されるゲームの評価基準のひとつとなっている。単純にいえば、あるゲームに100点をつけたレビューサイトと60点をつけたレビューサイトがあれば、それらを平均した80点がそのゲームのメタスコアとなる（実際にはメディアごとに重要度というものが設定されており、その重み付けを反映してスコアが計算されるため、もう少しややこしい）。
『The Last of Us Part II』は世界各国のメディアによるレビューで絶賛され、2020年6月20日10時（JST）時点では94件のレビューを平均して95点という非常な高評価を受けた。過半数を越える実に50件ものレビューが同作に100点満点を与えている。
このメタスコアは2020年に発売されたゲームのなかで最高評価であり、その下には同じく95点の『ペルソナ5 ザ・ロイヤル』、93点の『Half-Life: Alyx』、91点の『あつまれ どうぶつの森』などが続く。なお日本のユーザーに馴染みが深いタイトルで言うと、『ファイナルファンタジーVII リメイク』は87点、『仁王2』は85点、『バイオハザード RE:3』は84点である。（ https://www.metacritic.com/browse/games/score/metascore/year/all/filtered ）
PS4タイトル全体の中では、97点の『Red Dead Redemption 2』（2018年）と『グランド・セフト・オートV』（2014年）に次ぐ順位である。（ https://www.metacritic.com/browse/games/score/metascore/all/ps4/filtered?sort=desc&view=detailed ）
しかしその中にあって、日本のIGN Japanは10点満点で7点とやや厳しめの点数をつけている（ 過去との決別で残された物語『The Last of Us Part II』レビュー https://jp.ign.com/the-last-of-us-2/44388/review/the-last-of-us-part-ii ）。レビュアーの福山幸司は前作が「ビデオゲーム史上に残る、マスターピースであることが疑いようがない」とした上で、「残念ながら『The Last of Us Part II』は、前作を超えるどころか、共に並び立つことすら許されないほど、いびつな出来栄えとなってしまった。」と評した。福山が同作に批判的な評価を下している原因は、主にそのストーリー面についてのものだ。Metacriticに収集された94件のレビューのうち、ラスアス2にIGN Japanと同程度またはそれ以下の評価を与えているメディアは、ほかにGAMINGbibleとGame Revolutionだけである。
IGN Japanは6月13日に福山によるレビューを発表し、さらにその翌日には同編集部のクラベ・エスラによる同作のレビューをめぐる分析記事が掲載された（ 世界各国のメディアが『The Last of Us Part II』を大絶賛！ IGN JAPANの評価が激しく異なる理由を紐解く https://jp.ign.com/the-last-of-us-2/44460/news/the-last-of-us-part-ii-ign-japan ）。相反する評価を受けるビッグタイトルは時々あるが、それを分析した記事が投稿されるのは頻繁にあることではなく、それだけラスアス2が注目を集めるタイトルであること、IGN Japanのレビューが異色であったことを示していると言えるだろう。
2020年6月19日にいざゲームが発売されると、ユーザーからはたちまち賛否両論が巻き起こった。議論の的となるのはやはり主にストーリー面についてであり、前作のファンからの批判が多くを占めた。Metacriticのユーザーレビューは、2020年6月20日10時（JST）時点では17984件のレビューを平均して3.3という酷評としか言いようのないスコアになっている。
そして、このような酷評を与えられるにつれ、IGN Japanのレビューが再評価されつつある。興味深いのは、海外のゲーマーの多くが（日本のゲーマーが『ファミ通』のクロスレビューに対して揶揄するのと同様に）多くのメディアの絶賛レビューはメーカーから受け取った金銭によって操作されており信用に値しないと信じ込んでいる点だろう。以下、ツイッターでひっかかった意見の一部。
まおんも@nagineco
MichiruBOSS @N6Gi7
I think one of the best review about Tlou2 is from IGN Japan. If you are interestes, go check it out.
Sublem @DarthSublem
Whooo boy, friend is pissed off at TLOU2, he says it's a PoS because the fucked the story so hard. IGN Japan was right. Gameplay and graphics are great, but the story is complete ass. He told me about the story and ending, and I have to agree. It's basically a big FU to TLOU1
（友人がラスアス2に立腹している。ストーリーがとても酷くて凹んでいるらしい。IGN Japanは正しかった。ゲーム性とグラフィックは素晴らしい、しかしストーリーは本当に最低。彼はストーリーとエンディングについて語ってくれて、私も同意した。今作は基本的に前作に対するFU (Fuck You) だ）
The Last Of Us Part IIを5時間程度プレイしてみたが、IGN Japanのレビューで言いたいことが序盤をプレイしただけで、非常によく伝わってきた。7/10という点数になるかはともかく、賛否両論になるのがほぼ確実なゲーム。クリア時に今の感想を塗りつぶすほどの展開になっていると嬉しいな。
Mashiro@li__xunhuan
#TLOU2
高真剣@scaa315
Rich Price@richprice16
I’m only 3 hours in, but the IGN Japan review of game resonates the most so far. They basically said it’s a good game, but not 10/10. The gameplay is virtually identical to the original, which is 7 years old.
（まだ3時間プレイしただけだが、いまのところIGN Japanのレビューが最も共感できる。基本的には良いゲームだと言えるが、10点満点はない。ゲーム性は7年前のオリジナルとほぼ同じだ。）
Metacritic needs to make it that the Critic Reviews are based on actual critics and not paid off journalists. The only legitimate review on there is from IGN Japan. Even THEY were generous.
（Metacriticは、そのCritic Reviewsが実際の批評家に基づいたものであって報酬を受け取ったジャーナリストによるものではないことを明らかにする必要がある。唯一の正当なレビューはIGN Japanによるものだった。それですらまだ手ぬるい。）
IGN Japan did a better job review this game.
This game is not a masterpiece, is not a 10/10 or 9/10.
I don't care about gay or bi characters, i think that is amazing but the story of this game is a 6/10.
Yes the graphics are amazing but that alone is not what makes a great game.
（IGN Japanはこのゲームレビューで最も良い仕事をした。このゲームはマスターピースではないし、10点満点でも9点でもない。私はゲイやバイのキャラクターは気にしない、それは素晴らしいことだと思うけれど、でもこのストーリーは10点満点で6点だ。）
Sublem @DarthSublem
Friend has, he says the story is dog shit and just takes a shit on TLOU 1.
From what I can tell, IGN Japan was right, and everyone who gave a 10/10 was obviously paid off
（友人は今作のストーリーはラスアス1の上にひりだした犬の糞だと言った。私の知る限りではIGN Japanは正しかったし、10点満点を付けたやつは明らかに金をもらっている）
ラスアス2
まだ半分だけど、俺は苦手
IGNJのレビューも納得だわ...
話が重くて辛いとかじゃなくて単純に話がつまらなくて辛い
#ラスアス2
Ivanhoe20@Ivanhoe20
It means IGN Japan is less biased than IGN USA in terms of criticism
Let me tell you this IGN gave the game a 10/10 and most def is sucking up to ND and sony but IGN japan gave the game a 7/10 and said the story is bad and did not follow the same route as the first one so i wouldn't trust any gaming journalists or company on an honest review
（IGNは10点満点で10点を与え、Naughty Dogとソニーにおもねっているが、IGN Japanは同作に7点を与え、ストーリーは良くなく、前作のようにはなれなかったと言う。だから私はゲームジャーナリストや企業が誠実なレビューをするとは信用できない）
I don't believe to the 100% ratings, I don't believe to 0% ratings either...
IGN Japan gave the game a 70% score, probably what it really deserves.
（私は100点の評価は信じていないし、0点の評価も信じていない……。IGN Japanは本作に70点を付けたが、おそらくそれが実情に近い。）
vεr†rø@DaytimeCurfew
The thing with IGN is that you can pay them for a review. Like almost any "credible" reviewer. IGN Japan tho, thats a realistic review
（IGNについて重要なのは、レビューのために彼らに金銭を支払うことができるということです。ほとんどの「信頼できる」レビュアーと同様に。ING Japanは現実的なレビューだったけれども）
Nemui@Gelzoniansuss
IGN Japan summed that up pretty good there.
Graphics are out of this world. Its beautiful.
But well... new characters only to throw them away.
It seems like they couldn't buy IGN Japan in the end haha
（IGN Japanはかなり上手くまとめている。グラフィックはこの世のものとは思えない。美しい。でも、、、新キャラはそれらを投げ捨ててしまった。結局のところ彼らはIGN Japanを買収できなかったようだ。笑）
わからん。
考えられうる要因としては、ゲーマーの「ポリコレ疲れ」やTroll（荒らし）がある。
前作から引き続き主人公を務める女性主人公エリーは、本作ではレズビアンであることが明らかになり、新キャラクターでバイセクシャルのディーナと接近する。新キャラクターのレブはトランスジェンダーの少年である。今作でメインキャラクターの一人となるアビーは、発売前に誤って噂されていたようなトランスジェンダーの女性ではなく、単に「女性らしさ」がないだけの筋肉質な女性である。ラスアス2のシナリオを手掛けたNaughty Dogのイスラエル系アメリカ人のライターNeil Druckmann（ニール・ドラックマン）は、自身はシスジェンダーの男性であるものの、フェミニスト評論家Anita Sarkeesian（アニータ・サーキシアン）からの影響を公言しており、ジェンダーイコーリティや多様性に配慮したゲーム作りを心がけている。2004年よりNaughty Dogで働く彼は、前作『The Last of Us』や『アンチャーテッド 海賊王と最後の秘宝』のクリエイティブディレクターおよびライターを務めた。
ユーザースコアの世界には、Troll（荒らし）によるreview bomb（レビュー爆弾、レビュー爆撃）というものがある。『Death Stranding』のケースでは、1万8000件以上のユーザーレビューから約6000件以上が削除され、それにより「5.1」だったスコアは「7.3」まで上昇した。有名作の発売の際には、このようなreview bombの存在もまたよくある光景となっている（ レビューサイトが「デス・ストランディング」への「疑わしいユーザー評価」を大量削除してスコアが一気に急上昇 - GIGAZINE https://gigazine.net/news/20191210-removed-death-stranding-suspicious-ratings/ ）。おそらく今回のラスアス2でも、後日いくらかのレビューが削除され、揺り戻しが起こるだろう。
しかしツイッターでの評判などを見る限り、この低評価の原因はTrollによるいたずらだけとは思えない。結局のところ不満を集めるのは、新メインキャラクターのアビーが男性に媚びたところのない政治的に正しい女性キャラクターだったからではなく、前作で辛い旅をともにしてプレイヤーがさんざん感情移入した主人公ジョエルがポッと出のアビーによく確認もされずあっさり射殺され、ジョエルの代わりにそのアビーを長時間にわたってプレイアブルキャラとして操作しなくてはならないというゲームの構造によるもの、それにとっちらかって焦点の定まらないストイーリーラインによるものだろう。
ぼく「こんにちは、ベン。ぼくはWashlet2000。便意はどう？」
面「超いい感じだよ。きみは？」
ぼ「ぼくも超いい感じさ」
面「それはよかった。わたしは部署AのToiletエンジニアで3年目なんだ。社内ツールを作ってるよ。Benki関係のツールで、超クールでExcitingなやつなんだ」
ぼ「それはクールだね」
ぼ「うん。ぼくは経験豊富な自宅警備員で…〇〇で貢献して…リーダー経験が……」
面「Cool（たぶん聴いてない）。じゃ、問題に入ろうか。わたしからの問題はね…」
ぼ「あ、はい」
ぼ「Unkの管理…」
面「そう。Unkってさ、知的生命体でしょ？あれを実現するの。『分裂』もあるから注意して」
ぼ「なるほど。えーと、それはHankeyみたいな普通のUnkだよね。えーとえーと」
面「…」
ぼ「えーと、そうだ、Unicodeとか決まってる？」
面「決まってるよ。U+1F4A9」
ぼ「うーん。じゃあUnkって何を保持したらいい？種類、個数？」
面「いい匂いだね。ここでは簡単のため、そうだね、個数だけにしようか」
ぼ「ならUnkの個数を持つ感じかな」
面「多分そうだね」
ぼ「えーと、そして、『分裂』のときに増える個数、『消滅』したかどうかを返すAPIが要る」
面「うん。あと新しいUnkが産声を上げたときも」
ぼ「そうだね。じゃあ内部的には、分裂した時の増殖個数を計算して、unkで現在の個数を管理する感じかな…」
面「それで行けそう？」
ぼ「待って。それで、APIはdivision()、roar()、isDead()でいい？」
面「うん、そうだね。とりあえずAPIはそれで良いよ」
ぼ「OK。あ、division()でもうそれ以上増えれないときには、どうする？」
面「それもいい匂いだ。そうだね、今の個数を返すようにしようか」
ぼ「あと何かあるかな…」
面「…」
ぼ「Unkだと、大腸菌を表示したり、そこからBenkiにジャンプしたりできるけど…」
面「あとで必要になるかもね」
ぼ「だよね。速度は…当然すべてO(1)でやらないといけない」
面「速いほうがいいね」
ぼ「あとは、えーと、Benkiクリアもあとで付けそうだな。まあこれは簡単か」
面「そうだね」
ぼ「まとめると、Unkの個数を整数のIntで持ち、unkで管理する。division()が呼ばれたら、分裂して、isDead()が呼ばれたら、生存の真偽を返す。分裂時にはroar()を呼び出して、Unkoooooooooo!×(増殖個数分)産声をあげる」
面「それで良さそう？」
ぼ「うーん、多分…なにかあるかな…」
面「『消滅』を何度かしたあと、『分裂』をしたらどうなる？」
ぼ「ん？……あ、だめだ！そうか、『消滅』『消滅』『分裂』で過去の個数うんこに増えてしまう！つまり、isDead()が真なら、その時のunkを初期化しないと！」
面「そう！ならどうする？」
ぼ「うーん。変数maxUnkを足せばいいかな。isDead()はmaxUnkより大きな場合は真。そのときはunkを初期化する」
面「なるほど。大丈夫そうだね」
ぼ「あとはOKかな？…よし、じゃあコード書いてみるよ（マーカーを手に取る）」
ぼ「まずクラス外観はこんな感じかな…（カキカキ）」
class Unk: def __init__(self): pass def division(self): pass def roar(self): pass def isDead(self): pass
面「ん？これ何の言語？」
ぼ「pyてょnだよ。ぼくはpyてょn使いなんだ（自己紹介で言ったけど…）」
面「Cool」
ぼ「そして、Unkの個数を整数で持つよ。名前はunkでいいか」
面「OK」
ぼ「それと有効な最大unk数を保持するmaxUnkが要るね」
class Unk: def __init__(self): self.unk = 1 self.maxUnk = 1024 def division(self): pass def roar(self): pass def isDead(self): pass
面「なんでunkを1で初期化したの？」
ぼ「これは『いまの個数』だから。初めは１つのUnkが存在するのを想定してる」
面「なるほど」
class Unk: def __init__(self): self.unk = 1 self.maxUnk = 1024 def division(self): self.unk = self.unk*2 def roar(self): print("Unkoooooooo! ×", self.unk//2) def isDead(self): return self.unk > self.maxUnk
ぼ「division()、roar()、isDead()も書くとこんな感じかな…」
面「増殖の計算は２倍したんだね」
ぼ「そう。ちょっと手動テストしてみるね…。えーとunkが無いときのdivision()、roar()は大丈夫そうかな…。初回のdivision()でunkのサイズが1になって…そのあとroar()したら…isDead()は……」
unk = Unk() while True: if not unk.isDead(): unk.division() unk.roar() else: break --- Unkoooooooo! × 1 Unkoooooooo! × 2 Unkoooooooo! × 4 Unkoooooooo! × 8 Unkoooooooo! × 16 Unkoooooooo! × 32 Unkoooooooo! × 64 Unkoooooooo! × 128 Unkoooooooo! × 256 Unkoooooooo! × 512 Unkoooooooo! × 1024
面「大丈夫そう？」
ぼ「うん…たぶん…」
面「じゃいくつか聞くよ」
def myfunc(arr): if len(arr) ＜= 1: return arr left = [] right = [] ref = arr[0] ref_count = 0 for e in arr: if e ＜ ref: left.append(e) elif e ＞ ref: right.append(e) else: ref_count += 1 left = myfunc(left) right = myfunc(right) return left + [ref] * ref_count + right
どもども。
わたしは「なにか作ってみろ」系の言説にはまったく同意しません。
わたし自身、会社に3ヶ月間みっちり導入教育をしてもらい（COBOL85とPL/I。時代がわかる……）、基本的なアルゴリズム（コントロールブレーク、マッチング、マスタ－トランザクション、ソート、マージ、etc.いよいよ時代がわかる……）の演習を（給料をもらいながら）やって、その後もプログラムとつかず離れずでフラフラと生きてきました。
こういう経験は新卒カードがあるから有効なもので、では1から始めるとしたら……、というときに、プログラミングスクール（専門学校）というのは悪くない選択肢ではないかと思います。が、行ったことないので正直わかりません。
実際自分が1から始めるという立場になったら、まったくオロオロして元増田さんのように世のなか（の気にいらないヤツら）に呪詛を吐いて満足するだけだったと思います（当然ながらそれをいくらやってもプログラミングは上達しません）。
話をプログラミングだけに限っていえば、一番大事なのはやりかたじゃなくて動機だろうと思います。
「なにか作ってみよう」というのは、なにか作ってみようと思ってない人にはまったく心に響かないでしょう。
動機ドリブンで「なにか作ってみた」人といえば思いだすのは、MikuMikuDanceの樋口優さん（ミクを簡単に踊らせたい！）とhinadanの若宮正子さん（高齢者にも遊べるゲームが欲しい！）でしょうか。
ただかれらはわたしから見れば（モチベーションを維持しそれを行動に移す）天才で、あんまり参考にならないのも確かです。
あと、元増田さんの動機は「プログラミングを生業にしたい」ということなので、野良プログラマでは履歴書上でのアピール力が弱いかも、と思います。
ビジネスで使われるアルゴリズムにはそれなりのルールがあります。安全な（バグの出にくい）コードの書きかた、「車輪の再発明」はぜず、枯れた（将棋で言えば定跡のような）アルゴリズムを使う、ほかの人に使ってもらえるための工夫（可読性の向上など）、etc.です。
「なにか作ってみよう」を繰りかえしても、そういった作法的なものが身につくかどうか、それは才能に関わってくる問題だと思います。才能だのみの手法を推奨するのは無責任だと思いますね。
また、たとえば「例をコピーして解析する」というのもある意味有効なプログラミング学習法ですが、「下手に習うと下手が伝染る」ともいいます。どれがお手本として優れているか、それを見る目はある程度ビジネス用途のプログラムに関わっていないと持てないというジレンマがあります。
野生のプログラマで就職に有効なくらいの力を見せるとしたら、なにかのコミッター（なにする人かよく知りませんが）とかになって「××ならこの人」となったり、プログラミングコンテストで上位の成績を残したりしなければいけないのかもしれません。
どうしたものでしょうね。ブクマカのみなさんの反応を見ると、専門学校でもあまり就職に有利にならない（ホントか？専門学校の意味あるのか？）という話ですが、目的が就職ならば、一番の近道のような気がします。
そこらへんからは、元増田さんがなにをしたいか、あるいは聞いてみたいだけだったのかによります。仕事には適性とやる気が大事です。あとは年齢と必要性かな。進路はオーダーメイド以外にはありえないので、提示された案を自分で選んでそれに賭けるしかないのかな、と思います。
さて、この文章は実はこの一文に反応してのものです。（↑のは前書き）
GWあたりからトシも考えずにRubyの再入門をしていまして、手始めに「首相動静」の整形ツールを作ってみました。
初心者で（Rubyに関しては仕事で使ったことないので）なにか作ってみよう、というとこの程度ですね。
これで就職に有利になるかというと、あんまりそうは思えないなあ。Excelのマクロが組めるとかのほうがどこかの事務所に潜りこめそうですよ（でもそれも最近はインフレ気味かもしれませんね）。
朝日新聞の首相動静は詳細ですが、改行が入っておらず、大変読みにくいものです。こんな感じです。
【午前】９時３１分、自民党本部。３３分、同党役員会。１０時２分、官邸。５分、閣議。２１分、宇宙開発戦略本部。３４分、柴山昌彦文部科学相。３８分、岩屋毅防衛相。４１分、山下貴司法相。１１時３分、安全保障と防衛力に関する懇談会。
【午後】０時１１分、政府・与党連絡会議。４４分、山口那津男公明党代表。１時２７分、日韓議員連盟の額賀福志郎会長、河村建夫幹事長。２時２０分、行政改革推進会議。５２分、兼原信克官房副長官補、秋葉剛男外務事務次官。３時３６分、麻生太郎財務相、財務省の岡本薫明事務次官、太田充主計局長。４時７分、太田氏出る。可部哲生理財局長加わる。１５分、全員出る。２５分、黒川弘務法務事務次官。３４分、谷内正太郎国家安全保障局長、北村滋内閣情報官、宮川正内閣衛星情報センター所長。４１分、谷内、宮川両氏出る。５時３分、北村氏出る。１０分、東京・永田町のザ・キャピトルホテル東急。宴会場「鳳凰」で中曽根康弘世界平和研究所設立３０周年記念式典に出席し、あいさつ。２０分、官邸。６時１８分、ガーナのアクフォアド大統領を出迎え。記念撮影。１９分、儀仗（ぎじょう）隊による栄誉礼、儀仗。２７分、アクフォアド大統領と会談。７時１２分、署名式、共同記者発表。３２分、公邸。首相主催の夕食会。８時４３分、アクフォアド大統領を見送り。９時、ヨルダンのアブドラ国王と電話協議。
ただ、これはフォーマットがはっきりしており、
と、例を見るかぎりキッチリとしたルールに則っているようです。
なので、「これだったら整形できるかも」と思い、再び学びはじめたRubyで整形ツールを作ってみることにしました。
【午前】
１０時０２分、官邸。
１０時０５分、閣議。
１０時２１分、宇宙開発戦略本部。
【午後】
０１時２７分、日韓議員連盟の額賀福志郎会長、河村建夫幹事長。
０２時２０分、行政改革推進会議。
０３時３６分、麻生太郎財務相、財務省の岡本薫明事務次官、太田充主計局長。
０４時１５分、全員出る。
０４時３４分、谷内正太郎国家安全保障局長、北村滋内閣情報官、宮川正内閣衛星情報センター所長。
０４時４１分、谷内、宮川両氏出る。
０５時１０分、東京・永田町のザ・キャピトルホテル東急。宴会場「鳳凰」で中曽根康弘世界平和研究所設立３０周年記念式典に出席し、あいさつ。
０５時２０分、官邸。
０６時１８分、ガーナのアクフォアド大統領を出迎え。記念撮影。
０６時１９分、儀仗（ぎじょう）隊による栄誉礼、儀仗。
あと、午後の時刻を24時間制にしたいな、とも思いますが、それは今後の課題（つぎに首相動静が話題になったとき）とします。全角数字の計算ってどうやるんだろう？
たぶんRubyistにいろいろ突っこまれると思うけど、こんな感じです。
プログラマは玉石混淆ですが、これは石のほうの例だと思っていただければさいわいです。
※ はてな記法にはシンタックスハイライトあるけど、増田だとInternal Server Errorになるのではずしました。見にくくてスマソ。
# encoding: utf-8 # 漢字コンバータのライブラリを取りこむ（Stringに漢字変換メソッドを付けてくれる。神） require 'kconv' # 正規表現パターン # 時刻をｈ時ｍ分形式からｈｈ時ｍｍ分形式にする # 否定後読みを使用する # 時は行頭にある OneDigitHour = /^((?<![０-１])[０-９]時)/ # 分は時のあとにある。このパターンとマッチすると、\1が時、\2が分になる。 OneDigitMinute = /^([０-９]{1,2}時)(?<![１-５])([０-９]分)/ # 分のない、時だけの行のパターン。否定先読みを使用 HourWithoutMinute = /^([０-９]{1,2}時)(?![０-５]?[０-９]分)/ # 行頭のｈ時ｍ分をｈｈ時ｍｍ分にするサブ処理（これは関数といっていいの？） def convTopHourMinute2TwoDigits(oneLine) # 時を変換 oneLine.sub!(OneDigitHour, "０\\1") # 分を変換 oneLine.sub!(OneDigitMinute, "\\1０\\2") # 分がない場合"００分"を追加 oneLine.sub!(HourWithoutMinute, "\\1００分") # 戻り値 oneLine end # 入力ファイルの名前 InputFilename = "首相動静2018年12月11日.txt" # 出力ファイルの名前 OutputFilename = "首相動静2018年12月11日_編集済.txt" # 入力ファイルをオープン inFile = File.open(InputFilename, "r") # 出力ファイルをオープン outFile = File.open(OutputFilename, "w") # 時刻パターンはシンプルに、ｈ時、ｍ分、ｈ時ｍ分、という3パターンを結合する # 1つのパターンで全部カバーするよりこちらのほうが見やすい。というか、脳の容量の問題で1文に書ききれなかった jikokuPattern = /[０-９]{1,2}時[０-９]{1,2}分、|[０-９]{1,2}時、|[０-９]{1,2}分、/ # 午前/午後 ampm = /(【午前】|【午後】)/ # 午前/午後、あるいは時刻の前で改行するためのパターン kaigyouSign = Regexp.union(ampm, jikokuPattern) # ファイル一括読み込み # 昔は1行ずつ読みこんでました。メインメモリが3MByteとかだったので contents = inFile.read.toutf8 # 入力終了。閉じておきます inFile.close # スコープの関係から、ここでローカル変数に代入 # ※ Rubyのスコープと暗黙の型には泣かされました。これに慣れるのがRubyのコツかしら # 明示的な型宣言はあったほうがいいと思うなあ。エラー出力の理由がわからなかったりするので。 hour = "" # デバッグ行はコメント化しています # 時刻パターンチェックのため、コンテンツを出力してみる # p jikokuPattern.match(contents) # エントリを改行サインで行に分ける contents.gsub!(kaigyouSign, "\n\\&amp;") # "\\&amp;"はマッチした文字列そのもの。2重のエスケープ"\\"が必要 # 改行チェックのため出力 # p contents # 入力を行で分割して各行ごとに処理 contents.split("\n") do |oneLine| # 午前/午後を示す開きカッコ"【"があるか if (oneLine =~ /^【/) then # そのまま出力 outFile.write(oneLine + "\n") # p "午前午後：" + oneLine next # 空白行は無視（スキップする） elsif (oneLine =~ /^[\s ]*$/) then # 出力しない # p " 空白行：<skip>" next # 行頭に「時」があるか elsif (oneLine =~ /^[０-９]{1,2}時/) then # あったら時間表示を抜きだしておく hour = oneLine.match(/^([０-９]{1,2}時)/)[0] # p " 時：" + oneLine outFile.write(convTopHourMinute2TwoDigits(oneLine) + "\n") next else # 「時」がなければつけて出力 oneLine = hour + oneLine # p "普通の行：" + oneLine outFile.write(convTopHourMinute2TwoDigits(oneLine) + "\n") end end
手でやったほうが早いね。
以上
