[#xpfes12] 先駆者の集まりから、プロセス・チャンピオンの集まりに - XP祭り関西2012 - - ソフトウェアさかば
[#xpfes12] 先駆者の集まりから、プロセス・チャンピオンの集まりに - XP祭り関西2012 - ついにアジャイル開発は普及期に入りました。そんなことを、今年のXP祭り関西(リンク先はtogetter)で実感しました。 たぶん最初のXP祭り関西は、ワッハ髪型で行われたXP祭り2006です。私も赤いハッピを着て、スタッフをさせていただきました。リンク先を見ていただいても分かると思いますが、XPのプラクティスを試してみた人やXPを実践中の先駆者が、興味のある人やこれから始めようとする人に体験を踏まえて説明する集まりでした。 今回のXP祭り関西は、その内容も参加者もより実践的に感じました。私のつぶやきは上のリンクで見ていただくとして、変化を感じた3つの発表の感想を書きます。 【基調講演】「アジャイル開発の計画と管理」～アジャイルのプロジェクトマネジメント～ 梅田 弘之氏 /株式会社システ
![[#xpfes12] 先駆者の集まりから、プロセス・チャンピオンの集まりに - XP祭り関西2012 - - ソフトウェアさかば](https://cdn-ak-scissors.b.st-hatena.com/image/square/cb3189f8cb55f68fc5c2b0270b2e8657e0d2eb43/height=288;version=1;width=512/http%3A%2F%2Fsakaba.cocolog-nifty.com%2F.shared-cocolog%2Fnifty_managed%2Fimages%2Fweb%2Fogp%2Fdefault.png)
マネージャになりたくないプログラマのキャリアパス
金曜日、KLab元CTOの仙石さんからありがたい話をいただきました。 話は、開発者の採用、教育、評価あるいは開発者の心構えなど多岐に渡りました。いくつも興味深い話がありましたが、個人的に一番聞いて良かったと思える話を紹介します。表題の件です。 若いプログラマの中には年をとってもマネージャになりたくないと言う人がいます。他人事ではなく自分もそのひとりでした。若い時にマネージャ志望のキャリアパスに語ることは、プログラマとしての自分の誇りを傷つける気がしていました。マネージャを偉いと見なす風潮が、技術に対する裏切りのような気分がしていました。技術者をマネージャより低いと位置づけるのが許せませんでした。 たぶんピュアだったのでしょう。そんな経験があるので、今でもピュアな若者は好きです。本物のプログラマになるには、技術だけに一心に向き合うピュアな期間が必要だと信じています。そして、技術に真摯に向き合
はじめてのgithub
世界一簡単なGithub入門（githubは無料で使用する場合、全てのファイルが公開されていることにご注意ください） ややこしいコマンドを全スルーして個人用バックアップとして使ってみる 2013.01.26 LDD13 LT 【概要】 次々と新しい技術やサービスが公開され、いろいろ挑戦してみたい・・・とは思うのですが、それが複雑なものだったり高機能であったりすると、どうしても最初のハードルが高く、なかなか踏み出せないと感じます。 そんな時、私の場合は、とりあえず、できるだけ簡単なマニュアルを探してきて、良く分からないところは全部無視して無理やり使ってみることにしています。訳が分からないままでも、使っていることで、ちょっとずつイメージが湧いてきて、画面が見慣れたものになってきます。そして、それから改めて入門書を読み始めます。そうすることで、最初のハードルが、少しは下がるのではと考えています。
subversionリポジトリからの変換 - Sukalog
Twitterでこんなことをつぶやいたら入門Mercurialの著者の方にいろいろ教えてもらいました。Twitterスゴイネ！ Twitterでのやりとり :left REVMAPとは http://mercurial.selenic.com/wiki/ConvertExtension REVMAP is a a simple text file that maps each source commit ID to the destination ID for each revision. Unless specified, it defaults to the .hg/shamap in the destination directory. This file is automatically created and updated on each commit copied, its
状態遷移表設計手法の概要
組み込みソフトウェアには、さまざまなイベントに対し、その時の状態に応じた処理を行わせる必要がある。そのため「状態遷移表」を用いた設計が適している。本連載では、状態遷移表による設計手法について解説していく。 はじめに 組み込みソフトウェアには、さまざまなイベントに対し、その時の状態に応じた動作・処理をさせる必要があります。そのため、開発現場では「状態遷移表」を使った設計が行われてきました。 状態遷移表を用いた設計手法の歴史は長く、古くから“設計品質を向上させるための手法”として使用されてきました。そして、最近では検証系であるテスト手法、さらにはプロダクトライン設計手法、マルチコア環境における並列処理設計手法に対応するなど、その進化を続けています。 本連載では、この“状態遷移表による設計手法”について、以下全6回のテーマに分けてお届していきます。 状態遷移表設計手法の概要 なぜ状態遷移表を使う
何故バグ報告の99%が役に立たないのかもしくは何故プロのテスターが存在するのか - oops
テストにはプロがいます。「お仕事」で開発する場合はQA(Quality Assurance/品質保証)部門という「テストのプロ」がテストします。 バグ修正におけるテスターの役割は極めて重要で、「プログラマの手元で任意に再現可能な状態に持ち込めれば、バグ修正は8割終わっている」と言っても本当に過言ではありません。詳細聞き出しに10時間、修正30分、修正確認テスト30分、なんてのも実務ではザラです。この場合、プログラマも11時間拘束される(=時給x11時間分のコストが掛かる)わけですから、バグ修正のコストは聞き出しに掛かるコストがほとんどを占めることになります。 (誤報告一発で万単位の金が簡単に吹っ飛ぶとも言える) まずそもそもの問題として「素人」がテストを行うと以下のような論外ケースが頻繁に起こります。上に行くほどクソです。 誤報告 実際に起こったことと、現象が違う、手順が違う、設定
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
お金をかけずに簡単ういろう！ by なんちょ [クックパッド] 簡単おいしいみんなのレシピが40万品![お金をかけずに簡単ういろう！ by なんちょ [クックパッド] 簡単おいしいみんなのレシピが40万品](https://cdn-ak-scissors.b.st-hatena.com/image/square/531bb11d3751d1361eaea81e8eb4fcd2f61914f4/height=288;version=1;width=512/https%3A%2F%2Fog-image.cookpad.com%2Frecipe%2F189420%3Ft%3D1506329549)
