電車の遅延情報をslackに投稿するbotをつくりました

githubに公開しています。

使い方は REAME.md に書いてあり、特に難しいことをしなくてもいいのですぐに使えると思います。

github

https://github.com/acchanAlexander/notice-train-delay-to-slack

 

チャットワーク用はこちら

ブログ:電車の遅延情報をチャットワークに投稿するボットをつくりました。

github:https://github.com/acchanAlexander/notice-train-delay-to-chatwork

 

【サポーターズCoLab勉強会】客先常駐エンジニアが戦闘力を上げるN個の方法に行ってきました

【サポーターズCoLab勉強会】客先常駐エンジニアが戦闘力を上げるN個の方法

https://supporterzcolab.com/event/362/

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

※今回の講演は、あくまで登壇者の方の経験や意見です。

そもそも客先常駐って何?

  • 別の企業に出航して働く形態
  • SI系によく見られる
  • 派遣の場合もあるが、そうでない場合もある。

求人について

  • とりあえず未経験でも採用しているところが多い
  • 大手は新卒メインだが、中途は通年採用もしている
  • 前期黒字(設けている)ことを強くアピール
  • 土日はしっかり休めそうな雰囲気
  • 開発案件に携われるということを押している

実際にやる仕事

  • コールセンターだったり
  • SEサポートだったり、
  • ヘルプセンターだったり
  • テスターだったり
  • etc…

メリット

  • 大手企業で仕事をする権利がもらえる可能性がある。
  • 日頃触れないような、古い技術を触ることができる。
  • 給料は悪くないこともある。

デメリット

  • コミュ障にはやさしくない「調整業務」が発生する恐れ
  • 「まずやりたくない仕事」にぶちこまれる恐れ
  • 給料が良いとも限らない
  • 技術的モチベーションの高い人が少数派の恐れ
  • 技術的な向上が望めない場合もある

ぶっちゃけると、研修充実は怪しい

 → 十分な研修ができない可能性

なぜか

  • 教育的ノウハウがない
  • 下請け的なポジションになりがち
  • 保守的になりがち
  • リードするような人がいなかったり
  • モチベーションが低い空気

更にそれはなぜか?

  • そもそも入社する人の特徴が、休みや正社員に惹かれて来る人
  • プライベートな時間の使い方が勉強とかでなかったり
  • 自分が将来どうなりたいかとか、あまり考えてない
  • 安定を求めている
  • 技術に対するモチベーションが低い

客先にエンジニアをぶち込む人(自社の営業の人)の特徴

  • 法人向けの営業脂肪だった
  • 「ベンチャー」という言葉の響きに惹かれた
  • ITに興味がない
  • とりあえず、売り上げやノルマを達成すればいい
  • 数字や単語の組み合わせで仕事をしている
    → 「phpとは、何かサービスを作れるもの」など
    → 経験は何年で、給料はどのくらいで、ということだけを見て人を選んだりする
    → その人がどのようなことが得意か・やりたいかということは見ていない

戦闘力の上げ方

  • とりあえず勉強会に積極的に出てみよう
  • 周りのエンジニアや客先と仲良くなっておこう
  • 開発をやりたいなら自分でサービス作ろう
  • 副業やインターンに手を出してみよう
  • 自社に過度な希望をもつのはやめよう

実践できたら、次のステップ

  • とりあえず勉強会でLTとか登壇する
  • 客先から自分に会う案件を直接紹介してもらう
  • 自分で作ったサービスを人に使ってもらう
  • 異業種交流会とかで小規模な受託案件を探そう

本当の自社との付き合い方

「自社 = 自分の味方」ではないかも?

  • 敵というわけであはないが、少なくとも味方ではない恐れ
  • 敢えていうなら、自社は取引先
  • 基本的には、サポートは期待できない
  • 自社待機の社員は負債という見方も

会社の基本

  • 安く仕入れて高く売る
  • 長期的な教育よりも短期的な利益

どうしたらいいの?

  • 技術の学習はできるだけ自力で
  • 受けの姿勢よりも攻めの姿勢で
  • 副業はどんどんやろう
    → 実は、会社は副業禁止とは言えない。
    ただ、会社に不利益が怒るようなことはやってはいけない。
  • とにかく情報を集めること、集めまくること
    → 結構、常駐先の人からぽろっと聞けたりもする。

担当営業とは仲良くなろう

敢えて言うなら、担当のために働いてあげよう
→ 自分に仕事を持って来てくれる人のために働こう
会社は守ってくれないが、担当は守ってくれるかもしれない。

担当のことが信用できなくなったら終わり

担当もエンジニアが信用できなくなったら終わり

自分の会社のことを理解しよう

絶望する前に、会社に一石投じよう

居続けることもできる。辞めることもできる。

僕らは自由であることを常に頭に置いておこう。

【サポーターズCoLab勉強会】Google公式サポート!Kotlin入門に行ってきました

【サポーターズCoLab勉強会】Google公式サポート!Kotlin入門

https://supporterzcolab.com/event/360/

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

資料

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

 

Kotlin入門までの助走読本
https://drive.google.com/file/d/0Bylpznm149-gTGRjOFRkWm9PODg/view

というのを、登壇者の方が去年書いた

 

2012年に最初のKotlinがリリースされた

 

KotlinはJavaScriptへのトランスパイルもできる。Babelとか使って。

 

extension functionsがKotlinがJavaと比較して実装しやすいメリットの一つだ。

 

簡単なコードを実行したかったら
https://try.kotlinlang.org/
で簡単に実行できる。

 

デコンパイル
→ Kotlinで書き出したものを、Javaのソースに変換もできる。

 

Kotlinで書いて、iOS用のコードに変換することもできる。

 

Kotlinのオススメ本

 

型を書かずに変数宣言したりしたら、ビルド時間が遅くなる?

e.g

var str: String = “moji”

ではなく、

var str = “moji”

と書いた場合に、ビルド時間が遅くなる?

 → 特に感じることはない。

 

Null安全なので、スマートキャストができる

 → 逆に、Javaではできなかったらしい。。。

 

エルビス演算子は、右辺にreturnを書き、即 return するような場面が多い。

【サポーターズCoLab勉強会】副業/フリーランスことはじめに行ってきました

【サポーターズCoLab勉強会】副業/フリーランスことはじめ

https://supporterzcolab.com/event/361/

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

今回話す内容

  • 仲介会社を使わず、コミュニティで仕事を見つけて行く方法
  • 業務委託でやっていくにあたっての基礎知識と落とし穴・塞ぎ方
  • 辛いところなどの雑談

フリーランスと副業の違い

フリーランス

業務委託契約

特定の業務処理についての契約

業務委託

労務を約束し、報酬支払いを受ける契約

フリーランスのはじまり~終わり

はじまり

  1. クライアントから業務についての説明
  2. 秘密保持契約を結ぶ
    こういう情報は外に出したらいけないよという内容の約束
  3. githubとかでソースみたり構成を聞いたりして見積もり
  4. 見積もり額をクライアントに提示、金額と期間の交渉
  5. 金額と期間、進め方の承認
  6. 業務委託契約書を結んでGO

おわり

  1. 業務、成果物をクライアントにもらう
  2. 修正依頼が契約範囲内か確認、やるやらの相談
  3. クライアントから1についてokもらったら請求書発行
  4. 入金確認後、終わり

契約の種類

主に2つ種類がある

準委任契約

コミットに対して支払いが発生する

    → e.g. 作る人はいるけど、それを手伝う

デメリット

しれっと契約範囲外の依頼が飛んできてしまう。レビューなど。

メリット

コミットベースなので、事故っても働いた分だけ請求ができる。

請負契約

成果物に対して、支払いが発生する。

 → e.g. 作る人がいないから丸っとお願い的な

デメリット

これは納品に値しないと、無限に修正依頼がきてしまうリスク

  → 自分の資金が尽きてしまう。

メリット

期間が長いものだと労働単価が高い。

期間よりも短く終わらせたら、その分単価が上がる。

契約書のテンプレ(オフレコ)

オフレコでサンプルを見せてもらいました。

死にかけた話

請負の死にかけた案件

仕様がザルで、クライアントが銀行からなんとか借りてきたお金でなんとかできない?とか言われて始まった

「いい感じにやっといて」とか言われる

納期遅延した結果、「減額しないけど、キリのいいところでいいよ」で終わった…(なんだったのだろう)

請負の死にかけた案件2つ目

製品マニュアルのデータが散らかっているので、新しく乗せ替えるという案件

DB設計はあとで渡すからと言われたが、永遠に渡されず、

こういうことしてもらえませんか?という当初とは違うことを言われる毎日、更に迫る期日。

からの、「間に合わなかったから減額」ということを言われて喧嘩をしたりした。

準委任の死にかけた話

いま外注してるエンジニアがやばい(良くない)から手伝ってと、以前の友達から言われ仕事を受けた。

友情によるしれっと依頼がよく見られるが、友人関係からの「バイブスでOKと答える男気」のスタンスでいた

こういうことをしていたため、圧倒的赤字になってしまった。

ただ、運用フェーズで大きな責任を任せてもらえたりしたので、いい機会ではあった。

炎上や揉め事を防ぐ契約書パワー

落とし穴はだいたい契約書で防げる

契約範囲外のことは、改めて見積もりするよという話

自分の単価を守って行くために

  • 仕事をした分だけお金をもらうという当然のことを守るために契約書は不可欠。
  • 自分が案件をこなしきれないものは受けないようにする。

単価ってどうやって決めるの?

正社員の人の時給を計算してみよう。

 → 月給を160割った値。
→ そこに20~35%上乗せすると、相場っぽくて美味しい。
→ 準委任(コミット契約)はこれでOK

請負は、納期に関するブレが最初期ほど大きいので

最大60%ほど値段を多めに、納期を120%ほど多めにすると良さそう。

例えば、

人月100万の人の時給:6250円

人月80万の人の時給5000円

人月60万の人の時給:3750円

ちょっと高くない?

正社員では定期的に給料があるが、

フリーランスでは次がある保証は一切ない

いい仕事をして、その分の信頼とお金をゲットしよう。

会社によっては、フリーランスに出したほうが安くつくところもある。

どうやって案件を見つけるのか?

例えば、

  • エンジニアの友達が起業し、(3年くらいたったらエンジニアがやめていって)一時的に手が足りないという場合
  • 「同じ会社の文脈で」知り合いづてに連絡がくる
  • 副業やりたいなって、周りにアピールする
  • 昔趣味で一緒にコードを書いてた人と一緒に

やってはいけないこと

酒の席で知り合った人とその場で条件を出し合うこと

 → 再現性のないことを酒の席で言うことはできない。

NOといいつつ請求書を発行する勇気

大事かつ、めちゃくちゃ難しい

契約通りの仕事をしたが、追加でこれもお願いできない?という依頼が来たら、

 → 「無理です、請求書を送ります」と言おう。

相手が困っていることに自分も付き合ったら、自分が困る。

Q & A

Q1. 

自分のキャパを超えないようにということがあったが、

例えば「作ったあとに脆弱性が見つかって、それの対応が自分のキャパを超えてしまう」など

予期せぬことが起きた場合のために、何か気をつけていることがあるか。

A1.

まず、もちろん自分でも色々なパターンでテストをする。

検品の時点で請求書発行できるとか、後から見つかった瑕疵についてはまた別ですとかいう契約を結ぶようにする。

Q2.

契約書のテンプレはどこから入手する?

A2.

ググって用語調べたり、テンプレ見つけたりして、自分に不利のないように編集したりする。

Q3.

危ない案件の見分け方は?

A3.

PMのいない案件は基本的に受けないです。

現場のエンジニアがいて、情報がちゃんと聞けてって状況がよい

そうでないと、炎上する。

【サポーターズCoLab勉強会】【iOS】今更聞けないMVPとMVVMの違いに行ってきました

【サポーターズCoLab勉強会】【iOS】今更聞けないMVPとMVVMの違い

https://supporterzcolab.com/event/339/

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

資料

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

MVPMVVMの違いについて

iOSアプリ開発におけるMVPについて

View

presenterからデータをとって表示したり

Presenter

データを持ってるものからデータを取得する

PresenterはViewの参照を持つというのが、

他のアーキテクチャ(MVVM)とは違うところ

 

Viewでタップされたら、

Presenterが必要なロジックを用いてデータをModelとかから取得する。

PresenterからViewに値を渡す役割はViewControllerが担う。

iOSアプリ開発におけるMVVMについて

ViewModelviewの参照をするわけではなくて、DataBindingによってViewが値を参照する。

Viewは、DataBindingで画面に反映させる。

 

ボタンがタップされたときなどに

タップされたことをViewModelに伝えて、

ロジック処理をしたあとに、プロパティ(DataBindingしている値)を更新する。

 

MVVMでのユニットテストについて

referenceを持っているのは、

VMからModel側のみ

 

NotificationCenterは自前でインスタンス化すれば

そのインスタンスを知っている範囲内のみで通知することができる

NotificationCenter.defaultというものがよく知られいるが

それはアプリケーション全体に通知してしまう。

Q & A

Q1.

アーキテクチャ選定の際はどのようにしている

A1.

AbemaTVでは、MVPMVVMFLUXも使っている

利点として、変更とかあっても、大人数で行なっているときに、コンフリクトしにくいとかがある。

どのアプリケーションについてもこのアーキテクチャが良いというのはなくて、

こういうアプリケーション設計にしたいから、ということを考えて

MVPMVVMなのかとかを考えて行く。

Q2.

自前でやるときとライブラリを使うときの基準は?

A2.

開発体制や作りたいアプリによるところがあるのだが、

副業とかで何かアプリを作成しているときに

ライブラリのインストールとかも承認してもらったりとかあるんだったら

自前で作ったりとかもする。

本当はRxとか使ったりするのがいいかなとも思っている。

【CDN Study (Akamai/Fastly)】に行ってきました

CDN Study (Akamai/Fastly)

https://http2study.connpass.com/event/81469/

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

イントロ

資料

まず、jxckさんから

CDNの変遷(変化)

edgeの数こそ正義

そのあと

edgeの数よりは同じurl使ってることが良いよねってなった

jqueryのダウンロードを他のサイトでやってたらキャッシュされるよねとか

さらに

cloud cdnが出てきて敷居が下がった。

ただのファイルだけじゃなくて、

imageを最適化してくれるとか

ddosに強いとか

さらにedgeの中でいろんなプログラムが動いてたらいいよねとか

cdnが前提になりつつある今

パフォーマンスやセキュリティの面から

edgeが正義という感じではなくなってきた。

縁の下の力持ちという感じではなく、

もっと前へ前へと出てきている感じがする。


Akamaiの方(岡本さん)の話

悪魔で個人(登壇してくださった方)の見解です

資料

CDNの過去と現在

各CDNベンダの歴史を見てみる。

一応、CDNですと言って出てきたのは1995年にAkamaiが初

そのころ、今のインターネットはコンテンツ配信が中央集権的なものになってしまって

限界があるだろうと言われていた。

 

http://as2914.net/

というサイトで、インターネットの地図が見れる。

すごい

このサイトからも分かるように、インターネットはとても複雑な網目状になっているのに対して

配信箇所が一箇所だと、渋滞が起きてしまうだろう。

 

1998年にstar warsの映画の予告編が公開された

これが、「インターネット最大のダウンロードイベントだった」と、スティーブジョブズが言っていたらしい

このように、コンテンツが一気に様々なところからDLされるということがあり

このままではインターネットは壊れてしまうと予想された。

世界で動画を配信するような設計に、インターネットはなっていなかった。

このようなことからCDNの必要性が出てきた。

CDNの基本的な考え方

ユーザーの近くに必要なファイルのコピーがあればよいではないか。

akmaiの仕組み(ほんの一部)

Akamaipop(edge)が他のCDNベンダーと比べてダントツで多い(桁が1桁違う)

世界中に数多くあるのがAkamaiの特徴

ただ、数が多いと大変という話

ユーザーをどうやって最適なedgeに誘導するのか

 → DNSの名前解決の時点でアクセス元によって応答を動的に変える

  → 実は、これはAkamaiの特許(2019年で特許が切れる。)

Google Public DNSとAkamaiが相性が悪いという話

 → 全てが8.8.8.8からきてしまうと、区別がつかない

  → 今は別に相性が悪くなくなっている

最適なエッジサーバー群とは?

CPUバウンドやネットワークバウンドなどいろいろな要因があるなかで最適なedgeを探すのは難しい

 → 安定結婚問題、gale-shapleyアルゴリズムを当てはめている

Akamaiedgeサーバーの構成

  • 高機能な独自開発httpサーバー
  • xmlベースのdlsでロジックを組む
  • 膨大な機能があるため、したいことは現場のエンジニアレベルで大抵できる
    → なので、この問題はUSに問い合わせないとということがあまりない。

せっかく近くにいるのだから、もっと高度な処理をしたいよね

例えば、セキュリティ対策など

岡本さんがCDNでしたかったこと、していること

  • ddos対策
  • waf
  • スクレイピング対策
  • 画像動画htmlなどを自動的最適化
  • webサイト全体
  • apiをキャッシュから出して応答を速く
  • 静的ファイル配信はまかせたい
  • sslセッション数が多すぎるので対処
  • インターネットの経路の不安定さを解決

CDNのもともとの名前の意味としても

現状は大分変わってきている

Akamaiの動き

bot managerimage managerをリリース

最近だと、2018年にedgeで動作するjavascriptを開発中。

Akamaiの方(塲田(ばだ)さん)の話

資料

Akamai も標準化へ参加している

CDNがどんどん進化していくのも必要だし、ブラウザもどんどん進化する必要がある。

CDNベンダーもブラウザと共通言語で話せる必要がある。

新しいプロトコルを使いたいとなった場合もブラウザの対応が必要になる。

Akamaiによるhttp2

ユーザからhttp2でリクエストをしてもらい、Akamaiで受け、http1.1webサーバーに流すなど

real user monitorRUM

 → このページを見たユーザはこのページも見そうだから、
このcssjsを送るようにしよう
というアルゴリズムを作ったりしている。

QUIC

https://blogs.akamai.com/jp/2017/05/udpquic—akamai-media-acceleration.html

TLS1.3

draft21もしくは23に対応したopensslを使えば、AkamaiとTLS1.3で通信ができる

CDNの未来

edgeはどこか?
→ 今後、もっとedgeがユーザの近くになるのではないか
携帯電話会社なのか、電柱なのか、スマホの中なのかとかとか

edge computing がくるぜ!っていう論文もある。

The Emergence of Edge Computing
http://elijah.cs.cmu.edu/DOCS/satya-edge2016.pdf

  • コンテンツ予測配信
  • 携帯電話専用回線網
  • デバイス間コンテンツ共有
  • などなど、、、

webガバナンス強化のためのCDN

様々なドメインでサービス配信してる時に、メインサービスは脆弱性対応しているが、全てのサービスに手が回ってないとか

自分の会社のサービスはどこが守れていてどこが守れていないのか

どこがcipher suite しているのかしていないのか

そういうことを管理できるようにしよう。

取り入れられそうなこと

開発後にチューニングとしてCDNを取り入れるのではなく

CDNを最初から考え、どの程度のTTLなら許容できるのか、キャッシュはどのようにしようかなど設計しましょう。

cacheabilityの観点からのアプリケーションのモデリングをしよう

  • キャッシュの時間設定などが、ボトムアップだったり、良い設計ができていなかったりする
  • キャッシュの生存時間を変更できるようなアプリケーション

Let’s Encrypt

Akamaiを使えば、Let’s Encryptとの連携も比較的簡単にできるよ!

 → Let’s Encryptをそのまま使うとなると、 cert bot などちょっと癖があるが、
そういうのを簡単にできたりするよ。

Q & A

Q1.

cacheabilityに関して、

それを取り入れるのが難しいと思うが、

webアプリケーションフレームワークの中にcacheの機構を持たせるようなことができたらハードルが下がりそうではないか?

A1.

たしかに、その視点はなかったが、それは良さそう。

Q2.(岡田さんから)

Multi CDN の話とかがあるが

A2.

あんまり凝ったことをしたいわけではないのなら、singleでやったほうがいいと思う。

Q3.

server pushってクライアント側の情報がわからないと難しいと思います。

cacheダイジェストなどもあるが、Akamaiさんの中でどのくらいserver push が使われていて、どのくらい早いのかとか教えてほしい。

A3.

アルゴリズムの際に、機械学習などを利用しているという風に、岡田さんは聞いている。


Fastlyの方(奥さん)の話

悪魔で個人(登壇してくださった方)の見解です

資料

Fastlypop設計

キャッシュヒット率を高めたい。

  • コンビニモデル
    → ユーザの近くにたくさんのpop
     → メリット:底レイテンシ
  • スーパーマーケットモデル
    → ixの近くに巨大なpop
     → メリット:cacheのヒット率をあげることができる。

Fastlyは主にスーパーマーケットモデルを採用している。

popのキャパ

1Tbpsクラスのネットワーク

32台のクラスタ

Fastlyはルータレス、ルータを使っていませんよ。

32台のサーバーがルータも兼ねている

ロードバランサ

大量のリクエストをさばくにはコストが高い。

ECMPという技術

 → これも問題がある

  → 外すタイミング問題

   → ステートレスロードバランサというやり方をしている

    → クラスタの応用、ノードにあるサーバが知っている通信は別のサーバに流さないし、知っていない通信は別のサーバに流す。

他社と比べて

http2も早い

まとめ

FastlyはAkamaiとは違い、スーパーマーケットモデル
 → そのために、スケールアップ・スケールアウトの仕組みをソフトウェアを使って実装している

VCLについて

VCLができること

  • リクエストのルーティン具
  • リクエストの書き換え
  • レスポンスヘッダの書き換え
  • リクエストの再送(回数制限あり)
  • etc…

パージ

  • URLを指定してパージできる
  • キーを指定してのパージ
    → 特定のキーがついたキャッシュをまとめてパージできる
    → 例えば、jscssのファイルを一気にパージしたいとき、特定のキーを持たせておいて、それをパージさせる
    → メリット:url単位での参照、パージができる

ヒット率の高いキャッシュ率を実現するには

  • 大容量のキャッシュ
  • インスタント・パージ
  • shielding

他には

  • waf(web application firewall)
  • ddos対策
    → ddos対策をしながらも、他のお客さんにも迷惑がかからないような仕組み
  • edge-side includes(Akamaiでもやっているし、Akamaiからの移行もしやすそう)

CDNの歴史とこれから

  • プロトコル上の制限がボトルネックに
  • スマホの普及
  • スノーデン事件
    → 大規模な情報を管理する上で、プライバシー保護について厳しくなった

このようなことから、インターネットとプロトコルが進化してきた。

プロトコルの進化の方向性

  • 全ての通信の暗号化
    → ルータとかでの通信の硬直化をしないようにしよう
  • 迅速なセットアップ
    → リンクを端末にpushし、それがブラウザ上にあるか確認したりする
  • ネットワークをまたいでも途切れない通信
  • 劣悪な環境でも粘り強く通信をするように
  • DNS over https
    → DNSからのクエリなのか、CDNからのクエリなのか分からなくなるので、セキュア
  • cache diggest http
    → オリジンの処理中にCDNからアセットを配信
  • server timing
    → 配信タイミングをjsで取得
  • secondary certificates
    → 1本のTLS接続で複数の証明書を使う
  • short term cert
    → ある国では、証明書は政府で管理しましょうとなっているところもある。
    できるだけ秘密鍵が漏れたときの影響を少なくしよう。
  • variants
    → varyのキャッシュ爆発の問題を対策

QUICの目標

  • 1個目のパケットが処理できなかったとしても、2つ目3つ目のパケットを処理できるようにしたい。
  • 進化を続ける通信プロトコル
    → tcp first open という機能は、8年間実装にかかったりした。
    それは、アップデートを邪魔をするルータがいたりしたため。
    → アップデートに妨げられないプロトコルが必要
  • 相互接続試験をやりながら、各社プロトコルを実装している。
    → googleはGquicというものを使っているが、だんだんIquicというものに近づけている。
    そのような動きもある。
  • Fastlyもプロトコル標準化に参加している

まとめ

CDNとしてのミッション

  • より安く、より速くコンテンツを配信
  • 全世界的な分散kvs
  • edge cloud
  • プロトコル進化の促進

Q & A

Q1.

web packagingについてどう思いますか

A1.

ampの問題などがあるが、web packagingのような技術が標準化されるのはいいと思う。

Q2.

ネットワーク回線も問題になりがち。配線や回線について工夫しているところはあるか?

A2.

私はsoftware engineerなので言えることは少ないが、

弊社はコンテンツ配信の一点特化なので、それに合わせた設計をしている。

例えば、ルータレスルーティングとか。

Q3.

Fastlyvarnishが元になっていたりして、edgeのほうにバグが発生することも考えられるが

そのようなものに対してテストをやるための仕組みはあるか?

A3.

お客さんがテストするような仕組みはちょっと分からないです。開発の中でもテストはあると思うが。

ちょっと他の人に聞いてほしいです。すみません。

Q4.

標準化の中でデータを公開する話とかどうなってますか。

A4.

そこがやはり議論になっていて、何を見せて何を見せないかっていうのをちゃんと考えている。

例えば、うっかりルータから見えてはいけない情報が見えたりとか。

なので、何を見せるのか、見せない代わりに何か別のものを見せるとか、そういうのを明文化している。

Q5.

CDNwafとかddosの話も出ている。

ただ、動的なコンテンツを配信しているwebサーバもあり、どこまでを通すのかというのが難しいと思う。

どこが適材適所なのかという意見とかあるか。

A5.

FastlyはCDN会社なのでCDNでやってほしいと思うが、どうしても共用サーバであることの制約とかもある。

どうしても処理の重いこととかは、別なサーバーでやったほうがいいなどトレードオフはあると思う。