自動改札機の運賃計算プログラムはいかにデバッグされているのか？ 10の40乗という運賃パターンのテスト方法を開発者が解説（前編）
自動改札機の運賃計算プログラムはいかにデバッグされているのか？ 10の40乗という運賃パターンのテスト方法を開発者が解説（前編） ふだん何気なく使っている鉄道。改札を降りるときにICカードを自動改札にかざすと、「ピッ」という音と共に一瞬のうちに運賃を計算してくれます。けれど、複数の路線を乗り継いだり、途中で定期券区間が挟まっていたりと、想像しただけでもそこには膨大な組み合わせがあります。それでも運賃計算プログラムはわずか一瞬で正しい運賃計算が求められ、バグがあったら社会的な一大事にもつながりかねません。 爆発的な計算結果の組み合わせがあるはずの運賃計算プログラムは、どうやってデバッグされ、品質を維持しているのでしょうか？ 9月12日から14日のあいだ、東洋大学 白山キャンパスで開催された日本科学技術連盟主催の「ソフトウェア品質シンポジウム 2012」。オムロンソーシアルソリューションズ 幡
はじめに ソフトウェアプロジェクトには不思議な性質があります。現状のスケジュールに課題を感じて、短くするために人員を投下しても、なかなか思い通りに短くならない。それどころか悪化してしまうことがあります。場合によってはプロジェクト自体が破綻して失敗してしまうことすらあります。 今回は、このようなソフトウェアプロジェクトに潜む直感に反する性質を数理的なモデルを介して理解していく試みです。ある種の思考実験としてお楽しみください。 宣伝 Qiitaさんとコラボ企画でアドベントカレンダーをつくりました。 DXをめちゃくちゃ改善した話を募集しています。 https://qiita.com/advent-calendar/2021/dx-improvement 10人の妊婦がいても1ヶ月で一人の子供は生まれない これは誰かの技術力やプロジェクトマネジメント力に欠陥があるのではなく、「人月の神話」で有名な
Another HTML-lint gateway
HTML文書の文法をチェックし、採点します htmllint.cgi 1.28 / htmllint.pm 3.58 33,323 lints / 0 visits / since Jan 6, 1998 文法しか採点しません。内容の良し悪しは採点されません。結果に疑問を感じたら必ず結果の解説を読んでください。満点で慢心しないでください。 チェックしない警告は減点対象外で、満点は 100点です。チェックしても減点されない警告もあります。気に入らないチェック項目は外すことができます。お好みに調整してください。 また、基本的な設定項目だけの簡易ゲートウェイもあります。いちいちオプションなんかどうせ指定しないや、という方はご利用ください。 ローカル環境でチェックしたいとお考えの方は、ダウンロードのページを参照してください。 チェック方式 チェックしたいHTMLのURLを指定するか、HTMLを下の
失敗を後悔する「恥」としてはならない。 学習する機会と捉え、次に活かせばいいのだ。 そのためのスキルが品質管理だ。 失敗から学んでダブルチェックだと ちょっと前にこのツイートが流れてきた。 失敗を成功に変える唯一の方法https://t.co/0rF2myVk5I pic.twitter.com/9o88CNqSgj— ゆうきゆう/マンガ心療内科/セクシー心理学 (@sinrinet) June 27, 2021 基本的な主張は賛成だ。失敗から学ぶのはコスパが良い。複雑で全てを理解することができない世界において、対処すべき問題を明確にしてくれるからだ。失敗には特定のパターンがあり、対策しなければ未来にも同じ失敗が発生する。だから失敗から学び対策することは、未来の成功を助けてくれる。そして最も学習効率が高いタイミングとは、記憶が新しい失敗した直後だ。 また、失敗を精神論で終わらせないのも正し
ちゃんとした C# プログラムを書けるようになる実践的な方法～ Visual Studio を使った 高品質・低コスト・保守性の高い開発
トラックのタイヤ脱落事故の原因なんだが
トラックの左後輪に限ってタイヤが脱落する事故の原因だが、これはこの10～15年くらいでタイヤに関する規格が色々変わったせいだ。 以前に整備と管理経験があるので説明したい。 ホイール脱落のメカニズムそもそも重量車のホイールが脱落する時、直接の原因はホイールボルトの折れに因る。だがこれはボルトに問題があるのではない。 ホイールナットはホイールをもの凄い力でハブ（車軸の端でホイールボルトが生えている部品）やブレーキドラムに押し付けている。これによってホイールの裏側とハブ/ドラムの間には巨大な摩擦力が発生する。この摩擦力が車の重量を支えているのである。 つまりボルトには引っ張る力だけしかかかっていない。 これが緩むとどうなるか？ ナットが緩むと先の摩擦力が低減する。そして摩擦力が車両重量を支えられなくなるとこの重さはボルトを切断する力になるのである。1.5cm程度の鉄の棒でトラックを持ち上げられる
楠 正憲（内閣官房 政府CIO 補佐官） 2021年1月 Android版の接触確認アプリCOCOAが数カ月にわたって動作していなかったことが明らかにされた．筆者は 2020年4月から接触確認アプリの導入について，有志での議論に参加し，有識者会議のメンバとして，また途中から政府CIO補佐官として， 接触確認アプリの導入を支援してきた．本稿では接触確認アプリCOCOAの開発と運用について，どのような課題があったかについて振り返る． 接触確認アプリ導入の経緯 筆者が接触確認アプリについて知ったのは昨年（2020年）3月頃のことである．ちょうどシンガポールのTrace Togetherが話題となって，日本でも接触確認アプリをリリースできないかといった話題で，いくつかのコミュニティが盛り上がり始めた． Androidのシェアが高いシンガポールに対して，日本ではiPhoneのシェアが非常に高く，iP
Coding Horror - Quantity Always Trumps Quality Art & Fear という芸術家向けの本の中に，こんなエピソードがある ― ある陶芸クラスでのこと，最初の授業において，教師は生徒をふたつのグループに分けた。一方のグループは作品の「量」によって評価を行うとし，もう一方のグループは作品の「質」によって評価を行うとした。 これはどういうことかというと，「量」グループの生徒たちは，提出した作品の量のみによって評価が下される。作品の総重量が５０ポンドに達していたらＡ評価，４０ポンド台ならＢ評価，というように。それに対して「質」グループの生徒たちは，たったひとつの最高の作品を提出すればいい。その作品の出来に対して評価が下される。 すべての授業が終わり，さて評価は，となったとき，少し奇妙な事実が判明した。提出された作品のうち，最も高い質を持つものは，すべて
女の武器はどこまで通用するか" /><summary type="text/plain">[video]</summary></entry>
( ! ) Notice: Use of undefined constant id - assumed 'id' in /home/users/0/tfukatsu/web/app/hatenatube/index.php on line 19 Call Stack #TimeMemoryFunctionLocation
LT大会にお呼ばれしました。 内容は以前ブログにしたためた「コードレビューするのが怖いと思っていたエンジニアが半年間コードレビューを経験して思った 10 のこと」についてです☺ http://b.hatena.ne.jp/entry/yutokyokutyo.hatenablog.com/entry/20161213/1481590322
世界中のITエンジニアが悩まされている原因不明でテストが失敗する「フレイキーテスト」問題。対策の最新動向をJenkins作者の川口氏が解説（前編）。DevOps Days Tokyo 2022
世界中のITエンジニアが悩まされている原因不明でテストが失敗する「フレイキーテスト」問題。対策の最新動向をJenkins作者の川口氏が解説（前編）。DevOps Days Tokyo 2022 世界中のITエンジニアが悩まされている問題の1つに、テストが原因不明で失敗する、いわゆる「フレイキーテスト」があります。 フレイキーテストは、リトライすると成功することもあるし、失敗する原因を調べようとしてもなかなか分かりません。GoogleやFacebookやGitHub、Spotifyといった先進的な企業でさえもフレイキーテストには悩まされています。 このフレイキーテストにどう立ち向かうべきなのか、Jenkinsの作者として知られる川口耕介氏がその最新動向を伝えるセッション「Flaky test対策の最新動向」を、4月21日、22日の2日間行われたイベント「DevOps Days Tokyo 2
私たちソフトウェアエンジニアは、コード品質についてしばしば論ずるけれども、ではコード品質の良し悪しがどれほどビジネスに影響するのかと問われると、回答に窮する。只々、「コード品質が悪いと変更により多くの時間がかかります」だとか、「欠陥の修正に追われて開発時間が奪われます」だとか、個人の経験やエンジニア的一般論に頼った定性的な説明に終始するしかない。ソフトウェアを繰り返し変更する頻度が高いほど、コード品質が開発時間に影響を与えるのは確かにそのとおりだと思えるが、はたしてそれは、どれほどのインパクトなのだろうか。 2022年の研究論文 "Code Red: The Business Impact of Code Quality – A Quantitative Study of 39 Proprietary Production Codebases" では、コード品質がビジネスに与えるインパクト
∃ナハセド🇳🇿🏳️🌈🏳️⚧️🇵🇸通知OFF @yonahasedo1 繰り返し言ってるけど、「人口100人の村で70人が結託して残り30人を奴隷にするよう多数決で決める」は民意と言えるし全体主義だけど民主主義ではありません。民主主義にはこの場合に「30人の人権に触れるので、この多数決は無効です」と撤回出来るフールプルーフの仕組みが存在します。 2022-07-21 00:10:23 ∃ナハセド🇳🇿🏳️🌈🏳️⚧️🇵🇸通知OFF @yonahasedo1 あえてフールプルーフって言っとくよ。「30人を奴隷にするのは民意です。この30人の中には奴隷になる事を望んでいる者もいます。民主主義では民意に逆らってはいけません」は完全にフールだもん 2022-07-21 00:16:50 ∃ナハセド🇳🇿🏳️🌈🏳️⚧️🇵🇸通知OFF @yonahased
太平洋戦争で日本軍と戦ったイギリス軍のある司令官は、日本軍の上層部の体質を次の様に喝破していた。 「日本軍の指導者の根本的な欠陥は、“肉体的勇気”とは異なる“道徳的勇気の欠如”である。彼らは自分たちが間違いを犯したこと、計画が失敗し、練り直しが必要であることを認める勇気がないのだ」（第14軍 ウィリアム・スリム司令官 ※タイトル画像の人物） 戦いの舞台となったのは、インパール作戦で知られるビルマ戦線（現在のミャンマー）。実は、太平洋戦争で“最も無謀”といわれたインパール作戦のあと、それをはるかに上回る命が失われていたのだ。 指導者たちのどのような体質が、さらなる“地獄”を作り出したのか。 77年の時を経て、私たちが直視すべき「道徳的勇気の欠如」、その実態をひもとく。 （NHKスペシャル「ビルマ絶望の戦場」取材班）
以前に私が書いた「 Dockerの本番運用：失敗の歴史) 」という記事は、非常に多くの反響を呼びました。 その後、長い議論を交わして、何百件ものフィードバックや何千件ものコメントを読み、さまざまな人々や主要事業者とも顔を合わせました。Dockerでの試みが増えるほど、その失敗談は増えていきます。そうした現状を、今回アップデートしておきたいと思います。 この記事では、最近の交流や記事から得た教訓を紹介しますが、その前に簡単におさらいをして軽く背景を説明しましょう。 免責事項：対象読者 たくさんのコメントから、世の中には10種類の人々が存在するということが明らかになりました。 1) アマチュア 実際のユーザがいない試用版のプロジェクトやサイドプロジェクトを実行している人々です。Ubuntuのベータ版を使用するのが当然だと考えており、「安定したもの」は古いものと見なすようなタイプです。 注釈：書
2019/10/31(金)に開催されたEngineering Organization Festival 2019 で @t_wada さんの「質とスピード」という講演を聞き、とても感銘を受けたのでメモ。 品質とスピードはトレード・オフの関係にある。どちらを優先するか？要バランスだ。 そう思っていた時期が私にもありました。 けど、そんなことはなかった！ ■追記 個人的な捉え方としては、 プロダクトを漸進的に成長させ、仮説検証ループするスピード上げようとすると、犠牲にした保守性があとで(意外とはやく1ヶ月後には)足枷になる。 保守性(テスト容易性、理解容易性、変更容易性)が低いとリードタイムが延びてスピードがどんどん落ちていくループをまわせなくなる。ってことかな、と思う。 スピードを上げようとしたのに、意外とはやくスピードが上がらなくなるジレンマ。 @t_wadaさんのスライド 素敵なグラレ
質とスピード 初演: 2019/10/31 @ EOF2019
Revision 2.1 This style guide contains many details that are initially hidden from view. They are marked by the triangle icon, which you see here on your left. Click it now. You should see “Hooray” appear below. Hooray! Now you know you can expand points to get more details. Alternatively, there’s a “toggle all” at the top of this document. This document defines formatting and style rules for HTML
2016年11月3日（祝）、大田区産業プラザPiOにて開催された国内最大のPHPイベント「PHPカンファレンス2016」。レバテックフリーランスでは、カンファレンスセッションの登壇者のひとり・和田卓人氏にインタビューを実施しました。 テスト駆動開発の先駆者として知られる和田氏ですが、今回の講演テーマは「PHP7で堅牢なコードを書く-例外処理、表明プログラミング、契約による設計」。あえてテスト以外のテーマを設定した理由をはじめ、PHPの優位性や今注目している言語、初心者エンジニアへのアドバイスなど、幅広くお話を伺ってきました。 ＜この記事の要約＞ 1. PHPの良い点は、ゆるふわな言語に見せかけて堅牢なコードも書けるところ。悪い点は、覚えることが多くて難しいところ。 2. テストを書いていればコードの品質が高いわけではない。また、テストが書けないくらい問題を抱えたコードでも、中から改善してい
グーグルでは、社内のプログラマによって作り出される大量のコードの品質を保つため、チェックイン前にユニットテストとコードレビューが行われているそうです。しかし、コードが大量になってくると、ユニットテストやレビューをすり抜けるバグも少なからず発生します。 そこでコードの品質をさらに高めるために、グーグルでは「バグ予測アルゴリズム」を採用。バグがありそうな部分をレビュアーにアドバイスする仕組みを採用したとのこと。 そのバグ予測アルゴリズムとはどんなものなのか。Google Engineering Toolsブログに投稿されたエントリ「Bug Prediction at Google」（グーグルにおけるバグ予測）で説明されています。 ソースコードの修正履歴を基に予測 コードの中にバグがありそうな箇所を分析する手法としては、「ソフトウェアメトリクス」がよく用いられます。これはコードを静的に分析して、
［CEDEC 2017］「ゼルダの伝説BotW」の完璧なゲーム世界は，任天堂の開発スタイルが変わったからこそ生まれた
［CEDEC 2017］「ゼルダの伝説BotW」の完璧なゲーム世界は，任天堂の開発スタイルが変わったからこそ生まれた ライター：西川善司 CEDEC 2017は，任天堂からの登壇者が例年に比べて非常に多い。数えてみると8件あった。「海外のカンファレンスでは登壇する一方，日本国内のカンファレンスにはあまり出てこない」という，これまでの傾向からは一転した新しい動向と言える。「ゲーム開発シーンにおける知見の共有」において，これまであまり積極的でなかった任天堂だが，意識を変えてきたのだろうか。 いずれにせよ，CEDEC 2017で任天堂は，「ゼルダの伝説 ブレス オブ ザ ワイルド」（Nintendo Switch / Wii U，以下，ゼルダの伝説BotW）関連セッションを4本も持った。今回はその中から，開発者でない一般のゲーマーにも分かりやすかったと思われる「『ゼルダの伝説 ブレス オブ ザ
ソースコードのなかでバグが多いのは、より高頻度に、かつ最近になって集中的に直している部分。これが、グーグルで採用された「バグ予測アルゴリズム」であることを、先月の記事「グーグルはコードの品質向上のため「バグ予測アルゴリズム」を採用している」で紹介しました。 そのバグ予測アルゴリズムを実装したツール「bugspots」がオープンソースとして公開されています。 gitのレポジトリを分析 bugspotsはRubyで記述されており、gitのレポジトリから履歴を読み込んで分析し、どのモジュールにバグが含まれている確率が高いかを示してくれます。 以下のようにインストールして実行（説明ページから引用）。 $> gem install bugspots $> git bugspots /path/to/repo $> git bugspots . # (in current git directory)
Android と iPhone との比較は多くの点で議論されており、どちらがより良いかは、Android の画像の質は iPhone とくらべてずっと劣るという点を除けば、未だ結論が出ていません。Facebook、Twitter、Instagram 等どれを使っていても、写真をとって、フィルタをかけて、ソーシャルネットワーク上に公開すると、いつも Android から投稿される写真は画質が劣化しています。しかし何故でしょう？ 私達は昨年の間調査をし、そしてついに、Google が犯したほんのちょっとしたミスが原因であることを突き止めました。それは本当にちょっとしたミスでしたが、その影響はすべての画像を扱うアプリケーションに波及するほど大きく、現在に亘っても影響が続いています。 問題は、libjpegです。 libjpegといえば、数多くのオープンソースプロダクトでも使用されており、And
＊＊ 2014/09/23 24:00 追記＊＊＊ 想像以上に記事が注目を集めてしまい、私の主観に基づく見解で書かれたT440sとLenovoのイメージが拡散してしまうのは本意ではありませんので、個人的な意見や見解は削除しておきます。よろしくお願いいたします。 --------------------------------------- 度重なるT440sのトラブルに、思うことはあるのですが、Lenovo本家が運用している掲示板でも T440s nightmare というスレッドが立ち上がっており、盛り上がってる感じでした。 この1年間にT440sで発生したことを記録しておきます。 いきなり初期不良品にあたりました。 不良1点目 PC背面のパネルのネジがスカスカで止まらない(受け側にねじ山が無い？）そんな馬鹿な？と思う方もいると思うが、ほかにも同じ症状の方が動画挙げているのでご覧いただき
飛び交う怒号、やまない電話、不夜城と化した会議室。 集められたホワイトボードが衝立のように立ち並び、全員が立って仕事をしている（座る間が無いから）。週をまたぐとメンバーの疲弊が目に見えはじめ、月を跨げば一人二人といなくなり、仕事場はお通夜となる。 トラブルの無いプロジェクトは存在しない。炎上するかボヤで済むかの違いなだけで、大なり小なりトラブルは付きものである。 自分が所属する部署は大丈夫かもしれない。だが、隣のブースだとか、同期がいるチームで炎上しているのを横目で見ながら仕事する、なんてことがある。ホワイトボードは目につくし、大きな声はイヤでも耳に入ってくるので、プロジェクトが炎上⇒鎮火するパターンなんてものも、なんとなく伝わってくる。 消火作業のイロハとか、怒った客をあしらう方法、リカバリ計画の立て方なんてのも、肌感覚で分かってくる。 そして、トラブルの扱いが分かってくる頃には、「応援
質とスピード（2020春版） / Quality and Speed 2020 Spring Edition
質とスピード（2020春版） 2020/02/13 @ デブサミ2020
質とスピード（2022春版、質疑応答用資料付き） / Quality and Speed 2022 Spring Edition
質とスピード（2022春版、質疑応答用資料付き）
答えが分からないものを模索しながら作り続ける世界に我々は突入した。和田卓人氏による「組織に自動テストを根付かせる戦略」（その1）。ソフトウェア品質シンポジウム2022
答えが分からないものを模索しながら作り続ける世界に我々は突入した。和田卓人氏による「組織に自動テストを根付かせる戦略」（その1）。ソフトウェア品質シンポジウム2022 9月22日と23日の2日間、一般財団法人日本科学技術連盟主催のイベント「ソフトウェア品質シンポジウム2022」がオンラインで開催され、その企画セッションとして行われた和田卓人氏による講演「組織に自動テストを書く文化を根付かせる戦略（2022秋版）が行われました。 講演で、企業の業績はソフトウェアの開発能力に左右されるようになってきていること、その開発能力を高める上で重要なのがコードの「テスト容易性」や「デプロイ独立性」であると和田氏は指摘。その上で、それを実現させるような「自動テストを書く文化」をどうすれば組織に根付かせることができるのか、講演の後半ではこの本質的な議論へと踏み込みます。 本記事は、2時間におよぶこの講演をダ
『龍が如く7』は進化を続け、自動バグ発見どころかほぼ全自動のバグ取りシステムを構築。これぞ無職から勇者に成り上がるデバッグだ！【CEDEC 2020】 | ゲーム・エンタメ最新情報のファミ通.com
本記事では、1日目におこなわれた『龍が如く7 光と闇の行方』（以下、『龍が如く7』）のデバッグに関するセッション“「龍が如くスタジオ」のQAエンジニアリング技術を結集した全自動バグ取りシステム”をリポート。 セッションには、セガのQAエンジニア・阪上直樹氏と、ビルドエンジニアの粉川貴至氏が登壇した。 バグをハグしたくなる自動システム！ まずは阪上氏が開発者たちへ向けて、「バグは好きですか？」という質問からセッションがスタート。最初に龍が如くスタジオの各タイトルで、バグを発見した数の推移が公開された。ゲームの規模が大きくなるにつれ、バグも増加傾向にあるという。 そして全自動バグ取りシステムを運用した『龍が如く7』では、なんと25000ものバグが発見されたという。こう見るとネガティブな印象を受けるかもしれないが、バグ発見数が多ければ多いほど、ゲームクオリティがアップするということだ。 バグとい
※品質保証のエンジニアである筆者が自省・戒めのために書いた記事になります 品質管理（Quality Control）、品質マネジメントは国内では製造業を中心に発展し、プロダクトの競争力向上に貢献してきました。 JTCと呼ばれる旧来からのメーカーでは、その実績・年功の蓄積に応じて、独立性を保った品質管理・品質保証部門が権威を獲得し、今でもソフトウェア開発に強い影響力を保持するようになっています。筆者は複数のメーカーを転職やコンサルで巡って来ましたが、例えば品質保証部門が承認しないとマイルストーンで開発がブロックされる、プロダクトがリリースできないといった権限を持つ体制が、今なお普遍的に見受けられます。 この品質保証部門が権力を持ち、品質ゲートの門番として振る舞う体制は、今であっても、ある面で恩恵を提供しています。例えば次のようなものです： 法規制対応、標準化対応、その他公的なガバナンス要求へ
開発速度と品質のトレードオフの判断基準の合意 - Hatena Developer Blog
Webサービスの開発は、ユーザ/顧客へ価値を早く届けるため、競合より早くリリースするため、人的リソースを無駄使いしないためなど、とにかく素早く進めたいものですね。一方で、開発を急ぐあまり品質を犠牲にすればかえって価値が失われたり、技術的負債が溜まって長期的なコストが大幅に増大する可能性もあります。開発速度とプロダクト品質は基本的にはトレードオフの関係にあるのでしょう。 開発速度と品質のどちらを優先するかはプロダクトの性質や、チームもしくは会社の状況によって異なるとおもいます。この状況の認識がチームメンバー間でずれていると、チームのパフォーマンスを最大限に発揮できないばかりか、チーム内の関係悪化も招きかねません。エンジニアたちとプロダクトオーナーの間の対立のようなありがちな問題の原因の一つかもしれません。 そこで、開発速度と品質のトレードオフをどう判断すべきかの基準を明確にして、原則それに従
うちゃか @sayakaiurani 会社の全体リニューアルに注力してて「吐きそう」って言ってた友達に「結果どうなった？」って聞いたら送られてきた画像が全てを物語っていた。そう、業界あるあるに彼もまた飲み込まれたのだ。 pic.twitter.com/xjJCQvtzrK 2020-11-03 22:25:53
クソコードの測り方
PHPBLT#3 で話した内容です。
テスト自動化の理論と技術と戦略：LINE Developer Meetup Tokyo #39 - Testing & Engineering - LINE ENGINEERING
テスト自動化の理論と技術と戦略：LINE Developer Meetup Tokyo #39 – Testing & Engineering By Hiroyuki Ito | 2018.07.09 2021.01.08LINE株式会社のSET（Software Engineer in Test）です。「SETタスクフォース」（以下「SETチーム」と表記）のリーダーとして、主にLINEプラットフォームのサーバーサイドで、テスト自動化を活用したプロダクト開発ライフサイクルの改善を立案・実施・主導しています。また、アジャイルコーチも兼務しています。 はじめに こんにちは。LINE株式会社のSET（Software Engineer in Test）の伊藤 宏幸（Hiroyuki Ito）です。 2018年6月27日（水）に、電気通信大学の西 康晴さん（以下「にしさん」と表記）をお招きして、「
最近Amazonのサービスの劣化が著しい。9月以降のみに限っても次のような惨状だ。 2008年9月7日：現金還元サイト『小判』がAmazonのポイント還元を終了。これまでは小判経由で購入すると、Amazonポイントとは別に2%の還元がなされていたが、それが無くなった。 2008年9月11日：ショッピング・パレットがAmazonのポイント還元を終了。これまではショッピング・パレット経由で購入すると、Amazonポイントとは別に4%の還元がなされていたが、それが無くなった。 2008年12月15日：Amazonクレジットカードが終了。これまではAmazonクレジットカードで購入すると、Amazonポイントとは別に2%の還元がなされていたが、それが無くなる。 さらに、Amazonは配送業者の変更を行っているようだ。9月より配送先が千葉県であるユーザに対しては、旧来の日通ではなく、カトーレックと言
今月上旬に、川崎から東京に引越した。 主に通勤時間短縮が目的で、あとは生活の質を向上させたいよねということで、通勤時間片道２０分短縮できて、これまでの１．５倍くらいの広さのところに引越すことにした。 夫は家で仕事をしているので作業空間が大事というのはまぁ川崎の家でも同じだったけど、折角引越して家が広くなったので、色々試したらかなりＱＯＬが向上したので、ブログに書きます。 ２つのテーブル 部屋の主役は、オーク無垢材のダイニングテーブルで、作業するのに充分な広さがある。 お茶をよく飲むので、ＰＣ以外にお茶セットを置いている。 週末には椅子を引っ張りだしてきて、ハッカソンをします。（５人くらいまでならいける） ダイニングテーブル135 価格：59,400円（税込、送料別） ハンス・ウェグナー ザ・チェア 価格：12,629円（税込、送料別） 今回、早い段階で追加購入したものの一つが、カウンターテ
品質に厳しい組織で、なぜ品質が劣化するのか？ - 現場のためのソフトウェア開発プロセス - たかのり日記
このエントリーは「Software Test ＆ Quality Advent Calendar 2011」における12/18分として書いています。 12/17は @NoriyukiMizuno さんによる 「ソフトウェアテストの勉強会。1年目。」 というエントリでした。 今回は、以前から感じている矛盾について、私なりの考えをまとめたものです。 特に、マネージャーや経営層と呼ばれる人に読んでもらいたいと思っているのですが、このブログの読者層を、考えると、あまり多くはなさそうなので、以下に示す問題について、悩んでいる／苦しんでいるような人から、うまく伝われば良いと思っています。 矛盾する問題 私は、SEPG（Software Engineering Process Group）という役割上、いろいろなソフトウェア開発のプロジェクトや組織に関わってきました。 絶対数で言えば、そんなに多くはない
テスト／品質系エンジニアが身に付けておくと得をする7つの技術 - 現場のためのソフトウェア開発プロセス - たかのり日記
「Software Test & Quality Advent Calendar 2011」の初日エントリーとして、書きます！ テスト／品質系のエンジニアも、今や、テストや品質のことだけを知っているだけでは、幸せにはなれない時代となってきています。 プログラムは書けなくても、身に付けておくと良いと思っている技術をまとめてみました。 ※注 今回記述した内容は、以下のような私のドメインに偏ったモノになっています。 ミッションクリティカル／エンタープライズ系 Java／.NET 他のドメインでは異なる部分や他の標準的なツールがあれば、コメントを頂ければと思います。 バージョン管理／課題管理 今や、必須のスキルと言えるでしょう。 バージョン管理（SCM／VCS／DVCS）としては、 集中型のSubversion（SVN） 分散型のGit／Mercurial などが有名ですね。 分散型の場合は、各エ
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
なぜ、ソフトウェアプロジェクトは人数を増やしても上手くいかないのか - Qiita
日常の失敗も品質管理で解決できる - 本しゃぶり
ソースコードの品質向上のための効果的で効率的なコードレビュー
Azureテクノロジ入門 2016 目次 - 日経BP書店
接触確認アプリCOCOAからの教訓｜情報処理学会・学会誌「情報処理」
質より量に学ぶ - Radium Software
先輩から教えてもらったコードレビュー
コード品質はやはりビジネスに影響を与える - mtx2s’s blog
「100人の村で70人が結託して30人を奴隷にするよう多数決で決める」は民主主義ではない、という話「わかりやすい」
インパール作戦後の“地獄”指導者たちの「道徳的勇気の欠如」 | NHK | WEB特集
Dockerの本番運用 | POSTD
やはり俺の「質 v.s. スピード」はまちがっている。 #eof2019 - 名前考えるの苦手
質とスピード / Quality and Speed
Google HTML/CSS Style Guide
フリーエンジニアのIT案件ならレバテックフリーランス
グーグルはコードの品質向上のため「バグ予測アルゴリズム」を採用している
グーグルのバグ予測アルゴリズムを実装したツール「bugspots」、オープンソースで公開
なぜ iPhone の画像は Android の画像よりもずっと高品質なのか - Qiita
もうLenovo製品は永久に買わない、というお話
炎上プロジェクトの火消し術『プロジェクトのトラブル解決大全』
Webサイト品質管理のチェック項目リスト | 人手に頼らないWebサイトの戦略的品質管理指南
品質保証部門の陳腐化。そして陳腐化した品質保証は品質を悪化させる - 千里霧中
会社サイトの全体リニューアルに注力していた友達に「どうなった？」って聞いたら送られてきた画像が結果の全てを物語っていた
Amazonのサービスが急激に劣化している件について - A Successful Failure
引越して家の中を整えたらＱＯＬがかなり向上した話 - 本トのこと。