答:
For unit tests, start with testing that it does what it is designed to do. That should be the very first case you write. If part of the design is "it should throw an exception if you pass in junk", test that too since that is part of the design.

Start with that. As you get experience with doing that most basic of testing you'll begin to learn whether or not that is sufficient, and start to see other aspects of your code that need testing.

Title: What should you test with unit tests?

Body:
I'm freshly out of college, and starting university somewhere next week. We've seen unit tests, but we kinda not used them much; and everyone talks about them, so I figured maybe I should do some.

The problem is, I don't know what to test. Should I test the common case? The edge case? How do I know that a function is adequately covered?

I always have the terrible feeling that while a test will prove that a function works for a certain case, it's utterly useless to prove that the function works, period.


问:
Does your company have a coding standard?
I recently saw that Microsoft released a coding standards document (All-In-One Code Framework Coding Standards) and it got me thinking...  The company that I work for has no formal coding standards at all.  There are only a few developers and we have been together long enough to have evolved into similar styles and its never been an issue.

Does the company you work for have a documented coding standards?  If no, why not?  Does having a standard make a difference?  Is it worth writing a standard from scratch or should you adopt another standard as your own (ie. make Microsoft's standards yours)?

答: You need one standard.  I've seen different standards in different corners of an application that had different leads that all wanted to do it "their way".  Perhaps the concept of "standard" was misunderstood.  Very insane.  And, the worst standards are generated by one person.  Doesn't matter who that person is, if one person alone develops the standard, it's almost assured to be a bad one.</p>

ContentLicense: CC BY-SA 2.5

ContentLicense: CC BY-SA 3.0


答:
I disagree with the "we are an X shop" so we format our code in all languages in the same way.

Personally I have found that most languages have different accepted styles.

I really cant stand when C programmers write Java code with C formatting. Not only does it not look like Java, but it fools them into thinking they can use other C-like practices in Java.

I think that if you have a standard it should be per language

Title: Does your company have a coding standard?

Body:
I recently saw that Microsoft released a coding standards document (All-In-One Code Framework Coding Standards) and it got me thinking...  The company that I work for has no formal coding standards at all.  There are only a few developers and we have been together long enough to have evolved into similar styles and its never been an issue.

Does the company you work for have a documented coding standards?  If no, why not?  Does having a standard make a difference?  Is it worth writing a standard from scratch or should you adopt another standard as your own (ie. make Microsoft's standards yours)?


问:
What is the benefit of not using Hungarian notation?
One of the things I struggle with is not using Hungarian notation.  I don't want to have to go to the variable definition just to see what type it is.  When a project gets extensive, it's nice to be able to look at a variable prefixed by 'bool' and know that it's looking for true/false instead of a 0/1 value.

I also do a lot of work in SQL Server.  I prefix my stored procedures with 'sp' and my tables with 'tbl', not to mention all of my variables in the database respectively.

I see everywhere that nobody really wants to use Hungarian notation, to the point where they avoid it.  My question is, what is the benefit of not using Hungarian notation, and why does the majority of developers avoid it like the plague?

答:
As usual in such a case, I will post an answer before I read answers from other participants.

I see three "bugs" in your vision:

1) If you want to know the type of a variable/parameter/attribute/column you can hover your mouse or click it and it will be displayed, in most modern IDE. I don't know what tools you're using, but last time I was forced to work in an environment that didn't provide this feature was in the 20th century, the language was COBOL, oops no it was Fortran, and my boss didn't understand why I left.

2/ Types may change during the cycle of development. A 32-bit integer may become a 64-bit integer at some point, for good reasons that had not be detected at the start of project. So, renaming intX into longX or leaving it with a name that points to the wrong type is bad karma.

3) What you're asking for is in fact a redundancy. Redundancy is not very good design pattern or habit. Even humans are reluctant to too much redundancy. Even humans are reluctant to too much redundancy.


问:
Why am I seeing more boolean naming conventions where "is" is used as the first word in the variable (eg, IsUserAdmin vs UserIsAdmin)?
I think everyone will agree that the following boolean variable/property names are standard:

UserIsAdmin

OrdersAreClosed

The important thing to note about boolean expressions is that they are stated and then evaluated as true or false.  User is admin.  False.  You get the point.

However, lately I have seen an increase in booleans being formed this way:

IsUserAdmin

AreOrdersClosed

Am I the only one who doesn't think this sounds absolutely ridiculous?  You're not asking "Is user admin?" and then waiting for a yes or no.  You're making a statement of "User is admin" and waiting for a true or false evaluation.

Microsoft has been doing this a lot lately, as well as the programming behind our Telerik web controls.  The thing is that I don't understand where this is coming from.  It never used to be popular, leaving me to wonder if it's just me who is noticing this or if this is a trend that is actually on the rise and, if so, what's the point?

答:
One of the reasons to do that is to help with auto-completion. For example, Windows Forms apps suffered from an inconsistent .NET Framework APIs where you would never know if you must include "is" or not. For example, to check if a checkbox is checked, you would have to write this.checkbox.Checked. In WPF, this was changed, and now you have to use this.checkbox.IsChecked which is easier to remember.

This being said, I don't see how AreOrdersClosed would be better than OrdersAreClosed. A possible explanation would be the same auto-completion: it's easier to find boolean properties and fields.

But this can be criticized:

If we start doing that, why not also using Hungarian notation? Since Hungarian notation must not be used in most languages used today, there is no reason to use it just for booleans.

Boolean variables can start by is, are or can. Three prefixes for the same type is too much if the only reason is a better auto-completion. If we want to be consistent, AreOrdersClosed must be IsOrdersClosed and CanResumeDownloads must be IsResumeDownloadsPossible, which is ugly.

Probably people start with the properties grammatically formed as Is+<Adjective>, and when it comes to the rare cases of <Noun>+Is+<Adjective>, they just put it as Is+<Noun>+<Adjective> to have a more uniform API.

Now, there are a few cases where "is" can be found between two words in a name of a variable, and I can't remember any valid case from .NET Framework. Actually, looking at your examples, I feel like there is a refactoring to do:

IsUserAdmin can be IsAdmin, as suggested by the comments,

AreOrdersClosed may also be renamed into AreClosed or something else depending on the context. For example if this is a value which indicates whether somebody cannot add new products to the cart, I would rather create a property IsClosed or IsFinished to the Cart or the Order.


答:
As @Joe said in his comment, it's redundent to put the name of the object into the method name.  Say you call:

```<code>if (user.isUserAdmin()) {
</code>```

That's rather silly, because the method name repeats the class name (probably something like User, or maybe a subclass called Admin).  Beginning with is or are or can makes sense in the immediate context of the object you're calling it on.

However, it makes less sense when you're getting information from an object about another object it's responsible for.  For example:

```<code>if (user.ordersAreValid()) {
</code>```

Then it will get a little fuzzy.  areOrdersValid makes sense because it's in the form of a question.  But on the other hand, ordersAreValid becomes a sentence when combined with a control structure like if or while (e.g. "if orders are valid").  I lean toward the latter, but it's might be more a matter of taste.

Title: Why am I seeing more boolean naming conventions where "is" is used as the first word in the variable (eg, IsUserAdmin vs UserIsAdmin)?

Body:
I think everyone will agree that the following boolean variable/property names are standard:

UserIsAdmin

OrdersAreClosed

The important thing to note about boolean expressions is that they are stated and then evaluated as true or false.  User is admin.  False.  You get the point.

However, lately I have seen an increase in booleans being formed this way:

IsUserAdmin

AreOrdersClosed

Am I the only one who doesn't think this sounds absolutely ridiculous?  You're not asking "Is user admin?" and then waiting for a yes or no.  You're making a statement of "User is admin" and waiting for a true or false evaluation.

Microsoft has been doing this a lot lately, as well as the programming behind our Telerik web controls.  The thing is that I don't understand where this is coming from.  It never used to be popular, leaving me to wonder if it's just me who is noticing this or if this is a trend that is actually on the rise and, if so, what's the point?

Body:
As @Joe said in his comment, it's redundent to put the name of the object into the method name.  Say you call:

if (user.isUserAdmin()) {

That's rather silly, because the method name repeats the class name (probably something like User, or maybe a subclass called Admin).  Beginning with is or are or can makes sense in the immediate context of the object you're calling it on.

However, it makes less sense when you're getting information from an object about another object it's responsible for.  For example:

if (user.ordersAreValid()) {

Then it will get a little fuzzy.  areOrdersValid makes sense because it's in the form of a question.  But on the other hand, ordersAreValid becomes a sentence when combined with a control structure like if or while (e.g. "if orders are valid").  I lean toward the latter, but it's might be more a matter of taste.


问:
Should I stick with or abandon Python to deal with concurrency?
I have a 10K LOC project written in Django with quite a deal of Celery (RabbitMQ) for asynchronicity and background jobs where needed, and have come to the conclusion that parts of the system would benefit from being rewritten in something other than Django for better concurrency. Reasons include:

Signals handling and mutable objects. Especially when one signal triggers another, handling them in Django using the ORM can be surprising when instances change or disappear. I want to use some messaging approach where the data passed along doesn't change in a handler (Clojure's copy-on-write approach seems nice, if I got it right).

Parts of the system are not web-based, and need better support for performing tasks concurrently. For example, the system reads NFC tags, and when one is read an LED goes on for a few seconds (Celery task), a sound is played (other Celery task), and the database is queried (other task). This is implemented as a Django management command, but Django and its ORM being synchronous by nature and sharing memory is limiting (we are thinking of adding more NFC readers, and I don't think that the Django+Celery approach will work any longer, I'd like to see better message-passing capabilities).

What are the pros and cons of using something like Twisted or Tornado compared with going for a language such as Erlang or Clojure? I am interested in practical benefits and detriments.

How did you come to the conclusion that some parts of the system would fare better in another language? Are you suffering performance problems? How severe are those problems? If it can be faster, is it essential that it is faster?

Example 1: Django at work outside an HTTP request:

An NFC tag is read.

The database (and possibly LDAP) is queried, and we want to do something when data becomes available (red or green light, play a sound). This blocks using the Django ORM, but as long as there are Celery workers available it doesn't matter. May be a problem with more stations.

Example 2: “message-passing” using Django signals:

A post_delete event is  handled, other objects may be altered or deleted because of this.

At the end, notifications should be sent to users. Here, it would be nice if arguments passed to the notification handler were copies of deleted or to-be-deleted objects and guaranteed not to change in the handler. (It could be done manually simply by not passing objects managed by the ORM to handlers, of course.)

答:
I did some very sophisticated highly scalable development for a major US ISP. We did some serious tranasaction numbers using a Twisted server, and it was a nightmare of complexity to get Python / Twisted to scale on anything that was CPU bound. I/O bound is not an issue, but CPU bound was impossible. We could put together systems quickly, but getting them to scale to millions of concurrent users was a nightmare of configuration and complexity if the were bound by CPU.

I wrote up a blog post about it, Python/Twisted VS Erlang/OTP.

TLDR; Erlang won.

OwnerDisplayName: Simon Pantzare


答:
It's just a way of narrowing down a search in auto complete/Intellisense. When you start writing a conditional, typing in "Is" is a good way to find what you're looking for without having to scroll through everything, when you don't know the name of the member you're looking for.

The only reason we do this for "Is" and nothing else is because we know that boolean members are often going to be used in the context of a branch or loop. It's no coincidence that booleans are among the few types that most languages have so many special keywords and structures to recognize.

I'm sure we'd find more things to notate with similar prefixes if we could figure out what the appropriate contexts would be.


答:
I believe being in dire need of hungarian is a symptom.

A symptom of too many global variables ...or of having functions too long to be mantainable.

If your variable definition isn't in sight, usually, you've got trouble.

And if your functions don't follow some memorable convention, there again, big trouble.

That's... pretty much the reason why many workplaces dash it out, I suppose.

It originated on languages that needed it.

On times of global variables bonanza. (for lack of alternatives)

It served us well.

The only real use we have for it today is the Joel Spolsky one.

To track some particular attributes of the variable, like its safety.

(e.g. “Does variable safeFoobar has a green light to be injected into a SQL query?

— As it is called safe, yes”)

Some other answers talked about editor functionalities that helped seeing the type of a variable as you hover on it. In my view, those too are kind of problematic for code sanity. I believe they where only meant for refactoring, as many other features too, (like function folding) and should not be used on new code.

Title: What is the benefit of not using Hungarian notation?

Body:
One of the things I struggle with is not using Hungarian notation.  I don't want to have to go to the variable definition just to see what type it is.  When a project gets extensive, it's nice to be able to look at a variable prefixed by 'bool' and know that it's looking for true/false instead of a 0/1 value.

I also do a lot of work in SQL Server.  I prefix my stored procedures with 'sp' and my tables with 'tbl', not to mention all of my variables in the database respectively.

I see everywhere that nobody really wants to use Hungarian notation, to the point where they avoid it.  My question is, what is the benefit of not using Hungarian notation, and why does the majority of developers avoid it like the plague?


问:
What is a good workflow for a C++ beginner?
I desire to become a more serious scientific C++ programmer.  To do so, I need  a consistent style of workflow (e.g., coding, test-driven development, etc.).  My question is simply what sort of workflow should I consider?  I am familiar with Linux and Mac, and prefer to use free tools like cppcheck, valgrind, g++, etc.  I prefer to use Qt and Boost within my programming toolbox, and I am considering using mock objects (either Google Mock or MockPP) within the TDD.  I typically use vim for my editor.

In essence, should I do something like the following:

TDD -> code -> cppcheck -> valgrind -> debug -> repeat until ready to
  use profilers and coverage mechanisms

or, should I pursue some other way?  I realize that the opinions will vary, and I also understand that I must first take the time to think through the process and document my thoughts whether written or UML before coding, and I also know that I should document the code as I step write the code.

Any and all thoughts will be appreciated.

答:
You forgot something ... thinking. Programmers don't do enough thinking.

Think -> Design -> TDD -> code -> Think again -> cppcheck -> valgrind -> debug -> repeat until ready to use profilers and coverage mechanisms -> Think some more

OwnerDisplayName: Tim


问:
Key phrases showing benefits performing certified software testing for "your" company?
I am wondering what phrases that would have the most impact when approaching a business, to inform them why they should test their software.

Obviously you have easy ones; reduce costs/risk, improves stability/reliability/usability. But these are just words, how would you wrap them into something concrete that even people living in their own world, could see the potential benefit of software testing. I'm looking for shared experience. And how would you as a developer like to be approached by a software tester?

PS: Help! I'm not sure how to ask this question properly!

答:
Bugs that disrupt the line-of-business can easily rake in
  million-dollar losses per downtime day.

Bugs that compromise data integrity can cause irreparable damage to
  business goodwill.

Bugs that compromise security can allow targeted individuals to
  commandeer certain corporate assets. They could also choose to
  compromise data integrity along the way.

But most of the bugs are just nuisance, like flies. They just slow
  down users a tiny little bit. One thousandth of their time - which accumulates.

For each bug that cause massive disruption, there are 10x more bugs
  each can cause minor disruptions.

For each bug that cause minor disruptions, there are 10x more bugs
  that lose data silently for months.

For each bug that lose data silently, there are 10x more bugs each
  annoying users and slowing down things a little bit.

(The effects on this list are, as you have guessed, accumulative.)

If you have ever been impacted by a show-stopper bug one day, take
  note.

Not that I approve of the quoted text.

High-impact bugs are like freak accidents. Thousands of hours of manual testing will reveal and fix lots of little UI bugs, but it has to be combined with careful coding and code-level testing etc. to reduce the occurence of rare but high-impact freak accidents.

Can a certified software tester ensure that sufficient resources are devoted to each and every level of testing? Can a certified software tester deeply understands every level of testing (despite passing the certification exam) and able to spot out glaring inadequacies in test implementation (administration) - not of the paperwork kind? Can a certified software tester withstand managerial pressure to "make a trade-off" between release date and testing?

If you have a track record of success, it will speak for you. kudos.

This is not a rant against certificates. In fact, it is a great communication tool between the test lead and the manager, if they are both certified. This basically eliminates miscommunications mishaps.

OwnerDisplayName: CS


问:
Are enforced Professional Development Plans useful?
Many companies, especially larger ones have mandatory professional development plans for their employees. Employees and managers set out a personalized professional development plan and follow up on the progress every so often.

As a developer, do you find such PDPs useful, do you follow through with your commitments?

As a manager, do you think such PDPs bring value to the company and improve the overall quality of the employees?

It seems that good developers will continue to educate themselves and strive to be better regardless of companies' procedures while bad ones won't.

Are there benefits of having PDPs or is it just something managers feel they need to do?

答:
This is a great idea, although hardly implmented (IME) - I always find it amusing that we are suppose to know all new technologies the moment they come out regardless if the corporation is using them or not. I guess we are individually motivated to keep up on the learning curve so we getting better raises, bigger bonuses, not getting fired.

But if management want to move all applications to WPF in the next year, sending the developers out for WPF classes just makes all kinds of sense.


问:
Copyright assignment on open source projects
Some time ago I wrote a BlackBerry application. I find that I now want to release it under an open source license. I am strongly considering the GPL v3 license. All the code is mine; there are no third-party libraries (with the exception, of course, of the all the standard BlackBerry/Java libraries that I am "linked" to).

This is the first open source project that I will be maintaining or starting. I find myself a bit lost about how to handle contributions. It seems to be more-or-less standard to expect some kind of copyright assignment from contributors so that the project has a unified copyright. I could either assign all copyrights to the FSF or assign all copyrights to myself.

How should I handle this? The most important features of whatever implementation I use are:

Protects me from being sued for any unintentional violations of the GPL in my own code

Protects others' contributions from being misused by me if I become evil

Encourage others' contributions to the project (or at least does not discourage such contributions)

For assigning all copyrights to myself, the most promising strategy for copyright assignment seems to be one based on Oracle's contributor agreement, located here: http://openjdk.java.net/legal/oca.pdf. However, I feel like expecting any contributors to sign a legal document, providing me with fairly personal information is asking for a lot, especially given that my project is very small.

Should I proceed with requiring contributors to sign a document similar to Oracle's agreement? Should I just accept contributions and cross my fingers that I won't have any trouble down the road? Is there another strategy that I should employ?

答:
I would not recommend GPLv3 if you wanted contributions back. If we take a pragmatic look at the license it discourages any commercial company from using your product. And commercial companies have the time and money to put into something that will help them in the long run. Whether this is a legitimate reason for companies to be discouraged doesn't mean there isn't a stigma with GPL . I don't see many (or any) Apache v2 lawyers floating around but i've seen my far share of GPL ones.

That being said, it is not unreasonable for you to have any contributors "sign" a page stating they release their contributions under the same license you are using. Many OSS projects do something similar.


问:
Modifying an open source application
What is the general workflow when I want to add a feature to an open source application I didn't originally write? How do I get to know the code? How do I find the spot that needs to be changed or added? How do I actually make the change without breaking anything else? How do I test that everything is still working?

What are the general guidelines on such a project?

答:
Typically.

If it was a random OS project, you would most likely fix minor bugs here and there.

Eventually you would submit a a bunch of changes, as a "patch".

Usually you would get commit rights if your stuff is good.

I'm talking generally and as vague and nonspecific as possible due to the question

OwnerDisplayName: Dani

Title: Modifying an open source application


问:
Does agile development need a framework in place first?
We are planning a new project and we want to go with a services oriented architecture.
Everyone agrees that this is the way to go but how does this fit in with starting the development using agile methodologies?

I do not have any experience with SOA, although I have some experience with TDD (test driven development). The team I work with thinks that we need a framework in place before we can even start looking at developers doing work with TDD. In others we spend weeks getting a framework in place (a SOA framework) and then the developers can build on this framework to do their work.

From a TDD point of view, I would have expected each developer to just flesh out the functionality using MOCKs etc whilst the framework is being developed (although I have no idea what a framework in SOA would involve). Then we could plug in the actual framework calls when we need to. Not sure if this right but it feels the correct way.

答: You should definitely not plan to write a framework.  You could plan to use one that is already written, (e.g. JEE with Jersey or many others), but attempting to write a proprietary framework to meet some imagined requirements is at best break-even.  At worst it becomes a multi-million dollar mistake.  The developers who want to write a framework are just postponing the real work of meeting the needs of your customers.  If you follow test-driven development and continuously refactor, the exact framework you need will fall out as you refactor.


答:
There's some protocol, everybody more or less desumes it with time, but here it is, unrolled.

You download the distributed source.

You start navigating the code by yourself a little

If it's a compiled program, you learn now how to compile it.

If you fail compiling it, you report to the author / mailing list and ask directions

If you don't really understand a thing about the code...

Well, no, you don't ask them nigh.

You drop that, as you're probably not up to par and cannot be of any real help.

You submit a feature if the author(s) accepts feature requests.

Else

You find the spot you want to change.

If you wonder about some minor detail, you ask the author / mailing list , and explain your intentions.

You cd to the main directory of the distribution (the top one coming out of the untarring/unzipping)

You diff -ur . > mypatch.path

You send mypatch.patch to the author explaining what you did, why you did it, and (as you're already there) you state clearly that you waiver the rights on the patch to them.

if the author(s) doesn't like your contribution

you check if there's a way to release your modification as a plugin of some kind

in that case, now you're on your way to become a plugin mantainer.

else

you flame about the situation on your blog and release the patch there, free to download and try with your explanation and your rants,

you haunt now and then the bug system / mailing list trying to buy support for your patch. Avoid getting banned.

in none of these cases you fork the code, as it's a very tiring and unrewarding process you will hardly be able to keep up with time: that will leave users sad and confused. Forks shoud really only happen when a big corporation is trying to bully his decisions on a piece of OSS.

else

you receive further instructions from that author(s)

On the side: there is a recent alternative to the diff -ur . patch and is the github way.

You "fork" their code on github under your name,

(now you have a copy of their code on your account)

connect your git to that personal copy of yours,

make your modifications on that, check them in,

and tell the main author(s) to look at your github project.

If they like it, they will syncronize.

Otherwise, you can link your "gitfork" on your blog.

Title: Modifying an open source application

Body:
What is the general workflow when I want to add a feature to an open source application I didn't originally write? How do I get to know the code? How do I find the spot that needs to be changed or added? How do I actually make the change without breaking anything else? How do I test that everything is still working?

What are the general guidelines on such a project?


问:
Pointless Code In Your Source
I've heard stories of this from senior coders and I've seen some of it myself. It seems that there are more than a few instances of programmers writing pointless code. I will see things like:

Method or function calls that do nothing of value.

Redundant checks done in a separate class file, object or method.

if statements that always evaluate to true.

Threads that spin off and do nothing of note.

Just to name a few. I've been told that this is because programmers want to intentionally make the code confusing to raise their own worth to the organization or make sure of repeat business in the case of contractual or outsourced work.

My question is. Has anyone else seen code like this? What was your conclusion was to why that code was there?

If anyone has written code like this, can you share why?

答:
I object to if true statements to be indiscriminately classified as "pointless code".

There is a legitimate case for using an if (1) { ... } block in C code that either wants to be compatible with the C standard that insisted on variable definitions to be at the start of a function, or just wants local variables to be defined as locally as possible.

```<code>switch (i) {
    case 23:
        if (1) {
            /* I can declare a local var here! */
        }
        break;
}
</code>```

Title: Pointless Code In Your Source

Body:
I object to if true statements to be indiscriminately classified as "pointless code".

There is a legitimate case for using an if (1) { ... } block in C code that either wants to be compatible with the C standard that insisted on variable definitions to be at the start of a function, or just wants local variables to be defined as locally as possible.

switch (i) {
    case 23:
        if (1) {
            /* I can declare a local var here! */
        }
        break;
}


问:
How to turn truth table into smallest possible if / else block
How can I take a truth table and turn it into a compacted if block?

For instance, let's say I have this truth table where A and B are conditions and x, y and z are possible actions:

```<code>A B | x y z
-------------
0 0 | 0 0 1
0 1 | 0 0 1
1 0 | 0 1 0
1 1 | 1 0 0
</code>```

This could transform into below if block:

if(A)
{
    if(B)
    {
        do(x)
    }
    else
    {
        do(y)
    }
}
else
{
    do(z)
}
```

This is an easy sample, but I frequently have several conditions that combined in different ways should produce different outputs and it gets hard to figure out the most compacted and elegant way to represent their logic in an if block.

答:
Here is your library :)  And you dont need to pass full K-table, only fields that you are interested in :)
It assumes that its AND operator in truth table.
If you want to use more operators, you should be able to rewrite it.
You can have any number of arguments.
Written in python, and tested.

def x():
    print "xxxx"

def y():
    print "yyyyy"

def z(): #this is default function
    print "zzzzz"

def A():
    return 3 == 1

def B():
    return 2 == 2

def insert(statements,function):
    rows.append({ "statements":statements, "function":function })

def execute():
    for row in rows:
        print "==============="
        flag = 1

        for index, val in enumerate(row["statements"]):
            #for first pass of lopp, index is 0, for second its 1....
            #if any function returns result different than one in our row,
            # we wont execute funtion of that row (mark row as not executable)
            if funcs[index]() != val:
                flag = 0

        if flag == 1:
            #we execute function
            row["function"]()
        else: z() #we call default function

funcs = [A,B]  #so we can access functions by index key
rows = []

insert( (0,0), y)
insert( (0,1), y)
insert( (1,0), x)
insert( (1,1), x)
insert( (0,1), x)

execute()
```


答:
As a developer, I've found them to be a major pain to select where I want to improve, what I'll do it to get there and what result this is supposed to have to make it worthwhile.  While I can see the potential of it being ultimately good, there is something to be said for the growing pain of learning how to do these and seeing what is and isn't acceptable to the organization as such plans often require some form of managerial approval.

Course I should note that for most of my career I didn't have these until my current position and this is part of the formalization that the company is going through as it matures.

Title: Are enforced Professional Development Plans useful?

Body:
Many companies, especially larger ones have mandatory professional development plans for their employees. Employees and managers set out a personalized professional development plan and follow up on the progress every so often.

As a developer, do you find such PDPs useful, do you follow through with your commitments?

As a manager, do you think such PDPs bring value to the company and improve the overall quality of the employees?

It seems that good developers will continue to educate themselves and strive to be better regardless of companies' procedures while bad ones won't.

Are there benefits of having PDPs or is it just something managers feel they need to do?


答:
It happens. Quite often actually.

Sometimes these coding dead-ends are more like old goat-trails which have fallen into disrepair when a more efficient/modern/speedy freeway has been installed around them.

On other occasions (and I am probably guilty of this), they are foundations for extension of the software when a briefed, but unconfirmed set of features/functions are requested. (Sometimes putting in a bit of work in the initial build providing handles and the like for later work which you plan to "bolt-on" can make life easier, when it happens, or more difficult/messy if the further work doesn't eventuate.)

And, alot of it is directly due to the old "If it ain't broke, don't fit it." Sometimes tearing out code you do not understand, or believe is unused, can cause the programming version of "The Butterfly Effect". Have had that happen once or twice too.

Title: Pointless Code In Your Source

Body:
I've heard stories of this from senior coders and I've seen some of it myself. It seems that there are more than a few instances of programmers writing pointless code. I will see things like:

Method or function calls that do nothing of value.

Redundant checks done in a separate class file, object or method.

if statements that always evaluate to true.

Threads that spin off and do nothing of note.

Just to name a few. I've been told that this is because programmers want to intentionally make the code confusing to raise their own worth to the organization or make sure of repeat business in the case of contractual or outsourced work.

My question is. Has anyone else seen code like this? What was your conclusion was to why that code was there?

If anyone has written code like this, can you share why?


答:
It can help people, it can also really helps with tools:

If you want to be able to use any sort of automatic code formatting you really need to standardize the rules it is going to use, else you will constantly be getting a lot of meaningless formatting changes cluttering up your diffs.

Default rules sets for static analysis tools may well check for a specific naming style, and its probably easier all round to conform to that then write a bunch of new rules. (unless you are going to just turn the rule off altogether)

lastly its good to standardize anything which needs to be consulted with someone outside your team. i.e. you probably want a standard copyright notice in your headers as you don't want to be running every new file you write past your companies legal team, and you certainly want to get the names of any public API right first time


问:
When would polling for events be better than using observer pattern?
Are there scenarios where polling for events would be better than using the observer pattern? I have a fear of using polling and would only start using it if someone gave me a good scenario. All I can think of is how the observer pattern is better than polling. Conside this scenario:

You are programming a car simulator. The car is an object. As soon as the car turns on, you
  want to play a "vroom  vroom" sound clip.

You can model this in two ways:

Polling: Poll the car object every second to see if it's on. When it's on, play the sound clip.

Observer pattern: Make the car the Subject of the observer pattern. Have it publish the "on" event to all observers when itself turns on. Create a new sound object that listens to the car. Have it implement the "on" callback, which plays the sound clip.

In this case, I think the observer pattern wins. Firstly, polling is more processor intensive. Secondly, the sound clip does not immediately fire when the car turns on. There  can be up to a 1 second gap because of the polling period.

答:
Polling has some disadvantages, you basically stated them already in your question.

However, it can be a better solution, when you want to truly decouple the observable from any observers. But sometimes it might be better to use an observable wrapper for the object to be observed in such cases.

I'd only use polling when the observable can't be observed with object interactions, which is frequently the case when querying databases for example, where you can't have callbacks. Another issue might be multithreading, where it's often times safer to poll and process messages rather than invoking objects directly, to avoid concurrency issues.


问:
Effectiveness of "what is your greatest strength/weakness" interview questions
As someone who is now finding himself on the other end of the interview table, I'm wondering how useful these questions are from an employer's perspective. Some of my coworkers think they're good because you can see "how they respond," but I'm not convinced it tells you anything useful, for several reasons:

It's not a very comfortable question and can lead people to twist their answers, even if not on purpose

People may not fully know their greatest strengths or weaknesses (i.e. judge them by their peers)

Explaining what a strength is isn't as good as showing it

I still don't know any more about the candidate afterwards

The rationale of my coworkers is that it can help weed out people that give ridiculous responses, like one guy that said his greatest strength was "his intellect" or people that try to turn the weakness question into a strength like "I work too hard." But I think there's more effective ways to determine such things. If you want to see if someone's smart, ask them technical questions. If you want to see if someone is productive, look at their work history. If you want to see how someone reacts under stress or change, ask them how they've dealt with it and ask for concrete examples.

What are people's thoughts on these questions, from the perspective of an interviewer? What do they really tell you about a candidate, and what are better alternatives? How do I convince my colleagues of this?

答:
The value of that question seems obvious to me.

Someone that knows his strength and weaknesses will be a lot more efficient that the one that doesn't know what he can do well and what he shouldn't do (or improve)

In martial arts, this is one of the first things you have to learn. Because it determines how your attack and defense strategy will be.

I do think that it's the same in life in general, including daily work.


答:
Simplicity -- the art of maximizing the amount of work not done -- is
  essential.

Don't assume anything about what frameworks you will be using. Focus on satisfying your clients/users needs as quickly and professional as possible. Add frameworks when you have an actual, real, measurable need for it.

Title: Does agile development need a framework in place first?

Body:
We are planning a new project and we want to go with a services oriented architecture.
Everyone agrees that this is the way to go but how does this fit in with starting the development using agile methodologies?

I do not have any experience with SOA, although I have some experience with TDD (test driven development). The team I work with thinks that we need a framework in place before we can even start looking at developers doing work with TDD. In others we spend weeks getting a framework in place (a SOA framework) and then the developers can build on this framework to do their work.

From a TDD point of view, I would have expected each developer to just flesh out the functionality using MOCKs etc whilst the framework is being developed (although I have no idea what a framework in SOA would involve). Then we could plug in the actual framework calls when we need to. Not sure if this right but it feels the correct way.


答:
Imagine you want to get notified about every engine cycle, e.g. to display an RPM measurement to the driver.

Observer pattern: The engine publishes an "engine cycle" event to all observers for each cycle. Create a listener that counts events and updates the RPM display.

Polling: The RPM display asks the engine at regular intervals for an engine cycle counter, and updates the RPM display accordingly.

In this case, the observer pattern would probably loose: the engine cycle is a high-frequency, high-priority process, you don't want to delay or stall that process just to update a display. You also don't want to thrash the thread pool with engine cycle events.

PS:
I also use the polling pattern frequently in distributed programming:

Observer pattern: Process A sends a message to process B that says "each time an event E occurs, send a message to Process A".

Polling pattern: Process A regularly sends a message to process B that says "if you event E occured since the last time I've polled, send me a message now".

The polling pattern produces a bit more network load. But the observer pattern has downsides, too:

If process A crashes, it will never unsubscribe, and process B will try to send notifications to it for all eternity, unless it can reliably detect remote process failures (not an easy thing to do)

If event E is very frequent and/or the notifications carry a lot of data, then process A might get more event notifications than it can handle. With the polling pattern, it can just throttle the polling.

In the observer pattern, high load can cause "ripples" through the whole system. If you use blocking sockets, these ripples can go both ways.

Title: When would polling for events be better than using observer pattern?

Body:
Are there scenarios where polling for events would be better than using the observer pattern? I have a fear of using polling and would only start using it if someone gave me a good scenario. All I can think of is how the observer pattern is better than polling. Conside this scenario:

You are programming a car simulator. The car is an object. As soon as the car turns on, you
  want to play a "vroom  vroom" sound clip.

You can model this in two ways:

Polling: Poll the car object every second to see if it's on. When it's on, play the sound clip.

Observer pattern: Make the car the Subject of the observer pattern. Have it publish the "on" event to all observers when itself turns on. Create a new sound object that listens to the car. Have it implement the "on" callback, which plays the sound clip.

In this case, I think the observer pattern wins. Firstly, polling is more processor intensive. Secondly, the sound clip does not immediately fire when the car turns on. There  can be up to a 1 second gap because of the polling period.


问:
Is this agile? Scrum? How to improve agility?
Is this agile?  Scrum?  Any suggestions on how this can be made more agile under the circumstances?  Which points are positives and which can be improved?

The product is developed for a customer who will re-sell it while paying us royalty.

The team does not get to talk directly to the end user.  Only to the reseller.

A product requirements document was created before starting development.

The requirements are rigid and do not change.

A delivery schedule was agreed on with milestones such as "alpha", "beta" etc. and features/times attached to those milestones.

All developers on the Scrum team report to the product owner, a software manager.

Testers on the team report to a QA manager.

The product owner has directed the team towards certain high risk technical tasks.  The output of those tasks is not usable by the end user but rather some technology/code that will eventually be used in the product.

The product owner has created a backlog based on the requirements.

The product owner is unable to answer some questions regarding the product.  He refers to others or to the documented requirements.

The team goes through the motions of Scrum.  Daily Scrum, Sprint Planning, Retrospective etc.  There is a ScrumMaster.

Every sprint the product owner and management decide what backlog items the team works on.

There is a burndown chart.  Scrum board with stories and tasks.  The estimates on those come from the team.

The team sits in an open floor "bull pen" shared with other teams, all visible and audible.  There is cross-team noise and there is foot traffic around the team area.

The team may be required to attend various meetings not directly related to the goals of the sprint.

There are pressures to select certain technical solutions.  Some tools and processes are mandated.

答:
Looks like a mini-waterfall rather than fully agile approach

This may be splitting hairs

Although on the surface it look like an agile approach I believe it may have more in common with "mini-waterfall".  Mini-Waterfall projects assume that all (or most) requirements can be understood before designs can be created, and that coding follows each iteration or "phase".

This requires a high degree of certainty regarding the requirements. Agile assumes that all of the requirements are not knowable until a working version of the system is created.

Time boxing vs Feature fixing

Agile tends to be "time boxed" (using the Iron Triangle metaphor of time/features/cost).
Waterfall tends to be more "feature fixed."

Problems with delivering mini-waterfall

The problem with delivering "mini-waterfall" to the client is that generally they don't get what they want.  After they take a look at the working software, they realize only too late that what they said they put in the requirements document wasn't what they meant to say.

Client may change requirements once they've seen working software

This happens all the time, be prepared to make changes in your later phases to cater for changes in requirements.  This may change how you approach designing your framework if you're expecting changes in your requirements.

Some advice to make this more agile

http://simpleprogrammer.com/2010/04/07/dont-go-chasing-waterfalls-mini-waterfall-vs-agile/

If you want to stop thinking mini-waterfall and start thinking Agile…

stop thinking about building software serially, and start thinking
  about doing it in parallel.  Stop thinking in terms of:

```<code>* Step 1: Get the requirements
* Step 2: Design the solution
* Step 3: Develop the solution
* Step 4: Test
</code>```

Start thinking in terms of:

```<code>* Step 1: Figure out the first thing the user wants
* Step 2: Build a small piece, making sure it is right
* Step 3: Check with the user to see how to make it better
* Step 4: Continue until user is happy
</code>```

Body:
Looks like a mini-waterfall rather than fully agile approach

This may be splitting hairs

Although on the surface it look like an agile approach I believe it may have more in common with "mini-waterfall".  Mini-Waterfall projects assume that all (or most) requirements can be understood before designs can be created, and that coding follows each iteration or "phase".

This requires a high degree of certainty regarding the requirements. Agile assumes that all of the requirements are not knowable until a working version of the system is created.

Time boxing vs Feature fixing

Agile tends to be "time boxed" (using the Iron Triangle metaphor of time/features/cost).
Waterfall tends to be more "feature fixed."

Problems with delivering mini-waterfall

The problem with delivering "mini-waterfall" to the client is that generally they don't get what they want.  After they take a look at the working software, they realize only too late that what they said they put in the requirements document wasn't what they meant to say.

Client may change requirements once they've seen working software

This happens all the time, be prepared to make changes in your later phases to cater for changes in requirements.  This may change how you approach designing your framework if you're expecting changes in your requirements.

Some advice to make this more agile

http://simpleprogrammer.com/2010/04/07/dont-go-chasing-waterfalls-mini-waterfall-vs-agile/

If you want to stop thinking mini-waterfall and start thinking Agile…

stop thinking about building software serially, and start thinking
  about doing it in parallel.  Stop thinking in terms of:

* Step 1: Get the requirements
* Step 2: Design the solution
* Step 3: Develop the solution
* Step 4: Test

Start thinking in terms of:

* Step 1: Figure out the first thing the user wants
* Step 2: Build a small piece, making sure it is right
* Step 3: Check with the user to see how to make it better
* Step 4: Continue until user is happy


答:
It looks like you took some fancy items from agile development, put them to waterfall process and now you call it agile.

The product is developed for a customer who will re-sell it while
  paying us royalty.

This is OK.

The team does not get to talk directly to the end user. Only to
  the reseller.

This is OK. Product owner talk to reseller and collects requirements.

A product requirements document was created before starting
  development.

This is not OK. I haven't seen the project where definite requirement set can be defined upfront. Change your product requirements document to product vision (short) with some initial set of requirements which are subject to change.

The requirements are rigid and do not change.

This is not OK and you will see in the future that it is also not true.

A delivery schedule was agreed on with milestones such as "alpha",
  "beta" etc. and features/times attached to those milestones.

This is not OK. The real schedule will be visible from the team progress. You can make general milestones but assigning exact set of features which will be implemented in these milestones is not agile. This can change during development.

All developers on the Scrum team report to the product owner, a
  software manager.

This is not OK. I would not say that developers report to product owner. Scrum process keeps visibility of the process but developers do not report anything except regular meetings. It is responsibility of product owner to be in contact with a team and as active participant see the progress himself.

Testers on the team report to a QA manager.

This is not OK. Testers should be part of development team because user story is not done until it is tested (there should be automated test to validate acceptance criteria). There can be separate QA but it is additional level of complex testing and it is usually done on customer side (but doesn't have to be) to validate that SW does what customer expects and the feedback is collected as new backlog items or bugs to existing completed backlog items.

Separating complete QA outside of development team leads to breaking the whole purpose of definition of done. Some QA must be part of the team and that part is not related to any QA manager - that part is doing commitment with development team.

The product owner has directed the team towards certain high risk
  technical tasks. The output of those tasks is not usable by the end
  user but rather some technology/code that will eventually be used in
  the product.

This happens in every project but it should be part of some product backlog item targeting end user. It can be included directly in backlog item implemented in current iteration or it can be included as a spike (proof-of-concept) to clarify complexity of some backlog item which should be implemented in the future.

The product owner has created a backlog based on the requirements.

This is a must.

The product owner is unable to answer some questions regarding the
  product. He refers to others or to the documented requirements.

This is not OK. It is job of the product owner to know answers. He has a responsibility and he must do decisions. If he doesn't know answer he must find it asap.

The team goes through the motions of Scrum. Daily Scrum, Sprint
  Planning, Retrospective etc. There is a ScrumMaster.

This is OK but it doesn't mean that team is doing Scrum.

Every sprint the product owner and management decide what backlog
  items the team works on.

This is definitely not OK. The product owner and management can make priorities but commitment (selection of most prioritized items) is teams responsibility.

There is a burndown chart. Scrum board with stories and tasks. The
  estimates on those come from the team.

This is OK.

The team sits in an open floor "bull pen" shared with other teams,
  all visible and audible. There is cross-team noise and there is foot
  traffic around the team area.

It is Scrum master's responsibility to make end of this if team feels like it reduces their productivity.

The team may be required to attend various meetings not directly
  related to the goals of the sprint.

It is OK, the time wasted on these meetings will result in smaller commitment (team will do less real work). It is up to Scrum master / management to reduce these meetings to increase team's velocity.

There are pressures to select certain technical solutions. Some
  tools and processes are mandated.

This is partially OK. There can be non-functional requirements for tools and architecture and there can be defined processes but still final implementation is up to the team.

Title: Is this agile? Scrum? How to improve agility?

Body:
Is this agile?  Scrum?  Any suggestions on how this can be made more agile under the circumstances?  Which points are positives and which can be improved?

The product is developed for a customer who will re-sell it while paying us royalty.

The team does not get to talk directly to the end user.  Only to the reseller.

A product requirements document was created before starting development.

The requirements are rigid and do not change.

A delivery schedule was agreed on with milestones such as "alpha", "beta" etc. and features/times attached to those milestones.

All developers on the Scrum team report to the product owner, a software manager.

Testers on the team report to a QA manager.

The product owner has directed the team towards certain high risk technical tasks.  The output of those tasks is not usable by the end user but rather some technology/code that will eventually be used in the product.

The product owner has created a backlog based on the requirements.

The product owner is unable to answer some questions regarding the product.  He refers to others or to the documented requirements.

The team goes through the motions of Scrum.  Daily Scrum, Sprint Planning, Retrospective etc.  There is a ScrumMaster.

Every sprint the product owner and management decide what backlog items the team works on.

There is a burndown chart.  Scrum board with stories and tasks.  The estimates on those come from the team.

The team sits in an open floor "bull pen" shared with other teams, all visible and audible.  There is cross-team noise and there is foot traffic around the team area.

The team may be required to attend various meetings not directly related to the goals of the sprint.

There are pressures to select certain technical solutions.  Some tools and processes are mandated.


问:
Is it possible to make something open-source without publishing it?
I've been working on some piece of software while being "employed" by company A. I now want to continue working on the same software while being employed by company B. Company B wants the software to become open-source to prevent any future legal issues between company A and them. I will consult company A's lawyer to make sure it's fine by them, but I suspect it will be alright as company A is actually a public university which looks favorably on industry connections.

However, I am concerned by potential competitors getting access to that code before we make its results public. Is it possible to make the software open-source without sharing it with anyone but company B (neither in binary nor source form), or do I have to publish the software the minute it is made open-source or shared with anyone?

If the answer depends on the specific open-source license used, please be kind and provide details about the differences.

答:
Which license do you plan to use ? Because the terms may vary.
 I will copy/paste an extract from the GPL faq I used in another question (relevant if you decide to use this license) :

Does the GPL require that source code of modified versions be posted to the public?

The GPL does not require you to release your modified version, or
  any part of it. You are free to make modifications and use them
  privately, without ever releasing them. This applies to organizations
  (including companies), too; an organization can make a modified
  version and use it internally without ever releasing it outside the
  organization.

But if you release the modified version to the public in some way,
  the GPL requires you to make the modified source code available to the
  program's users, under the GPL.

Thus, the GPL gives permission to release the modified program in
  certain ways, and not in other ways; but the decision of whether to
  release it is up to you.

If you choose the GPL, it means you just need to release the source code when you release the software.

But it is you who decides when to release your software.


答:
The main reason for asking for copyright assignment is that it gives you the right to change the license on your code.  This might be desirable if you later want to sell the same code under a proprietary license.

Trolltech did that with great success for many years, by releasing Qt under the GPL while selling the same code with a proprietary license to commercial developers who wanted to keep their source private.

However, sometimes companies ask for copyright assignment for nefarious purposes.  The code that now drives Sourceforge was once GPL, but the main copyright owner, at the time VA Linux, asked all the contributors for copyright assignments without telling any of them that they were doing so so they could close the source completely and sell the code as a purely proprietary product.  That's just plain wrong.

If you don't plan to ever sell your code under a separate proprietary license - known as "dual licensing" and you think you will be happy with the license you initially choose, there's not that much point in asking for copyright assignments.

Title: Copyright assignment on open source projects

Body:
Some time ago I wrote a BlackBerry application. I find that I now want to release it under an open source license. I am strongly considering the GPL v3 license. All the code is mine; there are no third-party libraries (with the exception, of course, of the all the standard BlackBerry/Java libraries that I am "linked" to).

This is the first open source project that I will be maintaining or starting. I find myself a bit lost about how to handle contributions. It seems to be more-or-less standard to expect some kind of copyright assignment from contributors so that the project has a unified copyright. I could either assign all copyrights to the FSF or assign all copyrights to myself.

How should I handle this? The most important features of whatever implementation I use are:

Protects me from being sued for any unintentional violations of the GPL in my own code

Protects others' contributions from being misused by me if I become evil

Encourage others' contributions to the project (or at least does not discourage such contributions)

For assigning all copyrights to myself, the most promising strategy for copyright assignment seems to be one based on Oracle's contributor agreement, located here: http://openjdk.java.net/legal/oca.pdf. However, I feel like expecting any contributors to sign a legal document, providing me with fairly personal information is asking for a lot, especially given that my project is very small.

Should I proceed with requiring contributors to sign a document similar to Oracle's agreement? Should I just accept contributions and cross my fingers that I won't have any trouble down the road? Is there another strategy that I should employ?


答:
Did you work on the software during 'work' hours or as a personal project? If it was during work hours company B just want to cover their backsides as if company A turn round and claim as it was done on their time, it's their software and thank you very much for the cheque. </p>

<p>However if you get a sign off from company A to say that they're more than happy to let you use it however you want then great, if not you can say the source is open and just not publish it anywhere. I have loads of open source projects on my drive, but I won't be putting them online. </p>

Title: Is it possible to make something open-source without publishing it?

Body:
I've been working on some piece of software while being "employed" by company A. I now want to continue working on the same software while being employed by company B. Company B wants the software to become open-source to prevent any future legal issues between company A and them. I will consult company A's lawyer to make sure it's fine by them, but I suspect it will be alright as company A is actually a public university which looks favorably on industry connections.

However, I am concerned by potential competitors getting access to that code before we make its results public. Is it possible to make the software open-source without sharing it with anyone but company B (neither in binary nor source form), or do I have to publish the software the minute it is made open-source or shared with anyone?

If the answer depends on the specific open-source license used, please be kind and provide details about the differences.

Body:
Did you work on the software during 'work' hours or as a personal project? If it was during work hours company B just want to cover their backsides as if company A turn round and claim as it was done on their time, it's their software and thank you very much for the cheque.

However if you get a sign off from company A to say that they're more than happy to let you use it however you want then great, if not you can say the source is open and just not publish it anywhere. I have loads of open source projects on my drive, but I won't be putting them online.


答:
I think you'd be going the wrong way trying to use TDD as a way of fleshing out higher-level architecture elements like the choice of a framework (with the exception of a mocking framework maybe, the need for which can be discovered as your test suite grows). The refactor part of the TDD cycle is much more about micro decisions such as changes in the design of classes or methods, than big picture reorientations. If you need an ORM framework, for instance, you most certainly won't discover it through TDD.

You may be right though in saying that TDD will allow you to work out large parts of your code base in isolation from the rest and thus delay the choice of an SOA framework to the exact needed moment.

However the fact that you can afford to delay the choice doesn't mean it is forbidden to choose upfront, especially for big foundational architectural decisions that will have an impact on how your application is structured. Also keep in mind that unfortunately some frameworks are invasive and you end up forced to code things a certain way, which could ruin a part of your efforts if you have already developed a large part of your Services layer in an agnostic way through TDD.


问:
What is the minimum subset of best/well-known practices in software development for a solo programmer?
I've been the lonely programmer in my work for quite a long time. Usually I've read articles and posts about

Version Control Systems

Continuous Integration/Delivery

Development methodologies: Scrum, Waterfall, V-Model, Agile, XP, etc.

Software Project Management

But almost all of them seem to be focused on TEAMS. I'm not a team, so what would be the absolutely minimum set of practices for just one programmer?
Consider the following conditions:

I don't have conflicts with other's people code.

I don't need to maintain files/directory trees, my developement environment cares about versioning by itself (image-based development).

There are no formal requirements, my users don't know what they want
and they're are ok with that.

The only one which could be interested in delivering a release or
documentation it's me, basically customer want RESULTS and doesn't care about software methodologies, etc

My view is that I don't want to spend (too much) time and energy in anything not directly related with the customer requirements.
Any recommendations?

答: I'll just answer one, version control is massively important for any project and not just team ones. It takes a very small amount of extra time when you're using it but it provides a rich history for you to fall back on, it's not a silver bullet but it's certainly nice to be able to revert back to a working copy if that really experimental feature has broken most of the application.</p>


问:
How can I comply with Open Source licenses, and yet protect my own work + App Store
I recently developed an application for an organization (and I'm not charging them).
I want to maintain total ownership of the source code and there are various Open Source Project that I've used. I want/need to comply by the rules of the licenses that they use and still keep the project within a few guidelines:

If I ever give the source code out to the organization, It cannot
  be modified, redistributed, or shared in any form without my written
  permission (which needs to be re-obtained every version).

It should always attribute credits to the developer.

I retain all rights to redistribute/reuse the source code, since
  well, I made it

It needs to comply with the App Store's
  rules (which aren't too open-source friendly)

The organization has retained the copyright for the compiled application (if that matters)

The licenses include:

liberal BSD

Apache License, Version 2.0

royalty free

public domain (same as 3)

Small amount of artwork from an MIT licensed project

So my question is how can I comply with these licenses but also create a license for my own project that allows me to retain ownership of the source code.

答:
Because the executable is a derivative work of your source, the organization you wrote it for cannot own its copyright unless you give it to them.  Copyright descends on a work the instant you create it, and cannot be transferred to anyone else unless the copyright holder does so in writing.

If you want your client to have the copyright to the executable, then you will need to sign a copyright assignment for them.

As for your source code, you need to put a copyright and license notice at the beginning of all your source files:

Copyright (C) 2011 HelloFictionWorld.  All Rights Reserved.

"All Rights Reserved" means that you are not granting any manner of license to anyone.  However, some companies I've worked for wanted the following included as well:

This work is an unpublished proprietary trade secret of HelloFictionWorld.


答:
Behavioral interviews aren't necessarily a great thing either though. Here is a link to a blog post that while it is a over a couple of years old, it is worth mentioning on this subject to my mind.

Canned answers are what kill the effectiveness of the question, at least to my mind.  Most people have looked up various answers to this and just picked one that seems like, "Yeah, I'm kinda, sorta, maybe a bit like that."

Validating how someone did something has a couple of points I'd note:

Sometimes a dumb thing is done that isn't likely to be repeated.  When someone does royally screw up there may be alternatives that the person will take.  For example, most adults would not touch a hot stove with their bare hand but a child may not understand the warning and will learn after getting a burn not to do that.

References are where I'd look into some things here.  For example, if you want to see how someone handled a failed project, asking a former boss or co-worker may be better as an outsider may have a different take on things.  However, some people may fake their references so this does carry a caution to my mind.

Title: Effectiveness of "what is your greatest strength/weakness" interview questions

Body:
As someone who is now finding himself on the other end of the interview table, I'm wondering how useful these questions are from an employer's perspective. Some of my coworkers think they're good because you can see "how they respond," but I'm not convinced it tells you anything useful, for several reasons:

It's not a very comfortable question and can lead people to twist their answers, even if not on purpose

People may not fully know their greatest strengths or weaknesses (i.e. judge them by their peers)

Explaining what a strength is isn't as good as showing it

I still don't know any more about the candidate afterwards

The rationale of my coworkers is that it can help weed out people that give ridiculous responses, like one guy that said his greatest strength was "his intellect" or people that try to turn the weakness question into a strength like "I work too hard." But I think there's more effective ways to determine such things. If you want to see if someone's smart, ask them technical questions. If you want to see if someone is productive, look at their work history. If you want to see how someone reacts under stress or change, ask them how they've dealt with it and ask for concrete examples.

What are people's thoughts on these questions, from the perspective of an interviewer? What do they really tell you about a candidate, and what are better alternatives? How do I convince my colleagues of this?


答:
There's no right answer to this question because it depends on each person. If you use an iPad to do all your dev work and your clients are happy with you, you have no reason to change at all.

If, however, I were in your position, I would strongly enforce the following:

A version control system - While you may think an image-based development system does the job regarding regular backups and whatnot, you have zero wriggle room for experimental features where one would normally use a branch. You also have no way to retaining an important version of the project (tagging). If you ever expand to beyond just yourself, the developers that join will will think they're in hell.

Agile - This method is extremely applicable for clients who don't know what they want. Sooner or later, they'll realise they don't want to be spending money to chase their tail - they'll want to see progress.

Project management tool - This is a must. It's very formidable to be able to retain everything in your head, but you don't have to. Being disciplined and using a project management tool (e.g. Redmine) will allow you to separate your tasks and give you an easy-to-browse history of your work. It'll be very important for when you start charging per hour.

Title: What is the minimum subset of best/well-known practices in software development for a solo programmer?

Body:
I've been the lonely programmer in my work for quite a long time. Usually I've read articles and posts about

Version Control Systems

Continuous Integration/Delivery

Development methodologies: Scrum, Waterfall, V-Model, Agile, XP, etc.

Software Project Management

But almost all of them seem to be focused on TEAMS. I'm not a team, so what would be the absolutely minimum set of practices for just one programmer?
Consider the following conditions:

I don't have conflicts with other's people code.

I don't need to maintain files/directory trees, my developement environment cares about versioning by itself (image-based development).

There are no formal requirements, my users don't know what they want
and they're are ok with that.

The only one which could be interested in delivering a release or
documentation it's me, basically customer want RESULTS and doesn't care about software methodologies, etc

My view is that I don't want to spend (too much) time and energy in anything not directly related with the customer requirements.
Any recommendations?


答:
Version control is an absolute must for any programmer even a lone one. It means you can recover simply and quickly from deleted files and complex changes that are just wrong. </p>

<p>Basically it saves you from the stupid shit you do when you go to work hung over. </p>

Body:
Version control is an absolute must for any programmer even a lone one. It means you can recover simply and quickly from deleted files and complex changes that are just wrong.

Basically it saves you from the stupid shit you do when you go to work hung over.


答:
Version control is absolute must. Not only because of the keeping the source ok, but because of the source archaeology. A year from being able to check how a class or procedure evolved could save a lot of pain if you try to "fix" some piece of weird code.

For methodologies - I strongly recommend the programmers manifesto. It usually gives great results in small teams because of zero overhead and not having to keep in your head how the bunch of J2EE portlet-enabled JSR-compliant MVC role-based CMS web service application container frameworks work.


答: You don't have to make it open-source whilst working on it for Company B. Company A has the right to do whatever they want with the source code you produced for them- including giving it to company B. It doesn't have to be everyone or no-one.</p>


答:
As others say, version control or source code management is extremely important. Use a DVCS, and learn everything about it. It doesn't really matter which one it is, though it might benefit you if you chose a popular one: git or mercurial.

Another thing I didn't see mentioned, is a one-step build script. This is not straight-up continuous integration (that phrase is prone to BS in my opinion), but a very useful tool. Whenever you need to make an emergency update, you can just run the script and be done with it. When approaching the end of the project, it also happens that several builds are required per day. My experience is that it pays off greatly, even if the build process is not too complicated. You can even add ftp uploading capabilities, reports in e-mail, running unit tests, building installers, signing etc. Having the script written from the start it's easy to maintain and expand with more steps as the project progresses.


问:
Should the syntax for disabling code differ from that of normal comments?
For several reasons during development I sometimes comment out code. As I am chaotic and sometimes in a hurry, some of these make it to source control.

I also use comments to clarify blocks of code.

For instance:

```<code>MyClass MyFunction()
{
    (...)
    // return null; // TODO: dummy for now
    return obj;
}
</code>```

Even though it "works" and alot of people do it this way, it annoys me that you cannot automatically distinguish commented-out code from "real" comments that clarify code:

it adds noise when trying to read code

you cannot search for commented-out code for for instance an on-commit hook in source control.

Some languages support multiple single-line comment styles - for instance in PHP you can either use // or # for a single-line comment - and developers can agree on using one of these for commented-out code:

```<code># return null; // TODO: dummy for now
return obj;
</code>```

Other languages - like C# which I am using today - have one style for single-line comments (right? I wish I was wrong). I have also seen examples of "commenting-out" code using compiler directives, which is great for large blocks of code, but a bit overkill for single lines as two new lines are required for the directive:

```<code>#if compile_commented_out
    return null; // TODO: dummy for now
#endif
return obj;
</code>```

So as commenting-out code happens in every(?) language, shouldn't "disabled code" get its own syntax in language specifications? Are the pro's (separation of comments / disabled code, editors / source control acting on them) good enough and the cons ("shouldn't do commenting-out anyway", not a functional part of a language, potential IDE lag (thanks Thomas)) worth sacrificing?

Edit

I realise the example I used is silly; the dummy code could easily be removed as it is replaced by the actual code.

答:
First of all, in your example there are "TODO" comments. These types of comments are special in a way because they are detected by IDEs (at least Eclipse and Visual Studio) as a marker for "tasks". But I'm sure you know that since you use thme, and I suppose you're not referring to them when you use the term "disabled code".

As for the disabled code itself, my opinion is that it pollutes the code. I use another mechanism to keep track of what was there before: the source repository. Except when I'm in a code/test/code/test... mode, I don't comment unused code, I remove it. And when it's the case commenting X lines is just a matter of one keyboard shortcut.

Edit: so yeah, I forgot to answer your explicit question, I think that it's not useful to have special comments for disabled code. If you really want to keep the code, but say "don't use it", you can always mark it as @deprecated but that was not the point of your question.


答: Even if there's only one comment syntax in the language you're using you can still add your own flavour onto it, I've worked on projects where // denoted a disabled line and //-- indicated a comment. It's not as nice as having it built in, but most IDEs don't know you've used the different syntaxes for different purposes, so sometimes the old way of eyeballing to see the difference works best.</p>

Title: Should the syntax for disabling code differ from that of normal comments?

Body:
For several reasons during development I sometimes comment out code. As I am chaotic and sometimes in a hurry, some of these make it to source control.

I also use comments to clarify blocks of code.

For instance:

```<code>MyClass MyFunction()
{
    (...)
    // return null; // TODO: dummy for now
    return obj;
}
</code>```

Even though it "works" and alot of people do it this way, it annoys me that you cannot automatically distinguish commented-out code from "real" comments that clarify code:

it adds noise when trying to read code

you cannot search for commented-out code for for instance an on-commit hook in source control.

Some languages support multiple single-line comment styles - for instance in PHP you can either use // or # for a single-line comment - and developers can agree on using one of these for commented-out code:

```<code># return null; // TODO: dummy for now
return obj;
</code>```

Other languages - like C# which I am using today - have one style for single-line comments (right? I wish I was wrong). I have also seen examples of "commenting-out" code using compiler directives, which is great for large blocks of code, but a bit overkill for single lines as two new lines are required for the directive:

```<code>#if compile_commented_out
    return null; // TODO: dummy for now
#endif
return obj;
</code>```

So as commenting-out code happens in every(?) language, shouldn't "disabled code" get its own syntax in language specifications? Are the pro's (separation of comments / disabled code, editors / source control acting on them) good enough and the cons ("shouldn't do commenting-out anyway", not a functional part of a language, potential IDE lag (thanks Thomas)) worth sacrificing?

Edit

I realise the example I used is silly; the dummy code could easily be removed as it is replaced by the actual code.


答:
Back in the day, a very good book for answering this sort of question was Legal Care for Your Software.  However it is long out of print, and so has not been updated to address open source licensing.  I don't know of any equivalent book that has current information.

If you are going to work as a coder, you would do very well to learn about the parts of the law where you live that affect you, your work and your career.  Newbies are often advised to consult attorneys, but IMHO attorneys are no substitute for doing one's own homework.

There is a self-help legal book publisher called Nolo Press that has books on a wide variety of topics.  I used their How to Form Your Own California Corporation to incorporate my current company.  The book was straightforward and clear, and my Articles of Incorporation were approved by the California Secretary of State in just a few days.  Contrast that with the $1500 I was quoted by an attorney who I consulted for the incorporation of my previous company.

It's very important to actually read and understand the full text of each of the licenses you refer to.  If you don't understand something about a particular license, ask about it here.

The BSD (Berkeley Software Distribution) license is quite clear that its notice must be retained in all derivative works.  But when AT&T tried to sue UC Berkeley for infringing on AT&T's proprietary UNIX source code, it was found during discovery that AT&T has taken many of Berkeley's BSD licensed sources, removed the BSD license notices, then applied an AT&T copyright.  That was blatantly illegal, and was the reason that AT&T lost the lawsuit.

Happily for us, it meant that the various *BSD disributions could be openly published without interference from AT&Ts attorneys.

Title: How can I comply with Open Source licenses, and yet protect my own work + App Store

Body:
I recently developed an application for an organization (and I'm not charging them).
I want to maintain total ownership of the source code and there are various Open Source Project that I've used. I want/need to comply by the rules of the licenses that they use and still keep the project within a few guidelines:

If I ever give the source code out to the organization, It cannot
  be modified, redistributed, or shared in any form without my written
  permission (which needs to be re-obtained every version).

It should always attribute credits to the developer.

I retain all rights to redistribute/reuse the source code, since
  well, I made it

It needs to comply with the App Store's
  rules (which aren't too open-source friendly)

The organization has retained the copyright for the compiled application (if that matters)

The licenses include:

liberal BSD

Apache License, Version 2.0

royalty free

public domain (same as 3)

Small amount of artwork from an MIT licensed project

So my question is how can I comply with these licenses but also create a license for my own project that allows me to retain ownership of the source code.


答:
For several reasons during development I sometimes comment out code. As I am chaotic and sometimes in a hurry, some of these make it to source control.

I think this is the root of the problem. Being chaotic and rushed is only going to introduce problems. Figuring out why your development is being rushed and isn't well controlled should be the first step, not trying to find commented out code.

So as commenting-out code happens in every(?) language, shouldn't "disabled code" get its own syntax in language specifications? Are the pro's (separation of comments / disabled code, editors / source control acting on them) good enough and the cons ("shouldn't do commenting-out anyway", not a functional part of a language) worth sacrificing?

I don't think so. Commented out code is a bad practice and I don't think languages should encourage anyone to use it. Yes, people do it and I've seen it, but I refuse to check in code of mine that is commented out. Giving people the ability to easily manage unused, old code is beyond the scope of a language and is something that belongs in the realm of version control.

I'm also concerned about technical limitations. In order for this to work, you would need to either parse comments and determine if they are commented out source or text or add a new token to the language. Depending on the current complexity of the language, I'm not entirely sure what impact this would have on compilation (identifying if a line is or is not valid code to be compiled). Also, people would then expect IDEs to manage this in real time (is there a relationship between complexity of a language's syntax and IDE responsiveness to finding and highlighting various constructs and errors).


问:
Best practices for graph representation of a system architecture?
I don't really know the nomenclature regarding these matters, but here is a brief description of what I want. Please let me know if I should substantiate more.

So I have this larger project involving databases, different languages, and interfaces (SQL, R, C, Python, both GUI & CLI). It's growing a little too big to fit into a simple mental construct of what is actually going on. I am interested in making the mother of all charts mapping out the project from a system architecture perspective. Generally speaking I'd like the information to show some meta information of the data rather and where it is produced / consumed. I guess it is close to a flow chart, but as I am no expert in these matters I am asking for help.

Are there any tools for this? Any best practices regarding formatting etc? How about symbols for all the procedures / classes / methods / functions? Please chime in if you have any opinion regarding the matter.

Just to frame a little bit more what I would be interested in:

I rather use tools like Latex than Visio

I hate large and fancy IDEs, but I adore VIM

I would do with static solutions, but I would be interested in automated solutions too (as long as they are not too complicated of course)

答:
I am interested in making the mother of all charts mapping out the project from a system architecture perspective.

You aren't going to find such a thing, or at least such a thing that will add any value. The idea behind any architectural diagram is the architectural view that it provides. When I took my course in software architecture, the focus was on the 4+1 Architectural View Model, but there are other view models as well.

The idea behind the view models is that different people will need different information to do their jobs and make informed decisions. They each need to see a different aspect of the system, and don't want to have to wade through useless information. This means that you'll end up with several architectural models of the system.

Are there any tools for this? Any best practices regarding formatting etc? How about symbols for all the procedures / classes / methods / functions?

Conventionally, UML or an architecture description language is used for architectural models of a system. Depending on the needs of the user of the model, other techniques might also be used, such as flow charts, textual descriptions, and other less formalized diagrams.

The important thing to realize, as an architect, is that you need to realize who will be looking at the product and what information they want. Deliver exactly what they need in a format that they expect and can readily use.


答:
As the author of the source you can put it under two licenses. One can be the LGPL, while the other is the exclusive, closed-source deal you want with company B.

Go ahead and post the LGPL code on Github. You can even give the project a reasonable sounding name, or just give it a code name. The source will be out there, but you will still be able to enhance it using the company B license, and these changes you will not have to share on Github.

Then, if company A realizes it wants to charge fees (really, it's only company B that is concerned about this possibility) then you are in the end game and will need to switch to the open version. You are worried about keeping a competitive edge, but how you execute and work on this is far more important, and no one understands the code base or the problem as well as you do anyway.


问:
Is it out of line to give unsolicited constructive criticism to a programmer?
I recently started work at new office that uses a proprietary program written by a solo developer. He's occasionally around as part-time tech support, but the company has signed off on this software and he's no longer being paid to develop it.

As a user of his software there are many issues that leap out to me as a source of concern:

very simple to directly view the DB as a low-privilege user

passwords stored as plaintext

dictionary admin passwords

app uses the DB root account

DB doesn't meet 1NF (eg. appointment1, appointment2, etc.)

I feel like these are serious issues and that if I were him I'd want them pointed out to me, but I'm not a qualified programmer (I'm a social worker) and I don't know if it would be rude of me to just buttonhole him and start blabbering about salted hashes and normal forms, especially when this is no longer a paid task of his.

Is it out of line? If not, how would you broach it?

Edit - more info prompted by comments:

The application holds sensitive data.

It's for internal use, but it's running on lots of machines in several cities and many visitors come through our offices.

My concerns are for the developer's future projects as well as this specific one.

答:
Do you know the story behind the program?  Perhaps it was written in a very short time frame where the developer made these decisions rather quickly as the software had to be done as quickly as possible without a bunch of investigating being done into it.

Does the support include patches on the code?  This may work for some minor things that the code has that you see as major issues.  The other thought is how hard would it be to replace this software.

There are cases where a peer helping out a peer with unsolicited constructive criticism can work but this is a bit different to my mind.  I'd say be sensitive about how you communicate the issues and try to keep it professional.


问:
How do I isolate difficult to reproduce bugs?
There's a bug in my program. Doesn't really matter what the platform is. Every so often, a row in a ListView is the wrong color. I tried setting a watchpoint for the variable that is supposed to dictate the color of the row, and it doesn't change... I am guessing it means the problem could be in the framework code. I've only witnessed it happen once.. My client has noticed it though, and wants it fixed. No idea where to start. Someone told me to artificially increase the load of the program.

What are some methods for hunting down difficult to find bugs?

答:
Logging. Add a bunch of logging to the related module, set it to debug and get the user to send you a copy of the log when the error occurs again.

If you can reproduce the error, set your logger to go to the console, and try to reproduce it. Look for anomalies that only occur when the colour is wrong.

Back track. Find all references find any line of code that could possibly cause this issue. Then think about whether the code is doing what it should. Don't trust that your code works like you think it does. Challenge yourself - "this variable should be set to x" now test that it is. Set a conditional breakpoint. Or a print line. Or a log.

Grab a friend. Do some pair programing, another pair of eyes may help you.

Google the frame work, ask on SO, see if other people have had a similar issue. Maybe its not a bug in the framework, but a trap that people occasionally fall into.

This is framework dependent, but in WPF you should display the output and look for binding errors.

Go have a look over your clients shoulder. See if they are using the program in a different way to the way you test. Maybe they can reproduce it but aren't documenting their steps. Maybe you are assuming usage flow that is different to what the client is actually doing.

Take careful notes, or even better run a screen recording programing. Once the bug occurs, restart the app, and follow exactly what you did before. if you can reproduce it then you're half way there.


答:
Tracking down problems like these are a great opportunity to apply assertions. An assertion is simply a check on some boolean condition: "the set should be non-empty when pop is called". Many programming languages provide direct support for assertions: when enabled, assertions will abort the program or raise exceptions when they fail; when disabled, assertions are nothing more than fancy comments.

This will take some digging and re-engineering on your part. You will need to scatter through the relevant parts of the program assertions that you believe are true. You may be surprised to see that some condition is failing, when you thought it was true. When a program does something like this, it introduces an infection [in the Andreas Zeller sense], which could then lead to further infections, which might finally manifest themselves as defects [bugs].

For more tips, read through Zeller's lecture notes from his fine book, Why Programs Fail: http://www.st.cs.uni-saarland.de/edu/adebug/2002/07-tracing.pdf

And here is a link to his discussion of assertions.

Finally, given that your client regularly encounters this, this first place to start is with them! Good luck!

Title: How do I isolate difficult to reproduce bugs?

Body:
There's a bug in my program. Doesn't really matter what the platform is. Every so often, a row in a ListView is the wrong color. I tried setting a watchpoint for the variable that is supposed to dictate the color of the row, and it doesn't change... I am guessing it means the problem could be in the framework code. I've only witnessed it happen once.. My client has noticed it though, and wants it fixed. No idea where to start. Someone told me to artificially increase the load of the program.

What are some methods for hunting down difficult to find bugs?


答: Polling is better if the polling process runs considerably slower than the things it polls.  If you are writing events to a database, it's often better to poll all your event producers, collect all the events that have occurred since the last poll, then write them in a single transaction.  If you tried to write every event as it occurred, you might not be able to keep up and eventually would have problems when your input queues filled up.  It also makes more sense in loosely-coupled distributed systems, where latency is high or connection set-up and tear-down are expensive.  I find polling systems easier to write and understand, but in most situations observers or event-driven consumers seem to offer better performance (in my experience).</p>


问:
What is the benefit of not using Hungarian notation?
One of the things I struggle with is not using Hungarian notation.  I don't want to have to go to the variable definition just to see what type it is.  When a project gets extensive, it's nice to be able to look at a variable prefixed by 'bool' and know that it's looking for true/false instead of a 0/1 value.

I also do a lot of work in SQL Server.  I prefix my stored procedures with 'sp' and my tables with 'tbl', not to mention all of my variables in the database respectively.

I see everywhere that nobody really wants to use Hungarian notation, to the point where they avoid it.  My question is, what is the benefit of not using Hungarian notation, and why does the majority of developers avoid it like the plague?

答:
IMO the biggest benefit of not using Hungarian is the fact it forces you to use meaningful names.  If you are naming variables properly, you should immediately know what type it is or be able to deduce it fairly quickly in any well-designed system.  If you need to rely on str or bln or worse of all obj prefixes to know what type a variable is, I would argue it indicates a naming issue - either poor variable names in general or way too generic to convey meaning.

Ironically, from personal experience the main scenario I have seen Hungarian used is either "cargo-cult" programming (i.e. other code uses it, so let's continue to use it just because) or in VB.NET to work around the fact the language is case-insensitive (e.g. Person oPerson = new Person because you can't use Person person = new Person and Person p = new Person is too vague); I've also seen prefixing "the" or "my" instead (as in Person thePerson = new Person or the uglier Person myPerson = new Person), in that particular case.

I will add the only time I use Hungarian tends to be for ASP.NET controls and that's really a matter of choice.  I find it very ugly to type TextBoxCustomerName or CustomerNameTextBox versus the simpler txtCustomerName, but even that feels "dirty".  I feel some kind of naming convention should be used for controls as there can be multiple controls that display the same data.