RSpecのexpect() と expect{ } がややこしい

expect() と expect{ }の使い分けを理解する

最近RSpecのテストを書くようになったのですが、 expect()expect{ } の違いがよく分かっておらず、「どっちかでテストを書いてみて、 テストが落ちたら、もう片方に修正する。」 なんて、非常に無駄な作業が発生していたので、調べてみました!

もうお分かりかと思いますが、RSpec初心者向けの記事です笑

結論

結論から言うと、expect()expect{ }2つを使い分けるコツは expectはmatcherに中身をそのまま渡すので、() で書けるか、{}でかけるかはmatcherがProcを評価できるか出来ないか次第 と言うことでした!

なので、この2つの理解が大事と言うことですね。 - matcher - Proc

どちらも、ご存知とは思いますが、一応簡単に説明入れると

matcher

matcherとは下でいう to の部分のことです。 expect() で呼んでいる変数とeqの後に続く期待する答えの橋渡し的な存在です。 to以外では、not_to be raise_errorなどがあります。

hoge = 3
expect(hoge).to eq 3

Proc

Procとはブロック(何らかの)をオブジェクト化するためのクラスです。 Procオブジェクトはcallメソッドによって実行されます。

ex

add_number = Proc.new { |num_1, num_2|
  puts num_1 + num_2
}
add_number.call(1, 2) #=> 3

Procについては下記の記事がわかりやすいと思います Ruby Procについて学ぶ - Qiita

下記の記事を参考にしたので、理由は下記の記事を参照してください。 should を捨て expect を使うようになった、たった一つの理由 - MUGENUP技術ブログ

Rubyのattr_accessorについて

こちらの記事を参考にしました!

以下は自分なりにこの記事を咀嚼したものですので、詳しくは元記事をお読みください。

bryankawa.hatenablog.com

 

Rubyのattr_accessorについてのお勉強

なんとなくModelクラスにいるあいつってぐらいしかきちんと分かっていないので、まとめてみました。

 

結論からいうと

👇を省略して記述するためのものがattr_accessor

class User
  def name
    @name
  end

  def name=(str)
    @name = str
  end
end

user = User.new
user.name = 'Yusuke'
user.name # => "Yusuke"

 

`User`インスタンスにある`name`は

読み取り書き込みが必要である。

そのため本来は👆の様に、

読み取りようのnameメソッドと

書き込みようのnameメソッド

が必要だが、それを簡単に記述できるようにしてくれるものがattr_accessorになる。

 

で、実際に使うとこうなる。

 

class User
  attr_accessor :name
end

user = User.new
user.name = "Yusuke"
user.name # => "Yusuke"

 

ちなみにこの2つの実装の中間がこんな感じ

 

class User
  attr_reader :name
  attr_writer :name
end

 

readerをゲッター

writerをセッターと呼ぶ

 

そして最後に。

attr_accessorで設定したnamはインスタンス変数でUserオブジェクトに設定することが出来る

 

class User
  attr_accessor :name

  def greeting
    "Hello #{@name}"
  end
end

user = User.new
user.name = "Yusuke"
user.greeting # => "Hello Yusuke"

Rails5へのバージョンアップ ApplicationRecordへの変更

Rails4からRails5にバージョンアップする時の変更点として、ApplicationRecordを継承するようになるのが大きな変更点の一つとしてある。

 

それぞれRails4、5のモデルを見てみると、

 

これがRails4

class Article < ActiveRecord::Base

end

 

これがRails5

class Article < ApplicationRecord

 end

 

4ではActiveRecord::Baseを継承していたのが、

5からApplicationRecordを継承するようになった。

 

で、ApplicationRecordはどうやってできているかと言うと、

# app/models/application_record.rb class ApplicationRecord < ActiveRecord::Base

self.abstract_class = true

end

 

ActiveRecord::Baseを継承している。

つまり、各モデルとActiveRecord::Baseの間に一つクラスが挟まるようになった。

 

最初は余計なものが増えて面倒臭いだけでは?と思ったが、

モデルに何か機能を追加したいときに、今まではActiveRecord::Baseに追加するので、ActiveRecord::Baseを継承する全てのクラスが強制的に機能を継承してしまい、無駄な影響を与えてしまう危険性があったが、それを今までよりは回避しやすくなったのがメリットで、目的だと思われる。

BigDecimalとfloat

 

少数

→ 0以下の数字(0.1や0.25など)を含む数字

ex 1,44  2,25など

1.44 x 10^0、0.144 x 10^1などでも表せる。

仮数部 x 基数^指数の構造)

このような仮数、基数、指数で表現される小数を浮動小数点の表記方法という。

 

注意点

浮動小数点数はコンピュータに置いて丸め誤差が発生するので、正確な計算が求められるものに関しては適切ではない。

 

BigDecimal

浮動小数点数演算ライブラリであり、任意の精度で10進数で表現された浮動小数点を扱える。

0.xxxxxxxx10nという形で(10進数)数値を保持する。

浮動小数点数で発生していた丸め誤差を生じずに演算ができるようになっている。

 

計算は若干浮動小数点数を使った方が早い

 

 

 

エンジニアがデザインシンキングを学んでみる

週末の時間を使って、デザインシンキングのワークショップに参加してみました。

UIやUXに関しては興味はあったものの、全くの無知だったため、

初心者も歓迎という言葉につられて、参加。

結果としては、非常に参加しがいのある、有意義なワークショップでした!!

 

今日学んだことをサクッと振り返りたいと思います。

 

そもそもデザインとは何をさすのか?

日頃バックエンド中心で開発をしているプログラマとしては、「デザイン」といえば、

  • ユーザーに使いやすいフロントを考える
  • 美しいフロントを構築する
  • 必要な機能をどのページに配置するかを考える

などなどが思い浮かぶのですが、

 

今回のワークショップにおいて、「webデザイン」とは

ユーザーの課題を発見、解決するためのプロセスを作成する

と捉えていました。

 

デザイナーといえば、フロントの画面を作成することを専門としているのかと勘違いしがちなのですが、あくまでもデザインとは、ユーザの課題を解決するプロセスを構築することらしいです!

 

「むむ、そうなるとちょっとプログラマとデザイナーの境界線はどこなんだろう、、、」

と混乱しましたが、

ここで大事なことはデザインとは画面に絞ったことではないということで、

 

ユーザーが抱える問題の発見から、その問題を解決する手段を解決する方法を明確化する

ということにあって、非常に広い範囲を網羅しているんですね。

デザイナーの皆さん、大変失礼いたしました。。。

 

デザインとは足し算と引き算が重要!! 

今日のワークショプとは5時間超となかなかコンテンツも豊富で、基本的なデザインのプロセスなど多くのことを学ぶことが出来ました。(会社の同僚や友人のプログラマも参加したのですが、非常に満足どは高いようでした!!)

 

その中でも、今日一番刺さったことは

 

「デザインではTrade-offを大事にしています。」

 

trade-off?? 交換?なんの話?

と最初は思いましたが、説明を聞くとなるほど、

 

  • 機能を盛り込みすぎることには気をつけろ
  • 何かを足すメリットは同時に何かをなくすデメリットを孕んでいる
  • これ以上引くことが出来ない状態がゴール(これはminimalというらしいです。)

という事を意味しているらしく、

 

よくありますよね。使わない機能が盛り込まれすぎたアプリケーション。

「これじゃかえって使いたい機能も使いにくいっつーの!!」

という悲劇が発生している状態。

 

プログラマ的にはその気持ちは痛いほどわかりますし、ついつい気づけばその方向性に行きがちなのですが、、、

 

デザインでは、こういったことも非常に意識して作成することが大事だということ。

確かに、そもそもデザインとはユーザーの課題を解決することが大事なのに、

いらないお節介で対して重要じゃない課題の様なものまで解決しようとして、結局本来の課題解決自体が薄くなったら意味ないですもんね。

 

これは、今後開発をしていく中でも意識していくとかなり自分にとってプラスだなと思いました。

 

と簡単でしたが、今日のワークショップの感想とまとめでした。

今後はデザイナーの視点や、考え方も尊重しながら開発を出来たらと思います!!

 

ではでは!

 

 

 

 

 

発信するということ

初投稿です。

 

社会人1年目でエンジニアをしている、なすと言います。

 

未経験ながらプログラマという職業に夢見て、ベンチャーに就職。

理想と現実のギャップの葛藤7割、喜び2割、無気力1割でなんとか
生きています。

 

発信するのは大の苦手で避けてきたけど、このままいくと一生発信することが出来ない

人間のまま終わるのではと思い危機感が爆発。
まずはひっそりと初めてみました。

 

初投稿は「なぜブログを始めようと思ったか」について

 

生まれてからずっとでは無いけど、発信が苦手。

理由はおそらく自分に自信がないからだと思う。

 

発信したい考えが全くないわけでは無い。

むしろ、思っていることや考えていることは山ほどある。

 

ただ、それが間違った考えなのではないだろうか?

他人からバカにされる考えなのではないのだろうか?

といつも気にしてしまうのだ。

 

単純に言うと、プライドが高いだけ。

ミスをしたくないだけなんだと思う。

 

他人の評価を気にしすぎている。

→自分に対する自己評価の重要度が低い

→つまり自分に自信が無い。

ということだろう。

 

今まではそれでも別に支障はなかった。

討論をする機会も今までそんなになかったし。

 

けど、働き始めて少しずつ感じてきたのが、「それではまずいな」ということ。

もう、何かに流されるままでは、何も無い人間になってしまうなという危機感。

 

発信することは少なかったけど、それでも何かを達成できる人間では

ありたいと思っていたし、今の人生がすごく楽しいと思えるような

生き方をしたいと思っていた。

 

けど、そのためには悔いが残らないように行動しないといけないし、

味方も必要だ。

 

現実は厳しいことに、何も発言しない奴に味方はつかない。

 

それなら、自分から周りに訴えかけることで、自分で選択をし、味方を増やさないと

いけない。

 

そう思って、まずは小さな小さな一歩から始めようかと。

 

継続して頑張ろうと思います。