2013年3月12日のブックマーク (5件)

  • 自分が職を失った経緯 - id:anatooのブログ

    この記事は、How I Fired Myself.という記事の試訳です。 2010年の7月、私は22歳で、カリフォルニアのあるソーシャルゲームのスタートアップで働いていた。卒業したてで、私にとって初めての物の職だった。給料をもらってアパートに住んだ。そのころ私は初めて大人になったような気分でいた。 その会社の主力製品であるRPGのコードを書く二人のエンジニアのうちの一人が私だった。大学では哲学を専攻していた。これはどういうことかと言えば、問題に対してどうやって考えればいいかを知っていた一方で、ベストプラクティスや実用的なデザインパターンに関する知識は最低限しか持っていなかった。私は信じられないほどの熱意でもって自分が持っているごく普通のLAMPの知識を駆使した。 私の悩みの種であるゲームデザイナーはしばしばWorld of Warcraftからインスピレーションを得ていた。WoWは、Bl

    自分が職を失った経緯 - id:anatooのブログ
  • 国立国会図書館デジタルコレクション

    KeithYokoma
    KeithYokoma 2013/03/12
    国会図書館www
  • スクラムはアジャイルなのか? - 水まんじゅう2

    ここ半年ぐらいの疑問です。 以前、スクラム開発をしていますという会社におじゃまさせていただきました。 そこのプロダクトオーナー役をやっている人はそれなりに有名な人らしく、たまに講演活動もやっているとのこと。 アジャイルプラクティスの詰まった開発手法をとっているとのことで、ウォーターフォール*1でやっている身としてはすごい憧れの世界でした。 色々見てきた コードを見せてもらった まず、コードを見せてもらったのですが、酷い状態でした。いわゆるレガシーコード。 テストがない。テストがない。テストがない。 何かと理由をつけてテストを書かない。書こうとしない。 それなりに開発スケジュールとしては余裕があるように見えたのですが、リファクタリングもしない。 なんだこれ・・・・・それ以上の感想はない。 積み上がるタスクをみちゃった タスクボードでタスクを見える化していたのですが、山のようにタスクを抱えてい

    スクラムはアジャイルなのか? - 水まんじゅう2
  • 続・技術的負債の把握と改善を促すために - mixi engineer blog

    こんにちは, 先日Kansai.pmで発表させて頂いたgoccyこと五嶋@たんぽぽグループです. 今回は, 前回紹介した技術的負債の把握と改善を促すためにの続編として, 僕が作ったPerl5コードのコピペ検出器について紹介させて頂きます. はじめに 今やPerl, Ruby等さまざまな言語で, 便利なライブラリ群やフレームワークを利用できる時代になりました. これらを使うことでソフトウェアの開発コストは格段に下がり, より素早く開発することができるようになっています. しかし, 当初予定されていた機能を実装して, 「よしできたから終わり!」というわけにもいきません. 何か物を生み出せば, 必ずそれを保守・運用するコストが発生します. 開発することが便利になった今, 開発物を保守・運用することを支援するツールも求められています. ですが, 保守や運用, とりわけ保守に関して支援するツールはそ

    続・技術的負債の把握と改善を促すために - mixi engineer blog
  • A/Bテストとユーザビリティテストの使い分け

    A/Bテストは、用意した複数のデザインのどちらの成果指標がよりよいか、という結果を定量的に比較検討するための手法です。いくつかのデザインの選択肢があった場合に実際にユーザーに利用してもらうことで、どのデザインが最も数値目標達成率が高いかを把握するのには有効ですが、なぜその結果になったのか、という理由を把握することはできません。デザイナーの発想の域を越えることはできず、変更すべきデザイン要素が別のものだったとしても気づくことができません(例:真の問題は、色ではなく配置だった)。 一方、ユーザビリティテストは、ユーザーの利用状況を観察することで、目的達成を妨げる問題など、定性的な洞察を得るための定性的な手法です。まだ開発途中である場合や、リリースしたあとに、ターゲットとしたユーザーがどのように思考し行動するかを把握するのに有効ですが、定量的な指標による評価にはあまり向きません(それをしようとす

    A/Bテストとユーザビリティテストの使い分け