好奇心の赴くままに RSSフィード Twitter

2011-06-15 ポートフォワーディングの設定をしてソケット通信をおこなう

1.まずは、macにダイナミック転送(SOCKS prox)の設定をおこないます。

下記設定をおこなっておくとssh ショートカット名のみでsshができるので楽です。


$ vim ~hoge/.ssh/configで下記の設定を追加します。

Host hoge //ショートカット

Hostname hoge //繋ぎたい先のホスト名

IdentityFile ~/.ssh/hoge_rsa //鍵の場所

User hoge //ユーザ名

DynamicForward localhost:1080 //利用するポート番号

※ポート番号1080を他で使ってない事が前提です。

詳細はssh_configのmanpageを参照ください。

一般的なOpenSSHクライアント(sshコマンド)だと、コマンドラインオプションに-vを付加することで

いろいろな情報が出るので、下記メッセージがでるかどうかでうまくいってるか確認できます。

$ssh -v hoge

debug1: Local connections to localhost:1080 forwarded to remote address socks:0

debug1: Local forwarding listening on ::1 port 1080.

debug1: channel 0: new [port listener]

debug1: Local forwarding listening on 127.0.0.1 port 1080.

上記情報を確認できれば、ポートフォワーディングがうまくいっています。

2.ブラウザーからも転送してみる方法(chromeの場合)

chrome拡張機能Proxy Switchy!を導入しましょう。


Optionをおして、設定ファイルを開きましょう。

Proxy Profilesに関して,

New profileで新しくルールを追加します。

Profile Detailsに関して,

Profile Nameには題名を入力します。

Manual Configurationを選択し、SOCKS Hostにlocalhostを,Portに1080を代入します。

その下のSOCKS v5を選択します。

No Proxy forにlocalhost; 127.0.0.1; <local>を代入してsaveして設定終了です。

2010-05-28

svc

svcコマンドはサービス(dnscache,tinydnsなど)を制御するコマンドです

svc オプション サービス

オプション一覧

  • u Up サービス開始.もし,サービスが止まったら再起動させる.
  • d Down サービス停止.TERMシグナルとCONTシグナルを送り,サービス停止後再起動させない.
  • o Once サービス開始.もし,サービスが止まっても再起動させない.
  • p Pause STOPシグナルをサービスに送る.
  • c Continue CONTシグナルをサービスに送る.
  • h Hangup HUPシグナルをサービスに送る.
  • a Alarm ALRMシグナルをサービスに送る.
  • i Interrupt INTシグナルをサービスに送る.
  • t Terminate TERMシグナルをサービスに送る.
  • k Kill KILLシグナルをサービスに送る.
  • x Exit サービス停止後,superviseを終了する.安定したシステムでこのオプションを使うのは良くない.superviseは,止まらないように設計されている.

例:

サービスの起動

svc -u /var/lib/svscan/dnscache

サービスの停止

svc -d /var/lib/svscan/dnscache

サービスに変更を反映

svc -h /var/lib/svscan/dnscache


svcコマンド

2009-11-25

帝国の保守の仕方

1. 戦争は可能な限り避けよ。ただし、いついかなる時にも戦争が始められるかのように行動せよ。訓練を怠ってはならず、常に戦闘準備態勢にあるべきだが、戦争を望んではならない。戦争準備の最大の目的は、戦争を余儀なくされる確率を減らすことにある。

 

2. 敵の情報を心理面も含めて収集せよ。また、敵の行動を継続的に監視せよ。それは生産的活動ではないかもしれないが、無駄になることはまずない。

 

3. 攻撃・防衛両面で軍事活動を活発に行なえ。ただし、戦闘、特に大規模な戦闘は、よほど有利な状況で無い限り避けよ。説得を武力のおまけと考えたローマ帝国のように考えてはならない。武力行使を最小限に留めることは、説得に応じる可能性のある者を説得する助けになり、説得に応じない者を弱める助けになる。

 

4. 消耗戦や他国の占領ではなく、機動戦を実施せよ。電撃戦や奇襲で敵をかき乱し、素早く撤退せよ。目的は敵を壊滅させることではない。彼らは明日の味方になるかもしれない。敵が複数いる場合、お互いを攻撃させるように仕向けられれば、単一の敵よりもかえって脅威は小さくなる。

 

5. 同盟国を得て力の均衡を変えることにより戦争を成功裏に終結させることに傾注せよ。外交は平時よりも戦時においてこそ重要である。銃が口を開けば外交官は黙るという馬鹿げた慣用句は、ビザンティンがそうしたように否定せよ。最も有用な同盟国は、敵に最も近い国である。彼らは敵との戦い方を最も熟知している。

 

6. 政権転覆は勝利への最も安上がりな方法である。戦争の費用とリスクに比べれば実に安上がりなので、不倶戴天の敵に対しても実行を試みるべきである。宗教的狂信者でさえ買収可能であることは銘記すべき。そのことはビザンティンがいち早く気付いていた。狂信者は自分の大義に背く行動の正当化に長けているものなのだ

 

7. 外交政権転覆では目的を達成できず、戦争が不可避となった場合には、敵の弱点を衝く手法と戦術を適用せよ。消耗戦は避け、辛抱強く徐々に相手を弱体化させよ。これは時間が掛かるかもしれないが、急ぐ必要は無い。というのは、ある敵がいなくなったら、代わりの敵が必ず現れるからだ。支配者と国家は興亡を繰り返すが、帝国は永遠である。自ら自分を弱体化させなければ、だが。


米国がビザンティン帝国に学ぶこと

2009-10-29

twitterのプログラマーアカウントリスト

たぶん全員日本人です


nipotan

Perl hacker. Sr. manager at 'livedoor Co.,Ltd.' which runs portal site and various geeky services.


miyagawa

Kind of a symbol of Japanese hacker. CTO of Six Apart. Developer of 'Plagger'. One of top CPAN auther. Former leader of Shibuya Perl Mongers. ex CTO of livedoor Co.,Ltd.


dankogai

One of Perl guru in Japan. He developed encode.pm module. And also he is very famous as a blogger. Sometime he appeared in TV debate show. ex CTO of livedoor Co.,Ltd.


otsune

Internet watcher


nishio

Computer Scientist, Python guy.


Hamachiya2

Security hacker.


monjudoh

JavaScript guy.


yoshiori

Java guy.


koizuka

Developer of big movie delivering service 'Nico Nico Douga' is as popular as YouTube in Japan.


gyuque

JavaScript, Computer scientist, Ph.D student in Univ of Tokyo.


takesako

Current leader of Shibuya Perl Mongers.


shi3z

Runs a company which develops iPhone Apps.


hyuki

Perl hacker, wrote many books.


kawa0117

Web developer(back-end and front-end) in Recruit Media Technology Lab. He works on Open Social.


HolyGrail

Front-end Engineer of Yahoo! Japan.


rkmt

Researcher of Sony Computer Science Laboratory(Sony CSL).


masuidrive

Ruby developer, currently based on Seattle. He is famous for writing code in a bath. This is what I mean.


fshin2000

Developer of famous Japanese mobile interface service of Twitter called 'Movatwitter'.


Kuruma

ex Opera, Web Standards guy.


vant

One of most valuable Web Standards guy in Japan.


masui

Interface guru. ex Sony CSL, Apple. In Apple, he developed Japanese input interface on iPhone. Currently in SFC as researcher.


noriyo

Information Architect. Translate some O'Riely books. She has bririant point of veiw.


keita

Back-end engineer in tha ltd which is held by Yugo Nakamura worldwide-known web designer.


fladdict

Web Designer, iPhone app developer, Flash addict guy. also in tha ltd.


mayuki

Windows app and web service engineer. Developed TwitterIrcGateway.


yhassy

Web designer. wrote some books about CSS.


kazuhito

Web standards guy. He leads Web Standards community in Japan as a WaSP member.


orange_juno

An editor of webzine called 'With D' treats web design, online activity, and design things.


_masaka

Japanese Semantic web guru. Totally smart!


yanbe

"Ph.d student who is interested in web mining, especially social bookmarking services / Software developer." quoted from his twitter page :-P


LIND

baseball_flash、懇親会の人


akiyan

はてぶTV、CakePHPの人


bto

phshの人


cocoitiban

Ethnaの人


elf

よくきたなの人


halt

Ethnavimの人


hiro_y

moonyの人


hnw

round()の人

ichii386

Ethnaの人


iogi

PHP Extension勉強会の人


iteman

Piece Frameworkの人


junya

Sooey、guessworkの人


kensuu

ミルフィールの人


komagata

plnet.jpの人


koyhoge

とにかくすごい人


kumatch

Piece Frameworkの人


kunit

Mapleの人


masaki_fujimoto

PHPEthnaの人


masugata

mbstringの人


memokami

携帯の人


moriyoshi

PHPの人


mumumu

Ethnaの人


nowelium

PHP5の人


p4life

CakePHPの人


rhaco

rhacoの人


rsky

PHP Extensionの人


shigepon

rhacoの人


shimooka

Do you PHP?の人


shin1×1

Twitter検索、CakePHPの人


shoma

HTML_TagCloudの人


sotarok

PHP Framework Fight! の人


suzuki

メールの人


takagi

phpdocの人


tsukimiya

symfonyの人


yando

CakePHPの人


yohgaki

セキュリティPostgreSQLの人


yonekawa

PHP5の人 サイボウズ株式会社


yudoufu

symfonyの人


CanI_61st

中学生、この前rubyの高速化用のバッチを作った


tmtms

MyNAの会長にして日本最古参MySQLerのひとり。MySQL徹底入門の著者、MySQLにおける日本語文字コードの初期実装、なおかつ超^128重要なモジュールであるMySQL/Rubyの開発者としても知られる偉人である。


sakaik

MySQL 徹底入門 第2版や、その他数多くのMySQL関連書籍の共著者として知られる。


ikdttr

MySQLにおいて日本語フルテキストインデックスを使った検索を可能とする「Sennaストレージエンジン」の開発者


hirohama

日本におけるMySQL Clusterの第一人者にして実力者


kazuho

国際的な評価も高いサイボウズ・ラボの奥一穂氏。Q4Mストレージエンジン、Pacificドライバなど秀逸なソフトウェアを世に送り出している


sh2nd

OracleおよびInnoDBエキスパート


kentokushiba

SPIDERストレージエンジンの開発者として有名である。最近はVertical Partitioningエンジン(カラムごとにパーティショニングをするタイプのストレージエンジン)の開発も精力的に行っている。


kazeburo

大規模分散野郎Aチーム。Mixiインフラを支える職人的DBA


tmaesaka

Drizzleやmemcachedなどのプロジェクトにおいて精力的に活動 Tokyo Cabinetにデータを格納するDrizzle用ストレージエンジンであるBlitzDBの開発に勤しんでいる。


stanaka

はてなを果てしなくスケーリング


tokuhirom

えとらぼ


hirose31

えとらぼ


matsunobu

MySQLコンサルタント


RKajiyama

MySQL中の人


meijik

同じMySQLサポートエンジニアにしてキムラデービー代表


nippondanji

漢(オトコ)のコンピュータ


漢(オトコ)のコンピュータ道

30 Japanese geeks you should follow on Twitter

TwitterにいるPHPのすごい人リスト

2009-10-28

交渉

交渉の基本


企業や役所を相手にするときは、

「あらゆる行動を記録しろ。数字をメモしろ。ノートにまとめて、それを交渉の席に持参しろ」


名人の言葉


恐らくは「名人」には、「嘘」や「誇張」も混じっているのだろうし、「証人の○○さん」だって、下手するとその場で適当に思いだした名前なのかもしれない。それでも「○○さん」が証言を否定すれば、「○○は嘘をついた」と叫べばいいんだし、そのとき同席した人が確認をしなかったなら、今度は同席した人たちの怠惰を責めればいい。いずれにしても、名人は絶対損しない。


交渉の手順


1. 相手の「サービス」に、あれこれと難癖をつけてみたり、自己流を通したり、状況をできうる限り複雑にする

2. 付き合いきれなくなった相手が、「要するに」で何かを省略したその瞬間をめざとく記録しておく

3. その人がいない場所で、権威を持った別の誰かと親しく語り、「ここにいない誰か」の不作為や不義を訴える

4. それを否定すれば、自分たちの手落ちだから「交換条件」を引っ張れるし、それを傾聴すれば、今度はたぶん、「これ聞いたよね。その時否定しなかったよね」なんて、言質をとれる

5. たくさん作った「証言」や「証拠」は、裁判一歩手前の状況なんかで、交渉のテーブルに山と積まれて、相手を不利な立場に追い込む武器になる


農作業


こういうのはたぶん、状況を耕して、言葉を蒔いて、証拠や言質を収穫する、どこか農作業に似た営みであって、「耕される」側がどう突っぱねようと、こういうやりかたの上手な人には、あんまり関係ないような気がする。


「証拠と結びついた言葉」が、交渉の貨幣になる。


いざ交渉に臨めば、その人はだから、ものすごい量の貨幣をテーブルに積めることになる。身の回りに起きたあらゆることを記録していたところで、「普通の人」に提出できる貨幣の量なんてたかがしれていて、呼吸するように、何もないところから無尽蔵に交渉の貨幣を生める、こういうプロの人たちには、原理的には絶対勝てない。


そこに居合わせた法律の人たちが、貨幣の「質」を吟味してくれるのを祈るしかないんだけれど、それがきちんとできるなら、そもそも法律なんていらない。


交渉の名人が来た

MyISAMとInnoDBの比較

InnoDBの利点(MyISAMの欠点)

▲障害対応系

・クラッシュしても再起動するだけでリカバリができる

・クラッシュリカバリにかかる時間はテーブルサイズに比例するようなことはなく、コミット済みのデータは修復できる (巨大なMyISAMテーブルのREPAIRには数日単位で時間がかかることがある)

・オンラインバックアップができる

・INSERTやLOAD DATAなどを実行している途中でCtrl+Cでその更新系SQL文を止めても、テーブルは壊れないし、中途半端な状態で更新されることも無いし、スレーブが止まることも無い


▲性能系

・行レベルロックなので並列性が高い(MyISAMはテーブルロック)。またSELECTと更新系SQL文が競合しない。

・主キー検索が高速 (クラスタ索引のため)

・ダイレクトI/O(innodb_flush_method=O_DIRECT)を使えるためキャッシュ効率が高い

インデックスの追加/削除をするにあたってテーブルを再編成する必要がなく、そのインデックスだけを再構築するので効率が良い(InnoDB Plugin)

・Insert Bufferという仕組みにより、セカンダリインデックスへのINSERT処理の効率がMyISAMよりも良い


▲従来は欠点だったが、InnoDB Pluginによって改善されたもの

・グループコミットが無効化されるため同時更新性能が著しく低下していた

I/Oスレッドが事実上読み書き1本ずつしか無かったため並列性が低く、RAIDSSDを有効活用できなかった

CPUスケーラビリティが悪く、4CPUコアくらいまでしかスケールしなかった

・同じ量のデータを投入してもテーブルサイズがMyISAMよりも倍以上大きくなることがある(InnoDB Pluginの圧縮機能を使うことで緩和する手がある)


▲ほか

InnoDBでは外部キーが使える


MyISAMの利点

・WHERE条件無しのSELECT COUNT(*)が一瞬で返る

(InnoDBの場合はテーブルをなめる必要がある)

・メモリにおさまらないほど巨大なテーブルのフルテーブルスキャン系の処理効率が良い

(InnoDBではこうしたバッチ処理バッファプールの中身が追い出されてしまうし、バッファプールの管理オーバーヘッドもあるが、MyISAMは専用のバッファプールを持たないので効率が良い)

OSコピーによってテーブルの移動が極めて簡単にできる

・MERGEテーブルを使うことができる (InnoDBでも5.1のレンジパーティショニングを使えば十分なことは多い)

・リードオンリーのテーブルであれば圧縮できる

ALTER TABLE ENABLE/DISABLE KEYSを使える。例えばインデックスなしの状態で高速にロードして、後からインデックスを有効化とかができる (InnoDB Pluginではインデックス単位の再構築ができるのでかなり緩和できる)

InnoDBはテーブルのオープン処理がシリアライズされるため、大量の数のテーブルを初回オープンするような処理がきつい


▲ソリューションによって緩和できるもの

・クラッシュ時に壊れる問題やリカバリ(REPAIR TABLE)の遅さは、生きているスレーブを使って復旧すれば解決できる

・テーブルが巨大になることで引き起こされる性能問題は、小さなテーブルに分割することで解決できる


MyISAMにしか無い機能

全文検索 (TritonnやSphinx)

GIS


ログ蓄積系のテーブルではMyISAMが良いと考えている方が結構多いのですが、MyISAMでは複数のクライアントから同じテーブルに対してINSERTをすれば競合してしまいますし、InnoDBのInsert BufferのようなI/O最適化の仕組みが無いので、 InnoDBに比べても処理効率が悪いです。MyISAMを活用する場合は、上に挙げたようなテクニックを使って問題を緩和するのが効果的です。


MyISAMとInnoDBのどちらを使うべきか