続・Type Zが欲しい。

VAIOのType Zが欲しい。

Type Pを一月に買ったばかりな気がするけどType Zが欲しい。

そして、家のデスクトップPCを一掃したい。

Type Zが欲しい。 – NAL-6295の舌先三寸

悩んでいたら、いつのまにか液晶の解像度とグラフィックアクセラレータの無料アップグレードキャンペーンが終わってたよ。

今日の15時までだったらしい・・・。

1万円はでかい。

Share

未だに3年以上前の記事が一番人気

まぁ、そんなわけで、私が書いているコードはほとんどTry-Catch-Finallyではなく、Try-Finallyばかりだ。

正当な理由がある(Catchする事に意味がある。)時や、付加情報を付けて再Throwしたい時くらいしかcatchしない。

むやみにキャッチしないでね。ゴールキーパー以外はハンドで反則ですよ。 – NAL-6295の舌先三寸

うれしい反面、最近、あまりちゃんとした内容の記事を書けていないなと。

確かに最近は、ブログに対する熱が若干冷めてきた感じはあります。

Share

Type Zが欲しい。

VAIOのType Zが欲しい。

Type Pを一月に買ったばかりな気がするけどType Zが欲しい。

そして、家のデスクトップPCを一掃したい。

とりあえず、HPのWindows Small Business Server 2003搭載サーバをなんとかする事から始めないとな。

Share

webapp.WSGIApplicationでのURLマッピングを誤解していた

今、必要だったので、2アクションで行動履歴が取れるウェブアプリを作っているのだけれど、JQueryを活用して、Ajax的な動作を盛り込もうと試行錯誤しているところ。

スクリプトファイルを

index.py(通常の表示)

delete.py(削除処理を行う)

list.py(履歴表示を行う)

の3つにわけた上で、index.pyにimportしindex.pyのmainでwebapp.WSGIApplicationを利用してURLマッピングしていたのだけれど、どうもindex以外は無反応だった。

しかし、そもそも、この考え方がおかしかった。

リクエストはそれぞれ独立しているので、それぞれのスクリプトのmainが実行されるわけで、delete.pyがリクエストされるような時にindex.pyが呼ばれるわけがない。

そこで、それぞれのスクリプトファイルのmainにそれぞれwebapp.WSGIApplicationを利用してマッピングしたら無事動作するようになった。

今思えば、どうでも良いところで1時間もはまっていた。

複数のスクリプトファイルにする事と、Ajax化する事を同時に行っていたことで、何が原因で動かないのか分かりづらい状況になっていた。

やはり、同時に複数の事をするべきではないという事だ。

Share

Apple In-Ear Headphones with Remote and Micを買った

Apple In-Ear Headphones with Remote and Micを買った。

前々から気にはなっていたんだけど、既にTriple.Fi 10 proを買っているし、もういいやという気になっていた。

しかし、最近また物欲が沸いてきて逡巡した挙げ句、購入。

家に帰って聴くと、やはり10proと比べると、どうしても劣って聞こえる。

空気感が薄く、一枚膜がある感じ。

まぁ、値段が4倍以上する製品と比べてはいけないのだろうけど、収穫といえば最近慣れていた10Proのありがたみが再確認出来たということ。

ただいま、エージング中なので、また印象が変わることはあるかもしれない。

ただ、あくまで10Proと比べると、いけてないだけで十分いい音ではある。

10Proのケーブルが断線したときの代わりにはなるかなといった感じ。

Share

Yahoo!の形態素解析APIを利用してケブンリッジ ジェレネータを作ってみた

XMLElement等の使い方がいまいちわからなかったので、汚いソースコードになってしまったが、Yahoo!の形態素解析APIを利用してケブンリッジ ジェネレータを作ってみた。

ケンブリッジ ジェネレータともいう。

Yahoo!の日本語形態素解析については↓

http://developer.yahoo.co.jp/webapi/jlp/ma/v1/parse.html

あなたのアプリケーションIDの場所を取得したアプリケーションIDに置き換えれば、使えます。

先頭と末尾を維持したままスペルをランダムに変えるメソッドを呼ぶだけでよいです。

取り急ぎ。

XElementの使い方が分かったので書き直し。

private string  単語ランダム化(string 変換前単語)
{
//なんで、三桁までの単語は何もしないのかって、三文字じゃ順番を変えようがないからだ。
if (変換前単語.Length <= 3)
{
return 変換前単語;
}
string 変換後単語 = 変換前単語;
変換後単語 = "";
var キャラクタリスト = 変換前単語.ToCharArray(1, 変換前単語.Length - 2).ToList();
変換後単語 = 変換前単語.Substring(0, 1);
var ランダム番号生成オブジェクト = new Random();
while (キャラクタリスト.Count() >= 1)
{
var 対象Index = ランダム番号生成オブジェクト.Next(キャラクタリスト.Count());
変換後単語 += キャラクタリスト[対象Index];
キャラクタリスト.RemoveAt(対象Index);
}
変換後単語 += 変換前単語.Substring(変換前単語.Length - 1);
return 変換後単語;
}
private List<string> 形態素解析の結果(string value)
{
string requestUrl =
string.Format("http://jlp.yahooapis.jp/MAService/V1/parse?appid=あなたのアプリケーションID&results=ma&sentence={0}",
System.Web.HttpUtility.UrlEncode(value));
byte[] responseData = null;
using (System.Net.WebClient client = new System.Net.WebClient())
{
responseData = client.DownloadData(requestUrl);
}
List<string> result = new List<string>();
XElement Root = XElement.Parse(System.Text.Encoding.UTF8.GetString(responseData), LoadOptions.None);
IEnumerable<System.Xml.Linq.XElement> elements = Root.Descendants(Root.Name.Namespace + "reading");
foreach (XElement element in elements)
{
result.Add(element.Value);
}
return result;
}
public string 先頭と末尾を維持したままスペルをランダムに変える(string 変更前)
{
var 単語リスト = 形態素解析の結果(変更前);
StringBuilder 変更後 = new StringBuilder();
foreach (var 単語 in 単語リスト)
{
変更後.AppendFormat("{0} ", 単語ランダム化(単語));
}
return 変更後.ToString();
}

サンプル画像

f:id:NAL-6295:20090514121409p:image

Share
カテゴリー: .NET

「必要なインデックスがねえよ。」と言われたから困った

Google App Engineに新しいアプリをアップして実行しようとしたら

「必要なインデックスがねえよ。」

と言われた。

ローカルではうまく動くのにと思いながらダッシュボードで状況を確認したら、そのインデックスは存在するんだよね。

ただ、building(構築中)になっているので、使えない。

どうしようかなと思いながら朝になったので試しにアクセスしてみたら、ちゃんと構築が終わっていた。

昔は、すぐ使えるようになっていたような気がするんだけど、いつのまにか時間がかかるようになったのか、何かがまずかったのか・・・。

Share

推奨されたルールもまた銀の弾丸ではない

なんで、その段取りでやっているの?

なんで、そんなコーディングをしているの?

と聞くと

「○○がそうしているから。」

「○○が推奨しているから。」

という理由になっていない答えが返ってくることがある。

そのような相手は更に

「じゃあ、○○が推奨している、その手段に、どんな利点があるの?」

と聞くと返答に窮する場合が多い。

なぜなら、なんで、推奨しているか分からないから

「○○がそうしているから。」

「○○が推奨しているから。」

と返答するしかないんですね。

そして、まったく効果的ではない場所でも、同じ事をしてしまう。

なぜなら、なんで、推奨しているか分からないから。

どんな局面で、そうすると良いのか。

どう良いのか。

推奨されている理由を、

ルールになっている理由を、

ちゃんと理解していないとただの足枷にしか、ならないという事なんですね。

だから、

ルールを運用する側は、ちゃんと理解した上で運用する必要があるし、

ルールを決める側も、ちゃんと理解してもらえるように説明する必要がある。

Share