みねこあ

mineko. A! ―from mi-neko online.

2010-01-26

未来と言うより今がヤバイです 00:55 未来と言うより今がヤバイですを含むブックマーク

ちょっとだけ。わたしの目に見える範囲のことだから、一般化するのはアレだと思うけれど、書くだけ書いてみます。

「日本のIT業界に未来がない」のはデフォ - カレーなる辛口Javaな転職日記

かつてアウトソーシングなんて喧伝してた「特定派遣」なのだけれど、そう言う会社の稼働率(仕事のある社員の割合)は、だいたい6〜7割台くらいになっているそうです。会社としては稼働率が9割を超えないと赤になる感じなので、血を流しつつも、景気が回復するのを待ち、堪え忍ぶフェーズ。

9割超えるような稼働率を出している会社もあるにはあるのだけれど、そっちは整理解雇に踏み切ったところ。会社を守るために背に腹は代えられず..というところで、こちらは焼き畑農業的。だけれど、ちょっと切りすぎてしまっている感もあって「魍魎の匣」よろしく、延命のために手足を切って内蔵を摘出しちゃっているような状況。経営陣も管理職も人事も技術も、誰も人を切りたくないと思っているけれど、切らないと生き残れないので、切り続けている感じ。とても「健全」とは言えない・・というか健全に戻れるのか?

このまま景気が回復しないと、耐えているところも早々に整理解雇に踏み切るような気がします。3月危機とか来るのかな?切っているところも切りすぎ自滅してしまいそう。・・・どちらにせよ、このレイヤは酷いことになってます。


請負で仕事回す会社の層もちょっと危なそう。こちらも社員に回しきれる十分な仕事を確保できてないところが目立ってきました。特に組み込み系はかなりマズい状況かも。製造派遣が失業して派遣村が話題になった頃に、開発ラインもバンバン閉じられたのだけれど、1年たっても殆どが閉じたまんま。で、そうこうしてるうちに自然に(予定通り)終わるプロジェクトが出てきて、そういう人達の次の仕事が取れない・・みたいな。真綿で首をジワジワと。

Open系のほうがまだ状況はよいかな?と言う風に見えて(となりの芝かもしれないけれど)、こちらは不景気の出会い頭の一撃がそれほどではなかったようで、組み込みに比べれば、まだ「職にあぶれる感」は低い感触。ただ、仕事があるところも安泰とはほど遠くって、お金がないので人が増やせないから 超労働してる話もよく聞くし、一時期 本当に少なくなった「サービス残業」が息を吹き返した話をあちこちで聞きます。

そのほか、「有給を使わないで令」「せこせこした経費削減」「臨時休業日を増やして給料カット」みたいな せこい話が良く耳に入るようになってきてるので、お腹の中は結構厳しいのかもしれません。



大手SIer みたいなのは、どうなのでしょうか?わたしはカーストの底辺の方のエンジニアなので、友人からいろいろ聞いたりはするものの、んー、遠すぎてちょっと感触としてわかりません。

あと、電気・機械系のエンジニアさんとかの 仕事のなさは、ソフト屋さん以上と言う話も聞きます。


* * *


わたしも、周りを見回した感想として、

マジでやばい。



このまま不況が続けばどんどん会社潰れるだろ。

大手も全く仕事が無い奴を大量に抱えて相当やばいはず。

404 Not Found | このページは存在しないか、すでに削除されています

という、危機感を持っています。遠くまで見渡せているわけじゃないので、全部がそうなのか、たまたま自分の周辺だけなのかはわかりませんが(特にわたしは底辺よりですしね)、見える範囲を見てると、本当にヤバく感じます。

これはブラックかどうかとは別の話。たとえば SIer も派遣屋さんもブラックですが、会社としては ブラック同士で Win-Win、エンジニアだけ涙目 みたいな感じだったのですが、今は ロケットの多段切り離しみたいに 会社をプレイヤーにしたイス取りゲームが進行中、みたいな。

ブラックな方向な話では、給料は凄い下がってヤバいくらいだし、サービス残業は増えるし、3ヶ月後に職があるのか?という不安が荒唐無稽じゃぜんぜんないし。

特定派遣の会社だと、仕事が無くなるとすぐ首切って、その人が出来る仕事が取れたら再雇用・・みたいな恐ろしい話も聞ききます。解雇されて3ヶ月たっても6ヶ月たっても就職できないって人が多いから、こんなことが出来てしまうという。一応正社員だから仕事がない間も給料がでるのが特定派遣なのに、そんなことしたらタダの派遣になっちゃうじゃん?・・と思うのですが、本人にしてみれば、それでも無職でいるより声を掛けてくれた方がありがたいから、ある意味利害が一致してしまう、みたいな。そんな怖い話もいっぱいです。



・・・すみません。愚痴です。社会的にドウとか経済的にコウとかの話では全くなくて、単に「王様の耳はロバの耳」と、はてな穴に叫びたかっただけなんです。

2010-01-25

[]マリア様がみてる -私の巣(マイネスト) 21:17 マリア様がみてる -私の巣(マイネスト)を含むブックマーク

ごきげんようごきげんよう!

一言で言えば、凄く良かったし嬉しかった、マリみての最新刊。もう番外短編集しか出ないかと思ってました。

マリア様がみてる 35 私の巣(マイネスト) (コバルト文庫)

マリア様がみてる 35 私の巣(マイネスト) (コバルト文庫)

今回は、山百合会と関係のない一生徒・・じゃなかった、一姉妹で、でまるまる一冊という破格の扱い。そしてそのキャラがまた魅力的なんだ。百っちに、環さま。・・特に環さまが良い味を出しすぎてます。(呼び名「タマちゃん」が採用されなかったのが残念すぎです)

なんかもう、これで マリみて は あと10年は戦えるっ!・・って、実感してしまいました。

[]戦う司書と世界の力 21:17 戦う司書と世界の力を含むブックマーク

大好きな戦う司書シリーズもこれで完結。前巻がとても良い感じて引っ張っていたので、気になって気になってしかたがない最終刊でした。

戦う司書と世界の力 BOOK10 (スーパーダッシュ文庫)

戦う司書と世界の力 BOOK10 (スーパーダッシュ文庫)

読了してみての一番の感想は、戦う司書シリーズが急に色あせて感じたしまったこと。いいえ、最後で台無しにした、と言う意味ではありません。むしろ期待通りの最終巻でした。素晴らしいかった。でしたが、それだけに、きちんと、すっぱり、綺麗に終わってしまった。本当に何もかも終わってしまったのです。

立つ鳥跡を濁さず、じゃないですけれど、心になんの引っかかり(傷)も残さず、リークもなしに綺麗にガベージコレクトしてしまったというか。上手く言えないのだけれど、わたしは恐らく当分は戦う司書シリーズを読み返すことはないでしょう。

この終わらせ方が良くないという訳じゃないのです。ただ贅沢なんです。ほんのちょっとの食べ残し感、終わりの漏れをほしがる自分に気がつきます。もちろん山形さんもそれはわかっていて、でもマットアラストのエピソードは「食べ残させる」には少し足りない。うーん、物語の終わらせ方というのは、本当に難しいモノだとも思いました。(そう言う意味で「恋する爆弾」は絶妙でした)

この最終巻を読んで思い出したのは、皆川ゆか さんの ティーパーティーシリーズの最終巻、「ティーパーティー 我らこの世界を愛す」です。

ここまでの大団円で終わらせてる、そんな意味でとてもよく似た雰囲気の終わらせ方でしたが、ティーパーティーは後を引きます。戦う司書は後を引かない。そうして、はじめてティーパーティーの終わらせ方が絶妙なさじ加減であったことをいまさらながら知るのです。

[]君が僕を2 -私のどこが好き? 21:17 君が僕を2 -私のどこが好き?を含むブックマーク

百合です。相変わらずの圧倒的な文章力で読者を翻弄する中里十さんですが、今回は「どうしちゃったの?」とも思ってしまった。

君が僕を 2 (ガガガ文庫)

君が僕を 2 (ガガガ文庫)

中里十さんの小説は、いつもとてもレビューが難しくって、何故かというと、どこが面白いのかを自分でも説明できない。というかなんの話なのかも説明するのが難しい。なのに、確かに面白い感じている(思っている・・だと、違うニュアンスになっちゃうんですよね)自分がいて、繰り返し繰り返し読んでしまうと。

多分言葉には魔力があって、「言葉で物語を記述して、その物語が心を動かす」という正攻法の他に、直接わたしの脳に言葉で魔法をかけて、直接心を動かしてしまう、そんな風に感じるというか。(「空前絶後」のような魔術を想像してくだせい。「言語野の中里」みたいな)


けれど、今回は説明が出来てしまう。その説明が出来てしまうこと自体が罠(というか魔術的トラップ)でないかと疑ってしまう。

とにかく、とても面白かった反面、中里さんがこんな話を作るなんて、と言うこと自体が恐ろしい。

P.S.

こう書くと、まるで普通のお話のだったように見えてしまうけれど、いえいえ。良くこんな話を作れる(思いつける)モノだという凄みがある、相変わらずの中里式です。読み進めても読み進めても、全然先の予想が付かない。

ねぇ、「私のどこが好き?」と聞かれたら、あなただったらどうします?

マンガ コミック情報マンガ コミック情報 2010/03/09 15:34
携帯で無料&簡単に画像が読み放題です!
会員登録もありません!
FAIRYTAIL?エアギア?あねどきっの人気マンガ作品も充実!!
一度遊びに来て下さい!!
詳細はこちらになります▽

君と僕。 画像
http://comic.fansfree.com/gfantasy/kimitoboku/

戯言シリーズ 画像
http://comic.fansfree.com/lightnovel/zaregoto/

夢色パティシエール 画像
http://comic.fansfree.com/ribon/yumeiro/

ハヤテのごとく! 画像
http://comic.fansfree.com/sunday/hayate/

2010-01-23

つれづれ 00:43 つれづれを含むブックマーク

その200

InC-EPL
キーッと韓国語に韓国語にキーッeToysのバージョン*国際*国際怠け者のバ...
j2meSqueak
これは任意のj2meの携帯電話の対応にキーッ実現のためのプロジェクトで...
Squeak
キーッ、移植性の高いSmalltalkの80の実装、およびネットワークアクセス...
スラド -- アレゲなニュースと雑談サイト

を見て、思わず職場で吹き出してしまいました。完全に変な人です...orz

当然自動翻訳のせいなのだけれど、他の部分の翻訳がそこそこなので余計目立ちます、キーッ。

その201

LLな板で珍しく長いSmalltalkなお話

386 :デフォルトの名無しさん:2010/01/18(月) 14:06:48
Smalltalkなんて使ってるヤツいるのか 


387 :デフォルトの名無しさん:2010/01/18(月) 14:14:27
学校ではよく使われる 

388 :デフォルトの名無しさん:2010/01/18(月) 14:50:11
青木さんの居る会社では今でも使われてると思う 

389 :デフォルトの名無しさん:2010/01/18(月) 15:04:37
Smalltalkとguile仕事で使っているのはどっちが多いんだろ。 
いずれにしてもものすごくマイナーだろうな。 

390 :デフォルトの名無しさん:2010/01/18(月) 22:20:24
どちらにしても超高効率で使用されてるのは間違いない 
他の言語による製作では追いつけない程度のクオリティ 

391 :デフォルトの名無しさん:2010/01/18(月) 22:26:07
Smalltalkというと、オブジェクト指向の元祖ではあるが、「もはや他の言語に 
凌駕され使われなくなった古い言語」、もしくは「学術の世界でのみかろうじて 
生き残っている言語」という印象があるかと思います。しかし実際には 
Smalltalkならではの強みを活かしたシステム開発事例がしっかりと存在します。 
守秘義務などで見えにくくなっているだけです。 

392 :デフォルトの名無しさん:2010/01/18(月) 22:57:53
まったくこれだからマイナーな言語の信奉者は。 
ネタで書いたんだろ。分かってるよ。 

393 :デフォルトの名無しさん:2010/01/18(月) 23:06:56
>>392 
的外れなこと書くのが恐かったのはわかるが 
両立できない1行レスを両方とも書くなw 

394 :デフォルトの名無しさん:2010/01/18(月) 23:19:30
GoogleのBigTableに対咬してBigTalkでも作るんだな 
もしくはBigMouth 

395 :デフォルトの名無しさん:2010/01/18(月) 23:26:31
BigMouthはgo 

396 :デフォルトの名無しさん:2010/01/19(火) 00:29:38
>>392,394 
つ http://sites.google.com/a/smalltalk-users.jp/home/Home/gao-zhi/dai13kaismalltalkbenkyoukai 

397 :デフォルトの名無しさん:2010/01/19(火) 09:37:15
SmallTalkは頭のいい人がきちんと使うと威力が大きい 
ただ、俺らには無理だから教養程度にしておいて 
他の普通の言語でのろのろ作ろうぜ 
【Perl,PHP】LLバトルロワイヤル8【Ruby,Python】

Smalltalkって、商用の開発環境とかツールとか関連製品とかは凄くいろいろ目にします。ツールが商売として成り立つってことは使われているハズ。けれども、それを使って開発している方々とか、開発されたモノとかか、本当に目に付かないというか、全然見つけられない。そこら辺のアンバランスさがなんとも不思議ちゃんです。何処に隠れたっ!

本当、今 Smalltalk で食べている人ってどれくらいいるんでしょう。


その202

そんなことが気になるのは、いいとこ見つかったらいってしまおうかと思いながら、半分くらい本気で、求人ウォッチしているからで。組み込みSmalltalkのお仕事とかあったら最高なのに。

そういえば、組み込みSmalltalk OSVM ですけれど、少し見ないうちに CloudRunner と言う なんともbuzzい・・ゲフンゲフン、もといナウい名前になっていて、ビックリしました。


その203

artonさんちのコメント経由、ガスコンロの規制が変わります! - [キッチン]All About

知りませんでした。

個人的には、鍋が無いと火がつかないとか、いけてないと思います(とはいえ、単純に使いにくくならないよう、この手の false positive を減らすような工夫がいろいろとこらされているのでしょう、きっと)

これについては、不自由を質に安全を手に入れた、という見方が出来るかどうかだとおもうのですが、

250度でセンサーが働くために、調理できないメニューもいろいろ考えられるが、ハイカット温調やセンサー解除ボタンの利用によって、その問題も解決するという。しかし家庭料理を調理中に、あちらこちらのボタンを間違いなく操作しながらタイミングのいい料理ができるのだろうか?

ガスコンロの規制が変わります! [キッチン] All About

任意安全装置の5番目には「鍋なし検知装置」という鍋をのせていないと点火できない安全装置があるが、ガスコンロの調理は必ずしも鍋をのせて加熱するだけでなく、「炙る(あぶる)」という調理法もある。こんな加熱をしたい時は、やはりセンサー解除をするのだろうか?

ガスコンロの規制が変わります! [キッチン] All About

をみると、サイバークロスカウンター風に思えて、あやしい。「我々は万全の安全装置をつけました」「解除したユーザが悪い」ってなりそう。かなーり、建前だけの安全対策に思えます。更には、

端的にいえば、規制をクリアしたリンナイ、ハーマン、パロマの3社のガスコンロから限られた商品を選ぶしか余地が無くなる訳だ。

ガスコンロの規制が変わります! [キッチン] All About

みたいなことになれば、囲い込みをしているんじゃないかという 穿った見方をしてしまう。


* * *


ネガティブなことを書いてきましたが、これでもかっ、てくらい安全対策のついたハイテクガスコンロってのがあるのは、良いと思うのです。使いにくかったら売れないだけだし、使いやすくって安全だったら嬉しいでしょう?イザ使ったら戻れなくなる便利さかもしれない。

ただ、これが法で規制されるとなると、とたんに「使いやすくって安全」を期待する気になれなくなるのですよね。

だって、タスポとか、ちょっと前の 電気用品安全法(PSE)とか、こういうシステムとして機能しないシステム、すっごくよく目にするもん。「いまのガスコンロはこんなに多機能」とかだったら気にならなかったのに、「法規制」と聞くと、わたしの眼鏡は色は付いていないつもりなんだけれど、どんどんサングラスになっていくんだな、これが。


その204

日本って「標準的人間像」からはみ出したら、本人に問題があるみたいなところって多いと思う。「世界に一つだけの花」とかを「いいね」と思いつつも、自分が理解できないってだけで、「キモい」と根絶する。それどころか「悪」のレッテルを貼られる。

理解できない人が隣にいると、「イヤだ」とか「怖い」とか感じるのは、感情としてはわかる。だけれどそれは、偏見で差別だ、ということを知っている・・・というのがバランスだと思うけれど、そういう風に捉えられる人が多数はではないように感じる。問題はそこだ。排斥大好きならそう言えばいいのに。

自分は多様性を認めているという顔をしながらも、「世界に一つだけのラフレシア」みたいなのが想像できてない。そんなので個性を語っている。「綺麗でなければ花に非ず」という価値観で動いているのに気がついていないから、残酷になれるだと思う。

なんか抽象的で判りにくいですね。そう、たとえば。競争で脱落するのは「かわいそう」でも、方向性は絶対に揃って無くちゃいけないのでそういうのは「排斥」(または「矯正」)するのが良いことだ、みたいな。それを「個性」という文脈で語るのが...orz だというか。大きさには寛容(..というより着目してはいけない)のに方向には不寛容。個性はベクトルなのに。

まぁ、そういう空気(?) があるから、ちょっと変わった趣味ややり方について、それが出来なくなってしまう法律とかを平気でバンバン作ってしまう。生粋のオタクとしては、そう感じずに居られません。


その205

フィルムが...(T△T

富士フイルムプロフェッショナル製品一部製造販売終了のお知らせ 2010.1.21

【モノクロフィルム】

ネオパンアクロス100 135-24、120、プレスト400 120、スーパープレスト1600 135-24、アクロス100 11×14(特注品)他

【プロフェッショナルカラーネガフィルム】

プロ400 120、プロ160NS 120、リアラACE 120、プロ160 NC 120他

【プロフェッショナルリバーサルフィルム】

ベルビア50 120(シングル/20ロール)、ベルビア100F 120(シングル/20ロール)、ベルビア100 120(シングル/20ロール)、

プロビア100F 120(シングル/20ロール)、アスティア100F 120(シングル/20ロール)、プロビア400X 120(シングル/20ロール)、

64T 4×5、64T 4×5 QL、64T 8×10他

ナショナル・フォート製品情報 最新の銀塩感材ニュース

120フィルムがガンガン整理されてる。な、なぜ...。

追記

って、今見たら情報が削除されてます。誤報かしらん?だったら嬉しいです。

さらに追記

俺のカメラ趣味。俺の自己満足。」のarataさんが電凸してくれた模様。

「お客様相談室」に尋ねてみますた。「販売店からの情報がネットに流れていて,不安なんですが,どーょ?って」

  • 正式発表は1月28日にするわよ。
  • 120がなくなることは無くて,基本的に3本パックとか5本パック等のまとめ売りになるわよ。
  • 135も基本的に上と同じよ。
404 Not Found

ふみー。買えなくなるのではないのだけれど、まとめ買いしかできないのは痛いです。高くなってなかなか手が出にくくなりますし、いろんなフィルムを試すハードルが高くなります。こうなったらピン売りな無くなる前に、買いだめしておこうかしら(←意味ないジャン


その206

15×24 は 蓬莱学園の人のだよ、と聞いて、読んでみたいな、とおもったのだけれど、アレレ?、肝心の「蓬莱学園」の内容が全然思い出せない。

・・・あたしの書庫にあったかしら。借りただけな気もするけれど、なんとなく宇宙皇子の裏あたりに閉まってあるような気がします。むー、発掘を試みるべきか。

その207

26. ほとんど SF 的な交通網

都内の重要地区と近郊都市を結ぶ首都高速道路(首都高)は、地上数十メートルもの高さに位置し、ビルの隙間を潜り抜けるように走る。こんな斬新なデザインは日本以外では考えられない。 複雑に結ばれた数知れぬ路線、地上にも地下にもある出入口、そしてニュルブルクリンク(Nurburgring:超難関コースで知られるドイツにあるサーキット)も顔負けの急カーブ等、首都高は建築設計の観点からも驚異的なだけではなく、交通・物流的にも異次元的だ。

no title

意識してなかったけれど、言われてみればもっともです。

昔品川で働いていたとき、仕事で深夜首都高で返ってきた後(送ってもらった)、家で Dreamcast の 首都高バトルでストレスを癒すのが好きでした。(次の日も仕事なのに)

その208

1月26日にNHK BSハイビジョンで、「ハイビジョン特集 シリーズ東京モダン『萌えの心臓』」という同人誌なドキュメンタリーが放映されるとのこと。

インド人映像作家バラットゥ・ムルティが同人誌の世界を追うドキュメンタリーだ。コミケで出会った2人の主婦同人作家に描き続ける理由を問い、萌え人気、BL人気、腐女子ブームなどの秘密に迫る。

萩尾望都出演のドキュメンタリー番組。同人の世界を語る - コミックナタリー

うわ、おもしろそう。しかも、この中に萩尾望都さんが出演するそうで。

萩尾は初期の同人世界を知る人物としてインタビューパートに登場。

萩尾望都出演のドキュメンタリー番組。同人の世界を語る - コミックナタリー

見たいなー。でも、NHK BSハイビジョンじゃ、わたし見れない。

残念〜(>_<


その209

【職場観覧注意】空港の全身スキャナーからフルヌード写真集 : Gizmodo Japan

まさに科学の勝利ですね、うん!


その210

リコーGXR開発インタビュー

夢と苦労を詰め込んだGXRの設計

GXR が GX × XR だなんて初耳ですよ! ...これは盲点。


その211

Slashdot.jp より、MINIGURUというトラックポイント付きHHKB風キーボード。

– The Miniguru – Always on the Home Row

f:id:minekoa:20100124004031j:image

no title

これじゃ最早、買わないという選択肢がありえません。

問題は、何台買うかというところにあります。注文時にいろいろ構成が選べるのが悩みどころ。とりあえず、茶軸と赤軸、水平Enter と 垂直Enter は欲しいなー。

Comming soon 2010 4Q とのこと。はやくコイコイ♪



その212

unlessのつかいかた

A, unless B.

「Aです。でもBすれば、話は別です。」

よし、これなら、ピンとくる。

苦手なunless:MBAマッチョ日記

おーっ。なんだかストンと来ました。

2010-01-19

つれづれ 00:25 つれづれを含むブックマーク

その188

コミックサイエンス撲滅委員会ですが、どうも「買ってはいけない」と同じ臭いを感じるんですよね。

幻影随想: トンデモ本「買ってはいけない」とその著者の近況


彼らの言動には「ひょっとして、実験をしたこともそのレポートを書いたことも無いのじゃないかしら」と思ってしまうくらい、科学に親しんでるにしては違和感ありまくりです。

始めに結論(オレが正しい)ありきでそれを論理武装する姿ですとか(そのためにフラフラと言ってることが揺れて整合性が端から欠けていく)、どうも「科学」をアプローチじゃなくって「命題」に適用している風だとか、彼らからはむしろニセ科学文化のほうを感じてしまう。

前回「お里が知れる」と言ったのはそんなところで、だから誰の目にもダメダメなのは明らかよね(とりあわないよね)と思っていたのですが、予想外に世間は彼らを「ちょっとイけてないニセ科学批判者」と捉えてしまっている様子。もっと「ニセ・ニセ科学批判者」とフルボッコになるかと思ってた。


そういう背景に「買ってはいけない」をなんとなく連想してしまうわたしです。


その189

3分間クッキングメソッドでコッソリちょろちょろコードを書いていたわたしですが、最近はいよいよ SE(笑) となってしまってきていて、気がつけば、もう一月以上も仕事でコードを書いていません。

来る日も来る日もWordWordExcelWord*1。うがーっ、わたしにコードを書かせろー。書かせろー。書かせろー。...安西センセ、コードが書きたいです。

そこで思い出したのが、わたしが社会人2年目くらいのとき、超残業モードで働いてる側で「トラブル起きないかなー。そしたら俺もコード書けるのに」と宣っていた課長がおりまして、当時は「殺してやる殺してやる殺してやる殺してや...」と思ったモノでしたが、今ならその気持ちがわかります。

そう言えば、「お前が開発するな」とよく部長に説教喰らってる課長でした。


その190

結構前からなのですが、なんだか品質改善と称して、わたしたちのコードに 静的コード解析ツール PGRelief をかけることになって、「別部署」がそれを担当することになったのですが、そこ上がってくるレポートが酷い。

たとえば、

int func(){
    if (...){ return 42; }
    else { throw domain_error("fugafuga"); }
}

みたいなのでで、return が無いって言うし、

if ("hoghoge" == aString){
      ...
}

も、不正な比較っていう。(String に限らず、演算子のオーバーロード全般ダメ)

単に C としてチェックしているように思えるのですが、彼らはちゃんと C++ としてチェックしたと言う。これが本当なら、false positive が多すぎてツールとして全然使い物にならないのですが、なんぼなんぼでも商用ですし、ソレはないんじゃないかな、と思います。やっぱり設定ミスじゃない?(けれどそれだと、その前に構文解析エラーになるんじゃない?と疑問におもわなくもない)

これをそのまま上げてしまう「別部署」もいろんな意味で問題だけれども(Cしかわからない人達でした)、「設定が間違ってるんじゃない?」という言い分には納得いただいて、もう少し設定を調べてもらう、ということになり、いったん話はクローズしまいた。

けれど半年以上たっても改善されず、そればかりか、横紙破りが「コードの方を直せ」みたいなことを言いだし始めているみたいで、ちょっと先行きがどんより。


十中八九使い方が悪い..と思いつつも、こころのどこかで PGRelief を信頼しきれないわたしがいて、富士通の人が私的に作った C用のツールを、商売っ気だして外部売っちゃった・・というルーツとかと併せて「『C++対応』というのもC++ の構文的なところで転けなくしただけで、解析内容は Cと同じなんじゃない?」と疑ってしまうわたしがいます。C++ の静的コード解析ってどれだけ大変なのかというのを想像すると特に..。

と、自分で使ったことがないツールに陰謀論的妄想を炸裂させても仕方がないので、自分で色々試してみようかなと思ったのですが、なんだか藪をつついて仕事をいっぱい背負っちゃいそうだな、と思い直して、ぐぬぬ中。

うーん、累が及んでからで十分かしら。


その191

林晴比古さんの コンパイラ・インタプリタ開発の本、どうなんだろうと気になっていて、なにげにレビューを期待していたのですが(この発言は省略されました)


その192

谷川史子さんの「清々と」がツボでした。

清々と 1 (ヤングキングコミックス)

清々と 1 (ヤングキングコミックス)

あぁぁ、こういうのに弱いのです。


その193

3月いっぱいで現在の現場から去ることになりました。社員余ってるから協力会社を切るという流れの行き着いた先なのです。

どうもわたしはその会社の ほぼ最後の協力社員になっていたらしく、協力会社を例外なく使わない、という社の方針だから、と言う風に説明されたときは、なんというか、不謹慎にもニマニマしてしまいました。「そして誰もいなくなった」が現実のものに。

むー、次の仕事も面白そうなのとれそうにないし、いっそ転職しちゃおうかな。


その194

それはそうと

講演の冒頭、「1970、80年代に起きたソフトウェア・クライシスではソフトウェアの需要が増大し、開発者不足が叫ばれ、大量採用、資格の量産などが行われた。これと同じような状況が組み込み分野でも起きており、最近“組み込みソフトウェア・クライシス”という言葉を目にするようになった」と、飯田氏は現在の組み込み業界をめぐる状況について語った。

no title

って、どこの国の話なのでしょう。もしかしてわたしが井の中の蛙なだけで、日本全体としては組み込みの仕事が余っているのでしょうか。


その195

検査例外の話は、いいたいことは凪瀬さんに全部言われてしまって何も残っていないのです。

オブジェクト指向と型システムの狭間で例外を考える - プログラマーの脳みそ

ただ、根拠のない感覚の話なのですが、Java の検査例外の実装には、正常系と異常系のインターフェイスが癒着しているのが、気に掛かるなぁと感じます。

層というか粒度というか、それが正常系と異常系ってそんなに 1対1 にならないと思うのだけれど、にもかかわらずインターフェイスを解してモジュールがアシュラ男爵になることを強要されるようなイメージ。なんというか、C++的継承が ポリモーフィズムと差分プログラミングを 不可分にしてしまっているのと似た印象?

すみません、ちゃんと考えた話じゃないし、Java は使っていない人なので、我ながらトンチンカンなことを言ってるんじゃないか、と不安爆発です。

ブレインストーミングだとおもって、さらっと流していただけると助かります。


その196

「みねこあ」はもともと「みねこ」という名前が空いてなくて、絶対被らなそうでそれなりに耳に残る名前をと作った 名前なのですけれど、

みねこあネット通販

ビックリです。

どんな名前だって被るときには被るものなのですね〜。


その197

迷った末に値段見て春物ワンピースを諦めた。これに比べたら中古ワークステーションは安いよねっ、UPSも買っちゃおうかなと思った。

Yuki Yugui Sonodaさんのツイート: "迷った末に値段見て春物ワンピースを諦めた。これに比べたら中古ワークステーションは安いよねっ、UPSも買っちゃおうかなと思った。"

は、反則だと思いました。この台詞には「萌え」と呼ぶのも十分でないくらい、こころにグッと来るものがあります。

漫画を一本描けてしまう、というか、ネームを切り始めるわたし。


その198

妹が iPhoneを 買ってご満悦。影響をうけて凄く欲しくなります。でもでも。


その199

今日は父様 の手術だったので、有給休暇をとって病院にいました。ケータイはともかく(わたし 持ってないし)、パソコンが使えないのは辛いところ。依存してるなぁ。

仕方がないので、貯まっていた未読ラノベを持って行ったのですが(技術書は、手術が気になって頭に入らないかな?とか思ってしまったので)、1時間に1冊くらいのペースでしか消化できなくって、読むのが遅くなったな〜、と実感してしまいました。

頭のクロックが下がっているような。年ですね..orz

*1:PowerPoint がない事はよし

田辺田辺 2010/01/20 06:46 > 谷川史子さんの「清々と」がツボでした。
本屋でふと気になり、私も買いました。
ほんわかして良いですよね。

きむら(K)きむら(K) 2010/01/20 21:21 >なにげにレビューを期待していたのですが
もーちょっと時間が欲しいのじゃよブラザー。

minekoaminekoa 2010/01/21 01:25 > 田辺さん
ほんわかにもっと浸りたいのに、4話しかないのであっという間なのが惜しいですよね。10巻でも20巻でも出て欲しい...。


> きむら(K)さん
付箋紙がハリネズミになっているとか とか?じっくりコトコトお待ちしております。

2010-01-16

[]Smart UI について、だらだらと 01:05 Smart UI について、だらだらとを含むブックマーク

昨年のエントリー、 DDDについて、だらだらと からのびのびになってしまいました、 Smart UI アンチパターンについて。

Smart UI アンチパターンは コの業界で非常に目にするパターンで、また、素人が素人のままで仕事が出来てしまう パターンなのですが、その是非を論じる前に、まずはどういうものかを整理したいところです。

一言で言えば、「Smart UI、アンタ良い者なん?悪者なん?」


* * *


DDD の Smart UI “Anti-Pattern” を読んでいると、これは本当にアンチパターンなのかとも思えてきます。

Advantages

  • Productivity is high and immediate for simple applications.

シンプルなアプリを作る上では生産性は超高いし、出来るのも早いよ!

  • Less capable developers can work this way with litte traning.

底辺エンジニアでもちょっとのトレーニングで仕事ができちゃう!

  • Even deficiencies in requirements analysis can be overcome by releasing a prototype to users and then quickly changeing the product to fit their requests.

要件分析が全然ダメダメでも、プロトタイプをリリースし、そいつを足がかりにユーザのワガママ要望に添うよう、チャッチャと製品を整えて完成させる・・なあんて必勝法が使えるのは Smart UI の強み!

  • Applications are decoupled from each over, so that delivery schedules of small modules can be planned relatively accurately. Expending the system with additional, simple behavior can be easy.

アプリケーションが画面毎にぶった切りになってるから、小さなモジュール単位の出荷計画がわりと正しくできちゃう。システムの拡張も、簡単な振る舞いの追加程度なら あっという間。

  • Relational databases work well and provide integration at the deta level.

リレーショナルデータベースは、画面毎にぶつ切りになったアプリを、データレベルで統合するのにとても上手く働く。

  • 4GL tools work well.

4GLツールも上手い具合。

  • When applicatins are handed off, maintenance programmers will be able to quickly redo portions they can't figure out, becase the effects of the changes should be localized to each particular UI.

アプリケーションをリリースした後のこと。メンテナンスプログラマは、奴らが理解できない部分(解決出来なかった部分)があったって、そこだけちょちょいと作り直せちゃいます。だって変更の影響は、ぶった切りされた画面毎に局所化されてるんだもん。

(以上、適当訳)

こうみると「Smart UI」という出来たプロダクトのアーキテクチャの話というよりは、開発プロセスもひっくるめて「画面駆動デザイン」「画面駆動開発」と言ってしまいたいですね。Smart UI には、

  • 形になるのが早い
  • スキルはいらない
  • 要件分析もいらない
  • 画面毎にアプリがぶつ切りなので、
    • 影響は局所化されてて作業依存なし。並列作業可
    • 分割リリース可
    • 画面単位の工数を足せばいいだけなので、見積りが楽ちん
  • アプリケーション全体の統合は RDBMS にお任せ
  • 保守も引き継ぎもテキトーでも何とかなっちゃう

という特徴があります。

われわれプログラマは酷い目にあった経験上 Smart UI を忌み嫌いますが、そんな色眼鏡をハズして特徴だけをシンプルにみると、なかなかイケてるんじゃない?と思ってしまう。スキルに依存しないし、一応のモジュール化もされているので、分割されているメリットは享受できます。「見積りが容易で」「機械的に設計ができて」「誰にでも開発できる」という特徴は、工業化 とも言い換えられるかも。


なんと言っても Smart UI は、ウォーターフォール と開発組織の階層化が進んだ日本的なシステム開発によくマッチします。

「素人は抽象化が難しい」は まつもと さんの言葉ですが、だからドメインモデル分析には確かな技術力(プログラミングの力)が必要です。開発者(プログラマ)の技術力うんぬんの前に、要件分析フェーズが開発者から分断された状況では、見積りや開発に要件分析が必要とされない Smart UI パターンは、非常に心強い味方です。真面目な話、現実問題としてコレしか手がないかもしれない。

そして、実際に開発をするシーンでも、技術力のある開発者を必要としないため、管理者サイドとしては人員の調達が用意で、しかも教育費用が押さえられます。OJT と言う名の事実上の無教育がまかり通るのも、Smart UI という優れた開発パターンのおかげかも。


スーツ的視点では Smart UI は「これでもか!」ってくらい嬉しい特徴のてんこ盛り。しばしば「酷い開発者の巣窟ゆえの現象」として語られる Smart UI ですが、ひょっとしてコの業界は、愚かさ故に水の流れるように Smart UI にたどり着いたのではなく、自らの約束の地として能動的に Smart UI を選んだのかもしれない、、、なぁんて、思っちゃいます。


* * *


とはいえ、われわれプログラマが一見あま〜い Smart UI の「アドバンテージ」を聞いて、反射的にゾワゾワゾワっと身の毛がよだってしまうのは、これがデスマーチを呼び、数多の開発者を鬱病に葬り去ってきた元凶であると知っているからです。正直トラウマ。Smart UIな開発に乗って酷い目にあったプログラマのリストで、歴史の図書館は一杯です。

DDD では Smart UI を Layered Architecture と対になる「アンチパターン」と位置づけているわけで、

Disadvantage

  • Integration of applications is difficult except through the database.

データベースを介さないアプリケーションの統合は、ちょっち難しい。

  • There is no reuse of behavior and no abstraction of the business problem.Business rules have to be duplicated in each operation to which they apply.

振る舞いの再利用もできないし、ビジネス問題の抽象化されてない。ビジネスルールもそれを使っているオペレーション毎に重複してやがる。

  • Rapid prototyping and iteration reach a natural limit because the lack of abstraction limits refactoring options.

ラピッドプロトタイピングやイテレーションは自然と限界を迎える。だって、抽象化不足がリファクタリングの選択肢を制限しちゃうから。

  • Complexity buries you quickly, so the growth path is strictly toward additional simple applications. There is no graceful path to richer behavior.

複雑さがすぐにあなたを覆い尽くす。だから、新たなシンプルアプリケーションを追加するしか拡張への道はない。ようするに、リッチな振る舞いを素直に作る方法はないのだ。(訳、間違ってるかも)

まぁ、一言で言えば、「出来たプログラムはクソ」ということ。


ソフトウェア工学は 一言で言えば「人類と複雑さとの戦いの記録」*1。Smart UI は その強敵「複雑さ」と武器を持たずに体一つでガチンコ対決するようなもので、よく「竹槍でB29と戦う」と喩えられるのもさもありなん、といった感じ。

まぁ、そこを不満に思うのはわたしが戦闘員側(イーッ)だからで、スーツ的には「戦いは数だよ、兄貴」は正しいものの見方かも*2。ところが「全てが上手くいく話」なんてそうそう無いもの。このようなプログラムは「技術的負債」が貯まりまくりな状態で、初期開発は安く上がっても、拡張や保守にやたらとコストがかかります*3。これはスーツとしても美味しくない。

そこをセールストークでつつかれると...。


* * *


ASP.NET が世にデビューしたての頃、わたしは ASP →ASP.NET移行支援のお仕事をしていました。

そこは ASP を使って、Smart UI の極みのような開発をしていましたが、当然マンパワーで押し切るための超残業、収めたプログラムのトラブル多発でその対応での超残業という悲惨な現場でした。

コレでは(コスト的に)いけないということで、ASP.NET の移行の伴って 3層レイヤー構造を導入しようということになりました――エラい人が 日経や Microsoft のセールストーク にそそのかされて、そう思っちゃった(加えてもれなく「OOPは再利用(ry」なトークのおまけ付き)。

で、移行のための諸々をする基盤開発チームとして、外部からお呼ばれした次第です。

主なお仕事は、ASP.NET で「これまでやっていたことが出来るのか調べる」「どのようにつくればいいか標準化する」「標準のフレームワークを準備する」なのですが、難儀だったのが 要件であった 3層レイヤ構造化です。

だって、いままで Smart UI で開発してきて「関数禁止令」にも疑問を感じないで仕事をしてきた開発者軍団ですよ。ツルの一声でそんなことを言われても出来るわけない。「WebUI層とBiz層とData層に分けろ」というけれど、ドメインを分析するとか、プログラムを設計するとか、いままでやったことが全くないから、どうやればいいか想像すらつきません。・・そんなこんなが200余名。

当然 飛び出す話が「誰でも手順に従えば 3層レイヤー設計ができるような、マニュアルを作れ」。けれど、ちょっとまって。マニュアル化できるくらいなら、それってプログラムを作るプログラムを作っちゃえます。 Smart UI のノリだと自然に思えるカモだけど、それが出来たら論文書いちゃうよー。

そんなこんなで「ムリ」と回答したのですが、結果現場に蔓延したのは、各画面での分割を、WebUI層、Biz層、Data層まで貫いた、層状ならぬ賽の目状アーキテクチャーでした...orz*4。だ、誰か、タスケテ。


* * *


結局わたしたちは、まずは 一つの開発チームに絞って、実際の業務チームに参加して OOP導入 することにしました。千里の道も一歩からです。

でも、これまでの開発スタイルより、すごい工数かかるんですよね。ASP→ASP.NET の移行については、保守フェーズでの工数削減の他に、buzzってたOOPのウリ文句で 初期開発フェーズでの工数削減なんかも詠われてたので、エラい人にとって工数がふくらむのは詐欺です。あと「教育っていったって、なんでこんなに時間掛かるの?」という疑問も持ってしまう(これまで Smart UI だったから)。

もともと「設計をしない」Smart UI より ちゃんと設計をする開発が早く作れるわけがないし、「ならば、開発者どもすべてに今すぐ英知を与えてみせろ」も出来るわけがありません。

要件分析にも教育にもお金が掛からないことがSmart UI の旨みなのですから、その旨みを捨てることになると導入時点で認識していなかった、というのがそもそもの敗因です。

彼らも馬鹿ではないから、メリットのないことにはストップがかかります。結局 ASP→ASP.NET 移行計画は白紙に戻り、外部に「移行するよ!」と宣伝してしまった手前、とりあえず拡張子を .asp から .aspx に変更する、ということで 落ち着いたのでした。(すごいオチです)


* * *


以上、Smart UI をやめようとしても、誰も得をしなかった、と言う昔話。

依頼内容からして、もともと失敗する話だったと思います。それでも、今から思えば「Smart UI を止めるのを止めよう」という判断が出来なかったのは、わたし(たち)の失敗だと思う。当時 Smart UI というものが何かを正しく認識できていなくて、Smart UI を Smart UI と認識していない故に 中途半端に Smart UI から抜け出そうとしてかえって悲惨なことになる。そんなアリガチな惨事だったのだと 今は思ってます。


というわけで、いくら Smart UI に欠点があるからといって、責難は成事に非ず。Smart UI にはメリットも多いのですから、ちゃんとそこも含めて理解しなければ、と思います。

いっそ 胸を張って「Smart UI です!」って言えればいいのかな。日経あたりが上手いbuzzwordつくらないかな?「これからは Smart UI で、ソフトウェア開発を工業化」みたいな感じで。そうすれば Smart UI のメリット的なことを目指す企業は迷走しなくてすみますし、会社を選ぶときも うまく企業がタグづけされたりして、選びやすくなると思ったり。(妄想)


わたしはもちろん「そんな企業は選ばない」を選択するぜっ!・・・て、持ち上げといて、最後の最後で落としてゴメン。


おすすめ

Smart UI については こちらのエントリが秀逸です。

なんていうか、格好いいなぁ。


追記

まさか まつもとさんにつぶやかれるとは思っていなかった。超ビックリです。

「素人に抽象化は難しい」ってのに完璧に同意するけど、私自身の発言だっけ?

Yukihiro Matsumotoさんのツイート: "http://d.hatena.ne.jp/minekoa/20100116/1263657955 「素人に抽象化は難しい」ってのに完璧に同意するけど、私自身の発言だっけ?"

うわっ、記憶違い!? と焦って捜す。そうそう、まつもとさんが言っていたのは

ここから「初心者向け言語が避けていること」言い替えれば 「初心者が苦手なこと」が何であるかだいたいわかる。 彼らは「抽象化」が苦手なのだ。

Matzにっき(2008-02-04)

ですね。「初心者」と「素人」、「苦手」と「難しい」じゃニュアンスが全然ちがう。記憶だけで書くのはいけません..orz すみません。

*1:ギーク的には「はてしない物語」は『虚無』よりも『複雑さ』と戦ってほしかったです。こっちのほうが強敵で、文字通り開発が never ending になります...orz

*2:逆にギークに語らせると、ニュータイプ(=ハッカー)部隊的な話になります。ドズルとキシリアですね

*3:開発中に負債が返済不能になるとデスマーチ発動です。「トラップカード『技術的負債』発動!プロジェクトを『デスマーチ』状態にっ!」

*4:当時わたしはこれをネガティブなものとしてしか受け止めていなかったのですが、こちらを読むと、賽の目アーキテクチャを起点にリファクタリングを成功させてる。てことは、ただわたしの力不足だったんだなぁ、とちょっち落ち込みます..orz

masuda220masuda220 2010/01/23 22:32 minekoa さん

はじめまして。
「システム設計日記」を書いている masuda220 と申します。

Smart UI の記事へのアクセスが急に増えたので、ログ調べたら、こちらで取り上げていただいていたんですね。

ありがとうございます。

かなり持ち上げていただきましたが、実態は、もっと、ぶざまなもんです。恰好よく書きすぎました。

でも、取り上げていただけことは、ほんとうにうれしかったです。
ありがとうございました。

minekoaminekoa 2010/01/27 23:14 はじめまして。「システム設計日記」、いつも愉しく読ませていただいてます。

>実態は、もっと、ぶざまなもんです
具体的な事例をみるに、プロジェクトの悲惨さがひしひしと伝わってくるのが、またカッコイイんですよ!

くらべてしまうと、自分の未熟さが浮き彫りになるというか、頑張らねば!と力が入ります。

これからも色々勉強させていただきます。コメントありがとうございました。

2010-01-09

つれづれ 01:23 つれづれを含むブックマーク

その167

ThinkPad X100e。ThinkPad s30 にゾッコンだったわたしにはかなり気になるノートです。ThinkPad な モバイルPC というので期待が高まってしまいます。

確かに、あまりに 変わりすぎていることに「これはThinkPad なのだろうか」と、不安も覚えます。というか不満です。でも、s30のようなコストを掛けたモバイル機の市場は既に失われていますし、10万円を切る「ThinkPad X100e」は本当に“ThinkPad”なのかを読むと、コスト制約の中でできるだけ ThinkPad であろうとしたその姿勢は良し!とも思えてきます。

しかし気になるとはいえ、去年の夏に Wind NetBook U100 を買ってしまっています。 U100には不満もないし、当分は見送りかな。でもでも、トラックポイント付きネットブックというだけで、ググッと欲しくなるのですよ。これでキータッチが素晴らしかったら ズキュンとやられてしまうかも。

あぁ、あの妙なキーボード、打ち心地はどんなものかしら。早く打ってみたいなー。


その168

お年玉、そう、お年玉。

貰う方の立場からすると、社会人にとって 3,000円とか5,000円とかははした金・・というか負担を掛けているなんて夢にも思わず無邪気に無心していたなぁ、と思い出します。しかし払う方になればこんなに辛いものなんて。3,000円でも10人寄れば3万円です。兄弟なんてもう、「甥っ子は仲間を呼んだ」みたいな。MP がガンガン削られます。

あぁぁ、予想外の出費が痛い。タダでさえ true tears Blu-ray Box で 借金してしまってるというのに...orz


その169

最近 Smalltalk を使っていない。・・・このフレーズをかくのは何回目でしょ。

先日、ちょっとした Web ツールを書きたくって、日頃使い慣れている Seaside でプログラミングすればチョチョイよ・・と書き出したら、忘れてる忘れてる・・・。慣れていると思い込んでた Seaside だけに、すっかり忘れているというのは凄いショックでした。ガガーン。

なんだか、わたしのSmalltalk力は一生こんなもんで終わってしまうような気がします。


その170

最近、xyzzyより MS Word の方が使用時間が長いわたしです。


先日、客先の担当者が変わったために、わたしのほうがよっぽどドメインエキスパート、というシチュエーションが増えてしまいました。思えば長いの、この仕事。そんなこんなで、タダでさえ減っていた仕事でコードを書く機会が、ここ最近激減です。仕事で日常的にコードをかいてないと腕が錆びちゃいそうで怖い。

正直、仕様書書いている間に動くコードが作れちゃうのになー、と思ってしまう。その動くモノをみながら、仕様を詰めていく方が上手くいくんじゃないかなと思う。

けれどこの不景気のため、「標準化」「管理をしっかりやってムダをカット」みたいな風潮が強くなった、恐ろしくガチガチなウォーターフォールになりつつあるわたしたちの開発環境 ではムリなお話。

で、この書類駆動開発の流れですが、逝くとこまで逝ってるなぁ、と思う出来事がありました。なんとついに「デバッグ中に行ったテスト」の項目まで「試験表にして」「印鑑と実行ログをつけて」納品することになってしまいました。

言い分としては、「デバッグといっても項目を考えないでテストするのは怠慢だ」「考えたなら試験表に成っているはずだ」「ちゃんとデバックできたかを検収するのは管理として当然だ」・・みたいな論理のドミノらしいけれど。

・・・ぉぃぉぃ。

(注:このほかにも納品前に結合試験は別にちゃんとやっていて、その試験表などは納品しています/さらに品証の試験もやってるよ/すげぇ)


その171

昨年の暮れは Windows で GNU Smalltalk で遊んでました。

BLOX.BWindow subclass: PetitWorkspace [
    | txtAria |
    initialize: parent [
        <category: 'private'>

        super initialize: parent.

        self createCodeText.
        self createPouUpMenu.

        self map
    ]

    createCodeText [
        <category: 'private'>
        | container |

        container := BLOX BContainer new: self.
        container setVerticalLayout: true;
                  defaultHeight: self height;
                  defaultWidth: self width.

        txtAria := BLOX.BText new: container.
        txtAria stretch: true
    ]

    createPouUpMenu [
        <category: 'private'>
        | pmenu |
        pmenu := BLOX.BPopupMenu new: txtAria.

        (BLOX.BMenuItem new: pmenu label: 'do it')
            callback: self message: #doIt.

        (BLOX.BMenuItem new: pmenu label: 'print it')
            callback: self message: #printIt.
        pmenu popup
    ]

    doIt [
        <category: 'blue button menu commands'>

        ^Behavior evaluate: txtAria getSelection to: self
    ]

    printIt [
        <category: 'blue button menu commands'>

        txtAria insertTextSelection: self doIt printString
    ]
]

win := PetitWorkspace new: 'Petit Workspace'.
BLOX.Blox dispatchEvents: win

こんなスクリプトファイルを作って、実行。


f:id:minekoa:20100109211044p:image


いいですよね、まるで Perl か Python のよう。

今は Tk のパス解決の問題で、ショートカットにスクリプトファイルを ドラッグ&ドロップ で起動する、というちょっといけてない使い方をしています。また、なぜだか CPU使用率が非常に高くなるのでちょっと常用できません。けれど、将来Windows に簡単インストールできて、ダブルクリックで実行できて、安定するなら 直ぐに Python から乗り換えたいとところ。待ち遠しいにゃ〜。

けれど、そうなったらそうなったで、他のファイルを「モジュール」として inport できないので 本当に単ファイルスクリプトだけしかダメ、というのが次のネックに感じるのかな?この贅沢ものめー。



その172

久々に Seaside を使っていて思ったのは、カスケードと 流れるようなインターフェイスって相性がいいな、ということ。

renderContentOn: html

    html inputText text: 'ここにお名前を入力してください';
                 callback: [ :x | self inform: 'ごきげんよう、', x, '様' ]

みたいに書くとき、無名の inputText に対し、変数に束縛することなく(名付けることなく)、複数のメッセージを連続して送れるし、それが不自然でないし、なにより「連続して送っている」と文法上明らかなのは美味しすぎる。text: の戻りが yourself ならばカスケードがなくても出来るけれど、連続して送ってるぞ!という意思表明が読みやすい、と私は思う。

そういえば、Little Smalltalk はカスケードが独自な挙動で再定義されていて、

"Smalltalk-80"
7 + 5;
  - 8;  "7 - 8"
  * 2   "7 * 2"

"Little Smalltalk"
7 + 5;
  - 8;  "12 - 8"
  * 2   "12 * 2"

と挙動が違うけれど、Little Smalltalk 方式は text: の戻り値次第で callback: 送り先が変わるため、このわかりやすさは得られない、てことになるのかな?


その173

年末はちょっと立て込んでいて、今更なのだけれど

「俺のソースだから」というプログラマは死んだらいいのに - 神様なんて信じない僕らのために


を読むと、わたしも妄想がこよなくふくらみました。


この話は考えてみたら凄い話で、喩えて言うなら「運転のしかたが解らないからクルマを自分でスクラッチしてみた」とか、「(手元にレシピがあるのに)レシピを読むのがめんどくさいと、ペリメニを何も見ないで イメージだけでなんとなく作ってしまう」とか(肉マンになってしまう・・)、そんなちょっと 世界ビックリニュースなノリの話です。・・・ってペリメニはムリがありますね orz

けれど、コの業界人ではあんまり驚かないのは、

  • 自分でスクラッチするのがそれだけ簡単に思える
  • 他人のコードを理解するのはそれだけ超〜〜〜〜ぉ面倒くさい

からだと思います。

が、前者は単なる錯覚、もしくは幻。スクラッチして出来るのは「クルマ」じゃなくて「クルマ風」の何かであって、ちゃんとクルマを作るのなら、それだけ手間が掛かる。それこそコードを理解する方が楽であるハズ。

プロだったらそんなことぐらい判れ、「そんなことも判らない」「Cに魂を惹かれた人々」を「だから抹殺すると宣言した」というのが Isoparametric さんで、わたしも「あれ、あたしに実感なんだ」です。


その174

けれど、組み込み屋のわたしは、全部をスクラッチしてしまえる、と思いたい気持ちもわかるというか。

アセンブリ言語で組み込みの開発していたときは なにもかも自前スクラッチだったし、Cでのプログラミングはその雰囲気が良く残っていたと思います。そして C++ にもそんな「全部出来てしまう」と思えてしまう雰囲気がギリギリあると感じます。

例えばコンテナやStringが 言語のシンタックスで特別扱いされたりし出すと、一般の開発者と 言語や標準ライブラリを作り人達の間に、それが壁として ドーンと立ちはだかって、そうして「ここから先はブラックボックス」と尻込みできるようになる。けれど、C++ は 反対に言語と標準ライブラリの間に距離感があるから、アイツ(って誰だ?)が出来るんなら自分でも出来るんじゃないかと、イケイケGoGoな気分になれる。――それがいいことか悪いことかは別にして。

C++の場合、「わたしにも(現実的なコストで)できそう」はほぼ錯覚なのだけれど、C++ の「錯覚が多いよね」がある意味有害な現状が、全てが手に負える、ブラックボックス境界(自作の地平線)のない、フラットでコンパクトなシステムの存在の可能性や価値を否定するものでもないと思うし、C++ であっても魅力であると思います。


その175

他人のコードって読みにくいね、と思います。何でこんなに大変なんだろう。読むくらいなら自分でいっそ作り直してしまった方が早い・・と思ってしまう気持ちはわかります。

他人のコードが読みにくいから、ドキュメントを整備することが推奨されちゃう。つまり誰かがコードを理解して、それをもとにドキュメントを作れば、みんなが楽を出来る、という現実があって。

Python の魅力に良く整備されたマニュアルがあるけれど、Python のユーザー層でもそれが魅力に思えるくらい 強がったってコードは読みにくいです。理解しやすさは ドキュメント > コード または ドキュメント > プログラム。


再発明厨さん達が後から後から沸いてしまうのは、ここらへんが諸悪の根源。悪いモノは元から絶たなきゃだけれど、他人のコードがどうしても読みにくい(理解に手間が掛かる)のは、本質的なモノかもしれない。

数式が一部の人間しか解りやすいと感じないのと同様、コードも「フツーの人は読みにくいよね」となるし、そのフツーの人には職業プログラマのボリュームゾーンでもあります。それそのモノは、飲み込みやすい別のモノには永遠に勝てないというか。そうであったら、厄介な。


その176

昨年わたしは、ある機器のリファレンスドライバを書く仕事をしました。と言っても、主に社内の別の部署部署が使うもので、たいしたものではないのです。

実際に使うドライバと、プログラマが機器の理解のために参考に読む為のドライバじゃ、やっぱりコードの書き方が違います。規模と複雑さを押さえることが機能よりも優先される。その場だけみれば全てが解るように書くのが優先される。だから異常系はヘナチョコですし、拡張性は必要に足りてないですし、マジックナンバーだって使っちゃいます。それは使うには良いコードではないけれど、かわりに「わかりやすい」と言われます。わかりやすいってなんでしょうね。

「ドキュメントとしてのコード」は、まだまだ 実際に使うコードと一致しにくいということかしら。

ただ、そういうコードなら「ドキュメントよりコードのほうが解りやすいって」言って貰えます。先の再発明厨さんたちだって、ゼロから再発明するでなくサンプルコードを踏み台にすることのほうが多い。だから「元を経つ」にはこの程度の読みやすさで十分かもなのだけれど。

うーん、このわかりやすさを実コードでも提供できればいいなぁ。抽象化技法はその為のものですが、今一歩及ばない。(わたしが無知ってだけかもしれない)


余談ですが、こう勘違いされたらどうしようとか、こう使われたらバグっちゃうとか、いろいろ考えると、神経がつかれるというか、大変でした。これで本当に社外に出て行くサンプルコードとか、オマケに紙面まで限られる技術書のコードとか。作ってる人は大変だなぁと改めて実感。


その177

こんな偉そうなことを書いておいてなんですが、わたしは他人様のコードをあんまり読みません。だって面倒くさいです。(ぉ

たとえば boostのコードとか読むとき、結構気合いをいれて「よし、よむぞーっ!」と勢いをつけないと、なかなか取っつけません。少なくとも「ちょっと使い方が解らない」程度では、コードを読むよりまずGoogle先生に相談です。あぁ、へたれだわ。

そんなわたしですが、Smalltalk はちょっと別で、「使い方が解らない」程度でコードをチョコチョコ読んでしまう。そんなくらいに Smalltalk でのコード読みの敷居が低いと感じます。


* * *


Smalltalk は「子供でも十分理解できて、その子供が大人になっても使える本格さも併せ持つ」ことを目標につくられたシステムで、もしかしたら先のサンプルドライバの話の理想を地で追うシステムといえるかな?「コードがドキュメントだ」を追求してるシステムでもあります。だから かなり読みやすい。(おかげでドキュメントが全然整備されない...orz)

Smalltalk のコードの読みやすさには

  • コードが、良くドキュメントとして整備され、その閲覧環境もリッチであること
  • 動いているプログラム(オブジェクト)を動かしたままで自在にこねくり回せること

の二つの軸があると思います。

前者は、例えば、クラスカテゴリやメソッドカテゴリで整理されたコード。「テキストファイル」というコードのインスタンスを持たない Smalltalk だから、プログラムの抽象化要素と同じ粒度にコードが分割されていて、捜しやすい。それを「システムブラウザ」というできの良いドキュメントビュワーでサクサク読めてしまう。

また、書かれたコード自体もドキュメントとして親切で、例えば Smalltalk にはクラスメソッドとして Example を用意する文化があります。他にも実際には最適化のため動かないものについても、コードが用意されてたり。実際のアプリケーションとしては意味のないコードが、人に読ませるためだけに存在するのが普通です。


後者は、動いているプログラムそのものに際限なくアクセスできることの強み。デバッグモードとかじゃなくって、完成品の運用中のプログラムで、です。

喩えるならば、今あなたがこのblogを読んでいるWebブラウザ、そのタブってどういう仕組みなのかな?――と思ったら、今まさにそこにあるタブオブジェクトのフィールドもコードも直ぐに覗けてしまう。覗くだけでなくフィールドを変更することも、コードを変更することも、実行しているままで出来てしまう、そんな仕組み。

動いているモノを直接動かしたまま分解出来るというのは、現実世界のモノを理解するときそれが強力なのと同様に、プログラムの理解にだって早道です。

「動いてるプログラム」と 「動かないドキュメント」のうち、ドキュメントのほうが楽にプログラムを理解できるというのは、「コード=動いているプログラムそのもの」じゃなくって、コードとプログラムそのものの間にちょっと距離が離れてしまっているからです。

だからコードを読む頭の中でプログラムの姿を再現しなくてはいけなくなると言うか。そういう余分なステップや脳力が必要になるのが面倒くさく感じるというか、歯車そのものと、歯車の図面の違いというか。そういうのがなければ、シンプルに、プログラムを直接弄くり回したほうが理解しやすいハズ。

とはいえコードの実際はやっぱり設計図で、Smalltalk にあるのは、コードを設計図に見せない、そのものに見せてしまうシステム、なのだけれど。ツールが上手くマッピングしてくれるのですね。


そんな素敵な Smalltalkだけれど、まだ十分ではないのは現実です。規模の悩みとも無縁じゃないし、もっとコンパクトでなければ、と言われることもあり。なにより Smalltalk は主流になれなかったから、ナンデモ分解理解できる理想郷は、箱庭になってしまっているのが、悲しいところ。


* * *


もちろんSmalltalk のは一つのアプローチでしかないと思うし(文芸的プログラミングとか)、統合開発環境の進歩だとか、強力な抽象化技法だとか、どんどんコードは読みやすくなっていくのだと思います。Isoparametric さんのエントリーみたいな話が、ギャグにしか見えなくなるくらい、コードを読むのが簡単になればいいな、と思いました。


その178

以上、連想妄想終了。


その179

フィルムスキャナを手に取るまでは、単なる情報の読み取りという風に捉えていて、「フィルムを先込むと自動でビーッと全コマ読み込んでくれる便利な機械」くらいの認識でした。けれど実際は大きく違って、まず、一コマってどの範囲?という認識からして人の手を煩わせます。

それはそうです、考えてみればロールフィルムに適当な四角で適当な位置に露光してあるだけで、基準も位置合わせの原点もない、画像の見た目だけがキモの世界なのですから。露光不足のコマとかあると人間にだってお手上げ。

そしてそのコマ自体ののスキャンにも手間が掛かります。フィルムの持っている全情報を取り込める訳じゃないので、露出を合わせなくてはいけません(自動露出はあるけれどね)。

この手間って、印画紙に焼くのとあんまり変わらないじゃん。とすればこれは 一種の引き延ばし機なのだなぁ、と思うようになりました。スキャンは単なるデータ化ではなく、絵造りの一環なのだ。


そうなると、良いフィルムスキャナというものに俄然興味が沸いてきます。引き延ばし機はカメラと同じくらいに写真の命です。・・ですが、フィルムスキャナはフィルムカメラ以上に絶滅危惧種となってしまっていて、しかもフィルムカメラのような熟成技術ではなく、発展途上技術です。

これはちょっと頂けぬ。むー、なんとかならないかなぁ。


その180

フィルムスキャナ、国内メーカでは もう Nikon しか作っていません。その Nikon も新製品をもう開発していないでしょうから、あとは頼りになりそうなのは台湾の plustek 社だけかな?と思います。


OpticFilm シリーズは、Nikon の SUPER COOLSCAN V ED と同じ価格帯。2009年11月に国内発売になった新型の 7400 で光源がそれまでの冷陰極管から LED になったり。フィルムを手で動かす仕組みになっていること以外はCOOLSCAN Vとだいたい同じような感じかな?(7300の後継が7400。現行の最上位機7500の後継は7600で、こちらはまだ日本では売っていない)

f:id:minekoa:20100109233837j:image

Plustek Film Scanner - OpticFilm 7600i Ai

一方の Smart Photo F50 は 12,000円の 簡易スキャナで、YASHICAブランドで売っているのと同じ位置づけっぽいけれど、モノは違うし、なによりデザインがカッコイイ。

f:id:minekoa:20100109233629j:image

Plustek Film Scanner - SmartPhoto F50

こちらのblogの写真が凄くカッコイイ)


普通のフィルムスキャナが引き延ばし機ならば、こちらはライトボックスだと思えばよいかしら。


一応レビューを捜したのだけれど、イマイチよくわかりませんでした。

no title


今は わたしの SUPER COOLSCAN V は元気ですが、彼女が逝ったときの参考用に、人柱希望です。



その181

no title

こうした技術製品が現在のように複雑なものとなっている理由を、私は少なくとも3つ挙げることができる。第一に、技術を開発するのが普通の人々ではなく、技術者であるということ。短絡的で職業分類に偏った見解かもしれないが、マニアたちは複雑さを好む。(中略)彼らにとっては、余分な機能の使い方を学んだり、分かりにくいユーザーインターフェースをマスターしたりすることが喜びなのである(なんとも悲しい幻想のなのだが、ツールを使いこなす自分たちの高等な技術をかっこよく思ってもらいたいと彼らは望むものなのだ)。

これを読んだとき、反射的に「ばっかじゃないの」と思いました。「技術者の感性が歪んでいるのが問題だ」なんて、なんて幼稚な。

感性以前に、製品仕様を決めるのは技術者じゃない事が多いですので、世の中の製品が複雑である理由としては、ちょっとこじつけかな?、と思いますし、技術者の感性についても、わたしの意見はおおむね

現場の技術者からすると、全く反対の意見だ。

技術者は、マニアであればあるほどシンプルで特定の機能に特化した製品がかっこいいと思い、できればそのような製品を作りたいと思う。

しかし、開発費を出す人やマーケティングと呼ばれる人は、特定の機能に特化した製品は、売れる場所が限られてきてしまい売りにくいので、好まない。

従って、このような人たちの意見を幅広く取り入れた結果、多機能すぎて肥大化した製品が完成する。

のコメントと同じです。


なんてったって仕事です。自分の欲しいモノ なんて滅多に作ることはできません。もし世の技術者にそんな力があったなら、ポピュラーな好みであり夢である 「PDF だけ読めれば十分な シンプルなタブレットが欲しい」は、とっくに実現しているハズ。あぁぁ、CrunchPad..orz


その182

さっきの記事。反射的には「ばっかじゃないの」と思ったものの、すこし経って Emacs を思い浮かべてしまったら、技術者の感性を疑われるのもムリはないなぁと思い直しました。

Emacs はある意味シンプルだと思うのですが、これをシンプルといったら「頭おかしいのとちゃう?」と言われてしまいます。

技術屋さんが自分で自分のために作るツールは「ムチャクチャシンプルで、かつ、、ムチャクチャ取っつきにくいことが多い」かな。これを「シンプル」とみるか「複雑」と見るかは、その人の立ち位置の問題だよなー。

それにお客さんと話していると、UI や目に見える手続きが複雑であるのと、そのドメインモデルが複雑なのとを、区別を付けて貰うのは難しいなぁと、思いました。


その183

去年の秋頃、父様のつかっている LANケーブルの 爪が折れてしまったらしく、「使ってないケーブル持ってないか?」と聞かれたので、「それくらいなら頭付け替えればそのまま使えるよ」と、サクッと RJ-45コネクタを付け替えてあげたのですが、「始めてプロっぽいところを見た」と言われたとき、なんとも複雑な気分でした。

うーん、いままでも各種設定とかトラブルシューティングとかやって上げているし、そっちのほうがよっぽど 本来の仕事に近い内容なのだけれどなー。

技術者というと、やっぱり工作めいたことを手際よくする姿 をみせないと、プロっぽく見えないのかしら。むー。


その184

フジフイルムの高級フィルムコンパクトカメラ「クラッセ」が安い。38mm F2.8 のクラッセS で 実売 38.000円くらい。普通のフィルムコンパクトである ナチュラクラシカ と 5,000円くらいしか変わらないというのは、安く感じます。

クラッセは写りは本当に抜群で、ちょっと欲しい。けれど、デザインもイマイチですし、チョイ大きいし、実は写りを別にすれば ナチュラクラシカの方が格好良くて欲しかったり。いあ、でも、買いだなぁ。買いたいなぁ。


その185

わたし、こんなふうに物欲まみれで、我ながら浪費家なのだけれど、それでも買えずに我慢しているものはかなり多いです。それはみんな同じで、友人をみてても、blog とか巡ってても「欲しいけれど、買えない」は良く目にする気がするのですよね。

もちろん 目に付くものだけで判断するのは意味がないけれど、それでも、うーん、最近の若い子が嫌消費ってホントかなって思います。(←おまえは若くない、ってツッコミは禁止)


その186

ひだまりスケッチ×☆☆☆ (って、表記でよいのかな?)、本編は良く動くし面白かったのですが、オープニングとエンディングが全然動かない・・というか、落ちてしまったかのようなのは、なんだったのかなぁ。シャフトだし、本当に間に合わなかったのかと思われてしまいます。

ひだまりのOP は動くというイメージがあっただけに、「アレ?」と思ってしまいました。


その187

言葉は「意味」と、それとは別に「イメージ(印象)」を持ちます。言葉の持つイメージに着目して用語を作り出すのはマーケティングとして有効です。けれどそれは buzzword 化を招き、議論を阻害する困ったちゃん。だから技術者だって科学者だって、言葉の意味を大事にします。


コミックサイエンス撲滅委員会

「コミックサイエンス」は「似非科学」の類義語らしいけれど、「コミック」に、「子供だましの」「もっともらしい」「嘘の」という意味はありませんし、コミックの事実とも異なります。

「コミックサイエンス」はイメージ語です。

事実とは異なる、いわゆる言葉のイメージをもって、自陣の説得力を増そうとする構図は、まったくもって「ゲーム脳」と同じ。ここまでそっくりさんをやられると、こんなときどんな顔をしたらいいか解らない。

注目すべきはこれは「ミイラ取りがミイラになった」訳ではないということ。

この名前に問題を感じずに団体名にしてしまった時点で、お里が知れたと思います。彼らは「マイナスイオン」などの(科学っぽい、という印象を利用した)マーケティング名称を、企業が受け入れたのと同じ倫理観を持って行動しているんだぞ、と自ら公言してるのです。そこに科学者としての矜持はありません。

つまるところ、彼らは「科学」なんてちっとも大事にしていない。彼らはもともと、彼らが撲滅しようとしている輩と同じ穴の狢で、「似非」サイドの住人です。

kilreykilrey 2010/01/10 22:53 コミックサイエンスは白金ナノコロイドの会社が絡んでいるようです。下手をすれば同じ穴の狢どころか、そのまま当事者ですね。

minekoaminekoa 2010/01/11 00:12 Ω ΩΩ<な,なんだってー!!

逆襲のChar逆襲のChar 2010/01/11 10:25 アムロ!! 地上に残ったプログラマなどは、Cの蚤だということが何故分からんのだ!!

・・・ 宇宙(そら)に出なければ何も解決しないと、トミノ大先生もおっしゃっております。

minekoaminekoa 2010/01/14 01:05 シャアとCharは書いてて全然気がつきませんでした。うまいなぁ。

実は、「でもさ、それが分かる人って不幸な人じゃないかって、気になったの」というツッコミを期待していました。(Isoparametricさんが大変そうです、、、T△T)

2010-01-01

あけました 13:08 あけましたを含むブックマーク

あけましておめでとうございます。旧年中は大変お世話になりました。

プログラミングのこと

このブログ、一昨年に比べて去年は全然コードをかいたエントリーが少ないのですよ。これは大問題です。

去年の後半は仕様検討とか要件分析が多くって、お仕事のほうからのネタはほとんど無かったのですが、併せてプライベートでもプログラミングしなくなってしまっているのが問題です。それについては、わたしは職業プログラマなので、仕事のモチベーションがさがるとプログラミングのモチベーションもググっと下がるタイプです。・・といいわけするのですが、だから良いわけないだろ的な。うう、すみません。

去年は本当に全然勉強しなかったし、モノもつくらなかったです。かろうじてやったことといえば、WxWidgits などの GUIツールキットで遊んで回ることくらい(そういえば、意外に面白かった GNU Smallatalk の BLOX 、記事にしようとしてたのですが、すっかり忘れてました)。これは単なる遊びで、なんかプログラマとしてのわたしは、去年全然伸びてないんじゃないかしら。ヤバイです。

とにかく、あまりの体たらく、反省です。今年はもう少し何とかしなくては、と思うのですが、その前にまず、真剣に転職を考えないと駄目そうなのですよね。むー。


トラックボールルームのこと

実は我が家の Subversion のリポジトリを吹っ飛ばしてしまったので、そこから何とかしなくっちゃ。今度は Git にするかなぁ。

レビュー対象はいっぱいあるので、来年はネタがつきなそうなのですが、SlimBlade Trackball は Kensington の新しいドライバを待つべきか、もうそんなモノは出ないとあきらめるべきか、悩ましい次第です。わたしのページがダメダメなのは置いておいて、一昨年の暮れから 新製品ラッシュが続いたトラックボール界隈は、2009年は 久しぶりに活気のある一年となりました。

とはいえ、メーカー的にはマイクロソフトが抜けた状態が続いていて、Logitech も継続販売以外の動きはないので、サンワサプライとKensingtonとその他もろもろ、といった脆弱な基盤なので油断は禁物です。

それと、マウスやトラックボールといったポインティングデバイスがそろそろ過去のモノになるんじゃないかな、というムードも漂っていて、マルチタッチ技術や例の10フィンガーUI などをみると、マウス共々一気に過去のデバイスとしてドブンと波にさらわれてしまうのでは?という不安もぬぐえません。

というわけで、活気のあるウチにちゃんとページも充実させないとな、と思います。がんばろー。(エイプリルフールのネタがないのは、どうしたものかしら)


そうそう、Orbit with ScrollRing は大変快調ですよ♪


写真のこと

去年はたくさん写真をとりました。フィルムにして49本。去年よりも全然多いですね。カメラ別ではLOMO LC-A がダントツで、けいおん!効果ここに極まれりです(違)。ココだけの話、秘密の写真ブログのほうも順調に更新できていて、去年はかなり満足のいく写真趣味ぷりでした。ガンダムもいっぱい撮ったしね!

去年はフィルムスキャナーにもだいぶなれました。なんというか、単なるデータ取り込みみたいに思っていたのですが、フィルムの持つ情報全てが取り込めたりしないし、どういうところを拾い上げるかを選んでスキャンしなきゃいい結果はでないしで、うー、大変。・・・と思っていたら、そうだこれってあれです、焼き付けと同じ感覚なのですね。・・どおりで面倒くさいし時間もかかるわけだ、と吹っ切れてからは、愉しくスキャンできるようになりました。

とはいえ、フィルム代・現像代がかなり響いています。わたしはプリントはしていないので、フィルム一本600円、フィルム現像代600円と安めに見積もっても58,800円。むー。

本当はデジカメに移行した方が懐には優しいのですが、無二の相棒になりそうなデジカメは未だ居ないので、いっぱい浮気して、結局高くつきそうなのが怖い所です。でも、PEN は欲しいなー。GXRもいいなぁ。


GXRといえば、わたし、マクロに期待しているのです。

というのも、わたしのトラックボールルームのような写真ですとか、フィギュアレビューのような写真では、大きな撮像素子よりも小さな撮像素子の方が、被写界深度が深くって有利なのです。でも小さな撮像素子って今まではいわゆる「コンデジ」しかなかったでしょう? GXR なら、小さな撮像素子のマクロが出来る「システムカメラ」の夢が見れます。

これは、なかなかわくわくモノじゃないかしら。リングフラッシュ内蔵だったりしたらもう、借金してもかっちゃいますわ。


漫画のこと

プログラミングの情熱が冷めると、わたしはとたんに絵を描き出します。去年はスケッチブックを2冊つぶしたので、相当ストレスがたまっていたんだなぁ、と思います(^^;

もう、同人誌をつくらなくなって何年もたつのですが、漫画が描きたいなー。と、思います。最初に入った会社がブラックで、全然私生活(どころか寝る時間も)無い生活だったので、日常で漫画を描く習慣が途絶えてしまったのですよね。

とはいえ、漫画だけでなく写真趣味の方も途絶えていたのですが、こちらのほうは Nikon S3 を入手するご縁をきっかけに 見事に復活できたので、ならば漫画を描く趣味も復活させたいなぁ、と思っています。が、うーん、毎年同じ様なこといってるなぁ。


* * *


というわけで、反省と今年の抱負を書いてみようとしたのですが、反省ばかりで、あんまり抱負はないですね(^^;


こんなどうしようもないわたしですが、よろしければ今年も生暖かい目で見守って頂けると幸いです。今年もよろしくお願いします。

きむら(K)きむら(K) 2010/01/04 12:12 今年もよろしくお願いします。
さっそくみねこあさんにお年玉ですね。
予約入金数が2000件以上になれば生産される「true tears」のBD-BOX、無事生産が決定 - GIGAZINE
ttp://gigazine.net/index.php?/news/comments/20100104_true_tears_bd_confirmed/

minekoaminekoa 2010/01/05 22:11 今年もよろしくお願いします。

>さっそくみねこあさんにお年玉ですね。
ぐはぁ。どちらかというと 「みねこあさん『が』お年玉」でした。この正月は予期せぬ親戚の来訪に、すっかりお年玉でお金が飛んでいきましたョ。

工面したお金も変なところで消えちゃいまして、結局 true tears は 借金しての振り込みです。人として終わってますorz