答:
It depends on your precise application and how it's structured, but in general you should have more text than screen shots I've found. Unless your product will be a user's first introduction to a computer, you shouldn't worry about click-by-click instructions. Assuming your user interface is sane, you should be able to describe how to do most operations with text and maybe a few screenshots.

If, your user interface isn't quite sane and/or is misleading.. well, you could fix that, or you could give screenshots or even animated GIFs showing how to actually get your product to work. You should provide this in addition to a lot of plain text though.

Title: Should user documentation include screenshots?

Body:
This question focuses on user documentation, not on code documentation.

I just finished my software project, and the people I work for are expecting me to write user documentation, describing everything the software does.

All the documentation they had until now (about the rest of the software they use) is full of screenshots, and sometimes barely contains any text. I think it's awful. I've been struggling for hours to understand how screenshots were connected, and most of the time I had to ask for help from someone else.

I wrote a Java desktop application, and its appearance is likely to depend on the current Windows theme and Java update. I don't think screenshots can form reliable, definitive reference.

Taking hundreds of screenshots and annotating them will take forever, and I don't believe it will help more than accurate, plain text documentation.

How should I approach putting the user documentation together?  What guidelines should I follow regarding the use of screenshots versus explaining in text with user documentation?


问:
Is it ever OK to commit non-working code?

Is it good idea to require to commit only working code?

This commit doesn't need to leave the repository in a working state as:

... we are in early design stages, the code is not yet stable.

... you are the sole developer on the project. You know why things aren't working. Furthermore, you are not stopping anyone's work by committing broken code.

... the code currently doesn't work. We are going to make a big change to it. Let's commit, in order to have a point to revert to if things get ugly.

... the chain is long, no trouble if broken code exists in the local branch. I.e.

local files

staging area

commits in local branch

commits in remote personal feature branch

merge with remote develop branch

merge with remote master branch

merge with remote release branch

... commit early,commit often.

So in the above-linked question, the majority of answers say that committing not-compilable code is no problem in local and feature branches. Why? What is the value of a broken commit?

Some of the highly voted comments say that on a local brach one can do whatever one wants. However, I am not interested in the technical side of the question. Rather I would like to learn the best practices - the habits that people who have worked many years in the industry have found most productive.

I am amazed at the vast amount of great answers! They lead me to the conclusion that I am not adept enough at using branches to organize my code.

答:
Before you start getting dogmatic about how to work with your version control, it's worth thinking about why you're working with version control.

Committing to version control freezes the state of your code for future reference - everything else is falls out of this.  Looking at diffs and making patches is just seeing how code changed between snapshots.  Branches and tags are just ways of organizing snapshots.  Sharing code with other developers is just letting them look at a particular snapshot.

When should you commit?  When there's a reasonable chance you will look at the state of your code (or the commit message explaining a change) in the future.

Git gives you a whole lot of flexibility as to how to organize your snapshots.  There's no central repository so you can share your code with other devs without pushing your state to the 'main' repository.  You can easily create, merge & delete branches to isolate the details of a set of states from the main code's narrative.  You can commit locally, to help you undo a follow your current development, and then batch everything up into a single commit before pushing it out for others to see.  You can tag specific revisions so they're easy to find later.

KISS.  What works best for a single developer in the early stages of development of a small project is going to be completely different than what you need to do when you have a hundred developers working on a decade-old, mission critical system.  In any software development process, you should avoid creating unnecessary artifacts simply because somebody else told you to do it.

ContentLicense: CC BY-SA 4.0

ContentLicense: CC BY-SA 3.0


问:
TCP and UDP basics: connecting to a website
I am just learning computer networks so please forgive me if this question is naive. I know the TCP protocol binds itself to a port till the transfer of messages is over (port 80) and UDP is best effort (ie no binding). My question is if I try and access two websites at the same time (multiple tabs on my browser), assuming both websites are web servers, my questions are

Does my computer communicate with one webservice (website) first and then communicate with the other (serially). Also if this is the case is the time difference so small that I feel it loads simultaneously?

Suppose I have my own web server (tomcat) running on port 80, how can I communicate with other websites if it happens on the same port?

Do websites decide which protocol to use TCP or UDP?

答:
I know the TCP protocol binds itself to a port till the transfer of messages is over (port 80)

A TCP connection is uniquely identified by the 4-tuple (source address, source port, dest address, dest port). The source and destination IP addresses will take care of themselves, but you're slightly confused about the ports.

A port is just a 16-bit integer, used to distinguish between multiple active sockets on the same host, but there are certain conventions governing their allocation (reference: wikipedia):

"well-known" ports are < 1024.

These ports are generally protected by the OS, so an unprivileged process cannot bind one and hence masquerade as a well-known service.

As you noted, 80 is the "well-known" port for HTTP, which means it's the default unless your URL specifies otherwise.

"registered" ports, useable by unprivileged processes to provide services, are between 1024 and 49152. For example, 8080 is commonly used for an unprivileged HTTP server

remaining values from 49152 to 65535 are used for ephemeral ports. When you create a socket and connect to a server, without binding your socket to a particular local port, the kernel assigns a free port from the ephemeral range. This is just to create a unique 4-tuple identifying your connection, and you'll normally never care what the value is.

NB. the actual range used for ephemeral ports may vary by OS and even be configurable - it'll always start above 1024 though.

and UDP is best effort (ie no binding).

UDP stands for User Datagram Protocol. You're right that it is best-effort, but that has nothing to do with ports. Both TCP and UDP use exactly the same IP addressing scheme, with the same 4-tuple. You'll probably never use it for HTTP though (see the answer to your last question below).

My question is if I try and access two websites at the same time (multiple tabs on my browser), assuming both websites are web servers, my questions are

Does my computer communicate with one webservice (website) first and then communicate with the other (serially). Also if this is the case is the time difference so small that I feel it loads simultaneously?

Yes and no. You create two sockets and connect them both. The source IP will be the same for each (since they're on the same machine, and presumably using the same network interface on that machine). The destination IP and port will be the same (they're connecting to the same HTTP server). The source port however will be different, because your OS allocated a different ephemeral port to each socket.

Because each socket is your endpoint for a different TCP connection (they have different unique 4-tuples), they can run in parallel. However, assuming as above the two connections are over the same physical network interface, they can't send or receive physical packets simultaneously. In practise this doesn't matter, since the OS will interleave their packets onto the physical network for you.

The connections will generally be asynchronous, so both sockets can have in-flight requests at once, and the replies can also be interleaved.

Suppose I have my own web server (tomcat) running on port 80, how can I communicate with other websites if it happens on the same port?

Your website will be listening on the IP,port tuple (localhost,80). If you connect to it from the same machine, your connection will be something like (localhost, ephemeral1, localhost, 80). If you connect to a web server on a different machine, your connection will be something like (localhost, ephemeral2, remotehost, 80). They're still different, even if they both have an 80 in one of the 4 values.

The only thing you can't do is have two different web-servers both listening to port 80 on the same machine.

Do websites decide which protocol to use TCP or UDP?

You can always check this stuff yourself: the standard is here. Here's the relevant section:

HTTP communication usually takes place over TCP/IP connections. The
     default port is TCP 80 [19], but other ports can be used. This does
     not preclude HTTP from being implemented on top of any other protocol
     on the Internet, or on other networks. HTTP only presumes a reliable
     transport; any protocol that provides such guarantees can be used;
     the mapping of the HTTP/1.1 request and response structures onto the
     transport data units of the protocol in question is outside the scope
     of this specification.

So you see HTTP doesn't have to use TCP, but it does assume a reliable (and connection-oriented) protocol, so UDP is out.


问:
Why isn't iostream included as a header file anymore?
First of all I have gone through this question Why is #include <iostream.h> bad? and there the reason was simply that it is outdated but I personally think that as a header iostream was better cos you don't have to declare objects like cout and endl in global scope cos they were already in global scope and moreover since # is not used anymore that means it does not comes under a pre-processor directive. I just need to know that why was this done? I still use turbo sometimes and am comfortable in using it in c++ programs even though gcc and g++ provide better debuggers and everything. </p>

答:
I think you misunderstood the question. It's bad to include iostream.h because nowadays you should be using iostream. iostream.h is out of date, #include-ing it simply means that your code may or may not break, or shoot monkeys out of your nose, it's implementation defined.

Moving to iostream is simply moving to the standard version. You get the guarantee of it working, having an exception aware API, better localization, etc, etc.

Also, you don't want all of std dumped into global namespace. There is tons of stuff in there that you don't want to know about. Typing those 5 extra characters prevents weird errors if you have a class called map or something.

That being said, if you really want to use C++ as it was before 1998, have at it. But you're throwing away community support (The C++ community has moved on), updates, and any modern innovations from the last 1.5 decades. I think these outweigh the only downside I see, learning a few new things about how C++ has changed.


问:
Do you think that GAE alone is enough to justify learning Python over Ruby?
Considering the fact that you don't have to get involved in setting up/buying a server or even buying a domain, do you think that fact alone is enough to choose one over the other?

I don't necessarily want to work on Google App Engine, I just find it convenient when it comes to hosting/environment/etc. and wondering if that's a good enough reason to learn python.

In any case, I'm not looking for a debate between python and ruby but more on Google App Engine and whether its value is enough to dictate the language you should learn.

答:
No. Google App Engine does provide a free/cheap infrastructure for hosting Python applications, but Ruby has virtually the same thing with Heroku (and Heroku has a lot less restrictions that GAE). Before using GAE, make sure to read very closely about the restrictions that Google puts on the platform, many of which can be significant barriers to the goal you're trying to achieve. Carlos Ble's blog post goes into much more depth about the many restrictions he's run into, but I'll give you a quick overview:

Python 2.7 only with no compiled extensions (major performance hit)

30 second request timeout (so much for easy large file uploads) and 10 second outside request timeout (so you can't query slow API's from your app)

BigTable is stone age; no "LIKE" operators in your query and no single query can return more than 1,000 records

Memcache has a 1 MB max value size

Both BigTable and Memcache tend to die at a significant enough rate that it's productive to put code in your application to work around their failures

For a very small project, GAE is just fine; but if you're build something at a medium or large size, just be aware of the restrictions that may hamper you progress.

For more information about what sort of quotas and limitations you may have to deal with, see the GAE docs:

http://code.google.com/appengine/docs/quotas.html

http://code.google.com/appengine/docs/billing.html

Also see this response on Stack Overflow: https://stackoverflow.com/a/3068371/189079

ContentLicense: CC BY-SA 2.5


问:
Should user documentation include screenshots?
This question focuses on user documentation, not on code documentation.

I just finished my software project, and the people I work for are expecting me to write user documentation, describing everything the software does.

All the documentation they had until now (about the rest of the software they use) is full of screenshots, and sometimes barely contains any text. I think it's awful. I've been struggling for hours to understand how screenshots were connected, and most of the time I had to ask for help from someone else.

I wrote a Java desktop application, and its appearance is likely to depend on the current Windows theme and Java update. I don't think screenshots can form reliable, definitive reference.

Taking hundreds of screenshots and annotating them will take forever, and I don't believe it will help more than accurate, plain text documentation.

How should I approach putting the user documentation together?  What guidelines should I follow regarding the use of screenshots versus explaining in text with user documentation?

答:
The old adage "a picture tells a thousand words" is rarely as important as it is here. Please, please, please, for your sake and for your users: USE LOTS OF SCREENSHOTS.

Having been in a similar situation, where most of my users were elderly women, I cannot convey how useful screenshots are. The question becomes, how to present them. I found that a task-based approach works best.

e.g.

Table Of Contents

Customer Information

I want to update a customer's address

Billing

I want to create an invoice for a customer

I want to create a bill for a customer

Shipping

You get the idea

Note that each heading in the TOC is obviously a link (which any format, be it word/html/chm/whatever supports). Then for each individual action (eg. 1.1) start with the first screen the app shows when it opens up.

Start at the Home screen

[screenshot]

Click "Customers"

[screenshot with big red circle around "Customers" button]

You arrive at the Customers window

[screenshot of the customers window]

(note, use a test build with only fake customers)

Click "Search"

[screenshot with big red circle around "Search" button]

Enter the customer's last name and double-click their name

[screenshot of the search window with the customer's lastname in the search box]

You arrive at the customer details screen

[screenshot of the customer details]

Click "Edit"

etc.

Yes, this first few steps are redundant, and the whole thing is lot of laborious screen-shooting. Users will get used to just flipping past the first page or two but anyone and everyone, on their first day on the job, or after a long vacation, or mat leave, or sick leave, or whatever... can be told to "Go do [this]" then click "I want to do [this]" in the docs and have detailed instructions showing exactly what to do.

You can have the first step be "Open the customer's file" which is linked to the "I want to see a customer's information" section. Be wary, I switched to that, and had a large portion of my users that found this extremely complicated. The ones who didn't find it complicated, didn't care enough to appreciate the 'shortcut'. The tip is: Know your audience and don't assume anything about them.

There's an old article from Joel Spolsky (that, for the life of me, I cant find) where he talks about usability and the wheelchair assistance bars in bathrooms. The crux of the argument was that some usability features aren't necessary for everyone... but when available, everyone uses and appreciates them. I firmly believe that incredibly obvious documentation for internal apps fits in this category. Especially considering that they can't be searched for help online.


问:
Is a large increase in velocity realistic in a Scrum environment?
My manager has recently really been pushing to use velocity as a target and measure of productivity. We are currently working at an average velocity of 50 story points. My manager wants us to increase it by 40% to 70 story points (with no increase in team members). If we don't achieve this increase he wants us to deliver a full break down explaining why.

The whole idea of measuring team performance by velocity and using it as a target seems wrong to me, but I am finding it difficult to explain why. Any help? Why isn't this the right way to measure and incentivize productivity?

答:
Well, it's perfectly simple to increase velocity by 40% - just add 40% more points to all your estimates and do the same amount of work.

Given that this is so, it should be apparent why using velocity as a target is wrong, it just encourages inflated estimates.

A less glib answer is that your estimate already assumes you are going as fast as you can while doing everything correctly.  The only way to really increase productivity by 40% is either to work overtime or to not do everything correctly.  Both of these speed things up in the short term, but slow things down in the long term.  And the long term in this case isn't very long, a month at the outside. The optimal long term strategy is to never go faster than your sustainable pace.

Peopleware talks eloquently about the issues of trying to force programmers into higher productivity , and is an often cited classic.  But in general it won't be easy to change the mind of a manager that is going down the path that yours is.  Your project may well be in trouble - this is certainly a red flag.


问:
Why might an ASP.Net website load slowly?
Anecdotally, I've visited many .aspx website that require a significant amount of load time for each page.

Is my experience unique?

If not, why might an ASP.Net website load slowly?

Edit: It's now about 7 years later (12/29/2017). The good news is I don't see this problem much anymore, maybe because Google started penalizing sites that load too slowly. I now use ASP.NET MVC with good results, currently running on Vultr private virtual servers (Azure was way too slow when we tried it.) Some of the worst offenders I see now are the CMS systems like Wordpress and Drupal, probably running on hardware that's too slow or underspecced for the amount of traffic the site gets. -HK1

答:
All of the above are likely true.  The biggest single factor affecting the performance in the ASP.NET site that I worked on though was that everything relating to it was old.  The .NET framework version, the servers, the database infrastructure, and the code itself were all aging badly.

I suspect many ASP.NET sites tend to be corporate sites.  These don't get a lot of love, since they tend to just work. People don't rewrite them until they have to, which is often a very long time down the road.

I know the site that I worked with that used ASP.NET got a huge speedup just by moving to the newest version of the framework, which had much more efficient JITing and sane caching defaults.

The other thing that I've seen that a lot of ASP.NET sites do not know how to scale properly.  They don't have proper load balancing set up because designing their site to work correctly with web gardens is not common or well-documented in the community.  If you don't design your site for web gardens from the beginning, you can't use the built-in scale-out mechanism that IIS has.  Software load balancing with Windows NLB is not very common and is complex to manage.  (This harkens back to the fact that ASP.NET tends to be corporate software, and tends to be managed by the company running the site rather than IT professionals who know how to configure this stuff correctly.)

Hardware load balancing with F5s is very very expensive, but seems to be the most common and simple mechanism for scaling out ASP.NET sites within corporate networks.  I think among the open source crowd the expectation is that you build in load balancing from the beginning using freely available open source tools that automatically scale out based on usage.  This is not common in the ASP.NET world from what I've seen.


问:
How to do you judge the value of using TDD or plain unit testing in an Open Source project? Is there a good rule of thumb?
In my current OSS project, I knew literally nothing about what I was doing when I began.

I was integrating with a larger project as a plugin, and that in and of itself had a steep learning curve.

If I had begun with TDD it would have never been written as my code was changing as I was learning.

This has worked for quite a long time. Now I am past the point where unit tests provide negative returns, and I need to write them. So as I fix things, for items I know how to write a test for I will.

My question, does anyone have a good rule of thumb as to what point you should say to yourself - stop - unit tests need to be used from here on out.

Believe me - it is not day 1. I am looking for a pragmatic answer. Remember, I don't make any money off of my work, I enjoy writing new features not new tests for old ones. That is the root of the dilemma.

答:
No, there is no rule of thumb.

It really depends on how dependable and maintainable you want your code base to be.  If your project is a small class or one-shot utility, you may not need any unit tests at all. If, on the other hand, it is a framework or core program that will be used by many people, you may need extensive unit tests, and you'll probably need them from the beginning.

Unit testing, when used correctly, guides your overall software design.  Testable code is easier to maintain, easier to reason about, and has fewer bugs.  This is as true from day one as it is at the end of your project.  Delaying this process is based on the false idea that unit testing takes more time than just writing an application and testing it manually.  While unit testing takes a little longer to set up, it pays for itself the first time you have to re-run the tests.

Unless you are writing in a dynamic language with a REPL, I honestly don't see how delaying your unit tests is going to help you.  I use unit tests as a shim for trying out experimental code.  When I have code that works, I graduate both the unit test and the working code to "first-class" status in my project, and the unit test serves as a design prototype for the actual code, as well as verifying that the code still works after a refactor.

If you are working in a dynamic language with a REPL (as opposed to a statically-typed language like C#), unit tests become even more important, because you no longer have the safety net of static type verification during compilation.

Nowhere is this philosophy more evident than in the SQLite code base.  SQLite has roughly 84 thousand lines of production code, covered by more than 90 million lines of test code.  I'm pretty sure the author wasn't ever thinking "so when should I start writing unit tests for this thing?"

Further Reading

http://www.sqlite.org/testing.html


问:
Use a service layer with MVC
If a controller gets too fat and model instantiation starts to add up, a service layer could be used.

If I just wrap the logic inside a service class, I will get a bunch of Services with one/two methods. This feels like a code smell. Any best practices regarding this?

Can a service instantiate models?

If a service instantiates models, the services can't be unit tested. They can only be covered by integration tests?

答:
Controllers should only contain calls to the model (where the business logic happens) and based on those calls assign data for the view (objects of information or error messages) therefore controllers will be quite small even for a very complex page, if the controller still gets very big you should think that maybe that page should be expanded into more pages.

Still the model can be quite big... the solution I found was having a variable inside the controller that tells what model to load and for specific tasks I load the specific model.

Try to obey the model-view-controller model clean like this:

view: displays data

controller: collects userinput, asks model for the requested data and sends it back to the view

model: interacts with database and performs logical actions to prepare information

Title: Use a service layer with MVC


答:
Testing and test coverage are difficult things to quantify, I don't believe 100% code coverage is essential, or even a good idea, but a good set of tests developed using TDD or not is going to save you time in the long run and improve the quality of your code.

As a rule of thumb : if you really know what the code should be doing and can define it clearly and exactly I'd use TDD, it helps you get the requirements down and keeps you focused on the thing you are developing. Otherwise if the exact nature of the code is still forming or changing as you go, write a test as soon as you have a working version you are happy with and you think the signatures etc are not likely to change.

I find it much harder to retro fit tests to a project, it's easier to code tests when the thing you are working on is still fresh in your memory.

If its trivial code I'd probably not write a test at all.

Title: How to do you judge the value of using TDD or plain unit testing in an Open Source project? Is there a good rule of thumb?

Body:
In my current OSS project, I knew literally nothing about what I was doing when I began.

I was integrating with a larger project as a plugin, and that in and of itself had a steep learning curve.

If I had begun with TDD it would have never been written as my code was changing as I was learning.

This has worked for quite a long time. Now I am past the point where unit tests provide negative returns, and I need to write them. So as I fix things, for items I know how to write a test for I will.

My question, does anyone have a good rule of thumb as to what point you should say to yourself - stop - unit tests need to be used from here on out.

Believe me - it is not day 1. I am looking for a pragmatic answer. Remember, I don't make any money off of my work, I enjoy writing new features not new tests for old ones. That is the root of the dilemma.


问:
Finally block for methods - is it a bad idea?
The finally block for a try-catch structure is well known, and gives a really easy and elegant way to deal with some must-be-done code.

Therefore, I can see no reason why It shouldn't be good for methods too. For instance, lets say I'm writing some very complicated logic in a method, and I expect to end up with a bunch of boolean flags that will in turn lead to some decisions. Many times in such kind of methods I have branches of code where I would want to "break" the flow and just perform the "real stuff" that I called this method for, with the satisfying information I gathered so far.

So, Why isn't there such pattern? Or is there?

答:
The Go programming language has something similar to this idea: the defer statement.  Deferred functions are called when the enclosing function exits for any reason, and can be method calls or plain functions, e.g.:

func fileProcessor(filename string) (err error) {
    var file *os.File
    if file, err = os.Open(filename); err != nil {
        return
    }
    defer func() {
        fmt.Printf("Closing file\n")
        file.Close()
    }()
    fmt.Printf("Processing file\n")
    return
}
```
<p>In this case, the deferred function is anonymous.  It could also just be:</p>
<pre class="lang-go prettyprint-override"><code>defer file.Close()
</code>```

But the anonymous routine allowed the Printfs in the example to highlight the order of execution.

In practice, I find defers to be a clean way to ensure the release of locally acquired resources.  The approach isn't commonly found in other languages, but I find its presence in Go to be a welcome one, and would like to see it elsewhere.

Body:
The Go programming language has something similar to this idea: the defer statement.  Deferred functions are called when the enclosing function exits for any reason, and can be method calls or plain functions, e.g.:

func fileProcessor(filename string) (err error) {
    var file *os.File
    if file, err = os.Open(filename); err != nil {
        return
    }
    defer func() {
        fmt.Printf("Closing file\n")
        file.Close()
    }()
    fmt.Printf("Processing file\n")
    return
}

In this case, the deferred function is anonymous.  It could also just be:

defer file.Close()

But the anonymous routine allowed the Printfs in the example to highlight the order of execution.

In practice, I find defers to be a clean way to ensure the release of locally acquired resources.  The approach isn't commonly found in other languages, but I find its presence in Go to be a welcome one, and would like to see it elsewhere.


答:
As the comments have pointed out, the request is obviously wrong the way it has been put.  But he's not really wrong to want to constantly improve productivity.  As a rule, that is what managers strive (and are evaluated) for.

That said, managers are always looking to improve performance, and Scrum and Agile is all about being adaptable.  While velocity is a measure of your current sustainable pace, you shouldn't sit back on your laurels.  Scrum has a place for evaluating and changing what works and does not in your process: the retrospective.  If you take advantage of that and adjust your process, productivity (and possibly velocity) should go up.

So, are you looking (in your retrospectives) for ways to become more productive as a team?  Is there anything in your sprints that regularly consume a disproportionate amount of effort?  Can it be addressed?  It probably won't give you a 40% increase, but 5-10% is a start, no?  Every sprint you should look for bottlenecks and address them.  Eventually, you may get close to the goal he's set for you.

Title: Is a large increase in velocity realistic in a Scrum environment?

Body:
My manager has recently really been pushing to use velocity as a target and measure of productivity. We are currently working at an average velocity of 50 story points. My manager wants us to increase it by 40% to 70 story points (with no increase in team members). If we don't achieve this increase he wants us to deliver a full break down explaining why.

The whole idea of measuring team performance by velocity and using it as a target seems wrong to me, but I am finding it difficult to explain why. Any help? Why isn't this the right way to measure and incentivize productivity?


答:
It sounds like you face two issues.

The part about measuring velocity that bothers you is probably that the measurement is the cost. What you really want to improve is the value. Unfortunately, measuring the value of software is notoriously hard and subjective. Still, even an imperfect and subjective metric can be useful. It could be that the real issue is not that your team needs to write more code, but that the the stories need to be more valuable.

The other issue is that based on your account, your manager expected a 40% increase in productivity. It wasn't stated in your question the context of this request. It could be a good-natured if wishful desire for your team to improve. Or it could be a not so subtle indication that your manager believes that your team is under-performing.

edit: Based on your comment, the situation looks bad. It sounds like your company is laying the groundwork to fire you and your team (maybe your manager too). I suggest that you look for another job.


问:
More efficient way to paginate search results
I'm making a website in PHP where the user can search a big MySQL database. The user is shown the first result. I want the next button to take the user to the next result, and so on.

The trivial solution is for each result page to execute the user's search query again and use OFFSET and LIMIT to get the n-th result that is displayed. But this feels like a Schlemiel the Painter's algorithm: re-executing the same query over and over to get to the n-th result is inefficient.

Since others must have faced this situation before: how is this typically solved?

答:
So this is basically the best thing you can do in my opinion. It's far more scallable than keeping the whole result set in-memory and reusing it between page requests. But of course it's hard to judge without seeing your software requirements first.

If you need something more sophisticated then depending on your use case you can cache results from your query locally, or if the results rarely change you can even pre-generate the page in the back-end (one query at certain intervals, users get static results). This is basically what CQRS is designed to deliver:

http://martinfowler.com/bliki/CQRS.html

http://www.udidahan.com/2009/12/09/clarified-cqrs/

Excerpt:
"CQRS is about coming up with an appropriate architecture for multi-user collaborative applications. It explicitly takes into account factors like data staleness and volatility and exploits those characteristics for creating simpler and more scalable constructs.

Standard layered architectures don’t explicitly deal with either of these issues. While putting everything in the same database may be one step in the direction of handling collaboration, staleness is usually exacerbated in those architectures by the use of caches as a performance-improving afterthought."


问:
Are mutexes assigned to specific regions of memory?
I'm currently reading C++ Concurrency in Action by Anthony Williams and I'm facing an obstacle in thought.

First he describes deadlocks as when two threads lock simultaneously (at least, that's how I understood it), which makes sense.

However, he goes on to explain how you can lock two mutexes at the same time. Obviously this has a function, but with the above (assumingly wrong) understanding that would instantly deadlock both threads.

From that obstacle arises a new one; obviously it won't deadlock, which means the mutexes must have a more advanced use than just allowing a single thread to do work in a process. In the book, mutexes are given to particular objects.

This leads me to my overall question(s): Are mutexes assigned to specific memory regions, such as objects? If so, how?

The book does a great job at explaining how mutexes can be used but never really describes what mutexes are at a low level. I realize they're implementation specific but I never really grasped what exactly they do or how the locking functions use them.

答:
A mutex is not a specific memory region; it's a signal, basically a special type of object, and it works purely "on the honor system," so to speak.  A mutex protects a region of code because calls to it surround the code in question, not because it has any inherent relationship to the code.  (Even when it's a lock associated with an object, like with C#'s lock keyword, locks only work when they're invoked by some piece of code.)

There are two things that can happen when a piece of code attempts to acquire a lock: either it can find it available and acquire the lock, or it can find it already in use and fail.  The most common response to failing is to wait until the lock becomes available.  And a deadlock doesn't happen because two threads are both trying to use a lock at the same time; it happens because two threads are both waiting on each other at the same time.

Imagine that two locks exist, named A and B, and two threads exist, called 1 and 2.  Both of them are doing things that require locked access to both A and B, but thread 1 holds A and thread 2 holds B.  If they both try to acquire the other lock, and then (as is the norm) attempt to wait forever until it becomes available, they'll both be stuck waiting forever (deadlocked).

The best way to prevent a situation like this is to identify situations in which your code may need to hold more than one lock at a time, and impose some sort of general ordering rule across the entire codebase, such that no thread can acquire multiple concurrent locks out of order.  If no thread that needs A and B can acquire B without already holding A, for example, then it's impossible to get stuck in the deadlock described above.

At a low level, a mutex can be thought of as containing two pieces of data: a variable identifying the current holder, such as a thread ID number (or 0 if it's currently unlocked) and some sort of list of threads that are currently waiting on it.  Access to this data is controlled by atomic operations, to ensure that multiple threads both attempting to acquire the mutex don't overwrite or corrupt each other.


答:
Yes, so long as it is not a release branch.

In personal branches, everything goes and can then be discarded if the experiment did not work. That is one of the main benefits of DVCS: freedom

The value of committing broken code?: collaboration and experimentation

Title: Is it ever OK to commit non-working code?

Body:
Is it good idea to require to commit only working code?

This commit doesn't need to leave the repository in a working state as:

... we are in early design stages, the code is not yet stable.

... you are the sole developer on the project. You know why things aren't working. Furthermore, you are not stopping anyone's work by committing broken code.

... the code currently doesn't work. We are going to make a big change to it. Let's commit, in order to have a point to revert to if things get ugly.

... the chain is long, no trouble if broken code exists in the local branch. I.e.

local files

staging area

commits in local branch

commits in remote personal feature branch

merge with remote develop branch

merge with remote master branch

merge with remote release branch

... commit early,commit often.

So in the above-linked question, the majority of answers say that committing not-compilable code is no problem in local and feature branches. Why? What is the value of a broken commit?

Some of the highly voted comments say that on a local brach one can do whatever one wants. However, I am not interested in the technical side of the question. Rather I would like to learn the best practices - the habits that people who have worked many years in the industry have found most productive.

I am amazed at the vast amount of great answers! They lead me to the conclusion that I am not adept enough at using branches to organize my code.


答:
In this case, the manager has turned the wrong direction after getting an honest and faithful estimate from the team. The manager is supposed to turn to the stakeholder and let them know that their requirements cannot be completed in the time requested. The manager / analyst should then prioritize which of the features MUST be included and the others which can wait (if even only a couple weeks). If the stakeholder is being unreasonable, then it might require higher up managers to get involved, which can generally be challenging and require a whole other set of discussions.

If i was in your shoes I would come up with a detailed case as to why the project IS going to take as long as was estimated. Also try to identify low return items. Find the items which don't add much value and require substantial programming efforts and make a case for removing those from the sprint. Also come up with an iterative approach which delivers "X" on "Y" date and make sure that it's feasible, then come up with a follow up iteration which will get them the remaining items.

Basically, someone needs to tell the stakeholder what they can expect to receive by the deadline and that it includes the majority of their requirements. and that by the following release they will have the remaining items. If the customer is that unreasonable then upper management needs to be involved, the manager should be able make this happen.

However, if the customer was over promised, and no one has spoken up until now it will be an uphill battle. This is not an uncommon situation unfortunately.


答:
I'm not understanding which role your manager has in the Scrum team? Is he a coach? Is he a product owner?

If he is inside the team like a coach or such (he works at a development task) you may ask him why he undervalues his own productivity, because it seems that was not the case for other team members. If he believes he can personally assume 30 story points more every iteration, let him show it.

More probable: he is outside the team, maybe the product owner? If so he should understand making such a stupid request he just stopped agility.

A basic rule is that the product owner sets the goal while the team sets what can be done in an iteration. Not doing so leads to the classical and well known iron circle: resources, velocity, features. Pick two! You can't choose three of them at once (and remember: quality is not an adjustment variable, trying to cut corners through low quality will make things even worse).

If he doesn't want to change the current goal, maybe a 40% increase in productivity can be reached by recruiting more people for the team? Maybe investing in some advance training for some team members? Teams may also gain velocity over time through continuous improvement, but certainly not by arbitrary decision.

Trying to change the velocity of a team is like trying to change the size of a room. It can be done, but basically you need to change the room.

Don't you have some Scrum Master, or some other people around with basic understanding of Scrum who could explain that to him ?


答:
My experience is that it has been very, very hard to increase the actual velocity of a team, given that neither the team, problem domain or technology stack change.

Where I have been able to achive increases, it's been a matter of:

cleaning up technical debt; ensuring that everything is running the right (not necessarily latest!) version, that the code is well-factored, and that there is no redundancy in the system (duplicated code, unused code, etc.)

improving practices; pairing where possible (yes, I've found that increases velocity), taking the time to refactor aggressively (ditto!), and being ruthless about scope and focus

finding and / or buying the best tools for the job (e.g. ReSharper for .NET is worth its weight in gold, Airbrake and Splunk for Ruby development, etc.)

I agree with others here who say that your manager asking for an arbitrary increase in velocity is a red flag.  I would be looking for another job as a high priority.


问:
Partitioning code into assemblies for the sake of logical seperation
I've started working at this company, and the software is managed in a Visual Studio solution that includes hundreds of projects (C++ and C#).
After poking around the solution for couple of weeks, I started wondering why there are so many projects. Not only does it slows down VS considerably, but a rebuild can take up to an hour.

Since a visual studio project corresponds to a physical deployment unit (be it a .NET dll, a C++ lib or an exe), there are reasons why you'd want code partitioned across projects. Some of those reasons can be found in this article.

In my particular case, none of the reasons in that article stood. There are roughly 5 processes running across tiers, maybe a few dynamically loaded assemblies used for a plug-in model, and some infrastructure which is rarely changed.

I don't see any need for more than ~50 VS projects for this solution, and I believe that merging them will increase productivity and will allow for a shorter feedback loop.

When I tried to suggest this to the software manager, his response was that they are trying to have as many dlls as possible so that when they plan to ship a new feature, QA can test just the behavior of the modified dlls without having to worry that something else was effected. He said that since a dll was not changed, it will behave the same. For this to work they aim for high granularity of deployment units.

Does this make sense to anyone? I don't see the difference in the effect on behavior between  editing a single line in a project that has a single huge dll, and editing the same line in a project that includes hundreds of dlls.

EDIT

I'm looking for an answer on using assemblies/project as means for separating logical concerns and its effect on the testing effort. I would even go as far as saying that many assemblies that could give you more testing scenarios because of versioning incompatibilities.

So my distilled question is: When will you partition your code across projects/assemblies instead of namespaces in the same assembly, given that there are no runtime constraints, and why?

EDIT 2

I guess I'm looking for something like this article. However, I'm reluctant to post this as an answer and accept before I see if there are different opinions in the community.

答:
Yes, it does make a sense. The problem is it is still highly theoretical. I would question him if what he says, is really done in practice. Does QA really test individual DLLs or do they only test bigger parts of the project. Do they also test DLLs that have changed DLL as dependency? If no, how are they able to ensure it is also correctly working? There is also problem of actually tracking changes for each DLL. Because the more DLLs there are, the harder it is to track what DLLs were changed for specific feature/bugfix. Last thing that comes to mind is separation of concerns. If the structure of project is correct, then many changes would require change of only few DLLs. Preferably only one. This is rarely a case and more often than not, projects are in such a state that change propagates through many DLLs. In the end it is matter of compromise : Is the advantage of separate testing (with all that goes with it) higher than having really long build times and dealing with DLL hell?

I would definitely ask him, if what he says is just wishful thinking or real practice, that is actually advantageous.


问:
What licence should I choose for my project?
I originally thought of creative commons when while reading a book about wordpress (professional wordpress), I learned that I should also specify that the product is provided

... WITHOUT ANY WARRANTY; without even the
  implied warranty of MERCHANTABILITY or
  FITNESS FOR A PARTICULAR PURPOSE

and they recommend GNU GPL.  How do I write a license or select 1?

btw, what does MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE mean actually? Isn't without warranty enough?

答:
How are you giving these materials to people?

If you're licensing your application to people commercially, you're going down the wrong path - you need to see a lawyer to prepare a software license agreement. In these situations the customer paying for software licenses get statutory warranties, so clauses like that aren't enforceable.

If you're releasing source code or other materials for others to re-use, your original post is absolutely correct - you MUST include a warranty waiver, otherwise someone might turn around and say "you released this code claiming it did X, Y and Z - but it doesn't and I'm going to sue you", even if you didn't get paid for it.

In either case, you need to sit down and figure out what you want people to be able to do with the product.

In the latter case where you're releasing things to the community under an Open Source license, find a good OSI-approved license that aligns with your wishes:
http://opensource.org/licenses/category

But as greyfade mentions, don't even think about writing your own license - it's not worth the risk.


答:
Fire him. That is to say, go over his head and explain that he has lost all trust of his team, and explain he is no value to the business. Explain that managers with this level of incompetence are far easier to replace than the team below.

There is no good reason to put up with such a manager, but that should not automatically mean that the developers should resign. There is not necessarily something wrong with the business, just with this one individual. Fix that problem.

And to preempt any shushing from upper management, make it clear that this is not a forgivable mistake. It signals that the responsible manager has no understanding of the team he is managing. That does not lend itself to fixing, nor is there a need to in the current labor market. Managers are eminently replaceable just like sports coaches. Owners don't fire teams.

Now, this might look like a strategy that can backfire. But consider: if upper management sides with your manager regardless, you'd already be in a losing position anyway. So, if you only consider the situations in which you're not already in that losing position, the outcome will likely be far more positive. The real risk is that upper management just fires the whole team, including the manager. Only you can estimate that risk. Apparently your output is wanted, else they'd not ask for more of it, but at which price?


答:
TL;DR

Velocity is very useful for estimating schedules or generating planning values, and can also be a meaningful detective control for assessing process bottlenecks or changes in team capacity. It is not, however, a valid measure of productivity.

When Velocity is Confused with Management Targets

"Velocity" is a range that expresses a team's average capacity over some historical period. It is a statistical analysis of past performance, which can then be used to project probabilistic estimates of future workload capacity or cycle times. This is in stark contrast to a "scheduling target," which is a managerial objective that sets a timeline or goal for planning purposes.

Experienced agile project managers know that the proper use of velocity is to determine whether a team has the sustainable capacity to meeting management-defined scheduling targets. Sometimes the answer is yes, and everyone is happy. Sometimes the answer is no, at which point the iron triangle forces business decisions about scope, cost, time, and quality.

Evaluate Your Political Options

We have an average velocity of 50 story points...I have been asked to increase it by 40% to 70 story points (with no increase in team members).

Assuming that your estimation practices are sound and that your velocity is reasonably stable, your manager will get no joy from adjusting the estimate scale or setting management targets not based on historical performance. As you correctly point out, this is fundamentally a capacity problem.

The capacity limit may be related to the number of people on your team, or it may be a limitation of your organizational processes. Of course, adding more people doesn't always add actual project capacity either; see Brooks' Law for more on this common misconception.

The problem you face is political. From the tone of your post, it sounds like your manager wants to see an increase in productivity without making any actual changes to the team's underlying capacity. The solutions are therefore also political, and largely educational in nature.

If you are a Scrum shop, ask your Scrum Master to address this issue through the appropriate framework channels. Backlog Grooming and Sprint Retrospectives are often the ideal inspect-and-adapt opportunities for this particular issue.

If you're not a Scrum shop, you must decide what the proper way to address your concerns are within your organization. If you're on good terms with your manager, you might even loan him a copy of Agile Estimating and Planning for the two of you to discuss over lunch.

If all else fails, prepare for a death march by brushing up your resume, and doing your professional best until the project implodes. 68% of IT projects fail; unless management targets are solidly grounded in organizational capacity, yours will probably be one of them.


答:
I think having too many projects in a single solution is a bad thing. I have previously worked on the system that comprised of over 15 business domains. If I was to put them all into one solution, than I would end up with hundreds of projects. I suggest that you try and break these projects down into logical solutions (domains). In other words, work on separation of concerns. </p>

<p>In regards to build time - this can normally be improved. We had a system that took over an hour to build and after a year of work the time went down to under 10 minutes, which is a massive cost saving. </p>

Title: Partitioning code into assemblies for the sake of logical seperation

Body:
I've started working at this company, and the software is managed in a Visual Studio solution that includes hundreds of projects (C++ and C#).
After poking around the solution for couple of weeks, I started wondering why there are so many projects. Not only does it slows down VS considerably, but a rebuild can take up to an hour.

Since a visual studio project corresponds to a physical deployment unit (be it a .NET dll, a C++ lib or an exe), there are reasons why you'd want code partitioned across projects. Some of those reasons can be found in this article.

In my particular case, none of the reasons in that article stood. There are roughly 5 processes running across tiers, maybe a few dynamically loaded assemblies used for a plug-in model, and some infrastructure which is rarely changed.

I don't see any need for more than ~50 VS projects for this solution, and I believe that merging them will increase productivity and will allow for a shorter feedback loop.

When I tried to suggest this to the software manager, his response was that they are trying to have as many dlls as possible so that when they plan to ship a new feature, QA can test just the behavior of the modified dlls without having to worry that something else was effected. He said that since a dll was not changed, it will behave the same. For this to work they aim for high granularity of deployment units.

Does this make sense to anyone? I don't see the difference in the effect on behavior between  editing a single line in a project that has a single huge dll, and editing the same line in a project that includes hundreds of dlls.

EDIT

I'm looking for an answer on using assemblies/project as means for separating logical concerns and its effect on the testing effort. I would even go as far as saying that many assemblies that could give you more testing scenarios because of versioning incompatibilities.

So my distilled question is: When will you partition your code across projects/assemblies instead of namespaces in the same assembly, given that there are no runtime constraints, and why?

EDIT 2

I guess I'm looking for something like this article. However, I'm reluctant to post this as an answer and accept before I see if there are different opinions in the community.

Body:
I think having too many projects in a single solution is a bad thing. I have previously worked on the system that comprised of over 15 business domains. If I was to put them all into one solution, than I would end up with hundreds of projects. I suggest that you try and break these projects down into logical solutions (domains). In other words, work on separation of concerns.

In regards to build time - this can normally be improved. We had a system that took over an hour to build and after a year of work the time went down to under 10 minutes, which is a massive cost saving.


答:
In 'SOLID' the 'I' stands for Interface Segregation. The whole idea of this principle is to split large interfaces into smaller ones, more modular. In MVC service would normally have an interface that controller would rely upon. You don't want your controllers to know about concrete implementation of that service. Therefore, a bunch of services with one or two methods is a good thing to have.

Services normally return DTOs in large applications or domain models directly in smaller applications. DTOs normally means more work, but better separation of concerns. The typical flow is:

Controller calls service

Service returns an object (be it a DTO, domain model or something else)

Controller maps DTO/domain model to a view model

Mapping can be done manually, but most developers prefer to use auto mapping framework such as Automapper because we don't like writing plumbing code and we can be quite lazy :-)

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

https://github.com/AutoMapper/AutoMapper

One of many discussions on stackoverflow regarding use of DTOs and domain models: https://stackoverflow.com/questions/2680071/dto-or-domain-model-object-in-the-view-layer

Title: Use a service layer with MVC

Body:
If a controller gets too fat and model instantiation starts to add up, a service layer could be used.

If I just wrap the logic inside a service class, I will get a bunch of Services with one/two methods. This feels like a code smell. Any best practices regarding this?

Can a service instantiate models?

If a service instantiates models, the services can't be unit tested. They can only be covered by integration tests?


答:
Build/Release Branches

You should never deliberately commit broken code to a build branch. Any branch that is under continuous integration or from which releases or daily builds are made should always be in a potentially-releasable state.

Other Branches: Save State Often

For private or feature branches, the goals are often different. Frequent check-in of code (whether working or not) may be desirable. Generally, you will want to commit any time you may need to rewind to the current state.

Consider these examples where saved state provides a significant benefit:

You might perform a commit right before you run a global search-and-replace so you can revert your tree in a single operation if things go wrong.

You might perform a series of interim commits while refactoring a complex piece of code so that you can bisect or rewind if you end up breaking something in the process.

You might perform a commit, start a new branch, or create a tag when you want to try something experimental while being able to return to the state of the current working tree at any time.


问:
Is the Entity Component System architecture object oriented by definition?
Is the Entity Component System architecture object oriented, by definition?  It seems more procedural or functional to me.  My opinion is that it doesn't prevent you from implementing it in an OO language, but it would not be idiomatic to do so in a staunchly OO way.

It seems like ECS separates data (E & C) from behavior (S). As evidence:

The idea is to have no game methods embedded in the entity.

And:

The component consists of a minimal set of data needed for a specific purpose

Systems are single purpose functions that take a set of entities which have a specific component

I think this is not object oriented because a big part of being object oriented is combining your data and behavior together.  As evidence:

In contrast, the object-oriented approach encourages the programmer to place data where it is not directly accessible by the rest of the program. Instead, the data is accessed by calling specially written functions, commonly called methods, which are bundled in with the data.

ECS, on the other hand, seems to be all about separating your data from your behavior.

答:
Introduction

Entity–component systems are an object-oriented architectural technique.

There is no universal consensus of what the term means, same as object-oriented programming. However, it is clear that entity–component systems are specifically intended as an architectural alternative to inheritance. Inheritance hierarchies are natural for expressing what an object is, but in certain kinds of software (such as games), you would rather express what an object does.

It is a different object model than the “classes and inheritance” one to which you’re most likely accustomed from working in C++ or Java. Entities are as expressive as classes, just like prototypes as in JavaScript or Self—all of these systems can be implemented in terms of one another.

Examples

Let’s say that Player is an entity with Position, Velocity, and KeyboardControlled components, which do the obvious things.

```<code>entity Player:
  Position
  Velocity
  KeyboardControlled
</code>```

We know Position must be affected by Velocity, and Velocity by KeyboardControlled. The question is how we would like to model those effects.

Entities, Components, and Systems

Suppose that components have no references to one another; an external Physics system traverses all Velocity components and updates the Position of the corresponding entity; an Input system traverses all KeyboardControlled components and updates the Velocity.

```<code>          Player
         +--------------------+
         | Position           | \
         |                    |  Physics
       / | Velocity           | /
  Input  |                    |
       \ | KeyboardControlled |
         +--------------------+
</code>```

This satisfies the criteria:

No game/business logic is expressed by the entity.

Components store data describing behaviour.

The systems are now responsible for handling events and enacting the behaviour described by the components. They are also responsible for handling interactions between entities, such as collisions.

Entities and Components

However, suppose that components do have references to one another. Now the entity is simply a constructor which creates some components, binds them together, and manages their lifetimes:

```<code>class Player:
  construct():
    this.p = Position()
    this.v = Velocity(this.p)
    this.c = KeyboardControlled(this.v)
</code>```

The entity might now dispatch input and update events directly to its components. Velocity would respond to updates, and KeyboardControlled would respond to input. This still satisfies our criteria:

The entity is a “dumb” container which only forwards events to components.

Each component enacts its own behaviour.

Here component interactions are explicit, not imposed from outside by a system. The data describing a behaviour (what is the amount of velocity?) and the code that enacts it (what is velocity?) are coupled, but in a natural fashion. The data can be viewed as parameters to the behaviour. And some components don’t act at all—a Position is the behaviour of being in a place.

Interactions can be handled at the level of the entity (“when a Player collides with an Enemy…”) or at the level of individual components (“when an entity with Life collides with an entity with Strength…”).

Components

What is the reason for the entity to exist? If it is merely a constructor, then we can replace it with a function returning a set of components. If we later want to query entities by their type, we can just as well have a Tag component which lets us do just that:

```<code>function Player():
  t = Tag("Player")
  p = Position()
  v = Velocity(p)
  c = KeyboardControlled(v)
  return {t, p, v, c}
</code>```

Entities are as dumb as can be—they’re just sets of components.

Components respond directly to events as before.

Interactions must now be handled by abstract queries, completely decoupling events from entity types. There are no more entity types to query—arbitrary Tag data is probably better used for debugging than game logic.

Conclusion

Entities are not functions, rules, actors, or dataflow combinators. They are nouns which model concrete phenomena—in other words, they are objects. It is as Wikipedia says—entity–component systems are a software architecture pattern for modeling general objects.

Body:
Introduction

Entity–component systems are an object-oriented architectural technique.

There is no universal consensus of what the term means, same as object-oriented programming. However, it is clear that entity–component systems are specifically intended as an architectural alternative to inheritance. Inheritance hierarchies are natural for expressing what an object is, but in certain kinds of software (such as games), you would rather express what an object does.

It is a different object model than the “classes and inheritance” one to which you’re most likely accustomed from working in C++ or Java. Entities are as expressive as classes, just like prototypes as in JavaScript or Self—all of these systems can be implemented in terms of one another.

Examples

Let’s say that Player is an entity with Position, Velocity, and KeyboardControlled components, which do the obvious things.

entity Player:
  Position
  Velocity
  KeyboardControlled

We know Position must be affected by Velocity, and Velocity by KeyboardControlled. The question is how we would like to model those effects.

Entities, Components, and Systems

Suppose that components have no references to one another; an external Physics system traverses all Velocity components and updates the Position of the corresponding entity; an Input system traverses all KeyboardControlled components and updates the Velocity.

          Player
         +--------------------+
         | Position           | \
         |                    |  Physics
       / | Velocity           | /
  Input  |                    |
       \ | KeyboardControlled |
         +--------------------+

This satisfies the criteria:

No game/business logic is expressed by the entity.

Components store data describing behaviour.

The systems are now responsible for handling events and enacting the behaviour described by the components. They are also responsible for handling interactions between entities, such as collisions.

Entities and Components

However, suppose that components do have references to one another. Now the entity is simply a constructor which creates some components, binds them together, and manages their lifetimes:

class Player:
  construct():
    this.p = Position()
    this.v = Velocity(this.p)
    this.c = KeyboardControlled(this.v)

The entity might now dispatch input and update events directly to its components. Velocity would respond to updates, and KeyboardControlled would respond to input. This still satisfies our criteria:

The entity is a “dumb” container which only forwards events to components.

Each component enacts its own behaviour.

Here component interactions are explicit, not imposed from outside by a system. The data describing a behaviour (what is the amount of velocity?) and the code that enacts it (what is velocity?) are coupled, but in a natural fashion. The data can be viewed as parameters to the behaviour. And some components don’t act at all—a Position is the behaviour of being in a place.

Interactions can be handled at the level of the entity (“when a Player collides with an Enemy…”) or at the level of individual components (“when an entity with Life collides with an entity with Strength…”).

Components

What is the reason for the entity to exist? If it is merely a constructor, then we can replace it with a function returning a set of components. If we later want to query entities by their type, we can just as well have a Tag component which lets us do just that:

function Player():
  t = Tag("Player")
  p = Position()
  v = Velocity(p)
  c = KeyboardControlled(v)
  return {t, p, v, c}

Entities are as dumb as can be—they’re just sets of components.

Components respond directly to events as before.

Interactions must now be handled by abstract queries, completely decoupling events from entity types. There are no more entity types to query—arbitrary Tag data is probably better used for debugging than game logic.

Conclusion

Entities are not functions, rules, actors, or dataflow combinators. They are nouns which model concrete phenomena—in other words, they are objects. It is as Wikipedia says—entity–component systems are a software architecture pattern for modeling general objects.


答:
QA as a whole is about assessing the risk that the product is suitable for the users to use.  In reality, QA is not a 100% guarantee in part because it is usually impossible to test every possible action (including all non valid actions) in every possible environment.

Since you have limited QA resource, you have to make decisions about where to focus that resource to increase the likelihood that you detect critical bugs that have been missed by the developers.

The QA's comment about DLL's not changing means they can focus their testing effort better is correct. Although, it's correctness is decreased if the library is not version stamped by the autobuild system (how do you prove its the same DLL?) and its getting close to wrong if its a new DLL compiled from the same source code  (did compiler options / toolset change - producing a different library?)...   and if there is no mechanism that the QA actually do to audit that the source code between the two DLL's have not changed then its definitely wrong as QA cannot say with any confidence that a change has not slipped in.

I've worked on several teams that have large numbers of projects in the same solution file. It worked better for some than others. Things deteriorate when the number of projects files increase to such a point that Visual Studio starts becoming unstable.  However, on a well designed architecture, that designs the DLL's inter-dependencies to a minimum and has a strong release and version management process it can be made to work well.


问:
Best way to test a reimplemented web service
In my team, we are about to start the reimplement of a service. One of the important steps to do to accomplish this is how do we ensure that we are doing it in the right way and  we are not introducing new bugs.

So, what we have in mind is create a bunch of test to verify the following:

The behavior. Both services should behave the same way (store data in the same places, send same, notificacions, etc...)

Results. Object returned by the service's calls should be exactly the same.

So, the things that we have thought is to do the following:

Create a set of test that verifies the behavior and results of old service.

Create the new service adding unit test, and whitebox integration test for the new service

Create some kind of "Mirror test" that checks if the new service is working as the old one. Is there a way to do this?

Thanks for any help.

Note: None of the code of the previous version is reusable. There is no test for the older version of the service

[Edited]replaced original word "migrate" with "reimplement"

答:
I've worked on a re-implementation of a large IT project that faced this exact challenge.

There are several issues that you are likely to face.

The original implementation will have existing client apps which may be reluctant to change their client programs and retest to accommodate any changes.

The original implementation specifications may not reflect the original implementation. What is the goal for the replacement?

The original implementation is likely to have bugs.  Client apps are likely to have been programmed to accept the bugs as 'features'  Fix the bugs and break the client apps.

If the goal is a direct, drop in replacement, then you really do need to create replay tests that take test messages and their response from version 1, and create integration tests that pass these messages into version 2 and run diff on the output.

Some differences will be acceptable.  Time stamps, version numbers, some ID's etc...  but you will identify many bugs this way long before your client apps get near the rewritten system.  Some automated tools may help if your service is simple enough, but my guess is that you will end up scripting your own test suite.


答:
Are the users likely to be programmers/tech people themselves, precise description with only a few screenshots should be sufficient.

But if the users are non-tech people screenshots with precise descriptions will help a lot.
Keep in mind most people are not even aware of the technological terms you are probably using in your description. Try to ask any person using a computer what a radio button is.

Bottom line: Depends on your users


问:
Not copyrighting code and then reusing functions later
I'm coding something for my job to copy directories and then use regex to make all the filenames uniform.  I'm an undergrad student programmer for my university and I'm not sure what a professional coder would consider reasonable in this case. My job is mostly to implement mathematical research.  The current assignment is outside what I've been doing and seems like it would be really useful to have some of the functions available in case I (most likely) encounter a similar assignment at some point in my career in the future.  It's going to be really useful because the current filenames are so screwed right now that the admin assistants can't really keep up (and even trying to do so might just cause more human error).  I'm thinking that it may not overall be useful outside the current assignment because the regex will be so customised to the way the file are incorrectly named.

I'm wondering if this is simple work for a pro coder, and therefore I'm making this program to be much more important in my head than it actually is, or if this is something that a coder would really want to copyright or otherwise retain the ability to use this whenever and wherever else they feel like.  They've already told me that there is no question that I'll be given credit for the work, which I'm excited about.  My only concern was whether I should be thinking about reusing this code later or if this task is so generic that a pro coder would laugh about keeping the rights to such code.

This thread was interesting but seems different from my situation:

How can I reuse generic code for consulting between companies?

EDIT:

Florida, USA

答:
In the UK, the default owner of copyright is different from the accepted answer.

In the UK, copyright is, by default owned by the person who creates the line of code. However, if you are employed as a developer then:

It is normal for your terms of employment will include a clause to
assign ownership of 'designs' to your employer.

If your contract does not state it explicitly, because these terms
are a normal clause for software developers, they will still be deemed as 'implied' in the contract, unless you can get something in writing to counter this.

However, if your job role is not one that either does not have such a clause, or its not a normal for your job role to create intellectual property then you own copyright for your code.

It is often possible to get wavers of ownership from employers if you are contributing a to a non commercial project.


答:
Your manager has misunderstood the use of velocity. It is not a metric and it is not a target. Its purpose is the calibration of the team workload per sprint.

If you think about it, your velocity emerges from a best guess, which you remeasure after each sprint. Usually as time progresses, it should become somewhat stable. But that doesn't change the fact that it is a byproduct of what your team is actually doing: creating value for your customers.

The reason why it is wrong to use it as a target and/or a metric is because that would make it a vanity metric. It would look good on paper, but it would do absolutely nothing to reflect wether or not your products are fullfulling your customers needs. And that is what is most important (I hope).


问:
What is the exact semantic of reduce in clojure?
The Clojure docs regarding (reduce f val coll) state:

If val is supplied, returns the result of applying f to val and the
  first item in coll, then applying f to that result and the 2nd item,
  etc.

So I tried:

```<code>(reduce str ["s1" "s2"] "s3")
</code>```

Which leads to:

```<code>"[\"s1\" \"s2\"]s3"
</code>```

However, when I try

```<code>(apply str ["s1" "s2"])
</code>```

I get:

```<code>"s1s2"
</code>```

So why does the vector get converted into its string representation?

答:
Ok, I misread the docs. So reduce actually does this:

```<code>(str ["s1" "s2"] "s3")
</code>```

Which evaluates to:

```<code>"[\"s1\" \"s2\"]s3"
</code>```

Because str needs to convert its arguments to string!

Body:
Ok, I misread the docs. So reduce actually does this:

(str ["s1" "s2"] "s3")

Which evaluates to:

"[\"s1\" \"s2\"]s3"

Because str needs to convert its arguments to string!


问:
How do I unit test multi-threaded code?
Are there ways to unit test your multi-threaded code for race conditions and deadlocks?

To see if they are performing the way they should be...

答:
At JAOO/GOTO this year I saw this presentation:

http://gotocon.com/aarhus-2010/presentation/Testing%20Asynchronous%20Behaviour%20in%20an%20Instant%20Messaging%20Server

The trick is that you model what your hairball application is supposed to DO, in terms of invocation steps as well as the actual operations on your application.  John Hughes software then systematically tries many permutations of invocation steps repeatedly in parallel and checks afterwards that the state of the application corresponds with the state of the model.  If an error is found, the software knows how to reduce the steps to the minimal case producing the error.

He demonstrated live how to catch several bugs in core Erlang libraries which had been lurking for 15 years and occasionally reported but nobody could figure out where they came from and hence how to fix.  With the minimal cases reported by the software, the library maintainer was able to fix each bug within a day.

It was SO impressive.

John Hughes sells this software through his company.

Title: How do I unit test multi-threaded code?


答:
It's not Shlemiel's algorithm; getting page 16 takes pretty much exactly as long as getting page 1.

Yes, you do need a new query per page, but each of these queries gets only one page's worth of data. The alternatives are worse: If you get all data in one go and then filter it, you will still need one query per request, but now each of these queries gets the entire result set, and you'll be doing the partitioning in PHP - but a DBMS is much better at this than your hand-written PHP code. You could cache the whole thing, but this has two downsides: you still query the entire data set on first load, which means any request on a stale cache takes way longer than necessary, and you need to implement caching, which could add some significant overhead. Also, just like in the uncached example, you still need to do the pagination in PHP.

Should it turn out that your solution is too slow, you should first look at your database schema. Make sure you have the appropriate indexes on the relevant tables. Denormalize if you have to. If that doesn't cut it, consider caching individual pages.

And finally, if you need search functionality that scales, consider using something that specializes in indexing documents, e.g. Solr. These things are much better at indexing and searching documents than MySQL could ever hope to be.

Title: More efficient way to paginate search results

Body:
I'm making a website in PHP where the user can search a big MySQL database. The user is shown the first result. I want the next button to take the user to the next result, and so on.

The trivial solution is for each result page to execute the user's search query again and use OFFSET and LIMIT to get the n-th result that is displayed. But this feels like a Schlemiel the Painter's algorithm: re-executing the same query over and over to get to the n-th result is inefficient.

Since others must have faced this situation before: how is this typically solved?


问:
To rewrite or slowly refactor old C++ project
Our team has recently inherited a relatively large project from another company (~250k lines). It was developed using C++Builder and we intend to port the Ui side to Qt. Most of the Ui code is separate from the business logic (yay!) but the logic side is quite a mess.

There is a lot of diamond inheritance going on (virtual inheritance thankfully) but it makes understanding the code quite difficult to do.

We've got very little documentation to go on, what's there is out of date (comments included).

I generated class diagrams using Doxygen, here's the most complex one (I had to remove most of  the class names but kept some of the more important ones and kept the standard C++ data types and std classes, yes, they inherit from std)

So far we've been able to convert the base program to Qt and we're at a point where we can start converting the program's functionality bit by bit. Problem is, is it worth it long term? We would like to be maintaining this software as our own long term.

Is there a general approach we should take to untangling this kind of inheritance mess or should we simply redesign from scratch and only keep bits and pieces of the existing code as we go?

EDIT: Some more info

Zavior posted a link to an article about why we should not start from scratch but Ptolemy also brought up some good questions and I'd like to add some information about our situation.

The program we have is not 'bug free.' There are known issues that users have workarounds for most. There is no 'list' of these issues, that is currently being compiled by talking to all the existing users one by one as they tend to keep things to themselves.

We are all new developers to this project. Our only resource is a developer who started working on the project about half-way through its lifetime. He is available via e-mail/chat mostly. He has also put together some documentation on how some parts of the code work.

The program has only been used as an internal tool so far. We would like to make it commercially viable.

EDIT 2:

One of the most important things we want to do is have the program be in Qt. It's currently using the VCL framework from C++Builder that no one on our team is familiar with and we only have 1 license for. It's during my work porting from VCL to Qt that I found the messy code structure and question the decision to 'convert' vs redo.

答:
If you re-write & re-design from scratch, you're going to have two MASSIVE problems:

You don't have a spec. You might think you have a spec, but it turns out that the REAL spec is the old code. So you're going to have to dig into it to figure out what it really does, just so you know what to make the new system do.

You'll have a long period (looking at that class hierarchy, possibly years) in which you won't have a saleable product. Which means you either have to maintain the old one in parallel, or give up on shipping anything for a long time.

It stinks, but you probably need to just try to make the old one better. Write tests for everything you touch, don't hesitate to rip out a big section to make it better, but don't try to re-write it all at once. The project may not survive such an attempt.


答:
When I've implemented large scale re-factoring on projects, I've generally used the strategy of doing the architecture afresh, and proving the architecture first, whilst development continues on the original project.  When the new architecture has been proven, there is a large amount of transferring existing logic to the new architecture. This seems to be best done quickly, rather than as a background task.

Is it worth doing?  That's a difficult one to judge without being there on the project but think about these issues:

Is the existing code base stable and bug free? If you are having to spend significant time finding and patching the existing code without really understanding it, the time saved by a reduction in support by reimplementing using understood code can be significant.

Do you have at least as much knowledge of the product as the original coders? How much of the complexity is due to bug fixes for unexpected situations, and how much was poor design?

Do you have the time to finish the task?  One of the things I value most about a code base is consistency. Inconsistent code is a nightmare to support, extend and introduce to new members of the team.

If you have not got a substantial understanding of the products business rules, you are likely to do worse job than the current version.

Conclusion - based on the questions updates, is that you do not have enough knowledge of the project to do a re-implementation. In your current situation, even doing a significant re-factor is risky.  The good news at least, is that the current customers are not hit with bugs that prevent them from using the product, which means you have time to understand the code base.  This needs to be your first goal.

Title: To rewrite or slowly refactor old C++ project

Body:
Our team has recently inherited a relatively large project from another company (~250k lines). It was developed using C++Builder and we intend to port the Ui side to Qt. Most of the Ui code is separate from the business logic (yay!) but the logic side is quite a mess.

There is a lot of diamond inheritance going on (virtual inheritance thankfully) but it makes understanding the code quite difficult to do.

We've got very little documentation to go on, what's there is out of date (comments included).

I generated class diagrams using Doxygen, here's the most complex one (I had to remove most of  the class names but kept some of the more important ones and kept the standard C++ data types and std classes, yes, they inherit from std)

So far we've been able to convert the base program to Qt and we're at a point where we can start converting the program's functionality bit by bit. Problem is, is it worth it long term? We would like to be maintaining this software as our own long term.

Is there a general approach we should take to untangling this kind of inheritance mess or should we simply redesign from scratch and only keep bits and pieces of the existing code as we go?

EDIT: Some more info

Zavior posted a link to an article about why we should not start from scratch but Ptolemy also brought up some good questions and I'd like to add some information about our situation.

The program we have is not 'bug free.' There are known issues that users have workarounds for most. There is no 'list' of these issues, that is currently being compiled by talking to all the existing users one by one as they tend to keep things to themselves.

We are all new developers to this project. Our only resource is a developer who started working on the project about half-way through its lifetime. He is available via e-mail/chat mostly. He has also put together some documentation on how some parts of the code work.

The program has only been used as an internal tool so far. We would like to make it commercially viable.

EDIT 2:

One of the most important things we want to do is have the program be in Qt. It's currently using the VCL framework from C++Builder that no one on our team is familiar with and we only have 1 license for. It's during my work porting from VCL to Qt that I found the messy code structure and question the decision to 'convert' vs redo.


答:
it depends on your business situation.

assume that

it will take a long time to totally refactor the code, especially since you are new to the code base in the first place and can't forsee like you could if you were refactoring your own first draft code.

given this assumption, you must consider the business need for porting this code.  you said that you wanted 'to maintain' the code.  what exactly does that entail? are you going to be adding additional functionality?  or just fixing minor output bugs or logically easy, but showstopping, crashes.

what other benefits would you get from refactoring?  would the code be more portable or usable in a new environment or OS? be more easily integrated into a project that together will adequately serve a business need?

take these questions into consideration when decide or present a case.

consider the short, medium, and long term objectives of this task.  it may cost a lot in the short term to refactor, but  if you intend to keep the conceptual model around, it very well could serve as the basis for a whole new generation of products.

conversely, if you are having wholesale changes in your business environment that may make, not just the messy code, but the entire conceptual model obsolete , it may be better to just cherry pick the 10 buggiest or confusing pieces, rewrite them in original language, but clearly, and move on.  just keep it alive, and save money, and build something you really want later,taking lessons from what you have and like and don't like/need to guide you


答:
Rewriting a project of this size is doomed to fail due to the reasons in Michael Kohne's post.

Refactoring a buggy codebase is difficult because you'll never know if bugs are due to your refactoring or due to the original code.

I would take the approach of doing nothing but bug fixes for a significant period of time.  As part of these bug fixes, you can rewrite small sections that are blatantly wrong.  The benefits of this are:

Gives the developers the opportunity to learn a lot about the code, architecture, and product behavior.  You will need this knowledge to do any significant refactoring.

Stabilizes the codebase prior to any major restructuring work.

You can sell the stabilized product while major changes are made later.

It also sounds like you desperately need a bug tracking system and some sort of QA to find bugs & verify fixes.


问:
What is the preferred strategy for editing data from a database?
We are redesigning an old VB6 application in Net. The application makes extensive use of a database and includes management of club members and their results in the competitions that they partake in.

So, if we are editing a club member's name, address, etc. it is obvious not to send the data back to the database until the entire edit or add operation has been completed by the user.

But how to do this when registering and editing scores of matches? The advantage of sending each added or edited score directly to the database is that it enables live updates of the rankings. The disadvantage is that undoing changes may be more difficult and that there may arise performance problems when the connection to the database has a high latency. The latter problem might come up at some stage, but for the unforseeable future we will work with desktop versions of the database.

I would be interested in descriptions of best practices and live experiences.
Thanks!

答:
Personally, I would consider the end architecture that you are aiming for, and think about what consequences this has on the implementation.

The simplest approach is to do a 'database application' where you make the application tightly coupled to the database. Its simple, quick and works well on a desktop, and as a single user system, data locking strategies can be non-existent. However, high latency to the database is not an option with this approach - so don't expect to make this an internet or hosted solution in the future.

The other end of the scale is to have a multi-tier architecture. Database, behind a stack of web services (either SOAP or REST) that enable a client application (or another web server providing a web interface) to query and update data in the database.  This approach scales to the internet and can be hosted fairly cheaply. It can also be set up on a desktop, but is a database and a web server...  but is much more development effort.

Since you are asking this question, my instinct is to recommend the first approach to you, on the basis that you are more likely to be successful and have something working.  At a later stage the advantages of the distributed approach for the club, such as not being reliant on 'Fred' doing all the updates as the database is on his laptop can be introduced without the time pressure of needing something as soon as...


问:
How to write comments to explain the "why" behind the callback function when the function and parameter names are insufficient for that?
How should I approach writing comments for callback functions?  I want to explain the "why" behind the function when the function and parameter names are insufficient to explain what's going on.

I have always wonder why comments like this can be so ordinary in documents of libraries in dynamic languages:

```<code>/**
 * cb: callback    // where's the arguments & effects?
 */
 func foo( cb )
</code>```

Maybe the common attitude is "you can look into source code on your own after all" which pushes people into leaving minimalist comments like this.

But it seems like there should be a better way to comment callback functions.

I've tried to comment callbacks in Haskell way:

```<code>/**
 * cb: Int -> Char
 */
func foo(cb)
</code>```

And to be fair, it's usually neat enough.

But it gets into trouble when I need to pass some complex structure.  The problem being partly due to the lack of type system:

```<code>/**
 * cb: Int -> { err: String -> (), success: () -> Char }  // too long...
 */
func foo(cb)
</code>```

Or I have tried this too:

```<code>/**
 * cb: Int -> { err: String -> (),
 *              success: () -> Char }  // better ?
 */
func bar(cb)
</code>```

The problem is that you may put the structure in somewhere else, but you must give it a name to reference it.
But then when you name a structure you're about to use immediately looks so redundant:

```<code>// Somewhere else...
// ResultCallback: { err: String -> (), success: () -> Char }

/**
 * cb: Int -> ResultCallback    // better ??
 */
func foo(cb)
</code>```

And it bothers me if I follow the Java-doc like commenting style since it still seems incomplete.  The comments don't tell you anything that you couldn't immediately see from looking at the function.

```<code>/**
 * @param cb {Function}  yeah, it's a function, but you told me nothing about it...
 * @param err {Function} where should I put this callback's argument ??
 *                       Not to mention the err's own arguments...
 */
func foo(cb)
</code>```

These examples are JavaScript like with generic functions and parameter names, but I've encountered similar problems in other dynamic languages which allow complex callbacks.

答:
It depends upon how you're writing your callback functions.

If they're stand-alone functions, then you can use the same commenting methodology that you would use for any other function.

If they're lambda like functions, embedded within other functions, then you start running into problems.  You might try to mimic the commenting methods that you would use for a stand-alone function.  But by the time you need that level of commenting, you shouldn't be using a lambda function for your callback to begin with.

Lambda functions can be very powerful, but their purpose should be obvious and they shouldn't scroll for page after page.

On a related note, your function names and variables should be descriptive enough to convey what they're doing.  For example, use "result" or "results" instead of "callback."  Just because you're writing generic / re-usable code doesn't mean you can't use descriptive terms with the parameters.

It's also important not to mix your programming paradigms.  Haskell (a functional language) has different idioms than JavaScript.  Mixing style is a bad idea and will make your code more difficult to maintain.  There's an old programmer's saying of "You can write bad COBOL in any language."