t-wadaのブックマーク / 2014年3月4日

t-wada id:t-wada

2014年3月4日のブックマーク (3件)

TechCrunch | Startup and Technology News
Welcome back to TechCrunch’s Week in Review — TechCrunch’s newsletter recapping the week’s biggest news. Want it in your inbox every Saturday? Sign up here. Over the past eight years,…
t-wada 2014/03/04
Mt. Goxのソースコード、かなり腐臭がするのでレガシーコード改善 (テストの無いコードにテストを書きながら構造を改善すること) の良いお題になりそう

php

WEwLC

refactoring
リンク
uu59のメモ | semverによって演繹される世界とnpmのバージョン指定がちょっと変わる話
If at first you don't succeed; call it version 1.0. npmのバージョン指定が少し変わるらしい。 “npm install –save” No Longer Using Tildes npmのpackage.jsonでバージョンを固定するとき、~1.2.3と指定しておくと1.2.x(xは3以上でなるべく大きいもの)をインストールしようとします。これがデフォルトで^1.2.3のようになり、1.x.y(1.2.3以上で2.0.0未満のうち最新のやつ)をインストールしようとするようになったらしい。 semver、Semantic Versioningが定義するところでは、マイナーバージョンアップ(1.2.3→1.3.0)は後方互換性を壊さないはずなので^にしても理論的には問題なく、あったとすればそのパッケージのバージョニングが悪いという感じになり
t-wada 2014/03/04
"旧来は「メジャーバージョンが大きいほどよい」という漠然とした感覚（そもそも明確なルールがないので漠然とせざるを得ない）がありましたが、semver的世界ではそういう曖昧性を排除しようとしています" semver!!

node.js
リンク
Composer のセキュリティ上の問題が直ったので PHP な方は今すぐ更新を - co3k.org
Composer の以下の問題が 2 月半ばあたりから話題になっていました。 Limit Replace / Provides to packages required by name in root package or any dep · Issue #2690 · composer/composer https://github.com/composer/composer/issues/2690 一言で言うと、条件によってはユーザの意図しないパッケージがインストールされてしまうという問題です。悪意のあるパッケージをインストールしたことに気づかれなければ、攻撃者の思い通りのコードを実行させることができてしまいます。ざっくり説明すると、 Composer には fork したパッケージや、リネームしたパッケージから、元のパッケージを置き換えることのできる機能が存在する (本エン
t-wada 2014/03/04
1. composer を self-update する 2. インストールしたパッケージが期待通りのものかを都度確認 3. 自動化時は composer update ではなく、信頼できる lock ファイルを生成した上で composer install

php

security
リンク
- 2014年3月5日
- 2014年3月4日
- 2014年2月28日