サイト内検索
Translation here

2017/04/20(木)勉強会ネタ:人工知能時代の音楽制作への招待~Google Magenta 解説&体験ハンズオン

音楽AI.PNG

いつまでたっても音楽関連の才能を開花させられない野村ごろう(@official_nomura)です。
音楽関連の話は色々と縁があったんですが、ほとんどが失敗しているというか次につながらんのですよね。
とりあえず聞いているうちは分かった気になるんですけど、その後に続かないのでは習得できたうちに入らないので。

とはいえ、そこで諦めたら試合終了ですよ。
今回も諦めずに音楽やろう!

と思ったんですが、ハンズオンには参加できなかったのでエア参加する事にします。

ごあんない

この記事の勉強会

人工知能時代の音楽制作への招待 - Google Magenta 解説&体験ハンズオン -

対象者

  • なんでもAI教
  • 人工知能の可能性を模索している人
  • 人工知能+音楽でテンションが上がる人
  • 変わった事をやってみたい人

公式:対象者

  • 音楽への機械学習の適用に興味がある方
  • 音楽制作に携わっており、近年よく話題にされるAIが音楽制作にどのように活用できるかに興味がある方
  • 事前準備(後述)を勉強会当日までに実施し、事前準備したノートPCを当日持参できる方
引用です。

今回の記事は「どうしても行きたかったけど行けなかった」イベントです。

実際のレビューはハッシュタグ「#techcircleja」を私と一緒に追いかけていきましょう。
と言っても、エアハンズオンをやるだけです。

環境構築

今回は各自PCをお持ち込みいただき、そのPC上でハンズオンをしていただくことを想定しております。当日のハンズオンをスムーズに進めるため、事前に以下の準備をお願いします。

MagentaとSessionするためのStepByStep
もし不明点があれば連絡先、もしくは、当日お早めにご来場いただき、お問い合わせください。当日はスタッフメンバーもおりますのでお気軽に質問しながら進めていただければと思います。
ということで、事前準備からじっくり進めていきましょう。
この辺はハンズオンの前なのできっと出来るはず。

githubからcloneします。

(この記事はまだ書いてるです)

ハンズオン系はこの辺、大変です……

エンジニアの等級について

お疲れ様です、野村です。
最近自身の価値がどんなものなのか、考える機会が増えました。
そんな折、エンジニアの実力や肩書をどうするか、という話があったのでざっくり調べた感じと意見を述べてみたいと思います。

本日の議題

まずは定義

カテゴリ等級
シニア()アソシエイト
(チーフエンジニア)   
(プリンシバルエンジニア)   
(エンジニア)   
をクロスさせるイメージだそうです。
チーフエンジニアとプリンシバルエンジニアではひとつぐらい格が違っていて、
同じようにシニアエンジニアとエンジニアのように左右でも格が違う
カテゴリ等級
(将軍位)   
(佐官)   
(尉官)   
みたいな話ですね。
クロスした場所で中将とか大佐とか少尉とか呼んだりします。

念のため

カテゴリ等級
123
1123
10102030
100100200300
分かりやすいようにクロスした場所で掛け算やってますが、数値の幅はともかく順列的にこういう図になります。
数値が低いほうがエラいイメージです。

展開

プリンシバル級のエンジニアはマネージャーコースかエンジニアコースかを選ぶそうです。
いわゆるPMコースかハッカーコースみたいな、そういうイメージでしょうか。

ぶっちゃけ論

日本のプログラマー全体で見ると、そもそもプログラマーのレベルが低いので国内に置いてスーパープログラマーを目指すメリットは薄く感じます。
一部は国内の感覚で見るとバケモノじみてます。これはマジです。

とはいえ、日本企業は全体として過去の栄光や幻影(既存の業務システムやサービス等)に囚われているので、マネジメントすごい!といっても世界では通用しません。
本気でプログラマーをやるならとっとと日本から飛び出しましょう。オススメはみんな大好きシリコンバレー!
同じように、本気でマネジメントをするなら外資に行きましょう。

しかし、効率という点では間違いなく高い効果が見込めると思います。
まずはそこでやっていくための下地を作らなければなりません。

ちょうど関東には色々な勉強会をやってますし、他にも関西は大阪、ちょっと京都で、福岡(小倉方面?)はわりかし多いイメージですね*1

*1 : とは言え、東京の数と比べると絶対数が少ないです

今日本でスゴイ!と言われるエンジニアとは

これは私の偏見に満ち溢れた考察です。
大事なのは技術を使うこと、プログラム言語が分かることではなく、それらを使って生産性を上げる事が出来るか、に尽きます。
もっと言うと、自分で生産性を上げられる仕組みを考案し、実装し、運用するというスキルが求められます。
ざっくり言っちゃうと、現場作業員が社長でプログラム組んでる、というイメージでしょうか。
私も尊敬している故岩田聡 元任天堂社長のエピソードに倣うと良いと思います。
現在はスキルの差はあれど、プレイングマネージャー的な経営者は多くいますね。フリーランスエンジニアと言えばわかりやすいでしょうか。

具体的な話

これは私が理解できる範囲なので、正直レベルが低いと思います。
とはいえ、分からないものは語れないので、私が今わかる範囲で、主観的に星みっつぐらいで価値をざっくり設定します。
数が多いほど重要です。ついでに難度もざっくり書いてます。

因みにこれは業界も職種も不問です。ITやってるなら、という観点で書いてます。
ただし、デザイナーやマーケターは上記の○○エンジニアと言っていいのか微妙ですが、自分で当てはまるなぁ、と思ったら該当させておきましょう。

【難】★★★多岐多様のツールを使いこなせること

今私が思いつく限りで有名どころを上げるとAWS,IBM BlueMix,Slack,Jenkins,Docker(Kubernetes,FileMaker,Redmine,Backlog。
細かいところを言い出せば星の数もあるでしょうが、私が思いつくのはUnity,UnrealEngine4,BPM,AutoIT,Selenium,Jmeter,adiaryといったところでしょうか。
この辺は得意分野とか出てくると思います。

とりあえず有名どころは全部使えて当たり前みたいなところがありますね。
なお、これは使わないとどうしようもないやつです。イコール経験だと思ってもらってもいい。

プログラマーのスキルっぽいですが、マネージャークラスもこの辺ぐらい知っといてください。
たとえばJavaが慣れてるからJavaでシステム開発する、とかいうのは問題の先送りです。
ちゃんと技術的な要件は詰めておきましょう。
こうやって学ぼう!
正直、正解は案件によって変わります。これが100%正解というのがないからです。
ただし、正解に近づきやすい方法はあります。今人気の技術や基礎となる言語、考え方を習得することです。
案件Aでは全く役に立ちませんが、案件Bでは高い需要があったり、という事もあるので、自分にあったものを探しましょう。
技術も案件も、一つだけではありません。

【普】★★☆RestAPIを作れること・使えること

限りなく易に近い普。
システム間連携をWebでやろう!となったら多くの割合でお世話になる存在がRestAPI。いわゆるGoogleですとかFacebookですとかLinebotですとかもこれ。Twitterもですね。
いろんな所で公開されているデベロッパー情報の代表になるのがこのRestAPIで、ここから何が取得できるのかは各社でリファレンスを出されています。
これらをいい感じに使うテクニックを求められます。
こうやって学ぼう!
よく分からなかったらTwitterのbot作れるレベルぐらいに考えておいてください。
それだけでだいぶ仕組みが分かるんじゃないでしょうか。

【易】★☆☆自前でサーバー立てたり通信組んだり環境作ったり

これはずっと前から言われてますが、フロント・バック関係なく組めないと苦しいです。これが出来ないと上の項目はクリアできません。
自宅でサーバーを立ててみてはいかがでしょう?
こうやって学ぼう!
情報が多すぎるので、1から10まで全部順序立てて教えてくれるサイトに学ぶのが良いでしょう。順序立てた情報は本の方が良いことも多いです。
部分的な問題はピンポイントに検索して解決します。本の通りにやって上手くいかないから出来ない、ではエンジニアになれません。

【易】★★☆英語が読めること

英語のリファレンスが基本だと思ってください。
英会話に行く必要はありませんが、英語のドキュメントぐらいは読めないとつらい。
teratailで満足するのではなくて、stackoverflowに挑戦出来るレベル感がベスト。
こうやって学ぼう!
日本産のシステムよりは海外産のシステムに学ぶのが良いでしょう。
リファレンスも英語しかない。でもトラブルシューティングは日本語、みたいなのが良いです。
PHPとかJavaという基礎的な言語やスクリプトに戻って、使ったことのないライブラリを触ってみるのはアリですよ。

大切なこと

部門で一番を目指しましょう。
部門で出来ると認められれば、今度は部署で、会社で、プロジェクトで一番を目指しましょう。
会社やプロジェクトが窮屈に感じたら外に飛び出しましょう。ハンズオンやMeetupが良いです。いわゆるハッカソンやアイデアソンのような場に参加するのが良いです。
なお、ハッカソンやアイデアソンは賞金が出る事があります。一番になるということはそういう要素に挑戦できる権利を得る事が出来るのです。

ノマドワーカーの私が選んだリモートデスクトップサービス #splashtop #teamviewer #chromeリモートデスクトップ #検証

お疲れ様です、野村です。
ぶっちゃけGolang Hands-onの続き的な記事ですが、先にこっち出しちゃうのであんまり気にしなくていいかもしれませんね(笑)
そっちは上がったら案内します。

本日の議題

splashtop2って無料版もあるけど、今日は有料版のお話です

ついに有料だから、で敬遠していたsplashtop2というリモートデスクトップアプリを導入しました!
今更感すごいですね*1

TeamViewerと比べてsplashtop2を選んだワケもしっかりあります!
折角だから比較していきましょうか。

*1 : むしろ今までなぜ入れてなかったのか、という話にもなるんですが

無料 vs 有料

まずはじめに、この観点から始まります。
具体的には、月\0か\149?かの違い。
月額を払ってでも使いたいのにはワケがあります。
  • 家の回線が超不安定
    マジです、やってられません。
    プツプツ途切れながらやるのは結構ストレスになります。
    無料のsplashtop2で確認しているのですが、定期的に瞬断されるんですね。
    自宅のネットワークが悪いのか、と思ったんですがそういう事はなく。
なぜ宅内ネットワークで認識されてないのか分かりませんが、そもそも接続しているネットワーク側に問題がある可能性は否定しきれない(ないとは思ってますが)ので、
使用を見送ろうと思っていたところでもありました。

とはいえ、TeamViewerもそれはそれで問題があって、こっちは外からでもつなぎに掛かれるのが魅力なんですが、品質はあまりよくない。
長時間接続するとついには動かなくなります。
そしてクライアントがしょっちゅう死ぬ。

さすがに開発で使うものなので、そんな頻繁にパチパチ落とされてはたまったものではないです。

対策

目的は外でも業務ができること、に絞ります。

今すぐリモート開発をやめる前提でシンクラのスペックアップ

100%間違いないでしょう。リモート開発をやめる前提と書きましたが、やめる必要はありません。
ファットクライアントを使用しなければならないような理由がないなら、シンクライアントを強化すべきです。
間違ってもデータサーバーにアクセスするIPをファットクライアントのみに絞っているとかしょーもない理由で運用するものではないです。
紛失リスクを想定してシンクラを必要最低限にしていても、データが残っているとか運用を間違えたらシンクラにしてる意味がありません。
逆に、間違ったセキュリティ意識や運用をドブに捨てて運用を想定しているならシンクラをファットにしてしまうぐらいのつもりで使うのがいいです。
モニターが欲しいとかTwitterなどSNSを見たいなら小型ディスプレイを採用するのも良いでしょう。

しょぼいシンクラじゃなくて、それなりに使えるシンクラであることを想定します。
サブモニターの運用を検討しましょう!マジで。
あるのとないのとでは大きく違います。
私が使っているもの

AOC 15.6インチ USB接続 モニター ( 1366 x 768 / TN / 8ms ) E1659FWU-GP4R

気になったもの

【ノーブランド品】電源直結 7インチオンダッシュモニター FS-OMT70

使った事はないんで、ちょっとお試しでやってみるか!みたいなノリで使ってみてください。

リモートデスクトップアプリの併用

これは私は今も実践しています。
シンクラのスペックアップ+アプリ併用で可用性をあげる方法ですね。

この使い方は、シンクラで作成したファイルをファットクライアント側に転送してバックアップを取る、という方法が良いでしょう。
今風にやるなら、
  1. ファイル作成・バックアップ
  2. クラウドサービス
  3. ファットクライアントも連動(ファイルバックアップ)
というフローでやるのが良いでしょう。
クラウドも複数使っておいて、生のままファイルをやり取りするのにdropboxなりgoogledriveなりを使って、バージョン管理までやるとgitを使って過去の履歴を取る、という運用が良いと思います。
常に最新は取り続けて、ファイル管理は通常通りやって、という二重運用でリスクを最小限に抑える!

あとはリモートアプリ側の制御にさえ意識を向ければ無欠です。
上記で上げたTeamViewer・Splashtop2、chromeリモートデスクトップを全部入れてスタンドアロン状態にしておきます。
後はつながるもの、つなげたい操作感のものを全部入れればOKです。
chatworkとかRDPWrapでも出来たかな?まだここは触ってないです。
  • [(access failed) https://www.teamviewer.com/]
  • [(access failed) http://www2.splashtop.com/ja/download]
    リモートする側はパーソナル・される側はストリーマーを入れてください。
  • 紹介まで
chromeリモートデスクトップのちょっと注意事項など
  1. chromeは全く関係ない
    ブラウザのリモートではなくデスクトップのリモートです。googleアカウントのリモートヘルプを想定しているため、接続情報を許可すればやりたい放題です。
    アカウントに紐づくので、たとえばAさんがマシン1・マシン2を持っていてBさんにマシン1のリモートをお願いする、というシーンだったとしても、BさんはAさんの許可なくマシン2のリモートも可能なのです。
    また、一度許可すると明示的にアカウント側の設定でブロックしないといつでも接続できてしまいます。
    chromeリモートデスクトップでリモートヘルプをお願いするのはやめましょう
  2. googleアカウントが必要
    上で書いた通りですが、アカウントに紐づくので取得しておいてください。
    厳密には、取得はしてるけど使ってない人もいると思います(AndroidOSを使ってない人とか、MNPしてAppleIDに切り替えた人とか)ので、頑張ってアドレスを思い出すか、どうせなら新規で取っちゃっていいと思います。
    一瞬、その作業は発生します。

そもそもリモート開発をする必要のない状況を作る

それが出来たら誰も苦労しないよ!という話でもありますが、結構忘れがちなのでこの項目には書き起こしておきます。
色々な事情があると思いますが、そもそもなんでリモート開発をしているのか、見直すのも大事だと思います。

私がリモートワークをする理由

家に引きこもってゲームしたい!

これに尽きます。
まぁ実際はリモートワークだから家に引きこもります!と言うのかどうかはその人のワークバランスによるところがあるので、一概にどうとは言いません。
ただ、「今日は外で働く」「今日は内で働く」という選択肢はできます。台風の日にわざわざ出社するとかいうアホな制約から解放されるのは間違いないでしょう。

やるかやらないか、という基準も良いですが「選択肢を増やす」という事自体にも意味はあるでしょう。
OK キャンセル 確認 その他