问:
How to share control of links/domains on an open source project with many collaborators?
I'm trying to help the Rebol project re-engineer its web presence now that it is open source as Apache 2 — after nearly two decades of proprietary license!

The language's creator currently has registrar control of the rebol.com/.org/.net sites.  He wishes to keep control of the rebol.com domain as a holding for his Rebol Technologies company (and its remaining non-open codebases).  But he has indicated a willingness to let the community take over rebol.org and rebol.net — which are sites that show their age at present.  They need large overhauls in terms of organization / content / visual theming; and the current proposal is that the .org become a neutral Wikipedia-like documentation and curated module library (with few outbound links), while the .net be a more sociable "developer network" of diverse community resources.

While the creator is trusted as being benevolent, he can't really be a benevolent dictator for the project, as he has largely released his interest in Rebol due to a new career.  Moreover, the turnaround in responding to community concerns has historically been on very long timescales... and hence many alternative sites have popped up to fill in the gaps.

The question of how to take control of the issue and get the community to invest in content hosted under the nice domain names—rather than each going their separate direction—is a thorny one.  For comparison, I did WHOIS domain-name checks and a little research on the main go-to sites for Ruby and Python.

ruby-lang.org

Admin Name: Matsumoto.Yukihiro Matsumoto.Yukihiro

Admin Organization: Ruby Users Group

It seems that the source to ruby-lang.org is maintained on GitHub.  If I read it correctly, there are 35 members of the ruby GitHub organization, though I don't know enough about that to know which of these people have commit access or what the checks and balances are.

I don't see any official link defining the "Ruby User's Group".  There is a non-profit called Ruby Central that seems to do some organization, but the only holdings I could find was some controversy when the Rails guy tried to prevent people from using the rails logo.  ruby-lang.org seems to have almost no remarks on legal structure.

python.org

Admin Name: Domain Administrator

Admin Organization: Python Software Foundation

This seems significantly more formal, as they have bylaws and you can either buy your way into the voting structure with sponsorship...or be nominated / elected by a member of the existing membership.

I like how lightweight and trusting the Ruby model is.  But if Matz were hit by a bus—then other than people being sad—what would happen?  Whose hands would ruby-lang.org fall into?  What if the situation were slightly different such that Matz were very trusted on technical matters, but not to follow up on getting site issues fixed in a timely manner?

Python seems to have this more planned out, but is rather heavyweight.  According to Wikipedia the Python Software Foundation was formed in 2001, has 124 members with Guido Van Rossum as president, and had a budget of $750,000 in 2011!

So how might a project with fewer resources manage something as simple as a couple of domain names, and how content disputes will be resolved?  There's a desire to reboot the identity...but without some form of enforceable contract it's not likely going to please the parties involved.

答:
You have this problem twice.  Once for the website, and once for the code base for Rebol.  You should use the same solution for both.

That is, the structure that you come up with for controlling what goes into the code base is the also structure for the web site.  The actual people involved may be different.  But if, as with Ruby, one person is in charge, that person needs to be in charge of both.  If, as with Python, there is an official organization in charge, that organization needs to be in charge of both.  If there is a disagreement between people handling the website and people releasing code, it needs to be obvious how to resolve that.  (Even the nicest people have off days, assume there will be arguments.)

Next, consider carefully what you most fear.  Do you fear people going off in different directions and doing unrelated things?  Make contributing to the official site their easiest option.  Do you fear winding up with an inconsistent site?  Make sure that someone is in control and can enforce a consistent vision.  Note that there is a tension between these goals, "all of the above" is not a possible answer.  Figure out what you are scared of and try to address it as best as you can.

I know nothing of the Rebol community.  However my guess from your comments is that at this point it is fairly small and fragmented with no central authority.  Therefore I'd worry more about how to get people involved than on how to make people achieve some central vision.  But that's a general bias that I would personally bring to anything.

More generic advice.  If you're a small organization, keep it simple.  Benevolent dictator is common for good reason.  But in a situation like yours where you don't know who will step up you might consider Constitutional Monarchy instead.  For inspiration, consider how Perl does the whole pumpking thing.  Even though Larry Wall is not deeply involved in day to day development, for each release of Perl he appoints someone to be in charge.  If there was a huge problem (hasn't happened yet that I know of), he could unappoint them and appoint someone else.

The founder of Rebol might be convinced to play this role.  An example model might be, "As a final resort, I reserve the right to put someone else in charge at any point.  I hope never to do that.  Anyone who steps up and is not obviously objectionable gets whatever responsibility they want and seem to be doing.  Once there is a sense who is actively doing stuff, that group should figure out a way to rotate responsibility on a regular basis."

As a final thought, I leave you with this.  If you manage to get and keep the right people involved, it will work no matter how you organize it.  If you get the wrong people involved, it will fall apart no matter how well you organize it.  My impression is that "the right people" tend to be people who want to get stuff done, care about doing it well, don't have ego about doing it their way, and don't try to create fiefdoms.  Good luck finding them and encouraging them to feel at home.


问:
Is it correct to fix bugs without adding new features when releasing software for system testing?
This question is to experienced testers or test leads.
This is a scenario from a software project:

Say the dev team have completed the first iteration of 10 features and released it to system testing. The test team has created test cases for these 10 features and estimated 5 days for testing. The dev team of course cannot sit idle for 5 days and they start creating 10 new features for next iteration. During this time the test team found defects and raised some bugs. The bugs are prioritised and some of them have to be fixed before next iteration. The catch is that they would not accept the new release with any new features or changes to existing features until all those bugs fixed. The test team says that's how can we guarantee a stable release for testing if we also introduce new features along with the bug fix. They also cannot do regression tests of all their test cases each iteration. Apparently this is proper testing process according to ISQTB.

This means the dev team has to create a branch of code solely for bug fixing and another branch where they continue development. There is more merging overhead specially with refactoring and architectural changes.

Can you agree if this is a common testing principle. Is the test team's concern valid. Have you encountered this in practice in your project.

答:
You can solve this (common) problem by merging merge both teams.

Testers within the development team, testing as features are produced, can help most teams increase the quality of the output.

I suggest you to read this excellent blog post from Henrik Kniberg that explain Kaban. You will find many ideas in the Scrum process (a free book also by Henrik Kniberg).

He also wrote an excellent Kanban VS Scrum article on his blog.

Enjoy.

ContentLicense: CC BY-SA 2.5


问:
Is JavaBeans a good example of encapsulation?
I'm trying to understand if JavaBeans is a good example of encapsulation. In my view, it's not as usually all the internal state is exposed through getters and setters.

A simple example is

```<code>public class Test {
    private List<String> names = new ArrayList<String>();

    public List<String> getNames() {
        return names;
    }

    public void setNames(List<String> names) {
        this.names = names;
    }
}
</code>```

This follows the JavaBeans standard but it leaks the implementation. For example a user could call test.getNames().clear().

Am I missing something?

答:
JavaBeans do not have any business being mentioned in the context of object oriented concepts such as encapsulation.

Encapsulation refers to the containment of functionality behind an api - in object oriented languages, the api is typically provided by a class through its public members.  Encapsulation allows you to easily re-use functionality without causing undo binding because, again, the functionality is accessed through an api - never directly.

As someone mentioned above, an object by definition is when data and the code that operate on it are in the same class.  In 99.9% of the cases I have seen JavaBeans being used (which unfortunately is everywhere), they do not contain any functionality other than setters and getters.  Setters and getters are not application level functionality - i.e. you aren't going to cause an invoice to be saved by calling a setter or a getter, therefore beans are not objects.

Beans are structs, which are data only structures used in structured and procedural programming.  They were state of the art in the late 80's, early 90's, using just about every language available at the time, the most popular being C.

Using beans will make your programs much larger and far less flexible than, for example, using collections in appropriate places.  Everyone I discuss this with scoffs at this notion, but if I am not mistaken, compiled java classes, under the hood, are basically collections of collections.  These collections are what reflection trolls through to get you information about the class.  They are what the runtime looks through to find the correct method to run for a given class.

A bean is, without a doubt, about as automation unfriendly as you can get - they are utterly inflexible, and will grow your code base far beyond the functionality it contains.

ContentLicense: CC BY-SA 3.0


问:
How to convince my teammates that spawning numerous threads is a bad design?
I've stumbled upon this problem when tried to run our application in bad network conditions; it spawns hundreds of threads (which exist long time before termination), and with time the application crashes. However, other developers answered this is "not a bug" and "as designed".

I have a strong gut feeling that spawning so much threads instead of using async calls is defective design, in the first place. However, my teammates disagree.

Any ideas how I can convince them?

UPD can I say that spawning threads for short running tasks is a bad design? What arguments I can use to support this statement?

答: I'm sure you need to explain to them what Thread Pool is. And that each solid framework does have one implemented and people who implemented it are most probably many times better than themselves at solving this kind of problems.</p>


问:
Should we be looking out for lying code?
This is referring to a discussion in an answer and the comments of this question: What's with the aversion to documentation in the industry?.  The answer claimed that "code can't lie" and thus should be the go-to location instead of documentation.  Several comments pointed out that "code can lie".  There is truth on both sides, at least partly because of how poorly and inappropriately documentation is handled.

Should we be on the lookout for lying code, comparing it against any existing documentation?  Or is it usually the best source for what it needs to be doing?  If it is agile code, is it less likely to lie, or can that code not lie at all?

答:
You ask several questions.

Should we be on the lookout for lying code?

Of course!

Should we be comparing [code] against any existing documentation?

That could never hurt, though as mentioned in other answers, more often than not this will lead you to find problems in the documentation, not in the code.

Or is [code] usually the best source for what it needs to be doing?

It is always the best source for what it is doing. The best source for what code should be doing can be (a combination of) different things though, the main ones being:

The code itself;

The calling code;

Comments in that code;

Documentation;

Unit tests;

Integration and regression tests;

The programmer;

The end user;

Which is the "best" source (or combination thereof) depends on your situation.

If it is agile code, is it less likely to lie, or can that code not lie at all?

I'm not sure what you mean by "agile code", AFAIK "agile" usually refers to the coding process. Supposing you mean "code created in an agile programming process" then I think it's safe to say that it can still lie. How likely it is to lie, compared to code created in e.g. waterfall style projects is a subjective matter (personally I don't think there's a big connection).

Footnote

All the above is under the assumption that code can lie, and that this is a basic (though bit contrived) example:

```<code>public int DivideByTwo(int input)
{
    return input / 3;
}
</code>```

This is just one example where I'd say "code lies", @user61852 has a few others (unreachable code, complexity of code not matching complexity of problem, bad naming), and I think there are many more. Wikipedia has a somewhat decent summary of lies, many of them can be found code.

Note that if you're in an argument with someone, be very sure the other person's doesn't mean by "code can't lie" that "code does what it does". In essence the other person here is defining using a definition for "lie" that's so narrow that it can declare the statement "code can't lie" as an axioma / basic truth. In this case it's probably best to agree with his/her axioma.

Body:
You ask several questions.

Should we be on the lookout for lying code?

Of course!

Should we be comparing [code] against any existing documentation?

That could never hurt, though as mentioned in other answers, more often than not this will lead you to find problems in the documentation, not in the code.

Or is [code] usually the best source for what it needs to be doing?

It is always the best source for what it is doing. The best source for what code should be doing can be (a combination of) different things though, the main ones being:

The code itself;

The calling code;

Comments in that code;

Documentation;

Unit tests;

Integration and regression tests;

The programmer;

The end user;

Which is the "best" source (or combination thereof) depends on your situation.

If it is agile code, is it less likely to lie, or can that code not lie at all?

I'm not sure what you mean by "agile code", AFAIK "agile" usually refers to the coding process. Supposing you mean "code created in an agile programming process" then I think it's safe to say that it can still lie. How likely it is to lie, compared to code created in e.g. waterfall style projects is a subjective matter (personally I don't think there's a big connection).

Footnote

All the above is under the assumption that code can lie, and that this is a basic (though bit contrived) example:

public int DivideByTwo(int input)
{
    return input / 3;
}

This is just one example where I'd say "code lies", @user61852 has a few others (unreachable code, complexity of code not matching complexity of problem, bad naming), and I think there are many more. Wikipedia has a somewhat decent summary of lies, many of them can be found code.

Note that if you're in an argument with someone, be very sure the other person's doesn't mean by "code can't lie" that "code does what it does". In essence the other person here is defining using a definition for "lie" that's so narrow that it can declare the statement "code can't lie" as an axioma / basic truth. In this case it's probably best to agree with his/her axioma.


答: Don't manually manage threads if you don't have to and instead try to use a thread pool. Pretty much all languages and runtimes that support threads also have a thread pool implementation built into the standard library. So using threads in and of itself is not a bad idea but manually managing threads can get out of hand pretty quickly so in the beginning try to stick with whatever high level thread management comes built-in.</p>

Title: How to convince my teammates that spawning numerous threads is a bad design?

Body:
I've stumbled upon this problem when tried to run our application in bad network conditions; it spawns hundreds of threads (which exist long time before termination), and with time the application crashes. However, other developers answered this is "not a bug" and "as designed".

I have a strong gut feeling that spawning so much threads instead of using async calls is defective design, in the first place. However, my teammates disagree.

Any ideas how I can convince them?

UPD can I say that spawning threads for short running tasks is a bad design? What arguments I can use to support this statement?


答:
Spawning a new thread for each task is not necessarily a bad design, but there are some factors that need to be taken into consideration:

Context switching between threads takes time. If the number of runnable threads becomes very large (an order of magnitude larger than the number of cores/processors you have), then this can negatively affect the perceived performance of the application

There are only so many threads you can create. If there is no upper limit to the number of threads that an application creates, then the application will run out of resources sooner or later.

Creating a new thread is a heavy-weight operation. If you create a new thread for every short-running task, you might find that the thread creation takes a significant portion of the time that those threads 'exist'. Using a work queue and a thread pool might actually increase the performance of the application.


答:
Secret sharing might be useful to provide access to a secret (like a password) in a way that several people must agree to access it. This could help with the "Matz is hit by a bus" problem—a person in charge uses the secret on a day-to-day basis, while a group of people can together gain access should something happen to the leader. (Of course, if a sufficient number of them went rogue, they could still take over from the dictator, but... really?) As a wild idea... someone could implement secret sharing in Rebol (carefully—it needs to be secure, as the secret is being trusted to it) and then it could serve the dual role of being a backup for the secret and being one of the demo programs on rebol.org. Nice thing about doing it this way is that all Rebol coders can verify the system—it's in the language they know.

Some other thoughts: I think you might do well to think about how you're going to fund the domains and other public-facing infrastructure. It would seem to me that whoever is paying for infrastructure ultimately controls it, so that might be something to factor in. For example, if the creator is providing the domains, then it seems he ultimately has control over the existence of the sites. Perhaps that can be involved in the setup.

You might also find some interesting thoughts in this essay from Eric Raymond, particularly this part. He talks there about the different ways that open-source projects get their "owners," whether they be the original developer or a successor.

Some other communities you might take a look at for ideas:

Debian:

Debian is probably bigger than what you're thinking, but here's a couple quick links regarding their organizational structure: About Debian and Organization

Perl:
@btilly mentioned Perl's organizational structure, and it turns out their domain seems to be under control of one guy (who isn't Larry Wall!): Whois; Website. Also, you could take a look at http://www.perl.org/community.html and http://www.perlfoundation.org. It feels (to a latecomer like me) like the Perl Foundation has succeed in bringing together a number of parts without destroying their differences. For example, PerlMonks appears to have been an independent site and has now been "assimilated by The Perl Foundation" according to its footer.

Title: How to share control of links/domains on an open source project with many collaborators?

Body:
I'm trying to help the Rebol project re-engineer its web presence now that it is open source as Apache 2 — after nearly two decades of proprietary license!

The language's creator currently has registrar control of the rebol.com/.org/.net sites.  He wishes to keep control of the rebol.com domain as a holding for his Rebol Technologies company (and its remaining non-open codebases).  But he has indicated a willingness to let the community take over rebol.org and rebol.net — which are sites that show their age at present.  They need large overhauls in terms of organization / content / visual theming; and the current proposal is that the .org become a neutral Wikipedia-like documentation and curated module library (with few outbound links), while the .net be a more sociable "developer network" of diverse community resources.

While the creator is trusted as being benevolent, he can't really be a benevolent dictator for the project, as he has largely released his interest in Rebol due to a new career.  Moreover, the turnaround in responding to community concerns has historically been on very long timescales... and hence many alternative sites have popped up to fill in the gaps.

The question of how to take control of the issue and get the community to invest in content hosted under the nice domain names—rather than each going their separate direction—is a thorny one.  For comparison, I did WHOIS domain-name checks and a little research on the main go-to sites for Ruby and Python.

ruby-lang.org

Admin Name: Matsumoto.Yukihiro Matsumoto.Yukihiro

Admin Organization: Ruby Users Group

It seems that the source to ruby-lang.org is maintained on GitHub.  If I read it correctly, there are 35 members of the ruby GitHub organization, though I don't know enough about that to know which of these people have commit access or what the checks and balances are.

I don't see any official link defining the "Ruby User's Group".  There is a non-profit called Ruby Central that seems to do some organization, but the only holdings I could find was some controversy when the Rails guy tried to prevent people from using the rails logo.  ruby-lang.org seems to have almost no remarks on legal structure.

python.org

Admin Name: Domain Administrator

Admin Organization: Python Software Foundation

This seems significantly more formal, as they have bylaws and you can either buy your way into the voting structure with sponsorship...or be nominated / elected by a member of the existing membership.

I like how lightweight and trusting the Ruby model is.  But if Matz were hit by a bus—then other than people being sad—what would happen?  Whose hands would ruby-lang.org fall into?  What if the situation were slightly different such that Matz were very trusted on technical matters, but not to follow up on getting site issues fixed in a timely manner?

Python seems to have this more planned out, but is rather heavyweight.  According to Wikipedia the Python Software Foundation was formed in 2001, has 124 members with Guido Van Rossum as president, and had a budget of $750,000 in 2011!

So how might a project with fewer resources manage something as simple as a couple of domain names, and how content disputes will be resolved?  There's a desire to reboot the identity...but without some form of enforceable contract it's not likely going to please the parties involved.


问:
Working for free?
I came across this article Work for Free that got me thinking.

The goal of every employer is to gain
  more value from workers than the firm
  pays out in wages; otherwise, there is
  no growth, no advance, and no
  advantage for the employer.
  Conversely, the goal of every employee
  should be to contribute more to the
  firm than he or she receives in wages,
  and thereby provide a solid rationale
  for receiving raises and advancement
  in the firm.

I don't need to tell you that the
  refusenik didn't last long in this
  job.

In contrast, here is a story from last
  week. My phone rang. It was the
  employment division of a major
  university. The man on the phone was
  inquiring about the performance of a
  person who did some site work on
  Mises.org last year. I was able to
  tell him about a remarkable young man
  who swung into action during a crisis,
  and how he worked three 19-hour days,
  three days in a row, how he learned
  new software with diligence, how he
  kept his cool, how he navigated his
  way with grace and expertise amidst
  some 80 different third-party plug-ins
  and databases, how he saw his way
  around the inevitable problems, how he
  assumed responsibility for the
  results, and much more.

What I didn't tell the interviewer was
  that this person did all this without
  asking for any payment. Did that fact
  influence my report on his
  performance? I'm not entirely sure,
  but the interviewer probably sensed in
  my voice my sense of awe toward what
  this person had done for the Mises
  Institute. The interviewer told me
  that he had written down 15 different
  questions to ask me but that I had
  answered them all already in the
  course of my monologue, and that he
  was thrilled to hear all these
  specifics.

The person was offered the job. He had
  done a very wise thing; he had earned
  a devotee for life.

The harder the economic times, the
  more employers need to know what they
  are getting when they hire someone.
  The job applications pour in by the
  buckets, all padded with degrees and
  made to look as impressive as
  possible. It's all just paper. What
  matters today is what a person can do
  for a firm. The resume becomes pro
  forma but not decisive under these
  conditions. But for a former boss or
  manager to rave about you to a
  potential employer? That's worth
  everything.

What do you think? Has anyone here worked for free? If so, has it benefited you in any way? Why should(nt) you work for free (presuming you have the money from other means to keep you going)? Can you share your experience?

Me, I am taking a year out of college and haven't gotten a degree yet so that's probably why most of my job applications are getting ignored. So im thinking about working for free for the experience?

答:
When I graduated my resume was fairly sparse. Whilst looking for my first job, I approached a local charity and built them a web site.

Doing this had many benefits:

Firstly volunteering your skills for a good cause feels good

It was a valuable addition to my portfolio/work experience

I gained valuable experience

I had additional experience to discuss in subsequent interviews for paid jobs

The charity also nominated me for the Volunteer of the Year Award (I didn't win it :) ), but even the nomination was good addition to my resume

I'm glad I did it.

I would have been less inclined to work for a company for free, but it depends on the organisation. You have to weigh up whether offering your services for free with the chance of a good job/career is worth risking your time.

Contributing to open source projects, or even starting your own, is another good way to hit many of the points I listed above.

Title: Working for free?


答:
It's difficult to propose a solution to people who don't think they have a problem. Your app crashing under certain circumstances is considered acceptable. Like everything there is a level of risk and reward. You can try to approach in one or both directions.

Will "it was designed that way" be acceptable to users/customers? Personally, I'd suggest the design is flawed (and the designer is an idiot for intentionally doing this) and needs to change because I'll go find an app that doesn't crash. Do your collegues want to face these complaints? Maybe it is easier to just fix it?

Is the fix that difficult? Lots of suggestions give about frameworks that take care of threads for the most part. How difficult would they be to use?

"That's the way it was designed." "This is the way we always did it." If they want to argue that customers don't care and/or the fix is too difficult to make because of more important features or risk of further hindering the application would sound a lot more like they've given this some thought.


问:
When to use inheritance or composition/aggregation?
In general, how do I decide whether to use make a class a super class, or to make it a private data member of another class? For example, given two classes, how does one decide whether to do this:

```<code>public class Sprite {
    private BaseImage image;
    ...
</code>```

or this:

```<code>public class Sprite extends BaseImage {
    ...
</code>```

Functionally, I know the difference: in the second case, any method that uses an instance of the Sprite class will have access to the underlying BaseImage behavior. In the first case the behavior of the BaseImage object is hidden. But from a design perspective, which is preferable in what cases?

答:
If i understand your question correctly (and i am not sure that i do), you are having a similiar issue than i had a few weeks ago.

Ask yourself whether Sprite has a baseImage [instance] or rather is a baseImage [subclass]

Further reading:

my own question

Is-a

has-a

If i got something wrong, just ignore this answer :)


答:
In layman's words:

The first example is a "has a" relationship whereas the second one is an "is a relationship".

You don't have Car extend Wheel. Car has wheels.

Car doesn't have a Vehicle, Car is a Vechicle.

Inheritance is for "is a" relationships.

Composition is for "has a" relationships.

I don't know whether Sprite is a BaseImage  or has a BaseImage. That's for you to decide.

Title: When to use inheritance or composition/aggregation?

Body:
In general, how do I decide whether to use make a class a super class, or to make it a private data member of another class? For example, given two classes, how does one decide whether to do this:

```<code>public class Sprite {
    private BaseImage image;
    ...
</code>```

or this:

```<code>public class Sprite extends BaseImage {
    ...
</code>```

Functionally, I know the difference: in the second case, any method that uses an instance of the Sprite class will have access to the underlying BaseImage behavior. In the first case the behavior of the BaseImage object is hidden. But from a design perspective, which is preferable in what cases?


问:
What does long-term freelancing say about a developer's experience?
I have been interviewing candidates lately for a developer position requiring 10+ years experience and have come across a couple of CVs that I am not sure how to understand: I have interviewed a few of these people and so far have had no luck.

What are people's experience with developers with about 10 years experience, but who from day one have been working as mostly project-based freelancers? Are there potential benefits or drawbacks to a software development firm in having that type of experience?

答:
Well, there's different types of independent contractors. Some are really the same as corporate developers, their paychecks are just processed by a different company. Some mainly do long term (6 month+) single client engagements, and some are specialists in a particular technology.

This may be an Americanism, but I typically equate "freelancing" to a solo developer/entrepreneur who works a variety of smallish engagements for a variety of clients. The rest of this comment pretty much strictly applies to the somewhat stereotypical traits associated with that role. Of course, any individual should be judged individually - but, for me at least, there are a few different areas of probing during an interview that are dictated by the candidate's background. With that disclaimer, here's my thoughts on freelancers:

Some are freelancers by choice, some by circumstance, and some are forced to it.

You obviously don't want any of the latter - there is a non trivial amount (but nowhere near the majority) of freelancers that would not survive long-term employment for either personal or technical reasons. The only way they can get by is by constantly changing employers, and staying one step ahead of their poor references. These are pretty easy to weed out with standard interview practices - which should catch the bottom of the pile corporate developers as well. A freelancer's references are usually more forthcoming than a poor corporate developer's though (who often will either refuse to provide any useful feedback, or are so happy to get them out the door they'll lie through their teeth), so use those as well if you're still unsure.

Freelancers by circumstance will usually have either a long term engagement or a period where they went from employee to freelance for the same corporation. For me, I usually treat these the same as an employee - yeah, they're freelancers, but it's not really a part of their identity.

The freelancers by choice are where it gets interesting. These are the folks who have possibly turned down full time employment multiple times, but are now looking for a steady gig. Going from freelance to full time employment can certainly be a culture shock - and you want to find out why they're making the move. I'd look at these candidates similar to one looking to relocate - you're not just judging the company fit, but trying to make a determination on the lifestyle fit as well.

As for specific upsides/downsides, it's a mixed bag. On the pros, you may find more experience/skills in:

communicating with non-technical stakeholders/audiences

juggling multiple priorities

getting up to speed on a project or technology quickly

areas related to but not development (project management, server administration, support)

initiative

a personal support network

flexibility in work schedule

On the downsides, you may find:

lack of status reporting/bug tracking and team communication

little to no source control experience (don't know why, but a lot of solo developers don't see the need for it)

a focus on cranking out projects, with little to no eye for maintainability

a default resistance of "authority", whether that authority is corporate bureaucracy or a manager or a senior team lead or the team itself

flexibility in work schedule (see what I did there?)

Which, at the end of the day, are pretty much the range of solo corporate developer traits as well.


问:
What techniques do you use when interviewing developers?
I realize there have been lots of discussions about this type of thing and they often devolve into dogma around whether you ask the "100 logical pirates" type of questions or whether you get them to write "fizz buzz".

I'm interested in what techniques and questions have been effective for you when interviewing potential developers for jobs.

One technique per answer so we can vote on them, please.

答:
Have a conversation, let it drift and meander along the technical and professional route and look for insightful or stupid comments along the way. This gets you 3/4 of what you need from an interview, an assessment of: people skills and personality, general intelligence, and a rough assessment of technical skills.

Use your interview "questions" as topic starters and for keeping the conversation corralled to technical topics - you may need to reset the conversation from time to time (such as doing a coding exercise) to adequately probe areas of concern/interest.

The real trick to this technique is to make sure they do all the talking, otherwise you run the risk of a favorable evaluation because they made you feel smart by listening to/agreeing with everything you said.


问:
Should we design programs to randomly kill themselves?
In a nutshell, should we design death into our programs, processes, and threads at a low level, for the good of the overall system?

Failures happen. Processes die. We plan for disaster and occasionally recover from it. But we rarely design and implement unpredictable program death. We hope that our services' uptimes are as long as we care to keep them running.

A macro-example of this concept is Netflix's Chaos Monkey, which randomly terminates AWS instances in some scenarios. They claim that this has helped them discover problems and build more redundant systems.

What I'm talking about is lower level. The idea is for traditionally long-running processes to randomly exit. This should force redundancy into the design and ultimately produce more resilient systems.

Does this concept already have a name? Is it already being used in the industry?

EDIT

Based on the comments and answers, I'm afraid I wasn't clear in my question. For clarity:

yes, I do mean randomly,

yes, I do mean in production, and

no, not just for testing.

To explain, I'd like to draw an analogy to multicellular organisms.

In nature, organisms consist of many cells. The cells fork themselves to create redundancy, and they eventually die. But there should always be enough cells of the right kinds for the organism to function. This highly redundant system also facilitates healing when injured. The cells die so the organism lives.

Incorporating random death into a program would force the greater system to adopt redundancy strategies to remain viable. Would these same strategies help the system remain stable in the face of other kinds of unpredictable failure?

And, if anyone has tried this, what is it called? I'd like to read more about it if it already exists.

答:
No.

We should design proper bad-path handling, and design test cases (and other process improvements) to validate that programs handle these exceptional conditions well. Stuff like Chaos Monkey can be part of that, but as soon as you make "must randomly crash" a requirement actual random crashes become things testers cannot file as bugs.


问:
How do we provide valid time estimates during Sprint Planning without doing "too much" design?
My team is getting up to speed with Scrum, but most of us are more familiar with non-agile or  "pseudo-"agile methodologies. The part that is the biggest hurdle for us is running an efficient Sprint Planning meeting where we break our backlog items into tasks, and estimate hours. (I'm using the terminology from the VS2010 Scrum Template; apologies if I use the wrong word somewhere.)

When we try to figure out how long a task is going to take, we often fall into the trap of designing the feature at the code level -- table layout, interfaces, etc -- in order to figure out how long that's going to take.

I'm pretty sure this is not the appropriate place to be doing that kind of design. We  should be scheduling tasks for these design meetings during the sprint. However, we are having trouble figuring out how else to come up with meaningful estimates for the tasks.

Are there any practical habits/techniques/etc. for making a judgement call about how long a feature is going to take, without knowing how you plan to implement it? If our time estimates are going to change significantly once the design has been completed, how can we properly budget our Sprint backlog ahead of time?

EDIT:

Just to clarify, since some of the comments/answers are very valid but I think addressing the wrong question.

We know that what we're doing is not right, and that we should be building time into the sprint for this design. Conceptually all of the developers understand that. We also also bringing in a team member with Scrum experience to keep us on track if we start going off into the weeds.

The problem is that, without going through this design process, we are finding it difficult to provide concrete time estimates for anything. We are constantly saying things like "well if we design it this way it might take 8 hours but if we end up having to do this other way instead that will take about 32 but it might not be as bad once we start trying to write it...".

I also assume that this process will get better once we have some historical velocity to work from, but many of the technologies and architectural patterns we are using are new to us. But if potentially-wildly-wrong estimates are just a natural part of adapting this process then we will just need to recondition ourselves to accept that :)

答:
I know your question is specifically about avoiding design in planning. But this is sort of an XY Problem.

I've been where you are. Rather than give you something that may provide an incremental improvement, I'd like to help you leapfrog some of those intermediate states.

Here are three things our team does specifically related to planning and executing work. These have helped us avoid design thrashing and escape from inaccurate time estimates.

Automatable Acceptance Criteria

Our stories are pointed by their number of Automatable Acceptance Criteria. This means, if we were to write automated tests to confirm that the story is done, what would they be?

For example, "When the user clicks 'play' on an iPad running iOS 6+, the video starts playing." It might be hard to actually automate this test, but it's an acceptance criteria (AC) of the story and contributes one point.

We use the Fibonacci scale, and we always round up. So if a story has four automatable acceptance criteria, it's a five point story.

Our maximum story point size is eight points, but we rarely have those. If a story has more than five automatable acceptance criteria, we find a way to split them up.

Pre-Grooming

We have a kickoff meeting on Monday, but our grooming meetings are where team planning happens. Prior to grooming, team members will pre-groom a story by describing the outcome and taking a stab at the automatable acceptance criteria.

Grooming brings the expertise of the team to bear on the pre-groomed stories, ferreting out unspecified requirements, breaking stories up, etc.

We sometimes list tasks in addition to the acceptance criteria, but these are not time estimated. We never estimate time. Tasks are just statements of work that needs to be done in support of the criteria.

Limiting Work-in-Progress

Traditional scrum attempts to limit the time of work to the sprint duration. We found that this artificially caused us to rush to meet sprint deadlines, killing our weekends because the sprint ends on Friday.

Another approach is to limit the work in progress at any given time. We've migrated to the latter and have been significantly happier for it.

Once a story moves from the backlog into work in progress, we characterize it as being in one of several states:

On Hold - team work can't happen because we're waiting on some extra-team activity

In Development - working on achieving the acceptance criteria

Needs Test - we believe we've met the AC, waiting for someone else to verify

In Test - the story is being evaluated against the AC, bugs are being addressed

Ready to Deploy - at the next available opportunity, it's going live

We then use the number of stories in each state to drive the team's focus. For example, a developer may be available to take on a new story, but if we've got a lot of stories In Test, it's better for them help out on existing stories.


问:
Code Samples and Interviews?
I've seen a number of questions since I've been here where, in the answer, someone has asserted that they would never use portfolios or code samples coded outside of the interview process to judge a candidate, because there is a possibility of that code having been written by someone else. I find myself surprised by this.

The way I see it, if I ask someone to come in and solve a simple problem on the spot, there is very little I can learn from it. I don't work for a company like Google where jobs are sought after and I can demand a day of someone's time. But a substantial piece of hobby-written code can tell me a lot.

Yes, there is the possibility of plagiarism, but they're going to have to be very well coached to get through an hour long discussion about that code. And should that be the case, they'll have to be very quick learners to get through their 3-month probation (during which I can get rid of them with no reason and with no notice). If they become good programmers that quickly, fair enough, I've been duped, but I still have a good programmer.

In the end, the cost to our company and the benefit to the candidate of plagiarism is very minimal.

This got me to thinking about other industries. Artists, photographers, designers all use portfolios and nobody worries too much about plagiarism there. An author will get funded for a book based on chapters he has written in his own time. You wouldn't ask an architect to come in and draw design specs for a house at the interview.

So what makes us different? Why is it so important to put someone in front of a computer and make them code up a data merge or a factorial calculator, sometimes without access to the very tools we use day-to-day, like the internet? What is wrong with the idea of a code portfolio?

I'm genuinely interested to know, in case I am potentially making a huge mistake which just hasn't burned me yet.

答:
A code sample is a pretty efficient way of weeding out candidates - I can judge a code sample in 5 - 10 minutes, but even a phone screen takes 15 minutes and needs scheduling (and isn't terribly useful in weeding out anything but the very bottom of the pile in my experience).

I think the main objections to code samples are two fold, and are easily overcome:

that requiring a code sample puts up an artificial barrier for some talented developers

Obviously, this is true. Any barrier in the application or hiring process may potentially weed out a desirable candidate. The important thing here is to know your audience - if you have 1000 resumes for your one opening, you can afford some false negatives in service of efficiency. If you have five resumes, you can afford some inefficiencies in the screening process.

What I think most people miss, though, is that interviewing and hiring is basically a game of "find a reason not to hire this person". For any decent job, there's a lot of qualified applicants - the last one standing is usually the one that didn't set off any red flags along the way. It's easy to see the best in people or be non-committal, but that doesn't do you any good in hiring because you'll end up with 10 different candidates that you're comfortable with. That doesn't get you any closer to a decision.

Every tidbit you collect along the way of reviewing, screening, interviewing, etc. could potentially trigger a no-hire decision. You have to balance the sensitivity of your no-hire trigger with your current (and potential future) prospects. If you're in a boring industry,  with lots of legacy code, bureaucracy and poor salary (often things out of your control) then your trigger needs to be less sensitive than say, Google. Otherwise, you'll run the risk of never hiring anyone.

Personally, I find the easiest compromise for me has been to request but not require a code sample. If I get one, it's just an additional data point to evaluate the candidate with. Similarly, if I happen to have an acquaintance that has worked with the candidate in the past,  I'll attach some weight to that acquaintance's opinions. Not having worked with anyone I know certainly doesn't disqualify any candidates though - it just means that my job in evaluating them is a bit harder (and will probably include a coding exercise if they make it to an interview). If your sample is poor (or my acquaintance bad mouths you), it's pretty much a no-hire. Those that provide a sample may or may not have a small leg up on those that don't in initial screening - depending on the quality and quantity of the resume stack and samples, more information may be better or worse than no information.

that samples are easily faked

Well, yeah. So are resumes - but we still collect those. Why? For three main reasons - a poor resume or sample is an easy no-hire, being caught faking a resume or sample is an easy no-hire, and they're good conversation topics in an interview. The quicker I can figure out the candidate is a dolt, the better for everyone.

If you're smart enough to plagiarize a good sample without being caught, talk intelligently about it, and get through the interview - I don't particularly have a problem with how you got past the screening. There may be some ethical concerns here, but that's not really my area of expertise, so I'm not going out of my way to evaluate moral character during an interview. To me, it's virtually the same as my boss asking me to interview someone who didn't get through the screening process as a favor. Once you're at the interview stage, it doesn't really matter how you got there since there's so much more and better information that will come out during the interview.

TL;DR - a code sample is a great screening tool, but you should think carefully whether you can do require it or not. Once past screening, weight the interview much higher than a sample.

Title: Code Samples and Interviews?


答:
Yes.  No.  Maybe.

Periodic termination is a two-edged sword.  You're going to get hit with one edge or the other, and which is the lesser of two evils depends on your situation.

One edge is reliability:  If you force the program to end randomly (or predictably) and in an orderly way, you can be prepared for that event and deal with it.  You can guarantee that the process will exit when it's not otherwise busy doing something useful.  This also guarantees that bugs that would manifest themselves beyond the sanctioned run time won't rear their ugly heads in production, which is a good thing.  Apache HTTPD has a setting that will let you tune how many requests a child process (or thread in more recent versions) will serve up before terminating.

The other edge is also reliability:  If you don't allow the program to run long, you'll never find bugs that manifest themselves over time.  When you do finally run into one of those bugs, it's much more likely to cause the program to return a wrong answer or fail to return one at all.  Worse, if you run many threads of the same job, a time- or count-induced bug could affect very large numbers of tasks all at once and result in all a 3 a.m. trip into the office.

In a setting where you run a lot of the same threads (e.g., on a web server), the practical solution is to take a mixed approach that results in an acceptable failure rate.  If you run 100 threads, running a short-to-long ratio of 99:1 means that only one will exhibit long-term bugs while the others continue to do whatever it is they do without failing.  Contrast that with running 100% long, where you run a much higher risk of having all of the threads fail at the same time.

Where you have a single thread, it's probably better to just let it run and fail, because the dead time during a restart may result in undesired latency when there's real work to do that would complete successfully.

In either case, it's important that there be something supervising the processes so they can be restarted immediately.  Also, there's no law that says your initial decisions about how long a process should run have to be cast in stone.  Collecting operational data will help you tune your system to keep failures down to an acceptable level.

I would recommend against doing random termination, because that makes it more difficult to nail down time-related bugs.  Chaos Monkey does it to make sure the supervisory software works, which is a slightly different problem.

Title: Should we design programs to randomly kill themselves?

Body:
In a nutshell, should we design death into our programs, processes, and threads at a low level, for the good of the overall system?

Failures happen. Processes die. We plan for disaster and occasionally recover from it. But we rarely design and implement unpredictable program death. We hope that our services' uptimes are as long as we care to keep them running.

A macro-example of this concept is Netflix's Chaos Monkey, which randomly terminates AWS instances in some scenarios. They claim that this has helped them discover problems and build more redundant systems.

What I'm talking about is lower level. The idea is for traditionally long-running processes to randomly exit. This should force redundancy into the design and ultimately produce more resilient systems.

Does this concept already have a name? Is it already being used in the industry?

EDIT

Based on the comments and answers, I'm afraid I wasn't clear in my question. For clarity:

yes, I do mean randomly,

yes, I do mean in production, and

no, not just for testing.

To explain, I'd like to draw an analogy to multicellular organisms.

In nature, organisms consist of many cells. The cells fork themselves to create redundancy, and they eventually die. But there should always be enough cells of the right kinds for the organism to function. This highly redundant system also facilitates healing when injured. The cells die so the organism lives.

Incorporating random death into a program would force the greater system to adopt redundancy strategies to remain viable. Would these same strategies help the system remain stable in the face of other kinds of unpredictable failure?

And, if anyone has tried this, what is it called? I'd like to read more about it if it already exists.


答:
Do you really mean random? Having your software randomly kill itself sounds like a terrible idea. What point would that serve?

I'm  guessing what you really mean is that we should be realistic about long running threads/processes and accept that that the longer they run, the more likely they are to have encountered some sort of hidden bug, and gotten into a non-functional state. So, as a purely pragmatic measure, the lifetime of processes and threads should be limited.

I believe that back in the late 90s the Apache web server used something like this. They had a pool of worker processes (not threads) and each worker process would be killed after a fixed lifetime. This kept the server from being monopolized by worker processes that had gotten stuck in some pathological state.

I haven't worked in the area for some time, so I don't know if this is still the case.


答:
This is really no different than testing. If you're designing an always-available failover solution (like Netflix), then yes - you should test it. I don't know that random exits sprinkled throughout the code base is an appropriate way to test that, though. Unless you're really intent on testing that your design is resilient to shooting yourself in the foot, it'd seem more appropriate to test it by manipulating the environment around the code and verifying it behaves appropriately.

If you're not designing redundant systems, then no - you shouldn't add that feature because you added some random exits. You should just remove the random exits, and then you won't have that problem. Your environment may still fail on you, at which point you'll either chalk it up as not-supported/won't-fix or harden your code against that failure and add a test for it. Do that often enough, and you'll realize that you actually are designing a redundant system - see scenario #1.

At some point, you may determine that you're no longer sure what failures are or are not handled. Now you can start randomly pulling the rug out to detect the failure points.

The only interesting thing about the Netflix example is that they run these tests in production. That makes a certain amount of sense - some bugs really are production only things that are very hard or impossible to simulate in an isolated environment. I suspect that Netflix spent a long time in test environments before they were comfortable enough to do this in production though. And really all they're doing is trying to get crashes to occur during business hours, which makes a certain amount of sense for their market but not for a lot of others.


答:
The process of introducing defects in software or in hardware in order to test fault tolerance mechanisms is called fault injection.

From Wikipedia:

The technique of fault injection dates back to the 1970s when it
  was first used to induce faults at a hardware level. This type of
  fault injection is called Hardware Implemented Fault Injection (HWIFI)
  and attempts to simulate hardware failures within a system. The first
  experiments in hardware fault injection involved nothing more than
  shorting connections on circuit boards and observing the effect on the
  system (bridging faults). It was used primarily as a test of the
  dependability of the hardware system. Later specialised hardware was
  developed to extend this technique, such as devices to bombard
  specific areas of a circuit board with heavy radiation. It was soon
  found that faults could be induced by software techniques and that
  aspects of this technique could be useful for assessing software
  systems. Collectively these techniques are known as Software
  Implemented Fault Injection (SWIFI).


答:
I somewhat agree with that initial comment but I do think there are at least some things worth considering on a somewhat subjective level.

Somebody who has done a lot of shorter-term assignments, is more likely to have been exposed to a much wider variety of technology and practices, than somebody who worked at the same company, on the same app, for ten years.

On the flipside of that, somebody who's worked on the same app for 10 years, is more likely to have a heck of a lot more patience dealing with legacy systems and will know a  lot more about the impact of changes to a system in terms of long-term maintainability etc...

There are of course exceptions in both cases. It really depends on the nature of the work they've done and the personality of the individual doing it. A freelancer could be highly-specialized as consultants often are. The ten-years guy could still be juggling a wide variety of technologies depending on the nature of the work. I would treat these things more as avenues worth exploring at the interview than pre-judgments to rely on before it even starts. If I were putting a team together I'd want both devs described in the bullets on my team, personally.

But if you're looking to establish whether somebody is flaky on a single scan of a resume, I'm 100% agreed with that first comment. People don't choose freelance for 10 years because nobody will have them for full-time. It's what worked for them in that 10-year span and now they're ready to do something else.

If your problem is that you're getting more interest than you have time to interview, looking to filter candidates on arbitrary criteria should be a last resort. I'd recommend going to back to your ad and getting a lot more specific (and by that I don't mean "add more acronyms/bullet points") about what you're looking for and what kind of work they can expect to be doing at your company. That will allow a lot of them to filter themselves out.

Treat it like a matching process, not a contest. The advantage of candidates with that much experience is that the better you describe what they can expect, the more people who know they won't like working for you won't show up because they have plenty of options. And that's a good thing that reflects badly on neither you nor them. It just makes your job easier.

Title: What does long-term freelancing say about a developer's experience?

Body:
I have been interviewing candidates lately for a developer position requiring 10+ years experience and have come across a couple of CVs that I am not sure how to understand: I have interviewed a few of these people and so far have had no luck.

What are people's experience with developers with about 10 years experience, but who from day one have been working as mostly project-based freelancers? Are there potential benefits or drawbacks to a software development firm in having that type of experience?


问:
Which is better design: Determining if a function should execute from outside of it, or inside of it?
I'm often presented with these two options.  From a design point of view, which of these is subjectively better, and why?

Option A

```<code>class foo {
  private boolean bar() {
    //Stuff
  }

  private void A() {
     if(bar())
       B();
  }

  private void B() {
      // more stuff
  }
}
</code>```

Option B

```<code>class foo {
  private boolean bar() {
    //Stuff
  }

  private void A() {
      B();
  }

  private void B() {
     if(!bar())
        return;

     // more stuff
  }
}
</code>```

Let's assume that code duplication isn't an issue here, and the division is only to separate, logically, the code for better readability/understanding (A, B, and bar have meaningful names in context).    Is it more readable to have the reader know that B might not do anything when looking at just A?  Or is the encapsulation of state better put into B?  Obviously, this can be refactored to separate B and bar() into a separate class entirely, which separates concerns even more, but assuming mostly shared state, which is better?

答:
The important bit is who owns bar? If it's unclear, consider if B can live up to it's method name considering the value of Bar. If so, then make it part of B. If not, then make it part of A.

In a real world scenario, you'll generally find methods that fulfill a design responsibility, and helper methods that fulfill implementation steps. Generally, the decision of whether to call an implementation method resides with the API method - which is generally the public method.

```<code>public class Control {
    public bool IsVisible;
    public void Render() {
       if (this.IsVisible) {
          this.PrepareForRender();
       }
    }
    private void PrepareForRender() {
       // just do it. Don't check IsVisible
    }
 }
</code>```

It's possible that you have two different API methods calling each other. In that case, I'd suggest falling back on the semantics of why doesn't B run when Bar is false? Is it because B is unnecessary - then B should decide.

```<code> public class List {
    public int Count;
    public void SetTo(object[] values) {
       this.Clear(); // need to clear values; don't really care how
    }
    public void Clear() {
       // Count = 0 is just a shortcut to fulfilling Clear's responsibility
       if (this.Count == 0) return;
    }
 }
</code>```

Is it because B is incorrect? Then A should decide.

```<code>public class File {
    public bool IsBinary;
    public void Write() {
       if (this.IsBinary) {
          this.OpenBinaryStream();
       } else {
          this.OpenTextStream();
       }
    }
    private void OpenBinaryStream() {
    }
    private void OpenTextStream() {
    }
 }
</code>```

Because it's actively harmful? A should decide, and B should throw an exception:

```<code>public class File {
    public bool UseSecureDelete;
    public void Delete() {
       if (this.UseSecureDelete) {
          this.ZeroBytes();
       }
    }
    private void ZeroBytes() {
       if (!this.UseSecureDelete) throw new InvalidOperationException();
    }
 }
</code>```

Body:
The important bit is who owns bar? If it's unclear, consider if B can live up to it's method name considering the value of Bar. If so, then make it part of B. If not, then make it part of A.

In a real world scenario, you'll generally find methods that fulfill a design responsibility, and helper methods that fulfill implementation steps. Generally, the decision of whether to call an implementation method resides with the API method - which is generally the public method.

public class Control {
    public bool IsVisible;
    public void Render() {
       if (this.IsVisible) {
          this.PrepareForRender();
       }
    }
    private void PrepareForRender() {
       // just do it. Don't check IsVisible
    }
 }

It's possible that you have two different API methods calling each other. In that case, I'd suggest falling back on the semantics of why doesn't B run when Bar is false? Is it because B is unnecessary - then B should decide.

 public class List {
    public int Count;
    public void SetTo(object[] values) {
       this.Clear(); // need to clear values; don't really care how
    }
    public void Clear() {
       // Count = 0 is just a shortcut to fulfilling Clear's responsibility
       if (this.Count == 0) return;
    }
 }

Is it because B is incorrect? Then A should decide.

public class File {
    public bool IsBinary;
    public void Write() {
       if (this.IsBinary) {
          this.OpenBinaryStream();
       } else {
          this.OpenTextStream();
       }
    }
    private void OpenBinaryStream() {
    }
    private void OpenTextStream() {
    }
 }

Because it's actively harmful? A should decide, and B should throw an exception:

public class File {
    public bool UseSecureDelete;
    public void Delete() {
       if (this.UseSecureDelete) {
          this.ZeroBytes();
       }
    }
    private void ZeroBytes() {
       if (!this.UseSecureDelete) throw new InvalidOperationException();
    }
 }


问:
What are non-programming mistakes that a programmer should avoid?
People make mistakes, even in the real life... Which should we, geeky programmers, avoid?</p>

答: Learn that what constitutes "An acceptable degree of precision" to you is "Annoying goddamn nitpicking" to most of the world.</p>


答:
```<code>if (x > 5) {
  doSomething();
} else {
  doADifferentThing();
}
</code>```

You can argue about whether the word "lie" is technically appropriate, but this code is implying quite clearly that x will sometimes be greater than 5 and sometimes not. If you look at the full program and discover that this function is ever only called in one place, and that x is always set to a constant 6, then that's a lie.

Moreover, the compiler may have noticed this, and replaced this block of code with simply

```<code>doSomething()
</code>```

If doADifferentThing isn't called anywhere else in your program, it may be removed from the program entirely.

If your language supports an assert of some kind, which is turned off in production builds, each assert statement is potentially a lie. A typecast is another assertion which could be a lie.

Title: Should we be looking out for lying code?

Body:
This is referring to a discussion in an answer and the comments of this question: What's with the aversion to documentation in the industry?.  The answer claimed that "code can't lie" and thus should be the go-to location instead of documentation.  Several comments pointed out that "code can lie".  There is truth on both sides, at least partly because of how poorly and inappropriately documentation is handled.

Should we be on the lookout for lying code, comparing it against any existing documentation?  Or is it usually the best source for what it needs to be doing?  If it is agile code, is it less likely to lie, or can that code not lie at all?

Body:
if (x > 5) {
  doSomething();
} else {
  doADifferentThing();
}

You can argue about whether the word "lie" is technically appropriate, but this code is implying quite clearly that x will sometimes be greater than 5 and sometimes not. If you look at the full program and discover that this function is ever only called in one place, and that x is always set to a constant 6, then that's a lie.

Moreover, the compiler may have noticed this, and replaced this block of code with simply

doSomething()

If doADifferentThing isn't called anywhere else in your program, it may be removed from the program entirely.

If your language supports an assert of some kind, which is turned off in production builds, each assert statement is potentially a lie. A typecast is another assertion which could be a lie.


问:
Git tracks _lines_ of code. Is there something that track _words_?
In git if I change a character in a line the entire line is considered changed.

I don't know much but stackexchange seem to track changes in a word-by-word basis in the edit history.

Is there an option to make git like that, or is there anything else that does this?

答: I wouldn't say it's inherently true that git tracks lines, not words. Git stores snapshots of the entire source tree. It just happens to display differences between those trees as a line-based diff. But that's only the default way of displaying things. You can do git diff --word-diff to see a word-based diff which may be more useful in some cases. Do git help diff to see a zillion other flags you can pass to git diff.


答:
Adding random exit code to the application should not be necessary. Testers can write scripts which randomly kill the application's processes.

In networking, it is necessary to simulate an unreliable network for the sake of testing a protocol implementation. This does not get built into the protocol; it can be simulated at the device driver level, or with some external hardware.

Don't add test code do the program for situations that can be achieved externally.

If this is intended for production, I can't believe it's serious!

Firstly, unless the processes exit abruptly so that in-progress transactions and volatile data is lost, then it's not a honest implementation of the concept. Planned, graceful exits, even if randomly timed, do not adequately help prepare the architecture for dealing with real crashes, which are not graceful.

If real or realistic malfunctions are built into the application they could result in economic harm, just like real malfunctions, and purposeful economic harm is basically a criminal act almost by definition.

You may be able to get away with clauses in the licensing agreement which waive civil liability from any damages arising from the operation of the software, but if those damages are by design, you might not be able to waive criminal liability.

Don't even think about stunts like this: make it work as reliably as you can, and put in fake failure scenarios only into special builds or configurations.


答:
It depends. I've noticed that programmers tend to overgeneralize the techniques that apply to their specific domain ignoring all others. For example getting program released at the cost of fixing all of the bugs may be good... unless you program aircraft controller, nuclear reactor etc. "Don't optimize - cost of programmer is greater then cost of running program" is not necessary valid for HPC as there relatively simple program can occupy cluster for months etc. (or even a popular program that is used by large amount of users). So even if company X is doing Y for very good reason you don't necessary need to follow their footsteps as your situation might be different.

Usually the error handling routines are the worst tested part of the code - while it seems simple it is hard to simulate that there is insufficient memory or some important file is not there. For that reason I read texts that proposed for Unix kernel to randomly fail some system calls. However it would make a simple programs harder to write (if I need to plug 3 C++ libraries together to run a program on 2 files once I don't want to bother with error handling). Even with exceptions, GC you need to ensure that you left consistent state behind (imagine exception in middle of adding node to linked list).

The more distributed services you have the more the failures is question of "how frequent" then "if" or "when". In data centers disk replacement in RAIDs are part of routine operations from what I know - not an unexpected failures. If you operate on large scale you need to take it into account as even if probability of failure of one component is small, chances are that something will fail.

I don't know what exactly you are doing but to know if it is worth it you need to think if failure is something you need to take into account (as ignoring it costs) or it is something too costly to analyse (as taking errors into account costs development time).


答:
This doesn't seem that preposterous of an idea.

Android OS randomly kills and restarts user apps/services all the time.  In my experience it has definitely helped me think more deeply about error conditions as well as design more robust architectures.


问:
What should you do when presented with a horrible design?
Our firm makes websites. We also design websites. But sometimes our client brings his/her own design. This is often made by an in-house designer, or it is the same design they used for something else. However, sometimes these designs look awful. And I am talking really unprofessional, unbalanced, uncool. But the client really wants this design. I really do not like working with a design that is so awful. It takes away all pleasure in coding. You code. You check the demo. Works great. Looks awful. It's just not fun.

And ultimately the client might be happy, but 1) I do not feel proud of the final product and 2) the community sees you 'develop' ugly websites, which is bad for your image.

Anybody experiencing this kind of stuff? What do you recommend?

I've been thinking:

Blocking these clients. If somebody has an 'own' design, ask to see it first. Then somehow politely decline. Drawback: you lose a client.

Create a new design. Have our in-house designers work one something really cool. Drawbacks: client would need to pay for this (without asking for it), or it will be declined and the company loses time = money. And it might come as an insult if you propose a new design out of the blue. THEIR designer won't like it for sure.

Put a clear disclaimer at the bottom of the site: Website design by XXXXX, Website development by US. Helps for the community-impact (if people pay attention), but not for the uneasy feeling.

答:
I'd say your 1 and 2 points are the critical issues here. I'm going backwards because that expresses my points in a better order.

2) the community sees you 'develop' ugly websites, which is bad for your image.

You're a client-side web developer. It's understood that you often have no control of a design. I'm not a designer in any way shape or form on the aesthetic side of things for instance but my early bread and butter was taking other people's designs and reproducing them as faithfully as possible in HTML/CSS/JS. In my early portfolio I had the original designs with side-by-side comparisons of the HTML/CSS produced to mimic them. Making it clear that you're showing something for layout work skills vs. your own aesthetic and usability design skills is something you can do in your portfolio, not something anybody is going to be willing to stamp on their property because you think it's ugly/stupid.

FYI, the first thing I would do when considering any client-side dev, even a strictly web design-oriented one, is see how clean their HTML is under the hood so make sure you don't neglect best practices on that front.

1) I do not feel proud of the final product

In cases like this "the final product" isn't your responsibility. Put your pride in things you control as best you can and swallow the rest. But yes, I do agree that the one thing that's worse than a client that has no idea what they want is one that knows exactly what they want right down to what kind of brass they want in the brass tacks.

As for your suggested solutions, forget about it. The only way you will ever be given that level of control is when you start your own interactive freelancing business and you've attracted enough clients to say no to people. And if you're a great designer you can get there, but you're going to have to hold your nose for a couple years until you've established that level of cred. In the meantime look for smaller agencies that are already in that position to say no to pre-built crap designs because too many people are seeking them out for excellent design they provide in the first place.

OwnerDisplayName: plua


答:
A lot of the existing answers have suggested you should take the money. You are a business not an artist. I agree with this to a point, but doing this could cause you reputational harm.

I've several friends who worked for a company who started to do exactly that. They built the games the publishers asked for, often designed by committee. The guys who worked for them knew the games where terrible. It was the beginning of a vicious cycle. They made these crappy games and then fewer and fewer people would work for them, except for those publishers who wanted that kind of crappy game. The company went bust.

What do you need more; money or more business? If you just need money and you have an endless supply of customers then you should just take the money. Sometimes your reputation is more valuable than any particular project.

I would suggest you politely suggest that you can provide design consultancy skills to help them. If they don't take the hint, tell them that you don't feel that it is a suitable project for you. Do not tell them their design is terrible, it is too subjective and again might harm your reputation.

Don't be afraid to turn down work unless its your only option.

Title: What should you do when presented with a horrible design?

Body:
Our firm makes websites. We also design websites. But sometimes our client brings his/her own design. This is often made by an in-house designer, or it is the same design they used for something else. However, sometimes these designs look awful. And I am talking really unprofessional, unbalanced, uncool. But the client really wants this design. I really do not like working with a design that is so awful. It takes away all pleasure in coding. You code. You check the demo. Works great. Looks awful. It's just not fun.

And ultimately the client might be happy, but 1) I do not feel proud of the final product and 2) the community sees you 'develop' ugly websites, which is bad for your image.

Anybody experiencing this kind of stuff? What do you recommend?

I've been thinking:

Blocking these clients. If somebody has an 'own' design, ask to see it first. Then somehow politely decline. Drawback: you lose a client.

Create a new design. Have our in-house designers work one something really cool. Drawbacks: client would need to pay for this (without asking for it), or it will be declined and the company loses time = money. And it might come as an insult if you propose a new design out of the blue. THEIR designer won't like it for sure.

Put a clear disclaimer at the bottom of the site: Website design by XXXXX, Website development by US. Helps for the community-impact (if people pay attention), but not for the uneasy feeling.


问:
What should every programmer know about programming?
Please, stay on technical issues, avoid behavior, cultural, career or political issues.

答:
Can't believe this hasn't been mentioned

Every programmer worth is salt needs to be able to produce world ready software.

By this I mean following basic internationalization principles such as externalizing all strings etc.

I can't believe how many times I've seen hard-coded English strings or dialogs with truncated strings etc. when the product has been translated.


问:
The 10 minutes technical interview
I must do a quick assessment of dozens of fresh students very quickly. I have 30 minutes meeting with each of them (in two or three days). I want to use most of the time to discuss non technical aspects. So I plan to use 10 minutes for technical questions. The same questions for all of them.

They are all hired already (they are students), what I need to know is the average level in order to prepare a training.

Ideally, the difficulty must be progressive in order to set a level for each. Level I will average, and I'll do an average on each question too.

If you had only 10 minutes and 10 questions to ask to a candidate, what would be your top 10 ?

答:
I believe in "self assessment"!
If you explain to the person the exact situation he will find himself, for example: "you will have to code SQL ... with database of 100+ tables and 500K+ records, which have to run under 4 seconds...". And if you ask him: "Do you think you can make it?" - you will get a correct answer.

I will spent 5 questions on the expectations of the students and 5 more technical:

What do you expect from this training?

What is your level (this should be domain specific)?

What do you want to see/learn during this training (point out 3 most important points)?

If we do exercises, what would you see more useful for you? (workshop, multiple-choice)?

What do you expect from the teacher?

Than you can go with some technical questions like (this should be according to the topic). for OOP for example:

What is encapsulation?

What is interface?

Polymorphism?

Sub-typing?

Dynamic binding?

Title: The 10 minutes technical interview


问:
Testcase runner for parametrized testcases
Let me explain my situation. I'm planning a kind of test case runner for doing testcases on external devices, which are microcontroller based. Lets consider the devices:

Device 1

Device 2

There exist a lot of test cases which can be run with one of the devices above. For example:

Testcase 1

Testcase 2

The main reason that all the testcases can be run with any device is, that the testcases validates some standard and this software should be extensible for future devices.

The testcases itself must be runnable with changing parameters. For example Testcase 1 does some Timing Verification the testcase needs as input parameter the datarate: 4800, 9600, 19200.

Now hoping you understand the situation, let me explain my design questions.

For implementing the test cases I thought about an Attribute based approach, like nunit does it.
The more complicated problem is, how to define the parametrized testcases?
Like this:

```<code>Device 1:
   Testcase 1:
      datarate: 4800, 9600, 19200
   Testcase 2:
      supply: 1, 2, 3

Device 2:
   Testcase 1:
      datarate: 9600, 19200, 38400
   Testcase 2:
      supply: 3, 4, 5
</code>```

How would you design such a framework?

I've done a similar desin in python where I had for every device a XML containing the testcase definitions like:

```<code><Testcase="Testcase 1" datarate=4800/>
<Testcase="Testcase 1" datarate=9600/>
<Testcase="Testcase 1" datarate=19200/>
</code>```

答:
Importing and reusing shared test projects should be feasible (especially if testing common data structures, or protocols).  However, more than likely and more ideally, that shared test project would test a shared production project with rather complete coverage, so there should be no need to repeat those tests.

Secondly, if behavior is essentially the same, but only varies by scaling factors, providing configuration to the test suite or fixture setup should be a reasonable option, like @tgkprog suggested.  The general xUnit patterns that demonstrate and provide rationale for this are most likely the Shared Test Fixture or a Data Driven Test.


问:
Functional as a first language
What are some pros and cons to learning functional programming before other paradigms?</p>

答:
The main advantage (or, non-disadvantage) of starting out with FP is that most concepts can apply to imperative programming as well.  Realm of Racket uses video game analogies to teach both functional and imperative concepts, and dedicated students are left with not only a functional game (n.p.i.), but a solid understanding of conditionals, recursion, loops, ADTs, and event-driven design.  These concepts are practically ubiquitous in modern programming and are used constantly.

Even more important, though, is learning how to encode abstractions, something in which FP excels, with the use of higher-order functions and data types.  How to Design Programs takes a unique approach to this by teaching through induction.  For example, students learn how fold works by looking at the code for taking both the sum and the product of a list, finding what they have in common, and deriving the implementation themselves.

The OOP equivalent of the above would likely involve one or more of the following: interfaces, abstract classes, generics, functors, or (if you're doing it wrong) singletons.  While these are perfectly acceptable design patterns in Java, IMHO they do not belong in an introductory curriculum and only serve to obfuscate the underlying principles.  Even as someone who was introduced to FP languages "late", I can say that navigating the ever-shifting sea of OOP has been made vastly easier by having a strong functional anchor.

Title: Functional as a first language


问:
What does "branching is free" mean in Git?
What does "branching is free" mean in Git?

I hear this a lot whenever Git is mentioned in comparison to other version control systems.

I haven't had the opportunity (?) to deal with others (SVN, etc.), so how is branching "expensive" in others?

答:
In Git, a branch is just reference to a commit to the local repo. Creating it is very cheap, no network at all. Not quite free (you've got to type a command), but damn near.

Branching isn't particularly expensive in SVN - it's just a copy, which is a very cheap commit. SVN does have a central repository model, so it's a network access, but not a horrible one.

In the venerable CVS, on the other hand, branching is VERY expensive. Basically, CVS branches involve adding a tag, but in CVS that means that EVERY FILE AFFECTED has to be modified. Each file is re-written to include the new tag. That's horribly expensive. And if your repository is big, it's also horribly slow. In fact, if you're on a big project, it's slow enough that some folks tend to avoid making branches if they can.


问:
Is it correct to fix bugs without adding new features when releasing software for system testing?
This question is to experienced testers or test leads.
This is a scenario from a software project:

Say the dev team have completed the first iteration of 10 features and released it to system testing. The test team has created test cases for these 10 features and estimated 5 days for testing. The dev team of course cannot sit idle for 5 days and they start creating 10 new features for next iteration. During this time the test team found defects and raised some bugs. The bugs are prioritised and some of them have to be fixed before next iteration. The catch is that they would not accept the new release with any new features or changes to existing features until all those bugs fixed. The test team says that's how can we guarantee a stable release for testing if we also introduce new features along with the bug fix. They also cannot do regression tests of all their test cases each iteration. Apparently this is proper testing process according to ISQTB.

This means the dev team has to create a branch of code solely for bug fixing and another branch where they continue development. There is more merging overhead specially with refactoring and architectural changes.

Can you agree if this is a common testing principle. Is the test team's concern valid. Have you encountered this in practice in your project.

答:
We use a hybrid approach. For customer release, we definitely have its own branch which are strictly for critical bug fixes only.

Regular development continues on multiple software versions. For example, lets say the latest stable release version is 2.0. All risky features will be added to 3.0 branch. Only bug fixes go into 2.0 branches. Testing by dedicated QA team is done only on stable branches. Customer releases are of course done from another branch based off 2.0. Long running features like the next gen platform development will be done in 4.0 not even 3.0.

All this looks good on paper. But if a customer wants a specific feature, it needs to be added to 2.0 branch itself since 3.0 is not stable enough to be released to customers. This means QA team will have to re-run the entire regression suite.

One thing we do is to do code coverage of each regression test case. Only those regression test cases are run which will be affected by the code changes for the feature. Of course, for a customer release, full regression suite is run.


答: The real cost of a branch is merging it. Git makes this easier than some other source control systems. See Stack Overflow question How and/or why is merging in Git better than in SVN?.

Body:
What does "branching is free" mean in Git?

I hear this a lot whenever Git is mentioned in comparison to other version control systems.

I haven't had the opportunity (?) to deal with others (SVN, etc.), so how is branching "expensive" in others?


答:
Another aspect of "free / cheap / expensive" is to do with how much is costs in terms of developer resources to deal with the downstream consequences of branching; i.e. the process of merging changes from branches.

And here, merging branches in DVCS systems like Git and Mercurial is easier than in older systems ... because the DVCS systems do a much better job of tracking the history of the versions in the graph; i.e. where previous branching an merging has occured.  This makes merges more accurate, reduces unnecessary conflicts and ... makes merging subjectively "easier" or "less scary" for the developers involved.

Title: What does "branching is free" mean in Git?


问:
APIs that deal with logins
I have been asked to make a mobile app for a friends website. The website is a Multi level marketing site that sells products and franchises. A client logs in in to the website and can view his or her dashboard ( user can view team members, business volume, commissions, invoices, etc.) The app is supposed to bring the dashboard to user's mobile devices (w/ some added features).

The company does not have any APIs that deal with interaction or authentication, and I am new to the whole secure login side of app development.  My questions is this, how do I let the users gain access to their information via my app from the secure website when there is no API?

答:
You'll need to understand several things to get the full picture. I'll try my best to help you understand.

They have to give you some API. The API's should take input using HTTP/S requests and give only data out in a format preferred by both(JSON/XML/CSV/other). Especially, the login part should use HTTPS so that the password and user name are not sent in plain text to the website. Once user keys in user name & password, they will be sent to server for authentication. Upon successful authentication, server should give you an authentication token or id that has a validity period(can be infinite also). After that, every request should use this authentication token. Indeed, the API should be designed that way to serve any account specific data only with an Authentication token. If the authentication token expires, then user has to login again to get a new token. This in a nutshell is the OAuth protocol(there is much more to it like clientID, client token). Google, Twitter, Facebook use this for their API.

If that site cannot give out API's, I can give you one terrible advice - Make your app work like a browser. i.e., Once you login, store the session cookie in the app and use it to request web pages. Then you scrap the web pages for the data you need and then display it in the app. Like I said, this is terrible advice, but a possibility that should be okay for minimal loads. For handling more loads/users, you should definitely go the API way.

Title: APIs that deal with logins


问:
What specific features of NHibernate cause it to be recommended for legacy database systems?
So, I've been evaluating Entity Framework and NHibernate (I'm not looking for an EF vs. NH battle here, though!).

One thing that I see come up very often is that NHibernate is recommended for "legacy"/brownfield database projects, and lighter-weight ORMs (Dapper, etc) are sometimes recommended for newer dbs.

I will be applying my ORM to a brownfield database.  What specific features of NHibernate make it so widely recommended for "legacy" dbs.  (I have never heard anyone say "here's why NHibernate is better for legacy DB's -- I really want to know that, so that I can evaluate NHibernate appropriately)

And by the way, what is the definition of legacy here?  Do people mean

"databases that are not well normalized"?

(or)

"databases that are being accessed through non-ORM means, such as SQL queries or stored procs?
(or)

not talking about the database at all, but referring to classic 2 tier systesms (or 2-tier web apps, where there is thick session state, and no application tier)?

(or)

Any database that is isn't a noSQL database?

If it's of any use the discussion.  I will be using this ORM to build distributed, multi-tier software.  So I think that a lot the stateful features in ORMs -- like change tracking, etc, will not matter to me very much.

答:
I'm not familiar with EF, so it's possible that what I'm about to mention exists in EF as well.

I'm working with Priority ERP, which has a legacy database. What does legacy means in this case?

No foreign keys

Sometimes being forced to create both a sequence numeric primary key and a unique key due to Priority ERP

Table and field names limited to 20 characters capital letters only

Fake floating numbers (field stores int 10500, actual value is 10.500)

Booleans are stored as one character varchar field, where "Y" is true, and anything else is false (and I do mean anything else, some Priority ERP procedures use empty string, some "N")

Dates and times are stored as number of minutes since 1-1-1988 (only minutes, no ability to store seconds)

Having to work with prebuilt tables that were built in the 80's and because of no foreign keys the relationship between the tables is awkward to say the least

Some tables have FIELD1...FIELD10 per row instead of a join table, which makes it impossible to do normal queries on the table.

No nulls allowed in any field

Every table, even with zero data, has an empty row filled with default values that is used as a replacement for outer join because of the no nulls setting.

NHibernate plus ActiveRecord enables me to support all those limitations pretty easily:

Built in extension points when handling CRUD operations

Ability to map the actual field contents on a field and convert it back and forth with a property

Letting me define almost any mapping between entities

Creating a custom query with HQL to do exactly what I need, even if I can't map the relationships between the entities


问:
In an online questionnaire, what is a best way to design a database for keeping track of users all attempts?
We have a web app where users can take online exams.

Exam admin will create a questionnaire. A questionnaire can have many Questions. Each question is a multiple choice question (MCQ).

Let's say an admin creates a questionnaire with 10 questions. Users attempt those questions. Now, unlike real exams users can attempt single questionnaire multiple times. And we have to keep track of his all attempts.

e.g.

```<code> +-------+-----------------+------------+-------+------------+----------+
 |User_id|Questionnaire_id |question_id |answer |attempt_date|attempt_no|
 +-------+-----------------+------------+-------+------------+----------+
 |1      |1                |1           |a      |1 June 2013 |1         |
 |1      |1                |2           |b      |1 June 2013 |1         |
 |1      |1                |1           |c      |2 June 2013 |2         |
 |1      |1                |2           |d      |2 June 2013 |2         |
 +-------+-----------------+------------+-------+------------+----------+
</code>```

Now it can also happen that  after user has attempted same questionnaire twice, admin can delete a question from same questionnaire, but users' attempt history should still have reference to that so that user can see his that question in his attempt history in spite of admin deleting that question.

If user now attempts this changed questionnaire he should see only 1 question.

```<code> +-------+-----------------+------------+-------+------------+----------+
 |User_id|Questionnaire_id |question_id |answer |attempt_date|attempt_no|
 +-------+-----------------+------------+-------+------------+----------+
 |1      |1                |1           |a      |3 June 2013 |3         |
 +-------+-----------------+------------+-------+------------+----------+
</code>```

Also, after this user modified some part of question, users attempt history should show question before modification while any new attempt should show the modified question.

How do we manage this at database level?

My first gut feeling was that,

For deletes, do not do physical delete, just make a question inactive so that history can still keep track of users attempt.

For modifications, create versions for questions and each new attempt refres to latest version of each question and history keeping reference to version of question at attempt time.

答:
A Few Things:

Each answer gets a Date Stamp. The typical DD/MM/YY HH:MM:SS type stamp will do nicely. Ensure you index this field.

When determining what answer a user gave, you search for the latest one.

Each question gets a Start Date, and End Date stamp.

You can now change questions and have the answers still be meaningful, as you can retrieve answers within the date range that's valid for that question.

For deletion, Simply marking that question as "Deleted" will suffice. And will keep the history regarding that question around for reporting purposes.


答:
The problem I see is that if such a program dies, we'll just say "Oh it's just another random termination - nothing to worry about".  But what if there is a real problem that needs fixing?  It will get ignored.

Programs already "randomly" fail due to developers making mystaykes, bugs making it into production systems, hardware failures, etc.  When this does occur, we want to know about it so we can fix it.  Designing death into programs only increases the probability of failure and would only force us to increase redundancy, which costs money.

I see nothing wrong with killing processes randomly in a test environment when testing a redundant system (this should be happening more than it is) but not in a production environment.  Would we pull a couple of hard drives out from a live production system every few days, or deactivate one of the computers on a aircraft as it is flying full of passengers?  In a testing scenario - fine.  In a live production scenario - I'd rather not.