作成者別アーカイブ: ニタ

ニタ について

PHP、javascriptがメインですが、他の言語も触ったり触られたり。 WordPressが好きで、プラグインなども公開しています。 http://dev.blog.fairway.ne.jp/wordpress-plugin-rucy/

『リーダブルコード』を読みました。(1)

こんにちは、ニタです。

最近、オライリーの『リーダブルコード』という本を読みました。
その名の通り、読みやすいコードを書くためのノウハウが書かれた、大変ためになる内容でした。

どれだけ短期間でプログラムが出来たとしても、後で他の人が修正を加える事になった時、どこで何の機能をどのように書いているのか、全く理解できなければ、メンテナンス性の低いコードになってしまいます。
最初にプログラムを書いた人が、ずっと保守していかなければならないのでしょうか。
その人が設計内容を忘れてしまったら、どう保守していけばいいのでしょう。

様々な開発言語や、日々新しく出てくるシステムに触れてみるのも大事ですが、プログラムを書くためには、この本に書かれてあるような、もっと基礎的なことが大事だと思います。
これから数回に分けて、この本について感じたこと、大事だと思ったことを書いていきたいと思います。
よろしくお願い致します。

理解しやすいコードとは

僕がプログラマという肩書を戴き、プログラミングの仕事をもらうようになってから、自分で書いたものはともかく、様々なフレームワーク、他のプログラマの方々のコード…いろんなコードを目にしてきました。
共通して分かっていることは、「読みやすいコードは分かりやすい」ということです。
まあ、当然なことなんですけどね…。 そう、コードは理解しやすい内容じゃないといけません。
じゃあ「理解しやすい」って何でしょうか。

コードの意味が分かるということではないでしょうか。
他の人(プロジェクトに参加していない同僚や新しく参加する人)や未来の自分が、そのコードを読んで、短時間で変更を加える事が出来たり、バグを見つけることができることが「理解できる」ということではないでしょうか。
自分が書いたコードの内容って、時間が経つと忘れたりしますしね…。

「簡潔」と「安心」どちらが大事なのでしょう

また、簡潔なコードは理解しやすいと感じる場合もあるでしょう。コード数、行数が少なければその分コードを読む時間は短縮されますし。
では、この場合はどうでしょうか。

return ($foo > 0) ? $hoge * (1 * $var) : $hoge / (1 * $var);

ワンライナーで書かれていて、スマートって感じです。
これをこう書くと、どう感じるでしょうか。

if($foo > 0){
return $hoge * (1 * $var);
} else {
return $hoge / (1 * $var);
}

前者のほうが簡潔なコードですが、読んだときパッと理解できたのは後者のほうではないでしょうか。
後者の方が読んでいて分かりやすく安心します。
簡潔なコードも大事ですが、読んだときの「安心さ」も、分かりやすいコードとして大事なのではないでしょうか。

そのコード、後で読んで理解できますか?

ところで、自分が書いたコードを「理解しやすいコード」と思って書いていますか?
例えそう思っていたとしても、それは自分が仕様を理解し、設計しているからだけではないでしょうか。

前述しましたが、そのプロジェクトに関係のない同僚、もしくはそのプロジェクトに新しく入った人が、そのコードを読んで理解できる内容かどうかが大事だと思うのです。

新しくコードを書くとき、修正するとき、すぐに手を動かそうとせず、
「これから書くコードは理解しやすいコードだろうか?」と一歩引いてみることも大事だと思います。

まとめ

以上のことから、理解しやすいコードを書くためのポイントは、このようなことではないでしょうか。

  • コードは(未来の自分も含む)他人が、最短時間で理解できるように書かなければならない。
  • コードは短くした方がいい。でも「理解するまでにかかる時間」を短くする方が優先。
  • コードを書くとき、すぐにコードの修正に入らず、「このコードは理解しやすいだろうか?」と一歩引いて自問自答し、考えることから始める。

次回は、変数名、関数名などの名前について触れてみたいと思います。
それでは、また。


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!


[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を使用しているので、カスタマイズも可能です。


日付取得で気をつけておきたい事

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

はじめまして、ニタです。

早速ですが、PHPで「今から数日後」「今から数ヶ月後」の日付が欲しい場合、こんな書き方をすると思います。

// 今から2日後
date('Y-m-d H:i:s',strtotime(date('Y-m-d H:i:s',time()) . "+2 days"));

では、以下の条件ではどうでしょうか。


$date = "2012-8-31 00:00:00";
$res = date('Y-m-d H:i:s', strtotime($date . " + 6 month"));
print_r($res);

結果は「2013-03-03 00:00:00」となります。
ですが、8月31日の6ヶ月後なので、2月末日(2013-02-29)でないといけないと思います。

これはstrtotime()において、以下の様に判断しているからのようです。
・2012年8月31日の6ヶ月後は2013年2月31日

・2月31日は存在しない

・31日は28日から3日後。つまり3月3日

最初の時点で日付の正当性をチェックをすべきなのですが、間違ってますね。
なので、ここは多少面倒ですが日付の正当性チェックを挟むようにします。


$sdate = "2012-8-31 00:00:00";
// 年月日時分秒毎に分ける
$hour = date('H',strtotime($sdate));
$min = date('i',strtotime($sdate));
$sec = date('s',strtotime($sdate));
$mon = date('m',strtotime($sdate));
$day = date('d',strtotime($sdate));
$year = date('Y',strtotime($sdate));
// 6ヶ月後の月の1日
$ym = mktime($hour,$min,$sec,$mon + 6,1,$year);
$arrayYm = getdate($ym);
// 日を置き換えて日時の正当性チェック
if(checkdate($arrayYm['mon'],(int)$day,$arrayYm['year'])){
    // そのままの日付で日時取得
    $res = mktime($arrayYm['hours'],$arrayYm['minutes'],$arrayYm['seconds'],$arrayYm['mon'], $day, $arrayYm['year']);
}else{
    // 6ヶ月後の末日にして日時取得
    $res = mktime($arrayYm['hours'],$arrayYm['minutes'],$arrayYm['seconds'],$arrayYm['mon'], date('t', $ym),$arrayYm['year']);
}
print_r(date('Y-m-d H:i:s',$res));

こんな感じで日付の正当性チェックをしつつ日付取得を行うと、いいと思います。