AWS 認定試験準備ワークショップを受けました

AWS 認定試験準備ワークショップ

https://pages.awscloud.com/event_JAPAN_certified-sa-associate.html

を受けたので、そのときのレポート

 

このセミナーでは、問題の解き方が主になります。
個々のサービスの詳細な説明はしません。

まず初めに、この資格は、AWSを使って設計ができることの証明です。

メリットとしては、客観的な評価が得られること
AWS認定の期限は2
更新するためには、繰り返し受験する必要がある。

ソリューションアーキテクトに関する具体的な内容
 → 要件に対して、AWSアーキテクチャのベストプラクティスを用いてソリューションを定義できること

現在、試験は旧バージョンと新バージョンがある。
合格した結果得られる資格は一緒。
新バージョンと旧バージョンの違いは、出題されるサービスの内容が新しいか古いかの違い

出題内容は4つの分野に分けられる。

  • 分野1:可溶性、コスト効率、スケーラブルなシステムの設計
    出題率:60%
  • 分野2:実装・デプロイ
    出題率:10%
  • 分野3:データセキュリティ
    出題率:20%
  • 分野4:トラブルシューティング
    出題率:10%

分野1がもっとも多く出題される。

問題となっているユースケースをサービスを使って解決するための問題が出る

設問は選択式の問題

今日の講義では、問題の狙いを見極めるポイントや答えのポイントを説明する。



分野1:可溶性、コスト効率、スケーラブルなシステムの設計

可用性、コスト効率、耐障害性に優れたスケーラブルなシステムの設計

最も出題数が多い分野

試験において重要なのが、これらの4つ(可用性、コスト効率、耐障害性、スケーラブル)を満たすために

どのようなサービスを組み合わせるのか知っていること。

可用性とは
→ システムが停止してしまったときに、復旧までの時間が短いこと
例えば、ec21台で動いているのであれば、停止したときのために Load Balancing を使う、など。

耐障害性とは
障害が起きてもサービスが動き続けられるかということ。

スケーラブルとは
システムの性能が足りなくなったときに、Auto Scaling する仕組みのこと
例えば SQS など

原則の1つ目

「疎結合で柔軟に」

システムが疎であるほど、スケーラビリティがあがる。

ポイントとしては、個々の固有の情報に依存しないこと

例えば、 IP アドレスを固定にせずに、 DNS とエンドポイント名を使うなど。

リソース固有の情報に依存しないサービス

  • ELB
  • RDS
  • Route 53
  • EIP(再マッピングが可能)

他のコンポーネントの健全性を前提にしない

  • ELB
  • SQS
  • SNS

 

練習問題

疎結合アーキテクチャの実装を用意にするものはどれですか?

選択肢

1:Cloud Formation

2:SQS

3:Croud Trail

4:ELB

5:Elastic Mapreduce

 

解答

2, 4

 

解説

1: 違う。コンポーネントのスタックを起動するサービス。

3: 違う。これは。ロギングサービス
 awsapiを全てロギングするサービス
なので障害が起こったときに、原因追求になる。

5: 違う。これはマネージド hadoop のサービス

 

実際に問題を解く際には、消去方が良い。

 

原則2つ目

「障害に備えた設計にすれば問題は起きない。」

各コンポーネントに障害が生じたらどうなるか?という観点が大事。

高可用性と耐障害性の考え方の違い

 

例えば、前提として、

SLAを満たすには4つのEC2インスタンスが必要という状況だった場合に、

AZ で障害が起きた場合を考える。

 

耐障害性のない例だと

AZ2つに、ec22台ずつ置いている場合。

耐障害性のある例だと

AZ2つに、4台ずつ置いている場合。

一般的に耐障害性が上がるとコストが上がるということがある。

もう1つの例だと、

AZ3つに、2台ずつ置く例。

これはコストを抑えられている。ただ、複雑さはある。

 

可用性の実現

  • 複数のAZおよびリージョンを使用する
  • 可用性の高いサービスを使う。
  • Multi-AZ Amazon RDS : 2つの AZ でレプリケーション
  • S3 : 異なる AZ に複数のコピーを保存
  • ELB : LB クラスターを提供
  • SQS : メッセージングクラスター
  • Dynamo DB :
    同じリージョンの複数の AZ 感でデータを自動的に同期してレプリケートする。
    施設規模で障害が発生してもデータを保護することができる。
  • Route 53 :DNSクエリに対する応答に失敗したことがない。

耐障害性の実現

  • Dynamo DB : 同上
  • Route 53 : 同上

 

練習問題

現在使用しているWebサービスのパフォーマンス SLA は、1秒未満でリクエストに応答するというもおです。
通常の運用でも高負荷な運用でも、4つのインスタンスにリクエストを分散することでこの SLA を達成しています。
1つの AZ が利用不可能になった場合、サービスの高可用性と耐障害性を確保できるのは次のどのアーキテクチャですか?

 

選択肢

1: 1つの AZ 4つのサーバーにサービスをデプロイする。

2: 1つの AZ 6つのサーバーにサービスをデプロイする。

3: 2つの AZ にまたがる4つのサーバーにサービスをデプロイする。

4: 2つの AZ にまたがる8つのサーバーにサービスをデプロイする。

 

解答
4

 

解説

1: 単一のAZなので違う

2: 単一のAZなので違う

3: 1つの AZ に対してインスタンスが2つだけでは SLA を満たさないので違う。

原則3つ目

「融通の聞く実装」

クラウドのメリットとしては、必要な時に生成して、不必要な時に削除するということ

固定IPアドレスが必要な構成にしないこと。(アンチパターン)

固定的なIPアドレスが必要な場合には付け替え可能なEIPを用いよう。

 

ELBを配置することで

背景にあるシステムに融通が聞く。

auto scalingを設定する。

これにより、適切なec2インスタンスの数を保持することができる。

 

自在に再起動できる設計を使用する

  • ステートフルではなく、ステートレスに。
    セッションデータを DynamoDBに保存するなど
  • ELB と Cloud Watach を使用して、インスタンスの健全性を調べる。
  • ブートストラップ
    ユーザデータやアプリケーションを、マシン起動時にインストールするようにするとよい。
    可能であれば、構成やカスタマイズ設定をインスタンス外に保存
  • S3にアプリケーションを置いて起き、ユーザデータ処理で配置など
    セッションデータなどを別レイヤ(RDS)などに保存するようにすれば、
    EC2が増えたとしても同じ値が取得できる。

 

練習問題

ある携帯電話会社が、動的コンテンツを使ってコンテストのテレビコマーシャルを放送しています。
この会社は、コマーシャルが放送された後のウェブサイトのトラフィックの急増に対応したいと考えています。
ウェブサイトは対話型で、訪問者の所在地、購入履歴、現在放送中のコマーシャルに応じてカスタマイズされたコンテンツが表示されます。
Auto Scaling を設定して需要の急増に応じてスケールアウトし、同時に需要の少ない時間のコストを最小化できる
アーキテクチャはどれですか?

 

選択肢

1: スケールアウトしなくても高いトラフィックボリュームに対応できるような最小サイズを持つ、
Auto Scaling グループを設定する。

2: トラフィック負荷のピークに対応できる大規模な Auto Scaling Group を作成し、
一部のインスタンスを停止する。停止したインスタンスを使用してトラフィックが増加したときに
スケールアウトするように Auto Scaling Group を設定し、新しいキャパシティーがすぐにオンラインになるようにする。

3: Cloud Front S3 を使用して静的コンテンツを保存する。トラフィックの増加に合わせて
スケールアウトするように Auto Scaling を設定する。事前設定された AMI から新しいインスタンスを起動し、
起動時にユーザデータを渡すようにし、起動設定を行う。

4: Auto Scaling グループをオリジンとして設定し、Cloud Front S3 を使用して変化するコンテンツをキャッシュする。
Auto Scaling を設定して、最初に Cloud Front ElastiCache にキャッシュを追加するのに
必要な数のインスタンスを起動し、キャッシュが完全に追加されたらスケールインする。

 

解答
3

 

解説

1: 常にトラフィックのピークに合わせてプロビジョニングするため、コストがかかりすぎる。

2: Auto Scalingの仕組みは、あらかじめ停止したインスタンスを用意するというものではなく

新しい EC2 インスタンスを生成したり削除したりするということ

4 : 動的コンテンツの配信に対応していないので違う

 

練習問題

3つの AZ (us-east-1 a, us-east-1 b, us-east-1 c) us-east-1で稼働しているアプリケーションがあります。
このアプリケーションは、通常9つの EC2インスタンス を実行する必要がありますが、
AZ が利用できなくなった場合に、 Auto Scaling が代替インスタンスを残りの AZ で起動しているあいだは
65% 以上のキャパシティーで実行できます。
このアプリケーションに最も高い可用性を実現できるインスタンスのデプロイ方法はどれですか?

 

選択肢

1: アプリケーションを us-east-1 a 4つのサーバー、 us-east-1 b5つのサーバーにデプロイし、

予備として us-east-1 a に停止したインスタンスを5つ用意する。

2: アプリケーションを us-east-1 a, us-east-1 b, us-east-1 c それぞれ3つのサーバーにデプロイする。

3: アプリケーションを us-east-1 b 6つのサーバー、 us-east-1 c 3つのサーバーにデプロイする。

4: アプリケーションを us-east-1 b 9つのサーバーにデプロイし、予備として us-east-1 aに停止した
サーバーを9つ用意する。

 

解答
2

 

解説

1: Auto Scaling は停止したインスタンスを起動しない

3: 2bが利用できなくなった場合、停止率が66%となる。

4 bで停止した場合に、100%停止してしまうのでだめ。



分野2:実装/デプロイ

10%の出題

全員が開発者である必要はない。

コードで自動化ができる

 

分野1(可溶性、コスト効率、スケーラブルなシステムの設計)では、何を使用するか(what)に焦点をあてた

分野2(実装:デプロイ)では、どう使用するか(How)に焦点をあてる

howに焦点を当てているので、より実践的な内容が出題される。

 

細かい機能を把握するには、実際に触ってみるのをおすすめする。

 

現在 100 ほどのサービスがあるが、

全部を学ぶのは現実てきでなないので重点的に勉強しよう。

重点的とは?

  • コンピューティングとネットワーク
    EC2, VPC
  • ストレージ
    S3, Amazon Glacier
  • DB
    RDS

上記3つはほぼ多くのビジネスパターンで必要になってくるため重要

  • デプロイメント
    CloudFormation, Cloud Watch, IAM

これは運用していくなかで必要

  • アプリケーションサービス
    SQS, SNS

これは疎結合な運用をするために必要

「コンピューティングとネットワーキング」

EC2のオンデマンド、リザーブドインスタンス、スポットインスタンスの違い、HW専有インスタンスとは何か?を理解しよう。

EBSルートとインスタンスストアルートの比較

メタデータとユーザデータを使用したブーとストラップ

ユーザデータとは、起動時に与えられるデータ。
これをつかってブートストラップする内容も押さえておこう

EC2に連携するサービス

  • ELB
    AZはまたげるが、リージョンはまたげない。など抑えておこう
  • Aout Scaling
  • EBS
    スナップショットやEBS最適化されたEC2の利用など
  • VPC
    IPアドレッシング。セキュリティグループ関連など。

 

問題の中で、IPレンジはCIDR表記で使用するため、読めるようになっておこう。

設計上の推奨としては、2つのAZにそれぞれpublicprivateのサブネットを作成する。

同じVPC内のEC2はプライベートIPを使ってアクセスできる

IPアドレスを関連ずける方法は、生成時に紐づける方法と、起動後に紐づける方法がある。

 

練習問題

EC2 インスタンスが起動され、EIP がそのインスタンスに関連づけられています。
そのEC2インスタンスで実行されているアプリケーションは、どのようにインスタンスの
新しい Public DNS 名を判断できますか?

 

選択肢

1: OSレベルの hostname コマンドを使用する。

2: EC2インスタンスのメタデータをクエリする。

3: 該当する Cloud Watch のメトリックスをクエリする。

4: EC2インスタンスのユーザデータをクエリする。

 

解答
2

 

解説

1: public nat の名前を引くことができない。

3: ホスト名はメトリックスではない。メトリックスとは常に変化するメトリックスなどを記録するもの。

4: ユーザデータはブートストラップ時の情報など。

「ストレージとコンテンツ配信」

S3 Clacier の違いを把握しておかなければならない。

S3

  • 結果を確認する整合性モデルであるということ
  • ストレージにクラスがあるということ

Clacier

  • S3は必要なときにすぐにデータを取り出せるのに対しGlacier は時間がかかる。
    これはオプションによって異なる。
  • S3での暗号化はサーバサイド暗号化のオプションが設定できる
    Gracierは全てのデータが暗号化される。

RDS

重要なポイント

フェイルオーバー時は IP アドレスが変わるので、DNS名を使用しよう

ユーザが指定した時間にバックアップが行われているよ

また、そのときにスナップショットを取っていて、それをもとに復元されるよ

復元の際は、上書きされるのではなく、新しいインスタンスが生成されるよ。

 

練習問題

プライマリの DB インスタンスで障害が発生した場合、RDS Multi-AZ 配置はどうなりますか?
3つ選択してください)

1: オリジナルのプライマリ DB インスタンスが再起動し、新しいスタンバイレプリカになる。

2: オリジナルのプライマリ DB インスタンスは削除され、新しいスタンバイレプリカが作成される。

3: DB インスタンスの DNS レコードが変更されて、新しいプライマリを指定する。

4: スタンバイの DB インスタンスがオリジナルのプライマリ IP アドレスを引き継ぐ。

5: 別の AZ のスタンバイのレプリカが新しいプライマリに「昇格」する。

6: 直近のバックアップから新しいプライマリ DB インスタンスが作成される。

 

解答
2,3,5

 

解説

この問題はフェイルオーバー時の問題。

1: オリジナルのプライマリは削除される。RDSでは、障害の要因に関わらず、すぐにセカンダリが昇格する。

4: RDS IP アドレスではなく、 DNS 名を使用する。
ほとんどのAWSサービスでは、ベストプラクティスを採用しており、DNSを利用することを覚えておこう

6: Multi-AZ RDS はレプリケーションとフェイルオーバーを使用する。

 

ここで問題を解くときに注意することが、フェイルオーバー時の処理が

選択肢の順番になっているとは限らないということ

 

順番にならべると

5 -> 3 -> 2の順番で処理が行われる。

デプロイメントとマネジメント

  • Cloud Formation
    EC2のブートストラップなども実行ができる。
  • Cloud Watch
    クラウドリソースとアプリケーションを監視

組み込みメトリックスとカスタムメトリックスの違いを把握しておこう

アラームと Auto Scaling

IAM

IAMロールなどを把握しておこう

 

アプリケーションサービス

  • SQS
    テキストのみのメッセージをやりとりできるポーリングモデルと、名前つきキュー

非同期ワークキュー

  • SNS
    Pub-Sub(プッシュ)モデル、名前付きトピック
    送信メカニズム:HTTP/HTTPSSQSSMS、メール

SNS Cloud Watch アラームと連携

この2つはメッセージングサービスである。

メッセージングサービスは、疎結合を実現するのに役立つ。

まとめ

  • 重要で、よく利用されているサービスに焦点を当てる。
  • 各サービスについて以下を実施する。
    → 基本的なユースケースとパターンを把握
    → サービスの仕組みと使用方法を把握
    → 実践での経験を積む
  • 暗記しない:試験に求められるのは機械的な暗記力ではなく、応用力です。


分野3:データセキュリティ

重要なことは、レイヤーごとにセキュリティを設定するということ

各レイヤーでどのようにセキュリティを設定するのかを把握しよう。

 

4つのレイヤー

  • インフラストラクチャーレイヤー
  • コンピューティング/ネットワークアーキテクチャレイヤー
  • データレイヤー
  • アプリケーションレイヤー

 

「インフラストラクチャー」で重要なこと

責任共有モデル

→お客さんとAWSで担保しなければならない責任範囲が別れているということ

→試験でも、どのように責任範囲が別れているのかが出題される。

 

AWS リソースの保護

最小権限の原則

アイデンティティ

各ユーザまたはプロセスの権限は、実行する必要があるアクティビティに限られる。

  • ユーザまたはプロセスの権限はアイデンティティで示される。
  • AWS API にアクセスできるアイデンティティは3種類
    → 「マスターアカウント」
    最初のメールアドレスによって設定されるアカウント
    乗っ取られたら被害がすごいので多要素認証を設定しよう。
    そのアカウント全体に対する完全な権限を持っている。
    制限できない。

MFAの追加をしよう。

ベストプラクティスは、このアカウントをアイデンティティに使わないことです。

  •  IAMユーザ
    グループやポリシーによる詳細なアクセスコントロール
  • AWSコンソール / CLI / API アクセスをコントロール
    → Security Token Service(STS)/フェデレーション

STS / フェデレーション」

おそらく理解するのがもっとも難しい仕組みが STS です。

STSを使用すると、

一時的な権限を付与することができる。

フェデレーションとは
→ AWS とか別の、例えば社内で許可を得た人だけがアクセスできるような仕組みのこと

 

練習問題

会社の AWS アカウント管理者が今日退職しました。
この管理者は、マスターアカウントとパーソナル IAM 管理者アカウントに対するアクセス権を持っていました。
これらのアカウントを使って、この管理者は別の IAM アカウントとキーを生成しました。
会社の AWS インフラストラクチャを保護するために今すぐに実行する必要があることは、
次のうちどれでしょうか?(3つ選択してください。)

 

選択肢

1: パスワードを変更し、マスターアカウントに MFA を追加する。

2: マスターアカウントによるログインに IP 制限をかける

3: キーを交換して、 IAM アカウントのパスワードを変更する。

4: IAM アカウントを全て削除する。

5: 管理者の IAM アカウントを削除する。

6: 全ての EC2 インスタンスを新しいロールで再起動する。

 

解答
1,3,5

 

解説

2: マスターアカウントは一切制限をすることはできません

4: デメリットが大きすぎるので、そこまでの必要はない。

6: ロールはSTSに基づいているため、元社員が認証情報を引き続き持っているわけではない。

「コンピューティング/ネットワークアーキテクチャの保護」

サブネットの役割は

vpcをさらに細かい IP アドレスの範囲に区切るということ。

SGNACLの比較

この2つの違いを把握しよう

ほとんどの場合はSGで対応できるが、許可の仕方だけが違う。

NACLでは、ホワイトリスト方式なので、

特定の CIDR 範囲からのアクセスを拒否することができる。

「インターネットゲートウェイ、仮想プライベートゲートウェイ、Direct Connect

VPC にトラフィックを出し入れするサービス

それぞれのユースケースを把握

  • IGW: インターネットに接続
  • VGW: VPNに接続
  • Direct Connnect: インターネットを使わずに、AWSとオンプレミスの環境を繋ぐ専用線接続
  • VPC ピアリング: 他のVPCに接続

「ルートテーブル」

通信の経路を設定するために使われる。

サブネットと関連づけられる。

IP範囲の宛先を定義

  • ローカルルールはデフォルトで定義
  • インターネット(パブリックサブネット)にアクセスするための IGW へのルート
  • オンプレミスネットワークにアクセスするための仮想プライベートGWへのルート
  • ピアリングされた VPC にアクセスするためのピアリング接続へのルート

ルートテーブルの際に意識しないといけないのが

VPC の外と中で通信をしたいときの設定。

 

練習問題

あなたは VPC 内のサブネットにインスタンスをデプロイしました。
S3 へのアクセスを許可する手順で、正しいのは次のどれでしょうか?

1: 仮想プライベートゲートウェイを追加する。仮想プライベートゲートウェイへのルートを 0.0.0.0/0 と指定する。
ACL のアウトバウンドルールでポート443 を開放をする。インスタンスに EIP を追加する。

2: IGW を追加する。IGW へのルートを 0.0.0.0/0 と指定する。SGのアウトバウンドルールで443 を開放する。インスタンスに EIP を追加する。

3: 仮想プライベートゲートウェイを追加する。仮想プライベートゲートウェイへのルートを 0.0.0.0/0 と指定する。
SGのアウトバウンドルールでポート443 を開放する。VPC から割り当てられる内部 IP アドレスを使用する。

4: 仮想プライベートゲートウェイを追加する。仮想プライベートゲートウェイへのルートを 0.0.0.0/0 と指定する。
SGのアウトバウンドルールでポート 443 を開放する。VPC から割り当てられる内部 IP アドレスを使用する。

5: IGW を追加する。IGW へのルートを 0.0.0.0/0 と指定する。ACL のアウトバウンドルールでポート443 を開放をする。インスタンスに EIP を追加する。

6: IGW を追加する。IGW へのルートを 0.0.0.0/0 と指定する。SGのアウトバウンドルールでポート 443 を開放する。VPC から割り当てられる内部 IP アドレスを使用する。

 

解答
2

 

解説
S3への経路で、仮想プライベートゲートウェイを使うことはありません。
そのため、1,3,4が除外できる。
ACLでは除外するためのアクセスのみ設定できるので、
アウトバウンドとインバウンドが設定できなければいけない。
そのため、5が除外できる。
IP アドレスは、EIPを使うので、 6が除外できる。

「データレイヤー」

データを保護する方法としては4つある

  • 転送中のデータ
    • AWS の入口と出口
    • AWS の内部
  • 保管時のデータ
    • S3
    • EBS

主要なストレージサービスである、EBS S3 を見ていこう

転送中のデータ

AWS インフラストラクチャへのデータ送信と、AWS インフラストラクチャからのデータ送信

  • ウェブ経由のSSL
  • IPSec VPN
  • 直接接続
  • インポート/エクスポート

AWS API に送信されるデータ

  • AWS API 呼び出しはすべて、HTTPS REST 呼び出しです。

S3 に保管中のデータ

アクセス

  • IAM ポリシー
  • バケットポリシー
  • アクセスコントロールリスト
  • 一時認証情報
    • 署名つき URL に使用

暗号化

  • サーバ側(AWS が管理するキー)
  • サーバ側(お客様が管理するキー)
  • クライアント側
  • クライアントコードの暗号化 / 復号化
  • キーは S3 から独立した形でお客様が管理する。

EBS に保管中のデータ」

  • 暗号化された EBS ボリューム(AWS が管理するキー)
  • EBS ボリューム上の暗号化されたファイルシステム

(お客様が管理するキー)

  • アプリケーションレベルで暗号化されたデータ
    • クライアント側にあるアプリケーションの暗号化 / 復号化データ
    • お客様が管理するキー
    • サードパーティの支援
      (例えば、一部のDBテクノロジーで使われてる Transparent Data EncryptionTDE))

EBS はインターネットにアクセスしないので、

インターネットに対するアクセスはアプリケーションの話になります。

 

練習問題

あなたの会社には機密情報があり、セキュリティポリシーにしたがってこの情報を暗号化形式で
保存しなければなりません。暗号化機能を提供するサービスは、次のどれですか?
3つ選択してください)

1: EBSボリューム

2: S3

3: EC2 インスタンスストレージボリューム

4: RedShift

5: DynamoDB

6: ElastiCache

 

解答
1,2,4

 

解説
3,5,6には暗号化機能がない。

ただし、この問題では補足が必要
5は、2018年に暗号化機能が追加された。

アプリケーションレイヤー

責任共有モデルでは、お客様が責任をおうことになっている。

「それぞれのアイデンティティによって、何を保護しているのかを把握しよう。」

  • IAM
  • OS/AD/LDAPアカウント
  • アプリケーションアカウント
  • アプリケーションの保護(オンプレミスと同様)
    安全なパスワードストレージとパスワードポリシーを使用する。

OSip tableなどで保護したり、ソフトウェアをアップデートしたりする

堅牢なロールベースアクセスコントロール(RBAC)を使用する。

 

練習問題

IAMポリシーでコントロールできるアクションは、次のうちどれですか?
3つ選択してください)

1: RDS データベーステーブルを作成する。

2: VPC SG を構成する。

3: .NET アプリケーションにログインする。

4: RDS データベースを作成する。

5: S3 バケットを作成する。

 

解答
2,4,5

 

解説
1: DB管理者の管理になる。IAMで制御できるのは RDS の作成。

3: アプリケーションのセキュリティになる。

4: 正解。1との違いは、RDSインスタンスを操作するので正解。1は、DBエンジン内の操作になるので違う。

 

練習問題

ウェブ層のインスタンス(ウェブ層の SG を共有する別のサブネットのインスタンスグループ)
からのみ HTTP トラフィックを受け入れるアプリケーション層サブネットに、
EC2 インスタンスのグループを作成しようとしています。
これを実現する方法として正しいのは次のどれですか?

 

選択肢

1: アプリケーション層インスタンスの手前の SG LB に追加する。

2: アプリケーション層の各インスタンスを、ウェブ層 SG からのインバウンド
HTTP トラフィックを許可する SG と関連づける。

3: ウェブ層サブネット IP 範囲からのインバウンド HTTP トラフィックを許可するアプリケーション層サブネットに、ACL を許可する。

4: IPアドレスに基づくアプリケーション層インスタンスにトラフィックを送信するために、
ウェブ層サブネットのルーティングテーブルを変更する。

 

解答
2

 

解説

1: ロードバランサーでは、レイヤー感でのトラフィックをコントロールできない。

3: 注目すべき点は、ACLはステートレスな操作になるので、アウトバウンドも設定しないといけない。

4: ルートテーブルはトラフィックを送信するが、ブロックはしない。

 

練習問題

公開ウェブアプリケーションがあり、ユーザが自分で登録してアカウント作成することになっています。
このアカウントは、アプリケーションの認証ユーザと静的オブジェクトを共有します。
そこで、このコンテンツを S3 に保存して、適切に権限を付与されたユーザだけがウェブ経由で
利用できるようにしたいと思います。これを実現する方法として、最もコスト効率が良く、パフォーマンス
に優れているのは次のどれですか?

 

選択肢

1: バケットポリシーでバケットにアクセス権を付与する。

2: ウェブサーバから、オブジェクトへの一時アクセス権付きの署名済み URL を返す。

3: IAM ポリシーでオブジェクトへのアクセス権を付与する。

4: ユーザのブラウザーに配信するために S3 からオブジェクトを読み出すウェブサーバコードを作成する

 

解答
2

 

解説

1: 公開ユーザは IAM ユーザを持っていない。IAM AWS インフラストラクチャを保護するが、アプリケーショは保護しない。

3: アプリケーションユーザは AWS アカウントを持っていない。

4: ウェブサーバーコードというのは、起動したウェブサーバー経友でアクセスするということ。これでも実現できないことはないが、
EC2インスタンス経友で起動するというステップが増えている。またEC2は帯域幅が小さいので遅くなる。またEC2も起動しているので、コストもかかる。



分野4:一般的なトラブルシューティングの情報および質問に関する問題

  • EC2インスタンスの接続
    • ec2にsshできないなどの問題
    • ec2が起動しないなどの問題
  • EC2 インスタンス、EBS ボリューム回復
  • AWS サービス制限の問題

「接続のトラブルシューティング」

ゲートウェイがアタッチされているか。

IGW VGW など、ゲートウェイの種類を把握しよう。

ルートテーブルをきちんと設定しないといけない

ポートに設定できるか問題:これはSGなどの設定などを把握しよう。

 

接続できないのにはいくつかの原因が考えられる。

VPC の外部から VPC 内のインスタンスまで:

  • アタッチされた GW IGW または VGW
  • 企業ネットワークから VPC までのルーティングルール
  • VPC またはサブネットのルートテーブル
  • インスタンスの EIP または パブリックIP
  • NACL
  • SG
  • OS レベルのファイアウォール

問題になるのは、あるケースで EC2 に接続できないという状況です

4つのポイントがあります。

  1.  IGW
  2. SG, NACL
  3. EIPが関連づけられているか
  4. ネットワーク経路の話
    → public サブネットのルートテーブルに、IGWが設定されていることが必要。

「インスタンス/EBS ボリューム回復のトラブルシューティング」

  • EC2 インスタンスが応答しなくなることがある
    ex. 例えば、Linux のカーネルパラメータに変な値を設定してしまったとか
    アタッチしているEBSボリュームはデタッチできる
    → 必要なら強制的にでタッチ
  • EBS ボリュームを正常なインスタンスに再アタッチする。
  • 以下のプロセスを実行して非稼動ブートボリュームを回復する。
    • ボリュームをでタッチ
    • データボリュームとしてアタッチ
    • ファイル内の問題を解決
    • 元のインスタンスに再アタッチして、再起動

「制限問題のトラブルシューティング」

AWS には様々なソフトリミットがあある。

また、いくつかのハードリミットもある

制限は相互に影響を及ぼすことがある

  • EBS の制限に達したために、 EC2 インスタンスを起動できないことがある。
  • Trusted Adviser が役立つ

一般的な制限は次の通り(基本的には全てリージョンごと)

  • アカウントごとのインスタンス数は 20 まで
    (インスタンスタイプによってはさらに少ない場合がある)
  • リージョンごとの EIP 5 まで
  • VPC ごとの SG の数は 500 まで
  • LB 20 まで
  • Auto Scaling グループは 20 まで
  • EBS: 5,000 ボリューム、10,000 スナップショット、40,000 IOSP20 TBのストレージ
  • S3 のバケット数は 100 まで。
  • ネットワークの帯域幅
  • etc…

 

問題を解く際に、制限のないようを記憶する必要はない。

  • 制限があることと、その制限によって生じる問題について注意が必要
  • 制限の引き上げを要求する方法について把握する。
    → ソフトリミットは、設定により変更できることがある。

 

練習問題

EBS-Backed EC2 インスタンスに障害が発生し、応答しなくなりました。
ルートボリュームに重要情報が入っているために復旧する必要がありますが、
あらゆる手段を試みてもインスタンスにログインできません。
元の AMI にはアクセスできますが、ルートボリュームの最新のバックアップが利用できません。
どうすればボリューム内の情報を復旧できますか?

 

解答
4

 

解説

1: デフォルトの設定では、インスタンスの削除と同時に、ルートボリュームも削除されてしまう。

設定でそうならないこともできるが、この問題ではそれが書いていないので、消えてしまう。

2: スナップショットからインスタンスは起動できない。起動は AMI からのみ可能。

3: 元の AMI には障害が発生したデータと同じデータは存在せず、同一データではないため間違い。

 

練習問題

VPC パブリックサブネットにアプリケーションをデプロイしました。
複数の同じ EC2 アプリケーションインスタンスが正常に稼動し、
インターネット経由でアクセスできます。
ここで、同じ AMI および SG を使用して、同じサブネットに新たな EC2 インスタンスを起動し、
アプリケーションをスケールすることにしました。
ところが、新しいインスタンスにはインターネットからアクセスできないことが分かりました。
どこに変更すれば、新しいインスタンスにインターネットからアクセスできるようになりますか?

 

選択肢

1: パブリックサブネット内にNATインスタンスをデプロイする。

2: 新しいインスタンスのゲスト OS に、パブリックIPアドレスを設定する。

3: EIP を新しいインスタンスに割り当てる。

4: サブネットのルートテーブルを、新しいインスタンスへのアクセスを許可するように変更する。

 

解答
3

 

解説

1: パブリックサブネット内のインスタンスが NAT インスタンスを使う必要はない。
windowファイアウォールがRDPをブロックすることはあるが、この場合、AMI から作られれているので、許可されているはず。
パブリックサブネット内のインスタンスは、EIPによって接続ができる。

2: ルーティングルールによって、ポートのトラフィックまでは制限できない。
ホスト OS が知っているのはプライベートIPのみ。パブリックIPOSが知らない情報。

4: ルートテーブルはサブネット全体に適用され、サブネット内の他のインスタンスは正常。
また、デフォルトでは全て許可されている。
ルートテーブルの問題ではないことが、問題文からわかる。

この問題のポイントは
SGは、デフォルトでは、全てのインバウンドは許可されていないということ
なので、つなげたかったら許可しないといけないということ。



まとめと今後について

実際に触って実務経験があることが重要。

試験の準備

詳細

https://aws.amazon.com/jp/certification/certified-solutions-architect-associate/

トレーニング

  • セルフペースラボ
    https://aws.amazon.com/jp/training/self-paced-labs/

コース
https://aws.amazon.com/jp/training/course-descriptions/

参考資料

  • ホワイトペーパー
    https://aws.amazon.com/jp/whitepapers/
  • アーキテクチャセンター
    https://aws.amazon.com/jp/architecture/
  • ドキュメント
    https://aws.amazon.com/jp/documentation/

試験ガイド
https://d1.awsstatic.com/training-and-certification/docs-sa-assoc/AWS%20Certified%20Solutions%20Architect%20-%20Associate_Exam%20Guide_v1.5_FINALJP.pdf

サンプル試験
https://d1.awsstatic.com/training-and-certification/docs-sa-assoc/AWS%20Certified%20Solutions%20Architect%20-%20Associate_Exam%20Sample_v1.5_FINALJP.pdf

模擬試験
https://aws.amazon.com/jp/training/

個々のサービスを詳しく学びたい場合

  • AWSクラウドサービス活用資料集
    https://aws.amazon.com/jp/aws-jp-introduction/

試験の登録
https://aws.amazon.com/jp/training/

認定FAQ
https://aws.amazon.com/jp/certification/faqs/

Androidエンジニア デザイン部 #2に行ってきました

Androidエンジニア デザイン部 #2

https://nohana.connpass.com/event/94621/

に行ってきたので、そのときのレポートブログ

LT1つ目:InvisionのAndroidアプリでみる4つのデザイン基本原則

エウレカのFutagawaさん

資料

以下、LTを聴きながらのメモ

今日話す内容

  • Invisionとは
  • 4つのデザイン原則とは

Invisionとは

モックでデザインを簡単に作れるやつ

4つの原則とは

  • Proximity:近接
  • Repetition:反復
  • Alignment:整列
  • Contrast:コントラスト

Proximity:近接」

グループ化した要素は近くに、そうじゃない要素はより遠くに

まとまりある要素同士の距離は、まとまりのない要素同士の距離よりも短くする。

Alignment:整列」

画面内の全ての要素が他の要素と視覚的なつながりをもつようにする。

Repetition:反復」

アプリの全体を通してなにかの特徴を繰り返す。

「Contrast:コントラスト」

同じ要素でないものははっきりと異ならせる。

例えば、タイトルとアップデート時間は全くことなるものなので

文字の濃さを変えたりする。

 

ノンデザイナーズ・デザインブック

https://book.mynavi.jp/ec/products/detail/id=22176

非デザイナーでも読みやすい。

たまにPDFを配ってるときとかもある。



LT2つ目:「ありがたいUI」をもっと大事にしたい。

資料

以下、LTを聴きながらのメモ

 

デザインに対する持論

デザインって広義的な意味でいっぱいあるが

大切にしたいと思っていることがある。

デザインって、かっこいいとか美しいとかクールと思われがちだ。

かっこいいからインストールするとか、そういう訴求力もあるが

かっこいいから使い続けてるとかはあまりない。

使い続ける理由としてかっこいいからというのはあまりない。

※ただし、アイコンは除く

 

ありがたいと思えるアプリ

twitterの画像表示がありがたい。

複数枚あるとスライドできるが、

消したいときは、下から上にスワイプする。

これの嬉しいところが、タイムラインを眺める動作と変わりない動作でできる。

これがもし、画面上のほうに×ボタンとかで閉じる UI だったら、少し手間になる。

CamScannerの画像切り抜き

タップ部分が拡大表示される。細かく調整ができる。

座標の調整が確認しやすい。

マルチウィンドウ対応アプリ

例えばyoutubeをバックグラウンド再生できる。

AbemaTVのCM中にtwitterみるとか、そういうことができる。

 

これらのアプリにある機能がありがたいので

他のアプリに乗り換えられない。

クールとか美しいアプリというのも大切だが、

ありがたいUIも大切。



LT3つ目:Google I/O 2018

Googleの方のLT

自社アプリ、IOSched について。

 

IOSchedは、

Androidアプリを作っている人に、リファレンスとして見てもらえるように作られている。

 

2018年の見所

  • 秘伝のたれのソースコードをフルスクラッチ
  • Kotlin
  • Architecture Component

UIの面でもベストプラクティスをやろうとしている。

マテリアルデザインで出したい。

だが、I/Oがあるまではマテリアルデザインで出せない。というジレンマがあった。

なので、デザインを2つ作った。

 

今年の見所

Lottieというアニメーションのライブラリを使っている。

カウントダウンを実装している。

githubにソースコード公開しているので、DLしてぜひ見て見てね。

 

ナビゲーション

去年まではナビゲーションペインで作っていたのだが

ナビゲーションボトムに切り替えた。

view pager

1つのviewはマテリアルデザインでいうところの1つの要素

なので、viewとviewの間には区切りが欲しい。

いろんなアプリはその区切りを入れてないので、入れることによりくっきり見える。

ボトムアップバー

これもライブラリの中に入っている。

ここはアクションのメニューを並べる。

fabが据えられる位置を決められる。

たとえばGmailみたいなアプリで、詳細画面に行ったときは返信するボタンになるとかで、

返信ボタンは左に出したいとかだったら、アニメーションを使う。

スナックバー

これまではfabを押し上げるような形だったが、

fabの上に出しましょうとしている。

ボトムシート

一時的な状態を出すのにすごくいい。

必須要素をぜひ知っていただきたい。

 

Googleのアプリをだすときにクリアしなければいけないこと

  • タッチフィードバック
  • 色のコントラスト。背景と文字のコントラストが十分かどうか?
    accesibility checkerというアプリで、チェックできる。
  • 色だけで情報を表さない。必ず文字も入れる。色弱の人がわからないので。
  • 前の画面ってなんだっけ?とならないようにアニメーションをつけるようにする。
  • talkbackでの動作


LT4つ目:Kyashはなぜ使いやすいのか

ノハナの方のLT

資料

以下、LTを聞きながらのメモ

 

今回のアンケート(connpassの参加フォームで「UIが好きなアプリは?」という質問があった)でも、

Kyashが一番評価がよかった。

1. シンプル

Navigation Drawerがない。

  • 機能が絞れている。
    我々は、多機能にしがちだが、Kyashは機能が絞られててよい。
  • 階層が浅い
    画面スタックが最大でも3階層
    人間は画面について覚えにくいが、3階層しかないので覚えやすい。
  • 画面内の要素が多くない

これらのこと = アプリで迷子になりにくい。

2. 操作感のあるUI

請求画面と送金画面が大体似ているが、

画面の下の操作が少し違う。

 

画面遷移

下から出てきて、前の画面が消えるようになっている。

横スライドで画面が変わったりもする。

画面の連続性を出すためにいい。

3. こだわり

39円を送ると、thank you というアニメーションが出る。

一見意味ないことのように思える(これでユーザ数が増えるとか思えない)が、こだわりがあってよい。

ギフトコードの画面についても、細かいアニメーション(プレゼントボックスがカタカタ動く)がある。

これも意味ないと思うが、こういったこだわりのアニメーションを実装したりすることで、

ファンが楽しくなって、ファンが増えていく。



以下、懇親会で周りの人と喋ってて知ったこと

  • https://material.io
    マテリアルデザインについて書かれている。
  • なるほどデザイン
    初心者向けのデザインの本。読みやすい
    https://www.amazon.co.jp/dp/B012VJNW6Q/
  • Xamarin
    Android, iOSアプリどちらも一度に作れる
  • Human Interface Guidelines
    iOSアプリを作るときのデザインのガイドライン

「割り勘オンライン」をリリースしました

趣味で作っているAndroidアプリ

「割り勘オンライン」を728日にGoogle Playで公開しました。

https://play.google.com/store/apps/details?id=com.jp.acchan.groupdutch

 

「割り勘オンライン」は

立て替えが何度か発生する関係の人との間で役にたちます。

領収証をとっておく必要がなく、

何をいくら立て替えたのかをスマホで共有することができます。

 

また誰がいくら多く払っているのかを

ボタン1つで計算することができます。

こんなときに使ってほしい

友達と旅行中に立て替えが発生するとき

旅行をしていて、

「今回ガソリン代払っとくよ~」とか

「今回レンタカー代払っとくよ~」と、立て替えをして

旅行が終わってから精算。ということがないでしょうか。

 

そんなときに、「割り勘オンライン」を使えば

誰が何を支払ったのかのメモをアプリで共有することができます。

 

また、立て替えた結果、誰がいくら多く払っているのかを

すぐに計算することができます。

恋人とお財布を分けてて、きっちり精算したいとき

私自身がそうだったのですが、

恋人と例えば

「今日スーパーで買い物してきたよ」とか

「コンビニまとめて払っておくね」とかしているけど

きっちり精算したい人はいませんか?

 

1ヶ月分のレシートを残しておいて

1でレシートを計算して精算、ということは面倒ですが、

「割り勘オンライン」があれば、レシートを取っておく必要も

電卓で計算する必要もありません。

 

まだリリースしたばかりで
至らない点が多いと思いますが、
気になった点や改善点があればレビューに書き込んでいただけると
幸いです。

【食事&景品付き】エンジニアの為の合コン(エジコン)に行ってきました。

【食事&景品付き】エンジニアの為の合コン(エジコン)

https://engineer-quality-life.connpass.com/event/93073/

に行ってきたので、そのときのレポート

エンジニアトークしていい前提なので話しやすい

日頃僕はエンジニア以外の方と話すときは

エンジニアの話題をしても話が広がらないので

頑張って他の趣味の話をするのですが、

技術の話のほうがいろいろ話せたり興味があります。

 

エンジニアトークしていい前提なので

自己紹介のときから「どんな言語・技術を触ってます」と言えるので

エンジニアな話ができてとてもよかったです。

 

また、これは偶然だったのかもですが、

私のテーブルには

  • Webのサーバーサイド
  • Webのフロントエンド
  • インフラ
  • 組み込み系

の人がいて、いろんな話が聞けて楽しかったです。

運営の方がいろいろしてくれている

現地に着いてから聞いた話だったのですが、

もともと用意していた会場が使えなくなり、急遽新しい会場で開催してくれたとのことでした。

少しバタついてしまっていましたが

急な対応をしてくれた運営の方には感謝です。

 

また、歓談の途中に、みんなで行うエンジニアクイズを企画してくれていました。

httpの意味は?」という問題だったり

「フォン・ノイマンがコンピュータを作ったときに言った言葉は?」

というちょっとトリビア的な問題だったりして

みんなで盛り上がってクイズ大会ができました。

 

またクイズに正解すると景品ももらえました。

偶然私が正解したクイズの景品が、映画のギフトカードだったのですが、

それを口実に女性に「一緒に行きましょう」と誘うことができました。

誘う口実になる景品を考えてくれた運営の方には感謝です。

まとめ

とても楽しかったです。

 

あまり合コンという意識をせずに

単純に集まった人で歓談を楽しむような雰囲気だったので

私も緊張せずに楽しむことができました。

 

ただ、connpassの予定では女性は6名の参加だったのですが、

当日になると欠席が多く、実際に集まってくれたのは2名でした。

 

このあたりは、運営の方が次回にむけて改善していきたいとおっしゃっていました。

 

あと強いて言うなら

僕がいないほうのテーブル(入り口から遠い方)のテーブルで

運営の方が喋りすぎてなかったかなとちょっと心配になりました。

参加者同士の会話よりも、運営の方の話を参加者が聞いているような時間がながく思えたので、

そこだけちょっと心配でした。

 

エンジニアはやっぱりエンジニアトークで盛り上がりやすいので

それができる人で集まる合コンはいいものですね!

ソフトスキル4章まとめ

まず始めに、私達は人との良い接し方をとらないといけないということを認識しよう

私達はコードのために働いているわけではなく、人のために働いている

私達は一日中コードを書いていたいと思うかもしれない

人との調整ごとなどできればしたくないと思うかもしれない

 

だが、そこについては一度考えなおしてみるとよい

私達が書くコードは、コンピュータから「この実装をしてくれ」と言われて書くものだろうか。

 

いや、違う。

人から「こういうことを実現したい」と言われてコードを書くのだ

コードに落としこむ内容を決めるために会議に出るし、ビジネス的な戦略を練ったりするだろう

 

このように、私達がコードを書く理由は人からきているのだ

自分の仕事はコードを書くことだと思い込むのではなく、

他の職種同様、人と接する職種だと認識しなくてはならない

このことから、私達は人との良い接し方をとらなければならない

人との接し方を学ぼう

「大切にされている」と誰もが感じたい。

人と接するときに最も重要にしたいことは、相手がどうされたいかを意識することだ。

 

では、相手はどうされたいか?

要望はいくらでもあるだろうが、最も根本的な要望は「大切にされたい」ということである。

この最も根本的な要望を常におさえたまま、人とは接しなければならない。

 

仮に、人を見くびったり、存在を否定するような接し方をしてしまった場合、

相手は自分に対して反抗的な姿勢になってしまうことを肝に銘じよう。

決して批判してはならない

人は大切にされたいという心理が理解できると、

批判が目的の結果を生み出さないことも理解できるだろう。

 

また、良い行動を褒めるほうが、悪い行動を懲らしめるよりはるかに効果的だということは、

数々の研究成果で示されている。

 

リーダーである人なら、メンバーにベストを出させたいときには、

余計なことは言わずに褒める言葉を繰り返すのがよい。

 

一つ例を出すと、あなたのこれまでの上司で、

失敗に対して叱責を繰り返す人がいたら、そのときのことを思い出してほしい。

叱責されて、やる気が出ただろうか、モチベーションが上がっただろうか。

多くの人は、あなたと同じようにモチベーションはあがらない。

他人の立場になって他人主体で考えよう

相手の立場になって物事を考えたり、話し方を変えるようにしよう。

そうすることで、相手のことを軽んじたりしたり批判したりすることを避けることができる

 

相手の立場になるうえで重要なことが、相手が何を望んでいるか、

何を大切にしているかを把握することだ。

自分が話をする番になっても、相手の立場になって、相手中心の話題になるようにしよう。

 

例えば

ある機能をある特定の条件で実装したいとなった場合、それをそのまま上司につつえるよりも、

その実装をすることで相手(上司)にどんないいことがあるのかを伝えるほうが、

承認をもらえる可能性がグッと高くなる。

議論は避けなければならない

ソフトウェア開発者の我々は、論理的な議論によって最適な解を得られると思っている。

 

しかし、それは間違いだ

議論する人は、思ったほど論理的になれない。

 

見た目は大人であっても、時には感情を剥き出しにするし、何か反論されたときなどには感情的な意見を言ってしまったりする

そういった理由で、議論によって最適な解を導き出せるわけではないので、避けなければならない。

 

泣き叫ぶ子供に正しいことを論じても通じないように、

あなたに冷たくされて人は、あなたの言うことに賛同しないだろう。

 

何かのやり方について賛同できないとき、特にそれに人が関わっているときは

命をかけてまで反対するべきかどうかを考えよう。

自分の意見を諦め、相手の意見を尊重した実績を積み上げれば

いずれ相手は自分の意見に耳を傾けてくれるかもしれない。

 

社交術のために時間を使ったことがなければ、いますぐ始めたほうがいい。

そうすれば自分の人生がもっと楽しくなり、それは値段がつけられないほど価値のあるものだ。

「毒」のある人の扱い方。

他人を蹴落とすことばかり考えていたり、自分を犠牲にして悪いことを集めたりする人はいるものだ。

そういう人に出くわしたら、できる限り早く距離をとったり、逃げ出したりしよう。

それが最善だ。

もし、どうしてもその人と関わらなければならない場合の選択肢は

  • 相手のご機嫌をとる
  • 異動を検討する
  • 感情的にならないように最小限の範囲で接する

ことだ。

【集まれKotlin好き!Kotlin愛好会 vol2】に行ってきました

集まれKotlin好き!Kotlin愛好会 vol2

https://love-kotlin.connpass.com/event/91710/

に行ってきたので、その時のレポート

談義: 「JavaからKotlinにコンバートする際にj2kコンバータをカスタマイズした話」by paraya3636さん

資料

以下、談義を聞きながらのメモ

Java から Kotlin に変換する際に苦労した点

通常、Android Studio で変換すると思う。このとき、j2k コンバータが使われている。

ただ、この j2k コンバータは問題がある。

それは、強制的にnon null 変換されること

これを調べてみると、

引数や戻りの型に non null のアノテーションがついてないと、

nulableな変換にしてくれない。

そのため、そのまま実行するとクラッシュしてしまう。

解決案1

目視で全部チェックする

解決案2

Kotlin 化して全部テストする

ただ、この2つの案だと、やる際に手作業で辛すぎる。

さらに考えて、

コンバータを改造すればいいのではないかと考えた。

Java から Kotlin に変換するツール「j2kコンバータ」をカスタマイズした話

ステップ

  1. Kotlin を build する環境を整える
  2. typeConverter.ktを編集
  3. チャイルド IDEA を実行
  4. コードをコンパイルする。

Kotlin の build 環境は長くなるので割愛。

資料のURLとかをみてね!

カスタムコンバータの使い心地は?

クラッシュの確率が激減した。

信頼感がupして、レビューを簡素にすることができた。



談義: 「Java で書かれた Android アプリを Kotlin で書き直すまでの話」by Ryutaro Miyashitaさん

資料

以下、談義を聞きながらのレポート

書き直す際に

最初は部分的に使えるところで使っていこうという形だった。

次に、既存の画面を書き換えてみた。

次に、新しい機能追加の際には Kotlin を使い始めた。

チーム内に Kotlin が浸透してきた。

Javaとつなぎこみたいときどうすればいいの?

Javaとの共存はもちろんできるが、このコードは Java から呼ぶとか Kotlin から呼ぶとか意識づけが必要。

Kotlin 側に、Java からアクセスさせるためにアノテーションをつけてあげたりする。

ここは Java からアクセスするんだねっていうのを意識する必要がない。

Java には Unit 型はないので、 Java 側に Unit を返すような実装をしなければいけない。

このように、Java 側に Kotlin の都合が侵食していったりする。

Kotlin の旨味を100%引き出したいとなると

Java と Kotlin がお互いに都合をお互いに考えなければいけなくなる。

いっそのこと、Kotlin に書き換えたほうがいいのでは?となり、

ただ、Kotlin の習熟度レベルはバラバラ。

なので、レビューをしたり、チャットでクイズを出したり、説明したりして、

理解を深めて行った。

結果、5.3万行くらいあった、コードが4.3万行くらいになった。

手作業でやりきったのはいい思い出。

10ヶ月で全部 Kotlin 化した。

その間に機能追加やリファクタリングもできた。

効果

可読性はあがった。

Null Pointer Exception の撲滅。ほぼ出会っていない。

最後に

既存のアプリも段階的に Kotlin 化して行けた。

中途半端に導入するぐらいであれば、全てを書き換えたい。

 → Java と Kotlin 間でそれぞれを意識する手間を省けた

他チームから見た、想定外の効果

 → iOS エンジニアや Scala のエンジニアが Kotlin のコードを読んで交流が生まれるようになった。



談義: 「低レベルな Kotolin 」by tomoya0x00さん

資料

以下、談義を聞きながらのメモ

Kotolin のbyte型の話。

符号なしで処理をしたいことがある。

kotlin の byte 型に 0x80 を突っ込むと

-128になってしまう。

そこで、

符号なしとして扱ったときの最大値が十分に表現できる型に変換する。

そして、マスクをする。

やり方は、

toInt()して、0xffでandをとる。

チェックサムの話

2の補数表現を考慮して実装をする。



談義: 「webエンジニアが 2ヶ月Kotlin(Android)開発して思ったこと」by achanさん

私の談義です。

資料

以下、概要

日頃はサーバーサイドを触っている

  • サーバーサイド
  • インフラ
  • Kotlin(Android)

ができると、一人でオンラインアプリが作れるようになる。

webもできてアプリもできるって人は少ないように感じる。

webの現場で「それ、アプリでできますよ」って言えるようになりたい。

Kotlin楽しい

これから始める人はぜひ実機デバッグで欲しい。

動いたときの感動がある。

型に厳密な言語は楽しい

IDEが叱ってくれる

型を書くのは頭の整理になる。

webだといろいろ複雑な要素が多いし、環境が違うこともあるが

Kotlinだと、同じ問題に当たっている人が同じ解決策で乗り切れることが多い。

Kotlinの世界を見て思ったこと

  • viewとロジックの分離が難しい
  • クライアントにインストールされている古いバージョンへの対応
  • 端末依存問題

まとめ

サーバーサイドを日頃触っているが、

Kotlinを触って新しい世界に触れるのは良い。



談義: Property Getterby scacheさん

資料



談義: 「完全に理解した気になる Kotlin Coroutines」by takahiromさん

資料

apiが多いが、基本的なところから理解したい。

coroutinesはスレッドの上で動く、動きは確認できる。

中断もできる。



談義: 「KotlinJs でも Coroutines」by Ryo Sakaguchiさん

資料

react wigh kotlinのインストールは簡単

npm で数コマンドたたくだけでできる!

【Kotlin Developers Meetup】に行ってきました

Kotlin Developers Meetup

https://kotlin.connpass.com/event/90679/

に行ってきたので、そのときのレポート

Creating DSLs in Kotlin

JetBrains社のHadi Hariri氏にKotlinについて講演してもらいました。

ただ、英語での講演だったので、全然聞き取れませんでした。。。


LT

LT1: FSM DSL in Kotlin

資料

https://speakerdeck.com/tomoya0x00/fsm-dsl-in-kotlin

Kotlinでtree探索をしようとした話。

私が不慣れなのと、内容の難易度が高くてついて行けませんでした。。。


LT2: Readable Code in Kotlin

資料

https://speakerdeck.com/kaonash/readable-code-in-kotlin

以下、LTを聴きながらのメモ

 

リーダブルコードの中で

「コードは理解しやすくなければならない」と書かれている。

 

理解しやすいコードは

簡潔なコードというわけではない。

短いコードは一見かっこいいかもしれないが、

理解がしずらい点もある。

 

どうやれば理解しやすいコードがかけるか?

1.  nullableのハンドリング

できるだけ早くスマートキャストをしてあげて、

nullなのかそうでないのかという状態を明示するようにする。

2. 型推論にあまりたよりすぎない。

型推論は便利。

ただ、あまり頼りすぎると、

この変数の型はなんなんだと分からなくなってしまう。

 

変数の型を確かめるために、コードをたくさん追わないと行けない。

だから、型推論できる場所でも型を書くようにしましょう。

ではどんなときに型を書くのか?

変数名で型を推測できるときは書かなくてもよいが、

そうでないときは書いたほうがいい。

 

また、letについてみんながどう思っているのかを知りたい。

letはわかりにくいので

runmapというネーミングに変えてあげたほうが

英語が苦手な見としては、わかりやすい。


LT3: multiplatform kotlin?

資料

https://speakerdeck.com/panini/kotlin-multiplatform

以下、LTを聴きながらのメモ

 

登壇者のPaniniさんはKotlinエンジニアなのだが

React Nativeも最近書いている。

React Nativeの良い点としては、

ファイルをセーブしたら、そのまま実行してくれるので便利。

 

ただ、jsよりもkotlin書きたい。。。。

そんなときに

Kotlin.js

という、kotlinをjsに変換してくれる神と出会った。

 

Kotlin を React Nativeで書くためには、

一行、ライブラリをimportする文を書くだけでできる。便利。

 

Hot Reload

jsはコンパイルされないから、すぐに実行できる。

Kotlinでもできないのかな?と思って調べたら、

gradle continuous build

という神の機能がある。

これを使ったら、ファイルの変化を検知してHot Reloadしてくれる。

コンパイルを挟むので少し時間がかかるけど、早いので良い。


LT4:spring fu on graalVM

以下、LTを聴きながらのメモ

 

登壇者の型は、Kotlin イン アクションとか、あかべこ本を書いた方。

graalVM

というのがある。

jvm言語はもちろん、それ以外の言語もこれの上で走る。

AOT compile

Javaや通常、実行時にバイトコードがマシンコードになるが、

これを使うことで、直接バイナリを得ることができる。

ただ、これはlinuxでしか動かない。

なので、macの上で docker  とか使って動かそう。

spring boot も動かせるよ!

ただ、jarファイルを食わせたら、エラーになってしまう。。。

ここで登場するのが

Spring Fu

kotlinでかけるよ!

これをgradlewで動かすと、もちろん動く。

そして、、、jarファイルを食わせると、、、同じようなエラーになってしまう。。。

告知!

kotolin fes 2018やるよ!

品川でやるよ!みんなきてね!


LT5: create minicraft mod with kotlin

以下、 LTを聴きながらのメモ

(英語でのLTだったので、メモが間違っている部分があるかもです。。)

 

登壇者の方は、Y.A.M の 雑記帳を書いている人。(いつもお世話になってます!!)

mine craft をやっているよ。

登壇者の方の息子さんもmine craftをやっているよ。私のPCでね!笑

mine craft modというものがあるよ

modというのは

オブジェクトのようなもので、

ブロックを追加したり、人のステータスを変更できたりするよ

forgeというもので、modカスタマイズできるよ。

modはInteljとgradleで作れるよ!

そしてjavaを使うんだけど、

今回kotlinでやってみたよ!

今回のゴールは私の息子がmodを作ることだ

ただ、

・子供がタイピングしたりエラーを解消したりいろんなファイルを触ったりするのはとても難しい

・重要なのは、早く、遊びながら作れること

結果として

modは子供がプログラミングに興味を持つのにいいきっかけになった。

そして、早くmodを作ることにも成功した!


Q & A

Hadi Hariri氏に直接質問をできるQ & Aが用意されました。

ただ、質問と回答が英語だったので聞き取れず。。。

英語勉強しよう。

【UIT#3 The “Backends for Frontends” sharing】に行ってきました

UIT#3 The “Backends for Frontends” sharing

https://uit.connpass.com/event/88434/

に行ってきたので、そのときのレポート

「マイクロサービスの思想から捉える、Backends for Frontendsとその類似パターン」 qsona (株式会社FiNC)

資料

以下、講演を聴きながらのメモ

BFFとは」「その位置付けと目的」

backend for frontendという言葉は少し混乱がある。

server for frontendという言葉のほうが実態に近いように思う。

複数のAPIを合成したりする位置付け

UI側でのABテストなどをする

BFFとマイクロサービスの関係性

マイクロサービスとは、協調して動作する、小規模な自律型のサービス

FINCアプリの場合は、各プロダクトが様々な機能を内包している。

機能の11個、それが単体でも事業になりそうなものが

FINCアプリの中にある。

それらを別々のマイクロサービスとして扱っている。

 

様々なクライアントと様々なサーバーがある。

それらを直接組み合わせると、

APIのコール数が増えるなどの問題がある。

 

その解決策として、中間に1つサーバーを挟む。

それを API Gateway として扱っている。

 

このAPI Gateway には独自のロジックは持たせたくない。

ロジックを持つと、マイクロサービスの旨味が減ってしまう。

注意点

バックエンドロジックをAPI Gateway にもりもりしてしまうと

辛くなる。

宣伝

Microservices architectureよろず本というのを書いたので、読んでね!

類似パターン

クライアントとBFF層のやりとりはgRPCにして

BFF層kotlinで書く。

iOS と Android は基本的に同じ構成をしている。

画面遷移など。

デザインによる違いなどの吸収はクライアント側で行う。

gRPCにした理由は

RPCにしたかったから。

レストフルは避けたい。

クライアントの要求に答える形なので、RPCとしたかった。

Kotlinの理由

既にいる Kotlin エンジニアのコストが減る。

並列処理として go や node.js を使おうかという考えもあったが、

コルーチンでギリギリ行けそうなので Kotlin



「FOLIOのBFFと秩序の話」 Quramy (株式会社FOLIO)

以下、講演を聴きながらのメモ

「FOLIOのBFFと秩序の話」 Quramy (株式会社FOLIO)

今日話すこと

FOLIO の BFF の自慢話

こんな失敗したのでみんなしないでねという話。

イントロ:サービス紹介、システム構成

MobileAPP と Web で大きく BFF を分けている。

モバイルアプリの iOS とAndroid へ提供している API は同じもので

デザインによる違いはクライアントで吸収させている。

BFF のお仕事

下流サービスの集約

Web の BFF は SSR(サーバサイドレンダリング)も行なっている

Aパート:良い話(うまくいった自慢話)

まずアーキテクチャはどんなのを採用しているか?

クリーンアーキテクチャ風

なぜこんな風にしているか?

BFF はクライアントやマイクロサービスに挟まれているので

クリーンアーキテクチャが親和性が高いと思ったから。

主な目的は型付け。

Json でやりとりをしていて、 Node.js を採用しているので、

型をつけたかった。

リクエストやレスポンス整形で誤っていればコンパイルエラーになるようにしている。

BFF の思想を決めておく

やるべきこと、やらないことを決めておく。

日付の計算やパースフォーマット、数値項目の加算原産など

チームでこれらのことに合意をとって進めて行くと良い。

Bパート:辛かった話(失敗した話)

Web の BFF と Mobile の BFF は作られた時期が全然違う。

Webのほうが古くて、それでつらかった部分を考慮して Mobile が作られている。

悲劇の紹介

ユーザーがみるダッシュボード的な画面。

ログインした次の画面、マイページ的な。

これが辛い。

薄いコントローラと巨大なロジック層によって

巨大な Json を返す。

React を採用しているので、クライアントで Json を処理する。

辛い部分として、

巨大なロジック層の部分が 1800 行とかある。

また、型も Any にしている。

型がついてないし、巨大なので触りたくない状態。

だが、旧来のMVCの形をしているので、ある意味わかりやすい部分はある。

直近の対処

改修をする際には、なるべく型付けを少しづつしていってリファクタリングをしている。

もう少し先の対応としては、

React コンポーネントが必要な Json を取りに行くという

画面側が必要な部分だけ取りに行く。next.jsのような思想を目指している。

おさらい

秩序をもたらすためには、

  • レイヤを意識しよう
  • ユースケースを意識しよう
  • スキーマ + 型を使おう


「merpay Frontend における BFF」 @1000ch (株式会社メルペイ)

資料

https://docs.google.com/presentation/d/1RY2qCIypDBju2LfVhBfBnBaaVN_SFM_KAz7-WVucl90/edit#slide=id.p

以下、講演を聴きながらのレポート

 

BFF のことを調べていたら

「使う側にとって、良い設計になっているバックエンド」

という文献に当たった。

最初は、API をまとめるための API サーバーという認識だったが、

複数の API サーバーにリクエストして、htmlを生成するサーバーも BFF と呼ぶ。

と、古川さん(Node.js会長の)が言っていた。

backend for frontendsという言葉なので、捉え方によってはなんとでもなりそう。

広義の意味では SSR Server を BFF と行ったり、

API をまとめる APIサーバーを backend for BFF という捉え方もできる。

node.js が API をまとめるようにしたくなかった。

isomorphoic app を動かすようにしたかった。

フロントエンドの人が js を触っているので、

その人たちもメンテナンスができる。

backend for bff がやっていること

API Gatewayとして動作させている。

httpリクエストを gRPC に変化して横流しする。

将来的にはアグリゲーションさせるかもしれない。



「なぜBFFを導入しなかったのか」 Kento Moriwaki (Wantedly, inc)

資料

Bffを導入しなかった理由(僕らにはまだ早かった)

以下、講演を聴きながらのメモ

システム構成

railsの一枚岩だけど Micro Service 化を進めている。

バックエンドとフロントエンドの責務を分けて行きたいと思って、

BFF の登場だ!ということを考えた。

課題

グローバルヘッダーやフッターは全ページ共通

ただ、SSR 化したかったのは、ヘッダーやフッターを除いて中のコンテンツを SSR したかった。

共通パーツ問題を解決するために考えたこと

  1. reactバージョンを作る?
    rails jqueryで2重管理になってしまう
  2. 全部react実装に統一する?
    Angularもいれていたので、Angular と React を2重管理させるのはカオスになりそうだった。

課題:インフラの問題

どうやってデプロイするか?

切り替わりの間で何か障害が起こったときのインパクトがでかすぎる。

また、画面を少しづつ移行させたいという要望もあった。

 

これらの課題を解決するに至らず、BFF は挫折した。

今後は

これらの要件を満たしつつ、最小限の工数で。

BFF は目的じゃなくて手段の一つ。

もともと作っていた Restful API でやってきたこと

model を json に変換するところを共通化していた。

複雑な処理もあるが、小さい Service 単位に切り出していた。

これらのことのように、Controller を薄くしておいたおかげで

さまざまな部分を共通化できた。

今後もし BFF に対応したかったら、

  • 対応する API を叩くように書き換えるだけ
  • BFF で直接 Render することも可能。

まとめ

SSR したいだけなら、BFF は必須じゃない

ただ、BFF のメリットはすごくあるので

1つ1つ疎結合にしていって、一歩ずつやっていこうと思う。



「LINEとBFFの話」 Jun (LINE株式会社)

資料

以下講演を聴きながらのメモ

LINEは、

  • サーバの人が多い
  • サーバは Java, Perl
  • サーバーサイドテンプレート
  • SPA でもindex.htmlはサーバーに置いてある

BFF というものは

フロントエンドとか技術だけの話だけではないと思う。

BFF の導入は慣れているプロセスを破壊するものなのか?

破壊は改善です!というのも、エンジニア以外から「本当に?」と思われてしまう。

BFF というのは、組織と責任が伴う。

 

BFF がなかったら、テンプレートがサーバーにあるため、責任が不明確。

例えば、画面の問題があって、テンプレートはサーバーにあるため

サーバーのエンジニアが見る

からの、「これはテンプレートの問題ですね」

となって、フロントエンドエンジニアが対応する

これは非効率

 

また、「これくらいのテンプレートならサーバーサイドエンジニアでも直せるや」

と思って直すと、フロントエンドエンジニアの人の知らないところで変更が入ってしまってつらい。

BFF があると

問題の切り分けが効率がよい。

サーバーサイドエンジニアはデータを触るだけ

フロントエンドエンジニアの人も、渡ってきたデータを触るのに集中できる。

何か BFF で問題が発生した場合は

インフラの人と責任分担して解決しよう。

SEO/OGP/i18n

のことは、最初から考慮して設計しよう

あとからの対応はほぼ無理になる。

performanceに関わること

BFF を導入しても遅くない。

むしろ早い。

node.js の速さもある。

内部ネットワークでの data fetch をすると rtt 1桁くらいになる。

「BFF しましょうとなったときに気をつけたいこと」

結果的にいいもの作って証明しないといけない。

開発環境を慎重に選びましょう

責任をちゃんと話し合いましょう

計測できるようにしましょう。

 → 数字がないと、何がよくなったのか証明できない。

結論

BFF はいいものだが、それだけじゃ進まないときもある

他の組織と話合おう

責任を分け合って、一部だけがつらくならないようにしよう。

結果的に良いものを作って、みんな幸せになろう。



「BFFアンチパターン」 @yosuke_furukawa

資料

バックエンドとフロントエンドを分けること自体がアンチパターンだという文献もある

そこで書かれていることが、

「どちらにも詳しいという人がいなくなってしまうし、責任の所在が不明確になったりもする。」

 

古川さんが BFF アンチパターンを書いていたときに

だんだん組織アンチパターンになってしまった。

 

BFF はフロントエンドとバックエンドの架け橋。

アンチパターンその1:スパースコミュニケーションのアンチパターン

BFF はアーキテクチャを疎結合にするが、

コミュニケーションまで疎結合になってしまうパターン。

n+1 queryのパターン

マイクロサービスだからといって

API を簡素にしていい訳ではない。

これらのことは、コミュニケーションをとらなかったから起こったこと。

アーキテクチャは疎であったとしても

対等な存在であり、コミュニケーションは密に行おう。

アンチパターンその2:インフラレスポンシビリティ

フロントのために BFF を導入したのに

何か BFF で問題があったとき、その責任をバックエンドに押し付けてしまうという問題

BFF は全員でみるべきものであるので、みんな当事者意識をもつようにしよう。

アンチパターンその3:ビックバンジョイント

フロントとバックエンドを別々で開発しており、

お互いに開発が完了した段階で結合テストをしましょうという段階で

確実に想定外のレスポンスが存在する。

なので、最後の最後で結合してあとは結合テストということができない。

なので、結合テストの部分はスケジュールを長く持たせないといけない。

古川さんたちがやっていることとして、

開発中にモックで作っているものを、

お互いの開発が部分的に終わったら、終わった部分から少しずつ本物にしていくということ。

【サポーターズCoLab勉強会】新規事業開発におけるエンジニアの心得に行ってきました

【サポーターズCoLab勉強会】新規事業開発におけるエンジニアの心得

https://supporterzcolab.com/event/410/

に行ってきたので、そのときのレポート

対象者

  • 現在新規事業の立ち上げに携わっている方
  • これから新規事業にたずさわるかもしれない方
  • (もしくはたずさわりたいと思っている方)
  • ライブラリを書くより、プロダクト開発が好きな方

話すこと

  • 作りすぎて失敗したことの事例紹介
  • つくりすぎないために
  • コアバリュー大事

登壇者の方が作ったサービス

pook

https://s.pook.life/lp/

ランサーズは、オンラインクラウドソーシングの会社だが

pookはオフラインでやることに特化したサービス

 → オフィスで肩を揉んでくれたり

 → 栄養士の方が手作りご飯を届けてくれたり

本題

エンジニアの新規事業への関わり方

そもそも新規事業って?

新規事業とは、既存事業から生かして、新しい経済成果を生み出すこと。

対して、起業というのは0から始めること。

どうやって関わって行くの?

求められること

サービスを作ることが求められる。

実際には、プログラムを書くというよりは、問題を解決すること。

失敗1:作りすぎた。

リリース時に作ったのは、

  • APIの数150本
  • ページは80

ガチガチの仕様をその通りに作ってリリースした。

多いと何が悪いか。

多いとリリースが遅くなる

 → 多すぎたということは、無駄なことを作ってしまった。

  → 使われないコードはただのゴミ。

本当にあった怖い話

 nヶ月書けて作った仕組みをすぐに消した。

 顧客が本当に求めていたものと違った。

どうすれば良かったか?

作らなければよかった

 → しかし作って見ないと分からないこともある。

  → 作る前にそもそも考えることがあるはず。

  • 同じような体験ができるサービスを作って模擬する。
  • ユーザーにもっとヒヤリングする
  • プロトタイプで実験してみる。

反省

  • 作らないで実験できないか考えてみる。
  • 試したい仮説をすぐに実装できないか考える

失敗2:技術選定

エンジニアあるある。

最近イケてる○○という技術を使おうぜ!

 → 既存に縛られないので、使いがち

結果

情報が少なくて死ぬ。

社内で知識が多い人の助けも受けられない。

サービスがあたるか当たらないかという問題の前に

サービスが作れるか作れないかという問題が発生する。

反省

  • 枯れた技術を使うべきだった
  • もっと協力しやすい技術を選定すべきだった。
  • できるかどうか分からないは早めに潰す。

失敗3:仕様が変わる。

どうしてそうなった?

  • 作るべきものがあやふやだった
  • 目的を達成するための機能がもりもり
  • 全部マスト

どうすればよかった?

コアバリューを定めて、やらないことを決める。

コアバリューとは?

ミッションやビジョン実現のために、組織が独自にもつ共通の価値観。

これを選定することで、作らないものを決めることができる。

 → コアバリューはなんですか。どうしても欲しい機能はなんですか。と唱える。

  → そうすることで、議論の着地点も見つかる。

反省

コアバリューを決めて、作らないを決める。


まとめ

新規事業開発に置けるエンジニアの心得

  • 一番大事なことは作らないこと
  • また、そのために、コアバリューを決める。
  • エンジニアとして問題を解決することにコミット

とはいえ、経験がないと分からないことが多いので、経験をたくさんしよう。


Q & A

Q1.

コアバリューを決めることでいらないものが見えてくるということだったが

APIの数など具体的にはどの程度減ったりするか?

A1.

Apiの数は80本になったりした。大体全部合わせて半分くらいになった。

Q2.

やっていくなかで一番コストがかかることは?

A2.

新規事業でいうと、人件費が一番コストになる。

技術でいうと、どこにコストがかかるか?

 → 作って捨てればいいので、キレイに作らないことを考えればよかった。

  → 無駄にキレイにつくることを考えてしまった。

   → 結果、使われないキレイな部分ができてしまった。

なので、キレイに作るっていうところにコストがかかる。

Q3.

新規事業をやる上で、予算をどのくらいに抑えろとかあったか?

A3.

最初はなかったが、途中からなんでこんなに時間かかってんだとかあった。

最初はノリで始まったものだが、どうしてこれこんなに時間かかってるの?とか。

新規事業は黒転するまでに時間がかかる。

 → なので、試算を前もってしておいて(エンジニアどのくらい必要です。どのくらいでリリースできます。どのくらいで黒転しますとか)ロードマップ考えておこう。

Q4.

開発するに置いて、「これ使ったよ」みたいなツールとかあるか?

A4.

プロトタイプを作るツールでいうと、InVisionというツールを作っていた。

https://www.invisionapp.com/

InVisionというのは、web上ピピッと操作してプロトタイプを作れるツール。

逆にコンフルエンスを使ったのは失敗だったと思った。

コンフルエンスはバージョン管理ができたり、キレイに書けたりすることができるツール

別にキレイに書く必要はなかったが、キレイにかけるがために、キレイに描こうという空気ができてしまった。

それよりも、ガンガンアウトプットできるようなツールのほうが良かった。

【集まれKotlin好き!Kotlin愛好会 vol1】に行ってきました

【集まれKotlin好き!Kotlin愛好会 vol1】

https://love-kotlin.connpass.com/event/86390/

に行ってきたので、そのときのレポート

談義: NaotoTakehataさん「サーバーサイドKotlinとの邂逅」

以下、談義を聴きながらのメモ

kotlin導入のきっかけ

Kotlin は Android のイメージがまだ強いが、なぜサーバーサイドで使おうと思ったか?

従来、 Java(spring) で開発をしていた。

開発メンバーから新しい言語にチャレンジしたいという要望があった。

リスクと葛藤

  • Java の資産がいっぱいある
  • 作り直す時間
  • 導入後に廃れたらどうしよう
  • Kotlin できる人材が少ない

kotlinのいいところ

Java からの移行がしやすい。

  • Kotlin で Spring の使用が可能
  • 過去に使っていたライブラリの活用も可能
  • 部分的にjavaを残すことも可能
  • コードの変換が可能

Java to Kotlin

Android Studio の機能で、コードの変換が可能

最初から自分で書き直すよりは、コストがかからない。

結果、Java から Kotlinに移行して、その他(ライブラリなど)はそのまま使えている。

構文の形だけkotlinに書き換えるくらいでいける。

Kotinはサーバーサイドでも十分使える

Javaを使って入れば移行コストは比較的低い

Kotlinはモダンで良い言語

宣伝

「てっくぼっと!」というエンジニアブログをやっていて、

そこで Spring と Kotlin の話を書いていたりするので読んでね。


談義: AtsukoFukuiさん「こんな時どう書くの? 逆引きKotlin入門」

資料

今回のゴールは Kotlin 描き始めたい初心者が  Kotlin よさそうって思えるようになることだよ。

以下、談義を聴きながらのメモ

変数

変数の宣言は var ,  val がある

var mutable

val imutable

型推論ができるので、型を書かなくても変数宣言できるよ!

オプショナルが使える。

null を許容する変数には、変数の末尾に をつける

null を意識するようになるので、ぬるぽで落ちることが少なくなるよ!

変数は class に属する必要がない。つまり、第1級オブジェクトとして宣言できる。

定数には const

関数

fun で関数がかける。

デフォルト引数と名前付き引数をサポートしている。

条件式

if文

Kotlin において if は式。文ではない。

つまり、値を返すことができる。

なので、if 文の中に値をそのまま書けば、それが return される。

例えば、

val max = if (a > b) {

  a

} else {

  b

}

のように。

三項演算子はつかえないが、エルビス演算子が使える。

エルビス演算子の名前の由来は「?:」という記号を横からみると

エルビスプレスリーに似ていることから付いた名前だよ!

null チェックは、スコープ関数とオプショナルの組み合わせがよく使われる。

when

if 同様に when も式

whenの後ろの()の値が比較の対象になる。

when(point) {

  in 0..10 -> User.gold

  else -> User.other

}

みたいにかける。

()を省略してもよい。

when {

  point in 0..10 -> User.gold

  score in 10..20 -> User.Silver

}

のように、違う値を比較することもできる。

まとめ

kotlinはかわいい!


談義: Paniniさん「Convert  Java  file to  Kotlin  file ⇧⌘K」

資料

以下、談義を聴きながらのメモ

android studioで、Java file を Kotlin にconvertすることができる

90%くらいはちゃんと動く。

Java で書いたコードは自分で意図は理解しているので

あとはコンバートしてくれれば Kotlin がかける!

 

ただ、Java  で書いたコードを変換してくれているだけなので、微修正は必要。

 

ぬるぽが起こるところは Kotlin でも起こるので

!!が付いていることがある。

その場合は?をつけると、その値が評価されなくなるので良い。

ただ、評価されなくなるのも困るので、

ちゃんと何か値が代入されるよってことで

lateinit 修飾子をつける。

そしたら ? もいらない。

ただ、初期化の段階で入れる予定の初期値をちゃんといれたい。

だが、onCreate 内で初期化している

そんな場合は、lazyを使えば遅延初期化で初期化ができる。


談義: takahiaさん「KotlinでRealmを扱う」

資料

以下、談義を聴きながらのメモ

Realm とは、Android や ios で使われる、簡易的なDB

登壇者の方は毎回、

「トランザクションの管理と CRUD の実装は、なんで面倒くさいんだろう。」

と思っていた。

Spring Boot は

1個のアノテーションでトランザクション管理ができる。

共通の interface で Crud の実装ができる

まとめ

Realm の transaction 管理は inline で定義して共通化する。

Realm の基本的な CRUD は abstract class で定義して共通化する。


談義: miho.sasakiさん「How to KotlinのセッションからKotlinらしい表現を学ぶ」

資料

Google I/O に行ってきて、

Java っぽいコードをどうやって Kotlin にしていくかっていうライブコーディングをやっていて

そのコードの書き出しを自分でもやってみたので、そういう発表。