いらないダッシュボードやデータはなぜ作られ続けるのか｜データ分析とインテリジェンス
無駄な抽出で時間を浪費したくないいらないダッシュボードを作らないようにしようは多くの人に読んでもらったようだ。この時は抽出者側としての心がけ、みたいなのを書いたのだがそれだけではいらないデータが作られるのを止めることはできない。 そこで、いらないデータが作られてしまう原因についての全体を考えてみた。ダッシュボードを作ることが活動の中心の人は「いらないダッシュボード」として読んでもらってかまわない。 前提として、抽出担当者が別にいて役割分担とコミュニケーションが発生する場合について考える。依頼者が自分で抽出して分析する場合はいらないデータを作るコストは当人の責任の中で完結するので、それは抽出ではなく「より効率良く分析を行うにはどうしたらいいのか」という別の問題として捉えることにする。 依頼者側の問題目的がないか、あっても正しくない目的がなければただデータを見ているだけであり、無駄である。 目
コンテナランタイムを自作した - zebian.log
コンテナの仕組みを勉強したかったため、Goでコンテナランタイムを自作した。雑実装だし未実装の機能もたくさんあるが、ある程度形になってきたため現状をまとめる。 リポジトリ github.com kombu/dashi - 自作コンテナランタイム kombu/nimono - eBPFを利用したシステムコールロガー kombu/yaminabe - dashiとnimonoを利用したマルウェアサンドボックス プロジェクト名から和の雰囲気を感じるが、これはリポジトリ名をkombu（昆布）にしたかったため、せっかくなら今回は和風で固めようと思ったから。趣があっていいんじゃないでしょうか。 dashiが自作コンテナランタイムだが、nimonoとyaminabeは実験的な要素で、セキュキャン2023でコンテナを使ったマルウェアサンドボックスを実装した経験があり、今回はその再実装を自作コンテナランタイム
Terraform 1.9 の新機能紹介 | DevelopersIO
Terraformのversion 1.9が2024年の6月26日にGAになりました。1.9の新機能を見ていきましょう。 変数のvalidationで色々参照できるようになった 変数にはvalidationを実装することができます。例えば以下のようなものです。 variable "aws_account_id" { type = string description = "AWS Account ID" validation { condition = can(regex("^[0-9]{12}$", var.aws_account_id)) error_message = "Invalid AWS accountID." } } これはAWSアカウントIDが格納されるのを想定した変数です。AWSアカウントIDは必ず12桁の数字ですので、そうでない場合はエラーにしています。 上記例では c
「『GitHub Copilot』は人を置き換えるのではなく、支援する存在」 GitHubが説明
生成AI（人工知能）の用途として、与えられたプロンプトに応じてソースコードを生成したり補完したりするAIコードアシスタントに注目が集まっている。GitHubは2024年5月中旬に開いた記者説明会で、同社のAIコードアシスタントである「GitHub Copilot」の現状やAI法規制を巡る同社の貢献を説明した。 登壇したのは、GitHub Japanの日本・韓国エンタープライズ担当シニアディレクターである角田賢治氏、GitHub COO（Chief Operating Officer：最高執行責任者）であるカイル・デイグル（Kyle Daigle）氏、そして同CLO（Chief Legal Officer：最高法務責任者）のシェリー・マッキンリー（Shelley McKinley）氏の3人だ。 まず角田氏が、日本市場でのGitHubの利用状況について説明した。現在、300万人を超える開発者が
開発者が安心して実行可能なSQL実行基盤の導入と運用 #ベッテク月間 - LayerX エンジニアブログ
こんにちは！バクラク事業部 Platform Engineering 部 DevOps チームの id:sadayoshi_tadaです。 7月はエンジニアブログがたくさん出る #ベッテク月間です。今後も記事が出ますので、どんな記事がでるのかこちらのカレンダーからよければチェックしてみてください！7/2にSRE Lounge#17にて開発者が安心して実行可能なSQL実行基盤の取り組みという発表させていただきました。この記事では当該発表で時間の関係で触れきれなかった内容や補足を行っていきます。 従来のデータベースのデータ変更における課題 課題に対する解決策の検討 Bytebaseの利用にかかるコスト Bytebaseの導入及びデータ変更のフロー整備 データ変更のフロー整備 Bytebase導入後の変化 データ変更オペレーション上の課題 まとめ 最後に 従来のデータベースのデータ変更における課
Webサービス公開前のチェックリスト
個人的に「Webサービスの公開前チェックリスト」を作っていたのですが、けっこう育ってきたので公開します。このリストは、過去に自分がミスしたときや、情報収集する中で「明日は我が身…」と思ったときなどに個人的にメモしてきたものをまとめた内容になります。 セキュリティ 認証に関わるCookieの属性 HttpOnly属性が設定されていること XSSの緩和策 SameSite属性がLaxもしくはStrictになっていること 主にCSRF対策のため。Laxの場合、GETリクエストで更新処理を行っているエンドポイントがないか合わせて確認 Secure属性が設定されていること HTTPS通信でのみCookieが送られるように Domain属性が適切に設定されていること サブドメインにもCookieが送られる設定の場合、他のサブドメインのサイトに脆弱性があるとそこからインシデントに繋がるリスクを理解してお
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
AWS ECS and Loki integration
机に後づけできるクッション入りアームレスト
DMMプラットフォームにおけるTiDBの導入から運用まで
