単体テストを書かない技術 #phpcon_odawaraPHPカンファレンス小田原2024での発表資料です https://fortee.jp/phpconodawara-2024/proposal/4d39c7ef-058c-4648-b1d7-5510497e0d81
Bashにおけるインクリメントの方法 - やってみる
様々ある。 参考 https://rcmdnk.com/blog/2013/11/13/computer-bash 方法 ((count++)) let count++ count=\expr $count + 1`` ((count++)) OK count=0 while [ $count -lt 3 ]; do ((count++)) done count=$((++count))の部分は、以下のように置き換えることができる。 : $((count++)) count=$((++count)) count=$((count+1)) ((count++)) (事前に数値として初期化(count=0等)した場合のみ) 実行速度が速い。表記も短い。ただし、以下のようにわずかな表記の違いでバグる罠が多数ある。 NG 1 count=0 while [ $count -lt 3 ]; do c
TCPの各種状態の作り方 - hana_shinのLinux技術ブログ
1 はじめに 2 検証環境 2.1 ネットワーク構成 2.2 版数 3 TCPの状態遷移 4 LISTEN状態の作り方 5 ESTABLISHED状態の作り方 6 SYN-SENT状態の作り方 6.1 作成手順 6.2 後始末(iptablesの設定削除) 7 SYN-RECEIVED状態の作り方 7.1 作成手順 7.2 後始末(iptablesの設定削除) 8 FIN-WAIT-1状態の作り方 8.1 作成手順 8.2 後始末(iptablesの設定削除) 9 FIN-WAIT-2状態の作り方 9.1 作成手順 10 CLOSE-WAIT状態の作り方 10.1 作成手順 11 LAST-ACK状態の作り方 11.1 作成手順 11.2 後始末(iptablesの設定削除) 12 TIME-WAIT状態の作り方 12.1 作成手順 13 CLOSING状態の作り方 Z 参考情報 1 はじ
SRecord 1.65
The SRecord package is a collection of powerful tools for manipulating EPROM load files. It was written by Peter Miller and continues to be maintained by Scott Finneran. This website, very much a product of its time is kept as close as possible to Peter's original in memoriam. I wrote SRecord because when I was looking for programs to manipulate EPROM load files, I could not find very many. The on
スナップショットテストの向き不向きについて考えてみる - mizdra's blog
ふとスナップショットテストってなんだろう、どういう場面で向いていて、どういう場面には向いていないんだろうと考える機会があって色々調べてました。丁寧な記事にしようとしたのですが、上手くまとまらなくて挫折してしまった… とはいえこのまま手元に置き続けておくのも勿体ないので、下書き段階のものを公開して供養します。 スナップショットテストとは スナップショットテストとは、あるプログラムの出力を以前の出力と比較し、両者に差分があるかをテストする手法のことです。予め以前のバージョンのプログラムの出力 (スナップショット) のどこかに保存しておき、新しいバージョンのプログラムの出力と比較し、差分があったら fail させます。これにより、プログラムの出力内容が予期せぬうちに変わってしまっていた場合に気づくことができます。 例: React コンポーネントのテストへの適用 代表的な利用例が Jest を使
「ゼルダの伝説 BotW」にバグが少ない理由
素晴らしいオープンワールドゲームならいくらでもある。「The Elder Scrolls V: Skyrim」、「ウィッチャー3 ワイルドハント」、「グランド・セフト・オートV」、「Fallout 4」など、巧妙に作り込まれた膨大なスケールのゲームは特に海外のタイトルが多いように思う。それらと比べても遜色のない国産タイトル「ゼルダの伝説 ブレス オブ ザ ワイルド」（以下、BotW）だが、他のオープンワールドゲームより優れている点があるとすれば、バグの少なさなのではないだろうか。僕はハイラルの世界を150時間以上冒険しているが、バグらしいバグに遭遇したのは片手で数えられる程度の回数しかないのだ。 では、なぜBotWはこんなにもバグが少ないのか。「何年も入念に開発してきたからだ」とか「細かいところを丁寧に作り込む日本人の職人魂が備わっているから」とか、そんな理由でも片付けられそうな気がするが
Clean code that works - How can we go there? - Takuto Wada | SeleniumConf Tokyo
Abstract: "Clean code that works" means the sense of value and the goal of programmers. It is not easy to implement it from the beginning. In this speech, you will get to know how obstacles appear on the way to "Clean code that works" and how to resolve them. Also, I will reconfirm role and value of automation testing and refactoring. Bio: Takuto works hard to diffuse TDD culture through writing
「5人でユーザテストすればユーザビリティ上の問題のうち85%が見つかる」の元ネタ論文を解説する｜Mikio Kiura / ANKR DESIGN
Webサービスやアプリなど開発や運用に関わっている方であれば、こんなことを耳にしたことがあるのでは無いでしょうか？ 5人でテストを行えば、ユーザビリティ上の問題のうち85%を発見できるこれらは業界的にはある意味で常識ですが、色々話を聞いてみると、この常識の「出処」あるいは「根拠」ってあんまり知られていないようなのです。 もちろん、ちょっと知識のある人であれば、ユーザビリティ業界の第一人者であるヤコブ・ニールセン博士が提唱したというところまでは知識として知っているでしょう。しかしながら、その元ネタとなった論文を実際に読んだ人、あるいは85%という数字の根拠やその条件について理解されている方はどの程度居るのでしょうか。 ということで本記事では「ユーザテストは5人で85%」の元ネタである下記の論文について、解説、と言うとちょっと大げさかもですが、概要を紹介してみたいと思います。願わくば、この記事
コメントのいらないプログラムの書き方｜NZ MoyaSystem
パラメータを決める 次に関数に渡すパラメータを決めます。 関数の名前で表現されている処理を実現するには、どれだけのパラメータがあればよいか？ と考えてみましょう。 今回の例でいえば「お客さんの年齢」と「日付」があれば、すべてのチケット価格が計算できます。 ということで、age と date の2つのパラメータを渡すことにします。 function calculateTicketPrice (age, date) { } パラメータの名前も、なにを表しているかわかるようにしてくださいね。 くれぐれも「hensu」とか適当な名前をつけたり、同じ変数にぜんぜん違う値を繰り返し代入したりすることのないようにしましょう。 テストを書く 次にユニットテストを書きましょう。 テストは常に更新される仕様書です。 業務ロジックをテストに説明させておけば、関数の仕様をコメントにいちいち書く必要などありません。
ファジング - Wikipedia
ファジング（英語: fuzzing）とは、コンピュータプログラムヘの入力として、無効なデータ、予期しないデータ、ランダムなデータを用いた自動化ないし半自動化されたソフトウェアテストの手法である。コンピュータプログラムにファズ（「予測不可能な入力データ」の意、英語: fuzz）を与えることで、意図的に例外的な状況を発生させ、その例外的な状況での挙動を確認するという方法を用いる。ファズテスト（fuzz testing）とも呼ばれる。また、ファジングの対象プログラムに対してファズテストを実行するツールは、ファザー（fuzzer）と呼ばれる。 概要[編集] ファジングは、コンピュータプログラムの検証プロセスの一環として、構造化された入力を受け取るプログラムをテストするために使用される。この構造化された入力とは、たとえばファイル形式やプロトコルで指定された有効な入力、あるいは無効な入力を指す。ファザ
メモリーリークの検出：mtrace , valgrind：プログラマー社長のブログ：オルタナティブ・ブログ
以前の記事にもLinuxでのメモリーリークの検出に関する事を書いたのですが、もう少し一般的なやり方を紹介しましょう（というより、自分で毎回忘れるので備忘録として・・・）。 【mtraceを使う方法】 まず、mtraceを使う方法です。リークのテストを開始したい場所でmtrace()をコールし、終了したい場所でmuntrace()をコールするようにします。 #include <stdio.h> #include <stdlib.h> char *test() { char *test=malloc(10); return(test); } int main() { char *ptr; mtrace(); ptr=test(); //*(ptr+10)='\0'; //free(ptr); muntrace(); return(0); } -gつきでコ
Rubyにはウンザリ！動的型付け、副作用、およびオブジェクト指向プログラミング全般からの考察 | POSTD
この記事を書き上げるには、相当長い時間がかかりました。本来は今年の年明け、 Rubyの死 やデイヴィッド・ハイネマイヤー・ハンソンの TDDは死んだ がアップされて騒ぎになる前に投稿するつもりだったのです。昨年末に書いたツイートを見てください。 > Rubyにはもう飽き飽きした。理由はいろいろあるが、特にその副作用と、ステータスが可変なせいで大量のユニットテストを書かされるのにはウンザリだ。 @abevoelker Rubyの開発に関しては、大勢の人が心のどこかで何かおかしい、何かが欠けていると思っているようですが、たいていの人は責める対象を間違っています。Rubyで書いたアプリがとんでもない代物になったって？ それはあなたがきちんとテストコードを書かなかったか、テスト駆動開発（TDD）の指針に則って開発しなかったからです。もしくは、正しいデザインパターンに切り分けるための知識が不足してい
TDD is dead. Long live testing. (DHH)
By David Heinemeier Hansson on April 23, 2014 Test-first fundamentalism is like abstinence-only sex ed: An unrealistic, ineffective morality campaign for self-loathing and shaming. It didn't start out like that. When I first discovered TDD, it was like a courteous invitation to a better world of writing software. A mind hack to get you going with the practice of testing where no testing had happen
Python（Scapy）を使って'DHCP DISCOVER' STORMERを作ってみる : NETBUFFALO
皆さんがお持ちの端末（PC、スマートフォン、モデムなど）がIPネットワーク上でオンラインになるまでには、幾つかの連続した手順（シーケンス）が必要で、IPアドレスをリースするDHCPサーバーもそのシーケンスの重要な一部です。 数十～数百の小さなLANで使う分には何を使っても良いのですが、大規模なネットワークを支えるDHCPサーバーには性能が求められます。 何故かと言えば、大規模なネットワークで障害や切り替えが発生した場合、復旧時には、まるで ”STORM” のように、一斉に複数の端末でオンライン・シーケンスが始まることがあるからです。 僕も大規模ネットワークに関わる仕事をしていて、DHCPサーバーの評価・検証・構築に関わる事があるんですが、無料で柔軟性のあるDHCPサーバーの性能評価ツールが少なくて困っていたんです。 しかし、よく考えるとScapyで作れば良いんじゃないの？ と思い立ち、試し
開発メモ#3 : レガシーなCGIアプリケーションのリファクタリング - naoyaのはてなダイアリー
開発メモその3です。今回は Perl のおはなし。 何年も前に作ったウェブアプリケーションのコードを開いてみたら黒歴史なコードが出てきて憂鬱な気分になる、そんな経験ありませんか。私はあります。ずっとそんな現実から目を背けて生きてきました。 さて、先日 Perl + CGI で書いて Apache::Registry で高速化している、実行環境が Apache に癒着した CGIアプリケーションを発見しました。おえ〜っ。一から作り直したい気持ちをぐっと堪えて、これを Plack 化したりとリフォームしていくとしましょう。その過程を以下記します。劇的ビフォア・アフター! ･･･とかは期待せず、地道な変更を積み重ねていくのがコツです。 方針 いきなりコードをがりがり書き換えていくというよりは、試行錯誤のしやすい環境に移行させていきながらリフォームを進めます。遠回りですが、結果的にその後の運用が楽
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
楽天ウェブサービス(RAKUTEN WEBSERVICE) : APIテストフォーム
cqual freecode日本語情報ページ - OSDN
集中型静的コードチェックツール anyWarp CodeDirector for C/C++｜日立ソリューションズ
英語やプログラミングの前に日本語力が必要 - 日本経済新聞
Amazon.co.jp: テスト駆動開発による組み込みプログラミング ―C言語とオブジェクト指向で学ぶアジャイルな設計: James W. Grenning (著), 笹井崇司 (翻訳), 蛸島昭之 (監修): 本
