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

人工生命を創る

こんにちは、id:Mitsuyoshi です。 普段は美容情報ポータル VICOLLEのiOSアプリ開発をしています。

人工生命について「SpeeeKaigi」で発表しました。
SpeeeKaigiについてはこちら↓

tech.speee.jp

はじめに

私は自分で制御できるけれども完全な制御権はない、生き物やロボット、セルオートマトンなどを観察するのが好きで、最近は人工生命を作っています。
目指しているのは「強い人工生命」なのですが 、完全に目指そうとすると世界の設計からしないといけないので(そしてそれはほとんど思考実験の段階でボツになるので)、今回は強い人工生命に必要なひとつの要素である、オープンエンドな(=収束しない)進化の実験をしました。

世界に最適解、必勝法、が存在すると、そこに最初に到達した生物が大繁殖するだけになってしまって面白くないので、そうならない手法の実験です。

内容

試してみたのは、生物の種族間の関係性を流動的にすることで、最適解があったとしてもそこから簡単に移動していけるようにするという方法です。
例えば、ある1種類の生物がフィールドを独占している状態を「天敵が多い」とみなすか、「餌がたくさんいる」とみなすかはそれぞれの生物個体の持って生まれた性質によって決まる、ということです。

結果

以下のようなサイクルができ、ひとつの種族に収束するということがなくなりました。

  1. 数種の生物がバランスして個体数の変動がなくなる
  2. それを捕食する性質の突然変異が生まれ、捕食者が大発生するとともに以前の種族が激減する
  3. 捕食者が増えて安定した系となる
  4. はじめに戻る

展望

“種族"というものを今はかなり恣意的に決めてしまっているので、その辺創発的に生まれるような仕組みを作りたいです。

そうだ関所を建てよう

こんにちは、新卒一年目が終わったばかりの山浦(arumi8go)と申します。
私は普段 VICOLLEというサービスのサーバーサイドエンジニアをやっています。

今回は、残念ながら体調不良で参加できなかったSpeeeKaiで話す予定だったRack MiddlewareとmongoDBを使用してログ管理をしようとした話をします。

SpeeeKaigiについてはこちらを参考にしてください。

tech.speee.jp

動機

VICOLLEの開発中にとある上司との会話で「どのタイミングでどのAPIが何回叩かれるか把握したい」という話から作り始めました。 また技術選定については触れたかったけど今までちゃんと触れていなかったRack MiddlewareとmongoDBを選び、一から学びつつゆっくり作りました。

機能

アクセスログ記録

この機能が今回のメイン機能となります。

f:id:arumi8go:20170306163520p:plain

上記の図のように飛んできたRequestを一度 Rack Middleware で受取りアクセスしようとしているパスやリクエストパラメータをmongoDBに記録します.

アクセスログ参照

こちらはログを参照するダッシュボードをRails Engineでマウントする形を取っています。

f:id:arumi8go:20170306164300p:plain

おしゃれな見た目でログが追える様になる予定でしたが、私のセンスの無さと時間の都合でダサダサなダッシュボードになっています……

アクセス制限

こちらの機能はおまけ的なモノですが、ダッシュボードのセキュリティについて考えているときに思いついて搭載しました。

f:id:arumi8go:20170306164713p:plain

上記の図のようにRequestがきたタイミングで予め指定したIPアドレスのブラックリストとホワイトリストを参照し該当するIPならRailsアプリケーションにRequestを通さずそのまま403を返すようになっています。

おわり

今回作っていて思ったのはもう少し難しい事にチャレンジしても良かったなということです。
学んだ知識を活かして難易度の高いテーマに挑んでいれば、もっと面白いものが作れ面白い発表ができたかなと!

ただこの関所くんもコツコツと改良を行っています。最終的にはコードを綺麗にしてGemにして公開できればいいなと思っています。

このつたない文章を最後まで読んでいただき有難う御座いました。 次のSpeeeKaiではもっと面白い発表を出来るように頑張ります。

GPSで勤怠情報を正しく把握するぞ!

管理系エンジニアのbino98です。

管理系とはその名の通り、管理 部門のエンジニアなのですが、 今回のSpeeeKaigiのネタも、 管理 部門っぽいお話をさせていただきました。

管理部門っぽい話、その前に。

SpeeeKaigiの詳細は下記を御覧ください。葉的に言うと、 エンジニアのお祭り です。

tech.speee.jp

発表した時の資料はこちら

勤怠、把握できてますか?

あなたの勤怠管理、正しく把握出来ていますか? と聞かれると、ドキッとする方、多いのでは。 特に忙しいときほど、正しく勤怠を付けねば意味がありません…。(正確な状況の把握ができねば、環境の改善や見直しも難しいかもしれませんし…)

しかし、実際には 打刻を忘れてしまうことは 多々ありますよね そこで今回の発表では、忘れにくさと正確な打刻を行うための試みとして、 GPSを用いて打刻を行ってみました

やっていく中で何が一番大変だったか

結局、GPSにするだけじゃ、打刻忘れは解決しないんです。 (コレに気づいたのはスライド作っている途中でした。) GPSにして、ブラウザを開いたら打刻されている仕組みを作っても、 ブラウザを開く行為を忘れれば何も意味はない…。 なので、打刻忘れは解決しないんです。当たり前ですね。

しかしGPSによる打刻は、思わぬ副作用をもたらします。 正確な勤怠申請とは、必ずしも 打刻時間が正しいか だけではなく、その打刻が実際に申請内容通り行われているか の確認も行わなければなりません。 例えば、GPS打刻があれば、 「出張の申請が提出されているが、本当に出張しているのか?」など、勤怠申請の内容も正しさを証拠として残せるのです。 また、リモートワークなど、場所に縛りを設けない働き方になったときも、GPS打刻は威力を発揮すると思います。 そんな夢を持った試み、ぜひ弊社の勤怠システムに取り入れたいですね。

今後に関して

弊社の勤怠システムは社内で内製しているのですが、 他の勤怠システムにない新しい技術を取り入れて、何処にもない勤怠システムを作っていきたいものです。

機械学習とは?から1ヶ月で対話botを作れるようになるまで

こんにちは、hatappiです。
デジタルコンサルティング事業部でエンジニアしてます。業務としては事業部で使用する顧客管理システムの作成を行っています。
今回は以前行われたSpeeeKaigiにて自分の発表した「機械学習とは?から1ヶ月で対話botを作れるようになるまで」について話していきます。

SpeeeKaigiとは?については下記の記事を参考にしてください。
一言でいうとSpeeeで実施されるエンジニアが自分の技術を自慢するお祭りです。

tech.speee.jp

発表した時の資料はこちら

speakerdeck.com

そもそもなぜ機械学習か

世の中的には機械学習という言葉であちらこちらで聞こえてくる中自分もやりたいなぁと思いつつもハードルが高そうという思いやってこなかったので 今回をきっかけにはじめてみようと思いました。
とはいえほぼゼロベースなので自分ひとりではどうにもならなさそうだったので、社内で機械学習勉強会を主催することにしました。

勉強会についてはこちら

tech.speee.jp

SpeeeKaigiが終わった後も勉強会は継続してやってます。

やっていく中で何が一番大変だったか

機械学習する前段階で自分が学習するところが一番大変でした。
機械学習を用いて何か作ろう!!だと世の中に参考になるものが落ちていますしChainerやTensorFlowを使えばそれっぽいものはすぐ出来ると思います。
ただ今回は折角なのでそもそも機械学習ってそもそもなんだという所などから学習しはじめたのですが、微分など高校でやったなーというものが出てきたりと立ち止まるところが多かったです。

今後に関して

社内勉強会自体は形はかえつつも継続してがんばらなくても開催できる運用をやっていきたいと思います。

Reactでシンセサイザーを作った話

こんにちは、nishayaです。
管理部のエンジニアとして、社内向けのシステムを作ったり、
社内で開催されるイベントでコーヒーを淹れたりしています。

社内向けだからこそできる冒険もある、ということで、
現在はReact/Reduxを用いたSPA開発を行っています。

今回のSpeeeKaigi(下記の記事を参照)では、
ReactとReduxを使ってシンセサイザーを作る話をしました。

tech.speee.jp

発表資料

使用したもの

Web MIDI APIを使用しているため、今回のターゲットブラウザはGoogle Chromeのみとしました。
そのため、webkit プレフィクス付きのAudioContextにも対応していません。

モチベーション

業務でSPA開発にReact/Reduxを使用するという決定をしたものの、
道具として使いこなせていない感があったため、
何か楽しみながら作れるものを開発して勘所を押さえようと考えました。

作りたかったもの

  • 音の出るものが作りたい
  • ただ録音された音を鳴らすだけでは面白くないので、音を合成して作り出したい
  • 音はユーザのインプットに応じてインタラクティブに鳴らしたい

どうやって作るか

  • Web Audioのノードを組み合わせてシンセサイザーを作るとしたら、それぞれをReactのComponentにすると扱いやすいのではないか?
  • 入力装置からのインプットをReduxのstate経由で通知することで、ハンドリングする側のコンポーネントに直接イベントを通知しなくてもよくなり、構成の自由度が上がるのではないか?
  • やはり楽器を作るなら、PCのキーボードではなくMIDIコントローラ(鍵盤など)を使いたい。Web MIDI APIが使えそう

解決すべき点

パフォーマンス

Reactについて、更新の伝播がうまくいかないことがあるとか、 パフォーマンスが悪いという話はなんとなく聞いていました。

楽器として機能するものにするためには、鍵盤を弾いてから発音までのレイテンシが短ければ短いほどよいし、 数十msを超えたらそれは音楽として別物になってしまうことを意味し、致命的といえるため 事前に検証しておくことにしました。

検証では、keydownイベントをトリガーにactionを発行し、 別のコンポーネントでstateの変化を検知するまでの時間を測定しました。

avg. 0.8281000000000586 ms / 50 times
avg. 0.9170500000002039 ms / 100 times
avg. 0.6555400000006857 ms / 500 times

結果としては、平均1ms以下となり、 楽器にも使えそうだということがわかりました。

適切なコンポーネント分割

行った分割は大別して2つ

  • Input/Outputを分割する
  • シンセサイザーの構成要素を分割する

詳細は発表資料を参照してください。

できたもの

発表当初から変更した点

発表当初はMIDIコントローラがないと音が鳴らせなかったんですが、
発表時に、MIDIコントローラなんてものは普通持っていないという意見が多かったので、その日のうちに

  • PCのキーボードによる演奏
  • トラックパッドによる音色変化

を追加しました。

また、週末時間があったので

  • 波形の追加
    • SuperSawなど、複数のオシレータにより太い音を出す波形
    • PeriodicWaveを用いたPWMや疑似三角波(いわゆるファミコンの音)
  • ADSR
  • Filter EG
  • ディレイ
  • ディストーション

などを追加しました。

所感

音を出したいという強いモチベーションがあったので、
不慣れなReact/Reduxを楽しみながら習得することができました。

結局一番役に立ったのは公式ドキュメントでした。
今までのフロント開発とはパラダイムがだいぶ異なるので、
とっつきにくさはあるものの、公式をくまなく読めば、
なぜそのように作るのか、どうしてこれを使うと嬉しいのかが理解できるようになっています。

また、先述のとおり、コンポーネントを分割しておいたため、
機能の追加、変更は容易で、他の部分に影響を与えず独立して行うことができ、
React/Reduxは道具として使いこなせれば気持ちよく開発を進められる技術だと感じました。

次は音の質に特化したmonophonicなシンセサイザーか、
コンポーネント指向のステップシーケンサを作ってみようと考えています。