テーブル・DB設計するときの極意 - Qiita
はじめに 「テーブル・DBを設計するときのさいきょうの極意」を完全に理解したので 初心者（私）向けに共有する記事です。 どうぞ揉んでいただければ幸いです。対戦よろしくお願いします。 さいきょうの極意 初心者が「テーブル・DB設計して」と言われると、 「アソシエーションってあったよね・・・バリデーションも？中間テーブルを使うときと使わないときと・・・」と大変に混乱し、何から手をつけていいかわからなくなります。 そんなあなたにこれ！ テーブル・DB設計は「属性」と「関係」の２つだけ 「属性」は必要なものを書くだけ 「関係」は 1:1 / 1:N / N:N しかない（しかも、ほとんど 1:N） これが極意だ！！！ 一般的な、「ユーザーがいて、投稿ができて、コメントといいねができるサービス」で考えてみましょうか。 users / posts / comments / likes のテーブルが必要
【爆速UI設計術】モダンなwebデザイン素材集 - Qiita
特徴 女性らしいイメージがやや多い 下記のような柔らかい印象のイラストが多いです。 【ガジェットストック】 ガジェット関連のものを使用したい場合は、下記を使用すると良いと思われます。 【アイコン系】 【human pictogram 2.0】 オリンピックで流行ったやつです。 本サイトでは、アタッチメントをつけたりすることでかなりカスタマイズ性が高いのが特徴です。 【EXPERIENCE JAPAN PICTOGRAMS】 特徴 海外から見た日本が表現されている これはシンプルにUIが凝ってたので紹介します。 和テイストを演出したい場合は、良さそうですね！ 【ICOOON MONO】 こちら色・サイズも変更可能です！ 【Icon-rainbow】 ICOOON MONOと異なり、こちらは、中が肉抜きされているのが特徴。 【IFN FREE ICONS】 このデザインはどのようなパターンにマ
オブジェクト指向でUIを考えられるようになりたい。 - Qiita
1. 目的 UIデザインを勉強し始めました。現在「オブジェクト指向UIデザイン-使いやすいソフトウェアの原理」を読んでいます。そのため、学習進行の記録と復習を兼ねて、学んだことを記事にしようと思います。 以下「1. オブジェクト指向UIとは何か」という本書のさわり部分についてまとめています。 この記事で載せている例には私が考えたものも含まれていますので、間違い等ありましたらコメントにてご指摘いただけますと幸いです。 2. オブジェクト指向UI(OOUI) UIをオブジェクト(ユーザーが操作する時の対象物)を起点に設計します。GUIももともとオブジェクト指向プログラミングのコンセプトに合わせて考案されました。多くのアプリはオブジェクト指向型のGUIです。 最大の目的は、ユーザーがオブジェクトに対して自由な順序で働きかけながら目的を達成することです。 原則 オブジェクトを知覚でき直接的に働きか
JWTでセッション管理してはいけない - Qiita
世の中にはJWT(JOSE/JWS/JWE)でセッション管理をしてはいけないという記事が2017年から山ほどあるのに、なぜかJWTでセッション管理をしようとする人がいる。翻訳記事だったり暗号の説明が長すぎたりして、JWTをセッションに使ってしまうような人の心に刺さってないんじゃないだろうか。 前提 JWTでセッション管理というのは、暗号化したトークンをブラウザのCookieに持たせて、サーバー側ではトークンを復号化してユーザー判定などのセッション管理を行うことである。サーバー側で[sessionId: userId]のペアを管理する必要がないのでステートレスに扱えてスケールしやすいというメリットがある。 問題 すごく便利な図があったのでまずこれを読んで欲しい。セッション方式の策定/設計をする職位の人ならすんなり読めると思う。 co3k.orgより引用 1 左から４番目Local Stora
【日本人エンジニア必携】英語命名規則の決定版 - Qiita
弊社Nucoでは、他にも様々なお役立ち記事を公開しています。よかったら、Organizationのページも覗いてみてください。 また、Nucoでは一緒に働く仲間も募集しています！興味をお持ちいただける方は、こちらまで。 はじめに 英語での適切な命名は、コードの可読性や保守性を向上させるために重要です。適切な命名規則を守ることがコードの理解や共有において不可欠です。 英語での命名規則を学び、適切な命名を行うことで、コードの読みやすさや保守性を向上させ、チーム全体でのコードの理解を促進する手助けとなります。 この記事では、日本人エンジニアが英語での命名規則を理解し、適切な命名を行うための指針を提供します。 命名フローチャート 変数 関数 クラス 1. 変数 1-1. boolean 1-1-1. 存在するかどうかのフラグ 名詞 + exists
実践：はじめてのWebAPI設計 - Qiita
はじめに この記事はAPIの基本的な実装方法を丁寧に解説します。基礎を学びたい方、今更聞けないような知識の振り返りを求める方の役に立つことを願っています。もう十分理解できている！という方は、目次から実装にとんでみてください。 具体的にはHTTPと呼ばれる通信方法を利用した、シンプルな本の貸し出しシステムの土台を考えます。要件の各ステップで、設計の基本原則やベストプラクティスについても触れながら、より実践的な知見を共有できればいいなと思います。 弊社Nucoでは、他にも様々なお役立ち記事を公開しています。よかったら、Organizationのページも覗いてみてください。 また、Nucoでは一緒に働く仲間も募集しています！興味をお持ちいただける方は、こちらまで。 基本用語 Webに関する基礎知識の解説記事はQiitaに豊富にあったので、要点を抑えつつリンクをまとめました。 WebAPI Web
FigmaとNotionでUML・経理処理・デザインまでAll in oneな仕様書を書いて、更新・共有を楽にしてる話 - Qiita
前提としての情報 単に「Figmaで要件定義のためのUMLも、外部設計のためのデザインも、内部設計のためのERDも全部つくるよ〜〜」という話をすると、ERD書くならデザインツールなんて使わないで、DBMSから自動生成できるツールとか使った方がいいじゃん、みたいな疑問が出るのは重々承知なので、そもそもこの形式に落ち着いた前提事項を書いておきたいと思います。 ご興味がなければ読み飛ばしてください。 筆者の仕事範囲 さて、冒頭で「事業会社でデザイナーとPMの狭間みたいな仕事をしてます」と書きました。キャリアの背景的には受託のPMっぽい仕事（厳密には違うんですが、本旨ではないので割愛します）→事業会社のインハウスデザイナー→現職という感じで、外渉から手を動かす所まで、必要ならなんでもします。 ざっくりいうと、機能の起案をして、経理などの関連部署に相談して、WBS引いて、UML書いて、画面遷移図書い
わかりやすいシステム構成図の書き方 - Qiita
わかりにくいシステム構成図とは こんなシステム構成図を書いてないでしょうか？ このシステム構成図のわかりにくい点が３つあります。それは 製品名は書いてあるが「役割」が書いていない データと処理が区別できない データの流れと制御の流れが区別できない の３つです。 わかりやすいシステム構成図 これら３つのわかりにくい点を改善したわかりやすいシステム構成図が↓です ポイントを解説していきます ポイント1. 製品名称ではなく「役割」を書く システム構成図には製品名称ではなくシステムコンポーネントの「役割」を書きます。 役割とは、例えば〇〇データや〇〇処理といったことであり、それを読むだけでシステムの動きを理解できる文字列です。役割をかかずに製品名称のみを書いてしまうと、その製品を知らない人が見たときに理解できません。例えば「Cloud Pub/Sub」という製品はGCPというパブリッククラウドの分
結局UMLとかシーケンス図とかAWSの図とかどれで描くと良いのよ？と思ったときの選択肢 - Qiita
自身のプライオリティによりますが、いくつか。 Markdownで幅広く再利用性を利かせたい、長期的に丁寧に版管理したい 自分自身の操作性、描きやすさと、見た目 俄然手軽に、短期的に、Onlineでいつでもどこでも いずれかという視点で考えると良いのかなと思い、並べてみました。 1. 長期的に: Markdownで幅広く再利用性を利かせたい、丁寧に版管理したいなら Markdownで描くことのメリットは再利用性。 将来的に追記・編集、自分以外の誰かが手を入れる可能性が高い。 現在のドキュメントだけでなく多種説明資料、媒体に転用する可能性がある。 ...という点で差分管理をしたいなら、以下。 VSCodeでPlantUML、Mermaid 上記参考で以下。 Alt+D でプレビュー起動。 Ctrl + Shift + P でコマンドパレットを起動し、出力。 png, svg, eps, pdf
【OOUI】設計を改善したらユーザー（オカン）が使ってくれるアプリになった話 - Qiita
▼この記事では、前回の記事で紹介した自作アプリを題材にしています。 前回の記事を先に読んでもらえると、この記事の内容がより理解しやすくなると思います！ 【初アプリ】未経験がFlutterで肉牛繁殖農家のためのアプリを作ってみた こんにちは、Takuです。 先日、Flutterで肉牛生育記録管理アプリ「Memow」をリリースしました。 このアプリのユーザーである自分のオカンオトンは、特にこちらからレクチャーせずとも問題なく使いこなしています。 基本的にオカンがデータを入力し、オトンは共有データを閲覧するという使い方をしているようです。 それまでアナログ管理をしていたオカンオトンがすんなりこのアプリを使用できていることについて、前回の記事を読んでいただいた方から「驚いた」という反応を多くいただきました。 ユーザー（オカンオトン）がこのアプリを使えている理由を自分なりに分析する
【初アプリ】未経験がFlutterで肉牛繁殖農家のためのアプリを作ってみた - Qiita
はじめに 皆さんはじめまして、Takuと申します。 自分はエンジニアとしての業務も業界も未経験ですが、先日初めてFlutterで肉牛繁殖農家のための生育記録アプリ「Memow」をリリースすることができました。 今回初めての個人開発を通して、ゼロからのモノづくりの楽しさを実感しました。 しかしその反面、知識や経験のない中で、要件定義、設計、UI/UXデザイン、コーディングなど、これら全てをひとりで行うのはなかなか大変でした。 そこで、自分がどのように「Memow」を作っていったのかまとめたいと思います。 今回は、アプリリリースまでの工程の中でも、どのようにアプリの構想を作り上げていったのかという「設計」に焦点を当てています。 自分と同じようにアプリを作る中で悩んでいる人にとって、何かのヒントになれば嬉しいです！ 肉牛生育記録アプリ「Memow」の紹介 自分が作ったのは、肉牛の生育日数や日々の
【初心者向け】Atomic Design っぽい、Figma の使い方 - Qiita
はじめに みなさま、いかがお過ごしでしょうか。Figma 流行ってきてますね〜。 他にも Framer X や STUDIO 、そして Figma の上位互換かもしれない Phase が盛り上がりを見せています。 導入記事も増えてきているので、具体的な 作成フロー を紹介したいと思います。 作成済みのファイルは探せばいっぱいあるので、Atomic Design ぽいプロセスで、よく使う UI パーツを作るところまでハンズオン形式で書いてみます。 ただし、原理主義的なプロセスや理論 ではなく、誰でも順を追って Figma を使える状態を目指します。 ストラテジストとエンジニア、そしてデザイナの作業が分断されている時点でイノベーティブではありません。 この三者が統合的にデザインできること、すなわち ワークフローそのものを最適化することが目標 です。 Figma と Atomic Design
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
