joeyDotNet - All Comments

re: Looking for some awesome .NET developers (work from home)

V. — Tue, 30 Sep 2008 17:54:14 GMT

Bad thing that www.careerbuilder.com isn't working... );

re: Looking for some awesome .NET developers (work from home)

V. — Mon, 29 Sep 2008 17:24:50 GMT

Tell me people can work from Brazil. (;

I´m gonna apply anyway. lol

re: Looking for some awesome .NET developers (work from home)

Tom Opgenorth — Sun, 28 Sep 2008 02:37:53 GMT

Dang. Where was this posting about six weeks ago when I was looking. Now I'm tied up until March, 2009.

re: Looking for some awesome .NET developers (work from home)

Chris Stewart — Sun, 28 Sep 2008 01:45:01 GMT

Thanks for posting this, I just submitted my resume. I'm also in Richmond, VA by the way.

re: MVC - Free Yourself from Web Forms!

Bryan Reynolds — Sat, 06 Sep 2008 14:01:24 GMT

Been working with MVC for about 2 weeks. Love it!

re: NHibernate Mapping Validation Tool?

Oran — Tue, 18 Mar 2008 01:48:23 GMT

Is this what you're looking for?

www.ayende.com/.../7360.aspx

re: ActiveSupport.NET - Namespace Overhaul

joeyDotNet — Sat, 09 Feb 2008 14:57:01 GMT

Yeah, I guess my vision for AS.NET is actually to keep it pretty small and focused on simply language extensions. Looking at the current ActiveSupport library for Ruby, the vast majority of features is in their "CoreExtensions" namespace. There are a couple other things like some JSON utils, which may or may not make it into AS.NET, but we'll see... :)

What would you like to see included in AS.NET besides the language extensions?

re: ActiveSupport.NET - Namespace Overhaul

chadmyers — Sat, 09 Feb 2008 11:24:11 GMT

The only thing with that is that if you ever add anything else to ActiveSupport beyond extensions, you will run into problems with the namespaces again.

How 'bout:

using ActiveSupport.Ext;

using ActiveSupport.Ext.Access;

using ActiveSupport.Ext.Conversions;

Better yet, if you have things like: Date/Time concerns (that involve System.DateTime, System.Int32, System.String):

using ActiveSupport.Ext.DateAndTime;

String Canonical concerns (which may involve ext methods on System.String, System.Int32, System.DateTime, etc)?

using ActiveSupport.Ext.StringCanonical;

re: Introducing ActiveSupport.NET

Christopher Bennage — Fri, 08 Feb 2008 05:21:51 GMT

Cool idea, and Scott's comment was useful too.

re: Introducing ActiveSupport.NET

joeyDotNet — Fri, 08 Feb 2008 03:22:26 GMT

Cool, thanks a bunch for the input Scott. I'm definitely still trying to figure out the best way to structure things to make it as simple as possible to use. And this really helps.

re: Introducing ActiveSupport.NET

Scott Bellware — Fri, 08 Feb 2008 02:07:29 GMT

You've added language extensions, for example, for conversion. It just so happens that you got an implementation for System.String, but namespaces for extension libraries should be named for what they communicate when used in a "using" statement since it's that statement that documents the concern being added to the language.

Namespace naming rules for extension libraries shouldn't follow namespace naming rules for class libraries. The "using" statement takes on a whole new meaning when used to extend the language, and so those namespaces that are imported should be reflective of the kind of concern and functional ability that we're bringing into play.

Your basic choice for a root namespace should be the root concept that users will identify, being "ActiveSupport". If you use no other namespace for these extension libraries, "ActiveSupport" should be the bare minimum. You may choose to offer finer-grained differentiation if needed or wanted: ActiveSupport.Access, ActiveSupport.Conversion, etc.

You might try experimenting with thinking of namespaces for extension libraries at *language extensions* rather than *type extensions* when possible.

re: Principles and Patterns over Tools and Frameworks

joeyDotNet — Thu, 07 Feb 2008 14:20:27 GMT

@Colin,

Yeah, perhaps I should have stuck to the standard wording regarding SRP. Although you could say that if a unit of code (be it a method, class, etc.) does NOT "just do one thing", then it probably will have more than one reason to change, hence breaking SRP. Potaytoes, Potahtoes. :D

re: Principles and Patterns over Tools and Frameworks

Colin Jack — Thu, 07 Feb 2008 13:58:50 GMT

Good post. Hope I'm not being too pedantic but SRP is really about a single reason for change though, which is slightly different to only doing one thing.

re: Random Thoughts On Humility and Perfection

Kerry MacLean — Mon, 28 Jan 2008 16:25:24 GMT

Great, thought provoking post! So here's some of what has been provoked:

Perfection has only been achieved once, but that shouldn't stop us striving for it. I agree that it's more of a process than an end-point, but I would suggest that, like code, it's definition changes depending on what it's applied to.

I disagree that it's achievable by mere us.

As to apologies for not having more code in your posts, isn't the "perfect" developer a combination of attitude and ideas, of which coding ability is actuall a small portion?

re: Random Thoughts On Humility and Perfection

Bill Campbell — Fri, 25 Jan 2008 02:54:50 GMT

Joey,

Thanks for some real thought provoking insights!!