Comments for stonean http://blog.stonean.com Thu, 26 Nov 2009 22:54:35 +0000 http://wordpress.com/ hourly 1 Comment on Views deserve thought by alampiogils http://blog.stonean.com/2009/11/10/views-deserve-thought/#comment-171 alampiogils Thu, 26 Nov 2009 22:54:35 +0000 http://blog.stonean.com/?p=314#comment-171 Cool post, did not thought reading this would be so great when I read your url! Cool post, did not thought reading this would be so great when I read your url!

]]> Comment on Views deserve thought by Colin Curtin http://blog.stonean.com/2009/11/10/views-deserve-thought/#comment-170 Colin Curtin Wed, 18 Nov 2009 19:41:44 +0000 http://blog.stonean.com/?p=314#comment-170 It reminds me of Meta-HTML: http://metahtml.sourceforge.net/ Docs: http://metahtml.sourceforge.net/documentation/manual/ Made by Brian Fox (creator of Bash), it was a precursor even to ColdFusion. Custom tags that controlled execution flow, defined variables, etc. RuHL looks like a cool project. Good work. It reminds me of Meta-HTML: http://metahtml.sourceforge.net/

Docs: http://metahtml.sourceforge.net/documentation/manual/

Made by Brian Fox (creator of Bash), it was a precursor even to ColdFusion. Custom tags that controlled execution flow, defined variables, etc.

RuHL looks like a cool project. Good work.

]]> Comment on Using ensure to reset a value by Bill Siggelkow http://blog.stonean.com/2009/04/25/using-ensure-to-reset-a-value/#comment-163 Bill Siggelkow Sat, 25 Apr 2009 20:33:37 +0000 http://blog.stonean.com/?p=296#comment-163 Oh I see! The ensure block is run regardless -- resetting @updated_path to @path.dup; but the changed @updated_path is returned from the call ... very interesting albeit a bit confusing. It saves having to create tmp variables. Oh I see! The ensure block is run regardless — resetting @updated_path to @path.dup; but the changed @updated_path is returned from the call … very interesting albeit a bit confusing. It saves having to create tmp variables.

]]> Comment on Using ensure to reset a value by stonean http://blog.stonean.com/2009/04/25/using-ensure-to-reset-a-value/#comment-161 stonean Sat, 25 Apr 2009 17:57:38 +0000 http://blog.stonean.com/?p=296#comment-161 Actually, the call to updated_path will return the value of @updated_path. The ensure statement will then reset @updated_path to the original value. For instance: new_path = add_key_value_to_path('miles','50') As add_key_value_to_path does it's thing, it updates @updated_path. The last line in add_key_value_to_path is the updated_path call. This will correctly return the value that new_path should get and reset @updated_path. Ready for the next iteration. No exceptions are involved. Ensure is being used for it's order of execution. Actually, the call to updated_path will return the value of @updated_path. The ensure statement will then reset @updated_path to the original value.

For instance:

new_path = add_key_value_to_path(‘miles’,'50′)

As add_key_value_to_path does it’s thing, it updates @updated_path. The last line in add_key_value_to_path is the updated_path call. This will correctly return the value that new_path should get and reset @updated_path. Ready for the next iteration.

No exceptions are involved. Ensure is being used for it’s order of execution.

]]> Comment on Using ensure to reset a value by Bill Siggelkow http://blog.stonean.com/2009/04/25/using-ensure-to-reset-a-value/#comment-160 Bill Siggelkow Sat, 25 Apr 2009 17:50:02 +0000 http://blog.stonean.com/?p=296#comment-160 Hmmm ... will @updated_path return an error? I thought ensure would only be fired if an exception was raised. If it's just that it could be nil then you could ||= ... Oh I think I understand ... the first ref to @updated_path should be to the method call updated_path ... then the ensure block will be executed if an exception is raised ... nice! Hmmm … will @updated_path return an error? I thought ensure would only be fired if an exception was raised.

If it’s just that it could be nil then you could ||= …

Oh I think I understand … the first ref to @updated_path should be to the method call updated_path … then the ensure block will be executed if an exception is raised … nice!

]]> Comment on Convention of Configuration by stonean http://blog.stonean.com/2009/03/06/convention-of-configuration/#comment-123 stonean Sat, 07 Mar 2009 19:00:20 +0000 http://blog.stonean.com/?p=258#comment-123 Thanks Lark! I really enjoyed the discussion and thought it was worthy of the public forum. Hopefully it's something others agree on or have already done privately and support this type configuration change within Rails. Thanks Lark! I really enjoyed the discussion and thought it was worthy of the public forum. Hopefully it’s something others agree on or have already done privately and support this type configuration change within Rails.

]]> Comment on Convention of Configuration by Jon Larkowski http://blog.stonean.com/2009/03/06/convention-of-configuration/#comment-122 Jon Larkowski Sat, 07 Mar 2009 18:45:16 +0000 http://blog.stonean.com/?p=258#comment-122 Thanks for typing this up. Glad to see you advocating this publicly after the conversation we had. Hope some people are convinced. Thanks for typing this up. Glad to see you advocating this publicly after the conversation we had. Hope some people are convinced.

]]> Comment on Convention of Configuration by stonean http://blog.stonean.com/2009/03/06/convention-of-configuration/#comment-120 stonean Sat, 07 Mar 2009 02:55:37 +0000 http://blog.stonean.com/?p=258#comment-120 Hey Phil! I don't have anything against config files like YAML. It's only an issue when they contain environment sections like database.yml. For each additional file that has its own environment sections you are creating another potential failure point when it comes to environment configuration. None of this is probably an issue with small teams. When you involve multiple dev teams and a separate infrastructure team, this convention is very, very helpful. Hey Phil!
I don’t have anything against config files like YAML. It’s only an issue when they contain environment sections like database.yml. For each additional file that has its own environment sections you are creating another potential failure point when it comes to environment configuration.

None of this is probably an issue with small teams. When you involve multiple dev teams and a separate infrastructure team, this convention is very, very helpful.

]]> Comment on Convention of Configuration by Phil http://blog.stonean.com/2009/03/06/convention-of-configuration/#comment-119 Phil Sat, 07 Mar 2009 02:42:17 +0000 http://blog.stonean.com/?p=258#comment-119 Heya Andy- I recently had a need to do something similar in one of my apps and I created a simple initializer that used an OpenStruct and a YAML::load passing the RAILS_ENV to get a particular section -- similar to how Rails does database.yml I believe. The idea isn't 100% mine -- read it somewhere (not sure where). I'm not sure if this is better or worse or just different. I agree it would be nice to have somewhere uniform to stash 'extra' config info though. Know any reasons to avoid OpenStruct or YAML in general? YAML just seems easier for the 'less experienced' to read and understand. Heya Andy- I recently had a need to do something similar in one of my apps and I created a simple initializer that used an OpenStruct and a YAML::load passing the RAILS_ENV to get a particular section — similar to how Rails does database.yml I believe. The idea isn’t 100% mine — read it somewhere (not sure where). I’m not sure if this is better or worse or just different. I agree it would be nice to have somewhere uniform to stash ‘extra’ config info though.

Know any reasons to avoid OpenStruct or YAML in general? YAML just seems easier for the ‘less experienced’ to read and understand.

]]> Comment on Cleaner Ruby by Kevin Menard http://blog.stonean.com/2009/02/03/cleaner-ruby/#comment-105 Kevin Menard Sat, 07 Feb 2009 17:34:03 +0000 http://blog.stonean.com/?p=207#comment-105 I can't say I agree with the 80 column rule. It made sense 10 years ago when I was writing C on a FreeBSD terminal, but now with at 23" display, 80 characters just wastes most of my screen. I tend to use whatever looks reasonable. One can normally tell an excessively long line upon inspection. I'm also not a huge fan of the newline escape to continue code onto the next line. I use it when necessary, but not something I make a habit of or want to. I can’t say I agree with the 80 column rule. It made sense 10 years ago when I was writing C on a FreeBSD terminal, but now with at 23″ display, 80 characters just wastes most of my screen. I tend to use whatever looks reasonable. One can normally tell an excessively long line upon inspection.

I’m also not a huge fan of the newline escape to continue code onto the next line. I use it when necessary, but not something I make a habit of or want to.

]]>