前の日 / 次の日 / 2010-07
01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

2010-07-18 Sun

上達に向けた努力の成果は受け止め方を工夫するべき

最近は何故か、いろんな職業の人と話す機会に恵まれるようになりました。
そうすると言葉にならないけど感じることが多くなります。
今日は「上達に向けた努力」に関する考え方の工夫について、まとまったのでメモっておきます。

結論としては「上達に向けた努力の成果はアウトプットである。アウトプットされてれば質はともかく万事よし。」と考えよう、ということです。

アウトプットの質だけ見ると、解決方法がない辛さを感じるときがある


上達に向けた努力には様々な形があると思います。努力の成果を計る尺度の一つはアウトプットの量です。アウトプットの量が増えると、徐々にアウトプットの精度が上がり、独自性が増し、成果も沢山出て良いことだらけです。

上達に向けて努力しているときに、自分よりも上手な人のアウトプットを見て自分のアウトプットの貧弱さに打ちひしがれることが、個人的には多々あります。
打ちひしがれるのは楽ですし、いろいろ言い訳を考えて自分の貧弱さから目をそらすのも悪くはないのですが、数時間後に何も解決してないため、さらに愕然としたりします。

上達目的のアウトプットは質はさておき、量で評価しよう


最近、自分よりもある種のアウトプットが圧倒的に上手な人を沢山見て、他人のアウトプットを見てもショックを受けないことが大切ではないか、と思うようになりました。

ミスもOK。稚拙でもOK。好奇心を沢山もって、とにかくアウトプットする。そういう姿勢の人が個人的に素晴らしく見えます。

アウトプットの成果を自ら「アウトプットの質で評価する」とした場合、世の中には様々な上級者がいるので、いつどこから高品質なアウトプットをひっさげて目の前に現れるか分かりません。
自信をもって出力したものが一瞬で無価値になるようなことを繰り返すと、どんなに強靭な精神をもっていても折れてしまうものです。少なくとも僕は万策尽きた時点でボッキリと折れます。

他方、アウトプットの成果を自ら「アウトプットの量で評価する」とした場合、周りにどんな上級者がいようとも、それ自体はあまり関係ありません。
自分のアウトプットの質が自分で許せるラインに到達していなくても問題は起きていません。起きていないと考えます。
これでアウトプットする度に無力感に襲われる負の連鎖に落ちることもなく、明るく出力ができます。

上級者はアウトプットの量が多い


しかし、そのときに気がつくことは「上級者は圧倒的にアウトプットが多い」ということです。
アウトプットの量だけで見ても、上級者に勝てないことが多々あることに気がつきます。
上級者はアウトプットの精度が高いだけでなく、いつのまにかアウトプットの速度が速くなっており、同じ時間で大量にアウトプットできます。

しかし、そのようなアウトプットの量で負ける問題は努力で解決できます。出来ない場合もありますが、できる場合がかなり多いのでは。
小粒で良いからとにかくアウトプットし、寝る間を惜しんで出し続ければ、量で勝てる可能性はあります。
相手も人間なので風邪をひくこともあるし、用事もあるし、やる気が無い日もあるので、相手が完全に止まってる日ならちょっとやるだけでもアウトプットの量で負けません。

量での評価は自分との戦い


量で評価するようにすると、全ては自分の内側での自分との戦いになります。
子供のころにラジオ体操のスタンプを押してもらいましたが、あれも行くことに意義がありました。
上手にラジオ体操ができたか、とか、ちょっと遅刻したか、とか、そういうのは関係ありませんでした。
毎日一個ずつ「毎日えらいね」とスタンプを押してもらえました。
子供心にあのスタンプはとても達成感があったなと思い、何が良かったのか時々考えています。

では、どの程度アウトプットすることを自分に課すべきか、というと、たぶん自分が負けたくない人よりも多くアウトプットすれば良いのではないかと思います。
どういう人に負けたくないか、というと、職業でアウトプットしている人は素人には負けたくありませんね。
例えばレストランのシェフの1日に料理をつくる回数が専業主婦に毎日毎日負けていたら何か嫌です。
まぁ、そんなに急激に腕は衰えないと思いますが。

おわり


ということで、上達を円滑にするには「出力の量を増やし、出力の質には一旦目をつぶり量だけ見よう。量の目標はライバルを見つけてそれ以上に出力するようにしよう」と考えてはどうかな、と結論づけて、一旦終わります。眠い。

投稿者:としのり  日時:23:59:59 | コメント | トラックバック |

ソースコードを private なレポジトリから github やレンタルサーバ上の git へ移動

とある事情から、ずっと手元のVM上のgitで一元管理してるソースコード管理を、状況に応じて別のレポジトリで管理するように切り替えることにしました。

僕以外の人には、ほとんど関係のない話です。

以前からコードを外部のリポジトリで管理しても、手元に全部のコードが残るので問題は無いし、そもそも僕の書くコードを流用する奇特な人はそんなにいないと思うので問題なさげ、と思っていました。
でも、手元のVMで管理が間に合ってるため外部公開とか面倒くさいし、CodeReposも最近は全然使ってないし、僕のコードは万人が頻繁に使う公共性の高いものではないのでユーザも居ないし、あんまり気持ちよく感じないなと思ってました。

今回の件は @mamoruk さんから、かなり背中を押されてやっとやり始めました。感謝。やりはじめると不思議と手が動きます。

状況に応じて管理方法を分けることにした


ソースコードは公開して平気なコードから、公開したら絶対駄目なコードまでいろいろあるので、自分でコントロールする必要があるコードはよりプライベートなgitレポジトリで管理することにした。

レポジトリ管理するコード
github公開して大丈夫で、とくにパッケージにもなってないコード
レンタルサーバ上のgit公に公開できないけど、知人に見せたいコード
手元のVM上のgit絶対公開できないコード
自分のサイトかGoogle Codeアプリケーションがまとまったらパケ化して上げておく

アプリケーションについてはアプリケーションごとにWIkiやトップページが欲しいので、自分のサイトで管理するかGoogle Codeで管理しようと思う。
多分、僕のサイト上に置いてあるよりもGoogle Code上にあった方が嬉しい人が多そう。

github の用意


実は github にアカウントを持ってなかったのでアカウント作りからやった。
自分のまとまってないコードを積極的に開示する状況に陥ることは予測してなかった。

20100718_1

アカウントを作ったあとは、以下のように作業をした。

- overlast's private - GitHub
-- http://github.com/overlast/private
Global setup:
 Download and install Git
  git config --global user.name "Your Name"
  git config --global user.email メールアドレス
  Add your public key
        
Next steps:
  mkdir private
  cd private
  git init
  touch README
  git add README
  git commit -m 'first commit'
  git remote add origin git@github.com:overlast/private.git
  git push origin master
      
Existing Git Repo?
  cd existing_git_repo
  git remote add origin git@github.com:overlast/private.git
  git push origin master


push するために追加する必要があるSSH の public キーは ssh-rsa だと怒られたけど、ssh-dss だと怒られなかった。

今後は dotfile など毒にも薬にもならないコードから順にアップしていく。

レンタルサーバ上に git をインストール


さくらのレンタルサーバにgitをインストールしてレポジトリを作った。
サーバの容量の上限が10GByteになったので、やろうと思えば、手元のコードは全部レンタルサーバでも管理できる。

さくらのレンタルサーバにgitをインストール

さくらのレンタルサーバに git の一番新しそうなのをインストール。
今日の段階では 1.7.1 っぽかったので、これをインストール。

実は自分の環境では、gmak中にエラーが起きた。

- @さくら
$ mkdir ~/src
$ cd src
$ wget http://kernel.org/pub/software/scm/git/git-1.7.1.tar.gz
$ tar xfvz ./git-1.7.1.tar.gz 
$ cd git-1.7.1
$ mkdir $HOME/local
$ ./configure --prefix=$HOME/local 
$ gmake 
(中略)
    SUBDIR perl
/usr/bin/perl Makefile.PL PREFIX='/home/overlast'
Only one of PREFIX or INSTALL_BASE can be given.  Not both.
gmake[1]: *** [perl.mak] エラー 255
gmake: *** [perl/perl.mak] エラー 2


たぶん、perlbrewを使っているからかな。
このエラーはINSTALL_BASEを指定して、perlbrewでprel5なモジュールが入るディレクトリを指定すれば解決できる。
あと、このperlモジュールをインストールするときに、manを/share以下にインストールしようとするので、それをローカルフォルダに入れてくれるようにSITEPREFIXも指定。

別途perlモジュールをコンパイルして、続きをgmake。

- @さくら
$ cd perl
$ perl ./Makefile.PL SITEPREFIX=$HOME/local INSTALL_BASE=${HOME}/perl5
$ gmake  SITEPREFIX=$HOME/local INSTALL_BASE=${HOME}/perl5
$ cd ../
$ gmake  SITEPREFIX=$HOME/local INSTALL_BASE=${HOME}/perl5
$ gmake  SITEPREFIX=$HOME/local INSTALL_BASE=${HOME}/perl5 install


.bashrcのPATHに「$HOME/local/bin」を追加して、source ~/.bashrc。

あとは、--bareをつけてinitする。付けないとpushできない。

- @さくら
$ cd $HOME
$ mkdir repos.git
$ cd repos.git
$ git init --bare
Initialized empty Git repository in /home/you/repos.git/


これでローカルからpushするリポジトリはできた。

bareなリポジトリはデータ格納場所なので開発はできない。
cloneして、そこで開発する。まっさらだったら手元のgitリポジトリをadd & pushする。

まずは、ローカルなPC上にディレクトリを作ってgit initしてcommitしてみる。

- @ローカル
$ mkdir repos
$ cd repos
$ echo "This is my git repository" >> README
$ git init
Initialized empty Git repository in /home/you/repos/.git/
$ git add README
$ git commit -m "first commit"
[master (you-commit) 8d0baee] first commit
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 README


今度は、これをレンタルサーバ上のリポジトリに突っ込んでみる。
SSHでpushするとレンタルサーバ上のgit-receive-packを見つけられないので、receive-packオプションでgit-receive-packの絶対パスを与える。

- @ローカル/repos
$ git remote add origin ssh://you@you.sakura.ne.jp/home/you/repos.git
$ git push --receive-pack=/home/you/local/bin/git-receive-pack origin master 
Public key aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa blacklisted (see ssh-vulnkey(1)); refusing to send it
you@you.sakura.ne.jp's password: 
Counting objects: 3, done.
Writing objects: 100% (3/3), 231 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To ssh://you@you.sakura.ne.jp/home/you/repos.git
 * [new branch]      master -> master


問題無いので、再度READMEを編集してadd、commitして、pushする。

- @ローカル/repos
$ echo "I'm very sleepy" >> README
$ git add README
$ git commit -m "second commit"
[master 8044db5] second commit
 1 files changed, 1 insertions(+), 0 deletions(-)
$ 再びpush
うまくいった


うまくいく。

つぎは今度は自分のPCの別のディレクトリでcloneする。
レンタルサーバの$HOME/local以下にgitをインストールしたので、SSHでアクセスするとパスが通っていないことになる。
なので、--upload-packオプションでgit-upload-packの絶対パスを与える。

cloneしたら3回目のコミットをclone先でやってpushもしてみる。

- @ローカル/repos
$ cd ../
$ mkdir repostest 
$ cd repostest
$ git clone ssh://you@you.sakura.ne.jp/home/you/repos.git repos --upload-pack /home/you/local/bin/git-upload-pack
Initialized empty Git repository in /home/you/repostest/repos/.git/
Public key aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa blacklisted (see ssh-vulnkey(1)); refusing to send it
you@you.sakura.ne.jp's password: 
remote: Counting objects: 6, done.
remote: Compressing objects: 100% (2/2), done.
Receiving objects: 100% (6/6), done.
remote: Total 6 (delta 0), reused 0 (delta 0)
$ cd repos
$ ls
README
$ less README
This is my git repository
I'm very sleepy
$ echo "I'm hungry" >> README
$ less README
This is my git repository
I'm very sleepy
I'm hungry
$ git add README
$ git commit -m "third commit"
[master e4fb5a1] third commit
 1 files changed, 1 insertions(+), 0 deletions(-)
$ git push --receive-pack=/home/you/local/bin/git-receive-pack origin master 
うまくいった


うまくいった。
今度は、最初に作ったreposを更新する。

- @ローカル/repostest
$ cd ../../repos
$ git merge origin/master
Updating 68abac3..e4fb5a1
Fast-forward
 README |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)
$ less ./README
This is my git repository
I'm very sleepy
I'm hungry


どうやら大丈夫。
clone、push、mergeが動いているので、多分なんとかなるはず。

ローカルで何かミスったら「git reset --hard ORIG_HEAD」すれば、直前のcommitに戻れる。

こっちでは活発な開発をおこなって、ある程度まとまったら知人にお試し公開する場所にする。

関連リンク


- GitHub
-- https://github.com/

投稿者:としのり  日時:23:59:59 | コメント | トラックバック |

サンマルクカフェ 恵比寿駅前店 (恵比寿)

恵比寿西口の以前にベッカーズがあった場所がサンマルクカフェに。

このサンマルクカフェは2Fにある喫煙席の密閉度が大変に高くできているので、喫煙席からタバコの匂いがほぼ流れてこないです。
1Fはもちろん、2Fに居ても衣服にタバコの匂いが付きません。素晴らしいです!

そこそこコンセントもあるし、コンセントを使っていても大丈夫っぽいので、今後は頻繁に利用する予定。

関連リンク


- サンマルクカフェ | SAINT MARC HOLDING
-- http://www.saint-marc-hd.com/cafe/
- サンマルクカフェ 恵比寿駅前店 - 恵比寿/カフェ [食べログ]
-- http://r.tabelog.com/tokyo/A1303/A130302/13112405/

投稿者:としのり  日時:23:59:59 | コメント | トラックバック |

SUFARY の任意な index を 64bit OS 上で構築するとき

ハマったのでメモ。

結論:後でとくに問題が起きないなら sufary.h を編集して SA_INDEX 型を int 型にすれば良い。

SUFARY の mkary で作れない索引を作る方法


SUFARY 付属の mkary を使うと「ファイルの全ての文字の位置」か「行頭の位置」を索引付けするなら簡単に array ファイル(SUFARY の索引ファイル)を作れる。

他方、各行の一部について部分に含まれる各文字ごとに索引付けしたい(例、CSVファイルの第Nカラムだけ索引付け)場合には、任意の部分の文字位置のポインタをバイナリで吐き出して 、最後に「mkary -so」することが多い。(-so を使うとソートだけ)

そうすることで、欲しい部分については柔軟に検索でき、不要な部分が検索結果に含まれなり、必要最低限のサイズの array ファイルを作ることができる。タスクによってはこのような索引付け方法が必須な場合がある。

このとき、バイナリはビッグエンディアンで出力する必要がある。
出力するバイナリのビット長は SUFARY のヘッダファイルである sufary.h において typedef されている SA_INDEX の型に依存する。

SA_INDEX の型が long だとハマる


sufary.h の SA_INDEX の型が標準だと long 型。

long 型のサイズは OS ごとに異なるが、手元の環境では 32bit long 型は4byteで、64bit long 型は 8byte だった。
もしも long 型のサイズが8byteなときに、4byte 長のビッグエンディアンなバイナリを mkary に入力すると、ソートできなくてSegment Faultする。

そのため特殊な array ファイルを作る際にバイナリを吐き出すプログラムは、環境ごとに異なる long 型のサイズに対応する必要がある。

SUFARY を 64bit OS 上でインストールする際はヘッダファイルを編集


とはいえ、環境ごとにことなる動作をする index 作成スクリプトはちょっと面倒くさい。
またプログラミング言語によっては 8byte 長のビッグエンディアンであるバイナリを出力するのが面倒くさい場合がある。

そもそも SA_INDEX の型が long で定義されているからややこしいことになる。
SA_INDEX の型が int でも、SUFARY を後で問題がとくに考えられない使い方しかしない場合には問題ない。

32bit OS上ののSUFARYでは索引づけできなくて、64bit OS上のSUFARYでは索引付けできるデータを扱うときだけ問題が起きる。
しかし、そのようなサイズのデータはそもそも接尾辞配列でindexするべきでは無いか、接尾辞配列の分散indexをつくるかすれば良い。

ということで、SUFARYの圧縮ファイルの lib/sufary.hを以下のように変更してからインストールする。

- sufary.h
- typedef long SA_INDEX;
+ typedef int SA_INDEX;


これでバイナリを出力するプログラムは 4byte 長のビッグエンディアンなバイナリを出力するようにするだけで、だいたいの環境で「mkary -so」できるようになる。

@echizen_tm さんに相談したら彼が過去に体験済みな問題で解決方法を教わった。ありがとうございます。

関連リンク


- SUFARY 臨時復旧ページ
-- http://nais.to/~yto/tools/sufary/

投稿者:としのり  日時:23:59:59 | コメント | トラックバック |