by ·0件のコメント

明けましておめでとうございます。

freeeに転職して（ = エンジニアとして働き始めて）3年が経ちました。

2017年はいろいろはじまたいい年だったなぁと思っています。

2018年を強く生きるために2017年を振り返ったり、今年やりたいことを書いたりします。

2017年

仕事面

年初の時点ではこんな感じであれやりたいこれやりたいみたいなことを言ってたみたいです。

転職して2年が経ちました。2016年の振り返りと2017年の目標

  • クエリ、データベース: 自分で早くKPIを追えるように、それが動く土台も詳しく
  • 機械学習: 経営者が一歩先に進むための判断をサポートするという文脈かついいタイミングなので追いたいです
  • 設計: 打ち手を増やして、サービスを作る、変える、大きくするを継続的によくするために。汎用的なデザインパターンとクライアントサイドの定石をまず身につけます。まだまだベストプラクティスを追うフェーズでよいと思っています。
  • フロントエンド: ユーザさんが直接的に触る部分をよくするための技術、問題解決できるサービスであることを伝えるための手段として。サービスで使われてるメインの技術をまずは追えるように…C#（WPF）的な文脈ではもうちょいxamlちゃんと理解しようと思います。
  • linux: もうちょっとコマンド自由に使えるように…去年はLinux標準教科書を環境作って追ってみたら多少ましになったので、その復習プラスサーバの負荷状況調べれるようになりたいです。
  • git: 最低限もわかってない感があるので、本一通り見るのは最低限やります…
  • Xamarin: C#のコードが自分のスマホで動くのは純粋に楽しそう
  • エディタ: RubymineとVisual Studioもうちょい使いこなそう…

実際書いた通りにやったこともあります。

機械学習も3月頃まで毎週勉強に参加しつつCourseraやったり、最終的にはAzure MLを使って社内勉強会でハンズオンをやったりしたのは楽しかったです。

でも、とあるランチがきっかけでもっと目の前の問題に向き合おうと思いました。（毎年言ってる気もする）

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

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

どういうテーマ・技術分野をするにしても、それによって解決したい問題がある状況の方が身になると。

一方で、本を読んだりする中で何かを学ぶときのスコープ（範囲、期間）の定め方が曖昧過ぎたのかなとも思いました。

今年最も影響を受けた本の1冊でもあるSOFT SKILLS　ソフトウェア開発者の人生マニュアルでも「学ぶことを学ぼう」という部（9章分）が確保されているほど大事なテーマです。

今年は初めてLTや長めのセッションにも登壇しましたが、学習の習慣作りとして重要な役割を果たしてくれました。

日付 イベント タイトル
6/22 第6回 Tokyo Jazug Night Azure FunctionsとAWS Lambdaの開発フローの違い
7/25 第7回 Tokyo Jazug Night VSTS、Slack、Microsoft FlowでASP.NET CoreアプリのCIをやってみる
8/30 初心者歓迎XamarinのLT会！Xamarin入門者の集い #3 LottieXamarinで始めるXamarinアプリのアニメーション
10/7 .NET Conf 2017 Tokyo, Japan Xamarin本の歩き方
12/9 JXUG福岡 Xamarin初心者向けハンズオン Xamarin本の歩き方2017

登壇の申し込みをする時点では何もテーマがないんですが、そこからそのときそのときの関心事を考えて、そこまで余裕のない期限に焦りつつ勉強し、なんとか資料にしていきます。

もちろん自分に確実に技術が身についていなくても喋れるのは喋れるし、妥協もいっぱいします。

それでも短期間で一定の形にして人前に晒すのを繰り返すことは意味があると思うので続けます。

登壇は最初は自分で申し込んだものの、.NET ConfやJXUG福岡での登壇はお声がけいただいたものでした。

きっと5分のLTの経験、しかも3回しかなかった自分が45分のセッション（.NET Conf）や東京から離れた土地での勉強会（JXUG福岡）に自分から踏み込む勇気はなかったはずですw

幸運にも機会が機会を読んでくれました。

会社では窓際（物理）でだいたいひきこもっている一方で、コミュニティや他社の方との絡みが広がっていったのもとても嬉しかったです。今年もかまってください。

一方登壇系は自分のやり方ではテーマがバラバラになったり、腰を据えて勉強するのが難しい短期決戦なのでもう少し長いスパンで取り組みたいと思うこともけっこう初期からありました。

そこで取り組んだ技術書典での同人誌の執筆やQiitaでのアドベントカレンダー記事、特定リポジトリ（OSS）へのコミットなど継続的にやっていきたいことです。

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

Advent Calendar 4記事の背景にあったテーマ

結果的にMicrosoft MVPも受賞できましたが、受賞自体よりも受賞することで得られる機会を大事にしていきたいと強く思っています。

Microsoft MVP を受賞しました

つまるところ、勉強しないといけないテーマ（技術領域）は年初に「これがやりたい」と思う以上にそのときそのときで変わります。

業務で Xamarin（今後公式にお知らせしますが、Xamarin.Macを使ったMacアプリは無事リリースしました🎉🎉🎉）やることになるとは微塵も思っていませんでした。

そのため、目の前の課題にしっかり向き合い、その向き合い方をより真摯で本質的にするための姿勢・習慣作りを明確にしておくことが大事そうということです。

ある程度「こういう領域やってみたい！」もないといざというときに「え、自分って何やりたいん…？」って困るんですけどね…

そういうわけで2018年の目標はより習慣的なところに重きを置きたいと思います。

音楽面

歌については去年の6月を最後に歌って気持ちいいなぁと思えない状況がひたすら続いています。

各フレーズの1言目が音にならなかったり、息が続かず異様にお腹に力が入ったりただただ苦しいです。（語気弱め）

苦手でできないことばっかりやっているので、ランチカラオケ復活してゆるゆるする時間でも作ろうと思います。

一方聴く面では7月にいった福岡でのミスチルライブが空前絶後のクオリティでした。

中3ではまりバンドをやり始めたきっかけにもなったミスチル、2009年にSUPERMARKET FANTASYのドームツアーで本物を見てからずっと追いかけていますがこの回ほど完璧と思ったことはあいませんでした。

各曲最高のシーンを集めた映画のようで、ある意味では臨場感を失っていました。

今年は早速主題歌も決まってるので楽しみですね！

家庭面

嫁氏最高本当にありがとうに尽きます。

行きたかった海外旅行（マレーシア・マラッカ）には行けたものの、新婚旅行だったり、結婚式的なものだったり大事なイベントがまだだったりするので、日付決めます。

あと、結婚したら自分の両親とお嫁さんと沖縄に行く！！！って何年か前にしていた約束も果たせたのはよかったです。

今度は2人で離島行きたい。

精神面

年初に掲げていた睡眠の質向上は継続的に取り組み、眠いと感じる日は1年でほぼなかったです。

このスリープ・レボリューションという本で文字通りスリープをレボリューションしました。

あと、精神は半信半疑で読んだマインドフルネス系の本（世界のエリートがやっている 最高の休息法――「脳科学×瞑想」で集中力が高まる）が刺さりました。

イライラと向き合うにあたり、宗教的なアプローチ（反応しない練習 あらゆる悩みが消えていくブッダの超・合理的な「考え方」とか）や名言的アプローチ（デール・カーネギーの悩まずに進め ──新たな人生を始める方法）もそれぞれわかる、せやかて工藤みたいなノリでなかなか定着しませんでした。

でもこの本は単にイライラしない以上に自分のパフォーマンスに直結するのと、よりハードワークな状況を迎えるにあたっての「心身を休める技法」の必要性に迫られている状況がある中取り組みの裏付けもしっかりしているようで比較的定着しそうです。

2018年

仕事面

新チーム

年初からこの1年親しんできた技術とはけっこう別の技術スタックを扱うチームでがんばることになりました。

技術面では、C#や.NETに触れる中で言語の周辺を支えるツールやライブラリの中身まで追うようになってきました。

その向き合い方を忘れずにまずはキャッチアップしてやり切れることを増やしたいなぁと思います。

副業/複業

あと大きいのは副業/複業を始めることです。

またしてもSOFT SKILLS　ソフトウェア開発者の人生マニュアルの影響ですが、自分が個人で仕事受けるとしたら何だろう？と、そういうテーマの章を読んでこのブログのAbout Meページで求職を書いてみました。

About Me

そしたら

「こういうことできるので仕事ください！」

と出せることの幅や深さに問題意識を持たざるを得ませんでしたw

そして実際に書いた内容で求職（副業/複業）し始めました。

意図としては、

  • 自分ができるようになってきたと思うことは社外でも（ある程度客観的に）通用するのか挑戦したい
  • ここに書くことをテーマに深めていけたら素敵。振り返りもしやすい。
  • 「どこまで勉強するか」の1つの基準になる。「仕事を受けてやり切れるまで」
  • 弊社サービス会計freeeで帳簿をつけ、Macアプリで電子申告する
  • 特定の組織に依存せず生きる力を…

というところです。

週あたりの時間を決めてやって行く予定ですが正直やってみないとわからないのでこれを主軸にやってみてから考えます。

幸い開発と本を書くことについてはお声がけいただいています。※確定して始まっているわけではない

弊社のサービス開業freeeで必要な書類は揃えたので、1/4か5に税務署に提出してきます。

習慣

習慣としてはこういうのを目安に作っていきたいです。

絶対達成したいのとできたらやりたいのを敢えてふわっと…

機会があれば他をおいても挑戦します。優先度順。

  • 本: 2冊/年
  • 登壇: 6回/年
  • OSS: 1PR/月
  • ひとまとまりのソースコード公開: 1リポジトリ/月
  • 技術記事: 2記事/月
  • 技術書: 30分/日
  • その他本: 30分/日

寄稿とかないかな？

テーマ

昨年はXamarin勉強した一方でサーバーレスな技術に触れてとても楽しかったです。

UIをHTMLやJS的なフロント以外（モバイル、Bot、Chat）におさまるというかフロント苦手意識が強い？

色々ためしてみたいことたくさんあるので、Trello（カンバン式タスク管理ツール）にチケット切って積み重ねていこうと思っています。

あとはこういう単位で自分で一通り使える状態のコード書いてGitHubにあげていきたいです。
https://github.com/toshi0607/ErrorNotificationLambda

「これできます」と言うためには、細々tips記事書くのを目標にしていたら到達しない（書くことは大事）だと思っていて、一通りサービスなりライブラリなり形にしていくのを増やしていかないとと思うこともあり上に載せたコードを書きました。

そして去年はAWS LambdaやAzure Functionに少し触れてとても楽しく、PaaSの幅広げたい（組み合わせて使いたい）のでAWSかAzureの認定資格とります。

音楽面

楽しいと思う気持ちを復活させる。

  • カラオケ: 2回/月
  • 歌練習: 1回/週

家庭面

家をきれいにw

いらないものを捨てて、書斎を復活w

ソファとか床とかでPC長時間いじるの辛い…

あと、

  • 品川健康センター: 2回/月
  • 走る: 1回/週

最近引きこもりすぎて走るのすらやってなかった。

健康診断評価のランクは変わってないけど、数値は悪くなっているw

そして現金以外の資産の比率高める。

精神面

平和な気持ちで過ごしていい1年にしような！

by ·0件のコメント

独習C 新版のレビュー記事です。本の分量自体が索引含め606ページととても読み応えのあるものだったため、読んだ感想（ざっくり）からだんだん詳細が伝わるように書いていこうと思います。

全部読み、各章についているの理解を確認するための問題も一通り考えてみました。

こういう人が読むといいかも

普段業務や趣味でC#である程度意図通り動作するアプリケーションを書いているが…

  • 人のコードを読んでいて構文的にわからないことがある
  • 動くけどなんでそれが構文的に正しいかよくわかってないなぁと思うことがある
  • いつも手に馴染んだ書き方で書いているが、他にも書き方ありそうなので打ち手を増やしたい
  • C#を体系的に勉強したいけどなにを「体系的」とするか一例を見てみたい

書いたことがあるけど、動いている部分を説明できるように「基礎」を勉強し直したいときに読むとよさそうです。

僕自身が読むにあたっては理解や知識に漏れがる部分がどんどん埋まっていく感じがしました。

こんな人が読むのは厳しいかも・向いてないかも・書いてないかも

  • デスクトップアプリ、モバイルアプリ、Webアプリケーションのフレームワークの使い方が知りたい
  • Visual Studioを使いこなしたい
  • はじめてC#を書くにあたってC#の概要を知りたい

はじめてC#に触れる人がこの本を読むのはちょっとしんどいと思いました。

C#経験が少ない人のことも意識されてますが、網羅的かつ詳細に説明されているだけに、どれも大事なことのように思えて読み終わらなさそうです。優先度の甲乙がつけがたい。

レビューを書く人（自分）のC#歴

C#との接点

  • 2015年夏くらいから業務でWPFのアプリ開発を半稼働くらいで開始
  • 2016年は半分と少しくらいWPFアプリ開発に従事
  • 2017年は7割くらいXamarin（Macアプリと趣味でモバイルアプリ）とWPFとAWS LambdaでC#を触る

読んだ本

  • Xamarin本一通り

あとC#本何冊か部分部分読みました。

特徴的なところ・いいなと思ったところ

似た使い方をする構文の違いの説明が詳しい

  • ジャグ配列と多次元配列のLengthの違い
  • ==とEqualsの違い
  • &と&&の違い
  • Regexのインスタンスメソッドとクラスメソッドの違い
  • readonlyとconstの違い
  • File/DirectoryとFileInfo/DirectoryInfoの違い
  • 値型の値渡し、参照型の値渡し、値型の参照渡し、参照型の参照渡しの違い
  • ListとLinkedListの使い分け
  • LINQのクエリ構文とメソッド構文の違い
  • 匿名型とタプルの用途の違い
  • interfaceと抽象クラスの使い分け
  • DynamicObject、ExpandoObjectの使い分け

本文中で説明されているものもあれば、「エキスパートに訊く」という特設コーナーでQA形式で説明されているものもあってとても勉強になりました。

使っているはずだけど知らなかったことが振り返れる

  • if、while、do whileの{...}省略時の意図していないはずの挙動
  • フィールドの初期化子、コンストラクター、オブジェクトの初期化子の初期化の順番
  • C#6からラムダ式で書けるようになったメンバーの一覧
  • Spritメソッドでseparatorなしの場合はIsNullOrWhiteSpace相当区切り
  • 正規表現で最長一致・最短一致させるための書き方
  • Stackはforeachで取り出すときも後ろから取り出す
  • 構造体使用が妥当なケース
  • ハッシュテーブルへのアクセス効率

自明なものとして表立って説明されることはなかったり省かれたりすることが多いけど概念的に大事なことを一言で言い表した上でC#の実装や図表と合わせて説明されている

  • サロゲートペア
  • バッファー
  • コレクション
  • スタック
  • キュー
  • セット
  • ディクショナリ、マップ、ハッシュ、連想配列
  • ジェネリック
  • アセンブリ
  • ストリーム
  • シグニチャ
  • スレッド
  • プロセス

ラムダ式登場の経緯

デリゲート型にをより簡素に書くためにラムダ式が登場した背景が具体的なコードと共に説明された上で、ラムダ式をよく使うLINQの説明がなされていてとても頭に入ってきやすかったです。

この部分に限らず、全体的に単に使い方だけでなく構文登場の背景や、以前のC#バージョンではこう書いていたが今はこう書けるので今後はこう書いていくべきのようにC#をとりまく歴史の中で説明されているので頭がスッキリしました。

全然知らなかった、考えてみたこともなかった…

  • volatile
  • 属性や動的オブジェクト（DynamicObject派生クラス）を自分で定義して使う
  • .NET FrameworkでPythonを動作させる（IronPython）
  • マルチキャストデリゲート
  • 演算子のオーバーロード

章毎の確認問題

章毎に理解度を確認するための問題がついています。

コードを書く以外の問題（◯×問題）を掲載するので、試しに確認してみてください。答えが気になる方は是非本でどうぞ！

※章途中の小問題もけっこうあるのでここに掲載する倍以上の問題とその解説が載っています。

  • 1章
    • C#の特徴を「マルチパラダイム」「マルチプラットフォーム」というキーワードを絡めて説明してみましょう。
    • C#アプリは、どのメソッドから実行されますか。また、そのようなメソッドのことをなんと呼ぶでしょうか。
    • 文の末尾を示す記号を答えてください。
    • C#で使えるコメントの記法をくべて挙げてください。また、これらのコメントの違いを説明してください。
  • ２章
    • 次の文章は、C#の基本構文について述べたものです。正しいものには◯、間違っているものには×を記入してください。
    • ( )小数点型は、符号なし型と符合あり型とに分類できる。
    • ( )文字列リテラルはダブルクオート、またはシングルクオートでくくる。
    • ( )short型の型サフィックスは「〜s」である
    • ( )暗黙的な型変換は常に安全なので、桁落ちなどの情報欠落は発生しない
    • ( )メソッド/フィールドなどにアクセスするには、必ずnew演算子でクラスをインスタンス化しなければならない。
  • 3章
    • (省略)
  • 4章
    • (省略)
  • 5章
    • (省略)
  • 6章
    • この文章は、コレクションについて説明したものです。正しいものには◯、誤っているものには×を付けてください。
    • ( )Listへの挿入/削除は、位置に関わらずほぼ一定のスピードで可能です。
    • ( )LinkedListへの挿入/削除では要素前後のリンクの付け替えが発生するので、比較的低速である。
    • ( )HashSetは要素の重複を許さず、一意の値を決められた順序で保持します。
    • ( )Dictionaryは一意のキーと値のペアでデータを管理します。キーの並び順は保証されません。
    • ( )Stackは先入れ先出し、Queueは後入れ先出しと呼ばれるデータ構造です。
  • 7章
    • 以下はオブジェクト指向の主要なキーワードについて説明したものです。正しいものには◯、誤っているものには×を付けてください。
    • ( )フィールド/メソッドは外部から呼び出すことが前提の仕組みなので、アクセス修飾子も既定はpublicである。
    • ( )readonlyフィールドとローカル変数の名前は重複してはならない
    • ( )forループで宣言されたカウンター変数は登場以降、そのメソッドの内部であればアクセス可能である。
    • ( )匿名型はその場限りであれば、引数や戻り値の型として利用することが可能である。
  • 8章
    • 以下の文章はオブジェクト指向構文について説明したものです。正しいものには◯、誤っているものには×を付けてください。
    • ( )派生クラスから基底クラスのコンストラクターを呼び出すには、superキーワードを利用する。
    • ( )virtual修飾子のないメソッドを、派生クラスで再定義することはできない。
    • ( )override修飾子のないメソッドに、sealed修飾子を付けることはできない。
    • ( )as演算子は左オペランドが右オペランドの方に変換できる場合にtrueを返す。
    • ( )インターフェイスを複数実装することはできるが、クラスと一緒に実装/継承することはできない。
  • 9章
    • 以下の文章は本章で学んだ機能について説明したものです。正しいものには◯、誤っているものには×を付けてください。
    • ( )catchブロックは、ブロックで指定された例外と発生した例外とが一致した場合にだけ実行される。
    • ( )クラス/インターフェイス/構造体は、互いに入れ子の関係になることが可能である
    • ( )構造体では、継承は可能だが、インターフェイスの実装はできない。
    • ( )列挙定数の型は、任意の数値型から選択できる。
    • ( )演算子のオーバーライドという機能を利用することで、「+」「-」「==」のような演算子をクラス独自に再定義できる。
  • 10章
    • 以下の文章は、デリゲート/ラムダ式/LINQについて述べたものです。正しいものには◯、誤っているものには×を付けてください。
    • ( )引数にメソッドを引き渡すような用途では、ラムダ式よりも匿名メソッドを利用すべきである。
    • ( )ラムダ式で引数がない場合には、「=>式」のように引数そのものを省略できる。
    • ( )LINQのクエリ構文は、メソッド構文でできることであれば必ず表現できる。
    • ( )LINQでは、与えられたデータソースによってプロバイダーを決定するので、アプリ開発者がプロバイダーを意識する必要はない。
    • ( )LINQのクエリ構文は必ずselect句で終了しなければならない。
  • 11章
    • 以下の文章は本章で解説したテーマニついて説明したものです。正しいものには◯、誤っているものには×を付けてください。
    • ( )スレッドを維持しておくのはリソースの浪費なので、できるだけその場その場で解放するのが望ましい。
    • ( )await演算子は、指定された非同期処理の終了を待ってメインスレッドを待機させる。
    • ( )属性によって適用できる要素は決まっている。
    • ( )dynamic型では、存在しないメンバーを呼び出してもエラーにはならない。
    • ( )イベントを登録するには、「=」演算子を利用する。

目次

意外とネットに転がってない…

  • 1章 イントロダクション
    • 1.1 C#の特徴
    • 1.2 C#アプリを開発/実行するための基本環境
    • 1.3 C#プログラミングの基本
  • 2章 C#の基本
    • 2.1 変数
    • 2.2 データ型
    • 2.3 リテラル
    • 2.4 型変換
    • 2.5 参照型
  • 3章 演算子
    • 3.1 算術演算子
    • 3.2 代入演算子
    • 3.3 関係演算子
    • 3.4 論理演算子
    • 3.5 ビット演算子
    • 3.6 その他の演算子
    • 3.7 演算子の優先順位と結合則
  • 4章 制御構文
    • 4.1 条件分岐
    • 4.2 繰り返し処理
    • 4.3 ループの制御
    • 4.4 制御命令のその他の話題
  • 5章 標準ライブラリ
    • 5.1 文字列の操作
    • 5.2 正規表現
    • 5.3 日付/時刻
    • 5.4 ファイル操作
    • 5.5 その他の機能
  • 6章 コレクション
    • 6.1 コレクションAPIの基本
    • 6.2 リスト
    • 6.3 セット
    • 6.4 ディクショナリ
  • 7章 オブジェクト指向構文（基本）
    • 7.1 クラス定義
    • 7.2 フィールド
    • 7.3 メソッド
    • 7.4 コンストラクター
    • 7.5 クラスメソッド/クラスフィールド
    • 7.6 引数/戻り値のさまざまな記法
  • 8章 オブジェクト指向構文（カプセル化/継承/ポリモーフィズム）
    • 8.1 カプセル化
    • 8.2 継承
    • 8.3 ポリモーフィズム
  • 9章 オブジェクト指向構文（名前空間/例外処理/ジェネリックなど）
    • 9.1 名前空間
    • 9.2 例外処理
    • 9.3 列挙型
    • 9.4 特殊なクラス（入れ子のクラス/パーシャルクラス）
    • 9.5 ジェネリック
    • 9.6 Objectクラス
    • 9.7 演算子のオーバーロード
  • 10章 ラムダ式/LINQ
    • 10.1 デリゲート/匿名メソッド/ラムダ式
    • 10.2 LINQ
  • 11章 高度なプログラミング
    • 11.1 マルチスレッド処理
    • 11.2 属性
    • 11.3 動的型付け変数（dynamic型）
    • 11.4 イベント

独習C 新版

by ·0件のコメント

今年は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/serverlessやAzure/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

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

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

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

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

まとめ

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

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

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件のコメント

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

by ·0件のコメント

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

by ·0件のコメント

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

Logicool ロジクール R1000SL 充電式 プレゼンテーションリモート スレート

posted with カエレバ
ロジクール 2017-03-22

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

お知らせ

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

技術書典3 出展情報 - Xamaritans

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

おまけ

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

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

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

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

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

by ·0件のコメント

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 （ってほどでもないですが）スライドから別ページに切り替えて動かしました。

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

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

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

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

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

新装版 達人プログラマー 職人から名匠への道
新装版 達人プログラマー 職人から名匠への道
Andrew Hunt, David Thomas
オーム社
Amazonで詳細を見る

P

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

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

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

気合とは具体的に

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

などのことです。

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

T

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

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

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

とりあえず言ってみる。

by ·0件のコメント

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でよしなにしてくれる仕組みを作ろうと思っていました。

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

しかし、その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しか持ってってなかったけど、端子トゲトゲの青いやつだった。コネクタ買っとくかな…

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

改善点

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

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

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

平日準備厳しい

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

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

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

UGREEN Type C USB アダプター VGA 3in1 USB3.1 C to VGA/ USB3.0/ USB-C PD MacBook Huawei Matebook Chromebook Pixel対応 Type C 変換 VGA

posted with カエレバ

その他

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

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

振り返りと今後

振り返り

Good

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

Challenge

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

今後

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

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

by ·0件のコメント

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アプリエンジニア募集！！