印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます Microsoftは米国時間11月2日、新しいセキュリティツール「Microsoft Defender for Business」のプレビュー版を近日中にリリースすると発表した。 Microsoft 365製品マーケティングマネージャーのJon Maunder氏はブログ投稿の中で、同ツールを「エンタープライズ水準のエンドポイントセキュリティを従業員数300人以下の組織に提供するために特別に設計された、使いやすく費用対効果の高いソリューション」と説明した。 リリース日以降、組織はDefender for Businessのスタンドアローン版をMicrosoftから直接購入できるようになる。使用料は1ユーザー当たり月額3ドル（約340円）だ

普通に書いたdiffは、関心がさまざまなところに散らばっていたたり、書きかけだったりで、意味のまとまりがないもので、それを整形して、説明を書いたものがPull Requestであり、コードレビューは、そのまとまりごとに、他人から見て理解可能であるという承認する行為、という理解をしていた。 なので、レビューを通すことは、動くことに賭けて、以後、動かなかったら責任を取る、みたいなイメージはあまり持っていなかった。 レビュワーの責任をどこまでと規定するか考えて、責任が大きい順に並べていくと レビューを通した以上、以後は私の責任です、という態度 職人魂を感じる 見たところよさそうに思いました、という態度 通りすがり風情を感じる まったくの無責任なので、工数最小化のために何が来てもapproveする、という態度 やっつけ仕事 かるぱさんのチームでは1になっているのかな(追記)こうなっている、というこ

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.

こんにちは、CX事業本部 IoT事業部の若槻です。 今までは有効期限を無期限でしか発行できなかったGitHubのPersonal Access Token（アクセストークン）ですが、2021/07より任意の有効期限を設定できるようになっていました。 Expiration options for personal access tokens | GitHub Changelog 期限付きのトークンを発行してみる https://github.com/settings/tokens/newより新規アクセストークンの発行画面を開きます。 [Expiration]メニューがありますね。既定の有効期限は30日間となっています。 リストメニューを開くと、有効期限は下記が選択可能となっています。 7日間 30日間 60日間 90日間 Custom No expiration（無期限） Customを選択

図1: QUICの無効化は待ってくださいQUICを無効化？！“Googleが遅く感じるので、QUICを無効化する” そのようなTIPSが散見されます。数年前から見ていましたが、QUICがトレンドになったのと同時に、再び目立ち始めたと感じています。IPv6が普及し始めた時期もそうでしたが、新しいプロトコルの出現時には、決まって現れる文言です。 問題に直面する利用者にとっては切実であり、無効化は間違った解決手段とは言いません。しかしエンジニアならば無効化する前に、原因を探求しなければなりません。 HTTP3/QUIC と HTTP2/TCP どちらが優先？QUICの無効化とは、TCPだけを利用する選択と言えます。はじめにQUIC, TCPの両者が使えるとき、どのように使い分けるのか見ていきます。 ある、HTTPSスキームのURL https://www.example.com/ があったとき、

HTTPS通信内の脅威をZscalerが分析、1年間で4倍以上に増加：なぜテクノロジー業界が狙われるのか ZscalerはHTTPS通信内でブロックした脅威を分析した年次レポート「State of Encrypted Attacks Report」を発表した。それによるとHTTPS通信に潜む脅威は2020年から314％増えた。同社によればテクノロジー業界が主な攻撃対象となっている理由があるのだという。 Zscalerは2021年10月28日（米国時間）、HTTPS（Hypertext Transfer Protocol Secure）通信内でブロックした脅威を分析した年次レポート「State of Encrypted Attacks Report」（暗号化された攻撃の現状）を発表した。それによるとHTTPS通信に潜む脅威が2020年から314％増え、ファイアウォールによる従来型セキュリティ

用語 レビュアー 対象となるコードをレビューする人のことを指します。 レビュイー レビューを受ける人、つまりレビューする対象のコードを書いた人のことを指します。 tl;dr アプリケーション開発業務におけるコードレビューはコードの正しさや質そして一貫性を保ち、それらと同時にコードに対するチームとしての共有知を作り上げる良いプラクティスだと思います アプリケーション開発チーム内でのコードレビューにおいてPull Requestを使ったレビューのスタイルは一般的ですが、Pull Requestの承認は実際にはほとんど意味がないのではないでしょうか？ ほとんど意味がないにも関わらず、承認の有無によって業務フローが左右されることでそれが権威的に扱われてしまいオーナーシップを希薄化させ、結果的にコードレビューのコストが増加したりそれを行う目的を見失ってしまっていることはないでしょうか？ Pull R

このサイト r7kamura.com の実装言語をRubyからRustに変えてみた。 アプリケーションの概観 このサイトには、大別すると次の6種類のルーティングパターンがある。 GET / トップページ GET /articles/:article_id 記事ページ GET /feed.xml RSSフィード GET /links リンク集 GET /sitemap.txt サイトマップ (Google Search Console等が利用する) GET /* その他の静的ファイル (CSSや画像など) Rubyの実装では、適当なRackアプリケーション + rack-captureという構成で、Webアプリケーションとして実装しつつGitHub Pagesのために静的ファイルも吐き出せるという仕組みになっていた。 Rustの実装もほぼ同じで、適当なHTTPサーバー + 適当なHTTPクラ