Tokyo HoloLens ミートアップ vol.2 参加記録
hololensのイベントに行ってきたのでその感想記事です。
例によってアジャイルなブログを目指しているので内容はちょくちょく更新が入ります。
「HoloLens エバンジェリスト養成講座 その1」HoloLens アプリ開発の勘どころ
高橋 忍さん(日本マイクロソフト株式会社)
hololensアプリを開発する上での意識するべき点がまとめられていました。
(が、資料は見つからず。。)
〇hololensアプリの3タイプ
・ARタイプ(環境拡張型)
現実世界のコンテンツに沿ったオブジェクトの配置が必要
エレベーターメンテナンスの例(作業スペースが増える)
イメージとしてはこちら
・MRタイプ(環境融合型)
現実世界を認識筒実物を仮想要素に置き換えるもの
→壁や床の情報を認識する
現実が主役、穴を開ける、現実にテクスチャを貼る
・VRタイプ(仮想環境型)
holotourのようなやつですね、ほとんどVR感があるアプリです
誰が、何を、目的、対象を考えよう
〇ホログラムをどこに置くのか
1.25m〜5m 置く場所
1m〜 操作に適した距離
2Dのメニューは2mぐらいのところに置こう!(スタートメニュー等)
〇ホログラムをどのように置くのか
ワールドロック:机の上とかに固定すること
ディスプレイロック:ディスプレイに常に固定する←やらないほうが良い
ボディロック:体や頭に紐付いて少し贈れて動く、(スタートメニュー等)
〇ポリゴンとパフォーマンス
ポリゴン数は減らそう!
hololensはあくまでもモバイルデバイス!
大きいものは遠くに、
ホログラフィックをよりリアルに見せるには?
重力加速度に応じた動きをするとリアルに見える
HoloLensであんなことできたらいいなを実現するUnityアセット達(ゆーじ @yuujii さん)
ライブコーディングをしながらいくつかお役立ちのアセットを紹介していただきました。
Krabl Mesh Processors
ポリゴン数を削減用
Hologram Shader Pack Pro
3DCGをスケルトン状態にできるみたいです
Vuforia
実物から3Dモデリングを起こしてくれるみたいです(別途色々必要)
Unityで始めるHoloLensアプリ開発(仮)
能代 和哉(のしぷ@noshipu)さん(株式会社 ViRD)
いくつか開発に役立つ話を事例を基にお話しいただきました
holotoolkit-unityを使おうぜ!
→絶賛更新中で破壊的な変更がどんどん入るので注意!
Demoを実行しよう
Academyをやろう
〇開発事例の詳細
ENGLISH BIRD SELECTが言えないユーザーのための発音トレーニング
キャラクターを小さくする
小さいと可愛い
視線誘導は使わない(鳥が多すぎて画面が煩雑になるため)
ホロジラフ
★プレイエリアの確保
3Dプリンタ転送召喚を使う
プレイヤーの視線をコントロールする
開発tips
リモートでは動いたmonoがビルドすると動かない
→権限関係
AssetStoreは要確認
TextToSpeechでログをしゃべらせると便利
VRSamplesを使うとUtniy でのアプリの作り方が分かる
↓メモだけ残ってるけど何を現しているのかよく分からない単語
Object Pool
UIFade
スライダー系
MakeBoxを使うと簡単にunity用の3Dモデリングが作れる
UWPって何?HoloLens上で動くアプリができることできないこと
津隈 和樹さん(日本マイクロソフト株式会社)
結局UWPがなんなのか分かりませんでしたのでメモも体系的ではない適当なものになります。
とはいえ、ストアアプリへのリリース関係など気になるところがきけて良かったです。
ストアを見てアプリにホログラフィックとついていればそれはhololens対応
デスクトップアプリとUWPの違い
Universal
Windows
Platform
Identityの中にタイトルやパブリッシャーの情報が含まれている
アプリ内課金をローカルで試すことができる
日本からhololensアプリはまだほとんどでていない!
2000円でアカウントは一生!
appsになるのがUWP(.exeじゃないよ!)
appcontainerってレベルで動く(exeとは違うよ!)
アプリケーションの置き場はアプリケーションの内部に置く?
マニフェクチャで機能の解除ができる
ピクチャーROLLはあんまり使わない
UWPは一つのアプリしか起動出来ないので勝手に終わる可能性がある
Sharing Deep Dive
sharing機能についてのお話しです。
空間アンカーは共有座標系の認識が大変
Sharingを甘く見るな!!ということです。
サンプルやればできるんでしょと思っていたので、正直これをやるときは腰を据えてやらないとだめそうですね
まとめ
色々なお話しが聴けたので長野唯一のホロレンジャー(自称)としてはこの手のtipsを活かせるように開発どんどんしていかないとな!!って思いました
python勉強会 in 長野#1の内容振り返り
お待たせしました、やっと本編のまとめ記事です。
オープニング「StartPythonClubとギークラボ長野の関わり」 ダメdeath.py (@nakajidamedeath)
ギーラボの紹介とかです。(当ブログの執筆者です)
講演②「長野で語るStapyのビジョン」Takeshi Akutsu (@akucchan_world)
元々オープンソースカルチャーが好きというのが原点にあるので、説得力もありますし、阿久津さんの熱意やがんばりを聴くと自分も何か頑張らなきゃ行けないと感じますし、モチベ向上に繋がります!
何よりも毎月欠かさず勉強会を開催し続ける継続力には頭が下がります。
講演②「もうpythonを始めるしかない」辻真吾 (@tsjshg)
http://www.tsjshg.info/Stapy_Nagano_Tsuji.pdf
pythonが世界的潮流になっているから今から勉強するならpythonだぜ!という話です。pythonの良い点が多数上げられています。
環境構築についてですが、辻さんはデータ解析系ということでanacondaを進めてますが、個人的にはweb系をやりたいときはvirtualenvなどの仮想環境でデータ解析系が前出のanacondaなのかなぁと勝手に思ったりしてます。
もちろん最初はとにかく動かすのが大事なのであれこれ迷わずにどれか一つの方法を決めてanacondaで始めるのも全然ありです。
「DjangoでさくっとWeb アプリケーション開発をする話」中澤祐一 (@y_nakazawa1220)
実はDjango自体さくっとしていない・・というのは置いておいて、初心者のweb系の方はだいたいbottleやFlaskがお勧めされていますが、実際に運用するようなもの、本番がある物に関してはDjangoで作るのが結果的には早くなると思ってます。
もちろんDjangoのプロジェクトを作るとたくさんのファイルができてしまい、初心者はそこで嫌になってしまうので勉強目的でのDjangoはお勧めしません。
最終的にデータベースとの接続やセッション管理などをほとんど裏側を気にすることなく使えるDjangoは実戦においては必要になってくると思うので、やってみたい方はこのスライドを参考にしてみてはどうでしょうか!
またこのスライドは実際にクラウドにupするところまで乗っていますので、本番開始までこれで行うことができます!
「ディープラーニングハンズオンを準備して学んだこと」Kiyoshi SATOH (@stealthinu)
ディープラーニングの数十年分の歴史を辿りつつ、パーセプトロンではこう、その解決としてのバックプロパゲーションではこう、色々あって今のディープラーニング(ニューラルネットワーク)ではこう、という考え方とその限界、そこから生み出された新しい手法を理解しつつ必然的にCNNになったということが分かるような仕組みでハンズオンを行ったことが分かります。
環境構築に関する話などもあるので、今後ディープラーニング系のハンズオンを行う方は、是非参考になさってみて下さい!
ここでもこのハンズオンを行った原動力が佐藤さん自身の大学生時代の経験によるところが大きいそうでこういう個人の自我に基づく発表というものは熱意の伝わりやすさが段違いだなぁと感じました。
LT①「オープンハードカンファレンスの紹介」 chinoppy (@chinoppy0727)
みんなきてね!
LT②「とあるプログラミング初心者の学習記録」sizumida
なんと中学一年生でDjangoアプリを作っているというエリート少年!のLT
アプリを作ってお金を稼いでNintendoSwitchを欲しいという動機も分かりやすくていいのですが、自分が中学生のころにお金を稼いでゲーム機買おうって発想はなかったなぁ・・今回のイベントで一番注目を集めたプレゼンだったんじゃないでしょうか!
LT③ 「PythonでつくるSlack Bot」 Akira Nonaka (@anonaka)
Twilio的なサービスを展開されている会社のようでなんと、このためだけにはるばる横浜からお越しいただきました!
最年少LTの後に最年長LTとなって、python界隈の年齢層の広さを感じました。
まとめ)
阿久津さんや佐藤さんの話を聞き、何かをするきっかけは、オープンソースコミュニティが好きだったり、学生時代の疑問を解決したいという思いだったり、やはり技術を習得するということには、モチベやきっかけが重要だと感じました。
自分にとって今のところ新しいプログラミングスキルを修得する理由がお賃金の上昇ぐらいしかなく、何かに熱中したり人間性を捧げて行きたいなと改めて感じました。
東京にあって長野にないもの、それはきっと同業者同士の刺激の有無だろうし、それが足りないから地方は衰退していくんじゃないのかとも思います。
刺激を求めて東京に出ていくのもいいと思いますが、どうしても都会では生きていけない人もいますし、地方で生きていかざるを得ない人たちもいます。
ギークラボ長野はそんな都会嗜好だけど地方で暮らしたい人にちょっと都会の刺激に近い何かを与えられる場所としてなっていければいいなーと思いました。
ということで、pythonに限らず地方のIT産業が発展するといいですね!
python勉強会 in 長野#1の運営振り返り、当日編
python勉強会の振り返り記事です。
今回は当日の動きについて書いていこうと思います。
前回の準備編はこちらになります。
1)準備編で書き漏らしたこと
〇ネームプレートを用意した。
せっかく色々な人が集まる場なので、懇親会では全力でコミュニケーションが取れるようにネームプレートを用意することにしました。
以下のサービスで参加者のネームプレートが作成出来ます。
こちらですが、役に立ったのか立たなかったのか正直よく分かりません。
ただ、あのTwitterアイコン人はこの人なのか!!というきっかけにはなりました。
理想的には私はこんなことに詳しいですとか、こんな立場ですみたいなのが可視化出来れば会話のきっかけになっていいんじゃないかなぁと思います。(とはいえちいさなネームプレートにそれを全部書くのは不可能に思えます)
みんなでhololensを付けて、ネームプレートにQRコードを付ければどんな人物か分かるとかあると良いですよね、みんなhololens買いましょう
2)当日の反省点
・オープニングの準備はしていたのにクロージングのセリフとかを全く考えてませんでした。
・一人の講演が終わった後に質問ありますか、では終わりですみたいな感じでテンポが悪かった。
→一人一人の発表が終わったらホスト側として自分も立ち上がってコメントしたりするなどホストとしての役目がもっとあったなぁと思ってしまいます。
・受付は2人いたほうが良い
40人近くのイベントで集金がある場合受付は2人いたほうが良いです。並びます。
焦らせてしまいます。
イベント開始後もまだ来ない人がいた時、受付の人は外で待ってなきゃいけないので、できれば話を聞かなくてもいい非エンジニアの人が理想ですね。
・雑務を頼める人がいないとだめ
当日は色々起きます。写真を撮る人、案内の貼り出し、これが足りない、Twitterにも書き込んでイベントを盛り上げる人、バリスタの水が終わった等々雑務力が必要になります。
その際にはやはり非営利人件費0で運営しているギークラボ長野としては、動かしやすい若者が多く参加してくれると非常に助かります。
年を取ってもう新しい技術を学ぶことを諦めた人が何かに自分にできることを探して雑
務のために参加してもいいんですけどね
・お菓子は配ろう
会社にある謎のお菓子を今回イベント用に提供したのですが食いつきは悪かったです。
会場が狭いというのもありましたが、もっと配布しても良かったように思います。
また、バリスタは休憩時間中大混雑だったので、先に紙コップで注いで置いて配布するなどの工夫があっても良かったかも知れません。
まぁ運営スタッフが少ないので難しいですけどね
・時間の見積もりが甘かった
当初はLT希望も少ないし、時間的にも余裕があるからと言うことで、時間設定を割と適当にやっていたのですが、結果的にはかなり押してしまい、自分が用意したLTをスキップするハメになりました。
スキップしたのが自分のLTだったので全然OKなんですが、これが違う人だったら大変でした。。講演時間の設定はきちんとしないとダメですね。
・LTを1人飛ばしたことを伝え忘れていた
LT参加者には事前に何番目か伝えてあったのですが、当日自分の順番を飛ばしたことを伝え忘れてしまい、次は貴方です、と突然伝えることになってしまいました。すみません。直前までLT準備しているような方でなくてよかったです。
・会場の空気をホットにするのは大変
自分のようにふにゃふにゃした人間は実に締まりが悪く、話をしていても、どうも話の終わらせ方、次への移行の仕方、要は参加者の心のつかみ方がが上手くいかなかったように思います。これはまぁ今後の課題と言うことで。。。
とりあえず、運営的目線はここまでということで次回でやっと内容について入っていこうと思います。
3)当日のトラブルについて
当日はトラブルが重なって講演者の方が遅刻するという事件が起きました!
結果的にはその方の登壇時間には間に合ったので良かったのですが、例えば来られなくなってしまった時に備えて時間調整用のLT資料みたいなのを隠し持っておくのはありかもしれません。
何事もコンテンジェンシープランは必要ですね。。。
スタッフへのねぎらい)
これが一番必要なことだと思います。ギークラボ長野のように日本システム技研が運営する形を取りながら、人件費0で運営する組織の場合、どうしても「社員の自発的なイベント参加」という圧力がかかってしまいます。
休日にある種のボランティア的な活動を強いるような活動は本来おかしいと思ってますし、ある種の会社からの同調圧力をかけつつ、実は体制側の人間が雑務をすることに非協力的というのは実はかなり問題だと思ってますが、ここでこれ以上話すのはqawsedrftgyhujikoなのでやめておきます。
せめてもの報酬としては、余ったお金、お酒、お菓子の分配が必要だと思っています。
またその際にイベント主催した人(今回の場合自分)はなるべくおこぼれに預からないようにしました。
(今回のpython勉強会では2000円弱の余りがでたので車をだしてくれた人、受付や片付けなどで残ってくれた人達で分配し、残った酒や菓子を分配するというお目こぼしを行いました。)
実を言うと勉強会に出ることは勉強ではないと思っています。
そこで得たこと、話をして聞いた知識を実践して始めて勉強会にでた意味は出てくると思ってます。
だから興味がないイベントに人数合わせや雑務のために参加を強いることは、その人の時間を奪う殺人的行為だと思っています。
本当であればこういう個人の犠牲に寄らないイベント実施が理想なんですが、それはギークラボ長野の今後の課題かなと思います。
まとめ)
・Itイベントの運営(無報酬非営利)がやることとして心がけることは、とにかく当日の手間を減らすこと!
・雑務を振れるスタッフを何人か用意すること
・手伝ってくれたスタッフには少なくても直接的な利益を分配しよう
この2点に尽きるのかなと思ってます。
逆に言うとこの2点が満たせない場合は、懇親会を開催しないなどの思い切りが必要に思えます。
ITイベントの運営で疲れることは、本来のエンジニアの業務ではないのですから。。
深夜テンションでやべーこと書いちゃったけどこのまま公開しちゃいます(はーと
3月20日unityの勉強メモ
4月に開催されるオープンハードカンファレンスで披露するアトラクションに向けてunityの勉強をしているのでそのメモです。
体系化とか整理とか正しいとか間違ってるとかじゃないです。
初心者なので理論はありません、経験的なもので書きます。
僕のメモです。
○とりあえず火を飛ばしたいimportしたStanderdAssetからwildfireを選択
それを適当なCubeかなんかにつけると、そのcubeの移動に合わせて火も移動する。
○オブジェクトに取り付けた.csにこんな書き方をすると移動し続ける
this.transform.position += new Vector3(0, 0, 0.1f);
床の上に置いたはずのロボットにRigibodyのコンポーネントを追加すると下に床があっても落ちてしまう。
BoxColliderをそのロボットに追加したらなぜか落ちなくなった。
まぁいいか
このBoxColliderっていうのであたり判定しているみたいなのでそれのサイズを大きくしてやることであたり判定も大きくなる模様
火の演出について
firebollを投げて相手に当たったら爆発というのを作りたいのですが
標準アセットのWildFireというのを使ってそれをSphereオブジェクトに取り付けて、Sphereオブジェクトを動かしてみたところ、なんかSphereオブジェクトが分身し続けて一気にメモリー不足に陥って固まる。
なんだかよくわからないけどこれ使わない方が正解なんじゃ・・・
うーん、なんかほかにもいろいろ不安定になるし、unityはプログラミングを学ぶというよりはunityを覚える感じなので、とりあえず触り続けていきたい
python勉強会 in 長野#1の運営振り返り、準備編
先日(2017/3/18)に長野で開催されたみんなのPython勉強会 in 長野 #1の振り返りレポートです
※納品のないブログを目指しているので写真等は後で追加します(単にカメラを会社に置いてきたから入れられないだけです)
開催前の不安要素
1)人数が集まるのか?
・東京では平日夜に100人以上の集客を見せるStartPythonClubですが、長野でそんなに集まるのか?(わざわざ東京からお越しいただて10人とかだったらどうしようという心配)
そもそも東京の人口が1000万人、長野県の人口が200万人(長野市に限ると38万、周辺を入れても40万人!)
1000万人VS40万人というとんでもない人口格差があります。
ただし、長野市は実は地政学的にはかなり有利な地で信州大学の工学部と長野高専があるため、地方としてはITイベント開催の需要がある土地ではないでしょうか?
実際に当日は学生枠で工学部の方と高専の方に来ていただいた上に、なんと中学生でDjangoをやっているという方にまで親子連れの方にまで来ていただきました!
告知に関してはツイッターだけでなく社内やFBや関係各所にイベント通知をしてもらい、当日には38名という集客をたたき出し、逆にこれ以上人が来たらもう入る場所がないという逆に困った事態となってしまいました。
反省点
・今まで応募人数は適当に書いてましたが、いっぱい来そうなときは参加人数をきちんと絞ることも大事
・会場が窮屈で休憩時間の移動等が少し大変そうだった→会場を変える以外の根本的解決は難しいかな・・・
・ハンガーとか用意できればよかったかも
良かったこと
・FBなどのSNSや社内メール、知った人に口頭でイベント紹介するなどの工夫で人は結構集まる!
2)長野側からも講演者を出したい
東京からお越しいただいた二名にお話しいただくのは当然として、長野側からも講演できればいいなぁと思っていました。
弊社はDjangoしかやっていないため、社内で探すと全員Djangoの話になってしまうため、多様性に欠ける。
けどまぁ、一人は弊社よりDjangoの話で決まり
もう一人ですが、ギークラボ長野でディープラーニングハンズオン準備会を開催していたさとうきよしさんに依頼することで結果解決しました。
もちろんディープラーニング全部の話は無理なので、ハンズオン準備会を実施して得た知見の話を中心にしていただくことでなるべく負担にならないように配慮しました。
結果的にはかなりの分量のスライドを作っていただいて本当にありがたかったです。
長野みたいなオワッテル田舎にも人材がいることが改めて分かったようでちょっと嬉しいです。またweb系の話と機械学習系の話というのも結果的にバランスがよかったように思えます。
3)LT枠が埋まるの?
こちらも応募がなかったらどうしようという不安で一杯でまずは自分で一枠埋めて、後は次のイベントの告知で2枠となりました。
とりあえず最低限の形にしたところで、なんと中学生Djangoエンジニアの方と、普段横浜にお住まいの方よりLT希望があり、結果的に埋まることに成功しました!
最後にLTしていただいた野中さんはなんと横浜からお越しいただきました!
また、LTで会社の製品の宣伝をすることで、交通費を出るという事情もあったようでそういう需要もあるんだなと感じました。
反省点
・時間数をあまり考えていなかったので、適当に枠を用意したけど時間が押していたのでこれ以上LT希望があったら危なかった
良かった点
・なんだかんだでLTは集まる!
4)ビアバッシュの準備
懇親会にも30名という結構な規模の参加者が集まりました。
ビアバッシュでは以下の二点を重要視しました。
・みんなに飲食が行きわたること
・なるべく運営スタッフに手間がかからないこと
ピザだと楽ですがはっきり言ってコスパ面が辛すぎる面があります。
割引キャンペーン中の寿司やオードブル・仕出し弁当など色々検討しましたが、種類が増えるにつれてスタッフの手間も増大するため結果的にはピザで攻めましたが、今回は試験的に冷凍食品を導入してみました。
冷凍ピラフですと700Wで1/2袋で6分程度、基本電子レンジに放置してたまに取りに行けばいいので結構いいかなと思いました。
→結果的には食事が結構余ったため冷凍食品の効果測定はできませんでいた。二袋余りました。
ビアバッシュもある程度になるとみんな話に夢中になるので飲食に関しては少しでいいのかもしれません。
なお、筆者は1500円の会費で酒が飲めておなかを満たすためにカロリー計算までしていましたが今思うと無駄なことでした。。
反省点
・会社にある使える在庫の数を確認しておかなかった。→結果酒が10本以上と菓子はほぼ手つかずで残ってしまった。
・会費はもっと下げれたが1500→1200円とかなので徴収がちょっと面倒かも
・試験導入された冷凍食品の余りは次回何らかの形で使おうと思います。
良かった点
・ピザ注文に精通した社員が弊社にいたため彼の力でそれなりにピザを集めることができた
・前日にお酒とお菓子とつまみの買い出しを済ませておいたので、当日にスタックオーバーフローにならずに済んだ。
→なるべく前日までにタスク消化することで安心面が増します。冷蔵庫がある会場なら前日準備はマストです!
・バリスタ無料開放は結構好評だったかも!
SQLアンチパターン読書会参加記録7章と8章
2週間に一回ギークラボ長野で開催されているSQLアンチパターン読書会のメモです。
今までも時々参加していましたが、個人的にはアウトプットは必ずしていきたいので今回参加分からメモを残していきたいと思います。
マルチカラムアトリビュート(複数列属性)
連絡先テーブルに電話番号を持たせる場合、自宅、携帯電話、職場、FAX等の4つ分電話番号のエリアを用意すれば良さそうですが、携帯の2台目とか4つだけでは収まりきれない場合はどうすればよいのか?というのがテーマです。
本書では電話番号の話は最初だけで バグに対するタグ付けの情報をどう持たすかという例で進みます。
バグ情報にタグ付け(パフォーマンス、クラッシュ、印刷機能)をしたいということです。
〇アンチパターンな設計
これだとタグを4つ以上付けたいときどうするのか、また、パフォーマンスに影響するバグを探したいときに
where 'パフォーマンス' = タグ1 or 'パフォーマンス' = タグ2 or 'パフォーマンス' = タグ3;
などと検索しなければならずめんどくさいSQLになってしまうなどの欠点があります。
結論としては別の従属TBLを作成して解決になります。
まぁそうだよねって話ですが、少なくとも最初の例で出てきた電話番号の例ですと連絡先TBL.電話番号1〜3のような設計は普通にしてしまいそうだし、電話番号を別TBLに出すような設計を出した際に、上司を説得出来るかどうかはよく分かりません。
目的としてはデータの量が増え続けるTBLに対する速度低下をどうやって防ぐかというものになります。
バグテーブルにいつそれが発生したのかという日付を持ちたい場合で話が進みます。
テーブルの容量はどんどん数が増えるのでそれを年単位で分けて持ちたいという話です。
色々な例がでてきますが、解決策としてはパーティショニングと正規化を行おうというもの
〇水平パーティショニング
バグTBLを報告日の年単位でいくつかのテーブルに分けるように設定ができるようです。(これはしらなかったので普通にすごい!)
〇垂直パーティショニング
別の例として、Blob型やtext型を別の従属テーブルに切り離すことで処理を軽くすると言う話もありました。
(今回の例では直接関係なさそうですが)
〇解決
解決は7章と同じく従属テーブルの導入、、なんですが、バグ管理の話なのに突然違うTBLがでてきたのでよく分からないですね!!
バグの親にあるプロジェクトを年単位の子を持たせることで、その子であるバグも取りやすくなるよ??ということでしょうか??
注にはサマリーテーブルの改善であることに注意とありますが実は欲しかったのはバグのフィックス数だけで2016年に発生したバグの詳細はいらないということでしょうか??
最後よく分からなかったのですが(というかよく分からないことに今気付いたのですが、)とりあえず正規化しようぜ!って話でいいのかな・・とも思ったり(^0^;)
うーん、どこかで本書で想定されているTBL全体が分かってないとちょっとついて行けないですね。。
追記
テーブル全体の構成は本書の最初の方に乗っているという指摘を頂きました。
@nakajidamedeath "どこかで本書で想定されているTBL全体が分かってないとちょっとついて行けない"
— とみたまさひろ (@tmtms) 2017年3月16日
「はじめに」の「サンプルデータベース」を見るんだ!
BugsTBLはProductsTBLと多対多の関係を持っているので、Productの子に新たに作ったProductHistoryBugsを作ってそこでバグの件数を持つようにすればいいんだよという話のようです。
結局欲しかったのは ある年のバグの総件数だけってことなんですね〜
詳細も含めたある年のバグ一覧が欲しいのかなぁとおもっていたのでちょっと認識相違があったみたいです。
理解してないのに読み飛ばしてしまうことがあるので、やっぱり読書会はためになります。
余談ですが
とみたまさひろ (@tmtms) さんがSQLアンチパターンに参加されますと面白い話や補足的な話がかなり聞けるので大変面白いです!
途中からでもデータベース設計を仕事でやりそうだ!って人は是非ご参加下さい!
落合陽一さん、澤円さん、ちょまどさん登壇決定!CodeIQ感謝祭~聞いて触って感じるデジタルアートな1日!に参加してきた
2017/03/13 追記
アジャイルなブログを目指してるので内容をアップデートしました
いい加減技術ブログ始めたいなぁと思っていて刺激的なタイトルが良いなと思ったので脱職エントリーというタイトルにしてみました。
東京のエンジニアにとって退職エントリーを書くことはステップアップを意味するのでいつか僕も書いてみたいのですが、地方に住むとなかなか人の流動性は低いですね。
最初の記事がcodeIQという転職サービス会社のイベントの記事というのも意味深すぎてあれですね。
イベントはこんな感じ。そうそうたるメンバーです。
基調講演:落合 陽一さん 「ミクスドリアリティからデジタルネイチャーへ」
#codeiq39 楽しかった! pic.twitter.com/QPTbIZollL
— 落合陽一/Dr.YoichiOchiai (@ochyai) 2017年3月11日
ミクスドリアリティについてはMS社等の見解では仮想現実と物理的実体の間にある壁を取り払うことと定義されているようです。
デジタルネイチャーについては落合陽一氏によると
人間の感覚を超越した設計を行うことで、メディアが物質世界自体をプログラミングできるようになります。そして僕は、コンピュータが制御するモノとモノ、あるいは場と場の新しい相互関係によって作られ、人間とコンピュータの区別なくそれらが一体として存在すると考える新しい自然観そしてその性質を「デジタルネイチャー」と呼んでいます。(『魔法の世紀』p.179)
「魔法の世紀」はリアルとバーチャルの対比構造が、コンピュータによって踏み越えられ、作り替えられた世界です。(『魔法の世紀』p.180)
ざっくり言って氏がやりたいことは今まで映像でみてきた世界をどうやって現実に引っ張り出してくるかをテーマに研究されている方です。
有名なものに電子パルスで作った蝶々を現実世界に投影するというアートがあります。
hololensについては
触る必要がないものからMR化されてくるのではないかというお話でした。
例)飼ってる金魚を触る人はいないのだから金魚はMRに置き換えられるのではないか。またすごくリアルに作られた金魚なら本物の金魚と見分けが付かないからそれでよいのではないか
一方で飼い犬はもふりたいのでMR空間でモフモフできないとあまり意味がない。
これからの時代に求められるのは以下のようなものではないかという話で締められました。(結構早口で色々な話があって追い切れないので色々漏れてるかも知れません)
・筋肉ロボ
・介護の自動遠隔
・メディアアート
・ファブリケーション
落合陽一氏の 話を聞くと未来というものに対してすごく肯定的になるので話の内容以上にモチベ維持になるので刺激があっていいですね。
(余談ですが氏は人間と機械の違いについてモチベの有無と上げています)
セッション:伊藤 直也さん 「問題にフォーカスする」
ソフトウェア開発の文脈でマネジメントの話です。
この話は非常に実践的で面白かったです。
問題(issue)を見極める→要求をこなしていても良いものはできあがらない、まずは問題を正しく認識することが必要(木のブランコの絵で言うところの顧客が本当に求めていたもの、というやつですね)
参考文献
マネージャーの必要性についての話がありましたが、マネージャーというのは管理職だけではなく、開発もして良いし、それぞれの役割のスコープを狭めちゃいけないというのも新鮮な話でした。
まずは問題を対処するという最終的なゴールから考えよう!という根本を改めて認識させられたいい話でした。
経験談として、技術的負債には問題を正しく把握することに時間を掛け、問題を整理して言語化して行くことで少しずつ直していけるという話がありました。
技術的負債というものはどんな現場にもあり得ることですので、参考にしていきたいです。
余談ですがアニメネタがとても多いので面白かったです。
エンジニアにとってアニメはリベラルアーツになってきてるなぁと感じました。
VR tech Tokyo 諸星 一行さん VR体験ブース紹介
VRブースに出展されていたいくつかのコンテンツの紹介です。
イベント中は行けなかったので懇親会中に参加しました。
全部は体験出来ませんでしたが、以下を体験してきました。
・ゴジラ体験出来るアプリ
・オキュラスタッチを使った音ゲー
http://www.wandv.jp/service/product/seiya
・オキュラスを使ってチャットができるアプリ
VR VoiceChat with MUN - モノビットエンジン公式サイト
・オキュラスタッチを使ってゾンビと戦うゲーム
オキュラスタッチは本当に凄くて、これを使って体を動かすことでVR酔いという問題がだいぶ解消されるのではないでしょうか?
弊社にもoculusRiftDK2がありますが、CV1にしてタッチも欲しいなぁと思ってみたり。
高橋 忍さん(日本マイクロソフト株式会社) 「Microsoft HoloLens による Mixed Reality の世界」
弊社エバンジェリストの
— ちょまど@MS入社して11ヶ月 (@chomado) 2017年3月11日
高橋 忍さんによる、
MRデバイス Microsoft ホロレンズ のセッション! #codeiq39 pic.twitter.com/WlzkwGQ7aD
MRについてはフィジカルとヴァーチャルの融合とMS社では定義
基本的な説明とデモを行い
いくつかの事例紹介
こんな感じで検索すると事例がたくさん出てくるのでそちらを参考にとのこと
やはり社員教育(例えば飛行機のエンジンのメンテナンス方法など)や車のカタログ的な使い方(現実に車を投影)がされているようです。
hololensについては個人的に追っていきたいところですので、また詳しく調査します!
特別対談:澤 円さん、ちょまどさん (千代田まどか) 「まどかxまどかの『自分で創るエンジニアキャリア』
大変笑える面白いイベントでした。
澤さんは保険会社のCOBOL、千代田さんはエクセルスクショがエンジニアのスタートだったようで、両方だった僕はとてもシンパシーを感じております。
また、二人とも文系と言うことで、元々エンジニアの世界は理系エリートではなくても活躍出来る実例となっていて、個人的にはとても励まされました。
お二人のキャリアについて、苦労したことについて等を話されていました。
澤円さんはすごい話の収集力がある方でなんでも相談出来るすごい人って感じでした。
懇親会でも質問・相談者が列を成してました。
アウトプットの重要性については何度も話されていたので、自分もブログ等を通してアウトプットに努めていきたいと思います。
よく覚えているのは質問コーナーでの壊れてしまったエンジニアの再生方法で、とにかく自信を付けさせて、その人が活躍出来るフィールドを用意して上げることが大切と言うことでした。
総評
無料イベントなのにこれだけのメンバ-の話を拝聴出来た上に料理にお酒にレッドブルまでつくのだから東京のイベントはもうなんか色々と桁違いだな!と思いました。
懇親会の様子
懇親会結構色々あった。
— NYRL(ナイル) (@nyrl2010) 2017年3月11日
あとレッドブルお姉さんも三人ほどいて、SEIYA体験後にじーっと見られてレッドブル貰った。#codeiq39 pic.twitter.com/tUBaYe6EAP
地方の勉強会によく参加する身としてはなかなか地方勉強会の厳しさを感じずにはいられません。
人口は力であると同時に地方にしかできないことってなんなんだろうってやはり考えてしまいます。
本日のコードIQ感謝祭、ありがとうござきました✨
— きゃんち (@kyanchiaki) 2017年3月11日
まさかの可愛いケーキを頂きズゴック嬉しいです😂
落合陽一さん、伊藤直也さん、ちょまどちゃん、澤円さん、素晴らしい講演ありがとうございました!面白いこと沢山聞けたから役立てていきたい😆#codeiq #codeiq39 pic.twitter.com/XR649VCwND