再現テストの話

テストコードで再現テストをしてから、bugfixするやつ。

不具合にテストを書いて立ち向かう - t-wadaのブログ

これうまく行ったら超気持ちいいけど、いつも気持ちいいとは限らないのでメモ。

バグのパターンがユニットテストとしてエッジすぎ

だいたい再現テストコードがエッジなパターンすぎて、
仕様を説明する助けとして不適切になってしまう。

describe 'somemethod' do
  subject { describe_class.new(params).somemethod }
  context 'A' do
   let(:params) { 'a' }
   it { is_expected.to eq ('A') }
  end

  context 'B' do
   let(:params) { 'b' }
   it { is_expected.to eq ('B') }
  end

  # 再現テストのコンテキストがハイコンテキスト
  context 'B and hogehogehoe' do
   let(:params) { 'a' }
   before do
     # ハイコンテキストな記述 
   end

   it { is_expected.to eq ('A') }
  end
end

↑この程度なら全然いいんだけど野生のコードはこんなのじゃすまない。

このままマスターに入れてマージすると、仕様を説明することを阻害するよなぁ的に。

しかし、マージしておかないと同じバグを繰り返すかもしれないので、対策としてそのハイコンテキストなテストを別ファイルに切り出したりしてる。

コンテキストやフィクチャでテストのファイル分ける

1つクラスに1つのテストファイルがデフォルトですが、
テストファイルがって大きくなってきたら、コンテキストやフィクスチャ、メソッド単位でテストファイルを分割しても問題ないわけです。

なので、コンテキストが揃わないケースでは、別ファイルにコンテキストを分けてしまう。

そうすれば、仕様のキャッチアップにはよりプリミティブな浅いコンテキストのテストケースを読めるようにしておく。

そして再現テストは別ファイルで自動テストされるようにしておく。

というわけです。

なんかうまくいかない時に選ぶ他の手段

その他にもこのケースには下記の対応方法があるけど、場合によってはこれらも選んじゃう。

まとめ

基本的にバグに対して再現テストを書いて立ち向かって見てるけど、、、、
書きあがったテストコードがぐちゃぐちゃしちゃうのが悩み。

ぐちゃぐちゃでもいいから、別ファイルにテストコードを分けてコミットして再現テスト -> 修正すると良さそう。

そのやり方も万能じゃない。

そもそも再現テスト書いて、不具合に立ち向かうのをサボりたくなるときもある。

ブログを独自のCMSに移行しました

ブログ移管した

ブログを jekyll + github pages での運用から、独自のCMS(heroku + rails)に移行しました。

移管した理由

オンラインからサクッと編集したい

記事の雛形は make post みたいなコマンドを書いて、サクッと記事を書き始められるようにしてはいたのだけれども、、、
ちょっとした修正を出先や移動時間にするのにgithubに接続してブラウザから修正することにイライラしており、サクッと編集できるものが欲しかった。

jekyll疲れ

jekyllのプラグインとか拡張とかに限界を感じていた。

GitHub離れ

買収が発表される前から検討していたので、半分冗談ですが、移管完成がこのタイミングになったのはこれもある。
blogはコミットを外に公開したくなかったので、privateリポジトリで運用していましたが、
microsoft買収により自分が課金する必要もないかなと思いました。

このお金はherokuに払っていくぞ!頑張れheroku!

(あといくつかのprivateリポをgitlabかbitbucketに移管すれば、コスト削減も同時に達成できます。ありがとうmicrosoft。)

移管先の検討

wordpress

ブログサービス系 (medium/note/qiita/はてな/livedoor/line)

この辺りのツールはスマホからも修正がかなり簡単で圧倒的に使いやすいのです。
が、当たり前ですが融通が効かない点も多いので、断念しました。

自作

rails + herokuで自作しました

railsは自分のライスワークでありながら、ライクワークなので、
ブログを書きたくない時も、railsを書いてインプットができるのは良さそうと思いました。
あと、railsはブログみたいなツール作るのに向いてるんですよね。

以下、有益になるかもしれないことです。

markdownで記述は html-pipeline 周りでサクッと対応

html-pipeline というgemを使うとmarkdownをhtmlに変換するのは簡単です。
独自に拡張したい時もfilterをサクッと書くことができて最高です。

https://github.com/jch/html-pipeline

パーマリンクをそのまま移管

railsでブログ記事というとURLが /articles/1 みたいになりそうですが、
パーマリンクを過去の記事のまま移管する方法に rails engineを使用しました。
記事公開するためだけの rails engine を作り完全にroutesを分離し、それによりパーマリンクのためだけの一つのroutesを実現しました。

main appの config/routes.rb に下記を記述します。

  constraints(-> 'koheisg.dreamin.cc'.eql?(req.host)) do
    mount SomeEngine::Engine => "/"
  end

そして、SomeEngineのroutes、つまり some_engine/config/routes.rb

get '/:permalink', to: 'articles#show', permalink: /[^\s]+/

と記述しました。

今後について

という感じで考えてます。

koheisgがどうやってプログラミングを身につけたか? - CGI編 -

前回 に続いてどうやってプログラミング覚えたか?シリーズです。
こうしてHTML/CSSをなんとなく覚えた私ですが、次は動的なサイトを作りたくなっていきます。

geocitiesからxreaの移行

geocitiesではhtml/css/javascriptは満足に動きますが、サイトを訪れた人が掲示板などサーバー上で動作するプログラムを置くことはできませんでした。

当時、ホームページを個人で運営している人は二つのいずれかの方法で、掲示板を運営していました。

前者は会員登録をすれば誰でも簡単に自分のサイト専用の掲示板を持てます。
後者はCGIの知識が多少必要とされますが、CGIスクリプトは配布されているものを使用すれば、動かすだけであれば、プログラミング自体の知識は必要ではありませんでした。

今でいうと、blogを始めるときにライブドアブログやアメブロを使うのか?wordpressやmovabletypeを使うのか?みたいな違いです。
wordpressを使えば様々なデザインや動きもカスタマイズできますが、ライブドアブログやアメブロではそこまでできません。

自分はカスタマイズも想定して、CGIが動くxreaと言うレンタルサーバーに自分のサイトを移管しました。

無料スクリプトをアップする

xreaにサイトを移管してから、配布されてるCGIスクリプトをサーバーで動かしました。
配布されているCGIスクリプトは、それぞれ微妙に設定の仕方が異なっており、動いたり動かなかったり悪戦苦闘をしました。

CGIスクリプトの提供者側で用意してくれている設定に慣れてくると、自分でも動作をカスタマイズしたくなってきました。
wordpressでいうとプラグインの改造くらいの難易度だと思えば良いと思います。

改造がしやすいCGIスクリプト

色々なCGIスクリプトを改造するようになってきたところで、改造することを前提として配布されているCGIスクリプトを見つけました。
HTML部分とperlで書かれたロジック部分が完全に分離しているスクリプトです。

これを使うと当時の自分のようにHTMLしか理解していない人でも掲示板の見た目をカスタムできます。

ブラウザから日記を投稿できるサイトにした

僕はテーブルレイアウトを卒業し、 <div class='diary'>ここに日記の文章を書く</div> みたいな感じで自分のホームページを更新していました。

この頃、はてなダイアリーが流行り初めていて、はてなダイアリーで日記を更新する人たちが増えてきました。その他にも日記専用のサービスみたいなものが乱立していました。

自分の掲示板を改造する力を利用して、自分だけの日記サイトを動的に作ることができるのでは?
と思い始めました。

そして公開されているperlスクリプトを改変して、自分でゼロからデザインした日記サイトを作ることに成功しました。
とても長くの時間かかってやりましたが、更新が楽になって最高に嬉しかったのを覚えています。

この頃の自分のスキルレベル

perlの文法はほとんど理解していなかったと記憶しています。
変数の代入やifやforは理解していないと改造できなかったのですが、基本的に感覚で「ここを動かしたらどうなる?」ってのを繰り返していました。
(このレベルから、現在プロのプログラマとして、プログラムを書く力に変換していくにはかなりの時間がかかったように思います。この頃perlの入門書を一つぐらい読んでいれば変わったかもしれません。)

プログラムを書くことよりも動かすことに興味があったので、ローカルでperlを動かしたり、Windowsを自家サーバとして公開しようとしました(公開しなくて良かった)ので、この頃にサーバーとはなんたるかの超初歩は理解してた気もします。

koheisgがどうやってプログラミングを身につけたか? - HTML/CSS編 -

どのようにしてHTML/CSSを身につけたか

きっかけはバンドを組んでないのにホームーページを作ろうとしたこと

中学校二年生の頃、バンドを組んでないのにバンドのホームページを作りたいと思っていました。
ある日、ある友達がホームページを持っていることを知り、彼にfront homepage express入門本を借り、早速サイトの制作に取り掛かりました。

その本を読み終え、geocitiesに簡単なテキストサイトを公開したように思います。

front homepage expressだけではいい感じのサイトにならず、どうしてもかっこ悪いデザインになってしまう。そこで本の巻末にあったメモ帳でhtmlファイルを編集する方法でサイトの更新を行うようになりました。

この時友達に質問したことを今でも覚えています。

sg「画像の横に文字書くのにはどうすんの?」

友達「罫線のない表を組めばいい」

爆誕tableレイアウトコーダー

tableレイアウトを覚えるとどんなデザインでも実現できるようになりました。
僕は様々なレイアウトのページをhtmlで作っていました。
htmlだけを作るのが楽しくなって、絵を描くようにいくつもサイトを作っていました。
サイトのメニューをいい感じに作れるようにframeタグもうまくつかっていました。
この頃にはエディタもterapadというお気に入りのエディタがありました。

「違う。。何かが違う。。俺のサイトはyahooとは全然違うぞ!!」

そう思った僕はありとあらゆるサイトを 右クリック→ソースを表示 を繰り返し、cssを学んでいきます。
ググりまくる中で、プロはレイアウトをdivで組むしいということを知り、floatレイアウトを覚えました。

cssは僕にとって最初aタグのhoverを作るためだけだったものでしたが、htmlは構造を書き、cssで見た目の装飾するという基本に気づいたのはこの頃でした。

インターネット上に公開されてるhtmlのソースを見て、見よう見まねでhtmlを覚えました。
この時に論理だった話はあまり勉強しなかったように思います。とほほさんのサイトにはお世話になった気がしますが、htmlは直感で乗り越えた気がします。

この頃高校生くらいになっていたかと思いますが、簡単なWebページであれば趣味レベルで作ることができるようになっていました。

これからHTML/CSSを勉強する人に

この二つが大事に思います。僕が中学生の時代よりはdeveloper toolsなども発達し、上記二つの作業のPDCAも回しやすくなってきたと思います。developer toolsの使い方はここでは触れませんので、検索するなどして見てください。

ブログをjekyllに移管のためにやったこと・やらなかったこと

jekyllにブログを変えてみました。
markdownで記事を書けるのはやはりすごい楽です。
お気に入りのエディタであるvimで書けることも素晴らしいです。
やったこと、やってないことをまとめておきます。

やったこと

bloggerで運営していたブログを移管しました。
一部labelページ以外を除いて、同じURLに移行しました。

bloggerで長らく運営していたこのブログですが、
bloggerのhtmlがなかなか弄りにくいことが主な要因です。

blogger自体テーマがあまり充実していないのと、良いテーマがあっても、
それをカスタマイズするのにhtmlのようなxmlを弄るのに疲れてしまいました。

wordpressという手段もあったのですが、静的サイトジェネレータに興味があったので、
今回のような形になりました。

ちなみに静的サイトジェネレータをjavascriptで作ろうとしたのですが、
そこは挫折してしまいました。。

なんでhugoじゃないの?とかなんでoctopressじゃないの?
って質問があると思うので、書いておきます。

hugoじゃない理由

rubyでpluginを作れることとgithub pagesでメジャーな手段になったことくらいでしょうか。
hugoは正直魅力的なので、どこかで試してみたいとは思っています。

octopressじゃない理由

htmlを弄りやすいようにしたいことが、今回の動機でもあったので、
octopressはテーマは充実していますが、htmlがそんなに得意ではない自分ではoctopressのテーマは弄りにくいなぁと思いました。
あと、jekyllの方がdocsも充実しているように見えたのと、コード自体の見通しもよかったです。

その他検討したもの

フロントの実装がメインになる静的サイトジェネレータですから、javascriptで全てを統一するという夢は僕もみました。
javascriptのエコシステムでほとんどのものがそろっていますので、gulpで適当にビルドしたりデプロイしたりは容易い御用なはずです。

そこでmatalsmithというjavascript静的サイトジェネレータを検討していたのですが、
独自のpluginのインターフェースに実装していくのが、骨が折れてしまいました。

しかも、pluginのほとんどはnpmのエコシステムにありふれたものをpluginとしてラッパさせたもので、
少しjavascriptを書けばいろいろなことができそうだったのですが、それを書く手間をはぶけるcomponent型のシステムを作れば。。。

と考えたところで土つぼにはまってしまい、本来のブログを書くという目的を見失っていたところ、
ふと正気に戻り、jekyllという選択をした経緯があったりします。。

各記事のURLが変わらないように。。

sitemap.xmlを取得して、URLを抽出。
その抽出したURLに対して、phpunit gazzleで200が帰ることをテストで書く。
そして、 /etc/hosts を新環境に向く事を確認して、再度同じテストを回す。

URLが変わってしまった記事に対してはテストが落ちるので、ちょこちょこそれらを微調整していく。
まぁ、そんな感じです。

やれていないこと or 見送ったこと

tagの移管も本当はしっかりしたいのだけど、まだできていない。
本当は移管自体はできているのだけど、ちゃんと機能させれていない。

google tag managerで広告枠とanalyticsを管理したかったけど、とりあえずいつでもできるので後回しに。

slimを導入したかったのだけど、ちゃんとコンパイルできず。。
jekyll puluginの使い方などわかっていないところがあるので、その辺りがわかるようになったら再度挑戦って感じかな。
htmlは書きにくいけど、DreamWeaverに頼れば割と簡単にいろいろできそうだし。。