TabMixに主流を明け渡したとはいえ、一世を風靡したTabbrowserExtensionの作者Piroさんの言葉ということに一定の権威性があります
しかし、それ以上に、明快で理屈の通った言葉に、このエントリーの価値がある。
まぁ、私もChromeのタブは位置が高すぎて文化的にどうこうという枠を超えて嫌いなのですが。
あれは、タブが一番上にあると、画面上にくっつけるべきタイプのインターフェースと非常に良く被さるので、あれはいくらなんでも上にありすぎ！と言うことなんですが
Webブラウザというのは、悪魔でアプリケーションであってプラットフォームでは無いのですから、あそこまで画面を支配する様な印象のUIは私はおかしいと感じます。
(これには反論もあるかもしれませんが、HTMLとJavaScriptの実行エンジンがプラットフォーム足りえる資産なのであって、インターフェースがそうなのでは無いと断言させていただく)
ただまぁ、私もTab on Topである事自体は私もおおかた賛成なので、是非Chromeみたいになんでも隠してタブとページだけ見える過度にシンプルなインターフェースに追随はしないで、良いエッセンスだけを掠め取って欲しい所です
嗚呼、それにしてもまたテーマ修正の手間がかかりそうだなぁ･･･（汗
投稿者 baban
2010/07/03 at 23:28
no comments
no trackbacks
最近、私新マシンを購入して(って言ってもCore2Celeronのビミョースペックなのですが)VMWareServerを導入して、仮想サーバーを構築したのですが(世に言うクラウドってヤツですね)
1台のマシンにスペックの許す範囲で何台でもOSをインストールが出来るというのは便利ですね。
ぶっ壊れても良いこと前提でコマンドが打てる！
この喜びったらないです。
ブートローダーの切り替えとか、linuxカーネルの入れ替えだとか。
1台自分のために、安定稼動させている環境の隣で好き放題弄りまわせる。
しかし、これを導入してすぐに困ったことに出会いました。
2台環境があるのに、IPが一つしかないんだから、どっちにしろ外部に1台分しか公開できないジャン。
もちろんNATの機能を使えば、全く出来ないとはいいません。
しかし、この段階でApacheの設定ファイルをこうして、アクセスする側にも80番以外のポートからのアクセスを求めて。
あからさまに、トリッキーな運用法を求められます。
ここで気づかされるのですが、IPv4って不足し始めている状況なのを、CIDRでかなり細分化して配って
不要なら出来るだけプライベートなIPを使い、とだましだまし運用している段階で既に社会のいたるところで
技術者の人件費等で小さな負担とを強いているんだな、と分かりました。
データセンターでも、新規のIPを100こづつくらいしか一度にもらえなくて、申請の事務負担を増やしていると効いたこともありますし。
というかネトゲユーザーなら分かってもらえると思いますが、固定IPもらうために追加料金払う羽目になっている状況が既におかしい。
IPが一つしかないという状況は、1台以上、外部に情報発信できる機器があることを否定しているわけで
例えば、家電制御用の小型サーバー等、未来にあるべき新製品の登場の機会を奪ってきていたんだな、と感じます。
正直、もう個人に対して1000個づつとかタダでIP配ってしまっていい時代なんだと思う
あとは、使い方はヘビーユーザーが各々考えるので。
固定IPふんだんに配ってくれるなら、基本料金が1500円くらい高くても喜んでそちらに移行しますので
そういうサービス、・・・ありませんかね？
投稿者 baban
2010/06/26 at 08:26
no comments
no trackbacks
ところでお話ですが、みなさんはお仕事でパソコンを使っているとき、何のエディタをインストールしていますか？
人によっては、EmEditerだったり秀丸であったり、サクラエディタであったり、変人はxyzzyやVim、NTEmacs等のUnixの伝統を受け継いでいるエディタを利用している方もいらっしゃるでしょう。
ばばんばーんは何を使っているかというと、当サイトでもコンテンツを持っている萌ディタを未だに使っています。
このエディタ、設定ファイルがJavaScriptで記述されている＆拡張子ごとに設定ファイルがあるので、設定を自分で書き足してやることで
ショートカットから色分けからその他まで、大抵の事が拡張できてしまうのが最大の利点です。
アルファ版のまま開発が停滞して、そのまま作者が音信不通になってしまって、大変に不安定という最大の欠点がありますが
使い込んで、設定を拡張していけば、それを補って余りある程に利便性が高いため、結局手放せなくて今に至ります。
特に萌ディタの場合はJavaScriptを選んだというのが大きな利点になっていて
- 萌ディタは設定をJavaScriptで変更可能。
- JavaScriptはプロトタイプオブジェクト指向なので自分自身を拡張できる
この2点が螺旋の輪の様に重なり合って、２倍と言わず、２乗の拡張性を持っています。
特にここ半年、ハマって使っているのが、画面上にある１行入力バッファ。
ここにJavaScriptのコードを入れてあげる事で、エディタ側をJavaScriptで直接操作する事が出来ます。
最初はいまいち使い道の思いつかない機能だなぁと思っていたのですが、実際には大違い。
ショートカットに追加するほど頻繁には使わないけど、手作業では面倒くさい様な事をやらせるには絶好の道具だと言う事が自分でも分かってきました。
範囲選択した20行だけに行番号を振りたい！
メールアドレスの一覧から@以下のホスト名だけを取りだしてABC順に並べたい
こういうちょっとしたテキスト仕事に非常に、というよりはおそらくWindows環境ではもっとも楽に作業可能なのが萌ディタの利点といえます。
こういうときには、まず範囲選択をしてから
App.Caret.Selection.Text
を入力してやれば、範囲選択した場所を取得できるので、そこの部分にプログラムを与えてやるだけです。
App.Caret.Selection.Text.replace( );
実際には、App.Caret.Selection.Textとは毎回打ち込みたくは無いので、ここでエディタを拡張するやることで解決を図りました。
実際にはどうしようか若干悩んだのですが、JavaScriptにおいては貴重な$変数に、選択範囲のテキストを自動代入することにしました。
これで、良く使う「App.Caret.Selection.Text」を1文字に圧縮できました。
しかし、短くできるのはコレだけではない。
JavaScriptはプロトタイプオブジェクト指向の言語なのでオブジェクトの拡張が可能です
このメソッドが欲しいな、とかいちいち長い名前打ち込むのは面倒くさいなと思ったら、拡張してしまえばいい！
例えば便利なのは、各行ごとに処理を行うeachメソッド
選択範囲に行番号をつけたい場合は
$.each(function(s,i){ return i+'\t'+s; }).send()選択範囲のHTMLタグを削除したいときは
$.deltag().send();こうすれば短い行数で、やりたい処理が大抵出来てしまいます。
というわけで、ちょこちょこと暇なときに継ぎ足していっていた萌ディタの拡張スクリプトをちょっと公開
実際は、prototoype.jsとRuby（というよりprototype.js自体がRubyの影響下にある）から便利なメソッドを継ぎ足してみました
実際便利に使っている道具なので、興味があればドウゾ
投稿者 baban
2010/06/23 at 06:20
no comments
no trackbacks
投稿者 baban
2010/06/19 at 00:51
no comments
no trackbacks
誰かと思ったら、ゆうくんちゃんの、石川プロかよ！
どんな精細にして大胆な変態っぷりか、胸と股間が熱くならざるおえないぜ！
投稿者 baban
2010/06/18 at 21:17
no comments
no trackbacks
ふと思い返してみると、このサイト緩やかに続けてきてそろそろ9年になる事に気づきました。
というか2001年からなんだかんだで閉鎖も無く良く続いてきたものです。自分でも恐ろしい。(宇治軍団とかもっと長いサイトも界隈にはあるのですが･･･、しかもあそこは衰えたためしがない)
界隈も
- 著作権問題でビクビクした時期があったり
- M@D Scene;fixedとむびすれに踊らされたり
- 静止画作者がプロとして活動したり
- ニコニコ動画が台頭したりと、色々なことがありましたが
正直な所、おおよそここ5年を一言でまとめると完熟しつつゆるやかな衰退を続けてきた
これに尽きると思います
かつて、静止画系は界隈が若いので、と言われてきましたが
これまで残り続けて来た人が平均年齢を押し上げています。
良くも悪くも人が固定化されてきているので、良く知った面々が界隈をひっぱりつつ、逆に新しい人が加わるための障壁になってるようにも見えます。
俯瞰してみるとやろうかやろうか言いながら、ダラダラと続けてきたなぁ･･･と、内省してしまうのですが
ここ数年の新作の発表ペースの低下は、好きで見て見て好きになってまだ今でも新作に胸踊る人間としては悲しいところがあります。
この状況なんとかするのは簡単ではないのですが、どうやれば界隈が利用しやすい空間になるのかインフラを考えて見ると、実際には現在のインフラは2001～2002年ごろまでに出来たインフラを継承しているだけで、発展と言える発展に持っていけないままだったので
基本的なインフラをそろそろ時代に合わせてバージョンアップすべきでが一案ではないのかな、と自分では思います。
具体的には
- 東温DBの復活
- RSS対応の情報掲示板
- ニコニコ、zoomeの容認
かなぁと思っています。
投稿者 baban
2010/06/16 at 03:48
no comments
no trackbacks
前回のエントリで、スマートフォンだと、ページみにくい話をしたのですが
今回はその続きの話です。
なんとかスタイルシート側の工夫で、スマートフォンでもPCでも快適にサイトが閲覧できるか考え直すために
久しぶりに、css2の仕様書を見直してみたのですが、主な分類はこのようになっています
| all |
全デバイス向け |
| braille |
点字出力 |
| embossed |
点字プリンタ |
| handheld |
白黒の携帯画面 |
| print |
プリンタ |
| projection |
プロジェクタ |
| screen |
コンピュータのディスプレイ |
| speech |
音声 |
| tty |
文字のみ出力可能な低機能プリンタ |
| tv |
テレビ |
このとき久しぶりに気づく
あ、handheldって白黒画面向けなのね･･･
つまり
この条件を満たすメディアタイプは存在しないということです。
というわけで、結論から言ってしまいますが
smartmediaって名前で、携帯電話向けのメディアタイプを追加すべきではないでしょうか？
他にも、携帯ゲーム機やカーナビ等、それなりのCPUと画面サイズを持ったデバイスは色々とあります。将来的には、IT家電等も、小さな画面＋タッチパネルでの操作を持つデバイスの代表的なものの一つに入るでしょう
(実際には、現在それらのメディアはCSS2にそれなりに対応しています。個人的にはそんなことをするよりcss1に完全対応を目指して欲しい所･･･)
ついでに、ぶっちゃけた話。これだけメディアタイプが使われていない原因って、css2で宣言されているからなんですよね。
css1を完全に理解できないと、css2の仕様を取り込めない。でもメディアタイプに宣言されている点字機器や、白黒画面のデバイス、音声出力など、市場の小ささや機器の性能が低い事を前提とするデバイスにcss1の仕様を全て理解させるのは決して現実的な話ではありません。
この様な状況では、過半数以上のメディアがcssを理解するなと言っている様なものです。
なので、私は次の仕様を含んだ、css1の拡張であるcss1.1を作ることを提唱したいです。
- メディアタイプsmatmediaをメディアタイプとして追加
-
上記のとおりですが、正直そこそこ小さい画面＋フルカラーのメディアに対する仕様が存在しないのは初期設計のミスであったとしか言いようが無い
-
@import "foo.css" screen, tv いう形のメディアタイプの -
メディアタイプの定義の方法はたくさんありますが、現在一番良く使われているのはこれですので
css1.0程度しか理解できないブラウザに出来るだけ負担をかけないように実装させるためにこの仕様のみくぉcss1の方に落としてあげるべきだと思います
- @cssversion
-
cssのバージョンを、次の様にして定義します。
@cssversion "1.0"
これを文書の先頭で定義してやることで、自分の対応し切れていないCSSがある場合はシート全体の読み込みをパスします。
現在css3に対応しているブラウザとcss2までしか対応していないブラウザの切り分けをしないといけない問題が出ていますが
今後、様々なメディアタイプのスタイルシートの切り分けを行わなければならないことまで考えると、いいかげん、こういうバージョンでの切り分け機能が必要だと思われます。
規格と歴史にはベクトルと質量がありますから。ここを逃すとズルズルと代替手段の無いまま後方互換性の波に飲まれて規格自体が消えかねない所に来ています。
正直、それを考えると、CMS等を使わないでアマチュアがデザインを管理するためには、メディアタイプを有効に使うしかないし、今は、その最大最後のチャンスではないかと思っています。
こんなネットの片隅で叫んでもなかなかうまくはいかないのは分かっていますが、何方かこの危機を感じ取っていただける型の目に留まることを祈るばかりです
投稿者 baban
2010/06/12 at 02:34
no comments
no trackbacks
大分久しぶりですが、HTML、CSSのオハナシ。
最近、といっても2月末あたりなのですが携帯をAndroidのものに変更しまして
常時ネットワークに繋がっているカイカンを楽しませていただいているのですが
携帯向けの画面だと全体を見ると文字が小さいし、拡大すると全体が見えないんですよね
インターフェースの拡大、縮小機能が秀逸なので、大きなストレスにはなっていないのですが
ここでやっと気が付いた。
あ、cssのメディアタイプ切り分け機能ゼンゼン役に立っていないジャン！メディアタイプ、cssを使っている人だとおおよそみんな知っていると思うのですが
スタイルシートでデータを読み込む場合等に
@import "def/html-default-css2.css" screen, tv;
とすれば、特定のメディアタイプだけに表示の変更を行えますが
スマートフォンに適した形に、整形をするための切り分けがぜんぜん出来ていない･･･
というよりは、cssのメディアタイプという機能はCSSハックのときの道具に成り下がっている。
何故こんな事になっているのか？ 原因を手繰っていくと最初のcssの設計に辿り着く。
最初のcssは普及はHTMLにcolorやsize属性でデザインを埋め込んでいくのを出来るだけうまくやめるという当時の問題を解決するだけの非常にシンプルな設計だった
その後、css2が出てきたときに、その仕様は音声出力や印刷関連まで仕様を盛り込んだ、実装するには非常に重いものになりました
このとき一緒に入ったのがメディアタイプによる読み込むシートの切り分けと言う機能ですが
既にcss2はどのベンダーにも実装する機能が多すぎる負担の大きいものになっていた。
通常のPCでも重いものを、携帯デバイスが処理できるかと言うとそんなはずはないわけで
cssはiPhoneクラスのスマートフォンの登場と、PCと同じブラウザの搭載で解決されるまでの間があったのですよ。
こうなると、PC向けのスタイルシートだけ解釈させていればスマートフォンでも見れるじゃないか、画面小さいのは操作法で解決してネ！
デザイナでは操作できない領域だし
という方向に作る側の頭も働く。
でもですね。現実的には使っていて次の様な問題が発生するんですよ
- 単純に重い！Xperiaでも1GHz程度のCPUしかないのに、css3を使用したサイトを処理させようとするのはおかしい。他のプロセスを動かせたはずの領域を無駄遣いしている
- フルFlashやSilverLightを使ったサイトを大抵処理できないし、そこは振り分けるのが自然な解答
- PC向けのディスプレイ向けの設計をスマートフォンの小さい画面でみると平気ではみ出る
結局のところ、スマートフォン向けにページを作ったり、ページを切り分けたりする必要が出てくる
CMSなら、User-Agent情報から判別して切り分けることも出来ますが、全てのサイトがシステム化する現実は私には想像できない
現実的には読み込むスタイルシートをブラウザ側が選択するcssのメディアタイプが一番現実的です
なのでスマートフォンならスマートフォン向けに適したスタイルシートを読み込むような
使われるような形でのメディアタイプの見直しが必要なのではないかなと感じます
投稿者 baban
2010/05/30 at 00:13
no comments
no trackbacks
特に、代替産業らしい代替産業もみえていない状況で、そんなにユーザー数が増えているとは思えないので
ここ５年程度の業界の趨勢は微増というのが正しい解釈だと思う
投稿者 baban
2010/05/29 at 22:25
no comments
no trackbacks
最近 ようやく時間が出来るようになって、東方 緋想天則をやっています。
お前いつのゲームやっているんだよ！ という感じで半周遅れではじめているので、逆に情報が出揃っていて追いかけがいがある。
以前、EFZをやっていた頃の面白さに目覚めて久しぶりにゲームらしいはまり方をしています。
EFZ時代の操作性を継承しつつ、起き攻めn択からのコンボゲーをどうやって解消しようかという方向でいろいろと追加を行ってゲーム設計を行っているのが滲み出ていて
可愛げのある設計になっています。
EFZの頃は大口のコンボがありすぎて、ゲーム性が崩れていたのを抑制した作りになっているけど、実力の差はキッチリと現れるのが黄昏フロンティア流みたいですね
(コンボは逆に決まるとアドレナリン出るんですよね♪)
まだまだオフ会とかもやっているみたいなので、そのうち参加でもしちゃおうかしら♪
投稿者 baban
2010/05/22 at 21:05
no comments
no trackbacks