6年勤めたNTTを退職しました - Software Transactional Memo
最終退社時の自分の机 2012年に修士卒からの新卒でNTT研究所に入り、6年間お世話になりました。 研究所では同期や先輩や後輩や上司に恵まれ、存分に書籍や論文を読んで勉強して力を蓄えたり、対外的な発表の場にも恵まれ外ではできないような体験をすることができました。 ありがとうございました。 入社当時に作られたtogetterを見返すと togetter.com togetter.com まるで昨日のように感じられる。 NTT社内で僕が何をやっていたかについては言える物は軒並みアウトプットされているのでわざわざここでは触れない。 NTT研究所について NTT研究所を客観的に見た時にどうかを書いていく とにかく人に恵まれている。採用の倍率が高いのもあって潤沢な学生エントリーからよりすぐりのエリートが謎の力でポテンシャルを見極められて採用されている。同期を見てひと目ですごい奴も居れば、一見してわか
Ericssonの『ユニットテストカバレッジの神話』を読んでみる - ソフトウェアの品質を学びまくる
今年の4月に『Mythical Unit Test Coverage』（ユニットテストカバレッジの神話）という論文が出ました。ソースコードの品質指標として言及されることの多いコードカバレッジについて、先行研究を整理したうえで、商用の大規模ソフトウェアにおける追加検証をしたものです。IEEEのサイトでも全文公開されています。 Mythical Unit Test Coverage - IEEE Journals & Magazine 長い論文ではないのですが、わたしには論理展開のわかりづらい部分があったので、整理してみました。 アブストのアブスト 「リリース前にどれだけのテストをすべきか」というのはずっと問題。 テストの十分性の指針として、Ericssonで長年使ってきたユニットテストのカバレッジのクライテリアを検証した。 結果として、ユニットテストカバレッジは、欠陥のないソフトウェアを作る
世界基準の認定資格「ISTQB テスト自動化エンジニア認定資格」をゲットしました！ | メルカリエンジニアリング
ロンドンは歴史豊富で、町並みの綺麗な所です！ こんにちは。メルカリのAutomation & QAグループ（通称：AQA）でAutomationエンジニアをぶりぶりしている@gloriaです。現在、私は主にiOSアプリの自動化を担当しています（詳細はtadashi0713によるこちらの記事をご覧ください）。 私は先月、ロンドンで開催された「ISTQB Advanced Level – Test Automation Engineer Certification」のトレーニングコースに参加しました。 ＊ なお、この記事は、@gloriaの原文（英語）を意訳しております。原文はこの記事の下部にありますのであわせてお楽しみください。 ISTQBとは？ この認定テストはISTQB Foundation Levelの延長線上にあるもので、ソフトウェアテストと品質保証の国際的なガイドラインを提供するも
テスト駆動開発における進化的設計とデザインパターンの勘所とは？〜テスト駆動開発をやめて、なお残すべき習慣とは(9)
前回から、書籍を辿り、TDDの再考を試みています。TDDを既に知っている、実践しているという人にとっては、TDDについて新しい発見、ジャメヴ（未視感）が起きれば幸いです。たとえTDDが不要だったとしても、不要だと判断したものが一体何だったのか知ることは欠かせません。 忘れないで、テスト駆動開発にもデザインパターンの話が出てくるよTDDはテストファーストやベイビーステップのインパクトがありすぎて、あまり目立っていないですが、書籍『テスト駆動開発』にもソフトウェアパターンの話が出てきます。そう、出てくるんですよ。 余談ですが、テスト駆動開発３部におけるSingletonパターンの説明はGoFの説明とは違ったユニークな内容になっています。（本で確認してみてね） 1回だけ設計ではなく繰り返し設計注意点ですが、テスト駆動開発においてのソフトウェアパターンは、プロジェクト初期に１回だけパターンを使って
第44回 2018年3月～修正できない脆弱性対応、繰り返される歴史、そして「あたりまえ」を実践すること | gihyo.jp
インフラセキュリティの処方箋 第44回2018年3月～修正できない脆弱性対応、繰り返される歴史、そして「あたりまえ」を実践すること 今月は、時折見られる「開発者と連絡を取れず、修正できない（修正を期待できない）脆弱性」、繰り返される「攻撃」の歴史、そして「あたりまえ」という3つのトピックについて解説します。 「連絡不能案件」扱いされるソフトウェアの脆弱性対処 通常、ソフトウェアに脆弱性がある場合、当該ソフトウェアの開発者に連絡が行き、開発者による脆弱性修正がなされるのが通例と考える方が多いかと思います。実際、情報セキュリティ早期警戒パートナーシップの枠組では、IPAが受付機関となり、JPCERT/CCが調整機関となって、開発者との連絡を取り、脆弱性情報を提供した上で、脆弱性修正および修正版の公開を推進します。 しかし、脆弱性があるソフトウェア開発者との連絡がつかない場合には、このような
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
