问:
What is an example of a computationally impossible business problem?
I have coworker who refuses to accept the reality that Turing machines (and Von Neuman machines by extension) cannot solve their own halting problem stating:

You can do anything with enough time and money.

He also dislikes theoretical problems arguing that:

In our field, we'll never run into those questions. We're application developers, not theoretical scientists.

Is there a good example of a business problem that is computationally impossible that I could use to help convince him of this?

答:
The classic example is trying to parse HTML with regular expressions.
This can work with limited sets of HTML but a general solution is impossible, due  to the fact that they have different Chomsky grammars (as the link makes clear(ish)).

More generally some people don't like to think philosophically (like your co-worker) and I'm not sure you can argue your way out of a mind set.  His  first point is certainly wrong but his second might just be a way of saying I don't need to worry about this to code web forms for goods receiving.  I've got some sympathy with this but sometimes knowing the theory means you don't commit yourself to finding the Holy Grail on work time.


问:
Semantic versioning for desktop applications
I can easily follow the Semantic Versioning recommendations if I develop a library or API, but what if the developed product is a website or a desktop application?

When would you increment a major component in that case?

In case of a complete UI redesign? Or something else?

Thoughts?

答:
I adapted semantic versioning for desktop or web applications, so in our work we are using:
X.Y.Z

Z is increasing if a release contains just a bug fix, dependencies update or some application internal changes, so no new functionality introduced to user;

Y is increasing if a release contains minor changes in UI or just introduces some new feature, or some feature redesign/functionality update which will affect user;

X is increasing if a release contains major UI/functionality update, for example: new interface design/layout;

New project starts with version 0.1 and minor version is increasing with development;

If a project contains all planned functionality for version 1.0 the version should be changed to 1.0.

ContentLicense: CC BY-SA 3.0


问:
What is the name of the functional argument in fold
In the higher order function fold/reduce what is the name, if any, of the functional argument?

I am working on a monadic tabular processing library where rows are folded to produce simple analyses (like finding the minimum, maximum, average of a column).  I am therefore looking for a sound name for the argument of the fold function and any name which is well-established in the ML community (or Haskell or Common Lisp as second and third candidates) would be interesting.

A name like f is common in the description of fold functions, it is however undescriptive and a noun would be better suited.

答:
I disagree with the idea that f is a bad name for the function argument of fold.  The reason we want descriptive names in programming is so we know what the name describes, and the name f is commonly used in mathematics (and functional programming languages) for a function (as are g and h).

We know almost nothing about f (by design, since if we could be more specific about it, we could not use fold on as many things), and the name f tells us everything we need to know, except that it is a function of two arguments.  The name f is a lot like the pronoun 'it' in English -- it's a placeholder which could mean almost anything.  We don't know what 'it' is until we use it in a sentence, and we don't know what f is until we call fold.

When naming things, we want to get as much information out of the name as possible, and we prefer the name to be short (if we can get that without sacrificing important information).  Here, we have a very short name that tells us nearly everything we know about it.  I don't think it can be improved on.

In imperative programming, i is used as a loop counter (as are j and k, if we need more); in functional programming, f is used for a function argument in higher-order functions (as are g and h, if we need more).  I don't have enough experience with functional languages to be sure that the f/g/h convention is as well established as the i/j/k convention, but if it isn't, I think it should be (it definitely is established in mathematics).


答:
The most common name for this that I've heard other than the pronoun f would be binary operation or binary function - the problem with being more specific than that is it could do literally anything, and that's why people stick to the type signature a -> b -> a (or a -> b -> b if it's right fold).

So I propose that you do exactly that, stick to the type signature, luckily that specific type signature does have a name: binary function, just like a -> a is a unary operation, and a -> b is a unary function, you can call a -> a -> a a binary operation and a -> b -> c a binary function.

Title: What is the name of the functional argument in fold

Body:
In the higher order function fold/reduce what is the name, if any, of the functional argument?

I am working on a monadic tabular processing library where rows are folded to produce simple analyses (like finding the minimum, maximum, average of a column).  I am therefore looking for a sound name for the argument of the fold function and any name which is well-established in the ML community (or Haskell or Common Lisp as second and third candidates) would be interesting.

A name like f is common in the description of fold functions, it is however undescriptive and a noun would be better suited.


问:
The value of potential shippability when the product is not minimally viable yet
The main benefit of having a potentially shippable product at the end of each Sprint is the ability to release the product quickly in case market conditions change.

However, usually in the first half year or more the product doesn't have enough value to be actually shipped. So why spend all this energy to make a potentially shippable increment each Sprint if you know with complete certainty that the product won't be shipped?

答:
No, the main benefit of having a potentially shippable product at end of each iteration is ability to get early feedback, to show developers are actually doing something and to motivate developers to actually do something. The "potentially shippable" has nothing to do with actually being able to ship it, but fact that the software has to be in shippable quality.

In this case, there is no problem having really bare-bones product at beginning of the project, as long as customer is able to produce feedback based on it.


答:
There is value in having a shippable product because it implies that the product quality has been kept higher than it would be if development was performed with a longer term shipping plan.

One has to keep in mind the motivation for the "shippable" requirement. In many software projects with a long development schedule, a lot of resources might go into developing one portion of the software, usually the area called "essential infrastructure" when communicating with higher level managers. This may lead to an imbalance whereby too much resources are spent on one area, while other areas, such as testing, or UI design, are starved of resources. In the end, resources may run out, and the end result is an unusable product.

If on the other hand, the product is kept "shippable", the project at least feels like it was not a complete waste, even if the plug is pulled on development mid-way.

Title: The value of potential shippability when the product is not minimally viable yet

Body:
The main benefit of having a potentially shippable product at the end of each Sprint is the ability to release the product quickly in case market conditions change.

However, usually in the first half year or more the product doesn't have enough value to be actually shipped. So why spend all this energy to make a potentially shippable increment each Sprint if you know with complete certainty that the product won't be shipped?


问:
Super Fast File Storage Engine
I basically have one big gigantic table (about 1.000.000.000.000 records) in a database with these fields:

id, block_id, record

id is unique, block_id is not unique, it contains about 10k (max) records with the same block_id but with different records

To simplify my job that deals with the DB I have an API similar to this:

```<code>Engine e = new Engine(...);
// this method must be thread safe but with fine grained locked (block_id) to improve concurrency
e.add(block_id, "asdf"); // asdf up to 1 Kilobyte  max

// this must concatenate all the already added records added block_id, and won't need to be bigger than 10Mb (worst case) average will be <5Mb
String s = e.getConcatenatedRecords(block_id);
</code>```

If I map each block to a file(haven't done it yet), then each record will be a line in the file and I will still be able to use that API

But I want to know if I will have any peformance gain by using flat files compared to a well tunned postgresql database ? (at least for this specific scenario)

My biggest requirement though is that the getConcatenatedRecords method returns stupidly fast (not so with the add operation). I am considering caching and memory mapping also, I just don't want to complicate myself before asking if there is an already made solution for this kind of scenario ?

答:
Key-value NoSQL databases are practically made for this scenario. In your case, you are looking for something like secondary index on top of key-value store.

I'm not experienced in this field, so I can't tell you concrete implementation or tool to use. But I believe you can find something that can fit your needs.

Title: Super Fast File Storage Engine


答:
Part of the reason is that it is up to stakeholders to determine when the product is worthy of release, and this determination is based upon demonstrating the results of each sprint.  At any arbitrary point, the product could be deemed "good enough" and released.

It may take many more iterations to bring the project to completion, but it's quite possible that a very small sub-set of features provide the bulk of the product's value, making it worthwhile to release early.  If prioritization is done right, those features should be done first.

Iterative development methodologies make no assumptions about how early that "good enough" stage is reached, so it's easiest to make sure the product can always be shipped.


问:
Can a scrum master reprimand his team?
Scrum master is a facilitator for the delivery team and acts as a bridge between Project Management and the team. In course of time if he realizes that his team is not delivering the deliverables perfectly possible w.r.t competency of his team, can he question his team members why it is not happening?

It is more like a show-cause notice to them. He knows why it is not happening eg:- spending time on social sites or wasting time on less important issues.

Is it okay for him to say "reprimand" the delivery team on their style of working? Or should it be escalated and left for the functional managers to deal with it?

Important thing to note is that usually in an Org, the scrum master is a good friend with his team and so it makes all the more awkward to react to such a situation.

答:
The scrum master advocates for the team to management and the customer.  The product owner advocates for the customer to the team.  The manager advocates for the company to individual team members.

That's an oversimplification because good leaders try to balance all concerns, but those are their primary responsibilities.  They are split into separate people to make it easier to separate conflicts of interest.

So issues of personal productivity, like excessive web use, should be handled by the manager.  However, issues of team productivity which are not a direct result of personal performance can certainly be addressed by the scrum master.

Take your example of wasting time on less important issues.  A scrum master can find out why team members feel they need to spend time on those things, and advocate for the team in resolving it.  That's why we have retrospectives.  Maybe time really does need to be carved out for those things.  Maybe other groups like product management are applying pressure to work on tasks not in the plan, and that pressure needs to be removed.  Maybe team members simply aren't aware of how much time goes into those activities.  Maybe priorities aren't being communicated clearly.  Maybe your team commits to too much work in progress, so team members try to finish it all instead of focusing on the highest priorities.  These are the kinds of things a scrum master should fix.

Title: Can a scrum master reprimand his team?


答:
Reprimand is very strong word. And it's not a question of can you do it. Of course you can reprimand anyone you want.  But should you do it?  I find that when management/leadership takes this type of approach, it generally demoralizes the team and doesn't really improve anything.  So you tell me, I can't be on P.SE during work hours.  How would that translate into me giving you higher output?

As others have mentioned, low output and people browsing the internet is an effect.  Your question is how do you fix this symptom but you need to look deeper for the root cause.

And before you look too deep (and the reason why I want to add my 2 cents here) is you (and possibly some of your management) should familiarize yourself with the core ideas behind Agile and motivations to have those ideas in the first place.

In essence, Agile advocates a decentralized form of control, where the management sets general direction but leaves everything else up to the team.  Decisions such as how we are going to deliver, how long its going to take, what technology to use, who will work on what.  The team should decide that on their own.  The reason for that is because people doing the work, really have the most knowledge about how to do that work and when it comes to schedules, if my boss tells me that I have 5 days to finish a task, I go back to my desk and continue working as usual. If it takes 10 days, it must be poor planning on my boss' part. If it takes 4 days, I'll spend the other day doing who knows what.  Whereas when your developers make the decisions, and developer is the one who says, it shouldn't take me more than 5 days, that developer has a stronger personal pressure to deliver on his word but it only works if those 5 days aren't shoved down his throat from up top.

As you keep doing your sprints, part of your process should be to continuously look for improvements, which is what retrospectives are about. And again, the whole thing is completely developer focused.  "Guys, let's discuss what slowed you down and what frustrated you." Identify the biggest frustrations and eliminate those first and repeat.  People will feel more energized and motivated to deliver if they see that the company structure is designed to help them and make their lives easier.

If you do it right, your entire team should get into the mindset (it will take some time but not as long as you'd think, I've seen it done in 3 months) of we are in this together.  We control our schedule.  We want to build a great product.  The key is "we".  When you get to that point, a) if someone isn't carrying his own weight, his own teammates will call him out and ask, Bob "we" are waiting for you to finish this, what's up??  and b) people will feel more strongly about delivering because their own teammates, not management, are depending on them.  So when you get to that point, there will be absolutely no need to reprimand anyone.

This answer is based partially on Agile, partially on management theories they teach in MBA school (yes I went back to school to get masters degree in the dark side), and partially on my own experience in my previous company.  I had a great boss who let me try all kinds of things with our team.  We implemented a lot of the ideas that "true" agile advocates, and although we haven't fully gotten there (didn't have regular retrospectives and unit tests were significantly lacking) but in terms of attitudes, motivations and general ethic, our team really did turn around 180 degrees in 3 months.  And while we worked hard, and often logged in at night or at other random times just to complete stuff here and there, a) no one ever asked or forced us to work extra hours and b) we were probably the happiest development team in the entire organization because a lot of corporate BS stopped at our manager.

Title: Can a scrum master reprimand his team?

Body:
Scrum master is a facilitator for the delivery team and acts as a bridge between Project Management and the team. In course of time if he realizes that his team is not delivering the deliverables perfectly possible w.r.t competency of his team, can he question his team members why it is not happening?

It is more like a show-cause notice to them. He knows why it is not happening eg:- spending time on social sites or wasting time on less important issues.

Is it okay for him to say "reprimand" the delivery team on their style of working? Or should it be escalated and left for the functional managers to deal with it?

Important thing to note is that usually in an Org, the scrum master is a good friend with his team and so it makes all the more awkward to react to such a situation.


答:
Not to be too picky but the Scrum Master's duties are all about Scrum and not giving promotions, checking time sheets, tracking days off etc. That doesn't mean the same person can't be the SM and the department manager.

I don't know about reprimand, but the Scrum Master's roles involve: making sure Scrum is being done correctly, balancing work loads with stake holder expectations, helping the team perform at a high-level, etc. Some Scrum Masters come from a team lead/manager position, so there may be additional management duties where the SM plays a different role like doing an annual evaluation (not very Scrim-like).

The SM is obligated to let a team know that there is a problem. Teams have to be held accountable and it is very difficult for a SM to tell everyone outside the team that they are working at capacity when they are not. It may not be accurate and/or fair, but if an outside manager sees the team slacking-off, it's going to be that much more difficult for the SM to defend the team when they fail to deliver.

If it is a particular individual that the team has failed to motivate, that person may need a reprimand not from the SM but some other manager who could in fact be the same person.

Title: Can a scrum master reprimand his team?


问:
Should I have unit tests for known defects?
If my code contains a known defect which should be fixed, but isn't yet, and won't be fixed for the current release, and might not be fixed in the forseeable future, should there be a failing unit test for that bug in the test suite? If I add the unit test, it will (obviously) fail, and getting used to having failing tests seems like a bad idea. On the other hand, if it is a known defect, and there is a known failing case, it seems odd to keep it out of the test suite, as it should at some point be fixed, and the test is already available. </p>

答:
Depending on the test tool you may use an omit or pend function.

Example in ruby:

```<code>gem 'test-unit', '>= 2.1.1'
require 'test/unit'

MYVERSION = '0.9.0' #Version of the class you test

class Test_omit < Test::Unit::TestCase
  def test_omit
    omit('The following assertion fails - it will be corrected in the next release')
    assert_equal(1,2)
  end

  def test_omit_if
    omit_if(MYVERSION < '1.0.0', "Test skipped for version #{MYVERSION}")
    assert_equal(1,2)
  end

end
</code>```

The omit command skips a test, the omit_if combines it with a test - in my example I test the version number and execute the test only for versions where I expect the error is solved.

The output of my example is:

```<code>Loaded suite test
Started
O
===============================================================================
The following assertion fails - it will be corrected in the next release [test_omit(Test_omit)]
test.rb:10:in `test_omit'
===============================================================================
O
===============================================================================
Test skipped for version 0.9.0 [test_omit_if(Test_omit)]
test.rb:15:in `test_omit_if'
===============================================================================

Finished in 0.0 seconds.

2 tests, 0 assertions, 0 failures, 0 errors, 0 pendings, 2 omissions, 0 notifications
0% passed
</code>```

So my answer: Yes, implement the test. But don't confuse a tester with errors, where you know it will fail.

Body:
Depending on the test tool you may use an omit or pend function.

Example in ruby:

gem 'test-unit', '>= 2.1.1'
require 'test/unit'

MYVERSION = '0.9.0' #Version of the class you test

class Test_omit < Test::Unit::TestCase
  def test_omit
    omit('The following assertion fails - it will be corrected in the next release')
    assert_equal(1,2)
  end

  def test_omit_if
    omit_if(MYVERSION < '1.0.0', "Test skipped for version #{MYVERSION}")
    assert_equal(1,2)
  end

end

The omit command skips a test, the omit_if combines it with a test - in my example I test the version number and execute the test only for versions where I expect the error is solved.

The output of my example is:

Loaded suite test
Started
O
===============================================================================
The following assertion fails - it will be corrected in the next release [test_omit(Test_omit)]
test.rb:10:in `test_omit'
===============================================================================
O
===============================================================================
Test skipped for version 0.9.0 [test_omit_if(Test_omit)]
test.rb:15:in `test_omit_if'
===============================================================================

Finished in 0.0 seconds.

2 tests, 0 assertions, 0 failures, 0 errors, 0 pendings, 2 omissions, 0 notifications
0% passed

So my answer: Yes, implement the test. But don't confuse a tester with errors, where you know it will fail.


问:
How do I read the Entity Framework Model and validate it against a given connection?
I have a Entity Framework Database First Model.

I want to write a MSTest/nUnit test to verify that all the stored procs, tables and views that are defined in my edmx model are still valid on the database.

答:
I found the answer:

```<code>var list = context.MetadataWorkspace.GetItems<EdmFunction>(DataSpace.SSpace).Where(i=>i.ReturnParameter == null);
</code>```

This returned the correct schema and stored procedure name. I then could call for each item in the list:

```<code>var sqlCommands = string.Format("SELECT 'x' FROM sys.objects WHERE object_id = OBJECT_ID(N'{0}') AND type in (N'P', N'PC')", storedProcedureName);
var exists = dbContext.Database.SqlQuery<string>(sqlCommands).Any();
</code>```

Body:
I found the answer:

var list = context.MetadataWorkspace.GetItems<EdmFunction>(DataSpace.SSpace).Where(i=>i.ReturnParameter == null);

This returned the correct schema and stored procedure name. I then could call for each item in the list:

var sqlCommands = string.Format("SELECT 'x' FROM sys.objects WHERE object_id = OBJECT_ID(N'{0}') AND type in (N'P', N'PC')", storedProcedureName);
var exists = dbContext.Database.SqlQuery<string>(sqlCommands).Any();


问:
Why should we NOT do frequent deployment in PROD or to test server?
I was instructed by my project manager that frequent deployment in PROD or to test server should be avoided. But I don't understand why? We roll our testing copy to PROD on every sprint end but suddenly client would ask a simple change to the existing application which would require a re-deployment. When every thing was well tested and QA approved. why should we avoid frequent deployment?

How it was done universally?

答:
There are always cases where issues are found in prod.  Back to back deploys can make it MUCH more difficult in many cases to determine the actual source of the problems.  Other than that I would deploy as often as everyone is comfortable with.

On the other hand, the client is the boss, if they want it deployed now with no testing that is there option and unless there is something irreversibly dangerous about it that you can explain to them about the change you have little recourse but to document the request, the approval, and make certain you have a way to go back if they don't like the outcome.

You are not always going to have total process buy-in from the client.

ContentLicense: CC BY-SA 2.5


答:
Potentially shippable doesn't necessarily mean that the product make sense or is desirable from a market perspective. Just that it works from an engineering one.

I understand 'potentially shippable' as an encouragement to manage technical and functional debt:

you should not break something that used to work (no regression)

you should have few enough defects that if you were to ship in emergency, it would be quick enough (a couple days) to fix

any feature or story declared 'done' should be working, if unperfect

any dead code (critical bug preventing access to a functionality or code not working at all) is NOT ok and needs to be fixed or finished with the highest priority.

minor bugs, polish, enhancements are ok, as they're just other stories and can be prioritized as they deserve


答:
It seems like your "storage system" whatever that is has a very simple abstraction interface. It essentially boils down to "here's an id, gimme data".

So you can easily define this interface and build your entire app on top of it.  Behind the scenes you can continue using PostgreSQL like you do today. And if you want to experiment with flat file storage, it should take you more than 1 or 2 days to implement something very simple that reads/writes files straight on disk  (my recommendation is to have 1-3 tiers of directories based on first portion of the ID, so you don't have too many files in one flat directory).

If you do that you can compare the performance straight up and see if it's good enough for you.

However, as Euphoric pointed out, most NOSQL stores where introduced and became popular for the very purpose that you are trying to accomplish.  I'm not going to recommend a specific store as that's something for you to decide but some advantages they provide are:

managing storage of huge amounts of small entities by buffering and doing writes in larger chunks.  In my experience most file systems can work with very large numbers of files, but not in the most efficient way. For example, if you were to try to delete that many files from disk, unless you just reformat the whole disk, it could take multiple hours just for "rm -rf *" command.

If and when you outgrow the limitations of a single physical box, a lot of NoSQL solutions allow you to scale horizontally which will give you a) more storage, b) redundancy of data so if one host goes down, your storage server is still online and c) faster query times since your clients can load balance where they get the info.

Another option to consider is that potentially your storage and your indexing does not have to be implemented in the same system.  You could use a separate indexing product like Solr or Elasticsearch and store the actual data in a NoSQL DB (or a straight-up file system)

Title: Super Fast File Storage Engine

Body:
I basically have one big gigantic table (about 1.000.000.000.000 records) in a database with these fields:

id, block_id, record

id is unique, block_id is not unique, it contains about 10k (max) records with the same block_id but with different records

To simplify my job that deals with the DB I have an API similar to this:

```<code>Engine e = new Engine(...);
// this method must be thread safe but with fine grained locked (block_id) to improve concurrency
e.add(block_id, "asdf"); // asdf up to 1 Kilobyte  max

// this must concatenate all the already added records added block_id, and won't need to be bigger than 10Mb (worst case) average will be <5Mb
String s = e.getConcatenatedRecords(block_id);
</code>```

If I map each block to a file(haven't done it yet), then each record will be a line in the file and I will still be able to use that API

But I want to know if I will have any peformance gain by using flat files compared to a well tunned postgresql database ? (at least for this specific scenario)

My biggest requirement though is that the getConcatenatedRecords method returns stupidly fast (not so with the add operation). I am considering caching and memory mapping also, I just don't want to complicate myself before asking if there is an already made solution for this kind of scenario ?


答:
Assuming we may set aside moral questions aside for the moment:

Business A has contracted to you for a way to communicate between satellite offices A1 and A2 without anyone besides the authorized people in A1 and A2 being able to understand the communication.

Business B has contracted to you for a way to intelligently eavesdrop on all communications between A1 and A2.

Obviously you can't do both.

Due to the way the math works out (the exact math has been subject to ongoing research for 100 years), one of the following requirements cannot be satisfied:

(1): Provide an encryption algorithm that cannot be broken by an attacker with an arbitrary amount of money available.

(2): Provide an encryption breaking algorithm for an arbitrary encryption algorithm that runs in a reasonable time.

Title: What is an example of a computationally impossible business problem?

Body:
I have coworker who refuses to accept the reality that Turing machines (and Von Neuman machines by extension) cannot solve their own halting problem stating:

You can do anything with enough time and money.

He also dislikes theoretical problems arguing that:

In our field, we'll never run into those questions. We're application developers, not theoretical scientists.

Is there a good example of a business problem that is computationally impossible that I could use to help convince him of this?


答:
You seem to be painting yourself in a corner here.

I don't see why a product can't be minimally viable within weeks (if not days, for example see hackathons) instead of months. It depends on the product and the market and who you are shipping to, and for what purpose.

What do you mean by "minimally viable"? Does it need to be polished? If so, how would it be minimally viable? In many cases I've seen products never becoming minimally viable because "no one would buy them". But that's not what minimally viable means. A product you can't sell, you can demo or trial, for example. Or you can give away a minimal version without all the bells and whistles for free to build user base before you introduce new features.

Keeping the product under wraps until it's "ready" (big-bang release) it's the opposite of MVP. :-)

By definition, each iteration will deliver value in form of potentially shippable increments. Since iterations iterations do deliver value, why isn't the product minimally viable? I agree it won't be great, though, initially and probably not sell-worthy.

"Viable" doesn't mean anything by itself: for what purpose it should be viable?

Who are we shipping to? Not all users have the same requirements. You can often ship to a subset of users much earlier.

A personal anecdote. At Stack Exchange we are always shipping. Let's take our own mobile apps: as soon as we had the build system created, we started using them internally. There was a build going out to interested internal employees within weeks, and an alpha/beta program for selected users. Most of these users did not see a polished, complete, bug-free app, but the feedback we got was invaluable. We are now shipping our first app "for real", openly, to the public, but there's absolutely no doubt that our earlier "potentially shippable" increments were super-valuable for feedback and field testing.


问:
Is dependency injection essential for unit testing?
Is using dependency injection (DI) essential for unit testing?

I can't think of another alternative for isolating code so it can be tested. Also, all the examples I have ever seen use this pattern. Is that because it is the only viable option or are there other alternatives?

答:
Yes, there are alternatives to the use of DI for isolation.

One alternative is to use factories or a ServiceLocator which can be configured from tests to return mock objects instead of real ones.

Another is to use a suitable isolation framework or mocking tool. Such tools exist for just about every modern programming language (for Java, C#, Ruby, and Python, at least). They can isolate a class being tested from the implementation of other classes/types, even when the tested class directly instantiates its dependencies.


问:
How do Text User Interfaces (TUI) work?
I have recently been assigned to port an old COBOL program. I am used to GUIs, and I can't understand how a TUI works. I searched a lot through Google but couldn't find something.

I knew that console applications could output line by line, but how are colors etc. drawn to the terminal screen? How all this stuff is being drawn?
Do terminals support it somehow? Is there a standard? I am really confused.

答: The generic term for that sort of interface is "command line". You'll probably do better googling for that than for "text user interface".</p>

Title: How do Text User Interfaces (TUI) work?


问:
Does following TDD inevitably lead to DI?
I learned to do Test Driven Development (TDD), Dependency Injection (DI) and Inversion of Control (IoC) all at the same time. When I write code using TDD I always end up using DI in my class's constructors. I am wondering if this is because of how I learned to do TDD, or if this is a natural side-effect of TDD.

So my question is this: Does following TDD principals and writing unit tests that do not depend on external services inevitably lead to DI?

答:
As already pointed out in other answers, TDD does not require unit tests. You can just as well write integration/functional tests while doing TDD. Of the several ways to apply TDD,  creation of unit tests would be the "fake it till you make it" way (see the book by Kent Beck for details).

As for "TDD inevitably leads to DI", it definitely does not. What one needs when writing unit tests is to isolate the unit being tested from the implementations of its external dependencies. And this can be done just as easily with or without DI. The best way, probably, is to use a proper isolation/mocking tool.


问:
Techniques to avoid entangling git merges when working on an extensive change
I am absolutely miserable when I get in a situation where I have to merge other developers' changes into mine.  When using git and working on a really extensive change, that happens a lot.

When I start working on a change, I make a new local branch and start working in it.  The intent is to push my changes to the remote from it once I am done.  The concept seems wonderful if it weren't for one pesky complication:  other people are making changes to the same files as you are in the meantime.

I am looking for a set of techniques and policies to minimize my exposure to having to reconcile my changes with those of other people who have pushed their change to the same file after I pulled it from the remote, since there is no such thing as locking in git.

For example, will pulling from remote into my local branch on a daily basis reduce this exposure overall?  Are there other tricks and techniques?  Also, if you have a set of git commands that you run to sync up regularly, please share.  I am literally in a situation where I spend more time syncing my changes to other people's than writing code -- and I think this is not an efficient model.  It is either that I am doing something wrong or we are doing something wrong as a team.  I am miserable because of it and it seriously affects my quality of life.

I understand and acknowledge the benefits of git and I love being able to switch branches so easily.  But I feel that the exposure it leaves to merging is an elephant in the room many in the community refuse to or are kindof dogmatically discouraged to discuss.

答:
The model isn't too bad and in most cases is not really avoidable.

Few suggestions:

Do you coordinate any work with other developers?  We use Git at work and generally people modify what they need to where they need to but sometimes, if someone says, hey I'm in this area doing so and so.  Other developers might hold off working on tickets that touch the same thing.

If I'm working on a large feature that requires a long-lived feature branch.  I do not merge in on daily basis but definitely frequently.  As you pointed out, doing several smaller merges does reduce the surprise factor of OMFG this looks completely different.

Use graphical tools.  I'm aware that some people still run "git merge", gut a bunch of text files and then manually reconcile them.  That sounds absolutely aweful and I would never wish that on anyone.  In my previous job, we used Perforce, and when I joined my current team where we use git, the first time I had to do a 3-way merge, I went online and found this blog post.  P4merge definitely makes the process of reconciliation so much easier.

Another thing you could consider is breaking your large task into smaller ones.  Especially if you need to make refactoring or architecture changes.  If you rearrange stuff first, make sure it works and push that to common develop branch, you'll get much less surprises if the rest of your work is in few specific areas of the product.

To build a bit on previous point, this might also depend on how well your software is designed. Having a modular approach and keeping Open-Close Principle in mind when writing code will definitely help to keep developers from stepping on each others toes too much. However, if you have many monolithic classes that often have to be modified any time you fix a bug or add a feature, that will contribute to your frustration levels. In that case, fixing design is a much bigger question than just git workflow.


答:
In general, the more often you'll merge your changes, the fewer conflicts you'll have in total and thus the less total time will be spent on the merges.

Of course there will be no conflicts when merging independent parts of code. And that does not necessarily say anything about files. If a file contains two functions, one person changes one of them and another changes the other, the automatic merge will resolve it fine in a split second.

So you should:

Work on improving general design of the code. The more modular the code is, the easier it is to work on different parts of it without interfering with each other.

Coordinate tasks in the team so that tasks that need to touch the same part of the code are not done at the same time. This will of course be made easier by keeping the code modular.

Split the tasks to smaller chunks that can be pushed to main development branch (develop or next or whatever you call it). Again keeping the code well modularized will allow you to do localized refactoring in preparation for some feature that does not break anything else and can be pushed to everybody.

If you need to modify the same part of the code at the same time and can't make the tasks small, merge between the people working on it during the work, so the later changes are done with the earlier work of the other colleagues already included and don't need merging. Of course you have to merge at points where the code is not broken to the point that the others could not test their parts (but during any larger task you need intermediate points where the code works enough for testing partial changes anyway).

If you can live with all the tasks to only be delivered when all are done, just set up a shared develop branch and push your partial changes there and keep up to date with it.

If you know which feature has to be delivered first, you can keep merging one way from the feature branch of the feature to be done earlier to the one for later. So the first feature can still be delivered immediately when finished while the later saves some merge trouble by merging early.

If you need to keep the features separate, you can still get some help by periodically merging all of them together, resolving any conflicts, recording the resolutions with git rerere(1) and discarding the merge result again. The next merge attempt will only show any new conflicts and when some of the features are finally integrated, the resolutions can again be reused to bring the remaining feature branches up to date.

It should be noted that you would have the same problems in any other version control system, because the funamental working of a 3-way merge is always the same. Git will at least let you easily back off and retry if you make any mistake using the powerful git reflog(1). And the git rerere(1) also helps now and then.

Title: Techniques to avoid entangling git merges when working on an extensive change

Body:
I am absolutely miserable when I get in a situation where I have to merge other developers' changes into mine.  When using git and working on a really extensive change, that happens a lot.

When I start working on a change, I make a new local branch and start working in it.  The intent is to push my changes to the remote from it once I am done.  The concept seems wonderful if it weren't for one pesky complication:  other people are making changes to the same files as you are in the meantime.

I am looking for a set of techniques and policies to minimize my exposure to having to reconcile my changes with those of other people who have pushed their change to the same file after I pulled it from the remote, since there is no such thing as locking in git.

For example, will pulling from remote into my local branch on a daily basis reduce this exposure overall?  Are there other tricks and techniques?  Also, if you have a set of git commands that you run to sync up regularly, please share.  I am literally in a situation where I spend more time syncing my changes to other people's than writing code -- and I think this is not an efficient model.  It is either that I am doing something wrong or we are doing something wrong as a team.  I am miserable because of it and it seriously affects my quality of life.

I understand and acknowledge the benefits of git and I love being able to switch branches so easily.  But I feel that the exposure it leaves to merging is an elephant in the room many in the community refuse to or are kindof dogmatically discouraged to discuss.


问:
Why does Apple only allow for Static Frameworks on iOS?
Clearly Apple has the ability to create dynamically loaded libraries (known as frameworks) for iOS, as they ship several with XCode (such as UIKit). App developers only have the ability to create static libraries, or at best, trick Xcode into thinking it's loading a framework when it's actually loading a static library, this is known as creating a fake framework, some of the drag-and-drop convenience, but none of the dynamic loading benefits.

What is Apple's reasoning for keeping dynamic frameworks from app developers? It seems like it would ease using external libraries considerably, since developers wouldn't have to rely on finicky linker flags or open-source library dependency chains.

I see a common reason is security. Why then does Apple allow it on OSX and not iOS? Isn't security a requirement there as well?

EDIT: This is no longer relevant as of iOS 8. Apple has added support for dynamic frameworks.

答:
The reason is security as mentioned in this Stack Overflow question:

The reason is security: since a dynamic library can be loaded and
  unloaded at runtime you could download additional executable code and
  load it (think plug-in). This could get compromised by a hacker and
  then having malicious code executing on your phone is a very bad
  thing. It would also make it possible to add unapproved features to an
  approved app. In short: in this environment, Apple considers dynamic
  linking to be a Pandoras box that must be strictly controlled,
  otherwise it could compromise security and I agree that it does make
  sense on the phone.


答:
One of Apple's criteria for accepting a program is whether or not it makes calls to unsupported Apple API's (or other bad stuff).  By requiring static linking, they can prove that the software does not make such calls.   Allowing dynamic linking would allow any kind of behavior to be added later, which pretty much invalidates their approval process.

Apple allows dynamic linking in OSX because, well, Macintoshes are real computers, not tablet devices, and the users of real computers expect them to be programmable in this fashion.  The market for tablets and phones is quite different from that of desktop and laptop computers.  Computers are production devices; users expect to be able to produce products on them, including writing programs that do what they want, how they want.  This was never the expectation of tablet devices, which are consumption devices.

The whole point of tablets and the Apple Store was to create a closed environment to protect consumers from pedestrian viruses, and the like  (well, and to allow Apple to collect 30% of all software sales made through their store).

Title: Why does Apple only allow for Static Frameworks on iOS?

Body:
Clearly Apple has the ability to create dynamically loaded libraries (known as frameworks) for iOS, as they ship several with XCode (such as UIKit). App developers only have the ability to create static libraries, or at best, trick Xcode into thinking it's loading a framework when it's actually loading a static library, this is known as creating a fake framework, some of the drag-and-drop convenience, but none of the dynamic loading benefits.

What is Apple's reasoning for keeping dynamic frameworks from app developers? It seems like it would ease using external libraries considerably, since developers wouldn't have to rely on finicky linker flags or open-source library dependency chains.

I see a common reason is security. Why then does Apple allow it on OSX and not iOS? Isn't security a requirement there as well?

EDIT: This is no longer relevant as of iOS 8. Apple has added support for dynamic frameworks.


问:
On which abstraction level would you do TDD?
Problem

I find myself nailing the class structure down by having too many unit tests which makes making changes hard.

Example

Assume we have a class A which uses classes B1 and B2.
Class B1 uses classes C1 and C2.

I start off by writing tests first for class A. During that process, classes B1 and B2 are created. To make sure that classes B1 and B2 work, I start writing tests for B1 and B2. Same for C1 and C2.

Now, I end up having unit tests for all the different levels off abstraction. Assuming class A was for example a payroll system and classes B1, B2, C1 and C2 came to existence while building A.

Question

Where did I go wrong in my process? Shouldn't I have written tests for levels B and C? Should my unit tests in level A cover all the functionality in levels B and C?

What is the process which will lead to the "correct" unit tests and a flexible design?

Perhaps you can make an example with two or more levels of abstraction and show me your process and the code (including unit tests and production code and design) that comes out of your process.

答:
You didn't go wrong.

TDD involves Unit Testing; that is, it tests methods.  You have methods at all three levels of your project, not just level A.

Writing tests at level A to test functionality through levels B and C isn't TDD; it's integration testing.  You're still going to want to do this, but it doesn't have anything to do with your unit tests.

You test your individual methods at various levels of the project by decoupling them from the other layers.  This can be done by using mocks or stubs.

Worth noting

It is a common misconception that practicing TDD will automatically "grow" an architectural design for your program.  It won't.  You still have to create an architecture for your program yourself.  What TDD will do is force you to write code that is testable, which will assist you in creating a sensible and robust architecture.


答:
Establish coding standards for your team

It may seem trivial, but I learned to love DVCS (Git, Mercurial) the day our team decided to set coding standards, which were then tuned in our IDEs.

For instance, if you code like this:

```<code>// tabs indents

if($you+$me==$wow) {
    $answer='It\'s gonna be great';
    return $answer;
}
</code>```

Whereas you colleague codes like that:

```<code>// spaces indents

if ($me + $you = $hey)
{
    $answer = "Let\'s talk a bit, won't you?";
    return $answer;
}
</code>```

You're undergoing a LOT of merging problems. So if that's not the case yet, take the time to establish coding standards in your team, and customize your IDEs accordingly to automatize everything.

Another advantage of coding standards

A little off-topic (that's why it's separated from the rest) but useful.

If your team's manager manages your team well, your team probably organizes frequent collaborative code reviews. For example, friday afternoon is code review time.

Establishing coding standards ensures that nobody is pecking anybody else's way of coding, or is having trouble understanding a snippet because of a coding style he is not used to. So, you can rest assured that the code review time will be fully used to discuss real programming matters, not punctuations matters.

Body:
Establish coding standards for your team

It may seem trivial, but I learned to love DVCS (Git, Mercurial) the day our team decided to set coding standards, which were then tuned in our IDEs.

For instance, if you code like this:

// tabs indents

if($you+$me==$wow) {
    $answer='It\'s gonna be great';
    return $answer;
}

Whereas you colleague codes like that:

// spaces indents

if ($me + $you = $hey)
{
    $answer = "Let\'s talk a bit, won't you?";
    return $answer;
}

You're undergoing a LOT of merging problems. So if that's not the case yet, take the time to establish coding standards in your team, and customize your IDEs accordingly to automatize everything.

Another advantage of coding standards

A little off-topic (that's why it's separated from the rest) but useful.

If your team's manager manages your team well, your team probably organizes frequent collaborative code reviews. For example, friday afternoon is code review time.

Establishing coding standards ensures that nobody is pecking anybody else's way of coding, or is having trouble understanding a snippet because of a coding style he is not used to. So, you can rest assured that the code review time will be fully used to discuss real programming matters, not punctuations matters.


问:
Are optional parameters helpful or a hindrance to application maintenance?
As stated in the title, are optional parameters, such as those used in C# helpful or are they a hindrance to application maintenance and should be avoided as they can make the code harder to understand?</p>

答: It depends on what your code is doing. If there are sensible defaults then you should use optional parameters but if there are no sensible defaults then adding optional parameters will make your code more complicated. In many instances optional parameters are a neat way of sidestepping nil checks and cutting out branching logic. Javascript doesn't have optional parameters but there is a way to emulate them with || (logical or) and I use it all the time when doing database related stuff because if the user doesn't provide some value then I substitute my own values with the help of || which saves me the trouble of writing a whole bunch of if then statements.</p>


问:
Getting List of objects of same class
I have a class 'Task' which represents any Task that is done by an individual employee. For this class I wrote properties like EmpID, Priority, etc. and methods like AddNewTask(), ArchiveTask(), MoveTaskToUser(int userid), etc.
Then I wrote a method

```<code>public List<Task> GetAllTasks()
</code>```

This seemed incorrect to me with regard to OOP. I thought any single task object should represent one single task and it doesnt seem right to call taskObj.GetAllTasks() because object taskObj should carry out methods on the single Task that it represents.
So I changed the method to static:

```<code>public static List<Task> GetAllTasks()
</code>```

Now I call Task.GetAllTasks(). Is this the proper way to follow object oriented approach. Was the earlier idea of calling the method from single object correct?

答:
The static approach is a good start. You could also just write up a class that manages all tasks. You could then go like:</p>

```<code>TaskManager.addTask(/*whatever params are necessary*/);
TaskManager.getTask(/*whatever identifier you desire*/);
TaskManager.getTasksOfEmployer(/*employer-id*/);
TaskManager.getAllTasks();
TaskManager.updateTask();
etc...
</code>```

Title: Getting List of objects of same class

Body:
The static approach is a good start. You could also just write up a class that manages all tasks. You could then go like:

TaskManager.addTask(/*whatever params are necessary*/);
TaskManager.getTask(/*whatever identifier you desire*/);
TaskManager.getTasksOfEmployer(/*employer-id*/);
TaskManager.getAllTasks();
TaskManager.updateTask();
etc...


问:
Is the result of strcmp the same on all machines and compilers?
Code:

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

int main()
{
    int n = strcmp("hello","help");
    printf("%d\n", n ) ;
    return 0;
}
</code>```

Result:

```<code>-1
</code>```

Does the value for this program have to be the same on all machines or different compilers?

In other words can this return value take on different values for the same program when run on different compilers or different machines?

答:
No, only its sign is specified.

C99 §7.21.4.2 The strcmp function

Synopsis:

```<code>#include <string.h>
int strcmp(const char *s1, const char *s2);
</code>```

Description:

The strcmp function compares the string pointed to by s1 to the string pointed to by s2.

The strcmp function returns an integer greater than, equal to, or less than zero,
accordingly as the string pointed to by s1 is greater than, equal to, or less than the string pointed to by s2.

Body:
No, only its sign is specified.

C99 §7.21.4.2 The strcmp function

Synopsis:

#include <string.h>
int strcmp(const char *s1, const char *s2);

Description:

The strcmp function compares the string pointed to by s1 to the string pointed to by s2.

The strcmp function returns an integer greater than, equal to, or less than zero,
accordingly as the string pointed to by s1 is greater than, equal to, or less than the string pointed to by s2.


答:
Interestingly just recently Justin Searls wrote a blog post covering this topic. He identified 6 causes that might generate the pain you are experimenting using TDD and suggest a different approach to do learn TDD.

I think it can relate to what you are describing in your workflow.

Here's a summary of the 6 different failures Justin identified when applying TDD.

Failure #1: Encouraging Large Units

Failure #2: Encouraging Costly Extract Refactors

Failure #3: Characterization Tests of Greenfield Code

Failure #4: Redundant test coverage

Failure #5: Eliminating Redundancy Sacrifices Regression Value

Failure #6: Making a Mess with Mocks

In reaction to this post, Uncle Bob destroys it all. (with an exception regarding the up front Architecture/Design).

Basically Uncle Bob reminds us of the core principles behind TDD. And this is where I think you will find your answer.

Code your test first. (test fails (red))

Code the logic (test is green)

Refactor to make your code readable and maintainable.

Uncle Bob says:

... the Author argues that the new smaller units need new unit tests. That's news to me. I certainly don't rewrite my tests just because I extracted some functions or classes.

TDD is the practice to Test First. It doesn't require one class to have its associated unit test. As long as you are testing first. Make sure the intention of  your tests are very clear and specific. It'll help you refactor properly your code (once the test are green), identifying properly the different responsibilities and interfaces you need to extract.

I also make sure my tests are readable as they might be read as a form of documentation specifying the intention behind the code. Sometimes that implies I have to refactor them and I may end up with unit tests for my different classes, or may not entirely.

Uncle Bob finishes his article with some good architecture material. He explains when to do up front design and when not to do it. Basically, you do it when you know there will be a separation of concern. Here's what he says about it:

... So our up front decisions can be limited to choosing a user experience, and choosing the architectural pattern that is most consistent with that user experience. Once those choices are made, we can TDD the problem domain into existence.

I hope you'll find those two blog posts useful. I certainly enjoyed reading them.

Title: On which abstraction level would you do TDD?

Body:
Problem

I find myself nailing the class structure down by having too many unit tests which makes making changes hard.

Example

Assume we have a class A which uses classes B1 and B2.
Class B1 uses classes C1 and C2.

I start off by writing tests first for class A. During that process, classes B1 and B2 are created. To make sure that classes B1 and B2 work, I start writing tests for B1 and B2. Same for C1 and C2.

Now, I end up having unit tests for all the different levels off abstraction. Assuming class A was for example a payroll system and classes B1, B2, C1 and C2 came to existence while building A.

Question

Where did I go wrong in my process? Shouldn't I have written tests for levels B and C? Should my unit tests in level A cover all the functionality in levels B and C?

What is the process which will lead to the "correct" unit tests and a flexible design?

Perhaps you can make an example with two or more levels of abstraction and show me your process and the code (including unit tests and production code and design) that comes out of your process.

ContentLicense: CC BY-SA 4.0


答:
it allows for early feedback, not just from customers

it keeps management from getting nervous (they can 'see' the progress)

it keeps the dev. team into a good habit

And most important (at least in my opinion)

it makes you challenge your initial concept of a minimal viable product

it gives you the flexibility to redefine your minimal viable product


问:
Criteria for prioritizing product backlog
My list of the most important criteria is below. What do you think?

The value to the user - naturally features that are more important to the user must come first

Implementation time - the faster it is to implement a feature, the higher it should be on the list

Dependency between features - obviously you can't make a "roof" feature without developing the "walls" feature first.

Risk reduction - If a certain feature is very important for the project but we are not sure if we can actually develop it (because of either technological limitations or because we don't know how users will react to it), it climbs up on the list.

答:
You are mixing two things here : priority for business and technical priority. And both things are handled by different people. Business priority should be chosen by customer/product owner. This is how the whole backlog should be ordered. No technical things are taken into account by this list. Developers then pick from this list based on technical priority. The key point is that they don't have to pick top 10 items, but they can cherry-pick items they know they can implement in the sprint, but that still have high priority.

The problem of mixing both into single list is that the business value gets blurred. For example, some story might have huge business value, but might take long to implement. In your case, it would drop down even though it is really important thanks to mixing the implementation time into it. Similar if this story depends on other stories, that might have lower priority. If developers don't pick it outright, the fact that it is still on top of list reminds them that they should focus on implementing it in next iterations. On the other side, they might pick low-priority story simply because it is short and no other story would fit into remainder of the iteration.


问:
Do I need to understand pointers to use C++?
Well, I love C++, I have been using it for a while: I like all the libraries (Allegro, SDL, QT, Ogre, etc.), but I have a problem: I don't understand pointers.

Do I really need them ? I just program for fun: but I want to study it some day.
Thanks.

答:
Pointers is one of the great features that c/C++ provides. You can write the programs in C++ without knowing and without understanding the concept of pointers to some extent.

But You can write the program in better way by knowing them. Also in some cases it is very essential. So, it is always good idea to learn and understand the concept of pointers.


问:
scoping concern when dealing with coupling
I'm learning ruby (and OOP in the process) and I find keep having to write the same patterns when logging progress so I want to wrap this up in a logging library that my other code can then just pass data to - say a string, a file name and a log level. This of course couples the logging library with other code - other code still has to be aware of how the logging library works (that it wants the string, name, & level). I tend not to like coupling like this but it seems like I can't really prevent it, but rather have to deal with it by consciously deciding to scope the library's use to an area of concern "ie: snoweagle's personal tech projects"

Is this good design or is there a better way to approach coupling?

答:
I don't think what you're describing is necessarily tightly coupled

This of course couples the logging library with other code - other code still has to be aware of how the logging library works (that it wants the string, name, & level)

Not exactly.  The consuming code won't need to know how the logging library works.  It'll simply need to know what is expected of a logging library.  In other words, consuming code only needs to know about the logging library's public interface.

If your language supports it, you can guarantee looser coupling by forcing the consuming code to work against a Logger Interface (as opposed to the Logger implementation).

This is considered loosely coupled because there is only one --clearly defined-- point of contact between the Logger library and the consuming code.  This is the Logger Interface.

If in the future you decided to swap out your Logger for a new-fangled modern logger, then all you would need to do is code a compatibility layer between your new Logger lib and your existing Logger Interface.  Loose coupling to the max ;)

In C#:

Your logger interface:

```<code>public interface ILogger
{
    void Log(String filename, String message, Level level);
    void Log(String filename, Exception exception, Level level);
    void Log(String message, Level level);
    void Log(Exception exception, Level level);
    void LogInfo(String message);
    void LogWarning(String message);
    void LogError(String error);
    void LogError(Exception error);
    // etc...
}
</code>```

A specific implementation of ILogger

```<code>public class AbcLogger : ILogger
{
    // Implements all of ILogger

    public void LogWarning(String message)
    {
        this.abcTarget.Write(message, AbcLevelsEnum.Warning)
    }
}
</code>```

Code consuming a Logger

```<code>public void SomeMethod(int a)
{
    if (a < 1000)
    {
        String message = "Quantities of fewer than 1000 bananas are not accepted";

        ILogger logger = ServiceLocator.GetMeMyLogger();
        logger.LogWarning(message);

        throw new BananaException(message);
    }

    // do more...
}
</code>```

As you can see, the consuming code isn't aware it's dealing with AbcLogger.  All it knows is that a logger is available and that it can be used by going throw the ILogger interface.

And this way, if you ever want to switch to another logger like this one...

```<code>public class XyzLogger : ILogger
{
    // Implements all of ILogger

    public void LogWarning(String message)
    {
        this.xyzTarget.Flush();
        this.xyzTarget.OtherPreRequisites();

        this.xyzTarget.Write(message, XyzLevel.NonCritical)

        this.xyzTarget.Flush();
        this.xyzTarget.OtherPostRequisites();
    }
}
</code>```

...it's just a matter of changing your application's bootstrapping code to use XyzLogger instead of AbcLogger.

```<code>public Bootstrapping()
{
    ServiceLocator.SetLogger(new XyzLogger());
    ServiceLocator.SetBananaManager(new BananaManaga());
    // ... etc
}
</code>```

Body:
I don't think what you're describing is necessarily tightly coupled

This of course couples the logging library with other code - other code still has to be aware of how the logging library works (that it wants the string, name, & level)

Not exactly.  The consuming code won't need to know how the logging library works.  It'll simply need to know what is expected of a logging library.  In other words, consuming code only needs to know about the logging library's public interface.

If your language supports it, you can guarantee looser coupling by forcing the consuming code to work against a Logger Interface (as opposed to the Logger implementation).

This is considered loosely coupled because there is only one --clearly defined-- point of contact between the Logger library and the consuming code.  This is the Logger Interface.

If in the future you decided to swap out your Logger for a new-fangled modern logger, then all you would need to do is code a compatibility layer between your new Logger lib and your existing Logger Interface.  Loose coupling to the max ;)

In C#:

Your logger interface:

public interface ILogger
{
    void Log(String filename, String message, Level level);
    void Log(String filename, Exception exception, Level level);
    void Log(String message, Level level);
    void Log(Exception exception, Level level);
    void LogInfo(String message);
    void LogWarning(String message);
    void LogError(String error);
    void LogError(Exception error);
    // etc...
}

A specific implementation of ILogger

public class AbcLogger : ILogger
{
    // Implements all of ILogger

    public void LogWarning(String message)
    {
        this.abcTarget.Write(message, AbcLevelsEnum.Warning)
    }
}

Code consuming a Logger

public void SomeMethod(int a)
{
    if (a < 1000)
    {
        String message = "Quantities of fewer than 1000 bananas are not accepted";

        ILogger logger = ServiceLocator.GetMeMyLogger();
        logger.LogWarning(message);

        throw new BananaException(message);
    }

    // do more...
}

As you can see, the consuming code isn't aware it's dealing with AbcLogger.  All it knows is that a logger is available and that it can be used by going throw the ILogger interface.

And this way, if you ever want to switch to another logger like this one...

public class XyzLogger : ILogger
{
    // Implements all of ILogger

    public void LogWarning(String message)
    {
        this.xyzTarget.Flush();
        this.xyzTarget.OtherPreRequisites();

        this.xyzTarget.Write(message, XyzLevel.NonCritical)

        this.xyzTarget.Flush();
        this.xyzTarget.OtherPostRequisites();
    }
}

...it's just a matter of changing your application's bootstrapping code to use XyzLogger instead of AbcLogger.

public Bootstrapping()
{
    ServiceLocator.SetLogger(new XyzLogger());
    ServiceLocator.SetBananaManager(new BananaManaga());
    // ... etc
}


答:
Whether you are using git or anything else, if people are making incompatible changes to the codebase in parallel, merging your work will always be painful. This has nothing to do with the git model in particular.

If you find merging is too painful, likely something is wrong with the way you and the other developers are coordinating your efforts.

For example, refactorings which touch a lot of lines in a lot of different files (such as renaming heavily used functions/classes/etc) should not be done as others are working. When you want to make broad changes like that, communicate with the other developers, agree on what will be changed, sync up with everybody, make the change, then sync up again.

The same is true if you want to redesign some part of the code, pulling it all apart and then putting it together in a different way, or possibly rewriting it from scratch. Working independently in parallel, and then merging afterwards, is an unworkable model in that case. The solution is to agree that someone is going to overhaul certain files/classes/modules/etc, sync up, make the changes, then sync up again. After that, you can continue working in parallel.

Although git and other distributed VC tools allow any dev to work on any part of the code at any time, that doesn't mean you should actually do so. There are times when you need to use some discipline, times when you need to communicate more with the other devs and coordinate your efforts. Yes, that coordination has overhead. Yes, it will slow you down sometimes. That's an unavoidable consequence of working as a team rather than an individual. Of course, if you can divide up the work in a way which eliminates the need for fine-grained coordination, that overhead will be much less.


问:
Is masking really necessary when sending from Websocket client
The current Websocket RFC requires that websocket clients mask all data within frames when sending (but server is not required to). The reason the protocol was designed this way is to prevent frame data from being altered by malicious services between the client and server (proxies, etc). However, the masking key is still known to such services (it is sent on a per frame basis at the beginning of each frame)

Am I wrong to assume that such services can still use the key to unmask, alter, and than re-mask the contents before passing the frame to the next point? If I'm not wrong, how does this fix the supposed vulnerability?

答:
Section 10.3 of the RFC explains exactly why masking is required.  It's a very specific response to a specific hacking technique.  The problem it is trying to address is described in a 2010 paper called Talking to Yourself for Fun and Profit by some of the sharpest Internet transport security folks.

Client-to-Server masking is used by the Websocket protocol to prevent proxies from unwittingly treating WebSockets data as a cacheable HTTP request. You can argue whether that's pandering to stupid proxies (and I think it is), but that's the reason.


答:
I have done something similar in the past and I used a TaskList type of object which contained the list of Task objects and manages the addition, removal and retrieval of each of the Tasks. Each Task implemented an ITask interface which had a Name property which was used to retrieve a task.

```<code>public interface ITask
{
    string Name { get;set; }
    void Execute();
}
</code>```

Each task would implement this interface and as such the class that manages the Tasks does not need to know about any particular, it just knows it can call the Execute method and a Task will carry out its action.

```<code>public class TaskList
{
    private List<ITask> _taskList = new List<ITask>();
    public void Add(ITask task)
    {
        //Check for null / duplicate task
        _taskList.Add(task);
    }

    public void GetTask(string name)
    {
        foreach(var task in _taskList)
        {
            if(task.Name.Equals(name))
                return task;
        }
        throw new ArgumentOutOfRangeException();
    }

    public void Remove(ITask task)
    {
        if(_taskList.Contains(task))
            _taskList.Remove(task);
    }
}
</code>```

Hope this helps a bit.

Title: Getting List of objects of same class

Body:
I have a class 'Task' which represents any Task that is done by an individual employee. For this class I wrote properties like EmpID, Priority, etc. and methods like AddNewTask(), ArchiveTask(), MoveTaskToUser(int userid), etc.
Then I wrote a method

```<code>public List<Task> GetAllTasks()
</code>```

This seemed incorrect to me with regard to OOP. I thought any single task object should represent one single task and it doesnt seem right to call taskObj.GetAllTasks() because object taskObj should carry out methods on the single Task that it represents.
So I changed the method to static:

```<code>public static List<Task> GetAllTasks()
</code>```

Now I call Task.GetAllTasks(). Is this the proper way to follow object oriented approach. Was the earlier idea of calling the method from single object correct?

Body:
I have done something similar in the past and I used a TaskList type of object which contained the list of Task objects and manages the addition, removal and retrieval of each of the Tasks. Each Task implemented an ITask interface which had a Name property which was used to retrieve a task.

public interface ITask
{
    string Name { get;set; }
    void Execute();
}

Each task would implement this interface and as such the class that manages the Tasks does not need to know about any particular, it just knows it can call the Execute method and a Task will carry out its action.

public class TaskList
{
    private List<ITask> _taskList = new List<ITask>();
    public void Add(ITask task)
    {
        //Check for null / duplicate task
        _taskList.Add(task);
    }

    public void GetTask(string name)
    {
        foreach(var task in _taskList)
        {
            if(task.Name.Equals(name))
                return task;
        }
        throw new ArgumentOutOfRangeException();
    }

    public void Remove(ITask task)
    {
        if(_taskList.Contains(task))
            _taskList.Remove(task);
    }
}

Hope this helps a bit.


问:
Why Perl is appropriate language for CGI?
I heard many people around still saying Perl is great language for CGI. But i think it is not as much as popular as now growing languages such as Python, Ruby.

Is there any solid reason for Perl still being the appropriate language for CGI.

答:
Perl is not a great language for CGI. Or rather, CGI isn't great.

The Perl language was designed by Larry Wall to make his sysadmin tasks easier. It is interpreted, highly portable, has deep Unix integration, and unparalleled text handling facilities (especially when compared with C). When the Web came around, Perl was at the right place at the right time, and became popular as an easy to learn language which was available on virtually any server. This allowed people to easily cobble together simple forms or other kinds of dynamic content. Originally, many people used cgi-lib.pl to abstract over the CGI protocol, later CGI.pm was used.

Today, Perl isn't used very much in this area, as other languages like PHP have taken over this specific niche. While Perl is a general-purpose programming language that was used for the Web, PHP was specifically built for creating websites via CGI.

While Perl still is a great language, CGI has become unpopular: This protocol requires a new interpreter to be started for each request, which is too slow for anything but low-traffic websites. The FastCGI protocol is better in this regard as one interpreter instance handles multiple requests. Certain servers like Apache have tried to reduce overhead by integrating the languages deeper into the server, via plugins like mod_perl or mod_php. They have a ton of issues themselves.

Today, most programming languages define a specific server interface, e.g. Perl has PSGI, Python has WSGI. This interface defines how a server can pass on requests to a web application and allows a variety of efficient or backwards-compatible middlewares.

Web programming today has been irreversibly shaped (no, improved) by the innovative Ruby web frameworks Ruby on Rails and Sinatra. Since then many projects have scrambled to bring this ease of creating webapps to other languages. In Perl, these projects are

Dancer (basically just a simple way to map routes to templates)

Mojolicious (a very complete, low-dependency web framework)

There's also the older Catalyst framework, but it's far more complex.

As these frameworks are built on PSGI, they can be deployed via CGI or via any other interface where appropriate middleware exists (there are also a few specialized PSGI servers).

Perl isn't the only language that has such awesome stuff: Ruby was already mentioned, and Python has a few nice frameworks of it's own, the most well-known being Django. While PHP is very much invested in being usable via mod_php without much further ceremony, it too has a number of modern frameworks. Actually, any language that has been used in the past twenty years has some kind of web framework, and Wikipedia has a nice list of them.


问:
Should unit-tests be entirely self-contained?
As the title suggests my question is whether or not
unit-tests should be entirely self-contained or can
one rely on the results yielded by previous tests?

What I mean, in case that it isn't entirely clear,
is that if ones initial test sufficiently asserts
that a certain module A works in a certain way can,
or more appropriately, should one write subsequent
tests with the assumption that the aforementioned
module A is tested beforehand? This would imply that
the order that the unit-tests are executed matters.

Or should each individual test be self-reliant
to the point that if one needs to know whether a
module B works, which can only be validated
if module A works, should one then test module A
within the same test as module B which
would imply that the separate unit-tests can be
executed in any order.

To give a concrete example, consider the "stack" datatype, which we won't delve too deeply into, specifically two fundamental properties we'd need to be able to reason about the datatype in any meaningful sense. Namely, isEmpty(stack) and Empty(). Now, if one wishes to test the validity of isEmpty which takes a stack and returns a True or False depending on whether or not the stack received as an argument is empty or not one would first need to create an empty stack using Empty().

Then we consider the scenario of doing the following: isEmpty(Empty()) and checking what kind of result we get. Either we get a True statement, so Empty() could have returned a non empty stack and isEmpty might view that as an empty stack which would be wrong. Or we get False, and we still don't know how the two actually interplay, nor how either works on their own (assuming we can't view the source). (There is a third option, we receive something that's neither True nor False, but that is beyond the scope of this discussion, this is solely a remark).

Finally, to tie this back to my question, if we create a test where we can be reasonably certain that isEmpty works in a satisfying manner can then all tests executed after it trust that it does indeed work? Or should they all try and incorporate this ambiguity into their own test logic (for instance, including an else statement to if neither True nor False was returned)

答:
Each unit test should be testing one thing, so yes, they should assume that all other parts of the system is working. The way to do this reliably is to mock any other code which should not be tested at the same time.

For example, consider this pseudo-code:

```<code>house_json(id):
    name = get_house_name(id)
    return json.format({'id': id, 'name': name})
</code>```

This depends on the functionality of two other functions: get_house_name and json.format. To unit test this you'll have to mock both of them. First the normal case, testing that with a valid house ID we end up calling json.format with the expected parameters:

```<code>test_house_json_format():
    get_house_name = mock()
    json.format = mock()
    get_house_name.return_for(5) = 'foo'
    house_json(5)
    assert_called_once_with(json.format, {'id': 5, 'name': 'foo'})
</code>```

Then to test that if we send an invalid house ID, the formatter should throw an exception:

```<code>test_house_json_with_invalid_house_id():
    get_house_name = mock()
    json.format = mock()
    get_house_name.return(x) = lambda: raise InvalidHouseError(x)
    assert_raises(house_json, 5, InvalidHouseError)
    assert_not_called(json.format)
</code>```

Making expectations about the code explicit in your test code means it will be easy for others to understand its expected behaviour, and to change it when requirements change. For example, if the function should handle thrown errors and return an error code in JSON format instead, you'd change that in this test:

```<code>test_house_json_with_invalid_house_id():
    get_house_name, json.format = mock()
    get_house_name.return(x) = lambda: raise InvalidHouseError(x)
    house_json(5)
    assert_called_once_with(json.format, {'invalid_house_error': 5})
</code>```

Then you'd run the test to verify that it fails, fix get_house_name to make it pass again, and refactor to make it the simplest possible code which passes (red-green-refactoring).

Once you've tested all the parts, you should add integration and acceptance tests without mocking to ensure that they all work together.

Body:
Each unit test should be testing one thing, so yes, they should assume that all other parts of the system is working. The way to do this reliably is to mock any other code which should not be tested at the same time.

For example, consider this pseudo-code:

house_json(id):
    name = get_house_name(id)
    return json.format({'id': id, 'name': name})

This depends on the functionality of two other functions: get_house_name and json.format. To unit test this you'll have to mock both of them. First the normal case, testing that with a valid house ID we end up calling json.format with the expected parameters:

test_house_json_format():
    get_house_name = mock()
    json.format = mock()
    get_house_name.return_for(5) = 'foo'
    house_json(5)
    assert_called_once_with(json.format, {'id': 5, 'name': 'foo'})

Then to test that if we send an invalid house ID, the formatter should throw an exception:

test_house_json_with_invalid_house_id():
    get_house_name = mock()
    json.format = mock()
    get_house_name.return(x) = lambda: raise InvalidHouseError(x)
    assert_raises(house_json, 5, InvalidHouseError)
    assert_not_called(json.format)

Making expectations about the code explicit in your test code means it will be easy for others to understand its expected behaviour, and to change it when requirements change. For example, if the function should handle thrown errors and return an error code in JSON format instead, you'd change that in this test:

test_house_json_with_invalid_house_id():
    get_house_name, json.format = mock()
    get_house_name.return(x) = lambda: raise InvalidHouseError(x)
    house_json(5)
    assert_called_once_with(json.format, {'invalid_house_error': 5})

Then you'd run the test to verify that it fails, fix get_house_name to make it pass again, and refactor to make it the simplest possible code which passes (red-green-refactoring).

Once you've tested all the parts, you should add integration and acceptance tests without mocking to ensure that they all work together.


问:
Decision making process within a Scrum team
Two questions:

I assume that when Scrum coaches say "the team should decide" they mean there has to be a consensus decision process usually facilitated by the Scrum Master?

What if there is a disagreement between members of the Scrum team on the way to develop/design some feature and a consensus cannot be reached, who decides? The Scrum Master? The system architect? The funcional manager?

Thanks.

答:
You're right when you say:

It's a decision for the Scrum Team.
AND

If the Scrum Team cannot agree on an approach then the Scrum Master may well facilitate a process to help the team decide.

Thereafter, if a consensus cannot be reached, the Scrum Team have effectively decided not to decide. This is a dysfunction that the Scrum Team have to address.

The Scrum Master should never decide for the team (and there is no such thing as a System Architect or Functional Manager in Scrum).

The Scrum Team have to resolve the situation for themselves. As a Scrum Master, I might encourage them to try one approach for one Sprint, and the other approach for another Sprint, and then review at the Sprint Retrospective. Inspect, adapt and move forward.


答:
In Scrum, the ordering of items in the Product Backlog is the sole province of the Product Owner.

There are many different ways to achieve this. From the simple:

Use the business value and estimate that should be attached to each Product Backlog item. Calculate a simple Return on Investment (RoI) number by dividing business value by estimate. Higher value RoI is ordered higher in the Product Backlog.

To the more complex, where Product Owners create their own, bespoke algorithms.

There are other factors that a Product Owner might consider as well such as risk (do high risk items first) or technical advice from the Development Team.

But the fact remains that only the Product Owner establishes the order of items in the Product Backlog.

One other quick note: When writing Product Backlog items, a guiding principle is to keep the items independent. It's not always possible, but Scrum Teams strive hard to achieve this. Therefore, the notion of using dependencies to decide ordering is rarely needed or used.

Title: Criteria for prioritizing product backlog

Body:
My list of the most important criteria is below. What do you think?

The value to the user - naturally features that are more important to the user must come first

Implementation time - the faster it is to implement a feature, the higher it should be on the list

Dependency between features - obviously you can't make a "roof" feature without developing the "walls" feature first.

Risk reduction - If a certain feature is very important for the project but we are not sure if we can actually develop it (because of either technological limitations or because we don't know how users will react to it), it climbs up on the list.


答:
First, it is a very good practice to make sure your automatic tests are independend from the order of execution (for example, when one test fails, you want to run exactly that test in your debugger without having 10 other tests to be run before).

But you asked something different:

is that if ones initial test sufficiently asserts that a certain module A works in a certain way [], should one write subsequent tests with the assumption that the aforementioned module A is tested beforehand

Writing a test for a function X which relies on the correctness of function Y does not make your tests order-dependend. If your function X is wrong, your tests for Y may fail (as well as your tests for function Y), and if they fail, they fail always if you run the tests for function X ,or if you don't run them, it does not matter.

Title: Should unit-tests be entirely self-contained?

Body:
As the title suggests my question is whether or not
unit-tests should be entirely self-contained or can
one rely on the results yielded by previous tests?

What I mean, in case that it isn't entirely clear,
is that if ones initial test sufficiently asserts
that a certain module A works in a certain way can,
or more appropriately, should one write subsequent
tests with the assumption that the aforementioned
module A is tested beforehand? This would imply that
the order that the unit-tests are executed matters.

Or should each individual test be self-reliant
to the point that if one needs to know whether a
module B works, which can only be validated
if module A works, should one then test module A
within the same test as module B which
would imply that the separate unit-tests can be
executed in any order.

To give a concrete example, consider the "stack" datatype, which we won't delve too deeply into, specifically two fundamental properties we'd need to be able to reason about the datatype in any meaningful sense. Namely, isEmpty(stack) and Empty(). Now, if one wishes to test the validity of isEmpty which takes a stack and returns a True or False depending on whether or not the stack received as an argument is empty or not one would first need to create an empty stack using Empty().

Then we consider the scenario of doing the following: isEmpty(Empty()) and checking what kind of result we get. Either we get a True statement, so Empty() could have returned a non empty stack and isEmpty might view that as an empty stack which would be wrong. Or we get False, and we still don't know how the two actually interplay, nor how either works on their own (assuming we can't view the source). (There is a third option, we receive something that's neither True nor False, but that is beyond the scope of this discussion, this is solely a remark).

Finally, to tie this back to my question, if we create a test where we can be reasonably certain that isEmpty works in a satisfying manner can then all tests executed after it trust that it does indeed work? Or should they all try and incorporate this ambiguity into their own test logic (for instance, including an else statement to if neither True nor False was returned)


答:
I would argue that you emphatically should not make your individual tests be entirely self-contained. It is not typically useful to try to write tests on Module B which will work even if Module A is buggy. In fact, I think it is often dangerous and unwise to attempt to do so.

A strict unit test will mock out all of the other classes besides the one being tested. Thus the test will specify the inputs and outputs to all objects/modules other than the one being tested. I do not think there is great value in writing these strict unit tests. There are cases to mock out modules, but in general one should default to using the actual module.

Why?

1) By running the actual implementation of Module A while testing Module B, you get additional testing on Module A for free. Bugs which you didn't catch while testing Module A may come in Module B's use of it. You are throwing away valuable checks on the accuracy of Module A if you simply mock it.

2) Mocking out all of the external calls is obnoxious. You end up having to write lots of code in your test to specify the inputs and outputs of the various objects used. This is typically tedious and makes your tests harder to read and write.

3) If you mock out the calls to Module A from Module B, you are asserting that Module B made the calls you expected. You are not checking that these were the correct calls to make. For example, suppose you have a function like:

```<code>Foobar highestScoring() {
    // getFoobars() returns the Foobars sorted by score.
    return module_a.getFoobars().getFirst();
}
</code>```

It seems pretty sensible, but what order does module_a sort them by? If it sorts lowest to highest, then this function is wrong. But if you mocked module_a, you'd have missed this because you assumed that it sorted the other way around. This is a bug in Module A that would have missed in try to isolate it from Module B.

What are the advantages of mocking every module? There are certainly advantages to mocking certain modules. You typically want to mock modules which slow, rapidly changing, or would cause side effects. But what does the practice of a strict unit test which mocks everything get you? The theory is that if Module A is buggy, then the tests will point to Module A, and not everything that Module A depends on.

I don't think this is very helpful in practice. If you've actually broken Module A, it is typically because you've modified Module A. So you probably already know module A is broken, because that's why were modifying.

Actually, if we really wanted that benefit, unit testing platforms could add it by annotating or inferring a dependency between tests. So if Module A's test fail, we wouldn't even both running Module B's tests.

So in short, systematically mocking every module in your test requires a lot of work, creates places for bugs to hide, and gives you marginal benefits. Just don't do it.

Body:
I would argue that you emphatically should not make your individual tests be entirely self-contained. It is not typically useful to try to write tests on Module B which will work even if Module A is buggy. In fact, I think it is often dangerous and unwise to attempt to do so.

A strict unit test will mock out all of the other classes besides the one being tested. Thus the test will specify the inputs and outputs to all objects/modules other than the one being tested. I do not think there is great value in writing these strict unit tests. There are cases to mock out modules, but in general one should default to using the actual module.

Why?

1) By running the actual implementation of Module A while testing Module B, you get additional testing on Module A for free. Bugs which you didn't catch while testing Module A may come in Module B's use of it. You are throwing away valuable checks on the accuracy of Module A if you simply mock it.

2) Mocking out all of the external calls is obnoxious. You end up having to write lots of code in your test to specify the inputs and outputs of the various objects used. This is typically tedious and makes your tests harder to read and write.

3) If you mock out the calls to Module A from Module B, you are asserting that Module B made the calls you expected. You are not checking that these were the correct calls to make. For example, suppose you have a function like:

Foobar highestScoring() {
    // getFoobars() returns the Foobars sorted by score.
    return module_a.getFoobars().getFirst();
}

It seems pretty sensible, but what order does module_a sort them by? If it sorts lowest to highest, then this function is wrong. But if you mocked module_a, you'd have missed this because you assumed that it sorted the other way around. This is a bug in Module A that would have missed in try to isolate it from Module B.

What are the advantages of mocking every module? There are certainly advantages to mocking certain modules. You typically want to mock modules which slow, rapidly changing, or would cause side effects. But what does the practice of a strict unit test which mocks everything get you? The theory is that if Module A is buggy, then the tests will point to Module A, and not everything that Module A depends on.

I don't think this is very helpful in practice. If you've actually broken Module A, it is typically because you've modified Module A. So you probably already know module A is broken, because that's why were modifying.

Actually, if we really wanted that benefit, unit testing platforms could add it by annotating or inferring a dependency between tests. So if Module A's test fail, we wouldn't even both running Module B's tests.

So in short, systematically mocking every module in your test requires a lot of work, creates places for bugs to hide, and gives you marginal benefits. Just don't do it.


答:
Your question is exactly the reason I believe that just because you (try to) practice Scrum or other form of Agile, it doesn't mean that there shouldn't be a technical team lead (aka benevolent dictator) on the project.

In my past experience, we had a project, where management came down and simply stated "no more management. No hierarchy. The team is responsible. Go"  We had a number of strong voices (some of which came from guys with only 1 year of experience in project and language they were in) on a relatively large team and most meeting degenerated into arguments, some of which were for rather silly reasons.  (can you imaging a 1.5 hour discussion if unit test project naming convention should be test_[projectname] or [projectname]_test or....)

So in reviewing with management how that team structure just didn't work for us, my proposal is that some hierarchy is not a bad thing.  For the next project, he gave me the label of a design lead (with basically dictator-like powers) and in a 1.5 years that it took us to complete the next release, I think I had to exercise those powers only few times and only towards the beginning of the project.

My role as a design lead and one of the scrum members was to be part of the team. We still had discussions and I welcomed/encouraged input.  So in reality I only had to step in few times when a consensus couldn't be reached.  And I think because our meetings stayed productive and there was no yelling or arguing to the point where half the team just wants to leave, over time we as a whole got more aligned on the same page where the necessity for those dictator-like powers mostly went away.

The other thing that I think helped was to break up large development team into smaller teams of 3-5 people so that those strong voices would each have a chance to naturally lead without stepping over each other.

Title: Decision making process within a Scrum team

Body:
Two questions:

I assume that when Scrum coaches say "the team should decide" they mean there has to be a consensus decision process usually facilitated by the Scrum Master?

What if there is a disagreement between members of the Scrum team on the way to develop/design some feature and a consensus cannot be reached, who decides? The Scrum Master? The system architect? The funcional manager?

Thanks.