感染ピーク、緊急事態宣言の前だった 専門家会議が評価：朝日新聞デジタル
","naka5":"<!-- BFF501 PC記事下（中⑤企画）パーツ＝1541 -->","naka6":"<!-- BFF486 PC記事下（中⑥デジ編）パーツ＝8826 --><!-- /news/esi/ichikiji/c6/default.htm -->","naka6Sp":"<!-- BFF3053 SP記事下（中⑥デジ編）パーツ＝8826 -->","adcreative72":"<!-- BFF920 広告枠）ADCREATIVE-72 こんな特集も -->\n<!-- Ad BGN -->\n<!-- dfptag ＰＣ誘導枠５行 ★ここから -->\n<div class=\"p_infeed_list_wrapper\" id=\"p_infeed_list1\">\n <div class=\"p_infeed_list\">\n <div class=\"
オープンソースの開発現場では限られたリソースで品質管理をどうしているのか。Twitter4J、GitBucket、Asakusa Framework、power-assertの作者が討論（前編）
和田氏 このセッションは、OSSにおける品質管理やテストなどをどう考え、運営しているのか、という内容でパネルディスカッションをさせていただきます。まずは登壇者がどんな方か、自己紹介してもらおうと思います。 竹添氏 ビズリーチの竹添と申します。転職サービスの会社なのですが、今日は個人で「GitBucket」という、GitHubのような機能を提供するWebアプリケーションを作っているので、その立場で参加させていただきます。 もともと僕はSIerにいて、そのときはGitHubのような外部のサービスを使えなくて、それで社内でもGitHubのようなサービスが使えたらいいなと思ってGitBucketをはじめました。 なのでGitBucketはGitHubを参考に開発を始めたのですが、同じようなニーズを持ったお客さんが国内にも、海外にも多くいるので開発を続けています。 川口氏 ノーチラス・テクノロジーズ
バグゼロを実現した話とその後の顛末 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、アプリケーション基盤チームの青木(@a_o_k_i_n_g)です。好きなメソッドは emptyIfNull です。 僕は、自社クラウドである cybozu.com のミドルウェアを開発するチームで働いています。具体的には、検索サービスやファイルサーバー、非同期処理用ワーカー、セッションマネージャーなどなどを提供しています。 僕がこのチームに来たのは数年前ですが、当時はバグの多いプロダクトでした。今はすべての既知のバグを直し、残存不具合件数が 0 件、つまりバグゼロな状態になりました。また、バグゼロを実現してから 2 年ほど経過していますが今もその品質を保っています。今回はこのバグゼロを実現した方法と、その後の顛末について記そうと思います。 以前のコード 数年前に提供されていたこのミドルウェア群は、はっきり言って、バグの塊のようなプロダクトでした。 当時のコードは保守性とは程遠い
技術的負債を管理する
日付2013-5-18(Sat) 書いた人おかざわ (id:yujiorama) 書いた理由技術的負債はいつ読んでも面白いんだけどそろそろ普通に向き合いたくなったので。 技術的負債を管理する 技術的負債は悪いものとみなされている。避けるべきものであり、できるだけ早く支払うべきものなのだ。 あなたもそう思うだろうか？私たちはそうは思わない。最初に技術的負債と財政的負債を比較して、戦略の設計とステークホルダーにおける類似点について驚くべき点があることを説明する。それからコード中の技術的負債を識別するための様々な可能性について一覧にする。それらはきっとあなたが対処しなければならないものだ。 最後にプロジェクトが技術的負債を返済するために取りうるいろんなやり方について述べる。あなたが返済したほうがよいのか、負債を変換するほうがよいのか、ただ注意を払うだけでよいのかを考える時にきっと役に立つだろう。
コードレビューについて - camlspotter’s blog
このところ立て続けにコードレビューについて話をする機会があったので 私が経験した最高のレビュー体制を簡単にまとめておこうと思います。 利点 何故必要か 何が嬉しいのか コスト うまく回すためには何が必要か 細かい運営方法 はっきり言って当たり前の事しか書きません。 私も当時は当たり前のことだと思っていましたから、特に気にもしていなかったのです。 ただ見聞するところによると、これをちゃんとやっているところはとても少ないようです。 ウォールストリート系のファンドでもろくにレビューしてないとかどういうことなんでしょう。 だから時々会社が吹っ飛ぶんですね… 結局は、ああだ、こうだ各論を言っても、ちゃんとやれるのか、それ一点に尽きてしまう話なのですが… 利点 レビューを何のためにするか、それはまず第一に自分達の書いているコードに潜在するバグによる損失をできるだけ少なくすることでしょう。 型システムや
走行中に新幹線はどのくらい変形するか：おきらくプログラマー
IT技術者として現場で働いていましたが，現在は母校の大学にて教員を務めています．趣味の風景写真を中心に，日々の出来事をお気楽に綴っていきます． 生まれ：1977年，東京都 性別：男 趣味：ドライブ，風景写真を撮ること 性格：楽観的なときもあるけどどちらかと言えばネガティブな思考．よく「自分に自信をもちなよ」と言われます． 座右の銘：特にないけど「出る杭は打たれる．出過ぎた杭は誰にも打てない．」は心に残る言葉の一つ． コメント・トラックバックはご自由にどうぞ．明らかに関連が薄いものは削除する場合があります．本ブログで使用しているCookieについてはこちらをご参照ください．本ブログの広告収益の一部はユニセフなどの慈善事業者へ寄付しています．
「ドラクエIX」発売延期の理由は 「油断していた」と和田社長
スクウェア・エニックスの和田洋一社長は2月12日、決算会見の席で、ニンテンドーDS用ソフト「ドラゴンクエストIX 星空の守り人」の発売日を3月28日から7月11日に延期した理由について、「デバッグが間に合わなかったため」と説明した。 延期の理由を問われた和田社長は、「ドラクエは、（機能の実装が）できあがったため油断していた。傲慢（ごうまん）だったと反省している」と切り出した。 実装が済み、本格的なデバッグに入った段階で「手強いバグがいくつもあることが判明した」という。バグの量は「とてもお客様に出せる状態ではない」ほど大量。「もう少しチューニングしようというレベルではなく、今出すべきでないことは明らかと判断した」 特に「ドラゴンクエストのチームとしては未開拓の通信分野」が強敵。「ゲーム全体でもまだまだバグは取り切れておらず、まして通信についてかなり掘り下げる必要があるため、十分な期間を取った
Joel on Software - ジョエル・テスト
Joel Spolsky ジョエル・スポルスキ 翻訳: Fukushige Erika 福重 永里香 翻訳チェック: Takeda Toshiyuki 武田俊之 9.8.2000 SEMAについて聞いたことがある？かなり難解なシステムで、ソフトウェアの開発チームがどれくらい良いかを測るためのものだ。ちょっと待った！そのリンクに飛ばない方がいい。きっと書いてあることを理解するだけで6年はかかるだろう。そこで、私は自分で作ることにした。これはソフトウェア開発チームの質を評価するものだが、とっても当てにならないいいかげんなテストだ。このテストの素晴らしいところは、3分程度で終わることだ。節約した時間を使って、医学部に通うことだってできるだろう。 ジョエル・テスト ソース管理システムを使っているか？ １オペレーションでビルドを行えるか？ 毎日ビルドを行うか？ 障害票データベースを持っているか？ 新
プログラマが仕様を決めればいい - GoTheDistance
最近よく思います。 システム開発の上流工程においてはコードは出てこない。言葉や図解で埋めつくされて、最終的には日本語でしかない。設計書とか仕様書とか。で、この大抵上流工程ではこれらのドキュメントに対するレビューなるものがあるのですが、これが実に無益なものだと感じることが多い。こんな所でPDCAまわして何が面白いんだろうとよく思う。 ここでチェックする多くのことは、言葉の解釈に関することがほとんどです。 この言葉はプロジェクトで使われていない 書き方が統一されていない 誤字脱字が多いので直せ。 この文章ではこのように解釈される恐れがある ここではこのような話になっていたがどうなのか こんなんばっか。どこもそうだと思う。解釈の違いは、要件の違い。なんちゃって。 で、結局こういうことを繰り返していくうちに段々とドキュメントがグダグダになっていく。そして繰り返していっても前提が変わってしまえば全部
デスマになるのはPDCAを滝に対して垂直に回すから - 404 じゃばてないわー Not Found(一部X-RATED)
ちょっと書いてみる最近、PMBOKだかを読むような人も増えてると思うけど、いくら読んでもデスマは解決しないのは、PDCAを滝に対して垂直に回すから。PDCAと滝の関係はP設計D開発CテストA修正と水平に回るべきなのに、今はこうなってる。PDCA設計PDCA開発PDCAテストPDCA修正つまり、垂直に回っている。設計に対していくらPDCAをまわしてみても、せいぜい誤字脱字、書式が正しくない、更新日付が間違ってる、と言ったことしか見つからないし、こいつらは、プログラムに対してまったく関係がない。まったく関係がないミスをいっぱい見つけて、はい、これで完璧です。次のフェースに行きましょう。って言ってるのが現状。で、開発になってこの設計ではうまく行かない点が見つかって大騒ぎになっている。何でだ設計書は完璧なんだろう？はい完璧に誤字脱字はありません。ギャグですかと。テストになってバグがいっぱい見つかっ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
asahi.com：トヨタに残業代の重荷 カイゼン活動の社員「過労死」 - ビジネス