最後の歯医者の帰りに雑誌ばっかり購入。
メガミマガジン クリエイターズは巻頭はいつも通りの記事なんだけども、その後の「この業界で生き残るために」っていう題名で岡崎武士のインタビューが載っていて非常におもしろかった。以下に目に留まった内容をメモしておく。
2項目はよく言われることかもだけど、個性を勘違いしちゃいけないなぁと。2,3項目は、ポール・グレアムも「ハッカーと画家」の中で言及している。
絵画と同様、ソフトウェアも多くは人間が見て、使うものだ。だからハッカーも、画家と同じように、ほんとうにすごい仕事を為すには、共感する力が必要だ。
(中略)
共感能力は、おそらく良いハッカーと偉大なハッカーの、たった一つの最も重要な違いだろう。ハッカーの中には非常に賢いが、共感するということにかけては全く自己中心主義の人々がいる。たぶんそういう人が偉大なソフトウェアをデザインするのは難しいだろう。ユーザの視点でものを観ることができないからだ。
ハッカーと画家 -Hackers and Painters- Copyright 2003 by Paul Graham 日本語訳:Shiro Kawai
この共感するっていうのがとても苦手、共感するという気持ちを阻害していると思うのが「個性を誇る」ことかな。「個性を誇る」というのは「個性的でいたい、ありふれた表現・見方をしたくないという勘違い」っであって、「(勘違い)個性的ありたい」と自分を強く守るせいで、「他人の視点=自分の個性(と思っている)以外の視点」へ自分を置くことを怖がっているのだと思う。
怖がることは二つ。自分を外から見るのが恥ずかしいという自意識からくるもの、もう一つは個性が弱まるのではという勘違い個性を守ろうとする考えからくるもの。
他人に見向きもしないで守ってきた「個性」を誰が見てくれるんだろうか。同業者?同じ境遇に居る人?じゃあ、せめて身近にいるそういう人の立場に立ったか、それさえしてない。
最終回、原作物で完結していないうちにアニメが最終回を迎えるのはうまくいかないパターンになっちゃったなぁ。最後のまとめかたは「彼らの話は続きますが、これで終わりですよ〜」と言われているようなまとめ方だった。とはいえこれは想定の範囲内だしまぁいいや。結局、ハチクロアニメに対する評価は変わらず。
と書いてみたものの、原作に対して強い思い入れがあると、自分の思い描いた解釈、テンポとアニメにズレがあればやっぱり評価は低くなるね。当たり前の話じゃん...。とりあえずアニメ版ハチクロは自分の求めるものでは無かった、おしまい。
この問題をふまえて、次のパラキスはアニメが終わるまで原作を読まないことにしよう。その前にNANAをさっさと読めよ> 自分。
なんか題名と後半言ってることが違う気がするんだけども。他人に自分の理解したこと(理解しようとしてること)を話す事で自分自身の理解が深まるってのは、アウトプットすることで強制的に順序立てて理解することができるということなんだろうなぁ。順序立てる過程で理解の足りないところとかもわかってるくし。
全然更新をしていなかったのは、最終日つくばに行く以外はトーンを貼る、ベタ塗り、落書き、しかしてないからです。これじゃあ書くこと全然ないさー、物が完成するまでは。
しかもずっと座ってた割りにあんまり進んでないし...orz。
学祭で研究室に遊びに行った時、また舞い上がっちゃっていたらん事になってた。あぁやっぱりかぁ...。ごめんなさい > 研究室の皆様
夏コミの時もそうだったっけど、明らかに舞い上がって周り見られなくなってた。うぅ、ええかげん落ち着こう。
これいじょう時間をかけられないので、予定から遅れること...、何とか終了、スカスカだぜーorz。さてさて二本目、まだネタが固まってないぜー(泣
問題は1ヶ月後、この原稿を見直して耐えられるのか...。まぁ耐えるしかないわけだけど。論文なんて次の日には見たくなくなるのにね。
最初読んだ感想は「さすが物書きの人は文章わかりやすいなぁ。」...、そんなわけで長文だけどもさっと読めるエロゲ業界の危険な産業構造について記したエントリ。
読んでも思ったことは、自分の姿勢に対する反省、絵ばっかり見てるのはいかがなものかと思った。
エントリの中身とは関係ないけど、描く側として、シナリオについてもっと勉強しようと思った、日常のシーンだって怪しいからなぁ、漫画/ゲーム以外からヒントを得ることがマジで重要なんだなぁと思わされた。も一つ、色々描けるようにならないといかんわなぁ、「描けないから描かない」は描く人間の言葉じゃない。
以前先輩がblogで書いていた言葉で「感性の研究といっても、感性で研究するのでない」みたいな事を言っていて、これらにもあてはまる言葉だと思い直した。
一つ目のリンクはOpen Solarisのサイトのエントリなのでそれを差し引いて読む必要がある。
1,2回目はまだ導入、次回以降に期待できるっ。
おもしろかったのはばらスィー氏の言葉。
人はたまに俺の絵を見て「お前のキャラは見分けがつかない」と言う。
そんなとき俺はこう言う。「がんばって見分けろ」
(2005年5月初めごろの「ばらスィーの画像置き場」のコメントより)
"タスク指向"という言葉の意味について調べているときにあたったもの。今注目されているらしい、"結果指向"とは何が違うのかわからないが、こういう視点が前からあることをはじめて知った。
作画が高いレベルで安定している上に演出が細かいので見ていてとても楽しいぱにぽにだっしゅ。問題は話のスジがあってないようなものであることか、ん?それともつかめてないだけなのか。
先週分は時間が遅れていたおかげで半分も見れず...orz
リンク先にも書いてあるけど、「一つの引数をとる関数を返す関数」のことをカリー化(もしくはそういう書き方)と呼ぶのかしら。...で何に使うんだろう、っていうか関数型言語を使える人たちはマジすげぇなぁ、自分は手続き型言語ですらまともに使えてないよ...。
弁当持参で節約してる意味ねージャン!まぁどうせ給料入ったら買うから意味ないけどー。
いばらの王は完結、一巻丸々隅から隅までクライマックスになっていた。映画的な進行演出だったのは確か。若干御都合主義を感じてしまうところがあってカタルシスを感じることはなかったけど、ガンガン展開していく話は読みごたえあった。
ラバ7はサブキャラの話がメインの巻だったんで少々物足りない。最後の話がどう続くのやらが気になるくらいかしら。あぁでも店長の話みたいな雰囲気は好きー。
Wネームはやっと話の筋が見えた巻で、主人公の実生活と裏稼業のつながりもできそうな雰囲気。とはいえインタビューやらサイン会に出るのは無理だろうと思いつつ、まぁいいや。若干話が重いかなぁと思ったけど、重要なファクターだし、これがなきゃ話にならないし。今後の展開が楽しみ。
RECは作者らしい展開ながらも、まったりした展開だったけど、巻末の話で話が動いてきた、あとがきを見る限り小ネタもかなりよい感じに入ってきそうな感じ。
以下の文章はHow to write a GIMP plug-in(developer.gimp.org)の1ページ目を勝手に訳してみたものです。間違い甚だしい訳だけどもとりあえず上げてみる。まぁ訳す作業は読むだけよりもちゃんと文章を読もうとするから読むだけより内容を理解している気がしないでもない。そんな自分の為の作業の一部というわけで。
ちなみに画像は省略してあります、また例のコードも長い物は省略しています。なので、読むときには原文とつきあわせながらの方が良いと思います。
原著者: Dave Neary(bolsh@NOSPAM.gimp.org)
この記事では、GIMPプラグインの基本的な事項を示し、libgimp APIを紹介する。また、他のスクリプト作者に自分で作ったプラグインが使えるようにするための、PDBの使い方も示す。
新しく開発を始める人はたいてい、GIMPのサイズと世間での評判に怖じ気づいてしまう。そのため、プラグインを書くことは難しいことだと考えてしまう。この記事の目的は、Cでプラグインを書くことがどれほど簡単であるかを示すことで、気遅れ(this feeling)を解消することである。
このパート(1P目)では、プラグインの基本的な事柄を示す。プラグインのインストールの仕方と、画像からデータを取得する方法やそれを直接操作する方法を示す。
GIMPスクリプトのインターフェースはProcedural database (PDB)に集中している。GIMPを起動したとき、あらかじめ設定されたスクリプトとプラグインの置き場所を確認しにいく、そして新しいスクリプトが無いかを自分に確認する。
このときプラグインは、自分自身をPDBに対して宣言する。そしてメニュー構造か入出力パラメータの中で、求められる位置情報のようなものを送り出す。
スクリプトかプラグインが他のプラグインを使いたい時、PDBを通して得る。PDBはユーザが意識しないレベルで一方から、または他方からのパラメータの伝達を管理する。
プラグインから操作できる内部関数は、coreでまずまとめられなければならない。coreはPDBでその関数を登録し、次にlibgimpがそれらを通常の関数のように呼ばれるようにする。
以下、まず最初のプラグインとしてHello, Worldを作ってみよう。
簡単なGIMPプラグインをコンパイルできるようにするには、libgimp headerと、GIMP関連ユーティリティであるgimptoolが必要である。
このユーティリティによって、プラグインを個人のディレクトリ(~/.gimp-2.0/plug-ins)か、システムのデフォルトディレクトリのどちらかにインストールできるようになる。
書式は以下の通りである。
gimptool --install plugin.c or gimptool --install-admin plugin.c
このユーティリティはオプションによってインストールスクリプトになれば、プラグインをアンインストールするのにも使える。
GIMPプラグインは通常、3つの異なる振る舞いをする。エッジ検出のように、プラグインは画像データを取得し、それを修正し、そして修正された画像を返すことができる。またいくつかのscript-fuやjpeg画像読み込みプラグインといったファイル読み込みプラグインのように、画像を生成して返すこともできる。そして、ファイル保存プラグインのように画像を取得し、対象データを修正することなく処理を行うものもある。
#include <libgimp/gimp.h>
このヘッダーは全ての基本的なプラグインの要素を利用可能にしてくれる。
GimpPlugInInfo PLUG_IN_INFO = { init, quit, query, run };
このstructureはPLUG_IN_INFOという名前を持たなければならない。このstructureは、4つの関数へのポインタを含んでいる、この関数はプラグインの生成と同時に呼び出される。initとquitはオプショナル(あってもなくても良い)である、必要でないときはNULLを与えておけば良い、しかし最後の二つは必ず必要である。
init()関数はGIMPが起動したときに呼び出される。この関数は通常使われない。プラグインの中には、init()関数を、コアが行わない補助的な検索をするために使うものもある。init()関数は標準的なGIMPプラグインでは使われていない。しかし役立つこともある、例えば、いくつかのファイルのあるところから条件付でprocedure(手続き)を登録したい場合などに使える。
quit()関数はほとんどのプラグインで使われていない。quit()関数は、リソースを解放するためにGIMP終了時に呼び出される。quit()関数はscript-fuプラグインの中で使われている。
query()関数は、そのプラグインが初めて現れたとき(インストールされたとき)呼び出される。プラグインが変更されたときも同様に呼び出される。
run()関数は、プラグインの中で中心となるものである。run()関数はプラグインが実行するかどうかたずねられたとき呼び出される。run ()関数は、対話的な方法を始めるかスクリプトによって、その時決定されるプラグイン名(プラグインがいくつかの手続きを登録するように)、入力パラメータや出力パラメータへのポインタを取得する。関数のプロトタイプを以下に示す。
void run (const gchar *name, gint nparams, const GimpParam *param, gint *nreturn_vals, GimpParam **return_vals);
MAINはCのマクロである。引数の初期化を行うおまじないである。これによって、PLUG_IN_INFOを適切なタイミングで呼び出すことができる。プラグインには必要な処理である。
query()は登録手続きと、入力引数の定義を扱う。これらの情報は立ち上がり時間を短縮するために保存され、プラグインに変更があった場合のみ再読み込みされる。
今回作成する"Hello World!"プラグインのquery()関数は次のようになる。
static void query (void) { ... }
GimpParamDefは3つの事柄を含んでいる。一つ目は引数の型、二つ目はその名前、三つ目はパラメータに関する記述である。
gimp_install_procedureはprocedure名、いくらかの記述とヘルプとなる文字列、プラグインがどこに入るべきかを示すメニューのパスを定義する。
"RGB*, GRAY*"という記述は、処理されたimageの型を宣言する。この記述はRGB, INDEXED または GRAY を選択できる、この時アルファ値を持たせたりすることもできる。つまり、"RGB*, GRAY*"はRGB, RGBA, GRAYまたはGRAYのimageの型を表している。
"GIMP_PLUGIN"は、このprocedureを外部対応するために宣言する、そしてGIMPのコアで実行されない。
ではrun()関数の殻を追加して、必要な要素を持たせたプラグインを確認してみる、そして、"Xtns->Plug-in Details"でPDBに登録されるか確認する。
PLUG_IN_INFOで求められているもう一つの関数がrun()である。プラグインの中心はrun()である。
出力値(プロトタイプでの return_vals)は、少なくともプラグインの状態に関係する一つの値は持つべきである。通常、この変数は"GIMP_PDB_SUCCESS"で保持するだろう。
Run-mode プラグインは様々なやり方で動作させることができる。GIMPを対話的に動作させているなら(通常起動)、GIMPメニューから動作させることができる、またscriptやbatchとして(まとめて)処理できるし、"フィルタ->再適用"としても使える。
入力引数"run_mode"は次の中から一つ適用できる。:"GIMP_RUN_INTERACTIVE", "GIMP_RUN_NONINTERACTIVE", "GIMP_RUN_WITH_LAST_VALS".
"GIMP_RUN_INTERACTIVE"は通常、オプションダイアログを生成する唯一のケースである、生成しない場合、直接入力引数かメモリの値を利用し処理を呼び出す。
今回のテストプラグインでは、単純に"Hello, World!"というメッセージを含むダイアログを表示するようにする。嬉しいことに、これはGTK+ではとても簡単なことである。以下にその関数を示す。
static void run(const gchar *name, ... { ... }
プラグインを走らせてみると、以下のように動作する。
次回は、より役立つプラグインを作成する。プラグインでimageデータを受け取るやり方を扱う。プラグインをよりよく使う為に、タイルを詰めていく画像処理を扱うことで、GIMPのimage構造をどのように使うのか示す。
この和訳文書はcreative commons : 帰属 - 非営利 - 同一条件許諾 2.5でライセンスされてます。
(2005/11/12 追記)2P目の私的和訳を以下のリンク先に作成しました。
tdiaryの形式にたぶん合わせて書いてみたけど、これじゃあRSSアグリゲータで見てたりすると項目が不自然に増えてしまうなぁ...。やっぱり別ページにしよう。
いくつかの印刷所が冬コミスケジュールを出していた、目標は12月第二週頭あたりやね。
土日はもう一本分のネタ出しをしていたけど、ダラダラして全然生産的じゃなくて結構後悔。うーん、結局大学院の時から何も変わっていないんだなぁ、〆切が近づかないと始めない大学の時の癖も直ってないしね...。どうにかしないと。
とりあえずネタだし時間切れ、thunderbirdをネタにした漫画は無しになりましたとさ。ベイズ定理を使ったSPAMフィルタをネタにしようと思ったけど、解説ネタとして裏をちゃんととれるほどソースを読めていないので断念。うまく説明できるかどうかなんて問題は描く描かないの基準としては重要度は低いけど、まがりなりにも"解説"として書くには手持ちの知識が少なすぎる。
今週末までにはネームきりたい。というわけで、今後は更新が少なくなる予定。作業中はほんとネタにすることが無いけんね。
今日は有給とりました、が相変わらず計画が立てられるダラダラと"何か"をしている感じで原稿は進んでいません。大学の時にはっきり見えて、大学院で悪化した「計画を立てられない」は未だ健在です...orz。
今日は計画をたてることにさえとても時間がかかってしまった。で、その時研修中によく言われたことを思い出しました。それが、「アウトプットをはっきりイメージしてからとりかかる」です。
アウトプットとはここでは計画の書かれたドキュメントです。上の意味は、計画をたてるというのは「何時なにをやるかはっきりさせる」だけではなく、「何時何をやって、その成果物がどんなモノになるのかをはっきりさせる」ことだということです。
計画を立てる場合、「このページにいつまでに何をどうやって書くか」をはっきりさせることが大切だということになります。これも研修でやった5W1Hです。
よく言われる当たり前のことですが、未だに継続して実践できていません。こうやって書くのも自分への確認だったりします。そして継続できるまで繰り返し実践するように努力すること > 自分。
まだ寝るまで時間はある。凹まないで前にすすむ!
99年2月に出た本です。買った理由はただ一つ!憧れの人が記事を描いているからー。
今の環境に慣れると昔のスペックが信じられなくなりますが、そういうところも見所か!?(ぇ
よくトイレで立ったりして全然落ち着いていない人間です。おかげで、作業を再開する為に必要な時間がかさんでしょうがない。
机にしがみつくという言葉は今まで好きではなくて、全然気分転換をしないで息がつまりそうなイメージだったんですが、そういう意味では無い気が今日しました。ずっとしがみついているのではなく、まとまるまでは絶対に手を休めないという強い意志の表れと捉えるべきなのではと思います。
大小は別にして一つのことを何かしらの形でまとまるまでに手を休めたりすると手を休める直前の状態に戻すのにもう一回最初から頭の中を辿らないといけないためとても非効率的です。なので、まとまった(くどいけど大小は関係なく)形で結論をかけるまではとにかく作業をするべきです。現実逃避への誘惑にも負けそうになりますが、それにも負けずとにかく作業にだけ目を向けることが大切です。集中しているわけでは無いですが、気を散らすわけでもありません、それで十分だと思います。
このまとめるまでの時間が長すぎては意味が無く、この時間を計画によって自制できるギリギリの時間単位に区切らないといけません。
あぁあと、自分に足らないのは集中力ではなく、「集中しようとする意志」な気もしたりしてきています。
というわけで、なんとかして自制するように心がけたい。前向きに考えることも考えないと。
同居人からの指摘によってウィルスにかかってることが発覚、以前avastを使っていたけど、無料ライセンスの更新が面倒で消してたのが良くなかった気、まぁノートで使うには重すぎるというのもあったけど。いかんね、こんなことじゃ。というわけで軽さと検出力で定評のあるNOD32を購入。確かに常駐させている重さを感じない。
後は前から欲しいと思っていた本達、Project SEVENはやねうらお氏のblogで知って著者の経歴を見て結構本格的な小説かなぁと感じて購入。
萌えよ戦車学校を買うとき思ったけど、その道に興味の無い人ってちょっと戦車格好良いよねというとすぐミリオタかと言ってくるし、ちょっとSLの写真を撮りに行っただけで鉄オタを思ってくるし。おいらは全然そんな極まってないよーと言いたい。とか思ったけど、オタクかどうかって本人がどうかではなくて、他人がその人をどう思うかでオタクかどうかってのは定義されるのかなぁと思った。だから、「俺はオタクじゃない」と言うのは意味を成さないのかなぁ。