2009年5月30日
#
概念や価値は認めます。
確かにXMLはテキストベースのツリー構造で何でも表現できる素晴らしい仕組みです。異なるコンピュータ間でも、情報を正確にやり取りできます。例えば、CSVと違って、列の順番や意味を別ルートで事前連絡しなくてもタグによって列の意味がそのXML文書だけで分かります。また、事情により送信側で列の順番を入れ替えても、受信側で混乱することはないなど、CSVよりもメリットが多いです。テキストなのにテキスト以上のものを表現できるのも素晴らしいです。冗長性のおかげで、どこか壊れても修復できる可能性が少しあります。また、数多くの標準化がなされているので異なる環境間でも正確に情報伝達ができることもよいことですね。
最近はさまざまな設定ファイルも、XMLになっています。これはどうかと思います。運用する人またはユーザが設定を変えられるアプリケーションの場合、XMLをいじってもらうのたぶん無理なので、別途、設定ツールを用意しなければなりません。XMLに比べれば昔ながらの.iniファイル、または、Javaの.propertiesつまり「設定名=設定値」などの方が、人間にはやさしいので誰でも設定できるのではと思います。というわけで、設定ファイルにXMLを使うのは個人的に好きではありません。
何か理由があって、設定ファイルにXMLを使う流れになってるのかもしれません。私が知らないメリットもあるのかもしれないです。ご存知であればどなたか、設定ファイルをXMLにする上述以外のメリットを教えてください。また、アプリケーションの設定として皆さん何をお使いですか？
あと、XMLを編集するエディタの決定版といったものってありますか。あれば、教えてください。
いつも、思ってましたが、Excelってすげー！って改めて思いました。
もはや表計算ソフトを超える使われ方をしている。さまざまな使われ方をするExcel。確かにテキストエディタの次に気軽に入力しやすい。Webアプリの入力フォームなんて到底かないません。多分コピペでの貼り付け先ってExcelが一番多いのでは？（推測）
よく「えっ！？そんなことまでExcelでやってるのー！？」とか驚かされることが多いです。Microsoft Officeの他の製品の役割を奪っていたりします。Wordの代わりとして、「～書」がExcelなんてのはざらにあるし、Visioの代わりとして気軽にExcelで図形ドローしたり（絶対座標だから？）、プロジェクトの進捗管理にProjectではなくExcelっていう場合も多い。人間の見た目で「表」を表せるからAccessの代わりにExcel使うこともあるだろうし、コピペの貼り付け先という意味では、OneNoteのお株も奪っていたりする（知名度？）。他のオフィスに表を貼り付ける時もExcelを経由する。VBAっていうとExcelなイメージがある(偏見だろうか？)。企業では、ある意味.NET FrameworkよりもOSの上のプラットフォームとして普及していると言えるかもしれない。「その道のプロ」な人も多いと思う。職人技でExcelを使いこなす。それはそれですばらしい。そういうの見たい。
で、意外な使われ方をしているのを見たとか意外な使い方している、知っている方！コメントください。大いに盛り上がりましょう（←他人のふんどしで盛り上がろうとしている）
2009年4月6日
#
集合写真アップロードしておきます。
なんでアップロードしようとするとエラーになるんだろう？？？
2009年3月18日
#
※注意：以下に書くことはまだ、[SharePoint]WSS3.0の累積的な更新・・・（KB961755）のパッチ未適用の環境でのことです。
あるリストで同一フォルダにアイテムが約2100以上あると、SPList.Items(SPListItemCollection)のメンバ使用するだけでも例外になってしまう場合があります。→[SharePoint]リストにアイテムが約2100件以上あると・・・(続き：再現)
このとき通常のWeb画面でもアイテムの一覧画面で
<!-- #RENDER FAILED -->
と表示されてしまいます。(kb/958577/en,kb/958577/)
このときSPListItemCollectionのCountプロパティやforeachで暗黙的に使用されるGetEnumerator メソッドでも例外になってしまいます。 一度には取得・列挙できません。
そこで、小分けに、IDの範囲を指定して分割して、たとえば100件以内ずつ複数回のクエリに分けて、取得してIDを表示する以下のサンプルプログラムを作成しました。
下のPrintAllListItemIds1とPrintAllListItemIds2はどちらも指定したリスト（ドキュメントライブラリ）のすべてのアイテムのIDを出力して最後に合計件数を出力するメソッド（のはず）です。一見するとどちらも同じ結果が期待できそうです。
[SharePoint]リストにアイテムが約2100件以上あると・・・(続き：再現)のときに作成した、直下のルートフォルダに4024件アイテムが登録されているドキュメントライブラリ（バージョン管理設定、下書きアイテムを表示できるユーザー = 「アイテムを編集できるユーザー 」）があるので、実際に実行してみました。
PrintAllListItemIds1
… … …
Number of Items : 1022
PrintAllListItemIds2
… … …
Number of Items : 4023
PrintAllListItemIds1は何度やってもこうなってしまいます。これは明らかに誤った結果です。
PrintAllListItemIds2も1件違いますが、これは別の問題です。別のユーザーがドキュメントライブラリにアップロードしたばかりでカスタムフィールドを編集していない、バージョン0.1のチェックアウトファイルと思われます。このようなドキュメントアイテムはItemsやクエリ結果に出現しません。
どうやらSPWebオブジェクトをクエリの都度生成しなおさないと、クエリを使用するだけでオブジェクトが何かおかしくなってしまうようです。
using System;
using Microsoft.SharePoint;
namespace TestSPQuery
{
class Program
{
const string QUERY_BY_ID_RANGE = @"<Where>
<And>
<Geq>
<FieldRef Name = ""ID""/>
<Value Type = ""Counter"">{0}</Value>
</Geq>
<Lt>
<FieldRef Name = ""ID""/>
<Value Type = ""Counter"">{1}</Value>
</Lt>
</And>
</Where>";
const int MaxItemID = 4500;//取得する最大IDの目安
const int DEFAULT_ID_RANGE = 100;//１回のクエリ対象にするIDの範囲
/// <summary>
/// start<=ID<endというクエリ
/// </summary>
public static string GetIDRangeQery(int start, int end)
{
return string.Format(QUERY_BY_ID_RANGE, start, end);
}
static void Main(string[] args)
{
String scUrl = "(サイトコレクションURL)";
String siteName = "サイト名";
String listName = "リスト名";
//PrintAllListItemIds1(scUrl, siteName, listName, DEFAULT_ID_RANGE);
//PrintAllListItemIds2(scUrl, siteName, listName, DEFAULT_ID_RANGE);
}
/// <summary>
/// 指定したリスト（ドキュメントライブラリ）のすべてのアイテムのID表示する。
/// </summary>
/// <param name="scUrl">サイトコレクションURL</param>
/// <param name="siteName">サイト名</param>
/// <param name="listName">リスト名</param>
/// <param name="rangesize">１回のクエリ対象にするIDの範囲</param>
private static void PrintAllListItemIds1(String scUrl, String siteName, String listName, int rangesize)
{
using (SPSite site = new SPSite(scUrl))
{
using (SPWeb web = site.AllWebs[siteName])
{
SPList list = web.Lists[listName];
Console.WriteLine("List Title :{0}, ItemCount: {1} ", list.Title, list.ItemCount);
int count = 1;
for (int start = 0; start <= MaxItemID; start += rangesize)
{
SPQuery q = new SPQuery();
q.Query = GetIDRangeQery(start, start + rangesize);
Console.WriteLine(q.Query);
SPListItemCollection itemColl = list.GetItems(q);
foreach (SPListItem item in itemColl)
{
Console.WriteLine("No.:{0} ID: {1} ",count++, item.ID);
}
}
Console.WriteLine("Number of Items : {0}",count-1);
}
}
}
/// <summary>
/// 指定したリスト（ドキュメントライブラリ）のすべてのアイテムのID表示する。
/// </summary>
/// <param name="scUrl">サイトコレクションURL</param>
/// <param name="siteName">サイト名</param>
/// <param name="listName">リスト名</param>
/// <param name="rangesize">１回のクエリ対象にするIDの範囲</param>
private static void PrintAllListItemIds2(String scUrl, String siteName, String listName, int rangesize)
{
using (SPSite site = new SPSite(scUrl))
{
using (SPWeb web = site.AllWebs[siteName])
{
SPList list = web.Lists[listName];
Console.WriteLine("List Title :{0}, ItemCount: {1} ", list.Title, list.ItemCount);
}
int count = 1;
for (int start = 0; start <= MaxItemID; start += rangesize)
{
using (SPWeb web = site.AllWebs[siteName])//クエリの度にサイト(SPWebオブジェクト)を生成。
{
SPList list = web.Lists[listName];
SPQuery q = new SPQuery();
q.Query = GetIDRangeQery(start, start + rangesize);
Console.WriteLine(q.Query);
SPListItemCollection itemColl = list.GetItems(q);
foreach (SPListItem item in itemColl)
{
Console.WriteLine("No.:{0} ID: {1} ", count++, item.ID);
}
}
}
Console.WriteLine("Number of Items : {0}", count - 1);
}
}
}
}
2009年3月15日
#
今回は普段のわんくまとは一風違う、DTM（音楽）がテーマの勉強会でした。
私は多少、音楽には苦手意識があるのですが・・・そんな音楽とは無縁の私でも楽しかったです。
たまには、そういう少しかわったテーマもいいですね～
スピーカーの方々がとても楽しそうでしたー
「歌姫調教のすべて」
最初ははつねさんによるミクの調教のお話
ボーカロイドソフトの紹介と扱い方、ミク調教メニューの紹介、楽曲との合成方法の紹介・・・
ミクのために調教した歌をルカに歌わせたらそっちの方がうまかったというのはおもしろかったですｗはつねさん的には調教しなければならないミクのほうがかわいいそうですｗ
私はDTMもボカロもできないけど、ミク歌はニコ動でよく聴きます。作者さん達はこれらを工夫・試行錯誤して作品を作っているのかと想像すると苦労がしのばれます。パソコン、インターネット、DTMソフト、ボーカロイドやニコニコ動画あとTwitterのある時代生きていてよかったです。
「テキストで音楽を操る方法(Muse活用術)」
Museの作者である加藤さんによるMuseのお話
私は知らなかったのですが大きなコミュニティまで自然に形成されているMuseというテキストでMIDI音楽を作成するフリーソフトを開発者ご本人がご紹介。すべてCで、しかもエディタまでそのために自作されるとは！コンピュータや音楽の知識がなくても使えるのように作らていて、多くのユーザ（Muserというらしいｗ）により多くの作品が生み出されているそうです。広がり方がすごい！そのようなソフトの作者がわんくま勉強会でセッションされるとは！わんくま素晴らしい！デモはとても素敵なものばかり！ネタ物も面白かったですｗ「ライブコーディング」もされてましたｗ
・・・これを使うと、音楽とか無知で疎遠な私でもなにかできるな・・・？
「続・C#であそんでみた ～VSTによるMIDIシーケンサ拡張のおはなし～」
こくぶんさんによるシーケンサ拡張プラグインのお話
シーケンサ（あらかじめ入力してある手順を自動で再生する装置・ソフト）を拡張するプラグインのうちスタンダードになっているVST(Virtual Studio Technology)についてご紹介、利用方法、アプリケーションから利用する方法の紹介と作成に奮闘しているお話。VSTHostを経由して自作アプリからミクにしゃべらせるといものを作られたそうです。
デモのいくつかは魔物に邪魔されてしまったようですが、こくぶんさんは5月もセッションするのでｗ 5月の内容はOslo。ミクが50分Osloについてしゃべるのでしょうか？ｗｗｗ ルカでもおｋ?ｗ
「打ち込みでオンガク」
今回の勉強会の言いだしっぺcheebowさんによるDTM入門のお話
打ち込みの紹介、必要な物の紹介…PC、DAW(Digital Audio Workstation)ソフト、ソフトウェア音源、オーディオインタフェース、MIDIキーボード、2万円ちょっとで揃うらしい！
で、実演のデモ、このデモのときのcheebowさんがとても楽しそうでした。いろいろいじってみて、好みじゃなかったといってやめたりｗ、機能を紹介して、自分は使わないとか・・・ある意味、おもちゃですね！
見ていて楽しそうだなーいいなーと思いました！
DTMと関係ないですが、cheebowさんの著書「twitterの本」にサインいただきましたー！
cheebowさんは有名なTwitterクライアント「twit」の作者さんでもあります。
cheebowさんは絵も描ける方らしいですね、そちらでも昔からご活躍されてらしい。多才な人はどこまでも多才なんですね～
ぽぴ王子もおっしゃっていましたが、またDTMのテーマの勉強会とかあるといいですね～ DTMはソフトウェアで実現できる部分が多くなったので、昔に比べたら、初心者でもハードルは下がっているのかもしれないですね～
私でもできるかな・・・？
2009年3月14日
#
三月某日・・・2009 MVP Global Summitで訪れたシアトルの、スペースニードル近くのEMPというところで開催されたパーティの会場にて・・・
謎のメイドさんが出現！
パーティを抜け出してお買いものへ逝く謎のメイドさん・・・
近くのQFCというスーパー
海外のMVPの方にも大人気の謎のメイドさん。
Windows Surfaceで遊ぶ謎のメイドさん。
仕事（？）する謎のメイドさん。
お部屋でもパーティ？
聞いた話によるとスーパーのレジのお兄さん2人が、自分たちを納得させるために「近くでパーティがあったんだよ。」という会話を英語でしていたとか。
2009年2月27日
#
[SharePoint]リストにアイテムが約2100件以上あると・・・ の続きです。
「ドキュメント ライブラリ」の同じユーザが閲覧できるアイテムの数が1つのフォルダで約2100件超えている時にWeb画面で
<!-- #RENDER FAILED -->
と表示される件と、Microsoft.SharePoint名前空間のクラスを使用したプログラミングでの
System.Data.SqlClient.SqlException: 着信の表形式のデータ ストリーム (TDS) リモート プロシージャ コール (RPC) プロトコル ストリームが不適切です。この RPC 要求に指定されたパラメータが多すぎます。最大数は 2100 です。
という例外が起こる件についてです。kb958577(機械翻訳kb958577)
確実に再現できるC# コンソールアプリケーションのサンプルプログラムを作成してみました。MOSS2007 SP1(WSS3.0)のサーバーのローカルで実行します。
ファイルを大量にアップロードして、SPListItemCollection.Count プロパティを呼び出すだけです。
まずはSharePointサイトに新規にドキュメントライブラリを作成しておきます。
コンソールアプリケーションを作成して、参照設定でmicrosoft.sharepoint.dllを追加してcsファイル冒頭でusing Microsoft.SharePoint;を書いておきます。次のコードをプログラムの中に記述します。
/// <SUMMARY>
/// 同じファイルをコピーしてドキュメントライブラリに
/// </SUMMARY>
/// <PARAM name="docLib">ドキュメントライブラリ(SPDocumentLibraryオブジェクト)</PARAM>
/// <PARAM name="filePath">コピー元ファイルの絶対パス</PARAM>
/// <PARAM name="loginName">ドキュメント作成者、更新者とするユーザ</PARAM>
/// <PARAM name="start">連番開始番号</PARAM>
/// <PARAM name="end">連番終了番号</PARAM>
private static void UploadManyFiles(SPDocumentLibrary docLib, string filePath, string loginName, int start, int end)
{
SPWeb web = docLib.ParentWeb;
SPFileCollection filecoll = web.Folders[docLib.Title].Files;
string fileName = Path.GetFileNameWithoutExtension(filePath);
string fileExt = Path.GetExtension(filePath);
byte[] fileBytes = ReadAsBytes(filePath);
SPUser user = web.EnsureUser(loginName);
string url = "";
SPFile file = null;
for (int i = start; i <= end; i++)
{
url = string.Format("{0}/{1}{2:D4}{3}", filecoll.Folder.Url, fileName, i, fileExt);
Console.WriteLine("{0} is uploaded by {1}.", url, user.LoginName);
file = filecoll.Add(url, fileBytes, user, user, DateTime.Now, DateTime.Now);
file.Item.BreakRoleInheritance(false);
file.Item.SystemUpdate();
}
}
/// <SUMMARY>
/// ファイルをバイト列として読み込む
/// </SUMMARY>
/// <PARAM name="filePath">パス</PARAM>
/// <RETURNS>ファイルの中身のバイト列</RETURNS>
private static byte[] ReadAsBytes(string filePath)
{
MemoryStream ms = new MemoryStream();
byte[] buffer = new byte[1024];
using (BinaryReader br = new BinaryReader(new FileStream(filePath, FileMode.Open)))
{
while (br.Read(buffer, 0, buffer.Length) > 0)
{
ms.Write(buffer, 0, buffer.Length);
}
}
byte[] fileBytes = ms.ToArray();
return fileBytes;
}
Main()の中で以下の変数の宣言や代入して（省略）下のコードを書きます。
- docLib：そのSPDocumentLibraryオブジェクト。 SPListからasで取得するなど。
- filePath：適当なファイルの絶対パス。
- loginName：に投稿できる権限を持つユーザのログイン名。
・・・
//ドキュメント ライブラリのバージョン設定
//「このドキュメント ライブラリのファイルを編集するたびにバージョンを作成する 」で
//「 メジャーとマイナー (下書き) バージョンを作成する」を選択するのと同様。
docLib.EnableVersioning = true;
docLib.EnableMinorVersions = true;
// docLib.DraftVersionVisibility = DraftVisibilityType.Reader;//（※1）
docLib.Update();
Console.WriteLine("EnableVersioning = {0}", docLib.EnableVersioning);
Console.WriteLine("EnableMinorVersions = {0}", docLib.EnableMinorVersions);
Console.WriteLine("DraftVersionVisibility = {0}", docLib.DraftVersionVisibility);
UploadManyFiles(docLib,filePath, loginName, 0, 2110);
//「この ドキュメント ライブラリ の下書きアイテムを表示できるユーザー」を 「アイテムを編集できるユーザー」にするのと同じ
docLib.DraftVersionVisibility = DraftVisibilityType.Author;//（※2）
docLib.Update();//（※2）
Console.WriteLine("DraftVersionVisibility = {0}", docLib.DraftVersionVisibility);
Console.WriteLine("list.Items.Count = {0}", docLib.Items.Count);//←ここで上記の例外が発生します！！！
ちなみに、（※1）の行をコメント解除して、（※2）の行をコメント化すると例外は発生しません。
Webでの設定画面でも「ドキュメント ライブラリ」＞「バージョン設定」 ＞「下書きアイテムのセキュリティ」＞「この ドキュメント ライブラリ の下書きアイテムを表示できるユーザー」 のラジオボタンの選択によって、以下のように起きない場合もあります。
| アイテムを閲覧できるすべてのユーザー |
この例外が発生しない。 |
| アイテムを編集できるユーザー |
この例外が発生する。 |
アイテムの作成者およびアイテムを承認できるユーザー
「コンテンツの承認を必須にする」が「はい」のとき |
この例外が発生する。 |
2009年2月17日
#
[SharePoint][ドキュメントライブラリ]SPWeb.GetSiteData(SPSiteDataQuery)使えないじゃん！
のエントリの続きです。
残念ながら、SPList.GetItems(SPQuery)メソッドでもマッチするアイテム数が約2100件越えると
System.Data.SqlClient.SqlException: 着信の表形式のデータ ストリーム (TDS) リモート プロシージャ コール (RPC) プロトコル ストリームが不適切です。この RPC 要求に指定されたパラメータが多すぎます。最大数は 2100 です。
という例外が起きました！
そればかりか通常のWebのUI画面においても・・・
リスト（同一フォルダ内）にアクセス権のあるアイテムが約2100件以上ある時にアクセス権を持っているユーザでその一覧を表示しようとすると・・・
<!-- #RENDER FAILED -->
のように表示され、一覧が出てこないことがあります。
これに関してのMSサポートオンラインのKBがあります。
Error message when you visit a sub-folder under a Windows SharePoint Services 3.0 list that contains more than 2,000 list items that have non-inheriting permissions: ”#RENDER FAILED”
（機械翻訳：継承している以外のアクセス許可を持つ 2,000 以上のリスト アイテムを含む Windows SharePoint Services 3.0 のリストをサブフォルダにアクセスすると、エラー メッセージ:”#RENDER に失敗しました”）
WSS3.0のバグということですね。
修正プログラム（kb957691）
957691 (http://support.microsoft.com/kb/957691/ ) Description of the Windows SharePoint Services 3.0 hotfix package (Sts.msp): October 28, 2008
（957691 (http://support.microsoft.com/kb/957691/ ) Windows SharePoint Services 3.0 修正プログラム パッケージ (Sts.msp): 2008 年 10 月 28 日）
がでているのですね。ところそのリンクの下に
Note After you apply this hotfix, you may still receive the error message that is mentioned in the "Symptoms" section. This may be caused by a query that is too long and that has a large number of non-inheriting permissions. In this case, you have to reduce the number of non-inheriting permissions. If you use 5,000 or more non-inheriting permissions in the list, you may encounter this problem.
注意してください。 この修正プログラムを適用した後も、「現象」に記載されているエラー メッセージが表示されます可能性があります。 考えられますが長すぎると多数のクエリによって継承以外のアクセス許可。 継承している以外の数を減らすにあるこの場合、アクセス許可。 一覧で 5,000 またはより以外の継承アクセス許可を使用する場合この問題が発生する可能性があります。
とあります。
すなわち、KB957691の修正プログラムあててもアイテム数の上限が2000件から5000件になるだけ！？
CAMLクエリを使用するAPIを使わないで、SPListItemCollectionとSPListItemを使用するべたなループで条件判断して該当アイテムを取得するか、クエリのWhere句を2000件超えないように調節して複数回実行するぐらいかしかないのでしょうか。それとも別の方法があるのでしょうか？
以下2/17追記：
残念ながら、アイテム数が約2100件超えている場合SPListItemCollectionのメソッドやメンバも同様の例外になります。SPListItemCollection.Count プロパティでさえも同様の例外となってしまいます！
2009年2月11日
#
ドキュメントライブラリにドキュメントが2000件以上ある時に、SPWeb.GetSiteData(SPSiteDataQuery)メソッドを実行しました。GetSiteData()は複数のリストから同時に条件を満たすアイテムのデータを取得できるメソッドです。
SqlExceptionが起きました。
System.Data.SqlClient.SqlException: 着信の表形式のデータ ストリーム (TDS) リモート プロシージャ コール (RPC) プロトコル ストリームが不適切です。この RPC 要求に指定されたパラメータが多すぎます。最大数は 2100 です。
1900件ぐらいだと問題なかったのに・・・orz
結局、GetSiteData()はあきらめて、リスト個別にSPList.GetItems(SPQuery)メソッドを使うことにしました。
SPWeb.GetSiteData(SPSiteDataQuery)使えないじゃん！
以下2009/2/16追記：
SPList.GetItems(SPQuery)メソッドでもマッチするアイテム数が約2100件越えると同様なエラーになります。
通常のWeb画面でもアイテム数が約2100件超えると
<!-- #RENDER FAILED -->
と表示されます。。。（次のエントリに書く予定）
2009年2月10日
#
SharePointで遭遇した不可思議な現象です。
ドキュメントライブラリで複数行テキストカスタムフィールドがあるとします。
- このライブラリにWebの画面を使ってOffice2003ドキュメント(doc,xls,ppt)とOffice2007ドキュメント(docx,xlsx,pptx)をアップロードします。
- そして、編集画面で複数行テキストフィールドに同じ複数行テキストを設定します。
- プログラムから、このフィールドの文字列を取得します。
すると、あら不思議！
- Office2003ドキュメントのフィールドの中の文字列は「\r\n」(Carriage Return + Line Feed)
- Office2007ドキュメントのフィールドの中の文字列は「\n」(Line Feed)
になっています！
一体どうなってるのでしょうか？
2009年2月5日
#
「素数 - Wikipedia」
http://ja.wikipedia.org/wiki/%E7%B4%A0%E6%95%B0
「1とその数自身以外に正の約数がない（つまり1とその数以外のどんな自然数によっても割り切れない）、1 より大きな自然数のこと。」
と定義されています。
この定義に「1 より大きな自然数」とついているのはなぜでしょう？
2009年1月11日
#
皆さん入れてるようなので、とりあえず、何も考えずにWindows 7 Beta (x64)入れてみました。
とりあえず入れただけですが。
ペイントにもリボンが！
電卓に「プログラマ」モード？
コマンドプロンプトにはMicrosoft Windows [Version 6.1.7000]と書いてある！
Windows エクペリエンスインデックス上限は7.9になったようですね。Vista時代は上限が5.9でした。基本スコアは一番低いサブスコアに影響されます。
このマシンはCPUとメモリは7.3でしたが、ゲーム用グラフィックスとハードディスク転送速度が6.0なので、基本スコアは6.0になりました。。。
#0.1ポイントしか上がらなかったか・・・
2009年1月8日
#
古いPCのファイルを見ていて、昔、学生時代、Javascriptで自分自身を出力するプログラムを書いてみて楽しんでたのを思い出しました。昔の自分に負けたくないので、頭の体操に（？）もう一度書いてみました。
→http://iijimas.wankuma.com/2009/01/SelfReplicationJS.html
実行結果は何も面白くありません。数字をカウントアップして表示するだけです。
ソースの表示すると、その都度HTMLが変わっているのがわかります。
このようなプログラム（スクリプト）を書くこと自体がパズルっぽくて面白いと思うのは僕だけでしょうか。
実際の生命とか、コンピュータウイルスとかもこんなアルゴリズムかその応用でできているのでしょうか。
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type" />
<title>Self Replication JS</title>
<script type="text/javascript">
var v="<!DOCTYPE html PUBLIC \"-//W3C//DTD XHTML 1.0 Transitional//EN\" \"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\">\r\n<html xmlns=\"http://www.w3.org/1999/xhtml\">\r\n<head>\r\n<meta content=\"text/html; charset=utf-8\" http-equiv=\"Content-Type\" />\r\n<title>Self Replication JS<"+"/title>\r\n<script type=\"text/javascript\">\r\n";
var w="function encode(s){\r\nvar r=\"\";\r\nfor(var i=0;i<s.length;i++){\r\nc=s.charAt(i);\r\nr+=(c=='\"') ? \"\\\\\\\"\":\r\n(c.charCodeAt()==10) ? \"\\\\n\":\r\n(c.charCodeAt()==13) ? \"\\\\r\":\r\n(c.charCodeAt()==92) ? \"\\\\\\\\\":\r\n(c==\"<\" && i+1<s.length && s.charAt(i+1) == \"/\") ? \"<\\\"+\\\"\":\r\nc;\r\n};\r\nreturn '\"'+r+'\"';\r\n}\r\n";
var x="function next(i){\r\nvar s = v;\r\ns+=\"var v=\"+encode(v)+\";\\r\\n\";\r\ns+=\"var w=\"+encode(w)+\";\\r\\n\";\r\ns+=\"var x=\"+encode(x)+\";\\r\\n\";\r\ns+=\"var y=\"+encode(y)+\";\\r\\n\";\r\ns+=\"var z=\"+encode(z)+\";\\r\\n\";\r\ns+=w+x+y+i+z;\r\ndocument.open();document.write(s);\r\nsetTimeout(\"next(\"+(i+1)+\")\",1000);\r\n}\r\n";
var y="<"+"/script>\r\n<"+"/head>\r\n<body>\r\n";
var z="<"+"/body>\r\n<"+"/html>";
function encode(s){
var r="";
for(var i=0;i<s.length;i++){
c=s.charAt(i);
r+=(c=='"') ? "\\\"":
(c.charCodeAt()==10) ? "\\n":
(c.charCodeAt()==13) ? "\\r":
(c.charCodeAt()==92) ? "\\\\":
(c=="<" && i+1<s.length && s.charAt(i+1) == "/") ? "<\"+\"":
c;
};
return '"'+r+'"';
}
function next(i){
var s = v;
s+="var v="+encode(v)+";\r\n";
s+="var w="+encode(w)+";\r\n";
s+="var x="+encode(x)+";\r\n";
s+="var y="+encode(y)+";\r\n";
s+="var z="+encode(z)+";\r\n";
s+=w+x+y+i+z;
document.open();document.write(s);
setTimeout("next("+(i+1)+")",1000);
}
</script>
</head>
<body onload="next(0);">
</body>
</html>
2009年1月2日
#
文化の違いなのでしょうか。Windows Live の「プロフィールの編集」「名前」「編集」で設定できる「名前」の使われ方について私は違和感を感じます。
以下の画面の左側だけ見れば、通常ユーザは、「姓 (例: 田中):」とあるので、上のテキストボックスには苗字を入力します。「名 (例: 太郎):」の方のテキストボックスには下の名前を入力します。
しかし、右側の説明を見ると
「姓は、連絡先情報の参照を許可した相手に表示されます。」
「名は常に公開され、インターネット上の全員に表示されます。」
と書いてあります。実際下の欄に設定した「名」はたとえば、Windows Live Messengerの「更新情報」部分等に公開表示されるようです。
私はこの「姓」「名」の使われ方についてなじめないので、「姓」に「姓 名」、「名」には「ハンドル」を入力しています。日本と欧米の文化の違いなんでしょうか？
