みんなのウェディングのCSS事情 — みんなのウェディングエンジニアリングブログ
こんにちは。みんなのウェディングの平岡です。 みんなのウェディングでは自社開発したCSSフレームワーク「Esthe（エステ）」を利用して開発をしています。 今回はそのEstheの簡単な説明と導入までの流れを紹介したいと思います。 導入前までに抱えていた問題 案件が発生する都度すべてのデザインを作成していたため、デザイナーの作業が増えていく デザインガイドラインがないため、コンテンツ作成毎にトンマナがずれていく CSSのルールがないため、どこから読まれているのかわからず解読＆確認に時間がかかる サービスの急激な伸びによる影響でCSS周りの整備まで手が回らず、 コンテンツの拡充に比例して日々メンテナンスコストが上がっている状態でした。 なんとかしたい サイトとして共通化されたデザインパーツがほしい デザインガイドラインがほしい 管理されたCSS環境がほしい bootstrap？ bootstr
みんなのウェディングの継続的デリバリー — みんなのウェディングエンジニアリングブログ
みんなのウェディングの高井です。今回は、みんなのウェディングで構築している継続的デリバリーの仕組みについての話です。 継続的デリバリーとは？ インターネットサービスを提供していくうえで、とても重要なプラクティスのひとつに「継続的デリバリー」があります。継続的デリバリーとは、ソフトウェアをいつでもリリース可能な状態にしたままで構築していくというソフトウェア開発の規律です。 継続的デリバリーを採用することで、ソフトウェアのリリースサイクルを短かくすることができるようになります。リリースサイクルを短かくすることは、サービスの仮説検証プロセスを短かくすることにつながります。 サービス開発の本質は、どこにあるのか分からないユーザーのニーズをとらえることにあります。ですから、仮説検証の機会を最大化できる継続的デリバリーはサービス開発にとって、欠かせないプラクティスとなるわけです。 完了条件を定義する
引数チェックの責務を設計する — みんなのウェディングエンジニアリングブログ
みんなのウェディングの高井です。今回のエントリも、若者との対話シリーズとなります。 あるオブジェクトが別のオブジェクトを呼び出すとき、受け渡される情報のチェックをどちらの責務で行なうかという問題があります。呼び出し側でチェックを行なうのがよいのでしょうか。それとも、呼び出され側でチェックを行なうのがよいのでしょうか。 この問題は、結局のところ設計の問題であり、ケース・バイ・ケースであるというのが正解になります。ですから、どのようにケースを見極めるのかという考え方が重要です。 信頼領域 『オブジェクトデザイン』には、この問題のヒントになるアイデアが書かれています。それが、「信頼領域」という考え方です。 信頼領域とは、システムを「信頼するコミュニケーションが発生する領域に切り分け」た領域のことです。システムは、ユーザーとユーザーインタフェースの境界、外部システムとの境界、異なるレイヤーとの境界
クラス設計の原則 — みんなのウェディングエンジニアリングブログ
みんなのウェディングの高井です。 クラスベースのオブジェクト指向プログラミング言語を利用している人であれば、クラスとは、ありふれていて普段から利用するものです。にもかかわらず、良いクラスをつくるというのは、なかなかに難しいことです。 先日、みんなのウェディングでアルバイトをしてくれている学生さんのコードレビューをしていたときにも、それを強く感じました。 実践的プラグマティックには「ソフトウェアの規模や文脈にあわせて、適切に抽象化していただきたい」という以上のことを言っても仕方がないところなのですが、それだけでは経験の浅いプログラマーにとって、まったく分からないという話になってしまいます。 というわけで、今回はクラス設計の原則についてのお話しです。 Bertrand Meyerのクラス設計の原則 Bertrand Meyerは『オブジェクト指向入門 第2版』の中で、クラス設計について章をひと
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
