问:
Structure of stack of a function call
I've been reading Aleph One's paper on Smashing the Stack for Fun and Profit. I wrote down example1.c from his paper, modified it a bit to see what the stack looks like on my system.

I'm running Ubuntu (64-bit) on a VM on an Intel i5 M 480.

The paper says that a stack will have the following structure. It also says that the word size is 4 bytes. I read up on word sizes and determined that on a 64-bit OS that is not "long-enabled" the word size is still 32 bits or 4 bytes.

However, when I run my custom code:

```<code>void function(int a, int b, int c) {
    char buffer1[5];
    char buffer2[10];
    memset(buffer1, "\xaa", sizeof(buffer1));
}

void main() {
    function(1, 2, 3);
}
</code>```

I do not get the same stack structure as the paper. Yes, I'm aware that the paper was published in 1998 but I haven't found any article on the internet stating that the stack structure has been modified greatly. Here's what my stack looks like (I'm also uploading GDB screenshots for verification, in case I've misinterpreted the stack):

```<code>    Lower memory                                                Higher memory
    -------------------------------------------------------------------------
    | int c   | int b   | int a   | buffer1  | buffer2  | RBP     | RET     |
    | 4 bytes | 4 bytes | 4 bytes | 16 bytes | 16 bytes | 8 bytes | 8 bytes |
    -------------------------------------------------------------------------
</code>```

Now for my questions:

Why has the stack structure changed?

What is with the extra space given to buffer1 and buffer2? According to the paper they should have only 8 bytes and 12 bytes allotted. However, buffer2 gets an extra 6 bytes and only then does buffer1 begin and even buffer1 is allotted 16 bytes. Am I missing something here? I read about slack space being given as a protective mechanism, is this it?

[EDIT]

The x64 ABI says that the stack is always eightbyte aligned (page 17, footnote number 9).

So, if the parameters and the 2 character buffers are pushed onto the stack then the total space occupied by the stack is 48 bytes (or 0x30 bytes). Since, it is 8 bytes for 3 integers amounting to a total and 24 bytes and 8 bytes for buffer1 and 16 bytes for buffer2, we arrive at our grand total of 48 bytes which is corroborated by the GDB screenshot.

However, the GDB stack also shows that the integers (a, b and c) have only been allotted 4 bytes each. The buffers also occupy the size declared in the program (obviously). Is this why I see the slack?

Slack = 48 - (5 + 10 + 4 + 4 + 4) = 21 bytes

Am I right?

答:
The difference is mostly explained by the difference of ABI :

the paper explains what happens in x86 (32 bit);

you are using x86_64.

In x86n the x86 ABI is used

The parameters are passed on the stack by the caller. This means that the 3 values on the top will be a, b and c.

The call instruction pushes the IP (the ret field).

Usually, the caller frame pointer is pushed by the callee (the sfp field).

All those fields are fixed on this architecture by the ABI.

The lower part of the stack (local variables, saved registers, etc.) is not fixed by the ABI and the compiler can decide how it will use it.

```
Lower memory                                                Higher memory
-------------------------------------------------------------------------
| buffer2 | buffer2 | sfp     | ret      | a        | b       | c       |
-------------------------------------------------------------------------
<----------(3)------><--(2)--><--------------------(1)------------------>

(1): Pushed by the caller for the callee, fixed by the ABI.
(2): Pushed by the callee, fixed by the ABI.
     Technically, this is optional as for x86 but it is generally used.
(3): Pushed by the callee, in any order.
```

In x86_64, the AMD-64/x86_64 ABI is used:

Parameters are usually passed by registers: the a, b, c variables that you find on the stack are copies of the parameters made by the callee (because you probably did not enable optimisations). This is why they are lower in the stack than the return address. This means that the compiler if free to place them in any order (and does not need to have them on the stack at all).

Moreover, the code is usually not compiled with frame pointers: the push rbp; mov rbp, rsp is usually omitted.

```
Lower memory                                                Higher memory
-------------------------------------------------------------------------
| int c   | int b   | int a   | buffer1  | buffer2  | RBP     | RET     |
| 4 bytes | 4 bytes | 4 bytes | 16 bytes | 16 bytes | 8 bytes | 8 bytes |
-------------------------------------------------------------------------
<-------------(2)--------------------------------------------> <---(1)-->

(1): Pushed by the caller for the callee, fixed by the ABI.
(2): Pushed by the callee, in any order.
```

In summary:

On x86, the parameters are pushed on the stack by the caller: their locations on the stack is fixed by the ABI. They are higher than the return address because they are pushed by the caller.

On x86_64, the parameters are passed in registers (unless you have too many of them). The callee is free to push them on the stack if it needs to in any order. As they are pushed by the callee they are lower than the return address on the stack (and can be intermixed with local variables, saved registers).

In both ABIs, using %rbp as frame base is optional but it is usually used for x86 and often not used in x86_64.

Note: the Windows x86_64 ABI is different.

Some references:

stack layout in x86_64;

stack layout in x86.

Title: Structure of stack of a function call

Body:
The difference is mostly explained by the difference of ABI :

the paper explains what happens in x86 (32 bit);

you are using x86_64.

In x86n the x86 ABI is used

The parameters are passed on the stack by the caller. This means that the 3 values on the top will be a, b and c.

The call instruction pushes the IP (the ret field).

Usually, the caller frame pointer is pushed by the callee (the sfp field).

All those fields are fixed on this architecture by the ABI.

The lower part of the stack (local variables, saved registers, etc.) is not fixed by the ABI and the compiler can decide how it will use it.

Lower memory                                                Higher memory
-------------------------------------------------------------------------
| buffer2 | buffer2 | sfp     | ret      | a        | b       | c       |
-------------------------------------------------------------------------
<----------(3)------><--(2)--><--------------------(1)------------------>

(1): Pushed by the caller for the callee, fixed by the ABI.
(2): Pushed by the callee, fixed by the ABI.
     Technically, this is optional as for x86 but it is generally used.
(3): Pushed by the callee, in any order.

In x86_64, the AMD-64/x86_64 ABI is used:

Parameters are usually passed by registers: the a, b, c variables that you find on the stack are copies of the parameters made by the callee (because you probably did not enable optimisations). This is why they are lower in the stack than the return address. This means that the compiler if free to place them in any order (and does not need to have them on the stack at all).

Moreover, the code is usually not compiled with frame pointers: the push rbp; mov rbp, rsp is usually omitted.

Lower memory                                                Higher memory
-------------------------------------------------------------------------
| int c   | int b   | int a   | buffer1  | buffer2  | RBP     | RET     |
| 4 bytes | 4 bytes | 4 bytes | 16 bytes | 16 bytes | 8 bytes | 8 bytes |
-------------------------------------------------------------------------
<-------------(2)--------------------------------------------> <---(1)-->

(1): Pushed by the caller for the callee, fixed by the ABI.
(2): Pushed by the callee, in any order.

In summary:

On x86, the parameters are pushed on the stack by the caller: their locations on the stack is fixed by the ABI. They are higher than the return address because they are pushed by the caller.

On x86_64, the parameters are passed in registers (unless you have too many of them). The callee is free to push them on the stack if it needs to in any order. As they are pushed by the callee they are lower than the return address on the stack (and can be intermixed with local variables, saved registers).

In both ABIs, using %rbp as frame base is optional but it is usually used for x86 and often not used in x86_64.

Note: the Windows x86_64 ABI is different.

Some references:

stack layout in x86_64;

stack layout in x86.


问:
Version control for independent developers?
Do you think it's worth it to use version control if you are an independent developer, and if so, why? Do you keep the repository on your own computer, or elsewhere, where it can serve as a backup?</p>

答:
If you use decentralized source control (Mercurial or Git or Bazaar or whatever), you get advantages over SVN/CVS that makes it easy, useful and powerful to use in case you're an indy:

You commit locally: your project dir is your repo with FULL history. So you don't have to have a server, you commit directly in your repo, and you can have several repos in the same computer. Using a laptop that you open sometimes to continue working on your things? Great! You don't have to setup a server and if you need one later, it's easy and you just "push" and "pull" changes between repositories.

It's made to ease experimentation: often you need to have an idea about a feature without polluting code. With SVN and CVS you can already use a branching system and ditch the branch if the feature is not as good as you wanted it to be. But if you want to merge the feature with the trunk version, you'll have a lot of hard to fix surprises. Git, Mercurial and Bazaar (at least) makes merges and branches really easy. You can even just duplicate a repo, work on it some time, still commit and kill it or push your changes in the main repo if you want.

Flexibility of organisation: as pointed before, as you have repos that you organize as you need, it's easy to start alone and allow other people to work with you by changing your organization. No organization is imposed so you just have to set it up and voilà. I often just push/pull changes between my own computers (laptop/desktop/server) and I'm still alone on my devs. I use Mercurial and that help me duplicate my work but also work on features I thought about outside on my laptop, then continue to work on other features on my desktop, then push my laptop changes on my desktop or server and merge the whole desktop+laptop and put it (as backup and future teamwork repo) on my server.

It helps setting up backups: if you setup a central repo (on GitHub if it's public, or in a private repo on BitBucket) you can easily write a script which will be executed each time a computer is booted, and then pass said script on to your friends so that it makes automatic backups of your work regularly. It's what I'm doing so now I'm sure it won't be easy to lose my work.

In fact, currently, you have no excuse to not use a control source tool for any project. Because they are more powerful and flexible than before and scale with your needs.

ContentLicense: CC BY-SA 3.0


问:
What's the best way to avoid catastrophe caused by negligence?
I have been a programmer for almost 1 year.

As an ADHD adult, naturally I don't have the same strength of attention on ordinary stuffs as my colleagues do.

And I find the catastrophe made by me are usually caused by trivial negligence.

Like for today, I found the cron process on the server collapsed in the morning.

After half hour of debugging. I found I wrote in the cron

* 4 * * * sh daily_task.sh

instead of

0 4 * * * sh daily_task.sh

Which runs the huge shell 59 times in the morning instead of the intended 1 time.

Is there some kind of cultivatable behaviour or some tools or anything that can help me at least reduce such kind of  mistake?

How do you do to avoid such kind of mistake?

答:
You always have to be at least two steps away from disaster. That means you never directly push something you just wrote into production. You either test it, or you have it tested, or you have it reviewed, or figure out some other way to have a two step path to disaster. Sometimes I will leave something for the next day and review my work again before committing.

In cases where something is really critical, you add a third step: a second reviewer, a second independent test, etc...

To err is human. Our brains are not built for precision. Everyone makes mistakes, everyone writes bugs, although some more than others (being careful still pays). You have to figure out a process that builds in the assumption that any individual's work is flawed.


答:
Previous answers mentioned two points:

Reviews.

Testing.

but there are also three additional elements which may help:

Better visualization.

By using tools which let you better visualize what you do, you may catch errors earlier. This is particularly illustrative with the cron jobs. Imagine you have a visualization tool which shows you, graphically, when the cron jobs you have defined run. Immediately, you see that there is something wrong.

Syntax highlighting, for example, is the most popular developers' visualization tool, and it indeed helps finding errors at very early stages (often within seconds of writing something wrong), before compiler or tests run.

Continuous monitoring.

Why the server collapsed? Wasn't there a way to see that something is going wrong before bad things happened?

Servers should have been properly monitored. Either a person or an app should have seen that after the last change, CPU usage increased from, say, an average of 42% to an average of 100%, and could do something to prevent the server to collapse.

This leads me to Continuous integration, and more specifically Continuous deployment. In Continuous deployment, when you make a commit, the new revision is built, tested and deployed to production on a few servers. Then, those servers are watched by an app. If the app sees an abnormal increase in resources usage or an abnormal quantity of warnings in syslog coming from those servers, the servers are reverted to their previous state.

Strictness.

Guidelines and rules are usually annoying (not convinced? Try to write a small C# app which conforms to StyleCop and Code analysis and has good results with Code metrics and has a decent code coverage!) but also particularly useful. This is why some projects target zero warnings with static checkers and zero warnings with the compiler set to a maximum level: errors found earlier are errors you don't have to solve when it is too late.

While this wouldn't help with cron jobs, it helps when writing code.

Title: What's the best way to avoid catastrophe caused by negligence?

Body:
I have been a programmer for almost 1 year.

As an ADHD adult, naturally I don't have the same strength of attention on ordinary stuffs as my colleagues do.

And I find the catastrophe made by me are usually caused by trivial negligence.

Like for today, I found the cron process on the server collapsed in the morning.

After half hour of debugging. I found I wrote in the cron

* 4 * * * sh daily_task.sh

instead of

0 4 * * * sh daily_task.sh

Which runs the huge shell 59 times in the morning instead of the intended 1 time.

Is there some kind of cultivatable behaviour or some tools or anything that can help me at least reduce such kind of  mistake?

How do you do to avoid such kind of mistake?


问:
How to test a method which is not as much as a unit, because it is more of a 'orchestrator' / 'process' / 'controller' / 'coordination' class
I want to test a method which is not as much as a unit, because it is more of a 'orchestrator' / 'process' / 'controller' / 'coordination' class.

This is the case:

I have four  unit tested classes:

One is a data service which can read/write data from the database

Second is a textservice which can create content for emails /
messages etc.

Third is a mailservice that can send email

Fourth is a  class dat can create tasks for users in our system (tasks are things
they should do)

Now I created a new class, which sends an email all people which are late with paying an invoice.
It reads data with the data service, creates the appropriate text with the textservice, sends an email with the email service, writes the new invoice status with the data service and creates a task when the emailing for a specific invoice fails.

Now this new class is my 'orchestrator' or 'process' or 'controller' or 'coordination' class.

I have these kind of classes a lot in our application because we try to make our classes (like the data/email/textservice) as small as possible so when 'work has to be done', like in this case the 'mail all people which are late with paying', we create a new 'orchestrator' or 'process' or 'controller' or 'coordination' class.

I think I have these kind of classes for the most of my actions in my webcontrollers because most input sent from the browser involves coordination between multiple (smaller) classes

Now how do I test these classes / methods?

I used to mock all 4 classes in my test and verify at the end that the classes are called, and in the right order.

But more and more I read that you shoud not do this, because then you test for the internal working of a method, and when you refactor that method, the test fails.
So I should test for results, not for inner working. But this method is void, so there is nut much of a result to verify on.
The only thing I can think for instance  to check for is: is email sent? But the only way to check that is to verify the email service is called, but then I'm back at testing the internals.

I don't see these kind of examples in the unit testing / tdd books, because they most of the time only work with the small classes like the calculator class, but rarely do I see examples for 'orchestrator' classes like I'm describing, but which occur a lot in my code.

For those who think it's a duplicate: I think the answers here provide much more background than the one answer at the other question. That other question was answered with a integration test in mind, and my question is about unit testing, not integration testing. So I can't agree with the duplicate answer mark.

答:
From what you describe I would say that the way you have been doing it - mocking the collaborators - is the best approach.  It may be that you are over-specifying with your mock - for instance, requiring an order which is not really required by the business needs; if that is the case you could lighten up on the order requirements of your tests.  But basically for the coordinator you want to know that:

given a data service who says "these people are late"

given a text service which generates email of the form "hey, you're late"

given an email service which sends to a list of recipients

it will submit a request to the email service to send "hey, you're late" to the aforementioned set of people.

If it's doing that (and a few other things you mentioned which I'm not bothering to re-specify here), then as far as you're concerned, your coordinator class is working.  That's an easy test to write with mocks, clean and communicative.  That's the way I'd recommend.


答:
I don't think there is anything else that you can do except testing that the functions inside that method are called.

Since the "orchestration" method doesn't contain much logic unit-testing is not so important. It's a method that only wires up other methods. It integrates other components. Therefore there should be integration tests that cover those lines of code. Unit tests may be omitted. So I wouldn't worry about it too much as long as you have those integration tests. Though, how this can be integration tested is another topic because you should not mock all of the other components and therefore get some dependencies that you are going to have to deal with.

Title: How to test a method which is not as much as a unit, because it is more of a 'orchestrator' / 'process' / 'controller' / 'coordination' class

Body:
I want to test a method which is not as much as a unit, because it is more of a 'orchestrator' / 'process' / 'controller' / 'coordination' class.

This is the case:

I have four  unit tested classes:

One is a data service which can read/write data from the database

Second is a textservice which can create content for emails /
messages etc.

Third is a mailservice that can send email

Fourth is a  class dat can create tasks for users in our system (tasks are things
they should do)

Now I created a new class, which sends an email all people which are late with paying an invoice.
It reads data with the data service, creates the appropriate text with the textservice, sends an email with the email service, writes the new invoice status with the data service and creates a task when the emailing for a specific invoice fails.

Now this new class is my 'orchestrator' or 'process' or 'controller' or 'coordination' class.

I have these kind of classes a lot in our application because we try to make our classes (like the data/email/textservice) as small as possible so when 'work has to be done', like in this case the 'mail all people which are late with paying', we create a new 'orchestrator' or 'process' or 'controller' or 'coordination' class.

I think I have these kind of classes for the most of my actions in my webcontrollers because most input sent from the browser involves coordination between multiple (smaller) classes

Now how do I test these classes / methods?

I used to mock all 4 classes in my test and verify at the end that the classes are called, and in the right order.

But more and more I read that you shoud not do this, because then you test for the internal working of a method, and when you refactor that method, the test fails.
So I should test for results, not for inner working. But this method is void, so there is nut much of a result to verify on.
The only thing I can think for instance  to check for is: is email sent? But the only way to check that is to verify the email service is called, but then I'm back at testing the internals.

I don't see these kind of examples in the unit testing / tdd books, because they most of the time only work with the small classes like the calculator class, but rarely do I see examples for 'orchestrator' classes like I'm describing, but which occur a lot in my code.

For those who think it's a duplicate: I think the answers here provide much more background than the one answer at the other question. That other question was answered with a integration test in mind, and my question is about unit testing, not integration testing. So I can't agree with the duplicate answer mark.


答:
You generally don't need to test controller classes, since they shouldn't hold complex logic.  The actual work should be done in other classes if it is written correctly, so in the end you're essentially ensuring that the work gets delegated correctly.

The complexity of this depends entirely on the language that you're using, since to do it correctly, you would need to create stubs.  Languages like Java might have a hard time with this, but there are libraries that help you with this like Mockito.

If you do need to test your controller class, then you should ideally remove the surrounding classes and put stub classes in their places, then you simply verify that the proper method gets called in response to each input to your controller class.  I remind you that the whole point of unit testing is to verify that each method is doing its job properly.  For a controller class, that generally means delegating tasks properly.

The alternative to using stubs would be to perform the actual work, though this can easily get overwhelming to test given the complexity and other complications such as writing to the database, so I would advise against it.

Also, I would strongly advise you to extract only the information required in web controller classes and pass it to the methods that do the logic.  The reason for this is that you don't have to mock http request and response objects, but only what you pass, and you shouldn't have to test a method that dumbly retrieves the data required and passes it to another method (if it passes a null value, fine, don't test any more than you have to).

I hope that helps!


答:
Yes.

Even single developers need to sometimes see the state of their code from some past revision. And it's always a good idea to backup everything important, and that applies to all people.

Title: Version control for independent developers?

Body: Do you think it's worth it to use version control if you are an independent developer, and if so, why? Do you keep the repository on your own computer, or elsewhere, where it can serve as a backup?</p>

ContentLicense: CC BY-SA 2.5


问:
Should I rename package after Android app name change?
I have an Android app.

I have changed the app's name from appname1 to appname2. I would like to know if I should also change my package name from com.myname.appname1 to com.myname.appname2 to reflect the app name change?

The advantage of also changing the package name is that everything is consistent. But the disadvantage is that Git will treat such renaming of package as deletion and addition of files; and this makes looking at changes difficult.

What do you think?

答:
Git should treat renaming a folder as files moved around the place (whether or not you use the git mv command).

The other problem of changing the name of package is that users of the application won't get it as an update but as a new application. If it's a paid app, it can be annoying. If it's a free app, they may not notice the new version and your downloads could suffer from it.


问:
Proper way of handling EINTR in libraries
What is the recommended etiquette when it comes to EINTR in libraries?

I'm currently writing a function that does some file system tasks with the POSIX API, but a lot of the calls I use can potentially return EINTR.  Additionally, the function can block under some circumstances.  (For those interested, it implements a locking mechanism.)

In the interests of making this as general as possible, I would like to know what is the proper way to deal with an interrupted system call.

From most sources I've read, people typically retry the call and continue on with their business.  However, I'm not sure that's the right thing to do here, since there may be legitimate reasons to interrupt my function given that it can take a significant amount of time.  Furthermore, it means the EINTR would simply get swallowed by the function and the caller would lose any indication that it occurred.

My current strategy is to immediately abort the operation if I receive EINTR and notify the caller about it.  This way, the caller can decide if they want to retry my function, right?  (Or perhaps my understanding of signals is flawed?)

答:
Signals in Unix

when some other process sends your process Signal, your program will stop what it’s doing...

1) Run the handler code you wrote. You have no idea what your program might be doing when the signal arrives. That’s the idea with signals, they can be completely asynchronous.

2) When the signal handler is done, it typically just does a return, and your program continues where it left off, as if nothing had happened.

Found some useful info in Richard Stevens

A characteristic of earlier UNIX systems is that if a process caught a signal while the process was blocked in a "slow" system call, the system call was interrupted. The system call returned an error and errno was set to EINTR. This was done under the assumption that since a signal occurred and the process caught it, there is a good chance that something has happened that should wake up the blocked system call.

POSIX.1 semantics for interrupted reads and writes changed with the 2001 version of the standard. Earlier versions gave implementations a choice for how to deal with reads and writes that have processed partial amounts of data. If read has received and transferred data to an application's buffer, but has not yet received all that the application requested and is then interrupted, the operating system could either fail the system call with errno set to EINTR or allow the system call to succeed, returning the partial amount of data received. Similarly, if write is interrupted after transferring some of the data in an application's buffer, the operation system could either fail the system call with errno set to EINTR or allow the system call to succeed, returning the partial amount of data written. Historically, implementations derived from System V fail the system call, whereas BSD-derived implementations return partial success. With the 2001 version of the POSIX.1 standard, the BSD-style semantics are required.

The problem with interrupted system calls is that we now have to handle the error return explicitly. The typical code sequence (assuming a read operation and assuming that we want to restart the read even if it's interrupted) would be

```<code>again:
    if ((n = read(fd, buf, BUFFSIZE)) < 0) {
        if (errno == EINTR)
            goto again;     /* just an interrupted system call */
        /* handle other errors */
    }
</code>```

To prevent applications from having to handle interrupted system calls, 4.2BSD introduced the automatic restarting of certain interrupted system calls.

Body:
Signals in Unix

when some other process sends your process Signal, your program will stop what it’s doing...

1) Run the handler code you wrote. You have no idea what your program might be doing when the signal arrives. That’s the idea with signals, they can be completely asynchronous.

2) When the signal handler is done, it typically just does a return, and your program continues where it left off, as if nothing had happened.

Found some useful info in Richard Stevens

A characteristic of earlier UNIX systems is that if a process caught a signal while the process was blocked in a "slow" system call, the system call was interrupted. The system call returned an error and errno was set to EINTR. This was done under the assumption that since a signal occurred and the process caught it, there is a good chance that something has happened that should wake up the blocked system call.

POSIX.1 semantics for interrupted reads and writes changed with the 2001 version of the standard. Earlier versions gave implementations a choice for how to deal with reads and writes that have processed partial amounts of data. If read has received and transferred data to an application's buffer, but has not yet received all that the application requested and is then interrupted, the operating system could either fail the system call with errno set to EINTR or allow the system call to succeed, returning the partial amount of data received. Similarly, if write is interrupted after transferring some of the data in an application's buffer, the operation system could either fail the system call with errno set to EINTR or allow the system call to succeed, returning the partial amount of data written. Historically, implementations derived from System V fail the system call, whereas BSD-derived implementations return partial success. With the 2001 version of the POSIX.1 standard, the BSD-style semantics are required.

The problem with interrupted system calls is that we now have to handle the error return explicitly. The typical code sequence (assuming a read operation and assuming that we want to restart the read even if it's interrupted) would be

again:
    if ((n = read(fd, buf, BUFFSIZE)) < 0) {
        if (errno == EINTR)
            goto again;     /* just an interrupted system call */
        /* handle other errors */
    }

To prevent applications from having to handle interrupted system calls, 4.2BSD introduced the automatic restarting of certain interrupted system calls.


答:
As well as testing...

I found that printing out the code on paper, then running the code in a debugger and ticker each line once I confirm that all the values were as expected in the debugger was a great way.   This gets you to look at your code in another way.

Driving the "debugger checking" with unit tests is nice...


问:
How to convert the following node evaluation procedure to a non recursive solution?
I have the following recursive method.

It evaluates a node (that represent a logical expression), using deep first search traversal :

```<code>EvaluateNode(Node node)
{
    bool result;
    switch(node.Type)
    {
        case AND_OPERATOR:
            result = true;
            foreach(Node nodeChild in node.Childrens)
            {
                childresult = EvaluateNode(nodeChild);
                result = result && childresult;
            }
        case OR_OPERATOR:
            result = false;
            foreach(Node nodeChild in node.Childrens)
            {
                childresult = EvaluateNode(nodeChild);
                result = result || childresult;
            }
        case VALUE:
            result = node.Value;
    }

    return result;
}
</code>```

I'd like to convert this to a stack/queue based, non recursive solution. Here is what I tried so far (incomplete) :

```<code>bool result;
stack.Push(node);
while(!stack.Empty())
{
    Node node = stack.Pop();
    switch(node.Type)
    {
        case AND_OPERATOR:
            foreach(Node nodeChild in node.Childrens)
            {
                stack.Push(nodeChild);
            }
        case OR_OPERATOR:
            foreach(Node nodeChild in node.Childrens)
            {
                stack.Push(nodeChild);
            }
        case VALUE:
            result = node.Value;
    }
}
</code>```

My guess is that I would need another stack for storing results but I have not been able to figure this out.

答:
You are doing a Breadth-first search. There is typicall two way to approach this: recursive and non-recursive.
You can find a pseudo code for a non-recursive algorithm here:

http://en.wikipedia.org/wiki/Breadth-first_search#Algorithm

You will of course need to tailor it for your own needs, but it does not really change the principal.

UPDATE

Ben Aaronson is right (comment bellow). This is not Breadth-first. It is Depth-first:

http://en.wikipedia.org/wiki/Depth-first_search#Pseudocode

Sorry for the confusion.

UPDATE 2

I think this also doesn't really address OP's problem, which is that what to do with each node depends on its parent, so you can't just push the individual nodes to the stack Ben Aaronson

I disagree. The tree traversal and the evaluation can be seperated from each other. Here is how you do it:

```<code>IEnumerable<Node> PostOrderDFS(Node root)
{
  ...
}
</code>```

Note that in post order DFS the children directly precedes the parent. A possible implementation is here:

Link

The only thing you need to change here is the return type, and make a yield return instead of Console.Write.

The evaluation would look like this:

```<code>bool Evaluate(Node root)
{
  List<Tuple<Node, bool>> traverseList = PostOrderDFS(root).Select(n => Tuple.Create(n, false)).ToList();
  for(int i = 0; i < traverseList.Count; ++i)
  {
    Tuple<Node, bool> tuple = traverseList[i];
    Node node = tuple.Item1;
    switch(node.Type)
    {
    case AND_OPERATOR:
        tuple.Item2 = true;
        foreach(int j = 1; j <= node.Childrens.Count; ++j)
        {
            bool childresult = traverseList[i-j].Item2;
            tuple.Item2 = tuple.Item2 && childresult;
        }
    case OR_OPERATOR:
        tuple.Item2 = false;
        foreach(int j = 1; j <= node.Childrens.Count; ++j)
        {
            bool childresult = traverseList[i-j].Item2;
            tuple.Item2 = tuple.Item2 || childresult;
        }
    case VALUE:
        tuple.Item2 = node.Value;
    }
  }

  return traverseList.Last().Item2;
}
</code>```

Body:
You are doing a Breadth-first search. There is typicall two way to approach this: recursive and non-recursive.
You can find a pseudo code for a non-recursive algorithm here:

http://en.wikipedia.org/wiki/Breadth-first_search#Algorithm

You will of course need to tailor it for your own needs, but it does not really change the principal.

UPDATE

Ben Aaronson is right (comment bellow). This is not Breadth-first. It is Depth-first:

http://en.wikipedia.org/wiki/Depth-first_search#Pseudocode

Sorry for the confusion.

UPDATE 2

I think this also doesn't really address OP's problem, which is that what to do with each node depends on its parent, so you can't just push the individual nodes to the stack Ben Aaronson

I disagree. The tree traversal and the evaluation can be seperated from each other. Here is how you do it:

IEnumerable<Node> PostOrderDFS(Node root)
{
  ...
}

Note that in post order DFS the children directly precedes the parent. A possible implementation is here:

Link

The only thing you need to change here is the return type, and make a yield return instead of Console.Write.

The evaluation would look like this:

bool Evaluate(Node root)
{
  List<Tuple<Node, bool>> traverseList = PostOrderDFS(root).Select(n => Tuple.Create(n, false)).ToList();
  for(int i = 0; i < traverseList.Count; ++i)
  {
    Tuple<Node, bool> tuple = traverseList[i];
    Node node = tuple.Item1;
    switch(node.Type)
    {
    case AND_OPERATOR:
        tuple.Item2 = true;
        foreach(int j = 1; j <= node.Childrens.Count; ++j)
        {
            bool childresult = traverseList[i-j].Item2;
            tuple.Item2 = tuple.Item2 && childresult;
        }
    case OR_OPERATOR:
        tuple.Item2 = false;
        foreach(int j = 1; j <= node.Childrens.Count; ++j)
        {
            bool childresult = traverseList[i-j].Item2;
            tuple.Item2 = tuple.Item2 || childresult;
        }
    case VALUE:
        tuple.Item2 = node.Value;
    }
  }

  return traverseList.Last().Item2;
}

ContentLicense: CC BY-SA 4.0


问:
When to fix something that is "wrong" but works fine

Short version:

I wrote some code that is not done "the right way" because, when I wrote it, I didn't know how to do it. Now that I know how to do it "the right way", how do I decide how to fix it?

Longer version with details:

java.util.DecimalFormat is not Thread safe. I have what's essentially an immutable Description object that is used all over my code over many different threads. To fix this problem, I created a wrapper class SynchronizedFormatter that basically just wraps a lock around the methods of DecimalFormat that I use.

The right way to do this is to use a ThreadLocal. I didn't even know what that was when I wrote the code the first time. Is it worth it to fix? The synchronized version works just fine. How do I decide, about this in specific and about this situation more generally?

Also, I should mention that I do need to make other changes to this class for more important reasons than "I did this bit wrong the first time". That's what got me thinking - if I'm mucking about in this class anyway, maybe I should fix these other things that are on my bucket list. But then I fear slippery slope...

This is not a duplicate of When to refactor because Refactoring means:

Improving a computer program by reorganising its internal structure without altering its external behaviour.

This question talks about actually modifying the behavior of the code (e.g. using synchronized vs. ThreadLocal. Perhaps it should not be tagged refactoring.

答:
It all comes down to risk management and gut feeling. Try to estimate the following:

How big are the costs of the mistake as it is in the code right now. Does it cause recurrent costs? Or costs in form of a risk that it might turn into a bug in the future? What is the cost and the probability of that bug?

How big are the costs of fixing it right now: Risk of breaking something + the time you (and the rest of the team) need.

Finally do this calculation for NOW and for some time in the future. Some kind of problems are not such a big problem right now, but might turn into an ugly mess in a year from now, but are then also much more expensive to fix. You probably want to fix them now.

In most projects you won't do these with actual numbers, but based on your gut feelings.

I generally try to reserve some time for this kind of code maintenance, and use it for the issues with the highest return per investment, and adjust the total time for this so my code base stays on a constant, high quality.


答:
Why not?

I'm a solo developer and I use BitBucket and Mercurial for my personal projects. Having the ability to revert and fork your code is just too good to pass up.


问:
Leaving intentional bugs in code for testers to find
We don't do this at our firm, but one of my friends says that his project manager asked every developer to add intentional bugs just before the product goes to QA. This is how it works:

Just before the product goes to QA, the development team adds some intentional bugs at random places in the code. They properly back up the original, working code to make sure that those bugs aren't shipped with the end product.

Testers are also informed about this. So they will test hard,
because they know there are bugs present and that not finding them might
be considered as a sign of incompetence.

If a bug (intentional or otherwise) has been found, they will be reported for the development team to fix. The development team then adds another intentional bug in a related section of the code just before the product goes to the second-level QA. The project manager says a tester should think like a developer and he/she should expect new bugs in sections where changes were made.

Well, this is how it goes. They say that this approach has following advantages.

Testers will be always on their toes and they will test like crazy.
That helps them to also find hidden (unintentional) bugs so developers
can fix them.

Testers feed on bugs. Not finding any bugs will affect their morale.
So giving them an easy one to find will help their morale.

If you ignore the scenario where one of these intentional bugs gets shipped with the final product, what are the other drawbacks we should consider before even thinking of adopting this approach?

Some clarifications:

They properly backup the original code in source control.

When a tester finds the intentional bug, the development team just ignores it. If tester finds out an unintentional (original) bug, the development team first checks whether it is caused by any of the intentional bugs. That is, the development team first tries to reproduce that on the original working code and tries to fix it if they can.

Just ignore the relationship issues between QA and development team. I specifically asked this question on Programmers, not on The Workplace. Consider that there is good rapport between QA and the development team, and they party together after working hours. The project manager is a nice, old gentleman who is always ready to support both teams (Godsend).

答:
Honestly, I'd call this behavior blatantly unethical and impractical. The PM is in need of some serious retraining, if not termination.

It demonstrates a fundamental lack of understanding of the concept of quality assurance. Testers should not think like developers: they should think like end users. The entire reason for having QA teams is that developers are inherently too close to the code; QA is supposed to maintain enough distance from the code that they can catch what the devs miss.

It wastes QA effort. Assuming that these bugs are not trivial -see below for when they are- it means that QA is spending time and resources investigating things that are already known, when they could be spending that effort seeking out what isn't known.

It wastes developer effort. For QA folks to catch these non-trivial bugs, developers must first write them. This requires yet further effort, spent not just coding the bugs, but also considering the software requirements and design.

It puts production at needless risk. It is only a matter of time before changes don't get merged in properly.

If it doesn't do the above, then it is pointless. If all of the known bugs are trivial, then they won't catch substandard workers: they will only catch people who are doing no work at all. There are better ways to do that.

It poisons the work environment. Your QA testers are professionals. They should be trusted to be professional until there is actual reason to suspect otherwise. When there is reason to suspect otherwise, there should be a proper investigation instead of these mind games. Anything else kills morale.

Seriously. Even if the PM's paranoia turns out to be well-founded in this specific case, this is not someone who has any business managing testers.


答: The problem of evaluating arithmetic expressions in a non-recursive way was solved and first published over 50 years ago.  You're looking for Dijkstra's shunting-yard algorithm.  The Wikipedia article has a great description of the algorithm, and there are tens of thousands of hits in Google, including a Literate Programs article that does a good job of combining description and implementation.</p>

Title: How to convert the following node evaluation procedure to a non recursive solution?

Body:
I have the following recursive method.

It evaluates a node (that represent a logical expression), using deep first search traversal :

```<code>EvaluateNode(Node node)
{
    bool result;
    switch(node.Type)
    {
        case AND_OPERATOR:
            result = true;
            foreach(Node nodeChild in node.Childrens)
            {
                childresult = EvaluateNode(nodeChild);
                result = result && childresult;
            }
        case OR_OPERATOR:
            result = false;
            foreach(Node nodeChild in node.Childrens)
            {
                childresult = EvaluateNode(nodeChild);
                result = result || childresult;
            }
        case VALUE:
            result = node.Value;
    }

    return result;
}
</code>```

I'd like to convert this to a stack/queue based, non recursive solution. Here is what I tried so far (incomplete) :

```<code>bool result;
stack.Push(node);
while(!stack.Empty())
{
    Node node = stack.Pop();
    switch(node.Type)
    {
        case AND_OPERATOR:
            foreach(Node nodeChild in node.Childrens)
            {
                stack.Push(nodeChild);
            }
        case OR_OPERATOR:
            foreach(Node nodeChild in node.Childrens)
            {
                stack.Push(nodeChild);
            }
        case VALUE:
            result = node.Value;
    }
}
</code>```

My guess is that I would need another stack for storing results but I have not been able to figure this out.


答:
I agree with all of the other answers, but the idea of defensive coding could also help here.

When practicing defensive coding, we write our code under the assumption that it's going to be used incorrectly; whether by us, or someone else. In this case, your shell script has been used incorrectly (run 59 times instead of once).

How could we defend against that? A simple but crude way would be to log a timestamp somewhere at the beginning of the run, and only run if the timestamp is found and more than, say, 20 hours old.

The problem with that coarse-grained approach is that we might want to manually trigger the script, eg. if some part of its functionality needs to be run again, but not all of it. In that case, a finer-grained approach would be better, eg. "if the latest DB backup is more than 20 hours old, backup the DB", "if the last announcement was sent out more than 20 hours ago, send out an announcement", etc.


问:
In SCRUM, should a long tedious task have a large size
Various articles on SCRUM methodology explicitly state that sizing should not focus on time, bur rather on the more abstract "complexity" or "effort needed" of the task.

How should a task be sized if the task is trivial to do, but requires a really long time to complete (say, half the sprint or the whole sprint)? Should it be sized 1, 2, 3, or more like 20-40-Inf?

As an example of such a task, I can give the following:

Convert the translated texts from the technical PDF documentation (10
  000+ texts) in the correct translations format for Android and iOS.

答:
When faced with similar tasks in the past what I have done is created a new task(s) to address the issue in a new way. One that better fits the scrum methodology and time frames.

In a situation similar to your example I have a task that comes at the end of every release cycle for translation of new strings in 6 different languages. Sometimes the strings numbers in the thousands. I created a system to extract these strings and format them in an appropriate way making it easier for translations so I had smaller tasks for creation of this tool. Then we have two very small tasks to ensure the strings are exported (sent off for translation by a service) and re-imported using this tool before release.

For many such mundane long tasks I would look at the problem differently and see if it can be automated in part or whole so that it is less time consuming in the future. I have often found that many times it just comes down to thinking about the issue in a different light, recasting the problem and then solving it.


答:
It is absolutely not the responsibility of your coordinator to send mail, only to ask that it be sent.  There are many reasons why a mail might not be sent, or delayed.  It is the responsibility of your mail class to

send valid mail

reject invalid mail

Log what it did (including unexpected failures to send valid mail)

All your coordinator has to do, with regard to mail, is

Ask for mail to be sent

React appropriately if the call to the mail object returns a failure.

Log what it did

If your tests for your mail class are comprehensive, you should be confident that valid mail requests will be sent and problems logged.  If, for some reason, your coordinator can create problem emails, this will become apparent very quickly in use and you will have all the data you need from the logs to fix the problem.  Please be relaxed about that; there is no way to create tests which guarantee no failure ever.  Content yourself with tests that test a components contract and that show the class always behaves responsibly both when a request honours the contract and when it breaks it.

It is important that components be testable in isolation.  If testing one component requires that others be fully present, then they really are not separate components and you risk creating one big ball of mud.  It is actually more dangerous than mocking, because you risk the creation of hidden dependencies on implementation details of those other components.  It also means that any internal changes to those components force an update to the build and test process for this one.  That scales terribly and wastes everybody's time.

Don't import any logic from the mail class into the mock.  Please do test for both success and failure of the mail class, but make those arbitrary events, not something using logic copied from the real class into your mock.  It is a waste of time and reintroduces the risk of hidden dependencies on implementation details.

Build your system cleanly based on these principles.  Trust the system. Don't complicate it into a mess because you want it to prove in each part that the whole system works.  That will fail and make failure more likely.

tl;dr

The law of Demeter applies to testing as well.


问:
Does snapshot change tracking break DDD principles?
I'm building a website with MVC 5 and Entity Framework 6, implementing the Unit of Work & Repository patterns, and - for flexibility and performance - would like to utilize Entity Framework's snapshot change tracking rather than proxy change tracking. The drawback of this feature is that navigation property fix-up is not done until DetectChanges is called by DbContext.

Adding an item to a collection...

```<code>order.LineItems.Add(orderLineItem);
</code>```

The inverse association will not be updated until DetectChanges is called...

```<code>lineItemOrder = orderLineItem.Order; // lineItemOrder == null
dbcontext.DetectChanges();
lineItemOrder = orderLineItem.Order; // lineItemOrder == order
</code>```

This navigation property fix-up behavior seems too specific to Entity Framework for the level of abstraction I'd like to see. Does this behavior break principles of Domain Driven Design, or can DetectChanges be considered a business transaction?

答:
It clearly not a business transaction, as one would expect lineItemOrder.Order to be readily populated without needing to call separate method,

With this approach not only it would be hard to debug, the domain model is not working as one expect it to work.

When designing a domain model one should try to keep domain model clean from supporting frameworks such as persistence.

personally I would not use

```<code>order.LineItems.Add(orderLineItem);
</code>```

when designing a domain model, instead I would use

```<code>order.AddLineItem(orderLineItem);
</code>```

and make the order.LineItems readonly

If it is possible to encapuslate the dbcontext.DetectChanges();inside the method AddLineItem it would be a better domain model even though it's not the optimal design,

Body:
It clearly not a business transaction, as one would expect lineItemOrder.Order to be readily populated without needing to call separate method,

With this approach not only it would be hard to debug, the domain model is not working as one expect it to work.

When designing a domain model one should try to keep domain model clean from supporting frameworks such as persistence.

personally I would not use

order.LineItems.Add(orderLineItem);

when designing a domain model, instead I would use

order.AddLineItem(orderLineItem);

and make the order.LineItems readonly

If it is possible to encapuslate the dbcontext.DetectChanges();inside the method AddLineItem it would be a better domain model even though it's not the optimal design,


答: I find value in it, personally. My projects are all checked into git repositories (all of which I keep on multiple machines in case of a hardware failure). The most useful features are branching (so that I can run an experiment that messes with half of my codebase, and not worry about blowing anything up permanently) and reverting (which is basically just undo on steroids; in case I find that I made some mistake that is out of regular undo range).</p>


答:
Take any trivial manual task and repeat it 10,000 times.

That will take effort - possibly a lot of effort.

Our profession is all about automation, so the obvious first approach should be "can I automate this?".  If you can, you probably should.

However, sometimes you can't automate as much as you'd like - maybe there's no budget for it, maybe defining the rules for automation are too difficult, etc.

It might be quicker to just do the task manually than to automate it.

I see no problem with sizing the task to reflect the work put in - even if it's totally mindless work.

Title: In SCRUM, should a long tedious task have a large size

Body:
Various articles on SCRUM methodology explicitly state that sizing should not focus on time, bur rather on the more abstract "complexity" or "effort needed" of the task.

How should a task be sized if the task is trivial to do, but requires a really long time to complete (say, half the sprint or the whole sprint)? Should it be sized 1, 2, 3, or more like 20-40-Inf?

As an example of such a task, I can give the following:

Convert the translated texts from the technical PDF documentation (10
  000+ texts) in the correct translations format for Android and iOS.


答:
Here is best solution I come with so far. It is based on Gábor Angyal answer.

It is slightly different from his implementation, so I post it here in case it would be useful for someone. Note that it still use recursivity, because the way GetNodesDFS() is implemented. I did it that way because the stack based implementation for DFS traversal is not trivial to write and code review (maintenance).

In the end I prefer that solution from the initial recursive example in OP, because the recursively part is separated from the main loop that deals with node evaluation. The real code is a lot more complex than these examples, and using recursivity as in the OP, I had to pass lot of variables for each recursive call (which is not a problem here)

```<code>nodesDFS = GetNodesDFS(nodes, x => x.Childrens.Reverse());
foreach(Node node in nodesDFS)
{
    switch(node.Type)
    {
        case AND_OPERATOR:
            result = true;
            for(i = 0 ; i < node.Childrens.Count ; i++)
            {
                result = result && results.Pop();
            }
            results.Push(result);
        case OR_OPERATOR:
            result = false;
            for(i = 0 ; i < node.Childrens.Count ; i++)
            {
                result = result || results.Pop();
            }
            results.Push(result);
        case VALUE:
            results.Push(node.Value);
    }
}
finalresult = evaluatedNodes.Pop();
</code>```

GetNodesDFS() is implemented this way (see remark above) :

```<code>GetNodesDFS(source, descendby)
{
   foreach (value in source)
   {
       foreach (child in descendby(value).GetNodesDFS(descendBy))
       {
           yield return child;
       }
       yield return value;
   }
}
</code>```

Body:
Here is best solution I come with so far. It is based on Gábor Angyal answer.

It is slightly different from his implementation, so I post it here in case it would be useful for someone. Note that it still use recursivity, because the way GetNodesDFS() is implemented. I did it that way because the stack based implementation for DFS traversal is not trivial to write and code review (maintenance).

In the end I prefer that solution from the initial recursive example in OP, because the recursively part is separated from the main loop that deals with node evaluation. The real code is a lot more complex than these examples, and using recursivity as in the OP, I had to pass lot of variables for each recursive call (which is not a problem here)

nodesDFS = GetNodesDFS(nodes, x => x.Childrens.Reverse());
foreach(Node node in nodesDFS)
{
    switch(node.Type)
    {
        case AND_OPERATOR:
            result = true;
            for(i = 0 ; i < node.Childrens.Count ; i++)
            {
                result = result && results.Pop();
            }
            results.Push(result);
        case OR_OPERATOR:
            result = false;
            for(i = 0 ; i < node.Childrens.Count ; i++)
            {
                result = result || results.Pop();
            }
            results.Push(result);
        case VALUE:
            results.Push(node.Value);
    }
}
finalresult = evaluatedNodes.Pop();

GetNodesDFS() is implemented this way (see remark above) :

GetNodesDFS(source, descendby)
{
   foreach (value in source)
   {
       foreach (child in descendby(value).GetNodesDFS(descendBy))
       {
           yield return child;
       }
       yield return value;
   }
}


问:
Is Emailing waste of time in Dev Teams
I know its not strictly related to what people ask here but I have to ask this anyway.

Isn't having long conversations/discussions over emails reduce one's productivity. I have joined this new company where people prefer emails alot. It's not a big company so every one is accessible to everyone and also senior techies tend to get together for a 30 mins session every day to discuss and plan things with managers and stake holders.

I think emails are great and should be used as long as they are to the point and don't waste anyone's time. In my professional experience getting or agreeing things over emails quickly becomes an endless game of ping-pong. Reaching to a conclusion often takes days just because.. oh well..not everyone has enough time to go through lengthy emails. Email subjects often become less subjective and more "re:re:re:re:fw:". After few "re:re's" and "fw:fw's" it becomes a nightmare to find what you're looking for since not every single thing in emails is a key-point so coming back to conversation after 8-9 months is like going through someone's source code writen in C.

It's also not the best approach for discussing ideas or agreeing over things as most people tend to be more reserved in email conversations than they are in real life because it's very easy to misinterpret one's tone.

Most of the times I find it much easier and quicker to send an email saying "Lets discuss thing X at xx:xx" followed by a quick call at agreed time rather than dragging the issue for days (or in some cases weeks). When needed I follow up with an email saying "well here's what we agreed on the phone".

Also people are generally more respectful to each other and open to discussions when talking face to face or over the phone.

Don't get me wrong, emails are important and should be used whenever they are absolutely necessary. But in small/medium sized teams why is this culture (of writing long stories i.e. emails) so so important ? why don't people use tools like Basecamp, redmine, wiki's instead.

How would you improve your team or company's communications so people become more productive and create a friendly environment.

Thank you for reading.

答:
I do use emails for:

Letting my supervisor know about something that is not immediately urgent, that doesn't require discussion, so I don't have to interrupt him.

Providing an electronic record ("proof") of a communication.

Disseminating documents.  The document itself might be the long story.

Reviewing a document (such as requirements) and providing detailed written feedback.

Asking clarifying questions about an email I received.

I do not use emails for:

Lengthy discussions, although I will email a summary of the discussion to the participants.

Diatribes, complaints, or anything that might come back to haunt me.

The usual abuses, like chain letters or pictures of my cat.

It might be handy to find out what it is about the corporate culture of this particular company that they prefer emails over other forms of communication.  To me, email has very specific uses, outside of which email can become difficult because it's such a constrained medium of communication (you can't see the other person's face or read their body language).

Title: Is Emailing waste of time in Dev Teams


问:
Any advice on how much browser memory to use?
I am writing an angular application, and I'm wondering how much client side memory to use.

I'm currently working on a scenario where there are 2 dropdowns.  The second will load new values depending on the selection of the first.  I'm thinking the max # of total records in the 2nd dropdown would be around 2000-3000 items, each being around 2k each.  Each selection would display probably 10-15 items of the 2000-3000.

Should I load the entire array into memory and parse the selected values from there, or should I read from the server every time the first dropdown changes?

I know for a desktop this wouldn't be a big deal.  But we support phones and tablets, and I'm not sure how much memory to worry about with these devices.

答:
What you're describing is called a "cascading dropdown."  It's commonly used by car websites to get Year, Make and Model.

I've seen a lot of these sites do an AJAX/JSON round trip for the sub-combos.  There's a bit of a lag if you do this, unless it happens before the user opens the second dropdown.  On a phone, I think you should probably do that instead of loading all of the items.  Phone users are already used to things happening a bit more slowly.

In any case, make sure you can get the server to send only the 20 bytes per entry that you need for the dropdown.  If you can't get it to do that, then taking the hit for all 2000 complete objects is probably out of the question (that's 4 megabytes, just for one page).


问:
Is there any harm in using amazon AWS as a development environment?
What modifications do I need to make to my workflow, and which skills do I need to learn in order to develop with Ruby On Rails on a Linux cloud server on Amazon Web Services (AWS)?

In particular, I am concerned that it won't work, or it will be much more difficult than developing on my Windows netbook, which is adequate for PHP development with XAMP.

答:
No - there is no harm in using an AWS Elastic Compute Cloud (EC2) instance for your development platform.

But you will have to learn some extra skills that you wouldn't need when developing on a local machine

how to use AWS Identity and Access Management (IAM),

how to use AWS billing (if you exceed the one year free micro instance), and

how to use SSH.

It is just as easy to run a Linux virtual machine to develop in Rails, or indeed to develop in another operating system such as FreeBSD, Mac OS X and Windows. Virtual machines can be slow on a netbook, but native development is often acceptable. RoR doesn't require much more resources than XAMP, but it depends on your application, so you will have to try it and see.

An AWS micro instance has similar power to a netbook (as of 2015.)


答:
Yes.  It is very very useful.  My friend Matt Gallagher posted this excellent article on this very subject just a few days ago to his "Cocoa With Love" iOS/MacOS development blog.

The article is Mac & Git centric but it covers the basics.

You may also be interested in the following StackExchange Questions (and their answers).

Are there advantages to using a dvcs for a solo developer?

What tools techniques can benefit a solo developer?

Git for a solo developer.


问:
How does one keep argument counts low and still keep third party dependencies separate?
I use a third party library. They pass me a POJO that, for our intents and purposes,  is probably implemented like this:

```<code>public class OurData {
  private String foo;
  private String bar;
  private String baz;
  private String quux;
  // A lot more than this

  // IMPORTANT: NOTE THAT THIS IS A PACKAGE PRIVATE CONSTRUCTOR
  OurData(/* I don't know what they do */) {
    // some stuff
  }

  public String getFoo() {
    return foo;
  }

  // etc.
}
</code>```

For many reasons, including but not limited to encapsulating their API and facilitating unit testing, I want to wrap their data. But I don't want my core classes to be dependent on their data (again, for testing reasons)! So right now I have something like this:

```<code>public class DataTypeOne implements DataInterface {
  private String foo;
  private int bar;
  private double baz;

  public DataTypeOne(String foo, int bar, double baz) {
    this.foo = foo;
    this.bar = bar;
    this.baz = baz;
  }
}

public class DataTypeTwo implements DataInterface {
  private String foo;
  private int bar;
  private double baz;

  public DataTypeOne(String foo, int bar, double baz, String quux) {
    this.foo = foo;
    this.bar = bar;
    this.baz = baz;
    this.quux = quux;
  }
}
</code>```

And then this:

```<code>public class ThirdPartyAdapter {
  public static makeMyData(OurData data) {
    if(data.getQuux() == null) {
      return new DataTypeOne(
        data.getFoo(),
        Integer.parseInt(data.getBar()),
        Double.parseDouble(data.getBaz()),
      );
    } else {
      return new DataTypeTwo(
        data.getFoo(),
        Integer.parseInt(data.getBar()),
        Double.parseDouble(data.getBaz()),
        data.getQuux();
      );
  }
}
</code>```

This adapter class is coupled with the other few classes that MUST know about the third party API, limiting it's pervasiveness through the rest of my system. However... this solution is GROSS! In Clean Code, page 40:

More than three arguments (polyadic) requires very special justification--and then shouldn't be used anyway.

Things I've considered:

Creating a factory object rather than a static helper method

Doesn't solve the problem of having a bajillion arguments

Creating a subclass of DataTypeOne and DataTypeTwo that has a dependent constructor

Still has a polyadic protected constructor

Create entirely separate implementations that conform to the same interface

Multiple of the above ideas simultaneously

How should this situation be handled?

Note this is not an anti-corruption layer situation. There's nothing wrong with their API. The problems are:

I don't want MY data structures to have import com.third.party.library.SomeDataStructure;

I can't construct their data structures in my test cases

My current solution results in very very high argument counts. I want to keep argument counts low, WITHOUT passing in their data structures.

That question is "what is a anti corruption layer?". My question is "how can I use a pattern, any pattern, to solve this scenario?"

I'm not asking for code, either (otherwise this question would be on SO), just asking for enough of an answer to enable me to write the code effectively (which that question does not provide).

答:
The strategy I've used when there are several initialization parameters is to create a type which just contains the parameters for initialization

```<code>public class DataTypeTwoParameters {
    public String foo;  // use getters/setters instead if it's appropriate
    public int bar;
    public double baz;
    public String quuz;
}
</code>```

Then the constructor for DataTypeTwo takes a DataTypeTwoParameters object, and DataTypeTwo is constructed via:

```<code>DataTypeTwoParameters p = new DataTypeTwoParameters();
p.foo = "Hello";
p.bar = 4;
p.baz = 3;
p.quuz = "World";

DataTypeTwo dtt = new DataTypeTwo(p);
</code>```

This gives a lot of opportunity to make it clear what all the parameters going into DataTypeTwo are and what they mean. You can also provide sensible defaults in the DataTypeTwoParameters constructor so that only values which need to be set can be done so in any order the consumer of the API likes.

Body:
The strategy I've used when there are several initialization parameters is to create a type which just contains the parameters for initialization

public class DataTypeTwoParameters {
    public String foo;  // use getters/setters instead if it's appropriate
    public int bar;
    public double baz;
    public String quuz;
}

Then the constructor for DataTypeTwo takes a DataTypeTwoParameters object, and DataTypeTwo is constructed via:

DataTypeTwoParameters p = new DataTypeTwoParameters();
p.foo = "Hello";
p.bar = 4;
p.baz = 3;
p.quuz = "World";

DataTypeTwo dtt = new DataTypeTwo(p);

This gives a lot of opportunity to make it clear what all the parameters going into DataTypeTwo are and what they mean. You can also provide sensible defaults in the DataTypeTwoParameters constructor so that only values which need to be set can be done so in any order the consumer of the API likes.


答:
I want to try to give a general answer. Because recursion is in fact using a stack (the call stack), any recursive function can be converted to an iterative one using a stack in a straight-forward way. You can just simulate the call stack:

The call stack contains:

the arguments

the return address

and the local variables.

Create a struct for these:

```<code>struct Context {
    Arguments args;
    LocalVars lvars;
    ExecutionState state;
}
</code>```

Arguments is easy: The arguments are set to the values of the arguments for the recursive call.

The tricky part is the "return address" or as I called it here the ExecutionState, and the LocalVars.

ExecutionState should keep track of where the call was made, to resume execution after the "recursive call" returns.
In your example, there are 3 possible states:

evaluating

returned from first call

returned from second call

LocalVars include the result, and the Children loop iterator. Because a call is made inside the loop, it has to be interrupted, and resumed later, so the loop iterator must be on the stack too.

Update: here I had written an untested C++/# pseudocode version. The OP (@tigrou) corrected some errors and made a working C# version, which he allowed me to include here:

```<code>enum ExecutionState
{
    S_EVAL,
    S_CALL1,
    S_CALL2
};

enum NodeType
{
    AND_OPERATOR,
    OR_OPERATOR,
    VALUE
};

class LocalVars
{
    public IEnumerator<Node> Enumerator;
    public bool Result;
}

class Context
{
    public Node Node;
    public LocalVars LocalVariables;
    public ExecutionState State;

    public Context(Node node, ExecutionState state)
    {
        this.Node = node;
        this.State = state;
        this.LocalVariables = new LocalVars();
    }
};

class Node
{
    public bool Value;
    public NodeType Type;
    public List<Node> Childrens;
};

static bool EvaluateNode(Node node)
{
    Stack<Context> stack = new Stack<Context>();
    Context context = new Context(node, ExecutionState.S_EVAL);
    stack.Push(context);

    bool returnresult = false;
    while(stack.Any())
    {
        context = stack.Pop();
        switch(context.State)
        {
            case ExecutionState.S_EVAL:
                switch(context.Node.Type)
                {
                    case NodeType.AND_OPERATOR:
                        if(context.LocalVariables.Enumerator == null)
                        {
                            context.LocalVariables.Enumerator = context.Node.Childrens.GetEnumerator();
                            context.LocalVariables.Result = true;
                        }

                        if(context.LocalVariables.Enumerator.MoveNext())
                        {
                            context.State = ExecutionState.S_CALL1;
                            stack.Push(context);        // push resume with S_CALL1

                            Context call = new Context(context.LocalVariables.Enumerator.Current, ExecutionState.S_EVAL);
                            stack.Push(call);           // push call
                        }
                        else
                        {
                            returnresult = context.LocalVariables.Result;    // no push -> return
                        }
                        break;

                    case NodeType.OR_OPERATOR:
                        if(context.LocalVariables.Enumerator == null)
                        {
                            context.LocalVariables.Enumerator = context.Node.Childrens.GetEnumerator();
                            context.LocalVariables.Result = false;
                        }

                        if(context.LocalVariables.Enumerator.MoveNext())
                        {
                            context.State = ExecutionState.S_CALL2;
                            stack.Push(context);        // push resume with S_CALL2

                            Context call = new Context(context.LocalVariables.Enumerator.Current, ExecutionState.S_EVAL);
                            stack.Push(call);           // push call
                        }
                        else
                        {
                            returnresult = context.LocalVariables.Result;    // no push -> return
                        }
                        break;

                    case NodeType.VALUE:
                        returnresult = context.Node.Value;  // no push -> return
                        break;
                }
                break;

            case ExecutionState.S_CALL1:
                context.LocalVariables.Result = context.LocalVariables.Result && returnresult;
                context.State = ExecutionState.S_EVAL;
                stack.Push(context);                        // continue with S_EVAL
                break;

            case ExecutionState.S_CALL2:
                context.LocalVariables.Result = context.LocalVariables.Result || returnresult;
                context.State = ExecutionState.S_EVAL;
                stack.Push(context);                        // continue with S_EVAL
                break;
        }
    }

    return returnresult;
}
</code>```

Body:
I want to try to give a general answer. Because recursion is in fact using a stack (the call stack), any recursive function can be converted to an iterative one using a stack in a straight-forward way. You can just simulate the call stack:

The call stack contains:

the arguments

the return address

and the local variables.

Create a struct for these:

struct Context {
    Arguments args;
    LocalVars lvars;
    ExecutionState state;
}

Arguments is easy: The arguments are set to the values of the arguments for the recursive call.

The tricky part is the "return address" or as I called it here the ExecutionState, and the LocalVars.

ExecutionState should keep track of where the call was made, to resume execution after the "recursive call" returns.
In your example, there are 3 possible states:

evaluating

returned from first call

returned from second call

LocalVars include the result, and the Children loop iterator. Because a call is made inside the loop, it has to be interrupted, and resumed later, so the loop iterator must be on the stack too.

Update: here I had written an untested C++/# pseudocode version. The OP (@tigrou) corrected some errors and made a working C# version, which he allowed me to include here:

enum ExecutionState
{
    S_EVAL,
    S_CALL1,
    S_CALL2
};

enum NodeType
{
    AND_OPERATOR,
    OR_OPERATOR,
    VALUE
};

class LocalVars
{
    public IEnumerator<Node> Enumerator;
    public bool Result;
}

class Context
{
    public Node Node;
    public LocalVars LocalVariables;
    public ExecutionState State;

    public Context(Node node, ExecutionState state)
    {
        this.Node = node;
        this.State = state;
        this.LocalVariables = new LocalVars();
    }
};

class Node
{
    public bool Value;
    public NodeType Type;
    public List<Node> Childrens;
};

static bool EvaluateNode(Node node)
{
    Stack<Context> stack = new Stack<Context>();
    Context context = new Context(node, ExecutionState.S_EVAL);
    stack.Push(context);

    bool returnresult = false;
    while(stack.Any())
    {
        context = stack.Pop();
        switch(context.State)
        {
            case ExecutionState.S_EVAL:
                switch(context.Node.Type)
                {
                    case NodeType.AND_OPERATOR:
                        if(context.LocalVariables.Enumerator == null)
                        {
                            context.LocalVariables.Enumerator = context.Node.Childrens.GetEnumerator();
                            context.LocalVariables.Result = true;
                        }

                        if(context.LocalVariables.Enumerator.MoveNext())
                        {
                            context.State = ExecutionState.S_CALL1;
                            stack.Push(context);        // push resume with S_CALL1

                            Context call = new Context(context.LocalVariables.Enumerator.Current, ExecutionState.S_EVAL);
                            stack.Push(call);           // push call
                        }
                        else
                        {
                            returnresult = context.LocalVariables.Result;    // no push -> return
                        }
                        break;

                    case NodeType.OR_OPERATOR:
                        if(context.LocalVariables.Enumerator == null)
                        {
                            context.LocalVariables.Enumerator = context.Node.Childrens.GetEnumerator();
                            context.LocalVariables.Result = false;
                        }

                        if(context.LocalVariables.Enumerator.MoveNext())
                        {
                            context.State = ExecutionState.S_CALL2;
                            stack.Push(context);        // push resume with S_CALL2

                            Context call = new Context(context.LocalVariables.Enumerator.Current, ExecutionState.S_EVAL);
                            stack.Push(call);           // push call
                        }
                        else
                        {
                            returnresult = context.LocalVariables.Result;    // no push -> return
                        }
                        break;

                    case NodeType.VALUE:
                        returnresult = context.Node.Value;  // no push -> return
                        break;
                }
                break;

            case ExecutionState.S_CALL1:
                context.LocalVariables.Result = context.LocalVariables.Result && returnresult;
                context.State = ExecutionState.S_EVAL;
                stack.Push(context);                        // continue with S_EVAL
                break;

            case ExecutionState.S_CALL2:
                context.LocalVariables.Result = context.LocalVariables.Result || returnresult;
                context.State = ExecutionState.S_EVAL;
                stack.Push(context);                        // continue with S_EVAL
                break;
        }
    }

    return returnresult;
}


答:
I think you might be interpreting Uncle Bob's recommendation too strictly. For normal classes, with logic and methods and constructors and such, a polyadic constructor does indeed feel a lot like code smell. But for something that is strictly a data container that exposes fields, and is generated by what is essentially a Factory object already, I don't think it's too bad.

You can use the Parameter Object pattern, as suggested in a comment, can wrap these constructor parameters for you, what your local data type wrapper is is already, essentially, a Parameter object. All your Parameter object will be doing is packing the parameters up (How will you create it? With a polyadic constructor?) and then unpacking them a second later into an object which is almost identical.

If you don't want to expose setters for your fields and call them, I think that sticking to a polyadic constructor inside a well-defined and encapsulated factory is fine.

Title: How does one keep argument counts low and still keep third party dependencies separate?

Body:
I use a third party library. They pass me a POJO that, for our intents and purposes,  is probably implemented like this:

```<code>public class OurData {
  private String foo;
  private String bar;
  private String baz;
  private String quux;
  // A lot more than this

  // IMPORTANT: NOTE THAT THIS IS A PACKAGE PRIVATE CONSTRUCTOR
  OurData(/* I don't know what they do */) {
    // some stuff
  }

  public String getFoo() {
    return foo;
  }

  // etc.
}
</code>```

For many reasons, including but not limited to encapsulating their API and facilitating unit testing, I want to wrap their data. But I don't want my core classes to be dependent on their data (again, for testing reasons)! So right now I have something like this:

```<code>public class DataTypeOne implements DataInterface {
  private String foo;
  private int bar;
  private double baz;

  public DataTypeOne(String foo, int bar, double baz) {
    this.foo = foo;
    this.bar = bar;
    this.baz = baz;
  }
}

public class DataTypeTwo implements DataInterface {
  private String foo;
  private int bar;
  private double baz;

  public DataTypeOne(String foo, int bar, double baz, String quux) {
    this.foo = foo;
    this.bar = bar;
    this.baz = baz;
    this.quux = quux;
  }
}
</code>```

And then this:

```<code>public class ThirdPartyAdapter {
  public static makeMyData(OurData data) {
    if(data.getQuux() == null) {
      return new DataTypeOne(
        data.getFoo(),
        Integer.parseInt(data.getBar()),
        Double.parseDouble(data.getBaz()),
      );
    } else {
      return new DataTypeTwo(
        data.getFoo(),
        Integer.parseInt(data.getBar()),
        Double.parseDouble(data.getBaz()),
        data.getQuux();
      );
  }
}
</code>```

This adapter class is coupled with the other few classes that MUST know about the third party API, limiting it's pervasiveness through the rest of my system. However... this solution is GROSS! In Clean Code, page 40:

More than three arguments (polyadic) requires very special justification--and then shouldn't be used anyway.

Things I've considered:

Creating a factory object rather than a static helper method

Doesn't solve the problem of having a bajillion arguments

Creating a subclass of DataTypeOne and DataTypeTwo that has a dependent constructor

Still has a polyadic protected constructor

Create entirely separate implementations that conform to the same interface

Multiple of the above ideas simultaneously

How should this situation be handled?

Note this is not an anti-corruption layer situation. There's nothing wrong with their API. The problems are:

I don't want MY data structures to have import com.third.party.library.SomeDataStructure;

I can't construct their data structures in my test cases

My current solution results in very very high argument counts. I want to keep argument counts low, WITHOUT passing in their data structures.

That question is "what is a anti corruption layer?". My question is "how can I use a pattern, any pattern, to solve this scenario?"

I'm not asking for code, either (otherwise this question would be on SO), just asking for enough of an answer to enable me to write the code effectively (which that question does not provide).


问:
Are there problems with using Reflection?
I don't know why, but I always feel like I am "cheating" when I use reflection - maybe it is because of the performance hit I know I am taking.

Part of me says, if it is part of the language you are using and it can accomplish what you are trying to do, then why not use it.  The other part of me says, there has to be a way I can do this without using reflection.  I guess maybe it depends on the situation.

What are the potential issues I need to look out for when using reflection and how concerned should I be about them?  How much effort is it worth spending to try to find a more conventional solution?

答:
Use of reflection is often harmful in OO languages if not used with great awareness.

I have lost count of how many bad questions I have seen on StackExchange sites where

The language in use is OO

The author wants to find out which type of object has been passed in and then call one of its methods

The author refuses to accept that reflection is the wrong technique and accuses anybody who points this out as "not knowing how to help me"

Here are typical examples.

Most of the point of OO is that

You group functions which know how to manipulate a structure/concept with the thing itself.

In any point of your code you should know enough about an object's type to know what relevant functions it has and ask it to call its particular version of those functions.

You ensure the truth of the previous point by specifying the correct input type for every function and having each function know no more (and do no more) than is relevant.

If at any point in your code, point 2 is not valid for an object you have been passed then one or more of these is true

The wrong input is being fed in

Your code is poorly structured

You have no idea what the hell you are doing.

Poorly skilled developers simply do not get this and believe that they can be passed anything in any part of their code and do what they want from a (hard-coded) set of possibilities.  These idiots use reflection a lot.

For OO languages, reflection should only be needed in meta activity (class loaders, dependency injection etc).  In those contexts, reflection is needed because you are providing a generic service to assist the manipulation/configuration of code which you know nothing about for a good and legitimate reason. In almost any other situation, if you are reaching for reflection then you are doing something wrong and you need to ask yourself why this piece of code does not know enough about the object that has been passed to it.


答:
explicitly state that sizing should not focus on time,

They've explicitly stated something ambiguous, "should not focus". Like a lot of agile principles, that doesn't mean never. The point of avoiding focusing on time is because it is difficult. Thinking in time can involve too much precision. If your sprint involved many complex tasks, generally, you should cut back on some.

In this case, it sounds like you have a very good idea of how long this is going to take. That's common with simple tasks. How many boards can you cut in a n hour if it takes 2 minutes to cut each board? You can convert your task into a percentage of the time of your sprint. Everything else gets the rest of the percentage.


答:
You really have two separate concerns here: wrapping an API and keeping the argument count low.

When wrapping an API, the idea is to design the interface as if from scratch, knowing nothing other than the requirements.  You say there is nothing wrong with their API, then in the same breath list a number of things wrong with their API:  testability, constructability, too many parameters in one object, etc.  Write the API you wish you had.  If that requires multiple objects instead of the one, do that.  If it requires wrapping one level higher, to the objects that create the POJO, do that.

Then once you have your desired API, the parameter count may no longer be an issue.  If it is, there are a number of common patterns to consider:

A parameter object, as in Erik's answer.

The builder pattern, where you create a separate builder object, then call a number of setters to set the parameters individually, then create your end object.

The prototype pattern, where you clone subclasses of your desired object with the fields already set internally.

A factory, which you are already familiar with.

Some combination of the above.

Note that these creational patterns often end up calling a polyadic constructor, which you should consider okay when it's encapsulated.  The problem with polyadic constructors isn't calling them once, it's when you're forced to call them every single time you need to construct an object.

Note that usually it's much easier and more maintainable to pass through to the underlying API by storing a reference to the OurData object and forwarding the method calls, rather than trying to reimplement its internals.  For example:

```<code>public class DataTypeTwo implements DataInterface {
  private OurData data;

  public DataTypeOne(OurData data) {
    this.data = data;
  }

   public String getFoo() {
    return data.getFoo();
  }

  public int getBar() {
    return Integer.parseInt(data.getBar());
  }
  ...
}
</code>```

Body:
You really have two separate concerns here: wrapping an API and keeping the argument count low.

When wrapping an API, the idea is to design the interface as if from scratch, knowing nothing other than the requirements.  You say there is nothing wrong with their API, then in the same breath list a number of things wrong with their API:  testability, constructability, too many parameters in one object, etc.  Write the API you wish you had.  If that requires multiple objects instead of the one, do that.  If it requires wrapping one level higher, to the objects that create the POJO, do that.

Then once you have your desired API, the parameter count may no longer be an issue.  If it is, there are a number of common patterns to consider:

A parameter object, as in Erik's answer.

The builder pattern, where you create a separate builder object, then call a number of setters to set the parameters individually, then create your end object.

The prototype pattern, where you clone subclasses of your desired object with the fields already set internally.

A factory, which you are already familiar with.

Some combination of the above.

Note that these creational patterns often end up calling a polyadic constructor, which you should consider okay when it's encapsulated.  The problem with polyadic constructors isn't calling them once, it's when you're forced to call them every single time you need to construct an object.

Note that usually it's much easier and more maintainable to pass through to the underlying API by storing a reference to the OurData object and forwarding the method calls, rather than trying to reimplement its internals.  For example:

public class DataTypeTwo implements DataInterface {
  private OurData data;

  public DataTypeOne(OurData data) {
    this.data = data;
  }

   public String getFoo() {
    return data.getFoo();
  }

  public int getBar() {
    return Integer.parseInt(data.getBar());
  }
  ...
}


问:
What's the best way to organize our unit tests
We've built up a substantial number of unit tests for our main program over the years. Several thousand. The problem is that we don't have a clear idea of what tests we have because there are so many. And that's a problem because we don't know where we're weak on tests (or where we have duplicates).

Our app is a reporting engine. So you can have a template that is used to test parsing (do we read all table properties), merging in data (did we keep the correct table properties in the merge), formatting the final page (is the table placed correctly on the page), and/or the output format (is the created DOCX file correct).

Add to this what we need to test. Take the padding around a table cell (we use Word, Excel, & PowerPoint for the report design). We have to test the padding across page break, for a table inside a cell, vertically merged cells, horizontally merged cells, a vertically & horizontally merged cell that contains a table with a vertically & horizontally merged cells in the inner table, where that table breaks across a page.

So what category does that test go in? Table padding, page breaks, nested cells, vertically merged cells, horizontall merged cells, or something else?

And how do we document these categories, name the unit tests, etc.?

Update: A number of people have suggested using coverage tools to verify that we have full coverage. Unfortunately that is of limited use in our case because the bugs tend to be due to specific combinations so it's code that has all been tested, but not in that combination.

For example, we had a customer yesterday that started a Word bookmark at the end of a forEach loop in their template (a Word document) and ended it in the beginning of the next forEach loop. This all used code that has unit tests against it, but we had not thought of the combination of a template expanding a bookmark start to be started 25 times, then ended 10 times (the two forEach loops had a different number of rows).

答:
The most common structure seems to be the src and test directory mirror.

```<code>src/module/class
test/module/class_test
</code>```

However, there is an alternative structure that I have seen which I now believe to be better.

```<code>src/module/class
src/module/class_test
</code>```

Since unit test tends to mirror the class they're testing, placing them in the same directory gives much easier access to the files so you can work on both side by side.

Body:
The most common structure seems to be the src and test directory mirror.

src/module/class
test/module/class_test

However, there is an alternative structure that I have seen which I now believe to be better.

src/module/class
src/module/class_test

Since unit test tends to mirror the class they're testing, placing them in the same directory gives much easier access to the files so you can work on both side by side.