書評：GitHub Copilot とのペアプロ TDD でつくるローグライク RPG - 若くない何かの悩み
本記事は「GitHub Copilot とのペアプロ TDD でつくるローグライク RPG」の書評です。題名にローグライクRPGとあるのでゲーム開発の本なのかなと思ってしまいますが、本題は仕様の端的な表現をもたないシステムを LLM を使って真っ当に開発する方法の解説だと思います。タイトルにローグライクRPGと書いていることでゲーム開発に興味のない人の興味を失わせてしまい損をしている気がします。 背景 最近の LLM の流行を受けて私も Chat-GPT や GitHub Copilot といった LLM を開発で利用しています。端的に仕様を表現できるシステムは LLM に質問して実装を得る方が自分で実装するより圧倒的に速く正確であるという感想を抱いています。ただ端的に仕様を表現できるシステムばかりではありません。えてして価値を生んでいるシステムというのは端的な仕様の表現が存在しないもので
ソフトウェアエンジニアでテストマンな私が家を買う際にやったこと - 若くない何かの悩み
はじめに ソフトウェアエンジニアでテストマンを生業とする Kuniwak です。今回は家を買うためにやったことを紹介します。 というのも、家を買うためにやったことを知人に話してみたら面白がられたため、誰かの役に立つかもしれないと思ったからです。 なおこの記事はソフトウェアに関する技術の記事ではありません（随所に検証の基本的な考え方などが散りばめられていますが…）。また、この記事で紹介する意見・手法は多分に cocopon 氏の影響を受けています。cocopon 氏の家購入エントリもこの記事と同時に公開されているはずです。 また、この記事はとても長いので先にポイントを説明しておきます。この記事ではライフプランシミュレーションに始まり次のような3Dモデルを作って日照や照明の検証をしていきます。また、3Dモデルを作るだけでは漏れが出るのでさまざまな検証を組み合わせています： 検証のために作った3
自動テストに限界を感じた私がなぜ形式手法に魅了されたのか - 若くない何かの悩み
長らく自動テストとテスト容易設計を生業としてきましたが、最近は色々な限界を感じて形式手法に取り組んでいます。 この記事では、既存の自動テストのどこに限界を感じてなぜ形式手法が必要なのかの私見を説明します。なお、私もまだ完全理解には程遠いため間違いがあるかもしれません。ご指摘やご意見はぜひ Kuniwak までいただけると嬉しいです。 著者について プログラマです。開発プロセスをよくするための自発的な自動テストを支援する仕事をしています（経歴）。ここ一年は R&D 的な位置付けで形式手法もやっています。 自動テストの限界 自動テストとは 私がここ数年悩んでいたことは、iOS や Web アプリなどのモデル層のバグを従来の自動テストで見つけられないことでした。ただ、いきなりこの話で始めると理解しづらいと思うので簡単な例から出発します。 この記事でいう自動テストとは以下のようにテスト対象を実際に
iOSDC ベストトーク賞2位の発表の蛇足 #iosdc - 若くない何かの悩み
iOSDC Japan 2018 で、ベストトーク賞2位をいただきました。タイトルは「iOSアプリの開発速度を170%に向上させたデバッグノウハウ」です。この記事では、スライドの紹介に加えて、スライドに書ききれなかった背景やレビュー体制などについてお話ししようと思います。 発表スライド スライドでは語られていない発表の目的 この発表は少し特殊な構成で組まれています。発表内で繰り返し出てくる「動作確認の自動化」とは、実のところ「テスト」のことです。しかし、私はこの発表でなるべく「テスト」というキーワードの使用を避けました。 この背景には、iOSDC ではテスト関連の CfP が通らないという経験則があります。私はこの原因を CfP 選考に関わる方たちに次のような人が多いからではないかと推測しました： テストをやったことがなくて興味がない テストに嫌な体験がある そこで、上記のような方にも受け
株式会社ミクシィを退職しました - 若くない何かの悩み
表題のとおり、株式会社ミクシィを退職しました。私は2014年の新卒入社なので、4年弱お世話になったことになります。たいへんお世話になりました。 さて、とりあえず在職中に印象に残っていることをまとめてみました。 印象に残っていること 新人賞 2015年に新人賞をもらいました。受賞者の発表は全社総会でやっていたらしいのですが、私は発表のタイミングに別室で休んでいたために何も知りませんでした。そのため残念なことに表彰時不在となりました。なお、その後に表彰時にもらえるはずの賞状が行方不明になるなど紆余曲折ありましたが、受賞を光栄に思います。 学生向け競技イベント「git challenge」 2015~2018年にかけては、壊れたgitリポジトリからの復旧などを問題とした学生向けイベント「git challenge」をやっていました。このイベントでミクシィを知ってくれた学生は、結構な確率でミクシィ
vim-splashを使い倒してこそ真のVimmerですぞ #vim - 若くない何かの悩み
Vim Advent Calendar の19日目です。昨日はyoshikawさんのサーバ管理に役立つVim技10選でした。 さて、@modsoundさんの記事、Vimmer名刺を持ってVimConfへ出かけよう に触発されてvim-splashの可能性を最大限に引き出す使い方を提案します。 vim-splashでなにができるの かっこいい起動画面 VimmerにモテるVim名刺 ひつようなもの thinca/vim-splash 起動時スプラッシュ 例 vim_intro.txt 名刺用スプラッシュ 例 orga_chem.txt かっこいいスプラッシュのつくりかた みなさんもかっこいいスプラッシュを作ってﾊｧﾊｧしましょう。 サンプルとして、vim.orgの名刺用スプラッシュをつくってみます。 雛形をつくる まず ASCII Art Gener ator をつかってアタリ（下書き）をつ
「メールアドレスのルール」系まとめがそろって間違ってるのでご注意を - 若くない何かの悩み
メールアドレスのルールのまとめ系のサイトの内容が間違っています。 なので、この類のまとめは安易に信じないように 、という注意喚起をしておきます。 追記（2013/11/27） twitterやはてブをみていたところ、「ユーザーへの啓蒙という観点ではまとめの内容間違ってない」というご意見をたくさんいただきましたので、補足をしておきますね。 どうも「ルール」と「トラブルを避けるためのガイドライン」が混同されているように思います。まとめで紹介されている内容がユーザ向けの「ガイドライン」なのであれば、「+ 記号使わせてよ」ぐらいしか文句はありません。 ですが、ほとんどのまとめは上記の内容を「ルール」として説明しています。ひどいものにはRFCに基づいてまとめを書いたようにミスリードさせる記事もありました。このような現状を憂い、このような記事を書いたのです。 そもそもこれに気づいた発端は@kusano
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
退職の前座エントリ - 若くない何かの悩み