KDDI 法人・ビジネス向け サイトーーTomorrow, Together通信、DX（デジタルトランスフォーメーション）を軸に、 KDDIの取り組みや 最新のトレンドを お届けします。
API 設計ガイド | Cloud APIs | Google Cloud
フィードバックを送信 API 設計ガイド コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 変更履歴 はじめに これは、ネットワーク API の一般的な設計ガイドです。2014 年以来 Google 内部で使用され、Cloud API やその他の Google API を設計するときに Google が従うガイドです。この設計ガイドは、外部のデベロッパーへの情報提供と、互いの連携作業の効率化のためにここで共有されています。 Cloud Endpoints のデベロッパーには、このガイドは、gRPC API を設計するときに特に役立つことがあり、そのような場合にはこれらの設計原則を使用することを強くおすすめします。ただし、このガイドの使用は必須ではありません。Cloud Endpoints と gRPC はガイドに従わなくても使用できます。 このガイドは、gR
GraphQLを使ったアプリケーションがリリースされたので勘所を考えた - Feedforce Developer Blog
小飼です。Dropbox上場のニュースをみて『Rustで上場』という標語を考えたんですが、ロジックが乱暴過ぎるとの評価を頂きました。 さて、フィードフォースでは去る3月8日広告出稿・運用支援ツール『EC Booster』をリリースしました。 この新サービスにはクライアント・サーバ間コミュニケーションのインターフェースにGraphQLを採用しています。 GitHub, Apolloなど、海外では採用事例の増えてきている印象のあるGraphQLですが、国内における採用事例はまだあまり多くはないようです。 そこで本稿では、フィードフォースで実際のプロダクションに採用してみての、初期の使用感などをお伝えしたいと思います。 なお、本アプリケーションはAPIサーバ及びアセット配信サーバとしてのRailsアプリケーションが、 React/Apolloで構築されたクライアント側アプリケーションと、Grap
タイムゾーン呪いの書 - Qiita
コメント欄で「Software Design 誌 (2018/12) に寄稿した内容や修正などをこちらの記事にも適用したい」と言ったあと、やるやる詐欺でずっと放置していましたが、三年近く経ってようやく 2021年 7月に大幅に改訂し、同時に Zenn に引っ越すことにしました。 タイムゾーン呪いの書 (知識編) タイムゾーン呪いの書 (実装編) タイムゾーン呪いの書 (Java 編) なにやら長くなりすぎたので三部構成になっています。 この Qiita 版は、しばらく (最低一年は) 改訂前のまま残しておきます。 タイムゾーンの存在はほぼ全ての人が知っていると思います。ソフトウェア・エンジニアなら多くの方が、自分の得意な言語で、タイムゾーンが関わるなにかしらのコードを書いたことがあるでしょう。ですが、日本に住んで日本の仕事をしていると国内時差もなく1 夏時間もない2 日本標準時 (Japa
はてブの闇を可視化したい - 坂本から君へ
最近知ったのだが、グーグルが提供しているWebAPIに、自然言語処理に関する機能を持つものがあって、これがなかなか面白そうだなと感じている。 cloud.google.com この中でも特に、「感情分析」というやつが気になっていて、どういうものかというと、なんでもいいので適当なテキストをこのAPIに与えると、その内容を分析して、ネガティブ度・ポジティブ度を判定してくれるというものだ。 実際にこのページからデモが試せるようになっていて、試しに「チョコレートが好きすぎて死にそう」と入れてみると、ポジティブ度９０％となり、「チョコレート嫌いなので食べると死ぬ」だとネガティブ度２０％と出てくる。 まあこれはわかりやすい例なんだけど、とにかくこちらが与えた文章に含まれる感情的な要素を読み取って、それを数値化して返してくれるというものだ。 こういうAPIが昔から欲しかったんだけど、なかなか気軽に利用で
同僚のコードレビューでこんなにクラスの設計が良くなったという話 - Qiita
弊社では、案件とは関係のないプロジェクトでも業務時間中にみんなにコードレビューを依頼できる時間が確保されています(参加は任意)。案件のコードレビューを依頼したり、ちょっとした個人の制作物を見てらったりと使い方は色々です。 先日、TypeScriptの練習にQiitaのAPIを叩いていて記事を表示するブログウィジェットを作成しました。このウィジェットのレビューを依頼したところ、クラスの設計について具体的な指摘と、それに対する改善を経験できたのでこの記事に記載します。 今回作ったQiitaWidgetの要件 Qiitaの公式APIV2から記事とユーザー情報を取得し、HTMLテンプレートに表示する 投稿の合計いいね数を算出するために、あるユーザーの投稿を全件取得する (このために複数回リクエストの送信とレスポンスデータの結合を行う) パラメータによってユーザー、いいね数によるソート、表示件数、ラ
今さらだけど「Web API: The Good Parts」 を読んだので自分なりにまとめてみる - Qiita
今さらですが、「Web API: The Good Parts」を読みました。 せっかくなので自分なりにまとめてみます。 1. URLについて 短く入力しやすいURL ×：http://sample.com/search-api/service/api/search ○：http://sample.com/api/search 人間が読んで理解できるURL ×：http://sample.com/api/u ○：http://sample.com/api/user 略すのもだめ products -> prod 大文字小文字が混在していないURL ×：http://sample.com/api/getUserInfo ○：http://sample.com/api/user 基本はすべて小文字 改造しやすい（Hackable）なURL ×：http://sample.com/api/ite
社内勉強会「エキスパートGo」を開きました #golang | メルカリエンジニアリング
こんにちは。 ソウゾウのエキスパートチーム所属の@tenntennです。 7月9日に3時間半かけてみっちりと「エキスパートGo」という社内勉強会を開催しましたので、今回はそのレポートを書きます。 また良い機会ですので、私が所属するエキスパートチームについても少し触れようと思います。 なお、当日の発表資料はSlide Shareに公開しておりますので、ぜひご覧下さい。 www.slideshare.net エキスパートチームについて ソウゾウでは「技術をアウトプットするところに技術は集まる」という思いから、稼働の50%以上を技術コミュニティへの貢献や担当する技術の普及に取り組むエキスパートチームが存在します。 メンバーはGo Conferenceやgolang.tokyoなどを運営している私@tenntenn（Go/GCP担当）とDroidKaigiや技術書典などを運営する@mhidaka（
セマンティック バージョニング 2.0.0
セマンティック バージョニング 2.0.0 概要 バージョンナンバーは、メジャー.マイナー.パッチ とし、バージョンを上げるには、 APIの変更に互換性のない場合はメジャーバージョンを、 後方互換性があり機能性を追加した場合はマイナーバージョンを、 後方互換性を伴うバグ修正をした場合はパッチバージョンを上げます。 プレリリースやビルドナンバーなどのラベルに関しては、メジャー.マイナー.パッチ の形式を拡張する形で利用することができます。 導入 ソフトウェア・マネージメントの世界には、「依存性地獄」と呼ばれる恐ろしいものがあります。あなたのシステムが大きく成長すればするほど、さまざまなパッケージを組み込めば組み込むほど、自分が地獄の底にいることにいつか気づくでしょう。 多くの依存性を有しているシステムにとって、新しいバージョンがリリースされることは悪夢でしかありません。厳密に依存関係を指定し
Semantic Versioning 2.0.0
Semantic Versioning 2.0.0 Summary Given a version number MAJOR.MINOR.PATCH, increment the: MAJOR version when you make incompatible API changes MINOR version when you add functionality in a backward compatible manner PATCH version when you make backward compatible bug fixes Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format. Introductio
API Blueprint | API Blueprint
API Blueprint. A powerful high-level API description language for web APIs. API Blueprint is simple and accessible to everybody involved in the API lifecycle. Its syntax is concise yet expressive. With API Blueprint you can quickly design and prototype APIs to be created or document and test already deployed mission-critical APIs. Tutorial Tools section Focused on Collaboration API Blueprint is bu
RESTfulなWeb APIを設計するときに考えること - Qiita
ApigeeやHerokuのドキュメントに従うのでもよかったんだけど、読んでいく中でやっぱり考えることは出てきたので、あくまで自分のための指針をまとめてます。 包括的なWeb API作成についての知見 HerokuのAPIデザイン | SOTA interagent/http-api-design · GitHub Web API 設計のベストプラクティス集 "Web API Design - Crafting Interfaces that Developers Love" - フリーフォーム フリークアウト Web API Design | Apigee NetFlixもWeb APIの設計についての知見をよく放出してくれてる印象。 設計の基本 基本は /コレクション/名詞 リソースの関係を表したい時に階層化する members/1234/friends 階層は浅く保つ できるだけ/c
画像認識対決 ~Microsoft VS Google VS IBM VS AWS~ - Qiita
はじめに この記事は、Life is Tech ! アドベントカレンダー2016 18日目の記事です。 はじめまして！iPhoneメンターのにっしーです。 「時間があるときに勉強しよう」と人工知能／機械学習／Deep Learning／認識技術といったトピックの記事の見つけてはストックしてきたものの、結局2016年は何一つやらずに終わろうとしているので、とにかく一歩でも足を踏み出すべく、 本質的な理解等はさておき、とにかく試してみる ということで画像認識技術に触れてみることにしました。 画像認識とは? 画像認識とは、画像データの画像内容を分析して、その形状を認識する技術のことである。 -- Weblio辞書 画像認識では、画像データから対象物となる輪郭を抽出して、背景から分離し、その対象物が何であるかを分析するのが基本になります。 しかし、人間なら無意識化に行われていることですが、コンピュ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
フロントエンドエンジニアも知っておきたいgRPC
まだAPI定義管理で消耗してるの？〜Swaggerを用いた大規模アプリ時代のAPI定義管理とコードジェネレート〜
質の高いAPIを作るための7つの習慣
海外・国内の便利なAPI一覧 - API LIST 100+
TechCrunch | Startup and Technology News
TechCrunch
Gamelocker Documentation — Vainglory 1.0 documentation