機械学習をツールとして使えるようになるまでに学習すれば良いことをまとめる。
機械学習フレームワークはPythonで書かれているものが多いので、Pythonをある程度読めると学習が早い。
機械学習フレームワークはWebフレームワークなど違って、ある程度裏側で動いている仕組みを理解しないとツールとして使うことも難しい。
機械学習を学習する上で前提となるのは、理系大学教養課程における初等解析学・線形代数学の知識。
ロジスティック回帰
活性化関数 (Activate Function)
Loss関数
24時間365日働くための方法について考察する。
睡眠中・食事中・入浴中・移動中なども含めて常に仕事のことを考える、または仕事の実作業を行うこと。
睡眠中に仕事のことを考えるというのは想像が難しいが、睡眠中も脳は活動しており、 その活動の成果として、記憶の定着や夢を見る、という現象が発生する。
睡眠中に仕事のことを考えるとは、いかにして記憶の定着や夢をみやすい環境を作るか、ということを意味する。
前述した通り、仕事に対する思考または実作業が必要であるため、ベースとなる脳の活動量・体の健康・精神面での健康が必要不可欠である。
趣味は仕事に関連する以外のものについては、時間を大幅に消費するため、仕事に関連のない趣味は全て捨てる必要がある。
人間関係においては、仕事に関連しない飲み会の誘いを基本的に断る必要がある。
ただし断ることにより、人間関係には大なり小なり影響を与える。
仕事を進める上で過去の人間関係が重要になる局面は多々あるため、断ることによりその人との関係例が終了しない、を判断基準とする。
また、情熱や執念、心の底から楽しむ、と言った喜怒哀楽が無ければ、生きている間常に仕事をし続けるというモチベーションを保つのは難しい。
24時間365日働ける人は、働くことがが自然となっており、だからこそ続けていけているのだ。
まとめると以下のとおりである。
「マンガでわかるプロジェクトマネジメント」を読んだため、要点と感想を記す
ITに限らない、より一般的な意味でのプロジェクトマネージメントに関する本を読んだことがなかったため、一度汎用的に使えるプロジェクトマネージメント手法について目を通しておきたかったからだ。
マンガで解説しつつもそれを補う形で文章での説明があり、amazonでの評価も悪くなかった。
以上から、必要最低限のプロジェクトマネージメントについて最速で学べると考えて、この本を購入して読んだ。
マンガで大まかな流れを説明し、細かい説明は文章解説がされているため、読みやすい。
以下、重要だと思った点についてまとめていく。
今までにない製品などを決められた期限内に作るような仕事をプロジェクトと言う。
プロジェクトは目的や成功基準を明確にするのが重要。
プロジェクトは生き物。常に観察をする。
プロジェクト成功率が上がる経験則。
PMBOK（Project Management Body of Knowledge）がデファクトスタンダード。
スケジュール・予算などに制約がある中で、計画・推進指示・調整などを行い、目標を実現し成功に導くこと。
コミュニケーション能力。
会話がうまいという意味ではなく（会話は下手だが優秀なプロジェクトマネージャーもいっぱいいる）、
相手の考えを正しく理解し、自分の考えを伝える能力のことを指す。
自分の考えを伝える能力とは単に自分の考えを述べるだけではなく、相手の理解度に応じた言葉を選んで話したり、自分の言いたいことが伝わっていない様子を察知し伝え方を変えてみたりといった、状況に応じた対応が出来る能力も含む。
プロジェクトに直接関わっている人、またはプロジェクトを実施することにより何らかの影響を受ける人。
本には書いてないが、以下の手法もある。
以下の三つ
品質は計画、設計、作り込みにより達成されるものであり、検査によってではない。
以下の四つの対応方法がある
成否に関わらず、プロジェクトの反省会を行う。 良かった点と改善点を洗い出しておく。
さっちゃんは可愛い。
| マンガでわかるプロジェクトマネジメント | |
 | 広兼 修 さぬきやん オーム社 2014-06-26 売り上げランキング : 26203 Amazonで詳しく見る by G-Tools |
人にサービスを使ってもらうために意識することについて考察する。
現状に満足していたらわざわざ大小のコストをかけて新しいサービスを使おうとは思わないので、 新しいサービスを作るということは現状に満足していないことに等しい。
現状に対する不満については、以下の種類に大別できる。
新しいサービスが使ってもらえるか使ってもらえないかは上記の不満を解決出来るかに依るところが大きいのではないかと考える (もちろん、この新しいサービスを認知してもらう広報も極めて重要な要素であるが、ここでは一旦おいておく）。
既存のサービスに対する不満とその不満を解消するサービスを開発しそれが広まった事例を記述する。 この事例はとても小規模なものであるが、大規模サービスにもスケール出来る考え方であると個人的に思っている。
会社ではJIRAでチケット管理をしているが、そのチケットの作成が毎回時間がかかるものであった。 その理由は以下の通りである。
現状のチケット管理に不満があったため自分が使うために即席でSlackbotを開発した。
仕様としては、botに対して発言するとその内容がそのままチケットとして発行される、というシンプルなものだが、 上記リストでかかっていた作業をワンアクションで完了できるようになった。
運用を開始してから当日の次点で他のチームメンバーもそのbotを使用するようになった。
そのチャンネルに入っていた別チームの人もそのbotを使おう、ということでその対応のためにプロジェクトコードに対してプルリクエストを送ってくれた。
サービスが広まった理由としては以下のことが考えられる
ユーザ視点から考えた場合、以下の要素が大きい。
既存ユーザがいるという点については、開発者が１番目のヘビーユーザであるのが重要。 開発者が常用しないサービスは誰も使わない。
「スマートフォンアプリマーケティング現場の教科書 リフロー版」を読んだのでまとめと感想をここに記します。
スマートフォンアプリに関わる企画、ビジネス、プロモーション、運用、マーケティング、分析について、企画からリリース、リリース後まで順序だてて、解説している。 この本を読むだけで、たとえスマートフォンアプリ開発の経験や質機などが無くても、スマートフォンアプリ開発・運用において必要十分の知識を得ることが出来る。
特に参考になったのは、企画立案手法、プロモーション手法、UI/UX開発手法だ。
スマートフォンアプリだと１人で企画・開発・運用までをやることが多いが、 その場合によく確立された企画手法に頼らずオレオレ開発メソッドで開発してしまうことがある。
そのような開発メソッドでは、ユーザの使い勝手などを考慮せずに、開発者が都合の良い仕様になりがちであるため、 この本に記述された典型的な企画立案手法、プロモーション手法、UI/UX開発手法を実践することで、 単独での開発の際に陥りがちな独りよがりな仕様を回避することが出来る。
以前リリースしたスマホアプリは、この本に書かれたプロモーション手法を実践することで、固定ユーザをリリース時に獲得することが出来た。
その当時はこの書籍をまだ読んではいなかったが、プロモーションを実施するまではほとんどダウンロード数はゼロに等しかったため、プロモーションは超重要であるということを身をもって体感した。
これは 第2のドワンゴ Advent Calendar 2016 - Qiita 18日目のために書かれた記事です。
AppleWatchの文字入力はキーボードやタッチUIを利用することが出来ないため、文字入力方法としては以下の３つが用意されています(数字のパスコードの入力については専用のタッチUIが用意されていますが、あくまで補助的なものです）
この中では個人的に音声入力について一番将来性を感じており、入力には多少癖のあるものの、慣れればかなり精度の高い音声認識を行うことが可能です。
私はこの機能を使って移動中に思いついたアイデアなどをEvernoteに書き込んでいます。
この機能をもうちょっと知的に使うことは出来ないかと思い、丁度良い題材として音声を入力とした簡単な処理系を実装することを思いついたため、実装してみました。
雑な図ですが、全体構成としては上図のような形になっています。
初めはクライアント側で完結する処理系を書こうと思っていましたが、 Swiftの正規表現処理機能が貧弱でかつ私が慣れていなかったため１日で実装が間に合う自信がなかったこと、 また他のデバイスでも汎用的に使えるようにしたいということから、 慣れたPythonでサーバーサイドで処理系を実装し、クライアントからはAPIベースでの処理系への入力・出力と出力のレンダリングのみを行う構成にしました。
サーバーサイドでは以下のAPIを用意しました。
セッションIDをキーに処理系が保持する環境をRedisに保存しています。
現段階では、以下のことが可能です。
もうちょっと本格的な言語機能を作り込みたかったのですが、直前過ぎて時間切れでした。 今後AdventCalendarに登録する時は、もうちょっと前もって作っておこうと思います。
一応動画を撮ってみました。 YouTube
今回は最小の機能として代入、評価、加算を実装しましたが、入力を学習して何らかのレコメンドに役立てたり、よりファジーな入力も受け付けられるようにできると、より応用の幅が広がるのではないかと思います。
| Apple Watch Sport 42mmスペースグレイアルミニウムケースとブラックスポーツバンド | |
 | アップル 売り上げランキング : 9962 Amazonで詳しく見る by G-Tools |
| Flask Web Development: Developing Web Applications with Python | |
 | Miguel Grinberg O'Reilly Media 2014-04-28 売り上げランキング : Amazonで詳しく見る by G-Tools |
皆さんはAmazonアフィリエイトIDを持っているでしょうか。
Amazonアフィリエイトは御存知の通り、特定のIDを含んだURLからAmazonの商品を購入することで、IDの管理者にお金が入るサービスです。
何かWeb上の記事を経由してAmazonで商品を購入した場合、たいていこのAmazonアフィリエイトIDが入っていると思います。
アフィリエイトIDの所有者自らが自身のID経由で購入しても利益にはならないことから、 わざわざ自分がamazonで何かを購入する時に、他人のアフィリエイトIDを設定するという人はあまり多くないと思います。
しかし個人的にそれは非常に勿体無いと思うので、是非他人のアフィリエイトリンクを踏んで購入することをおすすめしたいです。
その理由としては以下のとおりです。
自分の行為で他人が儲かるのを不快に感じてしまう人が一定数いるとは思いますが、少なくともamazonアフィリエイトリンクの場合は、 他人のアフィリエイトリンクを踏んだことにより購入者が被る不利益は全くありません。
押し売りされるといった場合は話が別だとは思いますが、元々買う意欲があったからこそ購入しているわけで、購入した結果にアフィリエイトリンクのあるなしは関与しません。
例えば数人グループでお互いのアフィリエイトIDを使うことを取り決めた場合、そのグループの全体の金額はアフィリエイト収入分だけ少なくすることが出来ます。
Amazonのヘビーユーザ/ライトユーザで多少儲けに偏りが出ることはあるとは思いますが、元々利益にならない予定だったものを利益にしているわけです。
あまり細かいことは気にせず、収入があることを喜びましょう。
グループでお互いに収入があったことを報告し合えば、世知辛い人生を多少なりとも楽しくすることが出来ます。
その連帯感はいずれ世界を救わないとも限りません。
グループの連帯感を大切にしましょう。
さて、これで他人のアフィリエイトリンクを踏む有用性が理解できたとは思いますが、いちいち自分で他人のアフィリエイトタグを入力するのはちょっとばかり手間です。
ということを少し話していたら、hirokikana (Hiroki Takayasu) · GitHub さんが 翌日 https://chrome.google.com/webstore/detail/amazon-affiliate-link-gen/faonikmibdepgjmdlcekknapdcmmcggk 拡張を作ってくれました。
設定も簡単だし、皆さんも是非こちらを活用してみましょう。
柄にもなくAmazonアフィリエイトリンクについて語ってみましたが、いかがでしょうか。
アフィリエイトリンクについて毛嫌いする方も多いとは思いますが、大多数の人にとってアフィリエイトリンク収入は雀の涙ほどのものです。
しかし雀の涙ほどの収入でも、利益があるというのは大変うれしいし、素晴らしいことです。
もしかしたら人生になんの希望も愛も感じられなかった人が、とある人からのアフィリエイト収入で生きる希望を見出した、という事例もあるかもしれません。
良いアフィリエイト生活を。
| 世界一やさしい アフィリエイトの教科書 1年生 | |
 | 染谷 昌利 イケダ ハヤト ソーテック社 2015-01-17 売り上げランキング : 19281 Amazonで詳しく見る by G-Tools |
プログラミングはゾーンに入るまでの時間が長いため、スキマ時間にプログラミングをやることに対して躊躇いが発生してしまうことがあるが、 以下の理由からむしろスキマ時間にこそプログラミングをやるべきなのではないか。
この場合のスキマ時間とは 10分〜1時間ぐらいを指す。
スキマ時間ならばプログラミングに対するモチベーションが沸かないときにでも、心理的障壁が少ない状態でプログラミングに取り掛かることが可能である。
スキマ時間にプログラミングをすることで、コードは常に中途半端な状態になるため、この作業を終わらせたいという意欲が、じっくり取り掛かれる時間帯まで維持される。 それにより、じっくり取り掛かれる時間におけるプログラミングに対する心理的障壁が少なくなる。
1日30分、スキマ時間にプログラミングするとした場合、１ヶ月で 30 * 30 / 60 = 15時間 のプログラミング時間が確保出来る。
時間があると思うとだらだら作業しがちだが、30分なら集中した時間を過ごすことが可能
スキマ時間にプログラミングをやることに対して躊躇いは必要ないし、積極的にやったほうが良い。
UIEvolutionの創設者が実践してきた「時間術」が本書では披露されている。 著者が実績のあるエンジニアであるため、エンジニア視点から実践してきた「時間術」は説得力がある。
なぜ、あなたの仕事は終わらないのか スピードは最強の武器である | |
 | 中島聡 文響社 2016-06-01 売り上げランキング : 1011 Amazonで詳しく見る by G-Tools |
Flask には Blueprintというアプリケーションをモジュール化出来る機能が備わっていますが、このBlueprintのtemplate_folderパス解決にはちょっとした罠があります。
Flaskで以下のようなパッケージ構成を組んだと仮定します。
run.py
admin/
__init__.py
views.py
pages/
index.html
frontend/
__init__.py
views.py
pages/
index.html
admin/views.py
from flask import Blueprint, render_template admin = Blueprint('admin', __name__, template_folder='pages') @admin.route('/') def index(): return render_template('index.html')
frontend/views.py
from flask import Blueprint, render_template frontend = Blueprint('frontend', __name__, template_folder='pages') @frontend.route('/') def index(): return render_template('index.html')
run.py
app = Flask(__name__) from admin.views import admin app.register_blueprint(admin) from frontend.views import frontend app.register_blueprint(frontend)
一見template folder として admin/views.py では admin/pages/ を 、
frontend/views.py ではfrontend/pages/ を参照するように読めます。
しかしこのコードは正常に動作しません。
admin/views.py と frontend/views.py で template_folder が、admin/pages/ になるか 、 frontend/pages/ になるかは不定となります。
Flask Blueprintのマニュアルを参照してみると以下のように記述があります。 http://flask.pocoo.org/docs/0.10/blueprints/
So if you have a blueprint in the folder yourapplication/admin and you want to render the template 'admin/index.html' and you have provided templates as a template_folder you will have to create a file like this: yourapplication/admin/templates/admin/index.html.
つまり、以下のようなパッケージ構成にする必要があるということです。
run.py
admin/
__init__.py
views.py
pages/
admin/
index.html
frontend/
__init__.py
views.py
pages/
frontend/
index.html
admin/views.py
from flask import Blueprint, render_template admin = Blueprint('admin', __name__, template_folder='pages') @admin.route('/') def index(): return render_template('admin/index.html')
frontend/views.py
from flask import Blueprint, render_template frontend = Blueprint('frontend', __name__, template_folder='pages') @frontend.route('/') def index(): return render_template('frontend/index.html')
この仕様は度々Flaskの利用者に誤解を与えてきたようで、以下のように Issueでも議論にもなりました。 Blueprint template lookup not documented enough · Issue #266 · pallets/flask · GitHub
なぜこのような仕様になっているかというと、実装上の都合です。
Flaskで指定するtemplate_folderは Jinja2 の FileSystemLoader のsearchpathに渡されます。
searchpathはアプリケーションのトップレベルに追加され、再帰的に検索されるため、template_folderで指定したディレクトリ文字列がかぶっているとどのテンプレートを選択すれば良いのか一意に特定出来ません。
そのため、このような仕様になっています。
| Flask Web Development: Developing Web Applications with Python | |
| Miguel Grinberg O'Reilly Media 2014-04-28 売り上げランキング : Amazonで詳しく見る by G-Tools |
| Pythonスタートブック | |
 | 辻 真吾 技術評論社 2010-04-24 売り上げランキング : 1920 Amazonで詳しく見る by G-Tools |
最近にわかに注目を集めている炊飯土鍋。
私も同僚から布教されて最近炊飯土鍋を使い始めたのですが、すっかり虜になってしまいました。
「炊飯土鍋を使うと炊飯器が不要になる」、布教者は口々にそう言います。
しかし元々炊飯は鍋でしていたしそれを淘汰するメリットがあったからこそ炊飯器は消費者に広く普及したはず。
そう考えていた私はその布教の言葉に半信半疑だったのですが、実際その通りになってしまいました。
理由としては炊飯器と炊飯土鍋、どちらにもメリット・デメリットはあるのですが、 総合すると明らかに炊飯土鍋の方が上という結論に至る人が多くなってきた、ということでしょう。
比較するために、私の考える炊飯器・炊飯土鍋のメリット・デメリットなどを項目別にまとめてみました。 ３合炊きを前提とします。
炊飯器は安いものは電気釜で5000円ほど、IHで高価なものは５万ほどします。 炊飯土鍋は安い商品なら1500円ほどで購入でき、高いものでも１万円以内であることが多いです。
価格の面では明らかに炊飯土鍋に優位性があるでしょう。
炊飯器は機械的に壊れるリスクがあり、炊飯土鍋は割れるリスクがあります。
炊飯器が機械的に壊れた場合は、新品を正規のルートで買えば１年のメーカー保証があります。 炊飯器を１年より長い期間使用した時の故障率については、明確な資料がなかったため不明です。
ただ経験的に言うと私は、炊飯器はそれほど壊れやすいものではないと思います。
炊飯土鍋のAmazonレビューで安い商品は「炊く時に割れた」という評価がされている時もあるので、 意外と割れるリスクは高いのかもしれません（私の身の回りで割れた人はまだいませんが）。
ただ割れても安いものであれば１５００円ほどなので、あまり故障率は気にしなくても良いと思います。
物理的に落として割れるリスクが一番高いと思うので、炊飯器よりは慎重に扱ったほうが良いでしょう。
これは圧倒的に炊飯土鍋の方が良いと考えています。
炊飯器は高級なものであればあるほど美味しく炊けるのですが、最上位の炊飯器でさえ1500円の炊飯土鍋に敵わなかったです。
そして炊飯土鍋はおこげを簡単に作ることが出来、おこげの量で風味も変わってくるので、 味のバリエーションを簡単に出すことが出来るというメリットもあります。
また、私の経験的には炊飯土鍋で炊いたお米は冷蔵庫で冷やした後温めなおしても美味しさが劣化しにくいです。
炊飯器（電気釜）の場合は電源の確保ができるところ、炊飯土鍋であればガスが使用できるコンロが前提となります。
電源がない家屋はあまりないと思いますが、ガスコンロが使えない家屋はそれなりにあるため、設置条件は炊飯器の方が緩いです。
これについてはだいぶ人によって評価が変わりそうです。
炊飯土鍋は基本的に米を３０分以上水に浸すのが前提になりますが、炊飯器ではそういう前提は無いです。 ただ炊飯器で炊く時も水を３０分以上浸したほうが美味しく炊けるので、これについて私は特に炊飯器との違いを感じませんでした。
炊飯土鍋に比べ炊飯器は、安全に炊ける、予約機能が使える、炊きあがるまで時間管理をしなくて良いという長所があります。
炊飯土鍋の場合は火を使うため、時間を測って安全と炊きあがりに注意して炊く必要があります。
炊飯土鍋は３合炊きの場合、火にかけるのは１５分ほどです。 コツを掴めば１５分タイマーで測ってあとは火事にならないように気をつければいいだけです。 むらす時間を併せても３０分ほどで炊きあがるので、炊飯器と比べてそれほど面倒だとは私は感じませんでした。
以上のようにまとめてみましたが、どの要素に重きをおくかというのは人によって変わってくるとは思います。
ただ多くの炊飯土鍋愛好家は、明らかな美味しさと手間はそれほど炊飯器と変わらないという認識から、炊飯土鍋を選択しているように感じています。
そして私の周りでは、炊飯土鍋を試してから、炊飯器を使う生活に戻った人は一人もいません。 そう、ただひとりとして。
既にちょくちょく炊飯土鍋の紹介記事が出ているので、私があえて宣伝する必要は無いかもしれませんが、 この記事で炊飯土鍋愛好家が増え、よりよい自炊生活を送るきっかけとなれば幸いです。
株式会社ドワンゴの運営するニコニコ動画にEmoji組版編集サービス artihata の紹介動画をアップしました。
artihata では言語はClojureとClojureのWebアプリケーションフレームワークである Luminus を採用しています。
ほとんどの実装はJavaScriptで記述されているので、Webアプリケーションフレームワークはあまり関係がないのですが、Luminusはテンプレートが豊富でぱっと実現したいサービスがさくっと作れるのが良いですね。
Clojureで一番のオススメWebアプリケーションフレームワークです。
Clojureは覚えることも少なく、プログラミング経験があまり無い人でもアプリケーションをさくさく書けます。
とりあえず、以下の書籍を読んでおけばアプリケーションを書くには必要十分だと思います。
| プログラミングClojure 第2版 | |
 | Stuart Halloway and Aaron Bedra 川合 史朗 オーム社 2013-04-26 売り上げランキング : 341785 Amazonで詳しく見る by G-Tools |
Clojureの日本語書籍も数冊出るぐらいになりましたので、ここで一つ2015年6月時点でのClojure日本語書籍についてまとめてみました。
Clojureの日本語書籍といえばまずコレ。
ハワイ在住Lispハッカーとして有名な川合史朗さん訳なだけあって、こなれた日本語での正確な記述は他のClojure日本語書籍の追随を許さないです。
内容も特別難しい訳ではないので、関数オブジェクト、ポリモーフィズム、マルチスレッドプログラミング辺りの概要が把握できていれば、 プロトコル、ソフトウェアトランザクショナルメモリ、エージェントなどのClojure特有の機能についてもすんなり理解できると思います。
プログラミングClojure 第2版
Clojureは言語自体の魅力もありますが、デファクトスダンダードとなっているLeiningen、Clojureらしいサウンドプログラミング環境Overtoneなど、Clojure独自の周辺ライブラリ・ツールも魅力のうちの一つです。
本書ではClojureでよく使われる一通りのツール・ライブラリが解説されているので、どのようなツール・ライブラリを使えば目的を達成できるかを考えるときに本書は指針になるでしょう。
ただしClojureの周辺ライブラリは結構個人依存のプロジェクトが多いので、メンテされなくなるものも多いです。 本書を参考にしつつも、今流行っている・メンテが継続されているプロジェクトを把握するためにはgithubを巡回したほうが良いでしょう。
dic.nicovideo.jp で有名になったニャンパス株式会社代表が執筆したのが本書。
内容自体は悪くないと思うのですが、 プログラミングClojure 第2版
Kindle専売のClojure日本語書籍です。 なんと１００円。 題材となるゲームをClojureで実装していく過程を追えるので、体当たり的に学習したい方はこの本がオススメです。
プログラミングClojure 第2版
Effective Clojure的なものが欲しい方にオススメです。
私が把握している限りで日本語でのClojure書籍をまとめてみました。 他にもClojureの日本語書籍を知っている方がいらっしゃれば教えていただければ幸いです。
さて、どの本を買えば良いかですが、個人的には プログラミングClojure 第2版
あまり踏み込んだ解説はしませんでしたが、とりあえず現時点での選択肢として以上にまとめてみました。
興味がある方の参考になれば幸いです。
ClojureのAgentの実装では、2 + Runtime.getRuntime().availableProcessors()で得られるサイズでスレッドプールを生成するが、このスレッドプールのサイズはset-agent-send-executor!に任意のExecutorServiceを渡して書き換えることが出来る。
set-agent-send-executor!が追加されたのはどうやらClojure1.5からのようだが、実装は、
(set! clojure.lang.Agent/pooledExecutor executor)
しているだけ。
以下のように使えばAgentのsend関数で使用されるスレッドプールを変更出来る。
(set-agent-send-executor! (Executors/newFixedThreadPool 20))
FlockingとはJavascriptで実装されたWeb上で動く音響合成エンジンです。
日本語での紹介記事が現時点で皆無なので、紹介したいと思います。
Web Audio APIをラップする形で実装されており、 ブラウザが対応さえしていれば、Flashなどのプラグイン無しでマルチプラットフォームの音響合成処理を行えるのが特徴です。
このFlockingを使用し、実際にどのようなことが出来るかというのは、まずデモを見ていただいた方が早いと思います。 http://flockingjs.org/demos/interactive/html/playground.html#amp_mod
上記のデモにあるコードはブラウザから直接書き換え・実行することが出来ます。 そのためしばらく触っていれば、どのようなことが出来るのかはおおよそ把握できると思います。
JavaScriptの連想配列で柔軟な設定が行えるため、 ひと通りの音響合成を複雑なコード無しに実現することが可能です。
Flockingを使用する上で最低限理解する必要がある概念は下の４つです。
Unit Generatorsは音声合成のベースと波形を生成します。 このUnit Generatorsによりシンセサイザーをコントロールする波形、シンセサイザーの入力波形を生成することが可能です。 Unit Generatorsは複数の入力と１つの出力を持ち、複数のUnit Generatorsを繋げることが可能です。
Unit Generatorから生成された波形を元に実際の音を生成します。 Synth自体にUnite Generatorが内蔵されているものもあります。 DAWなどでいうインスツルメントに近いです。
Unit GeneratorsとSynthsがそれぞれどのように繋がっているかを管理します。 DAWなどでもEnvironmentという名前で同じ名前が使用されます。
Synthsの実行タイミングを制御することが可能です。 DAWなどでいうシーケンサーに近いです。
今回は単純にFlockingの概要についてだけ説明しました。
次回は実際にFlockingを使用し、どのように音響合成を行うかについて説明をしたいと思います。
