答:
Googling for answers is a good practice: you are digging into the experience and knowledge of hundreds and thousands of people who just may have faced the exact same problem you have and can help you solve it.

As for blindly copying and pasting, well that's how we learn too. It's exactly what we do with our text books: typing out the code from the page into the IDE without quite understanding all of it just yet (if you did understand it already, you wouldn't want to see it run).

Eventually you hope that understanding will come: you're doing it right if you manage to learn something. But there is always more to learn, solving one problem just makes room for the next problem - so don't feel ashamed to get help when you need it.

If your c&p is truly blind, you will not progress; your ability as a student or professional is not measured by your capacity for Googling, but by your ability to understand and interpret the results and to develop your skills over time. Blind c&p is un-rewarding in the long run. Even for those problems where I had a magic c&p="wow, it works now!" I was never truly satisfied until I went back over it until I figured out how it works.

Sometimes you will find that Googling doesn't help. Particularly as you start to get more specialised either as a researcher or working developer, you will more often than not get an error message, type it into Google and to your astonishment see:

Your search - "Exception while unfenargling the heeble-blerg: why did you do that?" - did not match any documents.

Then will come a true test of your skills...


问:
Steve Yegge post about platform vs product
I am reading this and I came across:

The Golden Rule of Platforms, "Eat Your Own Dogfood", can be rephrased as "Start with a Platform, and Then Use it for Everything." You can't just bolt it on later. Certainly not easily at any rate -- ask anyone who worked on platformizing MS Office. Or anyone who worked on platformizing Amazon. If you delay it, it'll be ten times as much work as just doing it correctly up front. You can't cheat. You can't have secret back doors for internal apps to get special priority access, not for ANY reason. You need to solve the hard problems up front.

What does that exactly mean? Can someone please explain?

答:
I believe it's saying, "Use the same interface you're giving to the outside world." The interface you give your own programmers is going to be good (hopefully because a programmer will create an interface that s/he would like to use). If you have a different interface internally than you have externally, then the external interface will be lacking since the people who use it are not able to change it for the better.

In that way, nobody will use your platform because it will be impossible to use. They won't be able to get the information from the platform they need. They're relegated to second-class citizens and third-parties will go somewhere they are treated well.

ContentLicense: CC BY-SA 3.0


问:
Is it a good idea to always use Google as the first step to solving a problem?

Possible Duplicate:

  Importance of learning to google efficiently for a programmer?

Avoiding lengthy discussions, as a senior level student in CS, how can I get away from Googling problems I run into? I find myself using it too much; I seemingly reach for the instant answer and then blindly copy and paste code, hoping it works. Anyone can do that. I've read the related threads about being a better programmer, but mostly those recommend practicing on pet projects, which I have done, but again I feel EVERY wall encountered, from design through completion, was hurdled with Google.

Do professionals instantly "research" their problem? Or do you guys step back and try and figure it out yourselves?

I'm talking about both 'algorithm/design' problems as well as compiler issues.

答:
Maybe you should do some "in the field" or "real time" problems... where you don't have time or the resources to Google. Off the top of my head some of these involve ship board activities. For example the University in my area has some ROV related projects that CS students work on. While the project is developed on land (with google), when you're in the field trouble shooting, you have less chance to use Google. I'm not sure how practical this answer is for you, but I noticed that field techs (good field techs) are some of the most resourceful people I've seen. They're able to solve problems w/o Google etc if they have to.... but yes, these days, they have to less and less.

Another field activity would be GIS related stuff, where you're way out in the field testing / using GPS devices. Many of these places will have no internet, but you'll have your laptop and you'll need to get stuff done with it.

Think of places where there's no internet, and go and do computer stuff there.


问:
Speed of Java vs. JS / HTML / CSS for web applications
I am creating a web application.  I have primarily used Javascript specifically jQuery.  Because of some very specific functionality, I am running into practical limitations of Javascript--they're not hard limitations but stuff that I would find easy in Java, like making an equation editor where you can edit directly as opposed to entering TeX, is difficult in JS even using MathJax as a base.

I'm going to have to build even more complex functionality that involves 3D and physics engines.

For a large scale application like this--specifically one that involves 3D and physics engines--would Java be slower or faster than Javascript when one is run within a browser?  (Assume that code is written well in both cases.)  Or is it completely uncertain--i.e. dependent on far too many specific variables?

Thanks.

答:
Java will typically perform considerably perform better than Javascript - the JIT compiler for Java is extremely good and gets you to near-native performance in most cases.

I think if you want to build a 3D engine though you are best advised to go with Java - you're ultimately going to want full OpenGL capabilities and the performance of Java's JIT compiler.

You should note that Java is a bit "heavyweight" to start up compared to Javascript (overhead of loading .jar files and warming up the JVM etc). Also there are some security controls that you may have to work around, especially if you do something that requires native libraries. Typically this means signing your .jar files and/or having a user agree to trust your application. Alternatively, you may decide that it is best to offer a downloadable Java application.

I've personally have good experiences with LWJGL as a toolkit for building 3D browser applications using Java. You could also look at jMonkeyEngine if you want a more complete 3D engine with physics etc.


问:
Is there a pattern for subscribing to fired events/messages at specific intervals?
I'm not sure if this a common scenario or not, but I have a need along the following lines:

I have an object (I'll call it node) and this object has methods X, Y, and Z. I want to be able to have subscribers be notified if the methods are called in a specific order with specific timing (a range of time would be ideal). For instance:

Node.X() get called

Node.Z() is called 5 to 7 milliseconds  latter

Node.X() is called 1 to 2 milliseconds after that

Node.Y() is called 2 milliseconds seconds after that.

Finally, An event calling a subscriber to this sequence is fired.

Now, in this example I am simply using parameter-less methods, but in real life I'd need to be more specific about the contents of the parameters (I'd be looking for specific messages).

For reference I am using C# .net 4.

Are there any frameworks/patterns/libraries that exist out there that are built for doing this?

答: The Reactive Extensions for .NET could possibly be used to implement the scenario you describe.  You can think of them as "LINQ to events". Check out the samples.</p>


答:
Thanks for the link -- Steve Yegge must be the best ranter on the Internet these days. And since ranting is pretty much the killer app of the Internet, that's saying something. On to your question:

What does that exactly mean? Can someone please explain?

Uh, you did read the piece, right? I did, and I recall that Steve spends most (okay, some) of his column-inches explaining what that paragraph means. See Eating your own dogfood for an explanation of the dogfood metaphor, if you need that explained.

Beyond that, the Big Idea he's talking about through the whole piece is that there are a lot of advantages in building a platform for products instead of a single do-it-all product that tries to be everything to everybody. With a platform, you can build many different products, and you can let other people build products on your platform too, and in that way you can better serve your customers and even let them use your stuff to serve themselves. But, it doesn't work if you don't commit to the platform; it doesn't work if you don't use the platform yourself, or if you use it but also have some extra for-internal-use-only tools.

Adding my own 2 cents, what he's talking about is very much like the difference between top-down and bottom-up design. Top-down: you dream up a product, and then set about specifying all the things that product will be able to do, and then you build that product. Bottom-up: you dream up a product, but instead of trying to determine every little feature up front, you instead build a number of parts that you can combine in all sorts of ways to arrive at something kinda-sorta like the product you imagined in the first place, but along the way you might also use those same tools to build a bunch of other things you never even thought about.

Title: Steve Yegge post about platform vs product

Body:
I am reading this and I came across:

The Golden Rule of Platforms, "Eat Your Own Dogfood", can be rephrased as "Start with a Platform, and Then Use it for Everything." You can't just bolt it on later. Certainly not easily at any rate -- ask anyone who worked on platformizing MS Office. Or anyone who worked on platformizing Amazon. If you delay it, it'll be ten times as much work as just doing it correctly up front. You can't cheat. You can't have secret back doors for internal apps to get special priority access, not for ANY reason. You need to solve the hard problems up front.

What does that exactly mean? Can someone please explain?


问:
Are captchas worth the decreased usability?
When is it useful to use a captcha? When is it an unnecessary hindrance? Is a captcha just a quick fix for the lazy/unexperienced programmer, or are they really the best way to prevent spam and bots? </p>

答:
I use reCaptcha because it cuts 90% of the spam out with 5% effort.

I haven't had people complain that the captcha is hard, makes things more difficult, or has any decreased usability either.

Spammers and bots are abundant. It's very easy to scrape a form and start submitting bad requests en masse. It is a simple, secure, proven way to significantly reduce spam and bots. It's not a quick fix for the lazy or inexperienced, rather experience has led to this solution and it is now easy to implement.

Do I like captchas? Hell no. Squiggly lines, what does it mean, opps I entered it wrong. It is effective though.

ContentLicense: CC BY-SA 2.5


问:
working on open source project is bad from a programmer view?
I am working in a software company where we are mostly working on websites which are based on open source like dotnetnuke or nopcommerce or any other

and i am totally bored with all this as there is no scope for doing something new as most of the code is already done in these open source

i know the open source are good for company as they save their time and earn more money

but working on open source project is bad from a programmer view ?

i learn some good things from these open source also...like entity framework from nopcommerce 1.9

答:
Being bored for a prolonged period is a good sign that it is time to move on, but I do not think that this has anything to do with working on an open source project or not.

The phrase "there is nothing new in the world..." applies to software as easily as it does to movies or books. Open or closed source, finding something new to do is a relative question. What I mean by this is: if I am writing a website for a clothing company using dotCMS, am I doing something new?

No: dotCMS (an open source CMS) is not new.
No: plenty of clothing companies have websites.
No: I am probably not going to implement new features in dotCMS as part of the project.

But more importantly:
YES: it is a new project for me and I will hopefully learn a thing or two.
or
NO: this is the fifteenth dotCMS project in a row and I am bored.

I think the above answers will be exactly the same whether you are talking about using open or closed source software.

In every job I have taken, I have been doing new things on previously established frameworks, APIs etc. They were open source, but that isn't the point. What I was doing was new to me.. so if you are bored, look around for something that is new. :)


答:
Often, when googling, I find a better approach to solve what I was after, and actually learn something new.

That's very valuable - up there with a code-review by a better colleague.

Don't shy away from getting input into what your trying to achieve!

Title: Is it a good idea to always use Google as the first step to solving a problem?

Body:
Possible Duplicate:

  Importance of learning to google efficiently for a programmer?

Avoiding lengthy discussions, as a senior level student in CS, how can I get away from Googling problems I run into? I find myself using it too much; I seemingly reach for the instant answer and then blindly copy and paste code, hoping it works. Anyone can do that. I've read the related threads about being a better programmer, but mostly those recommend practicing on pet projects, which I have done, but again I feel EVERY wall encountered, from design through completion, was hurdled with Google.

Do professionals instantly "research" their problem? Or do you guys step back and try and figure it out yourselves?

I'm talking about both 'algorithm/design' problems as well as compiler issues.


答:
One point he's making is that, especially for anything web-oriented, but for others as well, you benefit greatly by providing an open, programmable interface. That doesn't mean a UI with a macro language, but a UI that's mostly separate from the "engine" that does the real work -- and full, open documentation of how the UI talks to the engine, so anybody can write a whole new UI that uses the engine, add-ons to the engine that can hook seamlessly into your UI, etc.

In short, instead of building (or even thinking in terms of) complete products, you should think and work primarily in terms of producing useful components. Those components need to work with each other cleanly, but that's not enough by itself. The interfaces between those components need to be clearly documented and defined so they're suitable for essentially anybody to replace (for example) your UI with something of their own, plug it into your engine, and be able to use your engine to its full capabilities, because they have just as much access to its capabilities as anybody else does.

Ultimately, this isn't a dramatic change from what's been pushed for some time (e.g., 3-tier applications). The big difference is that even though they're written as components, most typical 3-tier applications still basically assume that all the components in use will be produced together, so all the interfaces between them are "private". In quite a few cases there are implicit assumptions that one component need not check inputs from another, because it "knows" what inputs the other can produce.

Especially for web-facing servers and such, that's just not tenable. Instead, every interface has to be "hardened" -- specified and implemented to work under any circumstances, specifically including the possibility that whatever's on the other side of the interface may be sloppy and crappy, or even a carefully engineered attacker.

Looked at from a slightly different perspective, a product should provide for entry at any of a number of different levels. For beginning users, it should have a polished UI. For more advanced users, it should have some sort of built-in programmability to tweak things they don't like, automate things they do too often, etc. Finally, and most importantly, it should provide a low-level interface that gives full control of every aspect of the "engine" of that product. This needs to be exactly what you use to develop your own code to work with the product's engine, so anybody else has just as complete of access to that engine as your own UI does.


答:
Use your own software - it is the best way to test it and perfect it.

A "platform" is this article refers to a piece of software that other people can use to make their own programs work. For example, Facebook is the "platform" that Zynga used to make "Farmville" work.

Windows is a platform too - because other programs (Word, Chrome, World of Warcraft) use it to work.

The article makes the distinction between a "platform" and a "product". A product is also a piece of software, but is "stand alone" - it is something people will use, but isn't something that software creators can "extend" by writing software that uses it. Most programs that run on Windows are products in this sense rather than platforms.

The biggest criticism in this article is against Google+, which is a (to me) brilliant product (as in I love to use it) but not a good platform because it doesn't expose an API or service that other programmers can use. For example: Google Reader can't easily see and post to Google+; Flipboard (ipad app) can't see or post to Google+.


答:
'Bad' is subjective, and depends on the situation.  If your job consists of primarily working with and extending open source systems, you are missing out on developing the skills and experience required for building 'whole' systems from scratch. (or mostly scratch, as few people work without some framework/libraries/etc).  Thats not necessarily bad - its only bad if those are skills and experience you need/want.  Similarly, people who focus on creating systems from scratch and never work with open source projects arent improving their skills related to working with those.  Its a trade off.

If you are bored with what you are currently doing, next time around you'll probably want to look for a position that lets you be more creative.

Title: working on open source project is bad from a programmer view?

Body:
I am working in a software company where we are mostly working on websites which are based on open source like dotnetnuke or nopcommerce or any other

and i am totally bored with all this as there is no scope for doing something new as most of the code is already done in these open source

i know the open source are good for company as they save their time and earn more money

but working on open source project is bad from a programmer view ?

i learn some good things from these open source also...like entity framework from nopcommerce 1.9


问:
Why should company choose VB.NET over C#

Possible Duplicate:

  VB.Net vs C# debate

Are there any actual reasons why company should choose VB.NET over C#?

I work for a company which develops medical software and switched from VB6 to VB.NET several years ago. There were two reasons to switch to VB.NET but not to C# at that moment:

VB.NET is more similar to VB6 and it should make it easier for
developers to switch to .NET world

VB.NET had a better support for COM than C#

The first reason is not serious as VB6 and VB.NET are two different worlds and there is no significant difference between switching from VB6 to VB.NET or C#. The second reason is not actual after C# 4 release.

Our company eventually switched to C# (and yes, we now have modules in VB6, VB.NET and C#; and even some modules in C++) because:
1. It is easier to find developers in C#
2. .NET world is C#-oriented: Visual Studio works better with C#, Resharper has better support for C#, etc.

I am just curious whether there are still some reasons for company to choose VB.NET over C#.

答: Developer background... I have that situation at my new job right now. I come from a C# background, but the others developers (2) that already worked in the company come from a VB.net background</p>


答:
Mostly legacy reasons:

Existing devs don't know C#

Lots of existing VB6 / VB.Net code

Hard to find C# devs locally

Stuck on earlier versions of Visual Studio (which had better inlellisense for VB.Net)

Prior investment in VB.Net tools (e.g. only having VB.Net version of Resharper)

Liking VB.Net more than C#

Title: Why should company choose VB.NET over C#

Body:
Possible Duplicate:

  VB.Net vs C# debate

Are there any actual reasons why company should choose VB.NET over C#?

I work for a company which develops medical software and switched from VB6 to VB.NET several years ago. There were two reasons to switch to VB.NET but not to C# at that moment:

VB.NET is more similar to VB6 and it should make it easier for
developers to switch to .NET world

VB.NET had a better support for COM than C#

The first reason is not serious as VB6 and VB.NET are two different worlds and there is no significant difference between switching from VB6 to VB.NET or C#. The second reason is not actual after C# 4 release.

Our company eventually switched to C# (and yes, we now have modules in VB6, VB.NET and C#; and even some modules in C++) because:
1. It is easier to find developers in C#
2. .NET world is C#-oriented: Visual Studio works better with C#, Resharper has better support for C#, etc.

I am just curious whether there are still some reasons for company to choose VB.NET over C#.


问:
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.

答:
Not a dictionary word, or a trivial variation of it. That's it. A bundle of two dictionary words is pretty much uncrackable. A single-letter substitute for a character that is not an obvious substitute (0-O, 1-I, 5-S) too.

Also, if you limit response time - password accepted/denied after 1s, and no two parallel attempts for the same login allowed - one must finish (OK or error) before you try another, any non-dictionary 6-letter all-lowercase no-special-characters password will take 9 years to break.


问:
Should I move invariant out of cycle
Should I care about moving invariants out of cycle scope if it worsens code readability?

Let's take a look at a simple example:

```<code>for (var i = 0; i < collection.Count; i++)
{
   ...
}
</code>```

vs.

```<code>var collectionCount = collection.Count;
for (var i = 0; i < collectionCount; i++)
{
   ...
}
</code>```

The performance of second piece of code is better or equal to first one. It will be equal only if collection is fixed-size and Count is not calculated every time. It will be much better if, for example, collection is Linked List which doesn't cache somewhere its Length.

I understand that second approach will unlikely kill my application performance (it is much more likely some inefficient SQL query will) but at the same time I don't feel comfortable when I write second piece of code as I miss (small) optimization. But at the same time from readability point of view I like the first piece of code more (less lines of code, less variables).

I guess it is minor thing and may be it doesn't worth discussing but I would like to hear your opinion.

答:
Almost always the answer to this kind of thing is to leave it to the compiler.  I would recommend you write the most readable and maintainable code you can and don't worry about this kind of micro-optimisation.  Modern compilers are more than capable of make this sort of optimisation on their own.

If and only if you get to the point where you need to make the code run faster, then profile the code, looking at as much of the system as possible and then decide where to start trying to optimise.  You will usually find that 80% of the time is spent in a tiny fraction of the code, and this will form a natural point to optimise.

Title: Should I move invariant out of cycle


答:
I KISS Google.

Whatever solution Google gives me, I try to remove as much code as possible to get the minimum that solves my problem. This implies that I must understand what Google provides. Sometimes I end up with a totally different solution.


问:
How do you handle ever-growing piles of issues to be resolved "somewhen"?
We're using JIRA to keep track of issues in our software projects. One effect we noticed is that we often create a new issue but we don't knw yet when/if the problem is going to be fixed at all. So we invented a fake 'Distant Future' milestone which such issues get assigned to.

As it happens, the pile of issues assigned to this milestone keeps growing all the time so it seems this is not a good approach. There are so many of them by now that it became quite a lot of work to review all of them for validity. Some of them became invalid since the component they are related to you was removed. Some of them were duplicated by other issues. Some of them have such a poorly phrased description that nobody really knows what they are about anymore.

How do other software development teams deal with issues which are valid, but which might not get fixed anytime. Do you bother recording them at all? Do you assign them to the next planned version and then look at them again as the next release approaches? Something else?

答:
These are good first contact bugs to fix for new developers that have just joined your company.  Or for junior developers to expends their knowledge of the system.

If not, you can mark them "wont fix" if they are not serious enough to justify the time it would take to fix.


答:
Using honeypot fields is/was a method to reduce spam at no real usability cost.

Here's an article describing how it works with some CSS magic, and while they noted that its effectiveness diminished, it'll still catch some bots. There are probably also more advanced techniques besides CSS (read: JS) that can boost the effectiveness of honeypots.

Title: Are captchas worth the decreased usability?

Body: When is it useful to use a captcha? When is it an unnecessary hindrance? Is a captcha just a quick fix for the lazy/unexperienced programmer, or are they really the best way to prevent spam and bots? </p>


答:
You should fix a bug only if the application is more valuable without the bug.

If a text field is misaligned and it takes three days to fix it, then the cost is probably too high and you should leave it. On the contrary, if the users cannot write at all into the text field then you should fix it, and quickly.

In general it is easier to fix an issue immediately after it has been discovered. If you let time pass, developers may forget how that part of the code works and fixing the bug will take longer and therefore will be more expensive.

Some companies don't write a line of new code if there are still bugs pending. Others don't bother until the testing phase before delivery.

In your company you are obviously letting to much time pass before fixing new bugs so they're accumulating. It is also bad for the morale of the team to see a huge list of bugs.

I suggest you to spend a day just to sort out the existing bugs, deciding the ones that are worth fixing and the ones that are not and assigning the ones to fix to the existing team members with the goal of resolving the issues before the next milestone.

Title: How do you handle ever-growing piles of issues to be resolved "somewhen"?

Body:
We're using JIRA to keep track of issues in our software projects. One effect we noticed is that we often create a new issue but we don't knw yet when/if the problem is going to be fixed at all. So we invented a fake 'Distant Future' milestone which such issues get assigned to.

As it happens, the pile of issues assigned to this milestone keeps growing all the time so it seems this is not a good approach. There are so many of them by now that it became quite a lot of work to review all of them for validity. Some of them became invalid since the component they are related to you was removed. Some of them were duplicated by other issues. Some of them have such a poorly phrased description that nobody really knows what they are about anymore.

How do other software development teams deal with issues which are valid, but which might not get fixed anytime. Do you bother recording them at all? Do you assign them to the next planned version and then look at them again as the next release approaches? Something else?


问:
Where should I look to know which technology is used in a web app?
Let's say, I have one or more web app I find interesting, and as I want to do something similar, I would like to know on which technology they are based (programming language, database, web server, framework, ...).

Is there any site where such information is centralized? If not, where should I look for this information?

答:
There is no centralized place for such information. For some sites the technology stack is known and you can find it through google, for others you will have to find out on your own through hints such as headers in http messages and such.

Or you could just contact the admin and ask.


答: In our issue-tracking, there is a status "time-barred". If an issue is several months or even years old, and no client urges or refiles the issue, then this status is used as the final status. This is not done automatically, but manually, whenever the managers ask us to clean up the open issues. During this process, it's also likely that some of the issues are fixed because they are easy to fix and/or relatively important (despite not being urged or refiled). </p>


答:
I don't use JIRA, I've got fogbugz at work but I'm sure this applies to most bug trackers. While writing this I realized that the way I work is more agile than waterfall, deadlines are not concrete for me and what matters is priority.

If your boss cares about too many tickets being open just don't create the trivial ones in the first place. You should be prgamatic and not add any features/fixes that have no benefits. If it will make your life easier to polish some code or tweak the UI then sure, add it. Don't just make work for yourself by trying to fix minor flaws in the product, nothing is perfect.

Put the unimportant bugs/features in the current milestone but under a low priority. If more complaints/requests are mentioned about the issue then you can bump up the priority.

Close/resolve what you can as won't fix, can't reproduce, duplicate etc. Some bugs are too trivial to fix or they are feature requests that would take far too long. Sometimes you just need to tell the person requesting these fixes/features "No Sorry, we don't have time".

Prioritise the bugs as required and have your ticket list sorted by priority and milestone.

If they are not going to make the milestone then move them into a future milestone.

If a ticket is dependent on some other ticket being completed then mark it as blocked or organise the tickets into a hierarchy so it's obvious that ticket-x and ticket-y are related.

If a ticket requires some feedback from someone assign it to that person.

Ultimately you will always have a bunch of low priority tickets sitting about, but points above should help you minimize that.


答: Using bcrypt when storing the password is a good first start, simply because it makes brute-force hacking attempts unfeasible.</p>

Title: What is a reasonable and secure password requirement for user registration?

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


答:
If it is a plugin based web app like an RIA (Rich Internet Application) then it is fairly easy to identify a Flash plugin, Silverlight plugin or Java applet.

Otherwise if you view page source you can often times get a number of helpful clues about what technologies are being used.  Looking at script references can tell you things like:

ASP or ASP.NET

JQuery

YUI

Third-party ASP.NET controls (Eg. Infragistics, Telerik, etc..)

JSF and JSF2

Third party JSF controls (Eg. Richfaces, Primefaces, etc...)

Google API's

Sometimes even urls for various public web services like Amazon or Google.

You can gather an absurd amount of architecture clues just by View Source of a web page.

Title: Where should I look to know which technology is used in a web app?

Body:
Let's say, I have one or more web app I find interesting, and as I want to do something similar, I would like to know on which technology they are based (programming language, database, web server, framework, ...).

Is there any site where such information is centralized? If not, where should I look for this information?


答:
Be sure to allow spaces. Everyone I know can type short phrases faster than they can type the first letter of each word in the phrase. Eg try typing Bird in a Tree and then BiaT. This has the advantage that if you write a vaguely work appropriate phrase like pick Up milk or Meetings all day on a sticky note, it isn't obviously a password.

I'm not a big fan of the "you must have numbers and symbols" rules, but if you apply them consistently (eg i is always 1, a is always @) then you can still write the English phrase on the sticky, apply the known-only-to-you-leet-speak rules, and enter B1rd in @ tree on the password dialog. From a security point of view, the numbers and symbols don't add much, but they don't need to make you crazy as a user.

Sites with maximum password length make me angy if my nice phrase is deemed "too long". 26 seems reasonable. I understand someone has to design the width of the column, but 12 is just stupidly short.


问:
Delegate vs Interfaces-Any more clarifications available?
After reading the article-
When to Use Delegates Instead of Interfaces (C# Programming Guide),
I need some help  understanding the below given points, which I found to be not so clear (for me).
Any examples or detailed explanations available for these?

Use a delegate when:

An eventing design pattern is used.

It is desirable to encapsulate a static method.

Easy composition is desired.

A class may need more than one implementation of the method.

Use an interface when:

There are a group of related methods that may be called.

A class only needs one implementation of the method.

My Questions are,

What do they mean by an eventing design pattern?

How the composition turns out to be easy if a delegate is used?

if there is a group of related methods that may be called,then use interface-What benefit it has?

if a class only needs one implementation of the method,  use interface-how is it justified in terms of benefits?

答:
The "eventing" design pattern (better known as the Observer Pattern) allows you to attach multiple methods of the same signature to the delegate. You can't really do that with an interface.

I'm not at all convinced that composition is easier for a delegate than an interface though. That's a very odd statement. I wonder if he means because you can attach anonymous methods to a delegate.


答:
1) Eventing patterns, well the classic is the Observer pattern, here's a good Microsoft link
Microsoft talk Observer

The article you linked to isn't very well written imo and makes things more complicated than necessary. The static business is common sense, you can't define an interface with static members, so if you want polymorphic behaviour on a static method you would use a delegate.

The link above talks about delegates and why there are good for composition, so that might help with your query.

Title: Delegate vs Interfaces-Any more clarifications available?

Body:
After reading the article-
When to Use Delegates Instead of Interfaces (C# Programming Guide),
I need some help  understanding the below given points, which I found to be not so clear (for me).
Any examples or detailed explanations available for these?

Use a delegate when:

An eventing design pattern is used.

It is desirable to encapsulate a static method.

Easy composition is desired.

A class may need more than one implementation of the method.

Use an interface when:

There are a group of related methods that may be called.

A class only needs one implementation of the method.

My Questions are,

What do they mean by an eventing design pattern?

How the composition turns out to be easy if a delegate is used?

if there is a group of related methods that may be called,then use interface-What benefit it has?

if a class only needs one implementation of the method,  use interface-how is it justified in terms of benefits?


答:
A delegate is something like an interface for a single method signature, that doesn't have to be explicitly implemented like a regular interface. You can construct it on the run.

An interface is just a language structure representing some contract - "I hereby guarantee I make the following methods and properties available".

Also, I don't completely agree that delegates are primarily useful when used as an solution to the observer/subscriber pattern. It is, however, en elegant solution to the "java verbosity problem".

For your questions:

1 & 2)

If you want to create an event system in Java you typically use an interface to propagate the event, something like:

```<code>interface KeyboardListener
{
    void KeyDown(int key);
    void KeyUp(int key)
    void KeyPress(int key);
    .... and so on
}
</code>```

This means your class will have to explicitly implement all these methods, and provide stubs for all of them even if you simply want to implement KeyPress(int key).

In C#, these events would be represented as lists of delegate, hidden by the "event" keyword in c#, one for each singular event. This means you can easily subscribe to what you want without burdening your class with public "Key" methods etc.

+1 for points 3-5.

Additionally:

Delegates are very useful when you want to supply for example a "map" function, that takes a list and projects each element into a new list, with the same amount of elements, but different in some way. Essentially, IEnumerable.Select(...).

IEnumerable.Select takes a Func<TSource, TDest>, which is a delegate wrapping a function that takes a TSource element and transforms that element into a TDest element.

In Java this would have to be implemented using an interface. There is often no natural place to implement such an interface. If a class contains a list that it wants to transform in some way, it's not very natural that it implements the interface "ListTransformer", especially since there might be two different lists that should be transformed in different ways.

Of course, you could use anonymous classes which are a similar concept (in java).

Body:
A delegate is something like an interface for a single method signature, that doesn't have to be explicitly implemented like a regular interface. You can construct it on the run.

An interface is just a language structure representing some contract - "I hereby guarantee I make the following methods and properties available".

Also, I don't completely agree that delegates are primarily useful when used as an solution to the observer/subscriber pattern. It is, however, en elegant solution to the "java verbosity problem".

For your questions:

1 & 2)

If you want to create an event system in Java you typically use an interface to propagate the event, something like:

interface KeyboardListener
{
    void KeyDown(int key);
    void KeyUp(int key)
    void KeyPress(int key);
    .... and so on
}

This means your class will have to explicitly implement all these methods, and provide stubs for all of them even if you simply want to implement KeyPress(int key).

In C#, these events would be represented as lists of delegate, hidden by the "event" keyword in c#, one for each singular event. This means you can easily subscribe to what you want without burdening your class with public "Key" methods etc.

+1 for points 3-5.

Additionally:

Delegates are very useful when you want to supply for example a "map" function, that takes a list and projects each element into a new list, with the same amount of elements, but different in some way. Essentially, IEnumerable.Select(...).

IEnumerable.Select takes a Func<TSource, TDest>, which is a delegate wrapping a function that takes a TSource element and transforms that element into a TDest element.

In Java this would have to be implemented using an interface. There is often no natural place to implement such an interface. If a class contains a list that it wants to transform in some way, it's not very natural that it implements the interface "ListTransformer", especially since there might be two different lists that should be transformed in different ways.

Of course, you could use anonymous classes which are a similar concept (in java).


问:
Is this the right strategy to convert an in-level order binary tree to a doubly linked list?
So I recently came across this question - Make a function that converts a in-level-order binary tree into a doubly linked list. Apparently, it's a common interview question.

This is the strategy I had - Simply do a pre-order traversal of the tree, and instead of returning a node, return a list of nodes, in the order in which you traverse them. i.e return a list, and append the current node to the list at each point. For the base case, return the node itself when you are at a leaf.

so you would say

```<code>left = recursive_function(node.left)
right = recursive_function(node.right)
return(left.append(node.data)).append(right);`
</code>```

Is this the right approach?

答:
Top and tail with a script tag</p>

```<code>// load as html page.
// this will write "c1 b1 c2 a1 c3 b2 c4" to the browser

// test data
var c1 = {data: "c1"};
var c2 = {data: "c2"};
var c3 = {data: "c3"};
var c4 = {data: "c4"};
var b1 = {data: "b1", left: c1, right: c2};
var b2 = {data: "b2", left: c3, right: c4};
var a1 = {data: "a1", left: b1, right: b2};

// production function
var llist = function walktree(node)
{
    var l, r, head, tail;
    if ( node.left !== undefined)
    {
        l = walktree(node.left );
        node.prev = l.tail;
        l.tail.next = node;
        head = l.head;
    }
    else
    {
        head = node;
    }
    if ( node.right !== undefined)
    {
        r = walktree(node.right );
        node.next = r.head;
        r.head.prev = node;
        tail = r.tail;
    }
    else
    {
        tail = node;
    }
    return { head: head, tail: tail};
}(a1);

// test harness
var llnode = llist.head;
while ( llnode !== undefined)
{
    document.writeln( llnode.data );
    llnode = llnode.next;
}
</code>```

Body:
Top and tail with a script tag

// load as html page.
// this will write "c1 b1 c2 a1 c3 b2 c4" to the browser

// test data
var c1 = {data: "c1"};
var c2 = {data: "c2"};
var c3 = {data: "c3"};
var c4 = {data: "c4"};
var b1 = {data: "b1", left: c1, right: c2};
var b2 = {data: "b2", left: c3, right: c4};
var a1 = {data: "a1", left: b1, right: b2};

// production function
var llist = function walktree(node)
{
    var l, r, head, tail;
    if ( node.left !== undefined)
    {
        l = walktree(node.left );
        node.prev = l.tail;
        l.tail.next = node;
        head = l.head;
    }
    else
    {
        head = node;
    }
    if ( node.right !== undefined)
    {
        r = walktree(node.right );
        node.next = r.head;
        r.head.prev = node;
        tail = r.tail;
    }
    else
    {
        tail = node;
    }
    return { head: head, tail: tail};
}(a1);

// test harness
var llnode = llist.head;
while ( llnode !== undefined)
{
    document.writeln( llnode.data );
    llnode = llnode.next;
}


问:
What do you consider to be the prime cause of software defects (and how to minimize them)
I define defect as :

"something within the application design or code which prevents it functioning as per requirements."

I'm looking for ideas about the causes of defects, eg the human factor, lack of testing, lack of prototyping, and possible ideas to mitigate these.

答:
Communication gap. In requirements collection. In schedule. In design document. In functional specification. In code (gap between what programmer wants and what he tells the compiler).

Social etiquette. It is socially unacceptable to call someone incapable.


答:
I find that I reach for Google more when working on a small codebase, or when I don't know the language, framework or libraries I'm working with.

If you want to experience working without copy-and-paste, pick your most familier language, and find the biggest interesting open source project in that language.  Try working on it, and maybe even try finding some open bugs to work on.  You'll probably only use Google to understand the project and code, and never reach for CTRL+C.


问:
Should the build drive your tags or should the tags drive the build?
Our current method of creating a product release is to tag all of our component repositories with the next appropriate version and then modify a master build script with these new version numbers for each component.  The master build script will then be run and it will perform a SCM checkout of each component, then modify the AssemblyInfo.cs file so that the compiled .exe (or .dll) has the correct version number, and then compile the component.  All of these components are then coalesced into a product release which is "versioned" with a pure marketing decided number.

So our process falls under the "tags drive the build" description, but I am not certain that is the best method.  Specifically, where I see this failing us is if we were to integrate our release build into the CI process, it seems like it would be backwards.

Not just that, but where in a typical release-management process does the decision for the new component version numbers come in? Someone has to decide when component A goes from 2.1.4 to 3.0.0 and if library B should change from 6.3.2 to 6.3.3 or 6.4.0.  Where are these version numbers stored and at what stage are they decided?  Currently, we make these decisions at the "last moment" and they are stored in the master build script.  The master build script itself is versioned and is tagged with the "marketing" version number.

答:
I think "tags drive the build" is a good system in general, because it is easy to understand and use in all stages of your dev/test/qa/release cycle. If you are feeding a tag into your build script, you are deliberately saying "build x.y" is ready for the next step.

A build number that comes out of a CI process is useful too, but might not capture change information with the same grace - which is more descriptive: 2.3.5 or 23432?

No matter what public system of labeling you use, make sure detailed versioning information is accessible for debugging/reporting purposes - be as accurate as possible: version number, CI build number, source control revision number, build date and time - whatever data you need to nail down exactly what build you are dealing with.

As for the decision points, yes ultimately they are arbitrary and come down to whatever works. The semantic versioning system @Justice mentions is great: the important thing is that the team should be able come up with a system that is fairly easy to use when deciding what version number to use next.


答:
Back when I knew one language applied to one methodology/interface (in my case it was Perl/CGI, which give you a sense of my vintage as a developer), I knew everything about it. I literally had all of Perl in my head. Regular expressions, IO syntax, even those old-school <<<|..|<<|>>> reporting string controls, I knew them cold.

The minute I learned my second language, not only was I never able to attain that kind of retention, I also lost Perl. It doesn't help that my second language was PHP, which has no interest in language consistency, in terms of function names or parameter orders.

In the interview for my current job, I gained points with my now-manager by admitting right up front that Google is my best friend. I'm not shy in the slightest. Today I'm going to need to google the phrase "Spring MVC file upload" to tackle a function I've done many many times, but in a language and framework I'm new to. I fully expect I'll find more or less fully formed answers that I'll need to adapt into my framework.


问:
Why are there no PUT and DELETE methods on HTML forms?
HTML4 / XHTML1 allows only GET and POST in forms, now it seems like HTML5 will do the same. There is a proposal to add these two but it doesn't seem to be gaining traction.

What were the technical or political reasons for not including PUT and DELETE in HTML5 specification draft?

答:
Just throwing out a wild guess, but probably because HTTP isn't terribly good with access control at the best of times, and the last thing everyone needs is even more ways for malicious URLs to compromise a poorly secured website and/or application.

HTTP isn't really a good protocol for file transfers other than downloading from server to client. Use FTP - or better yet, SFTP.

ContentLicense: CC BY-SA 4.0


问:
How can I automate production deployments without experiencing extreme anxiety?
At our shop we use SVN for source control and CruiseControl for CI on handling automatic builds and deployments to our development, test, and integration environments.

This all works smoothly however due to hardware and resource constraints our integration environment is not a 2 server load balanced environment like our production environment.  While everything else is equal that would be the only difference between our integration and production environments (although a big one!)

Theoretically the difference is a slightly different configuration of our app servers and the deploy script merely would have to drop the build artifacts into two servers instead of just the one, but why am I so nervous to automate our production deployments?!

I am generally not a control freak but I always feel the insatiable need to deploy production to production manually.  I have heard from colleagues that this is generally a Really BAD Thing™ but they failed to make a case against it.

I know that when I do it manually I can SEE that I am physically copying the correct files, I am physically shutting down the app servers and ensuring they closed successfully, I am physically starting the servers back up and then physically inspecting the logs to make sure it started up okay and the deployment was successful.  It gives me a peace of mind.

What are arguments against this OR arguments for automatic scripted production deployment?

答:
There are a few obvious arguments against this.

What happens if you leave.  Is all this information carefully documented, or is it mostly in your head.  Automated scripts are a much better place for someone else to take over from.

Everyone makes mistakes.  There will come a time when the person doing the deployment is tired, not paying attention whatever.  Yes ideally deployments are only done in an happy calm place with lots of time.  In practise they can be rushed and stressed when trying to roll out urgent fixes.  This is the mostly likely time to make a mistake, and also the most costly.  If the deployment is a single script then the potential for mistakes is limited.

Time.  As deployments get more complicated the amount that needs doing increases.  Scripts just require kicking off, a manual check, and then a manual switch-over (you could automate this as well, but I share some of the paranoia :).


问:
Ways of integrating legacy applications
My company is one which has grown up rapidly over recent years in multiple territories. We are not a software company per se, but a technical one who have developed various bespoke applications inhouse. Some of these are now sold as SAAS.

I am personally responsible for 3 of these applications: all internal web applications, one written in MySQL/Python/Django, one written in SQL Server/Python/Django and one in MySQL/PHP/Symfony. My developer resource includes expertise in all of these, as well as some Java and Adobe Flex. None of us have any significant experience in Microsoft technologies beyond SQL Server.

However, all the other departments in my company that have developers all work using the Microsoft stack - all our other webapps are C#/asp.NET etc etc etc.

I have been asked to evaluate integration of our depts products with others in the company at a data-sharing and presentational level.

I see 3 possible routes:

We bite the bullet and move to the Microsoft development stack, and this becomes a company-wide policy. Pros: standardisation, ability to pool resource, integration can be done at any level. Cons: massive licensing costs we can't really afford right now, complete retraining of all developers required, having to use IIS instead of nice Ubuntu/Apache servers, and general philosophical opposition (we're mostly open-source evangelists in my dept).

Middleware. We've been looking at Adobe Flex in order to handle data subscriptions between services. Pros: relatively cheap solution, existing in-house experience, can use whatever underlying tech we choose. Cons: it took ages to get a quote for Adobe data services, it isn't clear to me how futureproof this route is - are we potentially buying into a tech that's going extinct?

DIY. We stick with open-source all the way, and custom-write web service APIs between all the apps. Pros: cheap on licensing, open-source. Cons: additional time required, more testing, core issue of techology proliferation not tackled

I'd be interested to know what other approaches there might be here. Are there other Middleware ways of going about this? Am I hopelessly out of date with my views? What's a safe bet for the future?

Thanks

答:
You have at least two different issues here that you are conflating into one.

Toolset / stack

Communication

For the first, you may or may not want to migrate towards fewer technologies.  Having one of everything under the sun can make maintenance difficult, and does limit your ability to share certain parts of your applications.

Communication between modules/applications/systems is the second part.  You mention data subscription, do you really have real-time push-type requirements.  If you do, then you should look at message-bus type technologies like RabbitMQ, ActiveMQhere and others (there are many questions covering these on this and other sites).

If on the other hand, you merely want to centralize some data, simple web services (be they SOAP or REST based) may well be your best bet.  The .NET teams can easily create them, and all your other technologies can merely call them, and vice versa.  This may well be your best short-term bet, allowing the various siloed apps to communicate while you work out a bigger plan.

Title: Ways of integrating legacy applications


问:
If you use MFC how did find it best to learn the concepts?
I'm currently working with C++ MFC applications in Visual Studio 2008.  I have spent most of my time up to this point working with Java Swing development which seems to be not quite as involved as win32 or MFC are.  I've noticed that there seems to be a lot of little parameters and specifications that go into creating even a simple element like a status bar or menu bar.  I've spent a bit of time working through the MSDN library on the matter but it doesn't seem to explain why many of these parameters and such are needed to set up these elements.  I always find that I'm able to wrap my head around things and remember them if I understand why I'm doing it. If you program using MFC (or a similar framework) what did you find helpful in the learning process? Do you recommend any website, books, or other references?  Any and all advice is appreciated!</p>

答:
I found MFC Internals by Shepherd/Wingo an excellent resource.

Covering the internals means it's not bogged down in beginner stuff and IDE explanations and it draws quite some lines between "raw" Win32 programming and using the MFC.


答:
You can get the best of best worlds: peace of mind with process verification and the reliability of automation.

Script the deployment.  Then, go through and manually verify that processes are started, files removed, etc.  In other words, write your own QA script just to verify that automated steps 1 - X actually occurred.

Title: How can I automate production deployments without experiencing extreme anxiety?

Body:
At our shop we use SVN for source control and CruiseControl for CI on handling automatic builds and deployments to our development, test, and integration environments.

This all works smoothly however due to hardware and resource constraints our integration environment is not a 2 server load balanced environment like our production environment.  While everything else is equal that would be the only difference between our integration and production environments (although a big one!)

Theoretically the difference is a slightly different configuration of our app servers and the deploy script merely would have to drop the build artifacts into two servers instead of just the one, but why am I so nervous to automate our production deployments?!

I am generally not a control freak but I always feel the insatiable need to deploy production to production manually.  I have heard from colleagues that this is generally a Really BAD Thing™ but they failed to make a case against it.

I know that when I do it manually I can SEE that I am physically copying the correct files, I am physically shutting down the app servers and ensuring they closed successfully, I am physically starting the servers back up and then physically inspecting the logs to make sure it started up okay and the deployment was successful.  It gives me a peace of mind.

What are arguments against this OR arguments for automatic scripted production deployment?


问:
Good resources and tools for modern, heavy JavaScript development?
I am interested in doing some projects that involve heavy use of JavaScript. Namely HTML5 based canvas games, potentially using node.js as well. I am interested in learning modern best practices, tools and resources for JavaScript.

JavaScript is tough to research because you end up wading through a lot of really outdated material, hailing from the times that "JavaScript" was a four letter word.

If you are heavily involved in JavaScript programming...

What text editor or IDE do you use?

What unit testing framework do you use?

Do you use Selenium, or something else?

What other tools do you use?

What communities exist that discuss recent advents in JavaScript?

What books do you read/refer to?

What blogs do you read?

答:
Hopefully won't get flamed too much for this, but if things like IDEs and tooling are important to you, then I strongly recommend looking at Google Web Toolkit.  You write your code in Java in Eclipse, which really helps write your code.  It provides highly effective code completion, refactoring utilities and help to debug and navigate through your codebase.

You can still go into raw Javascript when you need to.

Your code then gets compiled into optimised, minified JS.  I have used this approach successfully in a node.js-like DOMless JS environment.

For HTML5 games, check out PlayN which is a library that uses GWT for exactly that.


答:
There are probably those in the company that see too many disparate systems that are duplicating effort and making it harder to include data in the same report. The head of IT needs to focus on design and not be so myopic to think everyone using the same language is the panacea.

Consolidating to the MS stack may make it easier to share developers and knowledge. SQL Server is the most cost prohibitive part of doing this. There are other licensing issues for Windows Server and Visual Studio. If you can find an ROI for business operations and/or the development costs, you can justify the purchase.

Data integration is not going to be a pure technical problem just because you're on different stacks. You could do this through web services.

With presentation, you need a consistent ui design. A web app user could be moved to a different technology when they go from one module/department app to another without even knowing it. You need to decide what makes sense to consolidate. Are there separate databases holding employee data that are manually updated to match? HR and Sales have this in common. A good test is to see how difficult it is to have an employee leave, get hired, or have a name change due to marriage.

You should be providing some input from your department, but someone higher up in the company needs to be seeing the bigger picture.

Title: Ways of integrating legacy applications

Body:
My company is one which has grown up rapidly over recent years in multiple territories. We are not a software company per se, but a technical one who have developed various bespoke applications inhouse. Some of these are now sold as SAAS.

I am personally responsible for 3 of these applications: all internal web applications, one written in MySQL/Python/Django, one written in SQL Server/Python/Django and one in MySQL/PHP/Symfony. My developer resource includes expertise in all of these, as well as some Java and Adobe Flex. None of us have any significant experience in Microsoft technologies beyond SQL Server.

However, all the other departments in my company that have developers all work using the Microsoft stack - all our other webapps are C#/asp.NET etc etc etc.

I have been asked to evaluate integration of our depts products with others in the company at a data-sharing and presentational level.

I see 3 possible routes:

We bite the bullet and move to the Microsoft development stack, and this becomes a company-wide policy. Pros: standardisation, ability to pool resource, integration can be done at any level. Cons: massive licensing costs we can't really afford right now, complete retraining of all developers required, having to use IIS instead of nice Ubuntu/Apache servers, and general philosophical opposition (we're mostly open-source evangelists in my dept).

Middleware. We've been looking at Adobe Flex in order to handle data subscriptions between services. Pros: relatively cheap solution, existing in-house experience, can use whatever underlying tech we choose. Cons: it took ages to get a quote for Adobe data services, it isn't clear to me how futureproof this route is - are we potentially buying into a tech that's going extinct?

DIY. We stick with open-source all the way, and custom-write web service APIs between all the apps. Pros: cheap on licensing, open-source. Cons: additional time required, more testing, core issue of techology proliferation not tackled

I'd be interested to know what other approaches there might be here. Are there other Middleware ways of going about this? Am I hopelessly out of date with my views? What's a safe bet for the future?

Thanks


答:
GET and POST have a clear content-neutral rationale. GET is to retrieve the content of an URL in a way that is safe to repeat and possibly cache. POST is to do something in a way that is not safe to repeat, execute speculatively, or cache.

There was no similar rationale for PUT or DELETE. They are both completely covered by POST. Creating or destroying a resource are operations that are not safe to repeat, not safe to execute speculatively, and should not be cached. There are no additional special semantics needed for them.

So basically there is no benefit.

Title: Why are there no PUT and DELETE methods on HTML forms?

Body:
HTML4 / XHTML1 allows only GET and POST in forms, now it seems like HTML5 will do the same. There is a proposal to add these two but it doesn't seem to be gaining traction.

What were the technical or political reasons for not including PUT and DELETE in HTML5 specification draft?


问:
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.

答:
Have you considered having a daemon or cron job run on the file server and collect the relevant information and put it in a separate file (or pipe)?  That gives you your list of files to process, without having to waste a lot of time assembling and groveling over directory listings before you can start the real work.

Regardless, I don't think the speed difference between reading a file and querying a database will be significant.  Keeping the information in a database might be useful for other reasons (e.g., process auditing), but I don't think it'll help your performance.


答:
I think the key here is: why do you think that you can't script the verification process?

My deploy scripts don't just push archives and restart services. They print out lots of color-coded information during each step of the deploy, and provide me a summary of events at the end. It lets me know that processes are up and running, that the homepage is serving a 200 status code, and that all the machines and services can see one another fine. I then have a separate service that's not part of the script which monitors log files, 4xx and 5xx-level errors, and key site metrics. It then proceeds to yell at me through every medium possible (email, txt msg, and alarms) if there are drastic negative-effect spikes.

Between that and CI servers running tests, I literally deploy and forget at this level of automation. I don't even browse a single page on the site after a push because of how reliable the process now is, which not only lets me deploy as often as I want, but lets a new developer on the project make an update to the live site within minutes of coming on board. In the past I've even made the CI servers auto-deploy to production after a commit to a master/trunk branch that passes everything. That's how confident I am in my tools.

You should be too.


答:
In the days of MFC, my go to book was:

Think of it as an MFC cookbook chock full of pragmatic MFC code that solves specific problems. Certainly remember dipping into this book with greater frequency than any other MFC book I owned.

Title: If you use MFC how did find it best to learn the concepts?

Body: I'm currently working with C++ MFC applications in Visual Studio 2008.  I have spent most of my time up to this point working with Java Swing development which seems to be not quite as involved as win32 or MFC are.  I've noticed that there seems to be a lot of little parameters and specifications that go into creating even a simple element like a status bar or menu bar.  I've spent a bit of time working through the MSDN library on the matter but it doesn't seem to explain why many of these parameters and such are needed to set up these elements.  I always find that I'm able to wrap my head around things and remember them if I understand why I'm doing it. If you program using MFC (or a similar framework) what did you find helpful in the learning process? Do you recommend any website, books, or other references?  Any and all advice is appreciated!</p>


答:
I can understand being a bit nervous trying something new on the prod environment. Being wary of potential disaster is a Good ThingTM.

Automated scripting is also a Good ThingTM and so long as you approach it carefully, you should be able to minimise the danger and lower your fear. So my advice is this;

Prepare (and practice on the integration env) a checklist/set of tests so you can quickly find out whether it worked and what if anything went wrong. Verbose logging may help with this.

Back up everything. Prepare and practice a manual rollback so that you can recover if it goes badly wrong.

Test as much as you can before you do it for real on prod. Sounds like you're a good way along with this with your integration env.

First time you try it, do it on a low profile, low impact change. Something like a minor upgrade or patch. The idea is to minimise the fallout if it goes wrong. Do not choose a high profile major upgrade (where the CEO and all your competitors are watching) for your first run.

Once you've got a few successful runs under your belt your confidence will grow and soon you'll wonder how you ever managed doing manual deployments.


问:
Are value converters more trouble than they're worth?
I'm working on a WPF application with views that require numerous value conversions. Initially, my philosophy (inspired in part by this lively debate on XAML Disciples) was that I should make the view model strictly about supporting the data requirements of the view. This meant that any value conversions required to turn data into things like visibilities, brushes, sizes, etc. would be handled with value converters and multi-value converters. Conceptually, this seemed quite elegant. The view model and view would both have a distinct purpose and be nicely decoupled. A clear line would be drawn between "data" and "look".

Well, after giving this strategy "the old college try", I'm having some doubts whether I want to continue developing this way. I'm actually strongly considering dumping the value converters and placing the responsibility for (almost) all value conversion squarely in the hands of the view model.

The reality of using value converters just doesn't seem to be measuring up to the apparent value of cleanly separated concerns. My biggest issue with value converters is that they are tedious to use. You have to create a new class, implement IValueConverter or IMultiValueConverter, cast the value or values from object to the correct type, test for DependencyProperty.Unset (at least for multi-value converters), write the conversion logic, register the converter in a resource dictionary [see update below], and finally, hook up the converter using rather verbose XAML (which requires use of magic strings for both the binding(s) and the name of the converter [see update below]). The debugging process is no picnic either, as error messages are often cryptic, especially in Visual Studio's design mode/Expression Blend.

This isn't to say that the alternative--making the view model responsible for all value conversion--is an improvement. This could very well be a matter of the grass being greener on the other side. Besides losing the elegant separation of concerns, you have to write a bunch of derived properties and make sure you conscientiously call RaisePropertyChanged(() => DerivedProperty) when setting base properties, which could prove to be an unpleasant maintenance issue.

The following is an initial list I put together of the pros and cons of allowing view models to handle conversion logic and doing away with value converters:

Pros:

Fewer total bindings since multi-converters are eliminated

Fewer magic strings (binding paths + converter resource names)

No more registering each converter (plus maintaining this list)

Less work to write each converter (no implementing interfaces or casting required)

Can easily inject dependencies to help with conversions (e.g., color tables)

XAML markup is less verbose and easier to read

Converter reuse still possible (although some planning is required)

No mysterious issues with DependencyProperty.Unset (a problem I noticed with multi-value converters)

*Strikethroughs indicate benefits that disappear if you use markup extensions (see update below)

Cons:

Stronger coupling between view model and view (e.g., properties must deal with concepts like visibility and brushes)

More total properties to allow direct mapping for every binding in view

RaisePropertyChanged must be called for each derived property (see Update 2 below)

Must still rely on converters if the conversion is based on a property of a UI element

So, as you can probably tell, I have some heartburn about this issue. I'm very hesitant to go down the road of refactoring only to realize that the coding process is just as inefficient and tedious whether I use value converters or expose numerous value conversion properties in my view model.

Am I missing any pros/cons? For those who have tried both means of value conversion, which did you find worked better for you and why? Are there any other alternatives? (The disciples mentioned something about type descriptor providers, but I couldn't get a handle on what they were talking about. Any insight on this would be appreciated.)

Update

I found out today that it's possible to use something called a "markup extension" to eliminate the need to register value converters. In fact, it not only eliminates the need to register them, but it actually provides intellisense for selecting a converter when you type Converter=. Here is the article that got me started: http://www.wpftutorial.net/ValueConverters.html.

The ability to use a markup extension changes the balance somewhat in my pros and cons listing and discussion above (see strikethroughs).

As a result of this revelation, I'm experimenting with a hybrid system where I use converters for BoolToVisibility and what I call MatchToVisibility and the view model for all other conversions. MatchToVisibility is basically a converter that lets me check if the bound value (usually an enum) matches one or more values specified in XAML.

Example:

```<code>Visibility="{Binding Status, Converter={vc:MatchToVisibility
            IfTrue=Visible, IfFalse=Hidden, Value1=Finished, Value2=Canceled}}"
</code>```

Basically what this does is check if the status is either Finished or Canceled. If it is, then the visibility gets sets to "Visible". Otherwise, it gets sets to "Hidden". This turned out to be a very common scenario, and having this converter saved me about 15 properties on my view model (plus associated RaisePropertyChanged statements). Note that when you type Converter={vc:, "MatchToVisibility" shows up in an intellisense menu. This noticeably reduces the chance of errors and makes using value converters less tedious (you don't have to remember or look up the name of the value converter you want).

In case you're curious, I'll paste the code below. One important feature of this implementation of MatchToVisibility is that it checks to see if the bound value is an enum, and if it is, it checks to make sure Value1, Value2, etc. are also enums of the same type. This provides a design-time and run-time check of whether any of the enum values are mistyped. To improve this to a compile-time check, you can use the following instead (I typed this by hand so please forgive me if I made any mistakes):

```<code>Visibility="{Binding Status, Converter={vc:MatchToVisibility
            IfTrue={x:Type {win:Visibility.Visible}},
            IfFalse={x:Type {win:Visibility.Hidden}},
            Value1={x:Type {enum:Status.Finished}},
            Value2={x:Type {enum:Status.Canceled}}"
</code>```

While this is safer, it's just too verbose to be worth it for me. I might as well just use a property on the view model if I'm going to do this. Anyway, I'm finding that the design-time check is perfectly adequate for the scenarios I've tried so far.

Here's the code for MatchToVisibility

```<code>[ValueConversion(typeof(object), typeof(Visibility))]
public class MatchToVisibility : BaseValueConverter
{
    [ConstructorArgument("ifTrue")]
    public object IfTrue { get; set; }

    [ConstructorArgument("ifFalse")]
    public object IfFalse { get; set; }

    [ConstructorArgument("value1")]
    public object Value1 { get; set; }

    [ConstructorArgument("value2")]
    public object Value2 { get; set; }

    [ConstructorArgument("value3")]
    public object Value3 { get; set; }

    [ConstructorArgument("value4")]
    public object Value4 { get; set; }

    [ConstructorArgument("value5")]
    public object Value5 { get; set; }

    public MatchToVisibility() { }

    public MatchToVisibility(
        object ifTrue, object ifFalse,
        object value1, object value2 = null, object value3 = null,
        object value4 = null, object value5 = null)
    {
        IfTrue = ifTrue;
        IfFalse = ifFalse;
        Value1 = value1;
        Value2 = value2;
        Value3 = value3;
        Value4 = value4;
        Value5 = value5;
    }

    public override object Convert(
        object value, Type targetType, object parameter, CultureInfo culture)
    {
        var ifTrue = IfTrue.ToString().ToEnum<Visibility>();
        var ifFalse = IfFalse.ToString().ToEnum<Visibility>();
        var values = new[] { Value1, Value2, Value3, Value4, Value5 };
        var valueStrings = values.Cast<string>();
        bool isMatch;
        if (Enum.IsDefined(value.GetType(), value))
        {
            var valueEnums = valueStrings.Select(vs => vs == null ? null : Enum.Parse(value.GetType(), vs));
            isMatch = valueEnums.ToList().Contains(value);
        }
        else
            isMatch = valueStrings.Contains(value.ToString());
        return isMatch ? ifTrue : ifFalse;
    }
}
</code>```

Here's the code for BaseValueConverter

```<code>// this is how the markup extension capability gets wired up
public abstract class BaseValueConverter : MarkupExtension, IValueConverter
{
    public override object ProvideValue(IServiceProvider serviceProvider)
    {
        return this;
    }

    public abstract object Convert(
        object value, Type targetType, object parameter, CultureInfo culture);

    public virtual object ConvertBack(
        object value, Type targetType, object parameter, CultureInfo culture)
    {
        throw new NotImplementedException();
    }
}
</code>```

Here's the ToEnum extension method

```<code>public static TEnum ToEnum<TEnum>(this string text)
{
    return (TEnum)Enum.Parse(typeof(TEnum), text);
}
</code>```

Update 2

Since I posted this question, I've come across an open-source project that uses "IL weaving" to inject NotifyPropertyChanged code for properties and dependent properties. This makes implementing Josh Smith's vision of the view model as a "value converter on steroids" an absolute breeze. You can just use "Auto-Implemented Properties", and the weaver will do the rest.

Example:

If I enter this code:

```<code>public string GivenName { get; set; }
public string FamilyName { get; set; }

public string FullName
{
    get
    {
        return string.Format("{0} {1}", GivenName, FamilyName);
    }
}
</code>```

...this is what gets compiled:

```<code>string givenNames;
public string GivenNames
{
    get { return givenName; }
    set
    {
        if (value != givenName)
        {
            givenNames = value;
            OnPropertyChanged("GivenName");
            OnPropertyChanged("FullName");
        }
    }
}

string familyName;
public string FamilyName
{
    get { return familyName; }
    set
    {
        if (value != familyName)
        {
            familyName = value;
            OnPropertyChanged("FamilyName");
            OnPropertyChanged("FullName");
        }
    }
}

public string FullName
{
    get
    {
        return string.Format("{0} {1}", GivenName, FamilyName);
    }
}
</code>```

That's a huge savings in the amount of code you have to type, read, scroll past, etc. More importantly, though, it saves you from having to figure out what your dependencies are. You can add new "property gets" like FullName without having to painstakingly go up the chain of dependencies to add in RaisePropertyChanged() calls.

What is this open-source project called? The original version is called "NotifyPropertyWeaver", but the owner (Simon Potter) has since created a platform called "Fody" for hosting a whole series of IL weavers. The equivalent of NotifyPropertyWeaver under this new platform is called PropertyChanged.Fody.

Fody setup instructions: http://code.google.com/p/fody/wiki/SampleUsage (replace "Virtuosity" with "PropertyChanged")

PropertyChanged.Fody project site: http://code.google.com/p/propertychanged/

If you'd prefer to go with NotifyPropertyWeaver (which a little simpler to install, but won't necessarily be updated in the future beyond bug fixes), here is the project site:
http://code.google.com/p/notifypropertyweaver/

Either way, these IL weaver solutions completely change the calculus in the debate between view model on steroids vs. value converters.

答:
I have used ValueConverters in some cases and put the logic in the ViewModel in others.  My feeling is that a ValueConverter becomes part of the View layer, so if the logic is really part of the View then put it there, otherwise put it in the ViewModel.

Personally I don't see a problem with a ViewModel dealing with View-specific concepts like Brushes because in my applications a ViewModel only exists as a testable and bindable surface for the View.  However, some people put a lot of business logic in the ViewModel (I do not) and in that case the ViewModel is more like a part of their business layer, so in that case I wouldn't want WPF-specific stuff in there.

I prefer a different separation:

View - WPF stuff, sometimes untestable (like XAML and code-behind) but also ValueConverters

ViewModel - testable and bindable class that is also WPF-specific

EditModel - part of the business layer that represents my model during manipulation

EntityModel - part of the business layer that represents my model as persisted

Repository - responsible for persistence of the EntityModel to the database

So, the way I do it, I have little use for ValueConverters

The way I got away from some of your "Con's" is to make my ViewModel's very generic.  For instance, one ViewModel I have, called ChangeValueViewModel implements a Label property and a Value property.  On the View there's a Label that binds to the Label property and a TextBox that binds to the Value property.

I then have a ChangeValueView which is a DataTemplate keyed off of the ChangeValueViewModel type.  Whenever WPF sees that ViewModel it applies that View.  The constructor of my ChangeValueViewModel takes the interaction logic it needs to refresh its state from the EditModel (usually just passing in a Func<string>) and the action it needs to take when the user edits the Value (just an Action that executes some logic in the EditModel).

The parent ViewModel (for the screen) takes an EditModel in its constructor and just instantiates the appropriate elementary ViewModels such as ChangeValueViewModel.  Since the parent ViewModel is injecting the action to take when the user makes any change, it can intercept all of these actions and take other actions.  Therefore, the injected edit action for a ChangeValueViewModel might look like:

```<code>(string newValue) =>
{
    editModel.SomeField = newValue;
    foreach(var childViewModel in this.childViewModels)
    {
        childViewModel.RefreshStateFromEditModel();
    }
}
</code>```

Obviously the foreach loop can be refactored elsewhere, but what this does is take the action, apply it to the model, then (assuming the model has updated its state in some unknown way), tells all the child ViewModels to go and get their state from the model again.  If the state has changed, they are responsible for executing their PropertyChanged events, as necessary.

That handles the interaction between, say, a list box and a details panel quite nicely.  When the user selects a new choice, it updates the EditModel with the choice, and the EditModel changes the values of the properties exposed for the detail panel.  The ViewModel children that are responsible for displaying the detail panel information automatically get notified that they need to check for new values, and if they've changed, they fire their PropertyChanged events.

Body:
I have used ValueConverters in some cases and put the logic in the ViewModel in others.  My feeling is that a ValueConverter becomes part of the View layer, so if the logic is really part of the View then put it there, otherwise put it in the ViewModel.

Personally I don't see a problem with a ViewModel dealing with View-specific concepts like Brushes because in my applications a ViewModel only exists as a testable and bindable surface for the View.  However, some people put a lot of business logic in the ViewModel (I do not) and in that case the ViewModel is more like a part of their business layer, so in that case I wouldn't want WPF-specific stuff in there.

I prefer a different separation:

View - WPF stuff, sometimes untestable (like XAML and code-behind) but also ValueConverters

ViewModel - testable and bindable class that is also WPF-specific

EditModel - part of the business layer that represents my model during manipulation

EntityModel - part of the business layer that represents my model as persisted

Repository - responsible for persistence of the EntityModel to the database

So, the way I do it, I have little use for ValueConverters

The way I got away from some of your "Con's" is to make my ViewModel's very generic.  For instance, one ViewModel I have, called ChangeValueViewModel implements a Label property and a Value property.  On the View there's a Label that binds to the Label property and a TextBox that binds to the Value property.

I then have a ChangeValueView which is a DataTemplate keyed off of the ChangeValueViewModel type.  Whenever WPF sees that ViewModel it applies that View.  The constructor of my ChangeValueViewModel takes the interaction logic it needs to refresh its state from the EditModel (usually just passing in a Func<string>) and the action it needs to take when the user edits the Value (just an Action that executes some logic in the EditModel).

The parent ViewModel (for the screen) takes an EditModel in its constructor and just instantiates the appropriate elementary ViewModels such as ChangeValueViewModel.  Since the parent ViewModel is injecting the action to take when the user makes any change, it can intercept all of these actions and take other actions.  Therefore, the injected edit action for a ChangeValueViewModel might look like:

(string newValue) =>
{
    editModel.SomeField = newValue;
    foreach(var childViewModel in this.childViewModels)
    {
        childViewModel.RefreshStateFromEditModel();
    }
}

Obviously the foreach loop can be refactored elsewhere, but what this does is take the action, apply it to the model, then (assuming the model has updated its state in some unknown way), tells all the child ViewModels to go and get their state from the model again.  If the state has changed, they are responsible for executing their PropertyChanged events, as necessary.

That handles the interaction between, say, a list box and a details panel quite nicely.  When the user selects a new choice, it updates the EditModel with the choice, and the EditModel changes the values of the properties exposed for the detail panel.  The ViewModel children that are responsible for displaying the detail panel information automatically get notified that they need to check for new values, and if they've changed, they fire their PropertyChanged events.


问:
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 breakout area.

Somewhere where you can walk away from your desk and really chill out for a bit.