问:
What can qualify for potential tail call recursion (TCO) optimization or tail recursion elimination (TRE)
Short question is: what can qualify for potential tail call recursion optimization (TCO) or tail recursion elimination (TRE) if the compiler or interpreter supports it.

The summary of this question is in the section "Or is it true that, one simplest way to think about it" below.

I saw the Stack Overflow question "What is tail-recursion elimination?" as well, and read different descriptions of how a tail call recursion can happen.

First one:

a tail call is a subroutine call performed as the final action of a procedure (Wikipedia as of Jan 10, 2016)

Second one:

when the value returned by the recursive call is itself immediately returned (Programming Interview Exposed, Wiley, 2013)

Third one:

when a function calls itself, it cannot do any operation with this value that involves a local variable, and just return it. This call happens at the end of function, and so any local variables or "state" inside the stack (inside the current scope) can be thrown away

I think the second one is very close to the third one, except I didn't see exactly what it mean by "immediately".  The first one made me think if I return n * fact(n-1) then it qualifies, although later on in Wikipedia, it says n * fact(n - 1) is not tail recursive, because even though it calls itself on the last line, it uses n, so it doesn't qualify for TCO.

Interestingly, maybe the book Programming Interview Exposed 2013, Wiley, needs an errata, that it says

```<code>int factorial( int n ) {
    if (n > 1) {
        /* Recursive case */
        return factorial(n-1) * n;
    } else {
        /* Base case */
        return 1;
    }
}
</code>```

when the value returned by the recursive call is itself immediately returned, as in the preceding definition for factorial, the function is tail-recursive. Some compilers can perform tail call elimination on tail-recursive functions, an optimization that reuses the same stack frame for each recursive call

but I don't think it is tail recursive, is it?

Is calling on the last line important? On the page Tail Call Optimization in Ruby it says the following code can qualify for TCO:

```<code>def fact(n, acc=1)             # just assuming we pass in non-negative n
  return acc if n <= 1
  return fact(n-1, n*acc)
end
</code>```

But isn't it true that even the following qualify for TCO?

```<code>def fact(n, acc=1)
  return fact(n-1, n*acc) if n > 1
  return acc if n <= 1
end
</code>```

Or is it not, because it has "unfinished business" -- you need the stack to remember where the code has reached and continue later on, so you cannot wipe out the stack?

What if you do math operation, but it is like return 1 + fact(n-1)?  That is, you are adding a constant, 1 instead of touching any local variable, so there shouldn't be stack info that needs to be kept each time you recurs.  But if you view it as needing to remember 1 + (1 + (1 + (1 + ..., then in fact you still need more and more stack, unless if typical TCO can actually optimize it to 4 + fact(...) without needing new stacks.

Or is it true that, one simplest way to think about it is:

When you can wipe out the whole stack frame, because there is no need to keep any of those info in the current stack when you make the recursive call, then you can wipe the whole stack frame out and just use a "GO TO", instead of adding a new stack, then it can qualify for TCO?  Then, at least for this recursive call alone, there will be no stack overflow.

So because if you can wipe out the whole stack frame, that means, there is no local variables that is needed?

What if it is a recursive call to traverse a binary tree or rename all files under a directory and all its subdirectories, from the form "Programming_Ruby.pdf" to "Programming Ruby.pdf", and your recursion is not on the last line, because the last line has a print "this folder done"... then, can you wipe the whole stack frame out?  That is, will the position of the next line of code to run also depend on the stack frame?

If the next line to run depends on the stack, then maybe it can boil down to these 2 rules?

the recursive call must be the last operation of the function, so after this recursive call, the current function will end and there is no "next line of code to run" to remember.

there must be no operation involved with this recursive call.  No math operations, whatsoever, especially if it involves a local variable.  It must simply return f(...) and return it alone. (or call this procedure alone). The ... inside can involve calculations, even if it involves local variables.  Outside of (...) you cannot do any calculation at all.

答:
Tail call optimization indeed boils down to those final two rules you stated:

The tail call must be the last operation in the function and its result (if any) must only be used to return it unchanged to the function's caller.


答:
Consider the functional language Clojure, because TCO is difficult to implement in the JVM, Clojure presents tail calls as an expression with the recur. For example, we might have the following factorial function.

```<code>(def factorial
  (fn [n]
    (let [factorial-inner
         (fn [cnt acc]
           (if (zero? cnt)
             acc
             (recur (dec cnt) (* acc cnt))))]
         (factorial-inner n 1))))
</code>```

(Typically the loop macro is used as a way to save defining functions like factorial-inner.) This is functionally equivalent to the following

```<code>(def factorial
   (fn [n]
     (if (zero? n)
         1
         (* n (factorial (dec n))))))
</code>```

However, recur may only be called in the tail position and so guarantees that TCO may be performed. It is bound essentially by the rules you list. What adds complexity to this answer is that there are a number of well known optimizations that transform recursive calls into tail calls so that TCO may be performed. Somewhat confusingly, these optimizations are sometimes also called TCO.

A well known example is Tail call modulo cons. A function written in this way has the form:

```<code>f (base_case) = base_value
f (args) = cons(g(args), f(h(args)))
</code>```

Functions written in this way, when cons and g satisfy appropriate conditions, can be rewritten as

```<code>f (args) = f_inner(args, base_value)
  where
    f_inner (base_case, acc) = acc
    f_inner (args, acc) = f_inner(h(args), cons(g(args), acc))
</code>```

where f_inner is clearly tail-call recursive. (Exercise: show that the non-tail call factorial definition is a tail call modulo cons and that it can be transformed into the first definition.)  Even more complicated cases of such rewriting optimizations (those that rewrite a non-tail-call-recursive definition into a tail-call recursive one) are possible. The GHC implementation of the language Haskell contains perhaps the most extensive use of term-rewriting optimizations (even allowing users to contribute rewriting rules). For more details, consult this page and the linked papers.

ContentLicense: CC BY-SA 3.0

Title: What can qualify for potential tail call recursion (TCO) optimization or tail recursion elimination (TRE)

Body:
Short question is: what can qualify for potential tail call recursion optimization (TCO) or tail recursion elimination (TRE) if the compiler or interpreter supports it.

The summary of this question is in the section "Or is it true that, one simplest way to think about it" below.

I saw the Stack Overflow question "What is tail-recursion elimination?" as well, and read different descriptions of how a tail call recursion can happen.

First one:

a tail call is a subroutine call performed as the final action of a procedure (Wikipedia as of Jan 10, 2016)

Second one:

when the value returned by the recursive call is itself immediately returned (Programming Interview Exposed, Wiley, 2013)

Third one:

when a function calls itself, it cannot do any operation with this value that involves a local variable, and just return it. This call happens at the end of function, and so any local variables or "state" inside the stack (inside the current scope) can be thrown away

I think the second one is very close to the third one, except I didn't see exactly what it mean by "immediately".  The first one made me think if I return n * fact(n-1) then it qualifies, although later on in Wikipedia, it says n * fact(n - 1) is not tail recursive, because even though it calls itself on the last line, it uses n, so it doesn't qualify for TCO.

Interestingly, maybe the book Programming Interview Exposed 2013, Wiley, needs an errata, that it says

```<code>int factorial( int n ) {
    if (n > 1) {
        /* Recursive case */
        return factorial(n-1) * n;
    } else {
        /* Base case */
        return 1;
    }
}
</code>```

when the value returned by the recursive call is itself immediately returned, as in the preceding definition for factorial, the function is tail-recursive. Some compilers can perform tail call elimination on tail-recursive functions, an optimization that reuses the same stack frame for each recursive call

but I don't think it is tail recursive, is it?

Is calling on the last line important? On the page Tail Call Optimization in Ruby it says the following code can qualify for TCO:

```<code>def fact(n, acc=1)             # just assuming we pass in non-negative n
  return acc if n <= 1
  return fact(n-1, n*acc)
end
</code>```

But isn't it true that even the following qualify for TCO?

```<code>def fact(n, acc=1)
  return fact(n-1, n*acc) if n > 1
  return acc if n <= 1
end
</code>```

Or is it not, because it has "unfinished business" -- you need the stack to remember where the code has reached and continue later on, so you cannot wipe out the stack?

What if you do math operation, but it is like return 1 + fact(n-1)?  That is, you are adding a constant, 1 instead of touching any local variable, so there shouldn't be stack info that needs to be kept each time you recurs.  But if you view it as needing to remember 1 + (1 + (1 + (1 + ..., then in fact you still need more and more stack, unless if typical TCO can actually optimize it to 4 + fact(...) without needing new stacks.

Or is it true that, one simplest way to think about it is:

When you can wipe out the whole stack frame, because there is no need to keep any of those info in the current stack when you make the recursive call, then you can wipe the whole stack frame out and just use a "GO TO", instead of adding a new stack, then it can qualify for TCO?  Then, at least for this recursive call alone, there will be no stack overflow.

So because if you can wipe out the whole stack frame, that means, there is no local variables that is needed?

What if it is a recursive call to traverse a binary tree or rename all files under a directory and all its subdirectories, from the form "Programming_Ruby.pdf" to "Programming Ruby.pdf", and your recursion is not on the last line, because the last line has a print "this folder done"... then, can you wipe the whole stack frame out?  That is, will the position of the next line of code to run also depend on the stack frame?

If the next line to run depends on the stack, then maybe it can boil down to these 2 rules?

the recursive call must be the last operation of the function, so after this recursive call, the current function will end and there is no "next line of code to run" to remember.

there must be no operation involved with this recursive call.  No math operations, whatsoever, especially if it involves a local variable.  It must simply return f(...) and return it alone. (or call this procedure alone). The ... inside can involve calculations, even if it involves local variables.  Outside of (...) you cannot do any calculation at all.

Body:
Consider the functional language Clojure, because TCO is difficult to implement in the JVM, Clojure presents tail calls as an expression with the recur. For example, we might have the following factorial function.

(def factorial
  (fn [n]
    (let [factorial-inner
         (fn [cnt acc]
           (if (zero? cnt)
             acc
             (recur (dec cnt) (* acc cnt))))]
         (factorial-inner n 1))))

(Typically the loop macro is used as a way to save defining functions like factorial-inner.) This is functionally equivalent to the following

(def factorial
   (fn [n]
     (if (zero? n)
         1
         (* n (factorial (dec n))))))

However, recur may only be called in the tail position and so guarantees that TCO may be performed. It is bound essentially by the rules you list. What adds complexity to this answer is that there are a number of well known optimizations that transform recursive calls into tail calls so that TCO may be performed. Somewhat confusingly, these optimizations are sometimes also called TCO.

A well known example is Tail call modulo cons. A function written in this way has the form:

f (base_case) = base_value
f (args) = cons(g(args), f(h(args)))

Functions written in this way, when cons and g satisfy appropriate conditions, can be rewritten as

f (args) = f_inner(args, base_value)
  where
    f_inner (base_case, acc) = acc
    f_inner (args, acc) = f_inner(h(args), cons(g(args), acc))

where f_inner is clearly tail-call recursive. (Exercise: show that the non-tail call factorial definition is a tail call modulo cons and that it can be transformed into the first definition.)  Even more complicated cases of such rewriting optimizations (those that rewrite a non-tail-call-recursive definition into a tail-call recursive one) are possible. The GHC implementation of the language Haskell contains perhaps the most extensive use of term-rewriting optimizations (even allowing users to contribute rewriting rules). For more details, consult this page and the linked papers.


答:
A tail call is any call that is done immediately before the calling function returns. In return n + foo(), the last operation before returning must be the addition not the call. In return foo(), the call is indeed in tail position.

Why can't a compiler magically optimize that away, since some simple operation do not affect the stack? Because in most calling conventions, a function is given a return address during call. A return is like a goto to this address. When a function a() { return b() }; a() is not tail-called optimized, we get a sequence of operations like this:

a() is called with a return address in the main

b() is called with a return address in a

b returns into a

a returns into the main

With deep recursion, all of these return addresses start to consume a lot of stack space. So with TCO, a tail call is given the return address of the current function:

a() is called with return address in the main

b() is called with return address in the main ← TCO!

b returns into the main

So after b was called as a tail call, the flow of control never re-entered the a function! And since the same return address is reused for the call, no extra stack space was used.

Your final rules are therefore sufficiently correct. However, return n * fact(n - 1) does have an operation in the tail position! This is the multiplication *, which will be the last thing the function does before it returns. In some languages, this might actually be implemented as a function call which could then be tail-call optimized.

Another point to keep in mind is that tail calls are a special case of a “call with continuation”. A continuation is like a function or a closure, but also remembers where in that function the execution was stopped – it can therefore be continued. One surprising aspect is that every program can be translated into a form that uses continuations, where every call is a tail call! This is called Continuation-Passing-Style and is used in some compilers as an intermediate form.


问:
Is there any reason to use the "var" keyword in ES6?
Babel's guide to ES6 says:

let is the new var.

Apparently the only difference is that var gets scoped to the current function, while let gets scoped to the current block. There are some good examples in  this answer.

I can't see any reason to use var in ES6 code. Even if you want to scope a given variable to the whole function, you can do so with let by putting the declaration at the top of the function block, which is what you should be doing with var anyway to indicate the actual scope. And if you want to scope something more finely in an for block or something, then you can do that too.

So my instinct is to stop using var altogether when writing ES6 code.

My question is, am I wrong about this? Is there any legitimate case where var would be preferable over let?

答: I tend to agree that only "let" should be used in es6.  AFIK, redeclaring a "let" generates an error (which is good), while with "var", you simply override the value (though "strict mode" in es5 takes care of that too).</p>


问:
Handling multiple asynchronous events - Wait for pending offers to process on new offer?
I have a programming problem, that I don't know how to solve. And while I have provided a sample of my code, I am interested in a conceptual answer on how to resolve this problem.

On a tradeOffers event, I call a function to get a list of offers and process them one by one using async.forEachOfSeries from Async.js module. However, if a new offer comes in while pending offers are still processing then the same offer can be processed multiple times and also return an offer unavailable error because it was already accepted.  This is a problem because the new offer is effectively not evaluated.

Is it possible to solve this with simple callback or true / false flag, or would I need to implement a queue for the offers? If I need to use a queue, then I would like to avoid using SQL to store the offers. Or do I need a more complex control mechanism to handle new tradeOffers events when processing is already in place?

I am currently using steam-tradeoffers and steam-user module.

To better explain my current situation, here is the code:

```<code>    steam.on('tradeOffers', function(count) {
        if (count > 1 && bot_working == true) {
            processoffers();
        }
        });

    function processoffers() {
        if (bot_working) {
            offers.getOffers({
                get_received_offers: 1,
                active_only: 1,
                get_sent_offers: 0,
                get_descriptions: 1,
                time_historical_cutoff: Math.round(Date.now() / 1000),
                language: "en_us"
            }, function(error, body) {
                if(error) return;
                if(body.response.trade_offers_received){
                async.forEachOfSeries(body.response.trade_offers_received, function(offer, key, cboffer) {
                        if (offer.trade_offer_state == 2){
                            //process offer
                        }
                        }, function (err) {
                if (err) console.log(err.message);
                  console.log('Completed all incoming offers.');
                }
            ); //function foreach
        } //if trade tradeoffers
    }); //if getoffers
};
};
</code>```

答:
If the array you're asynchronously processing can be modified by other code, problems like this are bound to happen at some point. The simplest way to prevent this kind of race condition is to make a defensive copy.

The "multiple acceptance" bug you describe makes it sound like this callback is mutating the actual objects in the array, rather than merely changing which objects the array contains, so you'll probably have to use a deep copy rather than a shallow copy for this to work.

Ideally, the defensive copy would be done in the implementation of getOffers() before calling the callback, so that call sites never have to worry about these problems. Personally, I always throw in a defensive copy whenever I implement a method like this, because it preemptively prevents so many subtle bugs in client code. Whether I use a deep or a shallow copy depends on how much control I'm supposed to have over the objects I'm passing to client code.

But sometimes, the array or the objects it contains might be too large for a deep defensive copy to be practical. In that case, you're going to need a more interesting solution. I don't know if this applies to your problem, but for the sake of completeness...

You could try to ensure that tradeOffers never runs while there is an unfinished getOffers() request. As you suggested, the most straightforward way of doing this is to maintain a queue of requests and process them one at a time. But even that approach will require the getOffers() callback to somehow tell you when it's done executing all of its async bits. Relying on client code to always return a promise or always call a special callback when it's really really done is...risky to say the least.

A quick hacky solution would be to stick to fully synchronous code inside the getOffers() callback. However, this relies on the assumption that getOffers() calls your callback synchronously rather than asynchronously, otherwise you still have one tick where a tradeOffers event can sneak in. Maybe you happen to know that getOffers() always calls its callbacks synchronously. But personally, even if I did know that, this sort of subtle timing assumption makes me uneasy because it comes a bit too close to "releasing Zalgo".

You could store the offers in an actual database, since most databases have already solved this problem.

In case it isn't obvious, I'd go with a database when the data is too big to copy. Relying on databases to do heavy lifting tends to prevent a lot of headaches.


问:
Personal pages domains architecture
We're looking to add personal pages generator for our users, which is simple enough while all of them are on our domain. We also want to enable them to purchase their own domains through us, and serve these pages on their domain.

We currently use Google App Engine for all of our deployment and server needs, and it has been pretty great so far. Now the problem is that I can't really point a domain to single page handler on App Engine, thus I'll have to resort to an external solution.

We can easily handle the pages generation, the main issue I'm facing is serving a different dynamic page for different domains from a single server.

What architecture do you suggest? What technologies/platforms should I research?
(We're looking at significant users traffic when this thing is up)

答:
I'd start with a reverse proxy running Nginx or HAProxy with virtual hosts on a bigger Google Cloud VM.  Each of your customers' personal site domains would be directed to the reverse proxy and its virtual hosts would proxy back to the appropriate AppEngine instances.

This way you can serve distinct sites with TLS using SNI.

Other alternatives include Content Delivery Networks (CDNs) like Akamai, CloudFlare, Fastly, and Amazon CloudFront.  I've personally had good experiences with Akamai, but I use it primarily as a Web Application Firewall which is a different ballgame entirely.

Unless the traffic on these personal sites is massive the Nginx/HAProxy solution will hold for quite a long time.  The CDN solution is more for high traffic use cases.  The cost could be prohibitive depending on your revenue model.

Title: Personal pages domains architecture


问:
Event Sourcing and cross-context aggregate
I had this idea of different write models being used in different bounded contexts, but both being the same aggregate instance (the same events).

For example consider a User aggregate that is used in Administration and User contexts (that is the admin and the user-interface parts of the application). And the domain model says that the user (in User context) cannot do any action on itself (change email, change password, change address, whatever) unless he is logged in (which is the only action he is permitted to do if hes not logged in).

In administration context, however, the action does not need that user to be logged in (basically, an admin can change user's details on his behalf).

Can this be modeled with Event Sourcing as a single aggregate instance (same ID), but depending on the context a different object model would be built from the events? i.e. in admin context, the model does not verify the user is logged in, but in user context, the model does. This way the events would be shared between the contexts.

Is this a good idea? I can smell some issues but I am not completely sure.

答:
I had this idea of different write models being used in different bounded contexts, but both being the same aggregate instance (the same events).

That strikes me as a bad idea; very much at contradiction with best practices.

The aggregate really needs to have one source of truth.  In an event sourced implementation, that's really the history of the aggregate.  The consistency of that history is guarded by the aggregate itself.  If you have two different implementations of the aggregate (two different collections of business rules - which permit different states), then you are opening yourself up to a real mess when one implementation leaves the history in a state that the other is supposed to prevent.

Two different applications could (potentially) share the same domain model though.  In your case, that could mean that one of the contexts permits the command when the other would forbid it.

However, in the original blue book, a bounded context is a boundary beyond which a model may not apply, where the ubiquitous language changes, and so on.  If the words used to describe the business no longer mean the same thing, then sharing the same aggregates seems unwise.

See also: With all of these services, how can I not be anemic?

Note that there is absolutely nothing wrong with two different projections reading their state from the same history.  The User context could have one view of the history, where the Administration context has a completely different view of that same history.


问:
How are objects treated in an anonymous inner class?
Lets take this for example...

```<code>entryText.addTextChangedListener(new TextWatcher() {

    TextView wordCount = (TextView) findViewById(R.id.wordCount);
    TextView charCount = (TextView) findViewById(R.id.charCount);

    @Override
    public synchronized void afterTextChanged(Editable s) {
        wordCount.setText("W: " + String.valueOf(ChosenFile.countWords(entryText.getText().toString())));
        charCount.setText("C: " + Integer.toString(entryText.getText().length()));
    }

    @Override
    public void beforeTextChanged(CharSequence s, int start, int count, int after) {
        // TODO Auto-generated method stub
    }

    @Override
    public void onTextChanged(CharSequence s, int start, int before, int count) {
        // TODO Auto-generated method stub
    }
});
</code>```

Are new instances of textviews wordCount and CharCount created each time the listener is invoked? Would it be better to make them global?

How is memory handled? Lets say new instances are created, how does that affect memory?

答: The variables wordCount and charCount are created and initialized only when the TextWatcher object is created and added as a listener.  No new instance is created every time the text changes.</p>


问:
Why does git pull perform a merge instead of a rebase by default?
Consider the following situation:

You have a clone of a git repository

You have some local commits (commits that have not yet been pushed anywhere)

The remote repository has new commits that you have not yet reconciled

So something like this:

If you execute git pull with the default settings, you'll get something like this:

This is because git performed a merge.

There's an alternative, though. You can tell pull to do a rebase instead:

```<code>git pull --rebase
</code>```

and you'll get this:

In my opinion, the rebased version has numerous advantages that mostly center around keeping both your code and the history clean, so I'm a little struck by the fact that git does the merge by default. Yes, the hashes of your local commits will get changed, but this seems like a small price to pay for the simpler history you get in return.

By no means am I suggesting that this is somehow a bad or a wrong default, though. I am just having trouble thinking of reasons why the merge might be preferred for the default. Do we have any insight into why it was chosen? Are there benefits that make it more suitable as a default?

The primary motivation for this question is that my company is trying to establish some baseline standards (hopefully, more like guidelines) for how we organize and manage our repositories to make it easier for developers to approach a repository they haven't worked with before. I am interested in making a case that we should usually rebase in this type of situation (and probably for recommending developers set their global config to rebase by default), but if I were opposed to that, I would certainly be asking why rebase isn't the default if it's so great. So I'm wondering if there is something I'm missing.

It has been suggested that this question is a duplicate of Why do so many websites prefer “git rebase” over “git merge”?; however, that question is somewhat the reverse of this one. It discusses the merits of rebase over merge, while this question asks about the benefits of merge over rebase. The answers there reflect this, focusing on problems with merge and benefits of rebase.

答:
You're correct, assuming you have only one local/changed repository. However, consider there being a second local PC, for example.

Once your local/modified copy is pushed somewhere else rebasing will screw up those copies. Of course, you could force pushing, but that quickly becomes complicated. What happens if one or more of these have another completely new commit?

As you can see, it's very situational, but the base strategy seems (to me) a lot more practical in non-special/collaboration cases.

A second difference: The merge strategy will keep a clear and time consistent structure. After rebases it's very likely that older commits might follow newer changes, making the whole history and its flow harder to understand.


问:
ASP.NET storing encrypted & salted Password
I have a question about storing encrypted passwords in your database to help secure them. I have a class that encrypts the password passed in and returns a string. This string has 3 parts too it, all separated by a colon. The first part is the iteration, the 2nd part of it is the salt, and the third part of it is the encrypted password. Ex: "1000:{salt}:{encrypted password}".

My question is how am I suppose to store this? As of right now, I am storing the entire string in my database under the password column. Then when I go to check the passwords for a login, I retrieve that record, and I have a method in my class that parses it and verifies that the two passwords match. Is this a big 'no no?' I've read where some people store the salt in it's own column then pull that down when verifying a login. However, this class that I am using for the encryption will return a string like I showed above. Then it came with a method that I can just pass that entire string into it and it will parse it up and verify the passwords as a login.

I guess what I'm asking is, do I need to re-construct my class to separate the string ("{iteration}:{salt}:{encrypted password}"), or is storing that entire string in the database OK?

答:
What you do is how most are doing it, and it is perfectly fine.

The thing people say about not doing your own security is that you should not invent your own way of hashing the password. Always use a state of the art password hashing algorithm.

So store the hashed password including the individual salt and the number of iterations (which allows you to increase the number of iterations later if you need to) in the database.


答:
It is hard to know for sure why merge is the default without hearing from the person who made that decision.

Here is a theory...

Git cannot presume it is ok to --rebase every pull. Listen to how that sounds. "Rebase every pull." just sounds wrong if you use pull requests or similar. Would you rebase on a pull request?

In a team that is not just using Git for centralized source control...

You may pull from upstream and from downstream. Some people do a lot of pulling from downstream, from contributors, etc.

You may work on features in close collaboration with other developers, pulling from them or from a shared topic branch and still occasionally updated from upstream. If you always rebase then you end up changing shared history, not to mention fun conflict cycles.

Git was designed for a large highly distributed team where everyone does not pull and push to a single central repo. So the default makes sense.

Developers who do not know when it's ok to rebase will merge by default.

Developers can rebase when they want to.

Commiters who do a lot of pulls and have a lot of pull get the default that suits them best.

For evidence of intent, here's a link to a well known email from Linus Torvalds with his views on when they should not rebase.
Dri-devel git pull email

If you follow the whole thread you can see that one developer is pulling from another developer and Linus is pulling from both of them. He makes his opinion pretty clear. Since he probably decided Git's defaults, this might explain why.

A lot of people now use Git in a centralized way, where everyone in a small team pulls only from an upstream central repo and pushes to that same remote. This scenario avoids some of the situations where a rebase is not good, but usually does not eliminate them.

Suggestion: Don't make a policy of changing the default. Any time you put Git together with a big group of developers some of the developers won't understand Git all that deeply (myself included). They will go to Google, SO, get cookbook advice and then wonder why some things don't work, e.g. why does git checkout --ours <path> get the wrong version of the file? You can always revise your local environment, make aliases, etc. to suit your taste.

Title: Why does git pull perform a merge instead of a rebase by default?

Body:
Consider the following situation:

You have a clone of a git repository

You have some local commits (commits that have not yet been pushed anywhere)

The remote repository has new commits that you have not yet reconciled

So something like this:

If you execute git pull with the default settings, you'll get something like this:

This is because git performed a merge.

There's an alternative, though. You can tell pull to do a rebase instead:

```<code>git pull --rebase
</code>```

and you'll get this:

In my opinion, the rebased version has numerous advantages that mostly center around keeping both your code and the history clean, so I'm a little struck by the fact that git does the merge by default. Yes, the hashes of your local commits will get changed, but this seems like a small price to pay for the simpler history you get in return.

By no means am I suggesting that this is somehow a bad or a wrong default, though. I am just having trouble thinking of reasons why the merge might be preferred for the default. Do we have any insight into why it was chosen? Are there benefits that make it more suitable as a default?

The primary motivation for this question is that my company is trying to establish some baseline standards (hopefully, more like guidelines) for how we organize and manage our repositories to make it easier for developers to approach a repository they haven't worked with before. I am interested in making a case that we should usually rebase in this type of situation (and probably for recommending developers set their global config to rebase by default), but if I were opposed to that, I would certainly be asking why rebase isn't the default if it's so great. So I'm wondering if there is something I'm missing.

It has been suggested that this question is a duplicate of Why do so many websites prefer “git rebase” over “git merge”?; however, that question is somewhat the reverse of this one. It discusses the merits of rebase over merge, while this question asks about the benefits of merge over rebase. The answers there reflect this, focusing on problems with merge and benefits of rebase.


问:
Given a herd of horses, how do I find the average horn length of all unicorns?
The question above is an abstract example of a common problem I encounter in legacy code, or more accurately, problems resulting from previous attempts at solving this problem.

I can think of at least one .NET framework method that is intended to address this problem, like the Enumerable.OfType<T> method. But the fact that you ultimately end up interrogating an object's type at runtime doesn't sit right with me.

Beyond asking each horse "Are you a unicorn?" the following approaches also come to mind:

Throw an exception when an attempt is made to get the length of a non-unicorn's horn (exposes functionality not appropriate for each horse)

Return a default or magic value for the length of a non-unicorn's horn (requires default checks peppered throughout any code that wants to crunch horn stats on a group of horses that could all be non-unicorns)

Do away with inheritance and create a separate object on a horse that tells you if the horse is a unicorn or not (which is potentially pushing the same problem down a layer)

I have a feeling this is going to be best answered with a "non-answer." But how do you approach this problem and if it depends, what's the context around your decision?

I'd also be interested in any insights on whether this problem still exists in functional code (or maybe it only exists in functional languages that support mutability?)

This was flagged as a possible duplicate of the following question:
How to avoid downcasting?

The answer to that question assumes that one is in possession of a HornMeasurer by which all horn measurements must be made. But that's quite an imposition on a codebase that was formed under the egalitarian principle that everyone should be free to measure the horn of a horse.

Absent a HornMeasurer, the accepted answer's approach mirrors the exception-based approach listed above.

There's also been some confusion in the comments on whether horses and unicorns are both equines, or if a unicorn is a magical subspecies of horse. Both possibilities should be considered--perhaps one is preferable to the other?

答:
But the fact that you ultimately end up interrogating an object's type
  at runtime doesn't sit right with me.

The trouble with this statement is that, no matter what mechanism you use, you will always be interrogating the object to tell what type it is. That can be RTTI or it can be a union or a plain data structure where you ask if horn > 0. The exact specifics change slightly but the intent is the same - you ask the object about itself in some way to see if you should interrogate it further.

Given that, it makes sense to use your language's support to do this. In .NET you'd use typeof for example.

The reason to do this goes beyond just using your language well. If you have an object that looks like another one but for some small change, the chances are you're going to find more differences over time. In your example of unicorns/horses you may say there's just horn length... but tomorrow you'll be checking to see if a potential rider is a virgin, or if the poop is glittery. (a classic real-world example would be GUI widgets that derive from a common base and you have to look for checkboxes and listboxes differently. The number of differences would be too great to simply create a single super object that held all possible permutations of data).

If checking an objects's type at runtime doesn't hold well, then your alternative is to split the different objects right from the start - instead of storing a single herd of unicorn/horses, you hold 2 collections - one for horses, one for unicorns. This can work very well, even if you store them in a specialised container (eg a multimap where the key is the object type... but then even though we store them in 2 groups, we're right back at interrogating the object type!)

Certainly an exception based approach is wrong. Using exceptions as normal program flow is a code smell (if you had a herd of unicorns and a donkey with a seashell taped to its head snuck in, then I'd say exception based approach is OK, but if you have a herd of unicorns and horses then checking each for unicorn-ness is not unexpected. Exceptions are for exceptional circumstances, not a complicated if statement). In any case, using exceptions for this problem is simply interrogating the object type at runtime, only here you're misusing the language feature to check for non-unicorn objects. You might as well code in a if horn > 0 and at least process your collection quickly, clearly, using fewer lines of code and avoiding any issues rising from when other exceptions are thrown (eg an empty collection, or trying to measure that donkey's seashell)


问:
How do you scale your integration testing?
I am investigating techniques and strategies for scaling our growing number of integration tests on our current product, so that they can (humanly) remain part of our development, and CI process.

At about 200+ integration tests we are already hitting the 1hr mark to complete a full test run (on aa desktop dev machine), and this is negatively affecting a developer's ability to tolerate running the whole suite as part of the routine push processes. Which is affecting motivation to be disciplined about creating them well. We integration test only key scenrios front to back, and we use an environment that mirrors production, that is built from scratch each test run.

Because of the time it takes to run, it is making for a terrible feedback loop and many wasted cycles waiting on machines to finish test runs, no matter how focused the test runs are. Nevermind the more expensive negative impact on flow and progress, sanity and sustainability.

We expect to have 10x fold more integration tests before this product begins to slow down (no idea really, but it does not feel like we are even getting started in terms of features yet). We have to resaonably expect to be in the few hundreds or or couple thousands of integration tests, I reckon at some point.

To be clear, to try to prevent this becoming a discussion on unit testing versus integration testing, (which should never be traded). We are doing both unit testing with TDD AND integration testing in this product. In fact, we do integration testing at the various layers in the services architecture that we have, where it makes sense to us, as we need to to verify where we introduce breaking changes when changing the patterns in our architecture to the other areas of the system.

A little about our tech stack. We are currently testing on a (CPU and memory intensive) emulation environment to run our tests from end to end. Which is composed of Azure REST web services fronting a noSql backend (ATS). We are simulating our production environment by running in the Azure desktop Emulator + IISExpress. We are limited to one emulator and one local backend repository per dev machine.

We also have a cloud-based CI as well, which runs the same test in the same emulated environment, and the test runs are taking twice as long (2hrs+) in the cloud with our current CI provider. We have reached the limits of the cloud CI providers SLA in terms of hardware performance, and exceeded their allowance on test run time. To be fair to them, their specs are not bad, but half as good as an inhouse grunty desktop machine clearly.

We are using a testing strategy of rebuilding our data store for each logical group of tests, and preloading with test data. While comprehensively insuring data integrity, this adds 5-15% impact on each test. So we think there is little to be gained optimizing that testing strategy at this point in the product development.

The long and the short of it is that: whilst we could optimize the throughput of each test (even if by as much as 30%-50% each), we still wont scale effectively in the near future with several hundred tests. 1hr now is even still far in excess of humanly tolerable, we need an order of magnitude-ish improvement in the overall process to make it sustainable.

So, I am investigating what techniques and strategies we can employ to drastically reduce testing time.

Writing less tests is not an option. Lets please not debate that one in this thread.

Using faster hardware is definately an option, although very expensive.

Running groups of tests/scenarios on separate hardware in parrallel is also definately a preferred option.

Creating grouping of tests around features and scenarios under development is plausible, but ultimately not reliable in proving full coverage or confidence that the system is not affected by a change.

Running in a cloud-scaled staging environment instead of running in the desktop emulator is technically possible, although we start adding deployment times to test runs (~20mins each at the start of the test run to deploy the stuff).

Dividing the components of the system into independent logial pieces is plausible to a degree but we expect limited mileage on that, since the interractions between components is expected to increase with time. (i.e. a change is ine is likely to affect others iin unexpected ways - as often happens when a system is developed incrementally)

I wanted to see what strategies (and tools) others are using in this space.

(I have to believe others may be seeing this kind of difficulty using certain technology sets.))

[Update: 12/16/2016: We ended up investing more in CI parallel testing, for a discussion of the outcome: https://web.archive.org/web/20200114101702/http://www.mindkin.co.nz/blog/2015/12/16/16-jobs ]

答:
Cutting down/optimizing the tests seems like the best idea to me, but in case that's not an option, I have an alternative to propose (but requires building some simple proprietary tools).

I faced a similar problem but not in our integration tests (those ran in minutes). Instead it was simply in our builds: large-scale C codebase, would take hours to build.

What I saw as extremely wasteful was the fact that we were rebuilding the entire thing from scratch (about 20,000 source files/compilation units) even if only a few source files changed, and thus spending hours for a change which should only take seconds or minutes at worst.

So we tried incremental linking on our build servers, but that was unreliable. It would sometimes give false negatives and fail to build on some commits, only to then succeed on a full rebuild. Worse, it would sometimes give false positives and report a build success, only for the developer to merge a broken build into the main branch. So we went back to rebuilding everything every time a developer pushed changes from his private branch.

I hated this so much. I would walk into conference rooms with half the developers playing video games and simply because there was little else to do while waiting on builds. I tried to get a productivity edge by multitasking and starting a new branch once I committed so that I could be working on code while waiting for the builds, but when a test or build failed, it became too painful to queue up changes past that point and try to fix everything and stitch it all back.

Side Project While Waiting, Integrate Later

So what I did instead was to make a skeletal framework of the application -- same kind of basic UI and relevant parts of the SDK for me to develop against as a whole separate project. Then I would write independent code against that while waiting for builds, outside the main project. That at least gave me some coding to do so that I could stay somewhat productive, and then I would start integrating that work done completely outside the product into the project later -- side snippets of code. That's one strategy for your developers if they find themselves waiting a lot.

Parsing Source Files Manually to Figure out What to Rebuild/Rerun

Yet I hated how we were wasting so much time to rebuild everything all the time. So I took it upon myself over a couple of weekends to write some code that would actually scan files for changes and rebuild only the relevant projects -- still a full rebuild, no incremental linking, but only of the projects that needs to be rebuilt (whose dependent files, parsed recursively, changed). That was totally reliable and after demonstrating and testing it exhaustively, we were able to use that solution. That cut the average build times from hours to a few minutes since we were only rebuilding the necessary projects (though central SDK changes could still take an hour, but we did that a lot less frequently than localized changes).

The same strategy should be applicable to integration tests. Just recursively parse source files to figure out what files the integration tests depend upon (ex: import in Java, #include in C or C++) on the server side, and the files included/imported from those files and so on, building a full include/import dependency file graph for the system. Unlike build parsing which forms a DAG, the graph should be undirected since it's interested in any file that changed that contains code which could be executed indirectly *. Only re-run the integration test if any of those files in the graph for the integration test of interest have changed. Even for millions of lines of code, it was easy to do this parsing in less than a minute. If you have files other than source code which can affect an integration test, like content files, perhaps you can write metadata into a comment in the source code indicating those dependencies in the integration tests, so that should those external files change, the tests also get re-run.

* As an example, if test.c includes foo.h which is also included by foo.c, then a change to either test.c, foo.h, or foo.c should mark the integrated test as needing a fresh run.

This can take a full day or two to program and test out, especially in the formal environment, but I think should work even for integration tests and it's well-worth it if you have no other choice but to wait in the hours range for builds to finish (either due to the building or testing or packaging process or whatever). That can translate to so many manhours lost in just a matter of months that would dwarf the time it takes to build this kind of proprietary solution, as well as killing the energy of the team and increasing the stress caused by conflicts in bigger merges done less frequently as a result of all the time wasted waiting. It's just bad for the team as a whole when they're spending large portions of their time waiting on things. The easiest and most universal way to optimize is to simply realize the fact that not all changes require everything to be rebuilt/re-run/repackaged on every little change.

ContentLicense: CC BY-SA 4.0


答:
Have you measured each test to see where the time is being taken? And then, measured the performance of the codebase if there's a particularly slow bit. Is the overall problem one of the tests or the deployment, or both?

Typically you want to reduce the impact of the integration test so that running them on relatively minor changes is minimised. Then you can leave the full test for a 'QA' run which you perform when the branch is promoted to the next level. So you have unit tests for dev branches, run reduced integration tests when merged, and run a full integration test when merged to a release candidate branch.

So this means you do not have to rebuild and re-package and redeploy everything every commit. You can organise your setup, in the dev environment, to perform an as cheaply-as-possible deployment trusting that it will be OK. Instead of spinning up a whole VM, and deploying the entire product, leave the VM with the old version in place and copy new binaries in place, for example (YMMV depending what you have to do).

This overall optimistic approach still requires the full-on test, but that can be performed at a later stage when the time taken is less urgent. (eg you can run the full test once during the night, if there are any issues the dev can resolve them in the morning). This also has the advantage of refreshing the product on the integration rig for the next day's testing - it may get out of date as devs change things, but only by 1 day.

We had a similar problem running a security-based static analysis tool. Full runs would take ages, so we moved running it from the developer commits to an integration commit (ie we had a system where dev said they were finished, it got merged to a 'level 2' branch where more testing was performed, including perf tests. When that was complete it got merged to a QA branch for deployment. The idea is to remove the regular runs that would occur continually to runs that were made nightly - devs would get the results in the morning and they would not affect their development focus until later in their dev cycle).

Title: How do you scale your integration testing?

Body:
I am investigating techniques and strategies for scaling our growing number of integration tests on our current product, so that they can (humanly) remain part of our development, and CI process.

At about 200+ integration tests we are already hitting the 1hr mark to complete a full test run (on aa desktop dev machine), and this is negatively affecting a developer's ability to tolerate running the whole suite as part of the routine push processes. Which is affecting motivation to be disciplined about creating them well. We integration test only key scenrios front to back, and we use an environment that mirrors production, that is built from scratch each test run.

Because of the time it takes to run, it is making for a terrible feedback loop and many wasted cycles waiting on machines to finish test runs, no matter how focused the test runs are. Nevermind the more expensive negative impact on flow and progress, sanity and sustainability.

We expect to have 10x fold more integration tests before this product begins to slow down (no idea really, but it does not feel like we are even getting started in terms of features yet). We have to resaonably expect to be in the few hundreds or or couple thousands of integration tests, I reckon at some point.

To be clear, to try to prevent this becoming a discussion on unit testing versus integration testing, (which should never be traded). We are doing both unit testing with TDD AND integration testing in this product. In fact, we do integration testing at the various layers in the services architecture that we have, where it makes sense to us, as we need to to verify where we introduce breaking changes when changing the patterns in our architecture to the other areas of the system.

A little about our tech stack. We are currently testing on a (CPU and memory intensive) emulation environment to run our tests from end to end. Which is composed of Azure REST web services fronting a noSql backend (ATS). We are simulating our production environment by running in the Azure desktop Emulator + IISExpress. We are limited to one emulator and one local backend repository per dev machine.

We also have a cloud-based CI as well, which runs the same test in the same emulated environment, and the test runs are taking twice as long (2hrs+) in the cloud with our current CI provider. We have reached the limits of the cloud CI providers SLA in terms of hardware performance, and exceeded their allowance on test run time. To be fair to them, their specs are not bad, but half as good as an inhouse grunty desktop machine clearly.

We are using a testing strategy of rebuilding our data store for each logical group of tests, and preloading with test data. While comprehensively insuring data integrity, this adds 5-15% impact on each test. So we think there is little to be gained optimizing that testing strategy at this point in the product development.

The long and the short of it is that: whilst we could optimize the throughput of each test (even if by as much as 30%-50% each), we still wont scale effectively in the near future with several hundred tests. 1hr now is even still far in excess of humanly tolerable, we need an order of magnitude-ish improvement in the overall process to make it sustainable.

So, I am investigating what techniques and strategies we can employ to drastically reduce testing time.

Writing less tests is not an option. Lets please not debate that one in this thread.

Using faster hardware is definately an option, although very expensive.

Running groups of tests/scenarios on separate hardware in parrallel is also definately a preferred option.

Creating grouping of tests around features and scenarios under development is plausible, but ultimately not reliable in proving full coverage or confidence that the system is not affected by a change.

Running in a cloud-scaled staging environment instead of running in the desktop emulator is technically possible, although we start adding deployment times to test runs (~20mins each at the start of the test run to deploy the stuff).

Dividing the components of the system into independent logial pieces is plausible to a degree but we expect limited mileage on that, since the interractions between components is expected to increase with time. (i.e. a change is ine is likely to affect others iin unexpected ways - as often happens when a system is developed incrementally)

I wanted to see what strategies (and tools) others are using in this space.

(I have to believe others may be seeing this kind of difficulty using certain technology sets.))

[Update: 12/16/2016: We ended up investing more in CI parallel testing, for a discussion of the outcome: https://web.archive.org/web/20200114101702/http://www.mindkin.co.nz/blog/2015/12/16/16-jobs ]


问:
Objective-C Lesson in Class Design
I have the following classes:

```<code>   Teacher
   Student
   Class (like a school class)
</code>```

They all extend from KObject that has the following code:

```<code>- initWithKey
- send
- processKey
</code>```

Teacher, Student Class all use the functions processKey and initWithKey from KObject parent class. They implement their own version of send. The problem I have is that KObject should not be instantiated ever. It is more like an abstract class, but there is no abstract class concept in objective-c. It is only useful for allowing subclasses to have access to one property and two functions.

What can I do so that KObject cannot be instantiated but still allow subclasses to have access to the functions and properties of KObject?

答:
You can use a protocol, like so:

```<code>@protocol kObject
- (instancetype) initWithKey: (NSString *) key; // I'm assuming the key is a string.
- (void) send;
- (void) processKey;
@end
</code>```

However, it's uncommon in Objective-C for initializers to be declared in a protocol, and to enforce the LSP you would need to type any method or function that used one of these classes as id<kObject>, which is atypical given the use case.

Generally, there isn't really anything in Objective-C that can prevent a base class from being implemented or invoked. What I've done in the past is left comments in the header, and had the default implementation throw an exception. You won't get compile-time errors, but the code will still stop and you can enforce the constraints of your design that way.

I think of the Python motto, "We're all consenting adults" whenever dealing with abstract classes in Objective-C - it's on the programmer to enforce this given the highly dynamic and (practically) entirely public nature of Objective-C. I trust that if I say it shouldn't be done, it will be adhered to. Exceptions enforce this, even if a bit heavy handed. Alternatively, you can just have the methods return immediately too - making the class useless.

As an aside, you may have luck declaring the property as a protected instance variable, should you not need other classes, methods, or functions to directly access the kObject property.

Title: Objective-C Lesson in Class Design

Body:
You can use a protocol, like so:

@protocol kObject
- (instancetype) initWithKey: (NSString *) key; // I'm assuming the key is a string.
- (void) send;
- (void) processKey;
@end

However, it's uncommon in Objective-C for initializers to be declared in a protocol, and to enforce the LSP you would need to type any method or function that used one of these classes as id<kObject>, which is atypical given the use case.

Generally, there isn't really anything in Objective-C that can prevent a base class from being implemented or invoked. What I've done in the past is left comments in the header, and had the default implementation throw an exception. You won't get compile-time errors, but the code will still stop and you can enforce the constraints of your design that way.

I think of the Python motto, "We're all consenting adults" whenever dealing with abstract classes in Objective-C - it's on the programmer to enforce this given the highly dynamic and (practically) entirely public nature of Objective-C. I trust that if I say it shouldn't be done, it will be adhered to. Exceptions enforce this, even if a bit heavy handed. Alternatively, you can just have the methods return immediately too - making the class useless.

As an aside, you may have luck declaring the property as a protected instance variable, should you not need other classes, methods, or functions to directly access the kObject property.


问:
Interface Segregation Principle: What to do if interfaces have significant overlap?
From Agile Software Development, Principles, Patterns, and Practices: Pearson New International Edition:

Sometimes, the methods invoked by different groups of clients will overlap. If the overlap is small, then the
  interfaces for the groups should remain separate. The common functions should be declared in all the overlapping
  interfaces. The server class will inherit the common functions from each of those interfaces, but it will implement
  them only once.

Uncle Bob, talks about the case when there is minor overlap.

What should we do if there is significant overlap?

Say we have

```<code>Class UiInterface1;
Class UiInterface2;
Class UiInterface3;

Class UiIterface : public UiInterface1, public UiInterface2, public UiInterface3{};
</code>```

What should we do if there is significant overlap between UiInterface1 and UiInterface2?

答:
This is a judgement call that you have to make, on a case-by-case basis.

First of all, remember that SOLID principles are just that ... principles. They're not rules. They're not a silver bullet. They're just principles. That's not to take away from their importance, you should always lean towards following them. But the second they introduce a level of pain, you should ditch them until you need them.

With that in mind, think about why you're separating out your interfaces in the first place. The idea of an interface is to say "If this consuming code requires a set of methods to be implemented on the class being consumed, I need to set a contract on the implementation: If you provide me an object with this interface, I can work with it."

The purpose of ISP is to say "If the contract I require is only a subset of an existing interface, I shouldn't enforce the existing interface on any future classes that may be passed to my method."

Consider the following code:

```<code>public interface A
{
    void X();
    void Y();
}

public class Foo
{
     public void ConsumeX(A a)
     {
         a.X();
     }
}
</code>```

Now we have a situation where, if we want to pass a new object to ConsumeX, it has to implement X() and Y() to fit the contract.

So should we change the code, right now, to look like the next example?

```<code>public interface A
{
    void X();
    void Y();
}

public interface B
{
    void X();
}

public class Foo
{
     public void ConsumeX(B b)
     {
         b.X();
     }
}
</code>```

ISP suggests we should, so we should lean towards that decision. But, without context, it's hard to be sure. Is it likely that we'll extend A and B? Is it likely that they'll extend independently? Is it likely that B will ever implement methods that A doesn't require? (If not, we can make A derive from B.)

This is the judgement call you have to make. And, if you really don't have enough information to make that call, you should probably take the simplest option, which might well be the first code.

Why? Because it's easy to change your mind later. When you need that new class, simply create a new interface and implement both in your old class.

Body:
This is a judgement call that you have to make, on a case-by-case basis.

First of all, remember that SOLID principles are just that ... principles. They're not rules. They're not a silver bullet. They're just principles. That's not to take away from their importance, you should always lean towards following them. But the second they introduce a level of pain, you should ditch them until you need them.

With that in mind, think about why you're separating out your interfaces in the first place. The idea of an interface is to say "If this consuming code requires a set of methods to be implemented on the class being consumed, I need to set a contract on the implementation: If you provide me an object with this interface, I can work with it."

The purpose of ISP is to say "If the contract I require is only a subset of an existing interface, I shouldn't enforce the existing interface on any future classes that may be passed to my method."

Consider the following code:

public interface A
{
    void X();
    void Y();
}

public class Foo
{
     public void ConsumeX(A a)
     {
         a.X();
     }
}

Now we have a situation where, if we want to pass a new object to ConsumeX, it has to implement X() and Y() to fit the contract.

So should we change the code, right now, to look like the next example?

public interface A
{
    void X();
    void Y();
}

public interface B
{
    void X();
}

public class Foo
{
     public void ConsumeX(B b)
     {
         b.X();
     }
}

ISP suggests we should, so we should lean towards that decision. But, without context, it's hard to be sure. Is it likely that we'll extend A and B? Is it likely that they'll extend independently? Is it likely that B will ever implement methods that A doesn't require? (If not, we can make A derive from B.)

This is the judgement call you have to make. And, if you really don't have enough information to make that call, you should probably take the simplest option, which might well be the first code.

Why? Because it's easy to change your mind later. When you need that new class, simply create a new interface and implement both in your old class.


问:
How to handle a client app that connects to a TCP server and sends/receives text data bidirectionally?
I've got a conceptual question (which is probably better posted here than on StackOverflow?).

I want to develop a client application that maintains a persistent connection to a server, and exchanges text data back and forth. An IRC client is a great example. So, these are givens:

There is a fairly steady stream of incoming text that needs to be interpreted and dealt with in some way by the client.

The client will send commands and it expects specifically formatted responses back from the server.

There are probably quite a few approaches, but I'm looking for (obviously) the most efficient. Should I just manage all incoming text through the "on data received" event?

(pseudo-code)

```<code>on(data)
  if data matches /###DAT action1/
    handleAction1
  else if data matches /###DAT action2/
    handleAction2
  else if data matches /###DAT PRIVMSG/
    handlePrivateMessage
  else if data matches /###DAT LOGIN_OK/
    handleConfirmedLogin
</code>```

So every possible bit of text that I'd want to deal with, is scanned here, whether it's a private message from someone, or a response to a login command I just sent.

Is there a better way to deal with this? If it matters, I'm using JavaScript.

答:
It's likely the most efficient approach is to model your message handler as a state machine. Scan character by character and move to an appropriate state. If there's no state transition defined for a character, then the message is invalid. If the new state is final (a complete message), then execute the prescribed action. Until then, keep processing character by character. Basically, it's a message lexer with only one token to identify. (You can always add more, parameters or whatnot, down the road. Lexing will remain fast.) The advantage of this approach is that you only ever touch each character in the message once. In your pseudo-code, if the message is LOGIN_OK, you touch the first character four times before it's resolved.

Let's look at an example. Say our valid messages are:

```<code>ACTION_1
ACTION_2
PRIVMSG
LOGIN_OK
</code>```

Start scanning characters from left to right. If I see an 'L', I immediately know the message must be LOGIN_OK or invalid. There's no need to consider the other cases. Keep scanning to confirm.

If the first character I see is 'A', I know the message must be an action. There's no need to consider PRIVMSG or LOGIN_OK. I need to consume 'A', 'C', 'T', 'I', 'O', 'N', and '_' before I get to a character that resolves the ambiguity. The nice thing is that once I get there, I'm done. Either I know the answer or the message is invalid.

Consider the message ACTION_INVALID in your if/else approach. You have to scan the whole message to check for ACTION_1, then scan the whole message again to check for ACTION_2. Even then, you have to consider the possibility of PRIVMSG or LOGIC_OK. With a state machine/lexer, the first character immediately eliminates two possibilities. To fully resolve the message, you only have to look at eight characters versus scanning the string again and again.

If you decide to go this route, tools like Ragel are useful for generating the state machine versus writing it by hand. There's even a port that generates JavaScript.

Body:
It's likely the most efficient approach is to model your message handler as a state machine. Scan character by character and move to an appropriate state. If there's no state transition defined for a character, then the message is invalid. If the new state is final (a complete message), then execute the prescribed action. Until then, keep processing character by character. Basically, it's a message lexer with only one token to identify. (You can always add more, parameters or whatnot, down the road. Lexing will remain fast.) The advantage of this approach is that you only ever touch each character in the message once. In your pseudo-code, if the message is LOGIN_OK, you touch the first character four times before it's resolved.

Let's look at an example. Say our valid messages are:

ACTION_1
ACTION_2
PRIVMSG
LOGIN_OK

Start scanning characters from left to right. If I see an 'L', I immediately know the message must be LOGIN_OK or invalid. There's no need to consider the other cases. Keep scanning to confirm.

If the first character I see is 'A', I know the message must be an action. There's no need to consider PRIVMSG or LOGIN_OK. I need to consume 'A', 'C', 'T', 'I', 'O', 'N', and '_' before I get to a character that resolves the ambiguity. The nice thing is that once I get there, I'm done. Either I know the answer or the message is invalid.

Consider the message ACTION_INVALID in your if/else approach. You have to scan the whole message to check for ACTION_1, then scan the whole message again to check for ACTION_2. Even then, you have to consider the possibility of PRIVMSG or LOGIC_OK. With a state machine/lexer, the first character immediately eliminates two possibilities. To fully resolve the message, you only have to look at eight characters versus scanning the string again and again.

If you decide to go this route, tools like Ragel are useful for generating the state machine versus writing it by hand. There's even a port that generates JavaScript.


答:
Since the question has a functional-programming tag, we could use a sum type to reflect the two flavors of horses and pattern matching to disambiguate between them. For instance, in F# :

```<code>type Equine =
| Horse
| Unicorn of hornLength: float

module equines =

  let averageHornLength (equines : Equine list) =
    equines
    |> List.choose (fun x ->
      match x with
      | Unicorn u -> Some(u)
      | _ -> None)
    |> List.average

let herd = [ Horse ; Horse ; Unicorn(35.0) ; Horse ; Unicorn(50.0) ]

printfn "Average horn length in herd : %f" (equines.averageHornLength herd) // prints 42.5
</code>```

Over OOP, FP has the advantage of data/functions separation, which maybe saves you from the (unjustified ?) "guilty conscience" of violating the level of abstraction when downcasting to specific subtypes from a list of objects of a supertype.

In contrast with the OO solutions proposed in other answers, pattern matching also provides an easier extension point should another Horned species of Equine show up one day.

Title: Given a herd of horses, how do I find the average horn length of all unicorns?

Body:
The question above is an abstract example of a common problem I encounter in legacy code, or more accurately, problems resulting from previous attempts at solving this problem.

I can think of at least one .NET framework method that is intended to address this problem, like the Enumerable.OfType<T> method. But the fact that you ultimately end up interrogating an object's type at runtime doesn't sit right with me.

Beyond asking each horse "Are you a unicorn?" the following approaches also come to mind:

Throw an exception when an attempt is made to get the length of a non-unicorn's horn (exposes functionality not appropriate for each horse)

Return a default or magic value for the length of a non-unicorn's horn (requires default checks peppered throughout any code that wants to crunch horn stats on a group of horses that could all be non-unicorns)

Do away with inheritance and create a separate object on a horse that tells you if the horse is a unicorn or not (which is potentially pushing the same problem down a layer)

I have a feeling this is going to be best answered with a "non-answer." But how do you approach this problem and if it depends, what's the context around your decision?

I'd also be interested in any insights on whether this problem still exists in functional code (or maybe it only exists in functional languages that support mutability?)

This was flagged as a possible duplicate of the following question:
How to avoid downcasting?

The answer to that question assumes that one is in possession of a HornMeasurer by which all horn measurements must be made. But that's quite an imposition on a codebase that was formed under the egalitarian principle that everyone should be free to measure the horn of a horse.

Absent a HornMeasurer, the accepted answer's approach mirrors the exception-based approach listed above.

There's also been some confusion in the comments on whether horses and unicorns are both equines, or if a unicorn is a magical subspecies of horse. Both possibilities should be considered--perhaps one is preferable to the other?

Body:
Since the question has a functional-programming tag, we could use a sum type to reflect the two flavors of horses and pattern matching to disambiguate between them. For instance, in F# :

type Equine =
| Horse
| Unicorn of hornLength: float

module equines =

  let averageHornLength (equines : Equine list) =
    equines
    |> List.choose (fun x ->
      match x with
      | Unicorn u -> Some(u)
      | _ -> None)
    |> List.average

let herd = [ Horse ; Horse ; Unicorn(35.0) ; Horse ; Unicorn(50.0) ]

printfn "Average horn length in herd : %f" (equines.averageHornLength herd) // prints 42.5

Over OOP, FP has the advantage of data/functions separation, which maybe saves you from the (unjustified ?) "guilty conscience" of violating the level of abstraction when downcasting to specific subtypes from a list of objects of a supertype.

In contrast with the OO solutions proposed in other answers, pattern matching also provides an easier extension point should another Horned species of Equine show up one day.


答:
The big reason is probably that the default behaviour should "just work" in public repos. Rebasing history that other people have already merged is going to cause them trouble. I know you're talking about your private repo, but generally speaking git doesn't know or care what's private or public, so the chosen default is going to be the default for both.

I use git pull --rebase quite a lot in my private repo, but even there it has a potential disadvantage, which is that the history of my HEAD no longer reflects the tree as I actually worked on it.

So for a big example, suppose that I always run tests and ensure they pass before doing a commit. This has less relevance after I do a git pull --rebase, because it is no longer true that the tree at each of my commits has passed the tests. As long as the changes don't interfere in any way, and the code I pull has been tested, then presumably it would pass the tests, but we don't know because I never tried it. If continuous integration is an important part of your workflow, then any kind of rebase in a repo that's being CIed is troubling.

I don't really mind this, but it does bother some people: they'd prefer that their history in git reflects the code they actually worked on (or perhaps by the time they push it, a simplified version of the truth after some use of "fixup").

I don't know whether this issue in particular is the reason that Linus chose to merge rather than rebasing by default. There could be other disadvantages I haven't encountered. But since he's not shy of expressing his opinion in code, I'm pretty sure it comes down to what he thinks is a suitable workflow for people who don't want to think about it too much (and especially those working in a public rather than a private repo). Avoiding parallel lines in the pretty graph, in favour of a clean straight line that doesn't represent the parallel development as it happened, is probably not his top priority even though it is yours :-)


答:
If you read the git manpage for rebase, it says:

Rebasing (or any other form of rewriting) a branch that others have
  based work on is a bad idea: anyone downstream of it is forced to
  manually fix their history. This section explains how to do the fix
  from the downstream’s point of view. The real fix, however, would be
  to avoid rebasing the upstream in the first place.

I think that says it well enough as a reason not to use rebase at all, let alone automatically do it for every pull. Some people consider rebase to be harmful. Perhaps it should never have been put into git at all, as all it appears to do is prettify the history, something that shouldn't be necessary in any SCM whose single essential job is to preserve history.

When you say 'keeping ... the history clean',  think you're wrong. It may look nicer, but for a tool that is designed to keep history of revisions, it is much cleaner to keep every commit so you can see what happened. Sanitising the history afterwards is like polishing the patina away, making a rich antique look like a shiny repro :-)


问:
What is the significance of database host name while configuring database?
The name database host, how the name indicates "the server that hosts the database", should be the server ip, that hosts that database. I don't see any relation of it with the scripts that try to access it. But conversely, what I see the explanation mostly is :

"As long as the program ( php/.net scripts ) are on the same server as the database, which is the case with our servers, you will want to use 'localhost' as the database hostname.If you are needing to test an external connection, you can use the domain name (if pointed to our nameservers) or the server IP address"

It means, the scripts location decide the "database-host" ?

So, does that mean this terminology is confusing ? Also, why something called database-host needs to be configured ? What is it's importance ?

答:
It is not unusual for the database to be on one server and the scripts to be on another server.

In this situation, it is necessary for the script to know the name of the server that holds the database.  This name is sometimes known as the "database host name" because it is the name of the server that hosts the database.

Localhost is a special name that means "the name of the server the script is running on".  If you use this special name, then you don't need to worry if someone renames the server.  Likewise, your script will work fine on another server if the database is also on that other server.


答:
I had this idea of different write models being used in different
  bounded contexts, but both being the same aggregate instance (the same
  events).

The idea behind Bounded Contexts (BCs) is to have a very well defined purpose allowing developers to solve one well defined problem with no trade offs.

Using the same aggregate in two BCs makes no sense, by definition: different BCs have different purposes, and the same model serving different purposes will lead to accidental complexity, very quickly.

You can have BCs with very similar or overlapping data, but that's another story (and a deeper look at the data will show interesting details). Aggregates are formed around behaviour, not data.

Title: Event Sourcing and cross-context aggregate

Body:
I had this idea of different write models being used in different bounded contexts, but both being the same aggregate instance (the same events).

For example consider a User aggregate that is used in Administration and User contexts (that is the admin and the user-interface parts of the application). And the domain model says that the user (in User context) cannot do any action on itself (change email, change password, change address, whatever) unless he is logged in (which is the only action he is permitted to do if hes not logged in).

In administration context, however, the action does not need that user to be logged in (basically, an admin can change user's details on his behalf).

Can this be modeled with Event Sourcing as a single aggregate instance (same ID), but depending on the context a different object model would be built from the events? i.e. in admin context, the model does not verify the user is logged in, but in user context, the model does. This way the events would be shared between the contexts.

Is this a good idea? I can smell some issues but I am not completely sure.


答:
Assuming that in your architecture unicorns are a subspecies of horse and you encounter places where you get a collection of Horse where some of them may be Unicorns, I would personally go with the first method (.OfType<Unicorn>()...) because it is the most straightforward way of expressing your intention.  For anyone who comes along later (including yourself in 3 months), it is immediately obvious what you are trying to accomplish with that code: pick out the unicorns from among the horses.

The other methods you listed feel like just another way of asking the question "Are you a unicorn?".  For example, if you use some sort of exception based method of measuring horns, you might have code that would look something like this:

```<code>foreach (var horse in horses)
{
    try
    {
        var length = horse.MeasureHorn();
        //...
    }
    catch (NoHornException e)
    {
        continue;
    }
}
</code>```

So now the exception becomes the indicator that something is not a unicorn.  And now this isn't really an exceptional situation any more, but is part of normal program flow.  And using an exception instead of an if seems even dirtier than just doing the type check.

Lets say you go the magic value route for checking horns on horses.  So now your classes look something like this:

```<code>class Horse
{
    public double MeasureHorn() { return -1; }
    //...
}

class Unicorn : Horse
{
    public override double MeasureHorn { return _hornLength; }
    //...
}
</code>```

Now your Horse class has to know about the Unicorn class and have extra methods to deal with things it doesn't care about.  Now imagine you also have Pegasuss and Zebras that inherit from Horse.  Now Horse needs a Fly method as well as MeasureWings, CountStripes, etc.  And then the Unicorn class gets these methods too.  Now your classes all have to know about each other and you have polluted the classes with a bunch of methods that shouldn't be there just to avoid asking the type system "Is this a unicorn?"

So what about adding something to Horses to say if something is a Unicorn and handle all horn measuring?  Well, now you have to check for the existence of this object to know if something is a unicorn (which is just substituting one check for another).  It also muddies the waters a little bit in that now you may have a List<Horse> unicorns that really holds all unicorns, but the type system and debugger can't easily tell you that.  "But I know it is all unicorns" you say, "the name even says so."  Well, what if something was poorly named?  Or say, you wrote something with the assumption that it really would be all unicorns, but then requirements changed and now it might also have pegasi mixed in?  (Because nothing like this ever happens, especially in legacy software /sarcasm.)  Now the type system will happily put your pegasi in with your unicorns.  If your variable had been declared as List<Unicorn> the compiler (or the runtime environment) would have a fit if you tried to mix in pegasi or horses.

Finally, all these methods are just a replacement for the type system check.  Personally, I would rather not reinvent the wheel here and hope that my code works just as well as something that is built in and has been tested by thousands of other coders thousands of times.

Ultimately, the code needs to be understandable to you.  The computer will figure it out regardless of how you write it.  You are the one who has to debug it and be able to reason about it.  Make the choice that makes your job easier.  If for some reason, one of these other methods offers an advantage for you that outweighs clearer code in the couple spots it would show up, go for it.  But that depends on your code base.

Body:
Assuming that in your architecture unicorns are a subspecies of horse and you encounter places where you get a collection of Horse where some of them may be Unicorns, I would personally go with the first method (.OfType<Unicorn>()...) because it is the most straightforward way of expressing your intention.  For anyone who comes along later (including yourself in 3 months), it is immediately obvious what you are trying to accomplish with that code: pick out the unicorns from among the horses.

The other methods you listed feel like just another way of asking the question "Are you a unicorn?".  For example, if you use some sort of exception based method of measuring horns, you might have code that would look something like this:

foreach (var horse in horses)
{
    try
    {
        var length = horse.MeasureHorn();
        //...
    }
    catch (NoHornException e)
    {
        continue;
    }
}

So now the exception becomes the indicator that something is not a unicorn.  And now this isn't really an exceptional situation any more, but is part of normal program flow.  And using an exception instead of an if seems even dirtier than just doing the type check.

Lets say you go the magic value route for checking horns on horses.  So now your classes look something like this:

class Horse
{
    public double MeasureHorn() { return -1; }
    //...
}

class Unicorn : Horse
{
    public override double MeasureHorn { return _hornLength; }
    //...
}

Now your Horse class has to know about the Unicorn class and have extra methods to deal with things it doesn't care about.  Now imagine you also have Pegasuss and Zebras that inherit from Horse.  Now Horse needs a Fly method as well as MeasureWings, CountStripes, etc.  And then the Unicorn class gets these methods too.  Now your classes all have to know about each other and you have polluted the classes with a bunch of methods that shouldn't be there just to avoid asking the type system "Is this a unicorn?"

So what about adding something to Horses to say if something is a Unicorn and handle all horn measuring?  Well, now you have to check for the existence of this object to know if something is a unicorn (which is just substituting one check for another).  It also muddies the waters a little bit in that now you may have a List<Horse> unicorns that really holds all unicorns, but the type system and debugger can't easily tell you that.  "But I know it is all unicorns" you say, "the name even says so."  Well, what if something was poorly named?  Or say, you wrote something with the assumption that it really would be all unicorns, but then requirements changed and now it might also have pegasi mixed in?  (Because nothing like this ever happens, especially in legacy software /sarcasm.)  Now the type system will happily put your pegasi in with your unicorns.  If your variable had been declared as List<Unicorn> the compiler (or the runtime environment) would have a fit if you tried to mix in pegasi or horses.

Finally, all these methods are just a replacement for the type system check.  Personally, I would rather not reinvent the wheel here and hope that my code works just as well as something that is built in and has been tested by thousands of other coders thousands of times.

Ultimately, the code needs to be understandable to you.  The computer will figure it out regardless of how you write it.  You are the one who has to debug it and be able to reason about it.  Make the choice that makes your job easier.  If for some reason, one of these other methods offers an advantage for you that outweighs clearer code in the couple spots it would show up, go for it.  But that depends on your code base.


问:
What to legitimately charge clients for
I'm not talking about fixed price jobs, they're fairly straightforward. But I'm on about an hourly rate project, my question specifically relates to what to charge for.

If I have an IE/CSS issue that takes me an hour of scouring CSS to fix, is that chargeable? If I decide to use a really cool jQuery animation on their site but I need to get to grips with using it, do I charge them for the experimenting I do with the animation.

Do you charge customers for something that they ask for, that you don't know about and therefore need to spend time learning?

It's a grey area as far as I'm concerned and not clearly outlined in quotes (probably because not many clients would be happy to pay for your screw-up/learning).

What's the concensus on this?

答:
Your customers have to pay for your education and training one way or another, otherwise your business is not sustainable in the long run. The questions is whether time spent researching should be specified as hours on the bill, or rather should be covered by a higher hourly rate which finances non-billable hours spent on research and training.

I would say it depends on if the time spent researching is very specific for the project at hand (i.e. you wouldn't need to research this if it wasn't for this specific project), or if you expect the learning to be broadly applicable to many projects in the future.

Title: What to legitimately charge clients for


答:
While developing an application I was using an Encryption Library that had the same format {iterations}:{salt}:{PasswordHash}.  It had 2 main methods public string GetPasswordHash (string PlainTextPassword) and public bool VerifyPassword(string formatedPaswordHash, string PlainTextPassword).  Since GetPasswordHash returned and VerifyPassword expected a string in the {iterations}:{salt}:{PasswordHash} format that is how I stored it in the database.  It was then a simple retrieve hash from DB, Pass to Verify method and not have any additional code to deal with.

I could have broken it up into 3 columns (Iterations, Salt, PasswordHash) but then I would just have to combine them again to verify adding a step that could introduce a bug.  Since I would never manually update any of the parts I saw no benefit to storing them separate, especially when an attacker could break them apart or put them back together as easily as I could if they got access through a different bug.

Overall either way can be defended but I always tend to go with keeping things simple.  If the library spits out a string from one method and expects a string in the same format to be passed into another method, why bother changing the format for storage if we are not going to manually update any of the individual parts.

The only big no no of encryption is to not roll your own GetPasswordHash and VerifyPassword.  As long as those are strong, how you store things in the database becomes a secondary concern.

Title: ASP.NET storing encrypted & salted Password

Body:
I have a question about storing encrypted passwords in your database to help secure them. I have a class that encrypts the password passed in and returns a string. This string has 3 parts too it, all separated by a colon. The first part is the iteration, the 2nd part of it is the salt, and the third part of it is the encrypted password. Ex: "1000:{salt}:{encrypted password}".

My question is how am I suppose to store this? As of right now, I am storing the entire string in my database under the password column. Then when I go to check the passwords for a login, I retrieve that record, and I have a method in my class that parses it and verifies that the two passwords match. Is this a big 'no no?' I've read where some people store the salt in it's own column then pull that down when verifying a login. However, this class that I am using for the encryption will return a string like I showed above. Then it came with a method that I can just pass that entire string into it and it will parse it up and verify the passwords as a login.

I guess what I'm asking is, do I need to re-construct my class to separate the string ("{iteration}:{salt}:{encrypted password}"), or is storing that entire string in the database OK?


答:
In addition to the problems mentioned by other answers, it seems that you're mixing up concerns.

The fact that a user is logged in is an application-level concern, not a domain thing. It shouldn't be used to enforce an invariant inside an Aggregate.

Access and permission control is a cross-cutting concern that in most DDD systems is not baked in the domain but provided by a separate infrastructure module further out on the edge of the system.


问:
Should I bother learning about small or niche languages?
If you browse the code golf questions on StackExchange, you notice a ton of non-standard but real world (Eg not brain-f*ck) languages like F#, Scala, R, J and Clojure. Visiting their websites, some of the languages look interesting solving problems in whatever language your already using.

However there is coding in spare time, and coding for money. The closest thing we have to the truth on who uses a language is the TIOBE Index, which lists none of the above languages in the top 10-15. Which makes me wonder if I'll ever use them.

Should I even bother learning some of the small niche languages? It doesn't seem I would be making money, and some will probably fail anyway.

答:
I would learn any language that introduces me to concepts and paradigms I've never seen before. That's why I learned haskell and scheme - they introduced me to function programming and mostly-functional programming respectively. I wouldn't have cared less whether scheme and haskell were widely used, aside from how that would affect the available documentation and resources.

So basically, if a small niche language introduces you to new concepts and paradigms (especially those you can apply to other languages), then learn away!

Other reasons you may want to learn a 'small/niche' language:

The language allows you to solve a particular (type of) problem 'better' (faster, with a better solution, more portably, etc) than any other language

The language allows you to solve problems just as well as a popular language, but it has some cool features that you like (eg. clojure)

You want to help develop the language

ContentLicense: CC BY-SA 2.5


问:
What's the best way to manage list item sort order with Drag & Drop UI?
I have a list of Students that I should display to user on a web page in tabular format.

The items are stored in DB along with SortOrder information.

On the web page, user can rearrange the list order by dragging and dropping the items to their desired sort order, similar to this post.

Below is a screenshot of my test page.

In the above example, each row has sort order info attached to it. When I drop John Doe (Student Id 10) above the Student Id 1  row, the list order should now be: 2, 10, 1, 8, 11.

What's the optimistic (less resource hungry) way to store and update Sort Order information?

My only idea for now is, for every change in the list's sort order, every object's SortOrder value should be updated, which in my opinion is very resource hungry.

Just FYI: I might have at most 25 rows in my table.

答:
You are looking for a resource-friendly way to handling this but user-friendly perspective is also a must. I recommend individual requests after each reordered item. Each call allows for you to check if accepted or failed.

Failed responses will reset the view and displays an message to the end-user.

Accepted requests simple allows continued editing.

Alternatively, using a JSON object (@tom-squires) is a good idea to reduce HTTP overhead and server-side processing but ultimately requires more code to handle requests on the server and client side. If that is OK, passing the object to the server is most technically efficient. It also allows for a delay of a couple seconds to allow for multiple reorders before a single request, if you desire this.

Keep in mind, in order to provide a user with a feedback from failed requests you would have to parse a response JSON object from the server to figure out which item failed and reset the UI based on that.