Home¶

VPCエンドポイントは、サポート対象のAWSサービスなどにVPCをプライベートに接続可能な仮想デバイスのこと。Virtual Private Cloud (VPC) とサポートされているサービスの間の接続が有効になる。 ゲートウェイエンドポイント と インターフェースエンドポイント の2種類あり。

ゲートウェイエンドポイント

VPCにインターネットゲートウェイや NATデバイスを必要とせずに、Amazon S3 および DynamoDB への信頼性の高い接続を提供する。

vpc-endpoint-s3-diagram

インターフェイスエンドポイント

VPC内にインターフェイスを設置して、インターネットゲートウェイを介さずに、VPC外(AWS通信網内)のサービスにアクセスするための機能のこと。

下記例では、プライベートDNSの有効/無効時のVPC外の接続方法の違いを説明している。

プライベートDNSを使わない場合

デフォルトの DNS 名を使用して AWS リージョンのパブリック IP アドレス空間経由で Amazon Kinesis Data Streams と通信。

vpc-endpoint-kinesis-diagram

プライベートDNSを使った場合

デフォルトの DNS ホスト名またはエンドポイント固有の DNS ホスト名を使用して、インターフェイスエンドポイントを介して Amazon Kinesis Data Streams にリクエストを送信。

vpc-endpoint-kinesis-private-dns-diagram

VPCピアリング

2つのVPC間でプライベートな接続を可能にするネットワーキング機能。

2022年4月21日
このページは約1分で読めます

日記

妻が急遽手術して週末まで入院することになった。

3月下旬から定期的に左の下腹部の痛くなるので、消化器内科や婦人科系のクリニックで見てもらったりしてたけど、問題なしと診断されていた。

けど、昨日から痛みが出てきたので大きめの病院の婦人科で見てもらったら、子宮外妊娠と診断され緊急で手術することになった。手術は1時間程度で終わり無事成功。

妻は本当に痛そうだったので心配してたんけど、ようやく原因が分かったし処置できたので一安心。退院したらいっぱい美味しいものを一緒に食べに行こうと思う。

2022年4月10日
このページは約1分で読めます

PHPで数値判定をするときは"e"に気をつけよう

指数表現を理解していなかったために間違ってしまった問題があったのでメモ。

少し実装方法に触れてるのでアウトだったら消します。

paizaラーニングの問題B104:データのクレンジングで次の条件がありました。

今回行うクレンジングでは、回答が 0 以上 100 以下の整数ではないデータをすべて取り除きます。なお、先頭に 0 がついているデータ (035 など) は有効です。

上記説明を簡単にいうと、インプットの文字列が0以上100以下の整数であるかをチェックする必要があるということです。インプット文字列は以下の条件を満たします。

-1,000 ≦ s_{i, j} ≦ 1,000 または、「英字小文字 / 数字」からなる文字列
1 ≦ 文字列 s_{i, j} の長さ ≦ 5

このチェックを以下のように実装しました。

function hoge(string $value): bool
{
    if (!is_numeric($value))
    {
        // 数値文字列判定
        // $valueに英字が含まれている場合にfalseを返す
        return false;
    }

    $value = intval($value);
    // 0 以上 100 以下を判定
    return ($value >= 0 && $value <= 100);
}

しかし、この実装で提出するとエラーとなるパターンがありました。それが、eを含むときです。 PHPではeを指数表記として利用しています。例えば次の文字列は数値文字列として判定されます。

3e1
1e2

REPLを使って確認してみます。

php > echo 3e1;
30
php > echo 1e1;
10
php > var_dump(is_numeric("3e1"));
bool(true)
php > var_dump(is_numeric("1e2"));
bool(true)

そのため、整数チェックをする場合、次のうちどちらかを採用するのが良さそうです。

ctype_digit 関数で数値チェックをする
preg_match 関数を使って正規表現でチェックする

2022年4月9日
このページは約1分で読めます

日記

数日前からpaizaからスカウトメールが来るようになった。最後にやったのは2年前だし全然更新してないのに何故かよくメールが届く。

これをきっかけにプログラミングスキルチェックを少しやってみることにした。スコアやレーティングは意識せず継続的に続けていきたい。多分無理だけど。

2022年4月6日
このページは約1分で読めます

NordVPNで接続できないサイトがあったので設定を変えてみた

対応方法

VPNプロトコルはOpenVPNorIKEv2を使う

先日NordVPNの2年間プランを購入しました。実際に使ってみるとVPN未接続では繋がるのに、VPN接続中では繋がらないサイトがちょくちょくありました。

結論としてはVPNプロトコルNordLynx以外のプロトコルを使うようにしたら問題は解決できました。

デフォルトではNordLynxとなっています。NordLynxは最新の技術でありパフォーマンスに優れているとのことです。しかし、サイトに繋がらないのでは意味がないので、OpenVPNとIKEv2でVPNを使っていこうと思います。

繋がらないのは日本のサイトだったので、もしかしたら国が関係しているかもしれません。

2022年3月21日
このページは約1分で読めます

日記

3/19(土)に3回目のワクチン接種をしてきた。副反応としては37℃程度の熱と節々の痛みのみ。接種後20時間後ぐらいにロキソニン飲んだらそこからは体の不調もなく終了。4回目の接種時もこんな感じだったらいいな。

浅草キッド見た。深見千三郎が主役の映画って感じ。

2022年2月13日
in book
このページは約1分で読めます

『外資系コンサルが教えるプロジェクトマネジメント』

約10年、IT業界で働いていますが、リーダーというものがやってこずこれまで来ました。さすがにそろそろやりそうなので、事前に必要な知識を得たいと思い、この書籍を購入しました。

プロジェクトをリーダーとしてやっていくために気をつけていくことが実体験や歴史的事例を基に分かりやすく書いてあります。

以下は私が本書で気になった部分の抜粋です。（自分用メモ）

第1章プロジェクトは始まる前にすべてが決まる

目的が不明確なプロジェクトはポシャる可能性が高い。「目的」がないと大きく二つの問題が起きる。
プロジェクトに問題が起こったとき迂回路を取れないという問題が発生する。
チームメンバーの管理が難しくなる。
「問題」とは「現状と理想のギャップ」なので、「問題」を議論するということは「何を、どう変えたいのか」ということを議論するということ。目的をはっきりさせないと、人はどうしてもどこかでシラケてしまい、熱量を維持することができないくなる。
プロジェクトに必要な人材の質と量に対して、ちょうど100%になるようなチーム体制では必ず破綻する。なぜなら、機器対応できないから。何らかの想定外の事象が発生したとき、ギリギリのメンバー構成では対処できず、プロジェクトが破綻する。70%ぐらいの稼働率が理想的。
成功も失敗も、リーダーの評価になる。プロジェクトが成功すれば、すべては丸く収まり、失敗すれば、すべてはリーダーの責任になる。
プロジェクトメンバー全員が、物理的にいっしょにいられるかどうかで、業務効率は大きく変わる。想定通りに進んでいる場合はいいが、プロジェクトの難易度が高く、当初の想定通りにはいかない局面がでてきたばあいのコミュニケーション労力が大きく変わる。
リーダーはプロジェクトの目的を明確化する必要がある。チームが掲げる目標には三つのタイプがある。
合理的計算型
ビジョン型
ランダム試行型
強い組織は上記三つのパターンをうまく組み合わせている。
人間は、意義を感じない仕事には情熱を持って取り組めない
プロジェクトデザインにおいて、排除できるリスクについてはできる限り排除する
チームの稼働には、ある程度「遊び」があったほうが生産性が高くなる
「プロジェクトオーナーは誰か」「その人はそもそもどんな問題意識を持っているのか」「このプロジェクトにどんな期待をしているのか」を明らかにすることが重要。これを知るには単純に「聞く」しかない。「言語化」が大事。=> プロジェクトオーナーの期待値と問題意識を把握する。
プロジェクト内部における仕事や役割において、優劣や上下の感覚を許さない
参画するメンバーの懸念や期待を把握する
評判の良くないメンバーであっても、そのメンバーの「成長余力」を信じて接してあげる
「マタイ効果」を意識する
関係者の期待値より高い結果に終われば「成功」であり、関係者の期待値より低い結果に終われば「失敗」
プロジェクト関係者の裏マップをつくる。この辺に無頓着なメンバーは意外と多い。

第2章プロジェクト序盤に注意すべきこと

最初期のミーティングでは期待値を超え、「貯金」をつくる
ことあるごとに「目的」に立ち返らせる。プロジェクトの開始段階で、チームメンバーに目的を浸透させる。ことあるごとに意識させ、「自分で答えに至る」感覚を覚えさせること。
メンバーの士気が低いのはリーダーのせい。士気を高い水準に保つリーダーの特徴として2つある
プロジェクトがどのような意義を持っているのかを継続的にリマインドさせる
期待役割の明確化
関係者を不安にさせない
チーム形成のプロセスの例としてタックマンモデルがよく知られている
フォーミング（形成期）
ストーミング（混乱期）
ノーミング（規律確立機）
パフォーミング（活動期）
ストーミング（混乱期）を早期に乗り切るには、リーダーによるチーム憲章の宣言が有効
チームの力量が高いチームの要素の一つは「チーム内で流通する『情報の量』」が多い。メンバー同士の「横のコミュニケーション」が活発化されると、チームの自律性はより高まり、情報量は大きくなる。

第3章プロジェクトをうまく「着陸」させる

「メンバーの時間」にはデリケートな配慮が必要。
リーダーはメンバーに相談されるようになったほうがよい。そのためにはとにかく「聞く」こと
キーマンとは月に1回程度コミュニケーションをとり、プロジェクトの向かっている方向に大きなズレがないことを確認する。
定例会議では「やったこと」ではなく「その時点での結論」を出す
直感的に「何かがおかしい」と感じたときは早めに共有する
プロジェクトが進行していくに従って、プロジェクトが当初掲げた目的や問題からズレていってしまう、というのはよくあること。リーダーは遠くのゴールを見据えてそれをブレさせないようにする。
「最初に立てたお題にはこだわり続ける」必要があるが、当初考えていた仮設やアプローチがうまくいなかいということがわかったときは、迅速にそれを認めて仮設を作り直す、あるいは別のアプローチを考えることも必要。自らの考え方が誤っていたことを認め、変化を受け入れる。
プロジェクトでトレードオフとなる要素は「時間」「コスト」「品質」
メンバーへのフィードバックは「その場で」が基本。「自分のやった行動」と「結果のフィードバック」は、時間軸が短ければ短いほどいい
メンバーには「行動」ではなく「目的」を伝える。力量が足りていない、まだ未熟だという人には「目的と行動」を一緒に伝える。
フィードバックの基本は「行動＝ドゥーイング」について指摘する。「どうあれば＝ビーイング」の指摘ではない。

第4章計画を成功に導くリーダーシップ

慕われるだけのリーダー」でも「恐れられるだけのリーダー」でもダメで、両者を高次元でバランスさせているリーダーこそ、良いリーダー
優れたリーダーは必ず嫌われる。敵がいないリーダーなどありえない
「場をコントロールする」という意識をもつ。みんなから自然とリーダーとされる人の特徴は「一番先に話し始めた人」ということ
必要なときに「助けてください」と声をあげること
いつも上機嫌でいること。そうすることで、メンバー相互間、あるいはメンバーとリーダーとの間での情報量が増加する。
メンバーを他人と比較することはしない。過去の自分（メンバー）と今の自分（メンバー）を比較する
「率先垂範（人の先頭に立って物事を行い、模範を示すこと）」によって、組織は活性化するどころか、むしろ停滞する。
なにか失敗したときは、「犯人探し」よりも「原因究明」に軸足を置く

2022年1月29日
in book
このページは約1分で読めます

『ユーザー中心論〜あなたからはじめる心を動かすモノづくり〜』

ユーザーの課題を解決する、より良いものを提供する、といった観点で何か知りたいと思い、この書籍を購入しました。

なんとなく知っているようでもやもやしていたことを、うまく言語化し、わかりやすく説明された本だなーといった印象です。

仕事をしていく上で、うまくいかなくなったとき改めて読んでみると解決の糸口をつかめるような、素晴らしい一冊でした。

以下は私が本書で気になった部分の抜粋です。（自分用メモ）

ユーザーが多様なニーズを持つ現代においては、さまざまな人が共通のユーザー視点を持つことで、ユーザーに新しい価値を届けることができる
ユーザー視点を組織全体で持つことが、価値の創造につながる
価値は隣人や組織を通じてユーザーに届く
フレームワークは守破離の精神で使ってこそ活きる
ユーザー自身が気づいていない潜在意識に潜むニーズ、を把握して、ユーザー自身の心や体験に働きかける価値（意味的価値）を見つけ出すことが必要
機能の持つ価値がユーザーの心を揺さぶって、はじめて意味的価値は生まれる ※意味的価値: その機能がユーザーの感情を揺さぶった結果生まれた価値
自身が持つ 無意識のバイアス を自覚することが、ユーザー視点に立った観察をはじめる第一歩
「共感（Empathy）からはじまるユーザー視点」を持ってユーザーへの深い動作を続けることで、正しいユーザー視点を身につけることができる
共創を生む組織では、メンバーが持っている以上の能力を発揮したり、誰も思いつかなかったアイデアが生まれたりする
ユーザーに価値を提供するためには、プロダクトだけにではなく、組織そのものに注目しなければならない
それぞれの立場の支店からモノを評価するのではなく、評価する視点を組織でひとつにまとめることが大事。互いの視点がそろっていないとロスが生まれる
どんな立場のメンバーであっても、それぞれの「よいモノ」の先には同じユーザーがいる。ユーザー視点は、組織のモノづくりの共通の視点になりうる
さまざまな角度からユーザーに視点をそろえることで組織は成長する
ビジョンは、「なぜそれをするのか？」という本質的な目的
モノづくりのビジョンが実現したとき、その「誰か」にどんな喜びを与えることができるのか。これを具体化していく。
ユーザー中心なモノづくりでは、対象ユーザーをプロトペルソナという手法でさらに具体化する
ビジネスのサイクルとは、「価値」を提案して「ユーザー」が集まり「収益」が生まれている状態。「価値」があるから「ユーザー」があつまり、「ユーザー」が集まるからこそ「収益」が上がる
多くのユーザーに利用してもらえれば、健全なマネタイズのサイクルが生まれる
組織は大きくなればなるほど、いくつかの実行部隊＝チームに分割される
つくるべきモノが明確であれば、「役割別チーム」が理にかなった体制。つくるべきモノがの正解が見えづらい現代では、新しいユーザー価値を生み出すための共創不可欠。そこで「目的別チーム」を構成することで共創が生まれやすくなる。
チームがひとつの方向に進むためには目標設定が重要
さまざまな背景を持つメンバーが同じ視点をもって自律的に行動するためには、OKR（Objectives and Key Results）という手法が有効
OKRで重要なのは、チームがワクワクできる目標を言葉にできているかという点
現場でモノをつくるチーム全体でさまざまなルートを検討し、軌道修正を繰り返して、新しいユーザー価値に少しずつ近づいていくことができる
プロトタイピングは「検証可能な最小限のプロダクト（MVP：Minimum Viable Product）」ができたら、すぐユーザーに使ってもらい、目指す方向でなければ別のMVPを試すサイクルのこと
プロトタイピングを何度も繰り返せば、多くの失敗が積み上がり、仮設が正しいかどうかを徐々に知ることができる
こまめな軌道修正を繰り返しながら大きな目標に挑む
よいカルチャーはメンバーの自律性を育み、競争力を向上させる
「言葉」は、チームの視点をそろえるための土台となる最小単位のツール
人は多くのものごとを無意識に見て生活している。「意識して見る」ことで「気づき」が生まれる
組織を変えるときは、流れに逆らうのではなく寄り添って変えていく。川に投げ入れた小石のように組織を変える
組織の成長フェーズには「形成期」「混乱期」「統一期」「機能期」の4段階がある（タックマンモデル）
ユーザー中心な組織は、この組織成長フェーズを「ユーザー視点」という軸で統一し、共創からユーザー価値を生み出すことを目指す
一見大きく見える課題でも、注意深く観察すると小さな課題の集合であることに気づく。まずは大きく見える課題を自分ひとりで解決できるサイズにまで分解する
ユーザー中心なマインドセットを、組織で一緒に働く仲間にも向けてみる
メンバーを理解するには、相手への深い共感が必要。メンバーに影響を与えるのはあなた自身
大きな目的に軌道修正を繰り返すのは、モノづくりも組織づくりも同じ
普段何気なく行っている「無意識の振る舞い」を「意識的な振る舞い」に変えていくことがユーザー中心な組織へのムーブメントにつながる
自身の「なぜ」を発信する。ヒトは本質的に『なぜ』という背景に心を動かされる

Home¶

SurfaceのUSB-Cが認識しなかったときの対処法

結論

不具合があったときの情報

不具合時の状態

デバイスマネージャーを見ると、Surface Retimer に警告が出ていた

ドライバーのバージョン

ファームウェアのバージョン

ファームウェアの更新状態

AWSクラウドプラクティショナーのメモ

Elastic Beanstalk

責任共有モデル

AWS Artifact

TAM

AWS Shield

Standard

Advanced

AWS Direct Connect

VPCエンドポイント