问:
Database Context and Singleton injection with IoC
All of the below relates to a ASP.NET c# app.
I have a Singleton Settings MemoryCache that reads values from database on first access and caches these, then invalidates them using SQL Service Broker message and re-reads as required.

For the purposes of standard controllers, i create my Db Context in a request scope.
However, this obviously means that i can't use the same context in the Settings Cache class, since that is a singleton and we have a scope collision.

At the moment, i ended up with two db contexts - the Controllers get it via IoC container, whereas a Singleton just creates it's own.

However, i am not satisfied with this approach (mostly due to the way i feel about two contexts, the cache doesn't set anything on the db hence concurrency is not an issue as much).

What is a better way to do it?

答:
The DbContext is not thread safe so you should not use a singleton DbContext in an ASP.NET web app.  A thread per request is created and you'll start getting exceptions as soon as multiple users begin using your application.

It sounds like you're wrapping the cache in another class that has its own DbContext.  Why not just have that class take a DbContext in its constructor?  Also, is there a reason you aren't using HttpContext.Current.Cache (Cache class)?  That is the preferred way to Cache in ASP.NET (If you aren't using a 3rd party cache) and it will have the lifetime of the app domain.  I'm fairly sure this solves all of your singleton and 2 DbContext issues.

According to Microsoft

The MemoryCache class is similar to the ASP.NET Cache class. The MemoryCache class has many properties and methods for accessing the cache that will be familiar to you if you have used the ASP.NET Cache class. The main differences between the Cache and MemoryCache classes are that the MemoryCache class has been changed to make it usable by .NET Framework applications that are not ASP.NET applications. For example, the MemoryCache class has no dependencies on the System.Web assembly. Another difference is that you can create multiple instances of the MemoryCache class for use in the same application and in the same AppDomain instance.

source


问:
Are there alternatives to stack+heap+static memory model?
All programs I have seen organize their data memory into one or more call stacks (usually fixed size, but sometimes not), the heap, and static memory.  Lately thread-local static storage has been added to this as well.

Have there been any attempts to organize data memory layout in a radically different way, e.g. without the call stack?  Or organize memory in a different way that accomplishes the same thing?

答:
You might want to step back and see where and why those existing models come from.  When a process is created, it is simply given a flat storage area which is simply indexed from 0 to N. Because this storage area (talking about RAM here) is backed by a dedicated hardware and some fancy semiconductors it happens to be pretty fast, but it's not the only one of its kind.  Other devices such as hard drives are essentially the same thing, flat space addressable by an index, but many orders of magnitude slower.

The reason why "a heap" exists is because it would be impractical for each application to attempt to manage the use of RAM by itself.  Way back in the day, that's exactly how it happened, programmers planned ahead of time exactly what each RAM location would be used for. As software got more complex someone said, wouldn't it be nice if I could just go to some black box and say "I need 10 bytes so gimme" and not have to worry about all the intricate details of where and how those 10 bytes come from or how they are reclaimed.  That's what a heap is, doesn't really get more basic then that.

Each time a thread is created, there are some data structures (and a stack), which are acquired using the same "gimme operation" I just described.  A stack just about universally used because it fits perfectly with function call stack frames and their LIFO nature. In theory, each function invocation and local variables could be allocated on the heap, but that would simply be too expensive, compared with just a few assembly instructions that it takes to update stack pointer (ESP on x86) register.

Thread local storage (TLS) is also built on top of heap.  When a thread is created, as part of a trip to the heap to allocate memory for management structures, a separate space for TLS is also allocated from the heap.

So in the end, all you really have is a generic memory allocator (i.e. the heap) and everything else is a specialized form on top of that. In other words, if you are willing to give up some aspect of "I want to allocate as much (or as little) as I want, keep it for as long as I want and free whenever I want", you could get away trading off generic heap allocator for another model that offers speed but at the cost of some other limitation.

Take stack. It is incredibly fast when compared to the heap, but the two trade offs are 1) you don't control when memory is freed; instead once the function exits, whatever you allocated is gone and 2) because stacks are generally limited in size, you should be careful allocating large amounts of data directly on the stack.

Another type of "memory model" is the Virtual Memory Manager (VMM) offered by just about every major OS via system calls.  VMM is very similar to heap in a sense that you can ask for any amount of memory and keep it as long as you want.  However, the limitation is that you can only allocate memory in page size multiples (e.g. 4KB) so using VMM directly would cause a lot of overhead in a typical application that often allocates 8-24 bytes at a time.  In fact, just about every heap implementation is built on top of VMM specifically for purposes of allowing a very generic, non-specialized, small-block allocation.  Heap goes to VMM whenever it needs more memory and then doles out many small chunks of that memory to the application.

If you have an app, that has a need for allocating large blocks, you might consider going directly to VMM, although some heaps have an if-statement inside malloc() and if block size is greater than some threshold, they simply go to VMM for you.

Another form of allocators instead of directly using heap, would be pools.  A pool is a specialized allocator where all blocks are of the same size.  Pools (just like stack and TLS) are built on top of heap or VMM.  Pools are useful in places where you allocate a lot (millions) of short-lived, small objects of the same size. Think a network service processing incoming requests.  Each client requests may result in same N byte structure being allocated to handle that request.  The trade off with using pools is that each pool only handles one block size (but you can create multiple pools).  The advantage of pools is that because all objects are same size, it doesn't require intricate logic. Instead, whenever you need a new block, it just gives you the one that was recently freed.  So it kind of behaves like a heap in terms of giving you blocks that you can hang on to for as long as needed, but it's alloc/free operations are almost (but not quite) as cheap as using stack.

And lastly, remember that hard drive thing I mentioned way up top. You could have a memory model that behaves like a file system and duplicates same idea of directory entries and i-nodes to allow you hierarchical allocation of data blocks where each data block as addressed with a path. That's exactly what tmpfs does.

Beyond the stuff I mentioned, I'm sure there are other more specialized models, but in the end since everything is based on flat address space (that is until some genuis comes up with some kind of weird-a$$ non-flat space), it all goes back to that generic "gimme" allocator which is either VMM or the heap.

ContentLicense: CC BY-SA 3.0


问:
Mobile development project architecture model/pattern
I would like to hear some improvement suggestions for mobile development (Android/iOS) project architectures.
I would like to go for a "safe" design, modular and that can be easily maintained in time.

As far as I know Android and also iOS platforms are built on MVC, at least have the Activities and UIViewControllers that are a sort of controller part from MVC(as many stated out there on the internet).

Also I know two approaches so far for a basic project(Android/*iOS*):

 1. My favorite (a sort of MVC)

Model - I have here the models, only simple getter/setter classes

   shaping the project entities

View - the Activities, UIViewController
   and custom views, only display, get data from the user interface here, usually gets the data from the Controller, never directly from the Acess

Controller - some singletons (not necessary but usual) that manage
   each entity data, usually are doing business jobs, loading    data
   from the Access layer and don't have access to the view layer.

Access - Database and Web Service managers, serves data back to Controller layer, can't have contact to any other layers.

2. Commonly seen (also a sort of MVC)

Model - the models, only simple getter/setter classes shaping the project entities, I usually saw also some business jobs here too.

View-Controller -(Activities and UIViewController) that manage entity data, usually are doing business jobs and also take care of displaying data to the user. Also make calls through some web service classes to get the data.

So far I am using the first variant as I consider it more decoupled and I can see the difference between who is making business jobs, user interface communication and data providers. This making it more maintainable than the second one.

The drawback for the first one is that has 2 more layers than the second one, this means more classes(but less code in each class) and at the start of a project, this can take a bit longer to develop than the second one.

What approach do you use or which do you think it is better and why?

答:
I don’t think either of them represent classical MVC.

Model

The model is the data and the business logic. A model contains the state of the running application. It should report data and state. It should validate input. It should update data and state based on input.

The model should be independent of use. In iOS, this generally means it should derive from core Objective-C classes and use only core Objective-C objects. A good test for this would be to see if the model would work for other compilers like GCC Objective-C, or if it will work in other environments like OS X.

The model should be externally controllable. The model should be able to be driven by unit-tests or driven by a completely separate set of controllers.

View

A view is anything that is displayed to a user. In iOS, this generally means anything derived from UIView (UILabel, UIButton, …) Views are dumb: meaning that they know nothing of the model, business logic, or context in which they are created.

Controller

The controller binds model data to views so it can be displayed to users, provides context to views so they are shown correctly (disabled, highlighted, …), and handles user input to update the model. In iOS, this generally means anything derived from UIViewController. A controller may need to process model data in some small way to get it into a view. A controller may need to process user input in some small way to make it suitable for the model.

Data Store

The data store is the permanent repository for model data. This can be a database or a web service. Usually, data stores stand outside of MVC or are attached to the model.

My Answer

Now that I got that out of the way, my answer to your question: the MVC described above is the approach I use. This has implications, some of which are difficult to deal with.

A view must know nothing of the model. If you have a property in your view named price or total, then you’re doing it wrong.

A controller must not contain business logic. If you have a controller calculate sales tax, then you’re doing it wrong.

Addressing concerns in the comments

Warning: I'm not an Android developer and have limited understanding of how
Android works.

Services

Like data stores, long running async processing sits outside of MVC. If you need a service that updates the model, then think of it as method of the model. If you have a service that transforms data to show it to a user, then think of it as a method of a controller.

Novel Input

Like all input, broadcast receivers, orientation changes and task switching are tasks that should be handled by a controller. I think of iOS’s application delegate as a controller for the whole application: handling input which effects the whole application (like system notifications and application lifecycle changes).

Business Logic and Model Data

I see the Model composed of two parts, model data and business logic. I've learned it’s best to keep them separate. In practice, this means I wrap model data with business logic or add business logic on as a category of the model data.

Who I Am

To put it bluntly, it doesn’t matter who I am. I don’t think I’ve had a good original thought in my whole life. I’ve based my work on understanding patterns that other developers have created and applying them as best I can to the work I need to get done.

Since you asked, I’ve never worked in academia. I’ve been a software developer for the past 14 years. I’ve worked on code at all levels from drivers and debuggers to shiny custom views and silly apps. I’ve worked on iOS for the past 2½ years and have written many apps which have been released in the app store. I use my understanding of patterns to get my work done on time and on budget.

Update More questions in comments.

Models

I try to keep my data models as clean as possible. Usually they are mostly properties, sometimes conforming to NSCopying, NSCoding, and/or a JSON mapping. More and more, I include Key-Value Validation. This can be part of the data model or in a business logic category.

```<code>- (BOOL)validateValue:(inout MyValue **)value error:(out NSError **)error
{
    if (![self complexTestWithValue:*value]) {
        if (error != NULL) {
            // Report error to caller.
            *error = [self errorInValidation];
        }

        return NO;
    }

    return YES;
}
</code>```

Business Logic

In the past, I've written lots of code which looks like

```<code>[dataSource fetchObjectsWithInput:input completion:^(NSArray *objects, NSError *error) {
    // Model objects are in objects
}];
</code>```

or

```<code>[dataSource fetchObjectsWithInput:input completion:^(MyClassResult *result, NSError *error) {
    // Model objects are in result.objects
}];
</code>```

Recently, I've gotten into promises (I'm using PromiseKit).

```<code>[dataSource fetchObjectsWithInput:input].then(^(MyClassResult *result) {
    // Model objects are in result.objects
});
</code>```

This has been a good general purpose factory pattern for Objective C.

I tend to write business logic computations in categories.

```<code>@interface MyClass (BusinessLogic)

- (NSString *)textForValue; // A string to be used as label text.
- (MyResult *)computeOperationWithInput:(MyInput *)input error:(out NSError **error);
- (MyOtherClass *)otherObjectByTransformingValues;

@end
</code>```

Body:
I don’t think either of them represent classical MVC.

Model

The model is the data and the business logic. A model contains the state of the running application. It should report data and state. It should validate input. It should update data and state based on input.

The model should be independent of use. In iOS, this generally means it should derive from core Objective-C classes and use only core Objective-C objects. A good test for this would be to see if the model would work for other compilers like GCC Objective-C, or if it will work in other environments like OS X.

The model should be externally controllable. The model should be able to be driven by unit-tests or driven by a completely separate set of controllers.

View

A view is anything that is displayed to a user. In iOS, this generally means anything derived from UIView (UILabel, UIButton, …) Views are dumb: meaning that they know nothing of the model, business logic, or context in which they are created.

Controller

The controller binds model data to views so it can be displayed to users, provides context to views so they are shown correctly (disabled, highlighted, …), and handles user input to update the model. In iOS, this generally means anything derived from UIViewController. A controller may need to process model data in some small way to get it into a view. A controller may need to process user input in some small way to make it suitable for the model.

Data Store

The data store is the permanent repository for model data. This can be a database or a web service. Usually, data stores stand outside of MVC or are attached to the model.

My Answer

Now that I got that out of the way, my answer to your question: the MVC described above is the approach I use. This has implications, some of which are difficult to deal with.

A view must know nothing of the model. If you have a property in your view named price or total, then you’re doing it wrong.

A controller must not contain business logic. If you have a controller calculate sales tax, then you’re doing it wrong.

Addressing concerns in the comments

Warning: I'm not an Android developer and have limited understanding of how
Android works.

Services

Like data stores, long running async processing sits outside of MVC. If you need a service that updates the model, then think of it as method of the model. If you have a service that transforms data to show it to a user, then think of it as a method of a controller.

Novel Input

Like all input, broadcast receivers, orientation changes and task switching are tasks that should be handled by a controller. I think of iOS’s application delegate as a controller for the whole application: handling input which effects the whole application (like system notifications and application lifecycle changes).

Business Logic and Model Data

I see the Model composed of two parts, model data and business logic. I've learned it’s best to keep them separate. In practice, this means I wrap model data with business logic or add business logic on as a category of the model data.

Who I Am

To put it bluntly, it doesn’t matter who I am. I don’t think I’ve had a good original thought in my whole life. I’ve based my work on understanding patterns that other developers have created and applying them as best I can to the work I need to get done.

Since you asked, I’ve never worked in academia. I’ve been a software developer for the past 14 years. I’ve worked on code at all levels from drivers and debuggers to shiny custom views and silly apps. I’ve worked on iOS for the past 2½ years and have written many apps which have been released in the app store. I use my understanding of patterns to get my work done on time and on budget.

Update More questions in comments.

Models

I try to keep my data models as clean as possible. Usually they are mostly properties, sometimes conforming to NSCopying, NSCoding, and/or a JSON mapping. More and more, I include Key-Value Validation. This can be part of the data model or in a business logic category.

- (BOOL)validateValue:(inout MyValue **)value error:(out NSError **)error
{
    if (![self complexTestWithValue:*value]) {
        if (error != NULL) {
            // Report error to caller.
            *error = [self errorInValidation];
        }

        return NO;
    }

    return YES;
}

Business Logic

In the past, I've written lots of code which looks like

[dataSource fetchObjectsWithInput:input completion:^(NSArray *objects, NSError *error) {
    // Model objects are in objects
}];

or

[dataSource fetchObjectsWithInput:input completion:^(MyClassResult *result, NSError *error) {
    // Model objects are in result.objects
}];

Recently, I've gotten into promises (I'm using PromiseKit).

[dataSource fetchObjectsWithInput:input].then(^(MyClassResult *result) {
    // Model objects are in result.objects
});

This has been a good general purpose factory pattern for Objective C.

I tend to write business logic computations in categories.

@interface MyClass (BusinessLogic)

- (NSString *)textForValue; // A string to be used as label text.
- (MyResult *)computeOperationWithInput:(MyInput *)input error:(out NSError **error);
- (MyOtherClass *)otherObjectByTransformingValues;

@end


问:
Is it better to use an external variable or to pass around a pointer?
While writing in C, I have always wondered about when is the best time to use an external variable. I generally prefer to pass a pointer into a method. Is there a correct time to use an external variable and a correct time to use pointers?</p>

答:
Variables should always have the smallest scope possible.  This may lead to the "annoyance" of not being able to access the variables easily, but that is actually the point!  The more you hide a variable from intrusion the better.  If you can keep a variable safe from all reading and writing except from one point, that is the best!  This aids in writing bug-free code.

So to answer your question more specifically, pass variables as follows with #1 being the best method:

By value

As a pointer to variables where the address and data are constant

As a pointer to variables where the address and data are not constant

Globally to one file only

Globally to all files


问:
what kind of functions and/or classes are impossible to unit test and why
Main excuse from the developer for not having a good unit testing is "Code is not designed in a unit testable fashion." I am trying to understand what type of design and code that can't be unit tested. </p>

答:
There's no such thing as code that can't be tested. There are, however, a few examples of code that's REALLY, REALLY hard to test (to the point of possibly not being worth the effort):

Hardware interactions - If the code directly manipulates the hardware (for instance, writing to a register to move a physical device), then unit testing it might be too difficult or expensive. If you use real hardware for the test, that can get pricey to get appropriate feedback into the test harness (yet more equipment!), and if you don't, you have to emulate the exact behavior of physical objects - no small trick in some instances.

Clock interactions - This is usually easier, because it's almost always possible to mock out the system clock functions pretty trivially. But when you can't, then these tests become unmanageable - tests that are based on real-time tend to take a long time to run, and in my experience they tend to be very brittle as system loads make things take longer than they should, causing phantom test failures.


问:
Python - defining exit method before importing
This breaks nothing (in my experience), but lots of things "don't break anything" and are still wrong.

```<code>#! /usr/bin/env python
"""Short description of this module."""

def preferred_exit_method(*args):
    #code for exiting as desired

try:
    import foo
    import bar
    import eggs
except ImportError as e:
    #code code code
    preferred_exit_method(e)
</code>```

So, clearly defining the program's behavior on exit, then using it during the import process can't be too terrible, right? But it goes against the oft-cited PEP 8, which states that modules should be absolutely be imported before anything global.

It seems like an unrisky proposition, but then there's always something like this:

```<code>#! /usr/bin/env python
"""Description of module"""

def exit_of_choice(*args):
    #code code code
    sys.exit(0)

try:
    import sys
    import other_things
except ImportError as e:
    exit_of_choice(e)
</code>```

Apart from writing code that never needs to do this because it is perfect and never fails at anything, is there a reason besides PEP 8 and "other Python people will be cross with you" not to do this? (well, I'm less concerned with the latter - even though sys wouldn't typically fail to import, I still sort of hate that on principle)

答:
is there a reason besides PEP 8

Multiple module interaction

Your code becomes much more troublesome when there are multiple modules there isn't a good way to parameterize the modules with the code you have.  So you're left with 2 choices:

Duplicated the custom import-exit in every module that needs to import modules (or at least the imports you want to customize)

Centralize all your imports in one module and have subsequent modules import from the central module for use in their local namespace.

Only use it in one place, but an import of a particular module may or may not come from your custom import-exit code.  Any number of other imports may cause a different import to initialize the module in sys.modules.

It should be written as a custom importer

There is a better way.  If you want to customize imports Python has facilities for this.  They are called import hooks and you can write a hook that does a lookup against a white (or black) list of modules whose import you want to customize.  You can then have the hook exit explicitly when the import fails.


问:
REST API at backend and MVC Javascript framework at client side
I am building an online social network. I have finished writing RESTful API service using Django. This will return only JSON response (No HTML will be generated from server side) so that this JSON response can be used to build native smartphone apps. API service being common to all clients.

My question is, since there is no HTML response from server side, can the MV* Javascript Frameworks like Angular / Backbone / Ember take care of complete Front-end, right from generating HTML page with CSS?

答:
Yes definitely a MV* framework will work for you.

I am already working on a project where we use Zend framework's REST API which throws only JSON data and BackboneJS on the client side for generating and rendering the HTML content.

BackboneJS I would suggest. Alternatively AngularJS would be a very good option as it allows dynamic binding and easy MODEL - VIEW and VIEW - MODEL binding i.e. binding in AngularJS is both ways.


问:
Is there a software engineering principle that relates reuse and regression test cost on a production system?
I've worked on a large financial transaction system for a bank that looked after Pensions and Investments. After 15 years of feature changes, the manual regression test cost had climbed to $200K per release. (10M LOC, $10M transacted per day). This system also interfaces with 19 other systems around the company moving lots of data around. This system was implemented in Java.

What we observe however, is that the more 'reuse' we do, the more regression test costs go up. (The reason being that you need to "test the code you touch" - and reused/shared code impacts a multiplicity of places when it is touched. So despite 'DRY - Do Not Repeat Yourself' - ie don't copy and paste code - we observe a financial incentive to copy and paste code.  This is to drive regression test costs down, because we don't want to modify code that could be shared, because that will cause a big regression test impact. )

My question is is there a software engineering principle that describes the relationship between reuse and regression test costs?

The reason I'd ask this question is that arguably there is a cost benefit in decomposing the system into smaller parts to be tested.

Assumptions:

'Regression test' means 'acceptance test' - ie another group spending time to write new and reuse old tests against the system on behalf of the business, including environment and data setups.

I know the knee-jerk reaction to a big regression test cost is 'more automated tests'. This is a good principle. In this environment there are a couple of challenges.

(a) Automated tests are less useful across system boundaries, unless that system has a high automated test coverage as well. (Sphere of influence challenge).

(b) It is culturally difficult to get momentum on programmer time or capital investment on high automated test coverage when your system is already large and complex.

(c) The cost of maintaining automated tests is hidden on a project, and so they are easily discarded at a project level.

(d) This is just the cultural reality of working in a bank.

(e) I'm working to solve this problem in a different way (decomposition).

答:
we don't want to modify code that could be shared, because that will cause a big regression test impact

Above sounds about right to me. The more important is the code, the more it is shared, the higher are quality requirements, the more quality assurance should be involved when it changes.

Since your system is implemented in Java, you can see an example for above right there, in Java standard libraries (JDK). Its major releases are infrequent, and are accompanied with very effort consuming testing. And even minor releases run through very comprehensive JCK test suite to verify absence of regressions.

You may think this somehow stifles evolution of shared code, and... yes this is about right. The more impact and risk is associated with code change, the more careful you should be about doing it, the more effort needs to be involved into testing its releases.

Ideally, quality of releases of widely shared code should be such that it doesn't need big changes at all (save for infrequent enhancements). This line of thought is reflected in a famous quote of Joshua Bloch:

Public APIs, like diamonds, are forever. You have one chance to get it right so give it your best.

With above said though, it looks like some of the problems you describe are caused by inefficient strategy of shared code development. In particular, it looks especially troublesome that for reused code, only two options are considered: either duplicate this code or include it immediately into "core" shared libraries.

Limiting to only these two options is unnecessary and, again, you can find examples of how it can be done better in the very JDK you use. Take a look at java.util.concurrent packages (JSR 166) - until Java 5 release, these were a separate library, not a part of core JDK releases.

Think of it, that's a third option you overlooked, and fairly pragmatic one, the one you need to consider at "inception" of new shared code. When you just figure some code that can be shared between 2-3 components, nothing forces you to immediately include it into core API of the system.

You can package and release this "immature" shared code as separate library, just as it was done to Java concurrent utilities. This way relieves you from the need of full regression testing, because you can use only a relatively small amount of involved components. As a result, you have more leeway to modify and improve this shared code and to test how it works in production.

After your library matures and stabilizes enough to give you confidence that further changes in it are unlikely, you can consider its inclusion into core libraries of the system, just like concurrent utilities have been eventually included into JDK.

A concrete example of how much effort (including testing) may be involved into changing heavily reused code can be found, again, in JDK. In release 7u6 they changed internal String representation that involved a change in substring performance. Comments of a feature developer at Reddit outline how much effort was involved in this change:

The initial analysis came out of the GC group in 2007...

Internally the Oracle performance team maintains a set of representative and important apps and benchmarks which they use to evaluate performance changes. This set of apps was crucial in evaluating the change to substring. We looked closely at both changes in performance and change in footprint. Inevitably, as is the case with any significant change, there were regressions in some apps as well as gains in others. We investigated the regressions to see if performance was still acceptable and correctness was maintained...

My reply is not intended to be exhaustive but is a very brief summary of what was almost six months of dedicated work...


答:
I don't think there exist any metrics to calculate "cost for regression tests / LOC of reused code built". And I don't think anyone had ever invested so much time and money to build the same "big" system twice, one version with a lot of resuable components, and one without, to make any serious research on that.

But I have seen problems caused by reuse like yours before, and maybe you are interested in some thoughts about how to handle this better.

First, it is actually not reuse which is your problem - it is rather the attempt to build your own reusable components and use them throughout your system. I am sure you are doing a lot of reuse of big software packages where your problems don't arise: think of the whole Java stack you are using, or maybe some third party components (assumed you were satisfied with that components). But what is different with that software, for example, the Java libraries, while your own reusable components are causing you so much additional regression testing costs? Here are some points I guess that could be different:

those components are very mature and stable

they are developed and fully tested in isolation, by a completely different organization

to (re)use them, you don't have to change them (in fact you could not even if you would like that, since you don't maintain the source code)

you don't get daily a new version, only minor updates (at maximum per month), or major updates in intervals per year

most updates are designed to be 100% downwards compatible, especially minor updates

So to make your own reuseable components more successful, you should adapt some of that things from above for your own development:

for any reusable component, have a clear responsibility who does the maintenance and make sure that all people who reuse a component can be sure to get a bugfix immediately if problems arise.

establish a strict versioning and release policies. When evolving a reusable component, don't release it "to everyone" every day (at least, not if that would imply mean to run a full $200K regression test on the system). Instead, let new versions only be published from time to time, and provide mechanisms to let user of that component defer the change to the new version.

the more often a component is reused, the more important is it that it provides a stable interface and downwards compatible behaviour.

reusable components need very complete test suites to test them in isolation.

Lots of these things will mean that the cost of building the component itself will increase, but it will also decrease the costs of changes caused by failed regressions.

Title: Is there a software engineering principle that relates reuse and regression test cost on a production system?

Body:
I've worked on a large financial transaction system for a bank that looked after Pensions and Investments. After 15 years of feature changes, the manual regression test cost had climbed to $200K per release. (10M LOC, $10M transacted per day). This system also interfaces with 19 other systems around the company moving lots of data around. This system was implemented in Java.

What we observe however, is that the more 'reuse' we do, the more regression test costs go up. (The reason being that you need to "test the code you touch" - and reused/shared code impacts a multiplicity of places when it is touched. So despite 'DRY - Do Not Repeat Yourself' - ie don't copy and paste code - we observe a financial incentive to copy and paste code.  This is to drive regression test costs down, because we don't want to modify code that could be shared, because that will cause a big regression test impact. )

My question is is there a software engineering principle that describes the relationship between reuse and regression test costs?

The reason I'd ask this question is that arguably there is a cost benefit in decomposing the system into smaller parts to be tested.

Assumptions:

'Regression test' means 'acceptance test' - ie another group spending time to write new and reuse old tests against the system on behalf of the business, including environment and data setups.

I know the knee-jerk reaction to a big regression test cost is 'more automated tests'. This is a good principle. In this environment there are a couple of challenges.

(a) Automated tests are less useful across system boundaries, unless that system has a high automated test coverage as well. (Sphere of influence challenge).

(b) It is culturally difficult to get momentum on programmer time or capital investment on high automated test coverage when your system is already large and complex.

(c) The cost of maintaining automated tests is hidden on a project, and so they are easily discarded at a project level.

(d) This is just the cultural reality of working in a bank.

(e) I'm working to solve this problem in a different way (decomposition).


问:
When to use repository pattern
I have read recently that it is not good practice to use the repository pattern in conjunction with an ORM. From my understanding this is because the abstraction they provide over the SQL database is too leaky to be contained by the pattern.

I have a couple of questions about this:

What do you do if you want to switch out ORMs? You would have ORM specific code in your application if you do not contain it in a repository.

Is the repository pattern still valid when not using an ORM and you are using ADO.NET for data access and populating object data yourself?

If you use an ORM but not the repository pattern where do you keep commonly used queries? Would it be wise to represent each query as a class and have some sort of query factory to create instances?

答:
If the ORM offers flexibility of LINQ, eager loading etc. I wouldn't hide it behind any extra layer.

If it involves raw sql (micro ORM) then "method per query" should be used anyway to achieve reusability, thus making repository pattern a good fit.

```<code>What do you do if you want to switch out ORMs?
You would have ORM specific code in your application if you do not contain it in a repository.
</code>```

Why would you need to switch?

The one that has most of the features you need should be used.
It's possible that a new release of ormX brings new features and turns out to be better than the current one, but...

If you choose to hide the orm, you can only use the features all the candidates have in common.

E.g. you can't use Dictionary<string, Entity> properties in your entities because ormY can't handle those.

Assuming LINQ is used, majority of orm switch is just switching library references and replacing session.Query<Foo>() with context.Foos or similar until it compiles.
Boring task, but takes less time than coding the abstraction layer.

```<code>Is the repository pattern still valid when not using an ORM and you are using ADO.NET for data access and populating object data yourself?
</code>```

Yes. Code should be reusable and that means putting sql building, object materialization etc. in one place (separate class).
You may as well call the class "XRepository" and extract an interface from it.

```<code>If you use an ORM but not the repository pattern where do you keep commonly used queries?
Would it be wise to represent each query as a class and have some sort of query factory to create instances?
</code>```

Assuming LINQ is used a class wrapper would be overkill IMHO. A nicer way would be extension methods

```<code>public static IQueryable<T> Published<T>(this IQueryable<T> source) where T : Page
{
    // at some point someone is going to forget to check that status
    // so it makes sense to extract this thing
    return source.Where(x => x.Status == Status.Published && x.PublishTime <= DateTime.UtcNow);
}
</code>```

Any code that is used in multiple places (or has the potential) and is complicated enough (error prone), should be extracted to a centralized place.

Title: When to use repository pattern

Body:
If the ORM offers flexibility of LINQ, eager loading etc. I wouldn't hide it behind any extra layer.

If it involves raw sql (micro ORM) then "method per query" should be used anyway to achieve reusability, thus making repository pattern a good fit.

What do you do if you want to switch out ORMs?
You would have ORM specific code in your application if you do not contain it in a repository.

Why would you need to switch?

The one that has most of the features you need should be used.
It's possible that a new release of ormX brings new features and turns out to be better than the current one, but...

If you choose to hide the orm, you can only use the features all the candidates have in common.

E.g. you can't use Dictionary<string, Entity> properties in your entities because ormY can't handle those.

Assuming LINQ is used, majority of orm switch is just switching library references and replacing session.Query<Foo>() with context.Foos or similar until it compiles.
Boring task, but takes less time than coding the abstraction layer.

Is the repository pattern still valid when not using an ORM and you are using ADO.NET for data access and populating object data yourself?

Yes. Code should be reusable and that means putting sql building, object materialization etc. in one place (separate class).
You may as well call the class "XRepository" and extract an interface from it.

If you use an ORM but not the repository pattern where do you keep commonly used queries?
Would it be wise to represent each query as a class and have some sort of query factory to create instances?

Assuming LINQ is used a class wrapper would be overkill IMHO. A nicer way would be extension methods

public static IQueryable<T> Published<T>(this IQueryable<T> source) where T : Page
{
    // at some point someone is going to forget to check that status
    // so it makes sense to extract this thing
    return source.Where(x => x.Status == Status.Published && x.PublishTime <= DateTime.UtcNow);
}

Any code that is used in multiple places (or has the potential) and is complicated enough (error prone), should be extracted to a centralized place.


问:
How bad can it be to lack teamwork when you are a programmer?
I'm still at school, and I know I have problems dealing with other people.

I'm not an angry or shy or different, I just like to work my way and with my opinions while respecting other's, I have a big curiosity and hunger for knowledge, but I lack practice and I guess people don't want to work with me because they might fear I would talk some kind of morale. (For example I started to learn programming using linux instead of windows, even if I use windows a lot. And I have a mac).

What happens to programmers who lack teamwork? Where does the problems begin? Does being a good programmer compensate at least a little? Is it normal for a programmer to have a vision about his work instead of just doing what he is told?

答:
It's a learnable skill. You can learn now (by simply trying to work with others) or learn the hard way, on the job. (I'd suggest the former.)

If you can't work with other people then you can't build big systems. You also can't work with people smarter than you, which means you can't learn as much or as quickly.

ContentLicense: CC BY-SA 2.5


问:
Implementation of chess endgame engine without Endgame Tablebases
I'm interested in creating an chess endgame solving engine.

The endgames in chess are usually solved using the endgame table-bases generated by retrograde algorithm.

I have found that Artificial Intelligence and Genetic Algorithms have been applied to the chess programming.

However, before starting the implementation I wanted to find out whether the chess endgames can be played without the endgame tablebases?

If yes, then what are the pros and cons of these alternatives to endgame tables?

Are there any other algorithms known for this problem?

答:
Without any precalculated tables, you can just build a standard chess playing engine (not specifically for endgames). Look, for example, here for a starting point. To optimize such an engine for endgames, you can try to automatically adapt your evaluation function whenever you identify a "known endgame" situation for which you have a specific evaluation strategy ready.

Pros: you will need typically much less storage than for a table-based solution. End game tables for 5,6 or 7 pieces will AFAIK need several Giga- or Terrabytes (rough guess of mine), for more pieces a table based approach won't be feasible any more.

Cons: Your AI will be far from perfect (as opposed to an endgame table, which allows the engine to play perfect). End game situations suffer typically from the "horizon problem". See this Wikipedia article about what was achieved over the last years by using table based retrograde analysis. You cannot expect to get such results from a standard engine.


问:
How to evaluate CLR / C++ vs native C++?
How should I go about evaluating the performance or execution time of C++ with CLR versus native C++?

My personal bias is that I believe C++ with CLR to be slower since it has to run on a virtual machine.  I will also admit that I have never really been a fan of Visual C++ due to the syntax that has been added, so I wanted to know how to evaluate the performance of the two approaches and determine which is provably faster instead of relying only on my biases.

答:
Well, as always these kind of questions can't be answered with an absolute yes or no.

My experiences in general is that C++/CLI performs fast enough for me to work with it in desktop applications, C library wrappers or similar. However, if I needed to build a large hard real time system, I would not use it.

You need to look at what you need to use it for and if it is really performance critical, you should build a prototype - or model or whatever you want to call it - and benchmark. Do you have a lot of disc IO? Do you need a lot of varying memory allocation? Do you have any real time constraints?


答: Team work is a important part of Software Engineering. If you are working alone, you might not be bothered about how others are and what people expect from you. But if you are working with another person, working together really counts. When it comes to software, what you mean by team-work is a really 'communicating well'. Just give respect to your colleague and be tolerant of all ideas. It should be fine.

Title: How bad can it be to lack teamwork when you are a programmer?

Body:
I'm still at school, and I know I have problems dealing with other people.

I'm not an angry or shy or different, I just like to work my way and with my opinions while respecting other's, I have a big curiosity and hunger for knowledge, but I lack practice and I guess people don't want to work with me because they might fear I would talk some kind of morale. (For example I started to learn programming using linux instead of windows, even if I use windows a lot. And I have a mac).

What happens to programmers who lack teamwork? Where does the problems begin? Does being a good programmer compensate at least a little? Is it normal for a programmer to have a vision about his work instead of just doing what he is told?


答: I did some benchmarks in the past on my own, and my experience was that native C++ was around a factor 2 faster than C++/CLI for my typical business case, without any relevant change in code - your mileage will vary. For me, a factor 2 was almost always fully acceptable to stick to C++/CLI side, because interaction with the .NET framework and other .NET code was much more important for me than this performance gain.

Title: How to evaluate CLR / C++ vs native C++?

Body:
How should I go about evaluating the performance or execution time of C++ with CLR versus native C++?

My personal bias is that I believe C++ with CLR to be slower since it has to run on a virtual machine.  I will also admit that I have never really been a fan of Visual C++ due to the syntax that has been added, so I wanted to know how to evaluate the performance of the two approaches and determine which is provably faster instead of relying only on my biases.


问:
Separating front end from back end - Tomcat
I'm currently working with a company that uses Java / Tomcat / Spring for the back end of our web applications. As a front-end developer, I'm feeling more and more strongly that the back end should be a separate project from the front end, for a few reasons:

1) Building the project - many modern projects build with grunt and other front-end tools. The front-end build goals (concatenation, minification, front end tests, pre-processing CSS) are completely different from the back end goals (compiling java code, passing back end tests, deploying to a continuous integration server)

2) Deployment: When I commit a javascript or html file to our git repo, it doesn't make sense that our continuous deployment tool should rebuild and redeploy the whole project, but it has no way to tell the difference between a front-end commit and a back-end commit.

So, how would you restructure a project that previously automatically deployed from a single war file, living in a single git repo, to make a separate back end and front end? Can I actually do this, given that we use Spring framework?

Right now, my files live in a mixture of the /webapp/WEB-INF directory (for html pages / velocity templates) and the /webapp/resources directory for everything else (js, css, images). I'm slightly confused about how I should go about this when tomcat deploys a huge bulk of files to the /target directory, as well? If I keep a separate git repo for front end files, won't it be wiped out if I re-deploy the back end project?

(Originally I come from an Apache background, where it seemed so nice and simple...)

答:
At jClarity we've definitely followed this approach. We have a 'pure' HTML5 front end - AngularJS, HTML, CSS and a host of Javascript micro frameworks which is a separate project to the backend - vert.x with a variety of verticles coded in separate JVM languages as appropriate.

The trick is to have a well defined messaging API between the two that is tested by JUnit/TestNG style integration tests (backend) and Jasmine/Selenium tests (front end).

It's worked really well for us, great separation of concerns with the only dependency being on the messaging API between the front end and back end. We use a bit of clever Maven magic to check that the dependencies are correct between the two as well as end to end tests.

Despite an upfront cost in getting this all set-up, I've been amazed to see how quickly new functionality can be added with confidence using this structured approach. Even better, there's no stinking UI/View logic in our server side code and visa versa.

So in short - I highly recommend it :-).


问:
Should angularjs directive directly interact with services or is it considered an anti-pattern?
Which one is considered better:

having a directive that interacts with services directly

or

having a directive that exposes certain hooks to which controller may bind behaviour (involving services)?

答:
A directive is best (as a rule-of-thumb) when it's short (code-wise), (potentially) re-usable, and has a limited a scope in terms of functionality. Making a directive that includes UI and depends on a service (that I assume handles connection to the backend), not only gives it 2 functional roles, namely:

Controlling the UI for display/entry of data for the widget.

Submitting to the backend (via the service).

but also making it less re-usable, as you then can't use it again with another service, or with a different UI (at least not easily).

When making these decisions, I often compare to the built-in HTML elements: for example <input>, <textarea> or <form>: they are completely independent of any specific backend. HTML5 has given the <input> element a few extra types, e.g. date, which is still independent of backend, and where exactly the data goes or how it is used. They are purely interface elements. Your custom widgets, built using directives, I think should follow the same pattern, if possible.

However, this isn't the end of the story. Going beyond the analogy with the built-in HTML elements, you can create re-usable directives that both call services, and use a purely UI directive, just like it might use a <textarea>. Say you want to use some HTML as follows:

```<code><document document-url="'documents/3345.html'">
 <document-data></document-data>
 <comments></comments>
 <comment-entry></comment-entry>
</document>
</code>```

To code up the commentEntry directive, you could make a very small directive that just contains the controller that links up a service with a UI-widget. Something like:

```<code>app.directive('commentEntry', function (myService) {
  return {
    restrict: 'E',
    template: '<comment-widget on-save="save(data)" on-cancel="cancel()"></comment-widget>',
    require: '^document',
    link: function (scope, iElement, iAttrs, documentController) {
      // Allow the controller here to access the document controller
      scope.documentController = documentController;
    },
    controller: function ($scope) {
      $scope.save = function (data) {
        // Assuming the document controller exposes a function "getUrl"
        var url = $scope.documentController.getUrl();

        myService.saveComments(url, data).then(function (result) {
          // Do something
        });
      };
    }
  };
});
</code>```

Taking this to an extreme, you might not ever need to have a manual ng-controller attribute in the HTML: you can do it all using directives, as long as each directly has a clear "UI" role, or a clear "data" role.

There is a downside I should mention: it gives more "moving parts" to the application, which adds a bit of complexity. However, if each part has a clear role, and is well (unit + E2E tested), I would argue it's worth it and an overall benefit in the long term.

Body:
A directive is best (as a rule-of-thumb) when it's short (code-wise), (potentially) re-usable, and has a limited a scope in terms of functionality. Making a directive that includes UI and depends on a service (that I assume handles connection to the backend), not only gives it 2 functional roles, namely:

Controlling the UI for display/entry of data for the widget.

Submitting to the backend (via the service).

but also making it less re-usable, as you then can't use it again with another service, or with a different UI (at least not easily).

When making these decisions, I often compare to the built-in HTML elements: for example <input>, <textarea> or <form>: they are completely independent of any specific backend. HTML5 has given the <input> element a few extra types, e.g. date, which is still independent of backend, and where exactly the data goes or how it is used. They are purely interface elements. Your custom widgets, built using directives, I think should follow the same pattern, if possible.

However, this isn't the end of the story. Going beyond the analogy with the built-in HTML elements, you can create re-usable directives that both call services, and use a purely UI directive, just like it might use a <textarea>. Say you want to use some HTML as follows:

<document document-url="'documents/3345.html'">
 <document-data></document-data>
 <comments></comments>
 <comment-entry></comment-entry>
</document>

To code up the commentEntry directive, you could make a very small directive that just contains the controller that links up a service with a UI-widget. Something like:

app.directive('commentEntry', function (myService) {
  return {
    restrict: 'E',
    template: '<comment-widget on-save="save(data)" on-cancel="cancel()"></comment-widget>',
    require: '^document',
    link: function (scope, iElement, iAttrs, documentController) {
      // Allow the controller here to access the document controller
      scope.documentController = documentController;
    },
    controller: function ($scope) {
      $scope.save = function (data) {
        // Assuming the document controller exposes a function "getUrl"
        var url = $scope.documentController.getUrl();

        myService.saveComments(url, data).then(function (result) {
          // Do something
        });
      };
    }
  };
});

Taking this to an extreme, you might not ever need to have a manual ng-controller attribute in the HTML: you can do it all using directives, as long as each directly has a clear "UI" role, or a clear "data" role.

There is a downside I should mention: it gives more "moving parts" to the application, which adds a bit of complexity. However, if each part has a clear role, and is well (unit + E2E tested), I would argue it's worth it and an overall benefit in the long term.


答:
Right now I can't see a reason why you should use a global variable instead of passing another parameter around except in the case where you're dealing with performance-critical code and you might have constraints like stack memory, ABI restrictions and such.

This applies to the C code you asked in the question, wouldn't totally fit in an object oriented context (although people also use C++ objects in performance-intensive contexts).

Title: Is it better to use an external variable or to pass around a pointer?

Body: While writing in C, I have always wondered about when is the best time to use an external variable. I generally prefer to pass a pointer into a method. Is there a correct time to use an external variable and a correct time to use pointers?</p>


答:
Depends on what the job requires. Sometimes you won't even have a team for certain assignments. But most of the time, you will have a manager.

Also, having a team really helps to remind you from time to time that you write crap code.:

As a software developer, you are your
  own worst enemy. The sooner you
  realize that, the better off you'll
  be. - Jeff Atwood

Which means, having a team will make it easier to learn things faster! Being a loner will make you a hermit ;)


问:
What's the reason for C standard to consider const-ness recursively?
The C99 standard says in 6.5.16:2:

An assignment operator shall have a modifiable lvalue as its left
  operand.

and in 6.3.2.1:1:

A modifiable lvalue is an lvalue that does not have array type, does
  not have an incomplete type, does not have a const-qualified type, and
  if it is a structure or union, does not have any member (including,
  recursively, any member or element of all contained aggregates or
  unions) with a const-qualified type.

Now, let's consider a non-const struct with a const field.

```<code>typedef struct S_s {
    const int _a;
} S_t;
</code>```

By standard, the following code is undefined behavior (UB):

```<code>S_t s1;
S_t s2 = { ._a = 2 };
s1 = s2;
</code>```

The semantic problem with this is that the enclosing entity (struct) should be considered writable (non-read-only), judging by the declared type of the entity (S_t s1), but should not be considered writable by the wording of standard (the 2 clauses on the top) because of const field _a. The Standard makes it unclear for a programmer reading the code that the assignment is actually a UB, because it's impossible to tell that w/o the definition of struct S_s ... S_t type.

Moreover, the read-only access to the field is only enforced syntactically anyway. There's no way some const fields of non-const struct are going really be placed to read-only storage. But such wording of standard outlaws the code which deliberately casts away the const qualifier of fields in accessor procedures of these fields, like so (Is it a good idea to const-qualify the fields of structure in C?):

(*)

```<code>#include <stdlib.h>
#include <stdio.h>

typedef struct S_s {
    const int _a;
} S_t;

S_t *
create_S(void) {
    return calloc(sizeof(S_t), 1);
}

void
destroy_S(S_t *s) {
    free(s);
}

const int
get_S_a(const S_t *s) {
    return s->_a;
}

void
set_S_a(S_t *s, const int a) {
    int *a_p = (int *)&s->_a;
    *a_p = a;
}

int
main(void) {
    S_t s1;
    // s1._a = 5; // Error
    set_S_a(&s1, 5); // OK
    S_t *s2 = create_S();
    // s2->_a = 8; // Error
    set_S_a(s2, 8); // OK

    printf("s1.a == %d\n", get_S_a(&s1));
    printf("s2->a == %d\n", get_S_a(s2));

    destroy_S(s2);
}
</code>```

So, for some reason, for an entire struct to be read-only it's enough to declare it const

```<code>const S_t s3;
</code>```

But for an entire struct to be non-read-only it's not enough to declare it w/o const.

What I think would be better, is either:

To constrain the creation of non-const structures with const fields, and issue a diagnostic in such a case. That would make it clear that the struct containing read-only fields is read-only itself.

To define the behavior in case of write to a const field belonging to a non-const struct as to make the code above (*) compliant to the Standard.

Otherwise the behavior is not consistent and hard to understand.

So, what's the reason for C Standard to consider const-ness recursively, as it puts it?

答:
The reason is that read-only fields are read-only. No big surprise there.

You're mistakenly assuming that the only effect is on placement in ROM, which indeed is impossible when there are adjacent non-const fields. In reality, optimizers may assume const expressions are not written to, and optimize based on that. Of course that assumption doesn't hold when non-const aliases exist.

Your solution (1) breaks existing legal and reasonable code. That won't happen. Your solution (2) pretty much removes the meaning of const on members. While this won't break existing code, it seems to lack a rationale.


答:
If you cannot collaborate with others and you are not a naturally born coding stellar genius, you basically block yourself for working on any non-trivial project, because for these you want a team if nothing else than lowering the bus factor.

If you just do not like physical contact, but work well with telecommuting or on open source mailing lists, then you will have to specialize in those skills allowing for working like that.


问:
Are go-langs goroutine pools just green threads?
The commentator here offers the following criticism of green threads:

I was initially sold on the N:M model as a means of having event driven programming without the callback hell. You can write code that looks like pain old procedural code but underneath there's magic that uses userspace task switching whenever something would block. Sounds great. The problem is that we end up solving complexity with more complexity. swapcontext() and family are fairly strait-forward, the complexity comes from other unintended places.

All of a sudden you're forced to write a userspace scheduler and guess what it's really hard to write a scheduler that's going to do a better job that Linux's schedules that has man years of efforts put into it. Now you want your schedule to man N green threads to M physical threads so you have to worry about synchronization. Synchronization brings performance problems so you start now you're down a new lockless rabbit hole. Building a correct highly concurrent scheduler is no easy task.

Another critique is here:

A single process faking multiple threads has a lot of problems. One of them is that all the faked threads stall on any page fault.

My question is - are go-lang's goroutines (for a default pool) just green threads? If so - do they address the criticisms above?

答:
I'm only a casual Go user, so take the following with a grain of salt.

Wikipedia defines green threads as "threads that are scheduled by a virtual machine (VM) instead of natively by the underlying operating system". Green threads emulate multithreaded environments without relying on any native OS capabilities, and they are managed in user space instead of kernel space, enabling them to work in environments that do not have native thread support.

Go (or more exactly the two existing implementations) is a language producing native code only - it does not use a VM. Furthermore, the scheduler in the current runtime implementations relies on OS level threads (even when GOMAXPROCS=1). So I think talking about green threads for the Go model is a bit abusive.

Go people have coined the goroutine term especially to avoid the confusion with other concurrency mechanisms (such as coroutines or threads or lightweight processes).

Of course, Go supports a M:N threading model, but it looks much closer to the Erlang process model, than to the Java green thread model.

Here are a few benefits of the Go model over green threads (as implemented in early JVM):

Multiple cores or CPUs can be effectively used, in a transparent way for the developer. With Go, the developer should take care of concurrency. The Go runtime will take care of parallelism. Java green threads implementations did not scale over multiple cores or CPUs.

System and C calls are non blocking for the scheduler (all system calls, not only the ones supporting multiplexed I/Os in event loops). Green threads implementations could block the whole process when a blocking system call was done.

Copying or segmented stacks. In Go, there is no need to provide a maximum stack size for the goroutine. The stack grows incrementally as needed. One consequence is a goroutine does not require much memory (4KB-8KB), so a huge number of them can be happily spawned. Goroutine usage can therefore be pervasive.

Now, to address the criticisms:

With Go, you do not have to write a userspace scheduler: it is already provided with the runtime. It is a complex piece of software, but it is the problem of Go developers, not of Go users. Its usage is transparent for Go users. Among the Go developers, Dmitri Vyukov is an expert in lockfree/waitfree programming, and he seems to be especially interested in addressing the eventual performance issues of the scheduler. The current scheduler implementation is not perfect, but it will improve.

Synchronization brings performance problem and complexity: this is partially true with Go as well. But note the Go model tries to promote the usage of channels and a clean decomposition of the program in concurrent goroutines to limit synchronization complexity (i.e. sharing data by communicating, instead of sharing memory to communicate). By the way, the reference Go implementation provides a number of tools to address performance and concurrency issues, like a profiler, and a race detector.

Regarding page fault and "multiple threads faking", please note Go can schedule goroutine over multiple system threads. When one thread is blocked for any reason (page fault, blocking system calls), it does not prevent the other threads to continue to schedule and run other goroutines. Now, it is true that a page fault will block the OS thread, with all the goroutines supposed to be scheduled on this thread. However in practice, the Go heap memory is not supposed to be swapped out. This would be the same in Java: garbage collected languages do not accomodate virtual memory very well anyway. If your program must handle page fault in a graceful way, if it probably because it has to manage some off-heap memory. In that case, wrapping the corresponding code with C accessor functions will simply solve the problem (because again C calls or blocking system calls never block the Go runtime scheduler).

So IMO, goroutines are not green threads, and the Go language and current implementation mostly addresses these criticisms.


答:
So, what's the reason for C Standard to consider const-ness recursively, as it puts it?

From a type perspective alone, not doing so would be unsound (in other words: terribly broken and intentionally unreliable).

And that's because of what "=" means on a struct: it is a recursive assignment. It follows that eventually you have a s1._a = <value> happening "inside the typing rules". If the standard allows this for "nested" const fields, its adding a serious inconsistency in its type system definition as an explicit contradiction (might as well throw the const feature away, as it just became useless and unreliable by its very definition).

Your solution (1), as far as I understand it, is unnecessarily forcing the entire structure to be const whenever one of its fields is const. In this way, s1._b = b would be illegal for a non-const ._b field on a non-const s1 containing a const a.

Title: What's the reason for C standard to consider const-ness recursively?

Body:
The C99 standard says in 6.5.16:2:

An assignment operator shall have a modifiable lvalue as its left
  operand.

and in 6.3.2.1:1:

A modifiable lvalue is an lvalue that does not have array type, does
  not have an incomplete type, does not have a const-qualified type, and
  if it is a structure or union, does not have any member (including,
  recursively, any member or element of all contained aggregates or
  unions) with a const-qualified type.

Now, let's consider a non-const struct with a const field.

```<code>typedef struct S_s {
    const int _a;
} S_t;
</code>```

By standard, the following code is undefined behavior (UB):

```<code>S_t s1;
S_t s2 = { ._a = 2 };
s1 = s2;
</code>```

The semantic problem with this is that the enclosing entity (struct) should be considered writable (non-read-only), judging by the declared type of the entity (S_t s1), but should not be considered writable by the wording of standard (the 2 clauses on the top) because of const field _a. The Standard makes it unclear for a programmer reading the code that the assignment is actually a UB, because it's impossible to tell that w/o the definition of struct S_s ... S_t type.

Moreover, the read-only access to the field is only enforced syntactically anyway. There's no way some const fields of non-const struct are going really be placed to read-only storage. But such wording of standard outlaws the code which deliberately casts away the const qualifier of fields in accessor procedures of these fields, like so (Is it a good idea to const-qualify the fields of structure in C?):

(*)

```<code>#include <stdlib.h>
#include <stdio.h>

typedef struct S_s {
    const int _a;
} S_t;

S_t *
create_S(void) {
    return calloc(sizeof(S_t), 1);
}

void
destroy_S(S_t *s) {
    free(s);
}

const int
get_S_a(const S_t *s) {
    return s->_a;
}

void
set_S_a(S_t *s, const int a) {
    int *a_p = (int *)&s->_a;
    *a_p = a;
}

int
main(void) {
    S_t s1;
    // s1._a = 5; // Error
    set_S_a(&s1, 5); // OK
    S_t *s2 = create_S();
    // s2->_a = 8; // Error
    set_S_a(s2, 8); // OK

    printf("s1.a == %d\n", get_S_a(&s1));
    printf("s2->a == %d\n", get_S_a(s2));

    destroy_S(s2);
}
</code>```

So, for some reason, for an entire struct to be read-only it's enough to declare it const

```<code>const S_t s3;
</code>```

But for an entire struct to be non-read-only it's not enough to declare it w/o const.

What I think would be better, is either:

To constrain the creation of non-const structures with const fields, and issue a diagnostic in such a case. That would make it clear that the struct containing read-only fields is read-only itself.

To define the behavior in case of write to a const field belonging to a non-const struct as to make the code above (*) compliant to the Standard.

Otherwise the behavior is not consistent and hard to understand.

So, what's the reason for C Standard to consider const-ness recursively, as it puts it?


答:
Unfortunately this can be a bit of an issue as it is rare to work on large projects and not have to work on a team. Even if you work on project interdependently you are generally going to be finding that you have to work closer with the end users which all comes back to teamwork, so it is something that is very important.

That said though, as others have pointed out, this is a learn-able skill (to an extent) and if you put the effort into it. There are generally some courses that you can take here in the United States in larger cities to develop leadership skills; however, part of being a good leader is also being a good follower so those skills are developed as well. Likewise, being able to communicate effectively in public is sometimes a skill that people need practice with and is related to teamwork skills but is sometimes glossed over - someone that is unable to communicate effectively might be cited as not being a "team player" even though just need to work on their communication skills a bit.

However, a large part of working with a team is knowing yourself to an extent and being comfortable with yourself as well as with others so sometimes it doesn't hurt to talk to a psychologist or counselor to see if if there is anything you can improve in regards to working with others.

In regards to your career as a whole, here in the United States, having a reputation of "being hard to work with" or "not being a team player" can be extremely detrimental to your long term career prospects and I would hazard a guess that it would be the same in most other countries. This is also a difficult reputation to shake once it has been established without making a move to another company or possibly even another industry depending upon what field you work in.


问:
Should I merge from the same branch or from a merge?
Kind of a best practices question: is it better to merge directly from the source to other branches or is it OK to merge from a merge?

Using Subversion for source control.

Scenario:

Branch A has changes made and committed.

Branch B and the Trunk both need updates.

Case 1

Merge from A to B and again from A to Trunk.

or

Case 2

Merge from A to B and then merge from B to Trunk.

I may also be missing a Case 3 where you merge to B and Trunk Simultaneously (not sure if that is dependent on the source control being used?).

Note that there could be any number of branches that need merging to, such that you could "cascade" the merge (A to B to C to D...).

答:
I think it all depends on how the branches are structured.

1. Branch A and branch B are independent

```<code>branch A      +---------+-------------
             /           \ merge 1
trunk ------+--+----------+--+--------
                \             \ merge 2
branch B         +-------------+------
</code>```

As you can see here, I would merge from branch A to trunk, then merge from trunk to branch B.

2. Branch A is a branch of branch B

```<code>trunk ------+------------------+-----
             \                / merge 2
branch B      +--+--------+--+-------
                  \      / merge 1
branch A           +----+------------
</code>```

In this case, I would merge from branch A to branch B, then merge branch B to trunk.

3. Branch B is a branch of branch A

```<code>trunk ------+------------------+-----
             \                / merge 2
branch A      +--+--------+--+-------
                  \        \ merge 1
branch B           +--------+--------
</code>```

In this final case, I would merge from branch A to branch B, then merge branch A to trunk. Note: order doesn't matter for this case, a merge from branch A to trunk then branch A to branch B would have the same effect.

I guess the key to my thinking is always merge up to parent or merge down to child and avoid merging unrelated or indirect ancestral/descendent branches.

Body:
I think it all depends on how the branches are structured.

1. Branch A and branch B are independent

branch A      +---------+-------------
             /           \ merge 1
trunk ------+--+----------+--+--------
                \             \ merge 2
branch B         +-------------+------

As you can see here, I would merge from branch A to trunk, then merge from trunk to branch B.

2. Branch A is a branch of branch B

trunk ------+------------------+-----
             \                / merge 2
branch B      +--+--------+--+-------
                  \      / merge 1
branch A           +----+------------

In this case, I would merge from branch A to branch B, then merge branch B to trunk.

3. Branch B is a branch of branch A

trunk ------+------------------+-----
             \                / merge 2
branch A      +--+--------+--+-------
                  \        \ merge 1
branch B           +--------+--------

In this final case, I would merge from branch A to branch B, then merge branch A to trunk. Note: order doesn't matter for this case, a merge from branch A to trunk then branch A to branch B would have the same effect.

I guess the key to my thinking is always merge up to parent or merge down to child and avoid merging unrelated or indirect ancestral/descendent branches.


问:
Implementation of algorithm to generate chess positions
I am interested in developing a program that generates an endgame table-base for the chess.

I have gone through the technical papers of the greats like Shannon and Ken Thompson. I have found that retrograde analysis is used for the generation.

How can I generate all positions in a KBBK chess endgame which are mates in 0?

答:
The "mates in 0" would be the positions that the king is in checkmate.  Konrad gave a way to brute-force them through 444k positions, but we can do significantly better than that.

The black king must be on the edge of the board, so that gives 28 positions.  One of the bishops must be giving it check; there are only 7 spots that's possible.  The other bishop must be attacking one of the squares adjacent to the king, there are at most 15 positions for that.  Finally, the opposing king must also be attacking an adjacent square, so there are up to 9 possible spots for it.

After accounting for horizontal- and vertical-symmetry (divide by 4), we get ~6.6k positions to search over.


问:
Can I use Dependency Injection without breaking Encapsulation?
Here is my Solution and projects:

BookStore  (solution)

BookStore.Coupler  (project)

Bootstrapper.cs

BookStore.Domain (project)

CreateBookCommandValidator.cs

CompositeValidator.cs

IValidate.cs

IValidator.cs

ICommandHandler.cs

BookStore.Infrastructure (project)

CreateBookCommandHandler.cs

ValidationCommandHandlerDecorator.cs

BookStore.Web (project)

Global.asax

BookStore.BatchProcesses (project)

Program.cs

Bootstrapper.cs:

```<code>public static class Bootstrapper.cs
{
    // I'm using SimpleInjector as my DI Container
    public static void Initialize(Container container)
    {
        container.RegisterManyForOpenGeneric(typeof(ICommandHandler<>), typeof(CreateBookCommandHandler).Assembly);
        container.RegisterDecorator(typeof(ICommandHandler<>), typeof(ValidationCommandHandlerDecorator<>));
        container.RegisterManyForOpenGeneric(typeof(IValidate<>),
            AccessibilityOption.PublicTypesOnly,
            (serviceType, implTypes) => container.RegisterAll(serviceType, implTypes),
            typeof(IValidate<>).Assembly);
        container.RegisterSingleOpenGeneric(typeof(IValidator<>), typeof(CompositeValidator<>));
    }
}
</code>```

CreateBookCommandValidator.cs

```<code>public class CreateBookCommandValidator : IValidate<CreateBookCommand>
{
    public IEnumerable<IValidationResult> Validate(CreateBookCommand book)
    {
        if (book.Author == "Evan")
        {
            yield return new ValidationResult<CreateBookCommand>("Evan cannot be the Author!", p => p.Author);
        }
        if (book.Price < 0)
        {
            yield return new ValidationResult<CreateBookCommand>("The price can not be less than zero", p => p.Price);
        }
    }
}
</code>```

CompositeValidator.cs

```<code>public class CompositeValidator<T> : IValidator<T>
{
    private readonly IEnumerable<IValidate<T>> validators;

    public CompositeValidator(IEnumerable<IValidate<T>> validators)
    {
        this.validators = validators;
    }

    public IEnumerable<IValidationResult> Validate(T instance)
    {
        var allResults = new List<IValidationResult>();

        foreach (var validator in this.validators)
        {
            var results = validator.Validate(instance);
            allResults.AddRange(results);
        }
        return allResults;
    }
}
</code>```

IValidate.cs

```<code>public interface IValidate<T>
{
    IEnumerable<IValidationResult> Validate(T instance);
}
</code>```

IValidator.cs

```<code>public interface IValidator<T>
{
    IEnumerable<IValidationResult> Validate(T instance);
}
</code>```

ICommandHandler.cs

```<code>public interface ICommandHandler<TCommand>
{
    void Handle(TCommand command);
}
</code>```

CreateBookCommandHandler.cs

```<code>public class CreateBookCommandHandler : ICommandHandler<CreateBookCommand>
{
    private readonly IBookStore _bookStore;

    public CreateBookCommandHandler(IBookStore bookStore)
    {
        _bookStore = bookStore;
    }

    public void Handle(CreateBookCommand command)
    {
        var book = new Book { Author = command.Author, Name = command.Name, Price = command.Price };
        _bookStore.SaveBook(book);
    }
}
</code>```

ValidationCommandHandlerDecorator.cs

```<code>public class ValidationCommandHandlerDecorator<TCommand> : ICommandHandler<TCommand>
{
    private readonly ICommandHandler<TCommand> decorated;
    private readonly IValidator<TCommand> validator;

    public ValidationCommandHandlerDecorator(ICommandHandler<TCommand> decorated, IValidator<TCommand> validator)
    {
        this.decorated = decorated;
        this.validator = validator;
    }

    public void Handle(TCommand command)
    {
        var results = validator.Validate(command);

        if (!results.IsValid())
        {
            throw new ValidationException(results);
        }

        decorated.Handle(command);
    }
}
</code>```

Global.asax

```<code>// inside App_Start()
var container = new Container();
Bootstrapper.Initialize(container);
// more MVC specific bootstrapping to the container. Like wiring up controllers, filters, etc..
</code>```

Program.cs

```<code>// Pretty much the same as the Global.asax
</code>```

Sorry for the long setup to the problem, I have no better way of explaining this other than detailing my actual problem.

I don't want to make my CreateBookCommandValidator public. I would rather it be internal but if I make it internal then I will not be able to register it with my DI Container.  The reason I would like it to be internal is because the only project that should have notion of my IValidate<> implementations are in the BookStore.Domain project.  Any other project just needs to consume IValidator<> and the CompositeValidator should be resolved which will fulfill all validations.

How can I use Dependency Injection without breaking encapsulation?  Or am I going about this all wrong?

答: You can declare CreateBookCommandValidator as internal an apply the InternalsVisibleToAttribute in order to make it visible to the BookStore.Coupler assembly. This also often helps when making unit tests.

OwnerDisplayName: Evan Larsen


答:
Being a good programmer will compensate a little but only a little.  In sixteen years in the industry all the best programmers I've worked with could get on with people - it may not have come naturally to them but they managed it and it was an absolutely key skill.  Those who couldn't were tolerated but in honesty not much more.

For me the main area the ability to work with others comes into play is with users and analysts.  It doesn't matter how well you can code if you're coding the wrong thing and a good working relationship with the people who are defining the product is key to that.

The first step might be to understand a bit more about yourself.  You say you're happy to respect the opinions of others but is this really true?  If it is then why do you imply that you're prone to taking moral positions on issues (which tend to be the opposite of respecting the views of others)?

Generally getting on with others tends to be about ignoring who is right and who is wrong (which believe it or not is irrelevant in 80% of situations) and focusing on doing whatever moves the project forward.


答:
It is not a big deal that the CreateBookCommandValidator class is public.

If you need to create instances of it outside of the library that defines it, it is a pretty natural approach to expose the public class, and count on the clients only using that class as an implementation of IValidate<CreateBookCommand>. (Simply exposing a type does not mean that encapsulation is broken, it just makes it a bit easier for clients to break encapsulation).

Otherwise, if you really want to force clients to not know about the class, you can also use a public static factory method instead of exposing the class, e.g.:

```<code>public static class Validators
{
    public static IValidate<CreateBookCommand> NewCreateBookCommandValidator()
    {
        return new CreateBookCommnadValidator();
    }
}
</code>```

As for registering in your DI container, all DI containers that I know of allow construction by using a static factory method.

Title: Can I use Dependency Injection without breaking Encapsulation?

Body:
Here is my Solution and projects:

BookStore  (solution)

BookStore.Coupler  (project)

Bootstrapper.cs

BookStore.Domain (project)

CreateBookCommandValidator.cs

CompositeValidator.cs

IValidate.cs

IValidator.cs

ICommandHandler.cs

BookStore.Infrastructure (project)

CreateBookCommandHandler.cs

ValidationCommandHandlerDecorator.cs

BookStore.Web (project)

Global.asax

BookStore.BatchProcesses (project)

Program.cs

Bootstrapper.cs:

```<code>public static class Bootstrapper.cs
{
    // I'm using SimpleInjector as my DI Container
    public static void Initialize(Container container)
    {
        container.RegisterManyForOpenGeneric(typeof(ICommandHandler<>), typeof(CreateBookCommandHandler).Assembly);
        container.RegisterDecorator(typeof(ICommandHandler<>), typeof(ValidationCommandHandlerDecorator<>));
        container.RegisterManyForOpenGeneric(typeof(IValidate<>),
            AccessibilityOption.PublicTypesOnly,
            (serviceType, implTypes) => container.RegisterAll(serviceType, implTypes),
            typeof(IValidate<>).Assembly);
        container.RegisterSingleOpenGeneric(typeof(IValidator<>), typeof(CompositeValidator<>));
    }
}
</code>```

CreateBookCommandValidator.cs

```<code>public class CreateBookCommandValidator : IValidate<CreateBookCommand>
{
    public IEnumerable<IValidationResult> Validate(CreateBookCommand book)
    {
        if (book.Author == "Evan")
        {
            yield return new ValidationResult<CreateBookCommand>("Evan cannot be the Author!", p => p.Author);
        }
        if (book.Price < 0)
        {
            yield return new ValidationResult<CreateBookCommand>("The price can not be less than zero", p => p.Price);
        }
    }
}
</code>```

CompositeValidator.cs

```<code>public class CompositeValidator<T> : IValidator<T>
{
    private readonly IEnumerable<IValidate<T>> validators;

    public CompositeValidator(IEnumerable<IValidate<T>> validators)
    {
        this.validators = validators;
    }

    public IEnumerable<IValidationResult> Validate(T instance)
    {
        var allResults = new List<IValidationResult>();

        foreach (var validator in this.validators)
        {
            var results = validator.Validate(instance);
            allResults.AddRange(results);
        }
        return allResults;
    }
}
</code>```

IValidate.cs

```<code>public interface IValidate<T>
{
    IEnumerable<IValidationResult> Validate(T instance);
}
</code>```

IValidator.cs

```<code>public interface IValidator<T>
{
    IEnumerable<IValidationResult> Validate(T instance);
}
</code>```

ICommandHandler.cs

```<code>public interface ICommandHandler<TCommand>
{
    void Handle(TCommand command);
}
</code>```

CreateBookCommandHandler.cs

```<code>public class CreateBookCommandHandler : ICommandHandler<CreateBookCommand>
{
    private readonly IBookStore _bookStore;

    public CreateBookCommandHandler(IBookStore bookStore)
    {
        _bookStore = bookStore;
    }

    public void Handle(CreateBookCommand command)
    {
        var book = new Book { Author = command.Author, Name = command.Name, Price = command.Price };
        _bookStore.SaveBook(book);
    }
}
</code>```

ValidationCommandHandlerDecorator.cs

```<code>public class ValidationCommandHandlerDecorator<TCommand> : ICommandHandler<TCommand>
{
    private readonly ICommandHandler<TCommand> decorated;
    private readonly IValidator<TCommand> validator;

    public ValidationCommandHandlerDecorator(ICommandHandler<TCommand> decorated, IValidator<TCommand> validator)
    {
        this.decorated = decorated;
        this.validator = validator;
    }

    public void Handle(TCommand command)
    {
        var results = validator.Validate(command);

        if (!results.IsValid())
        {
            throw new ValidationException(results);
        }

        decorated.Handle(command);
    }
}
</code>```

Global.asax

```<code>// inside App_Start()
var container = new Container();
Bootstrapper.Initialize(container);
// more MVC specific bootstrapping to the container. Like wiring up controllers, filters, etc..
</code>```

Program.cs

```<code>// Pretty much the same as the Global.asax
</code>```

Sorry for the long setup to the problem, I have no better way of explaining this other than detailing my actual problem.

I don't want to make my CreateBookCommandValidator public. I would rather it be internal but if I make it internal then I will not be able to register it with my DI Container.  The reason I would like it to be internal is because the only project that should have notion of my IValidate<> implementations are in the BookStore.Domain project.  Any other project just needs to consume IValidator<> and the CompositeValidator should be resolved which will fulfill all validations.

How can I use Dependency Injection without breaking encapsulation?  Or am I going about this all wrong?

Body:
It is not a big deal that the CreateBookCommandValidator class is public.

If you need to create instances of it outside of the library that defines it, it is a pretty natural approach to expose the public class, and count on the clients only using that class as an implementation of IValidate<CreateBookCommand>. (Simply exposing a type does not mean that encapsulation is broken, it just makes it a bit easier for clients to break encapsulation).

Otherwise, if you really want to force clients to not know about the class, you can also use a public static factory method instead of exposing the class, e.g.:

public static class Validators
{
    public static IValidate<CreateBookCommand> NewCreateBookCommandValidator()
    {
        return new CreateBookCommnadValidator();
    }
}

As for registering in your DI container, all DI containers that I know of allow construction by using a static factory method.


问:
Optimal "if-else" tree algorithm to minimize duplicate code
I'm having trouble formulating this problem as an algorithm:

I have a set of conditionals (combined with &&) and operations, for example:

```<code>if (A && B)
    execute C
else if (D && A)
    execute E
</code>```

I want an algorithm to find the optimal "if-else" tree that minimizes the amount of duplicate code. The optimal branching for the example above would be:

```<code>if (A){
    if (B)
        execute C
    else if (D)
        execute E
}
</code>```

The cost of duplicate conditionals will be different for each conditional, but it is at least 1. The cost for duplicate operations (e.g. execute C) is 3.

This smells like a minimum spanning tree problem, to me. Or maybe some other known graph theory problem. But I can't figure out how to represent the problem as a graph to begin with.

Here is a comparison of the two "if-else" trees from the example:

答:
Avoid nesting logic into inner blocks as much as possible. It makes code harder to read.

```<code>if (!A)
   return

if (B)
   execute C

if (D)
   execute E
</code>```

Exit if not A. Otherwise B or D, but if you know D is already true when B is false. You could drop the if (D) and just execute E.

In cases like this it's preferred to use a switch.

```<code>if (!A)
   return

switch R
    case B:
       execute C
       break
    case D:
       execute E
       breal
</code>```

Body:
Avoid nesting logic into inner blocks as much as possible. It makes code harder to read.

if (!A)
   return

if (B)
   execute C

if (D)
   execute E

Exit if not A. Otherwise B or D, but if you know D is already true when B is false. You could drop the if (D) and just execute E.

In cases like this it's preferred to use a switch.

if (!A)
   return

switch R
    case B:
       execute C
       break
    case D:
       execute E
       breal


答:
Your behavior is pretty common at your age. I was like you.

The good news is that most of the time, it evolves in the good direction. You will learn how to integrate yourself within a team. You will love it! But I met some people that weren't able to make it and are now stuck is depression.

Depending on the style of management of your company, you will either be rejected by your team or simply fired after a while. So you must be prepared to face some difficulties.

France's most common style of management is based on fear and punishment. This is not a good news for you since it will encourage your individualism. So it will encourage your behavior.

That said, you already know there is a problem with you, so it's a pretty good indication that you have all you need to evolve without external help. The first step is being aware. The second one, the most difficult, is acting on it.


答:
Assuming you don't optimize the conditionals away, you can use a Propositional Directed Acyclic Graph. It can also be considered as a Binary Decision Diagram.

Example of a PDAG:

Leaves are labeled with  (true),  (false), or a
  Boolean variable.

Non-leaves are  (logical and),
   (logical or) and  (logical
  not).

 and  have at least
  one child.

 have exactly one child.

The PDAG allows you to use all the standard graph algorithms on it as appropriate. However, you're probably better off optimizing away any conditionals that you can.

Title: Optimal "if-else" tree algorithm to minimize duplicate code

Body:
I'm having trouble formulating this problem as an algorithm:

I have a set of conditionals (combined with &&) and operations, for example:

```<code>if (A && B)
    execute C
else if (D && A)
    execute E
</code>```

I want an algorithm to find the optimal "if-else" tree that minimizes the amount of duplicate code. The optimal branching for the example above would be:

```<code>if (A){
    if (B)
        execute C
    else if (D)
        execute E
}
</code>```

The cost of duplicate conditionals will be different for each conditional, but it is at least 1. The cost for duplicate operations (e.g. execute C) is 3.

This smells like a minimum spanning tree problem, to me. Or maybe some other known graph theory problem. But I can't figure out how to represent the problem as a graph to begin with.

Here is a comparison of the two "if-else" trees from the example: