タグ

qiitaと設計に関するmsakamoto-sfのブックマーク (9)

  • Webシステムにおいて「画像や帳票等のファイルはDBへ格納すべきなの?」を調べてみた(ファントムファイル) - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事は、 JPOUG Advent Calendar 2023 24日目の記事です。 23日目は multilayer さんの記事『OCIのLanding Zoneについて調べてみた!』でした。 想定読者 ファントムファイルについてよく知らない、帳票の扱い方をあまり考えたことがない人 イントロダクション 皆さん、世の中のWebシステムで利用される画像や帳票ファイルがどこに保存されているかご存知でしょうか? 帳票や大きな画像ファイルなどを扱う際、大きく分けて2つの設計方針があります。 ・DBに直接保存する ・DB外部に保存し、パスなど

    Webシステムにおいて「画像や帳票等のファイルはDBへ格納すべきなの?」を調べてみた(ファントムファイル) - Qiita
  • 設計を歪める認知バイアス - Qiita

    こんにちは、リファクタリングが大好きなミノ駆動です。 この記事は READYFORアドベントカレンダー2021 、5日目の記事です。 これはなに? ソフトウェア開発において、設計をないがしろにすると、低凝集密結合な構造に陥り、変更容易性が低下してしまいます。 設計スキルを高め、あるべき構造を設計する……これで解決できるに越したことはありません。 しかし、認知バイアスと呼ばれる心理効果により判断を誤り、良くない設計をしてしまうことが往々にしてあります。 記事は、設計を歪めてしまう認知バイアスを理解し、設計判断の精度向上を促すことを目的とします。 この記事のゴール 人間の判断を歪めてしまう心理効果「認知バイアス」の存在を知ること。 ソフトウェア設計も、認知バイアスの悪影響を受けてしまうこと。 認知バイアスに振り回されない設計アプローチを身につけること。 認知バイアスとは 先入観や思い込み、偏

    設計を歪める認知バイアス - Qiita
  • API設計スキルを次のレベルに引き上げるベストプラクティス22選 - Qiita

    記事は、Mohammad Faisal氏による「22 Best Practices to Take Your API Design Skills to the Next Level」(2021年4月15日公開)の和訳を、著者の許可を得て掲載しているものです。 REST API設計のための実践的アドバイス Photo by Andrea Piacquadio from Pexels はじめに すべてが分かりにくく、ひどいAPIに不満を感じたことはありませんか?私はそうです。 マイクロサービスの世界では、バックエンドAPIの一貫した設計が不可欠です。 今日は、知っておくべきベストプラクティスについて、簡潔に説明します。さあ始めましょう! 用語 API設計は、リソース指向設計というものに従います。3つの重要な概念で構成されています。 リソース:データの一部(例:ユーザー) コレクション:リソー

    API設計スキルを次のレベルに引き上げるベストプラクティス22選 - Qiita
  • コンテナ運用におけるログ基盤設計のベストプラクティス - Qiita

    課題 数年前と比較すると、GKEやECSを始めとするコンテナ実行環境でのアプリケーション運用を行うサービスはかなり増えてきた印象があります。 コンテナを運用する上では、アプリケーションのイベントを追跡する上でログをどう扱うかが課題になります。今までのように古いログを定期的にローテートして別のストレージに転送するといった手法はクラウドネイティブなアーキテクチャには最適とは言えません。 アプリケーション開発の方法論として、Twelve Factor App ではログをイベントストリームとして扱うためのガイドラインが示されていますが、近年のWebアプリケーションではシステムを疎結合に連携するマイクロサービスという考え方が主流になりつつあります。 アプリケーションログはサービスごとにフォーマットを整形した上で、ログ収集サービスに配送。必要に応じてリアルタイム分析や異常データの通知、そしてデータの可

    コンテナ運用におけるログ基盤設計のベストプラクティス - Qiita
  • 政府CIOの「デジタル・ガバメント推進標準ガイドライン実践ガイドブック」が とても良かったので紹介したい - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? これって何? 政府CIOとは、内閣から任命され日行政のシステム全体を統括する「日政府のCIO」です。この政府CIOをサポートするのが各省庁を担当する50名近い政府CIO補佐官からなる政府CIOチームです。(組織としては、内閣官房 情報通信技術(IT)総合戦略室というようです) この政府CIOチームがとりまとめた政府職員向けのIT調達とシステム導入に関する標準が「デジタル・ガバメント推進標準ガイドライン」です。 このガイドラインは「編」「解説書」「実践ガイド」の3点構成になっています。 中でも今日ご紹介したいのが上図一番右の**「実

    政府CIOの「デジタル・ガバメント推進標準ガイドライン実践ガイドブック」が とても良かったので紹介したい - Qiita
  • 【OOUI】設計を改善したらユーザー(オカン)が使ってくれるアプリになった話 - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? ​​▼この記事では、前回の記事で紹介した自作アプリを題材にしています。 前回の記事を先に読んでもらえると、この記事の内容がより理解しやすくなると思います! 【初アプリ】未経験がFlutterで肉牛繁殖農家のためのアプリを作ってみた こんにちは、Takuです。 先日、Flutterで肉牛生育記録管理アプリ「Memow」をリリースしました。​ ​ このアプリのユーザーである自分のオカンオトンは、特にこちらからレクチャーせずとも問題なく使いこなしています。 基的にオカンがデータを入力し、オトンは共有データを閲覧するという使い方をしているよう

    【OOUI】設計を改善したらユーザー(オカン)が使ってくれるアプリになった話 - Qiita
  • Webサービスによくある各機能の仕様とセキュリティ観点(ユーザ登録機能) - Qiita

    みたいな画面が出るパターン。 観点1: 第三者のメールアドレス・電話番号の登録状況が確認できてしまう この仕様は、多くのサイトで実装されています。 が、二つの観点で注意が必要です。 「サービスに登録している」という事実が漏洩してしまう サービスの性質や法務的観点・ポリシーなど考慮しつつ判断が必要です リスト型攻撃の攻撃準備に悪用されてしまう 流出済みID/パスワードの組を利用する際、登録済みIDだけを抽出する作業に悪用されてしまいます セシールオンラインショップへの不正アクセス、二重登録防止機能を悪用しリストをスクリーニング(ディノス・セシール) 事例とともにすでに解説記事があったので引用します 「大手サイトもやっているじゃないか!」という意見もあるかと思いますが、認証機能への監視・リスト型対策・自動化対策が成熟していると思われるサービスの仕様を新規に作るサービスで真似するのは、難しい場合

    Webサービスによくある各機能の仕様とセキュリティ観点(ユーザ登録機能) - Qiita
  • プロジェクトリーダーというお仕事 - Qiita

    たとえば、詳細設計から結合試験までを行う場合なら、 13sp + 13sp + 13sp + 19.5sp = 58.5sp と計算します。 スクラムでやるなら1スクラムあたり何sp消化できるか、ウォーターフォールなど日数を見積もりたい場合は、そこから1spが何人日かを予め定義しておいて、実際の工数を割り出します。 (1スプリントで10sp消化できるとした場合は6スプリントかかる計算になるし、1sp=0.5人日とした場合は、29.5人日≒1.5人月となります) なお、この比率は求められる品質レベルから算出します。 たとえばドキュメントをかっちり書く必要があるのなら設計の比率を上げる必要がありますし、メモレベルでよかったり、GitのPullRequestなどに記載する程度でいい場合は比率は下がるでしょう。テストの工数も同様です。なお、上記のは「ある程度かっちりやる」場合の比率です。 比率を算

    プロジェクトリーダーというお仕事 - Qiita
  • 変更に強いアーキテクチャについてIT業界19年目の僕が超ザックリ説明する - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事は、設計・アーキテクチャ Advent Calendar 2018 の第7日目の記事である。 はじめに この記事では、IT業界19年目の僕が実践している変更に強いアーキテクチャについて、出来るだけ難しい表現を避け、教科書的なありきたりな内容ではなく現場の肌感覚に近い切り口で「超ザックリ」な解説を試みてみようと思う。 普段自分がよく用いている実装パターンの紹介ともいうべきかも知れない。 この記事で説明すること いざ「変更に強いアーキテクチャとは」とズバリ訊かれても、一概に「これだ!」という答えはない。 プログラミング言語や、フレー

    変更に強いアーキテクチャについてIT業界19年目の僕が超ザックリ説明する - Qiita
  • 1