prog

Posts filed under prog

あーなんか実物見てみたい

Filed in prog

 言語を分析し、自律的に文法規則を推論するアルゴリズムなんつーのが発表されたとです。
 興味津々です。言語処理って割と萌えます。夢はコンパイラを作る事です。いえ、ちっちゃいのなら作れますけども……
 長月割と言語処理に興味あるみたいで、コンパイラだとか人工無能だとか作りたい人なんですね。
 なんだか随分前にモチベーション切れて以来あんまり触ってないんで忘れがちですが、一応色々勉強したようです。
 今回の技術、人工無能に搭載してみたい感じです。その内人工無能は考えるさんが取り上げそうな気がします(´ω`)
 綺麗にまとまるの期待して待ってるんで頑張ってくださいw>しまりすさん

長月葵->Status()->Perl

Filed in Perl, prog

 てなわけで長月の Perl 力がどれぐらいなのか。
 最近マイブームの何とか判定をやった訳ではないので主観なんですが、とりあえず基準としては http://d.hatena.ne.jp/naoya/20050809/1123563794 で書かれている物を使います。
 レベル4: use strict はもう書き出したら自動書記するぐらいだけど use warnings なんてしてないなぁ。 -w スイッチじゃダメですか?w
 レベル6: CPAN はあまり使わないかなぁ。標準モジュールで足りる事も多いし。まあでも標準モジュールに欲しい物が無ければとりあえず CPAN 見に行くのはやるから○かなぁ。
 レベル7:オブジェクト指向で書くとかモジュール作るとかは CPAN あさる様になる前からやってますがね。なんか学習の順番も割と個人差あるはずだからこのレベル表割と違和感ある人多そう。
 レベル8: AUTOLOAD は知ってるけど使いこなすというかふと使おうと思うほどは習熟してないなぁ。CPAN にモジュール送ったりもしないし。初心者さんに教えたり CGI.pm 使って CGI 作ったりはするけどね。
 どうも当てはまりそうなのはここらまでかな? レベル8についてはちゃんと対応できてるとは思えないのでレベル7ぐらいかな。
 なんか割とやっと中の上ぐらいになったかなと思ってたのは大体あってたみたいです。
 なんだかんだで Perl 使いつづけて四年ですからそれぐらいにはなってても不思議じゃないですね。
 ここを見てる Perl 使いの皆さんは如何ほどでしょうか?

リアルタイム/マルチタスクシステムの徹底研究

Filed in prog, , 読書感想文

 良書。
 もうすぐ組込みプログラムをお仕事で書く立場になるので勉強の為に買ってみました。どうやらこの選択は正解のようです。
 組込み系の世界で利用される技術を比較的わかりやすく読みやすくまとめています。
 専門分野の本だけあって少々前提知識を必要としますが、この本に興味を持つ人なら大丈夫でしょう。
 入門者向けの物をお求めなら「はじめて読む486」やなぜ動くのかシリーズをオススメします。

えーと、あれー? その後

Filed in Perl, prog

 なんかどうも糞いMIME エンコード済み文字列を持ってるらしい携帯メールのデータに付いてあれこれ調べてたんですが、 「なんか自力でやらなくても携帯メーカにデータ取り込むソフトあるらしいぞ」と言う事が判明。出来るからって調べる前に動く無計画っぷりが知れます。とりあえずはメーカホームページへ直行。
 しかし眺めてみてもSDカード経由での操作が用意されてない模様。糞い。仕方ないのでUSB経由でと思って携帯を買った時にブツが入ってた袋を探ってみてもケーブルなんぞない。うわ、別売ですか?
 結局自力でやる事に決定……orz
 さらに調べて回って結局解らないので RFC を読みに行く。最初からやっとけよって話なんですが英語読むのめんどくさいんです。日本語訳済みは訳が好みじゃないとか、どこまで正確か信じられないとかの問題で読むなら原版って人なんで。原版でも自分訳がアレなら結局同じとか原版書いた人が間違ってたらって話は棚に上げときます。
 それで RFC 2045 読んで 6.7.5 Soft Line Breaks 辺りが怪しげに見えたりしてやってみました。ソフト改行用の等価記号削除。見事に文字化け解消。それぐらい対応しといてくれ MIME::QuotedPrint ……orz
 むぅ、ライブラリの類は普通それなりにブラッシュアップしてある物と思い込んでたのが敗因ですね。疑ってごめんなさいPで始まる某社の担当の人m(_ _)m
 こんな事だから「これからはモジュールを信用しないで、むしろモジュールまで自作で行くべき!」とか車輪の再発明好きに言い訳を与えるんですよね┐(´ー`)┌

えーと、あれー?

Filed in Perl, prog

 以前書いたメールをうんちゃらのスクリプトなんですが。Perl で MIME::Base64 モジュールと MIME::QuotedPrint モジュール使って復号化してます。
 しかしなにやら文字化けなさるんですよね。んで元データ見てみたらなにやら微妙に不正なデータ。曖昧変換できたらまあいけるんだろうなって感じなんですが、MIME モジュールは割と厳密な変換をするようで化けます。
 これ何とかならないんですかね? オプションとかで曖昧変換出来たりとかしないんですかね?
 ああ、そう言えば use MIME::Explode; してる割に使ってないなw ヘッダの解析にせswitch 文でやっちゃってるよ'`,、(´∀`)'`,、

XSLよーわからん(´・ω・`) おかわり二杯目

Filed in prog

 こんなとこ見っけた。検索で来た人、うち見てる暇あったらサンプル熟読!

XSLよーわからん(´・ω・`) おかわり

Filed in prog

 いやもう大変でした。
 メッセンジャーのログ側が改行を <br /> に変換してくれてないので、何とかして改行を <br /> に変換しないと変な表示になる問題がありまして。
 昨日エントリを書いた時点では <pre> タグで囲んで誤魔化してたんですが、何か納得行かないので何とかしようと試みてみました。
 とりあえずは XPath 関数を調べてみて translate 関数が使えるかも? とやってみるも、第二引数と第三引数の扱いを勘違いしていて実は使えない関数だと発覚。
 仕方がないのでスクリプトでやるかとちょちょいと JavaScript を書き書き。しかし <xsl:value-of> タグはタグの位置に対応するテキストノードをべたっと展開するので改行が邪魔。これも上手く行きません。
 次の手をと <xsl:template> タグを用いて再帰的に substring-after 関数と concat 関数に突っ込む事で何とかしようと試みるも、<xsl:variable> は変数が const、これも断念。
 ひたすら悩んだ結果 translate 関数と JavaScript を組み合わせる事にしました。詰まり改行を translate 関数で他の文字に変換、その文字を <br />\n に再変換です。異様にアドホックで気に入らない解決策ですが仕方ありません。特殊文字代わりとして出現頻度の低そうな半角鍵括弧でも使っときませう。
 しかしこれも問題あり。 JavaScript で定義した関数の呼び出し側でシングルクォートを使っている為、対象のテキスト内にシングルクォートがあるとそのシングルクォートが引数括りの終わりと認識されてそのテキストが表示されません。なんてこった、ここまで来て……orz
 まあでも、さっきと同じ方法でいけるだろと translate 関数の引数にシングルクォートの実体参照を追加、特殊文字代わりに半角鍵括弧の残りを使えばいいかとやってみる物の。実体参照部分が普通のシングルクォート扱いで translate 関数の引数が不正に。ぽまいクォートの実体参照ってクォート内でも同種のクォート使える様に定義されてるんちゃうんかいと、どないせーっちゅうねんヽ(`Д´)ノ
 仕方がないので気持ち悪い物の JavaScript で定義した関数を呼び出す側で引数を括ってるクォートをダブルクォートにする事で凌ぎました。引数で渡してる <xsl:value-of> でもダブルクォート使ってていやんなんですが(´・ω・`)
 多分対象テキスト内にダブルクォートがあるとおかしな動作をする事でしょう……orz
 でも良いんです、長月の場合 MSN でのチャットでは顔文字の関係でシングルクォートは頻出する物のダブルクォートはあんまり出てこないですから(´・ω・`)
 すでにアドホックだし今更気にしないことにします。

GoF本第四章その5: Decorator

Filed in C/C++, prog, , 読書感想文

 仕事中に右手人差し指の先を切り、さらに右手中指の爪が割れて先の方が五分の一ほど剥がれかけな長月です。皆様はご健勝でしょうか? 長月は本人も仮想世界への代理人も割と不健康な感じです。皆様はご自愛ください。
 さて、キーボードが少し打ちづらいながらも基本的に左利き寄りの両利きの為割と生活には支障ないのでいつも通りエントリは追加される訳です。今日はもうそろそろ見てる方々も飽きてきたであろう GoF本 第4章から Decorator パターンです。
 Decorator パターンはオブジェクトに動的に責任を追加するパターンです。ロジックとしては前回取り上げた Composite パターンと似ています。Composite パターンは、コンテナとプリミティブなクラスを同じクラス階層に置く事でツリー状にお互いを包含する構造を作り出し、部分と全体に差を無くすパターンでした。Decorator パターンの場合も、Composite パターンでも行われた様に、全体を俯瞰する為のルートクラスを用意し、Decorator に当たるサブクラスではルートクラスのオブジェクトへの参照を持つ事で連鎖します。Composite パターンとの違いはルートクラスのインターフェイスが最大化しない事ですかね。
 Decorator パターンは、個々のオブジェクトに責任を追加し、且つ他のオブジェクトへの影響を最小化すべき時。責任の追加に加えて、責任の削除が出来るべき時。サブクラス化による責任追加が現実的ではない時。等に利用されます。
 Decorator パターンは継承を用いた拡張よりも柔軟です。また、クラス階層の上位のクラスが、所謂「スーパーマンクラス」になる事を防ぎます。
 しかし、ある Decorator クラスが装飾しているクラスはその Decorator クラスと同一ではないので、同一性に期待したコーディングが出来ない。非常に似通った小さなクラスが氾濫する。と言う欠点も持ちます。
 前述の通り Decorator パターンは Composite パターンと似通っています。構造を良く見てみれば内部に持つオブジェクトが一つに制限された Composite パターンに見えます。しかし Decorator パターンはオブジェクトの集約を目的としている訳ではありません。Decorator パターンはオブジェクトに責任を追加します。
 長月は Decorator パターンを余り使った事がないんですよね。もしかしたらやってるかもしれませんが、意識して使った事って少ないです。なんと言うか、動的に責任を追加する場面が余りないというか。そんなトリックが必要になるほど複雑な物を作ってないというか。そもそも殆どプログラム書いてな……げふっ(吐血
 まあそんな訳で今回はここまで、次回はおそらく長月の理解度が本書中一番低い Facade パターンをお送りします。

GoF本第四章その4: Composite

Filed in C/C++, prog, , 読書感想文

 今日は構造に関するパターンの三つ目、Composite パターンをお送りします。
 Composite パターンは複数のオブジェクトを合成します。また、合成されたまとめオブジェクトを一様に扱えるのが特徴です。
 プリミティブなオブジェクトを組み合わせる事で複雑なオブジェクトを構成する事はままあると思います。しかし、その時にそれらのオブジェクトを一様に扱う事に困難を覚えた事はありませんか? 例えば、プリミティブなオブジェクトをまとめて扱う方法としてコンテナへの格納は一手でしょう。しかし、プリミティブなオブジェクトとプリミティブなオブジェクトを集めたコンテナは別物です。いくつかのオブジェクトをまとめた物と、単一のオブジェクトを区別なく扱う。それが Composite パターンの提供する合成です。
 Composite パターンでは、プリミティブなクラスとコンテナクラスを同じクラス階層に置きます。詰まり一つの抽象クラスがコンテナでも、プリミティブなクラスでもあるのです。
 例として GUI コンポーネントを考えてみましょう。GUI コンポーネントには、Button や Label、Inputbox の様なプリミティブなコンポーネントや、Window や Panel 等の、他のコンポーネントを内包するコンポーネントが考えられます。Window クラスや Panel クラスは他のコンポーネントオブジェクトを内包するコンポーネントなので ContainerComponent から派生します。Button クラスや Label クラスはプリミティブなコンポーネントなので PrimitiveComponent から派生します。さて、これらを統一的に扱うにはどうしますか? ContainerComponent と PrimitiveComponent に共通の親クラス Component があれば良いですよね。これで Composite パターンの言う形になりました。これは ContainerComponent をノード、PrimitiveComponent をリーフとしたツリー構造と言えます。Composite パターンは、再帰的に複合オブジェクトを構成していくパターンなのです。
 Composite パターンでは、その構成要素であるノードに当たるクラスも、リーフに当たるクラスも区別しません。その特徴によってクライアント側のコードはノードであるかリーフであるかを意識せずにコーディング出来るようになります。また、部分と全体に区別の無い構造なので、柔軟な構成の変更が出来ます。
 しかし、設計を過度に一般化するというデメリットも持ちます。
 実装の面で言えば、Composite パターンは、その構造上ツリー構造の持つメリットデメリットを同じように持つようです。また、ルートに当たるクラスは自らの子孫であるクラスのインターフェイスをほぼ全て持つことになります。これはインターフェイスの最大化と呼ばれる好ましくない設計の一つです。
 Composite パターンは Decorator パターンと共に良く使用されます。この場合、Decorator パターンは Composite パターン側のインターフェイスに合わせる必要があり、若干割を食うようです。
 Composite パターンを用いた構造では、内部の操作に Iterator パターンが良く用いられます。
 Composite パターンは割と良く使われているはずです。なんと言うか、オブジェクト指向の本を読むと必ずこういった感じの設計について書かれてますし。文中で挙げたコンポーネントクラスの様に、素直に考えれば Composite パターンになる場合も多いからです。
 しかしそれだけに、経験だけで書いている方も多いのではないでしょうか? Composite パターンが持つメリットデメリットを再確認する為にも一度勉強しなおしてみるのも一手ですよ。
 では今回はここまで、次回は Decorator パターンをお送りします。

GoF本第四章その3: Bridge

Filed in C/C++, prog, , 読書感想文

 構造に関するパターンの二つ目は、前回も書いた通り Bridge パターンです。
 Bridge パターンは Handle/Body とも呼ばれ、割と良く使われているパターンだと思います。Bridge パターンはパブリックなクラスの定義と実装を分離し、それらを独立に変更できるようにしたパターンです。
 実装の分離と言うと pimpl イディオムを思い出しますね。あれも Bridge パターンの一形態だと思います。しかし Bridge パターンでは、実装の分離に関する思惑が pimpl イディオムとは違います。Bridge パターンは、実装上の汎化関係にあるクラスの関係を意味上の汎化関係を分離します。一般的に汎化関係は抽象クラスと継承を用いて表現されますが、クラス階層の中に実装上の汎化関係と意味上の汎化関係が混在すると、それぞれを独立に変更する事が困難になります。
 そんな場合、Bridge パターンを用いて実装と意味の階層を分離します。クライアントが参照する物は意味の階層、意味の階層の中で実装上必要とする物は実装の階層で定義する事で、クラス階層単位でのインターフェイスと実装の分離を実現します。
 Bridge パターンは抽出されたクラスとその実装を分離し、実装を動的に選択したり交換したりしなければならない場合、抽出されたクラスとその実装を両方ともサブクラス化によって拡張可能にする場合、抽出されたクラスの実装が変更によってクライアントに影響を与えるべきではない時、C++のような言語で実装を隠蔽したい時、複数のオブジェクト間でクライアントから隠蔽した状態で実装を共有したい場合等に使用されます。
 C++のような言語で実装を隠蔽するというのはまさに pimpl イディオムですね。一番良く使われる Bridge パターンではないでしょうか。
 Bridge パターンと Adapter パターンはクラス同士を繋ぐという関係では同じです。しかし Adapter パターンは既にあるクラス等、設計後に適用される事が多いのに対し、Bridge パターンは抽出されたクラスと実装を分離する為に、言い換えれば外部に向けた設計と実装を分離する為に、設計の早期に適用されます。
 長月は割と最近まで Bridge パターンを軽視していました。Bridge パターンというより pimpl イディオムですね。Exceptional C++ を読んでからは考えを改めたのですが、実装の隠蔽以外の意味で使用する Bridge パターンも馬鹿に出来ませんね。解っているつもりでやっぱり「ああなるほど」と思う所もいくつかありました。いや、本は読むものです。
 では今回はここまで、次回は Composite パターンをお送りします。


Warning: sprintf() [function.sprintf]: Too few arguments in /home/users/2/lolipop.jp-dp07042166/web/wordpress/wp-includes/widgets.php on line 1042
Oenology Post Formats
Click to view/hide

Warning: sprintf() [function.sprintf]: Too few arguments in /home/users/2/lolipop.jp-dp07042166/web/wordpress/wp-includes/widgets.php on line 1042
Posts Calendar
Click to view/hide
2017年8月
« 12月    
 12345
6789101112
13141516171819
20212223242526
2728293031  

Warning: sprintf() [function.sprintf]: Too few arguments in /home/users/2/lolipop.jp-dp07042166/web/wordpress/wp-includes/widgets.php on line 1042
アーカイブ
Click to view/hide

Warning: sprintf() [function.sprintf]: Too few arguments in /home/users/2/lolipop.jp-dp07042166/web/wordpress/wp-includes/widgets.php on line 1042
最近の投稿
Click to view/hide