问:
Algorithm for best subset of items
I have a matrix M with size NxN where each position M(i,j) is an integer representing the relationship between item i and j. If i and j are the same item then the positions M(i,j) and M(j,i) are 0.

What I'd need is to regroup these N items in subgroups of 5 elements each one. The value of each group would be Σ(M(i,j) for each i, j in the group).

And I would need to maximize the total value of all groups.

I studied lots of algorithms more than 15 years ago and I forgot the most of them, and nowadays are lots of new algorithms, so I'm a bit lost trying to find the best one for these case.

A friend told me to investigate Clustering algorithms but they have lots of different versions and specializations, so I don't know which one to look at first.

And just one more thing, besides this algorithm to maximize each group, would I need an algorithm to maximize the total value of all groups, discarding the non optimal selections? I remember algorithms that made this but I don't even remember their name.

答:
The amount of possible combinations grows very large, even with relatively small values of N, so one thing you could consider is some variant of the local search if that's acceptable. Such algorithms are not guranteed to find the global optima though.

You need two things for this: a cost function and a neighborhood relation. The cost function you already gave and the neighborhood relation can be something as simple as swapping two elements between groups.

Title: Algorithm for best subset of items


问:
Should UDP & TCP port numbers represented as a short or integer?
I am currently designing some networking code, and this code expects the caller of the code to give it a port and hostname to connect to.

Since I am still in the development phase, I can still change many aspects of the code and more advantages and disadvantages come in for the code. However, some aspect of the code has left me still wondering what kind of number I should pass to the underlying socket creation code.

I have now to decide what version I should keep,

Version 1:

```<code>int port = 80;
ServerSocket socket = new ServerSocket(port);
</code>```

Advantages:

Almost al libraries in java expects integers instead of shorts, including the InetSocketAddress.

Disadvantages:

Using integers instead of shorts has left its security bugs in the past by security systems that don't except the underlying code to skip the first 16 bits.

Version 2:

```<code>short port = 80;
ServerSocket socket = new ServerSocket(port);
</code>```

Advantages:

It follows the underlying system convention from [C] to use 16 bit numbers

Disadvantages:

There must be a reason why java uses integers, isn't it?

My Question: Should I design my program to accept a int or a short

答:
Always use integers, unless you have a good reason to do otherwise. Here, we actually have a good reason: port numbers must be in the range 0 to 216-1 (i.e. fits into an unsigned 16 bit number).

Unfortunately, Java's short is a signed 16 bit number, having the range -215 to 215-1. If you use shorts in your API, port 65535 would have to be specified as -1. This might be understood correctly by a C API that just casts the number to an unsigned interpretation, but within Java this will lead to loads of unnecessary pain. In particular, -1 != 65535, and you can't easily test whether a given port is inside some port range.

If you are worried about correctness, then take steps to ensure correctness. We can model a concept such as a “valid port number” as a new type:

```<code>class ValidPortNumber {
  private static final MIN_PORT = 0;
  private static final MAX_PORT = 65535;
  private final int port;
  public ValidPortNumber(int port) {
    if (!(MIN_PORT <= port && port <= MAX_PORT))
      throw ...;
    this.port = port;
  }
  public int get() { return port; }
}
</code>```

Alternatively, you can do this validation in your socket class.

Why can't we rely on the value range of primitive types instead of performing validation? When mapping concepts (such as port numbers) to an implementation (such as numeric types), there can always be a mismatch:

some instances of the concept cannot be mapped to the implementation, since the implementation is too restricted. This more or less happens if you had chosen short, since new ServerSocket(65535) would not have worked! For a correct implementation, it is necessary that no such mismatch exists.

the implementation can represent values that are not instances of the concept. This would happen if you just use ints without any validation, since new ServerSocket(65536) would have been accepted. Eliminating this mismatch is not strictly necessary for a correct implementation, but it is necessary to detect bogus input and make your implementation resilient against usage bugs.

So remember: every port number is an integer, but not every integer is a port number. Therefore, you will have to write validation code. You cannot use shorts since not every port number is a signed short, and not every signed short is a port number.

Exercises

Answers are displayed when hovering over the quote.

can I represent the concept “Address” as the type “String”?

 Yes, every address can be represented as a string. However, I should create a custom type with validation since some strings such as "92hhef92fdff#as" aren't usable addresses.

can I represent the concept “Name” as the type “String”?

 Yes, every name can be written in a Unicode string. Since it is not possible to validate whether a name is “correct”, it is not useful to add a validation type. While some names cannot be expressed in script, this is outside of the scope of any reasonable model of names.

can I represent the concept “Telephone Number” as the type “int”?

 No, for a variety of reasons: leading zeroes might be significant (e.g. for international calls), or because digits might be grouped with spaces, parens, hyphens, … for better readability. Some numbers might use letters as mnemonics for numbers. However, every telephone number can be represented as a sequence of digits (plus perhaps the + and # chars?). We should therefore define a custom type to provide validation and a correct concept of equality, but we could use a string to store the digit sequence and possibly any user-supplied formatting.

ContentLicense: CC BY-SA 3.0

Body:
Always use integers, unless you have a good reason to do otherwise. Here, we actually have a good reason: port numbers must be in the range 0 to 216-1 (i.e. fits into an unsigned 16 bit number).

Unfortunately, Java's short is a signed 16 bit number, having the range -215 to 215-1. If you use shorts in your API, port 65535 would have to be specified as -1. This might be understood correctly by a C API that just casts the number to an unsigned interpretation, but within Java this will lead to loads of unnecessary pain. In particular, -1 != 65535, and you can't easily test whether a given port is inside some port range.

If you are worried about correctness, then take steps to ensure correctness. We can model a concept such as a “valid port number” as a new type:

class ValidPortNumber {
  private static final MIN_PORT = 0;
  private static final MAX_PORT = 65535;
  private final int port;
  public ValidPortNumber(int port) {
    if (!(MIN_PORT <= port && port <= MAX_PORT))
      throw ...;
    this.port = port;
  }
  public int get() { return port; }
}

Alternatively, you can do this validation in your socket class.

Why can't we rely on the value range of primitive types instead of performing validation? When mapping concepts (such as port numbers) to an implementation (such as numeric types), there can always be a mismatch:

some instances of the concept cannot be mapped to the implementation, since the implementation is too restricted. This more or less happens if you had chosen short, since new ServerSocket(65535) would not have worked! For a correct implementation, it is necessary that no such mismatch exists.

the implementation can represent values that are not instances of the concept. This would happen if you just use ints without any validation, since new ServerSocket(65536) would have been accepted. Eliminating this mismatch is not strictly necessary for a correct implementation, but it is necessary to detect bogus input and make your implementation resilient against usage bugs.

So remember: every port number is an integer, but not every integer is a port number. Therefore, you will have to write validation code. You cannot use shorts since not every port number is a signed short, and not every signed short is a port number.

Exercises

Answers are displayed when hovering over the quote.

can I represent the concept “Address” as the type “String”?

 Yes, every address can be represented as a string. However, I should create a custom type with validation since some strings such as "92hhef92fdff#as" aren't usable addresses.

can I represent the concept “Name” as the type “String”?

 Yes, every name can be written in a Unicode string. Since it is not possible to validate whether a name is “correct”, it is not useful to add a validation type. While some names cannot be expressed in script, this is outside of the scope of any reasonable model of names.

can I represent the concept “Telephone Number” as the type “int”?

 No, for a variety of reasons: leading zeroes might be significant (e.g. for international calls), or because digits might be grouped with spaces, parens, hyphens, … for better readability. Some numbers might use letters as mnemonics for numbers. However, every telephone number can be represented as a sequence of digits (plus perhaps the + and # chars?). We should therefore define a custom type to provide validation and a correct concept of equality, but we could use a string to store the digit sequence and possibly any user-supplied formatting.


问:
What is the name for user-defined methods / functions that get called implicitly?
I want to mark such methods in my application code with a comment that highlights that these methods are expected to get called by the framework / compiler the application is written for, even if the application code itself contains no calls to them.

F.ex. the methods called by an Inversion of Control framework, like the beginRender and afterRender  of Apache Tapestry; or the ones of an event-driven language, like the Form_Load of Visual Basic.

I was tempted to say Event handlers but I'm not sure it's correct to limit the concept to events; f.ex. in Tapestry a page rendering triggered by one event (like the click on a link) is composed of several phases and each phase has its own methods, and they get called by the framework; these phases occur in a predefined sequence, so it might be misleading for the reader of my comment if I call "event" each of them.

Sometimes Callback is suggested but I have the doubt that that only applies to a function that gets passed to other functions as an argument.

The only thing the functions / methods I'm talking about have in common is that they get called by the framework / compiler, regardless of whether the developer also codes explicit calls to it or not.

答:
They're just … functions. Functions that the rest of the code you've written is already using.

If you're writing an application, then these are already indistinguishable from functions that code you might write in the future will be using.

If you're writing a library, making them private (and optionally providing a public wrapper) is a good way to isolate "functions I'm providing to the library user" from "functions my library uses itself". I then like to call them "internal functions" but that's probably just me.

I will note, however, that the specific examples you've given in your question all happen to be handlers/callbacks/hooks, so if you're not actually hoping for a broader term, that'll do just fine.

Naming things is hard. Sometimes we describe a function based on how we're using it in that context. Sometimes we describe a function based on how it is typically used. Sometimes we describe a function based on how it should always be used. Coming up with a general rule to cover all of these things, without context, is close to pointless. Just make your documentation clear and unambiguous, using as many English words as you need, and you'll be fine.


答:
As others already pointed out, we do not normally assign an overarching name to these functions. I have heard all of these terms and seen them in action, but so far, no common name that crossed language/platform/framework boundaries seems to have emerged as far as I can tell. But I think it's a fine question nevertheless. As it was said, naming things is hard, but we all agree that it is also important, so here's my take on this:

Hooks are as @Kilian Foth pointed out quite the old-school term and indeed, I haven't heard that term in a long time. There's not really a reason why it went out of fashion as it is still valid, though I have to admit I never really liked the idea of a visual hook for this sort of concept.

Handlers have been named too, however, these do in general have a slightly different semantics in most of the cases I encountered them. Handlers are typically found in correspondence to user interactions (action / button handlers). Event handlers are a slightly more targeted term, which directly corresponds to events. Due to many domains explicictly modelling events, however, I also don't like that as a general term, since it can be confusing to have "event handlers" in the hook/callback sense, when there is no actual "event" involved.

Callbacks are close to hooks, but due to the term have a different directional emphasis. With a hook there is something existing and from the outside you hook into that, whereas a callback is something you pass along and at some time lateron, the other side will reach out to your callback. Other than that, callbacks have fallen out of fashion similarly to hooks with derogatory derived terms like "callback hell" coming to mind.

"Implicitly" is yet another term that already exists for such a case, yet has again a completely different semantics. Check out the Scala language, which offers "implicitly" as a direct language term even. Its meaning though is not that of a hook/callback/whatever we discuss here.

In addition to that, several frameworks do not even bother with names for this purpose. A typical case is the usage of f.ex. Java's reflection API. Consider the Beans standard, in which you have accessor methods (a.k.a. getters). Several frameworks call these methods automatically via reflection and they serve yet another purpose in contrast to all of the above.

As a consequence of this discussion, I would like to argue Obi-Wan-style, that this term is not what you're looking for. As we have seen, the different candidate terms have wildly differing semantics or reasons for being called automatically. It is even disputable what "automatic" means. Since naming is primarily a means to transport meaning, the very use of a term denoting  "automatically used function" is questionable.

As soon as you fix some of these variable semantical interpretation options (or if you prefer UML "semantic variation points") though, a term to identify your choices starts to make sense. That's why we do have hooks, event handlers, callbacks, implicit methods, property accessors and what-not. But each of these terms contains more information than the mere fact of "automatic calling", whatever that may be.

Title: What is the name for user-defined methods / functions that get called implicitly?

Body:
I want to mark such methods in my application code with a comment that highlights that these methods are expected to get called by the framework / compiler the application is written for, even if the application code itself contains no calls to them.

F.ex. the methods called by an Inversion of Control framework, like the beginRender and afterRender  of Apache Tapestry; or the ones of an event-driven language, like the Form_Load of Visual Basic.

I was tempted to say Event handlers but I'm not sure it's correct to limit the concept to events; f.ex. in Tapestry a page rendering triggered by one event (like the click on a link) is composed of several phases and each phase has its own methods, and they get called by the framework; these phases occur in a predefined sequence, so it might be misleading for the reader of my comment if I call "event" each of them.

Sometimes Callback is suggested but I have the doubt that that only applies to a function that gets passed to other functions as an argument.

The only thing the functions / methods I'm talking about have in common is that they get called by the framework / compiler, regardless of whether the developer also codes explicit calls to it or not.


问:
How to refine the architecture, look for better solutions and not to spoil relationship with the team?
TL;DR

What are the good practices of iterative search of a better solution?

Well, if I knew everything in advance and could immediately suggest 146% correct solution for a given context, I'd probably be the richest man in the world, but definitely I am not.

Thus some space and time for experimentation is needed.

In case of approaching some new technology or framework it's quite reasonable (if you have time for that) to create small prototype project specially for the purpose of testing its capabilities and exploration of caveats.

On the other side, changing architecture is more about how code is written and refactored. It's more about the system's evolution, ease of development and augmenting the product with new functionality. So I believe that these kind of changes is somewhat difficult to verify if abstracted from the real world development use cases. I also have doubts that business allows parallel development of several versions of the product just for developers could find better solution.

I see no other way but introduce changes while developing new features.

After several iterations stabilization is achieved and solution gets polished. But then system becomes a good example for Lava antipattern: you have several slightly differt approaches (Refactoring is to the help). Not surprisingly some teammates are going mad without clear understanding HOW should they do.

I do not want to constantly think how I should do this, I just need to
  complete the task. We have conventions, I get used to it.

That's what I hear quite often from a teammate.

Actually even setting access modifier of a classs to internal instead of public, or decision to use constructor injection instead of indeed incorrectly but widespread used property injection, or using Trace.WriteLine can cause the same reaction.

So the relationship with some of my teammates is worsening, and I don't want it to happen, but the same time I hate to do things in a way just because everyone got used to without questioning myself whether better, more correct solution exists. Yet I understand I am not perfect and inevitably make mistakes sometimes.

The claim of PM is that I do not initiate a discussion. But should I really ask for permission not to use Copy-Paste development and extract setup logic of the test?! Should I discuss whether I may use test data generator like Autofixture?

More recent example:

I finally could express what I strongly didn't like about our code. Our Get is developed both for the needs of UI and subsequent validation while updating; thus we reuse the entity (completely anemic model) returned by the Get when performing an Update. So whenever we need to change what we show in UI we also 'toutch' Update functionality. At least this requires to change unit tests.

I decided to check my guess and extracted query logic into another class and made this class not accessible by business rules where only command processing logic leaves. I also put validation logic inside the entity.

The reaction of a reviewer?

What the heck? Are we moving to CQRS? Have we discussed it? We do not
  use logic inside entities. Why query is merged with Db access logic (I
  simply return projections from EF query)?

Could I do better?

Face to face discusson showed that majority of the team considered this approach worth trying though without being completely sure it brings dividends later. And few members was strongly against it stating that reuse suffers, and get-logic is going to be somewhat duplicated if we need data from other entities (aggregates).

The best way to test the hypothesis is practice, isn't it?

The feature is isolated and still under development, and requirements for UI and functionality will change for several iterations. Al said allows to test safely the assumption about more stable codebase with this approach. Nonetheless, those who were against demand it to be refactored back to conventional solution.

答:
Make sure you only refactor in places of your code base where you have a reason for changing it which is comprehensible for everyone in your team (a reason like adding a new feature, fixing a bug, or improving performance). Use that occasions to improve the design, do not improve the design just for the better design's sake. That makes it much easier to justify design improvements against the rest of the team.

Refactoring is not an end in itself. When you write "And to be honest they are faster", that gives me a big warning sign. When refactoring does not help you to evolve your software faster, at least in the long run, then you are refactoring too much and your colleagues are correct.


问:
At what point is it taboo to have loops within loops?
Just curious. The most I have ever had was a for loop within a for loop, because after reading this from Linus Torvalds:

Tabs are 8 characters, and thus indentations are also 8 characters.
  There are heretic movements that try to make indentations 4 (or even
  2!) characters deep, and that is akin to trying to define the value of
  PI to be 3.

Rationale: The whole idea behind indentation is to clearly define
  where a block of control starts and ends.  Especially when you've been
  looking at your screen for 20 straight hours, you'll find it a lot
  easier to see how the indentation works if you have large
  indentations.

Now, some people will claim that having 8-character indentations makes
  the code move too far to the right, and makes it hard to read on a
  80-character terminal screen.  The answer to that is that if you need
  more than 3 levels of indentation, you're screwed anyway, and should
  fix your program.

https://www.kernel.org/doc/Documentation/CodingStyle

I figured it was an unacceptable practice for me to go to a third layer of looping, and would restructure my code (Primarily Qt).

Was Linus joking?

Does it depend on the language or application?

Are there some things which absolutely need three or more levels of looping?

答:
To a degree, I stopped taking this quote seriously at "Tabs are 8 characters". The whole point of tabulators is that they are not a fixed number of characters (if anything, a tab is one character). What a load of tosh. Similarly, I'm not completely convinced that setting a hard-and-fast rule of "three levels of indentation" is sane (as much as setting a hard-and-fast rule for anything is sane).

However, limiting your levels of indentation is in general a reasonable suggestion, and not one that should come as a surprise to you.

Ultimately, if your program needs three levels of iteration, that's what your program needs. The spirit of the quote is not to magically alleviate that requirement from your project, but to hive off logic into functions and types so that your code is terser and more expressive.

This just feeds back into the same guideline given above regarding indentation levels. It's about how you structure your code and keep it readable, maintainable and fun to modify for years to come.


答: The point is the same as for any flow-control constructs: if the code is hard to understand, you need to refactor it. If you're doing some simple manipulation of a multi-dimensional array, then having loops nested five or six deep may be appropriate, as long as the logic in the innermost loop is straightforward. However, if you're processing some complicated business logic and the body of your loop is a dozen lines or more, then you will probably not want to nest that more than one loop deep. You can try calculating the cyclomatic complexity of the code, but what it really comes down to is the readability and maintainability of the code in question.</p>

Title: At what point is it taboo to have loops within loops?

Body:
Just curious. The most I have ever had was a for loop within a for loop, because after reading this from Linus Torvalds:

Tabs are 8 characters, and thus indentations are also 8 characters.
  There are heretic movements that try to make indentations 4 (or even
  2!) characters deep, and that is akin to trying to define the value of
  PI to be 3.

Rationale: The whole idea behind indentation is to clearly define
  where a block of control starts and ends.  Especially when you've been
  looking at your screen for 20 straight hours, you'll find it a lot
  easier to see how the indentation works if you have large
  indentations.

Now, some people will claim that having 8-character indentations makes
  the code move too far to the right, and makes it hard to read on a
  80-character terminal screen.  The answer to that is that if you need
  more than 3 levels of indentation, you're screwed anyway, and should
  fix your program.

https://www.kernel.org/doc/Documentation/CodingStyle

I figured it was an unacceptable practice for me to go to a third layer of looping, and would restructure my code (Primarily Qt).

Was Linus joking?

Does it depend on the language or application?

Are there some things which absolutely need three or more levels of looping?


问:
Adding permission levels in Rails
So I'm making a bug tracker to help me learn Ruby on Rails. My current setup is something like this:

Each Project has_many :metadata and has_many :permissions, through: :metadata. Also some other stuff, but that's all that's relevant to this question.

Each Metadatum (bad name, I know, but it'll work for now) has_many :permissions, and belongs_to both :project and :person.

Each Permission belongs_to :metadatum, and both has_one :project, through: :metadatum and has_one :person, through: :metadatum. It represents one person being able to do one thing on one project -- for example, add a new bug, or assign someone to a bug, etc. etc.

Now, my question is if this is a good way to go about adding different levels of permission that are different for each project -- so, for example, Project Manager Eve can't edit Project Manager Bob's projects just because she's a PM too, and QA James can't add lots of bugs to a project he isn't supposed to be testing.

It makes sense to me because each project has metadata that applies to everyone (which is stored in Project) and individual metadata for each person (which is in Metadatum and includes stuff like if they've starred it or if they've assigned it a custom name). To me, it's sensible that Metadatum would also store the permission level, since that's dependent on the project and person both.

However, I'm concerned about space usage, though I don't know if I should be. It would be fairly trivial to change it to use some bitmasking magic to do the same thing, but my concern about that is that it's less readable, and only allows a certain amount of permissions to be added before running out of room in a number. I'm also concerned that it'll take longer to check if someone is allowed to do something than bitmasking, because instead of permission & 1<<12 you have to check project.permissions.find_by(person: person, allows: :allowance), which involves filtering twice, and isn't as readable. However, it's conceptually simpler to understand, and custom methods could easily be written to simplify the syntax.

Have I got the best approach? How can I do it better?

答:
Now, my question is if this is a good way to go about adding different levels of permission that are different for each project

It's an okay start, but will suffer if used with a larger number of users.  Permissions management is best handled through groups.  So the Dev_Group is allowed Permissions A, B, C and the IT_Admin_Group is allowed permissions C, and D on the same Project.

The benefit here is that when Ishmael leaves the project, he's simply removed from the IT_Admin_Group. And when Helena joins the team then she's added to the Dev_Group.  All of the necessary permissions are then automatically revoked or applied as the circumstances dictate.  Group management of permissions helps avoid the problem of accidentally forgetting to update an area.  And on large projects, that happens quite frequently when individual permissions are used instead of group permissions.

You can still use individual permissions to override the group settings if you'd like.  So if Helena was in a probationary period after joining, she may have Dev_Group permissions to A, B, C but an individual override to remove C.

However, I'm concerned about space usage, though I don't know if I should be.

At this stage in the development of your project, you shouldn't be worried about it.  Err on the side of readability and ease of maintenance above all else.  If / when this grows into a reasonably large project, you'll thank yourself a million times over when you have to maintain a section of code that you haven't touched in 6 months.

Likewise, in most environments where this would be used, memory utilization for permissions is not going to be a constraining factor.

I'm also concerned that it'll take longer to check if someone is allowed to do something than bit masking

Again, err on the side of readability and ease of maintenance.  If you do a proper job of encapsulating the implementation of the permissions checks then you'll be able to more easily refactor that section to a different approach when circumstances dictate a refactoring is necessary.  Said more clearly, permissions checks in a typical environment are not going to be your constraining factor for performance purposes.

Overall, your focus should be on getting the project to a working state so you're able to achieve the learning goals you wanted.  And while it's good to keep an eye on these considerations, getting it working is more important.  Once you've written a complete unit test suite for it, then you'll be able to more easily go in and refactor the sections that are still bothering you.

Title: Adding permission levels in Rails


答:
From the tone of your post, I'm going to guess that you lack empathy and flexibility. You're aghast at your teams' reaction, which suggests you can't imagine why they might feel the way they do. That's rough. It's going to be hard to implement change if you can't project yourself into their point of view.

Regarding flexibility, think about these statements:

"...setting access modifier of a classs to internal instead of public"

"...constructor injection instead of indeed incorrectly but widespread used property injection" (my emphasis)

"But should I really ask for permission not to use Copy-Paste development and extract setup logic of the test?! "

"Should I discuss whether I may use test data generator like Autofixture?"

I would respond:

While internal is better than public, it's still a bit dubious since internal is simply public local to the assembly. Many languages don't even both with it. So, did you break someone's code by changing access to internal? If not and they're simply uncomfortable with it, is this really an issue you need to champion? Do you want to burn up goodwill on something so trivial?

It's fine to have an opinion on constructor versus property injection and I might even agree with you. But I'll let you in on a secret: no where is it writ in stone that property injection is incorrect. That's just your opinion. Again, an opinion that I happen to agree with, but still an opinion. Please treat it as such.

Yes.

Yes.

All this boils down to a couple concepts. First, from my man André Gide:

"Trust those who seek the truth but doubt those who say they have
  found it."

You have strong opinions, that's great. Other people have opinions too. Please recognize them for what they are. Software development is beautiful and complex and weird, but it's definitely not black and white. You don't know the best way to do things. Not because you're dumb or wrong, but because it's impossible to know the best way to do something in such a subjective practice. If there was a "best way", best practices wouldn't be such a moving target. Think about how much things have changed in your career!

That's not to say we shouldn't strive for perfection. We should. But it's precisely because it's an enterprise that's doomed to fail that makes it so beautiful. (Kinda like human beings are beautiful because they're doomed to die.) So, what's the biggest requirement for teams who are striving for perfection? It's communication. That's the second concept; be an awesome communicator before you're an awesome programmer. Because to be honest, you can't be one without the other. (Unless maybe you're developing something completely on your own like TempleOS.) Any time you change a process or tool: communicate. Any time you significantly rework someone else's code: communicate. Listen to your spider-sense. If you sense someone will get annoyed, communicate.

With humility, a hunch for what's best, and good communication, you can make the changes that are best for your team.

Title: How to refine the architecture, look for better solutions and not to spoil relationship with the team?

Body:
TL;DR

What are the good practices of iterative search of a better solution?

Well, if I knew everything in advance and could immediately suggest 146% correct solution for a given context, I'd probably be the richest man in the world, but definitely I am not.

Thus some space and time for experimentation is needed.

In case of approaching some new technology or framework it's quite reasonable (if you have time for that) to create small prototype project specially for the purpose of testing its capabilities and exploration of caveats.

On the other side, changing architecture is more about how code is written and refactored. It's more about the system's evolution, ease of development and augmenting the product with new functionality. So I believe that these kind of changes is somewhat difficult to verify if abstracted from the real world development use cases. I also have doubts that business allows parallel development of several versions of the product just for developers could find better solution.

I see no other way but introduce changes while developing new features.

After several iterations stabilization is achieved and solution gets polished. But then system becomes a good example for Lava antipattern: you have several slightly differt approaches (Refactoring is to the help). Not surprisingly some teammates are going mad without clear understanding HOW should they do.

I do not want to constantly think how I should do this, I just need to
  complete the task. We have conventions, I get used to it.

That's what I hear quite often from a teammate.

Actually even setting access modifier of a classs to internal instead of public, or decision to use constructor injection instead of indeed incorrectly but widespread used property injection, or using Trace.WriteLine can cause the same reaction.

So the relationship with some of my teammates is worsening, and I don't want it to happen, but the same time I hate to do things in a way just because everyone got used to without questioning myself whether better, more correct solution exists. Yet I understand I am not perfect and inevitably make mistakes sometimes.

The claim of PM is that I do not initiate a discussion. But should I really ask for permission not to use Copy-Paste development and extract setup logic of the test?! Should I discuss whether I may use test data generator like Autofixture?

More recent example:

I finally could express what I strongly didn't like about our code. Our Get is developed both for the needs of UI and subsequent validation while updating; thus we reuse the entity (completely anemic model) returned by the Get when performing an Update. So whenever we need to change what we show in UI we also 'toutch' Update functionality. At least this requires to change unit tests.

I decided to check my guess and extracted query logic into another class and made this class not accessible by business rules where only command processing logic leaves. I also put validation logic inside the entity.

The reaction of a reviewer?

What the heck? Are we moving to CQRS? Have we discussed it? We do not
  use logic inside entities. Why query is merged with Db access logic (I
  simply return projections from EF query)?

Could I do better?

Face to face discusson showed that majority of the team considered this approach worth trying though without being completely sure it brings dividends later. And few members was strongly against it stating that reuse suffers, and get-logic is going to be somewhat duplicated if we need data from other entities (aggregates).

The best way to test the hypothesis is practice, isn't it?

The feature is isolated and still under development, and requirements for UI and functionality will change for several iterations. Al said allows to test safely the assumption about more stable codebase with this approach. Nonetheless, those who were against demand it to be refactored back to conventional solution.


答:
This would appear to be a textbook case of the tail wagging the dog.

If you have an 80 character display then of course you are going to try and make the code fit as best you can even if it doesn't produce the best structure for the code.

Tackling the remainder of your points head on:

I figured it was an unacceptable practice.

I think you're reading too much into this. Resist the urge to take everything you read as gospel without properly understanding the context.

Was he joking?

Hard to ascertain the context, but see my original point above.

Does it depend on the language or application?

Very much so. Take any mainframe/midrange language where you're likely to be coding on a terminal (or terminal emulator).

Are there some things which absolutely need three or more levels of looping?

Yes, it is very common in some brute force algorithms. See Problem 31 on Project Euler. This is a classic example of a problem that could be solved with brute force using a number of loops (8 to be exact).


答:
You're thinking in terms of a programmer, and rightly so, but there are other aspects to take into consideration.

Refactoring code is costly.  It is true that you're already dedicating your time to writing to code, so why should it be a cost if it is only meant to help the project?  Well for one, it isn't helping the project unless it is a calculated and deliberate effort.  If you go against the flow of your project, you're not helping despite what you think to the contrary.  And either an enormous effort with no immediate gain has to be made to push it forward or an enormous effort with no change has to be made to restore it to its original glory.  All of this brings no external benefits to the project and thus is very hard to justify to one that doesn't program at all (aka the project manager's boss who's quite possibly paying for all of this development).

Consistency is key.  This somewhat falls in line with the above comment, with emphasis on what it means to have consistent code and inconsistent code.  On one hand, code corrections are straightforward, at least from the perspective of where to insert it in your program, and at least nobody can say that it's not orderly.  That isn't to say that it is ordered to your standards, but that is irrelevant.  Consistency has its own value.  An inconsistent project is a nightmare to work with.  Despite having some possibly positive merits with some techniques, it is like having poo-flavored sprinkles on your ice cream.  Nobody wants something that's a mix of good and bad components.

Your role is advisor when it comes to technical decisions.  You're right to want the technique to change, and it is, in fact, your duty as a programmer to at least present it as a possibility.  That said, not everything is black and white, and other programmers will disagree with you.  Take it with a grain of salt and know that it can be you every once and a while the one who is in the wrong.  It would be incorrect to stay silent and even moreso to impose yourself on your colleagues.

The best way to test a technique is to practice.  It isn't sufficient to hear some buzzword and try to apply it to your program.  If you're not confident with that technique, then you shouldn't propose it to your colleagues at least until you're sure it fits your program, and unfortunately the only way to know this is to use it in other circumstances.  Work is no place to test these techniques, but you can write projects at home and test your techniques there.

My advice is to treat your fellow programmers with respect and respect will be likewise given.  If you think something is worth mentioning, mention it in earnest and they will listen.  Also don't take it to heart if they decide not to adopt your approach.  It is still only business afterall.


答:
Linus has a very blunt speaking style, and a dry sense of humor, but he was not joking in this instance.  There are situations where an algorithm needs nesting deeper than two levels, but you can accomplish this using other means than indenting your code.  The Linux kernel style guide strongly prefers these other methods, because of the difficulty of maintaining deeply nested loops, and that is what Linus is saying here.

For some examples of alternative methods, you can use recursion, split off inner loops into their own functions, or make intermediate data structures.

Excessive nesting is one of those cases that's easier to write, but harder to read.  Setting a large tab depth is Linus' way of making it more annoying to write too.


问:
How do large corporations store API keys?
When FaceBook or Google give me an API key, are they just storing it in a database?

Unlike a password, where you can hash and salt it before putting it in the database, it seems to me that a key needs to be stored as-is (or else in a reversible form) so that they can provide it to me upon request.

My concern is with storing immediately usable information in my databases.

I understand that the exact method these companies use is only speculation, unless you are a past employee or have unique insider information, but I'm wondering if there is a most commonly accepted best-practice.

答:
API keys are technically just long passwords. It's altogether possible that a service provider would compute a new key, include it in an email to you, salt it, hash it, store the hash and then throw away the original. </p>

<p>(If you re-request it they can just re-generate a new key and send that - who's going to complain? Certainly not you, since you just declared that you don't know the old key anymore.)</p>

Body:
API keys are technically just long passwords. It's altogether possible that a service provider would compute a new key, include it in an email to you, salt it, hash it, store the hash and then throw away the original.

(If you re-request it they can just re-generate a new key and send that - who's going to complain? Certainly not you, since you just declared that you don't know the old key anymore.)


答: There are many questions where the advice is different for someone asking the question than for someone who doesn't ask. If you ask "Should I ever have loops that are nested more than two levels deep" then for you, the person asking that question, the answer is NO. If you ask, then don't do it. If you have enough experience that you don't need to ask, then you know what's the correct answer in each case. And don't argue if you don't agree with the answer, because the answer is not for you. </p>


答:
The kernel strongly prefers simple algorithms

While a variety of algorithms may require deeply nested loops within loops, in context of the Linux kernel (in which the quote was said) you generally need quick real time responses. In that context, deep nesting is a smell that may indicate that the code flow is too complex for this domain and may needs to be changed because of it's execution characteristics, not readability or indentation issues.

Furthermore, Linux kernel is different from most application code as for the requirements of auditability and testing - and thus would prefer to not have a 4+ level nested algorithm in a single function. It should be obvious to see what each code fragment does exactly and in detail, including all the possible control flow and edge cases. Deeply nested code hampers that.


问:
why use authentication token instead of session_id for app(android side) in REST API
in normal php web application after login we use session_id that came from web browser to check if user loged in or not.

But in REST API authentication I read some tutorials that say php should send back authentication "token" for android app to save it and give it back to php server for every request.

my question is why should I send back some authentication token instead of session_id? I can send back session_id by android app and do normal session stuff on php server side.

ps. if my question is not clear tell then I explain more.

答: The purpose of a session id is to maintain "state" of the application across requests. In REST, APIs are designed specifically to resist this kind of state. Each request is considered self-contained against a resource and should be independent of any specific application state. While the session id may be used similarly to an authentication token, its purpose is not similar. An authentication token performs a confirmed authentication/authorization with each request. A session id continues to live on the server across multiple requests which violates rest. </p>


问:
Is individual code ownership important?
I'm in the midst of an argument with some coworkers over whether team ownership of the entire codebase is better than individual ownership of components of it.

I'm a huge proponent of assigning every member of the team a roughly equal share of the codebase. It lets people take pride in their creation, gives the bug screeners an obvious first place to assign incoming tickets, and helps to alleviate "broken window syndrome".

It also concentrates knowledge of specific functionality with one (or two) team members making bug fixes much easier.

Most of all, it puts the final say on major decisions with one person who has a lot of input instead of with a committee.

I'm not advocating for requiring permission if somebody else wants to change your code; maybe have the code review always be to the owner, sure. Nor am I suggesting building knowledge silos: there should be nothing exclusive about this ownership.

But when suggesting this to my coworkers, I got a ton of pushback, certainly much more than I expected.

So I ask the community: what are your opinions on working with a team on a large codebase? Is there something I'm missing about vigilantly maintaining collective ownership?

答:
Jim, I'm with you on that one 100%. I'm in the midst of exactly the same battle in my place of work -- which is why I stumbled across your question.

The way I see it is: "when everybody owns it, nobody owns it".

To me, there is no single more important factor to code quality than ownership and responsibility.

Example from real life illustrate this well. which would you take care better: your private lawn or the community's park? Pretty obvious.

That does not, by the way, necessarily has to be traded off for "team flexibility". It merely means that when a person owns something he OWNS it -- and if only for the day.

ContentLicense: CC BY-SA 2.5

Title: Is individual code ownership important?


问:
Is equating a variable to a function that takes the same variable bad programming?
Is it improper programming to set a variable equal to the result of a function that accepts the same variable? The languages in question here are c#, javascript and PHP (not sure if this works in C families, personally).</p>

```<code>var a = 1;
a = alterData(a);
</code>```

答:
"Improper" how?

It is not illegal - that is, it's not a syntax violation in any language with mutable variables that I'm aware of.

It is not broken - that is, the post-condition of the expression will be the result of the function, and barring some weird concurrency effects be nice and consistent.

It's not ugly or non-idiomatic. In pretty much all languages I'm familiar with (that have mutable variables), this sort of thing is considered readable and a fine thing to do as long as a still means the same thing. Reusing a for some other semantic concept (like it is velocity for the first half of the function and acceleration for the second half) is not good.

If anything, programmers are moving more towards this form of programming and away from alterData(a) that uses side effects to change a under the covers.

So go right ahead.


答:
To me it depends on the dynamics of your team.

For example, if you have a team which isn't unified by standards, peer review, methodical testing, or if you have a team where the competence levels vary wildly among the members, it might be good to seek a stronger notion of code ownership with a more black-box modular mindset.

Lacking this, for example, your carefully-designed interface conforming to SOLID principles might quickly be ruined by someone who doesn't even know "SOLID" means and wants to add new eclectic functions all the time to the interface for "convenience", e.g. This is, by far, the worst.

You might also deal with sloppy co-workers whose idea of fixing a bug is fixing the symptom without understanding the root problem (ex: trying to respond to a crash report by simply putting workarounds in the code only to hide the bug and transfer the deadly side effects to someone else). In that case, it's not quite as bad as interface design sabotage and you can protect your intentions with carefully-constructed unit tests.

The ideal solution is to tighten up your team though to a point where this notion of authorship and ownership no longer become so important. Peer reviewing isn't just about improving code quality, it's also about improving teamwork. Standards aren't just about consistency, they improve teamwork.

Yet there are scenarios where peer review and actually having everyone conform to a standard is just hopeless and will bring a lot of hopelessly-inexperienced critics into the mix. I'd say a lot of whether code ownership or team ownership takes a stronger priority will be based on your team's ability to actually perform an effective peer review and actually leave everyone coming out like they benefited from it (both in terms of the review itself, and becoming closer together in mindset and standards as a result). In large, loose, and/or disparate teams, this might seem hopeless. If your team can function like a "squad" where you can barely even tell who wrote what, then sole ownership will start to seem like a silly notion.

In these kinds of far-from-ideal scenarios, this notion of code ownership may actually help. It's trying to make good of a worst-case scenario, but it can help if teamwork is generally hopeless to put a fence around an author's code. In that case, it's diminishing teamwork but that can be better if "teamwork" only leads to toe-stepping.

Title: Is individual code ownership important?

Body:
I'm in the midst of an argument with some coworkers over whether team ownership of the entire codebase is better than individual ownership of components of it.

I'm a huge proponent of assigning every member of the team a roughly equal share of the codebase. It lets people take pride in their creation, gives the bug screeners an obvious first place to assign incoming tickets, and helps to alleviate "broken window syndrome".

It also concentrates knowledge of specific functionality with one (or two) team members making bug fixes much easier.

Most of all, it puts the final say on major decisions with one person who has a lot of input instead of with a committee.

I'm not advocating for requiring permission if somebody else wants to change your code; maybe have the code review always be to the owner, sure. Nor am I suggesting building knowledge silos: there should be nothing exclusive about this ownership.

But when suggesting this to my coworkers, I got a ton of pushback, certainly much more than I expected.

So I ask the community: what are your opinions on working with a team on a large codebase? Is there something I'm missing about vigilantly maintaining collective ownership?


答:
Was Linus joking?

No, those are the official guidelines.

Does it depend on the language or application?

Coding guidelines are generally dependent on the language and application, however deeply nested code always taxes the reader.

The issue with nested code is that in general it increases cyclomatic complexity: that is, the more nested the code is, the more potential execution paths exist within the function. A combinatorial explosion of potential execution paths makes it difficult to reason about the code, and therefore should be avoided in general.

So why 3? A subjective coding guideline is both hard to enforce and impossible to enforce automatically. Setting up an objective coding guideline on the maximum level of indentation requires agreeing on a number: in the Linux kernel they picked 3.

It's arbitrary, and apparently sufficient for them.

Are there some things which absolutely need three or more levels of looping?

Algorithm-wise, probably, however in sufficiently expressive languages you can always refactor the code into smaller chunks (whether with functions or closures).

You can obviously write obfuscated code with little nesting and lots of small functions calling each other without ever spelling their contract...

... however, small functions with clear contracts are much easier to audit than large functions with clear contracts in general.


问:
How can I reduce http request while I have hundreds of images and thousands of users
I need an idea or concept how to reduce http request.

Conditions:

1000s of users(android/iphone) active

100s of small images (150kb/image) to be fetched

Simply by giving each image a hardcoded link, server will have to handle 100 * 1000 http requests.
How could I minimize the requests?

答:
You can't decrease the request count. Not really. HTTP is one response per request (and this is one of the reasons for HTTP/2).

What you CAN do is decrease the number of requests that hit a given server.

I'd first solve this using a CDN for your images. This will make them the CDN's problem, one they're prepared to handle by distributing the images over many servers behind a load balancer. The easiest way to get started with a CDN is to host images on S3, as described in How to Configure Amazon S3 as a Content Delivery Network

Similarly, if you can't use a CDN service for some reason you can bake your own by adding a load balancer in front of your site and shedding requests for images onto a server designed to serve many long lived connections concurrently. NGINX is a good one. Again, you won't decrease requests, but you will decrease the requests that hit your app server and your users will get their images faster than if they had to wait in a request queue on an app server.

BTW, 150k is NOT a "small image." 100s of those per user is a 15 MB download. If you're doing this on mobile, you're gonna have a slow site and pissed off users no matter what you do.


答:
First, you should try to use meaningful variable names.  In this case, you might have original_a and altered_a (where a should be something relevant, of course).

Second, the cost of a local variable is minimal  in most programming languages (and sometimes zero), so feel free to use them.

Third, using the functional style of immutable variables (assigned once) has merit. Apple's Swift, for example, is a modern language that is encouraging single variable assignment.  Some might argue programs are easier to read/maintain when local variables are not modified; you can see the value of the old and new in the debugger, and if something is amiss, it is easier to see where.

So, I say no, it is better to introduce another variable.

Title: Is equating a variable to a function that takes the same variable bad programming?

Body:
Is it improper programming to set a variable equal to the result of a function that accepts the same variable? The languages in question here are c#, javascript and PHP (not sure if this works in C families, personally).</p>

```<code>var a = 1;
a = alterData(a);
</code>```


问:
Microservices and isolated data storage models
I have been looking at Microservices for a while now. The concept is not new but it's communicated in a lightweight manner. So, I am very excited about this.

However, there is a question that I am not sure what the answer is: is each microservice supposed to have its own isolated data storage model completely? Consider the below:

Note: This is probably not a good example as the seperation here is done based on read/writes whereas the good approach would be to separate the business concerns.

products-write-service: responsible for dealing with creation and edits of the products. Knows MongoDB and writes data to there.

products-lookup-service: responsible for dealing with retrieving products by their identifiers, providing basic listing of products based on categories, etc. Knows MongoDB and reads data from there.

products-search-service: responsible for dealing with search requests on products. Knows Elasticsearch and reads data from there.

Here, we have two separate data storage techs between three services. However:

products-write-service and products-lookup-service works on the same data storage model. There is a tried relationship between two services.

at the end of the day, there should be a process to do ETL from MongoDB to Elasticsearch for products-search-service to function. In some sense, three microservices have their own data storage model but there is a middle process which knows about these two models.

What do you say about this model? Is the separation completely wrong here?

答:
I think that each service should have its own storage. Otherwise you're missing a point of (micro-)services - you can't quickly evolve the service if you're limited by storage shared with other service.

Why are you splitting read and write logic into separate services? That's a bit of a smell for me.

There's nothing saying that a service couldn't have multiple storages. Maybe you're looking at a single service with multiple storages? Updating a product could result in simultaneous updates to both MongoDB and ES.

Based on a limited domain knowledge I would provision 2 services: Product Catalog with MongoDB and Product Search with ES as backend. How you transfer data between services is a separate question:

ETL as you've suggested (would have to understand both storages - quick and dirty)

Domain Events - Product Search service could subscribe to events published from Product Catalog service (that would be my preferred choice)

Batch process that would use services' API instead of going directly to the storage (probably better than 1. but will require developing richer APIs)


答:
Well, the best analogy is encapsulation and Data-Hiding in OOP.

The only way you can interact with the state of the object is through its public interface. In the same manner, the only way you should be able to interact with the data of a (micro)service must be through its public API. Having said that, (micro)services often events that other services could subscribe to.

As such, read and write services are very much the same (micro)service as they access the same data source.

So what is the difference with the classic SOA? Well, not a lot here. But if you start breaking Product Catalog into its different aspects then services will be smaller. For example a classic SOA customer service stores everything related to customer but in a Microservice world, the address goes to one service while preferences got to one or more services.

But not all microservices have a data store. Some Microservices are composition services which aggregate the data from multiple service (enrich) and represent a more usable facade. Also some Microservices encapsulate an algorithm and do not have any data as such, perhaps some configuration only.

Hope this helps.

Title: Microservices and isolated data storage models

Body:
I have been looking at Microservices for a while now. The concept is not new but it's communicated in a lightweight manner. So, I am very excited about this.

However, there is a question that I am not sure what the answer is: is each microservice supposed to have its own isolated data storage model completely? Consider the below:

Note: This is probably not a good example as the seperation here is done based on read/writes whereas the good approach would be to separate the business concerns.

products-write-service: responsible for dealing with creation and edits of the products. Knows MongoDB and writes data to there.

products-lookup-service: responsible for dealing with retrieving products by their identifiers, providing basic listing of products based on categories, etc. Knows MongoDB and reads data from there.

products-search-service: responsible for dealing with search requests on products. Knows Elasticsearch and reads data from there.

Here, we have two separate data storage techs between three services. However:

products-write-service and products-lookup-service works on the same data storage model. There is a tried relationship between two services.

at the end of the day, there should be a process to do ETL from MongoDB to Elasticsearch for products-search-service to function. In some sense, three microservices have their own data storage model but there is a middle process which knows about these two models.

What do you say about this model? Is the separation completely wrong here?


答:
A sprite sheet is a series of images combined into a single image. This enables the content to be obtained once and cached by the user in a single request.

There are numerous tools able to create sprite sheets.

Stitches - an HTML5 based site sheet generator

Compass is a CSS preprocessor that also supports the creation of sprite sheets.

See this jsfiddle for implementation details:

Due to the large size of your individual images, your sprite sheet will be very large. Ensure your images are optimized for the web and set your caching headers correctly.

See Google Developers Web Fundamentals for image optimization for additional information on proper image optimization.

Title: How can I reduce http request while I have hundreds of images and thousands of users

Body:
I need an idea or concept how to reduce http request.

Conditions:

1000s of users(android/iphone) active

100s of small images (150kb/image) to be fetched

Simply by giving each image a hardcoded link, server will have to handle 100 * 1000 http requests.
How could I minimize the requests?


答:
Was Linus joking?

The piece is written in a playful style which suggests that the author is familiar with the way coding style is discussed among serious practitioners: We all have our preferences, and we defend them rabidly, but with tongue at least partially in cheek. We understand perfectly well that much of it is just a matter of personal taste. He says, in so many words, "Coding style is very personal, and I won't _force_ my views on anybody" -- at least outside of code he personally maintains. But consistency of style in a given project is a very good idea. I'd much rather code to a style I dislike than deal with multiple styles in a given function.

Here's an example of clearly playful writing:

```<code>However, there is one special case, namely functions: they have the
opening brace at the beginning of the next line, thus:

int function(int x)
{
    body of function
}

Heretic people all over the world have claimed that this inconsistency
is ...  well ...  inconsistent, but all right-thinking people know that
(a) K&R are _right_ and (b) K&R are right.  Besides, functions are
special anyway (you can't nest them in C).
</code>```

Playful(1).

It's arguably good advice to try to keep indenting from getting out of control, though a three level maximum might be hyperbolic. I'm not going to grep the kernel source and count sequences of four tab characters, but I'd bet money you could find at least one that Torvalds wrote.

On the other hand, if somebody can write the Linux kernel without often exceeding three levels of indenting, a three-level limit might be an exercise worth trying out for a while in your own code, just to see where it takes you. This isn't like a sex change, you know. It's not a lifetime commitment.

If you run into somebody on the Internet who thinks he understands programming much better than Torvalds(2), well, you know what kind of people like to talk big on the Internet.

On the other hand, he is criminally wrong about eight-space tabs. That is the raving of a man who should be kept in restraints and fed through a slot. Four spaces is obviously correct.

(1) But note how he erroneously puts a space before the ellipses, and two spaces after them, and two spaces after a full stop. WRONG, WRONG, WRONG. And then he has the brazen gall to castigate heretics. The heretic is you, Torvalds! IT IS YOU!

(2) If you want to talk about "understanding how to design a source control system", there might be some room for debate.

Note: Dear fellow user who has repeatedly submitted the same edit: The formatting in the quoted material is kept exactly as the author meant for it to be. That's because it's from an essay about the formatting of fixed-width text, written in fixed width text, by somebody who has given the formatting of fixed width text a fair amount of thought. The formatting is a conscious and deliberate part of the author's intent, and it's relevant to the subject.

In addition, I referred back to that formatting in my own text. If you take out the pre-formatting, my footnote (1) becomes gibberish. If the pre-formatting is removed, so should be the text in my footnote (1) referring to the pairs of spaces after the full stops at the ends of sentences. I can see a rationale for removing that footnote anyway, on account of it being less funny than it seemed when I wrote it. But to remove the formatting without removing the footnote is unhelpful.

Body:
Was Linus joking?

The piece is written in a playful style which suggests that the author is familiar with the way coding style is discussed among serious practitioners: We all have our preferences, and we defend them rabidly, but with tongue at least partially in cheek. We understand perfectly well that much of it is just a matter of personal taste. He says, in so many words, "Coding style is very personal, and I won't _force_ my views on anybody" -- at least outside of code he personally maintains. But consistency of style in a given project is a very good idea. I'd much rather code to a style I dislike than deal with multiple styles in a given function.

Here's an example of clearly playful writing:

However, there is one special case, namely functions: they have the
opening brace at the beginning of the next line, thus:

int function(int x)
{
    body of function
}

Heretic people all over the world have claimed that this inconsistency
is ...  well ...  inconsistent, but all right-thinking people know that
(a) K&R are _right_ and (b) K&R are right.  Besides, functions are
special anyway (you can't nest them in C).

Playful(1).

It's arguably good advice to try to keep indenting from getting out of control, though a three level maximum might be hyperbolic. I'm not going to grep the kernel source and count sequences of four tab characters, but I'd bet money you could find at least one that Torvalds wrote.

On the other hand, if somebody can write the Linux kernel without often exceeding three levels of indenting, a three-level limit might be an exercise worth trying out for a while in your own code, just to see where it takes you. This isn't like a sex change, you know. It's not a lifetime commitment.

If you run into somebody on the Internet who thinks he understands programming much better than Torvalds(2), well, you know what kind of people like to talk big on the Internet.

On the other hand, he is criminally wrong about eight-space tabs. That is the raving of a man who should be kept in restraints and fed through a slot. Four spaces is obviously correct.

(1) But note how he erroneously puts a space before the ellipses, and two spaces after them, and two spaces after a full stop. WRONG, WRONG, WRONG. And then he has the brazen gall to castigate heretics. The heretic is you, Torvalds! IT IS YOU!

(2) If you want to talk about "understanding how to design a source control system", there might be some room for debate.

Note: Dear fellow user who has repeatedly submitted the same edit: The formatting in the quoted material is kept exactly as the author meant for it to be. That's because it's from an essay about the formatting of fixed-width text, written in fixed width text, by somebody who has given the formatting of fixed width text a fair amount of thought. The formatting is a conscious and deliberate part of the author's intent, and it's relevant to the subject.

In addition, I referred back to that formatting in my own text. If you take out the pre-formatting, my footnote (1) becomes gibberish. If the pre-formatting is removed, so should be the text in my footnote (1) referring to the pairs of spaces after the full stops at the ends of sentences. I can see a rationale for removing that footnote anyway, on account of it being less funny than it seemed when I wrote it. But to remove the formatting without removing the footnote is unhelpful.


问:
Does low latency code sometimes have to be "ugly"?
(This is mainly aimed at those who have specific knowledge of low latency systems, to avoid people just answering with unsubstantiated opinions).

Do you feel there is a trade-off between writing "nice" object orientated code and writing very fast low latency code? For instance, avoiding virtual functions in C++/the overhead of polymorphism etc- re-writing code which looks nasty, but is very fast etc?

It stands to reason- who cares if it looks ugly (so long as its maintainable)- if you need speed, you need speed?

I would be interested to hear from people who have worked in such areas.

答:
Do you feel there is a trade-off between writing "nice" object
  orientated code and writing very fast low latency code? For instance,
  avoiding virtual functions in C++/the overhead of polymorphism etc-
  re-writing code which looks nasty, but is very fast etc?

I work in a field which is a bit more focused on throughput than latency, but it's very performance-critical, and I'd say "sorta".

Yet a problem is that so many people get their notions of performance completely wrong. Novices often get just about everything wrong, and their entire conceptual model of "computational cost" needs reworking, with only algorithmic complexity being about the only thing they can get right. Intermediates get a lot of things wrong. Experts get some things wrong.

Measuring with accurate tools that can provide metrics like cache misses and branch mispredictions is what keeps all people of any level of expertise in the field in check.

Measuring is also what points out what not to optimize. Experts often spend less time optimizing than novices, since they're optimizing true measured hotspots and not trying to optimize wild stabs in the dark based on hunches about what could be slow (which, in extreme form, could tempt one to micro-optimize just about every other line in the codebase).

Designing for Performance

With that aside, the key to designing for performance comes from the design part, as in interface design. One of the problems with inexperience is that there tends to be an early shift on absolute implementation metrics, like the cost of an indirect function call in some generalized context, as though the cost (which is better understood in an immediate sense from an optimizer's point of view rather than a branching point of view) is a reason to avoid it throughout the entire codebase.

Costs are relative. While there is a cost to an indirect function call, e.g., all costs are relative. If you're paying that cost one time to call a function which loops through millions of elements, worrying about this cost is like spending hours haggling over pennies for the purchase of a billion dollar product, only to conclude not to buy that product because it was one penny too expensive.

Coarser Interface Design

The interface design aspect of performance often seeks earlier on to push these costs to a coarser level. Instead of paying runtime abstraction costs for a single particle, for example, we might push that cost to the level of the particle system/emitter, effectively rendering a particle into an implementation detail and/or simply raw data of this particle collection.

So object-oriented design doesn't have to be incompatible with designing for performance (whether latency or throughput), but there can be temptations in a language that focuses on it to model increasingly teeny granular objects, and there the latest optimizer can't help. It can't do things like coalesce a class representing a single point in a way that yields an efficient SoA representation for the memory access patterns of the software. A collection of points with the interface design modeled at the level of coarseness offers that opportunity, and allows iterating towards more and more optimal solutions as needed. Such a design is designed for bulk memory *.

* Note the focus on memory here and not data, as working in performance-critical areas for a long time will tend to change your view of data types and data structures and seeing how they connect to memory. A binary search tree no longer becomes solely about logarithmic complexity in such cases as possibly-disparate and cache-unfriendly memory chunks for tree nodes unless aided by a fixed allocator. The view does not dismiss algorithmic complexity, but it sees it no longer independently of memory layouts. One also starts to see iterations of work as being more about iterations of memory access.*

A lot of performance-critical designs can actually be very compatible with the notion of high-level interface designs that are easy for humans to understand and use. The difference is that "high-level" in this context would be about bulk aggregation of memory, an interface modeled for potentially large collections of data, and with an implementation under the hood that may be quite low-level. A visual analogy might be a car that's really comfortable and easy to drive and handle and very safe while going at the speed of sound, but if you pop the hood, there's little fire-breathing demons inside.

With a coarser design also tends to come an easier way to provide more efficient locking patterns and exploit parallelism in the code (multithreading is an exhaustive subject that I'll kind of skip here).

Memory Pool

A critical aspect of low-latency programming is probably going to be a very explicit control over memory to improve locality of reference as well as just the general speed of allocating and deallocating memory. A custom allocator pooling memory actually echoes the same kind of design mindset we described. It's designed for bulk; it's designed at a coarse level. It preallocates memory in large blocks and pools the memory already-allocated in small chunks.

The idea is exactly the same of pushing costly things (allocating a memory chunk against a general-purpose allocator, e.g.) to a coarser and coarser level. A memory pool is designed for dealing with memory in bulk.

Type Systems Segregate Memory

One of the difficulties with granular object-oriented design in any language is that it often wants to introduce a lot of teeny user-defined types and data structures. Those types can then want to be allocated in little teeny chunks if they're dynamically allocated.

A common example in C++ would be for cases where polymorphism is required, where the natural temptation is to allocate each instance of a subclass against a general-purpose memory allocator.

This ends up breaking apart possibly-contiguous memory layouts into little itsy-bitsy bits and pieces scattered across the addressing range which translates to more page faults and cache misses.

Fields that demand the lowest-latency, stutter-free, deterministic response are probably the one place where hotspots don't always boil down to a single bottleneck, where tiny inefficiencies can actually genuinely kind of "accumulate" (something a lot of people imagine happening incorrectly with a profiler to keep them in check, but in latency-driven fields, there can actually be some rare cases where tiny inefficiencies accumulate). And a lot of the most common reasons for such an accumulation can be this: the excessive allocation of teeny chunks of memory all over the place.

In languages like Java, it can be helpful to use more arrays of plain old data types when possible for bottlenecky areas (areas processed in tight loops) such as an array of int (but still behind a bulky high-level interface) instead of, say, an ArrayList of user-defined Integer objects. This avoids the memory segregation that would typically accompany the latter. In C++, we don't have to degrade the structure quite as much if our memory allocation patterns are efficient, as user-defined types can be allocated contiguously there and even in the context of a generic container.

Fusing Memory Back Together

A solution here is to reach for a custom allocator for homogeneous data types, and possibly even across homogeneous data types. When tiny data types and data structures are flattened to bits and bytes in memory, they take on a homogeneous nature (albeit with some varying alignment requirements). When we don't look at them from a memory-centric mindset, the type system of programming languages "want" to split/segregate potentially-contiguous memory regions apart into little teeny scattered chunks.

The stack utilizes this memory-centric focus to avoid this and potentially store any possible mixed combination of user-defined type instances inside of it. Utilizing the stack more is a great idea when possible as the top of it is almost always sitting in a cache line, but we can also design memory allocators that mimic some of these characteristics without a LIFO pattern, fusing memory across disparate data types into contiguous chunks even for more complex memory allocation and deallocation patterns.

Modern hardware is designed to be at its peak when processing contiguous blocks of memory (repeatedly accessing the same cache line, the same page, e.g.). The keyword there is contiguity, as this is only beneficial if there's surrounding data of interest. So a lot of the key (yet also difficulty) to performance is to fuse segregated chunks of memory back together again into contiguous blocks that are accessed in their entirety (all surrounding data being relevant) prior to eviction. The rich type system of especially user-defined types in programming languages can be the biggest obstacle here, but we can always reach around and solve the problem through a custom allocator and/or bulkier designs when appropriate.

Ugly

"Ugly" is hard to say. It's a subjective metric, and someone who works in a very performance-critical field will start to change their idea of "beauty" to one that's a lot more data-oriented and focuses on interfaces that process things in bulk.

Dangerous

"Dangerous" might be easier. In general, performance tends to want to reach towards lower-level code. Implementing a memory allocator, for example, is impossible without reaching beneath data types and working at the dangerous level of raw bits and bytes. As a result, it can help to increase the focus on careful testing procedure in these performance-critical subsystems, scaling the thoroughness of testing with the level of optimizations applied.

Beauty

Yet all of this would be at the implementation detail level. In both a veteran large-scale and performance-critical mindset, "beauty" tends to shift towards interface designs rather than implementation details. It becomes an exponentially higher priority to seek "beautiful", usable, safe, efficient interfaces rather than implementations due to coupling and cascading breakages that can occur in the face of an interface design change. Implementations can be swapped out any time. We typically iterate towards performance as needed, and as pointed out by measurements. The key with the interface design is to model at a coarse enough level to leave room for such iterations without breaking the entire system.

In fact, I would suggest that a veteran's focus on performance-critical development will often tend to place a predominant focus on safety, testing, maintainability, just the disciple of SE in general, since a large-scale codebase which has a number of performance-critical subsystems (particle systems, image processing algorithms, video processing, audio feedback, raytracers, mesh engines, etc) will need to pay close attention to software engineering to avoid drowning in a maintenance nightmare. It's by no mere coincidence that often the most astonishingly-efficient products out there can also have the fewest number of bugs.

TL;DR

Anyway, that's my take on the subject, ranging from priorities in genuinely performance-critical fields, what can reduce latency and cause tiny inefficiencies to accumulate, and what actually constitutes "beauty" (when looking at things most productively).


问:
Dependency Inversion Principle and Hollywood analogy
Often DIP is known as the Hollywood principle: "Don't call us, we'll call you.".

But doesn't always higher level module calls lower level module, whether there is dependency inversion or not?

Then why is DIP called the Hollywood principle?

Am I missing something? Thanks!

答:
Inversion of Control

As demonstrated by @davidarno, you construct bottom up by instantiating the smaller bits first then passing that to the object's constructor it belongs in, and so on. In other words the construction of a composite has been inverted.

Also see this example of Object Oriented Dice

IOC enables Dependency Injection

Now we are passing the needed object - the dependency - via the constructor. Vola. Dependency Injection. Passing parameters IS dependency injection. But the larger point is now we can inject different objects; and there is further flexibility by specifying base types and interfaces.

The Hollywood Principle

Quoting from Head First Design Patterns

 The Hollywork principle gives us a way to prevent "dependency rot." Dependency rot happens when you have high-level components depending on low-level components depending on high-level components depending on sideways components depending on lo-level components, and so on.

With the Hollyworod Principle, we allow low-level components to hook themselves into a system, but the high-level components determine when they are needed, and how. In other words the high-level components give the low-level components a "don't call us, we'll call you" treatment.

The Clean Architecture by Bob Martin

The Hollywood Principle can be seen at work in the article

The overriding rule that makes this architecture work is The Dependency Rule. This rule says that source code dependencies can only point inwards.


问:
What is it exactly that makes programs platform dependent when they're using cross-platform APIs?
I understand that programming languages can either be run in a VM (Java, etc) on every OS that supports the VM natively or can be compiled to machine code (C, etc) for each platform.

What I don't necessarily understand is why programs (whether dealing with graphics APIs like OpenGL, DirectX12 or Mantle, or not dealing with any at all) aren't all cross-platform if it's as easy as cross-compiling?

What is it that keeps programs, games, APIs (for example OpenGL) from being compatible on all platforms (except that maybe the developers only wanted it on one platform)?

With the new graphics API, Vulkan, coming out soon, would it be theoretically possible if using a toolkit like wxWidgets, for native GUI, along with an API like Vulkan to create programs that run completely cross platform as long as the OS has a Vulkan driver? Any other insight on something I'm missing would be appreciated.

答:
With the new graphics API, Vulkan, coming out soon, would it be theoretically possible if using a toolkit like wxWidgets, for native GUI, along with an API like Vulkan to create programs that run completely cross platform as long as the OS has a Vulkan driver?

You've answered your own question.

The Vulkan driver has to be written for every system/OS, and not all systems will be compatible with what is required by Vulkan.


问:
Why is the most common integer number 32 bits, but the most common floating point number 64 bits?
Coming from a Java and C# background, I've learned to use int (32 bits) whenever I need a whole number, and double (64 bits) when dealing with fractional values. Most methods from their respective frameworks (JVM and .NET) usually expect these two types.

My question is, why don't we use both long and double for consistency? I know that having 64 bits of precision in integers is not needed most of the time, but then again, we don't usually need 64 bits of precision in floating point numbers, or do we?

What is the reasoning behind this, if any?

答:
Range vs. Precision

One thing is that I'd contest the idea that the most common floating-point number uses a 64-bit DPFP (double-precision floating-point) representation.

At least in performance-critical real-time fields like games, SPFP (single-precision floating-point) is still far more common, since approximation and speed there is preferable to utmost accuracy.

Yet perhaps one way to look at this is that a 32-bit int represents a range of 2^32 integers (~4.3 billion). The most common use of integers is probably going to be as indices to elements, and that's a pretty healthy range of elements that would be difficult to exceed without exceeding the memory available with today's hardware *.

* Note that out of memory errors can occur when allocating/accessing a single, contiguous 4 gigabyte block even with 30 gigabytes free, e.g., due to the contiguity requirements of that block.

A 32-bit integer isn't always more efficient at the instruction level, but it tends to generally be more efficient when aggregated into an array, e.g., as it requires half the memory (more indices that can fit into a single page/cache line, e.g.).

Also note that as Lightness Races in Orbit points out, it's not necessarily even true from a broad perspective that 32-bit integers are more commonly-used. I have my narrow perspective coming from a field where 32-bit ints are often aggregated by the hundreds of thousands to millions as indices into another structure -- there the halving in size can help a lot.

Now 64-bit DPFP might be used a whole lot more than 64-bit integers in some contexts. There the extra bits are adding precision rather than range. A lot of applications can demand precision, or at least have a much easier time programming with extra precision available. So that's probably why 64-bit DPFPs might be more common than 64-bit integers in some areas, and why int might still be 32-bits in many scenarios even on 64-bit platforms.


问:
Will Web Components in HTML Add Too Much Complexity?
The way I've been accustomed to User Interfaces is to see everything as a div. Where a div is essentially a box and they can be stylized in CSS.

```<code><div class='container'>
   <div class='header'></div>
   <div class='mainbody'>
       <div class='someusercontrol'>
       </div>
   </div>
   </div class='footer'></div>
</div>
</code>```

But it seems like nowadays with React and Angular Directives, and now with Web Components people are slowly shifting to:

```<code><container>
     <header></header>
     <mainbody>
             <someusercontrol someattribute='123'>
             </someusercontrol>
     </mainbody>
     <footer></footer>
</container>
</code>```

The problem that I see with the second example is that now all elements are heterogeneous as opposed to homogenous with divs. Each element can have different attributes / properties and can work in different ways. This can lead to complexity when viewing someone else's code for the very first time as each one of these "things" works differently.

But some argue that now elements will be more modular and easier to re-use. But I'm wondering if it's worth it. Are web components really the way to go? It sure seems that the future indicates they are.

答:
I believe what you're asking is based off of a person's personal preference or a particular level of when someone thinks something is "too complex" for them.

Now for me personally, I don't think it adds enough complexity for me not to use it.  For example, jquery.validate.js in VS2015 (using NuGet Package Manager) is great and has saved me some time.  For me, that's what it boils down to.  Does it save me time, even if it's a little?  Yes?  I learn it.  No?  No thanks, unless if there is some other payoff somewhere else.  For example:
<asp:DropDownList ID="status" runat="server" CssClass="form-control" AppendDataBoundItems="true" required > -- All I have to do is add that "required" at the end and jquery-validation.js knows I want it required.  It's the same for just about all the different inputs.  I know I could use ASP's "required" attribute, but I'm using other things customized for me.

Here's a link for more info: http://jqueryvalidation.org/


答:
Well, int and double is a Java thing. For example, in Objective-C and Swift you would use NSInteger or Int, which is 32 bit on a 32 bit machine and 64 bit on a 64 bit machine. Big enough to count any number of items that might be in memory. What is definitely useful is to use the same type almost everywhere, unless in a particular situation you need something else.

Java tries to have code that runs the same on any implementation, so they think you should use the same type independent of the machine you are using, and that the type should have the same number of bits independent of the machine. Objective-C and Swift (and C, C++ as well) have a different point of view.

Integers are mostly used for counting things, and usually you don't have that many things to count. Floating point arithmetic needs precision, and 32 bit floating point often doesn't give you enough precision. Using 64 bit double everywhere gives you a fighting chance to always have enough precision, without being a specialist in floating-point arithmetic. float doesn't.

But what consistency would using long and double give you? Integers and floating point numbers are not the same thing. There is no need for them to have consistent bit size. I use 2D points and rectangles a lot. So for consistency, should they also be 64 bits? Points having 32 bit per component, and rectangles having 16? Of course not. No consistency needed.

Title: Why is the most common integer number 32 bits, but the most common floating point number 64 bits?

Body:
Coming from a Java and C# background, I've learned to use int (32 bits) whenever I need a whole number, and double (64 bits) when dealing with fractional values. Most methods from their respective frameworks (JVM and .NET) usually expect these two types.

My question is, why don't we use both long and double for consistency? I know that having 64 bits of precision in integers is not needed most of the time, but then again, we don't usually need 64 bits of precision in floating point numbers, or do we?

What is the reasoning behind this, if any?


问:
Change database based on request origin
I am developing a web application which will be run by multiple companies.

Each company will have its own instance of that web application and its own database.  The web applications and databases will be running on the same server.

But each of these instances will be talking to one single Web API application to retrieve data from their database for that specific company.

My question is that I am wondering whether it is a good practice to change the database connection string in the Web API application based on the request origin? Or am I overlooking something?

答:
It is a bad idea to rely on anything the client provides for access control other than a shared secret that is difficult to spoof.

Request origin is easily spoofed.

Title: Change database based on request origin


问:
What happens if Sprint Goal is not met?
I've been reading Scrum Guide and one part is missing for me.
What happens if Sprint Goal is not met at all?
Let's say the Sprint Goal is a big part of a functionality which cannot be broken into parts further so devs have, say 2 weeks (the Sprint duration) to accomplish it or not, but they fail to do it. What happens with this functionality?

Should it be tossed away? (unlikely)

Should it be continued in the next Sprint? If yes, doesn't it break the rule of creating an Increment of potentially releasable product in each Sprint and also the rule that the duration of Sprint is fixed (technically the rule will stand but practically there will be a Sprint of 4 weeks)?

答:
It sounds like you say "Sprint Goal" and mean "a really big bit of something the product needs to do that it currently doesn't." This can be a separate discussion of how to craft better Product Backlogs including Epics, themes, story maps, etc.

For now, here are things to focus on improving:

Gain better understanding of Sprint Goal

Spend time removing impediments to decomposing work into more manageable sizes

Craft Sprint Goals based on work that can be accomplished in a single Sprint

I can help you with #1 :D

First, the Sprint Goal does not exist in the Product Backlog. Per the Scrum guide, a Sprint Goal is

...an objective set for the Sprint that can be met through the implementation of Product Backlog.

The Sprint Goal is crafted by the whole Scrum team (read: Product Owner, Development team and Scrum Master) after the Development team forecasts the work it can get done in the coming Sprint. The Sprint Goal may then be understood as:

...an objective that will be met within the Sprint
  through the implementation of the Product Backlog, and it provides
  guidance to the Development Team on why it is building the Increment.

Here's a visual representation of how a Scrum Team might handle forecasting work from their Product Backlog, form a Sprint Goal, react to unforeseen work, and still achieve their Sprint Goal:

If the Product Owner is unable to define work in the Product Backlog for which the Development Team can forecast completion in a Sprint, do not say/do the following:

Lengthen the Sprint

Say, "Scrum just can't work here"

Take work into the Sprint that the Development Teams cannot finish

Ironically, shortening the Sprint (Product Owner decision) will many times force Scrum Teams to find innovative ways of producing smaller chunks of valuable, working software.

Instead, ask "what would need to change?" This constructively leads discussion towards the art of the possible which in turn inspires us to work for change.

Take only work into a Sprint that the Dev. Team thinks it can accomplish. Doing otherwise invites death marching (shudders).

Producing working software in 30 days or less is one of the most important aspects of agility that Scrum teachs. Please consider making these improvements a top priority for the health of the team and the organization.

Title: What happens if Sprint Goal is not met?