<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: Dr Nic&#8217;s Magic Show at RejectConf2007</title>
	<atom:link href="http://drnicwilliams.com/2007/05/23/dr-nics-magic-show-at-rejectconf2007/feed/" rel="self" type="application/rss+xml" />
	<link>http://drnicwilliams.com/2007/05/23/dr-nics-magic-show-at-rejectconf2007/</link>
	<description>Ruby makes Rails, Javascript makes Ajax, Dr Nic makes Magic</description>
	<pubDate>Sun, 20 Jul 2008 09:00:18 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5.1</generator>
		<item>
		<title>By: Back From RailsConf Europe &#187; Viget&#8217;s Four Labs</title>
		<link>http://drnicwilliams.com/2007/05/23/dr-nics-magic-show-at-rejectconf2007/#comment-46551</link>
		<dc:creator>Back From RailsConf Europe &#187; Viget&#8217;s Four Labs</dc:creator>
		<pubDate>Sun, 23 Sep 2007 03:11:35 +0000</pubDate>
		<guid isPermaLink="false">http://drnicwilliams.com/2007/05/23/dr-nics-magic-show-at-rejectconf2007/#comment-46551</guid>
		<description>[...] Metaprogramming &#8211; Fresh off his RejectConf performance in Portland, Dr. Nic discussed some great metaprogramming techniques in Ruby and demo&#8217;ed his Magic Model Generator plugin as well as some controversial uses of metaprogramming. [...]</description>
		<content:encoded><![CDATA[<p>[...] Metaprogramming &ndash; Fresh off his RejectConf performance in Portland, Dr. Nic discussed some great metaprogramming techniques in Ruby and demo&#8217;ed his Magic Model Generator plugin as well as some controversial uses of metaprogramming. [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dr Nic</title>
		<link>http://drnicwilliams.com/2007/05/23/dr-nics-magic-show-at-rejectconf2007/#comment-34661</link>
		<dc:creator>Dr Nic</dc:creator>
		<pubDate>Thu, 28 Jun 2007 07:26:24 +0000</pubDate>
		<guid isPermaLink="false">http://drnicwilliams.com/2007/05/23/dr-nics-magic-show-at-rejectconf2007/#comment-34661</guid>
		<description>@craig - yep a patch is fine, assuming its a parameter or something to select which of the two generate methods are activated.</description>
		<content:encoded><![CDATA[<p>@craig - yep a patch is fine, assuming its a parameter or something to select which of the two generate methods are activated.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Craig Buchek</title>
		<link>http://drnicwilliams.com/2007/05/23/dr-nics-magic-show-at-rejectconf2007/#comment-34580</link>
		<dc:creator>Craig Buchek</dc:creator>
		<pubDate>Wed, 27 Jun 2007 17:37:29 +0000</pubDate>
		<guid isPermaLink="false">http://drnicwilliams.com/2007/05/23/dr-nics-magic-show-at-rejectconf2007/#comment-34580</guid>
		<description>I was going to suggest something very similar to Jack Nutting's idea. I don't think I would use MMG without it. Would you be willing to accept a patch? I'll probably use Jack's method of opening the class in both files, instead of using a base class, as it requires the least changes to existing model code.</description>
		<content:encoded><![CDATA[<p>I was going to suggest something very similar to Jack Nutting&#8217;s idea. I don&#8217;t think I would use MMG without it. Would you be willing to accept a patch? I&#8217;ll probably use Jack&#8217;s method of opening the class in both files, instead of using a base class, as it requires the least changes to existing model code.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Matt Scilipoti</title>
		<link>http://drnicwilliams.com/2007/05/23/dr-nics-magic-show-at-rejectconf2007/#comment-26960</link>
		<dc:creator>Matt Scilipoti</dc:creator>
		<pubDate>Sun, 27 May 2007 04:29:56 +0000</pubDate>
		<guid isPermaLink="false">http://drnicwilliams.com/2007/05/23/dr-nics-magic-show-at-rejectconf2007/#comment-26960</guid>
		<description>Looking for a tool to resolve conflicts?  Check out TortoiseSVN (http://tortoisesvn.tigris.org/TortoiseMerge.html#merge).  When a conflict is encountered during a svn update, the 'resolve conflict' menu choice opens a tool displaying three versions of the file: the original, the repo head, and the working copy.  It also indicates which merges can be handled automatically and which require manual intervention.  You can use either the included TortoiseMerge or an external tool.  Until recently, I would have recommended KDiff3. Recent updates have made the internal merge tool almost as slick and it now includes a 'mark as resolved' action.  Sweet.  I highly recommend you review TortoiseSVN.  Disclaimer: no amphibians (or furry, bipedal mammals) were harmed, or compensated, during the making of this commercial.</description>
		<content:encoded><![CDATA[<p>Looking for a tool to resolve conflicts?  Check out TortoiseSVN (http://tortoisesvn.tigris.org/TortoiseMerge.html#merge).  When a conflict is encountered during a svn update, the &#8216;resolve conflict&#8217; menu choice opens a tool displaying three versions of the file: the original, the repo head, and the working copy.  It also indicates which merges can be handled automatically and which require manual intervention.  You can use either the included TortoiseMerge or an external tool.  Until recently, I would have recommended KDiff3. Recent updates have made the internal merge tool almost as slick and it now includes a &#8216;mark as resolved&#8217; action.  Sweet.  I highly recommend you review TortoiseSVN.  Disclaimer: no amphibians (or furry, bipedal mammals) were harmed, or compensated, during the making of this commercial.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jeroen Janssen</title>
		<link>http://drnicwilliams.com/2007/05/23/dr-nics-magic-show-at-rejectconf2007/#comment-26431</link>
		<dc:creator>Jeroen Janssen</dc:creator>
		<pubDate>Thu, 24 May 2007 16:40:39 +0000</pubDate>
		<guid isPermaLink="false">http://drnicwilliams.com/2007/05/23/dr-nics-magic-show-at-rejectconf2007/#comment-26431</guid>
		<description>I found a (very old?) ruby project http://rubyforge.org/projects/merge3/ with the description "Merge3 is a 3 way merge for text/binary files. It works similar to diff3 but uses move/insert instructions to merge cases diff3 can't."

Maybe this can be used without requiring a seperate diff/merge tool?</description>
		<content:encoded><![CDATA[<p>I found a (very old?) ruby project <a href="http://rubyforge.org/projects/merge3/" rel="nofollow">http://rubyforge.org/projects/merge3/</a> with the description &#8220;Merge3 is a 3 way merge for text/binary files. It works similar to diff3 but uses move/insert instructions to merge cases diff3 can&#8217;t.&#8221;</p>
<p>Maybe this can be used without requiring a seperate diff/merge tool?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dr Nic</title>
		<link>http://drnicwilliams.com/2007/05/23/dr-nics-magic-show-at-rejectconf2007/#comment-26369</link>
		<dc:creator>Dr Nic</dc:creator>
		<pubDate>Thu, 24 May 2007 07:55:36 +0000</pubDate>
		<guid isPermaLink="false">http://drnicwilliams.com/2007/05/23/dr-nics-magic-show-at-rejectconf2007/#comment-26369</guid>
		<description>@jack + akita - I think support for a generated base model and a "free to edit" subclass model is a nice solution; and I've also seen it implemented elsewhere.

Ultimately the two solutions can co-exists, because "m"erge is an option to be selected when a conflict is found; 

Where as support for generated base classes is specific to generated files that include a single Ruby class, such as models/controllers, but not other types of generated content.

That is, it will be more complicated to implement, but certainly can be implemented in addition to offering merging as an option for conflict resolution.</description>
		<content:encoded><![CDATA[<p>@jack + akita - I think support for a generated base model and a &#8220;free to edit&#8221; subclass model is a nice solution; and I&#8217;ve also seen it implemented elsewhere.</p>
<p>Ultimately the two solutions can co-exists, because &#8220;m&#8221;erge is an option to be selected when a conflict is found; </p>
<p>Where as support for generated base classes is specific to generated files that include a single Ruby class, such as models/controllers, but not other types of generated content.</p>
<p>That is, it will be more complicated to implement, but certainly can be implemented in addition to offering merging as an option for conflict resolution.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: AkitaOnRails</title>
		<link>http://drnicwilliams.com/2007/05/23/dr-nics-magic-show-at-rejectconf2007/#comment-26313</link>
		<dc:creator>AkitaOnRails</dc:creator>
		<pubDate>Wed, 23 May 2007 23:52:37 +0000</pubDate>
		<guid isPermaLink="false">http://drnicwilliams.com/2007/05/23/dr-nics-magic-show-at-rejectconf2007/#comment-26313</guid>
		<description>Hey, this is nice. Jack's multiple file approach reminds me of an old Eclipse plugin for Hibernate called Hibernate Synchronizer. It did something similar: if the model is called Trick, it would create a class Trick that extends from a BaseTrick. If regeneration was needed only the Base* classes were overwritten leaving all the user logic secure.

I feel a little bit awkward about the revision based original/new/old approach. In a normal situation I would see dozens of models and several dozens .new and .old files spread out. And what happens when you regenerate again before fixing the conflicts? Maybe a multiple file or multiple class approach would be easier to handle?</description>
		<content:encoded><![CDATA[<p>Hey, this is nice. Jack&#8217;s multiple file approach reminds me of an old Eclipse plugin for Hibernate called Hibernate Synchronizer. It did something similar: if the model is called Trick, it would create a class Trick that extends from a BaseTrick. If regeneration was needed only the Base* classes were overwritten leaving all the user logic secure.</p>
<p>I feel a little bit awkward about the revision based original/new/old approach. In a normal situation I would see dozens of models and several dozens .new and .old files spread out. And what happens when you regenerate again before fixing the conflicts? Maybe a multiple file or multiple class approach would be easier to handle?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dr Nic</title>
		<link>http://drnicwilliams.com/2007/05/23/dr-nics-magic-show-at-rejectconf2007/#comment-26294</link>
		<dc:creator>Dr Nic</dc:creator>
		<pubDate>Wed, 23 May 2007 22:21:52 +0000</pubDate>
		<guid isPermaLink="false">http://drnicwilliams.com/2007/05/23/dr-nics-magic-show-at-rejectconf2007/#comment-26294</guid>
		<description>There is now a &lt;a href="http://dev.rubyonrails.org/ticket/8439" rel="nofollow" rel="nofollow" rel="nofollow" rel="nofollow"&gt;patch available&lt;/a&gt; for edge rails to support merging for generators if you wish to test drive it.

To patch your edge rails:

&lt;pre&gt;cd /vendor
curl http://dev.rubyonrails.org/attachment/ticket/8439/generator_merging.patch?format=txt &gt; generator_merging.patch
patch -p 0 &lt; generator_merging.patch
&lt;/pre&gt;

And go.

&lt;strong&gt;Windows users&lt;/strong&gt;: you'll need to install cygwin and the &lt;code&gt;diff3&lt;/code&gt; application, and add it to your path.</description>
		<content:encoded><![CDATA[<p>There is now a <a href="http://dev.rubyonrails.org/ticket/8439" rel="nofollow" rel="nofollow" rel="nofollow" rel="nofollow">patch available</a> for edge rails to support merging for generators if you wish to test drive it.</p>
<p>To patch your edge rails:</p>
<pre>cd /vendor
curl <a href="http://dev.rubyonrails.org/attachment/ticket/8439/generator_merging.patch?format=txt" rel="nofollow">http://dev.rubyonrails.org/attachment/ticket/8439/generator_merging.patch?format=txt</a> > generator_merging.patch
patch -p 0 < generator_merging.patch
</pre>
<p>And go.</p>
<p><strong>Windows users</strong>: you&#8217;ll need to install cygwin and the <code>diff3</code> application, and add it to your path.</pre>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dr Nic</title>
		<link>http://drnicwilliams.com/2007/05/23/dr-nics-magic-show-at-rejectconf2007/#comment-26201</link>
		<dc:creator>Dr Nic</dc:creator>
		<pubDate>Wed, 23 May 2007 13:09:45 +0000</pubDate>
		<guid isPermaLink="false">http://drnicwilliams.com/2007/05/23/dr-nics-magic-show-at-rejectconf2007/#comment-26201</guid>
		<description>@Mat - there are TOOLS to resolve conflicts? I need to get my hands on them. I haven't found a nice way to use TextMate to find and resolve conflicts yet. But it never occurred to me til now that there might be such tools. Certainly navigating between conflict regions in a project sounds handy at the very least.</description>
		<content:encoded><![CDATA[<p>@Mat - there are TOOLS to resolve conflicts? I need to get my hands on them. I haven&#8217;t found a nice way to use TextMate to find and resolve conflicts yet. But it never occurred to me til now that there might be such tools. Certainly navigating between conflict regions in a project sounds handy at the very least.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mat Schaffer</title>
		<link>http://drnicwilliams.com/2007/05/23/dr-nics-magic-show-at-rejectconf2007/#comment-26200</link>
		<dc:creator>Mat Schaffer</dc:creator>
		<pubDate>Wed, 23 May 2007 13:06:13 +0000</pubDate>
		<guid isPermaLink="false">http://drnicwilliams.com/2007/05/23/dr-nics-magic-show-at-rejectconf2007/#comment-26200</guid>
		<description>I don't know how possible this is, but it could be really nice if your 3 file approach somehow matched the way SVN outputs its files.  Then people would have a shot at resolving generator conflicts with the same tools they use to resolve regular code conflicts.

As always, Great work Dr. Nic!</description>
		<content:encoded><![CDATA[<p>I don&#8217;t know how possible this is, but it could be really nice if your 3 file approach somehow matched the way SVN outputs its files.  Then people would have a shot at resolving generator conflicts with the same tools they use to resolve regular code conflicts.</p>
<p>As always, Great work Dr. Nic!</p>
]]></content:encoded>
	</item>
</channel>
</rss>
