KubernetesのPodやネットワークをわざと落としまくってカオスエンジニアリングのテストができる「Chaos Mesh」がバージョン1.0に到達 Kubernetes上のシステムに対してわざと障害を発生させることで、システムの耐障害性のテストを行うためのソフトウェア「Chaos Mesh」がバージョン1.0に到達したことを、Chaos Meshの開発チームが明らかにしました。 Proud to announce the GA of #ChaosMesh 1.0: Powerful chaos support Visual chaos orchestration Enhanced observability Safe and controllable chaos Learn more: https://t.co/ynx3KIMzIS#chaosengineering @CloudNat

Adopt ? We feel strongly that the industry should be adopting these items. We use them when appropriate on our projects. Trial ? Worth pursuing. It is important to understand how to build up this capability. Enterprises should try this technology on a project that can handle the risk. The Astro framework is gaining more popularity in the community. One of our teams has used Astro to build content-

www.ntt.com これを見てちょっと最近の流れと違うなぁとしみじみ思ったので全力で反論してみる。。 僕自身は８１年代生まれ、小学校6年生のときにPC98シリーズのN88Basicで独学でBasicから入って、中高とDirectX使ってゲーム作ったりして、大学のときにバイトで実務のプログラムを初めて〜、と何故かまぁ小さいながらも経営者として傍らまだ炎上した案件とかに入って消火活動に勤しんでたりしてる。まぁ後半はどうでもいいけど、この世代では日本海外とわず独学で勉強するのは至って普通だと思う。クロアチアだと勿論PC98じゃなくてAmigaとかドイツ製のPCが主流のよう。 で、一方で最近の新入社員たちを見てると最初からスクールに通って、大学で授業を真面目にうけて、インターンでメンターに面倒を見てもらって、バイトも常にメンターがいつつ実務に関わってって流れが普通。プログラミングは常に勉強とし

https://pipecd.dev/docs/faq/#4-what-are-the-differences-between-pipecd-and-fluxcd https://pipecd.dev/docs/faq/#5-what-are-the-differences-between-pipecd-and-argocd Getting Started 「せっかくなので、軽く GitOps の雰囲気が感じられるチュートリアルをやってみましょう」 バージョン kubectl: 1.18.0 eksctl: 0.29.2 Kubernetes: 1.17.9 Helm: 3.3.4 alias k="kubectl" alias ek="eksctl" Kubernetes クラスタを作成 $ ek create cluster \ --name test-kim \ --version

Android11でワイヤレスデバッグという新しい機能が追加されました。 今までAndroid実機をADB経由で操作する際、USBケーブルで繋ぐ必要がありましたが、それをWi-Fi経由で接続できるようになった機能です。 参考 Google Developers Japan: Android 11: Developer Preview 3 機能と API の概要  |  Android デベロッパー  |  Android Developers ワイヤレスデバッグの有効化 ワイヤレスデバッグは開発者オプションから有効化できます。 開発者オプションが表示されない方は、デバイスの開発者向けオプションを設定する  |  Android デベロッパー  |  Android Developers を参考に開発者オプションの表示を有効化してください。 開発者オプションを開くと、デバッグメニューに表示さ

事業共創プログラム　OPEN HUB for Smart World 未来をひらく「コンセプトと社会実装」の実験場 OPEN HUB for Smart Worldは、社会課題を解決し、わたしたちが豊かで幸せになる未来を実現するための新たなコンセプトを創り、社会実装を目指す事業共創の場です

この例に関する質問への回答を補足の項に記載しましたので、より良い理解のためにご参照ください。 1.3 モデル構造 トランスダクションモデル(ある文章を他の文章に変換するモデル(翻訳など))において主流なのは以下のようなエンコーダ-デコーダモデルである。 エンコーダ: 入力の文 $(x_1,\ldots,x_n)$ を $\boldsymbol{z}=(z_1,\ldots,z_n)$ へ変換 デコーダ: $\boldsymbol{z}$ から単語 $(y_1,\ldots,y_m)$ を出力。 ただし、1時刻に1単語のみで、前時刻のデコーダの出力を現時刻のデコーダの入力として使う。 Transformerは基本的な大枠はエンコーダ-デコーダモデルでself-attention層とPosition-wise全結合層を使用していることが特徴。 つまり、以下の3つ(+2つ)のことが分かればモデル

エンジニアの辛い仕事を消す本かも（多分） 2014年の秋にリクルートに転職してから何社か経て今も自社サービスのエンジニアとして働いてるマンです. リクルートに入ったとき, そしてその後の転職先*1などなどで, 社内外問わずのコミュニケーションの辛さ. 社内調整, 顧客折衝etc... コードじゃなくて, ドキュメントを書く仕事の辛さ. プレゼンテーション・説明そのもの. 技術わかんない上司に説明(ry*2 みたいな経験をたくさんしました&これはエンジニアをやってたら誰でも直面する事態かなと思います, 自社サービス企業だろうがSIer/受託開発の企業だろうが. そもそも, 昔の調査にもそんな雰囲気ありますし, おそらく今もさほど変わらないでしょう. ...ということを, 前回のブログの執筆中および反響で改めて思い*3, そういえば自分はこの辺, 元々ITコンサルタント*4だった時に学んだこと