【翻訳】技術的負債という概念の生みの親 Ward Cunningham 自身による説明 - t-wadaのブログ
システム開発の世界において「技術的負債（Technical Debt）」は繰り返し話題になり、しばしば炎上しています。 技術的負債という概念の生みの親は Ward Cunningham （ウォード・カニンガム）です。彼は 1992 年にオブジェクト指向プログラミングの国際カンファレンス OOPSLA '92 の Experience Report でコードの初回リリースを負債に例えました（"Shipping first time code is like going into debt"）。 Ward Cunningham はソフトウェアの世界に多くの貢献を果たしてきました。Wiki の発明者であり、XP と TDD の父 Kent Beck の師匠のような存在であり、建築の世界の「パタン・ランゲージ」を Kent Beck と共にソフトウェアに輸入した人であり、「アジャイルソフトウェア開
0063 号 巻頭言
DDD を理解したいあなたのための DDD 入門以前 Rubyist Magazine 63 号をお届けする。 突然のお知らせで恐縮だが、日本 Ruby の会の主たる事務所が東京から北海道に移転した。それもあってあまりまとまった時間がとれず、11 月のうちに書くはずだったのが気がつくと 12 月も半ばを過ぎていたので、今回は以前書きかけていた文章を発掘してお茶を濁したい。 Ruby とは直接関係がなくて恐縮だが、Ruby に限らずソフトウェア開発では現在でもちょくちょく話題になることがある、DDD についての話である。 ドメイン駆動設計こと DDD は 2020 年代のソフトウェア開発でもよく話題にされるが、率直に言うとストレートにポジティブな評価が行われているとは言い難い。 どちらかというと、ある種マニアックで、対象分野が制限されており、また初心者にはとっつきにくいところがある手法と思わ
「コーディングは設計か製造か」という考え方の違い - 思考と現場の間で
以前の職場では、完全なウォータフォールをやっていたとは言い切れないのですが、基本的に設計→製造→テスト→リリースという1回の流れでやっていたため、どちらかと言うとウォータフォールだったと思っています。その職場では、コーディングを「製造」と読んでいました。当然、設計というのは「設計書を作る」ことによって行われることであり、その設計書に基づいてコードというアウトプットを行うわけですので、コーディングは「製造」と考えるのは当然だと思います。 アジャイル開発を始めて感じた違いは多くありましたが、その一つはコーディングの考え方の違いです。以下はXPのプラクティスです（Wikipediaより）。 テスト駆動開発 ペアプログラミング リファクタリング ソースコードの共同所有 継続的インテグレーション YAGNI これらの共通的な基本的な考え方は、「変えることを前提としている」という点です。私は製造業で働
メテオフォール型開発 - 実践ゲーム製作メモ帳2
今日は、日本の代表的なソフトウェア開発手法について紹介しよう。 その名も、メテオフォール型開発である*1。 第一節 通常のウォーターフォール型開発におけるプロジェクトはこのような形を取るが、 メテオフォール型開発ではこのような形が取られる。 そしてこうなる。 これはアジャイル型開発手法におけるサイクルであるが、 神の前では無力である。 神の一声は全てを崩壊させ、 民は一生懸命これを再建す。 これが、メテオフォール型開発*2である。 第二節 全てのスケジュールは天界の都合によって決まる。これを黙示録と呼ぶ。 ソフトウェア開発においてフィードバックは重要なファクターだが、 神にフィードバックは届かない。 ただし、祈りを捧げることはできる。この祈りはごくまれに届く。 神は様々な姿を取る。 外から現れることもあれば、 内に棲んでいることもある。 あるいは、まだ会っていない or 会うことすらできな
実践要件定義入門 - 勘と経験と読経
最近ネットを見ていると要件定義入門的な記事とか、あと要件定義は不要みたいな記事が目についたので思ったことを書いてみる記事その２。ITシステム開発における要件定義に関するあれこれ。本記事には前編があります。 目次 要件定義以前 要件定義の進め方 IPAユーザのための要件定義ガイドをベースにする 決め過ぎない 機能を定義するのではなく、機能要件を定義する 関係者をすべて洗い出す 利用者マニュアルの目次が作れるようになっているか ビジネス要件定義 前提事項、制約事項とリスクを定義する 優先順位の決定を忘れずに システム化要件定義 不安定な要件を構造で支える おまけ：本記事の元ネタ 要件定義以前 要件定義というプロセスが本当に必要なのか、ということなどは以下の記事に書いたので省略。 実践要件定義入門以前 - 勘と経験と読経 要件定義の進め方 IPAユーザのための要件定義ガイドをベースにする 前編に
徐々に高度になるリングバッファの話 - Software Transactional Memo
リングバッファのイメージ図 1. リングバッファとは何か 機能的にはFirst In First Out (FIFO)とも呼ばれるキューの一種であるが、リング状にバッファを置いてそれの中でReadとWriteのインデックスがグルグルと回る構造をとる事によって容量に上限ができることと引き換えに高速な読み書き速度を得たものである。キューを単に実装するだけなら山ほど方法があって線形リストを使ってもいいしスタックを2つ使っても原理的には可能だ。その中でもリングバッファを用いた方法の利点はひとえに性能の高さでありメモリ確保などを行わないお陰でシステム系の様々な場所で使われている。 これの実装自体は情報系の大学生の演習レベルの難度であるが少し奥が深い。まずリングバッファのスタンダードなインタフェースと実装は以下のようなものである。 class RingBuffer { public: explicit
テスト専門会社が出版した渾身の書、『【この1冊でよくわかる】ソフトウェアテストの教科書』の出版ストーリー：多くのエンジニアに愛される理由とは
テスト専門会社が出版した渾身の書、『【この1冊でよくわかる】ソフトウェアテストの教科書』の出版ストーリー：多くのエンジニアに愛される理由とは 『【この1冊でよくわかる】 ソフトウェアテストの教科書 [増補改訂 第2版]』は、初版の発行部数は22,000部、2021年8月出版の改訂版は13,000部に上り、技術書としては異例のシリーズ累計35,000部を突破しました。（2023年6月現在） ソフトウェアテスト専門企業であるバルテス株式会社の技術者が執筆した、ソフトウェア開発工程のテストについて、基礎からしっかり体系的に学習できる本格入門書です。 このストーリーでは、初心者から上級者まで幅広い層に読まれている、ソフトウェアテストのバイブルともいえる本書完成までの経緯や苦労話、著者であるバルテスの石原 一宏氏と布施 昌弘氏が伝え続けたい想いをお伝えします。 テスト設計に必要な考え方を身につけられ
ソフトウェア式年遷宮という概念の歴史と、Hatena::Let での実例 - id:onk のはてなブログ
Hatena Engineer Seminar #17 にて発表しました。 hatena.connpass.com Hatena::Letの式年遷宮 from Takafumi ONAKA www.slideshare.net 発表内容をかいつまんで記事にも書いておきます。 Hatena::Let とは はてラボ のサービスの一つ。 僕も入社するまで、はてラボ == ベータ版、だと思ってたんですが、 ラボならではの挑戦的なサービス 運用費が会社持ちで、会社の名前で出しても良い、はてなスタッフの有志が運営するサービス、という制度 も含んでいます。 で、Hatena::Let は、現在は主に id:onk が開発している、ブックマークレットをかんたんに作成・公開できるサービスです。 ソフトウェア式年遷宮とは 初出は 2013 年の id:kenjiskywalker によるもので、このときはイ
Error, Defect, Fault, Failureの定義と解釈
ソフトウェア設計を行う場合、必ずエラーや障害などの用語が飛び交うことがあるが認識がずれていることが多いので、以下に簡単にまとめてみた。 ソフトウェアの非正常を表す概念 ソフトウェアのエラーや障害などの非正常を表す概念の定義をいくつかピックアップしてみた。 JIS X 0014:1999の定義 出典: ソフトウェア品質知識体系ガイド -SQuBOK Guide-(第2版) 誤差・誤り(error) 計算，観測もしくは測定された値または状態と，真の，指定されたもしくは理論的に正しい値または状態との間の相違。 障害(fault) 要求された機能を遂行する機能単位の能力の，縮退または喪失を引き起こす，異常な状態。 故障(failure) 要求された機能を遂行する，機能単位の能力がなくなること。 JIS X 0014では、意図しない結果を引き起こす人間の行為は、「間違い、人的過誤(mistake,
オープンソースビジネスの挑戦と現実｜Rui Ueyama
いい感じのオープンソース・ソフトウェアを書いて、それを元に起業することを考えてみたことがある人は結構いるようだ。実際に僕はここ1年半ほど、自作のオープンソース・ソフトウェアを元にビジネスを立ち上げようと試行錯誤してきた。その経験についてここでシェアしてみようと思う。 あらすじ薄々予期していたことではあったけれど、結論から言うと、そんなにはうまくいかなかった話ということになる。要点をまとめると次の通りだ。 「moldリンカ」というオープンソースのツールを開発して、それを元にビジネスを行おうとしていた そこそこ稼ぐことはできたものの、大きなリターンを得るのは難しかった ほとんどの企業はオープンソースを大々的に活用していても「無料のソフトウェア」にはお金を払うつもりはないし、払いたくても社内制度上できない 大きなリターンを得たいのならば、自作のオープンソース・ソフトウェアを元にサービスを立ち上げ
ソフトウェアエンジニアの“燃え尽き症候群”への対処法とは？ 米国チームが調査
Innovative Tech： このコーナーでは、テクノロジーの最新研究を紹介するWebメディア「Seamless」を主宰する山下裕毅氏が執筆。新規性の高い科学論文を山下氏がピックアップし、解説する。Twitter: ＠shiropen2 米University of California, Irvine（UCI）に所属する研究者らが発表した論文「Mental Wellbeing at Work: Perspectives of Sofware Engineers」は、現役で働くソフトウェアエンジニアのメンタルウェルビーイング（精神的健康）を調査した研究報告である。 ソフトウェアエンジニアは、燃え尽き症候群の割合が高いことが分かっている。そこで研究者らは、米国の多様な職場環境に勤務するソフトウェアエンジニア14人（女性5人、男性9人）を対象にメンタルウェルビーイングに関する調査を行った。
フォワード・リーズニングとバックワード・リーズニング - 檜山正幸のキマイラ飼育記 (はてなBlog)
現状の証明支援系〈proof assistant〉について、僕はしょっちゅう愚痴と文句を言っています（twitterでぼやいたりしてる）。大きな不満点は、フォワード・リーズニングの対話的サポートがまったくない点です。不便だし面白くない。 内容： 証明ソフトウェアの進歩は遅い バックワード・リーズニング フォワード・リーズニング フォワード・リーズニングの対話的サポート 証明ソフトウェアの進歩は遅い 「プログラミング言語Lean 4の現状」に書いたように、証明ソフトウェアの開発は膨大な時間と手間がかかるもので、Coq, Isabelle, Mizar は30年から50年ほどの開発期間を経ています。新しいソフトウェアであるLeanでも、もう10年になります。どの開発チームも最優秀の人材を揃えています。それでも「使いものにならない」事実が、証明ソフトウェアの開発が極めて困難であることを物語ってい
自由なソフトウェアと抗議と倫理の「（不）可能性」について
自由なソフトウェアと抗議と倫理の「（不）可能性」について 2022.05.10 Updated by yomoyomo on May 10, 2022, 18:15 pm JST 大変ごぶさたしております。実に約5年半ぶりになりますが、またこちらで書くことになりました。ブランクが長かったため、ここへの文章の書き方を自分でも忘れてしまったところがあるのですが、稲田豊史氏の「ウェブは最初に結論を書く、くどくど掘り下げて説明しない、とにかく簡潔に」という金言に逆らい、地味な話題についてくどくどと書いていこうと思います。 いや、結論だけは先に書いておきましょうか。銀の弾はない、それだけです。 2022年2月にロシアがウクライナへの侵攻を開始して早くも2カ月以上経ち、ロシア（のプーチン大統領）の甘い見通し、予想以上のウクライナの抵抗、多くの国のウクライナへの支援などと相まって、現状、ロシアが手こずっ
「アジャイルサムライ」の著者が語る、技術志向の企業が世界をどう見ているのか？ そしてソフトウェアテスト自動化を進化させる方法について（前編）。JaSST'22 Tokyo基調講演
「アジャイルサムライ」の著者が語る、技術志向の企業が世界をどう見ているのか？ そしてソフトウェアテスト自動化を進化させる方法について（前編）。JaSST'22 Tokyo基調講演 Jonathan Rasmusson（ジョナサン・ラスムッソン）氏はアジャイル開発における著名人の一人であり、さまざまな先進的ソフトウェア企業において開発やテストに携わってきました。 日本ではアジャイル開発の入門書として話題となった書籍「アジャイルサムライ」（オーム社,2011）や「初めての自動テスト」（オライリー,2021）、「ユニコーン企業のひみつ」（オライリー,2017）の著者としても有名です。 そのラスムッソン氏が2022年3月10日と11日の2日間、ソフトウェアのテストに関わる国内最大のイベント「ソフトウェアテストシンポジウム 2022 東京」（JaSST'22 Tokyo）の基調講演に登壇しました。
SPDX Documentを理解する｜OSS管理ブログ｜ソフトウェア部品管理ソリューション｜日立ソリューションズ
毎々お世話になっております、株式会社 日立ソリューションズの明石と申します。本日は今年からSBOMフォーマットの国際標準として認定された、SPDXに準拠して作成されたSBOM、SPDX Documentについてご紹介したいと思います。 免責事項 当記事の内容については、できる限り正確な情報を提供するように努めておりますが、正確性や安全性を保証するものではなく、筆者独自の解釈も含むことをご了承ください。 掲載しているリンク先についても確認などは行っていますが、遷移先で提供される情報、サービスなどについては一切の責任を負いません。 また、掲載内容の活用は読者自身の自由と主体性の元に行うものとし、万が一損害が発生したとしても一切の責任を負いかねます。ご了承ください。 そもそも、SPDXって何？ SPDXという単語の由来は「Software Package Data Exchange」の頭文字から
Design Docs のいけすかなさ / morrita - Message Passing
Design docs というのが昔からあまり好きでない。読むのも書くのも好きでない。 仕事で文書を書くのはやぶさかではないけど Design docs はなんとなくいや。 せっかくなのでこのイヤさを言語化してみたい。 Design Docs とはなにか 自分が想定している Design docs は この文章が説明しているようなものだ。 なにかそれなりの規模があるものを作る時に設計やそのトレードオフをざっと文書化する文書。 もっというと一般名詞の design docs ではなく、リンク先に書いてあるような自分の勤務先固有の The Design Docs 文化が好きでない。 「設計やそのトレードオフをざっと文書化する。」 それだけ聞くと割と良いもののような気がして、自分もある時期までは良いものだと思っていた。 「ドキュメンテーション」というのは、プログラミングのポップカルチャーにおいて
Rustで書かれた、既存のソフトウェアの代替一覧を作った
Rustで既存のソフトウェアを再実装することは「Rewrite It In Rust」と言われたりしますが、 最近はfindの代替である fd やlsの代替である exa などといったUnixコマンドのRust実装がよく見られます。 このようなUnixコマンド以外にも、Goで書かれたコンテナランタイム runc のRust実装である youki や既存のNodeバージョンマネージャーである nvm よりも200倍速い[1]とされている fnm や Lemmy というRustで書かれた reddit の代替などがあります。 また、僕自身もRubyのバージョンマネージャーである rbenv のRust実装である frum を作ったりしています。 作ったもの 今回は、こういったRustで書かれた、既存のソフトウェアの代替の一覧を作ってみました。 RustでOSSを作る際にこういった一覧があると、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
フロム・ソフトウェアが語るデバッグメニュー最適化テクニック。ネットワークを活用し、ロード待ちが13秒→15ミリ秒以下に【CEDEC2023】
ソフトウェア開発者に必要な考え方 / Necessary mindset for software developers
「なぜ日本政府が作るソフトウェアは使えないモノばかりなのか？」――中島聡氏が考える「日本社会のDX」の要件
