问:
How much Code Coverage is "enough"?
We are starting a push for code coverage here at my work, and it has got me to thinking.... How much code coverage is enough?

When do you get to the point of diminishing returns on code coverage?  What is the sweet spot between good coverage and not enough?  Does it vary by the type of project your are making (ie WPF, WCF, Mobile, ASP.NET)  (These are C# classes we are writing.)

答:
I think it depends on the part of the application you are testing. E.g. for business logic or any component involving complex data transformations, I would aim at 90% (as high as possible) coverage. I have often found small but dangerous bugs by just testing as much of the code as possible. I would rather find such bugs during testing than letting them occur at a customer's site one year later. Also, a benefit of a high code coverage is that it prevents people from changing working code too easily, since the tests have to be adapted correspondingly.

On the other hand, I think there are components for which code coverage is less suited. For example, when testing a GUI it is very time consuming to write a test that covers all the code that gets executed when clicking on a button in order to dispatch the event to the right components. I think in this case it is much more effective to use the traditional approach of performing a manual test in which you just click on the button and observe the behaviour of the program (does the right dialog window open up? does the right tool get selected?).

Title: How much Code Coverage is "enough"?


问:
Is there a canonical book on Android Development?
I am getting into Android Development and want a book to help fill in some of the gaps.

Is there a book out there that's the de-facto standard for describing best practices, design methodologies, and other helpful information on Android Development? What about that book makes it special?

答: To me, definitively paying for a suscription in Commonsware was the best resource related to development of Android apps. Also Mark Murphy gives you weekly office hours and all the source code is in his Github account.</p>

ContentLicense: CC BY-SA 3.0


问:
How do you keep track of large projects?
When dealing with a project that has many different files, I always seem to loose track of how the parts interact with one another. I've never really had much of a problem understanding smaller components in isolation, but as the complexity of the project increases, I find myself unable to mentally construct an understanding of what is going on. I notice this especially with OOP projects, as the number of methods and source files increase.

My background:
I'm a self-taught web programmer. I've dealt mostly with python for quick and dirty scripts, but I've also done a few basic django projects. I like web frameworks such as flask, because in the simplicity of a single-file layout, I can easily keep track (mostly) of what is going on.

I now find myself in a situation where I need to interact with a large Zend Framework PHP project that someone else developed, and I'm overwhelmed with trying to understand the code spread out to numerous files.

What techniques and processes have you found useful to understand a large code base that someone else has developed? Is there any particular diagram that you find helps you grasp the larger picture?

答:
As requested, here is my comment as an answer.

When working with other people's code, I tend to create or if possible generate UML class diagrams to give me an overview of the static structure. The visual diagram helps me especially when I have to go back later on and already forgot the context of a class. I sometimes do it for dynamic behaviour as well to line out the interactions between collaborateurs, but I don't do that that often.

If the codebase contains tests (integration or unit), those are sometimes worth checking out as well.


答:
Space critical software requires 100% statement coverage.

At first it makes no sense. Everybody knows that a full test coverage doesn't mean that the code is fully tested and that it is not that difficult to get 100% coverage without actually testing the application.

Nevertheless, 100% coverage is a lower limit: although 100% coverage is not a proof of a bug-free software, it is certain that with a lesser coverage the code is not fully tested and this is simply unacceptable for space critical software.

ContentLicense: CC BY-SA 2.5

Title: How much Code Coverage is "enough"?

Body:
We are starting a push for code coverage here at my work, and it has got me to thinking.... How much code coverage is enough?

When do you get to the point of diminishing returns on code coverage?  What is the sweet spot between good coverage and not enough?  Does it vary by the type of project your are making (ie WPF, WCF, Mobile, ASP.NET)  (These are C# classes we are writing.)


问:
Organizing Class Members in Regards to Access Modifier
If we look at typical implementation of a Class, we usually see the private members defined at the beginning and public( mostly functions and Accessors) defined towards the bottom. Now, is this a Industry standard agreed by a lot of people?

How about keeping the private members towards the end as updates and additions are usually done to the Public Members(mostly functions), to fix bug or provide enhancement, so we don't have to scroll down towards the end to get to the function definition section.

I understand, good IDEs will allow us to Jump towards a specific attribute, but considering other factors, such as Code Review, it may be convenient to have the Public Definitions towards the beginning.

What is the most accepted standard for Class Member Organization?

答:
I think it has to do more on: how each developer like to organize the class members, based, on how it doing some class model in its mind.

Altought, its more common to start with the:

```<code>private
protected
public
</code>```

sort order.

And, eventually mix each access, depending on what they are doing.

Body:
I think it has to do more on: how each developer like to organize the class members, based, on how it doing some class model in its mind.

Altought, its more common to start with the:

private
protected
public

sort order.

And, eventually mix each access, depending on what they are doing.


问:
Are null references really a bad thing?
I've heard it said that the inclusion of null references in programming languages is the "billion dollar mistake".  But why?  Sure, they can cause NullReferenceExceptions, but so what?  Any element of the language can be a source of errors if used improperly.

And what's the alternative?  I suppose instead of saying this:

Customer c = Customer.GetByLastName("Goodman"); // returns null if not found
if (c != null)
{
    Console.WriteLine(c.FirstName + " " + c.LastName + " is awesome!");
}
else { Console.WriteLine("There was no customer named Goodman.  How lame!"); }
```

<p>You could say this:</p>

<pre class="lang-cs prettyprint-override"><code>if (Customer.ExistsWithLastName("Goodman"))
{
    Customer c = Customer.GetByLastName("Goodman") // throws error if not found
    Console.WriteLine(c.FirstName + " " + c.LastName + " is awesome!");
}
else { Console.WriteLine("There was no customer named Goodman.  How lame!"); }
</code>```

But how is that better?  Either way, if you forget to check that the customer exists, you get an exception.

I suppose that a CustomerNotFoundException is a bit easier to debug than a NullReferenceException by virtue of being more descriptive.  Is that all there is to it?

答:
null is evil

There is a presentation on InfoQ on this topic: Null References: The Billion Dollar Mistake by Tony Hoare

Option type

The alternative from functional programming is using an Option type, that can contain SOME value or NONE.

A good article The “Option” Pattern that discuss the Option type and provide an implementation of it for Java.

I have also found a bug-report for Java about this issue: Add Nice Option types to Java to prevent NullPointerExceptions. The requested feature was introduced in Java 8.

Title: Are null references really a bad thing?

ContentLicense: CC BY-SA 4.0


问:
Years experience over unfinished degree?
I'm currently in my placement year and working for a great software development company. It was always my intention of getting to this stage through university, getting enough academic experience as well as the year’s placement and then try to get a full time programming job without the need to finish my degree. I decided this from an early stage as I have never really liked the whole university environment. I was so unhappy at university and I’m so happy now I’m on my placement year, I really don’t know if I can go back.

My question is, do you think companies will take me on if I apply for other jobs after my placement year and not penalize me for not finishing my degree?

I guess at the end of the day I don't want to look back on my life and think "god, why didn't I just spend one more year being unhappy to have a job I love" but I know that even if I get a degree I could still end up without a programming job and this worries me more than anything.

答:
do you think companies will take me on if I apply for other jobs after my placement year and not penalize me for not finishing my degree?

Some will, and some will not. My advice, as well as the advice of others on this thread, is that you should complete your degree. It is very appealing (and easy) to look at the short-term costs/benefits without considering the longer term costs/benefits.

This is one of the few well-paying careers open to people without college degrees. It is also a bastion of libertarianism and one of the last meritocracies in America: what you can do is almost always more important than who you know. It will not always be this way.

I've got a close friend who has been a contractor for the past 20+ years. For him, the software development environment changed around 2009 and now he is finding that his lack of a college degree is what is getting him rejected. At his age, he'd be over 60 by the time he finishes a bachelors degree if he starts now. His experiences, as well as those of my other friends over 55, tell me that I need to have an exit plan from this career before one is forced upon me, and this is why I'm working on my 3rd bachelors degree (this particular credential - a bachelors in accounting - is required to sit for the CPA exam). From my own unscientific surveys, CPAs retire when they want to, not because someone wants to hire younger people in the office.

On another - legal - viewpoint, NCEES (the organization that makes the Professional Engineer exams) is developing an exam for Software Engineering. This means that at least 10 states have expressed an interest in the exam and are interested in licensing software developers (hey, here in Colorado, we license kickboxers and hunting guides as well as doctors, lawyers, accountants and hair dressers). NCEES started developing this exam in 2009 and usually it takes them 2-3 years to develop and prepare one. Currently, to sit for a PE exam, you will have to have a bachelors degree. By 2020, states will change the requirements so that you'll need a Masters (or PhD) to sit for a PE exam. A licensure requirement for software developers will cause a lot of grief and complainery. Whether you like it or not, this sort of thing is coming. If you are not prepared, then you may end up switching careers long before you burn out on development.


问:
Where should I store my Image files for an app
So In my app, I have a bunch of images.  And in order to keep the app size down, I could store those images on my serve, and just download and cache them as needed.  But my question is, will that hurt user experience?  Is it likely an iOS user won't have internet access while using my app?</p>

答:
This is a "it depends" type question:

If you are building an app like the XKCD or Dilbert comic viewers, you could get away with loading and caching at the user's discretion - both are web comics, and are updated frequently, so the user expects to have to have a web connection.

If your app showcases products, art or locations, you would have low-res versions in-app that are "good enough", you could then allow the user to download hi-res versions (or even videos) and cache them, again at the user's discretion (the hi-res option would only show up if the app can reach the web server, of course...)

If your app is a map kit based travel planning app - you probably will have to expect a web connection at least initially, caching only the specific map sections that pertain to the planned journey.

Lastly, if you want to give the full hi-res experience from the get-go, you will need to keep all media in-app as part of the initial app download - the user might be purchasing the app in iTunes and then sync it to their iOS device.

I have found iOS apps that use all the above.


问:
Version control programs for XML-files - merge/diff tool
My programming environment / language (gamemaker) gives the source files as "XML-files". Each resource has its own XML file. Where the properties (code is a property) are stored inside xml tags.

Is there a source control which can handle these? With subversion collisions don't seem to be handled correctly: when a collision happens, subversion breaks the XML structure. Which in turn breaks Gamemaker when updating.

EDIT (editing here as comments don't seem to handle newlines :P), an example of a source file that got "destroyed" by subversion:

```<code><object>
  <spriteName>sprBall</spriteName>
  <solid>0</solid>
  <visible>-1</visible>
  <depth>0</depth>
  <persistent>0</persistent>
<<<<<<< .mine
  <parentName>self</parentName>
=======
  <parentName>objExplosion</parentName>
>>>>>>> .r16
  <maskName><undefined></maskName>
  <events/>
</object>
</code>```

EDIT2: because of lack of experience with these tools, I asked the wrong question. So here a better wording:

In the example above an xml-file-reader will crash when trying to read the file. However manually resolving the conflict is "hard". (And in extreme cases impossible). "" doesn't say anything in itself. - As the first question becomes "parent name of what?"- An object? - which object? In this case one can see it quickly. However if the xml file reaches 100+ lines with 6-7 layers of tags it becomes a mess just looking through it. Especially as many tags are not named the same as they are in the IDE.

What I hoped to have is that the conflict to be changed in such a way an xml-reading library can read it. - For example that the .r16 change is displayed into a comment (or subtag/attribute).

```<code><parentName>self
<!--.r16: objExplosion--></parentName>
</code>```

From that point on I can program a tool to help analyzing the conflict. - I can use one of the many xml libraries to write a simple application visualizing the tree.

Well I'm just surprised this hasn't been a problem to anyone else :/.

答:
I think that you just need a better merge tool. Dont ever save a file with those svn merge markers in them, resolve the conflicts first and only save valid XML documents.

We used to use XML files for configuration of our application and these were stored in the Mercurial repository along with the application source code.

Using kdiff3 with TortoiseHG I never had a problem that couldn't be fixed by looking at both branches of a merge and their common ancestor.


答: My thought is that you should read the documentation. I know hackers love to tell you "the code is the documentation" and use that as an excuse not to write any documentation, but they are wrong. Look at the Linux kernel, a massive software project of many millions of lines of code: I don't think anyone could really come in fresh without having read a book and just pick it up. If the code you are working with isn't documented (or well commented if a smaller project) then it probably is not good code.</p>

Title: How do you keep track of large projects?

Body:
When dealing with a project that has many different files, I always seem to loose track of how the parts interact with one another. I've never really had much of a problem understanding smaller components in isolation, but as the complexity of the project increases, I find myself unable to mentally construct an understanding of what is going on. I notice this especially with OOP projects, as the number of methods and source files increase.

My background:
I'm a self-taught web programmer. I've dealt mostly with python for quick and dirty scripts, but I've also done a few basic django projects. I like web frameworks such as flask, because in the simplicity of a single-file layout, I can easily keep track (mostly) of what is going on.

I now find myself in a situation where I need to interact with a large Zend Framework PHP project that someone else developed, and I'm overwhelmed with trying to understand the code spread out to numerous files.

What techniques and processes have you found useful to understand a large code base that someone else has developed? Is there any particular diagram that you find helps you grasp the larger picture?


问:
Are there any "enterprise ready" functional programming languages?
By "enterprise ready" I am referring to availability of tools: dependency management, build management, message servers, databases, application platforms and servers, and are secure and scale well?

For example, is there a lisp (or ML) alternative to j2ee?

Please exclude FP's ported to JVM or .NET CLR.

EDIT:  I know that one could use an FP jvm port i.e. clojure or F# on .NET CLR however I am curious to know if it is possible to develop a purely functional application for the enterprise without the JVM or CLR?

答: I don't use Erlang, but I know someone who does, and from everything he's described it as it sounds like exactly what you are looking for.  (It was designed by an enterprise (Ericsson) for enterprise use, after all.)</p>

OwnerDisplayName: Reuben Peter-Paul

OwnerDisplayName: Chris K


答:
You have Haskell for Enterprise Linux. The haskell wiki even includes a survey page about how to use Haskell in the Enterprise.

Erlang (as mentioned by Chris) is definitely also a good suggestion. It is built to scale, be fault-tolerant and stay in continuous operation for many years.

Personally I'm more of a fan of the static type system that Haskell has.

Title: Are there any "enterprise ready" functional programming languages?

Body:
By "enterprise ready" I am referring to availability of tools: dependency management, build management, message servers, databases, application platforms and servers, and are secure and scale well?

For example, is there a lisp (or ML) alternative to j2ee?

Please exclude FP's ported to JVM or .NET CLR.

EDIT:  I know that one could use an FP jvm port i.e. clojure or F# on .NET CLR however I am curious to know if it is possible to develop a purely functional application for the enterprise without the JVM or CLR?


问:
what is exactly an enterprise app store
My idea of an enterprise app store is that there is a page on the company's website where all the apps that that company developed for its employees are listed so they can use them. And access to this apps is restriceted to the employees of the company.

As far as I know you can download an Android App from any website and install it on an Andoid phone, you don't have to use Android Market. However installing an App that does not come from the Android Market is not that straightforward.

For Apple, you can only install an app from the Appstore, so how can you have an enterprise app store?

Please tell me what exactly is an enterprise app store. I think I got it wrong, also I read a lot on the internet for this keywords.

答:
Apple's iOS Enterprise Developer programs allows a D&B rated corporation to be certified or authorized and get digital signing certificates which allow the companies employees to download apps from the company's own web site, which could look like an internal app store, or just be an internal web page, onto the employee's iOS devices.  It contractually restricts distribution to employees only.

For a small company with a bit less than 100 total max iOS devices (including all possible potential future replacements and upgrades) for all apps to be deployed, it's easier to just use a regular iOS Company Developer enrollment and Ad Hoc app distribution, where apps could then be deployed from a web site such as TestFlight to employees or clients to those less-than-100 registered devices.

Both Apple's Enterprise and regular Developer Ad Hoc apps will require annual renewal, as the certificates allowing the apps to run expire.

Title: what is exactly an enterprise app store


问:
Benefits/Pitfalls of include
Do web pages load faster or load slower when all headers, footers and basic functions are placed in external files and called using the statements below? Are there any other benefits to separating such content?</p>

```<code><?php include("includes/functions.php"); ?>
<?php include("includes/header.php"); ?>
<?php require_once("includes/functions.php"); ?>
</code>```

答:
Do web pages load faster or load slower when all headers, footers and basic functions are placed in external files and called using the statements below?

There's no noticable performance issue. Check out the metrics in this blogpost, which are simple enough to recreate on your own. The results are:

------------------------------------
Running for 1000 files: require, require_once, include_once, include
------------------------------------
Results:
                     faster by   og. time
    include_once:          n/a   0.088193
    require_once: +   0.013137   0.101330
         require: +   0.030759   0.118952
         include: +   0.045299   0.133492
```

<p>The benchmark is more geared towards comparing the functions, but it's evident that the times are extremely small. This other benchmark shows: </p>

<pre class="lang-none prettyprint-override"><code>[11-Jan-2008 11:31:57] Benchmark include 0.039840936660767
[11-Jan-2008 11:31:57] Benchmark require 0.05462384223938
</code>```

Also for 1000 files. So apparently, the performance penalty is minimal. At heart both include(), require() and their _once() equivalents are simple filesystem reads, nothing special about them that would hint towards a performance concern.

Bear in mind that if you find includes to be slow, you might have stumbled upon a bug. The one I've linked to is closed, but you never know. A good hint is the first answer to the bug:

The include process is identical on all Win32 systems, any slowdowns are likely to be related to either the drive speed or the OS internals.

That said one of the reasons you are getting such bad numbers is because you are using a partial path PHP needs to resolve first. This compounded with ZTS mode makes things very slow, change the include statement to use full paths and you'll see much improved performance, not to mention much more consistent numbers.

It didn't make any difference with the bug, but you should always have it in mind, if you are going for thousands of includes.

Are there any other benefits to separating such content?

Yes, of course. You have one file for your functions, one for your header and one for your footer, which means that you don't have to rewrite them every time you need them. Isn't that enough? Don't repeat yourself.

Title: Benefits/Pitfalls of include

Body:
Do web pages load faster or load slower when all headers, footers and basic functions are placed in external files and called using the statements below?

There's no noticable performance issue. Check out the metrics in this blogpost, which are simple enough to recreate on your own. The results are:

------------------------------------
Running for 1000 files: require, require_once, include_once, include
------------------------------------
Results:
                     faster by   og. time
    include_once:          n/a   0.088193
    require_once: +   0.013137   0.101330
         require: +   0.030759   0.118952
         include: +   0.045299   0.133492

The benchmark is more geared towards comparing the functions, but it's evident that the times are extremely small. This other benchmark shows:

[11-Jan-2008 11:31:57] Benchmark include 0.039840936660767
[11-Jan-2008 11:31:57] Benchmark require 0.05462384223938

Also for 1000 files. So apparently, the performance penalty is minimal. At heart both include(), require() and their _once() equivalents are simple filesystem reads, nothing special about them that would hint towards a performance concern.

Bear in mind that if you find includes to be slow, you might have stumbled upon a bug. The one I've linked to is closed, but you never know. A good hint is the first answer to the bug:

The include process is identical on all Win32 systems, any slowdowns are likely to be related to either the drive speed or the OS internals.

That said one of the reasons you are getting such bad numbers is because you are using a partial path PHP needs to resolve first. This compounded with ZTS mode makes things very slow, change the include statement to use full paths and you'll see much improved performance, not to mention much more consistent numbers.

It didn't make any difference with the bug, but you should always have it in mind, if you are going for thousands of includes.

Are there any other benefits to separating such content?

Yes, of course. You have one file for your functions, one for your header and one for your footer, which means that you don't have to rewrite them every time you need them. Isn't that enough? Don't repeat yourself.


问:
Is there any way to test how will the site perform under load
I have made an Asp.net MVC website and hosted it on a shared hosting provider. Since my website surrounds a very generic idea, it might have number of concurrent users sometime in future.

So, I was thinking of a way to test my website for on-load performance. Like how will the site perform when 100 or 1000 users are online at the same time and surfing the website. This will also make me understand whether my LINQ queries are well written or not.

答:
I also like Loadimpact for stress testing.  One thing I tend to use for quick checks on my site is Apache Bench.  When I want to run some final tests, I will look toward a pay service.

My work also invested in WebLoads, which is very pricey but allows us to test all of our sites internally.  I don't recommend it though.


答:
I have NEVER heard it said in a staffing meeting "I'd love to hire him, but HE HAS A DEGREE". I have REPEATEDLY heard the opposite (e.g. DON'T hire him because he DOESN'T have one).

Finish your degree. It WILL NOT hurt your job prospects... it enhances them!

Title: Years experience over unfinished degree?

Body:
I'm currently in my placement year and working for a great software development company. It was always my intention of getting to this stage through university, getting enough academic experience as well as the year’s placement and then try to get a full time programming job without the need to finish my degree. I decided this from an early stage as I have never really liked the whole university environment. I was so unhappy at university and I’m so happy now I’m on my placement year, I really don’t know if I can go back.

My question is, do you think companies will take me on if I apply for other jobs after my placement year and not penalize me for not finishing my degree?

I guess at the end of the day I don't want to look back on my life and think "god, why didn't I just spend one more year being unhappy to have a job I love" but I know that even if I get a degree I could still end up without a programming job and this worries me more than anything.


答:
There are some good answers here, I'm just adding this one due to my own frustration in the past (and nobody else has mentioned it yet).

Working abroad

If you don't have a four year degree, you may not be eligible for Visa sponsorship in many countries. I have upwards of 10 years of experience myself and have run into this issue (was a couple years ago and things may have changed, but I doubt it).

If you have your degree, then the world, as they say, is your oyster.


答:
There is no shortcut. You just have to suffer through it.

To answer your question about how to get diagrams, doxygen is what you want. AFAIK it works with PHP.

More generally, I go through the roughly following stages when encountering a new codebase:

Understand what it does from a user point-of-view. Be able to actually use the application yourself like a power-user. Understand how the real end-users work with it. This could require sitting down with them until you gain a solid understanding of what they do.

Communicate with the original developers, if possible. At first, you'll have architectural questions stimulated by the end-user experience. Later on, you'll have implementation questions about edge-cases and details. Being able to get answers from the developers will help far more than any comments or documentation (which is at best incomplete and often misleading or entirely absent).

Learn about whatever framework you're using. At a minimum, you should be able to create a "hello world" or other simple application with that framework before diving into the production application.

Get a grip on the entire deployment process (best done while original developers are holding your hand). If you can't take the current codebase and build it and deploy it through a test/validation/prod environment, you're toast. Even the smallest change will require jumping through all the hoops of deployment, so why not get this part down right away? In so doing, you'll get introduced to all the lovely servers, databases, services and scripts used by the app-- you will know "where it lives".

Get a grip on the functional tests (if any). How do you know if the thing is running properly? What do the operations folks have to do for the care and feeding of the application?

Understand the logs of the app. Although I've never worked with PHP, I'll take a wild guess and say that any serious PHP application will have some type of logging. If you understand the logs, you'll have a good starting point when the time comes for debugging problems.

---- Note that up until here, I've haven't even mentioned looking closely at the codebase. There is A LOT you can learn about a large project without even looking at the code. At some point, of course, you have to get comfortable with the code. Here's what helps me:

For diagrams, doxygen is an excellent tool that will generate call-graphs and other relationships for you. It happens to have PHP capability! If you haven't tried doxygen, you absolutely have to give it a spin. Although I can't vouch for how intelligible it will be for code inside a framework, but it could help. Original developers are often shocked at what they see when presented with doxygen-generated docs of their code. The good news is that it really helps to jog their memory and help you better.

If you have a suite of unit tests, taking a close look at them should provide a window into the inner workings of the application. These will also be the first place to look for bugs you might have introduced while making changes.

IDE bookmarks are invaluable for tagging hot-spots in the codebase. Being able to toggle through them rapidly will promote understanding.

Reading recent bug-reports and their resolutions are also valuable for understanding hot-spots and will help you get up to speed on the most relevant portions of the codebase.


问:
How do you organize your projects folders?
Good afternoon

I would like to know how do you guys organize your project folders?

I had once a boss that suggest me to organize by Customers.

```<code>Projects
|
|----Customer 1
     |---- A Cool Solution 1
           |---- source
                 |---- version1.0
                 |---- version1.1
           |---- docs
                 |---- analysis
                 |---- meetings
                 |---- manuals
|----Customer 2
|----Customer 3
</code>```

A friend of mine told me to organize tem by Technology

```<code>Projects
|
|----.NET
     |---- C#
          |---- Customer 1
                |---- A Cool Solution 1
                      |---- source
                            |---- version1.0
                            |---- version1.1
                      |---- docs
                            |---- analysis
                            |---- meetings
                            |---- manuals
|----Ruby
|----PHP
</code>```

And you? Do you have a clever way to organize your project folders?

答:
I have, in the past, used Subversion repositories to store my source documents, and followed the "project-minor" convention for repository organisation, which I have found to work very well for both large and small organisations.

We would structure our repository branches; tags & trunk as follows:

```<code>branches-+
         +-personal-+
         |          +-alice-+
         |          |       +-shinyNewFeature
         |          |       +-AUTOMATED-+
         |          |                   +-shinyNewFeature
         |          +-bob-+
         |                +-AUTOMATED-+
         |                            +-bespokeCustomerProject
         +-project-+
                   +-shinyNewFeature
                   +-fixStinkyBug
tags-+
     +-m20110401_releaseCandidate_0_1
     +-m20110505_release_0_1
     +-m20110602_milestone
trunk
</code>```

Within the actual source tree itself, we would use (something like) the following structure:

```<code>  (src)-+
        +-developmentAutomation-+
        |                       +-testAutomation
        |                       +-deploymentAutomation
        |                       +-docGeneration
        |                       +-staticAnalysis
        |                       +-systemTest
        |                       +-performanceMeasurement
        |                       +-configurationManagement
        |                       +-utilities
        +-libraries-+
        |           +-log-+
        |           |     +-build
        |           |     +-doc
        |           |     +-test
        |           +-statistics-+
        |           |            +-build
        |           |            +-doc
        |           |            +-test
        |           +-charting-+
        |           |          +-build
        |           |          +-doc
        |           |          +-test
        |           +-distributedComputing-+
        |           |                      +-build
        |           |                      +-doc
        |           |                      +-test
        |           +-widgets-+
        |                     +-build
        |                     +-doc
        |                     +-test
        +-productLines-+
        |              +-flagshipProduct-+
        |              |                 +-coolFeature
        |              |                 +-anotherCoolFeature
        |              |                 +-build
        |              |                 +-doc
        |              |                 +-test
        |              +-coolNewProduct-+
        |                               +-build
        |                               +-doc
        |                               +-test
        +-project-+
                  +-bigImportantCustomer-+
                  |                      +-bespokeProjectOne
                  |                      +-bespokeProjectTwo
                  +-anotherImportantCustomer-+
                                             +-anotherBespokeProject
</code>```

The idea was (and still is) to use the structure of the repository to help structure communication between the engineering team; the customer-facing part of the business and various other stakeholders & domain experts.

To wit: Source documents that sit in one of the "project" directories get used (and earn money) only once. Documents that sit in one of the "productLines" directories earn money as many times as a product from that particular line gets sold. Documents that sit in one of the "libraries" directories earn money as many times as any of the products that use them get sold.

It makes the notion of amortization of costs explicit, and helps build support for source document reuse across the business.

In an ideal world, the customer facing part of the business would also use this structure to store presentations & other sales collateral, so developers can see what customer expectations have been created, right alongside the relevant product directory, and customer facing colleagues can track development progress on the features and products that they are selling.

It also means that there is a common structure over which our build automation tools can operate. (Our build scripts walk the source tree looking for "build" folders within which they find configuration files specifying how each component is to be built; a similar process happens for documentation generation and testing). Again, in an ideal world, the organization's website and other marketing collateral could be built in the same way.

As one final note; the continuous integration system knows that it needs to trigger a build; static analysis; smoke test & unit test run each time trunk is modified, each time any "tag" branch is modified, and each time any "AUTOMATED" branch branch is modified. This way, individual developers can use the CI system with their personal branches, an important capability, IMHO.

Body:
I have, in the past, used Subversion repositories to store my source documents, and followed the "project-minor" convention for repository organisation, which I have found to work very well for both large and small organisations.

We would structure our repository branches; tags & trunk as follows:

branches-+
         +-personal-+
         |          +-alice-+
         |          |       +-shinyNewFeature
         |          |       +-AUTOMATED-+
         |          |                   +-shinyNewFeature
         |          +-bob-+
         |                +-AUTOMATED-+
         |                            +-bespokeCustomerProject
         +-project-+
                   +-shinyNewFeature
                   +-fixStinkyBug
tags-+
     +-m20110401_releaseCandidate_0_1
     +-m20110505_release_0_1
     +-m20110602_milestone
trunk

Within the actual source tree itself, we would use (something like) the following structure:

  (src)-+
        +-developmentAutomation-+
        |                       +-testAutomation
        |                       +-deploymentAutomation
        |                       +-docGeneration
        |                       +-staticAnalysis
        |                       +-systemTest
        |                       +-performanceMeasurement
        |                       +-configurationManagement
        |                       +-utilities
        +-libraries-+
        |           +-log-+
        |           |     +-build
        |           |     +-doc
        |           |     +-test
        |           +-statistics-+
        |           |            +-build
        |           |            +-doc
        |           |            +-test
        |           +-charting-+
        |           |          +-build
        |           |          +-doc
        |           |          +-test
        |           +-distributedComputing-+
        |           |                      +-build
        |           |                      +-doc
        |           |                      +-test
        |           +-widgets-+
        |                     +-build
        |                     +-doc
        |                     +-test
        +-productLines-+
        |              +-flagshipProduct-+
        |              |                 +-coolFeature
        |              |                 +-anotherCoolFeature
        |              |                 +-build
        |              |                 +-doc
        |              |                 +-test
        |              +-coolNewProduct-+
        |                               +-build
        |                               +-doc
        |                               +-test
        +-project-+
                  +-bigImportantCustomer-+
                  |                      +-bespokeProjectOne
                  |                      +-bespokeProjectTwo
                  +-anotherImportantCustomer-+
                                             +-anotherBespokeProject

The idea was (and still is) to use the structure of the repository to help structure communication between the engineering team; the customer-facing part of the business and various other stakeholders & domain experts.

To wit: Source documents that sit in one of the "project" directories get used (and earn money) only once. Documents that sit in one of the "productLines" directories earn money as many times as a product from that particular line gets sold. Documents that sit in one of the "libraries" directories earn money as many times as any of the products that use them get sold.

It makes the notion of amortization of costs explicit, and helps build support for source document reuse across the business.

In an ideal world, the customer facing part of the business would also use this structure to store presentations & other sales collateral, so developers can see what customer expectations have been created, right alongside the relevant product directory, and customer facing colleagues can track development progress on the features and products that they are selling.

It also means that there is a common structure over which our build automation tools can operate. (Our build scripts walk the source tree looking for "build" folders within which they find configuration files specifying how each component is to be built; a similar process happens for documentation generation and testing). Again, in an ideal world, the organization's website and other marketing collateral could be built in the same way.

As one final note; the continuous integration system knows that it needs to trigger a build; static analysis; smoke test & unit test run each time trunk is modified, each time any "tag" branch is modified, and each time any "AUTOMATED" branch branch is modified. This way, individual developers can use the CI system with their personal branches, an important capability, IMHO.


问:
several similar tables vs several one-to-one relationships?
I have a sort of blog application that I'm working on for constrained writing. The posts have several types, and share some columns in common (title, body for instance), but they also have columns that they don't share in common. Please correct me if I'm wrong, but I feel like my two database design options are:

Create a separate table for each type of post (and then use UNION if I ever need to select all of the various types).

Create one table to store all of the similar columns (and then have several one-to-one relationships to define what's different about them--like an inheritance-type situation).

Which is better? Why? Are there other designs that would be better?

UPDATE:  these posts will be different types of constrained writing (I.e., poems), that are validated in specific ways based on the particular constraint technique, and may have a variety of other tables associated with them, so extensibility will be really important. That said it sounds like either the nosql or inheritance options would be best. I would just be worried about doing analytical stuff with nosql (never used it, so I just don't know anything about how to aggregate, etc, with it).

答:
Another choice is SQL blobs.  This is in some ways similar to the NoSQL approach, but you can stick to something you are more familiar with.  If some of your data fits the relational model more easily than the particular data you are having a problem with, this lets you put everything in the same relational database.

You could, for example, put the extra fields that are not in common in XML blobs, or JSON blobs, or any other form of serialization you like.

You could also have some kind of Name/Value table to store each property in it's own row of data for any extra properties you need.

None of the options in this answer or the others so far (or anywhere, AFAIK) are 100% ideal, so you have to pick your poison.

I usually do the inheritance based structure, but might map more than one class onto the same physical table (allowing nulls, so combining Oded's suggestion with inheritance).

You are really going to need to encapsulate your data access layer given your requirements.  Though even if you do, changing your mind later will be tough, since it will involve a data migration to your new structures.

Also, if you will hand-code a bunch of SQL queries based on your structure then your are that much more committed to it.


答:
What I would do is package the smallest necessary amount of images to get the app running on opening screen. If your app depends on the internet which it should, place your subsequent images in a CDN like Akumai or Amazon S3 and have the app start downloading them in the background if you think that is necessary. Otherwise, have them on demand.

Consider saving the loaded images in cache. This will be easier to maintain as you add more images rather than updating your app each time.

You were not specific as to what the app is doing. Do we need to sign an NDA first? :)

Title: Where should I store my Image files for an app

Body: So In my app, I have a bunch of images.  And in order to keep the app size down, I could store those images on my serve, and just download and cache them as needed.  But my question is, will that hurt user experience?  Is it likely an iOS user won't have internet access while using my app?</p>


问:
Internal Libraries (Subversion Externals, 'library' branch, or just another folder)
Currently working on multiple projects that need to share internal libraries. The internal libraries are updated continually. Currently only 1 project needs to be stable but soon we will need to have both projects stable at any given time.

What is the best way to SVN internal libraries?

Currently we are using the 'just another folder' like so...

trunk\project1

  trunk\project2

  trunk\libs

It causes a major headache when a shared library is updated for project1 and project2 is now dead until the parts that use the library are updated.

So after doing some research on SVN externals I thought of this...

trunk\project1\libs (external to trunk\libs @ some revision)

  trunk\project2\libs (external to trunk\libs @ different revision)

  trunk\libs\

I'm a little worried about how externals work with commits and not making library commits so complicated that I am the only one capable of doing it (mostly worried about branches with externals as we use them extensively).

On top of that we have multiple programming languages within each project some of which don't support per-project library directories (at least not easily) so we would need to check out on a per project basis instead of checking out the trunk.

There is also the 'vendor' style branching of libraries but it has the same problem as above where the library would have to be a sub folder of each project and is maybe a little to complicated for how little projects we have.

Any insight would be nice. I've spent quite a bit of time reading the Subversion book and feeling like I'm getting no where.

答:
In practice, this is less of a problem than it at first appears.

The basic principle is this: If you make a change to a library, it is your responsibility to ensure that all products and systems that are impacted by your change are modified to accomodate that change.

It is easy enough to identify components that use a library, and your regression tests should catch anything that you miss.

Comprehensive testing gives you the peace of mind to make changes quickly and with confidence.

Go with what you already have. It is the right thing to do.

```<code>trunk/developmentAutomation
trunk/libs/library1
trunk/libs/library2
trunk/productLines/productLine1/product1a
trunk/productLines/productLine1/product1b
trunk/productLines/productLine2/product2a
trunk/customers/customer1/bespokeProject1a
trunk/customers/customer1/bespokeProject1b
trunk/customers/customer2/bespokeProject2a
</code>```

Body:
In practice, this is less of a problem than it at first appears.

The basic principle is this: If you make a change to a library, it is your responsibility to ensure that all products and systems that are impacted by your change are modified to accomodate that change.

It is easy enough to identify components that use a library, and your regression tests should catch anything that you miss.

Comprehensive testing gives you the peace of mind to make changes quickly and with confidence.

Go with what you already have. It is the right thing to do.

trunk/developmentAutomation
trunk/libs/library1
trunk/libs/library2
trunk/productLines/productLine1/product1a
trunk/productLines/productLine1/product1b
trunk/productLines/productLine2/product2a
trunk/customers/customer1/bespokeProject1a
trunk/customers/customer1/bespokeProject1b
trunk/customers/customer2/bespokeProject2a


问:
Use of NotImplementedException
Is it considered bad practice to throw NotImplementedException for code you haven't written yet? Possibly TODO comments would be considered safer?

答:
It depends on your general philosophy around errors and error handling.  I am the "hard error" type of guy: I will throw an exception at the slightest hint that something might be wrong; I will assert everything; If there is an error, if something was expected to be there, and it is not, or if something is there, and it shouldn't, the entire universe must stop. The windows exclamation sound must ring ominously through the loudspeakers.

There are other people who would rather not be bothered with errors. So what if we ship it to the client and the entire reports module is missing because we forgot to code it, and nobody in testing realized it, because the application was all too silent about it?  Better do nothing, than throw an exception in the client's face!

Title: Use of NotImplementedException


答: I think it's good practice. The alternative is propagating an invalid value or state, which is going to affect both test and production code. </p>

Title: Use of NotImplementedException

Body: Is it considered bad practice to throw NotImplementedException for code you haven't written yet? Possibly TODO comments would be considered safer?


问:
Optimal organizational structure for IT?
There are many approaches to how to structure a company's IT shop to better fit the needs of the core business.  In my scenario, developing web and mobile access is central to the the needs of the organization of which I am thinking.  It is structured such that development is done by one group of worker bees, another for maintenance, another still for testing, etc. etc.

It seems this structure tends to lend itself to adversarial relationships because each area has its own measure of what success is:

Development --> Time To Market

Maintenance --> Stability of the environment

Testing --> Making sure they don't get spanked if something goes wrong.

There are many other organizational groups (for lack of a better term) for analysts, project managers, designers, etc.  In a perfect world, these groups would create checks and balances against one another, but in the end priority invariably gets placed on TTM, sometimes to the detriment of the other players.  This creates a lot of tension whenever releases come because an attitude of 'throwing code over the wall' prevails as the MO.

What other organizational structures have you observed in industry that better lend themselves to a greater sense of cohesiveness amongst the players?

答:
Conway's Law states:

"..organizations which design systems ... are constrained to produce
  designs which are copies of the communication structures of these
  organizations"

The corollary of this is that the best organizational structure is the same as the best software architecture.

Not knowing the specifics of your business, I am basing the following on some sweeping generalizations:

Experience indicates that software development is both expensive and risky; and that this risk and expense can only (even with strenuous effort) be reduced to a very limited extent.

Since cost & the level of risk is (approximately) fixed, you need to increase returns to achieve an acceptable reward:risk ratio.

The first obvious consequence of this is that organisations should focus on projects with a big pay-off. This is not always achievable, as the opportunities might not exist in the marketplace. The second obvious consequence of this is that development costs should be amortized as much as possible. For example, by spreading development costs over multiple product lines & projects. (I.e. code reuse).

So, back to Conway's law: What organizational structure maximises code reuse? The obvious answer would be to align organizational units around libraries & APIs, with each developer responsible for one or more libraries AND one or more products. How libraries get re-used is then no longer a purely technical decision, but an important business decision also. It should be a management function to ensure that development costs are amortized effectively to maximise return per unit development effort.

Each developer then has responsibility for the development, testing & in-service performance of the features supplied/supported by his library.


答:
iOS devices are often used in places without internet.

For iPhones, they are almost always going to be able to get to the net, even if slowly, barring abject wilderness and cellphone dead-zones. Further, much of the time, it will get at least 3G speeds.

While the iPod Touch is mainly an iPhone less the phone... internet requires access to a suitable WAP. Just because you're standing next to it doesn't mean you have access to it. Further, this makes for potentially much slower access - it's possible to set up a WAP on a dial-up connection. (I have seen this done by a couple of businesses.)

the iPad is, functionally, either of those modes, depending upon model.

Further, you need to consider the potential for success of your application. Can your storage/server handle 100 users? Probably. 1000? Most likely. Should it go wild and be 30K users? Can you afford the upgraded hosting should it succeed?

The trick is to balance the following issues:

expectation of internet

load times

memory footprint

your ability to host the potential traffic


答:
I'd say it's a good idea. Usually I see those exceptions thrown by skeleton code that is auto-generated from a form or diagram or something. The exception reminds me to implement the code, and it makes sure that there will be errors if I try to use the functionality that was set up but never fully implemented. Sometimes I will stub it out or replace it with something that is less likely to halt execution (such as printing a warning to the console), but I find that it works for me.

If you're building a library that others will be using having this exception is better than the alternative, which would be a user of your library calling a function and wondering why nothing seemed to happen. Of course, it's still pretty bad to have this exception in a shipped library but better than silent failures, IMO.

Title: Use of NotImplementedException


答:
I believe NotImplementedException is actually a good practice.

Indeed, if you forget to implement a method, and you use it later on in your project (and believe me, it happens), you might spend a long time debugging looking for what went wrong step by step. If you have the exception, the program will stop directly, prompting the exception (if you catch the exception, you'll find it quickly by looking what exception you caught).

I would recommend using the NotImplementedException combined with TODO comments, that way you combine GUI help (with the tasks in VS) and program safety.

For the release version, it's even more important in my opinion, as in most cases you would prefer your program to crash rather than having a program apparently working properly but producing erroneous results.

Title: Use of NotImplementedException


答:
The best organizational schemes I have ever seen can basically be described as "amoebas." Just a bunch of guys (and gals) with common goals working to get there and organically swallowing everything in their path. You might have someone in a lead role on a specific piece, but when everyone owns everything some beautiful things can happen.

Unfortunately this sort of structure makes PHBs heads explode and is rarely seen in the wild.

Title: Optimal organizational structure for IT?

Body:
There are many approaches to how to structure a company's IT shop to better fit the needs of the core business.  In my scenario, developing web and mobile access is central to the the needs of the organization of which I am thinking.  It is structured such that development is done by one group of worker bees, another for maintenance, another still for testing, etc. etc.

It seems this structure tends to lend itself to adversarial relationships because each area has its own measure of what success is:

Development --> Time To Market

Maintenance --> Stability of the environment

Testing --> Making sure they don't get spanked if something goes wrong.

There are many other organizational groups (for lack of a better term) for analysts, project managers, designers, etc.  In a perfect world, these groups would create checks and balances against one another, but in the end priority invariably gets placed on TTM, sometimes to the detriment of the other players.  This creates a lot of tension whenever releases come because an attitude of 'throwing code over the wall' prevails as the MO.

What other organizational structures have you observed in industry that better lend themselves to a greater sense of cohesiveness amongst the players?


答:
What kind of project is this? Work or home? At home, do whatever you want - whatever best reminds you that you need to finish whatever it is that you're working on.

At work, finish writing it.

I can't see a situation where I would checkin code that can/will break other devs, QA or a build.

Title: Use of NotImplementedException


问:
Mercurial Repository structure with heavyweight corporate comms, configuration management & test requirements
I am yet another Subversion user struggling to re-educate myself in the Tao of distributed version control.

When using Subversion, I was a big fan of the project-minor approach, and, with most of my former employers, we would structure our repository branches; tags & trunk as follows:

```<code>branches-+
         +-personal-+
         |          +-alice-+
         |          |       +-shinyNewFeature
         |          |       +-AUTOMATED-+
         |          |                   +-shinyNewFeature
         |          +-bob-+
         |                +-AUTOMATED-+
         |                            +-bespokeCustomerProject
         +-project-+
                   +-shinyNewFeature
                   +-fixStinkyBug
tags-+
     +-m20110401_releaseCandidate_0_1
     +-m20110505_release_0_1
     +-m20110602_milestone
trunk
</code>```

Within the actual source tree itself, we would use (something like) the following structure:

```<code>  (src)-+
        +-developmentAutomation-+
        |                       +-testAutomation
        |                       +-deploymentAutomation
        |                       +-docGeneration
        |                       +-staticAnalysis
        |                       +-systemTest
        |                       +-performanceMeasurement
        |                       +-configurationManagement
        |                       +-utilities
        +-libraries-+
        |           +-log-+
        |           |     +-build
        |           |     +-doc
        |           |     +-test
        |           +-statistics-+
        |           |            +-build
        |           |            +-doc
        |           |            +-test
        |           +-charting-+
        |           |          +-build
        |           |          +-doc
        |           |          +-test
        |           +-distributedComputing-+
        |           |                      +-build
        |           |                      +-doc
        |           |                      +-test
        |           +-widgets-+
        |                     +-build
        |                     +-doc
        |                     +-test
        +-productLines-+
        |              +-flagshipProduct-+
        |              |                 +-coolFeature
        |              |                 +-anotherCoolFeature
        |              |                 +-build
        |              |                 +-doc
        |              |                 +-test
        |              +-coolNewProduct
        +-project-+
                  +-bigImportantCustomer-+
                  |                      +-bespokeProjectOne
                  |                      +-bespokeProjectTwo
                  +-anotherImportantCustomer-+
                                             +-anotherBespokeProject
</code>```

The idea was (and still is) to use the structure of the repository to help structure communication between the engineering team; the customer-facing part of the business and various other stakeholders & domain experts.

To wit: Source documents that sit in one of the "project" directories get used (and earn money) only once. Documents that sit in one of the "productLines" directories earn money as many times as a product from that particular line gets sold. Documents that sit in one of the "libraries" directories earn money as many times as any of the products that use them get sold.

It makes the notion of amortization of costs explicit, and helps build support for source document reuse across the business.

It also means that there is a common structure over which our build automation tools can operate. (Our build scripts walk the source tree looking for "build" folders within which they find configuration files specifying how each component is to be built; a similar process happens for documentation generation and testing).

Significantly, the products on which I work typically take a LONG time to run performance measurement & characterization tests; from 20 to 200 hours; generating somewhere between several GB to several TB of processed test results/intermediate data (that must be stored and tied to a particular system configuration so performance improvement over time can be measured). This issue makes configuration management an important consideration, and also imposes some requirement for centralisation, as typically the computational resources needed to run the performance measurement and characterization tests are limited; (a small cluster of 64-128 cores).

As one final note; the continuous integration system knows that it needs to trigger a build; static analysis; smoke test & unit test run each time trunk is modified, each time any "tag" branch is modified, and each time any "AUTOMATED" branch branch is modified. This way, individual developers can use the CI system with their personal branches, an important capability, IMHO.

Now, here is my question: How can I replicate all of the above (and improve upon it, if possible), with Mercurial.

--edit:

My current line of thinking is to use a central Subversion Repository, to define the overall structure, but to allow the use of hg as a client so developers can have repos available locally.

答:
Okay, trying to answer this simply.

What you need to know

First thing you need to know: Mercurial is distributed version control and has some properties you should know about listed below.

The source come from one repository, where that repository can be cloned. All cloned repositories can share code with each other through synching (with pull and push commands, that can be access restricted).

Every user that has a copy of the code, has a clone of the repository. If they want to branch, they can do it in their local clone. That means you don't need to organize how every user should branch. They can do this for themselves.

Tags are created in mercurial by a commit (which is the same as hard tags in git). This means you don't need a directory inside your repository structure for tags.

The usual model that people work with in DVCS (which is employed in github and bitbucket) is to do it semi-centralized.

Each user has a public repository (in some share or on a secure server) and a private repository (in their own workstations). They are both clones of an integrator's "blessed" repository. Whenever they feel they're ready to publish their code, they can push the changes from to their public repository. An integrator can then choose which users to pull code into the "blessed" repository.

If the integrator can't merge some user's code easily, then the changes are rejected and it is up to that particular user to update their repository and fix the merge themselves. It is usually not that difficult if you merge often (as it is less code that needs to be merged) and usually that user should know what went wrong with the merge.

Repositories-per-project setup

So the usual set up is that for each project there is the following:

A public read-only repository that the integrator is responsible for. It is "blessed".

I.e. all users can pull/fetch content but have no access to push it.

Each user can have their own public clone of the repository.

Easiest set up as put in a share drive (though you might consider hosting such as bitbucket). The integrator receives pull-requests from the users and tries to pull the new code from these repositories. When merges are done without a hitch, it is put in the read-only repository. If not, then users are asked to fix the merge conflicts that arise by updating and merging it for themselves locally.

Each user can have their own private clones of the repository.

Good practice is to pull from their public clone, but it doesn't matter if they pull from their public or the integrator's. All commits are uniquely identifiable so merging commits that you forgot to fetch in the public one is relatively easy to fix (by pushing the changes from the private to the public, it automatically gets the integrator's changes as well).

Source code organization

As in how to arrange the project source itself is something you need to think through. If an artifact needs to be source controlled then put it in source control. Personally I don't like the idea of checking in artifacts that are made by the build or runtime (due to the high risk of merge conflicts on these kinds of artifacts) such as binaries or log files.

You can also check in configuration, as long as they make it easy for developers to get going and doesn't mess up configuration for releases or live/production environment (such as app/web server settings). This leads to the notion that if the configuration you have seriously hinders the developers to get started within five minutes after they've checked out the code then it needs to be refactored. Another requirements is that it should be darn hard for the developers to mess up the release or live/production environment.

You mention that you have test data that needs to be tied to some version of the code. Now this is a bit trickier because DVCS-systems such as Mercurial and Git have a tendency to get slow when you check in data that is HUGE. In my experience it gets really unbearable after 5 GB of binary files (your milage may vary, so you should test out how it works out for you). I would however recommend that you put generated data into it's own repository and have your test system tag them appropriately when checking them in (and/or create text files for the same meta data purposes).

I hope this all makes sense. Please comment below if I missed some detail or if something needs further explaining and I'll try to edit.


答:
Common Lisp has a long history of being used professionally.

It has two commercial implementations:

http://www.franz.com/

http://www.lispworks.com/

And several high-quality open source implementations.


问:
Is the GoF book still the one to read?

Possible Duplicate:

  Is there a canonical book on design patterns?

I'd like to read a design patterns book. GoF for sure is the one to read. But after 15 years is it still valid, I mean isn't there an updated one?

Something like "Charles Darwin On the origin of species" is a very important book, and some main concepts are still valid, anyway today (2010) one would read another book to study the subject.

In this question the main suggestions are the Head First and GoF books. But Head first is not a replacement for GoF.

So any suggestion or should I stick with GoF?

答:
Definitely begin with GoF - but bear in mind that since it came out there are numerous books with various pattern catalogues in them (most of the 'signature' series comes to mind, such as PoEAA or Enterprise Integration Patterns) which take the pattern idea into more specific areas.

Also remember that the implementation of some of the patterns is potentially a little archaic depending on the language you're working in. For example, although you could implement the Java code pretty much as-is in C# (and that would have been fine when C# 1 was knocking about) you'd be missing out on the potential that some modern language features provide. Specifically for .net I like the examples from dotfactory, Judith Bishop's book is pretty good too.

Title: Is the GoF book still the one to read?


问:
Is there an IDE for python that creates the same kind of reflective environment that Smalltalk provides?
As anyone who has used Smalltalk knows, one of the main benefits (other than a late-bound language that discourages many poor practices), is that the system is totally transparent and reflective, which makes understanding APIs and existing code easy, and locating functionality pretty easy.

Is there anything that creates a similar environment for Python?

A few examples of features of a smalltalk development environment, not natively found in python are:

search class/method/etc names,

examine inheritance hierarchies

functionality to show the full interface of a given class/object, and where the properties therein originate

an integrated graphical debugger which allows one to examine the full state of everything in the system, and see every instance of a given type, as well as all threads.

Note that I use windows, so anything that works well on windows would be particularly useful.

答: You can't really expect a Smalltalk-like Python IDE. In Smalltalk, the IDE is an integral part of the runtime (or "image").</p>


问:
What is the best way to evaluate new programmers?
What is the best way to evaluate the best candidates to get a new job (talking merely in terms of programming skills)?  In my company we have had a lot of bad experiences with people who have good grades but do not have real programming skills.  Their skills are merely like code monkeys, without the ability to analyze the problems and find solutions.

More things that I have to note:

The education system in my country sucks--really sucks.  The
people that are good in this kind of job are good because they have talent for it
or really try to learn on their own.

The university / graduate /post-grad degree doesn't mean necessarily that you know exactly how to do the things.

Certifications also mean nothing here because the people in charge of the certification course also don't have skills (or are in low paying jobs).

We need really to get the good candidates that are flexible and don't have mechanical thinking (because this type of people by experience have a low performance).

We are in a government institution and the people that are candidates don't necessarily come from outside, but we have the possibility to accept or not any candidates until we find the correct one.

答:
I suggest you go with a FizzBuzz question and hire the first one that passes. Further tests tend to be flawed as not every good programmer will approach a problem like you, or handle an interview without stuttering, or know the languages you want or care about or silliness like exchanging integers without a third variable (who needs that anyway? I mean, since RAM exceeded 128 bytes?).

Think about it. If the FizzBuzz question eliminates 199 out of 200, then it just eliminated hundreds of interviews. Were you really going to interview hundreds of prospects?

Just seems like diminishing returns after FizzBuzz. That is assuming that 199/200 is even approximately close. And I presume YOUR time is valuable too...


答:
I do not have a degree. It has not affected my ability to find work. I however have spent lots of time studying on my own to gain the knowledge I have (e.g. discrete mathematics, compiler theory). Without guidance, it was quite difficult at times, since I did not know what to learn first. I also spent the earlier part of my career as a contractor, so work was not steady. However, excluding the dot com bust, I have always been able to find work within a month of leaving my old contract.

I have worked for some very well known companies, but only later in my career. The skill set on my resume is what got me in the door. What sold them on me were the things I have accomplished, not the skill set that was on my resume. I'm sure I have missed opportunities due to the lack of a college degree, but I feel that it is only because those companies are filtering on a college degree and not my accomplishments.

I would much rather work for a company who hires programmers that enjoy and love what they do; not a company who simply wants people with college degrees.

To summarize, without a college degree, yes there will be missed opportunities, but there are so many opportunities out there that you won't notice them.


答:
The original proposal of using SVN externals is a good one, since this is pretty much exactly the problem that the externals feature was meant to solve.

```<code>trunk\project1\libs (external to trunk\libs @ some revision)
trunk\project2\libs (external to trunk\libs @ different revision)
trunk\libs\
</code>```

The main advantage of this arrangement is that it decouples project1 and project2 from changes to the library. The act of committing a change to trunk\libs does not by itself affect anyone working on either project1 and project2 (since they continue to refer to earlier versions of trunk\lib). Only when project1 or project2 are ready to deal with updates to trunk\lib will they commit a change to their repository updating the external reference to point to a more recent version of trunk\libs (and likely also including corresponding changes in their code that is affected by the library changes).

The key point is that project1 deciding to use a newer version of trunk\lib doesn't affect project2 (or vice-versa).

If you make trunk\lib a shared folder in a single repository, then commits to it will be normally affect both project1 and project2 whenever they update their working copies unless you work on branches to keep updates to the trunk from having immediate effect (but then you have to deal with merging changes you do want).

Title: Internal Libraries (Subversion Externals, 'library' branch, or just another folder)

Body:
Currently working on multiple projects that need to share internal libraries. The internal libraries are updated continually. Currently only 1 project needs to be stable but soon we will need to have both projects stable at any given time.

What is the best way to SVN internal libraries?

Currently we are using the 'just another folder' like so...

trunk\project1

  trunk\project2

  trunk\libs

It causes a major headache when a shared library is updated for project1 and project2 is now dead until the parts that use the library are updated.

So after doing some research on SVN externals I thought of this...

trunk\project1\libs (external to trunk\libs @ some revision)

  trunk\project2\libs (external to trunk\libs @ different revision)

  trunk\libs\

I'm a little worried about how externals work with commits and not making library commits so complicated that I am the only one capable of doing it (mostly worried about branches with externals as we use them extensively).

On top of that we have multiple programming languages within each project some of which don't support per-project library directories (at least not easily) so we would need to check out on a per project basis instead of checking out the trunk.

There is also the 'vendor' style branching of libraries but it has the same problem as above where the library would have to be a sub folder of each project and is maybe a little to complicated for how little projects we have.

Any insight would be nice. I've spent quite a bit of time reading the Subversion book and feeling like I'm getting no where.

Body:
The original proposal of using SVN externals is a good one, since this is pretty much exactly the problem that the externals feature was meant to solve.

trunk\project1\libs (external to trunk\libs @ some revision)
trunk\project2\libs (external to trunk\libs @ different revision)
trunk\libs\

The main advantage of this arrangement is that it decouples project1 and project2 from changes to the library. The act of committing a change to trunk\libs does not by itself affect anyone working on either project1 and project2 (since they continue to refer to earlier versions of trunk\lib). Only when project1 or project2 are ready to deal with updates to trunk\lib will they commit a change to their repository updating the external reference to point to a more recent version of trunk\libs (and likely also including corresponding changes in their code that is affected by the library changes).

The key point is that project1 deciding to use a newer version of trunk\lib doesn't affect project2 (or vice-versa).

If you make trunk\lib a shared folder in a single repository, then commits to it will be normally affect both project1 and project2 whenever they update their working copies unless you work on branches to keep updates to the trunk from having immediate effect (but then you have to deal with merging changes you do want).


答:
I expect a candidate to be able to manage algorithm analysis as well as the formal analysis required to understand and create more sophisticated concepts. That is taught in a comp sci degree. It is of course debatable as to whether they learned it, but it is taught.

Without amazing experience, portfolios (github et al), and recommendations, I would not recommend hiring someone for programming without a math-based degree, regardless of years of experience.

If someone drops out of college because they didn't want to finish it (that is, they didn't have health, family, or other practical reasons preventing the finish), that's pretty much a DQ. I don't want to work with a quitter.  College is not that hard to complete in the US.


答:
We used to have teams organized by client (or project) with a few specialists who supported mulitple clients. Then we went to the org structure of application developers and maintenance developers and database developers and the clients had to pool from a pool of people. This failed miserably. We are now back to the orginal structure and everyone is much happier.

One thing that happened when whe had a maintenance set of developers and application developers was that it became impossible to move from one category to another. Maintenance were looked on as having less skill and thus not qualified to change to be application developers.

Application developers in the meantime had no idea of the problems they created when they did a poor design because they never saw the support tickets. So they continued to make the same mistakes repeatedly. This of course annoyed the "less skilled" maintenance developers who had to fix the application developers mistakes while the application developers got all the recognition including pay raises and promotions.

Project managers were in a continual and time-consuming battle to get resources to do their work  which created a lot of organizational hate and discontent. No one could prioritize work effectively because they didn't know from day to day who they would have available to do the work. This also took away from the time they had to actually manage their projects and some bad delays and overrruns occured because they didn't have the time to see what was happening because of spending too many hours a day fighting to get people assigned to their high priorities.  Smaller clients were annoyed because they always lost the resource battle and thier high priorities weren't getting met. So they could have critical show-stopper bugs that weren't getting fixed.


答: I do both I but a \todo in my doxygene autodocing and then throw the exception.  That way if people can't be bothered to RTFM at least they will be able to figure out why their program crashed, instead of wondering why there is a declared function that is not returning a logical value.</p>

Title: Use of NotImplementedException


问:
For user defined data, is it better to use a table of tables or dynamically created tables?
In an application that allows users to define their own tables and columns (details of that are not the focus of this question, but imagine a tool that lets users create their own forms and automatically handles storage, just to get the idea) is it better to store each table and column they create in a "table" table and a "column" table, or to dynamically create tables and columns?

This "one table to rule them all" question is somewhat related, but in that case the "table" table is more clearly a bad idea.  In this case, if you don't go that route then all your queries will have to be dynamically generated.

Even though the argument "don't write yet another application designer tool for non-programmers, so you can keep adding features until you are basically having users develop in a crummy version of, say, Visual Studio, using your custom crummy language" is pretty reasonable, I've had a lot of projects with some version of the user defined tables requirement and this question is about how to implement it.  Whether to implement it is another question, but probably too specific to particular applications to be a good question here.

答:
A generic database design limits the proliferation of new tables as the number of forms and data elements grows. On the other hand even the simplest query involved 3 tables, in our case.

Queries indeed got very mind boggling. After 3 years of this I became of the opinion that explicit tables was better. I'd rather deal with more tables that better reflect the business form/model - that I can understand just by looking at them; vice 1/2 the tables but with multitudes of meaningless join tables requiring astonishing long, nested queries to make even the most rudimentary sense out of the data. You actually start memorizing the meaning/context of individual identity column primary keys!

Finally, we had evolved to where we had that one table to rule them all so as to get away from some of the inherent complexities (and bad coding and design decisions of the past) in the existing design and evolving user requirements. Nonetheless, we were certain we'd have problems as the table size went into the million+ row size.


答:
I always use NotImplementedException -- that's what it's for, after all.

This is related to the concept of "fail fast": if your code is throwing an exception, that should get caught before going to production.  If it does get to production, then at least the client knows that the assembly is incorrect.

If the code returns a meaningless value or, for void methods, takes no action, then the consumers of your code might reasonably think that the call was meaningful when it was not.  Then, later, when they get some correct code, their code might break because it depends on the former incorrect behavior.

Title: Use of NotImplementedException


问:
I've unit tested my class, now how do I get started with an integration test?
I've written a class that manages recipients on a MailChimp list, called MailChimpRecipient. It uses the MCAPI class, which is an third-party API wrapper.

http://apidocs.mailchimp.com/api/1.3/
http://apidocs.mailchimp.com/api/downloads/

I pass the MCAPI object into the constructor of the MailChimpRecipient object, so I have written unit tests using PHPUnit that test all of the logic in my own class (I am not testing the MCAPI class). I have 100% code coverage and all tests pass. This is done by mocking and stubbing the MCAPI object.

My next step was to write an integration test, also using PHPUnit, where I would construct the MailChimpRecipient fixture using a real MCAPI object, set up to use a real MailChimp list.

I have written what I think is an intergration test, which basically runs tests agains the public interface of the object, like:

```<code>public function testAddedRecipientCanBeFound()
{
    $emailAddress = 'fred@fredsdomain.com';
    $forename = 'Fred';
    $surname = 'Smith';

    // First, delete the email address if it is already on the list
    $oldRecipient = $this->createRecipient();
    if($oldRecipient->find($emailAddress))
    {
        $oldRecipient->delete();
    }
    unset($oldRecipient);

    // Add the recipient using the test data
    $newRecipient = $this->createRecipient();
    $newRecipient->setForename($forename);
    $newRecipient->setSurname($surname);
    $newRecipient->setEmailAddress($emailAddress);
    $newRecipient->add();
    unset($newRecipient);

    // Assert that the recipient can be found using the same email address
    $this->assertTrue($this->_recipient->find($emailAddress));
}
</code>```

The "integration" test doesn't test any of the internals of the class - it just makes sure that given a real MCAPI object, it behaves as advertised.

Is this correct? Is this the best way to run an intergation test? After all, the internals have been tested with a unit test. Am I right in thinking that the integration test is there to test that it really works, according the way its behaviour is advertised?

To take it a step further, the MailChimpRecipient class implements an interface, which will also be implemented by other classes. The idea is to use a factory to pass different types of mailing list recipient objects to my code, which all do the same thing, albeit using different mailing list providers. Since my integration tests test the that interface, how about using it for all of the classes that implement the interface? Then, in the future, if I design a new class to be used interchangably, I can run the same integration test before inserting it into a project.

Does this sound reasonable? The unit tests test the internals of an object, intergration tests make sure that it behaves as advertised?

答:
When testing your code you should pay attention to three areas:

Scenario testing

Functional testing

Unit testing

Normally the amount of test you have in each category would have the shape of a pyramid, meaning a lot unit tests at the bottom, some functional tests in the middle, and just a few scenario tests.

With a unit test you mock out everything that the class under test uses and you test it in pure isolation (this is why it's important to make sure that inside your class you retrieve all dependencies trough injection so they can be replaced under test).

With unit testing you test all possibilities, so not only the 'happy path' but also all error conditions.

If you are completely certain that your all units work in isolation you write a couple of tests (functional tests) to make sure the units also work when combined.
Then you write a scenario test, which tests the wiring between all the functional modules.

For example, suppose you're testing a car.

You could assemble the whole car and as a driver check every possible condition but that would be really hard to do.

Instead you would test a small part of the engine with all possibilities (unit test)

Then you test the whole engine (separate from the car) which would be a functional test.

As a last test, you put your key in, start the car and drive it to the parking lot. If that's working then you know that all parts (battery, fuel, engine, ..) are connected and since you tested them in isolation you can be pretty sure that the whole car is functioning correctly.

So in your case, you tested all error conditions and the happy path in your unit test and know you only have to an end-to-end test with the 'real components' to check if the wiring is correct.

A few other points,

Avoid conditional logic in your unit test. If you have to clean up, your using some kind of global state and the tests can suddenly influence each other.

Don't specify any data that's not relevant for the test. If I would change forename, or surname, would the test fail? Probably not because it's the email address that's important but because you mention it explicitly in your test, I can't be sure. Try looking at the Builder Pattern for building your test data and making it explicit what's really important.

OwnerDisplayName: Lewis Bassett

OwnerDisplayName: Wouter de Kort


答: If the tables that your user will define are not related through FKs, then you may want to consider dealing with such 'user defined tables' as spreadsheet files (or spreadsheets). You can present them as a grid and store them as csv files or convert each to a table. This approach would make life easier for you the developer and for the user since the user will be familiar with spreadsheets (I assume). In the .NET world there are many tools that gives you that spreadsheet look and feel.</p>

Title: For user defined data, is it better to use a table of tables or dynamically created tables?

Body:
In an application that allows users to define their own tables and columns (details of that are not the focus of this question, but imagine a tool that lets users create their own forms and automatically handles storage, just to get the idea) is it better to store each table and column they create in a "table" table and a "column" table, or to dynamically create tables and columns?

This "one table to rule them all" question is somewhat related, but in that case the "table" table is more clearly a bad idea.  In this case, if you don't go that route then all your queries will have to be dynamically generated.

Even though the argument "don't write yet another application designer tool for non-programmers, so you can keep adding features until you are basically having users develop in a crummy version of, say, Visual Studio, using your custom crummy language" is pretty reasonable, I've had a lot of projects with some version of the user defined tables requirement and this question is about how to implement it.  Whether to implement it is another question, but probably too specific to particular applications to be a good question here.


答:
Personally I try to do such a good job of defining the data needs that user defined fields and tables are not necessary. If you haven't defined 98% of what they would need, in most cases that means you haven't done your job. There are few genuine needs for that kind of flexibility (lab tests come to mind where new ones with very differnt needs come up all the time).

In the event I need them, I would first choose have a table with 5 or 6 basic columns plus the client_id to join to other stuff thqat the client could define as meaning something to them. Queries would use the generic name and you would set up some way to actually atach a label to the column. You might even have one client-defined table for each major function, so you could join to the Order table on orderid and get the client_defined fields. ANd have five or six fileds available for use for the users, etc.

At least this way the queries are written up front. The con is that you only get so many client defined field, but honestly in most situations no one will define any or they will only do one or two unless you did a horrible job o nthe orginal design. It is my experience that users love to say they want that flexibility,  but they hate to actually use it because it confuses them. Additonally every COTS program I ever used that was sold for it's flexibility was a nightmare to actually use and slower than slow, so I find that flexibility is vastly overrated.

My very last choice would be an EAV table as they are slow and difficult to query. If I really really needed that functionality because in fact many client defined things were not only possible but likely, I would consider using a nosql database for that part of the application. At least nosql are optimized to better use EAV structures. No reason they can't be combined with relational databases in the same application.


问:
In DVCS with production and development branches, whats the master/default branch?
If your following the standard DVCS methodology of having a production branch and a development branch, I'm really interested in what do you do with the default (mercurial) or master (git) branch?

Do you delete it (not recommended by several guides)?

Do you use it as production?

Do you use it as development?

Or do you leave it empty and have separate dev and production branches?

Note: I'm really interested in Mercurial specifically, but any other DVCS or just general rules would be ok

答:
as answered here in different ways, and in some other ServerFault question, you want to follow Mercurial guidelines here:

3 . The default branch

This is where development of new features occurs. [...]

(!) It is strongly recommended to do your primary development on the so-called 'default' branch, because it is the branch used by default in various commands such as clone.

The rest of article explains pretty well how to manage development Vs release branching.


问:
Are null references really a bad thing?
I've heard it said that the inclusion of null references in programming languages is the "billion dollar mistake".  But why?  Sure, they can cause NullReferenceExceptions, but so what?  Any element of the language can be a source of errors if used improperly.

And what's the alternative?  I suppose instead of saying this:

Customer c = Customer.GetByLastName("Goodman"); // returns null if not found
if (c != null)
{
    Console.WriteLine(c.FirstName + " " + c.LastName + " is awesome!");
}
else { Console.WriteLine("There was no customer named Goodman.  How lame!"); }
```

<p>You could say this:</p>

<pre class="lang-cs prettyprint-override"><code>if (Customer.ExistsWithLastName("Goodman"))
{
    Customer c = Customer.GetByLastName("Goodman") // throws error if not found
    Console.WriteLine(c.FirstName + " " + c.LastName + " is awesome!");
}
else { Console.WriteLine("There was no customer named Goodman.  How lame!"); }
</code>```

But how is that better?  Either way, if you forget to check that the customer exists, you get an exception.

I suppose that a CustomerNotFoundException is a bit easier to debug than a NullReferenceException by virtue of being more descriptive.  Is that all there is to it?

答:
And what's the alternative?

Optional types and pattern matching. Since I don't know C#, here is a piece of code in a fictional language called Scala# :-)

Customer.GetByLastName("Goodman")    // returns Option[Customer]
match
{
    case Some(customer) =>
    Console.WriteLine(customer.FirstName + " " + customer.LastName + " is awesome!");

    case None =>
    Console.WriteLine("There was no customer named Goodman.  How lame!");
}
```

Title: Are null references really a bad thing?


答:
I would clearly want to take advantage of the DBMS I'm using. I would map the data types I offer to DBMS data types and dynamically create real 1 to 1 tables in the DBMS (probably with a system of table name prefixes according to the foreseeable needs). Then, you can have simplified table definitions somewhere (another table, maybe), which describe the tables using the subset of data types and/or SQL you chose to use. These simplified definitions would be used to describe the tables to the frontend application, create your forms, format the query results, etc. I would think the bigger the subset, the best your application can get, but also  the more complicated. I'm really thinking this in term of an interface between what you offer to your users and the DBMS.

For performance and flexibility, I'd stay close to the DBMS. You probably don't really want to optimize the multi-table multi-select multi-constraint queries yourself and re-implement keys, constraints, etc. You can still provide apparently different features to the users. The hard part is thinking the architecture in a way that the code doesn't get too complicated to use/maintain and to do not decrease the subset of features too much.

In the end, it depends on the actual flexibility and performance requirements too.