API開発の基本 - 銀行APIの開発事例に学ぶ『使いやすい』のデザインプロセス APIは多くのWebシステムにおいて、欠かすことのできない技術です。APIをどのように設計、デザインすれば、ユーザに利便性を提供できるのかを、GMOあおぞらネット銀行 CTOの矢上聡洋さんが解説します。API設計の基本、そして実際の銀行APIの設計から、“使いやすい”を生み出すためのデザインプロセスを学びます。
フィードバックを送信 API 設計ガイド コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 変更履歴 はじめに これは、ネットワーク API の一般的な設計ガイドです。2014 年以来 Google 内部で使用され、Cloud API やその他の Google API を設計するときに Google が従うガイドです。この設計ガイドは、外部のデベロッパーへの情報提供と、互いの連携作業の効率化のためにここで共有されています。 Cloud Endpoints のデベロッパーには、このガイドは、gRPC API を設計するときに特に役立つことがあり、そのような場合にはこれらの設計原則を使用することを強くおすすめします。ただし、このガイドの使用は必須ではありません。Cloud Endpoints と gRPC はガイドに従わなくても使用できます。 このガイドは、gR
DELETE_FLAG という思考停止フラグ DELETE_FLAG という boolean の列が DB 設計でよく話題になります。 論理削除という言葉で上手に論理武装し、スキを見せるとすぐに入れたがる人がおり、 一方でそれにつよく反対する人もいます。 自分の経験としては、広義の論理削除はありえると思いますが、実現方法が DELETE_FLAG だとなった時、それはあまり考えてないでなんとなくパターンとして盛り込んでる場合が多いと感じます。 ただし、設計に唯一の答えは無いので、もしかしたらそれが妥当な設計である場合があるかもしれません。 今回は「DELETE フラグがなぜダメなのか?」などという話をするつもりも、アンチパターンだと断言するつもりもありません。 問題は、仕様をきちんと把握すると、「最適な設計は DELETE_FLAG ではない」という場合が有って、その場合は、その最適な設計
今日朝イチで見たエントリーがこれでした。 qiita.com 論理削除の弊害は色々なところで言われているけど、僕の足りない頭で理解している所によると、二つの値しか持たない削除フラグ的なものはカーディナリティが云々で検索条件につけても性能上的にもよくないし、意味がないということです。 論理削除を完全に悪だとは言いませんが、論理削除を極力排したい人たちは、基本的にデータそのものを削除する、もしくは論理削除というのはまだ要件的に未確定な要素が隠されていることを示すフラグであると考えているようです。 僕がITの業界でキャリアをスタートしてから2年目くらいに配置されたプロジェクトではT字型ER手法というのをベースにしたテーブル設計をしていて、そこでかなり鍛えられたわけですが、その時にはだいたいこのような原則を叩きこまれました。 テーブルに状態を持たせない 究極には機械が認識するキーと、人間にとって意
コマンドラインから引数が渡すようなモジュールでも以下のような要件があったりする。 コマンドラインからだけじゃなくて、コード内で直接オブジェクトをnewしたい場合もある 複数のコマンドラインツールを組み合わせて使うような場合に@ARGVを何度か渡すケースがある growthforecast.plみたいなサーバースクリプトだとよくあると思っていて、スクリプト単体で引数渡して起動できるけど、自分でGrowthForecast::Web->newしたくなることもある。これが前者。 growthforecast.plにPlackとGrowthForecastのオプションをコマンドラインから同時に渡したいみたいなのがある。これが後者。 GrowthForecastはあくまで例えです。念のため。 それに対しては以下のようにすればよいのかなーとなった。 parse_optionsというクラスメソッドで@A
とあるブログエントリで「ナチュラルキーを主キーにしてはいけない」という主張を見かけたのでこれに反論しておく。これはリレーショナルモデル的には明らかに間違った考えだからだ。 リレーショナルモデルにあるのはナチュラルキーだけリレーショナルモデルには「サロゲートキー(代理キー)」という概念はない。まずこの点に注意して頂きたい。サロゲートキーとは、データベースアプリケーション開発において実用上必要とされる機能であって、本質的には不要のものである。リレーショナルモデルでは、いわゆるナチュラルキーというものがあれば機能的には十分だからだ。 そのためにはまず「キー」という概念が何を指し示すかということについて正しく理解しなければならない。リレーショナルモデルではキーと呼ばれるものは候補キーとスーパーキーという2つの概念だけである。「タプル(≒行)の値を一意に決定することができる属性(≒カラム)の集合」の
ツイート今日は、第 1 回のSQL アンチパターンの回から良コンテンツを提供しまくりなエンバカデロ・テクノロジーズさん主催の第 3 回 DB エンジニアのための勉強会に参加してきました。 今回は 漢(オトコ)のコンピュータ道で有名な漢の中の漢、 @nippondanji 氏がデータベース設計を徹底指南してくれるということで、元々 DB エンジニアがバックグランドのわたしとしてはいかないわけにはいかんだろう、と喜び勇んでいってきました! 内容はというと下記の概要をカバーする内容でした。 リレーショナルデータベース(以下RDB)は登場してからかなりの時間が経っています。その名が示すように、RDBはリレーショナルモデルをベースに考案されたソフトウェアです。しかしながら、未だに現場ではRDBが使いこなされているとは言いがたく、リレーショナルモデルへの理解も進まず、誤った常識が跋扈しているのが現状で
DBエンジニアのための技術勉強会というイベントで、リレーショナルモデルにおけるDB設計について話す機会を頂いた。リレーショナルモデルは非常に重要であるにも関わらず、現場ではないがしろにされてしまっている。その結果、アプリケーションのロジックを上手くクエリで表現できず、開発現場では非効率な開発が行われ、多くの人がデスマ的な状況に追い込まれている。そういう危機意識について、これまで何度か本ブログでも書いてきたし、WEB+DB Pressで連載している動機もその点にある。リレーショナルデータベースはやはりリレーショナルデータベースとして使うべきだ。そのための鍵となるのが、DB設計である。 今回はなんと約2時間の持ち時間を頂いた。リレーショナルモデルについてはこれまで何度か話す機会を頂いたが、2時間というのは最長記録である。それに合わせてスライドもボリュームたっぷりのものになった。過去のスライドと
日付を扱う処理についていろいろまとめたついでに、わりと簡単なことだけど知らないと落とし穴にハマる系のネタを。 日頃いろいろな処理を書いていて、現時刻を扱うこともは少なくないはずです。ですが、これを適当にやっていると困ることが多々あります。 実行中に「現時刻」を元にした処理が食い違う 例えばこんなコード。ログ集計とかやってるイメージです。 class Analyzer(object): def analyze(self): logfile = datetime.datetime.now().strftime('my_log_file.%H') self.save(self.analyze_logfile(logfile)) def save(self, result): now = datetime.datetime.now() self.result[now.hour] = result
移転しました http://please-sleep.cou929.nu/20130121.html
Aiming Inc. 社内で行われたレベルデザインに関する勉強会のスライドです。使用許可の無い画像は削除してあります。ご了承ください。
最近考えていることを話す機会があったので文章にしてまとめてみる。 疎結合 昨今の複雑化するウェブアプリケーションを効率的に開発するにあたって、疎結合な設計にすることは開発/保守効率を上げるためには必須の条件となることは経験上嫌というほど皆が経験している。(このへんの感覚がわからない人は一度疎結合なアプリケーションを書いてみると良い) 疎結合な設計をすることで問題の切り分けが容易になり、自動化されたユニットテスト・コンポーネントテスト・ UAT が手元の MacBook で実行でき、高いカバレッジに助けられて臆すること無くコードに手を入れられる環境を入手でき、開発する上でストレスなく障害も少ないというメリットが享受できる。 話を戻して、疎結合な設計の例をみると、ウェブサーバとアプリケーションを分離することであるとか、 MVC であるとか、良質かつ単体で動く小さなモジュールを組み合わせて書くと
先月から出稼ぎで東京に来てます。毎年、プロジェクトの特性上、3〜4月に空きが出てしまうので、仕方のないことなんですが。 で、最近ネットワーク図を書く仕事をしているのですが、ちゃんとしたネットワーク図を仕事で書くのは初めてのことでしたので、「コツ」をつかむまでだいぶ時間がかかってしまいました。 その過程で、いろいろと参考にしたサイトをまとめてみます。 書籍 ネットワーク現場の教科書 改訂版 (マイコミムック) (MYCOMムック) 作者: IDG出版社/メーカー: 毎日コミュニケーションズ発売日: 2011/03/31メディア: ムック購入: 1人 クリック: 9回この商品を含むブログ (2件) を見るこれはネットワークの教科書 改訂版 (マイコミムック) (MYCOMムック)の実践編的な内容ですが、本当に役に立ちました。ネットワーク図を書く際には、物理構成図と論理構成図をきちんと分けて書か
HTTPでアクセスして、JSONを返すようなWebサーバを書きたいとする。 どんな言語を選ぶか。どんなミドルウェアを選ぶか。どんなライブラリを選ぶか。 たとえば、TIOBE Softwareが公表している「Programming Community Index(PCI)」という指標がある。人気のあるプログラミング言語の数値化。これを見ていて思ったのは、「多すぎだよね、プログラミング言語」ということ。これらのうち、どの言語を勉強し、どの言語をプロジェクトに採用すべきなのか。 その感触を得るために、 「同じ仕様のREST serviceを複数言語で実装したらいいんじゃね?」 と思った。いくつかの言語で実装を起こしてみている。 前提条件 大規模な開発を想定する。ユーザの規模が大規模。トランザクション数が大規模。そして、開発者が大規模。 実用的かつモダンな開発を想定する。プロジェクト毎のバージョン
完全に手続き的に書くというより、すこしMVCというかMVVC的な構造に切り分けてかいたらいいのではという内容。チラ裏に移動させた
HowFriendFeedUsesMySqlToStoreSchemaLessData - FriendFeed では MySQL を使いどのようにスキーマレスのデータを保存しているのか 目次 この記事について FriendFeed? では MySQL を使いどのようにスキーマレスのデータを保存しているのか 背景 概観 詳細 一貫性と原子性 性能 FriendFeed? では MySQL を使いどのようにスキーマレスのデータを保存しているのか この記事について "How FriendFeed? uses MySQL to store schema-less data" の日本語訳です http://bret.appspot.com/entry/how-friendfeed-uses-mysql CC 2.5 でライセンスされています: http://creativecommons.org/
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く