タグ

設計に関するikosinのブックマーク (375)

  • iOSDC2017で「ディープリンクの設計と実装」について発表した - ninjinkun's diary

    9/15-17に開催されたiOSDC2017に参加し、9/16の1日目に「ディープリンクの設計と実装」というタイトルで発表を行った。一休レストランアプリのディープリンク対応を例にして、ユーザー体験から実装まで含めた話題を取り上げた。 Universal Linksの実装方法自体は既によく知られているので、自分の発表では実際にサービスに適用する際に困るポイントなど、できるだけ生々しい現場の話をするという方針で内容を組み立てた。スライドを見ていただければわかるが、自社アプリの宣伝も兼ねている。 また今回の発表後に、参加者からの投票で選ばれるベストスピーカー賞の2位を受賞した。発表で賞をいただくのは初めてのことで、とても嬉しい。「あるある」を詰め込んだのが良かったのかもしれない。 イベント中に各社のiOSエンジニアとディープリンク対応について話をしたが、皆共通して今のディープリンク体験はまだ微妙

    iOSDC2017で「ディープリンクの設計と実装」について発表した - ninjinkun's diary
  • Getter/Setterを避けて役に立つドメインオブジェクトを作る - かとじゅんの技術日誌

    Clean Architecture 達人に学ぶソフトウェアの構造と設計を読んでます。モデリングに関しては成分薄めですが、よいだと思います。はい。 Clean Architecture 達人に学ぶソフトウェアの構造と設計 作者: Robert C.Martin,角征典,高木正弘出版社/メーカー: KADOKAWA発売日: 2018/07/27メディア: 単行この商品を含むブログを見る 書の大筋から少し逸れるが、「5章 オブジェクト指向プログラミング」の「カプセル化」が面白かったので、これを切り口にモデリングについて考えてみる。 OO言語のカプセル化はすでに弱体化している オブジェクト指向の三大要素の一つである、カプセル化について、以下のようなことが書いてあります。 「カプセル化」がOOの定義の一部となっているのは、OO言語がデータと関数のカプセル化を簡単かつ効果的なものにしているから

    Getter/Setterを避けて役に立つドメインオブジェクトを作る - かとじゅんの技術日誌
  • Martin Fowler's Bliki (ja)

    ここは、Martin Fowler's Blikiの日語翻訳サイトです。Martin Fowler氏人の許可を得て公開しています。データはGitHubで管理していますので、どなたでも翻訳に参加することが可能です。 ※現在、移行中につき、Markdown形式になっていないものが多々あります……。PRいただけると大変ありがたいです。 API design / agile / agile adoption / agile history / application architecture / application integration / bad things / build scripting / certification / clean code / collaboration / computer history / conferences / continuous deliv

  • Patterns of Enterprise Application Architecture - Martin Fowler's Bliki (ja)

    Martin Fowler氏とAddison-Wesley Pub Coの許可を得て、パターンカタログの翻訳を行っています。 ※書籍の邦訳とは一切関係ありません。 PofEAAのパターンカタログから読始めるとよいでしょう。 パターンカタログの日語版 パターンカタログの英日対応表 上記のカタログでは書籍の訳語を踏襲していますが、各ページでは「できるだけ正しい」訳語を使うようにしています。邦訳版のパターン名に関する議論などは、JapanesePatternNamesを参照。 ページ一覧 アクティブレコード アプリケーションコントローラ 関連テーブルマッピング BBS パターンカタログ パターンカタログの比較表 パターンカタログ(日語) クラステーブル継承 クライアントセッションステート 粗粒度ロック 具象テーブル継承 データマッパー データ転送オブジェクト データベースセッションステート

  • 昨日のツイート群への個人的な回答 - lacolaco

    技術的に誤った認識でnot for meされるのは悲しいし寂しいので、誤った認識に反論しておきます。 React の過激派(高尚なコードを求める人々)と Vue の過激派(動けば良い人々)と Angular の過激派(オブジェクト指向信仰の人々)— ユーン🍆 (@euxn23) August 7, 2018 何を以ってオブジェクト指向とするかは人それぞれだけど、Angularはオブジェクト指向ではないと個人的には思ってる。 クラス使ってたらオブジェクト指向、というのであればそれは否定できない。 ちなみに過激というかアドバンスドな設計をすればするほどAngularもRxJSをベースにしたリアクティブプログラミングに寄っていく傾向にある。 AngularAngularFire(FirebaseのAngular向けライブラリ)を使って簡単なアプリケーションでも書いてみれば多少体感できると思う

    昨日のツイート群への個人的な回答 - lacolaco
    ikosin
    ikosin 2018/08/09
    初心者向け Angular 設計思想の紹介にいい記事だったので、別の形で再掲してほしい
  • 最高のITエンジニアリングを支える守りと攻めの「設計技術」と「SRE」 - Speaker Deck

    最高のITエンジニアリングとは、ユーザーへの価値提供に最大限集中できる状態を維持し続ける技術だと私は考えます。では、その状態を阻害する要因は一体何であり、どうすれば取り除くことができるのでしょうか。このような具体的な問題と向き合い、近年注目されているSRE の考え方を取り入れ、実装しながら乗り越えてきた体験談についてお話します。(HashiCorp ツールの実装、運用自動化など)また、一歩進んだITエンジニアになるため、実装に留まらない組織的な施策実行の考え方や実際の進め方についてもお伝えします。July Tech Festa 2018 での発表資料です。

    最高のITエンジニアリングを支える守りと攻めの「設計技術」と「SRE」 - Speaker Deck
  • データベーステーブル設計の基礎の基礎〜エンティティの抽出・定義から正規化まで - エンジニアHub|若手Webエンジニアのキャリアを考える!

    データベーステーブル設計の基礎の基礎~エンティティの抽出・定義から正規化まで 適切な形でデータベースのテーブルを設計し、運用するには?テーブル設計に必要な初歩を日MySQLユーザ会副代表の坂井恵さんが丁寧に解説します。 金融系アプリ、ゲーム人工知能などなど……。どんな種類のシステムを開発する上でも、避けて通れない領域があります。データベースです。データを適切な形式で格納し、取り出す。単純明快ながらも奥深いこの仕組みは、多くのシステムの根幹を支えています。 しかし、適切な形でデータベースのテーブルを設計し、運用するのは簡単なことではありません。「良いテーブル設計」のためには知識と経験が不可欠です。今回は日MySQLユーザ会の副代表である坂井恵さんに、これからテーブル設計に着手する方に向け、設計に必要な技術と、良い設計を作るための考え方を教えていただきました。 坂井恵(さかい・けい) @

    データベーステーブル設計の基礎の基礎〜エンティティの抽出・定義から正規化まで - エンジニアHub|若手Webエンジニアのキャリアを考える!
  • マルチテナント・ウェブアプリケーションの実践

    Kibelaのマルチテンシーを解説します。 #railsdm 2017 の資料です。

    マルチテナント・ウェブアプリケーションの実践
  • ざっくり理解するPaxos - 小野マトペの納豆ペペロンチーノ日記

    ゴールデンウィーク中、Appleがオープンソースとしてリリースした分散データベース FoundationDB のドキュメントを読んでいました。なかなか面白いデータベースだと思うのでこれについては別途書きたいですが、それはそれとしてFoundationDBでは、分散環境下でACIDトランザクションを実現するために、分散合意プロトコルとして有名なPaxosを採用しているようでした。 PaxosはGoogleのChubbyやCassandraのLight Weight Transactionなどで使われていますが、僕はいまだにPaxosがどのように動作するのかあまりよく分かっていませんでした。良い機会だと思い、FoundationDB技術を理解するためにも連休の後半でLeslie LamportによるPaxosの論文の一つ Paxos Made Simple を読み、何となくわかった気持ちにな

    ざっくり理解するPaxos - 小野マトペの納豆ペペロンチーノ日記
  • ユーザ情報を保存する時のテーブル設計 - そーだいなるらくがき帳

    はじめに ※この発言は個人の見解であり、所属する組織の公式見解ではありません 用法用量を守り、個人の責任で業務に投入してください 参考資料 2024/02/14追記 実際のテーブル設計の詳細はこちらを参考にどうぞ。 agilejourney.uzabase.com 要件 User情報を保存するときにどのようなテーブル設計を行うか 今北産業で頼む テーブルに状態を持たせず状態毎のテーブルを作る 状態が変わればレコードを消して別のtableに作る tableの普遍的な情報は別に持たせる 僕の考えた最強のDB設計 PostgreSQLをベースの雑なER図を作った。 これを元に話を進める。 table構成 users 親tableであり、すべてのユーザはここに属する。 基はINSERTのみでUPDATE、DELETEを考慮しない。 user_detail userに付随する詳細の情報がここに登録

    ユーザ情報を保存する時のテーブル設計 - そーだいなるらくがき帳
  • 「悪い方が良い」原則と僕の体験談|Rui Ueyama

    ソフトウェアの世界には「悪い方が良い」原則という有名なエッセイがある。キレイにレイヤ分けされた一貫性のある良いデザインよりも、一見手抜きっぽい悪いデザインのほうが実は良いときもあるという話だ。この逆説的なデザイン原則を僕は身をもって体験したことがある。それについてちょっと書いてみようと思う。 僕はlldというリンカの現行バージョンのオリジナル作者だ。リンカというのはコンパイラと組み合わせて使うもので、実行ファイルやDLLを作るのに使用される。lldはプロダクトとしてはかなり成功していて、標準のシステムリンカとして採用しているOSがいくつかあったり、GoogleやFacebookなど皆が知っているような大規模サイトの中で広く使われていたりする。 現在のlldは2世代目で、第1世代のlldは僕がプロジェクトに参加する前から存在していたのだけど、数年前にそれを捨てて一から書き直すということになっ

    「悪い方が良い」原則と僕の体験談|Rui Ueyama
  • Worse Is Better

    Worse Is Better(悪いほうが良い) Richard P. Gabriel (Original article: Worse Is Better. Japanese translation by Hisashi Morita.) "worse is better"として知られる考え方では、ソフトウェアを作る際には(おそらく他の分野でも同様に)最小限のものをまず作り、そして必要に応じて育てるほうがよいとされる。Christopher Alexander*なら"piecemeal growth"(一口分ずつの成長)と呼んだかもしれない。その考えがどのように進化したかを話そう。 1984から1994まで、私は"Lucid, Inc."というLispを生業とする会社を所有していた。1989の時点で、Lispビジネスが好調ではないことは明らかだった。ひとつにはAIを生業とする会社が泥沼に

  • 【それでもCSSは破綻する】 CSSの設計手法と書き方を考える - Qiita

    Register as a new user and use Qiita more conveniently You get articles that match your needsYou can efficiently read back useful informationWhat you can do with signing up

    【それでもCSSは破綻する】 CSSの設計手法と書き方を考える - Qiita
  • タベリー | とある仕様書 – Yamotty – Medium

    グループ共有機能仕様書の公開に踏み切ったのは、10Xのプロダクトがどうやって作られているか、について部分的に触れてもらえると思ったから。 10Xでは「細かな実装・デザインの白兵戦」・「認知と理解を獲得していく空中戦」を一緒に戦えるプロダクト・マネージャーを育てていきたいと思っているので、この仕様書を読んで「10Xで力を試してみたい!」という方はぜひ以下のフォームから応募してほしい。ユーザーの感情を科学できる人が10XのPMにはフィットすると思う。 仕様書の前提となる考え仕様書は「チームのワーキングスタイル」によってその役割をかえるものだ。今の10Xは「ユーザーの前に積まれた膨大な課題の山に優先度を付け、とにかく早くプロダクトをプッシュしていくこと」が最優先のチーム。 そのため、「膝を突き合わせて瞬発力の高いコミュニケーション」を重視している。リモートはしない。 この環境では議論のすべてが口

    タベリー | とある仕様書 – Yamotty – Medium
  • Custom Overlays with Angular's CDK

    You have probably heared of Angular Material haven’t you? If you haven’t, it’s a library that provides you with high-quality Material Design components for Angular. Material Design itself is a visual design language that aims for consistency of user experience across all platforms and device sizes. That’s cool but what if your company has its own opinions about styles and the overall look and feel

    Custom Overlays with Angular's CDK
  • How Reddit ranking algorithms work

    This is a follow up post to How Hacker News ranking algorithm works. This time around I will examine how Reddit’s story and comment rankings work. The first part of this post will focus on how are Reddit stories ranked? The second part of this post will focus on comment ranking, which does not use the same ranking as stories (unlike Hacker News). Reddit’s comment ranking algorithm is quite interes

    How Reddit ranking algorithms work
  • ランキング設計はどうあるべきか? その2|深津 貴之 (fladdict)|note

    前エントリで論じられた、正しいランキング設計の考察の続き。第2回は、ランキングの収奪性、格差の固定性を軽減する手段を、具体的に論じてみる。 前回の記事へのTwitter上のフィードバックは、Togetterにまとめてある。こちらもご興味があれば、一読の価値がある。いくつか被ってしまったものもあるけれど、諸々の後半記事。 「ランキング」以外の名称を用いるこれはほぼ確定。ランキングという名前は、「noteとして競争原理を推奨する」という強いメッセージを発する。noteの全てのユーザーが、競争原理で動いているわけではないので、これは望ましくない。 おそらく最終的には「注目」「人気」などの名称を使うことになるかと思われる(「オススメ」はパーソナライズ用にとっておく)。また、「ランキング」という名称やスタンスをやめることで、後述するようないくつかの公平性のための施策を行う余地が生まれる。 時間による

    ランキング設計はどうあるべきか? その2|深津 貴之 (fladdict)|note
  • Data Models

    Data Models: A Comprehensive Guide to Structuring Information for Optimal Insights and Decision-Making In the realm of data management, the use of effective data models plays a pivotal role in organizing and representing information in a structured and meaningful way. Data models serve as the blueprint for databases, facilitating efficient data storage, retrieval, and analysis. This article delves

    Data Models
  • Webアプリケーションフレームワーク導入時に考慮すべき22の観点 - Qiita

    記事では、 チームによる持続的に変更可能なWebアプリケーションの開発を目標に、フレームワーク導入時に考慮すべき22の観点を紹介する。 フレームワークによって特徴は異なるが、番導入にあたって、考慮すべきポイントはあまり変わらないので、極力フレームワーク1に依存しすぎないよう配慮する。また、話をシンプルにするため、REST APIを提供するアプリケーションを題材とする。 前提 ソフトウェアのエントロピー ソフトウェアがエントロピー増大の法則を避けられないことを、体感している開発者は多いだろう2。普通にアプリケーション開発を続けると、開発スピードは鈍化し、品質は低下してバグが増え、開発者からは技術的負債への怨嗟の声が聞かれるようになる。エントロピー増大というフォースは極めて強力で、意思を持って立ち向かわなければ、容易にダークサイドに堕ちてしまう。 関心事の分離 大規模Webアプリケーション

    Webアプリケーションフレームワーク導入時に考慮すべき22の観点 - Qiita
  • ID生成大全 - Qiita

    セッションIDやアクセストークン、はたまた業務上で使う一意の識別子など、いろんなところで一意のIDを生成しなきゃいけないケースが存在します。 そこで世間で使われているIDの生成方法について調べてみました。 選択基準 ID生成における要求として、以下の観点が上げられるかと思います。 生成の速度 大量にデータを短期間で処理し、それらにIDを付与する場合、ID生成そのものがボトルネックとなることがあります。 推測困難性 IDを機密情報と結びつける場合、IDを改ざんされても、機密データが見れないようにできている必要があります。 順序性 採番した順にデータをソートする必要がある場合は、IDがソートキーとして使えないといけません。 それぞれについて各生成手段を評価します。 ID生成の手段 データベースの採番テーブル 採番用のテーブルを作り、そこで番号をUPDATEしながら取得していくやりかたです。古い

    ID生成大全 - Qiita