答:
In a half hour you can judge a person's technical ability is at least as good as x.  That is, their ability might be higher than they demonstrated, but you can be fairly sure it's not worse.  If x is higher than your requirements, you hire them.  Yes, it's unfair if you demonstrate below your actual ability.  All I can say is get better at demonstrating.

If someone rattled off a practically memorized answer, I would give them a harder problem.  In academia memorization is an important skill.  In a job, it's mostly redundant when you have google right there.

Seeing how most great programmers are employed, it's safe to assume they passed a job interview at some point.  No, you can't tell if someone will be a great programmer from a half hour interview.  Fortunately, most companies don't need great programmers.  They get along just fine with solid, reliable programmers who aren't afraid to tackle tasks just outside their comfort zone.

The reason ground-breaking thinkers might flunk job interviews is that opportunities to solve flashy, ground-breaking problems are very rare, and you'll only be trusted to solve them after you've proven you can solve mundane, yet difficult problems your colleagues can't, like why the software crashes when it gets above 16% load.


问:
What does mathematics have to do with programming?
I just started a diploma in software development. Right now we're starting out with basic Java and such (so right from the bottom you might say) - which is fine, I have no programming experience apart from knowing how to do "Hello World" in Java.

I keep hearing that mathematics is pertinent to coding, but how is it so? What general examples would show how mathematics and programming go together, or are reliant on one another?

I apologize of my question is vague, I'm barely starting to get a rough idea of the kind of world I'm stepping into as a code monkey student...

答:
I'm by no means an expert at math! I did well in HS Geometry, which was all logic to me. I find programming and geometry to be very similar. Boolean logic ties very well in my mind to geometric proofs.

Then there's little things like knowing that you can control how many columns are in a row using the modulus operator.

I strongly favor the idea of being a good programmer who has a friend (or colleague / consultant) who is a good mathematician.

Obviously if you're blessed to have both skillsets, run with it!

ContentLicense: CC BY-SA 3.0


问:
Should I require users to register to use my app?
So I'm very close to releasing an app I've been working on, and the server I integrate with allows me to register users.  So I was wondering if I should require users to register with the app before they use it.  The app wouldn't "need" the registration for any of the features (although I have some ideas about future updates where the user's data could be saved to their account in the cloud), but it would still be nice to have a list of registered users.

One reason I think I should require users to register is because when the app launches for the first time, the user must accept my privacy policy and terms of use; so if I made a registration screen, it might be an easier and more straightforward, rather than bombarding the user with the thick legal language.

But I'm afraid requiring the user to register will cost me some users.  I once downloaded an app, and it wanted me to register, but I was lazy never did.  Is that a legitimate fear with requiring registration?

Thanks!

Edit:
To clearify, if I was to require registration, what info should I collect: name, email, password?  other?  And we wouldn't be spamming them with emails at all.  We also have a very strong privacy policy and would store all data securely.

答: It depends on your use cases. I think a great model is the StackExchange sites - you can get value without registering, but you get even more if you do. Also, registering is easier because with OpenID integration, you don't have any more credentials to remember.</p>


问:
Should I care about Junit redundancy when using setUp() with @Before annotation?
Even though developers have switched from junit 3.x to 4.x I still see the
following 99% of the time:

```<code>@Before
public void setUp(){/*some setup code*/}

@After
public void tearDown(){/*some clean up code*/}
</code>```

Just to clarify my point... in Junit 4.x, when the runners are set up correctly, the framework will pick up the @Before and @After annotations no matter the method name. So why do developers keep using the same conventional junit 3.x names? Is there any harm keeping the old names while also using the annotations (other than it makes me feel like devs do not know how this really works and just in case, use the same name AND annotate as well)?

Is there any harm in changing the names to something maybe more meaningful, like
eachTestMethod() (which looks great with @Before since it reads 'before each test method') or initializeEachTestMethod()?

What do you do and why?

I know this is a tiny thing (and may probably be even unimportant to some), but it is always in the back of my mind when I write a test and see this. I want to either follow this pattern or not but I want to know why I am doing it and not just because 99% of my fellow developers do it as well.

答: I always call it setUp because there is very little to be gained in terms of making my tests more informative. If I saw someone call setUp something else, I would expect that new name to be particularly important somehow because of the divergence from the standards.</p>


答:
It is better to avoid user registration because Registration costs some users as you think.
when it is mandatory rather than directly taking user to user registration page ,take to a intermediate page where you explain why registration is required and regarding what information to collect ,

collect as minimum information as possible.

Better if you provide login through third party like facebook,gmail or openID like stackexchange.but one problem exists with third party logins it(gmail,facebook) may not open in office networks.

```<code>We also have a very strong privacy policy and would store all data securely.
</code>```

you can communicate the same to user to create some confidence in him.

```<code>user registration decreases usability of your application.
</code>```

you might want to perform usability testing on your application.

Title: Should I require users to register to use my app?

Body:
So I'm very close to releasing an app I've been working on, and the server I integrate with allows me to register users.  So I was wondering if I should require users to register with the app before they use it.  The app wouldn't "need" the registration for any of the features (although I have some ideas about future updates where the user's data could be saved to their account in the cloud), but it would still be nice to have a list of registered users.

One reason I think I should require users to register is because when the app launches for the first time, the user must accept my privacy policy and terms of use; so if I made a registration screen, it might be an easier and more straightforward, rather than bombarding the user with the thick legal language.

But I'm afraid requiring the user to register will cost me some users.  I once downloaded an app, and it wanted me to register, but I was lazy never did.  Is that a legitimate fear with requiring registration?

Thanks!

Edit:
To clearify, if I was to require registration, what info should I collect: name, email, password?  other?  And we wouldn't be spamming them with emails at all.  We also have a very strong privacy policy and would store all data securely.

Body:
It is better to avoid user registration because Registration costs some users as you think.
when it is mandatory rather than directly taking user to user registration page ,take to a intermediate page where you explain why registration is required and regarding what information to collect ,

collect as minimum information as possible.

Better if you provide login through third party like facebook,gmail or openID like stackexchange.but one problem exists with third party logins it(gmail,facebook) may not open in office networks.

We also have a very strong privacy policy and would store all data securely.

you can communicate the same to user to create some confidence in him.

user registration decreases usability of your application.

you might want to perform usability testing on your application.


问:
Career guidance books for programmers
I am currently reading the recently published Being Geek by Michael "Rands" Lopp and I can't get enough of it.

Is there any other career guidance books aimed directly or indirectly at programmers that are worth reading?

答:
some books I can recommend.

1.code complete

2.pragmatic programmer

3.programming pearls

4.joel on software

5.mythical manmonth

6.coders at work for inspiration.

ContentLicense: CC BY-SA 2.5

Title: Career guidance books for programmers


问:
Does giving a developer a slower development machine result in faster/more efficient code?
Suppose I give my developers a screaming fast machine.  WPF-based VS2010 loads very quickly.  The developer then creates a WPF or WPF/e application that runs fine on his box, but much slower in the real world.

This question has two parts...

1) If I give a developer a slower machine, does that mean that the resulting code may be faster or more efficient?

2) What can I do to give my developers a fast IDE experience, while giving 'typical' runtime experiences?

Update:

For the record, I'm preparing my even-handed response to management. This isn't my idea, and you folks are helping me correct the misguided requests of my client.  Thanks for giving me more ammunition, and references to where and when to approach this.  I've +1'ed valid use cases such as:

- specific server side programming optimizations

- test labs

- the possibly buying a better server instead of top of the line graphics cards

答:
I work on a package that takes about an hour to build on my 8 core 8G machine (full clean build).   I also have a relatively low end laptop I test on.   The low end laptop doesn't manage two full builds during a single work day.

Am I more productive on the fast machine with some deliberate testing done on the laptop, or should I do all my builds on the laptop?

Keep in mind these are not made up numbers.

It is a rigged demo in that I don't normally need to do a clean build every day (I can do a lot of testing on single modules), but even the partial builds show roughly an order of magnitude difference in compile/link times.

So the real issue is on my slower machine a typical build is long enough for me to go get a cup of coffee, while on my faster machine I can only sip a little coffee.

From a point of view of getting work done I prefer doing development on a fast machine.  I can far more reliably hit deadlines.   On the other hand I imagine if management made me do development on my slow machine I would get a lot more web browsing done, or at least book reading.


问:
Java or Python for Google App Engine not knowing either language?
I have a few project ideas that I'd like to deploy on GAE. I'm interested in developing a logging application for amateur radio contacts, shortwave, and utility monitoring. More complex projects include satellite tracking, audio streaming from multiple radios, and radio remote control including transmitting and receiving.

I'm taking Java and Python languages through my local junior college, so I don't know which language is suitable for these projects. What are the strengths and weaknesses of each language for developing on GAE specifically, especially audio and number crunching for the tracking app? I'm not asking for a general comparison between the two languages, only as they are used on GAE. The end result is to tie them into my website which is hosted on Google, with some of the apps publicly available, some privately available to friends.

If it helps, I have the most experience with Perl, bash, followed by C.

答: Python is simpler. Since you specifically mentioned number crunching, select Python 2.7 (experimental version) of GAE which includes numpy (you can crunch a lot of numbers with it) built-in. Java has a lot of libraries but numpy is the defacto number-crunching package for Python. So if you develop it on Python, the code could be understood by almost any Python developer with numpy experience. And since you are new to both Java and Python, you would find Python much easier to learn. Regarding performance, Numpy is right up there with the fastest of implementations (Only a few libraries in C/C++ beat Numpy in terms of pure speed but speed also depends on GAE's implementation)</p>


答:
Imagine you live in a small town and you have two supermarkets.

The first one is across the street. You go there, you buy what you need, you pay for it, and you can leave with the products you've bought.

The second one is outside the city. You have to use your car to go to it, then you have to find a free parking spot (the parking being small, you have sometimes to wait for ten minutes or more for other customers to leave), then you have to travel by foot for five minutes, since the parking is not at the same place as the supermarket.

When entering in the supermarket, you have to register, which consists in providing lots of personal information about you, your bank account number, the age of your daughters, the list of things you're interested in, an address where advertisement will be sent (yes, it's mandatory), etc. Once registered, you wait for two days for your customer card to be ready, and then you can enter inside the supermarket.

Also, when paying for your products, they make a phone call to your bank to verify that your card is still valid. If they can't contact your bank, you have to wait until tomorrow.

Finally, each time you leave, you have to fill a questionnaire with your feedback about the supermarket. The questionnaire is ten pages long and all points are mandatory.

Which one of those markets do you choose?

The rule is: don't force the users to do things neither they, nor you need. If you provide a service to an end user, you must ensure the fastest possible access to this service (from UX point of view), with the fewest steps needed in order to use it:

If something can be done in one click of a mouse, don't force the person to do two clicks.

Don't force a person to fill 100+ fields in a form when you actually need only ten.

Don't force a person to spend two hours searching documentation when he needs to use a feature of your product he didn't use before.

etc.

Registration is a two way thing: when I register on Amazon, they have my e-mail account, and I can buy products on their website. Without registration, I can still see the products, but can't buy anything. When I register on Stack Exchange, I provide my identity to Stack Exchange, but in response, they provide me the ability to edit other people posts, comment, etc. As a guest, I can still see all the information and even post questions or answers. Through registration, I provide value to them, but I know perfectly well what I receive from them.

Forcing users to register just "because we can" is always bad. The users may want to ask two questions:

Is there something so valuable on your website that it worth my time I'll spent registering?

How do I know it's really so valuable?

On Amazon or Stack Exchange, those questions are easy to answer. For example, on SE, I know precisely that it's a valuable, high-quality series of websites, plenty of competent and smart people, just by reading the questions and answers I have access to as a guest. On Amazon, I know precisely that once I register, I will be able to buy this specific product I'm looking on right now as a guest.

There is nothing worse as starting a relation with a potential customer by "register first, then we will show you how useful we are for you". Show your product. Let us touch it, test it, see if it really matches our expectations. Let us ensure you provide value competitors cannot provide.

Last but not least: many customers need to know why are you asking them to do something:

If I know that a website costs money to a person, and the only way to keep the website is to show ads to the users, I will be more inclined to not block those ads compared to a situation when I paid for a service a large amount of money, and I'm still forced to see the annoying ads.

If I know you need registration because your application cannot work without identifying the users or because it allows you to gather statistics for BI, improving the service in the future, I would register. If I have no idea why you're asking me to provide my e-mail address, the first idea that comes to mind is that you're just intending to spam me.


答: IMHO, Coding Horror by Jeff Atwood, is the best programming blog out there. </p>

Title: Career guidance books for programmers

Body:
I am currently reading the recently published Being Geek by Michael "Rands" Lopp and I can't get enough of it.

Is there any other career guidance books aimed directly or indirectly at programmers that are worth reading?


答:
well for myself i would prefer an app where i don't have to register , simply cause just like you  I am lazy to fill in the registration form for a new app that i am not sure if i will really use or not

well i can give you better options

did you concider making registration optional until you really require it after your app updates and allow user to save their data in the cloud  ?

what about letting the user use their cerdintial from other services ( google login, facebook login, open ID)

in case of android phones i think you can get to know phones main google account and keep it as user registered to your app


答:
If you just want to keep track of whether or not they've accepted the license agreement, you can use a permanent cookie (or unique app id plus server side variable) to track whether or not they have accepted your agreement.

Of course, it won't help with multiple browsers, but depending on your user base and how your app works and is used, it may not matter.

Requiring registration for something that does not otherwise need user personal information is just going to drive down adoption.


问:
Should I nest functions in languages that allow me to do that or should I rather avoid it?
In JavaScript, PL/SQL and some other languages, functions can be nested, i.e. declared within another function. This could be used to break a large function into smaller pieces, but keep those pieces within the context of the larger function.

```<code>function doTooMuch() {
    function doSomething () {
       ...
    }
    function doSomethingElse() {
       ...
    }
    function doYetAnotherThing() {
       ...
    }

    // doTooMuch body

    doSomething();
    doSomethingElse();
    doYetAnotherThing();
}
</code>```

In some cases, when those smaller functions do not use local variables of the larger function, this could easily changed to a version where all functions are unnested.

```<code>function doSomething () {
   ...
}
function doSomethingElse() {
   ...
}
function doYetAnotherThing() {
   ...
}
function doTooMuch() {
    doSomething();
    doSomethingElse();
    doYetAnotherThing();
}
</code>```

Assuming that those nested functions are not to be used anywhere else, is it better to keep them within the context of the large function or is it bad because this is exactly what makes the large function, well, large?

答:
It is a matter of opinion, but I would avoid nesting functions unless it was actually a necessary and deliberate part of your design.

When you nest functions, in most languages, you end up with some sort of mechanical effect.  The most common, and interesting, is to close over the lexical scope of a variable that can be used inside the body, but others (eg: visibility of the function) also show up some of the time.

Those are typically awesome tools, when used right - but they are complex tools, because they can result in non-local or non-obvious effects when you first glance at the code.

If you don't use them, many people will read the code and not see anything doing that - so will assume they missed it, and look again, trying to work out why you did it that way, and not in a separate scope.

You also risk that future programmers will deliberately or even accidentally close over something they didn't intend to, by not noticing the risk right there.

Finally, if your function declaration declares a named function outside the scope of the enclosing function, just avoid it.  That is super confusing to everyone.

As to the final note: because individual functions help delimit code, nesting functions is less troublesome than a single giant function, but ultimately it does mean reading a lot more code to understand doTooMuch() - especially if you can hide code between the nested function declarations, or need to check that nobody did.


答: This is one of those questions that have no right answer and words like "personal preference", "team practice" come to mind. In my opinion, little functions (now here's another subjective thing) that aren't used anywhere belong inside their parent functions, especially when they can be unnamed.</p>

Title: Should I nest functions in languages that allow me to do that or should I rather avoid it?

Body:
In JavaScript, PL/SQL and some other languages, functions can be nested, i.e. declared within another function. This could be used to break a large function into smaller pieces, but keep those pieces within the context of the larger function.

```<code>function doTooMuch() {
    function doSomething () {
       ...
    }
    function doSomethingElse() {
       ...
    }
    function doYetAnotherThing() {
       ...
    }

    // doTooMuch body

    doSomething();
    doSomethingElse();
    doYetAnotherThing();
}
</code>```

In some cases, when those smaller functions do not use local variables of the larger function, this could easily changed to a version where all functions are unnested.

```<code>function doSomething () {
   ...
}
function doSomethingElse() {
   ...
}
function doYetAnotherThing() {
   ...
}
function doTooMuch() {
    doSomething();
    doSomethingElse();
    doYetAnotherThing();
}
</code>```

Assuming that those nested functions are not to be used anywhere else, is it better to keep them within the context of the large function or is it bad because this is exactly what makes the large function, well, large?


答:
Several points are raised by your question:

Why does your application need a privacy policy? Do you collect user's data?

What is your benefit of collecting name and email through registration? Isn't it enough to keep a copy of the invoices? or a count of downloads?

Many countries requires that you declare to the authorities any file that contains personal data. Do you plan to go through that process?

As others have mentioned, a registration process is a hassle for the users. I think this is a hassle for you as well.


问:
What is considered best practice for printing usage / help (--help)?
When writing tools for the CLI of UNIX, how should I make the program print out help and/or usage?

I usually use fprintf(stderr, "help text here");, but there are several issues with that.

First, I'm not sure, whether I should use stderr. Is that OK, or should I use stdout?

As you can imagine, the help text is quite long, depending on how many options the tool has. Now, I usually, just put several "strings like that\n" in the second parameter. This however, fills my source code with fifty or more lines of help text. It is not easy manageable at all. What should I do instead?

When a tool is not written in C or a C-like language, I tend to use here-docs where possible (most prominently with Perl). I can't use that in C, but is there something like that, that I could use?

I was considering putting it in a headerfile.h inside a #define HELP "help text here", I've never seen it in the wild, don't know whether I should actually use that.

Ideally, I could put the text in an external file, and include it. Using #include for that seems wrong, though. What should I do then?

The idea is, to have a help text, that is easily manageable. Having it inside the source code isn't really convenient.

答:
If I'd be you I'd just opened up sources of grep, tail, cat, your_other_favorite_unix_shell_command to see how it's done there. I'm pretty sure their ways are pretty well thought out and can be maintained by many people.

About stderr or stdout. It's really simple, if there's an error - write to stderr, if it's just info - stdout. For example, if I run your tool with wrong options, you might want to display an error, say Use --help for usage, this one belongs in stderr. If I run your tool with a valid option --help, please use stdout.

If it's your preference not to have long help strings near your code, don't. #define in a header file is perfectly fine, but it's really a personal preference. If I had to read the code of a command line tool I'd prefer its help string to be inside a file that handles options supplied by the user.


问:
Worst coding standard you've ever had to follow?
Have you ever had to work to coding standards that:

Greatly decreased your productivity?

Were originally included for good reasons but were kept long after the original concern became irrelevant?

Were in a list so long that it was impossible to remember them all?

Made you think the author was just trying to leave their mark rather than encouraging good coding practice?

You had no idea why they were included?

If so, what is your least favorite rule and why?

Some examples here

答:
All interaction with the database has to be done through stored procedures. It might make sense if we're living in 1997 and not 2010.

I just realized that this actually covers all the criteria of the original question:

Greatly decreased your productivity? CHECK. Please - just use an ORM.

Were originally included for good reasons but were kept long after the original concern became irrelevant? CHECK. The manager was a developer for a database server 1000 years ago and put this coding standard in.

Were in a list so long that it was impossible to remember them all? CHECK. This included 'as much logic should be stored in the database as possible'.

Made you think the author was just trying to leave their mark rather than encouraging good coding practice? CHECK. Keeps coming back to the manager being an ex-database server developer.

You had no idea why they were included? CHECK.


问:
Who extends interfaces? And why?
AFAIK, my class extends parent classes and implements interfaces. But I run across a situation, where I can't use implements SomeInterface. It is the declaration of a generic types. For example:

```<code>public interface CallsForGrow {...}

public class GrowingArrayList <T implements CallsForGrow>  // BAD, won't work!
                              extends ArrayList<T>
</code>```

Here using implements is syntactically forbidden. I thought first, that using interface inside <> is forbidden at all, but no. It is possible, I only have to use  extends instead of implements. As a result, I am "extending" an interface. This another example works:

```<code>public interface CallsForGrow {...}

public class GrowingArrayList <T extends CallsForGrow>  // this works!
                              extends ArrayList<T>
</code>```

To me it seems as a syntactical inconsistancy. But maybe I don't understand some finesses of Java 6?  Are there other places where I should extend interfaces? Should the interface, that I mean to extend, have some special features?

答:
In the case of generic type variables the compiler doesn't actually care if T is a class, an interface, an enum or an annotation. All it cares about is that it is a type with a given set of sub- and super-types.

And there is no reason to complicate the syntax just because in one other place (where you actually implement an interface) the distinction between classes and interfaces is relevant (for example if you implement an interface, you need to implement all methods it defines, but you don't need to, if you extend a (non-abstract) class).

Assuming for a moment that you'd have to write implements here, then you'd also need a separate syntax for enum values (instead of simply writing <E extends Enum<E>>) and annotations (which you can easily declare using ).

The only place where you need to write implements is at the point where you actually implement the interface. At that point (and that point only) the difference is important, because you must implement the methods defined in the interface. For everyone else, it doesn't matter if any given A is a base class or an implemented interface of B: it's a super-type and that's all that matters.

Also note that there's one other place where you use extends with interfaces:

```<code>interface A {
}

interface B extends A {
}
</code>```

At this point implements would be wrong, because B does not implement A.

Title: Who extends interfaces? And why?

Body:
In the case of generic type variables the compiler doesn't actually care if T is a class, an interface, an enum or an annotation. All it cares about is that it is a type with a given set of sub- and super-types.

And there is no reason to complicate the syntax just because in one other place (where you actually implement an interface) the distinction between classes and interfaces is relevant (for example if you implement an interface, you need to implement all methods it defines, but you don't need to, if you extend a (non-abstract) class).

Assuming for a moment that you'd have to write implements here, then you'd also need a separate syntax for enum values (instead of simply writing <E extends Enum<E>>) and annotations (which you can easily declare using <A extends Annotation>).

The only place where you need to write implements is at the point where you actually implement the interface. At that point (and that point only) the difference is important, because you must implement the methods defined in the interface. For everyone else, it doesn't matter if any given A is a base class or an implemented interface of B: it's a super-type and that's all that matters.

Also note that there's one other place where you use extends with interfaces:

interface A {
}

interface B extends A {
}

At this point implements would be wrong, because B does not implement A.


答: This question has no right answer, because neither choice maximizes encapsulation. If you nest them, they still have access to variables they shouldn't. If you don't, then other functions have access to functions they shouldn't. Either way, you lose.</p>


答:
I use stdout, because a help is not an error.

If this is a long help in C, I try to mimic here-docs:

```<code>printf("This is the help for MyWonderfulApp\n"
       "Options are:\n"
       "    --help: display what you are reading now\n"
       "    --quiet: output nothing\n");
</code>```

But most of the time I write a man page using nroff -man dedicated tags. The in-app help simply consists in refering to that man page.

Title: What is considered best practice for printing usage / help (--help)?

Body:
When writing tools for the CLI of UNIX, how should I make the program print out help and/or usage?

I usually use fprintf(stderr, "help text here");, but there are several issues with that.

First, I'm not sure, whether I should use stderr. Is that OK, or should I use stdout?

As you can imagine, the help text is quite long, depending on how many options the tool has. Now, I usually, just put several "strings like that\n" in the second parameter. This however, fills my source code with fifty or more lines of help text. It is not easy manageable at all. What should I do instead?

When a tool is not written in C or a C-like language, I tend to use here-docs where possible (most prominently with Perl). I can't use that in C, but is there something like that, that I could use?

I was considering putting it in a headerfile.h inside a #define HELP "help text here", I've never seen it in the wild, don't know whether I should actually use that.

Ideally, I could put the text in an external file, and include it. Using #include for that seems wrong, though. What should I do then?

The idea is, to have a help text, that is easily manageable. Having it inside the source code isn't really convenient.

Body:
I use stdout, because a help is not an error.

If this is a long help in C, I try to mimic here-docs:

printf("This is the help for MyWonderfulApp\n"
       "Options are:\n"
       "    --help: display what you are reading now\n"
       "    --quiet: output nothing\n");

But most of the time I write a man page using nroff -man dedicated tags. The in-app help simply consists in refering to that man page.


答:
Just my experience, no more :

I'm not mathematicien. I'm not a genius, just a autodidact.

... and after many years, I realize than I work with intuition

First I learned Pick (dead system) from scratch (alone with paper documentation and samples),

... after C, C++ for fun, and Java for work.

As you told about it, I can say that learning this language is not a mathematical problem (even if basic/minimalist algebra help you,) but a logical one.

Now many tools (like Eclipse) help and correct you : you have to focus to what you want to do, with only 52 reserved words ... and many libraries which have down work for you.

So if you like language, choose a Java project, study Pattern Design, UML, understand JVM and how use it with Bigloo and Scala, understand again and again during 10 000 hours.

Experience in Java give you well paid jobs, and for a long time in industrial big projects, and you will be able to switch to another environment because you are able to speak informatic, not mathematic.

If  understanding language (words, meaning, concept and other hided logical sciences like semantic, ontology, ..) is a good objective for your human person, for all your life, you can begin now.

Otherwise, experiment another way.

Best regards

Claude

Title: What does mathematics have to do with programming?

Body:
I just started a diploma in software development. Right now we're starting out with basic Java and such (so right from the bottom you might say) - which is fine, I have no programming experience apart from knowing how to do "Hello World" in Java.

I keep hearing that mathematics is pertinent to coding, but how is it so? What general examples would show how mathematics and programming go together, or are reliant on one another?

I apologize of my question is vague, I'm barely starting to get a rough idea of the kind of world I'm stepping into as a code monkey student...


问:
How can I justify my disclaimer of warranties license to a customer?
I'm selling software that lets users manipulate critical information.

In my licence contract (drafted by a lawyer specialized in this field), I've got a standard clause reading:

THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
  IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
  WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
  DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT,
  INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
  (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
  SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
  HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
  STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
  IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
  POSSIBILITY OF SUCH DAMAGE.

I've seen equivalents in almost every single software I've been using so far.

So far, all of our clients accepted that without difficulty, but now one potential client is contesting it. Actually he's telling me something along the lines of :

You mean that if I use your software to buy something at $10 from a
  third party company, and there's a bug in your software (as you don't
  guarantee there aren't any), and you transmit a $20 order, I shall pay
  the $10 difference, not you?

I'm a bit stuck between what seems like common sense on his part, and the fact that my insurance companies would probably not insure me for those kind of risks, and if you consider we're talking millions, not plain $, it doesn't feel comfortable being responsible for that kind of potential loss.

So far, the best answer I've come up with is that everybody does it in the industry (Microsoft doesn't guarantee that the mail you've sent using Outlook won't be altered, e.g., by turning all the $10's into $20's ...)

Any advice on how to handle this? (apart from doing our best to ship bug-free software, of course :p)

答:
I think you need to have a talk with a lawyer. Different jurisdictions have different consumer laws. In the UK there are a couple of statutes on unfair contract terms. I don't know whether your disclaimer would hold water or not (I've seen several contracts from large companies that would fall foul of the legislation).

If your lawyer says that your disclaimer is OK then you have various options to sell this to your customer. How about:

"While we make every effort to ensure the quality of our software, because of the complexity of all the different pieces of software in involved from the operating system, database, web server, browser etc, in practice it is almost impossible to determine which piece of software caused the bug". Eg if my software fails due to a bug in Internet Explorer (or whatever) it would be unfair to hold my company liable."

An alternative would be:
"try suing Microsoft, you can only get the price of the software back."

It rather depends on your relationship with the customer.

I was involved in a court case involving a crashing file server that corrupted a database for a company. It was almost impossible to prove that the company that installed it had been negligent even though they had not followed the hardware requirements for the software.

ContentLicense: CC BY-SA 4.0


答:
Inspire yourself from your target platform's internals

Have a look at the BSD's source code. For instance, here are the:

usage(void) for NetBSD's /usr/bin/uname tool [source]:

```<code>usage(void)
{
    fprintf(stderr, "usage: uname [-amnprsv]\n");
    exit(EXIT_FAILURE);
}
</code>```

usage(void) for NetBSD's /usr/bin/telnet [source]

usage(void) for OpenBSD's /bin/ls [source]

Have a look at alternatives

And decide for yourself whether they're better or worse. You can use Google CodeSearch to find others, like:

SkyLoad's usage [source]

As you can see, different style between these and the BSD systems integrated tools listed above. It doesn't mean you have to follow one or the other. But usually it's good to look around, and settle for the consistent solution.

A non-standard solution to the 50 lines of help...

If you don't like to avoid 50 lines of text, you could simply read the help from a text file (in plain text, or maybe directly parse the man's source if you created one). I find that a rather elegant way (as you can even look up the text doc), however for core systems programs that would make them inherently unsafe and introduce a point of failure. Other people will argue it's heavy for a usage or help message, but it's not like these are called in fast tight loops...

When in doubt, follow the giants.

Body:
Inspire yourself from your target platform's internals

Have a look at the BSD's source code. For instance, here are the:

usage(void) for NetBSD's /usr/bin/uname tool [source]:

usage(void)
{
    fprintf(stderr, "usage: uname [-amnprsv]\n");
    exit(EXIT_FAILURE);
}

usage(void) for NetBSD's /usr/bin/telnet [source]

usage(void) for OpenBSD's /bin/ls [source]

Have a look at alternatives

And decide for yourself whether they're better or worse. You can use Google CodeSearch to find others, like:

SkyLoad's usage [source]

As you can see, different style between these and the BSD systems integrated tools listed above. It doesn't mean you have to follow one or the other. But usually it's good to look around, and settle for the consistent solution.

A non-standard solution to the 50 lines of help...

If you don't like to avoid 50 lines of text, you could simply read the help from a text file (in plain text, or maybe directly parse the man's source if you created one). I find that a rather elegant way (as you can even look up the text doc), however for core systems programs that would make them inherently unsafe and introduce a point of failure. Other people will argue it's heavy for a usage or help message, but it's not like these are called in fast tight loops...

When in doubt, follow the giants.


答:
"If I gave you such a warranty, and I gave it to all my other customers too, probably I would be out of business very soon. All it takes is a single malicious customer who finds a bug and uses it to deliberately cause large fictive damages. Because of the complexity of software development, it's currently next to impossible to create software that doesn't contain any single bug.

But even if my software was perfect, other components of the whole system, like the hardware, the operating system, the libraries I use, the database system etc. could still contain bugs, and they most likely do; so whenever something goes wrong, you would probably try to make me pay for the damages, because I'm the only one who gave you a warranty and the problem eventually shows up in my program, since this is the frontend you are working with. Defending against such claims is something I simply cannot afford."

Title: How can I justify my disclaimer of warranties license to a customer?

Body:
I'm selling software that lets users manipulate critical information.

In my licence contract (drafted by a lawyer specialized in this field), I've got a standard clause reading:

THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
  IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
  WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
  DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT,
  INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
  (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
  SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
  HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
  STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
  IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
  POSSIBILITY OF SUCH DAMAGE.

I've seen equivalents in almost every single software I've been using so far.

So far, all of our clients accepted that without difficulty, but now one potential client is contesting it. Actually he's telling me something along the lines of :

You mean that if I use your software to buy something at $10 from a
  third party company, and there's a bug in your software (as you don't
  guarantee there aren't any), and you transmit a $20 order, I shall pay
  the $10 difference, not you?

I'm a bit stuck between what seems like common sense on his part, and the fact that my insurance companies would probably not insure me for those kind of risks, and if you consider we're talking millions, not plain $, it doesn't feel comfortable being responsible for that kind of potential loss.

So far, the best answer I've come up with is that everybody does it in the industry (Microsoft doesn't guarantee that the mail you've sent using Outlook won't be altered, e.g., by turning all the $10's into $20's ...)

Any advice on how to handle this? (apart from doing our best to ship bug-free software, of course :p)


答: You should tell him that if he wishes to pay for you to hire about fifty thousand CS professors to formally prove your program correct, then you'll waive it. Else, there's no way you could possibly guarantee it. That's just how software development works.</p>


问:
Change my way of thinking in preparation for functional programming
When switching to a functional style of programming after coming from procedural and OOP, what things do I need to know upfront about "this new way of thinking"?

How do you prepare yourself for diving in the FP world and get it first time around?

What are the basics to learn and set straight first?

答: You're going to need declarative thinking instead of the procedural "first do this, then do this, then do this..." way of solving problems. Understanding recursion might be good starting point, as it is a kind of sweet spot between procedural and declarative thinking.


答:
FP is based on lamdba calculus. You need to know that. Its a good starting point. Functions are everything. There is no concept of state (although you can fake it at a higher level).

In OOP,

a=1 a=a+1

is accepted. Not so in FP. You just can't assign the variable an another value.
If you want to learn FP for the long-term, learn Haskell. It's the most purest version of FP out there and its quite complicated too (I have just started learning it) but still worth learning it.

An Introduction to Functional Programming gives you a high level overview of what FP is all about.

Two caveats though

If you want to learn FP for jobs, then there aren't too much vacancies out there. Procedural and OOP still rules the job market. But FP can help you a lot in exploring new ways of solving a problem.

FP compilers aren't blazingly quick. Since FP is more concerned with solving the problem, you can't expect C speed. But still you can issue instructions to compiler(in Haskell) to speed up the execution process. The trade-off is you get a lot of time focusing on the program in hand rather than fire-fighting bugs.

Title: Change my way of thinking in preparation for functional programming

Body:
When switching to a functional style of programming after coming from procedural and OOP, what things do I need to know upfront about "this new way of thinking"?

How do you prepare yourself for diving in the FP world and get it first time around?

What are the basics to learn and set straight first?


答:
Get a copy of "Structure and interpretation of computer programs" and work yourself through the first chapter "Building abstractions with Procedures". Best introduction to functional programming I have ever had.

EDIT: If you want something more comparative, try "Seven languages in seven weeks" (disclaimer: this book is still on my TODO list).


答:
From your explanation you seem to have two options:

Have no registration and display your privacy policy every time the app starts

Don't display the privacy policy to registered users, unregistered users have to accept it.

You seem to be afraid of loosing users because a) they don't like to repeatedly accept the same legal terms over and over again; or b) they don't like to register. Why not offer them the choice? Make the registration voluntary, but offer them a better user experience (no 'nag screen') for it.

That way you will not drive away the ones who don't like to register, nor those who don't like the nag screen.


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

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

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

答:
Well from my experience so far I think the following things are absolutely vital:

Powerful development machine

Dual monitors (at least 22" or 24")

Decent chair

Unfiltered internet (I don't know how many useful sites I've seen blocked by WebSense)

The ability to decorate/furnish your workspace (it's amazing how much this can help you be comfortable/at east)

Good support servers for version control, wiki, backup, testing with other applications if your solution stack includes several, etc.


问:
why do some job posts say "high pressure environment"?
Why would there be any pressure if everyone knows what they are doing and the projects are accurately estimated? If there's pressure, or even high pressure, then it implies what they are currently doing is not working, why would any good programmer want to join a team like that? Are these kind of job posting failed at trying to show off or are they really just being honest? Or is there really some good reasons for having pressure?</p>

答: I've always considered this code for "we're under-resourced and have unrealistically aggressive deadlines."</p>


问:
Should developers enter bugs into the bug tracking system?
While developing (either features or bug fixes) I sometimes happen to discover bugs that are not directly related to what I'm working on.  What should I do in that situation.  Just fix it?  Try to remember to fix it later?  Write it down somewhere?  Or enter it into the bug tracking system?

I generally enter it into the bug tracking system and let the process play itself out (i.e. triaging, assigning, etc.).  However I have hardly ever seen another developer enter a bug.  (Why is that?)

答:
I think this is more a political question than a question about bestpractice.

does the bug-entry blame sombody?

can the customer read bug-entries and sees that there are aditional errors. Is this a reputation-issue for your company?

is this realy a bug or a feature you are not aware of?

who will be paying the bugfix?

In my opinion it is a good practice to add non trivial bugs into the tracker system but the management has to decide how to cope with this.

For non trivial cases you should not fix the issue without consultating somebody else to make shure that

this is realy a bug and not a feature

sombody else can test the fix and make shure that the fix does not introduce a new bug elsewere (regression)


答:
I think you get the point.

Good programmer don't work in theses companies, then company get less thing done (different studies show a difference of TCO going from 10 to 26 between devs, which is huge) and increase pressure, which lead to more good devs leaving.

Such a company will often cut on testing, QA or refactoring to reach unrealistic deadlines. Which lead to harder to meet deadline for the next release. This is a self maintaining process, and as long as the upper management doesn't want to break this trend, this is a recipe for disaster.

Note that 60% to 80% of IT project are considered as failure (see chaos report for precise numbers). And this has a lot to do with the behavior shown in the job posts you read.

This is often referenced as dead sea effect, and is a very real phenomena in the IT industry.

Title: why do some job posts say "high pressure environment"?

Body: Why would there be any pressure if everyone knows what they are doing and the projects are accurately estimated? If there's pressure, or even high pressure, then it implies what they are currently doing is not working, why would any good programmer want to join a team like that? Are these kind of job posting failed at trying to show off or are they really just being honest? Or is there really some good reasons for having pressure?</p>


答:
well the fact is most of the  times projects are never accurately estimated!

which will create high pressure !

also most of these companies have week teams which will create  system failures that will need you to work at midnight on short notice under pressure :)


答:
I would personally say, it depends upon the level of programming that is involved. The data models and the correlations between those, the programming algorithms involved. For eg: to write a program that outputs "Hello World", i see no requirement for familiarizing someone with Higher Mathematics.
The level of Mathematical involvement would depend upon the level of complexity of the problem that needs to be solved programaticaly.</p>


答:
Maybe the recruiters assume that someone who can stand, or even enjoy, a "high-pressure environment", would be more productive in that particular company.

It can actually be a correct assumption: an inferior developer, who's willing to take the pressure for the sake of keeping his job, may be marginally productive, while a good developer, who can afford to choose and thus, should he end up in such a joke company, would leave in no time and wouldn't be at all productive.


答:
There are disadvantages in both allowing and prohibiting such syntax, and those of allowing are far greater.

Just think of it.

Separation of interface and implementation is one of fundamental programming idioms. Because of that, syntax allowing to spell "interface implements something" would be about as bad as one using plus sign to denote multiplication of operands.

Title: Who extends interfaces? And why?

Body:
AFAIK, my class extends parent classes and implements interfaces. But I run across a situation, where I can't use implements SomeInterface. It is the declaration of a generic types. For example:

```<code>public interface CallsForGrow {...}

public class GrowingArrayList <T implements CallsForGrow>  // BAD, won't work!
                              extends ArrayList<T>
</code>```

Here using implements is syntactically forbidden. I thought first, that using interface inside <> is forbidden at all, but no. It is possible, I only have to use  extends instead of implements. As a result, I am "extending" an interface. This another example works:

```<code>public interface CallsForGrow {...}

public class GrowingArrayList <T extends CallsForGrow>  // this works!
                              extends ArrayList<T>
</code>```

To me it seems as a syntactical inconsistancy. But maybe I don't understand some finesses of Java 6?  Are there other places where I should extend interfaces? Should the interface, that I mean to extend, have some special features?


问:
Convince a lone developer to use a separate build tool instead of the IDE one-click build
In my years of programming Java and more recently Scala, I've never used Ant, Maven, Gradle or any of those build tools for Java.  Everywhere I've worked there was a build manager who took care of all of that -- I'd compile locally with the IDE for development and unit testing, then check in the source code and notify the build manager who did what was necessary to compile everybody's files for the shared environment.

Now that I'm between contracts I've been working on my own self-funded project and it's getting to the point where it could be good enough to actually make money.  I even have a potential investor lined up and plan to show them a beta version in the next few weeks.

But all along I just click the build button on the IDE, and it creates the Jar file and it works just fine.  Of course, the conventional wisdom suggests that I "should" be writing my own Ant/Maven/Gradle scripts and using that instead of the IDE, but what are the concrete advantages of that in my situation (working alone)?

I've done some reading about how to use those build tools, and it just looks like I'd be writing hundreds of lines of XML (or Groovy or whatever) to do to what the IDE does in one click (the IDE-generated Ant XML for the project is over 700 lines).  It just looks error-prone and time-consuming and unnecessary for my situation.  Not to mention the learning curve, which would take away time from all the other work I'm doing to get the product ready to show people.

答:
Benefits of Build Tools

It's a short summary just showing the tip of the iceberg, and you won't necessarily notice the important of all this unless you need to do with a combination of many projects, large projects and medium to big team. But if you have faith and try, you'll reap the benefits.

They facilitate your development lifecycle and as they allow you to:

organize and structure your projects consistently and effortlessly

re-use good practices across projects and easily and quickly kick-start them,

integrate multiple projets in a single build,

automate your continuous integration process,

share your project with others

without enforcing them to use a specific toolkit or IDE (apart from the build system),

and without surprising them as they'll expect a standard build

automate and facilitate the maintenance of your product

automate your product's release process

If We Apply this to Maven...

For those of you in the Java world and who use Maven, by reading this you naturally associated each point with:

Maven's structured project convention

Maven Archetypes

Materializing a project from SCM and reactor builds

Jenkins/Hudson/Bamboo/other support + Maven's support for integration testing practices

m2eclipse, native IntelliJ or NetBeans support - or mvnsh for the command line

versions-maven-plugin

maven-release-plugin, buildnumber-maven-plugin plugin and versions-maven-plugin

And of course, Maven (but other tools as well) gives you dependency management, and that's a huge time and space saver for you (factored to the number of people in your team) and your SCM.

Everything's Relative:

I'm using Maven as an example because I think it is the most comprehensive and "batteries included" build system, but it doesn't mean it's necessarily the "best". It does fit all the tickboxes listed above though, and when looking for a good build system, I compare it to this list and Maven. However, Maven is not always very flexible - it is however very extensible - if you deviate from your standardized process. It boosts your productivy in the general case (once ahead of the learning curve), not if you fight it.

OwnerDisplayName: Gigatron


问:
validating APIs
We have a series of hardware and we have decided on a common API to be given to the customer for use. The customer will use this API in order to program the hardware.
The API includes functions for establishing a connection with the h/w like X_Open,X_Close,X_SetConfig, X_GetConfig, no of hardware connected, error handling with the corresponding structs to be filled by the API or the customer.
The hardware will ofcourse be validated independently also.
What strategies can I use to validate this API ?
    We want to test this API i.e it works as expected for instance we are actually able to setConfig in the h/w or get no of devices on the bus or if the API function X_Open is called , the function is able to establish a connection to the hardware as expected or say API function X_GetNoDevices returns no. of present devices on the bus.
We want to validate that all API functions work as described to the customer</p>

答:
Essentially what you refer to is known as compatibility test suite, a set of sample applications that demonstrate reference usage of your API, along with documentation clearly describing expected behavior of these applications, allowing to judge whether API functions as intended.

When your API is modified or extended, you change your test suite accordingly by modifying / extending your sample applications and adjusting documentation for expected behavior.

Stuff like that is widely used in the industry, one example that immediately jumps to mind is Java TCK / JCK. Another example is Khronos conformance tests for OpenGL and other API implementations.

If you plan for a long term use of such test suite, it makes much sense to treat it as a separate software product, with version control, issue tracking, releases and such.

Title: validating APIs


问:
What are good strategies in C for dealing with pointer errors of this type?
In C, I often come across errors with code like this

```<code>prio_queue->head[index] = newEntry;
</code>```

Yields a " "Cannot assign Entry** to Entry* "
How do you prevent/debug errors of this type, in general?

答:
How do you prevent/debug errors of this type, in general?

This particular issue comes down to knowing the types of the respective expressions, and there are no shortcuts to that; either you know it or you don't.  The question to answer is why the types are different in the first place; that indicates that someone was a bit confused when they wrote the code.


答:
I rarely see it worded like this, but then such statements are buzzwords at best, and baseless drivel at worst.

I have seen jobs that were described as "fast paced" being some of the slowest, most uninspiring, brain decaying and insidiously boring jobs that could possibly be concieved for a human being.  I have also put LOTS of time and was significantly challenged at jobs where by the description in no way gave credit to the actual needs of the job.

You would make a mistake to put too much thought into wording like this.  You learn far more about a work environment and the responsibilities of a potential job by interviewing and in turn asking the interviewer important questions that help unveil the hidden mysteries and dysfunctions that they don't tell you about.


答:
It doesn't mean that much in most cases. After all, would a company really say that they have a work environment where their philosophy is "Mañana". It's one of those standard clichés that get throw into job listings by HR people, just like saying they want "highly motivated people" and that they offer "a competitive salary with a complete benefit package". </p>

<p>You'll need to find out from your interview exactly what kind of pressure a job is likely to have, if it's just HR-speak or if they really have time critical work that has to be done. For example, you may find out that they do a lot of client driven or time critical projects that need to be done very quickly, such as advertising campaigns or event planning. Or, you may find that the organization is populated with bullies and jerks who create ugly pressure. Or, it may be just HR-BS and the environment is a pretty typical development shop. </p>

Body:
It doesn't mean that much in most cases. After all, would a company really say that they have a work environment where their philosophy is "Mañana". It's one of those standard clichés that get throw into job listings by HR people, just like saying they want "highly motivated people" and that they offer "a competitive salary with a complete benefit package".

You'll need to find out from your interview exactly what kind of pressure a job is likely to have, if it's just HR-speak or if they really have time critical work that has to be done. For example, you may find out that they do a lot of client driven or time critical projects that need to be done very quickly, such as advertising campaigns or event planning. Or, you may find that the organization is populated with bullies and jerks who create ugly pressure. Or, it may be just HR-BS and the environment is a pretty typical development shop.


问:
Users creating instances from a template - is there a software pattern that corresponds to this use case?
I am looking into designing a system where users build a template item and then create many instances based on this template.They then need to be able customise each instance but I also need for them to be able to make changes to the template and have all instances updated. These items are fairly complex, each consisting of many components that will be stored in numerous database tables.

I see two implementation paths.

Store complete copies of the templates to create the instances and
migrate updates to the instances.

Store records only for the changes and build each instance from a combination of the template and instance changes.

I believe the first option would create a lot of unneeded extra data however the 2nd way introduces complexities in querying the data.

This seems like it has probably been implemented many times before but I am having trouble finding much reading material. Are there common names for data models or pattern options used in implementations of such systems?

Any advice on benefits or pitfalls of each option, other options, or implementation guidance would be useful too.

edit:

Sorry I may not have been clear. I was looking more for a name for the general architecture not a design pattern. It is the end users who create instances not developers.

For example the system might allow users to define templates to model manufacturing processes of many items. Then at different sites where facilities or requirements are different, the end user would would use one of these templates to define a process specific for that site. Things will be added, removed and modified for each site.

I believe I will go with option two mentioned above - storing only delta changes, not complete copies.

答:
If I understand you correctly, user creates few templates, then based on some template creates multiple "usefull" instance that change or add something and later changes the template and wants this change to be reflected in all instances based on such template.

I would call it data inheritance.

Because its like creating base class, inheriting it and then changing base class.


答:
A startup that rushes to the market must struggle to be faster than the competition. For such a company, it makes sense to create a high pressure work environment, since being there two months before others working on the same problem might make the difference between being the next facebook and being, well, a too-little-too-late service nobody remembers. Working in such a company might make you rich quickly, through stock options.

For a well established software company, constantly high pressure is a sign of bad management and/or greedy owners and therefore a red flag.


问:
Type mocking frameworks does not change coding practices from testability point?
Many people recommend that we should code against interfaces and avoid statics for testability.

Interfaces are not just for testability, they are sometimes a requirement. But sometimes we introduce new interfaces in application only for testability.

If type mocking frameworks help us to isolate dependent types, then why should we use interfaces just for the sake of testability?  Also, why should we avoid static members?

答:
You don't have to introduce new interface if you are 100% sure that the class you are mocking will not have polymorphous behavior in the future.

Say if you are mocking on a DatabaseHelper class which help you access data from SQL Server, and you are sure you(or your sucessor developers) definitely won't let it support any additional Database(MySql,Oracle,etc) in the future, you can mock the DatabaseHelper directly without introduce a new interface.

However, most of the time, you can't predict the future, so you'd better introduce an interface for future extension.

we don't use interface just for the sake of testability. It is the pursuing of testability that forces us to write extensible/maintainable code by introduce new interface.

Also, why should we avoid static members

Static members is global state variable in its essence . Code units that sharing/access global state are usually highly-coupled, which is a threat for maintainability, thread-safety, and isolated unit testing,etc.


答:
Man, there's a LOAD of venting in this thread :P

"everyone knows what they are doing and the projects are accurately estimated" is what everyone wants but you shouldn't forget that those teams weren't always like that. Every team starts off bad before it eventually gets better, so until it gets to this utopian state, pressure is normal. If it weren't then management would probably be guilty of asking too little.

I like the "high pressure" statement on the rare occasions when I see it because those are the teams that have seen the symptoms, even though they may not have all the answers. That is better than most of the other ads that have no clue at all.

So unless the competition is some great software house that I know of, odds are I would find this "high pressure" one interesting at the very least. There are less good teams in the market than good programmers and frankly, holding out for the best (assuming they want you as well) is pretty much a waste of time unless you don't have mouths to feed.

So in that sense, the phrase "high pressure" doesn't really deter me at all.


答:
If type mocking frameworks help us to isolate dependent types, then why should we use interfaces just for the sake of testability? Also, why should we avoid static members?

I think you answered your own question here.  Interfaces representing a testable component improve the testability of the component and by that measure alone it is preferrable to components with functionality or business logic that has static typing.  Unwarranted statics and singletons are far more difficult for the majority of mocking frameworks to work with.  This makes unit tests more complicated.

Besides the testability benefits, a component having an interface decreases coupling between components.  Components are modular and cohesive.  Component based design calls for the Interface as the contract between the defined behavior and the actor.  This aspect of a component makes them more substitutable. http://en.wikipedia.org/wiki/Component-based_software_engineering

Title: Type mocking frameworks does not change coding practices from testability point?

Body:
Many people recommend that we should code against interfaces and avoid statics for testability.

Interfaces are not just for testability, they are sometimes a requirement. But sometimes we introduce new interfaces in application only for testability.

If type mocking frameworks help us to isolate dependent types, then why should we use interfaces just for the sake of testability?  Also, why should we avoid static members?


答:
When Java 5, and in particular generics, was initially made available to developers who had registered an interest the syntax was quite different. Instead of Set<? extends Foo> and Set<? super Bar> it had Set<+Foo> and Set<-Foo>. However, the feedback was that it wasn't clear whether + meant more specific or wider (more classes). Sun responded to that feedback by changing the syntax, but within the constraint of not introducing new keywords, which would have been a problem for backwards compatibility.

The result is that neither is quite natural. As you observe, extends is overloaded to talk of classes "extending" interfaces, which isn't the language used in other contexts; and super is overloaded to mean "is a superclass of", which is the opposite direction of the relationship previously expressed by the keyword, i.e. referring to a superclass.

However, the fundamentals of what an interface is are not affected by this change, and it doesn't introduce special interfaces which are extended in a new way.

Title: Who extends interfaces? And why?


答:
"if everyone knows what they are doing and the projects are accurately estimated?" is a really big assumption. Usually that assumption is false if the company says it is a "high pressure environment".

And, yes, there are a lot of companies that fail to plan and have under-achieving employees. There are plenty of companies that don't fit that mold, you just have to maintain your own standards and refuse to work in these high pressure jobs.


答:
One of two reasons:

They want you to give up your social life doing 12 hour days and weekends for no extra reward to save a project that is late and over budget with the customer threatening to sue. Usually because the sales team promised extra features without running them past the developers.

The windows don't open and the staff suffer from flatulence.

I think it's 1.


问:
I have a bad memory. Is dynamic typing language+vim appropriate for me?
I am switching from C#+Visual Studio to Ruby+Vim for a few months. The only thing that I am missing from C#/Visual Studio is  intellisense, especially when I have a new ruby gem to familiarize.

As a programmer with a below-average memory like Joel, I miss the a happy time in Visual Studio that I can Ctrl+Space everywhere to get a hint list so that I don't  have to memorize a single method , whether it's name or it's parameter list.  I can even get it's usage/sample code at MSDN with only a press of F1.

So, ruby(dynamic typing language)+vim/TextMate programmers, when you are coding

Do you run google/gem API reference manual/irb/ri side by side with your vim/TextMate like me most of the time ?

or A Good memory is a must-have for ruby(or other dynamic language) programmers?

答:
I did not try it on my own, but this link may provide what you are looking for:

http://vootey.wordpress.com/2010/03/28/ruby-code-completion-with-vim/

(google for "vim ruby code completion" to find more links).


答:
Why?

Because they ARE high pressure.

Why?

Because, in IT terms, they do not know what they are doing, or more precisely, they do not follow good development practices, because someone outside of IT is in charge.

One of the problems we software developers have is that software is not a tangible, physical object. To non-IT people it is this wooly, obscure thing that just exists inside their computer.

But because they cannot touch it, they do not appreciate the intricacies that go into building good software.

So when you get these types of people "driving the bus", you soon get comments like:

just build it

we need it in 1 month

we don't need testers

They don't get it.


问:
Servicing background tasks on a large site
We're dealing with an interesting problem on StackOverflow.

We've got a whole bunch of little "needs to be done soon-ish" tasks.  An example is updating "Related Questions" lists.  What we've done in the past is to piggy-back those tasks onto some users' page loads.

This was never ideal, but it wasn't really noticeable.  Now that SO has passed the 1,000,000 question mark, those unlucky users are starting to feel it.

The natural solution is to actually push these tasks into the background.  There are two broad ways of doing this I'm considering.

1. In IIS as a custom Thread-Pool/Work-Queue

Basically, we spin up a few (non-ThreadPool, so as to not interfere with IIS) threads and have them services some collections we're shoving Funcs into.

The big pro here is simplicity.  We don't have to worry about marshaling anything, nor do we have to make sure some external service is up and responding.

We also get access to all of our common code.

The con is, well, that we shouldn't use background threads.  The objections I know of are all centered around starving IIS (if you use ThreadPool) and the threads dieing randomly (due to AppPool recycling).

We've got existing infrastructure to make the random thread death a non-issue (its possible to detect a task has been abandoned, basically), and limiting the number of threads (and using non-ThreadPool threads) isn't difficult either.

Am I missing any other objections to in IIS process thread-pooling/work-queues?

Moved to StackOverflow, as it wasn't really addressed here.

2. As a Service

Either some third-party solution, or a custom one.

Basically, we'd marshal a task across the process boundary to some service and just forget about it.  Presumably we're linking some code in, or restricted to raw SQL + a connection string.

The pro is that its the "right way" to do this.

The cons are that we're either very restricted in what we can do, or we're going to have to work out some system for keeping this service in sync with our code base.  We'll also need to hook all of our monitoring and error logging up somehow, which we get for free with the "In IIS" option.

Are there any other benefits or problems with the service approach?

In a nutshell, are there unforseen and insurmountable problems that make approach #1 unworkable and if so are there any good third-party services we should look into for approach #2?

答:
I have implemented this type of thing a few times. On windows, I set up a python command-line program that does something at various times. This program also exposes an xmlrpc interface on a port. Then, a scheduled-task job runs every minute and queries the xmlrpc interfaces. If they are not up, it tries to launch them. If it can't, it emails me.

The advantage is that the job that runs isn't cron or schedule bound. I have a process job that runs every seconds, but will wait longer and longer between starting a new job depending on whether it had work to do. Also, it can be used to act intelligently based on the result. Got a 500 error? Got a really long delay? Do something else. Notify another service. Etc.

And the same system works on unix, with minor modifications.


问:
Splitting 1 large object into 2 tightly-coupled ones - good, bad?
I have a complex object (call it BusinessLogic) which provides an RPC interface to semi-trusted users. The functions in the RPC interface have to decide which procedure to call, check authorisation for that function, perform some argument checking, and then call private functions to carry out the required functionality, and then return results to the caller.

I decided to implement this by having the RPC functions in a separate stateless object (call it AppInterface), to separate out the concerns somewhat, so that BusinessLogic just moves its own data around and AppInterface decides which methods on BusinessLogic to call to implement the functionality it exposes.

This works very well for the most part. However it feels a bit wrong to me. The BusinessLogic object has benefited from not having to worry about authorisation, argument checking, etc, which is good. But since the AppInterface implements all of its functionality in terms of BusinessLogic, it can just be a thin wrapper for some procedures (which makes me question its necessity) and is a complex wrapper in other procedures (which makes me wonder whether that complexity should be pushed back into the BusinessLogic, given that the BusinessLogic has all of the information needed to perform the task). It also means that AppInterface needs access to methods in BusinessLogic that would otherwise be private as nothing else uses them; think friend functions in C++. Finally, it means I can't effectively unit-test AppInterface without using a full BusinessLogic object as that is the only practical way to get valid output.

I am happy to leave the system as it is, as it works, but I am curious as to whether there are obvious improvements I can make to such a system.

(For what it's worth, I am using Python 2.7, in a primarily object-oriented style.)

答:
Having coupling between two objects is not good. Anyone would vouch for it. However, i think two coupled objects still makes it better than one monolithic objects any day.

The object split allows simplification on at least how the code is managed even if they are not truly independent to evolved.

As far as your elements are concerned, i felt the best bet is if you can successively reduce the back dependency of AppInterface over Business Object. A simple process that allows you to think that way, is to think of another Business object that needs to access the same AppInterface. Try to keep reasonably unique and different behavior/expectation of the second BO that will force to AppInterface to be as general purpose as possible.

You should never merge AppInterface back inside Business object, but try to make it as generic as possible.


答:
These times where they are only introduced for testability is incorrect.

As others have said, programming against an interface decreases coupling between components, and allows your code to be easily extendable in the future.

This in turn allows you to more easily test components in isolation.

While introducing an interface may give you slightly more work now, it is a good foundation for your software to be built on.


问:
Problems of multiple threads sharing/accessing the same data
I have been researching into when data is being accessed or shared by multiple threads within Java. And looking into the problems such as:

Thread Interference

Memory Consistency

Deadlock

Starvation

From this, solutions to solve these problems.

So far all I seem find to fixing these problems is by using a synchronizing method. Are there other alternatives to using a synchronizing method?

I have found most of this information from the sun Java tutorial.
Any recommendations on further reading?

答:
I would recommend looking into using immutable objects for shared data.  As much as possible, try to restrict access to mutated data to a single thread.

Some of the advantages:

no problems with memory consistency or thread interference since the shared data can't be changed

no need to use synchronized methods

Possible disadvantages:

can't update an immutable object

less efficient if you have to often create new copies instead of updating


答: You should check out the java.util.concurrent package of Java SE. There are plenty of options on keeping things synchronized. If that doesn't work for you, Google Guava has some interesting additions to this package.</p>

Title: Problems of multiple threads sharing/accessing the same data

Body:
I have been researching into when data is being accessed or shared by multiple threads within Java. And looking into the problems such as:

Thread Interference

Memory Consistency

Deadlock

Starvation

From this, solutions to solve these problems.

So far all I seem find to fixing these problems is by using a synchronizing method. Are there other alternatives to using a synchronizing method?

I have found most of this information from the sun Java tutorial.
Any recommendations on further reading?


答:
Have you had a look at atomic variables?

http://www.ibm.com/developerworks/java/library/j-jtp11234/

The author of the article Brian Geotz also wrote a very good book "Java Concurrency in practice"


答:
There are many techniques which don't require explicit synchronisation.

For example, if you keep all data local to each thread and communicate only via passing messages, then the synchronisation is performed implicitly by sending and awaiting messages.

Message passing systems have the advantage that they scale very well, since they don't require a unified memory architecture and there are formal techniques for detecting and preventing deadlock, for instance Communicating Sequential Processes (CSP) helps you formally reason about such systems.

Another option is the use of immutable data sets. If nothing can change, you never need to synchronise, because there will never be any chance that more than one thread will try to write at once.

You can even combine them, if one process creates immutable shared memory data sets, it can use messages to pass pointers to consumers of that data.

Finally, you could think in terms of higher levels of abstractions. Tie your processes together by BlockingQueue from java.util.concurrent and you don't need to think about the actual implementation of the Queue, you just produce them in with one process and consume them in another.

There is even a lower level of abstraction than synchronized, using primitives such as Semaphor.

In all, it is a rich and deep area to study, and understanding the pros and cons of each technique has the potential to make you a better programmer.


答: I think you should combine these objects and look for a different way to divide them, if your objects are that tightly coupled they shouldn't be separated that way and its just going to confuse future programmers why object A and B always have to be used together to get anything done.</p>

Title: Splitting 1 large object into 2 tightly-coupled ones - good, bad?

Body:
I have a complex object (call it BusinessLogic) which provides an RPC interface to semi-trusted users. The functions in the RPC interface have to decide which procedure to call, check authorisation for that function, perform some argument checking, and then call private functions to carry out the required functionality, and then return results to the caller.

I decided to implement this by having the RPC functions in a separate stateless object (call it AppInterface), to separate out the concerns somewhat, so that BusinessLogic just moves its own data around and AppInterface decides which methods on BusinessLogic to call to implement the functionality it exposes.

This works very well for the most part. However it feels a bit wrong to me. The BusinessLogic object has benefited from not having to worry about authorisation, argument checking, etc, which is good. But since the AppInterface implements all of its functionality in terms of BusinessLogic, it can just be a thin wrapper for some procedures (which makes me question its necessity) and is a complex wrapper in other procedures (which makes me wonder whether that complexity should be pushed back into the BusinessLogic, given that the BusinessLogic has all of the information needed to perform the task). It also means that AppInterface needs access to methods in BusinessLogic that would otherwise be private as nothing else uses them; think friend functions in C++. Finally, it means I can't effectively unit-test AppInterface without using a full BusinessLogic object as that is the only practical way to get valid output.

I am happy to leave the system as it is, as it works, but I am curious as to whether there are obvious improvements I can make to such a system.

(For what it's worth, I am using Python 2.7, in a primarily object-oriented style.)


答:
You're describing a layer relationship more than a coupled relationship.  Unless your BusinessLogic depends on and makes calls into AppInterface, it's not coupled.  Having a lot of dependencies on the layer below you is quite natural and unavoidable.  You don't worry about how much your BusinessLogic depends on a database layer, do you?

However, the fact that some calls are thin wrappers and some are thick leads me to question the reasons why some are so complex.  If it's just a different-looking interface to a BusinessLogic function, that should be moved into BusinessLogic.  If it's because some arguments are more difficult to validate than others, you should figure out a way to separate that concern.  Same goes for authorization.


答:
Effectively, with the contract you have today there's an implied risk that's assumed by all your customers (except the one you mentioned). Apparently the associated cost is acceptable, since they keep doing business with you, and even if in the future such bugs cause damages to them, the consumer base as a whole considers them bearable. That's effectively what happens in the software industry in general, and that's why such clauses are considered acceptable.

Now, theoretically, you could give to your customer what he's asking for - theoretically. What it takes is to have either insurance (as you mentioned) for possible damages, or a rigorous enough development process to validate the software behavior, most likely a combination of both. These things obviously increase your operational/development costs, and you'd have to increase the price you charge for the software. And we are talking about dramatic increases: For instance, according to a table from Software Estimation (p. 243) the most efficient way of removing defects is high volume beta testing, which is quite costly, and removes only 60%-85% of defects.

Is your customer willing to pay for such things? In some industries the customers are: aerospace, car embedded systems, etc. In others it is an unjustifiable burden.

The bottom line is: you can't provide what he wants for free. And the increase in price he'll have to pay won't probably be less than the provision he has to make to absorb the risk himself. That's why the rest of the customers accept the agreement.


答:
You could refactor the public interface of BusinessLogic into a separate base class IBusinessLogic, which provides all functions needed by AppInterface. When creating the AppInterface instance, pass it a IBusinessLogic object, which in your running system will be an instance of BusinessLogic.

For testing purposes, you are able to create a BusinessLogicMock class, which inherits from IBusinessLogic, too. Now you can easily unit-test AppInterface without providing a full-blown BusinessLogic object. This may be the form of decoupling you are looking for.


答:
A few things that help:

vim has auto-completion (Ctrl-n), though it is not syntax-aware

a tags file (generated by exuberant-ctags or another appropriate tool) helps tons: not only does it extend the auto-completion's vocabulary, it also allows jumping through the code file using the 'tag stack' - Ctrl-] takes you to the definition of whatever the cursor is on, Ctrl-t pops you back where you came from

consistent naming and a DRY coding style

a tiling window manager and multiple screens (I prefer to have at least three: one for the code, one for the running application, one for documentation)

Title: I have a bad memory. Is dynamic typing language+vim appropriate for me?

Body:
I am switching from C#+Visual Studio to Ruby+Vim for a few months. The only thing that I am missing from C#/Visual Studio is  intellisense, especially when I have a new ruby gem to familiarize.

As a programmer with a below-average memory like Joel, I miss the a happy time in Visual Studio that I can Ctrl+Space everywhere to get a hint list so that I don't  have to memorize a single method , whether it's name or it's parameter list.  I can even get it's usage/sample code at MSDN with only a press of F1.

So, ruby(dynamic typing language)+vim/TextMate programmers, when you are coding

Do you run google/gem API reference manual/irb/ri side by side with your vim/TextMate like me most of the time ?

or A Good memory is a must-have for ruby(or other dynamic language) programmers?


答:
I try my best to remember the following mantra:

Data in --> Transform Data --> Data out

or

TransformData(Data In)--> Data Out


答:
rubyMine is pretty amazing and shows a lot more suggestions and has much better auto-complete than Eclipse or netBeans.

Don't kick it until you try it! Free for 30 day trial anyway!


答:
Every object needs coupling. What you want to avoid is tight coupling. Does your BusinessLogic object break encapsulation, or depend upon methods being called in a specific order? If not, then it exists in a fine abstraction state.

Does the AppInterface depend too much upon the details of how the BusinessLogic object functions? Then you need to redesign AppInterface. Note that depending upon the agreed upon return values from functions is correct.

For your unittests, just properly document what "should" be returned by method calls, and build a MockBusinessLogic object. All the same methods, with only a return statement.


问:
What should I do with production error logs?
We have a PHP intranet site that we run with warning/error logging on (as it's not under heavy load and there's a number of bugs/bad code left to find). Because the site is relatively unstable and in active development, I've been clearing the production error logs when each new version releases so I get a clean look at what problems we're having. We usually don't release until all logged problems identified in the last production build are fixed.

I still keep Apache's error logs because our code shouldn't mess up Apache (and if it does it's a huge deal), so if something's wrong there I want to know.

I'm wondering what a good practice is here; our previous code base logged hysterically verbosely so I've been trying to limit the logs so it's actually usable information, but just clearing the logs seems suspect as well.

For reference, most of the logs are undefined variables because a past programmer liked to use if (!$var) instead of if (empty($var)). I've been eager to remove those entries since the application doesn't perform any unexpected actions but I would get dozens of the same warning daily until we fixed it. Those are also why I left warning logging on in production.

Should I keep all my error logs for future reference? Should I segregate old logs somehow and tag them to build numbers?

答:
If you are using them to eliminate the bugs being reported, then they are doing their job.

They are useful NOW in the identification of current bugs, but if they are all fixed then I'm not sure there is much value in keeping the old logs once issues from them have been dealt with.


答:
It's a code phrase for "We want young unmarried programmers who are willing to work completely unreasonable hours at the expense of having any personal life."

They can't say that explicitly in part because it is illegal to discriminate based on age and marital status.


答: I'd save them  and stick them in a zip file or some other archive.  Archiving should compress them, so they won't take a log of space, and they'll still be easily accessible if you want/need to review them.  Name the files after the release/deployment ID so it's easy to correlate them with the version of the software that produced them.</p>

Title: What should I do with production error logs?

Body:
We have a PHP intranet site that we run with warning/error logging on (as it's not under heavy load and there's a number of bugs/bad code left to find). Because the site is relatively unstable and in active development, I've been clearing the production error logs when each new version releases so I get a clean look at what problems we're having. We usually don't release until all logged problems identified in the last production build are fixed.

I still keep Apache's error logs because our code shouldn't mess up Apache (and if it does it's a huge deal), so if something's wrong there I want to know.

I'm wondering what a good practice is here; our previous code base logged hysterically verbosely so I've been trying to limit the logs so it's actually usable information, but just clearing the logs seems suspect as well.

For reference, most of the logs are undefined variables because a past programmer liked to use if (!$var) instead of if (empty($var)). I've been eager to remove those entries since the application doesn't perform any unexpected actions but I would get dozens of the same warning daily until we fixed it. Those are also why I left warning logging on in production.

Should I keep all my error logs for future reference? Should I segregate old logs somehow and tag them to build numbers?


问:
Do we need "obvious" Method Documentation information?
I know we have questions about comments in general but I'm specifically wondering about Java Doc style method documentation here.

I've been pruning unnecessary comments as I refactor and I've noticed our code has painfully obvious descriptions of methods.

```<code>/**
* @name save
* @desc Validates and saves submitted daily plant production information.
*/
</code>```

Most of the "documented" functions are just method names used by convention in our MVC framework (CakePHP). It's inherently obvious that the save method in the Production Controller performs the necessary actions to save Production Information.

We don't actually use Java Doc and I question the value of these descriptions even if they were included in Java Doc style documentation. The only reason I haven't touched these because they're method documentation that's supposed to be valuable. The method documentation also hasn't been used consistently, about half of our Controller/model methods are documented.

Is there any reason to keep these obvious "Java Doc" comments or should I prune them in favor of "self documenting code" and only make Java Doc comments for less obvious methods?

答:
Your question is should I prune them in favor of "self documenting code"

Ignoring the inevitable argument of their value, you shouldn't remove them if they are already there. If they are bothering you, change the code folding settings in your IDE.

You don't need to worry about having to edit in two places on a change (code/comments) as you would need to add Javadoc anyway if methods such as 'save' did anything that is not obvious in the method signature.


答:
I ran into something similar with python. I wanted vim, but I also wanted IDE features. So I ended up rolling my own with vim plugins.

For what you want, get supertab for easy autocomplete, including dynamic method completion. Not quite as effective as an IDE, but it works. Also get snipmate for snippets.

Finally, get ConqueShell. That's very important, because it allows you to run a ruby shell inside a vim buffer! Don't know what command to use? Flip buffers, and test it. There should also be built in method help and autocompletion provided by the ruby shell.

I use conque for running ipython, which works great. I can even navigate the buffer and use vim's yank syntax for copying into a code window.


答:
Logs are a useful source of information. Though a lot verbose, they are really good for researching and zeroing in on a problem. My suggestion would be

Use a bug-tracking system to track frequent errors. Trac is a good way to start. Though the error logs are large, it would be caused only be a few bugs. A bug-tracking system would help you to track bugs in a compact manner.

Archive your error logs in a different database. SQLite is a good choice. If your error logs are extremely big, I prefer a key-value database such as Redis or a hierarchical database such as HDF5. You can always use queries to extract data

Track the bugs with your error log report for better control. Assuming a page not found error has been hit 100 times and the bug being the page misspelled, you have Bug1 occurrence 100 times. This would make it accessible to all so that errors can be quickly ironed out. Though its a bit difficult, its a better long-term solution.