问:
Strategy for Public / Private API, Encrypted (or Hashed) Data, and Server Compromise
In this very simplistic but realistic scenario, I have 2 combo web/database servers (A) behind a load balancer and a single IP address. They also permit access only from one IP address -- the client (B). On each database server, we need to store read-only secret identity information (like email address, username, etc.).

I need a solution that prevents a hacker who may have compromised server (A) from being able to do anything with the data unless they also gain access to server (B).

I need a strategy where client server (B) uses a public key from a private/public API key pair to find a match for this identity information (like an email address) on server (A), and then, without server (A) evaluating that result, return the result back to (B) for evaluation using its private key. The theory being that if the hacker gets root level access to server (A), they can't do anything with it to decode the data, not even with brute-force attacks on md5(), sha1(), sha256(), or against any hashing algorithm.

Here's a strategy that won't work, as an example. Imagine you have PHP's libsodium (a common public/private key system). You use it to encrypt the data and store it on (A). Then, when (B) wants to do a lookup, they send in the public key, it gets mated with the private key on (A), a hash is generated, and that hash is checked against a hash in the database. (So, you find if hashed email request matches a hashed email address in the database.) The problem with this strategy is that if server (A) is compromised for root-level access, all the attacker has to do is intercept the web traffic to find the public key from (B), combine it with the private key from (A) in the PHP server scripts, and then use that information to run a powerful brute-force script to break the hash so that the entire database can be decrypted. This brute-force attack has been used to break md5() and sha1(), but can be used to break even someone's sha256 or other hash API.

Right, so that won't work. It would be better if there was some way that the result of the match can't be interpreted on server (A) and must be sent back to server (B) for final evaluation, which then requires server (B)'s private key to decrypt the result.

Using PHP, can you explain a programmer API key strategy where a compromised data store will yield no useful information to a hacker unless he has the private key of that programmer's public/private key pair?

答:
As I mentioned in a comment, I'd do all the encrypting/decrypting on (B) and let (A) do nothing but store the data.

As an example:

This happens on (B)

```<code>string encryptedKey = encrypt('John Smith');
string encryptedData = encrypt('121 Main Street');
</code>```

(B) sends the 2 encrypted strings to (A).

(A) stores the 2 encrypted strings in a key/value database.

Later, (B) can request the data by sending a message to (A) send me the value associated with the key "xxx" where xxx is the output of the encrypt('John Smith') call.

(A) has no knowledge of encryption at all.  (A) also does not know what is being stored - just an "opaque string" for the key, and another "opaque string" for the value.

(B) can use symmetric encryption if desired - it doesn't matter.

Body:
As I mentioned in a comment, I'd do all the encrypting/decrypting on (B) and let (A) do nothing but store the data.

As an example:

This happens on (B)

string encryptedKey = encrypt('John Smith');
string encryptedData = encrypt('121 Main Street');

(B) sends the 2 encrypted strings to (A).

(A) stores the 2 encrypted strings in a key/value database.

Later, (B) can request the data by sending a message to (A) send me the value associated with the key "xxx" where xxx is the output of the encrypt('John Smith') call.

(A) has no knowledge of encryption at all.  (A) also does not know what is being stored - just an "opaque string" for the key, and another "opaque string" for the value.

(B) can use symmetric encryption if desired - it doesn't matter.


问:
JIT based on precompiled code templates
This is a crazy idea that I just came up with, and I'm interested in knowing if it would be workable, or if someone already wrote about or implemented it.

Imagine you are on a platform (a game console, iOS, ...) where you cannot implement a JIT compiler due to technical reasons1 - you cannot make writable memory executable. You can write an interpreter, but you'd like to make it faster. Now, memory is fairly cheap and code is relatively small compared to other assets, so you can always add more pre-compiled code.

What if you just add lots of (ahead-of-time) compiled code pieces to your binary - one for every sequence of instructions you're likely to need? You can make the pieces configurable by passing arguments in through registers or memory. One trivial example is replacing a simple loop (pseudocode)

```<code>for i in range(100000):
    array[i] = 0;
</code>```

with memset(&array, 0, 100000). But you can do a lot better. Compile some typical programs, take the 1000 top N-grams of instructions, and put them in your binary. Now string them together - either using computed jumps (I don't know if they would be available in a typical locked-down system) - or by wrapping the larger ones in functions, or by using some return-based-programming trickery.

There are a few trade-offs here:

One is that there is much overhead since you have to compile in a lot more code than you actually will use. However, it might be that performance-critical code (for a given platform and use case) has a lot of common pieces. Think graphics code for example.

Another one is that, while executing the compiled code bits is faster than interpreting them, you have some overhead due to jumping around between the code bits. I also have a hunch that the lack of cache locality between far-apart code pieces might be bad. Both these should be especially true on modern processors.

So, I'm wondering if someone smarter than me already thought about this, and can tell me about these trade-offs, and how well this would work in reality.

1) Note I'm not asking about the legal aspects, which is beyond the scope of the site anyway. Someone might forbid you from writing a JIT compiler, and then you invent something that is technically not a JIT, but the same thing in spirit, and you've just created a lot of work for lawyers. This question is about technical aspects - say you want something JIT-like on a Havard architecture computer.

答:
Congratulations, you invented the DLL.

Edit: Yes, that was a bit brief. A comment would have done. So let me elaborate. A little.

Using pre-compiled code to make compilation of your application faster, particularly targeting parts that are executed often, that is what a dynamic link library offers. It also allows sharing compiled code among different applications. The code in it can be addressed from both compiled languages and interpreted languages. That is the case for the Microsoft Windows world, I do not know about other environments.

DLL's where common in the Win32 era. Most if the Windows operating system is implemented as DLL's. The concept remains in the .net world, the extension of the files is still DLL, although we prefere to call them assemblies there.

So my point is that it is a great idea (although it took Microsoft a while to iron out the versioning issues, commonly known as "DLL hell"), but you are not the first one who came up with it.

ContentLicense: CC BY-SA 3.0

Title: JIT based on precompiled code templates


问:
How to unit test a constant that defines an implementation detail?
How do I unit test a constant that defines an implementation detail?

And should I?

For instance, let's say I have the following class:

class A
{
   private Cache _cache;
   const int timeToLiveInCache = 30; // 30 seconds of TTL

   A()
   {
      _cache = new Cache(timeToLiveInCache);
   }
}
```

In my unit test, how can I test that my TTL is indeed 30 seconds?

The Cache class has been tested and I know that whatever TTL I input will work as intended, but I want a unit test to make sure that the class A actually uses a TTL of 30 seconds. Is it even a good idea to unit test that?

答:
The unit tests need access to this constant, in order to verify that cache entries aren't removed before their time to live has expired. The actual value given is irrelevant, I'd think.

Therefore: make this constant public and document it. After all, the time to live is not a secret but results in externally observable consequences. If you like, you can also note that the specific value of this constant is unspecified and subject to change. This avoids duplicating the constant value in your code and in your tests. If you had duplicated such information, your tests would be more fragile.

Bad test:

mockTime = 0;
cache.put(value);
assert cache.contains(value);

mockTime += 30;

assert !cache.contains(value);
```

<p>Better test:</p>

<pre class="lang-cs prettyprint-override"><code>mockTime = 0;
cache.put(value);
assert cache.contains(value);

mockTime += cache.TIME_TO_LIVE;

assert !cache.contains(value);
</code>```

ContentLicense: CC BY-SA 4.0

Body:
The unit tests need access to this constant, in order to verify that cache entries aren't removed before their time to live has expired. The actual value given is irrelevant, I'd think.

Therefore: make this constant public and document it. After all, the time to live is not a secret but results in externally observable consequences. If you like, you can also note that the specific value of this constant is unspecified and subject to change. This avoids duplicating the constant value in your code and in your tests. If you had duplicated such information, your tests would be more fragile.

Bad test:

mockTime = 0;
cache.put(value);
assert cache.contains(value);

mockTime += 30;

assert !cache.contains(value);

Better test:

mockTime = 0;
cache.put(value);
assert cache.contains(value);

mockTime += cache.TIME_TO_LIVE;

assert !cache.contains(value);


问:
Does this class design violate the single responsibility principle?
Today I had an argument with someone.

I was explaining the benefits of having a rich domain model as opposed to an anemic domain model. And I demoed my point with a simple class looking like that:

```<code>public class Employee
{
    public Employee(string firstName, string lastName)
    {
        FirstName = firstName;
        LastName = lastname;
    }

    public string FirstName { get private set; }
    public string LastName { get; private set;}
    public int CountPaidDaysOffGranted { get; private set;}

    public void AddPaidDaysOffGranted(int numberOfdays)
    {
        // Do stuff
    }
}
</code>```

As he defended his anemic model approach, one of his arguments was: "I am a believer in SOLID. You are violating the single responsibility principle (SRP) as you are both representing data and performing logic in the same class."

I found this claim really surprising, as following this reasoning, any class having one property and one method violates the SRP, and therefore OOP in general is not SOLID, and functional programming is the only way to heaven.

I decided not to reply to his many arguments, but I am curious what the community thinks on this question.

If I had replied, I would have started by pointing to the paradox mentioned above, and then indicate that the SRP is highly dependent on the level of granularity you want to consider and that if you take it far enough, any class containing more than one property or one method violates it.

What would you have said?

Update: The example has been generously updated by guntbert to make the method more realistic and help us focus on the underlying discussion.

答:
On the contrary, for me Anemic domain model breaks some OOP main concepts (which tie together attributes and behavior), but can be inevitable based on architectural choices. Anemic domains are easier to think, less organic and more sequential.

Many systems tend to do this when multiple layers must play with the same data (service layer, web layer, client layer, agents...).

It is easier to define the data structure in one place and the behavior in other service classes. If the same class was used on multiple layers, this one may grow big, and it asks the question of which layer is responsible to define the behavior it needs, and who is able to call the methods.

For example, it may not be a good idea than an Agent process which computes statistics on all your employees can call a compute for paid days. And the employee list GUI certainly not need at all the new aggregated id computation used in this statistic agent (and the technical data coming with it). When you segregate the methods this way, you generally end with a class with only data structures.

You can too easily serialize / deserialize the "object" data, or just some of them, or to another format (json)... without worrying about any object concept / responsibility. It is just data passing though.
You can always do data mapping between two classes (Employee, EmployeeVO, EmployeeStatistic…) but what does Employee really mean here?

So yes it separates completely data in domain classes and data handling in service classes but it is here needed. Such system is at the same time a functional one to bring business value and a technical one too to propagate the data everywhere it is needed while keeping a proper responsibility scope (and distributed object does not solve this either).

If you don’t need to separate behavior scopes you are more free to put the methods in service classes or in domain classes, depending on how you see your object. I tend to see an object as the "real" concept, this naturally help to keep SRP. So in you example, it is more realist than the Employee's Boss add payday off granted to his PayDayAccount. An Employee is Hired by company, Works, can be Sick or be Asked for an advice, and he has a Payday account (the Boss may retrieve it directly from him or from a PayDayAccount registry...) But you can make an aggregated shortcut here for simplicity if you don't want too much complexity for a simple software.


答:
Try working at a higher level -- what use case that the business cares about will fail if TTL isn't 30 seconds?

More generally:

Don't write unit tests for things that can't fail; it annoys the pig.

Writing tests that verify a specific implementation is usually a bad idea.  When you later come up with a better way to implement what you need, all of those tests are going to get thrown away (or not -- maybe somebody is going to have to go through them to try to figure out if there is any business value left hiding in them -- more waste!).

Which isn't to say that it isn't nice to have some block and tackle when you are down in the trenches trying to get something working the first time.  For instance, when you are doing a spike of some functionality, tests that are specific to the implementation can be a comfort, as they more quickly help you identify what has gone wrong, rather than simply what requirement has been missed.

For instance, you wouldn't write a test to verify getRandomNumber() That's just deranged.  Instead, you write tests that ensure that any implementation that passes the tests are acceptable to the business.

Consider sort, for example.  Unless what you are actually shipping is the World's Best Web-Scale Bubble Sort, you don't care about the implementation details under the hood.  What you care about is whether or not a bunch of pathological use cases produce acceptable results.  You care about whether certain pathological data cases cause your comparator to become unstable, and so on.

That said, certain kinds of things are a real pain to test.  Caches would be one of them; a cache is basically a memory/computation tradeoff, usually made to improve an SLA, rather than to provide additional correctness guarantees.  So a durable unit test for this might look like

```<code>given(User.hasBeenIdleFor(MINUTES(29)))
.when(User.loadsPage())
.expect(Probability(Page.loadsWithin(MILLISECONDS(1)))>Probability.NINES(3));
</code>```

and then you try to figure out how to implement that test to satisfy

```<code>Probability.testExecutesWithin(SECONDS(1)) > Probability.NINES(2);
</code>```

Whee - fun times.

Title: How to unit test a constant that defines an implementation detail?

Body:
How do I unit test a constant that defines an implementation detail?

And should I?

For instance, let's say I have the following class:

class A
{
   private Cache _cache;
   const int timeToLiveInCache = 30; // 30 seconds of TTL

   A()
   {
      _cache = new Cache(timeToLiveInCache);
   }
}
```

In my unit test, how can I test that my TTL is indeed 30 seconds?

The Cache class has been tested and I know that whatever TTL I input will work as intended, but I want a unit test to make sure that the class A actually uses a TTL of 30 seconds. Is it even a good idea to unit test that?

Body:
Try working at a higher level -- what use case that the business cares about will fail if TTL isn't 30 seconds?

More generally:

Don't write unit tests for things that can't fail; it annoys the pig.

Writing tests that verify a specific implementation is usually a bad idea.  When you later come up with a better way to implement what you need, all of those tests are going to get thrown away (or not -- maybe somebody is going to have to go through them to try to figure out if there is any business value left hiding in them -- more waste!).

Which isn't to say that it isn't nice to have some block and tackle when you are down in the trenches trying to get something working the first time.  For instance, when you are doing a spike of some functionality, tests that are specific to the implementation can be a comfort, as they more quickly help you identify what has gone wrong, rather than simply what requirement has been missed.

For instance, you wouldn't write a test to verify getRandomNumber() That's just deranged.  Instead, you write tests that ensure that any implementation that passes the tests are acceptable to the business.

Consider sort, for example.  Unless what you are actually shipping is the World's Best Web-Scale Bubble Sort, you don't care about the implementation details under the hood.  What you care about is whether or not a bunch of pathological use cases produce acceptable results.  You care about whether certain pathological data cases cause your comparator to become unstable, and so on.

That said, certain kinds of things are a real pain to test.  Caches would be one of them; a cache is basically a memory/computation tradeoff, usually made to improve an SLA, rather than to provide additional correctness guarantees.  So a durable unit test for this might look like

given(User.hasBeenIdleFor(MINUTES(29)))
.when(User.loadsPage())
.expect(Probability(Page.loadsWithin(MILLISECONDS(1)))>Probability.NINES(3));

and then you try to figure out how to implement that test to satisfy

Probability.testExecutesWithin(SECONDS(1)) > Probability.NINES(2);

Whee - fun times.


问:
Why is it good programming practice to limit scope?
I'm relatively new to programming (July 2015), and I've always wondered why it's good programming practice to hide variables as much as possible.

I've run into this question mainly recently when I looked into events and delegates in C#. I searched around as to why I should use events rather than just a delegate, since they do the same thing it seems.
I read that it's better programming practice to hide the delegate fields and use an event.

I decided it was time to learn why it was good programming practice, but I couldn't really find anything other than "Because it's good programming practice".

If you could provide some basic examples and maybe some pseudo-code that would be helpful.

答:
Because the more things you have to deal with in any task the harder it becomes.

For example, try patting your head. Then try patting your head and counting backwards from 1000. Then try patting your head counting backwards from 1000 and hopping on one leg. Then try patting your head counting backwards from 1000 and hopping on one leg and singing the national anthem. Gets a lot harder doesn't it?

Each of those tasks were simple and would be easy on their own. If you keep your code small and granular and limit the amount of variables in scope you're dealing with less things at a time. This means you're less likely to fall over while standing on one leg because you were distracted by singing the national anthem and counting backwards from 1000.


答:
The simpler your application is, the less likely it will be to break.

Adding complexity means adding places where errors can occur. Usually those errors will be in your code, but occasionally you can hit errors from either the compiler or operating system.

An Example

You build a calculator object. It can do all sorts of calculator things (i.e., add numbers, multiply numbers, even determine square roots). You wouldn't need or want to add a method that draws lines on an image. You also wouldn't need or want a method that asks StackExchange for the person with the most reputation on all of its sites.

Title: Why is it good programming practice to limit scope?

Body:
I'm relatively new to programming (July 2015), and I've always wondered why it's good programming practice to hide variables as much as possible.

I've run into this question mainly recently when I looked into events and delegates in C#. I searched around as to why I should use events rather than just a delegate, since they do the same thing it seems.
I read that it's better programming practice to hide the delegate fields and use an event.

I decided it was time to learn why it was good programming practice, but I couldn't really find anything other than "Because it's good programming practice".

If you could provide some basic examples and maybe some pseudo-code that would be helpful.


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

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

答:
While not quite the same thing, this is sort of why HTML turned into the disaster it is. Browsers tolerated bad markup and next thing you knew, browser A couldn't render the same way Browser B did (yes there's other reasons, but this was one of the top few, esp around 10 years ago before some of the looseness rules became convention).

As Eric Lippert infers, many of these things are best handled by the IDE, not the compiler. That let's you see what the automatic bits are attempting to screw up for you.

The strategy I think that is predominant now is continual language refinement instead of loosening up the compiler: If it truly is something that the compiler can figure out automatically, then introduce a well defined language construct around it.

The immediate example that comes to mind is auto-properties in C# (not the only language that has something similar): Given that the majority of getters/setters in any app are really just wrappers around a field, just allow the developer to indicate their intent and let the compiler inject the rest.

Which then gets me to thinking: Most C style languages already do this to some extent. For things that can be figured out automatically, just refine the syntax:

```<code> if (true == x)
 {
    dothis();
 }
 else
 {
    dothat();
 }
</code>```

Can be reduced to:

```<code>if (true == x)
    dothis();
else
    dothat();
</code>```

In the end, I think it comes down to this: The trend is that you don't make the compiler "smarter" or "looser". It's the language that is made smarter or looser.

Besides, too much "help" can be dangerous, such as the classic "if" bug:

```<code>if (true == x)
    if (true == y)
       dothis();
else
    dothat();
</code>```

ContentLicense: CC BY-SA 2.5

Body:
While not quite the same thing, this is sort of why HTML turned into the disaster it is. Browsers tolerated bad markup and next thing you knew, browser A couldn't render the same way Browser B did (yes there's other reasons, but this was one of the top few, esp around 10 years ago before some of the looseness rules became convention).

As Eric Lippert infers, many of these things are best handled by the IDE, not the compiler. That let's you see what the automatic bits are attempting to screw up for you.

The strategy I think that is predominant now is continual language refinement instead of loosening up the compiler: If it truly is something that the compiler can figure out automatically, then introduce a well defined language construct around it.

The immediate example that comes to mind is auto-properties in C# (not the only language that has something similar): Given that the majority of getters/setters in any app are really just wrappers around a field, just allow the developer to indicate their intent and let the compiler inject the rest.

Which then gets me to thinking: Most C style languages already do this to some extent. For things that can be figured out automatically, just refine the syntax:

 if (true == x)
 {
    dothis();
 }
 else
 {
    dothat();
 }

Can be reduced to:

if (true == x)
    dothis();
else
    dothat();

In the end, I think it comes down to this: The trend is that you don't make the compiler "smarter" or "looser". It's the language that is made smarter or looser.

Besides, too much "help" can be dangerous, such as the classic "if" bug:

if (true == x)
    if (true == y)
       dothis();
else
    dothat();


问:
What is the difference between ADTs and objects?
This question was answered in "Understanding Abstract Data Types (ADTs)", and the top voted answerer (by Frank Shearar) is currently as follows:

Objects are not ADTs (*) [editor's note: Links to "On  Understanding  Data  Abstraction,  Revisited" - Cook]. (So in C# String and Int32 are not
  ADTs.)

With that out of the way, an abstract data type "has a public name, a
  hidden representation, and operations to create, combine and observe
  values of the abstraction". (Quoting from the linked paper.)

(*) Briefly, Cook explains that:

Objects cannot inspect the hidden representation of other objects,    unlike members of an ADT. That implies that values of an ADT may be

  implemented efficiently, even for operations that require inspection

  of multiple abstract values.

Objects behave like a characteristic function over the values of a type, rather than as an algebra. Objects use procedural abstraction
  rather than type abstraction

ADTs usually have a unique implementation in a program. When one's language has modules, it's possible to have multiple implementations
  of an ADT, but they can't usually interoperate.

My problem is with the second bullet point.I think that in the paper linked, it just happens to be the case that for the specific example of a set used in Cook's paper, an object can be viewed as a characteristic function. I don't think that objects, in general can be viewed as characteristic functions.

Also, in the paper Aldritch (The power of interoperability: Why objects are inevitable) suggests

Cook’s definition essentially identifies dynamic dispatch as the most
  important characteristic of object

agreeing with this and with Alan Kay when he said

OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.

However, in these set of lecture slides it suggests that Java classes are ADTs while Java interfaces are objects - and indeed using interfaces "objects" can inter-operate (one of the key features of OOP as given in one of the bullet points above).

My questions are

Am I correct to say that characteristic functions are not a key feature of objects and that Frank Shearar is mistaken

Are data that talk to each other through Java interfaces examples of objects even though they don't use dynamic dispatch? Why? (my understanding is that dynamic dispatch is more flexible, and that interfaces are a step towards objective-C/smalltalk/erlang style messaging)

Is the idea of dependency inversion principle related to the distinction between ADTs and objects? (see the wikipedia page or google "The Talking Objects: A Tale About Message-Oriented Programming". Although I'm new to the concept, I understand that it involves adding interfaces between "layers" of a program (see wikipedia page diagram)

Please provide any other examples/clarifications of the distinction between objects and ADTs, if you want.

答:
No. Objects are well known today to involve a mix of data and functions. Removing the functions means you don't have an object any more.

Yes. Interfaces still use dynamic dispatch to call the right function depending on the runtime type of the object that satisfies the interface. You are right that dynamic dispatch is often used to mean multiple dispatch, where more than just the this parameter can cause dispatch, but the limited dispatch is still enough for objects.

Not particularly. I mean, since ADTs are just data, there's no dependencies to invert. You could look at function objects over ADTs as a sort of dependency inversion, but the ADT doesn't own them.

Write more code. ADTs have a number of traits that most objects do not. Hell, even most objects do not have the traits of objects. The difference is often in the capabilities of the things. And a lot of those traits become clear once you start using each and understanding how their different capabilities limit your program design and implementation.


问:
Should I always store parsed data in database before manipulating?
I am about to start a new project which involves taking an excel file, parsing the data (php-excel-reader) and then using the parsed values in a HTML email.

My question is pretty simple. Is it better practice to store the parsed data in a database first and then use the data however I wish?

For me it makes more sense as then I don't need to re-parse if errors occur when sending the email for example.

答:
Depends on the business model.
Let us say it like this.

If the processed excel file should generate a different result to the previous one,  I would say store and according the request the model process the output different previous according the uri.

But if the data is running on the same data the same routine (request), with the service resultset, process it and then store it in the DB.


答:
I think parsing the file and storing the data to a database would be a good idea.

It provides a transactional history so you can retry failed messages, audit records sent, and provide reporting.

That said, if you have no requirements to support any of those functions and no possibility of having them in the future, writing to a database would just be unnecessary overhead.

Title: Should I always store parsed data in database before manipulating?

Body:
I am about to start a new project which involves taking an excel file, parsing the data (php-excel-reader) and then using the parsed values in a HTML email.

My question is pretty simple. Is it better practice to store the parsed data in a database first and then use the data however I wish?

For me it makes more sense as then I don't need to re-parse if errors occur when sending the email for example.


问:
Methods of debugging code (Nightmare situation)
I am frequently tasked with debugging an application at my job. It is a BI Application that we deploy to businesses, which includes a test environment, and a production environment. I am wondering if there are any apps/tools/methods that people can suggest, based on these constraints:

Debugger cannot be used on client site or locally, because the software depends on custom third party applications that we don't have test environments for. (EDIT: to be fair, it is possible to debug locally in some cases. If we use nothing but the core code. Much of the problematic code resides in a dll that encapsulates third party specific communication: sockets, process pipes, soap calls, custom logic that changes the behavior of core code. Typically during an implementation or enhancement for a client, we would be writing new code to this area.)

There is virtually no logging done in our apps. There are no unit tests.

Version control only has 1 version of the full solution (using source safe 2005). So it's not possible to get a previous version of the entire solution, only individual files. (Unless someone knows ways around this).

Cannot reproduce locally, often times cannot reproduce on test environment (High chance that test and production are not the same version).

There is a high chance that the version the client is using is different from the one on source safe. This is because individual files are updated, which have embedded custom logic for that specific client. Often what happens is an update is made to a binary, which requires changes to several other binaries, but when a commit is done, no one has any record or knowledge of this. A somewhat common error I see is the 'Function/Method not found' or 'Method call has too many/too few parameters specified' on a clients environment.

This is a .net VB solution

Cannot install any software on client sites, but can locally

Our application is extremely customizable, but unfortunately the customization logic is spread out across all the classes and files, from the front end all the way to the data layer, including custom changes made to the database on a per client basis.

There are virtually no comments in the code. There is no documentation about the architecture. No documentation about the api. The only thing we have are hundreds upon hundreds of email chains that somewhat explain what's going on. The only people that know the code are the ones that originally wrote it, but they're no longer developers per say so they don't get involved that much.

And before you say it... yes I know; I want to shoot myself as well. It doesn't help that there's spaghetti code, hundreds of compiler warnings, and broken polymorphism that REALLY should be fixed, but I don't have a say in it.

Most common sort of errors I run into are null reference errors, invalid casts, and missing functions/function signature mismatches. Sometimes I am lucky and event viewer will log the class, method, and exception message. It's not the most helpful, but it's still something. The worst are the errors that have no trace, no repro steps besides a screenshot, and are generic error messages like the ones mentioned above. Sometimes it's not possible to find out why they occurred, only to pray that the environment is not properly configured, and that it will go away later.

I know this comes off as a bit of a rant, and to some extent it is. But I'm desperate for options. Are there other methods / tools I can use?

答:
Robert Harvey's advice is likely best, but since career advice is off topic, I'll give what answer can be given:

You are at the bottom of a very steep mountain covered in brambles and mud and irritable mountain goats.  There's no easy way up.  If you want to get to the top, you've got to force your way up one tremendously painful step at a time.

It seems you know exactly how things should work.  If no one else will help you then (again, ignoring career advice) your only choice is to start fixing these things yourself.

First, for all that is holy, get that stuff in a real version control system.  Pretty much anything at all but Source Safe, which is well-known as a stinking pile of garbage.  git is free and can be set up fairly easily.  You can't fix issues of the past lack of version control, but at least stop the problem from continuing on into the future.

Next, look into logging.  Find, or worst case, write a logging system, and start using it.  Use one that can be used on the client sites as well, so when things go sideways you have at least something.

And start writing tests, at least for new changes you make.

There is no sugar coating it: there is no answer here that doesn't involve lots of work, or treating this as a question of career.


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

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

How did you define and find your coding style?

How do you keep augmenting and improving it?

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

答:
How did you define and find your coding style?

By focusing on simplicity and readability (readability !== understandability, see Spartan Programming)

How do you keep augmenting and improving it?

By reviewing others' and my own code (and even coding standards themselves).

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

I use dokuwiki, a breeze to setup (no database), hierarchical structure, granular control (ACL out of the box), really nice looks, and well, its a wiki, so anyone can contribute. Also, contributions/changes are always under consensus and justified, based on simplicity and readability.


答:
For me it makes more sense as then I don't need to re-parse if errors occur when sending the email for example.

In such a case, the main decision criteria are simplicity and performance (which depend not only on the process you are implementing, but also how you do it).

For example, when the running time for re-parsing the input file is negligible, and you need the full data of the excel sheet again in case of an email sending error, it will probably be simpler and faster to reparse the excel file again and not take the burden of storing the data in a database first, and retrieving it again when the email has to be resent. Reparsing the same data twice is not "bad" just because it happens twice, as long as it gives you reliably the same output from the same input, and as long as the parsing does not involve a complex, very slow transformation process.

If the parsing itself can show up errors which must be corrected first (maybe the spreadsheet has not the expected structure?), or if there is a clean-up step involved, the situation starts to change. Then you need an additional intermediate data store for the cleaned data anyway. That could be a new Excel file, of course, and that may be still the most simple solution. But if one needs to integrate additional data from other data sources as well, if you need to enforce some kind of relational constraints on the data, some kind of lightweight database might be a solution which serves you better.

However, lets assume you will have to generate 1000 emails from one excel file, each based on a different part of the data in the file. Now in the process of sending the mails, 5 of the mails come back and you need to retrieve the data for exactly those 5 receivers for preparing a resend. For such a case chances are high that by using database to re-query exactly the needed data only for those 5 persons, you can make the process simpler and faster. And if you need to store additional metadata like how many sending attempts for each receiver you had, a database gives you a place where you can introduce additional tables or columns for this metadata.

So the answer is it depends. A database introduces additional overhead, but also gives you benefits, this is a trade-off. And if you currently do not know the upcoming requirements well enough, start with the simpler approach first (which is probably not using a database initially), but make sure your HTML generation uses some intermediate data structures. That gives you the option to switch to a database later, when you get requirements that demand it.


问:
Passing the data of a certain page to another page. Windows Phone 7
The user will fill out information in page 1, and the data will be seen in the other page listed in a listbox.

Is it advisable to use data binding?

I've been studying/researching about data binding already for about 2 days and still couldn't understand it.

Simple example would really help.

答:
Page:1

```<code> PhoneApplicationService.Current.State["tittle"] = QTittle;
            PhoneApplicationService.Current.State["name"] = QUsername;

        NavigationService.Navigate(new Uri("/EditMyDetails.xaml", UriKind.RelativeOrAbsolute));
</code>```

Page:2

```<code> var tittle = PhoneApplicationService.Current.State["tittle"];

        var name = PhoneApplicationService.Current.State["name"];
</code>```

Body:
Page:1

 PhoneApplicationService.Current.State["tittle"] = QTittle;
            PhoneApplicationService.Current.State["name"] = QUsername;

        NavigationService.Navigate(new Uri("/EditMyDetails.xaml", UriKind.RelativeOrAbsolute));

Page:2

 var tittle = PhoneApplicationService.Current.State["tittle"];

        var name = PhoneApplicationService.Current.State["name"];


问:
Do feature fixes need to be local only?
From this blog post describing the git-flow model, it seems that feature branches have to remain local to the user working on them and are actually deleted right before pushing to origin.

This kind of makes sense, but what if other people want to checkout my feature branch to help me out for example? Should I push my branch only then? Should I not? If so why?

答:
Under the original gitflow specification, there is no requirement that features be local only, only that they SHOULD NOT be pushed to origin:

Feature branches typically exist in developer repos only, not in origin.

However, it's not a hard requirement. The gitflow API supports publishing and tracking features on origin:

```<code>git flow feature publish <name>
</code>```

Start sharing feature <name> on $ORIGIN

```<code>git flow feature track <name>
</code>```

Start tracking feature <name> that is shared on $ORIGIN

It was not part of the original specification, but was silently added in gitflow 0.2 when it was refactored to be a git subcommand.

Title: Do feature fixes need to be local only?

Body:
Under the original gitflow specification, there is no requirement that features be local only, only that they SHOULD NOT be pushed to origin:

Feature branches typically exist in developer repos only, not in origin.

However, it's not a hard requirement. The gitflow API supports publishing and tracking features on origin:

git flow feature publish <name>

Start sharing feature <name> on $ORIGIN

git flow feature track <name>

Start tracking feature <name> that is shared on $ORIGIN

It was not part of the original specification, but was silently added in gitflow 0.2 when it was refactored to be a git subcommand.


答:
(since you code in PHP, I am guessing that the Excel file is uploaded in some browser, so is coming from the Internet; if it is not the case, ignore my answer)

Is it better practice to store the parsed data in a database first and then use the data however I wish?

I believe that yes. The data is coming from an untrusted source, the "bad Internet", so parsing it carefully is validating the data.

(a malicious hacker might "fake" some HTTP requests and build bad ones)

In your database, you want to store somehow trusted (non-malicious) data.

Things could be different in an intranet (internal to a corporation) web application: then you could somehow trust your users, and data validation might be slightly less important.

Always beware of code injection.


问:
Avoid This Pointer
PROBLEM: this points to different instances at different stages of execution (as it should). But it is not always obvious which instance is that. On the other hand we could minimize the use of this, fixing its state with meaningful-name variables.

EXAMPLE:

```<code>// Variant A:
this.someFunction();

// Variant B:
var combobox = this;
combobox.someFunction();
</code>```

QUESTION: Is it a good or a bad style to replace this pointer with variables and why?

答:
I think there are two layers to this question (pun intended)

Note: I assume that you are referring to javascript, and I base my answer in that language.

1) this refers to the object that invokes the function

(or the object that the function was bound too, but we don't need to get into all of that...)

Why is this important?

Because, in javascript, functions are objects and can be set as properties on other objects.  If you are not careful with your function scope, it is easy for things to go wrong (especially when wiring up events/callbacks).

If you use a variable that locks this to the instance of the object, you are creating a "closure" in the function.

example (note what is being alerted):

```<code>var o1 = new function (){
    this.name = "o1";

    this.m1 = function () {
        alert(this.name);
    };
};

o1.m1(); // alerts "o1"

var o2 = new function () {
    this.name = "o2";

    this.overrideM1 = function () {
        alert(this.name + " override");
    };
};

o1.m1 = o2.overrideM1; // replace the function
o1.m1(); // alerts "o1 override"

var o3 = new function () {
    var self = this;

    self.name = "o3";

    self.overrideM1 = function () {
        alert(self.name + " override2"); // note the use of "self" instead of "this".
    };
};

o1.m1 = o3.overrideM1; // replace the function
o1.m1(); // alerts "o3 override2", because we have a "closure" in the function to the "o3" instance.
</code>```

So, how does this relate to your question?

Variant A and Variant B are not necessarily as "equivalent" as you might think when you look at all the code in your project.

Some places might need to use the this literal inside a function, because it gets used on different objects and needs the correct scope when called on those objects.  Other places might assign this to a variable to create a closure in a function for a specific reason.

It's not a matter of which one is "better" because they are functionally different.

2) But what about in the places where we don't have to worry about scope, and the two variants are actually functionally the same?

In these cases it would be best to come up with a convention that your team agrees with and will use consistently.  Either would work.

In my opinion, Variant A is the cleaner of the two (assuming that your code is designed well)  If it is not obvious what this is referring to in the code you are looking at, it's probably a sign that you need to clean up your code.  Adding more variables all over the place is just going to make more clutter in an already "confusing" code base.

Title: Avoid This Pointer

Body:
I think there are two layers to this question (pun intended)

Note: I assume that you are referring to javascript, and I base my answer in that language.

1) this refers to the object that invokes the function

(or the object that the function was bound too, but we don't need to get into all of that...)

Why is this important?

Because, in javascript, functions are objects and can be set as properties on other objects.  If you are not careful with your function scope, it is easy for things to go wrong (especially when wiring up events/callbacks).

If you use a variable that locks this to the instance of the object, you are creating a "closure" in the function.

example (note what is being alerted):

var o1 = new function (){
    this.name = "o1";

    this.m1 = function () {
        alert(this.name);
    };
};

o1.m1(); // alerts "o1"

var o2 = new function () {
    this.name = "o2";

    this.overrideM1 = function () {
        alert(this.name + " override");
    };
};

o1.m1 = o2.overrideM1; // replace the function
o1.m1(); // alerts "o1 override"

var o3 = new function () {
    var self = this;

    self.name = "o3";

    self.overrideM1 = function () {
        alert(self.name + " override2"); // note the use of "self" instead of "this".
    };
};

o1.m1 = o3.overrideM1; // replace the function
o1.m1(); // alerts "o3 override2", because we have a "closure" in the function to the "o3" instance.

So, how does this relate to your question?

Variant A and Variant B are not necessarily as "equivalent" as you might think when you look at all the code in your project.

Some places might need to use the this literal inside a function, because it gets used on different objects and needs the correct scope when called on those objects.  Other places might assign this to a variable to create a closure in a function for a specific reason.

It's not a matter of which one is "better" because they are functionally different.

2) But what about in the places where we don't have to worry about scope, and the two variants are actually functionally the same?

In these cases it would be best to come up with a convention that your team agrees with and will use consistently.  Either would work.

In my opinion, Variant A is the cleaner of the two (assuming that your code is designed well)  If it is not obvious what this is referring to in the code you are looking at, it's probably a sign that you need to clean up your code.  Adding more variables all over the place is just going to make more clutter in an already "confusing" code base.


答:
There is a very old joke circa 1916. A harassed young lieutenant sent the message "Send reinforcements we are going to advance" via a runner who passed on the message by telephone and eventually a telegram was received at HQ. A confused general received the message "Send three and fourpence we are going to a dance" and duly sent the correct change.

EXCEL is a pretty decent data store (with a c***p API) just parse it when you need to. Using an intermediate data store will only introduce bugs and its doubtful that the extra IO involved in writing to a database would lead to a performance improvement.


问:
Isn't the master branch just a surrogate of tagging in the gitflow model?
Reading the gitflow model, it seems to me that the master branch is there only to provide a branch where to store stable versions. What does that add to just tagging develop with the stable versions?

答:
It is similar to the question "Why do we say 'today', instead of 'the day that started the last time the clock went from 23:59 to 00:00'?"

Having the concept of "latest stable" codified in a branch rather than something you have to search for simplifies things.

Whenever you need the latest stable version of the code, you check out the master branch. If you only use tags to mark stable versions, you'd need to first find out what the latest version was so you can check out the correct tag.

You can also feed it into your production line; any time a commit is made to the master branch, that triggers a build and deployment of your product.

You could do all those things without a master-branch; without any branches or tags at all. But it is easier with them, and the whole point of git-flow is to make things easier. Easier to know what you should do, what others do and to communicate about those doings.


答:
If your idea is that by storing data in a database in case an error occurs you don't need to parse it again: Errors should be rare, they are a big hit anyway, so a little bit of time for parsing wouldn't matter. On the other hand, you must now make sure that the database file is still there, that it hasn't been modified or overwritten, you must delete it when it's not needed anymore, ..., you add all kinds of useless work that you have to code, that you have to test, that you have to get right. Especially since this all has to work correctly if an error occurs, which is hard to test, and difficult - because there has just been an error.

You add a huge lot of additional work for a rare case, where nobody cares about the performance, and it isn't that likely that you actually gain any performance, because parsing Excel files isn't that slow, and databases aren't that fast.

There was an article about the evils of "premature optimisation"; that whole article assumed that there is actually optimisation, which I somehow doubt. Has anyone actually complained that re-parsing the Excel file in case an error happened is too slow?


问:
Is there any reason to use "plain old data" classes?
In legacy code I occasionally see classes that are nothing but wrappers for data. something like:

```<code>class Bottle {
   int height;
   int diameter;
   Cap capType;

   getters/setters, maybe a constructor
}
</code>```

My understanding of OO is that classes are structures for data and the methods of operating on that data. This seems to preclude objects of this type. To me they are nothing more than structs and kind of defeat the purpose of OO. I don't think it's necessarily evil, though it may be a code smell.

Is there a case where such objects would be necessary? If this is used often, does it make the design suspect?

答: With game design, the overhead of 1000's of function calls, and event listeners can sometimes make it worth it to have classes that only store data, and have other classes that loop through all the data only classes to perform the logic.</p>


问:
Is it effective to review code in language I don't know?
I'm an experienced developer, but have not done many code reviews. I'm being asked to review code written in Python but I do not know Python.

Does it make any sense at all to review code in a language I don't know?

答:
This could be a win-win situation.  I would go as far as to say that you could be an especially valuable reviewer because you are a Python virgin who has not been tainted by the Curse of Knowledge.

Think of it this way: if code is clear enough that even a Python virgin can understand it, then it must be good code.  The parts that you have trouble understanding might be candidates for rework or better commenting.

Obviously, it would also be beneficial for you, because you would be picking up a new language as you go.  (Hopefully, the code you are given is a good example to learn from.)  This arrangement should work particularly well for Python, a language that has a reputation of being "executable pseudocode".  If you are an experienced developer, then you shouldn't have much difficulty understanding the gist of a Python program.

The caveat would be that you wouldn't be expected to spot bugs arising from language-specific gotchas.  But bug-finding is not the only purpose of code reviews.  If nothing else, you would be participating in knowledge transfer simply by being aware of what kind of stuff goes on in your colleague's code.


问:
JavaScript functional conversion from flat list to tree
I've been going through the RxJS tutorials http://reactivex.io/learnrx/.
Almost all of the exercises involve moving from a hierarchical structure to a flat structure so I thought I'd try to do the opposite.

I want to convert from a flat array to a tree structure based on a property of each array item, using the same functional constructs from the tutorial.

I.e. Go from this:

```<code>var videos = [
    {
        "id": 70111470,
        "title": "Die Hard",
        "category": "Action"
    },
    {
        "id": 654356453,
        "title": "Bad Boys",
        "category": "Action"
    },
    {
        "id": 65432445,
        "title": "Anchorman",
        "category": "Comedy"
    },
    {
        "id": 675465,
        "title": "Everest",
        "category": "New Release"
    }
];
</code>```

To this (based on each video's category):

```<code>result === [
    {
        "category": "Action",
        "videos": [
            {
                "id": 70111470,
                "title": "Die Hard"
            },
            {
                "id": 654356453,
                "title": "Bad Boys"
            }
        ]
    },
    {
        "category": "Comedy",
        "videos": [
            {
                "id": 65432445,
                "title": "Anchorman"
            }
        ]
    },
    {
        "category": "New Release",
        "videos": [
            {
                "id": 675465,
                "title": "Everest"
            }
        ]
    }
];
</code>```

I've come up with the following code that works, but I feel like I'm missing an easier way (perhaps solving in a single reduce) which would in turn be more performant (rather than filtering videos many times):

```<code>var result =
    videos.reduce(function(catArray, video) {
       var catName = video.category;
       if (catArray.indexOf(catName) === -1) {
          catArray.push(catName);
       }
       return catArray;
    }, [])
    .map(function(categoryName) {
        return {
            category: categoryName,
            videos: videos.filter(function(video) {
                        return video.category === categoryName;
                    }).map(function(video) {
                        return {
                            id: video.id,
                            title: video.title
                        };
                    })
        };
    });
</code>```

Is there a better way using functional methods?

答:
This is simpler than a tree because your result can only have one level. All you want is to group your array by category and then map each group into objects. The map part will just be rearranging things a little bit into your final desired structure. You won't need to filter the full list of videos inside the map like you're currently doing.

Unfortunately, JavaScript isn't particularly friendly to the functional paradigm by default so it doesn't have a built in groupBy. So you can either reimplement grouping inside your reduce or you can use one from an external library like Ramda. The example code there should help you understand how groupBy works.


问:
Declaration confusion in pointers
I was just confused about the following declaration in C:

```<code>char **p[5]
</code>```

I understand the char *p[] as an array of character pointers, but this one is puzzling me. Based on the precedence of [] over *, how can I interpret this?

答:
In 'C', an "array" is effectively the address of its first element ...

```<code>char a[5] == char * a
</code>```

... so your variable ...

```<code>char **p[5]
</code>```

... is a pointer to a pointer to a pointer to a character (of which there just happen to be five allocated sequentially in memory).

If in doubt, revert to pen and paper and draw boxes to represent each pointer:

```<code>  ---      ---      ---
p| * | -> | * | -> | * |
  ---      ---      ---
                     |
                     v
                    "four\0"
</code>```

Title: Declaration confusion in pointers

Body:
In 'C', an "array" is effectively the address of its first element ...

char a[5] == char * a

... so your variable ...

char **p[5]

... is a pointer to a pointer to a pointer to a character (of which there just happen to be five allocated sequentially in memory).

If in doubt, revert to pen and paper and draw boxes to represent each pointer:

  ---      ---      ---
p| * | -> | * | -> | * |
  ---      ---      ---
                     |
                     v
                    "four\0"


问:
Junction table related to another junction table
I'm defining a DB structure, and I have a strong feeling I'm not doing it right. I have hotels that can be configured to offer some optional services (airport pickup, massage), that can in turn be booked with a room. So, each hotel picks which services it offers and the price. Currently I have the following tables (simplified):

```<code>Guests (id, (PK), name)
Hotels (id (PK), name)
HotelServices (name (PK))
Hotels_HotelServices (id (PK), hotel_id (FK), service (FK), price_value, price_currency)
Rooms (id (PK), hotel_id (FK), number, capacity, price_value, price_currency)
Bookings (id (PK), guest_id (FK), room_id (FK), date_from, date_to)
Bookings_Hotels_HotelServices (id (PK), hotels_hotelServices_id (FK))
</code>```

Is this last table that disturbs me the most. I don't like having a junction table pointing to another junction table, but I can't think of another way of representing which services were booked with the room.

Is there a better, common approach to modelling such situation?

答:
Why do you need a triple reference? The savoy is a HOTEL. "Turkish massage" is a SERVICE. If the Savoy offers that, that's an entry ii your H_S table.

If someone stays at the savoy, that's an entry in the BOOKING table pointing to the hotel; if they order a massage as well, that's an entry in the B_S table pointing to the booking and to the service. There's no need to point to H_S rather than directly to SERVICE.

Edit. If your "service" definitions vary in price from hoptel to hotel, and all you're interested in is the price, then sure, you should store the price right in the H_S table and not even have a SERVICE table. But if the services have attributes of their own which you need to retrieve (e.g. for describing them on the bill), then they should always go into a separate table to which you join as necessary. Quasi-static data like model or service definitions with a couple hundrend or thousand rows are really not "big data" - database engines basically laugh at that. It's just the ones with unlimited growth potential (e.g. social media comments) where access efficiency usually becomes a problem.


答:
1) Debugger cannot be used on client site ...

That's perfectly normal.

... or locally

Now that's a problem.

2) There is virtually no logging done in our apps.

Logging is the Production Debugging.

There are no unit tests.

Oh dear.
All to common, though.

3) Version control only has 1 version of the full solution

Then you're not using Version Control.

4) Cannot reproduce locally, often times cannot reproduce on test environment (High chance that test and production are not the same version).

So only the deployed, client environment shows the errors.

In that case, you need disgnostic logging embedded in the application code that (a) traps and [fully] records [fatal] errors and (b) can be "dialed up" on demand to produce additional, continuous, diagnostics that are useful in tracking down the problem(s).

5) There is a high chance that the version the client is using is different from the one on source safe.

Again, you're just not using version control to your advantage.

8) Our application is extremely customizable

That's fairly typical.

The site-specific differences should be managed through Version Control "Branching".

9) There are virtually no comments in the code.

Again, that's all too common, because Developers write "self-documenting" code, don't they?

Or, at least, code that they understand on the day that they write it.

There is no documentation about the architecture.

Oh dear.

No documentation about the api.

Oh dear, oh dear.

And before you say it... yes I know; I want to shoot myself as well.

No; you want to shoot the people who wrote all this stuff, created an undocumented, unmaintainable mess and then moved on to pastures new, leaving the unconscionable mess behind them.

Most common sort of errors I run into are null reference errors, invalid casts, and missing functions/function signature mismatches.

Null references and invalid casts are run-time errors; to some extent, you should be expecting them and the fact they you're getting them frequently suggests a lack of defensive programming (or a surplus of optimism) by the original authors.

Function signature mismatches should cause a broken build; those should cause "broken builds" and should never make it out of the door!

Title: Methods of debugging code (Nightmare situation)

Body:
I am frequently tasked with debugging an application at my job. It is a BI Application that we deploy to businesses, which includes a test environment, and a production environment. I am wondering if there are any apps/tools/methods that people can suggest, based on these constraints:

Debugger cannot be used on client site or locally, because the software depends on custom third party applications that we don't have test environments for. (EDIT: to be fair, it is possible to debug locally in some cases. If we use nothing but the core code. Much of the problematic code resides in a dll that encapsulates third party specific communication: sockets, process pipes, soap calls, custom logic that changes the behavior of core code. Typically during an implementation or enhancement for a client, we would be writing new code to this area.)

There is virtually no logging done in our apps. There are no unit tests.

Version control only has 1 version of the full solution (using source safe 2005). So it's not possible to get a previous version of the entire solution, only individual files. (Unless someone knows ways around this).

Cannot reproduce locally, often times cannot reproduce on test environment (High chance that test and production are not the same version).

There is a high chance that the version the client is using is different from the one on source safe. This is because individual files are updated, which have embedded custom logic for that specific client. Often what happens is an update is made to a binary, which requires changes to several other binaries, but when a commit is done, no one has any record or knowledge of this. A somewhat common error I see is the 'Function/Method not found' or 'Method call has too many/too few parameters specified' on a clients environment.

This is a .net VB solution

Cannot install any software on client sites, but can locally

Our application is extremely customizable, but unfortunately the customization logic is spread out across all the classes and files, from the front end all the way to the data layer, including custom changes made to the database on a per client basis.

There are virtually no comments in the code. There is no documentation about the architecture. No documentation about the api. The only thing we have are hundreds upon hundreds of email chains that somewhat explain what's going on. The only people that know the code are the ones that originally wrote it, but they're no longer developers per say so they don't get involved that much.

And before you say it... yes I know; I want to shoot myself as well. It doesn't help that there's spaghetti code, hundreds of compiler warnings, and broken polymorphism that REALLY should be fixed, but I don't have a say in it.

Most common sort of errors I run into are null reference errors, invalid casts, and missing functions/function signature mismatches. Sometimes I am lucky and event viewer will log the class, method, and exception message. It's not the most helpful, but it's still something. The worst are the errors that have no trace, no repro steps besides a screenshot, and are generic error messages like the ones mentioned above. Sometimes it's not possible to find out why they occurred, only to pray that the environment is not properly configured, and that it will go away later.

I know this comes off as a bit of a rant, and to some extent it is. But I'm desperate for options. Are there other methods / tools I can use?


问:
What is "Split Data Model", mentioned in the book "Java Concurrency In Practice"?
I'm learning Java multithreading programming by the book "Java Concurrency In Practice". In chapter 9.4.2 Split Data Model, I read this:

From the perspective of the GUI, the Swing table model classes like TableModel and treeModel are the official
  repository for data to be displayed. However, these model objects are often themselves "views" of other objects
  managed by the application. A program that has both a presentation‐domain and an application domain data model is
  said to have a split‐model design (Fowler, 2005).

In a split‐model design, the presentation model is confined to the event thread and the other model, the shared model,
  is thread‐safe and may be accessed by both the event thread and application threads. The presentation model registers
  listeners with the shared model so it can be notified of updates. The presentation model can then be updated from the
  shared model by embedding a snapshot of the relevant state in the update message or by having the presentation
  model retrieve the data directly from the shared model when it receives an update event.

The snapshot approach is simple, but has limitations. It works well when the data model is small, updates are not too
  frequent, and the structure of the two models is similar. If the data model is large or updates are very frequent, or if one
  or both sides of the split contain information that is not visible to the other side, it can be more efficient to send
  incremental updates instead of entire snapshots. This approach has the effect of serializing updates on the shared
  model and recreating them in the event thread against the presentation model. Another advantage of incremental
  updates is that finer‐grained information about what changed can improve the perceived quality of the display if only
  one vehicle moves, we don't have to repaint the entire display, just the affected regions.

What is the meaning of "Split Data Model"? Can you show me an example to help me understand it?

答:
The idea here is to incrementally change things using events instead of refreshing the model every time the user needs the "latest data".

Suppose for example an application that shows the contents of a database table, for example, in a select box. Usually, when you refresh the component, the app queries the whole database table and update the whole list, even if 90% of the list has the very same elements.

Now suppose a second situation. You have a table of alarms for different components. Instead of polling all of them periodically, you wait each one of them to notify you when something happens. So you're actually listening for events instead of asking them all every time "is that ok? is that ok?"

An example is OSGI. Eclipse for example uses OSGI (Equinox) to manage its modules and plug-ins (in fact, Eclipse itself is a big plug-in manager). When you update a module or install a new plug-in, you don't have to restart the whole application to load the changes. Instead, Eclipse is notified by the OSGI engine and reloads just that part that was updated, via an event. So changes are updated incrementally and, in most of the cases, without the need of re-starting the app.

OwnerDisplayName: FireSun


问:
How to handle file uploads express (UUID / location)
I am building a community website with a NodeJS express backend and a mysql database. Now I am up to the point where I want to store profile pictures of users and pictures related to specfic questions. I googled a bit and found many ways how to handle image upload, but I still have problems to figure out how and what to store regarding the location of the image.

I was thinking about creating a key-value store or a database table with a generated UUID as the key and the location of the image on the server (e.g. /images/user/123/profilepic/bla.jpg) as the value. This way I could store the UUID in the database (for example in the table user as profilePicId) and handle all image requests the same way, just by asking for the image with a certain UUID.

Using this method, the process would be like the following when client wants to get user info + profile pic of a user:

Do get request to get user a object (firstname lastname, picUUID).

Do get request on the api /file/{picUUID}

Server > check key-value store what location is assigned to UUID and
return image

Put the apiUrl/file/{user.picUUID} address in an image tag's src and done :)

Am I on the right track here or what would be your take on this? I guess that this problem has been tackled many times. I am therefore also pretty stumped that there is not much information about this topic.

答:
If there's only ever one image per person, you may not need a separate image data store. You could store the path with the user. Keeping it separate doesn't hurt, or course.

Regardless of how you store it, I would simply return the image path as part of the user "profile". /api/userprofile/id might return:

```<code>{
    name: "Honey Boo Boo",
    favoriteColor: "plaid",
    imagePath: "/images/user/123/profilepic/bla.jpg"
}
</code>```

Then it's a one step process to bind the profile data to a view versus a secondary request to fetch, bind, and resolve the image.

Body:
If there's only ever one image per person, you may not need a separate image data store. You could store the path with the user. Keeping it separate doesn't hurt, or course.

Regardless of how you store it, I would simply return the image path as part of the user "profile". /api/userprofile/id might return:

{
    name: "Honey Boo Boo",
    favoriteColor: "plaid",
    imagePath: "/images/user/123/profilepic/bla.jpg"
}

Then it's a one step process to bind the profile data to a view versus a secondary request to fetch, bind, and resolve the image.


问:
Tracking progress via a burndown chart when sprints overlap
Our team has adopted some agile practices to help us develop and deliver our software to our client. We adopt practices as needed (as problems/challenges were identified) rather than jumping wholesale into the agile camp. The big ones for us are maintaining a product and sprint backlog and developing and delivering new versions in roughly one month sprints. We do estimate the items in our sprint backlog to guesstimate what we can deliver within a sprint. However we do not track progress very well so it's difficult to know whether or not we are on target.

The next step in our evolution appears to be to improve our progress tracking ability. We are looking at using burn down charts to aid us. However, our sprints overlap significantly due to established and procedures for our software promotion schedule. We have the following established events:

Development begins on Sprint 1 and continues until code freeze. That said we do test our software throughout this phase with the development and test groups.

Code freeze stops development on Sprint 1 functionality. We have a small window to finish or fix any issues before the next event acceptance promotion 1. In addition development begins on Sprint 2.

Acceptance promotion 1 promotes the application to the client's acceptance environment where it is tested by our test group. Issues identified in testing may be fixed during a small window before acceptance promotion 2. Meanwhile Sprint 2 development continues.

Acceptance promotion 2 promotes the application one last time to the client's acceptance environment to validate any issues identified during acceptance promotion 1. Sprint 2 development continues.

Production promotion promotes the application to production and it is tested by our test group and Sprint 1 is officially completed. This is when it is truly done.

A visual depiction of this can be seen below. The average calendar time between development begins and code freeze is four weeks. The average time between code freeze and production promotion is two weeks.

larger resolution version

This schedule of events is not within our control. Client policy dictates when application software is promoted from Test to Acceptance to Production. No application code may be modified beyond our second fix window. We do not perform the promotions. This is accomplished by '3rd' parties at the client's site, again, due to policy.

In addition, some tasks such as data updates, can and do happen outside of this schedule. Certain data updates follow the code (for instance, when there is a schema dependency) but others such as data bugs or new data can and do occur outside of this schedule. This is due to fewer restrictions as to what may be modified on the clients environment and when. Only application code is restricted to these specific milestones. Data and configuration are exempt and technically may be modified as needed. We are considering tightening this up so that data updates follow the same schedule as the code.

Given this scenario, our overlapping sprints, I have a several questions?

What is the proper way to create/handle a burn down chart when we burn development, testing, and data hours from the previous sprint while also working towards the next one?

I think we have 2 concurrent burn down charts on for each sprint.

Assuming we at most have two burn down charts how do we best display the cumulative burn down when the sprints overlap so as to understand our actual workload progress on each so as to best set us up for success?

If items are found in Sprint 1 after code freeze that need to be addressed in Sprint 2 how does that our Sprint 2 backlog and burn down?

I assume that for critical items we need to bump out less critical Sprint 2 items to make room for the incomplete Sprint 1 items. Non critical items will be bumped to Sprint 3 or later.

What would be the proper start and end dates for the burn down chart?

It seems the best option would be to reflect reality. Sprint 1 is not truly done (including testing and data updates) until production promotion and its final testing. So the start date would be development begins
and the end date be production promotion despite any overlap.

What else am I missing? What else could or will bite us?

答:
The simplest way is to stop thinking that Scrum is agile and use a slightly different (and better - everything is better than Scrum :) ) methodology such as Kanban.

You do not need a burndown chart to be agile, and you do not even need to be "on target". Burndowns are really there solely as a tool to help you determine how much work you should be able to achieve in a sprint, as measured by work completed in previous sprints. Other methodologies do not bother with such things and prefer to just do what is needed until complete - which is what you do in Scrum anyway, but without the pressure of a burndown chart driving you to burnout.

If you insist on using burndown charts, remember that they are tools based on previous work (which is why you use estimation tools like t-shirt sizing for tasks instead of allocating definite time durations), a burndown is a relative to every other burndown. So you can simply set your sprint to include the 6 weeks (yes, ignoring the overlap) as the amount of work you get done in one sprint will be reduced by the overlapping work, and the sprint after that will also include the overlapping work, etc. This means every burndown will be consistent with every other one, and therefore will be self-regulating. After 3 sprints your velocity will settle down to a stable number. (note, in normal Scrum systems you have to perform 3 sprints or so to get a stable velocity anyway!)


答:
QUESTION: Is it a good or a bad style to replace this pointer with
  variables and why?

To me, if we try to go as language agnostic as possible, then a lot of the temptation to give this a more meaningful name seems kind of counter-productive.

Focus on Abstract Interfaces

First, a lot the flexibility of languages that allow you to write this.someFunction() where this could point to different data types at different times within the same function can benefit from that flexibility. In such a generic context, it shouldn't matter to the correctness of the function what this is:

```<code>function impale(stick)
{
    // Kill this thing. It doesn't matter what it is in the context
    // of this function, all that matters is that it can be killed.
    this.kill();
    stick.combine(this);
}
</code>```

In such a case, the impale function shouldn't care about what is actually implicitly passed through it (what object it is invoked on). All it should care about is that it can be killed, made dead, and can be combined with a stick (though some of that passes responsibility passes over to stick). If someone passes something which cannot be killed, that's an error in the one calling the function, and not the callee (the function) itself.

In such generic contexts, to try to assign a variable name as a sort of alias defeats a lot of the purpose:

```<code>function impale(stick)
{
    // This kind of documentation suggests this function only works on cats.
    var cat = this;
    cat.kill();
    stick.combine(cat);
}
</code>```

... same goes for this (simply a comment):

```<code>function impale(stick)
{
    // Kill a cat.
    this.kill();
    stick.combine(this);
}
</code>```

To add this kind of type-based information, even in the form of a comment, might actually place an unhealthy focus on concrete details over abstract interfaces: "what is this exactly?" vs. "what can this do regardless of what it actually is?"

Focusing much more on the latter, and caring less about the former, will generally enhance your ability to write code that works in a wider range of scenarios (and therefore ultimately write less code to maintain). Yet, of course, it is hard to do this perfectly. In debugging scenarios, for example, what something actually is might start to become very relevant, yet that's something most decent debuggers will show in a watch window when examining what this is.

Superfluous, Mutable State

Taking the above example though, I'd say the comment route is actually preferable to aliasing this through a mutable variable, in cases where there is no logical difference and the local variable only serves as an alias for documentation purposes.

It's because the complexity of a function to human interpreters is often multiplied by the amount of mutable state that is accessible. This is especially true in a team-wide setting where we don't even know what the other members of the team did exactly to every single line of code in every function until we carefully decipher them line-by-line. A function that has 300 lines of code and 20 mutable variables at the top and access to 5 global variables at module/file/class scope, e.g., will feel like it has an immediate state complexity of 25*300 = 7500. Meanwhile a function that is 20 lines of code with access to one local variable in the middle of the function (10 lines of code capable of accessing it) and no global variables will feel  more like it has a state complexity of 1*10 = 10.

As asinine as it might seem to think that the introduction of a cat variable above might lead to a higher potential of error ("no one would ever mess with that and set it to anything else"), in a wide team setting, you start to see every kind of goofy mistake imaginable at some point, accompanied by a strong appreciation for Murphy's law.

This idea of state complexity is kind of a rough metric I made up (perhaps best formally expressed in terms of coupling), and we don't perfectly think this way, but the more mutable state is exposed to each line of code, the more it tends to feel complex, the more room there will seem to exist for error, since the more our mental stack has to account for potential changes made to all such accessible states.

This is one of the reasons why it's generally preferable to give variables a narrower scope (shorter functions, variables declared more locally within shorter scopes, classes with fewer member functions that have access to internal states, smaller files if they have access to file-scope global variables, etc). From the same standpoint, if a class can store fewer member variables because they can be computed cheaply on demand, then it might very well be preferable to cheaply compute them on demand instead of storing and managing extra state. The less places that exist that have access to mutable states, the less potential there typically is for human error, and the fewer suspects we have to check when we encounter a bug caused from an invalid state (a failure to maintain an invariant). If we encounter a variable that is set to a value it should never have, then our immediate list of suspects is basically the number of lines that had access to the variable (the fewer the better). For this reason, it's likewise generally preferable not to create temporary local variables superfluously, like solely for the sake of aliasing/documentation with no other benefit, when a comment will do.

So in this ultra general, language-agnostic context, for any question that asks, "Should I create more mutable state than necessary?", I'd suggest to err on the side of less state to manage. A lot of the obstacles for a program to function correctly will be the number of mutable states multiplied by their scope. If you can get away with fewer variables or smaller scopes, then aim for fewer variables/smaller scopes.

Non-Generic Contexts

In cases where type information seems very relevant, including cases where the functions cannot hope to apply to more than one type of thing, it should generally be contextually obvious what this is. That's where I'd suggest looking to improve things more than trying to alias/document what this is in such a blatant and immediate way. That is, improve the documentation and organization of the surrounding code.

There are many ways to make such contextual info more obvious. For example, if the file name in which the function is defined is called cat.something, then it should be obvious that it applies to cat objects. If naming files to contain a single class is not idiomatic (something I found is not very idiomatic in Python, e.g., but it has special safeguards to make module-scope global variable access blatantly explicit to mitigate the problems), then perhaps we'll at least have something like this:

```<code>// Pretty obvious that this kills a cat.
cat.impale = new function(stick)
{
    this.kill()
    stick.combine(this);
}
</code>```

If you're doing something fancy with closures as in Caleb's example where the difference between capturing this to a variable makes a logical difference and not merely designed for documentation, you'll notice he used the variable name, self, which is equally generic. That's also what I'd recommend if you encounter a scenario where it makes a difference: don't try to degeneralize the function by giving the variable capturing this a data type-specific name.

Asserting Preconditions

Yet let's say, after exhausting all of these scenarios, you still find the information about what this is both extremely relevant and elusive simultaneously (not obvious from the surrounding context). If refactoring is out of the question, then perhaps you could at least do something like this:

```<code>function impale(stick)
{
    assert(this is cat);
    this.kill();
    stick.combine(this);
}
</code>```

With this at least, the assert does more than document. It guarantees that the function is invoked for a cat or else it'll become a runtime error, immediately noticeable (in a good way, helping to spot bugs immediately before they grow more difficult and elusive to correct the longer they fly under radar). I'd still recommend it as a last resort, but at least this does something more than just add documentation which could end up no longer matching what is actually going on. The assert makes it impossible: it serves as both documentation and an enforced guarantee/safeguard that the function will always match the expected behavior should it continue past the assertion.

Title: Avoid This Pointer

Body:
PROBLEM: this points to different instances at different stages of execution (as it should). But it is not always obvious which instance is that. On the other hand we could minimize the use of this, fixing its state with meaningful-name variables.

EXAMPLE:

```<code>// Variant A:
this.someFunction();

// Variant B:
var combobox = this;
combobox.someFunction();
</code>```

QUESTION: Is it a good or a bad style to replace this pointer with variables and why?

Body:
QUESTION: Is it a good or a bad style to replace this pointer with
  variables and why?

To me, if we try to go as language agnostic as possible, then a lot of the temptation to give this a more meaningful name seems kind of counter-productive.

Focus on Abstract Interfaces

First, a lot the flexibility of languages that allow you to write this.someFunction() where this could point to different data types at different times within the same function can benefit from that flexibility. In such a generic context, it shouldn't matter to the correctness of the function what this is:

function impale(stick)
{
    // Kill this thing. It doesn't matter what it is in the context
    // of this function, all that matters is that it can be killed.
    this.kill();
    stick.combine(this);
}

In such a case, the impale function shouldn't care about what is actually implicitly passed through it (what object it is invoked on). All it should care about is that it can be killed, made dead, and can be combined with a stick (though some of that passes responsibility passes over to stick). If someone passes something which cannot be killed, that's an error in the one calling the function, and not the callee (the function) itself.

In such generic contexts, to try to assign a variable name as a sort of alias defeats a lot of the purpose:

function impale(stick)
{
    // This kind of documentation suggests this function only works on cats.
    var cat = this;
    cat.kill();
    stick.combine(cat);
}

... same goes for this (simply a comment):

function impale(stick)
{
    // Kill a cat.
    this.kill();
    stick.combine(this);
}

To add this kind of type-based information, even in the form of a comment, might actually place an unhealthy focus on concrete details over abstract interfaces: "what is this exactly?" vs. "what can this do regardless of what it actually is?"

Focusing much more on the latter, and caring less about the former, will generally enhance your ability to write code that works in a wider range of scenarios (and therefore ultimately write less code to maintain). Yet, of course, it is hard to do this perfectly. In debugging scenarios, for example, what something actually is might start to become very relevant, yet that's something most decent debuggers will show in a watch window when examining what this is.

Superfluous, Mutable State

Taking the above example though, I'd say the comment route is actually preferable to aliasing this through a mutable variable, in cases where there is no logical difference and the local variable only serves as an alias for documentation purposes.

It's because the complexity of a function to human interpreters is often multiplied by the amount of mutable state that is accessible. This is especially true in a team-wide setting where we don't even know what the other members of the team did exactly to every single line of code in every function until we carefully decipher them line-by-line. A function that has 300 lines of code and 20 mutable variables at the top and access to 5 global variables at module/file/class scope, e.g., will feel like it has an immediate state complexity of 25*300 = 7500. Meanwhile a function that is 20 lines of code with access to one local variable in the middle of the function (10 lines of code capable of accessing it) and no global variables will feel  more like it has a state complexity of 1*10 = 10.

As asinine as it might seem to think that the introduction of a cat variable above might lead to a higher potential of error ("no one would ever mess with that and set it to anything else"), in a wide team setting, you start to see every kind of goofy mistake imaginable at some point, accompanied by a strong appreciation for Murphy's law.

This idea of state complexity is kind of a rough metric I made up (perhaps best formally expressed in terms of coupling), and we don't perfectly think this way, but the more mutable state is exposed to each line of code, the more it tends to feel complex, the more room there will seem to exist for error, since the more our mental stack has to account for potential changes made to all such accessible states.

This is one of the reasons why it's generally preferable to give variables a narrower scope (shorter functions, variables declared more locally within shorter scopes, classes with fewer member functions that have access to internal states, smaller files if they have access to file-scope global variables, etc). From the same standpoint, if a class can store fewer member variables because they can be computed cheaply on demand, then it might very well be preferable to cheaply compute them on demand instead of storing and managing extra state. The less places that exist that have access to mutable states, the less potential there typically is for human error, and the fewer suspects we have to check when we encounter a bug caused from an invalid state (a failure to maintain an invariant). If we encounter a variable that is set to a value it should never have, then our immediate list of suspects is basically the number of lines that had access to the variable (the fewer the better). For this reason, it's likewise generally preferable not to create temporary local variables superfluously, like solely for the sake of aliasing/documentation with no other benefit, when a comment will do.

So in this ultra general, language-agnostic context, for any question that asks, "Should I create more mutable state than necessary?", I'd suggest to err on the side of less state to manage. A lot of the obstacles for a program to function correctly will be the number of mutable states multiplied by their scope. If you can get away with fewer variables or smaller scopes, then aim for fewer variables/smaller scopes.

Non-Generic Contexts

In cases where type information seems very relevant, including cases where the functions cannot hope to apply to more than one type of thing, it should generally be contextually obvious what this is. That's where I'd suggest looking to improve things more than trying to alias/document what this is in such a blatant and immediate way. That is, improve the documentation and organization of the surrounding code.

There are many ways to make such contextual info more obvious. For example, if the file name in which the function is defined is called cat.something, then it should be obvious that it applies to cat objects. If naming files to contain a single class is not idiomatic (something I found is not very idiomatic in Python, e.g., but it has special safeguards to make module-scope global variable access blatantly explicit to mitigate the problems), then perhaps we'll at least have something like this:

// Pretty obvious that this kills a cat.
cat.impale = new function(stick)
{
    this.kill()
    stick.combine(this);
}

If you're doing something fancy with closures as in Caleb's example where the difference between capturing this to a variable makes a logical difference and not merely designed for documentation, you'll notice he used the variable name, self, which is equally generic. That's also what I'd recommend if you encounter a scenario where it makes a difference: don't try to degeneralize the function by giving the variable capturing this a data type-specific name.

Asserting Preconditions

Yet let's say, after exhausting all of these scenarios, you still find the information about what this is both extremely relevant and elusive simultaneously (not obvious from the surrounding context). If refactoring is out of the question, then perhaps you could at least do something like this:

function impale(stick)
{
    assert(this is cat);
    this.kill();
    stick.combine(this);
}

With this at least, the assert does more than document. It guarantees that the function is invoked for a cat or else it'll become a runtime error, immediately noticeable (in a good way, helping to spot bugs immediately before they grow more difficult and elusive to correct the longer they fly under radar). I'd still recommend it as a last resort, but at least this does something more than just add documentation which could end up no longer matching what is actually going on. The assert makes it impossible: it serves as both documentation and an enforced guarantee/safeguard that the function will always match the expected behavior should it continue past the assertion.


答:
I'm not sure whether hotel services are "booked with the room". What about conference rooms or all-day pool passes?

Hotels have customers that are not guests, so a "CUSTOMER" entity is a better suit. A customer that is staying in a room is a guest.

Also, entities/tables should have singular names.

EDIT:

There's absolutelly no problem in what you call "junction tables" having relationships with other "junction tables". Often times junction tables have business domain name which gives them a legitimate entity name. For example a junction table between workers and ships should be called CREW instead of WORKER_SHIP. That way what bothers you about relatioship between junction tables maybe would bother you less.

Title: Junction table related to another junction table

Body:
I'm defining a DB structure, and I have a strong feeling I'm not doing it right. I have hotels that can be configured to offer some optional services (airport pickup, massage), that can in turn be booked with a room. So, each hotel picks which services it offers and the price. Currently I have the following tables (simplified):

```<code>Guests (id, (PK), name)
Hotels (id (PK), name)
HotelServices (name (PK))
Hotels_HotelServices (id (PK), hotel_id (FK), service (FK), price_value, price_currency)
Rooms (id (PK), hotel_id (FK), number, capacity, price_value, price_currency)
Bookings (id (PK), guest_id (FK), room_id (FK), date_from, date_to)
Bookings_Hotels_HotelServices (id (PK), hotels_hotelServices_id (FK))
</code>```

Is this last table that disturbs me the most. I don't like having a junction table pointing to another junction table, but I can't think of another way of representing which services were booked with the room.

Is there a better, common approach to modelling such situation?