世界で人気の開発ツール、作った動機は“怒り”
ソフト開発のコンパイルからテストまでを自動化し、1日に複数回実施することで品質改善や納期短縮を目指す「継続的インテグレーション（CI）」が注目を集めている。米国を拠点に活動し、世界的に最も人気が高いCIツール「Jenkins」を開発した川口耕介氏は、開発の動機は“怒り”だったと明かす。 Jenkinsが実現するCIとはどのようなものですか。 ソフトウエア開発プロセスを改善するための取り組みです。プロセスのなかには、単なる反復作業がたくさん存在します。ソースコードのコンパイルなどによって実行可能なファイルを作成するビルドやテスト、品質検査などです。 人間はそもそも反復作業が得意ではありません。人間が不得意な作業は極力ツールに代行させて、開発者が設計やプログラミングに集中するのが望ましい姿でしょう。これがCIの狙いです。 ビルドツールを補完 CIという概念自体は1990年代末に、アジャイル開発
ラピュタには何故自爆コマンドが用意されているのか: 不倒城
バルスのことなんですけど。 大多数のネットユーザー諸兄はご存知かと思うが、バルスは天空の城ラピュタにおける「滅びの言葉」である。劇中ラストシーンにおいて、家伝の飛行石を手にしたシータとパズーが「バルス！」と叫ぶと、なんか飛行石がやたら光ってムスカさんが目が目が星人になったりラピュタがぶっ壊れたり、色々とエラいことになる。 「バルス=滅びの言葉」という図式の定着度・認知度はWeb上では恐ろしい程であり、ラピュタ放映時には実況板が「バルス！」の書き込みとAAで埋め尽くされるという。 まず考えなくてはいけないのは、このバルスという命令は一体何の為に用意されたAPIなのかということである。 ラピュタは人工物なので、当然設計者や開発者がいた筈である。そして彼らは、管理権限キーっぽい小さな飛行石に、複数のコマンドを用意している。「困った時のおまじない」であるとか、「滅びの言葉」がそれである。飛行石を身
大企業はソースコードの管理に何を使っている？
Facebookの元CTOだったダスティン・モスコヴィッツが立ち上げた質問サイト、Quoraにて大企業がどんなソースコード管理システムを使っているのか？という質問が挙っていました。Quoraは回答の質が高いという触れ込みでスタートしているサービスなのでこれらの情報は多分正しいのでしょう。 Facebook svn (一部の人はgitも使っている) Amazon perforce Zynga svn Netapp Perforce Google git(Android), Perforce Quora git SAP Perforce ebay Clear Case git(実験中) VMware Perforce この内容の限りだとオープンソースではgit、商用ではPerforceという流れがあるようですね。 via:http://www.quora.com/What-version-co
設計書を作ってるせいで生産性落ちてないか？
1 ：仕様書無しさん：2007/01/25(木) 23:27:12 概要設計書、外部設計書、詳細設計書 クラス図、シーケンス図、状態遷移図、アクティビティ図 リファレンスマニュアル、レビュー管理記録、成果物リスト、・・・・・・・ アホか、、 外設した後はさっさとコーディングした方が 設計書なんかで妄想してるより何倍も多くのことが分かるっての。 で、実装とテストが終わったあとに 改めて補足のドキュメントまとめた方が明らかにソースと食い違いのないものができる。。 だいたい「ソフトウェア 設計書」でググったら 現状懐疑論ばっかじゃねーか。 2 ：仕様書無しさん：2007/01/25(木) 23:31:57 設計書よりも デバッグ期間とか、発生数／対応数のグラフだけ毎日書くひとじゃねえの？ 3 ：仕様書無しさん：2007/01/25(木) 23:37:05 >>2 そういう単純作業は派遣社員に
ゲームプログラマーという職業はもうありません。 - teruyastarはかく語りき
暴言なのは分かってますが、 学生の頃ゲームプログラマーを目指した昔の僕に そのまま言ってやりたいセリフ。 こんな記事を見つけたので。 プログラマ、ＳＥ、ゲームプログラマについて - Yahoo!知恵袋 http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1438427284 自分は将来、プログラマ、いずれはＳＥになりたいと考えていましたが、 最近では３Ｄも学んで、ゲームも作ってみたいと思うようになりました。 長時間労働、低賃金といわれていますが、やってみたいんです。 そこで、本題なんですが、 上記の仕事で働くには、今、どんなことをすればいいんでしょうか。 プログラマとして、働けるのは短いとか、 ゲーム業界は就職倍率高いとかは分かっています。 自分がやりたいのは、ＢＧＭとかグラフィックではなくて、 企画、制作、プログラムという部門
SubversionとTracでファイル管理の“迷宮”から脱出
SubversionとTracでファイル管理の“迷宮”から脱出：ユカイ、ツーカイ、カイハツ環境！（2）（1/4 ページ） プロジェクトで修正／仕様変更が“迷宮”入りする理由 ソフトウェア開発を行ううえで、設計書やソースコードのバージョンをきちんと管理することは非常に重要です。構成管理（ファイル管理）を行っていないプロジェクトでは、例えば次のような問題が発生します。 2人以上の開発者が同時に成果物を編集した場合、後に編集を始めた開発者がすでに編集を行った開発者の編集内容を上書きしてしまう。結果として、修正したはずのバグや変更したはずの仕様が、設計書やソースコードに反映漏れするという事態が発生 設計書やソースコードのレビューを行って修正したはいいが、どこをどう修正したのか分かりにくく、レビュー内容の反映の確認を行っても修正漏れや修正誤りに気が付かない ソースコードを変更すると、動かなくなってし
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
プログラミングに関するあまり知られていない７つの真実