Jenkinsでプロジェクトの状況をウォッチするために、RedmineMetricsPluginと言うものを作りました。 (twitter上では自分自身RedmineTicketMetricsPluginと読んでいたり、ちょっと名前が揺れてます） 背景 システムの開発現場では「プロジェクトのタスクがどのように推移していて、どのようなフローで消化される傾向にあるか。今どれぐらいのタスクが残っているのか、それらのチケットのステータスはどうなっているか」が知りたい場面が多いです。 特にリリース直前のリリース判定会などでは「今、残不具合はN件でM日で修正できる予定です」という報告をもらっても「M日で修正できるならリリースに間に合う」という判断を行うには材料が足りません。 「不具合は今日までにどのような勢いで発生しているのか、日々不具合が報告されているのか、既に報告される数は落ち着いているのか」が分
ソフト開発のコンパイルからテストまでを自動化し、1日に複数回実施することで品質改善や納期短縮を目指す「継続的インテグレーション（CI）」が注目を集めている。米国を拠点に活動し、世界的に最も人気が高いCIツール「Jenkins」を開発した川口耕介氏は、開発の動機は“怒り”だったと明かす。 Jenkinsが実現するCIとはどのようなものですか。 ソフトウエア開発プロセスを改善するための取り組みです。プロセスのなかには、単なる反復作業がたくさん存在します。ソースコードのコンパイルなどによって実行可能なファイルを作成するビルドやテスト、品質検査などです。 人間はそもそも反復作業が得意ではありません。人間が不得意な作業は極力ツールに代行させて、開発者が設計やプログラミングに集中するのが望ましい姿でしょう。これがCIの狙いです。 ビルドツールを補完 CIという概念自体は1990年代末に、アジャイル開発
バルスのことなんですけど。 大多数のネットユーザー諸兄はご存知かと思うが、バルスは天空の城ラピュタにおける「滅びの言葉」である。劇中ラストシーンにおいて、家伝の飛行石を手にしたシータとパズーが「バルス！」と叫ぶと、なんか飛行石がやたら光ってムスカさんが目が目が星人になったりラピュタがぶっ壊れたり、色々とエラいことになる。 「バルス=滅びの言葉」という図式の定着度・認知度はWeb上では恐ろしい程であり、ラピュタ放映時には実況板が「バルス！」の書き込みとAAで埋め尽くされるという。 まず考えなくてはいけないのは、このバルスという命令は一体何の為に用意されたAPIなのかということである。 ラピュタは人工物なので、当然設計者や開発者がいた筈である。そして彼らは、管理権限キーっぽい小さな飛行石に、複数のコマンドを用意している。「困った時のおまじない」であるとか、「滅びの言葉」がそれである。飛行石を身
私の所属している会社では、2年程前にバージョン管理システムをSubversionからGitに移行し、現在まで開発フローを試行錯誤してきました。ようやく形になってきたということで、守秘義務に接触しない程度に紹介＆考察していきたいと思います。 形になってきたとはいえ、まだまだ試行錯誤中ですので色々なツッコミは大歓迎です。 現在の開発フローの俯瞰図# 現在の開発フローを俯瞰してみると大体下記図のような感じになっています。途中で図を書くのが面倒になった都合上、Jenkinsさんが１人しか居ませんが、実際はmasterブランチの他にreleaseブランチも監視してもらっています。 以降この図を元に話を進めていきたと思います。 Gitoriousを利用して自由に開発# GitoriousというGitHubに似たサービスがあります。このGitoriousはオープンソースとしても公開されていますので社内に
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 名無しさん＠涙目です。(埼玉県)2011/03/20(日) 19:52:26.64 ID:FykGF+mX0● ?2BP(1) システム障害の復旧作業のために連休中の全ＡＴＭを休止しているみずほ銀行は19日夜、 ＡＴＭの代わりに臨時開業した440店舗で８万5000人が合計49 億7000万円を引き出したとの集計結果を発表した。 ＡＴＭを休止して復旧作業を進めた結果、最大で116万件程度まで膨らんでいた決済の未処理は78万件程度になった。 臨時開業した店舗の窓口は午前９時から午後５時まで。 利用客は通帳やキャッシュカードに加えて身分証明書を提示して専用の領収書に名前や口座番号、 金額を記入すれば、窓口で最大10万円まで受け取れる。 http://www.nikkei.com/news/category/article/g=96958A9C9C81E2E2E3E2E2E2E58DE3EBE
1 ：仕様書無しさん：2007/01/25(木) 23:27:12 概要設計書、外部設計書、詳細設計書 クラス図、シーケンス図、状態遷移図、アクティビティ図 リファレンスマニュアル、レビュー管理記録、成果物リスト、・・・・・・・ アホか、、 外設した後はさっさとコーディングした方が 設計書なんかで妄想してるより何倍も多くのことが分かるっての。 で、実装とテストが終わったあとに 改めて補足のドキュメントまとめた方が明らかにソースと食い違いのないものができる。。 だいたい「ソフトウェア 設計書」でググったら 現状懐疑論ばっかじゃねーか。 2 ：仕様書無しさん：2007/01/25(木) 23:31:57 設計書よりも デバッグ期間とか、発生数／対応数のグラフだけ毎日書くひとじゃねえの？ 3 ：仕様書無しさん：2007/01/25(木) 23:37:05 >>2 そういう単純作業は派遣社員に
1 名前：以下、名無しにかわりましてVIPがお送りします：2011/02/03(木) 22:35:36.67 ID:lm3qMq680 ただしSIは除く 47 名前：以下、名無しにかわりましてVIPがお送りします：2011/02/03(木) 23:39:44.31 ID:vYSOiTpY0 *ワロタ プロジェクトによってはデスマになるしなｗ 59 名前：以下、名無しにかわりましてVIPがお送りします：2011/02/03(木) 23:48:02.72 ID:+F3ZABCZ0 SIって何？システムインフラ的ナ？ 62 名前：以下、名無しにかわりましてVIPがお送りします：2011/02/03(木) 23:50:05.26 ID:O+y+/ePwP >>59 システムインテグレーション SIerとは エスアイアー, エスアイヤー： - IT用語辞典バイナリ http://www.sophia
暴言なのは分かってますが、 学生の頃ゲームプログラマーを目指した昔の僕に そのまま言ってやりたいセリフ。 こんな記事を見つけたので。 プログラマ、ＳＥ、ゲームプログラマについて - Yahoo!知恵袋 http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1438427284 自分は将来、プログラマ、いずれはＳＥになりたいと考えていましたが、 最近では３Ｄも学んで、ゲームも作ってみたいと思うようになりました。 長時間労働、低賃金といわれていますが、やってみたいんです。 そこで、本題なんですが、 上記の仕事で働くには、今、どんなことをすればいいんでしょうか。 プログラマとして、働けるのは短いとか、 ゲーム業界は就職倍率高いとかは分かっています。 自分がやりたいのは、ＢＧＭとかグラフィックではなくて、 企画、制作、プログラムという部門
Home | Serena Open Source and Hosted Project Management Software via GIGAZINE フリーでありながら Microsoft Project 互換の高機能プロジェクト管理ソフトである「OpenProj」を試してみました。 ■動作環境 Java で作成されているため Windows/Mac/Linux で動作可能で、GIGAZINE によると JRE1.5以上で動作するとのこと。 一応、SOURCEFORGE.NET では以下のような動作環境になっていました。 # Operating System : All 32-bit MS Windows (95/98/NT/2000/XP), All POSIX (Linux/BSD/UNIX-like OSes), OS X # Programming Language : Ja
1 はじめに システム開発における要求分析モデルとして、ユースケースを中心に説明してきました。 ユースケースはユーザの目的をモデル化したモデル要素であり、システムがユーザに提供する機能を表現するという意味で機能要求のモデルといえます。第1回では、図1[営業社員のシステム・ユースケース]に示すユースケースを用いた要求モデルを作成しましたが、これは機能要求ということになります。 しかし、要求仕様は機能要求だけで構成されるわけではありません。実際のシステム開発では「ユーザの目的」とは別の観点でさまざまな要求を定める必要があります。このような機能外の要求のことを非機能要求と呼びます。 今回は、この非機能要求について説明します。 2 ISO/IEC 9126(JIS X 0129) 非機能要求を考える上では、システムの品質という切り口が重要です。 ISO/IEC 9126は、ソフトウェア開発における
はじめに 役に立つシステムを構築するための要件定義書とは、いったいどういうものなのでしょうか。 「何でこの機能が必要なんですか？」「理由は分からないけどXXX機能があるのでこの機能が必要なんです。これがないとつじつまが合わなくなるんです」もしくは「要件定義書にこの機能が載っているので必要なんです」など、要件定義書の役割を理解しないまま、システムの開発に着手していることなどがないでしょうか。 本稿では、要件定義書の役割や重視すべき点、要件定義書に盛り込むべき情報について解説します。 何をやるのか、そしてなぜそうするのか 要件定義書はジグソーパズル？ システム開発を受託した会社にコンサルテーションしたときのことです。機能とデータがある程度記述された要件定義書を受け取ったその会社では、要件定義書を読み解き、システムの全体像を掴むためにおのおのの機能の関係を整理し、その役割を把握しようとしていまし
かつては憧れであり、ステータスだった「管理職」。しかし、現在は「管理職になりたくない」若い世代がとても増え、管理職に任用されたタイミングで「辞表を出す」という人も少なくないといいます。その背景には、一体何があるのでしょうか。また、そんな時代にあなたが管理職になってしまったら、どうすればよいのでしょうか？ 「もし『管理職になれ』なんて言われたら、会社を辞めるでしょうね」 こう話してくれたのは、部品商社の主任社員Ａさん。入社7年目にして直属の上司は4人目になっていましたが、「仕事ぶりがよく見えない」「会社の言いなりに見える」ことで、管理職によくないイメージを抱くようになっていました。 確かにオフィスの席にあまりいない。会議ばかりしている。部長から呼び出されてヒソヒソ話をしている。一般社員からすれば、不信感が募るのももっともです。そうしたことから、管理職になるより現場で仕事している方が楽しい･･
高橋克徳（（株）ジェイフィール執行役員）、重光直之（（株）ジェイフィール執行役員） 【第12回】 2009年12月24日 先日、あるミドルマネジャーが私の前でこんな言葉をもらしました。 「上司から理不尽なこと言われても、言い返せないんです。部下にも強く言えなくて、全部自分で抱え込んじゃうんですよね」 話を聞くと、前回お話ししたような「パワハラ上司」ではないのに、彼は上司とちゃんと向き合えないようです。同時に、部下にもものが言えないのです。 こういったミドルは、争いを好まないというよりも回避するタイプです。流行の言葉で言えば、「草食系ミドル」という言い方の方がわかり易いかもしれません。 実は、私が接するミドルの多くが、こういったタイプのように思います。彼も、見るからに弱そうなタイプではないのに、対立や葛藤が起こると自分から引き下がるようです。別の見方をすれば、「職場でのバランスをとって潤滑油
マネージャの仕事の中でも重要なものに、部下に適切に仕事を任せる、というものがある。英語では"delegating(権限の委譲)"という。仕事を丸投げしたり、介入しすぎたりしては部下も思い通りの仕事ができないことは容易に想像がつく。U.S.News & WORLD REPORTに「部下に仕事を任せる際の5つの間違い(原題: 5 Ways Managers Fail at Delegating)」という記事が載っているので紹介しよう。 1. 共通の認識を持たない 仕事が成功裏に終了した時のゴールは何かということを事前に部下と確認しなかったため、最後に出てきたものがあなたの期待したものと違っていたということはよく起こる。 2. 進捗管理をしない プロジェクトの最初に話をするだけで、計画通りに仕事が進む……なんてことはない! プロジェクトに関与し続け、チェックすることはマネージャの有効な武器だ。進
「人月計算をやめたいんだよね…，どうも納得がいかない」 2008年3月15日号の日経コンピュータで「ITコスト」を取り上げた特集を組んだ。企画の段階で，「○システムなら△円」といった指標が出せないものかと考えたのである。そうした指標があれば，ユーザーがベンダーと交渉したり，逆にベンダーがユーザーに提示する相場観の目安となる。想定したのが不動産情報だ。「新宿のビルで□坪なら×円」といった情報を提供したかった。 そこでユーザーのIT部門とベンダーの両方に取材したのだが，「相場は難しいんじゃない？システムは会社によって違うから」という反応がほとんど。それに続いて「それよりも…」という冒頭の言が出てくる。どうも完成品であるシステムの機能や価値ではなく，それを作るためのコストを問題視しているようだった。 長らく使われてきたこの人月単価や人月計算を，ユーザーとベンダーの両者が止めたいと思っている（注1
SubversionとTracでファイル管理の“迷宮”から脱出：ユカイ、ツーカイ、カイハツ環境！（2）（1/4 ページ） プロジェクトで修正／仕様変更が“迷宮”入りする理由 ソフトウェア開発を行ううえで、設計書やソースコードのバージョンをきちんと管理することは非常に重要です。構成管理（ファイル管理）を行っていないプロジェクトでは、例えば次のような問題が発生します。 2人以上の開発者が同時に成果物を編集した場合、後に編集を始めた開発者がすでに編集を行った開発者の編集内容を上書きしてしまう。結果として、修正したはずのバグや変更したはずの仕様が、設計書やソースコードに反映漏れするという事態が発生 設計書やソースコードのレビューを行って修正したはいいが、どこをどう修正したのか分かりにくく、レビュー内容の反映の確認を行っても修正漏れや修正誤りに気が付かない ソースコードを変更すると、動かなくなってし
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
