classのattrに対して下記のようなpublic_sendで値を設定できるらしい。
public_send("#{attribute_name}=", val)
ということは、obj.hoge=の`hoge=`はメソッドなのか？と思って呟いていたら、attr_*はhoge フィールドとhoge= メソッドを定義するものだと教えてもらえた。（ありがたや〜）
だからpublic_sendで呼び出せるというわけ。
リファレンスにもバッチリ書いてある。
ref.xaio.jp
なるほど〜。
プロを目指す人のためのRuby入門 言語仕様からテスト駆動開発・デバッグ技法まで (Software Design plusシリーズ)
ちょっと大量のデータを扱うことになったのでmongoDBのセットアップをした。
当初はGAS+スプレッドシートでササッとやるつもりだったが、調べていくとデータの件数が数十万件を超えることが発覚したのでGASではさばききれない*1ためDBを立てることにした。
mongoDBにしたのは単に以前仕事で使ったことがあるから。
使う人がmacとWindowsと両方いたからDockerで書いた。
mongoDBをDockerで使う方法についてはQiitaに投稿した。
DBはmongoDBに決めたあと、処理するスクリプトはPythonで書くことにした。
ついでにPython3環境もDockerで作るかということでPython3とpymongoが入った環境を作った。
しかしPython自体は問題なく動かせるが、VSCodeでPylintしながら書こうとするとローカルにはpymongo入ってないので常にlintエラーが出続けてしまう。
試せてはいないけど、DockerでPylintのコンテナを立てて検証はそっちにさせればよさそう。
しかしその結果をVSCodeの問題タブに出そうとするとやはり拡張機能作ったりする必要がある気がする。
ひとまずPylintは諦めて書くことにした。
それほど大規模にはならないはずだから多分大丈夫…なはず。
一連のDocker環境はこちら
既存のmodelにカラムを追加するやり方
rails g migration クラス名
クラス名は通常「行なう処理＋テーブル名」になる。例えば、AddAgeToUsers（またはadd_age_to_users）となる。
生成されたマイグレーションファイルのchange内にadd_columnを書けばいい。
テーブル名は複数形で書く。
def change
add_column :users, :age, :integer, default: 0, comment: '年齢'
end
add_column - リファレンス - - Railsドキュメント
出来上がったらdb:migrateを実行すればDBやmodelに反映される（modelにもコメントとしてフィールド情報が記載される）
RailsはC#やjavaと違ってmodelにカラムの一覧をフィールドやプロパティで書かないので結構戸惑いますねー。
書き方が悪くてマイグレーションに失敗した場合、一旦下記コマンドをする必要がある*1
rails db:environment:set
その後マイグレーションファイルを直して再度db:migrateを実行する。
*1:詳しい理由はググって
Qiitaに投稿しました。
ソースと使い方はこっち。
主な内容はQiitaに書いたので開発時点の苦労話でも。
いまひとつSlackのTokenの扱いがよくわからない。
もともと参考にしたやつではherokuにデプロイして各ユーザーのトークンを保存することでbotがユーザーとして振舞うみたいなコードになっていたけれど、このトークンがどこから取得されるのかがよくわからなかった。
なので、暫定的にOAuth Access Tokenを使ってユーザーのアイコンとユーザーを取得することでユーザー"のように"振舞っている。
また最初はLegacy Tokenを用いていたが、OAuth Access Tokenの方が明示的に権限スコープを制御できるのでこちらの方がいいと思う。
なお権限スコープを設定していないAPIを叩くとエラーが発生するのではなく、結果が取得できない（undefinedになる）。
これがわからなくてAPIの使い方が間違っているのかを1から調べなおしていた。
403エラー返してほしい…。
APIを用いてユーザー名を取得するとdisplay_nameとreal_nameが取得できる。
users.profile.get method | Slack
自分はdisplay_nameが入っていたのでそれを使っていたが、テストしてもらったユーザーから「名前がslack api testerになる」という報告を受けて調べたら、ユーザーによってはdisplay_nameが入っていたりいなかったりする。
なのでdisplay_nameがあればそれを使い、なければreal_nameを使う仕様とした。
どのような設定をするとこの現象が起こるのかはよくわからない。
わからないことがあるまま動かしているのは危険ではあるが、自分の趣味のslackなのでひとまずはこのまま運用することにする。
Slackが絵文字を大きく表示する機能を実装してくれればいいだけなのに（ぁ
7月に引っ越すにあたって引越し先の選定をしないといけないが、SUUMOで表示される内容を見やすく一覧で見るためにスクリプトを書いた。
ただしSUUMOにはAPIがないため、検索結果のURLを叩いて返ってきたレスポンスを解析するという手法を採っている。
そのため具体的なソースを載せることは控える。
スクリプトはGoogleAppsScriptを用いた。
標準でスケジュール実行の機能があることとスプレッドシートとの親和性が高いため向いている。*1
まずURLはSUUMOで最寄り駅や各種条件で検索を押した後に出てくる画面のURLをそのまま用いた。
パラメータが大量に設定されているが内容を逐一照合するのは面倒なことと一つでもパラメータが欠けていると結果が返ってこないためそのままコピペすることにした。
これをUrlFetchApp.fetchで叩く。
返ってきたレスポンスから詳細ページへのリンク部分を正規表現で抜き取る。
具体的には「chintai/jnc_xxxxxxxxxxxx?bc=xxxxxxxxxxxx」となっているものを抜き取る。
そうして得られた詳細ページを一つずつUrlFetchApp.fetchで叩き、返ってきたレスポンスから家賃や間取り等の情報を取得する。
しかし詳細ページのページ構成は同じclassのdivが多数使われているため、正面から正規表現で抜くのはかなり困難なためパーサーを使う。
今回は下記のものを使用した。
fromを少し多めに取ることで該当する部分の要素を抜き出すことが出来る。
こうして出来たのが下記のシートである。
家賃や間取り、面積等を一覧で見られるため比較がかなりやりやすくなった。
スクレイピングといえばPythonみたいなところがあるが、GoogleAppsScriptはこうして他のGoogleのプロダクトとの連携がしやすいところが最大の長所である。
詳解! GoogleAppsScript完全入門 ~GoogleApps & G Suiteの最新プログラミングガイド~
*1:掲載情報は日々変わるため毎日最新を取得することにした
もうjavaは久しく触ってないですが。
var （型推論）が導入されていろいろ物議を醸しているみたい。
C#では10年も前に実装され、散々され尽くしたであろう議論がまた行われてるのを見てるといろいろと考えてしまう。
そこそこよく見かけるjava使いの人もvar否定的な感じだったりしてC#er的にはうーんと思ったり。
「読む時に読みづらい」というのを見かけるけど、これは多分慣れだと思うんだよなぁ。
C#でも結局ほとんどがvarで書かれてるし。
ただ、java10が使えない環境がたくさんあるというのは考える必要があるかもしれない。
あと、型推論について勘違いしてる人がいるけど、varで書いてもビルドの時点で型は確定する。
あくまで右辺から型が一意に決まるときのみ使えるのであって、そうでない時はそもそもビルドエラーになる。
javaScriptみたいに動かすまで型がわからないとかそういうことはない。
ちなみにMSDNではvarを使用しないほうがいい場合をコーディングルールで示しています（暗黙的に型指定されるローカル変数節）
javaでも参考になるのでは。
C# のコーディング規則 (C# プログラミング ガイド) | Microsoft Docs
