タグ

2020年4月16日のブックマーク (5件)

  • キャンセルボタンに色をつけてはいけない理由

    キャンセルボタンをデザインする時に、カラーで悩むことはありませんか? キャンセルボタンに色をつけてはいけない理由、ニュートラルなグレーが適している理由を紹介します。 キャンセルボタンのデザインがアクションボタンと同じだと、ユーザーは迷ってしまいます。キャンセルできることを明確にすることで、認知速度が上がります。また、ボタンが3個以上だったり、ラベルが違っていると、ユーザーは余計に戸惑います。 Why Cancel Buttons Should Never Have a Color by UX Movement 下記は各ポイントを意訳したものです。 ※当ブログでの翻訳記事は、元サイト様にライセンスを得て翻訳しています。 キャンセルボタンに色をつけてはいけない理由 ニュートラルボタンのためのニュートラルカラー キャンセルに適したラベルとは グレーを使う時は十分に暗くする キャンセルボタンはニュ

    キャンセルボタンに色をつけてはいけない理由
  • progress要素を使ったロードの状態の管理 | きるこの日記帳

    HTML には、プログレスバー向けに progress 要素が存在し、タスクの進行状況を管理できる。 HTML LS より progress 要素の説明 Can I use Polyfill ロードの種類 ローディングアニメーションには、目的地が決まっている Determinate (確定型)と、 同じ動きを繰り返し行う Indeterminate (不確定型)の 2 種類が存在する。 このうちプログレスバーは、Determinateに属するもの。 クルクル回るスピナーなどは Indeterminate にあたる。 非progress要素 progress 要素を使わず、divなどでプログレスバーを表現する場合。 html <div id="progresslabel" class="opacity0">ロードの進捗状況</div> <div role="progressbar" aria

    progress要素を使ったロードの状態の管理 | きるこの日記帳
  • 複雑怪奇な nginx を Go と Docker でユニットテストする - Cybozu Inside Out | サイボウズエンジニアのブログ

    全国の nginx 職人のみなさま、こんにちは。野島(@nojima)です。 私の所属するYakumoプロジェクトでは、nginxGoDocker によってユニットテスト1しています。 手元で簡単に実行でき、ブランチへのpushのたびにCIでテストされるので、非常に便利です。 この記事では、このnginxのユニットテストについて紹介してみたいと思います。 背景 nginx は極めて柔軟なロードバランサであり、プロダクション環境ではその柔軟さを生かして多彩な役割を担っています。 我々の nginx は、ユーザーからのリクエストを AP サーバーに振り分け、アクセス制限を行い、リクエストをリダイレクトし、HTTPヘッダを付与したり削ったりしています。 しかし、nginx は便利な反面、その設定は極めて複雑になり、読解したり変更したりするのが難しくなっています。 そこで、nginx

    複雑怪奇な nginx を Go と Docker でユニットテストする - Cybozu Inside Out | サイボウズエンジニアのブログ
  • なぜMicroservicesか?

    現職においてMonolithアーキテクチャからMicroservicesアーキテクチャへの移行とその基盤の構築に関わって2年近くが経った.未だ道半ばであるがこれまでの経験や日々のインプットをもとにいろいろ書いておこうという気持ちになった.記事ではそもそもMicroservicesアーキテクチャとは何かを整理し,なぜやるべきか?・なぜ避けるべきかを整理する. Microservices? Microservicesアーキテクチャとは「Single purpose,High cohesion,そしてLoosly Couploedなサービスを組み合わせてシステムを構築する」アーキテクチャ手法である.それぞれの原則をまとめると以下のようになる. Single purpose: 一つのことに集中しておりそれをうまくやること Loose coupling: サービスは依存するサービスについて最小限の

  • Microservices for Everyone - 2つの "why-microservices" を読んで|qsona

    どちらも大変素晴らしい記事で、大変よくまとまっていながら主張が入っていて読みごたえのある文だった。それに比べたら、以下の文はまとまりもない駄文だが、それでもどうしてもこの話題には物申したくなる自分がいる。知見と呼べるほどでもないけれど、3年間マイクロサービスのことを考え続けてきた者の率直な感想として、読んでいってもらえたら嬉しい。 tl;drこの記事を通して、僕が結局何が言いたいのかというと、マイクロサービスはもっと開かれたものであってほしいということだ。複数のビジネスをやるならマイクロサービスの考え方を導入する権利があるし、すでにマイクロサービスをやっているなら、マイクロサービスのことを考えるのは基盤チームだけじゃなくてみんなであるべきだ。 マイクロサービスは「やる」か「やらない」かではない前者のdeeeetさんの記事は、全くマイクロサービスを知らない人がぜひ読むべき、当に良い記事だと

    Microservices for Everyone - 2つの "why-microservices" を読んで|qsona