Comments for Peter Williams http://barelyenough.org … and there is much to be learned Sun, 18 Jul 2010 13:33:53 +0000 http://wordpress.org/?v=2.9.2 hourly 1 Comment on Ruby Backtraces by Peter Williams http://barelyenough.org/blog/2005/04/ruby-backtraces/comment-page-1/#comment-84715 Peter Williams Sun, 18 Jul 2010 13:33:53 +0000 http://pezra.barelyenough.org/blog/2005/04/ruby-backtraces/#comment-84715 <p>Asher,</p> <p>Very cool. It is good to know that you can achieve that sort of thing in user space with the 1.9 vm.</p> Asher,

Very cool. It is good to know that you can achieve that sort of thing in user space with the 1.9 vm.

]]> Comment on Ruby Backtraces by Asher http://barelyenough.org/blog/2005/04/ruby-backtraces/comment-page-1/#comment-84705 Asher Sun, 18 Jul 2010 08:21:32 +0000 http://pezra.barelyenough.org/blog/2005/04/ruby-backtraces/#comment-84705 <p>I put together a gem to address this with Ruby >= 1.9</p> <p>gem install sender</p> <p>Adds a number of functions including object oriented backtrace (Kernel.backtrace), backtrace_includes? each_backtrace_frame, <strong>sender</strong> and <strong>caller</strong>.</p> I put together a gem to address this with Ruby >= 1.9

gem install sender

Adds a number of functions including object oriented backtrace (Kernel.backtrace), backtrace_includes? each_backtrace_frame, sender and caller.

]]> Comment on Vertical Slicing by Peter Williams http://barelyenough.org/blog/2010/07/vertical-slicing/comment-page-1/#comment-84600 Peter Williams Tue, 13 Jul 2010 18:41:56 +0000 http://barelyenough.org/?p=466#comment-84600 <p>Devon,</p> <p>I apply DRY at the semantic level, rather than syntactic. Doing so makes it equivalent to SPOT, in my opinion. The formal definition of DRY is:</p> <blockquote> <p>Every piece of knowledge must have a single, unambiguous, authoritative representation within a system</p> </blockquote> <p>That seems quite the same as SPOT. (Without the unsavory implication that anything like truth can occur in a computer program.)</p> <p>I see your point about the potential misapplication of DRY. It certainly has the potential to result in excessive complexity if applied incorrectly. However, in my experience, it is far more common for it to be under applied, or ignored entirely, than to be applied at the wrong level.</p> Devon,

I apply DRY at the semantic level, rather than syntactic. Doing so makes it equivalent to SPOT, in my opinion. The formal definition of DRY is:

Every piece of knowledge must have a single, unambiguous,
authoritative representation within a system

That seems quite the same as SPOT. (Without the unsavory implication that anything like truth can occur in a computer program.)

I see your point about the potential misapplication of DRY. It certainly has the potential to result in excessive complexity if applied incorrectly. However, in my experience, it is far more common for it to be under applied, or ignored entirely, than to be applied at the wrong level.

]]> Comment on Vertical Slicing by Devon Jones http://barelyenough.org/blog/2010/07/vertical-slicing/comment-page-1/#comment-84599 Devon Jones Tue, 13 Jul 2010 15:22:53 +0000 http://barelyenough.org/?p=466#comment-84599 <p>I quite agree. My only area of significant difference is that I prefer to aim for SPOT (single point of truth) as opposed to DRY. My contention is that when people try to overgeneralize code so that no code is ever repeated, that code becomes inherently more complicated. If instead you target a system having a SPOT for each piece of data or process, you ensure avoiding connascence of algorithm while allowing the code in each piece to be as simple as possible. IMHO DRY drives code complexity in ways that SPOT does not. Worded another way, sometimes a little repetition is preferred.</p> I quite agree. My only area of significant difference is that I prefer to aim for SPOT (single point of truth) as opposed to DRY. My contention is that when people try to overgeneralize code so that no code is ever repeated, that code becomes inherently more complicated. If instead you target a system having a SPOT for each piece of data or process, you ensure avoiding connascence of algorithm while allowing the code in each piece to be as simple as possible. IMHO DRY drives code complexity in ways that SPOT does not. Worded another way, sometimes a little repetition is preferred.

]]> Comment on Vertical Slicing by Kevin Weller http://barelyenough.org/blog/2010/07/vertical-slicing/comment-page-1/#comment-84588 Kevin Weller Mon, 12 Jul 2010 23:37:09 +0000 http://barelyenough.org/?p=466#comment-84588 <p>Nicely put. However, vertical and horizontal slicing are not mutually exclusive...they can be effectively combined.</p> Nicely put. However, vertical and horizontal slicing are not mutually exclusive…they can be effectively combined.

]]> Comment on Vertical Slicing by Tweets that mention Peter Williams - Vertical Slicing -- Topsy.com http://barelyenough.org/blog/2010/07/vertical-slicing/comment-page-1/#comment-84584 Tweets that mention Peter Williams - Vertical Slicing -- Topsy.com Mon, 12 Jul 2010 17:27:25 +0000 http://barelyenough.org/?p=466#comment-84584 <p>[...] This post was mentioned on Twitter by Jim Ray. Jim Ray said: RT @pezra: New blog post: Vertical slicing http://barelyenough.org/blog/2010/07/vertical-slicing [...]</p> [...] This post was mentioned on Twitter by Jim Ray. Jim Ray said: RT @pezra: New blog post: Vertical slicing http://barelyenough.org/blog/2010/07/vertical-slicing [...]

]]> Comment on Hypermedia as the Engine of Application State by Peter Williams - Vertical Slicing http://barelyenough.org/blog/2007/05/hypermedia-as-the-engine-of-application-state/comment-page-1/#comment-84582 Peter Williams - Vertical Slicing Mon, 12 Jul 2010 15:39:04 +0000 http://pezra.barelyenough.org/blog/2007/05/hypermedia-as-the-engine-of-application-state/#comment-84582 <p>[...] design can introduce excessive coupling which will eat up most of the advantages described above. Hypermedia – or more precisely, following the REST architectural style – is the best way i know to [...]</p> [...] design can introduce excessive coupling which will eat up most of the advantages described above. Hypermedia – or more precisely, following the REST architectural style – is the best way i know to [...]

]]> Comment on Small pieces by Peter Williams - Vertical Slicing http://barelyenough.org/blog/2009/09/small-pieces/comment-page-1/#comment-84576 Peter Williams - Vertical Slicing Mon, 12 Jul 2010 02:57:36 +0000 http://barelyenough.org/?p=397#comment-84576 <p>[...] am a fan of polylithic architectures. Such architectures have many advantages related to enhancing evolvability and maintainability. [...]</p> [...] am a fan of polylithic architectures. Such architectures have many advantages related to enhancing evolvability and maintainability. [...]

]]> Comment on Mercurial and Perforce by Johan Walles http://barelyenough.org/blog/2006/08/mercurial-and-perforce/comment-page-1/#comment-83957 Johan Walles Thu, 10 Jun 2010 14:01:30 +0000 http://pezra.barelyenough.org/blog/?p=250#comment-83957 <p>If directory tracking is important to you in a VCS you may want to have a look at Bazaar:</p> <p>http://doc.bazaar.canonical.com/migration/en/why-switch-to-bazaar.html#rename-tracking-and-smart-merging</p> If directory tracking is important to you in a VCS you may want to have a look at Bazaar:

http://doc.bazaar.canonical.com/migration/en/why-switch-to-bazaar.html#rename-tracking-and-smart-merging

]]> Comment on Unobtrusive link info by Peter Williams http://barelyenough.org/blog/2010/01/unobtrusive-link-info/comment-page-1/#comment-83921 Peter Williams Tue, 08 Jun 2010 16:43:26 +0000 http://barelyenough.org/?p=416#comment-83921 <p>Reda B.,</p> <p>There are advantages of using a standard link mechanism, such as a atom:link element or a xlink attribute. Using standardized linking structures allow clients that do not understand the semantics of your doctype to extract some link related information. Such standardization should allow libraries to be built that are less media type specific, and therefore more reusable.</p> <p>That being said i think that the <code>Link</code> header field is a better way to deal with the sorts of links that benefit from standardization.</p> Reda B.,

There are advantages of using a standard link mechanism, such as a atom:link element or a xlink attribute. Using standardized linking structures allow clients that do not understand the semantics of your doctype to extract some link related information. Such standardization should allow libraries to be built that are less media type specific, and therefore more reusable.

That being said i think that the Link header field is a better way to deal with the sorts of links that benefit from standardization.

]]>