问:
Methodology To Determine Cause Of User Specific Error
We have software that, for certain clients, fails to download a file. The software is developed in Python and compiled into a Windows Executable. The cause of the error is still unknown but we have established that the client has an active internet connection. We suspect that the cause is due to the clients network setup. This error cannot be replicated in house.

What technique or methodology should be applied to this kind of specific error that cannot be replicated in house? The end goal is to determine the cause of this error so we can move onto the solution.

For example:

Remote Debugging: Produce a debug version of the software and ask the client to send back a debug output file. This involves a lot of time (back and forth communication) and requires the client to work and act in a timely manner to be successful.

In-house debugging: Visit the client and determine their network setup, etc. Possibly develop a series of script tests before hand to run on the clients computer under the same network.

Other methodologies and techniques I am not aware of?

答:
Remote Debugging: Produce a debug version of the software and ask the client to send back a debug output file. This involves alot of time (back and forth communication) and requires the client to work and act in a timely manor to be successful.

The general idea here is correct, but there are two things to improve in this.

First, you should not need to produce a special "debug version" of your software - your client should be able to run your latest release of the application in a logging mode, without the need for reinstalling the thing - the logging feature should be always available for him if needed.

Second, you have to improve the logging mechanisms in your software - so you can minimize the communication effort for the client. So instead of "add a little logging here, send the client a different version of your software, he sends you a log back, you analyse the logs and change your software a little bit again", the cycle should be "when the problem occurs, the client sends you the basic log which is always activated, and if that's not enough, he switches on extensive logging, you get a huge log file containing each and everything which might be cause of the problem, and then you got ideally enough information to reproduce the problem or pinpoint the cause". Of course, in practice you might need still more than one cycle at when you start with this, but the goal should be to bring this down to "one".

There is also a nice tool included in Windows since Win-7 for logging what the user does in front of the client - the problem step recorder (psr.exe). See here for more details. This probably won't help you much if a server configuration is the real problem's cause, but maybe it is helpful to get a better understanding what happened at the client's site, without the need of physically visiting the client.

ContentLicense: CC BY-SA 4.0


答:
Remote debugging.

Agreed, this involves a lot of time. But don't expect to find such error magically in a short amount of time with no effort.

Agreed, this involves implication from the customer. But if the customer is not interested in solving the issue, there are chances it will remain unsolved.

Extensively verbose logging.

If you have a mechanism which enables frequent updates, transparent for the end user (just like Chrome does), then you can frequently push changes with more and more logging, and pin out the issue this way. This also involves the ability to get the logs back to you.

Depending on the product, you may force it to download a file (i.e. do the problematic operation) when the application loads, and to report the result.

On-site debugging (≠ in-house debugging).

This may be the most difficult one, but may be relevant to some companies. Send one of your developers to the customer in order to study the issue. If he can be granted an administrative access to the problematic machine, resolving the issue may be easy and short enough, similarly to if the issue was reproduced in-house.

Title: Methodology To Determine Cause Of User Specific Error

Body:
We have software that, for certain clients, fails to download a file. The software is developed in Python and compiled into a Windows Executable. The cause of the error is still unknown but we have established that the client has an active internet connection. We suspect that the cause is due to the clients network setup. This error cannot be replicated in house.

What technique or methodology should be applied to this kind of specific error that cannot be replicated in house? The end goal is to determine the cause of this error so we can move onto the solution.

For example:

Remote Debugging: Produce a debug version of the software and ask the client to send back a debug output file. This involves a lot of time (back and forth communication) and requires the client to work and act in a timely manner to be successful.

In-house debugging: Visit the client and determine their network setup, etc. Possibly develop a series of script tests before hand to run on the clients computer under the same network.

Other methodologies and techniques I am not aware of?

ContentLicense: CC BY-SA 3.0


问:
Store scores for players and produce a high score list
This question is derived from an interview question that I got for a job I was declined.  I have asked for code review for my solution at the dedicated Stack Exchange site (https://codereview.stackexchange.com/q/51842/43237). But I hope this question is sufficiently rephrased and asked with a different motivation not to be a duplicate of the other question.

Consider the following scenario:

You should store player scores in the server back end of a game. The server is written in Java.

Every score should be registered, that is, one player may have any number of scores for any number of levels.

A high score list should be produced with the fifteen top scores for a given level, but only one score per user (to the effect that even if player X has the two highest scores for level Y, only the first position is counted and player Z has the second place).

No information should be persisted and only Java 1.7+ standard libraries should be used. No third party libraries or frameworks are acceptable.

With the number of players as the primary factor, what would be the best data structure in terms of scalability and concurrency?

How would you access the structure to register a single score given a level and a player id?

How would you access the structure to compile the high score list?

答:
This might be a trick question, since it's implying that you should be able to represent the scores for every single level for every single player in a single data structure.  While that may be true in general, we're talking about a game with many many players.  Therefore, trying to hold everything in memory might work initially, but it's not reasonable to assume it would scale, and since scalability is important here, you should flat out tell your interviewer that a java data structure of any form could not reasonably be thought to hold all the information required.

What comes to mind is a database for such things, since it is both scalable as well as completely supporting concurrency, both of which are requirements in this case.  If the interviewer wants to go into details in that regard you can, but I think the key point here is that you wouldn't try to stuff everything into the server's memory.

However on that point, you should probably add that it would be also inefficient to have to load all scores after each level in order to see if you've got a spot on the top scores list.  Therefore to that effect, I do think keeping the top scores for each level is a reasonable compromise for performance.  In terms of memory, top 10 slots X 100 levels is 1000 slots, perfectly reasonable amount of space and more importantly, it does not grow.

I would represent this using a Map<int, SortedMap<long, Player>>.  The outer map is used to store a map for each level (no need searching in other levels other than the one I've just beaten).  It is also irrelevant what type the Map is, since it just has to find the given level.  The inner SortedMap stores the score as the key and the associated Player class which got that score.  In this case it is relevant that it is a SortedMap, since you may likely want to access them sequentially based on score.

When a player finishes a level, you can do a quick check in memory to see if the player has made it to the top score list for that given level without making an explicit fetch to the database each time.  If so, in a synchronized action, you should insert the player into the SortedMap for that level (removing the worst score afterwards) and then update the database.  It must be synchronized in order to guarantee that it is also consistent with the database and consistent with the multiple requests that will be done.

Does that answer your question?


问:
Developers blocked by waiting on code to merge from another branch using GitFlow
Our team just made the switch from FogBugz & Kiln/Mercurial to Jira & Stash/Git. We are using the Git Flow model for branching, adding subtask branches off of feature branches (relating to Jira subtasks of Jira features). We are using Stash to assign a reviewer when we create a pull request to merge back into the parent branch (usually develop but for subtasks back into the feature branch).

The problem we're finding is that even with the best planning and breakdown of feature cases, when multiple developers are working together on the same feature, say on the front-end and back-end, if they are working on interdependent code that is in separate branches one developer ends up blocking the other.

We've tried pulling between each others' branches as we develop. We've also tried creating local integration branches each developer can pull from multiple branches to test the integration as they develop. Finally, and this seems to work possibly the best for us so far, though with a bit more overhead, we have tried creating an integration branch off of the feature branch right off the bat. When a subtask branch (off of the feature branch) is ready for a pull request and code review, we also manually merge those change sets into this feature integration branch. Then all interested developers are able to pull from that integration branch into other dependent subtask branches. This prevents anyone from waiting for any branch they are dependent upon to pass code review.

I know this isn't necessarily a Git issue - it has to do with working on interdependent code in multiple branches, mixed with our own work process and culture. If we didn't have the strict code-review policy for develop (true integration branch) then developer 1 could merge to develop for developer 2 to pull from. Another complication is that we are also required to do some preliminary testing as part of the code review process before handing the feature off to QA.This means that even if front-end developer 1 is pulling directly from back-end developer 2's branch as they go, if back-end developer 2 finishes and his/her pull request is sitting in code review for a week, then front-end developer 2 technically can't create his pull request/code review because his/her code reviewer can't test because back-end developer 2's code hasn't been merged into develop yet.

Bottom line is we're finding ourselves in a much more serial rather than parallel approach in these instance, depending on which route we go, and would like to find a process to use to avoid this.

Last thing I'll mention is we realize by sharing code across branches that haven't been code reviewed and finalized yet we are in essence using the beta code of others. To a certain extent I don't think we can avoid that and are willing to accept that to a degree.

答:
The issue might also lie in a too rigid separation of task between back-end and front-end development.

If a front-end developer need a new API, isn't it possible to allow him or her to create a dummy API on the back end (returning always the same value for example) to validate the layout ? Then commit that partial implementation with a stub, and in a second time, a back-end developer will implement the real feature.

By breaking the dependency, you will get a better flow and you don't have stop everything waiting for a single task that acts as a bottleneck.


问:
How to analyze a scenario where a bug didn't get caught and adjust development workflow to prevent similar errors
I had a bug that was really difficult to track down, because all the unit tests were green, but the production application didn't work properly.

Here's what happened:

I had a filter class that set my application to ignore data that was not in some specified time windows.

The unit test, which seemed thorough to me, turned green.

Additionally, my integration tests also produced results as expected.

Production, however, did not work.

As a result of the first two bullets, this problem was very difficult to find.

It turned out the problem was that my test dates were using my time zone (America/Chicago) but the production data was providing dates in UTC, which I did not realize, and the logic for the filter wasn't correct for UTC dates. (I was using joda time DateTime objects).

Where did my workflow break down?

Did I fail to produce a spec that specified that the logic needed to handle dates in any time zone?

Did I fail to thoroughly consider all cases at the unit test level?

Did I fail to insure the integration test was sufficiently similar to production?

Other?

What changes can I make to my workflow to better prevent this sort of mistake in the future?

How can I more effectively debug a problem when there is an issue in production but not in testing?

答:
In addition to Jimmy Hoffa's answer:
You ask wide net around all kind of bugs but your example is a bit more narrow:
As far as I can see from your example you ran into an application weak-spot in that it doesn't deal well with localization. This is a big area where subtle bugs can come up and is very wide. Local differences and assumptions about those can give you headaches.
Some examples:

Sunday is first day of the week in the US, Monday in Europe.

Month before day in US vs day before month in Europe.

But also using "," or "." when using values are different.

So my answer would be:

1) Where did my workflow break down?

It broke down because you didn't take localization into account.

2) What changes can I make to my workflow to better prevent this sort of mistake in the
future?

Learn about localization and check you entire application for localization issues.


问:
Using packages (gems, eggs, etc.) to create decoupled architectures
The main issue

Seeing the good support most modern programming platforms have for package management (think gem, npm, pip, etc), does it make sense to design an application or system be composed of internally developed packages, so as to promote and create a loosely coupled architecture?

Example

An example of this would be to create packages for database access, as well as for authentication and other components of the system.  These, of course, use external packages as well.  Then, your system imports and uses these packages - instead of including their code within its own code base.

Considerations

To me, it seems that this would promote code decoupling and help maintainability, almost in a Web-based-vs.-desktop-application kind of way (updates are applied almost automatically, single code base for single functionality, etc.).

Does this seem like a rational and sane design concept?  Is this actually used as a standard way of structuring applications today?

答:
This is a good idea, all in all. You will need to think about setting up an internal package repository (usually called "artifact repository" in the Java world, or "pypi server" in the  Python world), so that you keep there those packages you don't want or can't release as open source.

As @pdr has noted, be prepared to have your own dependency hell, where a change to some package requires first another change in another package, and this means not just changing a line of code, but testing it, possibly getting the changes accepted, building a release, and uploading the release to the aforementioned package repository. And then changing what you intended to change.

The only recipe I can give you from my experience to try and minimize this: do not rely solely on abstracting common concepts from your packages into a "common" or "framework" package. This can seem like a very objective thing to do, but it will lead to a monster package that needs frequent, possibly contradictory changes and releases. Much better, think about the functionalities in your system, and create a helper package for each one of them, as you have outlined in your question.

Aside from that, the main benefit you will get is that your apps are insulated from (many) dependencies, so you can exchange them without pain.


答:
More to add to both: though process can't guarantee a bug free application, neither can 100% code coverage by unit tests.

In fact having that can very easily lead to a false sense of security, you wouldn't be the first team lulled into complacency by the idea that "we have 100% code coverage, now our system must be free of bugs".

Not only can there be bugs in the unit tests themselves, hiding bugs in the software, but unit tests do not test whether parts of the application work together as expected. If you have say a web service client and a web service, both unit tested, but against different specifications (say the specs changed after the service was written, the client was written to a different WSDL than what the service implements) your unit tests are never going to alert you about that.

You will also need proper integration testing, regression testing, functional testing (does the system actually implement the functionality required, if it doesn't it may be technically correct but it's still useless), usability testing (if it works, but is so kludgy the users don't use it or don't use it as intended, it's still a useless system). All are needed, all have their place, neither is on its own a guarantee that the system works correctly.

And of course all of them depend on properly written, well detailed, and well verified and signed off functional design documents, translated into correct technical design documents.

Title: How to analyze a scenario where a bug didn't get caught and adjust development workflow to prevent similar errors

Body:
I had a bug that was really difficult to track down, because all the unit tests were green, but the production application didn't work properly.

Here's what happened:

I had a filter class that set my application to ignore data that was not in some specified time windows.

The unit test, which seemed thorough to me, turned green.

Additionally, my integration tests also produced results as expected.

Production, however, did not work.

As a result of the first two bullets, this problem was very difficult to find.

It turned out the problem was that my test dates were using my time zone (America/Chicago) but the production data was providing dates in UTC, which I did not realize, and the logic for the filter wasn't correct for UTC dates. (I was using joda time DateTime objects).

Where did my workflow break down?

Did I fail to produce a spec that specified that the logic needed to handle dates in any time zone?

Did I fail to thoroughly consider all cases at the unit test level?

Did I fail to insure the integration test was sufficiently similar to production?

Other?

What changes can I make to my workflow to better prevent this sort of mistake in the future?

How can I more effectively debug a problem when there is an issue in production but not in testing?


问:
Clean way to use mutable implementation of Immutable interfaces for encapsulation
My code is working on some compost relationship which creates a tree structure, class A has many children of type B, which has many children of type C etc.  The lowest level class, call it bar, also points to a connected bar class.  This effectively makes nearly every object in my domain inter-connected.  Immutable objects would be problematic due to the expense of rebuilding almost all of my domain to make a single change to one class.

I chose to go with an interface approach.  Every object has an Immutable interface which only publishes the getter methods.  I have controller objects which constructs the domain objects and thus has reference to the full objects, thus capable of calling the setter methods; but only ever publishes the immutable interface.  Any change requested will go through the controller.  So something like this:

```<code>public interface ImmutableFoo{

    public Bar getBar();
    public Location getLocation();
}

public class Foo implements ImmutableFoo{

    private Bar bar;
    private Location location;

    @Override
    public Bar getBar(){
        return Bar;
    }

    public void setBar(Bar bar){
        this.bar=bar;
    }

    @Override
    public Location getLocation(){
        return Location;
    }
 }

 public class Controller{
     Private Map<Location, Foo> fooMap;

     public ImmutableFoo addBar(Bar bar){
         Foo foo=fooMap.get(bar.getLocation());

         if(foo!=null)
             foo.addBar(bar);

         return foo;
     }
}
</code>```

I felt the basic approach seems sensible, however, when I speak to others they always seem to have trouble envisioning what I'm describing, which leaves me concerned that I may have a larger design issue then I'm aware of.  Is it problematic to have domain objects so tightly coupled, or to use the quasi-mutable approach to modifying them?

Assuming that the design approach itself isn't inherently flawed the particular discussion which left me wondering about my approach had to do with the presence of business logic in the domain objects.

Currently I have my setter methods in the mutable objects do error checking and all other logic required to verify and make a change to the object.  It was suggested that this should be pulled out into a service class, which applies all the business logic, to simplify my domain objects.  I understand the advantage in mocking/testing and general separation of logic into two classes.

However, with a service method/object It seems I loose some of the advantage of polymorphism, I can't override a base class to add in new error checking or business logic.  It seems, if my polymorphic classes were complicated enough, I would end up with a service method that has to check a dozen flags to decide what error checking and business logic applies.  So, for example, if I wanted to have a childFoo which also had a size field which should be compared to bar before adding par my current approach would look something like this.

```<code> public class Foo implements ImmutableFoo{

     public void addBar(Bar bar){
         if(!getLocation().equals(bar.getLocation())
            throw new LocationException();

         this.bar=bar;
     }
 }

 public interface ImmutableChildFoo extends ImmutableFoo{
     public int getSize();
 }

 public ChildFoo extends Foo implements ImmutableChildFoo{

      private int size;

      @Override
      public int getSize(){
          return size;
      }

      @Override
      public void addBar(Bar bar){
          if(getSize()<bar.getSize()){
              throw new LocationException();

          super.addBar(bar);
      }
</code>```

My colleague was suggesting instead having a service object that looks something like this (over simplified, the 'service' object would likely be more complex).

```<code> public interface ImmutableFoo{
     ///original interface, presumably used in other methods
     public Location getLocation();
     public boolean isChildFoo();
 }
 public interface ImmutableSizedFoo implements ImmutableFoo{
     public int getSize();
 }

public class Foo implements ImmutableSizedFoo{
     public Bar bar;

     @Override
     public void addBar(Bar bar){
         this.bar=bar;
     }

     @Override
     public int getSize(){
         //default size if no size is known
         return 0;
     }

      @Override
      public boolean isChildFoo
         return false;
      }
 }

 public ChildFoo extends Foo{

      private int size;

      @Override
      public int getSize(){
          return size;
      }

      @Override
      public boolean isChildFoo();
         return true;
      }
 }

 public class Controller{
     Private Map<Location, Foo> fooMap;

     public ImmutableSizedFoo addBar(Bar bar){
         Foo foo=fooMap.get(bar.getLocation());
         service.addBarToFoo(foo, bar);

         returned foo;
     }

     public class Service{

         public static void addBarToFoo(Foo foo, Bar bar){

            if(foo==null)
               return;
            if(!foo.getLocation().equals(bar.getLocation()))
                throw new LocationException();
            if(foo.isChildFoo() && foo.getSize()<bar.getSize())
                throw new LocationException();

            foo.setBar(bar);
         }
   }
}
</code>```

Is the recommended approach of using services and inversion of control inherently superior, or superior in certain cases, to overriding methods directly?  If so is there a good way to go with the service approach while not loosing the power of polymorphism to override some of the behavior?

答:
I think that calling those interfaces Immutable is source of confusion. They are not Immutable, they are read only view of possibly muttable objects. This alone can lead to your design to be misunderstood. Call them ReadOnlySomething or ReadableSomething (this convention allows for  WritableSomething and ReadWriteableSomething (which is ugly long, so maybe not so gud idea)), or SomethingView (or anything else that conveys meaning that these things are not necessarily  immutable, but does not allow mutation thourg them).

About inheritance: use it if there actually is 'IS A' rellationship and caller does not need to know actual type to use it meaningfully. If caller needs to inspect it, use composition.


问:
If a library doesn't provide all my needs, how should I proceed?
I'm developing an application involving math and physics models, and I'd like to use a Math library for things like Matrices. I'm using C#, and so I was looking for some libraries and found Math.NET. I'm under the impression, from past experience, that for math, using a robust and industry-approved third party library is much better than writing your own code.

It seems good for many purposes, but it does not provide support for Quaternions, which I need to use as a type. Also, I need some functions in Vector and Matrix that also aren't provided, such as rotation matrices and vector rotation functions, and calculating cross products. At the same time, it provides a lot of functions/classes that I simply do not need, which might mean a lot of unnecessary bloat and complexity.

At this rate, should I even bother using the library? Should I write my own math library? Or is it a better idea to stick to the third party library and somehow wrap around it? Perhaps I should make a subclass of the Matrix and Vector type of the library? But isn't that considered bad style?

I've also tried looking for other libraries but unfortunately I couldn't find anything suitable.

答:
Write the classes you need using the library.  Once you have proper code and tests in place, offer to contribute those classes back into the library, since MathDotNet seems to be an open source project.

Just to make things clear, using the library to write those functionalities you find missing does not mean to modify the library's source code to patch it on your own.  It means importing the library in your code, and using its existing functions to save as much work as possible while developing your new classes.  You can later isolate those changes and create a patch for the library out of them.

Also, to clarify license matters: the MIT license of MathDotNet does not force you to contribute your changes.  But it is a Good Thing to share, it lifts the burden of maintaining your changes from your own shoulders, and it helps prevent a future where every C# developer has his/her own Quaternion implementation.


问:
Should a package manager modify your .bashrc file?
I am writing a package for something that requires an environment variable to be set in order to execute properly.  Should the install step of a package manager modify a user's environment, or simply prompt the user to do so themselves?  My intuition would be the latter, but I can see arguments for the former.</p>

答:
You're assuming that "user" is singular. What happens if I have thousands of users on this system?

You're assuming that you can even find the home directory of the user. If users are managed through e.g. LDAP you may not even be allowed to get a list of all valid users. The home directories may not be in /home; they may be dynamically mounted from the network. The user's home directory may be encrypted and the key inaccessible while they are not logged in.

There is no way to do this reliably in every possible situation. Use the distro's mechanism for setting environment variables for users as they log in or spawn shells. If that doesn't work, write a wrapper. (The wrapper can also be a binary if necessary, to address the argument in comments).


问:
Password reset process
So I'm working on my first password reset mechanism. I'm going with what I understand to be a fairly common procedure:

User clicks "Forgot Password"

User is prompted for email address

If the entered email address is valid, send an email with a reset link to it

Reset link uses a token of some kind to identify the user account and keep its details secure

When password is reset, generate a new token and save it to the user account

I feel like this should be pretty secure, but I was wondering if anyone could provide any insights that I may not be considering at this point.

答:
From the OWASP Forgot Password Cheat Sheet:

Gather Identity Data or Security Questions

The first page of a secure Forgot Password feature asks the user for multiple pieces of hard data that should have been previously collected (generally when the user first registers). [...] At a minimum, you should have collected some data that will allow you to send the password reset information to some out-of-band side-channel, such as a (possibly different) email address or an SMS text number, etc. to be used in Step 3.

Verify Security Questions

After the form on Step 1 is submitted, the application verifies that each piece of data is correct for the given username. If anything is incorrect, or if the username is not recognized, the second page displays a generic error message such as “Sorry, invalid data”. If all submitted data is correct, Step 2 should display at least two of the user’s pre-established personal security questions, along with input fields for the answers.

Send a Token Over a Side-Channel

After step 2, lock out the user's account immediately. Then email or SMS the user a randomly-generated code having 8 or more characters. This introduces an “out-of-band” communication channel and adds defense-in-depth as it is another barrier for a hacker to overcome. If the bad guy has somehow managed to successfully get past steps 1 and 2, he is unlikely to have compromised the side-channel. It is also a good idea to have the random code which your system generates to only have a limited validity period, say no more than 20 minutes or so.

Allow user to change password

Step 4 requires input of the code sent in step 3 and allows the user to reset his password. Display a simple HTML form with one input field for the code, one for the new password, and one to confirm the new password. Verify the correct code is provided and be sure to enforce all password complexity requirements that exist in other areas of the application.

There's more detail at the link.

Title: Password reset process


问:
Builder Pattern: When to fail?
When implementing the Builder Pattern, I often find myself confused with when to let building fail and I even manage to take different stands on the matter every few days.

First some explanation:

With failing early I mean that building an object should fail as soon as an invalid parameter is passed in. So inside the SomeObjectBuilder.

With failing late I mean that building an object only can fail on the build() call that implicitely calls a constructor of the object to be built.

Then some arguments:

In favor of failing late: A builder class should be no more than a class that simply holds values. Moreover, it leads to less code duplication.

In favor of failing early: A general approach in software programming is that you want to detect issues as early as possible and therefore the most logical place to check would be in the builder class' constructor, 'setters' and ultimately in the build method.

What is the general concensus about this?

答:
Invalid values which are invalid because they are not tolerated should be made known immediately in my opinion.  In other words, if you accept only positive numbers, and a negative number is passed in, there is no need to have to wait until build() is called.  I wouldn't consider these the types of problems you would "expect" to have happen, since it is a prerequisite to calling the method to begin with.  In other words, you would not likely depend on the failing of setting certain parameters.  More likely you would presume the parameters are correct or you'd perform some check yourself.

However, for more complicated issues which aren't as easily validated may be better off being made known when you call build().  A good example of this might be using the connection information you provide to establish a connection to a database.  In this case, while you technically could check for such conditions, it is no longer intuitive and it only complicates your code.  As I see it, these are also the types of issues which might actually happen and that you cannot really anticipate until you try it.  It's sort of the difference between matching a string with a regular expression to see if it could be parsed as an int and simply trying to parse it, handling any potential exceptions which may occur as a consequence.

I generally dislike throwing exceptions when setting parameters since it means having to catch any exception thrown, so I tend to favor validation in build().  So for this reason, I prefer using RuntimeException since again, errors in parameters passed should not generally happen.

However, this is more of a best practice than anything.  I hope that answers your question.

Title: Builder Pattern: When to fail?


答:
As far as I know, the general practice (not sure if there's consensus) is to fail as early as you can feasibly discover an error.  This also makes it more difficult to unintentionally misuse your API.

If it is a trivial attribute that can be checked on input, such as a capacity or length which should be non-negative, then you're best to fail immediately.  Holding off the error increases the distance between mistake and feedback, which makes it more difficult to find the source of the problem.

If you have the misfortune of being in a situation where the validity of an attribute depends on others, then you have two choices:

Require that both (or more) attributes be supplied simultaneously (i.e. single method invocation).

Test validity as soon as you know no more changes are incoming: when build() or so is called.

As with most things, this is a decision made in a context.  If the context makes it awkward or complicated to fail early, a trade-off can be made to defer checks to a later time, but fail-fast should be the default.

Title: Builder Pattern: When to fail?

Body:
When implementing the Builder Pattern, I often find myself confused with when to let building fail and I even manage to take different stands on the matter every few days.

First some explanation:

With failing early I mean that building an object should fail as soon as an invalid parameter is passed in. So inside the SomeObjectBuilder.

With failing late I mean that building an object only can fail on the build() call that implicitely calls a constructor of the object to be built.

Then some arguments:

In favor of failing late: A builder class should be no more than a class that simply holds values. Moreover, it leads to less code duplication.

In favor of failing early: A general approach in software programming is that you want to detect issues as early as possible and therefore the most logical place to check would be in the builder class' constructor, 'setters' and ultimately in the build method.

What is the general concensus about this?


答:
Let's look at the options, where we can place the validation code:

Inside the setters in builder.

Inside the build() method.

Inside the constructed entity: it will be invoked in build() method when the entity is being created.

Option 1 allows us to detect problems earlier, but there can be complicated cases when we can validate input only having the full context, thus, doing at least part of validation in build() method. Thus, choosing option 1 will lead to inconsistent code with part of validation being done in one place and another part being done in other place.

Option 2 isn't significantly worse than option 1, because, usually, setters in builder are invoked right before the build(), especially, in fluent interfaces. Thus, it's still possible to detect a problem early enough in most cases. However, if the builder is not the only way to create an object, it will lead to duplication of validation code, because you'll need to have it everywhere where you create an object. The most logical solution in this case will be to put validation as close to created object as possible, that is, inside of it. And this is the option 3.

From SOLID point of view, putting validation in builder also violates SRP: the builder class already has responsibility of aggregating the data to construct an object. Validation is establishing contracts on its own internal state, it's a new responsibility to check the state of another object.

Thus, from my point of view, not only it's better to fail late from design perspective, but it's also better to fail inside the constructed entity, rather than in builder itself.

UPD: this comment reminded me of one more possibility, when validation inside the builder (option 1 or 2) makes sense. It does make sense if the builder has its own contracts on the objects it is creating. For example, assume that we have a builder that constructs a string with specific content, say, list of number ranges 1-2,3-4,5-6. This builder may have a method like addRange(int min, int max). The resulting string does not know anything about these numbers, neither it should have to know. The builder itself defines the format of the string and constraints on the numbers. Thus, the method addRange(int,int) must validate the input numbers and throw an exception if max is less than min.

That said, the general rule will be to validate only the contracts defined by the builder itself.

Title: Builder Pattern: When to fail?


答:
Given that you use Java, consider authoritative and detailed guidance provided by Joshua Bloch in the article Creating and Destroying Java Objects (bold font in below quote is mine):

Like a constructor, a builder can impose invariants on its parameters. The build method can check these invariants. It is critical that they be checked after copying the parameters from the builder to the object, and that they be checked on the object fields rather than the builder fields (Item 39). If any invariants are violated, the build method should throw an IllegalStateException (Item 60). The exception's detail method should indicate which invariant is violated (Item 63).

Another way to impose invariants involving multiple parameters is to have setter methods take entire groups of parameters on which some invariant must hold. If the invariant isn't satisfied, the setter method throws an IllegalArgumentException. This has the advantage of detecting the invariant failure as soon as the invalid parameters are passed, instead of waiting for build to be invoked.

Note according to editor explanation on this article, "items" in above quote refer to rules presented in Effective Java, Second Edition.

The article doesn't dive deep into explaining why this is recommended, but if you think of it, the reasons are pretty apparent. Generic tip on understanding this is provided right there in the article, in the explanation how builder concept is connected to that of constructor - and class invariants are expected to be checked in constructor, not in any other code that may precede / prepare its invocation.

For a more concrete understanding for why checking invariants prior to invoking a build would be wrong, consider a popular example of CarBuilder. Builder methods may be invoked in an arbitrary order and as a result, one can't really know whether particular parameter is valid until the build.

Consider that sports car can't have more than 2 seats, how could one know if setSeats(4) is okay or not? It's only at the build when one can know for sure whether setSportsCar() was invoked or not, meaning whether to throw TooManySeatsException or not.

Title: Builder Pattern: When to fail?


问:
Why do we need a format for binary executable files
When binary files (i.e. executables) are saved they usually have a format (e.g. ELF or .out) where we have a header containing pointers to where data or code is stored inside the file. But why don't we store the binary files directly in the form of sequence of machine instructions.
Why do we need to store data separately from the code?
Secondly when the assembler creates a binary file is the file is among the above formats?

答:
Setting certain areas as data lets some architectures detect when trying to execute them (and then let the OS kill it).

Also there is an architecture design that splits code and data into separate address spaces so the file needs to make the difference between the 2 otherwise it wouldn't be able to access the data. The restrictions of the executable format comes from trying to be cross compatible between them (assuming the same instruction sets).


答:
Because we want our computers to do more than just execute one fixed program.

Having a stream of opcodes in memory and endlessly stepping through it is fine if you have a single-purpose machine. But on a real computer, you want to achieve things such as

have one binary call another and transfer control to it

have one binary call another and get control back after it terminates

multi-task between many programs and make it appear as if they were running simultaneously

give one program monitoring or administration rights over another program to limit the things the other program can do

and much, much more!

For all of this, you need executable software that treats other executable software as its input data, which means that you have to be able to express things such as "this code owns that memory address" or "those two processes are really instances of the same program and can share their static data segment".

A lot of the bytes in a binary file is, in fact, a string of machine code, but everything else has to be stored somehow as well, and a binary file format is just a spec saying how to do this.

Title: Why do we need a format for binary executable files

Body:
When binary files (i.e. executables) are saved they usually have a format (e.g. ELF or .out) where we have a header containing pointers to where data or code is stored inside the file. But why don't we store the binary files directly in the form of sequence of machine instructions.
Why do we need to store data separately from the code?
Secondly when the assembler creates a binary file is the file is among the above formats?


答:
There are several use cases for metadata like this, some being "necessary" and others being nice to have.

At the very bare minimum (if the code isn't position-independent, which is still not the default), the loader needs to know at which address the code should go.

On some platforms (including some in common use today, such as embedded micro controllers), there is separate memory for code and for data. The loader needs to be able to tell code from data to put the code into memory the CPU can execute from, and the data into memory the CPU can read and write.

For binaries which aren't executable files but rather libraries, you need a symbol table to enable code using that library to call the right function.

Even if there isn't physically separate memory for code and data, it's beneficial to set up memory such that the data is not executable and the code is not writable. Sure, you could let the program do that itself in initialization, but that's error prone, pointless code duplication for no good reason.

Knowing the purpose of data sections can allow optimization. For example, if you have a separate .bss section for data that should be initialized to zero, a modern OS can lazily allocate zero'd pages to improve process creation time. If you have a .rodata section for read-only data, this data can go into separate ROM (if your computer has ROM), freeing up RAM and possibly bringing other benefits. When running multiple instances of a program, the data assumed read-only (including code) can be shared among those processes.

I'm sure there are more reasons, I'm not very familiar with the design decisions that go into a loader.


问:
Which approach would lead to an API that is easier to use?
I'm writing a JavaScript API and for a particular case, I'm wondering which approach is the sexiest. Let's take an example: writing a VideoPlayer, I add a getCurrentTime method which gives the elapsed time since the start.

The first approach simply declares getCurrentTime as follows:

```<code>getCurrentTime():number
</code>```

where number is the native number type. This approach includes a CURRENT_TIME_CHANGED event so that API users can add callbacks to be aware of time changes. Listening to this event would look like the following:

```<code>myVideoPlayer.addEventListener(CURRENT_TIME_CHANGED, function(evt){
    console.log ("current time = "+evt.getDispatcher().getCurrentTime());
});
</code>```

The second approach declares getCurrentTime differently:

```<code>getCurrentTime():CustomNumber
</code>```

where CustomNumber is a custom number object, not the native one. This custom object dispatches a VALUE_CHANGED event when its value changes, so there is no need for the CURRENT_TIME_CHANGED event! Just listen to the returned object for value changes! Listening to this event would look like the following:

```<code>myVideoPlayer.getCurrentTime().addEventListener(VALUE_CHANGED, function(evt){
    console.log ("current time = "+evt.getDispatcher().valueOf());
});
</code>```

Note that CustomNumber has a valueOf method which returns a native number that lets the returned CustomNumber object being used as a number, so:

```<code>var result = myVideoPlayer.getCurrentTime()+5;
</code>```

will work!

So in the first approach, we listen to an object for a change in its property's value. In the second one we directly listen to the property for a change on its value. There are multiple pros and cons for each approach, I just want to know which one the developers would prefer to use!

答:
Go with the first approach. When people use a method like getCurrentTime() and store the returned value, they expect that that value will remain the time at the moment they called the method. Having that value suddenly change is going to be a source of great confusion:

```<code>prevTime = myVideoPlayer.getCurrentTime();
//...at some later point
timeElapsed = myVideoPlayer.getCurrentTime() - prevTime;
</code>```

Now timeElapsed is 0, which is wrong. The correct code for that API would be:

```<code>prevTime = myVideoPlayer.getCurrentTime().valueOf();
//...at some later point
timeElapsed = myVideoPlayer.getCurrentTime() - prevTime;
</code>```

But this way is very uncommon, and most people will instinctively use the first method and get confusing bugs.

Body:
Go with the first approach. When people use a method like getCurrentTime() and store the returned value, they expect that that value will remain the time at the moment they called the method. Having that value suddenly change is going to be a source of great confusion:

prevTime = myVideoPlayer.getCurrentTime();
//...at some later point
timeElapsed = myVideoPlayer.getCurrentTime() - prevTime;

Now timeElapsed is 0, which is wrong. The correct code for that API would be:

prevTime = myVideoPlayer.getCurrentTime().valueOf();
//...at some later point
timeElapsed = myVideoPlayer.getCurrentTime() - prevTime;

But this way is very uncommon, and most people will instinctively use the first method and get confusing bugs.


问:
What non-programming books should a programmer read to help develop programming/thinking skills?
There are a lot of questions about what programming books should be on the programmer's bookshelf. How about non-programming related books that can help you become a better programmer or developer? It would also be interesting to know why they would help.

My first choice would be Sun Tzu's "Art of War" (however cliché), because it made it obvious that the success of any project depends on the strength of its weakest link (and warfare is a big project).

答: The art of problem solving</p>

ContentLicense: CC BY-SA 2.5

Body: The art of problem solving


问:
Is Object Oriented Programming a solution to complexity?
Do you think Object Oriented Programming is a solution to complexity. Why? This topic may be a bit controversial but my intentions to know the answer of Why from the experts here !</p>

答:
OOP is an attempt at a solution.

The best way to manage complexity is to create abstractions.  If I can turn my data into useful collections, with recognizable functions which operate on those collections, I can start thinking about the collections as discrete "things."  That's the basis for classes and methods.  In that respect, properly designed OOP can help to manage complexity.

Somewhere along the way, someone decided that we could use OOP to help solve the problem of code-reuse.  I mean, why reinvent the wheel? If someone else has done much of the work towards solving this problem, leverage what they've done, add the tweaks that your, particular project requires and voila! You've created a powerful, sophisticated application with relatively little work on your part.  OO programmers can be very productive programmers.

The end result is that modern OO programmers end up being "sorcerer's apprentices," where they tie together a bunch of large, unwieldy libraries with a few lines of "glue" and get something which works.  Sorta.  Kinda.  Most of the time.  Are there potential side-effects from using this library with that one? Maybe.  But who has time to really dig into the code contained in those libraries? Especially when the libraries are evolving.  The result is that we end up with bloated applications, where a programmer needed a handful of classes and methods from that library, but the app has to carry the weight of all the OTHER stuff they didn't need.

The end result is that you end up with much more complexity than you need.

Another mechanism to deal with complexity that you want to separate functionality.  You want all of your data access functions in one place.  You want all of your user interface functionality in one place.  You want all of your controllers in one place.  So you create different classes which manage different parts of the functionality.  So far, so good.  And this scales, to a degree; your developers who are skilled with data access can write those classes, your user-interface people can write the user-interface classes, etc.  All is well and good.

Until you have to maintain something written by someone else.

Yes, it's good to know that all of the data access functions are located here.  But what calls them?

This method is calling that method on that class.  But when I look at the class definition, there is no method with that name.  Oh, that's inherited from something else one or two layers up in the inheritance chain.  Wait a minute; that class implemented an interface? How many different classes implement that interface? And we're using some complicated run-time system (I'm looking at you, Spring) to "wire together" instances of classes at run-time? Where ANY class that implements that interface can be used?

You end up with lots of small, discrete methods which do precise things.  But this one calls that one, in another class.  Which calls that one, in yet another class.  Which calls that one, in still another class.  Which calls that one, in an additional class.  Which returns a result of a particular type.  On which you have to call a method to do a certain thing.  Which returns a result of another type.  Etc.

There's a term for this: spaghetti code.

You end up with a very complex system needed just to compose the code.  Hence IDEs like Visual Studio, Eclipse and NetBeans.  All of which have a significant learning curve.  Indeed, many of them are able to encapsulate/aggregate multiple tools, developed by different groups, each of which have their OWN learning curves.

This is managing complexity?

Debugging code is twice as hard as writing it.  Good luck debugging some of this stuff.  Especially if it's using multiple libraries, "wired together" at run-time using some kind of dependency-injection system.

In summary: OOP provides what looks like a promising tool to help manage complexity.  The reality is the resulting code tends to be horribly bloated (because you can't extract just the pieces you need from all of those linked libraries) and you need sophisticated tools just to navigate the code.  It quickly becomes a maintenance nightmare.

IMHO, it's a net loss; it adds more complexity than it eliminates.  It does allow you to do things which would be exceedingly difficult, possibly even impossible, without it.  But any large project rapidly evolves into an unmaintainable mess.

If you already know how it works, and you can remember that, you might stand a chance at maintaining it.

Remember to apply Eagleson's Law: any code of your own, which you haven't looked at in six months, might as well be written by someone else.


问:
Are sequence designs appropriate for GUI button design?
Specifically, I have numerous buttons that will be changing color based on state information from operator input and input from various subcomponents and sensors.  I would like to use UML or some other type of design diagrams to be able to capture the color transition.

Some folks have suggested sequence diagrams, but I haven't been able to find any good examples that show how to incorporate this design artifact.  I would really like to head in this direction to help developers.

Are sequence designs in fact, appropriate, or is there a more appropriate design?

答: Use wireframes.  Basically a drawing or artificial screenshot of the UI in each state, with transitions marked with the user input that causes the transition.  These tend to be clear to both designers and coders.</p>


问:
Should data structures be integrated into the language (as in Python) or be provided in the standard library (as in Java)?
In Python, and most likely many other programming languages, common data structures can be found as an integrated part of the core language with their own dedicated syntax. If we put LISP's integrated list syntax aside, I can't think of any other languages that I know which provides some kind of data structure above the array as an integrated part of their syntax, though all of them (but C, I guess) seem to provide them in the standard library.

From a language design perspective, what are your opinions on having a specific syntax for data structures in the core language? Is it a good idea, and does the purpose of the language (etc.) change how good this could be of a choice?

Edit: I'm sorry for (apparently) causing some confusion about which data structures I mean. I talk about the basic and commonly used ones, but still not the most basic ones. This excludes trees (too complex, uncommon), stacks (too seldom used), arrays (too simple) but includes e.g. sets, lists and hashmaps.

答:
In general I find convenient to have literals for lists, sets and so on. But it sometimes bugs me that I do not know anything about the actual implementation of - say - the Python list or the Javascript array. The only thing I can be sure of is that they expose a given interface.

I take as a benchmark of a language expressiveness how well it can write its own data structures as libraries, and how convenient is to use them.

For instance, Scala provides various collections with different implementation and performance guarantees. All of them are implemented in Scala itself, and the syntax to use them is only slightly more complex than if they were builtin and had runtime support.

The only basic structure that really needs support from the runtime itself, at least in a managed language, is the array: if you do not manage the memory, you will have a hard time getting a bunch of adjacent bytes. Every other structure can be built out of arrays and pointers (or references).


问:
WPF properties memory management
I'm trying to build binding system similar to the one that is used in WPF and I ran into some memory leaking problems, so here comes my question - how is memory managed in WPF property system?

From what I know in WPF values of DependencyProperties are stored in external containers - what I wanna know is how are they collected when DependencyObject dies?

Simplest solution would be to store them is some weak reference dictionary - but here comes the main problem I ran into - when there is a listener on property that needs reference to its (this property) parent it holds it (the parent) alive (when value of weak reference dictionary points somewhere, even indirectly, to key - it can't be collected).

How is it avoided in WPF without the need of using weak references everywhere?

答:
WPF makes extensive use of weak references for this very reason. While it may be a bit of a pain to implement, it is the correct answer here. When discussing the weak reference design pattern, Microsoft writes that:

Implementing the weak event pattern is interesting primarily for control authors. As a control author, you are largely responsible for the behavior and containment of your control and the impact it has on applications in which it is inserted. This includes the control object lifetime behavior, in particular the handling of the described memory leak problem.

Certain scenarios inherently lend themselves to the application of the weak event pattern. One such scenario is data binding. In data binding, it is common for the source object to be completely independent of the listener object, which is a target of a binding. Many aspects of WPF data binding already have the weak event pattern applied in how the events are implemented."

Since you are writing something along these lines, from the sound of it, you should make use of this pattern.

Title: WPF properties memory management


问:
Who should have full visibility of all (non-data) requirements information?
I work at a smallish mid-size company where requirements are sometimes nothing more than an email or brief meeting with a subject matter manager requiring some new feature.

Should a programmer working on a feature reasonably expect to have access to such "request emails" and other requirements information? Is it more appropriate for a "program manager" (PGM) to rewrite all requirements before sharing with programmers?

The company is not technology-centric and has between 50 and 250 employees. (fewer than 10 programmers in sum)

Our project management "software" consists of a "TODO.txt" checked into source control in "/doc/".

Note: This is nothing to do with "sensitive data access".  Unless a particular subject matter manager's style of email correspondence is top secret.

Given the suggested duplicate, perhaps this could be a turf war, as the PGM would like to specify HOW.  Whereas WHY is absent and WHAT is muddled by the time it gets through to the programmer(s)...

Basically.  Should specification be transparent to programmers?  Perhaps a history of requirements might exist.  Shouldn't a programmer be able to see that history of reqs if/when they can tell something is hinky in the spec?

This isn't a question about organizing requirements.  It is a question about WHO should have full VISIBILITY of requirements.  I'd propose it should be ALL STAKEHOLDERS.  Please point out where I'm wrong here.

答:
There must be a process of winnowing down customers' desires into what are the actual requirements. Someone has to separate the "nice to haves" from the "must haves", so the team knows what to implement and test.

But I would think that sharing the bigger picture would be helpful, because the devs might have insight that would make the functionality more relevant, more complete, more direct, or easier to implement.

And I would get awfully annoyed if expressed requirements surfaced after work had started or completed on the rewritten requirements.


问:
Can Javascript code be encrypted making it hard for someone to copy?
When you compile and distribute a client you are automatically protecting yourself from someone seeing and modifying your code. Can this be achieved on a Javascript client?</p>

答:
..because they can implement your app on their own server, and use your back-end resources to power their site.  Many client-side apps store an appKey that gives them access to the backend.  That's how the server knows it's an authorized client.

Worse, I don't want them to be able to modify my client-app, such that they can clone my site, and fool users into logging into my site, while also submitting the user's password to their own database as a harvesting mechanism.

Also, imagine I offer a free web app/service .. another site downloads the client-app, and modifies it such that they charge for access, handling billing/payment collection on their own server, but otherwise relying upon the API services on my server to provide the backend to their webApp offering (that I created).

At least with the code minified, it is unlikely that they can easily edit the client-app to charge people money, or clone my site and harvest passwords, etc.


问:
Should I always encapsulate an internal data structure entirely?
Please consider this class:

```<code>class ClassA{

    private Thing[] things; // stores data

    // stuff omitted

    public Thing[] getThings(){
        return things;
    }

}
</code>```

This class exposes the array it uses to store data, to any client code interested.

I did this in an app I'm working on. I had a ChordProgression class that stores a sequence of Chords (and does some other things). It had a Chord[] getChords() method that returned the array of chords. When the data structure had to change (from an array to an ArrayList), all client code broke.

This made me think - maybe the following approach is better:

```<code>class ClassA{

    private Thing[] things; // stores data

    // stuff omitted

    public Thing[] getThing(int index){
        return things[index];
    }

    public int getDataSize(){
        return things.length;
    }

    public void setThing(int index, Thing thing){
        things[index] = thing;
    }

}
</code>```

Instead of exposing the data structure itself, all of the operations offered by the data structure are now offered directly by the class enclosing it, using public methods that delegate to the data structure.

When the data structure changes, only these methods have to change - but after they do, all client code still works.

Note that collections more complex than arrays might require the enclosing class to implement even more than three methods just to access the internal data structure.

Is this approach common? What do you think of this? What downsides does it have other? Is it reasonable to have the enclosing class implement at least three public methods just to delegate to the inner data structure?

答: This is pretty common to hide your internal data structure from outside world. Sometime it is overkill specially in DTO. I recommend this for domain model. If at all its required to expose, return the immutable copy. Along with this i suggest creating an interface having these methods like get , set , remove etc.</p>


答:
Last minute changes kill projects regardless if you are talking software, construction, etc...

A Program Manager helps mitigate competing requests from different parties to determine based on priority, need or other criteria which of these requests get accommodated and how to resolve conflicts in requests.  They generally declare what the next release should have.  The person in the project manager role generally can take over from here.

The Project Manager will be responsible for organizing the appropriate resources and keeping track of the project so that the schedule is met.  They will communicate the project status to stakeholders, and work with the program manager as well as the other stakeholders to mitigate project changes that are necessary.

If you don't have these two guys playing tackle for the software developers then they will inevitably be distracted from the goal of getting a software release out on time and on budget and with agreed upon features.  It basically comes down to game theory, each business unit has important needs and some may be better or more important than others but when they compete for a developers time and attention on a software project then nobody wins.

The business needs to agree that while not a software or IT company that IT should be a partner in the business as a business unit in its own right, rather than a class of employees like Janitors or Secretaries, or like a cost center that is to serve IT as McDonalds serves hamburgers made to order and immediately.  Once this realization occurs by management then a program manager for the software can truly be appointed to make sure that an acceptable outcome to all business units can occur with a much lower risk to the project in general.

Frame the argument in this way to the business in a post-mortem for your next project, "We can let each business unit fight for exactly what they want and have high risk that the project will fail, or we can ensure that an acceptable outcome can be met across the board that has low risk."

Title: Who should have full visibility of all (non-data) requirements information?

Body:
I work at a smallish mid-size company where requirements are sometimes nothing more than an email or brief meeting with a subject matter manager requiring some new feature.

Should a programmer working on a feature reasonably expect to have access to such "request emails" and other requirements information? Is it more appropriate for a "program manager" (PGM) to rewrite all requirements before sharing with programmers?

The company is not technology-centric and has between 50 and 250 employees. (fewer than 10 programmers in sum)

Our project management "software" consists of a "TODO.txt" checked into source control in "/doc/".

Note: This is nothing to do with "sensitive data access".  Unless a particular subject matter manager's style of email correspondence is top secret.

Given the suggested duplicate, perhaps this could be a turf war, as the PGM would like to specify HOW.  Whereas WHY is absent and WHAT is muddled by the time it gets through to the programmer(s)...

Basically.  Should specification be transparent to programmers?  Perhaps a history of requirements might exist.  Shouldn't a programmer be able to see that history of reqs if/when they can tell something is hinky in the spec?

This isn't a question about organizing requirements.  It is a question about WHO should have full VISIBILITY of requirements.  I'd propose it should be ALL STAKEHOLDERS.  Please point out where I'm wrong here.


问:
Origins of code indentation
I am interested in finding out who introduced code indentation, as well as when and where it was introduced.

It seems so critical to code comprehension, but it was not universal. Most Fortran and Basic code was (is?) unindented, and the same goes for Cobol.

I am pretty sure I have even seen old Lisp code written as continuous, line-wrapped text. You had to count brackets in your head just to parse it, never mind understanding it.

So where did such a huge improvement come from? I have never seen any mention of its origin.

Apart from original examples of its use, I am also looking for original discussions of indentation.

答:
An expansion on Ross Patterson's comment - COBOL compilers (or at least IBM's compilers, which I used in my pre-open systems career) enforced indentation (the "A" and "B" areas he mentions). If any of the elements that were required to be in these areas were not placed exactly, your code would fail compilation. However, beyond that no specific indentation was required - this often led to griping when modifying the code of another developer whose indentation style was different than yours - etiquette would suggest you follow the existing pattern as that preserved peace among peers; additionally, different styles in the same source would be aggravating to view, almost Tetris-like in appearance.

It's been years since I've thought about COBOL and its indentation - thanks for asking the question and providing a little trip to the past!

Marty

Title: Origins of code indentation


问:
"bug" in C++11 text by Stroustrup?
I found an apparent contradiction in the c++ text having to do with the result of the c_str() function operating on std:strings (in my copy, the definition and contradiction are on p1040).

First it defines the c_str() function as something that produces a 'C-style' (zero-terminated) string, but later it talks about how a C++ c_str value can have embed a 'C'-style, end-of-string terminators (i.e. NUL's) embedded in the string (that is defined by being NUL terminated).

Um... does anyone else feel that this is a 'stretching' of the definition of a C-string beyond it's definition?  I.e. I think what it means, is that if you were to look at the length() function as applied to the string, it will show a different end of string than using the C-definition of a z-string -- one that can contain any character except NUL, and is terminated by NUL.

I likely don't have to worry about it in my of my programs, but it seems like a subtle distinction that makes a C++ c_str, not really a 'C'-string.  Am I misunderstanding this issue?

Thanks!

答:
In C, NULL is the same as 0x00.  Or null is the same as zero.

And just to be clear, NUL is an equivalent name of NULL.

So Stroustrup's text is correct about how C++ c_str are terminated.

To provide a bit more context.  It's fairly common practice in C to memset a character array after creating it in order to make sure it will be null terminated.

```<code>char foo[20];
memset(foo, 0x00, 20);
strlen(foo);  /* Should return 0 */
</code>```

 Please forgive me if my syntax is off a bit. And for the use of magic numbers.

Title: "bug" in C++11 text by Stroustrup?

Body:
In C, NULL is the same as 0x00.  Or null is the same as zero.

And just to be clear, NUL is an equivalent name of NULL.

So Stroustrup's text is correct about how C++ c_str are terminated.

To provide a bit more context.  It's fairly common practice in C to memset a character array after creating it in order to make sure it will be null terminated.

char foo[20];
memset(foo, 0x00, 20);
strlen(foo);  /* Should return 0 */

 Please forgive me if my syntax is off a bit. And for the use of magic numbers.


答:
Your question has a lot of layers to it which make a simple answer elusive. At first blush the answer seems obvious - of course all stakeholders should have visibility into the requirements. But what does that actually mean?

To answer this please let me summarize your question to make sure I understand the situation correctly. According to your description the process for gathering requirements from your customers is informal - requirements come in via various means including e-mails and action items that are the result of meetings with customers, and that you are not included in these email or meeting discussions. It also sounds like your customers may have various level of experience in writing requirements for software. You have a person in a program-management role who is attempting to mediate these requirements to you, and whose processes for managing those requirements are minimal at best. To complicate matters further, it sounds like you do not trust the mediation and translation of the requirements by your PGM. Information that you believe is essential to fulfilling requirements is missing (Why and What). I also suspect that you may feel like the PGM is over-specifying the HOW in the requirements which would impinge on the design authority of you and your team - after all - As Engineers the HOW should be largely left up to you, especially since you are the people who are going to be held accountable for failure. The net-result of all of this is that you want to be able to see the whole "chain of custody" or history of a requirement in order to defend yourself and your team against certainty of being held accountable for failure due to what was ultimately a badly conceived/written/managed requirement. Is this correct?

My first reaction after reading your question was to think - this is a situation where agile practices could really make a difference on your team.

For instance, one of the root problems seems to be a lack of trust between you and the GPM. In agile we try to value "Individuals and interactions" over "Processes and tools". Doing this is very hard when trust has broken down between team members - and it is very tempting to try to find a solution by modifying the processes which have led to loss of trust. The first step in reestablishing the trust is always open and honest communication. Have you discussed this problem with the GPM in terms the GPM can understand and accept? It's not an easy thing to explain to someone that the reason you want a process change is because you don't trust them or their judgement. But that is exactly what needs to be communicated. You may also be surprised by the underlying reasons that the GPM wants to over-specify the HOWS and not communicate the WHY and WHAT. Perhaps this conversation can lead to a mutually beneficial compromise? One avenue I would suggest is agreeing on a format/template for the requirements produced by the GPM - my personal favorite way to specify requirements is via user-stories... but what you call them, their format or even the level of detail is not as important as the agreement about what they must communicate. Also remember than unless your PGM is a complete sociopath that they are going to be motivated by many of the same things you are. No one wants to be part of a losing team, everyone wants to succeed at least at some level. Upfront recognition of this will make this discussion a lot easier for everyone.

My second reaction also involves one of the agile principals - Customer collaboration over contract negotiation. It sounds to me like this PGM has inserted themselves between you and the customer - which I believe is an error on both of your parts. The PGM should have nothing to fear by allowing you to interact with the customer directly - better communication with the customer will ALWAYS result in a better product. This is common sense. It may be that the PGM's instinct here is actually to actually protect you from randomization by the customer. This is a noble instinct - but it can sometimes be a problem if the PGM does not recognize a difference between structured interactions (such as during a product demo or a product-backlog grooming session) and randomization. Perhaps the PGM doesn't see a difference between seeking out the customer's opinion about the best way to execute a feature and allowing the customer to lobby you for new features or task priority directly? The answer here is the same as before - open and honest communication and an understanding and agreement between you the PGM of what aspects of communication with the customer each is responsible for. At the very least, I would ask to be included in any discussions about new requirements. This is a very reasonable request and should not be threatening to your PGM if they think about it. But it's success will also depend on you as much as the PGM. Remember that the engineers role in discussions with customer's is primarily one of listening - which also means asking a lot of questions. Try not to engage with the customers directly about the priority or value of a feature request in these meetings - that is the job of the PGM who should then advocate the customer's position in their negotiations with you about priorities and scheduling.

Another agile principal that can help here as that of "Deliver[ing] working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale". If you can get your PGM to schedule software delivery in small incremental units that would be best, especially if you can get a commitment that no changes to requirements will be accepted after that incremental unit of work has started (i.e. no changes to a sprint after it has started, using SCRUM phrasing). Again, open and honest communication is key here. You need to communicate clearly what you are committing to delivering in order for the PGM to reasonably trust that you will achieve that commitment. Then you need to prove that you met that commitment by demonstration or openly and constructively confront failure when it occurs.

Finally - and least - consider advocating for adoption one of the cannon of formal agile practice systems such as SCRUM. To be clear - I think that adoption of an agile strategy will solve most of your problems without any need to change any of your management tools at all if that is what you are your Peers are comfortable with. But I also think that the social and cooperative underpinnings of methodologies like SCRUM could also help out A LOT.

For instance - the roles and processes around requirements gathering and management are very well defined in SCRUM with a tremendous amount of support in both the Programmer community and in the PM community. Likewise issues around communication with the customer. This could be a strategic move as well if it turns out that your PGM is simply an irrational control-freak who hates customers and programmers and can't wait to leave every night so they can go torture kittens or something... Advocating a well understood and industry accepted solution will make it easier for you to bypass that person if that ultimately ends up being what is required. For more information about SCRUM, please see https://www.scrum.org/. Also, keep in mind that SCRUM is an agile process. What this means in practical terms is that you should not feel constrained by someone else's opinion of what SCRUM is - if it works for you and your team then that is good enough so feel free to experiment!


问:
How to diagram custom programming languages, non textual?
I've used and created domain-specific languages before, plenty of times (e.g. using yacc/lex). Normally we'd start with grammar written in BNF, and a bunch of keywords. This is easy to do, easy to share.

Recently, I've started working with diagrammatic programming languages - closest parallel is circuit-diagrams in electronics, where it's very difficult to express ideas in text, but very easy to express them in wiring-diagrams.

This is a new and novel problem for me: how to efficiently express these mini-languages, and share concepts in them with colleagues?

(i.e. how to whiteboard-program within them. Actual programming is easy - you have physical components to hand)

Are there tools for this? Or good/best practices (e.g. equivalent of "always use BNF as starting point for your new DSL, and use tools like yacc to generate the parser, compiler, etc"). My googlefu is proving weak - all I get is false positives for wiring diagrams, and UML editors (since these are custom languages, UML doesn't seem to help)

答:
There are tools available that will allow you to represent your DSL graphically and then use the graphic representation to "program" the DSL. These are called "DSL Workbenches"

Right now the only DSL workbench that I can think of that is specifically targetting Graphic DSLs is Microsoft's DSL Tools. There might be others out there, but that's the only one that has hit my radar.


答:
Not sure, if is what you are looking for, but, aA visual way to express a programming language are "Syntax diagrams", also known as "RailRoad diagrams"

http://en.wikipedia.org/wiki/Syntax_diagram

Good Luck

Title: How to diagram custom programming languages, non textual?

Body:
I've used and created domain-specific languages before, plenty of times (e.g. using yacc/lex). Normally we'd start with grammar written in BNF, and a bunch of keywords. This is easy to do, easy to share.

Recently, I've started working with diagrammatic programming languages - closest parallel is circuit-diagrams in electronics, where it's very difficult to express ideas in text, but very easy to express them in wiring-diagrams.

This is a new and novel problem for me: how to efficiently express these mini-languages, and share concepts in them with colleagues?

(i.e. how to whiteboard-program within them. Actual programming is easy - you have physical components to hand)

Are there tools for this? Or good/best practices (e.g. equivalent of "always use BNF as starting point for your new DSL, and use tools like yacc to generate the parser, compiler, etc"). My googlefu is proving weak - all I get is false positives for wiring diagrams, and UML editors (since these are custom languages, UML doesn't seem to help)


问:
"Collection Wrapper" pattern - is this common?
A different question of mine had to do with encapsulating member data structures inside classes. In order to understand this question better please read that question and look at the approach discussed.

One of the guys who answered that question said that the approach is good, but if I understood him correctly - he said that there should be a class existing just for the purpose of wrapping the collection, instead of an ordinary class offering a number of public methods just to access the member collection.

For example, instead of this:

```<code>class SomeClass{

    // downright exposing the concrete collection.

    Things[] someCollection;

   // other stuff omitted

    Thing[] getCollection(){return someCollection;}

}
</code>```

Or this:

```<code>class SomeClass{

    // encapsulating the collection, but inflating the class' public interface.

    Thing[] someCollection;

    // class functionality omitted.

    public Thing getThing(int index){
        return someCollection[index];
    }

    public int getSize(){
        return someCollection.length;
    }

    public void setThing(int index, Thing thing){
        someCollection[index] = thing;
    }

    public void removeThing(int index){
        someCollection[index] = null;
    }

}
</code>```

We'll have this:

```<code>// encapsulating the collection - in a different class, dedicated to this.

class SomeClass{
    CollectionWrapper someCollection;

    CollectionWrapper  getCollection(){return someCollection;}
}

class CollectionWrapper{

    Thing[] someCollection;

    public Thing getThing(int index){
        return someCollection[index];
    }

    public int getSize(){
        return someCollection.length;
    }

    public void setThing(int index, Thing thing){
        someCollection[index] = thing;
    }

    public void removeThing(int index){
        someCollection[index] = null;
    }

}
</code>```

This way, the inner data structure in SomeClass can change without affecting client code, and without forcing SomeClass to offer a lot of public methods just to access the inner collection. CollectionWrapper does this instead.

E.g. if the collection changes from an array to a List, the internal implementation of CollectionWrapper changes, but client code stays the same.

Also, the CollectionWrapper can hide certain things from the client code - from example, it can disallow mutation to the collection by not having the methods setThing and removeThing.

This approach to decoupling client code from the concrete data structure seems IMHO pretty good.

Is this approach common? What are it's downfalls? Is this used in practice?

答:
I think you are right.

I have developed several custom collections in diferent programming languages, and, sometimes, I applied the pattern. I also check that other developers also applied.

It seems that it depends on what the developer wants to achieve, sometimes, the collection is access directly, sometimes, using the pattern.

Visual controls with several items like "Treeview", "Listview", "Gridview" use a lot of this technique.


答:
I am not aware of any tools that are generic enough for your purposes but perhaps I can help with your Google-Fu...

If you are not familiar with the concept of Dataflow programming languages the wikipedia article is a great place to start - it should at least help make your google-searches a little more targeted to more appropriate content.

I would also recommend that you check out some of the graphical programming languages described there, especially LabView/G. My thought here is that the symbolic languages used in such tools can be easily mimicked in tools like Visio. I am someone who uses pictures and diagrams a lot to communicate with my technical peers and over time I have come to adopt a kind of visual short-hand that looks a lot like LabView's programming language - especially when I am trying to communicate something in the realm of parallelism or multi-threading. I have a set of VISIO template shapes that I use for this purpose... it was a little spendy in terms of VISIO shape authoring learning curve but I think it was worth it.


问:
Android design advice - services & broadcast receivers
I'm in the process of learning the Android SDK and creating some projects to get a grasp on the system.  The current project I'm working with works just fine but I'd like to get some advice about other ways I can go about designing it.

Here's what it needs to do.
When a text message is received from a specific number, it should fire off a toast message that repeats at a certain interval for a specific duration.

To make this work, I created an SMS BroadcastReceiver and checked the incoming messages for the number I'm looking for.

If found, an IntentService would be started that would pull out the interval and duration from saved shared prefs.  The IntentService would then fire off a broadcast.

The BroadcastReceiver for this would catch it and use the AlarmManager to handle the toast message repetitions.

This all works just fine, but I'm wondering if there's a cleaner or more efficient way of going about doing this?
Any suggestions or advice?

答:
I think that your first 2 pieces are correct. While you could combine steps 1 & 2 into a single step by doing everything in the broadcast receiver - but you don't want to do that. The biggest difference between a BroadcastReceiver and an IntentService is that Broadcast Receiver's run on the main thread. This means that you want to spend as little time in them as you can. That makes it a pretty good idea to follow the pattern of receiving a message in the receiver and then dispatching a message to an IntentService where work can be done off of the main thread.

Where I would change my approach to your problem is steps 2-3... I would do the work of setting up the first (or next) alarm in the IntentService or not, depending on your business logic (i.e. user disabled the alarm some how). I would then use Handler.PostDelayed to start the same IntentService - again - at some point in the future.

Also - using toasts is one option - but I would also consider using a notification in addition to the toast (or maybe instead of)... that would provide a convenient means of allowing the user to respond to the alarm condition.


答:
You are implementing a restricted set of the Collection interface, without actually giving it something that you can work with.

E.g. if the collection changes from an array to a List, the internal
  implementation of CollectionWrapper changes, but client code stays the same.

This is exactly what the Collection interface is intended to do.  If you pass back a Collection, that is all the client can work from.

Also, the CollectionWrapper can hide certain things from the client code - from example, it can disallow mutation to the collection by not having the methods setThing and removeThing.

In Java, this is known as an Unmodifiable Collection, and the Collections utility has just such a method to convert a modifiable collection to an unmodifiable one.

By making the restricted wrapper you are also giving up things such as sort and iterator which come in very handy from time to time.  This means code such as:

```<code>for(Thing t : someCollection) {
    ....
}
</code>```

won't work.  Instead, the code would need to be:

```<code>for(int i = 0; i < someCollection.size(); i++) {
    Thing t = someCollection.get(i);
    ....
}
</code>```

While that is perfectly acceptable code, it also means you are failing to take advantage of the language to allow the client to write code faster (programmer time is expensive).

The way you decouple the implementation is to use an interface, preferably one that already exists in the language framework so that other things that use that same interface can use your code without jumping through additional hoops.

Just a note:

What I'm trying to do, is not expose the collection - because I don't want the client code to break when the collection changes say from a List to a Set. If I just allow the client code to do class.getCollection() it'll break when the type of the collection changes. So the idea is to make a thin layer around it ("CollectionWrapper"), so when the type of collection changes, only the wrapper has to change, but not the code using the collection (i.e. using the wrapper). Is what I'm saying clear?

If the collection is only given as a Collection interface, it won't break.  However, I must point out that the public methods that you are presenting with this class, namely public Thing getThing(int index), public void setThing(int index, Thing thing), and public void removeThing(int index) would preclude the implementation from changing from a List to a Set, because Sets have no concept of indexes and these methods would need to change.

Title: "Collection Wrapper" pattern - is this common?

Body:
A different question of mine had to do with encapsulating member data structures inside classes. In order to understand this question better please read that question and look at the approach discussed.

One of the guys who answered that question said that the approach is good, but if I understood him correctly - he said that there should be a class existing just for the purpose of wrapping the collection, instead of an ordinary class offering a number of public methods just to access the member collection.

For example, instead of this:

```<code>class SomeClass{

    // downright exposing the concrete collection.

    Things[] someCollection;

   // other stuff omitted

    Thing[] getCollection(){return someCollection;}

}
</code>```

Or this:

```<code>class SomeClass{

    // encapsulating the collection, but inflating the class' public interface.

    Thing[] someCollection;

    // class functionality omitted.

    public Thing getThing(int index){
        return someCollection[index];
    }

    public int getSize(){
        return someCollection.length;
    }

    public void setThing(int index, Thing thing){
        someCollection[index] = thing;
    }

    public void removeThing(int index){
        someCollection[index] = null;
    }

}
</code>```

We'll have this:

```<code>// encapsulating the collection - in a different class, dedicated to this.

class SomeClass{
    CollectionWrapper someCollection;

    CollectionWrapper  getCollection(){return someCollection;}
}

class CollectionWrapper{

    Thing[] someCollection;

    public Thing getThing(int index){
        return someCollection[index];
    }

    public int getSize(){
        return someCollection.length;
    }

    public void setThing(int index, Thing thing){
        someCollection[index] = thing;
    }

    public void removeThing(int index){
        someCollection[index] = null;
    }

}
</code>```

This way, the inner data structure in SomeClass can change without affecting client code, and without forcing SomeClass to offer a lot of public methods just to access the inner collection. CollectionWrapper does this instead.

E.g. if the collection changes from an array to a List, the internal implementation of CollectionWrapper changes, but client code stays the same.

Also, the CollectionWrapper can hide certain things from the client code - from example, it can disallow mutation to the collection by not having the methods setThing and removeThing.

This approach to decoupling client code from the concrete data structure seems IMHO pretty good.

Is this approach common? What are it's downfalls? Is this used in practice?

Body:
You are implementing a restricted set of the Collection interface, without actually giving it something that you can work with.

E.g. if the collection changes from an array to a List, the internal
  implementation of CollectionWrapper changes, but client code stays the same.

This is exactly what the Collection interface is intended to do.  If you pass back a Collection, that is all the client can work from.

Also, the CollectionWrapper can hide certain things from the client code - from example, it can disallow mutation to the collection by not having the methods setThing and removeThing.

In Java, this is known as an Unmodifiable Collection, and the Collections utility has just such a method to convert a modifiable collection to an unmodifiable one.

By making the restricted wrapper you are also giving up things such as sort and iterator which come in very handy from time to time.  This means code such as:

for(Thing t : someCollection) {
    ....
}

won't work.  Instead, the code would need to be:

for(int i = 0; i < someCollection.size(); i++) {
    Thing t = someCollection.get(i);
    ....
}

While that is perfectly acceptable code, it also means you are failing to take advantage of the language to allow the client to write code faster (programmer time is expensive).

The way you decouple the implementation is to use an interface, preferably one that already exists in the language framework so that other things that use that same interface can use your code without jumping through additional hoops.

Just a note:

What I'm trying to do, is not expose the collection - because I don't want the client code to break when the collection changes say from a List to a Set. If I just allow the client code to do class.getCollection() it'll break when the type of the collection changes. So the idea is to make a thin layer around it ("CollectionWrapper"), so when the type of collection changes, only the wrapper has to change, but not the code using the collection (i.e. using the wrapper). Is what I'm saying clear?

If the collection is only given as a Collection interface, it won't break.  However, I must point out that the public methods that you are presenting with this class, namely public Thing getThing(int index), public void setThing(int index, Thing thing), and public void removeThing(int index) would preclude the implementation from changing from a List to a Set, because Sets have no concept of indexes and these methods would need to change.


答:
The c_str function returns a pointer to the string's contents, ensuring that the data is followed by a NUL (zero) character.

```<code>┌─────────────data─────────────┐ end
48 65 6C 6C 6F 20 77 6F 72 6C 64 00
H  e  l  l  o  ␠   w  o  r  l  d  ␀
</code>```

However, the string's data itself may contain a NUL character.  (This is possible because std::string has to store its length explicitly instead of depending on null termination.)  When this happens, strlen(str.c_str()) will return a smaller value than str.length().

```<code>┌─────────────data─────────────┐ end
48 65 6C 6C 6F 00 77 6F 72 6C 64 00
H  e  l  l  o  ␀   w  o  r  l  d  ␀
└────────────┘
 string seen by strlen() etc.
</code>```

The above is the equivalent of doing strlen("Hello\0world") in C.  The string as seen by the C function is a left-substring of the original string.

Sometimes this causes data loss or even a security risk, but what else could c_str() do in this situation?

Title: "bug" in C++11 text by Stroustrup?

Body:
I found an apparent contradiction in the c++ text having to do with the result of the c_str() function operating on std:strings (in my copy, the definition and contradiction are on p1040).

First it defines the c_str() function as something that produces a 'C-style' (zero-terminated) string, but later it talks about how a C++ c_str value can have embed a 'C'-style, end-of-string terminators (i.e. NUL's) embedded in the string (that is defined by being NUL terminated).

Um... does anyone else feel that this is a 'stretching' of the definition of a C-string beyond it's definition?  I.e. I think what it means, is that if you were to look at the length() function as applied to the string, it will show a different end of string than using the C-definition of a z-string -- one that can contain any character except NUL, and is terminated by NUL.

I likely don't have to worry about it in my of my programs, but it seems like a subtle distinction that makes a C++ c_str, not really a 'C'-string.  Am I misunderstanding this issue?

Thanks!

Body:
The c_str function returns a pointer to the string's contents, ensuring that the data is followed by a NUL (zero) character.

┌─────────────data─────────────┐ end
48 65 6C 6C 6F 20 77 6F 72 6C 64 00
H  e  l  l  o  ␠   w  o  r  l  d  ␀

However, the string's data itself may contain a NUL character.  (This is possible because std::string has to store its length explicitly instead of depending on null termination.)  When this happens, strlen(str.c_str()) will return a smaller value than str.length().

┌─────────────data─────────────┐ end
48 65 6C 6C 6F 00 77 6F 72 6C 64 00
H  e  l  l  o  ␀   w  o  r  l  d  ␀
└────────────┘
 string seen by strlen() etc.

The above is the equivalent of doing strlen("Hello\0world") in C.  The string as seen by the C function is a left-substring of the original string.

Sometimes this causes data loss or even a security risk, but what else could c_str() do in this situation?