//適応度を更新
  updateFitness() {
    this.fitness = Math.pow(1 / this.RecordDistance * this.finishTime, 4);
    if(this.hitObstcle){
      this.fitness *= 0.01;
    } else if(this.hitTarget){
      this.fitness *= 2;
    }
  }

前回はライフサイクルが終了した時のビークルの位置を見て適応度としていたが、
今回はライフサイクル中に一番近い付いたときの距離と、そのサイクル数の短さが適応度に反映されるようにする。
また、ターゲットにぶつかったときは２倍の適応度に、障害物にぶつかったときは10分の1の適応度にすることで重みをつけている。

この課題、写経なのでなんとなくできている感のある動きになってはいるものの、
適応度を図る部分や突然変異率、母数などちょっとしたことが与える影響がかなり大きくて自分一人で1から組み立てチューニングできるようになるのは大変なんじゃないかな、と思ったり。。

2016-07-02

nature of code：今日の練習「獲物に向かうように進化するビークル」

nature of code

See the Pen 獲物に向かうように進化するビークル by kanaparty (@kanaparty) on CodePen.

久しぶりにnature of codeの課題！
前回の進化の課題の表現を文字列から運動に変えて、解を「獲物（画面右端の丸）にたどり着くこと」とした。
はじめはてんでバラバラの方向に向かう集団が、世代を進めるとだんだん獲物に辿り着けるように進化していく。

2016-05-25

読書メモ：webを支える技術(1)(2)

読書メモ

URL URN URI

URL(リソースの場所）、URN(リソースの名前)、URI(リソースの識別)

REST

REST・・・webのアーキテクチャスタイル（指針・作法・流儀、システムを設計するときの指針）

リソース

web上に存在する、名前(URI)をもったありとあらゆる情報のこと。
URIを使うことでプログラムがアクセスできるようになる。
複数のURIをもったリソースもある。
ひとつのリソースは複数の表現ができる。
リソースには状態がある。

クライアント/サーバー

ステートレスサーバー
アプリケーション状態を保存しない
キャッシュ
いちど取得したデータをクライアントで使い回す
統一インターフェイス
httpが８個のメソッドしかもっていないのとかがそれ
階層化システム
負荷分散したりできる
コードオンデマンド
プログラムをサーバからクライアントへ落としてきて実行する（jsとか）

クールなURI

「クールなURIは変わらない」

言語依存の拡張子を使わない
実装依存のパス名を使わない
メソッド名を使わない
セッションIDを含めない
そのリソースを表現する

Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)

作者: 山本陽平
出版社/メーカー: 技術評論社
発売日: 2010/04/08
メディア: 単行本（ソフトカバー）
購入: 143人クリック: 4,320回
この商品を含むブログ (181件) を見る

2016-05-22

読書メモ：webを支える技術(3)

読書メモ

TCP/IPについて

インターネットのネットワークプロトコルは階層型になっている

ネットワークインターフェイス層
インターネット層
パケット単位でデータのやりとり。IPが相当する部分。データ送り出すことは保証するが、送り先に辿り着いたかの保証はしない。
トランスポート層
 TCPが相当するところ。データの転送の保証をする。接続先の相手にコネクションを貼ってデータの抜け漏れがないかチェックする。どのアプリケーションにデータが渡るか決めるのがポート番号。
アプリケーション層
メールやDNSやHTTPを実現するところ。

ソケット・・・ネットワークのデータのやりとりを抽象化したAPI。

ステートレス

HTTPはステートレスなプロトコル。

ステートレス　←→　ステートフル

ステートレスでは・・　- アプリケーション状態を保持しない
- クライアントのリクエストメッセージに必要な情報をすべて含める（自己記述的メッセージ）
- サーバ側のシステムが単純になる
- でも毎回必要な情報を送るので送信するデータ量が多くなる
- ネットワークトラブルが起きたときにリクエストが処理されたかわからないので通信エラーへの対処が必要　
ステートフル
- 代表的なものにFTPがある
- クライアントの数がふえると同期するサーバも増やさなくてはいけなくて大変

アプリケーション状態・・セッション状態（ログインしてからログアウトするまで）のこと

HTTPのメソッド８個

HTTP入門

POSTとPUT

どっちでもリソースの作成ができる。でも、クライアントがURIを決めたいときはPUTが適しているがそのURIが存在しているか調べたり、クライアントが内部実装を熟知していないといけなかったりするので特別な理由がない場合はPOSTでリソース生成をしたほうがよい

べき等

冪等 - Wikipedia 「ある操作を1回行っても複数回行っても結果が同じであること」

GET HEAD ・・・　べき等　で　安全（通信エラーが起こっても結果がかわらない）
PUT DELETE ・・・　べき等
POST ・・・べき等ではなく安全でもない

POSTの誤用に注意

GET PUT DELETE で実現できる機能はべき等と安全性が利用できるのでなるべくそれで実現する

ステータスコード

クライアントの挙動を左右するのでステータスコードの選択は重要。

ステータスコードは先頭の数字で分類されている

1** 処理中（クライアントはリクエストを継続するか再送信）
2** 成功
3** リダイレクト（レスポンスメッセージの locationヘッダを見て新しいリソースに接続する）
4** クライアントエラー
5** サーバーエラー

認証

Basic認証　 Basic認証 - Wikipedia
Digest認証 Digest認証 - Wikipedia
WSSE認証 https://wiki.suikawiki.org/n/WSSE%E8%AA%8D%E8%A8%BC$14454
OpenID OpenIDとは？ - Yahoo! JAPAN IdP(アカウントを提供する側)のwebサービスのアカウントで他のwebサービスにログインできるようになる
OAuth OAuth - Wikipedia webサービス間での許可の委譲