MacのAppleScript

私がAfter Effectsを駆動するアプリを作る際の「常套手段」は、AppleScriptと組み合わせるやり方です。GUIをAppleScriptに担当させて、After Effects上のスクリプトは処理に徹します。

Xcodeを用いて本格的なGUIを装備する方法もあるのですが、何だかんだと時間がかかるので、AppleScriptオンリーでGUIを調達します。AppleScriptはalert()的なものはもちろん、リスト表示、ファイル選択、フォルダ選択、新規ファイル指定、カラーピック、テキスト入力など、とりあえずひと揃えがあるので、開発上は特に困らないのです。一般的な開発環境と違って、自作のウィンドウ(インターフェイスビルダーで作るような)は作れませんが、対話式のアプリならストレスを感じずスイスイ作れます。

例えば、AppleScriptは、Finderで扱うファイルやフォルダをas unicode textで簡単にファイルパスに変換できますから、FinderでChooseしてファイルパス文字列に変換し、Adobeのスクリプトに組み込めば良いのです。ちなみに、HFSのパス文字列がイヤな場合は、POSIX Path of...でスラ区切りのパスを取得できます。quoted form of...を使うと意図せぬコマンドと文字列の衝突を防げます。

MacOSXでAfter EffectsをAppleScript経由で制御し、さらにWindowsに処理を渡す場合は、ちょっと工夫が必要ですが、出来ない事はありません。Windowsで「After Effectsサーバ」的なスクリプトを走らせておいて、MacOSXから投げこむ‥‥のような事も可能です。独自のキューファイル(ジョブファイル‥‥呼び方はどうとでも)を規定して、Mac/Win共通規格の書類とする事で、MacからでもWinからでもAfter Effects処理サーバに処理を投げ込む事ができるのです。After Effects処理サーバは、特別な事をしているわけでなく、単にスケジュールタスクを定間隔で走らせて指定フォルダ内をCrawlして、新規キューファイルを見つけたら指示通りに処理をするだけ‥‥です。

ぶっちゃけ、今の私は、ソフトウェアの開発にそんなに時間をかけられなくなっているので、AppleScriptくらいのレベルがちょうど良いのです。まあ、他の言語に馴れちゃうと、AppleScriptは冗長なコードになりやすく、タイプがめんどくさくて、たまに心が折れる事もあるんですがネ‥‥。theArray[0]で済むところを、item 1 of theArrayですからネ‥‥。

また、Windows作業環境グループでQuickTimeのProRes出力する場合などは、規模にもよりますが、Mac miniとCompressor、AppleScriptを使えば変換サーバを仕立てられます。AppleScriptのon idleを使って自動巡回変換ソフトを作っちゃえば良いのです。仮にAfter Effectsのライセンスがあれば、さらに高度な変換(スレートを自動生成するとか)もできます。AppleScriptベースなので、開発時間が最小で済むのです。

Macを使ってるんなら、今さら何ですが、AppleScriptを使わないのは、もったいないですヨ。

‥‥ちなみに、無理すれば、AppleScriptから直にビットマップデータを書き出す事が可能です。SGIなどの簡単な書式であれば、ですが。スクリプト文中にヘッダ部とビットマップを文字列で記述し、open for accessで書き出し、ファイル名に拡張子をシレッと付ければ、ちゃんと画像ファイルになります。

スクリプトを書くとソフトを覚える

何か逆説的な言い方ですが、私がコンピュータに詳しくなっていったのは、スクリプトを書いたからかも知れません。「スクリプトって、コンピュータに詳しい人が書けるものなんじゃないの?」とか思われるかも知れません。‥‥が、みんなが超能力者や諜報機関の人間じゃないので、他人が作った仕様を何もなしに理解などできません。誰もが、開発者サイドの用意した文献なりヘルプなりを読みながら、スクリプトやプログラムを書きます。

つまり、スクリプトを書く過程で、否が応でも、ソフトウェアの仕組みを覚えてしまうのです。スクリプトの書き始めは基礎的な知識しか無くても、書き進むうちに、ソフトウェアやコンピュータの事を覚え、さらには、ソフトウェアの内部構造を知ると、スクリプトの書き方が改良され、「上昇気流」にのるようにどんどん総合スキルが上がっていきます。

スクリプトがわからない‥‥と言っているうちは、実は、コンピュータもわからず仕舞い‥‥なのかも知れません。極論めいた響きではありますが。 「スタートアップガイド」を丸暗記しても、コンピュータを使えるようになったとは言い難いですもんネ。
*‥‥ただ、昔からコンピュータをいじっている人は、時代的に、プログラムやスクリプト、マクロといったものと無縁ではいられなかったでしょうから、コンピュータとはどんなものかは、嫌でも知っている事とは思います。

例えば、Finderのウィンドウ。ただ漠然と接しているだけだと、「ただのウィンドウ」としか言いようのないものです。しかし、ウィンドウ絡みのスクリプトを書くと、ウィンドウに関する色々な事柄に触れる事になります。

target, position, bounds, current view, statusbar visible, sidebar width

これらは、ウィンドウの見た目を制御するプロパティです。これらの値を変えると、ウィンドウも呼応して変化します。ウィンドウの姿がどのように制御されているかを知る事になります。

class:icon view options, arrangement:arranged by name, icon size:64, shows item info:false, shows icon preview:true, text size:12, label position:bottom, background picture:missing value, color:{65535, 65535, 65535}

これは、アイコン表示時のウィンドウのプロパティです。icon size を64から128にすると、アイコンの表示サイズが倍になります。

こうして、スクリプトを書くうちに、Finderや、PhotoshopやAfter Effectsなどの内部構造を、「知ってしまう」わけです。

After Effectsでは色々な要素を扱いますが、各要素はどのような関係性をもっているのか? フッテージとは? レイヤーとは? ‥‥AVレイヤー、ソリッドレイヤー、テキストレイヤー‥‥みな同じレイヤーですが、After Effectsの内部的には、扱いは大きく異なります。

実は私は、スクリプトを書くまで、そんなにAfter Effectsの内部を知っていたわけでなく、単に経験則で「こんな構造なんだろうな」と考えていただけです。しかし、スクリプトを書く事で、After Effectsの「融通の良さ・悪さ」に対して「合点が行った」わけです。

他人が書いたエクスプレッションをコピペしてるだけじゃ、After Effectsは深く理解できんです。自分で書いてみないと。 ‥‥同じように、コンピュータのスペックだけ詳しくても、単に「コンピュータが好きな人」なだけで、駆使する能力は身につきません。

スクリプトとコンピュータの知識って、右足と左足のようなもんで、片方ずつ繰り出して進んでいくもんですネ。

作業環境マネージャ

小刻みな仕事を多くこなしていると、フォルダやファイルの管理というか、作業環境がルーズになってきます。‥‥とは言え、そうじゃない人もいるでしょうから、私は特に‥‥と言っておきましょう。

アニメの撮影だけやってた頃は、あまり乱れなかったんですが、多種多様な作業をおこなうようになって、自分でも嫌になるほどフォルダ構成がルーズになってしまいました。「このファイルはどんな名前のフォルダに入れて整理しておけばいいんだ?」とか、「そもそもこのファイルのカテゴリは何だ?」とか、迷ううちにテキトーな名前を付けてテキトーな名前のフォルダに入れて、そして後で探しまわる事になる‥‥と。

「検索すればいいじゃん」とか思うのですが、テキトーな名前ゆえ、検索文字列すら思い起こせないので、検索が解決案とはならないのです。例えば「.psd」で検索してたら、色んなファイルが引っかかりますしネ。

ここ数ヶ月、こまめな仕事をしていて、とりあえずプロジェクトごとのフォルダには収まっているものの、中身は混沌としてしまって、昨夜、「まだ記憶が残っているうちに」整理しました。

‥‥で、整理をしてて、「これって、コンピュータでヘルプ可能だよな」と、ふと感じました。

まあ、もともと私がコンピュータに期待して、プログラムを習得したのは、こうした自分自身の欠点〜整理が苦手〜を、「作業に足枷にならない程度に改善したい」という目的があったからでした。

その昔、OSのウィンドウが散らかるのがイヤで、「どのフォルダのウィンドウを、どのような表示形式で、どの位置とサイズで開くか」を記憶するアプリケーションを作った事がありました。自分で使い易いように各ウィンドウを整頓して並べて、その状態をテキストファイルに記録し、適宜呼び出す‥‥というものです。ウィンドウの整頓は、Finderのスクリプトで誰もが一度はやる内容かも知れませんが、その自作アプリは各ウィンドウの状態を独自のテキスト書式で読み書きするのがミソでした。「ウィンドウマネージャー」とでも言いましょうか。

それに似た事を、フォルダのツリー構造でやれば良いんですネ。テキストファイルの書式やごく簡単なマクロ言語を決めちゃえば、そんなに難しい事ではないです。MacOSXは素でShellが使えるので、正規表現も流用可能ですし。

作業環境マネージメントのソフトウェアを作り、そのひな形を何種類か用意しておいて、通常はそのひな形を使って整理し、ちょっと変わった仕様の作品には、ひな形を適宜書き換えて用いる‥‥という具合です。ひな形はテキストファイルで、汎用テキストエディタで編集可能とします。わざわざバイナリデータにする必要ないですネ。

アプリ作成は、やっぱりAppleScriptかなぁ。手軽なJavaScriptよりも、さらに手軽ですからネ。Shellも巻き込んじゃえば、ひと通りの事はできちゃいますしネ。


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月あたりで何とか書き直そうかと思っています。あまり、奇麗にしようと欲張らずに。

空セル

After Effectsでアニメ撮影‥‥で思い出しましたが、初心の頃、大体つまずくのが、「空セル」の処理です。

ちまたを眺めてみると、

  • ブラインドエフェクトなどのエフェクト処理
  • 透明度0%
  • 全部透明の画像を用意する

‥‥が多いようです。今でも、そうなんだろうか?

一番簡単で融通が利くのは、プリコン&空フレームでしょう。初心者はなぜ、これに気付かんのか、不思議です。私も以前はそうでしたから。

画像シーケンス(もしくはQTでも)を読みこんで、すぐに使うのではなく、一旦プリコンします。‥‥で、プリコンした先でコンポのデュレーションを1フレーム分延ばし、何も絵がない1フレームをコンポジション上で作ってやるわけです。すげー簡単な、空セル製造法。

仮に先頭1フレーム目を空にして、2フレーム以降からイメージシーケンスをレイヤー配置すると、「0:00:00:00」フレームが空セルになりますネ。ちまたのWebでは、「timeRemapの値の調整だけでは難しい」とありますが、プリコンして空フレームを用意するだけで、「timeRemapの値の調整だけ完了」します。透明度やブラインドを併用するよりも、シンプルかつエレガントです。メンテも楽です。

スムージングのフィルタはプリコン前でも後でも。‥‥ただし、プリコン後にスムージングをする際は、レイヤー配置の座標は「0.5」が発生しないようにルーチンを組みましょう。じゃないと、画像補間法が邪魔して、スムージングがうまく適用されません。

プロジェクトのオートビルドのサブルーチンに、イメージシーケンス検証ルーチンと、この空セル処置を含めたプリコンのルーチンを組み込んでおくと、困った動画番号(歯抜けの番号とか、追加動画のA101,102とか)にも対応できます。空セルを作るだけでなく、歯抜けのセルを空セルで補うわけですネ。

イメージシーケンスファイル名を総チェックし、番号が全部繋がっていれば動画フッテージ、そうでなければ、静止画フッテージとして読み込みます。もちろん、スクリプトで、ですよ。歯抜けだったり、番号が一部飛んでいる場合は、静止画フッテージで読み込んだ連番をシーケンスレイヤー的に配置します。これももちろん、スクリプトで、です。‥‥シーケンスレイヤーなんて、手作業でやると地獄ですが、コンピュータでスクリプト処理すると一瞬ですからネ。

でもまあ、実は私、こうした「シートをつけて動きを云々」するタイプのアニメーションから、結構ご無沙汰しています。私が規約しているタイムシート「らしき」ものは、まず横書きですし、ABCDEセルなんていう概念はありません。3Dのリギングやオブジェクトのバインドに近い考え方で、シートの主目的は、演技シーケンスを記述するためのものです。1秒間を把握しやすくするために、都合、秒間をセル(=表の)で分割していますが、24コマの縛りはありません。概念としてはステップレスなので、60fpsでも120fpsでも、その場に合わせていかようにでも。‥‥もちろん、紙ではなく、データです。コンフィグ関連をいちいち紙にしているとロスが半端ないですからネ。

PHPとかJavaScriptとか

PHPロゴ-GIF久々にPHPのコードを書いているのですが、すっかり忘れとります。困ったもので。

どう書けば、PHP足り得るんだっけか‥‥とか、そんなレベルで忘れてます。ぶっちゃけ、似たような色んな言語を扱ってると、混同するんです。

PHPは、

<?php

?>

ですね。

Webをやるなら、PHPとかJavaScriptを最低限でも活用すべきです。そこそこ本気でやるならば、です。

「高度な事ができる」とか、そんなんじゃありません。手間を減らせるのです。要はCSSと一緒ですネ。

「HTMLだけ書いた方が、一番手間が少ないじゃん?」とか思う人は、あまり量をこなしていないんだと思います。でも、量といっても、ページにして50〜100くらいのレベルであって、実際にその量をメンテすれば、「手間」について実感できるとは思うんですけどネ。

例えば、Webページに共通のパーツや、記述。必ず、ページ最下部に表記されるクレジット的な一文を、50ページくらい書いた後で、「変更したい」となったら、どうするんでしょう? 我慢して50ページを全部開いて、修正部分を書き直しますか?‥‥そういうのを人生の無駄使いと呼びます。

「ひな形ファイルを用意して、そこから各々ページを書き増やす」だけじゃダメなんです。もしそのひな形が間違ってたり、後々修正したいと思ったら、それまでに書き溜めたコンテンツは全部修正しなきゃならんじゃないですか。

もしPHPやJavaScriptがあれば、そうした「ページ共通の記述・パーツ」を1つのファイルだけで管理し、どんなに書き増やそうが、最小の手間で、いつでも変更を反映できるようになります。

一番手軽なJavaScriptですと、例えば「credit.js」などの適当な名前でファイルを作り、document write()でクレジット文を書いておき、何10ページに及ぶ各HTMLページはJavaScriptを実行するだけにしておきます。つまり、スクリプトを実行する事だけをHTML上で書いておいて、文面の中身は他のファイル「credit.js」に任すわけです。そうすれば、「credit.js」を書き換えるだけで、100ページだろうが、1000ページだろうが、変更内容が反映されます。

PHPの場合は、共通パーツを書き集めたファイルを用意しておき、include_once()でそのファイルを読みこんで、実際の本文内で活用します。いくつもの変数、ユーザ定義の関数を書いておけば、あらゆる場面で活用できます。

このような構造は、もちろん、コンポジットの作業現場でも利用可能です。私はもう10年以上前に、「同じ作品を皆で作業するのに、何で、めいめいがAfterEffectsの設定を自己的におこなってるんだ?」と非効率で危うい(=人によって設定が間違っているかもしれない)運用に疑問を感じていました。ゆえに、xtoolsとatDBを自己開発し、「基本設定や仕様は、サーバ(=一元管理)に任せる」運用を実践したのです。これによって、ケアレスミスが格段に減ったのは言うまでもありません。

メンテや環境整備の手間が減る。これはすなわち、「本当に作りたいものに時間を割り当てられる」という事です。コンピュータは「真正直に手作業で向き合っていたら、その人間の『生気』をどんどん吸い取っていく」性質が多分にあります。怖いヤツなのです。

で、PHPとJavaScript。

本来は様々な機能を持っているのですが、「手間を削減する、ちょっとした工夫」にも威力を発揮します。プロパティの集中管理だけでも、使う意義はありますし、それならば難易度は低いです。変数をまとめて記述し、Web本文中に「echo」するだけですからネ。




calendar

S M T W T F S
   1234
567891011
12131415161718
19202122232425
2627282930  
<< November 2017 >>

selected entries

categories

archives

profile

search this site.

others

mobile

qrcode

powered

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