分散SCMを使いたい！と思う今日この頃。 仕事ではSVN（Subversion）を使っているのだが、ちょっとしたお試し編集をするためにブランチを作ることに抵抗がある。ブランチは欲しい、大きめな変更をコミット無しで行いたくない、やはり少しずつコミットして進めていきたい。しかし、変更が全て記録されてしまうのがいただけない。ログが残るのは良いことなのだが、本当に使うかどうか未知数な実験的プログラミングのログまで残したくない。使うと決まってから初めて残すようにしたいのだ。 すまん、これまで一緒に仕事をしてきた人々よ。俺はこれまで「ログが残って困ることがなんかある？いらなきゃ無視すればいいだけなんだから、気にするな。ブランチでもなんでもバンバン作ってしまえ！」とうそぶいてきているわけだが…ハッタリかましてました！本当は俺も抵抗があるのだ。 そこで、分散SCMだ。さらにいうと、SVKがいまひとつ気に入

頻繁に使うわけではないけど便利なgitのtipsをいくつか紹介。というか自分が忘れるからメモ。 git stash 現在作業中のbranchでまだコミットはしたくないけど、trunkで直さないといけないバグとかが見つかったときに、今の変更を横にどけておくコマンド。 $ git stash で変更をいったん横にどけておいて、他のbranchに切り替えて作業後、今のbranchに戻ってきて $ git stash pop とすれば横にどけておいた変更が復活する。 git ignore プロジェクトの中で除外する必要があるファイルは.gitignoreに書くけど、自分の環境だけで除外したいファイルがある場合は.git/info/excludeに書くのがよいです。 自分の環境ではいつでも除外したいというときは $ git config --global core.excludesfile $HOM

赤び～の備忘録 & 子育て月記 Linux/Mac関連の個人的な備忘録と第一子の育児記録です。 Xen、KVM、Java、Eclipse、JSF2.0 を中心にまとめています。 現在は CentOS 6.3 の 64bit と Mac OS X 10.8 をメインに使用中です。

ＩＴ業界の人からときどき聞く発言の一つに、「ＩＴプロジェクトではクリティカル・パス法なんか使えない」という主張がある。わたしはスケジューリングとかタイム・マネジメントの分野で長く仕事をしてきたが、こういう主張をＩＴ分野以外できいた覚えがない。ＩＴ業界人は知的な人が多いと思うが、自分達の仕事を“特殊な仕事”だと考える傾向も強いように思われる。無論ある意味では特殊な分野かもしれないが、だとしても1日の作業のあとに2日の作業をした場合、合計3日かかるのは、どんな仕事でも共通ではないか。なぜＩＴ業界の人だけ、“ウチの分野は1+2=3の算数が成立しない”といった意味のことを言いたがるのか？　当初はとても不思議に感じた。 しかし、話しあっていく内に、次第にＩＴ系の人たちの抱える不満、ないし問題がすこしずつ分かるようになってきた。クリティカル・パス法はいうまでもなく、プロジェクト全体を複数のアクティビテ

English follows Japanese. 以下のコンテンツは新規情報がみつかる度に書き換えられます。 xcode 4.3 から Commandline tools とか色々と分離されたらしい。 ちょうど同じタイミングで Mac Ports とか HomeBrew とか更新したお陰で半日潰すハメになったよ。。 とりあえず本体は Appstore からで、他は Developer site とか、紛らわしいから止めて欲しいのだが、リリースノート読まない俺が悪いのか。。Apple Developer Account 持ってる人は AppStore からインストールしないほうがいい気がするぞ。 とりあえず分かったこと。 Xcode.app は Application 本体と各種ツール群を分離 その結果、アプリケーションの実体のインストール先がこれまでの /Developers  から /

オライリー・ジャパンから先日発表されたプレスリリース「ePUBフォーマットによる電子書籍のラインナップを開始します」にあるとおり、弊社トップスタジオはオライリー・ジャパンとの共同事業として、ePUBフォーマットでの電子書籍の制作を開始しました。 トップスタジオではこのePUBフォーマット電子書籍の出版候補の選定、翻訳、編集、そしてePUB制作までに関わっています。本稿では、このePUBの制作プロセスを支えるシステムにフォーカスを当て、その仕組みについて紹介します。 フリーソフトウェア/オープンソースソフトウェアの集合体としてのシステム ePUBの作成にはいろいろな手法がありますが、制作を支えるシステムを構築する上で最も重視したのは、できる限り自動化し、手作業による調整を最小限にするということでした。そのため、このシステムでは原稿を常に最新マスターデータとしてそこから一方向にePUBを作成す

Register as a new user and use Qiita more conveniently You get articles that match your needsYou can efficiently read back useful informationYou can use dark themeWhat you can do with signing up

ときどき間違うので。 大雑把に言うと、git rebase は「git reset + git cherry-pick × n回　を自動化したもの」と考えられる（適用するコミット群が少なければ、手動でreset & cherry-pickしても良いが、たくさんあるとそうもいかない） 好きな場所にresetして、好きな位置から好きな位置までのコミットを順次適用できる。 つまりコミットを並べ替えたり除外したり、「積み木を積み直す」ようなことが出来る。 git rebase ポピュラーな使い方。 現在のブランチをにreset から見て現在のブランチにだけ存在していたコミットを順に適用 適用されるコミット群は、から見て現在のブランチにだけ存在していたコミット、つまりgit log ..HEAD で出てくるコミット。 以下の例だとA、B、Cのコミットがreset後に適用される予定 A---B---C

クリアコードではMozilla製品やRuby関連の開発だけではなく、広くフリーソフトウェアのサポートもしています。もちろん、サポート対象のソフトウェアの多くは私達が開発したものではありません。しかし、それらのソフトウェアに問題があった場合は調査し、必要であれば修正しています。 このようなサポートが提供できるのは、もともと、私達がフリーソフトウェアを利用したり開発したりしているときに日常的に問題の調査・修正をしていたからです。ソフトウェアを利用していると、問題に遭遇することはよくあることです。そのソフトウェアがフリーソフトウェアの場合は、開発者に問題を報告し、可能ならパッチを添えます。このとき、そのソフトウェアの内容を完全に把握していることはほとんどありません。しかし、それでも修正することができます。 それはどうしてでしょうか？今まではどのようにやっているのかを自分達でもうまく説明できなかっ

費やした55億円、水の泡に　特許庁がシステム開発中断 技術検証報告書 ～フォローアップ結果とりまとめ～ 平 成 ２４年 １月 ２３日 どっちを読んでも全然わからん。というわけで、 賀沢さんのGoogle+ をヒントに平成22年8月20日の 調査報告書 を読んでみた。めっちゃ読みに...

捕捉できる範囲でまとめました。スタッフの熱意にただただ感動。 ※フォロー外もまとめているので問題がある場合は報告なり編集なりしてください。編集可設定です。

ドットインストール代表のライフハックブログ

先日、ソースコードのメンテナビリティについてのエントリを書きましたが、dankogaiさんから「で、具体的にどんなコード書いてるの？」という指摘がありました。 返信エントリでは、「DataSpiderはオープンソースではないのでソースコードをそのまま出すことはできない」と書いたのですが、よく考えたら、一部エッセンスを抜き出してサンプルコードとして紹介することはできるので、最近私が書いたコードの中で、メンテナビリティに関係するコードを紹介したいと思います。 ※ ソースコードの行数が正しく表示されない場合にはブラウザの幅を広げると正しく表示されます。なお、ソースコードの構成をシンプルにするため今回のサンプルではViewModelは使用していません。 目次 ・コンポーネント間のインタラクションの管理 ・最も原始的な実装方法: コンポーネントの相互参照 ・Mediatorパターン ・Role Ob

2. はじめに ● ２００８年からRedmineで様々なプロジェクト管理を行ってきた。 ● 中には凄く忙しい案件、危機一髪な案件もあり。 →こういうケースでのチケット運用の肝が見えてきている →自分の経験を一回フィードバックしておきたい 注：あくまでもテンパる前に何とかするのが プロジェクト管理の理想です！ 4. 状況 (よくありがちなケース)：その１ ● 終了済みバグ、タスクがRedmineに大量に山積みされている ● 優先度や期日が有名無実化 ● チケットの粒度があいまい (一週間かかるものまである) ● なぜかExcelやGoogleドキュメントが併用して使われている。 ※ある時点でのチケット一覧をCSVで出力。 顧客から言われて作ってしまったケースが多い。 5. 状況 (よくありがちなケース)：その２ ● 次から次へとタスクやバグが追加される → 終わりが見えないので各担当者のモチ