サバンナ便り ～ソフトウェア開発の荒野を生き抜く～ 第7回テストコードの認知負荷 ～テストの名前⁠⁠、構造⁠⁠、情報量を工夫する～ 開発の現場では、既存のテストコードから仕様を読み解く機会がよく訪れます。そのようなとき、テスト対象の仕様やテストの意図を読み解きやすいテストとそうではないテストがあることに気付きます。今回はテストコードの読み解きやすさに寄与する要素を考えます。 認知資源と認知負荷 人間は何かを読み解くときに脳のリソース（脳内のワーキングメモリ）を使います。リソースの量は有限で、個人差があります。このような脳のリソースは「認知資源」と呼ばれています。 人間が何かを読み解くときに認知資源が何にどのくらい割かれているかという概念を「認知負荷」と言います。「⁠どのくらい」は状況に左右されます。たとえば、読み解く対象を知っているかどうかで認知資源が割かれる量は変化します。「⁠何に」も状

有能ではあるが万能には足りない 前回の予告どおり、今回はSwiftへの不満と将来への期待を取り上げます。 公式サイトのAbout Swiftにはこうあります。 The goal of the Swift project is to create the best available language for uses ranging from systems programming, to mobile and desktop apps, scaling up to cloud services. 「Swift プロジェクトのゴールは、システムプログラムからモバイルおよびデスクトップアプリケーション、そしてクラウドサービスに至るまで最良の言語を創ることである⁠」⁠。裏を返すと、Swiftへの不満はこのゴールに足りないものということになります。 RustにあってSwiftにないもの＝Rust

大量の文章から学習することで、多言語を取り扱う能力だけでなく、高度な推論能力まで手に入れました。 GPT-3.5、とりわけその初期モデルのCodexはGitHubに存在する5400万の公開リポジトリから採取された159GBのPythonコードでGPT-3をfine-tuning（微調整）することで生まれました。ChatGPTがとりわけPythonが得意なのはここから来ています。 ChatGPTの学習データを考えることはその能力を発揮させるときに極めて有効です。質問時も以下のように、『⁠涼宮ハルヒの憂鬱』というライトノベル作品について日本語で聞いたときはSOS団の略称を間違えるなどしますが、英語ではほぼ期待通りの回答を見せます。 図1 『ハルヒの憂鬱』について日本語で聞いた場合の回答 図2 『ハルヒの憂鬱』について英語で聞いた場合の回答 知ったかぶりをするChatGPT ところで、ChatG

本連載は分散型マイクロブログ用ソフトウェアMisskeyの開発に関する紹介と、関連するWeb技術について解説を行っていきます。第1回はMisskey、ひいては分散型SNSの簡単な紹介とその内部実装の概略を説明します。 はじめまして！ はじめまして、Misskey（みすきー）のプロジェクトリーダーをしている、しゅいろ（@syuilo）です！ この度連載の機会をいただきましたので、ちょっと仰々しい気もしますが「Misskey & Webテクノロジー最前線」と題して、今後Misskeyやそれに関わる最新のWeb技術について解説をしていく予定です。 今回はMisskey、ひいては分散型SNSの簡単な紹介とその内部実装の概略を説明します。 対象読者は、後半の実装解説の部分においてはある程度のWeb開発の知識がある人を想定しています。 Misskeyとは⁠、そして分散型とは Misskeyは、オープン

ノートアプリ「Obsidian」を使いこなす 「Obsidian」でノートを作るときの考え方とは？ ～デイリーノートの活用と、PKMとしてのノート術 前回までの記事で、Obsidianの基本的な設定は完了しています。あとは、ノートを自分の好きなようにMarkdownで書いていけばよいのです。 しかし、ノートを書くといっても、何から手をつければよいのかわからない人が多いでしょう。 ノートの書き方は人によって違ってよいのですが、先人が残してくれた知恵がいくつか公開されています。その方法と合わせて、私がノートを作るときの考え方を紹介します。 デイリーノートを使う Obsidianではじめてノートを作成する人に対して、私がおすすめしているのは前回の記事で紹介したコアプラグインの「デイリーノート」を使う方法です。 デイリーノートとは、名前の通り毎日のノートのことです。初期設定のままで設定を変更してい

import What? 今回はモジュール（module）について話します（図1⁠）⁠。モジュールとはいったいなんでしょう？ 図1　モジュールとは？ macOSにもiOSにも標準搭載されているOxford American Dictionaryにはこうあります。 > _Computing_ any of a number of distinct but interrelated units from which a program may be built up or into which a complex activity may be analyzed. 同じく標準搭載のスーパー大辞林ではこうです。 > ④ ソフトウェアやハードウェアを構成する部分のうち、独立性が高く、追加や交換が容易にできるように設計された部品。 このとおり専門用語を超え一般用語として受け入れられているモジュールで

ニコニコ動画：https://www.nicovideo.jp/watch/sm2316665 クロコさんからの質問 なるほど。連載第5回でも、「⁠写経をやってみた、リズムもわかってきた。でもいざ自分でやろうとすると、最初はどういうテスト書こうかとか、どういう単位でテストを書けばいいのかとかで詰まってしまう」という質問をいただきましたね。 私は実は、明確にこういう単位でテストを書くべしという決まりはないと思っています。 不安をテストで表現する では、私がどういうときに小さいテストを書いているかというと、私は「不安」を最小単位の基準としています。不安を手がかりにしてテストを書きます。 私たちプログラマの手を止めるものは何でしょうか。私は「不安」だと思っています。「⁠もしかしたら」という感情ですね。「⁠もしかしたら、自分の書いているコードは間違っているかもしれない」「⁠もしかしたら、ライブラリ

ニコニコ動画：https://www.nicovideo.jp/watch/sm2325718 家永さんのコメント そうですね。 今「モックテスト」という言葉が出てきました。モックテスト、モックオブジェクトという技法は、『⁠WEB+DB PRESS Vol.35』の特集1「実演！ テスト駆動開発」でも少し説明しましたが、この場で詳しく説明しましょう。 モックオブジェクト技法とは 「モックオブジェクト」「⁠モックテスト」とは、ニセモノのオブジェクト（モックオブジェクト）をテストに使う技法です。本物のコードや本物のクラスではなく、テスト用の偽者のオブジェクトを作成し、テストを書きやすく、実行しやすくします。 詳しくは後述しますが、具体的には、テスト対象である本物のクラスと、それと協調動作するオブジェクトの偽物を使います。偽者オブジェクトは、テストの中で、テストの内容に即した動きをします。 メリ

導入 現在主流となっているオブジェクト指向プログラミング言語を用いたプログラミングは、既存のクラスを利用するか、自前でクラスを記述するかしてソフトウェアを構成します。クラスの数が数個の小さなソフトウェアのうちは問題になりませんが、片手を超える数のクラスを取り扱うようになると、それぞれの役割や存在さえも不明確になってしまいます。図は概念を確認するための良いツールです。今回学習するクラス図は、その意味で私たちを助けてくれる頼もしい味方です。 展開 クラス図とは クラス図と、それに関連する語句の定義を示します。 クラス図 : 静的で宣言的な要素（クラスやインターフェイス、およびそれらの関係）の集合です。つまり、インスタンスにする前、sketchを実行する前のソースコード段階の各要素とその関係を示す図。 参考文献『オブジェクトモデリング表記法ガイド』より（一部文言を変更） 詳細度による描き分け ク

エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング 著者 広木大地　著 発売日 2018年2月22日 更新日 2018年6月21日

GoogleメッセージをKDDIが採用⁠⁠、そして⁠⁠、＋メッセージへの期待 傍島康雄 2024-05-23