ActiveRecord単体でMigration機能を使いたい
Railsを使わずにActiveRecordとその機能であるMigrationを使いたい。どうやって使うんだ？となり色々調べて、欲しいのができたのでメモ程度に残します。
最初に
- ruby 2.6.5
- MySQL 5.7
- ActiveRecord 6.x
- Rake 13.x
- Dotenv 2.7
Gemfileを用意する
./Gemfile
source 'https://rubygems.org' git_source(:github) { |repo_name| "https://github.com/#{repo_name}" } gem 'dotenv' gem 'activerecord' gem 'mysql2' gem 'rake'
=> 適宜インストールしていただく
秘密っぽい接続情報を.envファイルに持たせる
./.env
DATABASE_HOST=localhost DATABASE_PORT=3306 DATABASE_NAME=db_name DATABASE_USER=user_name DATABASE_PASSWORD=password
そして.envファイルから読んだ値をymlで読みたい
production: adapter: mysql2 encoding: utf8 charset: utf8mb4 host: <%= ENV['DATABASE_HOST'] %> port: <%= ENV['DATABASE_PORT'] %> database: <%= ENV['DATABASE_NAME'] %> username: <%= ENV['DATABASE_USER'] %> password: <%= ENV['DATABASE_PASSWORD'] %>
migrationファイルたち
※ samples テーブルを作ってみます
% mkdir -p db/migration % touch db/migration/20200127000000_create_sample_table.rb
内容を書いていく
db/migration/20200127000000_create_sample_table.rb ※ファイル名とクラス名は合わせる必要あり(snake_case to PascalCase)
class CreateSampleTable < ActiveRecord::Migration[6.0] def change create_table :samples do |t| t.string :name t.text :description t.timestamps end end end
Database接続周りを書く
./chanshige/database.rb
require 'active_record' module Chanshige class Database # establish connection def self.connection(config, env = 'production') ActiveRecord::Base.configurations = config ActiveRecord::Base.establish_connection env.to_sym ActiveRecord::Base.time_zone_aware_attributes = true end end end
最初に大体呼び出しちゃうファイルを作る
./bootstrap.rb
BASE_DIR = __dir__ $LOAD_PATH.unshift File.expand_path('./lib', BASE_DIR) require 'dotenv/load' require 'erb' require 'chanshige/database' # db connection config = YAML.safe_load(ERB.new(IO.read(File.expand_path('./config/database.yml', BASE_DIR))).result) Chanshige::Database.connection config
Rakefileを書く
./Rakefile
require_relative 'bootstrap' namespace :db do migration_context = ActiveRecord::MigrationContext.new( File.expand_path('./db/migration', BASE_DIR), ActiveRecord::SchemaMigration ) desc "Migrate the database (option: VERSION=x)" task :migrate do migration_context.migrate ENV['VERSION'] ? ENV['VERSION'] : nil end desc "Rolls the schema back to the previous version (specify steps w/ STEP=n)" task :rollback do migration_context.rollback ENV['STEPS'] ? ENV['STEPS'] : 1 end desc "Retrieves the current schema version number" task :version do p ActiveRecord::Migration.current_version end end
実行！
% bundle exec rake --tasks rake db:migrate # Migrate the database (option: VERSION=x) rake db:rollback # Rolls the schema back to the previous version (specify steps w/ STEP=n) rake db:version # Retrieves the current schema version number
普段、お仕事などでrubyを書く機会があまりないので、違和感などあったら教えてください！
2020年ももっと面白く、楽しんでまいりましょう！また次回！
最近作ったやつ
もう年末ですね。皆さん忘年してますでしょうか！僕はまだです※2019/12/17現在
2019年がおわりますので、今まであるものをライブラリ化するとか、欲しかったやつを作る勢いを加速させているこの頃でございます。
まず初めにドメイン関係で、whoisに続くdigもライブラリ化しました。
しかしながら中途半端なので、近いうちにアップデートします。
github.com
※composerは composer require chanshige/dig
次に、Slackへのメッセージ投稿のためにIncomingWebhookを使うことがあるんですが、そのときのメッセージ整形やポストのためのリクエストを簡単にするやつを用意しました。Laravelプラグインにインスパイアされて作ってます。
github.com
※composerは composer require chanshige/slack-notifier
最後ですが、これはちょっと前に作ったやつですがNulabのBacklogサービスから課題を取得したり登録したり、、用意されているAPIをええ感じに操作できるライブラリも作っています、AuraDIを使いたくてつくりました。APIの種類が豊富なので、実装が追いついてないところがあります。
github.com
※composerは composer require chanshige/backlog-client
このような感じで、簡単ではありますが”あーこんなのあったらいいな簡単なの”みたいな気持ちで作っているので、僕が使わなくなった＆皆さんにもあまり利用されていなさそうなものはどんどん削除し、逆につかわれてそうだああ！はどんどんアップデートしていきたいと思いますので、是非PR、Bugのご連絡などいただけるとうれしいです。
また、ちょいちょい利用いただいている whoisproxy.info もそろそろ、、リニューアルします。
引き続きご利用いただければと思いますので、こちらもよろしくお願いします。
まだ今年を締めるのは早いですが、良いお年をお迎えください!!!!!!!!1 (年内にまた書けたら書きます)
kudaranai.infoの記録
kudaranai.infoというくだらないドメインを過去取得していて、くだらないコンテンツにしようと思っていたので「僕の誕生日までカウントするサイト」を作っていました。
※インターネットアーカイブから拾っております。
2012,2013-2014
CSSが拾えなくてこの感じでしたが、当時はiWebを使ってました。
なぜMacから見ないとダメだったかは謎
2014-2015
アプリ一切ないのにそれっぽくしたかったやつ
2015-2016
Let it go... 時代を感じますね
2016-2017
色とフォント変えてきただけか
2017-2018
色すら変えてないな(飽きてきてる
2018 - END
完全に飽きた状態
whoisproxyのAPI仕様変更しました
ちゃんしげです。ちょくちょくご利用いただいている api.whoisproxy.infoですが、以下を変更しました。
APIバージョニングについては様々な意見があって、よく議論されている部分かなと思いますが、そもそも不要なのでは？というところから、本APIの利用者様に提供するレスポンスの内容(価値)に大きな変更が無いので、もっと気軽にリクエストできるように廃止しました。
例として、https://api.whoisproxy.info にリクエストした場合は、特別なリソースを設定していないので404ですが、'_link'プロパティにリクエスト可能な形式を記載しています。
Content-Type: application/problem+json;charset=utf-8
{ "code": 404, "state": "fail", "_links": { "self": { "href": "/" }, "doc:whois": { "href": "/whois/{domain}", "title": "Lookup find out the registered domain holder." }, "doc:dig": { "href": "/dig/{domain}[/{q-type}]", "title": "domain information groper." }, "reference": { "href": "" } }, "results": "Welcome to a whoisproxy api." }
※上記 /whois や /dig でのレスポンス形式はこれまで通りです。
このような感じで、APIへのリクエスト方法を使い手側が知らなくても、とりあえず投げてみればわかるほうが便利じゃんと思いました。
奥が深いRESTの世界に興味があるので、引き続き学びつつアップデートしていきます。是非ご意見お待ちしております!!!!1
whoisproxyのAPIをアップデートした
前回、僕が運用しているwhoisproxy.infoのAPI版を作成した話をしましたが、その中の一つであるdig(DNSレコードを検索するやつ)で、クエリタイプも指定できるようになりました。
許可しているクエリタイプは、以下です。
a any aaaa mx ns soa txt srv cname
リクエストとしては、https://api.whoisproxy.info/dig/{ドメイン名}/{クエリタイプ} の形式となります。
以下、例としてicloud.comのAレコードとMXレコードをリクエストしてみます。
/dig/icloud.com/a
{ "code": 200, "state": "success", "_links": { "self": { "href": "/dig/icloud.com/a" } }, "results": [ "icloud.com. 2246 IN A 17.253.144.10" ] }
/dig/icloud.com/mx
{ "code": 200, "state": "success", "_links": { "self": { "href": "/dig/icloud.com/mx" } }, "results": [ "icloud.com. 271 IN MX 10 mx1.mail.icloud.com.", "icloud.com. 271 IN MX 10 mx2.mail.icloud.com.", "icloud.com. 271 IN MX 10 mx3.mail.icloud.com.", "icloud.com. 271 IN MX 10 mx4.mail.icloud.com.", "icloud.com. 271 IN MX 10 mx5.mail.icloud.com.", "icloud.com. 271 IN MX 10 mx6.mail.icloud.com." ] }
クエリタイプを渡さない場合は、これまで通り"ANY"でのリクエストととなり、仮に許可しないクエリタイプを指定された場合はエラーを返します。
/dig/icloud.com
{ "code": 200, "state": "success", "_links": { "self": { "href": "/dig/icloud.com" } }, "results": [ "icloud.com. 21571 IN SOA adns1.apple.com. hostmaster.apple.com. 2011093772 1800 900 2592000 1800", "icloud.com. 21571 IN NS b.ns.apple.com.", "icloud.com. 21571 IN NS e.ns.apple.com.", "icloud.com. 21571 IN NS c.ns.apple.com.", "icloud.com. 21571 IN NS f.ns.apple.com.", "icloud.com. 21571 IN NS a.ns.apple.com.", "icloud.com. 21571 IN NS d.ns.apple.com.", "icloud.com. 3571 IN A 17.253.144.10", "icloud.com. 271 IN MX 10 mx5.mail.icloud.com.", "icloud.com. 271 IN MX 10 mx6.mail.icloud.com.", "icloud.com. 271 IN MX 10 mx4.mail.icloud.com.", "icloud.com. 271 IN MX 10 mx3.mail.icloud.com.", "icloud.com. 271 IN MX 10 mx1.mail.icloud.com.", "icloud.com. 271 IN MX 10 mx2.mail.icloud.com.", "icloud.com. 3571 IN TXT google-site-verification=knAEOH4QxR29I4gjRkpkvmUmP2AA7WrDk8Kq0wu9g9o", "icloud.com. 3571 IN TXT v=spf1 ip4:17.36.0.0/16 ip4:17.41.0.0/16 ip4:17.58.0.0/16 ip4:17.110.0.0/15 ip4:17.111.110.0/23 ip4:17.120.0.0/16 ip4:17.133.0.0/16 ip4:17.139.0.0/16 ip4:17.142.0.0/15 ip4:17.151.1.0/24 ip4:17.158.0.0/15 ip4:17.162.0.0/15 ip4:17.164.0.0/16 ip4:17.171.37.0/24 ip4:17.172.0.0/16 ip4:17.179.168.0/23 ~all" ] }
/dig/icloud.com/query （Error）
{ "code": 403, "state": "fail", "_links": { "self": { "href": "/dig/icloud.com/query" } }, "results": "query-type:query is not supported." }
※digはGoogle Public DNS(@8.8.8.8)で参照した結果を返しています
地味に便利だったりするので、ぜひご活用ください！
前回の記事 chanshige.hatenablog.com
ドメインのwhoisとdnsレコードを検索できるAPIをつくってみた
ドメインのwhois情報やDNSレコードを検索できるWHOISPROXYサイトを運営していますが、世の中に新しいドメインが増えて、検索できる種類が限られてきたことと、そろそろ(見た目も)作り変えたいなと思ってきたので、SlimPHP3x(Framework)を使って簡単なAPIを作ってみました。
APIにするからにはそれっぽくapi.whoisproxy.infoをFQDNとして、WEB上でも検索できる2種類(whois, dig)のエンドポイントを用意しました。
結果は、安定のJSON形式で返すようにしています。
https://api.whoisproxy.info/{whois or dig}/{検索したいドメイン名} でリクエストする感じです。
試しにAppleのiCloudドメイン(icloud.com)を使ってWHOISとDIGのリクエスト(GET)を投げると、以下のように返ってきます。
/whois/icloud.com
{ "code": 200, "state": "success", "_links": { "self": { "href": "/whois/icloud.com" } }, "results": { "domain": "icloud.com", "servername": "whois.corporatedomains.com", "tld": "com", "registered": true, "reserved": false, "client_hold": false, "detail": { "registrant": [ "Registrant Name: Domain Administrator", "Registrant Organization: Apple Inc.", "Registrant Street: One Apple Park Way", "Registrant City: Cupertino", "Registrant State/Province: CA", "Registrant Postal Code: 95014", "Registrant Country: US", "Registrant Phone: +1.4089961010", "Registrant Phone Ext:", "Registrant Fax: +1.4089741560", "Registrant Fax Ext:", "Registrant Email: domains@apple.com" ], "admin": [ "Admin Name: Domain Administrator", "Admin Organization: Apple Inc.", "Admin Street: One Apple Park Way", "Admin City: Cupertino", "Admin State/Province: CA", "Admin Postal Code: 95014", "Admin Country: US", "Admin Phone: +1.4089961010", "Admin Phone Ext:", "Admin Fax: +1.4089741560", "Admin Fax Ext:", "Admin Email: domains@apple.com" ], "tech": [ "Tech Name: Domain Administrator", "Tech Organization: Apple Inc.", "Tech Street: One Apple Park Way", "Tech City: Cupertino", "Tech State/Province: CA", "Tech Postal Code: 95014", "Tech Country: US", "Tech Phone: +1.4089961010", "Tech Phone Ext:", "Tech Fax: +1.4089741560", "Tech Fax Ext:", "Tech Email: apple-noc@apple.com" ], "billing": [], "status": [ "Domain Status: clientTransferProhibited http://www.icann.org/epp#clientTransferProhibited" ], "date": [ "Updated Date: 2018-09-27T20:55:11Z", "Creation Date: 1999-01-15T05:00:00Z", "Registrar Registration Expiration Date: 2020-01-15T05:00:00Z" ], "name_server": [ "Name Server: b.ns.apple.com", "Name Server: d.ns.apple.com", "Name Server: f.ns.apple.com", "Name Server: e.ns.apple.com", "Name Server: a.ns.apple.com", "Name Server: c.ns.apple.com" ] } } }
/dig/icloud.com
{ "code": 200, "state": "success", "_links": { "self": { "href": "/dig/icloud.com" } }, "results": [ "; (1 server found)", ";; global options: +cmd", "icloud.com. 21371 IN SOA adns1.apple.com. hostmaster.apple.com. 2011089978 1800 900 2592000 1800", "icloud.com. 21371 IN NS c.ns.apple.com.", "icloud.com. 21371 IN NS a.ns.apple.com.", "icloud.com. 21371 IN NS d.ns.apple.com.", "icloud.com. 21371 IN NS b.ns.apple.com.", "icloud.com. 21371 IN NS e.ns.apple.com.", "icloud.com. 21371 IN NS f.ns.apple.com.", "icloud.com. 3371 IN A 17.253.144.10", "icloud.com. 71 IN MX 10 mx1.mail.icloud.com.", "icloud.com. 71 IN MX 10 mx6.mail.icloud.com.", "icloud.com. 71 IN MX 10 mx5.mail.icloud.com.", "icloud.com. 71 IN MX 10 mx4.mail.icloud.com.", "icloud.com. 71 IN MX 10 mx2.mail.icloud.com.", "icloud.com. 71 IN MX 10 mx3.mail.icloud.com.", "icloud.com. 3371 IN TXT google-site-verification=knAEOH4QxR29I4gjRkpkvmUmP2AA7WrDk8Kq0wu9g9o", "icloud.com. 3371 IN TXT v=spf1 ip4:17.36.0.0/16 ip4:17.41.0.0/16 ip4:17.58.0.0/16 ip4:17.110.0.0/15 ip4:17.111.110.0/23 ip4:17.120.0.0/16 ip4:17.133.0.0/16 ip4:17.139.0.0/16 ip4:17.142.0.0/15 ip4:17.151.1.0/24 ip4:17.158.0.0/15 ip4:17.162.0.0/15 ip4:17.164.0.0/16 ip4:17.171.37.0/24 ip4:17.172.0.0/16 ip4:17.179.168.0/23 ~all" ] }
まず、whoisについては以前僕が作成したwhoisライブラリを使っていて、新ドメインも大体は検索できる？かな？と思っています。
検証するにも、種類が多すぎているので思いついた時にしかチェックしていません。もし結果が来ない！おかしい！があったらGithubのIssueかLINEでも連絡ください！切実っっ！
※GDPR施行により、ドメインによっては結果がほとんど出てこないものもありますが、各ドメインレジストリ・レジストラのポリシーに準して、whois結果自体は加工せずそのまま使用しているので、そういうこともあります。
digについては、GooglePublicDNS(8.8.8.8)に対してリクエストを投げているだけなので特別な加工はしていません。
僕がカスタマーサポート業をやっていた時代(4,5年前)からつくってたwhoisproxy.infoですが、今も利用してくれている方がいてとても嬉しいです！ありがとうございます!!!!!!1
このサイトが何かの役に立っている限り、徐々に更新していきたいと思いますが、サイト自体のリニューアルはこれからやりますので引き続きよろしくお願いします。
※2019/02/20追記
json形式をcontent-type: application/hal+jsonに変更しました。
今後の予定として、正常・エラー時のレスポンスにLink属性をつけて、リファレンス等のリンクをつける予定です。
dockerを使ってシュッと開発環境をつくる
前回、Vagrant(VirtualBox)を使った開発環境構築の流れを書きましたが、PHPと触れ合うまでに結構時間がかかります。
サーバー構築って割と勉強になると思っていますが、(実際に)環境構築の時間はできる限りかけたくないものなので、最近の僕はDockerを使ってアプリケーションごとにシュッと環境を立ち上げています。
immutableかつ、使わない時はサッと環境を捨てることができるし管理が楽です。ありがとうコンテナ！
そこで、僕が使ってるDockerfileとdocker-composeファイルをGithubに公開しました。
README.md に書いてあるようなコマンドを実行してもらえば、あっという間に環境が出来上がるので、お試しください！
docker-composeは、Dockerイメージを複合的に管理・実行できる(と思っている)ツールで、たとえばWordpressのようにwebサーバ(PHP)と、DBが必要なアプリケーションであれば、使いたい各イメージ(webサーバ、DB)と、ポートや環境変数をdocker-compose.yml書くことで、いい感じに出来上がります。料理のレシピみたいなもんだとおもっていただければ良いのかなと（？）
dockerfile自体は docker commit でバージョン管理もできるのでとても素敵。
※Dockerっって！っという方は、さくらさんのとてもわかりやすいナレッジがあるので是非ご覧ください knowledge.sakura.ad.jp