railsのfind_or_create_by(!)が便利

find_or_create_by - リファレンス - - Railsドキュメント

find_or_create_byは検索条件を指定して、該当のレコードが一件もなければ

新規レコードを作成してくれます

rails4系から実装されたので、古いrailsでは使えません><

最近はクローラーをよく作るのですが、キーとなるデータで検索をして

該当データがなければレコードを作成して、詳細情報のupdateは非同期処理しております

user情報や商品情報なんか、めっちゃ便利ですね

railsから離れられなくなりそうです

ソースコード

こちらから引用

rails/relation.rb at 78bd18a90992e3da767cfe492f1bc5d63077da8a · rails/rails · GitHub

    def find_or_create_by(attributes, &block)
      find_by(attributes) || create(attributes, &block)
    end

    # Like <tt>find_or_create_by</tt>, but calls <tt>create!</tt> so an exception
    # is raised if the created record is invalid.
    def find_or_create_by!(attributes, &block)
      find_by(attributes) || create!(attributes, &block)
    end

ソースコードもとてもシンプルでfind_by or createです

Active Recordのcreateの戻り値は成功可否に関わらずobjectです

結構はまるんですが、失敗しても例外が発生しないのでfind_or_create_by!を使うことが多いです

またレコードが見つかった場合は、どちらもfind_byなので1件だけ取得されることに注意します

複数件とってくる場合はwhereを使えばOKです

複数件取得or作成したい!って場合はfind_or_create_byのコードを参考にすれば良いのかな(あまり用途なさそうだけど)

railsは楽しいです(白目)

bundlerのバージョンを下げる

bundlerのバージョンがあがるとGemのinstallができなかったりと

設定ファイルを色々変える必要がでてくる(苦痛)

この辺りはrubyで辛いところで、マイクロサービスなら簡単にアップデートできるんだけど

そこそこ大きいプロジェクトはむりだよ、、、まじむり(白目)

というわけで、意図的にバージョンを下げる方法のメモ

bundle -v
Bundler version 1.15.3

使いたいバージョンは1.10.xなのでuninstall

gem uninstall bundler

You have requested to uninstall the gem:
    bundler-1.15.3

bundle-0.0.1 depends on bundler (>= 0)
If you remove this gem, these dependencies will not be met.
Continue with Uninstall? [yN]  Y
Remove executables:
    bundle, bundler

in addition to the gem? [Yn]  y
Removing bundle
Removing bundler
Successfully uninstalled bundler-1.15.3

指定したバージョンでinstall

簡単でよかった・・・特に手で消さなきゃいけないファイルとかはありませんでした

 gem install bundler -v {version}

 bundle -v

 ```

[WIP] sublime text + Emmet でフロントエンドのコード書くメモ

完全に個人的なメモです( ´ ▽ ` )

Web制作者のためのSublime Textの教科書 今すぐ最高のエディタを使いこなすプロのノウハウ

逆引き

よく使うショートカットキー

書き始め

  • 書き出し部分(HTMLのテンプレート的な)

! とエディタに書いて展開(tab) する

以下の内容が自動で作成されます!超便利

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>Document</title>
</head>
<body>
  
</body>
</html>

ただ言語部分のデフォルト設定が"en"になっているので、lang=“ja"になるよう設定

メニュー>Preferences>Package Settings>Emmet>Settings - User

ここに以下の内容をコピペ

{
    "snippets": {
        "variables": {
            "lang": "ja",
            "locale": "ja-JP",
            "charset": "UTF-8",
            "indentation": "\t",
            "newline": "\n"
        }
    }
}

もう一回 “!"と入力して展開(tab)をしてみると、以下の通り

<!DOCTYPE html>
<html lang="ja">
<head>
  <meta charset="UTF-8">
  <title>Document</title>
</head>
<body>
  
</body>
</html>

できたー!

コメントの文字を変更する

環境によりけりですが、こちらに設定ファイルがありました!

~/Library/Application Support/Sublime Text 3/Packages/User

手順はこちらを参考に、とってもわかりやすい、感謝感謝

qiita.com

Githubでローカルファイルを個人的に管理対象外にする方法

githubでコード管理をすることが増えてきました

また最近はフロントエンドが多様化していて、独自の構成をしたかったり

ビルドした結果をgithub上にあげたくなかったりします

通常は除外ファイルは.gitignoreに記載するのですが、.gitignore自体がgithub上に上がっているため

汚さずにいたかったりします、綺麗なままの.gitignoreであってほしい!(よくわからなくなってきた)

A .git/info/exclude ファイルに バージョン管理対象外にしたいファイルを指定する!

最近知ったのですが、project配下にある.git/info/excludeに追記すると

gitの管理からはずしてくれるみたいです

これをやることで、ローカル環境で好き放題やっても、リモートに反映されずに気が楽になります

数年前に知りたかったorz

この辺りが参考になります

Ignoring files - User Documentation

Githubで個人的によく参考にする本

GitHub実践入門 ~Pull Requestによる開発の変革 (WEB+DB PRESS plus)

GitHub実践入門 ~Pull Requestによる開発の変革 (WEB+DB PRESS plus)

マージ済みのローカルbranchを一括削除

だんだん溜まってくるローカルブランチが邪魔になってくることってありますよね

毎回やるたびに調べて『ほうほう…』ってなるのに、また忘れて・・・を繰り返しがちなのでまとめました

私もコマンドがまだまだ苦手なので(エンジニア10年目)、簡単に解説なんかもしながら…

こんなコマンドになりました

git branch --merged  | grep -v 'master' | grep -v 'develop' | xargs git branch -d

やっているのは、たった三つだけ

  • マージ済みのbranch一覧を出す
  • 削除したくないbranchをリストから除外
  • リストのbranchを消す

一見難しそうに見えますが、分解したら超簡単です

–margedでマージ済みのbranchを調べる

–mergedオプションは意味の通り、過去にマージしたbranch一覧を出してくれます。

git branch --merged

ここにはmasterブランチや、git-flow使っている場合developなんかも一覧にでてきます

grepで合致しない一覧を出す

例えばmasterとdevelopをマージ済みbranchとして表示したくない場合は、こんな感じで指定できます。

git branch --merged | grep -v 'master' | grep -v 'develop'

hotfixも除外してみたり(しなくてもよいんだけど)

git branch --merged | grep -v 'master' | grep -v 'develop' | grep -v 'hotfix*'

参考

http://linux.just4fun.biz/%E9%80%86%E5%BC%95%E3%81%8DUNIX%E3%82%B3%E3%83%9E%E3%83%B3%E3%83%89/grep%E3%81%A7%E8%A4%87%E6%95%B0%E3%81%AE%E3%82%AD%E3%83%BC%E3%83%AF%E3%83%BC%E3%83%89%E3%82%92%E9%99%A4%E5%A4%96%E3%81%99%E3%82%8B%E6%96%B9%E6%B3%95.html

リストアップされたブランチを削除する

xargsって最初分からずに使っていたんですが(危険!)、簡単に言うとリストを渡すコマンドです

あまりイメージがつかなかったんですが、ここの記事をみてすっと納得できました

https://hydrocul.github.io/wiki/commands/xargs.html

xargsでリストを渡して、branchの-dオプションで削除!

きっとこれで、すっきりするはずです

git branch --merged  | grep -v 'master' | grep -v 'develop' | xargs git branch -d

参考

http://www.backlog.jp/git-guide/reference/branch.html

思ったこと

コマンドを覚えたり、一括操作をし始めるとプレフィックス(頭とかおしりに付ける決まった文字)が大切だなって実感します

そして反省します・・・orz

参考にしたページ

こちらのページを参考にさせていただきました

3.3 Git のブランチ機能 - ブランチの管理

GitHub実践入門 ~Pull Requestによる開発の変革 (WEB+DB PRESS plus)

GitHub実践入門 ~Pull Requestによる開発の変革 (WEB+DB PRESS plus)

フォーム入力とpermit、StrongParametersについて

ソースコードレビューをしてたらpermitって見慣れない文字を見かけてgoogle先生に聞いてみた

そもそもStrongParametersの存在を知らなくて(恥ずかしい)

言い訳をすると現在のシステムで使っているRailsのバージョンが古く、レビューしたのはRails4.1のコードだったからです

元々Railsにはparamsがあるんですが、若干セキュリティ面で弱いそう(知らんかった・・・)

StrongParametersとparamsの違い

paramsの場合は予期しないデータくる場合があります

params # => { "name" => "名無しさん", "password" => "hoge", "admin" => "true" }
User.create(params) # => 新しいユーザーが管理者権限でで作成されてしまう

StrongParametersを使うことで、更新する値を制御することができます

上記のケースでは"admin"の項目は更新せずに、nameとpasswordのみ更新したいので

params.require(:user).permit(:name, :password)

こんな感じでuserモデルのnameとpasswordを更新してねって指定することができます

もともとはモデル内のattr_accessibleで制御する流れだったのですが

Rails4からはコントローラで制御するのが主流になりそうです

参考にしたサイト

とても分かりやすく詳しくかかれていました

http://ruby-rails.hatenadiary.com/entry/20141126/1417012848

QAサイトで実際のぜい弱性の例なんかもあります https://teratail.com/questions/30734

shellで前の週の指定した曜日を算出したい

会社の開発環境がlinux サーバーで、データ取ってきたりするときとに、作成日時がファイルになっていたりするんですよね

更にそれが火曜日1度だけの同期、とかなると前の週の火曜日のファイル名を指定しなきゃいけなかったり

そんなときに右往左往して作ってみたshell

hoge.sh
 #!/bin/bash

_targetWday=2
_wday=`date +%w`
_numOfLastWeek=`expr 7 - $_targetWday + $_wday`
_date=`date -d "$_numOfLastWeek days ago" '+%Y%m%d10'`

echo $_date

exit 0

もっとスマートなやり方が、世の中にはたくさん転がっているかもしれません

いや、転がっているに違いない