gariig posted:

Also, Microsoft agrees with you because JSON.Net will be the JSON serializer when Web API ships

uXs posted:

Because I want to test (almost) everything, I find that I have to use interfaces. A lot. For almost everything I make, I have to define an interface, and use that instead of the concrete class in other classes (or interfaces).

Now this is all fine, but it's getting very annoying that every single time I add a function or a property or an event or anything, I have to update the interface as well. Is there a way so I don't have to do this manually, or am I just going to have to suffer?

uXs posted:

Because I want to test (almost) everything, I find that I have to use interfaces. A lot. For almost everything I make, I have to define an interface, and use that instead of the concrete class in other classes (or interfaces).

Now this is all fine, but it's getting very annoying that every single time I add a function or a property or an event or anything, I have to update the interface as well. Is there a way so I don't have to do this manually, or am I just going to have to suffer?

wwb posted:

Or just avoid mocking the poo poo out of everything -- I think that worm as swung over too far in some places. I totally appreciate mocking / stubbing out / faking external dependencies but mocking every class something interacts with is overkill. Especially when the other classes have tests to ensure they work correctly and your code is reasonably clean as to not have wacky dependencies.

Ithaqua posted:

I agree. Plus, if the code is reasonably well-written in the first place, it's generally fairly painless to refactor later on if you need to decouple further.

boo_radley posted:

Active directory manipulation:

code:

using (var childGroup = GroupPrincipal.FindByIdentity(ouContext, groupName) ?? new GroupPrincipal(ouContext, groupName))
        {
          foreach (var personUserName in groups[groupName])
          {

            if (string.IsNullOrEmpty(personUserName))
            {
              continue;
            }
            using (var thisUser = UserPrincipal.FindByIdentity(domainContext, personUserName))
            {
              if (thisUser == null) continue;
              if (childGroup.Members.Contains(thisUser)) continue; 
              childGroup.Members.Add(thisUser);
              childGroup.Save();
              i++; 
              if (i % 100 == 0) Console.WriteLine(i);
            }

          }
        }

Right now the System.DirectoryServices.AccountManagement calls in this loop are 90% of this program's execution. I'm looking for ways to speed up this set of loops. I don't know if there's a way to intelligently cache AD objects, or if there's a different API that would lend itself better to the task.

boo_radley posted:

Right now the System.DirectoryServices.AccountManagement calls in this loop are 90% of this program's execution. I'm looking for ways to speed up this set of loops. I don't know if there's a way to intelligently cache AD objects, or if there's a different API that would lend itself better to the task.

PhonyMcRingRing posted:

I dunno if it'd add any performance benefit, never worked with ActiveDirectory, but storing the user in a dictionary might help some.

code:

// I'm assuming thisUser is a UserPrincipal type.
var userCache = new Dictionary<string, UserPrincipal>;

using (var childGroup = GroupPrincipal.FindByIdentity(ouContext, groupName) ?? new GroupPrincipal(ouContext, groupName))
{
  foreach (var personUserName in groups[groupName])
  {

	if (string.IsNullOrEmpty(personUserName))
	{
	  continue;
	}
	UserPrincipal thisUser;
	if (!userCache.TryGetValue(personUserName, out thisUser)) {
		thisUser = UserPrincipal.FindByIdentity(domainContext, personUserName);
		if (thisUser == null) { continue; }
		else { userCache.Add(personUserName, thisUser); }
	}
	
	if (childGroup.Members.Contains(thisUser)) continue; 
	childGroup.Members.Add(thisUser);
	childGroup.Save();
	i++; 
	if (i % 100 == 0) Console.WriteLine(i);
  }
}

foreach(var kvPair in userCache) {
	kvPair.Value.Dispose();
}

Ithaqua posted:

ReSharper has a "pull member up" function that will add a method to an interface with like 2 clicks.

PhonyMcRingRing posted:

Are you only doing the interfaces specifically for mocking? You could mark members as virtual and mock it that way, too.

wwb posted:

Or just avoid mocking the poo poo out of everything -- I think that worm as swung over too far in some places. I totally appreciate mocking / stubbing out / faking external dependencies but mocking every class something interacts with is overkill. Especially when the other classes have tests to ensure they work correctly and your code is reasonably clean as to not have wacky dependencies.

uXs posted:

Yeah, that's possible too. But then I have to make everything virtual. Apart from that being work as well, you also risk executing code that you forgot to mark as virtual.

I can see it now: 'public void ClearTable() { ... }'.

Oops.

PhonyMcRingRing posted:

What is this "new-object" and lack of Dims?

Paul MaudDib posted:

Once again I am having a moment.

Paul MaudDib posted:

Paul MaudDib posted:

code:

new Task(..).Start(..)

aBagorn posted:

This is pretty much what I would suggest, as well.

edmund745 posted:

Also by zooming in it is demonstrated that the MS UI Gothic font looks clearer, because it is acting like a bitmap font--it isn't dithering at all?

boo_radley posted:

These were good suggestions! The cacheing overhead has its own impact at around 7,000 users that seems to outweigh the time to do a raw query. However it seems like we're just doing too much in one monolithic process: 35,000+ users and 2 to 10 AD groups per user averaging 12s/1,000 group-users will take a bit over 8 hours to run. We're just doing too much with too many people all at once.

aBagorn posted:

Is this something I should be using jquery for?

Ithaqua posted:

It's probably bad markup somewhere in the page. When you have a weird issue in an existing codebase, find the simplest reproduction you can. Start commenting out chunks of HTML until it works. Then start uncommenting chunks until it doesn't. You'll eventually find the chunk that's your culprit.

But regardless, you should be using MVC and jQuery.

redleader posted:

I'm trying to figure out WPF ValidationRules and bindings and whatnot.

In my project, Validations.cs contains a validation rule. In MainWindow.xaml, I have a TextBox that should use this custom validation rule. However, I can't quite figure how to get the right XAML to actually bind the two. I think it looks something like:

code:

<TextBox Name="fooText">
    <Binding>
        <Binding.ValidationRules>
            <Something.Goes.Here.But.I.Don't.Know.What />
        </Binding.ValidationRules>
    </Binding>
</TextBox>

How do I bind the control defined in MainWindow.xaml (with associated code file MainWindow.cs) to the ValidationRule in Validations.cs?

More generally, is there a good introduction to WPF bindings and whatnot? I feel I'm missing out on some major elements of WPF by not understanding bindings and what they can do.

Ithaqua posted:

Validation
Data binding

For the record, I found both of those in about 5 seconds on Google.