New Microsoft Incident Response guide simplifies threat investigation | Microsoft Security Blog
Microsoft Incident Response guide highlights Our guide serves as an essential resource, meticulously structured to illuminate commonly seen, but not commonly understood, Windows Internals features in forensic investigations. Understanding these artifacts will strengthen your ability to conduct Windows forensic analysis. Equipped with this information and your new findings, you’ll be able to constr
失敗から理解した、急成長なスタートアップの開発組織の中でのマネージャの動き方｜ふと思ったを書いておく - shinden
今回も、ふと思いついたことをつらつらと書いています。 マネージャはとにかく忙しくなりやすい 全ての情報を集約し、全ての意思決定が集まる やらないことを決め、仕事を減らすことが必要 重要な課題を見つける時間を作るため 課題の解き方を考える時間を作るため 新しく生まれる課題に負けず、今やっていることをやり切るため 逆を言えば、これら全てが出来ていなかった。 日々のタスクの意思決定フローに入ってしまって忙しくしてしまった 状況変化に対して、効果的な課題を見つける時間を十分に作れていなかった 重要な課題を見つけても解き方を考える時間を作ることが出来ず、目の前のすぐ出来る必要な雑事の実行に時間を取られていた 新しく生まれる重大な課題に対処するため、中長期に向けた施策の優先度が下がってしまっていた こうなってしまった１つの原因はミドルマネージャの動きを出来ていなかったからだと考えています。マネジメント
及川卓也氏×吉羽龍太郎氏が“プロダクトマネージャーの覚悟”を分解 求められる役割のひとつ、“カネを利用する覚悟”
テーマは「プロダクトマネージャーの“覚悟”を分解する」 司会者：それでは、キーノートセッションを開始いたします。「プロダクトマネージャーの『覚悟』を分解する」と題して、Tably株式会社、代表取締役。Global Hands-On VC、Founding Partner。アドビ、Executive Fellow。クライス＆カンパニー、顧問、及川卓也さま。株式会社アトラクタ、取締役CTO、アジャイルコーチ、吉羽龍太郎さまよりご講演いただきます。 及川さま、吉羽さま、よろしくお願いいたします。 （会場拍手） 吉羽龍太郎氏（以下、吉羽）：よろしくお願いします。 及川卓也氏（以下、及川）：おはようございます。よろしくお願いいたします。 吉羽：じゃあ、さっそく始めていきたいと思います。今日は、「プロダクトマネージャーの『覚悟』を分解する」というテーマでお話をさせていただきます。実は、実行委員の方から
「理不尽な要求にはサラリーマン人生を懸けてでも『NO』と言う」 プロダクトマネージャーにとって重要な“NOと言う覚悟”
「NO」と言うのはメチャ重要 及川卓也氏（以下、及川）：逆に言うと、リソースが限られているからこそ研ぎ澄ます時に、どこを削るべきかというのができる。 吉羽龍太郎氏（以下、吉羽）：そう、それが振りで、「NOと言う覚悟」の話をしようかなと思っていたんですけど。 及川：あと、あれですよ。「未完成なプロダクトを人に使ってもらう覚悟」というところにつながってくるんですよね。 吉羽：そうそう、そうそう。そのあたりの話をしていけたらいいかなと思うんですけど。 「NO」と言うのはメチャ重要だなって。僕らはすごく気軽に「NOと言ってください」と言うんですけど、いざ言うとなったら、むちゃくちゃ難しいワードだと思います。 及川：そのとおりですね。でも、「NO」と言っていますよね。 吉羽：そう。自分の経験上まあまあ言っていると思うんですけど、けっこう慣れが必要な気もしますよね。 及川：そうですよね。私は吉羽さんと
20分で完全に理解するGrafanaダッシュボード
皆さん、Grafana使ってますか？このセッションでは、Grafanaの基本的な概念や用語を解説し、初心者の方でも迷わずに使えるようになるための知識をお伝えします。このセッション聞いた後、あなたはダッシュボードを作りたくてウズウズすることでしょう！
「AI事業者ガイドライン（第1.0版）」を取りまとめました （METI/経済産業省）
経済産業省と総務省は、生成AIの普及を始めとする近年の技術の急激な変化等に対応すべく、有識者等と議論を重ね、関連する既存のガイドライン（注）を統合・アップデートし、「AI事業者ガイドライン（第1.0版）」を取りまとめました。 （注）AI開発ガイドライン（平成29年、総務省）、AI利活用ガイドライン（令和元年、総務省）、AI原則実践のためのガバナンスガイドラインVer1.1（令和4年、経済産業省） 概要 AI戦略会議（座長：松尾豊 東京大学大学院工学研究科教授）で取りまとめられた「AIに関する暫定的な論点整理」（令和5年5月26日（金曜日））において、近年の生成AIの普及を踏まえ、既存のガイドラインに関して必要な改訂などを検討する必要性が示されました。それを受けて経済産業省及び総務省では、既存のガイドラインを統合・アップデートし、広範なAI事業者向けの統一的で分かりやすいガイドラインの検討を
継続事前学習による金融ドメイン特化LLMの構築の検証 - Preferred Networks Research & Development
この記事は、金融チームエンジニアの今城(@imos)と金融チームリサーチャーの平野(@_mhirano)による寄稿です。 概要 本稿では、ドメインに特化したLLMの構築の一環として、金融ドメイン特化のLLMの構築の検証を行いました。継続事前学習によるドメイン知識の獲得を模索し、特定のドメイン向けに専用のパラメータ数が多い高性能なLLMを提供を可能にすることを目指します。 実験では、nekomata-14bとPFNで構築した金融に特化したデータセットを用いて、継続事前学習を実施しました。 継続事前学習の結果として、金融ベンチマーク性能が向上することが確認できました。 出力の差としては、Instruction Tuningを施していないため、大きな差は見られないものの、一定の差が見られるケースもありました。 継続事前学習後のモデルは、https://huggingface.co/pfnet/n
日本語音声認識に特化したWhisperである kotoba-whisper-v1.0を早速試してみた | DevelopersIO
はじめに 昨日公開された日本語音声認識に特化した「Kotoba-Whisper」のkotoba-whisper-v1.0を試してみました。 本モデルは、OpenAIの「Whisper large-v3」を教師モデルとして使用し、蒸留（大規模な学習モデルから、同機能を持つより小さなモデルを開発する手法）を用いて開発されました。 kotoba-whisper-v1.0は、ReazonSpeechコーパスの一部である日本語音声と文字起こしのペアデータセットを使用して学習されたモデルです。学習データには、日本のテレビ番組の音声と、文字起こしたものが含まれています。具体的には、1,253時間の音声データと16,861,235文字の文字起こしデータが使用されています。 本モデルは、Pythonのライブラリであるtransformersに対応しており、短時間の音声ファイルの文字起こしから、長時間の音声フ
DevOpsDays History and my DevOps story
a keynote at DavOpsDays Tokyo 2024 https://www.devopsdaystokyo.org/
今がオープンソースから「ポストオープン」へ踏み出すとき。オープンソースの中心人物ブルース・ペレンズ氏が提案する、開発者にお金を分配できる新たな仕組み［後編］
今がオープンソースから「ポストオープン」へ踏み出すとき。オープンソースの中心人物ブルース・ペレンズ氏が提案する、開発者にお金を分配できる新たな仕組み［後編］ Bruce Perens（ブルース・ベレンズ）氏は、オープンソースの定義とオープンソースのライセンシングのルールを作り、オープンソースを世界に初めて発表した人物であり、DebianプロジェクトとOpen Source Initiativeの創設者でもあります。オープンソースにおける中心的な人物です。 そのペレンズ氏は、今年（2024年）2月にロンドンで開催されたオープンソースのイベント「State of Open Con24」の基調講演で、「ポストオープン」と呼ぶオープンソースの新たな仕組み作りを提案しました。 この記事では、ペレンズ氏がポストオープンを提案した基調講演「What Comes After Open Source?」の内
今がオープンソースから「ポストオープン」へ踏み出すとき。オープンソースの中心人物ブルース・ペレンズ氏が提案する、開発者にお金を分配できる新たな仕組み［前編］
今がオープンソースから「ポストオープン」へ踏み出すとき。オープンソースの中心人物ブルース・ペレンズ氏が提案する、開発者にお金を分配できる新たな仕組み［前編］ Bruce Perens（ブルース・ベレンズ）氏は、オープンソースの定義とオープンソースのライセンシングのルールを作り、オープンソースを世界に初めて発表した人物であり、DebianプロジェクトとOpen Source Initiativeの創設者でもあります。オープンソースにおける中心的な人物です。 そのペレンズ氏は、今年（2024年）2月にロンドンで開催されたオープンソースのイベント「State of Open Con24」の基調講演で、「ポストオープン」と呼ぶオープンソースの新たな仕組み作りを提案しました。 オープンソースは今、大手クラウドベンダがオープンソースを用いて莫大な売り上げを上げる一方で、オープンソースのプロジェクトの多
**強い**エンジニアのなり方 - フィードバックサイクルを勝ち取る / grow one day each day
# 参考資料 - https://speakerdeck.com/pokotyamu/furikaeri-2024-95ceb97e-d587-4c4b-a4ec-5e52672644f6 - https://www.1101.com/umeda_iwata/ - https://speakerdeck.com/soudai/release-small
PdMの育成・成長における「7つのプロダクトシコウ」 熟成途中のジャンルだからこそ必要な“学ぶための心構え”
「プロダクトマネージャーカンファレンス 2021」は、プロダクトマネジメントに携わる人たちが共に学び、切磋琢磨することを目的に開催されるイベントです。エムスリー株式会社からは山崎氏が登壇。プロダクトマネージャーの育成・成長のための「7つのプロダクトシコウ」について話します。 山崎氏の自己紹介、エムスリーの紹介 山崎聡氏：全国のプロダクトマネージャー（PdM）およびプロダクトマネジメントファンのみなさま、こんにちは。エムスリー株式会社で、執行役員 VPoE プロダクトマネージャーをやっている山崎聡です。今日は「非連続な環境、変化、プロダクトに対応していくためにPdMが習得するべき7つのシコウ」という話をします。よろしくお願いします。 もともと8歳からプログラミングを始めたエンジニアで、VPoEをやっています。今はアプリのプロダクトマネージャーをメインに、その他のSaaS製品も扱っています。デ
2024年Gitワークフロー再考 | フューチャー技術ブログ
春の入門祭り2024の2記事目です。 Gitは、出自としては1週間で作られたLinuxカーネルのための分散バージョン管理システムでした。当時のワークフローに合わせてパッチをテキスト化してメールに添付できるような機能だったりが備わっています。 一方で、現代のGitは、デファクトスタンダードなバージョン管理システムになりLinuxカーネル以外のアプリケーション開発で利用されています。分散バージョン管理ではあるものの、サーバー・クライアント型の使われ方をしていて、GitHubやGitLabを核にして、ローカルで作ったブランチをpushして、Pull Requestの形にして管理しています。少なくとも周りで見る限りでは、それ以外の使われ方の方が少なくなってきてます。そんなこんなで求められている使われ方が変わってきていて、それに合わせた機能がぼちぼち増えています。それを活用することで、ウェブ画面上で
Github Actions 入門 ~概要・競合比較・おすすめの書き方など~ - GMOインターネットグループ グループ研究開発本部
次世代システム研究室の Y.I です。開発/運用を行っているとどのPJでもCI/CDの構築は必要となります。自分で構築する場合はJenkins、サービスを利用するならば、CircleCIやGithub Actoinsを使うことが多いと思います。今回はCircleCIとの比較も交えてGithub Actionsについてまとめます。 2024/04/08 まとめ 今回のまとめです。 できること Github社提供のワークフローでCI/CDの実現などに利用できる Githubに対するさまざまなイベントをトリガーとして実行できる yamlファイルを記載するだけでワークフローを実現できる Marketplaceが用意されており、さまざまな機能(コンポーネントのようなもの)が提供されていてフローを構築できる 料金 Public Repositoryは完全無料 Private Repositoryは無料
Railsでメールアドレスをバリデーションする方法（翻訳）｜TechRacho by BPS株式会社
RailsのActive Recordは、意味のあるデータを確実に得られるようにするためのバリデーション機能をActive Modelライブラリ経由で提供しています。 ユーザーにメールを送信可能であることを確認する処理は、アプリケーションを正しく設定するうえで非常に重要なので、既に皆さんもUser#email属性でバリデーションを行っていることでしょう。 🔗 以下の方法ではなく 手作り正規表現や、Railsの古いAPIドキュメントにあるものを使う。 class User < ApplicationRecord validates :email, format: { with: /\A([^@\s]+)@((?:[-a-z0-9]+\.)+[a-z]{2,})\z/i }, presence: true, uniqueness: { case_insensitive: true } end
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://www.uber.com/en-JP/blog/how-ledgerstore-supports-trillions-of-indexes/
https://co-trip.jp/article/649733?page=1
新卒向けふりかえり研修
オーナーシップを持つ領域を明確にする
