Clouder::Blogger

よくターミナルで、catとかlessとかファイルなどを見たときに2バイト文字が化けて出力されて以降にlsなどの出力がガタガタになるときありますよね。

あれ、ないですか？それは幸せですね。

僕はよくあるんですけど、そういうときの対処法を昔だれかに聞いて、それ以来この状態になるとずっと今回紹介する技を使ってきています。

やり方は簡単です、ターミナルに以下のコマンド(?)を打つだけです。

% echo ^[c

でも、単純に「echo スペース ハット ブラケット c」って打ってもだめです。
実際には「echo Ctrl-v Esc c」と打っています。

このあとリターンを押せば、あら不思議。
ガタガタしてた出力が直ります。

他にも対処法あると思いますが、僕がよく使うのはこれです。

これはエスケープシーケンスの1種で、この用途以外にもターミナルで色などを変えることもできます。ネットで調べると色の定義とかはあるんですがこの「c」だとこういうことができるっていうのは探してみたのですが出てきませんでした。

この辺のエスケープシーケンス一覧が載ってるところを知ってる方がいたら教えて欲しいです。

gitを手動でmakeしたんですが、コマンド系はさくっとmakeできるのに、make docがなにやらいろんな用意が必要で、めんどくさかったのでメモっておきます。(id:gfxに言われて書いてみたけど、正直参考になるかわかりませんｗ)

ちなみに、ここに書いてあることはMac OS X 10.6.4でしか試してません。

あと、今回make docをする上で以下のサイトを参考にしました。
Tigerのときのメモっぽいけど...。
https://wincent.com/wiki/Installing_Git_1.5.2.3_on_Mac_OS_X_Tiger

まずは、make docに必要なソフトウェア。(あ、もしかしたらこれ以外に元々入ってて気付かなかったものがあるかもしれません...)

• asciidoc
• gettext(getoptに必要)
• getopt(xmltoに必要)
• xmlto

最初のasciidocは、http://sourceforge.net/projects/asciidoc/からダウンロードして、./configure; make; sudo make install で普通にいけます。

問題なのはxmlto。
こちらは最初に紹介したサイトを参考に以下のような感じでmakeしました。

まずは、依存するgettextをインストールします。
こちらは普通にmakeできました。
http://www.gnu.org/software/gettext/ からダウンロードして、./configure; make; sudo make install でいけます。

で、その次のgetoptですが、http://software.frodo.looijaard.name/getopt/ からダウンロードしてきて解凍したら、Makefile の

LDFLAGS=

を

LDFLAGS=-lintl

と修正をしてmake; sudo make install でインストールできるはず。

そして、一番めんどかったのがxmltoのmakeです。
xmltoをmakeする前にいろいろと準備が必要でした。

まず、前述のサイトを参考に

sudo mkdir /etc/xml
sudo xmlcatalog --noout --create /etc/xml/catalog
sudo mkdir -p /usr/local/share/docbook/xsl
cd /usr/local/share/docbook/xsl
sudo wget http://docbook.sourceforge.net/release/xsl/1.75.2.tar.bz2
sudo tar xjvf 1.75.2.tar.bz2

sudo xmlcatalog --noout --add 'nextCatalog' '' 'file:///usr/local/share/docbook/xsl/1.75.2/catalog.xml' --create /etc/xml/catalog

とxsl用のカタログを作ります(てか、実はこれがなんだかよくわかってないｗ)。
ちなみに前述のサイトよりも、ちょっとバージョンが新しめ。

次にxmlのカタログも作ります。

cd /usr/local/share/docbook
sudo mkdir -p xml/4.5
cd xml/4.5
sudo curl -O http://www.oasis-open.org/docbook/xml/4.5/docbook-xml-4.5.zip
sudo unzip docbook-xml-4.5.zip
sudo xmlcatalog --noout --add 'nextCatalog' '' 'file:///usr/local/share/docbook/xml/4.2/catalog.xml' --create /etc/xml/catalog

これが終わったら、xmltoを http://cyberelk.net/tim/software/xmlto/ あたりからダウンロードして、解凍して、./configure --with-getopt=/usr/local/bin/getopt; make; make install をすると、warningが出つつも、なんとかmakeできます。

で、最後に git のディレクトリにいって、make doc; sudo make install-doc とすると、たぶんドキュメントができるはず(warningは出ます)。なぜか、makeにけっこう時間かかります。(使ってるマシンが非力だったからかも)

ということで、あまり参考にはならないかもですがメモということで書いておきます。

自分はあんまり本を読むのが苦手なんです。 そんな本を読むのが苦手な自分がこの半年に買った本をまとめる。

まぁ、もう遅いかもしれないけど、そういう年齢だということで...。
内容は面白くて、文章もとても読み易かったです。オススメ。


なんか流行ってたので。自分は文章がちょっとよみづらいかなと思いました。
結局このあとエッセンシャル版を購入することになった。


会社の人たちと結果を見せ合うために購入。
自分がなにに強みがあるのかわかって結構面白かった。


先に買った「たりないお金―20代、30代のための人生設計入門」の本がとても読みやすかったので、同じ著者のこの本を買ってみた。自分は投資についてよくわからないのですが、発売したのが数年前なので、このままの投資の仕方だと微妙かもという話もあるみたいだけど、投資信託の入門としてはいいと思います。


AS3をわざわざ環境用意しなくてもできるってんで買っちゃいました。


この中にはWeb技術者が知っておくべきことが盛り沢山なので持っていて損はないですね。


自分はネットワークの知識があまりなく、そこがダメダメなのでまずはここから始めようと思い買いました。


ずっと欲しかったんだけど買ってなかったので買いました。
日本のブログの歴史とかが書いてあり、何月何日ごろにこのブログが立ち上がったとかまで書いてあって面白い。以前、友人からこのブログも出てるよって聞いてたので読んでみたら、ちゃんと載っていてビックリした。


なんとなく買ってみた。どんなことしてるかざっくりわかります。


まだ読んでないんだけど、一般的な知識として携帯サイトをどう作るか知りたくて。


あまりにも女子マネージャーのが本の情報としては薄かったので結局購入...。
でもまだ読んでないｗ


第1版ももってるんですが、より実践的な内容になっているというので書いました。


サービスを育てる上で広告は重要。
そこでとりあえず今メインでやっているモバイルの広告から知ろうと思い買いました。


たまたまみつけたんだけど、先に紹介した「投資信託にだまされるな!」に真っ向勝負のタイトルだったので思わず購入。でも内容としては、真っ向勝負はぜんぜんしてなくて時代に合わせたまともな投資についての話になっている。個人的には文章の構成がちょっと読みにくかった。


予約だけした。まだ来てない。

ということで、半年でこんなぐらいしか買ってないですが、ご紹介でした。
本を読むのが遅いので、これでもかなりハイペースで買っている気がする...。

githubとかで他の人のリポジトリをforkしたあとに、元のリポジトリの更新を取り込む方法。

$ git remote add foo git://元のリポジトリ
$ git fetch foo
$ git merge foo/master

これでいける。
たぶん他にも方法はあると思うんだけど

追記(2010-06-25)
lestrratさんから
git pull foo でいけますお。 その前にgit checkout -b for_merge したほうが安全だと思うけど。

との返信を頂いた。
なるほど、その方が簡単ですね。

シェルスクリプト書いてて調べるのに時間かかったのでメモしておく。

• exprの正規表現
  $valにfooかbarかbazどれかが入ってるかどうかを調べるには。

  expr $val : 'foo\|bar\|baz'

  でOK。 でもMac OS X 10.6.3のexprはだめでした。方言があるっぽい。 ちなみにifで使うとしたら

  if [ expr $val : 'foo\|bar\|baz' ]
  then
  ...
  fi

シェルスクリプト書いてて調べるのに時間かかったのでメモしておく。

• ifのOR表現
  

  if [ "x$val1" = "xfoo" -o "x$val2" = "xbar" ]
  then
  ...
  fi

  でOK。「-o」なんですね。 一生懸命「||」って書いてました...。

タイトルの問題ですが、自分はよく以下のような関数でやります。
HTML::TreeBuilderのas_HTML()がうまいことやってくれます。
(実際にはHTML::Element::as_HTML()ですが)

sub _complement_html {
    my $broken_html = shift;
    my $html = do {
        no strict 'refs';
        no warnings 'redefine';
        local *HTML::Entities::encode_entities = sub {};
        local *HTML::Entities::decode = sub {};
        my $tree = HTML::TreeBuilder->new;
        $tree->parse( $broken_html );
        $tree->as_HTML;
    };
    $html =~ s#<html><head></head><body>##g;
    $html =~ s#</body></html>##g;
    $html =~ s#<div>(?:\&nbsp;)?</div>##ig;
    return $html;
}

この関数を使って

<div align="right">foo<font color="#000000">black text

のような閉じてないタグをもったHTMLを渡すと

<div align="right">foo<font color="#000000">black text</font></div>

こんな感じに補完してくれます。

もっと良い方法あるんですかね。
あったら教えて欲しいっす。

% ack --thpppt foo lib
_   /|
\'o.O'
=(___)=
   U    ack --thpppt!

--help みたら --thpppt ってのがあったのでなんだろうと思ったら、こんなのがでた。
それだけです。

2010-03-05に行われたYokohama.pm #5でData::ObjectDriverについて発表したプレゼンを公開します。少しわかりづらい部分を加筆・修正したり、あとなんとなく英語にしてみました。

個人的にD::ODは、やれることは少ないけど、その分ソースが少ないので処理の全部を把握できるし、キャッシュやパーティショニングもサポートしてて使いやすいので、好きなORMの1つです。
興味がある方は是非使ってみてください。

なんか急に書いてみようと思い立ちました。

すべてを書ききれてないし、どの会社なのか、なんのプログラマなのか、どんな立場なのか、だれから見てなのかなど多角的に見たら正しくなかったり当てはまらないところもあるかもですが、個人的になんとなく「よいプログラマってなんだろう？」について現時点で思っていることをまとめてみました。

ちなみに、これらは今の時点で思っていることなので、またしばらくしたら変ってくるかもしれません。

• 目的への近道を知っている
  
  • バグってる箇所を効率的に見付ける方法を知っている
  • 目的の実装をする近道を知っている
  • ターミナルでの操作が早い(我流でもよい)
• 広い視野で設計できる
  
  • 場当たり的な対応をしない
  • 場当たり的な対応ができる(敢えて)
  • 複数人での開発を意識できる
  • プログラム・作業量・インフラなどのコストを計算できる
  • 自分の書いたプログラムの影響範囲を把握している
• 実装が早い
  
  • 無駄な実装をしない
  • 無駄な実装をしてもそれが結果として良い実装に繋がると知っている
  • とはいっても早けりゃいいってもんじゃない
• トラブル経験が豊富
  
  • 経験がものを言う
  • トラブル時になにを捨てて、なにを残すかの選択ができる
  • どこでトラブルっているかの把握が早い、見付けるのが早い
• 温故知新と温新知故
  
  • 古い技術を理解していることで、新しい技術の取捨選択ができる
  • 新しい技術を理解しつつ、古い技術を選択できる
  • 無駄に新しい技術に飛び付かない
• コードが綺麗
  
  • センスが半分(いや半分以上かも...？)
  • 他人のコードを多く読んでいる
  • 無駄なコード(スニペットとか)をいっぱい書いている

人それぞれ思うところはあると思いますが、自分としては現状こんな感じに思っています。