问:
Approaches to Concurrency
I’ve been doing some research on the various approaches to concurrency, and I’ve ended up with the following taxonomy:

Manual thread based concurrency with locks

Asynchronous dispatch queues and callbacks as implemented in Apple’s libdispatch (GCD)

Asynchronous functions, blocking, and message passing as first class language constructs as implemented in Go

Functional concurrency where immutability makes parallelization near automatic as implemented in Haskell, Clojure, etc.

Obviously this isn’t a ‘pure’ taxonomy (since some elements are built on top of others), but it seems to correspond with the paradigms that people and languages adopt for writing real, useful code (i.e. not academic papers).

Assuming that my list is correct, I’m looking for a grizzled concurrency veteran to give me brief rundown on the pros and cons of each.

For example, most people tend to view threads as hard to manage, but appreciate that they’re a low level construct which can be highly performant if you can afford the dev time.  I’m looking for that level of detail on the other 3, and any relevant comparisons between them.

答:
The fact that some environments mix and match some approaches unnecessarily complicates the discussion, so it is best left out. Asynchronous functions are largely equivalent to message passing, (just a more convenient syntax,) so they do not need to be regarded as a separate category.

So, the four approaches that you listed can be restated as only three:

Synchronization with locks.

Message passing.

Functional concurrency.

Synchronization with locks tends to yield elegant designs that are expressed with a minimal number of lines of code.  The problem is, they are very hard to debug, and it is impossible to guarantee their correctness, because they are not testable. Your program may contain a timing-related defect which only manifests itself once in a million operations, meaning that you stand virtually no chance of discovering it during in-house testing, but once you ship your product to millions of users all over the globe, who are exercising it around the clock, the defect starts manifesting itself somewhere on the planet every few minutes or so, and that's when your nightmare begins. Untestability means that no matter what you do, at the moment that you ship your product you cannot be sure that it will not result in such a nightmare.

Message passing tends to require more code, but it is easier to debug, and most importantly, it is testable.  What this means is that once your system works, it can be expected to continue working without surprises.  Of course, this requires some discipline, for example making sure that you never pass anything mutable in your messages, but with proper tools this is something that can be enforced and not left to chance.

As for functional concurrency, let's see if someone who has actual experience with it can tell us some of its pros and cons.  One disadvantage that I know it has is that it is painful to debug, because it is difficult to set a breakpoint on a subexpression, or to single-step into a subexpression, though I would expect that this is a limitation of debuggers, and debuggers should really be getting better at this.

Title: Approaches to Concurrency


问:
how to evaluate own project
I am working on a open source project in pure C, that I have started some time ago, but only recently found time to add some features. I can clearly some weaknesses of my old design, so I am trying to refactor my old code. I have no idea however, how to evaluate properly my new code. Do you know about any techniques or tools for code evaluation? I am pretty good with object oriented design, but for about three years I had no contact with purely structural one. Therefore I don't have enough experience, to be able to discern between good and bad design choices.

答:
I think that when dealing with OOP one good idea to keep in mind is:

Keep class lightweight, i read some where this quoute: "Keep it simple stupid"

When facing some peace of code that you think might need flexibility. It's always good to give it some time and check for Design Patterns that may add some goodness to your solution (you wont regret it)

OwnerDisplayName: gruszczy

ContentLicense: CC BY-SA 2.5

Title: how to evaluate own project


问:
How can I handle errors in functions
I'm programming a web app using Perl and Dancer. The logic is not trivial and I want to separate the web page logic (inside Dancer routes) from the business logic that reads and writes from the database. The business logic is going to be stored in several modules the read and write in the database using DBIx::Class.

My question is: What is the best way to keep DB logic in the business Logic modules but still be able to send messages explaining the error to a Web Page and storing more details of the error in a log. I'd like a technique that works with nested functions.

I've been thinking about this, but I haven't found a clear winner. Possible options might be:

Catch all the exceptions inside the function and return array ref with the data. If an error happens, the result would be undef.

Catch all the exceptions inside the function and return a hash ref. If there hasn't been an error the key "ok" would be equal to 1. A return data would be like this:

```<code>return ({
        ok => 1,
        data => [
                {
                        name => 'Alfa',
                        year => 2014,
                },
                {
                        name => 'Beta',
                        year => 2015,
                },
        ],
});
</code>```

In an error case the return value might be something like this:

```<code>return ({
        ok => 0,
        err => 'bussines.deliveries.estimated_date.no_access_dhl',
        err_web => 'No access to DHL site',
});
</code>```

Catch exceptions in the web code using Try::Tiny;

Edit 1: Expanding my question as an answer to Umut Kahramankaptan:
I'm only starting with exceptions. In the past days I've read several web pages about expections in perl and how to handle them. What should trigger an exception? Is an exception only caused by an error (not being able to open a file, a division by 0 or a database not responding) or should it be triggered by other cause that blocks the execution of a function?

To explain the last question, I propose several cases:

A function executes several read and write operations against a database. If one of them fails it should trigger an exception.

Similarly to the previous one a function has to perform several read and write operations with a database. If it finds that it can't continue its sequence (due to some logic or value existing in the database), should in this case trigger the exception?

A simpler example could be a login function. If the username and passwords are correct, it should return several user data. What should happen if it fails? return undef? or trigger an exception?

答:
I would rather go with an OO style exception handling instead of trying to manage error codes.

Normally when you reach an exception, it should mean that your function is not able to work anymore and it should stop. So Option 1 is a waste of resources in a sense.

Option 2, will bring more problems in nested function calls. I think the article Object Oriented Exception Handling in Perl by Arun Udaya Shankar explains the situation very well.

With Option 3, once you catch an exception, you will be in a code block which is dedicated to handling that exception, where you can do logging, web logic error prompting one after another. And if you need to extend your code to include an additional form of communication, only place you will modify will be inside the catch statement.

In short, Try::Tiny to implement OO style exception handling is my preference .

Response to Edit 1: I hope while you were reading you also see how easily you can raise your own exceptions. Here is a page from c2.com that gives use of Exception Class. You can even throw exception depending on your own business logic.

The trick is to decide when your function needs to stop working and return to its caller scope with a message stating why it shouldn't execute anymore. So all your examples could be valid based on a design criteria. Even it is for .Net framework, the guideline from MSDN might give more clarity to you.

To finish with one of your examples. you have a login function which returns undef or user data. You will check if it is undef or not after you call this function. Instead in a try block you can execute the login function, and you will check if you catch the exception or not?

ContentLicense: CC BY-SA 3.0

Title: How can I handle errors in functions


问:
Should defects have story points in Scrum?
As far as I know, we use story points to measure the complexity of a story in Scrum.

But what about Defect? Should Defect have story points? If it does, what does it mean by completing these points, given that a Defect doesn't have business value like a story? Should we have something different from story points, for example, defect points?

答:
I've been on a couple of scrum teams where we've debated this, but ultimately come to the conclusion that defects should be story pointed like stories. The reason is the purpose we are using story points for - by measure the amount of story points completed each sprint we can get a rough metric for the team's capacity, how much work the team can complete in a sprint. </p>

<p>If a defect is significant enough that it will take development resources away from other stories, then it should be pointed and figured into your team's capacity for the sprint. I've always found that once the testing effort enters into the discussion, which often include writing missed unit/integration tests, it always ends up being significant enough work to point. If the bug is so ridiculously small and no real testing effort is required then you could always give it zero story points. </p>

OwnerDisplayName: Hackjustu

Body:
I've been on a couple of scrum teams where we've debated this, but ultimately come to the conclusion that defects should be story pointed like stories. The reason is the purpose we are using story points for - by measure the amount of story points completed each sprint we can get a rough metric for the team's capacity, how much work the team can complete in a sprint.

If a defect is significant enough that it will take development resources away from other stories, then it should be pointed and figured into your team's capacity for the sprint. I've always found that once the testing effort enters into the discussion, which often include writing missed unit/integration tests, it always ends up being significant enough work to point. If the bug is so ridiculously small and no real testing effort is required then you could always give it zero story points.


答:
I'd argue that a defect represents an earlier feature that has not been adequately completed.  Therefore the fixing of defects is not given story points.

If you apply story points to defects your burn-rate looks great "We completed 20 story points worth of features this sprint" - but, 10 of those points were bug-fixes so your real rate of progress is only 10 this sprint.

Now, I'm not advocating fixing every bug in the sprint immediately following discovery.  Some bugs just aren't that critical.  But don't "complete" a 5 point feature then the following sprint do another 5 points of bugfixes to it - it masks bad estimating, bad coding or both.

Title: Should defects have story points in Scrum?

Body:
As far as I know, we use story points to measure the complexity of a story in Scrum.

But what about Defect? Should Defect have story points? If it does, what does it mean by completing these points, given that a Defect doesn't have business value like a story? Should we have something different from story points, for example, defect points?


问:
What's the most used programming language in high performance computing? And why?
I believe a lot of Fortran is used in HPC, but not sure if that's only for legacy reasons.

Features of modern programming languages like garbage collection or run-time polymorphism are not suitable for HPC since speed matters so not sure where C# or Java or C++ come in.

Any thoughts?

答:
Fortran, for some good and some not-so-good reasons. For heavy math crunching, a good reason is there are extensive libraries (BLAS, LAPACK) of tried-and-true subroutines, all written in Fortran (though those can be called from C and C++).

A not-so-good reason is the supposed performance advantage of Fortran over C/C++. Optimizers are pretty good, and few people understand that the benefit of optimizing a piece of code is proportional to the percent of time it is busy, which in almost all code is almost zero.

Another not-so-good reason is a culture gap between CS and non-CS programmers.
Scientific programmers tend to be taught bad habits in Fortran, and to look down on the CS programmers and the bad habits they have been taught, and who look down on the former.


问:
Why is abstract Decorator class needed in this example?
Why do we need ShapeDecorator in this design? Why can't we just have RedShapeDecorator implement Shape directly and inherit from Shape?

答:
Indeed, one could leave out the ShapeDecorator, but this would worsen the design.

To derive RedShapeDecorator directly from Shape, one needs to move the decorates association (the reference to the "decorated shape object") from ShapeDecorator to another place. There are two possibilites for this:

Either it gets moved to RedShapeDecorator, which means one will have to repeat the decorating logic in every other decorator (BlueShapeDecorator, GreenShapeDecorator, ...), so a violation of the DRY principle.

Or it is moved it to the Shape class:

But that would mean every derivation of Shape is also a decorator of another Shape. However, Circle and Rectangle are no decorators, so this leads to a violation of the Liskov Substitution Principle, and to a violation of the SRP, since now a Shape is responsible for shape drawing and decorating other shapes.


问:
Benefit of non-volatile access to volatile objects being undefined?
This is a question about ISO C, which contains this sentence:

If an attempt is made to refer to an object defined with a volatile-qualified type through use of an lvalue with non-volatile-qualified type, the behavior is undefined.

In ISO9899:1999 (C99) this appears in 6.7.3 Type Qualifiers.

Firstly, if we entirely removed this sentence from the text, would the behavior still be undefined? That is to say, is this re-stating an existing lack of a requirement, or is it explicitly taking away a requirement that could otherwise be inferred from elsewhere in the text?  (Imagine that a sentence were added which says "whenever two values of type int are added together whose arithmetic sum is forty-two, the behavior is undefined". Without such a sentence, the requirement for such an addition to produce a value can (and is) inferred).

Secondly, what useful behaviors does this allow an implementation to provide? That is to say, can an implementation do something beneficial which breaks programs that access something volatile with a non-volatile lvalue, and which therefore depends on the above sentence?  Are there any implementations which do this, whatever it is?

For example, it is interesting and noteworthy that C programs can access const-qualified objects with non-const lvalues, just not store to them. Making the store behavior undefined is tangibly beneficial: implementations can place constants in read-only storage, and in some cases can propagate constants through a program image at translation time as if they were manifest constants.  Yet, mere non-const access is required to work. Not requiring non-const accesses to const objects to work would presumably be a permissiveness  which brings no benefits.  Yet, in the case of volatile, it is that strict: no non-volatile-qualified access is required to work. What is the benefit?

Can an object which is defined as volatile by the C program itself be endowed with useful properties which break if there take place any accesses whatsoever to that object through a non-volatile lvalue?

(Under "useful", I would specifically like to exclude diagnosis. Terminating the program upon detecting such an access, without a message, or with a message like "volatile accessed as non-volatile" doesn't count as useful; it serves only to enforce the lack of requirement.)

(Also, I'm not interested in memory mapped registers and such; strictly objects defined by the program in static, dynamic or automatic storage. Use of hardware registers is inherently nonportable.)

All I can think of is that a non-volatile access to a volatile object could retrieve a stale value, rather than value that was last stored
(properly, through the volatile lvalue).  This is an economic benefit in the following way: if a write occurs through, say, a volatile int lvalue, the compiler does not have to suspect that this has any effect on any plain int lvalue. This leads to better code generation in functions which work with  mixtures volatile and non-volatile objects of the same type:

```<code>volatile int global;

void foo(int *p)
{
   int x = *p, y;
   global++;
   y = *p;
}
</code>```

Here, the compiler doesn't have to consider that *p might be an alias for global, because that usage is not required to work according to ISO C.  Hence it can freely assume that the value of *p does not change between the two references. Both x and y receive to the same value, derived from a single access to *p.

If the aliasing were permitted, then the compiler would have to generate code to re-load *p on the second access, in order that it pick up the most recent value stored in global.

(If we remove volatile from the above program fragment, then this is in fact the case; it has to be at least suspected, if not confirmed. that *p may be an alias for global and so *p has to be re-inspected. Or else code has to be generated which compares the run-time value of p to the address of global and takes two different paths.)

However, we don't introduce volatile into programs to obtain this kind of obscure optimization benefit; it is used to defeat optimization. The restrict keyword can be used instead to allow the implementation to reason about lvalues not being aliased. It seems that the above cannot be the rationale.

答:
Non volatile access to a variable is faster as this access can be from local cache, but what you read can have changed else where hence is is dangerous to do this unless you know the value does not change during access.

In case there are 2 non volatile modifications how this is resolved is compiler and hardware dependent.

How these kind of modification are hardware dependent hence the most efficient way to handle it is to leave it undefined so the compiler can handle it the best possible way while letting you benefit for non volatile access to even volatile variables when you know what you are doing to reap speed ups.


答:
Imagine a hypothetical machine with a magic memory location 0xc0103 that, when written to, sets the brightness of a blinkenlight at the machine chassis to the stored value.

You might have a program like this.

```<code>volatile uint32_t * pindicator = (volaitle uint32_t *) 0xc0103;

for (;;)
  {
    uint32_t amount = do_some_work();
    *pindicator = amount;
  }
</code>```

It would make the light flash according to the amount of work currently handled by the system.  Even though the program never reads the value of *pindicator, the compiler is not allowed to optimize any store to it away because it is qualified as volatile. The compiler does not know what consequences a store to *pindicator might have but you know and you can write your program accordingly relying on the compiler not getting into your way.

However, if we were to access it via a non-volatile pointer, the compiler would be free to optimize away any store that it can prove has no visible side effect to the program under the as-if rule. In this simple example, the worst this could do is make the light flash in erratic ways or – more likely – stay forever dark. But the C standard doesn't know about blinkenlights and 0xc0103. It cannot say what consequences would be permissible for accessing the variable though a non-volatile pointer. Another variable might refer to a “heartbeat” register that must be incremented at least once per second and failure to do so might cause a safety mechanism to set off a fuse that makes the device explode. So, the standards way of saying “anything or nothing might happen” is to say: “the behavior is undefined”.

Title: Benefit of non-volatile access to volatile objects being undefined?

Body:
This is a question about ISO C, which contains this sentence:

If an attempt is made to refer to an object defined with a volatile-qualified type through use of an lvalue with non-volatile-qualified type, the behavior is undefined.

In ISO9899:1999 (C99) this appears in 6.7.3 Type Qualifiers.

Firstly, if we entirely removed this sentence from the text, would the behavior still be undefined? That is to say, is this re-stating an existing lack of a requirement, or is it explicitly taking away a requirement that could otherwise be inferred from elsewhere in the text?  (Imagine that a sentence were added which says "whenever two values of type int are added together whose arithmetic sum is forty-two, the behavior is undefined". Without such a sentence, the requirement for such an addition to produce a value can (and is) inferred).

Secondly, what useful behaviors does this allow an implementation to provide? That is to say, can an implementation do something beneficial which breaks programs that access something volatile with a non-volatile lvalue, and which therefore depends on the above sentence?  Are there any implementations which do this, whatever it is?

For example, it is interesting and noteworthy that C programs can access const-qualified objects with non-const lvalues, just not store to them. Making the store behavior undefined is tangibly beneficial: implementations can place constants in read-only storage, and in some cases can propagate constants through a program image at translation time as if they were manifest constants.  Yet, mere non-const access is required to work. Not requiring non-const accesses to const objects to work would presumably be a permissiveness  which brings no benefits.  Yet, in the case of volatile, it is that strict: no non-volatile-qualified access is required to work. What is the benefit?

Can an object which is defined as volatile by the C program itself be endowed with useful properties which break if there take place any accesses whatsoever to that object through a non-volatile lvalue?

(Under "useful", I would specifically like to exclude diagnosis. Terminating the program upon detecting such an access, without a message, or with a message like "volatile accessed as non-volatile" doesn't count as useful; it serves only to enforce the lack of requirement.)

(Also, I'm not interested in memory mapped registers and such; strictly objects defined by the program in static, dynamic or automatic storage. Use of hardware registers is inherently nonportable.)

All I can think of is that a non-volatile access to a volatile object could retrieve a stale value, rather than value that was last stored
(properly, through the volatile lvalue).  This is an economic benefit in the following way: if a write occurs through, say, a volatile int lvalue, the compiler does not have to suspect that this has any effect on any plain int lvalue. This leads to better code generation in functions which work with  mixtures volatile and non-volatile objects of the same type:

```<code>volatile int global;

void foo(int *p)
{
   int x = *p, y;
   global++;
   y = *p;
}
</code>```

Here, the compiler doesn't have to consider that *p might be an alias for global, because that usage is not required to work according to ISO C.  Hence it can freely assume that the value of *p does not change between the two references. Both x and y receive to the same value, derived from a single access to *p.

If the aliasing were permitted, then the compiler would have to generate code to re-load *p on the second access, in order that it pick up the most recent value stored in global.

(If we remove volatile from the above program fragment, then this is in fact the case; it has to be at least suspected, if not confirmed. that *p may be an alias for global and so *p has to be re-inspected. Or else code has to be generated which compares the run-time value of p to the address of global and takes two different paths.)

However, we don't introduce volatile into programs to obtain this kind of obscure optimization benefit; it is used to defeat optimization. The restrict keyword can be used instead to allow the implementation to reason about lvalues not being aliased. It seems that the above cannot be the rationale.

Body:
Imagine a hypothetical machine with a magic memory location 0xc0103 that, when written to, sets the brightness of a blinkenlight at the machine chassis to the stored value.

You might have a program like this.

volatile uint32_t * pindicator = (volaitle uint32_t *) 0xc0103;

for (;;)
  {
    uint32_t amount = do_some_work();
    *pindicator = amount;
  }

It would make the light flash according to the amount of work currently handled by the system.  Even though the program never reads the value of *pindicator, the compiler is not allowed to optimize any store to it away because it is qualified as volatile. The compiler does not know what consequences a store to *pindicator might have but you know and you can write your program accordingly relying on the compiler not getting into your way.

However, if we were to access it via a non-volatile pointer, the compiler would be free to optimize away any store that it can prove has no visible side effect to the program under the as-if rule. In this simple example, the worst this could do is make the light flash in erratic ways or – more likely – stay forever dark. But the C standard doesn't know about blinkenlights and 0xc0103. It cannot say what consequences would be permissible for accessing the variable though a non-volatile pointer. Another variable might refer to a “heartbeat” register that must be incremented at least once per second and failure to do so might cause a safety mechanism to set off a fuse that makes the device explode. So, the standards way of saying “anything or nothing might happen” is to say: “the behavior is undefined”.


答:
You have to assign story points, otherwise you have no way to accurately measure the teams velocity.

If you get through 50 points in a sprint, but you are working on 10 points worth of bugs, your velocity would only be 40. How would you account for this in the next sprint planning?


问:
Is there anything that can be done with recursion that can't be done with loops?
There are times where using recursion is better than using a loop, and times where using a loop is better than using recursion. Choosing the "right" one can save resources and/or result in fewer lines of code.

Are there any cases where a task can only be done using recursion, rather than a loop?

答:
Yes. There are several common tasks that are easy to accomplish using recursion but impossible with just loops:

Causing stack overflows.

Totally confusing beginner programmers.

Creating fast looking functions that actually are O(n^n).


问:
Is it always better to use __construct() in CodeIgniter's Models and Views, even if it's not needed?
Sometimes we have Models and Controllers where the function __construct() just doesn't do anything, but is sitting on the top of all the methods in CodeIgniter's models and controllers. A lot of CodeIgniter books teach it that way.
Following is the example of a __construct(), where it isn't doing anything, and if you remove it the application doesn't break.

```<code><?php
defined('BASEPATH') OR exit('No direct script access allowed');

class Register_model extends CI_Model {

  public function __construct()
  {
    parent::__construct();
  }

  public function register_user($data)
  {
    return ($this->db->insert('users', $data)) ? true : false;
  }

}

/* End of file Register_model.php */
/* Location: ./application/models/Register_model.php */
</code>```

If we instead use it like as follow (without __construct()), the application won't break.

```<code><?php
defined('BASEPATH') OR exit('No direct script access allowed');

class Register_model extends CI_Model {

  public function register_user($data)
  {
    return ($this->db->insert('users', $data)) ? true : false;
  }

}

/* End of file Register_model.php */
/* Location: ./application/models/Register_model.php */
</code>```

So what is better (or good practice) in this case, to use a __construct(), or not to use it?

答:
In your example, the constructor is just calling parent constructor and isn't adding anything to it.
e.g.,

It isn't initializing any helpers or libraries which you need in other methods of the class.

You aren't adding any code which you need to be executed during the time this class loads (or the class adds to the super object in case of codeigniter).

So in this case you don't need to add a __constructor inside the model or controller unless one of the above two conditions meet.


答: Do Test-Driven Development, not only it will help you to test everything is right and give your open-source audience a sense of stability, but also force you to write modular, better architected and more refined code.</p>

Title: how to evaluate own project

Body: I am working on a open source project in pure C, that I have started some time ago, but only recently found time to add some features. I can clearly some weaknesses of my old design, so I am trying to refactor my old code. I have no idea however, how to evaluate properly my new code. Do you know about any techniques or tools for code evaluation? I am pretty good with object oriented design, but for about three years I had no contact with purely structural one. Therefore I don't have enough experience, to be able to discern between good and bad design choices.


问:
Are there any compilers that attempt to fix syntax errors on their own?
I heard a while back that there used to be a compiler that attempted to fix syntax errors by analyzing context and inferring what was intended.

Does such a compiler really exist? Obviously it has little practical value, but would be very interesting to play with and learn from.

答: Such a compiler would simply be a relaxed, non-standard implementation of whatever language it's compiling.</p>


答:
Quite simply, non-volatile access to volatile variables must be either defined or undefined. So if you want to remove the section that makes it undefined, you must make it defined. I'd be curious how you would do that. For example, just define the behaviour of

```<code>int* p = "address of variable which may or may not be volatile";
*p = 1;
</code>```

in a way that is efficient when *p is not volatile, and defined when *p is volatile. And remember that most uses of pointers fall into this category.

Body:
Quite simply, non-volatile access to volatile variables must be either defined or undefined. So if you want to remove the section that makes it undefined, you must make it defined. I'd be curious how you would do that. For example, just define the behaviour of

int* p = "address of variable which may or may not be volatile";
*p = 1;

in a way that is efficient when *p is not volatile, and defined when *p is volatile. And remember that most uses of pointers fall into this category.


答:
If you are only interested in "portable C," then you will find the keyword volatile to serve little to no use, and thus the requirements will seem unusual.  It's entire purpose in the language is to permit compilers to expose memory mapped hardware.  It gets some minimal life if you add a [non-portable] threading library into the mix, but at its core, it's job is to do implementation specific behaviors.  So much so that the spec states:

An object that has volatile-qualified type may be modified in ways unknown to the
  implementation or have other unknown side effects. ... What constitutes an access to an object that
  has volatile-qualified type is implementation-defined. (ISO/IEC 9899:TC2 6.7.3.6)

The value in denying access to a volatile object via non-volatile means becomes apparent in that line.  The spec permits "volatile" operations to be implemented differently than "non-volatile" operations.  As a trivial example, a volatile write might look up a mapped register in a mapping, and then write to the register instead, while the non-volatile write simply writes to that memory.  That example might be a little unrealistic, but the developers of C went to great lengths to support writing software in C on many platforms, and other than adding one line into the spec (the one you mentioned), it literally cost them nothing to add this support to the language.  In doing so, all sorts of exotic memory mapping situations are made much simpler.

On modern x86 machines, there's probably no reason for the compiler to take advantage of this.  In fact, I would not be surprised if the x86 compilers "undefined behavior" in this case is to just do what you think should have been done.  However, on more anemic platforms, the ability to not have to worry about the case where a developer access a volatile via a non-volatile lvalue may be a substantial difference in compiler code generation.


问:
Deleting subtrees in hierarchical agreggates
I am working on a file-system-like application where I use CQRS/event-sourcing to handle the state of folders and files (creating, moving, renaming, etc). Each node (folder or file) is represented by a single aggregate (as they are standalone unit with own ID). Now I am about to implement deleting of the nodes, where the system is capable, of course, deleting a whole subtree of nodes (= delete a folder containing other folders and files).

Now I quite don't know how to handle this in CQRS style because the command, as I learned, should operate on a single aggregate.

One idea I had is to create a saga which would be created by FolderDeleteStarted event and the responsibility of the saga would be to create commands for each of the child nodes, resulting in cascading creation of sagas for each child folder. Saga would ensure to delete the parent folder once all the commands for child folders would be finished, so it would be blocking. Saga would run in separate thread so the initial command for deleting folder will be still async.

However I don't really like the idea of cascading sagas.

I am new to CQRS and still learning the basics. I would love to know how you would solve similar situation.

答:
Two approaches:

The easy way: Command handler deletes children before parent. Then parent. Then confirm deletion.

Low (and fixed) latency for deletes: Use a journal. Command handler adds entries in the journal (one for each child) and deletes parent. Then, an asynchronous task, for each entry in the journal:

Get entry (a parent)

Add entries in the journal (one for each child)

Delete entry


问:
Background Threads in Horizontally Scaled Application
I have what I believe is a fairly common situation these days: I have a webapp that scales horizontally across multiple machines in order to serve greater load. This particular application is written in Java.

On this same webapp, I find that I have a need to run a background process in this webapp periodically. However, this process executes requests against another service, and I don't believe it would be safe to have multiple invocations of this process going at once.

It would be easiest to just get a new machine that runs these background processes by itself. However, company policies make it difficult to get new machines, so I'm trying to investigate other options in case this isn't possible. This means I'm trying to figure out how to make just one machine at a time run this background process at once. I've thought about some of the following ways:

Figure out how to make one machine the "leader" and be the only one to execute these periodic background tasks. This is complicated by the fact that I'm running on an AWS auto-scale group, so this leader could be killed at any time, so I'm stuck with needing to do leader election on my own.

Establishing a mutex of some kind that each instance must grab before it executes. I've thought about using an in-memory data grid like Hazelcast for this, but that seems a bit heavyweight to set up and use just for this.

What are some good ways of achieving my goal of running this background process in my webapp and making sure it only runs once?

答: It looks like you need a scheduler. These typically allow periodical starting of jobs, and will also allow configuration to make sure the job is only started once. We use the Quartz scheduler, but there are many more options. Also, if you run on a recent JEE application server, these might provide this functionality natively, see JSR 352 for the description of the JEE 7 standard. This might also provide the required functionality. </p>


问:
Exception Handling in Java web application
I know exception handling is a topic often discussed in the world of Java. I've read a few threads on here and SO as well.

https://stackoverflow.com/questions/2169339/exception-handling-in-a-java-web-application

I find myself identifying with principles such as Do not suppress or ignore exceptions, Do not catch top-level exceptions, and avoid anti-patterns like Log and Throw.

http://today.java.net/article/2006/04/04/exception-handling-antipatterns#throwingException
http://www.onjava.com/pub/a/onjava/2003/11/19/exceptions.html?page=2

Question #1, is there a different standard of practice when it comes to web applications? For example, is it a legitimate use case to catch Exception for logging purposes and then throw it up the stack?

```<code>function void xyz() throws Exception {
    try {
    } catch (Exception e) {
        LOG.error("ERROR: " + e);
        throw e;
    }
}

function void otherFuncA() throws Exception {
    xyz();
}

function void otherFuncB() {
    try {
        xyz();
    } catch (Exception e) {
        LOG.error("ERROR: " + e);
        throw e;
    }
}
</code>```

I am finding it very hard to accept as a practice because it is generating so much unnecessary code (see otherFuncA and otherFuncB), affecting the function calls all through the different layers (DAO, Service, Controller, etc.)

Question #2, do I lose information about an error (let's say what caused a NullPointerException) if I let unexpected, unchecked exceptions float up to the Controller layer and then, and ONLY then, handle it there (catch Exception and throw stack trace)? As opposed to logging immediately, and re-throwing (seen above).

Of course, I will still check for specific exception types where applicable.

I seem to find the stack trace is often a better indicator of what went wrong vs. which specific field was causing an error...  I am really interested in input from more experienced developers and what best practices/reasoning guide your exception handling.

答:
A very good use-case for the Log and Throw pattern is when your framework passes the exception to the front-end. This can happen for instance with web applications that handle errors locally, but also in client server systems where you throw an exception and have the exception be encapsulated and sent to the client (JAX-WS will do this, and send an error response containing the exception).

But normally you also want to have the exception in the log of the originating server. And this pattern provides this exact behaviour.

Note that - when possible - you want the Log and Throw pattern to be part of an interceptor like solution, so that you don't have to sprinkle your code with this pattern. But sometimes that is just not convenient or possible.


问:
Why Garbage Collection if smart pointers are there
These days, so many languages are garbage collected. It is even available for C++ by third parties. But C++ has RAII and smart pointers. So what's the point of using garbage collection? Is it doing something extra?

And in other languages like C#, if all the references are treated as smart pointers(keeping RAII aside), by specification and by implementation, will there still be any need of garbage collectors? If no, then why is this not so?

答:
Garbage collection can be more efficient - it basically 'batches up' the overhead of the memory management and does it all at once. In general this will result in less overall CPU being expended on memory de-allocation, but it means that you'll have a big burst of de-allocation activity at some point. If the GC isn't properly designed this can become visible to the user as a 'pause' while the GC tries to de-allocate memory. Most modern GCs are very good at keeping this invisible to the user except under the most adverse conditions.

Smart pointers (or any reference counting scheme) have the advantage that they happen exactly when you'd expect from looking at the code (smart pointer goes out of scope, thing gets deleted). You get little bursts of de-allocation here and there. You overall may use more CPU time on de-allocation, but since it's spread out over all of the things happening in your program, it's less likely (baring de-allocate of some monster data structure) to become visible to your user.

If you are doing something where responsiveness matters, I would suggest that smart pointers/ref counting let you know exactly when things are happening, so you can know while coding what's likely to become visible to your users. In a GC setting you have only the most ephemeral of control over the garbage collector and simply have to try to work around the thing.

On the other hand, if overall throughput is your goal, a GC based system may be a much better choice, as it minimizes the resources needed to do memory management.

Cycles: I do not consider the problem of cycles to be a significant one. In a system where you have smart pointers, you tend toward data structures that don't have cycles, or you are simply careful about how you let go of such things. If necessary, keeper objects that know how to break the cycles in the owned objects can be used in order to automatically insure proper destruction. In some realms of programming this may be important, but for most day-to-day work, it's irrelevant.


答:
The classical answer is "no", but allow me to elaborate on why I think "yes" is a better answer.

Before going on, let's get something out of the way: from a computability & complexity standpoint:

The answer is "no" if you are permitted to have an auxiliary stack when looping.

The answer is "yes" if you are not permitted any extra data when looping.

Okay, now, let's put one foot in practice-land, keeping the other foot in theory-land.

The call stack is a control structure, whereas a manual stack is a data structure.
Control and data are not equal concepts, but they're equivalent in the sense that they can be reduced to each other (or "emulated" via one another) from a computability or complexity standpoint.

When might this distinction matter?  When you're working with real-world tools. Here's an example:

Say you're implementing N-way mergesort. You might have a for loop that goes through each of the N segments, calls mergesort on them separately, then merges the results.

How might you parallelize this with OpenMP?

In the recursive realm, it's extremely simple:
just put #pragma omp parallel for around your loop that goes from 1 to N, and you're done.
In the iterative realm, you can't do this. You have to spawn threads manually and pass them the appropriate data manually so that they know what to do.

On the other hand, there are others tools (such as automatic vectorizers, e.g. #pragma vector) that work with loops but are utterly useless with recursion.

Point being, just because you can prove the two paradigms are equivalent mathematically, that doesn't mean they are equal in practice.
A problem that might be trivial to automate in one paradigm (say, loop parallelization) might be much more difficult to solve in the other paradigm.

i.e.: Tools for one paradigm do not automatically translate to other paradigms.

Consequently, if you require a tool to solve a problem, chances are that the tool will only work with one particular kind of approach, and consequently you will fail to solve the problem with a different approach, even if you can mathematically prove the problem can be solved either way.

Title: Is there anything that can be done with recursion that can't be done with loops?

Body:
There are times where using recursion is better than using a loop, and times where using a loop is better than using recursion. Choosing the "right" one can save resources and/or result in fewer lines of code.

Are there any cases where a task can only be done using recursion, rather than a loop?


问:
Best way to accelerate data access to two data warehouses?
I am embarking on a business intelligence project which will require abstracting access to two existing data warehouses. I need to design an application architecture to allow self-service business intelligence to join up the data and provide a single view over the two existing warehouses. I have come up with something like this:

I am struggling with the virtualization/caching piece and wondering if there are any enterprise design patterns to solve my problem. Would an architecture like this work to abstract star schemas in data warehouses? I'm looking at products such as Red Hat JBoss Data Virtualization and Red Hat JBoss Data Grid (amongst others).

We are not using Hibernate currently and my understanding of Data Grids is that they are key-value stores, or object stores and therefore unsuitable for caching a relational model. I should also mention that we are keen to use vendor products for the Self-Service Dashboard part, but we may end up doing some custom-build in this area if vendors can't offer us everything we want.

答:
There isn't a huge amount of detail about what you're trying to achieve here but from what you've described, it sounds like you could do with a data mart to abstract away the main repositories and expose a minimal subset of data to service the application.

Even if you could design a decent application layer, you're likely to hit performance issues due to load on one (or both) of the repository databases. The benefit of the mart approach is that the DB the application talks to is highly performant. Updates take place on the repository DBs behind the scenes and are pushed thru on whatever basis you see fit.

An additional benefit that you also only have one DB vendor to consider in your application layer.


问:
Would UTF-8 be able to support the inclusion of a vast alien language with millions of new characters?
In the event an alien invasion occurred and we were forced to support their languages in all of our existing computer systems, is UTF-8 designed in a way to allow for their possibly vast amount of characters?

(Of course, we do not know if aliens actually have languages, if or how they communicate, but for the sake of the argument, please just imagine they do.)

For instance, if their language consisted of millions of newfound glyphs, symbols, and/or combining characters, could UTF-8 theoretically be expanded in a non-breaking way to include these new glyphs and still support all existing software?

I'm more interested in if the glyphs far outgrew the current size limitations and required more bytes to represent a single glyph. In the event UTF-8 could not be expanded, does that prove that the single advantage over UTF-32 is simply size of lower characters?

答:
RFC3629 restricts UTF-8 to a maximum of four bytes per character, with a maximum value of 0x10FFFF, allowing a maximum of 1,112,064 code points. Obviously this restriction could be removed and the standard extended, but this would prove a breaking change for existing code that works to that limit.

From a data-file point of view, this wouldn't be a breaking change as the standard works on the basis that if the most significant bit (MSB) of each byte is set, then the next byte is part of the encoding. Even before RFC3629, the standard was limited to 31 bits, leaving the MSB of the fourth byte unset.

Extending the standard beyond 0x10FFFF would break UTF-8's partial data compatibility with UTF-16 though.


问:
What would you consider best practice workflow tools for web application (PHP) development?
I'm really hoping somebody with more experience can edit the question as per my examples of answers:

using version control

test driven development

debugging code (xdebug for php)

use of UML diagrams

use of OOP for maintainable, reusable code

use of frameworks (like Zend Framework for php) for rapid application development

Anything else or an elaboration of what I mentioned above?

Basically, I'm in the middle of forming a team of developers (I'm a developer myself) and I'd like some advice on how professional programmers/designers etc should work together and what standards/paradigms they should use.

Also, if anybody has any books or links on the subject I'd welcome that!

I did find this which I guess satisfies what I'm looking for, or at least part thereof:

http://www.ibm.com/developerworks/websphere/library/techarticles/0306_perks/perks2.html

答:
I'd recommend looking at Bazaar for version control. Compared to Git it has the major advantage that it is actually easy to use and install on Windows, Mac OS and Linux. Also the bzr commands are very similiar to it's svn counterparts, therefore somebody who has worked with Subversion before can easily use Bazaar without to much of a learning curve. I'm looking at you Git.

Apart from that I am a strong believer in don't force anything on your developers. That beeing said let them use the IDE, operating system and so on that they prefer.

Apart from that I strongly recommend you do wirte tests for all your code, no matter how tedious that is.

The decision for or against a framework imho isn't something you can do based on recommendations made here. I suggest you list the ones that look promising to you based on their features and then write a small test app in every one of them. (Write the same one each time.)


问:
Using symbols instead of strings in conditions
I usually have if/else conditions which involves comparing values with a constant string.

Is it really advantageous to use symbols in such cases or use string.
For eg.

```<code>if status == 'submitted'
  ...
elsif status.try(:to_sym) == :open
  ...
</code>```

Also what are the affects on memory consumption when this condition is in an instance method or class method or global method. Is the string takes up memory every time it's called ?

答:
In Ruby, symbols and string are the same with only one difference. Symbols are inmutable. here

Because of the strings are mutable, it also has a performance impact.

But IMHO, I think the most important reason to use a symbol instead of a string can be found in this article:

```<code>"... to use symbols every time you need internal identifiers. ..."
</code>```

And in your particular case, you have indeed an internal identifier for status. Future developers of your code will understand that you are refering to a particular state and not to the representation you have at the moment.

Body:
In Ruby, symbols and string are the same with only one difference. Symbols are inmutable. here

Because of the strings are mutable, it also has a performance impact.

But IMHO, I think the most important reason to use a symbol instead of a string can be found in this article:

"... to use symbols every time you need internal identifiers. ..."

And in your particular case, you have indeed an internal identifier for status. Future developers of your code will understand that you are refering to a particular state and not to the representation you have at the moment.


答:
The Unicode standard has lots of space to spare. The Unicode codepoints are organized in “planes” and “blocks”. Of 17 total planes, there are 11 currently unassigned. Each plane holds 65,536 characters, so there's realistically half a million codepoints to spare for an alien language (unless we fill all of that up with more emoji before first contact). As of Unicode 8.0, only 120,737 code points have been assigned in total (roughly 10% of the total capacity), with roughly the same amount being unassigned but reserved for private, application-specific use. In total, 974,530 codepoints are unassigned.

UTF-8 is a specific encoding of Unicode, and is currently limited to four octets (bytes) per code point, which matches the limitations of UTF-16. In particular, UTF-16 only supports 17 planes. Previously, UTF-8 supported 6 octets per codepoint, and was designed to support 32768 planes. In principle this 4 byte limit could be lifted, but that would break the current organization structure of Unicode, and would require UTF-16 to be phased out – unlikely to happen in the near future considering how entrenched it is in certain operating systems and programming languages.

The only reason UTF-16 is still in common use is that it's an extension to the flawed UCS-2 encoding which only supported a single Unicode plane. It otherwise inherits undesirable properties from both UTF-8 (not fixed-width) and UTF-32 (not ASCII compatible, waste of space for common data), and requires byte order marks to declare endianness. Given that despite these problems UTF-16 is still popular, I'm not too optimistic that this is going to change by itself very soon. Hopefully, our new Alien Overlords will see this impediment to Their rule, and in Their wisdom banish UTF-16 from the face of the earth.

Title: Would UTF-8 be able to support the inclusion of a vast alien language with millions of new characters?

Body:
In the event an alien invasion occurred and we were forced to support their languages in all of our existing computer systems, is UTF-8 designed in a way to allow for their possibly vast amount of characters?

(Of course, we do not know if aliens actually have languages, if or how they communicate, but for the sake of the argument, please just imagine they do.)

For instance, if their language consisted of millions of newfound glyphs, symbols, and/or combining characters, could UTF-8 theoretically be expanded in a non-breaking way to include these new glyphs and still support all existing software?

I'm more interested in if the glyphs far outgrew the current size limitations and required more bytes to represent a single glyph. In the event UTF-8 could not be expanded, does that prove that the single advantage over UTF-32 is simply size of lower characters?


问:
Enterprise Architecture: Where to put persistence/dbContext management?
I'm working on architecting a somewhat enterprise-level solution and have a question about how to best handle the persistence details.

My overall setup is that there's a core set of business logic/objects, as well as a number of isolated components that rely on the core logic, but never on other components.  Sitting on top of this component/core business logic layer is application logic and presentation stuff.  Underneath these two layers is infrastructure and persistence.

note: currently I'm working on the Core specifically, haven't gotten into Components yet

My Current Persistence Implementation:

Currently (and incorrectly, I suspect), my Core project has a reference to the Persistence project, and a Core model (Orders, let's say) has an IOrderRepository field.  When the Order is instantiated, I can pull up the info, I can save it, etc.

My Current Concern:

1) My core domain objects are not following SRP because they essentially have persistence details attached to them (despite those details being interface details rather than implementation details, it's still there).

2) Upon reading a good article on managing EF's DbContext (which can be considered in a more generic context form than EF specifically) (ref: http://mehdi.me/ambient-dbcontext-in-ef6/) - I've realized that it makes little sense to loading a persistence context when a domain object is loaded, because it's not at all representative to the context in which the objects are used (e.g., the objects could be loaded under any number of contexts) (note also that I haven't forgotten about Aggregates, but not included here for simplicity because the end result is the same, I think).

What Seems Better:

It "feels" better to me that the persistence context (and thus the DbContext and thus the repositories) should be handled under the general context of any specific business task rather than simply on a business object, which, in itself, has no true context despite the fact they do encapsulate various behaviors (is this statement correct??).

Considering that a persistence context/dbContext is can essentially be considered a transaction, it thus seems more correct in an architecture sense that such persistence context should in fact be included where these driving actions begin, as this is the context in which they essentially operate.

What I Can't Seem to Grasp:

How do I set this up so the persistence context is closer to the context in which it's used (which feels right, but correct me if I'm wrong), while at the same time fully separating it from the domain objects so those latter maintain their required SRP (e.g., so I don't have Save() and Load() methods on the domain objects, no matter how well abstracted away they are)?

I appreciate any input on how to best keep this from turning into a tangled-up mess.  Thanks

答:
Taking a few hints from the following two posts (apparently SE's search abilities are better than mine...), I've come up with something that seems to fit well.

Are Persistence-Ignorant objects able to implement lazy loading?

Where to validate domain model rules that depend on database content?

It appears what I'm looking for are ObjectProviders.  Essentially, these live outside the scope of the domain objects themselves and are tied to a particular application layer piece.  Their role is to instantiate the domain objects as required and manage the persistence of them (though, the persistence implementation itself still lives in the bottom persistence layer).

So, the application layers will not interact directly with the domain object POCOs themselves, but will instead generate them through these providers.

Having the providers be per-application section allows me to implement the details as required per context (e.g., application A might only need to load X part of the object graph, where application B might need X and Y, etc.)

The diagram below isn't the prettiest but describes the layout well enough:

Now the domain objects themselves are completely freed of the persistence layer and the persistence management itself is closer to the context in which it's used (while the persistence implementation remains isolated in it's own layer).

This likely isn't 100% perfect: I'm sure there's further details I'll have to smooth out, but from a 30kft view, it does seem much better.

With that said, I'm still open to exploring other ideas, so if you have one feel free to spit it out.  Thanks


答:
Strings and Symbols are fundamentally different. String is a datatype for text. Symbols are a datatype for unique identifiers. You should use the one which best models your problem domain.

There may or may not be performance differences, but as always, you should only start thinking about exchanging strings for symbols, if all of the following are true:

you have a hard performance requirement

you have a precise definition of that hard performance requirement

you have an exact number to hit for that hard performance requirement

you have a statistically significant, representative, repeatable, automated benchmark for that performance requirement

running that benchmark shows that you don't meet your performance requirement

you cannot switch on more aggressive optimizations

you cannot switch to a faster Ruby implementation

you cannot buy faster hardware

you cannot buy bigger hardware

you cannot buy more hardware

you cannot tweak the existing architecture

you cannot change to a more performant architecture

you cannot tweak the existing design

you cannot change to a more performant design

you cannot tweak the existing algorithm

you cannot change to a more performant algorithm

you have statistically significant, representative profiling data that shows that string comparisons are indeed the most pressing bottleneck in your application

Then, and only then does it make sense to think about such micro-optimizations.

Note that with Ruby moving towards immutable strings and string deduplication on the one hand, and garbage-collectable symbols on the other hand, the performance differences are likely to get smaller. It really is all about semantics: if it's text, use a string, if it's a unique name, use a symbol.

Title: Using symbols instead of strings in conditions

Body:
I usually have if/else conditions which involves comparing values with a constant string.

Is it really advantageous to use symbols in such cases or use string.
For eg.

```<code>if status == 'submitted'
  ...
elsif status.try(:to_sym) == :open
  ...
</code>```

Also what are the affects on memory consumption when this condition is in an instance method or class method or global method. Is the string takes up memory every time it's called ?


答:
In a comment to Lorehead, Kaz correctly remarks that this rule only is relevant if the code is otherwise well-defined. You can't make code more Undefined after all, UB is a binary state.

So take the portable uses of volatile, i.e. with signals and longjmp. In both cases the compiler must ensure the proper semantics are being respected. In particular, the update of visible (volatile) global state must be as described in the code. Non-volatile state can be updated in any order.

Now let's assume that a write through int* could affect volatile state. It means any indirect write cannot be reordered anymore. This is a huge performance impact. Even worse, all reads through int* have to be done and cannot be cached in a register.

Thus, this rule allows for significant optimizations, by massively increasing the number of memory operations that can be reordered.


问:
How to mitigate complexity of fallbacks introduced to automatically retry upon failure?
So this may come off a bit broad and generalized, but after spending some time working around under developers, I've come to notice many different methods and design patterns. However, one big thing that sticks out to me is how mind-bendingly complex some of these relatively simple (logic-wise) classes can get.

For example, I recently built a service that synchronizes data between SalesForce and Zendesk. Now there are a lot of different business rules that have to be taken into considerable, but I built the application around the MVVM code pattern.

But once you dig in a bit deeper, you'll notice a lot of complexity and you start digging through a lot of classes to figure out quite what's going on.

For example, here's a class diagram of my synchronization tool.

Even a casual glance will be able to show some of the complexity, and it gets even more difficult when you dig into the actual code behind the individual methods.

Not only are you interfacing between two separate APIs, you're also interacting with multiple protocols (SOAP and REST). Both of these services are prone to hiccups and failures, so fallbacks are necessary to automatically retry upon failure. Then you need to map all the fields correctly back and forth. From there you have to ensure that nothing else manages to fail either. Every single field is a possibility for failure, and each feature you add makes in exponentially complex.

How can you mitigate some of this complexity?

答:
You create classes (or abstractions) as necessary which each handle one of the complicated bits. For example, you may have a class that will try its best to send a message from your application to a certain server and get a reply, and will either succeed or fail and tell you which one, and will handle possible errors to such an extent that if it fails, the caller just accepts the failure and doesn't try anything else.

That's hard to implement, but it's hard to implement not because you use some wrong strategy or pattern, but because it's just hard. But with this interface, the class is easy to use: Send a message, on success process the reply, on failure process the failure.

And you repeat that, writing multiple classes that each are just as complicated as they ought to be and not any more, and that are each easy to use.


问:
Why is a frame pointer set as an offset from the stack pointer?
I'm trying to understand how stack frames are constructed and have run into this description on wikipedia:

The locations of all other fields in the frame can be defined relative
  either to the top of the frame, as negative offsets of the stack
  pointer, or relative to the top of the frame below, as positive
  offsets of the frame pointer. The location of the frame pointer itself
  must inherently be defined as a negative offset of the stack pointer. --- https://en.wikipedia.org/wiki/Call_stack

The description in the quote above implies that the frame pointer's address being an offset from the stack pointer is trivially obvious from their respective definitions.

I'm confused about why the location of the frame pointer must inherently be defined as a function of the stack pointer.

As I understand the situation, the stack pointer is incremented when new memory is allocated to the frame. However the location of the frame pointer is fixed from the point where the procedure's prologue has finished.

Since all memory accesses within the frame must either be addressed as offsets from the frame pointer or as memory offsets from the stack pointer, and one of the frame pointer and stack pointer is a fixed location and the other one is inherently mutable, surely it makes sense to make the mutable pointer an offset from the fixed pointer?

As I understand it, in the above scheme, you'd need to update the frame pointer reference every time you incremented the stack pointer, which seems excessive. What have I misunderstood?

答:
Well, you are right, this is all very confusing.  First of all, the frame pointer is not even necessary.  Everything is addressable using only the stack pointer.

The main reason for the existence of the frame pointer is that the value of the stack pointer may change during the execution of the function, (namely, as you are pushing into the stack parameters of other functions that you are willing to call,) meaning that the offset of each argument and each local will vary. This is not a problem at all to a compiler, which can simply keep track of how the stack pointer varies and use adjusted offsets accordingly, but it can become a nightmare to a human who is trying to write the function or debug it later.

Another reason for the existence of the frame pointer is historical: the Intel x86 architecture used to be somewhat inconvenienced with respect to addressing memory relative to the stack pointer. The only registers that could be used as index registers were BX,BP,SI and DI, note how SP is missing from the list. So, the BP register was used as the frame pointer. However, it is kind of strange that the Wikipedia article should be influenced by the 8086, because it is describing a stack which grows upwards, while on the x86 architecture the stack grows downwards.  Go figure.

Note that this has all been fixed in x64.  If you look at the System V Application Binary Interface AMD64 Architecture Processor Supplement, on page 16 there is a footnote which says:

The conventional use of %rbp as a frame pointer for the stack frame may be avoided by using %rsp (the stack pointer) to index into the stack frame.  This technique saves two instructions in the prologue and epilogue and makes one additional general-purpose register (%rbp) available.

So, in a nutshell, the conventional use of the frame pointer is as follows: upon entry to a function, the frame pointer receives a copy of the value of the stack pointer, and the stack pointer is adjusted to make room for the locals. Then, during the execution of the function, the stack pointer is allowed to vary, but the frame pointer remains constant, so arguments and locals are still addressable at fixed offsets from the frame pointer.

To return in your question, the location of the frame pointer is not exactly defined as a function of the stack pointer, in the sense that the value of the stack pointer is copied into the frame pointer only once, in the beginning of the function.  From that point on, the frame pointer stays constant, while the stack pointer varies.


问:
Does one need to mock concrete data objects?
I've been working on a large project where much of the code is not under test. I have been able to add some unit tests to functional areas of the code, and also to start mocking services but I have a question about how much mocking to do on other areas.

This application and endpoints are primary based on .NET remoting so there are a lot of "data objects" that are being manipulated over the channel.

In testing some functions that operate on the object I'm unsure if I should be mocking the data object or instantiating one.

Here is an example:

[TestMethod()]
public void Test_GetAgeTest()
{
    //Arrange
    var familyMemberData = new FamilyMemberData
    {
        Demographics = { DoB = new DVDateTime(2000, 01, 01, 0, 0, 0) }
    };
    var year = DateTime.Today.Year;

    //Act
    var age = Translators.Test_GetAge(familyMemberData);

    //Assert
    Assert.AreEqual(year - 2000, age);
}
```

Translators is a static class, and GetAge is a function that does some calculation on the FamilyMemberData to get the age (Test_GetAge exposes it publicly).

Should FamilyMemberData be a Mock Object, or a Fake, or in cases like these just use them as is?

答: The general purpose to mocks/fakes etc is to bypass functionality in a class to simplify testing. If eg FamilyMemberData only contains data, then there is nothing to be gained from mocking it.


问:
Webdesign MVC - going in the right direction?
I am trying to learn webdesign using the MVC design pattern. Right now, I am stuck at a point where my code gets more complex, and I am unsure about the structure and where to put which code parts.

I started with an index.php file as my controller, which right now does not much more than loading the Slim framework to render the different views

```<code>$app->get('/', function() use ($app){
$app->render('header.php');
$app->render('content.php');
$app->render('footer.php');
});
$app->run();
</code>```

Then I built a complex content.php where I do a lot of form data logic,
reading from a server directory, and echoing the results mixed with html tags. That surely will violate the MVC pattern, right?

What is the general approach to this? Should I put all the logic inside the index.php, store the results in an array, and pass that to the framework's render function, like this:

```<code>$app->get('/', function() use ($app){

//Do something and store results in an Array

$app->render('header.php', anArray());
$app->render('content.php', anArray());
$app->render('footer.php', anArray());
});
$app->run();
</code>```

How can I prevent index.php becoming too complex when doing so? Is there a different approach to take?

答:
The trick is, you have to pass your variables into your object like this:
$app->vars = $yourVars

Then if you include the files inside your render function the files works as part of your object and you can access your vars like this:
$this->vars

Or you can also pass the vars as you thought $app->render('file.php', $yourVars)

That's the whole point of MVC you only pass specific variables to objects so they can't access all of them.

OwnerDisplayName: bnny


答:
There are several reasons to use Mocks/Fakes/Stubs (putting them all together, although they really are different things):

You want to have more control over the responses of a dependency, so that you can more easily test situations that are hard to recreate with the real objects

You want to isolate your tests from slow, possibly unreliable network connections

You want to make it easy on yourself to make sure that changes made by a test do not persist beyond the test

You want to isolate the code-under-test from dependencies that could have errors in them themselves.

If none of these reasons exist for the code you want to test, then you should just use the real objects, as that is typically much simpler than arranging for a mock, fake or stub.

In your case FamilyMemberData appears to be just a simple data container without complex logic or dependencies that might trigger any of the reasons to create a mock, so there is no value in mocking FamilyMemberData.

Title: Does one need to mock concrete data objects?

Body:
I've been working on a large project where much of the code is not under test. I have been able to add some unit tests to functional areas of the code, and also to start mocking services but I have a question about how much mocking to do on other areas.

This application and endpoints are primary based on .NET remoting so there are a lot of "data objects" that are being manipulated over the channel.

In testing some functions that operate on the object I'm unsure if I should be mocking the data object or instantiating one.

Here is an example:

[TestMethod()]
public void Test_GetAgeTest()
{
    //Arrange
    var familyMemberData = new FamilyMemberData
    {
        Demographics = { DoB = new DVDateTime(2000, 01, 01, 0, 0, 0) }
    };
    var year = DateTime.Today.Year;

    //Act
    var age = Translators.Test_GetAge(familyMemberData);

    //Assert
    Assert.AreEqual(year - 2000, age);
}
```

Translators is a static class, and GetAge is a function that does some calculation on the FamilyMemberData to get the age (Test_GetAge exposes it publicly).

Should FamilyMemberData be a Mock Object, or a Fake, or in cases like these just use them as is?


答:
But once you dig in a bit deeper, you'll notice a lot of complexity and you start digging through a lot of classes to figure out quite what's going on.

In my point of view you have the opposite problem. You have a feeling of complexity because there are too few classes.

Complexity does not come from retry pattern, complexity is price you pay to do not use one essential OOP tool: inheritance.

Without some code it's hard to highlight many defects (you may consider to post relevant parts on Code Review) but few things you should consider:

Naming convention if not uniform: different casing (for example camel case for some private methods), names like SfAttach and SfAttach2. Lower case name for properties and underscores here and there. Stick strictly to environment conventions/best practices. Also consider to drop prefixes (Sf, Zd, E) whenever possible.

You have many God classes and many helper classes. They usually mean there is something wrong in your design. As it is now you just splitted a big bunch of code in four classes with some pure entities around them. Also consider to use collection classes. Do you have a list of Attachment? You probably need an AttachmentCollection class. Don't span implementation details everywhere in your code.

Follow common patterns (introduce them when you don't use them) and implement them correctly: for example I see IDisposable implemented without a protected/private Dispose(bool) method.

I'd also guess methods are long and complex (I see few private methods but I think there is a lot to do then methods length must be high). Split your code! I want to understand what a method does from its name and how it does it reading 5/10 lines of code, no more.

What to do?

First of all you should describe everything at very high level. It doesn't matter you're using SalesForce and Zendesk. Do it writing your tests and think you have to keep in sync two different services. No names, no implementation details.

Create high level abstract classes with all the logic you need. This is your domain, populate it with high level entities. Each time you feel you need an helper class then you're doing something wrong, go back.

Implement mocks to complete your tests. You will know your logic is right, regardless concrete implementation. With mocks you can simulate network errors...

...it's time to implement a good retry pattern. If you did everything right you just need to add this complexity to one single ReadField() method and one WriteField() method (or their equivalents if you're working at record level).

Now you can derive implementation specific classes. Zendesk and SalesForce. Fill the gap between abstract representation and actual implementation.

Add tests specific for services you're using. You may also mock them one by one to simulate errors and weird conditions.

You're done.

You will see you have many more classes (probably with less methods) but to understand what's going on you just need to read few lines of code...

Title: How to mitigate complexity of fallbacks introduced to automatically retry upon failure?

Body:
So this may come off a bit broad and generalized, but after spending some time working around under developers, I've come to notice many different methods and design patterns. However, one big thing that sticks out to me is how mind-bendingly complex some of these relatively simple (logic-wise) classes can get.

For example, I recently built a service that synchronizes data between SalesForce and Zendesk. Now there are a lot of different business rules that have to be taken into considerable, but I built the application around the MVVM code pattern.

But once you dig in a bit deeper, you'll notice a lot of complexity and you start digging through a lot of classes to figure out quite what's going on.

For example, here's a class diagram of my synchronization tool.

Even a casual glance will be able to show some of the complexity, and it gets even more difficult when you dig into the actual code behind the individual methods.

Not only are you interfacing between two separate APIs, you're also interacting with multiple protocols (SOAP and REST). Both of these services are prone to hiccups and failures, so fallbacks are necessary to automatically retry upon failure. Then you need to map all the fields correctly back and forth. From there you have to ensure that nothing else manages to fail either. Every single field is a possibility for failure, and each feature you add makes in exponentially complex.

How can you mitigate some of this complexity?


问:
Real world pitfalls of introducing F# into a large codebase and engineering team
I'm CTO of a software firm with a large existing codebase (all C#) and a sizable engineering team.  I can see how certain parts of the code would be far easier to write in F#, resulting in faster development time, fewer bugs, easier parallel implementations, etc., basically overall productivity gains for my team.  However, I can also see several productivity pitfalls of introducing F#, namely:

1) Everyone has to learn F#, and it's not as trivial as switching from, say, Java to C#.  Team members that have not learned F# will be unable to work on F# parts of the codebase.

2) The pool of hireable F# programmers, as of now (Dec 2010) is non-existent.  Search various software engineer resume databases for "F#", way less than 1% of resumes contain the keyword.

3) Community support as of now (Dec 2010) is less available.  You can google almost any problem in C# and find someone that has already dealt with it, not so with F#.  Third party tool support (NUnit, Resharper etc) is also sketchy.

I realize that this is a bit Catch-22, i.e. if people like me don't use F# then the community and tools will never materialize, etc.  But, I've got a company to run, and I can be cutting edge but not bleeding edge.

Any other pitfalls I'm not considering?  Or anyone care to rebut the pitfalls I've mentioned?  I think this is an important discussion and would love to hear your counter-arguments in this public forum that may do a lot to increase F# adoption by industry.

答:
As a practical matter, IntelliSense support is quite lacking -- to the point where the productivity gains of type inference are outdone by the less-sophisticated autocomplete available in C#.

The error messages caused by erroneous type inferences also take longer to fix for beginners (and often for intermediate users like myself), simply because you're less inclined to provide type annotations than you would in a language like C#.

OOP is also lacking in surprising ways in F#; for instance, there's no support for nested types/classes. You have to be careful when you're porting code, because there are some things that you can do in C# that you can't do in F#, sadly.

Last but not least, both the size and the quality of the F# community is sort of disappointing. A lot of the F# information out there on the web is either for old versions or simply not very good -- either un-idiomatic, poor performance or flat out incorrect. Then there are people charging huge money for newsletters that are largely just of existing information digests.

I myself use C# for work projects and F# for my own stuff. As much as I love F#, unfortunately, it's a bit hard to predict how/when things might fall apart.

OwnerDisplayName: nganju


答:
If UTF-8 is actually to be extended, we should look at the absolute maximum it could represent. UTF-8 is structured like this:

```<code>Char. number range  |        UTF-8 octet sequence
   (hexadecimal)    |              (binary)
--------------------+---------------------------------------------
0000 0000-0000 007F | 0xxxxxxx
0000 0080-0000 07FF | 110xxxxx 10xxxxxx
0000 0800-0000 FFFF | 1110xxxx 10xxxxxx 10xxxxxx
0001 0000-0010 FFFF | 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
</code>```

(shamelessly copied from the RFC.) We see that the first byte always controls how many follow-up bytes make up the current character.

If we extend it to allow up to 8 bytes we get the additional non-Unicode representations

```<code>111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
11111110 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
11111111 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
</code>```

Calculating the maximum possible representations that this technique allows we come to

```<code>  10000000₂
+ 00100000₂ * 01000000₂
+ 00010000₂ * 01000000₂^2
+ 00001000₂ * 01000000₂^3
+ 00000100₂ * 01000000₂^4
+ 00000010₂ * 01000000₂^5
+ 00000001₂ * 01000000₂^6
+ 00000001₂ * 01000000₂^7
</code>```

or in base 10:

```<code>  128
+  32 * 64
+  16 * 64^2
+   8 * 64^3
+   4 * 64^4
+   2 * 64^5
+   1 * 64^6
+   1 * 64^7
</code>```

which gives us the maximum amount of representations as 4,468,982,745,216.

So, if these 4 billion (or trillion, as you please) characters are enough to represent the alien languages I am quite positive that we can, with minimal effort, extend the current UTF-8 to please our new alien overlords ;-)

Body:
If UTF-8 is actually to be extended, we should look at the absolute maximum it could represent. UTF-8 is structured like this:

Char. number range  |        UTF-8 octet sequence
   (hexadecimal)    |              (binary)
--------------------+---------------------------------------------
0000 0000-0000 007F | 0xxxxxxx
0000 0080-0000 07FF | 110xxxxx 10xxxxxx
0000 0800-0000 FFFF | 1110xxxx 10xxxxxx 10xxxxxx
0001 0000-0010 FFFF | 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx

(shamelessly copied from the RFC.) We see that the first byte always controls how many follow-up bytes make up the current character.

If we extend it to allow up to 8 bytes we get the additional non-Unicode representations

111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
11111110 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
11111111 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx

Calculating the maximum possible representations that this technique allows we come to

  10000000₂
+ 00100000₂ * 01000000₂
+ 00010000₂ * 01000000₂^2
+ 00001000₂ * 01000000₂^3
+ 00000100₂ * 01000000₂^4
+ 00000010₂ * 01000000₂^5
+ 00000001₂ * 01000000₂^6
+ 00000001₂ * 01000000₂^7

or in base 10:

  128
+  32 * 64
+  16 * 64^2
+   8 * 64^3
+   4 * 64^4
+   2 * 64^5
+   1 * 64^6
+   1 * 64^7

which gives us the maximum amount of representations as 4,468,982,745,216.

So, if these 4 billion (or trillion, as you please) characters are enough to represent the alien languages I am quite positive that we can, with minimal effort, extend the current UTF-8 to please our new alien overlords ;-)


问:
Web Services vs Server Side Methods
With all the front end development frameworks now available.  I'd like to know if the generally accepted protocol is for a back end service to simply provide web services for the front end to consume?

For example: An application that may have displayed products in the past may have just generated the HTML on the server and sent it down to the client browser during the request.  It seems like the preferred way now would be to send the page template to the client, then the front end would make the request to get the list of products and display them using (Angular, Ember, React...)

Are there any performance cost to writing all client/server communication as web services?

答:
There's a time & place for everything.  Sometimes the right answer is to offer a web service that's consumed by client-side code.

This gives you the benefit of clearly separating your presentation from your model and business logic.  One example is that you could completely replace your web interface with a native app.

There is of course a drawback to using a web service. It's often more complicated to code up, and it requires 2 round trips to the server - one for the template and one for the data.

To answer your question

Are there any performance cost to writing all client/server communication as web services?

Yes - it takes a little more developer concentration to code up and maintain, and it requires 2 round trips to the server to get the template and data.

However, that extra cost is often a good investment and well worth the effort.

Title: Web Services vs Server Side Methods


问:
How have you found, refined and maintained your coding style?
Recently, I've been switching between several projects and development environments. The expectations for coding style in each is different.

Now, my question is three part, the first, just of curiosity:

How did you define and find your coding style?

How do you keep augmenting and improving it?

How do you maintain it? (From mental notes, keeping a document, using a tool like StyleCop etc.)

答:
№1. # How did you define and find your coding style?

Through code samples first in books, then in MSDN texts and articles, then blogs and other web sites.

№2. How do you keep augmenting and improving it?

I keep my eye open to all suggestions people make. I try them out, if they work for me, they stick. I also experiment from time to time, what seems to improve things stays with me.

№3. How do you maintain it? (From mental notes, keeping a document, using a tool like StyleCop etc.)

I sort of remember my style and apply it automatically everywhere.

Note 1. Keeping an eye open and an ear sharp is extremely important to stay current. Years ago I learned from others the Hungary notation was a must so I followed it. When the community realized it was not so great I changed with everybody.

Note 2. It is often not that important what particular style elements you adopt but rather that you keep your style consistent throughout your codes. The same applies for a team. Choose some style but then stick to it.

Note 3. Coding styles for different languages may vary. C++ deserves one style, Java the other. HTML and CSS have their characteristics require some different style again.

Note 4. Whatever style you choose, understand and accept that it won't work 100%. Sometimes you have some code that requires a different style just in-place, either split multiline, different alignment or whatever to keep that particular code piece more readable. Don't push your style everywhere, focus on the code readability. If it is obvious, the style doesn't work in this particular place, make an exception.

Note 5. Don't make following a code style to a religion. Tools enforcing a code style are good, but sometimes can make you mad. I for instance disabled the Visual Studio's automatic code formatting because it was driving me nuts. If a tool becomes an obstacle, just add an exception and don't worry that your code isn't 100% compliant. It's not that important really and perfection not achievable is anyway.


答:
As you say "web services" (not single service) you will be subjecting your users to multiple network requests to populate your page. This can be a bad thing, http 1.1 introduced the idea of keeping the connection open to request every page element in a single connection as it was quite faster, not to mention more efficient on the server.

There's also a question of security if your data-providing web services are directly connected to your untrusted clients.

As a result of these, its better to architect your page to make a single request to a single server that may then request multiple data sources and aggregate them into a single data set for the client. Whatever might look beautiful to the developer means nothing to the user who is going to have to wait for one block of data to arrive, then watch the page populate another set - it will seem far slower than simply having to wait for the old-style HTML request (regardless of the actual speed).

Of course the best way nowadays would be to use a websocket and stream data to the client continuously. This would require a single server on the back-end to serve this (last thing you want is many sockets opened on your server to serve a single user, that won't scale well)

Title: Web Services vs Server Side Methods

Body:
With all the front end development frameworks now available.  I'd like to know if the generally accepted protocol is for a back end service to simply provide web services for the front end to consume?

For example: An application that may have displayed products in the past may have just generated the HTML on the server and sent it down to the client browser during the request.  It seems like the preferred way now would be to send the page template to the client, then the front end would make the request to get the list of products and display them using (Angular, Ember, React...)

Are there any performance cost to writing all client/server communication as web services?


问:
Uncle Bob's clean architecture - An entity/model class for each layer?
BACKGROUND :

I'm trying to use Uncle Bob's clean architecture in my android app. I studied many open source projects that are trying to show the right way to do it, and I found an interesting implementation based on RxAndroid.

WHAT I NOTICIED :

In every layer (presentation, domain and data), there's a model class for the same entity (talking UML). Plus, there are mapper classes that take care of object's transformation whenever the data is crossing the boundaries (from layer to another).

QUESTION :

Is it required to have model classes in every layer when I know that they'll all end up with the same attributes if all CRUD operations are needed? Or, is it a rule or a best practice when using the clean architecture?

答:
No, you don't need to create model classes in every layer.

Entity(DATA_LAYER) - is a full or partial representation of Database object. DATA_LAYER

Mapper(DOMAIN_LAYER) - actually is a class which convert Entity to  ModelClass, which will be used on DOMAIN_LAYER

Take a look : https://github.com/lifedemons/photoviewer

OwnerDisplayName: Rami Jemli

OwnerDisplayName: ssh