適当に、つらつらと

日々思った事等を適当に書いていければと。

rspec-grapeでのGrape APIのテストコード

Grape APIRSpecについて調べてみると、大体 Request Spec での書き方ばかりだったので備忘録的なメモとして。

使用するGemは下記

github.com

大体はREADME読めば分かるんだけど、書き方としては以下のように type: :api を定義する。

describe API::V1::Users, type: :api do
   ...
end

テスト対象のAPIはcontextで指定する。
contextの記載は下記のように METHOD PATH の形で指定する。
なので、POSTメソッドのテストの場合は POST /api/v1/users/ のように記載する。

describe API::V1::Users, type: :api do
  context "GET /api/v1/users" do
    ....
  end
end

type requestとは違い、リクエストには call_api メソッドを使用する。
引数にhash形式でパラメータを渡す事が出来る。

describe API::V1::Users, type: :api do
  context "GET /api/v1/users" do
    it "request success" do
      expect(call_api.status).to eq 200
    end
  end

  # パラメータが必要な場合
  context "POST /api/v1/users/create" do
    it "request success" do
      expect(call_api({name: "hoge"}).status).to eq 200
    end
  end
end

また、PATHにid等の可変パラメータがある場合は下記のように指定する。
可変パラメータはcontextで記載した :id などの値を call_api にhashで渡す事で反映される。

describe API::V1::Users, type: :api do
  context "GET /api/v1/users/:id" do
    it "request success" do
      expect(call_api({id: 1}).status).to eq 200
    end
  end
end

以下調査中。
Authorization等、認証でheaderに値を設定する必要がある場合の call_api の呼び方。
type requestと同様に引数で渡せばいい?

Gem、、、じゃなくてRailsEngineのRSpecをRailsAppから呼び出せるようにした際のメモ

書き残して置かないと忘れそうなので箇条書き。

Gemの形で作成しているRailsAppRailsEngineのRSpecをどうやればスマートに実施出来るか試行錯誤中。 一旦、タイトルのようにGemをInstallしたRailsAppから呼び出せるようにしたのでメモ。

まあ、概ね公式にもある通りかな。 rakeタスクを lib/tasks 配下に作成し Rails::Railtie を継承したクラスを用意して rake_tasks 内で呼び出すようにする。

rakeタスクの例

namespace :hoge do
  desc "gems rspec"
  task :spec do
    Rspec::Core::RakeTask.new(:hoge) do |t|
      example = []
      example += ENV['spec_example'].split if ENV['spec_example'].present?
      t.rspec_opts = example.map{|ex| "-e #{ex}"}.flaten.join(' ')
      t.pattern = File.join(Gem.loaded_specs['hoge'].full_gem_path, t.pattern)
    end
    Rake::Task[:hoge].invoke
  end
end

Railtieの例

module hoge
  class Railtie < ::Rails::Railtie
    rake_tasks do
      load "tasks/rspec.rake"
    end
  end
end

こんな感じにしておいて、あとはrails_helperやspec_helperを用意すれば RailsAppのRakeタスク一覧に表示され、実行も出来るようになるはず。

しかし、書き方が悪かったのかGemのテストで定義していたFactoryBotが読み込まれずエラーとなったので taskの処理を以下のように変更した。

namespace :hoge do
  task :spec do
    from_rails_helper  = "#{Hoge::Engine.root}/spec/rails_helper.rb"
    from_spec_helper = "#{Hoge::Engine.root}/spec/spec_helper.rb"
    to_dir = #{Rails.root}/spec/"
    FileUtils.mkdir_p(File.dirname(to_dir))
    FileUtils.cp(from_rails_helper, to_dir)
    FileUtils.cp(from_spec_helper, to_dir)
  end
  〜〜〜 略 〜〜〜
end

Gemで作成したrails_helperには下記のようにrequire処理を追加しておく

Dir[Rails.root.join("#{Hoge::Engine.root}/spec/factories/**/*.rb")].each {|f| require f}

凄くざっくり&強引だけど、rakeタスク実行時にrails_helperとspec_helperをGemからRailsAppへコピーして呼び出してる。 なのでRSpecのrequireは "rails_helper" だけで問題ない。

現状の課題としては

  • RailsAppからの実行なので、RailsAppのgemfileでRSpecやfactory_botがinstallされてないと実行できない。

    -> 解決した。add_development_dependencyなんてものがあった。

  • 複数のRailsEngineのテストを一気に流す事が出来ない

  • やっぱりRailsAppからではなくRailsEngine単体でテスト実行出来るようにしてCI回したい

-> add_development_dependencyオプションを使って行けるか試行錯誤中

こんなところ。

参考にさせて頂いたのは以下 qiita.com

api.rubyonrails.org

会社を辞める事にした。

突然だけど、今月一杯で今勤めている会社を退職します。

幸い、次の勤め先も決定していて(と言うか、決定したから辞める事にした訳で。) 後は退職時期を調整するだけ……だったのだが、何とか希望通り今月一杯で退職できそうな目処が立った。 とは言え、急な話となって今の派遣先に多少迷惑をかけてしまった事については申し訳なく思う。

実は、数年前から転職を考えていたのだけど踏み切った理由としては色々あるんだけど。。。 やっぱり一番は、今後のキャリアが今の会社だとどん詰まりになる事が見えてきたからかな?

約8年間(だったかな?)の間で自社内での業務ってトータルで1年ちょいぐらいしか無くて それ以外はぜーんぶ外に出ての派遣業務。 で、無駄に色々やってきたんで新しい現場にもある程度早く馴染めるようにはなってきてる実感はあるんだけど 自分のスキルとしては、、、プログラマ+αな域を出ない状態なんだよね。 SIer的なキャリアは別に考えては居ないんだけど、提示された仕様を元に作る仕事ばかりで……

いや、中には(今の案件みたいに)色々と仕事を振って頂いたりプチSE的な仕事もあったんだけど トータルで見ると、今後エンジニアとして生き残れる力がついたかと問われると……うーん。。。

今の派遣先で、幸いにもそう言う色々な部分が足りないと言う事に気づけた事。 あと、心の奥底に「まあ、派遣だから仕方ないよね」的な気持ちが存在してる事に気づいて このままだとマジでどん詰まりだって強く感じちゃってねー

安穏とした派遣と言う立場に甘んじて、このままダラダラと行くよりは 多少無茶をしてでも頑張って行く方が、今後を考えるとプラスになるだろうし。

転職先は主に受託で企画〜保守まで幅広くやってる所なので、出来る限り物怖じせずに自分から色々とやれるように 意識を切り替えないとだめだろうなーと思いつつも、なんとかなるかなーとも。

まあ、来月から改めて頑張っていきましょー

「自己紹介 あなたへ30の質問」に回答!

何かあったので回答してみる。

自己紹介 あなたへ30の質問

01. みんなから何て呼ばれてる?

イステ、若しくは苗字

02. 自分の自慢できるところは?

既に過去の栄光になっちゃってるけど、高校時代に工事担任者総合種と第二種電気工事士を取得した事かなー

03. 自分の弱点は?

打たれ弱い事。

04. 自分の口癖は?

(自分が)シネバイイノニ

05. 持ってるケータイの機種は?

Xperia NX

06. カラオケでよく歌う歌は?

勇者王誕生!かなぁ?
基本アニソンしか歌えない

07. 過去に似ていると言われたことのある芸能人は?

ジャッキー。でも似てないよ?

08. 座右の銘は?

人生万事塞翁が馬

09. 将来の夢は?

何かプロダクト/サービスを作る

10. ブログをはじめたきっかけは?

技術メモや勉強会レポを書くため、かな。
もう最初の趣旨からかなり離れてる気がするけど(;´Д`)

11. 好きなアニメは?

スクライド魔法少女まどか☆マギカ
今期だとMJP/ガルガンティア/はたらく魔王さま!

12. 好きなゲームは?

最近だとSkyrim

13. 好きな食べ物は?

福岡人ならとんこつラーメンでしょ

14. 好きな飲み物は?

コーヒーと牛乳

15. 好きな動物は?

犬、猫

16. 好きな色は?

黒と赤黒

17. 好きな芸能人は?

いない。

18. 好きなファッションブランドは?

ないなー

19. 好きな雑誌は?

週刊漫画雑誌とWeb+DB

20. 好きなスポーツは?

ロードレース/F1

21. 昨日晩ご飯に何を食べた?

ハヤシライス

22. 最近見た夢を教えて!

覚えてない。

23. 最近読んでおもしろかった本を教えて!

はたらく魔王さま!シリーズ
ダンウィッチの末裔

24. 最近見ておもしろかったテレビ番組を教えて!

無い。そもそも朝と帰宅直後にニュースを観るぐらいだし。

25. マイブームを教えて!

RoR/Git
あとはクトゥルフ神話

26. 旅行するとしたらどこに行きたい?

台湾

27. 明日地球が滅びるとしたら何がしたい?

本を読む

28. 自分を一言で表すと?

残念

29. 自分の秘密を1つ教えて!

こっそり転職活動実施中

30. 次に答えてほしい人をidコールしよう!

居ないアル

とりあえず、こんなところで。
3DS LLが当たるらしいけど、まあ無理だろうからゆるーくね。

子供に読ませたい本、ねぇ

はてブで見かけた
こちら
「子どもに読ませたい本」から感じる違和感 - やわらか図書館学
とこれ
「子どものための本棚作り」というのをずっと密かにやっている - 脱社畜ブログ
を読んで、ふと自分の子供時代はどうだったかを思い出してみる。

とは言え、自分も本を読むことについて親から強制された記憶は無い。
ただ、本棚には絵本と一緒に親の蔵書である「ニュートン」や「宇宙英雄ペリー・ローダン」シリーズや考古学関連の本が一緒くたにされて置かれてあったのは覚えている。
あと、漫画本もあったのだけど、そちらは押入れの中に収納されていて、探さないと見つけられないようにされていたくらいなか?
(その中に親父が未だに愛読しているゴルゴ13シリーズもあったから、今思えば隠されていたのは当たり前だとも思っている。まあ、小学生の頃から押入れから引っ張りだして読んでいたがw)

両親揃って読書家だった為なのか、本が身近にある生活が当たり前だったし
暇な時に理解出来ないながらも棚にあったニュートン別冊の図を見たりして胸をときめかせた記憶もある。
そのお陰(?)なのか分からないが、今ではすっかりSF好きになったし
考古学や歴史についても一定の興味は持ち続けている。
ただ、後者についてはそこまで熱心ではなく、興味はどちらかと言うと寺社仏閣寄りだったりするが。

まあ、そんな感じで読書や趣味に親の影響がある事は否定出来ないのだけれど
親から強制された訳では無い事は確かだ。
多分、強制されてたら反発してたと思うけど、そんな事は一度もなかったと記憶しているし
自分の読書ジャンルに口出しされた記憶も無い。

そして自分と同じ環境に居た妹は少女漫画とメジャーな少年漫画ぐらいしか読んでないけど
やっぱりそっちも何も言われてないし、自分も言うつもりはない。

まあ、何というか
本ってのは強制されて読んでも面白く無いよね。
確かに、自分が好きな作品とか薦めたくなるけど、無理やり薦めても意味は無いし
例え強固に薦めて読んでもらっても、それだけじゃ意味が無い。
小説でも漫画でも技術書でも学術書でも、読むのなら根底に「楽しさ」が無いとダメだと思う。

だから自分も他人に本を薦める事は滅多にない。 自分が面白いと思う本を相手も同じように感じてくれると思えば、その限りではないけど。

そんな感じで、興味を持った本を読めばいいんじゃないかな?
その為には、色んなジャンルの本を置いて、どの本に興味を示すのかじっくり待てばいいと思う。
そもそも本に興味を持たくてもそれでもいい。

どんな名作だって、強制されて「読まされる」となると面白く無いし、内容も頭に入ってこないからね。
興味を持ってくれるのを気長に待つのが一番だと思う。

HHKLite2を衝動買い

自宅WinPCに接続してるキーボードの反応が悪くなってきた&前買ったフラットタイプなので使い辛いと感じていたので ついついHHKLite2を衝動買いしてしまった。

Amazonで昨日……と言うか木曜の午後にスマホのAmazonアプリで購入して 届いたのが金曜の昼。 幾ら鳥栖に集配センターがあると言っても、ちょっと早すぎなんじゃないかと思ったりも。 ……配送記録見たら、AM3:00過ぎに配送開始してたよ(;´Д`)

鳥栖のセンターの中の人や配送会社の方には頭が上がりません。

で、今は何故かMacに接続して使ってたりします。 いや、WinPCの背面から今のキーボードを外すのが面倒だっただけなんですがね。 まあとりあえず、初HHKなので使い心地を試そうかと。

まだ使い始めて数時間だけど、何でもっと早く買わなかったのかな? CtrlキーがCapsLockの位置にあるのって、やっぱり凄く楽だわ。 Macのキー配列に慣れたからってのもあると思うんだけど、それでもやっぱり楽だわ。 キー自体も良い感じに押しやすいし、売りの一つになってる各列の傾斜も良い感じ。 確かにこりゃ人気出るわなーと思ったり。

どうしよう、、、最初は自宅用にと考えてたんだけど、仕事でも使いたい。。。 案としては 1. もう一つ購入して片方持っていく 2. 今あるやつを使いまわす なんだけど、どうしたもんだかなー? まあ、決めるのは後でいいか。

しかし、キーボードが良いと何か書きたくなるのは自分だけかね?


追記。

Macに繋いでいたのをWinPCに繋ぎ直してみた。 改めて思ったんだけど、HHKってMac……と言うかEmacs/Vimキーバインドと相性が良いよね。 CtrlがShiftキーの上にあるのが理由の一つなんだけど。

これはキーバインド変更アプリでも入れてWinのキーバインドEmacsライクに変えるべきなのかなぁ……? と言うか、幾つかのblogにも書かれてたけどMacとの相性抜群だね。

TDDBC Fukuoka 2013に参加してきました。@1日目

はい。タイトル通り6/15,16とRubyセンターで開催された TDD Boot Campに参加してきました。

1日目は和田さん(id:t-wada)のkeynote講演から始まって 希望言語毎にグループ分け・ペアを決めてのペアプロでのTDD。

keynoteで印象に残った事柄とか

  • バージョン管理を使わない開発は「セーブ無しでRPGをクリアするようなもの」
  • テストはするだけじゃなく、続ける事が重要
  • 自動化して面倒事はシステム側に押し付けると楽だよね
  • 「テスト」の粒度・対象による名称使用が企業、下手したらチームレベルで違う事による混乱
  • TDDのサイクル

とりあえず、TDDのサイクルとして目標をTODOとして切り出していって 1つのTODOに対してテスト→実装→リファクタを繰り返して進めていくって事を Demoとハンズオンで肌で感じれた事が一番の収穫かも。

特に、TODOに切り出す粒度とか。 あんなに(ヘタすると1行毎のレベル)まで切り出してから進めるなんて正直ビックリした。 ハンズオンを経験した後だと、確かに粒度をどんどん細かくして行った方が サイクルも早く回るし(和田さんがkeynoteで言われてた通り)問題等が発生した時の 方針修正とかも素早く行えたので、納得……と言うか体で理解できたんだけど。 ハンズオンが無かったらそこまで理解できていたかどうかw

ハンズオン1日目

1日目はRuby組(これが最大勢力だった。流石福岡?w)に参加してのハンズオン。 他の組は * java * C# * Objectiv-C * JavaScript だったかな?

そして課題は * 郵便番号バリデータ * 数値三桁を許容 * 数値七桁を許容 * 数値三桁 + "-" + 数値四桁を許容 の実装。

ベースサンプルをTDDBCのgithubリポジトリからcloneしてきて ペアを組んで進めて行ったんだけど、最初は方針を決定するだけで一苦労w とりあえず、後の事はあまり考えずに簡単な物から簡単な実装で進めて行く事にしました。 TODOとして切り出した項目毎にテスト→実装を繰り返して、1項目が完了する毎にドライバーを交代 と行った感じで進めて行きました。

途中、考慮漏れに気づいた時とか先に実装をしようとしてペアの方に諌められる事も何度かw うーん。まず実装するって行動をちゃんと自分で制御出来るようにならないと。。。

で、ある程度TODOの消化が進んだらリファクタリングの為にテスト書いてリファクタして と進めて行ってると、スライドの内容に変化が……!!

  • 誰が全て0を許容していいと言った?

な、なんだってーーー!? って感じで追加仕様提示があって焦ったりも。

ただ、最終的にはなんだかんだ言いつつ提示された仕様は全て実装出来て リファクタリングもある程度出来たので良かったかな、と。

ペアプロ&TDDの感想としては * 最初は右往左往に近い状態だったけど、進むにつれてTODO消化速度が明らかに上がっていった * ペアプロ楽しい * ペアプロ疲れる * ペアプロやるとコミュ力上がりそう

後半につれてどんどん速度が上がって余裕が出来てきた事を実感できたのが大きかったかな。 そりゃ確かにコードを書く時間は増えるかもしれないけど、慣れれば慣れる程機能辺りの実装時間は短く感じてくる(実際短くなってた)から面白いなーと。

そしてレビューと振り返り。 各言語チームによるレビューと、KPTでの振り返りをやった後にLT大会が行われての1日目終了。

その後は懇親会があったけど、そっちについてはまた後で書こうと思う。