OpenAPIはいいぞ - Qiita
この記事は Open API Advent Calendar 2017 の 1 日目の記事です。 Open API Specification は、 Open API Initiative が策定を進めている REST API を定義するための仕様です。どの URL にどのようなパラメータを渡すとどのような結果が返ってくるかを記述するための JSON/YAML ベースのフォーマットで、ツールやサービスとの連携も図られています。 今年 2017 年は、 3.0.0 がリリースされました。元となった Swagger が 1, 2 で Open API Spec としては最初のバージョンとなります。 構造の改善 が入り、全体的に使い勝手が良くなった・細かいハックをしなくても運用しやすくなったという印象です。 また、 2016年の API Blueprint (apiary) に続き RAML の
「悪い方が良い」原則と僕の体験談｜Rui Ueyama
ソフトウェアの世界には「悪い方が良い」原則という有名なエッセイがある。キレイにレイヤ分けされた一貫性のある良いデザインよりも、一見手抜きの悪いデザインのほうが実は良いときもあるという話だ。この逆説的なデザイン原則を僕は身をもって体験したことがある。それについてちょっと書いてみようと思う。 僕はlldというリンカの現行バージョンのオリジナル作者だ。リンカというのはコンパイラと組み合わせて使うもので、実行ファイルやDLLを作るのに使用される。lldはプロダクトとしてはかなり成功していて、標準のシステムリンカとして採用しているOSがいくつかあったり、GoogleやFacebookなど皆が知っているような大規模サイトの中で広く使われていたりする。 現在のlldは2世代目で、第1世代のlldは僕がプロジェクトに参加する前から存在していたのだけど、数年前にそれを捨てて一から書き直すということになった。
API 設計ガイド | Cloud APIs | Google Cloud
フィードバックを送信 API 設計ガイド コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 変更履歴 はじめに これは、ネットワーク API の一般的な設計ガイドです。2014 年以来 Google 内部で使用され、Cloud API やその他の Google API を設計するときに Google が従うガイドです。この設計ガイドは、外部のデベロッパーへの情報提供と、互いの連携作業の効率化のためにここで共有されています。 Cloud Endpoints のデベロッパーには、このガイドは、gRPC API を設計するときに特に役立つことがあり、そのような場合にはこれらの設計原則を使用することを強くおすすめします。ただし、このガイドの使用は必須ではありません。Cloud Endpoints と gRPC はガイドに従わなくても使用できます。 このガイドは、gR
プログラミング経験がない経営者のためのソフトウェア開発 11の事実 | Social Change!
今やどんなビジネスでもITが関係している。ITを支えているのはソフトウェアだ。あらゆるものがソフトウェアで実現される時代になった。そんな事業や生活に密接に関わるソフトウェアだが、その開発について知られていないことも多い。 とくに経営者がプログラミング経験がないことで、ソフトウェア開発のリーダーシップをとるときに的外れなマネジメントをしてしまうことがある。あまねく経営者がプログラミング経験があれば良いのかもしれないが、それは現実的ではない。 プログラミング経験がなくても、せめてソフトウェア開発の特性について知っておくと良さそうなこともあると思い、なるべく専門用語を使わずに本稿を書いた。 プログラミングは製造ではなく、設計である いまだにソフトウェア開発を、ビルや家屋の建築に喩える人がいるし、工場でモノを製造するようにプログラムが作られると思っている人もいる。 ここが間違いのもとだ。ハードウェ
シンプルさの必要性 · eed3si9n
2013-06-24 2012年4月23日にテキサスの Austin で行われた RailsConf 2012 での Rich Hickey (@richhickey) さんによる基調講演、Simplicity Matters を書き起こして翻訳しました。 Rich Hickey さんは Clojure や Datomic の作者です。 この翻訳は Creative Commons Attribution ShareAlike 3.0 ライセンスに基いて公開します。 Rich Hickey 講演 e.e d3si9n 訳 談: こんにちは。ご招待いただきありがとうございます。 聞く所によると RailsConf はいつもコミュニティーからかなり外れた人を選ぶらしく、今回は僕ということになりました。 僕の電話ボックスは外に駐車してあります。(会場、笑) だけど、今日は言語の壁を越える話題を持
Reduxは不要ではないか？ - Qiita
僕の本職はサーバーサイドなのですが、半年くらいReactとReduxを使ったフロント部分を触ったので、書きたいと思います。 先にReact.jsについてですが、本家がチュートリアルをしっかりと用意しており、学習コストも高くなく、悪くないものだなと思いました。 しかし、Reduxが入った途端、めっちゃ複雑になった印象があります。chromeのプラグインを入れて開発するのが普通とか言われたのですが、そんなものを使わないと作業できないくらいに複雑で辛いなぁという印象です（Javascriptは、console.logがあれば、ほぼ開発できる気がします。） ここから先は、こんなこと考える人も居るんだなぁ程度で見てください。Reduxが好きな人はすごく嫌な記事かもしれません。その場合は、ここでそっ閉じしてください。 Reduxはモダンだから採用した これよく聴くのですが、本当に辞めてほしいです。jQ
サーバーレスがアプリケーションにもたらす本当のメリットとは？「サーバーレスのポテンシャルとシステム表現」#devsumi ｜ Developers.IO
サーバーレスがアプリケーションにもたらす本当のメリットとは？「サーバーレスのポテンシャルとシステム表現」 #devsumi 「そのサーバーレス、本当に意味あるの？」 AWS re:Invent 2014で、AWS Lambdaが発表されてから丸3年が経過。サーバーレスという単語もすっかりこの界隈では定着した感はあります。 ですが、実際の開発・運用ノウハウについては、まだまだ試行錯誤が続いているのが現状じゃないでしょうか。ぶっちゃけ、既存アプリケーションのEC2をLambdaに置き換えるだけではほとんどメリット無いでしょ、という感触は、ある程度サーバーレスアプリケーションをゴリゴリ作っている人であれば、よく感じていることだと思います。 そんななか今回受講したこのデブサミのセッションでは、新しい観点でサーバーレスがもたらす恩恵やメリットを捉えることができてごっつ新鮮だったので、その模様をお届け
エンジニア歴20数年の私が、設計書を書く際に心がけていること - Qiita
はじめに 時の経つのは早いもので、私がIT業界に身を置いて四半世紀になってしまいました。 その間、膨大な数の「設計書（仕様書）」を書いて来ましたが、未だに悩み・迷いは尽きません。 それでも、亀の甲より年の劫とも申しますので、私なりの経験則を「個人」と「チーム」の両観点でまとめてみました。 本稿のテーマは、「主に設計書を想定した、開発ドキュメントの書き方」です。 本稿で前提とする設計書は、ExcelやWordで書かれた、フォーマルな（≒納品物になりえる）設計文書、です。 したがって、自社サービス開発よりも受託開発、アジャイルよりもウォーターフォール、を前提として読んでいただいた方が、しっくりくると思われます。 ＜ご注意＞ 本稿の内容は執筆者独自の見解であり、所属企業における立場、戦略、意見を代表するものではありません。 個人的に心がけていること 当該文書の作成目的や位置付けを冒頭に記載する
日経電子版を速くする / nikkei-inside-frontend - Speaker Deck
Inside Frontend #2 の発表資料です https://inside-frontend.com
SpaceXの超大型ロケット「Falcon Heavy」に強力なエンジンではなく27基の小型エンジンを搭載した理由とは
2018年2月6日(火)に打ち上げに成功したSpaceXの「Falcon Heavy」は3基のブースターを使って、地球の重力圏を脱出する推力を得ていますが、1基のブースターには9基の小型エンジンを搭載しています。つまり、計27基のエンジンを正しくコントロールして、打ち上げを成功させていました。過去の歴史をさかのぼってみても、「Falcon Heavy」以外に10基以上のエンジンを搭載したロケットの打ち上げが成功したことはなく、前人未到の記録であることがわかります。なぜ、「Falcon Heavy」が複雑な設計方針を採用したのか、その理由について、SpaceXのCEOであるイーロン・マスク氏が語っています。 Musk explains why SpaceX prefers clusters of small engines | Ars Technica https://arstechnica
構造化プログラミング - Wikipedia
構造化プログラミング（こうぞうかプログラミング、（英: structured programming）は、コンピュータプログラムの処理手順の明瞭化、平易化、判読性向上を目的にしたプログラミング手法である。一般的には順接、分岐、反復の三種の制御構造（control structures）によって処理の流れを記述することと認識されている[1][2]。制御構造は制御構文、構造化文（structured statement）、制御フロー文（control flow statement）とも呼ばれる。また、プログラムを任意に分割した部分プログラム（サブルーチンとコードブロック）の階層的な組み合わせによるプログラムの構造化も指している。 このプログラミング手法の普及に貢献したのは、1968年の計算機科学者エドガー・ダイクストラによるACM機関紙への投書「Go To Statement Consider
ランキング設計はどうあるべきか？ その2｜深津 貴之 (fladdict)｜note
前エントリで論じられた、正しいランキング設計の考察の続き。第2回は、ランキングの収奪性、格差の固定性を軽減する手段を、具体的に論じてみる。 前回の記事へのTwitter上のフィードバックは、Togetterにまとめてある。こちらもご興味があれば、一読の価値がある。いくつか被ってしまったものもあるけれど、諸々の後半記事。 「ランキング」以外の名称を用いるこれはほぼ確定。ランキングという名前は、「noteとして競争原理を推奨する」という強いメッセージを発する。noteの全てのユーザーが、競争原理で動いているわけではないので、これは望ましくない。 おそらく最終的には「注目」「人気」などの名称を使うことになるかと思われる（「オススメ」はパーソナライズ用にとっておく）。また、「ランキング」という名称やスタンスをやめることで、後述するようないくつかの公平性のための施策を行う余地が生まれる。 時間による
どのようにしてクラス設計を行うのか？クラス設計の考え方とコツ
今回は、詳細設計（内部設計）におけるクラス設計について、考えてみたいと思います。 クラス設計とは 外部的な振る舞いを設計する基本設計（外部設計）と違い、クラス設計は、プログラム内部の構造を設計する詳細設計フェーズに位置します。 極端な話、クラス設計などなくても、全ての処理をひとつのメソッドに書いてしまうこともできます。 では、なぜそうしないのか？先に述べたようなプログラムでは、様々なコストが掛かってしまう可能性が非常に高いからです。 劣悪な設計によるコスト増大 保守コスト たとえば、一人でプログラムを組むとしましょう。プログラムの隅々までしっかり把握しており、何か変更を加えなくてはならなくなったときでも、素早くその箇所に辿り着き、変更を加えることができます。 しかし、現実に、一人でそのプログラムを永久にメンテナンスすることはあり得ません。自分ひとりで運営しているサービスであったとしても、不
いまさら聞けない「オブジェクト指向設計の3つのコツ」～オブジェクト指向設計問題解説 #objectoriented - CodeIQ Blog
CodeIQ中の人、millionsmileです。 いろいろ経歴を積むと、「いまさら聞けない」ことが増えてきます。「オブジェクト指向」というのもそんないまさら聞けないものの一つでしょうか。 そんなわけで、いまさら聞けないことをイマサラ問題として出題してみました。 問題は、日本のITエンジニアの父と言いたくなるくらい温かみのあるフィードバックをしてくれることで好評な有限会社システム設計の増田亨さんからの出題です。オブジェクト指向設計について2問出題していただきました。総計65名もの方に挑戦いただきました！ 問題の解説記事は、オブジェクト指向設計の3つのコツを中心に説明してくれていますので、読みやすいですし、頭にすっと入ってきます。 ではでは、増田亨さんによる解説記事をお楽しみください。 https://codeiq.jp/ace/toru_masuda/ ◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇
オブジェクト指向とクラス設計の考察 - Qiita
はじめに ここで書かれていることは、真理や解答を提示するものではなく、あくまでも個人的な見解です。 オブジェクトの選定とクラス設計 オブジェクト指向について、色々と投稿したところご意見を頂いたので、それを踏まえながら、 オブジェクトとクラス設計について書いてみます。 オブジェクト指向では人間や動物などを例にとって説明されることがあります。これ自体便宜上よいと思います。ただし、実際クラス設計を使って行く時、気をつけないといけない落とし穴があると思っています。 オブジェクトの特性は、値（プロパティ）と処理（メソッド）をパッケージにしているところにあると思います。つまり、値と処理の関連性があるからこそ、クラスにそれらを閉じ込めるわけです。 ただ、人間と動物の例で注意しないといけないのが、値と処理の関係性が希薄になったりし、それが「クラスの肥大化」をもたらしかねないということです。（あくまでも例だ
単一責任の原則（SRP） - Qiita
Single Responsibility Principle（単一責任の原則）は、Tom DeMarco の Structured Analysis and Systems Specification と、Meilir Page-Jones の The Practical Guide to Structured Systems Design で説明されている。この原則は次のようなものだ。 クラスを変更する理由は複数存在してはいけない なぜこうする必要があるのか？ 役割が単一なクラスの仕様要求が変化した場合、その変更部分は浮き彫りになり、どのように変化したのかわかりやすい。これは、ほとんどの人が納得するはなしではないだろうか。 しかし、役割が複数あると、その1つ1つが変更理由になってしまう。複数の変更理由によってクラスが変更されると、変更部分がぼやけてしまう。また、ある理由により変更した部
アジャイル設計の本を読んでいる | ゴミ人間.com
単一責任の原則(SRP: Single Responsibility Principle) オープンクローズド原則(OCP: Open-Closed Principle) リスコフの置換原則(LSP: Liskov Substitution Principle) 依存関係逆転の原則(DIP: Dependency Inversion Principle) インターフェース分離の原則(ISP: Interface Segregation Principle) 設計に関するいろいろな本がでているが、基本的にまずこれを守れてない上でそういうものを取り入れようとしても、かえってカオスになるケースのほうが多いのではないかなぁと個人的に感じている。まあ採用しているアーキテクチャなど状況によりけりでしょうけど。とはいえ、ソフトウェアのうまくいっている部分に無理やり、この 5 原則を適用しにかかるのはやめ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
SOLIDの原則ってどんなふうに使うの？
今あえてDRY原則に向き合う
Real World PlantUML
