ディスクの故障とデータのサルベージ

ディスクの故障、ある日突然やってきます。残念ですが、ハードディスクは消耗品であり、ある日突然データが読めなくなっても不思議ではありません。現在普及しているUSBメモリ・SDカード・SSDも物理的には安定とはいえ、何らかのトラブルが起これば読み込みができなくなることも多々あります。

自分がトラブルに陥った時に、たいへん助かったツールをご紹介いたします。

まずはじめに・・・

あなたがこのサイトを、Googleで探し当てたということは、おそらくデータのバックアップを取っていなかったということを意味するのだと思います。

今回を契機に、適切なバックアップ環境の構築をおすすめします。データの復旧は、バックアップの何倍もコストが掛かり、時間を浪費し、また確実にデータが戻ってくるとは限りません。

データ復旧専門の会社

復旧には手間も時間もかかります。もし自信がなければ、お金がかかりますがデータ復旧専門の会社、たとえば日本データテクノロジーさんなどの専門会社さんへ依頼するのがお勧めです。

注意: 以後のソフトウェアはプロフェッショナル向けです。使い方を間違えると、復旧できるはずだったデータが戻らなくなるだけではなく、現在確保できているデータさえ失う可能性があります。

GNU ddrescue

辛うじてデータが読み込みできているディスクに頻繁にアクセスを行うと、それだけでディスクに負担をかけてしまうことになります。まずはディスクをイメージとして確保しましょう。 続きを読む

Pixelmatorの新機能 新しくなった修復ツールがすごすぎる

repair_nosheep

この画像、実は、あるものを消しているのです。どこに何があったか分かりますか?

続きを読む

タブ文字はもう使うべきではない (Python + vim編)

Ubuntu 12.04 LTSからUbuntu 14.04 LTSにアップグレードしたところ、vimの設定ファイルが変わったのか、自分の.vimrcの設定に関わらず、tabstopが8で表示されるようになってしまいました。

tab8

続きを読む

LMS法について

近年、年齢ごとの標準値などを考える際に、LMS法という統計手法が用いられることが多くなっています。

従来の正規分布の考えと、その考え方からなぜLMS法が生まれてきたかを解説します。

続きを読む

gitのお気に入りコマンドなど

お気に入りのgitの設定およびコマンドです。

git status -sb

[alias]
st = status -sb

と登録しておくのがお勧めです。git status –short –branchの省略形です。

通常の場合、

$ git status

を実行すると、

gitstatus

と、本来必要である情報以上にたくさんのメッセージが表示されます。もちろん、なれないうちは大変助かるメッセージではありますが、慣れてくると冗長すぎてむしろ見通しの悪さを感じてきます。

$ git status -sb

では、

gitstatussb

と、本来必要な情報を簡潔に表示してくれます。

git 1.8.4以上をお使いならばGitの更新ログにあるようにstatus.shortとstatus.branchというconfigがありますのでそちらを利用するのもお勧めです。

pager = less -r

(参考: どせいけいさんきより)

git diffなどの結果は、core.pagerで設定したコマンドに送られます。現在の設定が不明な場合は

$ git config --get core.pager

で調べることができます。おそらく、設定していない場合はlessが標準のページャとして使用されていると思います。

標準のlessは長い行を折り返してくれないので、

gitless

こんなかんじで、長い文は右側にはみ出してしまって見通しが悪いです。

.gitconfigに

[core]
pager = less -r

と設定することで、

gitlessr

長い行は自動的に折り返してくれるので見通しが良くなります。

git diff –word-diff

長い行も一度に表示できるようになって少し見通しが良くなったとはいえ、上記のdiffでは結局どこが変わったのか調べるのはかなり大変です。

$ git diff --word-diff

を使うと

gitworddiff

変更になった部分だけをハイライトして表示してくれます。知っていると便利なコマンドです。

git commit -v

コミットログの記載画面にコミット内容を表示することができます。

gitcommitv

こんな感じでコミットログ記載部分の下部に今回のコミットではどの部分が変更されたかが表示されます。

git log –graph

僕のおすすめは

$ git log --graph --date=short --pretty=format:'%Cgreen%h %cd %Cblue%cn %Creset%s'

です。

gitloggraph

こんなかんじで履歴をコンソール上でグラフィカルに表示してくれます。いろいろ設定オプションがありますが僕は上記を使っています。

もちろん、vim上でgregsexton/gitvを使うという手もあります。

僕がMacBookで必ず使う43のソフトウェア達

macapps

最近良く見かけるのでやってみました。

よくあるやつです。

僕がMacを使っていて、なかったら困るソフトウェアをまとめてみました。

続きを読む

Google Code Jam Round 1A – Problem A. Bullseye

Problem A. Bullseye

X個目(0 origin)の黒い円の半径 = (r+ 2X + 1)2 – (r+2X)2

a2-b2=(a+b)(a-b)なので上記 = (2r + 4X + 1)

n番目までの円を書くと、使うインクの総量はΣ(x=0 to n) 2r+4x+1

Σ(x=0 to n) x= n(n+1)/2、Σ(x=0 to n) 1=n+1。

ので、上記 = 2n2 + (2r+3)n+(2r+1)となる。

2n2 + (2r+3)n+(2r+1) > t →  2n2 + (2r+3)n+(2r+1) – t > 0

解の公式より上記nを求める

結局perlでやってみた。

use bignum;
my $case = <>;

for(my $i=0; $i<$case; $i++){
  my @line = split(/ /, <>);
  my $r = $line[0];
  my $t = $line[1];
  my $circles = 0;

  my $n = (sqrt((2*$r+3)**2 - 8 * (2*$r+1-$t))-2*$r-3)/4;
  $circles = int($n) + 1;   # 0 origin

  print("Case #" . ($i+1) . ": " . $circles . "\n");
}

vim QuickRunとsyntasticで clang++のC++11を使う方法

これでMac OS 10.8.3 Mountain Lion + Xcode 4.6.1でもC++11使い放題。

動かない場合はきちんとclang++がインストールされているか、まずはwhich clang++で確認を。

if executable("clang++")
  let g:syntastic_cpp_compiler = 'clang++'
  let g:syntastic_cpp_compiler_options = '--std=c++11 --stdlib=libc++'
  let g:quickrun_config = {}
  let g:quickrun_config['cpp/clang++11'] = {
      \ 'cmdopt': '--std=c++11 --stdlib=libc++',
      \ 'type': 'cpp/clang++'
    \ }
  let g:quickrun_config['cpp'] = {'type': 'cpp/clang++11'}
endif

 

超音波洗浄機

超音波洗浄機を買ってみました。シチズン 超音波洗浄機 SW1500です。

めがね

これでいつでもメガネをきれいにすることができますね。見た目には綺麗になってるのかどうかよく分からなかったですけど、洗浄したあとの水にはゴミみたいなのかけっこう浮いていたので綺麗になったのでしょう。

 

万年筆

というより、一番の購入目的は万年筆の洗浄です。Pilotのcapless decimoに、コンバーターを使用してセーラーの顔料系インクを使用しています。とてもはっきりとした黒で使いやすいのですが、やはり顔料系であり乾くと詰まりやすいので時々洗浄してあげたくなります。

よく水洗いしたしばらく水につけたりしているはずなんですが、超音波洗浄するとやはりまだまだついているインクが残っているようです。

 

ごぼう

 

おまけでごぼうを洗浄してみたら

綺麗なごぼう

 

土がとれて綺麗になりました。

Git:圧縮とリポジトリのサイズ

Git便利ですね。Gitではオブジェクト(ファイルなど)をzlibで圧縮して保持します。それだけではなく、差分を計算したり、複数のオブジェクトを packすることで、単純にすべての履歴を記録するよりも効率的にリポジトリを保持することができます。

% git --version
git version 1.7.9.2
% alias | grep dirsizeinbyte
dirsizeinbyte='find . -type f -print -exec wc -c {} \; | awk '\''{ sum += $1; }; END { print sum }'\'

duだとファイルサイズではなくてブロックサイズになるので上記コマンドを使います。Landscape – エンジニアのメモを参考にしました。

まずはgit initしただけの状態で。

% git init
Initialized empty Git repository in /Users/kcrt/repostest/.git/
% cd .git
% dirsizeinbyte
13917

13.6KiBです。ここからどうなっていくかを見て行きましょう。まずはテキストファイルから。

% cd ..
% perl -e 'for(1..1000000){print "This is a large text file\n";}' > textfile
% wc -c textfile
26000000 textfile
% git add textfile
% git commit -m "textfile"
[master (root-commit) f274f23] textfile
1 file changed, 1000000 insertions(+)
create mode 100644 textfile
% cd .git
% dirsizeinbyte
165888

Gitはファイルをテキストファイルとして認識してくれました。巨大なテキストファイル(24.8MiB)を追加したにもかかわらず、リポジトリのサイズは162KiBに収まっています。これは繰り返し文字列でありzlibによる圧縮が良好に効いていることによります。

ファイルの一部(10000行目のみ)改変してみましょう。

% cd .. 
% vi textfile
(10000行目のみ改変)
% cat textfile | grep test 
10000:This is a large test file
% git add textfile 
% git commit -m "text->test" 
[master a87fd52] text->test
 1 file changed, 1 insertion(+), 1 deletion(-)
% cd .git 
% dirsizeinbyte 
317734

Gitは一行のみの変化であることをきちんと認識してくれました。しかし、リポジトリのサイズは310KiBとなっています。先ほどのリポジトリのサイズが162KiBなのでほとんど倍です。圧縮されて効率的なのは確かですが、ちょっと期待していた動作と違います。1行だけの変更なので、もう少し小さなサイズになることを期待していました。

Gitは、コンテンツの変更の際も単純にリポジトリに新しいオブジェクトとして追加します。これは高速に動作しますが、ディスク容量の観点からは非効率です。差分を探して、不必要なオブジェクトを削除するにはgit gcコマンドを使います。

% git gc 
Counting objects: 6, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (6/6), done.
Total 6 (delta 1), reused 0 (delta 0)
% cd .git 
% dirsizeinbyte 
79679

リポジトリのサイズは78KiBと十分に小さくなりました。一つ目のファイルを追加した際のサイズより小さくなっています。

git gcコマンドは上記のように手動で実行することもできますが、必要と考えられるときやリモートリポジトリへのpushを行う時には自動で実行されます。

それではバイナリファイルの実験に入りましょう。リポジトリを初期化して開始します。

% yes | \rm -R .git 
% git init 
Initialized empty Git repository in /Users/kcrt/repostest/.git/
% perl -e 'for(1..1000000){print "\x00\x01\x02\x03\x04\x05\x06\xfd\xfe\xff";}' > binfile 
% wc -c binfile 
 10000000 binfile
% git add binfile 
% git commit -m "binfile" 
[master (root-commit) 8580c04] binfile
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 binfile
% cd .git 
% dirsizeinbyte 
67942

Gitはファイルをバイナリ(binfile)として認識してくれました。binfileは9.5MiBと大きなファイルですが、繰り返しが多いのでzlibによる圧縮が効率的に行えそうです。リポジトリのファイルは66KiBと期待通り小さなものになりました。

一部を改変するとどうなるでしょうか。

% ..
% vi -b binfile
(:%! xxd 編集 :%! xxd -r)
% git add binfile                                                                   
% git commit -m "small change"                                                      
[master c05696a] small change
 1 file changed, 0 insertions(+), 0 deletions(-)
% cd .git                                                                           
% dirsizeinbyte                                                                     
121847
% git gc                                                                            
Counting objects: 6, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (6/6), done.
Total 6 (delta 1), reused 0 (delta 0)
% dirsizeinbyte                                                                     
36149

binfileに16バイトのわずかな変更を加えました。git gcを行うとリポジトリのサイズは35KiBとなりました。バイナリファイルでも差分による圧縮とzlib圧縮を行なって効率的にリポジトリにファイルが格納されることがわかりました。