タグ

設計に関するyuutookunのブックマーク (6)

  • FLOCSSを使ってCSSファイルを20,000行から9,000行にした話 - Qiita

    入社して僕が最初にアサインされたのがこのプロジェクト。 サービスをスタートさせたのは今年の2月。最初は外注でとりあえずサービスを作ることに集中していたらしい... その結果、どのスタイルがどこに作用するか全く分からないCSSの魔境でした。 これでは簡単なページを追加するにも一苦労。 そこで、20,000行あるCSSファイルのリファクタリングに踏み切りました。 当時の問題 スタートアップのサービスなのでもっと機能を追加したり、変更したりしたいと言う要望は日に日に大きくなっていました。 一方で、実際に機能を作ったとしてもそれを view に反映させるのも日に日に苦しくなっていました。 僕たちを苦しめていた理由は以下の通りです。 どこにスタイルが作用しているか分からないので、CSSを安易に変更ができない。 新しい部品を付け足す時にCSSの影響範囲を考慮しなくてはならず、プロダクトのUI変更が困難

    FLOCSSを使ってCSSファイルを20,000行から9,000行にした話 - Qiita
  • Open-source tool that uses simple textual descriptions to draw beautiful UML diagrams.

    🚀 Getting Started PlantUML is a highly versatile tool that facilitates the rapid and straightforward creation of a wide array of diagrams. Utilizing a simple and intuitive language, users can effortlessly draft various types of diagrams. For a detailed exploration of the language's capabilities and syntax, please refer to the PlantUML Language Reference Guide. If you are new to PlantUML, we recom

    Open-source tool that uses simple textual descriptions to draw beautiful UML diagrams.
  • 持続可能な開発を目指す ~ ドメイン・ユースケース駆動(クリーンアーキテクチャ) + 単方向に制限した処理 + FRP

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事は、開発を持続可能にできるようなアーキテクチャとその適用方法を考察するものです。 骨子はできていますが、実装経験をフィードバックして詳細を若干変更するかもしれません。 勉強不足な点もあるので、意見を歓迎します。 開発においてよくある問題点 ビジネスロジックの質が何だったか見失う。ソースコードのどこまでが業務上の関心で、どこからがそれを実現するための技術上の関心か分からなくなる。 入出力双方向の処理が散在して処理が追い切れなくなる。特にイベント処理でどこに飛ぶかわからないコールバック地獄になる。 初期化・つなぎ込み・統合者的オブ

    持続可能な開発を目指す ~ ドメイン・ユースケース駆動(クリーンアーキテクチャ) + 単方向に制限した処理 + FRP
  • データモデルはドメインモデルに先行する - 設計者の発言

    関わっているあるプロジェクトで、Javaでのコンポーネントベース開発を進めるためのクラス図が出来上がりつつある。DDD(ドメイン駆動設計)に関心を持つ技術者にとってお手になるような端正なドメインモデルだ。それを眺めながら関係者がしみじみと感じていることがある。どんなに優秀なドメインエキスパートと組んだとしても、DDDにもとづいてこのモデルを「先に」生み出すことは不可能だっただろう。 どういうことか。我々はまず、泥臭い分析と設計を重ね、あるべきデータモデルを完成させた。そのうえで実装方式の専門家の協力を仰ぎ、クラス図が出来上がった。つまり、データモデルからドメインモデルが導かれたのであって、その逆ではない。じっさい、ドメインモデルからデータモデルを導くことが不可能であったことは、両者を並べたら一目瞭然なのであった。 これは重要な論点だ。データモデリングとドメインモデリングのどちらを先行させ

    データモデルはドメインモデルに先行する - 設計者の発言
  • 【第15回】段取りの四:スケジュール表を作成する

    < 前回 | 目次 | 次回 > 今回は、プロジェクトの“スケジュール表”を作成するというお話です。 材料として使うのは、前回作成した“作業リスト”。このリストで洗いだしたそれぞれの作業を、「誰が、いつからいつまで実施するのか」を計画し、紙に書いたものがスケジュール表です。 メンバーはこのスケジュール表に沿ってプロジェクトの作業を進めることになりますので、ここがしっかりしていないと後で問題が噴出することになってしまいます。慎重に慎重を重ねてスケジュールを組むこと、それはプロジェクトの計画における非常に重要なポイントと言えるのです。 スケジュール表の書き方 普段、皆さんは手帳を使ってご自身のスケジュールを管理されていることと思います。 プロジェクトにおけるスケジュール表もこれと基は同じですが、複数のメンバーの予定を1枚の紙に書くことになりますので、少々特別な書き方を用います。 とはいうもの

    【第15回】段取りの四:スケジュール表を作成する
  • Scalaコードでわかった気になるDDD | GREE Engineering

    みなさん、こんにちは。グリーのかとじゅん(@j5ik2o)です。 このエントリは GREE Advent Calendar 2013 の 18日目の記事です。よろしくお願いします。 私がグリーに入社してやっていることは、プログラミング言語 Scalaとドメイン駆動設計(以下、DDD)の布教活動です。布教活動といっても宣伝するだけでは具体性に欠けるので、実際に開発チームに入ってScalaやDDDの技術支援を行っています。エントリでは、Scalaを用いたDDDの設計と実装をどのように行っているかを、DDDを知らない人でもできるだけわかりやすく説明したいと思います(Scalaわかっていると読みやすいですが、あんまり複雑なコードは出てこないのでなんとなく読めるのではないかと思います)。なお、DDDの実践例は他にもあります。一例だと思って読んでいただければ幸いです(先日のSNSチームでのドメイン駆

    Scalaコードでわかった気になるDDD | GREE Engineering
  • 1