1月 24
adminアナウンス
いつもサイクロンをご利用頂きまして、誠にありがとうございます。
ciklone.com の計画メンテナンスを実施予定です。メンテナンス中は ciklone.com にアクセスすることはできませんのでご注意願います。
【実施予定日】: 1月29日(日) 22:00 – 01:00 (1月30日(月) -25:00)
【作業時間】: 約3時間を予定
【内容】: ciklone が利用している Amazon EC2 チューニングと サービスのチューニングを実施します。
【サービス】:メンテナンス実施中の約3時間はすべてのサービスにアクセスすることが出来ません。
今回のメンテナンスで ciklone のパフォーマンスを向上させるための作業を実施します。これまで以上に安定・高速なサービスのご提供が可能となります。 お客様にはご迷惑をおかけしますが、ご理解とご協力をお願いします。
メンテナンスに関するご質問は、こちらまでご連絡ください。
12月 19
syojiciklone, SAP, ソフトウェア開発
「クラウドのメリットを一番享受できるのは、個人開発者、ソーシャルアプリ開発企業、IT系ベンチャー企業」
小さく・安く・始めて、成長に合わせてサービスレベルを向上させることが出来るクラウド・コンピューティングはそのような企業にとって大きなメリットがあると考えています。
クラウドは、開発環境、本番環境のインフラ、スケールアップ、運用負荷軽減を低リスクで担保できるサービスになっています。これからのアプリ開発でははじめるときにハードウェアのことをほとんど考えなくて良くなる、と言えます。
サービス提供者の役割によるメリットを簡単にまとめると、
経営者
- システムの投資の無駄を排除 →「所有」から「利用」
- 求めるサービス提供のためのハード購入費用がかからない
- 素早いサービス立ち上げ
開発者
- 開発環境の迅速な構築
- スケールアップ・可用性向上
- 本番リリースに向けたサーバ規模の設計を軽減
- 負荷分散
運用者
- 利用状況に応じた柔軟なリソース割当
- システム運用負荷の軽減
- ハード障害から解放(自前に比べて…

数年前まではデータセンターを借りて自前のハードを用意するか、ホスティングサービスを利用するかが一般的だったと思います。最近はクラウドを使うことで低コストでストレスなく(ハードの面倒を見る必要なく)始めることが出来る。スタートするときの敷居が低くなることはアプリケーションベンダーにとっては良いことです。
2,3年のスパンで見た場合、クラウドよりコスト面でメリットがあるサービスもありますがソーシャルアプリ・ソーシャルゲームに限ればベストなソリューションではないでしょうか。
新しいサービスをすばやく提供するために、その時、そのタイミングで最適なサービスを積極的に利用していきたいですね。
12月 14
adminciklone, アナウンス
いつもサイクロンをご利用頂き誠にありがとうございます。
サイクロン運営チームです。
11月中頃にご利用者様に向けて、サービスの向上に関するアンケートのご依頼をさせて頂きました。多くの方に回答して頂き、利用者様のアンケート結果を今後のサイクロン開発とサービス改善に役立てて参りたいと思います。
ご協力誠にありがとうございました。
アンケートの御礼として回答者全員にAmazonギフト券(500円分)をお送りさせて頂きました。ご活用下さい。
アンケートについてのお問い合わせにつきましては、support @ ciklone.com にメールを送るか、お問い合せフォームからご連絡いただきますようお願いいたします。
今後ともサイクロンを宜しくお願いします。
12月 14
syojiciklone, SAP, ソフトウェア開発
ソーシャルアプリ開発者、とくにインフラを担当している技術者の方はシステム構成をどのようにしていますか。
最近の一般的だと思われるシステム構成とソーシャルアプリ開発のインフラ構築時に使える10個のチェックリストをご紹介します。
実際にソーシャルアプリやソーシャルゲームのシステム構成として稼働実績があるシステム構成になりますので参考になるかもしれません。
インフラ構築に使える10個のチェックリスト
- 必要なときにスケールアウト、スケールアップができるか
- トラブル発生時に問題箇所の原因特定できるか、可能ならその箇所を分離できるか
- トラブル発生時に担当者に通知がされ、その障害対応フローやエスカレーションがマニュアル化されているか
- 性能を考慮したハードウエア、OS、ミドルウエア(Apache、MySQL)構成、設定になっているか
- メンテナンス時間を最小化できるか
- ログファイルをいつでも参照、見える化(グラフ化)できるように管理出来ているか
- サーバの状態を常に把握できているか(全体PV、各ページPV,日毎、時間毎)
- WEBサーバ、キャッシュサーバ、DBサーバ、踏み台サーバの分離、機能の明確化ができているか
- バックアップ・リカバリの方法は確立されているか
- 監視用アプリケーションは正しく、漏れなく設定されているか
1. 必要なときにスケールアウト、スケールアップができるか
自前でマシンを用意する場合、ある程度余裕を持ったインフラを構築しておきたいものです。しかし多くのサービスでは必要最小限ではじめたい。という声があるのも確かです。(予算もありますし)
これがクラウドサービスを利用した場合、クラウドの一番のメリットと言える内容です。それぞれの意味を把握しておくと良いことがあるかもしれません。
- スケールアウト(Scale Out) ・・・ 稼働する仮想サーバの台数を増やす機能
- スケールアップ (Scale Up)・・・ 稼働するサーバ1台の性能をあげる
多くのクラウドサービスではこのスケールアウト、スケールアップは対応しています。その方法については開発しているサービスに合わせて手順書化しておくことがベストです。
ref:クラウドでよく言われる「スケールアウト」の反対の言葉って何だろう?
2. トラブル発生時に問題箇所の原因特定できるか、可能ならその箇所を分離できるか
障害対応やバグ対応でもっとも大切なことは「障害が発生したときの原因を突き止めること」です。
問題が分かってしまえば解決するための対策を行うことはそんなに難しいことではないですし、いつ解決するのかを見積もることも比較的容易に出来ます。インフラを構築する時は、この原因を突き止めるための材料(ログ、発生手順、システムの挙動、エビデンス)をできるだけ多く、楽に集める仕組みが必要ということを意識して、インフラを構築するべきです。
3. トラブル発生時に担当者に通知がされ、その障害対応フローやエスカレーションがマニュアル化されているか
多くのシステムでは有料、無料を問わず、使い慣れた監視システムやパッケージ等のソフトウェアを導入していると思います。監視システムにより障害を検知し、関係者にアラートできることは当たり前ですが、障害発生後の
- 1次受付け
- 問題の切り分け
- 判断をする役割、管理者の判断の有無(ビジネス上の)
- 担当者割当
が重要になります。障害が発生したときは、少なからず現場が混乱した状態になることが考えられますので落ちついて対処するためのルールやマニュアルを問題が起こる前に決めておくべきです。
4. 性能を考慮したハードウエア、OS、ミドルウエア(Apache、MySQL)構成、設定になっているか
アプリケーションの性質に合わせて、特にOS、ミドルウェアの設定は本番サービス開始までに必ず見直しをするべきです。
Apacheの設定ファイルやPHPの設定ファイルが環境によって異なっていたり、開発環境の設定になっている場合がよくありますので注意が必要です。Web#1とWeb#2は同じ役割のはずがApacheの設定やPHP.iniの設定が違う・・・は避けたいですね。
5. メンテナンス時間を最小化できるか
システムを長時間稼働させるように構成されたシステムにおいても、メンテナンスは多くのサービスで必要になります。ソーシャルゲームの場合、メンテナンス中は利用者が「アクセスすることが出来ない = 売上がない」、状態であるため可能な限りメンテナンス時間を最小化させる方法を考えるべきです。
- メンテナンス中に実施している作業は本当に必要なのか・・・サービス停止しなくても良いのでは?
- 夜間等のバッチ処理でできるのではないか
- ジョブの順番や時間帯の変更は可能か
等の今より最適化することは常に考える必要があります。可能なら無停止アップデートができるのかを検討すべきです。
6. ログファイルをいつでも参照、見える化(グラフ化)できるように管理出来ているか
ウェブアプリケーションやソーシャルアプリでは、Apache、MySQL等のミドルウェアのログ、システムログ、アプリケーションログと見なければいけないログが散らばっており、さらにサーバによっても分散していると思います。開発や運用に多くの情報とヒントを提供するものがこのログファイルです。ログファイルをいつでも、すぐに参照できるように管理(集約、集計)することはとても重要です。
サービスが運用フェーズに入った段階でも、警告やエラー情報、タイムアウト等の異常をすぐに見つけ、原因を探す糸口として活用できるようになっているのかをチェックします。
7. アクセスの状態を把握できているか(全体PV、ページPV、日毎、時間毎、リソース)
サービス提供しているウェブサイトのアクセス解析を導入しているのか、また導入済みのアクセスログから自分たちに必要な数字を把握できているのかはとても重要なことです。直接利用者の動向を把握することが出来るツールになるため、自サイトのターゲットと実際の利用者の行動を把握するために活用できるような仕組みになっている必要があります。
8. WEBサーバ、キャッシュサーバ、DBサーバ、踏み台サーバの分離、機能の明確化ができているか
Webアプリケーションの場合、役割によってサーバを分けたりパフォーマンス向上のために分割したり、をよくやります。ボトルネックになりやすいDB(マスタ)やスレーブDB等、機能の明確化をメモ書きしておくことで
- システムの全体像を把握したり、
- 将来の拡張性を考える
- 運用保守の補助資料として利用
- チーム内で情報共有(どのようなインフラになっているかを説明出来る)
ができます。役割分担(機能分担)を明示することはとても重要になります。

ソーシャルアプリ開発プラットフォーム(クラウド環境)

ソーシャルアプリ開発プラットフォーム(クラウド環境)/開発・ステージング環境
9. バックアップ・リカバリの方法は確立されているか
アプリケーションやDBのバックアップを実施することは比較的容易に出来るのですが、
- リカバリにどれくらいの時間が必要なのか、
- 正常にリカバリできるのか
ということは問題になるのではないでしょうか。
バックアップ・リカバリについては本番機と同等のマシンでリハーサルを実施しなければ正確なリカバリ時間や問題点は見えてこない場合が多々あります。(見積だけでは理想値になりやすく、試験をしない場合、障害が起こったときに想定外のトラブルや取り返しの付かない問題が発生すると考えるべきです。)
どうしても開発中は開発が優先されるため、バックアップ・リカバリは後回しにされる場合がありますが、利用者データや自分たちのシステム保全はとても大切なことなので実際にやってみることはとても重要になります。それが運用マニュアルとして記録されているとベストです。
10. 監視用アプリケーションは正しく、漏れなく設定されているか
システムのリソースやサービス監視用の専用ツールはとても高機能で便利に利用しているサイトが多くあります。自分たちのアプリケーション特性にあったチューニングや設定ファイルになっているのかを確認すべきです。デフォルトのままというありがちなミスをしないように注意する必要があります。
ソーシャルアプリ、ソーシャルゲーム開発のプラットフォームを構築するインフラエンジニアは表に立って活躍する目立つ存在ではありませんが、縁の下の力持ちな人材です。ソフトウェア開発期間よりももっと長い期間、運用を支える大切な基盤環境を構築しなければいけません。
インフラに関する10個のチェックリストをあなたの開発チームでも確認してみてください。
これ以外にも大切なチェックはあると思いますので教えてもらえればインフラエンジニアのスキルアップに繋がりますのでご意見をお待ちしています。
12月 12
syojiciklone, SAP, ソフトウェア開発
ソーシャルアプリ・モバイルアプリケーションの開発環境や支える技術についてご紹介。
ソーシャルアプリとは、mixi、mobageやGREEなどのSNSプラットフォーム上で動作するアプリケーションです。
2009年末頃から各SNSプラットフォームのオープン化が進められ、外部開発者でもアプリケーションを開発し、SNSに登録されている多くのユーザに対して公開できるようになっている。数千万人という会員をもつプラットフォームに公開が可能になることで、労せずに大量のユーザに利用してもらえる可能性が高い。
また、これまでのコンシューマ向けのゲームやECサイトと違い、SNSの利点を活用したコミュニケーションを重視していることが特徴の1つになっている。
ビジネスとして考えた場合、
- 大量のユーザにリーチ
- 少ない投資で開発が可能
- その上で大きな成功の可能性あり
など、良いことだけを挙げると一日でもはやく始めたいと思うかもしれないが、そんなに簡単ではないことは承知の通り。
開発者から見たソーシャルアプリ開発で重要だと思われる点は
- 競合が多いく、早いリリースが必要 → 開発の効率化
- アプリがヒットするかどうか不安要素が多く、初期費用を抑える → インフラ・維持費
- クチコミ等、一気にユーザが増えた場合のスケールアップ → インフラ・スケールアップ
- 利用者に向けたイベント、日々サイト更新必須 → サービス運営・ソフトウェアライフサイクル
1. 競合が多く、早いリリースが必要(開発の効率化)
ciklone(サイクロン)を利用しているお客様で携帯向けやスマートフォン開発されている企業様から話を聞いたり、開発者と話をすると、数名~5,6名の開発チームで2,3ヶ月くらいの期間でリリースとなる場合が多いようです。
開発の効率化について実践していることは
- Ruby/PHP/Python等フレームワークを利用
- 開発環境の仮想化・チーム内で共通化
- バージョン管理システムとバグ管理システムの利用
- 開発拠点の分散に対応したコミュニケーションツール・情報共有ツールの利用
などがあります。ソーシャルアプリを開発している企業の傾向がベンチャーというのもあるかもしれませんが…
2. アプリがヒットするかどうか不安要素が多く、初期費用を抑える
初期費用で一番コストがかかるのがサーバ費用やデータセンター費用(人件費以外で)。この費用は売りあげゼロでも確実に必要になる費用です。多くの企業でインフラに関する部分は8,9割がクラウドサービスを利用されているようです。最近は国内クラウドサービスも増えてきており、日本語でのサポートや情報が充実しています。
- GMOクラウド http://www.gmocloud.com/
- ニフティクラウド http://cloud.nifty.com/
- Amazon EC2 http://aws.amazon.com/jp/ec2/
3. クチコミ等、一気にユーザが増えた場合のスケールアップ
自分たちのアプリケーションのユーザが増えることはとてもうれしいことですが、不測のアクセス増加(それも何十倍)が起こった場合には
- ハードウェアの増強 – Webサーバを増やす、キャッシュサーバを増やす、DBサーバを増やす
- アプリケーションのチューニング
などの対応が必要になります。ここでもクラウドによる大きなメリットがあり
- スケールアップが容易
- 一気に増える時間帯、特定の日のみサーバ数を増やすなどの柔軟な対応
が可能です。
開発期間中に高トラフィックを発生させ負荷試験を実施したり、チューニングをすることがとても重要です。わかっていても現実のタイトなスケジュール内ではその時間と人材を確保することが難しいのが現実です。
4. 利用者に向けたイベント、日々のサイト更新必須
ソフトウェアやソーシャルアプリは開発期間よりも運用期間の方が長いことが通常だと思います。特にソーシャルアプリの場合、既存のユーザが飽きないように次から次へと新しいキャンペーンやイベントを行っています。
あるソーシャルゲームサイトでは、朝、前日のアイテム課金結果をみてよく売れている傾向から、その日の夕方には傾向に沿った新アイテムをリリースしたり。週替わり、月替わりのタイミングでイベントを実施したりしています。小さな改善だけではなく、コアなシステムに影響のある変更までユーザ動向に合わせた改善が日々くり返されています。
これは
- 複数サーバの安定した運用
- 複数サーバ(数台~数十台)に確実にリリースするデプロイ管理
- 24時間のサーバ、サービス監視
- ログの解析、ログの視覚化
- デザイン・素材・プログラムのバージョン管理
- 不測の事態と前兆を教えてくれるアラートシステム
ソーシャルアプリ開発では提供するサービスだけではなく、バックエンド側にも高度な技術力が必要とされます。
すべての環境が満足できるレベルまで整備されたプロジェクトが理想ですが、そのようにできない場合が多いのではないでしょうか。
技術者のスキルによりカバーできる部分とできない部分を見極め、あなたのチームに最適な環境を見つけてください。
そのための開発方式やインフラ技術について情報提供していきたいと考えています。


12月 02
adminアナウンス
いつもサイクロンをご利用頂きまして、誠にありがとうございます。
ciklone.com の計画メンテナンスを実施予定です。メンテナンス中は ciklone.com にアクセスすることはできませんのでご注意願います。
【実施予定日】: 12月5日(月) 00:00 – 01:00 (12月4日(日) 24:00-25:00)
【作業時間】: 約10分予定
【内容】: ciklone が利用している Amazon EC2 インスタンスのバージョンアップのため
【サービス】:メンテナンス実施中の10分間はすべてのサービスにアクセスすることが出来ません。
お客様にはご迷惑をおかけしますが、ご理解とご協力をお願いします。
メンテナンスに関するご質問は、こちらまでご連絡ください。
10月 24
jun66j5TracLightning
いましがた TracLightning 3.1.3 をリリースしました。3.1.2 をリリースしてからかなり時間が経ってしまいました。
今回のリリースはメンテナンスを主眼としているため新しい機能などはありません。ちいさなバグをいくつか修正したことと、本バージョンから各 Trac プラグインの egg ファイルを展開した状態でインストールようにしました。
egg ファイルを展開するのは、少しでもパフォーマンスを稼ぐ意味 (それと最初のレスポンスを早くする) で行なっています。その際のチケットは チケット #26414: TracLightningのチューニング方法について にあります。このチケットでは TracLightning に取り込んでいない Trac のチューニング方法もあげていますので興味のある方はご覧下さい。
次回のリリースは 3.2 で Apache と Subversion をバージョンアップして Apache 2.2.x 最新版、Subversion 1.6.x 最新版にする予定です。動作する Subversion 1.7 系の Python バインディングが確保できれば、両方を同梱するかも知れません。
TracLightning や Trac そのもの、同梱しているモジュールのバグを見つけたり TracLightning に対する要望などありましたら TracLightning プロジェクトページまでお願いします。
余談ですが、現時点 (2011-10-24) で Windows 上で動作する Subversion 1.7.x の Python バインディングは CollabNet Subversion Edge 2.1 のみで Trac を Windows で動かすには Subversion Edge 2.1 を使うしかありません。ただし同梱されている Python は 2.7 です。また Apache, mod_wsgi の上で動作するかは未確認です。tracd での動作は確認しています。もう一つの http://souceforge.net/projects/win32svn にある Python バインディングには問題があり動作しません (詳しくは Trac Project #10416 参照)。
Trac と Subversion 1.7.x との組合せの問題は http://trac.edgewall.org/query?keywords=svn17 に上がっています。もし、これ以外に問題を発見したらぜひ教えてください。
それでわ。

10月 11
jun66j50.12, Trac
こんにちわ。いつのまにか十月になっていて朝夕は寒くて、あまり体調がよくないおおまえです。今日は blockdiag というツールを TracLightning から使えるようにする手順を書きたいと思います。
blockdiag というのは http://blockdiag.com/ja/ によると『blockdiag シリーズはシンプルなテキストからブロック図などの画像を生成する画像生成ツール群です。』だそうです。graphviz 風のテキストからブロック図が生成できるツールで graphviz が好きな人はきっと blockdiag も好きなはずです
この blockdiag を Trac から扱えるようにしたプラグインがあり、今回はこのプラグインをインストールして使えるようにします。
1. コマンドプロンプトの起動
インストール作業は easy_install コマンドが主体になるので、コマンドプロンプトを起動しておきます。「スタートメニュー」>「Trac」>「コマンドプロンプト」を使って起動してください。
2. Python Imaging Library のインストール
次に blockdiag が画像を描画するのに使用している Python Imaging Library (PIL) を easy_install コマンドでインストールします。 ここで最新版である 1.1.7 ではなく、1.1.6 をインストールします。
C:> easy_install PIL==1.1.6
なぜ PIL-1.1.6 をインストールするかというと、PIL-1.1.7 のライブラリが VC++ 2008 のデバッグ用 DLL にリンクしているために VC++ 2008 をインストールしていない環境では動作しないという問題があり、これを回避するためにこのようなことをしています。
ちなみに PIL は「Microsoft Visual C++ 2008 SP1 再頒布可能パッケージ」 (x86, x64) が必要なので、インストールしていない場合にはここで一緒にインストールしておきましょう。
3. blockdiag シリーズのインストール
同じく easy_install を使って簡単にインストールできます。
C:> easy_install blockdiag
C:> easy_install seqdiag
C:> easy_install actdiag
C:> easy_install nwdiag
ちゃんとインストールできていれば、blockdiag コマンドが使えるはずなので確かめておきます。その他のコマンドも確かめておきましょう。
C:> blockdiag -h
Usage: blockdiag-script.py [options] infile
Options:
--version show program's version number and exit
-h, --help show this help message and exit
-a, --antialias Pass diagram image to anti-alias filter
-c FILE, --config=FILE
read configurations from FILE
-o FILE write diagram to FILE
-f FONT, --font=FONT use FONT to draw diagram
-P, --pdb Drop into debugger on exception
-s, --separate Separate diagram images for each group (SVG only)
-T TYPE Output diagram as TYPE format
--nodoctype Do not output doctype definition tags (SVG only)
C:> blockdiag --version
blockdiag-script.py 0.9.4
4. TracBlockDiagPlugin のインストール
これも easy_install から簡単にインストールできます。現時点では 0.5.0 です。
easy_install http://trac-hacks.org/svn/tracblockdiagplugin/0.12
5. TracLightning の再起動
必要なモジュール、プラグインをインストールしたので、ここで再起動しておきます。管理ツールで再起動、もしくはコマンドラインから以下のように入力しても再起動できます。
C:> net stop traclightning
C:> net start traclightning
6. trac.ini の設定
プラグインを有効にするために、以下の記述を C:\TracLight\python\share\trac\conf\trac.ini の [components] セクションに追加します。
blockdiagplugin.* = enabled
さらに blockdiag で使用するフォントを指定するために、以下の設定を追加します。
[blockdiag]
font = C:\WINDOWS\FONTS\msgothic.ttc
ここで指定したフォントを使ってブロック図の文字が描画されるようになっていて、この指定がないと文字化けを起こすはずです。メイリオが好きな人は代わりに meiryo.ttc にしたり、自分の好きなフォントをフルパスで指定してみてください。
7. 実際に使ってみる
適当なプロジェクトの Wiki ページで以下のようなのを書きこんでみます。
{{{#!blockdiag(type=png)
diagram admin {
// Set M17N text using label property.
A [label = "起"];
B [label = "承"];
C [label = "転"];
D [label = "結"];
A -> B -> C -> D;
// Use M17N text directly (need to quote).
春 -> 夏 -> 秋 -> 冬;
// Use M17N text including symbol characters (need to quote).
"春は 曙" -> "夏 = 夜" -> "秋.夕暮れ" -> "冬 & つとめて";
}
}}}
すべて問題なくインストール・設定できていれば以下のような形でブロック図が Wiki に展開されているはずです。

すばらしいです。Wiki から手軽に簡単にブロック図を書くことができるようになりました。
ここで試してみたものはあくまで一例に過ぎないので、インストールしていろいろ試してみてください。
10月 03
syojiciklone, アナウンス
ciklone は Trac をベースにした BTS サービスのホスティングサービスを提供しています。利用しているお客様からの声から開発した新しい機能のご紹介です。
チケット管理システムを利用しているとき、使い慣れたメールクライアントからメールからチケット登録やチケットの更新ができれば・・・と思ったことはありませんか?
今回ご紹介する機能は、
- メールクライアントから新規メールを送信してチケットを登録
- チケットの通知メールに返信してチケットを更新
- メールに添付ファイルを付けることで、チケットにファイル添付が可能
- プロジェクトごとに送信用メールアドレスを自動で管理
- メンバー以外のチケット登録は不可
ciklone をご利用のお客様(無料アカウント含む)はどなたでもご利用可能です。

チケットの登録
- プロジェクトの概要タブの「メールでチケット登録」リンク
- プロジェクトごとに送信用メールアドレスが登録されています。このメールアドレスは送信専用です。
- いつも利用しているメールクライアントから東進専用メールアドレスにメールを送信する
- 件名:チケットの件名
- 本文:チケットの詳細内容
- 添付:チケットの添付ファイル
チケットの更新
- メール通知設定をしておきます。チケットが新規作成、更新されるとメールが送信されます。
- 通知メールを受信し、受信したメールを返信。返信するとき、ciklone により管理されたチケット更新用のメールアドレスが設定されます。
- チケットに内容を記述し、送信します。
利用シーン
- ホームページ担当者が顧客からの問い合わせをメールで開発チームに報告
- 顧客先、出先から障害報告
- 携帯、スマートフォンから障害報告
- 自分のタスクを連続で登録
- メールによる返信により、ブラウザでURLを開かなくても状況の確認とコメント作成
ciklone は無料アカウントがあります。
どなたでもすぐに使うことが出来ます。
10月 03
syojiciklone, アナウンス
ciklone 1.8 リリースのお知らせです。
本日、ciklone のリリースを実施しました。ご利用のお客様は新しい機能を利用する事が出来ます。ぜひご利用下さい。
機能紹介
ご要望やバグ報告を頂きました皆様、まことにありがとうございます。
これからもどうぞよろしくお願いいたします。
今後もさらなる改善をおこなってまいります。
ご要望やご質問はこちらまでご連絡ください。
Older Entries