Los Techies - Latest Comments

Re: Entity interface anti-pattern

Keith — Fri, 01 Dec 2017 10:30:02 -0000

I'm obviously 9 years late, but I would have to respectively disagree, especially with the use of ORMs today. A great benefit in having abstractions that simply have properties is that we can have different entity implementations of that abstraction. A great use case for this is when you're using different data access technologies over the lifetime of the application. Some ORMs such as PetaPoco require adding metadata to your POCOs to specify the mapping between your properties and table fields. It's highly probable that your properties and table fields are not a 1-2-1 match in naming convention. Some ORMs such as Dapper allow you to specify this mapping within the SQL itself, therefore, eliminating the need to add metadata to your POCOs. I'm not a fan in going back and changing existing classes and/or having that POCO having a dependency on a specific data access framework.

Re: Git guts: Merging and rebasing

John Anderson — Tue, 31 Jan 2017 15:59:31 -0000

Thanks for the article. s/"bare this in mind"/"bear this in mind"/ :)

Re: Me on NHibernate 3.2

kns98 — Thu, 12 Nov 2015 12:49:53 -0000

FNH >>> CONFORMIST

Re: Git guts: Merging and rebasing

Sachin Agrawal — Mon, 03 Aug 2015 14:49:13 -0000

One of the best description regarding differences between rebasing and merging.
Thanks for this piece. Very helpful.

Re: Behaviours in MSpec

Haidet Vlad-Dragos — Wed, 04 Feb 2015 07:48:25 -0000

Nice post!! One question - why all the fields must be static when working with MSpec ?

Re: Git: Remotes, contributions, and the letter N

David Land — Thu, 12 Jun 2014 00:21:05 -0000

Very helpful. It would be great to get an article about the "guts" behind git push. I've always wondered exactly what git was doing during a push outside of broad stroke terms like "sharing your local changes with the remote repository".

Re: Git’s guts: Branches, HEAD, and fast-forwards

David Land — Thu, 12 Jun 2014 00:14:24 -0000

Images are broken

Re: Git guts: Merging and rebasing

David Land — Wed, 11 Jun 2014 23:45:01 -0000

Wow, really nice article. Getting down in the details like this really helps clarify a lot of the more mysterious behaviors of git.

Re: Behaviours in MSpec

Jeremy Wilkins — Fri, 20 Dec 2013 18:16:29 -0000

What about being able to add the Act part to the behaviour definition:
Because of = () =>
vehicle.StartEngine();

is there any way that this Act part can be isolated for commonality?
I can see this as being useful given your example and having recently struggled with
breaking DRY myself just as you are doing in your solution, but wouldn't this be better?

[Behaviors]
public class StartingAVehicleBehaviors
{
protected static IVehicle vehicle;

Because of = () => vechicle.StartEngine();

It should_have_a_running_engine = () =>
vehicle.IsEngineRunning.ShouldBeTrue();

It should_be_polluting_the_atmosphere = () =>
vehicle.IsPolluting.ShouldBeTrue();

It should_be_idling = () =>
vehicle.RevCount.ShouldBeBetween(0, 1000);
}

I ran info the need to simplify equality testing for IEquatable<t> where it would be
nice to do:

[Behaviors]
public class IsEqualBehavior<t>
{
protected static IEquatable<t> equatable;
protected static IEquatable<t> otherObject;
protected static IEquatable<t> isEqual;

Because of = () => isEqual = equatable.Equals(otherObject);

It should_be_equal = () => isEqual.ShouldBeTrue();
}

[Behaviors]
public class IsNotEqualBehavior<t>
{
protected static IEquatable<t> equatable;
protected static T otherObject;
protected static bool isEqual;

Because of = () => isEqual = equatable.Equals(otherObject);

It should_not_be_equal = () => isEqual.ShouldBeFalse();
}

Although the type of T and the setup is guaranteed to be different, the
implementation should most likely be constrained to the same behaviour
despite the many uses of IEquatable<t>.

This also satisfies DRY much better.

Re: Behaviours in MSpec

Anon — Thu, 19 Dec 2013 10:54:05 -0000

Just a note that your " It should_have_a_running_engine = " is duplicated both in the second example and the behaviours class.

Re: Preventing debugger property evaluation for side-effect laden properties

Joom — Wed, 05 Jun 2013 10:00:46 -0000

Just what i was looking for, thanks! This saved me

Re: Observations on the Play! framework

Ashish — Thu, 21 Feb 2013 13:09:28 -0000

I am fairly new to Play, but seems very difficult to do DI. I am not able to get the confidence in doing TDD in Play

Re: Observations on the Play! framework

lotan — Sat, 29 Sep 2012 16:16:21 -0000

Has this changed much at all in Play? My suspicions after toying with Play 2.0 this morning were that testing was going to be annoying, especially isolation unit tests that I want to run fast, without services running. Seems like this post confirms my fears. I also see plenty of stack overflow posts mentioning that DI is unnecessary in Play but I think people forget that well laid out services/controllers rely on interfaces and class composition to perform work, which invites DI and makes it easier to unit test this code as well as configure your application.

Re: Observations on the Play! framework

Samario — Thu, 19 Jan 2012 16:52:52 -0000

Hello James,

Five years ago you shared this knowledge <<http: jagregory.com="" writings="" how-to-use-clientids-in-javascript-without-the-ugliness=""/>>, I don´t know how to implemented it, Can you please share a complete implementation, that is to say, a little visual studio project using the code. I will be gratefull for your help. Thansk. Henry.-

My email is : samario@gmail.com.

Re: Me on NHibernate 3.2

James Gregory — Thu, 29 Dec 2011 17:16:48 -0000

I like you.

Re: Me on NHibernate 3.2

Brad Smith — Thu, 29 Dec 2011 17:01:02 -0000

Ever thought about making FNH licensed? "Closer to my millions", eh? I mean don't rake us over the coals or anything, but fair compensation for a hard days work is acceptable by all means.

Re: Me on NHibernate 3.2

tor — Sun, 11 Dec 2011 18:50:29 -0000

james, any word when the next fluent nhibernate gets released.

Re: Me on NHibernate 3.2

Myri — Thu, 08 Dec 2011 10:15:46 -0000

I finally managed to get something done with nhibernate, and it's all thanks to you, FNH and all the people in the community using it and helping out when running into issues...
So for that, I can only thank you! (and hope FNH will be here for the long haul!)

Re: Me on NHibernate 3.2

Rafael — Fri, 18 Nov 2011 10:27:26 -0000

Good news... I really love fluent nhibernate, make our job much more easier.

Waiting for the next release... :)

Re: Me on NHibernate 3.2

James Gregory — Fri, 18 Nov 2011 02:04:48 -0000

Nope :)

Re: Me on NHibernate 3.2

Rafael — Thu, 17 Nov 2011 21:44:36 -0000

So.... fluent nhibernate is dead?

Re: Me on NHibernate 3.2

BigFan — Thu, 10 Nov 2011 21:00:15 -0000

Hey Greg

When is FNH version 2.0 coming out?

bigFan

Re: Observations on the Play! framework

Royston Shufflebotham — Sun, 30 Oct 2011 13:08:20 -0000

I've always subscribed to the notion that a framework API shouldn't be considered as having 'survived contact with the enemy' until not only has somebody written something using your API, but that they have also written tests against their code.

I've just started getting into Play, having previously used ASP.NET MVC and Rails, and having spent the last few years doing constructor-based injection testing, it's bit of a disappointment testing-wise. Didn't they learn from the static unmockable HttpContent fiasco in ASP.NET? *sigh*

But maybe it's not a 'deal breaker' - can we make it work anyway?

Controller action methods are meant to be extremely lightweight, and generally you want to get out of those and into services, repositories, other (non-REST) 'controller' objects as quickly as possible. Those can all be developed using proper instances with constructor injection and all the usual good stuff, no?

Play introduces its own 'FunctionalTest' and 'UnitTest' base classes, but you don't have to use them: you can write your own (fast) plain JUnit tests as long as the code you're testing doesn't make heavy use of Play stuff, which is probably in the database level. But then you're straying out of unit tests and into more integration-y tests, perhaps? The biggest area of irritation there is all the static fields inherited from Controller, e.g. 'validation'.

I dunno. I like the feel of the framework (apart from the curious static methods everywhere) and so I _want_ it to work. But when I see the great work that's been going on in ASP.NET MVC, where they've made it really easy to use out-of-the-box yet have made everything completely pluggable and testable, Play seems a bit backward.

I'm going to give it a try and see if I can bend it to my DI+unit testing will. If not, I'm dumping it. But what's the alternative in Java land? :(

Re: Observations on the Play! framework

James Gregory — Sun, 25 Sep 2011 12:03:40 -0000

Hi Ryan, you are correct. I do actually do this, though re-reading what I wrote I can see how that's not very clear. My real complaint is that whilst you can run them in your IDE, they require the full web stack to be available before they'll execute; this basically means you get a minimum of a 5s overhead for running your tests. Five seconds doesn't sound like much, I admit, but it quickly gets frustrating when you're used to a fast cycle.

Like many things in Play, I can live with it, and I can appreciate their decisions; however, it would be nice to not *have* to do it their way. I get the feeling Play! is at the place where Rails was a few years ago.

Phase 1: "You WILL do it our way!"
Phase 2: "Ok, you SHOULD do it our way but you can deviate a bit"
Phase 3: "Our way is the default, do whatever the hell you want though."

Re: Observations on the Play! framework

rssvihla — Sun, 25 Sep 2011 11:21:53 -0000

It's been awhile since I've been in the Java space but I seem to remember being able to run tests through Intellij when using the play "idealize" command see the following link

http://www.playframework.or...