心理的安全性について考える

心理的安全性に支障をきたす原因

  • 無知だと思われる不安
  • 無能だと思われる不安
  • 邪魔だと思われる不安
  • 批判的だと思われる不安

THE TEAM 5つの法則 (NewsPicks Book)

THE TEAM 5つの法則という本からの抜粋です。

  • Aim
  • Boarding
  • Communication
  • Decision
  • Engagement

5つの法則とはこれらのことで心理的安全性の話はCommunicationの項目で出てきます。

メンバーから意見が出てこないなあと思う前に言うべきでない発言を自分も含め誰かがしていないか気をつけておこうと思う。

wordpressのアップデートでハマった話

先日、wordpressの更新があることに気づいたので何気なく更新ボタンを押したら管理画面にもブログにもつながらなくなってしまった。

最初、wordpress側のファイルが壊れたのかな?と疑って、既存のwordpressフォルダを退避して最新版をダウンロードして置き直した。

けれども全く改善せず、、

アクセスログをみてみると、そもそもサーバまで到達していないような様子。

ネットワーク設定が急に変わる訳もないがファイヤーウォールの設定を見直したりとかするも特に変なところはない。

サーバに入ってローカルからcurlで叩いてみるとhtmlが返されている。

結論としてはグローバルIPが書き換わっていたことが原因でDNSに設定されているIPを新しいものに更新したらなおったと。

GCPのインスタンスに割り当てられたIPがエフェメラルで静的なものではなかったことに起因していたと思うのでこの機会に変更した。

しかし、wordpressの更新でグローバルIPが変わってしまっているとは思わず解決に時間がかかってしまったのは修行が足りない。

Cloudflare対応してみた

特にこのサイトに負荷がある訳ではないけれどCloudflareを経由するように設定してみました。

ドメインはお名前で取得したものですのでこの辺の記事を参考にしてDNSの設定まで行って、直後にアクセスしても元の経路でしたが数時間後にみてみたらSSL証明書がCloudflareのものになっていたので、切り替わってるなあとわかりました。

あんまり早くなった気はしないが、、

追記

このQiitaの記事がなかなか良い。画像ファイルをCloud Strage使うのをやってないけど試してみようかな。

https://qiita.com/ryuta69/items/dbb0db5cf7099b7a7cc4

Amazon Dashボタンの不具合が解消していた件

以前に記事を書いたこれ。
最近、荷物を整理していたらこの役に立たなかったダッシュボタンが出てきました。捨てる前にもう一回設定試してみるかーと思ってやってみたらアッサリと接続できました。
Amazon.comとアカウント連携している場合に発生していた不具合は今は解消されたようです。

光るりんご

これはアップルが学生向けのプロモーション動画の中の1シーン。

どうやら2016年のモデルチェンジ以降は鏡面仕様の現在のりんごマークになっている様子。最新モデルの機能をアピールしたりするような内容ではないのでモデルはなんでも良いという判断なのかな?

鍵を探すTile Mate

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

2019年が始まりました。
今年の4/1には新年号が発表となり5/1に改元となりますし、10月には消費税増税が待っているという変化の年となりそうです。

さて、Amazonが初売りセールをしていたので眺めていてTile Mateという製品を買っちゃいました。

スマートトラッカーという言われるもので家の中でどこに行ったかわからなくなったものを音を鳴らして探せるというものです。

Apple WatchでiPhoneを探すのもちょいちょい使っているのですが、もう一つよくなくすのが家のカギです。カバンや上着のポケットに入れっぱなしにしてしまいどこにしまったのかわからなくなってしまうのでカギに付けました。

これで今年はカギを探している時間を節約できるハズ。

Google PayがQUICPay対応でKyashも利用可能に

iPhoneではApplePay対応が進みませんが。。
KyashのApplePay対応は誤報

Google PayがQUICPayに対応しKyashも利用できるようです。

ワリカンなどで回収したKyashの残高をリアル店舗で使いやすくなるのは素晴らしい。

iPhoneではOrigamiPayにKyashのカードを登録することでローソンなんかで利用できることを最近知りました。
キャッシュバックの還元率も良いみたいなのでLINE Payみたいにキャッシュバックがなくなる前に試しておくのが良いかもですね。

[AWS] SNSメッセージをSQSでサブスクライブする

マイクロサービス化する場合にモジュール間を疎結合に保つためコレオグラフィアーキテクチャを採用できるところではしたくなります。

コレオグラフィについてはQiitaの以下の記事が参考になります。

そこでpub/subの仕組みをどうやって実装するか?という課題ができてきますがAWSであればSNS/SQSが利用できます。
以下のスライドや記事が参考になります。


これで本番運用しよう!と思った時に1つ疑問が出てきました。
SNS->SQSとメッセージを送る際にSQSが障害などで利用できなくなっていた場合にSNSにパブリッシュされたメッセージはどうなるのか?まさか消えちゃうとか無いよね?と。

答えはFAQにありました。

Q: サブスクライブしているエンドポイントが利用できない場合、Amazon SNS メッセージはどうなりますか?

SNS に送信されたすべてのメッセージは、直ちに処理されて配信されます。最初の試行でメッセージが正常に配信されない場合、SNS では次の 4 段階の再試行ポリシーに従った処理が行われます。(1) 遅延なしの再試行、(2) 最小遅延間隔での再試行、(3) バックオフモデル (線形または指数的) を使用した再試行、(4) 最大遅延間隔での再試行です。
ポリシーはエンドポイントによって、以下のように異なります。

SQS: SQS キューが利用できない場合、SNS は直ちに 10 回、続いて 20 秒間隔で 100,000 回の再試行を行います。つまり 23 日あまりで合計 100,010 回の再試行が行われます。この再試行後に配信されないメッセージは SNS から破棄されます。

SQSへの送信が失敗した場合のメッセージの消失については23日間障害が続くというのは考えにくいですし、十分にリトライ処理がされるようなのであまり気にしなくても大丈夫そうです。

とはいえ、SQSが利用できない間はサービスが利用できない状態になると復旧までにかかる時間によっては何か考えないといけないです。
全リージョンで同時に障害というのはあまりないのでマルチリージョンで構築するというのも1つのやり方のようですがどの程度まで担保するかは要検討。

VPNサービスと動画配信サイト

先日、タイにいってきました。
その際にJリーグの試合の観戦をしたくてHotspotVPNを利用して日本サーバから接続してみましたが観ることはできませんでした。
以前はこの方法で海外から接続できたことがあったのですが。。ついでにスカパーオンデマンドもダメでした。

おそらく有名どころのVPNサービスが利用しているIPアドレスをブラックリスト化しているのかなと思われますが利用者側からすると残念です。
海外での配信権を持っていないからということだと思うので実際VPNを利用してもみられないのがサービス提供者としては正しい状況です。

ゲームや動画配信の権利って音楽に比べると全世界で提供できるようなライセンスを取得するのが難しいものなのですかねえ?
そもそもサービス提供者がコンテンツごとの配信料を視聴数とかで従量で権利者に支払うような契約ができるなら再生された分だけきちんと権利者に支払いがされて、視聴を制限するよりもみんな得すると思うのですけどそうも行かない事情があるのかな。

コンテンツを持っている人にきちんと利益を配分しつつ、ユーザが利用しやすいようになるといいなあと思ったのでした。

DDDを実践するときのアーキテクチャ

エリックエバンス本や実践ドメイン駆動を読んでも思想的なところは定義されているものの実際のプロジェクトの中でどう落とし込むのかについては、それぞれで考えないといけないです。

DDDと一緒に語られているアーキテクチャについてよくまとまっている記事がQiitaにあったので参考に。

今、進行中の案件ではKotlinでSpringBootを使ってバックエンドのAPIを開発していて、
普通にやるといわゆるMVCの三層アーキテクチャになってしまうのですがここにドメインモデル層を確立してドメインロジックを集約したいなと思っています。

Controller -> Presentation
Service -> Application

思想的なところでのマッピングとしてここまではよくて、
ドメインモデルとORマッパー実装を切り離しドメインモデル層を確立しないといけないです。
ORマッパーはMyBatisを採用しています。
model層にはモデルとMapperのinterfaceを定義しinfrastracture層にMyBatisに特化した実装を逃しています。

以下のようなinterfaceをmoodel層に定義し、

infrastracture層には以下を定義します。

Couponモデルに値オブジェクトとしてCouponCodeを定義していたり、Couponのビジネスロジックを集約するようにします。

こんな感じで三層アーキテクチャ+ドメインモデルを試みておりますがまだまだ色々と試行錯誤を繰り返しています。