ライブファイルシステム形式とマスタ形式

WindowsマシンでデータをCDやDVD等のディスクに書き込む場合、その際の形式を「ライブファイルシステム形式(UDF形式)」と「マスタ形式(ISO形式)」から選択する。

ライブファイルシステム形式では、書き込んだデータは後から編集可能である。パソコンからCDやDVDの中身を見た時、ローカルにあるフォルダを見た時と同様に表示される。ただし、WindowsXPより古いマシンでは読み取れない。

一方で、マスタ形式では、Windows以外のパソコンやDVDプレーヤー等の機器でも読み込める。書き込んだデータは個別に編集したり削除したりできない。

Windowsマシンを使っている場合の利便性ではライブファイルシステム形式だが、いろんな機器で読み取れる汎用性ではマスタ形式といった感じか。

[参考]

https://www.fmworld.net/cs/azbyclub/qanavi/jsp/qacontents.jsp?PID=9710-8358

Windows標準の書込み機能で書き込む(Windows Vista) Ｑ＆Ａ情報（文書番号：105384）：シャープ

pingで「宛先ホストに到達できません。」が出る場合

存在しない IP アドレスに対して ping コマンドを実行すると、「宛先ホストに到達できません。」と出ることがある。これは、icmp パケットを送信する前段階の arp 要求に対する応答が pingコマンドを実行したマシンまで返ってきていないことを意味している。

上記のケースをパケットキャプチャで観察すると、icmp パケットは出ていない。それの前段階の arp 要求が失敗しているので当然ではあるが、上述のことを意識していないと、「あれ？ping コマンドを実行しているのに、icmp パケットがパケットキャプチャに出ない (　ﾟдﾟ)ﾎﾟｶｰﾝ」となるので注意。。

bonding インターフェースに対するtcpdump

Linuxには、複数の物理インターフェースを論理的に一つと見なす、bondingという技術がある。

この bonding インターフェースに対して tcpdump コマンドでパケットキャプチャを取得する場合、bonding インターフェースを構成する物理インターフェース(ethX)を tcpdump コマンドの -i オプションで指定すると、パケットの取りこぼしが起き得るらしい。なので、-i オプションには bonding インターフェース(bondX)を指定する。

https://support.hpe.com/hpsc/doc/public/display?docId=emr_na-c03694133

当初は、tcpdump を bonding インターフェースに対して実行できるのか、ということを調べていて、上記の記事を見つけた。

Observerパターン

オブジェクト指向のデザインパターンの一つである、Observerパターンについて簡単にまとめる。

登場するのはObserver(通知を受ける側)とSubject(通知する側)である。このパターンでは、まずSubjectにObserverを登録する。次に、対象のイベントが発生したら、Subjectが、保持しているObserverのメソッドを呼ぶ(Observerに通知する)。そして、Observerがイベントに対応した処理を実施する、というのがざっくりとした流れである。

オブジェクトを通じて行うコールバックのようなイメージだろうか。

gitでコミットする前にステージする理由

gitでは、リポジトリにコミットする前に、作業ディレクトリからステージング領域にファイルを上げる(addする)。つまり、以下のようなイメージ。

  作業ディレクトリ ---add---> ステージング領域 ---commit---> リポジトリ

コミットすると、gitはステージング領域にあるファイルをリポジトリにコミットする。

ここで、何故ステージング領域が必要かと言うと、例えば、しばらくコミットし忘れて、作業ディレクトリ内の多数のファイルを編集した後、編集したファイルのうち一部だけをコミットしたい場合があると思う。この時、コミットしたいファイルだけをaddしておけば、作業ディレクトリに対してコミットした時に、事前にaddしたファイルのみがリポジトリに追加される。まあ、コミットする単位を作業ディレクトリではなく、対象のファイルのみにすれば、ステージング領域は経由しなくても良いのだが。

簡単に纏めると、gitに対して、「作業ディレクトリ内のこのファイルとこのファイルをリポジトリへの追加対象にして下さい」と伝えるために、ステージング領域があるのだと思う。

perlで文字列から1文字ずつ取得

perl で文字列から1文字ずつ取得して配列に格納するには、以下のように split 関数を使うのが楽。

splitString.pl

use strict;
use warnings;
use Encode;

my $inputStr = shift;
my $decodedInputStr = decode('Shift_JIS', $inputStr); # SJISの文字列から内部文字列に変換
my @chars = getCharsArray($decodedInputStr);

foreach my $char (@chars) {
    my $encodedChar = encode('Shift_JIS', $char); # 内部文字からSJISの文字に変換
    print "$encodedChar\n";
}

sub getCharsArray {
    my $str = shift;
    my @chars = split(//, $str); # ★ここ！
    return @chars;
}

上記のスクリプトを、
splitString.pl abcあいう
として実行すると、一文字ずつ分けられて、

a
b
c
あ
い
う

と出力される。

なお、上記のスクリプトは SJIS 環境で実行したので、SJIS の文字列から内部文字列(≒UTF-8)にデコードする処理と、内部文字からSJISの文字にエンコードする処理が入っている。（マルチバイト文字対策）

内部文字コードを意識する時

各プログラミング言語には、内部文字列の文字コード(以下、内部文字コードと呼ぶ)がある。

外部から読み込んだデータをそのままで扱う場合は内部文字コードを意識することはないが、読み取ったデータを文字列として扱ってゴニョニョする場合は、一旦、内部文字コードに変換されることになる。なので、外部から読み込んだデータの文字コード⇒内部文字コードへの変換の処理(デコード処理)を書かないといけないことが多い。この処理がないと、誤った変換が行われてデータが解釈不能なものになってしまうことがある。

また、内部文字コードに変換したら、それを出力する時は、出力先で扱える文字コードに合わせて、内部文字コードから外部文字コードに適切にエンコードする必要がある。