  |
はてなキーワード: 文字列とは
一点のみ、ゲームの実力が分断してしまったことについて、サーモンランがそれを解決する可能性があることは一緒に指摘しておこう。
サーモンランの co-op によって基本操作力が向上するのであれば、それを繰り返すことで、実力の向上する楽しさを得ることができるかもしれない。
そのためには、廃人が協力してあげようと思うくらいのインセンティブが必要で、それをどの程度提供することができるのか、割とそこにすべてがかかっていると言ってもおかしくはない。←ここまで
以下のサイトにコピペして入れると、その値(20c434365134990e6ae6f88a5fe48004)になります。単に伏せてた所についての予告文字列です。
……というわけで、元エントリにはこれを続けていました。
一点のみ、ゲームの実力が分断してしまったことについて、サーモンランがそれを解決する可能性があることは一緒に指摘しておこう。
サーモンランの co-op によって基本操作力が向上するのであれば、それを繰り返すことで、実力の向上する楽しさを得ることができるかもしれない。
そのためには、廃人が協力してあげようと思うくらいのインセンティブが必要で、それをどの程度提供することができるのか、割とそこにすべてがかかっていると言ってもおかしくはない。
以上、ハッシュ値の説明でした。後はチラ裏。後付けエントリは伸びない。
1年も経たないうちから「今後10年戦えるIP」とか書いてる人がいたので、逆を張っても良いのかなと思ってやってみました。
300近いブクマの中で6件だけ。意外とみんな興味がない？
ゲームキューブの時もWiiのときもWii Uの時も、早期から「新ハードで出すよ！」って牽引の材料にしていたものが、現在まで一切アナウンスされていないので心配しています。
上に書いたけど、サーモンランで操作に慣れる＆自分好みのギアを得られるようになって、そして次はバトルにいける、みたいな流れができたら良いと思う。
あとは正しいレーティングによるマッチの割り当てだけど……これはどのゲームでも課題になっているところと言うか越えられない壁なので、勝ち負けによらない楽しい体験をどんだけ提供できるかだと思う。勝率の平均はどう頑張っても5割なので。
言われて気づいた。確かにさみしくなりそう。
転売をサポートするシステムが全部死ねば良いのにね。ヤホクとかメルカリとか。
コロコロコミックの連載もだけど、確かにちゃんと商品展開やってますね……3日後、遊びたいと思っている子供たちにちゃんと届くと良いですね。
自分は根暗で、人間が嫌いで、自分にとって嫌なことがあるとすぐにスマホでネガティブワードで検索をし始め、精神病の名札がほしいというただそれだけの思いで精神病を調べまくってたらいつのまにかバーナム効果に陥っちゃってたり、ルサンチマンとかアレキシサイミアとかいう自分の中でかっこいいと思っているカタカナの文字列をわざわざ使いつつ、大学の心理学とか哲学だかの講義の論述問題で自分のどっよ～んとした心情を吐露して先生をドン引きさせて人様に迷惑をかけない主義の自分が先生に迷惑をかけたりしている超アイデンティティークライシス状態のつい最近虐待以外で自分の意志で飲酒しても未成年者飲酒禁止法に引っかからない程度の年齢になった大学生だけど、
本当の幸せになりたい
と思った。
自分の中での本当の幸せの定義は、「恒常的に幸せであると"感情レベル"で感じることができている状態」のことである。
感情レベルで感じるというのは、感情的に感じることができるということであり、逆に、いままで見てきた人の中に「～だから幸せだ」という、"考えた"結果として自分は幸せであると言っている人がいて、これを"思考レベル"の幸せというのならば、自分の中では 思考レベル ＜ 感情レベル という幸せ度の違いがある。
そして3時間程度考えた結果、本当の幸せになるには性格を変えなければいけないという結論に至った（性格は簡単に変えることができないと考慮した上での結論である）。
なぜそのような結論に至ったのかというと、自分の中では感情とは脊髄反射に似たような反応であると思っていて、脊髄反射に似たような反応は性格によって起こっていると思っているので、脊髄反射的に幸せを感じるには、性格という不可侵領域をなんとか書き換えるしかないと思ったからだ。
自分の中では性格という地盤の上に考えが成り立っているので、思考レベルの幸せで妥協しようとしても、自分の場合は情緒不安定で考えが性格に支配されているので、考えがコロコロ変わり恒常的に思考レベルの幸せを感じることができない。
そこで、考えがコロコロ変わってしまうのなら、その考えを性格に強制的にインストールしてしまえばいいんじゃない？と思ったが、それはもはや"思考レベルのインストール"でしかない。
やはり本当の幸せになるためには、大嫌いな第三者に自分へ自分が感情レベルで脊髄反射的に感じる言動を与えてもらって性格を書き換えてもらうしかないのだろうか。
当方、フリーの IT 技術者。ある Web ベースのシステムを開発しているのだが、プロジェクトのマネージャー、リーダーをはじめとするメンバーの無知と無理解のおかげで作業が進まずに困っています。
ブラウザーのキャッシュの仕組みを少しでも知っている人なら、非 IT 系の方でも読めるように書きました。ぜひ助言をお願いします。
私は発注元(A 社)に客先常駐している。私が契約しているのは A 社のグループ会社である B 社だ。
A 社内のチームメンバーは以下のとおり。
さて、今開発しているシステム(以下システム P)はもともとスタンドアローンで運用する形態だったが、最近クラウドバージョンの提供も始まり、現在はスタンドアローンバージョンとクラウドバージョンの並行開発となっている。X さん、Y さん、Z さんは主にクラウドサーバーの管理や、私や W さんが作った部分のテストを担当している。
クラウドバージョンの初めてのアップデートを控えた 6 月に問題が発覚した。コードをアップデートすると、ブラウザーのキャッシュが効いていて表示がおかしくなるというのだ。
プログラマー以外の 4 人は実は Web システムの案件は初めてで、ブラウザーのキャッシュの仕組みすら理解していない。X さんから相談を受け、「Web アプリケーションからブラウザーのキャッシュをクリアーすることはできない。代わりに、HTML から読み込まれる外部リソースの後ろに『?v=3.14』のようなダミーのクエリー文字列をつければよい。アップデートのたびに数字を変える。これは一般的に採用されている手法で、これ以外の解決策はない」ということを伝えた。具体的にコードエディター上で修正イメージを見せて、すべてに対応するのに 1 日あればできる、とも。
これで「そうですか、ではお願いします」となれば、テストを含めて 2、3 日で終わった話なのだが、ここから長い混乱が始まる。
X さんから、「変更箇所をなるべく少なくしたいので、前回リリース分と今回リリース分で変更のあったファイルのリストを出してほしい」と言われる。変更のないリソースにはクエリー文字列をつけたくないらしい。
内心呆れつつ、Git (ソースコード管理システム)でファイルの変更履歴を調べ、一覧表を提出した。X さんに「それぞれのページでソースコードを確認し、この一覧表に載っているファイルにはクエリー文字列がついていることをひとつひとつ確認するのですよね。却って手間が掛かりますよ。それよりも、すべてのファイルを対象にしたほうが作るほうもテストするほうも楽です」と伝えた。
6 月も残り 1 週間を切ったある日、Z さんから、「実際に問題になっているのはどのファイルのどの部分か、スタイルシートのどのクラス・ID 指定が効いていないのか、V さんが知りたがっている。原因解明に必要なので調べるように」と指示が出る。
私は「ブラウザーのキャッシュが効いているためで、キャッシュを消すか無効にすれば直る。今までも修正のたびにテストではキャッシュを消してもらっていたでしょう」と説明するが、調べろ調べろと繰り返すばかり。「そんなことを調べて何になるんですか。キャッシュの問題ですよ?」と言うと、Z さんは手をわなわな震わせて、「お客さまが知りたいと言っているのに、『そんなことを調べて何になるんですか』とはどういうことですか!」と声を荒らげる。しまいには「お客さまのご要望にお応えして私たちはお金をもらっている。お客さまからの依頼なら応えるのが当たり前」と言い出す。技術的に意味がないことをいくら説明するも理解されない。
非プログラマー 4 氏の知識の底上げをしないといつまで経っても平行線だと思い、Redmine (課題管理システム)にブラウザーのキャッシュの仕組みを解説する文書を投稿した。ほぼ同じものを以下に掲載する。非技術者にも分かりやすく書いたつもりだ。あまり細かいことを説明しても混乱させるだけだと思い、リクエストヘッダーの Cache-Control や Expires などは説明を省いた。
キャッシュとは
キャッシュ(cache) とは、一度読み込んだデータを内部に保存しておく機構のことです。2 回目以降の読み込み時はキャッシュを読み込むことで、処理時間の短縮を図ります。
ウェブブラウザーにおけるキャッシュは一般に、HTML ファイルおよび HTML から読み込まれる外部リソース(スタイルシートファイル、JavaScript ファイル、画像ファイルなど)に対して適用されます。
キャッシュが作られるタイミング
ブラウザーがあるファイルを読み込もうとする時、キャッシュがなければ実ファイルを読み込んだ上でそのファイルの内容をキャッシュします。
キャッシュが破棄されるタイミング
キャッシュがいつ破棄されるのかは完全にブラウザー依存です。異なるファイルのキャッシュが同じ期間だけ存在するかどうかも分かりません。
キャッシュはユーザーがブラウザーの操作で明示的に削除(クリアー)することはできますが、 サーバー側からクライアント(ブラウザー)のキャッシュをクリアーすることはできません。
ウェブアプリケーションのキャッシュ対策
ウェブアプリケーションをアップデートした際、クライアントのキャッシュを無効にするために、以下の手法がよく使われます。
＜ link rel="stylesheet" type="text/css" href="style.css" ＞ ＜ script type='text/javascript' src='script.js' ＞＜ /script ＞ ＜ img src="picture.jpg" alt="" width="640" height="480" ＞このような外部リソース読み込みについて、ファイル名の後ろにクエリー文字列を追加します。
＜ link rel="stylesheet" type="text/css" href="style.css?v=2.4.0" ＞ ＜ script type="text/javascript" src="script.js?v=2.4.0" ＞＜ /script ＞ ＜ img src="picture.jpg?v=2.4.0" alt="" width="640" height="480" ＞スクリプトでない静的ファイルにクエリー文字列を付加しても、読み込まれるファイルは同じです。つまり、
style.cssとstyle.css?v=2.4.0は同じ style.css というファイルを指します。ブラウザーが style.css をキャッシュしている状態で、この行を読み込んだとします。
＜ link rel="stylesheet" type="text/css" href="style.css?v=2.4.0" ＞ブラウザーは「
style.css?v=2.4.0というファイルはキャッシュにない」と判断し、style.css?v=2.4.0 というファイルを読み込みます。結果として、ディスク上の style.css が読み込まれてスタイルシートが更新されます。この HTML をまた読み込んだ時は、「
style.css?v=2.4.0というファイルはキャッシュ済み」と判断し、ディスク上のファイルではなくキャッシュを利用します。ウェブアプリケーションをバージョン 2.5.0 にアップデートする時には、「
?v=2.4.0」の部分を「?v=2.5.0」に書き換えてリリースします。＜ link rel="stylesheet" type="text/css" href="style.css?v=2.5.0" ＞ ＜ script type="text/javascript" src="script.js?v=2.5.0" ＞＜ /script ＞ ＜ img src="picture.jpg?v=2.5.0" alt="" width="640" height="480" ＞同様の仕組みで、2.4.0 時代のキャッシュがあっても 2.5.0 用に書き換えられたファイルが読み込まれ、キャッシュの問題は起こりません。
この手法は、キャッシュ問題を解決する手段としては一般的に用いられているものです。俗に「キャッシュバスター (cachebuster)」とも呼ばれます。
数日経った日の午後。Y さんが A4 判数ページにもなる「調査報告書」を作成した。問題になっているスタイルシートについて前回リリース分と今回リリース予定分の差分を取り、それぞれの行について「新規」「変更」「削除」の印をつけ、「とりあえず、このクラス指定が効いていないだけなので、HTML 中にインラインスタイル(＜ div style="..." ＞)で指定すればよい」と結論づけていた。
報告書には「状況から見て、変更・削除されたスタイル指定は影響が出るらしい。新規に追加した部分については影響がないようだ」とも。私が書いた説明を読んでいないのか、理解できなかったのか。
この報告書を元に、X さんから「この行とこの行にインラインスタイルを指定してください。これで暫定対応とします」と指示が出た。
私は「この修正は何ら根本的な対策になっていないことは理解していますか。『現状で問題になっている箇所』は、この環境でたまたまそうなっているだけの話で、ほかのお客さまの環境では別の画面が崩れるかもしれないのです。それを承知の上で、これを暫定対応としてよいのですね」と X さんに確認。X さんは「はい」とだけ答えたので、黙って作業を完了した。Git のコミットメッセージに「この方法は何の効果もないこと、それでも作業をしてよいのかを X さんに確認の上、作業」と書いてコミットした。
しばらくすると X さんから「うまく表示されています。OK です」と報告があった。
夕方、私が帰ろうとすると、X さんが Y さんに「画面がおかしい」と言っている。横から覗くと、先ほど「暫定対応」とやらを入れた画面で、表示は正常だがボタンを押しても何の反応もない。私は静かに「JavaScript のキャッシュですね」。
聞けば、Y さんは「キャッシュはスタイルシートにだけ効く」と思い込んでいたらしい。やはり先の説明を読んでいないようだ。そして、Y さんの環境ではボタンは有効だったとも。
私は「Y さんの環境では(JavaScript の)古いキャッシュは効いていなかった。X さんのところではキャッシュが効いていた。これが、私が言っている『環境依存』の意味です。昼の暫定対応ではダメなんです。半月前から私が言っているように、すべての外部リソース読み込みにキャッシュバスターをつけないと解決にならないんです」と伝える。
Y さんは観念した様子で、「キャッシュバスターって、一部分にだけ適用することもできますか」と聞く。この人、理解してないなと思いつつ、「はい、できますよ」と返すと、「では、問題の発生している範囲を調査して、問題が起こっているファイルにだけキャッシュバスターを……」。やはり何も分かっていない。
私は繰り返し、ブラウザーのキャッシュは環境依存なのですべての外部リソース読み込みにキャッシュバスターを付加しないと無意味だと説明した上で、こう付け加えた。
「指示されたことだけを黙ってやっていれば、そりゃあそっちのほうがラクですよ。でも、喧嘩をしてでも、場の雰囲気を悪くしてでも自分の意見を主張するのは、技術者としてのちっぽけな良心からです。お願いですから、専門家の言うことを聞いてください。私の意見が信用ならないのでしたら、ほかの技術者に意見を聞いてください」
この数日後、本件の対応を先送りにすることが決まったと X さんから報告があった。
聞けば、リリースを急いでいるのは特定の顧客の要望によるものらしい。その顧客はスタンドアローンバージョンを利用しているので、アップデートの現地作業の際にブラウザーのキャッシュを消してくればいいとのこと。
リリースに間に合わない間に合わないとあれだけ騒いでいたのに。プロジェクト管理がまるでできていない。
そして今日の夕方、この件についてレビューを開きたいとプロジェクトマネージャーの V さんから言われる。レビューって、何をやればいいんだろう。何をすれば気が済むんだろう。Redmine に書いた説明を読んで理解してもらえれば、やるべきことはひとつしかないと分かろうものなのに。
X さんから質問を受ける。「例の件、ほかの方法はないんでしょうか。『こういう方法もあるけれど、工数が掛かるので採用しません』というのがもしあれば話が進めやすいかと」。残念ながらありません、せいぜいファイル名そのものを変更するくらいですが、本質的には同じことですし管理の手間が増大します、と伝えた。
ついでに、X さんに「あの説明を読んで、よく分からない部分があったら教えてください」と尋ねると、実は忙しくて斜め読みしかしていないと白状された。その状態で対応策を一生懸命協議していたのですな。
レビューの席でまた一悶着ありそうだ。どうやったら彼らを納得させられるのだろうか。信用できない技術者に説明してもらったって、信じないんだったら意味がないのにねえ。
文字数制限に引っかかってしまい、末尾が切れてしまっていました。続きはこちらに書きました。
退職者が「会社で何らかの『システム』を入れないから、これで作るしかない」といってVBAで作っていた。
一時は社内規定の残業上限に達するほどに、「夢中」で作っていた。
が、退職後3ヶ月、あるマクロの書き出すデータに致命的な問題が判明し、私が一部、使用停止を宣言した。
基幹系へ投入するデータが特定条件で確実に狂うのである、それも何ヶ月にも渡って誰も気づかなかった。
当該マクロでのデータ処理を禁止し、1年と少しぐらい、現業部が手作業でエクセルデータを作成していたと思う。
ろくに解説サイトも見ないでVBEでコードをこねくり回して作っていたのだと思う。
もしかすると、解説サイトや書籍の内容が理解できなかったのではないか、とすら思う。
Dim da as String da = "データ" Dim after as String after = "修正済" '---------------------------------------------- With ThisWorkbook.Worksheets(after) .Cells(i, 1).Value = ThisWorkbook.Worksheets(da).Cells(i, 1).Value .Cells(i, 2).Value = ThisWorkbook.Worksheets(da).Cells(i, 2).Value .Cells(i, 3).Value = ThisWorkbook.Worksheets(da).Cells(i, 3).Value .Cells(i, 4).Value = ThisWorkbook.Worksheets(da).Cells(i, 4).Value End with
シートをまたいで、ただ値をコピーして集計していく程度の内容であるが、Workbook/Worksheetの呼出が理解できていないのだと思う。
また、変数はワークシート名を格納する程度にしか使っていない。
シートの見出しも「修正決定○○数」という、一体、何の数量なのか理解に苦しむ見出しである。
使える制御構文はFor Nextだけらしく、Do WhileやFor Eachもなく、果てはLike構文すら見たことがない。
その人が退職して直ぐ後のミーティングで、自部署の担当役員がレジュメにこう書いていた
「努力は夢中に勝てない」
退職者も「夢中」で書いていたのだろうか。
最初はその日の気分とかを一行二行書き殴ってハイおしまい、といったような使い方だったが、そんな駄文以下の文字列にでもコメントをくれる人がいるもんで、コメントをもらうと嬉しくなってくるのが人情である。扇動による木登り速度が豚よりも速いと評判の俺はすぐさま調子に乗って色々書き始めた。
だが、俺自身にはさしたるバックグラウンドがない。名家の出身だとか、幼少期に大事件に巻き込まれたとか、大病を患ったとか、同級生にスゴいやつがいたとか、猛勉強して東大に入ったとか、その手の「他人とはちょっと違う体験」などが、圧倒的に無かった。
そうなると自分語りのネタなぞ三日やそこらで尽きる。かと言って創作増田を書けるような文才もなく、「〇〇と言えば」系のお題も思い浮かばない。そもそも他人が下着のことをパンツと呼ぼうがパンティーと呼ぼうがどうでもいい。
だが承認欲求は満たしたい。そんな浅薄な俺が選んだのは「自作自演」だった。互助会も魅力的だったが、いちいち他人のブログをチェックしてコメントを残さないといけないと知って止めた。
俺が増田を投稿する。その増田に俺が返信をつける。さらにその増田に俺が返信をつける。そんな事を繰り返していくと、ブコメやスターがチラホラとつく。「おああーーーっ。あーっ。いけない。いけないやつだこれ。」などとコメントするだけで800以上のスターをもぎ取っていく大物ブックマーカーからすれば、俺の自作自演につくスターやブコメはまさに塵芥に等しかった。自作自演してその程度だったが、それでも俺は結構満足していた。
変化があったのは先週だ。いつものようにクソ下らないやりとりを増田で自作自演していた俺のスレッドに、全く関係ないやつが割り込んできたのだ。
はた目から見れば、おかしいことなど特にないように見える。だが、そのスレッドのアホみたいなやりとりをしているのは、俺と、誰かも分からない奴の二人だけなのだ。しかも俺の書き込みが大半を占める中、「俺ではない何者か」の書き込みは1件だけ。
例で言うと、ちょっと前に「零戦が飛ぶのが不快」っていうホッテントリがあったと思うが、あの長いやり取りをしているのは9割俺で、たったひとつの書き込みだけ「俺ではない何者か」っていう状態である。
いや、確かに今までも自作自演エントリ中に俺以外の奴が書き込んでくる事はあった。ただ、今回の書き込みは、何と言うか、その・・・俺のことを知っているんじゃないかと言うか、見られてるんじゃないかと言うか、自作自演がバレてるんじゃないかと言うか・・・。単純に言えば、気味が悪かった。シュタインズゲートってゲームの中で、主人公がいきなり「お前を見ているぞ」ってメールを受信する場面があるが、今俺が抱いている感情はあの場面に近い。
この前の土日は、「えっ、もしかして自作自演ってバレてる？って言うか、俺の個人情報漏れてる？って言うか、俺の住所知ってる？」などの考えが脳裏をよぎりつつ、不安と恐怖に苛まれながら週末を過ごしていた。
そういう事を考えているうちに、ひとつの映画が思い浮かんだ。表題にある「トゥルーマンショー」だ。この映画を知らない人向けに簡単に説明すると、映画セットの中で何も知らずに暮らしている男の話だ。男は普通に人生を謳歌しているが、実は無数の監視カメラで24時間撮影され続けており、その様子は全国放送されている。家も、街も、友人も、妻さえもすべてが造り物であり、男だけがその真実を知らない。
映画の続きが気になる方は直接本編を見てもらうとして、ここでは俺の抱いている不安の話だ。一瞬でも「もしかすると、はてな匿名ダイアリーにまじめに投稿しているのは俺だけで、俺以外の増田は全部はてな運営が書いている」「俺の個人情報は全国に晒されていて、俺が増田に投稿すると通知が飛ぶ」「それを見た一般大衆は『またクセエ自作自演してるな』とニヤつきながらスマホやディスプレイを眺める」といった場面を想像してしまうと、もう脳裏にこびりついてしまって振り払う事ができない。
少し前の俺なら、「そんな事あるわけねえだろ」とタカを括っていられたが、あのエントリが、あのコメントが、あの増田が、俺を呪縛から解き放ってくれない。あれは絶対に俺の事を知っている奴にしか書けないコメントだ。
昨日は会社のPCで仕事そっちのけで「増田 正体」「はてな 自作自演」とかのキーワードで検索していた。だが、俺の知りたいような情報は一切ヒットしなかった。当たり前だ。このPCも監視されていて、俺に都合の悪い情報は遮断されているに決まっている。昼休みに、同僚にスマホを借りて同じようなワードで検索してみた。こっちでもヒットしなかった。クソ、手が込んでるな。だが俺は見た。俺が「スマホを貸してくれ」といった時の同僚の怪訝な顔を。いけしゃあしゃあと「いいけど、何に使うの？」等とのたまっていたが、お前のその怪訝な表情は一切隠せてないからな。しかし今思えば、あれは失敗だった。俺が世界の謎に気付いているという無用な情報を渡してしまっただけではないのか。いや、どうせPCの検索履歴から過去の女性経験から全部赤裸々になっているんだ、今更引き返せない。
決意して、上司のLINEに「申し訳ありませんが、本日より2日～3日程度有休を頂きたいのですが、よろしいでしょうか」と送ったのがついさっきだ。上司からは「えらく急だね。いいよ、了解」というすっとぼけた返信が届いたが、そんな態度でいられるのも今のうちだからな。俺は必ず世界の真理、人類の根源、至るべき場所に到達してやるからな。これはこの増田を見ているお前たちへの宣戦布告でもある。首を洗って待っていろ。
書いている人が20歳以下だと思って書かせてもらうけど、
どの業界で働きたいのか、働いた時の自分を想像すると手が動かしやすいかなーと。
たとえばロボットだったり自動車だったり飛行機だったり、機械の中の制御部分をプログラミングでやりたいのであれば
CやC++、Web系でサービス開発がしたいなら…というように。ここは将来何がやりたいかを考えたほうが思いつきやすい。
例として、インターネットでサービスを展開している企業で働いている自分を想像する。リーダーから与えられたタスクを消化するため
Git/GitHubを使って進捗管理、統合開発環境・テキストエディタを立ち上げ、□□言語で書かれた○○の部分を弄る。実際に本番環境で立ち上がるか云々…。
□□や○○の部分はまだ分からないかもしれないけど、Git/GitHubや統合開発環境、テキストエディタはプログラミングする時に必要なので
ここは極めても良いはず。だから勉強する題材になる。もし、既にこの□□言語の部分が具体的に出てきて、Web系で働くんだという気持ちがあるならその言語を極めれば良い。
ちなみに、文章から文字列を抽出したい場合、正規表現についても知っておくと武器になるぞ。正規表現を扱いやすいプログラミング言語についても調べてみると良いと思う。
でも独学のやり方が分からない。
プログラミングができる人にプログラミングの始め方を聞くと「何が作りたい？」と聞かれる。
僕はプログラミングで何が出来て何が出来ないのか知らない。パソコンで動いているものは全てプログラムで動いているのは分かるが想像がつかない。
今日はwhile文とif文を使って文字列から文字を探す方法を学んだ。
方法を学んだ僕はJ-POPの歌詞から”愛”を探すプログラミングをすることが出来るようになった。
26文字あった。
何が出来るのかを知ったことで僕はプログラミングをすることができた。
確かに問題を出されるより何が作りたいか分かったほうがプログラミングをする気になれるのではないかと思う。でもプログラミングで何が出来るのか分からない。
箸が使えるようになりたいから箸が使える人に訪ねたら「何が食べたい？」と聞かれた気分だと思う。
プログラミングが出来る人は何かを作りたくてプログラミングが出来るようになったのだと思う。
今の時代には技術が溢れすぎていて僕はプログラミングをするまでもなく既存のツールの組み合わせで何かを作りたい欲求に応えることが出来ていた。
お箸も必要に迫られて正しい持ち方を学ぼうとする人がいる。そんな気分に似た動機が僕がプログラミングをしたい理由だ。
もっと聞こえを良くすることもできたが考えを巡らせていると結局そこへ行き着いてしまう。
僕と同じようにプログラミングがしたいけど何からすればいいのか分からない人が周囲に沢山いる。同じ者同士惹かれ合うのかその様は死屍累々だ。
僕がプログラミングを出来るようになればそういう人達になんて言うのだろう。
「何が作りたい？」
人は読書から何かを得るという。知識や情緒、技術。それらを自分の糧にして、自分を高めていく。
でも僕はそうではなかった。僕はたくさんの本を読んだ。親が教育熱心で、幼い僕に積極的に読み聞かせをしてくれた。文字を読むことに一瞬楽しみを覚えた。周囲からは本の虫といわれた（気がする）。というか、本を読んでいると親が喜んだ。周りは天才扱いした。もてはやされて、楽だった。
ニート生活を経て気づいた。僕が文章を読んでも、それは一時僕の中をかすめるだけで何物にもならない。文字列が透明なフィルターを通り過ぎていくだけ。小説でもドキュメンタリーでも漫画でも図鑑でも論文でも2ちゃんでもツイッターでもなんでもいい。それらが僕の中に入ったところで起こることはいつも同じだから。読んだところで何も起きない。その証拠に、こんなにも文章が下手だ。いい年にもなって僕はまるで透明で箸にも棒にも掛からぬ人間だ。身近な人間、社会、その他諸々ぜーんぶどうでもいい。
ちなみに上の文章の「読書」は声楽、勉強、ピアノ、チェロ、バスケに置き換え可能
確かに僕はかなり恵まれてる。経済的に困窮したこともないしたぶんこれからもそんなことはないだろう。それでもどこかむなしくて、つらい。
とても陳腐で滑稽だ。つまらない文章、つまらない人間。自分で何かを考える能力がまるでない。
今時BASP21 DLL（フリー版）でメール受信してどうのこうので困ってる人が世の中にどのくらいいるかどうかわからないけど、今日嵌ってググってもまともな答えが出てこなくて途方にくれたのでポイントをメモっておく。
BASP21 DLLのRcvMailメソッドでPOP3サーバから受信してReadMailメソッドでメールの内容を取得すると、一部のメールが送信者や添付ファイル名が文字化けして正常に取得できない。これはBASP21 DLLのReadMailメソッドが最近普通に送信されるUTF-8のメールに対応していないため。
RcvMailで受信したファイルをReadMailで読み込む前に直接開き、Base64エンコードされたUTF-8の文字があったらデコードしてJISに変換してBase64エンコードして保存する。その処理したファイルをReadMailで取り扱うようにする。全部BASP21の機能でできる。
BASP21のKconvメソッドの第１引数のinstrに文字列を渡せるのはUnicode UCS-2のみの場合だけらしく、UTF-8の文字列を渡しても正常に動作しない。なので、一旦テンポラリファイルに書き出しKconvFileメソッドを使用して変換を行う必要がある。っていまドキュメント眺めてたら文字列をバイト配列にするByteArrayというメソッドがあるみたいなのでこれをを使えばできるかもしれない。けどもう正直いじりたくないよ…。
人工知能学会から返って来た人工知能研究者。例の論文の著者の１人とも知合で今回もご挨拶した。家族に文系研究者あり。
多分理解されていないところをいくつか書く。
これは工学の論文なので、あくまで分析の対象はフィルタリング手法であり、小説は手法に入力するデータに過ぎない。
文学研究と異なり、小説の内容については評価を下していない。あくまで、データにどういう文字列が含まれていると、手法がどういう影響をうけるのかについて分析しているだけ、という立場だ。
分析の対象は手法であって小説ではない。だからこそ、「有害」という内容について評価を下しているかのような表現が不適切なのだと思う。
人工知能学会全国大会論文は査読なしだ。これは、人工知能学会だけが問題なのではなく、情報系の大部分の国内学会は査読なしである。
ただ、その理由が「本会議でボコボコにして論文で落とせばいい」としているのが、こちらからみると不思議だ。査読付き論文も同じ国内学会に出すことを前提に書かれているかのようだ。
この分野における研究者の業績評価に用いられるのは国内学会ではない。
AAAI,IJCAIなどのトップカンファレンスと言われる、重要な査読付き国際会議にどれぐらい通したかで研究者の業績が決まる。
つまり、英語に直さないと、そもそも、業績になどならない。ダメな論文は、国際的に評価されないだろう…と思っているから、あまり関心がないのだ。
今回の人工知能学会も、多くの論文が、今年、同内容でどこか良い査読付き国際会議に投稿された英語論文の原稿を、日本語に翻訳したものだ。
国内学会を査読なしにしているのは、多様な論文を受け入れる意味もあるが、一番の理由は、査読者を確保する事が難しいからだろう。
査読者になるのは国際的に活躍するトップの優秀な研究者たちだ。彼らの時間を、国内学会の論文の査読などに使わせてしまっては、国際競争力が落ちる。
ただ、一応、賞を出す制度があるので、全論文に対し、誰かが読んで評価はしている。
そういうわけで、全国大会で発表することに大した業績的意義がないので、学生も普通に発表する。
企業研究者も全国大会に大勢来ているので、優秀な学生が入ればインターンに呼んだり就職勧誘したりする。
多分、今回問題になったのは、ここだろう。人工知能学会は、全論文PDFを一般公開してしまう。
このあたりの対応は、情報系でも、国内学会によってまちまちだ。昔は、CD-ROMを配るだけで、CD-ROMを持っていないと論文が見られないなんて会議や、電話帳みたいな紙の予稿集を配っていた会議もある。
「うっ...どうやらおれはもうだめみたいだ。みんな、後は頼んだ...」
「ちょっと待ってください！」
「なんだ...おれはもう...」
「まだ引継ぎが終わっていませんよ」
「引継ぎ？」
「後任の方に対して残すべきドキュメントはどこにあるんですか？」
「ドキュメント」
「あなたがここまでどれだけ進捗したのか、それを管理しているガントチャートなりバーンダウンチャートなりはどこにあるのかと聞いているんです」
「ガントチャート」
「ないのであればPCを渡すので、その中にあるエクセルで作ってください。私のLet's Noteをお貸しします」
「お、おれはMac派なのに」
「Macだとエクセルとの相性が良くないんです。表計算からワイヤーフレーム作成、進捗管理まですべて行えるエクセルが使えないなんてMacは信用なりません。」
「あの、これなにをかけば」
「始まりの村を出発してから魔王を倒すまで、どういったスケジュールでいくつもりだったのか、もう後付けでいいのでスケジュールを引いてください。お客様とやり取りするためにドキュメントは絶対に必要です。ドキュメントがないと魔王討伐どころかソフトウェア開発も出来ませんよ。こんなの常識です。」
「えっと、この装備品一覧っていうシートは何をかけば」
「そこではあなたが今持っている装備を全て記して頂きます。ちゃんとIDをふってくださいね。」
「ID」
「IDをつける際にはお客様とのコミュニケーションで誤解が生じないようにあえてA-xxx-xxみたいにつけます。確かに番号にするとまるでわかりませんが、リモートコミュニケーションにおいて、例えばマサムネと言われた時にそれが武器なのか防具なのかわからないので、装備品定義書を用意してそれを確認しながらやり取りしたほうがいいんですよ。あえてコミュニケーションコストをあげることで証拠づくりをするんです。小規模なプロジェクトならわかりやすい文字列でもいいかもしれませんが、大規模プロジェクトになるとそうはいかないので、今のうちに意味不明なIDをつけられるようにしておきましょう。あ、ちゃんとIDと名称の対応表は作っておいてくださいね。あと、この資料は紙に出力するので罫線などは勿論しっかり整えてください。」
「...」
「あ、勇者がおなくなりに」
件の論文の著者のうち１名とは知り合いではあり、今回もご挨拶ぐらいはした関係である。
件の論文の話が大きくなり、文系研究者の方の記事も何件か出てきた。
https://srad.jp/~yasuoka/journal/612256/
http://mistclast.hatenablog.com/entry/2017/05/26/203043
http://d.hatena.ne.jp/font-da/20170526/1495783027
前置きするが、件の論文を正当化する意図は毛頭ない。とにかく、件の論文が不適切であった事は確かだと思う。
私は、家族に文系研究者がいるので、ある程度文系領域についても分かっているつもりである。
文系研究者の皆さんが、大きく勘違いしていると思われる点がひとつだけあるので、指摘しておきたい。
文系では、テクストそのものを研究対象とすることが通例であるので、今回挙げられた小説を「分析対象」や「研究対象」と思ってしまう傾向があるようだ。
しかし、工学の観点からは、今回挙げられた小説は、分析対象でも研究対象でもない。
工学は手法を論じる方法論であるので、分析や研究、そして評価の対象となるのは、あくまで、手法である。
小説の内容自体は、研究・分析・評価の対象ではない。小説の内容については評価しない。
極端に言えば、小説を単なるデータとしてみて、データの中にある文字列が含まれている場合に、手法がどのような振る舞いをするのかを観察しているだけである。
研究対象・分析対象・評価対象は手法である。小説は単なるデータだ。小説の内容については評価しない。
ただし、世の中には色々なテキストがあるので、そのような小説に書かれている表現が入力として与えられる可能性はある。
そういう場合に、「手法が」どのような振る舞いをするのかを観察し、「手法を」評価するのが、工学研究だ。
このように言うと、おそらく、「しかし、有害、という言葉を使っている時点で、小説に対して評価を下しているではないか」という反論が返って来そうだ。
私が、今回の件で、非常に不適切であると思っているのは、まさに、このポイントだ。「有害」というような、内容を評価しているかのような表現は用いるべきではない。
例えば、「性的」といったような、内容に対する評価を含まない表現に置き換えるべきであったろう。
あるいは、有害図書の基準などの参考文献を引っ張ってきて、「その基準に照らせば有害に分類されるデータ」という体で小説を扱い、評価しているのは論文著者たちではないという事を明確にするべきであった。
繰り返しになるが、工学研究では、通常、研究対象は手法であり、今回の論文も、明らかにこのタイプの研究であると思う。
この論文は、「この小説がなぜ書かれたのか」「この小説が社会の中でどう位置づけられるか」といったような、小説自体を対象とする研究ではない。
追記：
「「わいせつ」といったような、内容に対する評価を含まない表現」に引っかかってる人が多いみたい。「わいせつ」自体が「有害」同様に、評価を含んだ言葉だという点は、確かにそうかもしれない。上記の論旨とズレていて申し訳なかった。
まぁ、件の表現が「わいせつではない」と判断するのは、社会通念上難しいと思うが…？
まぁ、「わいせつ」という言葉が問題なのだとしても、論旨は同じ。私の言いたいことは、件の表現をクラス分けする工学的手法が主たる関心なのだから、別に、「表現001」でも何でも、クラスにテキトーな名前をつけて、クラス分けすることが主たる関心であると分かるように書くべきであったということ。
どういう名前でクラス分けしようと、自動的にクラス分けしたい場合がある事そのものは否定できないと思いますよ。
「自動的にクラス分けしたい場合があると著者たちが思っていること」そのものが意見である、という見方もできるとは思いますが、今回のケースについては、類似研究がたくさんあるので、自動的にクラス分けしたいニーズの存在は否定することが難しいのでは。
とりあえず、当該表現は「わいせつ」ではなく、ブコメにあった「性的」としておきますね。小説に出てきたような表現が性的であることは明らかだと思いますので（そうではないという反論もあると思いますけど）。
あと、これ。 id:aoi-sora 「人工知能研究者は、事実と意見の区別すらできないのか。」まぁ、当該小説の表現が「わいせつ」には該当するだろうと思ってしまったのは私の落ち度だったけど、それ１つを持って、人工知能研究者全体を語られるのは困るなぁ。あなたこそ、そんな過度な一般化をして、事実と意見の峻別が出来ないのか…と思います。木下是雄の当該本も読んでいますよ。
id:type-100 環境の話とは話が違うんじゃないですかね。そもそも、今回の論文は、pixivという環境については何も直接の介入は行っていないわけですし。これが、研究のために、例えば、「意図的にpixivに作品を批判するようなコメントを書いて作者の様子を見た」みたいな話だったら、おっしゃるような問題と類似するケースになると思いますけど。
