とっぷぺーじ
ねこめしにっき
2005/01
2005/04
だだだ未夢たんの萌え萌え着せ替えなのさー。 KISS なのさー。懐かしいですねー KISS 。そっか昨今は Java で動いちゃいますかー。そして、これまた数年ぶりに French Kiss Carbon 版を取ってきて、着せ替えまくりんぐ中。制服にエプロン姿がやっぱかわういな。そうそう、初代 OP のツインテール & 白ワンピ (つかそいつはよもや下着デスカ？と思う程度に各所防御が甘すぎたえちぃアレ) のバリエーションもほしいなー…。
ところで話は KISS にもどるが、一見動かなさげなナニをも動かせてしまう裏技とか、何ぞあったような記憶がするのですが、なんだっけ、忘れたー。誰ぞ覚えてませんか。うーむ。うごけー。(…なにやってますか
数年前、 JavaScript + 標準 DOM にてオブジェクトドラッグの実装練習にと習作したのも KISS モドキだったなー。どこぞの台湾サーバで見つけた偽春菜たんの KISS モドキから画像パーツだけ拝借して。 (←ゴルァ！…まぁそもそもが、どこぞからの盗用品なんだろけど…。) モトは JScript だか VBScript だか、ともかく WinIE でしか動作しない腐ったツクリであって、それにハラ立って作り直したのでした。もちろんそんなもん、おおっぴらにできないシロモノなので、以下略。
指向性メモにて異様に有用な記事が連発されまくっているので、負けじとメモまくっとく次第。（メモるだけじゃあかんだろ…
まずはIterator。
Singleton。インスタンスの同一性を保証したい場合。
Strategy。アルゴリズムの切り替え。とかいうと、難しく感じるけど、やってることはOOPの基本。
Composite。
Windows Media Video の動画を主体に構成されてる 日経ブロードバンドニュース の 2 月 23 日版にて、無償ブラウザー「モジラ」急成長
なるニュース解説をやっていた。(ヘッドラインでのテキスト見出しは非ＩＥブラウザーが急成長
となっている。)
ほぼ Firefox についての話題なのだけど、その Firefox 自身はブラウザ判別で弾かれて閲覧不能なのが笑うポイント。
Win IE5.5 以上あるいは Win Netscape7.1 以上必須となってて、実際 Win2000 + Netscape7.1 でフツーに閲覧できた。であれば技術実装面だけ考えれば Firefox でも同様にいけるはずなのだが。そこはホラ、 "Netscape" の文字列の有無が生死を分けてるショボいブラウザ判別でもしてるのでしょう。 (いちおうプラグインの有無やバージョンも見ている模様なれど、最終的な振り落としはやっぱり文字列なんじゃないのかな？)
ああ、もちろん Mac とか何とかゆー、日経大好きのオジたちにとっては見たことも聞いたことも触ったこともない、イコール存在しないのと同然のプラットフォームは、即座に弾かれて終了ですけどねー。てひひひ。もちろん、くだんのニュース解説中でも "Safari" という単語は一言たりとも出てきませんよ。ギコハハ。ハァ…。
動画の内容は下記のようなあたりで、このにっきの閲覧者であれば取るに足らない内容といってしまえばそれまで。（笑）
実は私もモジラのユーザーでありまして
落としてくれる(「フィルタしてくれる」の意であろう…) ので便利。
Microsoft ばっかり使ってると飽きてしまうということで(なんじゃそりゃ…)
あーちなみに、くだんのニュース解説動画への直アクセス URL は下記ですよ。どうみても恒久的 URL には見えないでアレですが、あと数日間は大丈夫じゃないかな？ URL 直叩きならば、 OSX でも Windows Media Player for Mac OS X の最新版 (v9.0) で無問題に再生できまっせ。
mms://nikkeibbn-wmtod.stream.ne.jp/vod05/nikkei-bbnews/wed/kaisetsu.asf
ネタとしてすばらしいのみならず、サンプルコードがついてて、何事もサンプル無しでは習得できねーぼくみたいな応用力欠如派には最高。そして、ここを読んだあとに「デザインパターン入門」を読んで、何を言ってるのかをようやく多少なりとも分かり初めてみたりという逆転現象。
(なんでこの項目のジャンル分けが「ジャバスク関係」なのかちうと、自分がこの知恵を活用しようと思う、あるいは思えるだけの下地のある分野がそこしかないからで…。)
モノゴトというのは、名前がついて初めて「存在する」事になるのであって。
- Ajaxの定義
Ajax は技術そのものではない。それは、それぞれに繁栄している様々な技術を、新しいやり方で強力に組み合わせることなのだ。Ajax は次の技術の組み合わせである。
- XHTML と CSS を用いた、Web 標準に基づくプレゼンテーション
- Document Object Model によるダイナミックな表示と相互作用
- XML と XSLT による、データの変換や操作
- XMLHttpRequest による、データの非同期的な取得
- それらを JavaScript によって結びつける
(上記引用部、けんたろたんの訳のほうがこなれていたので取り替えましたヨ。)
google suggestとか google maps とかみたく、まぁフツーにジャバスク駆動なんだが、なんか裏で激しく通信してデータをゴニョりつつ、 DOM と CSS を駆使して見た目も動的にゴニョって、なんかリッチっぽい UI を実現する系のシカケの事らし。
RIA って単語を見るといままでは、あーそうねそうね Flash だの Flex 何だのよくわからんが Macromedia お世話しまくりされまくり系ですねー so what? とか冷めてたのだが、このジャバスクが主役なシカケも RIA death! とか叫んでいいのね？ね？いいぞいいぞ！いきなり RIA が自分にちかしいモノになった気がしてきたぞー。
なんか「まだまだ日本では云々」的な気分の漂うシカケだけど、サーバサイドなバックエンドとの何らかのやりとりを動的発生させてその結果を DOM 使って動的反映、ってなジャバスクギミックなら、既に某国内サイト業務案件にて実装した事アリ。たぶん同様の事なら、そこかしこで以前から秘かになされているのではないかと思った次第。つまり既存物であっても舶来の新語として輸入されて初めて広く認知されるという "blog" パターンだったりしない？しないか。
ぼくのソレ (どれ) がそうであったように、バックエンドとのヤリトリはレガシーな手法 (謎) であって、そこに XML はちっとも介在してなかったりする気がするので、それだと略語は Ajax じゃなくて "Aja" になっちゃうしなー。あじゃ。
「XML Parse Error 放置いやん (1)」に呼応して書かれた気がしないでもない記事。
XHTMLはXMLであり、XMLパーサーを使って解析をする事を前提としている。「XHTML」と銘打つなら、この点を見過ごしてはならない。
(略) well-formedで無いXHTML文書は致命的である(それがtext/htmlであってもapplication/xmlであっても同様。XHTMLはXMLであるという前提なので、第三者からはXMLであると受け取られる)。何故なら、XMLパーサーで解析が出来ないからだ。これではXHTMLにしている意味が無い。XMLは単なる凡ミスで、簡単にwell-formedでなくなる。(略) そう考えれば、XHTMLを含めXMLはやはり手打ちでなく、オーサリングツール等を使うのが本来の姿だろう。手打ちでやるならば、well-formedであるかの確認は必須ではなかろうと、自戒を込めて考えている。
[ 勝手にしやがれ より ]
いろいろな都合により日和って text/html で送出してはしているけど、このにっきも含め当サイトはほぼすべて XHTML1.1 。皆様ごぞんじのよーに (?)、これらの公開用 XHTML は今やほぼ皆 XSLT にて生成されてる次第。XHTML2 の <section> / <h> 構造相似形狙いの div.section 多重入れ子とか、もはや手書きでできる作業ではないですよって。
で、 XSLT の性格上、吐き出される XML (この場合は XHTML だけど) は自動的に Well-formed となる。…のはず、なのだ。 XSLT スタイルシート内で、なんかイレギュラーな事をムリクソやろうとか思って、よせばいいのに <xsl:text> とか使ってタグを「書く」という無体な事をして、そこでミスしなければ、だが…。
あと Well-formed 云々とは違う話だけど、実体参照の扱い方に制限が多くて、勝手に参照展開される不意打ちを食らい、 xml:lang="en" なブロック内に全角文字として燦然と存在してしまったりとかのポカが、どうも避けられなくて困っている。
インターネットにあまり慣れていないひとによく訊かれるのが、こういった「どうやって儲けてるの？」系の質問。
[ antipop2.0 より ]
同人世界のことをあまりしらないひとによく訊かれるのが、こういった「それって儲かるの？」系の質問。
なんで儲かるとか、儲からないとか、そこに思いを馳せるのでしょうね。やっぱり金銭の収受がある以上、興味はそこに行きますか。そうですか。
金銭の収受があるシュミといえば、バンド活動なんかもそのはずだが (チケットノルマね)、バンドやってた頃に「バンド儲かるの？」とは誰からも訊かれたことは無い。そういえば。
おちはない。
XML としての側面を活用してるわけでもない、後方互換 HTML の範疇をまったく逸脱しない XHTML を、 text/html ではなくわざわざ application/xhtml+xml で提供するだけの気合いがあるんであれば、 非 Well-formed で XML パースエラー発生させまくり状態のまま、放置しないでほしいところ。
「XML Parse Error 放置いやん (2)」に関連記事あり。
(Mozilla あるいは Firefox の) ウィンドウ切り替え時のアンカーへの反応 (に関して：)
ウインドウが重なっていて、下のウィンドウをクリックしてアクティブになるまでは、ページ内のリンクを辿らないようにしてほしい。なぜなら、広告などが下にあると、そのページに移動してしまうから。これは結構イライラもの。
[ ryuzi_kambeの？Ｄ より ]
Piro 『アクティブでないウィンドウをクリックしたときはウィンドウにフォーカスを移すだけでクリックイベントとしては処理しない、というのは、Mac OSの動作ですね。iTunesはWindows版でもそういう動作をします。しかし逆に言うと、それはWindowsの動作とは異なっているということでもあります。ぶっちゃけ、その一点をもってiTunes for Windowsは使いにくいと言えます。 (略) 』
[ 同日同所のコメント欄 より ]
インアクティブウインドウ内の任意箇所におけるクリック一回が、そのウインドウのアクティべートのみに消費されないで、クリック位置におけるクリック動作まで自動的に続けて発生する……とゆー操作概念。これを Apple Human Interface Guidelines では
Click-Through
と呼称してますね。…というように Apple HIG で定義されてる位だから、 Click-Through はなにも 非 MacOS 的なものでもない、つまり「 Click-Through しない事」を指して Mac OSの動作ですね
と短絡するのは違うと思った。
たしかに棺桶 OS 時代はこの Click-Through 、ほとんど無いに等しい概念だった。ただし、 MacOS を MacOS たらしめていたあの旧 Finder それ自身には、 Click-Through が実装されてた。インアクティブのままクリック一回でアイコンを選択状態できてたし、ドラッグ開始できてたでしょ？…そしてマカーは、さもそれが当然であるかの如く Finder をサクサク操作していた。その後、あの悲惨な OSX 黎明期の一時期、Finder からはこの Click-Through も失われており、そうなって初めてマカーは、古き良き Finder のサクサクの操作感がどのような深い知恵で構成されていたかを、今更のように知るというアリサマだった。 (とか、一般論のように書いているが、漏れがそうだったという話ね)
さてさて、その Apple HIG では Click-Through をどう定義しているか。ご紹介しますかにょ。
Click-through provides greater efficiency in performing such tasks as closing or resizing inactive windows, and copying or moving files. In many cases, however, click-through could confuse a user who clicks an item unintentionally.
つまり Click-Through はそれがハマる部位では超イケイケな操作感をもたらすが、考え無しだと超ヘボヘボになるよ、と。いわずもがなである。その観点により、 Click-Through を実装すべきでない部位について、以下のような具体例を示してる。
- Are potentially harmful (for example, the Delete button in Mail)
- Are difficult to recover from, such as:
- Actions that are difficult or impossible to cancel (the Send button in Mail)
- Dismissing a dialog without knowing what action was taken (for example, it's not easy to "unsave" a document)
- Removing the user from the current context (selecting a new item in a column, for example, can change the target of the Finder window)
神部さんの (非 OSX 版) Firefox に対するウィンドウをクリックしてアクティブになるまでは、ページ内のリンクを辿らないようにしてほしい
という要望は、上記引用にある「今現在の文脈を勝手に失わせるような Click-Through は宜しくない」という題目に相当するのかな。…単純なページ遷移が difficult to recover from
なのかというとビミョな気もするが、アンカーのモノによっては「商品購入ケテーイ」だったり「データの削除」だったりの impossible to cancel
なモノの可能性もあるし、ブラウザ的にアンカーの「原状回復不可性・困難性」の判別はムリなので、安全を取れば Click-Through はしないに越したことはない、と言ってみるテスト。
そりゃもう、例によって、 OSX アプリだって全てが HIG に沿っているわけもなくて。たとえば漏れ愛用の Cocoa 製 OSX 専用メールソフト GyazMail は、上記ガイドラインに反して「送受信」ボタンも「削除」ボタンも Click-Through しちゃう罠。 Click-Through の可・不可を視覚的に判断させるための云々も一応 HIG には示されているんだけど、それも同様にして以下略。まぁ OSX では Click-Through するのはほぼツールバー近辺のみと相場が決まっているので、だいたいあんしんですが、ツールアイコンくさい物体がいっぱい並んでる「環境設定パネル」の系列ともなると、考え無しのクリックは予想外の Click-Through を起こしたり起こさなかったりして、そこそこ物騒な世界になりつつある。
ところで iTunes デスガ。 Win 版にしろ Mac 版にしろ、通常モードのウインドウだと「再生」ボタン等はたしかに非 Click-Through 。しかし「ミニプレーヤ」モードだと突如 Click-Through になったり。 「ミニプレーヤ」はほぼインジケータ兼用のリモコンなので、その場合は Click-Through で正解、と Apple は踏んでる模様。(「ミニプレーヤ」つのは Win 版でしか出てこない名称だけど、 Mac 版でズームボックスをクリックしてちっこくした状態、アレの事。そして Mac 版だと Click-Through どころか、 iTunes 「ミニプレーヤ」窓はインアクティブ状態のままボタン操作できたり。) ボタンの見てくれも一応 HIG の通りに、 Click-Through 不能時はディム表示、 Click-Through 可能時はハッキリ表示、となってる。…んー。その程度では正直、見分けつきませんよアポーさん？ …ちうかですね、あの iApp 系のメタルブラシ窓を見ると、いかにも HIG 非準拠な GUI を想起させられてですね (以下略
まぁ、 Windows の世界は「いつでもどこでも誰とでも Click-Through 」の超音速操作世界なので、アポーは iTunes についてもそうすべきカモナとオモタ。そこであえて、 Win 版 Firefox が Click-Through すべき場面の取捨選択とか考え始めるならば、 Firefox の GUI 全般、ひいては Mozilla.org の XUL なプロダクツの GUI 全般に及ぶ一貫したガイドラインとか、定め始める必要が出るんじゃなかろかというか、「単なる慣習と違ってこちとら体系的仕様に基づき云々」とか Apple みたくうそぶく用の体制が必要カモ？
てなわけで。ざっと見てかいつまんで。
5. The 'background-image' property
- Value:
- <uri> [ , <uri> ]* | none
複数背景画像置けまくりイイヨイイヨー。
18. The 'border-image' property
- Value:
- none | <uri> [ <number> | <percentage> ]{4} [ / <border-width>{1,4} ]? [stretch | repeat | round]{0,2}
伸びたりパターン繰り返したりの画像を border に使えまくりイイヨイイヨー。
22. The 'box-shadow' property
- Value:
- none | [ <length> <length> <length>? || <color> ] [ , <length> <length> <length>? || <color> ]+
ボックスに影までついちゃってイイヨイイヨー。
…夢のような話ばかりで、しばしウットリした。さて、こやつらを日常的に駆使しまくって CSS レイアウトデザインをする日々は何十年後の事だろうか… orz
昨日一番のギョーカイ (何処) ニュースといえばコレにつきますね、やっぱ。
いくら Firefox が追い上げているといってもせいぜいシェア 10% 程度 (そんなにないか？)、ほかの有象無象ブラウザ計で 5% 、残りはすべて WinIE とゆー、1999 年頃以来このかたの異常なシェア率のおかげで、現在も近未来も WinIE の出来不出来はサイレントマジョリティの Web 生活の質に直結する。ゆえにセキュリティにしろ Web 標準準拠にしろ、抜本的に良いものになるよう、がんばってほしいところではあるが、 Firefox の盛り上がりにちょっとだけ鼻毛がかゆくなった巨人が、とりあえずの牽制にと飛ばしてみたクシャミ、ってな風体の報なので、正直期待しない。
Firefox が対 IE の宣伝としてセキュリティ面を叫びすぎたおかげで (?)、 IE7 の件もセキュリティ面の強化が主なというかほぼ唯一の力点となっている模様。つまり、漏れたち (誰) の望む、標準規格準拠へのすさまじい励行などというのは、この夏にむけての段階ではほぼ省みられないだろな、と。
というか、拙速に標準準拠を高められても、 Safari や Opera の CSS 実装みたく、カンジンなトコロが抜け作なデキだったりすると、ハック技による適用除外もままならなくなるとかで、大いに困るわけですよ。まぁ、簡単なところから、アルファチャンネル PNG の対応をシテオケ。と。
[ Baka Memo 2005年2月11日 経由 ]
3代目ミンキーモモ "みらくるドリーム ミンキーモモ"
小学館 小学二年生で好評連載中！
し、シランかった！去年の4月から連載始まってて、そして知らぬまま最近連載終了してた…って何なんだ！なんで誰も教えてくれんのじゃ！！新作アニメ・特撮情報の「放映開始時期未定・企画中」のとこにもちゃっかりエントリーだけはあったり…。このままアニメにならず消えるのか、それとも。もしやるのであればやはり三作目も湯山監督・首藤脚本でよろしくおながいします…。
しかし上記サイト名、なんで「ムーミン」モモなのかいな？聞くのがヤボ系なのかな…。謎だ。
[ Tales about Apple 経由 ]
最新 PowerBook に搭載された例の二本指トラックパッドスクロール機能が、実はある程度最近の旧機種 PowerBook/iBook でもハード的には既に対応済みであり、それら旧機種で同機能を有効にするとのフレコミにて、巷で話題のカーネルエクステンション (つまりドライバ)。
SideTrack が正規版になったところでシェアウェアになっちまったので、金払おうか考えていたところ。もしこれがウチの iBook Opaque16VRAM でも機能するのであれば、 SideTrack にはオサラバかなーとワクワク。さっそく、上記サイトにて配布されてる二本指トラックパッドスクロール対応チェック用スクリプトを走らせてみた。
注: 配布サイト他にもくどいくらい書いてあるけど、 SideTrack を使用している場合は、このチェックを行う前に SideTrack をアンインストールする必要アリ。
Checking if your trackpad supports two-finger scrolling... Your trackpad does not seem to support W-enhanced mode. W-enhanced mode is necessary for two-finger scrolling to work.
…ダメデスカ。ソウデスカ。 (´ー`)y-~
さて、そろそろいいかげんレジスト催促のダイアログもウザくなってきたことだし、 SideTrack に金払いますかにょ…。
二本指スクロール機能の良さげなトコは、やっぱ、 SideTrack のアレやよくある Windows ノートのスクロール機能みたいに、トラックパッドの隅っこを一生懸命なぞらなければいけないんじゃなく、トラックパッド全体を使ってアバウトにガッ！ガッ！と行けるあたりですかね。たぶん。あと iPod 式のクルクルができるのもいいよなぁ。
なつみかん開発凍結の報より一年。開発再開そして次は PHP5 になるのだそうな。ぺちぺー。
それから重要なのは、新生「なつみかん」が提供するのは、サイトの更新時刻の取得機能だけ、ということです。つまり、HTML化したり、はてなアンテナのように差分を表示したり、という機能はありません。あくまで、「LLPSNM」を入力し、更新時刻を取得して「LLPSNM」として出力するだけです。「LLPSNM」をどうにかするとしたら、新たにアプリケーションを作る必要があります。
[ 暇な時間に書く雑記 より ]
「LLPSNM」なるものは今までのLIRSと同等のもの
ってことで、やっぱ CSV なのかな。うーむむ。イロイロ変換して活用させるのが前提であるなら、そこは時流に逆らわずに、せめて XML ではあってほしい…と一瞬思ったけど、その XML 云々自体「LLPSNM」をどうにか
して生成すべきってことなんだろな。
OSX 用アプリをいろいろ作ってる Panic 社のオリジナルグッズ販売ページ。ドラッグ＆ドロップオリエンテッドな UI が展開されててオモロイ。つまり、欲しい商品をページ下部のカート領域へドラッグ＆ドロップで放り込める。逆に、カートに入れたけどやっぱイラネとなった商品は、これまたドラドロでカート外へおもむろに放り出せば OK。すると、煙をポムっと出して消えるの。要するに OSX の Dock とかツールバーとか Finder サイドバーとかでおなじみのアレ。
この操作、マカーにとっては日常触れてるモノにかなり近いから、分かりやすく親しみの持てるものだとは思う。だけど、世間一般を相手にすると、そうでもないと思ったりする。なんでかというと、非マカーはみなドラドロがチョー苦手なんですよ！w
というのは冗談としても、ともかく、 Web コンテンツの UI 体験としてのドラドロ操作体験は、マカーであってもほとんど無いのが実情なんでなかろか。つまり Web コンテンツの上に転がっているモノはドラッグしても動かないのが常で、ドラッグしようとか出来るとか思わないのが常。なので、いきなりドラッグ操作できますよーといっても、なかなかね。
実は漏れも、某業務案件における、最大 6 つのアイテムを二次元マス目上に配置させる旨のページ…ってワケワカランがな、ぶっちゃけると座席指定用のページなんですが、その GUI 実装をする際に、ドラドロオリエンテッドな GUI はどうよ？とチーム内で提案したことがありまして。つまり 1 〜 6 のアイコンをドラドロして、座席表の好きな位置に配置して完了、みたいな。エレガントちゃうん？と自分では思った次第だったのだが。
しかし反対意見いろいろ。どんなにドラドロの距離が短くてもドラッグが苦手な人はかなりの率で存在するだろう。座席表はけっこう細かいのでシビアな操作 (とシビアな位置判定実装) が要求される。そもそもドラッグ操作が Web ではあんまりポピュラーではない。等々。とすればドラドロ以外の代替操作の用意も必要になってくる。 Panic グッズのページにもある、カート追加の [+] ボタンや [カート一括クリア] アンカーのような。そしてドラドロの実装は (それ用のライブラリとか整備してない現段階では一からの開発となるので) 負荷が高い。しかも非ポピュラーな操作である以上、代替操作のほうが多く使われるだけのオチだから、いろんな意味で高くつくドラドロは実装するだけ時間がムダ。つーか納期がグェァー！…というわけであえなく却下だた。
しかしこの Panic 社の例を見てしまった以上、やはりいつかリベンジしたいと思った！
弊社 (何処) でも風邪が大流行な昨今の先週末、ちょっとムリして徹夜で仕事してみたら、一発で風邪ひいた。そして折角の三連休は完全に寝込んで無為に消費してしまった。それだけでは足らなくて、今日も仕事休んで寝込んだ始末。おかげさまでだいぶよくなったんだけど、こうなってみると、風邪菌とかインフルエンザウイルスとかその他いろんなもので充ち満ちて汚れた公共空間の空気を吸うのが恐いとか思い出す始末。
会社もそうなのだが、電車内とか、店舗内とか、なんでああも無駄に暑くて汗ばむほどの暖房を効かすんだろ。おかげで菌が繁殖しまくりでわなかろか！会社では冬でも T シャツ一枚で過ごしてあまつさえウチワをパタパタさせつつ作業してたりするし。電車でも汗だらだら垂らして乗ってたり。異常です。…漏れが異常なのか？
暖房装置の吐き出す、乾燥した高温のほこりっぽい空気に「中古感」を覚えるのは漏れだけだろか？そして逆に、冷たい空気は、たとえそれが冷房装置が吐きだしたものであっても、なぜか「新品」のように感じる謎とか。
もちろん寒いのは人並みにイヤですよ？空気が不自然に必要以上に暖かいのがキモいの。よって赤外線ヒーターなどを好む次第。
「クールなURIは変わらない」のお題目をいくら叫んでも、自分のものでないドメイン名やサーバにリソースを置くという判断がすでにダメポ。わかってますよもう。
というかむしろ、情報到達の確実性を鑑みるに、実体ある特定のサーバ装置にデータを固着シテオクのがまだまだ圧倒的に最良、というあたりもそろそろダサイ気がするし、そもそも、ドメイン名だのファイル名だの URI だのといった、文字列ベースのリソース同定機構がいいかげんダサイ、という話は無いのかな。いやモチロン、文句いうだけで代案も最先端技術動向の知見もこれっぽっちもありませんが何か？
諸般のやむにやまれぬ事情による「 NAJO プロジェクト (謎) 」の終了にともない、 najo.cc.sakura.ne.jp 鯖にあった各種ページの、 alimika.alib.jp 鯖への移転をお知らせする次第なのです。
なお、現在は旧 URL へのアクセスをリダイレクトで新 URL へ飛ばしているので、移転にともなう不都合などは表面上 (たぶん) 起きてないと思うです。が、 najo.cc.sakura.ne.jp ドメイン、あるいはサーバ実体そのものの今後の存続が未定。近日中にも旧 URL はアクセス不能 (もちろんリダイレクトも不能) となる公算が高いです。お手数ですが、いまのうちにブクマクあるいはリンク先の変更をよろしくです。 (なお cc.sakura.ne.jp ドメインだけは死守される予定。残念でした＞誰)
移転するおもなページと URL は以下のとおり。
「謎クエリつかない版」改め「リダイレクタ使わない版」 index_nq.shtml, mini_nq.shtml は終了。ほとんど利用者がいなかった模様につき。
日記にコメント機能がついた今や、存在意義がもはや見いだせない気がしているが。
古いサムネイルがいつまでも貼られっぱなしな件に関しての苦情に耳日曜中、というかそもそもこんなページはイラネ感が公開当初より漂っているが。
DTI の会員向け無料 Web 領域の増量をうけて、これまで容量対策で他サーバに逃がしていた画像ファイル等を試験的に DTI 鯖へ戻してみた昨今。そうでなくてもあっちこっちリダイレクトリダイレクトな状況で、ヤヤコシくてタマランし。んで、 50MB なんて天文学的サイズに増えたのだから、あれこれ戻してもぜんぜん余裕デショー？とか左うちわのお大尽気分でホクホクと利用状況を確認してみたのですが…。
- ディスクご使用量
- 41.56 MBytes
＿|￣|○ ﾀﾞﾒﾀﾞｺﾘｬ…。
[ 煤 - Note 経由 ]
あの懐かしのウゴウゴルーガのうねうね画を作るツールだそーな。で、こんなんあるらしーよと妻たんに見せたら、とっくに DL して遊び済みで (くそぅ) 、こんなん描いたんだってさ。
元は 800 x 600 ピクセル 334 フレームの 3.3MB だた。ファイルサイズだけ超大作。あんまりにあんまりなので、タテヨコを半分にリサイズしたのが上。うねうね感がちと薄れてビミョ。
[ Latest topics - outsider reflex 経由 ]
漏れも妻たんも、実家では犬を飼っているので、というか、犬を残して東京に出てきているわけでして。やっぱ犬飼いたいなぁーとか、よく話に出る。まぁ今のココのアパート住まいでは叶わぬ夢なんだけど。ちなみにふたりしてマジ猫アレルギーなので、猫はかわいいとは思っても飼えないのであった。
リンク先の読本にあるとおり、犬猫その他を飼うってのはいろいろとハンパではない営み。なのだけど、言葉は通じなくても、いや通じてるけど通じてないフリをしくさっているというか何というか、ともかく互いを理解しまくりあった存在ってのは大切で、ひとはひとりではいきてはいけぬ、云々。ウチの犬も妻たんトコのも、おなじくらい年くっていて、明らかに余命は数年、長くても 10 年は持たないはず。たぶんぼくたちはこの非情な大都会・東京に居るまま、死に目には逢えないのだろうなぁと、ふと寂しい考えがよぎる夜もある。
ウチの犬たち (今のは二代目) が漏れの情緒面に対して与えてくれたものはかなり大きいなーとか感じていて、できれば自分たちの子供にも、この恩恵と気持ちを感じられる機会を与えてやりたいところ。
今の妻たん (当時は「彼女たん」でさえなかったが) のツテを経由して自分トコまで漂着した文書を、無断転載してみるの巻。最近 HDD の奥底からふたたび発掘された。初出メディア、初出年月日不明。少なくともここへ漂着した 2000 年 1 月よりは前の初出と思われ。情報求ム。
ヲタ絵を描くこと自体から逃げて久しい漏れが、いまさらのようにこーいう文書を提示してみせるのもどうかと思ったが。まぁ、なんだ、この文書にグッとくる程度にはソレ (どれ) に何かを賭けていた青春時代もあったのよ、とか言い張りたいんじゃなかろか？すくなくとも、ちまたにはびこる冷笑主義に与するまでは干からびちゃいないつもりよ、とか何とか？イミフメ。
読んだことあるなーと思ったら、希有馬（奇有馬ではないはず）氏のカラフル萬福星（ビブロス刊）に掲載されたコラムだった気が。さすがに何号かはちょっと憶えてないんだけど。
[ ARTIFACT@ハテナ系 より ]
不勉強にて、希有馬氏の名前を知りませんでした。どうりで何百回ググっても出てこないわけだ。
Nakada Hiroshi 『調べてみたら、「オタク絵には常に正解がある。」はカラフル萬福星1999年Vol.08の掲載でした。「おたくのお」の４回目。もう５年も経つのか…』 (2005/02/13 13:29)
[ ARTIFACT@ハテナ系 (2005/02/13 コメント欄) より ]
情報ありがとうございます。長年わからなかった正確な初出や筆者名をようやく知ることができました。
ねこめしにっきヘッドライン
Mail to Alimika Satomi
Site search
About copyrights
