見つけたのでメモ。
- random accountの作成
- アプリの登録
ができる。
- client_id
- client_secret
が取得できるので、これを使って
- redirect_uri
を設定すると、redirect 先で
- authorization_code
を取得できる。
OAuth2 の authorization code grant をそのまま試すことができるし、この流れがちゃんと Quick Start Guide
にまとまっているので迷わず使える。
rsync の -C オプションは CVS と似たアルゴリズムで同期対象からファイルを除外してくれる。
- $HOME/.cvsignore
- CVSIGNORE 環境変数
- 各 SRC ディレクトリの .cvsignore
を参照してくれるが、それ以外にもデフォルトで除外してくれるパターンもある。
少なくとも rsync 3.0.7 では
-C, --cvs-exclude
This is a useful shorthand for excluding a broad range of files
that you often don't want to transfer between systems. It uses a
similar algorithm to CVS to determine if a file should be
ignored.
The exclude list is initialized to exclude the following items
(these initial items are marked as perishable -- see the FILTER
RULES section):
RCS SCCS CVS CVS.adm RCSLOG cvslog.* tags TAGS
.make.state .nse_depinfo *~ #* .#* ,* _$* *$ *.old *.bak
*.BAK *.orig *.rej .del-* *.a *.olb *.o *.obj *.so *.exe
*.Z *.elc *.ln core .svn/ .git/ .bzr/
が対象になっている。ということで
- RCS
- SCCS
- CVS
- Subversion
- Git
- Bazzar
これらはデフォルトで対応しているが Mercurial は対応していない。ことが分かった。ちぃ、……覚えられない。
あー。
自分もまだ何がどれとははっきり言えないんだけど、
知識からでも学べることと経験からしか学べないことの違い
じゃないですかね。なんとなくもやもやは分かる気がしますが、何もかも本で解決できるわけはないし、闇雲にただ経験を積ませりゃいいってもんでもないと思います。（そんなことは分かりきっていると言われるかもしれませんが。）
なんでこんな話をしているかというと、自分でもせめて C を知っといてほしいなぁと思うことはあるからです。1ただ、ほしいなぁとも思うが具体的にどう役に立つか、あるいはどう役立てたらいいかは自分の中で明確になってはいません。自分が C を学んだときにはそれ自体が目的で、その知識を援用するという使い方は考えていなかったからです。2
はて。
この状態で C を学ばせて果たして役に立つと思ってもらえるだろうか？ いや、役に立つのだろうか？
今まさにここで行き詰まっています。もう一つはどこまでやらせれば十分という線引きが自分の中にできていない、という問題でもあります。そりゃなんだってできてくれるに越したことはないんだけど、
常に「今それやってもらうわけにいかない」
っつーのがまぁ現実なわけです。さてどうしたもんかと思いつつもリポジトリの話とかステージングの話とか「上の」ことばっかやってますよね、実際。だってそっちも別に「十分」じゃないし、そっちを強化することの方が戦力計算としては重要ですし、もしかすると下のレイヤーのスキルを上のレイヤーで応用できるかどうかも、実はその人次第かも知れないとも思います。なんとなくですが。本当に役に立つと言えるのだろうか？という疑問も実は自分の中にあります。
こういう話って別にプログラミングには限定されない話で、例えばクライアント PC のトラブルを解決する際の当たりの付け方なんてところにも、いろいろなレイヤーの知識とともに経験が総動員されるわけじゃないですか。でもこれってできない人はやっぱできないわけですよ。例えば「実際に今まさに使っている生の PC を相手にするとき」なんかに差が出ます。この場合、どれだけ深いレベルまで下りられるか、根源的な解決を試みることができるかということはたいした問題ではなくて、当座のワークアラウンドを即座に決断、実行して、時間の取れるタイミングを確認し、そこまでをどう繋ぐかを決定する3ことがまず最初に求められる行動4なのですが、これができるようになるにはそれなりに経験が必要です。何せヘルプが飛んでくるときというのはたいていトラブルの状況と同時に、そのうえで遂行中のタスクも切羽詰まっているからです。こういう状況には知識だけではなかなか太刀打ちできません。もちろん知識がなくていいという言い訳にはならないのですけど。
ここまで書いて、「問題」に対処するのに必要な力ってのは、下のレイヤーを知っているかどうかよりも、どんな武器を持っているかってことのような気がしてきました。ソフト、言語においてはバイナリアンとしての力は足腰として重要だと思いますが、我々は普段足腰で仕事してるわけではない。ただしんどい状況になってくると足腰を含めた全身の体力を求められることもある。
できれば全系統の能力をフルに発揮できる「クラピカの無敵モード」みたいな力がほしいです。でもそんなのは無理。そこで我々はこれがあればオレはやっていける、と確信できる必殺技を求めているのではないでしょうか。それがマシン語の人もいれば Perl や Lisp の人もいる。むしろ日本語という人もいる5でしょうし、それは各自が各自の現場でもって確信するのでいんじゃねーの？と思うわけです。で、
自分が必殺技を持つことと他人にそれを習得させることはベツモノ
ってやっぱ思うわけです。だからかな、○○を学ぶべきとあまり言いたくないのは。
というか突き詰めていけばですよ。
○○をやらせるべきか否かを考えている人間ではなく、○○をやりたいぜ、やってやるぜと考えている人間の方にイニシアチブはあるんですよ。「やらせる」とか言ってる人はどうあがいたって他人の頑張りの「結果」しか受け取ることができないんだから、「やらせる」なんて言ってる連中が最も心を砕かなきゃいけないことは
楽しんでもらう、のめり込んでもらうために我々は何をしないべきか？
じゃないのか、と思うわけです。6老害って言われるのはお互いに不幸だもの。
cf.
最近 Perl は CGI の初歩の話ばかりで Perl そのものの話を見つけるのが難しい。現在スクリプトを実行している環境を判別したくなったのでちょっと調べてみた。するとこんなスクリプトで分かりそうだった。
#! /usr/bin/env perl
use Config;
print $Config{'osname'} . "\n";
print $Config{'osvers'} . "\n";
以下 uname -spr と perl -v とスクリプトの実行結果を順に。
Debian 3.0r2
Linux 2.4.18-1-686 unknown
This is perl, v5.6.1 built for i386-linux
linux
2.6.3-deb2-skas3
cygwin 1.5.9
CYGWIN_NT-5.0 1.5.9(0.112/4/2) unknown
This is perl, v5.8.2 built for cygwin-thread-multi-64int
cygwin
1.5.5(0.9432)
FreeBSD 4.10R
FreeBSD 4.10-RELEASE i386
This is perl, version 5.005_03 built for i386-freebsd
freebsd
4.0-current
FreeBSD 4.10R の返事はずいぶんいい加減な数字のような気もするが、これは build 環境なんだよな。
Windows 2000 SP4
This is perl, v5.6.1 built for MSWin32-x86-multi-thread
(snip)
Binary build 635 provided by ActiveState Corp.
MSWin32
4.0
NT 4 で build してる？ 古い Perl for Win32 とか JPerl for Win32 はどうだか分かりません。
MacOS
MacJPerl5 を動かしてみた。
osname='MacOS
osvers='7.5
げ。なんか余計な文字列ついてきてるんですけど。
しかし、Perl 4 以前はどうしてたんだろうか。。。