<?xml version="1.0" encoding="utf-8"?>
			
			<rss version="2.0">
			<channel>
			<title>Application Generation - Dynamic Programming</title>
			<link>http://www.pbell.com/index.cfm</link>
			<description>A series of occasional musings on architecting, securing, optimizing and generating web based applications. By Peter Bell.</description>
			<language>en-us</language>
			<pubDate>Fri, 24 May 2013 02:38:47 -0400</pubDate>
			<lastBuildDate>Thu, 01 Mar 2007 22:36:00 -0400</lastBuildDate>
			<generator>BlogCFC</generator>
			<docs>http://blogs.law.harvard.edu/tech/rss</docs>
			<managingEditor>test@test.com</managingEditor>
			<webMaster>test@test.com</webMaster>
			
			
			
			
			
			<item>
				<title>What Makes an Application?</title>
				<link>http://www.pbell.com/index.cfm/2007/3/1/What-Makes-an-Application</link>
				<description>
				
				It could be argued that the functional requirements for any system can be fully defined by its interfaces. As long as it provides the appropriate outputs for all inputs (taking into account persistent state) then by definition it meets the functional requirements for the app.

People have talked for a while now about using an interface driven approach to application specification. From FLiP to 37 Signals, From our Intent Driven Design to Clark Valbergs Interface Driven Architecture, the interface drives the application.

So, as a thought experiment, if the interface fully defines the application, why would we need to do anything more than describe the interfaces using a set of sufficiently descriptive DSLs and then press the button to allow the application to write itself?
				 [More]
				</description>
				
				<category>Dynamic Programming</category>
				
				<category>Design Patterns</category>
				
				<category>Domain Specific Languages</category>
				
				<pubDate>Thu, 01 Mar 2007 22:36:00 -0400</pubDate>
				<guid>http://www.pbell.com/index.cfm/2007/3/1/What-Makes-an-Application</guid>
				
			</item>
			
		 	
			
			
			<item>
				<title>Fun with Dynamic Programming</title>
				<link>http://www.pbell.com/index.cfm/2007/2/25/Fun-with-Dynamic-Programming</link>
				<description>
				
				Just having fun with a little bit of metaprogramming. Often you want to add a bunch of &quot;me too&quot; methods to your application. For example, you might want to have a bunch of methods called things like getAdminList(), getDefaultList(), getSpecialList(), etc. 

You could code them all in full, but that is so 1990s. You could generate the code, but even with active regeneration it is still sitting there, a class of errors just waiting to happen. I though it might be nice to allow for the specification of such &quot;me too&quot; methods as metadata that could then be dynamically processed (can always refactor to code generation later if necessary) . . .
				 [More]
				</description>
				
				<category>Dynamic Programming</category>
				
				<pubDate>Sun, 25 Feb 2007 19:15:00 -0400</pubDate>
				<guid>http://www.pbell.com/index.cfm/2007/2/25/Fun-with-Dynamic-Programming</guid>
				
			</item>
			
		 	
			</channel></rss>
	

