「これがしたい!」ではなく「これになる!」の学校教育のまずさ
なにがしたいですか?世界を作ります!djannです。
誰もが一度は「将来の夢」を聞かれたことがあるだろう。小学校の授業でもおそらく書いただろうし、卒業する時にも書かされたと思う。よく卒業アルバムにそれぞれの将来の夢が載せられている写真を見るだろう。
しかし、将来の夢とは果たしてその様なものなのだろうか?無邪気に将来の夢として挙げたものが、その人の将来を狭めているのではないだろうか?
問題点として、将来の夢として聞かれるとき、必ず「現在存在する職業」で答えているところが挙げられる。
せいと「将来は宇宙を飛び回りたいです!」
せんせ「うんうん、せいと君は『宇宙飛行士』になりたいんだね!大きな夢だなぁ~」
このようなやり取りがあった時、せいと君は本当に「宇宙飛行士」になりたかったのだろうか?生身で宇宙を飛び回るような、そんな「なにか」をイメージしていた可能性はないだろうか?
仮にそうだった場合、せんせはせいと君が将来起こすはずだったイノベーションを、この不用意な発言で無くしてしまったこととなる。
せいと君はおそらく
「そっかー、ぼくがやりたいことは宇宙飛行士なんだー」
と枠を決め、「宇宙飛行士になるために」勉強し、身体を鍛え、立派な宇宙飛行士になるだろう。それはきっと、子どもの頃からの夢を叶えた素晴らしい人物として社会に認識されるはずだ。
だが、彼は決して「人間が生身で宇宙を飛び回れるような発明」を行う事はない。せんせの一言により、無限の可能性は有限の可能性に成り下がってしまっている。
こういった「カテゴライズ」というのは、確かに先生も分かりやすいし、他の人も分かりやすい。おそらく学校教育以外の現場でも「これは〇〇だ」という形で行われていることだろう。
しかし果たしてそれは常に行うべきことだろうか?
人間は往々にして「これはこうである」と一度定義したものに対して、違った考えを受け入れられないものだ。蟻塚の例を考えると分かりやすいだろう。
「蟻塚の中はこんな過酷な環境なのに快適らしい。」
「調べなければ」
「蟻塚の中はこういった構造になっているに違いない。」
「確かにそれなら説明が付く。では下に外気を取り入れる穴があるんだな。」
現実には、一定の方向で風が吹き続けることなど有り得ず、蟻塚の構造も長らく勘違いされたまま「蟻塚の構造を参考にした建築物」が作られている。が、現実にはほぼ間違っていたのだ。
カテゴライズは、現実の一般サラリーマンが仕事をする上では有用だろう。名付けることによりコンセンサスを得、それによって情報を伝達するコストを削減する。
しかし無限の可能性を持つはずの子どもたちを相手にする学校教育の現場でカテゴライズを行うことは、存在したはずの可能性を消滅させるような行動に思えてならない。
ゲーム開発者よ、Coinhiveで稼げ
金はすべてに勝る。djannです。
Coinhiveライクなシステムをゲームに仕込み、その上で無料で提供する収益化手法を世のゲーム開発者に提案したい。
あなたのゲームを好きになり、長時間遊んでくれればくれるほど、あなたには収益が入る。
さて、近頃IT業界が賑やかだ。
技術的に程度の低いサイバー警察へ強制捜査を受けたというような話があったり話(勘違いで簡単に人権侵害が行われるのは危険だ)
そしてあのうっとうしい広告に代わる収益化手法として産まれたCoinhive(コインハイブ)を用いたWebページの提供者が、合同捜査本部まで立てられ一斉検挙されたという。
サイバー警察の能力向上を願う、またCoinhiveのような新たな技術や発想をどうか潰して萎縮させてくれるなという陳情書や裁判は、是非とも光明を見出だしてほしいし、応援したい。
しかして、結果が出るまで現状のままうっとうしい広告を出し続ける、はたまた収益化を諦めるというのは発展への機会損失となり非常に痛い。
では、今でもそういった、演算資源を間借りしたマイニングを行うのに適した環境は無いものだろうか?
思うに、Webページだけでなくゲームも多くの無料の作品が世に提供されており、広告による収益化を望むといった、似た土壌が形成されている。
Webページとの違いとして、ゲームの場合はそのコンテンツを享受する前には企業ロゴや各種警告などが表示されることは一般的だ。そこに「マイニングを行う」と一文を入れることが出来る。これならばCoinhiveの争点となっている「ユーザの意図しない動作」にはならないだろう。
警告だけで不十分というのならば、インストール時に許諾要項を出し、合意を取ることも出来る。
また、ゲームは多くの演算資源を使うことが事前に予測されており、しかしVsyncや各オブジェクトの同期などで完全に100%の演算資源を使わず待ちを行う場面も多い。
一番は、ゲームはある程度の時間継続して起動し続けてくれるだろう。ちょっとした内容を読んだら他へ移動するWebページより、より収益が見込めるはずだ(誤差レベルだろうが)。
そして、少なくともWebページよりは悪意の改竄による影響範囲が狭まると思われるので、ターゲットにもされにくく少なくとも意図しない悪意へ収益を与えてしまう嫌悪感も軽減できるのではないだろうか?
以上の理由が、Coinhiveライクなシステムをゲームに仕込み、その上で無料で提供する収益化手法を世のゲーム開発者に提案する根拠だ。
繰り返しになるが、あなたのゲームを好きになり、長時間遊んでくれればくれるほど、あなたには収益が入る。
ユーザにとっても、ユーザが遊べば遊ぶほど収益になるという考えが一般的になれば、即時的にガチャでお金にするのではなく、より面白いものを作ることに開発者が力を注いでくれるようになるだろう。
これはとてもよいことだ。開発者はより面白くすればするほど稼ぐことができ、ユーザは札束で叩くゲームから解放される。ちょっとした演算資源の間借りさえ許せば、そんなゲームのユートピアが我々を待っている。
そして、ゲームによる演算資源を間借りしたマイニングが広く行われるようになれば、Webページでもマイニングが行われることが「社会的なコンセンサスが取られていない」ということにはならなくなるかもしれない。
汝、自らを救うべからず
私は誰からも救われない・・・djannです。
さて、突然だが自力救済(じりょくきゅうさい)という言葉をご存知だろうか?
言葉の通り、自らの力で救うという意味であり、例を挙げるとするならば
「あいつに貸したゲームが返ってこない。何度も何度も持って来いと言ったにも関わらずあいつは持ってこないんだ。なので、あいつの家に遊びに行った時に持って帰った。」
というような行為を指す。自らの不利益を自らの力、行動で解消する行為だ。
さて、この場合例えば、相手がゲームを盗られたと訴えたとしよう。そうすると一般的な感情的には何も悪くない、もう何も怖くないはずだが、実はこれは違法な行いとなってしまう。
現代社会(日本のみとは限らない)では、司法の介さぬところで自らの手で不利益を解消する行為は「自力救済」として、明確に認められない行為となっているのだ。
原理的には、それがまかり通るのであれば、この世の中は「物理的な力」が全てとなってしまいまた、自力救済を手助けするような団体が世の支配権を得てしまうからだ。
もちろんそんなことになっては、逆に生きづらい世の中になってしまうのは目に見えている、故に自力救済は禁じられている。
が、小さな諍いに逐一司法を介入させることが難しいのもまた現実、はてさて結局厚顔無恥な居直りがこの世の中、一番強いと言う事だ。
Clang for Windows 3.7を入れた
サナ・・・実は俺、お前のことを・・・djannです。
毎回恒例とも言えるようになったClang for Windowsの更新レビューである。といってもClang 3.7が出たのは2015年9月となるので、ずいぶん間が空いてのこととなる。
さて、インストール手順はいつもの通り*1だ。前回と同じく、コード中のリテラルを変更ビルドを行っても、実行ファイル中での定数は変わっていないバグ(?)はそのままのようである。
個人的にReleaseNotes中でのトピックスだと思ったのは、例外に対して一部対応が行われた事だろう。相変わらず自身でtry - catch等を書くことは出来ないが、従来のように
#define _HAS_EXCEPTIONS (0)
を定義してからC++ヘッダをインクルードしなければならないといった制限は無くなった。またVisual Studio 2015上でchar16_t/char32_tの取り扱いが変わったことによる自作型の定義も不必要となっている。
故に、今回のバージョンから「例外機構は例外として、それ以外はインストールが終われば特別気にすることなくC++のコードが書ける」ようになったと言えるだろう。もちろん標準ライブラリはそのVisual Studioで実装済みのものに限定されるが、その他言語機能はClangで最新の実装済みのものが使用可能である。
例外に関しては、ReleaseNotes中で明示的に「しばらくはサポートされない」と書かれているので、そういうことなのだろう。では例外以前にリテラルの書き換え等の軽微なコード変更が反映されないバグの修正を願っておこう。また、修正されないことも考えてOSS界隈への参入方法もこっそりと調べておこう。
Clang for Windows 3.6.2を入れた
そう・・・あなたの為のClangよ・・・。djannです。
今更になるが、このブログ中で一番役に立っているともっぱらの噂のClang for Windows系の記事の最新版を記述する。なお3.6.2自体は7月16日に既にリリースされていたらしい。
と言っても、今回入れたことによって何が変わったかは、ほぼ分かっていない。リテラルを書き換えてビルドしても、変更された結果が反映されていないバグもそのままだし#define _HAS_EXCEPTIONS (0)を先に定義しなければC++の標準ライブラリをインクルード出来ない*1のもそのまま、変数の値をウォッチ出来ないのもそのままだ。
強いて大きな変化を挙げるとするならば、Visual Studio 2015が公開されているので、そちらに対応が行われたのだろうということくらいだ(前から対応されてた?)
という訳で、早速いつもの手順*2でインストールを行い、その使用感を試している。Visual Studio 2012、Visual Studio 2013に関しては、パッと見は*3本当にアップデートをしたのか?というほど何も変わっていない。今までのプロジェクトもそのまま全く同じように(バグまで)ビルド出来るし、新しく作ってからの手順も変わっていない。ひとまず以下のようにハローワールドだ。
#define _HAS_EXCEPTIONS (0) #include <iostream> int main() { std::cout << "Hello, New LLVM world!!" << std::endl; }
さて、では肝心のVisual Studio 2015ではどうなのかというと、現状のところどうしようもない。まずかわいいバグとして、以下のようにPlatform Toolsetでの選択肢がLLVM-vs2014となっている。おかしいな、これはVisual Studio 2015だったと思ったのだが。
さて、早速ビルドしたところ、以下のエラーが大量に出る羽目になってしまった。
use of undeclared identifier 'char16_t' use of undeclared identifier 'char32_t'
単純にVisual Studio上のコードハイライトを見てみるだけでも、従来char16_tやchar32_tはtypedefされていたものが、どうやら組み込みの型になったらしい。
int main() { char16_t a; // error : unknown type name 'char16_t' }
そして上記コードの通り、Clang for Windows 3.6.2ではchar16_tは組み込みの型として存在せず、結果エラーとなるようだ。そして性質の悪いことに(当たり前だが)、これらcharXX_t型は標準ライブラリ各所で特殊化に指定されており、C++標準ライブラリを用いようとすれば、すぐさま大量のエラーを吐いてくれる。
では型定義をしたらどうか?
using char16_t = short; using char32_t = long; #include <iostream> int main() // 以下略.
shortやlongに対する特殊化を再定義したことになり、これもエラーだ。では新たな型を作ってはどうか?
これは整数値への変換と受け取りが可能な型を作成すればいける。ただし標準ライブラリの挙動が正しいままかどうか、その他もろもろの検証が必要になるだろう。とりあえずビルドを通すだけの適当な定義は以下の通りとなる。LLVM-vs2015で(いや2014だったか)最小限のHello, Worldプログラムは以下の通りだ。
struct char16_t { short elem; constexpr char16_t() : elem(0) {} constexpr char16_t(int val) : elem(val) { } operator int() const { return elem; } operator unsigned int() const { return elem; } operator short() const { return elem; } operator unsigned short() const { return elem; } operator long() const { return elem; } operator unsigned long() const { return elem; } }; struct char32_t{ int elem; constexpr char32_t() : elem(0) {} constexpr char32_t(int val) : elem(val) {} operator int() const { return elem; } operator unsigned int() const { return elem; } operator short() const { return elem; } operator unsigned short() const { return elem; } operator long() const { return elem; } operator unsigned long() const { return elem; } }; #define _HAS_EXCEPTIONS (0) #include <iostream> int main() { std::cout << "Hello, New LLVM World!!" << std::endl; std::cin.get(); }
というわけで、長々と書いたが現状Visual Studio 2015でLLVM-vs2014を使ってビルドするのは使い物にならない。流石にここまでして使う意味はないだろう。大丈夫だ、Visual Studio 2013があれば戦える。ドラゴンボールがあればry
回を重ねるごとに雑になってきている気がするが、今回の記事は以上となる。
相変わらず彼は規格に詳しくない
こういう決まりですので。djannです。
相変わらずの規格上の疑問である。ポインタ型からboolへの変換は、規格上認められた動作で、暗黙的に行えるという認識だったのだが、これは正しくはないのだろうか?
Visual Studio 2015で以下のコードをコンパイルすると警告が出る。
class foo { int *m_ptr; explicit operator bool() { return m_ptr; } };
'int *': forcing value to bool 'true' or 'false'
int*をtrueまたはfalseのbool型に強制する。それのどこが問題なのだろうか?nullptrであればfalseに、そうでなければtrueに変換されることを明確に期待しているのだが、規格上正しくないのだろうか?
こちらが該当しそうな気がしていたのだが
4.12 Boolean conversions
1 A prvalue of arithmetic, unscoped enumeration, pointer, or pointer to member type can be converted to a prvalue of type bool. A zero value, null pointer value, or null member pointer value is converted to false; any other value is converted to true.
Visual Studio 2015 Community入れた
まだまだ関係は続いていく。djannです。
先日正式公開されたVisual Studio 2015を入れた。前回の記事でもこっそりと2015を使っていると書いているが、公開翌日にインストールしている。
さて、このVisual Studio 2015だが、私自身は特別何の問題もなく入れられ、使用出来た。だが会社の者や知人はインストールしてもC++が使えなかったりと言った問題があったらしいので注意すべし。
ちなみに私はインストール時にカスタムインストールで、常にすべての項目を選択してインストールする事にしているので、もしかしたらそれが要因なのかもしれない。
Visual Studio 2013からだが、Productivity Power Toolsを入れなくても標準でスクロールバーのマップモードが入った。だが選択したキーワード、検索キーワードの位置がソース中のどこにあるか表示してくれる機能(下記画像参照)の、色変更設定がどこで行えるのか、そもそも行えないのかが不明となっている。知っている人がいれば教えてほしい。