问:
Are there laws to protect us from hackers who disclose vulnerabilities prior to alerting the vendor?
Take the example of the recent ASP.NET (and Java Server Faces) vulnerability disclosure at a Hacker conference in Brazil.  It's my understanding that the poet tool was demonstrated before Microsoft was even aware of the issue.

Are there laws to protect legitimate customers from people who encite the hacker community to start hacking all the ASP.NET servers they can?  Who knows how many legitimate businesses were compromised between when the tool was demoed and the patch was applied to the server.

答:
None that I know of, and there probably shouldn't be, either.

Who knows how many legitimate businesses were compromised between when the tool was demoed and the patch was applied to the server.

Who knows how many legitimate business were compromised before the tool was demoed?  You seem to be making the assumption that because of this demo at a conference in Brazil that that was the first any bad guys heard of it.


问:
How to create scalable & side-effect free integration tests?
In my current project, I am having a hard time coming up with a good solution to create scalable integration tests that have no side effects. A little clarification on the side effect free property: it is mostly about the database; there shouldn't be any changes in the database after the tests are completed (state should be preserved). Maybe scalability and state preservation don't come together, but I really want to push for a better solution.

Here is a typical integration test (these tests touch the database layer):

```<code>public class OrderTests {

    List<Order> ordersToDelete = new ArrayList<Order>();

    public testOrderCreation() {
        Order order = new Order();
        assertTrue(order.save());
        orderToDelete.add(order);
    }

    public testOrderComparison() {
        Order order = new Order();
        Order order2 = new Order();
        assertFalse(order.isEqual(order2);
        orderToDelete.add(order);
        orderToDelete.add(order2);
    }
    // More tests

    public teardown() {
         for(Order order : ordersToDelete)
             order.delete();
    }
}
</code>```

As one might imagine, this approach yields tests that are extremely slow. And, when applied to the whole integration tests, it takes around 5 seconds to test only a small portion of the system. I can imagine this number going up when the coverage is increased.

What would be another approach for writing such tests? One alternative I can think of is having kind of global variables (within a class) and all test methods share this variable. As a result, only few orders get created & deleted; resulting in faster tests. However, I think this introduces a bigger problem; the tests are no longer isolated and it gets more and more difficult to understand & analyze them.

It might just be that integration tests are not meant to be run as often as unit tests; therefore low performance might be acceptable for those. In any case, it would be great to know if someone came up with alternatives for improving scalability.

答:
This is the eternal problem that everyone faces while writing integration tests.

The ideal solution, particularly if you're testing on production, is opening a transaction in setup and rolling it back in teardown. I think this should suit your needs.

Where that isn't possible, for example where you're testing the app from the client layer, another solution is to use a DB on a virtual machine and take a snapshot in setup and go back to it in teardown (it doesn't take as long as you might expect).

ContentLicense: CC BY-SA 3.0


答:
Look into using Hypersonic, or another in-memory DB for unit testing.  Not only will the tests execute faster, but side-effects aren't relevant.  (Rolling back the transactions after each test also makes it possible to run many tests on the same instance)

This will also force you to create data mockups, which is a good thing IMO, as it means something that occurs on the production database can't inexplicably start failing your tests, AND it gives you a starting point for what a "clean database install" would look like, which helps if you need to suddenly deploy a new instance of the application with no connection to your existing production site.

Yes, I do use this method myself, and yes it was a PITA to set up the FIRST time, but it's more than paid for itself in the lifetime of the project I'm about to complete.  There are also a number of tools that help with the data mockups.

Title: How to create scalable & side-effect free integration tests?

Body:
In my current project, I am having a hard time coming up with a good solution to create scalable integration tests that have no side effects. A little clarification on the side effect free property: it is mostly about the database; there shouldn't be any changes in the database after the tests are completed (state should be preserved). Maybe scalability and state preservation don't come together, but I really want to push for a better solution.

Here is a typical integration test (these tests touch the database layer):

```<code>public class OrderTests {

    List<Order> ordersToDelete = new ArrayList<Order>();

    public testOrderCreation() {
        Order order = new Order();
        assertTrue(order.save());
        orderToDelete.add(order);
    }

    public testOrderComparison() {
        Order order = new Order();
        Order order2 = new Order();
        assertFalse(order.isEqual(order2);
        orderToDelete.add(order);
        orderToDelete.add(order2);
    }
    // More tests

    public teardown() {
         for(Order order : ordersToDelete)
             order.delete();
    }
}
</code>```

As one might imagine, this approach yields tests that are extremely slow. And, when applied to the whole integration tests, it takes around 5 seconds to test only a small portion of the system. I can imagine this number going up when the coverage is increased.

What would be another approach for writing such tests? One alternative I can think of is having kind of global variables (within a class) and all test methods share this variable. As a result, only few orders get created & deleted; resulting in faster tests. However, I think this introduces a bigger problem; the tests are no longer isolated and it gets more and more difficult to understand & analyze them.

It might just be that integration tests are not meant to be run as often as unit tests; therefore low performance might be acceptable for those. In any case, it would be great to know if someone came up with alternatives for improving scalability.


问:
What are the pros and cons of directly exposing a Table/View entity class to the client?
I'm developing a multi-tier application. We separate our project into three logical layers: client, service and data access. However, almost all methods in the service layer don't do anything except returning table/view from DAL to the client and then the client continues processing data. More than 50% of the returned data is bigger than it really needs to be. For example the client needs a username and an email-address but the service layer returns way more data. This is the coding standard in my team. I tried to change this by shaping classes that return what the client really needs but they wanted me to change it back after I had done it.

I'm curious what are the pros and cons of doing things that way?

答:
If the clients request many different groupings of data and if you don't give them the ability to request the data they want through some type of query language, constructing classes to return various data combinations will be a never ending battle. For every entity the possible number of combinations can be absolutely huge if the number of fields is more than a few.

So if the classes created only serve to limit the amount of data returned then the work probably wouldn't be worth it. Unless of course there are very common data groupings that are requested often by many different clients.

Now if you want to simply limit the amount of data returned you could create classes that lazy load the fields as they are requested. Depending on architecture this could be beneficial. But in many cases lazy loading actually hurts overall scalabilty and performance.


问:
Why does TDD work?
Test-driven development (TDD) is big these days. I often see it recommended as a solution for a wide range of problems here in Programmers SE and other venues. I wonder why it works.

From an engineering point of view, it puzzles me for two reasons:

The "write test + refactor till pass" approach looks incredibly anti-engineering. If civil engineers used that approach for bridge construction, or car designers for their cars, for example, they would be reshaping their bridges or cars at very high cost, and the result would be a patched-up mess with no well thought-out architecture. The "refactor till pass" guideline is often taken as a mandate to forget architectural design and do whatever is necessary to comply with the test; in other words, the test, rather than the user, sets the requirement. In this situation, how can we guarantee good "ilities" in the outcomes, i.e. a final result that is not only correct but also extensible, robust, easy to use, reliable, safe, secure, etc.? This is what architecture usually does.

Testing cannot guarantee that a system works; it can only show that it doesn't. In other words, testing may show you that a system contains defects if it fails a test, but a system that passes all tests is not safer than a system that fails them. Test coverage, test quality and other factors are crucial here. The false safe feelings that an "all green" outcomes produces to many people has been reported in civil and aerospace industries as extremely dangerous, because it may be interepreted as "the system is fine", when it really means "the system is as good as our testing strategy". Often, the testing strategy is not checked. Or, who tests the tests?

In summary, I am more concerned about the "driven" bit in TDD than about the "test" bit. Testing is perfectly OK; what I don't get is driving the design by doing it.

I would like to see answers containing reasons why TDD in software engineering is a good practice, and why the issues that I have explained above are not relevant (or not relevant enough) in the case of software. Thank you.

答:
Design first

TDD is not an excuse to skip design.  I've seen many jump in the "agile" bandwagon because they though they could start coding immediately.  True agile will get you to stat coding much faster than the (other field) engineering good practices that inspired the waterfall process.

But test early

When one say that the test are driving the design it simply means that one can use tests very early in the design phase, long before it is complete.  Doing this tests will strongly influence your design by challenging the grey areas and pitting it against the real world long before the product is completed.  forcing you often to go back to design and adjust it to take this into account.

Test and design...  one and the same

In my opinion TDD simply brings test to be an integral part of design instead of something done at the end to validate it.  As you start using TDD more and more you get in the mindset of how to destroy/break your system as you design it.  Personally I do not always do my tests first.  Sure I do the obvious (unit) tests on an interface but the real gains come from the integration and specification tests that I create when I think of a new and creative way this design can break.  As soon as I think of a way, I code a test for it and see what happens.  Sometimes I can live with the consequence, in this case I move the test in a separate project that is not part of the main build (since it will continue to fail).

Then who drive the show ?

In TDD the driven here simply means that your tests influence so strongly your design that one can feel they are actually driving it.  However it one stops at that, and here I understand your concerns, it is a bit scary... who drives the show ?

YOU are driving, not the tests.  The tests are there so that as you move along you gain a good level of confidence in what you have created thus allowing you to build further knowing it rests on solid grounds.

solid so long as the tests are solid

Exactly, hence the driven in the TDD.  It is not so much the tests are driving the whole thing, but they will have such deep influence over how you do things, on how you design and think your system that you will delegate a large chunk of your thought process to tests and in return they will have a deep influence on your design.

yeah but if I do that with my bridge th....

stop right there...   software engineering is VERY different from any other engineering practices out there.  In fact software engineering has actually a lot more in common with literature.  One can take a finished book, rip a 4 chapters from it ans write two new chapters to replace them stick them back in the book and you still have a good book.  With good tests and software you can rip any part of your system and replace it with another and the cost of doing so is not much higher that it was creating it in the first place.  In fact, if you did your tests and allowed them to influence your design enough it may very well be cheaper than creating it in the first place since you will have a certain level of confidence that this replacement will not break what the tests are covering.

If its sooo good how come it does not always work ?

Because testing requires a VERY different mindset than building does.  Not every one is able to switch back and from, in fact some people will not be able to build proper tests simply because they cannot set their mind to destroy their creation.  This will yield projects with too few tests or tests just enough to reach a target metrics (code coverage comes to mind).  They will happy path tests and exception tests but will forget about the corner cases and boundary conditions.

Others will just rely on tests forgoing design partly or altogether.  Each member doing it's thing then integrating with one-another.  Design is first and foremost a communication tool, stakes we set in the ground to say this is where I will be, sketches that say this is where the doors and windows will be.  Without this your software is doomed regardless of how many tests you put in the thing.  Integration and merges will always be painful and they will lack tests at the highest levels of abstractions.

Tor these teams TDD may not be the way to go.

Title: Why does TDD work?


问:
Why should I know concurrent programming?
Concurrent programming is quite difficult to me: even looking at a basic slide seems challenging to me. It seems so abstract. </p>

<p>What are the benefits to knowing Concurrent programming concepts well? Will it help me in regular, sequential programming? I know there is a satisfaction to understanding how our programs work, but what else? </p>

答: Learn the insight of operating systems. Reading the source code of schedulers and device drivers will help; they are definitely concurrent.</p>


答:
Here's a quick and easy motivation: If you want to code for anything but the smallest, weakest systems, you will be writing concurrent code.

Want to write for the cloud? Compute instances in the cloud are small. You don't get big ones, you get lots of small ones. Suddenly your little web app is a concurrent app. If you designed it well, you can just toss in more servers as you gain customers. Else you have to learn how while your instance has its load average pegged.

OK, you want to write desktop apps? Everything has a dual-or-more-core-CPU. Except the least expensive machines. And people with the least expensive machines probably aren't going to fork over for your expensive software, are they?

Maybe you want to do mobile development? Hey, the iPhone 4S has a dual-core CPU. The rest won't be far behind.

Video games? Xbox 360 is a multi-CPU system, and Sony's PS3 is essentially a multi-core system.

You just can't get away from concurrent programming unless you are working on tiny, simple problems.

2016 update: The current iteration of the $35 Raspberry Pi is built around a quad-core system on a chip intended for cell phones. Dramatic advances in AI have been made in part due to the availability of high-end graphics cards as parallel compute engines.

Title: Why should I know concurrent programming?

Body:
Concurrent programming is quite difficult to me: even looking at a basic slide seems challenging to me. It seems so abstract. </p>

<p>What are the benefits to knowing Concurrent programming concepts well? Will it help me in regular, sequential programming? I know there is a satisfaction to understanding how our programs work, but what else? </p>


问:
VPN or TLSv1 for securing a programs protocol from field device to mainframe
I am working on a product that requires devices to exists anywhere in the world hooked up to the internet though cell modems or on WLAN lines which communicates to a server(s) that exists elsewhere in the world.

When deigning the networking portion of the program i cant figure what the best option is for securing the communication between the server and end device.

From my searches iv'e come up with two options.

Option 1: Using a host to host vpn connection between the two devices.

Pros: VPN software seems to be well tested and does not require extra programming for the network protocol. The IT department is more comfortable with it because of using software that is already tested and they comfortable with vpn.

Cons: Since my end devices are linux on OMAP platforms cross compiling the vpn software if not already done could be tricky. Dealing with firewalls and routers behind the end devices network. Setup of the connection can be tricky.

Option 2: Implementing the TLSv1 protocol in my program to deal with the encryption.

Pros: Does not require extra software to be running on the device. Only relies on the encryption libraries as a dependency. Don't have to worry about dealing with nats and firewalls because the protocol will only require one tcp port to be open.

Cons: Extra coding to the network software. IT is skeptical because our program is responsible for securing the protocol.

FYI: For implementing the TLSv1 i would use http://www.gnu.org/software/gnutls/

答:
Using VPN and adding TLS capability to your program are two independent answers, dealing with different protocol layers with each other.

VPN secures the network packets between two hosts. On the other hand, TLS capability of your program will secure the communication between the two programs regardless of the underlying protocols, including the physical layer (WLANs or modem links).

If you're trying to use your program where VPNs are not available, TLS is mandatory.


问:
If a language changes quickly, is this considered a good thing?
I have seen some languages that change quickly (I mean they are improved every year for example) and some others that are improved slowly.

My question, if a language changes quickly is this a good thing or a bad thing for the programmer? Do programmers like to learn new thing in the language or do they prefer to stick with what they already know?

答:
Language stability is a must for business and for developers. Changes in the language are welcome if they solve problems or introduce features that were missed in earlier releases, but changing languages so that it is trendy or just because you want to catch-up with a competitor is not that good.

When the language is stable, over time, developers stop focusing efforts on learning the language because they would have mastered it and start focusing their efforts on serving the business with what they know. The result is shorter project, happy end users and more proud developers!

Change also comes with learning cost and time. Not all employers are willing to educate developers in new features. This adds a significant burden on the developers to train themselves or else - This is not trivial, specialized courses can be $1500-$3500 each!

Continuous change can lock developers in 'legacy' software. Take the case of ASP developer who did not catch with MVVM in 2 years from now or the case of a Windows Forms developer that did not learn WPF. This locking may hurt the developer career significantly.

Overtime, the architecture of software in a business becomes to look like a garden salad. All sorts of tools and versions and you find projects starting to do nothing but upgrading software from one version to the next without any business gain.


问:
Is it true that websites don't need to use an event driven framework given the stateless nature of the web?
I feel like it's critical to use an event driven architecture with a lot of application types that aren't web sites. However, when coding web sites(which are stateless at the most basic level) it seems like it isn't really necessary to use an event driven architecture.

Is this true? Do most web frameworks not use events to communicate between objects?

答:
The stateless nature of HTTP does complicate event driven programming for the web, but not that much, as state or the perception of state is very easy to build. There are several event driven frameworks for the major web languages out there, one example for php is Prado, and every web platform with a capable application server.

That being said, it's also mostly true that web developers and our tools are not especially geared towards event driven development. My perception is that events are useful mostly on the front end (where it should be noted that javascript is event driven) and don't really add much to the back end. From a historical point of view, state wasn't always that easy to build and we've trained ourselves to be able to leave without it, to the point that when state became actually easy to build we only use it for it's truly essential purposes as we have already covered all our bases for all the stuff that events would be useful for.

On a more generic note, when moving from coding for the desktop to coding for the web or coding for mobile phones, you should be ready for a change of mentality. Several techniques that are essential to desktop apps are not so on another platform (medium, architecture) and vice versa. Every developer of every platform (m, a) likes and benefits from staying as close to the platform's (m, a) low level / core technologies and protocols. Events, although 100% possible and useful and some times completely necessary, are somewhat unnatural to back end web development.


问:
How to do TDD for something with many permutations?
When creating a system like an AI, which can take many different paths very quickly, or really any algorithm that has several different inputs, the possible result set can contain a large number of permutations.

What approach should one take to use TDD when creating a system that outputs many, many different permutations of results?

答:
Strict TDD does tend to break down a bit for more complex systems, but that doesn't matter too much in practical terms - once you get beyond being able to isolate individual inputs, just pick some test cases that provide reasonable coverage and use those.

This does require some knowledge of what the implementation will be to do well, but that is more of a theoretical concern - you are highly unlikely to be building an AI that was specified in detail by non-technical users. It's in the same category as passing tests by hardcoding to the test cases - officially the test is the spec and the implementation is both correct and the fastest possible solution, but it never actually happens.


问:
How do Programmers in the East see programmers in the West?
The other half of this question: How do programmers in the West see programmers in the East?

I think it's just as interesting and important to see how programmers in the east view programmers in the west.

The eastern part of the world (India/China/Philippines ) is often seen as mainly providing outsourcing services to the western world (USA and Europe).

Do you have the experience of working as part of an offshore team? If yes, how was it?

Do you hold any generalized ideas or opinions about the programmers from the West (e.g. Are they cooperative, do they deliver on time or do they do quality work?)

答:
```<code>in india most of us are programmers not by choice but by our circumstances.
</code>```

the example of this is that one of much reputated company tata consultancy services employee give the wrong answer in KBC(indian version of who wants to be millionaire ) and question  is ?

what you not find genrally  on google home page ?

and options are

gmail youtube facebook Orkut

and he answered youtube

so you can have now have idea in INDIA  most of the companies hire just fresher engineer and give training them what they have to do daily ??? and there is no change in daily work same timings same work no challenge no learning no research

Body:
in india most of us are programmers not by choice but by our circumstances.

the example of this is that one of much reputated company tata consultancy services employee give the wrong answer in KBC(indian version of who wants to be millionaire ) and question  is ?

what you not find genrally  on google home page ?

and options are

gmail youtube facebook Orkut

and he answered youtube

so you can have now have idea in INDIA  most of the companies hire just fresher engineer and give training them what they have to do daily ??? and there is no change in daily work same timings same work no challenge no learning no research


答:
I don't think there's any one answer that's right.

Generally speaking, when a language is relatively young, there's a lot more freedom to make relatively large changes relatively quickly. There's not a large base of existing code to break, so people are generally much more open to experimentation.

As the language ages, assuming it comes into wide enough user for anybody to really care, the base of existing code starts to place tighter and tighter restrictions on what changes can be made. Not only is there more code making use of more features so it's harder to guess what changes might break code, but people's expectations change.

Just for example, let's assume there were about the same number of people writing Ruby and Fortran. Furthermore, let's assume there was about the same amount of code in both. I'd say the chances are pretty good that a change that broke exactly the same percentage of each (and in a way that took about the same work to correct) would be a lot more acceptable to Ruby users than Fortran users as a general rule (at least assuming they saw it as an improvement).

I think a lot also depends on people's perception of the language to start with. People who choose a language because it's "cutting edge" are a lot more likely to put up with major changes that break a lot of existing code, if that's what it take to keep it on the cutting edge.

Another factor is the size and life expectancy of the projects for which the language is intended. A language that caters to relatively small projects or ones we know up-front have a short life expectancy (e.g., a web UI) can get away with breaking things relatively frequently, because it's unlikely many people are going to continue using the same code base for, say, 10 years any way. A language (e.g., C++ or Java) that caters more for larger, longer lived projects that may take, say, 5 years to get to an initial release, may be in regular use (and continuous development) for three or four decades obviously demand a great deal more stability.

Title: If a language changes quickly, is this considered a good thing?

Body:
I have seen some languages that change quickly (I mean they are improved every year for example) and some others that are improved slowly.

My question, if a language changes quickly is this a good thing or a bad thing for the programmer? Do programmers like to learn new thing in the language or do they prefer to stick with what they already know?


答: There are more elder and experienced programmers in west while there are more younger and elder managers in India. Ok there are few programmers also in India. Becoming a manager from a developer is seen as career advancement and I hate this perception.</p>

Title: How do Programmers in the East see programmers in the West?

Body:
The other half of this question: How do programmers in the West see programmers in the East?

I think it's just as interesting and important to see how programmers in the east view programmers in the west.

The eastern part of the world (India/China/Philippines ) is often seen as mainly providing outsourcing services to the western world (USA and Europe).

Do you have the experience of working as part of an offshore team? If yes, how was it?

Do you hold any generalized ideas or opinions about the programmers from the West (e.g. Are they cooperative, do they deliver on time or do they do quality work?)


问:
Are there best practices for checking for errors in business logic for DB refreshes?
I'm working for a company with very large databases which all refresh overnight, ready for users to interrogate in the morning.  These over night loads essentially truncate all the tables, and reload again using pretty complicated business logic.

This is all fine and good, but occasionally, rather than going through the proper routes, a quick fix is needed in the business logic, and changes will be made on the "Live" server to the business logic without too much testing.

This has, as I'm sure you can imagine, resulted in subtle but significant mistakes being made.  I basically want to now independently write logic (in T-SQL probably) which will try to spot any abnormal changes, so at least I'm ahead of the game, and can report them sooner.

My question is, fairly obviously, does anyone have any advice on this?  Is there any theory or general good practice which I could incorporate to hopefully limit the impact of future "quick and dirty" changes to business logic?

Just so you know, we do use source control, and use Live, UAT, and Dev server environments, its just that sometimes, changes need to made immediately, rather than going through the stricter channels.

答:
If you have many such changes, then your organization has to face the fact that the installed software does not match the business requirements. Accordingly, the organization should launch a project to determine the gap and fix the existing software and eventually publish a new release or version.

If your organization desire quality, there is no substitute for following proper development, testing and promotion procedures which take time and effort.


答:
I'm presuming that the overnight run is calling stored procedures.  If you can't write a text log & get access to it fight for it.  DBAs can sometimes be a bit possessive of logs because they don't like developers reading them and asking difficult questions ;).

Assuming you lose the fight, create a simple logging table and a logging library (if your RDBMS doesn't have one).  Then during the run write entries to the table.  You want these entries outside of the main transaction so you get "encountered error type XYZ in record ABC rolling back" type entries in the log instead of having the error log rolled back as well.

Then, first thing you do in the morning is scan the days log entries & look for issues.

Over time you may encounter data issues that don't get logged.  If you get an unlogged issue, write code to identify and log the problem before you fix the code (a bit like TDD).  That way, like unit tests the assumptions about the data will be documented and tested and exceptions logged so you can fix them.

Title: Are there best practices for checking for errors in business logic for DB refreshes?

Body:
I'm working for a company with very large databases which all refresh overnight, ready for users to interrogate in the morning.  These over night loads essentially truncate all the tables, and reload again using pretty complicated business logic.

This is all fine and good, but occasionally, rather than going through the proper routes, a quick fix is needed in the business logic, and changes will be made on the "Live" server to the business logic without too much testing.

This has, as I'm sure you can imagine, resulted in subtle but significant mistakes being made.  I basically want to now independently write logic (in T-SQL probably) which will try to spot any abnormal changes, so at least I'm ahead of the game, and can report them sooner.

My question is, fairly obviously, does anyone have any advice on this?  Is there any theory or general good practice which I could incorporate to hopefully limit the impact of future "quick and dirty" changes to business logic?

Just so you know, we do use source control, and use Live, UAT, and Dev server environments, its just that sometimes, changes need to made immediately, rather than going through the stricter channels.


答:
It's not possible to test every permutation of a computation with many variables. But that's nothing new, it has always been true of any program above toy complexity. The point of tests is to verify the property of the computation. For instance, sorting a list with 1000 numbers takes some effort, but any individual solution can be verified very easily. Now, although there are 1000! possible (classes of) inputs for that progam and you can't test them all, it's completely sufficient to just generate 1000 inputs randomly and verify that the output is, indeed sorted. Why? Because it is nearly impossible to write a program that reliably sorts 1000 randomly generated vectors without being also correct in general (unless you deliberately rig it to manipulate certain magic inputs...)

Now, in general things are a bit more complicated. There really have been bugs where a mailer would not deliver emails to users if they have an 'f' in their username and the day of the week is Friday. But I consider it wasted effort trying to anticipate such weirdness. Your test suite should provide you with a steady confidence that the system does what you expect on the inputs you expect. If it does funky things in certain funky cases you will notice soon enough after you try the first funky case, and then you can write a test specifically against that case (which will usually also cover an entire class of similar cases).

Title: How to do TDD for something with many permutations?

Body:
When creating a system like an AI, which can take many different paths very quickly, or really any algorithm that has several different inputs, the possible result set can contain a large number of permutations.

What approach should one take to use TDD when creating a system that outputs many, many different permutations of results?


答:
From 1970 to about 2002 processors doubled in speed about every 18 months. So as a programmer all you had to do was wait and your program would go faster. The problem is that around 2002 the rules changed. Now they are not making bigger fast processors they are making smaller slower processors but putting them out in groups. The computer I am working on now has 4 cores, and Chips with up to 8 cores (and 4 threads per core) exist. Soon enough we will have chips with a lot more cores.

So if you write a program that is not at all concurrent you will find that you are using 1 core or thread, but the rest of the CPU is sitting there doing nothing. So if you have 16 cores 1 will be running your program and the other 15 are sitting there!

The problem with concurrency is that it is non deterministic. Which is to say that you don't know exactly what order different threads will do things in. Traditionally programmers have tried to solve this by using locks and the like. This has lead to a LOT of pain. Having some form of mutable state that more than one thread can access freely is often a formula for pain and heisnebugs!

Of late the trend has be to moving to functional languages which tightly control mutable state. There are two basic ways that functional languages handle concurrency. The first is by using message passing. This is best shown by Erlang. In Erlang there is in general no Shared state between processes. They communicate not by sharing memory but my passing messages. This should make sense to you as we are doing it right now. I am sending this information to you by sending you a message, not by you remembering it out of my brain! By switching to message passing most of the locking bugs simply go away. In addition messages can be passed over the network as well as within one node.

The other method is STM, which stands for Software Transcriptional Memory, This is present in clojure and Haskell (and others). In STM memory is shared but changes can only be made via a transaction. As the Database folks figured all this stuff out in the 1970's it is pretty easy to ensure that we get it right.

Actually I over simplified a bit, Clojure and Haskell can both do message passing, and Erlang can do STM.

Disclaimer I am the author of Programming Web Services with Erlang, which will be out in Early release in the next few weeks.


问:
Is this the correct way to use extends?
I am making a UML diagram. Im wondering if im using the extends feature correctly.

I have a marketer that can search contacts but only if they have created them in the first place....

Have i got the right idea. Or should there be an association between the marketer and the update/delete contact too? Should the update/delete even extend the create contact?

答:
Hmm...extends is normally used to describe a use case that adds further functionality to a base use case. Moreover it is also used to describe something that might be optional and/or occur only in certain circumstances.

Example:

In this case, "Order Food" is the base use case and "Order Wine" extends it with further functionality. Moreover "Order Wine" is somehow optional as not everyone will necessarily order it.
I've written a blog post about that, explaining the difference between the "include" and "extend" attributes of uml here:
http://blog.js-development.com/2009/03/uml-use-case-extend-and-include.html

In your situation however, you want to introduce a condition that a given usecase can only be executed when that condition is met. IMHO using extends in this situation is not 100% correct. Moreover, personally I wouldn't introduce such constraints at the level of uml use case diagrams. Maybee later when detailing the use case you can add pre-/and postconditions where you then specify that the update/delete action can only be done if an item exists.

If you insist in adding that information on the use case diagram directly because you think the viewers should have that information, you might add a simple note on that use case.

Hence, I would model it this way

Title: Is this the correct way to use extends?


问:
How to convince a teammate, who sees oneself as senior, to learn SVN conceptual basics?
To start with some background, I took up a new developer position this summer and ended up being the newest member on the team, yet with most experience under the belt.

So far I have managed to push sanity initiatives through easily enough because of low adoption costs (in terms of time and effort). However things have leveled up a bit.

One of my teammates, although experienced, does not really understand SVN. Naturally, blank areas on his mental map depicting oceans of SVN cause him to adopt rather strange usage patterns.

For example, he had declared a policy of "1 SVN commit per day per developer" because otherwise "the server would soon run out of disk space". When I explained him that SVN commits are deltas, not full copies, he responded with doubt and even today I'm not entirely sure if he understands what it means.

We also had a heated argument about whether to include Eclipse .project configuration in SVN. My teammate insisted we should, although it has caused numerous pointless conflicts. I was against keeping individual developer configuration files in SVN. Finally, it turned out that my teammate had a practice of re-checkouting the entire source tree after every commit to just make sure "code committed into repository works". That was the reason he was so adamant in keeping the project configuration in SVN - so it would be easy to re-import the project. When I explained that commit synchronizes working copy to remote byte-by-byte which makes re-checkout unnecessary, my teammate responded with doubt again and eventually waved the whole issue off as insignificant.

In my opinion, our team wastes time by resolving SVN conflicts in project configuration files which contain only developer-specific settings that need not be shared to SCM at all. All this mess because someone tailored the process around incorrect assumptions.

How can I convince a teammate, who sees oneself as senior, to get a better understanding of SVN basics?

答:
I was once in the reverse of your position about 8 years ago when SVN was reasonably newish technology. I was a senior developer and was requested/bugged to install SVN by a junior dev (actually he was more accurately IT support than a dev). I took an open mind despite my initial suspicions regarding increased workload, needless complexity, etc ... and then became a huge fan of it.

In my view, from what you have described this problem definitely comes down to team personalities - his stubbornness is proving a hinderance to the team as a whole on this issue. You may be better off just backing off at this point and letting pressure from the rest of the team build naturally to force his hand.


答: This is not really true.  There are significant numbers in both camps.  The web is actually very well suited for event driven approaches.  Several web frameworks treat every HTTP request as an event which is dispatched to handlers based on the content of the request.  These applications typically have a more component based design, where the components cut vertically through the web stack from UI and JavaScript layers up through the network into particular objects on the server where state is maintained.  While this has several advantages, it is not without its disadvantages.</p>

Title: Is it true that websites don't need to use an event driven framework given the stateless nature of the web?

Body:
I feel like it's critical to use an event driven architecture with a lot of application types that aren't web sites. However, when coding web sites(which are stateless at the most basic level) it seems like it isn't really necessary to use an event driven architecture.

Is this true? Do most web frameworks not use events to communicate between objects?


答:
Improvements are great... if they are backwards compatible.

C# does this nicely. They add things lamdba expressions, better support for multithreading, linq,... But your five year old C# 2.0 program will still work nicely without needing any changes and can easily be upgraded to C# 4.0 without needing any changes.

Learning new stuff is great if it's allowing you to do your tasks in an easier, faster way. If spending an hour learning means saving your hours in development time, it's well worth it.


答:
Take the edge cases plus some random input.

To take the sorting example:

Sort a few random lists

Take a list that is already sorted

Take a list that is in reverse order

Take a list that's almost sorted

If it works fast for these, you can be quite sure that it will work for all input.


答:
TDD is not about testing, it's about design.

Far from falling apart with complexity, it excels in these circumstances. It will drive you to consider the larger problem in smaller pieces, which will lead to a better design.

Do not set out to try to test every permutation of your algorithm. Just build test after test, write the simplest code to make the test work, until you have your bases covered. You should see what I mean about breaking the problem down because you will be encouraged to fake out parts of the problem while testing other parts, to save yourself having to write 10 billion tests for 10 billion permutations.

Edit: I wanted to add an example, but didn't have time earlier.

Let's consider an in-place-sort algorithm. We could go ahead and write tests which cover the top end of the array, the bottom end of the array and all sorts of weird combinations in the middle. For each one, we would have to build a complete array of some kind of object. This would take time.

Or we could tackle the problem in four parts:

Traverse the array.

Compare selected items.

Switch items.

Coordinate the above three.

The first is the only complicated part of the problem but by abstracting it out from the rest, you have made it much, much simpler.

The second is almost certainly handled by the object itself, at least optionally, in many static-typed frameworks there will be an interface to show whether that functionality is implemented. So you don't need to test this.

The third is incredibly easy to test.

The fourth just handles two pointers, asks the traversal class to move the pointers around, calls for a compare and based on the result of that compare, calls for the items to be swapped. If you've faked out the first three problems, you can test this very easily.

How have we led to a better design here? Let's say that you've kept it simple and implemented a bubble sort. It works but, when you go to production and it has to handle a million objects, it is far too slow. All you have to do is write new traversal functionality and swap it in. You don't have to deal with the complexity of handling the other three problems.

This, you will find, is the difference between unit testing and TDD. The unit tester will say that this has made your tests fragile, that if you had tested simple inputs and output then you wouldn't now have to write more tests for your new functionality. The TDDer will say that I have separated concerns suitably so that each class I have does one thing and one thing well.


答:
I had a guy tell me he likes his C++ and it will stay that way. He doesnt care or have interest in D, he doesnt want to know nor use C#. He learned java because he HAD to for the many projects he needed to do and he apparently does a good job in the languages he knows

Another loves C# and doesnt know every keyword or know the .NET 4 libraries (async and all) and hasnt used the abstract keywords or used attributes.

I'm simply saying most people DONT CARE

Now of the effects of the upgrade is breaking (for libs or compiled code) people WILL care.


答:
Taking a more practical approach to pdr's answer. TDD is all about software design rather than testing. You use unit tests to verify your work as you go along.

So on a unit test level you need to design the units so they can be tested in a completely deterministic fashion. You can do this by taking anything that makes the unit nondeterministic (such as a random number generator) and abstract that away. Say we have a naïve example of a method deciding if a move is good or not:

```<code>class Decider {

  public boolean decide(float input, float risk) {

      float inputRand = Math.random();
      if (inputRand > input) {
         float riskRand = Math.random();
      }
      return false;

  }

}

// The usage:
Decider d = new Decider();
d.decide(0.1337f, 0.1337f);
</code>```

This method is very hard to test and the only thing you really can verify in unit tests is its bounds... but that requires a lot of tries to get to the bounds. So instead, let's abstract away the randomizing part by creating an interface and a concrete class that wraps the functionality:

```<code>public interface IRandom {

   public float random();

}

public class ConcreteRandom implements IRandom {

   public float random() {
      return Math.random();
   }

}
</code>```

The Decider class now needs to use the concrete class through its abstraction, i.e. the Interface. This way of doing things is called dependency injection (the example below is an example of constructor injection, but you can do this with a setter as well):

```<code>class Decider {

  IRandom irandom;

  public Decider(IRandom irandom) { // constructor injection
      this.irandom = irandom;
  }

  public boolean decide(float input, float risk) {

      float inputRand = irandom.random();
      if (inputRand > input) {
         float riskRand = irandom.random();
      }
      return false;

  }

}

// The usage:
Decider d = new Decider(new ConcreteRandom);
d.decide(0.1337f, 0.1337f);
</code>```

You might ask yourself why this "code bloat" is necessary. Well, for starters, you can now mock the behavior of the random part of the algorithm because the Decider now has a dependency that follows the IRandoms "contract". You can use a mocking framework for this, but this example is simple enough to code yourself:

```<code>class MockedRandom() implements IRandom {

    public List<Float> floats = new ArrayList<Float>();
    int pos;

   public void addFloat(float f) {
     floats.add(f);
   }

   public float random() {
      float out = floats.get(pos);
      if (pos != floats.size()) {
         pos++;
      }
      return out;
   }

}
</code>```

The best part is that this can completely replace the "actual" concrete implementation. The code becomes easy to test like this:

```<code>@Before void setUp() {
  MockedRandom mRandom = new MockedRandom();

  Decider decider = new Decider(mRandom);
}

@Test
public void testDecisionWithLowInput_ShouldGiveFalse() {

  mRandom.addFloat(0f);

  assertFalse(decider.decide(0.1337f, 0.1337f));
}

@Test
public void testDecisionWithHighInputRandButLowRiskRand_ShouldGiveFalse() {

  mRandom.addFloat(1f);
  mRandom.addFloat(0f);

  assertFalse(decider.decide(0.1337f, 0.1337f));
}

@Test
public void testDecisionWithHighInputRandAndHighRiskRand_ShouldGiveTrue() {

  mRandom.addFloat(1f);
  mRandom.addFloat(1f);

  assertTrue(decider.decide(0.1337f, 0.1337f));
}
</code>```

Hope this gives you ideas on how to design your application so that the permutations can be forced so you can test all the edge cases and whatnot.

Body:
Taking a more practical approach to pdr's answer. TDD is all about software design rather than testing. You use unit tests to verify your work as you go along.

So on a unit test level you need to design the units so they can be tested in a completely deterministic fashion. You can do this by taking anything that makes the unit nondeterministic (such as a random number generator) and abstract that away. Say we have a naïve example of a method deciding if a move is good or not:

class Decider {

  public boolean decide(float input, float risk) {

      float inputRand = Math.random();
      if (inputRand > input) {
         float riskRand = Math.random();
      }
      return false;

  }

}

// The usage:
Decider d = new Decider();
d.decide(0.1337f, 0.1337f);

This method is very hard to test and the only thing you really can verify in unit tests is its bounds... but that requires a lot of tries to get to the bounds. So instead, let's abstract away the randomizing part by creating an interface and a concrete class that wraps the functionality:

public interface IRandom {

   public float random();

}

public class ConcreteRandom implements IRandom {

   public float random() {
      return Math.random();
   }

}

The Decider class now needs to use the concrete class through its abstraction, i.e. the Interface. This way of doing things is called dependency injection (the example below is an example of constructor injection, but you can do this with a setter as well):

class Decider {

  IRandom irandom;

  public Decider(IRandom irandom) { // constructor injection
      this.irandom = irandom;
  }

  public boolean decide(float input, float risk) {

      float inputRand = irandom.random();
      if (inputRand > input) {
         float riskRand = irandom.random();
      }
      return false;

  }

}

// The usage:
Decider d = new Decider(new ConcreteRandom);
d.decide(0.1337f, 0.1337f);

You might ask yourself why this "code bloat" is necessary. Well, for starters, you can now mock the behavior of the random part of the algorithm because the Decider now has a dependency that follows the IRandoms "contract". You can use a mocking framework for this, but this example is simple enough to code yourself:

class MockedRandom() implements IRandom {

    public List<Float> floats = new ArrayList<Float>();
    int pos;

   public void addFloat(float f) {
     floats.add(f);
   }

   public float random() {
      float out = floats.get(pos);
      if (pos != floats.size()) {
         pos++;
      }
      return out;
   }

}

The best part is that this can completely replace the "actual" concrete implementation. The code becomes easy to test like this:

@Before void setUp() {
  MockedRandom mRandom = new MockedRandom();

  Decider decider = new Decider(mRandom);
}

@Test
public void testDecisionWithLowInput_ShouldGiveFalse() {

  mRandom.addFloat(0f);

  assertFalse(decider.decide(0.1337f, 0.1337f));
}

@Test
public void testDecisionWithHighInputRandButLowRiskRand_ShouldGiveFalse() {

  mRandom.addFloat(1f);
  mRandom.addFloat(0f);

  assertFalse(decider.decide(0.1337f, 0.1337f));
}

@Test
public void testDecisionWithHighInputRandAndHighRiskRand_ShouldGiveTrue() {

  mRandom.addFloat(1f);
  mRandom.addFloat(1f);

  assertTrue(decider.decide(0.1337f, 0.1337f));
}

Hope this gives you ideas on how to design your application so that the permutations can be forced so you can test all the edge cases and whatnot.


问:
Should I reuse variables?
Should I reuse variables?

I know that many best practices say you should not do it, however, later, when different developer is debugging the code and have 3 variables that look alike and the only difference is that they are created in different places in the code, he might be confused. Unit-testing is a great example of this.

However, I do know that best practices are most of the time against it.
For example they say not to "override" method parameters.

Best practices are even are against nulling the previous variables (in Java there is Sonar that gives a warning when you assign null to variable, that you don't need to do it to call the garbage collector since Java 6. You can't always control which warnings are turned off; most of the time the default is on.)

答:
Your problem appears only when your methods are long and are doing multiple tasks in a sequence. This makes the code harder to understand (and thus maintain) per se. Reusing variables adds on top of this an extra element of risk, making the code even harder to follow and more error prone.

IMO best practice is to use short enough methods which do one thing only, eliminating the whole problem.

Title: Should I reuse variables?


答:
You should use different variables. If you are worried that your colleague will be confused, give them names that clearly cover their roles.

Re-using variables is a likely source of confusion in the future; better to clear it up now.

In some cases, the same variable name can be re-used; for example i in a simple counting loop. In these cases, you should of course make sure that the variables are in their own scope.

EDIT: Re-using variables is sometimes a sign that the Single Responsibility Principle is violated. Check to see if the re-used variable is used in the same role. If it is, it may not be re-use at all (although it may still be preferable to have two different variables, to restrict the scope of said variables). If it is used in different roles, you have an SRP violation on your hands.

Title: Should I reuse variables?

Body:
Should I reuse variables?

I know that many best practices say you should not do it, however, later, when different developer is debugging the code and have 3 variables that look alike and the only difference is that they are created in different places in the code, he might be confused. Unit-testing is a great example of this.

However, I do know that best practices are most of the time against it.
For example they say not to "override" method parameters.

Best practices are even are against nulling the previous variables (in Java there is Sonar that gives a warning when you assign null to variable, that you don't need to do it to call the garbage collector since Java 6. You can't always control which warnings are turned off; most of the time the default is on.)


答:
I'll give you a short answer. Typically TDD is looked at the wrong way just like unit testing is. I never understood unit testing until recently after watching a good tech talk video. Essentially TDD is just stating you want the following things to WORK. They MUST be implemented. Then you design the rest of the software the way you normally would.

Its kind of like writing use cases for a library before designing the library. Except you can change the use case in a library and you might not for TDD (I use TDD for API design). You are also encouraged to add more test and think of wild inputs/uses the test may get. I find it useful when writing libraries or APIs where if you change something you must know you broke something. In most day to day software i dont bother since why do i need a test case for a user pressing a button or if i want to accept a CSV list or a list with one entry per line... That doesnt really matter i am allow to change it thus i shouldnt/cant use TDD.

Title: Why does TDD work?

Body:
Test-driven development (TDD) is big these days. I often see it recommended as a solution for a wide range of problems here in Programmers SE and other venues. I wonder why it works.

From an engineering point of view, it puzzles me for two reasons:

The "write test + refactor till pass" approach looks incredibly anti-engineering. If civil engineers used that approach for bridge construction, or car designers for their cars, for example, they would be reshaping their bridges or cars at very high cost, and the result would be a patched-up mess with no well thought-out architecture. The "refactor till pass" guideline is often taken as a mandate to forget architectural design and do whatever is necessary to comply with the test; in other words, the test, rather than the user, sets the requirement. In this situation, how can we guarantee good "ilities" in the outcomes, i.e. a final result that is not only correct but also extensible, robust, easy to use, reliable, safe, secure, etc.? This is what architecture usually does.

Testing cannot guarantee that a system works; it can only show that it doesn't. In other words, testing may show you that a system contains defects if it fails a test, but a system that passes all tests is not safer than a system that fails them. Test coverage, test quality and other factors are crucial here. The false safe feelings that an "all green" outcomes produces to many people has been reported in civil and aerospace industries as extremely dangerous, because it may be interepreted as "the system is fine", when it really means "the system is as good as our testing strategy". Often, the testing strategy is not checked. Or, who tests the tests?

In summary, I am more concerned about the "driven" bit in TDD than about the "test" bit. Testing is perfectly OK; what I don't get is driving the design by doing it.

I would like to see answers containing reasons why TDD in software engineering is a good practice, and why the issues that I have explained above are not relevant (or not relevant enough) in the case of software. Thank you.


答:
Variable reuse in a method is a strong sign that you should refactor/split it.

So my answer would be that you shouldn't reuse them, because if you do then it would be that much harder to refactor it later.

Title: Should I reuse variables?


问:
Packages organisation with MVC design pattern
I have been programming quite a lot now and still can't decide which of these packages hierachies was the best:

```<code>package1
  Class1Controller
  Class1Model
  Class1View
package2
  Class2Controller
  Class2Model
  Class2View
</code>```

or

```<code>controller
  Class1Controller
  Class2Contoller
model
  Class1Model
  Class2Model
view
  Class1View
  Class2View
</code>```

In other words, is it better to apply the MVC design pattern to classes or to packages? Is there any reason to choose one over the other?

My question is language-agnostic, but I'm mostly a Java programmer, if it does any difference.

答:
Short Answer:  It depends :-)

Normally I would recommend your first suggestion because you put stuff in a package which belongs together.
In your second example Class1Controller and Class2Controller may have nothing in common except that they are controllers.

But as I said in the beginning, there may be a reason to use the second pattern instead the of the first.


答: Because concurrency can blow up in your face when you expect it the least...</p>


答: The biggest reason I don't reuse variables (especially in unit tests) is because it introduces an unecessary code path, one that is hard to test and debug.  A good unit test should be independent from other tests and when you reuse class (instance) level variable in a unit test fixture you have to ensure to assert on their state before each test. A good unit test also isolates defects so in theory each test case (method) should only assert 1 behavior for the system under test.  If your test methods are written like this there is rarely a need or benefit to reusing a method level variable.  Last, in languages that support closures and asynchronous processing, it is really hard to reason about what the hell is going on if you are reusing variables throughout a method.  </p>

Title: Should I reuse variables?


问:
Starting a new startup/web application, how to choose a hosting provider?
When creating a new startup related to a web application, how to choose a hosting provider ?

Assuming the code of the web application is oriented DDDD (Distributed Domain Driven Development) to handle large deployment scenario, the idea is to avoid too much cost for hosting.

Basically, the launch of the web app, with its very users will be able to fit on a "single" box (DB + APP), maybe two for redundancy. Eventually the apps will grows progressively to more and more users (I hope:)). How can I choose wisely the hosting ?

Today, I see three options :

hosting ourself : not actually an option today as it requires a lot of administrative skills and related task

hosting on virtual/dedicated servers : maybe a good options as virtual dedicated hosting is quite cheap, but I fear this will quickly limit us in term of scalability

hosting on cloud (amazon or azure) : probably the best option in the long term, but with a higher cost to start (having to adapt a bit the application, cost of instances)

Does anybody have feedback/advise about such requirements ?

PS: FYI, the web apps will probably be written with ASP.NET MVC as web framework, and Ncqrs+NServiceBus to target the DDDD pattern in a CQRS style

Edit: as a backend, MongoDB is today our probable choice, as NoSQL is marrying well with event-sourcing + CQRS (no need for joins, etc.). However, finding VPS with asp.net AND mongodb can be challenging. I may have to use some traditional RDBMS found on all providers (MS SQL SErver or MySQL)

答:
This is just my opinion but....
How many users are you expecting? Do you expect to get 100 users hitting the site at the same moment? How about 1000users? or 10k?

nginx can handle 1k-10kusers depending on your machine with very little cpu/ram until it gets up to 10k per user at the same moment. Then cpu will be a bottleneck. Also how complex is your application? Do most pages need lots of processing power? Are you going to convert videos or sound?

I seen a person go viral and got millions of hits on his site. It was on simple VPS. He solved his problem by throwing ONE file (a rather large swf) onto amazon aws and his site coped with it.

If you have 10k users regularly then your site or app will need to be rewritten or changed which is a different ballgame. But thats IF you get that many on a regular basis... I'm pretty sure you'll be fine with a plain VPS if you have someone to set it up (the server, backups and anything you need)


答:
There is one situation in which you may want to reuse a variable regardless of the great advice given by other answers: when your compiler needs a helping hand.

In some cases your compiler may not be clever enough to realize that a certain register-allocated variable is no longer being used by the next part of the code.  Therefore it will not re-use that theoretically free register for the next variables, and the generated code may be sub-optimal.

Note that I don't know of any current mainstream compilers that fail to catch this situation correctly, so never, ever, ever do this unless you know for a fact that your compiler is generating sub-optimal code.  If you are compiling for special embedded systems with custom compilers, you might run into this problem still.

Title: Should I reuse variables?


问:
What is the purpose of arrays in C, when pointers could have done the job?
Arrays and pointers are not the same thing in C, although they are related and can be used similarly. So far we all agree.

However, I don't see why arrays were included in C, when pointers could have done their job perfectly.

I am not saying to remove the array notation (e.g, a[5] or int a[4] = {0,1,2,3};), which is quite useful and convenient. But you could have that same notation working on top of pointers (as is the case), as a cosmetic measure. So the array notation is not a reason to have arrays, just the notation!

The only difference I see is that arrays are constant pointers, and the size of memory they point to can't be changed. But this can be achieved with pointers as well, exactly by making them constant (the memory wouldn't be of fixed size, but I am not sure if this is an issue).

So why not have only pointers and let the programmer decide how the pointer should behave (i.e., constant, not constant, fixed size, variable size, etc)?

答:
I am surprised that nobody has commented anything about multidimensional arrays yet.

If you have a matrix made of "nested pointers" (say int **p) what you have in each "row" (outer dimension) is a pointer that points to the first element in that row, so accessing a value requires two memory access. Plus, the memory it requires is sizeof(*int)*n + n*m*sizeof(int).

In the bidimensional array scenario int p[n][m], accessing an element requires just one memory access, because the address of the row is calculated rather than looked up; and the memory required is just n*m*sizeof(int).

Another place where an array cannot be replaced by a pointer is inside structures.

```<code>struct s {
    int[2];
    float;
}
</code>```

is definitively not the same as

```<code>struct s {
   *int;
   float;
}
</code>```

the size of the array is important there, and pointers do not have that information.

So yes, unidimensional arrays and single pointers are mostly interchangeable, but their similarities end there.

Body:
I am surprised that nobody has commented anything about multidimensional arrays yet.

If you have a matrix made of "nested pointers" (say int **p) what you have in each "row" (outer dimension) is a pointer that points to the first element in that row, so accessing a value requires two memory access. Plus, the memory it requires is sizeof(*int)*n + n*m*sizeof(int).

In the bidimensional array scenario int p[n][m], accessing an element requires just one memory access, because the address of the row is calculated rather than looked up; and the memory required is just n*m*sizeof(int).

Another place where an array cannot be replaced by a pointer is inside structures.

struct s {
    int[2];
    float;
}

is definitively not the same as

struct s {
   *int;
   float;
}

the size of the array is important there, and pointers do not have that information.

So yes, unidimensional arrays and single pointers are mostly interchangeable, but their similarities end there.


答:
Here is how you can prevent most dramatic situations:

Don't choose one, but at least two.

Use the DNS manager of your domain registry (that should be a different company than your hosters).

Backup from one to another.

If you can afford it, load-balance, fail-over, early

Test support early. Don't hesitate to simulate a problem. Support is probably the most important things after reliability.

Title: Starting a new startup/web application, how to choose a hosting provider?

Body:
When creating a new startup related to a web application, how to choose a hosting provider ?

Assuming the code of the web application is oriented DDDD (Distributed Domain Driven Development) to handle large deployment scenario, the idea is to avoid too much cost for hosting.

Basically, the launch of the web app, with its very users will be able to fit on a "single" box (DB + APP), maybe two for redundancy. Eventually the apps will grows progressively to more and more users (I hope:)). How can I choose wisely the hosting ?

Today, I see three options :

hosting ourself : not actually an option today as it requires a lot of administrative skills and related task

hosting on virtual/dedicated servers : maybe a good options as virtual dedicated hosting is quite cheap, but I fear this will quickly limit us in term of scalability

hosting on cloud (amazon or azure) : probably the best option in the long term, but with a higher cost to start (having to adapt a bit the application, cost of instances)

Does anybody have feedback/advise about such requirements ?

PS: FYI, the web apps will probably be written with ASP.NET MVC as web framework, and Ncqrs+NServiceBus to target the DDDD pattern in a CQRS style

Edit: as a backend, MongoDB is today our probable choice, as NoSQL is marrying well with event-sourcing + CQRS (no need for joins, etc.). However, finding VPS with asp.net AND mongodb can be challenging. I may have to use some traditional RDBMS found on all providers (MS SQL SErver or MySQL)


答:
Accoring to this report , the number 1 reason why startups' fail is premature scaling.

Its not a wise solution to spend a lot on scalibility until you have not reached a point where you need it. Scale your application on a 'as per needed' bases. Start small (VPS), keep costs low, monitor your growth and expand as and when you need. Its not difficult to move from a VPS to a dedicated server or into a cloud. Hosting companies help you with this. Also look at my answer here for some added tips on startups.

P.S. Read more about the report online


问:
Explaining technical things to non-technical people
I often have to explain technical things and technical decisions to my extremely non technical manager and I'm pretty awful at it. What are good ways to essential dumb things down for the rest of the world who don't have a passion for programming?

Example questions I've been asked:

Why are you using Django instead of Java (Didn't accept that it was cheaper either)

Asking me to rephrase things in non technical words, my sentence was "Certain HTML tags are not allowed". How can I possibly dumb that down?

Other stuff that makes perfect sense to me, but is just so basic I don't know how to explain it

Why this, why that, why everything!

Also, how do I tell my manager to look the basic stuff up on Google, like "What is Pylons?"

答:
Things I Use

to great and not so great effect.

Analogies: When explaining a situation or a process it really works well if you can put it into terms that they will understand.

Generic terms: Instead of saying HTML tags you could say code. If they follow up requesting an explanation it might be time for a brief summary of HTML and how it works. "Web pages are built out of blocks called "tags." If your browser doesn't support a specific tag the it won't be displayed correctly."

Summaries and Overviews: Sometimes it works well to give a brief synopses prior to hitting them upside the head with technical jargon.

Remove Jargon: Turn "The database isn't properly load balancing when hit by multiple requests from an IP subnet." into "The database is having trouble handling requests from certain people." If you might have to explain it, replace it with something else. If you have to explain database you're in trouble. "Place to store stuff" is my fallback.

Visual Aids: Whiteboards rock. Use them to your advantage.

Make them technical: Keeping managers, bosses, and coworkers in the loop helps. If the account manager is confused at meetings because everyone but them understands what's being said, it might make them want to read those emails they were CC'ed on. Take time when writing memos or emails to explain yourself thoroughly or point to references for explanation. Having someone figure out what HTML is on their own will probably be better then trying to cram it into them during an important meeting.


答:
I'll answer for C# (but this analysis may be applied to Scala as well):

This feature changing causes some problems when you are approaching a "style" of a language:

In 2011, C# can do a lot of different things, and this is good. Unfortunately it has two different paradigms (if not more):

OOP

Functional (think of lambda functions and LINQ)

Different type checking styles

Dynamic Typing

Static Typing

It's not always clear when you want to use one or another.


问:
What are the valid reasons to use ContentPresenter outside of template?
I stumbled upon an article by Den Delimarsky on What is a ContentPresenter? which says:

In WPF there is an element called ContentPresenter, that is often used inside control templates, as well as inside the root application markup.

I don't understand the "inside the root application markup" part, because I thought that ContentPresenter can only used inside of a ControlTemplate.

The role of the ContentPresenter is quite clear when used in a ControlTemplate, but what are the valid reasons to use ContentPresenter outside of a template's markup?

答: There are no reasons. You should use ContentControl rather then ContentPresenter outside of a template.


问:
Stuff every programmer needs while working
I've been tasked with creating a fun and relaxing environment, one thing I know that I want is ergonomic mice and keyboards, others have suggested exercise balls and bands.

What is it that every programmer needs while working? What might not be necessary but would be nice to have anyway?

Note: this question was asked previously, but has been recommended to be posted here. See this link for the previous responses: https://stackoverflow.com/questions/3911911/stuff-every-programmer-needs-while-working-closed

答: A sound-proof office.

ContentLicense: CC BY-SA 2.5

Body: A sound-proof office.


问:
Do object-oriented programming languages exist that are not class-based?
Are there any object-oriented programming languages that are not based on the class paradigm?</p>

答:
Io is another prototype-based object-oriented language. It actually draws inspiration from several of the languages already mentioned in other answers.

Io is a dynamic prototype-based programming language. The ideas in Io
  are mostly inspired by Smalltalk (all values are objects), Self
  (prototype-based), NewtonScript (differential inheritance), Act1
  (actors and futures for concurrency), Lisp (code is a runtime
  inspectable / modifiable tree) and Lua (small, embeddable).


问:
How can we plan projects realistically while accounting for support issues?
We're having a problem at work: we're trying to schedule work so that we can assess time scales and get deadline dates.

The problem is that it's difficult to plan for a project without knowing everything that's going to happen.

For instance, right now we've planned all our projects through the start of December, however in that time we will have various in house and external meetings, teleconferences and extra work. It's all well and good to say that a project will take three weeks, but if there is a week's worth of interruption in that time then the date of completion will be pushed back a week.

The problem is 3 fold:

When we schedule projects the time scales are taken literally. If we estimate three weeks, the deadline is set for three week's time, the client is told, and there is no room for extension.

Interim work and such means that we lose productive time working on the project.

Sometimes clients don't have the time that we need to take to do the work, so they'll sometimes come to us and say they need a project done by the end of the month even when we think that the work will take two months - not to mention we already have work to be doing.

We have a Gantt chart which we are trying to fill in with all the projects we have and we fill in timesheets, but they're not compared to the Gantt chart at all. This makes it difficult to say "Well, we scheduled 3 weeks for this project, but we've lost a week here so the deadline has to move back a week."

It's also not professional to keep missing deadlines we've communicated to the client.

How do other people deal with this type of situation? How do you manage the planning of projects? How much "extra" time do you schedule into a project to account for non-project work that occurs during a project? How do you deal with support issues and bugs and stuff? Things you can't account for during planning?

UPDATE

Lots of good answers thank you.

答:
I would suggest dig into the Scrum development process details. It covers such sidetracking activities by the focus factor metric. Basically you've to work 2-3  sprints/iterations and then measure focus factor of your team (and for the each member it would be helpful as well). After this you would be able provide more accurate estimates which covers daily activity.

Take a look at this article - "The focus factor"

If any of you are familiar with Agile development, you’ve probably
  heard of the focus factor (or productivity factor).  It’s used for
  planning to help determine how many “real hours” you have to work on
  something.  It’s the difference between “real hours” and “ideal
  hours.”


答:
The problem is though that its difficult to plan for a project without knowing everything that's going to happen.

That's the point of risk management. You can't know everything, so you plan based on what you know and identify what things could have the most impact on your plan and how likely those are to happen. Assess the potential schedule impact as well by saying that if X happens, it will cause the schedule to slip by an estimated (key word - estimated) Y days or weeks.

Its all well and good saying that a project will take 3 weeks,

Never give such a specific estimate. Give a range or quantify the probability of hitting that estimate. For example, say "this project will take 2-5 weeks" or "there's an 85% chance this project will be done in 3 weeks and a 95% chance it will be done in 4 weeks".

Its also not professional to the client to keep saying we've missed a deadline.

True. However, you're mixing the concepts of "estimate", "schedule", and "deadline". Your estimate is an approximation of how long it will take to finish a given task or project and the probability of meeting that. The deadline is a customer-imposed date on which the project must be done in order to add value. The schedule is how you use your available resources to meet your deadline.

There are times when it's simply not possible to finish the assigned work within a deadline and all the estimation and scheduling in the world isn't going to make a difference.

So my question... how do other people do this? How do you manage the planning of projects? How much "extra" time do you schedule into a project to account for anything that happens in the mean time?

I recommend reading two books, both by Steve McConnell: Software Estimation: Demystifying the Black Art and Rapid Development: Taming Wild Software Schedules. Software Estimation is all about coming up with your estimates, presenting them to the clients, and some aspects of negotiation and dealing with unrealistic expectations. Rapid Development is general project management, dealing with development lifecycles, scheduling, resource allocation, and how to best schedule and budget projects to meet your estimates and deadlines.

Title: How can we plan projects realistically while accounting for support issues?

Body:
We're having a problem at work: we're trying to schedule work so that we can assess time scales and get deadline dates.

The problem is that it's difficult to plan for a project without knowing everything that's going to happen.

For instance, right now we've planned all our projects through the start of December, however in that time we will have various in house and external meetings, teleconferences and extra work. It's all well and good to say that a project will take three weeks, but if there is a week's worth of interruption in that time then the date of completion will be pushed back a week.

The problem is 3 fold:

When we schedule projects the time scales are taken literally. If we estimate three weeks, the deadline is set for three week's time, the client is told, and there is no room for extension.

Interim work and such means that we lose productive time working on the project.

Sometimes clients don't have the time that we need to take to do the work, so they'll sometimes come to us and say they need a project done by the end of the month even when we think that the work will take two months - not to mention we already have work to be doing.

We have a Gantt chart which we are trying to fill in with all the projects we have and we fill in timesheets, but they're not compared to the Gantt chart at all. This makes it difficult to say "Well, we scheduled 3 weeks for this project, but we've lost a week here so the deadline has to move back a week."

It's also not professional to keep missing deadlines we've communicated to the client.

How do other people deal with this type of situation? How do you manage the planning of projects? How much "extra" time do you schedule into a project to account for non-project work that occurs during a project? How do you deal with support issues and bugs and stuff? Things you can't account for during planning?

UPDATE

Lots of good answers thank you.


答:
It depends.

Some variables might be created exactly for the purpose of holding a certain kind of data, which can change during the execution of a function. Return codes come to mind here, for example:

```<code>void my_function() {
    HRESULT errorcode;
    errorcode = ::SomeWindowsApiFunction();
    if (FAILED(errorcode)) { /* handle error */ }
    errorcode = ::AnotherWindowsApiFunction();
    if (FAILED(errorcode)) { /* handle error */ }
}
</code>```

The variable name makes it very clear what this variable is intended to store. I think other usecases such as this are possible, where a variable is conceptually a container which is logically used by different instances of very similar things during the course of a function.

In general, however, this should be done only in circumstances where it is absolutely clear to possible readers of the code. In no case, except maybe extreme optimization with no regard to code legibility, should a variable be reused just because the type fits.

All of this basically follows from good practices in variable naming. Names should speak for themselves. If it is difficult to put the exact purpose for all re-uses in a short name, it is best to just use distinct variables.

Title: Should I reuse variables?

Body:
It depends.

Some variables might be created exactly for the purpose of holding a certain kind of data, which can change during the execution of a function. Return codes come to mind here, for example:

void my_function() {
    HRESULT errorcode;
    errorcode = ::SomeWindowsApiFunction();
    if (FAILED(errorcode)) { /* handle error */ }
    errorcode = ::AnotherWindowsApiFunction();
    if (FAILED(errorcode)) { /* handle error */ }
}

The variable name makes it very clear what this variable is intended to store. I think other usecases such as this are possible, where a variable is conceptually a container which is logically used by different instances of very similar things during the course of a function.

In general, however, this should be done only in circumstances where it is absolutely clear to possible readers of the code. In no case, except maybe extreme optimization with no regard to code legibility, should a variable be reused just because the type fits.

All of this basically follows from good practices in variable naming. Names should speak for themselves. If it is difficult to put the exact purpose for all re-uses in a short name, it is best to just use distinct variables.


问:
Why should I know concurrent programming?
Concurrent programming is quite difficult to me: even looking at a basic slide seems challenging to me. It seems so abstract. </p>

<p>What are the benefits to knowing Concurrent programming concepts well? Will it help me in regular, sequential programming? I know there is a satisfaction to understanding how our programs work, but what else? </p>

答:
The first rule of concurrent programming is "It's difficult". The second rule of concurrent programming is "It. Is. Difficult"..!!

Seriously though, there are two common approaches to concurrent programming, multi-threading and multi-processing. Multi-processing is the easiest to comprehend since it just means having multiple instances of a process running to accomplish a task. The is pretty easy to do on Unix based systems via calls to fork/join, but not so easy on Windows systems.

Multi-threading is probably the approach most people think of when talking about concurrency. It's not difficult to start multiple threads within an application, but the devil is in the details. You need to co-ordinate data sharing between thread (usually using locks) which can lead to deadlock or data in an invalid state. You also need to understand how to communicate between thread using concepts like semaphores, conditional variables etc etc.

The advantage to all this is that once you understand it you're able to more effectively utilize the underlying hardware. These days it's pretty much the norm for a processor to have multiple cores. By utilizing concurrent programming you can make these cores work for you, and your application will get a speed improvement.

The disadvantage is that you have to start thinking about how you'll split your application up into small parts that can be run on different threads. This is a lot harder than it sounds. Also, highly concurrent solutions can be awkward to unit test as the order of execution is less deterministic.

These days most languages ship with an abstraction over most concurrent primitives to make life a bit easier. For example, .NET 4 ships with the Task Parallel Library which make life a bit easier. In Java land they've got the Concurrency package.


答:
It depends.
In a dynamic language, where type resides on values rather than variables then if I had a well-named argument to a function that, for example, was a string. I a change in algorithm meant that it was always used after being interpreted as an integer, then, as a first draft I might do the equivalent of

scrote = int(scrote)

But I would eventually look to change the type sent in to the function and note the change in parameter type.

Title: Should I reuse variables?


答:
In general you should divide your application into functional packages rather than structural ones. What use is, for example, a business exception ("Order not found" e.g.) in a general exceptions package?

You should have a high cohesion within packages. I'd rather split a single package into several layers than dividing them by their structural/architectural purpose. For example, I believe that the model deserves an own layer with all its necessities. Then, for the specific model, I'd have an application layer with controllers and possibly another exchangeable layer with views, all tied together with well defined interfaces.

Your second option clearly leads to an architecture where many parts of your application will have unecessary and unwanted dependecies. This will limit your flexibility and extensibility options. Just think about it: Whenever you change a single interface in the model package, all packages that use this package need to have an updated dependency as well.

In short, I'd structure a basic application like this:

```<code>package1
   model        (subpackage/assembly, contains the business logic)
   application  (subpackage/assembly, contains controllers etc)
   presentation (subpackage/assembly, contains views etc.)
   interfaces   (optional, encapsulates well defined interfaces
                  so the layers can communicate and for Dependency Injection)
</code>```

The layers can be namespaces of physically distinct. Physical distinction (compiling to different Dlls) really helps to keep your architecture clean, the interfaces part can be a gatekeeper.

Also be aware that the term model can mean different things. Model can refer to business logic (in OOP mostly an object model of your business domain) or to a single "presentation model (at this point I don't refer to Fowler's pattern 100%, but rather to the myriads of MVC variants in general)". While the first one truly belong to the model package, the latter one belongs to the application layer. I like MVC best when the controller just calls the business logic and the persistence layer. Most of the time it doesn't need a separate model.

Title: Packages organisation with MVC design pattern

Body:
I have been programming quite a lot now and still can't decide which of these packages hierachies was the best:

```<code>package1
  Class1Controller
  Class1Model
  Class1View
package2
  Class2Controller
  Class2Model
  Class2View
</code>```

or

```<code>controller
  Class1Controller
  Class2Contoller
model
  Class1Model
  Class2Model
view
  Class1View
  Class2View
</code>```

In other words, is it better to apply the MVC design pattern to classes or to packages? Is there any reason to choose one over the other?

My question is language-agnostic, but I'm mostly a Java programmer, if it does any difference.

Body:
In general you should divide your application into functional packages rather than structural ones. What use is, for example, a business exception ("Order not found" e.g.) in a general exceptions package?

You should have a high cohesion within packages. I'd rather split a single package into several layers than dividing them by their structural/architectural purpose. For example, I believe that the model deserves an own layer with all its necessities. Then, for the specific model, I'd have an application layer with controllers and possibly another exchangeable layer with views, all tied together with well defined interfaces.

Your second option clearly leads to an architecture where many parts of your application will have unecessary and unwanted dependecies. This will limit your flexibility and extensibility options. Just think about it: Whenever you change a single interface in the model package, all packages that use this package need to have an updated dependency as well.

In short, I'd structure a basic application like this:

package1
   model        (subpackage/assembly, contains the business logic)
   application  (subpackage/assembly, contains controllers etc)
   presentation (subpackage/assembly, contains views etc.)
   interfaces   (optional, encapsulates well defined interfaces
                  so the layers can communicate and for Dependency Injection)

The layers can be namespaces of physically distinct. Physical distinction (compiling to different Dlls) really helps to keep your architecture clean, the interfaces part can be a gatekeeper.

Also be aware that the term model can mean different things. Model can refer to business logic (in OOP mostly an object model of your business domain) or to a single "presentation model (at this point I don't refer to Fowler's pattern 100%, but rather to the myriads of MVC variants in general)". While the first one truly belong to the model package, the latter one belongs to the application layer. I like MVC best when the controller just calls the business logic and the persistence layer. Most of the time it doesn't need a separate model.


问:
What are the typical naming conventions for OO C public and private functions?
Short Question

Is there a typical way to name 'public' and 'private' members of an OO C project?

Background

I fully understand that public and private members do not really exist in the C language.  However, like most C programmers, I still treat members as public or private to maintain the OO design.  In addition to the typical OO methods I have found my self following a pattern (see example below) that makes it easier for me to distinguish which methods are meant for the outside world vs the private members that may have fewer checks / are more efficient etc... Does a standard or best practice exist for such a thing or is my example below a good way to approach this?

Example Header

```<code>#ifndef _MODULE_X_H_
#define _MODULE_X_H_

bool MOD_X_get_variable_x(void);
void MOD_X_set_variable_x(bool);

#endif /* _MODULE_X_H_ */
</code>```

Example Source

```<code>// Module Identifier: MOD_X
#include "module_x.h"

// Private prototypes
static void mod_x_do_something_cool(void);
static void mod_x_do_something_else_cool(void);

// Private Variables
static bool var_x;

// Public Functions - Note the upper case module identifier
bool MOD_X_get_variable_x(void)      {return var_x;}
void MOD_X_set_variable_x(bool input){var_x = input;}

// Private Functions  - Note the lower case module identifier
void mod_x_do_something_cool(void){
     // Some incredibly cool sub routine
}

void mod_x_do_something_else_cool(void){
     // Another incredibly cool sub routine
}
</code>```

答:
The convention I use is:

Public function (in header file):

```<code>struct Classname;
Classname_functionname(struct Classname * me, other args...);
</code>```

Private function (static in implementation file)

```<code>static functionname(struct Classname * me, other args...)
</code>```

Don't focus on case. The point is to distinguish two public methods from two classes by prepending a prefix (class name in this convention).

Moreover, what makes OO-C is the way the object is passed as first argument.

Body:
The convention I use is:

Public function (in header file):

struct Classname;
Classname_functionname(struct Classname * me, other args...);

Private function (static in implementation file)

static functionname(struct Classname * me, other args...)

Don't focus on case. The point is to distinguish two public methods from two classes by prepending a prefix (class name in this convention).

Moreover, what makes OO-C is the way the object is passed as first argument.


问:
If a language changes quickly, is this considered a good thing?
I have seen some languages that change quickly (I mean they are improved every year for example) and some others that are improved slowly.

My question, if a language changes quickly is this a good thing or a bad thing for the programmer? Do programmers like to learn new thing in the language or do they prefer to stick with what they already know?

答: I think it truly depends on the language and the following that the language has. For instance, I think that if C# and Java started popping out changes in a more rapid pace that it would be accepted (as long as they are backwards compatible like Carra said). However, if the language hasn't gained traction yet and it is still changing rapidly, I know I wouldn't bother with it since there is a chance what I try to learn today will be totally different than what is out in 6 months and since the language is new/unpopular it wouldn't be detrimental to me (read: my career) for me to just pass on it.</p>


问:
Can a Code Review help in learning the code-flow and/or technology of a large code-base?
I'm new to VC++, and so am not very familiar with COM, ActiveX, IDL etc. When I mentioned this to my tech-lead, he assigned me the task of doing the code review of files he felt were important, in terms of the code that I'll soon be working with.

The actual code-base is approx. 10000 files.

I'm a bit skeptical that doing a code review can help in understanding VC++ (I've already worked with C++ on Linux extensively for 2 years and have plenty of experience in Actionscript, Processing and many other languages).

Since the code yet has to be built and run on my system (I'd prefer putting breakpoints and finding the code-flow), my tech-lead gave me the code review work. Is there a better way?

答:
In general, yes, code review is a good way to learn a code base.

As described, maybe, code review is a way to learn VC++.

I know that's wishy-washy, but it truly depends on the goal of the code review and how it's carried out.  If you're being used as a QA step, independently doing code review at your work station to distract you while your dev system is set up, then you're going to have a hard time learning anything.  You can certainly turn it into a learning experience with the right mindset (taking notes, recording questions), but it's an overwhelming way to start.  You have no context, and in this environment, no way to even test your assumptions.  This is not dissimilar to the age-old trope of putting new team members on low priority bug fixes.  You'll learn enough out of necessity to fix that bug, but you won't have the big picture.

If the goal of the code review is to get you familiar with the system, then it should be carried out as part of a group exercise, with projectors and discussion.  A code review is a great way to focus communication and the instant feedback you can get can accelerate your learning curve.  You'll have an opportunity to point out confusing parts and get answers in context of the code you'll be working on.

Edit:

Given your constraints, I have two more suggestions.  If you can setup a machine that will run VC++ (but not necessarily your project's full dev environment), you could try prototyping concepts as you come across them in the code.  So, discover a new technology in your code reading, fire up Visual Studio, find an example online and get it running, then adapt the example (as much as possible) to match the code you're reading.

The other suggestion is to approach it as described in this other answer.  This is a new system, you don't know anything about it and are encouraged not to trouble others.  You can still do some measure of "debugging" via breakpoints, you just have to do it on paper.  This will feel painful (it is), but it will improve your code reading skills and will give you another tool to use when firing up a debugger isn't optimal.