Railsで考えるドメイン駆動設計のコアドメイン銀座Rails#26の登壇資料です https://ginza-rails.connpass.com/event/189892/
アプリケーションにおける権限設計の課題 - kenfdev’s blog
日々権限設計で頭を抱えてます。この苦悩が終わることは無いと思ってますが、新しい課題にぶつかっていくうちに最初のころの課題を忘れていきそうなので、現時点での自分の中でぐちゃぐちゃになっている情報をまとめようと思い、記事にしました。 所々で「メリット」「デメリット」に関連する情報がありますが、そのときそのときには色々と感じることがあっても、いざ記事にまとめるときに思い出せないものが多々ありました。フィードバックや自分の経験を思い出しながら随時更新する予定です。 TL;DR（長すぎて読みたくない） 想定する読者や前提知識 この記事での権限とは 権限の種類 ACL(Access Control List) RBAC(Role-Based Access Control) ABAC(Attribute-Based Access Control) どの権限モデルを採用するべきか 権限を適用する場面 機能
図解 システム化とアドリブのよい使い分けとは？｜深津 貴之 (fladdict)
世の中をみると、官僚的なシステム化と現場主導のアドリブ、二つの世界観に二分されがちです。本当は両者の中間がベストなのに、どうしても片側に寄ってしまうようです。 偏る原因は、おそらく両方が得意な人が少ないため。 このためシステムとアドリブの住み分け、バランスの取り方を人に説明するのは難しいものです。僕も長く悩んでいましたが、最近、ようやく頭の中でメンタルモデル化できました。 岩として考えるシステムとアドリブの特性は、以下のようにモデル化できます。システムは大きな岩。アドリブは多くの小石。 システム化：単一の大きな岩 アドリブ化：大量の小石 システムの考え方平地にドンと置かれた大岩が安定するように、システム化は地盤がしっかりした環境で力を発揮します。また大きな問題をざっくり埋めるような、手っ取り早く80点をとるような場合にも便利です。 一方、大岩を坂道のような不安定な足場に置くと、とても危険で
初めてWeb API設計をする前に読みたい記事・本・API実例と個人的にハマったこと - 仮想サーファーの日常
働いている会社で「サービス全体のサーバーサイドの処理をAPIに置きかえよう！」というプロジェクトにアサインされて、初めてAPIをゼロから設計する仕事をすることになって早1ヶ月。初めてだらけで何度も悩みながらAPI設計をし続けていますが、1ヶ月前に比べてだいぶいろんな記事や本にお世話になってきたので、個人的に参考になったなあと思うものたちをまとめておきます。 あと、API設計を進めていく上で個人的にハマったことも書いておきます。後世のAPI設計者が同じような疑問にぶつかった時にハマらないことを願います。（自分の記憶力が🐔レベルなので、メモの意味でもまとめておきます。） API設計する上で参考になった記事 まずは、初心者の段階で読んでおきたい記事たち。まずはAPI設計はどのように進めていくべきか、どのようなところでハマりやすいのかを知るために記事を読んで大枠を掴むと良いかと思います。 Web
リファクタリング専門チームによるお金周りリファクタリング - クラウドワークス エンジニアブログ
こんにちは、エンジニアの @MinoDriven です。 今年2019年4月にリファクタリング専門チームを発足しました。 crowdworks.jp の最重要機能であるお金周りの機能に関して、どのような技術アプローチでリファクタしているかを紹介致します。特に、Railsには適用困難と言われているドメイン駆動設計の考え方を取り入れた手法を解説致します。 目次 背景 リファクタリング専門チーム発足 技術的負債 リファクタリング対象選定 方針①：パレートの法則（80:20の法則） 方針②：リファクタリング選定基準3軸 「仕事周り」か「お金周り」か お金周りモデルのリファクタリングを妨げるConcern 課題①：ActiveRecord側の構造に依存したコード 課題②：型や構造のチェック(リスコフの置換原則違反) 課題③：重要業務概念の埋没 どのようにリファクタしたか 手法①：Concern側メソ
クラウドワークスのユーザーインタビュー設計手順を大公開！ - CrowdWorks Designer Blog | クラウドワークス デザイナーブログ
こんにちは！UXデザイナーの小阪（@yuta3594）です。 3月22日のサッカー日本代表vsコロンビア代表@日産スタジアムのチケットを取ることができました。 何気に代表戦をスタジアムで観るのは初めてで、今からとても楽しみです！ 初めてだと何かとわからないことがありますよね。応援歌とか覚えておかないと…？ 初めてでわからないと言えば、「ユーザーインタビューを始めたいけど、どうしたら良いかわからない…」という方もいらっしゃるのではないでしょうか。 ユーザーインタビューを始める前に、弊社では設計書を作成します。 設計手順はテンプレートとしてまとめられており、毎回そのテンプレートを使って新しい設計書を作成し、ユーザーインタビューをおこなっています。 本日は、そのユーザーインタビュー設計手順を大公開いたします！ なお、大前提として、弊社は人間中心設計の考え方に沿ってUXデザインをしています。 ユー
ズバリ！ 必要なサンプルサイズはいくつ？ A/Bテストのための例数設計入門 - 廿TT
こういう状況を考える 広告 A と広告 B で CVR（コンバージョンレート）に差があるかテストしたい。しかも仮説検定をやりたい。 A/Bテストに長い時間をかけるのは無駄だからやめたい（リスティング広告でやってはいけない8つの施策 | スポンサードサーチ再入門 | Web担当者Forum） 一方で一定のクリック数がなくては判断できない（Sexyなリスティング広告プレイヤーになるために…、スライドを公開します。 | SEM-LABO） では、結局一定のクリック数っていくつあればいいの？ R で計算してみる。 用意するもの： 有意水準（α） 検出力（1-β） 広告 A の経験的 CVR 広告 B の期待される CVR ↑これらについては後で説明する。 CVR は CTR（クリック率）と読み替えてもらってもかまわない。なにかをなにかで割った「割合」なら同じように考えて問題ない。 広告 A という
タベリー | とある仕様書 – Yamotty – Medium
グループ共有機能仕様書の公開に踏み切ったのは、10Xのプロダクトがどうやって作られているか、について部分的に触れてもらえると思ったから。 10Xでは「細かな実装・デザインの白兵戦」・「認知と理解を獲得していく空中戦」を一緒に戦えるプロダクト・マネージャーを育てていきたいと思っているので、この仕様書を読んで「10Xで力を試してみたい！」という方はぜひ以下のフォームから応募してほしい。ユーザーの感情を科学できる人が10XのPMにはフィットすると思う。 仕様書の前提となる考え仕様書は「チームのワーキングスタイル」によってその役割をかえるものだ。今の10Xは「ユーザーの前に積まれた膨大な課題の山に優先度を付け、とにかく早くプロダクトをプッシュしていくこと」が最優先のチーム。 そのため、「膝を突き合わせて瞬発力の高いコミュニケーション」を重視している。リモートはしない。 この環境では議論のすべてが口
ランキングの設計はどうあるべきか？｜深津 貴之 (fladdict)
「発見性」の強化のために、noteにランキングやホットエントリーに類するものをつけたいと思っている。しかしランキングやホットエントリーは、世間で思われている以上にデリケートなUIであるため、その設計は慎重に行われなければならない。下手な設計は、サービスのカルチャーそのものを破壊しかねないためである。 以下は、ランキング設計のための忘備録。 PVランキングは収奪的な設計であるPVランキングを設計する場合、まず最初に意識すべきことがある。それは本質的に、PVランキングは収奪的な構造であることだ。 「収奪的」とは、勝者が全てを独占してしまうことを意味する。 基本的にランキングに上位のコンテンツは、ユーザーの注目を獲得する。つまり、PVのあるコンテンツはランキング上位となる。そして上位コンテンツはその露出によって、さらにPVを集めてしまう。 結果、PVランキングは少数のコンテンツにPV、フォロワー
目指したのは「全ユーザーを全力で信じるサービス」 性善説から生まれたCASH、その結果は？
「究極的にはすべていい人！」を前提に作ったCASH 岩本有平氏（以下、岩本）：定量的な話は聞けなさそうなので（笑）。できれば定性的なお話だけでもうかがえないかなと思います。 光本勇介氏（以下、光本）：はい、定性……。 岩本：例えば、リピートするユーザーさんはいるのか、属性としてどういう方が多いのか。たしか最初は、ブランド品とか、わりと商品のカテゴリーを絞られていて、しかも認識も少し緩かったという話だったり。ただ性善説にもとづいて、みなさんちゃんと商品を送っていた。その辺での気付きなどあれば、教えていただけないですか？ 光本：はい。うーん、気付き。 私がすごく興味があったのは、世の中のあらゆるインターネットのサービス、その多くって、悪い人がいるのが前提で設計されていることが多いんです。それって、しょうがないと思うんです。サービスを安全にちゃんと運営していかなきゃいけないから。悪い人がいること
5分で絶対に分かるAPI設計の考え方とポイント
API設計を学ぶべき背景と前提知識、外部APIと内部API、エンドポイント、レスポンスデータの設計やHTTPリクエストを送る際のポイントについて解説する。おまけでAPIドキュメント作成ツール4選も。 【0分】API設計を学ぶべき背景 APIの公開が増えている 最近、自社で保有するデータや、システム、アプリケーション、Webサービスの機能を「API（Application Programming Interface）」として公開する企業が、増えてきています。これに伴い、「API経済圏（APIエコノミー）」という新たなビジネスモデルが確立されつつあります（参考：5分で絶対に分かるAPIマネジメント、API経済圏）。 「ProgrammableWeb」というAPIに関するニュースサイトや、さまざまな企業が提供するAPIのリンクがまとまったサイトもあり、APIの普及はものすごいスピードで進んでいる
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
なんたって”DevQA” アジャイル開発とQAの合体が改善を生む - 永田 敦 氏 #postudy
growiz.us