好きなアニメについて書いてみたらとアドバイスを受けたので

一挙に軽い話題

今期はまだアニメ見ていない気がする。 書き出してみたら、作品数はそこそこだけど、続きを見れてないのが大半である。

年末にデレマス、正月にFGOを始めて、艦これの備蓄を再開したため、そっちに時間取られているのが大きい。 また、今期は、学園恋愛もの増えた印象だったのも影響してる気がする。

セイレン

二話のみ視聴。実に紳士だと友達と話しながら見るのがいい。

あやねるが恋愛もののヒロインやるの新鮮な気がする(たぶん全然そんなことはないはずなのだが。) 「デース」で笑ってしまった。

うらら

きらら枠 卓球娘楽しかったので、中の人つながりでうらら観てる。opがなんかもにょもにょする。 セイレンの紳士ネタは楽しめるのに、こちらのお腹推しはどうも乗り切れないのはなんでだろう。 かやのんのキャラがアリシアさんっぽいのだが、意識してるのかな。

メイドラゴン

卓球娘つながりその2。

政宗くんのリベンジ

小十郎くんかわいいですな。

このすば2

まだ見れてない。

信長の忍び

前期スルーしてたけど、テンポ良くて面白い。 opは前期のほうが好きだな。

書き出してみて

アニメ観るの好きな割に、(小並感)ってつけたくなる文しかでてこない。 話数ごとのレビューみたいなのが書けたらよかったのだけど。

箇条書きメモ以上に長い文章を書けないので練習を始める

とにかく文章を書くのが苦手だ。読ませるとか、わかりやすいとか以前に、絶対的な量が足りない。 1つの段落あたり3文以上つけるのが苦痛で、日々の技術文章ですら出来上がる頃に定時近くになっている。

自分が書きたいテーマについて、内容はともかく、2~3時間以内にそれなりの量を生成できるようになりたいと思う。

手始めに、正月あたりからtwitterでつぶやくのを再開した。短い文ならいけるやろという安直な理由。 ずっと書いてないと1行つぶやくのすらつらくて結構へこんだ。 2週間ぐらいしたら、1日2~3ツイートぐらいなら大丈夫になってきてる。 そろそろ次の段階に進みたい。

何が原因なのか列挙してみる

今まで苦手ななりに、メジャーな文章術は読んだし、たくさん本を読みましょうみたいなアドバイスは一通り試した(と思っている)

それなりに本は読んできたから、書こうと思っている分量にたいして、情報のインプットが足りていないということはなさそう。どちらかというと、引用だらけになって、自分の主張がなくて詰むことが多い。

箇条書きはできるのだから、論理構成を考えるのが壊滅的にだめってことはないと思っている。(この文章はめちゃくちゃだが。。。)

筋を書いて肉付けしている力尽きるというか。

いろいろ悩んできた末に、ひとつ仮説があって、小さい頃に「難しい言葉を使うな。簡単な言葉で説明しなさい」言われたというのが結構ボトルネックになっている気がする。

たとえば、↑の文章を書き出す時に、「衒学な文章」という言葉が思い浮かんだけど、それを「難しい言葉」と脳内で置き換えてからタイピングしている。実際の読み手が衒学という言葉を理解しないとは思ってないが、すべての熟語やカタカナ語に対してこの処理にリソースが割かれているとすると、結構負担になっているのではないか。

大人の話に首を突っ込んで生意気だと怒られる年齢でもないし、難解な語彙を使いこなせるから偉いみたいに思ってるわけでもない。とにかく考えたことがスムーズにでてくれば、形式は問わないわけで、鼻につくところは書いてから直せばいいやぐらいに思ってやっていくことにする。

ここまで書いて力尽きた。。。

Windows7+Cygwinな環境からvagrant-aws使ってみた。

経緯

DockerとかAlminiumとか試したいものがいろいろあるのだけど、たいだい64bit版OSでないと入らなくなってきてる。 自宅のPCは一応64bitマシンなのだけど、vt-xが有効にできないため、仮想環境で64bitOS使えない

なるべくお金かけずに出来ないかなと考えた末 昨年もらったAWSの無料利用枠の期限が迫ってきてるのを思い出したので、使ってみることに。

やり方

naoyaさんの記事を参考に

Vagrant 1.1 で EC2 を vagrant up - naoyaのはてなダイアリー

Vagrantの公式サイトからwin版を落としてきてインストール

# awsプラグイン
$ vagrant.bat plugin install vagrant-aws
# 適当にディレクトリを切って移動
$ mkdir -p ~/work/aws && cd ~/work/aws

$ vagrant box add dummy https://github.com/mitchellh/vagrant-aws/raw/master/dummy.box
$ vagrant.bat init
$ emacs Vagrantfile

バージョンアップしてVagrantfileの鍵の指定方法が微妙に変わってたのでこちらを参考に修正 vagrant 1.2を使ってみる - Qiita

# -*- mode: ruby -*-
# vi: set ft=ruby :

# Vagrantfile API/syntax version. Don't touch unless you know what you're doing!
VAGRANTFILE_API_VERSION = "2"

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
  # All Vagrant configuration is done here. The most common configuration
  # options are documented and commented below. For a complete reference,
  # please see the online documentation at vagrantup.com.

  # Every Vagrant virtual environment requires a box to build off of.
  config.vm.box = "dummy"

  config.vm.provider :aws do |aws, override|
    aws.access_key_id     = ENV['AWS_ACCESS_KEY_ID'] 
    aws.secret_access_key = ENV['AWS_SECRET_ACCESS_KEY']
    aws.keypair_name = "ec21" #先にWeb上でKeyPairを生成するか、インポートしておく必要あり

    aws.ami = "ami-0d13700c"
    aws.availability_zone = "ap-northeast-1a"
    aws.region = "ap-northeast-1"
    aws.security_groups = ['test'] #先にWeb上でセキュリティグループを設定する必要(sshのポートあけないと繋げない)
    aws.instance_type = "t1.micro"

    # ログインユーザーと秘密鍵の指定部分
    override.ssh.username = "ec2-user"
    override.ssh.private_key_path = "~/.ssh/ec21.pem"
  end
end

アクセスキーを環境変数に設定するスクリプト

env.sh

#!/bin/bash
export AWS_ACCESS_KEY_ID=<アクセスキーID>
export AWS_SECRET_ACCESS_KEY=<シークレットアクセスキー>

加えて、cygwin環境だとvagrant upの最期に共有ディレクリをつくろうとしてエラーがでる。 sudoerの中で、requirettyされてるため

vagrant-awsを使う際はuser_dataを設定してみよう - akadama vagrant-awsでmkdir -p /vagrantで失敗する - あんこの成長記録

強引だけど適当にソースいじってmkdirしないようにしてしまった。

$ emacs ~/.vagrant.d/gems/gems/vagrant-aws-0.4.1/lib/vagrant-aws/action/sync_folders.rb 

 50            # on windows rsync.exe requires cygdrive-style paths
 51            if Vagrant::Util::Platform.windows?
 52              hostpath = hostpath.gsub(/^(\w):/) { "/cygdrive/#{$1}" }
+ 53              return

実行

$ sh env.sh
# 立ち上げ
$vagrant.bat up --provider=aws

# 接続
$vagrant.bat ssh

# 止める(インスタンスを消すとき) cygwinからだと--forceをつけないととまらないっぽい
$vagrant.bat destroy --force
 

cygwinだと、vagrant upでなくvagrant.bat upを実行しないと証明書関連のエラーがでる。

An error occurred while executing multiple actions in parallel.
Any errors that occurred are shown below.

An unexpected error ocurred when executing the action on the
'default' machine. Please report this as a bug:

Unable to verify certificate, please set `Excon.defaults[:ssl_ca_path] = path_to
_certs`, `ENV['SSL_CERT_DIR'] = path_to_certs`, `Excon.defaults[:ssl_ca_file] =
path_to_file`, `ENV['SSL_CERT_FILE'] = path_to_file` or `Excon.defaults[:ssl_ver
ify_peer] = false` (less secure).

C:/Users/malmrashede/.vagrant.d/gems/gems/excon-0.28.0/lib/excon/ssl_socket.rb:76:i
n `connect'
C:/Users/malmrashede/.vagrant.d/gems/gems/excon-0.28.0/lib/excon/ssl_socket.rb:76:i
n `initialize'
C:/Users/malmrashede/.vagrant.d/gems/gems/excon-0.28.0/lib/excon/connection.rb:373:
in `new'
C:/Users/malmrashede/.vagrant.d/gems/gems/excon-0.28.0/lib/excon/connection.rb:373:
in `socket'
C:/Users/malmrashede/.vagrant.d/gems/gems/excon-0.28.0/lib/excon/connection.rb:122:
in `request_call'
(略)

感想

週に2~3時間起動する程度だったらVPS借りるより安くすみそう。 $0.020 /1 時間だから 1ドル=100円 1ヶ月5週として 0.020 * 3 * 5 = 3ドル 300円程度

ServersMan@VPS(490円/月)

digitalOceanも気になる。 徳丸浩の雑記帳: 試験環境用VPSとして1時間1円から使えるDigitalOceanが安くて便利

絶対パスでrequire_onceしているクラスをなんとかテストする

状況

パフォーマンス最適化でrequire_onceのパス指定を絶対パスにしている場合、 phpUnitでテストする際に呼び出しにくい。

指定先にファイルを置くのが自然だけど、sudo権限持ってないと置けないパスだったり、修正のたびに配置し直す必要があったり意外と面倒。

そこで、強引だがテスト前に外部コマンドでrequire_onceをコメントアウトすることにした。 これで、tmp以下のファイルをrequire_onceすれば、元のクラスを呼び出すこともできるし、テストダブルを差し込むことも可能になる。

サンプル

絶対パスでrequire_onceしているクラスをなんとかテストする

参考

自動テストがない状態から、受け入れテストを書くとき何書いたらいいのかメモ

自動テストがない時

→受け入れテストから始めるのがセオリーらしい(ATDDとか)

しかし、受け入れテストで何書いたらいいのかが意外とちゃんと書かれてない印象。

 

 

受け入れテストで、あまりページの要素を細かくチェックすると壊れやすくなる+スローテストになる。

  • うまく単体テスト側でカバーしましょうとなっているけど、その単体テストがない。。。卵が先かニワトリが先か

 

使用するテストツール

  • WebAPIだったらxUnitとかrspecとかそういうの
  • ページだったら、selenium、capybara

 

 

最初のチェック項目

まずは、薄く広く網をかける。

  • アクセスするとページが返ってくるか確認
  • ステータスコード
  • (可能であれば手動の画面チェックリストでチェックしている項目をコードに落としていく)

 

気軽に書いて、捨てる(この辺りは我流)

  • 要素をチェックする部分は壊れやすいが、短期間であればそこそこ役立つ
  • (画面仕様はそこまで変わらないけど、テストデータを毎回整えるのが意外と難易度高い)
  • 動かなくなったら、割りきってその部分は捨ててしまう。

 

参考

あーありがち - 実はCapybaraってよく分からないんです

レガシーなコードもたくさんあるのでそういうときにせめて外からテスト揃えておくと安心だよねぇと調べてから思ったけど、それって

Rails での spec:requests にも同じことが言えるんじゃ?

と思い始めた。今まで request を元に内部で分岐する部分のテスト以外は真面目に書いてなかったけど、

単にちゃんとページが返ってくる

ことを spec でガードしておくのも大事だなと急に思い直した。初期の頃にはほとんど意味を感じない spec だけど、ある程度複雑になってきたときに予想していなかったところに影響が出てしまったことを素早く検知するために、

「ページが表示されて当たり前じゃん」と思っていても spec:requests は書いておいた方がいい

 

xUnitのルーツから考えると、サンプルコードを書くことから始めるのがよさそう

挫折しないための自分用メモ

 

 

アジャイル開発とTDDを半年間実践してみた顛末と、これから

0-9, TDDの準備としてのサンプルコードテストのすすめ

 

テスト駆動開発ハンズオン後編

 

xUnitのオリジナルはSUnitで、原作者のケント・ベック氏はインタビューでこう答えている。

『JUnit の歴史とテスティングの未来(Kent Beckインタビュー)』を訳します。:An Agile Way:ITmedia オルタナティブ・ブログ

Kent: ぼくの職業プログラマとしての最初は、Smalltalkだった。Smalltakはテスティングの習慣がある。ちょっとプログラムを変更したら、ちょっと動かしてみる。というインクリメンタルなサイクルを回す。でも、それは自動化されていなかった。以前コンサルタントとして開発プロジェクトに助言を求められたときに、自動テストを書いてみるようにすすめたかったが、やり方がなかった。Smalltak でやっていることの構造を、そのままオブジェクトモデルにそのまま実装したらどうなるか考えた。Workspaceがクラスで、変数がインスタンス変数、テストしたいコード片がメソッド。これは、ナイーブなマッピングだ。そこで、マニュアルでテスティングしている部分、すなわち、プリントアウトして期待される結果と比較することを、「じゃあ、ここはコンピュータにやってもらおう」と考えた。これが、assertionの原型。ここまでが、アーキテクチャの起源だ。いつごろだったかな、うーん、1992かな。これが最初のユニットテストフレームワーク

 

ワークスペースとは、Smalltalk環境におけるターミナル画面(+エディタ)のような物。

 

加えてSmalltalkにはサンプル用のコードをクラスにつける習慣がある

(メソッド分類におけるexamplesカテゴリの存在)

 

Pharo(Smalltalkの実装のひとつ)マニュアルより

PharoByExample-japanese/SUnit/SUnit.tex at master · SquareBracketAssociates/PharoByExample-japanese · GitHub

 

\st コミュニティは、長らくテストを重視してきました。\st のプログラミング環境ではインクリメンタルな開発が容易だからです。
\st の伝統的な開発では、プログラマはメソッドを実装するとすぐにワークスペースでテストします。
メソッドのコメントにテストを書いたり、セットアップが必要なテストはサンプルメソッドとして実装したりする場合もあります。
しかしこれらの方法には問題があります。まずワークスペースにテストを書いた場合(イメージファイルを共有しない限り)他のプログラマから使えません。
コメントやサンプルメソッドにした場合、状況は多少改善されますが
それでも、メソッドの開発に合わせてテストを見直し、さらに自動的に実行させるのは簡単ではありません。