国内でZopeを普及させる目的の会社設立 65
ストーリー by Oliver
時代に勝て 部門より
時代に勝て 部門より
hebereke 曰く、 "日本に於けるZopeの普及を目標に掲げた会社、breakbeansが設立された。代表は桜井通開(mojix)氏。事業内容として教育とコンサルティングが挙げられている。
ここ半年から1年足らずで個人ベースでの認知と普及は急速に進んだが、欧米での事例からZopeのポテンシャルを見れば、日本ではまだビジネスでの活用が少ないと言える。
理由は様々だが、ひとつの側面としてbreakbeansのようなZopeをビジネスで展開する旗振り役が居なかったことが挙げられる。
常に日本のZopeシーンを先頭に立って切り開いてきたmojix氏だが、ビジネスシーンに駒を進めた氏の今後に注目したい。
またJZUG設立や全国布教行脚、記事連載など氏の活動はZope普及に大きな影響を与えてきたが、会社化されたことによりより安定した活動が出来るようになるのではないかと期待する。Zopeの発展とともに、氏の今後の一層のご活躍をお祈り申し上げる。"
アプリケーションサーバじゃないよ (スコア:3, 参考になる)
Zopeを紹介するもので「アプリケーションサーバ」という記述がされている場合がよくありますが、Zopeはアプリケーションサーバではありません。"Z Object Publishing Environment"と言うように、主に出力系を制御する為のものでしかないのです。だからPython<->JavaだからZOPE<->Servletにはならないんですよね。
だから「何をどう表現すべきか」は得意だけど「何をどう処理してからどう返すのか」は得意じゃないと思います。得意じゃないというのはZOPEではなくてPythonに持ち込めば全然できちゃうからです。
だから社内イントラ等でWeb経由の文書管理をしたいときの様な用途にはめちゃくちゃなコスト&管理パフォーマンスを期待できるんだと思います。プロダクト使えば開発すらする必要もないしね。
職業としてのプログラマ
Re:アプリケーションサーバじゃないよ (スコア:1)
>「何をどう表現すべきか」は得意だけど「何をどう処理してからどう返すのか」は得意じゃないと思います。
すると、処理結果を見せるのではなくモノ(Object)を見せる、という感じですかね。
動態よりも静態を扱う(見せる)ほうが感覚的にピンと来る俺としては、
もし上記の通りだとすれば、嬉しいです。
>得意じゃないというのはZOPEではなくてPythonに持ち込めば全然できちゃうからです。
「処理結果Object」を作る、ってな感じですかね?
Re:アプリケーションサーバじゃないよ (スコア:1)
> すると、処理結果を見せるのではなくモノ(Object)を見せる、という感じですかね。
モノ(Objects)の見せ方を定義するための仕組みだと理解しています。たとえばJZUGのページを見て頂ければよくわかると思うのですが、ページの基本的なレイアウトは同じで、内容と左に現れるメニューが変化していく様に。どっかにこのサイトのソースが公開されていたんじゃないかな?見てもらえれば何を作っていけばこういったサイトができあがるのかがわかると思いますが、設計さえよければ個々の内容を充実させることに専念できるようになります。実は同じような発想のモノでwmlってモノがありますが、これはhtmlを生成する為の仕組みでしかありません。
補足をさせてもらうと「処理結果」とひとまとめにされると困る訳で「処理」が苦手である、特にservlet等の業務にも使えるようなロジックをどんどん書いていくような仕組みはとても作りにくいということです。DTMLとかZPTとかは言語としてはかなり不自由な部類だと思いました。
ですので、
> 「処理結果Object」を作る、ってな感じですかね?
ではなくて、「ZOPEが提供する言語では処理が出来ないようなものは外部に丸投げして、あたかもその処理結果を扱うべきコンテンツとして」出力することが出来る。これはちょうどSSI的な使い方だと思います。
職業としてのプログラマ
Re:アプリケーションサーバじゃないよ (スコア:1)
Re:アプリケーションサーバじゃないよ (スコア:1)
ZPTは1ページ単位のテンプレートに、どんなオブジェクトを組み込むか、ページを表示する瞬間に何か条件判断(i.e. 検索結果が1件以上あるか)を行うかを指定したりできるようです。
# 慣れてないから、よく知らない。
DTMLでの例だと、こんなのはどうでしょう。
たとえば、こんなフォルダ構造になってるとします。
(root)
├ standard_html_header (画面表示用のHTMLヘッダなど)
├ standard_html_footer
│
├ standard_print_header (印刷用のHTMLヘッダやCSSとか)
├ standard_print_footer
│
├ index_html (フォルダにアクセスしたときのデフォルト・テンプレート)
├ print (印刷用テンプレート)
│
└ Folder
├ contents (表示したい文章その1)
└ Folder2
└ contents (表示したい文章その2)
/.のように、ページを上部メニュー、左側メニュー、コンテンツ、右側メニュー、フッタで構成するなら
http://localhost/Folder/ にアクセスすれば画面表示用、
http://localhost/Folder/print にアクセスすれば印刷用
というように、用途に合わせて異なる表示ができます。
「表示したい文書その2」も
http://localhost/Folder/Folder2/ で画面表示用、
http://localhost/Folder/Folder2/print で印刷用
と、同様に作成できます。
印刷用のprintの中身は、こんな感じ。index_htmlとの違いは、ヘッダとフッタの指定が異なるだけですね。
# 詳しくは書籍でもWebページでもRe:アプリケーションサーバじゃないよ (スコア:1)
あれは、出力テンプレート作成用でZPTもお同じです。
ロジックをあれで書くと、とんでもないことになります。
ロジックは、Pythonで記述して出力テンプレートと分離しないと。
私見ですが、「アプリケーションサーバー」の要件は満たしてると思いますが。どうでしょう。
hoihoi-p 得意淡然、失意泰然。
選択肢としてのZope (スコア:3, 興味深い)
スラドにタレこまれて光栄です。
ひとまず私がやりたいのは、選択肢としてのZope / Pythonがあるんだということをビジネスレベルに普及させることです。
Java系のものとどっちかいいかといった話は、やりたいことや、技術レベル、予算などの状況によって一概には言えないでしょう。Zopeのほうがベターだという状況もそれなりに存在する以上、Zopeの会社があってもいい。
Zopeという選択肢があることを知らずにWebをやっている個人や会社に対し、Zopeというものがあることを知らせたい。また、サーバサイド技術そのものをやったことがない人の入門ツールとしても、Zopeは素晴らしいと思います。無償だし。
すでにZopeを知っていて、Zopeをダメだという人にはそれなりに説得力がありますが、知らずに拒否している人、ぜひやってみてください。少なくとも、なんらかのインスピレーションを受けることは確実だと思います。
Re:選択肢としてのZope (スコア:1)
でも、出てきた費用は市販のソリューション購入とほぼかわらない金額。それに、こちらの要求仕様を無視してすべてのデータをZope内に収める仕様になっていました(他のDBに、って言ったのに…)。
個人的にはぜひ活用したいとは思っていますが、これではちょっと。
ごく基本的なことの組み合わせなので、自分でできるようになればすむ話なんですけどね。
面白そうですね (スコア:1)
業界人じゃないからあまりわからないけども、隙間狙いで一社ぐらいそういう会社があってもいいと思う。Javaでいく会社はすでにたくさんあるから新しく会社を興しても目立つことは難しいと思いますし・・・。
他力本願。
キラーアプリ (スコア:2, おもしろおかしい)
今年のLinuxWorldで見せて頂いたときに大爆笑した記憶があります。
#/.-Jerの皆さんの場合にはこちら [squishdot.org]のほうがいいかもしれませんね。
教えて欲しいこと (スコア:1, 参考になる)
Re:教えて欲しいこと (スコア:2, 参考になる)
てとこですかね。これくらいのこと、Zope説明してるサイトなら
大抵書いてあると思うけど、念のため。
Re:教えて欲しいこと (スコア:1)
こういうのでもできるようですよ(検証してませんが)。
運用次第ではApache使わなくてもいいみたいです。
http://www.apsis.ch/pound/
-- (ま)
Re:教えて欲しいこと (スコア:1)
Web Serverが内蔵されていますからね。
逆に、特に理由がなければApacheを使わない事のが多いようです。
Yasuda
Re:教えて欲しいこと (スコア:0)
まぁ、同じ事かもしれませんし、ユーザ数なんてのは鶏と卵の関係で増え始めたらどんどん増える面もあるので、現時点でのユーザ数は将来性には直接関係無いから、「短所」と言うのもどうかという気はしますが。
Re:教えて欲しいこと (スコア:0)
も。(・_・;)/
---
どうでもいいことなのでAC
Re:教えて欲しいこと (スコア:1, 興味深い)
WebObjectsの方が (スコア:1)
Re:WebObjectsの方が (スコア:1, 興味深い)
Re:WebObjectsの方が (スコア:1, 参考になる)
特にWebObjectsに関しては、採用している企業を知っているのですが(誰でも知っている出版社ですが)、そこの担当者が「おちた事がない」つう事で、大変気に入っています。
また、日産なども採用していたり(今してたっけ?)、運用実勢もそこそこあるんではないかと・・・
ただ、これら二つを同じ土俵に載せるのは、若干無理があるかなって思うんですけど、いかがでしょうか?
#ネタ暴露気味なんでAC
Re:WebObjectsの方が (スコア:0)
氏のノートはLinuxで(苦労が多いからOSXに乗り換えちゃるって言ってましたが)mozillaが組み込まれてコーディングとプレビューを往復していたような
Re:WebObjectsの方が (スコア:1, 参考になる)
ただ、結局Webサーバのサービスとして組み立ててくから、Servletなどと同じで、サイトの統合的なものを構築するには、がちっと仕様を決めて取りかからないとパーソナライズなど実現しにくいんでは、、もひとつ上のフレームワークがないと、、
一方、Zopeは全体が1つのサービスなので、個々の機能を連結したりするのが結構楽。MyYahooみたいなのはpython使わなくてもできるね。あとは安定性ですが、一応負荷分散もできるし、サーバ側は落ちたこと無いな。高負荷のもとではクライアント側は落ちるね。
Re:WebObjectsの方が (スコア:0)
Zopeはftpサーバにもなります。ange-ftp使えばemacsで幸せです。
あと、WebDAVもオッケーです。
Re:WebObjectsの方が (スコア:0)
Zopeは入手に金額を要求されないぶん、まだwebアプリケーションに
明るくない私のような人間には気軽に入手できてありがたいです。
ニュースソース補足 (スコア:1)
HTMLの記述をミスったのかニュースソースへのアンカーが抜けているようなので補足させてください。
Zopeで作っている? (スコア:1)
breakbeans [breakbeans.com]
のWebサイトはZopeで作られているんですか?
そんな感じはしなかったのですが。
Masafumi Otsune [otsune.com]
Re:Zopeで作っている? (スコア:1)
Zopeの機能を盛り込もうとしすぎていて、最低のデザインになっている、とか?
Re:Zopeで作っている? (スコア:1)
「http://zope.jp/bookmark/」あたりを見ると、わかるかも。
>Zopeの機能を盛り込もうとしすぎていて、最低のデザインになっている、とか?
ってことはないと思うけどね。
普通にHTMLをエディタで手書きしてれば、デザイン面では特にZopeの機能には依存してないよ。
ただ、Squishdotがわりと使いやすいプロダクトなので、それベースのわりと似たかよったかのデザインの物が多いんじゃないかなあ。
そうするとわりとTABLE中心のレイアウトになりやすい。
自宅や社内のZopeで動かしているローカルなサイトでは、XHTMLとCSSばりばり使ったソースだけど。
Zopeのことはほとんど知らないのですが (スコア:1)
W3C原理主義者としては、日本Zopeユーザ会 [zope.jp]や、breakbeans [breakbeans.com]やらを見るだけで使おうという気が無くなります……
まぁ、私のような原理主義者はごく少数でしょうが、多少は綺麗なHTMLを公開していただけると嬉しいな、と。
P.S. Cのコーディングにうるさい人は多くても、HTMLのコーディングはえらいいい加減な人が多いのは何故だろう……
Re:Zopeのことはほとんど知らないのですが (スコア:1)
別コメントにも書きましたが、別にXHTML+CSSのソースでも作成できますよ。おそらくもとにしているテンプレート(「Standard Html Header」とかの流用できるパーツや、Squishdot等のプロダクト)がそうなので(TABLE主流のレイアウト)、そのままそうなっているサイトが多いんだと思います。
>P.S. Cのコーディングにうるさい人は多くても、HTMLのコーディングはえらいいい加減な人が多いのは何故だろう……
これについては完全に同意。
Re:Zopeのことはほとんど知らないのですが (スコア:1)
>これについては完全に同意。
多少間違えててもブラウザが表示してくれたり、
HTMLエディタがタグ中で改行するような適当なものを出力してくれたりで
言う気力が抜けちゃったのではないかと思ったり思わなかったり。
はすかわ
Re:Zopeのことはほとんど知らないのですが (スコア:1)
「htmlのソースが論理的に美しくない」という事だと思います。
たとえばhtml文書で、レイアウトを保つためにフォントのサイズ
決め打ちがあったり、とか、「閲覧側の環境を決めウチ」するHTML文書が大半ですが、アレは歳をとって、遠視になると
「めちゃくちゃみえねー」
という、最悪のページに変貌したりするんです。
年寄りになると、遠視になって、小さい文字がめっちゃめちゃ
見えなくなって、デフォルトのフォントを一回り大きくしたく
なりますからね。
ですから、閲覧者の状況にあまり依存しない形で、特にレイアウト
してほしーなーと。
で、こういう方向を考えると、結局凝ったレイアウトより、
論理的に素直なタグを使う方が結局はよろしいようです。
-----------------
#そんなワタシはOS/2ユーザー:-)
Zope と Java (スコア:0)
ところで今じゃ Zope も Python オンリーじゃなくなったけど、 Python は Java とモロに競合する言語なんだよなぁ。 Java が作られなかったら今頃は Python がその地位を占めていた可能性もある。 思えば Java ってあえて作る必要がない言語だったのだなぁ。
Java の方が絶対イイって。 (スコア:1)
Re:Java の方が絶対イイって。 (スコア:1)
Re:Java の方が絶対イイって。 (スコア:0)
その代表がGoslingですよね。
# マジだけどAC
Re:Zope と Java (スコア:1)
Zopeで始めるのは、Servletで始めるより楽だと思うけどね。
あとはCMFかなぁ(あまり触ってないので自信無し)。
#Pythonの方が好きだけど、確実にJava触ってる方の時間が長いし…
-- 雪のない富士山もきれいだな
まずPythonをどうにかしないと (スコア:0)
俺使ってるよとかそういうんじゃなく、冷静に判断してさ。
Re:まずPythonをどうにかしないと (スコア:2, 参考になる)
また、最近見つけた pyDDR [clickass.org] というゲームは、Python で書かれてました。
Re:まずPythonをどうにかしないと (スコア:0)
goolgle先生によると、
「python script」
-約384,000件
「ruby script」
-約94,500件
#この調べ方が適切かどうかは置いといて。
日本的に見ると… (スコア:1)
「python script」
-約2,340件
「ruby script」
-約7,100件
#この調べ方が適切かどうかは置いといて。
Re:まずPythonをどうにかしないと (スコア:0)
キラーアプリケーションって奴です。
蛇足、ZopeではPHPやPerlなども使えるです。
# Blenderに触れてPython本を買って眠らせ
# Zopeに触れて再び紐解く
Re:まずPythonをどうにかしないと (スコア:0)
で、 (スコア:0)
WebObjectsみたいなもん?
Re:で、 (スコア:1)
微妙。 (スコア:0)
ていうか、zope.jp を見てれば、mojix 氏にその、リード能力があるかどうかはつくづく疑問。で、結局分裂?したわけだし。zope.jp 内にもコア ./er はたくさんいる(た?)のにタレ込み遅いしね。
Re:微妙。 (スコア:0)
Re:微妙。 (スコア:0)
こういうやつ? [kaishajiten.com]
Re:微妙。 (スコア:1)
主に日本で活動する場合、日本での営業権を取ればいい。
これが最もローコストに株式会社を立ち上げる方法だとか。
日本みたいに、資本金がいくらいくらっていう厳しい制限がない。
もちろん、株式会社の税金面での特典は利用可能だそうだ。
ちなみに、あっちの事務所か何かに手数料さえ払っておけば、
ずっと日本ばかりで活動していても、文句は言われないとか。
あと、メンバーが米国に渡航するときに優遇されると
聞いたような気がするな。
ただし、この会社が既に日本のドメインを取っていた場合、
この方法は使えなかったと思う。
Re:Zope 2.6.0がリリースされたというのに... (スコア:1)
http://ml.zope.jp/pipermail/zope-devel/2002-October/000502.html
または↓これ
http://ml.zope.jp/pipermail/zope-devel/2002-October/000546.html