コードは綺麗だけど儲からないプロジェクトと、 コードは糞汚いけど儲かるプロジェクトのどっちがいいですか？ もちろん、コードは綺麗で儲かるプロジェクトがいいのは理想ですが、今回は、この2つです。 コードは糞汚いけど儲かるプロジェクトの場合、次期バージョンとかの予算を確保することができます。 そこで、汚い部分を捨てて書きなおすことだって出来ます。 コードは綺麗だけど儲からないプロジェクトは、次のバージョンの改修費用もでずにゴミ箱に送られる運命です。 プロジェクト解散、メンバーは散り散りです。 フリーソフトの場合は、儲かるをユーザに使ってもらえるソフトとか支持されるソフト、 ゲームの場合は、儲かるを面白いゲーム、支持されるゲームとかと適当に読み替えてください。 コードは綺麗に越したことはないです。 だけど、プロジェクトとして成立しないことには意味がありません。 コードは綺麗だけど、誰も遊んでくれ
コードクローンと品質について話題になっている。元ネタはこちら。 ソースコードの品質についても、みずほ証券は問題を指摘している。今回のバグがあったプログラム全体について、「ソースコードの著しい重複が見られるなど、エラーの潜在する率が極めて高い作り方をされており、品質が極めて低い」と主張。これに対して東証は「コードクローン（記述の重複）を含むプログラムは、含まないプログラムと比較して信頼性が高いことが定量的な研究で裏付けられている」と反論した。 ［論点3］どんな開発手法を適用すべきか | 日経 xTECH（クロステック） この「コードクローンを含むプログラムのほうが信頼性が高い」というのはどこからきた話題なのかという話。 僕が昔読んだ論文で似たような話があったなと思って探してみた。 コードクローンに基づくレガシーソフトウェアの品質の分析(PDF) 本論文では，20年以上前に開発され，拡張COB
概要 1ヶ月くらい一緒にお仕事している外国人プログラマさんを観察した記録です。 スペック 性別: 男性 仕事内容: うちの会社のプログラマは、ざっくり JS 等のフロントエンドと、 Java 等のバックエンドエンジニアにわかれているのですが、彼はどちらもやっているようです。 好きな食べ物: はちみつ たまに、くまさんのようにはちみつを舐めていました。 性格 彼はめんどくさがり屋です。 同僚の Windows ユーザの手伝いをしている時、 "C:¥Program Files¥..." みたいなパスを打ちながら、「めんどくさい。 ああ めんどくさい」 と 100回くらいつぶやいていました。 (普段の彼の環境は mac なので /usr/local/bin) パスワードを覚えるのもめんどくさいので 1Password で管理しているようです。 PC スペック マシン: Macbook Pro メ
こんにちは、20時から予定がありました。遅刻しそうです。 さて、ということでさっくり話をすると、「ペアプロってやったことないな」ってところからスタートです。 ペアプロするのって難しい 難しいんです。何が難しいって、相手が居ない。居ないんですよ相手が。家庭内ペアプロとかやってる夫婦を1組知ってますが、そんなん普通ねーよ。アホか。 そして会社でペアプロするのは違うんです。違う、そうじゃない。会社でペアプロするのはいい。いいんだ。でも俺は趣味のコードとかを友達ときゃっきゃうふふしながら書きたい。 だからペアプロするのは難しい。勉強会にいって「どうもーはじめましてロージーですー」と自己紹介してその直後に「ということでペアプロしませんか？」とでも聞いたらその場で Twitter に勉強会にホモがいるとか言われて ID 晒されて大炎上ですよ。リスキーすぎる。 ということで簡単に、とりあえず俺は友達とペ
昨日は年始の挨拶ついでに ELPA について脈絡もなく突然書きましたが、引き続き近頃の開発環境についてもだらだらと書いてみよう。 Mosh mosh というと一部の人間はひげなんとかさんが開発しているモナー的なあれを思い浮かべるかもしれないがそうではなく、mobile shell のことである。 思い切り簡略化して言うと「快適なssh」。回線が不安定な所でもエコー遅延など全く気にせず使えるし、Mac をスリープさせて復帰させたときもリモートホストにそのまま繋がりっぱなしのように見せかけてくれたりする。 詳しくはこの辺を。 mosh: MITからモバイル時代のSSH代替品 - karasuyamatenguの日記 インストールはリモートとローカル両方に必要ですが、まあ大概パッケージがあると思います。EC2 の Amazon Linux でも yum レポジトリの EPEL を有効にすれば y
3. ソフトウェア工学とは • ソフトウェアの開発・運用・保守に ついて体系化、分析、研究する分野 • 高度で安全なソフトウェアを短期間 で設計するための研究を行う
昔々、あるところにジェイソンという、大変真面目な開発者がおりました。 彼がとある会社の情報システム部にやってきたとき、彼は社内システムのクオリティのひどさに衝撃を受けました。 情報システム部といっても、その会社では外注はせず、社内の開発メンバーがシステムを作っていました。 ジェイソンがそこで最初に担当したシステムは、見事なまでのスパゲッティコードでバグだらけ、データ設計も素人レベルでパフォーマンスも最悪、エラー処理もずさん、おまけにまともなドキュメントもなく、ちょっとした障害を調査したり、小さな改造を実施したりするのにも、大変な苦痛を伴うという、それはそれは大変なシロモノでした。 このシステムは元々エセーグルという、ちょっと変わった名前の開発者によって作られていました。 しかし彼はすでに別の開発チームに異動していて、こちらの質問には答えてくれますが、もはや本人が直接手を動かすことはありませ
スクウェア・エニックスの人気RPG「ドラゴンクエスト」シリーズの最新作「ドラゴンクエストX（ドラクエ10）」はシリーズ初のオンライン作品となりましたが、その舞台裏は一体どうなっていたのか。ゲームの世界観を支えるサーバシステムがどのように構成されているのかということや、ドラゴンクエストⅩならではの仕組みや機能から開発の苦労話まで、株式会社スクウェア・エニックス開発部プログラマ森山朋輝さんが語っています。 タイトル | CEDEC 2012 | Computer Entertaintment Developers Conference http://cedec.cesa.or.jp/2012/program/NW/C12_P0040.html 森山朋輝： 皆様、本日はお集まり頂きどうもありがとうございます。このセッションを担当させて頂きます、株式会社スクウェア・エニックス開発部所属の森山朋輝と
PofEAAのWikiです。Martin Fowler氏とAddison-Wesley Pub Coの許可を得て、 パターンカタログの翻訳を行っています。bliki_jaと同じくどなたでも参加可能ですので、是非参加してみてください ;-) ※このサイトは書籍の邦訳とは一切関係ありません。 ■ PofEAAのパターンカタログ and PofEAAのパターンカタログ(邦訳版)ここから読み始めるとよいでしょう。対応表もあります。 ■ 読書会 第12回の開催予定は未定です。 ■ PofEAA読書会メーリングリスト読書会に関する話題を扱っていますが、読者会への参加を強制するものではありません。興味のある方の参加は随時受け付けています。
This document introduces Aiming, a startup founded in 2011 by Toshiaki Katayama. It previously worked on Community Engine from 2001-2003 and Play Online China from 2003-2007. Aiming focuses on building online and mobile games using technologies like HTML5, Unity, Ruby on Rails and Flash. It aims to create fun and social games and uses agile practices like Git and continuous integration. The compan
このエントリーは「Software Test ＆ Quality Advent Calendar 2011」における12/18分として書いています。 12/17は @NoriyukiMizuno さんによる 「ソフトウェアテストの勉強会。1年目。」 というエントリでした。 今回は、以前から感じている矛盾について、私なりの考えをまとめたものです。 特に、マネージャーや経営層と呼ばれる人に読んでもらいたいと思っているのですが、このブログの読者層を、考えると、あまり多くはなさそうなので、以下に示す問題について、悩んでいる／苦しんでいるような人から、うまく伝われば良いと思っています。 矛盾する問題 私は、SEPG（Software Engineering Process Group）という役割上、いろいろなソフトウェア開発のプロジェクトや組織に関わってきました。 絶対数で言えば、そんなに多くはない
みなさんは罪悪感駆動開発(zaiakukan-driven development; ZDD)という言葉をご存知だろうか。私はつい先ほどまでこの概念を知らなかった。なぜなら先ほど自分で思いついたばかりだからだ。 仕事をしていく中で、やるべきことが山積みなのについネットサーフィンをしてしまい、「うわ、今日仕事全然進んでない、やばい」という罪悪感から、その後の仕事が妙に捗る、という経験をしたことがある人は少なくないだろう。 罪悪感駆動開発は、こうした危機感や罪悪感といった人間が本来持っている感情を引き出すことで、より高い仕事の成果を上げていくことを志向する。 罪悪感を感じるポイントは人によって個人差があるが、一般に仕事中に罪悪感が高まりやすい充填行為として、次のようなプラクティスが広く認知されている。 (a) 昼寝 (b) ネットサーフィン (c) ゲーム (d) タイピングソフトでランキング
The document discusses the traditional "iron triangle" of project management consisting of scope, cost, and schedule. It then introduces the "agile iron triangle" which prioritizes value and adds quality and constraints. The agile approach recognizes that scope, cost, and schedule are constraints, not priorities. It emphasizes that XP (eXtreme Programming) is about enabling social change through t
［技術講座］ レガシーシステムの設計手法 レガシーマイグレーションで、オブジェクト指向アプローチを採用するために 1. はじめに COBOL 技術者の引退や、ハードウェアのダウンサイジングに伴い、Java 技術者には、レガシーマイグレーション（注1）の業務が増える可能性がある。ところが、Java 技術者の育った文化と、レガシーシステム（注2）の文化は異なる。具体的には、それぞれの文化で使う専門用語は異なっている。さらに、専門用語よりも重要な相違として、専門用語の土台となる開発手法が挙げられる。 開発手法に焦点を当てると、多くのレガシーシステムは、データ中心アプローチやプロセス中心アプローチといった従来的な開発手法に基づいて開発されてきたといえる。したがって、レガシーシステムの仕様を理解するためには、こうした手法の特徴を知っておく必要がある。そこで本稿では、現在のシステム開発で主流を成すオブ
outputz でいまだに1位になれたことがない村瀬です。 社内で開発をスムーズにするための tips 集を紹介したので、まとめておきます。 記事ではデモができないので便利さが伝わらない物も多いですが参考になれば幸いです。 screenとかzshとか便利だよ！と言う話は社内ではさんざんしているのでありません。 また、OSX 限定の内容もあります。 でははじめましょう。 keychain keychain と言っても OSX の KeyChain ではなく、コマンドラインのツールです。 これは ssh-agent をより便利にするためのラッパーです。これを使用すると ssh の秘密鍵のパスワードを一度入力するとあとはパスワードなしで ssh 接続できるようになります。 「同じこと二回も言わせんな！」といつも切れているような人は導入すると良いでしょう。 使い方は $ keychain ~/.s
「An Open Letter to the Software Managers of the World」という記事がありました。 世界のソフトウェア開発者から、世界のソフトウェアマネージャへの公開書簡らしいです。 原文は、マネージャへの要求と、要求を約束するのであればソフトウェア開発者が果たす義務の2部構成になっています。 最初に義務の部分が書いてあります。 ほどほどに面白い内容でした。 以下、要約です。 かなり省略/意訳しているので、詳細は原文をご覧下さい。 我々ソフトウェア開発者は、以下の事項を約束する。 我々は、要求されなくても任務遂行に必要な行動を自主的に起こす。 残業もこれに含まれる。 (ただし、次章の項目1を満たす限り) 我々は、つまらない仕事を任されても文句は言わない。 他人のコードの管理も行う。 (ただし、次章の項目4と5を満たす限り) 我々は、可能な解決法の提示するな
なお、システム開発の工程の分類の仕方や名前は、現実には、上記のものと違うことが多い。 図４－１の分類の仕方や名前は、「高度情報化人材育成標準カリキュラム」に沿っている。 基本計画：ユーザの要求（システムに求めること、システムに備えておくべき機能、満たすべき条件など）を明確に定義する段階である。 外部設計：コンピュータから見て、外側部分（ユーザとのインタフェースをとる部分）の設計をする段階である。 基本計画の段階で作成された要求仕様書をもとに、 ・システムのもつべき機能を確定し ・どのようなシステムにするかの概要を設計する ため、概要設計とよばれることもある。 なお、外部設計の目的はユーザからの了承を得ることなので、コンピュータ内部の技術的部分は、基本的に考えなくてよい。 内部設計：情報システムの内部（ハードウェアや基本ソフトウェアに依存する部分）の設計をする段階である。 外部設計の段階で作
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
