tmux入れてみた

端末の画面を分割して表示したいと思った。

linuxの画面分割について調べてみると、tmuxやterminatorとかいうソフトウェアで実現できるとのこと。

terminatorは端末エミュレーターのひとつ、tmuxは端末マルチプレクサーのひとつらしい。 端末エミュレーター、端末マルチプレクサーとはなにか?よくわからなかった。今のところ以下のようにぼんやりと解釈している。合っているかはわからない。

  • 端末エミュレーター… 端末をエミュレートする。GUIからコンソールを覗ける?有名なのはgnome terminal, terminator, iterm2(Mac)など。
  • 端末マルチプレクサー…ひとつの仮想端末から複数のログインセッション(?)を扱える?有名なのはtmux,GNU screen, byobuなど。

画面分割機能はterminator,tmuxのどちらでも実現可能。 リモートからSSH接続したときでも画面分割が利用できるので、tmuxを入れることにする。

.tmux.confファイルに設定を記入する。ここを参考にした。 qiita.com

上記リンクのコピーモード設定はMacのもの。下記のページ群を参考に、Ubuntu版をファイルに記入した。 Everything you need to know about Tmux copy paste - Ubuntu · rushiagr coderwall.com qiita.com

# キーストロークのディレイを減らす
set -sg escape-time 1

# マウス操作を有効にする
setw -g mouse

# 256色端末を使用する
set -g default-terminal "screen-256color"

# ステータスバーの色を設定する
set -g status-fg white
set -g status-bg black

# ウィンドウリストの色を設定する
setw -g window-status-fg cyan
setw -g window-status-bg default
setw -g window-status-attr dim

# アクティブなウィンドウを目立たせる
setw -g window-status-current-fg white
setw -g window-status-current-bg red
setw -g window-status-current-attr bright

# ペインボーダーの色を設定する
set -g pane-border-fg green
set -g pane-border-bg black

# アクティブなペインを目立たせる
set -g pane-active-border-fg white
set -g pane-active-border-bg yellow

# コマンドラインの色を設定する
set -g message-fg white
set -g message-bg black
set -g message-attr bright

# ステータスバーを設定する
## 左パネルを設定する
set -g status-left-length 40
set -g status-left "#[fg=green]Session: #S #[fg=yellow]#I #[fg=cyan]#P"
## 右パネルを設定する
set -g status-right "#[fg=cyan][%Y-%m-%d(%a) %H:%M]"
## リフレッシュの間隔を設定する(デフォルト 15秒)
set -g status-interval 60
## ウィンドウリストの位置を中心寄せにする
set -g status-justify centre
## ヴィジュアルノーティフィケーションを有効にする
setw -g monitor-activity on
set -g visual-activity on
## ステータスバーを上部に表示する
set -g status-position top

# コピーモードを設定する
## viのキーバインドを使用する
setw -g mode-keys vi
## コピーモードの操作をviライクに設定する
bind-key -t vi-copy v begin-selection
bind-key -t vi-copy y copy-pipe "xsel --input --clipboard"

なお、普通にマウスでコピーしたいときは、shiftキーを押しながらコピーすればよい。地味に大事な情報だと思う。

Highcharts

Highchartsは、グラフを描画するJavaScriptのライブラリです。 商用利用にはお金がかかります。

第一引数にグラフ書き込み先のID、第二引数にoptionオブジェクトを渡すのが基本の使い方です。

Highcharts.chart('container', options);

といった形です。

optionオブジェクトで細かく描写を指定できます。指定方法はこちらにリファレンスがあります。

実際に描写を設定したいときは、上記のリファレンスから適当な単語で検索すればいいと思います。例えばタイトルの配置場所を変えたいとき、「title」で検索すると一覧に「title.align」が見つかります。

どのような単語で検索すればいいか見当がつかないときは、コンセプトのページやそのリンク先を見れば、HighCharts的になんという単語があてがわれているかがわかると思います。

たとえば、月別降水量のグラフ描写を設定していて、月と月の間に引いてある短い線の描写を設定したいとします。英語でなんと呼ぶか、highCharts的になんと呼ぶか、わからないとします。そのようなときは、上のコンセプトのページから「Axes」のページに飛ぶと、該当部分は「tick marks」と呼ばれていることがわかります。リファレンスで「tick」と検索欄に入力すると、関連する設定が出てきます。

JavaScript 分割代入

developer.mozilla.org

分割代入について。 配列からデータを変数に代入する、さまざまな方法が書いてあった。

  • テンポラリ変数を作らずに変数同士をスワップできる。
  • 不要な戻り値は無視し、必要なもののみ選択して受け取れる。「正規表現のマッチから値を取り出す」は真似したいと思った。

未サポートのブラウザが多いので注意。

自分は読み飛ばしたが、リンクには、オブジェクトからの取り出しについても記載がある。

モジュール、凝集度、結合度

モジュール

ソフトウェアは複雑だ。すぐ人間に管理できなくなる。 言い換えると、仕様変更があったとき、どこを変更すればいいのか、すぐわからなくなる。 そうならないために、プログラムを分割して複雑さを低く保つという考えがある。分割したひとつひとつをモジュールと呼ぶ。どういうふうにモジュールを区切ればいいかの指標として、結合度と凝集度という考え方がある。

凝集度

モジュール内の要素がすくないほど複雑度は減る。とはいえ、ひたすら細かく別モジュールに分けるべきではない。管理の手間がむしろ増える。関わりの強い要素をうまくひとつのモジュールとして切り出すべきだ。モジュール内の要素の関わりの強さを凝集度と呼ぶ。 じつは、すべての入出力操作をひとつにまとめたモジュールというのは、凝集度が低い。論理的な関係よりも、機能の関連度で評価するべきだからだ。そういう意味で、オブジェクト指向の多くのクラスは凝集度が低い。各メソッドで凝集度を高くなるように意識すべきだ。 ひとつの機能を実行するためにすべての命令が関連しているモジュールは、凝集度が高い。たとえば、秒速を時速に変換するメソッドだ。

結合度

モジュール内の変更が他のモジュールに影響を及ぼさないように注意すべきだ。他のモジュールへの影響しやすさのことを結合度と呼ぶ。結合度は低いほうが良い。 たとえば、あるモジュールが他のモジュールの内部を直接参照する実装は結合度が高く、避けるべきだ。 結合度が低い(=良い)状態とは、入力データと出力データをやり取りする形でモジュールが結合しているという状態だ。モジュール内を変更しても、入出力形式が同じなら、ほかのモジュールへの影響はない。

Rails MySQL ストレージエンジン

MySQLでは、テーブルごとに「テーブル型」を設定できる。これをストレージエンジンと呼ぶ。 ストレージエンジンが違うと、データの格納、取り出しの内部的な処理が変わる。 各々のエンジンに特徴があり、開発者は目的に応じて使い分けるのが望ましい。 ストレージエンジンには、たとえばMYISAMInnoDB、BLACKHOLE、MEMORYといったものがある。 使用できるエンジンは、

mysql> SHOW ENGINES;

で確認できる。ちなみに横長すぎて見づらければ

mysql> SHOW ENGINES\G

とすれば出力形式を縦長にできる。

現在存在するテーブルの型を知りたい場合、

mysql> SHOW TABLE STATUS;

で確認できる。

Railsアプリを作るにあたり、ストレージエンジンを考えてみた。 トラブル時に対応が載っている可能性が高いため、人気なのを使用したい。InnoDBMyISAMに絞られるだろう。 比べてみると、InnoDBトランザクション処理が可能、外部キー制約が使える、クラッシュ時比較的復旧しやすいとのこと。 MyISAMはレコードのカウントが高速、オーバーヘッドが小さいらしい。

Railsの場合、トランザクションをsave,save!,destroyといったメソッドで活用しているらしい。また、アソシエーションで外部キー制約を活用している。さらに、デフォルトでInnoDBのテーブル型を指定している。ならInnoDBでいいかな?

ほとんどのRailsアプリは、InnoDB使っておけばいいんじゃないかなと思った。

以下参考

MySQL :: MySQL 5.6 リファレンスマニュアル :: 15 代替ストレージエンジン

MySQL :: MySQL 5.6 リファレンスマニュアル :: 14.1.1 デフォルトの MySQL ストレージエンジンとしての InnoDB

ja.stackoverflow.com

rorguide.blogspot.jp

UNIX系OS アクセス権

UNIX系OSでは、ファイルごとにアクセス権(パーミッション、モードなどとも呼ばれる)が設定されている。 これらアクセス権により、ユーザーからのファイルの見え方、操作できることが決まる。

アクセス権は基本的に3種類ある。Read、Write、eXecuteだ。また、権限を設定する対象(クラス)が3種類ある。User、Group、Otherだ。アクセス権と対象の組み合わせで、3×3=計9種類のアクセス権が存在する。このほかに、実行に関係する特殊なアクセス権がある。SetUserID、SetGroupID、sTickyの3種類だ。よって計12種類。それぞれの権限の有無が、ファイルごとに設定されている。

後述の八進数表記を鑑みるに、特殊権限、Userの権限、Groupの権限、Otherの権限、の順にビットがならんでいるのかな?

  • 権限の意味
    • ファイルの場合
      • Read 読み込み
      • Write書き込み
      • eXecute 実行
      • SetUserID そのファイルの所有者としてプロセスが実行される。/bin/passwdで設定されている…そうなんだが、自分のMacだと確認できなかった。
      • SetGroupID そのファイルのグループIDでプロセスが実行される。/usr/bin/write(ほかユーザーにメッセージ発信)で設定されている。
      • Sticky 自分はよくわからなかった。
    • ディレクトリファイルの場合
      • Read 中のファイル一覧が見れる。
      • Write ディレクトリ内の操作(新規作成、パーミッション変更、削除)ができる。
      • eXecute ディレクトリファイルに移動可能。中のファイルにアクセス可能。
      • SetUserID ディレクトリには設定不可。
      • SetGroupID ディレクトリの場合、配下のファイルのグループはそのディレクトリのグループとなる。
      • Sticky 所有者かroot意外は他ユーザー所有のファイルの名前変更および削除ができなくなる。たとえばtmpディレクトリに設定されている。

ls -l を実行すると、ファイルのアクセス権が確認できる。ちなみに左端の文字の意味は下記の通り。

アクセス権は chmod (CHange MODe)コマンドで変更できる。chmodコマンドでのアクセス件の指定方法には、記号表記と八進数表記の二種類がある。

ファイル作成時のデフォルト権限は、"umask"というビットマスクで決まる。通常、新規ファイルは0666,新規ディレクトリファイルは0777からそれぞれumaskの値を引いた権限が設定される。 umaskでは許可しない権限を指定している、と言い換えても良い。 多くの場合は0022が設定されている。 umask で確認可能である。

PHP アクセス権

クラスのメンバーにはプロパティとメソッドがある。 キーワードを指定することで各メンバーへのアクセス権を設定できる。 キーワードはpublic,private,protectedの3種類。定義時にキーワードを宣言する。

あるクラスのメソッドを呼び出したいとき、 メソッドをpublicにしておけば、インスタンスからアクセスすることができる。 privateだと直接アクセスできない。(そのクラス内からしかアクセスできない)

<?php

class MyClass
{
  public function PublicFunc()
  {
    echo "useful function." , PHP_EOL;
  }

  private function PrivateFunc()
  {
    echo "another useful function." , PHP_EOL;
  }
}

$obj = new Myclass();
$obj->PublicFunc(); //呼び出せる
$obj->PrivateFunc(); //Fatal error

ただ、安易にpublicにするのは危険な気がする。どういう危険があるのか、どういうときならpublicにしてもいいのか、わかったら書こう。

<追記>
単にメソッドを使いまわしたいな、というときは、staticを宣言したほうがインスタンスを作らずに済むので良い。

<?php

class MyUtil
{
  public static function StaticFunc()
  {
    echo "useful function." , PHP_EOL;
  }
}

MyUtil::StaticFunc(); //=> "useful function."