de:code 2019参加レポート


こんにちは 弥生の辻野です。

この記事は私がde:code 2019が参加した際のレポートになります。
(ちょっと時期を逃してしまったのですが…)

■はじめに:de:code 2019って?

まずde:code 2019って何と思う方への軽い説明です。
Microsoftが毎年1回開催している技術者向けの一大イベントで、 今年はなんと延べ来場者数(2日間)5,172人だったようです。

www.microsoft.com

■初スピーカーに挑戦

ここ数年弊社はde:codeにスポンサーとして参加しており、ブレイクアウトセッションとして50分の枠をいただきました。
今回そのセッションの中で、製品の開発だけでなく、Azureの運用構築についても紹介することになりまして、 そこで日頃Azureの運用構築を行なっている私が初のスピーカーにチャレンジする事となりました。
当日の資料は以下ご参考ください。

※閲覧にはMicrosoft アカウントまたはLinkedIn アカウントで サインインが必要です。


■準備開始:セッション資料作成

私がブレイクアウトセッションを行うにあたり、準備は大きく2つでした。
セッション資料作成と発表練習です。

私はこの2つでしたが、de:code 2019参加全体を監督していた中山は出展ブース内容の調整、 ブースへ来ていただいた方へ渡すノベルティの準備など他にも多くの準備を行なっていました。
諸々の準備があってこそであることを改めて再認識です。

発表のネタは比較的すぐに決まりましたので、発表慣れしている先輩のアドバイスのもと以下のように進めました。
①:パワーポイントに話したい内容の概要だけ書いたアウトラインの作成
②:アウトラインに肉付け
③:図の追加や表現の修正
④:②~③の繰り返し

■準備開始:発表練習

事前にこの日程までにセッション資料作成の①まで作って持ち寄りましょうと決めていたので、 ①の時点から発表の練習を始めました。

初のスピーカーだったのでもっと資料が完成した状態で発表練習をするのかと思っていたのですが、
発表者は発表順などを意識していなかったので内容的に多少被ってしまう所などあり
そのような後々気がつくと大変な箇所を早いうちから気がつけたので良い練習となりました。

また弊社の持ち時間50分を私含め3人で15分ずつ担当する事を事前に決めていました。
その持ち時間を意識しながら発表練習を行いました。

その後は次回の練習日を決め、各自がセッション資料作成の④を行い、リハーサルの繰り返しでした。

■セッション当日

8時過ぎに現地に到着し資料の最終確認と発表順番などを会場のスタッフさんと打ち合わせしました。
その後弊社ブースに移動し当日の動きについて軽く認識合わせ。
私は午前中を発表練習の時間として頂けたので、発表者控室にて小声でひたすら発表練習をしてました。

いざ発表直前となりステージ裏で共に発表する藏屋、牛尾と待機。
ステージ裏からも会場の様子をモニターで確認できたのですが、
去年は数十人規模の来場者だったとお聞きしていたのに明らかに多い!
あとから集計した結果、今年は弊社のセッションには186人の方がいらっしゃったようです。

f:id:kentsuji:20190620113508j:plain
セッションの様子

セッション自体は練習の成果もあり、時間超過などもなく無事完了することが出来ました。
発表後はブースなどで他社のエンジニアが発表内容について質問に来てくれたのが大変嬉しかったです。
その後はブースでの説明、AzureAD関連のセッションに参加、澤円さんのセッションをライブビューイングで見るなどをしていました。

■まとめ

発表が決まった際は正直どんな発表をしようという不安ばかりでした。
しかし発表準備から当日までを通して話し方、資料のまとめ方などを学ぶ事ができ、
また発表後にはブース対応や気になるセッションにも参加しさせて頂き大変貴重な経験を得ることができました。

得た内容を少しでも日頃の業務に活かしていきたいと思います。

実践!オブジェクト指向 文系出身ひよっこエンジニアの勉強記

こんにちは、弥生の野川です。

この記事はMisoca+弥生+ALTOA Advent Calendar 2018の23日目のエントリーになります。 いよいよクリスマスが目前ですね!

簡単に自己紹介をさせていただきます。

・2018年4月に弥生に新卒入社
・入社以前にプログラミングの経験は全くなし(学生時代は文系の学科に所属)
・入社後のJavaの研修でプログラミングに興味を持ち、開発の部署への配属を希望
・現在は自動テストを開発・運用するチームでエンジニアとして奮闘中(歴6ヶ月)

今回はこんな私が、オブジェクト指向について勉強して思ったことを書き連ねます。

はじめに:一般的なオブジェクト指向の説明

一般的な参考書では、オブジェクト指向は以下のように説明されることが多いかと思います。

  • 対象(オブジェクト)そのものに重点をおき、対象のふるまいや操作が対象の属性として備わるという考え方。
  • 現実世界の部品(モノ)をモデリングし、プログラムに置き換えるという考え方。
  • オブジェクト間のメッセージ・パッシングでプログラムを動作させるという考え方。

しかしながら、プログラミング未経験者にこの説明は本当にキツイ! なぜかと言いますと・・・

初心者はここがわからない

  • 「オブジェクト指向」という名前に馴染みが1ミリもない。
  • 「対象に重点をおく」のは良いけど、おいてどうするのかがわからない。
  • 「ふるまいや操作が属性として備わる」のイメージがつかめない。
  • 「現実世界のモノをプログラムに置き換える」なんてできるんですか?って思う。
  • 「オブジェクト間のメッセージ・パッシング」がまるで呪文のように聞こえる(つまり何もわからない)。

などなど、初心者の前には高すぎる壁が立ちはだかります! (よくこれでへこたれずに勉強したな自分・・・)と思うぐらいです。

オブジェクト指向はこうして理解する

そんな壁を乗り越え、私がオブジェクト指向を理解することができたのは、 以下のことを実践したおかげでした。

  1. とにかく複数クラスのプログラムを実装してみる
  2. 先輩エンジニアと話す
  3. 複数人での開発を、身をもって経験する

これだけです。しかしこれが私にとってはすごく重要でした。

1. とにかく複数クラスのプログラムを実装してみる

 概念を文字だけで理解しようとするのではなく、 実際にメインクラスで他クラスをインスタンス化してメソッドを呼び出すプログラムをいくつか書くと、 「オブジェクト間のメッセージ・パッシング」は呪文ではなくなりました。

特に引数・戻り値を使うメソッドだと良いです。メッセージ・パッシングめっちゃ楽しい~!ってなります。

 また、オブジェクト指向に特有な「継承」「ポリモーフィズム」などの考え方も、 実装してみないことには、なぜ必要か、どのような時に必要になるのかがわからないんですよね。

 私もそうなんですけど、文系出身の人間には結構ありがちな「概念を理解しないと先に進めない!」という思考は、 オブジェクト指向の勉強ではちょっと横に置いておくのが良さそうです。

2. 先輩エンジニアと話す

 自主勉強の一環で、トランプのゲームを実装している時のことです。 1枚のカードを表すカードクラスはサッと実装できたのですが、 束になったトランプクラスを作ろうと思ったところで手が止まりました。

「た、束・・・!?」

私が悩んでいると、プログラミング経験のある同期と大ベテランの先輩が声をかけてくださって、 トランプクラスについて一緒に議論してくれました。 ポイントは、「そこにあるかのように、トランプの束の状態を想像すること」でした。

・トランプの束に含まれているカードは、4種類のマーク×13の数字の組み合わせで、計52枚。
・カードの引き方は、束の好きなところから引くパターンや、
 山の上から1枚引くパターンがある(ゲームによる)。
・カードが引かれると、そのカードは束の中からなくなる。

などなど、トランプの特徴を1つ1つあげて、それらに対応するように実装していくと まさに現実世界のトランプ(=モノ)をプログラムで実現することができました! 下図は、束の好きなところから引くパターンで実装しました。 f:id:kenta_nakayama:20190116100338p:plain

このレベルの話を先輩エンジニアとする必要が果たしてあるのか? と思われてしまいそうですが、私は一人で中身を考えていると、合っているのか間違っているのかもわからずモヤモヤしてしまいます・・・。 先輩エンジニアが「うんうん、そうそう」と言ってくださるだけで脳内の設計が明快になるので、とてもありがたいです。

3. 複数人での開発を、身をもって経験する

 ソフトウェア開発では、機能ごとに分担して実装したり、既存のコードを別の人が後になって改修したり ということが当たり前のように行われています。

しかし、私はエンジニアになるまで、ソフトウェア開発の工程なんて全く気にしたことがなかったので、 オブジェクト指向の目的である「効率化」「保守性」の必要性もわからないというレベルでした。

最近ようやく、私も開発プロセスの一端を担うようになったので、 「開発ってみんなで分担してやるから、機能ごとに分かれてると開発・改修しやすいんだな~」 ということを肌で感じることができています。

このイメージを持てた瞬間、オブジェクト指向への親しみやすさはぐんと跳ね上がりました。 特に、なぜこんなにもアクセス修飾子を気にしないといけないのか、その理由がよくわかるようになりました。 仕事では、既存の自動テストが安定して動作するようにコードを改修することが多いのですが、 いじるものがprivateメソッドだと、あまりびくびくせずに変更を加えることができます(笑)

まとめ:オブジェクト指向を理解するために必要なこと

色々書きましたが、未経験者にとってはとにかく【イメージや実感をつかむこと】が重要です。

個人的に、上で述べた①~③は、イメージや実感をつかむための最速の手段だと思っています。

もしこの先、プログラミング経験の浅いメンバーが入ってきて、 オブジェクト指向で大変な思いをしている時には 設計について一緒にあれこれ話したり、私がやってみて良かった課題を共有したりしたいです!

さいごに

ここまで読んでいただき、ありがとうございました。

Misoca+弥生+ALTOA Advent Calendar 2018、次は@ryo_mt09spさんの「たぶんVue.js + Django REST framework」です。お楽しみに!

AWS AppSyncについて勉強してみた

こんにちは、弥生の八木です。

この記事は、Misoca+弥生+ALTOA Advent Calendar 2018の 22日目の記事です。

記事を書くにあたって、せっかくなので業務とは関係なく、気になる技術を勉強しようと思ったので、 今回は、AWS AppSyncとそのバックグラウンドの技術であるGraphQLを勉強したことや簡単に作ってみたものについて書きます。

AWS AppSyncとは

GraphQLベースのAPIを作成でき、APIに合わせてDynamoDBを自動で作成できる「フルマネージドGraphQLサービス」です。 AWSのコンソール画面からDBを設計、設定をするだけで簡単にAPIとDBを作成できます。

GraphQLとは

GraphQLは、Facebookにより開発されたオープンソースのクエリ言語のことです。 クエリ言語とは「問い合わせ言語」といい、コンピュータのデータに対して問い合わせるための言語で、代表的なクエリ言語だと、SQLが当てはまります。

以下のようなリクエスト、レスポンスになります。

リクエストサンプル

query list {
  listHoge {
    items {
      id  hoge
    }
  }
}

レスポンスサンプル

{
  "data": {
    listHoge": {
      "items": [
        {
          "id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
          "hoge": "hogehoge"
        }
      ]
    }
  }
}

実際に動かしてみた

やること

AWS AppSyncでAPIを作成し、クライアントからAPIにリクエストして、なんでもいいから結果を受け取って「AppSync使ってるぜ」感を味わう!

やったこと

  1. WebクライアントからAWS AppSyncにアクセスできるようにする
  2. AWS AppSyncでAPIとDBを作る
  3. 作成したAPIのエンドポイントなど設定する
  4. WebクライアントからAPIにアクセスし、レスポンス結果を画面に表示する

APIとDBの作り方

  1. AWSコンソールにログインし、「Create API」ボタンをクリックする f:id:ym_AdventC:20181218183733p:plain

  2. 「Create with wizard」にチェックを入れ、「Start」ボタンをクリックする f:id:ym_AdventC:20181218183842p:plain

  3. 「Model Name」に任意にDBの名称を付けて、「Configure model fields」でDBのカラムの設定をする、完了したら「Create」ボタンをクリックする f:id:ym_AdventC:20181218184133p:plain

  4. 「API Name」に任意にAPIの名称を付けて、「Create」ボタンをクリックして完了です f:id:ym_AdventC:20181218184716p:plain

作成したAPIは、AWSコンソール上でも動作させることができます

登録のクエリ f:id:ym_AdventC:20181218192142p:plain

取得のクエリ f:id:ym_AdventC:20181218192344p:plain

APIにアクセスして結果を取得

簡単にReactのサンプルプロジェクトをいじって取得した内容を表示させます。

Reactプロジェクト内のApp.jsの設定にGraphQLのクエリを記述し、レスポンス結果を取得する関数を作成

~~略~~

const ListTodos = `
query list{
  listTodos{
    items{
      id name description
    }
  }
}
`;

class App extends Component {
  state = {todos: []}
  async componentDidMount() {

    const todos = await API.graphql(graphqlOperation(ListTodos))
    console.log('todos:', todos)
    this.setState({todos: todos.data.listTodos.items})
  }

~~略~~

実際にWebブラウザからAPIにアクセス f:id:ym_AdventC:20181219180840p:plain

GraphQL APIでDynamoDBにアクセスして取得したデータを表示しています。 (画面下部のWebブラウザの開発ツールのコンソールに表示しているのが、レスポンス結果です。)

まとめ

AWS AppSyncについて触ってみてわかったこと

  • とても簡単にAPI(GraphQLベース)とDB(DynamoDB)を作成できる
  • APIアプリケーションを作成する必要なし
  • APIサーバーを用意する必要なし
  • DBサーバーを用意する必要なし
  • 簡単なWebアプリやスマホアプリ作成に便利

おわりに

AWS AppSyncで作成したAPIレスポンスを検証するために、React+AWS Amplifyを使用しましたが、環境構築やReactのJSXでWebブラウザ画面に表示するほうが大変でした。。 当たり前ですが、継続的に勉強しなきゃいけませんね!

Misoca+弥生+ALTOA Advent Calendar 2018 、次は@s_nogawaさんの「実践!オブジェクト指向 文系出身ひよっこエンジニアの勉強記」です!お楽しみに!