おしりんブログ

新人PGおしりんの色々まとめるよブログ

プロキシとピロシキの関係性

Git Proxy Maven

これいかに。
みなさんこんにちは。おしりんです。

最近現場に一人でいることが多いです。
一日を通して誰ともしゃべらないことがよくあります。

おしゃべり好きな私にとっては、まさに苦行。

というわけで、本日のお題はこちら。

プロキシサーバの監視を一時的に突破する

一時的に、です。一時的に。
しゃーなしなやつです。

それでは本題に入っていきたいと思います。

Gitでクローンができない！

そうなんです。題名の通りなんですけど、先日現場の社内ネットワークを経由して
外部サーバにおいてあるGitのリポジトリをクローンしようとしたら、出来ないんですよ。

わたし、普段自社からPCを持ちこんで仕事しているので、
現場のネットワーク制限とかあんまり気にしたことなかったんです。

でですね、クローンしようとした際に出たエラーがこちらです。

fatal: unable to access 'https://[クローンしたいGitリポジトリのURL]'
: Failed connect to　[リポジトリのあるサーバ名]:443; No error

で、このエラーを調べてみると、どうやらプロキシサーバが邪魔しているらしい！
ぷ、プロキシサーバってなんぞや！ということで…

プロキシサーバとは

インターネットに接続されているコンピュータの種類のひとつ。
Proxyは「代理」とか「代理人」という意味なので、代理サーバーと訳すこともある。

プロキシサーバーは通常、社内ネットワーク（LAN）と外部のインターネットの間に置かれる。
基本的な役割はデータの出入りを監視すること。

以下ページ抜粋▶▶Proxyサーバーとは

なるほどなるほど。
このサーバが社内から外部に出る際に「出ちゃダメだよ」と言っている訳ですな。

ということで、このサーバに「出してくれエエエ」と頼むことにしましょ！

プロキシサーバを調べる

プロキシサーバーのせいでクローン出来ないことはわかった。
それでは実際にプロキシサーバーの働きをしているのはどのサーバなのか！

IPを突き止めたいと思います。

調べる方法としては以下を追っていきまする。

  1. ブラウザの設定タブ
  2. ネットワーク
  3. プロキシ設定の変更
  4. 接続タブのLANの設定
自動構成スクリプトを使用するにチェックがしてある場合

アドレスにアクセス。
Javascriptで自動構成スクリプトが書かれているはず。

その中に

return "PROXY xxx.xxx.xxx.xxx:8080";

こんな感じで書いてあったら、そいつがプロキシサーバーじゃ！

LANにプロキシサーバーを利用するにチェックが入っている場合

アドレスとポート番号をφ(..)メモメモ

これで、プロキシサーバーのIPをつきとめたので、
Gitにこのプロキシ環境下を突破してくれるよう頑張ってもらいまする。

敵がわかればあとは攻めこむのみ！いざ！

プロキシ環境下でGitを使えるようにする

コマンドプロンプトを開いてーーGitコマンド使えることを確認！

あとはコマンド上でこれを叩くだけ。

$ git config --global http.proxy http://proxy.example.com:8080
$ git config --global http.proxy https://proxy.example.com:8080

もしくは.gitconfigに

[http]
proxy = http://proxy.example.com:8080
[https]
proxy = http://proxy.example.com:8080

と設定。
これで無事クローンできるようになりやした。

なにが大変だったって、どこがプロキシサーバーになってるのかを調べるところ。

今になって思うと、なんでこんなにつまづいたのかよく分からにゃい。
普通に調べれば色々出てくる。

ただその調べてた時は、自動構成スクリプトなんていうものがプロキシの設定をしているとか
全然思いつきもしなくて、結局先輩が調べてくれました。

まあひとまず一件落着したのでヨカッタヨカッタ。

おまけ：プロキシ環境下でMavenを使えるようにする

これ、会社の先輩がブログにまとめておりました。拝借。 ▶▶猫にWeb

ではでは。

Gitを「じっと」と読む人が職場にいるんですよぉ～

Git gradle

なぁーにー！やっちまったなぁー！

あ、落ちはありません。
みなさんこんにちは。おしりんです。

ということで？今回はがっつり自分用メモ。
プロジェクトをgit管理化する手順についてまとめるます。

プロジェクトのGit管理化手順

よく使用されるであろう

で管理するときの手順をまとめておく。

  1. Eclipseでローカルプロジェクト作成
  2. build.gradleを作成、プロジェクトに配置
  3. プロジェクトのディレクトリに移動し、git init でgitプロジェクト化
  4. GitもしくはBitBucketでリポジトリ作成
  5. ローカルのプロジェクトをリモートにadd
    【Git】git remote add origin https://github.com/ユーザ名/リポジトリ名.git
    【BitBucket】git remote add origin https://ユーザ名@bitbucket.org/ユーザ名/リポジトリ名.git
    git add -A
    git comit -m "first commit"
    git push origin master
  6. リモートからローカルにclone
    【Git】git clone git://github.com/ユーザ名/リポジトリ名.git
    【BitBucket】git clone https://ユーザ名@bitbucket.org/ユーザ名/リポジトリ名.git
  7. gradle eclipseを叩いてEclipseプロジェクト化
  8. Eclipseでプロジェクトをインポート

普段Eclipseを通してしかGitさわってないから、
こうたまにコマンドからあれこれしなきゃいけないってなるとめっちゃ迷う。

Gitの用語やら仕組みやらをしっかり抑えるためにも、
普段からコマンド使っていかなきゃなのかなとかね…思いますね…まる。

最後にわたしの素敵なパイセンが書いてくれたbuild.gradleを…
これほんと、毎回助けてもらってます…ありがとうございます(T人T）ﾅﾑﾅﾑ

apply plugin: 'java'
apply plugin: 'war'
apply plugin: 'eclipse-wtp'
apply plugin: 'findbugs'

sourceCompatibility = 1.7
version = '1.0'

repositories { mavenCentral() }

ext { defaultEncoding = 'UTF-8' }

dependencies {
    providedCompile 'javax:javaee-api:7.0'
    compile 'log4j:log4j:1.2.17'
    // testCompile 'org.hamcrest:hamcrest-all:1.3'
    // testCompile 'junit:junit-dep:4.11'
    // testCompile 'org.mockito:mockito-all:1.9.5'
}

tasks.withType(AbstractCompile).each {
    it.options.encoding = defaultEncoding
    it.options.debug = true
}

eclipse {
    project {
        name = project.name
        buildCommand 'org.eclipse.jdt.core.javabuilder'
        buildCommand 'edu.umd.cs.findbugs.plugin.eclipse.findbugsBuilder'

        natures 'org.springsource.ide.eclipse.gradle.core.nature',
                'org.eclipse.jdt.core.javanature',
                'org.eclipse.wst.jsdt.core.jsNature',
                'edu.umd.cs.findbugs.plugin.eclipse.findbugsNature'
    }

    classpath {
        downloadSources = true
        downloadJavadoc = true
    }
}

ありがとうございます(T人T）ﾅﾑﾅﾑ（２回目）
あー春が待ち遠しい。

テスト～Spring～その２

spring DBUnit

みなさんこんにちは、おしりんです。

私事ですが、先日２３歳になりました。
社会人になって初めての誕生日でした。

当日は朝から「誕生日なのに仕事…」とかブツブツ言ってました。

でもね、ほんと、誕生日って自分にとってはなんとなく特別な日だけど、
他人からしたら、別になんでもない日なんですよね。

あ、なんかひねくれたようなこと言ってますけど
嬉しい事に仕事おわりに美味しいご飯連れてってもらえたので、
結果的には( ´∀｀)bｸﾞｯ!な一日になりました。

そんなどうでもいい話から始まりましたが、
本日まとめるのはこちら。ででん。

JUnitを使用したSpringのテストについて第二弾！

前回の記事から続いているのでもしよかったらこちらもどうぞ。
テスト～Spring～

そんなわけで

第二弾ではあれです。
テストの中でDBにつないじゃいます。

コントローラークラスを実装する時、どうやってもDBにつながないことなんてないじゃないですか。
コントローラーの中でサービスクラスをAutoWiredしてDBにつなぐじゃないですか。

あれをMockを使わないでテストしちゃいます。

使用するのは、前回から引き続き

  • SpringJUnit4ClassRunner

と、こちら

この２つを組み合わせてテストを実装していきます。

＠Annotation

まずは@Annotationについて。
結構ごちゃごちゃとクラスにくっつけます。

  • @RunWith(SpringJUnit4ClassRunner.class)
  • @ContextConfiguration(locations = { "classpath:test-application-config.xml" })

ここまでは前回と同じ。
追加するのは次の３つ。

  • @TransactionConfiguration
  • @Transactional
  • @WebAppConfiguration

トランザクションの管理をしてくれる。
テスト用に更新したデータをロールバックしてくれたりとか。

一番下のは…ちょっとなんで付けたのか思い出せないんですけど、
これなかったら正常に動かなかったです。f:id:shiori_west:20150309191825p:plain

どこで見つけてきたんだっけなあ。（にじみ出るテキトー精神）

設定ファイルへの追記

前回の記事でも｜дﾟ)ﾁﾗｯと書いたけど
DBUnitを使用する場合は、データソースを上書く必要があります。

 <!-- もともとの設定 -->
    <bean id="dataSource" class="org.apache.commons.dbcp2.BasicDataSource">
        <property name="driverClassName" value="com.mysql.jdbc.Driver" />
        <property name="url" value="jdbc:mysql://127.0.0.1:3306/DB名" />
        <property name="username" value="root" />
        <property name="password" value="mysql" />
    </bean>

    <!-- 追加部分 -->
    <bean id="dataSourceTest"
        class="org.springframework.jdbc.datasource.TransactionAwareDataSourceProxy">
        <constructor-arg ref="dataSource"/>
    </bean>

とりあえずこんな感じ。

SpringとDBUnitを一緒に使うためのデータソースは
TransactionAwareDataSourceProxyじゃなきゃだめなのです。

理由はこちらのサイトで詳しく説明してくれてます。
ありがたやありがたや…

DBUnitへの対応

SpringのテストをDBUnitに対応させるには、以下のテストケースを継承させる。

  • DataSourceBasedDBTestCase

TestCase that uses a DataSourceDatabaseTester.
ということで、このクラスのメソッドをごちゃごちゃとオーバーライドして実装していきます。

さっそく実装していきまひょう。
の、前に。

このクラス、デフォルトのタイムゾーンが９時間ずれています。
GMT(世界標準時間)との時差を計算して、あえてずらしてあるらしいっす。（モヤさま風）

この時差を修正しないと、DBUnitを経由して日時のインサートやら更新やらをした際、
意図した時間と異なる時間が登録されてしまいます。

ということで、DataSourceBasedDBTestCaseクラスのラッパークラスを作成して、
その中でタイムゾーンを修正したいと思います。

public abstract class DataSourceBasedDBTestCaseWrapper extends DataSourceBasedDBTestCase {
    @Override
    protected void setUp() throws Exception {
        TimeZone t = TimeZone.getDefault();
        // dbunit modifies time incorrectly when timezone is not GMT.
        TimeZone.setDefault(TimeZone.getTimeZone("GMT"));
        databaseTester.onSetup();
        TimeZone.setDefault(t);

        super.setUp();
    }
}

参考▶▶山下寛人オフィシャルブログ
ありがとうございましたm(__)m

なので、テストクラスに継承させるのはDataSourceBasedDBTestCase.classではなく、
自作したDataSourceBasedDBTestCaseWrapper.classということになりまする。

テストデータの準備

引き続きDBUnitを使用するための準備です。
DBUnitについては詳しく説明しませんー。

今回はエクセルにテストデータを定義したいと思いまうす。
エクセルの他にもCSVやXML等にも定義できまうす。

こんな感じどん。

f:id:shiori_west:20150309191825p:plain

ファイル名は原則としては「テストケース名.xls」らしい？

S2JUnit4とかは「テストクラス名_メソッド名.xls」か「テストクラス名.xls」
この形じゃないと動かなかった気がする。

シートにテーブル名を定義して、一行目にカラムを定義する。
あとはテスト実行時に読み込みたいデータを追加していくだけ。

ファイルを作成する時の注意点としては、

  • 不必要なシートは削除する

くらいですかね。
不必要なシートが存在したままファイルを読み込むとエラーが発生するんですよ。

エクセル立ち上げた時にデフォルトで作成される「シート２」とか「シート３」とか
ついつい消し忘れてしまってよく怒られます。

ファイルはテストクラスから見えるところに置いて下さい。
私は今回src/test/resource上にxlsフォルダを作成し、その中に配備しました。

テストの実装

準備が整ったのでようのやくで実装していきますー。
１つ上の見出しでも書いたように、色々とオーバーライドしていきます。

とりあえずテスト対象のコントローラークラスどん。

かなりテキトーなおいにーが漂っていますが、
ログイン認証をしてくれるクラスだと思っていただければ…。

DBにユーザ情報が存在したらSUCCESSページに、失敗したらFAILページに遷移します。

@Controller
public class LoginController {

    @Autowired
    UserService userService;

    @RequestMapping(value="/login", method = RequestMethod.GET)
    public String login(Model model, Principal principal) {
        String id = principal.getName();
        UserInfo user = UserService.findById(id);

        String view;
        if (user != null) {
            view = "success";
        } else {
            view = "fail";
        }
        return view;
    }
}

つづいてテストどん。

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations = { "classpath:test-application-config.xml" })
@TransactionConfiguration
@Transactional
@WebAppConfiguration
public class LoginControllerTest extends DataSourceBasedDBTestCaseWrapper {

    private final String RESOURCE_PATH
        = Thread.currentThread().getContextClassLoader().getResource("").getPath();
    // テストケース名の取得
    private String testClassName = "xls/" + getClass().getSimpleName();

    @Autowired
    LoginController sut;

    // ①
    @Autowired
    private TransactionAwareDataSourceProxy dataSourceTest;

    // 使用するDBの設定
    @Override
    protected void setUpDatabaseConfig(DatabaseConfig config) {
        config.setProperty(DatabaseConfig.PROPERTY_DATATYPE_FACTORY, new MySqlDataTypeFactory());
    }

    // ①で定義したデータソースの取得
    @Override
    protected DataSource getDataSource() {
        return dataSourceTest;
    }

    // XlsDataSetのコンストラクタでエクセルファイルが置いてあるディレクトリを参照
    @Override
    protected IDataSet getDataSet() throws Exception {
        return new XlsDataSet(new File(RESOURCE_PATH + testClassName + ".xls"));
    }

    // 親クラスのSetUpメソッドの呼び出し
    @Before
    public void setUp() throws Exception {
        super.setUp();
    }

    @Test
    public void ログイン成功の場合はSUCCESSページのVIEW名を返却() {
        // modelとprincipalのセットアップは省略
        String actual = sut.login(model, principal);
        String expected = "success";

        assertThat(actual, is(expected));
    }
}

テスト対象クラス自体をAutoWiredするって自分では思いつかないなあ。

DB接続の部分をMockを使わないでかけるから
より本番に則したテストができるのですねん。（たぶん）

今回はDBのデータを参照することしかしてないけど
インサートとか更新、削除がからんでくるとトランザクションに気をつけなきゃだったり…

インサートや更新時のテストも時間ある時においおいのっけていきたいです。

それではでは。おしまい！