A new tool that blends your everyday work apps into one. It's the all-in-one workspace for you and your team
今回の記事の内容はGitHub共同創業者のScott Chacon氏の「Pro Git」と同氏の今年の「So You Think You Know Git」(Gitがわかっているとでも思っているか?)発表をベースにしている。 コンフィグ ここでコンフィグにてデフォルトとして指定して損がないオプションをいくつか紹介します。 git rerere git rerereは"reuse recorded resolution"(記録ずみ解決方法を再利用)の略語になっている。 名の通りマージコンフリクトがどう解消されたかを記録し、次に同じようなコンフリクトが発生した際、同様の解決方法を自動的に適用するためのコマンドです。 また、基本的にデフォルトにしてもときに差し支えないため、ぜひgit config --global rerere.enabled trueを実行してみてください。 git main
この記事は Go Advent Calendar 2018 の16日目の記事です。 Golangでプログラムを書く時にログを吐くの、どうしてますか? 本記事ではログを吐く際のコツというか気にして欲しい事項と、 なぜそうなるのかを解説していきます。 一概に「ログを吐く」と言っても、 ライブラリからログを吐く場合とアプリケーションから吐く場合では 相当に事情が異なります。 TL;DR ライブラリ(パッケージ)を書く時は… まずログを吐かないことを検討しましょう。 error で返してライブラリのユーザーにログへ吐かせるかどうかを選ばせましょう。 *log.Logger を使いましょう。 デフォルトは log.Printf に対して吐き(またはそれと同等のログを吐く)、 ライブラリユーザーの設定で任意の *log.Logger に切り替えられるようにしましょう。 自前の Logger インターフ
SharePointとは SharePointはMicrosoftが提供する企業向けのサービスで、ファイル等を保存、整理、共有するためのWebサイトを作成することができるサービスです。 SharepointはMicrosoftの他のサービス(Teams、OneDrive)とも関連しており、Teamsでは、チームを作成すると自動的にSharePointのサイトも作成されます。 また、OneDriveとは機能的に似通う部分もありますが、SharePointが組織全体でのファイル共有を目的としたサービスであり、OneDriveは個人のファイルを保存、共有する目的で使用されます。 SharePointのファイル共有 Microsoftの監査ログについて説明したページでは、 SharePointの監査シナリオとして、外部ユーザーと共有されているリソースの識別について解説しています。 SharePoi
サマリー Webサイトの安全性は、サイバー攻撃の狙いを見抜く洞察力にかかっています。Loggol(ロゴル)は、Webアクセスログを自動的に解析し、隠された攻撃の足跡を発見します。あなたのサイトはいつ、誰に、どのように攻撃されているのでしょうか。 課題 Webサイトのアクセスログには、様々なセキュリティ的な情報が含まれています。しかしながら、これらのログを正しく分析せずに放置しているケースが多く見受けられます。その結果、未知の脅威やサイバー攻撃の兆候が見落とされる可能性があり、Webサイトのセキュリティを確保することが難しくなっています。また、分析を行っているシーンでも、Webのアクセスログ特有の圧倒的な量の前に、作業が追いつかない場合もあるでしょう。Loggolはこうした課題にアプローチし、Webアクセスログのセキュリティ分析を手軽に行うためのソリューションを提供します。 サービス内容紹介
Hello there, ('ω')ノ この三連休で、Twitterにアップしたデジタルフォレンジックに関係するツール等は以下のとおりで。 Windowsのイベントログについて検索するのに便利なデータベースサイトは、いろいろとあります。 https://www.ultimatewindowssecurity.com/ 日本でよく知られているのは、Elastic Stackでしょうか。 https://www.elastic.co/jp/downloads/ インシデント発生前に組織がログに記録する方法と内容、それらのログを維持する方法を明確に定義することが重要で、ログ管理ポリシーや関連する手順内で確立する必要があります。NISTがログ管理の簡単なガイドを公開しています。 https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpubli
自分が所属している会社のメンバーの教育用資料として、それなりの規模のデータを扱う時に前提として意識しておかなければいけないことをざっくりまとめたので、弊社特有の話は除外して公開用に整理してみました。 大規模データ処理、分散処理に慣れている人にとっては今更改めて言うことじゃないだろ、みたいな話ばかりだと思いますが、急激にデータスケールが増大してしまったりすると環境に開発者の意識が追い付かないこともあるかと思います。 そういったケースで参考にできるかもしれません。 弊社は基本的にAWSによって運用されているので、AWSを前提にした様なキーワードやサービス名が出てきます。後、句読点があったり無かったりしますが、ご容赦ください。 追記: 社内用の資料の編集なのでかなりハイコンテキストな内容だから誤解するかもしれませんが、これらはそもそもRDBの話ではありません。(関係無くは無いけど) 1000万オ
広告技術部のUTです。 最近はカービィディスカバリーをゆっくりやってます 概要 過去の失敗 どうやったか 仕組み 結果 まとめ 概要 昨今ではデータドリブンな意思決定を重視する企業がどんどん増えており、データを活用することにより事業成長へのインパクトを出そうとしています。 データを事業へと活用するためには、蓄積されるデータを分析するために保管しておく必要があります。 弊社も創業時からデータを蓄積し事業に活用することに力を入れてきた企業の一つであり、日々大量のログが収集されています。 またAWSアカウントを複数運用していますが、一番データ量の多い広告アカウントのS3にはペタバイトレベルのデータが保管されています。 普段何気なく使っているデータレイクとしてのS3ですが、少量であれば無視できるくらい小さいので、コストを気にせず使っておられる方も多いのではないでしょうか? そのようなS3でも巨大な
log4j_rce_detection.md log4j RCE Exploitation Detection You can use these commands and rules to search for exploitation attempts against log4j RCE vulnerability CVE-2021-44228 Grep / Zgrep This command searches for exploitation attempts in uncompressed files in folder /var/log and all sub folders sudo egrep -I -i -r '\$(\{|%7B)jndi:(ldap[s]?|rmi|dns|nis|iiop|corba|nds|http):/[^\n]+' /var/log This
久々に溜まったブログネタ放出をしようかなと、その前に下書きから掘り起こしてきた、いまさらなスロークエリ関連で準備運動です。 RDSのスロークエリ情報は当然、集計を自動化していつでも見れるようにしてあるのですが、ちょいと必要があったので、今回はあえて単発ログを集計する形に切り出したものを用意してみました。 スロークエリログの必要性 最近はNewRelicとかで、アプリケーションの処理を分別して処理時間などを集計するので、それで課題となるクエリを確認したりもします。 非常に便利な仕組みですが、アプリケーション外のジョブなどが実行したクエリは集計されないことや、負荷試験で課題を炙り出すときだとテスト環境にエージェントやライブラリを仕込む必要がある、といったデメリットとまでは言わないまでも面倒さがあります。 その点、スロークエリはサーバー側で記録するものなので、0.1秒とかでONにしておけば、対象
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く