Semantic Versioningの闇 - knqyf263's blog
今回も誰も興味ないシリーズなので今まで書いてこなかったのですが、Semantic Versioningに関して幻想を抱いている人がいる可能性があり、そういう方にどうしても現実を知っておいて欲しかったので書きました。3行要約（と可能なら余談）だけでも読んでいただけると幸いです。 3行要約 Semantic Versioning 2.0.0にはバージョン"比較"の定義はあるが、バージョン"制約"（>= 2.1.3みたいなやつ）の定義がない その結果、同じsemver準拠ライブラリでも制約の解釈が異なり結果が真逆になる というかそもそもsemver使ってるエコシステムが少なすぎる 背景 セキュリティアドバイザリでは特定のバージョンが脆弱であることを示すためにバージョン制約が使われることが多いです。例えば >=1.2.0 <1.2.6みたいなやつです。この場合、1.2.5は脆弱だが1.2.6は修正
転校生の本歌取 - steps to phantasien
ふと思い出し書き直しの話 (1, 2) の続き。 書き直しの必要に迫られることも、たまにはある。それはオリジナルが手に入らないとき。転職先で前の職場にあった内製ツールが使いたい。慣れたプログラミング言語にあったライブラリが新しい言語に欲しい。そんなときは自分の新しい環境でオリジナル相当品を書き直したいかもしれない。再発明、移植なんて呼ぶこともある。 この書き直し、再発明は、必ずしもオリジナルを超えなくていい。越えるべきオリジナルを使えない事情があってのコードだから。スポーツの試合で怪我をしたエースのかわりに急遽投入された補欠の立場に似ている。ベストを尽くし役割を果たせばいい。補欠系書き直しとでも呼ぶことにしよう。 Bazel と補欠たち 一応の役目は果たすものの、オリジナルほどはぱっとしない。そんな補欠系書き直しはたくさんある。 プログラミング言語をまたいだ補欠系書き直しとして真っ先に思い
パターンによるソフトウェア構成管理 - 未来のいつか/hyoshiokの日記
パターンによるソフトウェア構成管理を大学の図書館で見つけて読んでみたところ意外に良書だったので紹介する。 16個のパターンを紹介している。 Pattern Name Summary Mainline マージを最小化する。メインラインで開発することによってアクティブなコードラインの数を管理可能な集合にする。 Active Development Line Active Development Lineを作ることによって急激に成長するコードラインを安定化する Private Workspace Private Workspaceによって、統合の問題で集中できない状況から守る、また自分の変更が他の人に影響を及ぼさないようにする Repository 必要なものを全て持っているRepositoryを設定する Private System Build Repositoryにコミットする前にPriva
Github Enterprise じゃなくてもいいじゃん
1) Gitlab was chosen as an alternative to GitHub Enterprise due to its web UI, pull request functionality, and the fact that it could be maintained by GREE Tech's 80 Ruby engineers. 2) The company transitioned from Subversion to Gitlab by using git-svn to allow cross commits between the two systems during a period of combined use. 3) The speaker felt pull requests promoted a better development cul
Version Control by Example
About the book This book uses practical examples to explain version control with both centralized and decentralized systems. Topics covered include: Basic version control commands and concepts Introduction to Distributed Version Control Systems (DVCS) Advanced branching workflows Strengths and weaknesses of DVCS vs. centralized tools Best practices How distributed version control works under the
Mercurial MQ について - daily dayflower
巷では git の大ブームだけど，ひさしぶりに Mercurial について書きます。 Mercurial について言及されたブログとか読んでいるとき，たまに MQ という言葉を目にして気になっていた。ながらく気にはとめつつ全然調べていなかったんだけど，ちょっと利用しようかなというケースがあり，ちょこっと触ってみた。 自分の理解では，MQ (Mercurial Queues) とは，誤解を恐れずにいえば Mercurial の changeset と独立して構成される修正履歴（パッチ）のスタックのようなものだ。 （なので今後 MQ の patch queues を Queues という名称と裏腹に「パッチスタック」「パッチ群」などと勝手に呼び称します） 「誤解を恐れずにいえば」と書いたけれど，この直感的な印象は MQ を使っていくうちに――大筋では変わらないものの――ちょっと変わった。それ
＠IT編集部のblog : Git!? そんなの学生しか使わんよ
2009年06月09日21:53 カテゴリ 西村 こぼれ話 Git!? そんなの学生しか使わんよ こんにちは、＠ITの西村です。JavaOneの展示会場に出展していた「Perforce」（パフォース）が目にとまりました。プロプライエタリなソースコード管理ツールです。名前は聞いたことがありましたが、実はどんなものかよく分かっていません。Perfoceのサイトによれば、世界中の4700組織で28万人の開発者が使っているデファクトスタンダードということです。ソフトウェア開発者だけでなく、AMDやNVIDIAといったチップメーカーも入っているようです。バイナリの管理もできからという話です。最近はGitやMercurial、あるいはSubversionが話題ですが、プロプライエタリのPerforceのほうがパフォーマンスや機能、スケーラビリティでは優れているのかもしれません。私は思わずブースに近づき
ソーシャル化するOSS開発者たち － ＠IT
ロング・テール理論の名付け親で、雑誌「Wired」の編集長としても知られるクリス・アンダーソン氏が3月12日付けのブログでオープンソースソフトウェア（OSS）プロジェクトの運営体制に関する誤解を指摘をしている。 アンダーソン氏によれば、多くの人はオープンソースプロジェクトというのは草の根から立ち上がり、自律的に組織化し、民主的に運営されているという誤った認識を持っている。ところが現実はまったく逆で、1人か2人の「慈悲深い独裁者」によって運営されている、という。 これはオープンソースプロジェクトに参加していたり、あるいは日常的に成果物を利用している人であれば、そういうものだと首肯するかもしない。メーリングリストで客観データに基づいて議論したり、リーダーを民主的に選ぶようなプロジェクトもあるかもしれないが、おおかたのオープンソースプロジェクトには、それを開始し、中心に位置し続ける“独裁者”がい
Copyright © 2008, Junio C Hamano All Rights Reserved Introduction to git Junio C Hamano <gitster@pobox.com> 2 Introduction to git Copyright © 2008, Junio C Hamano All Rights Reserved git A distributed Source Control System, started by
Copyright © 2008, Junio C Hamano All Rights Reserved Introduction to git Junio C Hamano <gitster@pobox.com> 2 Introduction to git Copyright © 2008, Junio C Hamano All Rights Reserved git A distributed Source Control System, started by Linus Torvalds in April 2005. Originally developed for the Linux kernel. Used by many nonkernel projects: Wine, X.org, OLPC, RoR, Samba, VLC... 3 Introduction
プログラマの思索: Redmineを使って気づいたこと
日々の新規開発をRedmineのチケットで進捗管理して気づいた点があったのでまとめてみる。 【1】ロードマップを見ると、進捗率が逆に下がる場合がある 下記のロードマップになるようにチケットを登録したと仮定しよう。 ◆ロードマップ1：5月1日現在 進捗：0％ #1 機能Aの開発（新規） #2 機能Bの開発（新規） #3 テスト（結合テスト）（新規） すると、普通は、0％→33％→66％→100％ と進捗率が上がって終わるはず。 ◆ロードマップ1：5月5日現在 進捗：100％ #1 機能Aの開発（終了） #2 機能Bの開発（終了） #3 テスト（結合テスト）（終了） しかし、テストでバグが上がったり仕様変更が入った時、バグ報告をチケットに登録すると、下記のようになる。 ◆ロードマップ1：5月6日現在 進捗：42％ ← 終了3件/全7件だから。 #1 機能Aの開発(終了) #2 機能Bの開発(終
メインラインモデルとソフトウェアプロダクトラインの類似性 - プログラマの思索
アジャイルプラクティス勉強会in関西に出て、メインラインモデルをソフトウェア構成管理の視点から興味深い指摘があった。 組み込み系では、メインラインでソース管理していても、多種類の似たような製品を作る派生開発が多い。 例えば、iPodのように、似たような機能だがどれも微妙に仕様が異なる家電製品など。 元々、組込系製品やパッケージ製品では、製品ファミリーを展開して、多品種少量生産で売り込むビジネスが多い。 だから、製品ファミリーのソフトウェア構成管理にソフトウェアプロダクトラインの概念を持ち込む手法は、10年以上前から実践されてきた。 有名なビジネスモデルは、MSのOffice製品やMSが展開する製品群がそれに当たる。 本来、メインラインモデルのように、リリースブランチ・メインライン・作業ブランチのようにソース管理を複数のラインで管理する時、コア資産とアプリケーション独自の資産を分ける。 この
プログラマの思索: Subversionのブランチを有効活用してアジャイルに開発せよ
デブサミ2008講演資料の「SubversionとMaven 2 による構成管理」を読んで、改めてソフトウェア開発ではソース管理が最重要であると再認識した。 ソース管理について振り返ってみる。 【1】ソース管理の歴史 ソフトウェア開発では、ソース管理が必須だ。 ソース管理の本質は、履歴を辿って、いつでもソースをUndo、Redoできること。 昔のコンピュータ資源が希少な時、そもそもプログラムを履歴に残すことすらできなかっただろう。 今でもリリース時によくやるように、システム一式を複製して日付でリネームしていた。 僕は当初、ソース管理に、MSのVisualSourceSafeを使っていた。 CVSよりも直感的でGUIが使いやすい。 VSSを使い始めてから、下記の作業がルーチンになった。 朝、出社後、VSSから最新ソースを落として、VisualAgeForJavaのワークスペースにインポートす
SVN's svn:externals to GIT's Submodule for Rails Plugins - Panther Software
Why Git? Do you manage your Rails Plugins via svn:externals? Thinking of switching to Git but are concerned that Git lacks a direct equivalent of svn:externals? In this article I present a work-around or even IMHO a better solution than SVN's.Please note that I have posted a follow-up article, which presents a working solution using Git sub-projects to overcome the git-cat-file bad file error whe
大規模プロジェクトはバージョン管理が重要になってくる - プログラマの思索
ソース管理について良い記事があったのでメモ。 Subversionベストプラクティス 複数のアジャイルチームでのバージョン管理 「複数のアジャイルチームでのバージョン管理」の指摘は非常に重要なので、まとめておく。 【1】バージョン管理の目的 1-1. Fail First コードのコンフリクトや統合の問題を早期に解決する。 1-2. 常にリリース可能 どんなに悪いイテレーションでも、その成果物はリリース可能にならねばならない。 1-3. シンプル チェックインやマージ作業などのポリシーはシンプルで明確であること。 オブジェクト指向のパッケージ原則の一つに「再利用できる粒度とリリースできる粒度は同じだ」という法則がある。 つまり、最終的にリリース可能であるということは、その成果物が公開された時、他の誰もが安心して使える品質レベルを保障しているということ。 我々プログラマは、結局、他の開発者が
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Using CPEs for Open-Source vulnerabilities? Think Again | Veracode
GitHub - x-motemen/ghq: Remote repository management made easy
https://jp.techcrunch.com/2015/10/07/20151006new-perforce-tool-gives-developers-what-they-love-and-it-what-it-needs/
microHOWTO: Configure Subversion to trust a given SSL certificate
"複数のアジャイルチームでのバージョン管理"を若干修正する - NAnduブログ
Charming Python: Functional programming in Python, Part 3