"読書について"を読んでみた感想
ショーペンハウエルの「読書について」を読んだ感想です。
本の内容をただ読むだけではなくてちゃんと噛み砕いて飲み込むところまでするのが読書だ、という感じでした。
- 作者: ショウペンハウエル,Arthur Schopenhauer,斎藤忍随
- 出版社/メーカー: 岩波書店
- 発売日: 1983/07
- メディア: 文庫
- 購入: 27人 クリック: 297回
- この商品を含むブログ (177件) を見る
"なんだか本が読みたいな"と思うことが自分の体内では数ヶ月に一度くらいの頻度で起こるのですが、いざ何読もうかと考えたときに大学生の時期に読んでおきたい本n選!のようなブログ記事で目に付いたのがこの本でした。本を読むなんてことは自分の普段の生活だとライトノベルを読んで娯楽に浸るだとか、技術書をパラパラっとめくって新たな情報を得たりするぐらいしかしてないが、哲学的な話は結構好きなのでついつい読んでしまった。
まだ一度しか読んでないので結構適当なこと書いてます(´・ω・`)
読書をするという行為は、自分の思想を硬直させてしまう危険性をはらんでいる
これは確かにそうだなあと思ってしまった。自分の行動の傾向として、読んだ本の内容を自分で咀嚼して噛み砕くことをせずに一語一句本と同じ内容を他人との話し合いやら議論やらで持ち出すということをよくやってしまう。
例えば本の内容を人に説明するときにやたら専門用語を持ち出して相手側に理解を及ばすことが出来ないのは、その専門用語の意味を思考することを怠った結果なんだと思う。これではただ記憶力に頼っているだけでああいえばこういう奴と何ら変わりないなーと思うとなんだか悲しい。
あとp.50~60にはこんな事が書いてあった。
"婉曲的、複雑、意味の捉えづらい複合造語などで構成される著作は、著者が自ら施策した形跡を持っておらず、それは読者に思考することをゆだねるものであり、無責任である"
いかに簡単な文章で物事を伝えられるかどうか、が課題になってきそう。
ただ、婉曲的で意味の分からない複合造語ってファンタジーゲームとかマンガ・アニメの世界では中二心を煽られてわくわくさせられるいい言葉だと思うし、そこまで否定されるものでもないと思った。この著者が過ごしてきた背景では意味の分からない造語は良いものとはされてないけど、いい意味で思考を委ねているのがアニメ・ゲームなのかなーと勝手に思います。
読書によって自分の考えが固定されてしまってはいけないので、「思索」が必要であるということ
考えが固定されるとなぜいけないのか?というと、格言を無条件で信仰するという、まさに宗教的盲信に走ってしまう危険性につながるからだと解釈しました。
ところがこの本の「思索」という言葉が実際どういった行動を指し示しているのか、僕のふやけた頭では結局分からずしまいでした。ショーペンハウエルさんの「本の中身を自分でちゃんと噛み砕くことが大切だ」という主張が結構強烈で、それが格言として自分の脳内に突っ込まれちゃってる状況かもしれません//時間があればもう一度そこを意識して読みたい。
心に思想を抱く=恋人を抱くようなもの
思想も恋人も常日頃変化するけれど恋人は常に繋ぎとめる努力をしなければどっかいっちゃうように、思想も常に自分に繋ぎとめて置かなければ自分の考えが固まらないよという話。
なんかこのたとえ面白いなと思っていろいろな考えちゃいました。流れだけ言うと、恋人ができる過程でも最初はその人のなにかに惹かれたから好きになり、好きであるから相手に何かをする→でも時間が経つとなんでその人を好きになったのか忘れがち→好きになった理由というのは時間によって変化していることに気づく→その変化さえも受け入れたいと思ったときに愛を享受しあえる
思想=恋人に置き換えても通用するのかなあ。とか書いてると恥ずかしいのでこの辺にしときます( ˘ω˘)暇があれば今度別記事で。
Unity初心者が2DShootingGameのチュートリアルを読みました
ゲーム制作編第10回まで読みました。スクリプトを変更しつつ遊んでいたら無限ループに陥ったらしくUnityが落ち、シーンファイルがなぜか初期化されてしまいつらかったです・・・。気になった点をググって調べてみたのでそれをいくつかピックアップしてみます。雑なので綺麗に書く時はQiitaに書こうと思います。また、ここでは様々なサイトを参考にさせていただきました。ありがとうございます。
QuadとPlaneの違い
PlaneはXZ平面、QuadはXY平面の板
Planeは平らな床や平面を表示するのに利用
Quadは画像や動画、シンプルなGUIディスプレイを表示するディスプレイとして利用
LerpとClampとは
Lerpは、区間[a, b]をパラメータ0<=t=<1で線形補間する関数。たとえばa=3,b=7,t=0.4ならLerpの戻り値は4.6
Clampは、valueを入力として、区間[min, max]より外側をカットする関数。たとえばmin=-2,max=2,value=3ならClampの戻り値は2。
配列の初期値をインスペクタでセットする
あるクラスのフィールドに
public GameObject[] spawnObject;
と書くと、インスペクター上で
このようにサイズが可変になり、各要素を指定できるようになる。
コルーチンでできそうなこと
・Start()でUpdateもどきが作れる。Unityではこういうのが良くあるらしい
IEnumerator Start() { while(true) { //update like yield return null; } }
・A→B→Cとアニメーションしたい時に以下のようなコードが使えたりする。BからCへはcondがtrueであるかぎり進まない。WaitForEndOfFrame()はEmitter.csに書いてあったが、yield return nullでも変わらなさそう(未検証)。WaitForEndOfFrame()はリファレンスによると、スクリーンショットをWWWFormなどを使ってどこかに送信するなどという用途らしく、かなり限定的な使い方らしい。
IEnumerator f() { A(); yield return new WaitForSecond(1.0f); B(); while(cond) { yield return new WaitForEndOfFrame(); } C(); yield return new WaitForSecond(1.0f); }
Unity3つの座標系
・ワールド座標系・・・3次元。原点は世界の中心。
・スクリーン座標系・・・2次元。カメラの写る範囲を(0, 0)から(640, 480)などで表す。ただしレゾリューションにより異なる点に注意。
・ビューポート座標系・・・2次元。カメラの写る範囲を正規化された座標系で表す。つまり(0, 0)から(1, 1)
衝突検出で注意すべき点
OnCollisionEnter, OnCollisionExit, OnCollisionStay, OnTriggerEnter, OnTriggerExit, OnTriggerStay 関数について。
・どちらかにRigidBodyがアタッチされてないとNG
・RigidbodyのIs KinematicがOffになってないとNG(物理演算が効かない)
・ColliderコンポーネントのIs TriggerがOffのとき→OnCollision〜関数が呼ばれる
・Is TriggerがOnならOnTrigger~であることに注意
まとめ
Transformを直接動かす方法でゲームオブジェクトを行うとそもそも物理演算が行われない。
Rigidbody.velocityに値を設定したり、Is Gravityなどによる物理演算が行われて初めて、OnColliderなんちゃらなどのイベントハンドラが実行される。
解決しなかったこと
・Sceneビューを見ているときに、wave.childcountが0のときに働くリスポーン機能が働かない。
・UnityのGUITextはなぜかSceneビューからは見れない謎
・GameObject (named 'XXXX') references runtime script in scene file. Fixing!
UnassignedReferenceException: The variable projectile of ‘explosion' has not been assigned.
というエラーが以下のコードで出てしまう。言い換えると、抽象クラスで定義された関数内で、抽象クラスで定義された変数を利用した時に以上のエラーが起きてしまう。これをメモする前に実際のコードを変更してしまったのでもしかしたら以下のコードは正しいのかもしれないがよく分からない。調査中。
class Spaceship : MonoBehaviour { [SerializeField] protected GameObject explosion; protected void Explosion() { Instantiate (explosion, transform.position, transform.rotation); } } class Player : Spaceship { void hoge() { base.explosion(); } }
情熱プログラマーを少し読んだ
「14.師匠になる」という説を読んでて思ったこと
”知識を他人に教えられるということは、それを本当に理解している”ということを実感したという話です。
僕が所属している大学のサークルでは、サークルのサーバーはどんな風に動いてるのかとか、作ったゲームのアルゴリズムどうなってるのとか、そんな話をLTでたまにやることがある。サーバーの話をした時、思うようにサーバーの何たるかを喋ることができなかったことを未だに覚えていて、そんなもやもやが残っている中この節を読んだ。この節によると、誰かに教えてみれば自分がそれを本当に分かっているかが分かるということが書いてあり、「ああ、自分は本当に分かっていなかったんだな」ととれた。または、アウトプットする力が足りなかったと考えた。
学んだことをノートやらブログやらに書いてみる習慣をつけることは技術の向上にもつながるはず。それが技術ではなく人生の考え方やお金、ビジネス、恋愛、遊びなどの話題でも、そのような話題提供をしたり、深く考えたりする力に繋がる事は全然マイナスではないし、むしろトークの幅が広がって面白いと思うし、どんどんアウトプットしていくことが必要だなぁと思った。まあなんでもかんでもアウトプットしてしまうと思いもがけない炎上が起こったりでまた大変なのかもしれないが、規模の小さいブログでそれが起こることは少ないだろう。
いままで何個もブログを作っては放置しての繰り返しだった過去を振り返ると、自分にとってはアウトプットの習慣をつけることは容易ではなさそう。
しかし、、やってみるしかないですね
この本は読んでいると嫌でも意識が高まってしまうマジックがあるようだ。
Mojoliciousのunderがうごかない?
クライアントでネイティブに動くゲームと、そのゲームのスコアを集計してランキングを表示する簡単なwebサービスを作ってみたいな〜という思いが湧いてきてしまって最近、Mojolicious::Liteをかじってみている。
Perlではおなじみの木本さんのサンプルコード
(http://d.hatena.ne.jp/perlcodesample/20140412/1396426029)
を直接使って動かしてみたのだが、ユーザー名をadminにしてもなぜかForbiddenのページが現れてくれない。なぜだろう。環境が合ってないからなのかな。分からないのでここに書き留めておく。
確かにadmin.
ファッ・・・!?
以下は引用です。
use Mojolicious::Lite; # 前処理 under sub { my $self = shift; # ユーザーがadminの場合は許可しない my $user = $self->url_for->path->parts->[0] // ''; if ($user eq 'admin') { $self->res->code(403); $self->render(text => 'Forbidden'); return } return 1; }; # /ユーザー名/プロジェクト名/ディレクトリ名 # あるいは /ユーザー名/プロジェクト名 get '/:user/:project/*dir' => {dir => undef} => sub { my $self = shift; # パラメーター my $user = $self->param('user'); my $project = $self->param('project'); my $dir = $self->param('dir') // 'Nothing'; # 描画 $self->render( 'index', user => $user, project => $project, dir => $dir ); }; any '/http-method' => sub { my $self = shift; # HTTPメソッドの取得 my $http_method = $self->req->method; $self->render(text => "HTTP Method: $http_method"); }; app->start; __DATA__ @@ index.html.ep <% my $user = stash('user'); my $project = stash('project'); my $dir = stash('dir'); %> <html> <head> <title>Routing</title> </head> <body> User: <%= $user %><br> Project: <%= $project %><br> Directory: <%= $dir %></br> </body> </html>
Observerパターンの練習をしてみた
下記のページを参考にObserverパターンを作る練習をしてみたので、そのコードと重要だと思った点をまとめてみようと思います。
17.Observer パターン | TECHSCORE(テックスコア)
Subject(生徒)からObserver(新人先生)に伝える内容
enum class MessageKind{ UPDATE_COUNT, }; struct Message{ public: Message(int value, MessageKind kind) { this->value = value; this->kind = kind; } public: int value; MessageKind kind; };
抽象クラス
class IObserver{ public: virtual void update(Message) = 0; }; class Subject abstract{ public: void addObserver(IObserver* observer) { observerList.push_front(observer); } void notifyObservers() { } virtual void run(int count) = 0; protected: std::list<IObserver*> observerList; };
派生クラス
class Teacher : public IObserver{ public: Teacher() { stuScore = 0; } void update(Message message) override { if (message.kind == MessageKind::UPDATE_COUNT){ stuScore = message.value; } } void display() { std::cout << "[Teacher] student's score: " << stuScore << std::endl; } private: int stuScore; }; class Student : public Subject{ public: Student(IObserver* observer) { addObserver(observer); this->count = 0; } Student(IObserver* observer, int count) { addObserver(observer); this->count = count; } void run(int count) { this->count += count; notifyObservers(); } void display() { std::cout << "[Student]student's count: " << count << std::endl; } private: void notifyObservers() { for (const auto& observer : observerList){ observer->update(Message(this->count, MessageKind::UPDATE_COUNT)); } } private: int count; };
main関数
int main() { Teacher* teacher; teacher = new Teacher(); Student* stu1; stu1 = new Student(teacher); teacher->display(); stu1->display(); std::cout << std::endl; stu1->run(2); teacher->display(); stu1->display(); std::cout << std::endl; stu1->run(3); teacher->display(); stu1->display(); std::cout << std::endl; delete teacher; delete stu1; return 0; }
まとめ?
Message構造体は始めはclassで実装しようと考えたのですが、そうするとTeacherがMessageを受け取った時、つまりTeacher::update()が呼ばれた時にMessageのフィールド変数valueをgetする処理が、オブジェクト指向の9つのルールのうちの一つ「getterは使わない」に引っかかってしまいます。それを回避した結果として構造体にしました。デフォルトでメンバーがpublicかprivateになるかを除けば構造体もクラスとほぼ一緒じゃん!と言われればそれまでなんですけど。なんでこんなルール守ってるかというとはてなダイアリ(http://d.hatena.ne.jp/seaview_p35/20150218/p1)にも書いたんですがクラスの肥大化が起こってクラス設計を見なおさないといけないなーと思ったためです。