タグ

2020年10月23日のブックマーク (8件)

  • フロントエンド開発環境の継続的なリファクタリング | MEDLEY Developer Portal

    2020-10-20フロントエンド開発環境の継続的なリファクタリングこんにちは、第二開発グループエンジニアの西村です。主にCLINICSの開発を担当しています。 はじめにCLINICS は電子カルテ、オンライン診療、予約システム、患者アプリなどを含む統合アプリです。CLINICS がローンチしてから現在に至るまで常に新機能開発と定常改善が行われており、開発環境のメンテナンスは後手になりがちでした。今回はそういった状況を改善すべく、開発環境のメンテナンス、リファクタリングを行った過程から得られたプラクティスについて紹介していこうと思います。 モチベーションプロダクトの新規開発時に行われる技術選定は非常に難しく、業務要件やチーム状況など総合的に考慮してその時点でのベストな選択をする必要があります。 しかし、選択した技術で長期運用をしていくうちに、メンテナンスが行き届かなくなったコードやライブラ

    フロントエンド開発環境の継続的なリファクタリング | MEDLEY Developer Portal
  • 『デザイン思考』という言葉にデザイナーとして改めて向き合って考えた結果得られたもの - Pepabo Tech Portal

    こんにちは、デザイン部デザイン戦略チームでプリンシパルデザイナーをしている咲 @satosio です。 2020年4月にGMOインターネットグループの新卒入社パートナーを対象に「デザイン思考について」約1時間の講義を行いました。この記事ではそこで使用したスライドをもとに「デザイナーにとってデザイン思考とはなにか」を説明していきます。 「デザイン思考」はデザイナーに限った話ではないのですが、「デザイン思考(笑)」というように、言葉自体をなんとなく毛嫌いしてしまっているデザイナーに「デザイン思考」と呼ばれているものの正体はなにかを説明することが記事の目的です。 結論 概要 共感とはSympathyではなくEmpathy 共感からインサイトを得ることで自分ごと化する デザインとは意思決定の積み重ね 意思決定は「仮説推論」に基づいている デザインの思考法とはフレーミングを用いた仮説推論 デザイン

    『デザイン思考』という言葉にデザイナーとして改めて向き合って考えた結果得られたもの - Pepabo Tech Portal
    iselegant
    iselegant 2020/10/23
    僕もワークショップに参加した際、デザインシンキングはそもそも課題を見つけるというプロセスを実施してた。そうすることで、僕らが本来困っていることを改めて見つめ直すプロセスが生まれることに価値がある。
  • ISUCON10 本選問題の解説と講評 : ISUCON公式Blog

    こんにちは、ISUCON10 の選出題を担当した白金動物園の mirakui です。最近はパン作りにハマっています。この記事では、選問題であるアプリケーションの「XSUCON」について、問題の概要と想定していた解き方について解説していきたいと思います。 XSUCON とは近年の ISUCON にはとても多くの方が参加してくださり、スコアランキングを表示したりベンチマーカー実行を指示したりするいわゆる「ポータルサイト」の負荷対策には毎年の出題担当たちが苦労してきました。記念すべき 10 回目の開催である ISUCON10 ではぜひこの ISUCON ポータルサイト自体を問題にしたい、と私たち白金動物園が1年前から温めてきた構想を形にしました。 というわけで ISUCON10 の選問題は「XSUCON」という、 ISUCON を模した仮想的な競技のポータルサイトでした。XSUCON の世

    ISUCON10 本選問題の解説と講評 : ISUCON公式Blog
    iselegant
    iselegant 2020/10/23
  • Googleが採用するUXデザイン手法「3対1の法則」とは デザイン会社 ビートラックス: ブログ

    先週アップしたエシカルデザインに関する内容に関して、具体的にどのようにして“正しいデザイン”を行えば良いのかという質問が寄せられた。 一つの方法は、UXピラミッドの原則に従ってプロダクトの体験価値を検証したり、UXハニカムを活用する方法もある。 それらに加えて今回紹介したいのは、GoogleAndroidチームが採用しているUXデザイン手法である。とてもシンプルですぐにでも活用できる内容になっている。 進化するデジタルプロダクトに対するUXデザインアプローチサービスのデジタル化やDXが進む中で、多くのプロダクトにおける「完成」という概念がなくなり、デザインは常に進化し続ける必要性が出てきた。特にユーザー体験においては、デバイスの進化やユーザーの感覚の変化などを考慮し、常に改善を続けなければならない。 では、実際にどのようにデザインの良し悪しを判断すれば良いのだろうか?継続的にバージョンア

    Googleが採用するUXデザイン手法「3対1の法則」とは デザイン会社 ビートラックス: ブログ
    iselegant
    iselegant 2020/10/23
  • なぜ金融系プロジェクトで先進のコンテナ技術を選択したのか

    なぜ金融系プロジェクトで先進のコンテナ技術を選択したのか:巨大SIerのコンテナ・Kubernetes活用事例(2)(1/2 ページ) NRIのコンテナ・Kubernetes活用事例について紹介する連載。第2回はFinTechサービスをクラウドやコンテナで支援した事例を紹介する。 金融系サービスでも顧客体験を改善する迅速さは不可欠 「金融」と聞くと、勘定系処理や外部システムとの接続、バックオフィス業務などを思い浮かべる読者も少なくないだろう。これらのシステムでは、「求められるシステム品質が高く、ドキュメントは重厚に整備、管理され、大規模な工数が必要なプロジェクト」という点を想像するに難くない。野村総合研究所(以後、NRI)はインターネットバンキングや証券業の大規模共同利用型サービスを構築、運用しており、まさにNRIが得意とする領域でもある。 こうした大規模プロジェクトのみならず、NRIは

    なぜ金融系プロジェクトで先進のコンテナ技術を選択したのか
    iselegant
    iselegant 2020/10/23
    寄稿しました。内容・文章ともに拙い点があるかと思いますが、皆様のビジネス発展のヒントになればと思います。
  • スタディサプリENGLISHの基盤をECSからEKSに移行しました | Recruit Tech Blog

    こんにちは、スタディサプリ ENGLISH SREグループの大島です。 オンライン英語学習サービスであるスタディサプリ ENGLISHは2015年10月のリリース1)当時は英語サプリという名前でリリースしていましたから5年が経ち、おかげさまでサービスを拡充させることができています。リリース当初からインフラにはコンテナを採用し、長い間AWSのコンテナオーケストレーションサービスのAmazon Elastic Container Service(以下、ECS)で運用してきましたが、この度ECSからAmazon Elastic Kubernetes Service(以下、EKS)に移行しました。 今回の記事では、その歴史の変遷となぜEKSにしたのかというところを書いていきたいと思います。 コンテナと歩んできた5年間 まず、ECSからEKSに移行しようと思ったきっかけの前に、インフラの歴史を少し振

    スタディサプリENGLISHの基盤をECSからEKSに移行しました | Recruit Tech Blog
    iselegant
    iselegant 2020/10/23
    なるほど。ECS-->EKSの理由がちゃんと述べられていてわかりやすい。
  • GoのテストをCIで簡単に並列実行する | おそらくはそれさえも平凡な日々

    https://github.com/Songmu/gotesplit gotesplitというかなり便利なツールを書いた。Goのテストをいい感じのサブセットに分割して、それを実行するものです。このアプローチで、社内のテストを15分から3分くらいまでに短縮しました。 これを使えばCI環境での高速なテストの並列実行を簡単に実現できます。 実例 CircleCIGitHub Actions上で簡単に導入できます。 CircleCIの場合 parallelism: 5 docker: - image: golang:1.15.3 steps: - checkout - run: command: | curl -sfL raw.githubusercontent.com/Songmu/gotesplit/main/install.sh | sh -s bin/gotesplit ./... -

    GoのテストをCIで簡単に並列実行する | おそらくはそれさえも平凡な日々
  • 再考 - ドメインサービス  - まっちゅーのチラ裏

    自分が大規模システムで組むアーキテクチャは基的にはCleanArchitectureを踏襲しているが、その中の構成要素であるドメインサービスだけは少し独自(?)の解釈をしていて、書籍などでよく見る ビジネスロジックを持つが、状態をもたない 複数の集約にまたがる処理を書く場所 という責務の他に、外部システムへの委譲処理だったり、共通UseCaseのような責務も持たせている。 これは、自分が「xxService」という命名にトラウマがあり(何でも置き場になりがち)、単なるServiceだとコントローラやらプレゼンターやら、どこから呼ばれても違和感がない様に見えてしまうから、とりあえずDomeinServiceへ寄せている経緯がある。 ※ここで語るのは、あくまで大規模想定で、小さいシステムならこんな事を意識する必要はないはず。 ※あくまで自分の考えで、一般的ではない可能性があることをご了承くだ

    再考 - ドメインサービス  - まっちゅーのチラ裏