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."

ビルド関係の言葉

ビルド
実行可能なファイルを生成すること。機械語やデータの羅列になっていることが多い。ソースコードコンパイルし、必要な外部ライブラリや初期化コードをリンクする。
cc,gcc
コンパイルに使われるコマンド。ソースコードを解析してオブジェクトファイルを生成するのが主な目的。
リンク
機械語のプログラム(オブジェクトコード)をリンクさせること。スタティックリンクとダイナミックリンクがある。
スタティックリンク
すべての必要なプログラムを一つのファイルにまとめるリンク。
ダイナミックリンク
実行時に、必要に応じて外部ファイルをメモリに呼び出すリンク。
make
簡単にビルドするためのツールおよびコマンド。Makefileが必要。
Makefile
コンパイル対象、リンク対象、処理方法などの手順ををまとめて記述したファイル。
configure
Makefileを生成するシェルスクリプト。環境に応じたMakefileを生成する。
autoconf
configureファイルを生成するツール。らしい。

テスト駆動開発

テスト駆動開発とは、Test-Driven Development(TDD)のこと。

ふつう、コードを書いてからテストを書くところを、
まずテストを書いて、それからコードを書こうという開発手法。

ふつうの書き方の場合は、設計と実装をコードを書くときにまとめてやる必要があるが、TDDの場合テストで設計、コードで実装と分割できて負担が減るということらしい。

一般に、TDDはリファクタリングまで含めて説明される事が多い。ただ、単体テストを書いていれば、TDDの順番じゃなくてもリファクタリングはできると思う。

そこはTDDと単体テストの言葉の定義の話かもしれない。

リファクタリング

仕事では、時間がなかったり、技術力が足りなかったりして、やっつけでコードを書いてしまいがち。結果、コードが汚くなっていく。コピペの重複コードとか、不適切な変数名とか。

そういうのが積み重なって、コードがわからなくなっていく。それを技術的負債と呼ぶ。とりあえず動いていても、バグ修正や仕様変更、担当引き継ぎのときに苦労することになる。技術的負債を解消することをリファクタリングと呼ぶ。地道にリファクタリングしていくほうが、その時間を新規開発に充てるより多くの場合長期的に得である。

リファクタリングは、まとめてやるととたんに難しくなる。少しずつ、こまめに、毎日やるべき。

大がかりなリファクタリングは、状況を考慮してやるかどうか決定しよう。プロジェクト終了間際にはやる必要がないかもしれない。時間がもったいないうえに、その後コード修正が無いかもしれないから。

とはいえ、リファクタリングは怖い。うっかり変更して、不具合が出るかもしれない。このジレンマを解消するのがテスト自動化リファクタリング後にテストを行い、すべて通れば思わぬ副作用が(おそらく)ないことを確認できる。

ユニットテスト

小さな単位で行うテストテストのこと。小さな単位とは、たとえばメソッドである。

昨今はユニットテストを自動化するのが一般的になっている。
自動化すると、テスト実行の負担がほぼゼロになる。
(そのかわり、テスト自動化のコードを書くため、コードを書く量は大幅に増える。)
つまり気軽にテストを繰り返せる。ちょっと書いて気軽にテストできる。気軽に回帰テストができるので、細かくリリースができる。また、ユニットテストに通っているので、まあまあ安心してリリースができる。

vim ちょっとした繰り返し

使い捨てのちょっとした繰り返し作業は、レジスタにマクロを保存すると楽。 q{register}で保存開始。qで終了。@{regiser}で呼び出し。

たとえば、.erbファイル編集中、コマンドを<%= %>で囲みたいとする。

qaI<%= <ESC>A %><ESC>q

I<%= <ESC>A %><ESC>レジスタaに記録できる。

puts 123
puts 456

の1行目で@aを入力すると、

<%= puts 123 %>
puts 456

となる。2行目を囲むには、2行目でまた@aとしてもよいが、直前のマクロは@@で再実行できる。少しだけ楽。なので2行目は@@と入力。

<%= puts 123 %>
<%= puts 456 %>

レジスタを使ったマクロは以上。

その場だけでなく、今後も使いたいマクロはにmapしたほうがいいかも。

nnoremap <leader>a I<%= <ESC>A %><ESC>

自分は上のように設定している。\aで呼び出せる。