技術書典に一般初参加してきた話
今日は秋葉原・アキバスクエアにて開催された「技術書典2」というイベントに行ってきました。
開場前
去年の技術書典は参加していないのですが、事前に確認した情報によると去年は会場前に整理券が配布されるほどの大盛況だったらしいので、少し早めに家を出ました。
しかし、余裕を持って少し早めに開場に到着したのですが、すでに大きな列ができており1列8人で並ぶようにアナウンスがあり整列。
自分が並んだ時点で150人ほどの行列ができていたようです。
その後も列は大きくなり、開場をぐるりと反対側まで列が伸びていました。。。強烈。。。
小雨も降る中だったので、雨除けが着いていない場所に並んでる人はしんどそうでしたね。。。
入場
開演時間の午前11:00から5～10分遅れていよいよ開場。
入場の際には「2バイト（2列16人）ずつで入場してくださいー」とのアナウンスがｗなるほど、1列8人だったのはそういう意図（8bit）があったんですねｗ
いざ入場すると、通路は少し混んでいたような気もするけど、それほど強烈な、行ったこと無いけど想像するコミケ的な殺人的な混み方は一切なく目的のブースもすんなりと寄れました。
目的のブースを一通り回った後はチェックしていなかったけど面白そうなブースにも寄りながら散策。自分はソフトウェア系の本を目的に行ったんだが、FPGAとかスピーカー工作のようなハードウェア関係のサークルも多く色々面白そうでした。
戦利品
私が購入した戦利品はこちら。
- WANTEDLY TECH BOOK #1
- WANTEDLY TECH BOOK #2
- WANTEDLY CULTURE BOOK 2016
- アプリケーションパフォーマンスTips
- GAS “Automation” Book
今回のメインの目的はWANTEDLYさんの実務経験から得られたTipsをまとめた「WANTEDLY TECH BOOK」だったのですが、こういった実務から得られた経験をまとめた本ってなかなか無いと思っていて、このような知見を得られるのは貴重だと思う。
アプリケーションパフォーマンスTipsはこちらも実務経験を元に得られた知見をまとめたものとなっている。実務の上で遭遇するであろう課題が体系的にまとめられていて、サンプルコードも公開されていてサポートも手厚い。
GAS"Automation"BookはGoogle Apps Scriptを使用した自動化入門書。GASは今まで触ったことがないので、これを機会に自動化するために使っていきたい。
超技術書典
4月29～30日に開催される「ニコニコ超会議2017」にて技術書典も参加するようで、その名も「超技術書典」らしいです。
興味がある方はこちらも参加してみてはいかがでしょうか。
DeNA TechCon2017に行ってきました！
日にちが経ってしまいましたが、去る2月10日にDeNAさん主催のDeNA TechCon 2017に参加してきました。
会場とそれぞれのトーク
去年に続き2回目の参加になります。
会場にはステージが5つありまして、それぞれ
となっておりました。
メインとなるAステージでは、トレンドであるAIに関する技術の発表が主となっており今の時代のトレンドであることを改めて強く認識できました。
去年はDeNAエンジニアの飛び込みのLTが行われていたのですが、今年はE-STAGEとしてスケジュールが組まれていました。
トークとトークの間の休憩時間は20分あり、かなり余裕のある感じで知り合いのエンジニアなどと近況を色々と話すこともできました。
トークも盛り沢山でクロージングが20時を過ぎるという感じでした。
聞いたものは3つ
私用の関係で聞けたトークは3つ。
- 深層学習による機械とのコミュニケーション
- Anyca(エニカ)のC2Cビジネスを支えるシステムと運用
- Unityネイティブプラグインマニアクス
自分は機械学習や深層学習といった分野は全く知らないのですが、深層学習のトークは聴いていてわからないなりにも興味が持てた。
年によってトレンドの移り変わりがあるようでそのキャッチアップは大変そうだけど面白さもあるでしょうね。
単語の表現ベクトルの話が特に印象深くて、単語の意味をベクトルで表現したときに例えば「Berlin」「German」「France」という単語をベクトル計算でvec(Berlin) - vec(German) + vec(France)としたときに、計算結果が「Paris」となったという話。
なんでそんなことになるのかは詳しい話は時間の関係で省略されたのですが、この結果もたまたまそうなったという部分が大きいらしく（？）聞いていてかなり興味深かったです。
カンファレンスのメモは以下↓
DeNA TechCon 2017
深層学習による機械とのコミュニケーション 株式会社Preferred Networks海野裕也様
深層学習のトレンド推移
- 年によってトレンドが変わる
- 深層学習は2012年は自然言語処理の中ではそれほどトレンドではなかった
- 2013年にWord2Vecの登場で注目され始めた
- 2014年LSTM, 符号化複合モデル
- 2015年は注意機構（Google翻訳の生後向上はこれがキーになっている（？））
- 2016年ｍ畳み込みネットワーク
深層学習の登場で何が変わったのか
- 表現ベクトルの学習が可能になった
- 一気通貫の学習が可能になった
- より応用よりの研究が増えている
表現ベクトルの学習が可能になった
- 各単語の「意味」を表現するベクトルの話
- vec(Berlin) - vec(German) + vec(France)と一番近い単語を探したらvec(Paris)だった
- ベクトルの計算でたまたまできた(?)
複数の情報を結びつける研究が出現
- convolutional neural network
- 言語と画像
- 言語と操作
- 言語と映像
マルチモーダルの研究がやりやすい
- ベクトル同士の比較の問題に定式化できる
一気通貫の学習が可能になった
自然言語処理のパイプライン 単語分割 瀕死タグつけ 構文解析 意味解析 構文解析で問題を細分化 先で間違った結果がエラーが積み重なっていき、うまくいかない
符号化復号化モデル 機械翻訳の例 英語→符号化ネットワーク→中間表現→復号化ネットワーク→日本語
一気通貫型の学習の何が憂いしのか
- 問題特価の工夫を入れやすい
- 試行錯誤の余地が広がって、たくさん手を動かす人が勝つようになってきた
適用が注目されている
- 機械翻訳
- 要約
- 対話
スマホ時代にブレークした技術
デバイスの変化と特質の変化
まとめ
Anyca(エニカ)のC2Cビジネスを支えるシステムと運用 蛭田慎也様
- カーシェアのサービスAnyca
C2Cならではの課題
- 利用までのハードルが高い
コミュニティ作り
- ユーザー参加型のイベント
- 運営とユーザーの関わり
- エントリーイベント
- Anyca若手グループ
- Anycaアンバサダー
トラブルを予防・解決するシステムと運用
- キズ確認機能
- 記録を残しておくことでトラブル防止に繋がった
- オーナー・ドライバー間で傷に対する価値観の相違が少なくなった
- 修理サポートセンター
- クルマ修理を有料修理工場でスムーズに行うことができる
- 万が一、シェア中の事故などにより車の修理が必要となった場合
修理サポートのバックエンド
- Opeツール
- webベースの管理ツールとして実装
- 運用上必要なオペレーションの大部分
- ユーザー情報の確認
- 修理サポートのチャット
- 見積もり結果の通知
- 案件登録〜納車まで完了した案件15件
- 最短で案件登録〜納車完了まで18日で完了
- 案件が登録される割合
- 一般的なB2Cレンタカーサービスの事故発生率よりも低い
健全なコミュニティ形成に向けた取り組み
- 重要なユーザーアクションの検知
- システム化できる部分とできない部分がある
- 全自動化が難しいオペレーションや運用方法を模索中
- レビューの確認、ペナルティ対応
- 修理サポートにおける修理業者との確認
- 事業推移とのバランス
- 運用をシステム化する工数・運用の手間を常に天秤にかけて判断
まとめ
- エンジニアとしてユーザーとの距離が近い
- 安心安全の向上に向けた取り組みは泥臭い部分が多い
- 運用をサポートするバックエンドのシステム化は面白い
Unityネイティブプラグインマニアクス 大竹悠人様・山内沙瑛様
ネイティブプラグインの作り方
- ネイティブ実装とそれを呼び出すためのインターフェースを用意することで相互に呼び出しを行うことができる
- 必要な実装
- ネイティブ 拡張機能のコア
- マネージドコートから呼び出すインターフェース
- ネイテイブコードとの連携実装
- 利用者向けの呼び出しフロントエンド実装
ネイテイブコードとの連携実装
- スライド参考
P/Invoke
CLIの機能でネイティブコードをマネージドコードのように呼び出すことができる 引数や返り値は必要に応じてマーシャリングという変換処理が行われる
ANdroidJavaObjectなど
AndroidのAPIやJARに含まれるコードを呼び出すことができるUnityのAPI。マネージドコードからクラス名を指定して呼び出すことができる。
UnitySendMessage
ネイティブコードからマネージドコードに文字列を渡すことができる。 指定したGameObjectの指定したメソッドに対して、stringを引数にして呼び出す。 ネイティブで一定処理を行った後に結果を返したい場合に利用する。 非同期のため、同一フレーム間でメッセージをやりとりできるわけではない。
利用者向けフロントエンド実装
C Linkage関数のインターフェースをC#で扱いやすくするためにラッパーを実装する。
ネイティブプラグイン作成時の注意点と対応策
書くプラットフォーム用のライブラリ対応
各プラットフォーム用に実装したライブラリを用意する必要がある。
各プラットフォームごとのネイティブコードの呼び出し実装
各プラットフォームようにP/Invoke宣言の対応も追加する。 ライブラリごとにDllImport指定が異なるため、プリプロセッサディレクティブで分岐させる。
ネイテイブプラグインのライフサイクル
- Android
- ロード順序が担保されない
- ライブラリは関数呼出し時にロードされるため、ライブラリをロードするための関数を用意し、依存関係順に呼び出しておく。
- Unity Editor
- ネイテイブプラグインがロードされるのは初回再生時の初回呼び出しのみ
- UnityEditorの再生停止モードには影響されない
- 初期化処理が複数回呼ばれる処理にする
ネイティブコードからマネージドコードを呼び出す実装の注意点
資料参考
フェイルセーフ性の担保
プレイヤーのユーザー体験を損なわないように。開発チームの開発効率を下げないようにする。 すべてのネイティブコード呼び出しは常に安全に実行でき、正しく失敗するようにする。 * マネージドからエラーをハンドリングできる仕組み * ネイティブプラグインで発生したエラーもUnityEditor上から把握できるように
プラットフォームごとのアラインメント問題の考慮
構造体を使用する場合、メモリ上の配置にアラインメントが発生する。 マーシャリング対象のため、アラインメントを意識し構造体を定義する。 * 8byteのフィールドは8の倍数の位置から配置される * その間はパディングとして未使用のフィールドになる
実機上での実行効率
実行効率を上げるためにメモリコピーを回避するようにする。 そのためには、ネイティブ層とマネージド層のそれぞれのヒープを意識する。 * マネージドヒープ * マネージドコードから扱われるヒープ.GCで消されたり移動する可能性がある * ネイティブヒープ
メモリコピーの回避
メモリコピーはマーシャリング時に発生する。 やり取りするデータが大きい・頻度が高い場合はマーシャリングを回避するようにする。 回避策として、Blittable型を使う。 マネージド/ネイティブでメモリレイアウトがおなじになる型のこと。 P/Invokeでマネージド/ネイティブへ受け渡す際にマーシャリングせずに参照渡しができる。 Blittable型を使った参照では、アドレスが保証されるのは関数呼び出し間のみのため、同期呼び出しにしか使用できない。
初心者RubyエンジニアがRailsチュートリアルに入門して2週間の感想
先週からほそぼそとRailsチュートリアルをやっていたのですが、昨日やっとチャプター14まで一通り終わらせることができたました。
今回はRailsチュートリアルを一通りやってみての感想をまとめたいと思います。
なぜ、やったか
今回Railsチュートリアルに手を出した理由は大きくわけて、ふたつあります。
- 業務では静的言語を使っているので動的言語での開発を覚えたかった
普段はC#やJavaを使用して開発を行っているので、「達人プログラマー」の毎年1つの言語を学べという教えに則って、普段とは違うRubyを使用した開発を覚えたほうが良いと考えました。なぜ、Rubyを選んだかというのにはコミュニティの活動が盛んであることやRailsというMVCフレームワークのデファクトスタンダードがあることなど様々な理由がありましたが、後述の理由が自分のなかでは大きいです。
- 転職活動をしており、Ruby on Railsを覚えたほうが選択肢が広がると思った
現在、私は転職活動をしておりWeb業界へ進みたいという思いがあります。そこで大手からスタートアップまで幅広く採用されているRuby on Railsでの開発を覚えたほうが選択肢が広がると考えました。入社してから覚えます！という意欲を見せるより、実際に手を動かして今学んでいるということをアピールできたほうが企業への自分のアピールになると思いました。
困った点は、わからないことを聞けない辛さ
Railsチュートリアルを行う上で、困った点はつまづいたときに自分のまわりに教えてくれる人が居なかったことです。まわりに教えてくれる人がいなかったため、わからない点は自分でググり倒して問題を解決しました。今思えば、Stackoverflowで質問したり、このブログなどで不明点を書けばもっと早くわからないことが解決して時間を無駄にせずに済んだかもしれません。。。
私の現職ではRuby on Railsは使用しておらず、環境もUNIXではなくWindows。なおかつ、同僚には技術的に興味をもっている仲間もいませんでした。勉強会などに参加していれば、そこで仲間ができたのかもしれませんが今はまだRubyのコミュニティ活動には参加していないので、これまた聞ける相手はおらず。。。
結果、Google先生に質問をぶつける毎日でした。
それでも、このググり倒すことで時間は無駄にしたかもしれませんが、なんとか自分で問題を解決する力が身についた気もします。
実際にやってみて気づいたこと
Railsはコマンドで色々なことができます。これが自分のこれまでの経験してきた言語と圧倒的に違う点で、最初は慣れが必要だったかなぁと思います。
それこそ最初はdb:migrateしたときにマイグレーションファイルでカラム名をtypoしていて「あれ！？これ、カラム名ってどうやって直すんや！？」なんて悩み倒したときもありました（めっちゃ恥ずかしい）
私はいきなりRailsチュートリアルに手を出したのですが、最初にドットインストールなどで一通りの基礎的な部分を学んでおけば躓くことも少なく進められたかもしれません。
Railsチュートリアルの次に何をするか
Railsチュートリアルを終え、Railsを使えるようになったかと言いますと、まだまだ手に馴染んだという感覚はないので書籍を購入して引続き、まずは勉強という感じです。
最近仕事でRailsのコードレビューをする時間が長くって、いろいろ指摘するんですが、 Railsって「Railsチュートリアル」には書いてないのに覚えないと仕事にならないこと多すぎだなと気付かされます。
Ruby on Railsを仕事にしていくための第一歩 - 酒と泪とRubyとRailsと
と、あるようにやはりRailsチュートリアルができたからといって業務ができるレベルということではなさそうです。今後はこの記事中にある参考書籍やTipsを読み漁る活動になることでしょう。
また、Railsの知識だけでなく根本は「コードを書く」ということなので、コーディングに関すること（リーダブルコードを読むとか）や、オブジェクト指向、ソフトウェアの設計、ソフトウェア・テストなど引続き学ばなければならないことはたくさんありますね。
Ruby on Railsエンジニア募集中の企業様へ
Railsチュートリアルを一通り完了しました。
エンジニア募集中の企業様、お声がけ頂く事ができましたら幸いでございます。
連絡はコメントかメールでご連絡ください！
パーフェクト Ruby on Rails
posted with amazlet at 17.02.16
