All Articles by Akky Akimoto

2563 Articles

Ruby on Rails の PHP 移植プロジェクト

メモ: PHP フレームワークと Ruby on Rails からの影響

PHP 用の Rails クローンや、Rails を移植したと主張しているプロジェクト達

CakePHP
https://trac.cakephp.org/

Biscuit
http://bennolan.com/biscuit/

PHP on Trax (旧名 PHP On Rails)
http://phpontrax.com/

この記事は移転前の古いURLで公開された時のものです

  • ブックマークが新旧で分散している場合があります。
  • 移転前は現在とは文体が違い「である」調です。(参考)
  • 記事の内容が古くて役に立たなくなっている、という場合にはコメントやツイッターでご指摘いただければ幸いです。最新の状況を調べて新しい記事を書くかもしれません

ソースコード検索とコピペプログラミング

プログラマー向けにまた新しいサービスが出たようなのでご紹介。

code fetch { は、ソースコードに特化したソースコード検索エンジン。”{” 記号もサイト名の一部のようだ。

関数名などを検索すると、関数名を含むサンプルを、書籍のサンプルコードから抜き出して表示しているようだ。

言語ごとに検索することができる。以下はいくつか試してみた結果。

サイト自身は、紹介した書籍を買ってもらうことでビジネスとするつもりらしい。

ある関数を使うとき、関数の挙動はわかっていても、それを実際にどのように呼び出すのかが、マニュアルからだと簡単に把握できないことがある。

PHP のマニュアル などでは、マニュアルの末尾にユーザのディスカッションをつけて、そこでサンプルコード的なものが流れているが、サンプルから使い方のあたりをつける、という点ではこれも役立つ気がする。

ソースコード検索エンジンとしては、日本にも高林さんの gonzui があるが、同じような技術を基盤に、公開されているサンプルコードと amazon アフィリエイトを組み合わせてビジネス化しよう、という試みと言える。(検索してほしくない本の著者は連絡してくれ、とあるので、このあたりに問題点をはらんでいる可能性はある)

ビジネス的にこれがいけるのか、著者によってはこれを許したくないのでは、という話は別として、こういったソースコード検索によって「他者のソースを見る」という機会は重要なのではないかと僕は思っている。

究極的には、僕らプログラマーが書いているコードのほとんどは、過去にどこかで見た他人のコードを真似て、再構築しているといってもいい。本質を理解せずにコピーした粗悪なコードの氾濫も大きな問題ではあるものの、読むことや真似ることそのものが悪だとは僕には思えない。

ペアプログラミングなども「よいソースを書いている状態を目の前で見る」ことの教育効果が評価されている理由の一つではないだろうか。

検索によって良いお手本が簡単に見つかるようになっていくことは、決して悪いことではないな、と思うがどうだろう。

この記事は移転前の古いURLで公開された時のものです

  • ブックマークが新旧で分散している場合があります。
  • 移転前は現在とは文体が違い「である」調です。(参考)
  • 記事の内容が古くて役に立たなくなっている、という場合にはコメントやツイッターでご指摘いただければ幸いです。最新の状況を調べて新しい記事を書くかもしれません

日曜は PHP 勉強会

昨日の Java 読書会に続き、日曜は PHP 勉強会に参加してみた。

mixi の PHP コミュニティから発生したらしいこの勉強会、会自体は3回目のようだが、当然これまでは参加していない。何か発表するものを、という話だったので、自分が書いたわけじゃないが CyDE2 の開発環境を持って行き、インストーラとユニットテストをどうやってるかあたりをちょろっと紹介させていただいた。他の発表を聞いてみて比べると、あまり技術的じゃない。宣伝臭いし。

他には、PHP フレームワーク Maple の作者の方が、AOP による DB アクセスの Maple へのウィービングについて実装発表されていて、面白かった。

あとは、PHP に関する洋書のレビュー発表など。アメリカに居たとき本屋でパラパラと見ていた本がいくつか出てきて興味深かった。

全体的に、昨日の Java 読書会が「最近面白い本出てないねぇ」といった感じだったのに比べて、PHP 勉強会のほうが活気があるように見えた。

でも、土曜日にあった Lightweight Language Day and Night (LLDN) に参加されてた方も多く、そちらでは Ruby や Perl のヒトタチが元気だったということで、PHP もがんばらないとね、という雰囲気もあった。

それと、いつも PHP 関連の雑誌記事などでお世話になっている著者のみなさんと直接お会いできたのは非常によかったと思う。来月もあるようなのでぜひまた参加したい。

この記事は移転前の古いURLで公開された時のものです

  • ブックマークが新旧で分散している場合があります。
  • 移転前は現在とは文体が違い「である」調です。(参考)
  • 記事の内容が古くて役に立たなくなっている、という場合にはコメントやツイッターでご指摘いただければ幸いです。最新の状況を調べて新しい記事を書くかもしれません

土曜日は Java 読書会

Java 読書会 に参加してきた。一冊の本を、毎月一回集まって「読む」というもの。インターネット協会の部会ということになっているが、参加者は興味のある有志の集まりだ。

僕も、転職でアメリカのサイボウズに行く前はよく参加していた。今回はひさしぶりの参加となる。

今回は翻訳者の瀬谷さんにも来ていただき、読んでいて難しい点など直接解説していただくこともあり、非常によかった。

今月分で読了となった、「アジャイルソフトウェア開発の奥義」だが、今回読んだ中で「付録C: 皮肉な運命」が読み物として面白かった。

同じプロジェクトを実施することになった二つの会社の話を、横に二つ並べて小説風に描く、というもので、一つはガチガチのウォーターフォールで大混乱になり、もう一方はアジャイル的な手法でなんとか成功する、というオチ。

悪い方の例では硬直したプロジェクト管理や理不尽な上司の要求、と言ったものが書かれている。思わず「あるある」と言ってしまうところも多い。ちょっとだけ触りを抜粋すると

上司「即刻開始する必要がある。分析にはどれくらいの時間がかかるかね?」
あなた「仕様要求がわからなければ分析にかかる時間を申し上げられません」
上司「仕様要求が出てくるまでには4~5週間かかるだろう。だから、仕様要求が今君達の目の前にあるものと仮定したまえ。君達は分析にどれぐらいの時間が必要なのかね」

さて上記の流れは変だ、とあなたは思うだろうか? あるいは、いったい何がおかしいというのだ、と思うだろうか。

アジャイル開発についての本なので、アジャイル開発に対してちょっと甘いかな、という気もするが、二つを並べて読むことで、果たして自分達の開発プロセスはどうだろうか、という良い自省ができる話かなあ、と思った。

もちろん、本文の方も充実した内容で、XP、デザインパターンについて実例をなぞりながら勉強することができる。いい本だと思った。

Java 読書会 は9月から新しい課題書(まだ決まっていない)で最初からスタートするので、会社の外で業務とは別に勉強してみたい、という方は参加してみてはどうだろうか。

こういった社外の勉強会は、Java 読書会の場合は「Java」というキーワードはあるものの、ウェブサービス系や組み込み系などさまざまな業務をしている人(もちろん仕事は全然 Java じゃないが自分で勉強してる人も)が集うので、見聞を広めるのにも役立つと思っている。

この記事は移転前の古いURLで公開された時のものです

  • ブックマークが新旧で分散している場合があります。
  • 移転前は現在とは文体が違い「である」調です。(参考)
  • 記事の内容が古くて役に立たなくなっている、という場合にはコメントやツイッターでご指摘いただければ幸いです。最新の状況を調べて新しい記事を書くかもしれません

商用アプリ開発に関する PHP の利点と欠点

現在サイボウズ本社でいちばん使われているコンピュータ言語は、と訊かれれば、それは PHP という言語になるだろう。

PHP はそもそもウェブサイトを作るために開発された、目的のはっきりとした言語で、ウェブアプリケーションの世界では非常にユーザー数の多い言語である。PHP のエンジン部分を開発している Zend 社の調査では、インターネット上のウェブサイトの 20% 超は PHP で書かれているともいう。

また、PHP の言語としての文法は C 言語に似せて作られていて、C 言語風のスクリプト言語といえる。専門学校や大学などの授業で C 言語や C++/Java など C 言語に似た言語が使われることも多いため、比較的とっつきやすいとも言えるだろう。

そういった普及度からすると、PHP を多用することには、プログラマーが足りなくなったときに社外から人材を集めやすい、あるいは協力会社を探しやすい、という利点がある。

2年以上前から準備され、今回発売となったガルーン2 では、この PHP が大きな部分を占めている。それ以前は独自のスクリプト言語(Cybozu Labs 社長でもある畑の名前を冠した、Hata-Script である)を使っていた。これもまぁ、Office6 までのサイボウズ製品を見ていただければわかるように、軽量できびきび動く、いい言語ではあったのだが、やはり PHP のユーザベースの大きさというのは意味がある。

この変更では、内製も含めて様々なオプションが検討されたわけだが、サイボウズ製品の特性や技術者の確保のしやすさ、などいろいろな観点を総合し、PHP が選定された。

ただし、その選定の際には、満場一致ですぐに PHP を使うことに決まったわけでもない。(主に反対していたのは僕だが)

どんな言語も完璧ではありえない。PHP にも危惧されている問題点はあった。言語としての出来、や、インタプリタの安定度、リソースの消費量、処理の速度、利用できるライブラリの量や質、利用や配布に関する制約、などなど、について、問題があるかどうか、あるとしたらどう解決するか、解決法が現実的な対処であるか、といった事柄について多数の討論をおこなった。

そういった技術やライセンスの問題については一つずつ問題点をつぶしてきており、今のところ大きな問題点は残っていないと言ってもよさそうだ。僕自身は早い段階で CyDE2 のプロジェクトから離れており(==米国の子会社に帰った)、実際にそれらの改善を辛抱強くおこなってきたのは本社の開発部の面々である。

それでも残る問題は、一部の硬派プログラマーから、PHP は「初心者向けの言語」と思われていることにある。こればかりは、サイボウズの開発部ががんばるだけで解決する問題ではない。

まぁ、現在主流のバージョン 4、PHP4 では、言語としていいかげんなところや使いづらいところもたくさんあり、技術力のあるプログラマー達の多くが「一番好きな言語」とか「一番使いやすい言語」に選ぶ言語だ、とまでは言えないだろう。

「弘法筆を選ばず」というから、真にできるプログラマーならどんな言語であってもちゃんとした成果を残せるのかもしれない。しかし、実際問題として、そのとっつきやすさ、はじめやすさがかえって災いし、「PHP ができます」という人の中に「PHP *しか*できない人」も多い。

理想としては、どんな言語でもすばやくマスターでき、PHP インタプリタの挙動に疑問点があれば、PHP のソースまで遡って調査することも全然苦にならない、といった人がたくさん来てくれるといいんだろうな。ま、これは主に本社側の話だが。

サイボウズ・ラボでのこれからの開発は、必ずしもサイボウズ本社と同じ言語を使う必要はないため、たとえば PythonRuby のような言語を使ってもよいし、LispJSF/Java でもいい。それは入ってきた人が自分で先導して決めていってしまえばいいのだ。いまのところ、そのへんはまるっきり流動的だ。

むしろ、自分の好きな言語や環境について熱く語れて、まわりを引っ張って巻き込んでいけるような、そんな人であれば面白いし、僕もぜひその人からいろいろ学んでみたいものだ、と思う。

この記事は移転前の古いURLで公開された時のものです

  • ブックマークが新旧で分散している場合があります。
  • 移転前は現在とは文体が違い「である」調です。(参考)
  • 記事の内容が古くて役に立たなくなっている、という場合にはコメントやツイッターでご指摘いただければ幸いです。最新の状況を調べて新しい記事を書くかもしれません

成功する Web2.0 企業になるための 10 のステップ

成功する Web2.0 企業になるための 10 のステップ より。

  1. 利用者の問題をよく理解したうえで、最小単位から解決せよ
  2. 反応のよい、意見を言ってくれる利用者を獲得せよ
  3. 今すぐ公開せよ。明日公開せよ。毎日公開せよ
  4. データを配布しまくれ
  5. 利用者のデータを囲い込まないこと
  6. おどろくほど単純にせよ
  7. 無料でありつづけよ
  8. マーケティング費用は無駄
  9. 投資しすぎないこと
  10. どのサービスにも見るべき点がある

詳細は元エントリをどうぞ。いくつもの実サービスを例にあげて、成功したネットサービスに共通の要素を解説してくれている。

この記事は移転前の古いURLで公開された時のものです

  • ブックマークが新旧で分散している場合があります。
  • 移転前は現在とは文体が違い「である」調です。(参考)
  • 記事の内容が古くて役に立たなくなっている、という場合にはコメントやツイッターでご指摘いただければ幸いです。最新の状況を調べて新しい記事を書くかもしれません