読者です 読者をやめる 読者になる 読者になる

自己言及器官

プログラマーワナビー

劇場版『ハーモニー』 見てきた感想

評判なんとも言えない感じだったけど、せっかくなので初日にレイトショーで見てきました。
とりあえず気がついたところ

  • シュタウフェンベルク首席監察官の声がサイコパスの上司
  • 序盤、ところどころ3Dアニメでキャラクターの動きがぎこちないところがある
  • 街並みがすごくピンク
  • キアンの体系が異常に細いように見える(おそらく狙った演出だと思うが)
  • カプレーゼのシーンがめっちゃ血が出てる
  • 冴紀ケイタの髭が長い
  • オンラインセッションの画面がみんな白い
  • すばらしい新世界が燃えてる(書いたのはオルダス・ハクスリー ってセリフまで入れて欲しかった)

ここから真面目な感想

ラストのセリフの変更はやはりトァンの動機に関わるので変えてしまうべきではないと思う、ところどころ挿入されていたキスシーンとかよりも問題に見えた。
それにエピローグやetmlの解説を削ったのも問題、あれがあるから話が締まるのに。

あと、やはり虐殺器官より先に上映してしまったので原作未読の人にとっては設定が追いきれないと思う、
何故大災禍<メイルストロム>が起こったかとか、どうしてこういう世界が構築されたのかとか、オルタナ(副現実)の設定とかとかその他もろもろ。

個人的に残念な点としては
カフェイン関連が規制されてる描写とか二分間憎悪とか「ただの人間には興味がないの」とかそういうのが削られていたこと。 カフェイン飲料が不道徳なので、それを避けてみんな水を飲むようになってる描写でこの世界が極端な健康社会に移行してることや、二分間憎悪(元ネタは1984年)や「ただの人間には興味ないの」(元ネタは当然涼宮ハルヒの憂鬱)といった*1
私達が今生きている世界と地続きなことを示している描写が感じられていない、虐殺器官は色々なフィクションを引き合いに出していてそこがゾクッとさせてくれたんだけど、映画のハーモニーはウェルテル効果ぐらいでしかそういったシーンが無かった。

まとめ

原作ファンはいちおう見てもいいかもしれない、
もっと映画化しやすそうな虐殺器官に期待しましょう。(公開いつになるんや……)

*1:追記:「ただの人間には興味ないの」はあったという指摘を受けました

歌舞伎座.tech#8「C++初心者会」 でLTをした

大学でC++03を教わった私が、便利そうだと思ったC++11の新機能

www.slideshare.net

残念ながら5分に収まらず3分ほどオーバーしてしまった。
少し大学批判みたいな感じになってしまったが、学費高いし最新の機能を学びたいという気持ちがあった。

WindowsにおけるGitの導入 (書きかけ)

このドキュメントはGitの導入につまづいている友人のために書かれた。
目標はcommitとpushの使い方を覚え、彼の書いたコードをGitHubに上げられるようになるまでである。

Gitをインストール

  • まず、Git for Windowsをダウンロードする。
    Git for Windows
    環境変数関連の設定は Use Git from Git Bash Only で問題無し
    同様にUse OpenSSHも選択、改行コード関連はたぶんWindows-Styleでいいと思う。

インストールが終わったら、スタートメニューからGit Bashを起動、Git GUIも存在するが
CLIのGitを覚えた方が絶対良い。

絶対に知る必要のあるCLIの基礎的なコマンド

$ cd src # srcディレクトリに移動する
$ cd .. # 1つ上のディレクトリに移動する
$ ls # カレントディレクトリのリストを表示する
$ ls -a # カレントディレクトリのリストを隠しファイル・フォルダを含めて表示する
$ pwd # カレントディレクトリの場所を確認する

初期化

Git Bashからgitで管理したいフォルダにcdで移動する、大抵は管理する対象はソースコードだが
テキストであれば何でも差分で管理できる(バイナリは向いていない)
移動した後

$ git init

でgitを初期化できる。 さらにあなたがやるべきことはGitに自分が何者か教えることだ、つまり自分のユーザーネームとメールアドレスを設定することである。

$ git config --global user.name AIUEO
$ git config --global user.email AIUEO@example.com

とすると設定できる、もちろんAIUEOやAIUEO@example.comは自分が設定したい物に置き換えて設定する。

Initial Commit

まずは何か一つファイルを管理してみよう、管理したいファイルが例えば start.javaならこうだ。

$ git add start.java

もしもカレントディレクトリ以下のファイルをすべて管理対象にしたい場合はこうする。

$ git add .

コミットするにはこうだ。

$ git commit -m "Initial Commit"

-m 以下のオプションはコミットメッセージである。こう書くと"Initial Commit"がそのコミットのメッセージになる。 このコミットではstart.javaをコミットしたとする。この後start.javaの開発を進めて内容が変更したとする、この変更を記録するには同様に

$ git add start.java
$ git commit -m "開発をすすめた"

とすると変更を記録できる。
ここでコミットのログを見てみたいとする、そうするには

$ git log

とするとコミットログが表示される。例えばこうだ

commit 41e90963f04ffc8d88e7dd97e7a7f5d82d6fb36e
Author: tSURooT <XXXXXX@example.com>
Date:   Sun Jan 4 22:38:40 2015 +0900

    開発をすすめた

commit 32568aebff5f6f07f530217cfc5a7e6d6d58190d
Author: tSURooT <XXXXXX@example.com>
Date:   Sun Jan 4 22:27:48 2015 +0900

    Initial Commit

とりあえず自分の書いたコードをGitHubにあげたい時

まずGitHubから上げるためのリポジトリを作成する。
GitHubにログインし、右上の"+"のアイコンから"New repository"を選択、 Repository name、Descriptionを書く。
すでにGitで管理しているリポジトリを上げる場合、"Initialize this repository with a README"や"Add .gitignore"や"Add a license"はチェックをつけなかったり、Noneを選択すると楽だろう。(上げる際に衝突しないように)
ここではすでにGitHubにあげたいリポジトリを持っていることを想定する、 まずリポジトリのディレクトリに移動し、

$ git remote -v

とすると、リモートのリポジトリの登録が見れる おそらく何も登録されていないので何も出力されていないはずだ。
ここでリモートのリポジトリを登録するには

$ git remote add [shortname] [url]

とする、さきほどあなたはGitHubで空のリポジトリを作成したはずである。なのでこの空のリポジトリを登録しようと思う。
この作成空のリポジトリのURLが"https://github.com/tSU-RooT/test" だったなら(Repository nameとURLの最後は同じになる。)
[url]には https://github.com/tSU-RooT/test が入る。[shortname]にはoriginと入れるといいだろう。これは初歩の段階ではおまじないだと思って良い。
さてあなたの書いたコードをGitHubに上げるにはこの後、pushすれば良い。pushするには

$ git origin master

とする。これはoriginと名前をつけたリモートのmasterブランチに対して、今いるブランチをpushするという意味だが今理解する必要はないだろう。
このコマンドを打った後、おそらくGitHubからパスワードの入力を求められると思う。あなたがGitHubに公開鍵を登録していればこの手間は必要ないのでこの方法は後述する。
さてこのpushに成功すればあなたのGitHub上のリポジトリにコードが上がっているはずだ、確認してみよう。

GitHubに上げる場合の注意点

GitHubの公開リポジトリに上げたコードは全世界に公開されるし、forkする権利が公衆に開かれることになる。
もし自分のコードが公開したくないならGitHubには上げないほうが良い。
非公開リポジトリの作成は有料会員になる必要がある。

公開するコードのライセンスについて

基本的にあなたが書いたコードには著作権が存在するので、それを公開する際には できるかぎりライセンスを設定するのが望ましい(ライセンスを設定しないとGitHubの規約によってforkだけはできるものの、誰も改造したり再配布することができなくなってしまう)
ライセンスの選択と詳細についてはこういった物を読むと良い
Qiita:ライセンスの選択を恐れる必要はありません
さまざまなライセンスとそれらについての解説
ライセンスを宣言するには、ディレクトリのトップに"LICENSE"や"LICENSE.txt"というファイルを作ってそこに宣言するのが一般的だ。

公開鍵の作成

すでに公開鍵を持っていて、自分で設定できる技量があるなら飛ばしてOK
公開鍵と秘密鍵について素養が無い場合、Wikipediaを読むと良い
まずGit Bashから

$ ssh-keygen 

と打ち込む すると

Generating public/private rsa key pair.  
Enter file in which to save the key (/Users/tsuroot/.ssh/id_rsa):

という風に表示されるので、ファイル名を変えたい場合以外はそのままEnterを押す。 次に

Created directory '/c/Users/tsuroot/.ssh'.
Enter passphrase (empty for no passphrase):

と出るので、ここで秘密鍵にパスワードをかけることができる。かけておくと多少安全である。
パスワードの再入力もすませると公開鍵と秘密鍵が作成され、fingerprintやrandomart imageが表示される。
ファイル名を変えていなければ、秘密鍵は'ホームフォルダ/.ssh/id_rsa'、公開鍵は'ホームフォルダ/.ssh/id_rsa.pub'に保存されている。このうち".pub"のついていない方のファイルは絶対に他人に渡してはいけない。一方".pub"のついたファイルはしばしばコピペして使うことになる。
さてGit Bashを起動させた後、特にカレントディレクトリを移動していなければホームフォルダにいるはずだ。それならば

$ cat .ssh/id_rsa.pub  

で表示できる。(略)

ほかのコマンドについて知りたいとき

Gitの他のコマンドを使えば履歴を書き換えたり戻したりすることができる、 こういった物を読むと良い。
commitとpushしかできない人のためのgithubの使い方まとめ
初心者がプルリクまでに覚えるべきたった 9つの厳選 Gitコマンド

もっと詳しい入門(本)

入門Git

入門Git

この本はGitのトップメンテナーである、濱野 純氏によって書かれている。
Gitの開発トップは日本人が務めている、(初期バージョンの開発はLinuxカーネルの作者であるLinus Torvalds氏)
そこらへんの事情はここにも詳しい。

Goのエラー処理について

TLでまたGoのエラー処理関係で荒れていたので、そういえばちゃんとテストコード書いてみたりして自分の中で整理しなきゃなぁと思ったので書いてみる。

通常の処理

file, err := os.Open(name)  
if err != nil {  
    // Error Handling
}  

もしくは

if file, err := os.Open(name);err != nil {
    // Error Handling
}

というように書く。 エラーを意図的に無視するなら

file, _ := os.Open(name)

というようにエラーの返り値を"_"にバインドする。 基本的にGoではエラーは関数の返り値の一つとして戻ってきて、try-catch-finally構文はそもそも使えない。
こういう風になった理由としてはgoroutineで非同期に処理が行われることと関係があるようだ。
(他にchannelが閉じているかどうかを安全に判別する関数が無い等)
参考:Goでchannelがcloseしてるかどうか知りたい というアンチパターン

recoverを使ったハンドリング

どうしても似た形のパターンを書きたいなら、builtinにある関数のrecoverを使うという手がある。
recoverは基本的に遅延ステートメントのdeferの中で行うことになる、通常panicを呼び出すと 関数の実行は直ちに停止し、プログラム全体が基本的に停止されます。ただしdeferは例外的に実行され、その中でrecoverが実行されたときはそこから処理が継続する。つまり

defer func() {
    if err := recover();err != nil {
        // Error Handling
    }
}()  
errFunc() // 何らかのpanicを起こす処理

というふうに書ける。つまり異常系を外側で処理することができる、しかしこれはオススメされない。
panicは例外的に直ちにプログラムを終了させなければいけないような状態でのみ使われるべきで、 特にライブラリでは初期化を除いて使用されるべきではないとされている。
Javaのような異常系を特別な制御構造を使ってハンドリングするのと、通常の値として返すのと どちらが優れているかどうかは私にはよくわからないが、いちいちファイルのオープン程度でtry-catch-finallyで囲むのは確かに読みづらくなる原因であるようにも思える。(if err != nil〜と書いてハンドリングする方がマシ)

しかしいちいちif err != nilとやりたくない場合

似たようなエラーを返す関数を複数回連続で呼び出した場合当然以下のようになる。

file1, err := os.Open(name1)
if err != nil {
    // Error Handling
}
file2, err := os.Open(name2)
if err != nil {
    // Error Handling
}
file3, err := os.Open(name3)
if err != nil {
    // Error Handling
}

しかし当然これはあまりにも面倒くさいし、DRY原則に反する。 そこで補助的に関数を使って書くとこういう風に書くことができる

var err error
open := func(name string) *os.File {
    var file *os.File
    if err != nil {
        return nil
    }
    file, err = os.Open(name)
    return file
}
file1 := open("file1.txt")
file2 := open("file2.txt")
file3 := open("file3.txt")
if err != nil {
    // Error Handling
}

外側でerrを定義しているのと、わざわざ関数を作ってそれを呼び出すというのを使っているのがなんとなくもにょるがこれで同じハンドリングは一箇所に纏められる。お試しあれ。
参考:Errors are values

Copyright (C) 2015 tSU-RooT. Unless otherwise noted, the text of this page is Dual licensed under a "Creative Commons Attribution 4.0 International License", OR the "GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts", AND also source code is licensed under a "Creative Commons CC0 License".

卒業研究着手

4年生に進級して今日から卒業研究が始まった、私が3年次に配属されたのは高周波(マイクロ波)を研究するところで 主に回路シミューレーターを使って無線電力伝送や整流回路について研究することになる。本当はソフトウェアについて研究したかったが、それならば浪人してでも情報工学科に入るべきだったので1年くらい寄り道してもとりあえずいいかという感じである。

卒業にはまだ10単位足りないので前期は就活と卒業研究と授業を平行して進めていくことになる。

とりあえず初日ということで自分に割り当てられたPCに研究に必要なマイクロ波回路のシミューレーターをインストールした、このソフトウェアは何故かDVDに入った2GB近くある巨大な実行ファイルからインストールするようになっており、インストールし終わるのに異常な時間を要した、
最近はUbuntuでだいたいsudo apt-get installで一発でインストールが終わる(ソースからコンパイルとか設定に手間取った場合を除く)のに慣れていたので久しぶりの体験だった。
インストール中は暇を持て余していたので最近嵌ってるGo言語でもいじくりまわしたいなーと思ったが、CUI環境が貧弱なWindowsではなんとなく弄くる気にならない、他にはとりあえずFirefoxやGit for WindowsAtomをインストールしておいた。
Git fow Windowsは初めて使ってみたのだが、割りとまともにBashが動くのに驚いたし
普段使うだいたいのcoreutilsは組み込まれているようだ、環境変数を見るとUNIXとして動いてるらしい。
本当はここ1年ぐらいMacGNU/LinuxUNIX互換環境に慣れていたので、常にそういったOSを使いたいのだが実質使えるのがWindowsのみなのだからここらへんで妥協しようと思う。(本当は回路シミューレーターにLinux版があるようだし、VirtualBoxをインストールする手もあるがトラブったときのことを考えたり、スペックに余裕が無かったりするので避けたい)

Copyright (C) 2015 tSU-RooT. Unless otherwise noted, the text of this page is licensed under a "Creative Commons Attribution-NoDerivs 4.0 International License".

アイの物語/山本弘

アイの物語

アイの物語

まず構成が素晴らしい、SF版シェヘラザードであり著者の短篇集でもある。
話はメタ構造にもなっており、ネタバレせずに包括して語るのは難しい。 ところどころ面白く感じたところを書くと、作中に出てくるAIの使う彼らの考えた造語は
まるで星界の紋章アーヴ語のような趣きを喚起したし、アンドロイド(or ロボット or AI)は人間とは異なる存在であるというのもアーヴと人間が遺伝的に違う種族であるという設定を思い出させた。
あるいは膚の下の人間と機械人、そしてアートルーパーの関係と言ってもいい。

「立て。アートルーパーの目的は人間になることではない、アートルーパーとして生きることだ」
(神林長平:膚の下(下) Kindle版 ページNo.1040より)

また作中のレイヤー2などの仮想世界の描写はとても面白く感じた、もしバーチャルリアリティが現実化したら
出始めた初期はソードアート・オンラインのようにはなるかもしれないが、浸透するにあたってレイヤーとか
正義が正義である世界のように、仮想世界ごとに別のワールドとして認識するようになるんじゃないかというのはなんとなく自分でも思っていたからだ。
他にも思ったことはいくつかあるが構造上書くのは難しいし、さらにこれの前に読んでいた「去年はいい年になるだろう」のせいでさらにメタ構造は複雑化している。("去年はいい年になるだろう"で"アイの物語"のネタバレをされかけたので急いで注文して読んだ)
ともかくフィクション論を扱ったSFとして面白かった。

Copyright (C) 2015 tSU-RooT. Unless otherwise noted, the text of this page is licensed under a "Creative Commons Attribution 4.0 International License"

Self-Reference ENGINE/円城塔

床下からジグムント・フロイトがどんどん出てくる!!!!!
という短編があって、これに興味を引かれたから読んだ。
ハルヒフロイト先生を知った俺としては、他のラノベやらアニメにはこういう知的なギャグが見受けられないように感じて寂しいのだがこの短編でジークムント・フロイト成分を10年分ぐらい補給したと思う。足りない分は本人の著書を読もう。

あとJapaneseという短編が面白かった、正直このオチにはやられたと感じている。
巨大知性体は神林長平の作品にしばしば出てくる人工知性体を円城塔なりに表現したものなのかなーと考えている、神林長平 トリビュートにも参加してるしね。
あと人外の怪盗とか時空を通り抜けるモリアーティ教授についてなど、細かいところで見るととても気に入っている与太話(大真面目に語るギャグ)が多い、Infinityとか普通に感動的だし与太話かつ多彩な話をデビュー作でやっていて何故虐殺器官と共々 第7回小松左京賞を落選したのか不思議でならない。(書きなおしてから出版したらしいが)

これはペンです。や良い夜を待っているも楽しく読めたが、Self-Reference ENGINEの方がユーモアに満ちていて良い。

Self-Reference ENGINE (ハヤカワ文庫JA)

Self-Reference ENGINE (ハヤカワ文庫JA)

Copyright (C) 2014 tSU-RooT. Unless otherwise noted, the text of this page is licensed under a "Creative Commons Attribution 4.0 International License"

このブログの記事は必要である範囲で他の著作物を引用していることがあります。また指摘・修正を受け付けます