桐生あんずです

京都在住大学生のブログです。日常やプログラミングについて書いてます。

フライパンでガトーショコラを作ろう #独身男性手作りチョコバトル

桐生あんずです。巷では独身男性手作りチョコバトルなる催しがインターネットで行われているらしい。それも兼ねてチョコを作った時のことを記事を書こうと思います。

(私は独身男性ではないですが、このイベントは独身男性でなくてもチョコに関係なくとも参加できるらしいです。)

 今まで私はバレンタインデーに手作りチョコを生成するにしても、湯煎で溶かしたチョコを流して市販のタルトの型(ロフトとかでよく売ってるやつ)に流し込むぐらいしかしていなかったのですが、さすがに22歳女子大生がこのような状態を貫くのはやばいのではないかという危機感に襲われるようになり、今年は何か手の込んだことをしたいとずっと唸っていました。

だが、一人暮らしの下宿先にオーブンなどない。炊飯器や電子レンジで何か作ることもできそうだけど、あんまりうまくできるか不安だなあとなりどうすべきかとなっていた時に大学の先輩のid:chidorimemoさんのこの記事を読んで、

バレンタインデーの手作りチョコでガトーショコラを炭にした話 - とりめも

ガトーショコラがフライパンでも作れることを知りました。

フライパンで作ってみるの、なんか手料理感があるし焼き加減もコントロールできるし楽しそう。よし、フライパンでガトーショコラを作るぞ!!!

f:id:kiryuanzu:20180215020605j:plain

まずはチョコ100gとバター一切れを湯煎(45~55度くらい。沸騰するくらいまで沸かしてしまうとチョコの旨味がなくなっちゃうらしい。)に溶かす。

溶かしたら、卵一個、ホットケーキミックス600g、砂糖大さじ2杯、無糖ココアパウダー大さじ2杯を一緒にかきまぜて、フライパンにクッキングシートを敷き、弱火で10分ほど焼いてみました。

f:id:kiryuanzu:20180215020718j:plain


なんか、こんな感じに焼けました。ちょっとこのままだと見た目が微妙ですね…。

なので、クッキーの型を使ってハート形や星型を作ってみました。

f:id:kiryuanzu:20180215020742j:plain

ちょっと可愛くなった。

ただ、これ失敗しやすい上に型の外側の余った部分が非常にもったいないことになる。なので全部に適用するのは断念しました。(余った部分は調理者が作った翌日の朝ごはんとして美味しくいただきました。)

f:id:kiryuanzu:20180215020748j:plain

星型を作ろうして失敗した図。

 

結果的に、一口サイズくらいに包丁で切ってココアパウダーとかホワイトシュガー(名前間違ってそう)みたいなやつをかけたらそこそこいい感じになりました。

f:id:kiryuanzu:20180215020752j:plain

f:id:kiryuanzu:20180215020756j:plain

わーい。

 

そんな感じで初めてバレンタインデーにほんのちょっとだけ手の込んだお菓子を作ることができました。味見してみたらちゃんとガトーショコラの味になってました。よかったです。1回分作るだけでも30分満たないぐらいはずだったのでお手軽です。フライパンは良いぞ。

 

作ったガトーショコラは、アルバイト先とその日会った人にあげました。ありがとうございました。

 

「入門コンピュータ科学 ITを支える技術と理論の基礎知識」を読んだ

桐生あんずです。
最近、プログラミング言語の教本を読み進めて勉強してはいるけれども、もっと根底の部分というか情報学の土台の部分をもっと知るべきなのではないかと思ってまずはKADOKAWAから出版されている「入門コンピュータ科学 ITを支える技術と理論の基礎知識」を数日間かけて読んでいた。

入門 コンピュータ科学 ITを支える技術と理論の基礎知識

入門 コンピュータ科学 ITを支える技術と理論の基礎知識

内容としては、1~3章はブール演算の説明から始まり、マシン語オペレーティングシステムといった情報学の土台の土台と言えるような話が続く。

個人的に、実学的な話だと強く感じ始めたのは4章からでネットワークの基礎の話が始まりサーバーとクライアントの構造やネットワークセキュリティの解説が参考になった。一番ハッとさせられたのが5章のアルゴリズムについての章で、どのようにコードを構築すべきかを具体的にイメージするプロセスが細かく説明させられていたのがすごくよかった。
コーディングがちゃんとできるようになるためには、問題解決をするためのプロセスのイメージを膨らませて具体化させていく作業がとても重要だとわかったので、今後開発をしていく中でも困ったらすぐネットの文献やサンプルコードに頼るのではなく開発における問題で何が起きているのかをまず捉えて、どのような対処をすべきなのかを書き出して捉える作業をしようと思った。
問題解決のイメージをどう段階的に膨らませるかについては、P209に紹介されていたポリアの問題解決の段階の定義をプログラムの文脈に置き換えた話ががすごくわかりやすかったので引用します。

第一段階:問題を理解する。
第二段階:問題を解く計画を考案する。
第三段階:計画を実行する。
第四段階:解の正確さと、それが他の問題を解くためのツールとなり得るかどうか評価する。
プログラム開発の文脈に翻訳すると、これらの段階は次のようになるだろう。
第一段階:問題を理解する。
第二段階:アルゴリズム的な手続きによって、どのような問題が解けるかのアイデアを得る。
第三段階:アルゴリズムを定式化して、プログラムとして表現する。
第四段階:プログラムの正確さと、それが他の問題を解くためのツールとなり得るかどうかを評価する。

これをちゃんと行うためには、問題を捉えることはもちろん大事で、問題を解決するために繰り返し構造や再帰構造をどう使っていくかといった「武器」の扱い方を理解することが大事だと思う。
私の場合、問題を捉えるところまでいっても言語に用意されている「武器」の使い方についての知識が乏しいせいで自分で考える能力がまだちゃんと身についてない状態と言える(つまり日本語の読み書きが不自由な状態…)ので、まずは武器の使い方を教本やサンプルコードで理解し、問題を用意して武器をどう使うべきなのかを自分で考えるといった勉強方法が必要なのではと思った。

6章のプログラミング言語について紹介された章も、5章と同じくらい重要なことが書かれていた。
プログラミング言語の形成の歴史から始まり、変数とデータ型、データ構造といった伝統的なプログラミング概念、オブジェクト指向プログラミングにおけるクラスとオブジェクトの概念などといったプログラミング言語の学習においてはかかせない常識が一から説明されている。
この部分に関しては、いずれかのプログラミング言語を勉強してから読んでみると、スッと入る部分が多かったと思う。もちろん早めに知っておくべき話ばかりなのだが、RubyJavascriptの基本的な書き方をある程度知った後に読むと具体的な使い方のイメージがすごくしやすいと思う。
7~9章もモジュールの扱い方やデータ構造、SQLなどといった開発においてはかかせない説明が多くあり、特にDMBSについての解説はまだ完全に理解できない部分はありながらも重要そうだと思った。
なので、一度で読み終わらすにはとても勿体無い本だと思ったので4~9章は定期的(まずは週一ぐらい)に読み振り返っておきたい。

なんとかして全体通して読んでみたけれど、文系非情報系エンジニア見習い的な立場としては情報工学の基礎を文字通り入門できた気がする本だった。
実際、同年代の情報理工系の人はこういった内容を1回生ですでにやっているのだろうと思うしやっぱり専攻の違いはデカいなあ…と今更ながら思った。そんなことを嘆いても仕方ないので、バイト先や個人開発でコードを書いて実際に学びつつ、彼らが授業で知り得ている内容は技術書をガンガン読んで知見を得ていくしかないのだと思う。
また、読んでいて難しいとは思うところはかなりあれど、「ああ、ここが知りたかったんだよ!!!」とずっと思いながら楽しく読めた。

自分が使っているプログラミング言語の教本を読み進めることも大事だけど、もっとこういった基礎じみたことを勉強したいなあとなったので基本情報技術者試験を申し込んでみた。
去年、プログラミング言語のことをあまり理解してない状態でITパスポートを取っていた時よりかは実学的なイメージで勉強ができそうなので楽しみ。
ITパスポートの時にもお世話になった栢木先生の本を書いました。のちのち午後問題の対策もやらないとなあ…。

そんな感じです。文系で情報系に入門したい方はかなりおすすめの本でした。ありがとうございました。

1/30~2/1に東京に行っていました

桐生あんずです。タイトル通りの話です。12月の東京遠征の際はプリパラのライブとコミケといった感じで趣味メインでしたが今回は会社訪問で就活メインで動いていました。

Twitterではちらっと社名は出していましたが、あんまり掘り下げて書いてはいけないお仕事に関する話もあると思うので抽象的な感じで今回の東京遠征を感想を書いていきます。つまりポエムです。恥ずかしいので短めです。

 

勉強会等で京都の会社のオフィスに遊びに行かせていただくことは何度かありましたが、会社訪問という体で行くのは今回が初めてでした。最初はすごく緊張していてどのように社員さんたちと話せばいいか不安でしたが、技術の話や会社のサービスの話をたくさんしてもらえて次第にリラックスできました。あと、こちらが作ったものも見てもらえてすごく嬉しかったです。

会社訪問ということで、オフィス見学がメインになるのかなと思っていたのですが想像以上にエンジニアさんや人事さんとフランクに話せて興味深いお話をたくさん聞けました。インターネットの人の話や、RubyKaigiやRailsGirlsの話もできました。RubyKaigiで知り合った方々とこの機会のおかげで再会することができたのも本当に良かったです。

 

また、3日間ずっとそれぞれの会社を回ったおかげで、それぞれの会社の特徴、福利厚生や働き方の違いをより深く考えることができて今後の就活を考えるにおいてかなり重要な経験になったと思います。

また、どの会社でも「ちゃんと手を動かしてて偉いね」と褒められたのがすごく励みになりました。

Twitterでも述べたことなんですが、子供の頃から使っていた身近なサービスの会社や今もよく利用させてもらっているサービスの会社の方々とここまで身近な距離で好意的にコミュニケーションさせてもらえることが正直まだ非現実すぎて、ものすごく動揺しています。

周りにすごい人がたくさんいるということもあり、自分の技術力に関しては本当にまだまだだと思っていて自信はあまり持てません。でも、今回の3日間の中でいろんなすごい人たちから褒めていただけて、「私が今までやってきたこと、やっていることに関してはちょっとだけ自信を持っても大丈夫なのかもしれない」と頑張って思うことにしました。正直まだまだ自信は持てないけれど、否定してしまったらその方々にすごく申し訳ないと思うので。

その気持ちを大切にして、自分が行きたい企業をちゃんと選んで就活していこうと思います。人生初の会社訪問でそれぞれの会社の状況を生で見れたこともすごく良い学びになったのですが、これからの就活に備えて自分への自信をちょっとだけ持てるようになったことが一番大きいと思います。

 

テストの疲れも癒えてきて、会社訪問も終えて日常に帰って来た気がするのでとりあえず2月,3月の具体的な目標とスケジュールをちゃんと立てようと思います。(遅い気がする)

就活が始まって人生がどんどん進んでしまっている気がして正直不安もちょっとありますが、止まらないように手だけは動かしていきたいです。体調も考えつつ。

そんな感じです。ありがとうございました。やっぱりポエムになってて恥ずかしい。

 

Railsのminitestで画像アップロードのテストをする際にpublic/system以下に余分なディレクトリを生成しないようにする

桐生あんずです。
以前に以下の記事で、
kiryuanzu.hatenablog.com
paperclipで画像アップロードをした際の画像テストのやり方を紹介しました。
ただ、このままの状態だと、テストするたびにpublic/system以下にディレクトリが生成されてしまう現象を確認しました。
このような何層にも連なる画像コピーファイルのディレクトリが生まれて、テストするたびに更新されています。
f:id:kiryuanzu:20180130133022p:plain
テストする際に大きな問題はないかもしれませんが、余分なディレクトリが毎回生成されるのは邪魔なので、生成されない方法を考えたいと思います。

どこかに手がかりはないかな〜と思ってpaperclipの公式リファレンスを見ることにしました。
github.com
Testingの章を探っていくと、似たような問題に言及している記述が。

Integration Tests

Using integration tests with FactoryBot may save multiple copies of your test files within the app. To avoid this, specify a custom path in the config/environments/test.rb like so:

Paperclip::Attachment.default_options[:path] = "#{Rails.root}/spec/test_files/:class/:id_partition/:style.:extension"
Then, make sure to delete that directory after the test suite runs by adding this to spec_helper.rb.

config.after(:suite) do
  FileUtils.rm_rf(Dir["#{Rails.root}/spec/test_files/"])
end

ここでは、FactroyBotを利用した際にテストファイルのコピーが発生するのでそれを避けるためにコピーファイルを指定のディレクトリに生成したのちにテストが終わったらファイルを削除する記述のやり方を教えてくれているようです。
rspecによる書き方ですが、minitestの構文に書き換えて同じことをやってみたらなんとかなりそうですね。

Railsテスティングガイドを見ていくと
Rails テスティングガイド | Rails ガイド

 # 各テストの実行直後に呼び出される
  def teardown
    # @article変数は実際にはテストの実行のたびに直前で初期化されるので
    # ここで値をnilにする意味は実際にはないのですが、
    # teardownメソッドの動作を理解いただくためにこのようにしています
    @article = nil
  end

teardownを使うことで各テストの実行直後にメソッドを呼び出すことができることがわかりました。

なので、config/enviroments/test.rbに

 Paperclip::Attachment.default_options[:path] = "#{Rails.root}/minitest/test_files/:class/:id_partition/:style.:extension"

と記述してminitestのディレクトリにコピーを生成するようにし、
テストを実行するファイルに

def teardown
   FileUtils.rm_rf(Dir["#{Rails.root}/minitest/test_files/"])
end

と記述し、指定したファイルをテストの度に消すようにしました。(FileUtilsはrubyのメソッドでファイルを消したり、他にも様々なことができるメソッドです)

そのように記述することで、無事不要なディレクトリが生成されることはなくなりました。いい話。

期末試験を終えての振り返りと法学部の試験勉強のやり方

桐生あんずです。先週の土曜日から始まっていた大学の期末試験が終わりました。

1週間プログラミングに関わることはお休みして大学の試験勉強&本番の試験という流れをずっとやっていたけれど、政治学や、日本史、法学などを中心とした法理念や学説を叩き込む勉強が中心だったのでプログラミングのことをやりたいのにやれないストレスもあいまって気が狂いそうになっていました。

大学4回生にもなり、試験への耐性もついてきた…と思いたいのですが毎回心も体も疲弊してしまうのであんまりついてないと思います。でも、試験のための勉強のやり方はなんとなく身に付いてきたかもしれません。
最近、周りをみていると法学部でいることの苦しみを語る若い後輩がたくさんいて1,2回生時代の自分ととても重ねてしまい辛い気持ちになります。その後輩たちのためになるかはわからないのですが、今回はどう勉強していったら法学部でも単位をうまく取ることができるのかを先輩からの伝聞や自分の経験を元にしつつ、簡潔にまとめていくエントリにしたいと思います。

大学にうまく馴染めなくて単位が取れない人のための単位取得メソッドっぽいエントリは1年近く前にも書いたのですが、今回はその続編的記事として読んでいただけたらと思います。(今更ながらタイトルだけ読み返して思い出したけど私って去年までは卒業できるかすら分からないレベルだったんですね。泣けてきた。)
kiryuanzu.hatenablog.com
前回は「難易度の高そうな試験科目をやらず、出席点やレポート点の多い科目を狙っていこう」という趣旨の話メインでしたが、人間どうしても試験を受けないと単位がもらえない時期がきます。ということで今回は試験科目メインの対策を考えていきます。
そんな感じで、箇条書きで自分が今回行った試験対策を紹介していきます。 (これは、あくまでも私のやり方なので相性が合わない法学部生はいると思われます。そこはご理解お願いします。)

・一夜漬けをやめる

単位がなかなか取れない法学部生のみなさま、普段どのように勉強をしていますか。これは私の予想にすぎないんですが単位を落としまくる6割くらいの人たちは一夜漬けして頑張ってみたけど残念ながら取得できなかった人たちなんじゃないかと思います。ぶっちゃけると私がそうです。

もちろん、暗記中心の科目で覚えることが少なかったり、試験問題が確実にわかっている科目でしたら一夜漬けでも十分乗り切れると思います。ただ、私が通う大学の法学部の専門科目は試験範囲が超曖昧かつ膨大なことが多いです。これを一晩でやるのは専門知識が元々ある人or要領がいい人以外ではないと普通に単位をもらうことは無理だと気づきました。そして私は要領が良くないです。

正直、大学で勉強する内容は人生において役に立つかわからない科目が多いです。第一次世界大戦の独ソ関係を覚えたところで将来役に立つことってほとんどなくないですか。だから、やる気が湧かずギリギリになって一夜漬けで頑張って覚えようとします。でも結局ヤマをかけていたところが出ない時もあるし、ここは出ないだろと思って勉強しなかったところが出ることもあります。そのような事態を考えると、どんなに学ぶ意味が見出せなくても最低でも3日、最長で1週間前から覚え始めることが私にとっての単位を取る鍵なのかもしれないと気づきました。

なので、今回は最低でも3日前から授業のレジュメを読み込んでまとめる作業を始めることにしました。結果的に、これ覚えられるのかな?と思っていた単語や判例が意外に頭の中に残ってて、そのような勉強方法で挑んだ科目の試験に関しては白紙答案で出すことは今回一切ありませんでした。
というわけで、一夜漬けで単位が取れない人は1週間~3日前からレジュメを読み込んでまとめる作業をやってみましょう。当たり前の話っぽいけど単位が取れないということは今の勉強方法が間違っているか先生が鬼畜かのどちらかです。一夜漬けができない脳であることを受け入れて試してみてください。(もしかしたら周りの友達に一夜漬けで乗り切る人が結構いるかもしれませんが、そういう人は法学についての予備知識があるか要領が良くて頭のいい人たちなので参考にしないほうがいいです。)

チームプレイをしよう

上述のエントリでも述べたかもしれませんが、私は授業に関することで人に頼みごとをするのがめちゃくちゃ苦手です。人の努力を利用して自分が楽をしているのではという罪悪感が湧いてくるからです。ただ、どうしても一人で授業を受けて試験勉強するのは難易度が高い時があります。そういう場合、やっぱり一緒に授業を受けている知り合いがいるかいないかで大きく変わるんですよね。4回生になったということもあり、来年度中に卒業も就活もできないとまずいので申し訳ないながらも今回は後輩や同期に頼る行いを増やすことにしました。

だけど、頼るだけなのは忍びない…ということで先輩からもらった楽単リストや過去問を後輩や同期に情報提供しつつ、見せてもらうといったトレード交換っぽい感じにして罪悪感を減らしました。実際、そうやって互いに協力することでお互い頼りやすくなって情報交換もしやすくなります。私みたいに罪悪感をこじらせて人にお願いするのが苦手なタイプの人は先に交換条件として何か情報を所持しておきましょう。

これも当たり前すぎる話だと思うんですが、難易度の高い試験科目の場合授業のレジュメが1回分ないだけでも致命的な場合があります。授業に行って自分でレジュメを手に入れ書き込むことが一番気持ち的には楽なんですけど、文化祭の準備で忙しくなる、具合が悪い時、等どうしても授業にいけない時は出てくるのでその時は人に頼るのが単位を取るためには大事な取り組みです。そのお礼に情報交換をしたりお菓子をあげるとWin-Winな人間関係が築けるかもしれません。

過去問をやろう

正直過去問をやるかやらないかで試験対策ってめっちゃ変わってきますよね。過去問の問題形式を見つつ、レジュメのどの部分を重点的に覚えていくかを探る作業が試験勉強において超重要です。だから過去問をチェックしないのは論外です。
あと、気づいたんですけど授業を取り始めた時から大学のmanabaページから先に過去問をプリントアウトしておいて、過去問の中身をチェックしつつ授業を受けたら重要ポイントを理解するにおいてめちゃくちゃ効率いいのでは?来期試してみます。

丸暗記は極力しない

私は割と丸暗記は好きなんですが、ぶっちゃけコスパ悪いし法学部の専門科目に向いている試験科目ではありません。でも別に暗記が悪という訳ではないです。問題をコスパよく解くためには記憶力が必要です。

法学部の専門科目の場合、制度趣旨や判例、学説を覚えることがメインだと思われます。正直私は数年前まで覚えると言ってもどう覚えたらいいかわかりませんでした。そんな中、プログラミングの勉強を趣味でやり出してしばらくした時、プログラミングの勉強と法学の勉強は結構共通点があることに気づきました。

プログラミングの場合、教本やチュートリアルをこなして写経するのは確かに勉強になるけどコードを丸暗記するだけなのはあまり大きな意味はなくて「このメソッドやこのコードの流れはどういう意味合いがあってどういう時に使うことができるか」を念頭に考えて理解する学び方が大事だと思います。これは法学も一緒でただ虚無になって条文を覚えるよりも。「どんな問題が出てきた時にどんな制度を使って、どんな判例を持ち出してどういった主張をもってどう解決すべきなのか」をイメージしながら制度趣旨や判例を覚えるとするっと頭の中に入ってくることがわかりました。
つまり法学部の専門科目の単位を取るためには高校でやったような歴史、政治経済、倫理の科目でやったようなただ事実を丸暗記していく解き方とかなり相性が悪いのです。
ということで、「この問題を対処するためにはこの武器(制度趣旨、判例、学説)が必要だ」とイメージして覚えていくと重点的に覚えたほうがいい判例や学説、制度が見えてきます。
例えば、売買契約で商品に隠れた瑕疵が発覚した問題が発生したときをイメージしてみましょう。損害賠償請求をするためには瑕疵担保責任を求めることになるけど、特定物か不特定物かを検討しなきゃとか、法定責任説か契約責任説をとるかどうかとか、そもそも売主に帰責事由はあるのか、とか問題を解くにおいて必ず考えるべき要点に触れることになるのです。そのような要点理解がいわば所持すべき武器であり、テストでもちゃんと書けるぐらい覚えるところなんだと思います。

要は自前の論理思考能力を駆使しつつ問題に対抗するための要素を把握しとけ〜って話ですね。自前のパワーも大事だけどそのためにはやっぱり覚えることが大事です。
法学部の場合、覚える内容が専門的なことが多いため勉強量を増やさないとどうしても単位が落ちる結果になってしまうんだと思います。辛い。

おわりに

法律系専門科目に試験に苦しむ法学部のみなさま、参考になりましたでしょうか。
ちゃんと単位をとってる人たちからしたら「当たり前すぎるでしょ」といった話ばかりだと思います。また、この方法を使わずともゴリ押しで単位を取ることだってできると思います。ただ、効率よく安定して試験で単位を取るためには人の力を借りたり暗記の仕方を工夫しないと難しいなあとこの1年で気づきました。
成績発表がくるのは3月はじめで、一体どうなってるか謎ですが4回生補正の力も加わってちゃんと単位がもらえていたら嬉しいです…。(結局補正頼み)
単位取得に悩む、法学部の方々も法学部ではない方々も頑張っていきましょう。ではでは。

HTMLのタグの中身をRailsのminitestを使って確認する書き方

桐生あんずです。
先日インターン先でSEO対策のために記事の詳細ページなどのmetaタグの中身(descriptionやog、TwitterCardsなど)を動的に変化させるコードを書きました。*1
Chromeの検証のおかげでちゃんと中身が変化していることはわかったけど、「せっかくだからテストコード書きたいよね〜!」という指令が出たので、Railsのminitestを使ってちゃんとmetaタグの中身がページ別に反映されているかどうかをチェックするテストコードを書くことになりました。
なおテストコードを自分で書くのはこれが初めてです。頑張っていきましょう。
Railsのバージョンは5.1.2、Rubyのバージョンは2.4.1です。
まず、Railsチュートリアルを参考に見ていくとふむふむ、「assert_select 」を使って対象のタグ名をチェックするんだな…?

assert_select "title", "Home | Ruby on Rails Tutorial Sample App"

じゃあ、これをmetaで置き換えてname属性の中身やproperty属性の中身を確認していけばいいじゃん!やってみよう!
と思ってまず書いてみました。

test "should be able to show topics meta tag" do
  get topic_path(topics(:one))
  assert_select "meta", {:property =>/og:title/, :content => /test/}
  assert_select "meta", {:property => /og:description/, :content => /hogehoge/ }   assert_select "meta", {:property => /og:url/, :content=>/topics_path(:one)/}
  #oneはfixtureで既に用意されたインスタンスのデータ
  assert_select "meta", {:name => /twitter:title/, :content => /test/}
  assert_select "meta", {:name => /twitter:description/, :content => /hogehoge/}
  assert_select "meta", {:name => /description/, :content=> /hogehoge/}
end

そしてテストしてみる。
通った!やったー!完!
で、終わると思ったか?
minitestに詳しい方はわかると思いますがこれは残念ながらザルテストです。content属性の中身が目的のもの以外になっていても通ります。理由はちゃんとわかりませんが、予想ではproperty属性やname属性の中身が合っているとそれでOKと判断されてしまうとかなのかなあ。

そこで、いい感じに判定してくれる記述はないものかと漁っているうちに。
効率的な動作確認の方法を求めて - ザリガニが見ていた...。
こんな記事がありました。(10年前だ…)
投稿時期はかなり古いですがもしかしたら何かヒントはあるかもしれないと思ったので探してみます。(探していてわかったことですが、minitestに関わる文献は日本語の新しい記事がめちゃくちゃ少ない。厳しい。)

assert_select "form input[name=slip][id=slip-1]"
  # formタグ以下に、name="slip"属性とid="slip-1"属性の両方を持つinputタグが存在すれば成功。
  # 複数の属性を指定可能。指定した全ての属性を持っていれば成功。

これで両方の属性をちゃんとテストすることができるのでは!?
やってみましょう。

test "should be able to show topics meta tag" do
  get topic_path(topics(:one))
  assert_select 'meta[name*=?][content*=?]', "description","hoge", { :count => 2 }
  assert_select 'meta[name*=?][content*=?]', "twitter:title","test", { :count => 1 }
  assert_select 'meta[name*=?][content*=?]', "twitter:description","hoge", { :count => 1 }
  assert_select 'meta[property*=?][content*=?]', "og:title","test", { :count => 1 }
  assert_select 'meta[property*=?][content*=?]', "og:description","hoge", { :count => 1 }
  assert_select 'meta[property*=?][content*=?]', "og:url","#{topics(:one).id}", { :count => 1 }
end
#[content*=?]という書き方で、指定した文字列がcontent属性の中身の一部に含まれているかどうかを探すことができる

ここで、細かい確認をするためにもbyebugをassert_selectの前に書き、指定したページのname属性やproperty属性の中身を確認しておきましょう。byebugが起動した際に「response」と入力すれば指定したページのviewの中身を確認ことができます。

確認したのちに、テストを動かしてみると…、無事通りました。
確認として、間違った中身を入れてみるとちゃんと失敗してくれます。本当によかった。
指定したHTMLタグの複数の属性の中身を確認したい場合、このような記述でテストコードを書けば良いことがわかりました。
初めてテストコードを書いたこともあり、ここまでいくのに4時間ほどかかりましたが、学ぶことはかなり多かったです。記述の調べ方もちょっとだけわかった気がするので新しいテストコードをどんどん書いていきたいです。
初めて技術記事っぽいものを書いたのでちゃんと書けているか緊張していますが、読んでいただいた方ありがとうございました。

おまけ contentの中身の画像URLの確認の仕方


まだ気になることがある方がいると思います。og:imageやTwitterCardsのcontentの中の画像URLが合っているどうかも確認したいですよね。
そこで、画像URLの中身を確認するテストを別に書くことにしました。

  test "should be able to show topic meta image tag" do
    log_in_as(@user)
    image = fixture_file_upload('test.jpg', 'image/jpg')

    assert_difference 'Topic.count', 1 do
      post topics_path, params: {topic: {title: "hi", content: "message1", category_id: 1, photo_attributes: {image: image}, user: @user}}
    end
    
    topic = assigns(:topic)
    assert_equal "test.jpg" , topic.photo.image_file_name
    get topic_path(topic)
    assert_select 'meta[content*=?]', "test.jpg", { :count => 2 }
  end
#topicモデルとphotoモデルの関係は1対1

paperclipで画像を生成している際の書き方です。
fixture_file_uploadで画像をテスト内で生成します。
また、fixturesのフォルダに同名の画像ファイルを突っ込んでおかないといけません。
assignsでオブジェクトを取得した後、ちゃんと画像が入っているか確認。
その後テストしたいページで、先ほどの記述と同じようにcontent属性の中に指定した画像ファイルが含まれているかどうかを確認。(:count => 2になっているのはog:imageとtwitter:imageの2つを確認したいから。)
これで画像の中身が動的に変化しているか確認できます。ありがとうございました。

*1:metaタグを動的に変化させるやり方の一例はこんな感じです。 【Rails】『meta-tags』gemを使ってSEO対策をおこなう方法 | vdeep

最近買ってよかった化粧品とか

桐生あんずです。

自分が今使っている化粧品の中で、思い切って買ってみたら「これ結構使い心地よいなあ」というものが何個かあるのでゆるい感じに紹介します。

 

ガールズメーカー エタニティアイテープ 

今まではAB(オートマティックビューティー)のダブルアイテープを貼って、アストレアビルゴのアイビューティーフィクサーWP(アイプチ)を上から塗ることで二重を形成していました。ただ、手間がかかるのと適当に化粧を落とすと目の上にのりが残りやすいことが悩みでした。

ちょうどアイテープが切れた時に、ダイコクドラッグで何か良いのないかな〜と探してたらこの商品がありました。

何が良いかというとアイテープだけでちゃんとした二重が作れる。そしてお風呂に入っても崩れないぐらい強い。

しかもかなり自然な二重が作れます。アイプチやアイテープを使ってる人たちの悩みってつけてる間に「不自然に見える」「時間が経つと取れる」「運動や入浴など何かの拍子で取れそうになる」の3つで分類できそうな気がします。(あとはかぶれる、まぶたが伸びてしまうなど使用後のリスクも悩みとして考えられます)

その3つの悩みを一気に解決してくれたのがこのアイテムなので二重形成メイクに悩んでる方はこれを試してみてください。値段は他のアイテープよりちょっと張りますが相応の価値はあるな〜と思います。

ガールズメーカー エタニティアイテープ

ガールズメーカー エタニティアイテープ

 

http://www.cosme.net/product/product_id/10117626/top

 

KATE ダブルラインフェイカー

1年前あたりにTwitterでバズった時に即買いしました。コスプレイヤーさん御用達コスメという印象があります。これを二重幅に引き、その後涙袋のラインを擬似的に作るだけで目の印象がかなり変わります。時間がなくてメイクが適当な時でもこれは必ず使ってしまいます。目を大きく見せたい人はかなりおすすめです。ただ、涙袋を濃く作りすぎるとちょっと違和感が強くなるので気をつけてください。

 

http://www.cosme.net/product/product_id/10097426/top

エチュードハウス ディアガールズオイルコントロールパクト

 なんとなくエツードハウスって呼びたくなる韓国のコスメブランドです。

完全に見た目が可愛いという理由で買ってしまったんだけど、肌を綺麗に見せられるのでおすすめです。あと、見た目が可愛いというだけで持ち歩いてて楽しくなるよね。あとエツードハウス全体的に安いですよね。最近よく使ってるカミソリもエツードハウスのやつです。

f:id:kiryuanzu:20180115223553j:plain

http://www.cosme.net/product/product_id/10067651/sku/836645

(Amazonのリンクはなぜかうまく反映されなかった…)

OPERA ティントオイルルージュ

メンソレータム リップフォンデュ

口紅って本当にたくさんブランドがあって、なんかティントだったりグロスだったりややこしくて実はあんまり手を出してない領域です。その中でも、OPERAはやっぱり安定感あって好きです。メンソレータムのリップフォンデュを加えるとぷるぷる感が出るし荒れにくいので個人的におすすめです。

 

 

http://www.cosme.net/product/product_id/10119418/top

メンソレータム リップフォンデュ スカーレットピンク 4.2g

メンソレータム リップフォンデュ スカーレットピンク 4.2g

 

http://www.cosme.net/product/product_id/10065848/top

 

普段使ってる中でも人におすすめしたいコスメはこんな感じです。また使い心地が良さそうなコスメが見つかったら紹介しますね。