スタッフブログ
その後オープンソースと関わるようになってから「CVS」「Subversion」を使うようになりました。
そして今使ってるバージョン管理システムが「Git」です。といってもあれこれ検討してSubversionからGitへうつったわけでなく、周囲の開発者さんたちが「Git便利!」って言ってほぼ全員Gitへ移行してたり、XOOPS CubeのリポジトリがSubversionからGitHubへ移行したりとなって、ようやく自分でも使い始めた格好です。
そうやって使い始めたGitですが、Subversionと同じ程度には使えるようになってきたのですが、他の開発者さんの使い方を観察するともっと色々便利なコマンドや使い方があるようなので、一通りざっくり把握してみようと思って、「Gitポケットリファレンス」をパラパラと読んでみました。
開発中の様々な要望に応える方法がほとんどありそう
というわけで「Gitポケットリファレンス」を毎朝数ページずつ読んでみたんですがすごいですねGit!
Subversion使ってたときに「あー、○○したいんだけど、うまい方法ないんだよなぁ」って思うことがほぼ解決してます。
というか、開発中に遭遇するバージョン管理にまつわるあれこれに対応する方法が網羅されてそうな印象です。
たとえば 、ファイルの各行の変更履歴を出力する "git blame"
プログラムの不具合が発生したときにプログラムコードを追っかけてると「あれ?なんでこんな処理してるんだろ?」って疑問に感じるコードにあたることがあります。
そんなときに過去バージョンをチェックして**いつごろその処理が書かれたのか**を調べて、関連するRedmineのチケットや議事録をもとに「そもそもどう意図で行われた変更か」というのを調査して、意図にあったコードになってるか確認します。
この「いつごろその処理が書かれたのか」を調べるのがgit blameを使うと簡単にできちゃうんですよね。
git blameで「このファイルの何行目から何行目はいつ更新された?」を調べられるので先ほど書いたシチュエーションではめっちゃ役立ちそうです。
この git blameをはじめとしてほんとかゆいところに手が届くバージョン管理システムになってますね。
というわけで、最近gitを使ってみた感触やこの本から得られた知識から考えてもこれからのバージョン管理システムは git がよさそうだなと思いました。
最近注目しているCMS「NetCommons」のセミナーでNetCommonsの次期バージョン「NetCommons3」に触れて遊んでみようというテーマの勉強会があったので参加してきました。
ただ私は勉強会中にひとりで勝手にNetCommons3をCakePHP3.0で動かせるようにならんかチャレンジしてました(^^;
というのもNetCommons3はCakePHP2.0ベースで開発されてるんですが、CakePHPは既に3.0の開発がすすんでおり、NetCommons3のリリース時期やCakePHP3.0のリリース時期なんかを考えると、できるだけ早めにCakePHP3.0へ乗り換えをした方がよさそうだと感じたからです。
事前予想としては「あんがいすんなりいくんじゃね?」とか思ってたんですが、CakePHP3.0のコードを探すとか、App側のコードがみつからなくてカンでNetCommons3のAppコードいじってなんとかしようとしたりしてどうにもならなかったりで、最終的に動かすことができませんでした…orz
今後のために各コードの所在へのリンクはっときます。
また時間をみつけて、NetCommons3+CakePHP3.0での動作にチャレンジしたいと思います。
「NetCommons」は国立情報学研究所で開発されてる国産CMSです。 グループウェア的にも使えるシステムに仕上がっていて私も注目してます。
21日の「NetCommonsユーザカンファレンス」では、東北の震災に対して どのようにNetCommonsが学校で活用されたのかの事例や 現在開発が進められている次期NetCommons「NetCommons3」についても 話しがありました。
「NetCommons3」はCakephpという人気のPHPフレームワークをベースに開発を しているそうで、現行バージョンよりもモジュールが開発しやすくなるだろうなぁと 思っています。 「NetCommons3」の正式リリース予定は2015年3月とまだまだ先ですが、 楽しみです。
少しお手伝いでブースのお留守番しながらたくさんの方にお話を聞くことができて良かったです。
Go-Coworkingもデモ展示。施設MAPに興味もたれた方、結構いましたねぇ。
午後は2会場にわかれてセッションがあったのですがたくさんの方がセッションに耳をかたむけてました。
ブースで一緒に留守番してくれた「コケロミン」かわいいですよ〜
トップページだけ"Protector detects site manipulation."と表示されることがあります。
これはProtectorモジュールによる簡易サイト改ざんチェックの結果、
何かしら変更があったことを知らせるメッセージです。
意図せぬ変更が勝手に行われたときに気がつくようにチェックが行われるのですが、
簡易チェックのため、意図的な変更を行ったときにも発動(誤報)することがあります。
この簡易サイト改ざんチェックですが、チェックしてるのは下記3点です。
・XOOPSをインストールしたディレクトリの更新日時
・XOOPSトップページのindex.phpの更新日時
・同じくindex.phpのinode番号
この3つの値がDBに保存されてる以前の値と異なっていたら「改ざんされたかも」
ということでトップページに"Protector detects site manipulation."を
表示するんですね。
ちょっとやっかいなのが「XOOPSをインストールしたディレクトリの更新日時」のチェック
「ディレクトリの更新日時」はファイルがアップされたり、編集されたり、削除されたときにも
更新されます。
そうすると、構築中やリニューアル作業で、.htaccessを変更したり、favicon.icoを書き換えたり、
XOOPS最新版を上書きアップロードしたときにも「ディレクトリの更新日時」は書き換わってしまいます。
●表示されてしまったときの対応策
このサイト改ざんチェックが実行されるのは、XOOPSのトップページだけで、
XOOPS_URL/user.phpは今まで通り表示できるので、こちらで管理者としてログインします。
ログイン後はXOOPS_URL/admin.phpで管理画面に入り
「Protector」→「一般設定」→「サイト改ざんチェック値」を空にして「送信」します。
これで最新データがDBに保存されます。
※ファイルの書換等を行った覚えが全くなければ、ほんとに改ざんされた可能性もありますので、ちゃんとチェックはおこなってくださいね。
●事前対策
事前にファイルUPなどの作業を行うことがわかっていれば、
「Protector」→「一般設定」→「サイト改ざんチェックを有効にする」を
「いいえ」にしておいて作業するのもひとつの手ですね。
ブログの様に時系列に記事を追加していくニュースサイトにも向いてます。
無数に存在するプラグインを組み合わせたり、プログラムを少し書き足したりすることで
実に多様なサイトを作ることができます。
ブログや中小企業の企業サイトなどはWordPressで作るのが良いと私も思います。
実際私もブログにはWordPressを使っています。
ではXOOPSはどういうときに使うのか?
判断ポイントは2つあります。
1.会員制サイトか?
2.プログラム開発が必要か?
つくろうとするWebサイトが会員制サイトである。会員向けサービスを提供するための
Webサイトであるというような場合は、会員制ポータルサイトシステムとして開発された
XOOPSが適しています。
またこれから構築するWebサイトで独自の機能(サービス提供型サイトでは
この機能がサイトのメインとなることが多い)が必要とされる場合も私はXOOPSを
使います。
CMS上で動くプログラムを開発する場合、覚えるべきやり方や従うべき制約などが
色々あるのすが、XOOPSでは覚えるコトや従うべき制約がかなり少ないため、
より自由に開発できるので助かってます。
1.会員制サイトか?
2.プログラム開発が必要か?
この2点に該当するのであればXOOPSから検討し、そうでなければWordPress等
他のシステムから検討してみるといいんじゃないかなと思っています。
愛知県三河地方出身の龍司です。
東京に出てくる前は新潟県上越市に住んでたので、新潟出身だと勘違いされることがよくあります。
ただ親父のふるさとが新潟県上越市で私も数年住んだことがあり、さらに離婚して別れて暮らすことになった息子が上越で暮らしてるので上越市は第2の故郷とも思ってます。
そんな上越市へ息子と遊ぶために行ってきました。
今回は息子とサイクリング予定なのでロードバイクももっての移動です。
複数の言語むけのサイトを構築することができます。
このとき問題になるのが、新着ブロック等でのタイトル文字列の切り詰めです。
cubeUtilで多言語対応するときに、タイトルには
「[ja]日本語のタイトル[/ja][en]English Title[/en]」
のようにタイトル欄に日本語と英語の表記を多言語用のタグをつけて登録します。
これが新着ブロック等で短くきりつめられると
「[ja]日本語のタイトル[/ja][en]English …」
のように中途半端なところで切り詰められてから、多言語対応の仕組みがうごいて、
タグが画面にでてきたり、予想外の範囲まで別言語の扱いになって画面から消えてしまうことがあります。
多言語対応のサイトを構築していて、一部のコンテンツが画面に表示されなかったり、
多言語用のタグが画面に表示されるようなことが発生したら、
どこかでタイトル切り詰めが起きてないか調べてみてください。
タイトルの切り詰めをやめれば問題が解決するはずです。
なかったようなのでちょっとpreloadファイルをつくってみました。
下記コードをhtml/preload/IsToppage.class.phpとして保存します。
<?php
class IsToppage extends XCube_ActionFilter
{
protected $isTop = false;
public function preBlockFilter()
{
$this->mController->mRoot->mDelegateManager->add("Legacypage.Top.Access", array(&$this, 'topAccess'));
}
public function topAccess()
{
$this->isTop = true;
$GLOBALS['xoopsTpl']->assign('xoops_is_top', $this->isTop);
}
}
<{if $xoops_is_top }>
トップページだよ!
<{else}>
トップページじゃないねっ
<{/if}>
予算を考えるときは、次の3つにわけて考えておくことをおすすめします。
1.開発時の初期費用
2.初年度の予算
3.次年度以降のランニング費用
この中でポイントは2番の初年度予算です。
構築時にまとまった工数が必要なので、初期費用がかかるのは当然ですね。
ここは皆さんしっかり確保されます。
3番のランニング費用もちゃんと検討される方が多いです。
忘れられることが多いのが2番の初年度予算。
新しいシステムを導入して運用しはじめると、いろいろと手直ししたくなる部分というのが発生します。
こればっかりはいくら事前に十分検討したつもりでも、発生するものです。
このときの改修費用を確保しておかないと、手直ししたくても手直しできないという、なんとも苦しい状況になってしまいます。
システムは使い始めたら手直ししたくなるモノ
そう考えて、初年度に改修用予算を確保しておくのがおすすめです。
最少の金額と最大の金額を比較したら桁がいくつもかわるぐらい金額に開きがあります。
ちょっとしたショッピングカートCGIを設置するのをSOHOさんに頼んで5千円なんてこともあれば、
独自オンラインショップシステムの開発に1,000万ってこともあります。
そのため私がお客さんとシステムの相談をさせてもらうときは、最初にご予算について質問させてもらうことがほとんどです。
お客さんから教えていただいたご予算の範囲で実現できること。
これをベースにしてお話していかないと、ご予算100万円というお客さんに1,000万かかるシステムの話しをしてしまって、話しがまったくまとまらずにお互いに時間を無駄にしてしまいます。
そのシステムはいくらぐらいの予算で実現したいことなのか?
是非これを明確にしてからシステム開発の相談をしてみることをおすすめします。