ソフトウェアエンジニアでテストマンな私が家を買う際にやったこと - 若くない何かの悩み
はじめに ソフトウェアエンジニアでテストマンを生業とする Kuniwak です。今回は家を買うためにやったことを紹介します。 というのも、家を買うためにやったことを知人に話してみたら面白がられたため、誰かの役に立つかもしれないと思ったからです。 なおこの記事はソフトウェアに関する技術の記事ではありません（随所に検証の基本的な考え方などが散りばめられていますが…）。また、この記事で紹介する意見・手法は多分に cocopon 氏の影響を受けています。cocopon 氏の家購入エントリもこの記事と同時に公開されているはずです。 また、この記事はとても長いので先にポイントを説明しておきます。この記事ではライフプランシミュレーションに始まり次のような3Dモデルを作って日照や照明の検証をしていきます。また、3Dモデルを作るだけでは漏れが出るのでさまざまな検証を組み合わせています： 検証のために作った3
自動テストに限界を感じた私がなぜ形式手法に魅了されたのか - 若くない何かの悩み
長らく自動テストとテスト容易設計を生業としてきましたが、最近は色々な限界を感じて形式手法に取り組んでいます。 この記事では、既存の自動テストのどこに限界を感じてなぜ形式手法が必要なのかの私見を説明します。なお、私もまだ完全理解には程遠いため間違いがあるかもしれません。ご指摘やご意見はぜひ Kuniwak までいただけると嬉しいです。 著者について プログラマです。開発プロセスをよくするための自発的な自動テストを支援する仕事をしています（経歴）。ここ一年は R&D 的な位置付けで形式手法もやっています。 自動テストの限界 自動テストとは 私がここ数年悩んでいたことは、iOS や Web アプリなどのモデル層のバグを従来の自動テストで見つけられないことでした。ただ、いきなりこの話で始めると理解しづらいと思うので簡単な例から出発します。 この記事でいう自動テストとは以下のようにテスト対象を実際に
コスパで学ぶ自動テストのはじめ方 - 若くない何かの悩み
Qiita 週間ランキング1位を獲得しました Kuniwak です。ご愛顧ありがとうございます。 qiita.com さて、本題に移りたいと思います。 つい最近ですが、勤め先の別チームに向けて自動テストの導入を支援するための資料を作成しておりました。こちらを共有したいと思います。 speakerdeck.com 資料中にある「仕様化テストを推奨しない」という決断には賛否両論あるかと思います。仕様化テストを推奨しなかった理由は、仕様化テストにかかるコストは相当に高く、本当に余裕があるときでないと選べない選択肢だったからです。今回自動テストを導入しようとしているチームは、見るからに余裕のない状況だったので仕様化テストからやれとは言えませんでした。 もし、「自分だったらこうする」等のアドバイスがあれば、ぜひ参考にしたいと思います。コメントなどに書いていただけると嬉しいです。
JavaScript 祭で発表してきました - 若くない何かの悩み
秋のJavaScript祭 in mixi で、「バグの見つけ方」について発表してきました。 speakerdeck.com 過去二つのスライドをくっつけたものなので、既視感があるかもしれませんが気のせいです。 さて、前の発表を終えてから、いくつか直したかった点があったので、その点だけ修正してあります。 例えば、「ステップ実行」→「手動動作確認」のあたりですね。 ステップ実行でバグを見つけるというより、見て触っておかしいと気づいて、ステップ実行へ突入するはずですから、「手動動作確認」の方がふさわしいと思ったためです。 あと、次の2つの感想が特に嬉しかったです。ありがとうございました。 スライドめっちゃすてきだしリントやテストの大事さがすごくわかりやすい… #jsfes— nao (@naoi109) October 15, 2016 これまでの人生で一番簡潔に型検査やリントやテストの重要性
「GitHub トレーニングチームから学ぶ Git の内部構造」に行ってきました #githubjp - 若くない何かの悩み
「GitHub トレーニングチームから学ぶ Git の内部構造」に行ってきました！Gitの中・上級者向けの素晴らしい勉強会でした。おもしろかった！ 今回の勉強会で一番面白かったのは、「とりあえずコミットをしろ。そうすりゃあとでなんとでもなる」です。git reset --hard によって消えたはずのコミットが git reflog から復元できるなんて目から鱗でした。現在の変更を破棄したい場合でもとりあえずコミットしておけ、という教訓の意味がやっと分かりました。 末尾に勉強会のノートを添えておきます。 このイベントは、その場で図を書くような説明などアドリブが多く、とてもわかりやすかったのですが、まとまった資料を貼るのが難しそうな発表でした。したがって、資料は公開されないかもしれません。とすると、このノートはいまのところ唯一の資料です！ ちなみに、会場の様子はこんな感じでした。勉強会の後の
ミクシィ内定者代表者挨拶で披露した「piine!」の技術的こだわり - 若くない何かの悩み
さて、前の記事からずいぶん時間が経ってしまいましたが「piine!」の技術的こだわりに触れておこうと思います。 こだわりポイント 力学モデル 操作方法はタップだけ 非ネイティブアプリ Webフォント 技術的こだわりポイント Closure Library + Socket.IO Github pages + AmazonEC2 それぞれを順に見ていきましょう。 こだわりポイント 力学モデル デモを用意しました。 まずは存分に力学モデルをお楽しみください。 プロジェクターに表示される側のpiine!では、挨拶を聞いているユーザーが点として表示されます。 ユーザーが参加・退出するとき点が増えたり減ったりするわけですが、このとき点の配置を滑らかに遷移させるために力学モデルを使っています。円上の点はそれぞれの距離が近いほど強い斥力が働きます。この斥力によって、それぞれの点は円を均等に分割する点へと
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
