RSS

月別アーカイブ: 4月 2011

C#でヒアドキュメント

 ちょっと調べて思ったこと。

 ヒアドキュメントっていうのは元々何の用語なのかはっきり知らない(来歴を知っている人がいれば教えていただきたい)が、シェルスクリプトを書くときや、言語的にはPerl、PHPの系統で使われる用語だ。意味としては「エスケープなどを必要とせず改行などを含むことが出来る文字列の記述法」くらいのものと思って良いだろう。
 C#の文字列リテラルでもヒアドキュメントと似たようなことが出来るのだが、呼び名が若干違う。MSDNでは「逐語的文字列リテラル」と表記されているが、他にも、「ヒアストリング」「@-quoted string」のような呼ばれ方もされるようで、どうにも統一性がない。確かに逐語的文字列リテラル…なんて変にややこしいだけの気もする。個人的には「ヒアストリング」がすっきりしてていいかな。

 具体的な記述法はこう、文字列リテラルの頭に@を付ける。

            string filepath = @"c:\hoge\fuga\piyo.xml";

            string strLines = @"エスケープ無しでも
                                改行付き文字列が作れるんだ。";

            string incQuote = @"ちなみに二重引用符は""こんな風に書く""と使える。";

 参考:http://msdn.microsoft.com/ja-jp/library/ms228362.aspx
 
 上記filepathの区切り文字のようにエスケープが必要とされる文字列を記述するのに便利ではある(バックスラッシュは本来なら\\と書かなければならない)。また同様にエスケープが必要な改行も、strLinesのように書くことが出来る(本来は\nなどと書く)。
 ただし「プレーンテキストをそのまま出力したい」という時にはあまり向かないと思う。なぜなら、当然のことだが、インデント用の空白も文字列として含まれるからだ。strLinesをこのまま出力した場合、インデント分だけ二行目の頭に空白が出力されてしまうことになる。どうしても空白が邪魔であれば、左詰めにして書くしかない。

string indentIyayo = @"インデントの空白が嫌なので
左詰めして
書きますよ";

 ただし見た目(=可読性)の問題がある。今はサンプルコードなのでこの程度だが、実際にはもっと深いインデントで書かれるだろう。namespace -> class -> method だけでも3段階程と考えると、1インデント4whitespaceだとして12個も空白があるわけで、そんな中で左詰め記法をしたらソースの可読性は著しく落ちてしまう。まぁこれはHTMLの<pre>タグでも似たような悩みと言えよう。
 ということで、自由に改行するためにヒアストリングを使う場合は「インデントの空白を無視してよい」ような状況、例えば、「通常は出力はしない」とか「あんまりメモリの制約を気にしなくて良い」という状況で使いましょう、ということになる。…まぁ好みの問題かもしれないけど。

 さてこんなヒアストリングだが使いたくなる局面といえば、先ほどのファイルパスの他、SQL文みたいなものをハードコーディングする場合がある。まぁ細かい議論は省略するが、SQL文をヒアストリングで書きたい場合とは要するに「面倒くさい記述をしたくない&可読性も確保したい」時だろう。可読性を考えると左詰めという技法はまず採用出来ない、と、なるとインデント空白を許容しなくてはいけない。
 SQL文ハードコーディングにおいてインデント空白が邪魔になる状況はあるだろうか?パッと思いつく限りではログ出力だ。デバッグ時や、例外発生時にSQL文をログ出力したいことは良くある。そういう時、あまり深いインデントでヒアドキュメント記述していると、ログでSQL文がやたら右の方に出力されてしまうし、記述場所がバラバラだとSQL文によって出力位置が変化しまって読みづらい。
 ということで、もしもSQL文をヒアストリングでハードコーディングする場合は、まとめて定数フィールドとして定義しておくのが良いだろう。

    public class DataBaseAccess
    {
        const string SQL_HOGE = @"
            select *
            from
                HOGE_TABLE hoge,
                FUGA_TABLE fuga
            where
                hoge.ID = fuga.ID
        ";

        private void selectHogeFuga()
        {
            // db はなんかSqlDataSourceみたいなオブジェクト。超適当。定義もしてないw
            db.selectCommand(SQL_HOGE);
            db.select();
        }

    }

 こんな感じ?適当すぎてゴメンナサイ。
 フィールド定義であれば左インデントも最小限に抑えられるし、同じインデント階層で定義することで出力位置もバラバラにならない。まぁ、ヒアストリング使わなくても普通はそうやって書くと思うけどね…(StringBuilder派はReadOnly化してstaticブロックで書いたり?とかかもだけど)。
 SQLの記述法としては何が綺麗なやり方なのか模索中だったりする。外部リソースとしてXMLファイルかテキストファイルで書いておいて別途作った読み込みモジュールで読み込む…というのが好みだったりするけど、毎回それが必要とも限らない。まぁ、それは別のお話なので掘り下げないけど。

 ぶっちゃけこんな記法が出来たらいいのに!と思ったりもする。

string newHereStr = @" こんな書き方あったらいいな。
                    $ 特定の記号より左側の空白は消される。
                    $ 可読性も確保され、記述の面倒さもあんまりない.
                    ";

 この場合、$が特殊な文字になっていて、その左の空白が無視される記法という意味。まぁ、これを実現する文字列操作関数を自分で作ることは可能だが、コスト考えると微妙だし、ちょっと強引すぎる気もする。実際こんな実装を持つ言語もあるようだけど、便利に使われているのだろうか?

 以上。予定の3倍くらいの長さのエントリになってしまった…。

 
1件のコメント

投稿者: : 2011/04/24 投稿先 プログラム, C#

 

タグ: , , ,

Visual StudioにおけるUTF-8の取り扱い

 たまには技術的な話題も書いていかないとね。
 といっても、ちょっと引っかかった程度のこと。

VisualStudioのテキストエディタではデフォルトで文字エンコードUTF-8で保存されるが、こいつはBOM付きなので注意すること。特にテキストファイルをプログラム中やWebページで取り扱うような場合。

という話。

 UTF-8エンコードでのテキスト記述が一般的となってきている昨今、そのファイルがBOM付きか否か、という注意は常識とも言える。多くのプログラマが一度は引っかかったことがあるのではないだろうか。この問題が根深いのは、何も考えずにIDE(統合開発環境)で保存するとデフォでUTF-8(BOM付)でエンコードされることが多いから、なのだろう。今回はVisualStudioだったが、Eclipseもそうだったような気がする(未調査)。BOM付きで保存されることを知っていたり、きちんと意識するようにしている時は問題ないが、気を抜いてると原因不明の空白に悩まされることになる。
 んで今回すっかりVisualStudioのことを信頼して気を抜いていた私も、危うくはまりかけたわけで、以下、一応経緯の記録。コード挿入タグを使ってやろうじゃなイカ、という目的もある。

 なお、BOMって何?問題は?という話はGoogle先生に丸投げします。 参考: バイトオーダーマーク – Wikipedia

[事例]

 ASP.NETで開発するWebページにて、外部テキストファイルに定義したHTML構造を挿入したいとする。これはページのヘッダやメニューを表示する際に良く行われる手法だ(ASP.NETならマスターページを使うという手もあるが、実はASP.NETは今回初めての触り始めなので、あのコントロールが裏で何をしてるか良く知らない)。例えば以下のASP.NETページを作成し実行する。

WebForm1.aspx

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="WebForm1.aspx.cs" Inherits="HtmlIncludeTest.WebForm1" %>

<!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 runat="server">
    <title>部分HTML挿入テスト</title>
    <meta http-epuiv="Content-Type" content="text/html;charset=utf-8" />
</head>
<body>
    <form id="form1" runat="server">
    <h1>部分HTML挿入テスト</h1>
<div style="width:200px;border:2px solid #00F">
<% Response.WriteFile("InsertPart.html"); %>
</div>
    </form>
</body>
</html>

InsertPart.html

<div style="border:2px solid #F00;">
<h2>今日の格言</h2>
<p>「訳が分からないよ。どうして人間はそんなに、魂の在処にこだわるんだい?」  </p>
</div>

 上記コードで表示されるページは以下のような画像になる。

HTML挿入プレビュー画像

 おかしな空白が入っていることがわかる。ソースを表示すると(表示に使うテキストエディタにも依るが)、上記のハイライト部分にあたる挿入テキストに半角空白が入っていることが確認できる。どうしてこういうHTML構造で表示上空白が入るんだったかという方は忘れたが…なんでだっけ。
 なお実際に直面したときは、埋め込みコードの書き方や、HttpRespose#WriteFile()メソッドを疑った(なにせASP.NETに不慣れだったので)。しかしそちらに問題はないわけで、ではでは、とファイル自体を疑ってバイナリエディタで表示してみると明らかにBOMなバイト列が入っていることがわかる(下の画像)。

[解決策]

 兎も角これじゃ困るので、BOMを削除する。しかしなぜかVisual StudioはBOMなしUTF-8が指定出来ないようで、バイナリエディタで無理矢理削除するか、別のテキストエディタで文字エンコードを指定しなおして保存する。
 で、ファイルを差し替えることでちゃんと空白が無くなる。


 よくある話といえばそれまでだが、IDEのデフォルトの指定がそうである、というところが罠っぽくなっていると思う。おそらく、IDEがUTF-8ファイルを判別する都合上、BOM付きで取り扱うことにしているのだろうが、それにしたってBOM無し指定にするメニューがあっても良いと思う。もしかしたらあるのかもしれない。もしくは、BOM無しにすると何か不都合があるのだろうか?今回の事例ではあまり問題になるようなことはなかったけれど。

 以上。トラブルシューティングというか、よくあるサンプルコード記事というのを目指して書いてみたけども、結構大変だな…画像を用意したり、サンプルコードを書いたり。世の中のコードサンプルブログの筆者はよく根気が続くなぁとも思う。
 まぁ今回は面白い話ではなかったけれども、今後何かしらもうちょっと役に立ちそうな、オリジナリティのあるコーディング記事でも公開していきたいところだ。

 
コメントする

投稿者: : 2011/04/16 投稿先 プログラム, C#, Visual Studio, Web

 

タグ: , , , , , ,

通勤用図書

 私は基本的に文庫本を読むのは通勤時だけと決めている。
 そうすることで、通勤が楽しみにすらなるから。

 通勤路線が日本混雑路線ワースト1と2である中、毎日通勤するのはそこそこ辛い。そこそこ、というのはそもそもワースト路線の混雑はそんなに辛いものではないからだ。まぁ路線混雑については色々語ることも多いのでいつか別エントリで書こうと思う。
 ともあれ満員電車はだるい。それでも「昨日の続きが読めるなら…!」と思えば気分も楽になる。というか楽しい。この通勤図書のおかげで通勤があまり苦にならない生活を送ることが出来ている(体調が悪い時を除く)。

 しかし、当然ながら弊害はある。
 まず乗車時間が数10分程度しかない。乗り継ぎ後は10分しかない。往復総計して一日に1時間程度しか読み進める時間がない。しかも私の読書スピードは(多分)人並みなので、原則として多読は出来ないことになる。ただ、内容にもよるが新しい文庫小説を1冊買えば1~2週間は保つ計算になるので、ある意味コストは抑えられる(いいやら悪いやら)。
 精神的影響もある。特に朝の通勤時、小説の内容がクライマックスだったりすると結構精神的に…クることがある。精神的に非常に弱々しい私はすぐに小説の内容に影響を受け、また妄想を始めてしまうので、下手すると仕事に影響が出かねない。まぁこの1年間の限りでは、会社の最寄り駅を降りてからの徒歩5分でなんとか回復出来ているので案外大丈夫なのかもしれないけど。最近は溢れ出る思い(笑)をTweetすることで発散してたりもする。どうもすみません。
 あとは、満員電車で読みづらくないのかと言われたことがある。確かに読みやすい環境とは言えないけども、読めないことはない。左手で開いて目の前にもってきて読むというスタイルなので物理的な迷惑度は最小限に抑えられている。まぁ混雑度によっては「こんな満員で読みやがって」と思われることはあるかもしれないけど。ああ、この時の「小説の読み辛さ」によって体感混雑度を表すこともできる。それもいずれ書く満員電車エントリで書こうかな。
 また、そういう状況で読むわけなので本の大きさは文庫本程度に限る、という縛りが発生するのもまた弊害か?

 このような弊害がありつつも尚、通勤が楽しくなるというメリットは大きい。
 さらにメリットというか逆説的なのだけど、これによって読書の習慣が出来たともいえる。「いつでも読んでいい」となると結局読まずじまいということがあるが、「通勤の時は必ず本を読む」という縛りにまで発展している現状、定期的に通勤図書を買い求め彷徨う…つまり自然と積極的に読本を探す習慣がついてしまった。これをメリットととるかデメリットととるかはその人次第だけども、あまり読書家ではなかった(が、潜在的に本は読みたい)自分としては大きな大きなメリットだ。…とはいえ大部分はラノベを読んでいるのだけども。

 と、いうわけで。

 通勤図書まじおすすめ!
 乾きがちな通勤時間に潤いを!

 というお話でした。

 
コメントする

投稿者: : 2011/04/10 投稿先 雑記, 読書

 

タグ: , ,

思わず保存したもの

ポルべぇさん

                    ~~~~~~~~~~~~~~~~~~~~~~~
                    |             |\           /|
                    |              |\\       //|
                    |             :  ,> `´ ̄`´ < 
                    |     .        V            V 
                    |     .        i{●      ●  }i 
                    |            ./|__、_,_,___,ハ
                    |            /´fト、_{ル{,ィ'eラ , タ人
                    |          /'   ヾ|宀| {´,)⌒`/ |<  ヽ 
                    |         ,゙  / )ヽ iLレ  u' | | ヾl ハ 
                    |          |/_/  ハ !ニ⊇ '/:}  V:::::ヽ 
                    |         // 二二二7'T'' /u' __ /:::::::/`ヽ 
                    |        /'´r ー---ァ‐゙T´ '"´ /::::/-‐  \ 
                    |        / //   广¨´  /'   /:::::/´ ̄`ヽ ⌒ヽ 
                    ◯     ノ ' /  ノ:::::`ー-、___/::::://       ヽ  } 
                   O     _/`丶 /:::::::::::::::::::::::::: ̄`ー-{:::...       イ 
        |\           /|。 ~~~~~~~~~~~~~~~~~~~~~~~ 
        |\\       //| 
       :  ,> `´ ̄`´ <  ′
.       V            V 
.       i{ ●      ● }i
       八    、_,_,     八
.       / 个 . _  _ . 个 ',
   _/   il   ,'    '.  li  ',__

ってかWordPressでAAはるのすげー苦労する…くそう

 
コメントする

投稿者: : 2011/04/08 投稿先 AA, ネタ

 

タグ: , ,

私がきのこ派である5つの理由

【magelixirが恋人に求める条件】
 1位「動物が好き」
 2位「きのこ派かどうか」
 3位「責任感」
 4位「きのこ派かどうか」
 5位「それなりのエロさ」
http://shindanmaker.com/106395

 このような結果が出てしまったからには、きのこ派として語らざるをえない。

---

 正直なところ、きのこの山と、たけのこの…里?だっけ?の優劣という話はどうでも良かったりする。どっちもお菓子としては普通だよと思う。
 ただ、世の中が「きのこ派 vs たけのこの里」という抗争、いや戦争に明け暮れる中「いやいやみんな仲良くしようよ」といって流れ弾に当たって脳漿を撒き散らすキャラになるのはまっぴらであることと、その他諸々の理由から、断固きのこ派として行動することにしている。

 そういうことでその他諸々の理由を挙げる。

  1. そもそもキノコが大好きだから(大前提)
  2. 大抵のスレできのこ派が劣勢だから(判官贔屓)
  3. あの凹凸を舌で弄んで溶かすのが好きだから(食触感)
  4. 形が卑猥だから(猥褻物)
  5. 状態異常攻撃(をする方)が好きだから(嗜虐性)

 

1.そもそもキノコが大好きだから(大前提)

 これがほぼ全てであるような気がしなくもない。
 食べ物として好きであり、生物学的存在(菌類)としても好きであり、さらには物理学的にも興味深かったりするので、私は基本的にきのこ贔屓であったりする。

 

2.大抵のスレできのこ派が劣勢だから(判官贔屓)

 きのこ派が有利なスレも見たことある気がしなくもないので、都合の良いように記憶が捏造されているのかもしれない。 まぁそれだけ心情的きのこ派であるということである。

 

3.あの凹凸を舌で弄んで溶かすのが好きだから(食触感)

 お菓子としての優劣はどうでも良いと書いたな。あれは嘘だ。
 いや、決してお菓子としての優劣だけからきのこ派であるというわけではないのだが、やっぱりたけのこの里はフォルムがつまらない。きのこの山は舌先をあの凹み部分であれやこれやしたり、歯などを駆使して美しく傘の部分をパージしたり、という楽しみがあるのである。

 

4.形が卑猥だから(猥褻物)

 言うまでもない。まずこれだけで親近感がわくものである。
 たけのこ派の諸兄だってアレがたけのこ型という人はなかなか少なかろう。

 

5.状態異常攻撃(をする方)が好きだから(嗜虐性)

 これは実は2の判官贔屓に近いのだけど。
 まずたけのこの里から語るとすると、モデルである「筍」の特徴はその堅さと力強さである。民家の床など軽く突き破る力強さ。おそらく諸兄等の中にはそれに憧れるという方もいるだろう。しかしその属性は悪く言えば「脳筋」タイプ。
 対してきのこは様々な毒を持つ種がある。その状態異常のレパートリーは豊富だ。徐々にタイプを奪うもの(毒)、痺れを起こすもの(麻痺)、テンションがハイになって踊り出すもの(混乱)、逆にダウナー系(睡眠)、痛みを伴いやがて死に至るもの(毒、気絶、死の宣告、即死)、まぁ色々だ。ゲーム攻略では、ダメージリソースの最適化計算なども好きには好きだが、状態異常攻撃を駆使したり解析したりして勝利を得るのがたまらなく好きだったりする。麻痺や睡眠により何もできず、毒で徐々に死にゆく敵…というのは嗜虐性をくすぐるという面もある。
 が、主人公になりがちなのは脳筋であるたけのこタイプといえる。状態異常系が主人公になるのはあまり見ない…。しかしだからこそ、マイノリティ指向やら判官贔屓と重なって…ということである。

---

 ぶっちゃけ2~5は半ば冗談だと思うのだけど、5でこんなに語れるとは思わなかった。自分で思っているよりよっぽどキノコが好きなのかもしれない。

 ただまぁ言うまでもないことだが、きのこの山 vs たけのこの里 戦争というのはネタである。たけのこの里に対する罵詈雑言を吐いていたとしてもそれもネタの範疇である。気分を悪くされた方は、こんなネタが流布した世の中も一緒に恨んでください。

 異常。じゃなくて以上!

 
コメントする

投稿者: : 2011/04/05 投稿先 ネタ, 雑記

 

タグ: ,

ヘッダの背景

 このブログはWordPress.comのサービスによるものなので、サービスが提供する機能以上のことは出来ない。一定以上のカスタマイズを施す場合は、お金を払ってグレードアップするか、別サーバーを用意してWordPress.orgのソフトをインストールして自分で運用する必要がある。実は自鯖で運用することも考えたが、それは使い慣れてからでいいだろうということで現状である。

 で、外観に関して、Chocoというテーマを適用している。
 「細かい部分は自分でカスタマイズしよう、CSSカスタマイズくらいは出来るだろう。」とタカをくくっていたのだけど、なんと、出来なかった。カスタマイズしてプレビューするまでは無料でも出来るのだが、結果をブログに適用するのは有料サービスとのことである。しかし流石にお金を払うほど熱心にカスタマイズする段階でもない。

 ただ唯一やりたいことがあった。ブログヘッダに背景を入れたかった。

 仮にCSSが設定出来るのであれば、以下の指定でも加えてやれば良いと思う。

#header {
    background-image: url("背景画像URL");
}

 (早速ソースコード機能を使いたかったので敢えて書いてみたけど、書く必要なかったな)

 しかしまぁ、それが出来ないということで、苦肉の裏技を施すことにした。
 実は、現状のフリーサービス状態でも「ブログ全体の背景画像」は設定出来る(多分body要素の背景スタイルだろう)。そこで、「ブログヘッダの位置にうまく納まるように背景画像を設定してしまう作戦」をとることにした。

 CSSファイルを参照したところ、ページ本体のwightが980pxに設定されており、#headerには30pxのトップマージンが設定されており、heightは特に設定されいなかった。ということはブログヘッダのheightは、中の要素で可変してしまうのだが、幸いなことにfont-sizeは絶対サイズ指定なようで、内部に置くcontentの量を増やさない限りheightが変わってしまう恐れは少ないことがわかった。
 そういうわけで、ブログヘッダの高さはピクセル定規で実測(ほぼ60pxだった)し、それに都合の良いサイズの画像を作成して背景設定した。

 具体的には、幅980px : 高さ100pxのキャンバスで上部10pxを透過にしたPNG画像である。ブログヘッダの領域より広いが、まぁビジュアルの好みである。

 いやぁ、まさに力技。

 ただ当然だが、大きくずれる可能性がある。というか管理者としてログイン中にこのブログを見ると、ページ上部にバーが出る影響で早速そのバーの高さ分ずれる(笑)。まぁそのへんはご愛敬。

 
コメントする

投稿者: : 2011/04/03 投稿先 Web, WordPress

 

タグ: , ,

コミュニケーション問題 (1)

 原発問題の影響で、普段科学的な数値に親しまない人もそういった数字を目にし、論ずる機会が増えた。これは良いことなんだけども、前提知識があまりに不足している場合、必ず思わぬ齟齬が発生する。この問題は平時としては緩やかに解決に向かっていた(と思っていた)が、今回の非常時に於いて致命的に顕在化してしまったように思える。

 ということで、実は「数値の受け取り方」について語ろうかと思うのだけど、前提となるコミュニケーションと認識齟齬の問題に触れたら長くなってしまった。ま、以下の議論について自己言及的ではあるけども、当たり前のことをぐだぐだと確認しておくだけである。

---

 コミュニケーション論とか教育論の基礎だと思うのだけど「聞き手がどの程度の知識・理解を持っているのを前提にするか」というえらい大問題がある。この種の問題はその筋の専門家が語り尽くしてるはずだけど、一応自分の考えとして軽く触れておこうと思う。

---

 前提が異なれば会話は成立しない。よく専門家の話や記述に関して、
 「専門用語?が多くて何をいってるのかわからない」
という話がよくあるけども、専門家側も
 「どこからが専門用語と思われているのだろう?」
という悩みがある。

 当人にとって直観まで落ちてしまった知識に関して、その直観を差し引いた思考を行うのは簡単ではない。

 このコミュニケーション問題はどこでも発生する。一般の会話でもそうだし、専門家同士の会話でも発生する。違う分野の専門家なら尚更だし、同じ分野と見なせる専門家でもそうである。では人はどうやって会話を成立させるのか?少なくとも自分の場合は、
 「相手のバックグラウンドにあたりをつける。」
まぁほとんどの人がそうだろう。同時に聴き手も相手の言いたいことを理解しようと歩み寄る。

 ・バックグラウンドに一致点が多い
 ・あたりの付け方がうまい
 ・話す/聴く側の歩み寄り方がうまい

上記の条件により会話が(表面上)盛り上がる。専門家 vs 聴き手 の場合もバックグラウンドが近ければ近いほど通じやすい。遠ければ遠いほど困難が増える。同じ分野の専門家同士なら一言で済む表現が、用語を知らない人には説明が必要になってしまう。それを分かりやすく説明することはほぼ純粋にその専門家の能力だけど、説明義務はあるとは限らない(義務は状況にしか存在しない。責任は常に在る)。

 なぜなら全てを説明していたら話が進まないから。
 けれども全てを省略したら相手に伝わらない。

 結局コミュニケーション問題とは、その駆け引きの問題である(少なくとも現場直近の問題としては)。バックグラウンドが遠いほど駆け引きが難しく、駆け引きにミスが生じると齟齬が生じる。この恐れがあるために、聴き手に配慮しようとすると「説明を過剰にしてしまう」という現象が発生する。これは結構仕方がない。相手が多数いる場合、どのレベルのバックグラウンドを想定するかという問題が非常に重要になってくる。
 説明のしすぎに対しては「主旨と対象を明確にする」ことが一般的施策だが、どちらにしても、どうしても明確に出来ない場合も存在する。どうしても齟齬は発生してしまう。ただ、それはもう構造的なコミュニケーション問題といっても良い。

 はてさて。
 こと科学に関していえば、科学コミュニケータという専門家がいる。専門分化した科学技術要素を人にわかりやすく伝える専門家だ。この人たちがうまく機能すれば、先述の問題のほとんどは解決する。うまく機能さえすれば。

 科学コミュニケータの理想的なあり方がどういうものか、不勉強によりよく知らない。ただ少なくともコミュニケータが全ての情報を仲介できるわけではない。この原理的な問題と、構造的なコミュニケーション問題が解決されない限り、齟齬は発生し続ける。
 とはいえ、平時ではそれほど致命的問題ではなかった。

 …このような観点からしてみても今は結構な非常事態だという実感が沸く。

(続く…)

 
コメントする

投稿者: : 2011/04/03 投稿先 科学, 雑記

 

タグ: , , ,

ソースコード用タグ

どうも<code>タグでは微妙すぎるので検索して

http://en.support.wordpress.com/code/posting-source-code/

というものを見つけたので試してみる。


int hoge = hoge + 1;

(プレビューしてみて)
おお?これは素晴らしい!
ということでちょっとC#のコードをだらっと貼ってみる


        /// <summary>
        /// うんたらかんたら
        /// </summary>
        /// <param name="sender"></param>
        /// <param name="e"></param>
        private void jmkControlTabContextMenu_Click(object sender, RoutedEventArgs e)
        {
            //コンテキストメニューの起動元はタブアイテムである
            ContextMenu contextMenu = sender as ContextMenu;
            MenuItem clickedItem = e.Source as MenuItem;
            if (contextMenu == null || clickedItem == null)
            {
                //想定外の型から呼び出された場合は落とす
                Environment.Exit(CODE_ERROR);
            }

            switch (clickedItem.Name)
            {
                case "addJmkControlMenuItem":
                    addJmkController();
                    break;
                case "removeJmkControlMenuItem":
                    TabItem tabItem = contextMenu.PlacementTarget as TabItem;
                    if (tabItem == null)
                    {
                        //呼び出し元がおかしい場合
                        Environment.Exit(CODE_ERROR);
                    }
                    removeJmkController(tabItem);
                    break;
            }
        }

おおー
すばらしい。

これつかっていけばいいんですね。

 
コメントする

投稿者: : 2011/04/03 投稿先 プログラム

 

タグ: , ,

はじめました

またしてもブログを作ってしまった。

ちょっと色々テスト。

Read the rest of this entry »

 
1件のコメント

投稿者: : 2011/04/03 投稿先 Uncategorized

 

タグ:

Hello world!

Welcome to WordPress.com. This is your first post. Edit or delete it and start blogging!

 
1件のコメント

投稿者: : 2011/04/02 投稿先 Uncategorized