APIのエラーハンドリングを見直そう - WebPay Engineering Blog
ここ数ヶ月にわたって、WebPayはAPIのエラーにまつわる変更を少しずつ行ってきました。 それに付随してドキュメントも拡張しましたが、変更の背景について十分に説明できていない部分がありました。 この記事では、最近のエラーに関連した変更の背景を紹介し、今後どのようにエラーをハンドルすべきか説明します。 記事の内容は執筆時点のものであり、今後同じようにエラーやAPIの変更を行うことがあります。 変更があっても記事の内容はその時点の内容を保持し、ウェブサイトのドキュメントのみ更新します。 必ずウェブサイトのドキュメントを合わせて参照し、手元で動作確認を行ってください。 エラーはなぜ起きるのか WebPayのAPIは、リクエストされた操作ができなかったときにエラーを返すように設計しています。 可能なかぎりエラーにならないような設計、実装を心がけていますが、エラーは絶対に避けられません。 例えば、
アプリケーションからSlackへの投稿を円滑にするSlack Anywhereをリリースしました - WebPay Engineering Blog
以前、Slackの検索機能を強化するSSlackをリリースしましたが、今回は引き続き、アプリケーションからSlackへの投稿を円滑にするSlack Anywhereを公開しました。 本記事では、その開発の経緯や使い方を説明します。 開発の背景 WebPayは私を含め、遠隔地で勤務しているメンバーが多いため、ChatOpsを積極的に取り入れています。 Slackは多くの外部ツールと簡単にインテグレートできる点でChatOpsにぴったりです。 しかし、用意されているものでは不満が出てくるのが技術者の性です。 導入当初から、より自分たちのオペレーションにマッチした機能に改良し、業務を効率化するために連携機能の開発をすすめてきました。 Slackに繋ぎこむサービスをつくるのではなく、手製ツールからSlackに通知を飛ばす場合、おもにIncoming WebHooksとSlack APIを使います。
Slackの検索機能を強化するSSlackをリリースしました - WebPay Engineering Blog
WebPayではメインのコミュニケーションに2014年2月よりSlackを使っています。 洗練されたインタフェースとエンジニアフレンドリーな機能をもったすばらしいチャットツールですが、いくつか不便な点があります。 そのうちのひとつが検索の性能の悪さです。 英語の文字列でも全然関係ない結果を返してくることが多く、日本語ではほとんど壊滅的になりますっていました（現在はかなり改善されています）。 Slackを利用している日本のチームはいくつもありますが、おそらく同じ問題で悩んでいるのではないでしょうか。 この問題を解決するために、SSlackというツールを作成しました。 （Slack API: Community Built Integrations | Slackにも掲載されました） SlackからOutgoing Webhookで監視しているチャンネル上の発言を取得し、elasticsear
定期課金を行うオブジェクト Recursion を追加しました - WebPay Engineering Blog
決められた周期で自動的に課金を行うためのオブジェクト、Recursionが追加されました。 Recursionオブジェクトを利用することで、これまで独自にバッチ処理などで実装する必要があった定期的な課金処理を代替できるようになりました。 Recursionオブジェクトは 定期的に課金する価格（と通貨） 対象となるCustomer 課金を引き起こす周期（毎月or毎年） を指定して作成すると、作成時から指定された周期で課金を行います。 毎月400円の定期課金をcus_7517t5eEOg04grEがidである顧客に設定する場合は以下のようになります。 1 2 3 4 5 6 7 8 9 require "webpay" WebPay.api_key = "test_secret_6Uz2yNdNA6cpeSW4X4cB5aSh" WebPay::Recursion.create( amount
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
