チケット駆動開発で作業管理はしないほうがいい - arclamp
先日、2013/3/23（土）に弊社でチケット駆動と開発環境に関するイベントを開催しました。リンク先には資料も上がっていますので参照ください（※アトラシアン製品関連のイベントです）。 基調講演にはチケット駆動開発を推進されている関西XPUGのあきぴーさんをお招きして「チケット駆動開発をパターン言語で読み解く」という話をしていただき、最終枠ではパネルディスカッションをしました。 チケット駆動開発とウォーターフォール パネルディスカッションでは、僕が「チケット駆動開発を作業計画に使うのは難しく、WBSとの併用が現実的」と話し、あきぴーさんが「作業計画をチケット駆動開発で回していくには」というノウハウを紹介されていました。 この違いは僕がウォーターフォール的な新規案件を、あきぴーさんがアジャイル的な開発/保守運用案件を前提にしているためです。 僕自身はBTS（Bug Tracking Syste
「TAKERU」と「通信カラオケ」の関係 - reponの忘備録
「カラオケ秘史」 カラオケ秘史―創意工夫の世界革命 (新潮新書) 作者:烏賀陽 弘道新潮社Amazonを読んだ。 非常に面白かった。 初めて読むことばかりだが、カラオケが広がった時代を生きていたこともあり、自分の記憶が上書きされた。 カラオケは、１）カラオケ装置 ２）カラオケボックス ３）通信カラオケという三段階の発明を経て一般に定着したのだが、そのことはあまり知られていない。 特に通信カラオケが、ブラザーのソフトウェア自販機「TAKERU」を「インフラ」として活用し作られた秘史が凄まじい。 「TAKERU」自体は商業的にはほぼ失敗で、撤退を余儀なくされていたのに、その技術者の先見により「カラオケの音楽情報（MIDIデータ）の中継サーバ」として変更され、会社の幹部も知らない内に力を発揮していた、という。 その「TAKERU」を中継サーバにして作られたカラオケ装置が「JOYSOUND」だった
はてなブログ | 無料ブログを作成しよう
織田信長 ぼちぼち、元気にやっています。少し薬にも慣れた...んかなぁ。相変わらず食べられないけど。朝、指がこわばって文字なんて入力できなかったけど、それはほぼなくなった。関節もどこも痛くない。薬効いてきたんやろな。 で、ブログを書こうと言う気がまた起きてきた。 …
PayPalがVMwareからOpenStackに移行する理由は「可用性を犠牲にすることなくスケーラブル」だから
8万台ものサーバを、VMwareの製品で構築されたシステムから、オープンソースのOpenStackベースのプライベートクラウドへ移行すると発表されたPayPalの事例は、OpenStackの勢いとオープンソースのクラウド基盤ソフトウェアの成熟を示すものとして注目されています。 OpenStackのWebサイトで公開された事例では、OpenStackへ移行する理由が次のように説明されています。 A key component of the selection criteria for PayPal’s cloud infrastructure was the ability to scale quickly without compromising availability. For its engineers and developers to be successful, the pla
武内絵美「現場リポート」 | 出産の適齢期 | 2016年01月11日
指定されたページは存在しません。 アドレスをご確認ください。
育児を開始する人のための心得・テクニックの私的覚え書き - FutureInsight.info
僕の周りでも育児を開始する人が増えてきました。これまでの経験で実用的と感じる心得・テクニックをエンジニア的視点から主に両親と同居しない共働きの家庭を前提にまとめてみます。 保活が始まる前に育児を行いやすい場所に引っ越す 奥様の妊娠が発覚したら自分の今住んでいる場所が本当に育児に適切な場所か調べましょう。重要な点は、 保育園に入園することがそこまで無理ゲーではない・保育園の代金が安い・無認可保育園でも自治体の補助がある。 近くに子どもと楽しく遊べる公園や施設がある。 子どもが車道に簡単にはでないように、歩道がある程度整備されている。 などなど、まぁ、結構オーソドックスな内容ですが、要は育児を行いやすい場所と行いにくい場所があるので、それをしっかり把握して、もし育児を行いにくい場所なら保活が始まる前に引越しましょうということです。夜も楽しい・遊ぶところがいっぱいある地域が育児に向いているかとい
文系学部生がSIerに入社してから読んだ本メモ - ギークに憧れて
2013-04-01 文系学部生がSIerに入社してから読んだ本メモ 基本情報技術者連続不合格から一人前のエンジニアを目指す: 文系学部生がSIerからの内定までに心掛けたこと ちょっと前にこんなコラムが話題になって､心の中で｢燃えろ〜よ燃えろよ〜｣とか言いながら読んでたけど､よく考えたら自分も就活してた時は全然コード書いた事無かった｡この人は何か思う所があって記事を書いたのだと思うし､少なくとも炎上狙いでは無い気がする｡ 4月から自分みたいに未経験だけどエンジニア目指したいって人もいると思う｡そういう人はとりあえずTwitterとかGitHubで凄いエンジニアを追っかければいいと思うけど､最低限の教養として本読まなきゃダメっていうのはある気がする｡とりあえず自分が読んでみて良かった本をメモ｡ でも本読むのは最低ラインでその倍くらいコード書いてコード読まないと成長ないと思う｡ 心構え
PressmanのSoftware Engineeringを超訳ななめ読み その３－各種アジャイル - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） みんなから、無慈悲な稲妻を受けないために、 大事そうなところを、超訳＆ななめ読みしている PressmanのSoftware Engineeringを超訳ななめ読みする 前回で、第一章が終わったので 今回から、本格的に超訳＆ななめ読みです。 まずは、アジャイル関連の３章 ■アジャイル概論 ３章 アジャイル開発 ２００１年、ケント・ベック他１６人の著名なソフト開発者、ライター、コンサルタント（アジャイル アライアンスと言われる）は、アジャイルマニュフェストに署名した。それは、以下のように始まる で、はじまる第三章はまず、 ３．１ アジャイルとは何か ではじまります。ここではヤコブソンの「アジリティ」の説明が載っています。 ３．２ アジリティと変化のコスト に関しては、アジャイルとア
アジャイルをやりたいなら、世界を相手にすべき！ - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） いくらなんでも、ソフトウェア工学話で引っ張るのは、無理が出てきたし、 アジャイルをダメにしないためにすべきこと http://arclamp.hatenablog.com/entry/2013/03/28/000000 で、大体話がまとまってきたので、もうそろそろ、ソフトウェア工学ネタ はうちも、終わりにしていいかな・・・ と思って、話をまとめる方向に行ってみたいと思う。 上記の「アジャイルをダメにしないためにすべきこと」は 結局、「アジャイルだけではない」という話だと思います。 現実は、その通りだと思います。 アジャイルで向いているプロジェクトもあるし、 アジャイルに向いていないプロジェクトもある。 だから、アジャイルで有名な永和システムさんも、 １００％アジャイル案件なわけで
アジャイルを終了させ、日本を中国化するかも？－裁判所と日経コンピューターが・・ - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） う～ん、ソフトウェア工学話を終わらそうとしたら、 日経コンピューター 2013年４月４日号 にこんな記事が 誤発注裁判が改めて問う 「バグは重過失か」 日経コンピューター 2013年４月４日号 ６８ページ～ これ、ツッコミどころ満載なんで、その中のいくつか ■この裁判を整理してみる この裁判は、 ・みずほ証券が誤発注をした。 ・誤発注したときに、取り消しをしたが、取り消せなかった →もし取り消せなかったら、 ふつうは、買いで失敗したら売り、売りで失敗したら買いと 反対取引を自らして、相殺すると思うけどが、反対取引は、 たしかかなり遅れてしたはず。 ・取り消せないのは、富士通がばぐったから ・だから、「東証に責任がある」？ →謝罪と賠償をせよ つまり、まとめると みずほ証券←裁判→
サービス終了のお知らせ - NAVER まとめ
サービス終了のお知らせ NAVERまとめは2020年9月30日をもちましてサービス終了いたしました。 約11年間、NAVERまとめをご利用・ご愛顧いただき誠にありがとうございました。
【JaSST13Tokyoメモ】 「過失に着目した欠陥のモデリング～バグ分析はなぜうまく行かないのか？～」
ホーム » ソフトウェア品質 » イベント » 【JaSST13Tokyoメモ】 「過失に着目した欠陥のモデリング～バグ分析はなぜうまく行かないのか？～」 不具合分析 不具合分析は多くの組織で行なわれているが、効果が出ていないのではないか。 近年、ソフトウェア開発は大規模化、複雑化している。 一人ですべてを把握できない 全て範囲をテストできない 複雑度の増加 組み合わせ数の爆発 そういった中で、バグとどのように立ち向かう、または扱っていく必要があるか。 「ワナ」 「ワナ」にはまることを繰り返さないようにするために、モデル化が必要 「開発者が埋め込んでしまう「ワナ」→開発プロセスで何があったのか？ 品質担当者が見逃してしまう「ワナ」→テスト工程で何があったのか？ なぜ不具合分析がうまくいかない理由 バグ分析の失敗要因 バグ分析の目的が明確でない バグ票に必要な情報がない 事実認識が甘すぎる
DNSの偉大さ - モジログ
ネットはたくさんの技術によって成り立っているが、私が特に偉大だと思う技術は、DNSである。 Domain Name System http://ja.wikipedia.org/wiki/Domain_Name_System ＜Domain Name System（ドメイン ネーム システム、DNS）はインターネットを使った階層的な分散型データベースシステムである。1983年に情報科学研究所 (ISI) のポール・モカペトリスとジョン・ポステルにより開発された＞。 ＜現在では主にインターネット上のホスト名や電子メールに使われるドメイン名と、IPアドレスとの対応づけを管理するために使用されている＞。 DNSとは、大ざっぱに言うと「ドメイン名をIPアドレスに直すもの」だ。 例えば、当サイトのドメインは「mojix.org」で、現在のIPアドレスは「133.242.174.18」である。「moj
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
JaSSTソフトウェアテストシンポジウム-JaSST'13 Tokyo レポート