スタブ・モックは本当に悪者なのか？〜テスト駆動開発をやめて、なお残すべき習慣とは (2)
技術詳細は外側へ寄せるポイントは、中心となる対象ドメインは何か？中心から排除したい要素は何か？を考慮して区分けすることです。中心のドメインから排除したい項目の代表例が、データベースアクセスや外部Webシステムやメッセージングといった詳細の技術要素です。ドメイン駆動設計の設計判断を取り入れている場合は、オブジェクトへのアクセスするためのRepositoryのインタフェースのみを中心ドメインに入れ込み、Repositoryの実装（特定のデータベース種類やSQLなど実装詳細）は外側に追いやります。同様に、インタフェースのみを中心にいれてメッセージングや他のWebシステムのアクセス等の実装の詳細は外部に追いやります。 うまく区分けできれば、中央に残った純粋なビジネスについてのルールや状態遷移についてをユニットテストやリファクタリングを継続することができます。リファクタリングによる設計改善を継続する
複雑なJavaScriptアプリケーションを考えながら作る話
autoscale: true theme: Plain Jane,5 複雑なJavaScriptアプリケーションを考えながら作る話 自己紹介 Name : azu Twitter : @azu_re Website: Web scratch, JSer.info #jsprimerを書いています JavaScript入門書に興味ある人はウォッチ :star: :warning: 注意 :warning: 作成するアプリケーションによって必要な構造は異なります 今回の話はある程度の規模で複雑性を持つクライアントサイド ライブラリ抜きで数万LOC >= 長期的にメンテンナンスや変更が発生するアプリケーション サーバサイドレンダリングはしないクライアントアプリケーション 3行でOK 複雑なJavaScriptアプリケーションを作るにあたりドメインモデルをどう実装するか悩んだ 色々と試行錯誤した
How to work as a Team
autoscale: true How to work as a Team 自己紹介 Name : azu Twitter : @azu_re Website: Web scratch, JSer.info 目的 新規でそこそこ複雑なウェブページを作る(アプリに近い) ある程度柔軟に拡張でき、メンテできるような設計にしたい 無難にReact + 何かでちゃんと設計して作っていきたい この設計部分をどう決めていくのかという話 現状 チームにReact/Flux/Reduxを触ったことがない人が多い どれが(主にView以外の設計)ベストかは分からない Flux的な部分の話 ものごとは変わる。 混乱は変わらない 混乱の原因 情報過多 情報不足 適切でない情報 上記の組み合わせ！ via P21 今日からはじめる情報設計 情報の共有 情報不足 そもそもReactなどを知らない人には知ってもらう必
[セッションレポート]NetflixにおけるMicroservicesアーキテクチャ #reinvent | DevelopersIO
この記事は AWS re:Invent 2014、PFC304-JT - Effective Interprocess Communications in the Cloud: The Pros and Cons of Micro Services Architectures - Japanese Trackのレポートです。 スピーカーはNetflixのSudhir Tonse。 レポート どうやってMicroservicesに変化していったのかを話したい。 これまで何度か本番環境が停止し、そこからたくさんのことを学んだ。それを共有したい。 Netflixについて。映画のストリーミングサービス。 PCやPS4などで再生できる。 ネットワークの1/3のトラフィックをNetflixが占めることがある。 20億以上のエッヂAPIリクエストがあって、500以上のMicroservicesが動いてい
![[セッションレポート]NetflixにおけるMicroservicesアーキテクチャ #reinvent | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/9f822a733dd20e28505900c2cfb90a863cdb365a/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2014%2F11%2Fre_invent_eyecatch.png)
持続可能な開発を目指す ~ ドメイン・ユースケース駆動（クリーンアーキテクチャ） + 単方向に制限した処理 + FRP
この記事は、開発を持続可能にできるようなアーキテクチャとその適用方法を考察するものです。 骨子はできていますが、実装経験をフィードバックして詳細を若干変更するかもしれません。 勉強不足な点もあるので、意見を歓迎します。 開発においてよくある問題点 ビジネスロジックの本質が何だったか見失う。ソースコードのどこまでが業務上の関心で、どこからがそれを実現するための技術上の関心か分からなくなる。 入出力双方向の処理が散在して処理が追い切れなくなる。特にイベント処理でどこに飛ぶかわからないコールバック地獄になる。 初期化・つなぎ込み・統合者的オブジェクトが小さな機能単位で生まれて統一感が無くなる。 状態を持つ値が大量に散在して副作用を起こしバグを生む。 これらの問題の結果、小さな単位ごとに個人のノウハウで"良い"設計がされ、機能を追加しようとしたときにどういう方針で行えばよいか分からなくなる。 解決
OOCSSの欠点とEvery Declaration Just Onceのもたらすもの
昨日も少し書いたEvery Declaration Just Onceアプローチ(以下EDJOと略す)について、皆が目を瞑っているOOCSSの欠点、CSSが持つ特徴、HTMLとの兼ね合いという点からもう少し書いてみたい。これについては未だ誰ともちゃんと議論していない。機会があったらこの記事をベースにでも誰かと話してみたい。 上記Googleの文書は、主にパフォーマンスの観点で書かれている。どうしても長くなりがちな定義を分散して書くよりも、能動的に短くすることができるセレクターを分散して書いた方が、プロダクションにおいてリリースされるCSSファイルのサイズを小さくすることが可能だろうというものだ。同時にこの文書の筆者は自身のブログで、より自然にCSSを書くための手法(原文: 「The Natural Way of Writing CSS」)としてこのEDJOという手法について述べている。 僕
MediumのCSSはこの上なく最高！ | POSTD
自分は常に最高であれって思っている。最高の香りを身にまとい、最高の振る舞いをする。ごみ1つ捨てるのだって、ほかの誰よりイカしてなきゃ。 ―Lil Wayne ずっと長いこと恥も外聞も知らずに、MediumでCSSについて執筆しようと思っていました…。 それからどうなったって？ 違うことをやっていた？ 何てこと、どうやったら同じことができるかって？ やり方を教わりたいって？ これから書くことは私たちのCSSについての覚書で、これまでに歩んできた道のりと現在のCSSについて述べています。 始まり（これまでの道のり） だいたい2年ほど前、私はソフトウェアアプリケーション開発と（皆さんが読んでくれているといいのですが） medium.com に取り組むためにObvious Corp.に加わりました。 その時、Mediumは、すでに一連の”スタイル更新”を行っていました（ スタイル更新とは デザイナ
"Microservices"を読んだ
James Lewis氏とMartin Fowler氏による“Microservices”を読んだ．以前ざっと目を通したが，最近よく耳にするようになったのでちゃんと読んだ．以下はそのメモ． 概要 “Microservices” とはソフトウェアシステムの開発スタイルである 近年このスタイルでの開発を見てきて良い結果が出ている 初出は2012年の3月の“Micro services - Java, the Unix Way” Microserviceは一連の小さなサービスで1つのアプリケーションを開発する手法 それぞれのサービスは自身のプロセスで動いており，軽量な機構（e.g., HTTP API）を通じて情報をやりとりする これらのサービスは独立して自動デプロイされる 一枚岩として構築されるMonolithicスタイルのアプリケーションと比較すると分かりやすい 一般的なエンタープライズのア
BugSnag's CSS Architecture
A few months ago, a number of designers and UI engineers, inspired by a popular blog post from GitHub’s Mark Otto, published articles on their approaches to writing and organizing CSS. In this post, I’m going to follow suit and take you through a breakdown of the tools we use, as well as the architecture of BugSnag’s CSS. There’s no surefire method for organizing CSS for all situations; the conten
CSS Architecture | en.ja Article
CreditThis article is translated with permission of Philip Walton. You can find original article at CSS Architecture.本記事はPhilip Walton氏の了承を得て翻訳された記事です。 原文はCSS Architectureにて掲載されています。CSSアーキテクチャ 多くのWebデベロッパとって、良いCSSとはビジュアルモックアップをコードで完全に再現できることを意味する。tableタグを使わず、また出来る限り画像を少なくすることに誇りを持つ。もしあなたが本当に優れたデベロッパであれば、メディアクエリ、Transitions、Transformといった最新で偉大な技術をも使うことだろう。 これらすべてが良いCSSデベロッパに必要なすべてであることは確かではあるものの、ス
クックパッドとマイクロサービス - クックパッド開発者ブログ
技術部の高井です。 最近、日本でもマイクロサービスという言葉が流行しつつあります。 今回は、なぜクックパッドがマイクロサービスを選択したのか、また実際にどのようなやり方をしているのかということを紹介します。 Conwayの法則 ここ数年の間、クックパッドはレシピの投稿・検索サービスから「食を中心とした生活のインフラ」として事業領域を拡大しつつあります。海外レシピサービスの買収による海外展開は、単なる金銭的な関係にとどまらず、人的・技術的な交流も含めて本格化しつつあります。また、「モバイルファースト」を標語とするモバイルアプリケーションへの取り組みも加速してきました。 事業領域の拡大やグローバル展開、モバイルファーストといったビジネス要求の変化に応じて、会社の組織構造も変化しています。そして、Conwayの法則 として知られているように、組織構造とソフトウェアアーキテクチャには密接な関係があ
Medium’s CSS is actually pretty f***ing good.
I always believe that to be the best, you have to smell like the best, dress like the best, act like the best. When you throw your trash in the garbage can, it has to be better than anybody else who ever threw trash in the garbage can. — Lil Wayne The best at drawing pictures of myselfI’ve been meaning to write something about the CSS at Medium for a while because I’m not completely ashamed of it…
Modern Java Web / SPA Development
JJUG CCC 2014 Spring の発表資料です。
A Look at Different Sass Architectures — SitePoint
As the size and complexity of a project grows, you require some sort of logic to structure your Sass files. It helps to follow some agreed upon guidelines for creating files and folders when working in large teams and projects. Below is a review of some of the techniques in use today. Bootstrap-sass Bootstrap’s intention is to be a UI library for web developers to quickly get off the ground. It is
長期かつ修正頻度の高いPJでのCSSメンテ - ワザノバ | wazanova
http://benfrain.com/enduring-css-writing-style-sheets-rapidly-changing-long-lived-projects/ 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約2時間前 長期的な大規模プロジェクト、かつ修正頻度が高い場合は、DRYよりはメンテ性を最優先にしたCSSを書くべきという、Ben Frainの方法論です。長文ですが、よくまとまってると思います。 1) テクノロジーとツール プレプロセッサ 長期のプロジェクトにおいて重要なのは、テクノロジーではなく、何ができて、どう進めるかというアプローチ。 Sass / LESS / Stylus / Myth などどれでも、しっかり書かれていれば、必要なときにいつでも統合はできる。プレプロセッサは
CodePen: CSSの構成と方針 - ワザノバ | wazanova
http://codepen.io/chriscoyier/blog/codepens-css 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約5時間前 GitHubやLonely Planetに触発されて、この手のエントリーが続いています。今回は、CodePenのChris Coyierのブログ。 Overview SCSS Autoprefixer RailsのAsset Pipeline スタイルの方針はあるが、目的はほぼ見た目の整合性をとるため 「classを多用する」以外に、アーキテクチャは採用していない ページ当たり、2-3個のCSSファイル media queryの@mixinを使うが、.scssファイルごとにオンオフできるようにしている コメントを残すのには賛成派 Preprocessing S
Lonely Planet & GitHub: CSSの構成と方針 - ワザノバ | wazanova
http://ianfeather.co.uk/css-at-lonely-planet/ 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約5時間前 CSS STATSが話題になったからでしょうか、自社のCSSの構成を分析して、記述方針について紹介するポストが続いています。 1) Lonely Planet Lonely Planetは旅行サイトらしく、写真/動画満載の構成です。 Quick Facts Sass Indented Syntax 150+ソースファイル キャッシュを考慮してコンパイルしたCSSは二つのスタイルシートに CSSはページ当たり35kb (gzip) 基本的には、remとpixelでサイズ指定。一部 em あり。 Preprocessor Railsを使っているが、Sprocketsは
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
技術的負債と向き合う
GitHub - jareware/css-architecture: 8 simple rules for a robust, scalable CSS architecture
Serverless Architecture
