api-guidelines/Guidelines.md at master · microsoft/api-guidelinesYou signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
Go 言語と React で考える「いい感じなURL設計」入門
Description 白ヤギコーポレーションさま主催の「最先端情報吸収研究所（AIAL）」のプレゼンテーションで使用したドキュメントです。 「URL」を軸にして、サーバーサイドを Go 言語、クライアントサイドを React (+ TypeScript) で実装する場合の要点を紹介しました。 - いい感じな URL と わるい感じな URL - RESTful API のおさらい - Echo と REST API と URL - React と SPA と URL - いい感じの URL設計を目指す旅 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. interface FooterProps { company:string } export class FooterComponent extends React.Compo
「レイヤードアーキテクチャを意識したPHPアプリケーションの構築」を発表しました
2015/06/27 に開催された PHPカンファレンス福岡2015 にて、「レイヤードアーキテクチャを意識したPHPアプリケーションの構築」という発表をしてきました。 MVC フレームワーク（CakePHP / Laravel）で構築したアプリケーションをレイヤードを意識して改善したという内容です。参加いただいた皆さんの顔ぶれを見ると歴戦の勇者みたいな方ばかりでしたが、和やかな雰囲気でセッションを進めることができました。ご参加ありがとうございました。 発表資料 発表資料は以下です。 MVC にサービスレイヤを追加して、それぞれの役割を意識して作る。レイヤ間の依存を明確にする。サービス（ドメイン）を中心に考える。よく言われていることなのですが、実際に実践する中で、ハマりがちなことや実際に実践してきた中で感じたことを紹介しました。もちろん、これで ok ということはないので、今後取り組んでい
昨今のCSS設計事情からみるCSS設計のあり方とは
本記事は2015年1月に開催されたHTML5 Conferenceでお話させていただいた、 「Beyond CSS Architecture」というCSS設計のセッションをフォローアップする記事です。 本記事では、このセッションの概要と補足、またセッション中に説明できなかった点などについて書いていきます。 ※当日のセッションの動画・スライドも公開されているので、文末からご覧ください。 CSSの難しさと、昨今のCSS設計事情 この近年、CSSにおける設計論というのが話題に出てくるようになりました。筆者も拙著『Web制作者のためのCSS設計の教科書』を書いたり、各地でCSS設計をテーマとした講演をする機会が多くありました。 CSSの難しさというのは、石本氏によるCSSコードの評価についての記事にも書かれているのですが、CSSは良くも悪くも厳格なコード規約は少なく、ただ宣言的に書けばいいだけです
【図解】RESTful WebサービスにおけるHTTPステータスコード : アジャイル株式会社
RESTful WebサービスではHTTPステータスコード=処理結果 弊社 アイコン認証Webサービス は、REST方式のWebサービスとして実装されています。 REST方式でない通常のWebアプリケーションでは、通常HTTPステータスコードとしては200(OK)しか返されません。 エラー等の状態を表す場合でもHTTPステータスは200(OK)が返され、画面に表示される内容にエラーを表すメッセージ等を含ませる事によって状態を表現します。 RESTfulなWebサービスを実現する場合には、処理結果はHTTPステータスコードで表現するべきとされています。 理由としては、以下のものがあげられます。 適切なHTTPステータスコードを返さない ( 全部 200 (OK) とかの ) 場合、エンティティの中身を解析しなければ、処理結果が判別できない。 Web標準に従う事で、HTTPステータスコードから
10 Best Practices for Better RESTful API | Thinking Mobile
Do not use verbs: /getAllCars /createNewCar /deleteAllRedCars 2. GET method and query parameters should not alter the state Use PUT, POST and DELETE methods instead of the GET method to alter the state. Do not use GET for state changes: GET /users/711?activate or GET /users/711/activate 3. Use plural nouns Do not mix up singular and plural nouns. Keep it simple and use only plural nouns for all r
論理削除はなぜ「筋が悪い」か
「論理削除が云々について - mike-neckのブログ」を読んで。 データベース設計において、「テーブルの書き換えをするな、immutableなマスタと更新ログによって全てを構成しろ」というこの記事の主張はモデリング論として全く正しい。 だが、残念なことに、ディスクやメモリが貴重な資源だった時代の技術であるRDBは、そのようなモデリングに基づいて設計されたデータベースには必ずしも適していない。 第一の問題は、RDBに対してなされる様々な「更新」（トランザクション）は不定形（どのテーブルをどのように修正するかはアプリケーション依存）だという点。不定形な「更新」を時系列にそってRDBに記録していくのは、設計と並走性の点において困難あるいは煩雑なコーディングが必要になる（というか、そのような「イベント」による「変化」はREDOログに書き、その更新された「状態」をテーブルに反映していくというのが
ソーシャルゲームのカード需要の話 - slideshare
Pornographic Defamatory Illegal/Unlawful Spam Other Violations Thanks for flagging this SlideShare! Oops! An error has occurred.
Web制作フローが「完璧」にわかる資料や流れのまとめ | コムテブログ
TL;DR 受注前、制作フロー、安定収益源の保守方法まで「作って終わりにしない」Web 制作の一連の流れを記載しておきます。社内だけじゃなく、これから独立する人、フリーランスの方も必見です。 オリエンテーション／受注前 １．書類テンプレート一式 オリエンテーションにおけるヒアリングでは、後に作成する提案・見積書に必要となる質問を用意しておきます。自社の説明をする時は、せっかちなクライアントさんもいるので、だらだら話さず、ポイントを抑えてわかりやすく説明します。ヒアリングした後は、議事録にメモし社内共有。必要な書類（ヒアリングシート／企画書／提案書／業務委託書／見積書／契約書）など一式まとめてますので、書類系のテンプレートは以下で。 企画・提案・見積・納品・契約などのテンプレ・知識まとめ２３ ２．見積もりの目安と計算方法 例えば項目を作るとき１．項目／２．内容／３．設計(人日)／４．製造(人
You don't need API version 2 - yohei's diary
周回遅れ感が半端ないけどバージョニング関連で色々読んで・聞いて思ったことを書く。 APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sight Kazuho's Weblog: 拡張可能なWeb APIの設計原則と、バージョン番号を使う理由について Rebuild: 35: You Don't Need API Version 2 (Kenn Ejima) rest - Best practices for API versioning? - Stack Overflow RESTfulなサービスのバージョンングから得られた知見 RESTとバージョニング 基本的にいわゆる狭義のRESTとAPIのバージョニングは何も関係ない。強いて言えば、HATEOASはバージョニングにも使えるよ、というのがREST信者の主張であるものの、それが正しい（というか実用的）かど
コマンドラインツールについて語るときに僕の語ること #yapcasia
http://yapcasia.org/2014/talk/show/b49cc53a-027b-11e4-9357-07b16aeab6a4
マルチプレイヤーゲームのレベルデザインの基礎を誰にでも理解できるように説明するとこうなる
レベルデザインとはゲーム開発における作業の1つで、ゲーム中に登場するエリアの空間を設計したり、障害物やアイテムを配置したりして、プレイヤーが楽しめるステージを作成することです。ゲーム開発に携わっていない人にとっては取っつきにくそうなレベルデザインですが、レベルデザイナーのBobby RossさんがFPSやTPSなどのシューティングゲームにおけるレベルデザインの基礎を公式ブログで公開しており、わかりやすい内容になっています。 The Visual Guide for Multiplayer Level Design — Level Art+Design Portfolio http://bobbyross.com/blog/2014/6/29/the-visual-guide-for-multiplayer-level-design ◆01：デザインに考慮すべき要素 プレイヤーの行動はレベル
実践的な設計って、なんだろう？
Devlove 名古屋 2014-5-18 DDD, Object Oriented Design, ドメイン駆動設計 オブジェクト指向設計Read less
APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sight
ちょっと前にTwitterでAPIのバージョニングをどうやるかみたいな話をしていたのですが、そのへんもやもやしているので少し整理しておきたいなと。 APIのURLを/api/v1/*とかってやるの、やめたほうがいいとおもうんだけどなぁ。いざv2を作るとなったときに、大量のコピペが発生して後悔するよ、って伝えたい。— Kenn Ejima (@kenn) February 28, 2014 さて、これについて色々と異論・反論も含めた意見が出たのですが、まずは、大昔にURL方式（＝コントローラ分割）でやってきて後悔したぼくが、（5年ぐらい前から）現在はどうやってAPIのバージョンを管理しているか？について紹介します。 基本原理としては、コピペが多発する根っこで分岐（＝コントローラ分割）じゃなくて、必要最小限のところで限局的に分岐するのがいい、という考え方に基づきます。 一言でいうと、「パラメー
Rails で、Controller に定義されている action を一度に取得する方法はありますか？ - QA@IT
平素よりQA＠ITをご利用いただき、誠にありがとうございます。 QA＠ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA＠ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、＠ITの今後のメディア運営方針などを検討した結果、2020年2月28日（金）15:00をもちましてQA＠ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA＠ITの7年間で皆さまの知識
複合主キー「否定派」と「許容派」の論争 - 設計者の発言
定期的に取り上げたくなるDB設計に関する話題である。WEBアプリが一般化して以来、議論されてきた事柄がある。テーブルの主キーを「単独主キー」のみとするか、複数項目を組み合わせた「複合主キー」を必要に応じて使うべきかという問題だ(*1)。複合主キーに対する「否定派」と「許容派」に分かれた議論は劇烈で、宗教論争のようにも見える。 主キーというものは、テーブルの存在意義といってもいいほどに重大な要素である。にもかかわらず、なぜそんな基本的なレベルの議論が始まってしまったのか。２つほどの理由が考えられる。 まず、単独主キーとしてIDを機械的に置くやり方（ID方式）が「オブジェクト指向」と相性がよかったからだ。オブジェクトは固有の識別子（オブジェクトID）を持つので、これに相当するIDをテーブルの主キーとすることで、オブジェクトとDBの設計問題を統合できると考えた技術者が少なからずいた。そのアイデア
ナチュラルキーを主キーにしてはいけない - 設計者の発言
定期的に複合主キーの話題が盛り上がるのは楽しい。好きな話題なので便乗しよう。 「複合主キーを許すべきかどうか」の議論に関して私が理解できないのが、なぜか「ナチュラルキーを主キー（一次識別子）に含めてはいけない」という話とセットで語られがちな点だ。もちろん、ナチュラルキーを主キーに含めてはいけない。だめ、ゼッタイ。しかしこれは複合主キーの必要性とは無関係な議論であって、複合主キーを回避すべき理由にはならない。 ■ナチュラルキーと人工キー ナチュラルキーについて、公開中の販売管理システムのモデルで説明しよう。まず、商品マスタの主キーは「内部商品№」である。これは、追加されるたびに自動的に発番されてセットされる項目で、ユーザの目には触れない「人工キー」だ。「Row ID」と思ってもらえばいい。 [商品] 内部商品№、品名、{品番}、．．． いっぽうユーザの目に触れる項目は、「二次識別子」とされて
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Private Site
GitHub - interagent/http-api-design: HTTP API design guide extracted from work on the Heroku Platform API
イマドキCSS設計
