答:
There needs to be effectively two branches.

The development branch, which contains just code. As developers are expected to be able to compile the code to produce the DLL's.

The release branch. Which contains just the executables and DLL's.

In the middle, overnight, you can use a continuous integration server to build the latest version and commit the DLL's/Exe's etc to the release branch, and tag those items with a version/release number.

The release branch doesnt need to be SVN. but you can do so if you wish. It does mean that people can find previous revisions quickly.

My personal opinion is that any developer should be able to sit down, sync the head of the development branch, be able to compile the source, and run it. If this isnt possible, you need to make it possible. Either by fixing the project structure, or providing binary DLL's of code that developers are not expected to recompile. (library DLL's etc).

Title: What is the proper aproach of Subversion when using DLL

Body:
Background:

Our team develops a solution and it includes a number of projects. Most of the projects are built as DLLs and those DLLs are used by the rest of the projects.

Currently we uses Subversion for our code management and I ask others to remove DLLs from Subversion because we do not need to keep the history of the DLLs. So I ask my team to update their source every morning from Subversion and build each project to get DLL with yesterday submitted changes.

Issue:

This procedure was very good in the beginning f the project. but now each project of the solution getting bigger and bigger.Also gets more time to compile. now each developer waste around 20 mins each morning for build solution in their local computer.

Now I'm thinking again to ask each developer to submit their built DLLs to Subversion at end of the day and the next morning the rest of the users can download these DLLs directly from Subversion.

But I feel something is wrong with this procedure. Because Subversion waste space keeping the history records of each DLLs. Now I'm searching for a better solution.

Do you guys have any idea over your experience?


问:
Recommended guidelines for declaring bash/sh variables
I have been programming in BASH for a while now and the scripts that I write are starting to get more complicated.

I realized that I started to bring in some habits from C/C++ and wanted to get confirmation on if I needed to break my current habits or not. The reason being, not all programming languages are the same and they should be used to capitalize on their strengths.

Using Variables

```<code>function()
{
    #declaration block
    runCommand=

    for string in "$@"; do
        runCommand="$runCommand $string"
    done
}
</code>```

vs

```<code>function()
{
    for string in "$@"; do
        runCommand="$runCommand $string"
    done
}
</code>```

Which is advised for BASH/SH and for what reasons?

I have currently referred to the following websites.

http://lug.fh-swf.de/vim/vim-bash/StyleGuideShell.en.pdf

https://stackoverflow.com/questions/15610794/bash-coding-conventions

http://wiki.bash-hackers.org/scripting/style

Edit: My question was a little unclear so I changed the code example a little bit.

答:
Some things I like to do to keep my scripts maintainable:

use functions

Instead of putting everything into one giant script file create several small functions

Example:

```<code>main() {
  # put logic here
}

main "$@" # pass commandline args to main function
</code>```

within functions, declare variables with the local modifier

```<code>main() {
  local result

  (($1 > 10) && result="greater than" || result="less than"
}

echo "$result" # result is not visible outside main
</code>```

variables in bash are not block scoped but lexically scoped so putting them into 'blocks' doesn't buy you much (bash actually has no blocks)

```<code> for i in {1..10}; do
   result=((result + i))
 done

 echo "$result" # still visible here
</code>```

still I think declaring variables at the point where they are needed is best

To come back to your example the loop is actually unnecessary. If you want to execute a command with "$@" as parameters just do

```<code>"$runCommand" "$@"
</code>```

ContentLicense: CC BY-SA 3.0

Body:
Some things I like to do to keep my scripts maintainable:

use functions

Instead of putting everything into one giant script file create several small functions

Example:

main() {
  # put logic here
}

main "$@" # pass commandline args to main function

within functions, declare variables with the local modifier

main() {
  local result

  (($1 > 10) && result="greater than" || result="less than"
}

echo "$result" # result is not visible outside main

variables in bash are not block scoped but lexically scoped so putting them into 'blocks' doesn't buy you much (bash actually has no blocks)

 for i in {1..10}; do
   result=((result + i))
 done

 echo "$result" # still visible here

still I think declaring variables at the point where they are needed is best

To come back to your example the loop is actually unnecessary. If you want to execute a command with "$@" as parameters just do

"$runCommand" "$@"


问:
Should you hard code your data across all unit tests?
Most unit testing tutorials/examples out there usually involve defining the data to be tested for each individual test. I guess this is part of the "everything should be tested in isolation" theory.

However I've found that when dealing with multitier applications with a lot of DI, the code required for setting up each test gets very long winded. Instead I've built a number of testbase classes which I can now inherit which has a lot of test scaffolding pre-built.

As part of this, I'm also building fake datasets which represent the database of a running application, albeit with usually only one or two rows in each "table".

Is it an accepted practice to predefine, if not all, then the majority of the test data across all the unit tests?

Update

From the comments below it does feel like I'm doing more integration than unit testing.

My current project is ASP.NET MVC, using Unit of Work over Entity Framework Code First, and Moq for testing. I've mocked the UoW, and the repositories, but I'm using the real business logic classes, and testing the controller actions. The tests will often check that the UoW has been committed, e.g:

```<code>[TestClass]
public class SetupControllerTests : SetupControllerTestBase {
  [TestMethod]
  public void UserInvite_ExistingUser_DoesntInsertNewUser() {
    // Arrange
    var model = new Mandy.App.Models.Setup.UserInvite() {
      Email = userData.First().Email
    };

    // Act
    setupController.UserInvite(model);

    // Assert
    mockUserSet.Verify(m => m.Add(It.IsAny<UserProfile>()), Times.Never);
    mockUnitOfWork.Verify(m => m.Commit(), Times.Once);
  }
}
</code>```

SetupControllerTestBase is building the mock UoW, and instantiating the userLogic.

A lot of the tests require having an existing user or product in the database, so I've pre-populated what the mock UoW returns, in this example userData, which is just an IList<User> with a single user record.

答:
Whatever makes the intent of your test more readable.

As a general rule of thumb:

If the data is part of the test (eg. Should not print rows with a state of 7) then code it in the test, so that it's clear what the author intended to happen.

If the data is just filler to make sure it has something to work with (eg. Should not mark record as complete if processing service throws exception) then by all means have a BuildDummyData method or a test class that keeps irrelevant data out of the test.

But note that I'm struggling to think of a good example of the latter. If you have many of these in a unit-test fixture, you probably have a different problem to solve ... perhaps the method under test is too complex.

ContentLicense: CC BY-SA 4.0


答:
If you are writing tests that involve a lot of DI and wiring, up to using "real" datasources, you probably left the area of plain unit testing and entered the domain of integration testing.

For integration tests, I think, it is not bad idea to have common data setup logic. The main goal of such tests is to prove that everything is correctly configured. This is rather independent of the concrete data sent through your system.

For Unit tests on the other hand, I would recommend to keep the target of a test class a single "real" class and mock everything else away. Then you should really hard-code the test data to make sure you covered as many special/previous-bug paths as possible.

To add a semi-hard-coded/random element to tests, I like to introduce random model factories. In a test using an instance of my model, I then use these factories to create a valid, but completely random model object and then hard-code only the properties that are of interest for the test at hand. This way you specify all relevant data directly in your test, while saving you the need of also specifying all irrelevant data and (to a certain degree) test that there are no unintended dependencies on other model fields.

Title: Should you hard code your data across all unit tests?

Body:
Most unit testing tutorials/examples out there usually involve defining the data to be tested for each individual test. I guess this is part of the "everything should be tested in isolation" theory.

However I've found that when dealing with multitier applications with a lot of DI, the code required for setting up each test gets very long winded. Instead I've built a number of testbase classes which I can now inherit which has a lot of test scaffolding pre-built.

As part of this, I'm also building fake datasets which represent the database of a running application, albeit with usually only one or two rows in each "table".

Is it an accepted practice to predefine, if not all, then the majority of the test data across all the unit tests?

Update

From the comments below it does feel like I'm doing more integration than unit testing.

My current project is ASP.NET MVC, using Unit of Work over Entity Framework Code First, and Moq for testing. I've mocked the UoW, and the repositories, but I'm using the real business logic classes, and testing the controller actions. The tests will often check that the UoW has been committed, e.g:

```<code>[TestClass]
public class SetupControllerTests : SetupControllerTestBase {
  [TestMethod]
  public void UserInvite_ExistingUser_DoesntInsertNewUser() {
    // Arrange
    var model = new Mandy.App.Models.Setup.UserInvite() {
      Email = userData.First().Email
    };

    // Act
    setupController.UserInvite(model);

    // Assert
    mockUserSet.Verify(m => m.Add(It.IsAny<UserProfile>()), Times.Never);
    mockUnitOfWork.Verify(m => m.Commit(), Times.Once);
  }
}
</code>```

SetupControllerTestBase is building the mock UoW, and instantiating the userLogic.

A lot of the tests require having an existing user or product in the database, so I've pre-populated what the mock UoW returns, in this example userData, which is just an IList<User> with a single user record.


答:
Different methods of testing

First define what you are doing: Unit testing or integration testing. The number of layers is irrelevant for unit testing since you only test one class most likely. The rest you mock out. For integration testing it is inevitable that you test multiple layers. If you have good unit tests in place the trick is to make the integration tests not too complex.

If your unit tests are good you don't have to repeat testing all details when doing integration testing.

Terms we use, those are a bit platform dependent, but you can find them in almost all test / development platforms:

Fixture: http://book.cakephp.org/2.0/en/development/testing.html#fixtures

Mock: http://book.cakephp.org/2.0/en/development/testing.html#mocking-model-methods

Example application

Depending on the technology you use the names may differ, but I will use this as an example:

If you have a simple CRUD application with model Product, ProductsController, and an index view which generates an HTML table with products:

The end result of the application is showing an HTML table with a list of all products which are active.

Unit testing

Model

The model you can test quite easily. There are different methods for it; we use fixtures. I think that's what you call "fake datasets". So before each test is run we create the table, and put in the original data. Most platforms have methods for this. For example, in your test class, a method setUp() which is run before each test.

Then we run our test, for example: testGetAllActive products.

So we test directly to a test database. We do not mock out the datasource; we make it always the same. This allows us for example to test with a new version of the database, and any query issues will come up.

In the real world you cannot always follow 100% single responsibility. If you want to do this even better you could use a datasource which you mock. For us (we use an ORM) that feels like testing already existing technology. Also the tests become much more complex, and they don't really test the queries. So we keep it this way.

The hard coded data is separately stored in the fixtures. So the fixture is like an SQL file with a create table statement and inserts for the records we use. We keep them small unless there is a real need to test with lots of records.

```<code>class ProductModel {
  public function getAllActive() {
    return $this->find('all', array('conditions' => array('active' => 1)));
  }
}
</code>```

Controller

The controller needs more work, because we don't want to test the model with it. So what we do is mock the model. That means: We test: index() method which should return a list of records.

So we mock the model method getAllActive() out and add fixed data in it (two records for example). Now we test the data the controller sends to the view, and we compare if we really get those two records back.

```<code>function testProductIndexLoggedIn() {
  $this->setLoggedIn();
  $this->ProductsController->mock('ProductModel', 'index', function(return array(your records) ));
  $result=$this->ProductsController->index();
  $this->assertEquals(2, count($result['products']));
}
</code>```

That's enough. We try to add as little functionality to the controller because that makes testing hard. But of course there is always some code in it. For example, we test requirements like: Show those two records only if you are logged in.

So, the controller needs one mock normally and a small piece of hardcoded data. For a login system maybe another one. In our test we have a helper method for it: setLoggedIn(). That makes it simple to test with login or without login.

```<code>class ProductsController {
  public function index() {
    if($this->loggedIn()) {
      $this->set('products', $this->ProductModel->getAllActive());
    }
  }
}
</code>```

Views

Views testing is hard. First we separate out logic which repeats. We put it in Helpers and test those classes strict. We expect always the same output. For example, generateHtmlTableFromArray().

Then we have some project specific views. We don't test those. It is not really desired to unit test those. We keep them for integration tests. Because we took out a lot of the code into views we have a lower risk here.

If you start testing those you likely need to change your tests every time you change a piece of HTML which is not useful for most projects.

```<code>echo $this->tableHelper->generateHtmlTableFromArray($products);
</code>```

Integration testing

Depending on you platform here you can work with users stories, etc. It could be webbased like Selenium or other comparable solutions.

Generally we just load the database with the fixtures and assert which data should be available. For full integration testing we generally use very global requirements. So: Set product to active and then check if the product becomes available.

We don't test everything again, like whether the right fields are available. We test the bigger requirements here. Since we do not want to duplicate our tests from the controller or view. If something is really key / core part of you application or for security reasons (check password is NOT available) then we add them to ensure it's right.

The hard coded data is stored in the fixtures.

```<code>function testIntegrationProductIndexLoggedIn() {
  $this->setLoggedIn();
  $result=$this->request('products/index');

  $expected='<table';
  $this->assertContains($expected, $result);

  // Some content from the fixture record
  $expected='<td>Product 1 name</td>';
  $this->assertContains($expected, $result);
}
</code>```

Body:
Different methods of testing

First define what you are doing: Unit testing or integration testing. The number of layers is irrelevant for unit testing since you only test one class most likely. The rest you mock out. For integration testing it is inevitable that you test multiple layers. If you have good unit tests in place the trick is to make the integration tests not too complex.

If your unit tests are good you don't have to repeat testing all details when doing integration testing.

Terms we use, those are a bit platform dependent, but you can find them in almost all test / development platforms:

Fixture: http://book.cakephp.org/2.0/en/development/testing.html#fixtures

Mock: http://book.cakephp.org/2.0/en/development/testing.html#mocking-model-methods

Example application

Depending on the technology you use the names may differ, but I will use this as an example:

If you have a simple CRUD application with model Product, ProductsController, and an index view which generates an HTML table with products:

The end result of the application is showing an HTML table with a list of all products which are active.

Unit testing

Model

The model you can test quite easily. There are different methods for it; we use fixtures. I think that's what you call "fake datasets". So before each test is run we create the table, and put in the original data. Most platforms have methods for this. For example, in your test class, a method setUp() which is run before each test.

Then we run our test, for example: testGetAllActive products.

So we test directly to a test database. We do not mock out the datasource; we make it always the same. This allows us for example to test with a new version of the database, and any query issues will come up.

In the real world you cannot always follow 100% single responsibility. If you want to do this even better you could use a datasource which you mock. For us (we use an ORM) that feels like testing already existing technology. Also the tests become much more complex, and they don't really test the queries. So we keep it this way.

The hard coded data is separately stored in the fixtures. So the fixture is like an SQL file with a create table statement and inserts for the records we use. We keep them small unless there is a real need to test with lots of records.

class ProductModel {
  public function getAllActive() {
    return $this->find('all', array('conditions' => array('active' => 1)));
  }
}

Controller

The controller needs more work, because we don't want to test the model with it. So what we do is mock the model. That means: We test: index() method which should return a list of records.

So we mock the model method getAllActive() out and add fixed data in it (two records for example). Now we test the data the controller sends to the view, and we compare if we really get those two records back.

function testProductIndexLoggedIn() {
  $this->setLoggedIn();
  $this->ProductsController->mock('ProductModel', 'index', function(return array(your records) ));
  $result=$this->ProductsController->index();
  $this->assertEquals(2, count($result['products']));
}

That's enough. We try to add as little functionality to the controller because that makes testing hard. But of course there is always some code in it. For example, we test requirements like: Show those two records only if you are logged in.

So, the controller needs one mock normally and a small piece of hardcoded data. For a login system maybe another one. In our test we have a helper method for it: setLoggedIn(). That makes it simple to test with login or without login.

class ProductsController {
  public function index() {
    if($this->loggedIn()) {
      $this->set('products', $this->ProductModel->getAllActive());
    }
  }
}

Views

Views testing is hard. First we separate out logic which repeats. We put it in Helpers and test those classes strict. We expect always the same output. For example, generateHtmlTableFromArray().

Then we have some project specific views. We don't test those. It is not really desired to unit test those. We keep them for integration tests. Because we took out a lot of the code into views we have a lower risk here.

If you start testing those you likely need to change your tests every time you change a piece of HTML which is not useful for most projects.

echo $this->tableHelper->generateHtmlTableFromArray($products);

Integration testing

Depending on you platform here you can work with users stories, etc. It could be webbased like Selenium or other comparable solutions.

Generally we just load the database with the fixtures and assert which data should be available. For full integration testing we generally use very global requirements. So: Set product to active and then check if the product becomes available.

We don't test everything again, like whether the right fields are available. We test the bigger requirements here. Since we do not want to duplicate our tests from the controller or view. If something is really key / core part of you application or for security reasons (check password is NOT available) then we add them to ensure it's right.

The hard coded data is stored in the fixtures.

function testIntegrationProductIndexLoggedIn() {
  $this->setLoggedIn();
  $result=$this->request('products/index');

  $expected='<table';
  $this->assertContains($expected, $result);

  // Some content from the fixture record
  $expected='<td>Product 1 name</td>';
  $this->assertContains($expected, $result);
}


问:
How have languages influenced CPU design?
We are often told that the hardware doesn't care what language a program is written in as it only sees the compiled binary code, however this is not the whole truth. For example, consider the humble Z80; its extensions to the 8080 instruction set include instructions like CPIR which is useful for scanning C-style (NULL-terminated) strings, e.g. to perform strlen(). The designers must have identified that running C programs (as opposed to Pascal, where the length of a string is in the header) was something that their design was likely to be used for. Another classic example is the Lisp Machine.

What other examples are there? E.g. instructions, number and type of registers, addressing modes, that make a particular processor favour the conventions of a particular language? I am particularly interested in revisions of the same family.

答:
Atmel's AVR architecture is entirely designed from the ground up to be suitable for programming in C. For example, this application note elaborates further.

IMO this is closely related with rockets4kids'es excellent answer, with early PIC16-s being developed for direct assembler programming (40 instructions total), with later families targeting C.


答:
If you don't want that inherited environment variables are used as initial values, it is important to initialize the variables you are using (or unset them explicitly).  An environment variable named "runCommand" will not influence your first snipset, it will be used in your second one.  (That may be a feature, but you have to be aware of it).

And you need to be aware that this is true also for variables which are interpreted by the shell (IFS for instance).

Title: Recommended guidelines for declaring bash/sh variables

Body:
I have been programming in BASH for a while now and the scripts that I write are starting to get more complicated.

I realized that I started to bring in some habits from C/C++ and wanted to get confirmation on if I needed to break my current habits or not. The reason being, not all programming languages are the same and they should be used to capitalize on their strengths.

Using Variables

```<code>function()
{
    #declaration block
    runCommand=

    for string in "$@"; do
        runCommand="$runCommand $string"
    done
}
</code>```

vs

```<code>function()
{
    for string in "$@"; do
        runCommand="$runCommand $string"
    done
}
</code>```

Which is advised for BASH/SH and for what reasons?

I have currently referred to the following websites.

http://lug.fh-swf.de/vim/vim-bash/StyleGuideShell.en.pdf

https://stackoverflow.com/questions/15610794/bash-coding-conventions

http://wiki.bash-hackers.org/scripting/style

Edit: My question was a little unclear so I changed the code example a little bit.


问:
What is the difference between HaXe NME and OpenFL?
On http://en.wikipedia.org/wiki/NME_%28framework%29 there is an info:

NME is an open-source game and application framework that supports
  iOS, Android, BlackBerry, Microsoft Windows, Mac OS X, Linux, Flash
  Player and HTML5, with legacy compatibility for webOS.

On OpenFL website ( http://www.openfl.org/about/overview/ ), is this info:

OpenFL is a software development kit that provides an environment for
  building fast, native games and applications for iOS, Android,
  BlackBerry, Windows, Mac, Linux, Flash and HTML5.

The link to the website of HaXe NME (on wikipage), redirects to website of OpenFL, and on that website, is zero informations about HaXe NME, it looks like it doesn't have its own website and any documentation. I have impression that both do kinda the same thing - enable easy compilation to the same platforms, but are clearly two different libraries in haxelib, so - what is the difference between them? How they relate to each other?

答:
From what i've understood, OpenFL is basically a better version of NME and has replaced it.

It gives you access to most of the Flash graphics API which is rendered via OpenGL, WebGL etc. depending on the target.

It's higher level on the user side and lower level on the rendering side, improving usability, performance, crossplatform compatibility etc.

As a developer, you needn't worry about the change, you update the imports in your project and it should compile just like NME used to.


问:
Is it ok to learn from C# 2002 materials?
I've found some videos that explain C# but it back to C#.NET when it is first appeared, if I learn from these videos will I learn something that has been removed from the language? will I miss alot? </p>

答:
You 'can', but in my opinion, don't waste your time.

Buy a new book, or go to current websites, and get current information.

ContentLicense: CC BY-SA 2.5


问:
Why can't the IT industry deliver large, faultless projects quickly as in other industries?
After watching National Geographic's MegaStructures series, I was surprised how fast large projects are completed. Once the preliminary work (design, specifications, etc.) is done on paper, the realization itself of huge projects takes just a few years or sometimes a few months.

For example, Airbus A380 "formally launched on Dec. 19, 2000", and "in the Early March, 2005", the aircraft was already tested. The same goes for huge oil tankers, skyscrapers, etc.

Comparing this to the delays in the software industry, I can't help wondering why most IT projects are so slow, or more precisely, why they cannot be as fast and faultless, at the same scale, given enough people?

Projects such as the Airbus A380 present both:

Major unforeseen risks: while this is not the first aircraft built, it still pushes the limits of the technology and things which worked well for smaller airliners may not work for the larger one due to physical constraints; in the same way, new technologies are used which were not used before, because for example they were not available in 1969 when the Boeing 747 was certified.

Risks related to human resources and management in general: people quitting in the middle of the project, inability to reach a person because she's on vacation, ordinary human errors, etc.

With those risks, people still achieve projects like those large airliners in a very short period of time, and despite the delivery delays, those projects are still hugely successful and of a high quality.

When it comes to software development, the projects are hardly as large and complicated as an airliner (both technically and in terms of management), and have slightly less unforeseen risks from the real world.

Still, most IT projects are slow and late, and adding more developers to the project is not a solution (going from a team of ten developers to two thousand will sometimes make it possible to deliver the project faster, sometimes not, and sometimes will only harm the project and increase the risk of not finishing it at all).

Those which are still delivered may often contain a lot of bugs, requiring consecutive service packs and regular updates (imagine "installing updates" on every Airbus A380 twice a week to patch the bugs in the original product to prevent the aircraft from crashing).

How can such differences be explained? Is it due exclusively to the fact that the software development industry is too young to be able to manage thousands of people on a single project in order to deliver large scale, nearly faultless products very fast?

答:
I will try answering using a verbatim copy of an article from Jack Ganssle's embedded muse. While this says firmware everywhere, just mentally replace it by software.

Compared to What?

Firmware is the most expensive thing in the universe. In his wonderful
  book "Augustine's Laws," Norman Augustine, former Lockheed Martin CEO,
  tells a revealing story about a problem encountered by the defense
  community. A high performance fighter aircraft is a delicate balance
  of conflicting needs: fuel range vs. performance. Speed vs. weight. It
  seems that by the late 70s fighters were at about as heavy as they'd
  ever be. Contractors, always pursuing larger profits, looked in vain
  for something they could add that cost a lot, but which weighed
  nothing.

The answer: firmware. Infinite cost, zero mass. Avionics now accounts
  for more than half of a fighter's cost. That's a chunk of change when
  you consider the latest American fighter, the F-22, costs a cool third
  of a billion a pop. Augustine practically chortles with glee when he
  relates this story.

But why is software so expensive? Tom DeMarco once answered this
  question with these three words: compared to what? He went on to
  discuss relatively boring business cases, but that answer has
  resonated in my mind for years. Compared to what? With software we
  routinely create product behaviors of unprecedented complexity. Sure,
  the code's expensive. But never in the history of civilization has
  anyone built anything so intricate.

Consider the following bubble sort, lifted shamelessly from Wikipedia
  and not checked for accuracy:

```<code>void bubblesort(int * A, int n){

    for(int i(0); i < n; ++i)

        for(int j(0); j < n - i - 1; ++j)

            if(A[j] > A[j + 1])

                std::swap(A[j], A[j + 1]);

}
</code>```

It's a mere 110 non-space characters, perhaps tossed off in an hour or
  two. Suppose we didn't have software and had to implement a sort using
  some other strategy. What would it cost?

A mechanical engineer might boast that his profession built sorters
  long before computers. Consider IBM's 1949-era model 82 card sorter
  (http://www.columbia.edu/acis/history/sorter.html) with a throughput
  of 650 cards per minute, rather less than our code snippet might
  manage even on a 4 MHz Z80. The model 82, of course, only sorted one
  column of a card at a time; to completely sort a deck could take
  dozens of passes.

How long did it take to design and build this beast? Years, no doubt.
  And its functionality pales compared to our code which is so much
  faster and which can handle gigantic datasets. But that was 1949. How
  long would it take to build a bubble sort from electronic components -
  without FPGAs and VHDL, or a CPU?

In an hour I managed a rough block diagram, one above the chip level
  (blocks have names like "adder," "16 bit latch" and the like). But the
  sequencing logic is clearly pretty messy so I've just tossed in a PLD,
  assuming at some point it wouldn't be too hard to write the
  appropriate equations. And, yes, perhaps that breaks the
  no-programmable-logic rule, but to design and debug all that logic
  using gates in any reasonable amount of time is as unlikely as
  buck-a-gallon gas.

Assuming 16 bit words and addresses, the circuit will need around a
  dozen 16 bit latches, adders, and the like. Plus memory. And I have no
  idea how the unsorted data arrives into the RAM or how the results get
  exported. Those are unspecified design requirements.  The
  software-only solution naturally resolves these requirements just by
  the act of writing the function prototype.

Translating the rough block diagram to a schematic might take a day.
  Then there's the time to design and produce a PCB, order and load
  parts (and change the design to deal with the unexpected but
  inevitable end-of-life issues), and then of course make the circuit
  work. We could be talking weeks of effort and a lot of money for the
  board, parts and appropriate test equipment.

All this to replace 7 little lines of code. Few real embedded programs
  are less than 10,000; many exceed a million. How much hardware and how
  much engineering would be needed to replace a real, super-sized
  computer program?

Consider a real program like a spreadsheet. How much circuitry would
  it take to make one without a processor? It could be the size of a
  city.

Firmware is the most expensive thing in the universe, but only because
  of the unimaginable complexity of the problems it solves. But it's
  vastly cheaper than any alternative. So when your boss irritably asks
  why the software takes so long, you know what to say.
  Compared to what?

So there! Software/firmware has unparalleled complexity.

Body:
I will try answering using a verbatim copy of an article from Jack Ganssle's embedded muse. While this says firmware everywhere, just mentally replace it by software.

Compared to What?

Firmware is the most expensive thing in the universe. In his wonderful
  book "Augustine's Laws," Norman Augustine, former Lockheed Martin CEO,
  tells a revealing story about a problem encountered by the defense
  community. A high performance fighter aircraft is a delicate balance
  of conflicting needs: fuel range vs. performance. Speed vs. weight. It
  seems that by the late 70s fighters were at about as heavy as they'd
  ever be. Contractors, always pursuing larger profits, looked in vain
  for something they could add that cost a lot, but which weighed
  nothing.

The answer: firmware. Infinite cost, zero mass. Avionics now accounts
  for more than half of a fighter's cost. That's a chunk of change when
  you consider the latest American fighter, the F-22, costs a cool third
  of a billion a pop. Augustine practically chortles with glee when he
  relates this story.

But why is software so expensive? Tom DeMarco once answered this
  question with these three words: compared to what? He went on to
  discuss relatively boring business cases, but that answer has
  resonated in my mind for years. Compared to what? With software we
  routinely create product behaviors of unprecedented complexity. Sure,
  the code's expensive. But never in the history of civilization has
  anyone built anything so intricate.

Consider the following bubble sort, lifted shamelessly from Wikipedia
  and not checked for accuracy:

void bubblesort(int * A, int n){

    for(int i(0); i < n; ++i)

        for(int j(0); j < n - i - 1; ++j)

            if(A[j] > A[j + 1])

                std::swap(A[j], A[j + 1]);

}

It's a mere 110 non-space characters, perhaps tossed off in an hour or
  two. Suppose we didn't have software and had to implement a sort using
  some other strategy. What would it cost?

A mechanical engineer might boast that his profession built sorters
  long before computers. Consider IBM's 1949-era model 82 card sorter
  (http://www.columbia.edu/acis/history/sorter.html) with a throughput
  of 650 cards per minute, rather less than our code snippet might
  manage even on a 4 MHz Z80. The model 82, of course, only sorted one
  column of a card at a time; to completely sort a deck could take
  dozens of passes.

How long did it take to design and build this beast? Years, no doubt.
  And its functionality pales compared to our code which is so much
  faster and which can handle gigantic datasets. But that was 1949. How
  long would it take to build a bubble sort from electronic components -
  without FPGAs and VHDL, or a CPU?

In an hour I managed a rough block diagram, one above the chip level
  (blocks have names like "adder," "16 bit latch" and the like). But the
  sequencing logic is clearly pretty messy so I've just tossed in a PLD,
  assuming at some point it wouldn't be too hard to write the
  appropriate equations. And, yes, perhaps that breaks the
  no-programmable-logic rule, but to design and debug all that logic
  using gates in any reasonable amount of time is as unlikely as
  buck-a-gallon gas.

Assuming 16 bit words and addresses, the circuit will need around a
  dozen 16 bit latches, adders, and the like. Plus memory. And I have no
  idea how the unsorted data arrives into the RAM or how the results get
  exported. Those are unspecified design requirements.  The
  software-only solution naturally resolves these requirements just by
  the act of writing the function prototype.

Translating the rough block diagram to a schematic might take a day.
  Then there's the time to design and produce a PCB, order and load
  parts (and change the design to deal with the unexpected but
  inevitable end-of-life issues), and then of course make the circuit
  work. We could be talking weeks of effort and a lot of money for the
  board, parts and appropriate test equipment.

All this to replace 7 little lines of code. Few real embedded programs
  are less than 10,000; many exceed a million. How much hardware and how
  much engineering would be needed to replace a real, super-sized
  computer program?

Consider a real program like a spreadsheet. How much circuitry would
  it take to make one without a processor? It could be the size of a
  city.

Firmware is the most expensive thing in the universe, but only because
  of the unimaginable complexity of the problems it solves. But it's
  vastly cheaper than any alternative. So when your boss irritably asks
  why the software takes so long, you know what to say.
  Compared to what?

So there! Software/firmware has unparalleled complexity.


答:
Ultimately, you want to write as little code as possible to get as much outcome as possible. Having a lot of the same code in multiple tests a) tends to result in copy-paste coding and b) means that if a method signature changes you can end up having to fix a lot of broken tests.

I use the approach of having standard TestHelper classes that provide me with a lot of the data types that I routinely use, so I can create sets of standard entity or DTO classes for my tests to query and know exactly what I will get each time. So I can call TestHelper.GetFooRange( 0, 100 ) to get a range of 100 Foo objects with all their dependent classes/fields set.

Particularly where there are complex relationships configured in an ORM type system which need to be present for things to run correctly, but aren't necessarily significant for this test that can save a lot of time.

In situations where I'm testing close to the data level, I sometimes create a test version of my repository class that can be queried in a similar way (again this is in an ORM type environment, and it wouldn't be relevant against a real database), because mocking out the exact responses to queries is a lot of work and often only provides minor benefits.

There are some things to be careful of, though in unit tests:

Make sure your mocks are mocks. The classes that perform operations around the class being tested must be mock objects if you are doing unit testing. Your DTO/entity type classes can be the real thing, but if classes are performing operations you need to be mocking them- otherwise when the supporting code changes and your tests start failing, you have to search for a lot longer to figure out which change actually caused the problem.

Make sure you are testing your classes. Sometimes if one looks through a suite of unit tests it becomes apparent that half of the tests are actually testing the mocking framework more than the actual code that they are supposed to be testing.

Don't reuse mock/supporting objects This is a biggie- when one starts trying to get clever with code supporting unit tests it is really easy to inadvertently create objects that persist between tests, which can have unpredictable effects. For example, yesterday I had a test that passed when run on its own, passed when all tests in the class were run, but failed when the entire test suite was run. It turned out there was a sneaky static object way off in a test helper that, when I created it, would definitely never have caused a problem. Just remember: At the start of the test, everything is created, at the end of the test everything is destroyed.


问:
What is a good strategy for binding view objects to model objects in C++?
Imagine I have a rich data model that is represented by a hierarchy of objects.

I also have a view hierarchy with views that can extract required data from model objects and display the data (and allow the user to manipulate the data).

Actually, there could be multiple view hierarchies that can represent and manipulate the model (e.g. an overview-detail view and a direct manipulation view).

My current approach for this is for the controller layer to store a reference to the underlying model object in the View object. The view object can then get the current data from the model for display, and can send the model object messages to update the data. View objects are effectively observers of the model objects and the model objects broadcast notifications when properties change.

This approach allows all the views to update simultaneously when any view changes the model.

Implemented carefully, this all works. However, it does require a lot of work to ensure that no view or model objects hold any stale references to model objects. The user can delete model objects or sub-hierarchies of the model at any time. Ensuring that all the view objects that hold references to the model objects that have been deleted is time-consuming and difficult.

It feels like the approach I have been taking is not especially clean; while I don't want to have to have explicit code in the controller layer for mediating the communication between the views and the model, it seems like there must be a better (implicit) approach for establishing bindings between the view and the model and between related model objects.

In particular, I am looking for an approach (in C++) that understands two key points:

There is a many to one relationship between view and model objects

If the underlying model object is destroyed, all the dependent view objects must be cleaned up so that no stale references exist

While shared_ptr and weak_ptr can be used to manage the lifetimes of the underlying model objects and allows for weak references from the view to the model, they don't provide for notification of the destruction of the underlying object (they do in the sense that the use of a stale weak_ptr allows for notification), but I need an approach that notifies the dependent objects that their weak reference is going away.

Can anyone suggest a good strategy to manage this?

答:
Be aware that you're accurately describing the observer design pattern, given the domain model object to be the subject and the views to be observers. Note also that the observer pattern implies a higher level of abstraction than a smart pointer, and that there is no direct conceptual correspondence between the two of them.

In order to implement this pattern, you must firstly ensure that all the involved views (observers) implement a common interface, for example by inheriting a common base, abstract class. Then, the domain object (subject) can proceed with managing a set of references to instances of that said observer interface, and notifying them all when required, by calling the appropriate interface methods.

Smart pointers can be used in this scheme to implement the references managed by the subject.


问:
Why do we study Java at university?
Java is often found in academia. What is the reason behind that? </p>

答:
A few Universities have somebody who's sufficiently well known that many (if not most) decisions revolve around that person's likes, dislikes, opinions, taste, etc. Just for example, Texas A&M has Bjarne Stroustrup on staff; it probably comes as little surprise to anybody that their curriculum tends to emphasize C++.

Most universities are a bit different though. First, decisions are often made much more for the benefit of the faculty than the students. The single biggest criterion in many cases is "which language requires the least effort on our part?" Most of them are also careful in their laziness -- they want not only the language with the fewest advanced concepts to learn, but also one that is (for example) the slowest to innovate, update, or embrace anything new.

Second, most decisions are made by committee. This means the final decision is rarely (if ever) what anybody actually wanted -- it's just what the fewest members of the committee (especially those with the most influence) found particularly objectionable. It's like picking a flavor of ice cream. One really likes strawberry, but another is allergic to strawberries. Another really loves chocolate, but somebody else can't stand it.  Yet another thinks rum raisin is great, but the other two worry that mentioning "rum" would be interpreted as encouraging alcohol abuse -- so they end up with vanilla, even though it's not what anybody really wanted.

Finally, even though it usually runs directly contrary to most of what the previous two criteria would produce in isolation, they generally need (or at least want) to be seen as responsive to the needs of industry.

Java is the intersection of these three:

Every concept it embodies was well known by 1980. There's not much to know beyond the very most basic notion of what OOP is.

It's the tasteless, odorless, non-toxic, biodegradable, politically correct choice.

Nearly the only other language in history to have existed as long and (probably) innovated less is SQL. Even though they're hardly what you'd call fast-moving targets, COBOL and Fortran have still both innovated more than Java.

It is widely used. When you get down to it, profs and PHBs have similar criteria.

Note that I'm not really saying (for example) that there's nothing more to know about Java than the most basic notion of what OOP is -- only that that's all that's needed to do what passes for an acceptable job of teaching it.

Title: Why do we study Java at university?


问:
Can compilers check whether certain axioms hold for a user defined type?
Suppose the following type is defined (C++ syntax, can be conceptually applied to any statically typed language.)

```<code>class T {
   int val;
   friend bool operator<(const T& lhs, const T& rhs) {
      return lhs.val < rhs.val;
   }
   // Ideally, if we should make them "friends"
   // Also, this doesn't make them belong to the type itself as they're not member functions
   friend bool operator>=(const T& lhs, const T& rhs) {
      return !(lhs < rhs);
   }
   // Also the following implementation is interesting
   friend bool operator>=(const T& lhs, const T& rhs) {
      return lsh.val >= rhs.val;
   }
};
</code>```

So, the compiler can definitely check whether T supports operator< or operator>=, it can just look up the declaration.

This gets more complicated should these be defined as "friends" instead of member functions, but it can be done as far as I'm concerned.

However, can the compiler check whether the "common axiom of sorts" hold? (Can as in is it possible to check this in all scenarios? Doesn't matter whether or not this would be standard-compliant.) Say:

not (a = b

Should we define one in terms of the other, it is definitely possible in this particular scenario, but this is naturally not the only axiom that needs to be checked, what about:

(a > b) => (b < a)

and it's also not necessary (unfortunately) to define our behaviour in terms of something that has already been defined. And sometimes it wouldn't be even possible.

So, if the compiler can check whether certain axioms hold, how? Generating random values from certain ranges? Is it possible to devise and proof correctness of such ranges?

This is mainly related to C++ concepts that unlike C++ concepts lite, should also be able to "support axioms", whatever that means, I just can't see a clear way as to how they can be enforced. Or will the creator of the type have to state what axioms his class obeys? C++ dropped the "concept maps" as far as I know.

答:
However, can the compiler check whether the "common axiom of sorts" hold?

No. That would be a non-compliant compiler. There's nothing in the standard that says that, for example, operator>= must be the boolean inverse of operator<. It's perfectly okay per the standard if a programmer wants to define all of the comparison operators as return 42;. That this is not a good idea is a different question.

The compiler has a hard enough time already given the complexity of C++. It's not a good idea to add a Sysiphean task to that load. Your 'testing of axioms' is in general an undecidable problem.


问:
What is the proper aproach of Subversion when using DLL
Background:

Our team develops a solution and it includes a number of projects. Most of the projects are built as DLLs and those DLLs are used by the rest of the projects.

Currently we uses Subversion for our code management and I ask others to remove DLLs from Subversion because we do not need to keep the history of the DLLs. So I ask my team to update their source every morning from Subversion and build each project to get DLL with yesterday submitted changes.

Issue:

This procedure was very good in the beginning f the project. but now each project of the solution getting bigger and bigger.Also gets more time to compile. now each developer waste around 20 mins each morning for build solution in their local computer.

Now I'm thinking again to ask each developer to submit their built DLLs to Subversion at end of the day and the next morning the rest of the users can download these DLLs directly from Subversion.

But I feel something is wrong with this procedure. Because Subversion waste space keeping the history records of each DLLs. Now I'm searching for a better solution.

Do you guys have any idea over your experience?

答:
You quite clearly need a dedicated team member who's job it is is to update their code to the head every time anyone commits a change, and also does a full, clean build every night and copies the dlls produced each and every time to a central location where the other team members can grab the dlls.

Unfortunately this is a laborious and tedious task.

Fortunately you can get a computer to do it for you!

They're called Continuous Integration servers and are designed to just this - grab code every commit, build it and "archive" the results somewhere. My favourite is Jenkins. It can put the resulting dlls into SVN or can copy them to a network share (I'd recommend putting only released dlls into SVN, daily or on-demand builds are too transient to keep for long). It can also email out everyone to say that a build failed (a developer forgot to add a file that was needed for example), and can also show a dashboard with the status of every build.


问:
Front end written in languages used for back end!
From my experience in web development, I know that languages like PHP,Java,Python..etc are used for backend development stuff (software that running on server), and for front end languages, JS/HTML/CSS are used.

But I see many companies say that they use, for example, PHP for front-end development, and python for the back-end.

Does that mean PHP is front-end for calling other services written in other languages via REST,RPC ..etc?

答:
You have confused the terms "front-end" and "back-end" with "server-side" and "client-side".  "Back-end" usually refers to systems which are not directly exposed to the user (database servers, middleware and so on), while "front-end" usually refers to the application (in the case of the Web, this normally means static and dynamic web pages) directly accessed by the client.

In a web application, the client (the user's browser), accesses web pages which are stored or dynamically generated "server-side" by "front-end" technologies.  Those front-end components may, in turn, pull data or other information from "back-end" components.  So a web application written in PHP would be "front-end" but "server-side".  However, if the web pages contained any javascript to be executed by the user's browser, that javascript code would be executed "client-side".

Hopefully I have removed some confusion, but now I risk creating some more.

First, we have AJAX, which is code (usually JavaScript) executed in the client (so client-side), to create the web pages you see by pulling information from Internet-facing services which do not themselves generate web pages.  The services are generating their information server-side on the front-end (since they are public and you can point your browser straight at them if you know the url).

Secondly JavaScript is not limited to client-side use, of course.  It has become increasingly popular as a "server-side" language (see node.js for one example).  As such, its most common use is for just the kind of Internet-facing services I described in the preceding paragraph.

Things used to be much simpler before Web 2.0.  Back then, in the context of web applications, the front end was where web pages were generated, while JavaScript only ran client-side and made minor cosmetic to web pages like hi-lighting images when you moved the mouse over them.   However, that simplicity made people lazy about their definitions.  Now the situation is more complex, so it is important to be precise about these terms.

(Oh, and if you have to use PHP, please keep it on the front end.  It is emphatically not a good back-end technology.  And if you ever find anybody creating a browser that executes PHP client-side, shoot them.)


答:
I think your question may be quite specific to PHP really, as I can't see any of the other back-end technologies you mention being used like this.

PHP is a funny example as it can be (in a rather ugly manner I may add) viewed as a all-in-one language with regards to a lot of web projects. You can do your traditional "back-end" tasks - such as file and database operations, whilst also building "front-end" mark-up.

This can clearly lead to a spaghetti mess where there is no real separation of concern, so it should really be frowned upon in my mind. For a great example, if you browse the wordpress source you can often get lost - and that is one project where I blame the language, the organisation of the codebase is actually very good.

This can be remedied, somewhat, by using a "templating engine" (such as Smarty)) - but it's still PHP which is building the "front-end" whilst also providing the "back-end" functionality. This was an intentional decision behind the design of PHP however, it is after all a "hypertext processor"!

So PHP can easily fit in to both "front-end" and "back-end" uses, which should clarify your example. Hence you are most likely correct in that PHP will be processing and building all the mark-up for a front-end, but it will be making requests somewhere else to gather the required data - most likely a service wrote in one of the aforementioned languages.

Personally, I feel the whole "back-end" and "front-end" terminology is a bit.. outdated perhaps. I'd rather things were just referred to a client-side and server-side; then there is no real ambiguity.*

Very recently I saw a client spec which required a back-end system wrote in node.js and associated tools, but wanted the front-end build using a PHP framework (Laravel). This comes with many associated costs, and in my mind - isn't an elegant solution and can cause a fair few issues down the line.

Personally speaking, these kind of configurations seem like someone has needlessly shoehorned PHP in to another stack - which means more resources are required than are actually necessitated, maintenance staff need exposure to a wider range of technologies and there are more points of failure.

Furthermore, I also think there are very few scenarios which warrant this kind of intermediary stack; most back-end languages/frameworks are perfectly capable of generating the mark-up required for the front-end. Although I stand to be corrected there.

*Although, to turn your question on it's head.. What about back-end systems built using Javascript? (node.js ;) )

Edit:

After reading a comment by @itsbruce, I've decided to clarify what I mean by the ambiguity of my "front-end"/"back-end" terminology.

Traditionally this terminology would've been fine, architecturally web applications were a lot simpler - and dare I say it, a lot dumber. It's a lot cleaner in my mind to say "Server Side" and "Client Side", and this is getting clearer as the current trend of pushing more of the processing and logic in to the client is getting common.

It's becoming acceptable to do a fair amount of data processing client-side (just look at some of the javascript frameworks currently trending), yet is that really front-end? The user doesn't see it, they see the results of it - and by traditional criteria that would generally be viewed as "back-end"; but this is occurring in the browser now..

Similarly, and incredibly relevant to this question, is building the mark-up in PHP truly a front-end task? I doubt it, a quick browse of job boards show few front-end developer positions expect PHP experience or knowledge; yet intuition would suggest that the mark-up for the interface is inherently front-end.

The very fact that this question exists acts as an example of how "front-end" and "back-end" are inherently ambiguous, and will continue to be so.

By referring to tasks as "server-side" or "client-side" that ambiguity is lost, you know where the code is executing and what languages will be used. If you said "front-end" in the example the OP has provided, I doubt many people would go "Oh, so PHP on the server right?".

Title: Front end written in languages used for back end!

Body:
From my experience in web development, I know that languages like PHP,Java,Python..etc are used for backend development stuff (software that running on server), and for front end languages, JS/HTML/CSS are used.

But I see many companies say that they use, for example, PHP for front-end development, and python for the back-end.

Does that mean PHP is front-end for calling other services written in other languages via REST,RPC ..etc?


问:
Unit of Work pattern
I have gone through many articles and I am still confused whether to use the Unit of Work pattern or not. I use generic repositories (Repository Pattern) but if my understanding of the UOW pattern is correct, most persistence tools today offer a unit of work pattern already implemented (DbContext, ObjectContext, DbSet). </p>

<p>I want to know if, in such cases, we should not try to implement the UOW pattern altogether? or I did see in one of the articles (sorry can't reference it since I missed it somewhere) that they had wrapped the DbContext inside an UOW class and I was left wondering what reason they might have of doing so. </p>

答:
Not everyone of us has the luxury of using a framework which provides a built-in "Unit of Work" component.

If you are using Entity Framework's DbContext and it serves you well, use it. If it doesn't, you may have to implement your "Unit of Work" yourself.

Title: Unit of Work pattern


问:
Task Consumer/Processor architecture
PROBLEM

We have various tasks in our system which can take up to 20 minutes.  These tasks are generally started from the web interface and run on a new thread.  This is obviously a terrible solution because the task could be recycled by IIS and it hogs up precious resources on the web server.

POSSIBLE SOLUTION

Hosting a TaskConsumer class in a windows service (or Azure Worker Role, in our case), which picks up tasks and processes them.  This would handle the queuing and running of tasks.

New tasks are added to a database table (say Tasks) in the client code via some TaskManager class (TaskManager.Enqueue(ITaskable)), which are then picked up by the TaskConsumer (perhaps it is polling this table for additions?).  This table would also be updated by the TaskConsumer while the task is executing (perhaps a state field - RUNNING, QUEUED, FAILED, COMPLETE).

To create a new type of task, one would implement an ITaskable interface.  This would demand implementations for a Process() method, which would contains the logic to run that task.

A UI interface could show all active tasks and perhaps provide some management capabilities (e.g. cancel a task, restart a task, etc).  This info can be retrieved from the TaskManager class (TaskManager.ActiveTasks), which essentially is reading from the Task database table.

The ITaskable concrete implementations would need to have serializable properties so to be stored in the database.  This is neede because there would be specific parameters/data needed to run the task.  For example, an ImportEmployees task would need to have the name of the file which was originally uploaded.  This would need to be known at the time the consumer needs to execute the task (on desialization).

Is this a good approach to tackle this problem?

I am sure there must be many patterns out there for this kind of problem.

答:
It is OK.  You run into the problem that task consumers have to needlessly hammer the DB to look for tasks, task cancels, etc.  I would have the task manager create an entry in the DB for the task so that the task consumer has a place to report results. Then use a Message queue like MSMQ or ActiveMQ to do the actual task consumer control.  I probably wouldn't go for results reported over the message queue because you are going to have to write(and read) results to the DB just incase iis unloads your process.  It much simpler to always read results from the DB.

If your DB load isn't that high or you don't want to complicate your deployment by throwing another bit of software in there, then your design will work just fine.  Just be careful to not kill the DB having task consumers hammer it too hard.

Title: Task Consumer/Processor architecture


答:
DBContext only provides you with a UoW pattern if you code up all the changes in one go yourself, which is pretty much no different to writing a single query in SQL yourself.

You should use the UoW pattern if performance is your concern - writing a single hit to the DB is better than writing 1 hit per change. However, most people use an ORM for RAD tooling ease-of-use, not performance. If this is what your solution is focussed on, then forget UoW. If you need performance then you should be considering rolling your own UoW pattern by using direct SQL anyway.

Title: Unit of Work pattern

Body:
I have gone through many articles and I am still confused whether to use the Unit of Work pattern or not. I use generic repositories (Repository Pattern) but if my understanding of the UOW pattern is correct, most persistence tools today offer a unit of work pattern already implemented (DbContext, ObjectContext, DbSet). </p>

<p>I want to know if, in such cases, we should not try to implement the UOW pattern altogether? or I did see in one of the articles (sorry can't reference it since I missed it somewhere) that they had wrapped the DbContext inside an UOW class and I was left wondering what reason they might have of doing so. </p>


问:
How to set up variable installation directory?
I have a couple projects that depend on additional files, like images or config files.

When compiling and installing a programs like Okular with cmake, I can specify an installation directory and let make install install to that. Somehow, that program will figure out that all its dependencies are within that folder, not withing the main Linux file system.

So far, I had absolute paths, like /etc/config.ini. The problem is that I cannot test the program without it installing it to my system any more.

How can I do that easily in C++ and Python?

答:
C/C++/other languages built with cmake/autotools/...

The usual method is to have the build system either pass the specified installation directory to the compiler as a define flag (-DPREFIX=${CMAKE_INSTALL_PREFX}) or written in a configuration header (#define PREFIX @CMAKE_INSTALL_PREFIX@). This gets compiled in the code, constant values are thus used at runtime.

Note, that it is important to allow the prefix to be changed for the installation, i.e. install the files in different path from what is compiled in the sources. This is used when creating packages and various special cases when the files will eventually be linked or mounted into the location that was compiled in the code. Both cmake and autotools allow such overriding by default.

Python

Here the usual method is simply placing all your data in the directory where your modules are and search for them in sys.path.


答:
I don't think that it's a good idea to have a branch purely for executables and DLLs.

Executables and DLLs should be a by product of building master branch on the build server.

Build server will build the branch, execute tests (if any) and store compiled assemblies somewhere on the network. Whenever deployment is needed, you will take compiled artefacts from your network location and deploy them into relevant environment.

You don't want to build DLLs locally and then upload them somewhere. What if you build on a 32 bit machine and then try deploying to a 64 bit machine? Same goes for sharing compiled artefacts between developers.

At my previous job we had a problem where full build (with all the unit and integration tests) was taking just under an hour to run (assuming nothing fails, which is a risky assumption to make). Now it's not feasible for the team of 20 developers to run a build each, potentially wasting 20 hours of development time. What we've decided to do is build all the executables and DLLs on a build server and then distribute them to the team through NuGet.


问:
How to approach scrum task burn down when tasks have multiple peoples involvement?
In my company, a single task can never be completed by one individual. There is going to be a separate person to QA and Code Review each task. What this means is that each individual will give their estimates, per task, as to how much time it will take to complete.

The problem is, how should I approach burn down? If I aggregate the hours together, assume the following estimate:

10 hrs - Dev time

4  hrs - QA

4  hrs - Code Review.

Task Estimate = 18hrs

At the end of each day I ask that the task be updated with "how much time is left until it is done". However, each person generally just thinks about their part of it. Should they mark the effort remaining, and then ADD the effort estimates to that? How are you guys doing this?

UPDATE

To help clarify a few things, at my organization each Task within a story requires 3 people.

Someone to develop the task. (do unit tests, ect...)

A QA specialist to review task (they primarily do integration and regression tests)

A Tech lead to do code review.

I don't think there is a wrong way or a right way, but this is our way ... and that won't be changing. We work as a team to complete even the smallest level of a story whenever possible. You cannot actually test if something works until it is dev complete, and you cannot review the quality of the code either ... so the best you can do is split things up into small logical slices so that the bare minimum functionality can be tested and reviewed as early into the process as possible.

My question to those that work this way would be how to burn down a "task" when they are setup this way. Unless a Task has it's own sub-tasks (which JIRA doesn't allow) ... I'm not sure the best way to accomplish tracking "what's left" on a daily basis.

答:
Can you define the dev task as "done" before QA does their part?  Can you define code review as "done" before  dev is done?  Can QA be "done" if the dev and code review are not?

I would say that you should aggregate the three items into a single task and the three people should work together on it.

Scrum does NOT say that any item is any one team member's responsibility.  Just the opposite--sprint log items are the TEAM's responsibility.  If it takes three people to perform a task, then that's what it takes.


问:
Should I combine similar functions even though they are slightly different?
On an application I've been working on I have a function, connecting to a virtual machine, that can be performed two ways. The user can either select a machine from a list and click the "Connect" button. Or can double click on the machine in the list. Currently they are two separate event handlers because they function slightly differently. If a user is already connected, clicking the button will disconnect them, and double clicking will bring the window back up.

///edit
The logic is essentially

```<code>button
if(connected)
Disconnect()
else
ConnectAndShowWindow()

List
ConnectAndShowWindow()
</code>```

My question is should I keep the methods separate or combine the two methods even though they are slightly different and then, for the disconnecting/reconnecting switch them based on the sender?

答:
An approach that I've used in that type of situation is to refactor the two methods into a single private method with a parameter to indicate which of the paths should be taken.

```<code>public void buttonEventHandler() {
    connectHandler(ConnectEvent.BUTTON);
}
public void DoubleClickEventHandler() {
    connectHandler(ConnectEvent.DOUBLE_CLICK);
}
private void connectHandler(ConnectEvent eventOption) {
    // conditional connection logic
}
</code>```

This keeps the interface simple and allows the connect code to be shared in place.

Body:
An approach that I've used in that type of situation is to refactor the two methods into a single private method with a parameter to indicate which of the paths should be taken.

public void buttonEventHandler() {
    connectHandler(ConnectEvent.BUTTON);
}
public void DoubleClickEventHandler() {
    connectHandler(ConnectEvent.DOUBLE_CLICK);
}
private void connectHandler(ConnectEvent eventOption) {
    // conditional connection logic
}

This keeps the interface simple and allows the connect code to be shared in place.


问:
Validation and data persistence in a domain model
My (first and current) workplace (a .NET shop) suffers from an over-abundance of anemic domain models, to the extent that I don't really know how validation and data persistence should be handled in a proper domain model.

Data Persistence

One option would be to give the domain model a way to do persistence itself. You could, for example, inject an IFooRepository via constructor injection, and have that resolved by an IoC container to ensure you don't create a dependency on it (à la onion architecture). But I'm not sure if the code that uses the domain model should be responsible for calling methods to save the data, etc., or if it should be done implicitly behind the scenes on a background thread. Perhaps this breaks that purity of the domain model and is more along the lines of the active record pattern.

The other option I see is to not tie the domain model to data persistence at all and instead have a coordinating service layer responsible for that aspect.

What are the best practices for data persistence in the domain model pattern?

Validation

Another problem I don't know how to solve with a proper domain model is how to indicate to the UI why the current model state is invalid without coupling to (or at least catering to) the UI. For example, let's say I have a form an user fills out with various fields. We want to validate that input, and if something is wrong, indicate an error on that specific field with a message.

How would we handle validation with that level of granularity without adding significant complexity to the domain model, or doing hack-ish stringly-typed things (like throwing an validation exception with the property's name and a message)?

答:
I could be mistaken in my understanding, but I believe your trying to redesign your Domain Model so that it isn't riddled with anemia.  A couple of really, really great books on the matter are:

Martin Fowler - Patterns of Enterprise Application Architecture

Eric Evans: Domain-Driven Design: Tackling Complexity in the Heart Of Software

Vaughn Vernon: Implementing Domain Driven Design

They have a lot of content which answers quite a few questions on your goal.  One of which is:

A rich Domain Model can look different from the database design, with
  inheritance, strategies, and other Gang of Four patterns, and complex
  webs of small interconnected objects.  A rich Domain model is better
  for more complex logic, but is harder to map to the database.

A simple Domain Model can use Active Record, whereas a rich Domain
  Model requires a Data Mapper.  Since the behavior of the business
  subject to alot of change, it's important to be able to modify, build,
  and test this layer easily.

That is an excerpt from Fowler.  He will go into details about the model being anemic and bloated models as well.  The scope of the question to me appears quite large; so I'm not sure I could delve far into it.  Those books should point you in the right direction; also will allow you to gauge your current project and implementation to refactor it quickly.

From a relatively basic understanding:

You should be able to abstract your model, which will allow a brief overlay of the UI and Data Access into your Domain Model.  But otherwise the model should allow a clear, clean, concise implementation which will help separate responsibility.

Sorry I couldn't be more help.


答:
Your features are:

Connect

Disconnect

Bring Window Forward

The logic of the "Connect" button is:

```<code>if (connected)
    Disconnect
else
    Connect
</code>```

The logic of the machine double-click is:

```<code>if (connected)
    Bring Window Forward
else
    Connect
</code>```

To me, these are quite separate handlers and I would leave them so.  They should of course call the common Connect method.

Title: Should I combine similar functions even though they are slightly different?

Body:
On an application I've been working on I have a function, connecting to a virtual machine, that can be performed two ways. The user can either select a machine from a list and click the "Connect" button. Or can double click on the machine in the list. Currently they are two separate event handlers because they function slightly differently. If a user is already connected, clicking the button will disconnect them, and double clicking will bring the window back up.

///edit
The logic is essentially

```<code>button
if(connected)
Disconnect()
else
ConnectAndShowWindow()

List
ConnectAndShowWindow()
</code>```

My question is should I keep the methods separate or combine the two methods even though they are slightly different and then, for the disconnecting/reconnecting switch them based on the sender?

Body:
Your features are:

Connect

Disconnect

Bring Window Forward

The logic of the "Connect" button is:

if (connected)
    Disconnect
else
    Connect

The logic of the machine double-click is:

if (connected)
    Bring Window Forward
else
    Connect

To me, these are quite separate handlers and I would leave them so.  They should of course call the common Connect method.


问:
Is it good practice to not filter values according to nullability?
Sometimes when I create an API that should enable getting a single value or all values I use the following pattern (passing NULL to the API, means get all rows):

@Usernames - comma separeted list of users

```<code>CREATE PROC GetUsers (@Usernames VARCHAR(100) = NULL)
AS
BEGIN
    SELECT *
    FROM Users
    Where @Usernames IS NULL OR dbo.in_list(@Usernames,Username) = 1
END
</code>```

Is this a good practice to use the OR condition the get both functionalities, or should i write something like this:

```<code>CREATE PROC GetUsers (@Usernames VARCHAR(100) = NULL)
AS
BEGIN
    IF(@Username IS NULL)
    BEGIN
        SELECT *
        FROM Users
    END
    ELSE
    BEGIN
        SELECT *
        FROM Users
        Where dbo.in_list(@Usernames,Username) = 1
    END
END
</code>```

*Note:
This is only SQL for example, this is not a specific coding language question.
Thanks.

答:
Create another procedure named GetEmployeesDetails.

Your procedure is named GetEmployeeDetails, so the procedure should only do one thing: get the details of an employee.

You're making it do other things than what its name says if it returns something else than the details of one employee.

What's usually done is having a GetEmployeesDetails taking a filter parameter. This filter can be a hashmap, empty or not.

This is important not to do it your way; your procedure's name is misleading.


问:
Should a RESTful API provide data for an entire form?
Let's say I have a JavaScript web application which entirely uses a RESTful API for data.

Let's say this application has a data form, and let's say I'm editing a record at /product/12345. When building the form, I make a RESTful request to /product/12345 and get JSON data:

```<code>{
  "id": 12345,
  "name": "Some Product",
  "active": true,
  "sales_user_id": 27
}
</code>```

So, my form obviously may have a dropdown list for selecting a sales person. I need to populate this list. Where should the data come from? What's the most common approach?

Would it make sense to make it part of the /product/12345 request response?

```<code>{
  "id": 12345,
  "name": "Some Product",
  "active": true,
  "sales_user_id": 27,
  "sales_users": [
    {"id": 1, "name": "Anna Graham"},
    {"id": 2, "name": "Dick Mussell"},
    {"id": 3, "name": "Ford Parker"},
    {"id": 4, "name": "Ferris Wheeler"},
    {"id": 5, "name": "Jo King"}
  ]
}
</code>```

What about when creating a new record? Should my API also respond to GET /product/new, with the following?

```<code>{
  "sales_users": [
    {"id": 1, "name": "Anna Graham"},
    {"id": 2, "name": "Dick Mussell"},
    {"id": 3, "name": "Ford Parker"},
    {"id": 4, "name": "Ferris Wheeler"},
    {"id": 5, "name": "Jo King"}
  ],
  "categories": [
    {"id": 1, "name": "Category 1"},
    {"id": 2, "name": "Category 2"},
    {"id": 3, "name": "Category 3"},
    {"id": 4, "name": "Category 4"},
    {"id": 5, "name": "Category 5"}
  ],
  "etc": [ ... ]
}
</code>```

答:
Assuming that the list of salespeople is relatively static, I would think you'd want a separate API call /salesusers that you could call once (on form load, etc.) and save off so you don't have to re-request this data each time. Remember in REST, you are organizing your API around resources, and salespeople are logically separate resources from products.

Likewise, when calling /product/new, you would only want to be submitting data for a new product, which might include a sales_user id, but nothing more. Changes to a sales_user itself would be a separate call.


答:
I lean towards very simple, narrowly-focused endpoints.  I would expect a request at some location like /sales_users which returns all sales users.

GET /sales_users:

```<code>[
    {"id": 1, "name": "Anna Graham"},
    {"id": 2, "name": "Dick Mussell"},
    {"id": 3, "name": "Ford Parker"},
    {"id": 4, "name": "Ferris Wheeler"},
    {"id": 5, "name": "Jo King"}
]
</code>```

Similarly, if you are going to have a list of categories, I would add a separate endpoint for that.

GET /categories:

```<code>[
    {"id": 1, "name": "Category 1"},
    {"id": 2, "name": "Category 2"},
    {"id": 3, "name": "Category 3"},
    {"id": 4, "name": "Category 4"},
    {"id": 5, "name": "Category 5"}
]
</code>```

I would not build a GET /product/new.  Rather, I would build a form in your app to handle adding new products which knows the appropriate requests to populate its lists (e.g., GET /categories, GET /sales_users, etc.).

Title: Should a RESTful API provide data for an entire form?

Body:
Let's say I have a JavaScript web application which entirely uses a RESTful API for data.

Let's say this application has a data form, and let's say I'm editing a record at /product/12345. When building the form, I make a RESTful request to /product/12345 and get JSON data:

```<code>{
  "id": 12345,
  "name": "Some Product",
  "active": true,
  "sales_user_id": 27
}
</code>```

So, my form obviously may have a dropdown list for selecting a sales person. I need to populate this list. Where should the data come from? What's the most common approach?

Would it make sense to make it part of the /product/12345 request response?

```<code>{
  "id": 12345,
  "name": "Some Product",
  "active": true,
  "sales_user_id": 27,
  "sales_users": [
    {"id": 1, "name": "Anna Graham"},
    {"id": 2, "name": "Dick Mussell"},
    {"id": 3, "name": "Ford Parker"},
    {"id": 4, "name": "Ferris Wheeler"},
    {"id": 5, "name": "Jo King"}
  ]
}
</code>```

What about when creating a new record? Should my API also respond to GET /product/new, with the following?

```<code>{
  "sales_users": [
    {"id": 1, "name": "Anna Graham"},
    {"id": 2, "name": "Dick Mussell"},
    {"id": 3, "name": "Ford Parker"},
    {"id": 4, "name": "Ferris Wheeler"},
    {"id": 5, "name": "Jo King"}
  ],
  "categories": [
    {"id": 1, "name": "Category 1"},
    {"id": 2, "name": "Category 2"},
    {"id": 3, "name": "Category 3"},
    {"id": 4, "name": "Category 4"},
    {"id": 5, "name": "Category 5"}
  ],
  "etc": [ ... ]
}
</code>```

Body:
I lean towards very simple, narrowly-focused endpoints.  I would expect a request at some location like /sales_users which returns all sales users.

GET /sales_users:

[
    {"id": 1, "name": "Anna Graham"},
    {"id": 2, "name": "Dick Mussell"},
    {"id": 3, "name": "Ford Parker"},
    {"id": 4, "name": "Ferris Wheeler"},
    {"id": 5, "name": "Jo King"}
]

Similarly, if you are going to have a list of categories, I would add a separate endpoint for that.

GET /categories:

[
    {"id": 1, "name": "Category 1"},
    {"id": 2, "name": "Category 2"},
    {"id": 3, "name": "Category 3"},
    {"id": 4, "name": "Category 4"},
    {"id": 5, "name": "Category 5"}
]

I would not build a GET /product/new.  Rather, I would build a form in your app to handle adding new products which knows the appropriate requests to populate its lists (e.g., GET /categories, GET /sales_users, etc.).


答:
Your question title is different from the question within your posting, so I try to answer both questions.

IMHO it is a perfectly valid idiom to have a function with an optional filter condition, and when you leave that filter out, you get the full unfiltered result set. That's true for SQL as well as for many other programming languages.

As for which implementation is better: your first one is more comprehensive with less repetition of the same code (SELECT * FROM Users) and less boilerplate code (IF .. END ELSE ...) - so in general I would prefer this, since it is clearly better maintainable. Only if you suffer from an unexpected loss of performance you may test if the second alternative is faster. That will probably depend on your database system (maybe on the version), so do this only if you are 100% sure that it will be worth the hussle.

Title: Is it good practice to not filter values according to nullability?

Body:
Sometimes when I create an API that should enable getting a single value or all values I use the following pattern (passing NULL to the API, means get all rows):

@Usernames - comma separeted list of users

```<code>CREATE PROC GetUsers (@Usernames VARCHAR(100) = NULL)
AS
BEGIN
    SELECT *
    FROM Users
    Where @Usernames IS NULL OR dbo.in_list(@Usernames,Username) = 1
END
</code>```

Is this a good practice to use the OR condition the get both functionalities, or should i write something like this:

```<code>CREATE PROC GetUsers (@Usernames VARCHAR(100) = NULL)
AS
BEGIN
    IF(@Username IS NULL)
    BEGIN
        SELECT *
        FROM Users
    END
    ELSE
    BEGIN
        SELECT *
        FROM Users
        Where dbo.in_list(@Usernames,Username) = 1
    END
END
</code>```

*Note:
This is only SQL for example, this is not a specific coding language question.
Thanks.


答:
So, what you're saying is that the software acts one way when the software is in one state and another thing when the software is in another state. Well, welcome to the State Pattern.

The short story is that you want two classes, each implementing the same interface. the interface should have two methods -- OnMachineConnectSelected and OnMachineDoubleClick.

The first class is called DisconnectedState, the second class is called ConnectedState.

DisconnectedState performs Connect and ShowWindow from OnMachineConnectSelected.

DisconnectedState performs Connect from OnMachineDoubleClick.

ConnectedState performs ShowWindow from both OnMachineConnectSelected and OnMachineDoubleClick.

(It's hard to tell without more specifics, but you can and probably should have Connect and ShowWindow as methods on your form or other application object and pass a reference, probably via another interface, into the constructor of your state class.)

Now your application simply needs an object on which it can call those methods, as the actions occur, and you can switch that object between an instance of DisconnectedState and ConnectedState as the actual state of your application changes.

See what this does for you?

First, it models your application very well. Look at the bullet-points above. You wouldn't have to rearrange the words much to explain what was going on to a user or non-technical manager. You are separating out the concepts of state (software/hardware decisions) and action (user decisions) neatly.

Second, it allows for extensibility. When you realise that you need to act very differently, while connecting and disconnecting, you can simply add two new state classes. Or if you need to add a new action that depends on the state, you can simply add a new method to all your state objects.

Third, it is more maintainable. When a business person says "Hey, currently, when the application is Disconnected and you Select Connect on a machine, it Connects and Shows the Window; but we want it to simply connect," you know EXACTLY where that logic exists in the code and can edit it easily, safe in the knowledge that you aren't breaking any of the other conditions.

Finally, it's more unit-testable. There is only one path through each method. Pass a mock form into your class constructor, call the OnX method and make sure it performs the right actions. And, on the form, you can test that your action calls the right method, no matter what state it's in.


答:
In application programming languages, I agree with Doc Brown. Nothing wrong here.

For the SQL implementation, parameter sniffing could create some havoc here. Consult an skilled DBA or read some serious papers on dynamic searching on your db engine of choice for better decision making.


答:
Task remaining time doesn't matter much: nothing can be delivered until the whole story is done.

If you want to track how much time is left on a story (overall) by having people fill in remaining time on tasks, then split tasks per person.

That said:

Big tasks might be an indication your stories are too big. In this case, the best solution is to reduce the scope and size of stories, and if you reduce it enough tracking remaining time on tasks doesn't matter any more (they're either done or not - sum of estimate on non done tasks is granular enough).

SCRUM encourages everyone to pick up what needs doing. If you are assigning tasks to persons (as opposed to roles), then you're potentially preventing yourself from delivering a story, even if developer is doing nothing - because QA is bottlenecked.

Title: How to approach scrum task burn down when tasks have multiple peoples involvement?

Body:
In my company, a single task can never be completed by one individual. There is going to be a separate person to QA and Code Review each task. What this means is that each individual will give their estimates, per task, as to how much time it will take to complete.

The problem is, how should I approach burn down? If I aggregate the hours together, assume the following estimate:

10 hrs - Dev time

4  hrs - QA

4  hrs - Code Review.

Task Estimate = 18hrs

At the end of each day I ask that the task be updated with "how much time is left until it is done". However, each person generally just thinks about their part of it. Should they mark the effort remaining, and then ADD the effort estimates to that? How are you guys doing this?

UPDATE

To help clarify a few things, at my organization each Task within a story requires 3 people.

Someone to develop the task. (do unit tests, ect...)

A QA specialist to review task (they primarily do integration and regression tests)

A Tech lead to do code review.

I don't think there is a wrong way or a right way, but this is our way ... and that won't be changing. We work as a team to complete even the smallest level of a story whenever possible. You cannot actually test if something works until it is dev complete, and you cannot review the quality of the code either ... so the best you can do is split things up into small logical slices so that the bare minimum functionality can be tested and reviewed as early into the process as possible.

My question to those that work this way would be how to burn down a "task" when they are setup this way. Unless a Task has it's own sub-tasks (which JIRA doesn't allow) ... I'm not sure the best way to accomplish tracking "what's left" on a daily basis.


答:
I like Joel Spolsky's post entitled The Perils Of Java Schools. I think Berin Loristch is correct about it simplifying the cirriculum and it also being applicable to the real world.

I have heard the following said many times: "a Computer Science degree isn't a degree to learn programming, it is to learn the theory". The language doesn't necessarily need to matter (although it shoudln't get in the way) as long the theory is being learned. Java is a relatively easy language to pick up and that allows for more time to be spent learning the theory behind everything. This is one of the reasons that MIT uses Scheme (so I've heard).

Title: Why do we study Java at university?

Body: Java is often found in academia. What is the reason behind that? </p>


问:
When is it NOT good to use actors in akka/erlang?
I've been working with akka for 7-8 months now daily.
When I started, I would be working on applications and notice that actors would be used basically anywhere once inside the actor system for communicating between most objects. So I did the same - spin up another actor for x/y/z.

It seems to me that this may be too indiscriminate, adding complexity where it isn't needed - but I can't find any discussions on where actors vs plain synchronous or even async logic via futures should be used. I started pondering my stance after my coworker mentioned something similar. I realized several cases more recently where I have pondered a task and then avoided creating another actor because I could achieve the same result safely in an immutable implementation - eg something like getting configuration values from a db or file somewhere where you access very infrequently and will wait for the result is the actual use case.

In particular, it seems to me that any case where you're playing with immutable state, actors create complexity and limit throughput - a pure function in an object, for example, can be called concurrently with no risk with any level of concurrency, yet an actor can only process one message at a time. The alternate consideration is you'll park the thread if you need to wait for the result unless you start using futures but cases where you don't need to worry about async messaging or scale it seems it may be overkill to employ an actor.

So my question is - is there a bad time to use actors? I'm curious how erlang looks and would really like other people's insight. Or if there are some principles around actor use.

答:
Your intuition is correct, IMHO. Using actors everywhere is like having the proverbial hammer and seeing only nails.

The Erlang best practice is to use processes/actors for all activities that happen concurrently. That is, just like in real life. Sometimes it is difficult to find the right granularity, but most of the times you just know by looking at the modeled domain and using a bit of common sense. I'm afraid I don't have a better method than that, but I hope it helps.


问:
Multiple applications in a single Visual Studio solution
I am doing work for a company that is wanting to put all their .Net applications (web applications, Windows applications and console applications) together in a single Visual Studio solution.

I am looking for experience from developers who either structure their own applications this way or who work in a company that does this. Is this a good idea?

What are the pro's/con's to putting all your applications in a single solution rather than having separate solutions for each application?

How fast is Visual Studio with a solution of 20+ projects?

And how stable is the solution file with source-controlled concurrent development?

答:
Recently, we migrated nearly all the source code in my company into a single solution.

Why?

Originally, we had dozens of solutions. Some projects from a solution reused projects from another one, and nobody cared about using a package manager. The day you substantially change a project which is used nearly everywhere, expect hours and hours of lost work for the entire company for the next days or weeks. The worst part is that you can't even know what exactly would be affected by the change.

Merging all the code into one solution was an alternative. It works well for the moment, and the dependencies are now easy to follow. Want to modify a method but also track the repercussions this change may have anywhere in the code base? Visual Studio can do that with ease. For me, it's a success.

Continuous integration is now easier too. One solution to compile and to deploy. Nearly nothing to configure.

Is it scalable?

Performance-wise, I was very surprised by Visual Studio. I thought that it will start crying with a solution with, say, 50 projects. Today, there are more than 200 projects; Visual Studio appeared to be scalable enough to manage them as if there were only 20 of them. Yes, there are things which take time. If you recompile every project, with Code contracts, Code analysis enabled by default, etc., expect it to take a while. But nobody would expect to compile 200 projects as fast as 10, and by the way, you shouldn't: this is the role of the Continuous integration server. Startup time (cold start, then loading the solution) is impressively fast; maybe not as fast as with 10 projects, but still very acceptable (under 20 seconds on a machine bought more than five years ago).

To go even further, systematically unloading projects is a good idea (and really easy when projects are organized in directories within the solution). If somebody works on something which requires only three projects to be loaded, there is no need to load all the 200 projects (unless, of course, dependencies may be affected).

Version control works as expected as well (I'm using an SVN server, if it matters). I haven't worked in a real concurrent environment, with, say, dozens of developers frequently committing code, but I would imagine that this wouldn't have too many issues. Just beware of the cases where many developers add new projects at the same time: merging the .sln file is not the easiest thing to do.

Conclusion

If I had to pick the decision again:

I would still migrate everything into a single solution. This reduces enormously the pain of broken dependencies, and this benefit alone is totally worth it. Having a centralized place for all the code is also a good idea; this makes it possible, for example, to search for something within Visual Studio. I can also work on two weakly-related projects, and still have just one Visual Studio window opened.

I would also study a bit more NuGet and the ability to host a private NuGet server. Managing the dependencies through NuGet can solve some of the problems when you don't want to merge a few projects into the common solution. Personally, I didn't have such cases, but I imagine that other companies might have.

Finally, investing in an SSD for every developer can make a huge difference. But you don't need to, and in my case, the code base is still stored on an ordinary hard drive.


问:
If the user declines a "continue?" prompt, what exit code should be returned?
In terminal based scripts (Shell, Bash, Python, etc), if you prompt the user "Do you wish to continue?" and the user chooses "No", what exit code should the script ideally return?

On one hand, the script executed as the user expected it to (the user wanted to quit, so it quit), so it should give an exit code of 0. On the other hand, the script was unable to complete its main task, which should be a non-zero exit code.

答:
The script was able to complete its main task: respond without any error to the user. It's not like it had a permission issue, a segfault, a missing file, or something like this. It was the intended behavior to stop.

Errors should be used when unintended behaviors happen: the user wanted the program to do a task, and the program couldn't.