テストの完了をゴールにしない! ~仮説検証を繰り返し、開発・QA・ユーザーが交流しながら開発することで見えてくる理想の姿~ - #RSGT2024 #DevSumi / Shift left and Shift right

テストの完了をゴールにしない! ~仮説検証を繰り返し、開発・QA・ユーザーが交流しながら開発することで見えてくる理想の姿~ - #RSGT2024 #DevSumi / Shift left and Shift right
# みんなの考えた最強のデータアーキテクチャ https://datatech-jp.connpass.com/event/258157/ ## イベント説明 datatech-jpで集ったデータエンジニアが、それぞれみんなの考えた最強のデータアーキテクチャを紹介し合うという夢のような企画が実現しました! たくさんの新しいプロダクトが群雄割拠する現在、モダンデータスタックなどという言葉も登場しています。 今こそ、どんなプロダクトを選び、どのようなデータ基盤を作れば、効率的にやりたいことが実現できるのか。 5人の猛者からおすすめの構成をご紹介いただきながら、参加者のみなさんとも一緒に考えていく時間としたいと思います。 ぜひ奮ってご参加ください! ## 発表概要 広告配信システムで発生する大量で多種多様のデータ。そして、人間の多種多様なデータへのニーズに耐えるために至ったデータアーキテクチャに
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? ほとんどの人はだれかと恊働しています。マネージャーやリーダーであるなら、この割合はより大きくなります。 筆者は、仕事の重要な要素のひとつを「進捗を出すこと」と定義しています。そして進捗を出すには、進捗をただしく把握することも重要になってきます。 しかし「進捗を把握する」と言っても、想像以上に難しいと感じる場面が多々ありました。たとえば、 進捗はどうですか? → 進行中です/〜をやっています なにか問題はありますか? → とくにないです 〜までに終わりそうですか? → たぶん大丈夫だと思います というようなやりとりは一般的なコミュニケーシ
バッチ処理は既に先人の方々が多くのナレッジを公開してくれていますが、それでもなお難しさが変わらないテーマだと思っています。 この記事は、筆者がこれまでの開発経験で気づいたバッチ処理の実装ナレッジを整理し、体系化を目指して文章にしました。 ここでの内容が、より良い課題解決に貢献できれば幸いです。 自身の断片的な思考整理(メモ書き)の延長で内容を整理したため、一部書き振りが統一されておらず、読みにくいかもしれません。ご了承ください。🙏 バッチ処理の難しさバッチ処理は難しい。 人によっては簡単なテーマかもしれませんが、自分は難しいテーマだと思っています。 「難しさの根源は何か?」を考えると、1. 考慮点が多様にあること 2. 解決する課題によって答えが大きく変わること に整理できました。 この2点は、どのソフトウェア開発にも当てはまる項目ではありますが、ことバッチ処理においては顕著に現れます。
リモートワークを本格的に始めて半年以上が経ちました。その間、試行錯誤(散財)しながらも現時点でマイベストだと思う構成が完成したので紹介したいと思います。 全体感 ビフォアー コロナ前は書斎に机と椅子はあるものの、そこにMacと24インチの外付けディスプレイが1枚あるだけの状態でした。これはこれで週に1回家で作業するくらいなら何の問題もありませんでした。 アフター しかし、毎日朝から晩まで家で仕事することになり、徐々に環境を整える必要性を感じ、今では机椅子も含めて全てをリプレイスしました。ちなみに元々暖色系の電球が好きだったのですがWEB会議でオレンジ色に映りすぎるので少し白っぽい電球にも変えています。なのでなんとなく部屋全体の色味も違うと思います。 デスク まずデスクですが、これまで横幅130奥行き60センチのものを使っていました。それまでは特に不満も感じていなかったのですが、外付けディス
黄金の方程式 FIREを目指す上で覚えておきたい黄金の方程式があります。 それは・・・ 資産形成 =(収入—支出)+(資産×運用利回り) です。 正直、世の中に溢れているお金持ちになるための方法は、この方程式を言い換えているだけだと思うくらい、この方程式はシンプルかつ正鵠を得ていると思います。 要するに、FIREを達成するために資産形成をするにあたって、3つの変数(①収入、②支出、③資産運用)しかなく、この3つだけを考えればいいのです。それぞれの変数について、以下で簡単に考えていきたいと思います。 収入について まず、収入についてです。当たり前ですが、収入は多ければ多いほどそれだけいいものです。なので、収入をいかにして多くするかということを考えることがとても重要になります。収入は、主に仕事でアウトプットした価値に対する対価としてもらえるものだと思います。そのように考えると、収入を増やすため
Microsoft SQL ServerMySQLOracle DatabasePostgreSQLSolarWinds DPAデータベース運用主要RDBMS製品の比較 2022.09.01 渡部 亮太 主要RDBMS製品の比較 – アーキテクチャ, スキーマ, データベース, メモリ Oracle ACE Proの渡部です。 主要なRDBMS製品についてアーキテクチャを比較します。 大枠を整理することが最大の目的です。細かい例外事項や拡張機能は適宜記載を割愛しています。 2022年9月時点の最新バージョンをベースに記載していますが、記載内容にバージョン依存は少ないはずです。 時間ができた時に随時追記予定です。 もし誤りを見つけた場合は、優しく教えていただけると嬉しいです。→ https://twitter.com/wrcsus4 or ryota.watabe at cosol dot
昨年までの数年間は、赤字を許容しながら売上成長を追う会社が多く存在していました。そのような会社を受容し、とにかく売上高の成長率に着目して投資判断を行っていた投資家も増えていたし、IPO時にPSRでバリュエーションを行う事例も散見されました。 しかし、今年に入ってからは投資家のスタンスがガラッと変わったと言われています。米国でのインフレや世界的な資源高等の外部要因が大いに影響しているかと思いますが、「やはりちゃんと利益を出す会社に投資しよう」という風潮が強まっているのは明らかです。実際に、IPO時に高い成長性を評価されて高い時価総額がつけられた会社の多くは、今年に入ってから大きく株価が下がっています。 そんな中でふと、「赤字を出さずに成長し続けている会社ってどんな特徴があるだろう?」と思い至りました。そこで今日は、高い利益率を維持しながら脅威的な成長を続けている会社の代表例とも言える「エムス
はじめに 弊社では、最近BEC(ビジネスメール詐欺)のインシデント対応を行いました。この事案に対応する中で、マイクロソフト社(*1)やZscaler社(*2)が22年7月に相次いで報告したBECに繋がる大規模なフィッシングキャンペーンに該当していた可能性に気づきました。マイクロソフトによると標的は10,000 以上の組織であるということから、皆様の組織でもキャンペーンの標的となっている可能性や、タイトルの通りMFA(多要素認証)を実施していたとしても、不正にログインされる可能性もあり、注意喚起の意味を込めてキャンペーンに関する情報、および実際に弊社での調査について公開可能な部分を記載しています。 *1: https://www.microsoft.com/security/blog/2022/07/12/from-cookie-theft-to-bec-attackers-use-aitm
どうも、すべての経済活動を、デジタル化したい福島です。 本日は、LayerXが賭ける「SaaS+Fintech」という新しい潮流についての解説や我々の考えを紹介できればと思います。 この記事でもあるように「SaaS+Fintech」と特に相性の良い領域である支出管理のDXも関連してくる話です。 SaaS+Fintechは第4世代のソフトウェアビジネスモデルSaaS+Fintechという新しい潮流「SaaS+Fintech」とは米国の著名VCであるa16zが2020年8月に投稿したFintech Scales Vertical SaaSという記事にて打ち出された概念です。それ以来ソフトウェアビジネスの最先端の潮流として認識されています。 https://future.com/fintech-scales-vertical-saas/ よりソフトウェアビジネスモデルの進化の歴史は、 第1世代(
はじめに ちょっとつぶやいたら思いのほか需要がありそうだったので、簡単にまとめておきます。 おことわり これを書いておけば、すべての不幸を避けられるというものではありません 提出先との関係性次第では、書かないほうがいいこともあるかも 私自身が普段提案している内容が、すべて記載されているわけでもありません(うろ覚えで書いてたり、大人の事情) これを流用しておこったすべての事項について、何らかの責任をとることはできません 本稿では請負による開発を想定しています でも共有することで、この業界の不幸が減ればいいなということでつらつら書いてみます。 他にもあるようなら、Twitterなりコメントなりで提案してもらえると嬉しいです。 前提条件を書く目的 見積・提案書通りに、実施するために必要な条件を明確にする 条件を逸脱したときに、どうなるのかハッキリさせる 上記は概ねつぎのとおり 実現が不可能になる
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く