by ·0件のコメント

2017/4/21のGlobal Azure Bootcamp 2018@Tokyoでお話してきました。

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

テーマ選定

スタンプカードアプリ作りたかった

妻が筋トレ（？）か何かをするにあたり、スタンプカードアプリ（別にアプリである必要はなかった）がほしい、スタンプはできれば猫がいい、みたいなことを言ってたのがきっかけの1つです。

※継続的に筋トレする習慣を作るのに必要なのは本当にスタンプカードなのかどうかはわからない

Durable FunctionのHuman Interactionパターン実装したかった

去年のServerless ConfかなにかでAzure Functionsの拡張機能であるDurable Fuctionsを知り、興味を持ちました。

中でもパターン #5: 人による操作に謎のロマンを感じ実装してみたくなりました。

一定以上のまとまりがあるコードが書きたかった

LTなり、何か記事を書くなり、技術系のアウトプットをするには技術的なインプットが必要と思っていますが、インプットの質を上げるためにももうちょっとアウトプットせねばという思いがありました。

しょうもなくてもいいからGitHubにひとまとまりのソースコードを上げられるだけコードを書くというのが今年の方針です。

振り返り

スライドでは主にコードについて書いてますが、もうちょっと取り組み全体寄りの振り返りです。

Good

  • クライアントもサーバもコードを書いてGitHubに上げたこと
  • 期待した動作をするアプリができたこと
  • Azure FunctionはHTTP Triggerを1回触る程度でよくわかってなかったけど、全体的なお作法をざっと見た上でDurable Fucntionsのキャッチアップに入れたこと
  • Durable Fucntionsの実行の仕組みもなんとなく把握できる程度にデバッグ実行したりストレージの中身のぞいたり研究できたこと
  • PaaSの組み合わせ方にもデザインパターンがあり、実装するからこそそのありがたみを感じられることを実感できたこと

Challenge

  • 声出すの、歌とかでなくてもほんとに音にならなくてつらい
  • 全部喋らんけど資料になるから資料厚くしよう、そして喋るときはいろいろ飛ばそう、はまだ自分には早そう
    • （練習した後）ギリギリまで資料を変えて本番に臨むとわりと混乱して大事などころだけ絞って喋るって緊張してると難しい。今回は資料アップロードした後もここ表現こうした方がいいとか、順番はやっぱこういう方がいいとか10回くらい直してアップロードし直した
  • 実装的にあれも足りないこれも足りないとウジウジしてないで学びたいことを学ぶためのサンプルと割り切ること
    • 足りないと思う部分はissueとかで残しとくともっと深めようとか現実的に稼働させたいとか思ったときに役立つかも
  • 一方で個人的に本番運用するプロダクトがあってもよいなぁ
    • クラウドリソースの認証・認可さすがにザルすぎる
  • ログの追い方は「とりあえずサンプル1つ動いた」の次の段階くらいで意識的に時間とって把握するのがよさそう
    • 今回くらいの規模のサンプルでも途中デプロイすることがあったり、単にブレークポイントはる以外にログきちんと追いたい局面が多々あった
  • Azure FunctionsがV1ベース
    • V2でやろうとするとnugetからのインストールからうまくいかなくて、古めのバージョンでうまくいく組みわせでやり過ごしてしまった感
  • 実行の仕組みの研究とか言うわりに「どう実装されているか」をコード見ながら考えてない。動きからテキトー想像する「だけ」は研究とは言わない
  • UI苦手やぁ
    • よくあるアプリのパーツ実装してみるとか、作りたいと思ってるものに沿った形で取り入れてみるのはやった方が表現の幅が広がっていきそう

まとめ

総じて取り組んでよかったなぁと思います。

需要があるかはおいておいて、今回のスライドでも20分くらいじっくり喋りたかった内容だったりするので機会があればリベンジしたいなぁと思いました。

あと、今回みたいなアーキテクチャでデータの整合性はどうすると保てるのかだったり、クラウドアーキテクチャの原則は何なのかだったり、もっと踏み込んで学んだら楽しそうな分野に出会えてよかったです。

クラス設計もデザインパターンからでなく、その前提となる原則やそれを実現するための具体的なコード（の変化）を追うととても実感がわきました。

今ではクラウド設計の原則的なことも整理が進んでいると思うので、追ってけたらなぁと思いました。

勉強会ではこのセッションが特に印象的でした。

by ·0件のコメント

ちょっとやりたいことがあってDurable Functionsを調べているとき、そもそもAzure Functionsももくもく会でXamarinアプリからHttpTriggerちょこっと触ったくらいだったことを思い出し、さささっと把握したいなぁと思いました。

そんなとき目に飛び込んできたのがUdemyの1/12 17:00まで¥1,300セール（！）でした。

Udemyとは？

Udemyは、学びたい人、教えたい人のためのオンラインのマーケットプレイスです。プログラミング、マーケティング、データサイエンスなど、55000以上のコースを1500万人の受講生が学んでいます。

だそうです。



なんとなくAzure Functionsで検索してみたらそれっぽいのが出てきました。

Azure Functionsの講座の感想

とてもよかったですw

Getting Started with Azure Functions

ポータルで簡単なスクリプトを実行するに始まり最終的にはARMテンプレートでCIするまでを5時間で概観できるとは思っていませんでした。

標準的な開発を説明するだけでなく、複数ある開発手法（デバッグ、デプロイ）のメリット・デメリット比較やAzure Fucntions/Logic Apps/Microsoft Flowの使い分け、料金プランを比較したり、サーバーレス・マイクロサービスアーキテクチャのベストプラクティスをどう適用するかにまで話が及んでいて想像以上に本格的でした。

全部英語だったのでついていけるか不安でしたが、Udemy側で自動生成の英語字幕（Serverlessを一度も正確に表示できないなど不完全ではあるw）がついていたり、速度を変えれたり（*0.5、0.75、1.25、1.5、2）親切でした。

定価の¥15,000だったら尻込みしますが、これがたったの¥1,300だなんてラッキーだなぁと思います。

ちなみにお品書きはこんな感じでした。

1. Get Started with Azure Functions

  • The Course Overview: 2:25
  • What are Azure Functions?: 9:22
  • Setting Up Your Azure Account: 6:20
  • Writing Your First Azure Function: 7:38
  • How Does Pricing Work?: 9:08

2. Different Languages in Azure Functions

  • JavaScript in Azure Functions with NodeJS: 10:25
  • C# in Azure Functions: 10:45
  • F# in Azure Functions: 12:08
  • Python in Azure Functions: 10:41
  • PHP in Azure Functions: 9:46
  • Other Languages in Azure Functions: 4:27

3. Triggers and Bindings

  • Introduction to Triggers and Bindings: 7:33
  • Basic Triggers: 12:20
  • Storage Triggers: 13:50
  • Other Triggers and Bindings: 5:24
  • Advanced Bindings: 13:23

4. Architecting with Azure Functions

  • Choosing Between Flow, Logic Apps, Azure Functions, and WebJobs: 7:23
  • Choosing a Hosting Plan: 3:04
  • Best Practices for Azure Functions: 5:35
  • Security Concerns: 15:10

5. Building a Serverless Architecture

  • What is Serverless Architecture?: 6:38
  • Why Serverless?: 3:13
  • Serverless Considerations: 6:10
  • Serverless Best Practices: 5:03
  • Moving to a Serverless Architecture: 5:36

6. Testing and Monitoring Your Azure Functions

  • C# Integration Tests: 12:31
  • Using the Postman REST Client: 9:59
  • Monitoring Your Azure Functions: 11:55
  • Debugging Your Azure Functions: 6:35

7. Automating Deployment

  • Using Azure Functions Core Tools: 8:45
  • Using Git to Edit and Deploy Functions: 11:18
  • Introduction to Azure Resource Manager: 10:09
  • Using Azure Resource Manager with Function Apps: 12:16
  • Putting it All Together for Continuous Delivery: 9:18

Getting Started with Azure Functions

プログラミングの勉強に動画はあり？

どちらかと言うと無し派でした。

Code SchoolでRspecの勉強したときよくわからなくて若干トラウマです。

今回は

  • テーマ的に部分部分知っていた
  • 言語（C#）的に馴染みがあった
  • どういうポイントがあるのかを押さえたいという目的があった

ので、それらに適う形でかなりありだなぁと思いました。

ある程度知ってる前提で、実際の動作（ポータルからポチポチする、コードを書く）を1つ1つ見せてもらえるのはザザッとキャッチアップしたいときにはもってこいっぽいです。

Golang一瞬でキャッチアップ()しないといけないのでこれ（評判良い）を観てみるのと、他にもいいのがあったら買っておこうと思いました。

人にプレゼントもできるらしいです。

Go: The Complete Developer's Guide (Golang)

英語動画コンテンツ

純粋にAzure Functions勉強したいという思いとは別にこの本を読んで思うところがありました。

（しつこい）

著者はプルーラルサイトでiOS、Android、.NETなどの講座を大量に持ってる人です。

資産形成の面で、たしかに1回作ればそれなりの期間は収入入り続けるのかとか、一瞬で古くなってしまうのではとか色々考えていました。

いざ観てみるとFunctionsの話はめちゃくちゃクオリティが高くて、これ1人でどうやって作んねん…って思ったら最後のページにCreditが出てきて9人がかりで作成されたコンテンツであることがわかって吹きました。

なかなかイバラな道なんでしょうか。

あとは今年の3月に1週間くらいアメリカに行って技術セッションに参加するので、Udemyにかぎらず慣らさねばって思いました。

by ·0件のコメント

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がマージされたのは嬉しかった
  • コードでコントリビューションしていけるようにがんばるぞ

というおはなしでしたー

by ·0件のコメント

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始めるならこれ！という感じです。

実践AWS Lambda ~「サーバレス」を実現する新しいアプリケーションのプラットフォーム~

posted with ヨメレバ
西谷 圭介 マイナビ出版 2017-06-09