タグ

設計に関するshimookaのブックマーク (9)

  • WebAPIリクエスト仕様書としてcurlコマンドのご提案 - Qiita

    WebAPIの仕様を記述する方法はいくつかあると思う。 普通に日語で記述する JSON Hyper-Schema、WADL、RAML、Swaggerなどを使う 仕様書の代わりにプログラムを書く HTTPメッセージそのものを記述しておく でも、文法にばらつきがあったり、読みにくかったり、ツールのセットアップが面倒だったり、どれもイマイチな所があって、手軽な方法が欲しいと思っていた。 何気なくcurlコマンドのオプションを調べていたら、「もうこれでAPIドキュメント扱いにしちゃえばいいんじゃね?」と思えてきたのでメモしておく。 curlコマンドのおさらい curlコマンドはlibcurlの付属コマンドで、最近のUnix系OSなら大抵最初から入っていると思う。コマンドの詳細はmanを読んでいただければ。 cURL - How To Use (マニュアルページ日語訳) curlコマンドのオプシ

    WebAPIリクエスト仕様書としてcurlコマンドのご提案 - Qiita
  • Impala Cookbook (非公式)日本語版 (2) メモリ使用量

    昨日のImpala Cookbookの非公式日語版の続きです。昨日は「Impalaの物理設計とスキーマ設計」でした。日は「Impalaのメモリ使用量」です。 例によって駆け足で日語化してるので、間違いがあればコメントに書き込むかTwitterでメンションしてください。 原文: [1] The Impala Cookbook http://www.slideshare.net/cloudera/the-impala-cookbook-42530186 メモリ使用量 – 基 メモリ以下により使用される Hash Join – 復元(decompression)、フィルタリング、射影 (projection)後のRHSテーブル Group by – グループ数に比例 Parquetの書き込みバッファ – パーティションごとに1GB IOバッファ (クエリに渡って共有される) メタデータの

    Impala Cookbook (非公式)日本語版 (2) メモリ使用量
  • Impala Cookbook (非公式)日本語版 (1) 物理設計とスキーマ設計

    The Impala Cookbook 概要 Part 1 – 基 物理設計とスキーマ設計 Impalaでのメモリ使用量 Part 2 – 実用上の問題 クラスタのサイジングと推奨ハードウェア Impalaでのベンチマーク マルチテナントのベストプラクティス クエリのチューニングの基 Part 3 – Impalaの外部 Apache Hive, Apache Sentry, Apache Parquetとのやり取り 物理設計とスキーマ設計 – 概要 スキーマ設計のベストプラクティス データ型 パーティション設計 一般的な質問 物理設計 ファイルフォーマット: いつ何を使うか ブロックサイズ(オプション) 物理設計とスキーマ設計 – データ型 数値(Numeric)型を使用する(Stringではなく) 可能であればString型を避ける String => 多くのメモリ消費、多くのディ

    Impala Cookbook (非公式)日本語版 (1) 物理設計とスキーマ設計
  • BEMによるフロントエンドの設計 | 第1回 基本概念とルール

    BEMによるフロントエンドの設計 第1回 基概念とルール この記事ではフロントエンドの設計方法「BEM」を紹介します。第1回目はBEMのもっとも基となるBlock、Element、Modifierの概念と、class名の命名ルールを解説しています。 はじめに 最近フロントエンド界隈で、『BEM』という言葉を見かけることが増えてきました。BEMとは、Block、Element、Modifierの略語です。Webサイトのコンポーネント化のためのフロントエンド設計方法のひとつで、厳格なclass名の命名ルールが特徴的な手法です。 第1回は、BEMをまったく知らない方向けの入門編です。 なぜBEMが必要なのか 私たちはHTMLCSSを使うことでしか、Webサイトを作ることができませんが、HTMLCSSにはプログラム的な機能が備わっていません。そのために、フロントエンドエンジニアは次のような

    BEMによるフロントエンドの設計 | 第1回 基本概念とルール
  • APIのエラーハンドリングを見直そう - WebPay Engineering Blog

    ここ数ヶ月にわたって、WebPayはAPIのエラーにまつわる変更を少しずつ行ってきました。 それに付随してドキュメントも拡張しましたが、変更の背景について十分に説明できていない部分がありました。 この記事では、最近のエラーに関連した変更の背景を紹介し、今後どのようにエラーをハンドルすべきか説明します。 記事の内容は執筆時点のものであり、今後同じようにエラーやAPIの変更を行うことがあります。 変更があっても記事の内容はその時点の内容を保持し、ウェブサイトのドキュメントのみ更新します。 必ずウェブサイトのドキュメントを合わせて参照し、手元で動作確認を行ってください。 エラーはなぜ起きるのか WebPayのAPIは、リクエストされた操作ができなかったときにエラーを返すように設計しています。 可能なかぎりエラーにならないような設計、実装を心がけていますが、エラーは絶対に避けられません。 例えば、

    shimooka
    shimooka 2014/12/11
    『どこでエラーになったかではなく、エラーにどう対処すればいいか』
  • いまさら「ドメイン駆動設計」を読み終えた - 勘と経験と読経

    今さらなのだけれども、「エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)」を読んだ。仕事で活用できるかと問われると微妙だけれども読んで良かった。避けていたのはいろいろな誤解があった。複雑なソフトウェアを作る為の考え方。 エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践) 作者:エリック・エヴァンス発売日: 2011/04/09メディア: 大型 Eric EvansがDDDのアイデアを著書のドラフトというかたちでWeb上で公開し始めた2002年以来、この知恵の書は多くの識者の間で話題の中心となり、「徹頭徹尾有用な書籍(most thoroughly useful book)」とまで評された。記述されている内容の一言一句すべてにおいて役に立つことしか書かれていない、と賞賛

    いまさら「ドメイン駆動設計」を読み終えた - 勘と経験と読経
  • Google App Engine上のベスト・プラクティス、その1: Datastore

    Google App Engine上でアプリを作りはじめて約二ヶ月。いろいろと分かって来たこともあるので、自分へのメモも含めてまとめてみる。まずは、Datastoreの話から。 なによりも大切なのはデータベースの設計 あたりまえと言えばあたりまえの話だが、App Engine上でアプリを作る上でもっとも大切なこと(=頭を使うべきところ)は、データベースの設計である。特にリレーショナル・データベース(RDB)上でのアプリ作りに慣れた人には、大きな「発想の転換」が必要なので、ここは注意が必要。 特に絶対にやっては行けないのは、 将来RDB上へ移行できるようにレイヤーを作って、その上にアプリを作る RDB上に作ったアプリをデータモデルを大幅に変更せずにApp Engine上に移植する RDBを前提に設計されたフレームワークをApp Engine上に載せて、その上にアプリを作る など。App En

  • CakePHPを使ったMVC設計のベストプラクティス - Sooey

    CakePHPを使ったMVC設計のベストプラクティス 個人的にはCakePHPはあまり好きではないのですが、CakePHP開発メンバーによるMVCデザインの記事 (CakePHP のおいしいべ方)で紹介されていたBest Practices in MVC Design with CakePHP (php|architect’s C7Y)はMVCフレームワーク利用者にとってとても有用な情報だったので、訳してみました(php|architectの方には翻訳許可を頂いています)。 この記事を読んでドメインモデルに興味を持った方は、エンタープライズ アプリケーションアーキテクチャパターン(PoEAA)やDomain-Driven Design: Tackling Complexity in the Heart of Softwareに手を出してみるのもいいかも。他に、InfoQにユーザー登録すれ

  • JDepend

    JDepend は、Javaパッケージ単位のメトリクスを測定するツールです。 これによって以下のような事がわかります。 パッケージに依存する外部パッケージの数 Afferent Couplings (Ca) と呼ばれ、この数値が大きいほど このパッケージは外部から参照されている箇所が多いという意味になります。 つまり、このパッケージの内容を変更することは 外部パッケージに大きな影響を与えることになります。 パッケージが依存する外部パッケージの数 Efferent Couplings (Ce) と呼ばれます。先程と全く逆ですね。 この数値が大きいことは、外部パッケージの変更が このパッケージに大きな影響を与えることを意味します。 抽象度 パッケージに属する全クラスのうち、抽象クラスもしくはインターフェイスの割合を Abstractness (A) と呼んでいます。 この値が大きくなると、パッ

  • 1