问:
Performing a username lookup before registering a User while conforming to REST philosophy
I have a REST Service based on Spring MVC. JSON is the only interchange format for any client to talk to this service.

I'm working on implementing a user registration workflow. So I have created an endpoint (/register, payload=User object in JSON) that accepts the User entity and does it's thing. So I'm transferring the state of an object which makes me content about adhering to the REST philosophy (I think).

My question is: Before I can register a user, I need to check if ther username is already used up. So I can create a new endpoint /register/username/
But this idea sounds bad and not RESTful at all as I'm using the endpoint to perform an action, not transfer of state. And this sounds like I'm invoking a method to perform an action (remote RPC). How can I re think this in terms of REST?

答:
If you want the user name uniqueness check to be performed as part of creating an account, you could let "POST /accounts" return 409 if an account for that user name already exists. See the overview of HTTP status codes. In the response body, you could return an appropriate error message. If you have a convention for specifying exactly which field is invalid in the error response, then you could use that convention to indicate that the user name is causing a problem (e.g. to highlight that field on the screen). Example 409 response:

```<code>{
    "message" : "Unable to register new account",
    "errorFields" : [
        { "field" : "userName", "message" : "An account with this user name already exists" },
        { "field" : "password", "message" : "Password too weak" }
    ]
}
</code>```

However, I am rather thinking in a totally different direction. It is common in such situations, that the client needs to check explicitly for a duplicate user name before attempting to create an account, for example as soon as the user leaves the user name field. In that case, the client app should use the HTTP method 'HEAD'. See the HTTP methods spec. The server returns 200 if an account for that user name already exists and 404 if the account does not exist.

Suppose /accounts represents the collection of accounts and /account/xxx represents an individual account for user name xxx, then the client should do HEAD /accounts/xxx to check if user xxx already has an account. Ideally, the client does not simply append "/xxx" to "/accounts", but uses a templated link, /accounts/{username}, provided by another resource.

I would not put user names in the path, though. I would use technical keys instead, e.g. /accounts/accountID represents an individual account, where accountID is a technical key. In that case, if the client app has to check if user name xxx is already in use, it can do HEAD /accounts?userName=xxx (again, another resource should provide a templated link to do this).

Body:
If you want the user name uniqueness check to be performed as part of creating an account, you could let "POST /accounts" return 409 if an account for that user name already exists. See the overview of HTTP status codes. In the response body, you could return an appropriate error message. If you have a convention for specifying exactly which field is invalid in the error response, then you could use that convention to indicate that the user name is causing a problem (e.g. to highlight that field on the screen). Example 409 response:

{
    "message" : "Unable to register new account",
    "errorFields" : [
        { "field" : "userName", "message" : "An account with this user name already exists" },
        { "field" : "password", "message" : "Password too weak" }
    ]
}

However, I am rather thinking in a totally different direction. It is common in such situations, that the client needs to check explicitly for a duplicate user name before attempting to create an account, for example as soon as the user leaves the user name field. In that case, the client app should use the HTTP method 'HEAD'. See the HTTP methods spec. The server returns 200 if an account for that user name already exists and 404 if the account does not exist.

Suppose /accounts represents the collection of accounts and /account/xxx represents an individual account for user name xxx, then the client should do HEAD /accounts/xxx to check if user xxx already has an account. Ideally, the client does not simply append "/xxx" to "/accounts", but uses a templated link, /accounts/{username}, provided by another resource.

I would not put user names in the path, though. I would use technical keys instead, e.g. /accounts/accountID represents an individual account, where accountID is a technical key. In that case, if the client app has to check if user name xxx is already in use, it can do HEAD /accounts?userName=xxx (again, another resource should provide a templated link to do this).


问:
Does syntax really matter in a programming language?
One of my professors says "the syntax is the UI of a programming language", languages like Ruby have great readability and it's growing, but we see a lot of programmers productive with C\C++, so as programmers does it really matter that the syntax should be acceptable?

I would love to know your opinion on that.

Disclaimer: I'm not trying to start an argument. I thought this is a good topic of discussion.

Update: This turns out to be a good topic. I'm glad you are all participating in it.

答:
Yes it does.
If you're in doubt, take APL, or J, or Brainfuck, or even plain and simple Lisp or Forth, and try to understand any not entirely trivial program on it. Then compare to e.g. Python.

Then compare the same Python (or Ruby, or even C#) to things like Cobol or VB6.

I'm not trying to say that hairy syntax is bad and natural-language-like syntax is good in all circumstances. But obvoiusly syntax does make a huge difference. All in all, everything you can write in the most beautiful programming language you can also write as a Turing machine program — but you usually don't want to, do you?

ContentLicense: CC BY-SA 3.0


问:
Are (database) integration tests bad?
Some people maintain that integration tests are all kinds of bad and wrong - everything must be unit-tested, which means you have to mock dependencies; an option which, for various reasons, I'm not always fond of.

I find that, in some cases, a unit-test simply doesn't prove anything.

Let's take the following (trivial, naive) repository implementation (in PHP) as an example:

class ProductRepository
{
    private $db;

    public function __construct(ConnectionInterface $db) {
        $this->db = $db;
    }

    public function findByKeyword($keyword) {
        // this might have a query builder, keyword processing, etc. - this is
        // a totally naive example just to illustrate the DB dependency, mkay?

        return $this->db->fetch("SELECT * FROM products p"
            . " WHERE p.name LIKE :keyword", ['keyword' => $keyword]);
    }
}
```

Let's say I want to prove in a test that this repository can actually find products matching various given keywords.

Short of integration testing with a real connection object, how can I know that this is actually generating real queries - and that those queries actually do what I think they do?

If I have to mock the connection object in a unit-test, I can only prove things like "it generates the expected query" - but that doesn't mean it's actually going to work... that is, maybe it's generating the query I expected, but maybe that query doesn't do what I think it does.

In other words, I feel like a test that makes assertions about the generated query, is essentially without value, because it's testing how the findByKeyword() method was implemented, but that doesn't prove that it actually works.

This problem isn't limited to repositories or database integration - it seems to apply in a lot of cases, where making assertions about the use of a mock (test-double) only proves how things are implemented, not whether they're going to actually work.

How do you deal with situations like these?

Are integration tests really "bad" in a case like this?

I get the point that it's better to test one thing, and I also understand why integration testing leads to myriad code-paths, all of which cannot be tested - but in the case of a service (such as a repository) whose only purpose is to interact with another component, how can you really test anything without integration testing?

答:
One of my co-workers maintains that integration tests are all kinds of bad and wrong - everything must be unit-tested,

That's a little like saying that antibiotics are bad - everything should be cured with vitamins.

Unit tests can't catch everything - they only test how a component works in a controlled environment.  Integration tests verify that everything works together, which is harder to do but more meaningful in the end.

A good, comprehensive testing process uses both types of tests - unit tests to verify business rules and other things that can be tested independently, and integration tests to make sure everything works together.

Short of integration testing with a real connection object, how can I know that this is actually generating real queries - and that those queries actually do what I think they do?

You could unit test it at the database level.  Run the query with various parameters and see if you get the results you expect.  Granted it means copying/pasting any changes back into the "true" code. but it does allow you to test the query independent of any other dependencies.

Title: Are (database) integration tests bad?


答:
You need both.

In your example if you were testing that a database in a certain condition, when the findByKeyword method is run you get the data back you expect this is a fine integration test.

In any other code that is using that findByKeyword method you want to control what is being fed in to the test, so you can return nulls or the right words for your test or whatever then you mock the database dependency so you know exactly what your test will receive (and you lose the overhead of connecting to a database and ensuring the data within is correct)

Title: Are (database) integration tests bad?

Body:
Some people maintain that integration tests are all kinds of bad and wrong - everything must be unit-tested, which means you have to mock dependencies; an option which, for various reasons, I'm not always fond of.

I find that, in some cases, a unit-test simply doesn't prove anything.

Let's take the following (trivial, naive) repository implementation (in PHP) as an example:

class ProductRepository
{
    private $db;

    public function __construct(ConnectionInterface $db) {
        $this->db = $db;
    }

    public function findByKeyword($keyword) {
        // this might have a query builder, keyword processing, etc. - this is
        // a totally naive example just to illustrate the DB dependency, mkay?

        return $this->db->fetch("SELECT * FROM products p"
            . " WHERE p.name LIKE :keyword", ['keyword' => $keyword]);
    }
}
```

Let's say I want to prove in a test that this repository can actually find products matching various given keywords.

Short of integration testing with a real connection object, how can I know that this is actually generating real queries - and that those queries actually do what I think they do?

If I have to mock the connection object in a unit-test, I can only prove things like "it generates the expected query" - but that doesn't mean it's actually going to work... that is, maybe it's generating the query I expected, but maybe that query doesn't do what I think it does.

In other words, I feel like a test that makes assertions about the generated query, is essentially without value, because it's testing how the findByKeyword() method was implemented, but that doesn't prove that it actually works.

This problem isn't limited to repositories or database integration - it seems to apply in a lot of cases, where making assertions about the use of a mock (test-double) only proves how things are implemented, not whether they're going to actually work.

How do you deal with situations like these?

Are integration tests really "bad" in a case like this?

I get the point that it's better to test one thing, and I also understand why integration testing leads to myriad code-paths, all of which cannot be tested - but in the case of a service (such as a repository) whose only purpose is to interact with another component, how can you really test anything without integration testing?


问:
Can I have two licenses in a Repository? One for a company and another one for everybody else?
So, I wrote a little piece of software (really little piece of software) and I want to open source it using Apache License for EVERYBODY but for a company, for that company I want the license to be GPL.

Is this possible? If so how should I implement this? I just add a License section in the github readme explaining that is open source for everybody but for "This Company"?

答:
No.

One of the fundamental principles of open source software is "no discrimination" - you can't have one licence for some entities and another one for others. If you want to release your software under the Apache licence to some entities, you have to release it under that licence to everybody.


问:
Stored Procedure performance
I'm working on upgrading an application written by a former developer at my work and I've been converting all the SQL queries in the code into Stored Procedures. I'm doing this with the idea that it can be easily called whenever it is needed instead of having the SQL query string repeated several times in the code. Also, I can easily use parameters with the stored procedure and avoid SQL injection vulnerabilities in my code.

I was talking with another developer on my team who asked why I did it that way and told me that "calling stored procedures a lot can impact the SQL Server's performance and that it is better performance-wise to just use the SQL string in the application's code." (Please note that this is a small VB.NET WinForms development team that doesn't use MVVM or other similar design patterns)

Is that an accurate statement? I've not found anything in my googling prior to posting this question that would indicate running stored procedures has a bigger impact to performance than a regular SQL query.

答:
I have not heard of that as a problem.

However stored procedures can be a bit more of a headache when it comes to making changes, or having changes obvious, and none of your reasons have to lead to using stored procedures.

You can make methods with the SQL strings in and call them wherever required in the code to remove duplication of queries. Also there is nothing stopping you using parameters on sql held in strings in the code.

For example.

```<code>var sql = "SELECT empSalary from employee where salary = @salary";
var connection = new SqlConnection(/* connection info */);
var command = new SqlCommand(sql, connection);

command.Parameters.AddWithValue("salary", txtSalary.Text);
</code>```

Title: Stored Procedure performance

Body:
I have not heard of that as a problem.

However stored procedures can be a bit more of a headache when it comes to making changes, or having changes obvious, and none of your reasons have to lead to using stored procedures.

You can make methods with the SQL strings in and call them wherever required in the code to remove duplication of queries. Also there is nothing stopping you using parameters on sql held in strings in the code.

For example.

var sql = "SELECT empSalary from employee where salary = @salary";
var connection = new SqlConnection(/* connection info */);
var command = new SqlCommand(sql, connection);

command.Parameters.AddWithValue("salary", txtSalary.Text);


问:
How is this pattern called?
Is there a name for this pattern where an API offers several variations of a method (differing in number of parameters) and internally forwards them with default parameters like this: </p>

```<code>public void doSomething(Object one) {
    doSomething(one, null);
}

public void doSomething(Object one, Object two) {
    doSomething(one, two, null);
}

public void doSomething(Object one, Object two, Object three) {
        // real implementation here
}
</code>```

答:
It's one use of overloading

In some programming languages, function overloading or method overloading is the ability to create multiple methods of the same name with different implementations. Calls to an overloaded function will run a specific implementation of that function appropriate to the context of the call, allowing one function call to perform different tasks depending on context.

If you are asking about this specific use case, then I don't know of a particular term, although it can be used as a substitute for optional parameters.

Title: How is this pattern called?


答:
As said the methods with different parameter lists is simple overloading.

The fact they call each other is simply a refactor to reduce duplication in the code. You could copy and paste the real implementation into each method body, but that would create problems when the common code changed (you would need to update the code in each method) so having the methods call each other is an obvious refactor.

In C# 4.0 and after you could use optional parameters to do the same

```<code>public void doSomething(Object one, Object two = null, Object three = null)
{
        // real implementation here
}
</code>```

Title: How is this pattern called?

Body:
Is there a name for this pattern where an API offers several variations of a method (differing in number of parameters) and internally forwards them with default parameters like this: </p>

```<code>public void doSomething(Object one) {
    doSomething(one, null);
}

public void doSomething(Object one, Object two) {
    doSomething(one, two, null);
}

public void doSomething(Object one, Object two, Object three) {
        // real implementation here
}
</code>```

Body:
As said the methods with different parameter lists is simple overloading.

The fact they call each other is simply a refactor to reduce duplication in the code. You could copy and paste the real implementation into each method body, but that would create problems when the common code changed (you would need to update the code in each method) so having the methods call each other is an obvious refactor.

In C# 4.0 and after you could use optional parameters to do the same

public void doSomething(Object one, Object two = null, Object three = null)
{
        // real implementation here
}


答: Way back when, the ODBC driver used to be a bottleneck, because it was very thorough about type-checking all arguments. If you invoked a stored procedure with more than a couple parameters, it would be noticeably slower than sending in a string with all the parameters embedded in it. That said, I would hope that the drivers available today would work better, so you should see an advantage to using stored procedures if your operations are more than a dozen or so lines of SQL. Regardless, you definitely shouldn't see a performance hit.</p>

Title: Stored Procedure performance

Body:
I'm working on upgrading an application written by a former developer at my work and I've been converting all the SQL queries in the code into Stored Procedures. I'm doing this with the idea that it can be easily called whenever it is needed instead of having the SQL query string repeated several times in the code. Also, I can easily use parameters with the stored procedure and avoid SQL injection vulnerabilities in my code.

I was talking with another developer on my team who asked why I did it that way and told me that "calling stored procedures a lot can impact the SQL Server's performance and that it is better performance-wise to just use the SQL string in the application's code." (Please note that this is a small VB.NET WinForms development team that doesn't use MVVM or other similar design patterns)

Is that an accurate statement? I've not found anything in my googling prior to posting this question that would indicate running stored procedures has a bigger impact to performance than a regular SQL query.


问:
Alternative way to expose you're returning Nothing in a method
I'm kind of in an impasse here.

Lets say I have module A which exposes some methods returning objets and module B that uses said methods from Module A. Module A will have situations when it will have to return Nothing.

The problem is: Of course I don't want to return Nothing. Many, many books, top-coders and heuristics will tell you. However, the use of exception is not allowed due to massive use of Module A. That would apparently kill performances.

At last, we do not want to use auto-instanciated objet and have to check inside state to know if it's in fact Nothing (like a check-null...)

What would be an alternative for Module A to expose it can return something empty (or nothing) and for everyone using it like Module B to be needed to check such case (like signed exceptions try-catch)?

Any help will be really appreaciated! I'm pretty much out of solution and I want to do something clean that will be able to evoluation without causing unwanted behaviours and errors. Thanks

--EDIT--

To close this question, project managers decided to return Nothing everywhere. They accept to have some production crash due to forgotten nothing-check...
From what I gathered during this timelaps, I'd say that the best alternative would be the Try-object patern, because it forces the client to check the why is the return a boolean and how to use the call... at least on first use.

答: As I mentionned in an edit of the question, the try-object pattern is the best alternative to this problem.</p>


答:
Theoretically, you can do that. But practically, it won't work.

When you license something as open source, you don't necessarily need to license it to everyone. You can choose to only license it to a selected audience.

But any open source license includes an unlimited right to sub-license. That means anyone who receives a copy under the Apache license can sublicense it under the same conditions to anyone they want, including "This Company", and there is nothing you can do against it (not as long as you still want to call your software Open Source and its license the Apache license).

You are of course free to create an own crayon license based on the Apache license which forbids redistribution to "This Company". It's your work and you alone can decide who can use it and for what. But when you make use of your copyright in this way, please do not call it open source.

Title: Can I have two licenses in a Repository? One for a company and another one for everybody else?

Body:
So, I wrote a little piece of software (really little piece of software) and I want to open source it using Apache License for EVERYBODY but for a company, for that company I want the license to be GPL.

Is this possible? If so how should I implement this? I just add a License section in the github readme explaining that is open source for everybody but for "This Company"?


问:
How to do peer reviews on GitHub pull requests?
We're moving from Bitbucket to GitHub and one thing we are struggling with are peer code reviews that worked very smoothly on Bitbucket like this:

Author opened a Pull Request (GitHub: the same)

Author added his/her colleagues as reviewers (GitHub: ?? struggling here with multiple assignees)

Reviewer either:

Approved the PR with green check mark (GitHub: ??)

Added comments (GitHub: the same)

Created lightweight tasks (GitHub: sort of similar if - [ ] syntax is used in the PR description; shame that it doesn't work for tasks )

There's a list of PRs where I can see at a glance which are reviewed and OK to be merged and which need further attention (GitHub: ??)

I should point out that we want to avoid 3rd party code review tools if at all possible and would like to stay on vanilla GitHub with some sort of workarounds.

答:
From what I've seen, most of those steps are done on Github by convention, and not by any official Github-provided process.

My employer uses Github, I run a good number of small open source projects, and make occasional contributions to other open source projects.

Here is how I've usually seen it done:

Author adding his/her colleagues as reviewers:

This varies from project to project, but in general, the assigned peer reviewers are all of the contributors to the project.

Open source projects seem to have a rough hierarchy - maybe their convention would be to only merge after a "core" contributor has given the okay.

At the shop where I am currently employed, we merge after any one of the half-dozen developers on the team has given their approval.

On rare occasions someone on the team may use a comment to specifically call out another developer that they think should peer review the code before it is merged, but otherwise, whoever gets there first and feels like doing so can review and make comments.

Reviewer approval:

Approval is typically shown by making a comment on the pull request saying "+1" or "lgtm" (looks good to me).

Lightweight tasks:

I've used the checkboxes as well, but in most cases, every comment on a pull request is considered an implicit "task" that is resolved either by:

changing the code that the line is commenting on

responding with another comment

Seeing at a glance what is approved and what still needs reviewed:

I have used the Looks Good To Me extension for Chrome, which gives you such a view from the Pull Requests screen.  The pull requests list view seems to have been broken by recent Github changes, though.


问:
What evidence is there that obeying the Open/Closed principle reduces bugs?
I'm currently putting together a talk where I discuss the value of unit tests in enforcing the SOLID Open/Closed principle.

However beyond the obvious "the bug wasn't there when I wrote it, it's been introduced" I'm looking for a definitive study which proves that obeying the SOLID rule of "Open to Extension but Closed to Change" will reduce the number of bugs introduced in our code?

Are there any irrefutable studies or figures I can cite to prove the value of obeying this rule.

答:
There's no such thing as a definitive or irrefutable study.

However, see Bug Inducing Analysis to Prevent Fault Prone Bug Fixes, which conducts an empirical study of bugs and the means used to fix them.   Section 4.2 states: "From the statistics, we can see that the percentage of
typeDeclarationAdded in bug-inducing changes is much lower than in non-bug-inducing changes.
Thus, we can make the assumption that typeDeclarationAdded
may be a much safer way to fix a bug."


答:
Yes, syntax matters, although really only for readability. Compare:

```<code>for i in range(10):
   print(i)
</code>```

(Yeah that's Python)
with

```<code>FOR(i<-RNG-<10){PRN<-i}
</code>```

(Yeah, that's a language I just made up)
Both would do exactly the same thing, in the same way, but the syntax is different, and Python is easier to read. So yes, syntax definitely matters. Even "syntactical sugar" matters.

```<code> @property
 def year(self):
     return self._date.year
</code>```

Is easier to read than

```<code> def year(self):
     return self._date.year
 year = property(year)
</code>```

Title: Does syntax really matter in a programming language?

Body:
One of my professors says "the syntax is the UI of a programming language", languages like Ruby have great readability and it's growing, but we see a lot of programmers productive with C\C++, so as programmers does it really matter that the syntax should be acceptable?

I would love to know your opinion on that.

Disclaimer: I'm not trying to start an argument. I thought this is a good topic of discussion.

Update: This turns out to be a good topic. I'm glad you are all participating in it.

Body:
Yes, syntax matters, although really only for readability. Compare:

for i in range(10):
   print(i)

(Yeah that's Python)
with

FOR(i<-RNG-<10){PRN<-i}

(Yeah, that's a language I just made up)
Both would do exactly the same thing, in the same way, but the syntax is different, and Python is easier to read. So yes, syntax definitely matters. Even "syntactical sugar" matters.

 @property
 def year(self):
     return self._date.year

Is easier to read than

 def year(self):
     return self._date.year
 year = property(year)

ContentLicense: CC BY-SA 2.5


答:
Two licenses in one repository is something that can be done. This is known as dual licensing and typically is the case when an author wants to release software under different licenses so that it can be used in projects that are restrictive (a BSD project can't include GPL code - so an author may wish to release under BSD and GPL).

However, a key part of the open source definition is "No Discrimination Against Persons or Groups" - you can't restrict a company from using the software under Apache if it is available to them under that license.  So, to the question of "licensing to one company under GPL and everyone else under Apache" - no, you can't do that, or rather you can't do that in a way that has any teeth.

Something else that is occasionally done is that one may release publically under one license (say AGPL) and than offer the ability for organizations to pay to receive the license under another (less restrictive) one.  An example of this can be seen with iText, which releases their software under AGPL, but provides another license for companies that wish to use a different license that isn't as restrictive (and is presumably, not an open source license).


答:
External dependencies should be mocked because you can't control them (they might pass during the integration testing phase but fail in production). Drives can fail, database connections could fail for any number of reasons, there could be network problems etc. Having integration tests doesn't give any extra confidence because they're all problems that could happen at runtime.

With true unit tests, you're testing within the limits of the sandbox and it should be clear. If a developer wrote an SQL query that failed in QA/PROD it means they didn't even test it once before that time.

Title: Are (database) integration tests bad?


答:
Write the smallest useful test you can. For this particular case, an in-memory database might help with that.

It is generally true that everything that can be unit-tested should be unit-tested, and you're right that unit tests will take you only so far and no further—particularly when writing simple wrappers around complex external services.

A common way of thinking about testing is as a testing pyramid. It's a concept frequently connected with Agile, and many have written about it, including Martin Fowler (who attributes it to Mike Cohn in Succeeding with Agile), Alistair Scott, and the Google Testing Blog.

```<code>        /\                           --------------
       /  \        UI / End-to-End    \          /
      /----\                           \--------/
     /      \     Integration/System    \      /
    /--------\                           \----/
   /          \          Unit             \  /
  --------------                           \/
  Pyramid (good)                   Ice cream cone (bad)
</code>```

The notion is that fast-running, resilient unit tests are the foundation of the testing process. There should be more focused unit tests than system/integration tests, and more system/integration tests than end-to-end tests. As you get closer to the top, tests tend to take more time/resources to run, tend to be subject to more brittleness and flakiness, and are less-specific in identifying which system or file is broken; naturally, it's preferable to avoid being "top-heavy".

To that point, integration tests aren't bad, but heavy reliance on them may indicate that you haven't designed your individual components to be easy to test. Remember, the goal here is to test that your unit is performing to its spec while involving a minimum of other breakable systems: You may want to try an in-memory database (which I count as a unit-test-friendly test double alongside mocks) for heavy edge-case testing, for instance, and then write a couple of integration tests with the real database engine to establish that the main cases work when the system is assembled.

As you noted, it's possible for tests to be too narrow: you mentioned that the mocks you write simply test how something is implemented, not whether it works. That's something of an antipattern: A test that is a perfect mirror of its implementation isn't really testing anything at all. Instead, test that every class or method behaves according to its own spec, at whatever level of abstraction or realism that requires.

In that sense your method's spec might be one of the following:

Issue some arbitrary SQL or RPC and return the results exactly
(mock-friendly, but doesn't actually test the query you care about)

Issue exactly the SQL query or RPC and return the results exactly
(mock-friendly, but brittle, and assumes SQL is OK without testing it)

Issue an SQL command to a similar database engine and check that it
returns the right results (in-memory-database-friendly,
probably the best solution on balance)

Issue an SQL command to a staging copy of your exact DB engine
and check that it returns the right results
(probably a good integration test, but may be prone to infrastructure
flakiness or difficult-to-pinpoint errors)

Issue an SQL command to your real production DB engine and check that
it returns the right results
(may be useful to check deployed behavior, same issues as #4 plus
the dangers of modifying production data or overwhelming your server)

Use your judgment: Pick the quickest and most resilient solution that will fail when you need it to and give you confidence that your solution is correct.

Title: Are (database) integration tests bad?

Body:
Write the smallest useful test you can. For this particular case, an in-memory database might help with that.

It is generally true that everything that can be unit-tested should be unit-tested, and you're right that unit tests will take you only so far and no further—particularly when writing simple wrappers around complex external services.

A common way of thinking about testing is as a testing pyramid. It's a concept frequently connected with Agile, and many have written about it, including Martin Fowler (who attributes it to Mike Cohn in Succeeding with Agile), Alistair Scott, and the Google Testing Blog.

        /\                           --------------
       /  \        UI / End-to-End    \          /
      /----\                           \--------/
     /      \     Integration/System    \      /
    /--------\                           \----/
   /          \          Unit             \  /
  --------------                           \/
  Pyramid (good)                   Ice cream cone (bad)

The notion is that fast-running, resilient unit tests are the foundation of the testing process. There should be more focused unit tests than system/integration tests, and more system/integration tests than end-to-end tests. As you get closer to the top, tests tend to take more time/resources to run, tend to be subject to more brittleness and flakiness, and are less-specific in identifying which system or file is broken; naturally, it's preferable to avoid being "top-heavy".

To that point, integration tests aren't bad, but heavy reliance on them may indicate that you haven't designed your individual components to be easy to test. Remember, the goal here is to test that your unit is performing to its spec while involving a minimum of other breakable systems: You may want to try an in-memory database (which I count as a unit-test-friendly test double alongside mocks) for heavy edge-case testing, for instance, and then write a couple of integration tests with the real database engine to establish that the main cases work when the system is assembled.

As you noted, it's possible for tests to be too narrow: you mentioned that the mocks you write simply test how something is implemented, not whether it works. That's something of an antipattern: A test that is a perfect mirror of its implementation isn't really testing anything at all. Instead, test that every class or method behaves according to its own spec, at whatever level of abstraction or realism that requires.

In that sense your method's spec might be one of the following:

Issue some arbitrary SQL or RPC and return the results exactly
(mock-friendly, but doesn't actually test the query you care about)

Issue exactly the SQL query or RPC and return the results exactly
(mock-friendly, but brittle, and assumes SQL is OK without testing it)

Issue an SQL command to a similar database engine and check that it
returns the right results (in-memory-database-friendly,
probably the best solution on balance)

Issue an SQL command to a staging copy of your exact DB engine
and check that it returns the right results
(probably a good integration test, but may be prone to infrastructure
flakiness or difficult-to-pinpoint errors)

Issue an SQL command to your real production DB engine and check that
it returns the right results
(may be useful to check deployed behavior, same issues as #4 plus
the dangers of modifying production data or overwhelming your server)

Use your judgment: Pick the quickest and most resilient solution that will fail when you need it to and give you confidence that your solution is correct.

ContentLicense: CC BY-SA 4.0


问:
How common are "bandage" fixes?
Imagine the following scenario:

You've detected that your (or someone else's) program has a bug - a function produces the wrong result when given a particular input. You examine the code and can't find anything wrong: it just seem to bog out when given this input.

You can now do one of two things: you either examine the code further until you've found the actual cause; or you slap on a bandage by adding an if statement checking if the input is this particular input - if it is, return the expected value.

To me, applying the bandage would be completely unacceptable. If the code is behaving unexpectingly on this input, what other input that you've missed will it react strangely to? It just doesn't seem like a fix at all - you're just shoveling the problem under the rug.

As I wouldn't even consider doing this, I'm surprised at how often the professors and books keep reminding us about how applying "bandage" fixes is not a good idea. So this makes me wonder: just how common are these kinds of "fixes"?

答:
Disambiguation.

Given a particular bug, there is considerable difficulty in objectively defining whether a particular fix is a "bandage" because: one's "correct solution" may be another person's "bandage".

So, I use the following definition: to fix a defect in a manner that is less elegant and less well-studied than I wish I would have done professionally.

First, regarding the frequency of "bandage" fixes:

New code: almost none.

Old code:

You will find some, although they are usually written elegantly enough (see "data-driven mitigation" below) that they don't look like bandages and will survive all code reviews.

Also pay attention to the "invisible bandage": simply don't call that function. With the lack of code, there is not even a trace of hint that a bug exists.

Old code with many external dependencies:

Almost full of it.

It was almost always written for an obsolete version of the dependency, and nobody really read the dependency's "release notes" before updating the dependency to a new version.

Second, my advice:

If the bug happens in a development team's own source code:

Fix it in a professional way. (If you fix it, you own it.)

When under time pressure, do the best things you can - which requires you to:

Look at the potential impact on the end-user: of the bug itself, and of the proposed fix, in order to decide whether to accept the fix.

Study related code snippets (using the history info from your source code management tool), and discuss with your coworkers (but don't occupy too much of their time), until you have well understood the problem and the solution.

Always track the bug with a defect tracking system.

If the bug happens in another team's source code:

Push that team to fix their bug.

Always file that bug with the other team's defect tracking system.

If the bug happens in another company's (or no company's) product:

In this case, duct-tape fixes (or data-driven workarounds) might be the only way to fix the bug.

If it is open source, file that bug with some (possibly public) defect tracking system anyway, so that someone can look into it.

Title: How common are "bandage" fixes?


问:
REST Service Description in a Hypermedia agnostic way?
How do I implement REST service description in a Content-type agnostic way?

Background

I am developing a RESTful API for Web Application. Now this app is somewhat different than a standard run-of-mills solution. This app uses a SIP B2BUA (asterisk), PHP+Mysql on Apache & NodeJS.

It is a call center solution that uses asterisk to handle VoIP calls and a LAMP stack for the UI.

Architecture

REST demands that application be stateless. However, due to the very nature of SIP, it cannot be 100% stateless. Thus I am using NodeJS at certain places to keep the real-time communication going.

Now, there is a REST API to all of this. It is designed in a pretty simple way. You have resources like user, call, campaign etc. And a user can initiate HTTP Verbs on these resources.

The Questions

I have arranged the architecture following the MVC pattern. The most salient thing I have done is, enforce Docblocks in the Models. The following is an example of such a class:

```<code>abstract class BaseUserInterface implements Interfaces\UserInterface {
protected $usrType = null;

/**
 * This is the constructor
 */
public function __construct(Interfaces\User $usrObj){
    $this->usrType = ($usrObj instanceof \Model\Agent) ? 'agent':$this->usrType;
    $this->usrType = ($usrObj instanceof \Model\Admin) ? 'admin':$this->usrType;
    if($this->usrType === null){
        throw new \Framework\APIException(__CLASS__." : Insane Type of User Passed while initiating Interface", 500);
    }

    //Force docblocks
    $methodList = $this->listMethods();
    foreach($methodList as $method){
        $docblock = $this->describe($method);
        if(!$docblock){
            throw new \Framework\APIException(__CLASS__." : Contract Violated - Method $method Lacks Documentation", 500);
        }
    }
} //End __construct

/**
 * This is the typeOfInterface
 */
public function typeOfInterface(){ //return whether this is admin or agent interface
    return $this->usrType;
} //End typeOfInterface

/**
 * This is the listMethods
 */
public function listMethods(){ //Allowed Methods
    return get_class_methods($this);
} //End listMethods

/**
 * This is the describe
 */
public function describe($methodName){
    $methodList = $this->listMethods();
    if(!in_array($methodName, $methodList)){
        throw new \Framework\APIException(__CLASS__." : Asked To Describe Insane Method - ".$methodName, 400);
    }
    $class = get_class($this);
    $reflector = new \ReflectionClass($class);
    $phpdoc = $reflector->getMethod($methodName)->getDocComment();
    if($phpdoc){
        return $this->docParse($phpdoc);
    }
    else {
        return false;
    }
} //End describe

/**
 * This is the DocParser
 */
protected function docParse($phpdoc){
    $phpdoc = new \phpDocumentor\Reflection\DocBlock($phpdoc);
            return $phpdoc->getShortDescription()."<br />";
} //End docParse

abstract public function logout();
</code>```

Of course, I have given an idea of the docblocks and not the complete docblocks here. Basically, they would have the necessary documentation. Now, all the classes in Model namespace that would extend this class would have to use docblocks thereby enforcing documentation.

Also, I have a Helper::convert() function that can convert any result between XML and JSON depending on the user's Accept Request in the HTTP Header.

So, I am all set with that.

What I am utterly confused with is:
1. I want the user to be able to ask for Describe() on available methods at a given resource. How do I implement that via HTTP headers?

OPTIONS in HTTP tells me to respond with allowed VERBS on ***this*** resource.

I want to have a common gateway to the app. User asks for /index.php. I respond with user, call, campaign and a brief message telling them that they can use GET on these resources to know more. Then upon those resources, I want to display available methods followed by description of the selected method and so on and so forth.

Most importantly, I want to respond in the user's chosen accept-header if supported by me.

How do I go about doing this following correct conventions? Also, some references to RFCs would be really appreciated.

答:
I'm not familiar with technologies like SIP and VOIP, but I think I can give answers to the four questions you have.

I want the user to be able to ask for Describe() on available methods at a given resource. How do I implement that via HTTP headers?

In a RESTful API, resources point to each other using links. I will focus on the case that your API returns XML or JSON (rather than HTML). These formats do not have a standard way of representing links, so you must pick a standard, or invent your own. Anyway, I think a link should not only specify a URI, but also the HTTP method to be used. If multiple HTTP methods can be used on the same URI, then there should a link for each of these HTTP methods. Example:

```<code>{
    "id": "12345",
    "name": "John Brown",
    "update" : { "href" : "/persons/12345", "method" : "PATCH" },
    "delete" : { "href" : "/persons/12345", "method" : "DELETE" }
}
</code>```

So this is how you can inform the client which methods are available.

OPTIONS in HTTP tells me to respond with allowed VERBS on this resource.

Fine, but the RESTful APIs I have seen do not use OPTIONS. They use links as the only means to convey the allowed HTTP methods to their clients.

I want to have a common gateway to the app. User asks for /index.php. I respond with user, call, campaign and a brief message telling them that they can use GET on these resources to know more.

Yes, you can respond with an XML or a JSON message containing links as described above. Example:

```<code>{
    "user" : { "href" : "/users/{userID}", "method" : "GET" },
    "call" : { "href" : "/calls/{callID}", "method" : "GET" },
    "campaign" : { "href" : "/campaign", "method" : "GET" }
}
</code>```

Then upon those resources, I want to display available methods followed by description of the selected method and so on and so forth.

Yes, when the client follows one of the links, it gets a JSON representation of that resource, containing links specifying what can be done with that resource.

Most importantly, I want to respond in the user's chosen accept-header if supported by me.

Yes, you can check that header and return a response in the appropriate format.

For more REST conventions proposed by myself, check out JAREST.

Body:
I'm not familiar with technologies like SIP and VOIP, but I think I can give answers to the four questions you have.

I want the user to be able to ask for Describe() on available methods at a given resource. How do I implement that via HTTP headers?

In a RESTful API, resources point to each other using links. I will focus on the case that your API returns XML or JSON (rather than HTML). These formats do not have a standard way of representing links, so you must pick a standard, or invent your own. Anyway, I think a link should not only specify a URI, but also the HTTP method to be used. If multiple HTTP methods can be used on the same URI, then there should a link for each of these HTTP methods. Example:

{
    "id": "12345",
    "name": "John Brown",
    "update" : { "href" : "/persons/12345", "method" : "PATCH" },
    "delete" : { "href" : "/persons/12345", "method" : "DELETE" }
}

So this is how you can inform the client which methods are available.

OPTIONS in HTTP tells me to respond with allowed VERBS on this resource.

Fine, but the RESTful APIs I have seen do not use OPTIONS. They use links as the only means to convey the allowed HTTP methods to their clients.

I want to have a common gateway to the app. User asks for /index.php. I respond with user, call, campaign and a brief message telling them that they can use GET on these resources to know more.

Yes, you can respond with an XML or a JSON message containing links as described above. Example:

{
    "user" : { "href" : "/users/{userID}", "method" : "GET" },
    "call" : { "href" : "/calls/{callID}", "method" : "GET" },
    "campaign" : { "href" : "/campaign", "method" : "GET" }
}

Then upon those resources, I want to display available methods followed by description of the selected method and so on and so forth.

Yes, when the client follows one of the links, it gets a JSON representation of that resource, containing links specifying what can be done with that resource.

Most importantly, I want to respond in the user's chosen accept-header if supported by me.

Yes, you can check that header and return a response in the appropriate format.

For more REST conventions proposed by myself, check out JAREST.


答:
No, they are not bad.  Hopefully, one should have unit and integration tests.  They are used and run at different stages in the development cycle.

Unit Tests

Unit tests should be run on the build server and locally, after the code has been compiled.  If any unit tests fail, one should fail the build or not commit the code update until the tests are fixed.  The reason why we want unit tests isolated is that we want the build server to be able to run all the tests without all the dependencies. Then we could run the build without all the complex dependencies required and have a lot of tests that run very fast.

So, for a database, one should have something like:

```<code>IRespository

List<Product> GetProducts<String Size, String Color);
</code>```

Now the real implementation of IRepository will go to the database to get the products, but for unit testing, one can mock IRepository with a fake one to run all the tests as needed without an actaul database as we can simulate all sorts of lists of products being returned from the mock instance and test any business logic with the mocked data.

Integration Tests

Integration tests are typically boundary crossing tests.  We want to run these tests on the deployment server (the real environment), sandbox, or even locally (pointed to sandbox).  They are not run on the build server. After the software has been deployed to environment, typically these would be run as post deployment activity.  They can be automated via command line utilities.  For example, we can run nUnit from the command line if we categorize all the integration test we want to invoke.  These actually call the real repository with the real database call.  These type of tests help with:

Environment Health Stability Readiness

Testing the real thing

These tests are sometimes harder to run as we may need to set up and/or tear down as well.  Consider adding a product.  We probably want to add the product, query it to see if it was added, and then after we are done, remove it.  We don't want to add 100s or 1000s of "integration" products, so additional set-up is required.

The integration tests can prove to be quite valuable to validate an environment and making sure the real thing works.

One should have both.

Run the unit tests for every build.

Run the integration tests for every deployment.

Title: Are (database) integration tests bad?

Body:
No, they are not bad.  Hopefully, one should have unit and integration tests.  They are used and run at different stages in the development cycle.

Unit Tests

Unit tests should be run on the build server and locally, after the code has been compiled.  If any unit tests fail, one should fail the build or not commit the code update until the tests are fixed.  The reason why we want unit tests isolated is that we want the build server to be able to run all the tests without all the dependencies. Then we could run the build without all the complex dependencies required and have a lot of tests that run very fast.

So, for a database, one should have something like:

IRespository

List<Product> GetProducts<String Size, String Color);

Now the real implementation of IRepository will go to the database to get the products, but for unit testing, one can mock IRepository with a fake one to run all the tests as needed without an actaul database as we can simulate all sorts of lists of products being returned from the mock instance and test any business logic with the mocked data.

Integration Tests

Integration tests are typically boundary crossing tests.  We want to run these tests on the deployment server (the real environment), sandbox, or even locally (pointed to sandbox).  They are not run on the build server. After the software has been deployed to environment, typically these would be run as post deployment activity.  They can be automated via command line utilities.  For example, we can run nUnit from the command line if we categorize all the integration test we want to invoke.  These actually call the real repository with the real database call.  These type of tests help with:

Environment Health Stability Readiness

Testing the real thing

These tests are sometimes harder to run as we may need to set up and/or tear down as well.  Consider adding a product.  We probably want to add the product, query it to see if it was added, and then after we are done, remove it.  We don't want to add 100s or 1000s of "integration" products, so additional set-up is required.

The integration tests can prove to be quite valuable to validate an environment and making sure the real thing works.

One should have both.

Run the unit tests for every build.

Run the integration tests for every deployment.


问:
In general, is it worth using virtual functions to avoid branching?
There seems to be rough equivalents of instructions to equate to the cost of a branch miss virtual functions have a similar tradeoff:

instruction vs. data cache miss

optimization barrier

If you look at something like:

```<code>if (x==1) {
   p->do1();
}
else if (x==2) {
   p->do2();
}
else if (x==3) {
   p->do3();
}
...
</code>```

You could have a member function array, or if many functions depend on the same categorization, or more complex categorization exists, use virtual functions:

```<code>p->do()
</code>```

But, in general, how expensive are virtual functions vs branching
It is hard to test on enough platforms to generalize, so I was wondering if any one had a rough rule of thumb (lovely if it were as simple as 4 ifs is the breakpoint)

In general virtual functions are clearer and I would lean towards them.  But, I have several highly critical sections where I can change code from virtual functions to branches. I would prefer to have thoughts on this before I undertake this. (it's not a trivial change, or easy to test across multiple platforms)

答:
Observations:

With many cases, virtual functions are faster because the vtable lookup is an O(1) operation while the else if() ladder is an O(n) operation. However, this is only true if the distribution of cases is flat.

For a single if() ... else, the conditional is faster because you save the function call overhead.

So, when you have a flat distribution of cases, a break-even point must exist. The only question is where it is located.

If you use a switch() instead of else if() ladder or virtual function calls, your compiler may produce even better code: it can do a branch to a location which is looked up from a table, but which is not a function call. That is, you have all the properties of the virtual function call without all the function call overhead.

If one is much more frequent than the rest, starting an if() ... else with that case will give you the best performance: You will execute a single conditional branch which is correctly predicted in most of the cases.

Your compiler has no knowledge of the expected distribution of cases and will assume a flat distribution.

Since your compiler likely has some good heuristics in place as to when to code a switch() as an else if() ladder or as a table lookup. I would tend to trust its judgment unless you know that the distribution of cases is biased.

So, my advise is this:

If one of the cases dwarfes the rest in terms of frequency, use a sorted else if() ladder.

Otherwise use a switch() statement, unless one of the other methods makes your code much more readable. Be sure that you don't buy a neglegible performance gain with significantly reduced readability.

If you used a switch() and are still not satisfied by the performance, do the comparison, but be prepared to find out that the switch() was already the fastest possibility.


问:
undirected c++ graph with a direction
I want to create a Graph in C++ that has directions, with directions I don't mean the direction of an edge but what I want is an undirected graph where the edges have a direction to the next vertex, for example lets consider we are in vertex1

```<code>up      = vertex2
right   = vertex3
down    = vertex4
left    = vertex5
</code>```

Lets consider the following basic classes

```<code> Class Edge{
    //To save an connection between two vertexes
    Vertex point1;
    Vertex point2;
 }

 Class Vertex
 {
     string description;
 }
</code>```

For this problem I came up with some possible solutions.

1. Give the vertexes a map with a direction (enum) and another Vertex for that direction (nullptr if no edge in that direction).

disadvantage is that we have to save directions on both vertexes or loop all other vertexes to see if it's connected to the current vertex.

pro? we don't need edges.

2.
Add an variable to the Edge object that contains a direction, we can make a rule that the direction is from point 1 to 2, so if the value of direction is down than the direction from point2 to point1 is up. We can save a list with all edges.

Also an important difference is that solution 1 save the edges in the vertexes and solution 2 in a class that contains a list with edges.

Context

What is important, is that I want to be able to set my position on a vertex and move around, when moved around I need to remember that I have used the connection between the vertexes. With solution 1 I can add a map for visited that has an enum direction (same as the concept to save the directions).
With solution 2 I could add a bool visited. I need to save the 'visited' variable because I want to test an edited dijksta algorithm based on visited edges.

In short, how should I create a undirected graph where the edges have a direction (direction as in up, down, left,right from current vertex).

What would you guys advise me to do?

答:
Divide your graph up into areas of fixed size.

Each areas vertices are now your fixed points of reference

Give your edges direction as they change position

Calculate your destination as vertices formed by edges from your fixed areas vertices.

Log the vertices, duration and or speed at each direction change

You can now pre-plot an arc or angle if required for a view or surface

Adding your direction as a would be compass direction from vertex 1 (origin) to vertex 2 (destination) would be as simple as determining if the vertices of the origin are greater or lower than the vertices of the destination. As for where you would store this value, this would be programmers discretion.

A similar method is employed by the game Minecraft. Searching on this might be of some aid.

Title: undirected c++ graph with a direction


答:
Syntax does matter, and I can give you two supporting examples: Dylan, which is a Lisp with a more conventional syntax, and Liskell, which is Haskell with Lisp-like syntax. In each case, a variant of the language was proposed that had exactly the same semantics, but radically different syntax.

In the case of Dylan, it was thought that dropping s-expressions in favor of something more conventional would help attract a wider range of programmers. It turned out that syntax wasn't the only thing preventing programmers from using Lisp.

In the case of Liskell, it was thought that using s-expressions would allow for easier use of macros. It turned out that macros really aren't necessary in Haskell, so that experiment didn't work either.

Here's the thing: if syntax didn't matter to anybody, neither experiment would have been tried.


答:
Database integration tests are not bad. Even more, they are necessary.

You probably have your application split into layers, and it's a good thing. You can test each layer in isolation by mocking neighbouring layers, and that's a good thing too. But no matter how many abstraction layers you do create, at some point there has to be layer that does the dirty work - actually talk to the database. Unless you test it, you don't test at all. If you test layer n by mocking layer n-1 you are evaluating assumption that layer n works on condition that layer n-1 works. In order for this to work, you must somehow prove that layer 0 works.

While in theory you could unit test database, by parsing and interpreting generated SQL, it's way much easier and more reliable to create test database on the fly and talk to it.

Conclusion

What's the confidence geined from unit testing your Abstract Repository, Ethereal Object-Relational-Mapper, Generic Active Record, Theoretic Persistence layers, when in the end your generated SQL contains syntax error?

Title: Are (database) integration tests bad?


问:
Java concurrency
I am working to solve interesting concurrent problem! Not sure if I understand it correctly since I am little bit confused.

The system needs to process the prices, and typically they cannot be processed as quickly as they arrive, so the implementation must sample the latest price. The external system produces prices for several entities, interleaved into a single sequence of the form:
 ```
Entity<sub>A</sub>: p<sup>a</sup>1,      p<sup>a</sup>2,          p<sup>a</sup>3...
Entity<sub>B</sub>:      p<sup>b</sup>1,      p<sup>b</sup>2, p<sup>b</sup>3 ...
       Time ▶ ▶ ▶
```
  For example, if during the time taken to process price pa1 the prices pa2, pa3, and pa4 arrive, the next price the application should process is pa4 and all previous prices should be ignored. Prices for other entities (e.g. pb1) do not affect the latest price entity for a, but are processed independently in the same way with respect to entity b.

For thread-safety I wanted to use ConcurrentMap

```<code>ConcurrentHashMap<String, BigDecimal> concurrentHashMap = new ConcurrentHashMap<String, BigDecimal>();

public BigDecimal getPrice(String id){
    return concurrentHashMap.get(id);
}

public void updatePrice(String id, BigDecimal newPrice){
    concurrentHashMap.put(id, newPrice);
}
</code>```

Will it guarantee a thread safe read/write?

If I write to key "a" will it lock the whole Map or writes to "b" key is available?

What does take following part of the task means? If during the time taken to process price Pa1 the prices Pa2, Pa3, and Pa4 arrive, then the next price the application should process is Pa4 and all previous prices should be ignored.  - Probably I am overcomplicating things but does that mean I should not store and cancel price update if new more recent price arrive? If yes, then how would implementation look like?

答:
From the documentation of ConcurrentHashMap:

However, even though all operations are thread-safe, retrieval operations do not entail locking, and there is not any support for locking the entire table in a way that prevents all access.

To answer your first two questions:

ConcurrentHashMap is guaranteed to be thread safe.

When writing, more than one write can happen at a time.  From the documentation:

The allowed concurrency among update operations is guided by the optional concurrencyLevel constructor argument (default 16), which is used as a hint for internal sizing. The table is internally partitioned to try to permit the indicated number of concurrent updates without contention.

This means that having a concurrencyLevel of 1 will mean you can only do one write at a time.  Having a concurrencyLevel of 16 means that up to 16 writes can happen at the same time.

Finally:

3.What does take following part of the task means? If during the time taken to process price Pa1 the prices Pa2, Pa3, and Pa4 arrive, then the next price the application should process is Pa4 and all previous prices should be ignored.

Here's my interpretation: You start by processing a price, in this case Pa1.  At the end of processing Pa1, you're looking to process the next price.  While processing Pa1, you received Pa2, Pa3, and Pa4.  When selecting the next price to process, you should ignore Pa2 and Pa3 because they're old, and only process Pa4.

This seems like a homework problem so I don't want to just outright give a solution, but you need to devise a way where, you only process the most recent price you've received.  You can do this by using a single variable priceToProcess which is updated whenever you receive a new price, or you could use a Queue and fill it with received prices(the last in the queue will be the one you process), etc.  There's definitely more than one way to accomplish this part.

Perhaps one point of confusion is the idea of processing a price - you don't necessarily process a price just because you received it.  You only process a price when you are not processing another price and there are no newer prices to process.

Title: Java concurrency


答:
If the delegation (and the default parameters filled in) are part of the function's contract, for example, if the DocString says

doSomething(one, two) is equivalent to doSomething(one, two, null).

then I refer to these as convenience overloads or convenience methods as they simply save the user some typing but don't do anything the user couldn't have done otherwise.

If the fact that the function simply delegates is not made public, then it is just an arbitrary implementation detail and probably does not deserve a special name.

I've picked this term up from the official Java documentation where it is used quite often.

A related idiom is to have a bunch of overloads for some public method doSomething that do nothing more than determining some parameters to then delegate to a private method doSomethingImpl. This is something different as the user is not aware of the existence of the doSomethingImpl method (and couldn't possibly call it). I have heard the doSomethingImpl be referred to as “worker method” or “workhorse” but those are probably very colloquial terms.

Title: How is this pattern called?


问:
Search Algorithm Question
I need to retrieve five stars from a group of stars so I can hide them by turning their visible flag to “false”.

I know the x, y coordinate value of each star I am looking for.
My algorithm opens a transaction and retrieves a group of stars whose x, y values falls within the extents of the five stars I am looking for.

This is faster than opening five separate transactions and looking at a particular x, y location of each star individually.

With the group of stars below what I want to do is to compare the x, y value of each star to find a match to the one of the five I am looking for.

Group of 400+ Stars to search

```<code>    *********************************************
    *********************************************
    *********************************************
    *********************************************
    *********************************************
    *********************************************
    *********************************************
    *********************************************
    *********************************************
</code>```

My thoughts on this is I have two choices for iterating through the collection:

(1) I can iterate through the 400+ stars one at a time, grab the x, y values of each and then iterate through the five sets of coordinates to see if it matches one of the five I am looking for.

(2) I can iterate through the “five stars to find” one at a time and then iterate the 400+ stars collection looking for a match

NB:

The stars collection has 400+ stars that fall within the extents.

The “visible” property only works for items in the stars collection.

The stars_to_find collection has the coordinates of the five stars I am looking for.

Code snippets

(1)

```<code>foreach (Star star in stars)
{
    foreach (Star star_to_find in stars_to_find)
    {
        if (star.Coordinates.Equals(star_to_find.Coordinates))
        {
            star.Visible = false;
        }
    }
}
</code>```

(2)

```<code>foreach (Star star_to_find in stars_to_find)
{
    foreach (Star star in stars)
    {
        if (star.Coordinates.Equals(star_to_find.Coordinates))
        {
            star.Visible = false;
        }
    }
}
</code>```

Is either search method, (1) or (2), faster than the other? Is there a different search algorithm that would work better?

答:
As a rule of thumb put the collection that is easiest to loop over on the inner most loop. Your 5 stars to find would just be a simple array so put that in the inner loop.

However it's much more efficient if you don't need a loop in the first place or reduce the number of iterations of the loop.

For example you could keep the stars in a nested Star[][] array (array of arrays) so you can do stars[x][y] and directly get the star you need.

If you need something less dense then you can use a hashmap and use the Coordinates as key. In both cases the eventual algorithm comes down to:

```<code>foreach (Star star_to_find in stars_to_find)
{
    stars.get(star_to_find.Coordinates).Visible = false;
}
</code>```

Title: Search Algorithm Question

Body:
As a rule of thumb put the collection that is easiest to loop over on the inner most loop. Your 5 stars to find would just be a simple array so put that in the inner loop.

However it's much more efficient if you don't need a loop in the first place or reduce the number of iterations of the loop.

For example you could keep the stars in a nested Star[][] array (array of arrays) so you can do stars[x][y] and directly get the star you need.

If you need something less dense then you can use a hashmap and use the Coordinates as key. In both cases the eventual algorithm comes down to:

foreach (Star star_to_find in stars_to_find)
{
    stars.get(star_to_find.Coordinates).Visible = false;
}


问:
Going TDD in the middle of the project
They want us to develop new features of a product with TDD.
I know that they don't usually write tests for legacy code of already developed modules.

But yet, what if new features have to be added to the legacy modules and we still want to stick with TDD?

答:
I've had a similar experience like MainMa described in his answer.

I've started working in the middle of a project that had a spaghetti code, a few unit tests but with some broken or commented, many god classes and a bad architecture design that required the developer to change 10 or 12 files just to add a DropDownList that retrieved data from the database.

When you try to use TDD in a project like that, you'll have a hard time to remove tightly coupled code, mock things and the scope of your tests may end up very limited. Refactoring is the best solution, but we know that if the technical debt is really high, no one is willing to pay for it.

However, even in maintenance projects, some features will be large enough to require a new Service or a new Web Page. When the time comes, take the opportunity to build it using TDD, good design patterns and to use a new architecture, if necessary. The objective is to break the loop of bad code and stop copying-paste messy choices.

With this approach, you will not pay the technical debt, but you can reduce it in absolute terms and, more important, overwhelm it in relative terms.

In a few months we had two distinct sides inside the same solution: one healthy that served as an example for junior devs to continue the work and another one that we called the "sick" part.

TL;DR

Refactoring old code to allow TDD is the best solution, but your manager may not authorize you to spend your time with this. At least, try to build new features/modules with good practices instead of copying-paste ugly code.

Title: Going TDD in the middle of the project


问:
A pattern to find out if data in a dialog-window was modified by the user?
I think about if there is a pattern or another intelligent solution for that problem. I am searching for a more generalized and reusable solution.

I load an existing and still persistent row/object from a database and display this data in a editable dialog-window to the user.

When closing the window I want to know if the user modfied the data in that dialog. e.g. I should write that modifications back to the database instance and store it.

I could simply check each attribut from the window with the database. Or I could add event-handlers to each component of the window that will set a isModified-flag or something like that. But this doesn't sounds intelligent to me.

Maybe there is a more generalized reusable solution for that?

答: I think your two options basically nail it. I tend to prefer the flag option. If you have a UI that's appropriate, this can be combined with the Command pattern (execute methods will store the current value of isModifies; undo methods restore the saved value).</p>


答: Generally speaking, when you need to search a collection for items that fall within a range of 2d coordinates, you should probably be using a quadtree (or an octree for 3d coordinates).</p>

Title: Search Algorithm Question

Body:
I need to retrieve five stars from a group of stars so I can hide them by turning their visible flag to “false”.

I know the x, y coordinate value of each star I am looking for.
My algorithm opens a transaction and retrieves a group of stars whose x, y values falls within the extents of the five stars I am looking for.

This is faster than opening five separate transactions and looking at a particular x, y location of each star individually.

With the group of stars below what I want to do is to compare the x, y value of each star to find a match to the one of the five I am looking for.

Group of 400+ Stars to search

```<code>    *********************************************
    *********************************************
    *********************************************
    *********************************************
    *********************************************
    *********************************************
    *********************************************
    *********************************************
    *********************************************
</code>```

My thoughts on this is I have two choices for iterating through the collection:

(1) I can iterate through the 400+ stars one at a time, grab the x, y values of each and then iterate through the five sets of coordinates to see if it matches one of the five I am looking for.

(2) I can iterate through the “five stars to find” one at a time and then iterate the 400+ stars collection looking for a match

NB:

The stars collection has 400+ stars that fall within the extents.

The “visible” property only works for items in the stars collection.

The stars_to_find collection has the coordinates of the five stars I am looking for.

Code snippets

(1)

```<code>foreach (Star star in stars)
{
    foreach (Star star_to_find in stars_to_find)
    {
        if (star.Coordinates.Equals(star_to_find.Coordinates))
        {
            star.Visible = false;
        }
    }
}
</code>```

(2)

```<code>foreach (Star star_to_find in stars_to_find)
{
    foreach (Star star in stars)
    {
        if (star.Coordinates.Equals(star_to_find.Coordinates))
        {
            star.Visible = false;
        }
    }
}
</code>```

Is either search method, (1) or (2), faster than the other? Is there a different search algorithm that would work better?


问:
Are there any arguments for using a local logger variable
PMD Rule LoggerIsNotStaticFinal:

In most cases, the Logger reference can be declared as static and final.

I seem to remember some arguments for using local variables for logging, but cannot recall it.

One example seems to be for an instance variable, but requires that it be a final, initialized in the constructor.

Another case I can think of (make up?) is when one might want to use different loggers for the same piece of code, perhaps dependent on some other variables.

Any other cases where a local variable of type logger may be more appropriate?

答:
I am not aware of any situation where a local logger makes sense over a static final logger using any of the built-in or industry-standard logging frameworks in Java.

Loggers are thread-safe, so threads can share loggers. Having "my own" logger does not have any benefit here.

Loggers are typically defined for one of the following categories:

For a fully-qualified class name. Having a local logger makes no sense, since two local loggers on different threads will resolve to the same object anyway.

For an arbitrary logger category. For example, perhaps all hardware events log to a dedicated hardware logger regardless of the code that responds to the event. As with the previous point, local copies of this logger will all resolve to the same object anyway.

If there are going to be multiple references to the same logger, it makes sense to have a single reference instead. There is a slight memory advantage that is not worth obsessing over, but the intent of this is the logger for this class is better represented by having it at the class level. Furthermore, retrieving the logger instance can be done once which might impact performance-critical code. It can also clutter code to have extraneous, unnecessary statements to retrieve a logger that can simply be retrieved at the top of the class.

Given how Java loggers work, there really is no advantage to a local logger.

What is more efficient from an execution and code clutter standpoint?

Static:

public class MyClass {
  private static final Logger LOG = Logger.getLogger(MyClass.class);

  public void doSomething1() {
    LOG.info("Yadda, yadda, yadda");
  }
}
```

<p>Local:</p>

<pre class="lang-java prettyprint-override"><code>public class MyClass {
  public void doSomething1() {
    Logger LOG = Logger.getLogger(MyClass.class);
    LOG.info("Yadda, yadda, yadda");
  }

  // OR...

  public void doSomething2() {
    Logger.getLogger(MyClass.class).info("Yadda, yadda, yadda");
  }
}
</code>```

The local statements are more verbose. Logging this way takes more space, which distracts the reader's eye from the code that actually does stuff.

There is no reason for acquiring local loggers.

Body:
I am not aware of any situation where a local logger makes sense over a static final logger using any of the built-in or industry-standard logging frameworks in Java.

Loggers are thread-safe, so threads can share loggers. Having "my own" logger does not have any benefit here.

Loggers are typically defined for one of the following categories:

For a fully-qualified class name. Having a local logger makes no sense, since two local loggers on different threads will resolve to the same object anyway.

For an arbitrary logger category. For example, perhaps all hardware events log to a dedicated hardware logger regardless of the code that responds to the event. As with the previous point, local copies of this logger will all resolve to the same object anyway.

If there are going to be multiple references to the same logger, it makes sense to have a single reference instead. There is a slight memory advantage that is not worth obsessing over, but the intent of this is the logger for this class is better represented by having it at the class level. Furthermore, retrieving the logger instance can be done once which might impact performance-critical code. It can also clutter code to have extraneous, unnecessary statements to retrieve a logger that can simply be retrieved at the top of the class.

Given how Java loggers work, there really is no advantage to a local logger.

What is more efficient from an execution and code clutter standpoint?

Static:

public class MyClass {
  private static final Logger LOG = Logger.getLogger(MyClass.class);

  public void doSomething1() {
    LOG.info("Yadda, yadda, yadda");
  }
}

Local:

public class MyClass {
  public void doSomething1() {
    Logger LOG = Logger.getLogger(MyClass.class);
    LOG.info("Yadda, yadda, yadda");
  }

  // OR...

  public void doSomething2() {
    Logger.getLogger(MyClass.class).info("Yadda, yadda, yadda");
  }
}

The local statements are more verbose. Logging this way takes more space, which distracts the reader's eye from the code that actually does stuff.

There is no reason for acquiring local loggers.


答:
In addition to cmaster's good answer, which I upvoted, keep in mind that function pointers are generally strictly faster than virtual functions. Virtual functions dispatch generally involves first following a pointer from the object to the vtable, indexing appropriately, and then dereferencing a function pointer. So the final step is the same, but there are extra steps initially. In addition, virtual functions always take "this" as an argument, function pointers are more flexible.

Another thing to keep in mind: if your critical path involves a loop, it can be helpful to sort the loop by dispatch destination. Obviously this is nlogn, whereas traversing the loop is only n, but if you are going to traverse many times this can be worth it. By sorting by dispatch destination, you ensure that the same code is executed repeatedly, keeping it hot in icache, minimizing cache misses.

A third strategy to keep in mind: if you decide to move away from virtual functions/function pointers towards if/switch strategies, you may also be well served by switching from polymorphic objects to something like boost::variant (which also provides the switch case in the form of the visitor abstraction). Polymorphic objects have to be stored by base pointer, so your data is all over the place in cache. This could easily be a bigger influence on your critical path than the cost of virtual lookup. Whereas variant is stored inline as a discriminated union; it has size equal to the largest data type (plus a small constant). If your objects don't differ in size too much, this is a great way to handle them.

Actually, I wouldn't be surprised if improving the cache coherency of your data would have a bigger impact than your original question, so I'd definitely look more into that.

Title: In general, is it worth using virtual functions to avoid branching?

Body:
There seems to be rough equivalents of instructions to equate to the cost of a branch miss virtual functions have a similar tradeoff:

instruction vs. data cache miss

optimization barrier

If you look at something like:

```<code>if (x==1) {
   p->do1();
}
else if (x==2) {
   p->do2();
}
else if (x==3) {
   p->do3();
}
...
</code>```

You could have a member function array, or if many functions depend on the same categorization, or more complex categorization exists, use virtual functions:

```<code>p->do()
</code>```

But, in general, how expensive are virtual functions vs branching
It is hard to test on enough platforms to generalize, so I was wondering if any one had a rough rule of thumb (lovely if it were as simple as 4 ifs is the breakpoint)

In general virtual functions are clearer and I would lean towards them.  But, I have several highly critical sections where I can change code from virtual functions to branches. I would prefer to have thoughts on this before I undertake this. (it's not a trivial change, or easy to test across multiple platforms)


答:
Unit tests don't catch all defects.  But they are cheaper to set up and (re)run compared that other kinds of tests.  The unit tests are justified by combination of moderate value and low-to-moderate cost.

Here's a table showing defect detection rates for different kinds of testing.

source: p.470 in Code Complete 2 by McConnell

Title: Are (database) integration tests bad?


问:
Understanding Enums in Java
In the book Effective Java its told that:

The basic idea behind Java’s enum types is simple: they are classes that export
  one instance for each enumeration constant via a public static final field. Enum
  types are effectively final, by virtue of having no accessible constructors.

So, if I have an enum like:

public enum Orange {NAVEL, TEMPLE, BLOOD}

Then, it must be similar to:

```<code>public class Orange implements Comparable , implements Serializable {
    private Orange() {}

    public static final Orange NAVEL = new Orange();
    public static final Orange TEMPLE = new Orange();
    public static final Orange BLOOD = new Orange();

    public int compareTo(Orange other) {}
}
</code>```

To this point it seems fine, but after some time the examples get over complicated, for example I am still puzzled over the following enum definition.

```<code>public enum Ensemble {
    SOLO(1), DUET(2), TRIO(3), QUARTET(4), QUINTET(5),
    SEXTET(6), SEPTET(7), OCTET(8), DOUBLE_QUARTET(8),
    NONET(9), DECTET(10), TRIPLE_QUARTET(12);

    private final int numberOfMusicians;

    Ensemble(int size) {
        this.numberOfMusicians = size;
    }

    public int numberOfMusicians() {
        return numberOfMusicians;
    }
}
</code>```

What could be its similar class equivalent and is there a length property on it?

答:
The latter example corresponds to a class like this:</p>

```<code>public final class Ensemble {
    public static final Ensemble SOLO = new Ensemble(1);
    public static final Ensemble DUET = new Ensemble(2);
    public static final Ensemble TRIO = new Ensemble(3);
    ...
    public static final Ensemble TRIPLE_QUARTET = new Ensemble(12);

    private final int numberOfMusicians;

    private Ensemble(int size) {
        this.numberOfMusicians = size;
    }

    public int numberOfMusicians() {
        return numberOfMusicians;
    }
}
</code>```

Title: Understanding Enums in Java

Body:
The latter example corresponds to a class like this:

public final class Ensemble {
    public static final Ensemble SOLO = new Ensemble(1);
    public static final Ensemble DUET = new Ensemble(2);
    public static final Ensemble TRIO = new Ensemble(3);
    ...
    public static final Ensemble TRIPLE_QUARTET = new Ensemble(12);

    private final int numberOfMusicians;

    private Ensemble(int size) {
        this.numberOfMusicians = size;
    }

    public int numberOfMusicians() {
        return numberOfMusicians;
    }
}


问:
Should we include the NuGet PACKAGE folder in version control?
In a C# or VB.NET project, should we include the PACKAGE folder (NuGet package folder that is created in the root of my project that contains the nupkg files and other content) to our source control repository (Git for instance)?</p>

答:
The basic rule for what goes into a source control repository is that you store there everything related to a project that you need to be able to build, test, deploy and execute the project and which can not be generated from items already present in the repository.

In other words, if you can throw away the PACKAGE folder and its contents without affecting your ability continue working on the project (the build might take longer, but you don't have to hunt down and install anything yourself), then the folder can be safely left out of the repository.

If the folder contains 3rd-party packages that might take a long time to download or that might become unavailable, then that might be a reason to add them to your repository anyway.


问:
Difference between Software Engineering and IT?
I see mostly everyone distinguishes between being a Software Engineer and being in IT on the jobs sections of their site. What are the definitions of each, and the distinction between them?</p>

答: In Morocco, to be an IT, it's required to study programming in general for 2 years.. but to be an engineer , you must study at least for 5 years , technically... the software engineer is somemone who not only writes programs, but he takes security, flexibility and reusibility in mind. An IT can only be specialized in either security,flexibility or reusability.</p>

OwnerDisplayName: Jungle Hunter

OwnerDisplayName: Simo TAQI


问:
How to reconcile "not mocking what you don't own" with "expectations" in unit tests?
I'm putting together a set of models for use in a Zend Framework 2 application. So, each model has a table class which acts as the interface between the model and database for querying. Using the ZF2 TableGateway means that even a fairly simple query, like getting the number of hits from a page log between two dates, ends up with some complex calls:

public function getDailyHits($start, $end)
{
    $select = $this->tableGateway->getSql()->select();

    $select->columns(array(
            "date" => new Expression("DATE_FORMAT(timestamp, '%Y-%m-%d')"),
            "hits" => new Expression("COUNT(timestamp)"),
        ));

    $select->where->between("timestamp", $start, $end);

    $select->group("date");

    $results = $this->tableGateway->selectWith($select);

    $dailyHits = array();
    foreach ($results as $result) {
        $dailyHits[$result->date] = $result->hits;
    }

    return $dailyHits;
}
```

<p>When it came to developing the unit test, I wrote up a bunch of expectations:</p>

<pre class="lang-php prettyprint-override"><code>public function testGetDailySearches()
{
    // Setup
    $result = new \stdClass();
    $result->date = "2015-01-01";
    $result->searches = 42;

    $resultSet = array($result);

    $sql = $this->getMockBuilder("Zend\Db\Sql\Sql")
        ->disableOriginalConstructor()
        ->getMock();

    $select = $this->getMockBuilder("Zend\Db\Sql\Select")
        ->disableOriginalConstructor()
        ->getMock();

    $where = $this->getMockBuilder("Zend\Db\Sql\Where")
        ->disableOriginalConstructor()
        ->getMock();

    $tableGateway = $this->getMockBuilder("Zend\Db\TableGateway\TableGateway")
        ->disableOriginalConstructor()
        ->getMock();

    $searchLogTable = $this->getMockBuilder("Usage\Model\Table\SearchLog")
        ->setConstructorArgs(array($tableGateway))
        ->setMethods(null)
        ->getMock();

    // Expectations
    $tableGateway->expects($this->once())
        ->method("getSql")
        ->will($this->returnValue($sql));

    $tableGateway->expects($this->once())
        ->method("selectWith")
        ->with($this->equalTo($select))
        ->will($this->returnValue($resultSet));

    $sql->expects($this->once())
        ->method("select")
        ->will($this->returnValue($select));

    $select->expects($this->once())
        ->method("columns")
        ->will($this->returnValue($select)); // TODO: need to assert parameters

    $select->expects($this->once())
        ->method("__get")
        ->with($this->equalTo("where"))
        ->will($this->returnValue($where));

    $where->expects($this->once())
        ->method("between")
        ->with(
            $this->equalTo("time"),
            $this->equalTo("2015-10-01 00:00:00"),
            $this->equalTo("2015-10-07 23:59:59")
        )
        ->will($this->returnValue($select));

    $select->expects($this->once())
        ->method("group")
        ->with($this->equalTo("date"));

    // Assertions
    $this->assertEquals(
        array("2015-01-01" => 42),
        $searchLogTable->getDailySearches("2015-10-01 00:00:00", "2015-10-07 23:59:59")
    );
}
</code>```

I had a go at using Prophecy to reduce the verbosity in these tests, but got tripped up on them magic __get method needed to read the $where property from the Select object.

After reading through a couple of threads on the Prophecy site, I uncovered a link to That's Not Yours. It makes a lot of sense. It also would reduce a lot of boilerplate in some tests if I just subclass TableGateway (or even maybe just mock it) so that all the Zend\Db behaviour is retained.

But, then what happens to my expectations? Is this a case of overengineered testing? Should I have these expectations, or should I rely on testing a mostly black box of a method?

If I did remove those expectations, and relied on a mocked result from the subclassed/mocked selectWith, I could write a passing test which didn't specify any of the select criteria, and would fail to function as required in the real world.

答:
The point of your test should be that it tests if getDailyHits returns the expected results. It is not doing that right now. It's a meaningless test that simply checks that your implementation makes a bunch of calls, instead of testing the behaviour itself. When for some reason your implementation or database structure changes you should not have to edit this test, which is what you will be doing right now.

This is a kind of test where I would actually run against the database itself. By some standards that would not make this a 'unittest', but it makes a lot of sense to test this against the database.

Think of it like this: if you could, would you write a piece of code to test that the generated SQL from this statement matches some predefined SQL that you think might work? Or would you rather test that the result of that query matches what you expect and does not lack data or return things it shouldn't?


问:
The Model or the Controller write data on the view in MVC and what is the use of the Model if we have data in Store?
I've read several articles, watched videos and read questions on here, but the more I read and learn about MVC - including MVCS or MVP in addition.. to make it even worse -  the broader the pattern seems, so I apologize if the question is broad or long it is just because I really want to figure it out and understand its combination.

First:

Is it the Model which writes, renders or updates data  on the View, or it's the Controller, I've seen places where the developer uses the first approach, while the latter is used more  - which makes more sense to me because of the view-controller pair and since the Model better be separated, or this what I think - but even with a simple block diagram, this varies a lot.

Second:

Having these generic logic codes for the two examples:

Example 1:

```<code>// UserModel:
function getUsersDetails(id= false){
    if(id){
        // Fetch that specific user details with the id provided
    }else{
        // Fetch all users details
    }
}
// UserController:
result = UserModel->getUsersDetails(id) // id is optional depending on the view
</code>```

Example2:

```<code>// UserModel:
function getAllUsersDetails(){
    // Fetch all users details
}
function getUserDetails(id){
    // Fetch that specific user details
}

//UserController:

    //for ONE user details View
    result = UserModel->getUserDetails(id)

    //for a View of ALL users
    result = UserModel->getAllUsersDetails()
</code>```

Which one of the above examples is the better approach, personally I guess it is the Example2 because of the "no logic in the Model" rule, but if so, this confuses me even more when some people say "No SQL in the Model, instead put it in repositories or a Store".
If the Model should not contain logic, and better not contain SQL , what would it be consist of then, just empty methods calling functions from the repositories? wouldn't this make it unnecessary and add more complexity to the whole design.

I apologize if the post has many questions or it is broad and Thanks in Advance

答:
MVC is a software architectural pattern for implementing user interfaces. Its concrete form highly depends on the technologies used, so it is difficult to describe how it works in detail outside the context of a specific stack of technologies.

Is it the Model which writes, renders or updates data on the View, or it's the Controller

The View has references to the Model, specifying which data is displayed how and where. The underlying framework or programming language makes sure that updates to the Model are automatically propagated to the View. The source code of the Model does not have explicit references to the View. The Controller may manipulate the View explicitly, not to change model data, but for user interaction purposes. The Controller should not directly change the presentation of model data, but should change the Model and, by doing that, change the View indirectly.

The above is the most common view on MVC, but this is not enforced by law.

Which one of the above examples is the better approach

This question is not related to the MVC concept. It is allowed to have business logic in the Model (e.g. validation checks), but it is not allowed to have user interaction logic in the Model. The logic you describe is neither business logic nor user interaction logic, but it is a matter of software decomposition. I think the second approach is better from a separation of concerns perspective: A single function should not both provide a collection of data and provide one item from that collection, depending on a special value of the parameter.

If the Model should not contain logic, and better not contain SQL , what would it be consist of then, just empty methods calling functions from the repositories?

It depends on your application architecture. For example, an application may consist of three layers: the database, a business logic layer or services layer on top of it and then a presentation layer. In that case, MVC is usually only applied in the presentation layer. It may (or may not) be a design decision to let business logic be executed exclusively in the business logic layer. In that case, the Model in the presentation layer does not contain any logic at all, it is just a bunch of data, supported by a framework or a programming language that makes sure that model data is synchronized with model data in the business logic layer and eventually in the database. But other architectures are possible too. It's up to the software architect to make the decisions clear.