The Bolla Blog - All Comments

Що ми чекаємо від C# 4.0?

Краковецький Олександр - персональний блог — Tue, 18 Nov 2008 11:07:29 GMT

Спробую підсумувати все, що мені вдалось знайти на тему "що ми чекаємо від C# 4.0". Отже, Feature

re: C# 4.0 Feature Request: "??=" the Lazy load operator...

boj — Mon, 10 Nov 2008 20:38:20 GMT

nice:)

Що ми чекаємо від C# 4.0?

Alex Krakovetskiy's blog — Fri, 24 Oct 2008 20:47:31 GMT

Спробую підсумувати все, що мені вдалось знайти на тему "що ми чекаємо від C# 4.0". Отже, Feature

NHibernate 2.0: Changes Overview - taccato! trend tracker, cool hunting, new business ideas

Fri, 05 Sep 2008 12:28:30 GMT

Pingback from NHibernate 2.0: Changes Overview - taccato! trend tracker, cool hunting, new business ideas

NHibernate 2.0: Changes Overview

Mirrored Blogs — Fri, 05 Sep 2008 04:42:11 GMT

My post .NET Framework 3.5 SP1: Changes Overview on analysis evolution, structure and quality of the

NHibernate 2.0: Changes Overview

Community Blogs — Tue, 26 Aug 2008 17:45:45 GMT

My post .NET Framework 3.5 SP1: Changes Overview on analysis evolution, structure and quality of the

NHibernate 2.0: Changes Overview - taccato! trend tracker, cool hunting, new business ideas

Tue, 26 Aug 2008 17:14:55 GMT

Pingback from NHibernate 2.0: Changes Overview - taccato! trend tracker, cool hunting, new business ideas

NHibernate 2.0: Changes Overview

Patrick Smacchia [MVP C#] — Tue, 26 Aug 2008 17:01:07 GMT

My post .NET Framework 3.5 SP1: Changes Overview on analysis evolution, structure and quality of the

View to Presenter Communication(转)

江南白衣 — Sat, 02 Aug 2008 11:41:38 GMT

Alright, I've purposely hid the View to Presenter communication in my previous posts on Supervising Controller and Passive View because I thought that subject was worthy of its own post. As I see it, there are 2 1/2 basic ways to communicate screen events

re: C# 4.0 Feature Request: "??=" the Lazy load operator...

AK — Sat, 12 Apr 2008 03:40:24 GMT

Dude we are already so close with C# , dont add FLUFF.

Add STUFF

return _MYSERVICECLASS ?? (_MYSERVICECLASS = new MyService());

public class MyService

{

public int Count()

{

return 10;

}

public partial class Form1 : Form

{

MyService _MYSERVICECLASS;

public Form1()

{

InitializeComponent();

}

private int GetCount()

{

return MYSERVICECLASS.Count();

}

private MyService MYSERVICECLASS

{

get

{

return _MYSERVICECLASS ?? (_MYSERVICECLASS = new MyService());

}

private void Form1_Load(object sender, EventArgs e)

{

MessageBox.Show(string.Format ("{0} count , service is null {1}",GetCount(),_MYSERVICECLASS==null ));

}

re: A Better Continuous Integration + Version Control System?

Sean Chambers — Sun, 06 Apr 2008 15:51:09 GMT

I feel the need to chime in here as well. Interesting ideas but like everyone else I think auto-commit is a very bad idea.

The last step of the TDD mantra is refactor. Therefore, if an auto-commit is happening every green step, then you never have an opportunity to refactor your tests/code to support the new test. In addition, I write 10-20 tests between commits because one commit from my workstation often includes a set of tests that test a specific portion of the project, but just a single test per commit.

Some of your ideas are great though, opening your IDE and it automatically getting the most current revision from SC is a good idea, maybe with an alert window in case you don't want the most recent revisions however.

re: A Better Continuous Integration + Version Control System?

Greg Young — Fri, 04 Apr 2008 21:57:04 GMT

While this sounds pretty good and reasonable you are asking your development environment to do the equivalent of realizing when you want a beer and walking over to the kitchen to bring you one.

btw: commit on tests pass only works if I write tests first ;-)

re: A Better Continuous Integration + Version Control System?

keith — Fri, 04 Apr 2008 18:21:18 GMT

"The other scenario is when Dev A and Dev B are editing the same block of code, which leads to merge conflicts. In this scenario "CIVCS" wound't be able to not automerge the changes but instead could indicate the merge conflict by putting a "merge confilct" icon in the gutter to the left of the relevant lines of code."

but then i'm forced to resolve the conflict _now_ instead of when i'm ready to (when my code is finished and ready, by my definition of ready, for integration)

disruption and context switches lower productivity substantially, on average.

re: A Better Continuous Integration + Version Control System?

Steve Campbell — Fri, 04 Apr 2008 15:02:22 GMT

I'm a little wary of the auto-commit idea - explicit commits are important for lots of reasons, not least of which is identification of atomic changes that need to be integrated to other branches of the code.

The idea of the working copy being auto-updated is ok for me, but may not work on larger projects that contain multiple solutions, in such a way that for the new working copy to function, I would need new binaries too, and possibly even a database migration script. Also, if a programmer is spiking on something, then they may throw away changes - integrating too early can be a bad thing then.

That said, I can see scenarios where the idea has merit - perhaps in the beginning stages of the project, where we are growing from nothing to something. Often, team members have to wait around while someone else works on a core feature. In that case, perhaps it would be good to get a more rapid integration cycle.

re: A Better Continuous Integration + Version Control System?

Jim Bolla — Fri, 04 Apr 2008 13:40:44 GMT

"Many times my tests 'pass', but I am not done with either the test or code under test. "

If you're writing new code that is not yet integrated into the entire system, then your teammate receiving this partially complete (but compiling and test passing) code should not disrupt him.

If you're modifying existing code by refactoring or adding functionality but the tests all pass, then this should still be safe code for your teammate to use.

If you're changing the behavior of code, and then changing the assertions in the tests for that code, then there is a chance that these changes may cause problems for your teammate.

Derik, can you think of any other scenarios where a committed change may be disruptive to another teammember?

So far I'm seeing two negative reactions:

"I don't want my changes automatically committed"

and

"I don't want my working copy automatically updated/"

I think auto-committing is a great idea. It means tested changes are available for integration sooner.

I can feel how auto-updating could be disrupted. This is probably where the tools need to work well to not disrupt the developer. I get this. But from my experience, at least 90% of the time changes could be merged in silently and successfully.