cssだけでアコーディオン表示
HTML
上記のコードのみで、
ボタンクリックで姉妹要素がスルスルっと出てきて、同時にボタンのデザインも⬇︎から✖︎に変わる。
参考サイトはCSSだけでアコーディオンを作る方法(レスポンシブ&矢印付)です。
rubyのversionをrbenvで切り替える
まずrbenvを最新にする。
その後、現在ダウンロードできるversionを確認する。
新しいバージョンのインストールをする。
インストールできたら、切り替える。
確認する。
これでバージョンが表示されれば完了。
rails5, puma, nginx, debianを使ってデプロイ!最初から最後まで!
何度やっても忘れるので今度こそ最初から最後まで備忘録を書きます。
デプロイまとめ
1. ローカルで本番環境に流す
1-1. 今回のアプリケーションに必要になる本番環境でのDBと、ユーザー名とパスワードを設定する。
以上でユーザ作成は完了です。
ちなみに上記の場合は全てのデータベースとテーブルに対する全権限をrailsuserに付与していますが、特定のデータベースや処理を限定して権限を付与することも可能です。
1-2. データベース設定ファイル修正
今回は本番環境のMySQLにRails用のMySQLユーザとしてユーザ名がrailsuser、パスワードがmypasswordであるユーザを作成したのでこの情報をconfig/database.ymlに記述します。
1-3. 開発, テスト, 本番環境のデータベース、テーブル、seed-fuを作成
続いて開発, テスト, 本番環境のデータベース、テーブルを作成します。
上記コマンドを実行により、
- development環境用にRails_developmentという名前のデータベース
- test環境用にRails_testという名前のデータベース
- production環境用にRails_productionという名前のデータベース
がそれぞれ作成されます。
ここでproduction環境のコマンド実行時に1-1で設定したmypasswordをオプションとして付け加えること。
そうしないとエラーが発生する。
上記コマンドでマイグレイト, seedファイルの挿入。
1-4. assetファイルのコンパイル
コンソールで以下のコマンドを叩いてapp/assets以下のファイルをコンパイルします。
assets:cleanも一緒に入れておくと古いファイルも消しておいてくれて便利。
そして、動的にコンパイルできるようにセッティングします。
Rails.root/config/environments/production.rbを少し編集します。
上記に編集します。
こうすることにより、
サーバがリクエストを受け取った際、コンパイル済みのファイルが見つからない場合にその場でコンパイルを行う設定が可能です。
これならリポジトリへの登録は不要です。しかし動的コンパイルなので初回リクエスト時にはレスポンスが犠牲になります。
それが嫌なら、capistranoを使いましょう。
ここまでできたら確認しましょう。
これで無事に繋がれば第一段階は完了です。
2. nginxとpumaでデプロイする。
2-1. nginxの設定
2-2. pumaの設定
rails-root/config/puma.rb このファイルに
これを足すだけだ
ここまでできたら確認しましょう。
これでnginxで設定したポートで開ければここまでは完了です。
3. debianにデータを移す
3-1. railsアプリをdebianにコピーします。
これでデビアンにローカルファイルが全てコピーされました。
4. 本番環境の更新をする。
4-1. gitでバージョンを合わせる。
4-2. databaseを作成して、シードファイルを流す
4-3. プリコンパイル
4-4. サーバー起動
これで完成!
ドメインを確認してください。
スはスペックのス(model)をRspec3, Rails5でやってみた。
こちらの「スはスペックのス」なのですが、とても古い記事でして2018年にrubyの勉強をし始めた僕にとってはversionの観点から少し分かりづらい内容でした。さらにネットの情報も様々なversionで書かれた記事が混在しており、さらにやりにくかったです。
そんな中、頑張ってとりあえず全部やったのでメモとしてブログに上げます。
スはスペックのス(model編)
環境
0. 準備
インストール
RSpec のリリースバージョンは RubyGems で提供されています。
RSpec が無事にインストールされて、実行できることを確認しましょう。
1. 簡単な配列のテスト
まず最初にRailsを使ってテストをする前に簡単な配列のテストをして、雰囲気を感じましょう。
適当なディレクトリに array_spec.rb という名前のファイルを用意します。 RSpec によるテストコードのファイル名は接尾辞を _spec とする のが一般的です。なお、RSpecで振舞を記述したファイルのことをスペックファイルと呼びます。
スペックファイルには、次のようにスペックを書きます。
array_spec.rb
こちらのテストを読んでいくと、
まず最初にテストの内容です。
これは"配列が空のとき"と読めます。
次に、 テスト内容です。
これの"it"の部分から読んでみると、"それは空であるべきだ"と読めます。
次もテスト内容です。
これの"it"の部分から読んでみると、"それは0サイズであるべきだ"と読めます。
まとめると、
- 配列が空のとき、 describe 〜
- それは空なのか、 it "should be empty" do
- 配列の数は0なのか、 it "should size 0" do
これらをテストしているということになります。
RSpec を実行してみます。
examplesがテストの数で、failures
がそのうち失敗した数です。つまり、全てのテストは成功したということです。
2. Railsでmodelテストの作成
railsアプリケーションを作ります。
Blog modelを作成します。
たくさんファイルができます。
マイグレーションファイルを編集する。
ブログに名前が無いと困るので必須項目にしておきましょう。blogs テーブルの name 属性を null 不可にします。
db/migrate/001_create_blogs.rb
DBを作成する。
フィクスチャを編集する。
少し先回りになりますが、こちらを編集しておきます。
3. Blogのバリデーションのスペックを定義する。
spec/models/blog_spec.rb
ここで実行すると失敗するはずです。なぜならまだ Blogクラスにname属性を検証するような実装をしていないからです。
一応、実行してみます。
予想通り失敗しました。
Blogクラスに期待される振舞を実装する。
name 属性の存在を検証するように Blog クラスを実装します。
app/models/blog.rb
blog.rb の修正を保存して、再度 rspec を実行します。DBに変更は無いので、そのまま rspecコマンドを叩きます。
予想通り成功しました。
3. Entryモデルの作成。
次は Blog に投稿された記事を表現する Entry モデルを作成します。 ジェネレータの利用からフィクスチャの設定までは Blog クラスの場合と同様です。
Entryモデルを生成する。
Entry の属性にはタイトル、本文、投稿日を用意します。Blog と関連づけるため の外部参照キーや、管理用の属性として、タイムスタンプも定義します。
マイグレーションファイルを編集する。
必須属性を null 不可にします。
db/migrate/002_create_entries.rb
投稿日 (posted_at) を created_at や updated_at といった Rails が標準でサポート するタイムスタンプで代用せずに独立させて定義しています。
これは「Blog の記事の投稿日」として扱いたい日付が必ずしもデータベースレコードの作成・更新タイムスタンプと同じとは限らないためです。
DBを移行する。
development環境のデータベースを変更しましょう。
フィクスチャを編集する。
テスト用の投稿記事を用意しておきます。
spec/fixtures/entries.yml
4. BlogとEntryを絡み合わせたspecを定義する。
では実装に入ります。今回作成するブログアプリケーションのモデルを確認しておきます。
両者の関連を確認しておくと:
- Blog は複数の Entry を所有する (Blog has_many Entry)
- Entry は特定の Blog に属する (Entry belongs_to Blog)
となります。この 2 つをスペックとして記述します。
せっかく Entry モデルを作成したので、まずは Entry 側の関連からスペックを定 義しましょう。
「Entryは特定のBlogに属すること」をスペックとして定義する。
Entry から Blog を参照できるという期待をスペックとして記述します。
spec/models/entry_spec.rb
RSpec on Rails では振舞を記述する際に、Rails 標準のテスティング環境と同様 に fixtures メソッドを使用できます。Rspec on Rails の fixtures と Rails 標準の fixtures との違いは、Rspec on Rails では「fixture_path」が 「$RAILS_APP/spec/fixtures」に設定されていることです。
spec を実行する前に、rake の db:test:prepare タスクを実行します。 entries テーブルを作成した際に、development 環境のデータベーススキーマは 変更しましたが、この変更をまだ test 環境のデータベースには反映していないからです。
ここでテストを実行すると失敗するはずです。なぜならまだEntry.blogを定義していません。
一応実行してみます。
予想通り失敗しました。
Entryにbelongs_toを実装する。
振舞の期待通りに Entry を実装しましょう。
app/models/entry.rb
spec を実行します。
予想通り成功しました。
とりあえずここまで。
Rubyでgemを作って公開するまで
- 0. 準備
- 1. ヒナ形の作成
- 2. 作成されたファイルの確認
- 3. test_gem.gemspecの修正
- 4. Gemの実装
- 5. 実行してみよう
- 6. RSpecを書こう
- 7. 実行コマンドを追加
- 8. Gemをパッケージ化する。
- 9. 公開
0. 準備
まずは準備のためにgemのアップデートとbundlerのアップデートを行います。
# gem自信のアップデート |
1. ヒナ形の作成
今回はtest_gemという名前のGemを制作していきます。
※実際にRubyGemsで公開する場合はまだ存在していないGem名にしないといけません。
# test_gemのひな形を作成(Rspec付き) |
2. 作成されたファイルの確認
今回作成されたファイルの簡単な説明。
bundle gem test_gem -t create test_gem/Gemfile create test_gem/Rakefile create test_gem/LICENSE.txt create test_gem/README.md => このgemの説明や使い方を記述 create test_gem/.gitignore create test_gem/test_gem.gemspec => このgemの説明や依存関係などを記述 create test_gem/lib/test_gem.rb => プログラムを記述 create test_gem/lib/test_gem/version.rb => このgemのバージョン情報を記述 create test_gem/.rspec create test_gem/spec/spec_helper.rb create test_gem/spec/test_gem_spec.rb create test_gem/.travis.yml => travisを使う際の設定を記述
create test_gem/exe/test_gem => 実行コマンドを追加する際に記述
3. test_gem.gemspecの修正
test_gem.gemspecの中身は以下のようにになっています。
# coding: utf-8 |
最低限修正が必要な部分を抜き出すと次のようになります。
# このgemの説明をダブルクオートで囲って書き直す spec.summary = "Make gem for summary." spec.description = "Make gem for description."
# このgemのHomepageを書く(GitHubのURLを入れてください) spec.homepage = "https://github.com/kubota-ryotaro/"
# 依存するgemが存在する場合のみ、次のように指定 spec.add_dependency 'xxxx', '~>x.x' # 開発時だけに必要な依存gemが存在する場合のみ、次のように指定 spec.add_development_dependency 'yyyy', '~>y.y'
4. Gemの実装
今回はテスト的にHello World!
と出力するようにします。lib/test_gem.rb
を開いて次のように変更します。
require 'test_gem/version' |
5. 実行してみよう
では先ほど作成したgemを実行してみます
# gem のインストール |
ということで無事実行できました!
6. RSpecを書こう
先ほどのTestGem.greet
のテストをRSepcで書いていきます。spec/test_gem_spec.rb
を次のように書き換えます。
require 'spec_helper' |
7. 実行コマンドを追加
コンソール上でtest_gem
というコマンドを使うとgemの内容を実行できるようにしたいので、exe/test_gem
に次を書いていきます。
#!/usr/bin/env ruby |
8. Gemをパッケージ化する。
次にGemをパッケージ化します。コマンドとしては、gem build test.gemspec
です。
gem build test_gem.gemspec |
9. 公開
GitHubと連携して管理するようなので以下のことは前提となります
・GitHubアカウントを持っていること
・GitHub用にSSHキーの設定を行う:GitHubへssh接続する
①rubygems.orgのアカウントを取得
作ったgemをリリースするまで
1.「sign up」からアカウントを作成
2. アカウント作成後、Edit profile(https://rubygems.org/profile/edit) に移動
3. APIアクセス用の鍵を作成(以下のコマンドが用意されている)
②GitHub上のリモートリポジトリの設定
現在の作業用ディレクトリをリモートリポジトリに反映させます
Githubにgem名と同じ名前の新規リポジトリを作成する
③リリース
あとは、releaseするだけ。
これでできたはず!
rakeの基本
前提 rubyプログラムの中でC言語をコンパイルして実行する。
1. まず最初に適当な作業ディレクトリを作成し、そこにRakefileを作る。
ここでお約束的な感じでRakefileの頭文字は大文字にしておく。
2. 今回使用するC言語プログラムを作っておく。
今回実行するプログラムはamidakuji.c
3. RakefileにCプログラムをビルドして実行するためのコードを書いていく。
$ rake としたらdefaultでamidakujiが呼ばれるようにしておく。
4~6行目で実行プログラムで、8~10行目でビルドだ。
このように芋ずる式で書いていくと良い。
$ rake
で実行できる。
8時間かけて作ったソースファイル達を rm ./* してしまった。
2日かけて計8時間ほどかけて作ったプログラムがありました。
それをGitHub上にpushしようと思ったんですよね。
だからまずローカル環境で、作業用ディレクトリからpush用のディレクトにコピーしました。そしてそこで一応中身を確認していたのですが一部気に入らない箇所があり、もう一度作業用ディレクトリの中で訂正しようと思ったんですよね。んで、そのファイル達を一旦消しました。
そしたら...
「あれ?」
作業用ディレクトリの中にさっきまで開いていたファイルがないお??
あれ、どこ行ったんだろ...
...
.......
「ない.......」
コマンドの履歴を確認してみたところ作業用ディレからpush用ディレにmvしていたようでした。
そして移動させたファイルを綺麗に削除したみたいでした。
解決策は基本的になく、もう一回作り直すしかないらしい...。゚(゚´ω`゚)゚。
その後誰かに聞いたら「そのためのgitじゃね? コミットしーや。」
とのことで解決しましたとさ。