僕はここだ!

読書記録とか、ポエムとか、メモとか、コードスニペットとか。まとまったのはQiitaにも書きます。(http://qiita.com/RyotaMurohoshi) 掲載内容は個人の見解であり、所属する企業を代表するものではありません。

Unity道場「ゲーム開発者のためのフォント活用術」に参加した!

2017/06/30(金)にベルサール六本木コンファレンスセンターで開催された、 Unity道場「ゲーム開発者のためのフォント活用術」に参加しました。

kenjin.unity3d.jp

ハッシュタグ : 「#Unity道場

感想ツイートピックアップ!

まとめ

  • 商用フォント、お高いけど素敵だしいつか
  • Unityのロゴ変わっていたの気がつかなかった
  • フォント、その国の文化やその時代の流行りがある、ということを忘れてはいけない
  • 「このゲームといえばこのフォント・このフォントといえばこのゲーム」、というのは日本だけなんだなー
  • TextMeshPro、アウトラインとか禁則処理とかすてきだ!

そして、懇親会の抽選でとっても素敵なUnityグッズをいただいてしまいました!!!!!

f:id:MRStar:20170701001336j:plain

ありがとうございます!!!!!!!

たくさん着ます!!!

「第6回 Kotlin勉強会 @Sansan」でKotlin 1.1のStandard Libraryの改善についてLTした #KOTLIN_SANSAN

2017/06/29(木)にSansanさんで開催された、第6回 Kotlin勉強会@SansanでLTをしました。

sansan.connpass.com

ハッシュタグ : 「#kotlin_sansan

タイトルは「Kotlin 1.1のStandard Libraryの改善」です。

Kotlin 1.1でStatndard Libraryに追加されたクラスとかメソッドについて、利用例、内部のコード、関連コードを踏まえて簡単に紹介しました。

speakerdeck.com

Kotlin 1.1がリリースされた時、Coroutineやtypealiasといった言語機能に関するブログや発表は多かったのですが、Standard Libraryの改善にふれている人は多くなかったので、それを紹介したいなと思いこのタイトルを選びました。

次回への改善ポイントは、

  • 自己紹介を削りすぎたから、さすがに次は名前くらいは言う
  • 10分のLTで2、3分オーバーしたので、次回は余裕を。1・2分余裕を持って終わらせて、質問をもらう

って感じです。

小ネタをたくさん言うLTって、文脈がころころ変わるので、コードを紹介するのに工夫が必要ですね。ちょっと苦労しました。

  • 余分なコードは極限まで削る
  • 紹介するコードはシンプルなものにする
  • 口頭で説明しやすいような、例・変数名を選ぶ
  • あえて口頭では余分な部分は説明しない
  • このメソッド・クラスは知っているよね、ってラインを自分の中で明確にする

という工夫が必要だなと思いました。

他の参加者の皆様の内容もとても素敵でした。

とくに、じゅんぺいさんの拡張関数を定義する基準・工夫の話とたろうさんのプラットフォーム型の話はとても素敵でした。

あと、「スコープ関数ってなんだ?」って話がでたのですが、まだ私の中で、「スコープ関数とは?」はもやもやしています。

最後になりましたが、Sansanさん、今回もまた素敵な勉強会をありがとうございました。

2017年5月振り返り

 気が付いたらあと数週間で2017年も1年の半分が終わるみたいです。

 5月は五月病になったりで浮き沈みが激しい1ヶ月だった人も多いのではないでしょうか?

 私もです。

 やばい。

Unite 2017 Tokyoに参加した

mrstar-logs.hatenablog.com

ゲームつくるぞ欲が高まるこのイベント!

つくるぞ!

「Kotlin入門までの助走読本」に参加した

mrstar-logs.hatenablog.com

ご縁があって、参加させていただきました。ありがたいです。

ブログ投稿まとめ

 技術的なことはQiitaに、勉強会の参加等ログ的なことははてなブログに書いています。

 Qiita

 はてなブログ

年間目標振り返り

 年始に建てた目標を振り返ります。

  • 個人ゲーム開発3個リリース
  • ブログ 100記事書く
  • TOEIC 860点以上をとる
  • 体重62kg以下にする
  • 彼女を1人作る

個人ゲーム開発3個リリース

 5月の目標

  • できてない ゲームを1個出す
  • できた 毎日10分でもいいからUnityプロジェクトを開いて何でもいいから何かを改善する

 小さいゲームを出す予定だったのを変更して、ある程度大きなやつを作ってリリースすることに。

 つくるぞ!流行らせるぞ!!!!!

ブログ 100記事書く

 計6記事。

 累計34記事。

  • やめることを検討。

TOEIC 860点以上をとる

 5月の目標

  • DMM英会話を月・水・金・日の週4回やる

 結果として、月合計0回。

 6月の目標

  • やめることを検討

体重62kg以下にする

 1月:69.5kg -> 2月:69.8kg -> 3月:68.5kg -> 4月:68.9kg -> 5月 68.4kg

 微減!

 立てた目標は守れたのだけど、運動があまり回数をこなせなかった。

  • 軽くてもいいので週2回運動
  • オフィスにいる時は、お菓子を自分で買わない
  • オフィスにいるときは、缶ジュースを買わないで1Lのお茶にする

彼女を1人作る

 進捗ありません。

 やめることを検討。

まとめ

 6月は、ちょっと今年の目標を今後の目標を考えたい。

ABC 2017 SpringのMR/VRトラックの運営お手伝いをしました

2017/05/28(日)に開催された、ABC 2017 SpringのMR/VRトラックの運営お手伝いをしました。

abc.android-group.jp

トラックオーナーのお世話になっている方にお声がけいただき、MR/VRトラックの運営お手伝いをしました。

主にタイムキーパーとTwitterの実況ですを担当しました。

http://abc.android-group.jp/2017s/timetables/#anc_track6

誰かの役に立てたならうれしいです。

Unite 2017 Tokyoに参加しました

2017/05/08(月)・09(火)に開催されたUnite 2017 Tokyoに参加しました。

unite.unity.com

今年は、Unity Meetup アプリが便利でした。アンケートにアプリで答えられるようになったり、気になるセッションの登録ができたりなど、とても便利でした。

また、去年に引き続きS席チケットはとてもよかったです。

1点、困った点をあげるとすれば、私が方向音痴なのもあって離れた場所にあるランチセッションの会場に行くのに迷ってしまったということです。

タイムテーブルはこちら。

events.unity3d.jp

セッション動画や資料が公開できるものはボチボチ上がっています。

それでは、気になるセッション・よかったセッションのメモピックアップ。

ゲーム開発を教えるツールとしてのUnity

リンク : http://events.unity3d.jp/unite2017tokyo/session-lineup.html#session10

他のセッションを見ていたけれど、Twitterから流れてくる内容がとても面白かったセッション。

なんでゲームって面白いのか。

これを見てもう一度考えたいです。

「黒騎士と白の魔王」にみるC#で統一したサーバー/クライアント開発と現実的なUniRx使いこなし術

UniRx作者でもある河合さんのセッション。

未来を信じていた。できる(私なら。グラニなら。)

ってところはめちゃめちゃかっこよかった。

リンク : http://events.unity3d.jp/unite2017tokyo/session-lineup.html#session19

Navmesh完全マスターへの道

いつもUnity道場で素敵なセッションをしてくださる山村さんのセッション。

個人プロジェクトでNavmeshを使っているので、マスターしたい。

リンク : http://events.unity3d.jp/unite2017tokyo/session-lineup.html#session25

いかにして個人制作ゲームで生きていくか〜スマホゲームレッドオーシャンの泳ぎ方〜

個人でゲームを作って、売れたい!!!

リンク : http://events.unity3d.jp/unite2017tokyo/session-lineup.html#session29

Unity Ads/Analytics/IAPを使ったマネタイゼーションの最適化とベストプラクティス

個人でゲームを作って、売れたい!!!

リンク : http://events.unity3d.jp/unite2017tokyo/session-lineup.html#session39

ランチタイム・トークセッション DAY2

個人でゲームを開発して、活躍している皆さんのランチセッション。

動画もなければ、資料もない。行ってよかった。

活躍したい!

好きなゲームを作り続けたい!!!

リンク : https://madewithunity.jp/info/unite-2017-tokyo-day2/

モバイルゲームマネタイズ円卓会議

3個のうち次の2個に参加しました。

「略式遊戯の集」テーマ:カジュアルゲーム全般 2017年5月9日 15時30分〜 「社交遊戯の集」テーマ:ソーシャルゲーム全般 2017年5月9日 16時50分〜

動画もなければ、資料もない。行ってよかった。

活躍したい!

さいごに

実は、公募していて落選したUnite 2017 Tokyo。来年こそは。

「Kotlin入門までの助走読本」の執筆に参加しました。

「Kotlin入門までの助走読本」の執筆に参加しました。

2017/05/29(月)に公開した「Kotlin入門までの助走読本」の執筆に参加しました。

Google ドライブ - 1 か所であらゆるファイルを保管

Kotlinユーザーグループの会長で、今回の発起人でもある代表の長澤太郎さんにお声がけいただき、今回執筆に参加させていただきました。

この本が誰かの助けになればうれしいです。

twitter.com

読書メモ カンバン仕事術 チームで始める見えるかと改善 (その1)

 O'Reillyの「カンバン仕事術 チームではじめる見えるかと改善」の途中までのメモです。

www.oreilly.co.jp

  • 自分の疑問点を多め
  • イントロの第1部「カンバンの学習」と第2部「カンバンの理解」までのメモ
  • 1部を読むのはこれで3週目、2部は初めて
  • 1カ月くらいカンバンを使って、まわしている
  • 応用の第3部も1日1章くらい読み進めたい

1章 チーム「カンバネロス」のはじまり

  • カンバンにすべてのタスクを書き出す => 自分以外のメンバーに関係のないタスクも?他チーム・他部門と兼任の人は?
  • カンバンに入る条件はチームごと違う、この定義が大切そう。
  • カンバンは、それ自体を改良するもの
  • 『「課題」というより、「実現していない改善の機会」』 => いいフレーズ、使いたい。
  • カンバンを作る目的 => 作業項目の状況を把握する、次に何をすべきか判断する
  • カンバン見える化、WIP制限をしても、カンバンにタスクを入れる人(?)がそのカンバンを見ていない顧客であれば、タスクであふれかえるのでは?
  • 専門的なタスクが多いと手伝えないのでは? => 邪魔しないことはできる。その人がやるべき雑用をまきとることはできるかも
  • 遠隔メンバーがいる場合、物理カンバンでやる?別の手段?

2章 カンバンの原則

  • カンバンを作ることにも価値がある。暗黙的だった作業ポリシー・フローの見える化 => 一人できるもの突発タスク、煩雑なもの、リーダーだけ知っているものはどうする?
  • まずは現在のワークフローでカンバンつくること
  • 一人でカンバンをつくるのはよくないこと => 改善ミーティングもみんなでやったほうがいい?

3章 作業の見える化

  • ポリシーの明示がやりずらいこともあるかも? 流れてくるタスクが、時と場合によって違うことが多いならば、そのポリシーはどうなる?どう定義する?
  • 物理カンバンのメリットは、通りかかるだけで常に情報がみえること
  • 電子ツールには、メリット・デメリットがある
  • 最大のデメリットは、壁やホワイトボードに張っているとはカンバンを無意識でも見るが、電子ツールだとその機会がなくなること
  • 電子ツールを選ぶポイントは、自分たちにあっている設定・枠組みに変更可能かどうかという点
  • Trelloを常に大きなディスプレイで表示するのもありに感じた?アバターが見えずらいことが問題点か?
  • ステークホルダーに重要」とあるけど、ステークホルダーがカンバンを見る立場でないこともあるよね
  • カンバンの近くでメンバーが集まっていろいろ相談する、と本書にある。実際そうだったし、電子ツールを使う場合でもやはりディスプレイには常に表示したほうがいい気がする
  • 新入条件と退出条件の明示(カンバンの下に書いておく) => これやろう。

4章 作業項目

  • 簡潔に、要点を抑えて
  • 「チームの全員が理解できるように」ってあるけど、これ難しいのでは?インフラとか特に。
  • POST IT(商品名)でも微妙に色が違うものがあったから、やっかい
  • 人にWIPを制限を加えるのもあり
  • ブロッカーに滞留している日付を書くの、良さそう
  • メンテナンス・技術タスクの付箋紙がない場合は技術的負債がたまっている可能性がある、っていうのは今までにない見方だった
  • カードに書く見積もり、難しそう => S・M・L、くらいならばなんとかできそうだろうか?
  • 「完了後の付箋紙に感情を書く」 => 面白そう

5章 仕掛り作業

  • リトルの法則
  • 「二人以上の作業者を同じ作業に割り当てたときに効率が下がったりするからだ」 => そもそもアサインできない場合も
  • 『仕様には「賞味期限」がある』 => それな
  • 『僕のマシンなら動くんだけど』 => それなorz
  • 『「本番環境にリリースされていないコードも」WIP』 => それな!!!!!
  • フィードバックループを素早く回す => 他の人からのレビュー依頼やテスト依頼はすぐにやったほうがいいね!
  • リソースの稼働率 => 難しい問題だ

6章 WIP制限

  • WIP制限は運用しながら、改善する
  • 『始めるのをやめて、終わらせることを始めよう』
  • WIP制限には正解はない、改善のためのツール
  • ボードごと・列ごと・人事のWIP
  • 枠を書くなど、カンバンを工夫することでWIPを制限するのもよさそう
  • ○○完了や××可能なキューの列のWIPの数え方は場合による

7章 流れの管理

  • 『何が作業の流れを止めているのか』
  • ソフトウェア開発の7つの無駄
  • 『「流れ」対「リソースの稼働率」』
  • デプロイ待ち、リリース待ちなんかは時間が多そう
  • スウォーミング => 問題をメンバーが多く集まって一気に解決する
  • タイムボックス、実際それっぽいことをしているけど9章にあるらしい
  • 『みんなで一緒に作業を完了させるチームのメンバーであることを理解しよう』
  • 『すぐに辞められる面白い作業』とあるけれど、これはカンバンでタスク管理しなくていいの?
  • 『始めるのをやめて、終わらせることを始めよう』 => 他の人を手伝うの、(実際は難しいけれど)大事