Author: josh

I’ve been reading Domain-Driven Design and I just wanted to share this snippet, from chapter four:

In an object-oriented program, UI, database, and other support code often gets written directly into the business objects. Additional business logic is embedded in the behavior of UI widgets and database scripts. This happens because it is the easiest way to make things work, in the short run.

When the domain-related code is diffused through such a large amount of other code, it becomes extremely difficult to see and to reason about. Superficial changes to the UI can actually change business logic. To change a business rule may require meticulous tracing of UI code, database code, or other program elements. Implementing coherent, model-driven objects becomes impractical. Automated testing is awkward. With all the technologies and logic involved in each activity, a program must be kept very simple or it becomes impossible to understand.

I wish I could say this was obvious stuff.

JsRender is a solid tool, but the documentation is a bit lacking at present. I had a need a while back to render a list of things separated by commas, but without a comma at the beginning or end. That seems like a simple enough task, but it wasn’t obvious to me what the syntax should be. This post helped me figure it out.

Here’s the code (modified for the sake of example):

{{for products}}
    {{:name}}
    {{if (#index+1) != #parent.data.length}}, {{/if}}
{{/for}}

(If you’ve got a better way, drop me a line!)

A dev on the EF team says some stuff here about Entity Framework’s automatic change detection that I think we might find valuable:

When you need to manipulate many entities … the advice is to switch off AutoDetectChanges while you, for example, do all your Adds, and then switch it back on again afterwards.

You can turn off automatic change detection at the context level like this:

myContext.Configuration.AutoDetectChangesEnabled = false;

I haven’t looked at the performance improvements you get from this, but this post makes me think the performance would go from quadratic to linear. That’s a big boost.

(Here’s another well written post on the matter.)

A great developer would be good at two very different kinds of communication: communication with the compiler/interpreter and communication with other humans. Skills or techniques that benefit one of these modes of communication are often at odds with those that would benefit the other. E.g.: precision.

If I’m communicating with a compiler, the ability to be precise is valuable. At a very basic level, I have to be precise with my variable names. If I declare a variable “foo”, I can’t spell it “phoo” elsewhere and expect the compiler to know what I mean. (Sure, in some languages I could change casing and it might work. That’s slightly less precise, but still a degree of precision.)

On the other hand, when you’re trying to communicate with people, precision is often the opposite of what you want. If I needed to explain the first fundamental theorem of calculus to you, I could do it like this:

That would be precise. Do you think that’s the best way of communicating the information? To someone who doesn’t know it? No, of course not. In a calculus class, you build to it with proofs and cement it with examples. That’s redundancy, which programmers are generally taught to despise, but in this context it’s valuable.

Communicating with businesspeople, whether for requirement gathering or support or what-have-you, is like that. You’ll often benefit from repeating yourself, especially if you frame information differently to help the other party understand what you’re trying to get across. Use examples. Ask obvious questions or state the obvious. Make the other person repeat what you just said back to you, or repeat it back to them. It feels uncomfortable, but it helps.

(Other developers can be a whole other story with respect to this. Some of us prefer precise communication, some of us don’t. I’d actually go so far as to say being a great developer would require being good at three very different modes of communication: with the compiler, with the businesspeople, and with other developers. Perhaps I’ll write about that some time.)

If I make an object like this:

var myObj = {
   key1: "foo",
   key2: "bar",
   key3: function() { return "Hi."; }
};

I can access those properties like this:

var myKey = myObj.key1; // assigns myKey the value "foo"
var myFunction = myObj.key3 // assigns myFunction the function function() { return "Hi."; }

Or like this:

var myKey = myObj["key1"]; // assigns myKey the value "foo"
var myFunction = myObj["key3"] // assigns myFunction the function function() { return "Hi."; }

These two styles are logically equivalent. However, the dot notation is preferred according to most JS nerds.

I think the second style can, in some situations, be more convenient or clearer about what the code is doing. But your mileage may vary.

jQuery’s extend method does a memberwise copy of one or more objects onto a target object and returns the altered target object.

For example, say I have an object that represents some default options, like this:

var defaultOptions = {
   foo: "foo",
   bar: "bar"
};

var options = {
   foo: "hmm",
   derp: "derp"
};

If I call $.extend({}, defaultOptions, options), I’ll get back this result:

{
   foo: "hmm",
   bar: "bar",
   derp: "derp"
}

This is handy when you want to have default options in a private member, then pass in an options object that only overrides what you configure and leaves the rest of the defaults alone.

When you call myObjectContext.ExecuteStoreQuery<TEntity>(string commandText, param object[] parameters), the objects returned are detached from the object context. You might have to jump through some hoops to get them attached to your context. (It wants to treat them as new instances, and you’re like WTF.)

If you want the returned entities to be added to your context, there’s an overload to ExecuteStoreQuery that lets you specify an entitySetName parameter and a mergeOption parameter. The entitySetName parameter is the name of the entity set in the object context you want your objects to go into, and the mergeOption specifies options about whether the results returned should overwrite stuff that might already be in your object context.

By default, an ASP.NET MVC project doesn’t compile Razor view code when you build it. Hence, errors in the views don’t get caught at compile time.

Sometimes, if I quickly want to see if a change has caused any compilation errors in my views, I’ll open my project file in a text editor and edit this element:

<MvcBuildViews>false</MvcBuildViews>

Set the value to true and you can see if your views compile. I’ll usually set it back to false when I’m done, though you certainly don’t have to.

This:

if (value) {
}

will evaluate to false if value is null, undefined, NaN, an empty string, 0, or false.

So you should never need to do any of the following:

if (value == null) {
}
if (value == undefined) {
}
if (value == "") {
}
if (someString.length == 0) {
}

The common JS version of all these is simply

if (value) {
}

It makes for cleaner code and smaller files, too.

If I have a DOM element

<div id="myDiv"></div>

and I call

$("#myDiv").data("id", 1)

I might expect it to be updated like so:

<div id="myDiv" data-id="1"></div>

But that’s not how jQuery’s .data() method works. It attaches the data to the element in its internal data store, but it doesn’t update the DOM element itself.

If I want to set the actual attribute in the HTML, I have to call

$("#myDiv").attr("data-id", 1);

In either case, though, jQuery’s .data() method can read the value like this:

var value = $("#myDiv").data("id")

It gives precedence to its internal data store, but will fall back to a data-whatever property on the DOM node, if it’s there.