ソフトウェアエンジニアリングサバイバルガイド: 廃墟を直す、廃墟を出る、廃墟を壊す、あるいは廃墟に暮らす、廃墟に死す
ソフトウェアエンジニアリングサバイバルガイド: 廃墟を直す、廃墟を出る、廃墟を壊す、あるいは廃墟に暮らす、廃墟に死す
はじめに ソフトウェアプロジェクトには不思議な性質があります。現状のスケジュールに課題を感じて、短くするために人員を投下しても、なかなか思い通りに短くならない。それどころか悪化してしまうことがあります。場合によってはプロジェクト自体が破綻して失敗してしまうことすらあります。 今回は、このようなソフトウェアプロジェクトに潜む直感に反する性質を数理的なモデルを介して理解していく試みです。ある種の思考実験としてお楽しみください。 宣伝 Qiitaさんとコラボ企画でアドベントカレンダーをつくりました。 DXをめちゃくちゃ改善した話を募集しています。 https://qiita.com/advent-calendar/2021/dx-improvement 10人の妊婦がいても1ヶ月で一人の子供は生まれない これは誰かの技術力やプロジェクトマネジメント力に欠陥があるのではなく、「人月の神話」で有名な
システム開発の世界において「技術的負債(Technical Debt)」は繰り返し話題になり、しばしば炎上しています。 技術的負債という概念の生みの親は Ward Cunningham (ウォード・カニンガム)です。彼は 1992 年にオブジェクト指向プログラミングの国際カンファレンス OOPSLA '92 の Experience Report でコードの初回リリースを負債に例えました("Shipping first time code is like going into debt")。 Ward Cunningham はソフトウェアの世界に多くの貢献を果たしてきました。Wiki の発明者であり、XP と TDD の父 Kent Beck の師匠のような存在であり、建築の世界の「パタン・ランゲージ」を Kent Beck と共にソフトウェアに輸入した人であり、「アジャイルソフトウェア開
はじめに 現代では、ソフトウェアは一般にサービスとして提供され、Webアプリケーション や Software as a Service と呼ばれる。Twelve-Factor Appは、次のようなSoftware as a Serviceを作り上げるための方法論である。 セットアップ自動化のために 宣言的な フォーマットを使い、プロジェクトに新しく加わった開発者が要する時間とコストを最小化する。 下層のOSへの 依存関係を明確化 し、実行環境間での 移植性を最大化 する。 モダンな クラウドプラットフォーム 上への デプロイ に適しており、サーバー管理やシステム管理を不要なものにする。 開発環境と本番環境の 差異を最小限 にし、アジリティを最大化する 継続的デプロイ を可能にする。 ツール、アーキテクチャ、開発プラクティスを大幅に変更することなく スケールアップ できる。 Twelve-F
開発手法など、一通り学んだが実際に使っていないものは多少なりあると思う。それらについて掘り起こしてみたい。 スクラム開発認定スクラムマスター研修には研修会場ホストという立場で数回立ち会った。認定外の研修も幾つか受講した記憶がある。書籍もそれなりに読み、Scrum Gathering Tokyoなどのコミュニティにも顔を出し、まあそれなりに色々考えて捉えてきた。でも、自分のチームでは使っていない。スクラム開発というアイデアに矛盾があるからだ。 そもそもスクラム開発ではチームの自律的な行動を良しとしており、それに対する”フレームワーク”を提供しているということになっている。イテレーション、バックログ、ふりかえり、デイリーミーティング(いまだに「朝会」って言ってる人いないよね?)、そしてそれらのお作法。誰が言ったかわからないが、それぞれの作者の意図を察するためには「守」が大事らしい。守破離の「守
自分の会社ではパッケージ製品、つまりお客様の環境で動かして頂く製品を販売している。 そのため、カスタマイズを希望される事もある。今の機能では簡単に実現するのが難しいというのがほとんどの希望理由だ。 カスタマイズの定義は製品に対して+アルファの何らかの特別な対応を機能を追加することという事にしておく。 結論から言うと自分の会社では一切のカスタマイズを受けないというスタンスだ。カスタマイズはメリットよりデメリットの方が多いという考え方からだ。 カスタマイズのメリットまちがいなく売り上げを上げやすい事だろう。カスタマイズが必須な場合の顧客はカスタマイズを受け付けない製品を購入しない。 さらにカスタマイズ対応ということで、追加の開発費やサポート費を手にすることができる。これは前職で十分実感できた。 ただメリットはこれしか無い。 カスタマイズのデメリット一番大きいのはコードのフォークが発生してしまう
11/15に東京(青山一丁目)で開催された、サムライ・インターナショナルさん主催のセミナー「ランキングに上がらなくてもアプリ収益化する方法」のレポート記事です。 本記事では参考になったポイントをまとめていきたいと思います。 広告の売上はユーザー1人で月に数円くらい。アクティブユーザーが500万人いたら3か月で1億円の売上。これはものすごいヒットなので難しい。100万人が1年使っても1億円、30万人が3年使っても1億円。 リアルな話に落とし込むと、1万人が3年間使ってくれるアプリが30本でも1億円だし、5,000人が1年使ってくれるアプリが100本でも1億円。 ラッキーゲームスさんは1人で100本以上アプリをつくっているが、平均5,000ユーザーは超えているだろうし使い続けてもらえればいくと思う。 ただ普通にアプリを運営しているとユーザーは逃げてしまう、みんなが使い続けてくれるように工夫する
絶対パスの先頭に/が来る事を期待してはいけない しかしながら絶対パスの先頭にドライブレターが来る事を期待してはいけない UNCパスのホスト名やシェア名はディレクトリではないのでファイルシステムAPIは使えない事を意識しておく unixに比べパス内に空白文字が入る可能性が高い事を意識しておく ホームディレクトリを意味するパスの先頭チルダは自前で展開する必要があり、またパスの途中にチルダが混じる事は日常的にある ソケットディスクリプタに対してもread/writeで送受信できる事を期待してはいけない パイプでない標準入力のselectはやっても意味がない ディレクトリ内にあるファイルを開き、ハンドルを保持したままディレクトリを消せるのは当たり前だと思わない パスのセパレータが/¥である事を期待してANSI APIを使ってはいけない Cランタイム(POSIX互換API)とWindows APIを
どうすれば小規模なチームでも大きな成果を出せるのか。大きな組織で沢山の量をこなすのは当たり前のことで、あまりクールではありません。少ない人数でも大きな成果を出すには、スピードをあげることと、そのためにも無駄をなくすことがポイントになってきます。 ソフトウェアをつくるための3つの役割で書いた通り、ソフトウェア開発をクラウドのようなサービス提供で続けていくには、プロダクトオーナーとプログラマーがキャッチボールのような形で、仕様と実装をずっと繰り返しながら作っていくのが自然です。 SonicGardenで使っているツールと開発の流れの全体は以下のようになります。大事なことは「動くソフトウェア」の状態を保ったまま、どれだけ回転数をあげていけるか、ということです。そのために、プロダクトオーナーとプログラマの間で待ち時間を減らすために並行して進めるようにするなど工夫しています。 ホワイトボードとMVP
Googleで実施されているというバグ予測の方法がブログで公開され(こちら)、ツールも利用できるようです(こちら)。Publickeyの記事での紹介で端的に紹介されていますので、時間がない方にお勧めします。ソースコードの変更(コミット)履歴から高い頻度でバグ修正されているコードは今後もバグが出る可能性が高いというものです。 類似の研究結果がたくさん報告されているので、この分野の研究者の1人として紹介したいと思いエントリを書きました。興味のある方には本エントリ末尾に示すこの分野の論文も読んでいただきたいです。 一例として2000年にICSMで発表された以下の論文を紹介します。 Mockus A, Votta LG. Identifying reasons for software changes using historic databases. International Conferen
記者という職業柄、これまで非常に多くのプレゼンテーションを見てきたが、プレゼンテーションの1枚目が半裸の女性モデルの写真だったのは初めてだった。 2月13日、14日の予定で東京・目黒で開催中の「デベロッパーズ・サミット2008」で講演したFog Creek Softwareの創業者でCEOのジョエル・スポルスキー(Joel Spolsky)氏のプレゼンテーション「Joel on Developers Summit――素晴らしいソフトウェアを作るということ」は、型破りに楽しく、なおかつソフトウェア開発者にとって示唆に富む内容だった。 スポルスキー氏は米マイクロソフトのExcelチームで、Excel用マクロ言語を、後にVBAと呼ばれることになるモダンなオブジェクト指向言語に置き換える仕事でプログラムマネージャを務めたことがあるなどソフトウェア開発のベテランだが、エッセイの書き手としても名を馳せ
[ Topページへ戻る ] Mercurialでバージョン管理 概要 「分散リポジトリ方式」なる言葉によって興味をひかれたバージョン管理ツールがこのMercurialです。 今までのバージョン管理ツールへの不満 オフラインでもバージョン管理したい いままで、職場や自宅において、CVSやSubversionを使うときは、1台のマシン上にリポジトリを置き、そのリポジトリに対してチェックアウトやコミットといった変更の払い出し・登録を行っています。 したがって、リポジトリのあるマシンと作業マシンがネットワークで接続できないときは、チェックアウトした作業ディレクトリの変更をコミットできませんし、過去の変更履歴も調べられません。ネットワークに接続できない期間が短時間ならいいのですが、長期間になるとこれはバージョン管理ができないに等しい状態です。 気軽なリポジトリ作成ができたらいい ちょっと作ったプログ
1 半纏(大阪府) 2010/12/12(日) 22:06:02.87 ID:cpwv5OplP ?PLT(18000) ポイント特典 ゲームを裏から支える「ゲーム開発」の特集番組です。 今週末、NHKで世界と日本のゲーム開発に関する特集番組「世界ゲーム革命」が放送されます。 12月12日(日)の午後9時15分から総合テレビで放送予定です。 番組の概要は、まず圧倒的な技術力とプロモーション力で世界中でシェアを拡大しつつある米国産ゲームの秘密に迫ります。 それに対し日本の逆転の切り札として期待される「ゲーム」と「アニメ」技術の融合、 そして「クールジャパン」を輸出の中心にする変わりゆく政府の姿をフューチャーします。 最後に『ムーブ』や『キネクト』に代表される様な新技術に伴う、進化し続けるゲーム開発の現場紹介となります。 また番組の前に、『スペースチャンネル5』や『Rez』のク
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く