[home-page:放置中]
|
[最近のツッコミ] |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| [全文検索] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ☆基本的に個人的なリンク集、偶に思い出したように文章を綴る日記。 ☆JAVA・Ruby・RELAX NGネタ中心です。O:原文,P:ポップアップ辞書,t:和訳 ☆[category]：カテゴリフィルタ画面 ☆[blogger]：Blogger出張所。徒然。 ☆[kuro]：個人的ライブラリ開発プロジェクト「Kuro Project」サイト。 ☆[kuro-pj]Kuro Project開発日誌。 ☆[ruby]Ruby学習日誌。 ☆[vox]：VOX出張所。 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
MacOS Xのキラーソフトの一つになるかもしれない。
「Mac OS X 10.4 Tiger以降に対応しており、残念ながらWindows版は"まだ"無い。」
と書かれていますが、Windowsへの移植はまずありえないｗ。
サイトの何処をみてもWindowsへの移植には一言も言及されていないにも関わらず、
「"Mac OS X"で出現するソフトのWindows版は後から必ず出る」と思い込むのは
素人のあさはかさ。
/* to (on off) */
「Pixelmator」開発陣自体、サイトで"MacOS Xマンセー"を明らかに謳い、自分達が
Mac専業であることをブログで明らかにしている。
Windowsへの移植をほのめかしすらしていない。
ざっとサイトに目をとおした印象では明らかにMacOS Xの独自機能Core Imageに依存、
GPUへのアクセスもCore Image経由。
MacOS X固有の機能をフル活用することで実装コストを下げ、値段を手頃にしている。
開発陣がCore Image依存機能を自前実装で置き換えることに精力を傾ける...繁雑な
部分をCore Imageに任せることで機能の実装に集中できる今の状態を
壊すとは思えない。
Windowsへ移植するということはGPUへのアクセスetcのCore Image依存機能を全て自前で
実装するということ。PhotoshopはOSに依存しない構造になっているから実装コストがはね上がり、
値段も高い。同様の事を小さな規模の「Pixelmator」開発陣で実現することはまず無理。
実現できるにしても、そのコストは高額であり、今の値段での販売はありえない。
「Pixelmator」がバカ売れして、自前部分の実装コストを捻出できるようになれば、
Windowsへの移植はあるかもしれないが、膨大なコストを被る危険を冒すより
MacOS Xに依存するほうが堅実でありメリットも多い。
基盤部分の再構築というユーザに見えないコストの負担をユーザに求めてもユーザは
ついてこない。
MacOS Xに依存し、新機能の開発に注力するほうがユーザをひきつけるし、
ライセンスの販売も行いやすい。
メモメモφ。
メモメモφ。
メモメモφ。
メモメモφ。
メモメモφ。
->反論になっていない反論(on off)
ZopeはAPサーバとフレームワークとCMSが混然一体となったような造り。
Railsは汎用フレームワーク、CMSに特化したZopeとは比較できない。
Zopeの比較対象となるのはCMSであり、汎用フレームワークではない。
MongrelはAPサーバ、フレームワークは非内蔵。Java製APサーバと同じで
特定のフレームワークには非依存。Railsとの組み合わせが多いだけ。
PythonにはRailsを参考にしたTurboGearsがある。
Zopeが廃れたのはZope設計者のCMSに対するイメージが写像されすぎていて、
汎用的には作られていなかったからだと思う。
汎用フレームワークとして作られたRailsとは原点からして異なる。
[蛇足]
IBMがPHPに関心があったのは昔の話。PHPが一定規模以上のシステムには
適さないことがわかってからは急速に興味が失せた模様。
Zend社が枯れる前に余りにも大きな変更をPHPに加え続けていることも
大手SI企業の関心が削がれた一因だろう。
メモメモφ。
メモメモφ。
メモメモφ。
メモメモφ。
方針がころころ変わるのは確か。
T**d* etcのJCKパスも考えてるとか一時期言っていたような気がするけど...
いつの間にかそれも消滅。くーすも消えたし、ゴーヤは行方不明。
M*y** or S*JSF->T**d*(JSF互換)+拡張機能⇒S*Presentation(JSF非互換)、
S*Dao ⇒S*Persistence(JPAモドキ)。
Java Expert #1 でT**d*、K**n*を宣伝して...次の瞬間には...
方針変わりますってついてゆくユーザは大変だな。
S*PHPは？昨今はPHPも落ち目、今後の展開はゼロ？
次がS*Rubyだったら笑える。
もしかして、流行に流されるのが戦略ですか？
JavaEE対応も所詮、準拠レベルではないし、この際、スパッとJavaEE対応
を"謳う"のを止めるのが無難。
中途半端なEJB3対応をコンテナから削るのは誤解を招くよりは良い。
JavaEE、EJB3への対応は"準拠"レベルまでいかないとあまり意味がない。
"準拠"でないと、JavaEE、EJB3仕様との微妙な違いに悩まされるケースが気になる。
必然的にJavaEE、EJB3を採用する場合、"準拠"しているプロダクトを選定する。
規模の大きな企業ほど、この傾向が強いから、JBoss etcは"準拠"を取得する。
新機能は最新版で...がS**s**のポリシー。
S*モジュール群それぞれの最新版がS*コンテナの最新版でしか動かないケースが
多いのは乙。
青い海構想でS*コンテナの内部が変わってS*コンテナ次期版リリース以降の
S*モジュール群最新版がS*コンテナ次期版以降でしか動かなくなる可能性は90%以上。
S**s**にバックポートという言葉は存在しない。
#ブックマークしてる某氏、隠れキリシタン、みたいなモノか？
#隠れキリシタン⇒キリシタンじゃない振りをして、実はキリシタン...。
#この某氏、あからさまに怪しい。
メモメモφ。
メモメモφ。
メモメモφ。
メモメモφ。
メモメモφ。
メモメモφ。
メモメモφ。
メモメモφ。
メモメモφ。
メモメモφ。
メモメモφ。
メモメモφ。
メモメモφ。
メモメモφ。
メモメモφ。
メモメモφ。
メモメモφ。
メモメモφ。
メモメモφ。
メモメモφ。
メモメモφ。
メモメモφ。
メモメモφ。
メモメモφ。
メモメモφ。
メモメモφ。
メモメモφ。
メモメモφ。
メモメモφ。
メモメモφ。
メモメモφ。
メモメモφ。
メモメモφ。
メモメモφ。
メモメモφ。
メモメモφ。
メモメモφ。
メモメモφ。
メモメモφ。
メモメモφ。
メモメモφ。
メモメモφ。
メモメモφ。
メモメモφ。
メモメモφ。
メモメモφ。
メモメモφ。
メモメモφ。
メモメモφ。
メモメモφ。
XPNo5な人物って...、「時間に対しての対価ではなく、"仕事"に対しての対価」
「仕事が速くて期日までに自分の担当作業を終了して"質"も一定水準ではじめて"１日８時間"」
「クライアントは時間に対して対価を払うのではなく、仕事(の内容)に対して
対価を払う」等々の基本を度外視しているんだろうな、きっと。
「自分がクライアント(所属している会社も含む)に対して責任を果たしているか」という
視点が欠落しているところが何ともいえない。この視点が欠落していることに気づくのが
遅れれば職業人として致命的。この場合の責任範囲が対価により規定されるのは自明。
XPNo.5な人物は常に他人が尻拭いをすることになるのでいらない。
XPNo.5な人物とはeXtreme Programming No.5(?)「１日８時間」"のみ"を実践している人物のことです。
期日までに自分の作業を一定の品質を確保して終了できないケースは多々ありますが、許容範囲を
超える(対価に見合わない)作業量が割り当てられているケース以外はXPNo5な人物サイド
の問題だと思います。許容範囲を超える(対価に見合わない)作業量を割り当てることが
恒常化しているプロジェクトはマネージメントの問題と考えます。
自分の担当作業(のうち自分の能力(対価)に相応の作業量)を期日までに一定の
品質を確保して終了することが「1日8時間」を実践するための必須事項でしょう。
それを満たしていれば、マネージメントする側も苦々しくは思えど、外す話にはならないはず。
メモメモφ。
メモメモφ。
メモメモφ。
メモメモφ。
メモメモφ。