タグ

2014年2月21日のブックマーク (2件)

  • Vagrant で作ったり壊したりできる Windows 環境を手に入れるまでの手順

    最近話題の Vagrant さんは「Linux の環境を作ったり壊したりして開発とか試験が楽になるよ」と紹介されることが多いけど、Windows の環境だって作ったり壊したりしたい! いろいろ調べつつ環境を作ってみたので、その手順を共有しておく。 完成イメージはこんな感じ。コマンドプロンプトから vagrant up をしたら VirtualBox 上に Windows Server 2012 R2 の環境が準備されて、そこにリモート デスクトップで接続している。 いろいろいじったあとに vagrant destroy したら環境は消え去って、vagrant up したら、また、まっさらな状態から使える。 ちょっと注目してほしいのは、ゲスト OS の C:\vagrant にホスト側の Vagrantfile がマウントされているところ。このあたりの処理は Vagrant-Windows

    Vagrant で作ったり壊したりできる Windows 環境を手に入れるまでの手順
  • DRY(don't repeat yourself)するかしないか、その判断基準について - kazuhoのメモ置き場

    「過剰なDRYが技術的負債を生む」みたいな内容の記事を書きたいが、うまく言語化できない。「過剰な事制限が健康を損なう」程度の内容に成り下がりそうだけど、そんなんじゃないんだよ… @methane 実装におけるDRYみたいなものを考えていて、そうすると前者のDRYというのがどこに位置づけられるかはわからないんですが、とにかく暗黙知みたいなものを過剰に増やすDRYは良くないよね、というような話なんです という@moriyoshitさんのツイート(1, 2)を見かけたので、僕の考え方をコメント。moriyoshitさんの考えたい問題とは、ずれてるかも。 DRY化の功罪とは何か? 僕の理解で言うと、共通するコード片をDRY化することには以下の変化をもたらす。 循環的複雑度は変化しない コールグラフは複雑化する モジュールをまたぐDRY化を行うと、モジュール間の依存関係も複雑化する*1 関数内の複

    DRY(don't repeat yourself)するかしないか、その判断基準について - kazuhoのメモ置き場
    shin1x1
    shin1x1 2014/02/21
    "関数内の複雑度の低下によるメリットが、コールグラフの複雑度の上昇によるデメリットを上回る場合のみ、DRY化を行う"