色彩設計と衣裳

アニメ作品において、キャラデザインの衣装は、原作ありのものはそれを踏襲、オリジナル衣装の場合は、アニメーターが考えてデザインします。

まあ、明らかに限界がありますよネ。アニメーターは、まさにアニメーターであって、衣装デザイナーやコーディネーターでは無いですから。どんなに頑張ったって、衣裳に関わっている時間の差が表れちゃいますよネ。

私は画面作りの初段階でイメージを作る事が多いですが、「キャラと衣裳が、情景を呼び寄せる」方法論も多いにアリ、だと感じます。違う言い方をすれば、衣裳を纏ったキャラクターが、存在感を放射する‥‥とでも言うか。

現在のアニメ制作は、実制作に入ると、「線画ありき」「背景合わせ」の色彩がほとんどで、キャラと衣裳、その色彩がシーン・カットの中心的存在になる事は、ほぼ皆無と言っても良いでしょう。例え、プリプロのキャラ基本色の設計で、精彩な色彩を施したとしても、実際のシーン・カットで巧く扱われなければ、威力は半減してしまいます。「巧く」あるためには、背景にキャラの色を合わせるだけでなく、キャラを中心にして背景が色を合わせるベクトルだって必要です。今のアニメ制作だと、必ず「背景が先手」ですよネ。

私は白いキャンバスから完成に至るまでを描く事も多いので、「線画ありき」「色彩は後で考える」的なアプローチでは得られない、キャラの存在感が画面を圧倒する類いの絵作りも存在する事を承知しております。「キャラの表情、衣裳の色彩」がまず強烈に思い浮かび、背景や線画の処理はその後に招集される‥‥といった具合です。

ただ、その方法論は、実際に現場でやろうとすると、現在の作業システム上で無理が生じますし、何よりも、スタッフが見当たらなくて実現できません。まあ、それは当然。そんな役割など、今まで無かったのですから。

おしゃれな服をチョイスして集めれば良いという訳では、全くないのです。いわゆる、観るものの眼球を通して、脳に刻印するかのごとくの、完全にイメージされた衣裳が欲しいのです。それを表現できるスタッフが欲しい。

私は近い将来、色彩設計というペイント行程で色を決める人が、その役職を兼任してくれたら良いな‥‥と前々から考えています。もちろん、アニメのペイントの知識は必要ですが、それ以上に衣裳の知識、デザイン能力も兼ね備えて欲しいのです。なぜ、ペイント行程の色彩設計さんが?‥‥というのは、ペイント上の限界や作業時間を「読める」からです。実写のままではなく、ペイント・CGという枠組みの知識を踏まえた、衣裳デザインが必要なのです。

まあ、今のアニメ業界のシステムでは、行程的にも予算的にもNGでしょう。ですから、今は単に「夢想」の段階です。

でもね‥‥、アニメ業界ズレした視野でなく、ごく普通に映像作り、作品作りを考えるならば、卓越した衣裳はどうしても必要ですヨ。

以前、北村道子さんと仕事をご一緒した事がありますが、‥‥あんな人が居てくれたら、どんなに作品は豊かで鋭くなる事か。

最初と最後

私はコンポジットの作業者として、各種素材を合成して映像を組み上げる作業を、数多くこなしてきました。また、ビジュアルエフェクトとして、通常のアニメの撮影とは異なったニュアンスの映像を作る役職も長く請け負ってきました。

最後の最後で、「ミラクルな何かを期待される」のは、まあ、ありがちな話です。特効薬としてのビジュアルエフェクト、です。しかし、病人が薬ひとつで快活なスポーツマンのような健康体になるわけも無し。人々の心を振り向かせる映像は、最後の特効薬では成し得ません。

「最後」だけでなく、「最初」もとても重要なのです。この点がよく解ってくれている人は、作品の絵作りの始まりで、声をかけてくれます。つまり、「からくり」を解っているからです。

マジックにはちゃんと仕掛けがあって、大掛かりなものほど、手の込んだ仕掛けとなります。イメージボードという作業は、「からくり」「仕掛け」を仕込む、重要な作業です。

でもまあ、イメージボードと言っても、その捉え方は多種多様で、いわゆる「気分だけ」「気休め」のイメージボードも存在します。描いてはみたものの、あまり役に立たない類いのイメージボードです。

私が重要な要素として捉えるイメージボードは、そのシーン・カットの「マイルストーン」となる役割のものです。もっと強く言うならば、映像が流されないように「くさびを打ち込む」役割、でしょうか。「こんな絵を作ろう」などと言った気分的なものではなく、あからさまに「仕掛けに行く」内容のものです。いわば「時計塔の歯車の構成」を示すレベルにイメージボードが初段で機能しないと、からくりは成立しないのです。

最初と最後を押さえると、多少の出来不出来の上下はあれ、「からくり」は作品に作用し、作風を形成していきます。まるで水路に導かれる水のごとく、映像が意図したベクトルへと進み始めるのです。

これは去年やった作品でも強く実感できた事で、正直、自分でもその効果に(今更ながら)驚きました。美術監督と共同でイメージボードを作る事で土台が強く形成され、その後のプロダクション作業においてあまりイメージボードが持ち出されなくとも、「くさび」として潜在的に作用したのです。もちろん、フィニッシュのAfter Effectsでは、既に「計算ずく」の作業が可能だったのは、言うまでもありません。もしイメージボードで最初にくさびを打ち込んでおかなかったら、作風はどんどん中庸なものへと流されていった事でしょう。

アニメ制作は、絵を作る作業が複数人数で分断されます。ゆえに、全体として「絵を描きあげる」感覚が希薄で、個々の作業者は「絵のパーツを作っている」感覚が支配的になります。

通常、絵を描く間は、絵全体を見渡し、行程を最初から最後まで、考えながら絵を描きます。絵をイメージする人間、下書きを描く人間、色を塗る人間、最終的に仕上げる人間は、同一人物です。ゆえに、からくりが全部見える‥‥というか、からくり構造がリアルに手中にあり、構想から実働、制御までを1人でおこないます。

アニメは1人では作れないので、作業分担する事になりますが、「結局、絵がどのようになるか、誰も解っていない」状態で作業が進み、最後のおとしまえを撮影・ビジュアルエフェクトがつける‥‥というのが、「よくある」話です。しかし、そんな後手の手法、何となくやっつけちゃう方法では、絵の「求心力」は一定のレベルで頭打ちになりますし、何よりも「やっつけた感」が画面から滲みだします。

これは例えるなら、旅行で、やりたい事だけを列挙して、目的地を決めないで、出発するようなものです。‥‥で、なんとなく車を走らせて、行き着いた場所で、「やりたい事に沿うように現地調達する」のです。

あてど無い気ままな一人旅‥‥なら良いですが、大所帯で金もかかる旅行で、行き先を決めずに方角だけ決めて出発するなんて、現実世界では誰もが「そんな事しないよ、普通」と言うでしょう。

最後に「やっつける」ばかりでなく、最初に「期待する結果の通りに、からくりを仕込む」事は、一定レベル以上の作品を造るためには、必須の事なのです。

イメージボード、画面設計って、潜在的に作用するものなので、作品制作が終了すると、その「効能」をほとんどの人が忘れ去ります。「影のファクター」とも言うべきイメージボード関連の作業は顧みられません。

素材だけ渡されて、「あの作品のように」と言われても、同じになるわけがない。まあ、腕試しと思って作業はしますが、事前の仕込みとからくりなしでは、「派手な一発芸」にしかならんのです。

アンドロメダ人気

最近、1980年頃のヤマトのプラモデルが再販されて、買ってもしょうがないな〜とか思いつつも、買ってしまいました。100円で売っていたシリーズで、今は210円で売ってます。子供の頃の記憶が疼くのでしょうか。

今、「さらばヤマト」を見返すと、中々にパンチが効いてて、見てて「ん〜?!」となる事も度々です。また、記憶ではインパクトの強い印象だった宇宙戦艦群も、実際の登場カット数はそれほどでもなく、子供心に随分「増強・補完」して見てたんだなぁ‥‥と思います。ビデオなんて無かった時代なので、映画館で1度きり見て、ずっと忘れないように反復しているうちに、どんどん「出来上がっていった」のでしょうネ。

作画・撮影なんかも、スケジュールが無かったのでしょうか、随分アラが目立ちますが、反面、今では3Dにしちゃうような大変な作画をこなしており、撮影でも奇麗なシーンがいくつもあります。テレサの洞窟のシーンは、透過光が画面作りの根本を成しており、白・黄色・グリーンの奇麗なグラデーションと軟調フィルタが、まさに神秘的な女性像を体現しています。同シーンの古代くんや真田さん(地上の人物)の色は、透過光のフレアが乗る事で微妙な色調を醸し出しております。「こういうシチュエーションのシーン、いつかやってみたいな」と感じましたネ。

子供時代、アンドロメダ(地球側の旗艦)は異様な人気を誇っており、みなでアンドロメダを描いたものです。あの複雑なディテールゆえ、上手く描けた子は一躍人気者になったほどです。

で、現代。いまでもアンドロメダは人気があるようで、ちまたにはプラモデルの作例がいっぱいあります。大型のアンドロメダも再販されておりますし、メカコレクションの小さいアンドロメダも再販されています。

大型のアンドロメダのほうは、ちょっとムックリした造形で、スマートな印象が消えているのが、ちょっと残念。発売当時、小学生だった私が、「こんなズングリしたのだったら、いいや」と、買えない事の理由付けにしていたのを、ふと思い出しました。

アンドロメダのデザインは、カラー的には、当時のアメリカ海軍のガルグレー&レドーム色と同じ、明るい配色です。また、2連の角張った波動砲のデザインは、どこか当時の最新鋭機F-14,F-15の二次元型エアインテークを想起させ、先進の「強いアメリカ」的な雰囲気を感じます。

ヤマトがそれこそ大和・武蔵だとしたら、アンドロメダはどこかアイオワ級的な直線ばったデザインで、「敗戦国色の濃厚な」旧ヤマトの作中にあって、暗黙のうちに強く語るものがあります。「戦勝国に吸収された敗戦国」の心情というか。‥‥デスラーと心情的に近しくなる表現が出てくるのも、「敗戦国同士」ゆえかも知れませんネ。

この頃までのアニメは、「敗戦のルサンチマン」が作品のルートになっている設定・ストーリーがよくあります。80年代に入って「うる星やつら」あたりでその影はほぼ消えたと思いますが、70年代(〜80年代初期)までの作品は、「父はまだ生きている」「母に会いたい」〜戦争孤児的な感情の流れを汲むものや、「国は負けたが、俺たちは負けてない」的な心情を根底に感じさせるものが、数多くありました。

もしかしたら、アンドロメダ人気は、作品の根底の感情からすれば、原作者としては苦みを感じるものかも知れませんネ。劇中では、最大の威容を誇って先陣をきるアンドロメダが、哀れにも全く無力で、ゴミ屑のように踏みつぶされる‥‥という描写で、「意図通り」の展開でしたが、子供たちの間ではデザインのかっこよさが優先され、アンドロメダの負けは「無かった事に」なっているという‥‥。

ヤマトシリーズのプラモを眺めて、単に「懐かしいプラモ」というよりは、デザインやカラーリングに色々な事を考えさせられる、オジサンになった私‥‥でした。

VMware Fusion 5

Windows環境が必要な時、近年はVMware Fusionという仮想マシン環境を使っています。私はリアルタイムレンダリングのゲームとか処理能力の必要なソフトウェアは使わないので、Fusionで充分事足りてしまいます。

このVMware Fusionは、アクトツーのWebでダウンロード版を買うよりも、アマゾンでパッケージ版を買った方が、まず15%くらい安いですし、USBメモリとディスクの両メディアが同梱されているのでお得です。

別途、OSのライセンスが必要ですが、Windowsに限らず、Ubuntuとか昔のMacOSXとかも動くようです。ちょっとだけRossetaが必要だけど、メインは10.8が良い‥‥なんて人は、10.5をFusionで実行する‥‥なんていうのもありですネ。

シームレスにWindowsが使えるのは、何だかんだいって、やっぱり楽です。別マシンを起動せずに済むので、電気代もかからないし。Fusionのバージョン5は、より一層、OSXのデスクトップとの統合が図られているので、WinodwsのソフトウェアをOSXのソフトウェアのように気軽に使えます。

仮想マシン‥‥と言えば、OS9の実行環境として、Sheep Shaverというのがあるのですが、いつか試してみようかと思っています。まあ、ノスタルジー以外のなにものでもないので、優先順位は低いですが‥‥。



コマ感覚

私は、長年アニメ業界に在籍して、いわゆる「コマ感覚」〜タイミングの感覚が24fpsで体の中に定着しています。

しかし、48,60,120などのハイフレームレートの場合、24コマ視点だと色々と扱いづらい面が出てきます。ゆえに、最近は1秒は1‥‥というような、ある種の浮遊小数点的な感覚でタイミングを捉えるように変えてきています。まあ、24コマの感覚は根強いので、どうしてもクセは出てしまいますが‥‥。

After Effectsのプロジェクト設定は、私は昔からタイムコード表記にしてあります。フレーム数表記は、使いません。シートを照合する際は、テキストレイヤーでシート枚数とコマ数を表示するガイドを作って合わせています。

フレーム数表記は、例えば、シート風に1スタートなら、6秒は1-144になります。私はこの「秒の間隔を直感的に感じない表記」がイヤなのです。「馴れればいいじゃん」とか言う人もいるかとは思いますが、フレームレートが変わる毎に「馴れ直す」んでしょうかネ?  30,60,120fpsの世界では、6秒は144コマじゃないですからネ。

アニメ制作ではなく、映像全般の制作における表現者たるには、フレームよりも秒感覚で体内ストップウォッチを持っていた方がツブしが効くと思うのです。もちろん、音楽の「拍」と同じく、24で秒をグリッドしても良いかとは思いますが、かたくなに24コマだけの世界に閉じこもるのは、少なくとも私は不安を感じます。‥‥というか、私は30fpsも普通に作業でこなさなければならないので、24の感覚のままではいられなかった‥‥のですけどネ。

これは大雑把に時間を捉える‥‥という事ではなくて、むしろ逆です。例えば24fpsの1コマという把握の仕方ではなく、0.04秒と実感する‥‥という事です。24コマに馴れきった体には、結構シンドいかも知れませんが、24コマだって仕事で馴れたんですから、出来ない事は無いです。思うに、0.02秒くらいの分解能は、持てるんじゃないですかネ。ごく普通に16分音符のハイハットが聴き分けられるんですから。

ちなみに、現在私が使っている時間情報テキストレイヤーの一例は、以下の通りです。
もっと高機能な切り貼りシート対応型のもありますし、もっと動作の軽いシンプルなものもありますが、スタンダードなものをご紹介しておきます。


var tsFrameCount=144;//6秒シートの場合

var fps=1/thisComp.frameDuration;
var fr=timeToFrames(time,fps,true);
var value1=getTsTime(fr,fps)["tsFrame"]+" : "+getTsTime(fr,fps)["tsTime"];
var value2=getTsTime(fr%tsFrameCount,fps)["tsFrame"]+" : "+getTsTime(fr%tsFrameCount,fps)["tsTime"];
var tsCount=String(Math.floor(fr/tsFrameCount)+1);

time.toFixed(2) + " / 秒¥r- - - - - - - - - - - - - -¥r" + value1 + " / 全体表記¥r- - - - - - - - - - - - - -¥r" + value2 + " / シート" + tsCount + "枚目";

function getTsTime(framecount,fps){
    return {tsTime:String(Math.floor(framecount/fps) + 100).slice(1) + "+" + String(Math.round(framecount%fps) + 101).slice(1), tsFrame:String(framecount + 10001).slice(1)};
}


timeToFrames()の困惑


After Effectsの尺など、時間やフレームをテキストレイヤーで表記する事はよくありますが、使い方によっては、意図しない結果になる事があります。

使う人はよく使う「timeToFrames()」は結構なくせ者で、ちゃんと3つの引数全てを入力しないと、何かのきっかけによって、返値が1、ズレる事があります。

例えば、12+12を表示しようとして、12+13になる事があります。これは、引数isDurationをtrueにすれば防げる事ですが、After Effects上での挙動が曖昧なので、「この引数は特に指定しなくても大丈夫だ」と処理しがちです。

同じスクリプト文でも、隣の人の環境ではちゃんと意図通りの結果、自分の環境だと1ズレる。じゃあ、自分の環境が何か違うのかと思っていると、隣の人の環境でも、やがて1ズレる。‥‥実は昨日体験した事例なのですが、挙動が曖昧で「再現性をつかめていない」ので根本の解決には至っておりません。対処法はありますが。

以下の例文。

timeToFrames(8/24,24,false)+" : "+timeToFrames(8/24,24,true);

人によっては「8 : 8」、違う人では「9 : 8」と表示されます。厄介なのは、「8 : 8」と表示されていた人の環境でも、何かのきっかけで「9 : 8」になる事です。なぜ最初から「9 : 8」と表示されないのでしょうネ?

要は「0,1,2,3,4」か「1,2,3,4」かの事だとは思うのですが、引数「isDuration」の挙動がおかしいんだよなあ‥‥。

作業用のテンプレートとして配布されるAfter Effectsプロジェクトで、上記のような障害が発生し、ボールドの尺表記が1フレーム分ズレる事があります。テンプレートを作った本人はその障害に気付いてないですし、受け取った人によっても挙動が違うので、「結果オーライ」とそうでない場合がマチマチなのです。

エラーの再現性を確立できなくても、対処法は簡単です。isDurationをtrueにして扱えば良いのです。isDurationをfalseにするのは、返値が曖昧なので、NGですかネ。‥‥まあ、ネジが外れた部分にガムテープで処置するような対処法ですが。

サンプルの尺表示のエクスプレッションです。

var offset=8;
var fps=1/thisComp.frameDuration;
var dur=timeToFrames(thisComp.duration,fps,true)-offset;
"("+String(Math.floor(dur/fps)) + "+" + String(100+Math.round(dur%fps)).slice(1)+")";

昨日はレンダリングしたQTをチェックしてビックリ。ボールド表記に、12+01とか、20+13とか、妙なコマ数が表記されてて、実際に尺をミスったかと思いました。困ったのは、環境によって障害が出ない事も多かった事です。草木も眠る深夜にAfter Effectsの珍妙な挙動に悩まされるとは‥‥。一律で全部1コマ多かったら、明快なんですけどネ。

尺、桁揃え

After Effectsで尺〜デュレーションを自動表記する際、私が昔から好んで使うのは、以下のようなエクスプレッションです。

var offset=8;
//ボールドなどの尺を引く場合は、適宜
var t=thisComp.duration-framesToTime(offset);
String(100+Math.floor(t)).slice(1)+ "+" + String(100+Math.round(t%1/thisComp.frameDuration)).slice(1);
//2桁で表記を統一する場合です


*ブログのデザイン上、改行されている箇所がありますが、行末はあくまで「 ; 」です。

私は、昔からの習慣で、小数点の端数で痛い目にあっているので、thisComp.durationをframeDurationで割る‥‥というような事はせずに、1秒で割った余りだけをframeDurationで割るようにしています。誤差を極力出さないルーチンにしておけば、どんな環境でも表記上の誤差は発生しない‥‥という事です。
*誤差の累積を、故意に発生させる場合は別ですヨ。

また、floorとroundは上手く使いわけてこそ‥‥です。floorばかり使っていると、思わぬ結果が出る事がありますネ。


また、数字の表記を2桁で揃えたい、4桁で揃えたい‥‥という時には、

var ketaNumber=Math.pow(10,桁数);

で、必要な桁数の位が繰り上がった数を用意しておき、

String(ketaNumber+任意の数).slice(1));

‥‥にすれば簡単にゼロで埋めた文字列を生成できます。つまり、0025が欲しい場合は、

String(10000+25).slice(1);

‥‥で済みます。わざわざIF文を使わずとも、1行でおさまります。

if num<10 {"0"+num} みたいなのは、2桁だとさほど苦ではないですが、例えば4桁の場合は、IF分岐がめんどくさい事になりますネ。for構文でゼロを追加するのも、なんだか大袈裟過ぎます。

私は今まで散々、桁数を揃えた番号と付き合ってきたのですが、何だかんだ言って、上記のプリミティブなやり方(10のべき算を一時的に足す)が一番シンプルで使い易く感じています。項目の数に応じて、動的に桁数を変える事だって、簡単にできますしネ。


*「var」も「;」も、エクスプレッションでは無くても見逃してくれるんですが、何かね、不安で。 ‥‥妙な省略癖がつくのもイヤだし。

スクリプト、凡ミスです

前に書いたスクリプトの例文で、8フレームのオフセットで、

thisComp.duration-8;

とか書いてましたけど、これじゃあ、8秒引いてしまいますがな。。。すみません。

正しくは、

thisComp.duration-(framesToTime(8));

ですネ。

仕事してたら、ふと気付きました。

当該の記事は訂正して、順番を上げときました。

オリジナルのFunction集

スクリプトやプログラムを覚えたての頃(1996年頃)は、漠然とコードを書いていたのですが、それではあまりにも効率が悪い事に気がつき、定型の処理をモジュール化して共用するようになりました。誰に教えられたのでもなく、自然と。

オブジェクト指向のプログラムを覚えたのは、自己流のモジュールを作り始めて、さらに効率的な方法を求めていた頃でした。2000年前後の頃に、REALbasicというのがMacソフトウェアで出て、それで自作のクラスの作り方・使い方やプロトタイプ的な考え方を習得しました。オブジェクト指向って、何たるかが理解できるまでは悶々としますが、理屈がふと解る境界があって、それを超えると、反ってエスカレートしてオブジェクト的な考えで指向するようになります。‥‥まあ、それは私の場合、ですが。

でも、オブジェクト指向を持ち出さなくても、効率的に自作ソフトは作れます。時と場所で使い分ければ良いんですネ。

効率的に作る方法は、何よりも「使い回しの効くFunction」を作る貯める事です。例えば、連番の番号抜けをチェックするルーチンを、その度に書いていたら、まず時間を浪費してしまいますし、改良を加えようとすると、複数の自作ソフトウェアに埋め込まれたそのルーチンを全部直して回るハメになります。

MacOSXの場合は「Application Support」と言う共有ライブラリを置いておく場所も用意されてますから、そこに自作のFunction集を置いて、ソフトウェア上ではそのFunctionを呼び出すようにします。もしFunctionに不具合があった場合は修正すれば、すべてのソフトウェアに反映されます。

まあ、スタンドアロンのソフトウェアを作りたいのなら別なのですが、アニメーション制作で用いる様々なツールで共有するFunctionライブラリは、作り貯めて、活用できるよう整備しておくと、開発の面でとても楽になります。

塵も積もれば‥‥でしょうが、結構な数のFunction、サブルーチンを書き貯めました。ファイル名を分析する、撮影種別を撮影用語に変換する、番号欠番をリストする、EDLをAfter Effectsのtimeに変換する、数列からタイムリマップキーを生成する、TGAの空セルを生成する、他社の命名規則へ変換するマクロ、虫食いのイメージシーケンスを虫食い連番から生成する‥‥などなど。

Function集が充実してくると、骨組みを作ってFunctionで肉付けするだけで、そこそこの処理ソフトが作れるようになります。その時に足りないものは、ここぞとばかりに書き足せば、Function集はどんどん強力に育ってきます。

やっぱり、コンピュータはプログラムを作れてナンボ、だと思います。うわべで快適を謳うソフトが増えても、底力としてプログラムの知識は「特にコンピュータで四六時中仕事をする人」は必須だと思います。今も昔も変わらずに。

思うに、近年のコンピュータって、使う人間と使われる人間の「貧富の差」がどんどん大きくなっているように思います。iOSなんぞに満足してたら、あかんのです。

コードを書き直し

プロジェクトとコンポジションを自動でビルドする「CBX」というオリジナルソフトウェアがあるのですが、作った当時、After Effectsのスクリプトを探りながら書いたので、今読むと「ありえない」ような書き方が頻発しております。覚えながら作る弊害みたいなもので。

そろそろ、その「CBX」も、書き正すところは正して、開発を一旦終了すべきかと考えております。大量に作画して大量にペイントして‥‥というスタイルのアニメの作り方が、もう私にとってはリアルでは無くなってきた事もあり、「CBX」を使う頻度はどんどん減少するでしょう。しかし、まだ従来撮影様式の要請があるのも事実なので、少ない頻度であっても「レタス素材のコンポジット」を効率良く作業するために、内容をかすかでも記憶している今のうちにコードを読みやすく、刷新しようかと考えています。

‥‥自分で書いたプログラムでも、時が経てばすっかり忘れるものなのです。というか、私の場合は、少なくとも。

「CBX」は通常のアニメ撮影内容〜セルと背景、全セル、BGオンリーなど、旧来からのアニメ撮影のスタンダードを網羅するため、非常に面倒で煩雑なルーチンが内蔵されております。さらに、必要に応じて「増築」したゆえに、ラビリンスと化しており、作った本人でも早々に迷子になります。困ったもんで。

もしこのまま放置すると、数年後には書いた本人ですら読解に時間のかかるシロモノになってしまいます。

あと、もうちょっとは活躍しそうなツールですし、近々に必要になるので、4月あたりで何とか書き直そうかと思っています。あまり、奇麗にしようと欲張らずに。


calendar

S M T W T F S
  12345
6789101112
13141516171819
20212223242526
2728293031  
<< August 2017 >>

selected entries

categories

archives

profile

search this site.

others

mobile

qrcode

powered

無料ブログ作成サービス JUGEM