Module: Utter::Utils

Defined in:
lib/generators/utils/tips.rb

Constant Summary collapse

@@design_qoutes =

Design qoutes

[
"Good Design Is Innovative ~ Dieter Rams",
"Good Design Makes a Product Useful ~ ",
"Good Design Is Aesthetic ~ ",
"Good Design Is Unobtrusive ~ ",
"Good Design Is Honest ~ ",
"Good Design Is Long-lasting ~ ",
"Good Design Is Thorough Down to the Last Detail ~ ",
"Good Design Is Environmentally Friendly ~ ",
"Good Design Is as Little Design as Possible ~ ",
"Good Design Makes A Product Understandable ~ "]
@@microservices_quotes =

Display microservices qoutes

[
"“The things you own end up owning you. It's only after you lose everything that you're free to do anything.” 
― Chuck Palahniuk, Fight Club #rails_must_die", 
 "Microservices are important simply because they add unique value in a way of simplification of complexity in systems.", 
"By breaking apart your system or application into many smaller parts, you show ways of reducing duplication, increasing cohesion and lowering your coupling between parts, thus making your overall system parts easier to understand, more scalable, and easier to change.",
"The downside of a distributed system is that it is always more complex from a systems standpoint. The overhead of many small services to manage is another factor to consider.", 
"One of the biggest problems with Microservices is the dependencies and challenges with designing services to not be all-in dependent on each other and the solutions to this."]
@@ddd_quotes =

Domain Driven Design qoutes

[
"“May I never be complete. May I never be content. May I never be perfect.” 
― Chuck Palahniuk, Fight Club", 
 "“The indirectness of communication conceals the formation of schisms—different team members use terms differently but don’t realize it.” 
	― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software",

	"“The effort of translation prevents the interplay of knowledge and ideas that lead to deep model insights.” 
	― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software",

	"“By using the model-based language pervasively and not being satisfied until it flows, we approach a model that is complete and comprehensible, made up of simple elements that combine to express complex ideas.” 
	― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software",

	"“Every software program relates to some activity or interest of its user.” 
	― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software",

	"“A model is a selectively simplified and consciously structured form of knowledge.” 
	― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software",

	"“Success comes in an emerging set of abstract concepts that makes sense of all the detail. This distillation is a rigorous expression of the particular knowledge that has been found most relevant.” 
	― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software",

	"“The heart of software is its ability to solve domain-related problems for its user.” 
	― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software",

	"“In the old waterfall method, the business experts talk to the analysts, and analysts digest and abstract and pass the result along to the programmers, who code the software. This approach fails because it completely lacks feedback.” 
	― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software",

	"“Knowledge trickles in one direction, but does not accumulate.” 
	― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software",

	"“That shallowness of knowledge produces software that does a basic job but lacks a deep connection to the domain expert’s way of thinking.” 
	― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software",

	"“Diagrams are a means of communication and explanation, and they facilitate brainstorming. They serve these ends best if they are minimal.” 
	― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software",

	"“They show design constraints, but they are not design specifications in every detail. They represent the skeletons of ideas.” 
	― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software",

	"“the model is not the diagram.” 
	― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software",

	"“The behavior of running code is unambiguous.” 
	― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software",

	"“documenting exclusively through code has some of the same basic problems as using comprehensive UML diagrams.” 
	― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software",

	"“A document shouldn’t try to do what the code already does well.” 
	― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software",

	"“Written documents should complement the code and the talking.” 
	― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software",

	"“you may hear the UBIQUITOUS LANGUAGE changing naturally while a document is being left behind.” 
	― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software",

	"“It takes fastidiousness to write code that doesn’t just do the right thing but also says the right thing.” 
	― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software",

	"“To communicate effectively, the code must be based on the same language used to write the requirements—the same language that the developers speak with each other and with domain experts.” 
	― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software",

	"“There is no need for explanatory models to be object models, and it is generally best if they are not.” 
	― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software",

	"“The astrolabe was a mechanical implementation of an object-oriented model of the sky.” 
	― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software",

	"“crucial discoveries always emerge during the design/implementation effort.” 
	― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software",

	"“If the design, or some central part of it, does not map to the domain model, that model is of little value, and the correctness of the software is suspect.” 
	― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software",

	"“The heart of software is its ability to solve domain-related problems for its user. All other features, vital though they may be, support this basic purpose. When the domain is complex, this is a difficult task, calling for the concentrated effort of talented and skilled people. Developers have to steep themselves in the domain to build up knowledge of the business. They must hone their modeling skills and master domain design. Yet these are not the priorities on most software projects. Most talented developers do not have much interest in learning about the specific domain in which they are working, much less making a major commitment to expand their domain-modeling skills. Technical people enjoy quantifiable problems that exercise their technical skills. Domain work is messy and demands a lot of complicated new knowledge that doesn’t seem to add to a computer scientist’s capabilities. Instead, the technical talent goes to work on elaborate frameworks, trying to solve domain problems with technology. Learning about and modeling the domain is left to others. Complexity in the heart of software has to be tackled head-on. To do otherwise is to risk irrelevance.” 
	― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software", 

	"“When we set out to write software, we never know enough.” 
	― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software", 

	"“The vital detail about the design is captured in the code. A well-written implementation should be transparent, revealing the model underlying it.” 
	― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software", 

	"“there should be some learning when a domain model is discussed.” 
	― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software", 


	"“The domain experts had learned more and had clarified the goal of the application.” 
	― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software", 

	"“The kind of knowledge captured in a model such as the PCB example goes beyond “find the nouns.” 
	― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software", 


	"“Business activities and rules are as central to a domain as are the entities involved; any domain will have various categories of concepts.” 
	― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software", 

	"“Knowledge crunching is an exploration, and you can’t know where you will end up.” 
	― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software", 


	"“Translation muddles model concepts, which leads to destructive refactoring of code.” 
	― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software" 
 ]

Class Method Summary collapse

Instance Method Summary collapse

Dynamic Method Handling

This class handles dynamic methods through the method_missing method

#method_missing(m, *args, &block) ⇒ Object 



140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
 
# File 'lib/generators/utils/tips.rb', line 140

def method_missing(m, *args, &block)  
  case m

  when :utter_banner 
	extend Thor::Shell
	utter_title		= set_color(" Utter ", :red, :on_white, :bold)
	utter_version 		= set_color(Utter::VERSION + " | ", :black, :on_white, :bold)
	#say(utter_title + utter_version )

	irc		   	= set_color("", :green, :on_white, :bold)
	irc_url 		= set_color("#utter @freenode.net" + " ", :green, :on_white, :bold)
	say(utter_title + utter_version + irc + irc_url)

	return # back to the calling routine	

  when :about_utter
	#say("Utter is a Domain-specific Microservices Framework written in Ruby for building both regular and advanced Rule-based web APIs")

  when :ddd_quotes
	quote = @@ddd_quotes.sample

  when :design_qoutes
	quote = @@design_quotes.sample

  when :microservices_quotes 
	quote = @@microservices_quotes.sample

  else
	puts " Utter doesn't know #{m} -- please try again."  
  end

  def wrap(s, width=75)
	s.gsub(/(.{1,#{width}})(\s+|\Z)/, "\\1\n")
  end

  say(wrap(quote))
end

Class Method Details

.included(klass) ⇒ Object 



4
5
6
 
# File 'lib/generators/utils/tips.rb', line 4

def self.included(klass)
  klass.extend self 
end

Instance Method Details

#wrap(s, width = 75) ⇒ Object 



171
172
173
 
# File 'lib/generators/utils/tips.rb', line 171

def wrap(s, width=75)
	s.gsub(/(.{1,#{width}})(\s+|\Z)/, "\\1\n")
end