2011/04/20

PowerShell 2.0の文法、仕様などが詳しく書かれたドキュメント(英文)がMicrosoftから公開されました。

Download details: Windows PowerShell Language Specification Version 2.0
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=509b77d0-5e5f-4194-a2d0-61648abfd093

320ページのWordファイルです。私はさっそくダウンロードしてpdfで保存しました。(定義済みフィールドプロパティのローカライズの関係上、ヘッダの文字列にエラーが出ているので修正すると良いです。「Heading 1」を「見出し 1」にすればOK)

PowerShellの文法については公式ドキュメントが長らく公開されていませんでした。私が知るかぎり、5年前にPowerShell 1.0のbeta版が公開されたときに付属していたのが公式から出された唯一のものだと思います(RC版からは現行ドキュメントに置き換え)。今回ようやく公式ドキュメントが公開されたのには、PowerShell言語に「Community Promise」が適用されたことと関係があります。

PowerShell Language now licensed under the Community Promise - Windows PowerShell Blog - Site Home - MSDN Blogs
http://blogs.msdn.com/b/powershell/archive/2011/04/16/powershell-language-now-licensed-under-the-community-promise.aspx

Community Promiseとは、Microsoftが自社開発のプログラミング言語などの特許権を行使しないという宣言で、すでにC#とCLIに適用されているものです。今回、PowerShell言語でもCommunity Promiseが適用され、サードパーティがPowerShell言語の実装を自由に行うことができるようになります。もちろんWindows以外のプラットフォーム上で動作するPowerShellを合法的に開発することも可能になります。すでにPashというオープンソースでマルチプラットフォーム対応のPowerShell実行環境のプロジェクトが存在しますが、このプロジェクトの進行を後押しする決定になると思われます。

元記事:http://blogs.wankuma.com/mutaguchi/archive/2011/04/20/198525.aspx

2009/12/03

TwitterはRESTなAPIを備えているので、httpの通信ができれば基本的にどんな言語でもクライアントを作ることができるのがいいです。そこで私もPSTweetsというPowerShell版Twitterクライアントを作っているのですが、認証周りで問題が発生しています。

Twitterの認証には標準認証とOAuthが使えるのですが、現在はセキュリティ上の理由で標準認証は非推奨です。標準認証がなぜまずいかというと、マッシュアップサービスでTwitterに対して認証が必要な操作をする場合、ユーザーがその第三者のサービスにTwitterのIDとパスワードを送らなければならないためです。そのサービスがユーザーの認証情報を安全に保持してくれる保証はありません。

そこで考えられたのがOAuthという認証方法です。OAuthはとてもややこしいプロセスを含んでいますが、実質はそんなに難しいものではないです。要は、Twitterというサービス(これをサービスプロバイダという)にアクセスするための権限を、マッシュアップやクライアントを提供する第三者(これをコンシューマという)に委譲する仕組みです。ユーザーが「コンシューマを使いたい!」と思ったら、コンシューマは「じゃあついったーのページに飛ばしますから、あなたのアカウントを私が自由に使うことを許可してね」と言います。それでユーザーがTwitterのOAuth承認ページで「許可」すると、コンシューマはユーザーのアカウント情報を使ってTwitterのAPIを叩けるようになり、ユーザーはコンシューマにTwitterのパスワードを知らせることなくコンシューマの提供するサービスを利用することができるわけです。

さて、このOAuthをコンシューマが利用するには、Twitterにあらかじめ申請する必要があります。といっても登録ページでクライアント/サービス名などを入力するだけです。そうすると、コンシューマキーとコンシューマシークレットという文字列をもらえます。これはクライアントを特定するためのユーザー名とパスワードみたいなものです。ちなみにこの情報はコンシューマを提供する人のTwitterのユーザーアカウントに紐づいています。

コンシューマを通じてユーザーがTwitterのサービスを使うには、コンシューマを通じてTwitterからアクセストークンというものを貰う必要があります。このとき、コンシューマはTwitterに毎回コンシューマキーとコンシューマシークレットを送らなければなりません。

ここでコンシューマが独立したサーバーで運営されているサービスならば何も問題ありません。ユーザーがコンシューマキーとコンシューマシークレットを知る必要もユーザーに知られる危険性もありません。ところが、デスクトップクライアントだとどうなるかというと、コンシューマはデスクトップクライアントそのものです。なので、デスクトップクライアントはコンシューマキーとシークレットを何らかの方法で取得し、Twitterに送る機構が必要になります。

ここで、いくつかの方法があると思います。コンシューマキーとシークレットをデスクトップクライアントに暗号化して埋め込むのも一つの方法でしょう。ですが、結局は復号してTwitterに送らなければならないので、その通信をキャプチャすればユーザーは知ることができます。

なぜコンシューマキーとシークレットをユーザーに知られるとまずいかというと、それらを使うとまったく別のクライアントやサービスを、そのサービス名を詐称して作ることができてしまうからです。これがどうして問題なのかというと、そうなるとOAuthの承認が有名無実化してしまうためです。ユーザーがOAuthの承認ページで承認するサービスが本物かどうか調べるすべがありません。

メール登録制にしてコンシューマキーとシークレットを配布するとか考えましたが、なんだか大昔のシェアウェアのようで、なんとかシリアル集がはびこったように誰かが漏らしてしまう危険性を考えると難しいです。

コンシューマキーとシークレットを自分で取得してもらうというのも考えましたが、それはユーザーにとってかなり敷居が高いうえ、クライアント名がみんなバラバラになってしまいます(Twitterクライアント名はユニークであるため)。

コンシューマキーとシークレットを保持し、ユーザーからのリクエストに応じてアクセストークンを発行するサーバーを立てるというのも考えましたが、それってもうデスクトップTwitterクライアントじゃなくて、Twitterマッシュアップのデスクトップクライアントになってしまいます。

なので、デスクトップクライアントでOAuthを使うのは事実上無理なんじゃないかというのが私の結論です。

標準認証でもいいんですが、現在は標準認証は非推奨であり、そのため今からクライアントを作る場合は標準認証だとクライアント名をTwitterに登録することができなくなっています(タイムラインには「APIで」という表示になってしまう)。昔はメールでクライアント名を申請できたんですが、今はできません(この体制になる前に申請されたクライアントなら、今でも標準認証でもクライアント名を名乗れます)。これから作るクライアントで、クライアント名を名乗るにはOAuth必須です。ボット作者など、コンシューマ=ユーザーの場合はそれでもいいんですが…。これはぜひなんとか改善してもらいたいところですね。といっても、Twitter側からみると、それがコンシューマからのアクセスなのか、ユーザーからのアクセスなのか、区別をするのは難しいでしょうから、デスクトップアプリに限り標準認証でもクライアント名を名乗れるようにする、というのは難しいんじゃないかという気はします。

最近、新しいデスクトップクライアントがあまり登場せず、一方でやたらTwitterのマッシュアップサイトが増えたと思いませんか?中には、それデスクトップアプリでいいじゃないというものもちらほら。もしかして、この制限ができたためなんじゃないかと邪推までしています。うーむ、なんとかならないですかねー?

元記事:http://blogs.wankuma.com/mutaguchi/archive/2009/12/03/183506.aspx

2009/08/15

イマイチ注目度の低いガジェットですが、Windows Vista→7でかなり変更があります。まだ開発までは追いきれてないのですが、とりあえず使用方法について気付いたことをメモ。

  Windows サイドバー ガジェット Windows デスクトップ ガジェット
OS Windows Vista Windows 7
デフォルト表示位置 デスクトップの左右どちらか(マルチディスプレイ環境ではいずれか一つのディスプレイ) デスクトップの任意の場所。ただし、デスクトップの左右には目に見えないグリッドがあり、マウスでD&Dすると位置補正がかかる。(シフトキーを押しながらだと補正はかからない)
整列 左右に格納(Docked)時は自動整列 自動整列なし
マルチページ 左右に格納時、はみ出したガジェットは2ページ目以降に表示される マルチページ機能なし
ショートカットキー

Windowsキー+スペースキーで手前に表示
Windowsキー+Gでガジェットの選択

Windowsキー+Gでガジェットの選択
のみ (8/19修正。JZ5さん komvoyさんありがとうございます)

ガジェットの大きさ Docked時は小さいサイズ、unDocked(デスクトップの任意の場所に配置)時は大きいサイズ ガジェットの右上に表示されるボタンで小さいサイズと大きいサイズのいずれかを選択できる
ガジェットの最小サイズ 130 x 55px なし?
起動方法 スタートメニュー→「すべてのプログラム」→「アクセサリ」→「Windows サイドバー」から起動 デスクトップを右クリックし、「表示」→「デスクトップ ガジェットの表示」にチェック
終了方法 通知領域(タスクトレイ)のアイコンの右クリックメニュー デスクトップを右クリックし、「表示」→「デスクトップ ガジェットの表示」のチェックをはずす
ガジェットの追加 サイドバーの上の+ボタンクリック デスクトップを右クリックして「ガジェット」をクリック
なんか、微妙に機能が削られてるというかなんというか…あと、デスクトップ右に並べた時に右にできるスペースが妙に広い。まぁアイコンが大きくなったせいなんでしょうが… 元記事:http://blogs.wankuma.com/mutaguchi/archive/2009/08/15/180164.aspx

2008/12/07

レガシASPでサイトを作ってると、Shift-JISなサイトを作るのが基本になると思います。なんでかというと、FileSystemObjectが基本的にShift-JISの読み書きにしか対応しておらず(UTF-16もいけますが)、いまどきのUTF-8を使うのはちょっと面倒です(FSOの代わりにADODB.Streamを使えば行けますけどどうでしょうねー?私はあんまり好きじゃないです)。

ただ、UTF-8な他のWebサイト/サービスと連携する場合はどうしても避けて通れません。そこでレガシASPでShift-JISなページを作る際、UTF-8文字列を扱う上で知っておくべきこと。

1. escape関数を使うとShift-JISでURLエンコードがされる

ASPはだいたいVBScriptで書くと思うんですが、隠し関数であるescape関数を使うとURLエンコードができます。ですが、escape関数は呼び出し元のページコードの文字コードでエンコードします。なのでShift-JISなページで呼び出すとShift-JISのエンコードURLを出力します。(ちなみにWSHで使うとUTF-16のものになる)

JScriptのencodeURIComponent関数はどんな場合でもUTF-8文字列を出力するので、これを使うといいでしょう。使い方はこうです。

Set sc = CreateObject("ScriptControl")
sc.Language = "JScript"
Set js = sc.CodeObject
Response.Write js.encodeURIComponent("文字列") 

逆にShift-JISなページでShift-JISなエンコードURL文字列を取得したい場合は単にescape関数を呼び出せばいいです。
さらに別なケースですがUTF-8なページでShift-JISなエンコードURLを取得したい場合は、こんな関数を使うといいんじゃないでしょうか

2. XMLHTTPでPostメソッドでSendする際は必ずUTF-8でURLエンコードがされる

Set xh = CreateObject("MSXML2.XMLHTTP")
xh.Open "POST", "http://hogehoge/hoge.aspx", False
xh.Send "文字列"

このように何も考えずに書いても、勝手にUTF-8でURLエンコードされてPostされるので大丈夫です。

3. UTF-8なページのHTMLを読み込む際

標準機能だけでやろうと思うとADODB.Streamを使うしかないと思います。
ちなみに読み込むページの文字コードが不明の場合は判定した上で変換する必要がありますが、これはかなり面倒なので、BASP21を使うといいんじゃないでしょうか。

Function GetPageString(strUrl)
 Set bobj = CreateObject("basp21")
 Set oHTTP = CreateObject("Msxml2.XMLHTTP")
 oHTTP.Open "GET", strUrl, False
 oHTTP.Send
 GetPageString = bobj.Kconv (oHTTP.responseBody,4)
End Function

これは引数にURLを与えるとそのHTMLを文字列として取得します。対象の文字コードが何であってもOKなのがミソ。

4. UTF-8のURLエンコードされたクエリ、あるいはPOSTされたデータを受ける際

これのやり方が分からない!具体的にはトラックバックpingなんかを受け取る際に困ります(さすがにShift-JISでトラックバックpingを送れ!というのはゴーマンだと思います)。私はここだけASP.NETを使って逃げました。どなたかやり方わかります?

追記。Request.BinaryReadしたやつをADODB.Streamにかけたあと&でsplitして=でsplitしてDictionaryに入れてdecodeURIComponentすればいけるかな?

ただし、ここだけASP.NETを使う際にも注意が必要です。まずweb.configの<system.web>セクションに

<globalization
requestEncoding="Shift-JIS" responseEncoding="Shift-JIS" fileEncoding="Shift-JIS"/>

というのを埋め込んで、まずレスポンスエンコーディングをShift-JISにしておきます。IISの設定でもいいですが。

続いてコーディング。Request.QueryStringやRequest.Formは使えないので、Request.InputStreamを使ってごりごり読まないと駄目じゃないかな・・・。なぜかVB.NETですがUTF-8なトラックバックpingをShift-JISなページで受けるサンプルコードを。

Dim str As System.IO.Stream
Dim counter, strLen, strRead As Integer
str = Request.InputStream
strLen = CInt(str.Length)
Dim strArr(strLen) As Byte
strRead = str.Read(strArr, 0, strLen)

Dim Forms As New Dictionary(Of String, String)

For Each item As String In Split(Encoding.UTF8.GetString(strArr),"&")
	If InStr(item, "=") Then
		Dim s As String() = Split(item, "=")
		If s.Length = 2 And Not Forms.ContainsKey(s(0)) Then
			Forms.Add(s(0), HttpUtility.HtmlEncode(HttpUtility.UrlDecode(s(1), Encoding.UTF8)).Trim().Replace(vbNullChar, ""))
		End If
	End If
Next

↑自分でも謎なコードを書いてたのでちょっとマシなのに修正。コンパイル通るかどうかわかりませんが・・・さらにゴミコードが残ってたのでバッサリ切りました。

ただし!これの問題は改行コードが消えることなんです。対処法は見つけていません(勘違いでした)。もっといい方法があったら教えてください。そもそもInputStreamを使わないでRequest.Formとか使いたいんですが、Shift-JISのところにUTF-8が来るとうまくいかないですねぇー。

というわけで長々と書きましたが、Shift-JISにこだわらなければこんなに苦労することはないです。FileSystemObjectがUTF-8を読み書きできないので私はSJISにこだわってるだけです。FSOはWSHからも使いますので・・・

元記事:http://blogs.wankuma.com/mutaguchi/archive/2008/12/07/162931.aspx

2008/11/22

ご無沙汰してます。牟田口です。近況は省略(えー mixiついったーブログその他などを。

さて、最近、spamコメントが鬱陶しくて色々対策を考えてるんですが、手っ取り早く効果的なのはBBQを使うことですね。某巨大掲示板群サイトで荒らしに使われた、おもに公開プロキシのリストをDNSを引いて持ってくるというものです。Perlの実装はこのページにあります。PHPの実装も見かけました

意外と.NET,C#な実装を見かけないので、最近覚えたC#でさくっとかいてみました。

using System;
using System.Net;
using System.Net.Sockets;

namespace CheckBBQ
{
    class Program
    {
        static void Main(string[] args)
        {
            if (args.Length == 0)
            {
                Console.WriteLine("BBQ判定プログラムの使い方:\r\ncheckbbq.exe IPAddressもしくはHostName\r\n戻り値:\r\n-1:失敗\r\n0:串ではない\r\n1:串である");
                return;
            }
            IPAddress[] addresses= Dns.GetHostAddresses(args[0]);
            if (addresses.Length == 0)
            {
                Console.WriteLine("-1");
                return;
            }
            string ipAddress = addresses[0].ToString();
            string[] ipAddressParts = ipAddress.Split('.');
            Array.Reverse(ipAddressParts);

            string hostName = string.Join(".", ipAddressParts) + ".niku.2ch.net";
            try
            {
                addresses = Dns.GetHostAddresses(hostName);
            }
            catch (SocketException ex)
            {
                Console.WriteLine("0");
                return;
            }
            catch (Exception ex)
            {
                Console.WriteLine("-1");
                return;
            }

            if (addresses.Length == 0)
            {
                Console.WriteLine("-1");
                return;
            }

            ipAddress = addresses[0].ToString();
            if (ipAddress == "127.0.0.2")
            {
                Console.WriteLine("1");
            }
            else
            {
                Console.WriteLine("-1");
            }
        }
    }
}

使い方はコードを見てください。これは単に引数のホストをBBQにかけ、結果を標準出力に出すコンソールアプリですが、メソッド化してもaspxに組み込んでもWebサービスにしてもまぁ好きなように使ってくださいませ。

でも、BBQは万能選手じゃありません。本来書き込めるべき人が書き込めないことも多々あります。なので、BBQをまず通してOKならOK、NGならCAPTCHA認証をやってもらう、とかがいいと思います。

トラックバックspam対策もいろいろ考えたんですが、まだ国産のは少ないので、送信データが英字のみをはじく、でも効果は結構あります。このへんmixiでメモったのでコピペ。

トラックバックって
2008年10月11日20:04

黒歴史になるんだろうか
オートディスカバリーはないと微妙だしあるとspamの温床になるし。
何らかの認証の共通規格を設ける?
RSSは2.0で一応落ち着いたけどトラックバックは発展しないままだなー
私はいま、現行規格のまま、オートディスカバリーを有効にしてかつspamトラックバックが送られないようにする方法を考え中
送り元を見に行くというはてな方式も一つの方法論であるんだけど、なんかこう納得できないものがある

コメント
むたぐち 2008年10月11日 20:07
送信元ホワイトリスト方式もなんだか微妙です
むたぐち 2008年10月11日 20:18
excerpt,titleなどの文字列で弾くのはよくある対策だけど根治法じゃない
いたちごっこだー
BBQは使えない。理由は少し考えれば分かりますので略。
やっぱりはてな方式なんかな。urlの先をまず見に行って、そこにこちらへのリンクがなければまず速効NG。
あとはお好みで、引用がなければNGとか。
でもこれって莫大なコストがかかるし送り元を見に行くというのがそもそもなんか根本的にどうなんっておもう。
むたぐち 2008年10月11日 20:38
トラックバックは性善説ベースで作られた規格
引用元を見に行くのは性悪説ベースの対処
両極端すぎる
むたぐち 2008年10月11日 21:08
送り元を見に行く方式の問題はまだあって、A→Bにトラックバックを送信された場合、B→Aに「AにBのURLが存在するか」を確認しに行く。
一見合理的だけど、このトラックバックって誰でも送れるんだよねー。Aを書いた人じゃなくても。つまり、AともBとも関係ない悪意を持つxがいて、A→Bへのトラックバックを乱射した場合どうなるか。B→AのDoS攻撃みたいなんが成立しちゃう。同ドメインへの確認間隔を制御する必要がでてくる。でもそれはもちろん正しくサービスを利用する人にとっては不便になるわけで。
むたぐち 2008年10月11日 21:28
送信元を見に行く方式で、トラックバックを送った人のリモートホストと、urlに指定されたWebサイトのドメインが一致するかまず調べるという方法もあるけど(たぶんはてなではこれをやっている)、これは正しい使い方をしていても一致しないことも当然あるわけで(手動でトラックバック打つときとかね)。だけどこの辺が確かに手の打ちどころではあるようには思う。手動で打つ時はオートディスカバリー関係ないしな。ただ、私のようにDNSの逆引きができないというか正逆で結果が異なるようなサーバーの場合は泣いてもらうしかないかなー。
むたぐち 2008年10月11日 21:32
つまり、オートディスカバリー用(Blog提供サービスが見に行く用)のtrackback ping URLと、手動で打つ場合のtrackback ping URLをまず分ける。
前者は、トラックバックを送った人のリモートホストと、urlに指定されたWebサイトのドメインが一致するかまず調べ、一致しない場合ははじく。一致した場合は送信元を見に行って、こちらへのリンクがある場合は通す。それ以外ははじく。
後者は、trackback ping URLを用意するがあるところまではコピペできるが、それに数文字、画像にかかれた文字をつけたすようにする(認証の代わり)。
この辺が落としどころかなー。
むたぐち 2008年10月11日 21:35
追加文字列は定期的に変わるようにする。
むたぐち 2008年10月11日 21:37
オートディスカバリーのほうはチェック間隔に制限を設ける。
JZ5 2008年10月11日 22:38
SPAM温床はメールと同じようなもんじゃないだろか。
バーベキューってなんですか?
手動のトラックバックURL(使わないけど)は、JavaScriptなんかで生成するのはどう? Server側とClient側で共通のアドレス作れるけど、直接ファイル読み込んでJavaScript実行してないと正しいURLがない。
http://katamari.jp/blog/index.php?UID=1163941454
むたぐち 2008年10月11日 22:54
いえねー、トラックバックってわりと新しい規格なのになんでspam温床になることを考えて規格作らなかったのかと。
eメールは昔々作られたものだから仕方ないとして。
JavaScriptいいですねー。やってみます。
トラックバックspam対策って結局同じところに辿りつくのねw>URL
むたぐち 2008年10月11日 22:55
BBQについてはこちら
http://bbq.uso800.net/

JZ5さん事後承諾でごめんなさいだけどコピペさせていただきました。

あと、BBXを使うのも一つの案かな。こっちは広告爆撃ブラックリストなので近いものがあるかと。

元記事:http://blogs.wankuma.com/mutaguchi/archive/2008/11/22/161939.aspx

2008/05/07

マイミクさんからの情報

ダウンロードの詳細 : Japanese ClearType fonts for Windows XP
http://www.microsoft.com/downloads/details.aspx?FamilyID=f7d758d2-46ff-4c55-92f2-69ae834ac928&DisplayLang=ja

メイリオフォントはVistaに標準搭載のクリアータイプな(拡大縮小してもぎざぎざしない)フォントですが、XP用のは公式にはありませんでした(Visual C# 2008 Express Editionを入れるとなぜか入ったりしましたが)。それがXPでも使えるように!

最近はWebページでもメイリオフォント指定のところが増えてますのでXPユーザーの方は入れておいて損はないかと。個人的にきれいなフォントだと思います。

元記事:http://blogs.wankuma.com/mutaguchi/archive/2008/05/07/136728.aspx

2008/03/20

Vistaガジェットに「付箋」というのがありますが、その内容をテキストに書き出すスクリプトをWSHで書いてみました。(22:55 WshNetworkを使ってAddDataパスを取得していたのをShell.Application経由で取得に変更)

'sTextFolderにVistaガジェット付箋をページごとに0.txt, 1.txt...のように保存していく
sTextFolder = "D:\document\Advanced_es の文書\" 'テキストファイル保存フォルダ
Set Fs = CreateObject("Scripting.FileSystemObject")
Set objShell = CreateObject("Shell.Application")
Const CSIDL_LOCAL_APPDATA  = &H1C
Set tsIni = Fs.OpenTextFile(Fs.BuildPath(objShell.NameSpace(CSIDL_LOCAL_APPDATA).Self.Path, _
            "\Microsoft\Windows Sidebar\Settings.ini"),,,True)
Set regEx = New RegExp
regEx.Global = True
bCNotesSection = False
Do Until tsIni.AtEndOfStream
    sLine = tsIni.ReadLine()
    If InStr(sLine,"CNotes.Gadget") Then
        bCNotesSection = True
    End If
    If bCNotesSection And InStr(sLine,"[") Then
        bCNotesSection = False
    End If
    If bCNotesSection Then
        regEx.Pattern = "(\d+)\=""(.+)"""
        If regEx.Test(sLine) Then
            For Each oMatch In regEx.Execute(sLine)
                Set oSubs = oMatch.SubMatches
                Fs.CreateTextFile(sTextFolder & oSubs(0) & ".txt").Write unescape(oSubs(1))
            Next
        End If
    End If
Loop
tsIni.Close

私はこのスクリプトをタスクスケジューラで5分間隔で動かしています。Advanced esというスマートフォンを使ってますが、これにViewTextというTodayプラグインを使うとテキストファイルがTodayに表示できるので、同期センターを使うと付箋の内容を同期できるわけです。

元記事:http://blogs.wankuma.com/mutaguchi/archive/2008/03/20/128772.aspx

2008/01/14

winscript - MyMiniCity
http://winscript.myminicity.com/

wankuma - MyMiniCity
http://wankuma.myminicity.com/

最近流行っているようなので便乗してみました。シムシティ2000風味ですか?よくわかってませんw wankuma cityも勝手に作っちゃいましたごめんなさい。

さて、仕事が忙しかったり沈没してたりでこっちにあんまり顔出せてませんが、2/16の講演は忘れてないので安心してください。デモ曲の作詞は完了して今作曲にとりかかっています。ミクにもちょっと歌わせてみましたがなかなかいいかんじでした。まぁ2コマあるので準備をちょっとがんばらないと色々まずいですが・・・(苦笑) そうそう、実は、初音ミクの開発元のクリプトン社さんからデモ用の初音ミクをお借りしました。デモ用ノートPCにばっちりインストールしましたよ!この場を借りて御礼申し上げます。当日はみなさんにミクが歌ってるところをお見せできるかと思います。

なお、当日はゲストスピーカーとしてやまにょん氏が遊びに(違)来てくれます。VSTiのマニアックな話をしてくれるそうですよ。たとえ私の講演がしょぼくてもきっとやまにょんがフォローしてくれるはずです。もうすぐ募集ページができると思いますのでまたよろしくお願いします。

そういえば関西の方で初音ミクに興味のある方は大阪電気通信大学でこんなイベントがありますよ。

2月10日(日)12:30〜14:30

「音声合成ソフト・初音ミク講演会」
特別ゲスト:クリプトン・フューチャー・メディア株式会社西尾公孝氏+声優 藤田咲氏

な、なんて豪華なんだ。中の人登場ですよ。今のところ申し込みも制限もないみたいなんでお時間ある方は行ってみるのもいいんじゃないでしょうか。私も行きますよーどんなに仕事が忙しくても!うちも負けてられませんがw

さて、また私事に戻りますが、そろそろ公表していいのかな?いいよね。めども立ってきたし。実はPowerShell本を書いています。初めての本です。3月末位に出せるといいなぁというスケジュールです。また詳細が決まり次第ここでご報告させていただきますね。(書名は決まってるんですがまだ秘密です)

荒井さんもPowerShell本を出されたのでそれに続く形になる・・・かな? ver2.0が出るまでに出るといいですね(ひとごとかよ!)

あ、あと独自ドメイン取りました。
http://winscript.jp/

まだ何もないですが将来的にはいろいろしようと思います。いろいろ・・・

whoisしても面白くないのであしからず。ではでは。

元記事:http://blogs.wankuma.com/mutaguchi/archive/2008/01/14/117393.aspx

2007/08/20

HTA(HTML Application)とは、拡張子htaで中身はHTMLなんですけど、VBScriptとかでFileSystemObjectなどのIEなどでは動かないオブジェクトも呼べて便利なものです。見た目、Windows Formのアプリケーションのようなものが作れちゃいます。Windows標準ツールとしては「アプリケーションの追加と削除」や「サーバーの役割管理」などが実はHTAでできています。

ewさて、Web標準ページ作成エディタであるところのMicrosoft Expression Webを何気に触っているのですが、これで実はHTAの開発ができます。しかも、インテリセンスが効きます。しかも、CreateObjectしたオブジェクト変数にもインテリセンスが効くんですよー。すばらしいですねー。HTAの開発がぐっと効率的に、お安くできますよー。

Expression Webの操作方法などについては、MSMVPのwanichanのサイトが参考になると思います。

元記事:http://blogs.wankuma.com/mutaguchi/archive/2007/08/20/91018.aspx

2007/04/27

Windows PowerShell フォーラム - TechNet フォーラム
http://forums.microsoft.com/TechNet-JA/ShowForum.aspx?ForumID=1559&SiteID=36

PowerShellが同梱されるWindows Sever "Longhorn" Beta3のリリースに合わせてTechNetフォーラムにPowerShellフォーラムが開設されました!
皆さん、情報交換や質問、スクリプトやテクニックの披露などに利用させていただきましょう。私も巡回サイトに含めようと思いますv

あと少し情報が遅れましたが、

Microsoft TechNet バーチャル ラボ: Windows システム管理スクリプティング
http://www.microsoft.com/japan/technet/traincert/virtuallab/scripting.mspx

というページもオープンになっています。仮想環境でPowerShellを学べるというものだそうです。私はちょっとまだ試してないですがよかったらこちらもどうぞv

元記事:http://blogs.wankuma.com/mutaguchi/archive/2007/04/27/73506.aspx

古い記事のページへ | 新しい記事のページへ


Copyright © 2005-2018 Daisuke Mutaguchi All rights reserved
mailto: mutaguchi at roy.hi-ho.ne.jp
プライバシーポリシー

Twitter

Books