知識０から、ちょっとUIデザインに詳しくなるnote｜やました
前回は、「UIデザインってそもそも何なの？」という概論的な説明と、UIデザイン未導入の組織の中でみんなでデザインを始めてみるための施策（プロトタイピングとユーザビリティ評価）を話しました。 今回はサービス、プロダクト開発において、デザイナーではない人でも知っていて損はないUIデザインの重要ポイントについて説明します。主に以下の３つのテーマについて順番に議論をしていきます。 デバイスやソフトによるUIの違い ユーザーにかかる身体的・認知的負荷を理解する UIの重要概念（ナビゲーション、インタラクションなど）を知る 「ちょっと」と銘打っておきながらめちゃくちゃ長いnoteになってしまったので、気になる項目だけ読むか、何回かに分けて読んでいただくことをおすすめします、。 ※どこか内容に間違ってる部分やご意見ありましたらコメントいただけたら嬉しいです。 デバイスやソフトによるUIの違い皆さんがお使
現実世界におけるスキーマ設計の妥協
存在感が薄い?!意外とがんばってるさくらインターネットFEチーム / Frontend Conference 2024
モダンなテストレベル設計（ユニットテスト～システムテスト等をどう設計するか）の原則 - 千里霧中
プロジェクト全体のテストを組み立てる際に重要な課題になるのが、テストレベル設計です。テストレベル設計は、ユニットテスト、結合テスト、システムテストといったテストレベルを、どのような責務・段取りで行うか分析・設計する活動です。 このテストレベル設計ですが、ここ10年程度の間に望ましいアプローチが変わってきたと感じています。今回はこの変化と、変化後のモダンなテストレベル設計の原則について、考えていることを書き出したいと思います。 旧来のテストレベル設計のアプローチ 旧来、このテストレベル設計では、Vモデルをベースしたアプローチや、自工程完結・品質積み上げをベースとしたアプローチがよく見られました。 このうち一つ目のVモデルをベースとしたアプローチは、要求定義から設計までの上流工程への対応を観点に、テストレベルを設計するものです。 （Vモデルが必須と明言しているわけではなく、極端な例ですが）例え
論理的思考の放棄 - 登 大遊＠筑波大学情報学類の SoftEther VPN 日記
僕は、1 日に少なくとも 3,000 行程度、多く書くときで 10,000 行以上のプログラムを書くことができる。その結果、多い月で 10 万行 / 月くらいである。なお、言語は書くソフトウェアの性質上、大半が C 言語である。 また、プログラミングにはバグが付き物だが、ここ 2、3 年の間は、発生するバグの数を極めて少なく保つことに成功している。 とても大きく複雑で、かつレイヤ的に OS に近い処理をたくさんやるプログラムを書く場合は、プログラミングをするときでも、事前の設計が極めて重要となる。設計をうまく行わないと、後になって全面的に書き直しをしないといけなくなったり、パフォーマンスが低下したりする原因となり、開発者の苦痛の原因となる。 当然のことながら、これまで書いたいくつかの大きく複雑といえるソフトウェアの大半の設計も、自分で行った。いかなる場合でも、設計は、最初の 1 回目で確定
【CSS設計手法】BEM、OOCSS、SMACSSの違いと特徴のまとめ | Web Design Trends
CSSの設計手法とは、CSSのメンテナンス性や作業効率を向上させるためのHTMLのクラス名の付け方と、CSSのコードの管理方法の考え方のことを言います。命名規則などとも呼ばれたりしますね。 ページ数が少なく、コード量もそこまで多くないような場合はあまり気にする必要はありませんが、大きなプロジェクトになるとCSSの設計手法を取り入れることで様々なメリットがあります。 今回は、CSSの設計手法に関する基本と、3つの人気のCSSの設計手法をご紹介したいと思います。 メンテナンス性が向上する CSSの設計手法を正しく取り入れることによって、全体的に管理の行き届いたコードを記述することができ、メンテナンス性が向上します。 逆に、煩雑になってしまったコードではスタイルの優先順位が複雑になってしまっていたり、!importantが随所で登場してしまっているようなコードのことで、一度コードが崩壊してしまう
FizzBuzzを題材にユースケース層についてを考えるのはおそらく無意味な気がする - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
やんざむ先生のこのツイートを見て考えたことをまとめます。 UseCase がわからない... FizzBuzz で 「3の倍数のときは fizz が返る」 「5の倍数のときは buzz が返る」 「3の倍数かつ5の倍数のときは fizzbuzz が返る」 「3の倍数でも5の倍数でもないときはそのままの数字が返る」 これは— Yuki Anzai (@yanzm) February 15, 2019 結論を先に書くと、「これはそもそも問い自体が不適切である」（しかし強いて言えばEntity）という立場をわたしは取ります。以下、まじめにFizzBuzzを設計しながら考えてみます。 ひとまず、出発点は上にあるツイートの疑問から出発するとしましょう。 まず前提として、ユースケースってどういう役割か まず前提として、ぼくはユースケースを「ドメインモデル（このツイートで言うところのEntity）やイン
実況中継シリーズ 「開発現場で役立たせるための設計原則とパターン」 #builderscon 2018 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
先日慶應義塾大学日吉キャンパスで行われた builderscon2018、最高のカンファレンスでしたね。わたしも「開発現場で役立たせるための設計原則とパターン」というタイトルで発表させていただきました。今回は恒例「実況中継シリーズ」として、プレゼンの再現をブログで行いたいと思います。 なお、過去の実況中継シリーズは前職の技術ブログにまとまっていますので、そちらからご覧ください。 それでは本編を開始したいと思います。 開発現場で役立たせるための設計原則とパターン アバンパート よろしくお願いします。 まず最初に簡単に自己紹介をさせていただきます。 先月転職をしまして、8/1からClassiという会社で働いています。妻と息子がおります。Scalaが好きですが、仕事ではRubyメインという感じです。 Web+DB PressやSoftware Designで何度か特集を書かせていただきました。と
カメラの豆知識 ～レンズ名称と歴史～ - Circulation - Camera
さて、今回はレンズの名称について述べてみたいと思います。 歴史も絡めた読み物的な内容にしてしまったので、5000字近く、ガチで読むと30分くらいかかるかもしれません (; ･`д･´) 量があってオタクな内容なので、興味のある方は御時間のあるときに読んでやって下さいませ ^^; ～前置き～ さて、CANONやNIKONのレンズはスペックがそのまま名称になっています。 例えばNIKONの「AF-S NIKKOR 24-70mm f/2.8E ED VR」の場合、 ・AF-S → 超音波モーター式のオートフォーカスを搭載 ・NIKKOR → ニコンのレンズです ・24-70mm → 35mm換算で24-70mmでズームできます ・f/2.8 → 細小絞り値は2.8です ・E → 絞りは電子制御です ・ED → 特殊低分散硝子を採用し色収差を抑制しています ・VR → 手振れ補正が付いています
メンテナンスしやすいVueComponentを設計するために気をつけていること
はじめに VueをつかってWebアプリケーションを実装するとき、Componentをどう切るかって誰でも一度は悩みますよね(悩みますよね？)。とりあえず思いつくままに切ってみたり、繰り返し使いそうなもので切ってみたり、CSSのスコープで切ってみたり…。いろいろな切り口があると思います。 この「いろいろな切り口」でコンポーネントを切ることができる点が、コンポーネント設計を難しくしている所以だと考えています。 そこで今回は、どのような切り口・観点でコンポーネントを切ればよいのか、そのときに気をつけるべきことは何か、といったComponentの設計方法についてまとめてみます。 すべての実用ケースを想定できているわけではないと思いますが、大小いくつかのWebアプリを開発する際に利用してみて今のところいい感じに運用できている方法です(というか自然と収束して出来上がった考え方という感じです)。 はじめ
ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か[DDD] - little hands' lab
DDD連載記事 背景・前提 なぜDDD初心者はググリ出してすぐに心がくじけてしまうのかの記事で、 ネット上の文献で紹介されるアーキテクチャが様々なものとなっているのです。IDDDではヘキサゴナルアーキテクチャというものが掲げられていましたが、それを進化させたオニオンアーキテクチャ、クリーンアーキテクチャなどの有名な亜種が存在します。 これが実装に着手する際に非常に大きな混乱を呼ぶのです。文脈の理解、採用するアーキテクチャの選定に時間を取られることでしょう。 と書きました。こちらに対して、私が「一番とっつきやすい」と考えるアーキテクチャを紹介します。 前提としてですが、完全に個人的な経験に基づく私見になります。 DDDの理論の中で、アーキテクチャに関しては「エリック・エヴァンスのドメイン駆動開発」(以下原典)と実践ドメイン駆動開発(以下IDDD)とでも異なったものが紹介されており、唯一の正解
![ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か[DDD] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/ed125204d89ae253a4ab2a6c711eff21748ee9c7/height=288;version=1;width=512/https%3A%2F%2Fqiita-image-store.s3.amazonaws.com%2F0%2F30489%2F81fcfd95-2ce1-82a8-db69-8618338a5f22.png)
キャッシュフレンドリーなステートレスアプリケーション設計について考える #CDN_Study - mizchi's blog
CDN_Study という勉強にいってきた。 https://http2study.connpass.com/event/81469/ そこで、Akamaiの方が、「個人の意見だけど、アプリケーション側がもっと基礎設計でステートレスでキャッシュフレンドリーな設計になってないといけないよね」という旨の発言をしていて、最近そのことにアプリケーションエンジニアとして同じようなことを考えていたので、書き出してみる。 SPAとかSSRとかフロントの不毛な話は出さないようにしてるが、主にサーバレス環境を意識している。 前提 世の中のアプリケーション内のモジュールは、Statefull or Stateless に分類でき、それをツリー状に表現できれば差分検知できる、という React の仮想 DOM 的な世界観が自分にある 以下の話は、基本的には Fastly のサロゲートペアーとそのためのミドルウェ
Angular中〜大規模アプリ設計 // Speaker Deck
All slide content and descriptions are owned by their creators.
PHPのエラーと例外再入門 / php-error-and-exception
PHPカンファレンス福岡2017の登壇資料です。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Androidアプリで安定して動作させ継続的に開発するために設計の原則を利用して開発した話
SimpleとEasyは違う / Simple is not Easy
終わりゆく Vue 2.x 時代の状態設計のアンサー - Vue 3 の Provider への期待 / The Last Architecture of the Vue 2.x
Atomic Architecture
あの日見た M V Whateverの Modelを僕たちは まだ知らない
Web API Design // Speaker Deck
ドメイン駆動設計基礎講座〜戦略編〜
