履歴を持つデータの設計酔いどれ設計ナイト2019の発表資料です。
grpc-gatewayの開発に学ぶ、ソフトウェアの設計手法〜Yuguiが定めた、2つの基本設計方針 - エンジニアHub｜若手Webエンジニアのキャリアを考える！
grpc-gatewayの開発に学ぶ、ソフトウェアの設計手法～Yuguiが定めた、2つの基本設計方針 良いソフトウェアとはどのような方針のもとに設計されているのでしょうか。広く使われているOSSであるgrpc-gatewayの開発過程を作者のYuguiさんが振り返り、その設計手法を解説してもらいました。 こんにちは。 Yuguiと言います。 本記事では読者がより良いソフトウェア設計を行うための参考として、筆者が経験してきた設計上の決定をご紹介します。 筆者はこれまでRuby 1.9のリリースマネジメントを担当したり、Google Mapsの日本向け地理データ処理やgrpc-gatewayの開発などをしてきました。そしてこれらを通じて、広く長く使われて拡張されていくソフトウェアを設計するための方針決定に携わったり、方針に関わる良い議論を目にしたりする機会に恵まれてきました。中でも本記事では、
コンテナのデザインパターンを学べる論文「Design patterns for container-based distributed systems」を読んだ - kakakakakku blog
2016年に USENIX Conference で発表された論文「Design patterns for container-based distributed systems」を読んだ．タイトルの通り，コンテナのデザインパターンがまとまっていて，これからコンテナ設計をする人も，既にコンテナを運用している人も，デザインパターンを学べるのは価値があると思う．一部ミスリードをしているかもしれない． Design patterns for container-based distributed systems 論文も公開されている． https://static.googleusercontent.com/media/research.google.com/ja//pubs/archive/45406.pdf パターン一覧 Single-container management pattern
ユーザー基盤を作り直しながらRailsでのサービス層に向き合う - クックパッド開発者ブログ
こんにちは。パートナーアライアンス部の諸橋 (@moro) です。 突然ですが、わたしはいまクックパッドの「ユーザー基盤」を再構築しようとしています。 一口に「ユーザー基盤の再構築」といっても、そのゴールが何を指すかは(わたし自身にとってもまだ)漠然としており、固定されたゴールは見いだせていません。しかし後述するように、いくつかの問題は明確な形を取っています。言い換えると、それら明確な問題と向き合いながら『柔軟でいい感じのユーザー基盤を目指す』というのがこの再構築プロジェクトの目的です。 その第一歩目として、ユーザー登録部分を現状のクックパッド本体とは別の小さなRailsアプリケーションとして実装を進め、つい先日、一部の限定された利用者の方に向けて公開することができました。 今後も様子を見ながら公開範囲を拡大していく予定です。 再構築の背景 ではその「明確な問題」とはなんでしょうか。 最大
より良い相対日時表記についての考察
ニュース系ウェブサイトの記事リストやソーシャルメディアのフィードなどでは、各記事の公開日時を相対表記で表現することがあります。「5分前」「3時間前」「きのう」というように、記事の公開からどれだけ時間が経過しているかを表現する形式です。具体的には、JavaScriptで記事のタイムスタンプをユーザーの閲覧時の日時と比較し、相対表記に変換することになります。一方、「2018年10月1日」のような形式は絶対表記と呼ばれます。各記事の個別ページでは絶対表記が採用されることが多いようです。 もっとも単純な相対日時の実装は、60分前までは「m分前」、24時間前までは「h時間前」、そしてそれより前は「d日前」というように、時間の単位どおり機械的に処理したものです。しかし私たちの日時の捉え方はカレンダーや時計のとおりではなく、もっと感覚的なものです。日時の相対表記を導入する意義は、正確に何時間何分前の記事
Large Scale Payments Systems and Ruby on Rails
I’ve been writing code for fun and for work at both small startups and large companies for the past 30 years. Over the years I’ve become fascinated with the payments industry, and I have spent the past decade working in payments related companies. Before coming to work on Payments at Airbnb, I worked for PayPal, for a few startups and then was part of the NFC Wallet project at Google. The payments
Fastly 前提で設計したほうがいい理由
Ginza.rb 63th で「新規開発で Fastly を使おうと思っている場合、最後に Fastly を入れるのではなく、最初から Fastly 前提で設計したほうがいいですよ」という話をチラッとしたんだけど、終了間際で時間も残っていなくて言葉足らずになってしまったので文章化しました。最初から Fastly 前提で設計すべきと思う理由は以下の3点です。 (1) サイドバーなど、メインのコンテンツとライフサイクルが異なるコンポーネントは非同期にすべきだから (2) バックエンドのキャッシュ（例えば Rails の MemCacheStore など）はそもそも不要になる可能性があるから (3) アクセスランキングやアクセスカウンタを作る場合、発想を根本的に変える必要があるため サイドバーなど、メインのコンテンツとライフサイクルが異なるコンポーネントは非同期にすべきだから 例えばウェブメディ
esaのデザインの話 - 自分たちのWebサービスを作るデザイナーとしてやっていること / Design Talk of esa - Speaker Deck
ハッカーズチャンプルー2018でお話させていただきました http://hackers-champloo.org/2018/ https://esa.io/
Railsアプリケーションでフォームをオブジェクトにして育てる - クックパッド開発者ブログ
ユーザーエンゲージメント部の諸橋 id:moro です。 わたしはずっと、ユーザー登録やログイン周りという、サービス的には基盤的なところ、技術スタック的にはアプリケーション寄りのところに取り組んできました。関連する話を何度かこの開発者ブログにも書いています。 ユーザー基盤を作り直しながらRailsでのサービス層に向き合う 巨大なWEBアプリケーションに巨大な変更を取り入れるためにやったこと この記事で触れている「電話番号による登録」について、チームメンバーが別の側面を紹介してくれています。 今日はそのあたりの開発を通じて考えた、Railsアプリケーションでのフォームオブジェクトやサービス層といったものが何であるか、という問いに対する、現在の自分のスタンスを紹介します。 サービス層、サービスオブジェクト、フォームオブジェクト もともと Railsは Web 画面から DB 構造までをあえて密
ひどいダッシュボードの法則 | POSTD
白状しますが、私にはひどいダッシュボードを構築してきた責任があります。個人的に、この記事に書いた間違いのほとんどを犯してしまいました。ユーザに謝罪するとともに、同じ過ちを繰り返さないことを誓います。これらの過ちが悪い見本として、プロジェクトマネージャやデザイナ、エンジニアがひどいダッシュボードを構築したり確認したりする無駄な時間を少し減らすのに役立つことを願います。 法則1：ほとんどのソフトウェアのダッシュボードはひどい ひどいと言うのは このGoogle画像検索 のようなひどさ（まだ吐いていませんよね？）のことではありません。退屈で、設計が不十分で、有用性も一切ないという意味です。 信じられませんか？ では、今すぐ優れたダッシュボードのソフトウェア名を3つ挙げてみてください。 見つかりましたか？ ええ、そうだと思いました。しかし、ダッシュボードはどこにでもあります。あなたが使っているSa
人はなぜ「分かりやすいデザイン」でも失敗するのか｜Tsutomu Sogitani
これは私が最近よく訪問する日本橋駅直結の商業ビル、東京日本橋ビル内のエレベーターのボタンです。 唐突に質問ですが、このボタンで操作ミスを起こすポイントがあるとすれば、それがどこだか分かりますか？ 説明が必要と思いますが、このビルは7Fがオフィスロビーになっています。駅直結のB1と1Fからは7Fまで直通するシャトルエレベーターがあり、全員7Fで一度降り、セキュリティチェックをし、23Fより上にあるオフィスフロアに入ります。そのオフィスロビーとオフィスフロアを行き来するためのエレベーターのボタンがこれです。 ボタンが23Fから30Fまでしかなくて、下に大きく7Fのボタンがあるのは、そういったビルの構造からです。 私と同行したディレクター（26歳）は、打ち合わせが終わってオフィスフロアからオフィスロビーに帰る際に、操作ミスをしました。それも1度だけでありません。次の打ち合わせの帰りにもまったく同
「アイデア」の誤解｜松倉早星(Nue inc・Ku-ko inc代表)
僕はプランナーというお仕事をしていますが、かれこれ10年以上これだけをしています。簡単にいうと「アイデアをつくる人」なんですが、全体のディレクションから、新規性ありすぎるものは僕自身がプロデューサーとしての立ち回りを求められるので仕事の説明が難しい状態になっているのが現状。 ありがたいことに「アイデアの作り方」講座の依頼を受けてることもあり、その際は「作り方ではなく、見つけ方としてください」とお願いしています。こういった先生的な立場に立つと、世の中のアイデアを必要とされるポジションの人たちの苦悩が聞けて勉強になります。早々に気づいたのは多くの人がアイデアを誤解しているということでした。 今日はGWのアイデア修行の流れで少しでもアイデアの誤解を解きたいなという記事です。 ■目次 1.「アイデア」と「企画」の違い 2.特別な才能はいらない 3.面白くなくていい 4.アイデアよりも大切なこと「ア
ユーザ情報を保存する時のテーブル設計 - そーだいなるらくがき帳
はじめに ※この発言は個人の見解であり、所属する組織の公式見解ではありません 用法用量を守り、個人の責任で業務に投入してください 参考資料 2024/02/14追記 実際のテーブル設計の詳細はこちらを参考にどうぞ。 agilejourney.uzabase.com 要件 User情報を保存するときにどのようなテーブル設計を行うか 今北産業で頼む テーブルに状態を持たせず状態毎のテーブルを作る 状態が変わればレコードを消して別のtableに作る tableの普遍的な情報は別に持たせる 僕の考えた最強のDB設計 PostgreSQLをベースの雑なER図を作った。 これを元に話を進める。 table構成 users 親tableであり、すべてのユーザはここに属する。 基本はINSERTのみでUPDATE、DELETEを考慮しない。 user_detail userに付随する詳細の情報がここに登録
スプラトゥーン、みまもりSwitchなど任天堂のUI/UXデザイナーさんによる「“娯楽”を追求するUIデザイナーの仕事とは」 #uicrunch
リンク connpass UI Crunch #13 娯楽のUI - by Nintendo - (2018/04/27 19:00〜) ## “娯楽”を追求する、UIデザイナーの仕事とは 私たちは日々、実用品と娯楽品に囲まれて生活しています。どちらも生活に大切なもの。 今回は"もっと便利に"を追求するのではなく、"もっと楽しく"を追求する、UIデザイナー3名を任天堂からお迎えし、「Splatoon」 や「Nintendo みまもり Switch」 などの事例を交えながらお話いただきます。 子どもから大人まで楽しめる娯楽の裏側には、どのような想いや工夫があるのか。 みなさんと一緒に学べる機会になればと思います。 また、後 59 users 1621 UI Crunch @ui_crunch 「娯楽のUI」、開場しました！19:30より、任天堂さんのUI/UXデザイナーさんにご登壇いただきま
娯楽を超えたデザイン （UI Crunch #13 娯楽のUI イベントレポート）｜のっち Ryosuke Inoue
「UI Crunch #13 娯楽のUI - by Nintendo -」に参加しました。世界的にも注目される企業かつあまり表に出てこないデザイントークが聞けると言うことで、倍率も相当なものとなっておりました。この企画は構想から2年くらいかかったそうで、とても濃いお話を聞くことができました。めちゃ感動しました。今回は、そちらのイベントレポートです。最初の方あまり写真を撮らなかったので、後半の写真が多めになります。 1人目は、UI/UX デザイン チーフの正木さん。「娯楽UIの思考の原点」についてお話いただきました。 Nintendo流の「伝え方」Nintendoが人に何かを「伝える」時にこだわっていること。それは、以下の3つです。 ・「教える」ことよりも「体験する」ことで、より早く、的確に伝えることができる。 ・初めての体験は一度きり。新鮮な印象を大切にする。 ・体験はやっぱり面白くしよう
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
操作履歴/時点指定アクセスの実現 - BiTemporal Data Model の実践 / Implementing command history and temporal access
activerecord-bitemporal/README.md at master · kufu/activerecord-bitemporal
Swiftのエラーハンドリングはなぜ最先端なのか - Qiita
エンティティサービスは複雑さを高める
GoらしいAPIを求める旅路 (Go Conference 2018 Spring)
