Macの統合開発環境XCode

XCodeを使っての開発環境について少しお話をします。
結論から言ってVisualStudioとはコンセプトが違うと思った。
そしてそれはあくまで定量的なものにはよらない。ただの推論。

基本的にWindowsは洗練とはかけ離れている。しかしそれが悪いという訳でない。
いくつもの選択肢から自らに適した方法を選びとることができる。
一方のMacは非常に洗練されている。しかしそれがいいという訳ではない。
ある特定の推奨される方法にとっては最適なものを提供するが、それに合致しないものには関与しない。
VisualStudioは基本的に何でもありの機能の見本市と化している。
一方のXCodeは非常に整ったあるやり方を提示している。
さてこのときにそのツールについて学習しやすいのはどちらでしょうか？
答えはVS。母体数の違いとさらにいうとその操作の選択肢の多さから多くの人がいろいろなところで情報をあげている。XCodeは母体数が少ないこととその操作の洗練されているが故にオフィシャルのもので十分であり、それ以外の情報があまりない。
XCodeでコードを組むことはそれなりに簡単である。しかしVisual Studioでならされた開発の癖を抜ききるのはなかなか難しい。むしろその違いに戸惑うばかりである。Edit Modeの見やすさはXCodeであるが、開発のしやすさに関しては、現状ではVSだ。クラスの生成の半自動化ができていないので、XCodeに若干不満がある。またライブラリの追加や、名前空間の宣言、開発環境に事前に登録しておきたい項目（Visual Studioで使っていたライブラリ）の登録方法がよくわからない。つまり道具としてXCodeになれていないので、その真価を評価しきれていない。

ただ初心者プログラマがMacで始めるのは正直どうなのかと思う。
かといってUNIX系のEmac？でいいのかは知らない。

C++の技術本を少々

買いました。
Exceptional C++―47のクイズ形式によるプログラム問題と解法 (C++ in‐Depth Series)
Accelerated C++―効率的なプログラミングのための新しい定跡 (C++ In Depth Series)
Modern C++ Design―ジェネリック・プログラミングおよびデザイン・パターンを利用するための究極のテンプレート
合計で７０００円超也
ちょいと本気で業務でC++使っていくなら、知っておくべきかと思って買ってみました。

"こんな本を読まなくてもC++ぐらい使えるようになる。"
ごもっともです。８割方もう趣味です。言語マニアですな。何度も言うけど、本当はC++よりもC#を愛しています。でも業務で使えないので、仕方なくC++をやっています、今は。まぁ使っていくと、それほど面倒でもなくなってきました。ですが、どうしてもC#の便利さに慣れているので、Propertyの存在やtry-catch-finallyの便利さが懐かしいです。あとは超強力リファクタリング機能。言語的な特性よりも開発環境からのサポートの強力さがC#Loveを推進しています。
現在はいまひとつ分かっていないC++のTemplate機能とSTL、Boostの使える機能。この二つをおさえれば、もう少し開発が楽になると思うので、前述の本を買いました。Boostの本は中古がなかったので、本屋で買おうと思っています。C#のほうはすでにオライリー本があるので、これ以上は買いませんが、いまだに効率的な例外処理クラスとカスタム属性がつかめていません。あとはラムダとヴァリアント。C#3.0を早いうちに慣れさせたいのですが、C#2.0ですら使わせてもらえないので、遅遅として進まないのが目下の問題です。

職業的ぷろぐらまー

先日、同期と一緒に食事に行った帰りに、本屋に寄った。
そのときに、プログラムの棚で楽しそうに本を選んでいたら、
「業務外でプログラムの勉強とかやる気しねーよ」と同期は言った。
まぁ、なんということはないごくごくありきたりの一言だ。業務外で勉強とか、働くとか、俺も嫌だ。なるべく避けたい。

私にはひとつ思うことがある…いや、いっぱいあるけど。
プログラムは経験と知識が物をいう。知らんものは書けないし、使えない技術じゃ意味がない。業務で楽をするために時間外で努力したり勉強をする。すべては楽をするために努力する。意味がちぐはぐかもしれないが、そういうものだ。全ては楽をするためだ。

楽をしているとたぶんもっとおもしろそうなことができるようになるし、くだらないことに関わらなくてもすむ。仕事の抽象度があがってくると余力が生まれてくると思う。

現在の仕事での評価の仕方が時間重視で計算されているので、それはとても大きな意味をもつ。仕事量が決まっていて、それに対して払われる金額が決まっていて、変数は時間しかない。このときに時間が短くなればなるほど、時間当たりの価値は上がる。より効率的労働しているということになる。企業としてはそれは望ましいことだし、時間給で労働力を購入しているので、効率的に労働してくれることによってより大きな儲けになる。ただこのときに、労働者は本当は逆に動きたいのだ。時間給であるが故に働き如何に関わらず給料は固定だ。なるべく労働しないようにするだろう。これは効率的に働くことへの動機付けがなされていないときには当たり前だろう。企業側はこの部分に対してより敏感になるべきだし、そのための動機付けを模索するべきだ。

個人的には基礎研究としての、ライブラリ構築やフレームワークの開発、チュートリアルやサンプルの充実がもっとも大きな効率を生むので、そういうことへの評価をしてもらいたいと思う。また環境的な面からもなるべく労働者が働きやすいように調整を行うべきだろう。あとは一度良質化した労働環境を下げることは、大きなマイナスを生む。通常ならそれは会社が傾いていることをあらわしているので、可能な限りそれはしないほうがいい。それまであったものがなくなることへの不満は予想以上に大きい。

話は戻るがライブラリの構築やまた基礎研究の整理は、長期的な目で見て、それらの情報を部分的にでも公開していくことは価値がある。現在ならHPへの掲載、あるいは書籍の発行である。勉強会を開くこともよいだろう。類似したことに関心のある人が集まるようになれば、それらの研究への価値が上がり、めぐりめぐって会社の価値が向上する。HPでの公開に関して言えば、サイトを利用する人から新たな情報の提供や提案がなされる可能性がある。直接的には金にはならないが、間接的に営業行為に結びつく可能性がある。なによりも名前を知ってもらえることは大きな意味がある。

HPの例でいえば、企業が情報を公開していることは、中小では稀である。しかしそこでしっかりとした情報が公開されていることは、稀であるが故にとても目につく。とても優位な広告活動である。しかも能動的なアクセスさせている点で、さらに情報の伝達率が高い。

事実、業務中もネットを通じて情報を集めることが多い。これらはすべて先人が情報をアクセス可能な状態にしてくれているからであり、この恩恵をただ受けているのでは、ただのROMでしかなく、それは道義的に下位の状態であると思う。

業務的にはライブラリの構築や調査内容を平易な書類にまとめることにも留意されているが、それによる評価の基準があいまいであるし、その情報を利用する範囲がわからない。また現在それらが使用可能な状態であるのか、それがどこにあるのかが不明確である。（なんでも訊けっていうけど、みんな忙しそうにしているから、訊けないですよ？）

さらにいうとどのライブラリの使用が推奨されているのか、またどのレベルでの開発が求められているのかを明確に示すことは、ある程度プログラムを組める人に対する指示としては妥当だと思われる。それは、そのレベルにあると思われう人は、自らライブラリを探してくるだろうし、プログラムを構築する際の選択肢も初心者に比べて多様になっていると思う。また真っ当なプログラマは「車輪の再発明」をしたくないものだ。つまりはなるべく公開されているフリーの外部ライブラリを使うとする。そのため、選択肢を制限するために、それらを指示することは妥当である。またその理由を説明することはプログラマにフラストレーションを溜めないために必要であると思う。「車輪の再発明」はなるべく避けたい。しかしそれが高速化、信頼性の向上である場合には、それは再発明ではなく、改良になる。これが重要である。再発明の強要ほど真っ当なプログラマを苦しめるものはないだろう。

話は戻るが、私は時間外でプログラムの勉強はよくする。それは楽をしたいがためだ。時間をかけて、くどくどしくプログラムをすることには何の意味も抱いていない。
可能なら楽をしたいし、可能ならプログラムを組みたくない。可能なら、１００行以下で求められていることを終わらせたい。

労働時間が長くなるのは、嫌だ。それが雇われであるなら当然。労働力を売っているんだから、供給したくないときだってある。それを選択できるか、できないかは別の問題。買い手がつかないときもあるし、つくときもある。雇用主との間に、持っている情報や資金的な面での不平等はあるが、契約に関して一方的に買い叩かれる謂れなどない。そしてそれを主張するためには非常に効率的に仕事をこなすことが必要だ。相手に「ここしかない」と思わせることは、商業的には下策だ。特にこちらから売り込まなければならないときには。無限に買い叩かれる可能性がある。それは本当に最低な営業活動だ。

それで結局何がいいたかったのか。
要はオレは業務で楽をするってこと。あとは買い叩かれたくないので、若干駆け引きするよ！ってこと。

DICOM覚書

DICOMというメディア規格について。

1. 規格の書物の１，３，５，６，１４で画像をうまく復元できるようになると思う。
2. １は概括、３はオブジェクトの説明、５はデータ構造、６は定義集、１４はGrayScaleの色調補正。
3. 浜松医科大学は生家のある都市だが、DICOMの情報が一番整っていた。やるな、浜松
4. ビットデータをどうしても8bitにしなければいけないので、さまざまなフィルタが必要である。
5. GrayScaleはどうしても黒に対する人間の目の感応力が低いので、黒よりも白でより多くの諧調を表現すようなトーンカーブをつくる。
6. ほかの画像に関してもガンマ補正が必要
7. DICOMはもともとは通信の規格から発展しているので、画像関係のところは散乱している。１、を参考にされたし
8. １がMin白、２がMin黒、GrayScaleの話

まぁ仕事が回ってくるのは良いが、せめて業務の範囲を明白にしてください。最後までやるならやるでもっと設計と解析に時間をかけたいです。というか、先にDICOMの規格の書物を全部日本語に訳さないとあとあと二度手間、三度手間だけど、それをして良いのかも、訊かないと分からないのもなんだかなぁ…さらに重要な、業務の期日も明白にして。

話は変わるけど、オブジェクト指向プログラム環境下でGetValueというメソッドで個別の変数を返す処理をしたいとする時に、引数と戻り値をどうするのがもっとも効率的か分からない。特にC++にはクラスに型タイプがない…１つ考えたのは、型の列挙型：eType
eType getValue(void *dst , unsigned long *size);

このように関数を作れば、値をつめたものとそのサイズ、自分で設定した識別子が手に入るのだが…仮にこの引数などは結局はポインタで参照しているデータのアドレスとそのデータのサイズが一緒になっていれば、１つの引数で終わるのだ。さらに言えば、識別子も入れるなら、getできるか出来ないかということまで記述できる。

ただこれだとまったくポリモじゃない。たぶんswitch文で大量に分岐するのが目に見えている。それはそれで面倒です。

さらに話は変わって、C/C++でもっとも信頼できるライブラリって何？そしてライブラリの信頼性の評価/テストってどうなってんの？Boost　C++ をいれてみたいけど、導入がよくわからんｗドキュメントを早く読んで使ってみるお。はじめからスタティックライブラリつけてくれてもいいのに…。

Fast Light Tool Kit

Fast Light Tool Kitの初心者のためのチュートリアルを少し見た。
これはWindowsの.NETのFormの作り方によく似た感じを覚える。
クラスをインスタンス化して、Begin()-End()の間でコントロールを設置している。そのあとでShow()、表示させて、Run()でメッセージループの開始をしている。このWindowのクラスの抽象度はとてもいいと思う。惜しむらくはBeginとEndに目的語に当たるものをちゃんと設定してほしかった。あるいはUnlock-Lockといった対になることとその間だけでなにかが許可されていることを表す関数名がよかった。
この抽象度は.NETのFormも同じぐらいだ。これは、C#のFormの動きをみればよく分かる。どちらが先とか言うことではなくて、この設計思想はたとえばボタンをすぐに乗っければいいと思う人にとっては、Begin()-End()のロック機構がまどろっこしいだろうし、呪文にしては、Begin－Endは上記の理由で不適切だと思う。
ぱっと見た感じだけど、よく考えられていると思う。そしてなにより扱いやすそうだ。抽象度が適当だと思う。このライブラリは更新も割りと頻繁に行われているようなので、当分はいけるのかな。日本語の解説サイトがないことがもしかしたら普及が遅い理由なのかもしれない。あるいはFLTKがクロスが不十分か、Macが非対応か？
そしてクロスプラットフォームにそれほどこだわるのはなぜか？実行形式にされないと結局はどの環境でも使えないし、そもそもパフォーマンスをあげるのは、やはりオーダーメイドで、仮想レイヤーが少ない場合だろう。この流れでいうと、Windowsのみで、クロスプラットフォームサポートを捨てた日本製のToolKitの開発というのも意外とアリなのかもしれない。解説サイトが日本語は当たり前だ。でも技術的な知識の蓄積は見込めないし、コードの修正、改造なども頻繁とは行かないだろう。海外のユーザーがつかわないと技術的な情報の蓄積が見込めない（母体数と能動的参加者の明白な差）ので、海外の技術者コミュニティにコミットしたものがいいだろう。それでいうとGLUTとFLTKはいいのだろう・・・
あとは映像製作用に特化した細分化された巨大なライブラリ群かな…
細分化された巨大なライブラリというのは、必要に応じて、使うライブラリを減らせるということでファイルサイズに制約がある場合に対応できて、なおかつ製作中は多くのライブラリでサポートすることによって撮影を簡便にすることだ。・・・え、既存のライブラリを集めればいいって？そりゃそうだ。
さらにさらにいうとライブラリの信頼性については、各々が確認してから使うしかないのがつらい。ライブラリの信頼性はアプリケーションの信頼性だし、もろもろのソースコードにまつわる問題と一蓮托生だ。とりあえず自分でWindowsのFormをC++ベースで抽象化してみる。・・・本当はC#が好きです。

最近のGLUTってどうなの？

• 最近、OpenGLの補助ライブラリ、GLUTってどうなのだろう。

現役なのだろうか？僕にはこれは使いづらい。カメラアングルのテストとかのためにマウスを最大限生かそうと思うと、このインタフェイスは不十分だ。それに日本語訳されたAPIリファレンスはLast Update 2001って何？７年も更新がないっていうのは、完成されたのか、破棄されたのか、どちらでしょうか？７年という時間はコンピュータの世界でレガシーになるには十分な気がします。とりあえずクロスプラットフォームのためのGUIサポートの関係上どうしてもMouseWheelを組み込めないのかもしれませんがいまどきWheelのないマウスが逆に少ない。それにWindowsに特化したOpenGLの補助ライブラリっていうのも必要な気がします。でもそれはGLUTの範囲を逸脱するのだとも思う。

とりあえず目に付いたのは、http://ja.wikipedia.org/wiki/FLTK
FLTKがクロスプラットフォームの補助ライブラリなのですが、正直これに関してはまた使用してみていないので、謎です。

それほど大きな仕組みを必要としていないので、カメラのクラス、関数や行列計算関数のライブラリとGUIの制御のライブラリ、画像処理ライブラリの組み合わせがいいなぁ…必要最低限の分をくみ上げるのにはちょいと時間がかかりすぎるので、周辺の情報をかき集めて、回答を探してみる。
とりあえず自前でBITMAPを扱える程度の能力とバイナリファイルの解析をするだけの忍耐が出来たので、画像のほうはいざとなれば、どうにでもできる。

• OpenGLをなぜ今やりだすのか、ということ。
  

単純に大学時代の先輩がなにかやるぞという動きを見せたときに、少しでも助けになるようにという軽い気持ちで。大学時代に先輩がDEMOをつくっているのをみたときから、プログラマの世界はずっと自分には遠い世界だと思っていた。その世界を自分は結局選んだ。だから、その世界の１つの到達点であるDEMO製作をやってみたいとはずっと思っていた。
きっと日本でのはじめての海外勢を呼んでのPatryには間に合わないけど、その領域に近づきたいから、がんばってみよう。会社のほうはまだ残業代もつかないし、定時で帰れるし。。ｗ

再帰処理を封印

今日先輩に「再帰処理」はメモリリークやDEBUGの困難さからどうしても駄目なときの最終手段だよっていわれました。個人的には再帰はとても合理的な選択だと思います。入れ子式のデータ構造を解析するときに深さが不明なのときには再帰処理が最適だと思います。というか、最近は再帰以外で考えるのが、若干難しいです(汗　forで代替する方法がわかりません。

あとクラスを使うことによってコードを簡単にすることを提案されました。これは合理的な判断だと思います。個人的にC++でクラスを書くのが嫌いです。C#と比してです。CベースでやるならUnionをつかってそれを構造体に型を特定する方法を含めて作れば、便利かも。とりあえずC++でクラスを表記するのが面倒。あと継承しているのにOverrideしないとVSのIntellisenceから消えるのが最低。C++もメソッドをマクロで作ってくれたり、クラスのメンバを追加してくれるならとっても楽チンで別にC++でもいいのです。できればクラスを書くのが簡単になったり、VC++でPrivateな変数をそれをHeaderから参照しているときには隠してほしいと思いました。アクセスさせそうになっていかん。

あと今日から電話を取るようになったけど、耳が悪いので、聞き取れないので気分が最低です。さらに「いつかかってくるかわからない感」が開発への集中度を下げます。とってもいかんです。電話は嫌いです。メールでお願いします。聞き逃しと伝達ミスが少ないので、私はメールを推奨します。特急の電話の時にはやりようがないですけれど、そんな状況になる前に問題解決させたいです。

とりあえず電話は文明の利器の中でもっとも嫌いです。次が核兵器です。
電話など消えてしまえ！

OpenGLが正しく動かない

GLUTをつかって描画を表示させようとしているのだが、Windowの表示の更新が死んでいる。またMessageLoopがおかしい。

それと気づいたが、GLUTで作られたWindowから正しく脱出する方法がない。

exit(0)で脱出しているときには、生成したWindowのハンドルが開放されていない気がする。

あとはWinAPIとの絡みで全般的にMouseWheelは使えない。これは.netでもいえるので、仕方ないかもしれないが、３Dでチルトホイルが使えないのは最低だ。Zoomがない。

GLUT自体のWindows配布版はいい加減VC6++はやめてほしい。

なんだかしらんが、すげー勢いでCPUを占拠して、活動がままならなくなった。

慣れもあるけど、GLを特にオススメする理由が見当たらない。

GLそのものを使うのがいいと思うが、それでは機械的なレベルすぎて、しんどい。でもGLUTの抽象度でここまで扱いにくいと正直もっとつらい。インターフェイスに関しては、必要じゃないものが省かれているけれど、正直サンプルをみて、リファレンスもみてじゃないとぜんぜん扱えない。というか、サンプルが動かないとか、致命的。

DEMOというあり方

• 大学時代の先輩がBreakPoint 2009に参加した。

System KのKioku氏、crv氏、sincl氏は先輩である。
http://www.sys-k.net/
チームサイト
http://kioku.sys-k.net/
kioku氏の個人ブログ

kioku氏のブログに「日本でPartyをやらないのか？」ということを聞かれた話が出ていた。
面白いと思う。ほんとうに面白いと思うけれど、
「それに自分は参加できるだけの力量があるのか？」と
考えるなら躊躇せざるを得ない。力量が今はないからだ。
ということで、すこしずつOpenGLを再度確認しようと思った。

ちなみに
http://www.siggraph.org/asia2009/jp/
SIGGRAPH ASIS 2009　は
日本の横浜で行われる。
これにあわせて、もしもPartyができるならさらに面白いと思う。

• SystemKの作品を見た感想

ここから先は失礼を承知で書く。コードを作る大変さや映像を作る大変を実際の１厘も分かっていないけど、観客としてみたことを書く。
その作品を見た。
僕は導入部分が好きだ。ありがちな無機的な映像だけど、あの映像とあの映像にかかっているエフェクトが好きだ。奥に引きずりこまれていく感覚と時計の表現から、流転するものを表現するのかと感じた。
しかし後半のモデルが乱立しているあたりでなんとなく映像に停滞を感じた。それも意図している停滞ではない停滞を。なんとなく映像が息切れしていると思った。
葉っぱから落ちる水滴の表現も個人的にはサンプルがそのままのような印象を受けた。実際の水のように落下する水滴の表面に下から上へ波が伝播するを期待していたが、それがなかった。当然くると思っていた波紋の表現がなかった。
全体的に前半のエフェクト部分と後半のモデルの部分でちぐはぐな感じを受けた。前半の表現の感覚を続けていくなら、後半のモデル部分では最低でも人間は必要がないと思った。

期待が大きかっただけになんだかもどかしかった。

DICOM

DICOMという医療用のTag付Media形式規格がある。

これがめちゃめちゃ巨大な規格である。

基本的にはTag+Value(s)みたいな形式のデータ構造。

Tag部分は、Keyデータに当たる部分があり、それぞれ規格によって決められた意味を持ったものと独自のタグが含まれている。

たとえば

GroupNum(2byte)|ElementNum(2byte)｜Keyword(2byte)｜（reserved）(2byte)｜DataLength（2/4byte）｜DataValue(DataLength)

という形式のデータがずっと並んでいる。

DataValueの中にふたたびTag+Valueみたいな形式のデータが入る、入れ子構造にもなっている。

人間の可読性は限りなく低い。機械に優しいわけでもなさそうです。

ただ汎用性の面では機械にレベルが近いので、優秀そうです。いまならXMLで構築されていそうです。

これが格納できる画像もしくは動画の形式はオーソドックス（JPG,PNG.RLE、MPGE）なものばかりですが、その格納方法もとい圧縮方法がいまいち分かりにくい。というか、最新の規格書は英語もので、PDFファイルもDeadLinkあるいはそもそも配布禁止っぽいもの。

でもこの規格自体の需要はあるので、OpenSourceでいろいろ公開されています。それはぐぐればいろいろ出てきます。

ただ本当に規格の文章を読むのなら、３，５，６でとりあえずはファイルの内容を読むことが出来るようになります。特に６の文章にはタグのデータの定義集がついているので、必須。５は圧縮されたデータについての情報。３は基本的なDICOMの話がある。もし画像をやるなら５，６は本当に必須。

でもこの５，６の文章が英語でもあまり判明ではない。またそれぞれの数値の実際的な使い方についての記述が少なく、規格からそれを実装するまでの溝が結構ある。

また規格自体が超巨大といってもいいので、それら全てを網羅したものを作れば、普通に販売が出来ます。というか、売っているところがあります。もっともタグに独自にデータを割り振れるところがあるので、完全に解析できることはなさそうですが、互換性がそこで完全ではない分、オーダーメイドの部分をもったソフト販売も夢じゃないですね。もっともそんなところとお付き合いのある会社に雇われていなきゃこんな規格みないでしょうけど…

仕様にしたがってファイル読み込みを作る練習にって思っているなら、やめたほうがいいですね。そもそもこの形式のファイルが手に入らない…ｗ一般的に流布しているファイル形式じゃないところが良いのでしょうけど…ちなみにIrfanViewではみられます。

車輪の再発明

題名は昔どこかのサイトで誰かが言ったすばらしい台詞。

意味としては、すでにあるものを再び発明するために労力を使うなんて馬鹿らしい、という意味だと思う。決して、再発明することによってそれを発明した人の経験を追体験できてすばらしいという意味ではないと思う。

なぜこのことを言うのか。今現在の世界ではあらゆるところで発明が日夜起きている。それの情報にどれだけ多くの人がアクセスすることができるのか、という観点をおいておいて、その発明を新たに知ることはそれを再発明する労力よりは割と軽微だと思う。もっともそれはよく訓練された検索エンジンが動いているからであり、ただその恩恵に対しては十分ありがたいと思うが、それが一般化されてしまうと忘れがちです。

話を元に戻すと、今度はアクセスの問題で、秘匿されている知識、発明はありますが、インターネット網で整備された巨大な図書館の存在は、それが存在していなかった時代に比べて、はるかに知識を手に入れることが容易になりました。またプログラムにおいては肝となる実装部分は本来は秘匿されていて、またあるいは高額な書籍の中に印刷されていました。ここにきて、オープンソースの話をするのですが、彼らは何のためにそれらをアクセス可能な形で残すのか。この動機付けに関して、商業に長く身を置いている人は、アクセス可能であることのありがたさを感じていながら、自身で身に着けた技術を隠すことが多いです。まぁそれで食っているのに、わざわざ手のうちをさらすまでもないのですが。

正直なところ、私もソースコードを公開する動機付けで１つだけいえるとすれば、「前に公開されている情報によって助けられたから」ということしかありません。言うなれば、「情けは人のためならず」ですな。特にプログラミングなんてほとんどどっかの誰かのコピペみたいなソースコードや誰かの提唱した考え方、アルゴリズムをふんだんに使って作っているのに、いまさら自分だけは秘密っていうのも･･･

まぁ、１つだけ大きな公開を躊躇させる懸念事項は、ソースコードの品質。ソースコードにも綺麗と汚いが存在するので、汚いソースコードを出したくないってことです。また誰かに再利用されるときに責任問題があったり、またその利用条件によって使えなかったりいろいろです。ソースコードは基本的に責任取らんから、好きに使って良いけど、「自分のものって言うなよ」って権利がいいのですが、ソースコードの独自性をどこまで認めるのかという問題が出てくると、改変禁止が一番分かりやすくて、でもそれは変えられ場合には誰の権利になるのかということが問題になります。

哲学で言うと、なんたかの舟という問題で、代替可能なもので作られたAを統一体としてのAとして認識させているものは何かって問題です。オリジナルや自己というものの本質を問う題目である。

それで再発明した場合には、発明しているのにすでに誰かのものっていうことで、全ての苦労が水の泡。権利問題もあるけど、なるべくならすでに発明されているものを利用してそれから先に行こうよって言うのが、私の基本スタンス。だってすでにあることを知ったときの脱力感が嫌いなんです。

いくつかの不満

どうしてもこれだけは許容できない点が私には存在します。
それは、とても主観的な問題で一般化できず、また特定の手順によって確認できるものでもないのです。

1. 浪費ばかりをし続ける人
2. 努力しない人
3. 口だけの人
4. 今だけしかない人

これらはただこのように並べられていると、どれも例外が存在しています。１．に関しても、資産をもってそれを食い潰している人は、まぁ許容できますが、２.該当するならば許容しがたいです。しかし、私は努力をむやみに礼賛する気もさらさらないのです。努力という言葉はその言葉にすでに善性を表す意味合いが含まれていますが、個人的にはこの努力というのは覚悟をもった労働であり、これによって如何なる結果が導かれても自己への内省を生むようなものをさします。そうでないと、努力であれば全てにおいて許されることになってしまいます。３．の口だけの人は結局は覚悟がないという点で２.と複合的に許しがたい行動をとることが多いので、いやです。４．の今のみに生きているというのも、確かに極限状態で事象の大まかな見通しすら立たないのであれば、それについては問えませんが、私が問題にしたい場合は十分予見可能な範囲のことすらも考慮に入れない人です。これを仮に確かめるならば、説明をしてもらえばいいのです。なぜそうするのか。

大抵の許容しがたさの根本には、自己への無理解であると思います。自己への理解、自己の行動原理の確度。内向きの検討であるけれど、それの題目は将来や外の事象に向けられていることをしっかりしている人を私は評価していますし、そのように私自身なるべきであると思っています。これらを多くなしている人のことは私は尊敬しますし、より少ない人でもこの志向性を持っている人へは敬意を払います。これらの志向性が欠如している人こそ、私がもっとも嫌うものであり、度し難いと思います。

もっとも簡単にたとえると、寄生虫はすべからく排除したい。

童話でたとえるなら、「アリとキリギリス」でのキリギリスは厳冬の雪の中で、アリに頼るようなら死すべきであり、その中でもキリギリスとして生き続けようと覚悟を決めるならば、わずかに助けるべきであろう、ということである。

考えて生きていくことをあきらめた人は、積極的に排除したいです。考えた末に死にたいと願う人にはわずかな憐憫を覚えますが、私は８割もったいないと思います。その覚悟をもって、ことにあたれば本当に困難なことなどないはずですから。死は根本的な無へいたった状態と考えるから、死への志向は生の逆であり、落下速度に近いエネルギーだと思うのです。そのエネルギーで問題を突破できるなら生きれば良いし、突破できなくても本来の覚悟へは至れるから、ただ死ぬことを選ぶことは、本当にもったいないと思う。

「必要とされていないから死ぬ」という人は、考え違いを起こしていると思っています。問題の局地は、他人が先に発生するのか、自己が発生するのが先か、です。「社会的に必要とされていないから死ぬ」という意味で死ぬならば、その前提とされている社会を変えることを考えられないことが哀れみを誘う。そして必要とされるようなことをしてこなかった、あるいはしていないのに、それを望むならそれはないものねだりであり、赤子である。してきて、今はなくなってしまったのなら、次の必要とされることをすればいい。「他人に必要とされる自分」でしか自分を保てないなら、それを満たすようにするか、そもそもの「他人に必要とされる自分」は人格的に壊して、別の人格を作り直すしかない。これを「死」とみられるならば、それでいい。なにもせっかく生きようとしている「身体」まで殺してしまうことはない。ハード的な「身体」はまだ使えるのだから、ソフト的な「人格」を再インストールするか、リカバリするしかない。ソフトの複製が確立されていないので、論理的に身体は根本的な自己といえるかもしれない。これは経年劣化や外的衝撃で破壊されてしまうまで使えばいい。

そして、やはりいいたいのは、どう行きたいのかを明確に自分にだけは説明できるようにしておいてほしい。そうでないと見苦しいし、救いようがない。芯になるものがないとざるにもかからない。本当の意味ですくいようがないｗ

AssertとException

アサートとエクセプション

ついさっき、AssertとExceptionの違いを理解した。

端的にいって

1. AssertはDeveloperのためのもの。
2. ExceptionはUserとDeveloperのためのもの。

Assertは前からその存在を知っていたのだが、うまく使い方が分からずにずっと放置していた。

とりあえず自分で考えた使い方のルールを備忘録。

1. Publicなメソッドの中での引数のエラーなどは、Exceptionで処理するか、もしくはそのまま情報を追加してThrowする。
2. Privateなメソッドの中での引数のエラーなどは、基本的に開発者に責任があるので、それはAssertで警告する。
3. ProtectedなメソッドでVirtualでないものは基本的にAssert、それ以外はException。
4. DLLなどの形のときに外部から使われるものは、基本的にはThrowする。それ以外は開発者のみが知ればいい情報なので、それらはAssertで処理する。

例外処理が万能すぎるからついつい多用してしまうので基本的にはこのルールでいいと思う。Trace…に関しては別の話でｗ。

あと問題だと思うのは、Exceptionでしか捕捉できないもので、なおかつAssertしたほうがいいものがあるけど、これはどうするのか…それとそもそも予期できないエラーはすべてExceptionに飛んでいくのはどうなのだろう…。プログラムの設計の仕方が悪いのかもしれない。

安全で、効率的なコーディングを目指してT&Eしかないのか…

就職した

1つ、意外と休みが多いこと。
2つ、8時間(9時間)の拘束って意外と苦痛。
3つ、新人だから気を使いすぎて倒れそう。

あとは地味に飲食と音楽聴くのがダメなのがきつい。
普通なのだと思うけれど、きつい。

休みが多いなぁと思った。実家で手伝いをしている感覚だと、拘束時間はゆるく長くて、なおかつ土日はない。休日はむしろ仕事って感じだったから、平日しか仕事がないことが不思議。
普通の会社は拘束時間は割りと長めでみっちりしてる。そしてCRTのモニタの前に8時間はつらいです。目が痛いです。

さらに一応、それなりにプログラミングをしていたので、会社では『期待の新人』らしい。とてもじゃないが、気を使いまくって倒れます。どの面下げて「できる」と言え、と。

･･･あと環境を設定させたいのなら、Officeとかは一番に入れさせて下さい。勤怠表が書けませんｗ

仕事が終わって帰宅して3時間ぐらいは時間が取れるので、意外と勉強とかできそうです。（今はまだｗ