CI部 佐竹です。 本日は ELB の1つ Gateway Load Balancer と Transit Gateway を組み合わせて利用する場合の重要な設定項目である「アプライアンスモード」について記載します。 はじめに Gateway Load Balancer と Transit Gateway を組み合わせた構成について Private subnet 01-1a にある EC2 からインターネットへの経路 Private subnet 02-1c にある EC2 からインターネットへの経路 非対称ルーティングとアプライアンスモード 非対称ルーティングの発生条件 非対称ルーティングの回避方法 アプライアンスモード有効時の経路 アプライアンスモードの有効化 アプライアンスモードの現状確認 アプライアンスモードの設定変更 まとめ はじめに Gateway Load Balancer

オンラインMTG（や、単なるオンラインの雑談）において、大半のメンバーが自宅などから一人ずつ接続しているときに、会議室などから複数名で参加すると、迷惑なことがある。 家メンバーと会議室メンバーの状況を比較すると、会議室メンバーには以下のような有利さがある。 遅延時間が有利 会議室のメンバー同士はいち早く情報をキャッチできるので、早く返答でき、リモートメンバーの発話チャンスを奪うことができる 視界が有利 会議室のメンバー同士は見えている範囲が広いので、ジェスチャーをキャッチアップできる。リモートメンバーには通じない 音圧で有利 会議室メンバーは話者が多いので音圧を上げて場を制圧することができる 音質面でのギャップがある 一人で接続するときには、近い距離のマイクで音を拾っていることが多いけど、会議室のマイクは話者から距離があって、音量や残響音などに差があり、聞き取りづらいので、会議室メンバーが

最近は、会社などの組織において仕事の指示をする場合に、単に上司が命令をするだけでは組織は動かないと言われています。部下に仕事をしてもらうには－－そう、まさにこの「してもらう」の気持ちこそが本質なのですが－－「命令」ではなく「依頼」の形を取ることで、お互いに気持ちよく仕事をすることができ、より良いチームとなるのです。 この世の中の流れは近年、ソフトウェアの世界にも強く適用されるようになってきました。ソフトウェアに於いても、常に、より中立的な立場での対応が求められてきています。 MySQﾚも例外ではなく、最近の修正ではレプリケーションの master-slave を source-replica と呼ぶように変更したり、blacklist を blocklist に変更したりなどの話題を目にした方も多いと思います。 これら一連のポリティカリーにコレクトな対応に今回新たに加わったのが、冒頭で紹介

Amazon CloudWatch に新しい機能、Metric Stream が登場しました！ いままでCloudWatchのメトリクスデータを、New RelicやDatadogのような外部のSaaSから参照しようと思ったら、定期的にAPIでポーリングするしかありませんでした。そのため、（この公式Blogにも書いてますが）メトリクスの種類によっては5〜10分程度の遅延が発生することになってました。 今回の機能で、CloudWatch側で更新されると同時にSaaS側へもpushされることになるため、同じタイミングで参照できるようになります。これはうれしいですね！ CloudWatch Metric Streamで出来ること 要は、CloudWatch MetricのデータをKinesis Data Firehoseに流し込むことができる機能です。 Firehose はストリームデータをS3

プログラマが気を付けることの1つは条件式に記述するときの演算子ですよね。&& じゃなくて || って書いてしまった。とか <= にすべきところを < だけにしちゃったとか。 法律の条文にも私がぶち当たった演算子があります。それが"または"です。 "または" って本当にORですか？何言ってんだ？当たり前やろ！と思うかもしれません。 結論から言うと法律の"または"(又は)　はあなたが想像する"OR"じゃないんです… 私は最初のころよくわかっていませんでした。先生に聞いても質問の意図が分かってもらえなかったし、Google先生に聞くとそのものズバリな回答もあったのですが、なんだかモヤモヤした結論でした。 法律の条文で"または"が出てきたらそれはXORです。もうこれが今回の記事のすべてなんでここで終わってもいいんですがちょっと説明します。 ORは一般的に論理和と呼ばれ、XORは排他的論理和と呼ばれ