私はシアトルのクラウドの中の人として、ソフトウェアの開発を行っているが、先日ある問題がきっかけで、技術者には試行錯誤がとても良くないということが腹落ちしたので、忘れないように書いておきたい。 先日起こった事先日起こった事は、私がシアトルから一時帰国して、普段使わないラップトップを使って日本から仕事をしている。 Application Insights というログを管理するプラットフォームがあるのだが、とても不思議なことに、Application Insights のログファイルを見ると完全に正常に動いているようにしか見えないのだが、クラウドのポータルに行くと、テレメトリが来ていない。 Application Insights のチームのメンバーが助けてくれることになったので、彼女に、Teamsで画面共有をして、「ほら、出ないでしょ？」と見せると、なんとテレメトリがポータルに来ている。その後

鍵長が長ければ長いほど、暗号文は解読しにくくなり安全になりますが、計算手順は増えるため暗号化・復号に時間がかかるようになります。 また、極端に短い鍵長の鍵を使用することはセキュリティ上好ましくなく、第三者に解読されてしまう恐れもあります。 GMOグローバルサインで用いているRSAは、公開鍵暗号の1つで、セキュリティ上の脆弱性の観点から、現在では基本的に鍵長2048bit以上のRSA鍵を使用するよう推奨されています。 SSL暗号化通信の流れ クライアント側から通信のリクエストがあると、まずサーバ側から「公開鍵」が送付され、それを元にクライアント側で「共通鍵」が生成され、サーバ側にも送られます。 次にクライアント側が生成された共通鍵を使って暗号化した個人情報や決済情報などのデータをサーバ側に送り、サーバ側は事前にクライアント側から送られた共通鍵を使ってデータを復号します。 接続要求 クライアン

◆ Live配信スケジュール ◆ サイオステクノロジーでは、Microsoft MVPの武井による「わかりみの深いシリーズ」など、定期的なLive配信を行っています。 ⇒ 詳細スケジュールはこちらから ⇒ 見逃してしまった方はYoutubeチャンネルをご覧ください 【6/19開催】Kong Community Japan Meetup #4 本イベントでは、Kong Inc. のVP of ProductであるReza Shafii氏もプレゼンターとして参加。当社からはアーキテクト マネージャーの槌野の登壇が決定！参加無料です!! https://column.api-ecosystem.sios.jp/connect/kong/1081/ 【6/21開催】開発者目線でのSBOMとの向き合い方 SBOMの導入から開発者がSBOMの作成・管理を自動で行っていくための方法（デモ）を紹介します。

Nexus, Scrum@Scale, LeSS, SAFeなど、スクラムチームをスケーリングする手法はたくさん存在する。 しかし、アジャイルコーチなどに、「スクラムをスケールするにはどうすればいいですか？」と聞くと「そもそもスケールをするな」と言われることもある。ぼくも基本的にはこれに同意する。 コンパクトな職能横断型のチームで、短いサイクルで高速に、安定したペースで開発をする。これをずっと続けることができるのならばそれが一番良い。 なのになぜ、人々はスクラムチームをスケールしたくなるのか。なぜこんなにたくさんのスケーリング手法が存在するのだろうか？ そういうことを考えてみた。 最初から人がたくさん必要な場合 そもそも最初からスケールされたチームでやりたいパターンがある。大規模な開発などはそうだろう。 小さくローンチして、インクリメンタルにユーザーフィードバックを受けながら開発できれば理

iOS14からユーザートラッキングに用いられている端末の広告識別子IDFA取得のオプトイン/オプトアウトの選択をユーザーに求めることが必須になります。アプリが取得するプライバシーポリシーの提出必須化と同じく大きな変更ですが、開発中のアプリが該当するか調べる時にFirebase AnalyticsとFirebase Crashlyticsのみを使っていて広告系のSDKも利用していない場合何の対応も必要ないかが心配になったので調べていました。 App Tracking Transparency | Apple Developer Documentation iOS14で必要になるユーザートラッキングについての対応 AppleからUser Privacy and Data Use というドキュメントが公開されました。ユーザーがアプリのプライバシーポリシーをダウンロード前に確認して、アプリが収集す

シャットダウンが延期されました 読み取り専用として存続します JCenter のシャットダウンについては2022年2月1日へ延期になりました。 https://jfrog.com/blog/into-the-sunset-bintray-jcenter-gocenter-and-chartcenter/ UPDATE: To better support the community in this migration, JFrog has extended the JCenter new package versions submission deadline through March 31st 2021. To clarify, the JCenter repository will keep serving packages for 12 months until February