今年はAdvent Calendarを4本書きました。

記事の内容自体を勉強したり広めたいというよりも、テーマの部分に自分のエンジニアとしてのあり方をこう変えていきたいという思いを込めていたのでその辺りをまとめることにしました。

概要

テーマ(ブログ内リンク) 記事タイトル Advent Calendar
OSS、ドキュメントじゃなくてコードでコミットしたい! CloudWatch Logsに書き込まれた内容をSlackとGoogle Homeで通知するAWS Lambda using dotnet AWS Lambda Advent Calendar 2017
ライブラリ、使い方のお勉強ばっかりしてないで自分でビルドして追いたい! XAMLの基本(Xamarin公式XAMLページ全訳)と基礎の入り口 Xamarin その1 Advent Calendar 2017
導入からリリースまで自力でやり抜きたい! Rubyがマジョリティな会社でC#を使ってAWS Lambdaの本番運用を開始した話 freee developers Advent Calendar 2017
エディターにも学習時間もっと割きたい! VS Code上でHTTPリクエストを送信し、VS Code上でレスポンスを確認できる「REST Client」拡張の紹介 Visual Studio Code Advent Calendar 2017

本題

OSS、ドキュメントじゃなくてコードでコミットしたい!

CloudWatch Logsに書き込まれた内容をSlackとGoogle Homeで通知するAWS Lambda using dotnet @ AWS Lambda Advent Calendar 2017

11月に会社のOSS Fridayという取り組みで、Microsoftの公式リポジトリに出したプルリクエスト(以下PR)がマージされました。

freeeのOpen Source FridayでMicrosoft公式リポジトリに出したPRがマージされて嬉しかったけど、ドキュメント翻訳で微妙にモニョるおはなし

ただ、それはチュートリアルの全訳でした。自分が必要だからやっているとはいえ、エンジニアならコードでコミットしたいなぁというのが正直な感想でした。

そこで、12月のOSS Fridayではアドベントカレンダー記事のようなコードを公開するのを世間体対策とし、なんとしてもこのリポジトリに自分が書いたコードをぶっ込むことを真の目標にしていました。

aws/aws-lambda-dotnet

AWS Lambda の.NET Core実装です。

自分がリポジトリに対して出す予定のPRに含める予定のコードをとりあえずは自分が公開するコードでユースケースとして妥当で実際に動作することを確認しました。

アドベントカレンダー記事にコードも掲載しています。

そして送ったPRがこちら。

add cloudwatch logs event #188

自力では何も実装してないに等しいですが、足りてないかつ自分が足せそうな部分がわかる程度ライブラリの実装を読んで、マージされるまでやりとりなり修正なりするのは今後もやっていきたいです。

最終的に本家に別途足されたデータのデコード部分(アドベントカレンダー記事に書いてる)や、PRの方向性が間違ってなかったら足そうと思っていたテストも足すべきなのはちょっと考えたらわかる話だったなぁという反省はあります。

実際に公式のライブラリから自分が足した部分がダウンロードでき、自分のプロジェクトで置き換えて見るのは思った以上に嬉しかったです。

CloudWatch Logs用のクラスに差し替える #3

今は特にserverless/serverlessAzure/azure-functions-durable-extensionに興味があるので、その辺りで何かやっていきたいです。

ライブラリ、使い方のお勉強ばっかりしてないで自分でビルドして追いたい!

XAMLの基本(Xamarin公式XAMLページ全訳)と基礎の入り口 @ Xamarin その1 Advent Calendar 2017

今年は「ライブラリ製作者」「ライブラリ利用者」という対立構造?が印象的でした。

僕は多くの人が利用するライブラリを作っているわけでも作れるわけでもないです。

しかし、「ライブラリ利用者」であってもライブラリの設計を理解し、足りなければ足し、「基礎」から理解しないと単なる消費者だし、それは嫌だなぁと思いました。

そして、そうかそういう原理で動いてるのかみたいなの追うのは楽しいです。

これはOSSへのコミットでも強く意識していたことですし、XAMLの記事でも同じスタンスです。

最近読んでいるSOFT SKILLS ソフトウェア開発者の人生マニュアルを読んで思うのは、技術の身につけ方のフォームを持ちたいなぁということです。

技術書を買ったら最初から最後までじっくり読みたくなってしまう派ですが、実現したいことベースで学習スコープを決め、技術書であれ何であれ学習リソースを確保し、試行環境が構築できて実現したいことに対する最低限の情報が揃ったら手を動かして実験したり、コード書いて公開したり、よりアウトプットに時間かけたいです。

来年は副業もしようと思っているので、自分に足りない技術を身につける速度を上げて、本業にもプラスになったみたいな流れを作ります。

導入からリリースまで自力でやり抜きたい!

Rubyがマジョリティな会社でC#を使ってAWS Lambdaの本番運用を開始した話 @ freee developers Advent Calendar 2017

自分のする仕事の大半は既存システムのメンテナンスだったり、機能追加やUI改善と言ってもやはり既存のシステムの枠組みの中での作業だったりです。

そんな中でもう少し解決したい課題に対して設計し、実装し、解決するという一連の流れを運用も考慮し「システムを構築」したいです。

そのためにちっさくてもいいので、「プロジェクトの追加」みたいな部分からCI/CD(CIサービスでボタンクリックしてビルド・デプロイできればいい)まで一気通貫でやりきるみたいな経験ができたというのが結果的にアドベントカレンダーの記事になりました。

※人の手を借りていないという意味ではないです

仕事に限らず、アウトプットは記事自体を目的にせず、何かしらサービスやライブラリを落としどころにしてその過程を技術記事でも出すくらいのスタンスにします。

エディターにも学習時間もっと割きたい!

VS Code上でHTTPリクエストを送信し、VS Code上でレスポンスを確認できる「REST Client」拡張の紹介 @ Visual Studio Code Advent Calendar 2017

これは新装版 達人プログラマー 職人から名匠への道に影響を受けています。

職人たるもの道具こだわってなんぼ的なやつです。

非効率と思いつつも無駄にキー連打で解決みたいなことやりがちなので、ショートカット覚えるなり、特定のユースケースのためのツール使いこなせるようになるだったりの意識が強まりました。

アドベントカレンダーの記事も、「便利な機能あったですごいやんな?」的なものではなくて、使いこなせるようになるために公式ドキュメント読み込んだ際の副産物という位置づけです。

まとめ

今年もやっとしてたいろいろなことを次に進めるための一歩がそれぞれ踏み出せてよかったです。

今年はまだ残っているとは言え、もう少し広い範囲で振り返ったり、来年のための準備に時間を割こうと思います。

freeeに転職して2年と11ヶ月が経とうとしています。新卒で入って企画/営業をしていた前職SIerには2年9ヶ月いたので、とうとうエンジニアとして働いた期間の方が長くなってしまいましたね…

Open Source Friday

最近freeeというか所属しているチームでOpen Source Fridayという取り組みが始まりました。

これ(「Open Source Friday」をGitHubが提唱。金曜日は自分の好きなオープンソースに貢献しよう)をやってみようというものです。

私たちはGitHubの従業員に対して少なくとも毎週第四金曜日には時間をとってオープンソースに協力し、お互いにどんなことをしたのか共有しあいましょうと呼びかけてきました

毎週(元記事の誤訳)でも毎月でもないですが、試行錯誤しつつ今後も続いていきそうです。

なぜやるのか?

  • かつての社内でもあったGoogleの20%的なものを継続的にやる
  • 社内のプロダクトへの貢献という枠を越えてOSSに貢献する
  • コードを集中して書く

あたりです。自分たちのプロダクトもOSSに支えられているので自分たちも貢献しようというのにはとても共感します。

こういう取り組みがなくてもやりたい人はやればいいと思いますが、「会社においても大事な活動と捉えられ、サポートしてもらえる」というのはとてもテンションが上がりました。

※サポート = 時間を確保してもらえる

推奨される活動

  • OSSにパッチを出す
  • 自分でリポジトリを立ててコードを書く
  • その他オープンな技術的な活動

テーマ設定

イベントありきで無理にテーマをひねり出すのではなく、普段の活動の延長でやりたいなぁという思いがありました。

Micorosoft公式リポジトリのハンズオンを日本語訳してQiitaに投稿した記事が元々あったので、どうせなら公式ドキュメントにしてしまうか…

ということで、「自分で訳した記事を本家に取り込んでもらう!」をテーマにすることにしました。

Qiita記事: Visual Studio for Mac で Azure Functions と Azure Table Storage を操作する Microsoft 公式チュートリアルの日本語訳
本家リポジトリ: Microsoft/vs4mac-labs

Visual Studio for Macのハンズオンに特化したリポジトリで、下記のようなカテゴリがあります。

  • Azure Functions
  • Docker
  • IoT
  • Mobile
  • Unity
  • Web

それぞれのカテゴリ自体の情報は多いですが、基本的にVisual Studio "for Windows" で扱うものが多く、その辺にわざわざリポジトリを独立させてある意義もあるのかなぁと思っています。

日本語記事が1ページ増えること自体はどうってことないかもしれませんが、広まるきっかけ作りになればいいなぁと思っています。

PR作り

PRの中身大体できてるんだからそれPRにしたらおしまいでは?と思う方もいらっしゃるかもしれません。実際そうです。

ただ、いくつか元々わかってなかったことがありました。

画像のホスティング

README.mdに載っている画像ってどこから配信してるんでしょうか?

同一リポジトリに画像フォルダでもあるのかなと思って探してみたのですが、ありませんでした。

URLを見てみると、たとえばこんな感じ。

https://user-images.githubusercontent.com/3944468/29033686-bdddd454-7b4a-11e7-8494-b3dad886c20a.png

このURLを調べてみると、GitHubのissueに画像をD&DするとURLが生成され、そのissueの存在の有無にかかわらずコンテンツは残り続けるということがわかったので活用しました。

いつ消えても文句言えないけど、それはGitHub諸共なくなってしまうときでは…とか思ったり。

参考: GitHubのissueを悪用して画像をホストする

あとは日本語設定にしたVS4Macでハンズオンを追い直しながら画像準備して、注目してほしい部分をSkitchを使って囲うという作業ゲーが最高に面倒でした。

素の画像サイズで上がるので、元の画像いじっておくか、タグで幅指定するとよさげです。

元のハンズオンのサイズに合わせました。

<あいえむじー src=https://user-images.githubusercontent.com/7035446/31535876-a84b33d0-b037-11e7-96fb-f8e27d43daee.png width="620px">

PRの規約

特にルールとかなさそうだったものの、一応commitはまとめました。

あと、初めてPR出すときはContributor License Agreementへの同意が求められました。

急いでるときに見たらちょっとびっくりするので、先に見ておいてもよさげです。

Microsoft Contribution License Agreement

同意してないとこのbotに怒られます。

msftclas

マークダウンの文法

Qiitaで投稿したときにナンバリングがうまくいかず、バックスラッシュでごまかしたけどこれレビューで弾かれるんじゃ…って思ったので直しました。

と思ってPR見直したら直してなかったwww

以上を経て完成したPRがこちらです。

Azure Functions lab for Japanese

なかなかレビューされない

Open Source Fridayの実施が2017/10/13、マージされたのは2017/11/21でした。

それまでの間、

  • 日本のMSの方々にこのリポジトリ関係の知り合いいないか、レビューしてもらえないか聞いてみる
  • コミットの多い人にPR内でメンションする
  • twitterアカウント把握したのでお願いしようとしたけど思いとどまる

などをしていました。

直近めちゃくちゃ活発に動いてるわけではないリポジトリだとこういうこともあるかもしれません。

とりあえずマージされてよかった。

ドキュメント翻訳に思うこと

ドキュメントの翻訳は最近よくやっています。

  • (受験)英語もともと苦手ではない
  • 日本語記事あると捗るなら、まず公式のドキュメントが日本語で存在してほしい
  • 何回も見る記事を訳すので、あると自分にとっても都合がいい
  • 素のままで読めてると思っても、訳してみて「え?そんなこと書いてたっけ?」みたいにとりこぼしがある。もったいない。

ただ、今回のPRにしても、訳すにしても微妙だなぁと思うこともあります。

  • どうせならコード(設定ファイルとかでもいいから)でコントリビューションしたい
  • 翻訳は人間がやるべき本質的な作業ではない
  • 自分の「価値」をだいぶ疑う、頭使ってない感に負い目を感じる

とは言え、もちろん全部手で訳すほど暇ではないので、1文ずつGoogle Chromeのエクステンション(文にカーソル合わせたら訳文を表示してくれる)の訳文と原文見比べて、実態にそぐわないものや構文的な誤訳を修正するみたいなフローを延々と繰り返しています。

その中でまだ人が介在しないと危うい部分が少なからずあるので、このモヤモヤを振り払って翻訳している次第です。(自己弁護)

それでもやっぱりモニョるのはやっぱりコード書いてドヤァするまで拭えない感情でしょう。

まとめ

いろいろ論点ごっちゃにしてしまいましたが、

  • Open Source Friday楽しかった
  • 公式リポジトリに自分のPRがマージされたのは嬉しかった
  • コードでコントリビューションしていけるようにがんばるぞ

というおはなしでしたー

2017/10/22開催の技術書典3で『Extensive Xamarin』という同人誌の出展・販売に携わりました。

https://techbookfest.org/event/tbf03 より

忘れないうちに感想や振り返りを書きます。

参加のきっかけ

7月の初旬頃(?)にXamarinの中の方がtwitterで書く人を募ってらっしゃったのを見たのがきっかけでした。

最初見たときは「あー、いつか書けたらいいな…」みたいな気持ちで流していたのですが、もうそろそろ募集は締切るというタイミング(8月の半ば)で参加することにしました。

参加しようと思ったきっかけは、何かすごく書きたいことがあるからではなく、Xamarin、強くなりたいからです。

テーマ選定

参加表明時はXamarin関係の興味がある分野として

を調べながら書こうと思っていました。

しかし、LottieXamarinはLTで調べたときにもっともっと深めたいとは思わなかったし、Realmもいつかは自分のアプリで使ってみたいなぁと思っていたものの自分のアプリで検証してそれから原稿を書いて...みたいなスケジュールで動くことは無理そうでした。

ならば自分が今業務で関わっていることに正面から向き合おうと思い、Xamarin.Macアプリ関連について書くことにしました。

ちょうどXamarin.Macを使い始めて間もないころだったので、開発フロー全体をどう組み立てていくのかについて不安を感じている時期でした。

そのため、自分のその不安を低減できるよう勉強・整理すべく「Xamarin.Macの配布方法」を具体的なテーマにすることに決めました。

Xamarinそのものを扱うことにはならないかもしれないけれど、Xamarin.Macを使ったMacアプリ開発を行う上で欠かせない情報、他の誰でもなく「自分が開発をスタートするときに欲しかった体系的な情報」を書くことにしました。

執筆

早速8月の半ばから記事を書き始めました。Extensive Xamarinのリポジトリに記事(Re:View形式)のPRを送ったのが9/10です。

土日のうち、イベントやその予習以外の時間と、たまに平日の夜に書きました。

少し空いて9/28には相互レビューが始まりました。僕はXamarin.Macの強い人にかなり詳細なレビューをいただき、このレビューがあったからこそ当日を迎えられました。

ここだけの話、レビューの修正対応期間が.NET Confの準備の佳境と重なってしまい、レビュー対応のうち体裁系は妻に手伝ってもらいました。

当日

会場に入って自分たちのブースに行き、『Extensive Xamarin』が入ったダンボールを開封したときの本に対するいとおしさが半端なかったです。

カバーイラストも画像では見せてもらっていたものの、いざ印刷されたものを目にするとたまらなくいとおしいです。

台風直撃(の直前)の生憎な天気でしたが、足を運んでくださったみなさまありがとうございました!

参加者としては最初の方に回らせていただいたので、気になる本は一通り買うことができました。

振り返り

Good

参加することにしたこと

いつか書けたらいいなぁ、で逃げなくてほんとによかったです。

もっとああすればよかった、こんな風に書けるようになりたい、も第一歩があってこそです。

テーマ
「自分が向き合うべき課題」に取り組めたことはよかったです。

Xamarin色が強くなかったことは心残りです。

期限
期限からだいぶ前倒しで書けたのはよかったです。

ただ、Challengeにつながる内容ですが、レビューが始まるまでに体裁や調べ足りない自覚があった部分は改善しておきべきでした。

Challenge

クオリティ
レビューしていただくにあたってそれまでにできることがあったというのは一番の反省点です。

Webページ用のビルドしかせず、PDF(実際に紙の本になるときの印刷状態に近い)で確認しなかった罪は大きい...。

Xamarin
どんな内容を書くか以前の話ですが、もっと「本質的なこと」について書いたり、理解したり、理解した上で開発したりしたいとは常々思っています。

それは動作原理に関するものです。

「こうすればこういう問題が解決できる」にとどまらず、「こういう問題はこうすれば解決できるが、それはこういう仕組みになっているからだ」という部分に踏み込めなければ成長しないんだろうなぁ...という気持ちが強いです。

なので、唐突ですが今年のQiitaのAdvent Calendar(きっとXamarin関連)はそういう内容にします。

そこで調べた内容をもとにどこかで話す機会があれば話せたらなぁとも思っています。

まとめ

どうまとめてもやっぱり参加してほんとによかったです。

特に主催の@atsushienoさん、レビューしてくださった@ailen0adaさん、一緒に技術書典3を仕上げてくださった執筆陣のみなさま、イベントの企画運営をしてくださったみなさま、足を運んでくださったみなさま、修正手伝ってくれた嫁氏、ありがとうございました!!

業務連絡

拝借します。
※情報が増えたら随時足します

booth

10/1に Microsoft MVP を受賞しました。カテゴリは Visual Studio and Development Technologies です。

Microsoft 関連のテクノロジーを使用した開発を行う上で各コミュニティの先輩方の助けがあってなんとかなった部分は数え切れません。

感謝するとともに、自分もより多くの人の役に立てるようにいっそうがんばります。

以下、自分とコミュニティの関わりについて書きます。

MS MVP が何か、どういうメリットがあるか等については何も触れていないので、そういう情報が必要な方は公式サイトをご覧ください。

C# との出会い

僕は「エンジニア」という職業に憧れ、2015年1月に SIer 営業から転「職」しました。

SIer企画営業をやめ、クラウド会計ソフトのfreeeでエンジニアとして働きます

最初の7ヶ月くらいは大体 Ruby を書いて(※書けない)過ごしましたが、2015年7月頃突然 Windows デスクトップアプリのプロジェクトにアサインされました。

それが C# や Visual Studio との出会いです。

まぁ何もわからなかったです。

前職で C# で書いていた UXデザイナーさんに Visual Studio の使い方を教えてもらったのは今となってはよい思い出です。

レビュー以外は基本的に自分しか触らない、ということは自分が開発を進められなかったらこの機能は世に出ない…!というプレッシャーがすごかったです。

(会社の中でわからないことを聞いても教えてくれる人はいたのかもしれませんが、)そのタイミングで利用し始めたのが teratail (もちろん Stack Overflow とかも)だったりします。

@Tak1wa さんを始めたくさんの方にすごいスピードで助けていただきました。

その助けがなければリリースまでたどり着かなかったかもしれない機能もたくさんあります。

感謝してもしきれません。

ここからオンライン・オフラインでの「コミュニティ」との関わりが始まりました。

はじめての Qiita

助けてもらってばかりの日々が続きましたが、無事大きな機能もリリースにこぎつけ、今度は自分も何か書いてみよう!と思っていると、世間は Qiita の( Qiita をはじめとする?) Advent Calendar で賑わっていました。2015年の12月のことです。

はじめての Qiita 記事は C# の Advent Calendar です。

Windowsアプリで出たバグをBugsnagで管理し、Trelloでタスク化し、slackに通知する

C# との闘争

2016年になり、Windows アプリのメンテや機能拡張が半稼働、Ruby で書くのが半稼働という日々が続きました。

正直頭切り替えるのしんどいし、どっちも中途半端だし、C# での開発は社内でメインストリームではない…ということでだいぶモヤモヤしていました。

しかし、紆余曲折を経て、腰を据えて C# を勉強することに決めました。

2016年の5、6月には C# の基本書を改めて読み、 Qiita 記事も色々と書き始めます。

設計もできるようになりたいという思いで、『Java言語で学ぶデザインパターン入門』を C# で書き直すという Qiita 記事も書き始めました。

C#で学ぶデザインパターン入門 ①Iterator

はじめての .NET 関連勉強会

そういう言えば C# なり .NET なり勉強会行ったことないよな…と思い、行ってみることにしました。

近々開催予定だったのが .NET Fringe Japan 2016です。(2016/10/1)

Ruby や JavaScript の勉強会と雰囲気(いる人の層?)が全然違うし、何より何言ってるかさっぱりわからなかった気がします。

今思えば最初に行く勉強会としては誤りだったと思う一方、メンバーの濃い本当に貴重な勉強会だったと思います。

はじめての Xamarin

C# でモバイルアプリの開発ができるとか何とか?という話を聞き、へ〜って思っていると、Xamarin Dev Days Tokyo というイベントがあるというのを知りました。

世界中で Xamarin のハンズオンイベントをやるとのことで、参加してみることにしました。

環境構築が全然進まず困っていたところ、@_shunsuke_kawaiさんや @atsushienoさんに助けていただきました。

atsushieno さんが Xamarin の中の人だということは後から知りました。

Japan Xamarin User Groupという日本の Xamarin ユーザグループもあり、勉強会もほぼ毎月行なっているということを知りました。

その年の会社 Advent Calendar では C# というかなんというかな話を書きました。

技術的マイノリティプロジェクトで幸せに過ごすための5つの方法

年が明けるともっと Xamarin のことを知りたいと思い、 Xamarin.Forms 本の邦訳読書会にも参加し始めました。

XamarinFormsBookReading

そして自分でも Xamarin.Forms を使って簡単なアプリを作り始めました。(2017年4月)

Xamarin.Formsで家の日用品管理アプリを作り始めたお話

はじめての機械学習

Xamarin に触れる一方で、社内では機械学習の勉強会に参加していました。

Coursera の機械学習を見つつ、その演習問題をやってみたり、Kaggle の問題を解いてみたり。

その文脈で Azure Machine Learning に出会い、そのわかりやすさに感動してこの本をベースに社内でハンズオンをやってみました。(2017年4月)

インサイド Xamarin

会社でも Xamarin で開発をすることが決まり、de:code にも参加して Xamarin の話を聞くぞ!予習するぞ!というときにある連載に出会いました。

インサイドXamarin

Xamarin に限らず、ビルドとかコンパイルって何することなんやろう?そもそも .NET って何?みたいなことがとても気になり始めていた時期(遅)で、衝撃的に面白かったです。

理解できてない部分は多いとは思いますが、詳しく知りたい気持ちが増す大きなきっかけになりました。

はじめての LT

思うところがあり、2017年6月から LT をし始めました。

その経緯はこの記事に詳しく書いています。

Tokyo Jazug Nightで「Azure FunctionsとAWS Lambdaの開発フローの違い」を話してきました。初めての登壇とその理由 #jazug

はじめての LT は日本の Azure のユーザグループである JAZUG で行いました。

これからもっと Azure を使って行く予定なので、もっともっと実践的な知見を共有できたらと思います。

Microsoft MVP

その後もイベントでの登壇やサポートをしたり、業務関連の Xamarin 記事を書いたり翻訳したり、たまにコードを GitHub に上げたりしていました。

その結果、2017年8月までの1年間の活動を評価していただき、Microsoft MVP を受賞しました。

自分のエンジニアとしてのキャリアと Microsoft 関連技術は密に結びついており、とても嬉しくて受賞した日はほとんど眠れませんでした。

(訳あって9月以降の実績を含まずに受賞できたら嬉しいなぁ…と思っていたりもしました)

会社のチームに報告したり、全社集会で報告したり、察して祝っていただいたり、全社集会で報告する日にMVP Kitが届き開封の儀を執り行ったり、自分のことのように喜んでくれる人がいたりで徐々に実感も湧いてきました。

ただ、評価指標はあくまでコミュニティへの貢献で「エンジニアとしてどうか」ということではないと思っています。

今後、MVP を受賞したことで得られる機会を最大限活用し、これまでお世話になった方々のように多くの人が一歩踏み出す力になれるよう努力し、エンジニアとしてより大きな問題を解決できるよういっそう精進していきます。

2017/10/7の .NET Conf 2017 Tokyo, Japan でお話して来ました。

発表に使用したスライドはこちらです。

下記について書いていきます。

  • 登壇のきっかけ
  • テーマ選定の理由
  • 準備
  • 振り返り
  • お知らせ
  • おまけ

登壇のきっかけ

Microsoftの方からXamarinについて登壇してみませんか?というお話をいただいたのがきっかけです。

Xamarinのユーザーグループには登壇してくれそうな人はいるものの、今回は普段あまり喋ったことない人がよいということでお声がけいただいたようです。

聴衆として参加登録はしており、「セッションは公募」というのを見たときは「さすがにこれまで5分しか喋ったことないし、いつかは喋ってみたいけどさすがに長時間(まだセッションの尺も掲載されていなかったので雰囲気)は無理やなぁ」くらいに思っていました。

お声がけいただいてもこの状況や思いは変わらなかったのですがw、ひとしきり周囲の人(たまたま家族旅行中で沖縄にいました…!)ときゃーきゃー騒いだあと、いつものようにネタは何も決まってないけどとりあえず引き受けることにしました。

たぶんいつかやりたいそのいつかも「はいはい45分セッションね?あれとあれとあれ話すから余裕ですよ!やりますよ!」みたいな状態ではないので、この機会逃すのは勿体なすぎる!

テーマ選定の理由

引き受けたものの、Xamarinに詳しいわけではないので、 準備しながら勉強したい、といういか勉強するプロセス自体がテーマにならないかなぁ?と思いました。

  • 体系的に勉強したい(学ぶべき領域整理されててほしいという甘え)
  • 45分という自分にとっては未知な時間を「埋め」やすい

というのを考えたとき、Xamarinの技術書の話をしようと思いました。

技術書にはある程度体系的(深くなくていいから網羅しててほしい)な知識が期待できるし、記憶ではこの1年でたくさん本が出ているので「m分 × n冊」みたいに時間も把握しやすいかなぁと。

そういうわけで、お声がけいただいたその日にXamarin本をテーマにすることに決めました。

5分のLTでも1ヶ月前から準備するタイプなので、本番3週間前スタートだと悩まず進み切るしかないのです…!

準備

本の数を把握する

本の話をするということで、まずはAmazonで「Xamarin」を検索しました。

ここ1年の日本語技術書は8冊。

本番2日前に発売されるものはスルー(しようと思っていましたが買えたので触れました)するとして、読めなくは無さそうです。

去年のスライドを眺める

ちょまどさんが当日の雰囲気や登壇者のスライドをまとめてくれいていて助かりました。

dotnetConf Japan 2016 で登壇してきました!

資料の枚数などを参考にしようと思いましたが、きっとそれぞれ芸風が異なりそうだったので一通り読んでそっ閉じしました。

本を買う、読む

すぐ読み始めたいものはKindleで買い、ある程度業務に関連あれば会社で買ってもらえるので他は購入申請しました。

既に買って読んでいるものもありました。

スライド作成

本を読むのにそれなりに時間がかかったのと、タイミングがいろいろと重なってしまったのとで10/3から当日(10/7)の朝に作成しました。

本を読んだ感想を念頭に構成だけ文字にしてスライド作成していくものの、意外と流れが作れなくて悩んでいる時間が多かったです。

「本を見ていく「基準」を提示して、その基準に各本を当てはめ、最後に傾向と感想を述べる」という大まかな流れの中で、突然本が出てきても流れがよくわからないし、基準の粒度が荒すぎると特徴を見出せないし、細かすぎると自分がわからなくなるしで最終的に資料のような形で腑に落ちたのは当日の朝でした。

練習

無事資料の作成が終わってスライドの枚数は60枚と少し。

いざ練習してみて、余るなら削ろうくらいの気持ちでいたら42分。

狙ってそうなったものでもなく、気持ちゆっくり目に話せばちょうど時間くらいで運よかったなぁ…という感じでした。

練習中に嫁氏が校閲してくれたときにいくつか誤字見つかったので感謝感謝でした。

振り返り

振り返ります。そういう芸風なので…。

Good

引き受けたこと

これは間違いなくよかったです。

準備期間は瀕死状態が続きましたが、そうやって大きくなっていくんです。(てきとう)

テーマ選定

自分が向き合うべきテーマだったのが何よりもよかったです。

前回のXamarin関連のLTではテーマが曖昧過ぎてちょっとアレだったという反省がありました。

XamarinのLT大会で「LottieXamarinで始めるXamarinアプリのアニメーション」を話してきました #jxug

今回はLTのタイトルとは別に「Xamarinやりたいけどよくわからんので、まずは広く見渡して知識を整理する、サンプルアプリで手もできる限り動かす」というテーマをおいて取り組んだので、目的がある程度果たせたのもよかったです。

内容(Xamarin本の整理)自体も、もし自分がやらなかったら他で企画があったかもしれない(関心がある人がいそう)ものだったようでよかったです。

(企画のネタの目を摘んでしまっていたら事故としか言いようがないですね…)

セッション終了後も本の紹介でちょうど困ってたところでよかった等コメントいただけて嬉しかったです。

セッション2日前発売の本にも触れたこと

たまたま入手できたからという側面はありますが、この本の内容自体が価値あるものだったので少し無理してでも触れることができたのはよかったです。

ただ、反省としてはこの本についてはパラパラ目を通したくらいなので、フェアな比較にはできてなさそうなことです。

これからサンプルも手を動かして追って、印象が変わったり事実と異なる扱いになってしまっていたりしたらスライドを修正します。

Challenge

誰向けのセッションなんや

僕は初心者なので初心者向けのセッションしかできないはずですが、初心者向けセッションなら「Xamarinアプリ開発に必要そうな知識」をもう少し整理?わかりやすく話す? などできればよかったかなぁと思いました。

本を評価していく「基準」なので、伝えられなければ前提が崩れてしまう…。

それか「どんなときXamarin使いたくなると思いますか?」じゃなくて、「Xamarin使ったことありますか?」「なんで使いましたか?」みたいに経験の有無やどういう説明必要か(はしょっていいか)確認したり、セッションの前に告知するとかしておくとよいのかなぁと思いました。

何はともあれ、自分が詳しくないと話すレベルの調整もできないので、詳しくなるところからです。

スライドが文字文字しい

自信の無いことの表れ…という側面と、発表するというか後から読める資料にしたいという側面どちらもあった気がします。

文字ばっかりのスライド見たくないですよね?書いていることをそのまま喋るだけならブログとかでええやんという感じです。

スライド自体は文字減らすか図にするかして、詳しく話ができる程度に準備するのがよさそうです。

また、サンプルアプリがついている本が大半だったので、その本で出来上がるアプリのGIFとか貼っときたかったです。

途中までGIFを準備しながらやっていたのですが、時間が足りなさそうで断念しました。

機材

USB-CとHDMIのコネクタを会社に忘れたのと、持参したUSB-CとVGAのコネクタが動作しませんでした。

Xamarin.Macの人に助けてもらいました。

純正奴買います。

こんなんなんかぁ…。

あと、ひらりんさんのブログ記事に触発されて本番直前に買ってはみたものの、余裕(論理/物理)がなかったので諦めましたw

発表中ずっとPCの画面見ていて発表っぽくないので、しゃべり方も変えてけたらなぁと思います。

お知らせ

発表でも触れましたが、技術書3で出展・販売されるXamarinの同人誌の1章分(Xamarin.Macアプリケーションの配布方法)を担当させていただきました。

技術書典3 出展情報 - Xamaritans

当日はブースにもいる予定なので、ぜひ遊びに来てください!

おまけ

5000兆年ぶりにTogetterで当日の自分のセッションやスライド関連のものをまとめてみました。

あと、動画撮っていただいてないと思ってたのですが記念に置いておきますw

まだ全部見てないのに、「まぁ」と「というところで」何回言うねんという喋りになっています。改善ポイントいっぱいですね。

運営のみなさま、聴いてくださったみなさま、資料見てくださったみなさまありがとうございました!

無事終わってほんとによかったーーーーーー

2017/8/30の 初心者歓迎XamarinのLT会!Xamarin入門者の集い #3 で LT して来ました。

発表した資料はこちらです。

もうちょっとだけ詳しく Qiita に書いた記事はこちらです。

LottieXamarinで始めるXamarinアプリのアニメーション

今日は

  • 登壇のきっかけ
  • テーマ選定の理由
  • 振り返り

について書きます。

登壇のきっかけ

Xamarin に強くなりたい!以上。

テーマ選定の理由

今回は単なる興味です。

LT のテーマは「身近な問題に向き合う」にすると決意していながら、自分が Xamarin について何か発表する姿がイメージできな過ぎて、

  • 取り組んでいる人あまり見かけない
  • もともと気になっていた

ということで、アニメーションのライブラリ Lottie の Xamarin 版を調べることにしました。

振り返り

結論としてはやっぱり何か直面してる問題を解決したかった一方で、特定のライブラリを(ある程度危機感を持ちながら継続的に)追いかけるのは良かったなぁと思いました。

K

ライブラリ(github上のリポジトリ)を追いかけるようになったこと

ライブラリの動作検証しているとき、最初に試したバージョンが iOS でバグがあり動かない状態でした。

リポジトリを見てみると issue が立っていて、何人か同じ問題で困っている模様。

リポジトリにスターをつけて issue に動きがある度に届くメールを見ていると、数日後に issue は解決。

(正確にはリポジトリで Watching 状態にして、特定の条件でメール通知するように設定)

本来使っているライブラリの動きくらい追えよという感じかもですがやってなかったので習慣にします。

ついでにこれまでスルーしてたメールのフィルタも整理したので業務効率もアップですw

あと、リポジトリにスターつけたら twitter に垂れ流すやつ( IFTTT )割とこけるので困ってます。

Microsoft Flow なんとなく見てみたら GitHub 系は issue 立てる系とかしかなかったのでリクエストしようと思います。

こんな感じで使える IFTTT みたいな iPaaS です。

Microsoft Flowを使ってSlackからVisual Studio Team Servicesのビルドを実行する

スライドの枚数少なくして DEMO 入れた

前回、前々回とスライドの枚数が多く、時間もキツキツで喋る方もしんどかったのでスライドの枚数を減らし、せっかくのアニメーションだったので DEMO (ってほどでもないですが)スライドから別ページに切り替えて動かしました。

趣旨にもよるとは思いますが、今回は動いてて楽しいやんなーみたいなのが伝わればよかったので…伝わってたら嬉しいです。

詰め込み過ぎもやめてよさそうです。

記事書くのマークダウンにしたら捗った(ブログの話)

効率は上がった気がします。

今更ながら読んでる『達人プログラマー』の影響です。

P

自分が解決したい問題ではなかったこと

今回はこれに尽きる気がします。

気になっていたライブラリだとは言え、自分がアニメーション導入したかったわけでもなく気合が足りませんでした。

気合とは具体的に

  • サンプルよりもっと踏み込んだ使い方をしてみる
  • どういうコードなのか追ってみる
  • ライブラリを使ったときと使わなかったときの実装を比較する

などのことです。

いきなり本質に切り込めなくても改善していこうと思います。

T

テーマ設定時に問いかける

  • 何が問題で、どうやって解決したのか
  • なぜ解決する必要があるのか
  • その解決策はどのように成り立つのか
  • 考え疲れた?まぁ LT は LT やし全部満たせんでもええよ

Microsoft Flow に GitHub スターのパーツリクエスト

とりあえず言ってみる。

7/25の第7回 Tokyo Jazug NightのLTで登壇してきました。

JAZUG

Japan Azure User Group (通称JAZUG) は、Microsoft Azureを学び、楽しみ、活かす、日本のユーザーグループです。2010/8/26に結成したばかりのコミュニティです。ぜひ、一緒に作っていきましょう。 ちょっと興味がある=ゆるふわな方 から 実ビジネスで使うんだよね な方まで歓迎。 職種はなんでもござれ。 ※プログラマ~企画者、デザイナ歓迎。ゆるふわなコミュニティとお考えください。

connpass JAZUG (Japan Azure User Group) ページより

発表した資料はこちらです。

VSTS、Slack、Microsoft FlowでASP.NET CoreアプリのCIをやってみる

第6回にも登壇したので、そのときと比べてどうだったか、今後どうしていくかについて書こうと思います。

Tokyo Jazug Nightで「Azure FunctionsとAWS Lambdaの開発フローの違い」を話してきました。初めての登壇とその理由 #jazug

このテーマにした理由

当初は「そんなに使わないけどたまにテストで使うASP.NET CoreアプリのCIとリソース管理(使うときだけ SlackとかでさっとApp Service立ち上げるイメージ)」をうやるべく、VSTS使ったり、下に貼ったスライドのようにAzure Automationでよしなにしてくれる仕組みを作ろうと思っていました。

第6回の記事に書いたように、直面している問題の解決が第一にあって、副次的に発表ネタが増えるみたいな感じにしたかったんです。

しかし、そのASP.NET Coreアプリは別にローカルで立ち上がればそれでよいという話になって前提がなくなってしまいましたw

※問題が、問題解決のための労力を割かずして解決するのはよいことです

ただ、

  • VSTS触ったことなかった
  • CIツールそもそも触ったことなかった
  • CIツール以前にビルドフローで叩かれるコマンドってどんなのがあるのかよくわかってなかった
  • Logic Apps面白そうだった(けど触ったことなかった)

というのもあり、大枠のテーマは変えないことにしました。

前回の振り返りを踏まえて改善したこと

前回の振り返りはこうでした。

Good

  • LTに臨む指針ができた
  • 会社でMS関連の技術扱ってることをLT後も含めて伝えられた
  • 他社の方と一緒に何かをやるきっかけができようとしている

Challenge

  • 間違ってる部分があった
    • シーケンス図→会社の人に教えてもらった。修正済み。LTくらいなら先に会社でさっとやってしまうとよさそう
    • Azure Functionsの実行時間は5分から10分に伸びた→LTの準備段階で参考にさせていただいたブログ書いてらっしゃる方のLT資料に対するご指摘。ありがたい。完璧に準備するのは無理なので、指摘もらった点は資料に反映していくようにしよう
  • 緊張しすぎわろた→もうちょい練習しよう
  • 平日準備厳しい→土日に8割方終わらせても平日に残りやり切るの厳しいタイミングもあるので、平日は練習するだけ、練習時に気づいたこと直すくらいに…
  • 変換コネクタ貸してもらえなかったらアウトだった→type C to HDMIしか持ってってなかったけど、端子トゲトゲの青いやつだった。コネクタ買っとくかな…

で、それを踏まえて変えた部分はこんな感じです。

改善点

間違ってる部分があった、緊張しすぎわろた

自分で何回か読む練習したのと、嫁氏がエンジニアなので変なところがないか聞いてもらいました。

嫁氏は今回発表した技術を普段使ってるわけではないことは棚に上げます。

平日準備厳しい

火曜日開催だったのでその前の土日には仕上げました。

変換コネクタ貸してもらえなかったらアウトだった

今回は(も)動画撮影の会社の方が準備してくださってましたが、購入したのでいつでも大丈夫!

その他

前回の内容はスライド見るだけではあまりにざっくりでだからなんやねんみたいな感じになってしまったので、今回は合わせてQiita記事にもしときました。

反響なさすぎて寂しいですが、備忘のため…(つよがり)

振り返りと今後

振り返り

Good

  • VSTS、Logic Apps、Microsoft Flowも触ったことなかったけど一応形になった
  • うまくいかないときフォーラムで聞いてみたら回避策が見つかった
  • 今回VSTS、次回MS Flowみたいな感じに分けようかと思ったけど、その時点で持ってる知識全部出して次はまた別のことやるべきって思ってそうしたこと

Challenge

  • 前進させたい
    • うまくいかないってtwitterで言ってるよりはフォーラムでも書くほうがマシではあったけど、OSSならPR出したり再現できる形でissue上げたり、英語で書いて開発してる人によりフィードバックが届きやすい形にすることで改善なり前進なりに繋がるようにしたい
  • 問題はより目の前のものを
    • 今回も調べ始めたらどんどん気になることが出てきて楽しかったけど、深堀っていく対象は選ばないと人生進捗しない感がすごい
  • 内容濃くない割りに詰め込みすぎで早口
      5分のLTに妥当な内容とはとか考えると悩みしかないけど、詳細は別にするにしても内容1つに絞ったほうがよいかも。けどまぁ人に行動促すんじゃなくて、自分が勉強するためにやってるしいっか…

今後

次は8月末の初心者歓迎XamarinのLT会!Xamarin入門者の集い #3でお話しします。

仕事でXamarin触っているので、強くなりながら臨めたらなぁと思います。

Japan Xamarin User Group (JXUG)主催のイベント、初心者向けXamarinハンズオン! #3でメンターをやってきました。

と言っても、 今回のハンズオンのテーマになっていたXamarin Dev Days Tokyoに参加したのが去年の11月、それを元にアプリを作って少しいじっただけ、という感じなので「メンター」と名乗るほど詳しくないですし、メンター枠でイベントに参加するのも初めてでした。

そんな前提のもと、

  • やっといてよかったこと
  • 答えられた質問
  • 答えられなかった質問

をまとめておこうと思います。

やっといてよかったこと

実際にハンズオンの題材をやってみる

事前に題材を嫁氏(エンジニア)とやってみました。

Xamarinの概要説明、環境構築、ハンズオンを一緒にやってみることで、つまずきそうなところに事前につまずきw、ある程度解決策・回避策を予習したり、自分が特にわかってない部分を勉強し直したりできたのはよかったです。

ハンズオンの題材をいじる

ちょっと前ですが、ハンズオンの題材をベースに簡単なアプリを作りました。

Xamarin.Formsで家の日用品管理アプリを作り始めたお話

ハンズオンを単になぞるのに加えて、いじってる方が次どういう風に勉強してったらいいのか実感がわくのはよかったです。実際参加者の方とそういう話をすることはなかったですが…!

答えられた質問

"XamlCTask" task failed unexpectedly

数人。今回の題材だと、Xamarin.FormsのバージョンアップすればOKでした。本質的な理解ができているわけではない…

Androidの実機デバッグをするとき、デバッグ対象に接続した実機が出てこない

その場で一緒に調べたところ、XamarinとかVisual Studio以前にドライバが端末を認識できていない状態でした。

この辺(Windows のデバイス マネージャーのエラー コード)見ながらの対応でした。

どんな質問にも怯まずとりあえず一緒にぶつかってみる姿勢大事そうでした。

ビルドし直しても変更内容がエミュレータに反映されない

コード絶対正しいはずなのに何でだろう…と思って、最終的にVisual Studio再起動したら反映されました。

本質的な理解はしていませんが、どこでVS側で新しいソースビルドできてかったのか、エミュレータが古いソース見ていたのか、もう少し問題切り分けできたいなと思いました。

コード正しいはずなのにコードビハインドで赤線が表示されている

多分できるのでビルドしてみください、でビルドできました。

正しいコードでも即座に反映(コード解析的な意味で)してくれないこともある…けど何でなんだ…

APIからデータ引っ張ってきてくれない

データ引っ張ってくる部分コメントアウトされていたので、コメント外してもらいました。

基本コードのコピペで進めていくハンズオンだと気付けないこともあると思うので、実際追ってみてから参加するのとても大事だと思いました。

Azureのポータルの見方よくわからない

本筋はXamarin.Formsであるがゆえに、バックエンドのサービス構成の基本事項等々まで説明するわけではないので、なおさらこういう部分まで丁寧にサポートできると安心して本来の勉強したい部分にフォーカスできるのかなと思いました。

Commandの書き方がしっくりこない…どう勉強したらいいか?

MVVMでUIからビジネスロジックを呼ぶ手段であること、メソッドと動作可否を引数にとること、ActionやFuncの元になるラムダ式の仕組みがあることをお話したものの、自分でもあまりしっくりこず…

勉強していくための記事とか添えれたらよかった気がしました。

他にもあった気がしますが、覚えてるのはこれくらいです。

答えられなかった質問

iOSのプロジェクトをiPhone実機でデバッグするために必要なこと

iOS持ってなくて、事前にも調べてなくてその場で調べました。

が、強い人が教えてくれてました。

Xcodeから設定してましたがよくわかったないので調べてみよう。

Androidのエミュレータが起動できない

今の自分の環境では特に問題なく動いた(理解してるわけではない)ので、何かあったときに何もわからず…

別の方に助けていただきました。

エミュレータ系は環境構築でハマるお決まりなのでもうちょい勉強しといてもよかったかもですね。

まとめ

自分の力不足感は否めなかったものの、自分が勉強できたこと、本質的な提案ではないけどハンズオンを進めるための手助けにはなった(はず)ということで勇気を出して申し込んでみてほんとによかったなぁと思いました。

次はこのイベント(初心者歓迎XamarinのLT会!Xamarin入門者の集い #3)で、JXUGでは初めての登壇です。

まだ1ヶ月半くらいあるので、それまでにもっと強くなって臨みます。

弊社freeeでもXamarin案件があるので、興味ある方ぜひお声がけください!!

日本を変えたいWindowsアプリエンジニア募集!!

6/22の 第6回 Tokyo Jazug Night のLTで登壇してきました。

JAZUG

Japan Azure User Group (通称JAZUG) は、Microsoft Azureを学び、楽しみ、活かす、日本のユーザーグループです。2010/8/26に結成したばかりのコミュニティです。ぜひ、一緒に作っていきましょう。 ちょっと興味がある=ゆるふわな方 から 実ビジネスで使うんだよね な方まで歓迎。 職種はなんでもござれ。 ※プログラマ~企画者、デザイナ歓迎。ゆるふわなコミュニティとお考えください。

発表した資料はこちらです。

connpass JAZUG (Japan Azure User Group) ページより

Azure FunctionsとAWS Lambdaの開発フローの違い

今回、社外・面識のない方が大半の場で登壇するのが初めてでした。そのため、なぜ登壇しようと思ったのか、これからどうしていくのかとかその辺書き残しておこうと思います。

登壇のきっかけ

マネジメント

色々あった気もしますが、根本にあったのは特に技術面での成長に対する不安だったと思います。

営業から業務プログラミングとか0でエンジニアへ転職したのが2015年の1月。

思うように伸びない時期が大半だった気もしますが、2017年4月、正式にロールとしてチームの運営的な部分もやっていくことになり、拍車がかかったというのが大きかったと思います。

当時といってもそんなに時間経ってないですが、こんなことを考えていました。

  • マネジメントも様々な技術分野同様、専門知識のある一分野なのでキャッチアップしないと
  • 業務として純粋にコード書いたりする時間減るかも
  • 技術大してないのにマネジメントってなんというかダサい

マネジメントが技術的成長を妨げるとは全く思ってなくて、技術的に成長していける確認が持てていないタイミングでマネジメントもやる絶望感がただただありました。

インプットの質を高めるためのアウトプット

チームではMicrosoft関連の技術を扱っていて、品川でよく開催されている勉強会にけっこう頻繁に足を運んでいました。

3/25に参加したのがこちら。

.NETラボ 勉強会 2017年3月

.NETラボ 勉強会 2017年3月のまとめ #dotnetlab

後の懇親会で色々と話を伺っていると、雰囲気的に自分も登壇できたらなぁと思いました。

そしてたまたま当日目について記事がこちら。

“ただの興味”がいつか武器になる–及川卓也氏が語る、一流エンジニアのアウトプット法

インプットしないかぎりアウトプットできないので、最初にアウトプットするということを続けていくと、必然的にインプットしなければいけなくなるのです。

僕がよく勉強会で言っているのは、「ライトニングトークは敷居が低いから、とりあえず枠を押さえちゃえ」と。それで手を挙げて、「こういうネタで話そうと思ったけどダメでした」と言っても、やさしい勉強会やコミュニティなら許してくれます(笑)。">僕がよく勉強会で言っているのは、「ライトニングトークは敷居が低いから、とりあえず枠を押さえちゃえ」と。それで手を挙げて、「こういうネタで話そうと思ったけどダメでした」と言っても、やさしい勉強会やコミュニティなら許してくれます(笑)。

あと、デザインパターン勉強していて、けどなんかしっくり来なくて「どうやって勉強したらいいですか?」って聞くと、

「実際にデザインパターンが必要な必要な開発・シチュエーションに出会って適用すること!」

っていうお話をしていきました。これは登壇のきっかけではないのですが、自分の「技術的成長に対する不安感」の核心なので後でまた触れます。

今度はどこで話すかというお話です。雰囲気的に3月に参加した.NETラボさんでお話できたらなぁと思っていました。

が、毎月第四土曜に開催されるこの勉強会は参加できないことが多く、どうしよう、と…

思っていたときに4/22のGlobal Azure Bootcamp 2017@Tokyoに参加してやっていく気持ちが高まり、5/17のJAZUG女子部 第11回勉強会で今回登壇した第6回 Tokyo Jazug NightにLT枠があると知って(?)20秒くらい悩んで申し込んでみました。

ネタはまだない。

話すネタ

そう、申し込んでみたものの何も決まってない。

そもそも5分のLTってどういうのあるんやろう…

  • 最新情報・動向
  • 新しい技術試してみた
  • 導入したときのtips
  • Deep Dive
  • 俺の作ったサービスを見てくれ
  • なんとなくエモい話

とかとか?形から入ると一番大事な部分、話す内容がない。

折しも社内ではピアレビューというのがある時期。

会社では定期的にマネージャー以外にも近くで仕事をする同僚から良い面と良い面を伸ばすために必要なことを書いてもらう機会があります。

そこでもらったコメントの一部がこうでした。

  • 得意分野ができて技術をインプットするサイクルはうまく作れるようになったと思うので、今度は情報をまとめるだけじゃなくアウトプットを意識するといいと思う。ここで言うアウトプットは社外での発表とかそういうものではなく、ちゃんと技術を形にしたものであるべき。
  • Webアプリ開発などの基礎的なスキルはまだまだ不足していると感じるので、引き続きエンジニアとしてのレベルをトータルで1段あげれるような取り組みはしていったほうがいいと思う。これも勉強会に参加するとかじゃなくて手を動かす時間を取ったほうがいい。

まさに自分が直面している問題の話でそうだなぁと思う一方で、もっと意図が知りたいと思ったのでランチのお時間いただきました。

誤解を恐れつつまとめると

「自分が困った問題の原因を考え抜く、調べきる」

です。

そういうわけで、LTするにしても、LTのためのネタ集めをするのではなく、問題に向き合うことを大前提にすると決めました。

その課題を解決する手段として、今回であればAzure技術を位置付けるような形で話できるのが理想であると。

先ほども少し触れたように「デザインパターンどう勉強したらいいですか」みたいな質問をしてしまう前提として、漠然と自分の打ち手がないことへの不安から何となく教科書的なものを一通りさらっていくような勉強してしまうという自分の弱点があります。

体系的な知識が必要な場面はあるとは思うものの、自分に圧倒的に足りてなかったのは問題そのものに向き合う姿勢でした。

サーバレスアーキテクチャ

今回LTで話したのはAWS Lambdaの話とAzure Functionsの話です。

サーバレスアーキテクチャとか、話は最近よく聞くし、ポップでキャッチーな響きなので登壇後も優しい方々がいいねやリツイートしてくださいました。

もちろん、このLTの準備はサーバレスアーキテクチャに始まっていなくて、メインは

こうだったのが

こうなった

というのが中核です。

アプリへのレスポンスを改善するためにとった手段が最終的にサーバレスアーキテクチャになっただけで、beforeとafterの間に移行のための別アーキテクチャがあったりします。

とはいえ、手段としてのAWS Lambdaの特性を知るためのAzure Functionsの勉強はとても有益でした。

  • 「サーバレスアーキテクチャ」としてメリット・デメリット
  • 制限事項への対応
  • 新機能の意図

は特定のプラットフォームにだけ活きるものではなく、両者に活きるものだからです。

LTのスライドだけ見ると、ちょろっと調べれば何となくまとめられてしまいそうな内容になっています。しかし、最終的な成果物がどういう形であれ、問題に向き合うプロセスは別に形にしたり、こんな風に書き留めておきたいと思っています。

登壇の振り返り

そういうわけで、7/25実施の第7回 Tokyo Jazug NightにLT枠で既に申し込んでいます。

よりよくしていくためにほんのちょっと振り返ります

Good

  • LTに臨む指針ができた
  • 会社でMS関連の技術扱ってることをLT後も含めて伝えられた
  • 他社の方と一緒に何かをやるきっかけができようとしている

Challenge

  • 間違ってる部分があった
    • シーケンス図→会社の人に教えてもらった。修正済み。LTくらいなら先に会社でさっとやってしまうとよさそう
    • Azure Functionsの実行時間は5分から10分に伸びた→LTの準備段階で参考にさせていただいたブログ書いてらっしゃる方のLT資料に対するご指摘。ありがたい。完璧に準備するのは無理なので、指摘もらった点は資料に反映していくようにしよう
  • 緊張しすぎわろた→もうちょい練習しよう
  • 平日準備厳しい→土日に8割方終わらせても平日に残りやり切るの厳しいタイミングもあるので、平日は練習するだけ、練習時に気づいたこと直すくらいに…
  • 変換コネクタ貸してもらえなかったらアウトだった→type C to HDMIしか持ってってなかったけど、端子トゲトゲの青いやつだった。コネクタ買っとくかな…

次回もがんばるぞー

スライドにも書きましたが、この本よかったです。今AWS Lambda始めるならこれ!という感じです。

今日はALGYAN主催の「IoT ALGYAN(あるじゃん)2周年記念・IoT祭り2017!機械学習 豪華3点盛+IoT」に行ってきました!

IoTには機械学習がつきもの!ということで、AWS、GCP、Azureのユーザグループからそれぞれ各プラットフォームの昨今の機械学習事情を勉強させてもらえる、という貴重な勉強会@品川Microsoftでした。

コミュニティ

ALGYAN(あるじゃん): 日本から世界へ、明るく楽しくIoYT(The Internet of "Your" Things)を広めよう! という、熱く真面目なコミュニティです! あなたもコミュニティーメンバーになって(会費無料)、わくわくしながら世界のIoYTを盛り上げましょう! https://www.facebook.com/groups/ioytjp/ (←登録必須:無料だし)

とのことです。

勉強会

IoTには馴染みまったくなかったですが、最近機械学習の勉強してるのと、データの発生源としてのIo「T」という視点で聴いてるとシンプルに楽しかったです!

ハッシュタグ

お品書きとスライド

スライドはconnpassやtwitterで見かけたものを適宜追加していきますー

概要はconnpassより。

JAWS-UG「AWS で始めよう!はじめての機械学習

発表者: 中丸良さん
JAWS-UG AI 支部・コンテナ支部コアメンバー。AWS 認定 DevOps エンジニア・ソリューションアーキテクトプロフェッショナル。
概要: 機械学習、特に深層学習に注目して各クラウドのサービス・状況をみながら、AWS を選択する理由やその上手な使い方をご紹介します。デモを交えて実例も見ていただけます。

TensorFlowとGCPの話

発表者: 下田倫大さん
TFUG(TensorFlow user Group)主催者
概要: 2/15に発表されたTensorFlow v1.0を中心に、GCP上の種々のデータ分析、機械学習サービスの話をします。GCP上のデータ分析のワークロードについてイメージを掴んで頂けるようなお話にします。

Azure MLとCognitive とBotFramework 豪華3点盛+IoT(裏話はトーク中心に)

発表者:梅崎猛さん
JAZUGメンバー、セゾン情報システムズ テクノベーションセンター
概要:
・質問応答システム with Cognitive Transrator +QnA
・BotFramework 現状と裏話
・IoTに絡んだなにか

LT

①「TED Azure IoT PoCキット(仮題)」

東京エレクトロンデバイス IoTカンパニー バイスプレジデント 福田さん

②「アットマークテクノのIoT戦略」

株式会社アットマークテクノ 代表取締役 實吉さん

③「さくらのIoT PlatformとMicrosoft Azureのちょうどいい関係」

さくらインターネット株式会社 IoT Platform Team 西田さん

④「ラズパイマガジンとIoT」

日経Linux副編集長(ラズパイマガジン編集長) 安東さん

⑤「スマホのパワーをIoTへ 〜ハイパフォーマンスボード『DragonBoard』で〜」

アロー・ユーイーシー・ジャパン株式会社 IoT事業推進室 室長 目黒さん

⑥「XamarinでIoT

ちょまどさん

⑦「PayPal User Group立ち上げました!」

PayPal User Group 本山さん

セッションメモ

JAWS-UG「AWS で始めよう!はじめての機械学習

発表者: 中丸良さん

機械学習ってなんだっけ?というところから、中でも話題の深層学習について。

TensorFlow、Chainer、CNTK等、深層学習を一から実装せずに済ませるフレームワークについては下記を基準に妥当なものを選定する必要があるという話はどのプラットフォームでやるにも大事なので詳しくなりたいなぁと思いました。

  • 対応アルゴリズム
  • 動作端末・環境
  • 計算速度/リソース利用効率
  • 利用可能な言語/手続的・宣言的
  • スケーラビリティ/複数GPU、並列サーバ対応
  • 情報の豊富さ/エコシステム/商用サポート

そして、チュートリアルならまだローカルのpythonで済むものの、多様かつ大量のデータを扱うにはクラウドサービスを活用して環境構築するのがよいと。

機械学習関連のサービスはもちろん、GPUインスタンスや機械学習にもってこいのDockerイメージも。

次のLTでもJupyter notebook + Dockerは必須だという話がありました。

これが全部入りAMI

僕は機械学習(ガチ)の環境構築やったことないのであまり実感わきませんが、経験ある方だとありがたみがより深く実感できるようです。

環境構築一連の流れはこちら!
DeepLearning ハンズオン環境構築 @ MaruLabo × JAWS-UG

個人的にはまだローカルで十分そう…

TensorFlowとGCPの話

発表者: 下田倫大さん

TensorFlow、名前はよく聞くものの、version1系になったのが2017年2月というのはとても意外でした。

Google社内で

  • OK Google(音声認識)
  • Gmail(スパムフィルタ)
  • Google Photo(画像の自動分類)
  • Google 翻訳(翻訳の自動学習)

で活用されていて、2015年の11月にオープンソースに。

Google Trendsでの人気度動向僕も今ちょっと見てみます。

セッションでもあったようにかなり地域差もあって面白いです。

リンククリックしたらそのまま見れるのでよかったらどうぞ!

コスト関数の動きや分類度合い等いろいろ可視化できるTensorBoardもいい感じです。

TensorFlowの技術的詳細はこっちのスライド見ると幸せになれるとのことでした。
× TensorFlowは深層学習に特化したツールである
◯ TensorFlowはデータフローグラフを利用した数値計算のためのオープンソースのソフトウェアライブラリである

あとはJupyterをベースとしたGCP特化の分析環境として紹介されていたGoogle Cloud Datalabが気になりました。

AzureにもMicrosoft Azure Notebooksがあるように、今のところJupyter Notebook形式で分析のデバッグ、記録、共有していくのはデファクトな感じになってるみたいですね。

ただ、Google Cloud Datalabはpythonの3系に対応しておらず、GPUインスタンスも使えないことから伸び代あります!状態。
Datalab(+GCP)を中心にしたデータ分析環境

Azure MLとCognitive とBotFramework 豪華3点盛+IoT(裏話はトーク中心に)

発表者:梅崎猛さん

まずはこちらのチュートリアルのお話。

Machine Learning のチュートリアル: Azure Machine Learning Studio で初めてのデータ サイエンス実験を作成する

Azure MLはデータ準備→モデルトレーニング→スコア付けとテストをGUI操作するとそのモデルをAPIとしても使えるというサービスです。

機械学習のフローをモジュール化し、パズルのように組み替えがらモデルを作ります。

豊富なチュートリアルを見つつ、チートシートを参考にしてアルゴリズムを選びつつ…

作ったモデルはAPIとして公開できるので、しっかりバッグエンドまで面倒見てくれるところが魅力的です。

MicrosoftのAI投資は基盤からサービスまで徹底してる様はこのブログの記事(勉強会レポート…)でもとりあげてきました。

.NETラボ 勉強会 2017年3月のまとめ #dotnetlab

まどすた #2、Visual Studio 2017 リリース記念勉強会のまとめ

TensorFlowもAzure GPUインスタンス上で!

GPU版TensorFlowをAzure NCシリーズ上に構築する

まとめ

コミュニティでっかい!今回はプラットフォームごとのユーザグループ複数分野で集まってたのもあるとは思いますが、めちゃくちゃ盛り上がってますね。

自分の業務がWebだから余計に感じるのかもですが、きゅうりの分類とか普通にわくわくしましたw

今はまだローカルでなんとかなる範囲の勉強してますが、そのときもフレームワークそれぞれの特徴の差異はまとめていこうと思いました。

クラウド上のリソース使うときはそもそも環境を作っていける人でないのでその辺も強くなれたらよいなぁ…

あと幸運にもいただきものが素晴らしかったのでとてもテンション上がるいい1日でしたー