しごとのはなし

web関連の仕事の話をメモ的に。

VPSを借りてしたこと

毎度思いつきのブログ更新失礼いたします。

格安のVPSを見つけたのでごにょごにょとやってみた。サーバ管理について忘れそうなのでメモしておく。

logwatch入れて毎日メールが来るのが楽しみです。

今日はEXIMが600件以上の同一アドレスからのエラーを報告したので一応検索してみた。

---

 2016-04-27 00:30:25 dovecot_login authenticator failed for (win-ncii0p3s2ha.domain) [185.103.253.217]: 535 Incorrect authentication data (set_id=admin@time4vps.eu): 1 Time(s)

---

 

以下を見る限りこんなipはとっとと弾いちゃいなさい、ということのようなので

http://www.inmotionhosting.com/support/email/bounceback-errors/535-incorrect-authentication

iptablesを更新しておく。

http://www.cyberciti.biz/faq/how-do-i-block-an-ip-on-my-linux-server/

こんな感じでbashにしておけばいいかな。保存。

#!/usr/bin/bash

 

sudo iptables -A INPUT -s $1 -j DROP

sudo service iptables save

 

Wordpressのthemeをテストする、準備編

お久しブリ大根、美味しい季節になってきましたね。

1. 前置き

ここ5年、wordpressのテーマ作りをよく手がけていたのですが、環境が随分と良くなったように思います。大っ嫌いなCSSJavascriptは、lessもしくはstylus、coffeescriptなんかでかなり楽ができる。HMTLやPHPもjadeもしくはjadephpなんかでかなり簡潔に書けるようになってきた。gruntでここら辺の設定をまとめておけば仕事量は半分ぐらいになっているような気がします。関数仕様も随分と頭に入り、経験も積み上がったので仕事のスピードは5年前に比べたら、控えめに言っても2.5−3倍は確実に早くなった気がする。

で、上記のテーマについては、つぎはぎ合わせばなんとか日本語のリソースもありそうなので、とりあえず気が向いたら書くとして、今回はWordpressのthemeのテスト、について書こうと思います。といってもまだ始めたばかり、そしてtest firstで育ってきていない世代なので、かなり腰が思い。本稿は自分に鞭を打つため、そして備忘録として書き記します。例によって書ききれるかわからないけど。

 

2. 前提

以下の経験があることを前提とします。

  • 自分でwordpressのテーマが作れる
  • 自動テストについての知識はなんとなくある
  • Composerは使ったことぐらいある。

(思い出したら随時追加します。)

 

3.リソース

だいたい以下が元ネタです。

Unit Testing Themes and Plugins in WordPress | INN News Nerds

Automated Testing in WordPress, Really?!

The Beginner’s Guide to Unit Testing: Building Testable Themes - Tuts+ Code Article

 

つづく。

gitのリモートブランチに自分のブランチをpushしたよ、というはなし

今度のプロジェクトでお恥ずかしながら初めて本格的なgit運用。正直言うと、ブランチ切って修正+master にmergeとかrebaseとかすらしたことなかった...(照

 

そういうわけで備忘録として今までやったことなかったことをメモしていくシリーズです。

 

要求

リモートにfeature/witty-testブランチを作ってもらったので、自分のテストコードのブランチtest-with-wkをpushしたい

 

やったこと

とりあえず、リモートブランチに自分のブランチをpushする書式は

git push (remote) (my-branch):(remote-branch)

 なので

$ git push origin test-with-wk:feature/witty-test

とやってみたところ

To https://myreposerver.com/git/our-project/

 ! [rejected]        test-with-wk -> feature/witty-test (non-fast-forward)

error: failed to push some refs to

'https://myreposerver.com/git/our-project/'

hint: Updates were rejected because a pushed branch tip is behind its remote

hint: counterpart. Check out this branch and integrate the remote changes

hint: (e.g. 'git pull ...') before pushing again.

hint: See the 'Note about fast-forwards' in 'git push --help' for details. 

と怒られた。

どうやらリモートブランチは自分のブランチと別の親だったらしいので、親を一致させるためにマージが必要みたいだった。なので自分のブランチにリモートブランチの状態をアップデート。

$ git fetch origin (<-ちょっとあやしい)  

 

 

でリモートリポジトリoriginの状態を取得。これをtest-with-wkブランチに反映させたいので

$ git checkout test-with-wk

$ git merge origin/feature/witty-test

として、test-with-wkの親とfeature/witty-testの親を一致させる。そしてもう一度

$ git push origin test-with-wk:feature/witty-test

を実行したところ

Counting objects: 1586, done.

Delta compression using up to 4 threads.

Compressing objects: 100% (1542/1542), done.

Writing objects: 100% (1580/1580), 3.71 MiB | 428.00 KiB/s, done.

Total 1580 (delta 262), reused 0 (delta 0)

remote: Scanning pack: 100% (1580/1580), done.

remote: Storing objects: 100% (1580/1580), done.

remote: Processing commits: 100% (2/2), done.

To https://myreposerver.com/git/our-project/

   ed5655e..fc87037  test-with-wk -> feature/witty-test 

で成功! 

 

git svnとbranchのはなし

で、諸事情により(というか必要がなくなったので)前回の予告は達成されていないのですが、今日は全く別の話。

 

目標:

SVNリポジトリをgitでチェックアウトして、trunk/branchそれぞれで作業したい。

あわよくば、git-new-workdirで別個の作業ディレクトリを確保したい。

# おそらく、だけど、これをやるとbranchをまたがった

# git cherry-pick が非常にやりやすそう。

 

で、gglってもこんな記事しか出てこない。直接ひょっとするとあんまりお勧めできないうんようなのだろうか?? まあでも以下のように作業したら、なんとなく出来た様なので、とりあえずめでたい記念にメモ。

http://stackoverflow.com/questions/9596412/how-do-i-remove-a-working-copy-created-via-git-new-workdir-without-hosing-the-or

 

 

0.前提 

 

svnリポジトリは、http://somewhere/svn-repositoriesこのリポジトリには{trunk,branches,tags}と標準レイアウトである。またsvnリポジトリにはすでにbranchがある事を前提とする(無ければ自分で作ってね ;)。

 

 

 

somewhere/working_dirをメインの作業ディレクトリとする。gitでいうところのmaster, svnでいうところのtrunk。

 

作業結果の確認にはsvnリポジトリを直接ブラウズ出来る様な仕組み(今回はUSVN)で確認しました。

 

 

1.標準レイアウト{trunk,branches,tags}のSVNリポジトリをgit svnでチェックアウト

参考: http://transitive.info/article/git/command/svn/

$ cd somewhere/working_dir

$ git svn clone -s http://somewhere/svn-repositories

 

 # -sが標準レイアウトをそのままgitに適用してくれる

 

2. svnのbranchで作業できるかを確認

参考: http://sessan.hatenablog.com/entry/2012/11/04/132746

 

branchの確認

$ git branch -a

* master

  remotes/origin/master

  remotes/origin/other_branch

 

 

svnのbranchを git のbranch 'my_branch'としてチェックアウト

$ git co -b my_branch remotes/other_branch

:

do something

:

$ git commit -a -m "done something"

$ git svn dcommit

 

 

するとsvnのother_branchのみ"do somethingな"変更を確認できた。

 

 

3. git-new-workdirでbranchのコピーを別ディレクトリにつくる

2の手順でローカルにremotes/other_dirのbranch,"my_branch"ができたので、これを利用する事が出来そうだ。my_branch用のディレクトリをother_dirとしようか。

$ git-new-workdir . ../other_dir my_branch

$ cd ../other_dir

:

do something

:

$ git commit -a -m "done something part2"

$ git svn dcommit

 

 

するとsvnのother_branchのみ"do somethingな"変更を確認できた!

 元のディレクトリに戻って、master (trunk) で作業してみる

$cd ../working_dir

$ git co master

:

do something on master

:

$ git commit -a -m "done something on working_dir"

$ git svn dcommit

 

 

するとsvnのtrunkのみ"do something on working_dir"な変更を確認できた!

 

 

これでなんとか楽に運用できそう!!

codeceptionことはじめ、その2

で、QuickStartは終わったので、もう少し実用的な事を、と思うんだけど、とりあえず本日はここまでね。この先調査が進んだらまた書くってことで。

 

 

で、今のところ以下をやっておきたい、と思っている。

  • bootstrapでのテスト環境構築の自動化
  • カスタムアサートの作成

とりあえずテストの範囲もまだまだ小さいので、テスト環境構築の自動化は後にしようと思う。

 

 

で、$I->seeNoEvil();とかカスタムアサートを書きたい訳ですよ。

そもそもの混乱は以下に書いてある事と(v1.6.3ベースの)実際の挙動がちょっと違う、所から始まる。

http://codeception.com/docs/03-ModulesAndHelpers

 

Codeception doesn't restrict you to only the modules from the main repository. No doubt your project might need your own actions added to the test suite. By running the bootstrap command, Codeception generates three dummy modules for you, one for each of the newly created suites. These custom modules are called 'Helpers', and they can be found in the tests/helperspath.

 tests/helpersってないじゃん!!

 tests/_helpersじゃん!!

ぐらいで終われば良かったんだけど、そうは問屋が卸さなかった。

とりあえず、tests/_helpers/WebHelper.php

 

 

<?php
function seeNoEvil() { $this->assertTrue(true); } ?>

 

って書いて、Cept.phpの方に

 

 

<?php
$I = new WebGuy($scenario); :
$I->seeNoEvil();
?>

とか書くじゃないですか、そうすると

$ php codecept.phar run acceptance

 

でテストを走らせると

Suite acceptance started
Trying to see no evil (WelcomeCept.php) - Error
Time: 10 seconds, Memory: 13.75Mb There was 1 error: --------- 1) Couldn't see no evil in WelcomeCept.php RuntimeException: Call to undefined method WebGuy::seeNoEvil

 っておこられちゃう。

ここでオイラは2-3時間ぐらいかなりの泥沼に入るんだけど、結論としては、

$ php codecept.phar build

 で、解決。bootstrapで出来たWebGuiさんはSelenium用じゃなくてPhpbrowser向けだし、いずれかのタイミングで必要だった、という事みたいです。

 

以上、 今日はここまで。次回はseeNoEvilの中身を書きたいと思うよ。

codeceptionことはじめ、その1

漸くここの仕事場でも、テスト自動化を導入できそうな余裕と論調(ここ大事)が形成されたので先走りつつも色々試している。とりあえず今日の成果。

#執筆時点でのcodeceptionは1.6.3 

 

まずは、Quickstartに従って...

1. Download + 2. install

wget http://codeception.com/codecept.phar

php codecept.phar bootstrap

これで、tests/ ディレクトリが作成され、テストを作成する準備ができる

 

3. Create Test

php codecept.phar generate:cept acceptance Welcome

で、WelcomeCept.phpというひな形がtests/acceptanceに作成されるのでそこにゴリゴリとテストを書いていけばよさそう。

ちなみに、1ファイルが1 Testという扱いで、SeleniumのプロセスもTestの数だけ立ち上がるみたい。(この辺はどう運用すべきか要調査...)

 

4. Write Basic Test

$I = new WebGuy($scenario);
$I->wantTo('ensure that frontpage works');
$I->amOnPage('/'); 
$I->see('Home');

# ゴメンね、とりあえず本家のコピペに解説を加える程度だよ...

まずはWebGuyのインスタンスを作成。

で、何をしたいか、とコメント的にwantToメソッド呼び出し。

そして、amOnPageで開く場所を指定、だね。

で、Home、が見えているか、というテスト。

なんとも見たままのシナリオをコードに落とせる。

ちなみに、これをそのままtextに変換できるけど、その件についてはまた別途。

 

5. Configure Acceptance Tests

で設定ファイルtests/acceptance.suite.ymlを編集。

 

class_name: WebGuy 
modules: 
    enabled: 
- Selenium2 - WebHelper config: Selenium2: browser: "safari" url: 'http://localhost/yourapp/' delay: 1000

本文ではPhpBrowserと書いてあるんだけど、javascriptのインタラクションもテストしたいので、ここは一気にSelenium2+Safariにしておく。とりあえずロードの時間を考慮して1秒づつ実行(delay:1000)という事にしておく。

 

 

6. Run!

 

でいよいよ実行。ターミナルから

 

php codecept.phar run

で、こんな結果が返ってくるんじゃないかと思います。

Suite acceptance started 
Trying to ensure that frontpage works (WelcomeCept.php) - Ok
Suite functional started
Suite unit started

Time: 1 second, Memory: 21.00Mb
OK (1 test, 1 assertions)

ここまで割と順調に行ったもんだから、使ってみようと思ったんだけど(Behatはここまでたどり着かなかった...orz)問題はここからだったんだよ。

 

その2に続く。

 

 

 

いろいろ、ことはじめ

今年3月より新しい仕事についた。

で、新しく学ぶ事が色々と多い。主にweb関連の技術。そしてコミュニケーションの方法等。忘れてしまいそうなので、とりあえずメモ程度には書いておきたい。