ネイティブと働いて分かった英語コミットメッセージの頻出動詞10つ
ウッ ここで詰まる事は往々にしてあります. 特に急いでる時の煩わしさは甚だしいです. どうせならそれっぽい英語を使いたいのでOSSや同僚のコミットメージの語彙の出現確率を調べてみましたら、 もちろんfeatureによってコミットメッセージの付け方など数多あるものの、一定の頻出パターンは見い出せたので筆を取りました. （英語勉強しないと..） 方法 github.com/rails/railsのコミットメッセージ内における各動詞の出現確率を求め、 またOSSと仕事でのコミットメッセージの趣向も変わってくる事も勘案するため、 （仕事でDeprecateとか滅多に使わんし） 同僚に聞きつつ10つあげてみた. 以下列挙 （例は実際の同僚やOSS上でのコミットメッセージです.） Add *A to *B AをBに加える
Eclipse 3.6 Helios × Subversive - 都元ダイスケ IT-PRESS
ご無沙汰しちょります。最近はがっつりAndroidの世界に身を置いてます。 さて、えーと、いよいよHeliosリリースですね。一般DLは始まっていないようですが、明日みんなDLできるようになるようです。わたしゃEclipseにはさんざんお世話になってるので、35US$を寄付してEclipseのお友達になってまして。前日からお友達専用サーバからダウンロードができる、というわけです。 さて、この時期はHeliosの新機能紹介なんかをするのが順当かとは思ってたんですが、id:kompiroに先を越されたので、そちら参照ｗ いよいよEclipse3.6(Helios)がやってくる。 - Fly me to the Juno! で、ですね。実はSubversiveを使っている人に悲報。control+option+C (commit)等のショートカットが、Heliosでは死んでしまうのです。いやー、
App Engine SDKを導入したEclipseが起動時に固まる現象 - nakawai’s diary
GAE/Java開発で困っていた現象なのですが、twitterで回避策を教えてもらいました。 具体的な操作をメモとして残しておきます。 現象 Eclipseを起動すると、ステータスバーに「Updating <プロジェクト名> ... gine」と進捗バーが表示された状態でフリーズする。 強制終了して、何度かEclipseの再起動を試みるとそのうち起こらなくなる。 現象を確認した環境 Eclipse 3.5 Google Plugin for Eclipse 3.5 (GPE) Google App Engine SDK Java 1.3.1 Subversive + SVNKit 1.3.0 上記で、App Engine SDKを使用したプロジェクトをSubversion管理対象にすると発生する。 回避策 war/WEB-INF/libの配下のApp Engine関連のjarをsvn:ig
バージョン管理ツールを使うとやる気が出る - プログラマの思索
「バージョン管理ツールを使うとやる気が出る」という文章に激しく同感。 【元ネタ】 論文を書くときにTeXを使う個人的な理由 - より良い環境を求めて (前略) それからバージョン管理ツールを使うとやる気が出る。 これはgitwebを使い出した効果で、履歴一覧で前回の変更からの経過時間が「1 hours」とか出る。 これが「5 hours」とかになってくるとやばいという気になってきて、とりあえず何でもいいからコミットする。そうすると、やる気はやり始めてから出るの法則で少しずつ進む。 「3 days ago」とかになってきたらもう「。」を「．」に変えるだけとか「である．」を消すとかそういう些細なことでも何かコミットしなきゃという気になってきて、そこから書き始めることができる。 (後略) ソースだけでなくExcelやWordに書いた設計書もバージョン管理すべき。 更新履歴を見るだけで、更新しなき
コミットコメントの書き方 - wyukawa's diary
ソースコードのコメントの書き方についてある程度情報が出回っているように思うが、コミットコメントの書き方についてはあまり情報が無い気がするのでちょっと書いてみる。自分が出来ているかはおいといてｗ で、これはリポジトリとバグ管理システムとセットで考えなくちゃいけないと思っている。まあ要するにTracやRedmineを使ったチケット駆動開発前提の話です。つまりコミットコメントにはチケット番号を書け。以上、って話でもあるｗ コミットにはタグやブランチ作成のコミットを除くと大きく分けて２種類あると思う。１つ目はバグ修正のためのコミットで２つ目は機能追加のためのコミット。リファクタリングは２つ目に属するとする。 コミットはバグ修正、機能単位つまりチケット単位で行うべきだと思ってる。複数のバグ修正のためのコミットを１回でやられるとどのコミットがどのバグ修正に関連付いているのかわからない。こうなっちゃうと
SVNリポジトリの管理方法の追記 - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
SVNリポジトリの管理方法 - プログラマの思索
かおるんさんの記事のコメントで、誤った意見を書いてしまったので修正しておく。 【元ネタ】 Subversion のフォルダ構成 - かおるんダイアリー Subversionのフォルダ構成 | Ryuzee.com Subversionで簡単・確実にファイルを構成管理 － ＠IT自分戦略研究所 InfoQ: 複数のアジャイルチームでのバージョン管理 【問題】 SVN直下のディレクトリは、branch/tag/trunkになっている。 ソースやドキュメントはどこに配置すべきか？ 【結論】 管理したい一つのまとまり(プロジェクト)単位で、trunk/branch/tag を作った方がブランチを管理しやすいと思っていた。 最初はtrunkの中にソースやら仕様書を配置して、管理方法がよく分からなかった。 でも、さかばさんと議論してみて、ryuzeeさんのやり方が良いと思う。 思い出してみたら、下記の
ドキュメントも構成管理すべきだ - プログラマの思索
SVNで構成管理する時の良い記事が公開されたのでメモ。 【元ネタ】 Subversionで簡単・確実にファイルを構成管理 － ＠IT自分戦略研究所 SVNの使い方の記事はネット上にいくらでもある。 しかし、上記の記事で重要と思われる内容は、構成管理や変更管理の考え方を初心者向けに分かりやすく説明している点と、ドキュメント管理に構成管理の考え方を入れるべきだという主張だ。 CMMIの観点では、ソフトウェア構成管理は「変更管理を含むソフトウェアの構成を制御・管理できていること」と定義されている。 この考え方に基づくと、バージョンとは実はプロセスのベースラインを意味する。 つまり、リリース時にバージョン(又はタグ)を付けるタイミングは、開発者から顧客へ、あるいは営業チームから顧客へ、などのように、他者へ成果物を手渡すタイミングと同一なのだ。 構成管理が変更管理と密接に関係する理由は、上記のような
分散バージョン管理Git/Mercurial/Bazaar徹底比較
分散バージョン管理Git/Mercurial/Bazaar徹底比較：ユカイ、ツーカイ、カイハツ環境！（3）（1/5 ページ） Subversionとは一味違う「分散バージョン管理」とは？ 最近、Linuxをはじめ、Ruby on Rails、MySQL、OpenSolarisなどのオープンソースプロダクトが次々と分散バージョン管理システムを導入し始め、「Git」「Mercurial」「Bazaar」といった、分散バージョン管理システムが注目を浴びています。 本稿では、バージョン管理ツールのデファクトスタンダードであるSubversion（以下、SVN）と分散バージョン管理システムを比較しながら、メジャーな分散バージョン管理システムであるGit、Mercurial、Bazaarについて紹介していきます。 集中型と分散型 最初に、集中管理方式（または、集中型）のバージョン管理システムと分散管理
Subversionを見直せ - プログラマの思索
SW構成管理の概念の中心は、バージョン管理。 バージョン管理こそが我々SW開発に従事する者にとって、背骨であり血液に当たる最重要なインフラ。 デスマーチに陥るプロジェクトは、バージョン管理に何かしらの欠点や弱点がある。 おそらく殆どのSW開発では、Subversionをバージョン管理に使っているが、Subversionは実は数多くの機能を持ち、従来のプロジェクト管理を根本的に変える可能性を秘めている。 もう一度、Subversionの機能を見直してみた。 【1】ムービー企画「Subversionによるバージョン管理入門」 WEB+DB PRESS Vol.39誌面連動ムービー｜gihyo.jp … 技術評論社 最近のバージョン管理は、trunkとbranchの2系統のバージョン管理戦略を持つ傾向がある。 メインラインモデルと呼ばれる。 メインラインモデルの手法を使って、本番運用中の保守br
SubversionとTracでファイル管理の“迷宮”から脱出
SubversionとTracでファイル管理の“迷宮”から脱出：ユカイ、ツーカイ、カイハツ環境！（2）（1/4 ページ） プロジェクトで修正／仕様変更が“迷宮”入りする理由 ソフトウェア開発を行ううえで、設計書やソースコードのバージョンをきちんと管理することは非常に重要です。構成管理（ファイル管理）を行っていないプロジェクトでは、例えば次のような問題が発生します。 2人以上の開発者が同時に成果物を編集した場合、後に編集を始めた開発者がすでに編集を行った開発者の編集内容を上書きしてしまう。結果として、修正したはずのバグや変更したはずの仕様が、設計書やソースコードに反映漏れするという事態が発生 設計書やソースコードのレビューを行って修正したはいいが、どこをどう修正したのか分かりにくく、レビュー内容の反映の確認を行っても修正漏れや修正誤りに気が付かない ソースコードを変更すると、動かなくなってし
Subversion設定の標準化
ディノ社内のバージョン管理は主にSubversionを利用しています。また、社内の開発環境はWindowsとMacとLinuxが入り乱れています。そんな環境で、一番問題が少なそうなSubversionの設定を考えてみました。現在これを社内標準として運用していますが、今のところ大きな問題は起きていません。 設定内容ですが、auto-propsとglobal-ignoresの設定です。各種ファイルについて、eol-style=nativeやkeywords=Idやsvn:mime-typeなどを設定します。 ちなみに、本設定はsymfonyの公式オススメ設定「Symfony Repository Tips」から大半を流用しています。 設定内容 設定内容はsubversion-config.txtの通りです。同じ内容を以下に貼付けておきます。 [helpers] #diff-cmd = dif
昨日のエントリーにお返事 - 都元ダイスケ IT-PRESS
ぼくは更新したプラグインのみ、MANIFEST.MFのバージョンを上書きするのが本来の筋じゃないかなと思います。 その通りですねー。本来。 Eclipseほどの規模になれば、Ganymedeのリリース責任者とECF, Mylyn等のリリース責任者は当然異なりますので、同じバージョンに揃える方がコストが高く、リスクが大きいからこそ、こういう事になっているのでしょう。 ただ、Sabotterに関しては全コンポーネントが自分の配下にある為、そこまで厳密にやる価値も感じていません。更新されたプラグインのバージョン表記を上げ忘れるよりも、更新していないプラグインのバージョンを上げる方がリスクが少ない。ということで、この様な対処方法になっています。 ケースバイケースじゃないですか、ということで。 # qualifierについては、採用済みです。 trunkでチェックアウトする件は、「Find/Chec
Eclipse+Subversive環境での、複数プロジェクトの扱い - 都元ダイスケ IT-PRESS
やー、凹んだorz 何が起きたのか Sabotter 0.0.2リリースの為に、タグ打ったんですよ。 そしたら、その一操作でCodeReposに12回ものコミットが入ったんですよorz で、IRCで話題沸騰。 一般的な話 Sabotterは、12個の「Eclipseプロジェクト」に分かれています。もう少し詳しく言うと、7つのコンポーネントと、5つのフィーチャープロジェクト*1。そして、その7つのコンポーネントはそれぞれ依存関係があります。 Sabotterの様な複数コンポーネントのプロジェクト群は、repository/trunk 内に、複数のディレクトリを作って、それぞれコミットすると思います。で、チェックアウト時には trunk ディレクトリを指定して、内部のプロジェクトをごっそりチェックアウトしますね。これが一般的な使い方。 /repository/ trunk/ Component
大規模プロジェクトはバージョン管理が重要になってくる - プログラマの思索
ソース管理について良い記事があったのでメモ。 Subversionベストプラクティス 複数のアジャイルチームでのバージョン管理 「複数のアジャイルチームでのバージョン管理」の指摘は非常に重要なので、まとめておく。 【1】バージョン管理の目的 1-1. Fail First コードのコンフリクトや統合の問題を早期に解決する。 1-2. 常にリリース可能 どんなに悪いイテレーションでも、その成果物はリリース可能にならねばならない。 1-3. シンプル チェックインやマージ作業などのポリシーはシンプルで明確であること。 オブジェクト指向のパッケージ原則の一つに「再利用できる粒度とリリースできる粒度は同じだ」という法則がある。 つまり、最終的にリリース可能であるということは、その成果物が公開された時、他の誰もが安心して使える品質レベルを保障しているということ。 我々プログラマは、結局、他の開発者が
プログラマの思索: Subversionのブランチを有効活用してアジャイルに開発せよ
デブサミ2008講演資料の「SubversionとMaven 2 による構成管理」を読んで、改めてソフトウェア開発ではソース管理が最重要であると再認識した。 ソース管理について振り返ってみる。 【1】ソース管理の歴史 ソフトウェア開発では、ソース管理が必須だ。 ソース管理の本質は、履歴を辿って、いつでもソースをUndo、Redoできること。 昔のコンピュータ資源が希少な時、そもそもプログラムを履歴に残すことすらできなかっただろう。 今でもリリース時によくやるように、システム一式を複製して日付でリネームしていた。 僕は当初、ソース管理に、MSのVisualSourceSafeを使っていた。 CVSよりも直感的でGUIが使いやすい。 VSSを使い始めてから、下記の作業がルーチンになった。 朝、出社後、VSSから最新ソースを落として、VisualAgeForJavaのワークスペースにインポートす
Maven2の小技 SSL（https://）のリポジトリへのアクセス - 現場のためのソフトウェア開発プロセス - たかのり日記
Maven2固有の話ではないのですが、https://のリポジトリにアクセスしようとすると、Maven2がエラーとなります。 きちんとした認証局で発行された証明書の場合 Subclipseなどで、一度手動で証明書を承諾すれば、その後は何もしないで動作します。 以下のような「電子署名の承諾」というダイアログが出るので、「永久に承諾」を選択すればOK。 オレオレ認証局で作った証明書の場合 Javaの標準ツールである、keytoolを利用することで解決できます。 つくば日記 (仮): オレオレ証明書を使った https://〜 なリポジトリにアクセスでエラー発生。
構成管理ベストプラクティス 〜変更管理計画〜 - 現場のためのソフトウェア開発プロセス - たかのり日記
「構成管理」と言うと、主にバージョン管理の部分が協調されることが多いように思うのですが、変更管理も重要です。バージョンだけを管理していても、何の変更によりバージョンが修正されたのか、どのバージョンに対する変更なのかが分からないためです。 変更管理ツールは、以前はBTS（Bug Tracking System）と呼ばれることが多かったですが、最近はバグだけでなく、要件やTODOタスクなども管理できるようなITS（Issue Tracking System）と呼ばれるようなツールが多くなってきています。 ここでは、ITSを前提として話をします。なので、1つの変更要求は「Issue」と呼ぶこととします。 入力項目は集計／分析することを前提に決定する Issueには、要件／バグ／タスク等の分類がありますが、入力項目は、各分類に対して、集計／分析したい内容に基づいて決定しておきます。最初は、Issu
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Subversionのリポジトリを監視「SVN-Monitor」 - 現場のためのソフトウェア開発プロセス - たかのり日記
Microsoft OfficeからTortoiseSVNコマンドを呼び出すVBAアドインプログラム