答:
TFS? Run for the hills! Move off as quickly as you can. It does a lot of different things but none of them as good as the available best of breed tools.

But seriously:

Once you have a decent version control system (SVN, GIT, etc.) I'd recommend setting up rules for branch management, e.g. when to create branches, for what, when to merge, who, and a lot more.

Until recently we used a single branch for new development ('trunk'). For a release we would create a branch off trunk. Final QA would be done in that branch and once completed we would release (we are on monthly releases).

We have switched to the concept of 'no junk in the trunk' to reduce the schedule risk. This concept basically contains a rule by which you'd create branches for development work separate from trunk. For example you could have a separate branch for a feature, for a small development team or similar. We use 'epics' to describe a small feature or releasable part of a feature and create a branch for each epic. At least once a day all changes from trunk are merged into the epic branch. Key is good merge support by version control or a separate tool (e.g. three way merge). QA for the epic would be done on the epic branch. Once passed the epic branch would be merged into trunk and an integration test be run. We still have branches for releases.

With the epic branches we have substantially reduced the schedule risk as we are now in a position to release out of trunk and include all epics that were successfully merged into trunk. Epics that are not complete miss the bus and will make the next release (next month).

This of course may work only in our environment. Very likely you will have factors different from ours that will influence what the best choices are for branch management.

For example if you have a team with a lot of people working remotely and not always being connected to the version control server, then you would want to use a version control system that supports a distributed model. GIT and a few others would fall into this category. TFS to the best of my knowledge requires a connection to the server to just make files writable (fixed in version 2010?).

I hope I was able to show that there is not "one size fits all". Start with your processes in particular branch management, determine the requirements and finally select the tool that is the best match for your needs. Maybe it is TFS, maybe not.


问:
How can I properly manage commits, prevent feature conflicts, and manage dependencies with a VCS?
It’s become an annoying factor of working with large teams: how do you manage checkins and prevent feature conflicts and manage dependencies with source control properly?

Currently at my workplace we use TFS 2008 and we're migrating to TFS 2010 in early December. Firstly any source control is better than none but what approach has anyone found useful to prevent multiple checkins and rollback all over source control history? Is a volatile trunk the best way to go or branch off when your implementing a new feature and once you're happy merge back into the trunk?

I'd really like to hear other people experiences and perhaps some best practices to managing source control.

答:
how do you manage checkins and prevent feature conflicts and manage dependencies with source control properly?

It is, from my POV, two-factors task: you have to do it from technical (good&easy&bullet-proof branching|merging|audit etc) and management (well established policy "what" "when" "how") sides. Two or even three tiers of separation code in ALM: something like "stable" (passed  unit testing), "unstable" (every included feature finished, but app as product have post-integration questions /yes, it can happens/) and "work in progress". This way proper Project Manager can decrease interference of separate developer's work in common.

TFS (which I don't used, use and will not use) have some, AFAIK, fundamental problems in in its aspect of Source Control Management. I just link here to some of James McKay's texts:

Team Foundation Server is the Lotus Notes of version control tools

Baseless merges in Team Foundation server – why?

ContentLicense: CC BY-SA 3.0


问:
I can't remember programming 5 mins after learning?
I'm learning Java, and I found a great teacher. He explains everything perfectly. I understand it all. My problem, is that after learning a short section, for example "Nested If Statements" or "Many Methods and Instances", I can type it all great, but in 5 mins, after going on to a new section (when I'm comfortable with the last section) I forget the code to type for the last section. Any tips or techniques you guys use to remember code????

答:
The way to learn is to practise; to write code; to get annoyed and frustrated by forgetting by mistyping a single variable :D

Pick up a problem and try to solve it; soon you'll be writing code without worrying about syntax.

OwnerDisplayName: Cole


答:
Maybe writing software is not for you.

When I was 13, I was writing in AppleBasic and Pascal. Programming made perfect sense to me.

It's the opposite with electrical engineer topics. In one ear and out the other. I never learned much in my EE classes, and I quickly realised I was never good at it.

That's why I'm a software engineer now instead of an electrical engineer.

Title: I can't remember programming 5 mins after learning?

Body: I'm learning Java, and I found a great teacher. He explains everything perfectly. I understand it all. My problem, is that after learning a short section, for example "Nested If Statements" or "Many Methods and Instances", I can type it all great, but in 5 mins, after going on to a new section (when I'm comfortable with the last section) I forget the code to type for the last section. Any tips or techniques you guys use to remember code????


问:
Which popular object-oriented languages support readonly methods?
I thought that many object-oriented languages have a reserved keyword for methods which do not modify the state of an object. These methods often have names that start with get. AFAIK a "getter" is always related to a single object attribute and "accessor" is too general, so "readonly" may the right term for this kind of methods (?). To give an example:

```<code>object Timespan {
    attribute start
    attribute end

    // getter, not changing the state
    readonly method getStart    { return start }
    readonly method getEnd      { return end }

    // also not changing the state
    readonly method getDuration { return ( end - start ) }
}
</code>```

The compiler/interpreter should check that readonly methods have no side-effect by modifying object attributes. I wonder why this language feature is not more common - just naming a method getFoo does not ensure that it won't modify the object.

答:
What you want is const of C++. I generally find it extremely useful and don't understand why other languages don't have it, but they don't. The only other language I know to have something similar is D, but the differences in semantics, while making it more useful to optimization, make it less useful for restricting interfaces.

In other languages like Java and C#, the only thing you can do is create an interface with the constant methods only, implement it in the object and downcast to that interface if you want to pass the object but not allow modifying it. Unlike C++, you won't get compiler checking the methods are in fact constant.

While the interface will serve the ultimate goal of being able to pass the object by reference and still being able the other code will not modify it, using an interface means always incurring the virtual call overhead while in C++ it's purely compile-time affair.


答: It's all about practice. The best way to learn programming is to build project alongside, and improve it every time you learn something new.</p>


问:
Why are there so many competing filesystem designs?
Just a quick question, but why are there so many file systems still competing and in use today? (ntfs, fat32, ext3(ffs), etc)

It seems that file system designers could agree upon the best aspects of each type of system and implement a "best" filesystem, no? Just a thought, since these filesystems have been around for a while now, and it should be at least somewhat apparent which ones have good qualities over others, and we could just combine the good in each and create an ultimate system that is much better

答:
I think that ZFS (use by Solaris in Sun system [now Oracle]) is THE solution for file system.

Unfortunatly Oracle close OpenSolaris for discoverer and test it.

ZFS is open source, some Linux are trying to integrate it, look in Wikipedia for more informations.


答:
My advice is that you find yourself a small but concrete project. If you want to practice if statements, implementing some kind of classification quiz could be a good excercise: the program asks the user to choose an animal out of a given list, and then asks questions like "Is it a mammal?", "Is it a bird?", and tries to guess what the user has chosen. One way to implement this is using a lot of nested if-statements.

Then you have to struggle through the project from specifying the program behavior, to coding, testing, debugging. Any time you do not remember the syntax or semantics, you go back to your book, read your notes, try to understand compiler errors. When you are finished and your program is working as expected, I am quite sure that you have learnt if-statements (and some other stuff as well).

This is at least the only method that really works for me when I want to learn a new programming language. For example, I have been trying to learn Haskell for the last two years, but just reading the book and writing small pieces of code is not enough: I keep forgetting stuff. Then I had the possibility to write a small tool (in Haskell) at my company, and I really learnt a lot.


问:
What's the difference between syntax and semantics?
I've always thought that referring to the syntax of a language was the same as referring to the semantics of a language. But I've been informed that apparently that's not the case. What's the difference?</p>

答:
Semantics ~ Meaning

Syntax ~ Symbolic representation

So two programs written in different languages could do the same thing (semantics) but the symbols used to write the program would be different (syntax).

A compiler will check your syntax for you (compile-time errors), and derive the semantics from the language rules (mapping the syntax to machine instructions say), but won't find all the semantic errors (run-time errors, e.g. calculating the wrong result because the code says add 1 instead of add 2).


答: Try to explain what you just learned, it doesn't matter to whom (it can be the famous rubber duck), just be serious and patient, and don't leave out things that are "obvious", but pay attention to the details. You'll find out that you still have gaps, and that you need to go back to things you thought to have understood.</p>


问:
Could I learn more about programming from deconstructing drupal rather than continuing with ZF?
When I was deciding how to go about learning to design PHP web applications, it made sense to sort of shoot toward the middle and go with Zend Framework so that I could be closer to the lower level, but I would be able to get down to business fairly easily, too, while learning about design patterns, etc.

That seemed to work out pretty well, but now I'm wondering if I wouldn't have learned more about design from a more top-down approach, like creating a drupal site and deconstructing it.

I realize that the degree of topness vs. bottomness in this context is pretty negligible in the spectrum of all programming experiences, but I think it matters very much where you start, especially at the very beginning, because your world is small; it's home base, and how you develop your personality there "at home" can determine how you approach other problems in the future--I believe people tend to try to repeat their successes, which often means adopting a preference for what's familiar to them.

I didn't want to "learn myself into a corner," so to speak, so I tried to aim for a level that would prepare me for the greatest amount of other experiences. LAMP with ZF seemed like a well-rounded, holistic choice, because I'd be learning about database design, patterns, web app development, server configuration, and a C-based programming language all at once.

Okay, great, but I haven't really progressed as far as I had hoped I would, honestly. And now I'm starting to wonder if I've done myself a disservice for wanting to start nearer to the bottom vs. learning to produce as much as possible right away. My instincts at the time were that, "sure, a CMS will get you up and running, producing stuff right away, but you'll eventually hit a wall and need to learn the lower-level stuff anyway, and you'll probably hit it sooner than later so you might as well start there. Don't eat dessert first."

But now I'm thinking "what would have stopped me from digging into the gears of a CMS?" Maybe I would have learned more from seeing a more complete implementation and deconstructing it rather than reinventing the wheel. Or, I could be exactly where I should be having only started in December?

And I just don't know the answer. I want to start a new project (redoing my website--I'm actually a composer (of music)). I know the basics of Zend Framework, and I'm fairly sure I could code a simple CMS for myself for my purposes, but would I learn more from deconstructing an out of the box CMS like drupal?

答:
For me I started getting in to programming when I was a freshmen in highschool after being sent off to bording school and having nothing to do with my free time. I bought a domain name and some godaddy hosting And started making a website. At first It was HTML static pages and realised that this would not work I then moved on to hosted forums but I was not really able to do anything with it. I moved on to working with PHPBB. I installed a blank copy and followed instuctions on how to install add-ons. As everyone knows back in the day adding addon-s was opening the code and copying and pasteing and replacing lines of code. You learn your own method of commenting out lines insted of deleting it. And when you have to plugins that need the same function you have to learn how to merge them together into one working plugin. In the end the website was small but it was my baby i had maybe 20 people that used the website all the time we were not concered about making the website big but just having fun and I was the only person working on it. As time went on i learned how to connect my own outside custom code to the user system And all sorts of other things.

The point of the story is not really about what tool you use to learn how to buld an application but how deep you go into the application. In the end the app that you make will need to be programmed and you are going to need to know how the framework is working from top-down and bottom-up because you will need to be able to find erros. My final advice is dont be afrid to make your own framework and make it meet your needs and always learn about secirty and learn how the other guys keep there stuff nice and tight.


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

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

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

答:
A Bench Outside

Seriously, sometimes the grind gets heavy, a problem is too hard, and you just need sunshine, air, and a moment to think while listening to cars drive by.  Nothing like a quiet place just off to the side of the building to go and think for a moment.

ContentLicense: CC BY-SA 2.5


问:
Scrum taskboard with QA stage
I've been reading this article by Mike Cohn about Scrum task boards.

One query I have is how this fits into a workflow where there is QA stage performed by testers who aren't developers.

It seems that many tasks could not easily be QA'd in isolation.

A practical alternative could be that the "To Verify" process should be carried out by another developer in the team, and then to have an additional stage after DONE to QA the whole story (probably after deployment to a stage/test environment).

Does this seem right?

答:
Actually yes, your point of view is correct.

During the sprint developers must verify that completed users story meets acceptance criteria (definition of done). This should be done by writing automated tests. Product owner must also verify that the user story really meets his expectations and after that it is considered as done and can be presented on review meeting. After the sprint you have shippable increment of your product and you can "ship" it to QA where more intensive testing can be performed - this is actually collecting of feedback because QA can find bugs or some missing or inconsistent features and forward this feedback back to team or product owner. QA can also provide feedback to usability of UI.

QA in this scenario is not part of the team but it doesn't mean team doesn't test their code! QA acts as "end user" or "customer" providing feedback to shipped increment.

Title: Scrum taskboard with QA stage


问:
Java/C# - When should AOT be considered if reverse engineering is a concern?
Long and short is really in the question title.  For a language which compiles to an intermediate language like MSIL or Java byte-code, if there's concern about something like reverse engineering or hacking to disable security features, should AOT (ahead of time) compilation be considered rather than just obfuscation?  Obviously, there's a bit of wiggle room in this question as there's no one answer I wouldn't imagine, but when would you start looking at performing an AOT compilation before distributing something versus sending it out obfuscated?

For anyone that stumbles across this and isn't familiar:

Wikipedia Entry on AOT Compilers:  http://en.wikipedia.org/wiki/AOT_compiler

Mono AOT Compiler feature:  http://www.mono-project.com/AOT

答: Don't distribute.  Expose via the web or something like Citrix.  Bloomberg have built a multi-billion dollar business doing that and their users love it.  (Well we don't seem to be able to provide much comfort with AOT or Obfuscation).</p>


答:
Actually there are not two levels but three:

lexical level: how characters are combined to produce language elements ( i and f produces if)

syntactical level: how language elements are combined to produce language expressions ( if, (, 42, ==, answer and ) produces a conditional statement)

semantic level: how language expressions are converted to CPU instructions in order to form a meaning (a conditional statement allows to execute one branch or the other depending on the result of the boolean expression)

Title: What's the difference between syntax and semantics?

Body: I've always thought that referring to the syntax of a language was the same as referring to the semantics of a language. But I've been informed that apparently that's not the case. What's the difference?</p>


答:
A method that does not have any observable effect on the state of the object is commonly known as a "pure" method. The key word here is observable. In the case of lazy instantiation or caching - these effects would not necessarily be observable to the consumer, so the method would still be considered a pure method.

In C# (and other languages which support meta data), you can declare an attribute on a method which marks it as pure, and static analysis tools can be used to warn you if it isn't (or more usefully, if it regresses from being pure).

see: http://msdn.microsoft.com/en-us/library/system.diagnostics.contracts.pureattribute.aspx

Title: Which popular object-oriented languages support readonly methods?

Body:
I thought that many object-oriented languages have a reserved keyword for methods which do not modify the state of an object. These methods often have names that start with get. AFAIK a "getter" is always related to a single object attribute and "accessor" is too general, so "readonly" may the right term for this kind of methods (?). To give an example:

```<code>object Timespan {
    attribute start
    attribute end

    // getter, not changing the state
    readonly method getStart    { return start }
    readonly method getEnd      { return end }

    // also not changing the state
    readonly method getDuration { return ( end - start ) }
}
</code>```

The compiler/interpreter should check that readonly methods have no side-effect by modifying object attributes. I wonder why this language feature is not more common - just naming a method getFoo does not ensure that it won't modify the object.


答:
I am a dedicated tester that works on a Scrum team working on a web app. What we do with regards to QA tasks on the taskboard, is we first choose the user stories that are to be tackled in the sprint. We then split those stories into sub-tasks, and add in two sub-tasks for QA: to develop acceptance tests and to run them. The task to develop the tests can generally start immediately and in tandem with the engineering tasks, and the task to run the acceptance tests is performed once the engineering work has been completed on the story. It should be noted that the engineering team also has an acceptance test task which is performed on a local machine deployment, and the QA team then performs the more in-depth testing on a deployment closer to production.

It is not useful for the QA team to attempt to test every task the engineers do, as much of it can be refactoring or such small pieces of functionality that it is much better to take as a whole. All commits go through code review anyway. It would waste a lot of time going back and forth between the QA and Eng teams asking how to test things and being told that the functionality is only on the backend and would not be visible to the user etc. Each feature is already split up neatly into stories and so these stories are the units of work that are tested by the QA team as part of the sprint.

The only downside to this approach is that the engineering can either be left with very little to do in the last 2/3 days of a sprint, or that they can easily be overwhelmed by sprint bugs to fix that may overflow into the next sprint. However, we have found that the very short feedback loop on finding bugs (as bugs can be found in just a day or two from coding) is much preferable to having a cleaner sprint plan but a feedback loop of up to two weeks.

Title: Scrum taskboard with QA stage

Body:
I've been reading this article by Mike Cohn about Scrum task boards.

One query I have is how this fits into a workflow where there is QA stage performed by testers who aren't developers.

It seems that many tasks could not easily be QA'd in isolation.

A practical alternative could be that the "To Verify" process should be carried out by another developer in the team, and then to have an additional stage after DONE to QA the whole story (probably after deployment to a stage/test environment).

Does this seem right?


问:
Explain to a non-technical manager that the tool he chose isn't apt
My non-technical manager just paid for a license to use a tool which designed to pick mentions of your brand name at blogs, "social media", comments, etc. and gauge the sentiment (positive, neutral, negative) of the post. What he wants me to do is use it to do a task which can only be achieved with a certain level of natural language processing and hence shows up unrelated results for whatever query you can try.

I want to be able to explain to him that this tool is designed for task X and what we are trying to do is task Y. Y cannot be modelled as X. And all the success of the tool he cites as proof is proof of X which is not Y.

答: Take the desired task that you expect the tool to handle and create some use cases. Show your manager that the tool fails to produce the desired output of those cases. Explain that the modification can't be done for reasons such as the tool has no potential for hooks, the tool vendor is not providing documentation to do that, etc. </p>


答:
First of all, be cautious when explaining him that the tool he choose isn't apt. Your intentions, however good they may be, they may be perceived as a way for you  to evade doing the task or even worse - you can make him feel stupid (and you don't want that).

As you explained here - the tool isn't capable of doing such things. Explain to him in plain language what are the intended use cases for this tool and which results are possible with this tool.

Also, you can find out about other ways (tools) to accomplish the task and discuss it with him. Prepare good for his questions so that he can see that you know what you're talking about.

If he's still not convinced try another approach. Calculate the time you will need to spend doing task (if you even succeed) with the tool X and time that will take you using tool Y. If the time benefits of using the tool Y are great (time == money) he can choose the other tool.

Title: Explain to a non-technical manager that the tool he chose isn't apt

Body:
My non-technical manager just paid for a license to use a tool which designed to pick mentions of your brand name at blogs, "social media", comments, etc. and gauge the sentiment (positive, neutral, negative) of the post. What he wants me to do is use it to do a task which can only be achieved with a certain level of natural language processing and hence shows up unrelated results for whatever query you can try.

I want to be able to explain to him that this tool is designed for task X and what we are trying to do is task Y. Y cannot be modelled as X. And all the success of the tool he cites as proof is proof of X which is not Y.


问:
Is Systems Hungarian notation still a useful practice?
I searched the forum, but I couldn't find the answers why it should be avoided, only why it's not a silver bullet. So I don't think this question is a duplicate.

Is there a VALID reason why I should unlearn Systems Hungarian I'm used to?

So far I see the following benefits in using it:

Consistent variable naming

You see type without searching (intellisense is dead/indexing half of the time, so it's still a valid reason)

Semantics can still be packed into second part of the name

And following downsides:

It annoys some people (no idea why)

If type is changed, the type might not match the naming of the variable (I don't think it's valid reason, types are changed rarely, and you have "rename all")

So why:

```<code>vector<string> vecCityNames;
wstring strCity = L"abc";
//more code here
vecCityNames.push_back(strCity);
</code>```

is worse than:

```<code>vector<string> cityNames;
wstring city = L"abc";
//more code here
cityNames.push_back(city);//Are we pushing back int on a queue? Float on a stack? Something else?
</code>```

答:
I used to use it (many years ago) and I don't anymore. The main reason is it's superfluous in the OO languages with strong typing (C++, Java) which I happen to have used most of my career. In these languages, if I define my types well, the compiler can and will enforce type safety for me. So any naming prefixes are just clutter which make the names longer, thus harder to read and to search.

In any well written OO program, most of your variables are (references to) user defined types. If you prefix these with the same general tag (like o for "object"), you won't get any benefit from it, only the drawbacks . If however you prefix them with type-specific tags, you get into a maze of trying to find different abbreviations for a thousand different types with often similar names*, and to remember to change them all when a type or its name changes (which is not rare at all in a well maintained program).

Of course, this doesn't apply to non-OO languages, and may not apply to weakly and/or dynamically typed languages (I have no experience with these, apart from C). Neither to suboptimal editors/IDEs without a usable IntelliSense (or its local equivalent). And this is just my 2 cents. So if Hungarian notation works for your team and your project, go for it. The important thing is to agree on this (as well as on a consistent coding style in general) before the project starts, and keep it consistent at all times.

*just a short list from our current project: we have Charge, ChargeBreakdown, ChargeCalculator, ChargeDAO, ChargeDTO, ChargeLineHelper, ChargeMaps, ChargePair and ChargeType, among others. Moreover we also have Contracts, Countries, Checkouts, Checkins... and this is just the letter C, in a project which probably wouldn't even be called "reasonably sized" by the OP.

Disclaimer: I am actually a Hungarian, so I believe I can speak on this issue with authority ;-)


答:
The IDE will trivially tell me what the type of a variable is when I mouse over it. So why bother duplicating that information? Fundamentally, Systems Hungarian Notation is a violation of DRY, with all the pitfalls that's associated with it. When that information is trivially accessible in a modern environment, there's no reason to pay that price.

Consistency is not an advantage in as of itself. Not naming them with the type is also consistent. You would only have inconsistency if only some variables had their types in the name. And packing semantics into the second part is simply "Well, it's not that bad.", everyone else gets to use the whole name for semantics. You don't have any real advantages listed.

Title: Is Systems Hungarian notation still a useful practice?

Body:
I searched the forum, but I couldn't find the answers why it should be avoided, only why it's not a silver bullet. So I don't think this question is a duplicate.

Is there a VALID reason why I should unlearn Systems Hungarian I'm used to?

So far I see the following benefits in using it:

Consistent variable naming

You see type without searching (intellisense is dead/indexing half of the time, so it's still a valid reason)

Semantics can still be packed into second part of the name

And following downsides:

It annoys some people (no idea why)

If type is changed, the type might not match the naming of the variable (I don't think it's valid reason, types are changed rarely, and you have "rename all")

So why:

```<code>vector<string> vecCityNames;
wstring strCity = L"abc";
//more code here
vecCityNames.push_back(strCity);
</code>```

is worse than:

```<code>vector<string> cityNames;
wstring city = L"abc";
//more code here
cityNames.push_back(city);//Are we pushing back int on a queue? Float on a stack? Something else?
</code>```


答:
Why is std::vector<string> vecCityNames;bad?

The problem with Hungarian notation as it is usually used it that, if profiling shows that city names should rather be kept in a std::deque, all variable names referring to an object of that type will suddenly have a misleading name.

Are you then going to rename all your variables? Have you ever tried to do that in a big project? With Murphy's help (and the guy is incredibly helpful there) someone somewhere will certainly have used variables called something like deqCityNames, making your changes break the build, leaving you sitting for hours fiddling with code that, for half a decade, nobody dared to even look at, for fear of being bitten by a poisonous beast.

From what I know, however, the way Charles Simonyi came up with Hungarian, the prefix was denoting the variables semantic usage, rather than it's syntactic type. That is, the proper prefix for your list of city names, no matter what type it is implemented in, would probably be listCityNames (or lstCityNames, if list isn't cryptic enough for you).

But I consider that prefix quite superfluous, because the plural ("names") already conveys that it is a bunch of cities. Bottom line: When you pick your identifiers with care, Hungarian notation is rarely needed. OTOH, the way it is commonly used it is, in the long run, actually doing damage to the code.


答:
Great tools. Be it editors, debuggers, compilers, OS, VCS whatever we are most comfortable and productive with.

Open standards. This gives us flexibility to use tools of our choice to work with. So no MS Exchange emails solution, no doc, docx, xls, ...

Simple processes. The mundane should be either taken care, or the process should be simple enough so as not to come in between what we love the most.

Extra chair, available nearby. Very useful if we want to discuss something with your peer or during code reviews.

Biggest baddest monitor you can get. Get as much screen real estate as possible. Whatever helps us see more code at once. This includes dual/multiple monitors, though I personally find it difficult to use multiple monitors. So I prefer one single large high resolution monitor.

Comfortable keyboard and mouse placed at proper height and distance.

White board, notepad (preferably unruled), pencil (a pen will not do, most admins fail to see the difference), board markers (multiple colors) ...

The usual stuff that applies to any other desk job - proper lighting, air circulation, space, regular supply of fresh coffee, quiet environment, ...

Title: Stuff every programmer needs while working

Body:
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


答: Syntax is how you arrange a language's tokens. Semantics is what those tokens mean (usually, what a particular arrangement of tokens means).</p>


答:
Clearly, this comes down to opinions, so it's going to be difficult to work with facts here.  Personally, I find that the argument for Hungarian notation runs a bit thin in strongly-typed, object oriented languages.  In my experience, OO applications tend to handle complexity by keeping classes coherent and concise, and the same thing can be said about functions.  This means that all other things being equal, you end up with:

More classes / types

Shorter methods

Now, if you want to use Hungarian notation, you have to decide whether to apply it across the board, or to just use it for certain privileged types and classes (such as core library classes).  The latter makes no sense to me, and the former leads to the "maze of trying to find different abbreviations to a thousand different types" that Péter Török was referring to.  This means that there is a significant overhead in maintaining abbreviation lists, and usually "consistent variable naming" goes out the window.

The second point about shorter methods means that in most cases, you are not going to have to go through hundreds of lines of code to check what type a variable is.  Naming variables slightly more carefully would eliminate some of your other questions - e.g. cityName vs. just city.  I would hope that cityName is not a float :)

Regarding why it annoys people - again, this is probably down to being used to it or not.  But as someone who is not used to it, I can tell you that the use of Hungarian notation breaks the flow of code for my eyes, making it harder to read quickly.  To summarise, I am not saying that it has no merit (although I haven't discussed some of its drawbacks, in terms of refactoring, etc), I am saying that the effort is not worthwhile, for strongly-typed, OO languages.


问:
How can we verify that software meets specifications meets requirements?
So we're pretty good at eliciting requirements from our end customers, business division and sales/marketing. We plan projects to add/enhance features to meet those requests and prioritize tasks to meet deadlines in most profitable order.

Over time, the software product has grown, the market has changed and the original customers are less of a priority compared to some new opportunities.

So, the requirements, and therefore specifications, have changed, although all the requirements of all the stakeholders can co-exist (there are no conflicts).

We've also had some churn in the development team with people moving up, across or out and so now there's nobody who was there "at the beginning".

This has led to some customer outages where we removed what looked like unused code paths (the logic was unfamiliar to everyone) only to find the customer that needed that logic happened to run through the application a couple of months later.

We know that we could put in Unit Tests to verify that behaviour does not change accidentally (as in the case above), but this is a large code-base so it is taking time to unit-test everything.

What non-manual techniques/technologies/best-practices are available to us to verify that the software (still) meets the specifications and requirements?

I've heard agile/iterative proponents say something like "the Unit Tests are the specification". Is there any thing we could use to marry the unit tests to the original requirements?

Footnotes

(I saw this other post, but that is less about verification and more about usability testing)

We already do iterative development, releasing every two weeks or less.

The source base is mostly C++ on Unix. Requirements and specifications currently documented in Wiki, Word, ticketing systems and MS Project.

答:
You have two things here: Verification and Validation.  The former deals with making sure that the code matches the specifications.  The latter deals with making sure that the code matches the customer expectations. Behaviour driven development and Agile methodologies aim to reduce the disparity between verification and validation. </p>

<p>Validation, can be done in terms of scenarios that testers can run through.  Those can be automated or not.  Beta testers are a good second line since customers can get to play with the new version.  Finally, user acceptance tests can be done and is recommended to iron out the last few bugs. A quick iteration time releases during this cycle can be beneficial. </p>

Body:
You have two things here: Verification and Validation.  The former deals with making sure that the code matches the specifications.  The latter deals with making sure that the code matches the customer expectations. Behaviour driven development and Agile methodologies aim to reduce the disparity between verification and validation.

Validation, can be done in terms of scenarios that testers can run through.  Those can be automated or not.  Beta testers are a good second line since customers can get to play with the new version.  Finally, user acceptance tests can be done and is recommended to iron out the last few bugs. A quick iteration time releases during this cycle can be beneficial.


答:
This has led to some customer outages where we removed what looked like unused code paths (the logic was unfamiliar to everyone) only to find the customer that needed that logic happened to run through the application a couple of months later.

That is a strange one. Unless you can prove the code can never be run (ie it is orphaned) why would you do this?

Unless you have a documented list of all requirements, you cannot PROVE the software definitely meets anything.

Title: How can we verify that software meets specifications meets requirements?

Body:
So we're pretty good at eliciting requirements from our end customers, business division and sales/marketing. We plan projects to add/enhance features to meet those requests and prioritize tasks to meet deadlines in most profitable order.

Over time, the software product has grown, the market has changed and the original customers are less of a priority compared to some new opportunities.

So, the requirements, and therefore specifications, have changed, although all the requirements of all the stakeholders can co-exist (there are no conflicts).

We've also had some churn in the development team with people moving up, across or out and so now there's nobody who was there "at the beginning".

This has led to some customer outages where we removed what looked like unused code paths (the logic was unfamiliar to everyone) only to find the customer that needed that logic happened to run through the application a couple of months later.

We know that we could put in Unit Tests to verify that behaviour does not change accidentally (as in the case above), but this is a large code-base so it is taking time to unit-test everything.

What non-manual techniques/technologies/best-practices are available to us to verify that the software (still) meets the specifications and requirements?

I've heard agile/iterative proponents say something like "the Unit Tests are the specification". Is there any thing we could use to marry the unit tests to the original requirements?

Footnotes

(I saw this other post, but that is less about verification and more about usability testing)

We already do iterative development, releasing every two weeks or less.

The source base is mostly C++ on Unix. Requirements and specifications currently documented in Wiki, Word, ticketing systems and MS Project.


答:
User christian.p had some excellent suggestions which I will recap:

Don't make him feel stupid: This will illicit irrational emotional based responses.

Look for other tools that perform Task Y:  This shows that you genuinely wish to help him solve the problem by offerring alternatives.

Provide quote for custom development of Y feature:  This shows you aren't lazy and gives him the impression that you aren't brushing him off.

What I would like to add is that you should try to see this through the management perspective.  I am sure it doesn't surprise you that there are a LOT of worthless software developers and IT professionals in the field, and your manager has probably been around the block enough times that he had the misfortune of managing a number of such individuals.

Managers get told "Y is impossible" by supposed "professionals" all the time that are either tragically misinformed, blatantly untrue, or scandalously deceitful.  Many of them figure this out later talking to a more qualified technical person or figure these things out years later after said person had already left the company and the new guy rolls in and actually does the imaginative impossible.

Where I work now my manager had a number of myths about the capabilities of the technology platform we are working under, fed by the previous development team (and if the abysmal quality of their code speaks to their skill level then it is not flattering).  I prototyped and implemented a number of game changing things on top of meeting deadlines and goals and now my manager trusts me.

Earning your managers trust is the only way to actually avoid the annoying leg work of proving your assertions.  Now that I have his trust I can tell him that something is "an extreme challenge" (I NEVER use the word impossible to describe anything), and he takes my word for it.


答:
For whatever reason, the existing answers here seem to be dancing around the rationale for Hungarian notation, without stating it outright. Hungarian notation is useful for adding type information (in a type theoretical sense) when it would be difficult to do so in the language itself. As it happens, it usually is not that difficult to use C++ or Java's type system in such a way that Hungarian notation (as usually described) is completely superfluous, and this is probably what has lead to the backlash against it - it adds programmer work to maintain those annotations in all our variable naes, but provides little-to-no additional value (and may even cause harm, as the code looks more cluttered).

On the other hand, if one restricts the use of Hungarian-notation to type information (again, in a type theoretical sense) that is not naturally encapsulated by the language, then it can be very useful. For example, C and C++ pass array references as pointer types, but array references and pointers have different operations that should be performed against them: arrays can be indexed beyond the first element, while pointers should not. This is useful information that gets lost to the type system as soon as an array is passed to a function as an argument. As such, in our group we've adopted variable-name annotations in C and C++ code to distinguish whether a pointer variable is actually a pointer to a single element, or a pointer to an array. Adopting this convention has been partly responsible for a large reduction in the occurrence of memory corruption problems in our code base.


问:
Are there any .NET based framework for working with English language?
I'm writing a web application in which I need to analyze words (now just in English, but maybe in future in any language). I tried to write a framework to do the job, but it soon proved to be something really really hard. Finding stems, understanding part of speech, finding consonants, determining morphological patterns, etc. It's really getting harder with each new requirement.

Is there any framework out there (preferably compatible with .NET or PHP frameworks) for working with human languages (English for example)? Some common methods of such framework could be:

```<code>List<Synonym> synonyms = SynonymFinder.FindSynonyms("Help");
Stem stem = MorphologyAnalyzer.GetStem("Determining");
Pronunciation pronunciation = Phonetics.Transcribe("Speech");
</code>```

答:
Having had a look around myself in this department, I really like OpenNLP, which is now maintained by Apache.

Since OpenNLP is a Java library, you need to use these instructions with IKVM, and you can (quite readily) get OpenNLP working with .NET.  You can then use the library directly in your C# code without having to have an additional compatibility layer (as I think getting some Python code to work with IronPython can be problematic).

SharpNLP was meant to be a .NET version, but it hasn't been updated since 2006.


答:
Syntax is what the computer understands, semantics is what the human understands.

A compiler/interpreter doesn't care a whit about your design, and in any code compiled down to machine level you'd have a hard time deducing the design.  Developers care about design because a good design is about reducing complexity by abstracting complex behaviors and interactions, and different kinds of problems lend themselves to different semantics. The choice of language is largely about how easily and efficiently the semantics you want to use can be expressed in its syntax.


问:
Why is testing MVC Views frowned upon?
I'm currently setting the groundwork for an ASP.Net MVC application and I'm looking into what sort of unit-tests I should be prepared to write. I've seen in multiple places people essentially saying 'don't bother testing your views, there's no logic and it's trivial and will be covered by an integration test'.

I don't understand how this has become the accepted wisdom. Integration tests serve an entirely different purpose than unit tests. If I break something, I don't want to know a half-hour later when my integration tests break, I want to know immediately.

Sample Scenario :
Lets say we're dealing with a standard CRUD app with a Customer entity. The customer has a name and an address. At each level of testing, I want to verify that the Customer retrieval logic gets both the name and the address properly.

To unit-test the repository, I write an integration test to hit the database.
To unit-test the business rules, I mock out the repository, feed the business rules appropriate data, and verify my expected results are returned.

What I'd like to do :
To unit-test the UI, I mock out the business rules, setup my expected customer instance, render the view, and verify that the view contains the appropriate values for the instance I specified.

What I'm stuck doing :
To unit-test the repository, I write an integration test, setup an appropriate login, create the required data in the database, open a browser, navigate to the customer, and verify the resulting page contains the appropriate values for the instance I specified.

I realize that there is overlap between the two scenarios discussed above, but the key difference it time and effort required to setup and execute the tests.

If I (or another dev) removes the address field from the view, I don't want to wait for the integration test to discover this. I want is discovered and flagged in a unit-test that gets multiple times daily.

I get the feeling that I'm just not grasping some key concept. Can someone explain why wanting immediate test feedback on the validity of an MVC view is a bad thing? (or if not bad, then not the expected way to get said feedback)

答: You can learn how to test the View returned by a controller action, how to test the View Data returned by a controller action, and how to test whether or not one controller action redirects you to a second controller action by check out the following URL, describe in this brief article about Testing View Data in MVC.</p>

Title: Why is testing MVC Views frowned upon?


问:
On the effectiveness of unit testing
How effective are unit tests in reality?

I am under the impression that at some point unit tests turn into tests that test the dependency between the object under test and another object. Sure, one can always abstract dependencies using interfaces, but what happens when even the interfaces should be changed? What if the unit under test no longer relies on those dependencies?

If our tests fail because of dependency issues, does it mean they are too coupled to our code? Also, do we have to change them every time when we change the dependencies?
If it happens quite often, is this a sign that our design is wrong?

I tended to believe that unit tests are an effective way to test ensure robustness, but if they are too coupled to the dependencies that our objects have with other objects (be they expressed as interfaces), it simply leads to more time wasted in fixing those tests to pass the new design. Am I wrong?

The thing is, I am perfectly aware of the existence of mocking frameworks, and so on. This is not the problem. The problem is what happens when you change your method's implementation and it simply doesn't call the mock anymore, and you start seeing a bunch of red lights in your test stack, because your mocks aren't called the way the way they should? Unit or Integration test, something should be done here, right?

If I start writing different mock methods for every test condition I like, what happens if I decide to change the signature of the class I've mocked? All my tests go to the trash bin, right? Is this normal, can it be avoided? Is it a design problem?

答:
The person that told you testing dependencies is integration testing rather than unit testing is indeed correct. Unit testing normally consists of creating mock objects of any dependencies and testing a single Class as a single "unit". You are only testing that it calls the correct methods on its dependencies and returns the correct things IF the dependencies return the correct things. This is one of the good reasons for using interfaces for your Classes as you can easily create a mock from an interface using for example EasyMock.

Unit tests are very useful as long as they are done right, but I do believe that some people take them too far. You don't need 100% code coverage, just make sure anything that isn't obviously correct is reasonably tested. I recommend adding system tests as well for any complicated system - these tests won't mock anything, they just test the system as a whole.

You may want to read some of the answers at https://stackoverflow.com/questions/16860/getting-started-with-unit-testing for getting the most out of your unit testing.

Title: On the effectiveness of unit testing


答:
How effective are unit tests in reality?

That depends on your problem domain!  I consider them to almost always to be worth it, they allow you to refector without fear!

I am under the impression that at some point unit tests turn into tests that test the dependency between the object under test and another object. Sure, one can always abstract dependencies using interfaces, but what happens when even the interfaces should be changed? What if the unit under test no longer relies on those dependencies?

Are you aware of Test Doubles, which also covers mocking? This should help you Unit (and Integration) test more effectively.

Using TDD, if your interface changes then in theory you should be altering your test first to indicate what your desired outcome should be, then change the actual code to pass the test.  So the whole Red-->Green-->Refactor cycle.

If our tests fail because of dependency issues, does it mean they are too coupled to our code? Also, do we have to change them every time when we change the dependencies? If it happens quite often, is this a sign that our design is wrong?

See my point above about Test Doubles.  However, sometimes you can't or don't want to use a Test Double.  In that case you're starting to test the interaction between 2+ components, which is often called Integration Testing.

I tended to believe that unit tests are an effective way to test ensure robustness, but if they are too coupled to the dependencies that our objects have with other objects (be they expressed as interfaces), it simply leads to more time wasted in fixing those tests to pass the new design. Am I wrong?

You're not wrong, I think your approach just needs some Test Double/Mock/Dependency Injection tweaks

NOTE: Someone mentioned that when we test the dependencies between two objects, it is no longer considered unit testing, but rather, integration testing. I don't know what to believe in, any longer

IMO, that person is correct - those sorts of tests are integration tests.

Also for slightly more advanced thinking in this space, lookup BDD as a complimentary approach to unit testing

Title: On the effectiveness of unit testing

Body:
How effective are unit tests in reality?

I am under the impression that at some point unit tests turn into tests that test the dependency between the object under test and another object. Sure, one can always abstract dependencies using interfaces, but what happens when even the interfaces should be changed? What if the unit under test no longer relies on those dependencies?

If our tests fail because of dependency issues, does it mean they are too coupled to our code? Also, do we have to change them every time when we change the dependencies?
If it happens quite often, is this a sign that our design is wrong?

I tended to believe that unit tests are an effective way to test ensure robustness, but if they are too coupled to the dependencies that our objects have with other objects (be they expressed as interfaces), it simply leads to more time wasted in fixing those tests to pass the new design. Am I wrong?

The thing is, I am perfectly aware of the existence of mocking frameworks, and so on. This is not the problem. The problem is what happens when you change your method's implementation and it simply doesn't call the mock anymore, and you start seeing a bunch of red lights in your test stack, because your mocks aren't called the way the way they should? Unit or Integration test, something should be done here, right?

If I start writing different mock methods for every test condition I like, what happens if I decide to change the signature of the class I've mocked? All my tests go to the trash bin, right? Is this normal, can it be avoided? Is it a design problem?


答: Meh - it is really all about personal preferences, no matter how hard one tries to rationalize their choices. I personally stick to the "When in Rome..." rule and use Hungarian in code that calls Windows API a lot. For platform-independent code, I tend to follow the C++ Standard Library style.</p>


答:
You seem flustered about a number of issues, I will try and address as many as I can:

I am under the impression that at some point unit tests turn into tests that test the dependency between the object under test and another object. Classes and components have dependencies on other classes and components, yes.  Thus we have a situation where the unit test for component A needs to test assertions on the functionality of A, and the dependency on component B should be accounted for.  Under Integration Testing, we are testing the appropriate interaction between the testing component A and its dependency in component B.  However in true Unit Testing, we assume that the behavior of component B is understood and well tested.

We can use a Mocking framework to create a dummy component B that has predefined behavior we specify.  The value of mocking then is that we can have unit tests for specific scenarios of component A Method 2 for instance:

Test Return Value of Component A Method 2 when argument passed is 4

Test Return Value of Component A Method 2 when argument passed is 4 and mocked dependency component B returns 12.

Test exception is throw from Component A Method 2 when mocked dependency component B returns 15.

Etc...

I tended to believe that unit tests are an effective way to test ensure robustness, but if they are too coupled to the dependencies that our objects have with other objects (be they expressed as interfaces), it simply leads to more time wasted in fixing those tests to pass the new design. Am I wrong?

This could be a sign of high coupling and low cohesion and violations of the single responsibility of a class if your tests are extraordinarily complicated and prohibitively brittle.  Unit tests are of less importance in this case as the major underlying design issues should be addressed first.  This will be more beneficial to software quality.

OTOH, if you find that most of the behavior of a component is actually inside of the dependent components, then it sounds like a wrapper component or pass-through component of some kind and test coverage of this component may be overkill.

Title: On the effectiveness of unit testing


答:
Silence.

Silence.

Silence.

A flat keyboard + any number of gadgets wanted by the programmer (and this varies).

Own office.

Freedom from ridiculous inquiries by non-tech staff, including some clueless (technology-wise) CEOs.

Access to educational resources, like books.

Headphones and a large share with selection of great music.

Free food is appreciated, though not necessarily a major plus.

Ability to work with cool technologies, whether it's just the cutting edge release of a framework, or implementing a fuzzy controller for sorting numbers (I know this is a very dumb example, it's here for illustration purposes).

Silence.

A no-noise environment

Coworkers who do not speak

Call-out-only phone

Quiet working environment.


答:
A really nice and recent article that plainly and concisely compares and contrasts a few different ways of working with source control is here: Source Control Done Right.

I don't think there's any one strategy/best-practice for using source control. Mature teams that have been working together for a long time have a much less "pain" in this area even if they aren't exactly following popular "best practices".

As for which tools... It almost doesn't matter. What really matters is having everyone on your team be on the same page as far as usage. This means everyone needs to understand how the code line is managed and what they're expected to do. And anyway, in practice you DON'T usually have a choice about which tool to use. Make the best of whatever you're using.

Title: How can I properly manage commits, prevent feature conflicts, and manage dependencies with a VCS?

Body:
It’s become an annoying factor of working with large teams: how do you manage checkins and prevent feature conflicts and manage dependencies with source control properly?

Currently at my workplace we use TFS 2008 and we're migrating to TFS 2010 in early December. Firstly any source control is better than none but what approach has anyone found useful to prevent multiple checkins and rollback all over source control history? Is a volatile trunk the best way to go or branch off when your implementing a new feature and once you're happy merge back into the trunk?

I'd really like to hear other people experiences and perhaps some best practices to managing source control.


答: If you really want to do this right, you have to accept that there's going to be a lot of manual work.  Unit/system/integration/regression testing is vital, but it'll only verify that the software works the way the tests require.  Requirements traceability means that each requirement gets an ID of some sort, and that ID is traceable throughout the development process.  A requirement ID has to be tied to one (or more) features, features have to be tied to a design, and designs are tied to tests.  Ultimately, you can look at any part of the system and trace it back or forward.  If a test fails, you can see what requirement isn't being met.  Look at some code and see why it is required and what parts of the system use it.  If a requirement gets dropped, you can identify what code and tests can be removed.  Unfortunately, there's no good tool support for this (we had a bunch of Perl scripts that wired FrameMaker, a custom change management system and a design tool together).</p>


答:
Another point with traditional forms of Hungarian notation is they are usually prefixes. there are 2 problems imho here:

1) A human reader would generally like the most important information first, in most forms of Hungarian the information encoded is arguably of less importance than than name itself.

2) Prefixes effect lexical sorting, so if for instance you are going to use a prefix to denote interfaces or classes and your IDE provides a sorted list of these, related classes/interfaces are going to be separated in this list.


问:
When should I prefix names with the project name?
If you work with SharePoint, you'll see classes like SPList, SPSite etc.

I've seen variations of this on other projects, in other technologies, e.g. for a CRM project, classes named CRMLoggingFactory, CRMEntity etc.

This stands out when you look at the code and you know what the prefix corresponds to, but when do you draw the line? What are the conditions for a class to be prefixed by the project name, company name, etc. (i.e. the "domain name" of the project)?

答: I would say that the line should be drawn when the class name seems somewhat generic but has a very particular implementation and meaning that is specific to the containing library/framework/api. Also if the library/api/whatever is expected to be used in the context with other compenents that may have classes with similar or identical names. You could also use namespaces to help with such problems, but that may not be available in all languages/environments.


答: This will at least partly depend on the language. Id say it is, in general, bad practice in languages that provide proper namespace facilities but good practice in languages that don't. </p>

Title: When should I prefix names with the project name?

Body:
If you work with SharePoint, you'll see classes like SPList, SPSite etc.

I've seen variations of this on other projects, in other technologies, e.g. for a CRM project, classes named CRMLoggingFactory, CRMEntity etc.

This stands out when you look at the code and you know what the prefix corresponds to, but when do you draw the line? What are the conditions for a class to be prefixed by the project name, company name, etc. (i.e. the "domain name" of the project)?


问:
Providing users with program revision history information?
One limitation of a program that I maintain is that the end-users often don't know what changes have been made.
To remedy this I would like to show my users a simplified list of changes made to their program.  Is there a good methodology/approach to follow that would create a easy to update list that could then be fed into the user interface?

For example:  Should I store everything in a XML file that is read into a form?  Should the change history go into a database?

Note:  The program is Winforms (C# 4.0).

UPDATE

Based on the excellent feedback I have decided to  use SQLite as my information storage and will provide the users with a chronological list of changes in a TreeView control.

答: Any decent issue tracker generates release notes (based on the closed stories in a release). Embed that as a text file and show it anywhere you like in your app.</p>


答: This is an indication that the environment has weak namespacing facilities, in Java, C++ or C# this is a tautology and a serious code smell. In C with a flat namespace this would be acceptable for public facing API functions.</p>


答:
Users don't generally care about things the same way you do. While you can be lazy and simply publish your bug list, it's far better if you take a little time and highlight the changes in the user's language.

This means losing detail. For the ones who want all detail, you could include a full list of issues addressed--but in general your release notes should only show, in this order:

Major new functionality, in the user's language.

Changes in workflow, possibly with a justification. E.g.: "The print dialog has been streamlined; you can now find page layout options on the print page, instead of their old location under Document Options."

Major bug fixes, in the user's language. E.g.: "Crashes are less frequent when opening files over 2 GB" rather than "Fixed buffer overflow in mt_file_read for inputs > 2GB"

A summary of any minor changes to workflow and tiny new features

In general, users don't care about minor bug fixes, so just say "and bug fixes" or the like. Again, you can provide a link to the full details for the programmers in the audience. ;)

This is more work, and your users will really appreciate the attention to detail.

Title: Providing users with program revision history information?

Body:
One limitation of a program that I maintain is that the end-users often don't know what changes have been made.
To remedy this I would like to show my users a simplified list of changes made to their program.  Is there a good methodology/approach to follow that would create a easy to update list that could then be fed into the user interface?

For example:  Should I store everything in a XML file that is read into a form?  Should the change history go into a database?

Note:  The program is Winforms (C# 4.0).

UPDATE

Based on the excellent feedback I have decided to  use SQLite as my information storage and will provide the users with a chronological list of changes in a TreeView control.


答:
The first question you need to answer is if your users care. There's no need to implement any functionality or user interface components in order to add something that users don't want or need. That's just more code that needs to be tested and validated. If there's no requirement for this information to be displayed in the application, you're just gold plating the requirements - a known antipattern.

If your users do want this information, you need to determine how to make it available. That should be driven by the users, through requirements that they provide. You seem to want to present it as a tool accessible through the user interface. However, there are many other options that should be considered, and discussed with your users (or the subset of users who might want this information). Possible options include a "changes since last release" in the README or user's manual, a changelog file alongside the README or user's manual, or a web page on the product's website that describes the changes in the latest version with the ability to view changes between latest versions. Depending on the file format that you use for the changes, you could either open that file using the OS-specified application or parse the file and display it in a user interface as well.

Regardless of how you deliver it, don't do it because you want to, but because your users want it. Otherwise, you're just creating work for youself that adds no value to your product.


问:
Employer asking me to use API for entire website?
I'm working with an ASP.net developer, under a boss who doesn't have much technical knowledge. I'm doing the front-end work, and and a database expert doing the backend.

However, recently, he said that he would be working on the API for our site- I asked why, thinking we should do the web version first, assuming the API was for mobile apps. However, he said that he would just make a single API to work for all the web and mobile apps, and I would do the front-end for that.

Is it just me, or is this a little crazy? If I'm doing front-end, it means there's going to be two back-ends, because I'm going to have to use PHP or something to curl his API to the site, which is twice the loading time as normal.

Thank for any help in advance. Also, I happen to be "the intern", so I'll have some but not very much pull with this issue.

答:
Consuming your own API is a common case. It is often called Eating your own dog food if I remember well.

Currently, I am doing the same thing for a project. I have created my Data Access Layer library, and I won't be using it directly on my web project. Instead, I will create REST APIs to reach out the data from my web site.

How I handle the authentication is another issue. What I will do is to give myself a APIKey as I will give others and go from there.

What advantages does this bring? Well, I will be handling statistics over the REST APIs and I really don't want to do the same work again. Also, by this way, my only data access concern is my API project.


答:
A door.

Seriously, everybody should have an office with a door they can shut when they really, really need to get some work done. You can leave it open most of the day, but for those times when you're carrying a lot of state in your head and you really don't care about some random media event or sub-culture in-joke, you need a door you can close.

I also like a good solid wall I can kick if I need to, but that's probably just me.


答:
Simply send an e-mail to the tech support of the product: "How should I do task Y using your tool?"

Maybe you'll be surprised, maybe your manager...


问:
Do technical interviews tend to be subjective?
Based on my experience in technical interviews, I have found that most tend to be subjective because the interviewer already has his own answer. Even though the answer from the candidate is correct, because the interviewer was not prepared for that answer, the candidate does not get the job.

In an interview recently I said something about using an AVL tree algorithm to solve a specific problem that was asked. The interviewer responded: "What's an AVL tree?". Another example is anything around syntax; I've encountered this mostly in interviews that require Ruby code because there are many ways to implement a solution to a given problem. A very common ones is problems around Object Oriented designs.

In this situation, there's no way for the interviewee to succeed. Has anybody else felt this way too or is it just me? If it's not just me, how can we make technical interviews better?

答:
The "real" technical interviews I had were all like: "Here is the problem, use these technologies, you have 3 hours". After that we did a code review and talked about why I did what I did. This way he saw what I already know and where I lack knowledgde.

Then we talked a bit about technologies and my goals in general and that was it. The interviews are, in my opinion, designed to get a feel for the candidate. You can not test everything. It takes a long time to get to know someone pretty well so that, again in my opinion, you should focus on the things that are important for you project and see how people handle this issues. The rest comes with experience over time


答:
Any interviewer who dismissed a candidate simply because they didn't provide the expected answer is a poor interviewer. If a company encourages this and I get that feeling in an interview, that's a serious red flag about the team and company interviewing me.

If an interviewee provided me with an answer that I didn't think of, I'd expect him to be able to explain what the solution used is and the advantages/disadvantages of it. Like you said, there are often multiple solutions, ranging from choosing an algorithm to the syntactical structures used, and almost always there are tradeoffs involved. I'd even probe the interviewee for alternative solutions to see if they can come up with others, especially if it's an obvious solution, and ask for the advantages/disadvantages of each.

Regardless of how you run the interview, it's going to be subjective. Every interviewer, as a person, will have biases. As an interviewee, you can just do the best you can, be thorough (but not overly verbose) when answering questions, and explain your answers and how you got there. That'll take you a long way.

Title: Do technical interviews tend to be subjective?

Body:
Based on my experience in technical interviews, I have found that most tend to be subjective because the interviewer already has his own answer. Even though the answer from the candidate is correct, because the interviewer was not prepared for that answer, the candidate does not get the job.

In an interview recently I said something about using an AVL tree algorithm to solve a specific problem that was asked. The interviewer responded: "What's an AVL tree?". Another example is anything around syntax; I've encountered this mostly in interviews that require Ruby code because there are many ways to implement a solution to a given problem. A very common ones is problems around Object Oriented designs.

In this situation, there's no way for the interviewee to succeed. Has anybody else felt this way too or is it just me? If it's not just me, how can we make technical interviews better?


答:
Trivia Questions are anti-patterns to interviews.  If you find yourself stuck in such an interview, try to direct them back to what you know.  Concentrate on your resume.  If this doesn't work...well consider looking elsewhere.

Interviewers should ask open-ended questions related to your Resume.  While it's possible to get a feel for a person's communication skills, it's difficult to gauge a person's development abilities by simply asking questions.  That's partly why so many people (including Joel on software) recommend, no require interviewees write code (and jump through several other hoops for that matter).

The fact remains that software development is still mostly about solving an unknown set of problems in an unknown amount of time.  There's no set of tests that prove, ok this guy can build "a bridge". We are getting better at turning software creation into a more defined engineering process, but we aren't there yet.


答:
Ask him to explain how you will consume his API.  Most likely, you will be developing a combination of server-side pages and Javascript to make REST calls on the website.

You might develop a page that calls the API then incorporates the response into the web page.  Or dispense with writing server-side code altogether and do it with all Javascript (see http://javascriptmvc.com).

Yes, if you write code that delegates to an API via HTTP calls, it might come at the cost of some additional latency, depending on how many hops separate the code rendering the page and the server which implements the API.  However, that cost has to be weighed against the code of duplication.  Duplicated code is twice as expensive to maintain.

This design should not require two separate back-ends. The purpose of using a single API is to avoid duplicating the back-end code.

Title: Employer asking me to use API for entire website?

Body:
I'm working with an ASP.net developer, under a boss who doesn't have much technical knowledge. I'm doing the front-end work, and and a database expert doing the backend.

However, recently, he said that he would be working on the API for our site- I asked why, thinking we should do the web version first, assuming the API was for mobile apps. However, he said that he would just make a single API to work for all the web and mobile apps, and I would do the front-end for that.

Is it just me, or is this a little crazy? If I'm doing front-end, it means there's going to be two back-ends, because I'm going to have to use PHP or something to curl his API to the site, which is twice the loading time as normal.

Thank for any help in advance. Also, I happen to be "the intern", so I'll have some but not very much pull with this issue.


答:
I think your own blind spots are leading you to an assumption that is invalid as to why you don't get the job.

It is possible to answer everything correctly in a job interview and not get the job because you are competing against other people who may also have gotten everything correct. When you only have 1 job and three people you think can do the job, you still can only hire one. It's a tough market out there and lots of experienced people are looking. You never know just how well your competition did in their interviews.

Yes interviews are subjective, they are looking for people who not only have technical skills but who will fit in the existing group. Just keep trying eventually if you are capable, you will find the right place and they will hire you.


问:
What's your favourite quote about programming?
What's your favourite quote about programming?

One quote per answer, and please check for duplicates before posting!

答:
I don't understand why cheerleaders
  won't talk to me. Maybe I don't throw
  five touchdowns against Newport High,
  but let's see one of those football
  morons program in assembly language!

  — Chris Lipe

LastEditorDisplayName: Roger Pate


答:
So far I see the following benefits in using it:

Consistent variable naming

If I name all my variables after characters from The Simpsons, that's consistent too, but is it a benefit?

You see type without searching (intellisense is dead/indexing half of the time, so it's still a valid reason)

This is the only valid reason, based on the weakness of one specific tool...

Semantics can still be packed into second part of the name

That's not a benefit; you're merely claiming the absence of a (massive) downside.


答:
I don't know in the context of C++ but in the Java/C# world I would much prefer having meaningful names that convey either a domain language or context than telling me that strFirstName is a String; it should be obvious that it's a string, or the name needs to be refactored to convey better intent.  If you require a prefix to know the type of what you are working with, I would argue your naming is inconsistent, not descriptive enough, or downright wrong.  In modern languages I always prefer longer names that leave no ambiguity than vague or ambiguous names.

The only time I use Hungarian is for ASP.NET controls, and that's more so I A) don't have to type something really long like CustomerFirstNameTextBox versus txtCustomerFirstName, and B) So Intellisense will sort all of the control types.  I feel "dirty" even doing that, though, I just have yet to find a better way.


答: Isn't this the correct way to abstract a site so you can have multiple front ends that display the same data, possibly in different formats?  Perhaps not a full-blown API but in .NET it's fairly common to have a "web service layer" that sits on top of your DAL and Business layer, so you can write a thin front end that focuses almost entirely on display concerns only since everything it needs to work with is pulled from the web service, and this also allows you to have various front ends that all point to the same service.


答:
Im afraid that that the subjective part cannot be removed, only diminish. I frecuently have technical interviews, where the interviewer "pollutes" the interview with its own subjective ideas.

One simple example, as you mention, is that the interviewer wants an answer very close to its own answer. Another example is, when an interviewer its more interested to probe he/she knows more than the candidate. And another simple one, is when the interviewer, wants the candidate to know the specific menu location for an operation of a programming I.D.E., (Visual Studio, Eclipse, NetBeans).

I have been on several like that, and its very frustrating.

And, of course, there is also the hidden discrimination thing, where the interviewer doesn't want the candidate, from been poor, gender, political ideas, race, school, whatever you like. And its looking for any excuse to reject the candidate.

The weirdest part, is that, been an C.S. graduate, I know some psychology, (was going to study that profession), and sometimes, detect a lot of the subjective "interference". Or, when the interviewer goes to the office next door, and explicitly tells their coworkers, he / she doesn't wants to hire a candidate, for a subjective reason.

Something important, to consider, is that many Universities, or Companies, teach I.T. / Technical people how to do job interviews, and that teaching include both the technical & human factors, not just technical.


问:
What are some good practices when trying to teach declarative programming to imperative programmers?
I offered to do a little bit training in F# at my company and they seemed to show some interest. They are generally VB6 and C# programmers who don't follow programming with too much passion. That being said I feel like it is easier to write correct code when you think in a functional matter so they should definitely get some benefit out of it.

Can anyone offer up some advice on how I should approach this?

Ideas

Don't focus on the syntax, instead focus on how this language and the idioms it promotes can be used.

Try and think of examples that are a pain to write in an imperative fashion but translates to elegant code when written in a declarative fashion.

答:
Functional programming is an odd beast for me.  I learned F# and Haskell, wrote a few simple programs and love using them, but never had the "flash of revelation" that some people talk about.  But slowly, I noticed that more and more I was writing code that was meant to be immutable, breaking up tasks into more, smaller functions, and trying to use delegates a lot more.  Its a thing that, if you like it, creeps into your work because the value of those techniques are self-evident.

Now, more practically for training:
I find that two concepts really click Functional Programming as a style to me.

First, FP style is based on structure of data, not composition as in OOP.  I looked at something like List in C# as being a clever trick to generate type-safe lists, something that composed the type (string) into the other type (list).  After learning FP, I look at generics more like Monads now.  List is a structured form that code can take, and it decorates the strings.

Second, and perhaps more useful to C#/ASP programmers, is the idea that FP works on recursion and repetition, while OOP works on mutability and looping. I tend to think of the ASP page lifecycle as a kind of FP now: each request is processed from scratch through the entire life-cycle, so the entire page is, in effect, one big slowly recursing program.  If you can narrow that notion down, you get a better idea of how an imperative program can be structured around loops of functions that take in data, operate over it, and return out new data instead of modifying the old.

The trickiest hurdle, at least for me, to overcome with this approach is that sinking feeling that you're wasting tons of resources when using mutable objects would save a ton of memory.  In GC we trust, and I just had to learn to let go of performance concerns until I'd actually seen the program run and verified if there even were any, and if so to use a profiler to see exactly where the problems were.


答:
Hate is too strong a word, IMO. You can write your code any way you want; I simply prefer not to use Hungarian notation in my own code, and given a choice I'd also prefer not to have to read it or work with it in other people's code.

You asked why some people find Hungarian notation annoying. I can't speak for others, but the reasons that it annoys me are:

It's ugly. Hungarian takes perfectly reasonable names and prepends what amounts to a code. Once you've internalized this code, I'm sure makes perfect sense, but to the uninitiated it just looks like somebody unleashed the C++ name mangler on my source code.

It's redundant. A variable's declaration establishes its type; I don't feel the need to repeat that information in the variable name. This isn't true in every language: in Perl, for example, sigils such as @ or $ prepended to the variable name essentially define the type of the variable, so you don't have any choice but to use them.

It solves a problem that I don't have. Methods and functions shouldn't be so long that you have to look hard to find the declaration of a local variable or parameter, and they shouldn't involve so many variables that you have trouble keeping track of what's what. Declaring local variables close to the code that uses them helps in this respect, too. C compilers of the past required that all local variables be declared at the beginning of the function, but that limitation was removed long ago.

It's incomplete. Hungarian notation was invented for a language (BCPL) that didn't have a type system, and was later used widely in a language (C) that had a fairly limited number of native types. IMO, it doesn't work well with languages like C++ or Java that have extensive type systems. Why would I want to use a prefix to indicate the type of a variable that's a native type, like char[], but not one that's a class? Alternately, if I start inventing prefixes like vec for classes, I'll end up with a large hierarchy of prefixes parallel to my class hierarchy. If that appeals to you, you're welcome to it; just thinking about it is giving me a headache.

It's ambiguous, at least as I understand it. What's the difference between szFoo and pszFoo? The first is a zero terminated string, and the second is a pointer to a zero terminated string. But in C or C++, as far as I know, any string variable is effectively a pointer, so are they the same or not? Which should I use? The actual answer really doesn't matter -- the point is that I can't discern the answer using the very notation that's supposed to help me avoid these sorts of questions. The variable's declaration, on the other hand, has to be unambiguous because it's what the compiler uses.

Those are the things that annoy me about Hungarian notation. Even as a group, though, I don't think they fully explain why Hungarian has been largely abandoned. Here are the three biggest reasons that most programmers don't use Hungarian:

There's no compelling reason to use it. See items 3 and 4 above. I could probably live with the annoyances if Hungarian offered some big advantage over not using Hungarian, but I don't see one, and apparently most other folks don't either. Perhaps the best thing about Hungarian was that it was a widely used convention, and if you stuck to the standard use you could reasonably expect other programmers with similar skills to be able to understand the notation.

Increased influence of companies that aren't Microsoft. It's probably fair to say that most programmers that adopted Hungarian notation did so because that's the way Microsoft wrote code, and its often easier to go with the flow. Companies like Google and Apple have much, much larger spheres of influence now than they did in the past, and more programmers than ever before are adopting the styles of those companies and others that mostly eschew Hungarian. (It's only fair to point out that you do still see some remnants, e.g. both Google and Apple often use a 'k' prefix for constant names.)

Microsoft itself has abandoned Hungarian. If you check Microsoft's General Naming Conventions section of its coding guidelines, you'll find that it says, in bold: Do not use Hungarian notation.

Accordingly, one valid reason to stop using Hungarian notation is:

Hungarian notation's popularity has diminished to the point that the convention is no longer helpful. Far fewer programmers use or even understand Hungarian these days, and the convention is therefore much less effective at conveying the information that it's supposed to. If you find it a useful way to write code in your own personal projects, then there's little reason to stop. However, if you're writing code as part of a team that doesn't use Hungarian, it may become a wall between you and the rest of the team instead of a successful communication strategy.


问:
What is a reasonable and secure password requirement for user registration?
This is the password policy I just got from UPS (just for package status checking):

Your password must be between 8 and 26 characters long. It must
  contain at least three of the following character types: lowercase
  letters, capital letters, numerals, special characters, or spaces. The
  password may not contain your User ID, your name, or your e-mail
  address. (SSO_1007)

I actually have to wrack my brain somewhat to generate this password, but not only that, most importantly, I am sure that after 3 days I will forget what this password is.  Users won't be so happy.  Password reset can be frequent.  I think users will try to avoid using the site unless they have to.

What is a reasonable and secure password policy when setting up a website?   I think some companies may fear some hackers trying passwords a million times or more, so they add all those requirements for "special characters, lower case, upper case", but won't it be reasonable to turn off the account or just disable the password and require a password reset if a user has tried 30 times or 100 times?  Or, add a 5 second delay each time after the user tried 30 times?  If so, then those special characters won't be that much needed.

答: To be honest, I find having strict password requirements to be an annoyance and not a benefit.  I would say as a rule the most reasonable is to just specify a length, maybe special characters + alphanumeric.  Anything more is asking for people to write down their password, which defeats the whole purpose of having secure passwords.  I also hate having to change your password every x days with the usual ridiculous set of rules (e.g. cannot re-use the last 25 passwords) - again all that does is force people to write the thing down so they don't forget, at which point you might as well not ask for a password at all.  </p>


答:
One that I found recently is when I said something about using an AVL tree algorithm to solve a specific problem that was asked. The interviewer asked me back: "What's an AVL tree?".

As an interviewer, I would ask that, too, even if I knew everything about AVL trees (I don't), to find out how much the candidate knows. Faking ignorance can be a trick to see if the candidate can explain well. But obviously, if you do come up with an algorithm/data structure that solves the problem, that I don't know, and that you can explain properly, I would hire you. Otherwise, shame on me. Not hiring people because they're smarter than yourself are is not a good hiring strategy.

But generally speaking: yes, technical interviews are always subjective. And they have to be. If you're going to spend 8 hours+ everyday with a person, it's wouldn't be reasonable to pick someone who manages to drive you crazy in a 60-minute interview.


答:
The answer lies in this question: Please tell me how to name the following variables:

```
char * nullTerminatedString;
wchar * nullTerminatedWideString;
string stlString;
wstring stlWideString;
CString mfcString;
BSTR comString;
_bstr_t atlString;
```

Add to these constant strings, pointer to these and constant pointers to these.

Body:
The answer lies in this question: Please tell me how to name the following variables:

char * nullTerminatedString;
wchar * nullTerminatedWideString;
string stlString;
wstring stlWideString;
CString mfcString;
BSTR comString;
_bstr_t atlString;

Add to these constant strings, pointer to these and constant pointers to these.


问:
For performance critical situations is storing file metadata in a database better?
As per the title of this question, for extremely performance critical situations, is storing a file's metadata (e.g. location, size, download on, etc) in a database going to allow for better performance than attempting to get it from the file system itself? Have there been any case studies into this problem?

To provide a bit more detail on a specific situation, the application needs to mirror terabytes of data (hundreds of files) between a remote site on a continual basis and the current program architecture uses Unix commands (i.e. ls) to determine which files needed to be updated. The file themselves are split between Isilon IQ clusters and Sun Thumper clusters which I have been told good throughput but poor metadata performance. As the application will be the only process to have write permissions to the files we aren't concerned with things getting out of sync, but we are concerned with performance as it currently takes between six and ten hours to transfer the data.

答:
For actually getting an individual file's meta data I would not expect much difference, and, it would very much depend on which database went head to head with which file system and how well either was configured.

However if you say wanted to search for files with a ".mp4" suffix or all movies > 1GB then the database will win hands down. Even if the file systems index was organized to be efficiently searchable the normally available POSIX APIs would limit you to searching sequentially through a directory. If you have distributed your data over several file systems and needed a separate search on each "leaf" directory.

However this may not be the case for much longer as there are several projects (including one from Google) which are actively working on file systems with searchable meta-data


答:
A good interviewer won't ask a question where they expect a specific answer, unless the question is something trivially simple where there's only one correct answer.  A good interviewer will see how you approach a problem, how you think through it, and how you arrive at your answer - if your answer is valid they should not hold it against you because you didn't do things the way they would do it.

It sounds like you have just been subjected to lousy interviewers more concerned about showing their "superiority" to the candidate than actually gauging technical skill.


问:
What is the acceptable failure rate for software?
Say I produce some software with a genetic algorithm. In order to be certain that the software works correctly in all situations, I would need to test all situations, which could be prohibitively (or infinitely) many. So I evolve the software with evolving test input (some fixed, some inherited, and some random). Now, with each generation, the probability measurably increases that the fittest functions will be general solutions, not just solutions for the known data at hand.

As developers, we are flawed, and our software may fail, in fact quite often. Generally speaking, we have no idea of the probability of failure at any given point, though we may be able to discern specific cases in which the software will fail. All we can do to reduce the failure rate is test thoroughly and practice good software development. But logically, we distribute flawed software all the time.

Would it make you uncomfortable as a developer to know how often your software might fail, but to know nothing about the specific cases in which it might? What failure rate is acceptable? 0.01%? 0.0001%? Would you hold a genetic algorithm to a higher standard than a human when it comes to failure rates?

答:
You are asking for a categorical absolute, without providing any sort of context (such as use case, requirements, industry, customers, users, etc.).

Therefore, the answer is a categorical absolute: 0.0%.

If you have a specific context in mind, the acceptable failure rate will depend entirely on the context.


答:
Works great.  Right up until something gets out of sync and then you're left with having to do a full scan anyways, and in the meantime with any little quirk in your systems you'll do yet another full scan just to rule out sync issues.

If this is one master system sourcing the data can you monitor file system activity?  If you can detect changes instead of scanning the entire system you could create a baseline (using your DB, or even a flat file manager) and then update based on recent activity.

Can you get reports from the data source(s) that modify the files?  Instead of having to detect changes after the fact you could queue up lists of files to watch for changes to complete and only update those.

Title: For performance critical situations is storing file metadata in a database better?

Body:
As per the title of this question, for extremely performance critical situations, is storing a file's metadata (e.g. location, size, download on, etc) in a database going to allow for better performance than attempting to get it from the file system itself? Have there been any case studies into this problem?

To provide a bit more detail on a specific situation, the application needs to mirror terabytes of data (hundreds of files) between a remote site on a continual basis and the current program architecture uses Unix commands (i.e. ls) to determine which files needed to be updated. The file themselves are split between Isilon IQ clusters and Sun Thumper clusters which I have been told good throughput but poor metadata performance. As the application will be the only process to have write permissions to the files we aren't concerned with things getting out of sync, but we are concerned with performance as it currently takes between six and ten hours to transfer the data.