Microsoft Azure x jThree Class Tokyo #2 に参加してきた
おはこんばんにちわ。
先日jThreeの勉強会に参加してきました。
2サイト合計130人突破!【jQuery初心者超歓迎!秋のWebGL+API祭り】Microsoft Azure x jThree Class Tokyo #2 : ATND
午前中にjThreeの解説をし、午後から協賛企業様が提供しているAPIを使ってハンズオンという形式でした。
協賛の企業様はコチラ!(敬称略、順不同)
* 日本マイクロソフト:Kinect for Windows
* テクニカルロックスターズ:Milkcocoa
* エクシング:IMINOS
* リコー:THETA
各企業様が持つAPIとjThreeを組み合わせて面白いモノを作るということで、、、
今日はスイカを作って揺らしにきました #j3_class
— きよぽん (@kiy0p0n) November 23, 2014
おっぱい揺らすつもりで参加しましたが、そんなハンズオンはありませんでした…
余談は置いておき、jThreeを触った感想と得られた知見をそれぞれ書いておきます。よろしくお願いします。
jThreeを触ってみて
非常に簡単に3DCGアニメーションが作れます
わりとこの一言で完結しそうです。
ブラウザ上で動くjThree専用エディタが存在し、GUI間隔でjThreeのプログラミングができます
ブラウザで作って即公開!MMDモデルも動く登録不要の『WebGL Editor』
jThreeの良いところ
* MMDのモデルやモーションを直接読み込める
* HTML要素を読み込める
* KANTAN
jThreeの弱いところ
* 処理速度は遅い
* ドキュメントがない
* 質を高めるための細かい実装はjThreeとは別で補ってあげる必要がある
感想
3Dで遊んでみたいと思う人の入門としてとても良いモノだと思います。
しかしながらやりたいこと(おっぱいを揺らすとか)が決まっている人にはちょっと物足りないなと感じました。
今後、jThreeでは3Dでできると思っているものは実装されるようなので期待したいです。
協賛企業のAPIについて
自分はエクシングさんのIMINOS触りにいったのですが、いいぞ〜コレとうなっていました。
なにが良いって、フツーに言語解析したらMeCab、CaboChaあたりを用意して手元で解析して、解析結果をごにょごにょするという手続きをすると思うんです。
それをWebAPIで文章を渡すだけで、解析結果をjsonで返してくれるという!
^q^ < ぅぇぇぇぶぅぅでぃぃげぇんごっっぉぉかぁぃせきいっぃぁお
とっても手軽に言語解析結果が利用出来るので、興味がある方はぜひ触って見てほしいです。
おちんぽのモザイクの検出器を作ろうとした理由
おはようございます、こんちにわ、ごんばんわ
今回はおちんぽのモザイクを検出しようと思います!!
そもそもなんでおちんぽを検出したいのか
数年前のネタなんですけど、フェラ画像のおちんぽ部分をSubwayに変えるネタがあったんですね
海外で「エロ画像で男性器をサブウェイにすり替える」って言うコラ画像が流行ってて、海外も日本に劣らず頭おかしいなって思った... pic.twitter.com/V6VYaJpQh8
— きなこ (@uiinya) 2013, 12月 16
これすげー天才だなぁと関心してしまったわけなんですよ
卑猥な画像を健全な画像に変えて公開できちゃう訳ですね
サブフェイのコラ画像を作るには
次の方法である程度形になる合成が出きるんじゃないかなと考えてます
- モザイク領域を検出する
- 領域に合わせてサブウェイをリサイズする
- Poisson Image Editingで合成
モザイク領域を検出する
モザイクの規則性を利用する
モザイクなんて同色の画素値が規則的な四角領域なんだろwww
とか軽い気持ちをもっていたことが僕にもありました。。。
確かにモザイクには、次のような性質があるようだった
- ひとつのブロック内の画素値が同色
- 上記のブロックが四角形で規則的に並んでいる
実際にプログラミングで検出しようとしてみると
- エッジ検出でモザイクの枠を検出→おちんぽ付近の色も近似しているのでうまくとれない
- 画素間の同色判定で検出 →おちんぽ以外の領域も検出する
- 画像毎でモザイクのブロックの大きさが違う
ひとえにモザイクといっても多くのバリエーションがあってなかなか汎用的に検出が難しいという壁に出会ってしまった
モザイクの検出器を作る
プログラミングで規則的な領域を見つけるのが難しいなら、
モザイクを検出する器を作ろう!と思い至りました。
以前からopenCVで検出器を作れるという知見があったので、
良い機会だし実践してみることに
導入おわり
検出器作成にいたる背得を書かせてもらった、次回は実際の体験をなぞって記事を書く
ひとつ言いたいことは、
おちんぽには勝てなかったよ。。。
ということだ
YAPC2014参加してきた【2日目】
宗教上の理由で休日は家から出れないのですが、
無理をしてYAPCの2日目に行ってきました(ネタ
久々のカンファレンスで体力的に辛かったよ!
人気のセッションは座席が足りなくて床に座って聞く人が沢山いたのは改善点だと思います!
以下、2日目に聞いたセッションについてのメモ
###############################################################:3#
【セッション】Dockerで遊んでみよっかー (40 分) Masahiro Nagano
【知見】
- Dockerはまだ若いサービスでベストプラクティスがまだない
- Dockerとはアプリケーションの開発、配布のためのプラットホーム
- ファイルシステム、ネットワーク、プロセステーブル、ユーザ権限、リソース権限がコンテナによって制御、隔離される
- コンテナの生存期間はプロセスの終了まで
- Dockerfileで簡単設定
- ファイルシステムの変更もプロセス終了時に消える(揮発性
- 差分イメージで変更部分だけ変えたビルドができる
- Vagrant上で起動すればホストとのファイル共有もお手がる
- Docker Hubで他の人が作った環境をゲットできる
- 問題は、ファイル共有時に上の階層が見えない、port forwardが面倒
【感想】
perlならCarton+cpanm、RubyならBundle+gemで開発環境を簡単に構築できる。
さらに、Dockerならディストリビューションから構築できる!
(CartonもBundleもDockerには勝てなかったよ…状態
現状のアプリケーション配布もだいぶ楽になったけど、開発環境から数個のコマンドで
構築するように世界が変わっていきそう。使う側の幸せ
###############################################################:3#
【セッション】半端なPHPDisでPHPerに陰で笑われないためのPerl Monger向け最新PHP事情(5.6対応)(40 分) うずら
【知見】
【感想】
すごいネタ感があった、PHPもやれば出来る子ろいうことだけ理解した
###############################################################:3#
【セッション】ほんとにあったスキーマの話 「ソーシャルゲーム」 (40 分) こばけん
【知見】
- 誰が使っても、解釈がかわらないようにスキーマを決める
- ソシャゲの場合はユーザからサーバのアクセスによりサービスを受ける
- ユーザは行動に応じた対価を得る
- 更新対象がユーザ自信、ユーザの行動によるUPDATEが多い
- 更新頻度の高いポイントだけ別スキーマで管理
- ex. 所持モンスターはカードのidと経験値だけ持たせる、成長率は別に管理
- 欲しいデータはindexを舐めるだけで終わるようにする
- ModelとDB層は分けて考える
【感想】
ソシャゲから見たDB設計の話
業務中にも感じることだが、情報を一つのテーブルで管理しようと思うのではなく、
独立に分解できるレベルで管理することがベストだと認識した。
ユーザの行動がいちいちDBのUPDATEになるなかでの効率的な運用が気になった。
###############################################################:3#
【セッション】モバイルアプリとAPIのありかたを考える2014 (40 分) あらたま
【知見】
- アプリは小さく出してコツコツ改善が難しい
- MBaas ( Mobile Backend as a Service
- 代表格Parse:でーたストア、プッシュ通知、解析、pluginなどバックエンドをまるっと面倒みてくれる
- 面倒なデータの同期も簡単にできる
- ユーザの体験を最大化したい→一つの更新データ毎に通信は体験の価値をさげる
- まとめてreq/resがしたい→JSON-RPC2.0のBatch
- ユーザの行動分析のために、ユーザの操作ログを送る時に便利
【感想】
通信を行うアプリケーションは環境を整えるのに時間がかかると思っていたが、
MBaaSのおかげでとても敷居がさがった
また、JSON-RPC2のBatch処理も有益だ
あらたまさんが利用しているライブラリが今後公開予定ではあるので、
ぜひ情報を追っていきたい
この発表を見ていて、アプリ開発って怖くないなと思えた
###############################################################:3#
【セッション】Perl5 meta programming (40 分) karupanerura
【知見】
- メタプログラミングは自由!だけど自由には責任が伴う
- メタプログラミングはパッチが当てやすい
- テストは必ず書く事、また、既存モジュールで解決できるのであればメタプログラミングはしない
- シンプルに表現出来ない場合は素直に諦めたほうが良い
- perlのメタプログラミングはstring eval, universal
- string eval:文字列で書いた関数がそのまま実行される
- universal:全てのpackageにbaseされる
- string evalを使う場合、条件処理などは文字列で埋め込むようにする
【感想】
メタプログラミングが向いている所と向いていないところの判別が難しそう
perlのevalなどは出来れば使わないで生きていきたいと思っていたけれども、
適切に使えば非常に強力だ
メタプログラミングについてもっと知りたくなった