Archive - Software
ver.1.3.0.8
- XboxInfoTwit - 09.11/16
暴走してしまいました。大変申し訳ありませんでした。Xbox.comが半メンテナンスで、壊れたデータを放出していたのですが(例えばFallout3の最大実績が620になったり)、それを取得して解析していた結果、実績を超連続投稿するということが発生しました。今回のものは暴走抑止用の暫定対策版となっています。しかし確実に防げる保証はないので、利用はXbox.comが安定してからにしてください。また、お願いなのですがXboxInfoTwitが不調な場合は、またXboxInfoTwitのクソが不安定だぜ、と思うのは当然なのですけど、少しだけXbox.comのほうも疑ってあげてください。そして、Xbox.comが怪しかったら、その日は利用を控えるという形でお願いします。これからは、データが怪しい場合は弾くような処理も増やしていこうとは思いますが、それでも全ての怪しいケースを弾けるわけではないので。
暴走抑止のほか、とりあえず実績連続投稿の最大数は10に設定しました。5だと、場合によっては少ないケースも出てきそうなのでとりあえず10で。それと、今回のアップデートは全くテストしていないので、そもそも正常動作するかも分かりません。その辺は、Xbox.comが落ち着いたら見ていきたいと思っています。
あと、責任はとても重く感じています……。公開停止しようとも思ったのですが、誰もがこのサイトを見に来ているわけでは当然ないので、まずは修正して新しく起動する人が、自動アップデートで最低限の回避をするのが第一だと思いました。今後の公開停止ですが、既に相当数の利用者がいる状態なので、公開停止にしてメンテ放置するよりは、問題が起こった際にちゃんと面倒を見る方が重要だと考え、当分は公開を続けることにします。
ver.1.3.0.9
連続ですがまた更新。1.3.0.8では実績解除自体が100%投稿できない状態になってました。風呂に入って頭冷やしてたら思い違いに気づいてああああああ、となりました、はは。それと、暴走の原因らしきものが見えたので(原因自体はXbox.comのデータ壊れなのですが、どの部分がどういう風に壊れていたのか、というのが私自体が遭遇してないので想像でしかないのですよー) とりあえずそれへの対策を重点的に追加してみました。原因が見込み違いだったり、他の原因だった場合は、まあ、しょうがない。そういえば今日ダッシュボード機能追加なんですね。毎回、機能追加前はXbox.comも合わせてドタバタしますが、しかし今回ほど酷いこともなかった。ちなみにもう一つの実績解除ツールも暴走していたので、今回のは本当に本当に不測の事態というかXbox.comのデータの壊れ方が誰にとっても想定外でした。天下のMSなのだから、メンテ時でもしっかりやってくれ、というのは贅沢ですかね。
ver.1.3.0.7
- XboxInfoTwit - 09.11/11
CoD4やMW2、L4Dなんかで顕著に見られるようですが、オンライン対戦時の他プレイヤーが「参加可能」時にデータの取得に失敗して、ゲーム名に参加可能が付いていたり実績が0/0になっていたりするような件を修正しました。実のところ、これver1.3.0.1の時に修正したはずだったんですが、いつのまにやらその時対策したはずのコードが元に戻ってました。あらららら……。
といったように、非常にいい加減な開発姿勢なので今回のリリースでも更にバグ埋め込んだりする可能性大です。バグ見つけたら怒ってやってください。Twitter検索でキーワード「XboxInfoTwit」を始終チェックしてますので、もし不具合があったらTwitterでの投稿時に「XboxInfoTwit」と文中に混ぜておけば、例えば「XboxInfoTwitクソ、***で動かねえ」とか言ってくれれば私の方で巡回して気づくと思いますので、気楽に苦情文句要望バグ報告してやってください。
そういえばというわけでもないのですけど、利用ユーザー数が500超えました。いやー、ビックリですね。当初は2桁台に行けばいいなあ、とか言ってたぐらいだったり、実際致命的な不具合があったのに3ヶ月放置してたり(誰も使わないので気づかなかった!)などだったはずが。嬉しいです。が、現在のコード品質は相当アレなので、なるべく早く、せめて今年中には全面的に書き換えたver2.0を出せるといいなあ、なんて思っています。
ちなみに、amazonアサマシゲイツポイントの購入者数はゼロに近かったりします(買ってくれた人は本当に本当にありがとうございます)。いやまあ、別にネタなのでいいんですけどね。はは。
C#でTwitterのStreaming APIを使ってリスト自動追加
- C# XboxInfoTwit - 09.11/05
XboxInfoTwitの認証数は現在450を越えて、近いうちに500には届きそうです。現在の実装はIEを裏で動かすという、しょーもないものになっていて、それに起因する不具合や、どうしょうもない点が幾つかあるため、クローラー部分は全面的に書き変えようと思っています。あと、エラーメッセージがド不親切とか至らない点だらけでした、すみません。そんな次期バージョンの作業は全然捗ってないのですが、せめて年内ぐらいには何とかしたいです。
@のお話
ゲーム名に@が含まれるものをポストする(例えばTHE IDOLM@STER)と、STERさんに@が飛んで迷惑。というお話を見たので検証してみました。@は行頭かスペース + @ + 数字/アルファベットのものがあると飛びます。つまり、@の前にアルファベットがあれば@は飛びません。なので、別にIDOLM@STERだからってSTERさんに@が飛びまくる、なんてことはありません。正規表現で表すと「(?<=^| )@[a-zA-Z0-9_]+」になります。ついでに、ハッシュタグのほうも軽く検証してみました。基本的には@と同じですが、英単語以外にもリンクが張られるようなので、正規表現は「(?<=^| )#[^ ]+」になるようです。
List
Twitterにリストが実装されました。そこで、XboxInfoTwitユーザーのリストを作ってみることにしました。手動で探して登録も大変なので、プログラムでクロールして追加していきましょう。パブリックイタイムラインからXboxInfoTwit利用者(Source=XboxInfoTwit)の人を片っ端からリスト登録するという方針で行きます。以下、C#でのTwitterストリーミングAPIの使用法と実際のコードになります。同じようなことをやりたい人は、適当に書き替えてどうぞ使ってください。突っ込みどころ多数なのでむしろ突っ込んで欲しい……。
2010/4/29 追記:このコードはストリームAPIの利用法にしては冗長すぎるので、書き直しました → neue cc - C#とLinq to JsonとTwitterのChirpUserStreamsとReactive Extensions ストリームAPI取得コードを参考にする場合は、新しいほうを見てください。
using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Net; using System.IO; using System.Xml.Linq; using System.Collections.Specialized; using System.Threading; using System.Xml; static class Program { // ザ・決めうち文字列s const string UserName = "neuecc"; // 自分のアカウントのユーザー名を const string Password = "password"; // 同じくパスワードを const string ListName = "xboxinfotwitusers"; // リストを、入力ですです const string StreamApi = "http://stream.twitter.com/1/statuses/sample.xml"; const string ListMembersApiFormat = "http://twitter.com/{0}/{1}/members.xml"; /// <summary>指定リストにメンバーを追加する</summary> static void AddMemberToList(string userName, string listName, int id) { var url = string.Format(ListMembersApiFormat, userName, listName); var wc = new WebClient { Credentials = new NetworkCredential(UserName, Password) }; wc.UploadValues(url, new NameValueCollection() { { "id", id.ToString() } }); } /// <summary>指定リストのメンバーIDを全て取得する</summary> static IEnumerable<int> EnumerateListMemberID(string userName, string listName) { var format = string.Format(ListMembersApiFormat, userName, listName) + "?cursor={0}"; var cursor = -1L; var xmlReaderSettings = new XmlReaderSettings { XmlResolver = new XmlUrlResolver { Credentials = new NetworkCredential(UserName, Password) } }; while (true) { using (var xr = XmlReader.Create(string.Format(format, cursor), xmlReaderSettings)) { var xEle = XElement.Load(xr); foreach (var item in xEle.Descendants("user").Select(x => (int)x.Element("id"))) { yield return item; } cursor = long.Parse(xEle.Element("next_cursor").Value); if (cursor == 0) yield break; } } } /// <summary>ストリームAPIのパブリックタイムラインから無限に取得</summary> static IEnumerable<XElement> EnumeratePublicTimeline(StreamReader reader) { while (true) { var xmlString = reader.EnumerateLines() .TakeWhile(s => s != "<?xml version=\"1.0\" encoding=\"UTF-8\"?>") .Join(); if (xmlString == "") continue; yield return XElement.Parse(xmlString); } } /// <summary>サーバーが死んでないか確認</summary> static bool IsServerStatusOK() { var req = WebRequest.Create("http://twitter.com/help/test.xml"); HttpWebResponse res = null; try { res = (HttpWebResponse)req.GetResponse(); if (res.StatusCode == HttpStatusCode.OK) return true; } catch (WebException e) { Console.WriteLine(e); } finally { if (res != null) res.Close(); } // どうでもいいと思っていたり return false; } static void Main(string[] args) { ServicePointManager.Expect100Continue = false; // おまじない(笑) var count = 0; // モニタリング用のカウント変数(動作的には別に使わない) var following = new HashSet<int>(EnumerateListMemberID(UserName, ListName)); var webRequest = (HttpWebRequest)HttpWebRequest.Create(StreamApi); webRequest.KeepAlive = true; webRequest.Credentials = new NetworkCredential(UserName, Password); LOOP: using (var res = webRequest.GetResponse()) using (var stream = res.GetResponseStream()) using (var reader = new StreamReader(stream)) { try { // 例外が発生しなければ、無限リピートになっているのでこの部分を永久に続けます EnumeratePublicTimeline(reader) .Do(_ => { if (++count % 100 == 0) Console.WriteLine("{0} : {1}", DateTime.Now, count); }) // 確認表示用 .Where(x => x.Name == "status") .Select(x => new { Source = x.Element("source").Value, ID = (int)x.Element("user").Element("id"), Name = x.Element("user").Element("screen_name").Value }) .Where(a => a.Source.Contains("XboxInfoTwit")) .Do(a => Console.WriteLine("Found:{0}", a.Name)) // ここでも確認表示用 .Where(a => following.Add(a.ID)) .ForEach(a => { AddMemberToList(UserName, ListName, a.ID); Console.WriteLine("{0} : {1} : {2}", a.Name, DateTime.Now, count); // 確認表示用 }); } catch (IOException e) { Console.WriteLine(e); // 接続が閉じられてたりするのでー。 while (!IsServerStatusOK()) { Thread.Sleep(TimeSpan.FromMinutes(5)); // サーバー死んでたら5分間お休み } } finally { webRequest.Abort(); // これ呼ぶ前にCloseするとハング } } goto LOOP; // goto! goto! } // Extension Methods public static IEnumerable<string> EnumerateLines(this StreamReader streamReader) { while (!streamReader.EndOfStream) { yield return streamReader.ReadLine(); } } public static string Join<T>(this IEnumerable<T> source) { return source.Aggregate(new StringBuilder(), (sb, s) => sb.Append(s)).ToString(); } public static void ForEach<T>(this IEnumerable<T> source, Action<T> action) { foreach (var item in source) { action(item); } } public static IEnumerable<T> Do<T>(this IEnumerable<T> source, Action<T> action) { foreach (var item in source) { action(item); yield return item; } } }
ストリーミングAPIとは無関係のリスト関連の処理や、投げやりなtry-catch-gotoがあって、ちょっとゴチャゴチャしてますが、基本的にはusing三段重ねの部分だけです。無限にXMLが継ぎ足されてくるので、接続を切らさずひたすらReadLine。XMLの切れ目は、XML宣言部を使うことにしましたが、今一つスマートではないです。文字列にしてParseってのもあまり良い感じじゃなく。あ、あと例外処理は全然出来てませんので何かあると平然と死にます。
コードは、書き捨て感全開。例によって何でもLinq、何でもIEnumerable。コレクションになりそうな気配があると、すぐにじゃあyieldね、と考える癖がついてしまっていて。細かいことは後段に任せればいーんだよ、というのが楽ちんでして。リストメンバー全件取得の部分なんかは、わりとスマートに書けてるかと思うのですがどうでしょう。
なお、このストリーミングAPIは全件を漏れなく取得出来るわけではないので、それなり、というかかなり漏れが出ます。なのでXboxInfoTwit使ってるのに登録されねーぞ、という場合は、しょーがない。です。そのうち登録されると思います。あと、このプログラムはサーバー上で24時間動かしているわけじゃなく、私のローカルPC上で動かしているだけなので、私の気まぐれで動かしてたり動かしてなかったりします。私が寝てる間はPCがウルサイので動いてませんし、私が家に居ない時は省エネのために動いてません。なので、むしろ登録されるほうが珍しいです。レアです。効率的には20000件に1人登録出来るか出来ないか、って感じでした。一時間に一人見つかるかどうかも怪しいぐらいの頻度。とてもレア。ぶっちゃけgoogle経由で引っ張ってくるとかしたほうが遙かに効率良さそうですが、まあ、Streaming API使ってみたかったというだけなので。
そういえばですが、逆にリストに登録されてUZEEEE、という場合は、現状はリスト機能がベータのせいなのか拒否は出来ないようです。すみません。UZEEEE、と思っても我慢してください。どうしても嫌な場合は私の方にメッセージをくれれば、リストからの撤去と、プログラムから以後の追加をしないようなコードを入れたいと思っています。
JavaScriptでString.Format的な超簡易テンプレート置換
- JavaScript linq.js - 09.09/18
// String.Format的な超簡易テンプレート置換関数 var Format = function(template, replacement) { if (typeof replacement != "object") // 可変長引数時はreplacementを詰め替え { replacement = Array.prototype.slice.call(arguments, 1); } return template.replace(/\{(.+?)\}/g, function(m, c) { return (replacement[c] != null) ? replacement[c] : m }); } // 例。可変長引数渡しでも配列渡しでもオブジェクト渡しでも可。 var case1 = Format("<div id={0}>{1}</div>", "あいでぃ", "要素"); var case2 = Format("<div id={0}>{1}</div>", ["あいでぃ", "要素"]); var case3 = Format("<div id={ID}>{ELEM}</div>", { ID: "あいでぃ", ELEM: "要素" })
.NET FrameworkのString.Formatは文字を連結するのに、非常にお手軽で良いです。というわけでJavaScriptでもそれをやる。ついでにテンプレート置換風にオブジェクト渡しにも対応させる。単純な置換時は数字で、長ったらしい置換時はオブジェクトで。両方に対応させなければ、詰め替えが必要ないので正規表現でカカッと一行なんですねえ。詰め替えも別にslice.callで一発だし。以前にlinq.jsを絡めてgdgdとやってたのですが、二度もね!、あんなにgdgdやらずとも、もんのすごーく単純明快に書ける。無理やり使おうとして、無駄に複雑になるのはイクない。
と、恥ずかしくなったので今回載せました。あと、JavaScriptは文字連結面倒くせー、って時にササッとコピペで取り出して使いたい時のために(笑) ちゃんとDateTime等も含めたフォーマット変換に対応させるとか、テンプレートだったらちゃんとテンプレートエンジンな感じでforやifも動くように、とかの話は知りません。
そういえば、置換部分の関数ですけど、最初は格好つけて「return replacement[c] || m」って書いたんですが、これだとマッチがハッシュ内に見つからなかった場合(undefinedになってる)だけでなく、 空文字列の場合もfalse扱いになってしまってダメなんですね。C#の??のように使いたいのですが、例えば数字だと「var i = 0 || 3」だったら3になるしで使いづらい。というわけで、結局==nullばかり使うことになる。===undefinedって書けって話でもありますが、まあ、==nullのほうが色々考えなくて済むから楽で。
無限リピートの幸福
- C# JavaScript linq.js - 09.09/09
Reactive Frameworkが、結構に無限リピートな感じなので、関連してC# Linqでどう書くにあった13日金曜日問題を今更書いてみた。n番煎じ。
// 今日から2013年12月31日までの、13日の金曜日とその総数を表示してください。 // 「今日」を無限リピートという方針で書いてみたりして(総数は省略) // 利点はTodayを変数として外側に定義する必要が無くLinq内に閉じ込められる // Toを求めるのに足したり引いたりする必要がなく自然に書ける、の二つかしらん // 「まで」という問いに対してTakeWhileで解答するのは自然で良いと思う Enumerable.Repeat(DateTime.Now, int.MaxValue) .Select((d, i) => d.AddDays(i)) .TakeWhile(d => d.Year < 2014) .Where(d => (d.DayOfWeek == DayOfWeek.Friday) && (d.Day == 13)) .ToList() .ForEach(d => Console.WriteLine(d.ToShortDateString()));
TakeWhileが好きです。問題文に対して、自然に解答出来るような気がするので。「今日から(Repeat)」「2013年12月31日までの(TakeWhile)」「13日の金曜日(Where)」。実に自然に記述できる。いやまあ、Repeatが直感的かというと結構微妙なところではありますが。Rangeでfrom,toのほうが自然だろ常識的に考えて、というのも確かなんですけど、Rangeだとtoを作るのに計算式が必要ってのが、ちょっと違うかな、と。
Pizza (programming language)のexampleにもあるような、Streamを始めとして何かを無限リピートしてTakeWhileで終了条件を設定、というのはパターンとして結構幅広く使える、と思う。ある種のデザインパターン。イディオムイディオム。参考リンクはC# 3.0 と while(true) と Iterator - NyaRuRuの日記この辺り。
例えばVS2010から搭載されるEnumerable.Zipや、あとCycleを定義してみる。
// この二つを混ぜ合わす(VS2010で搭載されるZip関数) var seq1 = Enumerable.Range(1, 10); var seq2 = Enumerable.Range(10, 10); Enumerable.Repeat(new { e1 = seq1.GetEnumerator(), e2 = seq2.GetEnumerator() }, int.MaxValue) .TakeWhile(t => t.e1.MoveNext() && t.e2.MoveNext()) .Select(t => t.e1.Current + t.e2.Current); // ここがZipのSelectorの部分 // foo,bar,hoge,foo,bar,hogeを無限に繰り返す var elements = new[] { "foo", "bar", "hoge" }; var cycle = Enumerable.Repeat(elements, int.MaxValue).SelectMany(ar => ar);
Linqのお陰でかつてない勢いでint.MaxValueを使っているこの頃。Repeatも万能ですねえ。いやまあ、もう素直にAchiral使えよって話なんですが、標準メソッドのみで粘るのも面白くて。そういえばでついでなのでlinq.jsでもやってみた。
// JavaScriptはAddDaysがないので副作用全開でTodayを // setHours(24)で翌日にしてしまう、という方針でやってみた E.Repeat(new Date()) .Do("$.setHours(24)") .TakeWhile("$.getFullYear() < 2014") .Where("$.getDay() == 5 && $.getDate() == 13") .ForEach("alert($)");
DoはReactive Frameworkにもありました。副作用を加えた上で素通しするメソッド。副作用は嫌なものです。汚いです。何が嫌かというと、動作を考えるのに見る範囲を広げなきゃいかんところかなあ。そしてLinqの何がいいかというと、見る範囲が物凄く限定される(ラムダ式一文だけを見ればいい)と思っている。だからLinq内でクロージャ(というか外部の変数をキャプチャして使う)もあんま好ましくないし、C#クエリ構文のletも好きじゃない。なるべくなら使いたくない。長文耐性なのは分かるけれど、カッコやインデントがなくてスマートだけれど、その分だけスコープが不明瞭になるという側面が否めない。まあ、letが必要なシチュエーションをSelectManyでやると、大抵はもっと奇怪になるのですけど。
んでまあ、この場合だとAddDaysのかわりにnew Date(year,month,day)で新しいのを作れば副作用なくSelectが使えるわけですが、ありきたりで面白くないと思ったので別な方向に走ってみた。というか、無限リピートは、無限リピートする何かに対して副作用全開で操作を加え続ける、という形の方が面白いというか実用的というか普通だとは思う。冒頭の例みたいなやつだと、別にRangeでよくね?って感じですし。Haskellじゃないんだから、潔癖症にならずに、副作用といかに楽しくお付き合いするかが大事なのですかね。
あ、ちなみに$は引数が一つの場合の省略記法です。こういった機能はScalaにもある。引数が一つのみの場合が大半なので、記述がグッと縮まるし、何よりも引数名を付ける必要がないのが嬉しい。C#でも使えるようになると嬉しいなあ、とずっと思ってるんですが中々どうして無理なんですかねえ、残念。
3桁到達
- XboxInfoTwit - 09.08/30
開発者用のOAuth管理ページで認証ユーザー数が見れるのですが(「誰が」までは分からないので安心してください)、いつのまにやらユーザー数が100を超えていました。三桁!奇跡的ですね。はてな同期云々とかフォトライフ云々は壊滅的な状態なので。世の中そんなものです。ついでにこのサイトのアクセス数も壊滅的だったりはします。成り行きでプログラミング系サイトに転換してから半年、以上は経つ感じですが、伸びもせず縮みもせず、ずっと低調をキープ。サイトの内容がガラッと変わったのにアクセス平均が変わらないってのも面白いですけど。検索サイトからのアクセスがほとんどなので、検索キーワードが入れ替わって、でも流入人口は変わらずという。あー、まあ、少し増えた、かな。つまりかわりに常連的な人口が減った、と。おお、虚しい!悲しい!RSSリーダー登録数も伸びないしね。しょぼーん。
ゲーム系サイトへは、XNAで返り咲きしたいとこっそり思ってます。XNAは使用言語がC#だからね。C#好きーなのです、私。積みタスクを全部消化したらXNAやりたいんですが中々どうして……。 そういえばインディーズゲーム(XBIG)を完全スルー状態なのはぶっちけ(略)
fromにクライアント名が出るようになってからは、googleのサイト検索で利用具合が見つかるので、毎日24時間以内の結果を眺めていたりします。見ていて思うというか教訓は、デフォルト設定大事ってことでしょうかね。カスタマイズせずそのまま、カスタマイズする場合も、デフォルトを残しつつ細部を変える、という感じなので、デフォルトの投稿文はちゃんとしたものを用意しなきゃダメなんですね。当たり前といえば当たり前なのですけど、この辺はてなついったー同期ツールは大失敗していて、どうせカスタマイズするだろうと踏んで、書式のサンプルとばかりにゴテゴテのものをデフォルトにしてしまったので……。反省。
あと、デフォルトでは「プレイ中タイトルの状況が変わった時の投稿」はオフにしているのですが、意外とこれをオンにする人が多かったのも驚き。これオンにすると物凄い勢いで投稿されるんですよ。更新間隔を5分にすると、例えばGoW2のHordeすると、WAVE44,45,46…と、全部のWAVE投稿するんじゃないか、最新50個の投稿が全部XboxInfoTwit経由になってますが大丈夫?みたいなことになる。こういう滅茶苦茶なことが出来るのはローカルで動くツールならでは、なのですが(ウェブサービス系じゃあ、ちいと無理ですね、秋のTwitter対応が仮に実績やプレイ状況の投稿に対応するとしても、ここまでの連投は無理かと)フォロワーの目からどうなのか、というと、まあ、分からにゃい。いや、本人の満足が一番だと思いますよ。一日のプレイ後に投稿を眺めると、状況の変化がよく見えて結構楽しかったりはします。お薦めはしませんけどお薦め。別アカでやるなら何も問題なくお薦め。
JavaScriptで要素追加するやり方
- JavaScript linq.js - 09.08/27
ド素人がjQueryとprototype.jsではどう書くのかな、と思っただけです。メジャーな両者ですが実はまともに使ったことがないのです。困ったことに。しょうがないので見よう見まねで書く。
<!-- このselectにoptionを一個追加する -->
<select id="selectID">
<option value="1">hugahuga</option>
</select>
<script type="text/javascript">
// 素のJavaScriptその1(古臭いというか微妙な……)
var option = new Option("要素", "属性");
var select = document.getElementById("selectID");
select.options[select.options.length] = option;
// 素のJavaScriptその2(これはダルい)
var option = document.createElement("option");
option.setAttribute("value", "属性");
option.appendChild(document.createTextNode("要素"));
document.getElementById("selectID").appendChild(option);
// みんな大好きjQuery
$("<option>").attr({ value: "属性" }).text("要素").appendTo("#selectID");
// 何だかんだで好きなprototype.js
var option = new Element("option", { value: "属性" }).update("要素");
$("selectID").insert(option);
// linq.js + linq.xml.jsの関数型構築
var option = X.Elem("option", X.Attr("value", "属性"), "要素");
X.ID("selectID").Add(option);
</script>素のJavaScriptその1はねーよ、というわけで、その2をいかにスマートにやるかという話。だと思う。jQueryのappendToが合理的というか便利なのは分かるけど、キモく感じてしまう。んで、どれが好きかっていたら、当然自分で作ってるlinq.jsのが一番好きですよ(笑)
// linq.js + linq.xml.js var options = E.RangeTo(1, 12).Select(function(i) { return X.Elem("option", X.Attr("value", i), i + "月"); }); X.ID("selectID").Add(options); // prototype.js var options = $R(1, 12, false).map(function(i) { return new Element("option", { value: i }).update(i + "月"); }); var elem = $("selectID"); options.each(function(e) { elem.insert(e) });
X.Elem()もAdd()もLinqオブジェクト/可変長配列を受け取れるので、まとめてドバーっと追加が結構楽かな、と思います。eachとかじゃなく、そのまんま追加出来るってのが大事。上の例だと、prototype.jsではmapでoptionsを作らずそのまんまeachでinsertしちゃえばいいぢゃん、というのはそのとーりなんですが(2回もループ回ることになるしね、あ、linq.jsのは遅延評価しているのでループはAddで呼び出される時の1回しか回りません)、配列(的なもの)が既にある状態ってのは、結構ありますよね?
と、何故か突然アピールしてますがlinq.xml.jsは作りかけで放置しているので足りない関数がいっぱいあるんですけどね!
WSH用にCOMのIntelliSenseを自動生成する
- C# JavaScript linq.js - 09.08/24
本題、の前にJavaScript用のIntelliSenseの作成方法について。以前、linq.jsにIntelliSense用ファイルを追加した時に利用法を書きましたが、今回はvsdocの作成方法を、ざっと書きます。まずVS2008 SP1とパッチを適用する。hoge.jsに対しhoge-vsdoc.jsを用意するとhoge.jsのかわりにhoge-vsdoc.jsがIntelliSense用に読み込まれる。IntelliSenseでVSが見ているのはメソッド名と引数だけなので、コードの中身はなくてもいい。例えば本来は存在するがprivateメソッドのつもりのものは、vsdoc.js側に書かなければIntelliSenseには表示されない。C#と同様に関数にはXMLドキュメントコメントを記述することが出来る。記述箇所はC#とは異なり開始の波括弧の直下。ドキュメントコメントのタグで現在機能しているものはsummary, params, returnsのみ。特に重要なのはreturns typeで、これにprototypeが存在する関数(ようするにクラスですなー)を指定することで戻り値の型をVSに認識させ、IntelliSenseを働かせることが出来る。ちなみに、ただのオブジェクトだと認識してくれない。
function Hoge(aaa, bbb) { /// <summary>hogehogehogehoge</summary> /// <param name="aaa" type="String">a!a!a!a!a!</param> /// <param name="bbb" type="Optional:Boolean">b?b?b?b?b?</param> /// <returns type="Number"></returns> }
基本はこんな感じ。引数の省略や、型が目で見て分かるので大分書きやすくなります。 で、いつぞやかに作成中とか言っていた通りにlinq.jsをWSH対応させようとしているわけですが、IntelliSense書きの量が思ったよりも膨大なわけです。実は最初は普通に手書きしてました。一応勉強も兼ねて書写みたいなノリで。ですが、あまりにも手間かかりすぎるので自動生成することにしました。こんなの人力でやるもんじゃないですよ。微調整はどちらにせよ必要なのですか、大枠だけでも書きだされていると物凄く楽になる。
static void Main(string[] args) { // add reference and replace dll path var assembly = Assembly.LoadFrom(@"Interop.IWshRuntimeLibrary.dll"); var types = assembly.GetTypes(); var enums = types .Where(t => t.IsEnum) .OrderBy(t => t.Name) .Select(t => string.Format("{0}: \r\n{{\r\n{1}\r\n}}", t.Name, Enum.GetNames(t).Select(s => string.Format("\t{0}: {1}", s, (int)Enum.Parse(t, s))).Join(",\r\n"))); var classes = types .Where(t => t.IsClass) .Select(type => { var bindingFlag = BindingFlags.Public | BindingFlags.Instance | BindingFlags.DeclaredOnly; var properties = type.GetProperties(bindingFlag) .OrderBy(pi => pi.Name) // .Select(pi => string.Format("{0}: {1}", pi.Name, pi.PropertyType.Name .Select(pi => string.Format("{0}: null", pi.Name)); var methods = type.GetMethods(bindingFlag) .Where(mi => !mi.IsSpecialName && mi.Name != "GetEnumerator") .Select(mi => new { mi.Name, Parameters = mi.GetParameters(), ReturnType = mi.ReturnType.Name }) .OrderBy(t => t.Name) .Select(t => string.Format("{0}: function({1})\r\n{{\r\n{2}\t/// <returns type=\"{3}\"></returns>\r\n}}", t.Name, t.Parameters.Select(pi => pi.Name).Join(", "), t.Parameters.Select(pi => string.Format("\t/// <param name=\"{0}\" type=\"{1}{2}\"></param>\r\n", pi.Name, (pi.IsOptional) ? "Optional:" : "", pi.ParameterType.Name.Replace("Void", "void").Replace("Int32", "Number"))) .Join(""), t.ReturnType.Replace("Void", "void").Replace("Int32", "Number"))); var result = properties.Concat(methods).Join(",\r\n"); return string.Format("{0} = function() {{ }}\r\n{0}.prototype =\r\n{{\r\n{1}\r\n}}", Regex.Replace(type.Name, "Class$", ""), result.Split(new string[] { "\r\n" }, StringSplitOptions.None).Select(s => "\t" + s).Join("\r\n")); }); var name = assembly.GetName().Name.Split('.').Last(); File.WriteAllText(name + "_enum.js", string.Format("{0}Enum =\r\n{{\r\n{1}\r\n}}", name, enums.Join(",\r\n").Split(new string[] { "\r\n" }, StringSplitOptions.None).Select(s => "\t" + s).Join("\r\n")), Encoding.UTF8); File.WriteAllText(name + "_class.js", classes.Join("\r\n\r\n"), Encoding.UTF8); } static string Join<T>(this IEnumerable<T> source, string separator) { var index = 0; return source.Aggregate(new StringBuilder(), (sb, o) => (index++ == 0) ? sb.Append(o) : sb.AppendFormat("{0}{1}", separator, o)) .ToString(); }
参照設定で対象のCOMを読み込んで、一旦ビルド。生成されてるInterop.hoge.dllを読み込んで解析、という流れをとってみました。もっとマシなやり方があれば教えてください。コードは、んーと、string.Formatがクドくて見難いですね! 最初はVSのフォーマッタに後で手動でかければいいや、と思ってたのを、出力状態でちゃんとフォーマットされてるようにと継ぎ接ぎしてたら酷いことに。一回文字列にしたものを改行でバラして再生成とか笑えない。こういうの、HTML/XMLが対象なら何も考えなくてもLinq to Xmlで綺麗に書けるのになあ……。 それ以外はまぁ、こんなものかしらんって感じでしょうか? リフレクションが絡むとLinq大活躍。Selectがネストしまくるのでクエリ構文の出番はない。リフレクションは掘り進める都合上、ネストが深くなるのでLinqがなかったら、と思うとゾッとします。最近はforの二重ループですらウエエ、とか思ってしまうので。
IWshRuntimeLibraryEnum = { IOMode: { ForReading: 1, ForWriting: 2, ForAppending: 8 } } Folder = function() { } Folder.prototype = { Name: null, ParentFolder: null, Drive: null, CreateTextFile: function(FileName, Overwrite, Unicode) { /// <param name="FileName" type="String"></param> /// <param name="Overwrite" type="Optional:Boolean"></param> /// <param name="Unicode" type="Optional:Boolean"></param> /// <returns type="TextStream"></returns> } }
一部抜粋ですが、こんなようなデータが出力されます。プロパティが全部nullなのは、ここに未指定のものが記述されているとIntelliSenseがエラー起こしてしまうから。例えばDrive: new Drive()で戻り値の型指定が可能といえば可能なのですが、出現位置の上下が問題になってくるので結構面倒くさい。ようはFolderよりも上にDriveがあれば関数が存在するので大丈夫だけど、下にあれば存在しないのでエラー。当たり前といえば当たり前なのですが、ダミーでのIntelliSense作りとしては面倒な問題でして。 この辺は素直に諦めて全部nullで型連鎖を止めてしまうのがお気楽といえばお気楽。あと、Dateはnew Date()にしてもDate.prototypeにしても型指定出来なかったりする問題もある。これは今のところ対処不能。
そんなわけで、linq.js + WSHはわりと順調に作成中なので期待しないでも待っててください。IntelliSenseというだけじゃなく、JScriptではバイト配列が扱いにくいので、扱いやすく出来るような補助メソッドを用意したりとか色々やってたらいつになっても終わらないー。例としてWSHでMD5を作る、とか。.NET Frameworkを通しているのでSHA1でも何でもいけます。これでWSHでwsse認証通してAtomAPIで投稿、とか出来ますね。まあ、もうC#でいいぢゃん、って気がかなりしなくもないですけど、うーん。C#4.0からdynamicが追加されるからCOM連携も楽になるしねえ。ただサイドバーガジェットに使うとか、JavaScriptの用途はまだまだあるもん!(これもSilverlightでやれば?って話がなくもないので、うーん)
ver 0.0.0.3
- FotolifeUploader - 09.08/22
拡張子が大文字だとアップロード出来なかったので直しました。XboxInfoTwitの時も同じのやってたのにまたかよって感じです。拡張子判定部分は、ちゃんとIgnoreCaseにしたしあれえ?と思ってたんですがContentType作るところで漏れがあって、ウッカリ。てへ。
まあ、そんなこんなでちゃんと一眼レフも買いました。わざわざこのためだけに!neuecc’s fotolife 。それで、しかし撮るものが悲しいほど無いんですよね、やっぱり。とはいえ、自分で撮って自分で上げてかないと、何をどうすれば良くなるのか分からないので、室内写真で栄える何かを探し中です。現在は多肉植物でも育てようかな、と思ってるんですがどうでしょうかねえ。
ちなみに現在までのDL数は余裕で一桁。べ、別に悲しくないもん! そういえばこの半自動ってぶっちゃけ機能的にいらなくね?むしろフォルダ監視で自動化したほうがよくね?とも思ってきたので、まあ、そのうち。そのうち。
LINQ to XMLのNamespaceと書き出し時のEncodingについて
- C# FotolifeUploader - 09.08/18
ver 0.0.0.2に更新。アップロードするフォルダが指定出来るようになりました。アップロードツール名(FotolifeUploader)が利用されるようになりました。フォルダ指定は再設定が必要なので、前のバージョンを使っている方はsettings.xmlを削除して、再度設定し直してください。あとは間抜けだったUploadToFotolifeメソッドを手直ししたり。
私自身が、そもそもフォトライフのヘビーユーザーではないので、細かいところに気が利いてないかもですね……。そういうのは、よくない。というわけで、当分はFotolifeをちゃんと利用しようキャンペーンを張ることにします。なので、デジタル一眼を買う。と言いたいのだけど、何か微妙なのよねん。いや、そもそも引き籠って家から出ないので撮影するものがないので。かといって熱帯魚や食虫植物とかフィギュアとか、撮影に適した趣味があるわけでもなく。困った困った。まあ、考えます。食虫植物を育てる方向で(?) 部屋が殺風景なので何かは入れたいのだけど、手間はかけたくない。ううむ、難しい。
LINQ to XML
アップロードにはAtomAPIを利用しているので、XMLです。つまりLINQ to XMLの出番です。出力結果がこんな感じなので、そこから逆に考えると……
<entry xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns="http://purl.org/atom/n s#"> <title>タイトル</title> <content mode="base64" type="image/jpeg">画像BASE64</content> <generator>FotolifeUploader</generator> <dc:subject>フォルダ名</dc:subject> </entry>
XElementは、Namespaceの利用が少しややこしいんですよね。最初引っかかりました。「XNamespace.Xmlns + “接頭辞”」で登録できます。
XNamespace ns = "http://purl.org/atom/ns#"; XNamespace dc = "http://purl.org/dc/elements/1.1/"; var xml = new XDocument(new XDeclaration("1.0", "UTF-8", null), new XElement(ns + "entry", new XAttribute(XNamespace.Xmlns + "dc", dc), new XElement(ns + "title", "タイトル"), new XElement(ns + "content", new XAttribute("mode", "base64"), new XAttribute("type", "image/jpeg"), "画像BASE64"), new XElement(ns + "generator", "FotolifeUploader"), new XElement(dc + "subject", "フォルダ名") )); Console.WriteLine(xml); // 出力確認、DeclarationはToStringでは出力されない
少し独特ですが、ほとんど1:1で対応させられるので慣れるとサクサク書けます。非常に快適。個人的にはXMLリテラル的なものよりも好き。Linqがあってほんと良かった……。で、Declarationを出力したい場合の話に続く。(hatena (diary ’Nobuhisa))にもあるように、ToStringでは出力されないのでSaveを使う、と……
var sb = new StringBuilder(); var sw = new StringWriter(sb); xml.Save(sw); Console.WriteLine(sb); // UTF-16になる
これでencodingがUTF-16になるのは、Saveメソッド呼ぶとDeclarationは作りなおしているから。.Save(”string fileName”)ではXDeclarationのエンコーディングを見て、それで保存するけれど、それ以外の場合はXDeclaration無視で再構築される。XDocumentというかXmlWriterのほうの話でしょうか。実際にファイル出力してみると分かる。
var fs = new FileStream(@"C:\text.xml", FileMode.Create); var sw = new StreamWriter(fs, Encoding.GetEncoding("x-mac-turkish")); xml.Save(sw);
出力先のエンコードに合わせてくれる、のを便利と見るか、むしろ気が利かない、Writer部分もC#3.0に合わせて作りなおせ、なのかは不明。まあ、嘘エンコード宣言は許しませんよってことですかね。じゃあどうするか、って言ったら
// これで別に何も問題ないと思います、文字列として吐くんだからToStringでいいと思ふ var xmlString = string.Format("{0}{1}{2}", xml.Declaration, Environment.NewLine, xml); Console.WriteLine(xmlString); // ToStringがどうしても嫌ならMemoryStream経由で、とか? string result; var encoding = Encoding.UTF8; using (var ms = new MemoryStream()) using (var sw = new StreamWriter(ms, encoding)) { xml.Save(sw); result = encoding.GetString(ms.ToArray()); } Console.WriteLine(result); // 望み通りのUTF-8で出力されてます
結論は、普通にToStringでいいんじゃないかな、と。ToStringメソッドだけではXmlWriterSettingsで言うところのOmitXmlDeclarationを設定出来ないから、デフォルトでは付加しないようにしてる。削除は無理だけど、追加なら簡単だから。XmlDeclarationを付加したい時は別途、自分でくっつければいい。というだけのお話かなー? ToStringで一発で終わらせられないからStringBuilder使って組み立てるってのは、何でそうなるの?と、とても思った。ついでにもう一つ。
// こんなXElementがあるとして var xElement = XElement.Parse("<hoge>3</hoge>"); // intとして値を取り出す時は var num1 = int.Parse(xElement.Value); // これダメ。 var num2 = (int)xElement; // こう書こう。
です。LINQ to XMLは既存のものを上手く使ってシンプルに書けるように作られてる。気がする。このキャストもそうだし、ToStringもそう。Parseは頻繁に行うから汚くなるよね→キャストでよくね? 文字列化はよくやるけどSaveもXmlWriterSettingsも面倒くさいよね→ToStringでよくね? といった感じ。関数型構築もそうだけど、今までのもの(XmlDocument)を踏まえて、よく練り直されているなー、と思います。
半自動はてなフォトライフアップローダー ver 0.0.0.1
- FotolifeUploader - 09.08/17
はてなフォトライフに画像をワンクリックでアップロードするプログラムです。ワンクリックの手間があるので、半自動。主な機能は、実行すると設定したフォルダの最新の更新画像一枚をアップロード。利用例としてデジカメ接続時やメモリーカード内の画像フォルダを指定することを想定しています。写真撮る→PCに繋げる→プログラムを実行する→アップロード完了。みたいな流れです。Twitterに載せるための写真とか最新一枚で十分でしょう? Blogに載せる場合でも、一枚で済む場合って結構多いよね。そんな感じに、サクサクッと写真と付き合えたらいいな、と。
設定
まさかのCUI設定画面(笑) 初回起動時にこの画面になります。設定し直したい時は、生成されるsettings.xmlを削除してください。レトロでアナログで半自動を貫く感じがいいかなー、と思ったんですが、どうでしょう。
最新画像一枚のアップロード
設定終了後にexeファイルを実行すると、設定時に指定したフォルダの中の、拡張子が「jpg/jpeg/gif/png/bmp」で更新日時が最も新しいもの一枚をアップロードします。設定によってはアップロード後にブラウザでフォトライフのURLが開きます。なので、そこからそのままTwitterにURLをポストするなりBlog書くなりがシームレスに行えるわけです。キリッ。ちなみにリサイズ等はこちら側では一切しません、そのまま丸投げ。リサイズ処理もはてな任せ。
任意画像複数枚のアップロード
フォルダ/画像をまとめてexeファイル(本体じゃなくてショートカットでもOKです)にドラッグアンドドロップすると、そのファイルをアップロードします。フォルダはサブディレクトリを含めて全てのファイルをアップロードします。拡張子が「jpg/jpeg/gif/png/bmp」以外のものはちゃんと無視しますので、多少適当でも大丈夫。また、いわゆる「送る」にショートカットを登録することで、このドラッグアンドドロップと同様の結果になります。Vistaの場合はエクスプローラー上で「%AppData%\Microsoft\Windows\SendTo」と入力するとSendToのフォルダに飛べますので、ここにショートカットを登録してみてください。
今回コンソールアプリにしたのは、実行にかかる手間を最小にしたかった、というのがあります。普通のアップロードアプリだと、「アプリを起動→画像フォルダを開く→ドラッグアンドドロップで画像を乗っける→アップロードボタンを押す→アプリを閉じる→Fotolifeにアップロードされた画像を確認しにいく」 これじゃあ工程多すぎであまりにも面倒くさい。というわけで、最新画像一枚ならば、アプリ起動だけで完了。複数毎でも画像フォルダ→ドラッグアンドドロップだけで完了という、考え得る限りの最短を目指しています。
ソースコード
ソースコードも同梱してあります。csファイル一つだけの、200行ちょいのちっぽいコンソールアプリです。好きに改変とか突っ込みとかディスとかしてください。しいていえば、Linqだらけです。個人的には
.SelectMany(s => (Directory.Exists(s)) ? Directory.GetFiles(s, "*", SearchOption.AllDirectories) : Enumerable.Repeat(s, 1)) .Select(s => new FileInfo(s)) .Where(fi => fi.Exists && FotolifeExtensionPattern.IsMatch(fi.Extension))
この部分が気に入ってます。ドラッグアンドドロップで来る文字列配列からファイル抜き出しの部分。SelectManyでディレクトリをファイル名配列に、ディレクトリじゃない場合はEnumerable.Repeatで繰り返し回数が1回のファイル名配列にする。あとはまあ普通に、SelectしてWhereしてToArray。Linqがあって良かったーと本当に思う。逆にAtomPub APIでアップロードする部分はLinqでやる意味がなかったというか、当初予定と変わってあれ追加これ追加で肥大化してしまった結果でして……。
LLの人はこの手のちょっとしたスクリプトをほいほい公開しているわけだから、C#もコンソールアプリぐらいほいほい公開出来ないといかんのぅ、と思いつつもページ用意して云々かんぬんは面倒くさくて、そうホイホイってわけにもいかない感じ。もちっと軽くやれる環境作らないとね……。まあ、でも、このちょっとした重苦しさも悪くはないんだ。だってほら、Rubyでスクリプトがホイッって転がってても、普通の人は動かせもしないわけですよ。だから、少し面倒くさいなー、と思いつつ設定画面つけてexeの形式にして、それだけで幸せになれないかな、どうだろう。
私はプログラム書き始めたのがほんとつい最近で、利用するだけ人間の歴が何年も何年もあるので、その辺は極力優しくやりたいなあ、と思ってます。
linq.js :: Next
- JavaScript linq.js - 09.08/02
音沙汰のないlinq.jsなんですが、現在はWindows Script Host対応を進めています。対応といっても数カ所書き換えるだけなんですけど、それに合わせてWSH用のラッパーライブラリを書いているので、それに時間を取られてる感じです。基本的にはほんと薄いラッパーで、列挙処理がlinq.jsに渡せるのでそっちで好きに処理してね、という方向なので機能面での補助は一切なく別にすぐ出来上がるというかもうほとんど出来てるんですが、IntelliSenseを聞かせるためのvs-doc書きに物凄く時間喰われています。とにかくIntelliSense命な私は、IntelliSenseが動かないものなんて書きたくない!なければ自分でIntelliSenseを書く!という意味不明な方向で頑張ってます。
画像の一枚目は一週間前のものなので、現在はW.ToLinqは廃止して、E.Fromで動くようになってます。何のこっちゃ。
このご時世、WSHなんて下火、これからはPowerShellだよねー、って感じですが、それでも私はWSHで頑張る! WSHでLinq書けるのかゴルァ、を合い言葉に。JavaScript好きだし。まあ、素のJScriptだとEnumeratorを被せなきゃいけなくて列挙処理がゴミで使う気になれないのは確かなのですが、そこをlinq.jsがあれば何とか出来るわけなので、全然WSHは現役で行ける、Windows7時代でも全然行ける、と思います、思いたいです。まあ、あとWindowsサイドバーガジェット(デスクトップガジェット)にも使えるので、もうちっと踏ん張っていきたいな、というところ。Web系で頑張るのは無意味なのでニッチを狙いだしたとかそういうことではありま、す。
ver 1.3.0.5 バグ修正とか動かない人用とか色々
- XboxInfoTwit - 09.08/01
動かない-、という人にログを出して貰ったお陰で、幾つか問題を潰せました。本当にありがとうございます。自分の環境で再現出来るエラーを潰せるのは当たり前。再現しないエラーを潰せないのは三流。というわけで三流な私はさっぱり分かりませんでした。分かってみれば、ああ、確かに問題だなーって感じなんですけどねえ。
変更内容は「オフライン→オンライン時投稿のチェックを外していた場合、同期に失敗する不具合を修正」だそうです。えー、こんな初歩ミス埋め込んでたのー、っていうと、そうです、はい、埋め込んでました、はい。げふんげふん。これは酷い。そう、「実績解除」だけ利用できればいいや、って人が利用出来なかったのです、なんだってー。あともう一つ、「GamerTagの入力を大文字小文字を区別しないように変更」です。今まで区別していたので、例えばnEUEcCとか入力すると、同期出来てませんでした。これはいかんですね。いかんので、区別しないようにしました。
ていうか、自分の環境で再現しない問題、じゃなくてただたんに例外ケースの見積もりが甘すぎなだけですなあ。もうちっと気を引き締めて書かないとダメですね。
追記
ver 1.3.0.6になりました。1.3.0.4以降は「+記号」が使えなかったっぽいので、それを直しました。ダメダメすぎて涙。
ver 1.3.0.4 動かなくなったのでちょっと書き換えた
- XboxInfoTwit - 09.07/29
昨日の朝だか昼だかから動かなくなってたっぽいので、それを直しました。何で動かなかったのかよく分かってないんですが、ダメになった箇所だけは分かったので別のアプローチで、ということで。応急処置もいいとこで、まー情けないのですが、動けばいっか、ってことで。眠いし。ダメですかダメですねすみません。
今後だと、一応ダッシュボードのアップデートが8月に控えているらしいので、それでも引っかかってダメになるかもしれませんが、ダメっぽくなったのを捕捉次第、速やかに直したいとは思っているのでダラダラとお待ちください。
ver 1.3.0.3 / ちょっとした拡張メソッド群
- C# XboxInfoTwit - 09.07/16
Gears of War 2やCall of Duty : World at Warでステータスが取得出来なかった件を修正しました。GoW2は修正を確認出来ましたがCoD:WaWは持ってないので分からない。多分直ってると思うけど。あと、この修正の影響で他がダメになる可能性がなくもないです。ダメっぽいのを発見したら即直す、という方向で暴走さえしなければある程度はいっかー、的にゆるふわ気分でいるのですがダメでしょうかダメですね。
ところで、int.Parseが多くなって結構面倒くさいので文字列に拡張メソッド。
public static int ToInt(this string value) { return int.Parse(value); } public static int ToIntOrDefault(this string value) { int result; int.TryParse(value, out result); return result; } public static string Remove(this string input, string pattern) { return Regex.Replace(input, pattern, ""); } public static Match Match(this string input, string pattern) { return Regex.Match(input, pattern); } public static string Replace(this string input, string pattern, MatchEvaluator evaluator) { return Regex.Replace(input, pattern, evaluator); }
RemoveとReplaceは既存のメソッド名のものに足してるので、別の名前のほうが良いかしらん。あと、Replaceは引数が被るので、ただの文字列置換は用意できなかった。まあ、_ => “hogehoge” といった具合に「_ => 」が増えるだけならそう手間でもないような十二分に手間のような。
totalGamerScore = document .Descendants("div") .First(e => e.GetAttribute("className") == "XbcProfileSubHead") .Descendants("strong") .Last() .InnerText .Match(@":\s*(\d+)/") .Groups[1] .Value .ToInt();
こんな風に書けます。これでスクレイピングも快適ー。ドット繋げまくれてバンザイしちゃう。ただまあ、デバッグはし辛いですね。ログ吐くメソッドを仕込んだりもいいんですが、もっと単純に、ラムダ式挟めばデバッガで止められるので
public static class Ext { public static TResult Tap<T, TResult>(this T self, Func<T, TResult> func) { return func(self); } public static T Tap<T>(this T self, Action<T> action) { action(self); return self; } }
RubyのTapみたいな、ということで。
ダミー置いて、その場で止められるようになる。それで作って、出来あがったらTapの行をCtrl+Xでゴミ箱ぽい。IEnumerableの場合は、普通にダミーのSelect置けばいいだけでしたね! 今、そのことに気付いた。うーん、あと.Groups.Cast<Group>().Skip(1).Select(g => g.Value) も、頻繁にあるあるなので、Matchに拡張メソッド埋めときますか。
