blog

Profile

mewlist
mewlist
寄り道する
音楽バカ
  • mixi
  • friendfeed
  • twitter

  • 29
  • 30
  • 31
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 1
  • 2

Categories

Discography

  • Unities_128 UNiTiES
    2009
  • Human_128 HUMAN
    2005
googleで「MSNメッセンジャー」を検索

メッセンジャーのページに行こうとして一番上の広告をクリックしたら、googleデスクトップ。

結構アクドイきがするんだけど、どうなんだろう。
ちょっとありえないと思った。


ネットワークプログラミングの勉強 #1
浅い知識の土台を作るため。間違いの突っ込み歓迎です

*

ブロードキャストパケットを聞いて、発信元のIPとポートを取得するの。



// ブロードキャストパケットを聞く
// on FreeBSD g++

#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <unistd.h>
#include <iostream>

int main()
{
int sock;
struct sockaddr_in addr;

sock = socket(AF_INET, SOCK_DGRAM, 0);

addr.sin_family = AF_INET;
addr.sin_port = htons(65530);
addr.sin_addr.s_addr = INADDR_ANY;

int one = 1;

// ブロードキャストパケットを話せるように
setsockopt(sock, SOL_SOCKET, SO_BROADCAST, (char *)&one, sizeof(one));

// ソケットとアドレスのひもづけみたいなの
bind(sock, (struct sockaddr *)&addr, sizeof(addr));

char buf[100];
memset(buf, 0, sizeof(buf));
while(1)
{
sockaddr_in addr_from;
memset(&addr_from, 0, sizeof(sockaddr_in));
socklen_t fromlen = sizeof(addr_from);
size_t count = recvfrom(sock, buf, sizeof(buf), 0, (struct sockaddr *)&addr_from, &fromlen);
buf[count]='\0';

std::cout << "from : " << inet_ntoa(addr_from.sin_addr) << ":" << addr_from.sin_port << std::endl;
std::cout << "data : " << buf << std::endl;
}

close(sock);

return 0;
}



*

blog内の検索(自分で検索できるように)意識して書いていくのはよいかも。


Visual Studio 2005が満足するPC
ウチのPentium4 1.5G では、もうそろそろ我慢の限界に来ている。

限界というのは、単純にPCの性能の話。
作業中のいろんな局面でストレスを感じるようになってしまった。

*

小規模のソースコードであれば、別段問題はないのだけど、依存する外部のライブラリや、プログラムの構造が複雑になっていったとき、InteliSense のデータベース更新が入るとほかのアプリケーションの操作もままならないほどCPUを占有してしまう。

コンパイルの速度も気になりだしている。よい環境というのを一度知ってしまうと、それ以下の環境に戻ったときに、今まで問題と感じていなかったことが、ストレスフル。

*

かといって、3.0GのPCでも、VS2005 はストレスが多い。
そもそも、VS2005はデュアル(コア)CPUのPCじゃなきゃ、快適に作業できないんじゃないかと感じていて、InteliSenseがあそこまでCPUを占有するというのは、マイクロソフトもそういう環境を想定しているからだと思う。

*

音楽PCは申し分のないものを使っていて、プログラム環境はいつもそのお下がりPCという位置づけだったけど、VS2005をまともに使おうと思ったら両方ともチョッパヤPC使わないといけないなぁと思った。

*

サーバにしている FreeBSDは Pentiumiii なんだけど、このCPUは昨今のCPU事情と比べると、脅威の低消費電力なので、しばらく現役でがんばってもらおう。

*

重いと感じるソフトを立ち上げたり使うことは、「重い」腰をあげることにほかならない。
その敷居が下がるだけでモチベーションはかなりあがる。

*

「環境のせいにしてりゃ物事楽」なんて話じゃない。
環境を作れなかった自分のせいなんだから。


RubyのPlagger
みたいなのを知り合いが今作っているらしい。

期待!


Plagger インストール
FreeBSD4 の初期から update で維持しているサーバに textproc/p5-Plagger を入れるのに、丸二日は費やした。

Perlが古いと怒られ、deinstall しろと怒られ、依存関係を修復するのに何回もキーを叩いてやっとインストールできた。

*

インストールしただけで満足


してはいけないな。。。

うぅむ、差し迫ってしたいことはないんだけど


デプロイメントとは(勉強)
勉強用まとめ。


デプロイメント:難しそうな言葉だが、Windowsで行われているインストールよりもことは単純で、構成どおりにファイルが配置されていさえすればよい。

多くはwebサーバに対するファイルの更新であるから、サーバの再起動など自由にコマンドを実行できれば良い。

*

極端な話、コピーできてコマンドが実行できればすべては事足りるし、多くのツールはそういったつくりになっている。

*

ツールで実現されているのは、リモートサーバへのデプロイメントを楽にするためのスクリプティング手段である。

*

どんな複雑なことだって、Windowsならツール類そろえてバッチファイル書けばなんだってできるわけで、そのバッチファイルを書くということが煩雑な作業になりやすい。

*

だから、ディプロイメントツールなんてものが作られているわけだ。

*

「ディプロイメント用ツール」という部分に本質はない。
本質的なことは、スクリプトの設計だ。

何でもできるスクリプトに何でも書かせるのは、作業を軽減することにはつながらない。

何かに特化したスクリプトを作ってあげてこそ作業が軽減する。

*

あと、ディプロイメントツールをあちこち見てみると、svnをファイルの配置作業に使っていることが多い。これは気に入らない。どんなサーバにもsvnが入っているとはありえないし、内部の信頼できる管理のもとに置かれているサーバ以外へのディプロイメントも行える必要がある。

*

ディプロイメントツールは、リモート上での作業を、リモートであることを意識させないスクリプティングでできるかどうかが肝であると思った。

結局どんなファイルの配置でも行えるようにするためには、どんなこともできる処理系が必要になるわけで、自分の考えてきたことが全然本質からぶれていないと、思い直すに至った。

- バッチファイルもかけなきゃいけない
- でも作業も軽減できるようにしなきゃいけない。

なんか、こういった分野に望まれているのは、「ハイブリッドスクリプティング」だとおもった。

「ハイブリッドスクリプティング」
この言葉、ふと思いついたけど、めちゃくちゃしっくりきた。


boost spirit
spirit
またまた勉強がてらいじり中…。

*

前やったときより時間を置いたせいかすんなり理解できた。

構文木を作るパース方法だと、スキップパーサがかなり重たい。読み込んですぐ実行みたいなスクリプトで使えるスピードじゃない。

全部セマンティックアクションのみで自前で構文木作成を目指す。

*

次のようなテスト用スクリプトを解釈するパーサを作った

(いんちきプログラムなのでめちゃくちゃです)


class c : base
{
var a;
var b=2;
function func(){echo("test");};
function test(a,b)
{
this.a = 2;
return;
}
var a = new hogehoge();
a.test(1,2);

if (test==3)
z=2;
for(a;;a)
;
foreach(k,v in c)
{
while(k==true)
{
echo(k+v);
if(true) break;
}
}
}

パーサの作成はさくっとやってしまって、完成したら、ecmascript のようなテンプレート方式を採用して実装する方針。

構文解析を作るのは楽しい。
時間はかかるけども、ひとつひとつブロックを積み上げていく感覚。バランスが悪いと崩れてしまう緊張感。

最終的には、C++のクラスと、スクリプトのオブジェクトが連携するようにしたい


コメントスパム
最近またひどい。

世の中には公開されているプロクシがあふれていて、ありとあらゆるIPからスパムが投稿される。

時限で書き込みを反映するのに僕の承認が必要な処理をしているのだが、先週は週に何百件ものスパム投稿が保留状態に。

消すという作業がばかばかしくなってくる。

今把握しているスパム発信元になっているプロクシは約250ホスト。

確定時にゲイツをクリックするようなロボット排除機能を入れようか。


ReactOS
http://www.reactos.org/xhtml/en/index.html

WindowsXP 互換OS
スクリーンショット見る限り問題なさそうな印象。

どのくらい時間掛かってるんだろうな、これ。


IdentitySystem
IdentityProviderが色々出てきていて、規格の違うものがたくさん。

多様性を認めるという流れから、全部共通化した規格で縛るのではなくて、どのIdentitySystemも統一的に利用できるようにしようという考えが生まれてYadis

「君のIdentityはどれとどれとどれ」というのを記述できるようになっていくようだけど、サービスを提供する側にしてみれば、可能な限り多くのIdentitySystemに対応したいという要求がある。

複数のIdentityを使い分ける状況で、考え付くニーズとしては、メッセンジャーを2アカウント取得してコミュニティを切り分けたいというもの。

覚えておくべきアカウントとパスワードのセットはできれば一つが理想なので、IdentitySystemの中に、拒否リストみたいな安直な方向ではない、コミュニティへの障壁の置き方が必要だと思う。

他のニーズとしては、IdentityProviderそのものへの信頼かな。

そういったSingleSignOn が思いつく限りどこでも利用できる時代が来るとして、データを安心して預けられる場所の問題が片付かない限り、やっぱり自分でサーバを用意してしまうのだろうなと思う。


iName は、今のDomain のような利用・管理方法になっているようなので、悪意を持ったIdentity が発生しにくいとも考えるけど、それは一般ユーザーにとっては、ただ敷居が高いだけのこと。