Ruby on Rails開発のインターン （Day 33）
こんにちは、皆さん！
今日、今週が結構タフになりそうだと気が付いた。いろんな仕事が重なり、土曜日まで忙しいという。まあ、でも、少し多くお小遣いが稼げるからよいことにしよう。でも、Railsとあと良ければReactJSを学習する時間も確保したい。できるといいけど．．．。
- トピック：
- 疑問：
- 問題：
- 学習した内容：
inputタグのacceptの値を設定することでアップロードできるファイル形式を決めることができる
- 今後やってみたいこと：
- リソース：
inputタグのaccept属性の値を設定する
inputタグに制限をつけようとした。そして、少し検索した結果、accept属性をつけ、".csv"と指定することで達成できることが分かった（僕の場合はRailsだったからfile_field_tag内に入れた）。下記のが僕ので成功した内容：
<%= file_field_tag :file, accept: '.csv' %>
これが普通のHTMLだと下記のようになる。
<input type="file" accept=".csv">
正直、ファイル形式を制限するのがこんなに簡単だとは思っていなかった。これでユーザーが他のファイル形式のファイルをアップロードしたときに出すエラーを考える必要がおそらくなくなった。
まとめ
ご精読ありがとうございました。では、また次回まで✌
Ruby on Rails開発のインターン （Day 32）
こんにちは、皆さん！
ついにインターンの最後の週がやってきた。結構な期間があったけど、やっぱりあっという間って感じだったね。
以前他の部のマネージャーが僕に新しいウェブサイトのデザインを準備しておくから、やってほしいと頼まれた。当時はまだ2週間あったからいいですよと答えたのだが、最後の1週間になった今、まだデザインが届かないのは果たしてどういうことだろうか．．．。今日もオフィスに行ってみると、そのマネージャーは来ていないし(笑)
- トピック：
- 疑問：
- 問題：
- 学習した内容：
- 今後やってみたいこと：
- CSVファイルのアップロードに関する記事を書く
- リソース：
CSVファイルをアップロードしてデータを作成する
.csvファイルをアップロードして、中のデータをRailsアプリにインポートすることができるだなんて知らなかった。僕はただこのサイト通りにコードを書いただけでそれができた。このサイトは本当によくまとめられていると思う。
いずれ完全なRailsでの実装方法をまとめるつもりなので、ここではcsvファイルについて基本的なことを少し説明しようと思う。
最初に、このタイプのファイルの構造はエクセルと大変似ている。行と列があり、それぞれでできた枠の中に数値や文字を入れる。しかし、もし、VScodeなどの枠に対応しないエディターで開くと、それぞれの要素の間にコンマを入れて、違う枠に入っていることを示さなければならない。
いいことは表と同じようにそれぞれの列が何を表すのかを示すヘッターは最初の1行だけでいいということだ。
例えば下記のように
id,name,age 1,Alisa,18 2,Nick,23 3,Bob,21
# ヘッターの一つ一つの名称はデータベースのそれと完全に同じである必要がある#
VScodeで書いたときに上記のようなcsvファイルを書く。これで、もし、このファイルをアップロードしたのなら、アプリ内でそれぞれの行を1行ずつ処理し、与えられた年齢とともに3人のユーザーがデータベースに登録される。
これはユーザーにとっても、アプリの管理人にとっても、とっても便利な機能となるので、データを扱うのなら絶対に実装したい機能だといえるしょう。
まとめ
仕事の後、家に帰ると、UBCでのパートタイムの仕事の面接を行いたいとメールが来ていた。前回たくさん応募したのに一つも返ってきたことがなかったし、学校という家に近いところで仕事ができるのですごく嬉しかった。うまくいくといいなーー！
ご精読ありがとうございました。では、また次回まで✌
Ruby on Rails開発のインターン （Day 31）
こんにちは、皆さん！
今週も最終日！！これでこのインターンも残り1週間ってところ。時間がたつのは本当に早い。そろそろ次に学校に行きながらできる仕事を探し始めないとな。
今日はcsvファイルをユーザーにアップロードさせるときの関数を設計していくところから始める。
- トピック：
- 疑問：
- 問題：
- 学習した内容：
- 今後やってみたいこと：
- リソース：
フローチャートを描くツール
この投稿ではマネージャーから紹介された2つのフローチャートを描く無料のソフトウェアについて紹介する。
最初のものはLucidchart。
これはマジですごい！！ソフトウェア内に様々な形のものがあり、ドラッグアンドドロップでサイドバーの中から図の中に取り出すことができる。そして、図に出した後、それぞれの図形の中に2つのマウスで動かせる部分があり、それぞれ矢印と図形の大きさをコントロールする赤い点と青い四角形である。下記のはそのスクショの一部である。
この機能によっていちいちサイドバーから矢印を選択したりなどの作業をしなくていいから効率性が増す。
さらに、グーグルドライブと同期することでこのソフトウェアで作った作品を他の人とシェアすることができる。
しかし、1点残念なところがある。無料アカウントを使う限り、3つまでしかグラフを描くことができないことだ。1年分払うのなら1か月＄4.95、月払いなら＄5.95と少し値は張る。まあ、それでも個人的にはフローチャートを多用するのなら2つ目のものとの機能性を比較して考えると、全然得するレベルだと思う。
2つ目はグーグル図形描画。これは完全無料の優れもの。そして、Chromeでサインインした状態なら自動的にグーグルドライブに保存される。そして、グーグルドライブに保存されるということは複数人で同時に編集することができるということでもある。
しかし、このソフトウェアを使うのなら、ナビゲーションバーのアイコンをいちいちクリックして、マウスでできる機能を変更する必要がある。例えば、「挿入」ボタンを押して、「図形」を押して、初めて、選びたい図形が選べる。これはLucidChartに比べると、かなり作業効率が低い。さらに、LucidChartと違って、矢印と文字の重複が発生するため、文字を矢印上におくと、文字が見にくくなる傾向がある。
それでも、そのシンプルなデザインと簡単なナビゲーションバーにより、こっちのインターフェイスを気に入る人もいる。あと、複数人で同時に編集できるという恩恵は大きい。
グーグル図形描画を使うかは一人当たりの効率性と複数人による作業の可能という2つの要素で判断するといいでしょう。
まとめ
ご精読ありがとうございました。では、また次回まで✌
Ruby on Rails開発のインターン （Day 30）
こんにちは、皆さん！
さーて、今日は職場のプログラムのテストで使われているfactory-girlというジェムの詳細を読んで、使えるようにするところから。
昨日、自分のウェブサイトを完成させたので、今は少しほっとしていて、仕事に集中できると思う。
- トピック：
- 疑問：
- 問題：
- マップテスト用のデータを効率的に定義する方法を見つける（
factory_botジェムで解決）
- 学習した内容：
factory_botジェムのテンプレートを作る方法
- 今後やってみたいこと：
- リソース：
factory_botジェムとは？
factory_botジェムはデータを作るときのテンプレートを作成してくれるもの。これはたくさんの一時的なデータを作るときに役に立つ。 簡単な例を挙げると、
# spec/factories/user.rb FactoryBot.define do factory :user do name "Bob" email "bob@example.com" admin false end end
こうして、定義した後、任意のspecファイルで下記のようなコードを書くと、
user = create(:user)
"Bob"という名前で"bob@example.com"というメールのユーザーを簡単に作れちゃうというわけだ。
これは下記のコードを実行するのと同じことをしている。
user = User.create(name: "Bob", email: "bob@example.com")
これでどれだけのコードを省くことができたのかが分かるでしょう。特に、これを何度も繰り返せば、その分だけ、このジェムの効力も大きくなる。
factory_botの始め方
gem "factory_bot_rails", "~> 4.0"
そして、bundle install
そしたら、設定のセットアップとして、下記のファイルを作成して内容を入れる。
# spec/support/factory_bot.rb RSpec.configure do |config| config.include FactoryBot::Syntax::Methods end
Railsを使わない場合はこちら↓↓
# RSpec without Rails RSpec.configure do |config| config.include FactoryBot::Syntax::Methods config.before(:suite) do FactoryBot.find_definitions end end
そしたら、specファイルがこの設定を使えるようにするため、下記のようにrails_helper.rbにファイルのインポートを入れる。
require 'support/factory_bot'
そしたら、データを作る準備はできたので、下記の簡単な例を試してみよう（始める前にUserのモデルが必要だが）
# spec/factories/user.rb FactoryBot.define do factory :user do name "Bob" email "bob@example.com" admin false end end
そしたら、Rspecのテストコード内で下記のように実行するだけ。
user = create(:user)
これで、もともと定義した通りのユーザーをデータベースに追加できる。
factory_botジェムを効率的に使う方法
factory_botジェムを最大限に利用するには、先ほどのように定義したデータにさらにケースごとに必要な部分だけを追加したデータを作る必要がある。下記のコードの例では、アドミンにするかどうかというケースを設置した。
先ほどの例に下記のようにコードをつけ足すと、アドミンのケースが完成する。
# spec/factories/user.rb FactoryBot.define do factory :user do name "Bob" email "bob@example.com" admin false trait :admin do admin true end end end
factory_botのおかげで、アドミンユーザーを作るときに変更する必要のない元から定義された名前とメールを再定義することなく、使用することができる。なので、アドミンの場合は、一つだけしか定義するコードがない。
そして、これを使うためには、ただ下記のようにすればよい。
admin_user = create(:user, :admin)
これで、下記のと同じことをしたことになる。
admin_user = User.create(name: "Bob", email: "bob@example.com", admin: true)
このようなケースがいくつも存在するとしたら、いったいどれほどのコードを省くことができるのでしょうか？
このジェムはマジで役に立ち、特に大きなプロジェクトで使うことによって、その真価を発揮するのだ。
まとめ
ご精読ありがとうございました。では、また次回まで✌
Ruby on Rails開発のインターン （Day 29）
こんにちは、皆さん！
今日はなぜCapybaraテストでドロップダウンをクリックできないのかを調べるところからスタート。それと、どうやって効率的にテスト用のデータを作るかだな。今日はどのくらいできるのか見てみよう。
- トピック：
- 疑問：
- なんでわざわざブラウザではドロップダウンの形式を変えてくるのだろうか？
- 問題：
- Capybaraテストからドロップダウンをクリックすることができない
- コンソールで作ったデータがテスト時に消えている
- 学習した内容：
- 今後やってみたいこと：
- リソース：
僕がどうやってCapybaraテストからドロップダウンをクリックしようとしたのか
今回はドロップダウンの中身を見ていくのだが、面白いことに、ドロップダウン自体は一つのボタンであり、その内容は下記のようにoptionタグで定義したのにもかかわらずそうではなかった。
<select id="gender"> <option id="option" value="male">Male</option> <option id="option" value="female">Female</option> </select>
それで、ディベロッパーツールで見たのだが、下記のようなものが出ていた。
つまり、optionタグ内に定義されたドロップダウンの内容はoptionタグの中にはもはや存在しないので、他の方法でliにアクセスする形でアクセスする必要がある。
幸運にも、Capybaraテストのfind()関数はCSSのセレクターと同じようにHTML要素を選択できるので、どこにそのドロップダウンの内容が隠れているかさえわかればよかったのだ。
ドロップダウンに関しては、もう一つ問題があった。僕たちが実際にドロップダウンから選択したい選択肢を選ぶときにそのドロップダウンをまず開く必要があるのと同じように、Capybaraテストでもそれを開くところから始まる。ということで、まず、Capybaraテストにドロップダウンのボタンを押すように指示した。
クリックする前：
クリックした後：
クリックした後に、選択肢の内容部分が色を変えて、有効になっているのが分かる。
なので、下記のようにボタンにクリックし、
find('button.dropdown-toggle').click()
そして、二個目の選択肢を下記のように選んだ。
find('ul.dropdown-menu li[data-original-index="1"]').click()
このCSSセレクターが見づらいのはわかる。単純に言うと、二つある順序のないリストの二つ目を選ぶという意味だ。
よって、ドロップダウンの二つ目の選択肢を選択するためのCapybaraテストコードは僕の場合、下記のようになる。
# Choose female from the dropdown find('button.dropdown-toggle').click() find('ul.dropdown-menu li[data-original-index="1"]').click()
完璧！今日もまた一つ問題を解決した。
まとめ
ご精読ありがとうございました。では、また次回まで✌
Ruby on Rails開発のインターン （Day 28）
こんにちは、皆さん！
今日はマーカー変数を効率よく定義する方法を探して、もう少しスマートにテストを書いていけるようにする。あと、マップ上でマーカーをフィルターする方法とそのときに使うチェックボックスとラジオボタンをCapybaraテストでどうやってコントロールするのかも勉強しないとな。
- トピック：
グーグルマップ上でマーカーをフィルターする方法
Capybaraテストでセレクターを使ってHTML内のものをアクセスする
- 疑問：
- 問題：
- マップ上にマーカーがいくつあるのか数える方法を探す必要がある（解決）
- 学習した内容：
- どこをどうやって変えることでマップ上でマーカーをフィルターすることができるか
- 今後やってみたいこと：
- マップだけでなく、自分のプロジェクトでもフィルターを実行する
- グーグルマップ上でマーカーをフィルターする方法に関するブログを書く
- リソース：
グーグルマップ上でマーカーをフィルターする方法
Advanced Google Maps with JavaScript: Filtering and Displaying Information | appendTo
このサイトのおかげでマップ上でフィルターする方法をだいぶ楽に理解できた。
はじめに、まずはJavaScriptをユーザーの選択次第で実行してHTMLのチェックボックスやラジオボタンの状態の変化に対応する必要がある。次に、フィルターされたシチュエーション次第でそれぞれのマーカーを表示するのか、それか非表示にするのか決める必要がある。
CodePenのこのサイトのコードを見ていくと、次のようなことが分かった。
サイト上のシステムはこうやって動いていた。
- 一つの配列にハッシュの形でそれぞれのシチュエーションをブーリアン型で入れて、そのシチュエーションでフィルターしているかどうかを記録する。マーカーはぞれぞれ自身にシチュエーションごとにその条件を満たしているかどうかをブーリアンで決めている。もし、ユーザーがフィルターの選択肢のどれかをクリックしたら、配列内のその値の真偽がひっくり返るという感じ。
- クリックした後、配列内の値が変わり、マーカーを一つ一つ見ていき、そのマーカーが配列内の条件を満たしているかどうか見る。この場合は配列内のすべての真のシチュエーションに対して、そのマーカーがそのすべての真のシチュエーションにおいて真であるのなら表示する。
setVisible(arg)関数を使ってマーカーが見えるかどうかを調整する。
こうやって、箇条書きで書きだすと長いコードもだいぶわかりやすくなってくる。でも、それぞれの動作をするのにさらに複雑に関数が絡み合っている印象を受けた。
これに関しては内容も深いわけなので、のちにブログを書きたいなと思っている。
Capybaraテストでセレクターを使ってHTML内のものをアクセスする
少し探してみたら、下記のようにコードを書くのが簡単だと思った。
page.should have_css('h1', :count => 1)
この例はページ内に一つだけh1タグがあることを確認する。多くても、少なくてもダメで、必ず一個だけ。
もうお分かりだと思うが、カッコ内の一つ目がどんなHTML要素を探すかで、二つ目がどれだけあるかである。なので、"center"というクラスを持つ要素がちょうど二つあることを確認したいのなら、
page.should have_css('.center', :count => 2)
またCSSで要素を選択するように書くこともできる（というかそれが本質）
# <div><div class="center"></div></div> page.should have_css('div div.center', :count => 1) # <input type="submit"></input> page.should have_css('input[type="submit"]', count => 1)
これのおかげでマーカーにたどり着くためのCSSのセレクターを見つけることができた。この例はマーカーの写真を選択するというもの。
（後日、別のものに変更した。たまにセレクターが変わることがあるっぽいのでディベロッパーツールでしっかり確認しよう。）
page.should have_css('div.gmnoprint img[src="/assets/default-map-marker-0ec32d1d8c746e755dc1207a63f227cb519433ad4879170711c8d2bc66e1c997.png"]', :count => 1)
他の選び方も試したが、見えないものの重複があって、数が合わなかった。で、結果的にこれになった(笑)
まとめ
それで、プログラミングに話を戻すと、グーグルマップ上でマーカーをフィルターする方法とマップ上のマーカーの数を確認する方法について学んだ。これのおかげで僕のマーカーのテストを一つ上のレベルまで押し上げてくれた。只今、なぜかわからないが、Railsのコンソールを開いて作ったマーカーがテストを始めると消えているので、そこら辺について、明日も頑張っていこうと思う。
ご精読ありがとうございました。では、また次回まで✌
Ruby on Rails開発のインターン （Day 27）
こんにちは、皆さん！
7週目がやってきた。インターンも残りわずかだ。もうあと2週間だから時間も限られている。今やっているマップテストをどこまでやるべきなのかもよくわからない。思い返すと、このインターンはすごくよかったし、思っていたよりずっと短かった気がする。時間がたつのって本当に早いね(笑)
- トピック：
- 疑問：
- 問題：
- 学習した内容：
- テストが始まる前に変数をあらかじめ定義する
- 今後やってみたいこと：
- リソース；
テストで使われる変数をあらかじめ定義する
テストでこの機能を使おうと思ったのは、多くのシチュエーションがあり、それぞれに対するマーカーが必要だし、いくつかのテストで同じものを使いたいと思ったからだ。
少し探してみたら、下記のようなテンプレが出てきた
before(:each) do # your code here end
それで、僕は下記のを試した
before(:each) do place = Place.find(1) end
その後、テスト内でその変数を使おうとしたら、下記のようなエラーが返ってきた。
NameError: undefined local variable or method `place' for #<RSpec::ExampleGroups::TheSigninProcess:0x0055ddbc033078>
スペルミスはなかったのですごくおかしな感じがしたのだが、後になって、インスタンス変数しかこのような役割を果たすことはできないとわかった。つまり、あらかじめ定義しようとしている変数の前に@をつける必要があったのだ。よって、下記のが正しい。
before(:each) do @place = Place.find(1) end
これで僕の場合はうまくいき、同じ変数の定義を避け、コードがずっとよく見えるようになった。
まとめ
ご精読ありがとうございました。では、また次回まで✌
