ウィキペディアがライセンス条項をGFDLから変更しようとしている。yomoyomoさんがこう書いている。
既にニュースサイトでも伝えられているが、Wikipedia のライセンスに CC by-sa を採用するかどうかの投票結果が出た。実はこの後財団理事会の決議がまだあるのだが、ここまで来たらもう決まりと言ってよいだろう。
賛成76％という結果は、およそ一年半前にその道筋がついた時点で予想したよりも賛成が多い印象である。それだけ GFDL が好かれてなかったのか。
最近のクリエイティブ・コモンズのライセンス周りの話題 - YAMDAS現更新履歴
ここでひとつ告白しておくと、僕は非常に法律やライセンスに蒙い人間だ。だからライセンスの良し悪しについてはyomoyomoさんや八田さんのようには語れないし、一方で好き嫌いのレベルでは思うことがある。
●
採用が見込まれているCC by-sa、クリエイティブ･コモンズ「表示･継承」のページには、次のように書かれている。
これは一般の方に読みやすいようにした利用許諾条項の要約です。
Creative Commons Attribution-Share Alike 2.1 Japan
実はこのページは、利用許諾条項そのものではなくて、利用許諾条項の重要な一部分を平易に説明した「コモンズ証」というページ。このページに見られる、Creative Commonsの以下2点を、僕はとても大切なことなんじゃないかと思っている。
- 公式に日本語でライセンス条項が発行されている。「正式版は英語です」などという但し書きにおびえて、英語の原文を読まなくていい。
- 公式に平易なバージョン「コモンズ証」が作成されている。私的解説の「筆者の解釈によるものであり」などという但し書きにおびえて、詳細確認の必要のないうちから利用許諾条項に目を通さなくていい。
実生活において僕は（おそらく僕以外の多くの人も）、コモンズ証レベルの法律理解に基づいて暮らしていて、何も六法全書を諳んじてはいない。正直に言えば僕は、六法全書を通読したこともないし、実は持ってもいない。それでもたぶん法に反したことはせずに暮らしているし、社会と折り合いをつく範囲で楽しくやれてる。
「日本語」の「コモンズ証」があることは、僕に実生活と同じ程度の善意と順法意識だけで、クリエイティブ･コモンズライセンス採用サイトでよく振舞うことができるようにしてくれる。
●
統計ページによれば日本語版だけで3万5千近いユーザー登録した編集者を誇るウィキペディアが、GFDLへの共感を醸成するでもなしに、GFDLの理解と厳守を強要しているように見えたのは、僕にはちょっとムリのあることをしているなと感じられた。
3万5千人（そしておそらくはもっとたくさんいるIPユーザ全員）に「悪いことしちゃダメよー」ぐらいならともかく、「ちゃんと規約読んでねー、細かいこといっぱい書いてあるから守ってねー、英語だけど誤読しないでねー」というのは、どうかと思ったんだ。もうちょっとライセンス策定者かライセンス採用サイトが、利用者が簡単に違反せずにいられる仕組みを持ったらいいと思うけど、GFDLはそうしていなかったと思うし、ウィキペディアもそれはできていなかったと思う。
みんなが簡単に「よく振舞う」ことができないようなルールは、あまり好きじゃない。そういう意味では、「GFDLとウィキペディア」という組み合わせはちょっと嫌い。「クリエイティブ･コモンズとウィキペディア」の組み合わせは、日本語版コモンズ証のようなものがあるというだけで、ちょっと好き。
●
改めて、僕は非常に法律やライセンスに蒙い人間だ、と書いておく。とんでもない誤解とか偏見に基づいてこう書いているかもしれない。GFDLとかウィキペディアもいろいろがんばっているのかもしれない。ただ、気持ちのところではたぶんみんなと同じことを思っていて、その上でCC by-saの採用を好きだと言えていると思う。
ウィキペディアが、もっと気軽に、気持ちよく付き合えるサイトになってくれればいいな。そう思う。
IBMのdeveloperWorksに「企業ウィキにシグネチャを」という記事3本を寄稿しました。長すぎるので3本に分割、でも話が分かれていな過ぎるので一挙掲載、というわがままを聞いていただき、昨日まとめて公開されました。
本日、下記の企業内 Wiki に焦点を当ててシグネチャの重要性を説いた日本独自記事3本を公開しました。
- 企業内ウィキにシグネチャを: 第 1 回 ウィキサイトの規模不足を考える
- 企業内ウィキにシグネチャを: 第 2 回 シグネチャによるウィキへの参加動機の強化
- 企業内ウィキにシグネチャを: 第 3 回 企業内ウィキでのシグネチャの役割
第1回では、一般的なウィキサイトの規模感と、規模の必要性、特にコンテンツ量とコンテンツ作成・更新への参加者数の必要性を説明します。続く第2回では、一般的なウィキへの参加動機を探り、参加動機の強化のためにシグネチャの明示を導入することを提案します。最後に第3回では、企業内ウィキに焦点をあててシグネチャの必要性を再確認し、同時に参加動機付けの他にもシグネチャを導入することに価値があることを見ていきます。
（「企業内ウィキにシグネチャを」シリーズの公開 - developerWorks Japan 編集長のブログ）
まず今回の恩人にお礼を。「Wikiばな」スターターのshinoさんは今回、「明後日までに50KBのテキストを読んでコメントくれる人」という私の無茶な呼びかけに答えてくれ、非常に文章をきれいにしてくれました。もし今回の文章が読みやすかったとすれば、shinoさんのリライトのおかげです。
●
それからこの記事に至るまでの3年ほどについて。
2007年8月にenNetforumで講演をし、その資料を公開しましたが、その際に「社内Wikiについては昨年の春から検討をはじめて、早1年半になります」と書きました。実を言えば2006年春に、技術評論社さんから企業ウィキについての本という企画をいただいたのですが、Wikiプログラマの私には「社員にとってのウィキ」は書け、「IT管理者にとってのウィキ」は1年かけてなんとかまとめてここまでを講演で発表しました。
しかし、それでも「企業にとってのウィキ」は理解できないまま、筆を進められませんでした。ここのギャップは「使いたい人だけが使いたいように使うウィキ」「使いたい人には使わせてあげるウィキ」という許容、放任から「ウィキを使う動機付けをする」「ウィキから創発を導き出す」といった推奨、活用へ、ウィキ提供者が積極的な意思を持つことにあるのだと思います。そして私にそちら側の視点を想像することもできなかったのだと思います。
その後Wiki小話で意見を聴き、直前のBusiness Blog & SNS World '07、特にIBMの森島氏の講演（今回資料の一部を転載させてもらいました）、みずほ情報総研の佐藤氏の講演などを入口にEnterprise 2.0というテーマについて勉強をはじめ、動機付けという一面についてwikipedia.silube.comというサイトを作ってみたりこうして文章を発表したリ、というところにたどりつきました。やっと、再スタートを切れたという感じです。
●
「企業ウィキ」というのは、十分に大きく、エキサイティングで、最後まで考え抜きたいテーマです。企画は賞味期限切れにしてしまったと思い、それについては申し訳ない思いでいっぱいなのですが、このテーマを与えてくれた技術評論社の馮さんにも感謝を。
そしてBBSNS07開催者、講演者、WikiばなやWiki小話参加者、enNetforumフォーラム（現EGMフォーラム）各位、2006年～2007年当時に取材をさせてくださった各社の方々、Enterprise2.0の実地を与えてくれたOKIのCrossba（立ち上げから今日までの）関係者各位にも感謝を。
本当に、ありがとうございました。
Web 2.0コンサルタントDion HinchcliffeによるEnterprise 2.0の2007年の修正コンセプトを、彼のZDNet.comブログのエントリ「The state of Enterprise 2.0 | Enterprise Web 2.0 | ZDNet.com」で見つけた。2007年11月とかなり前の話だが、ググってみても日本語でSLATESを説明している記事などは見つかるが、FLATNESSESを取り上げているものは見つからなかったので紹介しておく。
本文中にあるように、Andrew McAffeeがEnterprise 2.0を提唱した際の論文「Enterprise 2.0: The Dawn of Emergent Collaboration」で、彼は「知的労働者の行動とアウトプットを可視化するためのプラットフォーム」をEnterprise 2.0と命名し、このプラットフォームが担うべき機能として、SLATESというコンセプトを掲げた。これは以下の頭文字をつなげたものだ。
- Search（検索）
- Link（リンク）
- Authoring（文書化、発表）
- Tagging（タグ付け、分類）
- Extensions（拡張、たとえばリコメンドなどを介してによって他者の思考や活動を刺激する）
- Signals（通知、RSSフィードなど）
私が「Enterprise 2.0 : 社内Wikiの目的」に入れた図は、これが機能する一連の流れの、一パターンを想定したものだ。2007年8月のプレゼンを聞いてくれた人は、この図の隠れているオレンジの丸にSLATESの各単語があったことを覚えているかも知れない。2007年11月のHinchcliffeのブログエントリでは、この6つ（※）に以下の4つを追加して、FLATNESSESという改定案にまとめられている。
- Freeform（非定形）
- Network-oriented（ネットワーク指向、ウェブベースであることと、再利用可能でアドレス（URLなど）で指し示せる小片指向であることの2つを指す）
- Social（ソーシャル、非階層的で透明性の高いもの）
- Emergence（創発）
非定形であることについては、グループウェアとのすみわけを考える上で、常に意識にあった。ツールとしてのウィキ（しばしば一人ウィキ）を使う理由は、しばしばここにある。グループウェアのようなWell-formedなツールにそぐわない情報の受け皿、あるいはWell-formedなツールを作るためのプロトタイピングとして、ウィキは有用だ。創発は、最近のこうした分野の話ではしばしば取り上げられる注目の話題でもある。Network-orientedであることの必要性はウェブユーザの多くは自然に頷けるだろうし、Socialとあわせて「言わずもがなだけど、あえて指摘するのも悪くない」と思う。
つまり、私個人としては、総じて「SLATES」の修正版である「FLATNESSES」をEnterprise 2.0のコンセプトとして受け入れるのに異論はない。ただ会話中に時々、SLATESですら各要素が何だったかを思い出せなくて困る（特にExtension）。FLATNESSESとなると、そんなことがますます増えそうなのは心配だ。
※AuthoringがAuthorshipと改められているが、ここでは同等のものとみなした。
Confluenceの開発元であるAtlassian社の共同創設者兼CEO、Mike Cannon-Brookesによる「Organisational Wiki Adoption」を、同氏の承諾の元に和訳しSlideShareで公開しました。ブログエントリの日付は2007年10月になっていますが、編集用にKeynoteファイルをもらったら表紙がこう変わっていたので、この内容で2008年5月にも講演しているのですね。
「企業内ウィキはウィキペディアではない」はずっと僕の考えていたことでもあります。少なくとも、最初から企業内ウィキペディアをイメージして導入しようとすると、成功率は著しく低いように感じます。
じゃあ企業内ウィキとは何かというと、Mikeいわく「パブリッシングではなくコラボレーション、百科事典ではなくツール」とのこと。僕自身は、現状としてMikeの説を受け入れつつ、将来像としてウィキペディアを夢見ることができないか、悩んでいるというのが昨年来の話。
このエントリを読んでくれる人の意見がどちらか分かりませんが、Mikeのスライドは分かりやすくて役に立つと思うし、これに沿って企業内ウィキを試みてみるにも、これに反論するところから考えを深めるにも、良いスタート地点になると思います。
OpenPNE 3.0がリリースされた。
私たちは「あらゆる組織にOpenPNEを提供する」ことをめざし、OpenPNEプロジェクトをすすめています。
OpenPNE3.0のテーマは「プラットフォーム化」。OpenPNEをあらゆる組織のプラットフォーム、インフラとするための、数多くの機能改善を行いました。
本バージョンの特徴は以下の通りです。
- 国際化を実現
- プラットフォーム化を目指し、多彩なAPIを搭載
- 外部サービスとのID連携が可能に OpenID対応
- そのほかの技術革新
- OpenPNE3.0上で動くアプリケーション
昨夜未明までtrunkを動かしてきた感覚でいえば、SNSを運営するためのシステムというより、まだSNSを開発するためのベースという感じ。OpenPNE2相当の機能がそろって安定動作するのは、もうちょっと先かな。今日になって一気にリリースされている可能性はあるけど。
それでも、かなり動く部分は動くし、触りはじめるにはいいタイミングだと思う。僕も、合間合間を見て、少しずつ触っていきたいと思っているし、実際に気が付いたことはsns.openpne.jpやtrac.openpne.jpで報告し始めている。
まずは無事リリース、おめでとうございました！
（関連記事）
うごメモはてなで、不適切な作品についての通報に対して、はてなポイントを付与するという発表がありました。
うごメモはてなで通報を受けた作品を、はてなの管理者が確認して不適切であると判断、非公開とした際に、その作品について最初に通報いただいた方にはてなポイントを 5ポイントを付与します。
不適切な作品を通報いただいた方に「はてなポイント」の付与を開始します - うごメモはてな日記
2点、気になったことを。
「最初に通報した人」だけにポイント付与でいいのか？
ポイントを目的にパトロールする人にとっては、最初の通報者にならなければいけないから、「疑わしきは通報」することになりそうな気がします。「掲載ガイドライン」の禁止事項には、キス、抱擁、対戦格闘・ケンカ描写、非合法なギャンブル、言語・思想関連の不適切な描写が含まれます。かなり広い範囲、普通に見れば別にいいんじゃないかと思うようなものも、「疑わしくなくもない」に入ります。
「はてなポイント」でいいのか？
上記アナウンスに「『はてなポイント』て何？」とコメントがついています。うごメモはてな内では、はてなポイントを使う場面はなさそうです。うごメモだけを（でも熱心に）楽しんでいるユーザ層には嬉しくもなんともなく、それが何なのかすらわからないのです。一方で、他のはてなサービスユーザには、うごメモは使ってなくても、うごメモをどうでもいいと思っていても、嬉しい報酬です。
「うごメモが良くなって、ポイントももらえるなら」というパトロールは良さそうですが、ポイントだけが目的のパトロールだと「疑わしきは通報」が激しくなるでしょうし、「ユーザの適応的行動は自動でそれを行う事」とうそぶく向きも増えるでしょう。コンテンツが根こそぎになっても、サイトがつまらなくなっても良いのですから。報酬は、少なくともうごメモユーザみんなが嬉しいもの、できればうごメモユーザ以外には嬉しくないものが良かったように思います。例えば、作者ページに合計が表示されている（それだけの）はてなスターでも、はてなポイントより適切だったのでは。
2点挙げましたが、報酬がはてなポイントだったことは、はっきりと不適切だったのではないかと思います。
Windows環境で「定期的にRSSなどをチェック、新着情報をポップアップ表示」させたいと思って、簡易的なフィードクローラ“feed2growl”を書いてみました。次のような特徴があります。
- 新着情報をGrowlに送ります。
Growlなので、新着情報がポップアップ表示されます。Growl for WindowsやWhineでもOKです。 - タスクに登録して定期実行しやすいように配慮しています。
exeファイルは、定期実行時にコマンドプロンプト風の画面が出ないようになっています。
プロキシ情報はInternet Explorerから取得するので、環境変数などを気にしなくてOKです。
ただし使おうと思うと、Growlの設定ができること（私はWhineを使っています）、config.ymlを見て、何となく設定ができることが必要です。Perlスクリプトとしては、「LWP::UserAgent::ProxyAnyを使う」「Net::GrowlClientを使う」「タスクに登録しやすいexeファイル化をする」が個人的な今回のチャレンジ。むしろ、これらのサンプル程度にでもお役に立てば。
シンクライアントは死んだが話題になっている。
今日、IT業界の著名なコンサルタントである、日本IBM出身のK社のNさんのオフィスにお邪魔してた。（略）Kさんは開口一番、「シンクライアントは死んだね」とおっしゃった。
値段が下がらない、家に仕事を持って帰れない、サーバに負荷がかかる、既存パソコンを排除できない、そして不況、を挙げる。その上で、既存のパソコンのセキュリティーレベルを挙げれば済むことだと切って捨てる。
IT業界来し方行く末 > シンクライアントは死んだ : ITmedia オルタナティブ・ブログ
同じくITmedia オルタナティブ・ブログでも、これに言及したエントリがいくつかある。「代替案のある生活 > シンクライアントの使い方」では上記のエントリを「片貝さんのうまいアンチテーゼ的なブログ」のおかげで、と切り出し、シンクライアントの気に入っている点を挙げている。「平凡でもフルーツでもなく、、、 > 友人が個人情報漏洩から職を失った経験のある立場としてはシンクライアント賛成派です」ではその安心感に言及し、「『ビジネス2.0』の視点 > シンクライアント使っています」ではシンクライアントとパソコンを比較して長所短所を明確にした上で、「企業の文化や取り巻く環境などによって、シンクライアントの是非は分かれるところかと思われます」と締めている。
●
なるほど、シンクライアントの良さは分かる。でも、だったら「既存のパソコンを排除」できる世界を思い描いたらいいじゃないか、と直感的に思った。特別な環境を除けば、エンドユーザコンピューティングの全てがシンクライアント方式である世界。
エンドユーザコンピューティングを、「エンプロイ・コンピューティング」企業内を中心とした業務のためのコンピュータ利用と、「ホーム・コンピューティング」家庭を中心とした生活や楽しみに関わるコンピューティングに分けられると仮定してみる。彼らの議論は、「エンプロイ・コンピューティング」環境をシンクライアントで利用することの良さに終始している。でも「ホーム・コンピューティング」環境もシンクライアント化しちゃえば、とは言わない。
ホーム・コンピューティング環境もシンクライアント化しちゃえばいい。できるはずだ。例えば、Amazon EC2は仮想サーバ環境としてよく使われているが、本当の姿は純粋な仮想マシンだ。EC2上の仮想マシンをデスクトップ環境として使ったっていいはずだ。ローカルマシンと同じくらい快適に使えるとしたら、普段使いのデスクトップだってEC2上の仮想マシンでいい。そうなったら、普通の人が使う端末ってパソコンである必要はなくなって、シンクライアントを使うようになるんだ。
普段からシンクライアントを、何も考えず当たり前に使っていれば、仕事だってシンクライアントですることが普通だとみんなが思うだろう。全てのエンドユーザコンピューティングをシンクライアント化する。それができた時、先進的な普通の人がシンクライアントを使い始め、その後でキャズムの先にいる普通の普通の人たちも、シンクライアントでコンピューティングするようになる。それが、「既存パソコンが排除」された世界。多分企業だけをシンクライアント化した先には来ない未来だ。
●
現時点では、そんなにクラウドの向こう側のマシンを信頼できない（たとえばEC2はトラブル時に環境が失われる）し、多くの人にとってはそんなに信用もできないんだろう。もちろん、一般家庭でネットワーク越しにデスクトップ環境をすいすい使えるほどには、まだそこまでブロードバンドも太くない。
でもありうる未来のはずだ。ネットワークインフラから仮想マシン環境、信用や信頼を担保する仕組み作り、そしてホームコンピューティングが仮想マシンを選ぶ破壊的価格体系の実現。今のシンクライアントの想定利用方法や価格体系などを、一度殺すぐらいのことになる。それが行われれば、シンクライアントの世界は来ると思う。それは、クラウド化する世界がいずれ迎える、ごく正常な姿だと思うから。
Googleが携帯をGoogleにとっての良い端末にするために無償のOSまで公開したように、この大ナタを振るうのはそれを必要とするシンクライアント事業者や、あるいはクラウドのホスティング業者なんだろうな。それが行われなければ、「シンクライアントは死んだね」と言われたとおりになる。それが行われたならば、今のシンクライアントは死に、シンクライアント化したコンピューティング世界へと再生する。
どちらにせよシンクライアントは一度死ぬんじゃないか。滅亡に至って死ぬのか、再生に向けて死を遂げるのか。そこを選択するタイミングなのだ。全くの門外漢、一連のエントリを読んだだけでの感想だけど、そう思った。
■ 前提 Symfonyをセットアップしておきます。手順などは「symfony入門（1）：symfonyで始めるPHPフレームワーク：CodeZine」を参考に。ただし、PEARでインストールできるsymfonyのstableが1.2.1になってましたので、stableをインストールしました。 ■ インストール作業 手順はおおむね、リリースアナウンスからリンクされている「OpenPNE3alpha3 セットアップ手順」準拠。 c:\(略)\htdocs> svn co https://trac.openpne.jp/svn/OpenPNE3/trunk OpenPNE3 OpenPNE3\config\ProjectConfiguration.class.php.sampleを同ディレクトリにProjectConfiguration.class.phpとしてコピーし、手順通り3行目を以下のように修正。 require_once 'C:/Program Files/PHP/PEAR/symfony/autoload/sfCoreAutoload.class.php'; 次に、セットアップ手順にあるとおりデータベースを作成。ただしデータベース名は日付など省きました。 c:\(略)\htdocs> mysql -uroot -p そして、インストール。OpenPNE3\symfonyはUnix系のシェルスクリプトとして実行することを前提にしているので、「Symfony を Apache on Windows で使う」に倣ってOpenPNE3\symfony.batを作成。内容は全く同じでOKです。そして、OpenPNE3ディレクトリでコマンドプロンプトを開き、symfony（と入力すればsymfony.batのことになる）を実行。trunkを使用しているので、後にデータベース設定などは付けないこと。 c:\(略)\htdocs\OpenPNE3> symfony openpne:install 実行中にデータベース名その他の入力を求められます。ここで、上記で作成したデータベース名、アクセス用のDBユーザ名、パスワードなどを入力すると先に進みます。 Choose DBMS (mysql, pgsql or sqlite) mysql Type database username root Type database password (optional) jugemjugem Type database hostname localhost Type database name OpenPNE3 Type database socket path (optional) The DBMS mysql Is it OK to start this task? (y/n) ｙ これでしばらくするとインストールが完了します。完了後、ブラウザでOpenPNE3/web/pc_frontend_dev.phpにアクセスしてみます。 http://localhost/OpenPNE3/web/pc_frontend_dev.php ログイン画面が出ればインストール成功。メールアドレス“sns@example.com”、パスワード“password”でログインできるはずです。 ■ まとめ OpenPNE3は近日リリースされる予定で、開発もかなり進んできているようです。また、今回いろいろと対応してもらいながら、Linuxを用意しなくても、Windows環境でインストールできるところまできたことは確認できました。 Windows上で環境を整えられるようになったことは、試用の垣根を一つ下げたかと思います。私自身は、これから、各機能などを触りながら、できる限りのフィードバックをして行こうと思います。皆様もぜひOpenPNE3を試して、何かあれば開発コミュニティへフィードバックをしてください。 ■ 参考：OpenPNE3 beta3からtrunkのリビジョン10319までの試行エントリ 1月21日のエントリには、「Maximum execution time of 30 seconds exceeded」というエラーが出る時の対処や、http://openpne3.local/pc_frontend_dev.phpのようなURLでアクセスできるようにするためのApacheのバーチャル・ホスト設定などがあります。
まずApacheのドキュメントホームでOpenPNE3をチェックアウトします。
password: （パスワード入力）
mysql> CREATE DATABASE openpne3 DEFAULT CHARACTER SET=utf8;
mysql> exit
The Database Username root
The Database Password ******
The Database Hostname localhost
The Database Name OpenPNE3_trunk_20090119
The Database Socket
このエントリ時点ではインストールに成功しませんでした。
この後の「Windows+Apache2.2+PHP5.2.6でOpenPNE3beta3」が成功時のエントリです。
----
WindowsでOpenPNE3インストール(2009.01.20)の問題がリビジョン10288で修正された（投げまくって対応してもらいまくってますね）とのことなので、最新のtrunkをチェックアウト。リビジョン10302でインストールを再試行。
c:\(略)\htdocs\OpenPNE3> symfony openpne:install
今回は最後までインストールが行きました！
■ 問題点1 （解決済み）
そしてインストールしたローカルのURLにブラウザでアクセス。
http://localhost/OpenPNE3/web/pc_frontend_dev.php
エラーになります。
Fatal error: Maximum execution time of 30 seconds exceeded in C:\Program Files\PHP\PEAR\symfony\config\sfAutoloadConfigHandler.class.php on line 129
繰り返しますが、10回目まで毎回エラー。
Fatal error: Maximum execution time of 30 seconds exceeded in C:\Program Files\PHP\PEAR\symfony\util\sfFinder.class.php on line 421
Fatal error: Maximum execution time of 30 seconds exceeded in C:\Program Files\PHP\PEAR\symfony\config\sfAutoloadConfigHandler.class.php on line 129
Fatal error: Maximum execution time of 30 seconds exceeded in C:\Program Files\PHP\PEAR\symfony\util\sfFinder.class.php on line 421
Fatal error: Maximum execution time of 30 seconds exceeded in C:\Program Files\PHP\PEAR\symfony\util\sfFinder.class.php on line 421
Fatal error: Maximum execution time of 30 seconds exceeded in C:\Program Files\PHP\PEAR\symfony\util\sfFinder.class.php on line 415
Fatal error: Maximum execution time of 30 seconds exceeded in C:\Program Files\PHP\PEAR\symfony\config\sfAutoloadConfigHandler.class.php on line 129
Fatal error: Maximum execution time of 30 seconds exceeded in C:\Program Files\PHP\PEAR\symfony\config\sfAutoloadConfigHandler.class.php on line 130
Fatal error: Maximum execution time of 30 seconds exceeded in C:\Program Files\PHP\PEAR\symfony\util\sfFinder.class.php on line 399
Fatal error: Maximum execution time of 30 seconds exceeded in C:\Program Files\PHP\PEAR\symfony\config\sfAutoloadConfigHandler.class.php on line 130
毎回エラー内容は最長実行時間30秒に達したというもので、エラー個所が微妙に違うということは、本当に処理しているものの時間が足りないのだと判断します。C:\Program File\PHP\php.iniで制限を60秒に変更。
max_execution_time = 60 ; Maximum execution time of each script, in seconds
Apacheを再起動して、再度アクセス。このエラーはでなくなりました。
■ 問題点2 （未解決）
今度は別のエラー。
500 | Internal Server Error | sfConfigurationException
Configuration file "C:\Program Files\Apache Software Foundation\Apache2.2\htdocs\OpenPNE3\lib/config/config/auth.yml" does not have a registered handler.stack trace
symfony v.1.2.1 - php 5.2.6
そういえばcodezineのサンプルは仮想ホストを設定して、パスはルートでアクセスしないと画像やCSS周りでトラブルがありました。可能性は薄そうですが、そういうのが絡んでいる可能性もなくはない、と思って、仮想ホストの設定をC:\Program Files\Apache Software Foundation\Apache2.2\conf\extra\httpd-vhosts.confに追記。
<VirtualHost *:80>
ServerName openpne3.localhost
DocumentRoot "C:/Program Files/Apache Software Foundation/Apache2.2/htdocs/OpenPNE3/web/"
DirectoryIndex index.php
<Directory "C:/Program Files/Apache Software Foundation/Apache2.2/htdocs/OpenPNE3/web/">
AllowOverride All
Allow from All
</Directory>Alias /sf "C:/Program Files/PHP/data/symfony/web/sf/"
<Directory "C:/Program Files/PHP/data/symfony/web/sf/">
AllowOverride All
Allow from All
</Directory>
</VirtualHost>
仮想ホストの名前を使ってアクセスしてみます。
http://openpne3.localhost/pc_frontend_dev.php
これでも同じエラーになります。
いよいよエラーがアプリケーション由来っぽくなってきました。しかしテーブル定義とかSQLの問題であればともかく、SymfonyやOpenPNE3の中のことになってくると、これから始めようという身には掘るのが辛そう。
とりあえず、今晩はここでギブアップ。
developerWorks Japa... read more
on 「企業ウィキにシグネチャを」寄稿。