タグ別アーカイブ: web

Chromeデベロッパー・ツールを使ってヘッダー情報を確認する

寒くなりましたね!そろそろインフルエンザの季節が到来しますね。

対策にいち早くワクチン打ってもらおうかな~と思っているモリです。

 

今回はWeb開発で調査に活用できるネタとして、Chromeデベロッパー・ツールでヘッダー情報を確認する方法を簡単に紹介します。

 

画面遷移時の通信している詳細情報(HTTPリクエストやレスポンスのヘッダー情報など。。。)を確認する方法です。

まずは対象となる画面上で右クリックして「要素の検証」を押下します。

Chromeデベロッパー・ツールが立ち上がったら「Network」タブを押下して詳細情報を確認できます。

1

 

詳細情報は大きく分けて3つになります。

1.使用されているファイル一覧

2.ファイルに対する各種情報

3.通信の中身の詳細情報

 

 

1.使用されているファイル一覧

 画面で読み込んでいるファイルを一覧表示しています。

 いくつもファイルを読み込んでいる画面では、たくさん表示されているのでファイルの絞り込みをして最小限の表示に切り替えると見やすいです。

2

 

2.ファイルに対する各種情報

 以下の5つの情報の切換えが可能です。

 a.Headers
 b.Preview
 c.Response
 d.Cookies
 e.Timing

 

 Headers情報

  リクエストヘッダーおよびレスポンスヘッダーが確認できます。

3

 

 Preview情報

  ファイルの内容を確認出来ます。

  画像の場合、大きさ・サイズ・ファイルタイプ・URLなどCSSやJSならファイルのソースを確認することが出来ます。

4

 

 Response情報

  レスポンスされた内容を確認出来ます。

5

 

 Cookies情報

  リクエストおよびレスポンス時のクッキー情報が確認出来ます。

6

 

 Timing情報

  画面が表示完了するまでに掛かった時間が確認出来ます。

  要求の送信待機時間やDNSルックアップ・送信時間・待機時間など確認する事でどのリソースが重いのか把握出来ます。

7

 

表示が遅い!やどんな情報を送っているのかなどなど確認する事が出来るのでオススメです。

Network以外にもたくさんの機能があるので、開発や調査に重宝すること間違いなし!

でわでわ。。。


WordPressでajaxを使う

タグ: , , | 投稿日: 投稿者:

こんにちは、ニタです。

早速ですが、WordPressのプラグインを更新しました!

アイキャッチ画像と更新日を予約更新対象に追加しました!
iframeタグが消えたり、brタグなどに追記したstyle定義も消えないようにしました!
予約更新内容でのプレビュー機能はもう少し先になりそうです!

どうぞよろしくお願いします!
See you again next time, Enjoy WordPress Life!!

と、

これでおしまいとは、いきませんよねぇ…。
では、改めて。

WordPressでもajaxをカンタンに使いたい

WordPressのテーマやプラグインを開発していると、投稿データや外部からのデータをスムーズに取得したい時があります。なるべくスマートに。ajaxとかで。
例えば、投稿一覧ページをページングからajax読み込みによる無限スクロールにしてみたり、プラグインで下のような読み込み機能に使ってみたり…

多少コツが要ります

しかし、WordPressのフロント側のルーティングはすべてコンテンツページとして表示されるので、ajax用のJSONを返すページ(エンドポイント)を作り、そこへPOSTかGETでアクセスさせればajax通信できるわけではありません。
ですが、WordPressの管理画面はajaxをバッキバキにキメていて、そのための機能が用意されておりますので、そちらを使ってajax通信を行います。

基本的な実装の流れはこんな感じです。

  1. wp_ajax_ホニャララというアクションフックを追加し、そのアクションフックに関数を登録。
  2. POSTかGETでのリクエストを受け取って、求めているデータをJSON形式で返却する関数(アクションフックに登録する関数)を作成。
  3. データ取得用のJavaScriptの作成。

実際に作ってみよう

では、先ほどの流れを基に何かしら作ってみます。
前述の図にあった、URLからサイト情報を取得するajaxを実装してみます。
また、ここで使うプラグイン接頭辞はwpmra_とします。

1. アクションフックの追加

ここで追加するアクションフックは、後述するエンドポイントにフックさせることでアクションフックに登録した関数を呼び出すようになっています。
そのため、アクションフックの名前はwp_ajaxと自分で決めたアクション名を繋げたものになります。
wp_ajax_ホニャララホニャララの部分を決めて追加します。
プラグイン接頭辞を含め、以下の様なアクション名と関数名にしました。

add_action('wp_ajax_wpmra_fetch_site_info', 'wpmra_fetch_site_info');

また、フロント側で使いたい場合、WordPressへ未ログインのユーザー向けにwp_ajax_nopriv_ホニャララというフックが用意されているので、そちらを使用します。
ですが、こちらは未ログインユーザー向けのみのものらしく、これだけをアクションフックに追加すると今度はログインユーザーには有効にならないという謎仕様になっております。
ですので、同じ関数を呼び出すアクションフックを2つ追加します。

add_action('wp_ajax_wpmra_fetch_site_info', 'wpmra_fetch_site_info');
add_action('wp_ajax_nopriv_wpmra_fetch_site_info', 'wpmra_fetch_site_info');

2. 登録した関数の作成(JSON返却用)

1.で追加したアクションフックで呼び出している関数wpmra_fetch_site_infoを作成します。

function wpmra_fetch_site_info() {
    $res = array(
        'status' => 'NG',
    );
    if(isset($_POST['post_title'])) {
    // POSTで送信されたURLからRSS情報を取得する
        $rss = get_wpmra_fetch_feed($_POST['post_title']);
        // サイトタイトル、URLを配列へ
        if($rss) {
            $res['status'] = 'OK';
            $res['data'] = array(
                'title' => $rss->get_title(),
                'url' => $rss->get_permalink(),
            );
        }
    }
    // 配列をJSON形式で出力
    header('Content-Type: application/json; charset=utf-8');
    echo json_encode($res);
    exit();
}

// $urlからRSSのFeedデータを取得
function get_wpmra_fetch_feed($url){
    include_once ABSPATH . WPINC . "/feed.php";
    
    $rss = fetch_feed($url);
    if(!is_wp_error($rss)){
        return $rss;
    }
}

簡単に解説しますと、WordPressのwp-includes/feed.phpを使用してRSSのURLからFeed情報を取得し、その中からサイトタイトルとサイトURLをJSON形式で出力しています。
出力後は必ずexit()die()を使って終了させます。

アクションと関数は出来ましたが、JavaScriptでJSONデータを取得するためのURLを知らないといけません。
wp_ajax_のエンドポイントは、サイトURL/wp-admin/admin-ajax.phpになります。
フックに追加した関数を呼び出すには、リクエスト内のactionパラメータにwp_ajax_より後ろに記載した文字列を指定する必要があります。(今回の場合はwpmra_fetch_site_info

3. データ取得するJavaScriptの作成

custom.jsというファイルを作成し、読み込みます。

add_action('admin_enqueue_scripts', 'enqueue_wpmra_script');
function enqueue_wpmra_script(){
    wp_enqueue_script('wpmra_js', '/path/to/custom.js', array('jquery'), '0.1');
}

このjsファイルにデータ取得する処理を書いていきますが、ここで一つ問題が。
先ほどwp_ajax_のエンドポイントはサイトURL/wp-admin/admin-ajax.phpだと説明しましたが、サイトURLは開発環境、テスト環境、本番環境で変わっていきます。
また、この処理をプラグインに実装するとなると、余計に変わります。
JavaScriptにサイトURLの判定処理を書くのも何なので、wp_localize_scriptという関数でPHPからjsに渡すようにします。

PHPファイルにscriptタグで直接書けば良いのでは?という意見もあると思いますが、横着せずPHPはphpファイルに、JavaScriptはjsファイルで管理するよう心がけましょう。

add_action('admin_enqueue_scripts', 'enqueue_wpmra_script');
function enqueue_wpmra_script(){
    wp_enqueue_script('wpmra_js', '/path/to/custom.js', array('jquery'), '0.1');
    wp_localize_script('wpmra_js', 'WPMRAJS', array('endpint' => admin_url('admin-ajax.php')));
}

wp_localize_scriptの第2引数の文字列がcustom.jsでのグローバルオブジェクトになります。
第3引数に渡している配列でWPMRAJSというグローバルオブジェクトに値がアサインされます。

これでJavaScriptを書ける準備が整いましたので、書いていきます。

jQuery(function(){
    // URL情報を取得するボタンを押したらサイト情報を設置する
    jQuery("#wpmra_fetch_site_info").on('click', function(){
            // 記事タイトルに入力されたRSS Feed
        var post_title = jQuery('input[name="post_title"]').val();
        jQuery.ajax({
            url : WPMRAJS.endpoint,
            type : "POST",
            // actionパラメータに、実行したいアクションの「wp_ajax_」より後ろの文字列を指定
            data : {action : 'wpmra_fetch_site_info', post_title : post_title },
            success : function(res){
                if(res.status === 'OK') {
                    jQuery('input[name="mra_rss_title"]').val(res.data.title);
                    jQuery('input[name="mra_rss_feed_url"]').val(res.data.url);
                }
                if(res.status === 'NG') {
                    alert("取得に失敗しました。");
                }
                return false;
            }
        });
    });
});

WordPressプラグインの申請公開方法

タグ: , | 投稿日: 投稿者:

こんにちは、ニタです。

またしてもWordPressネタですが、プラグインを作ったのなら公開してみるのも良いと思います。WordPressをお使いの方々に多少貢献出来るかもしれません。
そこで、今回はWordPressプラグインの申請、公開方法をまとめした。

事前準備・用意するもの

wordpress.orgのアカウント

アカウント登録はこちらからできます。最低でもusernameとemailが入力していれば登録できます。
登録すると、入力したメールアドレスにwordpress.orgからusernameとpasswordが記載されたメールが送られてきます。
こちらでログインすると、プラグインとテーマの申請、WordPressのフォーラムへの参加ができるようになります。

プラグインファイル一式

当然ですが、動作テストし問題ない状態でリリースしましょう。
※今回は割愛しますが、管理画面などに項目を追加するようなプラグインの場合、表示項目の国際化処理をするのをおすすめします。

readme.txtを書く

プラグインには、readme.txtを追加する必要があります。
このtxtファイルを基に、WordPressプラグインページが作成されます。
表記内容は、WordPressのreadmeファイルの標準に沿ったものになり、MarkDown記法で記載していきます。
readme.txtは、プラグインディレクトリの直下に置きます。
表記例はこんな感じ。

=== Rucy ===
Contributors: gips-nita
Tags: post, update content, update post, update page, schedule update, reserve update, reservation update, rucy, Rucy
Requires at least: 3.5+
Tested up to: 3.9
Stable tag: 0.2.0
License: GPLv2 or later
License URI: http://www.gnu.org/licenses/gpl-2.0.html

Add reservation update published content.

== Description ==

You can automatically update the DateTime specified posts published by this plugin.

Post and Page, specify custom post type is also possible.

But in your WordPress, this plugin is a prerequisite is that the reservation can be posted (can use WP_CRON is required).

== Installation ==

You can install this plugin directly from your WordPress dashboard:

 1. Go to the *Plugins* menu and click *Add New*.
 2. Search for *rucy*.
 3. Click *Install Now* next to the *rucy* plugin.
 4. Activate the plugin.
 5. Configure reservation post type in *rucy* in *Setting* menu.

== Screenshots ==

1. Added Reservation Content Editor in Editor.
2. Reservation Content Type Setting Page.

== Frequently Asked Questions ==

== Changelog ==

= 0.2.0 =
* 2014-06-13
* fixed Bugs.
* change input type reservation datetime.
* add check validation reservation datetime is past.

= 0.1.2 =
* 2014-05-04
* add reservation datetime post updated messages.
* add "revision" and "attachment" in invalid custom post type Setting
* refactoring

= 0.1.1 =
* 2014-04-25
* if accept checkbox unchecked , clean schedule update content.
* modified revision post_type do not add schedule update.
* add donation link.

= 0.1.0 =
* 2014-04-18 First release

表記する項目は、以下のとおり。MarkDown記法で記載していきます。
=== [プラグイン名] ===

Contributors: [WordPress.orgで登録したusername]
Tags: [プラグインを検索した時にヒットされやすいタグをカンマ区切りで記載]
Requires at least: [このプラグインが動作保証出来るWordPressの最低バージョン]
Tested up to: [プラグインの動作テストで使用したWordPressのバージョン]
Stable tag: [動作保証出来るプラグインのバージョン]
License: GPLv2 or later (ライセンス)
License URI: http://www.gnu.org/licenses/gpl-2.0.html (ライセンスのURL)

== Description == 詳細説明
== Installation == インストール方法
== Screenshots == スクリーンショットの説明。
1.一番目のスクリーンショットの画像の説明。
スクリーンショット画像は、上記の番号に対応するスクリーンショット画像を用意します。
ファイル名は、screenshot-[番号].[拡張子]
拡張子は、png/jpg/jpeg/gifのいずれかです。
画像ファイルは、readme.txtと同じ階層に配置しておきます。
== Frequently Asked Questions == よくある質問。初回は項目があるだけでも構いませんが、想定される質問を記述するのもいいでしょう。
== Changelog == 更新履歴。更新する度に追記していきます。

wp-plugin_dir

説明用コメントアウトの更新

プラグインのphpファイルに、コメントアウトでプラグインの説明を記述していると思います。
以前、最低でもPlugin NameだけでOKと説明しましたが、こちらも更新しておきましょう。

/*
Plugin Name: (プラグインの名前)
Plugin URI: (プラグインの説明と更新を示すページの URI)
Description: (プラグインの短い説明)
Version: (プラグインのバージョン番号。例: 1.0)
Author: (プラグイン作者の名前)
Author URI: (プラグイン作者の URI)
License: (ライセンス名の「スラッグ」 例: GPL2)
*/

申請作業

wordpress.orgにアップロード

さて、色々準備をしてきましたが、ようやく申請です。
プラグインファイルとreadme.txt、スクリーンショット画像をまとめたzipファイルを作成し、外部からアクセス可能なサーバにアップロードしておきます。

そして、WordPressのプラグイン申請ページで、各入力内容を記入し申請します。

WordPress_›_Requests_«_WordPress_Plugins

これで申請完了です。
審査が通過し承認されると、WordPress.orgからその旨のメールが届きます。

申請ページにもありますが、現在申請している数と審査中の数が出ていますので、タイミングによっては結構待たされる場合もあるようです。
僕が以前申請した際は、2、3日程度でした。
もし、審査に引っかかた場合、その理由などが書かれたメールが届くそうなので、そちらを基に修正するなり、WordPress.orgとやり取りし、再申請となります。

審査が通ったら

審査を無事通過し公開可能となりますと、そのプラグイン用のsvnのリポジトリが与えられます。
前述の、承認されたという連絡のメールにリポジトリのURLが記載されているので、ローカル環境にリポジトリをチェックアウトし、プラグインファイルなどを追加し、コミットします。

// 作業ディレクトリを作成
mkdir ~/workspace/wordpress-plugin/
// チェックアウト
svn co [wordpress.orgから届いたリポジトリURL] ~/workspace/wordpress-plugin/

// プラグインなどファイルコピー
cp file/to/path/my-plugin.php ~/workspace/wordpress-plugin/trunk/my-plugin.php
cp file/to/path/readme.txt ~/workspace/wordpress-plugin/trunk/readme.txt

// svnに追加
svn add trunk/*

// コミット
svn ci -m 'コミットメッセージ'

参照:http://wordpress.org/plugins/about/svn/

コミットが完了すると、15分程度でWordPress.orgに反映され、めでたく公開となります。
以後、プラグインの更新は、このsvnからコミットし更新して反映していきます。

また、コミットする際、svnのtrunkやtagsと同階層にassetsディレクトリを作成し画像を追加すると、WordPress.orgのプラグインページのアイキャッチ的な部分に画像が反映されます。

画像ファイルの仕様は以下になります。
ファイル名:banner-772×250.png
幅:772px
高さ:250pxになります。
画像の種類は、jpg,pngのどちらかです。

また高解像度ディスプレイ向けに、以下の仕様の画像を用意すると、サイト側で動的に切り替えてくれます。
ファイル名:banner-1544×500.png
幅:1544px
高さ:500px

WordPress_›_Rucy_«_WordPress_Plugins


WordPressプラグイン開発のポイント

タグ: , , | 投稿日: 投稿者:

こんにちは。ニタです。

前回、WordPressプラグインのリリース報告後、まともに開発する時間が取れなくて、プラグインの更新が出来ずにおります。
今回は、WordPressプラグインを開発する際の要点、ポイントをまとめてみます。

ディレクトリ、ファイル構成

プラグインは、WordPressのwp-content/plugins/内に格納されます。
プラグインファイルのみを格納するだけでも、WordPressは認識しますが、管理面も考慮して個別のディレクトリに格納しておくのが良いでしょう。
ディレクトリ名は、管理面も考慮して、プラグイン名と同じにするのが一般的です。
他のプラグインと重複しないよう予め調査するか、プレフィックスなどで唯一性を持たせるのもひとつの手です。
もし、開発したプラグインを、一般公開する場合、プラグイン名は特に考慮しておくべきでしょう。

rc_directory

また、プラグインのメインとなるファイル名(そのプラグインのメインとなる処理などが書かれたPHPファイル)は、プラグイン名にするのがWordPress界隈の慣例のようです。
ですが、ファイルの先頭に、プラグインの説明文をコメントアウトで記述していると、WordPressが勝手にメインとなるファイルとして判断するようです。

コメントアウトでプラグインの説明を記述

前述した、プラグインの説明文についてです。WordPressのプラグイン、テーマファイルは、コメントアウトでプラグインやテーマファイルの名称、バージョン、作者名、ライセンスなどを記述する必要があります。

/*
Plugin Name: (プラグインの名前)
Plugin URI: (プラグインの説明と更新を示すページの URI)
Description: (プラグインの短い説明)
Version: (プラグインのバージョン番号。例: 1.0)
Author: (プラグイン作者の名前)
Author URI: (プラグイン作者の URI)
License: (ライセンス名の「スラッグ」 例: GPL2)
*/

特に、プラグインに関しては、このような説明がないと、いくらpluginsディレクトリに格納しても、管理画面のプラグインページで表示されず、プラグインの有効化ができません。
最低でも、プラグイン名「Plugin Name」の項目だけは記述する必要があります。

フックについて。アクションとフィルタ

プラグインを開発すると言いましても、ざっくり言いますと「WordPressのコアファイル群で走っている処理の間に、自作の処理を挟ませて、処理結果を変える。その処理を作る」のが、WordPressプラグインの主な仕事です。
その自作の処理を挟ませることを、WordPressではフック(hook)と呼びます。

フックは、アクションとフィルタに分けられます。

アクションは、投稿を追加した時、テーマを切り替えた時などに走ります。

add_action('publish_post','hoge');

上記の場合、publish_postというアクションをフックに、hogeというfunctionを実行させています。
publish_postアクションは、投稿が公開された時のアクションですので、投稿が公開されたタイミングで、管理者にメールを送信する、ということも可能です。

フィルタは、WordPressのデータベースからデータをブラウザへ表示させる際、ブラウザからのデータをデータベースへ追加するタイミングなどに通る関数を指します。
僕が開発したプラグイン「Rucy」では、以下の様な使い方をしています。

add_filter('post_updated_messages','addRcMessage');

コアファイル群がpost_updated_messagesという、投稿内容を追加・更新した際に編集画面にメッセージを表示する関数に、addRcMessageという自作の関数を通しています。
addRcMessageでは、予約更新日時に関するメッセージを追加させています。
その結果、編集画面では、以下の様なメッセージが表示されるようになります。

rc_addmessage

アクションとフィルタの一覧はWordPress公式のWikiに掲載されていますので、参考にしてみてください。

アクションフック一覧
フィルターフック一覧

プラグインのインストール、アンインストール時のフック

プラグインを、管理画面で有効にした際、プラグイン独自の設定項目などをデータベースに登録したい場合があると思います。
その場合、以下のコードによってプラグインを有効にした際に、関数fugaが実行されます。

// fugaという独自関数を有効化時にフックさせる。
register_activation_hook( __FILE__, 'fuga' );

同様に、アンインストール、無効にした場合に実行させたい処理は以下のようにフックします。

// goodbyeRucyという独自関数をアンインストール時にフックさせる。
register_uninstall_hook(__FILE__, 'goodbyeRucy');

「Rucy」によってデータベースに追加された、予約更新内容や、設定内容を削除しています。
飛ぶ鳥跡を濁さずと言いますか、データベースなどに残したデータによって、アンインストール後のシステムに影響を与えないようにしています。

ざっと書きましたので、まとめますと、

  • プラグインはディレクトリ名、ファイル名は合わせる。
  • プラグイン名は唯一性を持たせる。
  • ファイルの先頭に、プラグインの説明文をコメントアウトで記述する。
  • プラグイン開発の基本はアクションとフィルターのフックを活用する。

こんな感じでしょうか。

このエントリーが、皆様のプラグイン開発の一助になれれば幸いです。
Enjoy, WordPressLife!


background-sizeが効かない

タグ: | 投稿日: 投稿者:

こんにちはモリです。

今回は最近ハマったスタイルについて書いていこうと思います。

背景画像のサイズを変更した時にbackground-sizeを適用したかったのですが

デベロッパー・ツールで確認すると適用されていない。。。

CSSにはスタイルが適用される以下のような優先順位ですが、

1.important
2.インライン(style指定)
3.idセレクタ
4.その他セレクタ
5.ユニバーサルセレクタ(*{})

適用される条件は以下。

・backgroundプロパティの後に記述する事。
・IEはバージョンをIE9以上にすること。

backgroundプロパティの前に記述すると[background-size:auto auto;]で上書きされてしまうらしい。。。

CSS3のブラウザ対応は以下のサイトで確認できます。
HTML5 & CSS3 Support

スタイルはハマるな~。。。でわでわ


[WordPress]公開済みの記事を時限更新するプラグインを公開しました

タグ: , | 投稿日: 投稿者:

こんにちは、ニタです。
CMS、ブログのプラットフォームとしてWordPressは取っ付き易く、WordPressで管理している企業サイトも多いと思います。
「WordPress カスタマイズ」などで検索すると、結構な数の紹介記事などがヒットしますし。

そんなWordPressで、新規作成した投稿には日時指定での公開設定が可能ですが、公開済みの投稿への日時指定更新は、標準機能として備わっていません。
商品ページの価格や、キャンペーンページの時間指定更新がある場合、時間に合わせて更新する必要があります。
これが深夜0時更新だったり、複数ページの更新だとしたら…。ちょっと面倒ですよね。

そんな公開済みの投稿に対して、自動更新してくれるWordPressのプラグインが、既にあるのかと思ったのですが、なかなか見つからなかったので、自分で作ってみました。
WordPressの公式サイトからダウンロード、インストールできます。

img_plugin_rucy
WordPress › Rucy « WordPress Plugins

概要

「Rucy」というプラグインです。当初は「Reservation Update Content」という名前だったのですが、安直だし長いなと思い、頭文字から「Rucy」としました。
「るーしー」と読みます。

管理画面の投稿、固定ページ編集画面で予約更新分の記事内容、更新日時を登録できるようになります。
予約更新すると、指定された日時に記事内容が更新されます。…そのままですね。

利用環境

    • WordPress3.5以上
    • wp_cron()が実行できること(新規投稿で予約公開が正常動作できること)

インストール方法

方法は2つあります。
1. 直接ダウンロード

      • プラグインをこちらのダウンロードボタンからダウンロード
      • ダウンロードしたzipファイルを解凍し作成されたディレクトリを、お使いのWordPressのwp-content/pluginsディレクトリにコピー
      • WordPress管理画面「プラグイン」で「Rucy」を有効化

2. 管理画面から

      • WordPress管理画面「プラグイン」 > 「新規追加」に移動
      • 検索のテキストフォームから「Rucy」で検索
      • Rucyが表示されるので、インストール
      • インストールが成功したら、有効化

使用方法

有効化すると、編集画面に以下のような項目が追加されます。

rucy_sc003

「予約更新を行う」のチェックボックスをチェックすると、チェックボックス横の日時に、更新されます。
更新日時は、更新日時横の「編集」リンクから編集できます。
更新する記事内容は、WordPress標準のテキストエリアで編集できます。
更新日時、予約更新記事内容を編集し、「予約更新を行う」のチェックボックスをチェックして、公開項目の「更新」ボタンから記事を更新すると、指定日時に更新されるようになります。

設定

Rucyには、予約更新を実行する投稿タイプを設定できる設定画面があります。
有効化すると、管理画面の「設定」に Rucyというサブメニューが追加されます。
ここで投稿タイプ別に予約更新項目の追加設定ができます。

rucy_sc001

WordPress標準の、投稿、固定ページのほか、カスタマイズして追加したカスタム投稿タイプも、追加できます。

随時更新していきます

この記事を書いている今日現在(2014/05/06)、Rucyのバージョンは0.1.2です。
今後、アイキャッチ画像を更新可能にしたり、更新日時のUIの変更などの更新を予定しています。
また、Githubでもソースを公開しています。
ご意見、不具合などありましたら、ご連絡ください。可能な限り対応していきたいと思います。

※さくらクラウドにて期待通りの動作をしないという報告をいただいています。
同環境での動作検証ができておりませんが、同環境でご使用予定の方は、予めご考慮いただきインストールしてください。
(2014/09/11追記)

※バージョン0.4.0にアップデートし、ロールバック機能を追加しました。
指定日時に予約更新前の投稿内容に再更新(ロールバック)します。
(2015/10/22追記)


オープンソースカンファレンスに行ってきたよ

タグ: , | 投稿日: 投稿者:

ニタです。

先日というか、だいぶ前になりましたが、オープンソースカンファレンス2014 Tokyo/Springの2日目に行ってきました。

途中、1日目も来ていたhosoくんと会い、いくつか同じセッションを聞いたりしました。
1日目の感想などは彼が書いてくれると思う(多分きっと)ので、2日目聞いたセッションについて。

業務アプリケーションにおけるモダンWeb開発の現状
本当は登壇者は3人いて、ああだこうだ喋る予定だったらしいのですが、1日目の夜に呑んだ結果、お一人でのセッションでした。

カンファレンスあるある。

で、今はnode.jsなフレームワークでの開発がモダンなWeb開発なので、yeomanを使うと便利だYO!ということでした。
WebSocketとかも勉強しておかないといけないようだし、モダンなフロント系開発もやること沢山あって面白そうですね。

つづいて、MySQLパラメーターチューニングの理屈と定石

my.cnf系の話がメインでしたが、テーブル設計での1レコードのデータサイズの見積もりしてメモリに載る容量計算して…。
MySQL、データベースも極めると際限がないなと感じつつも、細かなチューニングについて説明されており、勉強になりました。
パラメータを変えるだけでなく、クエリを見直すのも改善の一つだとも説明していました。
効率的なクエリを書けて、それに見合ったテーブル設計が求められるのだなと痛感しました。

DB系が続きますが、分散KVSとクラウドストレージ Riak & Riak CS
初心者向けMongoDBのキホン!

Riakは本家Bashoジャパンの社員の方が登壇され、Riakの基本的な機能説明でしたが、2.0および新製品のRiakCSに追加される、全文検索(コードネーム:yokozuna)は使えそうなのかと。

MongoDBも機能説明程度でしたが、NoSQLなDBではMongoが使いやすそうな印象でした。
とはいえ、トランザクション、スキーマ、JOINがないとか使いドコロ難しそうな印象も受けました。

セッション以外にも、様々なオープンソースなプロジェクトの展示もありました。
なかでもbaserCMSの管理画面は、開発側の手離れがしやすく、日本人が操作しやすいつくりになっていて、管理画面づくりの参考になりそうでした。
管理画面のトップページに、よく使う機能(新規投稿やコメント一覧表示など)のリンクが設けてあったり、確認画面をページ遷移せず、モーダルで表示させるなど、妙なところの痒いところに手が届くようなアイディアは関心しました。


シャレオツなAPIドキュメントページを作ろう

タグ: , , | 投稿日: 投稿者:

ギロッポンよりこんにちは、ニタです。

今回はWebAPI向けのドキュメントジェネレーター「apiDoc」を紹介します。

ドキュメントジェネレーターといえば、ApiGenやDoxygen、phpDocumenterなどありますが、それらはクラス内メソッドについてのドキュメントであり、外部向けのドキュメントとしては不要な内容も記載されてしまいます。
RESTfulなAPIドキュメントとしてはちょっとドキュメントとしての意味合いが違います。
サンプルを見ていただくとわかると思いますが、apiDocは独自記法ではありますが、生成されたドキュメントの見易さとしては他のドキュメントジェネレーターより上だと思います。

※先日、弊社のサービス「extorage」のAPIが公開されましたが、そちらのドキュメントページの生成でも使用しています。

インストール

npmよりインストールしますので、予めインストールしておいてください。
まあ、node.jsと一緒にインストールされますので、node.jsをインストールすればいいでしょう。
mac以外は知りません。

brew install node

npm install apidoc -g

ソースへの表記方法

javaDocとは違う独自記法をメソッドのアノテーションに表記します。
パラメータの説明はこちらにありますが、ざっと書くと以下のようになります。


/**
 * メソッドへのリクエスト方法、URL、名前
 * @api {get} /api/username username (ユーザー名)
 * apiのバージョン
 * @apiVersion 1.0.0
 * apiの名前。生成されたページでのアンカー名になる。
 * @apiName ユーザー名
 * 所属するAPIグループ
 * @apiGroup API
 * 詳細説明。HTMLも表記可能。
 * @apiDescription 現在ログイン中のアカウントユーザー名を返却します
 *
 * APIリクエスト時の返却内容のサンプル。ファイル形式がjsonの場合、以下のようにします。
 * @apiSuccessExample Success-Response(example):
 *     HTTP/1.1 200 OK
 * {
 *     "UserName" : ユーザー名,
 *     "message" : "OK",
 *     "response" : 200
 * }
 * エラー名。複数表記可能。
 * @apiError NotFound 見つかりませんでした
 * エラー時の返却内容サンプル。同じくjson形式で。
 * @apiErrorExample Error-Response(example):
 * HTTP/1.1 404 Not Found
 * {
 * "error" : "ファイルが見つかりません。",
 * "message" : "Not Found",
 * "response" : 404
 * }
 */
public function username(){
    // すばらしいコード
}

生成

実行コマンドは以下になります。

apidoc -i path/to/dir -f ".*\\.php$" -o path/to/output/dir -t template/path/

コマンドオプション

-i 対象のソースがあるディレクトリパス
-f 上記-iで指定したディレクトリのどのファイルを対象とするか。1つのファイルだけの場合はファイル名を指定。デフォルトでjsファイルを対象とするので、上記のように拡張子指定も可能。
-o 生成したデータの出力先。
-t テンプレートディレクトリ。apidoc -hでデフォルトテンプレートのパスを参照可能。

実行すると、このようなページが生成されます。フラットデザインがイマドキ感があってシャレオツですね。
apiDoc__sample

基本的にこれだけで生成可能ですが、APIのサービス名やバージョン、利用方法などの総合的な説明文などは、生成時に、別ファイルを読み込ませます。
※apidocの実行は、以下の2ファイルがあるディレクトリ上で行わないと読み込まれないようです。

package.json 生成するAPIのサービス名、説明文、バージョンなどを管理。
API.md 総合的な説明文。Markdown記法で表記。pakage.jsonにファイル名を追記して読み込ませる。

package.json

{
"name": "sample API",
"version": "1.0.0",
"description": "サンプルAPIのドキュメント",
"apidoc": "This is a description, it will be ignored if parameter apidocFilename exist.",
"apidocFilename": "API.md"
}

API.md

# ご利用にあたって

ここに利用方法などの記載する。

## 共通URL
各APIのエンドポイントのURLは以下を共通して使用します。
http://examp.le/sample/

※ユーザー名取得の場合

http://examp.le/sample/api/username

apiDoc__sample_API_-_1_0_0-9

apiDoc__sample_API_-_1_0_0-15

また、テンプレートはbootstrapを使用しているので、カスタマイズも可能です。


[golang]マグマ大使よりステキなWebフレームワーク「Revel」

タグ: , | 投稿日: 投稿者:

norです。

今日はマグマ大使(Peeping Life バージョン)よりステキなWebフレームワーク

Revel

を紹介します。

Revel は Java/Scala 界隈で絶大な人気を誇る Play Framework を参考に開発されたWeb Application Framework です。

Play Frameworkのいいところどりをしつつ、golangの洗練された非同期処理機構によりコールバックという野蛮な押し込み強盗から身を守ることができます。

簡単にいいところを紹介しますと。

  • ソースコード変更自動検知による、ホットコードリロード
  • ノンブロッキング Web サーバ
  • フルスタック Web フレームワーク
  • ハイパフォーマンス
  • ステートレス
  • 非常に簡単な
  • golangで実装されている、golangで実装されている

という特徴をもっています。

特に、 Twisted や Tornado(Python)、EventMachine や Rev(Ruby)が好きな方、苦労したことがある方にはお勧めです。

golang でのノンブロッキングの実装の簡単さを経験すると、「君のサービス、サーバ何台で動かしてる? 僕ならきっと5分の1にできるよ(フフン」なんてブラックジャックも真っ青な勘違いをはじめてしまうほどアガります。

Erlang とか Huskell でごりごりサービス組み上げられちゃうような人も箸休めにどぞ。

※ nor は Erlang に片目をささげるほどの信者ですので、誤解のないよう

さて、golang への愛を語るのはこの程度にしまして、第1回ということで、今回は golang のセットアップから Revel で Web ページ表示までしてみたいと思います。

インストール

GOPATHの設定

mkdir ~/gocode
echo 'export GOPATH="$HOME/gocode"' >> ~/.zshenv
source ~/.zshenv

golang のインストール(マカー以外は知りません)

brew install go

Revel のインストール

go get github.com/robfig/revel

Revel のビルド。

go get github.com/robfig/revel/revel

$GOPATH/bin以下にコマンドがビルドされているので、PATHを通す。

echo 'export PATH=$PATH:$GOPATH/bin' >> ~/.zshenv
source ~/.zshenv

Revel アプリケーションの作成

cd gocode
revel new my app
~
~ revel! http://robfig.github.com/revel
~
Your application is ready:
/Users/nor/gocode/src/myapp
You can run it with:
revel run myapp

Revel アプリケーションの実行

revel run myapp

http://localhost:9000 にアクセス
ss