中長期のための大きなデザインも大事だけど、そのために日々の改修が犠牲になってはならない（その逆は言語道断）。そんなわけで、しばらくの間は、1〜2日で終わる小さな改修を、コンスタントにnoteチームに提案したいなぁと考えている。 もちろん、「リソースが許せば」だけれども。なぜならpiece of cakeにはまだデザイナーが1人しかいないことだ。そんなわけで、中長期でどういうチームを作るべきかウンウン唸っている。 並行して走るスロットが3-4つ欲しい理想を言えば、デザイン/開発リソースを3つのグループにわけたい。「大局リソース」、「開発リソース」、「カイゼンリソース」の3つだ。これらはそれぞれ独立しているのが望ましい。複数のレイヤーを1人のスタッフが兼任していると、どれかが忙しくなると、他の全てがストップしてしまうからだ。 大局リソース ガイドライン、コンポーネントなど、会社全体にストックさ
いまとあるアプリケーションの Web API を設計しているのだが、思った以上にいろいろたいへん。 当たり前だが、APIをただ使うのに比べると10倍以上考えなければならないことがある。 そこである勉強会で教えてもらったのは、「Github API を真似すればいいんじゃね？」という話。調べてみると、すごくシンプルで使いやすい印象。リンクがふんだんにつかわれていて、ハイパーメディアっぽいし。 GitHub API v3 GitHub API が数ある Web API のなかでどのようなポジションにあるのかは寡聞にして知らない。だけど、かなりイケテル部類なのではないか？なにせ、天下の GitHub である。世界のあらゆる優秀なITエンジニアたちの目に毎日触れているのである。おかしな設計の API なんて怖くて晒せないはずだ。ということは、GitHub API をパクって参考にして、Web AP
ちょっと前にTwitterでAPIのバージョニングをどうやるかみたいな話をしていたのですが、そのへんもやもやしているので少し整理しておきたいなと。 APIのURLを/api/v1/*とかってやるの、やめたほうがいいとおもうんだけどなぁ。いざv2を作るとなったときに、大量のコピペが発生して後悔するよ、って伝えたい。— Kenn Ejima (@kenn) February 28, 2014 さて、これについて色々と異論・反論も含めた意見が出たのですが、まずは、大昔にURL方式（＝コントローラ分割）でやってきて後悔したぼくが、（5年ぐらい前から）現在はどうやってAPIのバージョンを管理しているか？について紹介します。 基本原理としては、コピペが多発する根っこで分岐（＝コントローラ分割）じゃなくて、必要最小限のところで限局的に分岐するのがいい、という考え方に基づきます。 一言でいうと、「パラメー
As I discussed in my recent blog post on ProgrammableWeb.com, Netflix has found substantial limitations in the traditional one-size-fits-all (OSFA) REST API approach. As a result, we have moved to a new, fully customizable API. The basis for our decision is that Netflix’s streaming service is available on more than 800 different device types, almost all of which receive their content from our priv
OSFA == one-size-fits-all 単一の API で全てをカバーするのをやめたらどうか、ということ。 APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sight @kenn 最近はRESTfulなエンドポイントは完全に後方互換なまま、クライアントごとにオーケストレーション層(radical versionin)を設けるという方向にシフトしようとしている。詳しくは http://t.co/zODm7mFr5B— Tatsuhiko Miyagawa (@miyagawa) February 28, 2014 この話のポイントとはちょっとずれてる && Podcast 聴いてないのですが。 Quipper プラットフォームで内部的に利用されている API も、 /v1 というパスの下にはえててごく一部のエンドポイントだけ /v2 がある、み
2016/10/12 社内勉強会で使ったスライドを社外向けに一部加筆訂正したもの
この記事は 2016年 第2のドワンゴアドベントカレンダー、20日目の記事です。 qiita.com ドメイン駆動設計に関して悩める若者に送るポエムを書いていたら長くなりました。 20日目なはずなのに今日は 12/25 ですが、お察しください。 TL;DR ドメイン駆動設計には3つの顏がある それは「哲学」「戦略」「戦術」である 「戦術」にスポットがあたりがちだが、まず「哲学」とコアの「戦略」から理解する プロダクトにおけるドメインモデルの全体像を描いてから「戦術」を検討しよう ドメイン駆動設計をどの程度取り入れるかの 「ドメイン駆動設計の適用レベル」について はじめに ドメイン駆動設計(DDD)、以前と比較して認知が上がってきたのか、よく「DDD やってるんですか?」 「DDD ってどうはじめればいいんですか?」と聞かれることがあります。そしてこの時にまず話に上がるのが、エンティティ、集
こんにちは。技術部 開発基盤グループの諸橋です。 クックパッドでは昨今の多くのWeb企業と同じように、GitHub EnterpriseのPull Requestを使ったコードレビューを広範に実施しています。わたしたちのコードレビューでは、ソースコードの字面にとどまらず、サービスの機能として魅力的かどうかや、保守性を含めた設計が適切かといった議論に発展することも良くあります。 きょうはそんななかで話題に上がった「現在時刻」の扱いかたに関する設計の話を書きます。 背景 サービスを開発・運営している我々には、時間帯によって出し分けたり、特定の期間のみに表示したいコンテンツがたくさんあります。 そのたびにデプロイし直すというのはつらいので(特に24:00に出なくなるコンテンツなど)なんとかしたくなりますが、一方で時限式のコンテンツはその時になるまでちゃんと動いているか確証が取れないので怖いです。
autoscale: true theme: Plain Jane,5 複雑なJavaScriptアプリケーションを考えながら作る話 自己紹介 Name : azu Twitter : @azu_re Website: Web scratch, JSer.info #jsprimerを書いています JavaScript入門書に興味ある人はウォッチ :star: :warning: 注意 :warning: 作成するアプリケーションによって必要な構造は異なります 今回の話はある程度の規模で複雑性を持つクライアントサイド ライブラリ抜きで数万LOC >= 長期的にメンテンナンスや変更が発生するアプリケーション サーバサイドレンダリングはしないクライアントアプリケーション 3行でOK 複雑なJavaScriptアプリケーションを作るにあたりドメインモデルをどう実装するか悩んだ 色々と試行錯誤した
さて、日本でもとうとう「ポケモンGO」がローンチされました。皆さんも恐らくご存知の通り、一足先にリリースされたアメリカではもはや社会現象になっています。ローンチからたった一週間ですでにモバイルゲーム歴代最高のユーザー数を獲得し（！）、アクティブユーザー数ではTwitterを追い越しました。僕が住む比較的郊外でさえ、道を歩けばポケモンGOをプレイしている人と何度もすれ違います。アメリカに住んで12年、こんなことは初めてです。とにかく話題で持ちきりのポケモンGO、このゲームを任天堂と共同で開発している会社がサンフランシスコにあるNiantic, Inc.です。 Niantic, Inc.は元々Googleの社内スタートアップとして始まり、これまでにIngressというモバイルゲームを開発してきました。Ingressのゲームコンセプトは陣取りゲーム。ゲームフィールドは私たちが住む現実の世界そのも
今回のソリューション：【GitHub、Trello、Sketch、Flinto・他】 〜「デザイナーがプロダクトマネジャー」という意識を大切にする、トレタのデザインプロセスの全貌を公開〜 事業開発において、デザイナーと、デザインそのものが成すべき役割とは何か。それぞれの企業が「デザイン」をどう捉えているかは、そのデザイン・開発プロセスを知ることで明らかになる。 飲食店向け予約・顧客台帳サービス「トレタ」を運営する、株式会社トレタ。同社では、デザイナーをプロダクトマネージャーのような立ち位置に置き、「課題解決の設計」が役割であると定義している。 デザイナーが要件定義の段階から仮説検証、フィードバックに関わることで、プロダクトをより良くすることを目指しているのだ。 デザイナー出身者がプロダクトマネージャーの役割を担うようになっていくのは、ひとつの自然な流れだと話す、同社でCCO（最高クリエイテ
以前の記事を補足、あるいは主張を一部修正するものです。 〜・〜 サブジェクト指向とは？ ある要求仕様のセットがあったとき、そこに仕様変更のライフサイクルに違いのあるサブセットが認められるならば、それらは、同一のデータ資源（＝オブジェクト）に関わることであっても、別々の“モデル”として捉えよう、というのがサブジェクト指向の一つの意図です。例えば、「受注」という同じデータ（≒管理対象）に関わることでも、「注文受付オペレーター」観点の“モデル”と「販売管理担当」観点の“モデル”とでは、要求仕様のセットが異なるし、その後の仕様変更の発生タイミングや頻度も異なるでしょう。そういった状況においては、「受注」サブドメインに関わる全ての要求を一つの集約やエンティティに全て載せてしまうと、いわゆるファット・モデルとなり、当初段階はなんとかやり遂げたとしても、その後の仕様変更の度に、当初開発段階に近い苦労を都
みなさん、こんにちは。グリーのかとじゅん(@j5ik2o)です。 このエントリは GREE Advent Calendar 2013 の 18日目の記事です。よろしくお願いします。 私がグリーに入社してやっていることは、プログラミング言語 Scalaとドメイン駆動設計(以下、DDD)の布教活動です。布教活動といっても宣伝するだけでは具体性に欠けるので、実際に開発チームに入ってScalaやDDDの技術支援を行っています。本エントリでは、Scalaを用いたDDDの設計と実装をどのように行っているかを、DDDを知らない人でもできるだけわかりやすく説明したいと思います(Scalaわかっていると読みやすいですが、あんまり複雑なコードは出てこないのでなんとなく読めるのではないかと思います)。なお、DDDの実践例は他にもあります。一例だと思って読んでいただければ幸いです(先日のSNSチームでのドメイン駆
まったく個人的なモチベーションの問題から、前回の最終更新から2年以上が経過してしまい、多くの読者のみなさんにはご心配をおかけいたしました。「プログラミングに関して調べたことや日々感じたことをメモとして残していきたいと思います。」というもともとの原点に立ち返って、あまり気負わずに、また今後も時々更新していけたらと思います。今までこのブログの主なテーマとして、JavaEEやSpringといったような、いわゆる業務開発で使われるような技術を中心としてきたわけですが、最近Springを使ったJavaの開発に（アーキテクトではなく）プログラマーとしてちょっと参加する機会があったので、その時気づいたこと、感じたことを書いてみたいと思います。 さて、皆さんはアーキテクチャやアーキテクトという言葉に対してはどのようなものをイメージするでしょうか。システムのセキュリティを確保するための方式であったり、大量の
3. ドメイン駆動設計への道 設計の改善 ドメインの理解 ・メソッドの構成 オブジェクト指向 ・オブジェクト間の特性移動 設計のスタイル 言葉の力 基礎訓練 ・データの再編成 モデル駆動 ・条件記述の単純化 責任駆動設計 エクササイズ ・メソッド呼び出しの単純化 役割ステレオタイプ ９つのルール 小さく作る 責任割当の原則 GRASP For 実装の原則 Thoughtful Developer ・クラス Leading Designer ・振る舞いとメソッド ・状態とコレクション 契約による設計 4. ドメイン駆動設計への道 シンプルな ﾄﾗﾝｻﾞｸｼｮﾝｽｸﾘﾌﾟﾄ リッチな 大きな ﾄﾗﾝｻﾞｸｼｮﾝ 泥団子 ｽｸﾘﾌﾟﾄ リッチな シンプルな ドメインモデル ドメインモデル アーキテクチャなし 汎用データ型 テーブルと対応した 業務の言葉で組み立てる 汎用命名ルール ドメインオブジ
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? これは Enchant の開発者である Vinay Sahni さんが書いた記事「Best Practices for Designing a Pragmatic RESTful API」1を、ご本人の許可を得て翻訳したものです。 RESTful な WebAPI を設計しようとすると、細かなところで長考したり議論したりすると思います。また、他の API に倣ってやってはみたものの、本当にそれでいいのか、どうしてそうしているのか分からない、何てことも少なくはないと思います。 この記事では、そのようなハマリどころについて Vinay さん
私たちの救世主DHH™は最近の Full Stack Radioのインタビュー で、 Basecamp の最新版で彼がどのようにRailsのコントローラを書いたかを説明しています。下記は、彼のすばらしい話を書き取ったものです。 これまでに思うようになってきたのは、「RESTの原則に従うには、どのタイミングで新たなコントローラを作るべきかを一度決めたら、ほぼ異例なくその原則を遵守するべきだ」ということです。いつだってその方がうまくいくんです。自分の作ったコントローラの状態を悔やむのは決まって、作ったコントローラの数が少なすぎた時です。多くの処理を任せようとしすぎてしまうんです。 そこでBasecamp 3では、ある程度理にかなったサブリソースがあれば、毎回コントローラを分割していきます。フィルタなどの場合ですね。例えば画面があって、それがある状態になっているとします。もしこれにいくつかのフィ
※「Sketch」はMac専用アプリです。Windows版はありません。 __「演習ファイル＋動画＋演習付き」__で記事を書いてます。 エンジニアの人から「Sketch使ってみたい」「日本語の記事が少ない」という声を聞いて、最近社内で勉強会しました。 Sketchについて日本語の記事を調べてみたところ、このレベルの記事はけっこうありました。 ただ、学びやすいか？といえばそうではないらしいので、少し工夫して学びやすいように書いてみました。 __ハンズオン用__などにご利用ください。 #Sketchとは Sketchについて一応さらっと書いておきます。 ・アプリやWebのデザイン・UI設計などに使われるMac用アプリケーション IllustratorやFireworksのようなツールです。 ・$99 買いきり(2016/02 現在） 有料です。 ちなみにApp Storeでは買えなくなりました
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
