今年だけで3台目。Wi-Fi 7検証目的で買った最新ノートPCは今度こそ320MHz幅でつながるか？【イニシャルB】
DMM.comの施策から見る、事業をむしばむ「技術負債」への処方箋──リファクタリングの「言語化」でインシデントを予防
見積もりやリカバリーの「失敗」は必ず起こる このような事態が発生するのはなぜだろうか。石垣氏は以下の2点を挙げる。 「失敗は見積りの失敗」であるという認識の欠如 隠された失敗が明るみになり、「詰んでいる」状態であること 1．について石垣氏は、マーティン・ファウラー氏による言葉を引用しつつ、「プロジェクトが失敗するのは、そもそもの見積もりが失敗しているためだ」と話す。さらには「見積もり時点での計画工数が大きくなるほど、実績との乖離が大きくなる傾向がある」というIPAのデータも示した。 そのうえで石垣氏は、「見積もりが失敗するのは、プロジェクト初期の段階で多くの約束事を決めてしまうためだ」と指摘する。有名な図である「不確実性のコーン」が示すように、プロジェクトの初期は不確実性が非常に高いため、焦ってリカバリー策を講じたところで見積もりのズレは取り戻せないのだ。 初動のズレは「見積もりの失敗」で
チームに無能がいなくなる『メンバー全員で公式ドキュメントを読みあわせる』に感銘をうけた話。 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? これは、同じエンジニアである妻から聞いた話なのですが、彼女の案件で「メンバー全員で公式ドキュメントを読みあわせる」という取り組みがあったそうです。 で、この方法「チーム全体にとって大きなメリットがあるんじゃないか？」と思ったので、共有させていただきます。 「誰も知らない」から「みんな知ってる」に 私は開発職なので、めずらしいことなのかそうではないのか判断がつかないのですが、その案件では、導入対象の製品について詳しい知識を持っているメンバーが一人もいなかったというのです。 誰もその製品をさわったことがなく、とりあえず強そうなメンバーを入れ
シニアなエンジニアの振る舞いとリーダーシップについて - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 自分はこれまでメンバーレベルのポジションとしてしか働いたことがありません。 ただ、自分と比較して必ずしも技術的に優れているわけではない同僚がインパクトの大きい仕事をしたり、上司やマネージャーの信頼を得たりしていくのを見た経験から、 自分がよりインパクトの大きい仕事をしていくためにはどのような部分が足りていないのかを考えるために、色々と調べたり、考えたり、まとめたりしてみました。 シニアなエンジニアについて ここでは、グレードの高いエンジニアや抽象度の高い仕事を日常的に行っているエンジニアをシニアなエンジニアと呼ぶことにします。 シニアな
アジャイル型開発における未完成の責任 東京地判令3.11.25（平30ワ25117） - IT・システム判例メモ
アジャイル型でアプリ開発を進めたところ、完成に至らなかったことについて、ベンダの不完全履行、プロジェクトマネジメント義務違反等が主張されたが、いずれも否定された事例。 事案の概要 eスポーツ事業の企画・運営等を行う原告（Ｘ）は、ゲーマー向けソーシャルアプリの開発を構想し、開発ベンダである被告（Ｙ）との間で、平成28年8月18日に、ゲームに参加する人をマッチングし、参加者同士がコミュニティを形成するソーシャルメディア機能を有するソフトウェア（本件ソフトウェア）を開発する契約（本件契約）を締結した。対価の額合計は、2450万円。その支払は1000万円、1000万円、450万円の3回にわけて行われることとされ、最後の450万円は、納品物を納入後に支払うこととなっていた。 本件契約の締結前には、Ｘは、検収に合格しなかったら、支払済みの代金を返金する条項を設けることを求めたが、Ｙは「返金を想定してお
組織に自動テストを書く文化を根付かせる戦略（2024秋版） / Building Automated Test Culture 2024 Autumn Edition
2024年10月18日 日本SPIコンソーシアム（JASPIC） ソフトウェアプロセス改善カンファレンス2024
バグ密度・テスト密度に依存しない品質保証への挑戦 | NTTデータ
キーワードで探す カテゴリで探す 業界トレンド／展望 技術トレンド／展望 事例 サービスで探す コンサルティング CRM（Salesforce） ERP（SAP/Biz∫） 顧客接点・決済 カーボンニュートラル SCM・ロジスティクス 電子申請 データ＆インテリジェンス 生成AI アプリケーション開発・管理 データスペース ブロックチェーン 量子コンピュータ・イジングマシン デジタルツイン IoT ロボティクス・RPA クラウド ネットワーク データセンター サイバーセキュリティ アウトソーシング 業種で探す 金融 官公庁・自治体 医療・ヘルスケア 防災・レジリエンス 食品 流通・小売 モビリティ 製薬・ライフサイエンス 食農・農業 製造 通信・放送 電力・ガス・水道 建設・不動産 個人のお客様向け 教育 トピックで探す Foresight Day サステナビリティ キーワードで探す カテ
自然言語処理を役立てるのはなぜ難しいのか
PFNの海野裕也が2024/10/15に東大大学院「自然言語処理応用」にゲスト講師として登壇した際の講義資料です。
ついにBitNet Llama8Bが登場! CPUのみで爆速推論するLLM,BitNet.cpp｜shi3z
科学の世界では、それまでの常識が覆ることを俗に「パラダイムシフト」と呼ぶ。 しかし、もしもAIの世界にパラダイムシフトという言葉があるとしたら、今週の人類は一体何度のパラダイムシフトを経験しただろうか。 そのトドメの一撃とも言えるのが、BitNetのLlama8B版だ。 Lllama-8B構造で学習された最初のBitNetであり、全てを変えてしまうゲームチェンジャーでもある。CPUのみで秒間5-20トークンを出力する。超強力なLLM推論エンジンの出現だ。 BitNetとは、そもそも1.58ビットに相当する情報量で、本来は4ビット以上必要な大規模言語モデルの計算を劇的に高速化する技術である。 LLMの推論には通常は巨大な浮動小数点数(8ビットから16ビット)の、大量の乗算(掛け算)が必要なため、GPUなどの特殊な半導体を必要としていた。特にNVIDIAのGPUがこの目的にマッチしていたので今
Datadog APMの設定ミスのせいでメモリリークしていた話 - LIVESENSE ENGINEER BLOG
こんにちは、かたいなかです。 最近、転職会議のあるサーバで発生していたメモリリークについて調査する機会がありました。 今回の記事ではメモリリークをどのように調査したか等をまとめます。 ⚠️:2024/10/21追記 当初、デフォルトですべてのrakeタスクに対しての計装が有効と記載していました。しかし、実際にそのような挙動をするのはdd-trace-rbがv1.3.0より前のバージョンの場合のようです。それ以降のバージョンでは計装するrakeタスクを明示的に指定する必要があるため、デフォルト値に起因する設定ミスが起きにくくなっているようです。 はてなブックマークのコメントで教えていただいた、部分フラッシュのオプションについての記述を追加しました。 TL;DR 長時間稼働するrakeタスクのDatadog APMによる計装は避けましょう。 rakeタスク内の処理でのspanが、rakeタスク
コードを複雑化させないために意識したいパターン集 - Qiita
はじめに はじめはシンプルだったコードも積み重なる機能追加や変更、バグ修正等などによって、徐々にコードが複雑化し、修正コストの増加や品質低下に繋がります。 これはある程度の規模を持つプロダクトでは至って自然なことであり、そうならないようにするためには意識して設計しなければいけません。 ここではコードを複雑化させないために普段意識している手法やパターンを紹介します。(DDDやClean Architecture成分多め) また本記事で登場するコードはJavaですが、Javaを知らなくてもある程度は理解できるかなと思います。 あと、割とまとまりもなく幅広い範囲でダラダラと書いてしまい長いです... 以下項目ごとのアンカーリンクとなっておりますので興味がある項目のみどうぞ。 getter/setterがよくない理由 デメテルの法則と尋ねるな命じよ(Tell, Don't Ask!) 関心の分離
Ruby LSPアドオンシステムの概要（翻訳）｜TechRacho by BPS株式会社
カンファレンスニュース Ruby LSPチームは、11月にChicagoで開催されるRubyConf 2024に参加します。Ruby LSPやRuby開発者の経験について幅広く話してみたい方は、ぜひご参加ください。 🔗 概要 本記事では、Ruby LSPのアドオンシステムを紹介し、これによって解決される問題や、アドオンシステムのアーキテクチャについて解説するとともに、アドオンのサンプルもいくつか紹介し、今後のアドオンエコシステムでRuby開発エクスペリエンスを強化する構想についても共有します。 🔗 Ruby LSPの概要 Ruby LSPは、言語サーバー（language server）の実装であり、Rubyコードを効率よく書けるようにすることを目的として設計されています。Ruby LSPは、エディタに機能を提供するために静的コード解析を利用します。ただしRubyエコシステムでは動的プ
RBS::Inline を導入してみました (1) | Webシステム開発／教育ソリューションのタイムインターメディア
RubyKaigi 2024 の Embedding it into Ruby code というトークで RBS::Inline が発表されてから、4ヶ月が経ちました。 その間にいくつかの導入事例、利用記事を見かけてきましたが、タイミーさんの 前編：YARD から rbs-inline に移行しました という記事を読んで、重い腰を上げて RBS::Inline を導入することにしました。 この記事では、RBS::Inline を導入するにあたってハマったところや工夫が必要だった箇所について紹介します。 通常の導入や文法についての説明は省きますので、そのあたりは 公式の Syntax guideやタイミーさんの記事を見てください。 どの構文を選ぶのか RBS::Inline ではコメント形式で型情報を記述します。 attr_* アクセサの型や定数の型、メソッドの型など、さまざまなものに型コメ
翻訳: Parse, don’t validate (バリデーションせずパースせよ)
これまで、型駆動設計を実践することが何を意味するのか、簡潔でシンプルな説明を見つけるのに苦労してきました。誰かに「どうやってこのアプローチを思いついたのですか？」と尋ねられることが多いのですが、満足のいく答えを出せないことがよくあります。そのアイデアが突然のひらめきで浮かんだわけではなく、正しいアプローチを空から引っ張り出す必要がない、反復的な設計プロセスがあると分かってはいるのですが、そのプロセスを他の人にうまく伝えることができていませんでした。 しかし、およそ1ヶ月前、JSON を静的型付け言語で、そして動的型付け言語にパースしたときに経験した違いについてTwitter上で振り返っていた時、ついに私が探していたものを見つけました。そして、そのスローガンはたった3つの英単語で表せます。 Parse, don’t validate (バリデーションせずパースせよ) 型駆動設計のエッセンス
問題を"放置"さえしなければちょっとずつよくなっていくんですよ - Konifar's ZATSU
7月くらいに入社した同僚氏は「問題を放置しない」が口癖で、半ば麻痺している痛いところを突いてはすぐに何かしらアクションに移して状況を変化させている。ハイレベル問題解決ブルドーザーである。 「これは放置しないほうがいいですね」、「放置しないほうがいいのでやりましょう」といった感じで話してくることもあれば、「これどうします？放置しますか？」のように聞いてくることもある。見て見ぬふりをしたり、なんとなく結論が曖昧な状態のままにしておくことを"放置"と言っているらしい。ややこしい言い方をすれば、"今は (いつまで) 放置する"と決めたのであればそれは放置してはいないということなのだそうだ。 先日、彼が会議中にボソッと「問題を放置さえしなければちょっとずつよくなっていくんですよ」と言っていて、たしかになあとしみじみ噛み締めてしまった。 何かチャレンジをしていれば問題が多々発生するのは当たり前ではある
エンジニア採用のパラダイムシフト - laiso
エンジニア採用の状況は地域によって大きく異なる 最近視聴した2つのコンテンツが、同じソフトウェアエンジニア採用の話題を取り扱っているにもかかわらず、その内容が両極端で非常に興味深かった。 ひとつは「エンジニア採用必勝法・これだけでわかるDevRel入門」という動画で、もうひとつは「最近カナダで就職したエンジニアと一緒に北米就活の攻略法を語る」というポッドキャストのエピソードだ。 エンジニア市場と企業の採用戦略は地域や業界によって異なるが、ここで話されている東京と北米（バンクーバー）では顕著な違いが見られる。 東京を中心とする日本ではテック企業間での人材獲得競争が激しく、特にエンジニアが不足しているため、採用広報の役割の重要性が増し、DevRelといった呼び名で施策が実行されている。 一方、カナダでは、永住権を持たない外国人労働者が職を得るハードルが高く、求職者の競争が激しい現状が実際
詰め込み型のソフトウェアプロダクト開発は誰も得しない｜mtx2s
チームのキャパシティを超える要求を抱えたプロジェクトが、なんの問題もなく完了するはずがありません。なんとか作り上げられた機能は、表面上は要求通りでも、どこかぎこちなさを感じます。ユーザー体験が悪く、それがユーザー価値を押し下げ、ビジネス価値を削り取ります。触るたびに新しい欠陥も見つかるかもしれません。内部品質も最低です。それが今後の追加開発の足を引っ張ることにもなるでしょう。そして、ただ消費するような働き方によって、チームは成長も達成感も感じられず、疲弊します。 詰め込み型のプロジェクトは、誰にとっても利点がなく、そのうえ持続不可能なやり方なのです。 「詰め込んでもなんとかなる」という楽観主義詰め込み型のアプローチは、組織内でプラクティス化しやすいプロジェクト計画手法です。この手法で完了したプロジェクトは、一見すると、上手くいったように見えます。多少の遅延があったとしても、概ね一通りの機能
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
面倒な月末処理はAIに丸投げダー！Microsoft 365 Copilotの自動化エージェントが登場へ
エンジニアの「センス」とは何か / What is the sense of engineers
アップル、A17 Proチップ採用の新型「iPad mini」
