はてなブックマーク

この記事は何？ 11/15 に公開された OpenAI のEvan Morikawa へのインタビュー記事をざっくりまとめました。この日本語記事のソースは、 Gergely Orosz による Pragmatic Engineer Newsletter です。 ChatGPT や DALL·E がよく話題になりますが、これらの研究をUIやAPIを含むWebのサービスとして構築しているのが、応用エンジニアリングチーム(Applied Team)です。公開されているサービスには、ChatGPT だけでなく、DALL-E 3 なども含まれます。 この日本語記事を書いている私自身が、スタートアップとアジャイルチームに強い興味を持っているので、このまとめを書きました。 ほんとにざっくりまとめ、なので、詳細は、ソース記事を読むことをおすすめします。 サマリ 小さな独立したスタートアップのように運営する

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? これは何? Gilbert Strang 先生から学んだ線形代数シリーズ、第2回目の記事です。全体は以下から。 今回は、線形写像の表現行列 $A$ の「4つの部分空間」(The Four Subspaces)について、証明ではなく直感的に理解する方法について書いてみます。それらは$A$の零空間、$A$の列空間、$A$の行空間、$A$の左零空間です。 これは、『線形代数学の基本定理』とも呼ばれています。この定理には、先生の教育上の功績が大きいと思います。 線形代数学の基本定理 (Wikipedia) - $(m \times n)$行列

これは何か? このシリーズでは、Gilbert Strang 先生の Linear Algebra Vision 2020 を元に、線形代数の直感的理解を得るための「目から鱗」の話題を紹介したいと思います。 Gilbert Strang 先生は MIT の有名な（名物）線形代数の先生です。OpenCourseware で無償で先生の講義をみることができます。これが、とっても楽しいです。定理の証明を追うようなスタイルでなく、具体的な数で手を動かしながら、どんどん、直感的理解が進みます。ほんと、目から鱗です。まるで、古典落語を鑑賞するような感覚で何度も見ることができるクラシックです。 その他、有名な著作がいくつもあり、インタビュー動画等もあります。 先生の線形代数の本 『ストラング：教養の線形代数』 日本語版が出ました（2023/2/11)。 表紙の $A=CR$ の意味、解説はこちらに。（→

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 伝統的な品質保証(QA)からアジャイル品質(AQ)へと変わっていこう 2016/9/30、Hillside Group(後述)の代表Joseph Yoderさんが来日され、鷲崎先生と特別セミナーが開催されたとのこと。 そこで紹介された、**「QA to AQ: 品質保証(Quality Assurance)からアジャイル品質(Agile Quality)へ」**というパターンが秀逸で、かつ、日本のアジャイルオーディエンスに興味がある方が多いであろう、と思い、紹介します。 アジャイル開発は徐々に日本の開発現場にも浸透しています。特に、We

VersionOne 社が毎年出している "State Of Agile" レポートが今年で 10 年目だそうです。 簡単に内容を紹介します。ちなみに、この調査は基本的にアジャイル実践者が回答していることが多いこと、またアジャイルツールのベンダーの調査ですので、母集団や見せ方には多少のバイアスはあります。また、データの解釈については、私の私見も入っていますので、注意してください。 母集団とAgileの成長について 回答母数は3,880。===> 10年前(2006)の３倍。 回答者が属するソフトウェア開発組織として100名以上の会社が2/3、1,000名以上が1/3。 ===> 10年前は100名以下が2/3。 組織のアジャイル採用率95%。1/3以上が採用始めてから5年以上。 回答者は北米56%, 欧州26%, アジア11%, 南米6%, オセアニア2%, アフリカ1% 以下のレポートで

6/26日、JaSST関西に参加しました。西先生が考えているテストアーキテクチャ設計について、そのモデル（メタモデル）をトライしてみました。 先生は、システムアーキテクチャ設計の並行概念として、「テストアーキテクチャ設計」というコンセプトを提唱しています。最終的にはテストスイート（テストケース群）を設計するのですが、テストケースの上位概念として「テスト観点」を上げ、それらをモデル化（グループ化、階層化、関係づけ）することでテストの再利用性やその後の派生開発での利用をしやすくするある種の「設計行為」だとしています。 このモデルは、講義中に描いたものを、懇親会中に西先生と議論し、その後、二次会でも同じテーブルの方々とレビューして書き上げた、第一バージョンです。 この領域にいる方々のコメントを下にお待ちします。

コンピュータグラフィックスにおいて、図形を変換するには、ベクトルやマトリックス（行列）の演算が多用されます。その中でも、Quaternion(= 4元数 = 虚数単位が3つある複素数)を用いて回転変換を表現する手法の数学的な解説をしたいと思います。通常の複素数の掛け算が、2次元複素平面での回転変換を表現できることの3次元への応用ともなっています。 補記：この記事は、Qiita でLaTeXを利用してみたい(参照：『Qiita 上で数式を美しく書けるようになっていた件 (MathJax)』）、というモチベーションで書いています。この記事『Java3Dの数学』の一部抜粋を読みやすくしたものです。また、コンピュータグラフィックスに慣れた読者には、最初の準備は長いと思いますので、後半のみ読んでください。 (準備1) 点とベクトル、それらの座標系を用いた表現 数学的な準備からはじめましょう。点もベク

さて、派生開発の「変更」をどうモデル化するか。。。前回までのあらすじはこちら。 派生開発における変更指示をモデルで表現する（問題編） デルタの導入 欲しいものは、「修正」そのものをストレートに表現することです。なので、クラスの「修正」を表すステレオタイプ、《delta》を導入します。これは、クラスに対する変更指示そのものを示すクラスです。赤ペンで書くことを、少々フォーマルにして、このクラスの中に情報として書いて行きます。さらに、サブとなるステレオタイプ、《add》, 《delete》, 《modify》も導入。 デルタ: 《delta》 追加: 《add》 削除: 《delete》 変更: 《modify》 この 3 つに分け、変更を表現します。変更を「クラス」として閉じ込める分けです。さらに、この変更指示は、上位の変更要求に対応するはずです。この変更要求を「要求」（UMLでは《requi

セイコーエプソンの萩原さんと、モデルを使って派生開発の変更指示をうまく表現できない、という課題を議論しました。考えのメモです。 派生開発における「変更指示」 日本の組込み開発でよく使われる手法である清水さんの「派生開発」(XDDP)ですが、派生前の状態に対して「変更指示」を文書化します。 ソースコードレベルであれば問題は少ないのですが、構造に対しての修正は大域的になり、うまく表現しにくくなります。これをモデルで扱いたい、というのが問題です。 Before/After の問題点 まず考えられるのは、Before と After を示す方法です。 ここから実際の変更を行うのはとても観察力が必要！例えて言えば、間違い探しになってしまいます。 例えば astah などでは diff をとる機能もありますが、もっといい方法はないでしょうか？普通は「赤ペン」を入れたいところ。 さらに言うと、せっかくな

JaSSTの基調講演 Michael Bolton の「How to Get What You Want From Testing」のまとめ。 （※写真は実行委員会の許可を得て掲載） の内容をざっくりまとめると、 テストの中心はテスター（人間）だ。例えばテストが退屈だと感じたら何かが間違っている。我々の仕事は工場の組み立てラインとは違う。テストケース、という言葉が「数えられる」ために管理者は好きだ。でも、大切なものには数えられないものもある。例えば子供を育てること。「ペアレントケース」で測ったりしない。Checking と Testing を分けたい。Checking は機械的に可能なこと。これをやると飽きる。Testing は人間にしかできないこと。Testing は学習プロセスであり、フィードバックと適応の繰り返しである。テストにおいてバグでなくても「何かがしっくりこない」という「感情

『ソフトウェアシステムアーキテクチャ構築の原理(第2版)』を読んだので、メモとして内容の一部を紹介します。 原書、著者など Software Systems Architecture (2nd Edition) 著者 Nick Rozansky, Eoin Woods 監訳 榊原さん 何が書いてある? 「ソフトウェアシステムのアーキテクチャとは？」という深淵な課題について書いています。アーキテクチャ、システムとその関連概念群を定義しようという取り組みは古く、 1970s David Parnas 1990s Dewayne Perry, Alexander Wolf 1995 Philipe Kruchten, RUP (The “4+1” View Model of Software Architecture) ... 論理/プロセス/物理/開発 + シナリオ(Use Case) これが

特徴 特徴をマインドマップにすると、上記の定義に含まれている形容詞が列挙される。（本より抜き出したものに、ほんの少し注釈を加えた） ゴール駆動、プロセスフレームワーク 本書の中には、マインドマップが多くでてくる。これは、DADが「ゴール駆動」であることの強い反映だと思う。また、「プロセスフレームワーク」であるから、手順的な（プリスクリプティブな）プロセスではないことにも関連している。後述するが、各フェーズごとに「ゴール」が宣言的に書かれており、手順が書かれている訳ではない。組織が自分たちの手法としていくための考え方である。 ハイブリッド また、「ハイブリッド」というのは既存のアジャイル手法の組み合わせになっていること（RUPも含めて）。そして、「デリバリーライフサイクル」として、RUPに似た「フェーズ」概念が出てくる。「方向付け」/「構築」/「移行」の３フェーズである。全体としての手法づく

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事は、故石井勝さんが1999年に書いた記事を Qiita に転載するものです。オブラブ(objectclub.jp)にて記事をホスティングしていましたが、現代でも十分に読める内容なので、たくさんの方に読んでもらいたいと思い、若干の編集（リンクとコンテキスト追加）を平鍋が行い、転載します。今でも、読みやすく、カジュアルな語り口のよい記事です。 オブジェクト指向の法則集（転載元：http://objectclub.jp/community/memorial/homepage3.nifty.com/masarl/article/oo-p

これだけモデリングとは **「これだけモデリング」**とは、メソドロジックの山岸さんが提唱されている「軽い」モデリング手法です（山岸さんはリーンモデリングとも呼んでいたがぼくはベタにこれだけモデリング、という日本語が好き）。 デベロッパーでなく情報システム部門目線で見て、どんどん複雑になる企業アプリケーションの要求や設計を見通しよく「共通合意」を作るための、「軽い」モデリングの必要性がテーマです。 そうなんです、従来は、「全部書かなきゃだめ」とか「全部メンテしないといけない」とか、「下流を触ったら上流までさかのぼって修正しなきゃ」とか足かせが多かったので、なかなか実装から遠いモデリングがペイしなかったのですね。だから、「これだけ」モデリングを提案したい、という訳です。 エンタープライズアジャイル時代のリーンモデリング（slideshare） これだけモデリングとは、 誰が？　ー　情報システ

この記事は、英語ブログエントリ"How to make it better ? - Extracting implicit knowledge via GSN"の日本語訳です。  -あまりうまくない「かぶと」- 折り紙をうまく折る 折り紙には上手い人とそうでない人がいます。また、外人に折り紙を教えると、手順はうまく伝えることができても、あまり奇麗にできることはありません。折り紙をうまく織るには、「ここは角がしっかり合うように気をつけて」などというコツをうまく伝える必要があります。 ソフトウェア開発においてドキュメント、コード、報告書などをレビューしていても、同じ悩みがあります。作成する手順、プロセスだけではだめ。この小

IT人材はざっくり100万人いて、その8割がIT企業、というのが実態です。これはここ数年変わっていないようです。 また、これはこの調査と関係のない参考情報ですが、米国ではユーザー側の技術者の方が多く（人材の流動性が高く、プロジェクトが始まると積極的に採用する）。この日本の分断構造がアジャイルの採用を難しくしている、という１つの理由となっています（2012年のIPAの調査より）。 受託開発の今後 ぼくは、チェンジビジョンで「パッケージ開発」を、永和システムマネジメントで「受託開発」を事業としてやっています。受託開発やSIの今後（オワコンなどと呼ばれたりする）について興味があるので、このあたりを白書から見てみます。 サービス利用の拡大 明らかなデータとして、「作る」から「使う」に転換の傾向があります(p.18)。Google Apps, AWS, MS Azure, Salesforce など

実践テスト駆動開発を読んだ（和智さんいい仕事、ありがとう！）。 タイトル(GOOS = "Growing Object-Oriented Software, Guided By Tests")に、「テスト（TDD）」と「オブジェクト指向（Object-Oriented）」と「育てる（Growing）」が入っていて、ずっと読まなきゃと思っていた。出たときに角谷さんに「これは！」、と薦められたのに、機会を失っていたけど、最近、astahの開発でテストに悩みがあって読んでみた。 外から攻めるか、内からか テストを書いてプロダクトコードを育てていくという話なのだが、内側のテスト（ユニットテスト）と外側のシステムテスト（受け入れテスト、システムテスト、エンド・トゥ・エンド(E2E)テスト)をどっちを先に書くべきかいつも悩む。外側のテストを書いて、内側に進んでいくのか、内側から組み上げるか。設計の方向