Tag : Loggix

1 - 7 of 70

Git関連メモ：リポジトリのバックアップ

icn_GitX_128.png

GitのローカルリポジトリのバックアップはGitHubにpushするのがバックアップのようなものだが、毎日の作業を自分のLAN内にもバックアップしておきたい。

私の場合Ubuntu Linux 9.04をNASとしても使っているので、OS Xで開発を行っているLoggixのリポジトリをUbuntuにバックアップする場合の手順を例としてメモ。

準備

OS XでUbuntuのhtdocsディレクトリをヴォリュームとしてマウントしておき、

$ mkdir -p /Volumes/htdocs/repo/loggix.git
$ cd /Volumes/htdocs/repo/loggix.git
$ git --bare init

でバックアップリポジトリを作成。

git-backup-repo-1.png

バックアップ

毎回作業が終わったら最後に

$ git push /Volumes/htdocs/repo/loggix.git master

としておけば安心。

ディレクトリ名の最後を「.git」にしておくと、OS XでGitXを使っている環境だと上の画像のようにアイコンがGitXアイコンになり、クリックするとGitXが立ち上がってそのリポジトリを読み込んでくれるので便利。(↓)

git-backup-repo-2.png

Loggix関連メモ：P_BLOGからLoggixへの移行

私が知る範囲ではP_BLOGからLoggixへ移行する人はあまり多くないように感じるが、とりあえず私用としての覚え書きと、もしかしているかもしれない希少な方のために、メモしておく。

Loggixは基本的にはSQLiteであるが、前のバージョンでPDOドライバへの移行によりMySQLへの対応も果たしたので、P_BLOGで使っていたMySQLデータベースの資産を引き継ぎ、テーブル名を変更することでそのまま使う事が出来る。（理論上は）ただし、いくつか問題がある。

P_BLOGからLoggixへ開発のフォーカスを移行した際に、カテゴリーを廃止し、タグ周りを大幅改善した。また、パスワードをMD5からSHA-1へ移行したため、パスワード保存用のテーブルのテキストサイズが「32から40」になった、などの変更点がある。移行に必要な作業をまとめると、

【phpMyAdminでの作業】

  • テーブル名をP_BLOG用からLoggix用へ変更
  • パスワードを保存するフィールドを「32」から「40」に変更
  • P_BLOGにないフィールドをいくつか追加
  • 逆に、Loggixで使わないフィールドは削除(残してもよい）

し、

【手作業】

  • 従来のカテゴリー機能が無くなりタグ機能の仕様が大幅変更になったためP_BLOGで登録したカテゴリー／タグは使えなくなり、各エントリーごとに再登録する

という感じになる。

手順としては、phpMyAdminを使い、

  • 移行したいP_BLOGのテーブルのコピーを作る。
  • コピーしたテーブルのフィールド名をLoggix用に変更する。
  • Loggix用に新しく追加されたフィールドを追加する。
  • 新しく追加されたテーブルは、Loggix添付のMySQL用のインストールSQLファイルをphpMyAdminで読み込んでインストールする。
  • 新規に空のLoggix用のデータベース(仮に「loggix」とする）を作成し、そこにコピーしたテーブルを移動する。

という感じだ。

以下、P_BLOGとLoggixの、対応するテーブル比較表を作ってみた。赤で示した部分が、廃止したもの、もしくは変更した数値である。あと、ダウンロードファイル用のテーブルなど、フィールド名がいくつか変更になっているテーブルもある。もし必要な方がこのエントリーを見つけたら参考に。

ユーザー用テーブル

P_BLOG(p_blog_user) Loggix (loggix_user)
user_id smallint(3) user_id smallint(3)
user_name varchar(50) user_name varchar(50)
user_pass varchar(32) user_pass varchar(40) 数値変更
× user_nickname varchar(50) 新規追加
user_mail varchar(50) user_mail varchar(50) NOT
user_date datetime user_date datetime
× user_status tinyint(4) 新規追加

セッション用テーブル

P_BLOG(p_session) Loggix (loggix_session)
id varchar(32) id varchar(32)
sess_var text sess_var text
sess_date int(11) sess_date int(11)

コンフィグ用テーブル

P_BLOG(p_config) Loggix (loggix_config)
config_key varchar(64) config_key varchar(64)
config_value mediumtext config_value mediumtext

エントリー用テーブル

P_BLOG(p_blog_log) Loggix (loggix_log)
id int(11) id int(11)
title varchar(100) name varchar(100)
href varchar(255) href varchar(255)
category varchar(50) × (廃止)
comment longtext comment longtext
× excerpt longtext 新規追加
× text_mode tinyint(4) 新規追加
date datetime date datetime
mod timestamp mod timestamp
draft tinyint(4) draft tinyint(4)
ping_uri text ping_uri text
× allow_comments tinyint(4) 新規追加
× allow_pings tinyint(4) 新規追加
× author varchar(50) 新規追加

コメント用テーブル

P_BLOG(p_forum) Loggix (loggix_comment)
id int(8) id int(8)
tid int(8) tid int(8)
parent_key int(8) parent_key int(8)
title varchar(100) title varchar(100)
comment longtext comment longtext
user_name varchar(50) user_name varchar(50)
user_pass varchar(32) user_pass varchar(40) 数値変更
user_mail varchar(50) user_mail varchar(50)
user_uri varchar(100) user_uri varchar(255)
user_ico_num int(8) × (廃止)
color int(8) type int(8) 名称変更
date datetime date datetime
mod timestamp mod timestamp
user_ip varchar(255) user_ip varchar(255)
refer_id int(11) refer_id int(11)
trash int(8) trash int(8)

トラックバック用テーブル

P_BLOG(p_trackback) Loggix (loggix_trackback)
id int(11) id int(11)
blog_id int(11) blog_id int(11)
title varchar(100) title varchar(100)
excerpt varchar(255) excerpt varchar(255)
url varchar(255) url varchar(255)
name varchar(100) name varchar(100)
date datetime date datetime
× trash int(8) 新規追加

ダウンロード用テーブル

P_BLOG(p_bin_data) Loggix (loggix_downloads_data)
id int(11) id int(11)
masterid int(11) masterid int(11)
bindata mediumblob file_data mediumblob 名称変更
P_BLOG(p_bin) Loggix (loggix_downloads_meta)
id int(11) id int(11)
bin_title varchar(100) file_title varchar(100) 名称変更
bintype varchar(60) file_type varchar(60) 名称変更
binname varchar(100) file_name varchar(100) 名称変更
binsize bigint(20) file_size bigint(20) 名称変更
bindate datetime file_date datetime 名称変更
bin_mod timestamp file_mod timestamp 名称変更
× file_hash varchar(50)
bin_category varchar(50) × (廃止)
bincomment longtext file_comment longtext 名称変更
bin_count int(11) file_count int(11) 名称変更
drafttinyint(4) draft tinyint(4)
× author varchar(50) 新規追加

以下は、新しく採用されたタグ用のテーブル。

エントリーのタグ用テーブル

P_BLOG(なし) Loggix (loggix_log_tag)
× id int(11) 新規追加
× tag_name varchar(100) 新規追加
P_BLOG(なし) Loggix (loggix_log_tag_map)
× id int(11) 新規追加
× log_id int(11) 新規追加
× tag_id int(11) 新規追加

ダウンロードのタグ用テーブル

P_BLOG(なし) Loggix (loggix_downloads_tag)
× id int(11) 新規追加
× tag_name varchar(100) 新規追加
P_BLOG(なし) Loggix (loggix_downloads_tag_map)
× id int(11) 新規追加
× log_id int(11) 新規追加
× tag_id int(11) 新規追加

考えられる問題点

  • おそらく、文字化けが発生する

P_BLOGはEUC-JPでデータベースにストックされるため、UTF-8でストックされるLoggixで読むと文字化けが発生する。

対処法：

  • Loggixのコードを全てをEUC-JPにする（非推奨）。
  • phpMyAdminを使いSQLファイルに落とし、テキストエディタやその他の文字コード変換ツールを使ってEUC-JPからUTF-8に保存し直したあと、再度phpMyAdminで読み込んで実行する。

そのまま移行しない方が良いテーブル

  • コンフィグテーブル
  • ユーザーテーブル
  • タグテーブル
  • ファイルダウンローダー関係テーブル

などは新規にLoggix添付のMySQL用のSQLファイルにある該当部分をコピーしてphpAdminのSQL実行画面にコピーして実行し、インストールした方が良い（というか、楽）

また同様に、エントリーやコメントやトラックバックなどと違い、数が少ないと思われるファイルダウンローダーも、新規にインストールしてアップしなおした方がトラブルも少なく、楽。

まとめ

ようは、手間がかかるのだ。

なので、「P_BLOGからLoggixへは簡単に移行出来ますよ。」と大々的に言えない。かといって完全に移行出来ない訳でもないから、「出来ません」とも言えない、という感じである。「エントリーとコメントとトラックバックが引き継げればいいや。」という人のみ、

  • 素直にLoggixに添付されているMySQL用インストールSQLをphpMyAdminで実行
  • 「エントリー」「コメント」「トラックバック」のテーブルを上記の方法で移行

で移行出来ると思われる。

開発系メモ：リスタート

ここ２年くらいの懸案だったP_BLOG Projectにようやくけじめをつけ、サイトを整理し、コードをGitHubに移行したりしながらいろいろ考える事があった。

ちょうど良い機会なので、2009年8月1日を開発系に関するリスタートの日として、環境や、スタンスも含め、色々な意味で心機一転することにした。

まず、メインエディタをMacVimに完全に変更。

icn_MacVim_128.png

急に思い立ったわけではなく、実は2009年3月頃からテスト的に使い始め、覚え書きの記録を英語モードのページに書いたりしていた。

「脱・Macユーザー。これからはマルチOSユーザー」宣言をずいぶん前にしたので、テキストエディタもプラットフォームごとに違うものを使っていた(Linuxではgedit、Winではあれこれ触ったが良いのが見つからず現在に至る）のを、統一したかった。「メインはこれ」という感じで。

クロスプラットフォームではEmacsという選択肢もあるが、いつまでたってもCocoaな時代にふさわしいMacライクなインターフェイスの決定版が出ないし、もう待てなくなった。まぁ、「もう、出ないな、こりゃ」ということにした。あと、ファンにはもうわけないが、私はリチャードストールマンのファンではないし、本も読んだりWebの文献も読んだがあまり好きになれなかった、というのもある。

結局、OS X上でCocoa GUIがあり、マルチタブインターフェイスで、UbuntuとOS X上で同じ感覚で使えるエディターはVimしかない、という結論に達した。VimはUNIXの基本エディタなので覚えて困る事は無いし、マシンを選ばず使える。あと、流儀になれると病み付きになるのが分かった。

次に、クロスプラットフォーム、どのOS、どのマシンからでもコードを管理出来る、という点で、ソースコードの管理を全てGitHubに移行することにした。

ここ数日はずっとGitとGitHubで遊んでいたが、これも慣れると病み付きである。ホント、すばらしい。Linus、あなたは天才だ、Good-bye、SourceForge。Hello, GitHub！という感じである。

そんな感じなので、今後は自分でアーカイブを作って公開とかはもうやらないことにした。CommitしたらすぐにGitHubに上げて終了、というスタンスで。GitHubのHistory機能がすばらしいので、もういちいちChangeLogも書くのも、やめ。

とにかく、面倒な事は少しずつやめる方向で、過去のしがらみもどんどん捨てて次のステップへ、という感じである。

Web技術メモ：GitHub関連メモ

GitHubを使い始めて一日。すっかりGitHubファンになった。

というわけで、GitHubとはなんぞや、興味あるけどどうして良いか分からない、という人の何らかの参考になるかと思い、覚えた事をメモしていくことにする。

なにはなくともアカウント作成

とりあえず、公開するソースがあっても無くてもまずはアカウントを作成しておく。この場合SSH公開キーの登録などは必要なし。

リポジトリを作るにはSSH公開キーが必要

実際にリポジトリを作る段階でSSH公開キーをプロファイル管理画面で登録しておかなければいけない。SSH公開キーの作成方法は以下を参照。

自分はOS Xでやったけど、Mac OS XやLinuxのほうが*NIX系なので簡単かな。Windowsでは試していない。

アカウントに画像を表示する

ユーザーアカウントに画像を表示するには、Gravatarというサイトでアカウントを作って画像を登録する。

ここで登録するメールアドレスはGitHubに登録するメールアドレスと同じにしておく。それで画像が反映されるようになる。

とにかくGitをアクティブに使おう

しょっちゅう変更＆修正を加えるファイルは、もう、なんでもかんでもGitで管理すると便利かもしれない。

Mac OS Xの場合、GUIはGitX - HomeがCocoaでいい感じなのでこれを使っているが、GitHubのリポジトリにpushする方法が分からない。 :-(

とりあえず通常のaddやcommit管理はGitXなのだが、pushする時はTerminal.appを使っている。

コラボレーターの登録

リポジトリのコラボレーター(共同作業者）の登録は、GitHubにアカウントを持っているユーザーのリストから簡単に抽出出来て登録出来る。この際、リポジトリのオーナーがそのリポジトリの管理画面から登録すればよい。コラボしてもらうひとの公開キーとかの登録は必要なし。

あと、便利なのがGitHub内でアカウントを作るとGitHub内部で使えるメールアカウントみたいなものが自動的に作成されるので、ユーザー同士でメールが送れる事。これはGOOD。

・・・というわけで、これを読んだ方でLoggix、P_BLOGなどコラボレータとして登録したい方はメール下さい。:-)

関連URI

Web系メモ：Loggixのこと、P_BLOGのこと

LoggixをGitHubに移行

portal shit!さんの最近のエントリー「portal shit! : GitHubにP_BLOGのソースコードをアップロードしました」に誘発されて、LoggixもGitHubでコードを管理することにした。

kaz6120's Loggix at master - GitHub

今のところまだSourceForgeとの併用。SourceForgeも最近リニューアルされて多少は使いやすくなったんだけど、細かいとこの使い方がイマイチよく分からない、ってのが多いなぁってのがこれまでの印象。ファイルをアップするのも分かりにくいインターフェイスで、「あれ？どうやるんだっけ？」とフリーズすること多し。

暫く様子みて、不都合なければGitHubに完全移行しようかと思っている。

SourceForgeからGitHubに移行したい理由はいくつかあるが、SourceForgeを使っていて感じたのは、

  • 雰囲気が「堅い」。インターフェイスもごちゃごちゃ賑やかなのもあって、なんとなく敷居が高い感じがする。
  • よくも悪くも「プロジェクト」色が強い。
  • 正直、使いにくい。

という感じで、GitHubは

  • 雰囲気が「軽い」。
  • 「プロジェクト」色より「コードのシェア」色が強い。
  • デザインがオシャレで、使いやすいインターフェイス。

という感じ。今のところLoggixはアーカイブだけのリリースしかやっていなかったが、これだとどうしても自分が「プロジェクトリーダー」様という感じで、使う方も気軽に改造したり出来ないような気がする。GitHubにすることでもうすこし「ソースコードをシェア」という感じで、軽い感じで今後はやっていきたい。

Loggix Projectもこのまま行くとP_BLOG Projectのように自分で自分の首を絞めてしまう状態になってしまう気がしたので、このままじゃいかんなーと思っていた。これで生活の足しになるような収益を上げている訳じゃないし、誰かから報酬もらってやっているわけでもない。あくまでオープンソースマインドで「こうゆうコード書いたけど、どう？」というノリでやっている事なので、リアルライフをもう少し圧迫しないようにしないといけない、と考えての事である。

P_BLOGもGitHubへ。そして、オフィシャルサイト終了へ

去年告知したように、P_BLOGはオフィシャルリリースを1.2b4で完了した。が、サイトのほうはこれまで通り公開してきた。

最近はサーチエンジンのロボットでのアクセスが殆どを占めているため、そろそろ終焉、ということにする。ソースはLoggixと同じようにGitHubへ移行。

kaz6120's P_BLOG at master - GitHub

ソースの管理を外部サーバーへアウトソーシングするので、多少肩の荷がおりる。

ソース管理をアウトソーシングする理由

やっぱりソフトの管理サーバーが開発者の自宅サーバーではユーザーにとっても不安要素が多いだろう、ってのが第一。これまで何度も落ちてユーザーに迷惑かけたり、管理に労力使って結構な「自分リソース(時間、お金、労力）」を費やした。いろいろと勉強にはなったが、マイナスも多かった。なので、「もういいかなー」と。

自宅サーバーは、個人用ブログ＆実験用ということで、利用する事にする。その方が気が楽、という結論に達した。

こんな感じで、今年から徐々にWebから身軽になろうと考えている。

Loggix関連メモ：Newカレンダー機能（その２）

アイディア１に加え、年別から月別へアーカイブを手繰っていくアイディア２を実装してみた。

loggix-new-calendar-9526.png

jQueryのプラグインにはdroppy.plugin.jsを使用しているが、元々はオーバーレイするコンテンツメニューをリストの入れ子で作るためのプラグインなので、そのままではイメージ通りにいかない。

結局、droppy.plugin.jsの内部のコードを弄くって、dropplyのメソッドとjQueryの標準メソッドを組み合わせる事でとりあえずひとつの完成形に近いところまで持ってこれた。

ほんとはもっとスマートな実装方法があるかもしれないので、もう暫く当サイトで実装＆テスト運用しながら実験することにする。

Loggix関連メモ：Newカレンダー機能

ずっと「過去ログへのアクセスをもっと上手く出来ないものか」と試行錯誤していて、アーカイブ表示方法の２大メジャーパターンである「カレンダー形式」と「リスト形式」の良いところを上手く組み合わせる事が出来ないものかと考えていた。

当初はカレンダー機能とは別に年別／月別のアーカイブをインデックスするページを別につくろうかと考えていたが、いちいち別のページに飛んで過去ログを探るのはどうも面倒くさいのでこれの代替となるアイディアを考えていた。

ちょっと偶然的にだが、ある程度納得出来る形のものが出来たので、正式実装する前に、試験も兼ねて早速当サイトに導入してみた。

loggix-new-calendar-9522.png

タイトルの年／月をマウスオーバーすると、過去ログのリストが現れて選択出来るようになる。ジャンプするとその月のカレンダーに変わる。

あまり気づかれていない機能なのだが、Loggixではコメントやトラックバックのアーカイブもカレンダーに反映されるように実装してあるので、過去のコメントやトラックバックを探すのにも便利になると考えた。

「月や年度を大きくまたいでジャンプする」というのが苦手なカレンダー機能のインターフェイスをだいぶ改善出来るのでは、と思う。

1 2 3 4 5 6 次へ