问:
How can I test linkable/executable files that require re-hosting or retargeting?
Due to data protection, I cannot discuss fine details of the work itself so apologies

PROBLEM CASE

Sometimes my software projects require merging/integration with third party (customer or other suppliers) software. these software are often in linkable executables or object code (requires that my source code is retargeted and linked with it). When I get the executables or object code, I cannot validate its operation fully without integrating it with my system.

My initial idea is that executables are not meant to be unit tested, they are meant to be linkable with other system, but what is the guarantee that post-linkage and integration behaviour will be okay? There is also no sufficient documentation available (from the customer) to indicate how to go about integrating the executables or object files.

I know this is philosophical question, but apparently not enough research could be found at this moment to conclude to a solution. I was hoping that people could help me go to the right direction by suggesting approaches. To start, I have found out that Avionics OEM software is often rehosted and retargeted by third parties e.g. simulator makers. I wonder how they test them. Surely, the source code will not be supplied due to IPR rgulations.

UPDATE

I have received reasonable and very useful suggestions regarding this area. My current struggle has shifted into testing 3rd party OBJECT code that needs to be linked with my own source code (retargeted) on my host machine. How can I even test object code? Surely, I need to link them first to even think about doing anything. Is it the post-link behaviour that needs to be determined and scripted (using perl,Tcl, etc.) so that inputs and outputs could be verified? No clue!! :(

thanks,

答:
Treat the executable like a black box.  Make sure you have a software test harness that you can plug the executable into and verify it meets your expectations.  That test harness doesn't need to represent your full code suite. It just needs to handle the cases you care about.

Looking at it from a broader level, you've been given a library that purports to meet a contract or an API. You need to be able to verify that the executable will meet the contract in the manner that you expect it to.  Since you don't have the source code to visually inspect the implementation, you need to consider something else.  To me, this screams for having a test suite of unit / integration tests to validate behavior.

Simply assuming that the black box executable will perform as promised is a foolhardy assumption.  If the executable is mature, then it's a less risky proposition but there is still some risk.  Your end users / clients won't care if your software fails or if the black box fails.  To them, it is one and the same.  From their point of view, your software is at fault.

Have a test harness.  Create a step in your acceptance procedures to run new executables through the harness.  Ideally, nothing will ever turn up as wrong.  I've yet to see the ideal situation in software development though.


问:
Does understanding history of a programming language help in understanding the language?
Sometimes, the syntax of a language seems weird, I often think, why would someone make something like that, but definitely there is a reason and a history behind every aspect of a programming language.

Apart from being fascinating, It helps me remember the syntax and also the purpose that language solves.

Does knowing the background of languages like HTML & CSS (Okay, these are not programming-languages but still) JavaScript, C++, Objective C and even Java help in understanding the aspects of these languages?

答:
Martin Odersky opens his current presentation on Scala (at ScalaDays in NY and reprised on the West coast) with a history lesson.

What motivated the popularity of object-oriented programming?  "I'm an old guy and remember this."

He suggests that Scala occupies an historical moment in the transition from an object-oriented to a functional paradigm, or as he would prefer, a confluence of these paradigms in Scala's hybrid style.

His theme is that there's more than one way to do it in Scala, and that this is a good thing because the choices you make, in everyday programming, are informed by historical practice.  For example, whether you use combinators or a while loop; whether you extend a feature by subtyping or pattern matching to handle additional cases; or something as simple as whether you express an operation with a symbol (/: with the mnemonic of a falling domino) or name (foldLeft).

(One of his jokes is that /: seemed so cool but is obscure in practice; whereas ??? to mean "unimplemented" has immediate clarity for anyone looking at the code.)

History doesn't tell you that there is one right way to address a problem, but that there are two or three or nine.  Odersky says -- echoing Knuth's famous edict about premature optimization -- that you mustn't worry about getting it right the first time, that in fact one of the perks of a hybrid style is that you get to experience the pleasure of improving an expression, optimizing for performance or clarity or what have you, not once, but several times.  That's what makes programming fun!

For Scala, the tension between functional and imperative or object-oriented styles is not a battle to be won but an Auseinandersetzung, which is not Odersky's word but Heidegger's for the intimate love-hate relationship between two historical forces existing in close habitation.

Daniel Spiewak on the expression problem:
http://vimeo.com/user18356272/review/66548717/3531875329

ScalaDays talks are soon to be released on parleys.com.
http://parleys.com/channel/51ae1022e4b01033a7e4b6ca/presentations

ContentLicense: CC BY-SA 3.0


问:
Dividing a packet protocol into layers
I work on embedded systems, so frequently, I am required to implement protocols. When I do this I like to make nice clean layers.

However, this become difficult where the fields used by different layers are shared.

I like to think of the layers as offering a number of services following the spirit of OSI model:

Framing

  1. start byte / sequence (SOF)

  2. length of packet / message

  3. message integrity (CRC, xor checksum)

Network

 4. Source / Destination

Application

 5. Command / Response Type (how to interpret payload).

(I realize this is not the ISO model, but you get the point I hope.)

Sometimes the protocol exists on a point to point link (RS232 or tcp socket) so there is no concept of source and destination.

I would typically have a software layer for each of: Framing, Network and Application. The layer is typically a state machine processing bytes, or frames or packets. At the top, there is a hook point for the application specific functionality.

Typically as a packet moves up the stack and the layers are stripped off, I simply pass a pointer to the next inner scope. First pointer to SOF, then pointer to network fields and finally a pointer to the application payload.

As the fields are parsed they are added to a structure specific to the layer producing it. (A structure with a name like: Frame, Packet, Message / Command / Response) Each structure has a pointer to the packet buffer.

At the top I can deallocate the structure by calling free on each layer until at the bottom a pointer is available to free. (or return to a pool)

The question is how can I cleanly handle cases where the fields have dual use or are bit fields in a byte. (upper nibble is payload length, lower nibble is packet type, etc...)

An example of this is a simple packet format like this:

    <SOF> <CMD> <command specific payload> <CRC>

In this case the length of the packet is implied by the command code. So the CMD field (a single byte in this case) is shared between the framing and application layers.

I think in this case the framing layer has a lookup table for command to length and passes a pointer to the CMD field up to the application layer for handling in a structure.

答:
If you are dealing with a protocol that is so badly designed that the header fields of the difference conceptual layers are all over the place, then you don't really have much of a choice and you just have to treat it all as one big layer.
Fortunately, I have never encountered such a protocol and I think they tend to get obsoleted rather fast.

If you have a protocol where a layer boundary falls somewhere in the middle of a byte, then the lower layer's parsing code should not advance the buffer pointer past that byte (as it has not been fully consumed)  and both layers should be aware that the spare bits of that byte might contain valuable data for another layer and treat them accordingly. They don't have to know what those bits mean to the other layer.

To avoid buffer overruns if length fields in a message get corrupted, the parsing functions should always be informed how large the buffer is that they can inspect. If some protocol layer has part of its information at the tail end of the buffer (like often the case with CRC checksums), then the buffer length information can be used both for finding the CRC (the last two bytes of the buffer) and to avoid that the upper layers misinterpret the CRC bytes as data for them (by telling the upper layer that the buffer ends earlier).

This way, in the packet format

```<code><SOF> <CMD> <command specific payload> <CRC>
</code>```

the framing layer does not have to have any knowledge about the commands (or even the possibility that there might be more than one command in the message). The framing layer just checks the <SOF>, extracts the <CRC> from the end and validates the <CRC> by checking the intervening bytes as raw data. Then it tells the application layer that there is a message in the buffer starting at <CMD> and ending just before <CRC>.

Title: Dividing a packet protocol into layers

Body:
If you are dealing with a protocol that is so badly designed that the header fields of the difference conceptual layers are all over the place, then you don't really have much of a choice and you just have to treat it all as one big layer.
Fortunately, I have never encountered such a protocol and I think they tend to get obsoleted rather fast.

If you have a protocol where a layer boundary falls somewhere in the middle of a byte, then the lower layer's parsing code should not advance the buffer pointer past that byte (as it has not been fully consumed)  and both layers should be aware that the spare bits of that byte might contain valuable data for another layer and treat them accordingly. They don't have to know what those bits mean to the other layer.

To avoid buffer overruns if length fields in a message get corrupted, the parsing functions should always be informed how large the buffer is that they can inspect. If some protocol layer has part of its information at the tail end of the buffer (like often the case with CRC checksums), then the buffer length information can be used both for finding the CRC (the last two bytes of the buffer) and to avoid that the upper layers misinterpret the CRC bytes as data for them (by telling the upper layer that the buffer ends earlier).

This way, in the packet format

<SOF> <CMD> <command specific payload> <CRC>

the framing layer does not have to have any knowledge about the commands (or even the possibility that there might be more than one command in the message). The framing layer just checks the <SOF>, extracts the <CRC> from the end and validates the <CRC> by checking the intervening bytes as raw data. Then it tells the application layer that there is a message in the buffer starting at <CMD> and ending just before <CRC>.


问:
How to compute amoritized cost for a dynamic array?
I am trying to understand how to do the amortized cost for a dynamic table. Suppose we are using the accounting method.

Let A of size m be an array of n elements. When n = m, then we create a new array of size 4m, and then copy the elements of A to the new array. When n = m/4, then you create a new array of size m/4, and copy the elements to that array.

What I am confused about is how to calculate the costs.
From what I know so far:
Before the first expansion, you pay two dollars to insert. 1$ for the insert, and 1$ you just store with the element, so that you can use that later for a copy operation.

Then when you expand it, you use that stored $ to move the element to the new array.
Now in the new array the elements won't have any $ with them. But now as you insert a new element, you use 3$. 1$ for the insert, then one more for itself (for a future copy), and one more for the previous element that was just copied.

The problem here is, what if you have an array like this:

1$ 2$

Then insert an element

1$ 2 3$ _ _ _ _ _

Now how do you handle a delete operation?

答:
There are no amortized costs for an array like this.

Consider your example 1$ 2$. When adding one element, you will have to increase the size of the array. Now remove one element, and you have to reduce the size. Now again add one element. Etc.

Now consider a larger array with n = m. By increasing n, it gets more and more expensive to add and remove one single element. In fact, you can make the cost for adding and removing one single element arbitrarily high, and thus, there cannot be amortized costs.


问:
Does the VS version setting in Settings.settings matter?
Looking through the server vs local code on a humongous legacy project, I see this in Settings.settings:

```<code><?xml version='1.0' encoding='utf-8'?>

<SettingsFile xmlns="http://schemas.microsoft.com/VisualStudio/2004/01/settings" CurrentProfile="(Default)">
  <Profiles>
    <Profile Name="(Default)" />
  </Profiles>
  <Settings />
</SettingsFile>
</code>```

Is there a problem with having this VS2010 project reference 2004 this way? Or does it not matter?

答:
It's not a problem.

The "2004" actually is part of the namespace name, and it is not related with the version of Visual Studio.

Creating a new project with Visual Studio 2012 will create a settings file that references exactly the same namespace http://schemas.microsoft.com/VisualStudio/2004/01/settings.


问:
flow control solutions in Node.js - use async.waterfall?
Looking at node.js, and avoiding nesting callbacks. I found Async.js, can someone show me how can I rewrite this code using the async.waterfall method?

```<code>// db is a mongodb instance
db.open(function(err, client){
    client.createCollection("docs", function(err, col) {
         client.collection("docs", function(err, col) {
             for (var i = 0; i < 100; i++) {
                 col.insert({c:i}, function() {});
             }
             console.log('Insert done OK.');
         });
    });
});
</code>```

What problems does this naive solution with inner functions have, over the async method?

```<code>db.open(openAndInsert);

function openAndInsert(err, client) {
    var myCollection = "docs";

    client.createCollection(myCollection, openCollection);

    function openCollection(err, col) {
        client.collection(myCollection, insertIntoCollection);
    }

    function insertIntoCollection(err, col) {
        for (var idx = 0; idx < 100; idx += 1) {
            col.insert({c:idx}, function () {});
        }
        console.log('Insert done OK.');
    }
}
</code>```

The three levels of nesting in the original code seem like a code smell, but I'm not sure either my home rolled or the async solution are universally better. Would anyone prefer just leaving the nested functions as is? If so, how deep would the nesting have to be before going using some type of flow control?

答:
You asked several questions, I will respond tothe last two.

Callback nesting using anonymous functions is the opposite of code reuse and DRY. It makes code harder to read by splitting logic in one function by putting a callback right in middle.

Usually when you try to make more general functions to use for callbacks, you run into issues just trying to figure out what to do in different situations (like errors). You end up making a bunch of nested function calls and spaghetti code trying to account for everything.

Callbacks are there. That is the nature of nodejs.

Something like asyncjs or qcnode allows you to write code in a linear fashion that is more understandable and debuggable.

I feel that you should have little stub callbacks that handle errors and decide if you can go forward with what you trying to do, otherwise they should abort. I've been using qcnode (and it's ancestors) for years and I think this latest version is simple to use and very helpful.

Full disclosure: I am the publisher and main developer for qcnode.


问:
Working for free?
I came across this article Work for Free that got me thinking.

The goal of every employer is to gain
  more value from workers than the firm
  pays out in wages; otherwise, there is
  no growth, no advance, and no
  advantage for the employer.
  Conversely, the goal of every employee
  should be to contribute more to the
  firm than he or she receives in wages,
  and thereby provide a solid rationale
  for receiving raises and advancement
  in the firm.

I don't need to tell you that the
  refusenik didn't last long in this
  job.

In contrast, here is a story from last
  week. My phone rang. It was the
  employment division of a major
  university. The man on the phone was
  inquiring about the performance of a
  person who did some site work on
  Mises.org last year. I was able to
  tell him about a remarkable young man
  who swung into action during a crisis,
  and how he worked three 19-hour days,
  three days in a row, how he learned
  new software with diligence, how he
  kept his cool, how he navigated his
  way with grace and expertise amidst
  some 80 different third-party plug-ins
  and databases, how he saw his way
  around the inevitable problems, how he
  assumed responsibility for the
  results, and much more.

What I didn't tell the interviewer was
  that this person did all this without
  asking for any payment. Did that fact
  influence my report on his
  performance? I'm not entirely sure,
  but the interviewer probably sensed in
  my voice my sense of awe toward what
  this person had done for the Mises
  Institute. The interviewer told me
  that he had written down 15 different
  questions to ask me but that I had
  answered them all already in the
  course of my monologue, and that he
  was thrilled to hear all these
  specifics.

The person was offered the job. He had
  done a very wise thing; he had earned
  a devotee for life.

The harder the economic times, the
  more employers need to know what they
  are getting when they hire someone.
  The job applications pour in by the
  buckets, all padded with degrees and
  made to look as impressive as
  possible. It's all just paper. What
  matters today is what a person can do
  for a firm. The resume becomes pro
  forma but not decisive under these
  conditions. But for a former boss or
  manager to rave about you to a
  potential employer? That's worth
  everything.

What do you think? Has anyone here worked for free? If so, has it benefited you in any way? Why should(nt) you work for free (presuming you have the money from other means to keep you going)? Can you share your experience?

Me, I am taking a year out of college and haven't gotten a degree yet so that's probably why most of my job applications are getting ignored. So im thinking about working for free for the experience?

答:
I was able to tell him about a
  remarkable young man who swung into
  action during a crisis, and how he
  worked three 19-hour days

However, if this "remarkable young person" instead worked six 9-hour days and billed them per hour, I am sure he wouldn't get such "remarkable" comments.
Each and every employer tries to get as much free lunch  as possible.

I had an employer who made a big fuss about me taking a half a day off for a private event, even though I regularly did overtime without being paid for it.

I once had a guy literally call me a "genius" because he was trying to get me to make him some software for free. Of course at the risk of not being referenced as a "genius" (yeah, right)  to other employers by this guy, I refused.

If you need a reference, why not develop a project on your own and show it to potential employers (I mean those who can actually pay a decent wage). Plus you keep the IP rights and don't have to go through the hassle of working with a customer (requirements change, etc).

ContentLicense: CC BY-SA 2.5

Title: Working for free?


问:
Object schemas shared between web services
My question is about how to create a definition for an object that is handled by different web services.

A brief description of my current scenario and why I think it's a problem:

A PHP web application provides AJAX endpoints for populating various parts of my web app. The endpoint provides access to User and Project entities. A node.js application uses sockjs to deliver User and Project events in real time to my web app.

Here's the problem: The schema of the JSON objects delivered by the node.js service is slightly different to the same objects provided by the PHP endpoints. This is bad because it makes much my client size code hard to re-use, and there's lots of "if it came from node, access this property; if it came from AJAX, access this other property" type logic. Ugh!

The code base is too big to do a one time refactor and make sure all devs adhere to the new design.

I want a way to share information between my node.js app and my php app so they both know how they should define certain objects.

What is the most common way of solving this kind of problem?

答:
Normalize any outgoing JSON from your node.js webservice.

For example, for each schema you have, create a wrapper function that modifies your JSON data to match the format of your PHP data. Even if you just define a simple translation like this:

```<code>function convertUser(user) {
    return {
        id: user._id,
        anotherField: user.another_field,
        // ...
    };
}
</code>```

My bigger concern is the reason for this. Are you just dumping data directly from the database? This sort of normalization should be part of the dump process rather than blindly giving back whatever is requested. As database fields (or schemas, in your case) change, your API should not.

Body:
Normalize any outgoing JSON from your node.js webservice.

For example, for each schema you have, create a wrapper function that modifies your JSON data to match the format of your PHP data. Even if you just define a simple translation like this:

function convertUser(user) {
    return {
        id: user._id,
        anotherField: user.another_field,
        // ...
    };
}

My bigger concern is the reason for this. Are you just dumping data directly from the database? This sort of normalization should be part of the dump process rather than blindly giving back whatever is requested. As database fields (or schemas, in your case) change, your API should not.


问:
Gathering all data in single iteration vs using functions for readable code
Say I have an array of runners with which I need to find the tallest runner, the fastest runner, and the lightest runner. It seems like the most readable solution would be:

```<code>runners = getRunners();
tallestRunner = getTallestRunner(runners);
fastestRunner = getFastestRunner(runners);
lightestRunner = getLightestRunner(runners);
</code>```

..where each function iterates over the runners and keeps track of the largest height, greatest speed, and lowest weight. Iterating over the array three times, however, doesn't seem like a very good idea. It would instead be better to do:

```<code>int greatestHeght, greatestSpeed, leastWeight;
Runner tallestRunner, fastestRunner, lightestRunner;
for(runner in runners){
    if(runner.height > greatestHeight) { greatestHeight = runner.height; tallestRunner = runner; }
    if(runner.speed > ...
}
</code>```

While this isn't too unreadable, it can get messy when there is more logic for each piece of information being extracted in the iteration.

What's the middle ground here? How can I use only a single iteration while still keeping the code divided into logical units?

答:
Create a RunnerStats class that calculates the stats in a single for loop, just as you do in your second code snippet.

Then you read the stats into the variables via getters. The getters only return the already calculated values, they don't calculate anything.

That way you get the best of both solutions: efficiency and legibility.

```<code>runners = getRunners();

RunnerStats rStats = new RunnerStats(runners);

tallest = rStats.getTallets();
fastest = rStats.getFastest();
lightest = rStats.getTallest();
</code>```

Body:
Create a RunnerStats class that calculates the stats in a single for loop, just as you do in your second code snippet.

Then you read the stats into the variables via getters. The getters only return the already calculated values, they don't calculate anything.

That way you get the best of both solutions: efficiency and legibility.

runners = getRunners();

RunnerStats rStats = new RunnerStats(runners);

tallest = rStats.getTallets();
fastest = rStats.getFastest();
lightest = rStats.getTallest();

ContentLicense: CC BY-SA 4.0


问:
Is it okay for an application to check for automatic updates in less than 20 hour interval?
I have a desktop application that has the ability to automatically update itself on the next restart (without the user's consent - but this is another issue altogether). Assuming that the user would never notice anything related to application updating (such as a progress bar, or pop-up requiring restart), and that our server would support the request spam load, is there any reason why it should not check for updates in less than 20 hour interval?

The reason I'm asking this is because all applications that I know that have auto-update capability check for update every 20 to 24 hours and at startup. I was just wondering if there was an ethical rule about it, or simply because of the risk of overloading the server.

答:
Indeed it's the current mania, and it PITA. After every install I have to run hijackthis and weed out parazites. Or set firewall to tame programs that I installed to say edit a picture, but they think to own my network connections, and do whatever stuff they feel like.

No, it is not okay for a program to check for updates without user's consent and agreement in 20 hours, or even in 20 years.  You want to play fair, implement an option where the user can set his preference.

If you ask the question differently, whether it's okay to offer that as default, I'm not against.


答:
This does what I need it to using async.js:

```<code>db.open(function (err, client) {
    async.waterfall([
        function (callback) {
            client.createCollection("docs", callback);
        },
        function (collection, callback) {
            for (var i = 0; i < 100; i++) {
                collection.insert({c:i}, function() {});
            }
            callback(null, 'ok');
        }
    ],
    function (err, result) {
        console.log('result: ', result);
    });
});
</code>```

By putting the async code inside the anonymous function passed to db.open the 'client' variable was visible to the first async function. Got that idea from this SO answer

Title: flow control solutions in Node.js - use async.waterfall?

Body:
Looking at node.js, and avoiding nesting callbacks. I found Async.js, can someone show me how can I rewrite this code using the async.waterfall method?

```<code>// db is a mongodb instance
db.open(function(err, client){
    client.createCollection("docs", function(err, col) {
         client.collection("docs", function(err, col) {
             for (var i = 0; i < 100; i++) {
                 col.insert({c:i}, function() {});
             }
             console.log('Insert done OK.');
         });
    });
});
</code>```

What problems does this naive solution with inner functions have, over the async method?

```<code>db.open(openAndInsert);

function openAndInsert(err, client) {
    var myCollection = "docs";

    client.createCollection(myCollection, openCollection);

    function openCollection(err, col) {
        client.collection(myCollection, insertIntoCollection);
    }

    function insertIntoCollection(err, col) {
        for (var idx = 0; idx < 100; idx += 1) {
            col.insert({c:idx}, function () {});
        }
        console.log('Insert done OK.');
    }
}
</code>```

The three levels of nesting in the original code seem like a code smell, but I'm not sure either my home rolled or the async solution are universally better. Would anyone prefer just leaving the nested functions as is? If so, how deep would the nesting have to be before going using some type of flow control?

Body:
This does what I need it to using async.js:

db.open(function (err, client) {
    async.waterfall([
        function (callback) {
            client.createCollection("docs", callback);
        },
        function (collection, callback) {
            for (var i = 0; i < 100; i++) {
                collection.insert({c:i}, function() {});
            }
            callback(null, 'ok');
        }
    ],
    function (err, result) {
        console.log('result: ', result);
    });
});

By putting the async code inside the anonymous function passed to db.open the 'client' variable was visible to the first async function. Got that idea from this SO answer


问:
Two contradicting definitions of Interface Segregation Principle – which one is correct?
When reading articles on ISP, there seem to be two contradicting definitions of ISP:

According to first definition ( see 1, 2, 3), ISP states that classes implementing the interface shouldn't be forced to implement functionalities which they don't need. Thus, fat interface IFat

```<code>interface IFat
{
     void A();
     void B();
     void C();
     void D();
}

class MyClass: IFat
{ ... }
</code>```

should be split into smaller interfaces ISmall_1 and ISmall_2

```<code>interface ISmall_1
{
     void A();
     void B();
}

interface ISmall_2
{
     void C();
     void D();
}

class MyClass:ISmall_2
{ ... }
</code>```

since this way my MyClass is able to implement only the methods it needs ( D() and C() ), without being forced to also provide dummy implementations for A() and B():

But according to the second definition ( see 1 ,  2, answer by Nazar Merza), ISP states that MyClient calling methods on MyService shouldn't be aware of methods on MyService that it doesn't need. In other words, if MyClient only needs the functionality of C() and D(), then instead of

```<code>class MyService
{
    public void A();
    public void B();
    public void C();
    public void D();
}

/*client code*/
MyService service = ...;
service.C();
service.D();
</code>```

we should segregate MyService's methods into client-specific interfaces:

```<code>public interface ISmall_1
{
     void A();
     void B();
}

public interface ISmall_2
{
     void C();
     void D();
}

class MyService:ISmall_1, ISmall_2
{ ... }

/*client code*/
ISmall_2 service = ...;
service.C();
service.D();
</code>```

Thus with the former definition, the goal of ISP is to "make the life of classes implementing IFat interface easier", while with the latter the goal of ISP is to "make the life of clients calling methods of MyService easier".

Which of the two different definitions of ISP is actually correct?

@MARJAN VENEMA

1.

So when you are going to split IFat into smaller interface, which
methods end up in which ISmallinterface should be decided based on how
cohesive the members are.

While it makes sense to put cohesive methods within the same interface, I thought with ISP pattern the needs of the client take precedence over the "cohesiveness" of an interface. In other words, I thought with ISP we should lump within the same interface those methods needed by particular clients, even if that means leaving out of that interface those methods that should, for the sake of cohesiveness, also be put inside that same interface?

Thus, if there were lots of clients that will only ever needed to call CutGreens, but not also GrillMeat, then to adhere to ISP pattern we should only put CutGreens inside ICook, but not also GrillMeat, even though the two methods are highly cohesive?!

2.

I think that your confusion stems from the a hidden assumption in the
first definition: that the implementing classes are already following
the single responsibility principle.

By "implementing classes not following SRP" are you referring to those classes that implement IFat or to classes that implement ISmall_1 / ISmall_2? I assume you're referring to classes that implement IFat? If so, why do you assume they don't already follow SRP?

thanks

答:
ISP is all about isolating the client from knowing more about the service than it needs to know (protecting it against unrelated changes, for example). Your second definition is correct. To my reading, only one of those three articles suggests otherwise (the first one) and it is just plain wrong. (Edit: No, not wrong, just misleading.)

The first definition is much more tightly linked to LSP.


问:
How to securely implement auto-login
I've read many, many, many posts on how "you're probably storing passwords wrong". They are always referring to storing passwords on a server into which a user is logging; they basically rehash (pun intended) ubiquitous advice like make sure to salt the passwords, etc. etc. However, I've never seen an article on best practises for storing passwords on a client so that the client doesn't have to log in manually every time they want to log in; the "remember me" feature.

Many pieces of software have this feature, from browsers to programs like Dropbox.

I did read an old article recently about how Dropbox was storing an ID on your computer that you could just copy/paste to another computer and start Dropbox and be logged in as the device you got the ID from; no login, no nothing, and full access to the Dropbox account. This seems like a really stupid design, but I can't think of any better way to do it.

I'm not even sure how to avoid storing something like a cookie in plain-text. If you encrypt it, where do you store the key to decrypt it?

The only way I see to not introduce security vulnerabilities is to remove the autologin feature and make the user type their password every time they want to use  a service, but that's a usability struggle and users are spoiled to expect not to have to do that.

What can I read about locally storing credentials safely to implement the automatic login feature? If the principles are too simple for an entire article, what are they? The software in question should not depend on features not present on all platforms (like the "keychain" some linux distributions have).

答:
Amazon (and many others) use a hybrid approach.  They provide autologin for browsing, adding items to the cart, and placing orders using credit cared/shipping address combinations you have used before.  However, they require you to enter your password for many actions such as adding credit cards, adding/changing shipping addresses, updating passwords, viewing past orders(optionally to the user), and lots of other account settings.

So yeah, people who gain access to your computer could hijack your session, but you still get what they order! (More importantly, the incentive to hijack a session is pretty much negated.) But if someone has access to my computer, I have bigger problems than people stealing the average site sessions.

If you have parts of your application that don't need as high of security, you can choose a hybrid model where you store a session ID (hashed or whatever if you'd like) to auto login users to low security portions of the site, but require them to enter the password when the enter higher security areas and delete the high security token when the session ends.

Of course if this is a banking level site, than auto login isn't an option.  Again, sites that use these types of security assume the value of the data they are protecting and the added convenience to the user out weigh the potential risk of a hijacked session.  If you feel that is not the case for your application, then don't implement auto logins.  You need to access what level of security/usability trade offs are appropriate for your use case.

Title: How to securely implement auto-login


问:
JSON or XML for parsing for a Windows Store 8 applicaiton?
I am getting some data from Gov tracker (http://www.govtrack.us/developers/api)
and creating a Windows 8 Store application..

I started out trying to use the HttpClient to get the JSON and then use Json2Charp.com to convert it to classes... But then I had no idea what to do with this giant class and
the line

```<code>  var contacts = JsonArray.Parse(data);
</code>```

would not work..

So now I requested it as XML and I am using XML to LINQ to slowly get what I need ..for example..

```<code>    var things = from x in xdoc.Descendants("person")
                     select new Person
                     {
                         firstname = x.Element("firstname").Value
                     };
</code>```

But in this case and in general what is the easiest way?  Is it using XML for this windows 8 application and using JSON to javascript applications? (since I always hear about how JSON fits so well with javascript)

At the moment since I could not get the JSON deserialization to work I guess XML is easier in this case?

答:
I'm going to bet that the data retrieved from most REST URLs is a JSON object, not an array. The distinction is something like this:

```<code>array===> [1, 2, 3, 4]
object containing an array===> { "numbers": [1, 2, 3, 4] }
</code>```

I don't know the library you're using, but I'm betting the method you're looking for is JsonObject.Parse(data), and then something to retrieve the specific property you want (ie, "numbers" above). You could edit your post with some sample text data if you want us to confirm. I would recommend if the data is not public, then replace the actual values with made-up stuff to maintain data privacy.

Which one is easier to use may depend on what you're used to, or which developers you tend to work with. Many would argue in favor of JSON, since it could be easier to program for, supports arrays directly, and it tends to have less of a network footprint. Still, it does seem to be a not-so-consequential matter of preference and your app could certainly work fine just using XML. (There may also be some data types more easily represented in an XML-based format; for instance, declarative UI languages like HTML)

Body:
I'm going to bet that the data retrieved from most REST URLs is a JSON object, not an array. The distinction is something like this:

array===> [1, 2, 3, 4]
object containing an array===> { "numbers": [1, 2, 3, 4] }

I don't know the library you're using, but I'm betting the method you're looking for is JsonObject.Parse(data), and then something to retrieve the specific property you want (ie, "numbers" above). You could edit your post with some sample text data if you want us to confirm. I would recommend if the data is not public, then replace the actual values with made-up stuff to maintain data privacy.

Which one is easier to use may depend on what you're used to, or which developers you tend to work with. Many would argue in favor of JSON, since it could be easier to program for, supports arrays directly, and it tends to have less of a network footprint. Still, it does seem to be a not-so-consequential matter of preference and your app could certainly work fine just using XML. (There may also be some data types more easily represented in an XML-based format; for instance, declarative UI languages like HTML)


问:
How do I convert a list of Requirements into Constraints?
I am trying to prepare my first software design document. I am self-taught and have no formal training in CS. Having done a wee bit of reading up on it beforehand, I have created a list of Requirements, Qualities and Non-Qualities for the system, which provide an overview from a managerial viewpoint on what the project is tasked with providing. The intent was for these to be convertible into design Constraints, which in turn would guide justifiable design decisions. So far they do not get into many specifics of what resources are to be provided, but are general in that they should apply to all resources present in the system.

I am having difficulty, however, in proceeding to the next step. What exactly is a Design Constraint supposed to look like? How specific or general should it be? How do I convert domain Requirements into Constraints? Have I already gone nuts and over-specified things? :-)

Background

I am the only programmer at a small service company. We have a current HTML with PHP PIs application which grew organically and has no test infrastructure. Editing one bit has repercussions and unintended consequences in far flung parts of the app. I want to replace it with a more professionally designed (in fact, any kind of designed) one, object-based with a test suite. Management doesn't know about programming and I need to know which of the current features are cruft, which workflows are bogged down, etc. This is intended to be my guidance both during a perpetually postponed design meeting and during implementation.

So far, I have the following:

Terminology

"Owner" refers to a company or division running their own deployment of the Software, with data independent of any other deployments.

"Developer" means an individual who is either a programmer with write access to the source code, or a database admin working for an Owner.

"User" means an individual who has authenticated access to a deployment.

"Staff" means a User who works for an Owner.

"Client" refers to a User who is a customer of an Owner.

REQUIREMENTS

What features must the service exhibit?

Platforms: Access to the service must be available via a variety of recent-to-modern, general business computing devices. (i.e. desktop, laptop, tablet and smartphones as of 2013).

Mobility: Reasonable efforts at providing access to the service for all Users must be made, regardless of their physical location.

Secure: All data must require authentication and authorization to access, and non-safe requests must come with sufficient confirmation that they were initiated by user intent.

Access Controls: Resources and sets of resources must have variable authorization permissions.

Admin Powers: Read and write authorization to individual resources and sets of resources must be seperate.

Unbreakable: The system must not be able to be put into a "broken" state by Users.

No Clobber: A User should not be allowed to overwrite another user's changes unknowingly.

Off-line: A User's scheduled events for the current day must be readable off-line.

Rapid Bootstrap: New Staff must be able to get up to speed on the internal side of the system quickly.

Owner Agnostic: Nothing specific to one Owner should be present in a new, clean deployment for another Owner.

Brandable: An Owner must be able to configure the system to exhibit their branding and corporate specifics.

Safe Data: A frequent and reliable back-up of all data must be easily scheduled.

QUALITIES

What other features would we like the end product to exhibit?

Fast developer turn-around for bug fixes.

Fast prototyping for new features.

Error-free implementation of new features.

Regression-free changes.

Attractive Client UI.

Efficient Staff UI.

Widest device and OS support reasonably achievable.

All accountability/blame data (who did what, when?) should be involatile.

All other data should be editable by a user with sufficient authorization, without needing a Developer.

Data back-ups should be creatable on demand by a sufficiently authorized user.

Data back-ups should be restorable on demand by a sufficiently authorized user.

NON-QUALITIES

What features are not important and will allow flexibility of design?

Programming language choice

UI monolingualism

We do not need a generic resource import or export system.

[this list is incomplete]

答:
Since this post is tagged as "architecture" I'll weigh in from an architecture perspective.

You're on the right track with respect to the kinds of requirements you are gathering.  I would classify what you've shared more generally as architectural drivers.  That is, some minimalist set of information that you can use to drive the architecture design.  Most folks divide architectural drivers into four buckets.

Technical Constraints

Business Constraints

High-level functional requirements

Quality Attributes or quality requirements

See discussion on "How to handle 'ilities' (or non-functional requirements) for a project planning/prioritization/work-allocation?" and "Why bother differentiating between functional and nonfunctional requirements?" for some discussion and background.

Constraints are immovable, absolutely must have decisions made by at least one stakeholder that have significant influence over the design of the architecture.  Here is some specific advice with respect to dealing with constraints.

Always be very careful about choosing constraints.

Avoid to the greatest extent possible artificially constraining the system -- have a good reason for creating a constraint.

Design decisions can change.  Constraints cannot.

Design decisions that you make may become constraint-like due to other influencing factors (time, budget, brittleness, etc.).

Requirements are always negotiable, therefore they are never constraints...

It's subtle, but there is a huge difference between a constraint and a design decision.  A design decision is something that you, as the architect, chose therefore it is something that you can also change.  A constraint can never be changed.  This is important because it clearly lays out for the team and architect what you control/influence vs. what is influencing you.

I like to think of constraints as load bearing walls for your system.  If you were building a house, the load bearing walls are the ones that absolutely cannot be moved without serious - possibly catastrophic - costs.  Deferring major decisions until the last possible moment as advised in other answers is great advice.  But the assumptions that you make in the beginning of the project - especially the things that are flexible vs. immovable will haunt you for the entire project.

Some simple examples --

Technical Constraint: "Customer says the system must run on Apache/Linux"

Business Constraint: "Go-live must be before the November trade show"

Design Decision that becomes constraint-like: "We're going to use MongoDb to store the data."  You could change your mind later, but this was possibly a significant decision.  Frameworks and toolkits often fall into this category.

Design Decision: "We're going to use heartbeat to detect server failures"


问:
Memento with optional state?
EDIT:
As pointed out by Steve Evers and pdr, I am not correctly implementing the Memento pattern, my design is actually State pattern.

Menu Program

I built a console-based menu program with multiple levels that selects a particular test to run.  Each level more precisely describes the operation. At any level you can type back to go back one level (memento).

```<code>Level 1: Server Type?
             [1] Server A [2] Server B
Level 2: Server environment?
          [1] test [2] production
Level 3: Test type?
          [1] load [2] unit
Level 4: Data Collection?
          [1] Legal docs [2] Corporate docs
Level 4.5 (optional): Load Test Type
          [2] Multi TIF [2] Single PDF
Level 5: Command Type?
          [1] Move [2] Copy [3] Remove [4] Custom
Level 6: Enter a keyword
          [setup, cleanup, run]
</code>```

Design

States

PROBLEM:

Right now the STATES enum is the determining factor as to what state is BACK and what state is NEXT yet it knows nothing about what the current memento state is.

Has anyone experienced a similar issue and found an effective way to handle mementos with optional state?

```<code>static enum STATES {
    SERVER, ENVIRONMENT, TEST_TYPE, COLLECTION, COMMAND_TYPE, KEYWORD, FINISHED
}
</code>```

Possible Solution (Not-flexible)

In reference to my code below, every case statement in the Menu class could check the state of currentMemo and then set the STATE (enum) accordingly to pass to the Builder.  However, this doesn't seem flexible very flexible to change and I'm struggling to see an effective way refactor the design.

```<code>class Menu extends StateConscious {
    private State state;
    private Scanner reader;
    private ServerUtils utility;

    Menu() {
        state = new State();
        reader = new Scanner(System.in);
        utility = new ServerUtils();
    }

    // Recurring menu logic
    public void startPromptingLoop() {

        List<State> states = new ArrayList<>();
        states.add(new State());

        boolean redoInput = false;
        boolean userIsDone = false;

        while (true) {
            // get Memento from last loop
            Memento currentMemento = states.get(states.size() - 1)
                    .saveMemento();
            if (currentMemento == null)
                currentMemento = new Memento.Builder(0).build();

            if (!redoInput)
                System.out.println(currentMemento.prompt);
            redoInput = false;

            // prepare Memento for next loop
            Memento nextMemento = null;
            STATES state = STATES.values()[states.size() - 1];

            // get user input
            String selection = reader.nextLine();

            switch (selection) {

            case "exit":
                reader.close();
                return; // only escape

            case "quit":
                nextMemento = new Memento.Builder(first(), currentMemento,
                        selection).build();
                states.clear();
                break;

            case "back":
                nextMemento = new Memento.Builder(previous(state),
                        currentMemento, selection).build();
                if (states.size() <= 1) {
                    states.remove(0);
                } else {
                    states.remove(states.size() - 1);
                    states.remove(states.size() - 1);
                }
                break;

            case "1":
                nextMemento = new Memento.Builder(next(state), currentMemento,
                        selection).build();
                break;

            case "2":
                nextMemento = new Memento.Builder(next(state), currentMemento,
                        selection).build();
                break;

            case "3":
                nextMemento = new Memento.Builder(next(state), currentMemento,
                        selection).build();
                break;

            case "4":
                nextMemento = new Memento.Builder(next(state), currentMemento,
                        selection).build();
                break;

            default:
                if (state.equals(STATES.CATEGORY)) {
                    String command = selection;
                    System.out.println("Executing " + command + " command on: "
                            + currentMemento.type + " "
                            + currentMemento.environment);
                    utility.executeCommand(currentMemento.nickname, command);
                    userIsDone = true;
                    states.clear();
                    nextMemento = new Memento.Builder(first(), currentMemento,
                            selection).build();
                } else if (state.equals(STATES.KEYWORD)) {
                    nextMemento = new Memento.Builder(next(state),
                            currentMemento, selection).build();
                    states.clear();
                    nextMemento = new Memento.Builder(first(), currentMemento,
                            selection).build();
                } else {

                    redoInput = true;
                    System.out.println("give it another try");
                    continue;
                }
                break;
            }

            if (userIsDone) {

                // start the recurring menu over from the beginning

                for (int i = 0; i < states.size(); i++) {
                    if (i != 0) {
                        states.remove(i); // remove all except first
                    }
                }
                reader = new Scanner(System.in);
                this.state = new State();
                userIsDone = false;
            }

            if (!redoInput) {
                this.state.restoreMemento(nextMemento);
                states.add(this.state);
            }
        }
    }
}
</code>```

答:
Here's how I have handled a similar problem, though I don't think my implementation strictly followed Memento. Note that I was programming in ActionScript, which has a pretty robust event system that the whole thing hinges on. My understanding that events in Java don't actually center around an Event Object, so you may not be able to do what I did. Even so, there might be some concepts that you could apply.

Basically, everything that happened in the program was the result of an event that triggered a Command. Each Command knew how to undo itself. This knowledge was encapsulated in subclasses of an UndoStep Class. The UndoStep would be stored in a doubly linked list, along with the event that triggered the Command.

When an "Undo" event was received, the Command for that would look at the current link in the chain and run the undo step, then walk back a link. If a "Redo" event was received, the Command would dispatch the original event, which resulted in exactly the same result again. I can't remember if this would walk forward on the chain (which would result in multiple redos) or simply add a new link at the end, which would discard all the other Undos.

Title: Memento with optional state?


答:
You confuse the word "client" as used in the Gang of Four documents with a "client" as in consumer of a service.

A "client", as intended by Gang of Four definitions, is a class that implements an interface. If class A implements interface B, then they say A is a client of B. Otherwise the phrase "clients should not be forced to implement interfaces they don't use" wouldn't make sense since "clients" ( as in consumers ) don't implement anything. The phrase only makes sense when you see "client" as "implementor".

If "client" meant a class that "consumes" (calls) the methods of another class that implements the big interface, then by calling the two methods you care about and ignoring the rest, would be enough to keep you decoupled from the rest of the methods you don't use.

The spirit of the principle is avoid the "client" ( the class implementing the interface ) having to implement dummy methods in order to comply with the whole interface when it only cares about a set of methods that are related.

Also it aims to having the less amount of coupling as possible so that changes made in one place cause the less impact. By segregating the interfaces you reduce the coupling.

That problems appears when the interface does too much and have methods that should be divided into several interfaces instead of just one.

Both of your code examples are OK. It's only that in the second one you assume "client" means "a class that consumes/calls the services/methods offered by another class".

I find no contradictions in the concepts explained in the three links you gave.

Just keep clear that "client" is implementor, in SOLID talk.

Title: Two contradicting definitions of Interface Segregation Principle – which one is correct?

Body:
When reading articles on ISP, there seem to be two contradicting definitions of ISP:

According to first definition ( see 1, 2, 3), ISP states that classes implementing the interface shouldn't be forced to implement functionalities which they don't need. Thus, fat interface IFat

```<code>interface IFat
{
     void A();
     void B();
     void C();
     void D();
}

class MyClass: IFat
{ ... }
</code>```

should be split into smaller interfaces ISmall_1 and ISmall_2

```<code>interface ISmall_1
{
     void A();
     void B();
}

interface ISmall_2
{
     void C();
     void D();
}

class MyClass:ISmall_2
{ ... }
</code>```

since this way my MyClass is able to implement only the methods it needs ( D() and C() ), without being forced to also provide dummy implementations for A() and B():

But according to the second definition ( see 1 ,  2, answer by Nazar Merza), ISP states that MyClient calling methods on MyService shouldn't be aware of methods on MyService that it doesn't need. In other words, if MyClient only needs the functionality of C() and D(), then instead of

```<code>class MyService
{
    public void A();
    public void B();
    public void C();
    public void D();
}

/*client code*/
MyService service = ...;
service.C();
service.D();
</code>```

we should segregate MyService's methods into client-specific interfaces:

```<code>public interface ISmall_1
{
     void A();
     void B();
}

public interface ISmall_2
{
     void C();
     void D();
}

class MyService:ISmall_1, ISmall_2
{ ... }

/*client code*/
ISmall_2 service = ...;
service.C();
service.D();
</code>```

Thus with the former definition, the goal of ISP is to "make the life of classes implementing IFat interface easier", while with the latter the goal of ISP is to "make the life of clients calling methods of MyService easier".

Which of the two different definitions of ISP is actually correct?

@MARJAN VENEMA

1.

So when you are going to split IFat into smaller interface, which
methods end up in which ISmallinterface should be decided based on how
cohesive the members are.

While it makes sense to put cohesive methods within the same interface, I thought with ISP pattern the needs of the client take precedence over the "cohesiveness" of an interface. In other words, I thought with ISP we should lump within the same interface those methods needed by particular clients, even if that means leaving out of that interface those methods that should, for the sake of cohesiveness, also be put inside that same interface?

Thus, if there were lots of clients that will only ever needed to call CutGreens, but not also GrillMeat, then to adhere to ISP pattern we should only put CutGreens inside ICook, but not also GrillMeat, even though the two methods are highly cohesive?!

2.

I think that your confusion stems from the a hidden assumption in the
first definition: that the implementing classes are already following
the single responsibility principle.

By "implementing classes not following SRP" are you referring to those classes that implement IFat or to classes that implement ISmall_1 / ISmall_2? I assume you're referring to classes that implement IFat? If so, why do you assume they don't already follow SRP?

thanks


答: You should consider having a "criticality" level of the automatic update. If it is a security update you could make it a forced update, but if it's a functionality or less-critical bug fix update then let the user decide. The frequency doesn't sound bad because if there is a security update you might not want to wait until the next reboot or restart of the app. Even if the update is non-obtrusive users can get annoyed because of change in features.</p>

Title: Is it okay for an application to check for automatic updates in less than 20 hour interval?

Body:
I have a desktop application that has the ability to automatically update itself on the next restart (without the user's consent - but this is another issue altogether). Assuming that the user would never notice anything related to application updating (such as a progress bar, or pop-up requiring restart), and that our server would support the request spam load, is there any reason why it should not check for updates in less than 20 hour interval?

The reason I'm asking this is because all applications that I know that have auto-update capability check for update every 20 to 24 hours and at startup. I was just wondering if there was an ethical rule about it, or simply because of the risk of overloading the server.


答:
Consider two points:

Privacy. If the application sends information to you every time I'm launching it, it says too much about me. If I start your application very often, you can gather some statistics which I would consider too intrusive of my personal life. Over a few months or years, you'll know statistically when do I use my computer from Monday to Friday, and when do I use it on weekends. You'll be able to know that on May 9th, I launched the application sixteen times, or that I was on holiday from March 12th to April 4th.

Impact on server. If your app is actively used, the impact of checking for updates every time it starts may be important. Reducing it to one per day per user is not too bad.

Note that contrary to what we could think, it wouldn't affect peaks too much. For example, an application used by accountants in USA would see the highest number of requests in the morning, when accountants come to work and launch the application.

As for the point of view of users themselves:

if the users of your app are system administrators and IT professionals, then Balog Pal already gave you enough information. Always give a possibility to either disable the updates or make them manual or discard them in some way.

if the users are simple people with no much knowledge in IT, they don't care if you update your app every thirty seconds or once per month. What they care about is that some apps ask them to do the updates: a process which they don't understand and which they consider being a waste of time. That's why the model chosen by Google Chrome is so excellent and should be used in every application.


答:
You probably don't want to do an update that frequently.

With a daily update, you run the risk of hosing ALL your users if there's a problem in your update (I'm looking at you, Microsoft).  And then you get to deal with the resulting complaints and support issues.  If you make the frequency of the checks lower, if a problem does occur, it will affect a smaller portion of your customers, and you'll likely be able to catch it and fix it before it becomes a larger problem.

In my Windows apps, they check for updates (if enabled) on program launch only if they haven't checked in the past 14 days.  That seems to work well.  It just records the last checked date, and only does another check once its been 14 days, regardless of how often the program is launched.  And, if the user wants, they can also manually check in the 'About' window.


问:
user's requirements verification, howto?
My question is: How can you verify the users' requirements early in the software creation process?

I show the user specifications, prototypes, demos... but still users forget to share some "insignificant details" about the process or business rules and data. Which pops up after the final test as some "really small and rare exceptions" - which are turned into change request and accumulate a lot of work.

So how do you prototype (or verify) users requirements early in the project?

答:
You really just need to along the way make sure you are meeting the criteria listed there.  For example if it says "functionality x should be available to all users" then make sure this is true.

Early in the development process this will be tough but closer to deadline the more you should be able to verify.

Perhaps the things you do not yet have implemented, you can verify they are in the design considerations so you know they are being considered during early development.


问:
Over normalization in database
Currently I am working on creating a new database schema as part of a major new product.  Our previous customer address records (in a previous product)  look something like this in our current schema (not all columns shown):

```<code>AddressID, AddressLine1, AddressLine2, City, State. Zip, Country, Etc.
</code>```

I want to normalize this so that an address actually breaks down to:

1 address to many address lines

1 address to a zip/postal code

So I sent out a communication saying that zip code will now be in its own table and that each "address" corresponds to one zip/postal code.  In addition, addresses would be broken out so that we could support more than 2 address lines with a 1 to many relationship.

Some people in my group are now saying that I am over-normalizing the database.  Am I?

Note, I am not a DBA but I feel that this is more logical and more efficient than the previous schema.

Update

Thx to everyone for their input.  I'm not going to break out the address or zips to their own tables.  My original plan was to have a zip code lookup and re-use for the addresses so I would only have to have one set of zips, but I'll just drop everything on the record itself, and have a separate table for zip lookups.

答:
If you need to visualize large sets of geo based data (graphs, maps, ...) , report on it ,e tc, not normalizing your address data will be a real performance nightmare.

The problem I'm trying to overcome at my current project  is "bad data", and "incomplete data".. We found people living in belgium with zip code: 'CHINA' in our clients legacy database. DEAR GOD.

Doing it right will require a lot of data cleanup, and should allow a flexible way to add new cities/zipcodes + merge zipcodes when cities merge. Across the world this happens a lot. Depending on the size of your project  and the geographical scope you should onsider if it's worth by looking at the actual data you have.

Title: Over normalization in database


答:
Both are correct

The way I read it, the purpose of ISP (Interface Segregation Principle) is to keep interfaces small and focused: all interface members should have very high cohesion. Both definitions are intended to avoid "jack-of-all-trades-master-of-none" interfaces.

Interface segregation and SRP (Single Responsibility Principle) have the same goal: ensuring small, highly cohesive software components. They complement each other. Interface segregation ensures that interfaces are small, focused and highly cohesive. Following the single responsibility principle ensures that classes are small, focused and highly cohesive.

The first definition you mention focuses on implementers, the second on clients. Which, contrary to @user61852, I take to be the users/callers of the interface, not the implementers.

I think that your confusion stems from the a hidden assumption in the first definition: that the implementing classes are already following the single responsibility principle.

To me the second definition, with the clients as the callers of the interface, is a better way of getting to the intended goal.

Segregating

In your question you state:

since this way my MyClass is able to implement only the methods it
  needs ( D() and C() ), without being forced to also provide dummy
  implementations for A(), B() and C():

But that is turning the world upside down.

A class implementing an interface does not dictate what it needs in the interface it is implementing.

The interfaces dictate what methods an implementing class should provide.

The callers of an interface really are the ones that dictate what functionality they need the interface to provide for them and thus what an implementer should provide.

So when you are going to split IFat into smaller interface, which methods end up in which ISmall interface should be decided based on how cohesive the members are.

Consider this interface:

```<code>interface IEverythingButTheKitchenSink
{
     void DoDishes();
     void CleanSink();
     void CutGreens();
     void GrillMeat();
}
</code>```

Which methods would you put in ICook and why? Would you put CleanSink together with GrillMeat just because you happen to have a class that does just that and a couple of other things but nothing like any of the other methods? Or would you split it into two more cohesive interfaces, such as:

```<code>interface IClean
{
     void DoDishes();
     void CleanSink();
}

interface ICook
{
     void CutGreens();
     void GrillMeat();
}
</code>```

Interface declaration note

An interface definition should preferably be on its own in a separate unit, but if it absolutely needs to live with either caller or implementer, it should really be with the caller. Otherwise the caller gets an immediate dependency on the implementer which is defeating the purpose of interfaces altogether. See also: Declaring interface in the same file as the base class, is it a good practice? on Programmers and Why should we place interfaces with classes that use them rather than those that implement them? on StackOverflow.

Body:
Both are correct

The way I read it, the purpose of ISP (Interface Segregation Principle) is to keep interfaces small and focused: all interface members should have very high cohesion. Both definitions are intended to avoid "jack-of-all-trades-master-of-none" interfaces.

Interface segregation and SRP (Single Responsibility Principle) have the same goal: ensuring small, highly cohesive software components. They complement each other. Interface segregation ensures that interfaces are small, focused and highly cohesive. Following the single responsibility principle ensures that classes are small, focused and highly cohesive.

The first definition you mention focuses on implementers, the second on clients. Which, contrary to @user61852, I take to be the users/callers of the interface, not the implementers.

I think that your confusion stems from the a hidden assumption in the first definition: that the implementing classes are already following the single responsibility principle.

To me the second definition, with the clients as the callers of the interface, is a better way of getting to the intended goal.

Segregating

In your question you state:

since this way my MyClass is able to implement only the methods it
  needs ( D() and C() ), without being forced to also provide dummy
  implementations for A(), B() and C():

But that is turning the world upside down.

A class implementing an interface does not dictate what it needs in the interface it is implementing.

The interfaces dictate what methods an implementing class should provide.

The callers of an interface really are the ones that dictate what functionality they need the interface to provide for them and thus what an implementer should provide.

So when you are going to split IFat into smaller interface, which methods end up in which ISmall interface should be decided based on how cohesive the members are.

Consider this interface:

interface IEverythingButTheKitchenSink
{
     void DoDishes();
     void CleanSink();
     void CutGreens();
     void GrillMeat();
}

Which methods would you put in ICook and why? Would you put CleanSink together with GrillMeat just because you happen to have a class that does just that and a couple of other things but nothing like any of the other methods? Or would you split it into two more cohesive interfaces, such as:

interface IClean
{
     void DoDishes();
     void CleanSink();
}

interface ICook
{
     void CutGreens();
     void GrillMeat();
}

Interface declaration note

An interface definition should preferably be on its own in a separate unit, but if it absolutely needs to live with either caller or implementer, it should really be with the caller. Otherwise the caller gets an immediate dependency on the implementer which is defeating the purpose of interfaces altogether. See also: Declaring interface in the same file as the base class, is it a good practice? on Programmers and Why should we place interfaces with classes that use them rather than those that implement them? on StackOverflow.


问:
How do you schedule software updates, major releases, milestones (what is this?)
What are the common terminology used to schedule software update and support. For example, I really have no clue how releases and updates differ, how often are updates released (not everyday I hope)?

Most importantly communicating stuff like milestone (what is this mean?), roadmaps, basically I want to know how I can offer support to end users by using industry terminology.

答:
The specific term for what you're describing would be Release Management and the Software Development Life-Cycle. You may also find the Wikipedia article on the Software Release Life Cycle to be helpful as well.

Releases are often considered major updates to the software, but might also be brand new versions of the software. Updates are typically smaller patches that fix existing functionality or add less significant features. What each of these mean really depend on your company's specific approaches and internal lingo. For example, some companies might provide free updates containing just bug fixes but charge for releases of new features. Some companies call updates "releases" as well, as the term can be used more generically, but it can be useful to differentiate them.

Update deployment cycle depends on your company and products as well. Many companies offer a new release every year or every few months, with updates coming out every few weeks. Some companies only offer a new release every few years and offer updates quarterly. The type of product you're selling and the development methodologies you're using can significantly change your release schedule.

Roadmaps are typically internal items used by the business teams (product managers) to plan and schedule new features and fixes. Your company may choose to post a public roadmap to let customers know when you hope or expect to have new features added to your product. However, many companies avoid doing this because the roadmaps may be seen as advertised promises to customers, who could potentially sue or become upset if the features are cancelled or released late.

Milestones are often designated during project planning to help evaluate the progress of a feature or product's development.  They are usually marked by the completion of a specific subtask of the project. Having milestones can provide clear goals to work towards for each phase of development, and can give you a sense of how rapidly development is progressing compared to expectations.

There are a lot of good books on the subject, and Wikipedia has a surprising amount of well-written articles on software development as well. These ideas and good implementations thereof are really more nuanced than can be summarized here.


问:
Should a complex unifying class be doing computation?
I have a large application in Java filled with independent classes which are unified in a PlayerCharacter class. The class is intended to hold a character's data for a game called the Burning Wheel, and as a result, is unusually complex. The data in the class needs to have computations controlled by the UI, but needs to do so in particular ways for each of the objects in the class.

There are 19 objects in the class PlayerCharacter. I've thought about condensing it down, but I'm pretty sure this wouldn't work anywhere in the application as it stands so far.

```<code>private String name = ""; private String concept = "";
private String race = ""; private int age = -1;

private ArrayList<CharacterLifepath> lifepaths = new ArrayList<>();

private StatSet stats = new StatSet();
private ArrayList<Affiliation> affiliations = new ArrayList<>();
private ArrayList<Contact> contacts = new ArrayList<>();
private ArrayList<Reputation> reputations = new ArrayList<>();
//10 more lines of declarations
</code>```

I've been considering this problem for some time now, and have considered multiple
approaches. The problem arises primarily when data is deleted - for instance, since pretty much everything else (but not some parts!) depends upon Lifepaths, when a lifepath is deleted, nearly everything else must be recalculated. However, if a Skill is deleted, only a few things must be recalculated.

Additionally, the application must somewhere track certain values; skill points, trait points, etc. to ensure that the user is not unintentionally exceeding those values.

So my question is generally as follows: Where  should everything go? What makes this easiest? There are a couple options:

Place point total calculations in the PlayerCharacter class (but how does this generate a warning?)

Handle all calculation outside of the PlayerCharacter class, and just use PlayerCharacter as a container for all the character's information

Place all calculations in the PlayerCharacter class; after each item is changed, recompute the entire character. Then, if there are issues arising from deletion, throw warnings back at the UI.

I'm slightly overwhelmed by the scope of this particular class - whereas everything I've done so far has been easily broken down into small manageable chunks, this beast seems to resist being tamed. If there's a better approach to this, I'm all ears! But as of right now, I'm slightly confused, and progressing aimlessly probably won't get me anywhere. Any advice is appreciated.

I apologize if this is unclear - I'm certain I lack the software vocabulary to properly communicate my ideas. I would love to improve this question - any help here is appreciated!

答:
Isolate & Encapsulate Complexity

Pull calculations into their own "function" classes. Their structure and relationships is very highly dependent on your existing design.

Maybe turn affiliations, contacts, etc. into classes. This makes PlayerCharacter more usable by "function" classes.

With PlayerCharacter now a composite of other classes and individual properties as appropriate you can easily create "data" classes. These data classes are intended as customizations for the functional classes. The function class code will have the look and feel of dealing with a coherent class, not a jumble of PlayerCharacter and other classes.

Scrub your Design

You will need to re-analyze to make sure you get fundamental functionality into the right classes. For example each "data" class may have its own "delete" function that does very specific and minimal things. A "function" class, likewise, will orchistrate all the "data" classes in the overall delete process and and do "delete-y" things that are of an inter-class context.

Get a High-Level View of Design Patterns

Learn some basics about the various patterns. This will give you some insight as to how you might tackle the problem. Don't sweat the class diagrams just get the ideas and motivation behind them. I'm not saying you should explicitly implement a particular pattern or any pattern at all. You're just looking for inspiration.

Flyweight - Shared State.

Visitor - Performing the same operation on a collection of different types

Template Method - defines an algorithm in a base class using abstract operations that subclasses override to provide concrete behavior.

Adapter -
    Convert the interface of a class into another interface clients expect.
    Adapter lets classes work together, that could not otherwise because of incompatible interfaces.

Façade - Provide a unified interface to a set of interfaces in a subsystem. Façade defines a higher-level interface that makes the subsystem easier to use.


问:
Any tools/suggestions on how to refute code coverage quality argument
Now I know people could consider this question duplicate or asked many times, in which case I would appreciate a link to relevant questions with answer to my question.

I have been recently in disagreement with some folks about code coverage. I have a group of people who want our team to drop looking at code coverage altogether based on the argument that 100% coverage does not mean good quality tests and thus good quality code.

I have been able to push back by selling the argument that Code Coverage tells me what has not been tested for sure and help us focus on those areas.

(The above has been discussed in a similar fashion in other SO questions like this one - https://stackoverflow.com/questions/695811/pitfalls-of-code-coverage)

The argument from these folks is - then team would react by quickly creating low quality tests and thus waste time while adding no significant quality.

While I understand their point of view, I am searching for a way to make a more robust case for code coverage by introducing more robust tools/frameworks that take care of more coverage criteria (Functional, Statement,Decision, Branch, Condition, State, LCSAJ, path, jump path, entry/exit, Loop, Parameter Value etc).

What I am looking for is suggestion for a combination of such code coverage tools and practices/processes to go with them which can help me counter such arguments while feeling comfortable about my recommendation.

I would also welcome any accompanying comments/suggestions based on your experience/knowledge on how to counter such an argument, because while subjective, code coverage has helped my team be more conscious of code quality and value of testing.

Edit: To reduce any confusion about my understanding of weakness of typical code coverage, I want to point out that I am not referring to Statement Coverage(or lines of code executed) tools(there are plenty). In fact here is a good article on everything that is wrong with it: http://www.bullseye.com/statementCoverage.html

I was looking for more than just statement or line coverage, going more into multiple coverage criteria and levels.

See: http://en.wikipedia.org/wiki/Code_coverage#Coverage_criteria

The idea is that if a tool can tell us our coverage based on multiple criteria then that becomes a reasonable automated assessment of test quality. I by no means am trying to say that line coverage is a good assessment. In fact that's the premise of my question.

Edit:

Ok, maybe I projected it a bit too dramatically, but you get the point. The problem is about setting processes/policies in general across all teams in a homogeneous/consistent fashion. And the fear is general that how do you ensure quality of tests, how do you allocate guaranteed time without having any measure to it. Thus I like having a measurable feature that when backed up with appropriate processes and the right tools would allow us to improve code quality while knowing that time is not being force spent in wasteful processes.

EDIT: So far what I have from the answers:

Code reviews should cover tests to ensure quality of tests

Test First strategy helps avoid tests that are written after the fact to simply increase coverage %

Exploring alternative tools that cover test criteria other than simply Statement/Line

Analysis of covered code/number of bugs found would help appreciate the importance of coverage and make a better case

Most importantly trust the Team's input to do the right thing and fight for their beliefs

Blocks Covered/# of tests - Debatable but holds some value

Thanks for the awesome answers so far. I really appreciate them. This thread is better than hours of brainstorm with the powers that be.

答:
I have always found that code coverage is easily susceptible to the Hawthorne Effect. This caused me to ask "why do we have any software metrics at all?" and the answer usually is to provide some high level understanding of the current state of the project, things like:

"how close are we to done?"

"how is the quality of this system?"

"how complicated are these modules?"

Alas, there will never be a single metric that can tell you how good or bad the project is, and any attempt to derive that meaning from a single number will necessarily over simplify. While metrics are all about data, interpreting what they mean is a much more emotional/psychological task and as such probably cant be applied generically across teams of different composition or problems of different domains.

In the case of coverage I think it is often used as a proxy for code quality, albiet a crude one. And the real problem is that it boils down an awfully complicated topic to a single integer between 0 and 100 which will of course be used to drive potentially unhelpful work in an endless quest to achieve 100% coverage. Folks like Bob Martin will say that 100% coverage is the only serious goal, and I can understand why that is so, because anything else just seems arbitrary.

Of course there are lots of ways to get coverage that dont actually help me get any understanding of the codebase - e.g. is it valuable to test toString()? what about getters and setters for immutable objects? A team only has so much effort to apply in a fixed time and that time always seems to be less than the time required to do a perfect job, so in absence of perfect schedule we have to make do with approximations.

A metric I have found useful in making good approximations is Crap4J. It is now defunct but you can easily port/implement it yourself. Crap4J to attempts to relate code coverage to cyclomatic complexity by implying that code which is more complicated (ifs, whiles, fors etc.) should have higher test coverage. To me this simple idea really rang true. I want to understand where there is risk in my codebase, and one really important risk is complexity. So using this tool I can quickly assess how risky my code base is. If it is complicated the coverage had better go way up. If it isn't I dont need to waste time trying to get every line of code covered.

Of course this is but one metric and YMMV. You have to spend time with it to understand if it will make sense to you and if it will give your team a reasonably grok-able feeling of where the project is at.


答:
Use iterative development that forces you to have frequent feedback to the customer/user.

Also increase collaboration between developers and users by removing (usually useless) intermediate such as project managers or even business analysts (the latter can be very required in very complex business domains).

That's just a few recommandations. There is a lot to say on the subject.

I highly suggest you to have a look at Scrum. Which saved my life.

Title: user's requirements verification, howto?

Body:
My question is: How can you verify the users' requirements early in the software creation process?

I show the user specifications, prototypes, demos... but still users forget to share some "insignificant details" about the process or business rules and data. Which pops up after the final test as some "really small and rare exceptions" - which are turned into change request and accumulate a lot of work.

So how do you prototype (or verify) users requirements early in the project?


问:
Compile and run submissions of online judge in the same or separate server?
I am going to make an online judge platform.

I have looked for some online judge platforms on the Internet for reference (I mean the platforms which have the source code available, and can be hosted my others, not something like Codeforces). Most of them have a web interface written in PHP (or something else).

When users submit the solutions of the problems, the submissions are sent to another programs (a server side program written in C++, Java or something else), which is hosted on or not on the same server, through socket.

What is the benefit of this design? Why not doing so through PHP, with functions like exec()? Which design will you appreciate more?

答:
It can be done for security and to detect or prevent cheating. It's called sandboxing.

Your main server likely has a lot of important things on it: your source code, your database, access to email functions, etc. To exec arbitrary code from an untrusted user on that server is asking for trouble. Even if you sanitized their code (which is a big if, because you can't determine exactly how a program will behave without running it), there may be a PHP bug that they can exploit to take control of the server.

From there they could do anything from downloading the problem answers up to stealing credit card information (if you collect payments), wiping your database, or sending out spam.

If you sandbox and run submissions on another server, you can restrict that server's permissions by turning off modules like curl, mysql, and sendmail. You can limit it to the more basic functions that your users will need for solving coding problems.


问:
Tag an image in various places, and save to database
I'd like to create something similar to what you see here...
http://www.houzz.com/ideabooks/9424693/list/8-Beautiful-Ways-to-Work-Glass-Into-Your-Kitchen-Cabinets

If you click on the second photo down, youll notice it has a bunch of tags, linking to actual products, or just descriptions of products.

Is this done using HTML5 canvas overlayed onto the photo?

Or what would be the most efficient way to implement this??

I have a list of 1,000,000 products that the user will be able to tag.
I wanna link the two, so that as he tags, it saves to a database, and then anyone else viewing his room, can come in and click a link, to go to that product.

答:
The Method

Storing the Data

Present the taggable image to the user.

Capture mouse clicks on the image and store the coordinates relative to the image where the user clicks.

Once they've clicked, you can present the user with a pop-up/modal type form where they can select one of the products from a searchable list and enter any other information you want to save with the tag.

When they save the tag, store the x/y coordinates and relevant information in your database.

Retrieving the Data

The next time the image is loaded, load all of the tags with it.

For each tag, display a
 on top of the image at the coordinates you saved.

Display a tooltip or notification when the user clicks on a tag. This could include a link to the aforementioned product.

The Technology

The number of different configurations of technology you could create this project with is enormous. Before you settle on any single technology, you should do some research on all of them.

The Front-End

HTML and CSS

You can easily render the entire program in HTML and CSS. You may find it useful to use a JavaScript templating library such as Handlebars or Underscore.js and/or a CSS preprocessor framework such as LESS or SASS.

Javascript

There are a lot of different JavaScript frameworks/libraries (jQuery, Backbone and Underscore.js, Ember.js, YUI, etc.). Which one to use is pretty big question by itself and depends on the other things you're trying to achieve with the project. jQuery is one of the more commonly used libraries and should be able to accomplish most of the things you're trying to do. You should research all of them so you understand what you're getting into.

To store the data, you'll make an AJAX call to pass the information to a program on the server.

If you want to automatically send tags to other people viewing the same image, you can look at using something like Comet. There should be plugins or baseline Comet support for most or all of those libraries.

HTML 5

HTML5 could easily handle this, since it's a newer version of older technologies that were already capable of this feat (including JavaScript). It's kind of overkill to do the entire thing in strict HTML5 at this point, and you'll likely be eliminating older browsers from being able to use the site, but it is an option nonetheless. You should definitely research HTML5 before designing the project so you will be able to refactor to it easily if you decide to do so in the future.

The Back-End

Database

You will need a database of some sort to store your list. If you don't already have one you should look at PostgreSQL or MySQL. There's also the Oracle Database and Microsoft SQL Server to consider if you're doing this professionally for a client who can afford the extra licenses and hosting costs.

Server-Side Code

You will need a server-side component to the application to pull the data from the server and send it back to your front-end client. For this you have quite a few options, including  ASP.NET, Ruby, Python, Java, server-side JavaScript, PHP, and more.

More Questions?

For more specific help with any part of this application, you should probably post your question(s) on Stack Overflow.

Body:
The Method

Storing the Data

Present the taggable image to the user.

Capture mouse clicks on the image and store the coordinates relative to the image where the user clicks.

Once they've clicked, you can present the user with a pop-up/modal type form where they can select one of the products from a searchable list and enter any other information you want to save with the tag.

When they save the tag, store the x/y coordinates and relevant information in your database.

Retrieving the Data

The next time the image is loaded, load all of the tags with it.

For each tag, display a <div> on top of the image at the coordinates you saved.

Display a tooltip or notification when the user clicks on a tag. This could include a link to the aforementioned product.

The Technology

The number of different configurations of technology you could create this project with is enormous. Before you settle on any single technology, you should do some research on all of them.

The Front-End

HTML and CSS

You can easily render the entire program in HTML and CSS. You may find it useful to use a JavaScript templating library such as Handlebars or Underscore.js and/or a CSS preprocessor framework such as LESS or SASS.

Javascript

There are a lot of different JavaScript frameworks/libraries (jQuery, Backbone and Underscore.js, Ember.js, YUI, etc.). Which one to use is pretty big question by itself and depends on the other things you're trying to achieve with the project. jQuery is one of the more commonly used libraries and should be able to accomplish most of the things you're trying to do. You should research all of them so you understand what you're getting into.

To store the data, you'll make an AJAX call to pass the information to a program on the server.

If you want to automatically send tags to other people viewing the same image, you can look at using something like Comet. There should be plugins or baseline Comet support for most or all of those libraries.

HTML 5

HTML5 could easily handle this, since it's a newer version of older technologies that were already capable of this feat (including JavaScript). It's kind of overkill to do the entire thing in strict HTML5 at this point, and you'll likely be eliminating older browsers from being able to use the site, but it is an option nonetheless. You should definitely research HTML5 before designing the project so you will be able to refactor to it easily if you decide to do so in the future.

The Back-End

Database

You will need a database of some sort to store your list. If you don't already have one you should look at PostgreSQL or MySQL. There's also the Oracle Database and Microsoft SQL Server to consider if you're doing this professionally for a client who can afford the extra licenses and hosting costs.

Server-Side Code

You will need a server-side component to the application to pull the data from the server and send it back to your front-end client. For this you have quite a few options, including  ASP.NET, Ruby, Python, Java, server-side JavaScript, PHP, and more.

More Questions?

For more specific help with any part of this application, you should probably post your question(s) on Stack Overflow.


问:
Should we be looking out for lying code?
This is referring to a discussion in an answer and the comments of this question: What's with the aversion to documentation in the industry?.  The answer claimed that "code can't lie" and thus should be the go-to location instead of documentation.  Several comments pointed out that "code can lie".  There is truth on both sides, at least partly because of how poorly and inappropriately documentation is handled.

Should we be on the lookout for lying code, comparing it against any existing documentation?  Or is it usually the best source for what it needs to be doing?  If it is agile code, is it less likely to lie, or can that code not lie at all?

答:
In layman's words:

Yes, you should search for lying code and make it tell the truth. But not by comparing it to the documentation. That would be a method for detecting documentation that lies.

There are several ways code can lie, of which I will mention just a few:

Blocks of code that never gets run because conditions that are never met. The code is lying you about how much it does.

Code that adds unnecessary complexity lies about how complex the problem really is.

Code with no naming conventions lies because it misleads you into thinking it does something different to what it's really doing.

The shorter is, the less it lies. It's self evident.

The less complicated the code is, the more transparent it is. So it lies less.

Arcane syntax tricks lie a lot. Prefer clear, step-by-step algorithms. They lie less.

A good static code analysis tool can help you find code that lies.

Also a good automated test battery forces the code into telling the truth.


答:
Code can't lie.

What is in code is what your program is currently doing - no matter what documentation, QA, or the customer says. Especially if your code has been released and been in the field for a while, that expected behavior should not be ignored.

The code can certainly be incorrect. It can certainly be misleading in its naming or organization. It can certainly be unreadable.

But if you want the source of truth for what your code is doing, not what it's supposed to do, not what it was designed to do, not what you thought it was doing... if you need to know what it's actually doing, go to the code.

Title: Should we be looking out for lying code?

Body:
This is referring to a discussion in an answer and the comments of this question: What's with the aversion to documentation in the industry?.  The answer claimed that "code can't lie" and thus should be the go-to location instead of documentation.  Several comments pointed out that "code can lie".  There is truth on both sides, at least partly because of how poorly and inappropriately documentation is handled.

Should we be on the lookout for lying code, comparing it against any existing documentation?  Or is it usually the best source for what it needs to be doing?  If it is agile code, is it less likely to lie, or can that code not lie at all?