コピペコードで快適生活

明日使えるソースを自分のために

シェルでいつか使うかもしれないコマンド・オプションまとめ

便利かどうかはわからないけど、いつか使うかもしれないコマンド・オプションを随時追加していく。

# 素数を出す
# factorコマンドは素因数分解するコマンド
seq 1 20 | gfactor | awk 'NF==2{print $2}'

# 文字の16進数変換
# -p で 16進数にして出す
# -p -r で元に戻す
echo おはようございます | xxd -p | xxd -p -r

# アスキーコード出力
man ascii

# アニメーション
seq 10 | while read n; do clear; echo $n; sleep 1; done

# 100日後を出す
gdate -d '100 day' '+%F'

# xargs 一度に渡す値の数を変えることができる
# コマンドの指定なしの場合は、echoが暗黙的に呼ばれる
# -Pコマンドで並列処理になる
seq 1 5 | xargs -n 3 -P 4
1 2 3
4 5

よく使うステータスコード

APIのレスポンスコードをどうするか毎回迷うので。
下記より転記させていただきました。
http://ruby-rails.hatenadiary.com/entry/20141125/1416918957#render-ctrl-status-code

Code シンボル 説明
200 :ok レスポンスが正常に終了した
201 :created createなどのアクションの結果などでリソースが正常に作成された。作成されたリソースに対するlocationヘッダも指定する
302 :found 他のURLへのリダイレクトを示す。redirect_toメソッドが内部的に使っていて明示的に使うことは少ない
400 :bad_request リクエストチェックをした結果、不正だった
401 :unauthorized 認証に失敗した
403 :forbidden アクセスが禁止されている
404 :not_found 対象のURLやリソースが存在しない
406 :not_acceptable 指定されたフォーマットでレスポンスを返せない。respond_toの指定ミスなどで起こる
422 :unprocessable_entity バリデーションエラーなど
500 :internal_server_error サーバー側が現認のシステムエラーが発生した
503 :service_unavailable メンテナンスや高負荷など

Windows10でhosts編集ウィンドウを一発で開く

powershell -NoProfile -ExecutionPolicy unrestricted -Command "start notepad C:\Windows\System32\drivers\etc\hosts -verb runas"

これを edit_hosts.bat みたいな名前で保存して、ダブルクリックで起動したらOK。

シェルで便利だったコマンド&オプションまとめ

随時追加していく。

# grepでOR検索
cat file.txt | grep -e hoge -e fuga

# grepで前後行も出力
# -A -> 後の行数
# -B -> 前の行数
cat file.txt | grep -A 10 -B 5 hoge -e fuga

# xargsでパイプで渡された値を任意の場所に突っ込む
cat file.txt | grep "hoge" | awk '{print $1}' | xargs -IXXX grep XXX file2.txt

# tail -F をリアルタイムで grep する
tail -f production.log | grep --line-buffered "hogehoge"

# gz形式のファイルを解答せずに中身を見る
gzip -dc production.log-yyyymmdd.gz | less

# 全検索
sudo find / -name filename

# <() コマンド結果をファイルのようにして入力値として与える
diff <(seq 1 3) <(seq 2 4)

# trで文字列置換(改行コードも扱える)
cat file.txt | tr 'A' 'B' # AをBにする
cat file.txt | tr -d '\n'  # 改行を消す
cat file.txt | tr -dc 1 # => 1以外を消す

# 指定文字数で改行させなおす
# 一度改行消して、60文字区切りで改行させる
cat file.txt | tr -d '\n' | fold -w60

# ImageMagickで画像変換
convert test.png test.jpg # フォーマット変換
convert -geometry 50% testimg.png testimg.50p.png # サムネイル
convert -geometry 100x100 testimg.png testimg.50p.png # サムネイル

# xargsで複数のコマンドを実行
# (shコマンドの中で複数のコマンドを実行させて実現する)
seq 10 | xargs -I@ sh -c 'echo @; sleep 1'

# 乱数を出力する
# /dev/urandomは乱数を出す / tr-dcで0-9以外を消す
cat /dev/urandom | gtr -dc 0-9 | fold -w 10 | head

# テキストブラウザ
w3m http://google.co.jp 
w3m http://google.co.jp --dump # 表示出力

# bcコマンド 電卓
# オプション obase(output10進数)
# オプション ibase(input16進数)
echo 'obase=10;ibase=16; F + F' | bc

My.tmux.conf

随時更新していく

bind s split-window -v
bind v split-window -h
bind j select-pane -D
bind k select-pane -U
bind h select-pane -L
bind l select-pane -R
bind r source-file ~/.tmux.conf \; display "Reloaded!"

set -g pane-active-border-fg red
set -sg escape-time 1
setw -g mode-keys vi

bind c new-window -c "#{pane_current_path}"
bind % split-window -hc "#{pane_current_path}"
bind '"' split-window -vc "#{pane_current_path}"

サーバサイドとクライアントサイドのJavascriptが混在しているリポジトリ

表題の件の構成について社内チャットで説明したのを、再構成してみました。

ディレクトリ構成

- build
- src
- gulpfile.js
- package.json
- node_modules

buildには、ブラウザが読み込んでいるjs, css, html 一式、
そしてnodeサーバが動かしているjsが入ります。

srcの中に色々と置いてありますが、これはnodejs(サーバサイドjs) やブラウザでは実行できないES6仕様のJSで書かれてて、それを実行できる形に変換して、buildの中に突っ込んでいる感じです。SCSSも同様です。

その辺の変換のロジックはgulpfile.jsに書いてあります。

gulpfile.jsの中でやっているのは
1) sassの場所を見て、cssに変換してbuildに突っ込む
2) es6のjsを見て、js(es5)に変換してbuildに突っ込む
3) その他のファイル(画像とか)をコピーして、buildに突っ込む
4) sassのファイルに変更があったら、1)を実行する
5) es6のjsに変更があったら、2)を実行する
6) 開発用のWebサーバ立ち上げつつ、3)を実行して、4)と5)を常駐させる。
みたいなのです。

そのうち6だけが、npm run スクリプトで動かせるようになっています。
package.json の "start:server": "gulp serve" みたいに書いてあるところです。

npm run start ってやると、gulp serve が実行される。
で、gulp serve が 6) なわけです。

Javascriptの用途

あとjsの用途は基本的に3つあって混同しないように注意が必要です。

1) es6とかsassとかをビルドする用
npm run なんちゃら とかコマンド叩いて動かすやつ。
nodejsで動いています。

2) サーバサイドJS
PHPRailsみたいに、サーバ側で動かすJSです。htmlレンダリングしたりAPIの口になったりします。
build/*の中に入ったjsを nodejsが読み込んで動かしています。

3) クライアントサイドJS
ブラウザで動かすJSです。build/*の中に入っているjsをブラウザが読み込んで実行します。

静的HTML → SPA → SSR+SPA

静的HTMLから、現在の構成までの進化を追っていきましょう。

まず静的ファイルだけで作られたサイトがあります。

そのページ内の一部分だけReactJSとかでで動的に変えたいとなりました。
そのときは 1) と 3) だけでいけますね。

少し進んでシングルページアプリケーションになると、
htmlファイルは1つだけ。
その中でリンク(らしきもの)を踏むと、ページ遷移するかのようにhtmlの内容をjsが書き換えます。
これも 1) と 3) だけで実現できます。

さてここでですね。
URL直だたきでページを表示したときは、普通のwebアプリとして動かしたい。というのがあるとします。
これは、1) と 2) だけでやる感じですね。
でもでも、URL直だたきして、そのあとページ内のリンクをクリックしたときは、シングルページアプリケーションとして、JSでhtmlの内容を書き換えたいとします。
(なんでそんなことしたいかというと、サイト表示のレスポンスあげるためだったり、ページ遷移のUIをイケてる感じにしたかったり、サーバサイドの負荷を下げるためだったりします。)
で、シングルページアプリケーションとしてページ遷移っぽい動きをした時に アドレスバーの URL を書き換えちゃいます。
で、その書き換わったURLに直にアクセスすると、今度はサーバサイドのjsがページをレンダリングして、ブラウザに表示させます。
この仕組を作るために 1), 2), 3) の 3つが必要になってくるんです。

で、そこでふと気づくんです。
2) と 3) でプログラムが重複しない?っと。
同じhtmlレンダリングするのに、クライアント用とサーバサイド用でそれぞれ必要になっちゃうじゃないですか。

そこで Reactの出番なわけです。実は ReactってサーバサイドJSでも使えるんですよ。
srcに入っている React のコンポーネントって、
1) の JSによって、
2) 用と 3) 用にそれぞれビルドされるんですよ。

ルーティングも同様ですね。
どのURLで、どのコンポーネントを使うかは
サーバサイド、クライアントサイドで同じjsから情報を取得しています。

という感じです。

Rubyで名詞の単数形・複数形を変換する

たまにやりたくなる。いつもメソッド名忘れているけど。

require 'active_support'
'user'.pluralize # => users
'users'.singularize # => user